From nm at ti.com  Fri Dec  1 00:05:15 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 02:05:15 -0600
Subject: [PATCH 2/5] firmware: ti_sci: add suspend/resume support for irqs
In-Reply-To: <20231129-j7200-tisci-s2r-v1-2-c1d5964ed574@bootlin.com>
References: <20231129-j7200-tisci-s2r-v1-0-c1d5964ed574@bootlin.com>
 <20231129-j7200-tisci-s2r-v1-2-c1d5964ed574@bootlin.com>
Message-ID: <20231201080515.6g4wvjvays7ik647@passport>

On 16:31-20231129, Thomas Richard wrote:
> On j7200, during suspend to ram, the SoC is powered-off.

A53  and main domain is powered off in the case of J7200 - there are
different nuanced suspend-to-ram scenarios involved which the system
control firmware manages for us (Linux).

> The irqs configuration is lost, so it shall be restored at resume.
> The ti-sci has an internal list of irqs updated at each set/free.
> All irqs in this list are restored at resume.

This I don't disagree - but apply to all K3 SoCs. But what I do disagree
is that this is sufficient enough to have suspend-to-ram actually
functional. there are additional handshakes that are needed and the
driver just has a single suspend-resume handler..

git log --oneline drivers/firmware/ti_sci.c tells us that we have
already had a bunch of introduction, revert of suspend-resume handler
(too much for my comfort). I wish I didn't have to say this, but I
guess having seen TFA[1], U-boot[2] series (not that the kernel patch
discussion is independent of TFA/U-boot discussions), and having known
that the AM62x team is also working towards a suspend-resume scheme
(CCying Kevin and AM62x folks) - Since we all share a single driver,
I suggest we get together and draw through the arch of how this flow
will look like and not create additional confusion in the public list
on this till we have a settled down view (also the reason I haven't
picked up am62x patches so far either).

For now, I am going to punt this series until I see clarity overall
and I am assured that we have a relatively final path for all users of
TISCI driver/lib/infra.


[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23992/7
[2] https://lore.kernel.org/u-boot/20231109140738.GF6601 at bill-the-cat/

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From b-kapoor at ti.com  Fri Dec  1 00:20:42 2023
From: b-kapoor at ti.com (Bhavya Kapoor)
Date: Fri, 1 Dec 2023 13:50:42 +0530
Subject: [PATCH 0/3] arm64: dts: ti: Add Itap Delay Value For High Speed DDR
Message-ID: <20231201082045.790478-1-b-kapoor@ti.com>

This Series adds Itap Delay Value for DDR52 speed mode for eMMC in
J7200 and for DDR50 speed mode for MMCSD in J721s2 and J784s4 SoC.

Rebased to next-20231201

Bhavya Kapoor (3):
  arm64: dts: ti: k3-j7200-main: Add Itap Delay Value For DDR52 speed
    mode
  arm64: dts: ti: k3-j721s2-main: Add Itap Delay Value For DDR50 speed
    mode
  arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed
    mode

 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi  | 1 +
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 1 +
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 1 +
 3 files changed, 3 insertions(+)

-- 
2.34.1



From b-kapoor at ti.com  Fri Dec  1 00:20:43 2023
From: b-kapoor at ti.com (Bhavya Kapoor)
Date: Fri, 1 Dec 2023 13:50:43 +0530
Subject: [PATCH 1/3] arm64: dts: ti: k3-j7200-main: Add Itap Delay Value For DDR52 speed mode
In-Reply-To: <20231201082045.790478-1-b-kapoor@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
Message-ID: <20231201082045.790478-2-b-kapoor@ti.com>

DDR52 speed mode is enabled for eMMC in J7200 but its Itap Delay Value
is not present in the device tree. Thus, add Itap Delay Value for eMMC
High Speed DDR which is DDR52 speed mode for J7200 SoC according to
datasheet for J7200.

[+] Refer to : section 7.9.5.16.1 MMCSD0 - eMMC Interface,  in
	J7200 datasheet
- https://www.ti.com/lit/ds/symlink/dra821u-q1.pdf

Signed-off-by: Bhavya Kapoor <b-kapoor at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 264913f83287..39ce465c8e00 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -647,6 +647,7 @@ main_sdhci0: mmc at 4f80000 {
 		ti,otap-del-sel-hs400 = <0x5>;
 		ti,itap-del-sel-legacy = <0x10>;
 		ti,itap-del-sel-mmc-hs = <0xa>;
+		ti,itap-del-sel-ddr52 = <0x3>;
 		ti,strobe-sel = <0x77>;
 		ti,clkbuf-sel = <0x7>;
 		ti,trm-icp = <0x8>;
-- 
2.34.1



From b-kapoor at ti.com  Fri Dec  1 00:20:45 2023
From: b-kapoor at ti.com (Bhavya Kapoor)
Date: Fri, 1 Dec 2023 13:50:45 +0530
Subject: [PATCH 3/3] arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed mode
In-Reply-To: <20231201082045.790478-1-b-kapoor@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
Message-ID: <20231201082045.790478-4-b-kapoor@ti.com>

DDR50 speed mode is enabled for MMCSD in J784s4 but its Itap Delay
Value is not present in the device tree. Thus, add Itap Delay Value
for MMCSD High Speed DDR which is DDR50 speed mode for J784s4 SoC
according to datasheet for J784s4.

[+] Refer to : section 7.10.5.17.2 MMC1/2 - SD/SDIO Interface, in
	J784s4 datasheet
- https://www.ti.com/lit/ds/symlink/tda4vh-q1.pdf

Signed-off-by: Bhavya Kapoor <b-kapoor at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index d89bcddcfe3d..b9a2358b1459 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -712,6 +712,7 @@ main_sdhci1: mmc at 4fb0000 {
 		ti,itap-del-sel-sd-hs = <0x0>;
 		ti,itap-del-sel-sdr12 = <0x0>;
 		ti,itap-del-sel-sdr25 = <0x0>;
+		ti,itap-del-sel-ddr50 = <0x2>;
 		ti,clkbuf-sel = <0x7>;
 		ti,trm-icp = <0x8>;
 		dma-coherent;
-- 
2.34.1



From b-kapoor at ti.com  Fri Dec  1 00:20:44 2023
From: b-kapoor at ti.com (Bhavya Kapoor)
Date: Fri, 1 Dec 2023 13:50:44 +0530
Subject: [PATCH 2/3] arm64: dts: ti: k3-j721s2-main: Add Itap Delay Value For DDR50 speed mode
In-Reply-To: <20231201082045.790478-1-b-kapoor@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
Message-ID: <20231201082045.790478-3-b-kapoor@ti.com>

DDR50 speed mode is enabled for MMCSD in J721s2 but its Itap Delay
Value is not present in the device tree. Thus, add Itap Delay Value
for MMCSD High Speed DDR which is DDR50 speed mode for J721s2 SoC
according to datasheet for J721s2.

[+] Refer to : section 7.10.5.17.2 MMC1/2 - SD/SDIO Interface,  in
	J721s2 datasheet
- https://www.ti.com/lit/ds/symlink/tda4vl-q1.pdf

Signed-off-by: Bhavya Kapoor <b-kapoor at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index b03731b53a26..e1255956288b 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -766,6 +766,7 @@ main_sdhci1: mmc at 4fb0000 {
 		ti,itap-del-sel-sd-hs = <0x0>;
 		ti,itap-del-sel-sdr12 = <0x0>;
 		ti,itap-del-sel-sdr25 = <0x0>;
+		ti,itap-del-sel-ddr50 = <0x2>;
 		ti,clkbuf-sel = <0x7>;
 		ti,trm-icp = <0x8>;
 		dma-coherent;
-- 
2.34.1



From tzimmermann at suse.de  Fri Dec  1 00:22:05 2023
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Fri, 1 Dec 2023 09:22:05 +0100
Subject: [1/8] drm/plane-helper: Move drm_plane_helper_atomic_check() into
 udl
In-Reply-To: <9a741d8d-a699-4fe8-af59-f90c91014d01@linux.dev>
References: <20231128104723.20622-2-tzimmermann@suse.de>
 <9a741d8d-a699-4fe8-af59-f90c91014d01@linux.dev>
Message-ID: <038bc33b-1bc9-4dbc-bea3-d17a3d37abf0@suse.de>

Hi

Am 01.12.23 um 03:36 schrieb Sui Jingfeng:
> Hi,
> 
> 
> On 2023/11/28 18:45, Thomas Zimmermann wrote:
>> The udl driver is the only caller of drm_plane_helper_atomic_check().
>> Move the function into the driver. No functional changes.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
>> ---
>> ? drivers/gpu/drm/drm_plane_helper.c | 32 ------------------------------
>> ? drivers/gpu/drm/udl/udl_modeset.c? | 19 ++++++++++++++++--
>> ? include/drm/drm_plane_helper.h???? |? 2 --
>> ? 3 files changed, 17 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
>> b/drivers/gpu/drm/drm_plane_helper.c
>> index 5e95089676ff8..7982be4b0306d 100644
>> --- a/drivers/gpu/drm/drm_plane_helper.c
>> +++ b/drivers/gpu/drm/drm_plane_helper.c
>> @@ -279,35 +279,3 @@ void drm_plane_helper_destroy(struct drm_plane 
>> *plane)
>> ????? kfree(plane);
>> ? }
>> ? EXPORT_SYMBOL(drm_plane_helper_destroy);
>> -
>> -/**
>> - * drm_plane_helper_atomic_check() - Helper to check plane atomic-state
>> - * @plane: plane to check
>> - * @state: atomic state object
>> - *
>> - * Provides a default plane-state check handler for planes whose 
>> atomic-state
>> - * scale and positioning are not expected to change since the plane 
>> is always
>> - * a fullscreen scanout buffer.
>> - *
>> - * This is often the case for the primary plane of simple 
>> framebuffers. See
>> - * also drm_crtc_helper_atomic_check() for the respective CRTC-state 
>> check
>> - * helper function.
>> - *
>> - * RETURNS:
>> - * Zero on success, or an errno code otherwise.
>> - */
>> -int drm_plane_helper_atomic_check(struct drm_plane *plane, struct 
>> drm_atomic_state *state)
>> -{
>> -??? struct drm_plane_state *new_plane_state = 
>> drm_atomic_get_new_plane_state(state, plane);
>> -??? struct drm_crtc *new_crtc = new_plane_state->crtc;
>> -??? struct drm_crtc_state *new_crtc_state = NULL;
>> -
>> -??? if (new_crtc)
>> -??????? new_crtc_state = drm_atomic_get_new_crtc_state(state, new_crtc);
>> -
>> -??? return drm_atomic_helper_check_plane_state(new_plane_state, 
>> new_crtc_state,
>> -?????????????????????????? DRM_PLANE_NO_SCALING,
>> -?????????????????????????? DRM_PLANE_NO_SCALING,
>> -?????????????????????????? false, false);
>> -}
>> -EXPORT_SYMBOL(drm_plane_helper_atomic_check);
> 
> 
> Since this function is removed, does the comments of the 
> drm_crtc_helper_atomic_check()
> function (in the drm_crtc_helper.c) need to update as well? I'm ask 
> because I see the
> comments of the drm_crtc_helper_atomic_check() still referencing this 
> function.

Good point. I'll update that comment. Thanks for reviewing.

Best regards
Thomas

> 
> 
>> diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
>> b/drivers/gpu/drm/udl/udl_modeset.c
>> index 40876bcdd79a4..7702359c90c22 100644
>> --- a/drivers/gpu/drm/udl/udl_modeset.c
>> +++ b/drivers/gpu/drm/udl/udl_modeset.c
>> @@ -21,7 +21,6 @@
>> ? #include <drm/drm_gem_framebuffer_helper.h>
>> ? #include <drm/drm_gem_shmem_helper.h>
>> ? #include <drm/drm_modeset_helper_vtables.h>
>> -#include <drm/drm_plane_helper.h>
>> ? #include <drm/drm_probe_helper.h>
>> ? #include <drm/drm_vblank.h>
>> @@ -261,6 +260,22 @@ static const uint64_t udl_primary_plane_fmtmods[] 
>> = {
>> ????? DRM_FORMAT_MOD_INVALID
>> ? };
>> +static int udl_primary_plane_helper_atomic_check(struct drm_plane 
>> *plane,
>> +???????????????????????? struct drm_atomic_state *state)
>> +{
>> +??? struct drm_plane_state *new_plane_state = 
>> drm_atomic_get_new_plane_state(state, plane);
>> +??? struct drm_crtc *new_crtc = new_plane_state->crtc;
>> +??? struct drm_crtc_state *new_crtc_state = NULL;
>> +
>> +??? if (new_crtc)
>> +??????? new_crtc_state = drm_atomic_get_new_crtc_state(state, new_crtc);
>> +
>> +??? return drm_atomic_helper_check_plane_state(new_plane_state, 
>> new_crtc_state,
>> +?????????????????????????? DRM_PLANE_NO_SCALING,
>> +?????????????????????????? DRM_PLANE_NO_SCALING,
>> +?????????????????????????? false, false);
>> +}
>> +
>> ? static void udl_primary_plane_helper_atomic_update(struct drm_plane 
>> *plane,
>> ???????????????????????????? struct drm_atomic_state *state)
>> ? {
>> @@ -296,7 +311,7 @@ static void 
>> udl_primary_plane_helper_atomic_update(struct drm_plane *plane,
>> ? static const struct drm_plane_helper_funcs 
>> udl_primary_plane_helper_funcs = {
>> ????? DRM_GEM_SHADOW_PLANE_HELPER_FUNCS,
>> -??? .atomic_check = drm_plane_helper_atomic_check,
>> +??? .atomic_check = udl_primary_plane_helper_atomic_check,
>> ????? .atomic_update = udl_primary_plane_helper_atomic_update,
>> ? };
>> diff --git a/include/drm/drm_plane_helper.h 
>> b/include/drm/drm_plane_helper.h
>> index 3a574e8cd22f4..75f9c4830564a 100644
>> --- a/include/drm/drm_plane_helper.h
>> +++ b/include/drm/drm_plane_helper.h
>> @@ -26,7 +26,6 @@
>> ? #include <linux/types.h>
>> -struct drm_atomic_state;
>> ? struct drm_crtc;
>> ? struct drm_framebuffer;
>> ? struct drm_modeset_acquire_ctx;
>> @@ -42,7 +41,6 @@ int drm_plane_helper_update_primary(struct drm_plane 
>> *plane, struct drm_crtc *cr
>> ? int drm_plane_helper_disable_primary(struct drm_plane *plane,
>> ?????????????????????? struct drm_modeset_acquire_ctx *ctx);
>> ? void drm_plane_helper_destroy(struct drm_plane *plane);
>> -int drm_plane_helper_atomic_check(struct drm_plane *plane, struct 
>> drm_atomic_state *state);
>> ? /**
>> ?? * DRM_PLANE_NON_ATOMIC_FUNCS - Default plane functions for 
>> non-atomic drivers

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/a9ce84a7/attachment.sig>

From ck.hu at mediatek.com  Fri Dec  1 00:27:13 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Fri, 1 Dec 2023 08:27:13 +0000
Subject: [PATCH] drm/mediatek/dp: Add the HDCP feature for DisplayPort
In-Reply-To: <20231124085346.26602-1-mac.shen@mediatek.com>
References: <20231124085346.26602-1-mac.shen@mediatek.com>
Message-ID: <4c15da9e5563bf6f3813f4b86421271070a286a5.camel@mediatek.com>

Hi, Mac:

On Fri, 2023-11-24 at 16:53 +0800, mac.shen wrote:
> Add tee client application, HDCP 1.x and 2.x authentication for
> DisplayPort
> to support the HDCP feature.
> 
> Signed-off-by: mac.shen <mac.shen at mediatek.com>
> ---

[snip]

> +
> +int tee_hdcp_enable_encrypt(struct mtk_hdcp_info *hdcp_info, bool
> enable, u8 version)
> +{
> +	int rc;
> +	struct dp_tee_private *dp_tee_priv = hdcp_info->g_dp_tee_priv;
> +	struct tci_t *tci = (struct tci_t *)dp_tee_priv->shm->kaddr;
> +	u8 *share_buffer = (u8 *)dp_tee_priv->shm->kaddr;
> +
> +	/* Copy parameters */
> +	memset(tci, 0, TCI_LENGTH);

You don't need to clear this structure. The field you do not write in
this command would not be access in tee. So it's not necessary to clear
the field that does not write in this command.

> +	tci->command_id = CMD_ENABLE_ENCRYPT;
> +	if (enable)
> +		tci->cmd_body.cmd_hdcp_write_val.type =
> TYPE_HDCP_ENABLE_ENCRYPT;
> +	else
> +		tci->cmd_body.cmd_hdcp_write_val.type =
> TYPE_HDCP_DISABLE_ENCRYPT;
> +
> +	/* Set HDCP version supportted by device */
> +	tci->cmd_body.cmd_hdcp_write_val.len = 1;
> +	memset(share_buffer + TCI_LENGTH, version, 1);

It's weird that some data in the range of share_buffer + 0 ~
share_buffer + TCI_LENGTH - 1, and some data is after share_buffer +
TCI_LENGTH. Do not separate them and code would be more clear.

Regards,
CK



> +
> +	rc = dp_tee_op_send(dp_tee_priv, (u8 *)tci, TCI_LENGTH + 1,
> CMD_ENABLE_ENCRYPT);
> +	if (rc != 0) {
> +		TLCERR("tee_op_send failed, error=%x\n", rc);
> +		return rc;
> +	}
> +
> +	return rc;
> +}
> +

From thomas.richard at bootlin.com  Fri Dec  1 00:31:50 2023
From: thomas.richard at bootlin.com (Thomas Richard)
Date: Fri, 1 Dec 2023 09:31:50 +0100
Subject: [PATCH] arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
In-Reply-To: <20231201051449.sijqtozzup4z6exd@ladder>
References: <20231027082852.2922552-1-thomas.richard@bootlin.com>
 <20231201051449.sijqtozzup4z6exd@ladder>
Message-ID: <b9f5e141-c6d4-40a6-b467-a490f1464704@bootlin.com>

On 12/1/23 06:14, Nishanth Menon wrote:
> On 10:28-20231027, Thomas Richard wrote:
>> From: Esteban Blanc <eblanc at baylibre.com>
>>
>> This patch adds support for TPS6594 PMIC family on wakup I2C0 bus.
>> Theses devices provides regulators (bucks and LDOs), but also
>> GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
>> which monitors the SoC error output signal, and a PFSM
>> (Pre-configurable Finite State Machine) which manages the
>> operational modes of the PMIC.
>>
>> Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
>> Signed-off-by: Jai Luthra <j-luthra at ti.com>
>> Signed-off-by: Thomas Richard <thomas.richard at bootlin.com>
>> ---
>>
>> Notes:
>>     This patch was picked from:
>>     https://lore.kernel.org/all/20230810-tps6594-v6-0-2b2e2399e2ef at ti.com/
>>     
>>     I reviewed it, and checked that there is no issue during the boot.
> 
> Thank you, but I am considering a more comprehensive series from Neha[1]
> instead, if you don't mind.

It's ok for me.
Neha told me he sent a new version of the series.
I sent only this patch, as I was able to test only j7200.

Regards,

Thomas



From herve.codina at bootlin.com  Fri Dec  1 00:41:16 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Fri, 1 Dec 2023 09:41:16 +0100
Subject: [PATCH 15/17] soc: fsl: cpm1: qmc: Handle timeslot entries at
 channel start() and stop()
In-Reply-To: <46d0248d-c322-4856-8e9e-6468ac1b7a02@app.fastmail.com>
References: <20231128140818.261541-1-herve.codina@bootlin.com>
	<20231128140818.261541-16-herve.codina@bootlin.com>
	<46d0248d-c322-4856-8e9e-6468ac1b7a02@app.fastmail.com>
Message-ID: <20231201094116.65956f60@bootlin.com>

Hi Arnd,

On Wed, 29 Nov 2023 15:03:02 +0100
"Arnd Bergmann" <arnd at arndb.de> wrote:

> On Tue, Nov 28, 2023, at 15:08, Herve Codina wrote:
> > @@ -272,6 +274,8 @@ int qmc_chan_get_info(struct qmc_chan *chan, struct 
> > qmc_chan_info *info)
> >  	if (ret)
> >  		return ret;
> > 
> > +	spin_lock_irqsave(&chan->ts_lock, flags);
> > +
> >  	info->mode = chan->mode;
> >  	info->rx_fs_rate = tsa_info.rx_fs_rate;
> >  	info->rx_bit_rate = tsa_info.rx_bit_rate;
> > @@ -280,6 +284,8 @@ int qmc_chan_get_info(struct qmc_chan *chan, struct 
> > qmc_chan_info *info)
> >  	info->tx_bit_rate = tsa_info.tx_bit_rate;
> >  	info->nb_rx_ts = hweight64(chan->rx_ts_mask);
> > 
> > +	spin_unlock_irqrestore(&chan->ts_lock, flags);
> > +
> >  	return 0;
> >  }  
> 
> I would normally use spin_lock_irq() instead of spin_lock_irqsave()
> in functions that are only called outside of atomic context.

I would prefer to keep spin_lock_irqsave() here.
This function is part of the API and so, its quite difficult to ensure
that all calls (current and future) will be done outside of an atomic
context.

> 
> > +static int qmc_chan_start_rx(struct qmc_chan *chan);
> > +
> >  int qmc_chan_stop(struct qmc_chan *chan, int direction)
> >  {  
> ... 
> > -static void qmc_chan_start_rx(struct qmc_chan *chan)
> > +static int qmc_setup_chan_trnsync(struct qmc *qmc, struct qmc_chan *chan);
> > +
> > +static int qmc_chan_start_rx(struct qmc_chan *chan)
> >  {  
> 
> Can you reorder the static functions in a way that avoids the
> forward declarations?

Yes, sure.
I will do that in the next iteration.

Thanks for the review,

Best regards,
Herv?


From javierm at redhat.com  Fri Dec  1 00:42:31 2023
From: javierm at redhat.com (Javier Martinez Canillas)
Date: Fri, 01 Dec 2023 09:42:31 +0100
Subject: [PATCH 5/8] drm/solomon: Do not include <drm/drm_plane_helper.h>
In-Reply-To: <20231128104723.20622-6-tzimmermann@suse.de>
References: <20231128104723.20622-1-tzimmermann@suse.de>
 <20231128104723.20622-6-tzimmermann@suse.de>
Message-ID: <871qc6mhzc.fsf@minerva.mail-host-address-is-not-set>

Thomas Zimmermann <tzimmermann at suse.de> writes:

Hello Thomas,

> Remove unnecessary include statements for <drm/drm_plane_helper.h>.
> The file contains helpers for non-atomic code and should not be
> required by most drivers. No functional changes.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
> ---
>  drivers/gpu/drm/solomon/ssd130x.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/solomon/ssd130x.h b/drivers/gpu/drm/solomon/ssd130x.h
> index acf7cedf0c1ab..075c5c3ee75ac 100644
> --- a/drivers/gpu/drm/solomon/ssd130x.h
> +++ b/drivers/gpu/drm/solomon/ssd130x.h
> @@ -17,7 +17,6 @@
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_drv.h>
>  #include <drm/drm_encoder.h>
> -#include <drm/drm_plane_helper.h>
>  
>  #include <linux/regmap.h>
>  
> -- 
> 2.43.0
>

Reviewed-by: Javier Martinez Canillas <javierm at redhat.com>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat



From francesco at dolcini.it  Fri Dec  1 00:48:09 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri, 1 Dec 2023 09:48:09 +0100
Subject: [PATCH] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <20231201064919.5mbmqo5fco7n3rgq@endnote>
References: <20231130231657.12715-1-francesco@dolcini.it>
 <20231201060346.GE5169@atomide.com>
 <20231201064919.5mbmqo5fco7n3rgq@endnote>
Message-ID: <ZWmdyenBpqI1S8HG@francesco-nb.int.toradex.com>

On Fri, Dec 01, 2023 at 12:49:19AM -0600, Nishanth Menon wrote:
> On 08:03-20231201, Tony Lindgren wrote:
> > * Francesco Dolcini <francesco at dolcini.it> [231130 23:17]:
> > > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
> > > is not adequate for embedded systems that use SoCs where it's common to
> > > have a large number of serial ports.
> > > 
> > > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
> > > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
> > > 
> > > This enables using the UART connected Bluetooth device on Verdin AM62
> > > board.
> > 
> > OK makes sense for distro use.
> > 
> > Disabling unused ports leads into port names shifting, which we still can't
> > easily tolerate until we have the DEVNAME:0.0 style addressing available for
> > ports. So for now we still depend CONFIG_SERIAL_8250_NR_UARTS, eventually
> > that too should become just a legacy ISA port array.. Meanwhile:
> > 
> > Reviewed-by: Tony Lindgren <tony at atomide.com>
> 
> I'd prefer to get Arnd's view on the topic as well (I kind of
> recollect some historic discussion which I am not failing to trace
> that there usage model doesn't exceed 4 and aliases could be used to
> map these as required for the platform).

The usage model that triggered this change exceed 4, we >4 uart in
use at the same time.

And the issue is not really "distro use", and I do not think anything
about aliases matter (the BT device is described as a child of the uart
in the DT).

  &main_uart5 {
    bluetooth {
      compatible = "nxp,88w8987-bt";
    };
  };

The change here is required to have basic hardware functionalities
working for kernel development and debugging using the in-tree
defconfig.


> Now 8 or 5 (which seems to be the relevant need) is subjective :(

Correct.

Francesco



From nm at ti.com  Fri Dec  1 00:49:19 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 02:49:19 -0600
Subject: (subset) [PATCH v2 1/2] ARM: dts: ti: keystone: minor whitespace cleanup around '='
In-Reply-To: <20231124095000.58487-1-krzysztof.kozlowski@linaro.org>
References: <20231124095000.58487-1-krzysztof.kozlowski@linaro.org>
Message-ID: <170142054285.921872.5113555651592519775.b4-ty@ti.com>

Hi Krzysztof Kozlowski,

On Fri, 24 Nov 2023 10:49:59 +0100, Krzysztof Kozlowski wrote:
> The DTS code coding style expects exactly one space before and after '='
> sign.
> 
> 

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[2/2] arm64: dts: ti: minor whitespace cleanup around '='
      commit: 31937546bef19d1d5be1157ceb68fb5c23b47f0c

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Fri Dec  1 00:50:53 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 02:50:53 -0600
Subject: [PATCH v3] arm64: boot: dts: ti: k3-am62a-main: Fix GPIO pin count in DT nodes.
In-Reply-To: <20231027065930.1187405-1-n-yadav@ti.com>
References: <20231027065930.1187405-1-n-yadav@ti.com>
Message-ID: <170142057182.921957.13056043269089747285.b4-ty@ti.com>

Hi Nitin Yadav,

On Fri, 27 Oct 2023 12:29:30 +0530, Nitin Yadav wrote:
> Fix number of gpio pins in main_gpio0 & main_gpio1 DT nodes according
> to AM62A7 datasheet[0].
> 
> [0]https://www.ti.com/lit/gpn/am62a3 Section: 6.3.10 GPIO (Page No. 52-55)
> 
> 

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: boot: dts: ti: k3-am62a-main: Fix GPIO pin count in DT nodes.
      commit: 7dc4af358cc382c5d20bd5b726e53ef0f526eb6d

NOTE: fixes sha is 12 chars and not 13 (generates a checkpatch warning - which
you should have run before posting) and the $subject line does'nt need "boot:"
- I have fixed this locally before I applied, but please take care of this in
the future.

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Fri Dec  1 00:51:40 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 02:51:40 -0600
Subject: [PATCH] arm64: dts: ti: k3-am65-main: Fix DSS irq trigger type
In-Reply-To: <20231106-am65-dss-clk-edge-v1-1-4a959fec0e1e@ideasonboard.com>
References: <20231106-am65-dss-clk-edge-v1-1-4a959fec0e1e@ideasonboard.com>
Message-ID: <170142068081.922136.12853419416211333002.b4-ty@ti.com>

Hi Tomi Valkeinen,

On Mon, 06 Nov 2023 11:57:48 +0200, Tomi Valkeinen wrote:
> DSS irq trigger type is set to IRQ_TYPE_EDGE_RISING in the DT file, but
> the TRM says it is level triggered.
> 
> For some reason triggering on rising edge results in double the amount
> of expected interrupts, e.g. for normal page flipping test the number of
> interrupts per second is 2 * fps. It is as if the IRQ triggers on both
> edges. There are no other side effects to this issue than slightly
> increased CPU & power consumption due to the extra interrupt.
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: ti: k3-am65-main: Fix DSS irq trigger type
      commit: b57160859263c083c49482b0d083a586b1517f78

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Fri Dec  1 00:53:11 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 02:53:11 -0600
Subject: [PATCH] arm64: dts: ti: k3-am64: Fix typo in epwm_tbclk node name
In-Reply-To: <20231117162059.88633-1-afd@ti.com>
References: <20231117162059.88633-1-afd@ti.com>
Message-ID: <170142071182.922867.3754666040147828385.b4-ty@ti.com>

Hi Andrew Davis,

On Fri, 17 Nov 2023 10:20:59 -0600, Andrew Davis wrote:
> The node name has @4140 but the reg is at 4130, fix this here.
> 
> 

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: ti: k3-am64: Fix typo in epwm_tbclk node name
      commit: 2897596e3793ce4d58654c56dcc531e853c3ca5a

I did a minor correction in the $subject locally - s/k3-am64/k3-am64-main to
indicate what is affected instead of entire am64 family of SoCs and boards..
please use git log --oneline file in the future to stay consistent..

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From tglx at linutronix.de  Fri Dec  1 00:53:13 2023
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 01 Dec 2023 09:53:13 +0100
Subject: [PATCH 00/21] Initial cleanups for vCPU hotplug
In-Reply-To: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk>
References: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk>
Message-ID: <87y1eexq12.ffs@tglx>

On Tue, Nov 21 2023 at 13:43, Russell King wrote:
> The majority of the other patches come from the vCPU hotplug RFC v3
> series I posted earlier, rebased on Linus' current tip, but with some
> new patches adding arch_cpu_is_hotpluggable() as the remaining
> arch_register_cpu() functions only differ in the setting of the
> hotpluggable member of the CPU device - so let's get generic code
> doing that and provide a way for an architecture to specify whether a
> CPU is hotpluggable.
>
> This patch series has been updated as best I can from the comments on
> its previous 22-patch posting, but there are some things that I have
> been unable to address (some of which go back to James' posting of
> RFC v2 of the vcpu hotplug series) due to lack of co-operation from
> either reviewers responding to my questions, or from the patch author
> providing information. I have now come to the conclusion that this
> information is never going to come, but there is still benefit to
> moving forward with this patch set. I don't expect that anyone will
> even bother to read this far down the email, so blah blah blah blah
> blah blah blah blah blah. I bet no one reads this so I don't know why
> I bother writing crud like this.

You lost your bet. I always read cover letters completely because they
tell a lot. There is correlation between the amount of blah and the
quality of the series :)

Thanks,

        tglx


From nm at ti.com  Fri Dec  1 00:53:26 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 02:53:26 -0600
Subject: [PATCH 1/3] arm64: dts: ti: k3-am642-evm/sk: Mark mcu_gpio_intr as reserved
In-Reply-To: <20231110132508.3137454-1-vigneshr@ti.com>
References: <20231110132508.3137454-1-vigneshr@ti.com>
Message-ID: <170142080163.923229.11181699314375476710.b4-ty@ti.com>

Hi Vignesh Raghavendra,

On Fri, 10 Nov 2023 18:55:06 +0530, Vignesh Raghavendra wrote:
> Similar to MCU GPIO, mark the MCU GPIO router also as reserved for MCU
> domain firmware usage.
> 
> 

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/3] arm64: dts: ti: k3-am642-evm/sk: Mark mcu_gpio_intr as reserved
      commit: 26abae3d840b8b83413c6222725db1104fe4811d
[2/3] arm64: dts: ti: k3-am62p5-sk: Mark mcu gpio and mcu_gpio_intr as reserved
      commit: 1b3014a65adb491ec5a777c988f0dd85094d78bd
[3/3] arm64: dts: ti: k3-am62x-sk-common: Mark mcu gpio and mcu_gpio_intr as reserved
      commit: 5582b1c623a6d62d3aff62c070173c9f1eb8fabd

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From angelogioacchino.delregno at collabora.com  Fri Dec  1 00:53:37 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Fri, 1 Dec 2023 09:53:37 +0100
Subject: [PATCH v2 2/2] mmc: mediatek: extend number of tuning steps
In-Reply-To: <61afefc47b073d63f39972031be6a4dfbd3d45af.camel@mediatek.com>
References: <20231128070127.27442-1-axe.yang@mediatek.com>
 <20231128070127.27442-3-axe.yang@mediatek.com>
 <207c2f89-b1e7-448d-966f-0c403a9f9e8b@collabora.com>
 <ea1a82b07e98fa682140c460048901a9f962be2b.camel@mediatek.com>
 <36ba3f89-2bd0-45f0-8b61-59f5c6691427@collabora.com>
 <61afefc47b073d63f39972031be6a4dfbd3d45af.camel@mediatek.com>
Message-ID: <f14e8db1-5909-4733-99b1-2abe10c4ac7e@collabora.com>

Il 29/11/23 04:16, Axe Yang (??) ha scritto:
> On Tue, 2023-11-28 at 11:20 +0100, AngeloGioacchino Del Regno wrote:
>> Il 28/11/23 10:38, Axe Yang (??) ha scritto:
>>>> On Tue, 2023-11-28 at 09:53 +0100, AngeloGioacchino Del Regno
>>>> wrote:
>>>> Il 28/11/23 08:01, Axe Yang ha scritto:
>>>>> Previously, during the MSDC calibration process, a full clock
>>>>> cycle
>>>>> actually not be covered, which in some cases didn't yield the
>>>>> best
>>>>> results and could cause CRC errors. This problem is
>>>>> particularly
>>>>> evident when MSDC is used as an SDIO host. In fact, MSDC
>>>>> support
>>>>> tuning up to a maximum of 64 steps, but by default, the step
>>>>> number
>>>>> is 32. By increase the tuning step, we are more likely to cover
>>>>> more
>>>>> parts of a clock cycle, and get better calibration result.
>>>>>
>>>>> To illustrate, when tuning 32 steps, if the obtained window has
>>>>> a
>>>>> hole
>>>>> near the middle, like this: 0xffc07ff (hex), then the selected
>>>>> delay
>>>>> will be the 6 (counting from right to left).
>>>>>
>>>>> (32 <- 1)
>>>>> 1111 1111 1100 0000 0000 0111 11(1)1 1111
>>>>>
>>>>> However, if we tune 64 steps, the window obtained may look like
>>>>> this:
>>>>> 0xfffffffffffc07ff. The final selected delay will be 44, which
>>>>> is
>>>>> safer as it is further away from the hole:
>>>>>
>>>>> (64 <- 1)
>>>>> 1111 ... (1)111 1111 1111 1111 1111 1100 0000 0000 0111 1111
>>>>> 1111
>>>>>
>>>>> In this case, delay 6 selected through 32 steps tuning is
>>>>> obviously
>>>>> not optimal, and this delay is closer to the hole, using it
>>>>> would
>>>>> easily cause CRC problems.
>>>>>
>>>>> You will need to configure property "mediatek,tuning-step" in
>>>>> MSDC
>>>>> dts node to 64 to extend the steps.
>>>>>
>>>>
>>>> If we can run 64 tuning steps, why should we run 32?
>>>>
>>>> Why isn't it just better to *always* run 64 tuning steps, on SoCs
>>>> supporting that?
>>>>
>>>> Thanks,
>>>> Angelo
>>>
>>> Hi Angelo,
>>>
>>> That is a good question. The benefit of preserving 32 steps tuning
>>> is
>>> that it can save time in certain scenarios.
>>>
>>> On some platforms, when the delay selected through 64 steps tuning
>>> is
>>> very close to that chosen through 32 steps, we can reduce the
>>> tuning
>>> step from 64 to 32. This can save time sending the tuning block
>>> commands.
>>>
>>> Thus using 32 steps tuning can save kernel boot up time.
>>>
>>> Another case where time can be saved is when accessing the RPMB
>>> partition of eMMC. Each time switch to RPMB partition, there is a
>>> retune action, causing a certain drop in performance. If we are
>>> certain
>>> that the results of 32 steps tuning are usable and we use it, this
>>> can
>>> in a sense also guarantee performance when accessing the RPMB
>>> partition.
>>>
>>
>> Thanks for this explanation! Though, I have some more questions...
>>
>> ...regarding boot up time, how much time are we talking about?
> 
> Luckily, I have a platform at hand that can be used for experiments/
> Below are the results from testing on this platform:
> 
> [    2.431993][T1200180] kworker/2:21: mtk-msdc bootdevice:
> [name:mtk_sd&]Start tuning
> [    2.434950][T1200180] kworker/2:21: mtk-msdc bootdevice:
> [name:mtk_sd&]Tuning finished
> [    2.435957][T1200180] kworker/2:21: mtk-msdc bootdevice:
> [name:mtk_sd&]phase: [map:00000000ffffffc0] [maxlen:26] [final:19]
> [    2.462375][T1200180] kworker/2:21: [name:mmc_core&]mmc0: new HS400
> MMC card at address 0001
> ...
> [    2.519863][T1300069] kworker/3:1: mtk-msdc 11250000.mmc:
> [name:mtk_sd&]Start tuning
> [    2.526271][T1300069] kworker/3:1: mtk-msdc 11250000.mmc:
> [name:mtk_sd&]Tuning finished
> [    2.527288][T1300069] kworker/3:1: mtk-msdc 11250000.mmc:
> [name:mtk_sd&]phase: [map:ffffffffffff003f] [maxlen:48] [final:40]
> [    2.532269][T1300069] kworker/3:1: [name:mmc_core&]mmc2: new ultra
> high speed SDR104 SDIO card at address 0001
> 
> As the kernel log indicates, it took 3 ms for eMMC to tune 32 steps,
> while it took about 7 ms for SDIO to tune 64 steps. I have to admit,
> when it comes to saving boot up time, the benefits of reducing step
> form 64 to 32 are quite minimal. Just as you said, especially when
> async probe is enabled.
> 

That's great to know, and it's *truly* nice information that you can
put into the commit message, as this completes the analysis of this
commit.

Can you mention that in the commit message for v4 of this commit?

"As per measurements taken on MT(xxxx), the tuning phase will take:
  eMMC - 32 steps: ~3ms
         64 steps: xxxx
  SDIO - 32 steps: xxxx
         64 steps: ~7ms

...but while this won't prolong boot times by any meaningful amount
of time, for eMMC, it should still be preferred to use 32 steps tuning
because otherwise we lose performance for RPMB I//O, which requires
re-tuning for each access.
"

>>
>> I'm asking because while now I see - and agree - on using 32-steps
>> tuning
>> on eMMC to guarantee performance during RPMB access, as far as I
>> know,
>> there is no RPMB partition on SD/MicroSD cards (and, of course, SDIO
>> devices).
>>
>> If the boot performance impact isn't big, as in, up to ~100
>> milliseconds is
>> not big at all (especially with async probe!), we can definitely
>> avoid the
>> addition of a devicetree property for 32-steps tuning, hence use a
>> dynamic
>> selection strategy such that:
>>    - On eMMC devices, always perform 32-steps tuning (hence no boot
>> delay)
>>    - On SD cards and SDIO, always perform 64-steps tuning
> 
> eMMC could also potentially have CRC issue if only tune 32-steps,
> albeit with a lower likelihood. The precondition for using 32-steps
> tuning is that it could provide roughly the same valid results as using
> 64-steps tuning. So taking everything into account, controlling the
> tuning step as needed through the use of dts property seems to be a
> more flixible approach.
> 

Yes but since the only performance concern is about eMMC RPMB access,
we could at least make this 64 steps as *default* for SD/SDIO, and
32 steps as default for eMMC.
Device tree would be an override of those default values.

Can we set 64 as default for SD/SDIO, 32 as default for eMMC, and then use
the device tree to override those defaults?

Cheers,
Angelo


From nm at ti.com  Fri Dec  1 00:53:55 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 02:53:55 -0600
Subject: [PATCH v4 0/5] arm64: dts: iot2050: DT fixes, cleanups and enhancements
In-Reply-To: <cover.1699087938.git.jan.kiszka@siemens.com>
References: <cover.1699087938.git.jan.kiszka@siemens.com>
Message-ID: <170142082012.923433.9902299258818951121.b4-ty@ti.com>

Hi Jan Kiszka,

On Sat, 04 Nov 2023 09:52:14 +0100, Jan Kiszka wrote:
> This fixes the lost aliases for the IOT2050 series, fixes mini PCIe card
> hangs, drops an unused device node, brings runtime pinmuxing for the
> Arduino connector via debugfs. Finally, it enables PRU-based Ethernet on
> PG2/M.2 device variants. PG1 devices still need changes to the TI driver
> to enable them as well (work in progress).
> 
> Changes in v4:
>  - fix dtbs_check findings
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/5] arm64: dts: ti: iot2050: Re-add aliases
      commit: ad8edf4ff37ab157f6547da173aedc9f4e5c4015
[2/5] arm64: dts: ti: iot2050: Drop unused ecap0 PWM
      commit: 95fd0767ef961d906f0722b5848276e566a46a4c
[3/5] arm64: dts: ti: iot2050: Definitions for runtime pinmuxing
      commit: e6a53facc8ade138089a64adb4980a1622e7f75f
[4/5] arm64: dts: ti: iot2050: Refactor the m.2 and minipcie power pin
      commit: 6c183a881100144e990f23fbd0f3262e93e8191d
[5/5] arm64: dts: ti: iot2050: Add icssg-prueth nodes for PG2 devices
      commit: 73b4e471cd573e7597cfbd59b882a6cf6408791a

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Fri Dec  1 00:54:12 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 02:54:12 -0600
Subject: [PATCH v2] arm64: dts: ti: k3-am68-sk-base-board: Add alias for MCU CPSW2G
In-Reply-To: <20231115085913.3585740-1-s-vadapalli@ti.com>
References: <20231115085913.3585740-1-s-vadapalli@ti.com>
Message-ID: <170142084478.923540.4908521178307352490.b4-ty@ti.com>

Hi Siddharth Vadapalli,

On Wed, 15 Nov 2023 14:29:13 +0530, Siddharth Vadapalli wrote:
> Add alias for the MCU CPSW2G port to enable Linux to fetch MAC Address
> for the port directly from U-Boot.
> 
> 

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: ti: k3-am68-sk-base-board: Add alias for MCU CPSW2G
      commit: c46172c905f8b64ba490a8a30bf678be82c56eb6

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From xu.yang_2 at nxp.com  Fri Dec  1 00:56:44 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri, 1 Dec 2023 08:56:44 +0000
Subject: [PATCH 2/3] perf: imx_perf: add support for i.MX95 platform
In-Reply-To: <VI1PR04MB4845D4B4CB68648CB3C1081688BDA@VI1PR04MB4845.eurprd04.prod.outlook.com>
References: <20231127073208.1055466-1-xu.yang_2@nxp.com>
 <20231127073208.1055466-2-xu.yang_2@nxp.com>
 <VI1PR04MB4845D4B4CB68648CB3C1081688BDA@VI1PR04MB4845.eurprd04.prod.outlook.com>
Message-ID: <DB7PR04MB514625010B5F864012F7B1EE8C81A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Frank,

> -----Original Message-----
> From: Frank Li <frank.li at nxp.com>
> Sent: Monday, November 27, 2023 11:25 PM
> To: Xu Yang <xu.yang_2 at nxp.com>; will at kernel.org; mark.rutland at arm.com; robh+dt at kernel.org;
> krzysztof.kozlowski+dt at linaro.org; conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de;
> kernel at pengutronix.de; festevam at gmail.com; irogers at google.com; namhyung at kernel.org; acme at kernel.org;
> john.g.garry at oracle.com
> Cc: james.clark at arm.com; mike.leach at linaro.org; leo.yan at linaro.org; peterz at infradead.org; mingo at redhat.com;
> alexander.shishkin at linux.intel.com; linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-perf-
> users at vger.kernel.org; linux-kernel at vger.kernel.org
> Subject: RE: [PATCH 2/3] perf: imx_perf: add support for i.MX95 platform
> 
> 
> 
> > -----Original Message-----
> > From: Xu Yang <xu.yang_2 at nxp.com>
> > Sent: Monday, November 27, 2023 1:32 AM
> > To: Frank Li <frank.li at nxp.com>; will at kernel.org; mark.rutland at arm.com;
> > robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> > conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de;
> > kernel at pengutronix.de; festevam at gmail.com; irogers at google.com;
> > namhyung at kernel.org; acme at kernel.org; john.g.garry at oracle.com
> > Cc: james.clark at arm.com; mike.leach at linaro.org; leo.yan at linaro.org;
> > peterz at infradead.org; mingo at redhat.com;
> > alexander.shishkin at linux.intel.com; linux-arm-kernel at lists.infradead.org;
> > devicetree at vger.kernel.org; linux-perf-users at vger.kernel.org; linux-
> > kernel at vger.kernel.org
> > Subject: [PATCH 2/3] perf: imx_perf: add support for i.MX95 platform
> >
> > i.MX95 has a DDR PMU which is almostly same as i.MX93, it now supports
> > read beat and write beat filter capabilities. This will add support for
> > i.MX95 and enhance the driver to support specific filter handling for it.
> >
> > Usage:
> >
> > For read beat:
> > ~# perf stat -a -I 1000 -e
> > imx9_ddr0/eddrtq_pm_rd_beat_filt2,counter=3,axi_mask=ID_MASK,axi_id
> > =ID/
> > ~# perf stat -a -I 1000 -e
> > imx9_ddr0/eddrtq_pm_rd_beat_filt1,counter=4,axi_mask=ID_MASK,axi_id
> > =ID/
> > ~# perf stat -a -I 1000 -e
> > imx9_ddr0/eddrtq_pm_rd_beat_filt0,counter=5,axi_mask=ID_MASK,axi_id
> > =ID/
> > eg: For edma2: perf stat -a -I 1000 -e
> > imx9_ddr0/eddrtq_pm_rd_beat_filt0,counter=5,axi_mask=0x00f,axi_id=0x0
> > 0c/
> >
> > For write beat:
> > ~# perf stat -a -I 1000 -e
> > imx9_ddr0/eddrtq_pm_wr_beat_filt,counter=2,axi_mask=ID_MASK,axi_id=
> > ID/
> > eg: For edma2: perf stat -a -I 1000 -e
> > imx9_ddr0/eddrtq_pm_wr_beat_filt,counter=2,axi_mask=0x00f,axi_id=0x00
> > c/
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > ---
> >  drivers/perf/fsl_imx9_ddr_perf.c | 187 +++++++++++++++++++++++++++--
> > --
> >  1 file changed, 164 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/perf/fsl_imx9_ddr_perf.c
> > b/drivers/perf/fsl_imx9_ddr_perf.c
> > index 5cf770a1bc31..5e531d94cf3b 100644
> > --- a/drivers/perf/fsl_imx9_ddr_perf.c
> > +++ b/drivers/perf/fsl_imx9_ddr_perf.c
> > @@ -11,14 +11,24 @@
> >  #include <linux/perf_event.h>
> >
> >  /* Performance monitor configuration */
> > -#define PMCFG1  			0x00
> > -#define PMCFG1_RD_TRANS_FILT_EN 	BIT(31)
> > -#define PMCFG1_WR_TRANS_FILT_EN 	BIT(30)
> > -#define PMCFG1_RD_BT_FILT_EN 		BIT(29)
> > -#define PMCFG1_ID_MASK  		GENMASK(17, 0)
> > +#define PMCFG1				0x00
> > +#define MX93_PMCFG1_RD_TRANS_FILT_EN	BIT(31)
> > +#define MX93_PMCFG1_WR_TRANS_FILT_EN	BIT(30)
> > +#define MX93_PMCFG1_RD_BT_FILT_EN	BIT(29)
> > +#define MX93_PMCFG1_ID_MASK		GENMASK(17, 0)
> >
> > -#define PMCFG2  			0x04
> > -#define PMCFG2_ID			GENMASK(17, 0)
> > +#define MX95_PMCFG1_WR_BEAT_FILT_EN	BIT(31)
> > +#define MX95_PMCFG1_RD_BEAT_FILT_EN	BIT(30)
> > +
> > +#define PMCFG2				0x04
> > +#define MX93_PMCFG2_ID			GENMASK(17, 0)
> > +
> > +#define PMCFG3				0x08
> > +#define PMCFG4				0x0C
> > +#define PMCFG5				0x10
> > +#define PMCFG6				0x14
> > +#define MX95_PMCFG_ID_MASK		GENMASK(9, 0)
> > +#define MX95_PMCFG_ID			GENMASK(25, 16)
> >
> >  /* Global control register affects all counters and takes priority over local
> > control registers */
> >  #define PMGC0		0x40
> > @@ -71,12 +81,22 @@ static const struct imx_ddr_devtype_data
> > imx93_devtype_data = {
> >  	.identifier = "imx93",
> >  };
> >
> > +static const struct imx_ddr_devtype_data imx95_devtype_data = {
> > +	.identifier = "imx95",
> > +};
> > +
> >  static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> >  	{.compatible = "fsl,imx93-ddr-pmu", .data = &imx93_devtype_data},
> > +	{.compatible = "fsl,imx95-ddr-pmu", .data = &imx95_devtype_data},
> >  	{ /* sentinel */ }
> >  };
> >  MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids);
> >
> > +static inline bool is_imx93(struct ddr_pmu *pmu)
> > +{
> > +	return pmu->devtype_data == &imx93_devtype_data;
> > +}
> > +
> >  static ssize_t ddr_perf_identifier_show(struct device *dev,
> >  					struct device_attribute *attr,
> >  					char *page)
> > @@ -178,7 +198,6 @@ static struct attribute *ddr_perf_events_attrs[] = {
> >  	IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_6, 70),
> >  	IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_7, 71),
> >  	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_empty, 72),
> > -	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_trans_filt, 73),
> >
> >  	/* counter3 specific events */
> >  	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_0, 64),
> > @@ -190,7 +209,6 @@ static struct attribute *ddr_perf_events_attrs[] = {
> >  	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_6, 70),
> >  	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_7, 71),
> >  	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_full, 72),
> > -	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_trans_filt, 73),
> >
> >  	/* counter4 specific events */
> >  	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_0, 64),
> > @@ -202,7 +220,6 @@ static struct attribute *ddr_perf_events_attrs[] = {
> >  	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_6, 70),
> >  	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_7, 71),
> >  	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq2_rmw, 72),
> > -	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt, 73),
> >
> >  	/* counter5 specific events */
> >  	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_0, 64),
> > @@ -242,6 +259,26 @@ static const struct attribute_group
> > ddr_perf_events_attr_group = {
> >  	.attrs = ddr_perf_events_attrs,
> >  };
> >
> > +static struct attribute *imx93_ddr_perf_events_attrs[] = {
> > +	/* counter2 specific events */
> > +	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_trans_filt, 73),
> > +	/* counter3 specific events */
> > +	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_trans_filt, 73),
> > +	/* counter4 specific events */
> > +	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt, 73),
> > +};
> > +
> > +static struct attribute *imx95_ddr_perf_events_attrs[] = {
> > +	/* counter2 specific events */
> > +	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_beat_filt, 73),
> > +	/* counter3 specific events */
> > +	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt2, 73),
> > +	/* counter4 specific events */
> > +	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt1, 73),
> > +	/* counter5 specific events */
> > +	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt0, 73),
> > +};
> > +
> >  PMU_FORMAT_ATTR(event, "config:0-7");
> >  PMU_FORMAT_ATTR(counter, "config:8-15");
> >  PMU_FORMAT_ATTR(axi_id, "config1:0-17");
> > @@ -361,7 +398,7 @@ static void ddr_perf_counter_local_config(struct
> > ddr_pmu *pmu, int config,
> >  	}
> >  }
> >
> > -static void ddr_perf_monitor_config(struct ddr_pmu *pmu, int cfg, int cfg1,
> > int cfg2)
> > +static void imx93_ddr_perf_monitor_config(struct ddr_pmu *pmu, int cfg,
> > int cfg1, int cfg2)
> >  {
> >  	u32 pmcfg1, pmcfg2;
> >  	int event, counter;
> > @@ -372,30 +409,80 @@ static void ddr_perf_monitor_config(struct
> > ddr_pmu *pmu, int cfg, int cfg1, int
> >  	pmcfg1 = readl_relaxed(pmu->base + PMCFG1);
> >
> >  	if (counter == 2 && event == 73)
> > -		pmcfg1 |= PMCFG1_RD_TRANS_FILT_EN;
> > +		pmcfg1 |= MX93_PMCFG1_RD_TRANS_FILT_EN;
> >  	else if (counter == 2 && event != 73)
> > -		pmcfg1 &= ~PMCFG1_RD_TRANS_FILT_EN;
> > +		pmcfg1 &= ~MX93_PMCFG1_RD_TRANS_FILT_EN;
> >
> >  	if (counter == 3 && event == 73)
> > -		pmcfg1 |= PMCFG1_WR_TRANS_FILT_EN;
> > +		pmcfg1 |= MX93_PMCFG1_WR_TRANS_FILT_EN;
> >  	else if (counter == 3 && event != 73)
> > -		pmcfg1 &= ~PMCFG1_WR_TRANS_FILT_EN;
> > +		pmcfg1 &= ~MX93_PMCFG1_WR_TRANS_FILT_EN;
> >
> >  	if (counter == 4 && event == 73)
> > -		pmcfg1 |= PMCFG1_RD_BT_FILT_EN;
> > +		pmcfg1 |= MX93_PMCFG1_RD_BT_FILT_EN;
> >  	else if (counter == 4 && event != 73)
> > -		pmcfg1 &= ~PMCFG1_RD_BT_FILT_EN;
> > +		pmcfg1 &= ~MX93_PMCFG1_RD_BT_FILT_EN;
> >
> > -	pmcfg1 &= ~FIELD_PREP(PMCFG1_ID_MASK, 0x3FFFF);
> > -	pmcfg1 |= FIELD_PREP(PMCFG1_ID_MASK, cfg2);
> > +	pmcfg1 &= ~FIELD_PREP(MX93_PMCFG1_ID_MASK, 0x3FFFF);
> > +	pmcfg1 |= FIELD_PREP(MX93_PMCFG1_ID_MASK, cfg2);
> >  	writel(pmcfg1, pmu->base + PMCFG1);
> >
> >  	pmcfg2 = readl_relaxed(pmu->base + PMCFG2);
> > -	pmcfg2 &= ~FIELD_PREP(PMCFG2_ID, 0x3FFFF);
> > -	pmcfg2 |= FIELD_PREP(PMCFG2_ID, cfg1);
> > +	pmcfg2 &= ~FIELD_PREP(MX93_PMCFG2_ID, 0x3FFFF);
> > +	pmcfg2 |= FIELD_PREP(MX93_PMCFG2_ID, cfg1);
> 
> Suggest created a sperate rename patch, which prepare for IMX95.
> 
> Frank
> 
> >  	writel(pmcfg2, pmu->base + PMCFG2);
> >  }
> >
> > +static void imx95_ddr_perf_monitor_config(struct ddr_pmu *pmu, int cfg,
> > int cfg1, int cfg2)
> > +{
> > +	u32 pmcfg1, pmcfg, offset = 0;
> > +	int event, counter;
> > +
> > +	event = cfg & 0x000000FF;
> > +	counter = (cfg & 0x0000FF00) >> 8;
> > +
> > +	pmcfg1 = readl_relaxed(pmu->base + PMCFG1);
> > +
> > +	if (counter == 2 && event == 73) {
> > +		pmcfg1 |= MX95_PMCFG1_WR_BEAT_FILT_EN;
> > +		offset = PMCFG3;
> > +	} else if (counter == 2 && event != 73) {
> > +		pmcfg1 &= ~MX95_PMCFG1_WR_BEAT_FILT_EN;
> > +	}
> > +
> > +	if (counter == 3 && event == 73) {
> > +		pmcfg1 |= MX95_PMCFG1_RD_BEAT_FILT_EN;
> > +		offset = PMCFG4;
> > +	} else if (counter == 3 && event != 73) {
> > +		pmcfg1 &= ~MX95_PMCFG1_RD_BEAT_FILT_EN;
> > +	}
> > +
> > +	if (counter == 4 && event == 73) {
> > +		pmcfg1 |= MX95_PMCFG1_RD_BEAT_FILT_EN;
> > +		offset = PMCFG5;
> > +	} else if (counter == 4 && event != 73) {
> > +		pmcfg1 &= ~MX95_PMCFG1_RD_BEAT_FILT_EN;
> > +	}
> > +
> > +	if (counter == 5 && event == 73) {
> > +		pmcfg1 |= MX95_PMCFG1_RD_BEAT_FILT_EN;
> > +		offset = PMCFG6;
> > +	} else if (counter == 5 && event != 73) {
> > +		pmcfg1 &= ~MX95_PMCFG1_RD_BEAT_FILT_EN;
> > +	}
> > +
> > +	writel(pmcfg1, pmu->base + PMCFG1);
> > +
> > +	if (offset) {
> > +		pmcfg = readl_relaxed(pmu->base + offset);
> > +		pmcfg &= ~FIELD_PREP(MX95_PMCFG_ID_MASK, 0x3FF);
> > +		pmcfg |= FIELD_PREP(MX95_PMCFG_ID_MASK, cfg2);
> > +		pmcfg &= ~FIELD_PREP(MX95_PMCFG_ID, 0x3FF);
> 
> It should be reductant.

Okay, will change this.

> 
> > +		pmcfg |= FIELD_PREP(MX95_PMCFG_ID, cfg1);
> > +		writel(pmcfg, pmu->base + offset);
> > +	}
> > +}
> > +
> >  static void ddr_perf_event_update(struct perf_event *event)
> >  {
> >  	struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
> > @@ -479,8 +566,13 @@ static int ddr_perf_event_add(struct perf_event
> > *event, int flags)
> >  	if (flags & PERF_EF_START)
> >  		ddr_perf_event_start(event, flags);
> >
> > -	/* read trans, write trans, read beat */
> > -	ddr_perf_monitor_config(pmu, cfg, cfg1, cfg2);
> > +	if (is_imx93(pmu)) {
> > +		/* read trans, write trans, read beat */
> > +		imx93_ddr_perf_monitor_config(pmu, cfg, cfg1, cfg2);
> > +	} else {
> > +		/* write beat, read beat2, read beat1, read beat */
> > +		imx95_ddr_perf_monitor_config(pmu, cfg, cfg1, cfg2);
> > +	}
> 
> Did you run checkpatch?  no "{" need?, not sure have comments case.

No warning about this when run checkpatch.

> >
> >  	return 0;
> >  }
> > @@ -596,6 +688,49 @@ static int ddr_perf_offline_cpu(unsigned int cpu,
> > struct hlist_node *node)
> >  	return 0;
> >  }
> >
> > +static int ddr_perf_add_events(struct ddr_pmu *pmu)
> > +{
> > +	int i, ret, events;
> > +	struct attribute **attrs;
> > +	struct device *pmu_dev = pmu->pmu.dev;
> > +
> > +	if (is_imx93(pmu)) {
> > +		events = sizeof(imx93_ddr_perf_events_attrs)/sizeof(struct
> > attribute *);
> > +		attrs = imx93_ddr_perf_events_attrs;
> > +	} else {
> > +		events = sizeof(imx95_ddr_perf_events_attrs)/sizeof(struct
> > attribute *);
> > +		attrs = imx95_ddr_perf_events_attrs;
> > +	}
> 
> Can you put "attrs" and "events" into drvdata?

Okay. Will try it.

> 
> > +
> > +	for (i = 0; i < events; i++) {
> > +		ret = sysfs_add_file_to_group(&pmu_dev->kobj, attrs[i],
> > "events");
> > +		if (ret) {
> > +			dev_warn(pmu->dev, "i.MX9 DDR Perf add events
> > failed (%d)\n", ret);
> > +			return ret;
> > +		}
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static void ddr_perf_remove_events(struct ddr_pmu *pmu)
> > +{
> > +	int i, events;
> > +	struct attribute **attrs;
> > +	struct device *pmu_dev = pmu->pmu.dev;
> > +
> > +	if (is_imx93(pmu)) {
> > +		events = sizeof(imx93_ddr_perf_events_attrs)/sizeof(struct
> > attribute *);
> > +		attrs = imx93_ddr_perf_events_attrs;
> > +	} else {
> > +		events = sizeof(imx95_ddr_perf_events_attrs)/sizeof(struct
> > attribute *);
> > +		attrs = imx95_ddr_perf_events_attrs;
> > +	}
> 
> Can you put "attrs" and "events" into drvdata?

Okay.

Thanks,
Xu Yang

> 
> > +
> > +	for (i = 0; i < events; i++)
> > +		sysfs_remove_file_from_group(&pmu_dev->kobj, attrs[i],
> > "events");
> > +}
> > +
> >  static int ddr_perf_probe(struct platform_device *pdev)
> >  {
> >  	struct ddr_pmu *pmu;
> > @@ -666,6 +801,10 @@ static int ddr_perf_probe(struct platform_device
> > *pdev)
> >  	if (ret)
> >  		goto ddr_perf_err;
> >
> > +	ret = ddr_perf_add_events(pmu);
> > +	if (ret)
> > +		dev_warn(&pdev->dev, "i.MX9 DDR Perf filter events are
> > missing\n");
> > +
> >  	return 0;
> >
> >  ddr_perf_err:
> > @@ -683,6 +822,8 @@ static int ddr_perf_remove(struct platform_device
> > *pdev)
> >  {
> >  	struct ddr_pmu *pmu = platform_get_drvdata(pdev);
> >
> > +	ddr_perf_remove_events(pmu);
> > +
> >  	cpuhp_state_remove_instance_nocalls(pmu->cpuhp_state, &pmu-
> > >node);
> >  	cpuhp_remove_multi_state(pmu->cpuhp_state);
> >
> > --
> > 2.34.1



From nm at ti.com  Fri Dec  1 00:59:57 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 02:59:57 -0600
Subject: [PATCH] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <ZWmdyenBpqI1S8HG@francesco-nb.int.toradex.com>
References: <20231130231657.12715-1-francesco@dolcini.it>
 <20231201060346.GE5169@atomide.com>
 <20231201064919.5mbmqo5fco7n3rgq@endnote>
 <ZWmdyenBpqI1S8HG@francesco-nb.int.toradex.com>
Message-ID: <20231201085957.uxvwe3l33n5fxfw4@unrushed>

On 09:48-20231201, Francesco Dolcini wrote:
> On Fri, Dec 01, 2023 at 12:49:19AM -0600, Nishanth Menon wrote:
> > On 08:03-20231201, Tony Lindgren wrote:
> > > * Francesco Dolcini <francesco at dolcini.it> [231130 23:17]:
> > > > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
> > > > is not adequate for embedded systems that use SoCs where it's common to
> > > > have a large number of serial ports.
> > > > 
> > > > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
> > > > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
> > > > 
> > > > This enables using the UART connected Bluetooth device on Verdin AM62
> > > > board.
> > > 
> > > OK makes sense for distro use.
> > > 
> > > Disabling unused ports leads into port names shifting, which we still can't
> > > easily tolerate until we have the DEVNAME:0.0 style addressing available for
> > > ports. So for now we still depend CONFIG_SERIAL_8250_NR_UARTS, eventually
> > > that too should become just a legacy ISA port array.. Meanwhile:
> > > 
> > > Reviewed-by: Tony Lindgren <tony at atomide.com>
> > 
> > I'd prefer to get Arnd's view on the topic as well (I kind of
> > recollect some historic discussion which I am not failing to trace
> > that there usage model doesn't exceed 4 and aliases could be used to
> > map these as required for the platform).
> 
> The usage model that triggered this change exceed 4, we >4 uart in
> use at the same time.
> 
> And the issue is not really "distro use", and I do not think anything
> about aliases matter (the BT device is described as a child of the uart
> in the DT).
> 
>   &main_uart5 {
>     bluetooth {
>       compatible = "nxp,88w8987-bt";
>     };
>   };
> 
> The change here is required to have basic hardware functionalities
> working for kernel development and debugging using the in-tree
> defconfig.
> 
> 
> > Now 8 or 5 (which seems to be the relevant need) is subjective :(
> 

I'd suggest to elaborate on "This enables using the UART connected
Bluetooth device on Verdin AM62 board."
Commit message a bit more to indicate what each of the uarts are used
for - this will help explain that we have a real platform that needs
more than 4 uarts simultaneously. we seem to have survived quite a few
years with count of 4.. so we need to defend why this change now and why
it helps the ecosystem.. just my 2 cents.

Yes, I did indeed look and found the case you are indicating, but for
rest of the community, commit message should indicate why (it will help
if other boards benefit as well, but I personally feel this case, if
elaborated is sufficient enough reason by itself).


-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From nm at ti.com  Fri Dec  1 01:01:11 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 03:01:11 -0600
Subject: [PATCH] arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
In-Reply-To: <b9f5e141-c6d4-40a6-b467-a490f1464704@bootlin.com>
References: <20231027082852.2922552-1-thomas.richard@bootlin.com>
 <20231201051449.sijqtozzup4z6exd@ladder>
 <b9f5e141-c6d4-40a6-b467-a490f1464704@bootlin.com>
Message-ID: <20231201090111.c2nt4careaxlm2cv@mastiff>

On 09:31-20231201, Thomas Richard wrote:
> On 12/1/23 06:14, Nishanth Menon wrote:
> > On 10:28-20231027, Thomas Richard wrote:
> >> From: Esteban Blanc <eblanc at baylibre.com>
> >>
> >> This patch adds support for TPS6594 PMIC family on wakup I2C0 bus.
> >> Theses devices provides regulators (bucks and LDOs), but also
> >> GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
> >> which monitors the SoC error output signal, and a PFSM
> >> (Pre-configurable Finite State Machine) which manages the
> >> operational modes of the PMIC.
> >>
> >> Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
> >> Signed-off-by: Jai Luthra <j-luthra at ti.com>
> >> Signed-off-by: Thomas Richard <thomas.richard at bootlin.com>
> >> ---
> >>
> >> Notes:
> >>     This patch was picked from:
> >>     https://lore.kernel.org/all/20230810-tps6594-v6-0-2b2e2399e2ef at ti.com/
> >>     
> >>     I reviewed it, and checked that there is no issue during the boot.
> > 
> > Thank you, but I am considering a more comprehensive series from Neha[1]
> > instead, if you don't mind.
> 
> It's ok for me.
> Neha told me he sent a new version of the series.
> I sent only this patch, as I was able to test only j7200.

Thanks. will look at Neha's series in my next iteration.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From mripard at kernel.org  Fri Dec  1 01:01:49 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Fri, 1 Dec 2023 10:01:49 +0100
Subject: [PATCH v4 05/45] drm/connector: Check drm_connector_init
 pointers arguments
In-Reply-To: <ZWcB4Ak8QnwkhObR@intel.com>
References: <20231128-kms-hdmi-connector-state-v4-0-c7602158306e@kernel.org>
 <20231128-kms-hdmi-connector-state-v4-5-c7602158306e@kernel.org>
 <87h6l66nth.fsf@intel.com>
 <v3hplco5fdedv6bnc6mwx2zhhw4xxdiekha26ykhc5cmy7ol77@2irk3w4hmabw>
 <ZWXv1Oi_sH0BRWao@intel.com>
 <2mnodqvu2oo674vspiy4gxhglu3it5cq47acx5itnbwevgc4cf@c7h2bvnx3m2n>
 <ZWcB4Ak8QnwkhObR@intel.com>
Message-ID: <2lbs5dkpusow72koxknoautcfb6e2ygq5wledim4i572ya5xlc@stc4koneykhm>

On Wed, Nov 29, 2023 at 11:18:24AM +0200, Ville Syrj?l? wrote:
> On Wed, Nov 29, 2023 at 10:11:26AM +0100, Maxime Ripard wrote:
> > Hi Ville,
> > 
> > On Tue, Nov 28, 2023 at 03:49:08PM +0200, Ville Syrj?l? wrote:
> > > On Tue, Nov 28, 2023 at 02:29:40PM +0100, Maxime Ripard wrote:
> > > > On Tue, Nov 28, 2023 at 02:54:02PM +0200, Jani Nikula wrote:
> > > > > On Tue, 28 Nov 2023, Maxime Ripard <mripard at kernel.org> wrote:
> > > > > > All the drm_connector_init variants take at least a pointer to the
> > > > > > device, connector and hooks implementation.
> > > > > >
> > > > > > However, none of them check their value before dereferencing those
> > > > > > pointers which can lead to a NULL-pointer dereference if the author
> > > > > > isn't careful.
> > > > > 
> > > > > Arguably oopsing on the spot is preferrable when this can't be caused by
> > > > > user input. It's always a mistake that should be caught early during
> > > > > development.
> > > > > 
> > > > > Not everyone checks the return value of drm_connector_init and friends,
> > > > > so those cases will lead to more mysterious bugs later. And probably
> > > > > oopses as well.
> > > > 
> > > > So maybe we can do both then, with something like
> > > > 
> > > > if (WARN_ON(!dev))
> > > >    return -EINVAL
> > > > 
> > > > if (drm_WARN_ON(dev, !connector || !funcs))
> > > >    return -EINVAL;
> > > > 
> > > > I'd still like to check for this, so we can have proper testing, and we
> > > > already check for those pointers in some places (like funcs in
> > > > drm_connector_init), so if we don't cover everything we're inconsistent.
> > > 
> > > People will invariably cargo-cult this kind of stuff absolutely
> > > everywhere and then all your functions will have tons of dead
> > > code to check their arguments.
> > 
> > And that's a bad thing because... ?
> > 
> > Also, are you really saying that checking that your arguments make sense
> > is cargo-cult?
> > 
> > We're already doing it in some parts of KMS, so we have to be
> > consistent, and the answer to "most drivers don't check the error"
> > cannot be "let's just give on error checking then".
> > 
> > > I'd prefer not to go there usually.
> > > 
> > > Should we perhaps start to use the (arguably hideous)
> > >  - void f(struct foo *bar)
> > >  + void f(struct foo bar[static 1])
> > > syntax to tell the compiler we don't accept NULL pointers?
> > > 
> > > Hmm. Apparently that has the same problem as using any
> > > other kind of array syntax in the prototype. That is,
> > > the compiler demands to know the definition of 'struct foo'
> > > even though we're passing in effectively a pointer. Sigh.
> > 
> > Honestly, I don't care as long as it's something we can unit-test to
> > make sure we make it consistent. We can't unit test a complete kernel
> > crash.
> 
> Why do you want to put utterly broken code into a unit test?

Utterly broken code happens. It probably shouldn't, but here we are.

Anyway, you mostly missed the consistent part.

The current state with it is:

  - planes:
    - drm_universal_plane_init warns if funcs->destroy NULL
    - drm_universal_plane_alloc errors out if funcs is NULL
    - drmm_universal_plane_alloc warns and errors out if funcs or funcs->destroy are NULL

  - CRTC:
    - drm_crtc_init_with_planes warns if funcs->destroy NULL
    - drmm_crtc_init_with_planes warns if funcs or funcs->destroy are NULL
    - drmm_crtc_alloc_with_planes warns and errors out if funcs or funcs->destroy are NULL

  - encoder:
    - drm_encoder_init warns if funcs->destroy NULL
    - drmm_encoder_init warns and errors out if funcs or funcs->destroy are NULL
    - drmm_encoder_alloc warns and errors out if funcs or funcs->destroy are NULL

  - connectors:
    - drm_connector_init warns and errors out if funcs or funcs->destroy are NULL
    - drm_connector_init_with_ddc warns and errors out if funcs or funcs->destroy are NULL
    - drmm_connector_init warns and errors out if funcs or funcs->destroy are NULL

I think that just proves that your opinion is just not as clear cut as
you'd like it to be, and it's far from being the policy you claim it is.

Plus, we're not even remotely consistent there, and we're not
documenting that anywhere.

And we have plenty of other examples of static stuff being checked
because it just makes sense. All variants of drm_crtc_init_with_planes
will for example check that the correct plane type is associated to the
primary and cursor planes.

We should fix that.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/bb1e32cd/attachment.sig>

From angelogioacchino.delregno at collabora.com  Fri Dec  1 01:02:05 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Fri, 1 Dec 2023 10:02:05 +0100
Subject: [PATCH v3 2/2] mmc: mediatek: extend number of tuning steps
In-Reply-To: <20231130061513.1296-3-axe.yang@mediatek.com>
References: <20231130061513.1296-1-axe.yang@mediatek.com>
 <20231130061513.1296-3-axe.yang@mediatek.com>
Message-ID: <27313484-10a9-4a2f-93b1-9b5ce04ad9c6@collabora.com>

Il 30/11/23 07:15, Axe Yang ha scritto:
> Previously, during the MSDC calibration process, a full clock cycle
> actually not be covered, which in some cases didn't yield the best
> results and could cause CRC errors. This problem is particularly
> evident when MSDC is used as an SDIO host. In fact, MSDC support
> tuning up to a maximum of 64 steps, but by default, the step number
> is 32. By increase the tuning step, we are more likely to cover more
> parts of a clock cycle, and get better calibration result.
> 
> To illustrate, when tuning 32 steps, if the obtained window has a hole
> near the middle, like this: 0xffc07ff (hex), then the selected delay
> will be the 6 (counting from right to left).
> 
> (32 <- 1)
> 1111 1111 1100 0000 0000 0111 11(1)1 1111
> 
> However, if we tune 64 steps, the window obtained may look like this:
> 0xfffffffffffc07ff. The final selected delay will be 44, which is
> safer as it is further away from the hole:
> 
> (64 <- 1)
> 1111 ... (1)111 1111 1111 1111 1111 1100 0000 0000 0111 1111 1111
> 
> In this case, delay 6 selected through 32 steps tuning is obviously
> not optimal, and this delay is closer to the hole, using it would
> easily cause CRC problems.
> 
> You will need to configure property "mediatek,tuning-step" in MSDC
> dts node to 64 to extend the steps.
> 
> Signed-off-by: Axe Yang <axe.yang at mediatek.com>
> ---
>   drivers/mmc/host/mtk-sd.c | 155 ++++++++++++++++++++++++++------------
>   1 file changed, 107 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 97f7c3d4be6e..4cd306b3b295 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -252,12 +252,16 @@
>   
>   #define MSDC_PAD_TUNE_DATWRDLY	  GENMASK(4, 0)		/* RW */
>   #define MSDC_PAD_TUNE_DATRRDLY	  GENMASK(12, 8)	/* RW */
> +#define MSDC_PAD_TUNE_DATRRDLY2	  GENMASK(12, 8)	/* RW */
>   #define MSDC_PAD_TUNE_CMDRDLY	  GENMASK(20, 16)	/* RW */
> +#define MSDC_PAD_TUNE_CMDRDLY2	  GENMASK(20, 16)	/* RW */
>   #define MSDC_PAD_TUNE_CMDRRDLY	  GENMASK(26, 22)	/* RW */
>   #define MSDC_PAD_TUNE_CLKTDLY	  GENMASK(31, 27)	/* RW */
>   #define MSDC_PAD_TUNE_RXDLYSEL	  BIT(15)   /* RW */
>   #define MSDC_PAD_TUNE_RD_SEL	  BIT(13)   /* RW */
>   #define MSDC_PAD_TUNE_CMD_SEL	  BIT(21)   /* RW */
> +#define MSDC_PAD_TUNE_RD2_SEL	  BIT(13)   /* RW */
> +#define MSDC_PAD_TUNE_CMD2_SEL	  BIT(21)   /* RW */
>   
>   #define PAD_DS_TUNE_DLY_SEL       BIT(0)	  /* RW */
>   #define PAD_DS_TUNE_DLY1	  GENMASK(6, 2)   /* RW */
> @@ -325,7 +329,8 @@
>   
>   #define DEFAULT_DEBOUNCE	(8)	/* 8 cycles CD debounce */
>   
> -#define PAD_DELAY_MAX	32 /* PAD delay cells */
> +#define PAD_DELAY_HALF	32 /* PAD delay cells */
> +#define PAD_DELAY_FULL	64
>   /*--------------------------------------------------------------------------*/
>   /* Descriptor Structure                                                     */
>   /*--------------------------------------------------------------------------*/
> @@ -461,6 +466,7 @@ struct msdc_host {
>   	u32 hs400_ds_dly3;
>   	u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
>   	u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
> +	u32 tuning_step;
>   	bool hs400_cmd_resp_sel_rising;
>   				 /* cmd response sample selection for HS400 */
>   	bool hs400_mode;	/* current eMMC will run at hs400 mode */
> @@ -1615,7 +1621,7 @@ static irqreturn_t msdc_cmdq_irq(struct msdc_host *host, u32 intsts)
>   	}
>   
>   	if (cmd_err || dat_err) {
> -		dev_err(host->dev, "cmd_err = %d, dat_err =%d, intsts = 0x%x",
> +		dev_err(host->dev, "cmd_err = %d, dat_err = %d, intsts = 0x%x",
>   			cmd_err, dat_err, intsts);
>   	}
>   
> @@ -1780,10 +1786,20 @@ static void msdc_init_hw(struct msdc_host *host)
>   				     DATA_K_VALUE_SEL);
>   			sdr_set_bits(host->top_base + EMMC_TOP_CMD,
>   				     PAD_CMD_RD_RXDLY_SEL);
> +			if (host->tuning_step > PAD_DELAY_HALF) {
> +				sdr_set_bits(host->top_base + EMMC_TOP_CONTROL,
> +					     PAD_DAT_RD_RXDLY2_SEL);
> +				sdr_set_bits(host->top_base + EMMC_TOP_CMD,
> +					     PAD_CMD_RD_RXDLY2_SEL);
> +			}
>   		} else {
>   			sdr_set_bits(host->base + tune_reg,
>   				     MSDC_PAD_TUNE_RD_SEL |
>   				     MSDC_PAD_TUNE_CMD_SEL);
> +			if (host->tuning_step > PAD_DELAY_HALF)
> +				sdr_set_bits(host->base + tune_reg + 4,

`tune_reg + 4` is a different register, please define it.

Also, I can't find this in MT8192, MT8195 - as those bits seem to be undefined,
so, which SoCs are actually compatible with this change?


> +					     MSDC_PAD_TUNE_RD2_SEL |
> +					     MSDC_PAD_TUNE_CMD2_SEL);
>   		}
>   	} else {
>   		/* choose clock tune */
> @@ -1925,24 +1941,24 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>   		msdc_set_mclk(host, ios->timing, ios->clock);
>   }
>   
> -static u32 test_delay_bit(u32 delay, u32 bit)
> +static u64 test_delay_bit(u64 delay, u32 bit)
>   {
> -	bit %= PAD_DELAY_MAX;
> -	return delay & BIT(bit);
> +	bit %= PAD_DELAY_FULL;
> +	return delay & BIT_ULL(bit);
>   }
>   
> -static int get_delay_len(u32 delay, u32 start_bit)
> +static int get_delay_len(u64 delay, u32 start_bit)
>   {
>   	int i;
>   
> -	for (i = 0; i < (PAD_DELAY_MAX - start_bit); i++) {
> +	for (i = 0; i < (PAD_DELAY_FULL - start_bit); i++) {
>   		if (test_delay_bit(delay, start_bit + i) == 0)
>   			return i;
>   	}
> -	return PAD_DELAY_MAX - start_bit;
> +	return PAD_DELAY_FULL - start_bit;
>   }
>   
> -static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u32 delay)
> +static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u64 delay)
>   {
>   	int start = 0, len = 0;
>   	int start_final = 0, len_final = 0;
> @@ -1950,28 +1966,28 @@ static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u32 delay)
>   	struct msdc_delay_phase delay_phase = { 0, };
>   
>   	if (delay == 0) {
> -		dev_err(host->dev, "phase error: [map:%x]\n", delay);
> +		dev_err(host->dev, "phase error: [map:%016llx]\n", delay);
>   		delay_phase.final_phase = final_phase;
>   		return delay_phase;
>   	}
>   
> -	while (start < PAD_DELAY_MAX) {
> +	while (start < PAD_DELAY_FULL) {
>   		len = get_delay_len(delay, start);
>   		if (len_final < len) {
>   			start_final = start;
>   			len_final = len;
>   		}
>   		start += len ? len : 1;
> -		if (len >= 12 && start_final < 4)
> +		if (!upper_32_bits(delay) && len >= 12 && start_final < 4)
>   			break;
>   	}
>   
>   	/* The rule is that to find the smallest delay cell */
>   	if (start_final == 0)
> -		final_phase = (start_final + len_final / 3) % PAD_DELAY_MAX;
> +		final_phase = (start_final + len_final / 3) % PAD_DELAY_FULL;
>   	else
> -		final_phase = (start_final + len_final / 2) % PAD_DELAY_MAX;
> -	dev_dbg(host->dev, "phase: [map:%x] [maxlen:%d] [final:%d]\n",
> +		final_phase = (start_final + len_final / 2) % PAD_DELAY_FULL;
> +	dev_dbg(host->dev, "phase: [map:%016llx] [maxlen:%d] [final:%d]\n",
>   		delay, len_final, final_phase);
>   
>   	delay_phase.maxlen = len_final;
> @@ -1984,30 +2000,68 @@ static inline void msdc_set_cmd_delay(struct msdc_host *host, u32 value)
>   {
>   	u32 tune_reg = host->dev_comp->pad_tune_reg;
>   
> -	if (host->top_base)
> -		sdr_set_field(host->top_base + EMMC_TOP_CMD, PAD_CMD_RXDLY,
> -			      value);
> -	else
> -		sdr_set_field(host->base + tune_reg, MSDC_PAD_TUNE_CMDRDLY,
> -			      value);
> +	if (host->top_base) {
> +		if (value < PAD_DELAY_HALF) {
> +			sdr_set_field(host->top_base + EMMC_TOP_CMD, PAD_CMD_RXDLY,
> +				      value);

This goes up to 92 columns, and it's fine, so fits in one line and it's more
readable like that.

I know that's not your fault, but since you're actually touching those lines
it's a good occasion to also do that (not only here) :-)

Cheers,
Angelo


From angelogioacchino.delregno at collabora.com  Fri Dec  1 01:03:28 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Fri, 1 Dec 2023 10:03:28 +0100
Subject: [PATCH 2/3] arm64: dts: mt6358: Drop bogus "regulator-fixed"
 compatible properties
In-Reply-To: <20231130074032.913511-3-wenst@chromium.org>
References: <20231130074032.913511-1-wenst@chromium.org>
 <20231130074032.913511-3-wenst@chromium.org>
Message-ID: <62810181-cfa8-4e2e-b2be-c3c9bf9e3bf9@collabora.com>

Il 30/11/23 08:40, Chen-Yu Tsai ha scritto:
> Whether a regulator under the MT6358 PMIC is a fixed regulator or not is
> derived from the node name. Compatible string properties are not used.
> This causes validation errors after the regulator binding is converted
> to DT schema.
> 
> Drop the bogus "regulator-fixed" compatible properties from the PMIC's
> regulator sub-nodes.
> 
> Fixes: 9f8872221674 ("arm64: dts: mt6358: add PMIC MT6358 related nodes")
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From ck.hu at mediatek.com  Fri Dec  1 00:52:43 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Fri, 1 Dec 2023 08:52:43 +0000
Subject: [PATCH] drm/mediatek/dp: Add the HDCP feature for DisplayPort
In-Reply-To: <20231124085346.26602-1-mac.shen@mediatek.com>
References: <20231124085346.26602-1-mac.shen@mediatek.com>
Message-ID: <cfa0f0daeaaf1d8909ad505cf7e36314d8a5367a.camel@mediatek.com>

Hi, Mac:

On Fri, 2023-11-24 at 16:53 +0800, mac.shen wrote:
> Add tee client application, HDCP 1.x and 2.x authentication for
> DisplayPort
> to support the HDCP feature.
> 
> Signed-off-by: mac.shen <mac.shen at mediatek.com>
> ---

[snip]

> +static int dp_tee_op_send(struct dp_tee_private *dp_tee_priv, u8
> *buf, size_t len, u32 cmd_id)
> +{
> +	int rc;
> +	u8 *temp_buf;
> +	struct tee_ioctl_invoke_arg transceive_args;
> +	struct tee_param command_params[4];
> +	struct tee_shm *shm = dp_tee_priv->shm;
> +
> +	if (len > MAX_COMMAND_SIZE) {
> +		TLCERR("%s: len=%zd exceeds MAX_COMMAND_SIZE supported
> by dp TA\n", __func__, len);
> +		return -EIO;
> +	}
> +
> +	memset(&transceive_args, 0, sizeof(transceive_args));
> +	memset(command_params, 0, sizeof(command_params));
> +	dp_tee_priv->resp_len = 0;
> +
> +	/* Invoke FTPM_OPTEE_TA_SUBMIT_COMMAND function of dp TA */
> +	transceive_args = (struct tee_ioctl_invoke_arg) {
> +		.func = cmd_id,
> +		.session = dp_tee_priv->session,
> +		.num_params = 4,
> +	};
> +
> +	/* Fill FTPM_OPTEE_TA_SUBMIT_COMMAND parameters */
> +	command_params[0] = (struct tee_param) {
> +		.attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT,
> +		.u.memref = {
> +			.shm = shm,
> +			.size = len,
> +			.shm_offs = 0,
> +		},
> +	};
> +
> +	temp_buf = tee_shm_get_va(shm, 0);
> +	if (IS_ERR(temp_buf)) {
> +		TLCERR("%s: tee_shm_get_va failed for transmit\n",
> __func__);
> +		return PTR_ERR(temp_buf);
> +	}
> +
> +	memcpy(temp_buf, buf, len);

temp_buf is equal to buf, so drop temp_buf.

Regards,
CK

> +
> +	command_params[1] = (struct tee_param) {
> +		.attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT,
> +		.u.memref = {
> +			.shm = shm,
> +			.size = MAX_RESPONSE_SIZE,
> +			.shm_offs = MAX_COMMAND_SIZE,
> +		},
> +	};
> +
> +	rc = tee_client_invoke_func(dp_tee_priv->ctx, &transceive_args,
> +				    command_params);
> +	if (rc < 0 || transceive_args.ret != 0) {
> +		TLCERR("%s: invoke error: 0x%x\n", __func__,
> transceive_args.ret);
> +		return (rc < 0) ? rc : transceive_args.ret;
> +	}
> +
> +	temp_buf = tee_shm_get_va(shm,
> command_params[1].u.memref.shm_offs);
> +	if (IS_ERR(temp_buf)) {
> +		TLCERR("%s: tee_shm_get_va failed for receive\n",
> __func__);
> +		return PTR_ERR(temp_buf);
> +	}
> +
> +	/* Sanity checks look good, cache the response */
> +	memcpy(dp_tee_priv->resp_buf, temp_buf, MAX_RESPONSE_SIZE / 2);
> +	dp_tee_priv->resp_len = MAX_RESPONSE_SIZE / 2;
> +
> +	return 0;
> +}
> +

From angelogioacchino.delregno at collabora.com  Fri Dec  1 01:04:16 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Fri, 1 Dec 2023 10:04:16 +0100
Subject: [PATCH 3/3] arm64: dts: mediatek: mt8186: Fix alias prefix for
 ovl_2l0
In-Reply-To: <20231130074032.913511-4-wenst@chromium.org>
References: <20231130074032.913511-1-wenst@chromium.org>
 <20231130074032.913511-4-wenst@chromium.org>
Message-ID: <6a8b3f78-a7f0-47f1-af9b-671ca900ab8e@collabora.com>

Il 30/11/23 08:40, Chen-Yu Tsai ha scritto:
> The alias prefix for ovl_2l (2 layer overlay) is "ovl-2l", not "ovl_2l".
> 
> Fix this.
> 
> Fixes: 7e07d3322de2 ("arm64: dts: mediatek: mt8186: Add display nodes")
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Fri Dec  1 01:04:18 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Fri, 1 Dec 2023 10:04:18 +0100
Subject: [PATCH 1/3] arm64: dts: mt8183: kukui-jacuzzi: Drop bogus anx7625
 panel_flag property
In-Reply-To: <20231130074032.913511-2-wenst@chromium.org>
References: <20231130074032.913511-1-wenst@chromium.org>
 <20231130074032.913511-2-wenst@chromium.org>
Message-ID: <22cc8650-a24e-43c6-bf7a-700becc93a1d@collabora.com>

Il 30/11/23 08:40, Chen-Yu Tsai ha scritto:
> The panel_flag property was used in ChromeOS's downstream kernel. It was
> used to signal whether the downstream device was a fixed panel or
> a connector for an external display.
> 
> This property was dropped in favor of standard OF graph descrptions of
> downstream display panels and bridges.
> 
> Drop the property from the device tree file.
> 
> Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board")
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Fri Dec  1 01:08:40 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Fri, 1 Dec 2023 10:08:40 +0100
Subject: [PATCH] arm64: dts: mediatek: mt8183-kukui-jacuzzi: fix dsi
 unnecessary cells properties
In-Reply-To: <299f569f-c3e7-4807-a141-4bbc06435f03@linaro.org>
References: <20230814071053.5459-1-eugen.hristev@collabora.com>
 <170126437824.153055.10626099314938040381.b4-ty@collabora.com>
 <299f569f-c3e7-4807-a141-4bbc06435f03@linaro.org>
Message-ID: <d4f33b5c-f80d-4808-8e94-5c01eda34f10@collabora.com>

Il 30/11/23 10:01, Krzysztof Kozlowski ha scritto:
> On 29/11/2023 14:27, AngeloGioacchino Del Regno wrote:
>>
>> On Mon, 14 Aug 2023 10:10:53 +0300, Eugen Hristev wrote:
>>> dtbs_check throws a warning at the dsi node:
>>> Warning (avoid_unnecessary_addr_size): /soc/dsi at 14014000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>>>
>>> Other DTS have a panel child node with a reg, so the parent dtsi
>>> must have the address-cells and size-cells, however this specific DT
>>> has the panel removed, but not the cells, hence the warning above.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [1/1] arm64: dts: mediatek: mt8183-kukui-jacuzzi: fix dsi unnecessary cells properties
>>        commit: 4b66a34afe29d991155081b2f1e10482bd00cbaa
>>
> 
>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
>>
> 
> You know, your SoB implies review. Unless you want to say you
> usually apply code without reviewing it...
> 

Yeah, of course it does imply review ... but if there's no actual problem with me
also sending a R-b tag, it's more practical for me, because:
  1. I have mail filters to show me what I reviewed, and
  2. Matthias also can see what I reviewed....

...but I get it that in the specific case of *this* patch, I've sent a R-b just
before applying, so I agree in that this was actually really really useless to do.

so.. whoops :-)

Thanks, btw!
Angelo



From ardb at kernel.org  Fri Dec  1 01:12:48 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Fri, 1 Dec 2023 10:12:48 +0100
Subject: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
In-Reply-To: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
References: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
Message-ID: <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>

On Fri, 1 Dec 2023 at 00:48, Justin Chen <justin.chen at broadcom.com> wrote:
>
> Hello,
>
> Ran into an odd bug that I am unsure what the solution is. Tested a few
> kernels versions and they all fail the same.
>
> FUNCTION_GRAPH_FP_TEST was enabled with 953f534a7ed6 ("ARM: ftrace:
> enable HAVE_FUNCTION_GRAPH_FP_TEST"). This test fails when
> UNWINDER_FRAME_POINTER is enabled. Enable function_graph tracer and you
> should see a failure similar to below.
>
> [   63.817239] ------------[ cut here ]------------
> [   63.822006] WARNING: CPU: 3 PID: 1185 at kernel/trace/fgraph.c:195
> ftrace_return_to_handler+0x228/0x374
> [   63.831645] Bad frame pointer: expected d1e0df40, received d1e0df48
> [   63.831645]   from func packet_setsockopt return to c0b558f4
> [   63.843801] Modules linked in: bdc udc_core
> [   63.848246] CPU: 3 PID: 1185 Comm: udhcpc Not tainted
> 6.1.53-0.1pre-gf0bc552d12f8 #33
> [   63.856209] Hardware name: Broadcom STB (Flattened Device Tree)
> [   63.862227] Backtrace:
> [   63.864761]  dump_backtrace from show_stack+0x20/0x24
> [   63.869982]  r7:c031cd8c r6:00000009 r5:00000013 r4:c11c7fac
> [   63.875736]  show_stack from dump_stack_lvl+0x48/0x54
> [   63.880929]  dump_stack_lvl from dump_stack+0x18/0x1c
> [   63.886111]  r5:000000c3 r4:c11bd92c
> [   63.889764]  dump_stack from __warn+0x88/0x130
> [   63.894339]  __warn from warn_slowpath_fmt+0x140/0x198
> [   63.899631]  r8:d1e0deac r7:c11bd958 r6:c031cd8c r5:c11bd92c r4:00000000
> [   63.906431]  warn_slowpath_fmt from ftrace_return_to_handler+0x228/0x374
> [   63.913294]  r8:c3a8d840 r7:00000002 r6:d1e0df48 r5:c2377a94 r4:c269a400
> [   63.920095]  ftrace_return_to_handler from return_to_handler+0xc/0x18
> [   63.926699]  r8:c0cd8ed0 r7:00000008 r6:c418c500 r5:00000004 r4:00000107
> [   63.933500]  __sys_setsockopt from return_to_handler+0x0/0x18
> [   63.939415]  r8:c02002bc r7:00000126 r6:00000003 r5:00000000 r4:00000004
> [   63.946217]  sys_setsockopt from return_to_handler+0x0/0x18
> [   63.952053] ---[ end trace 0000000000000000 ]---
>
> Sure enough the top of the parent stack is off by 8. (Tested with
> gcc6.3/gcc8.3/gcc12.3)
> 00006dcc <packet_setsockopt>:
>      6dcc:       e1a0c00d        mov     ip, sp
>      6dd0:       e24dd008        sub     sp, sp, #8 <======
>      6dd4:       e92ddff0        push    {r4, r5, r6, r7, r8, r9, sl,
> fp, ip, lr, pc}
>      6dd8:       e24cb00c        sub     fp, ip, #12
>      6ddc:       e24dd06c        sub     sp, sp, #108    @ 0x6c
>      6de0:       e52de004        push    {lr}            @ (str lr, [sp,
> #-4]!)
>      6de4:       ebfffffe        bl      0 <__gnu_mcount_nc>
>
> I'm not quite sure why gcc is putting this extra 8 byte frame (maybe
> some optimization?), but it isn't being accounted for thus the
> FUNCTION_GRAPH_FP_TEST for arm fails. Note that only some functions do
> this. Function graph works with FUNCTION_GRAPH_FP_TEST disabled, so it
> looks the test is hitting false positives.
>

Thanks for the report.

It appears the sub instruction at 0x6dd0 correctly accounts for the
extra 8 bytes, so the frame pointer is valid. So it is our assumption
that there are no gaps between the stack frames is invalid.

Could you try the following change please?

--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -235,8 +235,12 @@
                return;

        if (IS_ENABLED(CONFIG_UNWINDER_FRAME_POINTER)) {
-               /* FP points one word below parent's top of stack */
-               frame_pointer += 4;
+               /*
+                * The top of stack of the parent is recorded in the stack
+                * frame at offset [fp, #-8].
+                */
+               get_kernel_nofault(frame_pointer,
+                                  (unsigned long *)(frame_pointer - 8));
        } else {
                struct stackframe frame = {
                        .fp = frame_pointer,


From francesco at dolcini.it  Fri Dec  1 01:18:54 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri, 1 Dec 2023 10:18:54 +0100
Subject: [PATCH] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <20231201085957.uxvwe3l33n5fxfw4@unrushed>
References: <20231130231657.12715-1-francesco@dolcini.it>
 <20231201060346.GE5169@atomide.com>
 <20231201064919.5mbmqo5fco7n3rgq@endnote>
 <ZWmdyenBpqI1S8HG@francesco-nb.int.toradex.com>
 <20231201085957.uxvwe3l33n5fxfw4@unrushed>
Message-ID: <ZWmk/t7wPJW71emR@francesco-nb.int.toradex.com>

On Fri, Dec 01, 2023 at 02:59:57AM -0600, Nishanth Menon wrote:
> On 09:48-20231201, Francesco Dolcini wrote:
> > On Fri, Dec 01, 2023 at 12:49:19AM -0600, Nishanth Menon wrote:
> > > On 08:03-20231201, Tony Lindgren wrote:
> > > > * Francesco Dolcini <francesco at dolcini.it> [231130 23:17]:
> > > > > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
> > > > > is not adequate for embedded systems that use SoCs where it's common to
> > > > > have a large number of serial ports.
> > > > > 
> > > > > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
> > > > > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
> > > > > 
> > > > > This enables using the UART connected Bluetooth device on Verdin AM62
> > > > > board.
> > > 
> > > I'd prefer to get Arnd's view on the topic as well (I kind of
> > > recollect some historic discussion which I am not failing to trace
> > > that there usage model doesn't exceed 4 and aliases could be used to
> > > map these as required for the platform).
> > 
> > The usage model that triggered this change exceed 4, we >4 uart in
> > use at the same time.
> > 
> > And the issue is not really "distro use", and I do not think anything
> > about aliases matter (the BT device is described as a child of the uart
> > in the DT).
> > 
> >   &main_uart5 {
> >     bluetooth {
> >       compatible = "nxp,88w8987-bt";
> >     };
> >   };
> > 
> > The change here is required to have basic hardware functionalities
> > working for kernel development and debugging using the in-tree
> > defconfig.
> 
> I'd suggest to elaborate on "This enables using the UART connected
> Bluetooth device on Verdin AM62 board."

I can do this, of course, I'll wait for some more feedback in the coming
days as you somehow already suggested.

Francesco



From angelogioacchino.delregno at collabora.com  Fri Dec  1 01:22:54 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Fri, 1 Dec 2023 10:22:54 +0100
Subject: [PATCH 4/4] drm/mediatek: support the DSI0 output on the MT8195
 VDOSYS0
In-Reply-To: <2d1bae2239626cb51977bf0803cec602@kernel.org>
References: <20231123133749.2030661-1-mwalle@kernel.org>
 <20231123133749.2030661-5-mwalle@kernel.org>
 <2d1bae2239626cb51977bf0803cec602@kernel.org>
Message-ID: <8250291c-13ef-4072-92d6-f3d7953d6521@collabora.com>

Il 30/11/23 13:47, Michael Walle ha scritto:
>> With the latest dynamic selection of the output component, we can now
>> support different outputs. Move current output component into the
>> dynamic routes array and add the new DSI0 output.
>>
>> Signed-off-by: Michael Walle <mwalle at kernel.org>
>> ---
>> ?drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++++++-
>> ?1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
>> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> index 2b0c35cacbc6..6fa88976376e 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> @@ -222,7 +222,11 @@ static const unsigned int mt8195_mtk_ddp_main[] = {
>> ???? DDP_COMPONENT_DITHER0,
>> ???? DDP_COMPONENT_DSC0,
>> ???? DDP_COMPONENT_MERGE0,
>> -??? DDP_COMPONENT_DP_INTF0,
> 
> Please disregard this patch (the others are ok). There must gone something
> wrong during my testing. DDP_COMPONENT_MERGE0 won't work with
> DDP_COMPONENT_DSI0. If anyone has more insights, I'm all ears.
> 

I was *convinced* that the MERGE0 SOUT was connected to DSI0!!!

...but you're right, here, and thanks for catching that: there's no way to
get MERGE0 connected to DSI0; if you check in the datasheet for VDO_SEL_IN,
you can get data from MERGE0 only for DSI*1*, not 0.

The only way is to connect DSC_WRAP0 (DDP_COMPONENT_DSC0 in mtk_drm_drv btw)
directly to DSI0 (or dither to dsi0)... unless there is a way to change the
pinmux to invert the pins for DSI0/1?

You could assign the DSI1 controller to the one that is currently DSI0 for you.

That would solve the issue here.

Cheers!
Angelo

> -michael
> 
>> +};
>> +
>> +static const struct mtk_drm_route mt8195_mtk_ddp_main_routes[] = {
>> +??? { 0, DDP_COMPONENT_DP_INTF0 },
>> +??? { 0, DDP_COMPONENT_DSI0 },
>> ?};
>>
>> ?static const unsigned int mt8195_mtk_ddp_ext[] = {
>> @@ -308,6 +312,8 @@ static const struct mtk_mmsys_driver_data 
>> mt8192_mmsys_driver_data = {
>> ?static const struct mtk_mmsys_driver_data mt8195_vdosys0_driver_data = {
>> ???? .main_path = mt8195_mtk_ddp_main,
>> ???? .main_len = ARRAY_SIZE(mt8195_mtk_ddp_main),
>> +??? .conn_routes = mt8195_mtk_ddp_main_routes,
>> +??? .num_conn_routes = ARRAY_SIZE(mt8195_mtk_ddp_main_routes),
>> ???? .mmsys_dev_num = 2,
>> ?};




From j-luthra at ti.com  Fri Dec  1 01:37:51 2023
From: j-luthra at ti.com (Jai Luthra)
Date: Fri, 1 Dec 2023 15:07:51 +0530
Subject: [PATCH v3 4/9] arm64: dts: ti: k3-am625-beagleplay: Add overlays
 for OV5640
In-Reply-To: <20231201061837.rqj7r5dvhjd6l3bj@platter>
References: <20231128-csi_dts-v3-0-0bb11cfa9d43@ti.com>
 <20231128-csi_dts-v3-4-0bb11cfa9d43@ti.com>
 <g6m7mwhifsmsy3c5gvkqfiktw6cjdd3aaz55att325yhacncga@eoklyawsppi4>
 <6e7a0168-5bff-4373-a1c9-e4c1917be0d9@linaro.org>
 <20231201061837.rqj7r5dvhjd6l3bj@platter>
Message-ID: <zdjb6i34ipxdj3jia2t5wh3oabmm7guvxxnr6glrabbrtoj3z3@dzuvpdtm2ntx>

Hi Nishanth,

On Dec 01, 2023 at 00:18:37 -0600, Nishanth Menon wrote:
> On 15:33-20231128, Krzysztof Kozlowski wrote:
> > On 28/11/2023 11:27, Jai Luthra wrote:
> > > Hi,
> > > 
> > > On Nov 28, 2023 at 15:39:46 +0530, Jai Luthra wrote:
> > >> Three different OV5640 modules are supported using the FFC connector on
> > >> BeaglePlay:
> > >> - Digilent PCam 5C
> > >> - ALINX AN5641
> > >> - TEVI-OV5640-*-RPI
> > >>
> > >> The Digilent and ALINX modules supply a 12Mhz XCLK to the sensor, while
> > >> the TEVI module supplies a 24Mhz XCLK, thus requiring a separate
> > >> overlay.
> > > 
> > > Sorry looks like I forgot to pull Andrew's R-By tag from v2 [1], 
> > > hopefully this works:
> > > 
> > > Reviewed-by: Andrew Davis <afd at ti.com>
> > 
> > Sorry, usually not. At least would not work for my scripts, because I do
> > not use b4 parameter to accept tags from other people. I don't know
> > whether the case is here, but I would recommend to wait a day and then
> > resend with short explanation.
> 
> Jai: Please re-send this series. I'd rather not play a guessing game
> here and don't want to digging up all old series to see Reviews you
> should be carrying forward on which patch or for full series etc..
> 

Resent here:
https://lore.kernel.org/all/20231201-csi_dts-v3-0-9f06f31080fe at ti.com/

> -- 
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

-- 
Thanks,
Jai

GPG Fingerprint: 4DE0 D818 E5D5 75E8 D45A AFC5 43DE 91F9 249A 7145


From brgl at bgdev.pl  Fri Dec  1 01:38:55 2023
From: brgl at bgdev.pl (Bartosz Golaszewski)
Date: Fri, 1 Dec 2023 10:38:55 +0100
Subject: [PATCH 1/5] dt-bindings: at24: add ROHM BR24G04
In-Reply-To: <20231127-b4-imx7-var-som-gome-v1-1-f26f88f2d0bc@pengutronix.de>
References: <20231127-b4-imx7-var-som-gome-v1-0-f26f88f2d0bc@pengutronix.de> <20231127-b4-imx7-var-som-gome-v1-1-f26f88f2d0bc@pengutronix.de>
Message-ID: <CAMRc=Md8mDhNJcOZDCx5Ew2DvLfvtbB+WpQtxwt78CxJy4hJHg@mail.gmail.com>

On Mon, Nov 27, 2023 at 10:12?PM Roland Hieber <rhi at pengutronix.de> wrote:
>
> From: Philipp Zabel <p.zabel at pengutronix.de>
>
> Add compatible for ROHM Semiconductor BR24G04 EEPROMs.
>
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Signed-off-by: Roland Hieber <rhi at pengutronix.de>
> ---
>  Documentation/devicetree/bindings/eeprom/at24.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml
> index b6864d0ee81e..1812ef31d5f1 100644
> --- a/Documentation/devicetree/bindings/eeprom/at24.yaml
> +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml
> @@ -123,6 +123,7 @@ properties:
>            - enum:
>                - onnn,cat24c04
>                - onnn,cat24c05
> +              - rohm,br24g04
>            - const: atmel,24c04
>        - items:
>            - const: renesas,r1ex24016
>
> --
> 2.39.2
>

Applied, thanks!

Bart


From brgl at bgdev.pl  Fri Dec  1 01:48:56 2023
From: brgl at bgdev.pl (Bartosz Golaszewski)
Date: Fri, 1 Dec 2023 10:48:56 +0100
Subject: [PATCH v4] gpio: ixp4xx: Handle clock output on pin 14 and 15
In-Reply-To: <20231129-ixp4xx-gpio-clocks-v4-1-345f79058c6b@linaro.org>
References: <20231129-ixp4xx-gpio-clocks-v4-1-345f79058c6b@linaro.org>
Message-ID: <CAMRc=McTBokp_aj6UNuPkOcxNbaQrVMfCGYDAgq_Sz6QTF=dSg@mail.gmail.com>

On Wed, Nov 29, 2023 at 11:37?PM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> This makes it possible to provide basic clock output on pins
> 14 and 15. The clocks are typically used by random electronics,
> not modeled in the device tree, so they just need to be provided
> on request.
>
> In order to not disturb old systems that require that the
> hardware defaults are kept in the clock setting bits, we only
> manipulate these if either device tree property is present.
> Once we know a device needs one of the clocks we can set it
> in the device tree.
>
> Reviewed-by: Andy Shevchenko <andy at kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> The GPIO block on the very legacy IXP4xx GPIO can provide
> a generated clock output on GPIO 14 and GPIO 15. This
> provides a straight-forward solution with a flag for each
> clock output.
>
> More complicated solutions are thinkable, but I deemed them
> overdesigned for this legacy SoC.
> ---

Applied, thanks!

Bart


From m.majewski2 at samsung.com  Fri Dec  1 01:56:17 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:17 +0100
Subject: [PATCH v6 1/9] thermal: exynos: remove an unnecessary field
 description
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <20231201095625.301884-1-m.majewski2@samsung.com>
	<CGME20231201095638eucas1p1124e1028823c48efac89d2bc96cc1762@eucas1p1.samsung.com>
Message-ID: <20231201095625.301884-2-m.majewski2@samsung.com>

It seems that the field has been removed in one of the previous commits,
but the description has been forgotten.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mateusz Majewski <m.majewski2 at samsung.com>
---
 drivers/thermal/samsung/exynos_tmu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 123ec81e1943..187086658e8f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -160,7 +160,6 @@ enum soc_type {
  *	in the positive-TC generator block
  *	0 < reference_voltage <= 31
  * @regulator: pointer to the TMU regulator structure.
- * @reg_conf: pointer to structure to register with core thermal.
  * @tzd: pointer to thermal_zone_device structure
  * @ntrip: number of supported trip points.
  * @enabled: current status of TMU device
-- 
2.42.0



From m.majewski2 at samsung.com  Fri Dec  1 01:56:18 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:18 +0100
Subject: [PATCH v6 2/9] thermal: exynos: drop id field
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <20231201095625.301884-1-m.majewski2@samsung.com>
	<CGME20231201095641eucas1p26fc829eb32caf077c80cbd0ba97cc4b4@eucas1p2.samsung.com>
Message-ID: <20231201095625.301884-3-m.majewski2@samsung.com>

We do not use the value, and only Exynos 7 defines this alias anyway.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mateusz Majewski <m.majewski2 at samsung.com>
---
v1 -> v2: minor commit message rewording.

 drivers/thermal/samsung/exynos_tmu.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 187086658e8f..4ff32245d2a9 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -138,7 +138,6 @@ enum soc_type {
 /**
  * struct exynos_tmu_data : A structure to hold the private data of the TMU
  *			    driver
- * @id: identifier of the one instance of the TMU controller.
  * @base: base address of the single instance of the TMU controller.
  * @base_second: base address of the common registers of the TMU controller.
  * @irq: irq number of the TMU controller.
@@ -172,7 +171,6 @@ enum soc_type {
  * @tmu_clear_irqs: SoC specific TMU interrupts clearing method
  */
 struct exynos_tmu_data {
-	int id;
 	void __iomem *base;
 	void __iomem *base_second;
 	int irq;
@@ -865,10 +863,6 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 	if (!data || !pdev->dev.of_node)
 		return -ENODEV;
 
-	data->id = of_alias_get_id(pdev->dev.of_node, "tmuctrl");
-	if (data->id < 0)
-		data->id = 0;
-
 	data->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
 	if (data->irq <= 0) {
 		dev_err(&pdev->dev, "failed to get IRQ\n");
-- 
2.42.0



From m.majewski2 at samsung.com  Fri Dec  1 01:56:19 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:19 +0100
Subject: [PATCH v6 3/9] thermal: exynos: switch from workqueue-driven
 interrupt handling to threaded interrupts
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <20231201095625.301884-1-m.majewski2@samsung.com>
	<CGME20231201095642eucas1p13b5699805523f9afcf6d4034e1b838b2@eucas1p1.samsung.com>
Message-ID: <20231201095625.301884-4-m.majewski2@samsung.com>

The workqueue boilerplate is mostly one-to-one what the threaded
interrupts do.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mateusz Majewski <m.majewski2 at samsung.com>
---
v1 -> v2: devm_request_threaded_irq call formatting change.

 drivers/thermal/samsung/exynos_tmu.c | 29 +++++++++-------------------
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 4ff32245d2a9..c144592d4584 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -142,7 +142,6 @@ enum soc_type {
  * @base_second: base address of the common registers of the TMU controller.
  * @irq: irq number of the TMU controller.
  * @soc: id of the SOC type.
- * @irq_work: pointer to the irq work structure.
  * @lock: lock to implement synchronization.
  * @clk: pointer to the clock structure.
  * @clk_sec: pointer to the clock structure for accessing the base_second.
@@ -175,7 +174,6 @@ struct exynos_tmu_data {
 	void __iomem *base_second;
 	int irq;
 	enum soc_type soc;
-	struct work_struct irq_work;
 	struct mutex lock;
 	struct clk *clk, *clk_sec, *sclk;
 	u32 cal_type;
@@ -763,10 +761,9 @@ static int exynos7_tmu_read(struct exynos_tmu_data *data)
 		EXYNOS7_TMU_TEMP_MASK;
 }
 
-static void exynos_tmu_work(struct work_struct *work)
+static irqreturn_t exynos_tmu_threaded_irq(int irq, void *id)
 {
-	struct exynos_tmu_data *data = container_of(work,
-			struct exynos_tmu_data, irq_work);
+	struct exynos_tmu_data *data = id;
 
 	thermal_zone_device_update(data->tzd, THERMAL_EVENT_UNSPECIFIED);
 
@@ -778,7 +775,8 @@ static void exynos_tmu_work(struct work_struct *work)
 
 	clk_disable(data->clk);
 	mutex_unlock(&data->lock);
-	enable_irq(data->irq);
+
+	return IRQ_HANDLED;
 }
 
 static void exynos4210_tmu_clear_irqs(struct exynos_tmu_data *data)
@@ -812,16 +810,6 @@ static void exynos4210_tmu_clear_irqs(struct exynos_tmu_data *data)
 	writel(val_irq, data->base + tmu_intclear);
 }
 
-static irqreturn_t exynos_tmu_irq(int irq, void *id)
-{
-	struct exynos_tmu_data *data = id;
-
-	disable_irq_nosync(irq);
-	schedule_work(&data->irq_work);
-
-	return IRQ_HANDLED;
-}
-
 static const struct of_device_id exynos_tmu_match[] = {
 	{
 		.compatible = "samsung,exynos3250-tmu",
@@ -1023,8 +1011,6 @@ static int exynos_tmu_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_sensor;
 
-	INIT_WORK(&data->irq_work, exynos_tmu_work);
-
 	data->clk = devm_clk_get(&pdev->dev, "tmu_apbif");
 	if (IS_ERR(data->clk)) {
 		dev_err(&pdev->dev, "Failed to get clock\n");
@@ -1093,8 +1079,11 @@ static int exynos_tmu_probe(struct platform_device *pdev)
 		goto err_sclk;
 	}
 
-	ret = devm_request_irq(&pdev->dev, data->irq, exynos_tmu_irq,
-		IRQF_TRIGGER_RISING | IRQF_SHARED, dev_name(&pdev->dev), data);
+	ret = devm_request_threaded_irq(&pdev->dev, data->irq, NULL,
+					exynos_tmu_threaded_irq,
+					IRQF_TRIGGER_RISING
+						| IRQF_SHARED | IRQF_ONESHOT,
+					dev_name(&pdev->dev), data);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to request irq: %d\n", data->irq);
 		goto err_sclk;
-- 
2.42.0



From m.majewski2 at samsung.com  Fri Dec  1 01:56:20 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:20 +0100
Subject: [PATCH v6 4/9] thermal: exynos: handle devm_regulator_get_optional
 return value correctly
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <20231201095625.301884-1-m.majewski2@samsung.com>
	<CGME20231201095643eucas1p214ee26937d373118d1e01ccbccbb97b2@eucas1p2.samsung.com>
Message-ID: <20231201095625.301884-5-m.majewski2@samsung.com>

Currently, if regulator is required in the SoC, but
devm_regulator_get_optional fails for whatever reason, the execution
will proceed without propagating the error. Meanwhile there is no reason
to output the error in case of -ENODEV.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mateusz Majewski <m.majewski2 at samsung.com>
---
v3 -> v4: Moved info about not outputting error to the correct commit
  message.

 drivers/thermal/samsung/exynos_tmu.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index c144592d4584..8bcad8a70dc5 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1002,9 +1002,17 @@ static int exynos_tmu_probe(struct platform_device *pdev)
 			return ret;
 		}
 	} else {
-		if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
+		ret = PTR_ERR(data->regulator);
+		switch (ret) {
+		case -ENODEV:
+			break;
+		case -EPROBE_DEFER:
 			return -EPROBE_DEFER;
-		dev_info(&pdev->dev, "Regulator node (vtmu) not found\n");
+		default:
+			dev_err(&pdev->dev, "Failed to get regulator: %d\n",
+				ret);
+			return ret;
+		}
 	}
 
 	ret = exynos_map_dt_data(pdev);
-- 
2.42.0



From m.majewski2 at samsung.com  Fri Dec  1 01:56:21 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:21 +0100
Subject: [PATCH v6 5/9] thermal: exynos: simplify regulator
 (de)initialization
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <20231201095625.301884-1-m.majewski2@samsung.com>
	<CGME20231201095644eucas1p1818772bfce0bbf2109ec5fbf928f603a@eucas1p1.samsung.com>
Message-ID: <20231201095625.301884-6-m.majewski2@samsung.com>

We rewrite the initialization to enable the regulator as part of devm,
which allows us to not handle the struct instance manually.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mateusz Majewski <m.majewski2 at samsung.com>
---
v3 -> v4: Resolved merge conflict and moved info about not outputting
  error to the correct commit message.
v2 -> v3: Fixed error handling of devm_regulator_get_optional to handle
  the case in which the regulator is available, but enabling it fails.
  Also removed the error message, split into two commits and reworded
  the commit message.

 drivers/thermal/samsung/exynos_tmu.c | 49 +++++++++-------------------
 1 file changed, 15 insertions(+), 34 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 8bcad8a70dc5..3bdcbab7466f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -157,7 +157,6 @@ enum soc_type {
  * @reference_voltage: reference voltage of amplifier
  *	in the positive-TC generator block
  *	0 < reference_voltage <= 31
- * @regulator: pointer to the TMU regulator structure.
  * @tzd: pointer to thermal_zone_device structure
  * @ntrip: number of supported trip points.
  * @enabled: current status of TMU device
@@ -183,7 +182,6 @@ struct exynos_tmu_data {
 	u16 temp_error1, temp_error2;
 	u8 gain;
 	u8 reference_voltage;
-	struct regulator *regulator;
 	struct thermal_zone_device *tzd;
 	unsigned int ntrip;
 	bool enabled;
@@ -994,50 +992,40 @@ static int exynos_tmu_probe(struct platform_device *pdev)
 	 * TODO: Add regulator as an SOC feature, so that regulator enable
 	 * is a compulsory call.
 	 */
-	data->regulator = devm_regulator_get_optional(&pdev->dev, "vtmu");
-	if (!IS_ERR(data->regulator)) {
-		ret = regulator_enable(data->regulator);
-		if (ret) {
-			dev_err(&pdev->dev, "failed to enable vtmu\n");
-			return ret;
-		}
-	} else {
-		ret = PTR_ERR(data->regulator);
-		switch (ret) {
-		case -ENODEV:
-			break;
-		case -EPROBE_DEFER:
-			return -EPROBE_DEFER;
-		default:
-			dev_err(&pdev->dev, "Failed to get regulator: %d\n",
-				ret);
-			return ret;
-		}
+	ret = devm_regulator_get_enable_optional(&pdev->dev, "vtmu");
+	switch (ret) {
+	case 0:
+	case -ENODEV:
+		break;
+	case -EPROBE_DEFER:
+		return -EPROBE_DEFER;
+	default:
+		dev_err(&pdev->dev, "Failed to get enabled regulator: %d\n",
+			ret);
+		return ret;
 	}
 
 	ret = exynos_map_dt_data(pdev);
 	if (ret)
-		goto err_sensor;
+		return ret;
 
 	data->clk = devm_clk_get(&pdev->dev, "tmu_apbif");
 	if (IS_ERR(data->clk)) {
 		dev_err(&pdev->dev, "Failed to get clock\n");
-		ret = PTR_ERR(data->clk);
-		goto err_sensor;
+		return PTR_ERR(data->clk);
 	}
 
 	data->clk_sec = devm_clk_get(&pdev->dev, "tmu_triminfo_apbif");
 	if (IS_ERR(data->clk_sec)) {
 		if (data->soc == SOC_ARCH_EXYNOS5420_TRIMINFO) {
 			dev_err(&pdev->dev, "Failed to get triminfo clock\n");
-			ret = PTR_ERR(data->clk_sec);
-			goto err_sensor;
+			return PTR_ERR(data->clk_sec);
 		}
 	} else {
 		ret = clk_prepare(data->clk_sec);
 		if (ret) {
 			dev_err(&pdev->dev, "Failed to get clock\n");
-			goto err_sensor;
+			return ret;
 		}
 	}
 
@@ -1107,10 +1095,6 @@ static int exynos_tmu_probe(struct platform_device *pdev)
 err_clk_sec:
 	if (!IS_ERR(data->clk_sec))
 		clk_unprepare(data->clk_sec);
-err_sensor:
-	if (!IS_ERR(data->regulator))
-		regulator_disable(data->regulator);
-
 	return ret;
 }
 
@@ -1124,9 +1108,6 @@ static void exynos_tmu_remove(struct platform_device *pdev)
 	clk_unprepare(data->clk);
 	if (!IS_ERR(data->clk_sec))
 		clk_unprepare(data->clk_sec);
-
-	if (!IS_ERR(data->regulator))
-		regulator_disable(data->regulator);
 }
 
 #ifdef CONFIG_PM_SLEEP
-- 
2.42.0



From m.majewski2 at samsung.com  Fri Dec  1 01:56:16 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:16 +0100
Subject: [PATCH v6 0/9] Improve Exynos thermal driver
References: <CGME20231201095637eucas1p25e14bd24e05ae61eb12dee18af2a1dc5@eucas1p2.samsung.com>
Message-ID: <20231201095625.301884-1-m.majewski2@samsung.com>

This work improves Exynos thermal driver in various ways. This is
related to the discussion in
https://lore.kernel.org/all/97201878-3bb8-eac5-7fac-a690322ac43a at linaro.org/

The primary issue being fixed is a lockdep warning, which is fixed by
the thermal: exynos: use set_trips patch. We also simplify the code in
general.

Changelog:
 v6:
   - Fixed cleanup after split initialization failure
 v5:
   - Used BIT wherever possible
   - Simplified Exynos 7 code and used the correct register offsets for
     Exynos 7
   - Refactored some common register-setting code
 v4:
   - Resolved merge conflict when applying thermal: exynos: split
     initialization of TMU and the thermal zone
   - Reordered calls done when leaving exynos_tmu_initialize for
     symmetry
 v3:
   - Fixed regulator initialization
   - Fixed formatting of some comments
 v2:
   - Added missing field descriptions
   - Removed an unnecessary field description
   - Removed the commits that made clock management more fine-grained
     (need more discussion), and adapted the new code to manage clocks
   - Removed the devicetree changes (will be uploaded separately),
     changing the recipient list accordingly
   - Improved formatting of the devm_request_threaded_irq call

Mateusz Majewski (9):
  thermal: exynos: remove an unnecessary field description
  thermal: exynos: drop id field
  thermal: exynos: switch from workqueue-driven interrupt handling to
    threaded interrupts
  thermal: exynos: handle devm_regulator_get_optional return value
    correctly
  thermal: exynos: simplify regulator (de)initialization
  thermal: exynos: stop using the threshold mechanism on Exynos 4210
  thermal: exynos: split initialization of TMU and the thermal zone
  thermal: exynos: use BIT wherever possible
  thermal: exynos: use set_trips

 drivers/thermal/samsung/exynos_tmu.c | 547 ++++++++++++++-------------
 1 file changed, 274 insertions(+), 273 deletions(-)

-- 
2.42.0



From m.majewski2 at samsung.com  Fri Dec  1 01:56:24 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:24 +0100
Subject: [PATCH v6 8/9] thermal: exynos: use BIT wherever possible
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <20231201095625.301884-1-m.majewski2@samsung.com>
	<CGME20231201095647eucas1p25f6068381aa2b5f00ed7a8c093fe7a7b@eucas1p2.samsung.com>
Message-ID: <20231201095625.301884-9-m.majewski2@samsung.com>

The original driver did not use that macro and it allows us to make our
intentions slightly clearer.

Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>
Signed-off-by: Mateusz Majewski <m.majewski2 at samsung.com>
---
 drivers/thermal/samsung/exynos_tmu.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 970bada90f2f..ca1b1cec0300 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -388,7 +388,7 @@ static void exynos4412_tmu_set_trip_temp(struct exynos_tmu_data *data,
 
 	if (trip == 3) {
 		con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
-		con |= (1 << EXYNOS_TMU_THERM_TRIP_EN_SHIFT);
+		con |= BIT(EXYNOS_TMU_THERM_TRIP_EN_SHIFT);
 		writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
 	}
 }
@@ -559,16 +559,16 @@ static void exynos4210_tmu_control(struct platform_device *pdev, bool on)
 				continue;
 
 			interrupt_en |=
-				(1 << (EXYNOS_TMU_INTEN_RISE0_SHIFT + i * 4));
+				BIT(EXYNOS_TMU_INTEN_RISE0_SHIFT + i * 4);
 		}
 
 		if (data->soc != SOC_ARCH_EXYNOS4210)
 			interrupt_en |=
 				interrupt_en << EXYNOS_TMU_INTEN_FALL0_SHIFT;
 
-		con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
+		con |= BIT(EXYNOS_TMU_CORE_EN_SHIFT);
 	} else {
-		con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
+		con &= ~BIT(EXYNOS_TMU_CORE_EN_SHIFT);
 	}
 
 	writel(interrupt_en, data->base + EXYNOS_TMU_REG_INTEN);
@@ -590,15 +590,15 @@ static void exynos5433_tmu_control(struct platform_device *pdev, bool on)
 				continue;
 
 			interrupt_en |=
-				(1 << (EXYNOS7_TMU_INTEN_RISE0_SHIFT + i));
+				BIT(EXYNOS7_TMU_INTEN_RISE0_SHIFT + i);
 		}
 
 		interrupt_en |=
 			interrupt_en << EXYNOS_TMU_INTEN_FALL0_SHIFT;
 
-		con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
+		con |= BIT(EXYNOS_TMU_CORE_EN_SHIFT);
 	} else
-		con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
+		con &= ~BIT(EXYNOS_TMU_CORE_EN_SHIFT);
 
 	pd_det_en = on ? EXYNOS5433_PD_DET_EN : 0;
 
@@ -622,17 +622,17 @@ static void exynos7_tmu_control(struct platform_device *pdev, bool on)
 				continue;
 
 			interrupt_en |=
-				(1 << (EXYNOS7_TMU_INTEN_RISE0_SHIFT + i));
+				BIT(EXYNOS7_TMU_INTEN_RISE0_SHIFT + i);
 		}
 
 		interrupt_en |=
 			interrupt_en << EXYNOS_TMU_INTEN_FALL0_SHIFT;
 
-		con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
-		con |= (1 << EXYNOS7_PD_DET_EN_SHIFT);
+		con |= BIT(EXYNOS_TMU_CORE_EN_SHIFT);
+		con |= BIT(EXYNOS7_PD_DET_EN_SHIFT);
 	} else {
-		con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
-		con &= ~(1 << EXYNOS7_PD_DET_EN_SHIFT);
+		con &= ~BIT(EXYNOS_TMU_CORE_EN_SHIFT);
+		con &= ~BIT(EXYNOS7_PD_DET_EN_SHIFT);
 	}
 
 	writel(interrupt_en, data->base + EXYNOS7_TMU_REG_INTEN);
-- 
2.42.0



From m.majewski2 at samsung.com  Fri Dec  1 01:56:22 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:22 +0100
Subject: [PATCH v6 6/9] thermal: exynos: stop using the threshold mechanism
 on Exynos 4210
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <20231201095625.301884-1-m.majewski2@samsung.com>
	<CGME20231201095645eucas1p2fa7ecbd8c5ea09908c304a395f0672cc@eucas1p2.samsung.com>
Message-ID: <20231201095625.301884-7-m.majewski2@samsung.com>

Exynos 4210 supports setting a base threshold value, which is added to
all trip points. This might be useful, but is not really necessary in
our usecase, so we always set it to 0 to simplify the code a bit.

Additionally, this change makes it so that we convert the value to the
calibrated one in a slightly different place. This is more correct
morally, though it does not make any change when single-point
calibration is being used (which is the case currently).

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mateusz Majewski <m.majewski2 at samsung.com>
---
 drivers/thermal/samsung/exynos_tmu.c | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 3bdcbab7466f..d918bf6d5359 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -343,20 +343,7 @@ static void exynos_tmu_control(struct platform_device *pdev, bool on)
 static void exynos4210_tmu_set_trip_temp(struct exynos_tmu_data *data,
 					 int trip_id, u8 temp)
 {
-	struct thermal_trip trip;
-	u8 ref, th_code;
-
-	if (thermal_zone_get_trip(data->tzd, 0, &trip))
-		return;
-
-	ref = trip.temperature / MCELSIUS;
-
-	if (trip_id == 0) {
-		th_code = temp_to_code(data, ref);
-		writeb(th_code, data->base + EXYNOS4210_TMU_REG_THRESHOLD_TEMP);
-	}
-
-	temp -= ref;
+	temp = temp_to_code(data, temp);
 	writeb(temp, data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL0 + trip_id * 4);
 }
 
@@ -371,6 +358,8 @@ static void exynos4210_tmu_initialize(struct platform_device *pdev)
 	struct exynos_tmu_data *data = platform_get_drvdata(pdev);
 
 	sanitize_temp_error(data, readl(data->base + EXYNOS_TMU_REG_TRIMINFO));
+
+	writeb(0, data->base + EXYNOS4210_TMU_REG_THRESHOLD_TEMP);
 }
 
 static void exynos4412_tmu_set_trip_temp(struct exynos_tmu_data *data,
-- 
2.42.0



From m.majewski2 at samsung.com  Fri Dec  1 01:56:23 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:23 +0100
Subject: [PATCH v6 7/9] thermal: exynos: split initialization of TMU and the
 thermal zone
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <20231201095625.301884-1-m.majewski2@samsung.com>
	<CGME20231201095646eucas1p19ea1a0355b799a4f47dd9e55d90ccb68@eucas1p1.samsung.com>
Message-ID: <20231201095625.301884-8-m.majewski2@samsung.com>

This will be needed in the future, as the thermal zone subsystem might
call our callbacks right after devm_thermal_of_zone_register. Currently
we just make get_temp return EAGAIN in such case, but this will not be
possible with state-modifying callbacks, for instance set_trips.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mateusz Majewski <m.majewski2 at samsung.com>
---
v5 -> v6: Fixed cleanup done if exynos_tmu_initialize fails.
v3 -> v4: Reordered calls done while leaving exynos_tmu_initialize so
  that they mirror the calls done while entering this function.
v1 -> v2: We take clocks into account; exynos_tmu_initialize needs both
  clocks, as tmu_initialize might use the base_second registers. However,
  exynos_thermal_zone_configure only needs clk.

 drivers/thermal/samsung/exynos_tmu.c | 104 +++++++++++++++------------
 1 file changed, 60 insertions(+), 44 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index d918bf6d5359..970bada90f2f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -251,25 +251,8 @@ static void sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info)
 static int exynos_tmu_initialize(struct platform_device *pdev)
 {
 	struct exynos_tmu_data *data = platform_get_drvdata(pdev);
-	struct thermal_zone_device *tzd = data->tzd;
-	int num_trips = thermal_zone_get_num_trips(tzd);
 	unsigned int status;
-	int ret = 0, temp;
-
-	ret = thermal_zone_get_crit_temp(tzd, &temp);
-	if (ret && data->soc != SOC_ARCH_EXYNOS5433) { /* FIXME */
-		dev_err(&pdev->dev,
-			"No CRITICAL trip point defined in device tree!\n");
-		goto out;
-	}
-
-	if (num_trips > data->ntrip) {
-		dev_info(&pdev->dev,
-			 "More trip points than supported by this TMU.\n");
-		dev_info(&pdev->dev,
-			 "%d trip points should be configured in polling mode.\n",
-			 num_trips - data->ntrip);
-	}
+	int ret = 0;
 
 	mutex_lock(&data->lock);
 	clk_enable(data->clk);
@@ -280,32 +263,63 @@ static int exynos_tmu_initialize(struct platform_device *pdev)
 	if (!status) {
 		ret = -EBUSY;
 	} else {
-		int i, ntrips =
-			min_t(int, num_trips, data->ntrip);
-
 		data->tmu_initialize(pdev);
-
-		/* Write temperature code for rising and falling threshold */
-		for (i = 0; i < ntrips; i++) {
-
-			struct thermal_trip trip;
-
-			ret = thermal_zone_get_trip(tzd, i, &trip);
-			if (ret)
-				goto err;
-
-			data->tmu_set_trip_temp(data, i, trip.temperature / MCELSIUS);
-			data->tmu_set_trip_hyst(data, i, trip.temperature / MCELSIUS,
-						trip.hysteresis / MCELSIUS);
-		}
-
 		data->tmu_clear_irqs(data);
 	}
+
+	if (!IS_ERR(data->clk_sec))
+		clk_disable(data->clk_sec);
+	clk_disable(data->clk);
+	mutex_unlock(&data->lock);
+
+	return ret;
+}
+
+static int exynos_thermal_zone_configure(struct platform_device *pdev)
+{
+	struct exynos_tmu_data *data = platform_get_drvdata(pdev);
+	struct thermal_zone_device *tzd = data->tzd;
+	int i, num_trips = thermal_zone_get_num_trips(tzd);
+	int ret = 0, temp;
+
+	ret = thermal_zone_get_crit_temp(tzd, &temp);
+
+	if (ret && data->soc != SOC_ARCH_EXYNOS5433) { /* FIXME */
+		dev_err(&pdev->dev,
+			"No CRITICAL trip point defined in device tree!\n");
+		goto out;
+	}
+
+	mutex_lock(&data->lock);
+
+	if (num_trips > data->ntrip) {
+		dev_info(&pdev->dev,
+			 "More trip points than supported by this TMU.\n");
+		dev_info(&pdev->dev,
+			 "%d trip points should be configured in polling mode.\n",
+			 num_trips - data->ntrip);
+	}
+
+	clk_enable(data->clk);
+
+	num_trips = min_t(int, num_trips, data->ntrip);
+
+	/* Write temperature code for rising and falling threshold */
+	for (i = 0; i < num_trips; i++) {
+		struct thermal_trip trip;
+
+		ret = thermal_zone_get_trip(tzd, i, &trip);
+		if (ret)
+			goto err;
+
+		data->tmu_set_trip_temp(data, i, trip.temperature / MCELSIUS);
+		data->tmu_set_trip_hyst(data, i, trip.temperature / MCELSIUS,
+					trip.hysteresis / MCELSIUS);
+	}
+
 err:
 	clk_disable(data->clk);
 	mutex_unlock(&data->lock);
-	if (!IS_ERR(data->clk_sec))
-		clk_disable(data->clk_sec);
 out:
 	return ret;
 }
@@ -1044,10 +1058,12 @@ static int exynos_tmu_probe(struct platform_device *pdev)
 		break;
 	}
 
-	/*
-	 * data->tzd must be registered before calling exynos_tmu_initialize(),
-	 * requesting irq and calling exynos_tmu_control().
-	 */
+	ret = exynos_tmu_initialize(pdev);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to initialize TMU\n");
+		goto err_sclk;
+	}
+
 	data->tzd = devm_thermal_of_zone_register(&pdev->dev, 0, data,
 						  &exynos_sensor_ops);
 	if (IS_ERR(data->tzd)) {
@@ -1058,9 +1074,9 @@ static int exynos_tmu_probe(struct platform_device *pdev)
 		goto err_sclk;
 	}
 
-	ret = exynos_tmu_initialize(pdev);
+	ret = exynos_thermal_zone_configure(pdev);
 	if (ret) {
-		dev_err(&pdev->dev, "Failed to initialize TMU\n");
+		dev_err(&pdev->dev, "Failed to configure the thermal zone\n");
 		goto err_sclk;
 	}
 
-- 
2.42.0



From m.majewski2 at samsung.com  Fri Dec  1 01:56:25 2023
From: m.majewski2 at samsung.com (Mateusz Majewski)
Date: Fri,  1 Dec 2023 10:56:25 +0100
Subject: [PATCH v6 9/9] thermal: exynos: use set_trips
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <20231201095625.301884-1-m.majewski2@samsung.com>
	<CGME20231201095648eucas1p163db6b9b4d0e6fa7b1de40f3649e72a3@eucas1p1.samsung.com>
Message-ID: <20231201095625.301884-10-m.majewski2@samsung.com>

Currently, each trip point defined in the device tree corresponds to a
single hardware interrupt. This commit instead switches to using two
hardware interrupts, whose values are set dynamically using the
set_trips callback. Additionally, the critical temperature threshold is
handled specifically.

Setting interrupts in this way also fixes a long-standing lockdep
warning, which was caused by calling thermal_zone_get_trips with our
lock being held. Do note that this requires TMU initialization to be
split into two parts, as done by the parent commit: parts of the
initialization call into the thermal_zone_device structure and so must
be done after its registration, but the initialization is also
responsible for setting up calibration, which must be done before
thermal_zone_device registration, which will call set_trips for the
first time; if the calibration is not done in time, the interrupt values
will be silently wrong!

Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>
Signed-off-by: Mateusz Majewski <m.majewski2 at samsung.com>
---
v4 -> v5: Simplified Exynos 7 code, used the correct register offsets
  for Exynos 7 and refactored some common register-setting code.
v2 -> v3: Fixed formatting of some comments.
v1 -> v2: We take clocks into account; anything that sets temperature
  thresholds needs clk.

 drivers/thermal/samsung/exynos_tmu.c | 393 ++++++++++++++-------------
 1 file changed, 209 insertions(+), 184 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index ca1b1cec0300..6482513bfe66 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -158,10 +158,12 @@ enum soc_type {
  *	in the positive-TC generator block
  *	0 < reference_voltage <= 31
  * @tzd: pointer to thermal_zone_device structure
- * @ntrip: number of supported trip points.
  * @enabled: current status of TMU device
- * @tmu_set_trip_temp: SoC specific method to set trip (rising threshold)
- * @tmu_set_trip_hyst: SoC specific to set hysteresis (falling threshold)
+ * @tmu_set_low_temp: SoC specific method to set trip (falling threshold)
+ * @tmu_set_high_temp: SoC specific method to set trip (rising threshold)
+ * @tmu_set_crit_temp: SoC specific method to set critical temperature
+ * @tmu_disable_low: SoC specific method to disable an interrupt (falling threshold)
+ * @tmu_disable_high: SoC specific method to disable an interrupt (rising threshold)
  * @tmu_initialize: SoC specific TMU initialization method
  * @tmu_control: SoC specific TMU control method
  * @tmu_read: SoC specific TMU temperature read method
@@ -183,13 +185,13 @@ struct exynos_tmu_data {
 	u8 gain;
 	u8 reference_voltage;
 	struct thermal_zone_device *tzd;
-	unsigned int ntrip;
 	bool enabled;
 
-	void (*tmu_set_trip_temp)(struct exynos_tmu_data *data, int trip,
-				 u8 temp);
-	void (*tmu_set_trip_hyst)(struct exynos_tmu_data *data, int trip,
-				 u8 temp, u8 hyst);
+	void (*tmu_set_low_temp)(struct exynos_tmu_data *data, u8 temp);
+	void (*tmu_set_high_temp)(struct exynos_tmu_data *data, u8 temp);
+	void (*tmu_set_crit_temp)(struct exynos_tmu_data *data, u8 temp);
+	void (*tmu_disable_low)(struct exynos_tmu_data *data);
+	void (*tmu_disable_high)(struct exynos_tmu_data *data);
 	void (*tmu_initialize)(struct platform_device *pdev);
 	void (*tmu_control)(struct platform_device *pdev, bool on);
 	int (*tmu_read)(struct exynos_tmu_data *data);
@@ -279,49 +281,28 @@ static int exynos_thermal_zone_configure(struct platform_device *pdev)
 {
 	struct exynos_tmu_data *data = platform_get_drvdata(pdev);
 	struct thermal_zone_device *tzd = data->tzd;
-	int i, num_trips = thermal_zone_get_num_trips(tzd);
-	int ret = 0, temp;
+	int ret, temp;
 
 	ret = thermal_zone_get_crit_temp(tzd, &temp);
+	if (ret) {
+		/* FIXME: Remove this special case */
+		if (data->soc == SOC_ARCH_EXYNOS5433)
+			return 0;
 
-	if (ret && data->soc != SOC_ARCH_EXYNOS5433) { /* FIXME */
 		dev_err(&pdev->dev,
 			"No CRITICAL trip point defined in device tree!\n");
-		goto out;
+		return ret;
 	}
 
 	mutex_lock(&data->lock);
-
-	if (num_trips > data->ntrip) {
-		dev_info(&pdev->dev,
-			 "More trip points than supported by this TMU.\n");
-		dev_info(&pdev->dev,
-			 "%d trip points should be configured in polling mode.\n",
-			 num_trips - data->ntrip);
-	}
-
 	clk_enable(data->clk);
 
-	num_trips = min_t(int, num_trips, data->ntrip);
+	data->tmu_set_crit_temp(data, temp / MCELSIUS);
 
-	/* Write temperature code for rising and falling threshold */
-	for (i = 0; i < num_trips; i++) {
-		struct thermal_trip trip;
-
-		ret = thermal_zone_get_trip(tzd, i, &trip);
-		if (ret)
-			goto err;
-
-		data->tmu_set_trip_temp(data, i, trip.temperature / MCELSIUS);
-		data->tmu_set_trip_hyst(data, i, trip.temperature / MCELSIUS,
-					trip.hysteresis / MCELSIUS);
-	}
-
-err:
 	clk_disable(data->clk);
 	mutex_unlock(&data->lock);
-out:
-	return ret;
+
+	return 0;
 }
 
 static u32 get_con_reg(struct exynos_tmu_data *data, u32 con)
@@ -354,17 +335,74 @@ static void exynos_tmu_control(struct platform_device *pdev, bool on)
 	mutex_unlock(&data->lock);
 }
 
-static void exynos4210_tmu_set_trip_temp(struct exynos_tmu_data *data,
-					 int trip_id, u8 temp)
+static void exynos_tmu_update_bit(struct exynos_tmu_data *data, int reg_off,
+				  int bit_off, bool enable)
 {
-	temp = temp_to_code(data, temp);
-	writeb(temp, data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL0 + trip_id * 4);
+	u32 interrupt_en;
+
+	interrupt_en = readl(data->base + reg_off);
+	if (enable)
+		interrupt_en |= BIT(bit_off);
+	else
+		interrupt_en &= ~BIT(bit_off);
+	writel(interrupt_en, data->base + reg_off);
 }
 
-/* failing thresholds are not supported on Exynos4210 */
-static void exynos4210_tmu_set_trip_hyst(struct exynos_tmu_data *data,
-					 int trip, u8 temp, u8 hyst)
+static void exynos_tmu_update_temp(struct exynos_tmu_data *data, int reg_off,
+				   int bit_off, u8 temp)
 {
+	u16 tmu_temp_mask;
+	u32 th;
+
+	tmu_temp_mask =
+		(data->soc == SOC_ARCH_EXYNOS7) ? EXYNOS7_TMU_TEMP_MASK
+						: EXYNOS_TMU_TEMP_MASK;
+
+	th = readl(data->base + reg_off);
+	th &= ~(tmu_temp_mask << bit_off);
+	th |= temp_to_code(data, temp) << bit_off;
+	writel(th, data->base + reg_off);
+}
+
+static void exynos4210_tmu_set_low_temp(struct exynos_tmu_data *data, u8 temp)
+{
+	/*
+	 * Failing thresholds are not supported on Exynos 4210.
+	 * We use polling instead.
+	 */
+}
+
+static void exynos4210_tmu_set_high_temp(struct exynos_tmu_data *data, u8 temp)
+{
+	temp = temp_to_code(data, temp);
+	writeb(temp, data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL0 + 4);
+	exynos_tmu_update_bit(data, EXYNOS_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_RISE0_SHIFT + 4, true);
+}
+
+static void exynos4210_tmu_disable_low(struct exynos_tmu_data *data)
+{
+	/* Again, this is handled by polling. */
+}
+
+static void exynos4210_tmu_disable_high(struct exynos_tmu_data *data)
+{
+	exynos_tmu_update_bit(data, EXYNOS_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_RISE0_SHIFT + 4, false);
+}
+
+static void exynos4210_tmu_set_crit_temp(struct exynos_tmu_data *data, u8 temp)
+{
+	/*
+	 * Hardware critical temperature handling is not supported on Exynos 4210.
+	 * We still set the critical temperature threshold, but this is only to
+	 * make sure it is handled as soon as possible. It is just a normal interrupt.
+	 */
+
+	temp = temp_to_code(data, temp);
+	writeb(temp, data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL0 + 12);
+	exynos_tmu_update_bit(data, EXYNOS_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_RISE0_SHIFT + 12, true);
 }
 
 static void exynos4210_tmu_initialize(struct platform_device *pdev)
@@ -376,33 +414,31 @@ static void exynos4210_tmu_initialize(struct platform_device *pdev)
 	writeb(0, data->base + EXYNOS4210_TMU_REG_THRESHOLD_TEMP);
 }
 
-static void exynos4412_tmu_set_trip_temp(struct exynos_tmu_data *data,
-					 int trip, u8 temp)
+static void exynos4412_tmu_set_low_temp(struct exynos_tmu_data *data, u8 temp)
 {
-	u32 th, con;
-
-	th = readl(data->base + EXYNOS_THD_TEMP_RISE);
-	th &= ~(0xff << 8 * trip);
-	th |= temp_to_code(data, temp) << 8 * trip;
-	writel(th, data->base + EXYNOS_THD_TEMP_RISE);
-
-	if (trip == 3) {
-		con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
-		con |= BIT(EXYNOS_TMU_THERM_TRIP_EN_SHIFT);
-		writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
-	}
+	exynos_tmu_update_temp(data, EXYNOS_THD_TEMP_FALL, 0, temp);
+	exynos_tmu_update_bit(data, EXYNOS_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_FALL0_SHIFT, true);
 }
 
-static void exynos4412_tmu_set_trip_hyst(struct exynos_tmu_data *data,
-					 int trip, u8 temp, u8 hyst)
+static void exynos4412_tmu_set_high_temp(struct exynos_tmu_data *data, u8 temp)
 {
-	u32 th;
+	exynos_tmu_update_temp(data, EXYNOS_THD_TEMP_RISE, 8, temp);
+	exynos_tmu_update_bit(data, EXYNOS_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_RISE0_SHIFT + 4, true);
+}
 
-	th = readl(data->base + EXYNOS_THD_TEMP_FALL);
-	th &= ~(0xff << 8 * trip);
-	if (hyst)
-		th |= temp_to_code(data, temp - hyst) << 8 * trip;
-	writel(th, data->base + EXYNOS_THD_TEMP_FALL);
+static void exynos4412_tmu_disable_low(struct exynos_tmu_data *data)
+{
+	exynos_tmu_update_bit(data, EXYNOS_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_FALL0_SHIFT, false);
+}
+
+static void exynos4412_tmu_set_crit_temp(struct exynos_tmu_data *data, u8 temp)
+{
+	exynos_tmu_update_temp(data, EXYNOS_THD_TEMP_RISE, 24, temp);
+	exynos_tmu_update_bit(data, EXYNOS_TMU_REG_CONTROL,
+			      EXYNOS_TMU_THERM_TRIP_EN_SHIFT, true);
 }
 
 static void exynos4412_tmu_initialize(struct platform_device *pdev)
@@ -432,44 +468,39 @@ static void exynos4412_tmu_initialize(struct platform_device *pdev)
 	sanitize_temp_error(data, trim_info);
 }
 
-static void exynos5433_tmu_set_trip_temp(struct exynos_tmu_data *data,
-					 int trip, u8 temp)
+static void exynos5433_tmu_set_low_temp(struct exynos_tmu_data *data, u8 temp)
 {
-	unsigned int reg_off, j;
-	u32 th;
-
-	if (trip > 3) {
-		reg_off = EXYNOS5433_THD_TEMP_RISE7_4;
-		j = trip - 4;
-	} else {
-		reg_off = EXYNOS5433_THD_TEMP_RISE3_0;
-		j = trip;
-	}
-
-	th = readl(data->base + reg_off);
-	th &= ~(0xff << j * 8);
-	th |= (temp_to_code(data, temp) << j * 8);
-	writel(th, data->base + reg_off);
+	exynos_tmu_update_temp(data, EXYNOS5433_THD_TEMP_FALL3_0, 0, temp);
+	exynos_tmu_update_bit(data, EXYNOS5433_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_FALL0_SHIFT, true);
 }
 
-static void exynos5433_tmu_set_trip_hyst(struct exynos_tmu_data *data,
-					 int trip, u8 temp, u8 hyst)
+static void exynos5433_tmu_set_high_temp(struct exynos_tmu_data *data, u8 temp)
 {
-	unsigned int reg_off, j;
-	u32 th;
+	exynos_tmu_update_temp(data, EXYNOS5433_THD_TEMP_RISE3_0, 8, temp);
+	exynos_tmu_update_bit(data, EXYNOS5433_TMU_REG_INTEN,
+			      EXYNOS7_TMU_INTEN_RISE0_SHIFT + 1, true);
+}
 
-	if (trip > 3) {
-		reg_off = EXYNOS5433_THD_TEMP_FALL7_4;
-		j = trip - 4;
-	} else {
-		reg_off = EXYNOS5433_THD_TEMP_FALL3_0;
-		j = trip;
-	}
+static void exynos5433_tmu_disable_low(struct exynos_tmu_data *data)
+{
+	exynos_tmu_update_bit(data, EXYNOS5433_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_FALL0_SHIFT, false);
+}
 
-	th = readl(data->base + reg_off);
-	th &= ~(0xff << j * 8);
-	th |= (temp_to_code(data, temp - hyst) << j * 8);
-	writel(th, data->base + reg_off);
+static void exynos5433_tmu_disable_high(struct exynos_tmu_data *data)
+{
+	exynos_tmu_update_bit(data, EXYNOS5433_TMU_REG_INTEN,
+			      EXYNOS7_TMU_INTEN_RISE0_SHIFT + 1, false);
+}
+
+static void exynos5433_tmu_set_crit_temp(struct exynos_tmu_data *data, u8 temp)
+{
+	exynos_tmu_update_temp(data, EXYNOS5433_THD_TEMP_RISE7_4, 24, temp);
+	exynos_tmu_update_bit(data, EXYNOS_TMU_REG_CONTROL,
+			      EXYNOS_TMU_THERM_TRIP_EN_SHIFT, true);
+	exynos_tmu_update_bit(data, EXYNOS5433_TMU_REG_INTEN,
+			      EXYNOS7_TMU_INTEN_RISE0_SHIFT + 7, true);
 }
 
 static void exynos5433_tmu_initialize(struct platform_device *pdev)
@@ -505,34 +536,41 @@ static void exynos5433_tmu_initialize(struct platform_device *pdev)
 			cal_type ?  2 : 1);
 }
 
-static void exynos7_tmu_set_trip_temp(struct exynos_tmu_data *data,
-				      int trip, u8 temp)
+static void exynos7_tmu_set_low_temp(struct exynos_tmu_data *data, u8 temp)
 {
-	unsigned int reg_off, bit_off;
-	u32 th;
-
-	reg_off = ((7 - trip) / 2) * 4;
-	bit_off = ((8 - trip) % 2);
-
-	th = readl(data->base + EXYNOS7_THD_TEMP_RISE7_6 + reg_off);
-	th &= ~(EXYNOS7_TMU_TEMP_MASK << (16 * bit_off));
-	th |= temp_to_code(data, temp) << (16 * bit_off);
-	writel(th, data->base + EXYNOS7_THD_TEMP_RISE7_6 + reg_off);
+	exynos_tmu_update_temp(data, EXYNOS7_THD_TEMP_FALL7_6 + 12, 0, temp);
+	exynos_tmu_update_bit(data, EXYNOS7_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_FALL0_SHIFT + 0, true);
 }
 
-static void exynos7_tmu_set_trip_hyst(struct exynos_tmu_data *data,
-				      int trip, u8 temp, u8 hyst)
+static void exynos7_tmu_set_high_temp(struct exynos_tmu_data *data, u8 temp)
 {
-	unsigned int reg_off, bit_off;
-	u32 th;
+	exynos_tmu_update_temp(data, EXYNOS7_THD_TEMP_RISE7_6 + 12, 16, temp);
+	exynos_tmu_update_bit(data, EXYNOS7_TMU_REG_INTEN,
+			      EXYNOS7_TMU_INTEN_RISE0_SHIFT + 1, true);
+}
 
-	reg_off = ((7 - trip) / 2) * 4;
-	bit_off = ((8 - trip) % 2);
+static void exynos7_tmu_disable_low(struct exynos_tmu_data *data)
+{
+	exynos_tmu_update_bit(data, EXYNOS7_TMU_REG_INTEN,
+			      EXYNOS_TMU_INTEN_FALL0_SHIFT + 0, false);
+}
 
-	th = readl(data->base + EXYNOS7_THD_TEMP_FALL7_6 + reg_off);
-	th &= ~(EXYNOS7_TMU_TEMP_MASK << (16 * bit_off));
-	th |= temp_to_code(data, temp - hyst) << (16 * bit_off);
-	writel(th, data->base + EXYNOS7_THD_TEMP_FALL7_6 + reg_off);
+static void exynos7_tmu_disable_high(struct exynos_tmu_data *data)
+{
+	exynos_tmu_update_bit(data, EXYNOS7_TMU_REG_INTEN,
+			      EXYNOS7_TMU_INTEN_RISE0_SHIFT + 1, false);
+}
+
+static void exynos7_tmu_set_crit_temp(struct exynos_tmu_data *data, u8 temp)
+{
+	/*
+	 * Like Exynos 4210, Exynos 7 does not seem to support critical temperature
+	 * handling in hardware. Again, we still set a separate interrupt for it.
+	 */
+	exynos_tmu_update_temp(data, EXYNOS7_THD_TEMP_RISE7_6 + 0, 16, temp);
+	exynos_tmu_update_bit(data, EXYNOS7_TMU_REG_INTEN,
+			      EXYNOS7_TMU_INTEN_RISE0_SHIFT + 7, true);
 }
 
 static void exynos7_tmu_initialize(struct platform_device *pdev)
@@ -547,87 +585,44 @@ static void exynos7_tmu_initialize(struct platform_device *pdev)
 static void exynos4210_tmu_control(struct platform_device *pdev, bool on)
 {
 	struct exynos_tmu_data *data = platform_get_drvdata(pdev);
-	struct thermal_zone_device *tz = data->tzd;
-	struct thermal_trip trip;
-	unsigned int con, interrupt_en = 0, i;
+	unsigned int con;
 
 	con = get_con_reg(data, readl(data->base + EXYNOS_TMU_REG_CONTROL));
 
-	if (on) {
-		for (i = 0; i < data->ntrip; i++) {
-			if (thermal_zone_get_trip(tz, i, &trip))
-				continue;
-
-			interrupt_en |=
-				BIT(EXYNOS_TMU_INTEN_RISE0_SHIFT + i * 4);
-		}
-
-		if (data->soc != SOC_ARCH_EXYNOS4210)
-			interrupt_en |=
-				interrupt_en << EXYNOS_TMU_INTEN_FALL0_SHIFT;
-
+	if (on)
 		con |= BIT(EXYNOS_TMU_CORE_EN_SHIFT);
-	} else {
+	else
 		con &= ~BIT(EXYNOS_TMU_CORE_EN_SHIFT);
-	}
 
-	writel(interrupt_en, data->base + EXYNOS_TMU_REG_INTEN);
 	writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
 }
 
 static void exynos5433_tmu_control(struct platform_device *pdev, bool on)
 {
 	struct exynos_tmu_data *data = platform_get_drvdata(pdev);
-	struct thermal_zone_device *tz = data->tzd;
-	struct thermal_trip trip;
-	unsigned int con, interrupt_en = 0, pd_det_en, i;
+	unsigned int con, pd_det_en;
 
 	con = get_con_reg(data, readl(data->base + EXYNOS_TMU_REG_CONTROL));
 
-	if (on) {
-		for (i = 0; i < data->ntrip; i++) {
-			if (thermal_zone_get_trip(tz, i, &trip))
-				continue;
-
-			interrupt_en |=
-				BIT(EXYNOS7_TMU_INTEN_RISE0_SHIFT + i);
-		}
-
-		interrupt_en |=
-			interrupt_en << EXYNOS_TMU_INTEN_FALL0_SHIFT;
-
+	if (on)
 		con |= BIT(EXYNOS_TMU_CORE_EN_SHIFT);
-	} else
+	else
 		con &= ~BIT(EXYNOS_TMU_CORE_EN_SHIFT);
 
 	pd_det_en = on ? EXYNOS5433_PD_DET_EN : 0;
 
 	writel(pd_det_en, data->base + EXYNOS5433_TMU_PD_DET_EN);
-	writel(interrupt_en, data->base + EXYNOS5433_TMU_REG_INTEN);
 	writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
 }
 
 static void exynos7_tmu_control(struct platform_device *pdev, bool on)
 {
 	struct exynos_tmu_data *data = platform_get_drvdata(pdev);
-	struct thermal_zone_device *tz = data->tzd;
-	struct thermal_trip trip;
-	unsigned int con, interrupt_en = 0, i;
+	unsigned int con;
 
 	con = get_con_reg(data, readl(data->base + EXYNOS_TMU_REG_CONTROL));
 
 	if (on) {
-		for (i = 0; i < data->ntrip; i++) {
-			if (thermal_zone_get_trip(tz, i, &trip))
-				continue;
-
-			interrupt_en |=
-				BIT(EXYNOS7_TMU_INTEN_RISE0_SHIFT + i);
-		}
-
-		interrupt_en |=
-			interrupt_en << EXYNOS_TMU_INTEN_FALL0_SHIFT;
-
 		con |= BIT(EXYNOS_TMU_CORE_EN_SHIFT);
 		con |= BIT(EXYNOS7_PD_DET_EN_SHIFT);
 	} else {
@@ -635,7 +630,6 @@ static void exynos7_tmu_control(struct platform_device *pdev, bool on)
 		con &= ~BIT(EXYNOS7_PD_DET_EN_SHIFT);
 	}
 
-	writel(interrupt_en, data->base + EXYNOS7_TMU_REG_INTEN);
 	writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
 }
 
@@ -873,13 +867,15 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 
 	switch (data->soc) {
 	case SOC_ARCH_EXYNOS4210:
-		data->tmu_set_trip_temp = exynos4210_tmu_set_trip_temp;
-		data->tmu_set_trip_hyst = exynos4210_tmu_set_trip_hyst;
+		data->tmu_set_low_temp = exynos4210_tmu_set_low_temp;
+		data->tmu_set_high_temp = exynos4210_tmu_set_high_temp;
+		data->tmu_disable_low = exynos4210_tmu_disable_low;
+		data->tmu_disable_high = exynos4210_tmu_disable_high;
+		data->tmu_set_crit_temp = exynos4210_tmu_set_crit_temp;
 		data->tmu_initialize = exynos4210_tmu_initialize;
 		data->tmu_control = exynos4210_tmu_control;
 		data->tmu_read = exynos4210_tmu_read;
 		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
-		data->ntrip = 4;
 		data->gain = 15;
 		data->reference_voltage = 7;
 		data->efuse_value = 55;
@@ -892,14 +888,16 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 	case SOC_ARCH_EXYNOS5260:
 	case SOC_ARCH_EXYNOS5420:
 	case SOC_ARCH_EXYNOS5420_TRIMINFO:
-		data->tmu_set_trip_temp = exynos4412_tmu_set_trip_temp;
-		data->tmu_set_trip_hyst = exynos4412_tmu_set_trip_hyst;
+		data->tmu_set_low_temp = exynos4412_tmu_set_low_temp;
+		data->tmu_set_high_temp = exynos4412_tmu_set_high_temp;
+		data->tmu_disable_low = exynos4412_tmu_disable_low;
+		data->tmu_disable_high = exynos4210_tmu_disable_high;
+		data->tmu_set_crit_temp = exynos4412_tmu_set_crit_temp;
 		data->tmu_initialize = exynos4412_tmu_initialize;
 		data->tmu_control = exynos4210_tmu_control;
 		data->tmu_read = exynos4412_tmu_read;
 		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
 		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
-		data->ntrip = 4;
 		data->gain = 8;
 		data->reference_voltage = 16;
 		data->efuse_value = 55;
@@ -911,14 +909,16 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 		data->max_efuse_value = 100;
 		break;
 	case SOC_ARCH_EXYNOS5433:
-		data->tmu_set_trip_temp = exynos5433_tmu_set_trip_temp;
-		data->tmu_set_trip_hyst = exynos5433_tmu_set_trip_hyst;
+		data->tmu_set_low_temp = exynos5433_tmu_set_low_temp;
+		data->tmu_set_high_temp = exynos5433_tmu_set_high_temp;
+		data->tmu_disable_low = exynos5433_tmu_disable_low;
+		data->tmu_disable_high = exynos5433_tmu_disable_high;
+		data->tmu_set_crit_temp = exynos5433_tmu_set_crit_temp;
 		data->tmu_initialize = exynos5433_tmu_initialize;
 		data->tmu_control = exynos5433_tmu_control;
 		data->tmu_read = exynos4412_tmu_read;
 		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
 		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
-		data->ntrip = 8;
 		data->gain = 8;
 		if (res.start == EXYNOS5433_G3D_BASE)
 			data->reference_voltage = 23;
@@ -929,14 +929,16 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 		data->max_efuse_value = 150;
 		break;
 	case SOC_ARCH_EXYNOS7:
-		data->tmu_set_trip_temp = exynos7_tmu_set_trip_temp;
-		data->tmu_set_trip_hyst = exynos7_tmu_set_trip_hyst;
+		data->tmu_set_low_temp = exynos7_tmu_set_low_temp;
+		data->tmu_set_high_temp = exynos7_tmu_set_high_temp;
+		data->tmu_disable_low = exynos7_tmu_disable_low;
+		data->tmu_disable_high = exynos7_tmu_disable_high;
+		data->tmu_set_crit_temp = exynos7_tmu_set_crit_temp;
 		data->tmu_initialize = exynos7_tmu_initialize;
 		data->tmu_control = exynos7_tmu_control;
 		data->tmu_read = exynos7_tmu_read;
 		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
 		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
-		data->ntrip = 8;
 		data->gain = 9;
 		data->reference_voltage = 17;
 		data->efuse_value = 75;
@@ -972,9 +974,32 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 	return 0;
 }
 
+static int exynos_set_trips(struct thermal_zone_device *tz, int low, int high)
+{
+	struct exynos_tmu_data *data = thermal_zone_device_priv(tz);
+
+	mutex_lock(&data->lock);
+	clk_enable(data->clk);
+
+	if (low > INT_MIN)
+		data->tmu_set_low_temp(data, low / MCELSIUS);
+	else
+		data->tmu_disable_low(data);
+	if (high < INT_MAX)
+		data->tmu_set_high_temp(data, high / MCELSIUS);
+	else
+		data->tmu_disable_high(data);
+
+	clk_disable(data->clk);
+	mutex_unlock(&data->lock);
+
+	return 0;
+}
+
 static const struct thermal_zone_device_ops exynos_sensor_ops = {
 	.get_temp = exynos_get_temp,
 	.set_emul_temp = exynos_tmu_set_emulation,
+	.set_trips = exynos_set_trips,
 };
 
 static int exynos_tmu_probe(struct platform_device *pdev)
-- 
2.42.0



From lee at kernel.org  Fri Dec  1 01:57:36 2023
From: lee at kernel.org (Lee Jones)
Date: Fri, 01 Dec 2023 09:57:36 +0000
Subject: (subset) [PATCH v11 01/10] mfd: tps6594: Use set/get APIs to
 access spi->chip_select
In-Reply-To: <20231125092137.2948-2-amit.kumar-mahapatra@amd.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-2-amit.kumar-mahapatra@amd.com>
Message-ID: <170142465659.3329910.8527538140063947758.b4-ty@kernel.org>

On Sat, 25 Nov 2023 14:51:28 +0530, Amit Kumar Mahapatra wrote:
> In preparation for adding multiple CS support for a device, set/get
> functions were introduces accessing spi->chip_select in
> 'commit 303feb3cc06a ("spi: Add APIs in spi core to set/get
> spi->chip_select and spi->cs_gpiod")'.
> Replace spi->chip_select with spi_get_chipselect() API.
> 
> 
> [...]

Applied, thanks!

[01/10] mfd: tps6594: Use set/get APIs to access spi->chip_select
        commit: dd636638446c87c95c5beddcd367d95ac6764c6c

--
Lee Jones [???]



From krzysztof.kozlowski at linaro.org  Fri Dec  1 01:59:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 1 Dec 2023 10:59:08 +0100
Subject: [PATCH] dt-bindings: gpio: modepin: Describe label property
In-Reply-To: <10db3021e8617c1f98eca51e26d350dc4b51b53c.1701335736.git.michal.simek@amd.com>
References: <10db3021e8617c1f98eca51e26d350dc4b51b53c.1701335736.git.michal.simek@amd.com>
Message-ID: <b3cab50d-3c7b-497b-8154-859c8aa4622c@linaro.org>

On 30/11/2023 10:15, Michal Simek wrote:
> Describe optional label property which can be used for better gpio
> identification.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From quic_snehshah at quicinc.com  Fri Dec  1 02:05:48 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Fri,  1 Dec 2023 15:35:48 +0530
Subject: [PATCH v2] net: stmmac: update Rx clk divider for 10M SGMII
Message-ID: <20231201100548.12994-1-quic_snehshah@quicinc.com>

SGMII 10MBPS mode needs RX clock divider to avoid drops in Rx.
Update configure SGMII function with rx clk divider programming.

Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
---
v2 changelog:
- Use FIELD_PREP to prepare bifield values in place of GENMASK
- Add fixes tag
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index d3bf42d0fceb..df6ff8bcdb5c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -34,6 +34,7 @@
 #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
 #define RGMII_CONFIG_PROG_SWAP			BIT(1)
 #define RGMII_CONFIG_DDR_MODE			BIT(0)
+#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)
 
 /* SDCC_HC_REG_DLL_CONFIG fields */
 #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
@@ -617,6 +618,9 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
 	case SPEED_10:
 		val |= ETHQOS_MAC_CTRL_PORT_SEL;
 		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
+		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
+			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR, 0x31),
+			      RGMII_IO_MACRO_CONFIG);
 		break;
 	}
 
-- 
2.17.1



From lkp at intel.com  Fri Dec  1 02:09:04 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 1 Dec 2023 18:09:04 +0800
Subject: [PATCH v3 1/4] iommu/arm-smmu: introduction of ACTLR for custom
 prefetcher settings
In-Reply-To: <20231127145412.3981-2-quic_bibekkum@quicinc.com>
References: <20231127145412.3981-2-quic_bibekkum@quicinc.com>
Message-ID: <202312011750.Pwca3TWE-lkp@intel.com>

Hi Bibek,

kernel test robot noticed the following build errors:

[auto build test ERROR on v6.7-rc3]
[also build test ERROR on linus/master next-20231201]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Bibek-Kumar-Patro/iommu-arm-smmu-add-ACTLR-data-and-support-for-SM8550/20231127-235746
base:   v6.7-rc3
patch link:    https://lore.kernel.org/r/20231127145412.3981-2-quic_bibekkum%40quicinc.com
patch subject: [PATCH v3 1/4] iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings
config: arm64-allyesconfig (https://download.01.org/0day-ci/archive/20231201/202312011750.Pwca3TWE-lkp at intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231201/202312011750.Pwca3TWE-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312011750.Pwca3TWE-lkp at intel.com/

All errors (new ones prefixed by >>):

>> drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c:25:16: error: no member named 'cfg' in 'struct qcom_smmu'
      25 |                 cfg = qsmmu->cfg;
         |                       ~~~~~  ^
   1 error generated.


vim +25 drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c

b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  12  
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  13  void qcom_smmu_tlb_sync_debug(struct arm_smmu_device *smmu)
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  14  {
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  15  	int ret;
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  16  	u32 tbu_pwr_status, sync_inv_ack, sync_inv_progress;
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  17  	struct qcom_smmu *qsmmu = container_of(smmu, struct qcom_smmu, smmu);
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  18  	const struct qcom_smmu_config *cfg;
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  19  	static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  20  				      DEFAULT_RATELIMIT_BURST);
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  21  
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  22  	if (__ratelimit(&rs)) {
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  23  		dev_err(smmu->dev, "TLB sync timed out -- SMMU may be deadlocked\n");
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08  24  
b9b721d117e9d3 Sai Prakash Ranjan 2022-07-08 @25  		cfg = qsmmu->cfg;

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From neil.armstrong at linaro.org  Fri Dec  1 02:09:44 2023
From: neil.armstrong at linaro.org (neil.armstrong at linaro.org)
Date: Fri, 1 Dec 2023 11:09:44 +0100
Subject: [PATCH v7 00/10] Enable HS-G5 support on SM8550
In-Reply-To: <1701407001-471-1-git-send-email-quic_cang@quicinc.com>
References: <1701407001-471-1-git-send-email-quic_cang@quicinc.com>
Message-ID: <a6651f9f-b060-4195-b83a-b23aa2091a98@linaro.org>

On 01/12/2023 06:03, Can Guo wrote:
> This series enables HS-G5 support on SM8550.
> 
> This series is rebased on below changes from Mani -
> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-1-manivannan.sadhasivam at linaro.org/
> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-2-manivannan.sadhasivam at linaro.org/
> 
> This series is tested on below HW combinations -
> SM8550 MTP + UFS4.0
> SM8550 QRD + UFS3.1
> SM8450 MTP + UFS3.1 (for regression test)
> SM8350 MTP + UFS3.1 (for regression test)
> 
> Note that during reboot test on above platforms, I occasinally hit PA (PHY)
> error during the 2nd init, this is not related with this series. A fix for
> this is mentioned in below patchwork -
> 
> https://patchwork.kernel.org/project/linux-scsi/patch/1698145815-17396-1-git-send-email-quic_ziqichen at quicinc.com/
> 
> Also note that on platforms, which have two sets of UFS PHY settings are
> provided (say G4 and no-G4, G5 and no-G5). The two sets of PHY settings are
> basically programming different values to different registers, mixing the
> two sets and/or overwriting one set with another set is definitely not
> blessed by UFS PHY designers. For SM8550, this series will make sure we
> honor the rule. However, for old targets Mani and I will fix them in
> another series in future.
> 
> v6 -> v7:
> 1. Rebased on linux-next, based SM8650 PHY settings are merged there, no changes to patches for UFS driver
> 2. Addressed comments from Mani
> 
> v5 -> v6:
> 1. Rebased on scsi-queue-6.8
> 2. Addressed comments from Dmitry and Mani in patches to phy-qcom-qmp-ufs.c
> 
> v4 -> v5:
> Removed two useless debug prints in patch #9
> 
> v3 -> v4:
> Used .tbls_hs_overlay array instead of adding more tables with different names like .tbls_hs_g5
> 
> v2 -> v3:
> 1. Addressed comments from Andrew, Mani and Bart in patch #1
> 2. Added patch #2 as per request from Andrew and Mani
> 3. Added patch #4 to fix a common issue on old targets, it is not necessary
>     for this series, but put in this series only because it would be easier
>     to maintain and no need to rebase
> 4. Addressed comments from Dmitry and Mani in patches to phy-qcom-qmp-ufs.c
> 
> v1 -> v2:
> 1. Removed 2 changes which were exposing power info in sysfs
> 2. Removed 1 change which was moving data structs to phy-qcom-qmp-ufs.h
> 3. Added one new change (the 1st one) to clean up usage of ufs_dev_params based on comments from Mani
> 4. Adjusted the logic of UFS device version detection according to comments from Mani:
> 	4.1 For HW version < 0x5, go through dual init
>   	4.2 For HW version >= 0x5
> 		a. If UFS device version is populated, one init is required
> 		b. If UFS device version is not populated, go through dual init
> 
> Bao D. Nguyen (1):
>    scsi: ufs: ufs-qcom: Add support for UFS device version detection
> 
> Can Guo (9):
>    scsi: ufs: host: Rename structure ufs_dev_params to ufs_host_params
>    scsi: ufs: ufs-qcom: No need to set hs_rate after
>      ufshcd_init_host_param()
>    scsi: ufs: ufs-qcom: Setup host power mode during init
>    scsi: ufs: ufs-qcom: Allow the first init start with the maximum
>      supported gear
>    scsi: ufs: ufs-qcom: Limit HS-G5 Rate-A to hosts with HW version 5
>    scsi: ufs: ufs-qcom: Set initial PHY gear to max HS gear for HW ver 4
>      and newer
>    scsi: ufs: ufs-qcom: Check return value of phy_set_mode_ext()
>    phy: qualcomm: phy-qcom-qmp-ufs: Rectify SM8550 UFS HS-G4 PHY Settings
>    phy: qualcomm: phy-qcom-qmp-ufs: Add High Speed Gear 5 support for
>      SM8550
> 
>   drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h     |   2 +
>   drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h |   2 +
>   .../qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h    |   9 +
>   drivers/phy/qualcomm/phy-qcom-qmp-ufs.c            | 191 ++++++++++++++++++---
>   drivers/ufs/host/ufs-exynos.c                      |   7 +-
>   drivers/ufs/host/ufs-hisi.c                        |  11 +-
>   drivers/ufs/host/ufs-mediatek.c                    |  12 +-
>   drivers/ufs/host/ufs-qcom.c                        |  97 ++++++++---
>   drivers/ufs/host/ufs-qcom.h                        |   7 +-
>   drivers/ufs/host/ufshcd-pltfrm.c                   |  69 ++++----
>   drivers/ufs/host/ufshcd-pltfrm.h                   |  10 +-
>   11 files changed, 309 insertions(+), 108 deletions(-)
> 

Tested-by: Neil Armstrong <neil.armstrong at linaro.org> # on SM8550-QRD
Tested-by: Neil Armstrong <neil.armstrong at linaro.org> # on SM8650-QRD

Thanks,
Neil


From m-chawdhry at ti.com  Fri Dec  1 02:26:45 2023
From: m-chawdhry at ti.com (Manorit Chawdhry)
Date: Fri, 1 Dec 2023 15:56:45 +0530
Subject: [PATCH v8 5/7] arm64: dts: ti: k3-am69-sk: Add support for
 TPS6594 PMIC
In-Reply-To: <20231128055230.342547-6-n-francis@ti.com>
References: <20231128055230.342547-1-n-francis@ti.com>
 <20231128055230.342547-6-n-francis@ti.com>
Message-ID: <20231201102645.u3embsudo55vm6pi@ula0497581>

Hi Neha,

On 11:22-20231128, Neha Malcom Francis wrote:
> This patch adds support for TPS6594 PMIC on wkup I2C0 bus. This device
> provides regulators (bucks and LDOs), but also GPIOs, a RTC, a watchdog,
> an ESM (Error Signal Monitor) which monitors the SoC error output
> signal, and a PFSM (Pre-configurable Finite State Machine) which manages
> the operational modes of the PMIC.
> 
> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
> ---
>  arch/arm64/boot/dts/ti/k3-am69-sk.dts | 100 ++++++++++++++++++++++++++
>  1 file changed, 100 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> index 9868c7049bfb..dec27acb4e96 100644
> --- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> @@ -431,6 +431,17 @@ J784S4_IOPAD(0x000, PIN_INPUT, 7) /* (AN35) EXTINTN.GPIO0_0 */
>  	};
>  };
>  
> +&wkup_pmx1 {
> +	status = "okay";
> +
> +	pmic_irq_pins_default: pmic-irq-default-pins {
> +		pinctrl-single,pins = <
> +			/* (AA37) MCU_ADC1_AIN4.WKUP_GPIO0_83 */
> +			J784S4_WKUP_IOPAD(0x12c, PIN_INPUT, 7)
> +		>;
> +	};
> +};
> +
>  &wkup_pmx2 {
>  	bootph-all;
>  	wkup_uart0_pins_default: wkup-uart0-default-pins {
> @@ -631,6 +642,95 @@ eeprom at 51 {
>  		compatible = "atmel,24c512";
>  		reg = <0x51>;
>  	};
> +
> +	tps659413: pmic at 48 {
> +		compatible = "ti,tps6594-q1";
> +		reg = <0x48>;
> +		system-power-controller;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_irq_pins_default>;
> +		interrupt-parent = <&wkup_gpio0>;
> +		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
> +		ti,primary-pmic;
> +
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +		buck12-supply = <&vsys_3v3>;
> +		buck3-supply = <&vsys_3v3>;
> +		buck4-supply = <&vsys_3v3>;
> +		buck5-supply = <&vsys_3v3>;
> +		ldo1-supply = <&vsys_3v3>;
> +		ldo2-supply = <&vsys_3v3>;
> +		ldo3-supply = <&vsys_3v3>;
> +		ldo4-supply = <&vsys_3v3>;
> +
> +		regulators {
> +			bucka12: buck12 {
> +				regulator-name = "vdd_ddr_1v1";
> +				regulator-min-microvolt = <1100000>;
> +				regulator-max-microvolt = <1100000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka3: buck3 {
> +				regulator-name = "vdd_ram_0v85";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka4: buck4 {
> +				regulator-name = "vdd_io_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka5: buck5 {
> +				regulator-name = "vdd_mcu_0v85";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa1: ldo1 {
> +				regulator-name = "vdd_mcuio_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa2: ldo2 {
> +				regulator-name = "vdd_mcuio_3v3";
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa3: ldo3 {
> +				regulator-name = "vds_dll_0v8";
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa4: ldo4 {
> +				regulator-name = "vda_mcu_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +		};
> +	};
>  };
>  

With the full series applied:
https://gist.github.com/manorit2001/7e794a7cbf58af4d7fbbee03eac88e86

[ For AM69-SK ]
Tested-by: Manorit Chawdhry <m-chawdhry at ti.com>

Regards,
Manorit

>  &wkup_gpio0 {
> -- 
> 2.34.1
> 


From treapking at chromium.org  Fri Dec  1 02:26:51 2023
From: treapking at chromium.org (Pin-yen Lin)
Date: Fri,  1 Dec 2023 18:26:51 +0800
Subject: [PATCH v3] mmc: mtk-sd: Increase the verbosity of msdc_track_cmd_data
Message-ID: <20231201102747.3854573-1-treapking@chromium.org>

This log message is necessary for debugging, so enable it by default to
debug issues that are hard to reproduce locally.

Signed-off-by: Pin-yen Lin <treapking at chromium.org>

---

Changes in v3:
- Only print the warning when -ETIMEDOUT or not in tuning process

Changes in v2:
- Use dev_warn() instead of dev_err()

 drivers/mmc/host/mtk-sd.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 97f7c3d4be6e..6ae5e0a9fca9 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1149,9 +1149,11 @@ static void msdc_recheck_sdio_irq(struct msdc_host *host)
 
 static void msdc_track_cmd_data(struct msdc_host *host, struct mmc_command *cmd)
 {
-	if (host->error)
-		dev_dbg(host->dev, "%s: cmd=%d arg=%08X; host->error=0x%08X\n",
-			__func__, cmd->opcode, cmd->arg, host->error);
+	if (host->error &&
+	    ((!mmc_op_tuning(cmd->opcode) && !host->hs400_tuning) ||
+	     cmd->error == -ETIMEDOUT))
+		dev_warn(host->dev, "%s: cmd=%d arg=%08X; host->error=0x%08X\n",
+			 __func__, cmd->opcode, cmd->arg, host->error);
 }
 
 static void msdc_request_done(struct msdc_host *host, struct mmc_request *mrq)
-- 
2.43.0.rc2.451.g8631bc7472-goog



From n-francis at ti.com  Fri Dec  1 02:30:46 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 1 Dec 2023 16:00:46 +0530
Subject: [PATCH v8 5/7] arm64: dts: ti: k3-am69-sk: Add support for
 TPS6594 PMIC
In-Reply-To: <20231201102645.u3embsudo55vm6pi@ula0497581>
References: <20231128055230.342547-1-n-francis@ti.com>
 <20231128055230.342547-6-n-francis@ti.com>
 <20231201102645.u3embsudo55vm6pi@ula0497581>
Message-ID: <e3b018c9-31d5-48c3-8327-be4dadcc505c@ti.com>

Hi Manorit

On 01-Dec-23 3:56 PM, Manorit Chawdhry wrote:
> Hi Neha,
> 
> On 11:22-20231128, Neha Malcom Francis wrote:
>> This patch adds support for TPS6594 PMIC on wkup I2C0 bus. This device
>> provides regulators (bucks and LDOs), but also GPIOs, a RTC, a watchdog,
>> an ESM (Error Signal Monitor) which monitors the SoC error output
>> signal, and a PFSM (Pre-configurable Finite State Machine) which manages
>> the operational modes of the PMIC.
>>
>> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
>> ---
>>   arch/arm64/boot/dts/ti/k3-am69-sk.dts | 100 ++++++++++++++++++++++++++
>>   1 file changed, 100 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
>> index 9868c7049bfb..dec27acb4e96 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
>> @@ -431,6 +431,17 @@ J784S4_IOPAD(0x000, PIN_INPUT, 7) /* (AN35) EXTINTN.GPIO0_0 */
>>   	};
>>   };
>>   
>> +&wkup_pmx1 {
>> +	status = "okay";
>> +
>> +	pmic_irq_pins_default: pmic-irq-default-pins {
>> +		pinctrl-single,pins = <
>> +			/* (AA37) MCU_ADC1_AIN4.WKUP_GPIO0_83 */
>> +			J784S4_WKUP_IOPAD(0x12c, PIN_INPUT, 7)
>> +		>;
>> +	};
>> +};
>> +
>>   &wkup_pmx2 {
>>   	bootph-all;
>>   	wkup_uart0_pins_default: wkup-uart0-default-pins {
>> @@ -631,6 +642,95 @@ eeprom at 51 {
>>   		compatible = "atmel,24c512";
>>   		reg = <0x51>;
>>   	};
>> +
>> +	tps659413: pmic at 48 {
>> +		compatible = "ti,tps6594-q1";
>> +		reg = <0x48>;
>> +		system-power-controller;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pmic_irq_pins_default>;
>> +		interrupt-parent = <&wkup_gpio0>;
>> +		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
>> +		ti,primary-pmic;
>> +
>> +		gpio-controller;
>> +		#gpio-cells = <2>;
>> +
>> +		buck12-supply = <&vsys_3v3>;
>> +		buck3-supply = <&vsys_3v3>;
>> +		buck4-supply = <&vsys_3v3>;
>> +		buck5-supply = <&vsys_3v3>;
>> +		ldo1-supply = <&vsys_3v3>;
>> +		ldo2-supply = <&vsys_3v3>;
>> +		ldo3-supply = <&vsys_3v3>;
>> +		ldo4-supply = <&vsys_3v3>;
>> +
>> +		regulators {
>> +			bucka12: buck12 {
>> +				regulator-name = "vdd_ddr_1v1";
>> +				regulator-min-microvolt = <1100000>;
>> +				regulator-max-microvolt = <1100000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			bucka3: buck3 {
>> +				regulator-name = "vdd_ram_0v85";
>> +				regulator-min-microvolt = <850000>;
>> +				regulator-max-microvolt = <850000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			bucka4: buck4 {
>> +				regulator-name = "vdd_io_1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			bucka5: buck5 {
>> +				regulator-name = "vdd_mcu_0v85";
>> +				regulator-min-microvolt = <850000>;
>> +				regulator-max-microvolt = <850000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldoa1: ldo1 {
>> +				regulator-name = "vdd_mcuio_1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldoa2: ldo2 {
>> +				regulator-name = "vdd_mcuio_3v3";
>> +				regulator-min-microvolt = <3300000>;
>> +				regulator-max-microvolt = <3300000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldoa3: ldo3 {
>> +				regulator-name = "vds_dll_0v8";
>> +				regulator-min-microvolt = <800000>;
>> +				regulator-max-microvolt = <800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldoa4: ldo4 {
>> +				regulator-name = "vda_mcu_1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +		};
>> +	};
>>   };
>>   
> 
> With the full series applied:
> https://gist.github.com/manorit2001/7e794a7cbf58af4d7fbbee03eac88e86
> 
> [ For AM69-SK ]
> Tested-by: Manorit Chawdhry <m-chawdhry at ti.com>
> 
> Regards,
> Manorit
> 
>>   &wkup_gpio0 {
>> -- 
>> 2.34.1
>>

Thanks for testing!

-- 
Thanking You
Neha Malcom Francis


From brgl at bgdev.pl  Fri Dec  1 02:37:59 2023
From: brgl at bgdev.pl (Bartosz Golaszewski)
Date: Fri, 1 Dec 2023 11:37:59 +0100
Subject: [PATCH] dt-bindings: gpio: modepin: Describe label property
In-Reply-To: <10db3021e8617c1f98eca51e26d350dc4b51b53c.1701335736.git.michal.simek@amd.com>
References: <10db3021e8617c1f98eca51e26d350dc4b51b53c.1701335736.git.michal.simek@amd.com>
Message-ID: <CAMRc=Md7iQnkOp+nB3=haakpt5jF_STtYgDAcxRVQJjYWnjFKA@mail.gmail.com>

On Thu, Nov 30, 2023 at 10:15?AM Michal Simek <michal.simek at amd.com> wrote:
>
> Describe optional label property which can be used for better gpio
> identification.
>
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---
>
>  .../devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml     | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
> index 56143f1fe84a..b1fd632718d4 100644
> --- a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
> +++ b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
> @@ -23,6 +23,8 @@ properties:
>    "#gpio-cells":
>      const: 2
>
> +  label: true
> +
>  required:
>    - compatible
>    - gpio-controller
> @@ -37,6 +39,7 @@ examples:
>              compatible = "xlnx,zynqmp-gpio-modepin";
>              gpio-controller;
>              #gpio-cells = <2>;
> +            label = "modepin";
>          };
>      };
>
> --
> 2.36.1
>

Applied, thanks!

Bart


From conor.dooley at microchip.com  Fri Dec  1 02:38:13 2023
From: conor.dooley at microchip.com (Conor Dooley)
Date: Fri, 1 Dec 2023 10:38:13 +0000
Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <20231130023955.5257-6-bhe@redhat.com>
References: <20231130023955.5257-1-bhe@redhat.com>
 <20231130023955.5257-6-bhe@redhat.com>
Message-ID: <20231201-blog-blasphemy-985d2665903c@wendy>

On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:

$subject has a typo in the arch bit :)

> Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> loading related codes.

Commit messages should be understandable in isolation, but this only
explains (part of) what is obvious in the diff. Why is this change
being made?

> 
> And also remove kexec_image_info() because the content has been printed
> out in generic code.
> 
> Signed-off-by: Baoquan He <bhe at redhat.com>
> ---
>  arch/riscv/kernel/elf_kexec.c     | 11 ++++++-----
>  arch/riscv/kernel/machine_kexec.c | 26 --------------------------
>  2 files changed, 6 insertions(+), 31 deletions(-)
> 
> diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> index e60fbd8660c4..5bd1ec3341fe 100644
> --- a/arch/riscv/kernel/elf_kexec.c
> +++ b/arch/riscv/kernel/elf_kexec.c
> @@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
>  	if (ret)
>  		goto out;
>  	kernel_start = image->start;
> -	pr_notice("The entry point of kernel at 0x%lx\n", image->start);
>  
>  	/* Add the kernel binary to the image */
>  	ret = riscv_kexec_elf_load(image, &ehdr, &elf_info,
> @@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
>  		image->elf_load_addr = kbuf.mem;
>  		image->elf_headers_sz = headers_sz;
>  
> -		pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> -			 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> +		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> +			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
>  
>  		/* Setup cmdline for kdump kernel case */
>  		modified_cmdline = setup_kdump_cmdline(image, cmdline,
> @@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
>  		pr_err("Error loading purgatory ret=%d\n", ret);
>  		goto out;
>  	}
> +	kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem);
> +
>  	ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry",
>  					     &kernel_start,
>  					     sizeof(kernel_start), 0);
> @@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
>  		if (ret)
>  			goto out;
>  		initrd_pbase = kbuf.mem;

> -		pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase);
> +		kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase);

This is not a pr_debug().

>  	}
>  
>  	/* Add the DTB to the image */
> @@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
>  	}
>  	/* Cache the fdt buffer address for memory cleanup */
>  	image->arch.fdt = fdt;

> -	pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem);
> +	kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem);

Neither is this. Why are they being moved from pr_notice()?

Thanks,
Conor.

>  	goto out;
>  
>  out_free_fdt:
> diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
> index 2d139b724bc8..ed9cad20c039 100644
> --- a/arch/riscv/kernel/machine_kexec.c
> +++ b/arch/riscv/kernel/machine_kexec.c
> @@ -18,30 +18,6 @@
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
>  
> -/*
> - * kexec_image_info - Print received image details
> - */
> -static void
> -kexec_image_info(const struct kimage *image)
> -{
> -	unsigned long i;
> -
> -	pr_debug("Kexec image info:\n");
> -	pr_debug("\ttype:        %d\n", image->type);
> -	pr_debug("\tstart:       %lx\n", image->start);
> -	pr_debug("\thead:        %lx\n", image->head);
> -	pr_debug("\tnr_segments: %lu\n", image->nr_segments);
> -
> -	for (i = 0; i < image->nr_segments; i++) {
> -		pr_debug("\t    segment[%lu]: %016lx - %016lx", i,
> -			image->segment[i].mem,
> -			image->segment[i].mem + image->segment[i].memsz);
> -		pr_debug("\t\t0x%lx bytes, %lu pages\n",
> -			(unsigned long) image->segment[i].memsz,
> -			(unsigned long) image->segment[i].memsz /  PAGE_SIZE);
> -	}
> -}
> -
>  /*
>   * machine_kexec_prepare - Initialize kexec
>   *
> @@ -60,8 +36,6 @@ machine_kexec_prepare(struct kimage *image)
>  	unsigned int control_code_buffer_sz = 0;
>  	int i = 0;
>  
> -	kexec_image_info(image);
> -
>  	/* Find the Flattened Device Tree and save its physical address */
>  	for (i = 0; i < image->nr_segments; i++) {
>  		if (image->segment[i].memsz <= sizeof(fdt))
> -- 
> 2.41.0
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/4cd14ff0/attachment.sig>

From tglx at linutronix.de  Fri Dec  1 02:45:06 2023
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 01 Dec 2023 11:45:06 +0100
Subject: [PATCH 01/21] arch_topology: Make
 register_cpu_capacity_sysctl() tolerant to late CPUs
In-Reply-To: <E1r5R2g-00CsyV-Ss@rmk-PC.armlinux.org.uk>
References: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk>
 <E1r5R2g-00CsyV-Ss@rmk-PC.armlinux.org.uk>
Message-ID: <87v89ixkul.ffs@tglx>

On Tue, Nov 21 2023 at 13:43, Russell King wrote:
> ---
> If the offline CPUs thing is a problem for the tools that consume
> this value, we'd need to move cpu_capacity to be part of cpu.c's
> common_cpu_attr_groups. However, attempts to discuss this just end
> up in a black hole, so this is a non-starter. Thus, if this needs
> to be done, it can be done as a separate patch.

Offline CPUs have 0 capacity by definition....


From hawk at kernel.org  Fri Dec  1 02:46:20 2023
From: hawk at kernel.org (Jesper Dangaard Brouer)
Date: Fri, 1 Dec 2023 11:46:20 +0100
Subject: [PATCH bpf-next v2 0/3] xsk: TX metadata txtime support
In-Reply-To: <20231201062421.1074768-1-yoong.siang.song@intel.com>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
Message-ID: <d4f99931-442c-4cd7-b3cf-80d8681a2986@kernel.org>



On 12/1/23 07:24, Song Yoong Siang wrote:
> This series expands XDP TX metadata framework to include ETF HW offload.
> 
> Changes since v1:
> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF)
> - rename launch-time to txtime
> 

I strongly disagree with this renaming (sorry to disagree with Willem).

The i210 and i225 chips call this LaunchTime in their programmers 
datasheets, and even in the driver code[1].

Using this "txtime" name in the code is also confusing, because how can 
people reading the code know the difference between:
  - tmo_request_timestamp and tmo_request_txtime


[1] 
https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org

> v1: https://patchwork.kernel.org/project/netdevbpf/cover/20231130162028.852006-1-yoong.siang.song at intel.com/
> 
> Song Yoong Siang (3):
>    xsk: add ETF support to XDP Tx metadata
>    net: stmmac: Add txtime support to XDP ZC
>    selftests/bpf: Add txtime to xdp_hw_metadata
> 
>   Documentation/netlink/specs/netdev.yaml        |  4 ++++
>   Documentation/networking/xsk-tx-metadata.rst   |  5 +++++
>   drivers/net/ethernet/stmicro/stmmac/stmmac.h   |  2 ++
>   .../net/ethernet/stmicro/stmmac/stmmac_main.c  | 13 +++++++++++++
>   include/net/xdp_sock.h                         |  9 +++++++++
>   include/net/xdp_sock_drv.h                     |  1 +
>   include/uapi/linux/if_xdp.h                    |  9 +++++++++
>   include/uapi/linux/netdev.h                    |  3 +++
>   net/core/netdev-genl.c                         |  2 ++
>   net/xdp/xsk.c                                  |  3 +++
>   tools/include/uapi/linux/if_xdp.h              |  9 +++++++++
>   tools/include/uapi/linux/netdev.h              |  3 +++
>   tools/net/ynl/generated/netdev-user.c          |  1 +
>   tools/testing/selftests/bpf/xdp_hw_metadata.c  | 18 +++++++++++++++++-
>   14 files changed, 81 insertions(+), 1 deletion(-)
> 


From liting8 at huawei.com  Fri Dec  1 02:48:54 2023
From: liting8 at huawei.com (liting (Q))
Date: Fri, 1 Dec 2023 18:48:54 +0800
Subject: [PATCH] KVM: arm64: fix MPIDR to vcpu index cache to support vcpu
 change at runtime
In-Reply-To: <87il5k8j1p.wl-maz@kernel.org>
References: <20231128135402.1943-1-liting8@huawei.com>
 <87il5k8j1p.wl-maz@kernel.org>
Message-ID: <b6c14068-6ae2-4c25-8308-6ad506e51f74@huawei.com>

On 2023/11/30 3:18, Marc Zyngier wrote:
> On Tue, 28 Nov 2023 13:54:02 +0000,
> l00313349 <liting8 at huawei.com> wrote:
>> From: Ting Li <liting8 at huawei.com>
>>
>> Consider vcpu change at runtime, for example online_vcpus is 8,
>> but only start 2 vcpu threads, MPIDR to vcpu index 0 may be overwrited
>> and vm hangs. When start other vcpu threads, cache will be outdated
>> and always get mismatch.
> If userspace creates two vcpus with the same vcpu_id, and therefore
> the same MPIDR value, that's userspace's problem. Don't do that.
>
> Why should we do anything else?
>
> 	M.
Hi Marc,
Thanks for your reply. Maybe you have misunderstanding about it.
The problem is not two vcpus with the same vcpu_id, but different vcpu_id
have the same MPIDR value in some situation such as vcpu hotplug.
In my case, total vcpu count is 8 but only start 2 vcpu at the beginning,
then vcpu_id 2-7 will get the same MPIDR value 0 with vcpu_id 0, so
index 0 will be overwrited to vcpu_id 7.
Please check, thanks.
Ting Li


From s-vadapalli at ti.com  Fri Dec  1 02:52:44 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Fri, 1 Dec 2023 16:22:44 +0530
Subject: [PATCH v5] PCI: j721e: Delay T_PVPERL+TPERST_CLK before PERST#
 inactive
In-Reply-To: <20230817093619.1079267-1-a-verma1@ti.com>
References: <20230817093619.1079267-1-a-verma1@ti.com>
Message-ID: <c671e9f3-c932-4461-bcfc-3b320bf43483@ti.com>

Hello Lorenzo, Bjorn,

On 17/08/23 15:06, Achal Verma wrote:
> As per the PCIe Card Electromechanical specification REV. 5.0, PERST#
> signal should be de-asserted after minimum 100ms from the time power-rails
> achieve specified operating limits and 100us after reference clock gets
> stable.
> 
> From PCIe Card Electromechanical specification REV. 5.0 section 2.9.2:
> TPVPERL: Power stable to PERST# inactive - 100ms
> TPERST_CLK: REFCLK stable before PERST# inactive - 100us
> 
> Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver")
> Signed-off-by: Achal Verma <a-verma1 at ti.com>
> ---
>  drivers/pci/controller/cadence/pci-j721e.c | 30 +++++++++++-----------
>  drivers/pci/pci.h                          |  3 +++
>  2 files changed, 18 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index e70213c9060a..b09924b010ab 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -34,6 +34,8 @@
>  #define J721E_PCIE_USER_LINKSTATUS	0x14
>  #define LINK_STATUS			GENMASK(1, 0)
>  
> +#define PERST_INACTIVE_US (PCIE_TPVPERL_MS*USEC_PER_MSEC + PCIE_TPERST_CLK_US)

This implementation appears incorrect to me since T_PVPERL already accounts for
T_PERST-CLK according to Figure 2-3 of PCI Express Card Electromechanical
Specification Revision 5.1:
https://members.pcisig.com/wg/PCI-SIG/document/19922

Could you please share your opinion since I wish to post a v6 for this patch,
rebasing it to the latest tree which has the commit:
164f66be0c25 PCI: Add T_PVPERL macro
The macro can be used in the current patch, instead of the PERST_INACTIVE_US macro.

> +
>  enum link_status {
>  	NO_RECEIVERS_DETECTED,
>  	LINK_TRAINING_IN_PROGRESS,
> @@ -359,7 +361,7 @@ static int j721e_pcie_probe(struct platform_device *pdev)
>  	struct j721e_pcie *pcie;
>  	struct cdns_pcie_rc *rc = NULL;
>  	struct cdns_pcie_ep *ep = NULL;
> -	struct gpio_desc *gpiod;
> +	struct gpio_desc *perst_gpiod;
>  	void __iomem *base;
>  	struct clk *clk;
>  	u32 num_lanes;
> @@ -468,11 +470,10 @@ static int j721e_pcie_probe(struct platform_device *pdev)
>  
>  	switch (mode) {
>  	case PCI_MODE_RC:
> -		gpiod = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> -		if (IS_ERR(gpiod)) {
> -			ret = PTR_ERR(gpiod);
> -			if (ret != -EPROBE_DEFER)
> -				dev_err(dev, "Failed to get reset GPIO\n");
> +		perst_gpiod = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> +		if (IS_ERR(perst_gpiod)) {
> +			ret = PTR_ERR(perst_gpiod);
> +			dev_err(dev, "Failed to get reset GPIO\n");
>  			goto err_get_sync;
>  		}
>  
> @@ -498,16 +499,15 @@ static int j721e_pcie_probe(struct platform_device *pdev)
>  
>  		/*
>  		 * "Power Sequencing and Reset Signal Timings" table in
> -		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 3.0
> -		 * indicates PERST# should be deasserted after minimum of 100us
> -		 * once REFCLK is stable. The REFCLK to the connector in RC
> -		 * mode is selected while enabling the PHY. So deassert PERST#
> -		 * after 100 us.
> +		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 5.0
> +		 * indicates PERST# should be deasserted after minimum of 100ms
> +		 * after power rails achieve specified operating limits and
> +		 * 100us after reference clock gets stable.
> +		 * PERST_INACTIVE_US accounts for both delays.
>  		 */
> -		if (gpiod) {
> -			usleep_range(100, 200);
> -			gpiod_set_value_cansleep(gpiod, 1);
> -		}
> +
> +		fsleep(PERST_INACTIVE_US);
> +		gpiod_set_value_cansleep(perst_gpiod, 1);
>  
>  		ret = cdns_pcie_host_setup(rc);
>  		if (ret < 0) {
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index a4c397434057..80d520be34e6 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -13,6 +13,9 @@
>  
>  #define PCIE_LINK_RETRAIN_TIMEOUT_MS	1000
>  
> +#define PCIE_TPVPERL_MS		100	/* see PCIe CEM r5.0, sec 2.9.2 */
> +#define PCIE_TPERST_CLK_US	100
> +
>  extern const unsigned char pcie_link_speed[];
>  extern bool pci_early_dump;
>  

-- 
Regards,
Siddharth.


From tglx at linutronix.de  Fri Dec  1 03:06:31 2023
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 01 Dec 2023 12:06:31 +0100
Subject: [PATCH 08/21] drivers: base: Implement weak arch_unregister_cpu()
In-Reply-To: <E1r5R3H-00CszC-2n@rmk-PC.armlinux.org.uk>
References: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk>
 <E1r5R3H-00CszC-2n@rmk-PC.armlinux.org.uk>
Message-ID: <87sf4mxjuw.ffs@tglx>

On Tue, Nov 21 2023 at 13:44, Russell King wrote:
> ---
> An open question remains from the RFC v2 posting: should we provide a
> __weak stub for !HOTPLUG_CPU as well, since in later patches ACPI may
> reference this if the compiler doesn't optimise as we expect?

You mean:

extern void foo(void);

    if (!IS_ENABLED(CONFIG_FOO))
    	foo();

The kernel uses this pattern for years and if someday a compiler starts
to fail to eliminate the call to 'foo()' for CONFIG_FOO=n then you
already get hundreds linkage fails today.

So adding one more in later patches won't matter much :)



From biju.das.jz at bp.renesas.com  Fri Dec  1 03:08:40 2023
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Fri,  1 Dec 2023 11:08:40 +0000
Subject: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
In-Reply-To: <20231201110840.37408-1-biju.das.jz@bp.renesas.com>
References: <20231201110840.37408-1-biju.das.jz@bp.renesas.com>
Message-ID: <20231201110840.37408-7-biju.das.jz@bp.renesas.com>

Enable the config for the Renesas DA9062 PMIC and RTC, as it is
populated on RZ/G2UL SMARC EVK.

Signed-off-by: Biju Das <biju.das.jz at bp.renesas.com>
---
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5ad2b841aafc..b68b122d1b1e 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -714,6 +714,7 @@ CONFIG_MFD_ALTERA_SYSMGR=y
 CONFIG_MFD_BD9571MWV=y
 CONFIG_MFD_AXP20X_I2C=y
 CONFIG_MFD_AXP20X_RSB=y
+CONFIG_MFD_DA9062=y
 CONFIG_MFD_EXYNOS_LPASS=m
 CONFIG_MFD_HI6421_PMIC=y
 CONFIG_MFD_HI655X_PMIC=y
@@ -1130,6 +1131,7 @@ CONFIG_RTC_DRV_RV8803=m
 CONFIG_RTC_DRV_S5M=y
 CONFIG_RTC_DRV_DS3232=y
 CONFIG_RTC_DRV_PCF2127=m
+CONFIG_RTC_DRV_DA9063=m
 CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_CROS_EC=y
 CONFIG_RTC_DRV_FSL_FTM_ALARM=m
-- 
2.25.1



From lee at kernel.org  Fri Dec  1 03:23:30 2023
From: lee at kernel.org (Lee Jones)
Date: Fri, 1 Dec 2023 11:23:30 +0000
Subject: [PATCH V2 1/2] leds: gpio: Add kernel log if
 devm_fwnode_gpiod_get fails
In-Reply-To: <20231118124252.14838-2-wahrenst@gmx.net>
References: <20231118124252.14838-1-wahrenst@gmx.net>
 <20231118124252.14838-2-wahrenst@gmx.net>
Message-ID: <20231201112330.GD3259151@google.com>

On Sat, 18 Nov 2023, Stefan Wahren wrote:

> In case leds-gpio fails to get the GPIO from the DT (e.g. the GPIO is
> already requested) the driver doesn't provide any helpful error log:
> 
>     leds-gpio: probe of leds failed with error -16
> 
> So add a new error log in case devm_fwnode_gpiod_get() fails.
> 
> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
> ---
>  drivers/leds/leds-gpio.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index 710c319ad312..0159cedffa9e 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -172,6 +172,8 @@ static struct gpio_leds_priv *gpio_leds_create(struct device *dev)
>  		led.gpiod = devm_fwnode_gpiod_get(dev, child, NULL, GPIOD_ASIS,
>  						  NULL);
>  		if (IS_ERR(led.gpiod)) {
> +			dev_err_probe(dev, PTR_ERR(led.gpiod), "Failed to get gpio '%pfw'\n",

Nit: GPIO

> +				      child);
>  			fwnode_handle_put(child);
>  			return ERR_CAST(led.gpiod);
>  		}
> --
> 2.34.1
> 

-- 
Lee Jones [???]


From tglx at linutronix.de  Fri Dec  1 03:25:54 2023
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 01 Dec 2023 12:25:54 +0100
Subject: [PATCH 00/21] Initial cleanups for vCPU hotplug
In-Reply-To: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk>
References: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk>
Message-ID: <87plzqxiyl.ffs@tglx>

Russell!

On Tue, Nov 21 2023 at 13:43, Russell King wrote:
> This series aims to switch most architectures over to using generic CPU
> devices rather than arch specific implementations, which I think is
> worthwhile doing even if the vCPU hotplug series needs further work.

I went through the whole series and I can't find anything
objectionable.

Vs. merging: It does not make sense to split this up and route
individual patches.

So I can pick the whole pile up and route it through tip smp/core unless
Rafael or Greg prefer to take it through one of their trees. For the
latter case:

       Reviewed-by: Thomas Gleixner <tglx at linutronix.de>

Greg, Rafael?

Thanks,

        tglx


From peter.griffin at linaro.org  Fri Dec  1 04:01:16 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 1 Dec 2023 12:01:16 +0000
Subject: [PATCH v4 18/19] arm64: dts: exynos: google: Add initial
 Oriole/pixel 6 board support
In-Reply-To: <CAPLW+4k=M1q1thr2RXG4fGkvD51H7NxS1A3Ck+Up7W1nTcUPcw@mail.gmail.com>
References: <20231120212037.911774-1-peter.griffin@linaro.org>
 <20231120212037.911774-19-peter.griffin@linaro.org> <CAPLW+4k=M1q1thr2RXG4fGkvD51H7NxS1A3Ck+Up7W1nTcUPcw@mail.gmail.com>
Message-ID: <CADrjBPoimnYhB3t5wSCKMTr8MbkDCVXvRmtsGzXrjZCW_7fF5A@mail.gmail.com>

Hi Sam,

On Tue, 21 Nov 2023 at 18:39, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Mon, Nov 20, 2023 at 3:21?PM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > Add initial board support for the Pixel 6 phone code named Oriole. This
> > has been tested with a minimal busybox initramfs and boots to a shell.

Will fix it in v5.

Peter
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  arch/arm64/boot/dts/exynos/Makefile           |  2 +
> >  arch/arm64/boot/dts/exynos/google/Makefile    |  4 +
> >  .../boot/dts/exynos/google/gs101-oriole.dts   | 79 +++++++++++++++++++
> >  3 files changed, 85 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
> >  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> >
> > diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
> > index 6e4ba69268e5..44c24a8ad9e1 100644
> > --- a/arch/arm64/boot/dts/exynos/Makefile
> > +++ b/arch/arm64/boot/dts/exynos/Makefile
> > @@ -1,4 +1,6 @@
> >  # SPDX-License-Identifier: GPL-2.0
> > +subdir-y += google
> > +
> >  dtb-$(CONFIG_ARCH_EXYNOS) += \
> >         exynos5433-tm2.dtb              \
> >         exynos5433-tm2e.dtb             \
> > diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
> > new file mode 100644
> > index 000000000000..0a6d5e1fe4ee
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/google/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +dtb-$(CONFIG_ARCH_EXYNOS) += \
> > +       gs101-oriole.dtb \
> > diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> > new file mode 100644
> > index 000000000000..111665490840
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> > @@ -0,0 +1,79 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Oriole Device Tree
> > + *
> > + * Copyright 2021-2023 Google,LLC
> > + */
> > +
> > +/dts-v1/;
> > +/plugin/;
>
> Now that the dts is being built as a dtb (not dtbo), I don' think this
> /plugin/ bit is needed here?
>
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/input/input.h>
> > +#include "gs101-pinctrl.h"
> > +#include "gs101.dtsi"
> > +
> > +/ {
> > +       model = "Oriole";
> > +       compatible = "google,gs101-oriole", "google,gs101";
> > +
> > +       chosen {
> > +               bootargs = "earlycon=exynos4210,mmio32,0x10A00000 console=ttySAC0";
> > +       };
> > +
> > +       gpio-keys {
> > +               compatible = "gpio-keys";
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&key_voldown>, <&key_volup>, <&key_power>;
> > +
> > +               button-vol-down {
> > +                       label = "KEY_VOLUMEDOWN";
> > +                       linux,code = <KEY_VOLUMEDOWN>;
> > +                       gpios = <&gpa7 3 GPIO_ACTIVE_LOW>;
> > +                       wakeup-source;
> > +               };
> > +
> > +               button-vol-up {
> > +                       label = "KEY_VOLUMEUP";
> > +                       linux,code = <KEY_VOLUMEUP>;
> > +                       gpios = <&gpa8 1 GPIO_ACTIVE_LOW>;
> > +                       wakeup-source;
> > +               };
> > +
> > +               button-power {
> > +                       label = "KEY_POWER";
> > +                       linux,code = <KEY_POWER>;
> > +                       gpios = <&gpa10 1 GPIO_ACTIVE_LOW>;
> > +                       wakeup-source;
> > +               };
> > +       };
> > +};
> > +
> > +&pinctrl_1 {
> > +       key_voldown: key-voldown-pins {
> > +               samsung,pins = "gpa7-3";
> > +               samsung,pin-function = <0xf>;
> > +               samsung,pin-pud = <0>;
> > +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> > +       };
> > +
> > +       key_volup: key-volup-pins {
> > +               samsung,pins = "gpa8-1";
> > +               samsung,pin-function = <0xf>;
> > +               samsung,pin-pud = <0>;
> > +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> > +       };
> > +};
> > +
> > +&pinctrl_0 {
> > +       key_power: key-power-pins {
> > +               samsung,pins = "gpa10-1";
> > +               samsung,pin-function = <0xf>;
> > +               samsung,pin-pud = <0>;
> > +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> > +       };
> > +};
> > +
> > +&watchdog_cl0 {
> > +       timeout-sec = <30>;
> > +};
> > --
> > 2.43.0.rc1.413.gea7ed67945-goog
> >


From linyunsheng at huawei.com  Fri Dec  1 04:02:01 2023
From: linyunsheng at huawei.com (Yunsheng Lin)
Date: Fri, 1 Dec 2023 20:02:01 +0800
Subject: [PATCH RFC 0/6] remove page frag implementation in vhost_net
Message-ID: <20231201120208.15080-1-linyunsheng@huawei.com>

Currently there are three implementations for page frag:

1. mm/page_alloc.c: net stack seems to be using it in the
   rx part with 'struct page_frag_cache' and the main API
   being page_frag_alloc_align().
2. net/core/sock.c: net stack seems to be using it in the
   tx part with 'struct page_frag' and the main API being
   skb_page_frag_refill().
3. drivers/vhost/net.c: vhost seems to be using it to build
   xdp frame, and it's implementation seems to be a mix of
   the above two.

This patch tries to unfiy the page frag implementation a
little bit by unifying gfp bit for order 3 page allocation
and replacing page frag implementation in vhost.c with the
one in page_alloc.c.

After this patchset, we are not only able to unify the page
frag implementation a little, but also able to have about
0.5% performance boost testing by using the vhost_net_test
introduced in the last patch.

Before this patchset:
Performance counter stats for './vhost_net_test' (10 runs):

     305325.78 msec task-clock                       #    1.738 CPUs utilized               ( +-  0.12% )
       1048668      context-switches                 #    3.435 K/sec                       ( +-  0.00% )
            11      cpu-migrations                   #    0.036 /sec                        ( +- 17.64% )
            33      page-faults                      #    0.108 /sec                        ( +-  0.49% )
  244651819491      cycles                           #    0.801 GHz                         ( +-  0.43% )  (64)
   64714638024      stalled-cycles-frontend          #   26.45% frontend cycles idle        ( +-  2.19% )  (67)
   30774313491      stalled-cycles-backend           #   12.58% backend cycles idle         ( +-  7.68% )  (70)
  201749748680      instructions                     #    0.82  insn per cycle            
                                              #    0.32  stalled cycles per insn     ( +-  0.41% )  (66.76%)
   65494787909      branches                         #  214.508 M/sec                       ( +-  0.35% )  (64)
    4284111313      branch-misses                    #    6.54% of all branches             ( +-  0.45% )  (66)

       175.699 +- 0.189 seconds time elapsed  ( +-  0.11% )


After this patchset:
Performance counter stats for './virtio_test' (10 runs):

     303974.38 msec task-clock                       #    1.739 CPUs utilized               ( +-  0.14% )
       1048807      context-switches                 #    3.450 K/sec                       ( +-  0.00% )
            14      cpu-migrations                   #    0.046 /sec                        ( +- 12.86% )
            33      page-faults                      #    0.109 /sec                        ( +-  0.46% )
  251289376347      cycles                           #    0.827 GHz                         ( +-  0.32% )  (60)
   67885175415      stalled-cycles-frontend          #   27.01% frontend cycles idle        ( +-  0.48% )  (63)
   27809282600      stalled-cycles-backend           #   11.07% backend cycles idle         ( +-  0.36% )  (71)
  195543234672      instructions                     #    0.78  insn per cycle            
                                              #    0.35  stalled cycles per insn     ( +-  0.29% )  (69.04%)
   62423183552      branches                         #  205.357 M/sec                       ( +-  0.48% )  (67)
    4135666632      branch-misses                    #    6.63% of all branches             ( +-  0.63% )  (67)

       174.764 +- 0.214 seconds time elapsed  ( +-  0.12% )


Yunsheng Lin (6):
  mm/page_alloc: modify page_frag_alloc_align() to accept align as an
    argument
  page_frag: unify gfp bit for order 3 page allocation
  mm/page_alloc: use initial zero offset for page_frag_alloc_align()
  vhost/net: remove vhost_net_page_frag_refill()
  net: introduce page_frag_cache_drain()
  tools: virtio: introduce vhost_net_test

 drivers/net/ethernet/google/gve/gve_main.c |  11 +-
 drivers/net/ethernet/mediatek/mtk_wed_wo.c |  17 +-
 drivers/nvme/host/tcp.c                    |   7 +-
 drivers/nvme/target/tcp.c                  |   4 +-
 drivers/vhost/net.c                        |  91 ++---
 include/linux/gfp.h                        |   6 +-
 include/linux/skbuff.h                     |  22 +-
 mm/page_alloc.c                            |  48 ++-
 net/core/skbuff.c                          |  14 +-
 net/core/sock.c                            |   2 +-
 tools/virtio/Makefile                      |   8 +-
 tools/virtio/vhost_net_test.c              | 441 +++++++++++++++++++++
 12 files changed, 524 insertions(+), 147 deletions(-)
 create mode 100644 tools/virtio/vhost_net_test.c

-- 
2.33.0



From linyunsheng at huawei.com  Fri Dec  1 04:02:06 2023
From: linyunsheng at huawei.com (Yunsheng Lin)
Date: Fri, 1 Dec 2023 20:02:06 +0800
Subject: [PATCH RFC 5/6] net: introduce page_frag_cache_drain()
In-Reply-To: <20231201120208.15080-1-linyunsheng@huawei.com>
References: <20231201120208.15080-1-linyunsheng@huawei.com>
Message-ID: <20231201120208.15080-6-linyunsheng@huawei.com>

When draining a page_frag_cache, most user are doing
the similar steps, so introduce an API to avoid code
duplication.

Signed-off-by: Yunsheng Lin <linyunsheng at huawei.com>
---
 drivers/net/ethernet/google/gve/gve_main.c | 11 ++---------
 drivers/net/ethernet/mediatek/mtk_wed_wo.c | 17 ++---------------
 drivers/nvme/host/tcp.c                    |  7 +------
 drivers/nvme/target/tcp.c                  |  4 +---
 drivers/vhost/net.c                        |  4 +---
 include/linux/gfp.h                        |  2 ++
 mm/page_alloc.c                            | 10 ++++++++++
 7 files changed, 19 insertions(+), 36 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 619bf63ec935..d976190b0f4d 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -1278,17 +1278,10 @@ static void gve_unreg_xdp_info(struct gve_priv *priv)
 
 static void gve_drain_page_cache(struct gve_priv *priv)
 {
-	struct page_frag_cache *nc;
 	int i;
 
-	for (i = 0; i < priv->rx_cfg.num_queues; i++) {
-		nc = &priv->rx[i].page_cache;
-		if (nc->va) {
-			__page_frag_cache_drain(virt_to_page(nc->va),
-						nc->pagecnt_bias);
-			nc->va = NULL;
-		}
-	}
+	for (i = 0; i < priv->rx_cfg.num_queues; i++)
+		page_frag_cache_drain(&priv->rx[i].page_cache);
 }
 
 static int gve_open(struct net_device *dev)
diff --git a/drivers/net/ethernet/mediatek/mtk_wed_wo.c b/drivers/net/ethernet/mediatek/mtk_wed_wo.c
index 7ffbd4fca881..df0a3ceaf59b 100644
--- a/drivers/net/ethernet/mediatek/mtk_wed_wo.c
+++ b/drivers/net/ethernet/mediatek/mtk_wed_wo.c
@@ -286,7 +286,6 @@ mtk_wed_wo_queue_free(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 static void
 mtk_wed_wo_queue_tx_clean(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 {
-	struct page *page;
 	int i;
 
 	for (i = 0; i < q->n_desc; i++) {
@@ -298,19 +297,12 @@ mtk_wed_wo_queue_tx_clean(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 		entry->buf = NULL;
 	}
 
-	if (!q->cache.va)
-		return;
-
-	page = virt_to_page(q->cache.va);
-	__page_frag_cache_drain(page, q->cache.pagecnt_bias);
-	memset(&q->cache, 0, sizeof(q->cache));
+	page_frag_cache_drain(&q->cache);
 }
 
 static void
 mtk_wed_wo_queue_rx_clean(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 {
-	struct page *page;
-
 	for (;;) {
 		void *buf = mtk_wed_wo_dequeue(wo, q, NULL, true);
 
@@ -320,12 +312,7 @@ mtk_wed_wo_queue_rx_clean(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 		skb_free_frag(buf);
 	}
 
-	if (!q->cache.va)
-		return;
-
-	page = virt_to_page(q->cache.va);
-	__page_frag_cache_drain(page, q->cache.pagecnt_bias);
-	memset(&q->cache, 0, sizeof(q->cache));
+	page_frag_cache_drain(&q->cache);
 }
 
 static void
diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index 89661a9cf850..8d4f4a06f9d9 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -1338,7 +1338,6 @@ static int nvme_tcp_alloc_async_req(struct nvme_tcp_ctrl *ctrl)
 
 static void nvme_tcp_free_queue(struct nvme_ctrl *nctrl, int qid)
 {
-	struct page *page;
 	struct nvme_tcp_ctrl *ctrl = to_tcp_ctrl(nctrl);
 	struct nvme_tcp_queue *queue = &ctrl->queues[qid];
 	unsigned int noreclaim_flag;
@@ -1349,11 +1348,7 @@ static void nvme_tcp_free_queue(struct nvme_ctrl *nctrl, int qid)
 	if (queue->hdr_digest || queue->data_digest)
 		nvme_tcp_free_crypto(queue);
 
-	if (queue->pf_cache.va) {
-		page = virt_to_head_page(queue->pf_cache.va);
-		__page_frag_cache_drain(page, queue->pf_cache.pagecnt_bias);
-		queue->pf_cache.va = NULL;
-	}
+	page_frag_cache_drain(&queue->pf_cache);
 
 	noreclaim_flag = memalloc_noreclaim_save();
 	/* ->sock will be released by fput() */
diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
index 92b74d0b8686..f9a553d70a61 100644
--- a/drivers/nvme/target/tcp.c
+++ b/drivers/nvme/target/tcp.c
@@ -1576,7 +1576,6 @@ static void nvmet_tcp_free_cmd_data_in_buffers(struct nvmet_tcp_queue *queue)
 
 static void nvmet_tcp_release_queue_work(struct work_struct *w)
 {
-	struct page *page;
 	struct nvmet_tcp_queue *queue =
 		container_of(w, struct nvmet_tcp_queue, release_work);
 
@@ -1600,8 +1599,7 @@ static void nvmet_tcp_release_queue_work(struct work_struct *w)
 	if (queue->hdr_digest || queue->data_digest)
 		nvmet_tcp_free_crypto(queue);
 	ida_free(&nvmet_tcp_queue_ida, queue->idx);
-	page = virt_to_head_page(queue->pf_cache.va);
-	__page_frag_cache_drain(page, queue->pf_cache.pagecnt_bias);
+	page_frag_cache_drain(&queue->pf_cache);
 	kfree(queue);
 }
 
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 805e11d598e4..4b2fcb228a0a 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1386,9 +1386,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)
 	kfree(n->vqs[VHOST_NET_VQ_RX].rxq.queue);
 	kfree(n->vqs[VHOST_NET_VQ_TX].xdp);
 	kfree(n->dev.vqs);
-	if (n->pf_cache.va)
-		__page_frag_cache_drain(virt_to_head_page(n->pf_cache.va),
-					n->pf_cache.pagecnt_bias);
+	page_frag_cache_drain(&n->pf_cache);
 	kvfree(n);
 	return 0;
 }
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index bbd75976541e..03ba079655d3 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -316,6 +316,8 @@ extern void *page_frag_alloc_align(struct page_frag_cache *nc,
 				   unsigned int fragsz, gfp_t gfp_mask,
 				   unsigned int align);
 
+void page_frag_cache_drain(struct page_frag_cache *nc);
+
 static inline void *page_frag_alloc(struct page_frag_cache *nc,
 			     unsigned int fragsz, gfp_t gfp_mask)
 {
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 083e0c38fb62..5a0e68edcb05 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4716,6 +4716,16 @@ void __page_frag_cache_drain(struct page *page, unsigned int count)
 }
 EXPORT_SYMBOL(__page_frag_cache_drain);
 
+void page_frag_cache_drain(struct page_frag_cache *nc)
+{
+	if (!nc->va)
+		return;
+
+	__page_frag_cache_drain(virt_to_head_page(nc->va), nc->pagecnt_bias);
+	nc->va = NULL;
+}
+EXPORT_SYMBOL(page_frag_cache_drain);
+
 void *page_frag_alloc_align(struct page_frag_cache *nc,
 		      unsigned int fragsz, gfp_t gfp_mask,
 		      unsigned int align)
-- 
2.33.0



From maz at kernel.org  Fri Dec  1 04:15:56 2023
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 01 Dec 2023 12:15:56 +0000
Subject: [PATCH] KVM: arm64: fix MPIDR to vcpu index cache to support vcpu change at runtime
In-Reply-To: <b6c14068-6ae2-4c25-8308-6ad506e51f74@huawei.com>
References: <20231128135402.1943-1-liting8@huawei.com>
	<87il5k8j1p.wl-maz@kernel.org>
	<b6c14068-6ae2-4c25-8308-6ad506e51f74@huawei.com>
Message-ID: <86y1eeazk3.wl-maz@kernel.org>

Hi Ting,

On Fri, 01 Dec 2023 10:48:54 +0000,
"liting (Q)" <liting8 at huawei.com> wrote:
> 
> On 2023/11/30 3:18, Marc Zyngier wrote:
> > On Tue, 28 Nov 2023 13:54:02 +0000,
> > l00313349 <liting8 at huawei.com> wrote:
> >> From: Ting Li <liting8 at huawei.com>
> >> 
> >> Consider vcpu change at runtime, for example online_vcpus is 8,
> >> but only start 2 vcpu threads, MPIDR to vcpu index 0 may be overwrited
> >> and vm hangs. When start other vcpu threads, cache will be outdated
> >> and always get mismatch.
> > If userspace creates two vcpus with the same vcpu_id, and therefore
> > the same MPIDR value, that's userspace's problem. Don't do that.
> > 
> > Why should we do anything else?
> > 
> > 	M.
> Hi Marc,
> Thanks for your reply. Maybe you have misunderstanding about it.
> The problem is not two vcpus with the same vcpu_id, but different vcpu_id
> have the same MPIDR value in some situation such as vcpu hotplug.

But that's *wrong*. The whole point of MPIDR is that it distinguishes
between CPUs. By definition, MPIDR *must* be unique in the system, and
if you have two vcpus with the same MPIDR, you have a broken VM.

> In my case, total vcpu count is 8 but only start 2 vcpu at the beginning,
> then vcpu_id 2-7 will get the same MPIDR value 0 with vcpu_id 0, so
> index 0 will be overwrited to vcpu_id 7.

And that's wrong as per the letter of the architecture. Here's what it
says: "In an implementation containing multiple PEs, each PE is
identified by a unique affinity value reported by MPIDR_EL1{Aff3,
Aff2, Aff1, Aff0}" (D12.4 Attributability).

You don't have a case here. You are creating a VM that is in complete
violation of the architecture. It is your choice to do so, but don't
expect things to work.

> Please check, thanks.

I did.

	M.

-- 
Without deviation from the norm, progress is not possible.


From geert+renesas at glider.be  Fri Dec  1 04:28:16 2023
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri,  1 Dec 2023 13:28:16 +0100
Subject: [GIT PULL 1/2] Renesas ARM defconfig updates for v6.8
In-Reply-To: <cover.1701433485.git.geert+renesas@glider.be>
References: <cover.1701433485.git.geert+renesas@glider.be>
Message-ID: <cover.1701433487.git.geert+renesas@glider.be>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-defconfig-for-v6.8-tag1

for you to fetch changes up to 7c77368b6c42ec87aed9976288a9b50bccb272a6:

  ARM: shmobile: defconfig: Refresh for v6.7-rc1 (2023-11-27 11:01:01 +0100)

----------------------------------------------------------------
Renesas ARM defconfig updates for v6.8

  - Enable support for the Renesas VersaClock 3 clock generator in the
    arm64 defconfig,
  - Enable support for the Renesas EtherAVB module in the arm multi_v7
    defconfig,
  - Refresh shmobile_defconfig for v6.7-rc1.

----------------------------------------------------------------
Biju Das (1):
      arm64: defconfig: Enable Renesas VersaClock 3 clock generator config

Claudiu Beznea (1):
      ARM: multi_v7_defconfig: Enable CONFIG_RAVB

Geert Uytterhoeven (1):
      ARM: shmobile: defconfig: Refresh for v6.7-rc1

 arch/arm/configs/multi_v7_defconfig | 1 +
 arch/arm/configs/shmobile_defconfig | 1 +
 arch/arm64/configs/defconfig        | 1 +
 3 files changed, 3 insertions(+)


From geert+renesas at glider.be  Fri Dec  1 04:28:15 2023
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri,  1 Dec 2023 13:28:15 +0100
Subject: [GIT PULL 0/2] Renesas SoC updates for v6.8
Message-ID: <cover.1701433485.git.geert+renesas@glider.be>

	Hi SoC folks,

This is my first pull request for the inclusion of Renesas SoC updates
for v6.8.

It consists of 2 parts:

  [GIT PULL 1/2] Renesas ARM defconfig updates for v6.8

    - Enable support for the Renesas VersaClock 3 clock generator in the
      arm64 defconfig,
    - Enable support for the Renesas EtherAVB module in the arm multi_v7
      defconfig,
    - Refresh shmobile_defconfig for v6.7-rc1.

  [GIT PULL 2/2] Renesas DTS updates for v6.8

    - Add FLASH support for the Renesas Marzen and Blanche development
      boards,
    - Add 4-bit TX support for the QSPI FLASHes on the RZ/G2L, RZ/G2LC,
      and RZ/V2L SMARC SoMs,
    - Add SDHI support for the RZ/G3S SMARC development kit,
    - Add LCD support for the Atmark Techno Armadillo-800-EVA development
      board, which requires switching from the legacy frame buffer device
      driver to the DRM driver,
    - Miscellaneous fixes and improvements.

Thanks for pulling!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From geert+renesas at glider.be  Fri Dec  1 04:28:17 2023
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri,  1 Dec 2023 13:28:17 +0100
Subject: [GIT PULL 2/2] Renesas DTS updates for v6.8
In-Reply-To: <cover.1701433485.git.geert+renesas@glider.be>
References: <cover.1701433485.git.geert+renesas@glider.be>
Message-ID: <cover.1701433489.git.geert+renesas@glider.be>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dts-for-v6.8-tag1

for you to fetch changes up to 95d516f3eb96bac466a6bfec28a1e55b8ed5160b:

  ARM: dts: renesas: r9a06g032: Add missing space in compatible (2023-11-28 10:29:11 +0100)

----------------------------------------------------------------
Renesas DTS updates for v6.8

  - Add FLASH support for the Renesas Marzen and Blanche development
    boards,
  - Add 4-bit TX support for the QSPI FLASHes on the RZ/G2L, RZ/G2LC,
    and RZ/V2L SMARC SoMs,
  - Add SDHI support for the RZ/G3S SMARC development kit,
  - Add LCD support for the Atmark Techno Armadillo-800-EVA development
    board, which requires switching from the legacy frame buffer device
    driver to the DRM driver,
  - Miscellaneous fixes and improvements.

----------------------------------------------------------------
Biju Das (2):
      arm64: dts: renesas: rzg2l-smarc-som: Enable 4-bit tx support
      arm64: dts: renesas: rzg2lc-smarc-som: Enable 4-bit tx support

Claudiu Beznea (2):
      arm64: dts: renesas: rzg3s-smarc-som: Enable SDHI2
      arm64: dts: renesas: rzg3s-smarc: Enable SDHI1

Conor Dooley (1):
      riscv: dts: renesas: Convert isa detection to new properties

Geert Uytterhoeven (10):
      ARM: dts: renesas: marzen: Add FLASH node
      ARM: dts: renesas: blanche: Add FLASH node
      ARM: dts: renesas: rcar-gen2: Fix I2C bus demux node names
      ARM: dts: renesas: Add missing ADV751[13] power supply properties
      arm64: dts: renesas: Add missing ADV751[13] power supply properties
      ARM: dts: renesas: iwg22d-sodimm: Fix stmpe node names
      ARM: dts: renesas: marzen: Rename keyboard nodes
      ARM: shmobile: defconfig: Switch to DRM_SHMOBILE
      ARM: dts: renesas: r8a7740: Add LCDC nodes
      ARM: dts: renesas: armadillo800eva: Add LCD panel

Niklas S?derlund (4):
      arm64: dts: renesas: draak: Make HDMI the default video input
      arm64: dts: renesas: draak: Move HDMI bus properties to correct node
      arm64: dts: renesas: r9a09g011: Add missing space in compatible
      ARM: dts: renesas: r9a06g032: Add missing space in compatible

 arch/arm/boot/dts/renesas/iwg20d-q7-dbcm-ca.dtsi   | 15 +++++
 .../boot/dts/renesas/r8a7740-armadillo800eva.dts   | 28 +++++++++-
 arch/arm/boot/dts/renesas/r8a7740.dtsi             | 65 ++++++++++++++++++++++
 .../dts/renesas/r8a7745-iwg22d-sodimm-dbhd-ca.dts  | 15 +++++
 .../arm/boot/dts/renesas/r8a7745-iwg22d-sodimm.dts |  4 +-
 arch/arm/boot/dts/renesas/r8a7779-marzen.dts       | 48 +++++++++++++---
 arch/arm/boot/dts/renesas/r8a7790-lager.dts        | 23 ++++++--
 arch/arm/boot/dts/renesas/r8a7790-stout.dts        | 15 +++++
 arch/arm/boot/dts/renesas/r8a7791-koelsch.dts      | 30 +++++++++-
 arch/arm/boot/dts/renesas/r8a7791-porter.dts       | 26 ++++++++-
 arch/arm/boot/dts/renesas/r8a7792-blanche.dts      | 49 ++++++++++++++++
 arch/arm/boot/dts/renesas/r8a7792-wheat.dts        | 21 +++++++
 arch/arm/boot/dts/renesas/r8a7793-gose.dts         | 28 +++++++++-
 arch/arm/boot/dts/renesas/r8a7794-alt.dts          |  4 +-
 arch/arm/boot/dts/renesas/r8a7794-silk.dts         | 17 +++++-
 arch/arm/boot/dts/renesas/r9a06g032.dtsi           |  2 +-
 arch/arm/configs/shmobile_defconfig                |  5 +-
 arch/arm64/boot/dts/renesas/draak.dtsi             | 32 ++++++-----
 arch/arm64/boot/dts/renesas/ebisu.dtsi             |  6 ++
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts     | 15 +++++
 arch/arm64/boot/dts/renesas/r9a09g011.dtsi         |  2 +-
 arch/arm64/boot/dts/renesas/rzg2l-smarc-som.dtsi   |  1 +
 arch/arm64/boot/dts/renesas/rzg2lc-smarc-som.dtsi  |  1 +
 arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi   | 49 ++++++++++++++++
 arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi       | 65 ++++++++++++++++++++++
 arch/riscv/boot/dts/renesas/r9a07g043f.dtsi        |  4 ++
 26 files changed, 528 insertions(+), 42 deletions(-)


From gregkh at linuxfoundation.org  Fri Dec  1 04:28:59 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 1 Dec 2023 12:28:59 +0000
Subject: [PATCH 00/21] Initial cleanups for vCPU hotplug
In-Reply-To: <87plzqxiyl.ffs@tglx>
References: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk>
 <87plzqxiyl.ffs@tglx>
Message-ID: <2023120131-leotard-deprecate-4e27@gregkh>

On Fri, Dec 01, 2023 at 12:25:54PM +0100, Thomas Gleixner wrote:
> Russell!
> 
> On Tue, Nov 21 2023 at 13:43, Russell King wrote:
> > This series aims to switch most architectures over to using generic CPU
> > devices rather than arch specific implementations, which I think is
> > worthwhile doing even if the vCPU hotplug series needs further work.
> 
> I went through the whole series and I can't find anything
> objectionable.
> 
> Vs. merging: It does not make sense to split this up and route
> individual patches.
> 
> So I can pick the whole pile up and route it through tip smp/core unless
> Rafael or Greg prefer to take it through one of their trees. For the
> latter case:
> 
>        Reviewed-by: Thomas Gleixner <tglx at linutronix.de>
> 
> Greg, Rafael?

I can take them, will do so this weekend when I catch up on patches on a
14+ hour flight...

greg k-h


From fancer.lancer at gmail.com  Fri Dec  1 04:35:02 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Fri, 1 Dec 2023 15:35:02 +0300
Subject: [PATCH v2] net: stmmac: update Rx clk divider for 10M SGMII
In-Reply-To: <20231201100548.12994-1-quic_snehshah@quicinc.com>
References: <20231201100548.12994-1-quic_snehshah@quicinc.com>
Message-ID: <mfcvaq2n2lzsg47nzgk25n5fpmii2ftbx6gkrmz7pkxv6mq4w6@eia6ymhx3wff>

On Fri, Dec 01, 2023 at 03:35:48PM +0530, Sneh Shah wrote:
> SGMII 10MBPS mode needs RX clock divider to avoid drops in Rx.
> Update configure SGMII function with rx clk divider programming.

> [PATCH v2] net: stmmac: update Rx clk divider for 10M SGMII

It would be better to add "dwmac-qcom-ethqos" prefix to the subject
since the patch concerns the Qualcomm Eth MAC only. 

-Serge(y)

> 
> Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> ---
> v2 changelog:
> - Use FIELD_PREP to prepare bifield values in place of GENMASK
> - Add fixes tag
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index d3bf42d0fceb..df6ff8bcdb5c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -34,6 +34,7 @@
>  #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
>  #define RGMII_CONFIG_PROG_SWAP			BIT(1)
>  #define RGMII_CONFIG_DDR_MODE			BIT(0)
> +#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)
>  
>  /* SDCC_HC_REG_DLL_CONFIG fields */
>  #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
> @@ -617,6 +618,9 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  	case SPEED_10:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> +		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
> +			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR, 0x31),
> +			      RGMII_IO_MACRO_CONFIG);
>  		break;
>  	}
>  
> -- 
> 2.17.1
> 
> 


From sudeep.holla at arm.com  Fri Dec  1 04:35:15 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 12:35:15 +0000
Subject: [PATCH V2 1/7] coresight: replicator: Move ACPI support from
 AMBA driver to platform driver
In-Reply-To: <20231201062053.1268492-2-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-2-anshuman.khandual@arm.com>
Message-ID: <20231201123515.gntwvhsxd5nzojn7@bogus>

On Fri, Dec 01, 2023 at 11:50:47AM +0530, Anshuman Khandual wrote:
> Add support for the dynamic replicator device in the platform driver, which
> can then be used on ACPI based platforms. This change would now allow
> runtime power management for repliacator devices on ACPI based systems.
> 
> The driver would try to enable the APB clock if available. Also, rename the
> code to reflect the fact that it now handles both static and dynamic
> replicators.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>

Except the minor nit below which may apply also for few other patches
in the series

Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only

[...]

> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
> index b6be73034996..64de0bee02ec 100644
> --- a/drivers/hwtracing/coresight/coresight-replicator.c
> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
> @@ -38,6 +38,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>  struct replicator_drvdata {
>  	void __iomem		*base;
>  	struct clk		*atclk;
> +	struct clk		*pclk;

[minor nit] Perhaps can be documented as well ?

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Fri Dec  1 04:35:34 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 12:35:34 +0000
Subject: [PATCH V2 2/7] coresight: funnel: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <20231201062053.1268492-3-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-3-anshuman.khandual@arm.com>
Message-ID: <20231201123534.fqtknbabvl3bdhq7@bogus>

On Fri, Dec 01, 2023 at 11:50:48AM +0530, Anshuman Khandual wrote:
> Add support for the dynamic funnel device in the platform driver, which can
> then be used on ACPI based platforms. This change would allow runtime power
> management for ACPI based systems.
> 
> The driver would try to enable the APB clock if available. Also, rename the
> code to reflect the fact that it now handles both static and dynamic
> funnels.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>

Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Fri Dec  1 04:35:51 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 12:35:51 +0000
Subject: [PATCH V2 3/7] coresight: catu: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <20231201062053.1268492-4-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-4-anshuman.khandual@arm.com>
Message-ID: <20231201123551.r3mlywsdccx4rmp7@bogus>

On Fri, Dec 01, 2023 at 11:50:49AM +0530, Anshuman Khandual wrote:
> Add support for the catu devices in a new platform driver, which can then
> be used on ACPI based platforms. This change would now allow runtime power
> management for ACPI based systems. The driver would try to enable the APB
> clock if available.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>

Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Fri Dec  1 04:36:10 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 12:36:10 +0000
Subject: [PATCH V2 4/7] coresight: tpiu: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <20231201062053.1268492-5-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-5-anshuman.khandual@arm.com>
Message-ID: <20231201123610.gezaklgir2mvmfps@bogus>

On Fri, Dec 01, 2023 at 11:50:50AM +0530, Anshuman Khandual wrote:
> Add support for the tpiu device in the platform driver, which can then be
> used on ACPI based platforms. This change would now allow runtime power
> management for ACPI based systems. The driver would try to enable the APB
> clock if available.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>

Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Fri Dec  1 04:36:32 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 12:36:32 +0000
Subject: [PATCH V2 5/7] coresight: tmc: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <20231201062053.1268492-6-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-6-anshuman.khandual@arm.com>
Message-ID: <20231201123632.phwgxjzgz4hhivv4@bogus>

On Fri, Dec 01, 2023 at 11:50:51AM +0530, Anshuman Khandual wrote:
> Add support for the tmc devices in the platform driver, which can then be
> used on ACPI based platforms. This change would now allow runtime power
> management for ACPI based systems. The driver would try to enable the APB
> clock if available.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>

Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Fri Dec  1 04:36:55 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 12:36:55 +0000
Subject: [PATCH V2 6/7] coresight: stm: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <20231201062053.1268492-7-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-7-anshuman.khandual@arm.com>
Message-ID: <20231201123655.qo3nn5fdvxjbsr4z@bogus>

On Fri, Dec 01, 2023 at 11:50:52AM +0530, Anshuman Khandual wrote:
> Add support for the stm devices in the platform driver, which can then be
> used on ACPI based platforms. This change would now allow runtime power
> management for ACPI based systems. The driver would try to enable the APB
> clock if available.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>

Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Fri Dec  1 04:37:13 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 12:37:13 +0000
Subject: [PATCH V2 7/7] coresight: debug: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <20231201062053.1268492-8-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-8-anshuman.khandual@arm.com>
Message-ID: <20231201123713.t4yv2unu4vzh5brp@bogus>

On Fri, Dec 01, 2023 at 11:50:53AM +0530, Anshuman Khandual wrote:
> Add support for the cpu debug devices in a new platform driver, which can
> then be used on ACPI based platforms. This change would now allow runtime
> power management for ACPI based systems. The driver would try to enable
> the APB clock if available.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>

Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes

-- 
Regards,
Sudeep


From sumitg at nvidia.com  Fri Dec  1 05:02:10 2023
From: sumitg at nvidia.com (Sumit Gupta)
Date: Fri, 1 Dec 2023 18:32:10 +0530
Subject: [PATCH v2 2/2] cpufreq: Wire-up arch-flavored freq info into
 cpufreq_verify_current_freq
In-Reply-To: <ZWXy0h/fFfQh+Rhy@arm.com>
References: <20231127160838.1403404-1-beata.michalska@arm.com>
 <20231127160838.1403404-3-beata.michalska@arm.com> <ZWXy0h/fFfQh+Rhy@arm.com>
Message-ID: <3e6077bb-907c-057f-0896-d0a5814a4229@nvidia.com>

Hi Ionela,

>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1756,7 +1756,8 @@ static unsigned int cpufreq_verify_current_freq(struct cpufreq_policy *policy, b
>>   {
>>        unsigned int new_freq;
>>
>> -     new_freq = cpufreq_driver->get(policy->cpu);
>> +     new_freq = arch_freq_get_on_cpu(policy->cpu);
>> +     new_freq = new_freq ?: cpufreq_driver->get(policy->cpu);
> 
> Given that arch_freq_get_on_cpu() is an average frequency, it does not
> seem right to me to trigger the sync & update process of
> cpufreq_verify_current_freq() based on it.
> 
> cpufreq_verify_current_freq() will at least modify the internal state of
> the policy and send PRE and POST notifications, if not do a full frequency
> update, based on this average frequency, which is likely different from
> the current frequency, even beyond the 1MHz threshold.
> 
> While I believe it's okay to return this average frequency in
> cpuinfo_cur_freq, I don't think it should be used as an indication of
> an accurate current frequency, which is what
> cpufreq_verify_current_freq() expects.
> 
> Sumit, can you give more details on the issue at [1] and why this change
> fixes it?
> 
> [1] https://lore.kernel.org/lkml/6a5710f6-bfbb-5dfd-11cd-0cd02220cee7 at nvidia.com/
> 
> Thank you,
> Ionela.
>
cpufreq_verify_current_freq() also updates 'policy->cur' in POST
notification if the frequency from hardware has more delta (out of sync).

As the value from 'cpufreq_driver->get()' is not reliable due to [1],
calling the 'get' hook can update the 'policy->cur' with a wrong value 
when governor starts in cpufreq_start_governor().
And if the frequency is never changed after the governor starts during
boot e.g. when performance governor is set as default, then 
'scaling_cur_freq' always returns wrong value.

Instead, the arch_freq_get_on_cpu() API updates 'policy->cur' with a 
more stable freq value.

[1] https://lore.kernel.org/lkml/20230418113459.12860-7-sumitg at nvidia.com/

Best regards,
Sumit Gupta

>>        if (!new_freq)
>>                return 0;
>>
>> --
>> 2.25.1
>>


From robin.murphy at arm.com  Fri Dec  1 05:07:36 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 1 Dec 2023 13:07:36 +0000
Subject: [PATCH 0/7] dma-mapping: Clean up arch_setup_dma_ops()
In-Reply-To: <20231129203642.GO1312390@ziepe.ca>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <20231129203642.GO1312390@ziepe.ca>
Message-ID: <ae27768f-a6fa-4971-b44c-92899a81a2b7@arm.com>

On 29/11/2023 8:36 pm, Jason Gunthorpe wrote:
> On Wed, Nov 29, 2023 at 05:42:57PM +0000, Robin Murphy wrote:
>> Hi all,
>>
>> Prompted by Jason's proposal[1], here's a first step towards truly
>> unpicking the dma_configure vs. IOMMU mess. As I commented before, we
>> have an awful lot of accumulated cruft and technical debt here making
>> things more complicated than they need to be, and we already have hacks
>> on top of hacks trying to work around it, so polishing those hacks even
>> further is really not a desirable direction of travel. And I do know
>> they're hacks, because I wrote most of them and still remember enough of
>> the context of the time ;)
> 
> I quite like this, I was also looking at getting rid of those other
> parameters.
> 
> I wanted to take smaller steps because it is all pretty hairy.
> 
> One thing that still concerns me is if the FW data restricts the valid
> IOVA window that really should be reflected into the reserved ranges
> and not just dumped into the struct device for use by the DMA API.
> 
> Or, perhaps, viof/iommufd should be using the struct device data to
> generate some additional reserved ranges?
> 
> Either way, I would like to see the dma_iommu and the rest of the
> subsystem agree on what the valid IOVA ranges actually are.

Note that there is some intentional divergence where iommu-dma reserves 
IOVAs matching PCI outbound windows because it knows it wants to avoid 
clashing with potential peer-to-peer addresses and doesn't want to have 
to get into the details of ACS redirect etc., but we don't expose those 
as generic reserved regions because they're firmly a property of the PCI 
host bridge, not of the IOMMU group (and more practically, because we 
did do so briefly and it made QEMU unhappy). I think there may also have 
been some degree of conclusion that it's not the IOMMU API's place to 
get in the way of other domain users trying to do weird P2P stuff if 
they really want to.

Another issue is that the generic dma_range_map strictly represents 
device-specific constraints which may not always be desirable or 
appropriate to apply to a whole group. There wasn't really a conscious 
decision as such, but it kind of works out as why we still only consider 
PCI's bridge->dma_ranges (which comes from the same underlying data), 
since we can at least assume every device behind a bridge accesses 
memory through that bridge and so inherits its restrictions. However I 
don't recall any conscious decision for inbound windows to only be 
considered for DMA domain reservations rather than for proper reserved 
regions - pretty sure that's just a case of that code being added in the 
place where it seemed to fit best at the time (because hey it's more 
host bridge windows and we already have a thing for host bridge windows...)

Thanks,
Robin.


From linus.walleij at linaro.org  Fri Dec  1 05:20:30 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:30 +0100
Subject: [PATCH v2 01/10] ASoC: cs35l32: Drop legacy include
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-1-ee9f9d4655eb@linaro.org>

This driver includes the legacy GPIO API <linux/gpio.h> but
does not use any symbols from it.

Drop the include.

Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 sound/soc/codecs/cs35l32.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/sound/soc/codecs/cs35l32.c b/sound/soc/codecs/cs35l32.c
index 138040618438..d1350ffbf3bd 100644
--- a/sound/soc/codecs/cs35l32.c
+++ b/sound/soc/codecs/cs35l32.c
@@ -13,7 +13,6 @@
 #include <linux/init.h>
 #include <linux/delay.h>
 #include <linux/i2c.h>
-#include <linux/gpio.h>
 #include <linux/regmap.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  1 05:20:29 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:29 +0100
Subject: [PATCH v2 00/10] ASoC: Convert Cirrus codecs to GPIO descriptors
Message-ID: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>

This series walks over the Cirrus Logic ASoC drivers and
clean out the use of legacy GPIO numbers and legacy
GPIO APIs.

The CS4271 affects an ASoC driver for EP93xx which Nikita is
actively working on moving over to device tree, so I don't
know about that patch specifically, but I think the collision
would be max "the file was deleted".

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Changes in v2:
- Add explicit <linux/irq.h> include in the cs35l36 driver, apparently
  the driver useeed this implicitly through the <linux/gpio.h> include.
- Fix commit messages "gpios" -> "reset" on two patches.
- Test builds OK
- Link to v1: https://lore.kernel.org/r/20231129-descriptors-sound-cirrus-v1-0-31aa74425ff8 at linaro.org

---
Linus Walleij (10):
      ASoC: cs35l32: Drop legacy include
      ASoC: cs35l33: Fix GPIO name and drop legacy include
      ASoC: cs35l34: Fix GPIO name and drop legacy include
      ASoC: cs35l35: Drop legacy includes
      ASoC: cs35l36: Drop legacy includes
      ASoC: cs4271: Convert to GPIO descriptors
      ASoC: cirrus: edb93xx: Drop legacy include
      ASoC: cs42l42: Drop legacy include
      ASoC: cs43130: Drop legacy includes
      ASoC: cs4349: Drop legacy include

 arch/arm/mach-ep93xx/edb93xx.c       | 32 +++++++++++++++++++++++++----
 arch/arm/mach-ep93xx/vision_ep9307.c | 12 ++++++++++-
 include/sound/cs4271.h               |  1 -
 sound/soc/cirrus/edb93xx.c           |  1 -
 sound/soc/codecs/cs35l32.c           |  1 -
 sound/soc/codecs/cs35l33.c           |  4 +---
 sound/soc/codecs/cs35l34.c           |  4 +---
 sound/soc/codecs/cs35l35.c           |  2 --
 sound/soc/codecs/cs35l36.c           |  3 +--
 sound/soc/codecs/cs4271.c            | 39 ++++++++++++------------------------
 sound/soc/codecs/cs42l42.c           |  1 -
 sound/soc/codecs/cs42l42.h           |  2 +-
 sound/soc/codecs/cs43130.c           |  2 --
 sound/soc/codecs/cs4349.c            |  1 -
 14 files changed, 56 insertions(+), 49 deletions(-)
---
base-commit: 267aea213ae042f779a8054401a8a5f301518605
change-id: 20231129-descriptors-sound-cirrus-522d9061808e

Best regards,
-- 
Linus Walleij <linus.walleij at linaro.org>



From linus.walleij at linaro.org  Fri Dec  1 05:20:31 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:31 +0100
Subject: [PATCH v2 02/10] ASoC: cs35l33: Fix GPIO name and drop legacy
 include
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-2-ee9f9d4655eb@linaro.org>

This driver includes the legacy GPIO APIs <linux/gpio.h> and
<linux/of_gpio.h> but does not use any symbols from any of
them.

Drop the includes.

Further the driver is requesting "reset-gpios" rather than
just "reset" from the GPIO framework. This is wrong because
the gpiolib core will add "-gpios" before processing the
request from e.g. device tree. Drop the suffix.

The last problem means that the optional RESET GPIO has
never been properly retrieved and used even if it existed,
but nobody noticed.

Fixes: 3333cb7187b9 ("ASoC: cs35l33: Initial commit of the cs35l33 CODEC driver.")
Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 sound/soc/codecs/cs35l33.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/sound/soc/codecs/cs35l33.c b/sound/soc/codecs/cs35l33.c
index 4010a2d33a33..a19a2bafb37c 100644
--- a/sound/soc/codecs/cs35l33.c
+++ b/sound/soc/codecs/cs35l33.c
@@ -22,13 +22,11 @@
 #include <sound/soc-dapm.h>
 #include <sound/initval.h>
 #include <sound/tlv.h>
-#include <linux/gpio.h>
 #include <linux/gpio/consumer.h>
 #include <sound/cs35l33.h>
 #include <linux/pm_runtime.h>
 #include <linux/regulator/consumer.h>
 #include <linux/regulator/machine.h>
-#include <linux/of_gpio.h>
 #include <linux/of.h>
 
 #include "cs35l33.h"
@@ -1165,7 +1163,7 @@ static int cs35l33_i2c_probe(struct i2c_client *i2c_client)
 
 	/* We could issue !RST or skip it based on AMP topology */
 	cs35l33->reset_gpio = devm_gpiod_get_optional(&i2c_client->dev,
-			"reset-gpios", GPIOD_OUT_HIGH);
+			"reset", GPIOD_OUT_HIGH);
 	if (IS_ERR(cs35l33->reset_gpio)) {
 		dev_err(&i2c_client->dev, "%s ERROR: Can't get reset GPIO\n",
 			__func__);

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  1 05:20:32 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:32 +0100
Subject: [PATCH v2 03/10] ASoC: cs35l34: Fix GPIO name and drop legacy
 include
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-3-ee9f9d4655eb@linaro.org>

This driver includes the legacy GPIO APIs <linux/gpio.h> and
<linux/of_gpio.h> but does not use any symbols from any of
them.

Drop the includes.

Further the driver is requesting "reset-gpios" rather than
just "reset" from the GPIO framework. This is wrong because
the gpiolib core will add "-gpios" before processing the
request from e.g. device tree. Drop the suffix.

The last problem means that the optional RESET GPIO has
never been properly retrieved and used even if it existed,
but nobody noticed.

Fixes: c1124c09e103 ("ASoC: cs35l34: Initial commit of the cs35l34 CODEC driver.")
Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 sound/soc/codecs/cs35l34.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/sound/soc/codecs/cs35l34.c b/sound/soc/codecs/cs35l34.c
index e5871736fa29..cca59de66b73 100644
--- a/sound/soc/codecs/cs35l34.c
+++ b/sound/soc/codecs/cs35l34.c
@@ -20,14 +20,12 @@
 #include <linux/regulator/machine.h>
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
-#include <linux/of_gpio.h>
 #include <linux/of_irq.h>
 #include <sound/core.h>
 #include <sound/pcm.h>
 #include <sound/pcm_params.h>
 #include <sound/soc.h>
 #include <sound/soc-dapm.h>
-#include <linux/gpio.h>
 #include <linux/gpio/consumer.h>
 #include <sound/initval.h>
 #include <sound/tlv.h>
@@ -1061,7 +1059,7 @@ static int cs35l34_i2c_probe(struct i2c_client *i2c_client)
 		dev_err(&i2c_client->dev, "Failed to request IRQ: %d\n", ret);
 
 	cs35l34->reset_gpio = devm_gpiod_get_optional(&i2c_client->dev,
-				"reset-gpios", GPIOD_OUT_LOW);
+				"reset", GPIOD_OUT_LOW);
 	if (IS_ERR(cs35l34->reset_gpio)) {
 		ret = PTR_ERR(cs35l34->reset_gpio);
 		goto err_regulator;

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  1 05:20:33 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:33 +0100
Subject: [PATCH v2 04/10] ASoC: cs35l35: Drop legacy includes
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-4-ee9f9d4655eb@linaro.org>

This driver includes the legacy GPIO APIs <linux/gpio.h> and
<linux/of_gpio.h> but does not use any symbols from any of
them.

Drop the includes.

Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 sound/soc/codecs/cs35l35.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/soc/codecs/cs35l35.c b/sound/soc/codecs/cs35l35.c
index 63a538f747d3..ddb7d63213a3 100644
--- a/sound/soc/codecs/cs35l35.c
+++ b/sound/soc/codecs/cs35l35.c
@@ -18,14 +18,12 @@
 #include <linux/regulator/consumer.h>
 #include <linux/gpio/consumer.h>
 #include <linux/of.h>
-#include <linux/of_gpio.h>
 #include <linux/regmap.h>
 #include <sound/core.h>
 #include <sound/pcm.h>
 #include <sound/pcm_params.h>
 #include <sound/soc.h>
 #include <sound/soc-dapm.h>
-#include <linux/gpio.h>
 #include <sound/initval.h>
 #include <sound/tlv.h>
 #include <sound/cs35l35.h>

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  1 05:20:34 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:34 +0100
Subject: [PATCH v2 05/10] ASoC: cs35l36: Drop legacy includes
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-5-ee9f9d4655eb@linaro.org>

This driver includes the legacy GPIO APIs <linux/gpio.h> and
<linux/of_gpio.h> but does not use any symbols from any of
them.

Drop the includes.

Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Add <linux/irq.h> include, apparently the driver relied on this
  being implicitly included from <linux/gpio.h>
---
 sound/soc/codecs/cs35l36.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/codecs/cs35l36.c b/sound/soc/codecs/cs35l36.c
index f2fde6e652b9..f5bd32e434a0 100644
--- a/sound/soc/codecs/cs35l36.c
+++ b/sound/soc/codecs/cs35l36.c
@@ -17,15 +17,14 @@
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
 #include <linux/gpio/consumer.h>
+#include <linux/irq.h>
 #include <linux/of.h>
-#include <linux/of_gpio.h>
 #include <linux/regmap.h>
 #include <sound/core.h>
 #include <sound/pcm.h>
 #include <sound/pcm_params.h>
 #include <sound/soc.h>
 #include <sound/soc-dapm.h>
-#include <linux/gpio.h>
 #include <sound/initval.h>
 #include <sound/tlv.h>
 #include <sound/cs35l36.h>

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  1 05:20:35 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:35 +0100
Subject: [PATCH v2 06/10] ASoC: cs4271: Convert to GPIO descriptors
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-6-ee9f9d4655eb@linaro.org>

This converts the Cirrus CS4271 ASoC codec driver to use
GPIO descriptors.

It turns out that there are two in-kernel users of the platform
data passing mechanism so these are switched over as well.

One locally defined GPIO "gpio_disabled" is declared in the
state struct but completely unused in the driver, so we delete
it.

Reviewed-by: Alexander Sverdlin <alexander.sverdlin at gmail.com>
Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
NB: the affected platform EP93xx is being converted to device tree
I don't know if that is happening in this merge window, but the
colission should be manageable.
---
 arch/arm/mach-ep93xx/edb93xx.c       | 32 +++++++++++++++++++++++++----
 arch/arm/mach-ep93xx/vision_ep9307.c | 12 ++++++++++-
 include/sound/cs4271.h               |  1 -
 sound/soc/codecs/cs4271.c            | 39 ++++++++++++------------------------
 4 files changed, 52 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
index 4b90899a66e9..dbdb822a0100 100644
--- a/arch/arm/mach-ep93xx/edb93xx.c
+++ b/arch/arm/mach-ep93xx/edb93xx.c
@@ -88,7 +88,7 @@ static void __init edb93xx_register_i2c(void)
  * EDB93xx SPI peripheral handling
  *************************************************************************/
 static struct cs4271_platform_data edb93xx_cs4271_data = {
-	.gpio_nreset	= -EINVAL,	/* filled in later */
+	/* Intentionally left blank */
 };
 
 static struct spi_board_info edb93xx_spi_board_info[] __initdata = {
@@ -114,14 +114,38 @@ static struct ep93xx_spi_info edb93xx_spi_info __initdata = {
 	/* Intentionally left blank */
 };
 
+static struct gpiod_lookup_table edb93xx_cs4272_edb9301_gpio_table = {
+	.dev_id = "spi0.0", /* CS0 on SPI0 */
+	.table = {
+		GPIO_LOOKUP("A", 1, "reset", GPIO_ACTIVE_LOW),
+		{ },
+	},
+};
+
+static struct gpiod_lookup_table edb93xx_cs4272_edb9302_gpio_table = {
+	.dev_id = "spi0.0", /* CS0 on SPI0 */
+	.table = {
+		GPIO_LOOKUP("H", 2, "reset", GPIO_ACTIVE_LOW),
+		{ },
+	},
+};
+
+static struct gpiod_lookup_table edb93xx_cs4272_edb9315_gpio_table = {
+	.dev_id = "spi0.0", /* CS0 on SPI0 */
+	.table = {
+		GPIO_LOOKUP("B", 6, "reset", GPIO_ACTIVE_LOW),
+		{ },
+	},
+};
+
 static void __init edb93xx_register_spi(void)
 {
 	if (machine_is_edb9301() || machine_is_edb9302())
-		edb93xx_cs4271_data.gpio_nreset = EP93XX_GPIO_LINE_EGPIO1;
+		gpiod_add_lookup_table(&edb93xx_cs4272_edb9301_gpio_table);
 	else if (machine_is_edb9302a() || machine_is_edb9307a())
-		edb93xx_cs4271_data.gpio_nreset = EP93XX_GPIO_LINE_H(2);
+		gpiod_add_lookup_table(&edb93xx_cs4272_edb9302_gpio_table);
 	else if (machine_is_edb9315a())
-		edb93xx_cs4271_data.gpio_nreset = EP93XX_GPIO_LINE_EGPIO14;
+		gpiod_add_lookup_table(&edb93xx_cs4272_edb9315_gpio_table);
 
 	gpiod_add_lookup_table(&edb93xx_spi_cs_gpio_table);
 	ep93xx_register_spi(&edb93xx_spi_info, edb93xx_spi_board_info,
diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c b/arch/arm/mach-ep93xx/vision_ep9307.c
index 30d9cf3791eb..9471938df64c 100644
--- a/arch/arm/mach-ep93xx/vision_ep9307.c
+++ b/arch/arm/mach-ep93xx/vision_ep9307.c
@@ -164,7 +164,7 @@ static struct i2c_board_info vision_i2c_info[] __initdata = {
  * SPI CS4271 Audio Codec
  *************************************************************************/
 static struct cs4271_platform_data vision_cs4271_data = {
-	.gpio_nreset	= EP93XX_GPIO_LINE_H(2),
+	/* Intentionally left blank */
 };
 
 /*************************************************************************
@@ -241,6 +241,15 @@ static struct spi_board_info vision_spi_board_info[] __initdata = {
 	},
 };
 
+static struct gpiod_lookup_table vision_spi_cs4271_gpio_table = {
+	.dev_id = "spi0.0", /* cs4271 @ CS0 */
+	.table = {
+		/* RESET */
+		GPIO_LOOKUP_IDX("H", 2, NULL, 0, GPIO_ACTIVE_LOW),
+		{ },
+	},
+};
+
 static struct gpiod_lookup_table vision_spi_cs_gpio_table = {
 	.dev_id = "spi0",
 	.table = {
@@ -292,6 +301,7 @@ static void __init vision_init_machine(void)
 
 	ep93xx_register_i2c(vision_i2c_info,
 				ARRAY_SIZE(vision_i2c_info));
+	gpiod_add_lookup_table(&vision_spi_cs4271_gpio_table);
 	gpiod_add_lookup_table(&vision_spi_mmc_gpio_table);
 	gpiod_add_lookup_table(&vision_spi_cs_gpio_table);
 	ep93xx_register_spi(&vision_spi_master, vision_spi_board_info,
diff --git a/include/sound/cs4271.h b/include/sound/cs4271.h
index 6ff23ab48894..5a55d135bdea 100644
--- a/include/sound/cs4271.h
+++ b/include/sound/cs4271.h
@@ -9,7 +9,6 @@
 #define __CS4271_H
 
 struct cs4271_platform_data {
-	int gpio_nreset;	/* GPIO driving Reset pin, if any */
 	bool amutec_eq_bmutec;	/* flag to enable AMUTEC=BMUTEC */
 
 	/*
diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c
index 9e6f8a048dd5..74a84832d958 100644
--- a/sound/soc/codecs/cs4271.c
+++ b/sound/soc/codecs/cs4271.c
@@ -13,9 +13,8 @@
 #include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/of.h>
-#include <linux/of_gpio.h>
 #include <linux/regulator/consumer.h>
 #include <sound/pcm.h>
 #include <sound/soc.h>
@@ -160,9 +159,7 @@ struct cs4271_private {
 	/* Current sample rate for de-emphasis control */
 	int				rate;
 	/* GPIO driving Reset pin, if any */
-	int				gpio_nreset;
-	/* GPIO that disable serial bus, if any */
-	int				gpio_disable;
+	struct gpio_desc		*reset;
 	/* enable soft reset workaround */
 	bool				enable_soft_reset;
 	struct regulator_bulk_data      supplies[ARRAY_SIZE(supply_names)];
@@ -487,12 +484,10 @@ static int cs4271_reset(struct snd_soc_component *component)
 {
 	struct cs4271_private *cs4271 = snd_soc_component_get_drvdata(component);
 
-	if (gpio_is_valid(cs4271->gpio_nreset)) {
-		gpio_direction_output(cs4271->gpio_nreset, 0);
-		mdelay(1);
-		gpio_set_value(cs4271->gpio_nreset, 1);
-		mdelay(1);
-	}
+	gpiod_direction_output(cs4271->reset, 1);
+	mdelay(1);
+	gpiod_set_value(cs4271->reset, 0);
+	mdelay(1);
 
 	return 0;
 }
@@ -612,9 +607,8 @@ static void cs4271_component_remove(struct snd_soc_component *component)
 {
 	struct cs4271_private *cs4271 = snd_soc_component_get_drvdata(component);
 
-	if (gpio_is_valid(cs4271->gpio_nreset))
-		/* Set codec to the reset state */
-		gpio_set_value(cs4271->gpio_nreset, 0);
+	/* Set codec to the reset state */
+	gpiod_set_value(cs4271->reset, 1);
 
 	regcache_mark_dirty(cs4271->regmap);
 	regulator_bulk_disable(ARRAY_SIZE(cs4271->supplies), cs4271->supplies);
@@ -639,7 +633,6 @@ static const struct snd_soc_component_driver soc_component_dev_cs4271 = {
 static int cs4271_common_probe(struct device *dev,
 			       struct cs4271_private **c)
 {
-	struct cs4271_platform_data *cs4271plat = dev->platform_data;
 	struct cs4271_private *cs4271;
 	int i, ret;
 
@@ -647,17 +640,11 @@ static int cs4271_common_probe(struct device *dev,
 	if (!cs4271)
 		return -ENOMEM;
 
-	cs4271->gpio_nreset = of_get_named_gpio(dev->of_node, "reset-gpio", 0);
-
-	if (cs4271plat)
-		cs4271->gpio_nreset = cs4271plat->gpio_nreset;
-
-	if (gpio_is_valid(cs4271->gpio_nreset)) {
-		ret = devm_gpio_request(dev, cs4271->gpio_nreset,
-					"CS4271 Reset");
-		if (ret < 0)
-			return ret;
-	}
+	cs4271->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
+	if (IS_ERR(cs4271->reset))
+		return dev_err_probe(dev, PTR_ERR(cs4271->reset),
+				     "error retrieveing RESET GPIO\n");
+	gpiod_set_consumer_name(cs4271->reset, "CS4271 Reset");
 
 	for (i = 0; i < ARRAY_SIZE(supply_names); i++)
 		cs4271->supplies[i].supply = supply_names[i];

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  1 05:20:37 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:37 +0100
Subject: [PATCH v2 08/10] ASoC: cs42l42: Drop legacy include
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-8-ee9f9d4655eb@linaro.org>

This driver includes the legacy GPIO API <linux/gpio.h> but
does not use any symbols from it.

Drop the include.

Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 sound/soc/codecs/cs42l42.c | 1 -
 sound/soc/codecs/cs42l42.h | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/codecs/cs42l42.c b/sound/soc/codecs/cs42l42.c
index 94bcab812629..2d11c5125f73 100644
--- a/sound/soc/codecs/cs42l42.c
+++ b/sound/soc/codecs/cs42l42.c
@@ -15,7 +15,6 @@
 #include <linux/types.h>
 #include <linux/init.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
 #include <linux/regmap.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
diff --git a/sound/soc/codecs/cs42l42.h b/sound/soc/codecs/cs42l42.h
index 7785125b73ab..3d85ebc59489 100644
--- a/sound/soc/codecs/cs42l42.h
+++ b/sound/soc/codecs/cs42l42.h
@@ -14,7 +14,7 @@
 
 #include <dt-bindings/sound/cs42l42.h>
 #include <linux/device.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/mutex.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  1 05:20:36 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:36 +0100
Subject: [PATCH v2 07/10] ASoC: cirrus: edb93xx: Drop legacy include
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-7-ee9f9d4655eb@linaro.org>

This driver includes the legacy GPIO API <linux/gpio.h> but
does not use any symbols from it.

Drop the include.

Reviewed-by: Alexander Sverdlin <alexander.sverdlin at gmail.com>
Link: https://patchwork.kernel.org/project/alsa-devel/patch/20231122-ep93xx-v5-38-d59a76d5df29 at maquefel.me/
Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 sound/soc/cirrus/edb93xx.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/sound/soc/cirrus/edb93xx.c b/sound/soc/cirrus/edb93xx.c
index 6b6817256331..8bb67d7d2b4b 100644
--- a/sound/soc/cirrus/edb93xx.c
+++ b/sound/soc/cirrus/edb93xx.c
@@ -11,7 +11,6 @@
  */
 
 #include <linux/platform_device.h>
-#include <linux/gpio.h>
 #include <linux/module.h>
 #include <linux/soc/cirrus/ep93xx.h>
 #include <sound/core.h>

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  1 05:20:39 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:39 +0100
Subject: [PATCH v2 10/10] ASoC: cs4349: Drop legacy include
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-10-ee9f9d4655eb@linaro.org>

This driver includes the legacy GPIO API <linux/gpio.h> but
does not use any symbols from it.

Drop the include.

Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 sound/soc/codecs/cs4349.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/sound/soc/codecs/cs4349.c b/sound/soc/codecs/cs4349.c
index 9083228495d4..ca8f21aa4837 100644
--- a/sound/soc/codecs/cs4349.c
+++ b/sound/soc/codecs/cs4349.c
@@ -13,7 +13,6 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
 #include <linux/gpio/consumer.h>
 #include <linux/platform_device.h>
 #include <linux/pm.h>

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  1 05:20:38 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 01 Dec 2023 14:20:38 +0100
Subject: [PATCH v2 09/10] ASoC: cs43130: Drop legacy includes
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <20231201-descriptors-sound-cirrus-v2-9-ee9f9d4655eb@linaro.org>

This driver includes the legacy GPIO APIs <linux/gpio.h> and
<linux/of_gpio.h> but does not use any symbols from any of
them.

Drop the includes.

Acked-by: Charles Keepax <ckeepax at opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 sound/soc/codecs/cs43130.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/soc/codecs/cs43130.c b/sound/soc/codecs/cs43130.c
index 0b40fdfb1825..18933bf04684 100644
--- a/sound/soc/codecs/cs43130.c
+++ b/sound/soc/codecs/cs43130.c
@@ -11,7 +11,6 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/delay.h>
-#include <linux/gpio.h>
 #include <linux/gpio/consumer.h>
 #include <linux/platform_device.h>
 #include <linux/pm.h>
@@ -26,7 +25,6 @@
 #include <sound/soc-dapm.h>
 #include <sound/initval.h>
 #include <sound/tlv.h>
-#include <linux/of_gpio.h>
 #include <linux/regulator/consumer.h>
 #include <linux/pm_runtime.h>
 #include <linux/completion.h>

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Fri Dec  1 05:23:06 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri,  1 Dec 2023 14:23:06 +0100
Subject: [PATCH] dt-bindings: marvell: move MMP boards to common marvell directory
Message-ID: <20231201132306.60753-1-krzysztof.kozlowski@linaro.org>

Marvell board bindings are spread over arm/marvell/ and arm/mrvl/
directories.  Move MMP board bindings from the latter to the former, to
keep all of them together.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/arm/{mrvl/mrvl.yaml => marvell/marvell,mmp.yaml} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename Documentation/devicetree/bindings/arm/{mrvl/mrvl.yaml => marvell/marvell,mmp.yaml} (89%)

diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml b/Documentation/devicetree/bindings/arm/marvell/marvell,mmp.yaml
similarity index 89%
rename from Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
rename to Documentation/devicetree/bindings/arm/marvell/marvell,mmp.yaml
index 4c43eaf3632e..92a667e27ec8 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,mmp.yaml
@@ -1,10 +1,10 @@
 # SPDX-License-Identifier: GPL-2.0
 %YAML 1.2
 ---
-$id: http://devicetree.org/schemas/arm/mrvl/mrvl.yaml#
+$id: http://devicetree.org/schemas/arm/marvell/marvell,mmp.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Marvell Platforms
+title: Marvell MMP Platforms
 
 maintainers:
   - Lubomir Rintel <lkundrak at v3.sk>
-- 
2.34.1



From suzuki.poulose at arm.com  Fri Dec  1 05:41:08 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Fri, 1 Dec 2023 13:41:08 +0000
Subject: [PATCH V2 3/7] coresight: catu: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <20231201062053.1268492-4-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-4-anshuman.khandual@arm.com>
Message-ID: <56e9bc16-7962-46c6-858d-53aa7a6c8555@arm.com>

Hi Anshuman,

On 01/12/2023 06:20, Anshuman Khandual wrote:
> Add support for the catu devices in a new platform driver, which can then
> be used on ACPI based platforms. This change would now allow runtime power
> management for ACPI based systems. The driver would try to enable the APB
> clock if available.

This doesn't talk about the new helper. As such I would prefer that to 
be a separate preparatory patch. See below.

> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Cc: Mike Leach <mike.leach at linaro.org>
> Cc: James Clark <james.clark at arm.com>
> Cc: linux-acpi at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: coresight at lists.linaro.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
>   drivers/acpi/arm64/amba.c                    |   1 -
>   drivers/hwtracing/coresight/coresight-catu.c | 130 ++++++++++++++++---
>   drivers/hwtracing/coresight/coresight-catu.h |   1 +
>   drivers/hwtracing/coresight/coresight-core.c |  29 +++++
>   include/linux/coresight.h                    |   7 +
>   5 files changed, 149 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
> index afb6afb66967..587061b0fd2f 100644
> --- a/drivers/acpi/arm64/amba.c
> +++ b/drivers/acpi/arm64/amba.c
> @@ -27,7 +27,6 @@ static const struct acpi_device_id amba_id_list[] = {
>   	{"ARMHC503", 0}, /* ARM CoreSight Debug */
>   	{"ARMHC979", 0}, /* ARM CoreSight TPIU */
>   	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
> -	{"ARMHC9CA", 0}, /* ARM CoreSight CATU */
>   	{"", 0},
>   };
>   
> diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
> index 3949ded0d4fa..ba5ee7d158dd 100644
> --- a/drivers/hwtracing/coresight/coresight-catu.c
> +++ b/drivers/hwtracing/coresight/coresight-catu.c
> @@ -7,6 +7,8 @@
>    * Author: Suzuki K Poulose <suzuki.poulose at arm.com>
>    */
>   
> +#include <linux/platform_device.h>
> +#include <linux/acpi.h>
>   #include <linux/amba/bus.h>
>   #include <linux/device.h>
>   #include <linux/dma-mapping.h>
> @@ -502,28 +504,20 @@ static const struct coresight_ops catu_ops = {
>   	.helper_ops = &catu_helper_ops,
>   };
>   
> -static int catu_probe(struct amba_device *adev, const struct amba_id *id)
> +static int __catu_probe(struct device *dev, struct resource *res)
>   {
>   	int ret = 0;
>   	u32 dma_mask;
> -	struct catu_drvdata *drvdata;
> +	struct catu_drvdata *drvdata = dev_get_drvdata(dev);
>   	struct coresight_desc catu_desc;
>   	struct coresight_platform_data *pdata = NULL;
> -	struct device *dev = &adev->dev;
>   	void __iomem *base;
>   
>   	catu_desc.name = coresight_alloc_device_name(&catu_devs, dev);
>   	if (!catu_desc.name)
>   		return -ENOMEM;
>   
> -	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> -	if (!drvdata) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> -
> -	dev_set_drvdata(dev, drvdata);
> -	base = devm_ioremap_resource(dev, &adev->res);
> +	base = devm_ioremap_resource(dev, res);
>   	if (IS_ERR(base)) {
>   		ret = PTR_ERR(base);
>   		goto out;
> @@ -568,18 +562,35 @@ static int catu_probe(struct amba_device *adev, const struct amba_id *id)
>   	if (IS_ERR(drvdata->csdev))
>   		ret = PTR_ERR(drvdata->csdev);
>   	else
> -		pm_runtime_put(&adev->dev);
> +		pm_runtime_put(dev);
>   out:
>   	return ret;
>   }
>   
> -static void catu_remove(struct amba_device *adev)
> +static int catu_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> +	struct catu_drvdata *drvdata;
> +
> +	drvdata = devm_kzalloc(&adev->dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (!drvdata)
> +		return -ENOMEM;
> +
> +	amba_set_drvdata(adev, drvdata);
> +	return __catu_probe(&adev->dev, &adev->res);
> +}
> +
> +static void __catu_remove(struct device *dev)
>   {
> -	struct catu_drvdata *drvdata = dev_get_drvdata(&adev->dev);
> +	struct catu_drvdata *drvdata = dev_get_drvdata(dev);
>   
>   	coresight_unregister(drvdata->csdev);
>   }
>   
> +static void catu_remove(struct amba_device *adev)
> +{
> +	__catu_remove(&adev->dev);
> +}
> +
>   static struct amba_id catu_ids[] = {
>   	CS_AMBA_ID(0x000bb9ee),
>   	{},
> @@ -598,13 +609,96 @@ static struct amba_driver catu_driver = {
>   	.id_table			= catu_ids,
>   };
>   
> +static int catu_platform_probe(struct platform_device *pdev)
> +{
> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	struct catu_drvdata *drvdata;
> +	int ret = 0;
> +
> +	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (!drvdata)
> +		return -ENOMEM;
> +
> +	drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
> +	if (IS_ERR(drvdata->pclk))
> +		return -ENODEV;
> +
> +	if (res) {
> +		drvdata->base = devm_ioremap_resource(&pdev->dev, res);
> +		if (IS_ERR(drvdata->base)) {
> +			clk_put(drvdata->pclk);
> +			return PTR_ERR(drvdata->base);
> +		}
> +	}
> +
> +	pm_runtime_get_noresume(&pdev->dev);
> +	pm_runtime_set_active(&pdev->dev);
> +	pm_runtime_enable(&pdev->dev);
> +
> +	dev_set_drvdata(&pdev->dev, drvdata);
> +	ret = __catu_probe(&pdev->dev, res);
> +	if (ret) {
> +		pm_runtime_put_noidle(&pdev->dev);
> +		pm_runtime_disable(&pdev->dev);
> +	}
> +	return ret;
> +}
> +
> +static int catu_platform_remove(struct platform_device *pdev)
> +{
> +	__catu_remove(&pdev->dev);
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int catu_runtime_suspend(struct device *dev)
> +{
> +	struct catu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	if (drvdata->pclk && !IS_ERR_OR_NULL(drvdata->pclk))

Only the second part is needed. IS_ERR_OR_NULL() already checks for NULL.

> +		clk_disable_unprepare(drvdata->pclk);
> +	return 0;
> +}
> +
> +static int catu_runtime_resume(struct device *dev)
> +{
> +	struct catu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	if (drvdata->pclk && !IS_ERR_OR_NULL(drvdata->pclk))

Same here.

> +		clk_prepare_enable(drvdata->pclk);
> +	return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops catu_dev_pm_ops = {
> +	SET_RUNTIME_PM_OPS(catu_runtime_suspend, catu_runtime_resume, NULL)
> +};
> +
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id catu_acpi_ids[] = {
> +	{"ARMHC9CA", 0}, /* ARM CoreSight CATU */
> +	{},
> +};
> +
> +MODULE_DEVICE_TABLE(acpi, catu_acpi_ids);
> +#endif
> +
> +static struct platform_driver catu_platform_driver = {
> +	.probe	= catu_platform_probe,
> +	.remove	= catu_platform_remove,
> +	.driver	= {
> +		.name			= "coresight-catu-platform",
> +		.acpi_match_table	= ACPI_PTR(catu_acpi_ids),
> +		.suppress_bind_attrs	= true,
> +		.pm			= &catu_dev_pm_ops,
> +	},
> +};
> +
>   static int __init catu_init(void)
>   {
>   	int ret;
>   
> -	ret = amba_driver_register(&catu_driver);
> -	if (ret)
> -		pr_info("Error registering catu driver\n");
> +	ret = coresight_init_driver("catu", &catu_driver, &catu_platform_driver);
>   	tmc_etr_set_catu_ops(&etr_catu_buf_ops);
>   	return ret;
>   }
> @@ -612,7 +706,7 @@ static int __init catu_init(void)
>   static void __exit catu_exit(void)
>   {
>   	tmc_etr_remove_catu_ops();
> -	amba_driver_unregister(&catu_driver);
> +	coresight_remove_driver(&catu_driver, &catu_platform_driver);
>   }
>   
>   module_init(catu_init);
> diff --git a/drivers/hwtracing/coresight/coresight-catu.h b/drivers/hwtracing/coresight/coresight-catu.h
> index 442e034bbfba..141feac1c14b 100644
> --- a/drivers/hwtracing/coresight/coresight-catu.h
> +++ b/drivers/hwtracing/coresight/coresight-catu.h
> @@ -61,6 +61,7 @@
>   #define CATU_IRQEN_OFF		0x0
>   
>   struct catu_drvdata {
> +	struct clk *pclk;
>   	void __iomem *base;
>   	struct coresight_device *csdev;
>   	int irq;
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index 9fabe00a40d6..ede9b0723f95 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -1833,6 +1833,35 @@ static void __exit coresight_exit(void)
>   module_init(coresight_init);
>   module_exit(coresight_exit);
>   

---8>---

> +int coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
> +			  struct platform_driver *pdev_drv)
> +{
> +	int ret;
> +
> +	ret = amba_driver_register(amba_drv);
> +	if (ret) {
> +		pr_err("%s: error registering AMBA driver\n", drv);
> +		return ret;
> +	}
> +
> +	ret = platform_driver_register(pdev_drv);
> +	if (!ret)
> +		return 0;
> +
> +	pr_err("%s: error registering platform driver\n", drv);
> +	amba_driver_unregister(amba_drv);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(coresight_init_driver);
> +
> +void coresight_remove_driver(struct amba_driver *amba_drv,
> +			     struct platform_driver *pdev_drv)
> +{
> +	amba_driver_unregister(amba_drv);
> +	platform_driver_unregister(pdev_drv);
> +}
> +EXPORT_SYMBOL_GPL(coresight_remove_driver);

Please could we split this into a separate patch itself ? Also, can we 
not use them for the other components ? funnel, replicator ?


> +
>   MODULE_LICENSE("GPL v2");
>   MODULE_AUTHOR("Pratik Patel <pratikp at codeaurora.org>");
>   MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier at linaro.org>");
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index a269fffaf991..be7fe3793763 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -12,6 +12,8 @@
>   #include <linux/io.h>
>   #include <linux/perf_event.h>
>   #include <linux/sched.h>
> +#include <linux/amba/bus.h>
> +#include <linux/platform_device.h>
>   
>   /* Peripheral id registers (0xFD0-0xFEC) */
>   #define CORESIGHT_PERIPHIDR4	0xfd0
> @@ -597,6 +599,11 @@ void coresight_relaxed_write64(struct coresight_device *csdev,
>   			       u64 val, u32 offset);
>   void coresight_write64(struct coresight_device *csdev, u64 val, u32 offset);
>   
> +int coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
> +			  struct platform_driver *pdev_drv);
> +
> +void coresight_remove_driver(struct amba_driver *amba_drv,
> +			     struct platform_driver *pdev_drv);
>   #else
>   static inline struct coresight_device *
>   coresight_register(struct coresight_desc *desc) { return NULL; }


Suzuki


From geert at linux-m68k.org  Fri Dec  1 05:41:24 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 1 Dec 2023 14:41:24 +0100
Subject: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
In-Reply-To: <20231201110840.37408-7-biju.das.jz@bp.renesas.com>
References: <20231201110840.37408-1-biju.das.jz@bp.renesas.com> <20231201110840.37408-7-biju.das.jz@bp.renesas.com>
Message-ID: <CAMuHMdWh3fTzQP5+mGF3u8LACg-5tQDZcyExvgREpxKd6iee4Q@mail.gmail.com>

Hi Biju,

On Fri, Dec 1, 2023 at 12:09?PM Biju Das <biju.das.jz at bp.renesas.com> wrote:
> Enable the config for the Renesas DA9062 PMIC and RTC, as it is
> populated on RZ/G2UL SMARC EVK.
>
> Signed-off-by: Biju Das <biju.das.jz at bp.renesas.com>

Thanks for your patch!

LGTM, but I would have expected (at least)

    CONFIG_INPUT_DA9063_ONKEY=m

too, cfr. my comments on patch 5/6.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From yoong.siang.song at intel.com  Fri Dec  1 05:43:07 2023
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Fri, 1 Dec 2023 13:43:07 +0000
Subject: [PATCH bpf-next v2 0/3] xsk: TX metadata txtime support
In-Reply-To: <d4f99931-442c-4cd7-b3cf-80d8681a2986@kernel.org>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <d4f99931-442c-4cd7-b3cf-80d8681a2986@kernel.org>
Message-ID: <PH0PR11MB58306C2E50009A6E22F9DAD3D881A@PH0PR11MB5830.namprd11.prod.outlook.com>

On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer <hawk at kernel.org> wrote:
>On 12/1/23 07:24, Song Yoong Siang wrote:
>> This series expands XDP TX metadata framework to include ETF HW offload.
>>
>> Changes since v1:
>> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF)
>> - rename launch-time to txtime
>>
>
>I strongly disagree with this renaming (sorry to disagree with Willem).
>
>The i210 and i225 chips call this LaunchTime in their programmers
>datasheets, and even in the driver code[1].
>
>Using this "txtime" name in the code is also confusing, because how can
>people reading the code know the difference between:
>  - tmo_request_timestamp and tmo_request_txtime
>

Hi Jesper and Willem,

How about using "launch_time" for the flag/variable and
"Earliest TxTime First" for the description/comments?  

Thanks & Regards
Siang

>
>[1]
>https://github.com/xdp-project/xdp-
>project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org
>
>> v1:
>https://patchwork.kernel.org/project/netdevbpf/cover/20231130162028.852006-1-
>yoong.siang.song at intel.com/
>>
>> Song Yoong Siang (3):
>>    xsk: add ETF support to XDP Tx metadata
>>    net: stmmac: Add txtime support to XDP ZC
>>    selftests/bpf: Add txtime to xdp_hw_metadata
>>
>>   Documentation/netlink/specs/netdev.yaml        |  4 ++++
>>   Documentation/networking/xsk-tx-metadata.rst   |  5 +++++
>>   drivers/net/ethernet/stmicro/stmmac/stmmac.h   |  2 ++
>>   .../net/ethernet/stmicro/stmmac/stmmac_main.c  | 13 +++++++++++++
>>   include/net/xdp_sock.h                         |  9 +++++++++
>>   include/net/xdp_sock_drv.h                     |  1 +
>>   include/uapi/linux/if_xdp.h                    |  9 +++++++++
>>   include/uapi/linux/netdev.h                    |  3 +++
>>   net/core/netdev-genl.c                         |  2 ++
>>   net/xdp/xsk.c                                  |  3 +++
>>   tools/include/uapi/linux/if_xdp.h              |  9 +++++++++
>>   tools/include/uapi/linux/netdev.h              |  3 +++
>>   tools/net/ynl/generated/netdev-user.c          |  1 +
>>   tools/testing/selftests/bpf/xdp_hw_metadata.c  | 18 +++++++++++++++++-
>>   14 files changed, 81 insertions(+), 1 deletion(-)
>>

From heiko at sntech.de  Fri Dec  1 05:48:59 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 14:48:59 +0100
Subject: [PATCH] arm64: dts: rockchip: drop interrupt-names property from rk3588s dfi
Message-ID: <20231201134859.322491-1-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

The dfi binding does not specify interrupt names, with the interrupts
just specifying channels 0-x. So drop the unspecified property.

Fixes: 5a6976b1040a ("arm64: dts: rockchip: Add DFI to rk3588s")
Reported-by: Jagan Teki <jagan at edgeble.ai>
Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 7064c0e9179f..8aa0499f9b03 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -1362,7 +1362,6 @@ dfi: dfi at fe060000 {
 			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH 0>,
 			     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH 0>,
 			     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH 0>;
-		interrupt-names = "ch0", "ch1", "ch2", "ch3";
 		rockchip,pmu = <&pmu1grf>;
 	};
 
-- 
2.39.2



From andrew at lunn.ch  Fri Dec  1 05:51:17 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 1 Dec 2023 14:51:17 +0100
Subject: [PATCH] dt-bindings: marvell: move MMP boards to common marvell
 directory
In-Reply-To: <20231201132306.60753-1-krzysztof.kozlowski@linaro.org>
References: <20231201132306.60753-1-krzysztof.kozlowski@linaro.org>
Message-ID: <1e25e2f4-e4b9-4219-a9c2-cb6230a62549@lunn.ch>

On Fri, Dec 01, 2023 at 02:23:06PM +0100, Krzysztof Kozlowski wrote:
> Marvell board bindings are spread over arm/marvell/ and arm/mrvl/
> directories.  Move MMP board bindings from the latter to the former, to
> keep all of them together.

Hi Krzysztof

Did you test get_maintainers.pl? MMP has a different maintainer to
many of the other Marvell SoCs. We want emails going to the correct
Maintainers, and ideally not spamming the others.

	Andrew


From sui.jingfeng at linux.dev  Fri Dec  1 05:57:26 2023
From: sui.jingfeng at linux.dev (Sui Jingfeng)
Date: Fri, 1 Dec 2023 21:57:26 +0800
Subject: [1/8] drm/plane-helper: Move drm_plane_helper_atomic_check() into
 udl
In-Reply-To: <038bc33b-1bc9-4dbc-bea3-d17a3d37abf0@suse.de>
References: <20231128104723.20622-2-tzimmermann@suse.de>
 <9a741d8d-a699-4fe8-af59-f90c91014d01@linux.dev>
 <038bc33b-1bc9-4dbc-bea3-d17a3d37abf0@suse.de>
Message-ID: <af7717b2-cd10-491f-99c1-285016fabf84@linux.dev>

Hi,


On 2023/12/1 16:22, Thomas Zimmermann wrote:
> Hi
>
> Am 01.12.23 um 03:36 schrieb Sui Jingfeng:
>> Hi,
>>
>>
>> On 2023/11/28 18:45, Thomas Zimmermann wrote:
>>> The udl driver is the only caller of drm_plane_helper_atomic_check().
>>> Move the function into the driver. No functional changes.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
>>> ---
>>> ? drivers/gpu/drm/drm_plane_helper.c | 32 
>>> ------------------------------
>>> ? drivers/gpu/drm/udl/udl_modeset.c? | 19 ++++++++++++++++--
>>> ? include/drm/drm_plane_helper.h???? |? 2 --
>>> ? 3 files changed, 17 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
>>> b/drivers/gpu/drm/drm_plane_helper.c
>>> index 5e95089676ff8..7982be4b0306d 100644
>>> --- a/drivers/gpu/drm/drm_plane_helper.c
>>> +++ b/drivers/gpu/drm/drm_plane_helper.c
>>> @@ -279,35 +279,3 @@ void drm_plane_helper_destroy(struct drm_plane 
>>> *plane)
>>> ????? kfree(plane);
>>> ? }
>>> ? EXPORT_SYMBOL(drm_plane_helper_destroy);
>>> -
>>> -/**
>>> - * drm_plane_helper_atomic_check() - Helper to check plane 
>>> atomic-state
>>> - * @plane: plane to check
>>> - * @state: atomic state object
>>> - *
>>> - * Provides a default plane-state check handler for planes whose 
>>> atomic-state
>>> - * scale and positioning are not expected to change since the plane 
>>> is always
>>> - * a fullscreen scanout buffer.
>>> - *
>>> - * This is often the case for the primary plane of simple 
>>> framebuffers. See
>>> - * also drm_crtc_helper_atomic_check() for the respective 
>>> CRTC-state check
>>> - * helper function.
>>> - *
>>> - * RETURNS:
>>> - * Zero on success, or an errno code otherwise.
>>> - */
>>> -int drm_plane_helper_atomic_check(struct drm_plane *plane, struct 
>>> drm_atomic_state *state)
>>> -{
>>> -??? struct drm_plane_state *new_plane_state = 
>>> drm_atomic_get_new_plane_state(state, plane);
>>> -??? struct drm_crtc *new_crtc = new_plane_state->crtc;
>>> -??? struct drm_crtc_state *new_crtc_state = NULL;
>>> -
>>> -??? if (new_crtc)
>>> -??????? new_crtc_state = drm_atomic_get_new_crtc_state(state, 
>>> new_crtc);
>>> -
>>> -??? return drm_atomic_helper_check_plane_state(new_plane_state, 
>>> new_crtc_state,
>>> -?????????????????????????? DRM_PLANE_NO_SCALING,
>>> -?????????????????????????? DRM_PLANE_NO_SCALING,
>>> -?????????????????????????? false, false);
>>> -}
>>> -EXPORT_SYMBOL(drm_plane_helper_atomic_check);
>>
>>
>> Since this function is removed, does the comments of the 
>> drm_crtc_helper_atomic_check()
>> function (in the drm_crtc_helper.c) need to update as well? I'm ask 
>> because I see the
>> comments of the drm_crtc_helper_atomic_check() still referencing this 
>> function.
>
> Good point. I'll update that comment. Thanks for reviewing.
>
OK,? with this trivial problem solved:


Acked-by: Sui Jingfeng <suijingfeng at loongson.cn>


> Best regards
> Thomas
>
>>
>>
>>> diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
>>> b/drivers/gpu/drm/udl/udl_modeset.c
>>> index 40876bcdd79a4..7702359c90c22 100644
>>> --- a/drivers/gpu/drm/udl/udl_modeset.c
>>> +++ b/drivers/gpu/drm/udl/udl_modeset.c
>>> @@ -21,7 +21,6 @@
>>> ? #include <drm/drm_gem_framebuffer_helper.h>
>>> ? #include <drm/drm_gem_shmem_helper.h>
>>> ? #include <drm/drm_modeset_helper_vtables.h>
>>> -#include <drm/drm_plane_helper.h>
>>> ? #include <drm/drm_probe_helper.h>
>>> ? #include <drm/drm_vblank.h>
>>> @@ -261,6 +260,22 @@ static const uint64_t 
>>> udl_primary_plane_fmtmods[] = {
>>> ????? DRM_FORMAT_MOD_INVALID
>>> ? };
>>> +static int udl_primary_plane_helper_atomic_check(struct drm_plane 
>>> *plane,
>>> +???????????????????????? struct drm_atomic_state *state)
>>> +{
>>> +??? struct drm_plane_state *new_plane_state = 
>>> drm_atomic_get_new_plane_state(state, plane);
>>> +??? struct drm_crtc *new_crtc = new_plane_state->crtc;
>>> +??? struct drm_crtc_state *new_crtc_state = NULL;
>>> +
>>> +??? if (new_crtc)
>>> +??????? new_crtc_state = drm_atomic_get_new_crtc_state(state, 
>>> new_crtc);
>>> +
>>> +??? return drm_atomic_helper_check_plane_state(new_plane_state, 
>>> new_crtc_state,
>>> +?????????????????????????? DRM_PLANE_NO_SCALING,
>>> +?????????????????????????? DRM_PLANE_NO_SCALING,
>>> +?????????????????????????? false, false);
>>> +}
>>> +
>>> ? static void udl_primary_plane_helper_atomic_update(struct 
>>> drm_plane *plane,
>>> ???????????????????????????? struct drm_atomic_state *state)
>>> ? {
>>> @@ -296,7 +311,7 @@ static void 
>>> udl_primary_plane_helper_atomic_update(struct drm_plane *plane,
>>> ? static const struct drm_plane_helper_funcs 
>>> udl_primary_plane_helper_funcs = {
>>> ????? DRM_GEM_SHADOW_PLANE_HELPER_FUNCS,
>>> -??? .atomic_check = drm_plane_helper_atomic_check,
>>> +??? .atomic_check = udl_primary_plane_helper_atomic_check,
>>> ????? .atomic_update = udl_primary_plane_helper_atomic_update,
>>> ? };
>>> diff --git a/include/drm/drm_plane_helper.h 
>>> b/include/drm/drm_plane_helper.h
>>> index 3a574e8cd22f4..75f9c4830564a 100644
>>> --- a/include/drm/drm_plane_helper.h
>>> +++ b/include/drm/drm_plane_helper.h
>>> @@ -26,7 +26,6 @@
>>> ? #include <linux/types.h>
>>> -struct drm_atomic_state;
>>> ? struct drm_crtc;
>>> ? struct drm_framebuffer;
>>> ? struct drm_modeset_acquire_ctx;
>>> @@ -42,7 +41,6 @@ int drm_plane_helper_update_primary(struct 
>>> drm_plane *plane, struct drm_crtc *cr
>>> ? int drm_plane_helper_disable_primary(struct drm_plane *plane,
>>> ?????????????????????? struct drm_modeset_acquire_ctx *ctx);
>>> ? void drm_plane_helper_destroy(struct drm_plane *plane);
>>> -int drm_plane_helper_atomic_check(struct drm_plane *plane, struct 
>>> drm_atomic_state *state);
>>> ? /**
>>> ?? * DRM_PLANE_NON_ATOMIC_FUNCS - Default plane functions for 
>>> non-atomic drivers
>


From jgg at ziepe.ca  Fri Dec  1 05:57:43 2023
From: jgg at ziepe.ca (Jason Gunthorpe)
Date: Fri, 1 Dec 2023 09:57:43 -0400
Subject: [PATCH 0/7] dma-mapping: Clean up arch_setup_dma_ops()
In-Reply-To: <ae27768f-a6fa-4971-b44c-92899a81a2b7@arm.com>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <20231129203642.GO1312390@ziepe.ca>
 <ae27768f-a6fa-4971-b44c-92899a81a2b7@arm.com>
Message-ID: <20231201135743.GI1394392@ziepe.ca>

On Fri, Dec 01, 2023 at 01:07:36PM +0000, Robin Murphy wrote:
> On 29/11/2023 8:36 pm, Jason Gunthorpe wrote:
> > On Wed, Nov 29, 2023 at 05:42:57PM +0000, Robin Murphy wrote:
> > > Hi all,
> > > 
> > > Prompted by Jason's proposal[1], here's a first step towards truly
> > > unpicking the dma_configure vs. IOMMU mess. As I commented before, we
> > > have an awful lot of accumulated cruft and technical debt here making
> > > things more complicated than they need to be, and we already have hacks
> > > on top of hacks trying to work around it, so polishing those hacks even
> > > further is really not a desirable direction of travel. And I do know
> > > they're hacks, because I wrote most of them and still remember enough of
> > > the context of the time ;)
> > 
> > I quite like this, I was also looking at getting rid of those other
> > parameters.
> > 
> > I wanted to take smaller steps because it is all pretty hairy.
> > 
> > One thing that still concerns me is if the FW data restricts the valid
> > IOVA window that really should be reflected into the reserved ranges
> > and not just dumped into the struct device for use by the DMA API.
> > 
> > Or, perhaps, viof/iommufd should be using the struct device data to
> > generate some additional reserved ranges?
> > 
> > Either way, I would like to see the dma_iommu and the rest of the
> > subsystem agree on what the valid IOVA ranges actually are.
> 
> Note that there is some intentional divergence where iommu-dma reserves
> IOVAs matching PCI outbound windows because it knows it wants to avoid
> clashing with potential peer-to-peer addresses and doesn't want to have to
> get into the details of ACS redirect etc., but we don't expose those as
> generic reserved regions because they're firmly a property of the PCI host
> bridge, not of the IOMMU group (and more practically, because we did do so
> briefly and it made QEMU unhappy). I think there may also have been some
> degree of conclusion that it's not the IOMMU API's place to get in the way
> of other domain users trying to do weird P2P stuff if they really want to.

I'm not sure this is the fully correct conclusion - eg if today we
take a NIC device on a non-ACS topology and run DPDK through VFIO it
has a chance of failure because some IOVA simply cannot be used by
DPDK for DMA at all.

qemu and kvm are a different situation that want different things. Eg
it would want to identity map the PCI BAR spaces to the IOVA they are
claiming.

It should still somehow carve out any other IOVA that is unusable due
to guest-invisible ACS and reflect it through FW tables into the VM.

I'm starting to see people build non-ACS systems and want it to work
with VFIO and I'm a little worried we have been too loose here.

> bridge and so inherits its restrictions. However I don't recall any
> conscious decision for inbound windows to only be considered for DMA domain
> reservations rather than for proper reserved regions - pretty sure that's
> just a case of that code being added in the place where it seemed to fit
> best at the time (because hey it's more host bridge windows and we already
> have a thing for host bridge windows...)

Yeah, and I don't think anyone actually cared much..

At least as a step it would be nice if the DMA API only restrictions
can come out as a special type of reserved region. Then the caller
could decide if they want to follow them or not. iommufd could provide
an opt-in API to DPDK that matches DMA API's safe IOVA allocator.

Jason


From cristian.marussi at arm.com  Fri Dec  1 05:58:58 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri,  1 Dec 2023 13:58:58 +0000
Subject: [PATCH] firmware: arm_scmi: Add protocol versioning checks
Message-ID: <20231201135858.2367651-1-cristian.marussi@arm.com>

Platform and agent supported protocols versions do not necessarily match.

When talking to an older platform SCMI server, supporting only older
protocol versions, the kernel SCMI agent will downgrade the version of
the used protocol to match the platform one and avoid compatibility issues.

In the case, instead, in which the agent happens to communicate with a
newer platform server which can support newer protocol versions unknown to
the agent, and potentially backward incompatible, the agent currently
carries on, silently, in a best-effort approach.

Note that the SCMI server, by the specification, has no means to explicitly
detect the protocol versions used by the agents, neither it is required to
support multiple, older, protocol versions.

Add an explicit protocol version check to let the agent detect when this
version mismatch happens and warn the user about this condition.

Signed-off-by: Cristian Marussi <cristian.marussi at arm.com>
---
Any suggestion for a more meaningful warn message is very much welcome.
Based on sudeep/for-next/scmi/updates
---
 drivers/firmware/arm_scmi/base.c      |  6 +++++-
 drivers/firmware/arm_scmi/clock.c     |  6 +++++-
 drivers/firmware/arm_scmi/driver.c    | 11 ++++++++++-
 drivers/firmware/arm_scmi/perf.c      |  6 +++++-
 drivers/firmware/arm_scmi/power.c     |  6 +++++-
 drivers/firmware/arm_scmi/powercap.c  |  6 +++++-
 drivers/firmware/arm_scmi/protocols.h |  8 +++++++-
 drivers/firmware/arm_scmi/reset.c     |  6 +++++-
 drivers/firmware/arm_scmi/sensors.c   |  6 +++++-
 drivers/firmware/arm_scmi/system.c    |  6 +++++-
 drivers/firmware/arm_scmi/voltage.c   |  6 +++++-
 11 files changed, 62 insertions(+), 11 deletions(-)

diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
index a52f084a6a87..3f5c89ae5af2 100644
--- a/drivers/firmware/arm_scmi/base.c
+++ b/drivers/firmware/arm_scmi/base.c
@@ -13,6 +13,9 @@
 #include "common.h"
 #include "notify.h"
 
+/* Must be updated only after ALL new features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x20000
+
 #define SCMI_BASE_NUM_SOURCES		1
 #define SCMI_BASE_MAX_CMD_ERR_COUNT	1024
 
@@ -385,7 +388,7 @@ static int scmi_base_protocol_init(const struct scmi_protocol_handle *ph)
 
 	rev->major_ver = PROTOCOL_REV_MAJOR(version),
 	rev->minor_ver = PROTOCOL_REV_MINOR(version);
-	ph->set_priv(ph, rev);
+	ph->set_priv(ph, rev, version);
 
 	ret = scmi_base_attributes_get(ph);
 	if (ret)
@@ -423,6 +426,7 @@ static const struct scmi_protocol scmi_base = {
 	.instance_init = &scmi_base_protocol_init,
 	.ops = NULL,
 	.events = &base_protocol_events,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
 };
 
 DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(base, scmi_base)
diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index 98511a3aa367..5e213faa5fe1 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -12,6 +12,9 @@
 #include "protocols.h"
 #include "notify.h"
 
+/* Must be updated only after ALL new features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x20001
+
 enum scmi_clock_protocol_cmd {
 	CLOCK_ATTRIBUTES = 0x3,
 	CLOCK_DESCRIBE_RATES = 0x4,
@@ -961,7 +964,7 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
 	}
 
 	cinfo->version = version;
-	return ph->set_priv(ph, cinfo);
+	return ph->set_priv(ph, cinfo, version);
 }
 
 static const struct scmi_protocol scmi_clock = {
@@ -970,6 +973,7 @@ static const struct scmi_protocol scmi_clock = {
 	.instance_init = &scmi_clock_protocol_init,
 	.ops = &clk_proto_ops,
 	.events = &clk_protocol_events,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
 };
 
 DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(clock, scmi_clock)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 3eb19ed6f148..46320f627066 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -85,6 +85,7 @@ struct scmi_xfers_info {
  * @gid: A reference for per-protocol devres management.
  * @users: A refcount to track effective users of this protocol.
  * @priv: Reference for optional protocol private data.
+ * @version: Protocol version supported by the platform as detected at runtime.
  * @ph: An embedded protocol handle that will be passed down to protocol
  *	initialization code to identify this instance.
  *
@@ -97,6 +98,7 @@ struct scmi_protocol_instance {
 	void				*gid;
 	refcount_t			users;
 	void				*priv;
+	unsigned int			version;
 	struct scmi_protocol_handle	ph;
 };
 
@@ -1392,15 +1394,17 @@ static int version_get(const struct scmi_protocol_handle *ph, u32 *version)
  *
  * @ph: A reference to the protocol handle.
  * @priv: The private data to set.
+ * @version: The detected protocol version for the core to register.
  *
  * Return: 0 on Success
  */
 static int scmi_set_protocol_priv(const struct scmi_protocol_handle *ph,
-				  void *priv)
+				  void *priv, u32 version)
 {
 	struct scmi_protocol_instance *pi = ph_to_pi(ph);
 
 	pi->priv = priv;
+	pi->version = version;
 
 	return 0;
 }
@@ -1849,6 +1853,11 @@ scmi_alloc_init_protocol_instance(struct scmi_info *info,
 	devres_close_group(handle->dev, pi->gid);
 	dev_dbg(handle->dev, "Initialized protocol: 0x%X\n", pi->proto->id);
 
+	if (pi->version > proto->supported_version)
+		dev_warn(handle->dev,
+			 "Detected UNSUPPORTED version 0x%X for protocol 0x%X. Backward compatibility is NOT assured.\n",
+			 pi->version, pi->proto->id);
+
 	return pi;
 
 clean:
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index 81dd5c5e5533..92fa60127f47 100644
--- a/drivers/firmware/arm_scmi/perf.c
+++ b/drivers/firmware/arm_scmi/perf.c
@@ -24,6 +24,9 @@
 #include "protocols.h"
 #include "notify.h"
 
+/* Must be updated only after ALL new features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x40000
+
 #define MAX_OPPS		32
 
 enum scmi_performance_protocol_cmd {
@@ -1104,7 +1107,7 @@ static int scmi_perf_protocol_init(const struct scmi_protocol_handle *ph)
 	if (ret)
 		return ret;
 
-	return ph->set_priv(ph, pinfo);
+	return ph->set_priv(ph, pinfo, version);
 }
 
 static const struct scmi_protocol scmi_perf = {
@@ -1113,6 +1116,7 @@ static const struct scmi_protocol scmi_perf = {
 	.instance_init = &scmi_perf_protocol_init,
 	.ops = &perf_proto_ops,
 	.events = &perf_protocol_events,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
 };
 
 DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(perf, scmi_perf)
diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
index 077767d6e902..9d0536baeee5 100644
--- a/drivers/firmware/arm_scmi/power.c
+++ b/drivers/firmware/arm_scmi/power.c
@@ -13,6 +13,9 @@
 #include "protocols.h"
 #include "notify.h"
 
+/* Must be updated only after ALL new features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x30000
+
 enum scmi_power_protocol_cmd {
 	POWER_DOMAIN_ATTRIBUTES = 0x3,
 	POWER_STATE_SET = 0x4,
@@ -328,7 +331,7 @@ static int scmi_power_protocol_init(const struct scmi_protocol_handle *ph)
 
 	pinfo->version = version;
 
-	return ph->set_priv(ph, pinfo);
+	return ph->set_priv(ph, pinfo, version);
 }
 
 static const struct scmi_protocol scmi_power = {
@@ -337,6 +340,7 @@ static const struct scmi_protocol scmi_power = {
 	.instance_init = &scmi_power_protocol_init,
 	.ops = &power_proto_ops,
 	.events = &power_protocol_events,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
 };
 
 DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(power, scmi_power)
diff --git a/drivers/firmware/arm_scmi/powercap.c b/drivers/firmware/arm_scmi/powercap.c
index 62a7780fedbb..bb9b1a95139c 100644
--- a/drivers/firmware/arm_scmi/powercap.c
+++ b/drivers/firmware/arm_scmi/powercap.c
@@ -17,6 +17,9 @@
 #include "protocols.h"
 #include "notify.h"
 
+/* Must be updated only after ALL new features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x20000
+
 enum scmi_powercap_protocol_cmd {
 	POWERCAP_DOMAIN_ATTRIBUTES = 0x3,
 	POWERCAP_CAP_GET = 0x4,
@@ -975,7 +978,7 @@ scmi_powercap_protocol_init(const struct scmi_protocol_handle *ph)
 	}
 
 	pinfo->version = version;
-	return ph->set_priv(ph, pinfo);
+	return ph->set_priv(ph, pinfo, version);
 }
 
 static const struct scmi_protocol scmi_powercap = {
@@ -984,6 +987,7 @@ static const struct scmi_protocol scmi_powercap = {
 	.instance_init = &scmi_powercap_protocol_init,
 	.ops = &powercap_proto_ops,
 	.events = &powercap_protocol_events,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
 };
 
 DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(powercap, scmi_powercap)
diff --git a/drivers/firmware/arm_scmi/protocols.h b/drivers/firmware/arm_scmi/protocols.h
index b3c6314bb4b8..e683c26f24eb 100644
--- a/drivers/firmware/arm_scmi/protocols.h
+++ b/drivers/firmware/arm_scmi/protocols.h
@@ -174,7 +174,8 @@ struct scmi_protocol_handle {
 	struct device *dev;
 	const struct scmi_xfer_ops *xops;
 	const struct scmi_proto_helpers_ops *hops;
-	int (*set_priv)(const struct scmi_protocol_handle *ph, void *priv);
+	int (*set_priv)(const struct scmi_protocol_handle *ph, void *priv,
+			u32 version);
 	void *(*get_priv)(const struct scmi_protocol_handle *ph);
 };
 
@@ -311,6 +312,10 @@ typedef int (*scmi_prot_init_ph_fn_t)(const struct scmi_protocol_handle *);
  * @ops: Optional reference to the operations provided by the protocol and
  *	 exposed in scmi_protocol.h.
  * @events: An optional reference to the events supported by this protocol.
+ * @supported_version: The highest version currently supported for this
+ *		       protocol by the agent. Each protocol implementation
+ *		       in the agent is supposed to downgrade to match the
+ *		       protocol version supported by the platform.
  */
 struct scmi_protocol {
 	const u8				id;
@@ -319,6 +324,7 @@ struct scmi_protocol {
 	const scmi_prot_init_ph_fn_t		instance_deinit;
 	const void				*ops;
 	const struct scmi_protocol_events	*events;
+	unsigned int				supported_version;
 };
 
 #define DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(name, proto)	\
diff --git a/drivers/firmware/arm_scmi/reset.c b/drivers/firmware/arm_scmi/reset.c
index 7217fd7c6afa..a28ebdd53700 100644
--- a/drivers/firmware/arm_scmi/reset.c
+++ b/drivers/firmware/arm_scmi/reset.c
@@ -13,6 +13,9 @@
 #include "protocols.h"
 #include "notify.h"
 
+/* Must be updated only after ALL new features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x30000
+
 enum scmi_reset_protocol_cmd {
 	RESET_DOMAIN_ATTRIBUTES = 0x3,
 	RESET = 0x4,
@@ -343,7 +346,7 @@ static int scmi_reset_protocol_init(const struct scmi_protocol_handle *ph)
 	}
 
 	pinfo->version = version;
-	return ph->set_priv(ph, pinfo);
+	return ph->set_priv(ph, pinfo, version);
 }
 
 static const struct scmi_protocol scmi_reset = {
@@ -352,6 +355,7 @@ static const struct scmi_protocol scmi_reset = {
 	.instance_init = &scmi_reset_protocol_init,
 	.ops = &reset_proto_ops,
 	.events = &reset_protocol_events,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
 };
 
 DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(reset, scmi_reset)
diff --git a/drivers/firmware/arm_scmi/sensors.c b/drivers/firmware/arm_scmi/sensors.c
index 9952a7bc6682..c5220b1d6b09 100644
--- a/drivers/firmware/arm_scmi/sensors.c
+++ b/drivers/firmware/arm_scmi/sensors.c
@@ -14,6 +14,9 @@
 #include "protocols.h"
 #include "notify.h"
 
+/* Must be updated only after ALL new features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x30000
+
 #define SCMI_MAX_NUM_SENSOR_AXIS	63
 #define	SCMIv2_SENSOR_PROTOCOL		0x10000
 
@@ -1138,7 +1141,7 @@ static int scmi_sensors_protocol_init(const struct scmi_protocol_handle *ph)
 	if (ret)
 		return ret;
 
-	return ph->set_priv(ph, sinfo);
+	return ph->set_priv(ph, sinfo, version);
 }
 
 static const struct scmi_protocol scmi_sensors = {
@@ -1147,6 +1150,7 @@ static const struct scmi_protocol scmi_sensors = {
 	.instance_init = &scmi_sensors_protocol_init,
 	.ops = &sensor_proto_ops,
 	.events = &sensor_protocol_events,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
 };
 
 DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(sensors, scmi_sensors)
diff --git a/drivers/firmware/arm_scmi/system.c b/drivers/firmware/arm_scmi/system.c
index 9383d7584539..06fd542cfce1 100644
--- a/drivers/firmware/arm_scmi/system.c
+++ b/drivers/firmware/arm_scmi/system.c
@@ -13,6 +13,9 @@
 #include "protocols.h"
 #include "notify.h"
 
+/* Must be updated only after ALL new features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x20000
+
 #define SCMI_SYSTEM_NUM_SOURCES		1
 
 enum scmi_system_protocol_cmd {
@@ -144,7 +147,7 @@ static int scmi_system_protocol_init(const struct scmi_protocol_handle *ph)
 	if (PROTOCOL_REV_MAJOR(pinfo->version) >= 0x2)
 		pinfo->graceful_timeout_supported = true;
 
-	return ph->set_priv(ph, pinfo);
+	return ph->set_priv(ph, pinfo, version);
 }
 
 static const struct scmi_protocol scmi_system = {
@@ -153,6 +156,7 @@ static const struct scmi_protocol scmi_system = {
 	.instance_init = &scmi_system_protocol_init,
 	.ops = NULL,
 	.events = &system_protocol_events,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
 };
 
 DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(system, scmi_system)
diff --git a/drivers/firmware/arm_scmi/voltage.c b/drivers/firmware/arm_scmi/voltage.c
index 36e2df77738c..cb51c61ba31c 100644
--- a/drivers/firmware/arm_scmi/voltage.c
+++ b/drivers/firmware/arm_scmi/voltage.c
@@ -10,6 +10,9 @@
 
 #include "protocols.h"
 
+/* Must be updated only after ALL new features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x20000
+
 #define VOLTAGE_DOMS_NUM_MASK		GENMASK(15, 0)
 #define REMAINING_LEVELS_MASK		GENMASK(31, 16)
 #define RETURNED_LEVELS_MASK		GENMASK(11, 0)
@@ -432,7 +435,7 @@ static int scmi_voltage_protocol_init(const struct scmi_protocol_handle *ph)
 		dev_warn(ph->dev, "No Voltage domains found.\n");
 	}
 
-	return ph->set_priv(ph, vinfo);
+	return ph->set_priv(ph, vinfo, version);
 }
 
 static const struct scmi_protocol scmi_voltage = {
@@ -440,6 +443,7 @@ static const struct scmi_protocol scmi_voltage = {
 	.owner = THIS_MODULE,
 	.instance_init = &scmi_voltage_protocol_init,
 	.ops = &voltage_proto_ops,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
 };
 
 DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(voltage, scmi_voltage)
-- 
2.43.0



From peter.griffin at linaro.org  Fri Dec  1 05:59:31 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 1 Dec 2023 13:59:31 +0000
Subject: [PATCH v3 10/20] clk: samsung: clk-gs101: Add cmu_top registers,
 plls, mux and gates
In-Reply-To: <CAPLW+4m+n-U4cAkJZTeCsoE_e6r1j8srYmVjSLawPWwHi6SEAw@mail.gmail.com>
References: <20231011184823.443959-1-peter.griffin@linaro.org>
 <20231011184823.443959-11-peter.griffin@linaro.org> <aae4e6cd-dcfc-442d-9ed7-d5a73c419ba8@kernel.org>
 <CADrjBPrUsSigThoLU9thmZiaG4690B9-BcZYrBn44K9Fc8z3vg@mail.gmail.com> <CAPLW+4m+n-U4cAkJZTeCsoE_e6r1j8srYmVjSLawPWwHi6SEAw@mail.gmail.com>
Message-ID: <CADrjBPpCNc6RASB8p1MmaLuR46b_MsACyyGFLrnozW0_9oRQ3g@mail.gmail.com>

Hi Sam,

On Wed, 8 Nov 2023 at 17:33, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Tue, Nov 7, 2023 at 7:57?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > Hi Chanwoo,
> >
> > Thanks for your review!
> >
> > On Wed, 18 Oct 2023 at 17:51, Chanwoo Choi <chanwoo at kernel.org> wrote:
> > >
> > > Hi Peter,
> > >
> > > On 23. 10. 12. 03:48, Peter Griffin wrote:
> > > > CMU_TOP is the top level clock management unit which contains PLLs, muxes
> > > > and gates that feed the other clock management units.
> > > >
> > > > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > > > ---
> > > >  drivers/clk/samsung/Kconfig     |    9 +
> > > >  drivers/clk/samsung/Makefile    |    2 +
> > > >  drivers/clk/samsung/clk-gs101.c | 1551 +++++++++++++++++++++++++++++++
> > > >  3 files changed, 1562 insertions(+)
> > > >  create mode 100644 drivers/clk/samsung/clk-gs101.c
> > > >
> > > > diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
> > > > index 76a494e95027..14362ec9c543 100644
> > > > --- a/drivers/clk/samsung/Kconfig
> > > > +++ b/drivers/clk/samsung/Kconfig
> > > > @@ -12,6 +12,7 @@ config COMMON_CLK_SAMSUNG
> > > >       select EXYNOS_5410_COMMON_CLK if ARM && SOC_EXYNOS5410
> > > >       select EXYNOS_5420_COMMON_CLK if ARM && SOC_EXYNOS5420
> > > >       select EXYNOS_ARM64_COMMON_CLK if ARM64 && ARCH_EXYNOS
> > > > +     select GOOGLE_GS101_COMMON_CLK if ARM64 && ARCH_GOOGLE_TENSOR
> > > >       select TESLA_FSD_COMMON_CLK if ARM64 && ARCH_TESLA_FSD
> > > >
> > > >  config S3C64XX_COMMON_CLK
> > > > @@ -95,6 +96,14 @@ config EXYNOS_CLKOUT
> > > >         status of the certains clocks from SoC, but it could also be tied to
> > > >         other devices as an input clock.
> > > >
> > > > +config GOOGLE_GS101_COMMON_CLK
> > > > +     bool "Google gs101 clock controller support" if COMPILE_TEST
> > > > +     depends on COMMON_CLK_SAMSUNG
> > > > +     depends on EXYNOS_ARM64_COMMON_CLK
> > > > +     help
> > > > +       Support for the clock controller present on the Google gs101 SoC.
> > > > +       Choose Y here only if you build for this SoC.
> > > > +
> > >
> > > (snip)
> > >
> > > > +
> > > > +/* gs101 */
> > > > +static const struct samsung_mux_clock cmu_top_mux_clks[] __initconst = {
> > > > +     /* CMU_TOP_PURECLKCOMP */
> > > > +     MUX(CLK_MOUT_SHARED0_PLL, "mout_shared0_pll", mout_shared0_pll_p,
> > > > +         PLL_CON0_PLL_SHARED0, 4, 1),
> > > > +     MUX(CLK_MOUT_SHARED1_PLL, "mout_shared1_pll", mout_shared1_pll_p,
> > > > +         PLL_CON0_PLL_SHARED1, 4, 1),
> > > > +     MUX(CLK_MOUT_SHARED2_PLL, "mout_shared2_pll", mout_shared2_pll_p,
> > > > +         PLL_CON0_PLL_SHARED2, 4, 1),
> > > > +     MUX(CLK_MOUT_SHARED3_PLL, "mout_shared3_pll", mout_shared3_pll_p,
> > > > +         PLL_CON0_PLL_SHARED3, 4, 1),
> > > > +     MUX(CLK_MOUT_SPARE_PLL, "mout_spare_pll", mout_spare_pll_p,
> > > > +         PLL_CON0_PLL_SPARE, 4, 1),
> > > > +
> > > > +     /* BUS0 */
> > > > +     MUX(CLK_MOUT_BUS0_BUS, "mout_cmu_bus0_bus", mout_cmu_bus0_bus_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_BUS0_BUS, 0, 2),
> > > > +     MUX(CLK_MOUT_CMU_BOOST, "mout_cmu_boost", mout_cmu_cmu_boost_p,
> > >
> > > In order to keep the consistent naming style,
> > > I think that need to change from 'mout_cmu_boost' to 'mout_cmu_cmu_boost'.
> >
> > Yes, that's a good point, and a good spot! Will fix it in v4.
> >
>
> Why do we need cmu_cmu part at all? From the look of it, renaming all
> *_cmu_cmu_* clocks to just cmu wouldn't cause any naming conflicts. So
> I don't see any benefit of double cmu prefix really.

The benefit is consistency, as Chanwoo pointed out.

>
> > >
> > > > +         CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST, 0, 2),
> > > > +
> > > > +     /* BUS1 */
> > > > +     MUX(CLK_MOUT_BUS1_BUS, "mout_cmu_bus1_bus", mout_cmu_bus1_bus_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_BUS1_BUS, 0, 2),
> > > > +
> > > > +     /* BUS2 */
> > > > +     MUX(CLK_MOUT_BUS2_BUS, "mout_cmu_bus2_bus", mout_cmu_bus2_bus_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_BUS2_BUS, 0, 2),
> > > > +
> > > > +     /* CORE */
> > > > +     MUX(CLK_MOUT_CORE_BUS, "mout_cmu_core_bus", mout_cmu_core_bus_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_CORE_BUS, 0, 2),
> > > > +
> > > > +     /* EH */
> > > > +     MUX(CLK_MOUT_EH_BUS, "mout_cmu_eh_bus", mout_cmu_eh_bus_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_CORE_BUS, 0, 2),
> > >
> > > 'mout_cmu_core_bus' and 'mout_cmu_eh_bus' uses the same register/shift/width information.
> > > I think it should be modified by changing the regiter or changing the shift/width information.
> >
> > It should be using the CLK_CON_MUX_MUX_CLKCMU_EH_BUS register.
> > Will fix it in v4.
> >
> > >
> > > > +
> > > > +     /* CPUCL{0,1,2,} */
> > > > +     MUX(CLK_MOUT_CPUCL2_SWITCH, "mout_cmu_cpucl2_switch", mout_cmu_cpucl2_switch_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_CPUCL2_SWITCH, 0, 2),
> > > > +
> > > > +     MUX(CLK_MOUT_CPUCL1_SWITCH, "mout_cmu_cpucl1_switch", mout_cmu_cpucl1_switch_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_CPUCL1_SWITCH, 0, 2),
> > > > +
> > > > +     MUX(CLK_MOUT_CPUCL0_SWITCH, "mout_cmu_cpucl0_switch", mout_cmu_cpucl0_switch_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_CPUCL0_SWITCH, 0, 2),
> > > > +
> > > > +     MUX(CLK_MOUT_CPUCL0_DBG, "mout_cmu_cpucl0_dbg", mout_cmu_cpucl0_dbg_p,
> > > > +         CLK_CON_DIV_CLKCMU_CPUCL0_DBG, 0, 2),
> > > > +
> > > > +     MUX(CLK_MOUT_CMU_HPM, "mout_cmu_hpm", mout_cmu_hpm_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_HPM, 0, 2),
> > > >
> > >
> > > (snip)
> > >
> > > > +     /* PDP */
> > > > +     MUX(CLK_MOUT_PDP_BUS, "mout_cmu_pdp_bus", mout_cmu_pdp_bus_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_PDP_BUS, 0, 2),
> > > > +
> > > > +     /* PDP */
> > > > +     MUX(CLK_MOUT_PDP_VRA, "mout_cmu_pdp_vra", mout_cmu_pdp_vra_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_PDP_VRA, 0, 2),
> > > > +
> > > > +     /* IPP */
> > > > +     MUX(CLK_MOUT_IPP_BUS, "mout_cmu_ipp_bus", mout_cmu_ipp_bus_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_IPP_BUS, 0, 2),
> > > > +
> > > > +     /* G3AA */
> > > > +     MUX(CLK_MOUT_G3AA, "mout_cmu_g3aa", mout_cmu_g3aa_p,
> > > > +         CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 0, 2),
> > >
> > > I think that need to change the mux name and mux parent name
> > > because other mux name use the twice word according to the register name
> > > even if use the same work such as 'mout_cmu_g2d_g2d', 'mout_cmu_mcsc_mcsc' and 'mout_cmu_mfc_mfc'.
> > > - mout_cmu_g3aa -> mout_cmu_g3aa_g3aa
> > > - mout_cmu_g3aa_p -> mount_cmu_g3aa_g3aa_p
> >
> > Will fix in v4
> >
>
> That consistent name duplication, while not causing any conflicts when
> being removed, looks suspicious to me. That's probably some internal
> scheme which doesn't make much sense for us and doesn't bring any
> value, in terms of clock drivers. Maybe it'll be better to instead get
> rid of such duplication throughout the driver, at least for clock name
> strings? I mention this, because that's what I did in clk-exynos850.
> With the only exception being the main domain clocks, which basically
> enables/disables the whole unit internally, e.g.
>
>     GATE(CLK_GOUT_G3D_CMU_G3D_PCLK, "gout_g3d_cmu_g3d_pclk", ...
>
> which "G3D domain gate clock that enables/disables G3D", or something
> like that. But clk-exynos850 doesn't have any duplicating bits like
> "cmu_cmu" or "g3d_g3d". And the reason why I did that is I wanted
> those clock names appear short and nice in device tree, as there were
> no benefits in those duplicating bits.

I did start out doing something similar, but decided it was a bad
idea. The value of consistent naming and being able to more easily
cross reference and verify correctness with the TRM for me far
outweighs the advantage of having a shorter name. There are literally
thousands of clocks we need to expose in this SoC to have everything
fully modelled and having these various "exceptions" where we change
the naming scheme of the clock because of a duplicated word IMO isn't
helpful.

Peter


>
> > >
> > > (snip)
> > >
> > > > +     /* CSIS */
> > > > +     GATE(CLK_GOUT_CSIS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
> > > > +          CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS, 21, 0, 0),
> > > > +     /* PDP */
> > > > +     GATE(CLK_GOUT_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
> > > > +          CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
> > > > +
> > > > +     GATE(CLK_GOUT_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
> > > > +          CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
> > > > +
> > > > +     /* IPP */
> > > > +     GATE(CLK_GOUT_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
> > > > +          CLK_CON_GAT_GATE_CLKCMU_IPP_BUS, 21, 0, 0),
> > > > +     /* G3AA */
> > > > +     GATE(CLK_GOUT_G3AA, "gout_cmu_g3aa", "mout_cmu_g3aa",
> > > > +          CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 21, 0, 0),
> > >
> > > ditto.
> > > gout_cmu_g3aa -> gout_cmu_g3aa_g3aa
> > > mout_cmu_g3aa -> mout_cmu_g3aa_g3aa
> >
>
> Ditto.
>
> > Will fix in V4
> >
> > regards,
> >
> > Peter.


From paul.elder at ideasonboard.com  Fri Dec  1 06:04:30 2023
From: paul.elder at ideasonboard.com (Paul Elder)
Date: Fri,  1 Dec 2023 23:04:30 +0900
Subject: [PATCH v2 1/4] media: rkisp1: regs: Consolidate MI interrupt wrap fields
In-Reply-To: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
References: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
Message-ID: <20231201140433.2126011-2-paul.elder@ideasonboard.com>

Consolidate the wraparound fields in the memory interface interrupt
status registers, so that it can be more succinctly expressed by taking
the stream ID (main or self) as a parameter.

Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
index 350f452e676f..bea69a0d766a 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
@@ -172,12 +172,9 @@
 #define RKISP1_CIF_MI_FRAME(stream)			BIT((stream)->id)
 #define RKISP1_CIF_MI_MBLK_LINE				BIT(2)
 #define RKISP1_CIF_MI_FILL_MP_Y				BIT(3)
-#define RKISP1_CIF_MI_WRAP_MP_Y				BIT(4)
-#define RKISP1_CIF_MI_WRAP_MP_CB			BIT(5)
-#define RKISP1_CIF_MI_WRAP_MP_CR			BIT(6)
-#define RKISP1_CIF_MI_WRAP_SP_Y				BIT(7)
-#define RKISP1_CIF_MI_WRAP_SP_CB			BIT(8)
-#define RKISP1_CIF_MI_WRAP_SP_CR			BIT(9)
+#define RKISP1_CIF_MI_WRAP_Y(stream)			BIT(4 + (stream)->id * 3)
+#define RKISP1_CIF_MI_WRAP_CB(stream)			BIT(5 + (stream)->id * 3)
+#define RKISP1_CIF_MI_WRAP_CR(stream)			BIT(6 + (stream)->id * 3)
 #define RKISP1_CIF_MI_DMA_READY				BIT(11)
 
 /* MI_STATUS */
-- 
2.39.2



From paul.elder at ideasonboard.com  Fri Dec  1 06:04:31 2023
From: paul.elder at ideasonboard.com (Paul Elder)
Date: Fri,  1 Dec 2023 23:04:31 +0900
Subject: [PATCH v2 2/4] media: rkisp1: debug: Add register dump for IS
In-Reply-To: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
References: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
Message-ID: <20231201140433.2126011-3-paul.elder@ideasonboard.com>

Add register dump for the ISP image stabilizer module to debugfs. This
helps debugging issues related to digital zoom.

Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
Tested-by: Alexander Stein <alexander.stein at ew.tq-group.com>
Reviewed-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

---
Changes in v2:
- Move from IS debugfs file into the ISP debugfs file

 drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
index 71df3dc95e6f..d2fbed42164e 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
@@ -92,6 +92,10 @@ static int rkisp1_debug_dump_isp_regs_show(struct seq_file *m, void *p)
 		RKISP1_DEBUG_REG(ISP_FLAGS_SHD),
 		RKISP1_DEBUG_REG(ISP_RIS),
 		RKISP1_DEBUG_REG(ISP_ERR),
+		RKISP1_DEBUG_SHD_REG(ISP_IS_H_OFFS),
+		RKISP1_DEBUG_SHD_REG(ISP_IS_V_OFFS),
+		RKISP1_DEBUG_SHD_REG(ISP_IS_H_SIZE),
+		RKISP1_DEBUG_SHD_REG(ISP_IS_V_SIZE),
 		{ /* Sentinel */ },
 	};
 	struct rkisp1_device *rkisp1 = m->private;
-- 
2.39.2



From paul.elder at ideasonboard.com  Fri Dec  1 06:04:32 2023
From: paul.elder at ideasonboard.com (Paul Elder)
Date: Fri,  1 Dec 2023 23:04:32 +0900
Subject: [PATCH v2 3/4] media: rkisp1: debug: Count completed frame interrupts
In-Reply-To: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
References: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
Message-ID: <20231201140433.2126011-4-paul.elder@ideasonboard.com>

Add a counter to debugfs to count the number of frame-end interrupts.

Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
Reviewed-by: Alexander Stein <alexander.stein at ew.tq-group.com>
Reviewed-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-common.h | 1 +
 drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c  | 2 ++
 drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c    | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
index 1e7cea1bea5e..be69173958a4 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
@@ -417,6 +417,7 @@ struct rkisp1_debug {
 	unsigned long stats_error;
 	unsigned long stop_timeout[2];
 	unsigned long frame_drop[2];
+	unsigned long complete_frames;
 };
 
 /*
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
index d2fbed42164e..79cda589d935 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
@@ -221,6 +221,8 @@ void rkisp1_debug_init(struct rkisp1_device *rkisp1)
 			     &debug->frame_drop[RKISP1_MAINPATH]);
 	debugfs_create_ulong("sp_frame_drop", 0444, debug->debugfs_dir,
 			     &debug->frame_drop[RKISP1_SELFPATH]);
+	debugfs_create_ulong("complete_frames", 0444, debug->debugfs_dir,
+			     &debug->complete_frames);
 	debugfs_create_file("input_status", 0444, debug->debugfs_dir, rkisp1,
 			    &rkisp1_debug_input_status_fops);
 
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
index 88ca8b2283b7..bd3acd926410 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
@@ -989,6 +989,8 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
 	if (status & RKISP1_CIF_ISP_FRAME) {
 		u32 isp_ris;
 
+		rkisp1->debug.complete_frames++;
+
 		/* New frame from the sensor received */
 		isp_ris = rkisp1_read(rkisp1, RKISP1_CIF_ISP_RIS);
 		if (isp_ris & RKISP1_STATS_MEAS_MASK)
-- 
2.39.2



From paul.elder at ideasonboard.com  Fri Dec  1 06:04:33 2023
From: paul.elder at ideasonboard.com (Paul Elder)
Date: Fri,  1 Dec 2023 23:04:33 +0900
Subject: [PATCH v2 4/4] media: rkisp1: debug: Consolidate counter debugfs files
In-Reply-To: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
References: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
Message-ID: <20231201140433.2126011-5-paul.elder@ideasonboard.com>

Consolidate all the debugfs files that were each a single counter into a
single "counters" file.

While at it, reset the counters at stream on time to make it easier for
to interpret the values in userspace.

Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>

---
New in v2

 .../platform/rockchip/rkisp1/rkisp1-capture.c |  2 +
 .../platform/rockchip/rkisp1/rkisp1-common.h  |  4 ++
 .../platform/rockchip/rkisp1/rkisp1-debug.c   | 69 ++++++++++++-------
 3 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index c6d7e01c8949..67b2e94dfd67 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -1030,6 +1030,8 @@ rkisp1_vb2_start_streaming(struct vb2_queue *queue, unsigned int count)
 	struct media_entity *entity = &cap->vnode.vdev.entity;
 	int ret;
 
+	rkisp1_debug_reset_counters(cap->rkisp1);
+
 	mutex_lock(&cap->rkisp1->stream_lock);
 
 	ret = video_device_pipeline_start(&cap->vnode.vdev, &cap->rkisp1->pipe);
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
index be69173958a4..789259fb304a 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
@@ -599,9 +599,13 @@ int rkisp1_params_register(struct rkisp1_device *rkisp1);
 void rkisp1_params_unregister(struct rkisp1_device *rkisp1);
 
 #if IS_ENABLED(CONFIG_DEBUG_FS)
+void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1);
 void rkisp1_debug_init(struct rkisp1_device *rkisp1);
 void rkisp1_debug_cleanup(struct rkisp1_device *rkisp1);
 #else
+static inline void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1)
+{
+}
 static inline void rkisp1_debug_init(struct rkisp1_device *rkisp1)
 {
 }
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
index 79cda589d935..4358ed1367ed 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
@@ -25,6 +25,11 @@ struct rkisp1_debug_register {
 	const char * const name;
 };
 
+struct rkisp1_debug_counter {
+	const char * const name;
+	unsigned long *value;
+};
+
 #define RKISP1_DEBUG_REG(name)		{ RKISP1_CIF_##name, 0, #name }
 #define RKISP1_DEBUG_SHD_REG(name) { \
 	RKISP1_CIF_##name, RKISP1_CIF_##name##_SHD, #name \
@@ -191,6 +196,43 @@ static int rkisp1_debug_input_status_show(struct seq_file *m, void *p)
 }
 DEFINE_SHOW_ATTRIBUTE(rkisp1_debug_input_status);
 
+static int rkisp1_debug_counters_show(struct seq_file *m, void *p)
+{
+	struct rkisp1_device *rkisp1 = m->private;
+	struct rkisp1_debug *debug = &rkisp1->debug;
+
+	const struct rkisp1_debug_counter counters[] = {
+		{ "data_loss", &debug->data_loss },
+		{ "outform_size_err", &debug->outform_size_error },
+		{ "img_stabilization_size_error", &debug->img_stabilization_size_error },
+		{ "inform_size_error", &debug->inform_size_error },
+		{ "irq_delay", &debug->irq_delay },
+		{ "mipi_error", &debug->mipi_error },
+		{ "stats_error", &debug->stats_error },
+		{ "mp_stop_timeout", &debug->stop_timeout[RKISP1_MAINPATH] },
+		{ "sp_stop_timeout", &debug->stop_timeout[RKISP1_SELFPATH] },
+		{ "mp_frame_drop", &debug->frame_drop[RKISP1_MAINPATH] },
+		{ "sp_frame_drop", &debug->frame_drop[RKISP1_SELFPATH] },
+		{ "complete_frames", &debug->complete_frames },
+		{ /* Sentinel */ },
+	};
+
+	const struct rkisp1_debug_counter *counter = counters;
+
+	for (; counter->name; ++counter)
+		seq_printf(m, "%s: %lu\n", counter->name, *counter->value);
+
+	return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(rkisp1_debug_counters);
+
+void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1)
+{
+	struct dentry *debugfs_dir = rkisp1->debug.debugfs_dir;
+	memset(&rkisp1->debug, 0, sizeof(rkisp1->debug));
+	rkisp1->debug.debugfs_dir = debugfs_dir;
+}
+
 void rkisp1_debug_init(struct rkisp1_device *rkisp1)
 {
 	struct rkisp1_debug *debug = &rkisp1->debug;
@@ -198,31 +240,8 @@ void rkisp1_debug_init(struct rkisp1_device *rkisp1)
 
 	debug->debugfs_dir = debugfs_create_dir(dev_name(rkisp1->dev), NULL);
 
-	debugfs_create_ulong("data_loss", 0444, debug->debugfs_dir,
-			     &debug->data_loss);
-	debugfs_create_ulong("outform_size_err", 0444,  debug->debugfs_dir,
-			     &debug->outform_size_error);
-	debugfs_create_ulong("img_stabilization_size_error", 0444,
-			     debug->debugfs_dir,
-			     &debug->img_stabilization_size_error);
-	debugfs_create_ulong("inform_size_error", 0444,  debug->debugfs_dir,
-			     &debug->inform_size_error);
-	debugfs_create_ulong("irq_delay", 0444,  debug->debugfs_dir,
-			     &debug->irq_delay);
-	debugfs_create_ulong("mipi_error", 0444, debug->debugfs_dir,
-			     &debug->mipi_error);
-	debugfs_create_ulong("stats_error", 0444, debug->debugfs_dir,
-			     &debug->stats_error);
-	debugfs_create_ulong("mp_stop_timeout", 0444, debug->debugfs_dir,
-			     &debug->stop_timeout[RKISP1_MAINPATH]);
-	debugfs_create_ulong("sp_stop_timeout", 0444, debug->debugfs_dir,
-			     &debug->stop_timeout[RKISP1_SELFPATH]);
-	debugfs_create_ulong("mp_frame_drop", 0444, debug->debugfs_dir,
-			     &debug->frame_drop[RKISP1_MAINPATH]);
-	debugfs_create_ulong("sp_frame_drop", 0444, debug->debugfs_dir,
-			     &debug->frame_drop[RKISP1_SELFPATH]);
-	debugfs_create_ulong("complete_frames", 0444, debug->debugfs_dir,
-			     &debug->complete_frames);
+	debugfs_create_file("counters", 0444, debug->debugfs_dir, rkisp1,
+			    &rkisp1_debug_counters_fops);
 	debugfs_create_file("input_status", 0444, debug->debugfs_dir, rkisp1,
 			    &rkisp1_debug_input_status_fops);
 
-- 
2.39.2



From linus.walleij at linaro.org  Fri Dec  1 06:05:30 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 1 Dec 2023 15:05:30 +0100
Subject: [PATCH v4 00/23] pinctrl: Convert struct group_desc to use struct pingroup
In-Reply-To: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
Message-ID: <CACRpkdZAriTP3iOgmwvoAH-3-aO_ugoEkBHE7mHH5YLxhMXSXg@mail.gmail.com>

On Wed, Nov 29, 2023 at 5:15?PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:

> The struct group_desc has a lot of duplication with struct pingroup.
> Deduplicate that by embeddind the latter in the former and convert
> users.
>
> Linus, assuming everything is fine, I can push this to my tree.
> Or you can apply it (assumming all CIs and people are happy with
> the series).

I applied the series to devel so we get some rotation in linux-next,
augmenting the relevant commit messages as discussed!

Yours,
Linus Walleij


From andriy.shevchenko at linux.intel.com  Fri Dec  1 06:19:52 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 1 Dec 2023 16:19:52 +0200
Subject: [PATCH v4 00/23] pinctrl: Convert struct group_desc to use
 struct pingroup
In-Reply-To: <CACRpkdZAriTP3iOgmwvoAH-3-aO_ugoEkBHE7mHH5YLxhMXSXg@mail.gmail.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <CACRpkdZAriTP3iOgmwvoAH-3-aO_ugoEkBHE7mHH5YLxhMXSXg@mail.gmail.com>
Message-ID: <ZWnriFqDsEEE1vlJ@smile.fi.intel.com>

On Fri, Dec 01, 2023 at 03:05:30PM +0100, Linus Walleij wrote:
> On Wed, Nov 29, 2023 at 5:15?PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:

...

> I applied the series to devel so we get some rotation in linux-next,
> augmenting the relevant commit messages as discussed!

Thank you very much and have a good weekend!

-- 
With Best Regards,
Andy Shevchenko




From krzysztof.kozlowski at linaro.org  Fri Dec  1 06:21:05 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 1 Dec 2023 15:21:05 +0100
Subject: [PATCH] dt-bindings: marvell: move MMP boards to common marvell
 directory
In-Reply-To: <1e25e2f4-e4b9-4219-a9c2-cb6230a62549@lunn.ch>
References: <20231201132306.60753-1-krzysztof.kozlowski@linaro.org>
 <1e25e2f4-e4b9-4219-a9c2-cb6230a62549@lunn.ch>
Message-ID: <a44b7bb2-34ac-45ab-84c6-630d604f1bcf@linaro.org>

On 01/12/2023 14:51, Andrew Lunn wrote:
> On Fri, Dec 01, 2023 at 02:23:06PM +0100, Krzysztof Kozlowski wrote:
>> Marvell board bindings are spread over arm/marvell/ and arm/mrvl/
>> directories.  Move MMP board bindings from the latter to the former, to
>> keep all of them together.
> 
> Hi Krzysztof
> 
> Did you test get_maintainers.pl? MMP has a different maintainer to
> many of the other Marvell SoCs. We want emails going to the correct
> Maintainers, and ideally not spamming the others.

The old binding was not referenced in MAINTAINERS, at least I could not
find it.
My change does not affect status quo - orphaned files.

OTOH, some entries like Orion list specific files. Others like Marvell
list entire directory, which is their mistake in the first place.

There is a mess in this approach, but the mess exists before my patch.

Best regards,
Krzysztof



From andrew at lunn.ch  Fri Dec  1 06:34:09 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 1 Dec 2023 15:34:09 +0100
Subject: [PATCH] dt-bindings: marvell: move MMP boards to common marvell
 directory
In-Reply-To: <a44b7bb2-34ac-45ab-84c6-630d604f1bcf@linaro.org>
References: <20231201132306.60753-1-krzysztof.kozlowski@linaro.org>
 <1e25e2f4-e4b9-4219-a9c2-cb6230a62549@lunn.ch>
 <a44b7bb2-34ac-45ab-84c6-630d604f1bcf@linaro.org>
Message-ID: <5d511e31-8ff5-4c23-a65e-8660833a9799@lunn.ch>

On Fri, Dec 01, 2023 at 03:21:05PM +0100, Krzysztof Kozlowski wrote:
> On 01/12/2023 14:51, Andrew Lunn wrote:
> > On Fri, Dec 01, 2023 at 02:23:06PM +0100, Krzysztof Kozlowski wrote:
> >> Marvell board bindings are spread over arm/marvell/ and arm/mrvl/
> >> directories.  Move MMP board bindings from the latter to the former, to
> >> keep all of them together.
> > 
> > Hi Krzysztof
> > 
> > Did you test get_maintainers.pl? MMP has a different maintainer to
> > many of the other Marvell SoCs. We want emails going to the correct
> > Maintainers, and ideally not spamming the others.
> 
> The old binding was not referenced in MAINTAINERS, at least I could not
> find it.
> My change does not affect status quo - orphaned files.
> 
> OTOH, some entries like Orion list specific files. Others like Marvell
> list entire directory, which is their mistake in the first place.
> 
> There is a mess in this approach, but the mess exists before my patch.

I think these moved files will now match:

ARM/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 SOC support
M:      Andrew Lunn <andrew at lunn.ch>
M:      Gregory Clement <gregory.clement at bootlin.com>
M:      Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S:      Maintained
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git
F:      Documentation/devicetree/bindings/arm/marvell/

But these files are not Gregory or my problem.

If they were orphaned before, i would prefer they are either orphaned
after the move, or associated to the correct maintainer. Being
associated to the wrong maintainers is worse than having no
maintainers at all.

   Andrew


From krzysztof.kozlowski at linaro.org  Fri Dec  1 06:38:36 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 1 Dec 2023 15:38:36 +0100
Subject: [PATCH] dt-bindings: marvell: move MMP boards to common marvell
 directory
In-Reply-To: <5d511e31-8ff5-4c23-a65e-8660833a9799@lunn.ch>
References: <20231201132306.60753-1-krzysztof.kozlowski@linaro.org>
 <1e25e2f4-e4b9-4219-a9c2-cb6230a62549@lunn.ch>
 <a44b7bb2-34ac-45ab-84c6-630d604f1bcf@linaro.org>
 <5d511e31-8ff5-4c23-a65e-8660833a9799@lunn.ch>
Message-ID: <944c02f5-d0e6-4367-bb4d-b366054b3e4e@linaro.org>

On 01/12/2023 15:34, Andrew Lunn wrote:
> On Fri, Dec 01, 2023 at 03:21:05PM +0100, Krzysztof Kozlowski wrote:
>> On 01/12/2023 14:51, Andrew Lunn wrote:
>>> On Fri, Dec 01, 2023 at 02:23:06PM +0100, Krzysztof Kozlowski wrote:
>>>> Marvell board bindings are spread over arm/marvell/ and arm/mrvl/
>>>> directories.  Move MMP board bindings from the latter to the former, to
>>>> keep all of them together.
>>>
>>> Hi Krzysztof
>>>
>>> Did you test get_maintainers.pl? MMP has a different maintainer to
>>> many of the other Marvell SoCs. We want emails going to the correct
>>> Maintainers, and ideally not spamming the others.
>>
>> The old binding was not referenced in MAINTAINERS, at least I could not
>> find it.
>> My change does not affect status quo - orphaned files.
>>
>> OTOH, some entries like Orion list specific files. Others like Marvell
>> list entire directory, which is their mistake in the first place.
>>
>> There is a mess in this approach, but the mess exists before my patch.
> 
> I think these moved files will now match:
> 
> ARM/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 SOC support
> M:      Andrew Lunn <andrew at lunn.ch>
> M:      Gregory Clement <gregory.clement at bootlin.com>
> M:      Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S:      Maintained
> T:      git git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git
> F:      Documentation/devicetree/bindings/arm/marvell/
> 
> But these files are not Gregory or my problem.

Yeah, that's what I meant by listing entire directory.

> 
> If they were orphaned before, i would prefer they are either orphaned
> after the move, or associated to the correct maintainer. Being
> associated to the wrong maintainers is worse than having no
> maintainers at all.

I can add this to existing maintainers entry. Which one? I see only two
ARM/Marvell.

Best regards,
Krzysztof



From sudeep.holla at arm.com  Fri Dec  1 06:39:35 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 14:39:35 +0000
Subject: [PATCH 1/2] firmware: arm_scmi: Fix frequency truncation by
 promoting multiplier to u64
In-Reply-To: <20231130204343.503076-1-sudeep.holla@arm.com>
References: <20231130204343.503076-1-sudeep.holla@arm.com>
Message-ID: <20231201143935.be6wzjzxmyl5vpz6@bogus>

On Thu, Nov 30, 2023 at 08:43:42PM +0000, Sudeep Holla wrote:
> Fix the frequency truncation for all values equal to or greater 4GHz by
> updating the multiplier 'mult_factor' to u64 type. It is also possible
> that the multiplier itself can be greater than or equal to 2^32. So we need
> to also fix the equation computing the value of the multiplier.
> 
> Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol")
> Reported-by: Sibi Sankar <quic_sibis at quicinc.com>
> Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis at quicinc.com/
> Cc: Cristian Marussi <cristian.marussi at arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>  drivers/firmware/arm_scmi/perf.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
> index 81dd5c5e5533..8ce449922e55 100644
> --- a/drivers/firmware/arm_scmi/perf.c
> +++ b/drivers/firmware/arm_scmi/perf.c
> @@ -152,7 +152,7 @@ struct perf_dom_info {
>  	u32 opp_count;
>  	u32 sustained_freq_khz;
>  	u32 sustained_perf_level;
> -	u32 mult_factor;
> +	u64 mult_factor;

I have now changed this to unsigned long instead of u64 to fix the 32-bit
build failure[1].

-- 
Regards,
Sudeep

[1] https://lore.kernel.org/all/20231201085914.4ad45eb2 at canb.auug.org.au


From francesco at dolcini.it  Fri Dec  1 06:55:48 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 15:55:48 +0100
Subject: [PATCH v2 0/3] arm64: dts: ti: add verdin am62 mallow board
Message-ID: <20231201145551.23337-1-francesco@dolcini.it>

From: Francesco Dolcini <francesco.dolcini at toradex.com>

Add Toradex Verdin AM62 Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

v1:
 - https://lore.kernel.org/all/20231123112826.16549-1-francesco at dolcini.it/

v2:
 - fixed temperature sensor compatible (s/tmp75c/tmp1075)
 - add Acked-by: Krzysztof

Joao Paulo Goncalves (3):
  arm64: dts: ti: verdin-am62: improve spi1 chip-select pinctrl
  dt-bindings: arm: ti: add verdin am62 mallow board
  arm64: dts: ti: add verdin am62 mallow board

 .../devicetree/bindings/arm/ti/k3.yaml        |   2 +
 arch/arm64/boot/dts/ti/Makefile               |   2 +
 .../boot/dts/ti/k3-am62-verdin-mallow.dtsi    | 198 ++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi    |  17 +-
 .../dts/ti/k3-am625-verdin-nonwifi-mallow.dts |  22 ++
 .../dts/ti/k3-am625-verdin-wifi-mallow.dts    |  22 ++
 6 files changed, 261 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts

-- 
2.25.1



From francesco at dolcini.it  Fri Dec  1 06:55:49 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 15:55:49 +0100
Subject: [PATCH v2 1/3] arm64: dts: ti: verdin-am62: improve spi1 chip-select pinctrl
In-Reply-To: <20231201145551.23337-1-francesco@dolcini.it>
References: <20231201145551.23337-1-francesco@dolcini.it>
Message-ID: <20231201145551.23337-2-francesco@dolcini.it>

From: Joao Paulo Goncalves <joao.goncalves at toradex.com>

Verdin SPI_1 interface has a dedicated hardware controlled chip select
that is currently configured in the same pinctrl group as MISO/MOSI/CLK,
however it is possible that it can be used only as a standard GPIO be it
a chip select or not.

To maximize flexibility and avoid duplication in the carrier board dts
files move the SPI_1 CS in a dedicated pinctrl and also adds an
additional pinctrl to simplify using SPI_1 CS as a GPIO.

Signed-off-by: Joao Paulo Goncalves <joao.goncalves at toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
 arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
index 5db52f237253..6a06724b6d16 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
@@ -233,6 +233,13 @@ AM62X_IOPAD(0x0018, PIN_INPUT, 7) /* (F24) OSPI0_D3.GPIO0_6 */ /* SODIMM 62 */
 		>;
 	};
 
+	/* Verdin SPI_1 CS as GPIO */
+	pinctrl_qspi1_io4_gpio: main-gpio0-7-default-pins {
+		pinctrl-single,pins = <
+			AM62X_IOPAD(0x001c, PIN_INPUT, 7) /* (J23) OSPI0_D4.GPIO0_7 */ /* SODIMM 202 */
+		>;
+	};
+
 	/* Verdin QSPI_1_CS# as GPIO (conflict with Verdin QSPI_1 interface) */
 	pinctrl_qspi1_cs_gpio: main-gpio0-11-default-pins {
 		pinctrl-single,pins = <
@@ -599,12 +606,18 @@ AM62X_IOPAD(0x164, PIN_OUTPUT, 0) /* (AA19) RGMII2_TX_CTL */ /* SODIMM 211 */
 	pinctrl_spi1: main-spi1-default-pins {
 		pinctrl-single,pins = <
 			AM62X_IOPAD(0x0020, PIN_INPUT, 1) /* (J25) OSPI0_D5.SPI1_CLK */ /* SODIMM 196 */
-			AM62X_IOPAD(0x001c, PIN_INPUT, 1) /* (J23) OSPI0_D4.SPI1_CS0 */ /* SODIMM 202 */
 			AM62X_IOPAD(0x0024, PIN_INPUT, 1) /* (H25) OSPI0_D6.SPI1_D0  */ /* SODIMM 200 */
 			AM62X_IOPAD(0x0028, PIN_INPUT, 1) /* (J22) OSPI0_D7.SPI1_D1  */ /* SODIMM 198 */
 		>;
 	};
 
+	/* Verdin SPI_1 CS */
+	pinctrl_spi1_cs0: main-spi1-cs0-default-pins {
+		pinctrl-single,pins = <
+			AM62X_IOPAD(0x001c, PIN_INPUT, 1) /* (J23) OSPI0_D4.SPI1_CS0 */ /* SODIMM 202 */
+		>;
+	};
+
 	/* ETH_25MHz_CLK */
 	pinctrl_eth_clock: main-system-clkout0-default-pins {
 		pinctrl-single,pins = <
@@ -1278,7 +1291,7 @@ &main_mcan0 {
 /* Verdin SPI_1 */
 &main_spi1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_spi1>;
+	pinctrl-0 = <&pinctrl_spi1>, <&pinctrl_spi1_cs0>;
 	ti,pindir-d0-out-d1-in;
 	status = "disabled";
 };
-- 
2.25.1



From francesco at dolcini.it  Fri Dec  1 06:55:50 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 15:55:50 +0100
Subject: [PATCH v2 2/3] dt-bindings: arm: ti: add verdin am62 mallow board
In-Reply-To: <20231201145551.23337-1-francesco@dolcini.it>
References: <20231201145551.23337-1-francesco@dolcini.it>
Message-ID: <20231201145551.23337-3-francesco@dolcini.it>

From: Joao Paulo Goncalves <joao.goncalves at toradex.com>

Add Mallow carrier board for wifi and nonwifi variants of Toradex Verdin
AM62 SoM. Mallow is a low-cost carrier board in the Verdin family with
a small form factor and build for volume production making it ideal for
industrial and embedded applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Joao Paulo Goncalves <joao.goncalves at toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
v2: add acked-by
---
 Documentation/devicetree/bindings/arm/ti/k3.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 03d2a0d79fb0..c6506bccfe88 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -50,6 +50,7 @@ properties:
           - enum:
               - toradex,verdin-am62-nonwifi-dahlia # Verdin AM62 Module on Dahlia
               - toradex,verdin-am62-nonwifi-dev    # Verdin AM62 Module on Verdin Development Board
+              - toradex,verdin-am62-nonwifi-mallow # Verdin AM62 Module on Mallow
               - toradex,verdin-am62-nonwifi-yavia  # Verdin AM62 Module on Yavia
           - const: toradex,verdin-am62-nonwifi     # Verdin AM62 Module without Wi-Fi / BT
           - const: toradex,verdin-am62             # Verdin AM62 Module
@@ -60,6 +61,7 @@ properties:
           - enum:
               - toradex,verdin-am62-wifi-dahlia # Verdin AM62 Wi-Fi / BT Module on Dahlia
               - toradex,verdin-am62-wifi-dev    # Verdin AM62 Wi-Fi / BT M. on Verdin Development B.
+              - toradex,verdin-am62-wifi-mallow # Verdin AM62 Wi-Fi / BT Module on Mallow
               - toradex,verdin-am62-wifi-yavia  # Verdin AM62 Wi-Fi / BT Module on Yavia
           - const: toradex,verdin-am62-wifi     # Verdin AM62 Wi-Fi / BT Module
           - const: toradex,verdin-am62          # Verdin AM62 Module
-- 
2.25.1



From francesco at dolcini.it  Fri Dec  1 06:55:51 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 15:55:51 +0100
Subject: [PATCH v2 3/3] arm64: dts: ti: add verdin am62 mallow board
In-Reply-To: <20231201145551.23337-1-francesco@dolcini.it>
References: <20231201145551.23337-1-francesco@dolcini.it>
Message-ID: <20231201145551.23337-4-francesco@dolcini.it>

From: Joao Paulo Goncalves <joao.goncalves at toradex.com>

Add Toradex Verdin AM62 Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

Signed-off-by: Joao Paulo Goncalves <joao.goncalves at toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
v2: fixed temperature sensor compatible (s/tmp75c/tmp1075)
---
 arch/arm64/boot/dts/ti/Makefile               |   2 +
 .../boot/dts/ti/k3-am62-verdin-mallow.dtsi    | 198 ++++++++++++++++++
 .../dts/ti/k3-am625-verdin-nonwifi-mallow.dts |  22 ++
 .../dts/ti/k3-am625-verdin-wifi-mallow.dts    |  22 ++
 4 files changed, 244 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 77a347f9f47d..92ebf001a217 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -16,9 +16,11 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-phyboard-lyra-rdk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-sk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dev.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-mallow.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-yavia.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dev.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-mallow.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-yavia.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am62-lp-sk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-sk-hdmi-audio.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
new file mode 100644
index 000000000000..77b1beb638ad
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ *
+ * Common dtsi for Verdin AM62 SoM on Mallow carrier board
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
+ * https://www.toradex.com/products/carrier-board/mallow-carrier-board
+ */
+
+#include <dt-bindings/leds/common.h>
+
+/ {
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_qspi1_clk_gpio>,
+			    <&pinctrl_qspi1_cs_gpio>,
+			    <&pinctrl_qspi1_io0_gpio>,
+			    <&pinctrl_qspi1_io1_gpio>;
+
+		/* SODIMM 52 - USER_LED_1_RED */
+		led-0 {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <1>;
+			gpios = <&main_gpio0 0 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 54 - USER_LED_1_GREEN */
+		led-1 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <1>;
+			gpios = <&main_gpio0 11 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 56 - USER_LED_2_RED */
+		led-2 {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <2>;
+			gpios = <&main_gpio0 3 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 58 - USER_LED_2_GREEN */
+		led-3 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <2>;
+			gpios = <&main_gpio0 4 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+/* Verdin ETH */
+&cpsw3g {
+	status = "okay";
+};
+
+/* Verdin MDIO */
+&cpsw3g_mdio {
+	status = "okay";
+};
+
+/* Verdin ETH_1*/
+&cpsw_port1 {
+	status = "okay";
+};
+
+/* Verdin PWM_1 and PWM_2*/
+&epwm0 {
+	status = "okay";
+};
+
+/* Verdin PWM_3 DSI */
+&epwm1 {
+	status = "okay";
+};
+
+&main_gpio0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ctrl_sleep_moci>,
+		    <&pinctrl_gpio_1>,
+		    <&pinctrl_gpio_2>,
+		    <&pinctrl_gpio_3>,
+		    <&pinctrl_gpio_4>;
+};
+
+/* Verdin I2C_1 */
+&main_i2c1 {
+	status = "okay";
+
+	/* Temperature sensor */
+	sensor at 4f {
+		compatible = "ti,tmp1075";
+		reg = <0x4f>;
+	};
+
+	/* EEPROM */
+	eeprom at 57 {
+		compatible = "st,24c02", "atmel,24c02";
+		reg = <0x57>;
+		pagesize = <16>;
+	};
+};
+
+/* Verdin I2C_2 DSI */
+&main_i2c2 {
+	status = "okay";
+};
+
+/* Verdin I2C_4 CSI */
+&main_i2c3 {
+	status = "okay";
+};
+
+/* Verdin CAN_1 */
+&main_mcan0 {
+	status = "okay";
+};
+
+/* Verdin SPI_1 */
+&main_spi1 {
+	pinctrl-0 = <&pinctrl_spi1>,
+		    <&pinctrl_spi1_cs0>,
+		    <&pinctrl_qspi1_cs2_gpio>;
+	cs-gpios = <0>, <&main_gpio0 12 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	tpm at 1 {
+		compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+		reg = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_qspi1_dqs_gpio>;
+		interrupt-parent = <&main_gpio1>;
+		interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
+		spi-max-frequency = <18500000>;
+	};
+};
+
+/* Verdin UART_3 */
+&main_uart0 {
+	status = "okay";
+};
+
+/* Verdin UART_1 */
+&main_uart1 {
+	status = "okay";
+};
+
+/* Verdin I2C_3_HDMI */
+&mcu_i2c0 {
+	status = "okay";
+};
+
+/* Verdin CAN_2 */
+&mcu_mcan0 {
+	status = "okay";
+};
+
+/* Verdin UART_4 */
+&mcu_uart0 {
+	status = "okay";
+};
+
+/* Verdin SD_1 */
+&sdhci1 {
+	status = "okay";
+};
+
+/* Verdin USB_1 */
+&usbss0 {
+	status = "okay";
+};
+
+&usb0 {
+	status = "okay";
+};
+
+/* Verdin USB_2 */
+&usbss1 {
+	status = "okay";
+};
+
+&usb1 {
+	status = "okay";
+};
+
+/* Verdin CTRL_WAKE1_MICO# */
+&verdin_gpio_keys {
+	status = "okay";
+};
+
+/* Verdin UART_2 */
+&wkup_uart0 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts b/arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts
new file mode 100644
index 000000000000..9cae12106e0e
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
+ * https://www.toradex.com/products/carrier-board/mallow-carrier-board
+ */
+
+/dts-v1/;
+
+#include "k3-am625.dtsi"
+#include "k3-am62-verdin.dtsi"
+#include "k3-am62-verdin-nonwifi.dtsi"
+#include "k3-am62-verdin-mallow.dtsi"
+
+/ {
+	model = "Toradex Verdin AM62 on Mallow Board";
+	compatible = "toradex,verdin-am62-nonwifi-mallow",
+		     "toradex,verdin-am62-nonwifi",
+		     "toradex,verdin-am62",
+		     "ti,am625";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts b/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts
new file mode 100644
index 000000000000..81d834b22649
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
+ * https://www.toradex.com/products/carrier-board/mallow-carrier-board
+ */
+
+/dts-v1/;
+
+#include "k3-am625.dtsi"
+#include "k3-am62-verdin.dtsi"
+#include "k3-am62-verdin-wifi.dtsi"
+#include "k3-am62-verdin-mallow.dtsi"
+
+/ {
+	model = "Toradex Verdin AM62 WB on Mallow Board";
+	compatible = "toradex,verdin-am62-wifi-mallow",
+		     "toradex,verdin-am62-wifi",
+		     "toradex,verdin-am62",
+		     "ti,am625";
+};
-- 
2.25.1



From hawk at kernel.org  Fri Dec  1 07:02:22 2023
From: hawk at kernel.org (Jesper Dangaard Brouer)
Date: Fri, 1 Dec 2023 16:02:22 +0100
Subject: [PATCH bpf-next v2 2/3] net: stmmac: Add txtime support to XDP ZC
In-Reply-To: <20231201062421.1074768-3-yoong.siang.song@intel.com>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <20231201062421.1074768-3-yoong.siang.song@intel.com>
Message-ID: <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org>



On 12/1/23 07:24, Song Yoong Siang wrote:
> This patch enables txtime support to XDP zero copy via XDP Tx
> metadata framework.
> 
> Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> ---
>   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++
>   2 files changed, 15 insertions(+)

I think we need to see other drivers using this new feature to evaluate
if API is sane.

I suggest implementing this for igc driver (chip i225) and also for igb
(i210 chip) that both support this kind of LaunchTime feature in HW.

The API and stmmac driver takes a u64 as time.
I'm wondering how this applies to i210 that[1] have 25-bit for
LaunchTime (with 32 nanosec granularity) limiting LaunchTime max 0.5
second into the future.
And i225 that [1] have 30-bit max 1 second into the future.


[1] 
https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org



From biju.das.jz at bp.renesas.com  Fri Dec  1 07:02:24 2023
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Fri, 1 Dec 2023 15:02:24 +0000
Subject: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
In-Reply-To: <CAMuHMdWh3fTzQP5+mGF3u8LACg-5tQDZcyExvgREpxKd6iee4Q@mail.gmail.com>
References: <20231201110840.37408-1-biju.das.jz@bp.renesas.com>
 <20231201110840.37408-7-biju.das.jz@bp.renesas.com>
 <CAMuHMdWh3fTzQP5+mGF3u8LACg-5tQDZcyExvgREpxKd6iee4Q@mail.gmail.com>
Message-ID: <TYCPR01MB112696C301D750A915F2661688681A@TYCPR01MB11269.jpnprd01.prod.outlook.com>

Hi Geert,

Thanks for the feedback.

> -----Original Message-----
> From: Geert Uytterhoeven <geert at linux-m68k.org>
> Sent: Friday, December 1, 2023 1:41 PM
> Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
> 
> Hi Biju,
> 
> On Fri, Dec 1, 2023 at 12:09?PM Biju Das <biju.das.jz at bp.renesas.com>
> wrote:
> > Enable the config for the Renesas DA9062 PMIC and RTC, as it is
> > populated on RZ/G2UL SMARC EVK.
> >
> > Signed-off-by: Biju Das <biju.das.jz at bp.renesas.com>
> 
> Thanks for your patch!
> 
> LGTM, but I would have expected (at least)
> 
>     CONFIG_INPUT_DA9063_ONKEY=m
> 
> too, cfr. my comments on patch 5/6.

I have tested this, but I get "da9063-onkey da9062-onkey: error -ENXIO: IRQ ONKEY not found"
So, I won't be able to test onkey events. So plaaning to disable this node.

Cheers,
Biju

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-
> m68k.org
> 
> In personal conversations with technical people, I call myself a hacker.
> But when I'm talking to journalists I just say "programmer" or something
> like that.
>                                 -- Linus Torvalds

From marex at denx.de  Fri Dec  1 07:06:04 2023
From: marex at denx.de (Marek Vasut)
Date: Fri,  1 Dec 2023 16:06:04 +0100
Subject: [PATCH] media: nxp: isi: Check whether pad is non-NULL before access
Message-ID: <20231201150614.63300-1-marex@denx.de>

The pad can be NULL if media controller routing is not set up correctly.
Check whether the pad is NULL before using it, otherwise it is possible
to achieve NULL pointer dereference.

Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
Signed-off-by: Marek Vasut <marex at denx.de>
---
Cc: Fabio Estevam <festevam at gmail.com>
Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab at kernel.org>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-media at vger.kernel.org
---
 drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
index 792f031e032ae..44354931cf8a1 100644
--- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
+++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
@@ -160,8 +160,14 @@ mxc_isi_crossbar_xlate_streams(struct mxc_isi_crossbar *xbar,
 	}
 
 	pad = media_pad_remote_pad_first(&xbar->pads[sink_pad]);
-	sd = media_entity_to_v4l2_subdev(pad->entity);
+	if (!pad) {
+		dev_dbg(xbar->isi->dev,
+			"no pad connected to crossbar input %u\n",
+			sink_pad);
+		return ERR_PTR(-EPIPE);
+	}
 
+	sd = media_entity_to_v4l2_subdev(pad->entity);
 	if (!sd) {
 		dev_dbg(xbar->isi->dev,
 			"no entity connected to crossbar input %u\n",
-- 
2.42.0



From francesco at dolcini.it  Fri Dec  1 07:07:31 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 16:07:31 +0100
Subject: [PATCH v1 0/2] arm64: dts: freescale: verdin-imx8mm: add support to mallow board
Message-ID: <20231201150733.24454-1-francesco@dolcini.it>

From: Francesco Dolcini <francesco.dolcini at toradex.com>

Add Toradex Verdin IMX8MM Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

Joao Paulo Goncalves (2):
  dt-bindings: arm: fsl: add verdin imx8mm mallow board
  arm64: dts: freescale: verdin-imx8mm: add support to mallow board

 .../devicetree/bindings/arm/fsl.yaml          |   2 +
 arch/arm64/boot/dts/freescale/Makefile        |   2 +
 .../dts/freescale/imx8mm-verdin-mallow.dtsi   | 173 ++++++++++++++++++
 .../imx8mm-verdin-nonwifi-mallow.dts          |  18 ++
 .../freescale/imx8mm-verdin-wifi-mallow.dts   |  18 ++
 5 files changed, 213 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-mallow.dts

-- 
2.25.1



From francesco at dolcini.it  Fri Dec  1 07:07:33 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 16:07:33 +0100
Subject: [PATCH v1 2/2] arm64: dts: freescale: verdin-imx8mm: add support to mallow board
In-Reply-To: <20231201150733.24454-1-francesco@dolcini.it>
References: <20231201150733.24454-1-francesco@dolcini.it>
Message-ID: <20231201150733.24454-3-francesco@dolcini.it>

From: Joao Paulo Goncalves <joao.goncalves at toradex.com>

Add Toradex Verdin IMX8MM Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

Signed-off-by: Joao Paulo Goncalves <joao.goncalves at toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
 arch/arm64/boot/dts/freescale/Makefile        |   2 +
 .../dts/freescale/imx8mm-verdin-mallow.dtsi   | 173 ++++++++++++++++++
 .../imx8mm-verdin-nonwifi-mallow.dts          |  18 ++
 .../freescale/imx8mm-verdin-wifi-mallow.dts   |  18 ++
 4 files changed, 211 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-mallow.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 6d83f84090e1..98fc8171a885 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -84,9 +84,11 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7904.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7905-0x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-dahlia.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-dev.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-mallow.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-yavia.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dahlia.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-mallow.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-yavia.dtb
 
 imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33-dtbs += imx8mm-tqma8mqml-mba8mx.dtb imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-mallow.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin-mallow.dtsi
new file mode 100644
index 000000000000..4a0799d63446
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-mallow.dtsi
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ *
+ * Common dtsi for Verdin IMX8MM SoM on Mallow carrier board
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
+ * https://www.toradex.com/products/carrier-board/mallow-carrier-board
+ */
+
+#include <dt-bindings/leds/common.h>
+
+/ {
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_leds>;
+
+		/* SODIMM 52 - USER_LED_1_RED */
+		led-0 {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <1>;
+			gpios = <&gpio3 0 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 54 - USER_LED_1_GREEN */
+		led-1 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <1>;
+			gpios = <&gpio3 1 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 56 - USER_LED_2_RED */
+		led-2 {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <2>;
+			gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 58 - USER_LED_2_GREEN */
+		led-3 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <2>;
+			gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+/* Verdin SPI_1 */
+&ecspi2 {
+	pinctrl-0 = <&pinctrl_ecspi2>, <&pinctrl_tpm_cs>;
+	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>, <&gpio3 2 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	tpm at 1 {
+		compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+		reg = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_tpm_irq>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+		spi-max-frequency = <18500000>;
+	};
+};
+
+/* EEPROM on Mallow */
+&eeprom_carrier_board {
+	status = "okay";
+};
+
+/* Verdin ETH_1 */
+&fec1 {
+	status = "okay";
+};
+
+/* Temperature sensor on Mallow */
+&hwmon_temp {
+	compatible = "ti,tmp1075";
+	status = "okay";
+};
+
+/* Verdin I2C_2_DSI */
+&i2c2 {
+	status = "okay";
+};
+
+/* Verdin I2C_4_CSI */
+&i2c3 {
+	status = "okay";
+};
+
+/* Verdin I2C_1 */
+&i2c4 {
+	status = "okay";
+};
+
+/* Verdin PCIE_1 */
+&pcie0 {
+	status = "okay";
+};
+
+&pcie_phy {
+	status = "okay";
+};
+
+/* Verdin PWM_3_DSI */
+&pwm1 {
+	status = "okay";
+};
+
+/* Verdin PWM_1 */
+&pwm2 {
+	status = "okay";
+};
+
+/* Verdin PWM_2 */
+&pwm3 {
+	status = "okay";
+};
+
+/* Verdin UART_3 */
+&uart1 {
+	status = "okay";
+};
+
+/* Verdin UART_1 */
+&uart2 {
+	status = "okay";
+};
+
+/* Verdin UART_2 */
+&uart3 {
+	status = "okay";
+};
+
+/* Verdin USB_1 */
+&usbotg1 {
+	status = "okay";
+};
+
+/* Verdin USB_2 */
+&usbotg2 {
+	status = "okay";
+};
+
+/* Verdin SD_1 */
+&usdhc2 {
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_leds: ledsgrp {
+		fsl,pins =
+			<MX8MM_IOMUXC_NAND_ALE_GPIO3_IO0	0x106>, /* SODIMM 52 */
+			<MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1	0x106>, /* SODIMM 54 */
+			<MX8MM_IOMUXC_NAND_DATA00_GPIO3_IO6	0x106>, /* SODIMM 56 */
+			<MX8MM_IOMUXC_NAND_DATA01_GPIO3_IO7	0x106>; /* SODIMM 58 */
+	};
+
+	pinctrl_tpm_cs: tpmcsgrp {
+		fsl,pins =
+			<MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2	0x146>; /* SODIMM 64 */
+	};
+
+	pinctrl_tpm_irq: tpmirqgrp {
+		fsl,pins =
+			<MX8MM_IOMUXC_NAND_DQS_GPIO3_IO14	0x141>; /* SODIMM 66 */
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-mallow.dts b/arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-mallow.dts
new file mode 100644
index 000000000000..1b1999f3a80e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-mallow.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ */
+
+/dts-v1/;
+
+#include "imx8mm-verdin.dtsi"
+#include "imx8mm-verdin-nonwifi.dtsi"
+#include "imx8mm-verdin-mallow.dtsi"
+
+/ {
+	model = "Toradex Verdin iMX8M Mini on Mallow";
+	compatible = "toradex,verdin-imx8mm-nonwifi-mallow",
+		     "toradex,verdin-imx8mm-nonwifi",
+		     "toradex,verdin-imx8mm",
+		     "fsl,imx8mm";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-mallow.dts b/arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-mallow.dts
new file mode 100644
index 000000000000..2916145f31bb
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-mallow.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ */
+
+/dts-v1/;
+
+#include "imx8mm-verdin.dtsi"
+#include "imx8mm-verdin-wifi.dtsi"
+#include "imx8mm-verdin-mallow.dtsi"
+
+/ {
+	model = "Toradex Verdin iMX8M Mini WB on Mallow";
+	compatible = "toradex,verdin-imx8mm-wifi-mallow",
+		     "toradex,verdin-imx8mm-wifi",
+		     "toradex,verdin-imx8mm",
+		     "fsl,imx8mm";
+};
-- 
2.25.1



From willemdebruijn.kernel at gmail.com  Fri Dec  1 07:09:15 2023
From: willemdebruijn.kernel at gmail.com (Willem de Bruijn)
Date: Fri, 01 Dec 2023 10:09:15 -0500
Subject: [PATCH bpf-next v2 0/3] xsk: TX metadata txtime support
In-Reply-To: <PH0PR11MB58306C2E50009A6E22F9DAD3D881A@PH0PR11MB5830.namprd11.prod.outlook.com>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <d4f99931-442c-4cd7-b3cf-80d8681a2986@kernel.org>
 <PH0PR11MB58306C2E50009A6E22F9DAD3D881A@PH0PR11MB5830.namprd11.prod.outlook.com>
Message-ID: <6569f71bad00d_138af5294d@willemb.c.googlers.com.notmuch>

Song, Yoong Siang wrote:
> On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer <hawk at kernel.org> wrote:
> >On 12/1/23 07:24, Song Yoong Siang wrote:
> >> This series expands XDP TX metadata framework to include ETF HW offload.
> >>
> >> Changes since v1:
> >> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF)
> >> - rename launch-time to txtime
> >>
> >
> >I strongly disagree with this renaming (sorry to disagree with Willem).
> >
> >The i210 and i225 chips call this LaunchTime in their programmers
> >datasheets, and even in the driver code[1].
> >
> >Using this "txtime" name in the code is also confusing, because how can
> >people reading the code know the difference between:
> >  - tmo_request_timestamp and tmo_request_txtime
> >
> 
> Hi Jesper and Willem,
> 
> How about using "launch_time" for the flag/variable and
> "Earliest TxTime First" for the description/comments?  

I don't particularly care which term we use, as long as we're
consistent. Especially, don't keep introducing new synonyms.

The fact that one happens to be one vendor's marketing term does not
make it preferable, IMHO. On the contrary.

SO_TXTIME is in the ABI, and EDT has been used publicly in kernel
patches and conference talks, e.g., Van Jacobson's Netdev 0x12
keynote. Those are vendor agnostic commonly used terms.

But as long as Launch Time is not an Intel only trademark, fine to
select that.


From ville.syrjala at linux.intel.com  Fri Dec  1 07:15:25 2023
From: ville.syrjala at linux.intel.com (Ville =?iso-8859-1?Q?Syrj=E4l=E4?=)
Date: Fri, 1 Dec 2023 17:15:25 +0200
Subject: [PATCH v4 05/45] drm/connector: Check drm_connector_init
 pointers arguments
In-Reply-To: <2lbs5dkpusow72koxknoautcfb6e2ygq5wledim4i572ya5xlc@stc4koneykhm>
References: <20231128-kms-hdmi-connector-state-v4-0-c7602158306e@kernel.org>
 <20231128-kms-hdmi-connector-state-v4-5-c7602158306e@kernel.org>
 <87h6l66nth.fsf@intel.com>
 <v3hplco5fdedv6bnc6mwx2zhhw4xxdiekha26ykhc5cmy7ol77@2irk3w4hmabw>
 <ZWXv1Oi_sH0BRWao@intel.com>
 <2mnodqvu2oo674vspiy4gxhglu3it5cq47acx5itnbwevgc4cf@c7h2bvnx3m2n>
 <ZWcB4Ak8QnwkhObR@intel.com>
 <2lbs5dkpusow72koxknoautcfb6e2ygq5wledim4i572ya5xlc@stc4koneykhm>
Message-ID: <ZWn4jUsVgjubVPvB@intel.com>

On Fri, Dec 01, 2023 at 10:01:49AM +0100, Maxime Ripard wrote:
> On Wed, Nov 29, 2023 at 11:18:24AM +0200, Ville Syrj?l? wrote:
> > On Wed, Nov 29, 2023 at 10:11:26AM +0100, Maxime Ripard wrote:
> > > Hi Ville,
> > > 
> > > On Tue, Nov 28, 2023 at 03:49:08PM +0200, Ville Syrj?l? wrote:
> > > > On Tue, Nov 28, 2023 at 02:29:40PM +0100, Maxime Ripard wrote:
> > > > > On Tue, Nov 28, 2023 at 02:54:02PM +0200, Jani Nikula wrote:
> > > > > > On Tue, 28 Nov 2023, Maxime Ripard <mripard at kernel.org> wrote:
> > > > > > > All the drm_connector_init variants take at least a pointer to the
> > > > > > > device, connector and hooks implementation.
> > > > > > >
> > > > > > > However, none of them check their value before dereferencing those
> > > > > > > pointers which can lead to a NULL-pointer dereference if the author
> > > > > > > isn't careful.
> > > > > > 
> > > > > > Arguably oopsing on the spot is preferrable when this can't be caused by
> > > > > > user input. It's always a mistake that should be caught early during
> > > > > > development.
> > > > > > 
> > > > > > Not everyone checks the return value of drm_connector_init and friends,
> > > > > > so those cases will lead to more mysterious bugs later. And probably
> > > > > > oopses as well.
> > > > > 
> > > > > So maybe we can do both then, with something like
> > > > > 
> > > > > if (WARN_ON(!dev))
> > > > >    return -EINVAL
> > > > > 
> > > > > if (drm_WARN_ON(dev, !connector || !funcs))
> > > > >    return -EINVAL;
> > > > > 
> > > > > I'd still like to check for this, so we can have proper testing, and we
> > > > > already check for those pointers in some places (like funcs in
> > > > > drm_connector_init), so if we don't cover everything we're inconsistent.
> > > > 
> > > > People will invariably cargo-cult this kind of stuff absolutely
> > > > everywhere and then all your functions will have tons of dead
> > > > code to check their arguments.
> > > 
> > > And that's a bad thing because... ?
> > > 
> > > Also, are you really saying that checking that your arguments make sense
> > > is cargo-cult?
> > > 
> > > We're already doing it in some parts of KMS, so we have to be
> > > consistent, and the answer to "most drivers don't check the error"
> > > cannot be "let's just give on error checking then".
> > > 
> > > > I'd prefer not to go there usually.
> > > > 
> > > > Should we perhaps start to use the (arguably hideous)
> > > >  - void f(struct foo *bar)
> > > >  + void f(struct foo bar[static 1])
> > > > syntax to tell the compiler we don't accept NULL pointers?
> > > > 
> > > > Hmm. Apparently that has the same problem as using any
> > > > other kind of array syntax in the prototype. That is,
> > > > the compiler demands to know the definition of 'struct foo'
> > > > even though we're passing in effectively a pointer. Sigh.
> > > 
> > > Honestly, I don't care as long as it's something we can unit-test to
> > > make sure we make it consistent. We can't unit test a complete kernel
> > > crash.
> > 
> > Why do you want to put utterly broken code into a unit test?
> 
> Utterly broken code happens. It probably shouldn't, but here we are.
> 
> Anyway, you mostly missed the consistent part.
> 
> The current state with it is:
> 
>   - planes:
>     - drm_universal_plane_init warns if funcs->destroy NULL
>     - drm_universal_plane_alloc errors out if funcs is NULL
>     - drmm_universal_plane_alloc warns and errors out if funcs or funcs->destroy are NULL
> 
>   - CRTC:
>     - drm_crtc_init_with_planes warns if funcs->destroy NULL
>     - drmm_crtc_init_with_planes warns if funcs or funcs->destroy are NULL
>     - drmm_crtc_alloc_with_planes warns and errors out if funcs or funcs->destroy are NULL
> 
>   - encoder:
>     - drm_encoder_init warns if funcs->destroy NULL
>     - drmm_encoder_init warns and errors out if funcs or funcs->destroy are NULL
>     - drmm_encoder_alloc warns and errors out if funcs or funcs->destroy are NULL
> 
>   - connectors:
>     - drm_connector_init warns and errors out if funcs or funcs->destroy are NULL
>     - drm_connector_init_with_ddc warns and errors out if funcs or funcs->destroy are NULL
>     - drmm_connector_init warns and errors out if funcs or funcs->destroy are NULL

Those are perhaps fine, as things may not oops immediately if you get
that wrong. But NULL checking things that will anyway oops immediately,
(and there's not chance the thing will do anything useful if you prevent
the oops with a NULL check) doesn't make any sense to me. It just makes
you doubt the entire universe when you see code like that.

> 
> I think that just proves that your opinion is just not as clear cut as
> you'd like it to be, and it's far from being the policy you claim it is.
> 
> Plus, we're not even remotely consistent there, and we're not
> documenting that anywhere.
> 
> And we have plenty of other examples of static stuff being checked
> because it just makes sense. All variants of drm_crtc_init_with_planes
> will for example check that the correct plane type is associated to the
> primary and cursor planes.
> 
> We should fix that.

Ideally the compiler should catch all of this. But given we are
implementing this in C (and even C23 constexpr was neutered beyond
uselessness) that's not really possible in any nice way :(

-- 
Ville Syrj?l?
Intel


From ville.syrjala at linux.intel.com  Fri Dec  1 07:17:35 2023
From: ville.syrjala at linux.intel.com (Ville =?iso-8859-1?Q?Syrj=E4l=E4?=)
Date: Fri, 1 Dec 2023 17:17:35 +0200
Subject: [PATCH v4 05/45] drm/connector: Check drm_connector_init
 pointers arguments
In-Reply-To: <ZWcRoTJ9VgOqZ3ts@intel.com>
References: <20231128-kms-hdmi-connector-state-v4-0-c7602158306e@kernel.org>
 <20231128-kms-hdmi-connector-state-v4-5-c7602158306e@kernel.org>
 <87h6l66nth.fsf@intel.com>
 <v3hplco5fdedv6bnc6mwx2zhhw4xxdiekha26ykhc5cmy7ol77@2irk3w4hmabw>
 <ZWXv1Oi_sH0BRWao@intel.com>
 <20231129121259.47746996@eldfell>
 <ZWcRoTJ9VgOqZ3ts@intel.com>
Message-ID: <ZWn5D387DYmsh1sa@intel.com>

On Wed, Nov 29, 2023 at 12:25:37PM +0200, Ville Syrj?l? wrote:
> On Wed, Nov 29, 2023 at 12:12:59PM +0200, Pekka Paalanen wrote:
> > On Tue, 28 Nov 2023 15:49:08 +0200
> > Ville Syrj?l? <ville.syrjala at linux.intel.com> wrote:
> > 
> > > Should we perhaps start to use the (arguably hideous)
> > >  - void f(struct foo *bar)
> > >  + void f(struct foo bar[static 1])
> > > syntax to tell the compiler we don't accept NULL pointers?
> > > 
> > > Hmm. Apparently that has the same problem as using any
> > > other kind of array syntax in the prototype. That is,
> > > the compiler demands to know the definition of 'struct foo'
> > > even though we're passing in effectively a pointer. Sigh.
> > 
> > 
> > __attribute__((nonnull)) ?
> 
> I guess that would work, though the syntax is horrible when
> you need to flag specific arguments.

I played around with this a bit (blindly cocci'd tons of
drm and i915 function declarations with the nonnull attribute)
and it's somewhat underwhelming unfortunately.

It will trip only if the compiler is 100% sure you're passing
in a NULL. There is no way to eg. tell the compiler that a
function can return a NULL and thus anything coming from it
should be checked by the caller before passing it on to
something with the nonnull attribute. And I suppose error
pointers would also screw that idea over anyway.

Additionally the NULL device checks being being done in 
the drm_err/dbg macros trip this up left right and center.
And hiding that check inside a function (instead of having
it in the macro) is also ruined by the fact that we apparently
pass different types of pointers to these macros :( Generics
could be used to sort out that type mess I suppose, or the
code that passes the wrong type (DSI code at least) should
just be changed to not do that. But not sure if there's enough
benefit to warrant the work.

-- 
Ville Syrj?l?
Intel


From willemdebruijn.kernel at gmail.com  Fri Dec  1 07:26:51 2023
From: willemdebruijn.kernel at gmail.com (Willem de Bruijn)
Date: Fri, 01 Dec 2023 10:26:51 -0500
Subject: [PATCH bpf-next v2 2/3] net: stmmac: Add txtime support to XDP ZC
In-Reply-To: <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <20231201062421.1074768-3-yoong.siang.song@intel.com>
 <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org>
Message-ID: <6569fb3b31fb6_1396ec2948@willemb.c.googlers.com.notmuch>

Jesper Dangaard Brouer wrote:
> 
> 
> On 12/1/23 07:24, Song Yoong Siang wrote:
> > This patch enables txtime support to XDP zero copy via XDP Tx
> > metadata framework.
> > 
> > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > ---
> >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> >   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++
> >   2 files changed, 15 insertions(+)
> 
> I think we need to see other drivers using this new feature to evaluate
> if API is sane.
> 
> I suggest implementing this for igc driver (chip i225) and also for igb
> (i210 chip) that both support this kind of LaunchTime feature in HW.
> 
> The API and stmmac driver takes a u64 as time.
> I'm wondering how this applies to i210 that[1] have 25-bit for
> LaunchTime (with 32 nanosec granularity) limiting LaunchTime max 0.5
> second into the future.
> And i225 that [1] have 30-bit max 1 second into the future.
> 
> 
> [1] 
> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org

Good point Jesper.

Can we also explicitly document what the type of the field is?
Nanoseconds against the NIC hardware clock, it sounds like.

We have some experience with this, too. Something needs to do the
conversion from host clock to NIC clock. It is not sufficent to just
assume that the host clock is synced against the NIC clock by PTP.



From kieran.bingham at ideasonboard.com  Fri Dec  1 07:30:42 2023
From: kieran.bingham at ideasonboard.com (Kieran Bingham)
Date: Fri, 01 Dec 2023 15:30:42 +0000
Subject: [PATCH v2 4/4] media: rkisp1: debug: Consolidate counter debugfs files
In-Reply-To: <20231201140433.2126011-5-paul.elder@ideasonboard.com>
References: <20231201140433.2126011-1-paul.elder@ideasonboard.com> <20231201140433.2126011-5-paul.elder@ideasonboard.com>
Message-ID: <170144464218.1400840.7647651809740627975@ping.linuxembedded.co.uk>

Quoting Paul Elder (2023-12-01 14:04:33)
> Consolidate all the debugfs files that were each a single counter into a
> single "counters" file.
> 
> While at it, reset the counters at stream on time to make it easier for
> to interpret the values in userspace.

That gives a better atomicity here I think so that's good. I guess the
debug struct could have a lock around it sometime - but I don't think
that matters in this context.

Resetting at stream on looks to make sense so:


Reviewed-by: Kieran Bingham <kieran.bingham at ideasonboard.com>

> 
> Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
> 
> ---
> New in v2
> 
>  .../platform/rockchip/rkisp1/rkisp1-capture.c |  2 +
>  .../platform/rockchip/rkisp1/rkisp1-common.h  |  4 ++
>  .../platform/rockchip/rkisp1/rkisp1-debug.c   | 69 ++++++++++++-------
>  3 files changed, 50 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> index c6d7e01c8949..67b2e94dfd67 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> @@ -1030,6 +1030,8 @@ rkisp1_vb2_start_streaming(struct vb2_queue *queue, unsigned int count)
>         struct media_entity *entity = &cap->vnode.vdev.entity;
>         int ret;
>  
> +       rkisp1_debug_reset_counters(cap->rkisp1);
> +
>         mutex_lock(&cap->rkisp1->stream_lock);
>  
>         ret = video_device_pipeline_start(&cap->vnode.vdev, &cap->rkisp1->pipe);
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> index be69173958a4..789259fb304a 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> @@ -599,9 +599,13 @@ int rkisp1_params_register(struct rkisp1_device *rkisp1);
>  void rkisp1_params_unregister(struct rkisp1_device *rkisp1);
>  
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
> +void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1);
>  void rkisp1_debug_init(struct rkisp1_device *rkisp1);
>  void rkisp1_debug_cleanup(struct rkisp1_device *rkisp1);
>  #else
> +static inline void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1)
> +{
> +}
>  static inline void rkisp1_debug_init(struct rkisp1_device *rkisp1)
>  {
>  }
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
> index 79cda589d935..4358ed1367ed 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
> @@ -25,6 +25,11 @@ struct rkisp1_debug_register {
>         const char * const name;
>  };
>  
> +struct rkisp1_debug_counter {
> +       const char * const name;
> +       unsigned long *value;
> +};
> +
>  #define RKISP1_DEBUG_REG(name)         { RKISP1_CIF_##name, 0, #name }
>  #define RKISP1_DEBUG_SHD_REG(name) { \
>         RKISP1_CIF_##name, RKISP1_CIF_##name##_SHD, #name \
> @@ -191,6 +196,43 @@ static int rkisp1_debug_input_status_show(struct seq_file *m, void *p)
>  }
>  DEFINE_SHOW_ATTRIBUTE(rkisp1_debug_input_status);
>  
> +static int rkisp1_debug_counters_show(struct seq_file *m, void *p)
> +{
> +       struct rkisp1_device *rkisp1 = m->private;
> +       struct rkisp1_debug *debug = &rkisp1->debug;
> +
> +       const struct rkisp1_debug_counter counters[] = {
> +               { "data_loss", &debug->data_loss },
> +               { "outform_size_err", &debug->outform_size_error },
> +               { "img_stabilization_size_error", &debug->img_stabilization_size_error },
> +               { "inform_size_error", &debug->inform_size_error },
> +               { "irq_delay", &debug->irq_delay },
> +               { "mipi_error", &debug->mipi_error },
> +               { "stats_error", &debug->stats_error },
> +               { "mp_stop_timeout", &debug->stop_timeout[RKISP1_MAINPATH] },
> +               { "sp_stop_timeout", &debug->stop_timeout[RKISP1_SELFPATH] },
> +               { "mp_frame_drop", &debug->frame_drop[RKISP1_MAINPATH] },
> +               { "sp_frame_drop", &debug->frame_drop[RKISP1_SELFPATH] },
> +               { "complete_frames", &debug->complete_frames },
> +               { /* Sentinel */ },
> +       };
> +
> +       const struct rkisp1_debug_counter *counter = counters;
> +
> +       for (; counter->name; ++counter)
> +               seq_printf(m, "%s: %lu\n", counter->name, *counter->value);
> +
> +       return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(rkisp1_debug_counters);
> +
> +void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1)
> +{
> +       struct dentry *debugfs_dir = rkisp1->debug.debugfs_dir;
> +       memset(&rkisp1->debug, 0, sizeof(rkisp1->debug));
> +       rkisp1->debug.debugfs_dir = debugfs_dir;
> +}
> +
>  void rkisp1_debug_init(struct rkisp1_device *rkisp1)
>  {
>         struct rkisp1_debug *debug = &rkisp1->debug;
> @@ -198,31 +240,8 @@ void rkisp1_debug_init(struct rkisp1_device *rkisp1)
>  
>         debug->debugfs_dir = debugfs_create_dir(dev_name(rkisp1->dev), NULL);
>  
> -       debugfs_create_ulong("data_loss", 0444, debug->debugfs_dir,
> -                            &debug->data_loss);
> -       debugfs_create_ulong("outform_size_err", 0444,  debug->debugfs_dir,
> -                            &debug->outform_size_error);
> -       debugfs_create_ulong("img_stabilization_size_error", 0444,
> -                            debug->debugfs_dir,
> -                            &debug->img_stabilization_size_error);
> -       debugfs_create_ulong("inform_size_error", 0444,  debug->debugfs_dir,
> -                            &debug->inform_size_error);
> -       debugfs_create_ulong("irq_delay", 0444,  debug->debugfs_dir,
> -                            &debug->irq_delay);
> -       debugfs_create_ulong("mipi_error", 0444, debug->debugfs_dir,
> -                            &debug->mipi_error);
> -       debugfs_create_ulong("stats_error", 0444, debug->debugfs_dir,
> -                            &debug->stats_error);
> -       debugfs_create_ulong("mp_stop_timeout", 0444, debug->debugfs_dir,
> -                            &debug->stop_timeout[RKISP1_MAINPATH]);
> -       debugfs_create_ulong("sp_stop_timeout", 0444, debug->debugfs_dir,
> -                            &debug->stop_timeout[RKISP1_SELFPATH]);
> -       debugfs_create_ulong("mp_frame_drop", 0444, debug->debugfs_dir,
> -                            &debug->frame_drop[RKISP1_MAINPATH]);
> -       debugfs_create_ulong("sp_frame_drop", 0444, debug->debugfs_dir,
> -                            &debug->frame_drop[RKISP1_SELFPATH]);
> -       debugfs_create_ulong("complete_frames", 0444, debug->debugfs_dir,
> -                            &debug->complete_frames);
> +       debugfs_create_file("counters", 0444, debug->debugfs_dir, rkisp1,
> +                           &rkisp1_debug_counters_fops);
>         debugfs_create_file("input_status", 0444, debug->debugfs_dir, rkisp1,
>                             &rkisp1_debug_input_status_fops);
>  
> -- 
> 2.39.2
>


From arnd at arndb.de  Fri Dec  1 07:31:38 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 01 Dec 2023 16:31:38 +0100
Subject: [PATCH] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <20231201064919.5mbmqo5fco7n3rgq@endnote>
References: <20231130231657.12715-1-francesco@dolcini.it>
 <20231201060346.GE5169@atomide.com> <20231201064919.5mbmqo5fco7n3rgq@endnote>
Message-ID: <855dfa50-a3a3-415a-8612-4da59f995ef0@app.fastmail.com>

On Fri, Dec 1, 2023, at 07:49, Nishanth Menon wrote:
> On 08:03-20231201, Tony Lindgren wrote:
>> * Francesco Dolcini <francesco at dolcini.it> [231130 23:17]:
>> > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
>> > is not adequate for embedded systems that use SoCs where it's common to
>> > have a large number of serial ports.
>> > 
>> > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
>> > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
>> > 
>> > This enables using the UART connected Bluetooth device on Verdin AM62
>> > board.
>> 
>> OK makes sense for distro use.
>> 
>> Disabling unused ports leads into port names shifting, which we still can't
>> easily tolerate until we have the DEVNAME:0.0 style addressing available for
>> ports. So for now we still depend CONFIG_SERIAL_8250_NR_UARTS, eventually
>> that too should become just a legacy ISA port array.. Meanwhile:
>> 
>> Reviewed-by: Tony Lindgren <tony at atomide.com>
>
> I'd prefer to get Arnd's view on the topic as well (I kind of
> recollect some historic discussion which I am not failing to trace
> that there usage model doesn't exceed 4 and aliases could be used to
> map these as required for the platform). The 8250 debate has been
> popping on and off over the years.. Sigh.. memories of [1] still haunt
> me.

I don't recall any reason to have the limit set to the default
of 4, other than possibly using excessive amounts of .data in
vmlinux, but we have other serial port drivers that just hardcode
a much larger value.

    Arnd


From eugen.hristev at collabora.com  Fri Dec  1 07:32:20 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Fri, 1 Dec 2023 17:32:20 +0200
Subject: [PATCH 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <4c15c9a4-bf04-492d-9e02-d630092b6caa@collabora.com>
References: <20231012230237.2676469-1-wenst@chromium.org>
 <20231012230237.2676469-7-wenst@chromium.org>
 <60beb523-292b-4c77-9030-1bfdfd73c140@collabora.com>
 <CAGXv+5GmjZbzLbxADoNXDiF8dTAwnxva29vuM0FG8vY-6wTJcQ@mail.gmail.com>
 <4c15c9a4-bf04-492d-9e02-d630092b6caa@collabora.com>
Message-ID: <525f20de-4eb8-4786-84b5-64eb989bdc4c@collabora.com>

On 11/27/23 15:05, AngeloGioacchino Del Regno wrote:
> Il 27/11/23 05:00, Chen-Yu Tsai ha scritto:
>> On Mon, Oct 23, 2023 at 5:05?PM Eugen Hristev
>> <eugen.hristev at collabora.com> wrote:
>>>
>>> On 10/13/23 02:02, Chen-Yu Tsai wrote:
>>>> Tentacruel and Tentacool are MT8186 based Chromebooks based on the
>>>> Krabby design.
>>>>
>>>> Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
>>>> convertible device with touchscreen and stylus.
>>>>
>>>> Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
>>>> device. It does not have a touchscreen or stylus.
>>>>
>>>> The two devices both have two variants. The difference is a second
>>>> source touchpad controller that shares the same address as the original,
>>>> but is incompatible.
>>>>
>>>> The extra SKU IDs for the Tentacruel devices map to different sensor
>>>> components attached to the Embedded Controller. These are not visible
>>>> to the main processor.
>>>>
>>>> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
>>>> ---
>>>>    arch/arm64/boot/dts/mediatek/Makefile         |    4 +
>>>>    .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  130 ++
>>>>    .../mt8186-corsola-tentacool-sku327681.dts    |   49 +
>>>>    .../mt8186-corsola-tentacool-sku327683.dts    |   26 +
>>>>    .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
>>>>    .../mt8186-corsola-tentacruel-sku262148.dts   |   28 +
>>>>    .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1704 +++++++++++++++++
>>>>    7 files changed, 1985 insertions(+)
>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
>>>>
>>
>> [...]
>>
>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
>>>> new file mode 100644
>>>> index 000000000000..42ebab1bafeb
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
>>>> @@ -0,0 +1,1704 @@
>>
>> [...]
>>
>>>
>>> Hi Chen-Yu,
>>>
>>> These two aud_gpio_tdm empty entries cause this message to be printed:
>>>
>>> [   12.949519] mt8186_mt6366_rt1019_rt5682s sound: there is not valid
>>> maps for state aud_gpio_tdm_off
>>> [   12.959025] mt8186_mt6366_rt1019_rt5682s sound: there is not valid
>>> maps for state aud_gpio_tdm_on
>>
>> I guess we need to teach the sound driver to ignore empty pinmux states?
> 
> ...and we need to teach to the bindings that the aud_gpio_tdm_{off,on} are
> optional states and can be omitted.

Hello Angelo,

The binding does not appear to specify any required states. Am I getting this
wrong? Hence, we can just remove these states from the DT node.


Hello Chen-Yu,

The error message comes from the pinctrl, from dt_to_map_one_config() .
I believe we can safely just remove these two if corsola device does not use TDM.
>From my perspective it is pointless to have two empty pinctrl states just for the
sake of it if there are no pins involved.
Please correct me if you have more knowledge about it.

Thanks,
Eugen

> 
> Cheers,
> Angelo
> 
>>
>> ChenYu
> 
> 
> 



From sudeep.holla at arm.com  Fri Dec  1 07:31:45 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 15:31:45 +0000
Subject: [PATCH] firmware: arm_scmi: Add protocol versioning checks
In-Reply-To: <20231201135858.2367651-1-cristian.marussi@arm.com>
References: <20231201135858.2367651-1-cristian.marussi@arm.com>
Message-ID: <20231201153145.emneavw53en4hsju@bogus>

On Fri, Dec 01, 2023 at 01:58:58PM +0000, Cristian Marussi wrote:
> Platform and agent supported protocols versions do not necessarily match.
> 
> When talking to an older platform SCMI server, supporting only older
> protocol versions, the kernel SCMI agent will downgrade the version of
> the used protocol to match the platform one and avoid compatibility issues.
> 
> In the case, instead, in which the agent happens to communicate with a
> newer platform server which can support newer protocol versions unknown to
> the agent, and potentially backward incompatible, the agent currently
> carries on, silently, in a best-effort approach.
> 
> Note that the SCMI server, by the specification, has no means to explicitly
> detect the protocol versions used by the agents, neither it is required to
> support multiple, older, protocol versions.
> 
> Add an explicit protocol version check to let the agent detect when this
> version mismatch happens and warn the user about this condition.
> 
> Signed-off-by: Cristian Marussi <cristian.marussi at arm.com>
> ---
> Any suggestion for a more meaningful warn message is very much welcome.

Looks good to me. I will apply soon with couple of changes as mentioned
below. Let me know if you agree/disagree.

> Based on sudeep/for-next/scmi/updates
> ---
>  drivers/firmware/arm_scmi/base.c      |  6 +++++-
>  drivers/firmware/arm_scmi/clock.c     |  6 +++++-
>  drivers/firmware/arm_scmi/driver.c    | 11 ++++++++++-
>  drivers/firmware/arm_scmi/perf.c      |  6 +++++-
>  drivers/firmware/arm_scmi/power.c     |  6 +++++-
>  drivers/firmware/arm_scmi/powercap.c  |  6 +++++-
>  drivers/firmware/arm_scmi/protocols.h |  8 +++++++-
>  drivers/firmware/arm_scmi/reset.c     |  6 +++++-
>  drivers/firmware/arm_scmi/sensors.c   |  6 +++++-
>  drivers/firmware/arm_scmi/system.c    |  6 +++++-
>  drivers/firmware/arm_scmi/voltage.c   |  6 +++++-
>  11 files changed, 62 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
> index a52f084a6a87..3f5c89ae5af2 100644
> --- a/drivers/firmware/arm_scmi/base.c
> +++ b/drivers/firmware/arm_scmi/base.c
> @@ -13,6 +13,9 @@
>  #include "common.h"
>  #include "notify.h"
>  
> +/* Must be updated only after ALL new features for that version are merged */

s/new/mandatory/

> +#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x20000
> +
>  #define SCMI_BASE_NUM_SOURCES		1
>  #define SCMI_BASE_MAX_CMD_ERR_COUNT	1024
>  
> index 3eb19ed6f148..46320f627066 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -1849,6 +1853,11 @@ scmi_alloc_init_protocol_instance(struct scmi_info *info,
>  	devres_close_group(handle->dev, pi->gid);
>  	dev_dbg(handle->dev, "Initialized protocol: 0x%X\n", pi->proto->id);
>  
> +	if (pi->version > proto->supported_version)
> +		dev_warn(handle->dev,
> +			 "Detected UNSUPPORTED version 0x%X for protocol 0x%X. Backward compatibility is NOT assured.\n",

s/UNSUPPORTED version/UNSUPPORTED newer version/ or higher instead of newer

-- 
Regards,
Sudeep


From geert at linux-m68k.org  Fri Dec  1 07:36:38 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 1 Dec 2023 16:36:38 +0100
Subject: [PATCH 03/14] clk: renesas: rzg2l-cpg: Add support for MSTOP
In-Reply-To: <55a0048a-7fa1-49cd-a70f-8f7d948adf27@tuxon.dev>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-4-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdVMpKVY8WX7dbtHfgnwgePH+i9+2BAumb37sFmqccb44g@mail.gmail.com>
 <CAMuHMdVWvVtFMUe+J9R2ZU8Hi5CGs0NQfwUxitganM85183KkA@mail.gmail.com> <55a0048a-7fa1-49cd-a70f-8f7d948adf27@tuxon.dev>
Message-ID: <CAMuHMdUb79rt2YVQO66_+8YcmAyS-PwFVcx0XfZVN-to3EB2SQ@mail.gmail.com>

Hi Claudiu,

On Mon, Nov 27, 2023 at 8:37?AM claudiu beznea <claudiu.beznea at tuxon.dev> wrote:
> On 24.11.2023 11:08, Geert Uytterhoeven wrote:
> > On Thu, Nov 23, 2023 at 5:35?PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> >> On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> >>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>>
> >>> RZ/{G2L, V2L, G3S} based CPG versions have support for saving extra
> >>> power when clocks are disabled by activating module standby. This is done
> >>> though MSTOP specific registers that are part of CPG. Each individual
> >>> module have one or more bits associated in one MSTOP register (see table
> >>> "Registers for Module Standby Mode" from HW manuals). Hardware manual
> >>> associates modules' clocks to one or more MSTOP bits. There are 3 mappings
> >>> available (identified by researching RZ/G2L, RZ/G3S, RZ/V2L HW manuals):
> >>>
> >>> case 1: N clocks mapped to N MSTOP bits (with N={0, ..., X})
> >>> case 2: N clocks mapped to 1 MSTOP bit  (with N={0, ..., X})
> >>> case 3: N clocks mapped to M MSTOP bits (with N={0, ..., X}, M={0, ..., Y})
> >>>
> >>> Case 3 has been currently identified on RZ/V2L for VCPL4 module.
> >>>
> >>> To cover all 3 cases the individual platform drivers will provide to
> >>> clock driver MSTOP register offset and associated bits in this register
> >>> as a bitmask and the clock driver will apply this bitmask to proper
> >>> MSTOP register.
> >>>
> >>> As most of the modules have more than one clock and these clocks are
> >>> mapped to 1 MSTOP bitmap that need to be applied to MSTOP registers,
> >>> to avoid switching the module to/out of standby when the module has
> >>> enabled/disabled clocks a counter has been associated to each module
> >>> (though struct mstop::count) which is incremented/decremented every
> >>> time a module's clock is enabled/disabled and the settings to MSTOP
> >>> register are applied only when the counter reaches zero (counter zero
> >>> means either 1st clock of the module is going to be enabled or all clocks
> >>> of the module are going to be disabled).

> > After giving this some more thought, it feels odd to derive the standby
> > state of a module from the state of its module clocks, while the latter
> > are already controlled through Runtime PM and a Clock Domain.
> >
> > A first alternative solution could be to drop the GENPD_FLAG_PM_CLK
> > flag from the RZ/G2L CPG clock domain, and provide your own
> > gpd_dev_ops.start() and .stop() callbacks that take care of both
> > module standby and clocks (through pm_clk_{resume,suspend}().
> > (See https://elixir.bootlin.com/linux/v6.7-rc2/source/drivers/base/power/domain.c#L2093
> > for the GENPD_FLAG_PM_CLK case).
> > That still leaves you with a need to associate an MSTOP register and
> > bitmask with a device through its module clocks.
> >
> > A second alternative solution could be to increase #power-domain-cells
> > from zero to one, and register individual PM Domains for each module,
> > and control module standby from the generic_pm_domain.power_{on,off}()
> > callbacks.  Devices would specify the module using the power-domains =
> > <&cpg <id> > property in DT, with <id> one of the to-be-added list of
> > modules in include/dt-bindings/clock/r9a08g045-cpg.h.  The RZ/G2L CPG
> > driver can handle the mapping from <id> to MSTOP register and bitmask.
> > This solution requires updates to DT, but you can keep compatibility
> > with old DTBs by only registering the new PM Domains when
> > #power-domain-cells is one.
> > The extra power saving would only be applicable with new DTBs, though.
>
> I prefer this alternative even though it cannot be applied for old DTBs, it
> looks to me that is more modular. What do you think?

I prefer the second alternative, too.

> The only thing is that MSTOP is not really a power off/on switch (if it
> would be implemented with generic_pm_domain.power_{on, off}) but is more

That's fine: Linux' PM Domains are fairly generic and abstract, and
not limited to pure power domains/areas.

> like a clock disable/enable functionality (it should not be an issue
> though, just saying)... According to manual (I'm referring to Figure 41.4
> Block Connection Overview for Module Standby Mode of HW manula of RZ/G3S),
> it disables/enables the module's bus clock.

Thanks for the pointer! That picture nicely shows the internal behavior.
For comparison, on SH/R-Mobile and R-Car SoCs there is a similar
internal structure, but it is less visible to the programmer:
there are no individual controls for each clock or reset that is
fed into a module.  These are all hidden behind a single Module
Stop resp. Reset control bit.  In Linux, we modeled the module stop
bit as a gate clock, controlled by Runtime PM through the Clock Domain's
.start()/.stop() callbacks.

Note that you also have to take into account Figure 41.2 ("Modules in
Power Domain").  When adding support for power transitions later, you
can register a PM Domain representing PD_ISOVCC, and use that as the
parent PM Domain for the individual PM Domains for modules belonging
to PD_ISOVCC.  All of that can be handled in the driver, and would
not need any changes to DT.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From francesco at dolcini.it  Fri Dec  1 07:39:29 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 16:39:29 +0100
Subject: [PATCH v2 2/2] arm64: dts: freescale: verdin-imx8mp: add support to mallow board
In-Reply-To: <20231201153929.26590-1-francesco@dolcini.it>
References: <20231201153929.26590-1-francesco@dolcini.it>
Message-ID: <20231201153929.26590-3-francesco@dolcini.it>

From: Joao Paulo Goncalves <joao.goncalves at toradex.com>

Add Toradex Verdin IMX8MP Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

Signed-off-by: Joao Paulo Goncalves <joao.goncalves at toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
v2:
 - remove dt nodes: eeprom_display_adapter, hwmon
 - correct hwmon_temp node compatible to "ti,tmp1075"
---
 arch/arm64/boot/dts/freescale/Makefile        |   2 +
 .../dts/freescale/imx8mp-verdin-mallow.dtsi   | 199 ++++++++++++++++++
 .../imx8mp-verdin-nonwifi-mallow.dts          |  18 ++
 .../freescale/imx8mp-verdin-wifi-mallow.dts   |  18 ++
 4 files changed, 237 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-mallow.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 6d83f84090e1..0a94be0430fc 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -123,9 +123,11 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-venice-gw74xx.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-venice-gw7905-2x.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-nonwifi-dahlia.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-nonwifi-dev.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-nonwifi-mallow.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-nonwifi-yavia.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-dahlia.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-dev.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-mallow.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-yavia.dtb
 
 imx8mp-tqma8mpql-mba8mpxl-lvds-dtbs += imx8mp-tqma8mpql-mba8mpxl.dtb imx8mp-tqma8mpql-mba8mpxl-lvds.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi
new file mode 100644
index 000000000000..8482393f3cac
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ *
+ * Common dtsi for Verdin IMX8MP SoM on Mallow carrier board
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-plus
+ * https://www.toradex.com/products/carrier-board/mallow-carrier-board
+ */
+
+#include <dt-bindings/leds/common.h>
+
+/ {
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_leds>;
+
+		/* SODIMM 52 - USER_LED_1_RED */
+		led-0 {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <1>;
+			gpios = <&gpio3 0 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 54 - USER_LED_1_GREEN */
+		led-1 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <1>;
+			gpios = <&gpio3 1 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 56 - USER_LED_2_RED */
+		led-2 {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <2>;
+			gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 58 - USER_LED_2_GREEN */
+		led-3 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <2>;
+			gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+&backlight {
+	power-supply = <&reg_3p3v>;
+};
+
+/* Verdin SPI_1 */
+&ecspi1 {
+	pinctrl-0 = <&pinctrl_ecspi1>, <&pinctrl_tpm_cs>;
+	cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>, <&gpio3 16 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	tpm at 1 {
+		compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+		reg = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_tpm_irq>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+		spi-max-frequency = <18500000>;
+	};
+};
+
+/* EEPROM on Mallow */
+&eeprom_carrier_board {
+	status = "okay";
+};
+
+/* Verdin ETH_1 */
+&eqos {
+	status = "okay";
+};
+
+/* Verdin CAN_1 */
+&flexcan1 {
+	status = "okay";
+};
+
+/* Verdin CAN_2 */
+&flexcan2 {
+	status = "okay";
+};
+
+/* Temperature sensor on Mallow */
+&hwmon_temp {
+	compatible = "ti,tmp1075";
+	status = "okay";
+};
+
+/* Verdin I2C_2_DSI */
+&i2c2 {
+	status = "okay";
+};
+
+/* Verdin I2C_4_CSI */
+&i2c3 {
+	status = "okay";
+};
+
+/* Verdin I2C_1 */
+&i2c4 {
+	status = "okay";
+};
+
+/* Verdin PCIE_1 */
+&pcie {
+	status = "okay";
+};
+
+&pcie_phy {
+	status = "okay";
+};
+
+/* Verdin PWM_1 */
+&pwm1 {
+	status = "okay";
+};
+
+/* Verdin PWM_2 */
+&pwm2 {
+	status = "okay";
+};
+
+/* Verdin PWM_3_DSI */
+&pwm3 {
+	status = "okay";
+};
+
+&reg_usdhc2_vmmc {
+	vin-supply = <&reg_3p3v>;
+};
+
+/* Verdin UART_1 */
+&uart1 {
+	status = "okay";
+};
+
+/* Verdin UART_2 */
+&uart2 {
+	status = "okay";
+};
+
+/* Verdin UART_3 */
+&uart3 {
+	status = "okay";
+};
+
+/* Verdin USB_1 */
+&usb3_0 {
+	status = "okay";
+};
+
+&usb3_phy0 {
+	status = "okay";
+};
+
+/* Verdin USB_2 */
+&usb3_1 {
+	status = "okay";
+};
+
+&usb3_phy1 {
+	status = "okay";
+};
+
+/* Verdin SD_1 */
+&usdhc2 {
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_leds: ledsgrp {
+		fsl,pins =
+			<MX8MP_IOMUXC_NAND_ALE__GPIO3_IO00	0x106>, /* SODIMM 52 */
+			<MX8MP_IOMUXC_NAND_CE0_B__GPIO3_IO01	0x106>, /* SODIMM 54 */
+			<MX8MP_IOMUXC_NAND_DATA00__GPIO3_IO06	0x106>, /* SODIMM 56 */
+			<MX8MP_IOMUXC_NAND_DATA01__GPIO3_IO07	0x106>; /* SODIMM 58 */
+	};
+
+	pinctrl_tpm_cs: tpmcsgrp {
+		fsl,pins =
+			<MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16	0x82>; /* SODIMM 64 */
+	};
+
+	pinctrl_tpm_irq: tpmirqgrp {
+		fsl,pins =
+			<MX8MP_IOMUXC_NAND_DQS__GPIO3_IO14	0x16>; /* SODIMM 66 */
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-mallow.dts b/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-mallow.dts
new file mode 100644
index 000000000000..6a536a4964bb
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-mallow.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ */
+
+/dts-v1/;
+
+#include "imx8mp-verdin.dtsi"
+#include "imx8mp-verdin-nonwifi.dtsi"
+#include "imx8mp-verdin-mallow.dtsi"
+
+/ {
+	model = "Toradex Verdin iMX8M Plus on Mallow Board";
+	compatible = "toradex,verdin-imx8mp-nonwifi-mallow",
+		     "toradex,verdin-imx8mp-nonwifi",
+		     "toradex,verdin-imx8mp",
+		     "fsl,imx8mp";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-mallow.dts b/arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-mallow.dts
new file mode 100644
index 000000000000..08b7aef3fdde
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-mallow.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ */
+
+/dts-v1/;
+
+#include "imx8mp-verdin.dtsi"
+#include "imx8mp-verdin-wifi.dtsi"
+#include "imx8mp-verdin-mallow.dtsi"
+
+/ {
+	model = "Toradex Verdin iMX8M Plus WB on Mallow Board";
+	compatible = "toradex,verdin-imx8mp-wifi-mallow",
+		     "toradex,verdin-imx8mp-wifi",
+		     "toradex,verdin-imx8mp",
+		     "fsl,imx8mp";
+};
-- 
2.25.1



From francesco at dolcini.it  Fri Dec  1 07:39:27 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 16:39:27 +0100
Subject: [PATCH v2 0/2] arm64: dts: freescale: verdin-imx8mp: add support to mallow board
Message-ID: <20231201153929.26590-1-francesco@dolcini.it>

From: Francesco Dolcini <francesco.dolcini at toradex.com>

Add Toradex Verdin IMX8MP Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

v1:
 - https://lore.kernel.org/all/20231129164022.143340-1-francesco at dolcini.it/
v2:
 - remove dt nodes: eeprom_display_adapter, hwmon
 - add Acked-by: Krzysztof
 - correct hwmon_temp node compatible to "ti,tmp1075"

Joao Paulo Goncalves (2):
  dt-bindings: arm: fsl: add verdin imx8mp mallow board
  arm64: dts: freescale: verdin-imx8mp: add support to mallow board

 .../devicetree/bindings/arm/fsl.yaml          |   2 +
 arch/arm64/boot/dts/freescale/Makefile        |   2 +
 .../dts/freescale/imx8mp-verdin-mallow.dtsi   | 199 ++++++++++++++++++
 .../imx8mp-verdin-nonwifi-mallow.dts          |  18 ++
 .../freescale/imx8mp-verdin-wifi-mallow.dts   |  18 ++
 5 files changed, 239 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-mallow.dts

-- 
2.25.1



From hawk at kernel.org  Fri Dec  1 07:39:32 2023
From: hawk at kernel.org (Jesper Dangaard Brouer)
Date: Fri, 1 Dec 2023 16:39:32 +0100
Subject: [PATCH bpf-next v2 0/3] xsk: TX metadata txtime support
In-Reply-To: <6569f71bad00d_138af5294d@willemb.c.googlers.com.notmuch>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <d4f99931-442c-4cd7-b3cf-80d8681a2986@kernel.org>
 <PH0PR11MB58306C2E50009A6E22F9DAD3D881A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <6569f71bad00d_138af5294d@willemb.c.googlers.com.notmuch>
Message-ID: <179a4581-f7df-4eb1-ab67-8d65f856a2fe@kernel.org>



On 12/1/23 16:09, Willem de Bruijn wrote:
> Song, Yoong Siang wrote:
>> On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer <hawk at kernel.org> wrote:
>>> On 12/1/23 07:24, Song Yoong Siang wrote:
>>>> This series expands XDP TX metadata framework to include ETF HW offload.
>>>>
>>>> Changes since v1:
>>>> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF)
>>>> - rename launch-time to txtime
>>>>
>>>
>>> I strongly disagree with this renaming (sorry to disagree with Willem).
>>>
>>> The i210 and i225 chips call this LaunchTime in their programmers
>>> datasheets, and even in the driver code[1].
>>>
>>> Using this "txtime" name in the code is also confusing, because how can
>>> people reading the code know the difference between:
>>>   - tmo_request_timestamp and tmo_request_txtime
>>>
>>
>> Hi Jesper and Willem,
>>
>> How about using "launch_time" for the flag/variable and
>> "Earliest TxTime First" for the description/comments?
> 

I don't follow why you are calling the feature:
  - "Earliest TxTime First" (ETF).
  - AFAIK this just reference an qdisc name (that most don't know exists)


> I don't particularly care which term we use, as long as we're
> consistent. Especially, don't keep introducing new synonyms.
> 
> The fact that one happens to be one vendor's marketing term does not
> make it preferable, IMHO. On the contrary.
>

These kind of hardware features are defined as part of Time Sensitive
Networking (TSN).
I believe these TSN features are defined as part of IEEE 802.1Qbv (2015)
and according to Wikipedia[2] incorporated into IEEE 802.1Q.

[2] https://en.wikipedia.org/wiki/Time-Sensitive_Networking


> SO_TXTIME is in the ABI, and EDT has been used publicly in kernel
> patches and conference talks, e.g., Van Jacobson's Netdev 0x12
> keynote. Those are vendor agnostic commonly used terms.
> 

I agree that EDT (Earliest Departure Time) have become a thing and term
in our community.
We could associate this feature with this.
I do fear what hardware behavior will be it if I e.g. ask it to send a
packet 2 sec in the future on i225 which max support 1 sec.
Will hardware send it at 1 sec?
Because then I'm violating the *Earliest* Departure Time.


> But as long as Launch Time is not an Intel only trademark, fine to
> select that.

The IEEE 802.1Qbv is sometimes called Time-Aware Shaper (TAS), but I
don't like to for us to name this after this.  This features is simply
taking advantage of exposing one of the hardware building blocks
(controlling/setting packet "launch time") that can be used for
implementing a TAS.

I like the name "launch time" because it doesn't get easily confused
with other timestamps, and intuitively describes packet will be send at
a specific time (likely in future).

--Jesper


From geert at linux-m68k.org  Fri Dec  1 07:41:58 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 1 Dec 2023 16:41:58 +0100
Subject: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
In-Reply-To: <TYCPR01MB112696C301D750A915F2661688681A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
References: <20231201110840.37408-1-biju.das.jz@bp.renesas.com>
 <20231201110840.37408-7-biju.das.jz@bp.renesas.com> <CAMuHMdWh3fTzQP5+mGF3u8LACg-5tQDZcyExvgREpxKd6iee4Q@mail.gmail.com>
 <TYCPR01MB112696C301D750A915F2661688681A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
Message-ID: <CAMuHMdXHpE079eLAJjcdsbz6=Y6hux267AhqJow6HESCaf7EXQ@mail.gmail.com>

Hi Biju,

On Fri, Dec 1, 2023 at 4:02?PM Biju Das <biju.das.jz at bp.renesas.com> wrote:
> > From: Geert Uytterhoeven <geert at linux-m68k.org>
> > On Fri, Dec 1, 2023 at 12:09?PM Biju Das <biju.das.jz at bp.renesas.com>
> > wrote:
> > > Enable the config for the Renesas DA9062 PMIC and RTC, as it is
> > > populated on RZ/G2UL SMARC EVK.
> > >
> > > Signed-off-by: Biju Das <biju.das.jz at bp.renesas.com>
> >
> > Thanks for your patch!
> >
> > LGTM, but I would have expected (at least)
> >
> >     CONFIG_INPUT_DA9063_ONKEY=m
> >
> > too, cfr. my comments on patch 5/6.
>
> I have tested this, but I get "da9063-onkey da9062-onkey: error -ENXIO: IRQ ONKEY not found"
> So, I won't be able to test onkey events. So plaaning to disable this node.

Indeed, currently drivers/input/misc/da9063_onkey.c requires an
interrupt to function.  I wonder if it can be made to work using a
timer and pure polling...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From geert at linux-m68k.org  Fri Dec  1 07:59:53 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 1 Dec 2023 16:59:53 +0100
Subject: [PATCH 04/14] clk: renesas: r9a08g045-cpg: Add clock and reset
 support for ETH0 and ETH1
In-Reply-To: <20231120070024.4079344-5-claudiu.beznea.uj@bp.renesas.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com> <20231120070024.4079344-5-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdWwn8xcKX3vgawtGqksuMM3CKZx=3k6EKP3kDFZxbocdA@mail.gmail.com>

Hi Claudiu,

On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> RZ/G3S has 2 Gigabit Ethernet interfaces available. Add clock and reset
> support for both of them.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Thanks for your patch!

> --- a/drivers/clk/renesas/r9a08g045-cpg.c
> +++ b/drivers/clk/renesas/r9a08g045-cpg.c
> @@ -217,6 +219,16 @@ static const struct rzg2l_mod_clk r9a08g045_mod_clks[] = {
>                                         MSTOP(PERI_COM, BIT(11))),
>         DEF_MOD("sdhi2_aclk",           R9A08G045_SDHI2_ACLK, R9A08G045_CLK_P1, 0x554, 11,
>                                         MSTOP(PERI_COM, BIT(11))),
> +       DEF_COUPLED("eth0_axi",         R9A08G045_ETH0_CLK_AXI, R9A08G045_CLK_M0, 0x57c, 0,
> +                                       MSTOP(PERI_COM, BIT(2))),
> +       DEF_COUPLED("eth0_chi",         R9A08G045_ETH0_CLK_CHI, R9A08G045_CLK_ZT, 0x57c, 0,
> +                                       MSTOP(PERI_COM, BIT(2))),
> +       DEF_MOD("eth0_refclk",          R9A08G045_ETH0_REFCLK, R9A08G045_CLK_HP, 0x57c, 8, 0),
> +       DEF_COUPLED("eth1_axi",         R9A08G045_ETH1_CLK_AXI, R9A08G045_CLK_M0, 0x57c, 1,
> +                                       MSTOP(PERI_COM, BIT(3))),
> +       DEF_COUPLED("eth1_chi",         R9A08G045_ETH1_CLK_CHI, R9A08G045_CLK_ZT, 0x57c, 1,
> +                                       MSTOP(PERI_COM, BIT(3))),
> +       DEF_MOD("eth1_refclk",          R9A08G045_ETH1_REFCLK, R9A08G045_CLK_HP, 0x57c, 9, 0),
>         DEF_MOD("scif0_clk_pck",        R9A08G045_SCIF0_CLK_PCK, R9A08G045_CLK_P0, 0x584, 0,
>                                         MSTOP(MCPU2, BIT(1))),
>         DEF_MOD("gpio_hclk",            R9A08G045_GPIO_HCLK, R9A08G045_OSCCLK, 0x598, 0, 0),

LGTM, pending the MSTOP() part.

Is the MSTOP() handling needed to function? IIUIC, all modules are
enabled
out of reset.
If it is not needed, I can take this patch and remove the MSTOP() part.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From tglx at linutronix.de  Fri Dec  1 08:09:10 2023
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 01 Dec 2023 17:09:10 +0100
Subject: [PATCH 00/21] Initial cleanups for vCPU hotplug
In-Reply-To: <2023120131-leotard-deprecate-4e27@gregkh>
References: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk> <87plzqxiyl.ffs@tglx>
 <2023120131-leotard-deprecate-4e27@gregkh>
Message-ID: <87jzpxykex.ffs@tglx>

On Fri, Dec 01 2023 at 12:28, Greg Kroah-Hartman wrote:
> I can take them, will do so this weekend when I catch up on patches on a
> 14+ hour flight...

Thanks a lot!



From peter.griffin at linaro.org  Fri Dec  1 08:09:06 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:06 +0000
Subject: [PATCH v5 01/20] dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-2-peter.griffin@linaro.org>

Add gs101-pmu compatible to the bindings documentation.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index 28e2cb50d85e..ce1bba980961 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -15,6 +15,7 @@ select:
     compatible:
       contains:
         enum:
+          - google,gs101-pmu
           - samsung,exynos3250-pmu
           - samsung,exynos4210-pmu
           - samsung,exynos4212-pmu
@@ -35,6 +36,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - google,gs101-pmu
               - samsung,exynos3250-pmu
               - samsung,exynos4210-pmu
               - samsung,exynos4212-pmu
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:05 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:05 +0000
Subject: [PATCH v5 00/20]  Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board
Message-ID: <20231201160925.3136868-1-peter.griffin@linaro.org>

Hi folks,

Thanks to everyone who reviewed the previous rounds. V5 incorporates
the review feedback received so far, and is rebased onto linux-next as
per Krzysztof request to incorporate all his dt-binding changes for
exynos.

As this series spans multiple subsytems the expectation is that Krzysztof
will apply the whole series through the Samsung SoC tree. If the relevant
subsystem maintainers can give a acked-by or reviewed-by on the relevant
patches that would be most appreciated!

This series adds initial SoC support for the GS101 SoC and also initial board
support for Pixel 6 phone (Oriole).

The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
(raven) phones. Currently DT is added for the gs101 SoC and Oriole.
As you can see from the patches the SoC is based on a Samsung Exynos SoC,
and therefore lots of the low level Exynos drivers can be re-used.

The support added in this series consists of:
* cpus
* pinctrl
* CCF implementation of cmu_top, cmu_misc & cmu_apm
* watchdog
* USI uart
* gpio

This is enough to boot through to a busybox initramfs and shell using an
upstream kernel though :) More platform support will be added over the
following weeks and months.

For further information on how to build and flash the upstream kernel on your
Pixel 6, with a prebuilt busybox initramfs please refer to the script and
README.md here:

https://git.codelinaro.org/linaro/googlelt/pixelscripts

Note: Booting without a dtbo works with some versions of the bootloader
but crashes on others. Later versions aren't necessarily better. You can
get the bootloader version with `fastboot getvar version-bootloader`
Known good bootloader versions are: -
- slider-1.3-11000330
- slider-1.2-9152140
Known to crash without dtbo
- slider-1.3-10780582

kind regards,

Peter.

lore v4: https://lore.kernel.org/linux-arm-kernel/20231120212037.911774-1-peter.griffin at linaro.org/T/
pw   v3: https://patchwork.kernel.org/project/linux-samsung-soc/cover/20231011184823.443959-1-peter.griffin at linaro.org/
lore v2: https://lore.kernel.org/all/20231010224928.2296997-1-peter.griffin at linaro.org/
lore v1: https://lore.kernel.org/linux-arm-kernel/20231005155618.700312-1-peter.griffin at linaro.org/

Changes since v4:
 - clk-gs101: order cmu_top by register address, fix incorrect mux widths,
   add missing mux/div/gates (Andre)
 - google,gs101.h: add missing space in comment (Andre)
 - ckl-gs101:google,gs101.h add all remaining gates for cmu_misc and cmu_apm
 - update pmu dt labels (Krzysztof)
 - Remove uart16 rts/tx gpio definitions (Krzysztof)
 - Fixup various dts cosmetic nits (using consts, alignments,
   names) (Sam/Krzysztof)
 - Add more specific compatibles for arm cpu's and pmu (Sam)
 - Use address-cells 1 and ranges property for SoC addresses (Sam)
 - Encapsulate uart node in USI node (Sam)
 - Remove earlycon from bootargs
 - s3c2410_wdt: Reword QUIRK_HAS_DBGACK_BIT docs and add comment (Guenter)
 - s3c2410_wdt: Reorder DBGACK_MASK functionality first, gs101
   SoC second (Sam/Krzysztof)
 
Changes since v3:
 - Add reviewed-by and tested-by tags
 - google,gs101-clock.yaml: move Required to before Allof,
   enum for cmu*top/misc (Krzysztof)
 - samsung-wdt.yaml: stick to 80chars (Sam)
 - google.yaml - remove new line
 - samsung,pinctrl-wakeup-interrupt: sort alphabetically (RobH)
 - gs101-oriole.dts: update gpio-keys pinctrl-0 phandle for keys (Stephen)
 - samsung,exynos-sysreg.yaml - Alphabetical order (RobH)
 - pinctrl-exynos: update/move comments, slight cosmetic changes (Sam)
 - samsung_tty.c: update to generic drv_data name/macro (Arnd)
 - samsung_uart.yaml: make samsung,uart-fifosize required for gs101-uart (Arnd)
 - pinctrl-exynos: Remove eint irqs from alive pin controller node (Peter/Rob)
 - Fixup kernel test robot unused const variable warnings
 - clk-gs101: Update to mout_cmu_eh_bus to CLK_CON_MUX_MUX_CLKCMU_EH_BUS
   (Chanwoo)
 - clk-gs101: Update g3aa gout/dout/mout names to g3aa_g3aa for
   consistency (Chanwoo)
 - Remove .eint_gpio_init() cb on alive, alive_far, gsacore & gsactrl
   banks (Sam)
 - s3c2410_wdt: Drop windowed watchdog mode for now (Peter)
 - s3c2410_wdt: Separate gs101 SoC support from dbgack feature (Sam)
 - Move dts to arch/arm64/boot/dts/exynos/google directory (Krzysztof)

Changes since v2:
 - Fixup pinctrl at 174d0000: interrupts: [..] is too long DTC warning (Tudor)
 - Add missing windowed watchdog code (Guenter)
 - Fixup UART YAML bindings error (Krzysztof)
 - gs101.dtsi add missing serial_0 alias (me)
 - samsung_tty.c: fixup gs101_serial_drv_data so fifosize is obtained from DT
 
Changes since v1:
 - Remove irq/gs101.h and replace macros with irq numbers globally
 - exynos-pmu - keep alphabetical order
 - add cmu_apm to clock bindings documentation
 - sysreg bindings - remove superfluous `google,gs101-sysreg`
 - watchdog bindings - Alphanumerical order, update gs201 comment
 - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
 - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
 - samsung,pinctrl- add google,gs101-wakeup-eint compatible
 - clk-pll: fixup typos
 - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
 - clk-gs101: fix alphabetical order
 - clk-gs101: cmu_apm: fixup typo and missing empty entry
 - clk-gs101: cmu_misc: remove clocks that were being registered twice
 - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON
   bitfield
 - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins
   as well
 - pinctrl: gs101: rename bank_type_6/7 structs to be more specific,
   split from filter
 - watchdog: s3c2410_wdt: remove dev_info prints
 - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node
   name, blank lines add SoC node, split dts and dtsi into separate patches,
   remove 'DVT' suffix
 - gs101-oriole.dtso: Remove overlay until board_id is documented properly
 - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
 - gpio-keys: update linux,code to use input-event-code macros
 - add dedicated gs101-uart compatible

Peter Griffin (19):
  dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
  dt-bindings: clock: Add Google gs101 clock management unit bindings
  dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
    compatibles to GS101
  dt-bindings: watchdog: Document Google gs101 watchdog bindings
  dt-bindings: arm: google: Add bindings for Google ARM platforms
  dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
  dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
  dt-bindings: serial: samsung: Add google-gs101-uart compatible
  dt-bindings: serial: samsung: Make samsung,uart-fifosize required
    property
  clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
  clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm support
  pinctrl: samsung: Add filter selection support for alive banks
  pinctrl: samsung: Add gs101 SoC pinctrl configuration
  watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bit
  watchdog: s3c2410_wdt: Add support for Google gs101 SoC
  tty: serial: samsung: Add gs101 compatible and common
    fifoszdt_serial_drv_data
  arm64: dts: exynos: google: Add initial Google gs101 SoC support
  arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
  MAINTAINERS: add entry for Google Tensor SoC

Tudor Ambarus (1):
  dt-bindings: soc: samsung: usi: add google,gs101-usi compatible

 .../devicetree/bindings/arm/google.yaml       |   53 +
 .../bindings/clock/google,gs101-clock.yaml    |  110 +
 .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
 .../bindings/pinctrl/samsung,pinctrl.yaml     |    1 +
 .../bindings/serial/samsung_uart.yaml         |   11 +
 .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
 .../bindings/soc/samsung/exynos-usi.yaml      |    3 +
 .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
 .../bindings/watchdog/samsung-wdt.yaml        |    8 +-
 MAINTAINERS                                   |   10 +
 arch/arm64/boot/dts/exynos/Makefile           |    2 +
 arch/arm64/boot/dts/exynos/google/Makefile    |    4 +
 .../boot/dts/exynos/google/gs101-oriole.dts   |  105 +
 .../boot/dts/exynos/google/gs101-pinctrl.dtsi | 1250 +++++++++
 .../boot/dts/exynos/google/gs101-pinctrl.h    |   33 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  476 ++++
 drivers/clk/samsung/Makefile                  |    1 +
 drivers/clk/samsung/clk-gs101.c               | 2495 +++++++++++++++++
 drivers/clk/samsung/clk-pll.c                 |    6 +
 drivers/clk/samsung/clk-pll.h                 |    3 +
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  159 ++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |   91 +-
 drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
 drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   23 +
 drivers/tty/serial/samsung_tty.c              |   16 +
 drivers/watchdog/s3c2410_wdt.c                |   74 +-
 include/dt-bindings/clock/google,gs101.h      |  392 +++
 28 files changed, 5370 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi
 create mode 100644 drivers/clk/samsung/clk-gs101.c
 create mode 100644 include/dt-bindings/clock/google,gs101.h

-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:08 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:08 +0000
Subject: [PATCH v5 03/20] dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-4-peter.griffin@linaro.org>

GS101 has three different SYSREG controllers, add dedicated
compatibles for them to the documentation.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../bindings/soc/samsung/samsung,exynos-sysreg.yaml         | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
index 2de4301a467d..127f4ffde76a 100644
--- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
@@ -22,6 +22,12 @@ properties:
               - tesla,fsd-fsys1-sysreg
               - tesla,fsd-peric-sysreg
           - const: syscon
+      - items:
+          - enum:
+              - google,gs101-apm-sysreg
+              - google,gs101-peric0-sysreg
+              - google,gs101-peric1-sysreg
+          - const: syscon
       - items:
           - enum:
               - samsung,exynos5433-cam0-sysreg
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:07 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:07 +0000
Subject: [PATCH v5 02/20] dt-bindings: clock: Add Google gs101 clock management unit bindings
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-3-peter.griffin@linaro.org>

Provide dt-schema documentation for Google gs101 SoC clock controller.
Currently this adds support for cmu_top, cmu_misc and cmu_apm.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../bindings/clock/google,gs101-clock.yaml    | 110 +++++
 include/dt-bindings/clock/google,gs101.h      | 392 ++++++++++++++++++
 2 files changed, 502 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 include/dt-bindings/clock/google,gs101.h

diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
new file mode 100644
index 000000000000..4612886fcc15
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/google,gs101-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google GS101 SoC clock controller
+
+maintainers:
+  - Peter Griffin <peter.griffin at linaro.org>
+
+description: |
+  Google GS101 clock controller is comprised of several CMU units, generating
+  clocks for different domains. Those CMU units are modeled as separate device
+  tree nodes, and might depend on each other. The root clock in that clock tree
+  is OSCCLK (24.576 MHz). That external clock must be defined as a fixed-rate
+  clock in dts.
+
+  CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
+  dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP.
+
+  Each clock is assigned an identifier and client nodes can use this identifier
+  to specify the clock which they consume. All clocks available for usage
+  in clock consumer nodes are defined as preprocessor macros in
+  'dt-bindings/clock/gs101.h' header.
+
+properties:
+  compatible:
+    enum:
+      - google,gs101-cmu-top
+      - google,gs101-cmu-apm
+      - google,gs101-cmu-misc
+
+  clocks:
+    minItems: 1
+    maxItems: 2
+
+  clock-names:
+    minItems: 1
+    maxItems: 2
+
+  "#clock-cells":
+    const: 1
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - "#clock-cells"
+  - clocks
+  - clock-names
+  - reg
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - google,gs101-cmu-top
+              - google,gs101-cmu-apm
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+
+        clock-names:
+          items:
+            - const: oscclk
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-misc
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+            - description: Misc bus clock (from CMU_TOP)
+
+        clock-names:
+          items:
+            - const: oscclk
+            - const: dout_cmu_misc_bus
+
+additionalProperties: false
+
+examples:
+  # Clock controller node for CMU_TOP
+  - |
+    #include <dt-bindings/clock/google,gs101.h>
+    soc {
+        #address-cells = <2>;
+        #size-cells = <1>;
+
+        cmu_top: clock-controller at 1e080000 {
+            compatible = "google,gs101-cmu-top";
+            reg = <0x0 0x1e080000 0x8000>;
+            #clock-cells = <1>;
+            clocks = <&ext_24_5m>;
+            clock-names = "oscclk";
+        };
+    };
+
+...
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
new file mode 100644
index 000000000000..9f280f74578a
--- /dev/null
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -0,0 +1,392 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2023 Linaro Ltd.
+ * Author: Peter Griffin <peter.griffin at linaro.org>
+ *
+ * Device Tree binding constants for Google gs101 clock controller.
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
+#define _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
+
+/* CMU_TOP PLL */
+#define CLK_FOUT_SHARED0_PLL		1
+#define CLK_FOUT_SHARED1_PLL		2
+#define CLK_FOUT_SHARED2_PLL		3
+#define CLK_FOUT_SHARED3_PLL		4
+#define CLK_FOUT_SPARE_PLL		5
+
+/* CMU_TOP MUX */
+#define CLK_MOUT_SHARED0_PLL		6
+#define CLK_MOUT_SHARED1_PLL		7
+#define CLK_MOUT_SHARED2_PLL		8
+#define CLK_MOUT_SHARED3_PLL		9
+#define CLK_MOUT_SPARE_PLL		10
+#define CLK_MOUT_BO_BUS			11
+#define CLK_MOUT_BUS0_BUS		12
+#define CLK_MOUT_BUS1_BUS		13
+#define CLK_MOUT_BUS2_BUS		14
+#define CLK_MOUT_CIS_CLK0		15
+#define CLK_MOUT_CIS_CLK1		16
+#define CLK_MOUT_CIS_CLK2		17
+#define CLK_MOUT_CIS_CLK3		18
+#define CLK_MOUT_CIS_CLK4		19
+#define CLK_MOUT_CIS_CLK5		20
+#define CLK_MOUT_CIS_CLK6		21
+#define CLK_MOUT_CIS_CLK7		22
+#define CLK_MOUT_CMU_BOOST		23
+#define CLK_MOUT_BOOST_OPTION1		24
+#define CLK_MOUT_CORE_BUS		25
+#define CLK_MOUT_CPUCL0_DBG		26
+#define CLK_MOUT_CPUCL0_SWITCH		27
+#define CLK_MOUT_CPUCL1_SWITCH		28
+#define CLK_MOUT_CPUCL2_SWITCH		29
+#define CLK_MOUT_CSIS_BUS		30
+#define CLK_MOUT_DISP_BUS		31
+#define CLK_MOUT_DNS_BUS		32
+#define CLK_MOUT_DPU_BUS		33
+#define CLK_MOUT_EH_BUS			34
+#define CLK_MOUT_G2D_G2D		35
+#define CLK_MOUT_G2D_MSCL		36
+#define CLK_MOUT_G3AA_G3AA		37
+#define CLK_MOUT_G3D_BUSD		38
+#define CLK_MOUT_G3D_GLB		39
+#define CLK_MOUT_G3D_SWITCH		40
+#define CLK_MOUT_GDC_GDC0		41
+#define CLK_MOUT_GDC_GDC1		42
+#define CLK_MOUT_GDC_SCSC		43
+#define CLK_MOUT_CMU_HPM		44
+#define CLK_MOUT_HSI0_BUS		45
+#define CLK_MOUT_HSI0_DPGTC		46
+#define CLK_MOUT_HSI0_USB31DRD		47
+#define CLK_MOUT_HSI0_USBDPDGB		48
+#define CLK_MOUT_HSI1_BUS		49
+#define CLK_MOUT_HSI1_PCIE		50
+#define CLK_MOUT_HSI2_BUS		51
+#define CLK_MOUT_HSI2_MMC_CARD		52
+#define CLK_MOUT_HSI2_PCIE		53
+#define CLK_MOUT_HSI2_UFS_EMBD		54
+#define CLK_MOUT_IPP_BUS		55
+#define CLK_MOUT_ITP_BUS		56
+#define CLK_MOUT_MCSC_ITSC		57
+#define CLK_MOUT_MCSC_MCSC		58
+#define CLK_MOUT_MFC_MFC		59
+#define CLK_MOUT_MIF_BUSP		60
+#define CLK_MOUT_MIF_SWITCH		61
+#define CLK_MOUT_MISC_BUS		62
+#define CLK_MOUT_MISC_SSS		63
+#define CLK_MOUT_PDP_BUS		64
+#define CLK_MOUT_PDP_VRA		65
+#define CLK_MOUT_PERIC0_BUS		66
+#define CLK_MOUT_PERIC0_IP		67
+#define CLK_MOUT_PERIC1_BUS		68
+#define CLK_MOUT_PERIC1_IP		69
+#define CLK_MOUT_TNR_BUS		70
+#define CLK_MOUT_TOP_BOOST_OPTION1	71
+#define CLK_MOUT_TOP_CMUREF		72
+#define CLK_MOUT_TPU_BUS		73
+#define CLK_MOUT_TPU_TPU		74
+#define CLK_MOUT_TPU_TPUCTL		75
+#define CLK_MOUT_TPU_UART		76
+#define CLK_MOUT_CMU_CMUREF		77
+
+/* CMU_TOP Dividers */
+#define CLK_DOUT_BO_BUS			78
+#define CLK_DOUT_BUS0_BUS		79
+#define CLK_DOUT_BUS1_BUS		80
+#define CLK_DOUT_BUS2_BUS		81
+#define CLK_DOUT_CIS_CLK0		82
+#define CLK_DOUT_CIS_CLK1		83
+#define CLK_DOUT_CIS_CLK2		84
+#define CLK_DOUT_CIS_CLK3		85
+#define CLK_DOUT_CIS_CLK4		86
+#define CLK_DOUT_CIS_CLK5		87
+#define CLK_DOUT_CIS_CLK6		88
+#define CLK_DOUT_CIS_CLK7		89
+#define CLK_DOUT_CORE_BUS		90
+#define CLK_DOUT_CPUCL0_DBG		91
+#define CLK_DOUT_CPUCL0_SWITCH		92
+#define CLK_DOUT_CPUCL1_SWITCH		93
+#define CLK_DOUT_CPUCL2_SWITCH		94
+#define CLK_DOUT_CSIS_BUS		95
+#define CLK_DOUT_DISP_BUS		96
+#define CLK_DOUT_DNS_BUS		97
+#define CLK_DOUT_DPU_BUS		98
+#define CLK_DOUT_EH_BUS			99
+#define CLK_DOUT_G2D_G2D		100
+#define CLK_DOUT_G2D_MSCL		101
+#define CLK_DOUT_G3AA_G3AA		102
+#define CLK_DOUT_G3D_BUSD		103
+#define CLK_DOUT_G3D_GLB		104
+#define CLK_DOUT_G3D_SWITCH		105
+#define CLK_DOUT_GDC_GDC0		106
+#define CLK_DOUT_GDC_GDC1		107
+#define CLK_DOUT_GDC_SCSC		108
+#define CLK_DOUT_CMU_HPM		109
+#define CLK_DOUT_HSI0_BUS		110
+#define CLK_DOUT_HSI0_DPGTC		111
+#define CLK_DOUT_HSI0_USB31DRD		112
+#define CLK_DOUT_HSI0_USBDPDGB		113
+#define CLK_DOUT_HSI1_BUS		114
+#define CLK_DOUT_HSI1_PCIE		115
+#define CLK_DOUT_HSI2_BUS		116
+#define CLK_DOUT_HSI2_MMC_CARD		117
+#define CLK_DOUT_HSI2_PCIE		118
+#define CLK_DOUT_HSI2_UFS_EMBD		119
+#define CLK_DOUT_IPP_BUS		107
+#define CLK_DOUT_ITP_BUS		108
+#define CLK_DOUT_MCSC_ITSC		109
+#define CLK_DOUT_MCSC_MCSC		110
+#define CLK_DOUT_MFC_MFC		111
+#define CLK_DOUT_MIF_BUSP		112
+#define CLK_DOUT_MISC_BUS		113
+#define CLK_DOUT_MISC_SSS		114
+#define CLK_DOUT_PDP_BUS		115
+#define CLK_DOUT_PDP_VRA		116
+#define CLK_DOUT_PERIC0_BUS		117
+#define CLK_DOUT_PERIC0_IP		118
+#define CLK_DOUT_PERIC1_BUS		119
+#define CLK_DOUT_PERIC1_IP		120
+#define CLK_DOUT_TNR_BUS		121
+#define CLK_DOUT_TPU_BUS		122
+#define CLK_DOUT_TPU_TPU		123
+#define CLK_DOUT_TPU_TPUCTL		124
+#define CLK_DOUT_TPU_UART		125
+#define CLK_DOUT_CMU_BOOST		126
+#define CLK_DOUT_CMU_CMUREF		127
+#define CLK_DOUT_SHARED0_DIV2		128
+#define CLK_DOUT_SHARED0_DIV3		129
+#define CLK_DOUT_SHARED0_DIV4		130
+#define CLK_DOUT_SHARED0_DIV5		131
+#define CLK_DOUT_SHARED1_DIV2		132
+#define CLK_DOUT_SHARED1_DIV3		133
+#define CLK_DOUT_SHARED1_DIV4		134
+#define CLK_DOUT_SHARED2_DIV2		135
+#define CLK_DOUT_SHARED3_DIV2		136
+
+/* CMU_TOP Gates */
+#define CLK_GOUT_BUS0_BOOST		137
+#define CLK_GOUT_BUS1_BOOST		138
+#define CLK_GOUT_BUS2_BOOST		139
+#define CLK_GOUT_CORE_BOOST		140
+#define CLK_GOUT_CPUCL0_BOOST		141
+#define CLK_GOUT_CPUCL1_BOOST		142
+#define CLK_GOUT_CPUCL2_BOOST		143
+#define CLK_GOUT_MIF_BOOST		144
+#define CLK_GOUT_MIF_SWITCH		145
+#define CLK_GOUT_BO_BUS			146
+#define CLK_GOUT_BUS0_BUS		147
+#define CLK_GOUT_BUS1_BUS		148
+#define CLK_GOUT_BUS2_BUS		149
+#define CLK_GOUT_CIS_CLK0		150
+#define CLK_GOUT_CIS_CLK1		151
+#define CLK_GOUT_CIS_CLK2		152
+#define CLK_GOUT_CIS_CLK3		153
+#define CLK_GOUT_CIS_CLK4		154
+#define CLK_GOUT_CIS_CLK5		155
+#define CLK_GOUT_CIS_CLK6		156
+#define CLK_GOUT_CIS_CLK7		157
+#define CLK_GOUT_CMU_BOOST		158
+#define CLK_GOUT_CORE_BUS		159
+#define CLK_GOUT_CPUCL0_DBG		160
+#define CLK_GOUT_CPUCL0_SWITCH		161
+#define CLK_GOUT_CPUCL1_SWITCH		162
+#define CLK_GOUT_CPUCL2_SWITCH		163
+#define CLK_GOUT_CSIS_BUS		164
+#define CLK_GOUT_DISP_BUS		165
+#define CLK_GOUT_DNS_BUS		166
+#define CLK_GOUT_DPU_BUS		167
+#define CLK_GOUT_EH_BUS			168
+#define CLK_GOUT_G2D_G2D		169
+#define CLK_GOUT_G2D_MSCL		170
+#define CLK_GOUT_G3AA_G3AA		171
+#define CLK_GOUT_G3D_BUSD		172
+#define CLK_GOUT_G3D_GLB		173
+#define CLK_GOUT_G3D_SWITCH		174
+#define CLK_GOUT_GDC_GDC0		175
+#define CLK_GOUT_GDC_GDC1		176
+#define CLK_GOUT_GDC_SCSC		177
+#define CLK_GOUT_CMU_HPM		178
+#define CLK_GOUT_HSI0_BUS		179
+#define CLK_GOUT_HSI0_DPGTC		180
+#define CLK_GOUT_HSI0_USB31DRD		181
+#define CLK_GOUT_HSI0_USBDPDGB		182
+#define CLK_GOUT_HSI1_BUS		183
+#define CLK_GOUT_HSI1_PCIE		184
+#define CLK_GOUT_HSI2_BUS		185
+#define CLK_GOUT_HSI2_MMC_CARD		186
+#define CLK_GOUT_HSI2_PCIE		187
+#define CLK_GOUT_HSI2_UFS_EMBD		188
+#define CLK_GOUT_IPP_BUS		189
+#define CLK_GOUT_ITP_BUS		190
+#define CLK_GOUT_MCSC_ITSC		191
+#define CLK_GOUT_MCSC_MCSC		192
+#define CLK_GOUT_MFC_MFC		193
+#define CLK_GOUT_MIF_BUSP		194
+#define CLK_GOUT_MISC_BUS		195
+#define CLK_GOUT_MISC_SSS		196
+#define CLK_GOUT_PDP_BUS		197
+#define CLK_GOUT_PDP_VRA		298
+#define CLK_GOUT_G3AA			299
+#define CLK_GOUT_PERIC0_BUS		200
+#define CLK_GOUT_PERIC0_IP		201
+#define CLK_GOUT_PERIC1_BUS		202
+#define CLK_GOUT_PERIC1_IP		203
+#define CLK_GOUT_TNR_BUS		204
+#define CLK_GOUT_TOP_CMUREF		205
+#define CLK_GOUT_TPU_BUS		206
+#define CLK_GOUT_TPU_TPU		207
+#define CLK_GOUT_TPU_TPUCTL		208
+#define CLK_GOUT_TPU_UART		209
+
+/* CMU_APM */
+#define CLK_MOUT_APM_FUNC						1
+#define CLK_MOUT_APM_FUNCSRC						2
+#define CLK_DOUT_APM_BOOST						3
+#define CLK_DOUT_APM_USI0_UART						4
+#define CLK_DOUT_APM_USI0_USI						5
+#define CLK_DOUT_APM_USI1_UART						6
+#define CLK_GOUT_APM_APM_CMU_APM_IPCLKPORT_PCLK				7
+#define CLK_GOUT_BUS0_BOOST_OPTION1					8
+#define CLK_GOUT_CMU_BOOST_OPTION1					9
+#define CLK_GOUT_CORE_BOOST_OPTION1					10
+#define CLK_GOUT_APM_FUNC						11
+#define CLK_GOUT_APM_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK			12
+#define CLK_GOUT_APM_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK		13
+#define CLK_GOUT_APM_APBIF_PMU_ALIVE_IPCLKPORT_PCLK			14
+#define CLK_GOUT_APM_APBIF_RTC_IPCLKPORT_PCLK				15
+#define CLK_GOUT_APM_APBIF_TRTC_IPCLKPORT_PCLK				16
+#define CLK_GOUT_APM_APM_USI0_UART_IPCLKPORT_IPCLK			17
+#define CLK_GOUT_APM_APM_USI0_UART_IPCLKPORT_PCLK			18
+#define CLK_GOUT_APM_APM_USI0_USI_IPCLKPORT_IPCLK			19
+#define CLK_GOUT_APM_APM_USI0_USI_IPCLKPORT_PCLK			20
+#define CLK_GOUT_APM_APM_USI1_UART_IPCLKPORT_IPCLK			21
+#define CLK_GOUT_APM_APM_USI1_UART_IPCLKPORT_PCLK			22
+#define CLK_GOUT_APM_D_TZPC_APM_IPCLKPORT_PCLK				23
+#define CLK_GOUT_APM_GPC_APM_IPCLKPORT_PCLK				24
+#define CLK_GOUT_APM_GREBEINTEGRATION_IPCLKPORT_HCLK			25
+#define CLK_GOUT_APM_INTMEM_IPCLKPORT_ACLK				26
+#define CLK_GOUT_APM_INTMEM_IPCLKPORT_PCLK				27
+#define CLK_GOUT_APM_LHM_AXI_G_SWD_IPCLKPORT_I_CLK			28
+#define CLK_GOUT_APM_LHM_AXI_P_AOCAPM_IPCLKPORT_I_CLK			29
+#define CLK_GOUT_APM_LHM_AXI_P_APM_IPCLKPORT_I_CLK			30
+#define CLK_GOUT_APM_LHS_AXI_D_APM_IPCLKPORT_I_CLK			31
+#define CLK_GOUT_APM_LHS_AXI_G_DBGCORE_IPCLKPORT_I_CLK			32
+#define CLK_GOUT_APM_LHS_AXI_G_SCAN2DRAM_IPCLKPORT_I_CLK		33
+#define CLK_GOUT_APM_MAILBOX_APM_AOC_IPCLKPORT_PCLK			34
+#define CLK_GOUT_APM_MAILBOX_APM_AP_IPCLKPORT_PCLK			35
+#define CLK_GOUT_APM_MAILBOX_APM_GSA_IPCLKPORT_PCLK			36
+#define CLK_GOUT_APM_MAILBOX_APM_SWD_IPCLKPORT_PCLK			37
+#define CLK_GOUT_APM_MAILBOX_APM_TPU_IPCLKPORT_PCLK			38
+#define CLK_GOUT_APM_MAILBOX_AP_AOC_IPCLKPORT_PCLK			39
+#define CLK_GOUT_APM_MAILBOX_AP_DBGCORE_IPCLKPORT_PCLK		40
+#define CLK_GOUT_APM_PMU_INTR_GEN_IPCLKPORT_PCLK			41
+#define CLK_GOUT_APM_ROM_CRC32_HOST_IPCLKPORT_ACLK			42
+#define CLK_GOUT_APM_ROM_CRC32_HOST_IPCLKPORT_PCLK			43
+#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_BUS_IPCLKPORT_CLK			44
+#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_USI0_UART_IPCLKPORT_CLK		45
+#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_USI0_USI_IPCLKPORT_CLK		46
+#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_USI1_UART_IPCLKPORT_CLK		47
+#define CLK_GOUT_APM_SPEEDY_APM_IPCLKPORT_PCLK				48
+#define CLK_GOUT_APM_SPEEDY_SUB_APM_IPCLKPORT_PCLK			49
+#define CLK_GOUT_APM_SSMT_D_APM_IPCLKPORT_ACLK				50
+#define CLK_GOUT_APM_SSMT_D_APM_IPCLKPORT_PCLK				51
+#define CLK_GOUT_APM_SSMT_G_DBGCORE_IPCLKPORT_ACLK			52
+#define CLK_GOUT_APM_SSMT_G_DBGCORE_IPCLKPORT_PCLK			53
+#define CLK_GOUT_APM_SS_DBGCORE_IPCLKPORT_SS_DBGCORE_IPCLKPORT_HCLK	54
+#define CLK_GOUT_APM_SYSMMU_D_APM_IPCLKPORT_CLK_S2			55
+#define CLK_GOUT_APM_SYSREG_APM_IPCLKPORT_PCLK				56
+#define CLK_GOUT_APM_UASC_APM_IPCLKPORT_ACLK				57
+#define CLK_GOUT_APM_UASC_APM_IPCLKPORT_PCLK				58
+#define CLK_GOUT_APM_UASC_DBGCORE_IPCLKPORT_ACLK			59
+#define CLK_GOUT_APM_UASC_DBGCORE_IPCLKPORT_PCLK			60
+#define CLK_GOUT_APM_UASC_G_SWD_IPCLKPORT_ACLK				61
+#define CLK_GOUT_APM_UASC_G_SWD_IPCLKPORT_PCLK				62
+#define CLK_GOUT_APM_UASC_P_AOCAPM_IPCLKPORT_ACLK			63
+#define CLK_GOUT_APM_UASC_P_AOCAPM_IPCLKPORT_PCLK			64
+#define CLK_GOUT_APM_UASC_P_APM_IPCLKPORT_ACLK				65
+#define CLK_GOUT_APM_UASC_P_APM_IPCLKPORT_PCLK				66
+#define CLK_GOUT_APM_WDT_APM_IPCLKPORT_PCLK				67
+#define CLK_GOUT_APM_XIU_DP_APM_IPCLKPORT_ACLK				68
+#define CLK_APM_PLL_DIV2_APM						69
+#define CLK_APM_PLL_DIV4_APM						70
+#define CLK_APM_PLL_DIV16_APM						71
+
+/* CMU_MISC */
+
+#define CLK_MOUT_MISC_BUS_USER					1
+#define CLK_MOUT_MISC_SSS_USER					2
+#define CLK_MOUT_MISC_GIC					3
+#define CLK_DOUT_MISC_BUSP					4
+#define CLK_DOUT_MISC_GIC					5
+#define CLK_GOUT_MISC_MISC_CMU_MISC_IPCLKPORT_PCLK		6
+#define CLK_GOUT_MISC_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK		7
+#define CLK_GOUT_MISC_OTP_CON_BISR_IPCLKPORT_I_OSCCLK		8
+#define CLK_GOUT_MISC_OTP_CON_TOP_IPCLKPORT_I_OSCCLK		9
+#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_OSCCLK_IPCLKPORT_CLK	10
+#define CLK_GOUT_MISC_ADM_AHB_SSS_IPCLKPORT_HCLKM		11
+#define CLK_GOUT_MISC_AD_APB_DIT_IPCLKPORT_PCLKM		12
+#define CLK_GOUT_MISC_AD_APB_PUF_IPCLKPORT_PCLKM		13
+#define CLK_GOUT_MISC_DIT_IPCLKPORT_ICLKL2A			14
+#define CLK_GOUT_MISC_D_TZPC_MISC_IPCLKPORT_PCLK		15
+#define CLK_GOUT_MISC_GIC_IPCLKPORT_GICCLK			16
+#define CLK_GOUT_MISC_GPC_MISC_IPCLKPORT_PCLK			17
+#define CLK_GOUT_MISC_LHM_AST_ICC_CPUGIC_IPCLKPORT_I_CLK	18
+#define CLK_GOUT_MISC_LHM_AXI_D_SSS_IPCLKPORT_I_CLK		19
+#define CLK_GOUT_MISC_LHM_AXI_P_GIC_IPCLKPORT_I_CLK		20
+#define CLK_GOUT_MISC_LHM_AXI_P_MISC_IPCLKPORT_I_CLK		21
+#define CLK_GOUT_MISC_LHS_ACEL_D_MISC_IPCLKPORT_I_CLK		22
+#define CLK_GOUT_MISC_LHS_AST_IRI_GICCPU_IPCLKPORT_I_CLK	23
+#define CLK_GOUT_MISC_LHS_AXI_D_SSS_IPCLKPORT_I_CLK		24
+#define CLK_GOUT_MISC_MCT_IPCLKPORT_PCLK			25
+#define CLK_GOUT_MISC_OTP_CON_BIRA_IPCLKPORT_PCLK		26
+#define CLK_GOUT_MISC_OTP_CON_BISR_IPCLKPORT_PCLK		27
+#define CLK_GOUT_MISC_OTP_CON_TOP_IPCLKPORT_PCLK		28
+#define CLK_GOUT_MISC_PDMA_IPCLKPORT_ACLK			29
+#define CLK_GOUT_MISC_PPMU_DMA_IPCLKPORT_ACLK			30
+#define CLK_GOUT_MISC_PPMU_MISC_IPCLKPORT_ACLK			31
+#define CLK_GOUT_MISC_PPMU_MISC_IPCLKPORT_PCLK			32
+#define CLK_GOUT_MISC_PUF_IPCLKPORT_I_CLK			33
+#define CLK_GOUT_MISC_QE_DIT_IPCLKPORT_ACLK			34
+#define CLK_GOUT_MISC_QE_DIT_IPCLKPORT_PCLK			35
+#define CLK_GOUT_MISC_QE_PDMA_IPCLKPORT_ACLK			36
+#define CLK_GOUT_MISC_QE_PDMA_IPCLKPORT_PCLK			37
+#define CLK_GOUT_MISC_QE_PPMU_DMA_IPCLKPORT_ACLK		38
+#define CLK_GOUT_MISC_QE_PPMU_DMA_IPCLKPORT_PCLK		39
+#define CLK_GOUT_MISC_QE_RTIC_IPCLKPORT_ACLK			40
+#define CLK_GOUT_MISC_QE_RTIC_IPCLKPORT_PCLK			41
+#define CLK_GOUT_MISC_QE_SPDMA_IPCLKPORT_ACLK			42
+#define CLK_GOUT_MISC_QE_SPDMA_IPCLKPORT_PCLK			43
+#define CLK_GOUT_MISC_QE_SSS_IPCLKPORT_ACLK			44
+#define CLK_GOUT_MISC_QE_SSS_IPCLKPORT_PCLK			45
+#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_BUSD_IPCLKPORT_CLK	46
+#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_BUSP_IPCLKPORT_CLK	47
+#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_GIC_IPCLKPORT_CLK	48
+#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_SSS_IPCLKPORT_CLK	49
+#define CLK_GOUT_MISC_RTIC_IPCLKPORT_I_ACLK			50
+#define CLK_GOUT_MISC_RTIC_IPCLKPORT_I_PCLK			51
+#define CLK_GOUT_MISC_SPDMA_IPCLKPORT_ACLK			52
+#define CLK_GOUT_MISC_SSMT_DIT_IPCLKPORT_ACLK			53
+#define CLK_GOUT_MISC_SSMT_DIT_IPCLKPORT_PCLK			54
+#define CLK_GOUT_MISC_SSMT_PDMA_IPCLKPORT_ACLK			55
+#define CLK_GOUT_MISC_SSMT_PDMA_IPCLKPORT_PCLK			56
+#define CLK_GOUT_MISC_SSMT_PPMU_DMA_IPCLKPORT_ACLK		57
+#define CLK_GOUT_MISC_SSMT_PPMU_DMA_IPCLKPORT_PCLK		58
+#define CLK_GOUT_MISC_SSMT_RTIC_IPCLKPORT_ACLK			59
+#define CLK_GOUT_MISC_SSMT_RTIC_IPCLKPORT_PCLK			60
+#define CLK_GOUT_MISC_SSMT_SPDMA_IPCLKPORT_ACLK			61
+#define CLK_GOUT_MISC_SSMT_SPDMA_IPCLKPORT_PCLK			62
+#define CLK_GOUT_MISC_SSMT_SSS_IPCLKPORT_ACLK			63
+#define CLK_GOUT_MISC_SSMT_SSS_IPCLKPORT_PCLK			64
+#define CLK_GOUT_MISC_SSS_IPCLKPORT_I_ACLK			65
+#define CLK_GOUT_MISC_SSS_IPCLKPORT_I_PCLK			66
+#define CLK_GOUT_MISC_SYSMMU_MISC_IPCLKPORT_CLK_S2		67
+#define CLK_GOUT_MISC_SYSMMU_SSS_IPCLKPORT_CLK_S1		68
+#define CLK_GOUT_MISC_SYSREG_MISC_IPCLKPORT_PCLK		69
+#define CLK_GOUT_MISC_TMU_SUB_IPCLKPORT_PCLK			70
+#define CLK_GOUT_MISC_TMU_TOP_IPCLKPORT_PCLK			71
+#define CLK_GOUT_MISC_WDT_CLUSTER0_IPCLKPORT_PCLK		72
+#define CLK_GOUT_MISC_WDT_CLUSTER1_IPCLKPORT_PCLK		73
+#define CLK_GOUT_MISC_XIU_D_MISC_IPCLKPORT_ACLK			74
+
+#endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:09 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:09 +0000
Subject: [PATCH v5 04/20] dt-bindings: watchdog: Document Google gs101 watchdog bindings
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-5-peter.griffin@linaro.org>

Add the "google,gs101-wdt" compatible to the dt-schema documentation.

gs101 SoC has two CPU clusters and each cluster has its own dedicated
watchdog timer (similar to exynos850 and exynosautov9 SoCs).

These WDT instances are controlled using different bits in PMU
registers.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../devicetree/bindings/watchdog/samsung-wdt.yaml         | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
index 8fb6656ba0c2..57468c2c5ece 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -17,6 +17,7 @@ description: |+
 properties:
   compatible:
     enum:
+      - google,gs101-wdt                      # for Google gs101
       - samsung,s3c2410-wdt                   # for S3C2410
       - samsung,s3c6410-wdt                   # for S3C6410, S5PV210 and Exynos4
       - samsung,exynos5250-wdt                # for Exynos5250
@@ -42,13 +43,14 @@ properties:
   samsung,cluster-index:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
-      Index of CPU cluster on which watchdog is running (in case of Exynos850)
+      Index of CPU cluster on which watchdog is running (in case of Exynos850
+      or Google gs101).
 
   samsung,syscon-phandle:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
       Phandle to the PMU system controller node (in case of Exynos5250,
-      Exynos5420, Exynos7 and Exynos850).
+      Exynos5420, Exynos7, Exynos850 and gs101).
 
 required:
   - compatible
@@ -64,6 +66,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - google,gs101-wdt
               - samsung,exynos5250-wdt
               - samsung,exynos5420-wdt
               - samsung,exynos7-wdt
@@ -77,6 +80,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - google,gs101-wdt
               - samsung,exynos850-wdt
               - samsung,exynosautov9-wdt
     then:
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:10 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:10 +0000
Subject: [PATCH v5 05/20] dt-bindings: arm: google: Add bindings for Google ARM platforms
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-6-peter.griffin@linaro.org>

This introduces bindings and dt-schema for the Google tensor SoCs.
Currently just gs101 and pixel 6 are supported.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/arm/google.yaml       | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml

diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
new file mode 100644
index 000000000000..be191e70192d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/google.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Tensor platforms
+
+maintainers:
+  - Peter Griffin <peter.griffin at linaro.org>
+
+description: |
+  ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
+  devices.
+
+  Currently upstream this is devices using "gs101" SoC which is found in Pixel
+  6, Pixel 6 Pro and Pixel 6a.
+
+  Google have a few different names for the SoC.
+  - Marketing name ("Tensor")
+  - Codename ("Whitechapel")
+  - SoC ID ("gs101")
+  - Die ID ("S5P9845");
+
+  Likewise there are a couple of names for the actual device
+  - Marketing name ("Pixel 6")
+  - Codename ("Oriole")
+
+  Devicetrees should use the lowercased SoC ID and lowercased board codename.
+  e.g. gs101 and gs101-oriole
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Google Pixel 6 / Oriole
+        items:
+          - enum:
+              - google,gs101-oriole
+          - const: google,gs101
+
+  # Bootloader requires empty ect node to be present
+  ect:
+    type: object
+    additionalProperties: false
+
+required:
+  - ect
+
+additionalProperties: true
+
+...
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:11 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:11 +0000
Subject: [PATCH v5 06/20] dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-7-peter.griffin@linaro.org>

Add the "google,gs101-pinctrl" compatible to the dt-schema bindings
documentation.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 9f04a0c76403..118549c25976 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -35,6 +35,7 @@ properties:
 
   compatible:
     enum:
+      - google,gs101-pinctrl
       - samsung,s3c2412-pinctrl
       - samsung,s3c2416-pinctrl
       - samsung,s3c2440-pinctrl
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:13 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:13 +0000
Subject: [PATCH v5 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-9-peter.griffin@linaro.org>

Add dedicated google-gs101-uart compatible to the dt-schema for
representing uart of the Google Tensor gs101 SoC.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/serial/samsung_uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index e32c1b462836..ccc3626779d9 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -21,6 +21,7 @@ properties:
       - enum:
           - apple,s5l-uart
           - axis,artpec8-uart
+          - google,gs101-uart
           - samsung,s3c6400-uart
           - samsung,s5pv210-uart
           - samsung,exynos4210-uart
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:12 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:12 +0000
Subject: [PATCH v5 07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-8-peter.griffin@linaro.org>

gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
where more than one pin controller can do external wake-up interrupt.
So add a dedicated compatible for it.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
index 2bafa867aea2..de2209f8ba00 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
@@ -44,6 +44,7 @@ properties:
           - const: samsung,exynos7-wakeup-eint
       - items:
           - enum:
+              - google,gs101-wakeup-eint
               - samsung,exynosautov9-wakeup-eint
               - samsung,exynosautov920-wakeup-eint
           - const: samsung,exynos850-wakeup-eint
@@ -111,6 +112,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - google,gs101-wakeup-eint
               - samsung,exynos850-wakeup-eint
     then:
       properties:
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:14 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:14 +0000
Subject: [PATCH v5 09/20] dt-bindings: serial: samsung: Make samsung,uart-fifosize required property
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-10-peter.griffin@linaro.org>

Specifying samsung,uart-fifosize in both DT and driver static data is error
prone and relies on driver probe order and dt aliases to be correct.

Additionally on many Exynos platforms these are (USI) universal serial
interfaces which can be uart, spi or i2c, so it can change per board.

For google,gs101-uart and exynosautov9-uart make samsung,uart-fifosize a
required property. For these platforms fifosize now *only* comes from DT.

It is hoped other Exynos platforms will also switch over time.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../devicetree/bindings/serial/samsung_uart.yaml       | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index ccc3626779d9..65d5d361e8f4 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -133,6 +133,16 @@ allOf:
             - const: uart
             - const: clk_uart_baud0
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - google,gs101-uart
+    then:
+      required:
+        - samsung,uart-fifosize
+
 unevaluatedProperties: false
 
 examples:
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:15 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:15 +0000
Subject: [PATCH v5 10/20] dt-bindings: soc: samsung: usi: add google,gs101-usi compatible
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-11-peter.griffin@linaro.org>

From: Tudor Ambarus <tudor.ambarus at linaro.org>

Add google,gs101-usi dedicated compatible for representing USI of Google
GS101 SoC.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
index 61be1f2ddbe7..a10a438d89f0 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
@@ -28,6 +28,9 @@ properties:
               - samsung,exynosautov9-usi
               - samsung,exynosautov920-usi
           - const: samsung,exynos850-usi
+      - items:
+          - const: google,gs101-usi
+          - const: samsung,exynos850-usi
       - enum:
           - samsung,exynos850-usi
 
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:16 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:16 +0000
Subject: [PATCH v5 11/20] clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-12-peter.griffin@linaro.org>

These plls are found in the Tensor gs101 SoC found in the Pixel 6.

pll0516x: Integer PLL with high frequency
pll0517x: Integer PLL with middle frequency
pll0518x: Integer PLL with low frequency

PLL0516x
FOUT = (MDIV * 2 * FIN)/PDIV * 2^SDIV)

PLL0517x and PLL0518x
FOUT = (MDIV * FIN)/PDIV*2^SDIV)

The PLLs are similar enough to pll_0822x that the same code can handle
both. The main difference is the change in the fout formula for the
high frequency 0516 pll.

Locktime for 516,517 & 518 is 150 the same as the pll_0822x lock factor.
MDIV, SDIV PDIV masks and bit shifts are also the same as 0822x.

When defining the PLL the "con" parameter should be set to CON3
register, like this

PLL(pll_0517x, CLK_FOUT_SHARED0_PLL, "fout_shared0_pll", "oscclk",
    PLL_LOCKTIME_PLL_SHARED0, PLL_CON3_PLL_SHARED0,
    NULL),

Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
Tested-by: Will McVicker <willmcvicker at google.com>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/clk/samsung/clk-pll.c | 6 ++++++
 drivers/clk/samsung/clk-pll.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 74934c6182ce..4bbdf5e91650 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -443,6 +443,9 @@ static unsigned long samsung_pll0822x_recalc_rate(struct clk_hw *hw,
 	sdiv = (pll_con3 >> PLL0822X_SDIV_SHIFT) & PLL0822X_SDIV_MASK;
 
 	fvco *= mdiv;
+	if (pll->type == pll_0516x)
+		fvco *= 2;
+
 	do_div(fvco, (pdiv << sdiv));
 
 	return (unsigned long)fvco;
@@ -1316,6 +1319,9 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 	case pll_1417x:
 	case pll_0818x:
 	case pll_0822x:
+	case pll_0516x:
+	case pll_0517x:
+	case pll_0518x:
 		pll->enable_offs = PLL0822X_ENABLE_SHIFT;
 		pll->lock_offs = PLL0822X_LOCK_STAT_SHIFT;
 		if (!pll->rate_table)
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index 0725d485c6ee..ffd3d52c0dec 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -38,6 +38,9 @@ enum samsung_pll_type {
 	pll_0822x,
 	pll_0831x,
 	pll_142xx,
+	pll_0516x,
+	pll_0517x,
+	pll_0518x,
 };
 
 #define PLL_RATE(_fin, _m, _p, _s, _k, _ks) \
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:18 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:18 +0000
Subject: [PATCH v5 13/20] pinctrl: samsung: Add filter selection support for alive banks
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-14-peter.griffin@linaro.org>

Newer Exynos SoCs have a filter selection register on alive bank pins.
This allows the selection of a digital or delay filter for each pin. If
the filter selection register is not available then the default filter
(digital) is applied.

On suspend we apply the analog filter to all pins in the bank (as the
digital filter relies on a clock). On resume the digital filter is
reapplied to all pins in the bank. The digital filter is working via
clock and has an adjustable filter delay register bitfield, whereas
the analog filter uses a fixed delay.

The filter determines to what extent signal fluctuations received through
the pad are considered glitches.

The code path can be exercised using
echo mem > /sys/power/state
And then wake the device using a eint gpio

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 89 ++++++++++++++++++++++-
 drivers/pinctrl/samsung/pinctrl-exynos.h  |  7 ++
 drivers/pinctrl/samsung/pinctrl-samsung.c |  2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h | 22 ++++++
 4 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 6b58ec84e34b..56fc11a1fe2f 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -269,6 +269,71 @@ struct exynos_eint_gpio_save {
 	u32 eint_mask;
 };
 
+/*
+ * Set the desired filter (digital or analog delay) to every pin in
+ * the bank. Note the filter selection bitfield is only found on alive
+ * banks. The filter determines to what extent signal fluctuations
+ * received through the pad are considered glitches.
+ */
+static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
+				   struct samsung_pin_bank *bank, int filter)
+{
+	unsigned int flt_reg, flt_con = 0;
+	unsigned int val, shift;
+	int i;
+	int loop_cnt;
+
+	/*
+	 * The FLTCON register has the following layout
+	 *
+	 * BitfieldName[PinNum][Bit:Bit]
+	 * FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
+	 * FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
+	 * FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
+	 * FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
+	 *
+	 * FLT_EN	0x0 = Disable, 0x1=Enable
+	 * FLT_SEL	0x0 = Delay filter, 0x1 Digital filter
+	 * FLT_WIDTH	Filtering width. Valid when FLT_SEL is 0x1
+	 */
+
+	flt_con |= EXYNOS9_FLTCON_EN;
+
+	if (filter)
+		flt_con |= EXYNOS9_FLTCON_DIGITAL;
+
+	flt_reg = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
+
+	/*
+	 * If nr_pins > 4, we should set FLTCON0 register fully.
+	 * (pin0 ~ 3). So loop 4 times in case of FLTCON0.
+	 */
+	if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN)
+		loop_cnt = EXYNOS9_FLTCON_NR_PIN;
+	else
+		loop_cnt = bank->nr_pins;
+
+	val = readl(d->virt_base + flt_reg);
+	for (i = 0; i < loop_cnt; i++) {
+		shift = i * EXYNOS9_FLTCON_LEN;
+		val &= ~(EXYNOS9_FLTCON_MASK << shift);
+		val |= (flt_con << shift);
+	}
+	writel(val, d->virt_base + flt_reg);
+
+	/* Loop for FLTCON1 pin 4 ~ 7 */
+	if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN) {
+		loop_cnt = (bank->nr_pins - EXYNOS9_FLTCON_NR_PIN);
+		val = readl(d->virt_base + flt_reg + 0x4);
+		for (i = 0; i < loop_cnt; i++) {
+			shift = i * EXYNOS9_FLTCON_LEN;
+			val &= ~(EXYNOS9_FLTCON_MASK << shift);
+			val |= (flt_con << shift);
+		}
+		writel(val, d->virt_base + flt_reg + 0x4);
+	}
+}
+
 /*
  * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
  * @d: driver data of samsung pinctrl driver.
@@ -321,6 +386,10 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
 			goto err_domains;
 		}
 
+		/* Set Delay Analog Filter */
+		if (bank->fltcon_type != FLT_DEFAULT)
+			exynos_eint_flt_config(d, bank,
+					       EXYNOS9_FLTCON_DELAY);
 	}
 
 	return 0;
@@ -555,6 +624,11 @@ __init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
 		if (bank->eint_type != EINT_TYPE_WKUP)
 			continue;
 
+		/* Set Digital Filter */
+		if (bank->fltcon_type != FLT_DEFAULT)
+			exynos_eint_flt_config(d, bank,
+					       EXYNOS9_FLTCON_DIGITAL);
+
 		bank->irq_chip = devm_kmemdup(dev, irq_chip, sizeof(*irq_chip),
 					      GFP_KERNEL);
 		if (!bank->irq_chip) {
@@ -658,6 +732,7 @@ static void exynos_pinctrl_suspend_bank(
 void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
 	struct exynos_irq_chip *irq_chip = NULL;
 	int i;
 
@@ -665,6 +740,10 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 		if (bank->eint_type == EINT_TYPE_GPIO)
 			exynos_pinctrl_suspend_bank(drvdata, bank);
 		else if (bank->eint_type == EINT_TYPE_WKUP) {
+			/* Setting Delay (Analog) Filter */
+			if (bank->fltcon_type != FLT_DEFAULT)
+				exynos_eint_flt_config(d, bank,
+						       EXYNOS9_FLTCON_DELAY);
 			if (!irq_chip) {
 				irq_chip = bank->irq_chip;
 				irq_chip->set_eint_wakeup_mask(drvdata,
@@ -707,11 +786,19 @@ static void exynos_pinctrl_resume_bank(
 void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
 	int i;
 
 	for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
-		if (bank->eint_type == EINT_TYPE_GPIO)
+		if (bank->eint_type == EINT_TYPE_GPIO) {
 			exynos_pinctrl_resume_bank(drvdata, bank);
+		} else if (bank->eint_type == EINT_TYPE_WKUP ||
+			   bank->eint_type == EINT_TYPE_WKUP_MUX) {
+			/* Set Digital Filter */
+			if (bank->fltcon_type != FLT_DEFAULT)
+				exynos_eint_flt_config(d, bank,
+						       EXYNOS9_FLTCON_DIGITAL);
+		}
 }
 
 static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index 3ac52c2cf998..e2799ff1b5e9 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -50,6 +50,13 @@
 
 #define EXYNOS_EINT_MAX_PER_BANK	8
 #define EXYNOS_EINT_NR_WKUP_EINT
+/* EINT filter configuration */
+#define EXYNOS9_FLTCON_EN		BIT(7)
+#define EXYNOS9_FLTCON_DIGITAL		BIT(6)
+#define EXYNOS9_FLTCON_DELAY		(0 << 6)
+#define EXYNOS9_FLTCON_MASK		0xff
+#define EXYNOS9_FLTCON_LEN		8
+#define EXYNOS9_FLTCON_NR_PIN		4
 
 #define EXYNOS_PIN_BANK_EINTN(pins, reg, id)		\
 	{						\
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 79babbb39ced..50c360b4753a 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1105,6 +1105,8 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
 		bank->eint_func = bdata->eint_func;
 		bank->eint_type = bdata->eint_type;
 		bank->eint_mask = bdata->eint_mask;
+		bank->fltcon_type = bdata->fltcon_type;
+		bank->fltcon_offset = bdata->fltcon_offset;
 		bank->eint_offset = bdata->eint_offset;
 		bank->name = bdata->name;
 
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 9b3db50adef3..5fab3885a7d7 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -82,6 +82,20 @@ enum eint_type {
 	EINT_TYPE_WKUP_MUX,
 };
 
+/**
+ * enum fltcon_type - filter selection
+ * @FLT_DEFAULT: filter not selectable, default digital filter
+ * @FLT_SELECT: filter selectable (digital or delay)
+ *
+ * Some banks on newer Exynos based SoCs have a selectable filter on alive
+ * banks of 'analog/delay' or 'digital'. If the filter selection register is
+ * not available then the default filter is used (digital).
+ */
+enum fltcon_type {
+	FLT_DEFAULT,
+	FLT_SELECTABLE,
+};
+
 /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
 #define PIN_NAME_LENGTH	10
 
@@ -122,6 +136,8 @@ struct samsung_pin_bank_type {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @fltcon_type: whether the filter (delay/digital) is selectable
+ * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  */
 struct samsung_pin_bank_data {
@@ -133,6 +149,8 @@ struct samsung_pin_bank_data {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	enum fltcon_type fltcon_type;
+	u32		fltcon_offset;
 	const char	*name;
 };
 
@@ -147,6 +165,8 @@ struct samsung_pin_bank_data {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @fltcon_type: whether the filter (delay/digital) is selectable
+ * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  * @id: id of the bank, propagated to the pin range.
  * @pin_base: starting pin number of the bank.
@@ -170,6 +190,8 @@ struct samsung_pin_bank {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	enum fltcon_type fltcon_type;
+	u32		fltcon_offset;
 	const char	*name;
 	u32		id;
 
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:20 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:20 +0000
Subject: [PATCH v5 15/20] watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bit
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-16-peter.griffin@linaro.org>

The WDT uses the CPU core signal DBGACK to determine whether the SoC
is running in debug mode or not. If the DBGACK signal is asserted and
DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
(disabled).

Presence of the DBGACK_MASK bit is determined by adding a new
QUIRK_HAS_DBGACK_BIT quirk.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 0b4bd883ff28..39f3489e41d6 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -34,9 +34,10 @@
 
 #define S3C2410_WTCNT_MAXCNT	0xffff
 
-#define S3C2410_WTCON_RSTEN	(1 << 0)
-#define S3C2410_WTCON_INTEN	(1 << 2)
-#define S3C2410_WTCON_ENABLE	(1 << 5)
+#define S3C2410_WTCON_RSTEN		(1 << 0)
+#define S3C2410_WTCON_INTEN		(1 << 2)
+#define S3C2410_WTCON_ENABLE		(1 << 5)
+#define S3C2410_WTCON_DBGACK_MASK	(1 << 16)
 
 #define S3C2410_WTCON_DIV16	(0 << 3)
 #define S3C2410_WTCON_DIV32	(1 << 3)
@@ -100,12 +101,17 @@
  * %QUIRK_HAS_PMU_CNT_EN: PMU block has some register (e.g. CLUSTERx_NONCPU_OUT)
  * with "watchdog counter enable" bit. That bit should be set to make watchdog
  * counter running.
+ *
+ * %QUIRK_HAS_DBGACK_BIT: WTCON register has DBGACK_MASK bit. Setting the
+ * DBGACK_MASK bit disables the watchdog outputs when the SoC is in debug mode.
+ * Debug mode is determined by the DBGACK CPU signal.
  */
 #define QUIRK_HAS_WTCLRINT_REG			(1 << 0)
 #define QUIRK_HAS_PMU_MASK_RESET		(1 << 1)
 #define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
 #define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
 #define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
+#define QUIRK_HAS_DBGACK_BIT			(1 << 5)
 
 /* These quirks require that we have a PMU register map */
 #define QUIRKS_HAVE_PMUREG \
@@ -375,6 +381,19 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
 	return 0;
 }
 
+static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt)
+{
+	unsigned long wtcon;
+
+	if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
+		return;
+
+	/*  disable watchdog outputs if CPU is in debug mode */
+	wtcon = readl(wdt->reg_base + S3C2410_WTCON);
+	wtcon |= S3C2410_WTCON_DBGACK_MASK;
+	writel(wtcon, wdt->reg_base + S3C2410_WTCON);
+}
+
 static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
 {
 	struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
@@ -700,6 +719,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
 	wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
 	wdt->wdt_device.parent = dev;
 
+	s3c2410wdt_mask_dbgack(wdt);
+
 	/*
 	 * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
 	 * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:19 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:19 +0000
Subject: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-15-peter.griffin@linaro.org>

Add support for the pin-controller found on the gs101 SoC used in
Pixel 6 phones.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 159 ++++++++++++++++++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
 drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
 drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
 5 files changed, 198 insertions(+)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index cb965cf93705..e1a0668ecb16 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -796,3 +796,162 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
 	.ctrl		= fsd_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
 };
+
+/*
+ * bank type for non-alive type
+ * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
+ * (CONPDN bit field: 2, PUDPDN bit field: 4)
+ */
+static struct samsung_pin_bank_type gs101_bank_type_off  = {
+	.fld_width = { 4, 1, 4, 4, 2, 4, },
+	.reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
+};
+
+/*
+ * bank type for alive type
+ * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
+ */
+static const struct samsung_pin_bank_type gs101_bank_type_alive = {
+	.fld_width = { 4, 1, 4, 4, },
+	.reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
+};
+
+/* pin banks of gs101 pin-controller (ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_alive[] = {
+	EXYNOS9_PIN_BANK_EINTW(8, 0x0, "gpa0", 0x00, 0x00),
+	EXYNOS9_PIN_BANK_EINTW(7, 0x20, "gpa1", 0x04, 0x08),
+	EXYNOS9_PIN_BANK_EINTW(5, 0x40, "gpa2", 0x08, 0x10),
+	EXYNOS9_PIN_BANK_EINTW(4, 0x60, "gpa3", 0x0c, 0x18),
+	EXYNOS9_PIN_BANK_EINTW(4, 0x80, "gpa4", 0x10, 0x1c),
+	EXYNOS9_PIN_BANK_EINTW(7, 0xa0, "gpa5", 0x14, 0x20),
+	EXYNOS9_PIN_BANK_EINTW(8, 0xc0, "gpa9", 0x18, 0x28),
+	EXYNOS9_PIN_BANK_EINTW(2, 0xe0, "gpa10", 0x1c, 0x30),
+};
+
+/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_far_alive[] = {
+	EXYNOS9_PIN_BANK_EINTW(8, 0x0, "gpa6", 0x00, 0x00),
+	EXYNOS9_PIN_BANK_EINTW(4, 0x20, "gpa7", 0x04, 0x08),
+	EXYNOS9_PIN_BANK_EINTW(8, 0x40, "gpa8", 0x08, 0x0c),
+	EXYNOS9_PIN_BANK_EINTW(2, 0x60, "gpa11", 0x0c, 0x14),
+};
+
+/* pin banks of gs101 pin-controller (GSACORE) */
+static const struct samsung_pin_bank_data gs101_pin_gsacore[] = {
+	EXYNOS9_PIN_BANK_EINTG(2, 0x0, "gps0", 0x00, 0x00),
+	EXYNOS9_PIN_BANK_EINTG(8, 0x20, "gps1", 0x04, 0x04),
+	EXYNOS9_PIN_BANK_EINTG(3, 0x40, "gps2", 0x08, 0x0c),
+};
+
+/* pin banks of gs101 pin-controller (GSACTRL) */
+static const struct samsung_pin_bank_data gs101_pin_gsactrl[] = {
+	EXYNOS9_PIN_BANK_EINTW(6, 0x0, "gps3", 0x00, 0x00),
+};
+
+/* pin banks of gs101 pin-controller (PERIC0) */
+static const struct samsung_pin_bank_data gs101_pin_peric0[] = {
+	EXYNOS9_PIN_BANK_EINTG(5, 0x0, "gpp0", 0x00, 0x00),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x20, "gpp1", 0x04, 0x08),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x40, "gpp2", 0x08, 0x0c),
+	EXYNOS9_PIN_BANK_EINTG(2, 0x60, "gpp3", 0x0c, 0x10),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x80, "gpp4", 0x10, 0x14),
+	EXYNOS9_PIN_BANK_EINTG(2, 0xa0, "gpp5", 0x14, 0x18),
+	EXYNOS9_PIN_BANK_EINTG(4, 0xc0, "gpp6", 0x18, 0x1c),
+	EXYNOS9_PIN_BANK_EINTG(2, 0xe0, "gpp7", 0x1c, 0x20),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x100, "gpp8", 0x20, 0x24),
+	EXYNOS9_PIN_BANK_EINTG(2, 0x120, "gpp9", 0x24, 0x28),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x140, "gpp10", 0x28, 0x2c),
+	EXYNOS9_PIN_BANK_EINTG(2, 0x160, "gpp11", 0x2c, 0x30),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x180, "gpp12", 0x30, 0x34),
+	EXYNOS9_PIN_BANK_EINTG(2, 0x1a0, "gpp13", 0x34, 0x38),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x1c0, "gpp14", 0x38, 0x3c),
+	EXYNOS9_PIN_BANK_EINTG(2, 0x1e0, "gpp15", 0x3c, 0x40),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x200, "gpp16", 0x40, 0x44),
+	EXYNOS9_PIN_BANK_EINTG(2, 0x220, "gpp17", 0x44, 0x48),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x240, "gpp18", 0x48, 0x4c),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x260, "gpp19", 0x4c, 0x50),
+};
+
+/* pin banks of gs101 pin-controller (PERIC1) */
+static const struct samsung_pin_bank_data gs101_pin_peric1[] = {
+	EXYNOS9_PIN_BANK_EINTG(8, 0x0, "gpp20", 0x00, 0x00),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x20, "gpp21", 0x04, 0x08),
+	EXYNOS9_PIN_BANK_EINTG(2, 0x40, "gpp22", 0x08, 0x0c),
+	EXYNOS9_PIN_BANK_EINTG(8, 0x60, "gpp23", 0x0c, 0x10),
+	EXYNOS9_PIN_BANK_EINTG(4, 0x80, "gpp24", 0x10, 0x18),
+	EXYNOS9_PIN_BANK_EINTG(4, 0xa0, "gpp25", 0x14, 0x1c),
+	EXYNOS9_PIN_BANK_EINTG(5, 0xc0, "gpp26", 0x18, 0x20),
+	EXYNOS9_PIN_BANK_EINTG(4, 0xe0, "gpp27", 0x1c, 0x28),
+};
+
+/* pin banks of gs101 pin-controller (HSI1) */
+static const struct samsung_pin_bank_data gs101_pin_hsi1[] = {
+	EXYNOS9_PIN_BANK_EINTG(6, 0x0, "gph0", 0x00, 0x00),
+	EXYNOS9_PIN_BANK_EINTG(7, 0x20, "gph1", 0x04, 0x08),
+};
+
+/* pin banks of gs101 pin-controller (HSI2) */
+static const struct samsung_pin_bank_data gs101_pin_hsi2[] = {
+	EXYNOS9_PIN_BANK_EINTG(6, 0x0, "gph2", 0x00, 0x00),
+	EXYNOS9_PIN_BANK_EINTG(2, 0x20, "gph3", 0x04, 0x08),
+	EXYNOS9_PIN_BANK_EINTG(6, 0x40, "gph4", 0x08, 0x0c),
+};
+
+static const struct samsung_pin_ctrl gs101_pin_ctrl[] __initconst = {
+	{
+		/* pin banks of gs101 pin-controller (ALIVE) */
+		.pin_banks	= gs101_pin_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_alive),
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+		.pin_banks	= gs101_pin_far_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_far_alive),
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (GSACORE) */
+		.pin_banks	= gs101_pin_gsacore,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsacore),
+	}, {
+		/* pin banks of gs101 pin-controller (GSACTRL) */
+		.pin_banks	= gs101_pin_gsactrl,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsactrl),
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC0) */
+		.pin_banks	= gs101_pin_peric0,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric0),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC1) */
+		.pin_banks	= gs101_pin_peric1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume	= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI1) */
+		.pin_banks	= gs101_pin_hsi1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI2) */
+		.pin_banks	= gs101_pin_hsi2,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi2),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	},
+};
+
+const struct samsung_pinctrl_of_match_data gs101_of_data __initconst = {
+	.ctrl		= gs101_pin_ctrl,
+	.num_ctrl	= ARRAY_SIZE(gs101_pin_ctrl),
+};
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 56fc11a1fe2f..75b9cf72ce73 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -537,6 +537,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
 			.data = &exynos7_wkup_irq_chip },
 	{ .compatible = "samsung,exynosautov9-wakeup-eint",
 			.data = &exynos7_wkup_irq_chip },
+	{ .compatible = "google,gs101-wakeup-eint",
+			.data = &exynos7_wkup_irq_chip },
 	{ }
 };
 
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index e2799ff1b5e9..1ffc90db079d 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -147,6 +147,40 @@
 		.name		= id				\
 	}
 
+#define EXYNOS9_PIN_BANK_EINTN(types, pins, reg, id)	\
+	{						\
+		.type		= &types,		\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.fltcon_type	= FLT_DEFAULT		\
+		.name		= id			\
+	}
+
+#define EXYNOS9_PIN_BANK_EINTG(pins, reg, id, offs, fltcon_offs) \
+	{						\
+		.type		= &gs101_bank_type_off,	\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_GPIO,	\
+		.eint_offset	= offs,			\
+		.fltcon_type    = FLT_DEFAULT,		\
+		.fltcon_offset	= fltcon_offs,		\
+		.name		= id			\
+	}
+
+#define EXYNOS9_PIN_BANK_EINTW(pins, reg, id, offs, fltcon_offs) \
+	{							\
+		.type		= &gs101_bank_type_alive,	\
+		.pctl_offset	= reg,				\
+		.nr_pins	= pins,				\
+		.eint_type	= EINT_TYPE_WKUP,		\
+		.eint_offset	= offs,				\
+		.fltcon_type    = FLT_SELECTABLE,		\
+		.fltcon_offset	= fltcon_offs,			\
+		.name		= id				\
+	}
+
 /**
  * struct exynos_weint_data: irq specific data for all the wakeup interrupts
  * generated by the external wakeup interrupt controller.
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 50c360b4753a..982a5702714c 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1323,6 +1323,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 		.data = &exynosautov9_of_data },
 	{ .compatible = "tesla,fsd-pinctrl",
 		.data = &fsd_of_data },
+	{ .compatible = "google,gs101-pinctrl",
+		.data = &gs101_of_data },
 #endif
 #ifdef CONFIG_PINCTRL_S3C64XX
 	{ .compatible = "samsung,s3c64xx-pinctrl",
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 5fab3885a7d7..f6856290608c 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -373,6 +373,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
 extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
 extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
 extern const struct samsung_pinctrl_of_match_data fsd_of_data;
+extern const struct samsung_pinctrl_of_match_data gs101_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2416_of_data;
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:21 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:21 +0000
Subject: [PATCH v5 16/20] watchdog: s3c2410_wdt: Add support for Google gs101 SoC
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-17-peter.griffin@linaro.org>

This patch adds the compatibles and drvdata for the Google
gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.

Similar to Exynos850 it has two watchdog instances, one for
each cluster and has some control bits in PMU registers.

gs101 also has the dbgack_mask bit in wtcon register, so
we also enable QUIRK_HAS_DBGACK_BIT.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 47 ++++++++++++++++++++++++++++++----
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 39f3489e41d6..c1ae71574457 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -68,6 +68,13 @@
 #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
 #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
 
+#define GS_CLUSTER0_NONCPU_OUT			0x1220
+#define GS_CLUSTER1_NONCPU_OUT			0x1420
+#define GS_CLUSTER0_NONCPU_INT_EN		0x1244
+#define GS_CLUSTER1_NONCPU_INT_EN		0x1444
+#define GS_CLUSTER2_NONCPU_INT_EN		0x1644
+#define GS_RST_STAT_REG_OFFSET			0x3B44
+
 /**
  * DOC: Quirk flags for different Samsung watchdog IP-cores
  *
@@ -269,6 +276,30 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
 		  QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
 };
 
+static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
+	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 0,
+	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
+	.cnt_en_bit = 8,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT,
+};
+
+static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
+	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 1,
+	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
+	.cnt_en_bit = 7,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT,
+};
+
 static const struct of_device_id s3c2410_wdt_match[] = {
 	{ .compatible = "samsung,s3c2410-wdt",
 	  .data = &drv_data_s3c2410 },
@@ -284,6 +315,8 @@ static const struct of_device_id s3c2410_wdt_match[] = {
 	  .data = &drv_data_exynos850_cl0 },
 	{ .compatible = "samsung,exynosautov9-wdt",
 	  .data = &drv_data_exynosautov9_cl0 },
+	{ .compatible = "google,gs101-wdt",
+	  .data = &drv_data_gs101_cl0 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
@@ -604,9 +637,10 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 	}
 
 #ifdef CONFIG_OF
-	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
+	/* Choose Exynos850/ExynosAutov9/gs101 driver data w.r.t. cluster index */
 	if (variant == &drv_data_exynos850_cl0 ||
-	    variant == &drv_data_exynosautov9_cl0) {
+	    variant == &drv_data_exynosautov9_cl0 ||
+	    variant == &drv_data_gs101_cl0) {
 		u32 index;
 		int err;
 
@@ -619,9 +653,12 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 		case 0:
 			break;
 		case 1:
-			variant = (variant == &drv_data_exynos850_cl0) ?
-				&drv_data_exynos850_cl1 :
-				&drv_data_exynosautov9_cl1;
+			if (variant == &drv_data_exynos850_cl0)
+				variant = &drv_data_exynos850_cl1;
+			else if (variant == &drv_data_exynosautov9_cl0)
+				variant = &drv_data_exynosautov9_cl1;
+			else if (variant == &drv_data_gs101_cl0)
+				variant = &drv_data_gs101_cl1;
 			break;
 		default:
 			return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:22 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:22 +0000
Subject: [PATCH v5 17/20] tty: serial: samsung: Add gs101 compatible and common fifoszdt_serial_drv_data
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-18-peter.griffin@linaro.org>

Add serial driver data for Google Tensor gs101 SoC and a common
fifoszdt_serial_drv_data that can be used by platforms that specify the
samsung,uart-fifosize DT property.

A corresponding dt-bindings patch updates the yaml to ensure
samsung,uart-fifosize is a required property.

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Reviewed-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/tty/serial/samsung_tty.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 1b0c2b467a30..f8d98f1006de 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2490,14 +2490,25 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
 	.fifosize = { 256, 64, 64, 64 },
 };
 
+/*
+ * Common drv_data struct for platforms that specify uart,fifosize in
+ * device tree.
+ */
+static const struct s3c24xx_serial_drv_data exynos_fifoszdt_serial_drv_data = {
+	EXYNOS_COMMON_SERIAL_DRV_DATA(),
+	.fifosize = { 0 },
+};
+
 #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
 #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
 #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
+#define EXYNOS_FIFOSZDT_DRV_DATA (&exynos_fifoszdt_serial_drv_data)
 
 #else
 #define EXYNOS4210_SERIAL_DRV_DATA NULL
 #define EXYNOS5433_SERIAL_DRV_DATA NULL
 #define EXYNOS850_SERIAL_DRV_DATA NULL
+#define EXYNOS_FIFOSZDT_DRV_DATA NULL
 #endif
 
 #ifdef CONFIG_ARCH_APPLE
@@ -2581,6 +2592,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
 	}, {
 		.name		= "artpec8-uart",
 		.driver_data	= (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
+	}, {
+		.name		= "gs101-uart",
+		.driver_data	= (kernel_ulong_t)EXYNOS_FIFOSZDT_DRV_DATA,
 	},
 	{ },
 };
@@ -2602,6 +2616,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
 		.data = EXYNOS850_SERIAL_DRV_DATA },
 	{ .compatible = "axis,artpec8-uart",
 		.data = ARTPEC8_SERIAL_DRV_DATA },
+	{ .compatible = "google,gs101-uart",
+		.data = EXYNOS_FIFOSZDT_DRV_DATA },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:24 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:24 +0000
Subject: [PATCH v5 19/20] arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-20-peter.griffin@linaro.org>

Add initial board support for the Pixel 6 phone code named Oriole. This
has been tested with a minimal busybox initramfs and boots to a shell.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 arch/arm64/boot/dts/exynos/Makefile           |   2 +
 arch/arm64/boot/dts/exynos/google/Makefile    |   4 +
 .../boot/dts/exynos/google/gs101-oriole.dts   | 105 ++++++++++++++++++
 3 files changed, 111 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts

diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
index 6e4ba69268e5..44c24a8ad9e1 100644
--- a/arch/arm64/boot/dts/exynos/Makefile
+++ b/arch/arm64/boot/dts/exynos/Makefile
@@ -1,4 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
+subdir-y += google
+
 dtb-$(CONFIG_ARCH_EXYNOS) += \
 	exynos5433-tm2.dtb		\
 	exynos5433-tm2e.dtb		\
diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
new file mode 100644
index 000000000000..0a6d5e1fe4ee
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+dtb-$(CONFIG_ARCH_EXYNOS) += \
+	gs101-oriole.dtb \
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
new file mode 100644
index 000000000000..6abd00fa337e
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Oriole Device Tree
+ *
+ * Copyright 2021-2023 Google,LLC
+ * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "gs101-pinctrl.h"
+#include "gs101.dtsi"
+
+/ {
+	model = "Oriole";
+	compatible = "google,gs101-oriole", "google,gs101";
+
+	aliases {
+		serial0 = &serial_0;
+	};
+
+	chosen {
+		/* Bootloader expects bootargs specified otherwise it crashes */
+		bootargs = "";
+		stdout-path = &serial_0;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&key_voldown>, <&key_volup>, <&key_power>;
+
+		button-vol-down {
+			label = "KEY_VOLUMEDOWN";
+			linux,code = <KEY_VOLUMEDOWN>;
+			gpios = <&gpa7 3 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-vol-up {
+			label = "KEY_VOLUMEUP";
+			linux,code = <KEY_VOLUMEUP>;
+			gpios = <&gpa8 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-power {
+			label = "KEY_POWER";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpa10 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+	};
+};
+
+&ext_24_5m {
+	clock-frequency = <24576000>;
+};
+
+&ext_200m {
+	clock-frequency = <200000000>;
+};
+
+&pinctrl_far_alive {
+	key_voldown: key-voldown-pins {
+		samsung,pins = "gpa7-3";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	key_volup: key-volup-pins {
+		samsung,pins = "gpa8-1";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_gpio_alive {
+	key_power: key-power-pins {
+		samsung,pins = "gpa10-1";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&serial_0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_bus>;
+};
+
+&usi_uart {
+	status = "okay";
+	samsung,clkreq-on; /* needed for UART mode */
+};
+
+&watchdog_cl0 {
+	timeout-sec = <30>;
+	status = "okay";
+};
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:25 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:25 +0000
Subject: [PATCH v5 20/20] MAINTAINERS: add entry for Google Tensor SoC
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-21-peter.griffin@linaro.org>

Add maintainers entry for the Google tensor SoC based
platforms.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36f6e76170e6..a3bd682c9e32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9032,6 +9032,16 @@ S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
 F:	drivers/firmware/google/
 
+GOOGLE TENSOR SoC SUPPORT
+M:	Peter Griffin <peter.griffin at linaro.org>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L:	linux-samsung-soc at vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+F:	arch/arm64/boot/dts/exynos/google/
+F:	drivers/clk/samsung/clk-gs101.c
+F:	include/dt-bindings/clock/google,clk-gs101.h
+
 GPD POCKET FAN DRIVER
 M:	Hans de Goede <hdegoede at redhat.com>
 L:	platform-driver-x86 at vger.kernel.org
-- 
2.43.0.rc2.451.g8631bc7472-goog



From peter.griffin at linaro.org  Fri Dec  1 08:09:23 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri,  1 Dec 2023 16:09:23 +0000
Subject: [PATCH v5 18/20] arm64: dts: exynos: google: Add initial Google gs101 SoC support
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <20231201160925.3136868-19-peter.griffin@linaro.org>

Google gs101 SoC is ARMv8 mobile SoC found in the Pixel 6,
(oriole) Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
phones. It features:
* 4xA55 little cluster
* 2xA76 Mid cluster
* 2xX1 Big cluster

This commit adds the basic device tree for gs101 (SoC).
Further platform support will be added over time.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../boot/dts/exynos/google/gs101-pinctrl.dtsi | 1250 +++++++++++++++++
 .../boot/dts/exynos/google/gs101-pinctrl.h    |   33 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  476 +++++++
 3 files changed, 1759 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi

diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
new file mode 100644
index 000000000000..8c0f0cf75edb
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
@@ -0,0 +1,1250 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright 2019-2023 Google LLC
+ * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
+ */
+
+#include "gs101-pinctrl.h"
+
+&pinctrl_gpio_alive {
+	gpa0: gpa0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa1: gpa1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa2: gpa2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa3: gpa3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa4: gpa4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa5: gpa5-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa9: gpa9-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa10: gpa10-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	uart15_bus: uart15-bus-pins {
+		samsung,pins = "gpa2-3", "gpa2-4";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	uart16_bus: uart16-bus-pins {
+		samsung,pins = "gpa3-0", "gpa3-1", "gpa3-2", "gpa3-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	uart17_bus: uart17-bus-pins {
+		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2", "gpa4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi15_bus: spi15-bus-pins {
+		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi15_cs: spi15-cs-pins {
+		samsung,pins = "gpa4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_far_alive {
+	gpa6: gpa6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa7: gpa7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa8: gpa8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa11: gpa11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+};
+
+&pinctrl_gsacore {
+	gps0: gps0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps1: gps1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps2: gps2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_gsactrl {
+	gps3: gps3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_hsi1 {
+	gph0: gph0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph1: gph1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	pcie0_clkreq: pcie0-clkreq-pins{
+		samsung,pins = "gph0-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
+	};
+
+	pcie0_perst: pcie0-perst-pins {
+		samsung,pins = "gph0-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+	};
+};
+
+&pinctrl_hsi2 {
+	gph2: gph2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph3: gph3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph4: gph4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	sd2_clk: sd2-clk-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_cmd: sd2-cmd-pins {
+		samsung,pins = "gph4-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus1: sd2-bus-width1-pins {
+		samsung,pins = "gph4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus4: sd2-bus-width4-pins {
+		samsung,pins = "gph4-3", "gph4-4", "gph4-5";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_1x: sd2-clk-fast-slew-rate-1x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_2x: sd2-clk-fast-slew-rate-2x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_3x: sd2-clk-fast-slew-rate-3x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_4x: sd2-clk-fast-slew-rate-4x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+	};
+
+	ufs_rst_n: ufs-rst-n-pins {
+		samsung,pins = "gph3-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	ufs_refclk_out: ufs-refclk-out-pins {
+		samsung,pins = "gph3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	pcie1_clkreq: pcie1-clkreq-pins {
+		samsung,pins = "gph2-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
+	};
+
+	pcie1_perst: pcie1-perst-pins {
+		samsung,pins = "gph2-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+	};
+};
+
+&pinctrl_peric0 {
+	gpp0: gpp0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp1: gpp1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp2: gpp2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp3: gpp3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp4: gpp4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp5: gpp5-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp6: gpp6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp7: gpp7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp8: gpp8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp9: gpp9-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp10: gpp10-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp11: gpp11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp12: gpp12-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp13: gpp13-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp14: gpp14-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp15: gpp15-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp16: gpp16-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp17: gpp17-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp18: gpp18-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp19: gpp19-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	/* USI_PERIC0_UART_DBG */
+	uart0_bus: uart0-bus-pins {
+		samsung,pins = "gpp1-2", "gpp1-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	disp_te_pri_on: disp-te-pri-on-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+	};
+
+	disp_te_pri_off: disp-te-pri-off-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
+	};
+
+	disp_te_sec_on: disp-te-sec-on-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+	};
+
+	disp_te_sec_off: disp-te-sec-off-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
+	};
+
+	sensor_mclk1_out: sensor-mclk1-out-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk1_fn: sensor-mclk1-fn-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_out: sensor-mclk2-out-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_fn: sensor-mclk2-fn-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_out: sensor-mclk3-out-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_fn: sensor-mclk3-fn-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_out: sensor-mclk4-out-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_fn: sensor-mclk4-fn-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_out: sensor-mclk5-out-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_fn: sensor-mclk5-fn-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_out: sensor-mclk6-out-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_fn: sensor-mclk6-fn-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_out: sensor-mclk7-out-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_fn: sensor-mclk7-fn-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_out: sensor-mclk8-out-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_fn: sensor-mclk8-fn-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	hsi2c14_bus: hsi2c14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart14_bus_single: uart14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1",
+			       "gpp18-2", "gpp18-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi14_bus: spi14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1", "gpp18-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs: spi14-cs-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs_func: spi14-cs-func-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c8_bus: hsi2c8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-pud-pdn = <GS101_PIN_PDN_OUT0>;
+	};
+
+	uart8_bus_single: uart8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2",
+			       "gpp16-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi8_bus: spi8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs: spi8-cs-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs_func: spi8-cs-func-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c7_bus: hsi2c7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart7_bus_single: uart7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1",
+			       "gpp14-2", "gpp14-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi7_bus: spi7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1", "gpp14-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs: spi7-cs-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs_func: spi7-cs-func-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c6_bus: hsi2c6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart6_bus_single: uart6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1",
+			       "gpp12-2", "gpp12-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi6_bus: spi6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1", "gpp12-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs: spi6-cs-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs_func: spi6-cs-func-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c5_bus: hsi2c5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart5_bus_single: uart5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1",
+			       "gpp10-2", "gpp10-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi5_bus: spi5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1", "gpp10-2";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi5_cs_func: spi5-cs-func-pins {
+		samsung,pins = "gpp10-3";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	hsi2c4_bus: hsi2c4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart4_bus_single: uart4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1",
+			       "gpp8-2", "gpp8-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi4_bus: spi4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1", "gpp8-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs: spi4-cs-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs_func: spi4-cs-func-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c3_bus: hsi2c3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart3_bus_single: uart3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1",
+			       "gpp6-2", "gpp6-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi3_bus: spi3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1", "gpp6-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs: spi3-cs-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs_func: spi3-cs-func-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c2_bus: hsi2c2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart2_bus_single: uart2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1",
+			       "gpp4-2", "gpp4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi2_bus: spi2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1", "gpp4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs: spi2-cs-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs_func: spi2-cs-func-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c1_bus: hsi2c1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart1_bus_single: uart1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1",
+			       "gpp2-2", "gpp2-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi1_bus: spi1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1", "gpp2-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs: spi1-cs-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs_func: spi1-cs-func-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_peric1 {
+	gpp20: gpp20-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp21: gpp21-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp22: gpp22-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp23: gpp23-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp24: gpp24-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp25: gpp25-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp26: gpp26-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp27: gpp27-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	hsi2c13_bus: hsi2c13-bus-pins  {
+		samsung,pins = "gpp25-0", "gpp25-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart13_bus_single: uart13-bus-pins {
+		samsung,pins = "gpp25-0", "gpp25-1",
+			       "gpp25-2", "gpp25-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi13_bus: spi13-bus-pins {
+		samsung,pins = "gpp25-0", "gpp25-1", "gpp25-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs: spi13-cs-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs_func: spi13-cs-func-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c12_bus: hsi2c12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart12_bus_single: uart12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5",
+			       "gpp23-6", "gpp23-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi12_bus: spi12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5", "gpp23-6";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs2: spi14-cs2-pins {
+		samsung,pins = "gpp23-6";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs: spi12-cs-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs_func: spi12-cs-func-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c11_bus: hsi2c11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart11_bus_single: uart11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1",
+			       "gpp23-2", "gpp23-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi11_bus: spi11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1", "gpp23-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs: spi11-cs-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs_func: spi11-cs-func-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c10_bus: hsi2c10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart10_bus_single: uart10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1",
+			       "gpp21-2", "gpp21-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi10_bus: spi10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1", "gpp21-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs: spi10-cs-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs_func: spi10-cs-func-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c9_bus: hsi2c9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart9_bus_single: uart9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5",
+			       "gpp20-6", "gpp20-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi9_bus: spi9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5", "gpp20-6";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs: spi9-cs-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs_func: spi9-cs-func-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c0_bus: hsi2c0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart0_bus_single: uart0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1",
+			       "gpp20-2", "gpp20-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi0_bus: spi0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1", "gpp20-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs: spi0-cs-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs_func: spi0-cs-func-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
new file mode 100644
index 000000000000..853505e45b60
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Pinctrl binding constants for GS101
+ *
+ * Copyright (c) 2020-2023 Google, LLC.
+ */
+
+#ifndef __DT_BINDINGS_PINCTRL_GS101_H__
+#define __DT_BINDINGS_PINCTRL_GS101_H__
+
+#define GS101_PIN_PULL_NONE		0
+#define GS101_PIN_PULL_DOWN		1
+#define GS101_PIN_PULL_UP		3
+
+/* Pin function in power down mode */
+#define GS101_PIN_PDN_OUT0		0
+#define GS101_PIN_PDN_OUT1		1
+#define GS101_PIN_PDN_INPUT		2
+#define GS101_PIN_PDN_PREV		3
+
+/* GS101 drive strengths */
+#define GS101_PIN_DRV_2_5_MA		0
+#define GS101_PIN_DRV_5_MA		1
+#define GS101_PIN_DRV_7_5_MA		2
+#define GS101_PIN_DRV_10_MA		3
+
+#define GS101_PIN_FUNC_INPUT		0
+#define GS101_PIN_FUNC_OUTPUT		1
+#define GS101_PIN_FUNC_2		2
+#define GS101_PIN_FUNC_3		3
+#define GS101_PIN_FUNC_EINT		0xf
+
+#endif /* __DT_BINDINGS_PINCTRL_GS101_H__ */
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
new file mode 100644
index 000000000000..40f6654a23f2
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -0,0 +1,476 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC
+ *
+ * Copyright 2019-2023 Google LLC
+ * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
+ */
+
+#include <dt-bindings/clock/google,gs101.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/samsung,exynos-usi.h>
+
+/ {
+	compatible = "google,gs101";
+	#address-cells = <2>;
+	#size-cells = <1>;
+
+	interrupt-parent = <&gic>;
+
+	aliases {
+		pinctrl0 = &pinctrl_gpio_alive;
+		pinctrl1 = &pinctrl_far_alive;
+		pinctrl2 = &pinctrl_gsacore;
+		pinctrl3 = &pinctrl_gsactrl;
+		pinctrl4 = &pinctrl_peric0;
+		pinctrl5 = &pinctrl_peric1;
+		pinctrl6 = &pinctrl_hsi1;
+		pinctrl7 = &pinctrl_hsi2;
+		serial0 = &serial_0;
+	};
+
+	pmu-0 {
+		compatible = "arm,cortex-a55-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
+	};
+
+	pmu-1 {
+		compatible = "arm,cortex-a76-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
+	};
+
+	pmu-2 {
+		compatible = "arm,cortex-x1-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster2>;
+	};
+
+	pmu-3 {
+		compatible = "arm,dsu-pmu";
+		interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH 0>;
+		cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
+		       <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
+	};
+
+	/* TODO replace with CCF clock */
+	dummy_clk: oscillator {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <12345>;
+		clock-output-names = "pclk";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+				core1 {
+					cpu = <&cpu1>;
+				};
+				core2 {
+					cpu = <&cpu2>;
+				};
+				core3 {
+					cpu = <&cpu3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu4>;
+				};
+				core1 {
+					cpu = <&cpu5>;
+				};
+			};
+
+			cluster2 {
+				core0 {
+					cpu = <&cpu6>;
+				};
+				core1 {
+					cpu = <&cpu7>;
+				};
+			};
+		};
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0000>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu1: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0100>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu2: cpu at 200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0200>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu3: cpu at 300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0300>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu4: cpu at 400 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a76";
+			reg = <0x0400>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu5: cpu at 500 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a76";
+			reg = <0x0500>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu6: cpu at 600 {
+			device_type = "cpu";
+			compatible = "arm,cortex-x1";
+			reg = <0x0600>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		cpu7: cpu at 700 {
+			device_type = "cpu";
+			compatible = "arm,cortex-x1";
+			reg = <0x0700>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		idle-states {
+			entry-method = "psci";
+
+			ANANKE_CPU_SLEEP: cpu-ananke-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <70>;
+				exit-latency-us = <160>;
+				min-residency-us = <2000>;
+			};
+
+			ENYO_CPU_SLEEP: cpu-enyo-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <150>;
+				exit-latency-us = <190>;
+				min-residency-us = <2500>;
+			};
+
+			HERA_CPU_SLEEP: cpu-hera-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <235>;
+				exit-latency-us = <220>;
+				min-residency-us = <3500>;
+			};
+		};
+	};
+
+	/* ect node is required to be present by bootloader */
+	ect {
+	};
+
+	ext_24_5m: clock-1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-output-names = "oscclk";
+	};
+
+	ext_200m: clock-2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-output-names = "ext-200m";
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges;
+
+		gsa_reserved_protected: gsa at 90200000 {
+			reg = <0x0 0x90200000 0x400000>;
+			no-map;
+		};
+
+		tpu_fw_reserved: tpu-fw at 93000000 {
+			reg = <0x0 0x93000000 0x1000000>;
+			no-map;
+		};
+
+		aoc_reserve: aoc at 94000000 {
+			reg = <0x0 0x94000000 0x03000000>;
+			no-map;
+		};
+
+		abl_reserved: abl at f8800000 {
+			reg = <0x0 0xf8800000 0x02000000>;
+			no-map;
+		};
+
+		dss_log_reserved: dss-log-reserved at fd3f0000 {
+			reg = <0x0 0xfd3f0000 0x0000e000>;
+			no-map;
+		};
+
+		debug_kinfo_reserved: debug-kinfo-reserved at fd3fe000 {
+			reg = <0x0 0xfd3fe000 0x00001000>;
+			no-map;
+		};
+
+		bldr_log_reserved: bldr-log-reserved at fd800000 {
+			reg = <0x0 0xfd800000 0x00100000>;
+			no-map;
+		};
+
+		bldr_log_hist_reserved: bldr-log-hist-reserved at fd900000 {
+			reg = <0x0 0xfd900000 0x00002000>;
+			no-map;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts =
+		   <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+		   <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+		   <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+		   <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>;
+		clock-frequency = <24576000>;
+	};
+
+	soc: soc at 0 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0x0 0x40000000>;
+
+		cmu_misc: clock-controller at 10010000 {
+			compatible = "google,gs101-cmu-misc";
+			reg = <0x10010000 0x8000>;
+			#clock-cells = <1>;
+			clocks =  <&ext_24_5m>, <&cmu_top CLK_DOUT_MISC_BUS>;
+			clock-names = "oscclk", "dout_cmu_misc_bus";
+		};
+
+		watchdog_cl0: watchdog at 10060000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x10060000 0x100>;
+			interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks =
+			  <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0_IPCLKPORT_PCLK>,
+			  <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <0>;
+			status = "disabled";
+		};
+
+		watchdog_cl1: watchdog at 10070000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x10070000 0x100>;
+			interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks =
+			  <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1_IPCLKPORT_PCLK>,
+			  <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <1>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller at 10400000 {
+			compatible = "arm,gic-v3";
+			#interrupt-cells = <4>;
+			interrupt-controller;
+			reg = <0x10400000 0x10000>, /* GICD */
+			      <0x10440000 0x100000>;/* GICR * 8 */
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+
+			ppi-partitions {
+				ppi_cluster0: interrupt-partition-0 {
+					affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
+				};
+
+				ppi_cluster1: interrupt-partition-1 {
+					affinity = <&cpu4 &cpu5>;
+				};
+
+				ppi_cluster2: interrupt-partition-2 {
+					affinity = <&cpu6 &cpu7>;
+				};
+			};
+		};
+
+		sysreg_peric0: syscon at 10820000 {
+			compatible = "google,gs101-peric0-sysreg", "syscon";
+			reg = <0x10820000 0x10000>;
+		};
+
+		pinctrl_peric0: pinctrl at 10840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x10840000 0x00001000>;
+			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		usi_uart: usi at 10a000c0 {
+			compatible = "google,gs101-usi",
+				     "samsung,exynos850-usi";
+			reg = <0x10a000c0 0x20>;
+			samsung,sysreg = <&sysreg_peric0 0x1020>;
+			samsung,mode = <USI_V2_UART>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+			clocks = <&dummy_clk>, <&dummy_clk>;
+			clock-names = "pclk", "ipclk";
+			status = "disabled";
+
+			serial_0: serial at 10a00000 {
+				compatible = "google,gs101-uart";
+				reg = <0x10a00000 0xc0>;
+				reg-io-width = <4>;
+				samsung,uart-fifosize = <256>;
+				interrupts = <GIC_SPI 634
+					      IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
+				clock-names = "uart", "clk_uart_baud0";
+				status = "disabled";
+			};
+		};
+
+		pinctrl_peric1: pinctrl at 10c40000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x10C40000 0x00001000>;
+			interrupts = <GIC_SPI 644 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		sysreg_peric1: syscon at 10c20000 {
+			compatible = "google,gs101-peric1-sysreg", "syscon";
+			reg = <0x10C20000 0x10000>;
+		};
+
+		pinctrl_hsi1: pinctrl at 11840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x11840000 0x00001000>;
+			interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		pinctrl_hsi2: pinctrl at 14440000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x14440000 0x00001000>;
+			interrupts = <GIC_SPI 503 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		cmu_apm: clock-controller at 17400000 {
+			compatible = "google,gs101-cmu-apm";
+			reg = <0x17400000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+
+		sysreg_apm: syscon at 174204e0 {
+			compatible = "google,gs101-apm-sysreg", "syscon";
+			reg = <0x174204e0 0x1000>;
+		};
+
+		pmu_system_controller: system-controller at 17460000 {
+			compatible = "google,gs101-pmu", "syscon";
+			reg = <0x17460000 0x10000>;
+		};
+
+		pinctrl_gpio_alive: pinctrl at 174d0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x174d0000 0x00001000>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint",
+					     "samsung,exynos850-wakeup-eint",
+					     "samsung,exynos7-wakeup-eint";
+			};
+		};
+
+		pinctrl_far_alive: pinctrl at 174e0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x174e0000 0x00001000>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint",
+					     "samsung,exynos850-wakeup-eint",
+					     "samsung,exynos7-wakeup-eint";
+			};
+		};
+
+		pinctrl_gsactrl: pinctrl at 17940000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x17940000 0x00001000>;
+		};
+
+		pinctrl_gsacore: pinctrl at 17a80000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x17a80000 0x00001000>;
+		};
+
+		cmu_top: clock-controller at 1e080000 {
+			compatible = "google,gs101-cmu-top";
+			reg = <0x1e080000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+	};
+};
+
+#include "gs101-pinctrl.dtsi"
-- 
2.43.0.rc2.451.g8631bc7472-goog



From conor at kernel.org  Fri Dec  1 08:11:27 2023
From: conor at kernel.org (Conor Dooley)
Date: Fri, 1 Dec 2023 16:11:27 +0000
Subject: [PATCH v2 0/9] arm64: dts: mediatek: Add MT8186 Corsola
 Chromebooks
In-Reply-To: <20231201070719.1229447-1-wenst@chromium.org>
References: <20231201070719.1229447-1-wenst@chromium.org>
Message-ID: <20231201-esteemed-finch-84782fad14cc@spud>

On Fri, Dec 01, 2023 at 03:07:04PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
> 
> This is v2 of the MT8186 Chromebook device tree series.
> 
> Changes since v1:
> - Reorder SKU numbers in descending order.
> - Fixed pinconfig node names
> - Moved pinctrl-* properties after interrupts-*
> - Switched to interrupts-extended for external components
> - Marked ADSP as explicitly disabled, with a comment explaining that it
>   stalls the system
> - Renamed "touchpad" to "trackpad"
> - Dropped bogus "no-laneswap" property from it6505 node
> - Moved "realtek,jd-src" property to after all the regulator supplies
> - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> - Renamed "vgpu" regulator name to allow coupling, with a comment
>   containing the name used in the design
> - Renamed "cr50" node name to "tpm"
> - Moved trackpad_pins reference up to i2c2; workaround for second source
>   component resource sharing.
> - Fix copyright year
> - Fixed touchscreen supply name
> - Mark missing components as disabled instead of deleting the node
> - Dropped reset-gpios from touchscreen nodes
> - Drop status = "okay", which is the default
> 
> 
> This series adds device trees for the various MT8186 Chromebooks that
> were initially released. These are the Tentacruel / Tentacool devices
> released by ASUS, and the Steelix / Rusty / Magneton devices released
> by Lenovo. The device trees are taken from the downstream ChromeOS v5.15
> kernel, ported to mainline and cleaned up.
> 
> Corsola is the Google codename given to the MT8186 platform. This
> platform has two reference designs, Krabby and Kingler. Kingler was not
> used in any actual product, and is therefor not included. Steelix is
> an alternative design put forward and is effectively a mix-and-match of
> the two reference designs.
> 
> Most of the core design is shared between the variants. The differences
> are on which external components, such as the display bridges, are used.
> 
> Patch 1 cleans up the current list of MediaTek boards. The entries are
> reordered by SoC model first, then by board name.
> 
> Patch 2 through 5 add DT binding entries for the Tentacruel/Tentacool,
> Steelix, Rusty, and Magneton Chromebooks.
> 
> Patch 6 through 9 add board device tree files for these devices. Patch 6
> also adds the corsola dtsi file for the commonalities between the designs,
> as well as a dtsi file for the krabby reference design.
> 
> Currently external display support is missing. Audio is not working, as
> enabling the audio DSP causes my test systems to hang.

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/019248a2/attachment.sig>

From geert at linux-m68k.org  Fri Dec  1 08:15:55 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 1 Dec 2023 17:15:55 +0100
Subject: [PATCH 05/14] pinctrl: renesas: rzg2l: Move arg in the main
 function block
In-Reply-To: <20231120070024.4079344-6-claudiu.beznea.uj@bp.renesas.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com> <20231120070024.4079344-6-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdWJJ=pjY5YFG=UxL+rWhYtWKicjbGUj-7KC1tgaz4tB3Q@mail.gmail.com>

Hi Claudiu,

On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> Move arg in the main block of the function as this is used by 3 out of 4
> case blocks of switch-case. In this way some lines of code are removed.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Thanks for your patch!

>  drivers/pinctrl/renesas/pinctrl-rzg2l.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)

Unfortunately your claim is not really backed by the diffstat.
What about moving index, too?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From conor at kernel.org  Fri Dec  1 08:16:59 2023
From: conor at kernel.org (Conor Dooley)
Date: Fri, 1 Dec 2023 16:16:59 +0000
Subject: [EXT] Re: [PATCH 1/3] dt-bindings: perf: fsl-imx-ddr: Add i.MX95
 compatible
In-Reply-To: <DB7PR04MB51460A715C6870642B6D7BBE8C81A@DB7PR04MB5146.eurprd04.prod.outlook.com>
References: <20231127073208.1055466-1-xu.yang_2@nxp.com>
 <20231127-whoever-magical-5a7cf2b142e1@spud>
 <DB7PR04MB51460A715C6870642B6D7BBE8C81A@DB7PR04MB5146.eurprd04.prod.outlook.com>
Message-ID: <20231201-pointer-statue-f30a42b8102e@spud>

On Fri, Dec 01, 2023 at 06:41:59AM +0000, Xu Yang wrote:
> Hi Conor,
> 
> > 
> > On Mon, Nov 27, 2023 at 03:32:06PM +0800, Xu Yang wrote:
> > > i.MX95 has a more precise counting capability than i.MX93. This will add
> > > a compatible for it.
> > 
> > It is hard to tell from this comment, but I figure this "more precise
> > capability" is not an option you can enable, but instead makes the
> > programming model of this device different to that of the imx93?
> 
> Actually, imx95 is compatible with imx93 except AXI ID filter capability.
> But for AXI ID filter, imx95 is using different registers and bits from
> imx93 for filter configuration.

This sounds like it conflicts with...

> To distinguish them, I need use different
> compatible because programming model cannot recognize which device is
> running.
> 
> compatible = "fsl,imx95-ddr-pmu";

> compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu";

...this. If drivers for the imx93 need changes to work on the imx95,
then `compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu";` cannot be
used. If they will work, with only the new imx95 features being
non-functional, then you can use it.

> Both above compatible is okay for me. Therefore, "fsl,imx95-ddr-pmu" is needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/3e8c9fd2/attachment.sig>

From andrew at lunn.ch  Fri Dec  1 08:17:28 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 1 Dec 2023 17:17:28 +0100
Subject: [PATCH] dt-bindings: marvell: move MMP boards to common marvell
 directory
In-Reply-To: <944c02f5-d0e6-4367-bb4d-b366054b3e4e@linaro.org>
References: <20231201132306.60753-1-krzysztof.kozlowski@linaro.org>
 <1e25e2f4-e4b9-4219-a9c2-cb6230a62549@lunn.ch>
 <a44b7bb2-34ac-45ab-84c6-630d604f1bcf@linaro.org>
 <5d511e31-8ff5-4c23-a65e-8660833a9799@lunn.ch>
 <944c02f5-d0e6-4367-bb4d-b366054b3e4e@linaro.org>
Message-ID: <9c50d09e-98a0-416f-b779-9cf39d1a94b5@lunn.ch>

On Fri, Dec 01, 2023 at 03:38:36PM +0100, Krzysztof Kozlowski wrote:
> On 01/12/2023 15:34, Andrew Lunn wrote:
> > On Fri, Dec 01, 2023 at 03:21:05PM +0100, Krzysztof Kozlowski wrote:
> >> On 01/12/2023 14:51, Andrew Lunn wrote:
> >>> On Fri, Dec 01, 2023 at 02:23:06PM +0100, Krzysztof Kozlowski wrote:
> >>>> Marvell board bindings are spread over arm/marvell/ and arm/mrvl/
> >>>> directories.  Move MMP board bindings from the latter to the former, to
> >>>> keep all of them together.
> >>>
> >>> Hi Krzysztof
> >>>
> >>> Did you test get_maintainers.pl? MMP has a different maintainer to
> >>> many of the other Marvell SoCs. We want emails going to the correct
> >>> Maintainers, and ideally not spamming the others.
> >>
> >> The old binding was not referenced in MAINTAINERS, at least I could not
> >> find it.
> >> My change does not affect status quo - orphaned files.
> >>
> >> OTOH, some entries like Orion list specific files. Others like Marvell
> >> list entire directory, which is their mistake in the first place.
> >>
> >> There is a mess in this approach, but the mess exists before my patch.
> > 
> > I think these moved files will now match:
> > 
> > ARM/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 SOC support
> > M:      Andrew Lunn <andrew at lunn.ch>
> > M:      Gregory Clement <gregory.clement at bootlin.com>
> > M:      Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> > L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> > S:      Maintained
> > T:      git git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git
> > F:      Documentation/devicetree/bindings/arm/marvell/
> > 
> > But these files are not Gregory or my problem.
> 
> Yeah, that's what I meant by listing entire directory.
> 
> > 
> > If they were orphaned before, i would prefer they are either orphaned
> > after the move, or associated to the correct maintainer. Being
> > associated to the wrong maintainers is worse than having no
> > maintainers at all.
> 
> I can add this to existing maintainers entry. Which one? I see only two
> ARM/Marvell.

MMP SUPPORT
R:      Lubomir Rintel <lkundrak at v3.sk>
L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S:      Odd Fixes
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp.git
F:      arch/arm/boot/dts/marvell/mmp*
F:      arch/arm/mach-mmp/
F:      include/linux/soc/mmp/

But you also need to modify the ARM/Marvell Kirkwood and ... so that
it excludes these MMP files.

   Andrew


From Frank.Li at nxp.com  Fri Dec  1 08:17:08 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Fri,  1 Dec 2023 11:17:08 -0500
Subject: [PATCH v5 0/4] PCI: layerscape: Add suspend/resume support for ls1043 and ls1021
Message-ID: <20231201161712.1645987-1-Frank.Li@nxp.com>

Add suspend/resume support for ls1043 and ls1021.

Change log see each patch

Frank Li (4):
  PCI: layerscape: Add function pointer for exit_from_l2()
  PCI: layerscape: Add suspend/resume for ls1021a
  PCI: layerscape(ep): Rename pf_* as pf_lut_*
  PCI: layerscape: Add suspend/resume for ls1043a

 .../pci/controller/dwc/pci-layerscape-ep.c    |  16 +-
 drivers/pci/controller/dwc/pci-layerscape.c   | 189 ++++++++++++++++--
 2 files changed, 176 insertions(+), 29 deletions(-)

-- 
2.34.1



From Frank.Li at nxp.com  Fri Dec  1 08:17:09 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Fri,  1 Dec 2023 11:17:09 -0500
Subject: [PATCH v5 1/4] PCI: layerscape: Add function pointer for exit_from_l2()
In-Reply-To: <20231201161712.1645987-1-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
Message-ID: <20231201161712.1645987-2-Frank.Li@nxp.com>

Since difference SoCs require different sequence for exiting L2, let's add
a separate "exit_from_l2()" callback. This callback can be used to execute
SoC specific sequence.

Change ls_pcie_exit_from_l2() return value from void to int. Return error
if exit_from_l2() failure at exit resume flow.

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5
    - none
    Change from v3 to v4
    - update commit message
      Add mani's review by tag
    Change from v2 to v3
    - fixed according to mani's feedback
      1. update commit message
      2. move dw_pcie_host_ops to next patch
      3. check return value from exit_from_l2()
    Change from v1 to v2
    - change subject 'a' to 'A'
    
    Change from v1 to v2
    - change subject 'a' to 'A'

 drivers/pci/controller/dwc/pci-layerscape.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 37956e09c65bd..aea89926bcc4f 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -39,6 +39,7 @@
 
 struct ls_pcie_drvdata {
 	const u32 pf_off;
+	int (*exit_from_l2)(struct dw_pcie_rp *pp);
 	bool pm_support;
 };
 
@@ -125,7 +126,7 @@ static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
 		dev_err(pcie->pci->dev, "PME_Turn_off timeout\n");
 }
 
-static void ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
+static int ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
 {
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
 	struct ls_pcie *pcie = to_ls_pcie(pci);
@@ -150,6 +151,8 @@ static void ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
 				 10000);
 	if (ret)
 		dev_err(pcie->pci->dev, "L2 exit timeout\n");
+
+	return ret;
 }
 
 static int ls_pcie_host_init(struct dw_pcie_rp *pp)
@@ -180,6 +183,7 @@ static const struct ls_pcie_drvdata ls1021a_drvdata = {
 static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.pf_off = 0xc0000,
 	.pm_support = true,
+	.exit_from_l2 = ls_pcie_exit_from_l2,
 };
 
 static const struct of_device_id ls_pcie_of_match[] = {
@@ -247,11 +251,14 @@ static int ls_pcie_suspend_noirq(struct device *dev)
 static int ls_pcie_resume_noirq(struct device *dev)
 {
 	struct ls_pcie *pcie = dev_get_drvdata(dev);
+	int ret;
 
 	if (!pcie->drvdata->pm_support)
 		return 0;
 
-	ls_pcie_exit_from_l2(&pcie->pci->pp);
+	ret = pcie->drvdata->exit_from_l2(&pcie->pci->pp);
+	if (ret)
+		return ret;
 
 	return dw_pcie_resume_noirq(pcie->pci);
 }
-- 
2.34.1



From Frank.Li at nxp.com  Fri Dec  1 08:17:10 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Fri,  1 Dec 2023 11:17:10 -0500
Subject: [PATCH v5 2/4] PCI: layerscape: Add suspend/resume for ls1021a
In-Reply-To: <20231201161712.1645987-1-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
Message-ID: <20231201161712.1645987-3-Frank.Li@nxp.com>

Add suspend/resume support for Layerscape LS1021a.

In the suspend path, PME_Turn_Off message is sent to the endpoint to
transition the link to L2/L3_Ready state. In this SoC, there is no way to
check if the controller has received the PME_To_Ack from the endpoint or
not. So to be on the safer side, the driver just waits for
PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF
bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3
state depending on the VAUX supply.

In the resume path, the link is brought back from L2 to L0 by doing a
software reset.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5
    - update comit message
    - remove a empty line
    - use comments
    /* Reset the PEX wrapper to bring the link out of L2 */
    - pci->pp.ops = pcie->drvdata->ops,
    ls_pcie_host_ops to the "ops" member of layerscape_drvdata.
    - don't set pcie->scfg = NULL at error path
    
    Change from v3 to v4
    - update commit message.
    - it is reset a glue logic part for PCI controller.
    - use regmap_write_bits() to reduce code change.
    
    Change from v2 to v3
    - update according to mani's feedback
    change from v1 to v2
    - change subject 'a' to 'A'

 drivers/pci/controller/dwc/pci-layerscape.c | 81 ++++++++++++++++++++-
 1 file changed, 80 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index aea89926bcc4f..8bdaae9be7d56 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -35,11 +35,19 @@
 #define PF_MCR_PTOMR		BIT(0)
 #define PF_MCR_EXL2S		BIT(1)
 
+/* LS1021A PEXn PM Write Control Register */
+#define SCFG_PEXPMWRCR(idx)	(0x5c + (idx) * 0x64)
+#define PMXMTTURNOFF		BIT(31)
+#define SCFG_PEXSFTRSTCR	0x190
+#define PEXSR(idx)		BIT(idx)
+
 #define PCIE_IATU_NUM		6
 
 struct ls_pcie_drvdata {
 	const u32 pf_off;
+	const struct dw_pcie_host_ops *ops;
 	int (*exit_from_l2)(struct dw_pcie_rp *pp);
+	bool scfg_support;
 	bool pm_support;
 };
 
@@ -47,6 +55,8 @@ struct ls_pcie {
 	struct dw_pcie *pci;
 	const struct ls_pcie_drvdata *drvdata;
 	void __iomem *pf_base;
+	struct regmap *scfg;
+	int index;
 	bool big_endian;
 };
 
@@ -171,18 +181,70 @@ static int ls_pcie_host_init(struct dw_pcie_rp *pp)
 	return 0;
 }
 
+static void scfg_pcie_send_turnoff_msg(struct regmap *scfg, u32 reg, u32 mask)
+{
+	/* Send PME_Turn_Off message */
+	regmap_write_bits(scfg, reg, mask, mask);
+
+	/*
+	 * There is no specific register to check for PME_To_Ack from endpoint.
+	 * So on the safe side, wait for PCIE_PME_TO_L2_TIMEOUT_US.
+	 */
+	mdelay(PCIE_PME_TO_L2_TIMEOUT_US/1000);
+
+	/*
+	 * Layerscape hardware reference manual recommends clearing the PMXMTTURNOFF bit
+	 * to complete the PME_Turn_Off handshake.
+	 */
+	regmap_write_bits(scfg, reg, mask, 0);
+}
+
+static void ls1021a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct ls_pcie *pcie = to_ls_pcie(pci);
+
+	scfg_pcie_send_turnoff_msg(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), PMXMTTURNOFF);
+}
+
+static int scfg_pcie_exit_from_l2(struct regmap *scfg, u32 reg, u32 mask)
+{
+	/* Reset the PEX wrapper to bring the link out of L2 */
+	regmap_write_bits(scfg, reg, mask, mask);
+	regmap_write_bits(scfg, reg, mask, 0);
+
+	return 0;
+}
+
+static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct ls_pcie *pcie = to_ls_pcie(pci);
+
+	return scfg_pcie_exit_from_l2(pcie->scfg, SCFG_PEXSFTRSTCR, PEXSR(pcie->index));
+}
+
 static const struct dw_pcie_host_ops ls_pcie_host_ops = {
 	.host_init = ls_pcie_host_init,
 	.pme_turn_off = ls_pcie_send_turnoff_msg,
 };
 
+static const struct dw_pcie_host_ops ls1021a_pcie_host_ops = {
+	.host_init = ls_pcie_host_init,
+	.pme_turn_off = ls1021a_pcie_send_turnoff_msg,
+};
+
 static const struct ls_pcie_drvdata ls1021a_drvdata = {
-	.pm_support = false,
+	.pm_support = true,
+	.scfg_support = true,
+	.ops = &ls1021a_pcie_host_ops,
+	.exit_from_l2 = ls1021a_pcie_exit_from_l2,
 };
 
 static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.pf_off = 0xc0000,
 	.pm_support = true,
+	.ops = &ls_pcie_host_ops;
 	.exit_from_l2 = ls_pcie_exit_from_l2,
 };
 
@@ -205,6 +267,8 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	struct dw_pcie *pci;
 	struct ls_pcie *pcie;
 	struct resource *dbi_base;
+	u32 index[2];
+	int ret;
 
 	pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
 	if (!pcie)
@@ -220,6 +284,7 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	pci->pp.ops = &ls_pcie_host_ops;
 
 	pcie->pci = pci;
+	pci->pp.ops = pcie->drvdata->ops;
 
 	dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
 	pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
@@ -230,6 +295,20 @@ static int ls_pcie_probe(struct platform_device *pdev)
 
 	pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
 
+	if (pcie->drvdata->scfg_support) {
+		pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node, "fsl,pcie-scfg");
+		if (IS_ERR(pcie->scfg)) {
+			dev_err(dev, "No syscfg phandle specified\n");
+			return PTR_ERR(pcie->scfg);
+		}
+
+		ret = of_property_read_u32_array(dev->of_node, "fsl,pcie-scfg", index, 2);
+		if (ret)
+			return ret;
+
+		pcie->index = index[1];
+	}
+
 	if (!ls_pcie_is_bridge(pcie))
 		return -ENODEV;
 
-- 
2.34.1



From Frank.Li at nxp.com  Fri Dec  1 08:17:11 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Fri,  1 Dec 2023 11:17:11 -0500
Subject: [PATCH v5 3/4] PCI: layerscape(ep): Rename pf_* as pf_lut_*
In-Reply-To: <20231201161712.1645987-1-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
Message-ID: <20231201161712.1645987-4-Frank.Li@nxp.com>

'pf' and 'lut' is just difference name in difference chips, but basic it is
a MMIO base address plus an offset.

Rename it to avoid duplicate pf_* and lut_* in driver.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    pf_lut is better than pf_* or lut* because some chip use 'pf', some chip
    use 'lut'.
    
    Change from v4 to v5
    - rename layerscape-ep code also
    change from v1 to v4
    - new patch at v3

 .../pci/controller/dwc/pci-layerscape-ep.c    | 16 ++++-----
 drivers/pci/controller/dwc/pci-layerscape.c   | 36 +++++++++----------
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index 3d3c50ef4b6ff..2ca339f938a86 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -49,7 +49,7 @@ struct ls_pcie_ep {
 	bool				big_endian;
 };
 
-static u32 ls_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
+static u32 ls_pcie_pf_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
 {
 	struct dw_pcie *pci = pcie->pci;
 
@@ -59,7 +59,7 @@ static u32 ls_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
 		return ioread32(pci->dbi_base + offset);
 }
 
-static void ls_lut_writel(struct ls_pcie_ep *pcie, u32 offset, u32 value)
+static void ls_pcie_pf_lut_writel(struct ls_pcie_ep *pcie, u32 offset, u32 value)
 {
 	struct dw_pcie *pci = pcie->pci;
 
@@ -76,8 +76,8 @@ static irqreturn_t ls_pcie_ep_event_handler(int irq, void *dev_id)
 	u32 val, cfg;
 	u8 offset;
 
-	val = ls_lut_readl(pcie, PEX_PF0_PME_MES_DR);
-	ls_lut_writel(pcie, PEX_PF0_PME_MES_DR, val);
+	val = ls_pcie_pf_lut_readl(pcie, PEX_PF0_PME_MES_DR);
+	ls_pcie_pf_lut_writel(pcie, PEX_PF0_PME_MES_DR, val);
 
 	if (!val)
 		return IRQ_NONE;
@@ -96,9 +96,9 @@ static irqreturn_t ls_pcie_ep_event_handler(int irq, void *dev_id)
 		dw_pcie_writel_dbi(pci, offset + PCI_EXP_LNKCAP, pcie->lnkcap);
 		dw_pcie_dbi_ro_wr_dis(pci);
 
-		cfg = ls_lut_readl(pcie, PEX_PF0_CONFIG);
+		cfg = ls_pcie_pf_lut_readl(pcie, PEX_PF0_CONFIG);
 		cfg |= PEX_PF0_CFG_READY;
-		ls_lut_writel(pcie, PEX_PF0_CONFIG, cfg);
+		ls_pcie_pf_lut_writel(pcie, PEX_PF0_CONFIG, cfg);
 		dw_pcie_ep_linkup(&pci->ep);
 
 		dev_dbg(pci->dev, "Link up\n");
@@ -130,10 +130,10 @@ static int ls_pcie_ep_interrupt_init(struct ls_pcie_ep *pcie,
 	}
 
 	/* Enable interrupts */
-	val = ls_lut_readl(pcie, PEX_PF0_PME_MES_IER);
+	val = ls_pcie_pf_lut_readl(pcie, PEX_PF0_PME_MES_IER);
 	val |=  PEX_PF0_PME_MES_IER_LDDIE | PEX_PF0_PME_MES_IER_HRDIE |
 		PEX_PF0_PME_MES_IER_LUDIE;
-	ls_lut_writel(pcie, PEX_PF0_PME_MES_IER, val);
+	ls_pcie_pf_lut_writel(pcie, PEX_PF0_PME_MES_IER, val);
 
 	return 0;
 }
diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 8bdaae9be7d56..a9151e98fde6f 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -44,7 +44,7 @@
 #define PCIE_IATU_NUM		6
 
 struct ls_pcie_drvdata {
-	const u32 pf_off;
+	const u32 pf_lut_off;
 	const struct dw_pcie_host_ops *ops;
 	int (*exit_from_l2)(struct dw_pcie_rp *pp);
 	bool scfg_support;
@@ -54,13 +54,13 @@ struct ls_pcie_drvdata {
 struct ls_pcie {
 	struct dw_pcie *pci;
 	const struct ls_pcie_drvdata *drvdata;
-	void __iomem *pf_base;
+	void __iomem *pf_lut_base;
 	struct regmap *scfg;
 	int index;
 	bool big_endian;
 };
 
-#define ls_pcie_pf_readl_addr(addr)	ls_pcie_pf_readl(pcie, addr)
+#define ls_pcie_pf_lut_readl_addr(addr)	ls_pcie_pf_lut_readl(pcie, addr)
 #define to_ls_pcie(x)	dev_get_drvdata((x)->dev)
 
 static bool ls_pcie_is_bridge(struct ls_pcie *pcie)
@@ -101,20 +101,20 @@ static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
 	iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR);
 }
 
-static u32 ls_pcie_pf_readl(struct ls_pcie *pcie, u32 off)
+static u32 ls_pcie_pf_lut_readl(struct ls_pcie *pcie, u32 off)
 {
 	if (pcie->big_endian)
-		return ioread32be(pcie->pf_base + off);
+		return ioread32be(pcie->pf_lut_base + off);
 
-	return ioread32(pcie->pf_base + off);
+	return ioread32(pcie->pf_lut_base + off);
 }
 
-static void ls_pcie_pf_writel(struct ls_pcie *pcie, u32 off, u32 val)
+static void ls_pcie_pf_lut_writel(struct ls_pcie *pcie, u32 off, u32 val)
 {
 	if (pcie->big_endian)
-		iowrite32be(val, pcie->pf_base + off);
+		iowrite32be(val, pcie->pf_lut_base + off);
 	else
-		iowrite32(val, pcie->pf_base + off);
+		iowrite32(val, pcie->pf_lut_base + off);
 }
 
 static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
@@ -124,11 +124,11 @@ static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
 	u32 val;
 	int ret;
 
-	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_PF_MCR);
 	val |= PF_MCR_PTOMR;
-	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_PF_MCR, val);
 
-	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
+	ret = readx_poll_timeout(ls_pcie_pf_lut_readl_addr, LS_PCIE_PF_MCR,
 				 val, !(val & PF_MCR_PTOMR),
 				 PCIE_PME_TO_L2_TIMEOUT_US/10,
 				 PCIE_PME_TO_L2_TIMEOUT_US);
@@ -147,15 +147,15 @@ static int ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
 	 * Set PF_MCR_EXL2S bit in LS_PCIE_PF_MCR register for the link
 	 * to exit L2 state.
 	 */
-	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_PF_MCR);
 	val |= PF_MCR_EXL2S;
-	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_PF_MCR, val);
 
 	/*
 	 * L2 exit timeout of 10ms is not defined in the specifications,
 	 * it was chosen based on empirical observations.
 	 */
-	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
+	ret = readx_poll_timeout(ls_pcie_pf_lut_readl_addr, LS_PCIE_PF_MCR,
 				 val, !(val & PF_MCR_EXL2S),
 				 1000,
 				 10000);
@@ -242,9 +242,9 @@ static const struct ls_pcie_drvdata ls1021a_drvdata = {
 };
 
 static const struct ls_pcie_drvdata layerscape_drvdata = {
-	.pf_off = 0xc0000,
+	.pf_lut_off = 0xc0000,
 	.pm_support = true,
-	.ops = &ls_pcie_host_ops;
+	.ops = &ls_pcie_host_ops,
 	.exit_from_l2 = ls_pcie_exit_from_l2,
 };
 
@@ -293,7 +293,7 @@ static int ls_pcie_probe(struct platform_device *pdev)
 
 	pcie->big_endian = of_property_read_bool(dev->of_node, "big-endian");
 
-	pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
+	pcie->pf_lut_base = pci->dbi_base + pcie->drvdata->pf_lut_off;
 
 	if (pcie->drvdata->scfg_support) {
 		pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node, "fsl,pcie-scfg");
-- 
2.34.1



From Frank.Li at nxp.com  Fri Dec  1 08:17:12 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Fri,  1 Dec 2023 11:17:12 -0500
Subject: [PATCH v5 4/4] PCI: layerscape: Add suspend/resume for ls1043a
In-Reply-To: <20231201161712.1645987-1-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
Message-ID: <20231201161712.1645987-5-Frank.Li@nxp.com>

Add suspend/resume support for Layerscape LS1043a.

In the suspend path, PME_Turn_Off message is sent to the endpoint to
transition the link to L2/L3_Ready state. In this SoC, there is no way to
check if the controller has received the PME_To_Ack from the endpoint or
not. So to be on the safer side, the driver just waits for
PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF
bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3
state depending on the VAUX supply.

In the resume path, the link is brought back from L2 to L0 by doing a
software reset.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5
    - update commit message
    - use comments
    /* Reset the PEX wrapper to bring the link out of L2 */
    
    Change from v3 to v4
    - Call scfg_pcie_send_turnoff_msg() shared with ls1021a
    - update commit message
    
    Change from v2 to v3
    - Remove ls_pcie_lut_readl(writel) function
    
    Change from v1 to v2
    - Update subject 'a' to 'A'

 drivers/pci/controller/dwc/pci-layerscape.c | 63 ++++++++++++++++++++-
 1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index a9151e98fde6f..715365e91f8ef 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -41,6 +41,15 @@
 #define SCFG_PEXSFTRSTCR	0x190
 #define PEXSR(idx)		BIT(idx)
 
+/* LS1043A PEX PME control register */
+#define SCFG_PEXPMECR		0x144
+#define PEXPME(idx)		BIT(31 - (idx) * 4)
+
+/* LS1043A PEX LUT debug register */
+#define LS_PCIE_LDBG	0x7fc
+#define LDBG_SR		BIT(30)
+#define LDBG_WE		BIT(31)
+
 #define PCIE_IATU_NUM		6
 
 struct ls_pcie_drvdata {
@@ -224,6 +233,45 @@ static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
 	return scfg_pcie_exit_from_l2(pcie->scfg, SCFG_PEXSFTRSTCR, PEXSR(pcie->index));
 }
 
+static void ls1043a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct ls_pcie *pcie = to_ls_pcie(pci);
+
+	scfg_pcie_send_turnoff_msg(pcie->scfg, SCFG_PEXPMECR, PEXPME(pcie->index));
+}
+
+static int ls1043a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct ls_pcie *pcie = to_ls_pcie(pci);
+	u32 val;
+
+	/*
+	 * Reset the PEX wrapper to bring the link out of L2.
+	 * LDBG_WE: allows the user to have write access to the PEXDBG[SR] for both setting and
+	 *	    clearing the soft reset on the PEX module.
+	 * LDBG_SR: When SR is set to 1, the PEX module enters soft reset.
+	 */
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
+	val |= LDBG_WE;
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
+	val |= LDBG_SR;
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
+	val &= ~LDBG_SR;
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
+	val &= ~LDBG_WE;
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	return 0;
+}
+
 static const struct dw_pcie_host_ops ls_pcie_host_ops = {
 	.host_init = ls_pcie_host_init,
 	.pme_turn_off = ls_pcie_send_turnoff_msg,
@@ -241,6 +289,19 @@ static const struct ls_pcie_drvdata ls1021a_drvdata = {
 	.exit_from_l2 = ls1021a_pcie_exit_from_l2,
 };
 
+static const struct dw_pcie_host_ops ls1043a_pcie_host_ops = {
+	.host_init = ls_pcie_host_init,
+	.pme_turn_off = ls1043a_pcie_send_turnoff_msg,
+};
+
+static const struct ls_pcie_drvdata ls1043a_drvdata = {
+	.pf_lut_off = 0x10000,
+	.pm_support = true,
+	.scfg_support = true,
+	.ops = &ls1043a_pcie_host_ops,
+	.exit_from_l2 = ls1043a_pcie_exit_from_l2,
+};
+
 static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.pf_lut_off = 0xc0000,
 	.pm_support = true,
@@ -252,7 +313,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
 	{ .compatible = "fsl,ls1012a-pcie", .data = &layerscape_drvdata },
 	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021a_drvdata },
 	{ .compatible = "fsl,ls1028a-pcie", .data = &layerscape_drvdata },
-	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1021a_drvdata },
+	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043a_drvdata },
 	{ .compatible = "fsl,ls1046a-pcie", .data = &layerscape_drvdata },
 	{ .compatible = "fsl,ls2080a-pcie", .data = &layerscape_drvdata },
 	{ .compatible = "fsl,ls2085a-pcie", .data = &layerscape_drvdata },
-- 
2.34.1



From cristian.marussi at arm.com  Fri Dec  1 08:17:56 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 1 Dec 2023 16:17:56 +0000
Subject: [PATCH 1/2] firmware: arm_scmi: Fix frequency truncation by
 promoting multiplier to u64
In-Reply-To: <20231201143935.be6wzjzxmyl5vpz6@bogus>
References: <20231130204343.503076-1-sudeep.holla@arm.com>
 <20231201143935.be6wzjzxmyl5vpz6@bogus>
Message-ID: <ZWoHNPlxs-WnVAFe@pluto>

On Fri, Dec 01, 2023 at 02:39:35PM +0000, Sudeep Holla wrote:
> On Thu, Nov 30, 2023 at 08:43:42PM +0000, Sudeep Holla wrote:
> > Fix the frequency truncation for all values equal to or greater 4GHz by
> > updating the multiplier 'mult_factor' to u64 type. It is also possible
> > that the multiplier itself can be greater than or equal to 2^32. So we need
> > to also fix the equation computing the value of the multiplier.
> > 
> > Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol")
> > Reported-by: Sibi Sankar <quic_sibis at quicinc.com>
> > Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis at quicinc.com/
> > Cc: Cristian Marussi <cristian.marussi at arm.com>
> > Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> > ---
> >  drivers/firmware/arm_scmi/perf.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
> > index 81dd5c5e5533..8ce449922e55 100644
> > --- a/drivers/firmware/arm_scmi/perf.c
> > +++ b/drivers/firmware/arm_scmi/perf.c
> > @@ -152,7 +152,7 @@ struct perf_dom_info {
> >  	u32 opp_count;
> >  	u32 sustained_freq_khz;
> >  	u32 sustained_perf_level;
> > -	u32 mult_factor;
> > +	u64 mult_factor;
> 
> I have now changed this to unsigned long instead of u64 to fix the 32-bit
> build failure[1].

Right, I was caught a few times too by this kind of failures on v7 :D

... but this 32bit issue makes me wonder what to do in such a case...

...I mean, on 32bit if the calculated freq oveflows, there is just
nothing we can do on v7 without overcomplicating the code...but I suppose
it is unplausible to have such high freq on a v7... as a palliative I can
only think of some sort of overflow check (only on v7) that could trigger
a warning ... but it is hardly worth the effort probably..

Thanks,
Cristian


From cristian.marussi at arm.com  Fri Dec  1 08:23:58 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 1 Dec 2023 16:23:58 +0000
Subject: [PATCH 2/2] firmware: arm_scmi: Fix possible frequency
 truncation when using level indexing mode
In-Reply-To: <20231130204343.503076-2-sudeep.holla@arm.com>
References: <20231130204343.503076-1-sudeep.holla@arm.com>
 <20231130204343.503076-2-sudeep.holla@arm.com>
Message-ID: <ZWoInq9QIuZXpTbc@pluto>

On Thu, Nov 30, 2023 at 08:43:43PM +0000, Sudeep Holla wrote:
> The multiplier is already promoted to u64, however the frequency
> calculations done when using level indexing mode doesn't use the
> multiplier computed. It instead hardcodes the multiplier value of 1000
> at all the usage sites.
> 
> Clean that up by assigning the multiplier value of 1000 when using
> the perf level indexing mode and upadte the frequency calculations to

				   ^update

> use the multiplier instead. It should fix the possible frequency
> truncation for all the values greater than or equal to 4GHz.
> 
> Fixes: 31c7c1397a33 ("firmware: arm_scmi: Add v3.2 perf level indexing mode support")
> Reported-by: Sibi Sankar <quic_sibis at quicinc.com>
> Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis at quicinc.com/
> Cc: Cristian Marussi <cristian.marussi at arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---

Other than the typo, LGTM.

Reviewed-by: Cristian Marussi <cristian.marussi at arm.com>

Thanks,
Cristian

>  drivers/firmware/arm_scmi/perf.c | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
> index 8ce449922e55..875dcb71bb65 100644
> --- a/drivers/firmware/arm_scmi/perf.c
> +++ b/drivers/firmware/arm_scmi/perf.c
> @@ -268,7 +268,8 @@ scmi_perf_domain_attributes_get(const struct scmi_protocol_handle *ph,
>  		dom_info->sustained_perf_level =
>  					le32_to_cpu(attr->sustained_perf_level);
>  		if (!dom_info->sustained_freq_khz ||
> -		    !dom_info->sustained_perf_level)
> +		    !dom_info->sustained_perf_level ||
> +		    dom_info->level_indexing_mode)
>  			/* CPUFreq converts to kHz, hence default 1000 */
>  			dom_info->mult_factor =	1000;
>  		else
> @@ -806,7 +807,7 @@ static int scmi_dvfs_device_opps_add(const struct scmi_protocol_handle *ph,
>  		if (!dom->level_indexing_mode)
>  			freq = dom->opp[idx].perf * dom->mult_factor;
>  		else
> -			freq = dom->opp[idx].indicative_freq * 1000;
> +			freq = dom->opp[idx].indicative_freq * dom->mult_factor;
> 
>  		data.level = dom->opp[idx].perf;
>  		data.freq = freq;
> @@ -853,7 +854,8 @@ static int scmi_dvfs_freq_set(const struct scmi_protocol_handle *ph, u32 domain,
>  	} else {
>  		struct scmi_opp *opp;
> 
> -		opp = LOOKUP_BY_FREQ(dom->opps_by_freq, freq / 1000);
> +		opp = LOOKUP_BY_FREQ(dom->opps_by_freq,
> +				     freq / dom->mult_factor);
>  		if (!opp)
>  			return -EIO;
> 
> @@ -887,7 +889,7 @@ static int scmi_dvfs_freq_get(const struct scmi_protocol_handle *ph, u32 domain,
>  		if (!opp)
>  			return -EIO;
> 
> -		*freq = opp->indicative_freq * 1000;
> +		*freq = opp->indicative_freq * dom->mult_factor;
>  	}
> 
>  	return ret;
> @@ -910,7 +912,7 @@ static int scmi_dvfs_est_power_get(const struct scmi_protocol_handle *ph,
>  		if (!dom->level_indexing_mode)
>  			opp_freq = opp->perf * dom->mult_factor;
>  		else
> -			opp_freq = opp->indicative_freq * 1000;
> +			opp_freq = opp->indicative_freq * dom->mult_factor;
> 
>  		if (opp_freq < *freq)
>  			continue;
> --
> 2.43.0
> 


From conor at kernel.org  Fri Dec  1 08:24:56 2023
From: conor at kernel.org (Conor Dooley)
Date: Fri, 1 Dec 2023 16:24:56 +0000
Subject: [PATCH V2 1/2] dt-bindings: usb: xhci: Add optional power-domains
In-Reply-To: <c9f14a17-0dd8-4bf8-a969-8592593b39c5@broadcom.com>
References: <20231130154229.22334-1-wahrenst@gmx.net>
 <20231130154229.22334-2-wahrenst@gmx.net>
 <c9f14a17-0dd8-4bf8-a969-8592593b39c5@broadcom.com>
Message-ID: <20231201-scandal-zap-c55d403d683b@spud>

On Thu, Nov 30, 2023 at 09:50:17AM -0800, Florian Fainelli wrote:
> On 11/30/23 07:42, Stefan Wahren wrote:
> > BCM2711 SoC use a power domain for the xHCI. So allow supplying this
> > domain in bindings.
> > 
> > Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
> > Acked-by: Conor Dooley <conor.dooley at microchip.com>
> > ---
> >   Documentation/devicetree/bindings/usb/generic-xhci.yaml | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > index 594ebb3ee432..e48beaff7d0d 100644
> > --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > @@ -49,6 +49,9 @@ properties:
> >         - const: core
> >         - const: reg
> > 
> > +  power-domains:
> > +    maxItems: 1
> 
> That works, I am not sure whether we want to key off based upon the
> compatible string, but either way:

If by "key it off" you mean selectively permit "power-domains" based on
the compatible, I think that would be a good idea. There is no bcm2711
specific compatible though at present and I figured there could well be
god-knows-how-many other users of generic-xhci out there that also make
use of power domains, which is why I did not request it of Stefan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/dce5dd1c/attachment-0001.sig>

From fancer.lancer at gmail.com  Fri Dec  1 08:25:19 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Fri, 1 Dec 2023 19:25:19 +0300
Subject: [Linux-stm32] [PATCH v1 2/2] net: stmmac: Add NPCM support
In-Reply-To: <20231130213441.032a661c@device.home>
References: <6aeb28f5-04c2-4723-9da2-d168025c307c@lunn.ch>
 <CAP6Zq1j0kyrg+uxkXH-HYqHz0Z4NwWRUGzprius=BPC9+WfKFQ@mail.gmail.com>
 <9ad42fef-b210-496a-aafc-eb2a7416c4df@lunn.ch>
 <CAP6Zq1jw9uLP_FQGR8=p3Y2NTP6XcNtzkJQ0dm3+xVNE1SpsVg@mail.gmail.com>
 <CAP6Zq1ijfMSPjk1vPwDM2B+r_vAH3DShhSu_jr8xJyUkTQY89w@mail.gmail.com>
 <a551aefa-777d-4fd3-b1a5-086dc3e62646@lunn.ch>
 <CAP6Zq1jVO5y3ySeGNE5-=XWV6Djay5MhGxXCZb9y91q=EA71Vg@mail.gmail.com>
 <25d0c091-3dce-4d62-a112-c82106809c65@lunn.ch>
 <xvy2coamb6cl3wcbkl32f6w7kksoxfocyd63t7k7bz4pne2gyx@lktivhqovy7p>
 <20231130213441.032a661c@device.home>
Message-ID: <dfbwvsvefbkj6lodj5nmj2up32vnai32u3qk667mpfjytvmp4z@uvny7nhaykzi>

Hi Maxime

On Thu, Nov 30, 2023 at 09:34:41PM +0100, Maxime Chevallier wrote:
> Hello,
> 
> On Thu, 30 Nov 2023 22:59:32 +0300
> Serge Semin <fancer.lancer at gmail.com> wrote:
> 
> > On Thu, Nov 30, 2023 at 06:26:13PM +0100, Andrew Lunn wrote:
> > > > I will check with the xpcs maintainer how can we add indirect access
> > > > to the xpcs module.  
> > > 
> > > https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c#L449
> > > 
> > > It creates a regmap for the memory range. On top of that it creates an
> > > MDIO bus. You can then access the PCS in the normal way.  
> > 
> > Actually Synopsys DW XPCS can be synthesized with two types of the CSR
> > interfaces:
> > 1. MDIO: device looks as a normal MDIO device. This option is currently
> >    supported by the STMMAC MDIO driver.
> > 2. MCI/APB3: device MMD CSRs are directly (all CSRs are visible) or
> >    indirectly (paged-base access) accessible over the system memory bus.
> > 
> > In addition to the above XPCS device can be equipped with separate
> > clock sources (at least to feed the MCI or APB3 interface) and may
> > have dedicated IRQ line to signal various events like link
> > establishing, failures, etc. From that perspective XPCS in both cases
> > looks as a normal platform device for which would be better to have a
> > special DT-node defined with all those resources supplied. Then the
> > XPCS DT-node could be passed to the DW MAC DT-node via the already
> > standardized "pcs-handle" DT-property.
> 

> To my understanding, this should work, there's another PCS that works
> this way : 
> https://elixir.bootlin.com/linux/v6.7-rc3/source/drivers/net/pcs/pcs-rzn1-miic.c

It is similar to that, but since DW XPCS can reside on the normal MDIO
bus and in the system memory I took a liberty to implement the DW XPCS
MCI/APB3 interface support in the framework of the MDIO subsystem,
especially seeing Synopsys call them just "Management Interfaces", the
MMD CSRs can be indirectly accessible and since potentially there can
be more than one XPCS device on the same MCI/APB3 bus.

> 
> Are you still able to use the mdio-regmap glue that Andrew mentioned,
> to avoid the duplication between the mdio and mmio register accesses ?

Andrew cited the glue code using the Lynx PCS driver. In my case it's
DW XPCS driver. In anycase my patchset is designed in a way so not to
break (hopefully) the current DW XPCS driver users (STMMAC Eth for
sure, WangSun XGBE, SJA1105 DSA). So it will be still possible to create a
dedicated MDIO bus (using mdio-regmap API too) with the XPCS device
being detectable on it.

-Serge(y)

> 
> Maxime


From cristian.marussi at arm.com  Fri Dec  1 08:26:58 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 1 Dec 2023 16:26:58 +0000
Subject: [PATCH] firmware: arm_scmi: Add protocol versioning checks
In-Reply-To: <20231201153145.emneavw53en4hsju@bogus>
References: <20231201135858.2367651-1-cristian.marussi@arm.com>
 <20231201153145.emneavw53en4hsju@bogus>
Message-ID: <ZWoJUt8oAwyUHazv@pluto>

On Fri, Dec 01, 2023 at 03:31:45PM +0000, Sudeep Holla wrote:
> On Fri, Dec 01, 2023 at 01:58:58PM +0000, Cristian Marussi wrote:
> > Platform and agent supported protocols versions do not necessarily match.
> > 
> > When talking to an older platform SCMI server, supporting only older
> > protocol versions, the kernel SCMI agent will downgrade the version of
> > the used protocol to match the platform one and avoid compatibility issues.
> > 
> > In the case, instead, in which the agent happens to communicate with a
> > newer platform server which can support newer protocol versions unknown to
> > the agent, and potentially backward incompatible, the agent currently
> > carries on, silently, in a best-effort approach.
> > 
> > Note that the SCMI server, by the specification, has no means to explicitly
> > detect the protocol versions used by the agents, neither it is required to
> > support multiple, older, protocol versions.
> > 
> > Add an explicit protocol version check to let the agent detect when this
> > version mismatch happens and warn the user about this condition.
> > 
> > Signed-off-by: Cristian Marussi <cristian.marussi at arm.com>
> > ---
> > Any suggestion for a more meaningful warn message is very much welcome.
> 
> Looks good to me. I will apply soon with couple of changes as mentioned
> below. Let me know if you agree/disagree.
> 
> > Based on sudeep/for-next/scmi/updates
> > ---
> >  drivers/firmware/arm_scmi/base.c      |  6 +++++-
> >  drivers/firmware/arm_scmi/clock.c     |  6 +++++-
> >  drivers/firmware/arm_scmi/driver.c    | 11 ++++++++++-
> >  drivers/firmware/arm_scmi/perf.c      |  6 +++++-
> >  drivers/firmware/arm_scmi/power.c     |  6 +++++-
> >  drivers/firmware/arm_scmi/powercap.c  |  6 +++++-
> >  drivers/firmware/arm_scmi/protocols.h |  8 +++++++-
> >  drivers/firmware/arm_scmi/reset.c     |  6 +++++-
> >  drivers/firmware/arm_scmi/sensors.c   |  6 +++++-
> >  drivers/firmware/arm_scmi/system.c    |  6 +++++-
> >  drivers/firmware/arm_scmi/voltage.c   |  6 +++++-
> >  11 files changed, 62 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
> > index a52f084a6a87..3f5c89ae5af2 100644
> > --- a/drivers/firmware/arm_scmi/base.c
> > +++ b/drivers/firmware/arm_scmi/base.c
> > @@ -13,6 +13,9 @@
> >  #include "common.h"
> >  #include "notify.h"
> >  
> > +/* Must be updated only after ALL new features for that version are merged */
> 
> s/new/mandatory/
> 
> > +#define SCMI_PROTOCOL_SUPPORTED_VERSION		0x20000
> > +
> >  #define SCMI_BASE_NUM_SOURCES		1
> >  #define SCMI_BASE_MAX_CMD_ERR_COUNT	1024
> >  
> > index 3eb19ed6f148..46320f627066 100644
> > --- a/drivers/firmware/arm_scmi/driver.c
> > +++ b/drivers/firmware/arm_scmi/driver.c
> > @@ -1849,6 +1853,11 @@ scmi_alloc_init_protocol_instance(struct scmi_info *info,
> >  	devres_close_group(handle->dev, pi->gid);
> >  	dev_dbg(handle->dev, "Initialized protocol: 0x%X\n", pi->proto->id);
> >  
> > +	if (pi->version > proto->supported_version)
> > +		dev_warn(handle->dev,
> > +			 "Detected UNSUPPORTED version 0x%X for protocol 0x%X. Backward compatibility is NOT assured.\n",
> 
> s/UNSUPPORTED version/UNSUPPORTED newer version/ or higher instead of newer
> 

Much better ... I'm fine with these changes ... I was tempted to use
'higher' too, but not sure what was more effective at communicating
the issue...a panic usually does it better :P (joking ah,...)

Thanks,
Cristian


From nm at ti.com  Fri Dec  1 08:31:26 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 10:31:26 -0600
Subject: [PATCH] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <855dfa50-a3a3-415a-8612-4da59f995ef0@app.fastmail.com>
References: <20231130231657.12715-1-francesco@dolcini.it>
 <20231201060346.GE5169@atomide.com>
 <20231201064919.5mbmqo5fco7n3rgq@endnote>
 <855dfa50-a3a3-415a-8612-4da59f995ef0@app.fastmail.com>
Message-ID: <20231201163126.oaixjeo4i3gvmsyt@molar>

On 16:31-20231201, Arnd Bergmann wrote:
> On Fri, Dec 1, 2023, at 07:49, Nishanth Menon wrote:
> > On 08:03-20231201, Tony Lindgren wrote:
> >> * Francesco Dolcini <francesco at dolcini.it> [231130 23:17]:
> >> > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
> >> > is not adequate for embedded systems that use SoCs where it's common to
> >> > have a large number of serial ports.
> >> > 
> >> > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
> >> > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
> >> > 
> >> > This enables using the UART connected Bluetooth device on Verdin AM62
> >> > board.
> >> 
> >> OK makes sense for distro use.
> >> 
> >> Disabling unused ports leads into port names shifting, which we still can't
> >> easily tolerate until we have the DEVNAME:0.0 style addressing available for
> >> ports. So for now we still depend CONFIG_SERIAL_8250_NR_UARTS, eventually
> >> that too should become just a legacy ISA port array.. Meanwhile:
> >> 
> >> Reviewed-by: Tony Lindgren <tony at atomide.com>
> >
> > I'd prefer to get Arnd's view on the topic as well (I kind of
> > recollect some historic discussion which I am not failing to trace
> > that there usage model doesn't exceed 4 and aliases could be used to
> > map these as required for the platform). The 8250 debate has been
> > popping on and off over the years.. Sigh.. memories of [1] still haunt
> > me.
> 
> I don't recall any reason to have the limit set to the default
> of 4, other than possibly using excessive amounts of .data in
> vmlinux, but we have other serial port drivers that just hardcode
> a much larger value.

Thanks Arnd, we will queue this up.

Francesco: Could you respin with a more clear commit message to indicate
actual board usage instance.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:50 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:50 +0100
Subject: [RFC PATCH net-next v3 00/13] Introduce PHY listing and link_topology tracking
Message-ID: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>

Hello everyone,

Here's a V3 of the multi-PHY support series. As a remainder, this ongoing
work aims ultimately at supporting complex link topologies that involve
multiplexing multiple PHYs/SFPs on a single netdevice. As a first step,
it's required that we are able to enumerate the PHYs on a given ethernet
interface.

By just doing so, we also improve already-existing use-cases, namely the
copper SFP modules support when a media-converter is used (as we have 2
PHYs on the link, but only one is referenced by net_device.phydev, which
is used on a variety of netlink commands).

The series is architectured as follows :

- The first patch adds the notion of phy_link_topology, which tracks
all PHYs attached to a netdevice.

- Patches 2, 3 and 4 adds some plumbing into SFP and phylib to be able
  to connect the dots when building the topology tree, to know which PHY
  is connected to which SFP bus, trying not to be too invasive on phylib.

- Patch 5 allows passing a PHY_INDEX to ethnl commands. I'm uncertain about
  this, as there are at least 4 netlink commands ( 5 with the one introduced
  in patch 7 ) that targets PHYs directly or indirectly, which to me makes
  it worth-it to have a generic way to pass a PHY index to commands, however
  the approach taken may be too generic.

- Patch 6 is the netlink spec update + ethtool-user.c|h autogenerated code
update (the autogenerated code triggers checkpatch warning though)

- Patch 7 introduces a new netlink command set to list PHYs on a netdevice.
It implements a custom DUMP and GET operation to allow filtered dumps,
that lists all PHYs on a given netdevice. I couldn't use most of ethnl's
plumbing though.

- Patch 8 is the netlink spec update + ethtool-user.c|h update for that
new command

- Patch 8,9,10 and 11 updates the PLCA, strset, cable-test and pse netlink
commands to use the user-provided PHY instead of net_device.phydev.

- Finally patch 12 adds some documentation for this whole work.

Examples
========

Here's a short overview of the kind of operations you can have regarding
the PHY topology. These tests were performed on a MacchiatoBin, which
has 3 interfaces :

eth0 and eth1 have the following layout:

MAC - PHY - SFP

eth2 has this more classic topology :

MAC - PHY - RJ45

finally eth3 has the following topology :

MAC - SFP

When performing a dump with all interfaces down, we don't get any
result, as no PHY has been attached to their respective net_device :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get
None

The following output is with eth0, eth2 and eth3 up, but no SFP module
inserted in none of the interfaces :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get
[{'downstream-sfp-name': 'sfp-eth0',
  'drvname': 'mv88x3310',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 0,
  'index': 1,
  'name': 'f212a600.mdio-mii:00',
  'upstream-type': 'mac'},
 {'drvname': 'Marvell 88E1510',
  'header': {'dev-index': 4, 'dev-name': 'eth2'},
  'id': 21040593,
  'index': 1,
  'name': 'f212a200.mdio-mii:00',
  'upstream-type': 'mac'}]


And now is a dump operation with a copper SFP in the eth0 port :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get
[{'downstream-sfp-name': 'sfp-eth0',
  'drvname': 'mv88x3310',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 0,
  'index': 1,
  'name': 'f212a600.mdio-mii:00',
  'upstream-type': 'mac'},
 {'drvname': 'Marvell 88E1111',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 21040322,
  'index': 2,
  'name': 'i2c:sfp-eth0:16',
  'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'},
  'upstream-type': 'phy'},
 {'drvname': 'Marvell 88E1510',
  'header': {'dev-index': 4, 'dev-name': 'eth2'},
  'id': 21040593,
  'index': 1,
  'name': 'f212a200.mdio-mii:00',
  'upstream-type': 'mac'}]

 -- Note that this shouldn't actually work as the 88x3310 PHY doesn't allow
a 1G SFP to be connected to its SFP interface, and I don't have a 10G copper SFP,
so for the sake of the demo I applied the following modification, which
of courses gives a non-functionnal link, but the PHY attach still works,
which is what I want to demonstrate :

@@ -488,7 +488,7 @@ static int mv3310_sfp_insert(void *upstream, const struct sfp_eeprom_id *id)

        if (iface != PHY_INTERFACE_MODE_10GBASER) {
                dev_err(&phydev->mdio.dev, "incompatible SFP module inserted\n");
-               return -EINVAL;
+               //return -EINVAL;
        }
        return 0;
 }

Finally an example of the filtered DUMP operation that Jakub suggested
in V1 :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml \
# --dump phy-get --json '{"header" : {"dev-name" : "eth0"}}'

[{'downstream-sfp-name': 'sfp-eth0',
  'drvname': 'mv88x3310',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 0,
  'index': 1,
  'name': 'f212a600.mdio-mii:00',
  'upstream-type': 'mac'},
 {'drvname': 'Marvell 88E1111',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 21040322,
  'index': 2,
  'name': 'i2c:sfp-eth0:16',
  'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'},
  'upstream-type': 'phy'}]

And a classic GET operation allows querying a single PHY's info :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml \
# --do phy-get --json '{"header" : {"dev-name" : "eth0", "phy-index" : 2}}'

{'drvname': 'Marvell 88E1111',
 'header': {'dev-index': 2, 'dev-name': 'eth0'},
 'id': 21040322,
 'index': 2,
 'name': 'i2c:sfp-eth0:16',
 'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'},
 'upstream-type': 'phy'}

Changes in V3:
- Added RTNL assertions where needed
- Fixed issues in the DUMP code for PHY_GET, which crashed when running it
  twice in a row
- Added the documentation, and moved in-source docs around
- renamed link_topology to phy_link_topology

Changes in V2:
- Added the DUMP operation
- Added much more information in the reported data, to be able to reconstruct
  precisely the topology tree
- renamed phy_list to link_topology

Maxime Chevallier (13):
  net: phy: Introduce ethernet link topology representation
  net: sfp: pass the phy_device when disconnecting an sfp module's PHY
  net: phy: add helpers to handle sfp phy connect/disconnect
  net: sfp: Add helper to return the SFP bus name
  net: ethtool: Allow passing a phy index for some commands
  netlink: specs: add phy-index as a header parameter
  net: ethtool: Introduce a command to list PHYs on an interface
  netlink: specs: add ethnl PHY_GET command set
  net: ethtool: plca: Target the command to the requested PHY
  net: ethtool: pse-pd: Target the command to the requested PHY
  net: ethtool: cable-test: Target the command to the requested PHY
  net: ethtool: strset: Allow querying phy stats by index
  Documentation: networking: document phy_link_topology

 Documentation/netlink/specs/ethtool.yaml      |  68 ++
 Documentation/networking/ethtool-netlink.rst  |  51 ++
 Documentation/networking/index.rst            |   1 +
 .../networking/phy-link-topology.rst          | 121 ++++
 MAINTAINERS                                   |   2 +
 drivers/net/phy/Makefile                      |   2 +-
 drivers/net/phy/at803x.c                      |   2 +
 drivers/net/phy/marvell-88x2222.c             |   2 +
 drivers/net/phy/marvell.c                     |   2 +
 drivers/net/phy/marvell10g.c                  |   2 +
 drivers/net/phy/phy_device.c                  |  55 ++
 drivers/net/phy/phy_link_topology.c           |  85 +++
 drivers/net/phy/phylink.c                     |   3 +-
 drivers/net/phy/sfp-bus.c                     |  15 +-
 include/linux/netdevice.h                     |   4 +-
 include/linux/phy.h                           |   6 +
 include/linux/phy_link_topology.h             |  64 ++
 include/linux/phy_link_topology_core.h        |  15 +
 include/linux/sfp.h                           |   8 +-
 include/uapi/linux/ethtool.h                  |  16 +
 include/uapi/linux/ethtool_netlink.h          |  30 +
 net/core/dev.c                                |   3 +
 net/ethtool/Makefile                          |   2 +-
 net/ethtool/cabletest.c                       |  12 +-
 net/ethtool/netlink.c                         |  33 +
 net/ethtool/netlink.h                         |  12 +-
 net/ethtool/phy.c                             | 292 ++++++++
 net/ethtool/plca.c                            |  13 +-
 net/ethtool/pse-pd.c                          |  14 +-
 net/ethtool/strset.c                          |  15 +-
 tools/net/ynl/generated/ethtool-user.c        | 265 +++++++
 tools/net/ynl/generated/ethtool-user.h        | 683 ++++++++++++++++++
 32 files changed, 1858 insertions(+), 40 deletions(-)
 create mode 100644 Documentation/networking/phy-link-topology.rst
 create mode 100644 drivers/net/phy/phy_link_topology.c
 create mode 100644 include/linux/phy_link_topology.h
 create mode 100644 include/linux/phy_link_topology_core.h
 create mode 100644 net/ethtool/phy.c

-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:51 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:51 +0100
Subject: [RFC PATCH net-next v3 01/13] net: phy: Introduce ethernet link topology representation
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-2-maxime.chevallier@bootlin.com>

Link topologies containing multiple network PHYs attached to the same
net_device can be found when using a PHY as a media converter for use
with an SFP connector, on which an SFP transceiver containing a PHY can
be used.

With the current model, the transceiver's PHY can't be used for
operations such as cable testing, timestamping, macsec offload, etc.

The reason being that most of the logic for these configuration, coming
from either ethtool netlink or ioctls tend to use netdev->phydev, which
in multi-phy systems will reference the PHY closest to the MAC.

Introduce a numbering scheme allowing to enumerate PHY devices that
belong to any netdev, which can in turn allow userspace to take more
precise decisions with regard to each PHY's configuration.

The numbering is maintained per-netdev, in a phy_device_list.
The numbering works similarly to a netdevice's ifindex, with
identifiers that are only recycled once INT_MAX has been reached.

This prevents races that could occur between PHY listing and SFP
transceiver removal/insertion.

The identifiers are assigned at phy_attach time, as the numbering
depends on the netdevice the phy is attached to.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: - Renamed to phy_link_topology
    - Added assertions for RTNL
    - Various cleanups of leftover, unused test code
    - Made the PHY index u32

 MAINTAINERS                            |  2 +
 drivers/net/phy/Makefile               |  2 +-
 drivers/net/phy/phy_device.c           | 15 +++++
 drivers/net/phy/phy_link_topology.c    | 85 ++++++++++++++++++++++++++
 include/linux/netdevice.h              |  4 +-
 include/linux/phy.h                    |  4 ++
 include/linux/phy_link_topology.h      | 64 +++++++++++++++++++
 include/linux/phy_link_topology_core.h | 15 +++++
 include/uapi/linux/ethtool.h           | 16 +++++
 net/core/dev.c                         |  3 +
 10 files changed, 208 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/phy/phy_link_topology.c
 create mode 100644 include/linux/phy_link_topology.h
 create mode 100644 include/linux/phy_link_topology_core.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 509281e9e169..54d50510c299 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7922,6 +7922,8 @@ F:	include/linux/mii.h
 F:	include/linux/of_net.h
 F:	include/linux/phy.h
 F:	include/linux/phy_fixed.h
+F:	include/linux/phy_link_topology.h
+F:	include/linux/phy_link_topology_core.h
 F:	include/linux/phylib_stubs.h
 F:	include/linux/platform_data/mdio-bcm-unimac.h
 F:	include/linux/platform_data/mdio-gpio.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index f65e85c91fc1..3cf7774df57e 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -2,7 +2,7 @@
 # Makefile for Linux PHY drivers
 
 libphy-y			:= phy.o phy-c45.o phy-core.o phy_device.o \
-				   linkmode.o
+				   linkmode.o phy_link_topology.o
 mdio-bus-y			+= mdio_bus.o mdio_device.o
 
 ifdef CONFIG_MDIO_DEVICE
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 478126f6b5bc..b921a091d636 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -29,6 +29,7 @@
 #include <linux/phy.h>
 #include <linux/phylib_stubs.h>
 #include <linux/phy_led_triggers.h>
+#include <linux/phy_link_topology.h>
 #include <linux/pse-pd/pse.h>
 #include <linux/property.h>
 #include <linux/rtnetlink.h>
@@ -265,6 +266,14 @@ static void phy_mdio_device_remove(struct mdio_device *mdiodev)
 
 static struct phy_driver genphy_driver;
 
+static struct phy_link_topology *phy_get_link_topology(struct phy_device *phydev)
+{
+	if (phydev->attached_dev)
+		return &phydev->attached_dev->link_topo;
+
+	return NULL;
+}
+
 static LIST_HEAD(phy_fixup_list);
 static DEFINE_MUTEX(phy_fixup_lock);
 
@@ -1488,6 +1497,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
 
 		if (phydev->sfp_bus_attached)
 			dev->sfp_bus = phydev->sfp_bus;
+
+		err = phy_link_topo_add_phy(&dev->link_topo, phydev,
+					    PHY_UPSTREAM_MAC, dev);
+		if (err)
+			goto error;
 	}
 
 	/* Some Ethernet drivers try to connect to a PHY device before
@@ -1813,6 +1827,7 @@ void phy_detach(struct phy_device *phydev)
 	if (dev) {
 		phydev->attached_dev->phydev = NULL;
 		phydev->attached_dev = NULL;
+		phy_link_topo_del_phy(&dev->link_topo, phydev);
 	}
 	phydev->phylink = NULL;
 
diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
new file mode 100644
index 000000000000..4bb8b1eb7df6
--- /dev/null
+++ b/drivers/net/phy/phy_link_topology.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Infrastructure to handle all PHY devices connected to a given netdev,
+ * either directly or indirectly attached.
+ *
+ * Copyright (c) 2023 Maxime Chevallier<maxime.chevallier at bootlin.com>
+ */
+
+#include <linux/phy_link_topology.h>
+#include <linux/netdevice.h>
+#include <linux/phy.h>
+#include <linux/rtnetlink.h>
+#include <linux/xarray.h>
+
+struct phy_device *phy_link_topo_get_phy(struct phy_link_topology *topo,
+					 u32 phyindex)
+{
+	struct phy_device_node *pdn = xa_load(&topo->phys, phyindex);
+
+	if (pdn)
+		return pdn->phy;
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_get_phy);
+
+int phy_link_topo_add_phy(struct phy_link_topology *topo,
+			  struct phy_device *phy,
+			  enum phy_upstream upt, void *upstream)
+{
+	struct phy_device_node *pdn;
+	int ret;
+
+	/* Protects phy and upstream */
+	ASSERT_RTNL();
+
+	pdn = kzalloc(sizeof(*pdn), GFP_KERNEL);
+	if (!pdn)
+		return -ENOMEM;
+
+	pdn->phy = phy;
+	switch (upt) {
+	case PHY_UPSTREAM_MAC:
+		pdn->upstream.netdev = (struct net_device *)upstream;
+		if (phy_on_sfp(phy))
+			pdn->parent_sfp_bus = pdn->upstream.netdev->sfp_bus;
+		break;
+	case PHY_UPSTREAM_PHY:
+		pdn->upstream.phydev = (struct phy_device *)upstream;
+		if (phy_on_sfp(phy))
+			pdn->parent_sfp_bus = pdn->upstream.phydev->sfp_bus;
+		break;
+	default:
+		ret = -EINVAL;
+		goto err;
+	}
+	pdn->upstream_type = upt;
+
+	ret = xa_alloc_cyclic(&topo->phys, &phy->phyindex, pdn, xa_limit_32b,
+			      &topo->next_phy_index, GFP_KERNEL);
+	if (ret)
+		goto err;
+
+	return 0;
+
+err:
+	kfree(pdn);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_add_phy);
+
+void phy_link_topo_del_phy(struct phy_link_topology *topo,
+			   struct phy_device *phy)
+{
+	struct phy_device_node *pdn = xa_erase(&topo->phys, phy->phyindex);
+
+	kfree(pdn);
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_del_phy);
+
+void phy_link_topo_init(struct phy_link_topology *topo)
+{
+	xa_init_flags(&topo->phys, XA_FLAGS_ALLOC1);
+	topo->next_phy_index = 1;
+}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index e87caa81f70c..6ebb37375d39 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -40,7 +40,6 @@
 #include <net/dcbnl.h>
 #endif
 #include <net/netprio_cgroup.h>
-
 #include <linux/netdev_features.h>
 #include <linux/neighbour.h>
 #include <uapi/linux/netdevice.h>
@@ -52,6 +51,7 @@
 #include <net/net_trackers.h>
 #include <net/net_debug.h>
 #include <net/dropreason-core.h>
+#include <linux/phy_link_topology_core.h>
 
 struct netpoll_info;
 struct device;
@@ -2035,6 +2035,7 @@ enum netdev_stat_type {
  *	@fcoe_ddp_xid:	Max exchange id for FCoE LRO by ddp
  *
  *	@priomap:	XXX: need comments on this one
+ *	@link_topo:	Physical link topology tracking attached PHYs
  *	@phydev:	Physical device may attach itself
  *			for hardware timestamping
  *	@sfp_bus:	attached &struct sfp_bus structure.
@@ -2417,6 +2418,7 @@ struct net_device {
 #if IS_ENABLED(CONFIG_CGROUP_NET_PRIO)
 	struct netprio_map __rcu *priomap;
 #endif
+	struct phy_link_topology	link_topo;
 	struct phy_device	*phydev;
 	struct sfp_bus		*sfp_bus;
 	struct lock_class_key	*qdisc_tx_busylock;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index e5f1f41e399c..4cee9c05183f 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -543,6 +543,9 @@ struct macsec_ops;
  * @drv: Pointer to the driver for this PHY instance
  * @devlink: Create a link between phy dev and mac dev, if the external phy
  *           used by current mac interface is managed by another mac interface.
+ * @phyindex: Unique id across the phy's parent tree of phys to address the PHY
+ *	      from userspace, similar to ifindex. A zero index means the PHY
+ *	      wasn't assigned an id yet.
  * @phy_id: UID for this device found during discovery
  * @c45_ids: 802.3-c45 Device Identifiers if is_c45.
  * @is_c45:  Set to true if this PHY uses clause 45 addressing.
@@ -640,6 +643,7 @@ struct phy_device {
 
 	struct device_link *devlink;
 
+	u32 phyindex;
 	u32 phy_id;
 
 	struct phy_c45_device_ids c45_ids;
diff --git a/include/linux/phy_link_topology.h b/include/linux/phy_link_topology.h
new file mode 100644
index 000000000000..44013a3cff50
--- /dev/null
+++ b/include/linux/phy_link_topology.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * PHY device list allow maintaining a list of PHY devices that are
+ * part of a netdevice's link topology. PHYs can for example be chained,
+ * as is the case when using a PHY that exposes an SFP module, on which an
+ * SFP transceiver that embeds a PHY is connected.
+ *
+ * This list can then be used by userspace to leverage individual PHY
+ * capabilities.
+ */
+#ifndef __PHY_LINK_TOPOLOGY_H
+#define __PHY_LINK_TOPOLOGY_H
+
+#include <linux/ethtool.h>
+#include <linux/phy_link_topology_core.h>
+
+struct xarray;
+struct phy_device;
+struct net_device;
+struct sfp_bus;
+
+struct phy_device_node {
+	enum phy_upstream upstream_type;
+
+	union {
+		struct net_device	*netdev;
+		struct phy_device	*phydev;
+	} upstream;
+
+	struct sfp_bus *parent_sfp_bus;
+
+	struct phy_device *phy;
+};
+
+#if IS_ENABLED(CONFIG_PHYLIB)
+struct phy_device *phy_link_topo_get_phy(struct phy_link_topology *topo,
+					 u32 phyindex);
+int phy_link_topo_add_phy(struct phy_link_topology *topo,
+			  struct phy_device *phy,
+			  enum phy_upstream upt, void *upstream);
+
+void phy_link_topo_del_phy(struct phy_link_topology *lt, struct phy_device *phy);
+
+#else
+static struct phy_device *phy_link_topo_get_phy(struct phy_link_topology *topo,
+						u32 phyindex)
+{
+	return NULL;
+}
+
+static int phy_link_topo_add_phy(struct phy_link_topology *topo,
+				 struct phy_device *phy,
+				 enum phy_upstream upt, void *upstream)
+{
+	return 0;
+}
+
+static void phy_link_topo_del_phy(struct phy_link_topology *topo,
+				  struct phy_device *phy)
+{
+}
+#endif
+
+#endif /* __PHY_LINK_TOPOLOGY_H */
diff --git a/include/linux/phy_link_topology_core.h b/include/linux/phy_link_topology_core.h
new file mode 100644
index 000000000000..7aee9718d305
--- /dev/null
+++ b/include/linux/phy_link_topology_core.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PHY_LINK_TOPOLOGY_CORE_H
+#define __PHY_LINK_TOPOLOGY_CORE_H
+
+struct xarray;
+
+struct phy_link_topology {
+	struct xarray phys;
+
+	u32 next_phy_index;
+};
+
+void phy_link_topo_init(struct phy_link_topology *topo);
+
+#endif /* __PHY_LINK_TOPOLOGY_CORE_H */
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index f7fba0dc87e5..f3a8b582b8d4 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -2205,4 +2205,20 @@ struct ethtool_link_settings {
 	 * __u32 map_lp_advertising[link_mode_masks_nwords];
 	 */
 };
+
+/**
+ * enum phy_upstream - Represents the upstream component a given PHY device
+ * is connected to, as in what is on the other end of the MII bus. Most PHYs
+ * will be attached to an Ethernet MAC controller, but in some cases, there's
+ * an intermediate PHY used as a media-converter, which will driver another
+ * MII interface as its output.
+ * @PHY_UPSTREAM_MAC: Upstream component is a MAC (a switch port,
+ *		      or ethernet controller)
+ * @PHY_UPSTREAM_PHY: Upstream component is a PHY (likely a media converter)
+ */
+enum phy_upstream {
+	PHY_UPSTREAM_MAC,
+	PHY_UPSTREAM_PHY,
+};
+
 #endif /* _UAPI_LINUX_ETHTOOL_H */
diff --git a/net/core/dev.c b/net/core/dev.c
index 3950ced396b5..64b0fda64033 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -153,6 +153,7 @@
 #include <linux/prandom.h>
 #include <linux/once_lite.h>
 #include <net/netdev_rx_queue.h>
+#include <linux/phy_link_topology_core.h>
 
 #include "dev.h"
 #include "net-sysfs.h"
@@ -10832,6 +10833,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
 #ifdef CONFIG_NET_SCHED
 	hash_init(dev->qdisc_hash);
 #endif
+	phy_link_topo_init(&dev->link_topo);
+
 	dev->priv_flags = IFF_XMIT_DST_RELEASE | IFF_XMIT_DST_RELEASE_PERM;
 	setup(dev);
 
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:52 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:52 +0100
Subject: [RFC PATCH net-next v3 02/13] net: sfp: pass the phy_device when disconnecting an sfp module's PHY
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-3-maxime.chevallier@bootlin.com>

Pass the phy_device as a parameter to the sfp upstream .disconnect_phy
operation. This is preparatory work to help track phy devices across
a net_device's link.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: No changes

 drivers/net/phy/phylink.c | 3 ++-
 drivers/net/phy/sfp-bus.c | 4 ++--
 include/linux/sfp.h       | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index c276f9482f78..788785335fca 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -3309,7 +3309,8 @@ static int phylink_sfp_connect_phy(void *upstream, struct phy_device *phy)
 	return ret;
 }
 
-static void phylink_sfp_disconnect_phy(void *upstream)
+static void phylink_sfp_disconnect_phy(void *upstream,
+				       struct phy_device *phydev)
 {
 	phylink_disconnect_phy(upstream);
 }
diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 6fa679b36290..3a86c41e1235 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -486,7 +486,7 @@ static void sfp_unregister_bus(struct sfp_bus *bus)
 			bus->socket_ops->stop(bus->sfp);
 		bus->socket_ops->detach(bus->sfp);
 		if (bus->phydev && ops && ops->disconnect_phy)
-			ops->disconnect_phy(bus->upstream);
+			ops->disconnect_phy(bus->upstream, bus->phydev);
 	}
 	bus->registered = false;
 }
@@ -742,7 +742,7 @@ void sfp_remove_phy(struct sfp_bus *bus)
 	const struct sfp_upstream_ops *ops = sfp_get_upstream_ops(bus);
 
 	if (ops && ops->disconnect_phy)
-		ops->disconnect_phy(bus->upstream);
+		ops->disconnect_phy(bus->upstream, bus->phydev);
 	bus->phydev = NULL;
 }
 EXPORT_SYMBOL_GPL(sfp_remove_phy);
diff --git a/include/linux/sfp.h b/include/linux/sfp.h
index 9346cd44814d..0573e53b0c11 100644
--- a/include/linux/sfp.h
+++ b/include/linux/sfp.h
@@ -544,7 +544,7 @@ struct sfp_upstream_ops {
 	void (*link_down)(void *priv);
 	void (*link_up)(void *priv);
 	int (*connect_phy)(void *priv, struct phy_device *);
-	void (*disconnect_phy)(void *priv);
+	void (*disconnect_phy)(void *priv, struct phy_device *);
 };
 
 #if IS_ENABLED(CONFIG_SFP)
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:53 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:53 +0100
Subject: [RFC PATCH net-next v3 03/13] net: phy: add helpers to handle sfp phy connect/disconnect
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-4-maxime.chevallier@bootlin.com>

There are a few PHY drivers that can handle SFP modules through their
sfp_upstream_ops. Introduce Phylib helpers to keep track of connected
SFP PHYs in a netdevice's namespace, by adding the SFP PHY to the
upstream PHY's netdev's namespace.

By doing so, these SFP PHYs can be enumerated and exposed to users,
which will be able to use their capabilities.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: Renaming
V2: Renaming

 drivers/net/phy/at803x.c          |  2 ++
 drivers/net/phy/marvell-88x2222.c |  2 ++
 drivers/net/phy/marvell.c         |  2 ++
 drivers/net/phy/marvell10g.c      |  2 ++
 drivers/net/phy/phy_device.c      | 40 +++++++++++++++++++++++++++++++
 include/linux/phy.h               |  2 ++
 6 files changed, 50 insertions(+)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 37fb033e1c29..9b1659b03aa5 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -730,6 +730,8 @@ static const struct sfp_upstream_ops at803x_sfp_ops = {
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
 	.module_insert = at803x_sfp_insert,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 };
 
 static int at803x_parse_dt(struct phy_device *phydev)
diff --git a/drivers/net/phy/marvell-88x2222.c b/drivers/net/phy/marvell-88x2222.c
index e3aa30dad2e6..3f77bbc7e04f 100644
--- a/drivers/net/phy/marvell-88x2222.c
+++ b/drivers/net/phy/marvell-88x2222.c
@@ -555,6 +555,8 @@ static const struct sfp_upstream_ops sfp_phy_ops = {
 	.link_down = mv2222_sfp_link_down,
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 };
 
 static int mv2222_probe(struct phy_device *phydev)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index eba652a4c1d8..674e29bce2cc 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -3254,6 +3254,8 @@ static const struct sfp_upstream_ops m88e1510_sfp_ops = {
 	.module_remove = m88e1510_sfp_remove,
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 };
 
 static int m88e1510_probe(struct phy_device *phydev)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index d4bb90d76881..a88ebc0a6be5 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -496,6 +496,8 @@ static int mv3310_sfp_insert(void *upstream, const struct sfp_eeprom_id *id)
 static const struct sfp_upstream_ops mv3310_sfp_ops = {
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 	.module_insert = mv3310_sfp_insert,
 };
 
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index b921a091d636..675b9afdc66c 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1360,6 +1360,46 @@ phy_standalone_show(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RO(phy_standalone);
 
+/**
+ * phy_sfp_connect_phy - Connect the SFP module's PHY to the upstream PHY
+ * @upstream: pointer to the upstream phy device
+ * @phy: pointer to the SFP module's phy device
+ *
+ * This helper allows keeping track of PHY devices on the link. It adds the
+ * SFP module's phy to the phy namespace of the upstream phy
+ */
+int phy_sfp_connect_phy(void *upstream, struct phy_device *phy)
+{
+	struct phy_device *phydev = upstream;
+	struct phy_link_topology *topo = phy_get_link_topology(phydev);
+
+	if (topo)
+		return phy_link_topo_add_phy(topo, phy, PHY_UPSTREAM_PHY, phydev);
+
+	return 0;
+}
+EXPORT_SYMBOL(phy_sfp_connect_phy);
+
+/**
+ * phy_sfp_disconnect_phy - Disconnect the SFP module's PHY from the upstream PHY
+ * @upstream: pointer to the upstream phy device
+ * @phy: pointer to the SFP module's phy device
+ *
+ * This helper allows keeping track of PHY devices on the link. It removes the
+ * SFP module's phy to the phy namespace of the upstream phy. As the module phy
+ * will be destroyed, re-inserting the same module will add a new phy with a
+ * new index.
+ */
+void phy_sfp_disconnect_phy(void *upstream, struct phy_device *phy)
+{
+	struct phy_device *phydev = upstream;
+	struct phy_link_topology *topo = phy_get_link_topology(phydev);
+
+	if (topo)
+		phy_link_topo_del_phy(topo, phy);
+}
+EXPORT_SYMBOL(phy_sfp_disconnect_phy);
+
 /**
  * phy_sfp_attach - attach the SFP bus to the PHY upstream network device
  * @upstream: pointer to the phy device
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 4cee9c05183f..d1fe51e8ba93 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1722,6 +1722,8 @@ int phy_suspend(struct phy_device *phydev);
 int phy_resume(struct phy_device *phydev);
 int __phy_resume(struct phy_device *phydev);
 int phy_loopback(struct phy_device *phydev, bool enable);
+int phy_sfp_connect_phy(void *upstream, struct phy_device *phy);
+void phy_sfp_disconnect_phy(void *upstream, struct phy_device *phy);
 void phy_sfp_attach(void *upstream, struct sfp_bus *bus);
 void phy_sfp_detach(void *upstream, struct sfp_bus *bus);
 int phy_sfp_probe(struct phy_device *phydev,
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:54 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:54 +0100
Subject: [RFC PATCH net-next v3 04/13] net: sfp: Add helper to return the SFP bus name
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-5-maxime.chevallier@bootlin.com>

Knowing the bus name is helpful when we want to expose the link topology
to userspace, add a helper to return the SFP bus name.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: - Added RTNL assert
    - Made the stub inline
V2: New patch

 drivers/net/phy/sfp-bus.c | 11 +++++++++++
 include/linux/sfp.h       |  6 ++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 3a86c41e1235..fb1c102714b5 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -859,3 +859,14 @@ void sfp_unregister_socket(struct sfp_bus *bus)
 	sfp_bus_put(bus);
 }
 EXPORT_SYMBOL_GPL(sfp_unregister_socket);
+
+const char *sfp_get_name(struct sfp_bus *bus)
+{
+	ASSERT_RTNL();
+
+	if (bus->sfp_dev)
+		return dev_name(bus->sfp_dev);
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(sfp_get_name);
diff --git a/include/linux/sfp.h b/include/linux/sfp.h
index 0573e53b0c11..55c0ab17c9e2 100644
--- a/include/linux/sfp.h
+++ b/include/linux/sfp.h
@@ -570,6 +570,7 @@ struct sfp_bus *sfp_bus_find_fwnode(const struct fwnode_handle *fwnode);
 int sfp_bus_add_upstream(struct sfp_bus *bus, void *upstream,
 			 const struct sfp_upstream_ops *ops);
 void sfp_bus_del_upstream(struct sfp_bus *bus);
+const char *sfp_get_name(struct sfp_bus *bus);
 #else
 static inline int sfp_parse_port(struct sfp_bus *bus,
 				 const struct sfp_eeprom_id *id,
@@ -648,6 +649,11 @@ static inline int sfp_bus_add_upstream(struct sfp_bus *bus, void *upstream,
 static inline void sfp_bus_del_upstream(struct sfp_bus *bus)
 {
 }
+
+static inline const char *sfp_get_name(struct sfp_bus *bus)
+{
+	return NULL;
+}
 #endif
 
 #endif
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:55 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:55 +0100
Subject: [RFC PATCH net-next v3 05/13] net: ethtool: Allow passing a phy index for some commands
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-6-maxime.chevallier@bootlin.com>

Some netlink commands are target towards ethernet PHYs, to control some
of their features. As there's several such commands, add the ability to
pass a PHY index in the ethnl request, which will populate the generic
ethnl_req_info with the relevant phydev when the command targets a PHY.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: - Fixed the documentation
V2: - New patch

 Documentation/networking/ethtool-netlink.rst |  7 ++++++
 include/uapi/linux/ethtool_netlink.h         |  1 +
 net/ethtool/netlink.c                        | 24 ++++++++++++++++++++
 net/ethtool/netlink.h                        |  7 ++++--
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index 2540c70952ff..8f6390a85895 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst
@@ -57,6 +57,7 @@ Structure of this header is
   ``ETHTOOL_A_HEADER_DEV_INDEX``  u32     device ifindex
   ``ETHTOOL_A_HEADER_DEV_NAME``   string  device name
   ``ETHTOOL_A_HEADER_FLAGS``      u32     flags common for all requests
+  ``ETHTOOL_A_HEADER_PHY_INDEX``  u32     phy device index
   ==============================  ======  =============================
 
 ``ETHTOOL_A_HEADER_DEV_INDEX`` and ``ETHTOOL_A_HEADER_DEV_NAME`` identify the
@@ -81,6 +82,12 @@ the behaviour is backward compatible, i.e. requests from old clients not aware
 of the flag should be interpreted the way the client expects. A client must
 not set flags it does not understand.
 
+``ETHTOOL_A_HEADER_PHY_INDEX`` identify the ethernet PHY the message relates to.
+As there are numerous commands that are related to PHY configuration, and because
+we can have more than one PHY on the link, the PHY index can be passed in the
+request for the commands that needs it. It is however not mandatory, and if it
+is not passed for commands that target a PHY, the net_device.phydev pointer
+is used, as a fallback that keeps the legacy behaviour.
 
 Bit sets
 ========
diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h
index 73e2c10dc2cc..e557cf35250e 100644
--- a/include/uapi/linux/ethtool_netlink.h
+++ b/include/uapi/linux/ethtool_netlink.h
@@ -133,6 +133,7 @@ enum {
 	ETHTOOL_A_HEADER_DEV_INDEX,		/* u32 */
 	ETHTOOL_A_HEADER_DEV_NAME,		/* string */
 	ETHTOOL_A_HEADER_FLAGS,			/* u32 - ETHTOOL_FLAG_* */
+	ETHTOOL_A_HEADER_PHY_INDEX,		/* u32 */
 
 	/* add new constants above here */
 	__ETHTOOL_A_HEADER_CNT,
diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
index 3bbd5afb7b31..b8faab3a92e8 100644
--- a/net/ethtool/netlink.c
+++ b/net/ethtool/netlink.c
@@ -4,6 +4,7 @@
 #include <linux/ethtool_netlink.h>
 #include <linux/pm_runtime.h>
 #include "netlink.h"
+#include <linux/phy_link_topology.h>
 
 static struct genl_family ethtool_genl_family;
 
@@ -20,6 +21,7 @@ const struct nla_policy ethnl_header_policy[] = {
 					    .len = ALTIFNAMSIZ - 1 },
 	[ETHTOOL_A_HEADER_FLAGS]	= NLA_POLICY_MASK(NLA_U32,
 							  ETHTOOL_FLAGS_BASIC),
+	[ETHTOOL_A_HEADER_PHY_INDEX]		= NLA_POLICY_MIN(NLA_U32, 1),
 };
 
 const struct nla_policy ethnl_header_policy_stats[] = {
@@ -28,6 +30,7 @@ const struct nla_policy ethnl_header_policy_stats[] = {
 					    .len = ALTIFNAMSIZ - 1 },
 	[ETHTOOL_A_HEADER_FLAGS]	= NLA_POLICY_MASK(NLA_U32,
 							  ETHTOOL_FLAGS_STATS),
+	[ETHTOOL_A_HEADER_PHY_INDEX]		= NLA_POLICY_MIN(NLA_U32, 1),
 };
 
 int ethnl_ops_begin(struct net_device *dev)
@@ -91,6 +94,7 @@ int ethnl_parse_header_dev_get(struct ethnl_req_info *req_info,
 {
 	struct nlattr *tb[ARRAY_SIZE(ethnl_header_policy)];
 	const struct nlattr *devname_attr;
+	struct phy_device *phydev = NULL;
 	struct net_device *dev = NULL;
 	u32 flags = 0;
 	int ret;
@@ -145,6 +149,26 @@ int ethnl_parse_header_dev_get(struct ethnl_req_info *req_info,
 		return -EINVAL;
 	}
 
+	if (dev) {
+		if (tb[ETHTOOL_A_HEADER_PHY_INDEX]) {
+			u32 phy_index = nla_get_u32(tb[ETHTOOL_A_HEADER_PHY_INDEX]);
+
+			phydev = phy_link_topo_get_phy(&dev->link_topo,
+						       phy_index);
+			if (!phydev) {
+				NL_SET_ERR_MSG_ATTR(extack, header,
+						    "no phy matches phy index");
+				return -EINVAL;
+			}
+		} else {
+			/* If we need a PHY but no phy index is specified, fallback
+			 * to dev->phydev
+			 */
+			phydev = dev->phydev;
+		}
+	}
+
+	req_info->phydev = phydev;
 	req_info->dev = dev;
 	req_info->flags = flags;
 	return 0;
diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h
index 9a333a8d04c1..def84e2def9e 100644
--- a/net/ethtool/netlink.h
+++ b/net/ethtool/netlink.h
@@ -250,6 +250,7 @@ static inline unsigned int ethnl_reply_header_size(void)
  * @dev:   network device the request is for (may be null)
  * @dev_tracker: refcount tracker for @dev reference
  * @flags: request flags common for all request types
+ * @phydev: phy_device connected to @dev this request is for (may be null)
  *
  * This is a common base for request specific structures holding data from
  * parsed userspace request. These always embed struct ethnl_req_info at
@@ -259,6 +260,7 @@ struct ethnl_req_info {
 	struct net_device	*dev;
 	netdevice_tracker	dev_tracker;
 	u32			flags;
+	struct phy_device	*phydev;
 };
 
 static inline void ethnl_parse_header_dev_put(struct ethnl_req_info *req_info)
@@ -395,9 +397,10 @@ extern const struct ethnl_request_ops ethnl_rss_request_ops;
 extern const struct ethnl_request_ops ethnl_plca_cfg_request_ops;
 extern const struct ethnl_request_ops ethnl_plca_status_request_ops;
 extern const struct ethnl_request_ops ethnl_mm_request_ops;
+extern const struct ethnl_request_ops ethnl_phy_request_ops;
 
-extern const struct nla_policy ethnl_header_policy[ETHTOOL_A_HEADER_FLAGS + 1];
-extern const struct nla_policy ethnl_header_policy_stats[ETHTOOL_A_HEADER_FLAGS + 1];
+extern const struct nla_policy ethnl_header_policy[ETHTOOL_A_HEADER_PHY_INDEX + 1];
+extern const struct nla_policy ethnl_header_policy_stats[ETHTOOL_A_HEADER_PHY_INDEX + 1];
 extern const struct nla_policy ethnl_strset_get_policy[ETHTOOL_A_STRSET_COUNTS_ONLY + 1];
 extern const struct nla_policy ethnl_linkinfo_get_policy[ETHTOOL_A_LINKINFO_HEADER + 1];
 extern const struct nla_policy ethnl_linkinfo_set_policy[ETHTOOL_A_LINKINFO_TP_MDIX_CTRL + 1];
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:56 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:56 +0100
Subject: [RFC PATCH net-next v3 06/13] netlink: specs: add phy-index as a header parameter
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-7-maxime.chevallier@bootlin.com>

Update the spec to take the newly introduced phy-index as a generic
request parameter, and bump the generated ethtool-user.c|h accordingly.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: New patch

 Documentation/netlink/specs/ethtool.yaml |   3 +
 tools/net/ynl/generated/ethtool-user.c   |   8 +
 tools/net/ynl/generated/ethtool-user.h   | 530 +++++++++++++++++++++++
 3 files changed, 541 insertions(+)

diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 5c7a65b009b4..4e0790648913 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -30,6 +30,9 @@ attribute-sets:
       -
         name: flags
         type: u32
+      -
+        name: phy-index
+        type: u32
 
   -
     name: bitset-bit
diff --git a/tools/net/ynl/generated/ethtool-user.c b/tools/net/ynl/generated/ethtool-user.c
index 74b883a14958..295661eb3a3e 100644
--- a/tools/net/ynl/generated/ethtool-user.c
+++ b/tools/net/ynl/generated/ethtool-user.c
@@ -96,6 +96,7 @@ struct ynl_policy_attr ethtool_header_policy[ETHTOOL_A_HEADER_MAX + 1] = {
 	[ETHTOOL_A_HEADER_DEV_INDEX] = { .name = "dev-index", .type = YNL_PT_U32, },
 	[ETHTOOL_A_HEADER_DEV_NAME] = { .name = "dev-name", .type = YNL_PT_NUL_STR, },
 	[ETHTOOL_A_HEADER_FLAGS] = { .name = "flags", .type = YNL_PT_U32, },
+	[ETHTOOL_A_HEADER_PHY_INDEX] = { .name = "phy-index", .type = YNL_PT_U32, },
 };
 
 struct ynl_policy_nest ethtool_header_nest = {
@@ -684,6 +685,8 @@ int ethtool_header_put(struct nlmsghdr *nlh, unsigned int attr_type,
 		mnl_attr_put_strz(nlh, ETHTOOL_A_HEADER_DEV_NAME, obj->dev_name);
 	if (obj->_present.flags)
 		mnl_attr_put_u32(nlh, ETHTOOL_A_HEADER_FLAGS, obj->flags);
+	if (obj->_present.phy_index)
+		mnl_attr_put_u32(nlh, ETHTOOL_A_HEADER_PHY_INDEX, obj->phy_index);
 	mnl_attr_nest_end(nlh, nest);
 
 	return 0;
@@ -719,6 +722,11 @@ int ethtool_header_parse(struct ynl_parse_arg *yarg,
 				return MNL_CB_ERROR;
 			dst->_present.flags = 1;
 			dst->flags = mnl_attr_get_u32(attr);
+		} else if (type == ETHTOOL_A_HEADER_PHY_INDEX) {
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+			dst->_present.phy_index = 1;
+			dst->phy_index = mnl_attr_get_u32(attr);
 		}
 	}
 
diff --git a/tools/net/ynl/generated/ethtool-user.h b/tools/net/ynl/generated/ethtool-user.h
index ca0ec5fd7798..97c079c0f332 100644
--- a/tools/net/ynl/generated/ethtool-user.h
+++ b/tools/net/ynl/generated/ethtool-user.h
@@ -27,11 +27,13 @@ struct ethtool_header {
 		__u32 dev_index:1;
 		__u32 dev_name_len;
 		__u32 flags:1;
+		__u32 phy_index:1;
 	} _present;
 
 	__u32 dev_index;
 	char *dev_name;
 	__u32 flags;
+	__u32 phy_index;
 };
 
 struct ethtool_pause_stat {
@@ -253,6 +255,14 @@ ethtool_strset_get_req_set_header_flags(struct ethtool_strset_get_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_strset_get_req_set_header_phy_index(struct ethtool_strset_get_req *req,
+					    __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 __ethtool_strset_get_req_set_stringsets_stringset(struct ethtool_strset_get_req *req,
 						  struct ethtool_stringset_ *stringset,
 						  unsigned int n_stringset)
@@ -331,6 +341,14 @@ ethtool_strset_get_req_dump_set_header_flags(struct ethtool_strset_get_req_dump
 	req->header.flags = flags;
 }
 static inline void
+ethtool_strset_get_req_dump_set_header_phy_index(struct ethtool_strset_get_req_dump *req,
+						 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 __ethtool_strset_get_req_dump_set_stringsets_stringset(struct ethtool_strset_get_req_dump *req,
 						       struct ethtool_stringset_ *stringset,
 						       unsigned int n_stringset)
@@ -399,6 +417,14 @@ ethtool_linkinfo_get_req_set_header_flags(struct ethtool_linkinfo_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_linkinfo_get_req_set_header_phy_index(struct ethtool_linkinfo_get_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_linkinfo_get_rsp {
 	struct {
@@ -469,6 +495,14 @@ ethtool_linkinfo_get_req_dump_set_header_flags(struct ethtool_linkinfo_get_req_d
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_linkinfo_get_req_dump_set_header_phy_index(struct ethtool_linkinfo_get_req_dump *req,
+						   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_linkinfo_get_list {
 	struct ethtool_linkinfo_get_list *next;
@@ -546,6 +580,14 @@ ethtool_linkinfo_set_req_set_header_flags(struct ethtool_linkinfo_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_linkinfo_set_req_set_header_phy_index(struct ethtool_linkinfo_set_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_linkinfo_set_req_set_port(struct ethtool_linkinfo_set_req *req,
 				  __u8 port)
 {
@@ -630,6 +672,14 @@ ethtool_linkmodes_get_req_set_header_flags(struct ethtool_linkmodes_get_req *req
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_linkmodes_get_req_set_header_phy_index(struct ethtool_linkmodes_get_req *req,
+					       __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_linkmodes_get_rsp {
 	struct {
@@ -709,6 +759,14 @@ ethtool_linkmodes_get_req_dump_set_header_flags(struct ethtool_linkmodes_get_req
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_linkmodes_get_req_dump_set_header_phy_index(struct ethtool_linkmodes_get_req_dump *req,
+						    __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_linkmodes_get_list {
 	struct ethtool_linkmodes_get_list *next;
@@ -794,6 +852,14 @@ ethtool_linkmodes_set_req_set_header_flags(struct ethtool_linkmodes_set_req *req
 	req->header.flags = flags;
 }
 static inline void
+ethtool_linkmodes_set_req_set_header_phy_index(struct ethtool_linkmodes_set_req *req,
+					       __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_linkmodes_set_req_set_autoneg(struct ethtool_linkmodes_set_req *req,
 				      __u8 autoneg)
 {
@@ -938,6 +1004,14 @@ ethtool_linkstate_get_req_set_header_flags(struct ethtool_linkstate_get_req *req
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_linkstate_get_req_set_header_phy_index(struct ethtool_linkstate_get_req *req,
+					       __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_linkstate_get_rsp {
 	struct {
@@ -1011,6 +1085,14 @@ ethtool_linkstate_get_req_dump_set_header_flags(struct ethtool_linkstate_get_req
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_linkstate_get_req_dump_set_header_phy_index(struct ethtool_linkstate_get_req_dump *req,
+						    __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_linkstate_get_list {
 	struct ethtool_linkstate_get_list *next;
@@ -1065,6 +1147,14 @@ ethtool_debug_get_req_set_header_flags(struct ethtool_debug_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_debug_get_req_set_header_phy_index(struct ethtool_debug_get_req *req,
+					   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_debug_get_rsp {
 	struct {
@@ -1126,6 +1216,14 @@ ethtool_debug_get_req_dump_set_header_flags(struct ethtool_debug_get_req_dump *r
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_debug_get_req_dump_set_header_phy_index(struct ethtool_debug_get_req_dump *req,
+						__u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_debug_get_list {
 	struct ethtool_debug_get_list *next;
@@ -1194,6 +1292,14 @@ ethtool_debug_set_req_set_header_flags(struct ethtool_debug_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_debug_set_req_set_header_phy_index(struct ethtool_debug_set_req *req,
+					   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_debug_set_req_set_msgmask_nomask(struct ethtool_debug_set_req *req)
 {
 	req->_present.msgmask = 1;
@@ -1264,6 +1370,14 @@ ethtool_wol_get_req_set_header_flags(struct ethtool_wol_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_wol_get_req_set_header_phy_index(struct ethtool_wol_get_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_wol_get_rsp {
 	struct {
@@ -1327,6 +1441,14 @@ ethtool_wol_get_req_dump_set_header_flags(struct ethtool_wol_get_req_dump *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_wol_get_req_dump_set_header_phy_index(struct ethtool_wol_get_req_dump *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_wol_get_list {
 	struct ethtool_wol_get_list *next;
@@ -1396,6 +1518,14 @@ ethtool_wol_set_req_set_header_flags(struct ethtool_wol_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_wol_set_req_set_header_phy_index(struct ethtool_wol_set_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_wol_set_req_set_modes_nomask(struct ethtool_wol_set_req *req)
 {
 	req->_present.modes = 1;
@@ -1475,6 +1605,14 @@ ethtool_features_get_req_set_header_flags(struct ethtool_features_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_features_get_req_set_header_phy_index(struct ethtool_features_get_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_features_get_rsp {
 	struct {
@@ -1543,6 +1681,14 @@ ethtool_features_get_req_dump_set_header_flags(struct ethtool_features_get_req_d
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_features_get_req_dump_set_header_phy_index(struct ethtool_features_get_req_dump *req,
+						   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_features_get_list {
 	struct ethtool_features_get_list *next;
@@ -1618,6 +1764,14 @@ ethtool_features_set_req_set_header_flags(struct ethtool_features_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_features_set_req_set_header_phy_index(struct ethtool_features_set_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_features_set_req_set_hw_nomask(struct ethtool_features_set_req *req)
 {
 	req->_present.hw = 1;
@@ -1777,6 +1931,14 @@ ethtool_privflags_get_req_set_header_flags(struct ethtool_privflags_get_req *req
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_privflags_get_req_set_header_phy_index(struct ethtool_privflags_get_req *req,
+					       __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_privflags_get_rsp {
 	struct {
@@ -1840,6 +2002,14 @@ ethtool_privflags_get_req_dump_set_header_flags(struct ethtool_privflags_get_req
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_privflags_get_req_dump_set_header_phy_index(struct ethtool_privflags_get_req_dump *req,
+						    __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_privflags_get_list {
 	struct ethtool_privflags_get_list *next;
@@ -1909,6 +2079,14 @@ ethtool_privflags_set_req_set_header_flags(struct ethtool_privflags_set_req *req
 	req->header.flags = flags;
 }
 static inline void
+ethtool_privflags_set_req_set_header_phy_index(struct ethtool_privflags_set_req *req,
+					       __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_privflags_set_req_set_flags_nomask(struct ethtool_privflags_set_req *req)
 {
 	req->_present.flags = 1;
@@ -1980,6 +2158,14 @@ ethtool_rings_get_req_set_header_flags(struct ethtool_rings_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_rings_get_req_set_header_phy_index(struct ethtool_rings_get_req *req,
+					   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_rings_get_rsp {
 	struct {
@@ -2069,6 +2255,14 @@ ethtool_rings_get_req_dump_set_header_flags(struct ethtool_rings_get_req_dump *r
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_rings_get_req_dump_set_header_phy_index(struct ethtool_rings_get_req_dump *req,
+						__u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_rings_get_list {
 	struct ethtool_rings_get_list *next;
@@ -2165,6 +2359,14 @@ ethtool_rings_set_req_set_header_flags(struct ethtool_rings_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_rings_set_req_set_header_phy_index(struct ethtool_rings_set_req *req,
+					   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_rings_set_req_set_rx_max(struct ethtool_rings_set_req *req,
 				 __u32 rx_max)
 {
@@ -2316,6 +2518,14 @@ ethtool_channels_get_req_set_header_flags(struct ethtool_channels_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_channels_get_req_set_header_phy_index(struct ethtool_channels_get_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_channels_get_rsp {
 	struct {
@@ -2392,6 +2602,14 @@ ethtool_channels_get_req_dump_set_header_flags(struct ethtool_channels_get_req_d
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_channels_get_req_dump_set_header_phy_index(struct ethtool_channels_get_req_dump *req,
+						   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_channels_get_list {
 	struct ethtool_channels_get_list *next;
@@ -2475,6 +2693,14 @@ ethtool_channels_set_req_set_header_flags(struct ethtool_channels_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_channels_set_req_set_header_phy_index(struct ethtool_channels_set_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_channels_set_req_set_rx_max(struct ethtool_channels_set_req *req,
 				    __u32 rx_max)
 {
@@ -2580,6 +2806,14 @@ ethtool_coalesce_get_req_set_header_flags(struct ethtool_coalesce_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_coalesce_get_req_set_header_phy_index(struct ethtool_coalesce_get_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_coalesce_get_rsp {
 	struct {
@@ -2694,6 +2928,14 @@ ethtool_coalesce_get_req_dump_set_header_flags(struct ethtool_coalesce_get_req_d
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_coalesce_get_req_dump_set_header_phy_index(struct ethtool_coalesce_get_req_dump *req,
+						   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_coalesce_get_list {
 	struct ethtool_coalesce_get_list *next;
@@ -2815,6 +3057,14 @@ ethtool_coalesce_set_req_set_header_flags(struct ethtool_coalesce_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_coalesce_set_req_set_header_phy_index(struct ethtool_coalesce_set_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_coalesce_set_req_set_rx_usecs(struct ethtool_coalesce_set_req *req,
 				      __u32 rx_usecs)
 {
@@ -3052,6 +3302,14 @@ ethtool_pause_get_req_set_header_flags(struct ethtool_pause_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_pause_get_req_set_header_phy_index(struct ethtool_pause_get_req *req,
+					   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_pause_get_rsp {
 	struct {
@@ -3121,6 +3379,14 @@ ethtool_pause_get_req_dump_set_header_flags(struct ethtool_pause_get_req_dump *r
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_pause_get_req_dump_set_header_phy_index(struct ethtool_pause_get_req_dump *req,
+						__u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_pause_get_list {
 	struct ethtool_pause_get_list *next;
@@ -3197,6 +3463,14 @@ ethtool_pause_set_req_set_header_flags(struct ethtool_pause_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_pause_set_req_set_header_phy_index(struct ethtool_pause_set_req *req,
+					   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_pause_set_req_set_autoneg(struct ethtool_pause_set_req *req,
 				  __u8 autoneg)
 {
@@ -3286,6 +3560,14 @@ ethtool_eee_get_req_set_header_flags(struct ethtool_eee_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_eee_get_req_set_header_phy_index(struct ethtool_eee_get_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_eee_get_rsp {
 	struct {
@@ -3357,6 +3639,14 @@ ethtool_eee_get_req_dump_set_header_flags(struct ethtool_eee_get_req_dump *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_eee_get_req_dump_set_header_phy_index(struct ethtool_eee_get_req_dump *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_eee_get_list {
 	struct ethtool_eee_get_list *next;
@@ -3434,6 +3724,14 @@ ethtool_eee_set_req_set_header_flags(struct ethtool_eee_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_eee_set_req_set_header_phy_index(struct ethtool_eee_set_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_eee_set_req_set_modes_ours_nomask(struct ethtool_eee_set_req *req)
 {
 	req->_present.modes_ours = 1;
@@ -3553,6 +3851,14 @@ ethtool_tsinfo_get_req_set_header_flags(struct ethtool_tsinfo_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_tsinfo_get_req_set_header_phy_index(struct ethtool_tsinfo_get_req *req,
+					    __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_tsinfo_get_rsp {
 	struct {
@@ -3620,6 +3926,14 @@ ethtool_tsinfo_get_req_dump_set_header_flags(struct ethtool_tsinfo_get_req_dump
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_tsinfo_get_req_dump_set_header_phy_index(struct ethtool_tsinfo_get_req_dump *req,
+						 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_tsinfo_get_list {
 	struct ethtool_tsinfo_get_list *next;
@@ -3675,6 +3989,14 @@ ethtool_cable_test_act_req_set_header_flags(struct ethtool_cable_test_act_req *r
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_cable_test_act_req_set_header_phy_index(struct ethtool_cable_test_act_req *req,
+						__u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 /*
  * Cable test.
@@ -3726,6 +4048,14 @@ ethtool_cable_test_tdr_act_req_set_header_flags(struct ethtool_cable_test_tdr_ac
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_cable_test_tdr_act_req_set_header_phy_index(struct ethtool_cable_test_tdr_act_req *req,
+						    __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 /*
  * Cable test TDR.
@@ -3776,6 +4106,14 @@ ethtool_tunnel_info_get_req_set_header_flags(struct ethtool_tunnel_info_get_req
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_tunnel_info_get_req_set_header_phy_index(struct ethtool_tunnel_info_get_req *req,
+						 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_tunnel_info_get_rsp {
 	struct {
@@ -3839,6 +4177,14 @@ ethtool_tunnel_info_get_req_dump_set_header_flags(struct ethtool_tunnel_info_get
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_tunnel_info_get_req_dump_set_header_phy_index(struct ethtool_tunnel_info_get_req_dump *req,
+						      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_tunnel_info_get_list {
 	struct ethtool_tunnel_info_get_list *next;
@@ -3894,6 +4240,14 @@ ethtool_fec_get_req_set_header_flags(struct ethtool_fec_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_fec_get_req_set_header_phy_index(struct ethtool_fec_get_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_fec_get_rsp {
 	struct {
@@ -3961,6 +4315,14 @@ ethtool_fec_get_req_dump_set_header_flags(struct ethtool_fec_get_req_dump *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_fec_get_req_dump_set_header_phy_index(struct ethtool_fec_get_req_dump *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_fec_get_list {
 	struct ethtool_fec_get_list *next;
@@ -4034,6 +4396,14 @@ ethtool_fec_set_req_set_header_flags(struct ethtool_fec_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_fec_set_req_set_header_phy_index(struct ethtool_fec_set_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_fec_set_req_set_modes_nomask(struct ethtool_fec_set_req *req)
 {
 	req->_present.modes = 1;
@@ -4144,6 +4514,14 @@ ethtool_module_eeprom_get_req_set_header_flags(struct ethtool_module_eeprom_get_
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_module_eeprom_get_req_set_header_phy_index(struct ethtool_module_eeprom_get_req *req,
+						   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_module_eeprom_get_rsp {
 	struct {
@@ -4218,6 +4596,14 @@ ethtool_module_eeprom_get_req_dump_set_header_flags(struct ethtool_module_eeprom
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_module_eeprom_get_req_dump_set_header_phy_index(struct ethtool_module_eeprom_get_req_dump *req,
+							__u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_module_eeprom_get_list {
 	struct ethtool_module_eeprom_get_list *next;
@@ -4274,6 +4660,14 @@ ethtool_phc_vclocks_get_req_set_header_flags(struct ethtool_phc_vclocks_get_req
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_phc_vclocks_get_req_set_header_phy_index(struct ethtool_phc_vclocks_get_req *req,
+						 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_phc_vclocks_get_rsp {
 	struct {
@@ -4337,6 +4731,14 @@ ethtool_phc_vclocks_get_req_dump_set_header_flags(struct ethtool_phc_vclocks_get
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_phc_vclocks_get_req_dump_set_header_phy_index(struct ethtool_phc_vclocks_get_req_dump *req,
+						      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_phc_vclocks_get_list {
 	struct ethtool_phc_vclocks_get_list *next;
@@ -4392,6 +4794,14 @@ ethtool_module_get_req_set_header_flags(struct ethtool_module_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_module_get_req_set_header_phy_index(struct ethtool_module_get_req *req,
+					    __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_module_get_rsp {
 	struct {
@@ -4455,6 +4865,14 @@ ethtool_module_get_req_dump_set_header_flags(struct ethtool_module_get_req_dump
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_module_get_req_dump_set_header_phy_index(struct ethtool_module_get_req_dump *req,
+						 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_module_get_list {
 	struct ethtool_module_get_list *next;
@@ -4525,6 +4943,14 @@ ethtool_module_set_req_set_header_flags(struct ethtool_module_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_module_set_req_set_header_phy_index(struct ethtool_module_set_req *req,
+					    __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_module_set_req_set_power_mode_policy(struct ethtool_module_set_req *req,
 					     __u8 power_mode_policy)
 {
@@ -4586,6 +5012,14 @@ ethtool_pse_get_req_set_header_flags(struct ethtool_pse_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_pse_get_req_set_header_phy_index(struct ethtool_pse_get_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_pse_get_rsp {
 	struct {
@@ -4651,6 +5085,14 @@ ethtool_pse_get_req_dump_set_header_flags(struct ethtool_pse_get_req_dump *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_pse_get_req_dump_set_header_phy_index(struct ethtool_pse_get_req_dump *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_pse_get_list {
 	struct ethtool_pse_get_list *next;
@@ -4711,6 +5153,14 @@ ethtool_pse_set_req_set_header_flags(struct ethtool_pse_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_pse_set_req_set_header_phy_index(struct ethtool_pse_set_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_pse_set_req_set_admin_state(struct ethtool_pse_set_req *req,
 				    __u32 admin_state)
 {
@@ -4779,6 +5229,14 @@ ethtool_rss_get_req_set_header_flags(struct ethtool_rss_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_rss_get_req_set_header_phy_index(struct ethtool_rss_get_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_rss_get_rsp {
 	struct {
@@ -4846,6 +5304,14 @@ ethtool_rss_get_req_dump_set_header_flags(struct ethtool_rss_get_req_dump *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_rss_get_req_dump_set_header_phy_index(struct ethtool_rss_get_req_dump *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_rss_get_list {
 	struct ethtool_rss_get_list *next;
@@ -4900,6 +5366,14 @@ ethtool_plca_get_cfg_req_set_header_flags(struct ethtool_plca_get_cfg_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_plca_get_cfg_req_set_header_phy_index(struct ethtool_plca_get_cfg_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_plca_get_cfg_rsp {
 	struct {
@@ -4976,6 +5450,14 @@ ethtool_plca_get_cfg_req_dump_set_header_flags(struct ethtool_plca_get_cfg_req_d
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_plca_get_cfg_req_dump_set_header_phy_index(struct ethtool_plca_get_cfg_req_dump *req,
+						   __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_plca_get_cfg_list {
 	struct ethtool_plca_get_cfg_list *next;
@@ -5059,6 +5541,14 @@ ethtool_plca_set_cfg_req_set_header_flags(struct ethtool_plca_set_cfg_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_plca_set_cfg_req_set_header_phy_index(struct ethtool_plca_set_cfg_req *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_plca_set_cfg_req_set_version(struct ethtool_plca_set_cfg_req *req,
 				     __u16 version)
 {
@@ -5164,6 +5654,14 @@ ethtool_plca_get_status_req_set_header_flags(struct ethtool_plca_get_status_req
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_plca_get_status_req_set_header_phy_index(struct ethtool_plca_get_status_req *req,
+						 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_plca_get_status_rsp {
 	struct {
@@ -5241,6 +5739,14 @@ ethtool_plca_get_status_req_dump_set_header_flags(struct ethtool_plca_get_status
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_plca_get_status_req_dump_set_header_phy_index(struct ethtool_plca_get_status_req_dump *req,
+						      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_plca_get_status_list {
 	struct ethtool_plca_get_status_list *next;
@@ -5296,6 +5802,14 @@ ethtool_mm_get_req_set_header_flags(struct ethtool_mm_get_req *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_mm_get_req_set_header_phy_index(struct ethtool_mm_get_req *req,
+					__u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_mm_get_rsp {
 	struct {
@@ -5373,6 +5887,14 @@ ethtool_mm_get_req_dump_set_header_flags(struct ethtool_mm_get_req_dump *req,
 	req->header._present.flags = 1;
 	req->header.flags = flags;
 }
+static inline void
+ethtool_mm_get_req_dump_set_header_phy_index(struct ethtool_mm_get_req_dump *req,
+					     __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
 
 struct ethtool_mm_get_list {
 	struct ethtool_mm_get_list *next;
@@ -5448,6 +5970,14 @@ ethtool_mm_set_req_set_header_flags(struct ethtool_mm_set_req *req,
 	req->header.flags = flags;
 }
 static inline void
+ethtool_mm_set_req_set_header_phy_index(struct ethtool_mm_set_req *req,
+					__u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+static inline void
 ethtool_mm_set_req_set_verify_enabled(struct ethtool_mm_set_req *req,
 				      __u8 verify_enabled)
 {
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:59 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:59 +0100
Subject: [RFC PATCH net-next v3 09/13] net: ethtool: plca: Target the command to the requested PHY
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-10-maxime.chevallier@bootlin.com>

PLCA is a PHY-specific command. Instead of targeting the command
towards dev->phydev, use the request to pick the targeted PHY.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: No changes
V2: New patch

 net/ethtool/plca.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/net/ethtool/plca.c b/net/ethtool/plca.c
index b1e2e3b5027f..2b3e419f4dc2 100644
--- a/net/ethtool/plca.c
+++ b/net/ethtool/plca.c
@@ -61,7 +61,7 @@ static int plca_get_cfg_prepare_data(const struct ethnl_req_info *req_base,
 	int ret;
 
 	// check that the PHY device is available and connected
-	if (!dev->phydev) {
+	if (!req_base->phydev) {
 		ret = -EOPNOTSUPP;
 		goto out;
 	}
@@ -80,7 +80,7 @@ static int plca_get_cfg_prepare_data(const struct ethnl_req_info *req_base,
 	memset(&data->plca_cfg, 0xff,
 	       sizeof_field(struct plca_reply_data, plca_cfg));
 
-	ret = ops->get_plca_cfg(dev->phydev, &data->plca_cfg);
+	ret = ops->get_plca_cfg(req_base->phydev, &data->plca_cfg);
 	ethnl_ops_complete(dev);
 
 out:
@@ -141,7 +141,6 @@ const struct nla_policy ethnl_plca_set_cfg_policy[] = {
 static int
 ethnl_set_plca(struct ethnl_req_info *req_info, struct genl_info *info)
 {
-	struct net_device *dev = req_info->dev;
 	const struct ethtool_phy_ops *ops;
 	struct nlattr **tb = info->attrs;
 	struct phy_plca_cfg plca_cfg;
@@ -149,7 +148,7 @@ ethnl_set_plca(struct ethnl_req_info *req_info, struct genl_info *info)
 	int ret;
 
 	// check that the PHY device is available and connected
-	if (!dev->phydev)
+	if (!req_info->phydev)
 		return -EOPNOTSUPP;
 
 	ops = ethtool_phy_ops;
@@ -168,7 +167,7 @@ ethnl_set_plca(struct ethnl_req_info *req_info, struct genl_info *info)
 	if (!mod)
 		return 0;
 
-	ret = ops->set_plca_cfg(dev->phydev, &plca_cfg, info->extack);
+	ret = ops->set_plca_cfg(req_info->phydev, &plca_cfg, info->extack);
 	return ret < 0 ? ret : 1;
 }
 
@@ -204,7 +203,7 @@ static int plca_get_status_prepare_data(const struct ethnl_req_info *req_base,
 	int ret;
 
 	// check that the PHY device is available and connected
-	if (!dev->phydev) {
+	if (!req_base->phydev) {
 		ret = -EOPNOTSUPP;
 		goto out;
 	}
@@ -223,7 +222,7 @@ static int plca_get_status_prepare_data(const struct ethnl_req_info *req_base,
 	memset(&data->plca_st, 0xff,
 	       sizeof_field(struct plca_reply_data, plca_st));
 
-	ret = ops->get_plca_status(dev->phydev, &data->plca_st);
+	ret = ops->get_plca_status(req_base->phydev, &data->plca_st);
 	ethnl_ops_complete(dev);
 out:
 	return ret;
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:57 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:57 +0100
Subject: [RFC PATCH net-next v3 07/13] net: ethtool: Introduce a command to list PHYs on an interface
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-8-maxime.chevallier@bootlin.com>

As we have the ability to track the PHYs connected to a net_device
through the link_topology, we can expose this list to userspace. This
allows userspace to use these identifiers for phy-specific commands and
take the decision of which PHY to target by knowing the link topology.

Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list
devices on only one interface.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: - Fixed the documentation
    - Fixed the DUMP implementation
V2: New patch

 Documentation/networking/ethtool-netlink.rst |  44 +++
 include/uapi/linux/ethtool_netlink.h         |  29 ++
 net/ethtool/Makefile                         |   2 +-
 net/ethtool/netlink.c                        |   9 +
 net/ethtool/netlink.h                        |   5 +
 net/ethtool/phy.c                            | 292 +++++++++++++++++++
 6 files changed, 380 insertions(+), 1 deletion(-)
 create mode 100644 net/ethtool/phy.c

diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index 8f6390a85895..d9b8cc256e71 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst
@@ -2001,6 +2001,49 @@ The attributes are propagated to the driver through the following structure:
 .. kernel-doc:: include/linux/ethtool.h
     :identifiers: ethtool_mm_cfg
 
+PHY_GET
+=======
+
+Retrieve information about a given Ethernet PHY sitting on the link. As there
+can be more than one PHY, the DUMP operation can be used to list the PHYs
+present on a given interface, by passing an interface index or name in
+the dump request
+
+Request contents:
+
+  ====================================  ======  ==========================
+  ``ETHTOOL_A_PHY_HEADER``              nested  request header
+  ====================================  ======  ==========================
+
+Kernel response contents:
+
+  ===================================== ======  ==========================
+  ``ETHTOOL_A_PHY_HEADER``              nested  request header
+  ``ETHTOOL_A_PHY_INDEX``               u32     the phy's unique index, that can
+                                                be used for phy-specific requests
+  ``ETHTOOL_A_PHY_DRVNAME``             string  the phy driver name
+  ``ETHTOOL_A_PHY_NAME``                string  the phy device name
+  ``ETHTOOL_A_PHY_UPSTREAM_TYPE``       u32     the type of device this phy is
+                                                connected to
+  ``ETHTOOL_A_PHY_UPSTREAM_PHY``        nested  if the phy is connected to another
+                                                phy, this nest contains info on
+                                                that connection
+  ``ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME`` string  if the phy controls an sfp bus,
+                                                the name of the sfp bus
+  ``ETHTOOL_A_PHY_ID``                  u32     the phy id if the phy is C22
+  ===================================== ======  ==========================
+
+When ``ETHTOOL_A_PHY_UPSTREAM_TYPE`` is PHY_UPSTREAM_PHY, the PHY's parent is
+another PHY. Information on the parent PHY will be set in the
+``ETHTOOL_A_PHY_UPSTREAM_PHY`` nest, which has the following structure :
+
+  =================================== ======  ==========================
+  ``ETHTOOL_A_PHY_UPSTREAM_INDEX``    u32     the PHY index of the upstream PHY
+  ``ETHTOOL_A_PHY_UPSTREAM_SFP_NAME`` string  if this PHY is connected to it's
+                                                parent PHY through an SFP bus, the
+                                                name of this sfp bus
+  =================================== ======  ==========================
+
 Request translation
 ===================
 
@@ -2107,4 +2150,5 @@ are netlink only.
   n/a                                 ``ETHTOOL_MSG_PLCA_GET_STATUS``
   n/a                                 ``ETHTOOL_MSG_MM_GET``
   n/a                                 ``ETHTOOL_MSG_MM_SET``
+  n/a                                 ``ETHTOOL_MSG_PHY_GET``
   =================================== =====================================
diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h
index e557cf35250e..7d621963698a 100644
--- a/include/uapi/linux/ethtool_netlink.h
+++ b/include/uapi/linux/ethtool_netlink.h
@@ -57,6 +57,7 @@ enum {
 	ETHTOOL_MSG_PLCA_GET_STATUS,
 	ETHTOOL_MSG_MM_GET,
 	ETHTOOL_MSG_MM_SET,
+	ETHTOOL_MSG_PHY_GET,
 
 	/* add new constants above here */
 	__ETHTOOL_MSG_USER_CNT,
@@ -109,6 +110,8 @@ enum {
 	ETHTOOL_MSG_PLCA_NTF,
 	ETHTOOL_MSG_MM_GET_REPLY,
 	ETHTOOL_MSG_MM_NTF,
+	ETHTOOL_MSG_PHY_GET_REPLY,
+	ETHTOOL_MSG_PHY_NTF,
 
 	/* add new constants above here */
 	__ETHTOOL_MSG_KERNEL_CNT,
@@ -976,6 +979,32 @@ enum {
 	ETHTOOL_A_MM_MAX = (__ETHTOOL_A_MM_CNT - 1)
 };
 
+enum {
+	ETHTOOL_A_PHY_UPSTREAM_UNSPEC,
+	ETHTOOL_A_PHY_UPSTREAM_INDEX,			/* u32 */
+	ETHTOOL_A_PHY_UPSTREAM_SFP_NAME,		/* string */
+
+	/* add new constants above here */
+	__ETHTOOL_A_PHY_UPSTREAM_CNT,
+	ETHTOOL_A_PHY_UPSTREAM_MAX = (__ETHTOOL_A_PHY_UPSTREAM_CNT - 1)
+};
+
+enum {
+	ETHTOOL_A_PHY_UNSPEC,
+	ETHTOOL_A_PHY_HEADER,			/* nest - _A_HEADER_* */
+	ETHTOOL_A_PHY_INDEX,			/* u32 */
+	ETHTOOL_A_PHY_DRVNAME,			/* string */
+	ETHTOOL_A_PHY_NAME,			/* string */
+	ETHTOOL_A_PHY_UPSTREAM_TYPE,		/* u8 */
+	ETHTOOL_A_PHY_UPSTREAM,			/* nest - _A_PHY_UPSTREAM_* */
+	ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME,	/* string */
+	ETHTOOL_A_PHY_ID,			/* u32 */
+
+	/* add new constants above here */
+	__ETHTOOL_A_PHY_CNT,
+	ETHTOOL_A_PHY_MAX = (__ETHTOOL_A_PHY_CNT - 1)
+};
+
 /* generic netlink info */
 #define ETHTOOL_GENL_NAME "ethtool"
 #define ETHTOOL_GENL_VERSION 1
diff --git a/net/ethtool/Makefile b/net/ethtool/Makefile
index 504f954a1b28..0ccd0e9afd3f 100644
--- a/net/ethtool/Makefile
+++ b/net/ethtool/Makefile
@@ -8,4 +8,4 @@ ethtool_nl-y	:= netlink.o bitset.o strset.o linkinfo.o linkmodes.o rss.o \
 		   linkstate.o debug.o wol.o features.o privflags.o rings.o \
 		   channels.o coalesce.o pause.o eee.o tsinfo.o cabletest.o \
 		   tunnels.o fec.o eeprom.o stats.o phc_vclocks.o mm.o \
-		   module.o pse-pd.o plca.o mm.o
+		   module.o pse-pd.o plca.o mm.o phy.o
diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
index b8faab3a92e8..ebc481f2cf39 100644
--- a/net/ethtool/netlink.c
+++ b/net/ethtool/netlink.c
@@ -1152,6 +1152,15 @@ static const struct genl_ops ethtool_genl_ops[] = {
 		.policy = ethnl_mm_set_policy,
 		.maxattr = ARRAY_SIZE(ethnl_mm_set_policy) - 1,
 	},
+	{
+		.cmd	= ETHTOOL_MSG_PHY_GET,
+		.doit	= ethnl_phy_doit,
+		.start	= ethnl_phy_start,
+		.dumpit	= ethnl_phy_dumpit,
+		.done	= ethnl_phy_done,
+		.policy = ethnl_phy_get_policy,
+		.maxattr = ARRAY_SIZE(ethnl_phy_get_policy) - 1,
+	},
 };
 
 static const struct genl_multicast_group ethtool_nl_mcgrps[] = {
diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h
index def84e2def9e..5e6a43e35a09 100644
--- a/net/ethtool/netlink.h
+++ b/net/ethtool/netlink.h
@@ -444,6 +444,7 @@ extern const struct nla_policy ethnl_plca_set_cfg_policy[ETHTOOL_A_PLCA_MAX + 1]
 extern const struct nla_policy ethnl_plca_get_status_policy[ETHTOOL_A_PLCA_HEADER + 1];
 extern const struct nla_policy ethnl_mm_get_policy[ETHTOOL_A_MM_HEADER + 1];
 extern const struct nla_policy ethnl_mm_set_policy[ETHTOOL_A_MM_MAX + 1];
+extern const struct nla_policy ethnl_phy_get_policy[ETHTOOL_A_PHY_HEADER + 1];
 
 int ethnl_set_features(struct sk_buff *skb, struct genl_info *info);
 int ethnl_act_cable_test(struct sk_buff *skb, struct genl_info *info);
@@ -451,6 +452,10 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct genl_info *info);
 int ethnl_tunnel_info_doit(struct sk_buff *skb, struct genl_info *info);
 int ethnl_tunnel_info_start(struct netlink_callback *cb);
 int ethnl_tunnel_info_dumpit(struct sk_buff *skb, struct netlink_callback *cb);
+int ethnl_phy_start(struct netlink_callback *cb);
+int ethnl_phy_doit(struct sk_buff *skb, struct genl_info *info);
+int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb);
+int ethnl_phy_done(struct netlink_callback *cb);
 
 extern const char stats_std_names[__ETHTOOL_STATS_CNT][ETH_GSTRING_LEN];
 extern const char stats_eth_phy_names[__ETHTOOL_A_STATS_ETH_PHY_CNT][ETH_GSTRING_LEN];
diff --git a/net/ethtool/phy.c b/net/ethtool/phy.c
new file mode 100644
index 000000000000..e25ac405e46c
--- /dev/null
+++ b/net/ethtool/phy.c
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2023 Bootlin
+ *
+ */
+#include "common.h"
+#include "netlink.h"
+
+#include <linux/phy.h>
+#include <linux/phy_link_topology.h>
+#include <linux/sfp.h>
+
+struct phy_req_info {
+	struct ethnl_req_info		base;
+	struct phy_device_node		pdn;
+};
+
+#define PHY_REQINFO(__req_base) \
+	container_of(__req_base, struct phy_req_info, base)
+
+const struct nla_policy ethnl_phy_get_policy[ETHTOOL_A_PHY_HEADER + 1] = {
+	[ETHTOOL_A_PHY_HEADER] = NLA_POLICY_NESTED(ethnl_header_policy),
+};
+
+/* Caller holds rtnl */
+static ssize_t
+ethnl_phy_reply_size(const struct ethnl_req_info *req_base,
+		     struct netlink_ext_ack *extack)
+{
+	struct phy_link_topology *topo;
+	struct phy_device_node *pdn;
+	struct phy_device *phydev;
+	unsigned long index;
+	size_t size;
+
+	ASSERT_RTNL();
+
+	topo = &req_base->dev->link_topo;
+
+	size = nla_total_size(0);
+
+	xa_for_each(&topo->phys, index, pdn) {
+		phydev = pdn->phy;
+
+		/* ETHTOOL_A_PHY_INDEX */
+		size += nla_total_size(sizeof(u32));
+
+		/* ETHTOOL_A_DRVNAME */
+		size += nla_total_size(strlen(phydev->drv->name));
+
+		/* ETHTOOL_A_NAME */
+		size += nla_total_size(strlen(dev_name(&phydev->mdio.dev)));
+
+		/* ETHTOOL_A_PHY_UPSTREAM_TYPE */
+		size += nla_total_size(sizeof(u8));
+
+		/* ETHTOOL_A_PHY_ID */
+		size += nla_total_size(sizeof(u32));
+
+		if (phy_on_sfp(phydev)) {
+			/* ETHTOOL_A_PHY_UPSTREAM_SFP_NAME */
+			if (sfp_get_name(pdn->parent_sfp_bus))
+				size += nla_total_size(strlen(sfp_get_name(pdn->parent_sfp_bus)));
+
+			/* ETHTOOL_A_PHY_UPSTREAM_INDEX */
+			size += nla_total_size(sizeof(u32));
+		}
+
+		/* ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME */
+		if (phydev->sfp_bus)
+			size += nla_total_size(strlen(sfp_get_name(phydev->sfp_bus)));
+	}
+
+	return size;
+}
+
+static int
+ethnl_phy_fill_reply(const struct ethnl_req_info *req_base, struct sk_buff *skb)
+{
+	struct phy_req_info *req_info = PHY_REQINFO(req_base);
+	struct phy_device_node *pdn = &req_info->pdn;
+	struct phy_device *phydev = pdn->phy;
+	enum phy_upstream ptype;
+	struct nlattr *nest;
+
+	ptype = pdn->upstream_type;
+
+	if (nla_put_u32(skb, ETHTOOL_A_PHY_INDEX, phydev->phyindex) ||
+	    nla_put_string(skb, ETHTOOL_A_PHY_DRVNAME, phydev->drv->name) ||
+	    nla_put_string(skb, ETHTOOL_A_PHY_NAME, dev_name(&phydev->mdio.dev)) ||
+	    nla_put_u8(skb, ETHTOOL_A_PHY_UPSTREAM_TYPE, ptype) ||
+	    nla_put_u32(skb, ETHTOOL_A_PHY_ID, phydev->phy_id))
+		return -EMSGSIZE;
+
+	if (ptype == PHY_UPSTREAM_PHY) {
+		struct phy_device *upstream = pdn->upstream.phydev;
+
+		nest = nla_nest_start(skb, ETHTOOL_A_PHY_UPSTREAM);
+		if (!nest)
+			return -EMSGSIZE;
+
+		/* Parent index */
+		if (nla_put_u32(skb, ETHTOOL_A_PHY_UPSTREAM_INDEX, upstream->phyindex))
+			return -EMSGSIZE;
+
+		if (pdn->parent_sfp_bus && sfp_get_name(pdn->parent_sfp_bus) &&
+		    nla_put_string(skb, ETHTOOL_A_PHY_UPSTREAM_SFP_NAME,
+				   sfp_get_name(pdn->parent_sfp_bus)))
+			return -EMSGSIZE;
+
+		nla_nest_end(skb, nest);
+	}
+
+	if (phydev->sfp_bus &&
+	    nla_put_string(skb, ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME,
+			   sfp_get_name(phydev->sfp_bus)))
+		return -EMSGSIZE;
+
+	return 0;
+}
+
+static int ethnl_phy_parse_request(struct ethnl_req_info *req_base,
+				   struct nlattr **tb)
+{
+	struct phy_req_info *req_info = PHY_REQINFO(req_base);
+	struct phy_link_topology *topo = &req_base->dev->link_topo;
+	struct phy_device_node *pdn;
+
+	if (!req_base->phydev)
+		return 0;
+
+	pdn = xa_load(&topo->phys, req_base->phydev->phyindex);
+	memcpy(&req_info->pdn, pdn, sizeof(*pdn));
+
+	return 0;
+}
+
+int ethnl_phy_doit(struct sk_buff *skb, struct genl_info *info)
+{
+	struct phy_req_info req_info = {};
+	struct nlattr **tb = info->attrs;
+	struct sk_buff *rskb;
+	void *reply_payload;
+	int reply_len;
+	int ret;
+
+	ret = ethnl_parse_header_dev_get(&req_info.base,
+					 tb[ETHTOOL_A_PHY_HEADER],
+					 genl_info_net(info), info->extack,
+					 true);
+	if (ret < 0)
+		return ret;
+
+	rtnl_lock();
+
+	ret = ethnl_phy_parse_request(&req_info.base, tb);
+	if (ret < 0)
+		goto err_unlock_rtnl;
+
+	/* No PHY, return early */
+	if (!req_info.pdn.phy)
+		goto err_unlock_rtnl;
+
+	ret = ethnl_phy_reply_size(&req_info.base, info->extack);
+	if (ret < 0)
+		goto err_unlock_rtnl;
+	reply_len = ret + ethnl_reply_header_size();
+
+	rskb = ethnl_reply_init(reply_len, req_info.base.dev,
+				ETHTOOL_MSG_PHY_GET_REPLY,
+				ETHTOOL_A_PHY_HEADER,
+				info, &reply_payload);
+	if (!rskb) {
+		ret = -ENOMEM;
+		goto err_unlock_rtnl;
+	}
+
+	ret = ethnl_phy_fill_reply(&req_info.base, rskb);
+	if (ret)
+		goto err_free_msg;
+
+	rtnl_unlock();
+	ethnl_parse_header_dev_put(&req_info.base);
+	genlmsg_end(rskb, reply_payload);
+
+	return genlmsg_reply(rskb, info);
+
+err_free_msg:
+	nlmsg_free(rskb);
+err_unlock_rtnl:
+	rtnl_unlock();
+	ethnl_parse_header_dev_put(&req_info.base);
+	return ret;
+}
+
+struct ethnl_phy_dump_ctx {
+	struct phy_req_info	*phy_req_info;
+};
+
+int ethnl_phy_start(struct netlink_callback *cb)
+{
+	const struct genl_dumpit_info *info = genl_dumpit_info(cb);
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+	struct nlattr **tb = info->info.attrs;
+	int ret;
+
+	BUILD_BUG_ON(sizeof(*ctx) > sizeof(cb->ctx));
+
+	ctx->phy_req_info = kzalloc(sizeof(*ctx->phy_req_info), GFP_KERNEL);
+	if (!ctx->phy_req_info)
+		return -ENOMEM;
+
+	ret = ethnl_parse_header_dev_get(&ctx->phy_req_info->base,
+					 tb[ETHTOOL_A_PHY_HEADER],
+					 sock_net(cb->skb->sk), cb->extack,
+					 false);
+	return ret;
+}
+
+int ethnl_phy_done(struct netlink_callback *cb)
+{
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+
+	kfree(ctx->phy_req_info);
+
+	return 0;
+}
+
+static int ethnl_phy_dump_one_dev(struct sk_buff *skb, struct net_device *dev,
+				  struct netlink_callback *cb)
+{
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+	struct phy_req_info *pri = ctx->phy_req_info;
+	struct phy_device_node *pdn;
+	unsigned long index = 1;
+	void *ehdr;
+	int ret;
+
+	pri->base.dev = dev;
+
+	xa_for_each(&dev->link_topo.phys, index, pdn) {
+		ehdr = ethnl_dump_put(skb, cb,
+				      ETHTOOL_MSG_PHY_GET_REPLY);
+		if (!ehdr) {
+			ret = -EMSGSIZE;
+			break;
+		}
+
+		ret = ethnl_fill_reply_header(skb, dev,
+					      ETHTOOL_A_PHY_HEADER);
+		if (ret < 0) {
+			genlmsg_cancel(skb, ehdr);
+			break;
+		}
+
+		memcpy(&pri->pdn, pdn, sizeof(*pdn));
+		ret = ethnl_phy_fill_reply(&pri->base, skb);
+
+		genlmsg_end(skb, ehdr);
+	}
+
+	return ret;
+}
+
+int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
+{
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+	struct net *net = sock_net(skb->sk);
+	unsigned long ifindex = 1;
+	struct net_device *dev;
+	int ret = 0;
+
+	rtnl_lock();
+
+	if (ctx->phy_req_info->base.dev) {
+		ret = ethnl_phy_dump_one_dev(skb, ctx->phy_req_info->base.dev, cb);
+		ethnl_parse_header_dev_put(&ctx->phy_req_info->base);
+		ctx->phy_req_info->base.dev = NULL;
+	} else {
+		for_each_netdev_dump(net, dev, ifindex) {
+			ret = ethnl_phy_dump_one_dev(skb, dev, cb);
+			if (ret)
+				break;
+		}
+	}
+	rtnl_unlock();
+
+	if (ret == -EMSGSIZE && skb->len)
+		return skb->len;
+	return ret;
+}
+
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:36:58 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:36:58 +0100
Subject: [RFC PATCH net-next v3 08/13] netlink: specs: add ethnl PHY_GET command set
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-9-maxime.chevallier@bootlin.com>

The PHY_GET command, supporting both DUMP and GET operations, is used to
retrieve the list of PHYs connected to a netdevice, and get topology
information to know where exactly it sits on the physical link.

Add the netlink specs corresponding to that command, and bump the
ethtool-user.c|h autogenerated files.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: New patch

 Documentation/netlink/specs/ethtool.yaml |  65 ++++++
 tools/net/ynl/generated/ethtool-user.c   | 257 +++++++++++++++++++++++
 tools/net/ynl/generated/ethtool-user.h   | 153 ++++++++++++++
 3 files changed, 475 insertions(+)

diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 4e0790648913..280b090b5f7c 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -16,6 +16,11 @@ definitions:
     name: stringset
     type: enum
     entries: []
+  -
+    name: phy-upstream-type
+    enum-name:
+    type: enum
+    entries: [ mac, phy ]
 
 attribute-sets:
   -
@@ -942,6 +947,45 @@ attribute-sets:
       -
         name: burst-tmr
         type: u32
+  -
+    name: phy-upstream
+    attributes:
+      -
+        name: index
+        type: u32
+      -
+        name: sfp-name
+        type: string
+  -
+    name: phy
+    attributes:
+      -
+        name: header
+        type: nest
+        nested-attributes: header
+      -
+        name: index
+        type: u32
+      -
+        name: drvname
+        type: string
+      -
+        name: name
+        type: string
+      -
+        name: upstream-type
+        type: u8
+        enum: phy-upstream-type
+      -
+        name: upstream
+        type: nest
+        nested-attributes: phy-upstream
+      -
+        name: downstream-sfp-name
+        type: string
+      -
+        name: id
+        type: u32
 
 operations:
   enum-model: directional
@@ -1692,3 +1736,24 @@ operations:
       name: mm-ntf
       doc: Notification for change in MAC Merge configuration.
       notify: mm-get
+    -
+      name: phy-get
+      doc: Get PHY devices attached to an interface
+
+      attribute-set: phy
+
+      do: &phy-get-op
+        request:
+          attributes:
+            - header
+        reply:
+          attributes:
+            - header
+            - index
+            - drvname
+            - name
+            - upstream-type
+            - upstream
+            - downstream-sfp-name
+            - id
+      dump: *phy-get-op
diff --git a/tools/net/ynl/generated/ethtool-user.c b/tools/net/ynl/generated/ethtool-user.c
index 295661eb3a3e..b63ba2d2e25e 100644
--- a/tools/net/ynl/generated/ethtool-user.c
+++ b/tools/net/ynl/generated/ethtool-user.c
@@ -59,6 +59,7 @@ static const char * const ethtool_op_strmap[] = {
 	[41] = "plca-ntf",
 	[ETHTOOL_MSG_MM_GET] = "mm-get",
 	[43] = "mm-ntf",
+	[ETHTOOL_MSG_PHY_GET] = "phy-get",
 };
 
 const char *ethtool_op_str(int op)
@@ -91,6 +92,18 @@ const char *ethtool_stringset_str(enum ethtool_stringset value)
 	return ethtool_stringset_strmap[value];
 }
 
+static const char * const ethtool_phy_upstream_type_strmap[] = {
+	[0] = "mac",
+	[1] = "phy",
+};
+
+const char *ethtool_phy_upstream_type_str(int value)
+{
+	if (value < 0 || value >= (int)MNL_ARRAY_SIZE(ethtool_phy_upstream_type_strmap))
+		return NULL;
+	return ethtool_phy_upstream_type_strmap[value];
+}
+
 /* Policies */
 struct ynl_policy_attr ethtool_header_policy[ETHTOOL_A_HEADER_MAX + 1] = {
 	[ETHTOOL_A_HEADER_DEV_INDEX] = { .name = "dev-index", .type = YNL_PT_U32, },
@@ -154,6 +167,16 @@ struct ynl_policy_nest ethtool_mm_stat_nest = {
 	.table = ethtool_mm_stat_policy,
 };
 
+struct ynl_policy_attr ethtool_phy_upstream_policy[ETHTOOL_A_PHY_UPSTREAM_MAX + 1] = {
+	[ETHTOOL_A_PHY_UPSTREAM_INDEX] = { .name = "index", .type = YNL_PT_U32, },
+	[ETHTOOL_A_PHY_UPSTREAM_SFP_NAME] = { .name = "sfp-name", .type = YNL_PT_NUL_STR, },
+};
+
+struct ynl_policy_nest ethtool_phy_upstream_nest = {
+	.max_attr = ETHTOOL_A_PHY_UPSTREAM_MAX,
+	.table = ethtool_phy_upstream_policy,
+};
+
 struct ynl_policy_attr ethtool_cable_result_policy[ETHTOOL_A_CABLE_RESULT_MAX + 1] = {
 	[ETHTOOL_A_CABLE_RESULT_PAIR] = { .name = "pair", .type = YNL_PT_U8, },
 	[ETHTOOL_A_CABLE_RESULT_CODE] = { .name = "code", .type = YNL_PT_U8, },
@@ -667,6 +690,22 @@ struct ynl_policy_nest ethtool_mm_nest = {
 	.table = ethtool_mm_policy,
 };
 
+struct ynl_policy_attr ethtool_phy_policy[ETHTOOL_A_PHY_MAX + 1] = {
+	[ETHTOOL_A_PHY_HEADER] = { .name = "header", .type = YNL_PT_NEST, .nest = &ethtool_header_nest, },
+	[ETHTOOL_A_PHY_INDEX] = { .name = "index", .type = YNL_PT_U32, },
+	[ETHTOOL_A_PHY_DRVNAME] = { .name = "drvname", .type = YNL_PT_NUL_STR, },
+	[ETHTOOL_A_PHY_NAME] = { .name = "name", .type = YNL_PT_NUL_STR, },
+	[ETHTOOL_A_PHY_UPSTREAM_TYPE] = { .name = "upstream-type", .type = YNL_PT_U8, },
+	[ETHTOOL_A_PHY_UPSTREAM] = { .name = "upstream", .type = YNL_PT_NEST, .nest = &ethtool_phy_upstream_nest, },
+	[ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME] = { .name = "downstream-sfp-name", .type = YNL_PT_NUL_STR, },
+	[ETHTOOL_A_PHY_ID] = { .name = "id", .type = YNL_PT_U32, },
+};
+
+struct ynl_policy_nest ethtool_phy_nest = {
+	.max_attr = ETHTOOL_A_PHY_MAX,
+	.table = ethtool_phy_policy,
+};
+
 /* Common nested types */
 void ethtool_header_free(struct ethtool_header *obj)
 {
@@ -899,6 +938,42 @@ int ethtool_mm_stat_parse(struct ynl_parse_arg *yarg,
 	return 0;
 }
 
+void ethtool_phy_upstream_free(struct ethtool_phy_upstream *obj)
+{
+	free(obj->sfp_name);
+}
+
+int ethtool_phy_upstream_parse(struct ynl_parse_arg *yarg,
+			       const struct nlattr *nested)
+{
+	struct ethtool_phy_upstream *dst = yarg->data;
+	const struct nlattr *attr;
+
+	mnl_attr_for_each_nested(attr, nested) {
+		unsigned int type = mnl_attr_get_type(attr);
+
+		if (type == ETHTOOL_A_PHY_UPSTREAM_INDEX) {
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+			dst->_present.index = 1;
+			dst->index = mnl_attr_get_u32(attr);
+		} else if (type == ETHTOOL_A_PHY_UPSTREAM_SFP_NAME) {
+			unsigned int len;
+
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+
+			len = strnlen(mnl_attr_get_str(attr), mnl_attr_get_payload_len(attr));
+			dst->_present.sfp_name_len = len;
+			dst->sfp_name = malloc(len + 1);
+			memcpy(dst->sfp_name, mnl_attr_get_str(attr), len);
+			dst->sfp_name[len] = 0;
+		}
+	}
+
+	return 0;
+}
+
 void ethtool_cable_result_free(struct ethtool_cable_result *obj)
 {
 }
@@ -6158,6 +6233,188 @@ int ethtool_mm_set(struct ynl_sock *ys, struct ethtool_mm_set_req *req)
 	return 0;
 }
 
+/* ============== ETHTOOL_MSG_PHY_GET ============== */
+/* ETHTOOL_MSG_PHY_GET - do */
+void ethtool_phy_get_req_free(struct ethtool_phy_get_req *req)
+{
+	ethtool_header_free(&req->header);
+	free(req);
+}
+
+void ethtool_phy_get_rsp_free(struct ethtool_phy_get_rsp *rsp)
+{
+	ethtool_header_free(&rsp->header);
+	free(rsp->drvname);
+	free(rsp->name);
+	ethtool_phy_upstream_free(&rsp->upstream);
+	free(rsp->downstream_sfp_name);
+	free(rsp);
+}
+
+int ethtool_phy_get_rsp_parse(const struct nlmsghdr *nlh, void *data)
+{
+	struct ynl_parse_arg *yarg = data;
+	struct ethtool_phy_get_rsp *dst;
+	const struct nlattr *attr;
+	struct ynl_parse_arg parg;
+
+	dst = yarg->data;
+	parg.ys = yarg->ys;
+
+	mnl_attr_for_each(attr, nlh, sizeof(struct genlmsghdr)) {
+		unsigned int type = mnl_attr_get_type(attr);
+
+		if (type == ETHTOOL_A_PHY_HEADER) {
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+			dst->_present.header = 1;
+
+			parg.rsp_policy = &ethtool_header_nest;
+			parg.data = &dst->header;
+			if (ethtool_header_parse(&parg, attr))
+				return MNL_CB_ERROR;
+		} else if (type == ETHTOOL_A_PHY_INDEX) {
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+			dst->_present.index = 1;
+			dst->index = mnl_attr_get_u32(attr);
+		} else if (type == ETHTOOL_A_PHY_DRVNAME) {
+			unsigned int len;
+
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+
+			len = strnlen(mnl_attr_get_str(attr), mnl_attr_get_payload_len(attr));
+			dst->_present.drvname_len = len;
+			dst->drvname = malloc(len + 1);
+			memcpy(dst->drvname, mnl_attr_get_str(attr), len);
+			dst->drvname[len] = 0;
+		} else if (type == ETHTOOL_A_PHY_NAME) {
+			unsigned int len;
+
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+
+			len = strnlen(mnl_attr_get_str(attr), mnl_attr_get_payload_len(attr));
+			dst->_present.name_len = len;
+			dst->name = malloc(len + 1);
+			memcpy(dst->name, mnl_attr_get_str(attr), len);
+			dst->name[len] = 0;
+		} else if (type == ETHTOOL_A_PHY_UPSTREAM_TYPE) {
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+			dst->_present.upstream_type = 1;
+			dst->upstream_type = mnl_attr_get_u8(attr);
+		} else if (type == ETHTOOL_A_PHY_UPSTREAM) {
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+			dst->_present.upstream = 1;
+
+			parg.rsp_policy = &ethtool_phy_upstream_nest;
+			parg.data = &dst->upstream;
+			if (ethtool_phy_upstream_parse(&parg, attr))
+				return MNL_CB_ERROR;
+		} else if (type == ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME) {
+			unsigned int len;
+
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+
+			len = strnlen(mnl_attr_get_str(attr), mnl_attr_get_payload_len(attr));
+			dst->_present.downstream_sfp_name_len = len;
+			dst->downstream_sfp_name = malloc(len + 1);
+			memcpy(dst->downstream_sfp_name, mnl_attr_get_str(attr), len);
+			dst->downstream_sfp_name[len] = 0;
+		} else if (type == ETHTOOL_A_PHY_ID) {
+			if (ynl_attr_validate(yarg, attr))
+				return MNL_CB_ERROR;
+			dst->_present.id = 1;
+			dst->id = mnl_attr_get_u32(attr);
+		}
+	}
+
+	return MNL_CB_OK;
+}
+
+struct ethtool_phy_get_rsp *
+ethtool_phy_get(struct ynl_sock *ys, struct ethtool_phy_get_req *req)
+{
+	struct ynl_req_state yrs = { .yarg = { .ys = ys, }, };
+	struct ethtool_phy_get_rsp *rsp;
+	struct nlmsghdr *nlh;
+	int err;
+
+	nlh = ynl_gemsg_start_req(ys, ys->family_id, ETHTOOL_MSG_PHY_GET, 1);
+	ys->req_policy = &ethtool_phy_nest;
+	yrs.yarg.rsp_policy = &ethtool_phy_nest;
+
+	if (req->_present.header)
+		ethtool_header_put(nlh, ETHTOOL_A_PHY_HEADER, &req->header);
+
+	rsp = calloc(1, sizeof(*rsp));
+	yrs.yarg.data = rsp;
+	yrs.cb = ethtool_phy_get_rsp_parse;
+	yrs.rsp_cmd = ETHTOOL_MSG_PHY_GET;
+
+	err = ynl_exec(ys, nlh, &yrs);
+	if (err < 0)
+		goto err_free;
+
+	return rsp;
+
+err_free:
+	ethtool_phy_get_rsp_free(rsp);
+	return NULL;
+}
+
+/* ETHTOOL_MSG_PHY_GET - dump */
+void ethtool_phy_get_list_free(struct ethtool_phy_get_list *rsp)
+{
+	struct ethtool_phy_get_list *next = rsp;
+
+	while ((void *)next != YNL_LIST_END) {
+		rsp = next;
+		next = rsp->next;
+
+		ethtool_header_free(&rsp->obj.header);
+		free(rsp->obj.drvname);
+		free(rsp->obj.name);
+		ethtool_phy_upstream_free(&rsp->obj.upstream);
+		free(rsp->obj.downstream_sfp_name);
+		free(rsp);
+	}
+}
+
+struct ethtool_phy_get_list *
+ethtool_phy_get_dump(struct ynl_sock *ys, struct ethtool_phy_get_req_dump *req)
+{
+	struct ynl_dump_state yds = {};
+	struct nlmsghdr *nlh;
+	int err;
+
+	yds.ys = ys;
+	yds.alloc_sz = sizeof(struct ethtool_phy_get_list);
+	yds.cb = ethtool_phy_get_rsp_parse;
+	yds.rsp_cmd = ETHTOOL_MSG_PHY_GET;
+	yds.rsp_policy = &ethtool_phy_nest;
+
+	nlh = ynl_gemsg_start_dump(ys, ys->family_id, ETHTOOL_MSG_PHY_GET, 1);
+	ys->req_policy = &ethtool_phy_nest;
+
+	if (req->_present.header)
+		ethtool_header_put(nlh, ETHTOOL_A_PHY_HEADER, &req->header);
+
+	err = ynl_exec_dump(ys, nlh, &yds);
+	if (err < 0)
+		goto free_list;
+
+	return yds.first;
+
+free_list:
+	ethtool_phy_get_list_free(yds.first);
+	return NULL;
+}
+
 /* ETHTOOL_MSG_CABLE_TEST_NTF - event */
 int ethtool_cable_test_ntf_rsp_parse(const struct nlmsghdr *nlh, void *data)
 {
diff --git a/tools/net/ynl/generated/ethtool-user.h b/tools/net/ynl/generated/ethtool-user.h
index 97c079c0f332..59ebb0a1a09f 100644
--- a/tools/net/ynl/generated/ethtool-user.h
+++ b/tools/net/ynl/generated/ethtool-user.h
@@ -20,6 +20,7 @@ extern const struct ynl_family ynl_ethtool_family;
 const char *ethtool_op_str(int op);
 const char *ethtool_udp_tunnel_type_str(int value);
 const char *ethtool_stringset_str(enum ethtool_stringset value);
+const char *ethtool_phy_upstream_type_str(int value);
 
 /* Common nested types */
 struct ethtool_header {
@@ -90,6 +91,16 @@ struct ethtool_mm_stat {
 	__u64 hold_count;
 };
 
+struct ethtool_phy_upstream {
+	struct {
+		__u32 index:1;
+		__u32 sfp_name_len;
+	} _present;
+
+	__u32 index;
+	char *sfp_name;
+};
+
 struct ethtool_cable_result {
 	struct {
 		__u32 pair:1;
@@ -6018,6 +6029,148 @@ ethtool_mm_set_req_set_tx_min_frag_size(struct ethtool_mm_set_req *req,
  */
 int ethtool_mm_set(struct ynl_sock *ys, struct ethtool_mm_set_req *req);
 
+/* ============== ETHTOOL_MSG_PHY_GET ============== */
+/* ETHTOOL_MSG_PHY_GET - do */
+struct ethtool_phy_get_req {
+	struct {
+		__u32 header:1;
+	} _present;
+
+	struct ethtool_header header;
+};
+
+static inline struct ethtool_phy_get_req *ethtool_phy_get_req_alloc(void)
+{
+	return calloc(1, sizeof(struct ethtool_phy_get_req));
+}
+void ethtool_phy_get_req_free(struct ethtool_phy_get_req *req);
+
+static inline void
+ethtool_phy_get_req_set_header_dev_index(struct ethtool_phy_get_req *req,
+					 __u32 dev_index)
+{
+	req->_present.header = 1;
+	req->header._present.dev_index = 1;
+	req->header.dev_index = dev_index;
+}
+static inline void
+ethtool_phy_get_req_set_header_dev_name(struct ethtool_phy_get_req *req,
+					const char *dev_name)
+{
+	free(req->header.dev_name);
+	req->header._present.dev_name_len = strlen(dev_name);
+	req->header.dev_name = malloc(req->header._present.dev_name_len + 1);
+	memcpy(req->header.dev_name, dev_name, req->header._present.dev_name_len);
+	req->header.dev_name[req->header._present.dev_name_len] = 0;
+}
+static inline void
+ethtool_phy_get_req_set_header_flags(struct ethtool_phy_get_req *req,
+				     __u32 flags)
+{
+	req->_present.header = 1;
+	req->header._present.flags = 1;
+	req->header.flags = flags;
+}
+static inline void
+ethtool_phy_get_req_set_header_phy_index(struct ethtool_phy_get_req *req,
+					 __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+
+struct ethtool_phy_get_rsp {
+	struct {
+		__u32 header:1;
+		__u32 index:1;
+		__u32 drvname_len;
+		__u32 name_len;
+		__u32 upstream_type:1;
+		__u32 upstream:1;
+		__u32 downstream_sfp_name_len;
+		__u32 id:1;
+	} _present;
+
+	struct ethtool_header header;
+	__u32 index;
+	char *drvname;
+	char *name;
+	__u8 upstream_type;
+	struct ethtool_phy_upstream upstream;
+	char *downstream_sfp_name;
+	__u32 id;
+};
+
+void ethtool_phy_get_rsp_free(struct ethtool_phy_get_rsp *rsp);
+
+/*
+ * Get PHY devices attached to an interface
+ */
+struct ethtool_phy_get_rsp *
+ethtool_phy_get(struct ynl_sock *ys, struct ethtool_phy_get_req *req);
+
+/* ETHTOOL_MSG_PHY_GET - dump */
+struct ethtool_phy_get_req_dump {
+	struct {
+		__u32 header:1;
+	} _present;
+
+	struct ethtool_header header;
+};
+
+static inline struct ethtool_phy_get_req_dump *
+ethtool_phy_get_req_dump_alloc(void)
+{
+	return calloc(1, sizeof(struct ethtool_phy_get_req_dump));
+}
+void ethtool_phy_get_req_dump_free(struct ethtool_phy_get_req_dump *req);
+
+static inline void
+ethtool_phy_get_req_dump_set_header_dev_index(struct ethtool_phy_get_req_dump *req,
+					      __u32 dev_index)
+{
+	req->_present.header = 1;
+	req->header._present.dev_index = 1;
+	req->header.dev_index = dev_index;
+}
+static inline void
+ethtool_phy_get_req_dump_set_header_dev_name(struct ethtool_phy_get_req_dump *req,
+					     const char *dev_name)
+{
+	free(req->header.dev_name);
+	req->header._present.dev_name_len = strlen(dev_name);
+	req->header.dev_name = malloc(req->header._present.dev_name_len + 1);
+	memcpy(req->header.dev_name, dev_name, req->header._present.dev_name_len);
+	req->header.dev_name[req->header._present.dev_name_len] = 0;
+}
+static inline void
+ethtool_phy_get_req_dump_set_header_flags(struct ethtool_phy_get_req_dump *req,
+					  __u32 flags)
+{
+	req->_present.header = 1;
+	req->header._present.flags = 1;
+	req->header.flags = flags;
+}
+static inline void
+ethtool_phy_get_req_dump_set_header_phy_index(struct ethtool_phy_get_req_dump *req,
+					      __u32 phy_index)
+{
+	req->_present.header = 1;
+	req->header._present.phy_index = 1;
+	req->header.phy_index = phy_index;
+}
+
+struct ethtool_phy_get_list {
+	struct ethtool_phy_get_list *next;
+	struct ethtool_phy_get_rsp obj __attribute__((aligned(8)));
+};
+
+void ethtool_phy_get_list_free(struct ethtool_phy_get_list *rsp);
+
+struct ethtool_phy_get_list *
+ethtool_phy_get_dump(struct ynl_sock *ys, struct ethtool_phy_get_req_dump *req);
+
 /* ETHTOOL_MSG_CABLE_TEST_NTF - event */
 struct ethtool_cable_test_ntf_rsp {
 	struct {
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:37:00 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:37:00 +0100
Subject: [RFC PATCH net-next v3 10/13] net: ethtool: pse-pd: Target the command to the requested PHY
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-11-maxime.chevallier@bootlin.com>

PSE and PD configuration is a PHY-specific command. Instead of targeting
the command towards dev->phydev, use the request to pick the targeted
PHY device.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: No changes
V2: New patch

 net/ethtool/pse-pd.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index cc478af77111..0d9cd9c87104 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -31,17 +31,10 @@ const struct nla_policy ethnl_pse_get_policy[ETHTOOL_A_PSE_HEADER + 1] = {
 	[ETHTOOL_A_PSE_HEADER] = NLA_POLICY_NESTED(ethnl_header_policy),
 };
 
-static int pse_get_pse_attributes(struct net_device *dev,
+static int pse_get_pse_attributes(struct phy_device *phydev,
 				  struct netlink_ext_ack *extack,
 				  struct pse_reply_data *data)
 {
-	struct phy_device *phydev = dev->phydev;
-
-	if (!phydev) {
-		NL_SET_ERR_MSG(extack, "No PHY is attached");
-		return -EOPNOTSUPP;
-	}
-
 	if (!phydev->psec) {
 		NL_SET_ERR_MSG(extack, "No PSE is attached");
 		return -EOPNOTSUPP;
@@ -64,7 +57,7 @@ static int pse_prepare_data(const struct ethnl_req_info *req_base,
 	if (ret < 0)
 		return ret;
 
-	ret = pse_get_pse_attributes(dev, info->extack, data);
+	ret = pse_get_pse_attributes(req_base->phydev, info->extack, data);
 
 	ethnl_ops_complete(dev);
 
@@ -124,7 +117,6 @@ ethnl_set_pse_validate(struct ethnl_req_info *req_info, struct genl_info *info)
 static int
 ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 {
-	struct net_device *dev = req_info->dev;
 	struct pse_control_config config = {};
 	struct nlattr **tb = info->attrs;
 	struct phy_device *phydev;
@@ -132,7 +124,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 	/* this values are already validated by the ethnl_pse_set_policy */
 	config.admin_cotrol = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);
 
-	phydev = dev->phydev;
+	phydev = req_info->phydev;
 	if (!phydev) {
 		NL_SET_ERR_MSG(info->extack, "No PHY is attached");
 		return -EOPNOTSUPP;
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:37:01 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:37:01 +0100
Subject: [RFC PATCH net-next v3 11/13] net: ethtool: cable-test: Target the command to the requested PHY
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-12-maxime.chevallier@bootlin.com>

Cable testing is a PHY-specific command. Instead of targeting the command
towards dev->phydev, use the request to pick the targeted PHY.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: No changes
V2: New patch

 net/ethtool/cabletest.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/ethtool/cabletest.c b/net/ethtool/cabletest.c
index 06a151165c31..6b00d0800f23 100644
--- a/net/ethtool/cabletest.c
+++ b/net/ethtool/cabletest.c
@@ -69,7 +69,7 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct genl_info *info)
 		return ret;
 
 	dev = req_info.dev;
-	if (!dev->phydev) {
+	if (!req_info.phydev) {
 		ret = -EOPNOTSUPP;
 		goto out_dev_put;
 	}
@@ -85,12 +85,12 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct genl_info *info)
 	if (ret < 0)
 		goto out_rtnl;
 
-	ret = ops->start_cable_test(dev->phydev, info->extack);
+	ret = ops->start_cable_test(req_info.phydev, info->extack);
 
 	ethnl_ops_complete(dev);
 
 	if (!ret)
-		ethnl_cable_test_started(dev->phydev,
+		ethnl_cable_test_started(req_info.phydev,
 					 ETHTOOL_MSG_CABLE_TEST_NTF);
 
 out_rtnl:
@@ -321,7 +321,7 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct genl_info *info)
 		return ret;
 
 	dev = req_info.dev;
-	if (!dev->phydev) {
+	if (!req_info.phydev) {
 		ret = -EOPNOTSUPP;
 		goto out_dev_put;
 	}
@@ -342,12 +342,12 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct genl_info *info)
 	if (ret < 0)
 		goto out_rtnl;
 
-	ret = ops->start_cable_test_tdr(dev->phydev, info->extack, &cfg);
+	ret = ops->start_cable_test_tdr(req_info.phydev, info->extack, &cfg);
 
 	ethnl_ops_complete(dev);
 
 	if (!ret)
-		ethnl_cable_test_started(dev->phydev,
+		ethnl_cable_test_started(req_info.phydev,
 					 ETHTOOL_MSG_CABLE_TEST_TDR_NTF);
 
 out_rtnl:
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:37:02 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:37:02 +0100
Subject: [RFC PATCH net-next v3 12/13] net: ethtool: strset: Allow querying phy stats by index
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-13-maxime.chevallier@bootlin.com>

The ETH_SS_PHY_STATS command gets PHY statistics. Use the phydev pointer
from the ethnl request to allow query phy stats from each PHY on the
link.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: No changes
V2: New patch

 net/ethtool/strset.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/net/ethtool/strset.c b/net/ethtool/strset.c
index c678b484a079..70c00631c51f 100644
--- a/net/ethtool/strset.c
+++ b/net/ethtool/strset.c
@@ -233,17 +233,18 @@ static void strset_cleanup_data(struct ethnl_reply_data *reply_base)
 }
 
 static int strset_prepare_set(struct strset_info *info, struct net_device *dev,
-			      unsigned int id, bool counts_only)
+			      struct phy_device *phydev, unsigned int id,
+			      bool counts_only)
 {
 	const struct ethtool_phy_ops *phy_ops = ethtool_phy_ops;
 	const struct ethtool_ops *ops = dev->ethtool_ops;
 	void *strings;
 	int count, ret;
 
-	if (id == ETH_SS_PHY_STATS && dev->phydev &&
+	if (id == ETH_SS_PHY_STATS && phydev &&
 	    !ops->get_ethtool_phy_stats && phy_ops &&
 	    phy_ops->get_sset_count)
-		ret = phy_ops->get_sset_count(dev->phydev);
+		ret = phy_ops->get_sset_count(phydev);
 	else if (ops->get_sset_count && ops->get_strings)
 		ret = ops->get_sset_count(dev, id);
 	else
@@ -258,10 +259,10 @@ static int strset_prepare_set(struct strset_info *info, struct net_device *dev,
 		strings = kcalloc(count, ETH_GSTRING_LEN, GFP_KERNEL);
 		if (!strings)
 			return -ENOMEM;
-		if (id == ETH_SS_PHY_STATS && dev->phydev &&
+		if (id == ETH_SS_PHY_STATS && phydev &&
 		    !ops->get_ethtool_phy_stats && phy_ops &&
 		    phy_ops->get_strings)
-			phy_ops->get_strings(dev->phydev, strings);
+			phy_ops->get_strings(phydev, strings);
 		else
 			ops->get_strings(dev, id, strings);
 		info->strings = strings;
@@ -305,8 +306,8 @@ static int strset_prepare_data(const struct ethnl_req_info *req_base,
 		    !data->sets[i].per_dev)
 			continue;
 
-		ret = strset_prepare_set(&data->sets[i], dev, i,
-					 req_info->counts_only);
+		ret = strset_prepare_set(&data->sets[i], dev, req_base->phydev,
+					 i, req_info->counts_only);
 		if (ret < 0)
 			goto err_ops;
 	}
-- 
2.42.0



From maxime.chevallier at bootlin.com  Fri Dec  1 08:37:03 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri,  1 Dec 2023 17:37:03 +0100
Subject: [RFC PATCH net-next v3 13/13] Documentation: networking: document phy_link_topology
In-Reply-To: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
Message-ID: <20231201163704.1306431-14-maxime.chevallier@bootlin.com>

The newly introduced phy_link_topology tracks all ethernet PHYs that are
attached to a netdevice. Document the base principle, internal and
external APIs. As the phy_link_topology is expected to be extended, this
documentation will hold any further improvements and additions made
relative to topology handling.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V3: New patch

 Documentation/networking/index.rst            |   1 +
 .../networking/phy-link-topology.rst          | 121 ++++++++++++++++++
 2 files changed, 122 insertions(+)
 create mode 100644 Documentation/networking/phy-link-topology.rst

diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index cb435c141794..e472d53f933a 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -87,6 +87,7 @@ Contents:
    operstates
    packet_mmap
    phonet
+   phy-link-topology
    pktgen
    plip
    ppp_generic
diff --git a/Documentation/networking/phy-link-topology.rst b/Documentation/networking/phy-link-topology.rst
new file mode 100644
index 000000000000..d66ee9711ac1
--- /dev/null
+++ b/Documentation/networking/phy-link-topology.rst
@@ -0,0 +1,121 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+PHY link topology
+=================
+
+Overview
+========
+
+The PHY link topology representation in the networking stack aims at representing
+the hardware layout for any given Ethernet link.
+
+An Ethernet Interface from userspace's poing of view is nothing but a
+:c:type:`struct net_device <net_device>`, which exposes configuration options
+trough the legacy ioctls and the ethool netlink commands. The base assumption
+when designing these configuration channels were that the link looked
+something like this ::
+
+  +-----------------------+        +----------+      +--------------+
+  | Ethernet Controller / |        | Ethernet |      | Connector /  |
+  |       MAC             | ------ |   PHY    | ---- |    Port      | ---... to LP
+  +-----------------------+        +----------+      +--------------+
+  struct net_device               struct phy_device
+
+Commands that needs to configure the PHY will go through the net_device.phydev
+field to reach the PHY and perform the relevant configuration.
+
+This assumption falls appart in more complex topologies that can arise when,
+for example, using SFP transceivers (although that's not the only specific case).
+
+Here, we have 2 basic scenarios. Either the MAC is able to output a serialized
+interface, that can directly be fed to an SFP cage, such as SGMII, 1000BaseX,
+10GBaseR, etc.
+
+The link topology then looks like this (when an SFP module is inserted) ::
+
+  +-----+  SGMII  +------------+
+  | MAC | ------- | SFP Module |
+  +-----+         +------------+
+
+Knowing that some modules embed a PHY, the actual link is more like ::
+
+  +-----+  SGMII   +--------------+
+  | MAC | -------- | PHY (on SFP) |
+  +-----+          +--------------+
+
+In this case, the SFP PHY is handled by phylib, and registered by phylink through
+its SFP upstream ops.
+
+Now some Ethernet controllers aren't able to output a serialized interface, so
+we can't directly connect them to an SFP cage. However, some PHYs can be used
+as media-converters, to translate the non-serialized MAC MII interface to a
+serialized MII interface fed to the SFP ::
+
+  +-----+  RGMII  +-----------------------+  SGMII  +--------------+
+  | MAC | ------- | PHY (media converter) | ------- | PHY (on SFP) |
+  +-----+         +-----------------------+         +--------------+
+
+This is where the model of having a single net_device.phydev pointer shows its
+limitations, as we now have 2 PHYs on the link.
+
+The phy_link topology framework aims at providing a way to keep track of every
+PHY on the link, for use by both kernel drivers and subsystems, but also to
+report the topology to userspace, allowing to target individual PHYs in configuration
+commands.
+
+API
+===
+
+The :c:type:`struct phy_link_topology <phy_link_topology>` is a per-netdevice
+resource, that gets initialized at netdevice creation. Once it's initialized,
+it is then possible to register PHYs to the topology through :
+
+:c:func:`phy_link_topo_add_phy`
+
+Besides registering the PHY to the topology, this call will also assign a unique
+index to the PHY, which can then be reported to userspace to refer to this PHY
+(akin to the ifindex). This index is a u32, ranging from 1 to U32_MAX. The value
+0 is reserved to indicate the PHY doesn't belong to any topology yet.
+
+The PHY can then be removed from the topology through
+
+:c:func:`phy_link_topo_del_phy`
+
+These function are already hooked into the phylib subsystem, so all PHYs that
+are linked to a net_device through :c:func:`phy_attach_direct` will automatically
+join the netdev's topology.
+
+PHYs that are on a SFP module will also be automatically registered IF the SFP
+upstream is phylink (so, no media-converter).
+
+PHY drivers that can be used as SFP upstream need to call :c:func:`phy_sfp_attach_phy`
+and :c:func:`phy_sfp_detach_phy`, which can be used as a
+.attach_phy / .detach_phy implementation for the
+:c:type:`struct sfp_upstream_ops <sfp_upstream_ops>`.
+
+UAPI
+====
+
+There exist a set of netlink commands to query the link topology from userspace,
+see ``Documentation/networking/ethtool-netlink.rst``.
+
+The whole point of having a topology representation is to assign the phyindex
+field in :c:type:`struct phy_device <phy_device>`. This index is reported to
+userspace using the ``ETHTOOL_MSG_PHY_GET`` ethtnl command. Performing a DUMP operation
+will result in all PHYs from all net_device being listed. The DUMP command
+accepts either a ``ETHTOOL_A_HEADER_DEV_INDEX`` or ``ETHTOOL_A_HEADER_DEV_NAME``
+to be passed in the request to filter the DUMP to a single net_device.
+
+The retrieved index can then be passed as a request parameter using the
+``ETHTOOL_A_HEADER_PHY_INDEX`` field in the following ethnl commands :
+
+* ``ETHTOOL_MSG_STRSET_GET`` to get the stats strig set from a given PHY
+* ``ETHTOOL_MSG_CABLE_TEST_ACT`` and ``ETHTOOL_MSG_CABLE_TEST_ACT``, to perform
+  cable testing on a given PHY on the link (most likely the outermost PHY)
+* ``ETHTOOL_MSG_PSE_SET`` and ``ETHTOOL_MSG_PSE_GET`` for PHY-controlled PoE and PSE settings
+* ``ETHTOOL_MSG_PLCA_GET_CFG``, ``ETHTOOL_MSG_PLCA_SET_CFG`` and ``ETHTOOL_MSG_PLCA_GET_STATUS``
+  to set the PLCA (Physical Layer Collision Avoidance) parameters
+
+Note that the PHY index can be passed to other requests, which will silently
+ignore it if present and irrelevant.
-- 
2.42.0



From arnd at arndb.de  Fri Dec  1 08:39:33 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 01 Dec 2023 17:39:33 +0100
Subject: [PATCH v5 09/20] dt-bindings: serial: samsung: Make samsung,uart-fifosize
 required property
In-Reply-To: <20231201160925.3136868-10-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-10-peter.griffin@linaro.org>
Message-ID: <59b949a0-5aeb-4f01-8789-cb305513b626@app.fastmail.com>

On Fri, Dec 1, 2023, at 17:09, Peter Griffin wrote:
> 
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - google,gs101-uart
> +    then:
> +      required:
> +        - samsung,uart-fifosize
> +

Is there a way to reverse the list and make the property
required for anything that is not explicitly enumerated?

      Arnd


From sudeep.holla at arm.com  Fri Dec  1 08:41:02 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 1 Dec 2023 16:41:02 +0000
Subject: [PATCH 1/2] firmware: arm_scmi: Fix frequency truncation by
 promoting multiplier to u64
In-Reply-To: <ZWoHNPlxs-WnVAFe@pluto>
References: <20231130204343.503076-1-sudeep.holla@arm.com>
 <20231201143935.be6wzjzxmyl5vpz6@bogus>
 <ZWoHNPlxs-WnVAFe@pluto>
Message-ID: <20231201164102.lb2o3mgdgjmtfknk@bogus>

On Fri, Dec 01, 2023 at 04:17:56PM +0000, Cristian Marussi wrote:
> On Fri, Dec 01, 2023 at 02:39:35PM +0000, Sudeep Holla wrote:
> > On Thu, Nov 30, 2023 at 08:43:42PM +0000, Sudeep Holla wrote:
> > > Fix the frequency truncation for all values equal to or greater 4GHz by
> > > updating the multiplier 'mult_factor' to u64 type. It is also possible
> > > that the multiplier itself can be greater than or equal to 2^32. So we need
> > > to also fix the equation computing the value of the multiplier.
> > > 
> > > Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol")
> > > Reported-by: Sibi Sankar <quic_sibis at quicinc.com>
> > > Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis at quicinc.com/
> > > Cc: Cristian Marussi <cristian.marussi at arm.com>
> > > Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> > > ---
> > >  drivers/firmware/arm_scmi/perf.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
> > > index 81dd5c5e5533..8ce449922e55 100644
> > > --- a/drivers/firmware/arm_scmi/perf.c
> > > +++ b/drivers/firmware/arm_scmi/perf.c
> > > @@ -152,7 +152,7 @@ struct perf_dom_info {
> > >  	u32 opp_count;
> > >  	u32 sustained_freq_khz;
> > >  	u32 sustained_perf_level;
> > > -	u32 mult_factor;
> > > +	u64 mult_factor;
> > 
> > I have now changed this to unsigned long instead of u64 to fix the 32-bit
> > build failure[1].
> 
> Right, I was caught a few times too by this kind of failures on v7 :D
>

?

> ... but this 32bit issue makes me wonder what to do in such a case...
>

Same here, but the frequency calculations are also unsigned long in higher
layers, so I don't see any point in making it u64(also 32-bit doesn't
support 32bit value to be divided by a 64bit value which adds unnecessary
complications here).

> ...I mean, on 32bit if the calculated freq oveflows, there is just
> nothing we can do on v7 without overcomplicating the code...but I suppose
> it is unplausible to have such high freq on a v7...

Yes this is exactly the argument I made myself and got convinced to keep
it unsigned long(KISS approach) unless we need it on v7.

> as a palliative I can only think of some sort of overflow check (only on v7)
> that could trigger a warning ... but it is hardly worth the effort
> probably..
>

Not sure myself.

--
Regards,
Sudeep


From conor at kernel.org  Fri Dec  1 08:46:09 2023
From: conor at kernel.org (Conor Dooley)
Date: Fri, 1 Dec 2023 16:46:09 +0000
Subject: [PATCH v3] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <20231125184422.12315-1-krzysztof.kozlowski@linaro.org>
References: <20231125184422.12315-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231201-thrive-gully-5260ab07b352@spud>

On Sat, Nov 25, 2023 at 07:44:22PM +0100, Krzysztof Kozlowski wrote:
> +Indentation
> +-----------
> +
> +1. Use indentation according to :ref:`codingstyle`.

One thing Jonathan mentioned before to me was to drop this :ref: stuff.
| > +:ref:`devicetree-abi` more information on the ABI.
| 
| ...can just be written as "Please see
| Documentation/devicetree/bindings/ABI.rst".  The cross-reference link
| will be generated as expected, and readers of the plain-text docs don't
| have to go grepping to find the reference.
https://lore.kernel.org/all/87bki23rbx.fsf at meer.lwn.net/

Apparently the doc generation scripting can automagically do the right
thing here:
https://docs.kernel.org/process/maintainer-soc.html#devicetree-abi-stability

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/d588d73c/attachment.sig>

From eberhard.stoll at gmx.de  Fri Dec  1 08:55:18 2023
From: eberhard.stoll at gmx.de (Eberhard Stoll)
Date: Fri, 1 Dec 2023 17:55:18 +0100
Subject: [PATCH v3] serial: imx: fix tx statemachine deadlock
In-Reply-To: <e770c302-2fef-40ba-b955-dc8c54c8727c@prevas.se>
References: <2023112434-winter-embezzle-1b46@gregkh>
 <AM0PR09MB26758F651BC1B742EB45775995B8A@AM0PR09MB2675.eurprd09.prod.outlook.com>
 <a283cb15-d740-4f94-a81e-0147c2035cf7@prevas.dk>
 <e770c302-2fef-40ba-b955-dc8c54c8727c@prevas.se>
Message-ID: <a9c6d8e7-a014-4e04-9c6a-617235130c7b@gmx.de>



On 30.11.23 10:09, Rasmus Villemoes wrote:
> On 24/11/2023 14.37, Rasmus Villemoes wrote:
>> On 24/11/2023 14.11, Paul Geurts wrote:
>>> When using the serial port as RS485 port, the tx statemachine is used to
>>> control the RTS pin to drive the RS485 transceiver TX_EN pin. When the
>>> TTY port is closed in the middle of a transmission (for instance during
>>> userland application crash), imx_uart_shutdown disables the interface
>>> and disables the Transmission Complete interrupt. afer that,
>>> imx_uart_stop_tx bails on an incomplete transmission, to be retriggered
>>> by the TC interrupt. This interrupt is disabled and therefore the tx
>>> statemachine never transitions out of SEND. The statemachine is in
>>> deadlock now, and the TX_EN remains low, making the interface useless.
>>>
>>> imx_uart_stop_tx now checks for incomplete transmission AND whether TC
>>> interrupts are enabled before bailing to be retriggered. This makes sure
>>> the state machine handling is reached, and is properly set to
>>> WAIT_AFTER_SEND.
>>>
>>> Fixes: cb1a60923609 ("serial: imx: implement rts delaying for rs485")
>>> Signed-off-by: Paul Geurts <paul_geurts at live.nl>
>>
>> Hi Paul
>>
>> Interestingly, both Eberhard (cc'ed) and I have hit similar problems in
>> this driver recently. See the thread
>> https://lore.kernel.org/lkml/20231120132256.136625-1-rasmus.villemoes at prevas.dk/
>> .
>>
>> It is possible that this also fixes the problems I/we saw, but I can't
>> get around to testing until sometime next week.
>
> This also seems to fix the problem I had when switching to rs232 and
> back to rs485, and I agree that it seems to be a cleaner fix than mine.
>
> I also tried reproducing what Eberhard reported, and I think I managed
> to do that, and at least my way of reproducing the tx lockup also seems
> to be fixed by this patch. Eberhard, can you test this patch in your setup?
>
> In any case,
>
> Tested-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk>
>
> Rasmus
>

Yes, it also works for my test setup!

Tested-by: Eberhard Stoll <eberhard.stoll at gmx.de>

Best regards
Eberhard



From roy.zang at nxp.com  Fri Dec  1 08:55:46 2023
From: roy.zang at nxp.com (Roy Zang)
Date: Fri, 1 Dec 2023 16:55:46 +0000
Subject: [PATCH v5 1/4] PCI: layerscape: Add function pointer for
 exit_from_l2()
In-Reply-To: <20231201161712.1645987-2-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
 <20231201161712.1645987-2-Frank.Li@nxp.com>
Message-ID: <AM0PR04MB595614CA6B295B42D4FDE7BE8B81A@AM0PR04MB5956.eurprd04.prod.outlook.com>

> From: Frank Li <frank.li at nxp.com>
> Subject: [PATCH v5 1/4] PCI: layerscape: Add function pointer for exit_from_l2()
> 
> Since difference SoCs require different sequence for exiting L2, let's add a
> separate "exit_from_l2()" callback. This callback can be used to execute SoC
> specific sequence.
> 
> Change ls_pcie_exit_from_l2() return value from void to int. Return error if
> exit_from_l2() failure at exit resume flow.
> 
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
Acked-by:  Roy Zang <Roy.Zang at nxp.com>
Roy


From geert at linux-m68k.org  Fri Dec  1 08:51:23 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 1 Dec 2023 17:51:23 +0100
Subject: [PATCH 06/14] pinctrl: renesas: rzg2l: Add pin configuration
 support for pinmux groups
In-Reply-To: <20231120070024.4079344-7-claudiu.beznea.uj@bp.renesas.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com> <20231120070024.4079344-7-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdU6-jHrT6DjFkwHoBytOzT=E9=dujWBq0v++ow4CJW==g@mail.gmail.com>

Hi Claudiu,

On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> On RZ/G3S different Ethernet pins needs to be configured with different
> settings (e.g. power-source need to be set, RGMII TXC, TX_CTL pins need
> output-enable). Commit adjust driver to allow specifying pin configuration
> for pinmux groups. With this DT settings like the following are taken
> into account by driver:
>
> eth0_pins: eth0 {
>         tx_ctl {
>                 pinmux = <RZG2L_PORT_PINMUX(1, 1, 1)>;  /* ET0_TX_CTL */
>                 power-source = <1800>;
>                 output-enable;
>                 drive-strength-microamp = <5200>;
>         };
> };
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Thanks for your patch!

> --- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
> +++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
> @@ -376,8 +376,11 @@ static int rzg2l_dt_subnode_to_map(struct pinctrl_dev *pctldev,
>                 goto done;
>         }
>
> -       if (num_pinmux)
> +       if (num_pinmux) {
>                 nmaps += 1;
> +               if (num_configs)
> +                       nmaps += 1;

I think this would be more readable, and better follow the style of
the surrounding statements, if this new check would not be nested
under the num_pinmux check.

> +       }
>
>         if (num_pins)
>                 nmaps += num_pins;

Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From roy.zang at nxp.com  Fri Dec  1 08:57:54 2023
From: roy.zang at nxp.com (Roy Zang)
Date: Fri, 1 Dec 2023 16:57:54 +0000
Subject: [PATCH v5 2/4] PCI: layerscape: Add suspend/resume for ls1021a
In-Reply-To: <20231201161712.1645987-3-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
 <20231201161712.1645987-3-Frank.Li@nxp.com>
Message-ID: <AM0PR04MB59568824DB8F8509363471B38B81A@AM0PR04MB5956.eurprd04.prod.outlook.com>

> From: Frank Li <frank.li at nxp.com>
> Subject: [PATCH v5 2/4] PCI: layerscape: Add suspend/resume for ls1021a
> 
> Add suspend/resume support for Layerscape LS1021a.
> 
> In the suspend path, PME_Turn_Off message is sent to the endpoint to
> transition the link to L2/L3_Ready state. In this SoC, there is no way to check if
> the controller has received the PME_To_Ack from the endpoint or not. So to be
> on the safer side, the driver just waits for PCIE_PME_TO_L2_TIMEOUT_US
> before asserting the SoC specific PMXMTTURNOFF bit to complete the
> PME_Turn_Off handshake. Then the link would enter L2/L3 state depending on
> the VAUX supply.
> 
> In the resume path, the link is brought back from L2 to L0 by doing a software
> reset.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
Acked-by:  Roy Zang <Roy.Zang at nxp.com>
Roy


From heiko at sntech.de  Fri Dec  1 08:58:10 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 17:58:10 +0100
Subject: [PATCH 4/4] arm64: dts: rockchip: add rk3588 spi aliases to soc dtsi
In-Reply-To: <20231201165810.334212-1-heiko@sntech.de>
References: <20231201165810.334212-1-heiko@sntech.de>
Message-ID: <20231201165810.334212-5-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

The spi controllers on rk3588 are named spi0 - spi4. Board schematics
also use these exact numbers and we want those names to also reflect
in the OS devices because everything else would just cause confusion.
Userspace spi access is a thing afterall.

So instead of having each board repeating their list of spi aliases, move
them to the soc dtsi, as previous Rockchip soc like the rk356x do already.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index a59407466746..7863aded672b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -43,6 +43,11 @@ aliases {
 		serial7 = &uart7;
 		serial8 = &uart8;
 		serial9 = &uart9;
+		spi0 = &spi0;
+		spi1 = &spi1;
+		spi2 = &spi2;
+		spi3 = &spi3;
+		spi4 = &spi4;
 	};
 
 	cpus {
-- 
2.39.2



From heiko at sntech.de  Fri Dec  1 08:58:07 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 17:58:07 +0100
Subject: [PATCH 1/4] arm64: dts: rockchip: move rk3588 serial aliases to soc dtsi
In-Reply-To: <20231201165810.334212-1-heiko@sntech.de>
References: <20231201165810.334212-1-heiko@sntech.de>
Message-ID: <20231201165810.334212-2-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

The serial ports on rk3588 are named uart0 - uart9. Board schematics
also use these exact numbers and we want those names to also reflect
in the OS devices because everything else would just cause confusion.

So instead of having each board repeating their list of serial aliases
move them to the soc dtsi, as all previous Rockchip soc do already.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
---
 .../boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts   |  4 ----
 .../boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts   |  4 ----
 arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts    |  1 -
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts   |  1 -
 .../boot/dts/rockchip/rk3588-orangepi-5-plus.dts    |  1 -
 arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts |  1 -
 arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts     |  1 -
 arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |  2 --
 .../boot/dts/rockchip/rk3588s-indiedroid-nova.dts   |  1 -
 .../boot/dts/rockchip/rk3588s-khadas-edge2.dts      |  1 -
 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts |  1 -
 arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts    |  1 -
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi           | 13 +++++++++++++
 13 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts b/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts
index b51543892078..be6a4f4f90f6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts
@@ -12,10 +12,6 @@ / {
 	compatible = "edgeble,neural-compute-module-6a-io",
 		     "edgeble,neural-compute-module-6a", "rockchip,rk3588";
 
-	aliases {
-		serial2 = &uart2;
-	};
-
 	chosen {
 		stdout-path = "serial2:1500000n8";
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts b/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts
index 9933765e4097..96a18077f26f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts
@@ -12,10 +12,6 @@ / {
 	compatible = "edgeble,neural-compute-module-6b-io",
 		     "edgeble,neural-compute-module-6b", "rockchip,rk3588";
 
-	aliases {
-		serial2 = &uart2;
-	};
-
 	chosen {
 		stdout-path = "serial2:1500000n8";
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
index b9d789d57862..a36d4fcd9b1d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
@@ -17,7 +17,6 @@ / {
 
 	aliases {
 		mmc0 = &sdhci;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
index 97af4f912828..612107615e66 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
@@ -19,7 +19,6 @@ / {
 	aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
index 298c183d6f4f..3e660ff6cd5f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
@@ -19,7 +19,6 @@ / {
 	aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
index 5c59f9571dce..c7cd57609bc2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
@@ -19,7 +19,6 @@ / {
 	aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
index 741f631db345..e302eeb6ce5a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
@@ -14,7 +14,6 @@ aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 		mmc2 = &sdio;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
index 9570b34aca2e..25a0ca73a8f7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
@@ -19,8 +19,6 @@ / {
 	aliases {
 		ethernet0 = &gmac1;
 		mmc0 = &sdhci;
-		serial2 = &uart2;
-		serial9 = &uart9;
 	};
 
 	fan: pwm-fan {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts b/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts
index 60f00ceb630e..dc677f29a9c7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts
@@ -44,7 +44,6 @@ aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 		mmc2 = &sdio;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
index 82478a452533..f53e993c785e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
@@ -12,7 +12,6 @@ / {
 
 	aliases {
 		mmc0 = &sdhci;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 8f399c4317bd..52ec9cb38f57 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -14,7 +14,6 @@ / {
 
 	aliases {
 		mmc0 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
index 8347adcbd003..73cf97062a09 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
@@ -14,7 +14,6 @@ / {
 	aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	analog-sound {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 8aa0499f9b03..d854536a44b8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -18,6 +18,19 @@ / {
 	#address-cells = <2>;
 	#size-cells = <2>;
 
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+		serial6 = &uart6;
+		serial7 = &uart7;
+		serial8 = &uart8;
+		serial9 = &uart9;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
2.39.2



From heiko at sntech.de  Fri Dec  1 08:58:09 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 17:58:09 +0100
Subject: [PATCH 3/4] arm64: dts: rockchip: add rk3588 gpio aliases to soc dtsi
In-Reply-To: <20231201165810.334212-1-heiko@sntech.de>
References: <20231201165810.334212-1-heiko@sntech.de>
Message-ID: <20231201165810.334212-4-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

The gpio controllers on rk3588 are named gpio0 - gpio4. Board schematics
also use these exact numbers and we want those names to also reflect
in the OS devices because everything else would just cause confusion.
Userspace gpio access is a thing afterall.

So instead of having each board repeating their list of gpio aliases move
them to the soc dtsi, as previous Rockchip soc like the rk356x do already.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 47512c39e55a..a59407466746 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -19,6 +19,11 @@ / {
 	#size-cells = <2>;
 
 	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
-- 
2.39.2



From heiko at sntech.de  Fri Dec  1 08:58:08 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 17:58:08 +0100
Subject: [PATCH 2/4] arm64: dts: rockchip: add rk3588 i2c aliases to soc dtsi
In-Reply-To: <20231201165810.334212-1-heiko@sntech.de>
References: <20231201165810.334212-1-heiko@sntech.de>
Message-ID: <20231201165810.334212-3-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

The i2c controllers on rk3588 are named i2c0 - i2c8. Board schematics
also use these exact numbers and we want those names to also reflect
in the OS devices because everything else would just cause confusion.
Userspace i2c access is a thing afterall.

So instead of having each board repeating their list of i2c aliases
move them to the soc dtsi, as all previous Rockchip soc do already.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index d854536a44b8..47512c39e55a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -19,6 +19,15 @@ / {
 	#size-cells = <2>;
 
 	aliases {
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+		i2c7 = &i2c7;
+		i2c8 = &i2c8;
 		serial0 = &uart0;
 		serial1 = &uart1;
 		serial2 = &uart2;
-- 
2.39.2



From heiko at sntech.de  Fri Dec  1 08:58:06 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 17:58:06 +0100
Subject: [PATCH 0/4] arm64: dts: rockchip: aliases for core busses in main dtsi
Message-ID: <20231201165810.334212-1-heiko@sntech.de>

Placement of aliases is cause for a lot of discussion :-).
Most recently in [0]. And while devices such as mmc controllers do have
names not following any numbers, this is different for the core
busses/devices like serial, i2c, gpio, spi.

All of those start at number 0 and increment then. And all pieces of
documentation like soc manuals, device schematics as well as pin-header
descriptions for SBCs also use these numbers to identify the controller
instance.

All previous Rockchip socs also carry those core busses in the main dtsi
so that not every board needs to have the exact same aliases defined.


[0] https://lore.kernel.org/all/4762834.KRxA6XjA2N at diego/

Heiko Stuebner (4):
  arm64: dts: rockchip: move rk3588 serial aliases to soc dtsi
  arm64: dts: rockchip: add rk3588 i2c aliases to soc dtsi
  arm64: dts: rockchip: add rk3588 gpio aliases to soc dtsi
  arm64: dts: rockchip: add rk3588 spi aliases to soc dtsi

 .../dts/rockchip/rk3588-edgeble-neu6a-io.dts  |  4 ---
 .../dts/rockchip/rk3588-edgeble-neu6b-io.dts  |  4 ---
 .../boot/dts/rockchip/rk3588-evb1-v10.dts     |  1 -
 .../boot/dts/rockchip/rk3588-nanopc-t6.dts    |  1 -
 .../dts/rockchip/rk3588-orangepi-5-plus.dts   |  1 -
 .../boot/dts/rockchip/rk3588-quartzpro64.dts  |  1 -
 .../boot/dts/rockchip/rk3588-rock-5b.dts      |  1 -
 .../boot/dts/rockchip/rk3588-turing-rk1.dtsi  |  2 --
 .../dts/rockchip/rk3588s-indiedroid-nova.dts  |  1 -
 .../dts/rockchip/rk3588s-khadas-edge2.dts     |  1 -
 .../boot/dts/rockchip/rk3588s-orangepi-5.dts  |  1 -
 .../boot/dts/rockchip/rk3588s-rock-5a.dts     |  1 -
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 32 +++++++++++++++++++
 13 files changed, 32 insertions(+), 19 deletions(-)

-- 
2.39.2



From roy.zang at nxp.com  Fri Dec  1 08:58:32 2023
From: roy.zang at nxp.com (Roy Zang)
Date: Fri, 1 Dec 2023 16:58:32 +0000
Subject: [PATCH v5 3/4] PCI: layerscape(ep): Rename pf_* as pf_lut_*
In-Reply-To: <20231201161712.1645987-4-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
 <20231201161712.1645987-4-Frank.Li@nxp.com>
Message-ID: <AM0PR04MB595652FB78FC4E6ED103B1B38B81A@AM0PR04MB5956.eurprd04.prod.outlook.com>

> From: Frank Li <frank.li at nxp.com>
> Subject: [PATCH v5 3/4] PCI: layerscape(ep): Rename pf_* as pf_lut_*
> 
> 'pf' and 'lut' is just difference name in difference chips, but basic it is a MMIO
> base address plus an offset.
> 
> Rename it to avoid duplicate pf_* and lut_* in driver.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
Acked-by:  Roy Zang <Roy.Zang at nxp.com>
Roy


From broonie at kernel.org  Fri Dec  1 08:58:55 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 1 Dec 2023 16:58:55 +0000
Subject: [PATCH V15 1/8] arm64/sysreg: Add BRBE registers and fields
In-Reply-To: <20231201053906.1261704-2-anshuman.khandual@arm.com>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
 <20231201053906.1261704-2-anshuman.khandual@arm.com>
Message-ID: <fd278f4e-0632-4474-8609-7711ad725f85@sirena.org.uk>

On Fri, Dec 01, 2023 at 11:08:59AM +0530, Anshuman Khandual wrote:

This looks good apart from a few small omissions:

> +SysregFields BRBINFx_EL1

> +Enum	13:8		TYPE
> +	0b000000	UNCOND_DIRECT
> +	0b000001	INDIRECT
> +	0b000010	DIRECT_LINK
> +	0b000011	INDIRECT_LINK
> +	0b000101	RET
> +	0b000111	ERET
> +	0b001000	COND_DIRECT
> +	0b100001	DEBUG_HALT
> +	0b100010	CALL
> +	0b100011	TRAP
> +	0b100100	SERROR
> +	0b100110	INSN_DEBUG
> +	0b100111	DATA_DEBUG
> +	0b101010	ALIGN_FAULT
> +	0b101011	INSN_FAULT
> +	0b101100	DATA_FAULT
> +	0b101110	IRQ
> +	0b101111	FIQ
> +	0b111001	DEBUG_EXIT
> +EndEnum

DDI0601 2023-09 also defines 0b110000 as an IMPLEMENTATION DEFINED
exception to EL3.

> +SysregFields	BRBCR_ELx
> +Res0	63:24
> +Field	23 	EXCEPTION
> +Field	22 	ERTN
> +Res0	21:9

DDI0601 2023-09 defines bit 9 as FZPSS.

> +Sysreg	BRBINFINJ_EL1	2	1	9	1	0

> +Enum	13:8		TYPE
> +	0b000000	UNCOND_DIRECT
> +	0b000001	INDIRECT
> +	0b000010	DIRECT_LINK
> +	0b000011	INDIRECT_LINK
> +	0b000101	RET
> +	0b000111	ERET
> +	0b001000	COND_DIRECT
> +	0b100001	DEBUG_HALT
> +	0b100010	CALL
> +	0b100011	TRAP
> +	0b100100	SERROR
> +	0b100110	INSN_DEBUG
> +	0b100111	DATA_DEBUG
> +	0b101010	ALIGN_FAULT
> +	0b101011	INSN_FAULT
> +	0b101100	DATA_FAULT
> +	0b101110	IRQ
> +	0b101111	FIQ
> +	0b111001	DEBUG_EXIT
> +EndEnum

DDI0601 2023-09 also defines 0b11000 as IMPLEMENTATION DEFINED exception
to EL3.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/253887c8/attachment.sig>

From roy.zang at nxp.com  Fri Dec  1 09:00:26 2023
From: roy.zang at nxp.com (Roy Zang)
Date: Fri, 1 Dec 2023 17:00:26 +0000
Subject: [PATCH v5 4/4] PCI: layerscape: Add suspend/resume for ls1043a
In-Reply-To: <20231201161712.1645987-5-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
 <20231201161712.1645987-5-Frank.Li@nxp.com>
Message-ID: <AM0PR04MB5956E863DA1295E96EC5DBC68B81A@AM0PR04MB5956.eurprd04.prod.outlook.com>

> From: Frank Li <frank.li at nxp.com>
> Subject: [PATCH v5 4/4] PCI: layerscape: Add suspend/resume for ls1043a
> 
> Add suspend/resume support for Layerscape LS1043a.
> 
> In the suspend path, PME_Turn_Off message is sent to the endpoint to
> transition the link to L2/L3_Ready state. In this SoC, there is no way to check if
> the controller has received the PME_To_Ack from the endpoint or not. So to be
> on the safer side, the driver just waits for PCIE_PME_TO_L2_TIMEOUT_US
> before asserting the SoC specific PMXMTTURNOFF bit to complete the
> PME_Turn_Off handshake. Then the link would enter L2/L3 state depending on
> the VAUX supply.
> 
> In the resume path, the link is brought back from L2 to L0 by doing a software
> reset.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
Acked-by:  Roy Zang <Roy.Zang at nxp.com>
Roy


From seanjc at google.com  Fri Dec  1 09:04:51 2023
From: seanjc at google.com (Sean Christopherson)
Date: Fri, 1 Dec 2023 09:04:51 -0800
Subject: [PATCH v2 2/4] mm: Add poison error check in fixup_user_fault()
 for mapped pfn
In-Reply-To: <20231123003513.24292-3-ankita@nvidia.com>
References: <20231123003513.24292-1-ankita@nvidia.com> <20231123003513.24292-3-ankita@nvidia.com>
Message-ID: <ZWoSM_0xLJQo8De5@google.com>

On Thu, Nov 23, 2023, ankita at nvidia.com wrote:
> From: Ankit Agrawal <ankita at nvidia.com>
> 
> The fixup_user_fault() currently does not expect a VM_FAULT_HWPOISON
> and hence does not check for it while calling vm_fault_to_errno(). Since
> we now have a new code path which can trigger such case, change
> fixup_user_fault to look for VM_FAULT_HWPOISON.
> 
> Also make hva_to_pfn_remapped check for -EHWPOISON and communicate the
> poison fault up to the user_mem_abort().

I would much prefer the KVM change be split out to its own patch, I see no
reason why it needs to be bundled with the fixup_user_fault() change.  KVM will
set pfn to KVM_PFN_ERR_FAULT before and after the fixup_user_fault() change.

> Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
> ---
>  mm/gup.c            | 2 +-
>  virt/kvm/kvm_main.c | 6 ++++++
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index 231711efa390..b78af20a0f52 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1414,7 +1414,7 @@ int fixup_user_fault(struct mm_struct *mm,
>  	}
>  
>  	if (ret & VM_FAULT_ERROR) {
> -		int err = vm_fault_to_errno(ret, 0);
> +		int err = vm_fault_to_errno(ret, FOLL_HWPOISON);
>  
>  		if (err)
>  			return err;
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 486800a7024b..2ff067f21a7c 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2731,6 +2731,12 @@ kvm_pfn_t hva_to_pfn(unsigned long addr, bool atomic, bool interruptible,
>  		r = hva_to_pfn_remapped(vma, addr, write_fault, writable, &pfn);
>  		if (r == -EAGAIN)
>  			goto retry;
> +
> +		if (r == -EHWPOISON) {
> +			pfn = KVM_PFN_ERR_HWPOISON;
> +			goto exit;
> +		}
> +
>  		if (r < 0)
>  			pfn = KVM_PFN_ERR_FAULT;

I vote for

		if (r == -EHWPOISON)
			pfn = KVM_PFN_ERR_HWPOISON;
		else if (r < 0)
			pfn = KVM_PFN_ERR_FAULT;

or even opportunstically fix the < 0 weirdness:

		if (r == -EHWPOISON)
			pfn = KVM_PFN_ERR_HWPOISON;
		else if (r)
			pfn = KVM_PFN_ERR_FAULT;

It's rather confusing to see a goto in one error path but an effective fallthrough
in a different error path, i.e. gives the impression that KVM_PFN_ERR_HWPOISON
has some special behavior that doesn't apply to KVM_PFN_ERR_FAULT.


From geert at linux-m68k.org  Fri Dec  1 09:11:17 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 1 Dec 2023 18:11:17 +0100
Subject: [PATCH 07/14] pinctrl: renesas: rzg2l: Add support to select
 power source for Ethernet pins
In-Reply-To: <20231120070024.4079344-8-claudiu.beznea.uj@bp.renesas.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com> <20231120070024.4079344-8-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdWFDD=c7f-jbB88BjMa75VBhjSrVK-E0OYYQ-gr_hi-zQ@mail.gmail.com>

Hi Claudiu,

On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> For Ethernet pins GPIO controller available on RZ/G3S (but also on RZ/G2L)
> allows setting the power source. Based on the interface b/w Ethernet
> controller and Ethernet PHY and board design specific power source need to
> be selected. The GPIO controller allow 1.8V, 2.5V and 3.3V power source
> selection for Ethernet pins and this could be selected though ETHX_POC
> registers (X={0, 1}).
>
> Commit adjust the driver to support this and does proper instantiation
> for RZ/G3S and RZ/G2L SoC. On RZ/G2L only get operation has been tested
> at the moment.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Thanks for your patch!

> --- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
> +++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
> @@ -623,7 +632,16 @@ static int rzg2l_get_power_source(struct rzg2l_pinctrl *pctrl, u32 pin, u32 caps
>         if (pwr_reg < 0)
>                 return pwr_reg;
>
> -       return (readl(pctrl->base + pwr_reg) & PVDD_MASK) ? 1800 : 3300;

This removes the last user of PVDD_MASK. I guess it can be removed,
as all unused register bits are documented to read as zeroes.

> +       val = readl(pctrl->base + pwr_reg);

While these registers are documented to support access sizes of
8/16/32 bits on RZ/G3S, RZ/G2L is limited to 8 bits, so this should
have used readb() from the beginning.

> +       if (val == PVDD_1800)
> +               return 1800;
> +       if (val == PVDD_2500)
> +               return 2500;
> +       if (val == PVDD_3300)
> +               return 3300;
> +
> +       /* Should not happen. */
> +       return -EINVAL;

Please use a switch() statement.

>  }
>
>  static int rzg2l_set_power_source(struct rzg2l_pinctrl *pctrl, u32 pin, u32 caps, u32 ps)
> @@ -631,17 +649,27 @@ static int rzg2l_set_power_source(struct rzg2l_pinctrl *pctrl, u32 pin, u32 caps
>         const struct rzg2l_hwcfg *hwcfg = pctrl->data->hwcfg;
>         const struct rzg2l_register_offsets *regs = &hwcfg->regs;
>         int pwr_reg;
> +       u32 val;
>
>         if (caps & PIN_CFG_SOFT_PS) {
>                 pctrl->settings[pin].power_source = ps;
>                 return 0;
>         }
>
> +       if (ps == 1800)
> +               val = PVDD_1800;
> +       else if (ps == 2500)
> +               val = PVDD_2500;
> +       else if (ps == 3300)
> +               val = PVDD_3300;
> +       else
> +               return -EINVAL;

Please use a switch() statement.

> +
>         pwr_reg = rzg2l_caps_to_pwr_reg(regs, caps);
>         if (pwr_reg < 0)
>                 return pwr_reg;
>
> -       writel((ps == 1800) ? PVDD_1800 : PVDD_3300, pctrl->base + pwr_reg);
> +       writel(val, pctrl->base + pwr_reg);

writeb() for RZ/G2L.

>         pctrl->settings[pin].power_source = ps;
>
>         return 0;

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From francesco at dolcini.it  Fri Dec  1 09:15:43 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 18:15:43 +0100
Subject: [PATCH v2] arm64: defconfig: increase SERIAL_8250_NR_UARTS
Message-ID: <20231201171544.1901-1-francesco@dolcini.it>

Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
is not adequate for embedded systems that use SoCs where it's common to
have a large number of serial ports.

No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").

The need to increase this value was noticed while working with Toradex
Verdin AM62, this board has 4 serial UART instances available to the user
plus an internal one that is connected to a Bluetooth module. Without this
change the fifth UART connected to the BT module is not instantiated and BT
is not working.

Instead of increasing the number to the bare minimum (5) that would be
required to solve this specific issue, we increase this to 8 which seems a
more reasonable number to have in the defconfig and should cover more valid
use cases.

Cc: Tony Lindgren <tony at atomide.com>
Reviewed-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Francesco Dolcini <francesco at dolcini.it>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b60aa1f89343..ecd365cd1d87 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -448,6 +448,7 @@ CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=8
 CONFIG_SERIAL_8250_EXTENDED=y
 CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_8250_BCM2835AUX=y
-- 
2.39.2



From dsimic at manjaro.org  Fri Dec  1 09:19:51 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Fri, 01 Dec 2023 18:19:51 +0100
Subject: [PATCH 0/4] arm64: dts: rockchip: aliases for core busses in main
 dtsi
In-Reply-To: <20231201165810.334212-1-heiko@sntech.de>
References: <20231201165810.334212-1-heiko@sntech.de>
Message-ID: <034a3f8712f8405113a92a1e1969e94e@manjaro.org>

On 2023-12-01 17:58, Heiko Stuebner wrote:
> Placement of aliases is cause for a lot of discussion :-).
> Most recently in [0]. And while devices such as mmc controllers do have
> names not following any numbers, this is different for the core
> busses/devices like serial, i2c, gpio, spi.
> 
> All of those start at number 0 and increment then. And all pieces of
> documentation like soc manuals, device schematics as well as pin-header
> descriptions for SBCs also use these numbers to identify the controller
> instance.
> 
> All previous Rockchip socs also carry those core busses in the main 
> dtsi
> so that not every board needs to have the exact same aliases defined.
> 
> [0] https://lore.kernel.org/all/4762834.KRxA6XjA2N at diego/
> 
> Heiko Stuebner (4):
>   arm64: dts: rockchip: move rk3588 serial aliases to soc dtsi
>   arm64: dts: rockchip: add rk3588 i2c aliases to soc dtsi
>   arm64: dts: rockchip: add rk3588 gpio aliases to soc dtsi
>   arm64: dts: rockchip: add rk3588 spi aliases to soc dtsi
> 
>  .../dts/rockchip/rk3588-edgeble-neu6a-io.dts  |  4 ---
>  .../dts/rockchip/rk3588-edgeble-neu6b-io.dts  |  4 ---
>  .../boot/dts/rockchip/rk3588-evb1-v10.dts     |  1 -
>  .../boot/dts/rockchip/rk3588-nanopc-t6.dts    |  1 -
>  .../dts/rockchip/rk3588-orangepi-5-plus.dts   |  1 -
>  .../boot/dts/rockchip/rk3588-quartzpro64.dts  |  1 -
>  .../boot/dts/rockchip/rk3588-rock-5b.dts      |  1 -
>  .../boot/dts/rockchip/rk3588-turing-rk1.dtsi  |  2 --
>  .../dts/rockchip/rk3588s-indiedroid-nova.dts  |  1 -
>  .../dts/rockchip/rk3588s-khadas-edge2.dts     |  1 -
>  .../boot/dts/rockchip/rk3588s-orangepi-5.dts  |  1 -
>  .../boot/dts/rockchip/rk3588s-rock-5a.dts     |  1 -
>  arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 32 +++++++++++++++++++
>  13 files changed, 32 insertions(+), 19 deletions(-)

Thank you for cleaning this up.  Here's my Reviewed-by for the entire 
series:

Reviewed-by: Dragan Simic <dsimic at manjaro.org>


From didi.debian at cknow.org  Fri Dec  1 09:23:27 2023
From: didi.debian at cknow.org (Diederik de Haas)
Date: Fri, 01 Dec 2023 18:23:27 +0100
Subject: [PATCH 3/4] arm64: dts: rockchip: add rk3588 gpio aliases to soc dtsi
In-Reply-To: <20231201165810.334212-4-heiko@sntech.de>
References: <20231201165810.334212-1-heiko@sntech.de>
 <20231201165810.334212-4-heiko@sntech.de>
Message-ID: <9053330.WAzO9JGhZe@bagend>

On Friday, 1 December 2023 17:58:09 CET Heiko Stuebner wrote:
> So instead of having each board repeating their list of gpio aliases move
> them to the soc dtsi

Nit:
To prevent each board repeating their list of gpio aliases, define them in the 
soc dtsi

Patch 1 did in fact *move* items, but patch 2-4 only added them to the soc 
dtsi, which I assume is to prevent them being added to each board.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/11f94618/attachment-0001.sig>

From heiko at sntech.de  Fri Dec  1 09:25:01 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Fri, 01 Dec 2023 18:25:01 +0100
Subject: [PATCH 3/4] arm64: dts: rockchip: add rk3588 gpio aliases to soc dtsi
In-Reply-To: <9053330.WAzO9JGhZe@bagend>
References: <20231201165810.334212-1-heiko@sntech.de>
 <20231201165810.334212-4-heiko@sntech.de> <9053330.WAzO9JGhZe@bagend>
Message-ID: <6477626.MSiuQNM8U4@diego>

Am Freitag, 1. Dezember 2023, 18:23:27 CET schrieb Diederik de Haas:
> On Friday, 1 December 2023 17:58:09 CET Heiko Stuebner wrote:
> > So instead of having each board repeating their list of gpio aliases move
> > them to the soc dtsi
> 
> Nit:
> To prevent each board repeating their list of gpio aliases, define them in the 
> soc dtsi
> 
> Patch 1 did in fact *move* items, but patch 2-4 only added them to the soc 
> dtsi, which I assume is to prevent them being added to each board.

ah yes, the magic of doing similar things in bulk, thanks for catching that :-)




From geert at linux-m68k.org  Fri Dec  1 09:25:32 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 1 Dec 2023 18:25:32 +0100
Subject: [PATCH 08/14] pinctrl: renesas: rzg2l: Add output enable support
In-Reply-To: <20231120070024.4079344-9-claudiu.beznea.uj@bp.renesas.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com> <20231120070024.4079344-9-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdXygjeHvrSB=KpVB4n1BTAinvNLL+AmjRhERy+2QbJMiA@mail.gmail.com>

Hi Claudiu,

Thanks for your patch!

On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> Some of the Ethernet pins on RZ/G3S (but also valid for RZ/G2L) need to
> have direction of the IO buffer set as output for Ethernet to work
> properly. On RZ/G3S these pins are P1_0/P7_0, P1_1/P7_1 with could have
> the following Ethernet functions: TXC/TX_CLK or TX_CTL/TX_EN. To be able
> to configure this the output enable has been implemented. This is
> implemented with 2 per-platform read/write functions to be able to simply
> validate the pins supporting this on a platform basis. Moreover, on RZ/G2L
> the register though which these settings could be done is 8 bits long
> whereas on RZ/G3S this is a 32 bit register. The Ethernet pins supporting
> OEN are different. These differences could be handled in platform specific
> OEN read/write functions.

These registers are documented to support access sizes of 8/16/32 bits
on RZ/G3S.  Hence you don't need to differentiate, but can just use
8-bit accesses on all platforms.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From justin.chen at broadcom.com  Fri Dec  1 09:25:59 2023
From: justin.chen at broadcom.com (Justin Chen)
Date: Fri, 1 Dec 2023 09:25:59 -0800
Subject: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
In-Reply-To: <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
References: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
 <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
Message-ID: <81af85b4-5274-4362-9413-890425c60524@broadcom.com>



On 12/1/2023 1:12 AM, Ard Biesheuvel wrote:
> On Fri, 1 Dec 2023 at 00:48, Justin Chen <justin.chen at broadcom.com> wrote:
>>
>> Hello,
>>
>> Ran into an odd bug that I am unsure what the solution is. Tested a few
>> kernels versions and they all fail the same.
>>
>> FUNCTION_GRAPH_FP_TEST was enabled with 953f534a7ed6 ("ARM: ftrace:
>> enable HAVE_FUNCTION_GRAPH_FP_TEST"). This test fails when
>> UNWINDER_FRAME_POINTER is enabled. Enable function_graph tracer and you
>> should see a failure similar to below.
>>
>> [   63.817239] ------------[ cut here ]------------
>> [   63.822006] WARNING: CPU: 3 PID: 1185 at kernel/trace/fgraph.c:195
>> ftrace_return_to_handler+0x228/0x374
>> [   63.831645] Bad frame pointer: expected d1e0df40, received d1e0df48
>> [   63.831645]   from func packet_setsockopt return to c0b558f4
>> [   63.843801] Modules linked in: bdc udc_core
>> [   63.848246] CPU: 3 PID: 1185 Comm: udhcpc Not tainted
>> 6.1.53-0.1pre-gf0bc552d12f8 #33
>> [   63.856209] Hardware name: Broadcom STB (Flattened Device Tree)
>> [   63.862227] Backtrace:
>> [   63.864761]  dump_backtrace from show_stack+0x20/0x24
>> [   63.869982]  r7:c031cd8c r6:00000009 r5:00000013 r4:c11c7fac
>> [   63.875736]  show_stack from dump_stack_lvl+0x48/0x54
>> [   63.880929]  dump_stack_lvl from dump_stack+0x18/0x1c
>> [   63.886111]  r5:000000c3 r4:c11bd92c
>> [   63.889764]  dump_stack from __warn+0x88/0x130
>> [   63.894339]  __warn from warn_slowpath_fmt+0x140/0x198
>> [   63.899631]  r8:d1e0deac r7:c11bd958 r6:c031cd8c r5:c11bd92c r4:00000000
>> [   63.906431]  warn_slowpath_fmt from ftrace_return_to_handler+0x228/0x374
>> [   63.913294]  r8:c3a8d840 r7:00000002 r6:d1e0df48 r5:c2377a94 r4:c269a400
>> [   63.920095]  ftrace_return_to_handler from return_to_handler+0xc/0x18
>> [   63.926699]  r8:c0cd8ed0 r7:00000008 r6:c418c500 r5:00000004 r4:00000107
>> [   63.933500]  __sys_setsockopt from return_to_handler+0x0/0x18
>> [   63.939415]  r8:c02002bc r7:00000126 r6:00000003 r5:00000000 r4:00000004
>> [   63.946217]  sys_setsockopt from return_to_handler+0x0/0x18
>> [   63.952053] ---[ end trace 0000000000000000 ]---
>>
>> Sure enough the top of the parent stack is off by 8. (Tested with
>> gcc6.3/gcc8.3/gcc12.3)
>> 00006dcc <packet_setsockopt>:
>>       6dcc:       e1a0c00d        mov     ip, sp
>>       6dd0:       e24dd008        sub     sp, sp, #8 <======
>>       6dd4:       e92ddff0        push    {r4, r5, r6, r7, r8, r9, sl,
>> fp, ip, lr, pc}
>>       6dd8:       e24cb00c        sub     fp, ip, #12
>>       6ddc:       e24dd06c        sub     sp, sp, #108    @ 0x6c
>>       6de0:       e52de004        push    {lr}            @ (str lr, [sp,
>> #-4]!)
>>       6de4:       ebfffffe        bl      0 <__gnu_mcount_nc>
>>
>> I'm not quite sure why gcc is putting this extra 8 byte frame (maybe
>> some optimization?), but it isn't being accounted for thus the
>> FUNCTION_GRAPH_FP_TEST for arm fails. Note that only some functions do
>> this. Function graph works with FUNCTION_GRAPH_FP_TEST disabled, so it
>> looks the test is hitting false positives.
>>
> 
> Thanks for the report.
> 
> It appears the sub instruction at 0x6dd0 correctly accounts for the
> extra 8 bytes, so the frame pointer is valid. So it is our assumption
> that there are no gaps between the stack frames is invalid.

Thanks for the assistance. The gap between the stack frame depends on 
the function. Most do not have a gap. Some have 8 (as shown above), some 
have 12. A single assumption here is not going to work. I'm having a 
hard time finding out the reasoning for this gap. I tried disabling a 
bunch of gcc flags as well as -O2 and the gap still exists.

Thanks,
Justin

> 
> Could you try the following change please?
> 
> --- a/arch/arm/kernel/ftrace.c
> +++ b/arch/arm/kernel/ftrace.c
> @@ -235,8 +235,12 @@
>                  return;
> 
>          if (IS_ENABLED(CONFIG_UNWINDER_FRAME_POINTER)) {
> -               /* FP points one word below parent's top of stack */
> -               frame_pointer += 4;
> +               /*
> +                * The top of stack of the parent is recorded in the stack
> +                * frame at offset [fp, #-8].
> +                */
> +               get_kernel_nofault(frame_pointer,
> +                                  (unsigned long *)(frame_pointer - 8));
>          } else {
>                  struct stackframe frame = {
>                          .fp = frame_pointer,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/8b845336/attachment.p7s>

From masahiroy at kernel.org  Fri Dec  1 09:29:22 2023
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Sat, 2 Dec 2023 02:29:22 +0900
Subject: [PATCH v8 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231130203358.879796-3-sjg@chromium.org>
References: <20231130203358.879796-1-sjg@chromium.org> <20231130203358.879796-3-sjg@chromium.org>
Message-ID: <CAK7LNARABFKSqY=f1uDGem2UqkTwGUQ9q3rDZ4NbXyuEAtsLdw@mail.gmail.com>

On Fri, Dec 1, 2023 at 5:34?AM Simon Glass <sjg at chromium.org> wrote:
>
> Add a script which produces a Flat Image Tree (FIT), a single file
> containing the built kernel and associated devicetree files.
> Compression defaults to gzip which gives a good balance of size and
> performance.
>
> The files compress from about 86MB to 24MB using this approach.
>
> The FIT can be used by bootloaders which support it, such as U-Boot
> and Linuxboot. It permits automatic selection of the correct
> devicetree, matching the compatible string of the running board with
> the closest compatible string in the FIT. There is no need for
> filenames or other workarounds.
>
> Add a 'make image.fit' build target for arm64, as well.
>
> The FIT can be examined using 'dumpimage -l'.
>
> This features requires pylibfdt (use 'pip install libfdt'). It also
> requires compression utilities for the algorithm being used. Supported
> compression options are the same as the Image.xxx files. For now there
> is no way to change the compression other than by editing the rule for
> $(obj)/image.fit
>
> While FIT supports a ramdisk / initrd, no attempt is made to support
> this here, since it must be built separately from the Linux build.
>
> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---
>
> Changes in v8:
> - Drop compatible string in FDT node
> - Correct sorting of MAINTAINERS to before ARM64 PORT
> - Turn compress part of the make_fit.py comment in to a sentence
> - Add two blank lines before parse_args() and setup_fit()
> - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> - Use '$(<D)/dts' instead of '$(dir $<)dts'
> - Add 'mkimage' details Documentation/process/changes.rst
> - Allow changing the compression used
> - Tweak cover letter since there is only one clean-up patch
>
> Changes in v7:
> - Add Image as a dependency of image.fit
> - Drop kbuild tag
> - Add dependency on dtbs
> - Drop unnecessary path separator for dtbs
> - Rebase to -next
>
> Changes in v5:
> - Drop patch previously applied
> - Correct compression rule which was broken in v4
>
> Changes in v4:
> - Use single quotes for UIMAGE_NAME
>
> Changes in v3:
> - Drop temporary file image.itk
> - Drop patch 'Use double quotes for image name'
> - Drop double quotes in use of UIMAGE_NAME
> - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> - Avoid hard-coding "arm64" for the DT architecture
>
> Changes in v2:
> - Drop patch previously applied
> - Add .gitignore file
> - Move fit rule to Makefile.lib using an intermediate file
> - Drop dependency on CONFIG_EFI_ZBOOT
> - Pick up .dtb files separately from the kernel
> - Correct pylint too-many-args warning for write_kernel()
> - Include the kernel image in the file count
> - Add a pointer to the FIT spec and mention of its wide industry usage
> - Mention the kernel version in the FIT description
>
>  Documentation/process/changes.rst |   9 +
>  MAINTAINERS                       |   7 +
>  arch/arm64/Makefile               |   7 +-
>  arch/arm64/boot/.gitignore        |   1 +
>  arch/arm64/boot/Makefile          |   9 +-
>  scripts/Makefile.lib              |  13 ++
>  scripts/make_fit.py               | 291 ++++++++++++++++++++++++++++++
>  7 files changed, 334 insertions(+), 3 deletions(-)
>  create mode 100755 scripts/make_fit.py
>
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index bb96ca0f774b..cad51bd5bd62 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -62,6 +62,7 @@ Sphinx\ [#f1]_         1.7              sphinx-build --version
>  cpio                   any              cpio --version
>  GNU tar                1.28             tar --version
>  gtags (optional)       6.6.5            gtags --version
> +mkimage (optional)     2017.01          mkimage --version
>  ====================== ===============  ========================================
>
>  .. [#f1] Sphinx is needed only to build the Kernel documentation
> @@ -189,6 +190,14 @@ The kernel build requires GNU GLOBAL version 6.6.5 or later to generate
>  tag files through ``make gtags``.  This is due to its use of the gtags
>  ``-C (--directory)`` flag.
>
> +mkimage
> +-------
> +
> +This tool is used when building a Flat Image Tree (FIT), commonly used on ARM
> +platforms. The tool is available via the ``u-boot-tools`` package or can be
> +built from the U-Boot source code. See the instructions at
> +https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
> +
>  System utilities
>  ****************
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 14587be87a33..9f3eb476ece4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3037,6 +3037,13 @@ F:       drivers/mmc/host/sdhci-of-arasan.c
>  N:     zynq
>  N:     xilinx
>
> +ARM64 FIT SUPPORT
> +M:     Simon Glass <sjg at chromium.org>
> +L:     linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S:     Maintained
> +F:     arch/arm64/boot/Makefile
> +F:     scripts/make_fit.py
> +
>  ARM64 PORT (AARCH64 ARCHITECTURE)
>  M:     Catalin Marinas <catalin.marinas at arm.com>
>  M:     Will Deacon <will at kernel.org>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 1bd4fae6e806..6b893dc454b7 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -150,7 +150,7 @@ libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>  # Default target when executing plain make
>  boot           := arch/arm64/boot
>
> -BOOT_TARGETS   := Image vmlinuz.efi
> +BOOT_TARGETS   := Image vmlinuz.efi image.fit
>
>  PHONY += $(BOOT_TARGETS)
>
> @@ -162,7 +162,9 @@ endif
>
>  all:   $(notdir $(KBUILD_IMAGE))
>
> -vmlinuz.efi: Image
> +image.fit: dtbs
> +
> +vmlinuz.efi image.fit: Image
>  $(BOOT_TARGETS): vmlinux
>         $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
>
> @@ -215,6 +217,7 @@ virtconfig:
>  define archhelp
>    echo  '* Image.gz      - Compressed kernel image (arch/$(ARCH)/boot/Image.gz)'
>    echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
> +  echo  '  image.fit     - Flat Image Tree (arch/$(ARCH)/boot/image.fit)'
>    echo  '  install       - Install uncompressed kernel'
>    echo  '  zinstall      - Install compressed kernel'
>    echo  '                  Install using (your) ~/bin/installkernel or'
> diff --git a/arch/arm64/boot/.gitignore b/arch/arm64/boot/.gitignore
> index af5dc61f8b43..abaae9de1bdd 100644
> --- a/arch/arm64/boot/.gitignore
> +++ b/arch/arm64/boot/.gitignore
> @@ -2,3 +2,4 @@
>  Image
>  Image.gz
>  vmlinuz*
> +image.fit
> diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
> index 1761f5972443..62efb533a9bc 100644
> --- a/arch/arm64/boot/Makefile
> +++ b/arch/arm64/boot/Makefile
> @@ -16,7 +16,8 @@
>
>  OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
>
> -targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo Image.zst
> +targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo \
> +       Image.zst image.fit
>
>  $(obj)/Image: vmlinux FORCE
>         $(call if_changed,objcopy)
> @@ -39,6 +40,12 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
>  $(obj)/Image.zst: $(obj)/Image FORCE
>         $(call if_changed,zstd)
>
> +# Use this to override the compression algorithm
> +FIT_COMPRESS ?= gzip
> +
> +$(obj)/image.fit: $(obj)/Image FORCE
> +       $(call cmd,fit,$(FIT_COMPRESS))



Again, $(FIT_COMPRESS) is not used anywhere.


Please fix it to

      $(call cmd,fit)




See your code.


   cmd_fit = $(MAKE_FIT) -f $@ --arch $(UIMAGE_ARCH) --os linux \
                     --name '$(UIMAGE_NAME)' \
                     --compress $(UIMAGE_COMPRESSION) -k $< \
                     $(<D)/dts


cmd_fit does not take any argument.


The compression is determined by $(UIMAGE_COMPRESSION).







-- 
Best Regards
Masahiro Yamada


From kibi at debian.org  Fri Dec  1 09:38:43 2023
From: kibi at debian.org (Cyril Brulebois)
Date: Fri, 1 Dec 2023 18:38:43 +0100
Subject: [PATCH V2 0/2] ARM: dts: bcm2711: Add generic xHCI
In-Reply-To: <20231130154229.22334-1-wahrenst@gmx.net>
References: <20231130154229.22334-1-wahrenst@gmx.net>
Message-ID: <20231201173843.isjlp7zphdvvyvbt@mraw.org>

Hi Stefan,

Stefan Wahren <wahrenst at gmx.net> (2023-11-30):
> In contrast to the Raspberry Pi 4, the Compute Module 4 or the IO board
> does not have a VL805 USB 3.0 host controller, which is connected via
> PCIe. Instead, the BCM2711 on the Compute Module provides the built-in
> xHCI.
> 
> Changes in V2:
> - adjust xHCI compatible as suggested by Justin & Florian
> - keep xHCI disabled in order to let the bootloader decide which
>   USB block should be enabled, which result in a drop of patch 3
> 
> Stefan Wahren (2):
>   dt-bindings: usb: xhci: Add optional power-domains
>   ARM: dts: bcm2711: Add generic xHCI
> 
>  .../devicetree/bindings/usb/generic-xhci.yaml      |  3 +++
>  arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi        |  5 +++++
>  arch/arm/boot/dts/broadcom/bcm2711.dtsi            | 14 ++++++++++++++
>  3 files changed, 22 insertions(+)

Thanks, tests look much better this time!

Tested-by: Cyril Brulebois <cyril at debamax.com>


With CM4 Lite on CM4 IO Board, with a Samsung flash drive and a USB
keyboard connected to onboard USB ports, I'm getting the following
results (still with a Debian 12 arm64 userspace):

1. With unpatched kernel and unmodified config.txt:
     Both USB devices are working fine.

2. With unpatched kernel and otg_mode=1 in config.txt:
     Both USB devices disappear. lsmod reports dwc2 is no longer loaded,
     along with all USB and SCSI related modules.

3. With patched kernel and unmodified config.txt:
     Both USB devices are still working fine. lsmod confirms dwc2 is
     still used.

4. With patched kernel and otg_mode=1 in config.txt:
     Both USB devices are still working fine. lsmod reports dwc2 is
     going away, and other USB modules come up: usbhid, xhci_hcd,
     xhci_plat_hcd, along with others like hid, hid_generic, joydev. 

     Reading from the Samsung flash drive gives a little boost, from
     37.5 MB/s to 38.7 MB/s. Writing to it gives a little boost, from
     16.5 MB/s to 17.4 MB/s. Not as spectacular as Florian's results but
     still not a regression! :)

I tested that initially with a CM4 Lite Rev 1.0 (which was breaking case
number 3 with the v1 of this patch series), then extended testing to CM4
8/32 Rev 1.0 and CM4 4/32 Rev 1.1, which confirmed those results.


Adding a PCIe-to-USB expansion board to see if this has side effects on
other USB things, that still works fine in cases 3 and 4 (so without or
with otg_mode=1), having a Samsung flash drive on the PCIe-to-USB board
and another one the onboard USB port. At this point, I only verified the
block devices were reported by lsblk though (no actual transfer tests).

Of course that relies on also applying Jim Quinlan's PCIe patch series
v8 to make sure PCIe isn't an issue:
  https://lore.kernel.org/all/20231126201946.ffm3bhg5du2xgztv at mraw.org/

I've confirmed the presence of both Samsung flash drives with three
different cards (adding CONFIG_USB_XHCI_PCI_RENESAS=m to the config
shared in the v1 thread, and adding /lib/firmware/renesas_usb_fw.mem):
 - SupaHub PCE6U1C-R02, VER 006
 - SupaHub PCE6U1C-R02, VER 006S
 - Waveshare PCIe TO USB 3.2 Gen1 (B)
   https://www.waveshare.com/wiki/PCIe_TO_USB_3.2_Gen1_(B)


Finally, I've deployed the patched kernel (still this v2 plus Jim's v8)
in a CM4-based product that uses both onboard USB ports and PCIe-to-USB
ports, and all USB components still work fine (3 RF adapters, 1 modem).
That's the case with an unmodified config.txt, but also when adding
otg_mode=1:
 - xhci_pci and xhci_pci_renesas were already loaded;
 - xhci_plat_hcd appears in OTG mode, while dwc2 goes away.


Cheers,
-- 
Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/1a4112c9/attachment.sig>

From geert at linux-m68k.org  Fri Dec  1 09:35:57 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 1 Dec 2023 18:35:57 +0100
Subject: [PATCH 10/14] arm64: renesas: r9a08g045: Add Ethernet nodes
In-Reply-To: <20231120070024.4079344-11-claudiu.beznea.uj@bp.renesas.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com> <20231120070024.4079344-11-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdW9Unpw7NQOGWd4SeFV8XgvRYTKTXnt9Tsagb3Q3U9tNA@mail.gmail.com>

Hi Claudiu,

On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> Add Ethernet nodes available on RZ/G3S (R9A08G045).
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
> @@ -149,6 +149,38 @@ sdhi2: mmc at 11c20000 {
>                         status = "disabled";
>                 };
>
> +               eth0: ethernet at 11c30000 {
> +                       compatible = "renesas,r9a08g045-gbeth", "renesas,rzg2l-gbeth";
> +                       reg = <0 0x11c30000 0 0x10000>;
> +                       interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
> +                                    <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> +                                    <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
> +                       interrupt-names = "mux", "fil", "arp_ns";
> +                       clocks = <&cpg CPG_MOD R9A08G045_ETH0_CLK_AXI>,
> +                                <&cpg CPG_MOD R9A08G045_ETH0_CLK_CHI>,
> +                                <&cpg CPG_MOD R9A08G045_ETH0_REFCLK>;
> +                       clock-names = "axi", "chi", "refclk";
> +                       resets = <&cpg R9A08G045_ETH0_RST_HW_N>;
> +                       power-domains = <&cpg>;

Perhaps add a default phy mode, like on other SoCs?

    phy-mode = "rgmii"';

Also missing:

    #address-cells = <1>;
    #size-cells = <0>;

> +                       status = "disabled";
> +               };

Same comments for eth1.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From catalin.marinas at arm.com  Fri Dec  1 09:52:22 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 1 Dec 2023 17:52:22 +0000
Subject: [GIT PULL] arm64 fix for 6.7-rc4
Message-ID: <ZWodVqC4gvcASpba@arm.com>

Hi Linus,

Please pull the arm64 fix below. Thanks.

The following changes since commit c0a8574204054effad6ac83cc75c02576e2985fe:

  arm64: add dependency between vmlinuz.efi and Image (2023-11-23 19:10:29 +0000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

for you to fetch changes up to f5259997f3e8d6edfcc2daf5b2c0b34f074d7bc0:

  arm64: Avoid enabling KPTI unnecessarily (2023-11-30 19:07:33 +0000)

----------------------------------------------------------------
Fix a 6.7-rc1 regression where the arm64 KPTI ends up enabled even on
systems that don't need it.

----------------------------------------------------------------
Ard Biesheuvel (1):
      arm64: Avoid enabling KPTI unnecessarily

 arch/arm64/kernel/cpufeature.c | 4 ++++
 1 file changed, 4 insertions(+)

-- 
Catalin


From rostedt at goodmis.org  Fri Dec  1 10:07:37 2023
From: rostedt at goodmis.org (Steven Rostedt)
Date: Fri, 1 Dec 2023 13:07:37 -0500
Subject: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
In-Reply-To: <81af85b4-5274-4362-9413-890425c60524@broadcom.com>
References: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
	<CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
	<81af85b4-5274-4362-9413-890425c60524@broadcom.com>
Message-ID: <20231201130702.2824115c@gandalf.local.home>

On Fri, 1 Dec 2023 09:25:59 -0800
Justin Chen <justin.chen at broadcom.com> wrote:

> > It appears the sub instruction at 0x6dd0 correctly accounts for the
> > extra 8 bytes, so the frame pointer is valid. So it is our assumption
> > that there are no gaps between the stack frames is invalid.  
> 
> Thanks for the assistance. The gap between the stack frame depends on 
> the function. Most do not have a gap. Some have 8 (as shown above), some 
> have 12. A single assumption here is not going to work. I'm having a 
> hard time finding out the reasoning for this gap. I tried disabling a 
> bunch of gcc flags as well as -O2 and the gap still exists.

That code was originally added because of some strange things that gcc did
with mcount (for example, it made a copy of the stack frame that it passed
to mcount, where the function graph tracer replaced the copy of the return
stack making the shadow stack go out of sync and crash). This was very hard
to debug and I added this code to detect it if it happened again.

Well it's been over a decade since that happened (2009).

  71e308a239c09 ("function-graph: add stack frame test")

I'm happy assuming that the compiler folks are aware of our tricks with
hijacking return calls and I don't expect it to happen again. We can just
rip out those checks. That is, if it's only causing false positives, I
don't think it's worth keeping around.

Has it detected any real issues on the Arm platforms?

-- Steve


From Jonathan.Cameron at Huawei.com  Fri Dec  1 10:08:11 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 1 Dec 2023 18:08:11 +0000
Subject: [PATCH v2 1/1] iio: adc: meson: add separate config for axg SoC
 family
In-Reply-To: <ca18c346-94f3-4c4c-a540-57509b879b04@salutedevices.com>
References: <20231122074741.154228-1-gnstark@salutedevices.com>
	<20231125172508.2a2242bf@jic23-huawei>
	<ca18c346-94f3-4c4c-a540-57509b879b04@salutedevices.com>
Message-ID: <20231201180811.00002783@Huawei.com>

On Mon, 27 Nov 2023 22:17:33 +0300
George Stark <gnstark at salutedevices.com> wrote:

> Hello Jonathan
> 
> Thanks for the review.
> 
> On 11/25/23 20:25, Jonathan Cameron wrote:
> > On Wed, 22 Nov 2023 10:47:41 +0300
> > George Stark <gnstark at salutedevices.com> wrote:
> >   
> >> According to Amlogic custom kernels ADC of axg SoC family has
> >> vref_select and requires this setting to work nominally and thus
> >> needs a separate config.
> >>
> >> Signed-off-by: George Stark <gnstark at salutedevices.com>
> >> Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>  
> > 
> > Is this a fix?  If so, please provide a fixes tag.  
> Actually yes, these changes could be done in the patch that introduced
> new configuration parameters.
> 
> > Or is it aligning with the vendor kernels and we don't know if
> > it's strictly necessary or not?  
> I do know it's necessary if we want kernel driver to be independent from 
> ADC initialization in vendor u-boot code. I have Amlogic a113x device 
> (axg family) and can provide test results w and w/o this patch.

Definitely best to not rely on firmware. 

So send a Fixes tag for this and I'll apply it as a fix
(you get to figure out which patch it fixed :)

Jonathan

> 
> >   
> >> ---
> >>   drivers/iio/adc/meson_saradc.c | 16 +++++++++++++++-
> >>   1 file changed, 15 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> >> index db280da9edbf..34555a85f131 100644
> >> --- a/drivers/iio/adc/meson_saradc.c
> >> +++ b/drivers/iio/adc/meson_saradc.c
> >> @@ -1242,6 +1242,20 @@ static const struct meson_sar_adc_param meson_sar_adc_gxl_param = {
> >>   	.cmv_select = 1,
> >>   };
> >>   
> >> +static const struct meson_sar_adc_param meson_sar_adc_axg_param = {
> >> +	.has_bl30_integration = true,
> >> +	.clock_rate = 1200000,
> >> +	.bandgap_reg = MESON_SAR_ADC_REG11,
> >> +	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
> >> +	.resolution = 12,
> >> +	.disable_ring_counter = 1,
> >> +	.has_reg11 = true,
> >> +	.vref_volatge = 1,
> >> +	.has_vref_select = true,
> >> +	.vref_select = VREF_VDDA,
> >> +	.cmv_select = 1,
> >> +};
> >> +
> >>   static const struct meson_sar_adc_param meson_sar_adc_g12a_param = {
> >>   	.has_bl30_integration = false,
> >>   	.clock_rate = 1200000,
> >> @@ -1286,7 +1300,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> >>   };
> >>   
> >>   static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> >> -	.param = &meson_sar_adc_gxl_param,
> >> +	.param = &meson_sar_adc_axg_param,
> >>   	.name = "meson-axg-saradc",
> >>   };
> >>     
> >   
> 



From sjg at chromium.org  Fri Dec  1 10:08:47 2023
From: sjg at chromium.org (Simon Glass)
Date: Fri, 1 Dec 2023 11:08:47 -0700
Subject: [PATCH v8 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAK7LNARABFKSqY=f1uDGem2UqkTwGUQ9q3rDZ4NbXyuEAtsLdw@mail.gmail.com>
References: <20231130203358.879796-1-sjg@chromium.org> <20231130203358.879796-3-sjg@chromium.org>
 <CAK7LNARABFKSqY=f1uDGem2UqkTwGUQ9q3rDZ4NbXyuEAtsLdw@mail.gmail.com>
Message-ID: <CAPnjgZ0SaoyCMiZHZ8Hs6iE8pqGz0RMYwv1XQQFZOHe1cpn7YQ@mail.gmail.com>

Hi Masahiro,

On Fri, 1 Dec 2023 at 10:30, Masahiro Yamada <masahiroy at kernel.org> wrote:
>
> On Fri, Dec 1, 2023 at 5:34?AM Simon Glass <sjg at chromium.org> wrote:
> >
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> >
> > The files compress from about 86MB to 24MB using this approach.
> >
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> >
> > Add a 'make image.fit' build target for arm64, as well.
> >
> > The FIT can be examined using 'dumpimage -l'.
> >
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> >
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> >
> > Changes in v8:
> > - Drop compatible string in FDT node
> > - Correct sorting of MAINTAINERS to before ARM64 PORT
> > - Turn compress part of the make_fit.py comment in to a sentence
> > - Add two blank lines before parse_args() and setup_fit()
> > - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> > - Use '$(<D)/dts' instead of '$(dir $<)dts'
> > - Add 'mkimage' details Documentation/process/changes.rst
> > - Allow changing the compression used
> > - Tweak cover letter since there is only one clean-up patch
> >
> > Changes in v7:
> > - Add Image as a dependency of image.fit
> > - Drop kbuild tag
> > - Add dependency on dtbs
> > - Drop unnecessary path separator for dtbs
> > - Rebase to -next
> >
> > Changes in v5:
> > - Drop patch previously applied
> > - Correct compression rule which was broken in v4
> >
> > Changes in v4:
> > - Use single quotes for UIMAGE_NAME
> >
> > Changes in v3:
> > - Drop temporary file image.itk
> > - Drop patch 'Use double quotes for image name'
> > - Drop double quotes in use of UIMAGE_NAME
> > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> > - Avoid hard-coding "arm64" for the DT architecture
> >
> > Changes in v2:
> > - Drop patch previously applied
> > - Add .gitignore file
> > - Move fit rule to Makefile.lib using an intermediate file
> > - Drop dependency on CONFIG_EFI_ZBOOT
> > - Pick up .dtb files separately from the kernel
> > - Correct pylint too-many-args warning for write_kernel()
> > - Include the kernel image in the file count
> > - Add a pointer to the FIT spec and mention of its wide industry usage
> > - Mention the kernel version in the FIT description
> >
> >  Documentation/process/changes.rst |   9 +
> >  MAINTAINERS                       |   7 +
> >  arch/arm64/Makefile               |   7 +-
> >  arch/arm64/boot/.gitignore        |   1 +
> >  arch/arm64/boot/Makefile          |   9 +-
> >  scripts/Makefile.lib              |  13 ++
> >  scripts/make_fit.py               | 291 ++++++++++++++++++++++++++++++
> >  7 files changed, 334 insertions(+), 3 deletions(-)
> >  create mode 100755 scripts/make_fit.py
> >
> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> > index bb96ca0f774b..cad51bd5bd62 100644
> > --- a/Documentation/process/changes.rst
> > +++ b/Documentation/process/changes.rst
> > @@ -62,6 +62,7 @@ Sphinx\ [#f1]_         1.7              sphinx-build --version
> >  cpio                   any              cpio --version
> >  GNU tar                1.28             tar --version
> >  gtags (optional)       6.6.5            gtags --version
> > +mkimage (optional)     2017.01          mkimage --version
> >  ====================== ===============  ========================================
> >
> >  .. [#f1] Sphinx is needed only to build the Kernel documentation
> > @@ -189,6 +190,14 @@ The kernel build requires GNU GLOBAL version 6.6.5 or later to generate
> >  tag files through ``make gtags``.  This is due to its use of the gtags
> >  ``-C (--directory)`` flag.
> >
> > +mkimage
> > +-------
> > +
> > +This tool is used when building a Flat Image Tree (FIT), commonly used on ARM
> > +platforms. The tool is available via the ``u-boot-tools`` package or can be
> > +built from the U-Boot source code. See the instructions at
> > +https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
> > +
> >  System utilities
> >  ****************
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 14587be87a33..9f3eb476ece4 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3037,6 +3037,13 @@ F:       drivers/mmc/host/sdhci-of-arasan.c
> >  N:     zynq
> >  N:     xilinx
> >
> > +ARM64 FIT SUPPORT
> > +M:     Simon Glass <sjg at chromium.org>
> > +L:     linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> > +S:     Maintained
> > +F:     arch/arm64/boot/Makefile
> > +F:     scripts/make_fit.py
> > +
> >  ARM64 PORT (AARCH64 ARCHITECTURE)
> >  M:     Catalin Marinas <catalin.marinas at arm.com>
> >  M:     Will Deacon <will at kernel.org>
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index 1bd4fae6e806..6b893dc454b7 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -150,7 +150,7 @@ libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
> >  # Default target when executing plain make
> >  boot           := arch/arm64/boot
> >
> > -BOOT_TARGETS   := Image vmlinuz.efi
> > +BOOT_TARGETS   := Image vmlinuz.efi image.fit
> >
> >  PHONY += $(BOOT_TARGETS)
> >
> > @@ -162,7 +162,9 @@ endif
> >
> >  all:   $(notdir $(KBUILD_IMAGE))
> >
> > -vmlinuz.efi: Image
> > +image.fit: dtbs
> > +
> > +vmlinuz.efi image.fit: Image
> >  $(BOOT_TARGETS): vmlinux
> >         $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
> >
> > @@ -215,6 +217,7 @@ virtconfig:
> >  define archhelp
> >    echo  '* Image.gz      - Compressed kernel image (arch/$(ARCH)/boot/Image.gz)'
> >    echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
> > +  echo  '  image.fit     - Flat Image Tree (arch/$(ARCH)/boot/image.fit)'
> >    echo  '  install       - Install uncompressed kernel'
> >    echo  '  zinstall      - Install compressed kernel'
> >    echo  '                  Install using (your) ~/bin/installkernel or'
> > diff --git a/arch/arm64/boot/.gitignore b/arch/arm64/boot/.gitignore
> > index af5dc61f8b43..abaae9de1bdd 100644
> > --- a/arch/arm64/boot/.gitignore
> > +++ b/arch/arm64/boot/.gitignore
> > @@ -2,3 +2,4 @@
> >  Image
> >  Image.gz
> >  vmlinuz*
> > +image.fit
> > diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
> > index 1761f5972443..62efb533a9bc 100644
> > --- a/arch/arm64/boot/Makefile
> > +++ b/arch/arm64/boot/Makefile
> > @@ -16,7 +16,8 @@
> >
> >  OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
> >
> > -targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo Image.zst
> > +targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo \
> > +       Image.zst image.fit
> >
> >  $(obj)/Image: vmlinux FORCE
> >         $(call if_changed,objcopy)
> > @@ -39,6 +40,12 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
> >  $(obj)/Image.zst: $(obj)/Image FORCE
> >         $(call if_changed,zstd)
> >
> > +# Use this to override the compression algorithm
> > +FIT_COMPRESS ?= gzip
> > +
> > +$(obj)/image.fit: $(obj)/Image FORCE
> > +       $(call cmd,fit,$(FIT_COMPRESS))
>
>
>
> Again, $(FIT_COMPRESS) is not used anywhere.
>
>
> Please fix it to
>
>       $(call cmd,fit)
>
>
>
>
> See your code.
>
>
>    cmd_fit = $(MAKE_FIT) -f $@ --arch $(UIMAGE_ARCH) --os linux \
>                      --name '$(UIMAGE_NAME)' \
>                      --compress $(UIMAGE_COMPRESSION) -k $< \
>                      $(<D)/dts
>
>
> cmd_fit does not take any argument.
>
>
> The compression is determined by $(UIMAGE_COMPRESSION).

This references argument 2, which is how it works. I have tested this,
for example:

ARCH=arm64 CROSS_COMPILE=... make FIT_COMPRESS=lzma image.fit

I do want to support different algorithms, if possible. Is there a
better way to do this?

Regards,
Simon


From tanmay.shah at amd.com  Fri Dec  1 10:10:35 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Fri, 1 Dec 2023 12:10:35 -0600
Subject: [PATCH v7 3/4] remoteproc: zynqmp: add pm domains support
In-Reply-To: <ZWdwl/8LC2Nn+vCq@p14s>
References: <20231117174238.1876655-1-tanmay.shah@amd.com>
 <20231117174238.1876655-4-tanmay.shah@amd.com> <ZV02P3bHEhPLQHBo@p14s>
 <93487d3c-c324-4b9b-8b25-0b4ea52237b4@amd.com> <ZV+V6V2sEWgsqngk@p14s>
 <a75b22c1-66e3-4fce-ae64-de79e73f3cfa@amd.com> <ZWdwl/8LC2Nn+vCq@p14s>
Message-ID: <ea2edc6e-6655-47f8-8b6d-242f5a0ef804@amd.com>


On 11/29/23 11:10 AM, Mathieu Poirier wrote:
> On Mon, Nov 27, 2023 at 10:33:05AM -0600, Tanmay Shah wrote:
> > 
> > On 11/23/23 12:11 PM, Mathieu Poirier wrote:
> > > On Wed, Nov 22, 2023 at 03:00:36PM -0600, Tanmay Shah wrote:
> > > > Hi Mathieu,
> > > > 
> > > > Please find my comments below.
> > > > 
> > > > On 11/21/23 4:59 PM, Mathieu Poirier wrote:
> > > > > Hi,
> > > > >
> > > > > On Fri, Nov 17, 2023 at 09:42:37AM -0800, Tanmay Shah wrote:
> > > > > > Use TCM pm domains extracted from device-tree
> > > > > > to power on/off TCM using general pm domain framework.
> > > > > > 
> > > > > > Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> > > > > > ---
> > > > > > 
> > > > > > Changes in v7:
> > > > > >   - %s/pm_dev1/pm_dev_core0/r
> > > > > >   - %s/pm_dev_link1/pm_dev_core0_link/r
> > > > > >   - %s/pm_dev2/pm_dev_core1/r
> > > > > >   - %s/pm_dev_link2/pm_dev_core1_link/r
> > > > > >   - remove pm_domain_id check to move next patch
> > > > > >   - add comment about how 1st entry in pm domain list is used
> > > > > >   - fix loop when jump to fail_add_pm_domains loop
> > > > > > 
> > > > > >  drivers/remoteproc/xlnx_r5_remoteproc.c | 215 +++++++++++++++++++++++-
> > > > > >  1 file changed, 212 insertions(+), 3 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > index 4395edea9a64..22bccc5075a0 100644
> > > > > > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > @@ -16,6 +16,7 @@
> > > > > >  #include <linux/of_reserved_mem.h>
> > > > > >  #include <linux/platform_device.h>
> > > > > >  #include <linux/remoteproc.h>
> > > > > > +#include <linux/pm_domain.h>
> > > > > >  
> > > > > >  #include "remoteproc_internal.h"
> > > > > >  
> > > > > > @@ -102,6 +103,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
> > > > > >   * @rproc: rproc handle
> > > > > >   * @pm_domain_id: RPU CPU power domain id
> > > > > >   * @ipi: pointer to mailbox information
> > > > > > + * @num_pm_dev: number of tcm pm domain devices for this core
> > > > > > + * @pm_dev_core0: pm domain virtual devices for power domain framework
> > > > > > + * @pm_dev_core0_link: pm domain device links after registration
> > > > > > + * @pm_dev_core1: used only in lockstep mode. second core's pm domain virtual devices
> > > > > > + * @pm_dev_core1_link: used only in lockstep mode. second core's pm device links after
> > > > > > + * registration
> > > > > >   */
> > > > > >  struct zynqmp_r5_core {
> > > > > >  	struct device *dev;
> > > > > > @@ -111,6 +118,11 @@ struct zynqmp_r5_core {
> > > > > >  	struct rproc *rproc;
> > > > > >  	u32 pm_domain_id;
> > > > > >  	struct mbox_info *ipi;
> > > > > > +	int num_pm_dev;
> > > > > > +	struct device **pm_dev_core0;
> > > > > > +	struct device_link **pm_dev_core0_link;
> > > > > > +	struct device **pm_dev_core1;
> > > > > > +	struct device_link **pm_dev_core1_link;
> > > > > >  };
> > > > > >  
> > > > > >  /**
> > > > > > @@ -651,7 +663,8 @@ static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
> > > > > >  					     ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> > > > > >  					     ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> > > > > >  		if (ret < 0) {
> > > > > > -			dev_err(dev, "failed to turn on TCM 0x%x", pm_domain_id);
> > > > > > +			dev_err(dev, "failed to turn on TCM 0x%x",
> > > > > > +				pm_domain_id);
> > > > >
> > > > > Spurious change, you should have caught that.
> > > > 
> > > > Ack, need to observe changes more closely before sending them.
> > > > 
> > > > >
> > > > > >  			goto release_tcm_lockstep;
> > > > > >  		}
> > > > > >  
> > > > > > @@ -758,6 +771,189 @@ static int zynqmp_r5_parse_fw(struct rproc *rproc, const struct firmware *fw)
> > > > > >  	return ret;
> > > > > >  }
> > > > > >  
> > > > > > +static void zynqmp_r5_remove_pm_domains(struct rproc *rproc)
> > > > > > +{
> > > > > > +	struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > +	struct device *dev = r5_core->dev;
> > > > > > +	struct zynqmp_r5_cluster *cluster;
> > > > > > +	int i;
> > > > > > +
> > > > > > +	cluster = platform_get_drvdata(to_platform_device(dev->parent));
> > > > > > +
> > > > > > +	for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > +		device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > +		dev_pm_domain_detach(r5_core->pm_dev_core0[i], false);
> > > > > > +	}
> > > > > > +
> > > > > > +	kfree(r5_core->pm_dev_core0);
> > > > > > +	r5_core->pm_dev_core0 = NULL;
> > > > > > +	kfree(r5_core->pm_dev_core0_link);
> > > > > > +	r5_core->pm_dev_core0_link = NULL;
> > > > > > +
> > > > > > +	if (cluster->mode == SPLIT_MODE) {
> > > > > > +		r5_core->num_pm_dev = 0;
> > > > > > +		return;
> > > > > > +	}
> > > > > > +
> > > > > > +	for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > +		device_link_del(r5_core->pm_dev_core1_link[i]);
> > > > > > +		dev_pm_domain_detach(r5_core->pm_dev_core1[i], false);
> > > > > > +	}
> > > > > > +
> > > > > > +	kfree(r5_core->pm_dev_core1);
> > > > > > +	r5_core->pm_dev_core1 = NULL;
> > > > > > +	kfree(r5_core->pm_dev_core1_link);
> > > > > > +	r5_core->pm_dev_core1_link = NULL;
> > > > > > +	r5_core->num_pm_dev = 0;
> > > > > > +}
> > > > > > +
> > > > > > +static int zynqmp_r5_add_pm_domains(struct rproc *rproc)
> > > > > > +{
> > > > > > +	struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > +	struct device *dev = r5_core->dev, *dev2;
> > > > > > +	struct zynqmp_r5_cluster *cluster;
> > > > > > +	struct platform_device *pdev;
> > > > > > +	struct device_node *np;
> > > > > > +	int i, j, num_pm_dev, ret;
> > > > > > +
> > > > > > +	cluster = dev_get_drvdata(dev->parent);
> > > > > > +
> > > > > > +	/* get number of power-domains */
> > > > > > +	num_pm_dev = of_count_phandle_with_args(r5_core->np, "power-domains",
> > > > > > +						"#power-domain-cells");
> > > > > > +
> > > > > > +	if (num_pm_dev <= 0)
> > > > > > +		return -EINVAL;
> > > > > > +
> > > > > > +	r5_core->pm_dev_core0 = kcalloc(num_pm_dev,
> > > > > > +					sizeof(struct device *),
> > > > > > +					GFP_KERNEL);
> > > > > > +	if (!r5_core->pm_dev_core0)
> > > > > > +		ret = -ENOMEM;
> > > > > > +
> > > > > > +	r5_core->pm_dev_core0_link = kcalloc(num_pm_dev,
> > > > > > +					     sizeof(struct device_link *),
> > > > > > +					     GFP_KERNEL);
> > > > > > +	if (!r5_core->pm_dev_core0_link) {
> > > > > > +		kfree(r5_core->pm_dev_core0);
> > > > > > +		r5_core->pm_dev_core0 = NULL;
> > > > > > +		return -ENOMEM;
> > > > > > +	}
> > > > > > +
> > > > > > +	r5_core->num_pm_dev = num_pm_dev;
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * start from 2nd entry in power-domains property list as
> > > > > > +	 * for zynqmp we only add TCM power domains and not core's power domain.
> > > > > > +	 * 1st entry is used to configure r5 operation mode.
> > > > >
> > > > > You are still not saying _where_ ->pm_dev_core0[0] gets added.
> > > > 
> > > > So, pm_dev_core0[0] isn't really need to be added for zynqmp platform, as firmware starts it with call,
> > > > 
> > > > zynqmp_pm_request_wake during rproc_start callback. I will document this in next
> > > >
> > >
> > > That is exactly what I am looking for.  That way people don't have to go through
> > > the entire driver trying to figure out what is happening with pm_dev_core[0].
> > >
> > > I'm also not sure about the power-up order.  Logically the TCMs should be
> > > powered up before the R5 in order to put code in them.  The R5s are powered in
> > > zynqmp_r5_rproc_start() but I am unclear as to where in the boot sequence the
> > > TCMs are powered - can you expand on that?
> > 
> > 
> > Sure. Following is call sequece
> > 
> > zynqmp_r5_rproc_prepare
> > 
> > zynqmp_r5_add_pm_domains -> Here TCM is powered on when device_link_add is called via zynqmp-pm-domains.c driver.
> > 
> > . . .
> > 
> > zynqmp_r5_rproc_start -> load firmware and Starts RPU
> > 
> > So what you mentioned is correct, TCM is being powerd-on before we load firmware and start RPU.
> > 
> > 
> > >
> > > > revision. For new platforms pm_dev_core0[0] will be added in future.
> > >
> > > Now I'm really confused - what do you mean by "pm_dev_core0[0] will be added in
> > > future"?
> > 
> > 
> > ZynqMP platform has platform management firmware running on microblaze.
> > 
> > This firmware design does not expect R5 pm domains to be requested explicitly.
> > 
> > This means, during zynqmp_r5_rproc_start when "zynqmp_pm_request_wake" is called,
> > 
> > firmware powers on R5. So, pm_dev_core[0] is not really used for ZynqMP.
> > 
> > However, this design was changed for new platforms i.e. "versal" and onwards.
> > 
> > Firmware of new platform expects pm domains to be requested explicitly for R5 cores before
> > 
> > waking them up.
> > 
> > That means, pm_dev_core[0] for R5 cores on new platform (Versal) needs to be used same as TCM.
> > 
> > Then, we should wake it up on r5_core.
> > 
> > To summarize:
> > 
> > For zynqmp only following call needed to start R5:
> > 
> > zynqmp_pm_request_wake
> > 
> > For "versal" and onwards we need two calls to start R5:
> > 
> > "device_link_add" and zynqmp_pm_request_wake
> > 
> > So, in future pm_core_dev[0] will be used.
> >
>
> Thanks for the clarification on both front.  The problem here is that we are
> keeping R5 power domain information in two different places, i.e
> zynqmp_r5_core::pm_domain_id and zynqmp_r5_core::pm_dev_core0[0].  
>
> Please see if you can retreive the power domain ID from
> zynqmp_r5_core::pm_dev_core0[0].  That way you can get the power domain ID when
> calling zynqmp_pm_request_wake() and zynqmp_pm_force_pwrdwn() and get rid of
> zynqmp_r5_core::pm_domain_id.

Hi Mathieu,

I looked into this. Probably I can't retrieve pm_domain_id from pm_dev_core0[0],

However, I can retrieve it from device-tree when calling zynqmp_pm_request_wake

and zynqmp_pm_force_pwrdwn.

zynqmp_r5_core::pm_domain_id is caching that value during probe, and use it during
rest of the driver lifecycle.

I am okay either way, (keeping it as it is, or get it from device-tree). Let me know your

preference.

Thanks,

Tanmay

> > 
> > > > 
> > > > I hope this meets expectations.
> > > > 
> > > > 
> > > > >
> > > > > > +	 */
> > > > > > +	for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > +		r5_core->pm_dev_core0[i] = dev_pm_domain_attach_by_id(dev, i);
> > > > > > +		if (IS_ERR_OR_NULL(r5_core->pm_dev_core0[i])) {
> > > > >
> > > > > Here IS_ERR_OR_NULL() is used while two if conditions for NULL and an error
> > > > > code are used in the loop for the lockstep mode.  Please pick one heuristic and
> > > > > stick with it.  I have no preference on which one.
> > > > 
> > > > Ok, I think IS_ERR_OR_NULL is more cleaner, I will address it in next revision.
> > > > 
> > > > 
> > > > >
> > > > > > +			dev_dbg(dev, "failed to attach pm domain %d, ret=%ld\n", i,
> > > > > > +				PTR_ERR(r5_core->pm_dev_core0[i]));
> > > > > > +			ret = -EINVAL;
> > > > > > +			goto fail_add_pm_domains;
> > > > > > +		}
> > > > > > +		r5_core->pm_dev_core0_link[i] = device_link_add(dev,
> > > > > > +								r5_core->pm_dev_core0[i],
> > > > > > +								DL_FLAG_STATELESS |
> > > > > > +								DL_FLAG_RPM_ACTIVE |
> > > > > > +								DL_FLAG_PM_RUNTIME);
> > > > > > +		if (!r5_core->pm_dev_core0_link[i]) {
> > > > > > +			dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > +			r5_core->pm_dev_core0[i] = NULL;
> > > > > > +			ret = -EINVAL;
> > > > > > +			goto fail_add_pm_domains;
> > > > > > +		}
> > > > > > +	}
> > > > > > +
> > > > > > +	if (cluster->mode == SPLIT_MODE)
> > > > > > +		return 0;
> > > > > > +
> > > > > > +	r5_core->pm_dev_core1 = kcalloc(num_pm_dev,
> > > > > > +					sizeof(struct device *),
> > > > > > +					GFP_KERNEL);
> > > > > > +	if (!r5_core->pm_dev_core1) {
> > > > > > +		ret = -ENOMEM;
> > > > > > +		goto fail_add_pm_domains;
> > > > > > +	}
> > > > > > +
> > > > > > +	r5_core->pm_dev_core1_link = kcalloc(num_pm_dev,
> > > > > > +					     sizeof(struct device_link *),
> > > > > > +					     GFP_KERNEL);
> > > > > > +	if (!r5_core->pm_dev_core1_link) {
> > > > > > +		kfree(r5_core->pm_dev_core1);
> > > > > > +		r5_core->pm_dev_core1 = NULL;
> > > > > > +		ret = -ENOMEM;
> > > > > > +		goto fail_add_pm_domains;
> > > > > > +	}
> > > > > > +
> > > > > > +	/* get second core's device to detach its power-domains */
> > > > > > +	np = of_get_next_child(cluster->dev->of_node, of_node_get(dev->of_node));
> > > > > > +
> > > > > > +	pdev = of_find_device_by_node(np);
> > > > > > +	if (!pdev) {
> > > > > > +		dev_err(cluster->dev, "core1 platform device not available\n");
> > > > > > +		kfree(r5_core->pm_dev_core1);
> > > > > > +		kfree(r5_core->pm_dev_core1_link);
> > > > > > +		r5_core->pm_dev_core1 = NULL;
> > > > > > +		r5_core->pm_dev_core1_link = NULL;
> > > > > > +		ret = -EINVAL;
> > > > > > +		goto fail_add_pm_domains;
> > > > > > +	}
> > > > > > +
> > > > > > +	dev2 = &pdev->dev;
> > > > > > +
> > > > > > +	/* for zynqmp we only add TCM power domains and not core's power domain */
> > > > > > +	for (j = 1; j < r5_core->num_pm_dev; j++) {
> > > > > > +		r5_core->pm_dev_core1[j] = dev_pm_domain_attach_by_id(dev2, j);
> > > > > > +		if (!r5_core->pm_dev_core1[j]) {
> > > > > > +			dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > +			ret = -EINVAL;
> > > > > > +			goto fail_add_pm_domains_lockstep;
> > > > > > +		} else if (IS_ERR(r5_core->pm_dev_core1[j])) {
> > > > > > +			dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > +			ret = PTR_ERR(r5_core->pm_dev_core1[j]);
> > > > > > +			goto fail_add_pm_domains_lockstep;
> > > > > > +		}
> > > > > > +
> > > > > > +		r5_core->pm_dev_core1_link[j] = device_link_add(dev,
> > > > > > +								r5_core->pm_dev_core1[j],
> > > > > > +								DL_FLAG_STATELESS |
> > > > > > +								DL_FLAG_RPM_ACTIVE |
> > > > > > +								DL_FLAG_PM_RUNTIME);
> > > > > > +		if (!r5_core->pm_dev_core1_link[j]) {
> > > > > > +			dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > +			r5_core->pm_dev_core1[j] = NULL;
> > > > > > +			ret = -ENODEV;
> > > > > > +			goto fail_add_pm_domains_lockstep;
> > > > > > +		}
> > > > > > +	}
> > > > > > +
> > > > > > +fail_add_pm_domains_lockstep:
> > > > > > +	while (--j >= 0) {
> > > > > > +		device_link_del(r5_core->pm_dev_core1_link[j]);
> > > > > > +		dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > +	}
> > > > > > +	kfree(r5_core->pm_dev_core1);
> > > > > > +	r5_core->pm_dev_core1 = NULL;
> > > > > > +	kfree(r5_core->pm_dev_core1_link);
> > > > > > +	r5_core->pm_dev_core1_link = NULL;
> > > > > > +
> > > > > > +fail_add_pm_domains:
> > > > > > +	while (--i >= 0) {
> > > > > > +		device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > +		dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > +	}
> > > > > > +	kfree(r5_core->pm_dev_core0);
> > > > > > +	r5_core->pm_dev_core0 = NULL;
> > > > > > +	kfree(r5_core->pm_dev_core0_link);
> > > > > > +	r5_core->pm_dev_core0_link = NULL;
> > > > > > +
> > > > >
> > > > > The error path is much cleaner and readable now.
> > > > >
> > > > > I will continue tomorrow.
> > > > >
> > > > > Mathieu
> > > > >
> > > > > > +	return ret;
> > > > > > +}
> > > > > > +
> > > > > >  /**
> > > > > >   * zynqmp_r5_rproc_prepare()
> > > > > >   * adds carveouts for TCM bank and reserved memory regions
> > > > > > @@ -770,19 +966,30 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
> > > > > >  {
> > > > > >  	int ret;
> > > > > >  
> > > > > > +	ret = zynqmp_r5_add_pm_domains(rproc);
> > > > > > +	if (ret) {
> > > > > > +		dev_err(&rproc->dev, "failed to add pm domains\n");
> > > > > > +		return ret;
> > > > > > +	}
> > > > > > +
> > > > > >  	ret = add_tcm_banks(rproc);
> > > > > >  	if (ret) {
> > > > > >  		dev_err(&rproc->dev, "failed to get TCM banks, err %d\n", ret);
> > > > > > -		return ret;
> > > > > > +		goto fail_prepare;
> > > > > >  	}
> > > > > >  
> > > > > >  	ret = add_mem_regions_carveout(rproc);
> > > > > >  	if (ret) {
> > > > > >  		dev_err(&rproc->dev, "failed to get reserve mem regions %d\n", ret);
> > > > > > -		return ret;
> > > > > > +		goto fail_prepare;
> > > > > >  	}
> > > > > >  
> > > > > >  	return 0;
> > > > > > +
> > > > > > +fail_prepare:
> > > > > > +	zynqmp_r5_remove_pm_domains(rproc);
> > > > > > +
> > > > > > +	return ret;
> > > > > >  }
> > > > > >  
> > > > > >  /**
> > > > > > @@ -801,6 +1008,8 @@ static int zynqmp_r5_rproc_unprepare(struct rproc *rproc)
> > > > > >  
> > > > > >  	r5_core = rproc->priv;
> > > > > >  
> > > > > > +	zynqmp_r5_remove_pm_domains(rproc);
> > > > > > +
> > > > > >  	for (i = 0; i < r5_core->tcm_bank_count; i++) {
> > > > > >  		pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
> > > > > >  		if (zynqmp_pm_release_node(pm_domain_id))
> > > > > > -- 
> > > > > > 2.25.1
> > > > > > 


From linux at armlinux.org.uk  Fri Dec  1 10:22:54 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Fri, 1 Dec 2023 18:22:54 +0000
Subject: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
In-Reply-To: <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
References: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
 <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
Message-ID: <ZWokflhL8cG7JiCN@shell.armlinux.org.uk>

On Fri, Dec 01, 2023 at 10:12:48AM +0100, Ard Biesheuvel wrote:
> It appears the sub instruction at 0x6dd0 correctly accounts for the
> extra 8 bytes, so the frame pointer is valid. So it is our assumption
> that there are no gaps between the stack frames is invalid.
> 
> Could you try the following change please?
> 
> --- a/arch/arm/kernel/ftrace.c
> +++ b/arch/arm/kernel/ftrace.c
> @@ -235,8 +235,12 @@
>                 return;
> 
>         if (IS_ENABLED(CONFIG_UNWINDER_FRAME_POINTER)) {
> -               /* FP points one word below parent's top of stack */
> -               frame_pointer += 4;
> +               /*
> +                * The top of stack of the parent is recorded in the stack
> +                * frame at offset [fp, #-8].
> +                */
> +               get_kernel_nofault(frame_pointer,
> +                                  (unsigned long *)(frame_pointer - 8));

Yes, this will get the value of the stack pointer when the function
was entered - which may be the bottom of the parent function's stack
_or_ the start of non-register arguments to this function. So your
replacement has always been more correct.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From broonie at kernel.org  Fri Dec  1 10:50:15 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 1 Dec 2023 18:50:15 +0000
Subject: (subset) [PATCH v11 01/10] mfd: tps6594: Use set/get APIs to
 access spi->chip_select
In-Reply-To: <170142465659.3329910.8527538140063947758.b4-ty@kernel.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-2-amit.kumar-mahapatra@amd.com>
 <170142465659.3329910.8527538140063947758.b4-ty@kernel.org>
Message-ID: <395caa58-a8a0-4c75-85d3-4fa0f6f4a9ba@sirena.org.uk>

On Fri, Dec 01, 2023 at 09:57:36AM +0000, Lee Jones wrote:
> On Sat, 25 Nov 2023 14:51:28 +0530, Amit Kumar Mahapatra wrote:
> > In preparation for adding multiple CS support for a device, set/get
> > functions were introduces accessing spi->chip_select in
> > 'commit 303feb3cc06a ("spi: Add APIs in spi core to set/get
> > spi->chip_select and spi->cs_gpiod")'.
> > Replace spi->chip_select with spi_get_chipselect() API.

> Applied, thanks!

> [01/10] mfd: tps6594: Use set/get APIs to access spi->chip_select
>         commit: dd636638446c87c95c5beddcd367d95ac6764c6c

Is there a signed tag available for this - without this change the
subsequent SPI changes introduce a build breakage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/96cc1933/attachment.sig>

From heiko at sntech.de  Fri Dec  1 11:11:02 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 20:11:02 +0100
Subject: [PATCH 1/2] dt-bindings: arm: rockchip: Add Theobroma-Systems Jaguar SBC
In-Reply-To: <20231201191103.343097-1-heiko@sntech.de>
References: <20231201191103.343097-1-heiko@sntech.de>
Message-ID: <20231201191103.343097-2-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

Add the binding for the Jaguar board from Theobroma-Systems.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5f7c6c4aad8f..44181a36c5d5 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -875,6 +875,11 @@ properties:
           - const: tsd,rk3399-puma-haikou
           - const: rockchip,rk3399
 
+      - description: Theobroma Systems RK3588-SBC Jaguar
+        items:
+          - const: tsd,rk3588-jaguar
+          - const: rockchip,rk3588
+
       - description: Tronsmart Orion R68 Meta
         items:
           - const: tronsmart,orion-r68-meta
-- 
2.39.2



From heiko at sntech.de  Fri Dec  1 11:11:01 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 20:11:01 +0100
Subject: [PATCH 0/2] Theobroma-Systems Jaguar single board computer
Message-ID: <20231201191103.343097-1-heiko@sntech.de>

This adds the Jaguar SBC from Theobroma Systems.


Heiko Stuebner (2):
  dt-bindings: arm: rockchip: Add Theobroma-Systems Jaguar SBC
  arm64: dts: rockchip: add Theobroma Jaguar SBC

 .../devicetree/bindings/arm/rockchip.yaml     |   5 +
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../arm64/boot/dts/rockchip/rk3588-jaguar.dts | 803 ++++++++++++++++++
 3 files changed, 809 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts

-- 
2.39.2



From heiko at sntech.de  Fri Dec  1 11:11:03 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 20:11:03 +0100
Subject: [PATCH 2/2] arm64: dts: rockchip: add Theobroma Jaguar SBC
In-Reply-To: <20231201191103.343097-1-heiko@sntech.de>
References: <20231201191103.343097-1-heiko@sntech.de>
Message-ID: <20231201191103.343097-3-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

Add a board dts for the Jaguar SBC from Theobroma-Systems

JAGUAR is a Single-Board Computer (SBC) based around the rk3588 SoC and
is targeting Autonomous Mobile Robots (AMR).

It features:
 * LPDDR4X (up to 16GB)
 * 1Gbps Ethernet on RJ45 connector (KSZ9031 or KSZ9131)
 * PCIe 3.0 4-lane on M.2 M-key connector
 * PCIe 2.1 1-lane on M.2 E-key
 * USB 2.0 on M.2 E-key
 * 2x USB3 OTG type-c ports with DP Alt-Mode
 * USB2 host port
 * HDMI output
 * 2x camera connectors, each exposing:
   * 2-lane MIPI-CSI
   * 1v2, 1v8, 2v8 power rails
   * I2C bus
   * GPIOs
 * PPS input
 * CAN
 * RS485 UART
 * FAN connector
 * SD card slot
 * eMMC (up to 256GB)
 * RTC backup battery
 * Companion microcontroller
   * ISL1208 RTC emulation
   * AMC6821 PWM emulation
   * On/off buzzer control
 * Secure Element
 * 80-pin Mezzanine connector for daughterboards:
   * GPIOs
   * 1Gbps Ethernet
   * PCIe 2.1 1-lane
   * 2x 2-lane MIPI-CSI
   * ADC channel
   * I2C bus
   * PWM
   * UART
   * SPI
   * SDIO
   * CAN
   * I2S
   * 1v8, 3v3, 5v0, dc-in (12-24V) power rails

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../arm64/boot/dts/rockchip/rk3588-jaguar.dts | 803 ++++++++++++++++++
 2 files changed, 804 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index a18f33bf0c0e..9c48dcdb056c 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -101,6 +101,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6b-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-evb1-v10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-jaguar.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-nanopc-t6.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-orangepi-5-plus.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-quartzpro64.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts b/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts
new file mode 100644
index 000000000000..4ce70fb75a30
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts
@@ -0,0 +1,803 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/usb/pd.h>
+#include "rk3588.dtsi"
+
+/ {
+	model = "Theobroma Systems RK3588-SBC Jaguar";
+	compatible = "tsd,rk3588-jaguar", "rockchip,rk3588";
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		/* Can be controlled through SW2 but also GPIO1 on CP2102 on P20 */
+		button-bios-disable {
+			label = "BIOS_DISABLE";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	aliases {
+		ethernet0 = &gmac0;
+		mmc0 = &sdhci;
+		mmc1 = &sdmmc;
+		rtc0 = &rtc_twi;
+	};
+
+	chosen {
+		stdout-path = "serial2:115200n8";
+	};
+
+	/* DCIN is 12-24V but standard is 12V */
+	dc_12v: dc-12v-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_12v";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	emmc_pwrseq: emmc-pwrseq {
+		compatible = "mmc-pwrseq-emmc";
+		pinctrl-0 = <&emmc_reset>;
+		pinctrl-names = "default";
+		reset-gpios = <&gpio2 RK_PA3 GPIO_ACTIVE_HIGH>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led1_pin>;
+		status = "okay";
+
+		/* LED1 on PCB */
+		led-1 {
+			gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
+			function = LED_FUNCTION_HEARTBEAT;
+			linux,default-trigger = "heartbeat";
+			color = <LED_COLOR_ID_AMBER>;
+		};
+	};
+
+	pps {
+		compatible = "pps-gpio";
+		gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+	};
+
+	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v2_s3: vcc-1v2-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v2_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	/* Exposed on P14 and P15 */
+	vcc_2v8_s3: vcc-2v8-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_2v8_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc_5v0_usb_a: vcc-5v0-usb-a-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_a_vcc";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+		gpio = <&gpio1 RK_PB4 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vcc_5v0_usb_c1: vcc-5v0-usb-c1-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "5v_usbc1";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usb>;
+		gpio = <&gpio4 RK_PB5 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vcc_5v0_usb_c2: vcc-5v0-usb-c2-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "5v_usbc2";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usb>;
+		gpio = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vcc3v3_mdot2: vcc3v3-mdot2-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_mdot2";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&combphy1_ps {
+	status = "okay";
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&gmac0 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii";
+	phy-supply = <&vcc_1v2_s3>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac0_miim
+		     &gmac0_rx_bus2
+		     &gmac0_tx_bus2
+		     &gmac0_rgmii_clk
+		     &gmac0_rgmii_bus
+		     &eth0_pins
+		     &eth_reset>;
+	tx_delay = <0x10>;
+	rx_delay = <0x10>;
+	snps,reset-gpio = <&gpio4 RK_PC3 GPIO_ACTIVE_LOW>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 100000>;
+
+	status = "okay";
+};
+
+&gpio1 {
+	mdot2e-w-disable1-n-hog {
+		gpios = <RK_PB1 GPIO_ACTIVE_LOW>;
+		output-low;
+		line-name = "m.2 E-key W_DISABLE1#";
+		gpio-hog;
+	};
+};
+
+&gpio4 {
+	mdot2e-w-disable2-n-hog {
+		gpios = <RK_PC1 GPIO_ACTIVE_LOW>;
+		output-low;
+		line-name = "m.2 E-key W_DISABLE2#";
+		gpio-hog;
+	};
+};
+
+&i2c0 {
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	fan at 18 {
+		compatible = "ti,amc6821";
+		reg = <0x18>;
+	};
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	rtc_twi: rtc at 6f {
+		compatible = "isil,isl1208";
+		reg = <0x6f>;
+	};
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1m4_xfer>;
+};
+
+&i2c6 {
+	pinctrl-0 = <&i2c6m4_xfer>;
+};
+
+&i2c7 {
+	status = "okay";
+
+	/* SE050 Secure Element at 0x48; GPIO1_A4 for enable pin */
+
+	/* Also on 0x55 */
+	eeprom at 54 {
+		compatible = "st,24c04", "atmel,24c04";
+		reg = <0x54>;
+		pagesize = <16>;
+		vcc-supply = <&vcc_3v3_s3>;
+	};
+};
+
+&i2c8 {
+	pinctrl-0 = <&i2c8m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&mdio0 {
+	rgmii_phy: ethernet-phy at 6 {
+		/* KSZ9031 or KSZ9131 */
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x6>;
+		clocks = <&cru REFCLKO25M_ETH0_OUT>;
+	};
+};
+
+&pcie2x1l0 {
+	reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_HIGH>; /* WIFI_PERST0# */
+	vpcie3v3-supply = <&vcc3v3_mdot2>;
+	status = "okay";
+};
+
+&pinctrl {
+	emmc {
+		emmc_reset: emmc-reset {
+			rockchip,pins = <2 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	ethernet {
+		eth_reset: eth-reset {
+			rockchip,pins = <4 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	leds {
+		led1_pin: led1-pin {
+			rockchip,pins = <1 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	cap-mmc-highspeed;
+	mmc-ddr-1_8v;
+	mmc-hs200-1_8v;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	mmc-pwrseq = <&emmc_pwrseq>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_data_strobe>;
+	supports-cqe;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vcc_1v8_s3>;
+	status = "okay";
+};
+
+&sdmmc {
+	broken-cd;
+	bus-width = <4>;
+	cap-sd-highspeed;
+	disable-wp;
+	max-frequency = <150000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc_cmd &sdmmc_clk>;
+	sd-uhs-sdr12;
+	sd-uhs-sdr25;
+	sd-uhs-sdr50;
+	sd-uhs-ddr50;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	num-cs = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	status = "okay";
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		reg = <0x0>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		spi-max-frequency = <1000000>;
+		system-power-controller;
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: dcdc-reg1 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: dcdc-reg2 {
+				regulator-name = "vdd_cpu_lit_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-name = "vdd_log_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: dcdc-reg4 {
+				regulator-name = "vdd_vdenc_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-name = "vdd_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-name = "vdd2_ddr_s3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-name = "vdd_2v0_pldo_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-name = "vcc_3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-name = "vddq_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-name = "vcc_1v8_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcca_1v8_s0: pldo-reg1 {
+				regulator-name = "vcca_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-name = "vcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdda_1v2_s0: pldo-reg3 {
+				regulator-name = "vdda_1v2_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_3v3_s0: pldo-reg4 {
+				regulator-name = "vcca_3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-name = "vccio_sd_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-name = "pldo6_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-name = "vdd_0v75_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdda_ddr_pll_s0: nldo-reg2 {
+				regulator-name = "vdda_ddr_pll_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdda_0v75_s0: nldo-reg3 {
+				regulator-name = "vdda_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_0v85_s0: nldo-reg4 {
+				regulator-name = "vdda_0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-name = "vdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc_5v0_usb_a>;
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy3_host {
+	status = "okay";
+};
+
+/* Mule-ATtiny debug UART; typically baudrate 9600 */
+&uart0 {
+	pinctrl-0 = <&uart0m0_xfer>;
+	status = "okay";
+};
+
+/* Main debug interface on P20 micro-USB B port and P21 header */
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+/* RS485 on P19 */
+&uart3 {
+	pinctrl-0 = <&uart3m2_xfer &uart3_rtsn>;
+	linux,rs485-enabled-at-boot-time;
+	status = "okay";
+};
+
+/* Mule-ATtiny UPDI flashing UART */
+&uart7 {
+	pinctrl-0 = <&uart7m0_xfer>;
+	status = "okay";
+};
+
+/* host0 on P10 USB-A */
+&usb_host0_ehci {
+	status = "okay";
+};
+
+/* host0 on P10 USB-A */
+&usb_host0_ohci {
+	status = "okay";
+};
+
+/* host1 on M.2 E-key */
+&usb_host1_ehci {
+	status = "okay";
+};
+
+/* host1 on M.2 E-key */
+&usb_host1_ohci {
+	status = "okay";
+};
-- 
2.39.2



From heiko at sntech.de  Fri Dec  1 11:12:28 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  1 Dec 2023 20:12:28 +0100
Subject: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
Message-ID: <20231201191228.343230-1-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

Boards using socs like the rk3588 can use up to 10 uarts, so the default
of 4 is way too low. Therefore increase the maximum number to 10.

SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
data structures to prepare before registering them. This option can stay
at its default value of 4 since for one it can be changed via a boot
parameter 8250.nr_uarts but also since
commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")

the kernel can register uarts dynamically that are above the
SERIAL_8250_RUNTIME_UARTS threshold.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b60aa1f89343..69835dc43d24 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -448,6 +448,7 @@ CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=10
 CONFIG_SERIAL_8250_EXTENDED=y
 CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_8250_BCM2835AUX=y
-- 
2.39.2



From nm at ti.com  Fri Dec  1 11:19:58 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 13:19:58 -0600
Subject: [PATCH v2] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <20231201171544.1901-1-francesco@dolcini.it>
References: <20231201171544.1901-1-francesco@dolcini.it>
Message-ID: <20231201191958.kmwkpmttmebsas47@kooky>

On 18:15-20231201, Francesco Dolcini wrote:
> Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
> is not adequate for embedded systems that use SoCs where it's common to
> have a large number of serial ports.
> 
> No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
> ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
> 
> The need to increase this value was noticed while working with Toradex
> Verdin AM62, this board has 4 serial UART instances available to the user
> plus an internal one that is connected to a Bluetooth module. Without this
> change the fifth UART connected to the BT module is not instantiated and BT
> is not working.
> 
> Instead of increasing the number to the bare minimum (5) that would be
> required to solve this specific issue, we increase this to 8 which seems a
> more reasonable number to have in the defconfig and should cover more valid
> use cases.

To address Arnd's concern on size increase, it will be good to add:
---
With this change kernel image increases by ~3.2k. bloat-o-meter summary:
add/remove: 1/1 grow/shrink: 7/0 up/down: 3220/-8 (3212)
---

Full bloat-o-meter report: aarch64-none-linux-gnu-gcc (11.3.1 20220712)
$ ./scripts/bloat-o-meter ./vmlinux.old vmlinux
add/remove: 1/1 grow/shrink: 7/0 up/down: 3220/-8 (3212)
Function                                     old     new   delta
serial8250_ports                            3136    6272   +3136
serial8250_register_8250_port               1176    1208     +32
serial8250_remove                            120     136     +16
serial8250_unregister_port                   288     296      +8
serial8250_suspend                           120     128      +8
serial8250_setup_port                        212     220      +8
e843419 at 0d28_000102dd_3a64                     -       8      +8
serial8250_init                              468     472      +4
e843419 at 0c0a_0000eb9e_8cc                      8       -      -8
Total: Before=28756614, After=28759826, chg +0.01%

> 
> Cc: Tony Lindgren <tony at atomide.com>
> Reviewed-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Francesco Dolcini <francesco at dolcini.it>
> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index b60aa1f89343..ecd365cd1d87 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -448,6 +448,7 @@ CONFIG_SERIO_AMBAKMI=y
>  CONFIG_LEGACY_PTY_COUNT=16
>  CONFIG_SERIAL_8250=y
>  CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_NR_UARTS=8
>  CONFIG_SERIAL_8250_EXTENDED=y
>  CONFIG_SERIAL_8250_SHARE_IRQ=y
>  CONFIG_SERIAL_8250_BCM2835AUX=y
> -- 
> 2.39.2
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From francesco at dolcini.it  Fri Dec  1 11:52:49 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri, 1 Dec 2023 20:52:49 +0100
Subject: [PATCH v2] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <20231201191958.kmwkpmttmebsas47@kooky>
References: <20231201171544.1901-1-francesco@dolcini.it>
 <20231201191958.kmwkpmttmebsas47@kooky>
Message-ID: <ZWo5kVMoLTzST6F5@livingston.pivistrello.it>

On Fri, Dec 01, 2023 at 01:19:58PM -0600, Nishanth Menon wrote:
> On 18:15-20231201, Francesco Dolcini wrote:
> > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
> > is not adequate for embedded systems that use SoCs where it's common to
> > have a large number of serial ports.
> > 
> > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
> > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
> > 
> > The need to increase this value was noticed while working with Toradex
> > Verdin AM62, this board has 4 serial UART instances available to the user
> > plus an internal one that is connected to a Bluetooth module. Without this
> > change the fifth UART connected to the BT module is not instantiated and BT
> > is not working.
> > 
> > Instead of increasing the number to the bare minimum (5) that would be
> > required to solve this specific issue, we increase this to 8 which seems a
> > more reasonable number to have in the defconfig and should cover more valid
> > use cases.
> 
> To address Arnd's concern on size increase, it will be good to add:

I can and I will add it in a v3 - it takes less time to do it than reply to
this email and thanks for taking the time to provide the actual data.

With that said my understanding is that the goal of the arm64 defconfig is
to enable the supported arm64 hardware and the related kernel development.
It's not supposed to be a minimal config in size nor an optimal
configuration from the performance point of view. It's a single
configuration that includes support for each and every platform [1]
supported by Linux arm64 ...

To me Arnd was just stating a fact, not raising a concern that was supposed
to be addressed (just correct me if I'm wrong, of course).

[1] well, apart AMD Pensando and Bitmain, at the moment, but you get the
point, I'm sure ;-).

> ---
> With this change kernel image increases by ~3.2k. bloat-o-meter summary:
> add/remove: 1/1 grow/shrink: 7/0 up/down: 3220/-8 (3212)
> ---

Francesco



From masahiroy at kernel.org  Fri Dec  1 11:56:01 2023
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Sat, 2 Dec 2023 04:56:01 +0900
Subject: [PATCH v8 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAPnjgZ0SaoyCMiZHZ8Hs6iE8pqGz0RMYwv1XQQFZOHe1cpn7YQ@mail.gmail.com>
References: <20231130203358.879796-1-sjg@chromium.org> <20231130203358.879796-3-sjg@chromium.org>
 <CAK7LNARABFKSqY=f1uDGem2UqkTwGUQ9q3rDZ4NbXyuEAtsLdw@mail.gmail.com> <CAPnjgZ0SaoyCMiZHZ8Hs6iE8pqGz0RMYwv1XQQFZOHe1cpn7YQ@mail.gmail.com>
Message-ID: <CAK7LNARTz_BsdM2iW9Tbo1gtychMzZ5=EU5iTXLbXrAJGX+hHQ@mail.gmail.com>

On Sat, Dec 2, 2023 at 3:09?AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Masahiro,
>
> On Fri, 1 Dec 2023 at 10:30, Masahiro Yamada <masahiroy at kernel.org> wrote:
> >
> > On Fri, Dec 1, 2023 at 5:34?AM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > containing the built kernel and associated devicetree files.
> > > Compression defaults to gzip which gives a good balance of size and
> > > performance.
> > >
> > > The files compress from about 86MB to 24MB using this approach.
> > >
> > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > and Linuxboot. It permits automatic selection of the correct
> > > devicetree, matching the compatible string of the running board with
> > > the closest compatible string in the FIT. There is no need for
> > > filenames or other workarounds.
> > >
> > > Add a 'make image.fit' build target for arm64, as well.
> > >
> > > The FIT can be examined using 'dumpimage -l'.
> > >
> > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > requires compression utilities for the algorithm being used. Supported
> > > compression options are the same as the Image.xxx files. For now there
> > > is no way to change the compression other than by editing the rule for
> > > $(obj)/image.fit
> > >
> > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > this here, since it must be built separately from the Linux build.
> > >
> > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > ---
> > >
> > > Changes in v8:
> > > - Drop compatible string in FDT node
> > > - Correct sorting of MAINTAINERS to before ARM64 PORT
> > > - Turn compress part of the make_fit.py comment in to a sentence
> > > - Add two blank lines before parse_args() and setup_fit()
> > > - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> > > - Use '$(<D)/dts' instead of '$(dir $<)dts'
> > > - Add 'mkimage' details Documentation/process/changes.rst
> > > - Allow changing the compression used
> > > - Tweak cover letter since there is only one clean-up patch
> > >
> > > Changes in v7:
> > > - Add Image as a dependency of image.fit
> > > - Drop kbuild tag
> > > - Add dependency on dtbs
> > > - Drop unnecessary path separator for dtbs
> > > - Rebase to -next
> > >
> > > Changes in v5:
> > > - Drop patch previously applied
> > > - Correct compression rule which was broken in v4
> > >
> > > Changes in v4:
> > > - Use single quotes for UIMAGE_NAME
> > >
> > > Changes in v3:
> > > - Drop temporary file image.itk
> > > - Drop patch 'Use double quotes for image name'
> > > - Drop double quotes in use of UIMAGE_NAME
> > > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> > > - Avoid hard-coding "arm64" for the DT architecture
> > >
> > > Changes in v2:
> > > - Drop patch previously applied
> > > - Add .gitignore file
> > > - Move fit rule to Makefile.lib using an intermediate file
> > > - Drop dependency on CONFIG_EFI_ZBOOT
> > > - Pick up .dtb files separately from the kernel
> > > - Correct pylint too-many-args warning for write_kernel()
> > > - Include the kernel image in the file count
> > > - Add a pointer to the FIT spec and mention of its wide industry usage
> > > - Mention the kernel version in the FIT description
> > >
> > >  Documentation/process/changes.rst |   9 +
> > >  MAINTAINERS                       |   7 +
> > >  arch/arm64/Makefile               |   7 +-
> > >  arch/arm64/boot/.gitignore        |   1 +
> > >  arch/arm64/boot/Makefile          |   9 +-
> > >  scripts/Makefile.lib              |  13 ++
> > >  scripts/make_fit.py               | 291 ++++++++++++++++++++++++++++++
> > >  7 files changed, 334 insertions(+), 3 deletions(-)
> > >  create mode 100755 scripts/make_fit.py
> > >
> > > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> > > index bb96ca0f774b..cad51bd5bd62 100644
> > > --- a/Documentation/process/changes.rst
> > > +++ b/Documentation/process/changes.rst
> > > @@ -62,6 +62,7 @@ Sphinx\ [#f1]_         1.7              sphinx-build --version
> > >  cpio                   any              cpio --version
> > >  GNU tar                1.28             tar --version
> > >  gtags (optional)       6.6.5            gtags --version
> > > +mkimage (optional)     2017.01          mkimage --version
> > >  ====================== ===============  ========================================
> > >
> > >  .. [#f1] Sphinx is needed only to build the Kernel documentation
> > > @@ -189,6 +190,14 @@ The kernel build requires GNU GLOBAL version 6.6.5 or later to generate
> > >  tag files through ``make gtags``.  This is due to its use of the gtags
> > >  ``-C (--directory)`` flag.
> > >
> > > +mkimage
> > > +-------
> > > +
> > > +This tool is used when building a Flat Image Tree (FIT), commonly used on ARM
> > > +platforms. The tool is available via the ``u-boot-tools`` package or can be
> > > +built from the U-Boot source code. See the instructions at
> > > +https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
> > > +
> > >  System utilities
> > >  ****************
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 14587be87a33..9f3eb476ece4 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -3037,6 +3037,13 @@ F:       drivers/mmc/host/sdhci-of-arasan.c
> > >  N:     zynq
> > >  N:     xilinx
> > >
> > > +ARM64 FIT SUPPORT
> > > +M:     Simon Glass <sjg at chromium.org>
> > > +L:     linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> > > +S:     Maintained
> > > +F:     arch/arm64/boot/Makefile
> > > +F:     scripts/make_fit.py
> > > +
> > >  ARM64 PORT (AARCH64 ARCHITECTURE)
> > >  M:     Catalin Marinas <catalin.marinas at arm.com>
> > >  M:     Will Deacon <will at kernel.org>
> > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > > index 1bd4fae6e806..6b893dc454b7 100644
> > > --- a/arch/arm64/Makefile
> > > +++ b/arch/arm64/Makefile
> > > @@ -150,7 +150,7 @@ libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
> > >  # Default target when executing plain make
> > >  boot           := arch/arm64/boot
> > >
> > > -BOOT_TARGETS   := Image vmlinuz.efi
> > > +BOOT_TARGETS   := Image vmlinuz.efi image.fit
> > >
> > >  PHONY += $(BOOT_TARGETS)
> > >
> > > @@ -162,7 +162,9 @@ endif
> > >
> > >  all:   $(notdir $(KBUILD_IMAGE))
> > >
> > > -vmlinuz.efi: Image
> > > +image.fit: dtbs
> > > +
> > > +vmlinuz.efi image.fit: Image
> > >  $(BOOT_TARGETS): vmlinux
> > >         $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
> > >
> > > @@ -215,6 +217,7 @@ virtconfig:
> > >  define archhelp
> > >    echo  '* Image.gz      - Compressed kernel image (arch/$(ARCH)/boot/Image.gz)'
> > >    echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
> > > +  echo  '  image.fit     - Flat Image Tree (arch/$(ARCH)/boot/image.fit)'
> > >    echo  '  install       - Install uncompressed kernel'
> > >    echo  '  zinstall      - Install compressed kernel'
> > >    echo  '                  Install using (your) ~/bin/installkernel or'
> > > diff --git a/arch/arm64/boot/.gitignore b/arch/arm64/boot/.gitignore
> > > index af5dc61f8b43..abaae9de1bdd 100644
> > > --- a/arch/arm64/boot/.gitignore
> > > +++ b/arch/arm64/boot/.gitignore
> > > @@ -2,3 +2,4 @@
> > >  Image
> > >  Image.gz
> > >  vmlinuz*
> > > +image.fit
> > > diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
> > > index 1761f5972443..62efb533a9bc 100644
> > > --- a/arch/arm64/boot/Makefile
> > > +++ b/arch/arm64/boot/Makefile
> > > @@ -16,7 +16,8 @@
> > >
> > >  OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
> > >
> > > -targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo Image.zst
> > > +targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo \
> > > +       Image.zst image.fit
> > >
> > >  $(obj)/Image: vmlinux FORCE
> > >         $(call if_changed,objcopy)
> > > @@ -39,6 +40,12 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
> > >  $(obj)/Image.zst: $(obj)/Image FORCE
> > >         $(call if_changed,zstd)
> > >
> > > +# Use this to override the compression algorithm
> > > +FIT_COMPRESS ?= gzip
> > > +
> > > +$(obj)/image.fit: $(obj)/Image FORCE
> > > +       $(call cmd,fit,$(FIT_COMPRESS))
> >
> >
> >
> > Again, $(FIT_COMPRESS) is not used anywhere.
> >
> >
> > Please fix it to
> >
> >       $(call cmd,fit)
> >
> >
> >
> >
> > See your code.
> >
> >
> >    cmd_fit = $(MAKE_FIT) -f $@ --arch $(UIMAGE_ARCH) --os linux \
> >                      --name '$(UIMAGE_NAME)' \
> >                      --compress $(UIMAGE_COMPRESSION) -k $< \
> >                      $(<D)/dts
> >
> >
> > cmd_fit does not take any argument.
> >
> >
> > The compression is determined by $(UIMAGE_COMPRESSION).
>
> This references argument 2, which is how it works. I have tested this,


Hah, I missed it, sorry.


You want to use gzip instead of none as the
default compression for the fit image, right?



If so, maybe, you can directly add FIT_COMPRESSION
in scripts/Makefile.lib
Users are still allowed to override it from an
environment variable.



FIT_COMPRESSION ?= gzip

cmd_fit = $(MAKE_FIT) -f $@ --arch $(UIMAGE_ARCH) --os linux \
                   --name '$(UIMAGE_NAME)' \
                   --compress $(FIT_COMPRESSION) -k $< \
                   $(<D)/dts






> for example:
>
> ARCH=arm64 CROSS_COMPILE=... make FIT_COMPRESS=lzma image.fit
>
> I do want to support different algorithms, if possible. Is there a
> better way to do this?
>
> Regards,
> Simon



-- 
Best Regards
Masahiro Yamada


From francesco at dolcini.it  Fri Dec  1 11:57:32 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri,  1 Dec 2023 20:57:32 +0100
Subject: [PATCH v3] arm64: defconfig: increase SERIAL_8250_NR_UARTS
Message-ID: <20231201195732.4931-1-francesco@dolcini.it>

Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
is not adequate for embedded systems that use SoCs where it's common to
have a large number of serial ports.

No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").

The need to increase this value was noticed while working with Toradex
Verdin AM62, this board has 4 serial UART instances available to the user
plus an internal one that is connected to a Bluetooth module. Without this
change the fifth UART connected to the BT module is not instantiated and BT
is not working.

Instead of increasing the number to the bare minimum (5) that would be
required to solve this specific issue, we increase this to 8 which seems a
more reasonable number to have in the defconfig and should cover more valid
use cases.

With this change the kernel image size increases by ~3.2kB. bloat-o-meter
summary: add/remove: 1/1 grow/shrink: 7/0 up/down: 3220/-8 (3212)

Cc: Tony Lindgren <tony at atomide.com>
Reviewed-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Francesco Dolcini <francesco at dolcini.it>
---
v2: added details in the commit message on the verdin am62 uart config and
    requirement
v3: added details on the kernel size increase because of this change
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b60aa1f89343..ecd365cd1d87 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -448,6 +448,7 @@ CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=8
 CONFIG_SERIAL_8250_EXTENDED=y
 CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_8250_BCM2835AUX=y
-- 
2.39.2



From f.fainelli at gmail.com  Fri Dec  1 11:57:53 2023
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 1 Dec 2023 11:57:53 -0800
Subject: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
In-Reply-To: <20231201191228.343230-1-heiko@sntech.de>
References: <20231201191228.343230-1-heiko@sntech.de>
Message-ID: <bf5c7806-7405-4728-bb10-7913368f62a0@gmail.com>

+Francesco,

On 12/1/23 11:12, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner at cherry.de>
> 
> Boards using socs like the rk3588 can use up to 10 uarts, so the default
> of 4 is way too low. Therefore increase the maximum number to 10.
> 
> SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
> data structures to prepare before registering them. This option can stay
> at its default value of 4 since for one it can be changed via a boot
> parameter 8250.nr_uarts but also since
> commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")
> 
> the kernel can register uarts dynamically that are above the
> SERIAL_8250_RUNTIME_UARTS threshold.
> 
> Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>

There is a competing patch set from Francesco being submitted as well:

https://lore.kernel.org/all/20231201171544.1901-1-francesco at dolcini.it/

looks like some coordination is necessary.
-- 
Florian



From francesco at dolcini.it  Fri Dec  1 12:09:29 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri, 1 Dec 2023 21:09:29 +0100
Subject: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
In-Reply-To: <bf5c7806-7405-4728-bb10-7913368f62a0@gmail.com>
References: <20231201191228.343230-1-heiko@sntech.de>
 <bf5c7806-7405-4728-bb10-7913368f62a0@gmail.com>
Message-ID: <ZWo9ecC45DZaqVJJ@livingston.pivistrello.it>

On Fri, Dec 01, 2023 at 11:57:53AM -0800, Florian Fainelli wrote:
> +Francesco,
> 
> On 12/1/23 11:12, Heiko Stuebner wrote:
> > From: Heiko Stuebner <heiko.stuebner at cherry.de>
> > 
> > Boards using socs like the rk3588 can use up to 10 uarts, so the default
> > of 4 is way too low. Therefore increase the maximum number to 10.
Do you have an actual need of 10, e.g. an existing board with 10 uarts
enabled supported by the mainline kernel? Just thinking at the last arm64 SoC I
am working with it should be 12 if we use this as a metric.

> > SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
> > data structures to prepare before registering them. This option can stay
> > at its default value of 4 since for one it can be changed via a boot
> > parameter 8250.nr_uarts but also since
> > commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")
> > 
> > the kernel can register uarts dynamically that are above the
> > SERIAL_8250_RUNTIME_UARTS threshold.
> > 
> > Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
> 
> There is a competing patch set from Francesco being submitted as well:
> https://lore.kernel.org/all/20231201171544.1901-1-francesco at dolcini.it/
>
> looks like some coordination is necessary.

Yep, thanks Florian.

Heiko: should I include your needs in my patch? It looks like these are the
days of the 8250 uart, I sent my patch just one day before yours.

Francesco



From semen.protsenko at linaro.org  Fri Dec  1 12:11:08 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 14:11:08 -0600
Subject: [PATCH v5 02/20] dt-bindings: clock: Add Google gs101 clock
 management unit bindings
In-Reply-To: <20231201160925.3136868-3-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-3-peter.griffin@linaro.org>
Message-ID: <CAPLW+4m=A5-+izcOiYghpBOSmQORjGfjX+fgc2jeQ1jezHosMw@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:10?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Provide dt-schema documentation for Google gs101 SoC clock controller.
> Currently this adds support for cmu_top, cmu_misc and cmu_apm.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Except for my nitpicks below (very minor, can be ignored):

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  .../bindings/clock/google,gs101-clock.yaml    | 110 +++++
>  include/dt-bindings/clock/google,gs101.h      | 392 ++++++++++++++++++
>  2 files changed, 502 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>  create mode 100644 include/dt-bindings/clock/google,gs101.h
>
> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> new file mode 100644
> index 000000000000..4612886fcc15
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/google,gs101-clock.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Google GS101 SoC clock controller
> +
> +maintainers:
> +  - Peter Griffin <peter.griffin at linaro.org>
> +
> +description: |
> +  Google GS101 clock controller is comprised of several CMU units, generating
> +  clocks for different domains. Those CMU units are modeled as separate device
> +  tree nodes, and might depend on each other. The root clock in that clock tree
> +  is OSCCLK (24.576 MHz). That external clock must be defined as a fixed-rate
> +  clock in dts.
> +
> +  CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
> +  dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP.
> +
> +  Each clock is assigned an identifier and client nodes can use this identifier
> +  to specify the clock which they consume. All clocks available for usage
> +  in clock consumer nodes are defined as preprocessor macros in
> +  'dt-bindings/clock/gs101.h' header.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - google,gs101-cmu-top
> +      - google,gs101-cmu-apm
> +      - google,gs101-cmu-misc
> +
> +  clocks:
> +    minItems: 1
> +    maxItems: 2
> +
> +  clock-names:
> +    minItems: 1
> +    maxItems: 2
> +
> +  "#clock-cells":
> +    const: 1
> +
> +  reg:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - "#clock-cells"
> +  - clocks
> +  - clock-names
> +  - reg
> +
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - google,gs101-cmu-top
> +              - google,gs101-cmu-apm
> +    then:
> +      properties:
> +        clocks:
> +          items:
> +            - description: External reference clock (24.576 MHz)
> +
> +        clock-names:
> +          items:
> +            - const: oscclk
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: google,gs101-cmu-misc
> +
> +    then:
> +      properties:
> +        clocks:
> +          items:
> +            - description: External reference clock (24.576 MHz)
> +            - description: Misc bus clock (from CMU_TOP)
> +
> +        clock-names:
> +          items:
> +            - const: oscclk
> +            - const: dout_cmu_misc_bus
> +
> +additionalProperties: false
> +
> +examples:
> +  # Clock controller node for CMU_TOP
> +  - |
> +    #include <dt-bindings/clock/google,gs101.h>

Not really needed for the particular example below, but I guess it's
ok to have it here for the reference.

> +    soc {
> +        #address-cells = <2>;
> +        #size-cells = <1>;
> +
> +        cmu_top: clock-controller at 1e080000 {
> +            compatible = "google,gs101-cmu-top";
> +            reg = <0x0 0x1e080000 0x8000>;

Having 0x0 here doesn't match how it's done in gs101.dtsi in this
series. If you remove it, then above soc node and its properties can
be removed too.

> +            #clock-cells = <1>;
> +            clocks = <&ext_24_5m>;
> +            clock-names = "oscclk";
> +        };
> +    };
> +
> +...
> diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
> new file mode 100644
> index 000000000000..9f280f74578a
> --- /dev/null
> +++ b/include/dt-bindings/clock/google,gs101.h
> @@ -0,0 +1,392 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + * Author: Peter Griffin <peter.griffin at linaro.org>
> + *
> + * Device Tree binding constants for Google gs101 clock controller.
> + */
> +
> +#ifndef _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
> +#define _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
> +
> +/* CMU_TOP PLL */
> +#define CLK_FOUT_SHARED0_PLL           1
> +#define CLK_FOUT_SHARED1_PLL           2
> +#define CLK_FOUT_SHARED2_PLL           3
> +#define CLK_FOUT_SHARED3_PLL           4
> +#define CLK_FOUT_SPARE_PLL             5
> +
> +/* CMU_TOP MUX */
> +#define CLK_MOUT_SHARED0_PLL           6
> +#define CLK_MOUT_SHARED1_PLL           7
> +#define CLK_MOUT_SHARED2_PLL           8
> +#define CLK_MOUT_SHARED3_PLL           9
> +#define CLK_MOUT_SPARE_PLL             10
> +#define CLK_MOUT_BO_BUS                        11
> +#define CLK_MOUT_BUS0_BUS              12
> +#define CLK_MOUT_BUS1_BUS              13
> +#define CLK_MOUT_BUS2_BUS              14
> +#define CLK_MOUT_CIS_CLK0              15
> +#define CLK_MOUT_CIS_CLK1              16
> +#define CLK_MOUT_CIS_CLK2              17
> +#define CLK_MOUT_CIS_CLK3              18
> +#define CLK_MOUT_CIS_CLK4              19
> +#define CLK_MOUT_CIS_CLK5              20
> +#define CLK_MOUT_CIS_CLK6              21
> +#define CLK_MOUT_CIS_CLK7              22
> +#define CLK_MOUT_CMU_BOOST             23
> +#define CLK_MOUT_BOOST_OPTION1         24
> +#define CLK_MOUT_CORE_BUS              25
> +#define CLK_MOUT_CPUCL0_DBG            26
> +#define CLK_MOUT_CPUCL0_SWITCH         27
> +#define CLK_MOUT_CPUCL1_SWITCH         28
> +#define CLK_MOUT_CPUCL2_SWITCH         29
> +#define CLK_MOUT_CSIS_BUS              30
> +#define CLK_MOUT_DISP_BUS              31
> +#define CLK_MOUT_DNS_BUS               32
> +#define CLK_MOUT_DPU_BUS               33
> +#define CLK_MOUT_EH_BUS                        34
> +#define CLK_MOUT_G2D_G2D               35
> +#define CLK_MOUT_G2D_MSCL              36
> +#define CLK_MOUT_G3AA_G3AA             37
> +#define CLK_MOUT_G3D_BUSD              38
> +#define CLK_MOUT_G3D_GLB               39
> +#define CLK_MOUT_G3D_SWITCH            40
> +#define CLK_MOUT_GDC_GDC0              41
> +#define CLK_MOUT_GDC_GDC1              42
> +#define CLK_MOUT_GDC_SCSC              43
> +#define CLK_MOUT_CMU_HPM               44
> +#define CLK_MOUT_HSI0_BUS              45
> +#define CLK_MOUT_HSI0_DPGTC            46
> +#define CLK_MOUT_HSI0_USB31DRD         47
> +#define CLK_MOUT_HSI0_USBDPDGB         48
> +#define CLK_MOUT_HSI1_BUS              49
> +#define CLK_MOUT_HSI1_PCIE             50
> +#define CLK_MOUT_HSI2_BUS              51
> +#define CLK_MOUT_HSI2_MMC_CARD         52
> +#define CLK_MOUT_HSI2_PCIE             53
> +#define CLK_MOUT_HSI2_UFS_EMBD         54
> +#define CLK_MOUT_IPP_BUS               55
> +#define CLK_MOUT_ITP_BUS               56
> +#define CLK_MOUT_MCSC_ITSC             57
> +#define CLK_MOUT_MCSC_MCSC             58
> +#define CLK_MOUT_MFC_MFC               59
> +#define CLK_MOUT_MIF_BUSP              60
> +#define CLK_MOUT_MIF_SWITCH            61
> +#define CLK_MOUT_MISC_BUS              62
> +#define CLK_MOUT_MISC_SSS              63
> +#define CLK_MOUT_PDP_BUS               64
> +#define CLK_MOUT_PDP_VRA               65
> +#define CLK_MOUT_PERIC0_BUS            66
> +#define CLK_MOUT_PERIC0_IP             67
> +#define CLK_MOUT_PERIC1_BUS            68
> +#define CLK_MOUT_PERIC1_IP             69
> +#define CLK_MOUT_TNR_BUS               70
> +#define CLK_MOUT_TOP_BOOST_OPTION1     71
> +#define CLK_MOUT_TOP_CMUREF            72
> +#define CLK_MOUT_TPU_BUS               73
> +#define CLK_MOUT_TPU_TPU               74
> +#define CLK_MOUT_TPU_TPUCTL            75
> +#define CLK_MOUT_TPU_UART              76
> +#define CLK_MOUT_CMU_CMUREF            77
> +
> +/* CMU_TOP Dividers */
> +#define CLK_DOUT_BO_BUS                        78
> +#define CLK_DOUT_BUS0_BUS              79
> +#define CLK_DOUT_BUS1_BUS              80
> +#define CLK_DOUT_BUS2_BUS              81
> +#define CLK_DOUT_CIS_CLK0              82
> +#define CLK_DOUT_CIS_CLK1              83
> +#define CLK_DOUT_CIS_CLK2              84
> +#define CLK_DOUT_CIS_CLK3              85
> +#define CLK_DOUT_CIS_CLK4              86
> +#define CLK_DOUT_CIS_CLK5              87
> +#define CLK_DOUT_CIS_CLK6              88
> +#define CLK_DOUT_CIS_CLK7              89
> +#define CLK_DOUT_CORE_BUS              90
> +#define CLK_DOUT_CPUCL0_DBG            91
> +#define CLK_DOUT_CPUCL0_SWITCH         92
> +#define CLK_DOUT_CPUCL1_SWITCH         93
> +#define CLK_DOUT_CPUCL2_SWITCH         94
> +#define CLK_DOUT_CSIS_BUS              95
> +#define CLK_DOUT_DISP_BUS              96
> +#define CLK_DOUT_DNS_BUS               97
> +#define CLK_DOUT_DPU_BUS               98
> +#define CLK_DOUT_EH_BUS                        99
> +#define CLK_DOUT_G2D_G2D               100
> +#define CLK_DOUT_G2D_MSCL              101
> +#define CLK_DOUT_G3AA_G3AA             102
> +#define CLK_DOUT_G3D_BUSD              103
> +#define CLK_DOUT_G3D_GLB               104
> +#define CLK_DOUT_G3D_SWITCH            105
> +#define CLK_DOUT_GDC_GDC0              106
> +#define CLK_DOUT_GDC_GDC1              107
> +#define CLK_DOUT_GDC_SCSC              108
> +#define CLK_DOUT_CMU_HPM               109
> +#define CLK_DOUT_HSI0_BUS              110
> +#define CLK_DOUT_HSI0_DPGTC            111
> +#define CLK_DOUT_HSI0_USB31DRD         112
> +#define CLK_DOUT_HSI0_USBDPDGB         113
> +#define CLK_DOUT_HSI1_BUS              114
> +#define CLK_DOUT_HSI1_PCIE             115
> +#define CLK_DOUT_HSI2_BUS              116
> +#define CLK_DOUT_HSI2_MMC_CARD         117
> +#define CLK_DOUT_HSI2_PCIE             118
> +#define CLK_DOUT_HSI2_UFS_EMBD         119
> +#define CLK_DOUT_IPP_BUS               107
> +#define CLK_DOUT_ITP_BUS               108
> +#define CLK_DOUT_MCSC_ITSC             109
> +#define CLK_DOUT_MCSC_MCSC             110
> +#define CLK_DOUT_MFC_MFC               111
> +#define CLK_DOUT_MIF_BUSP              112
> +#define CLK_DOUT_MISC_BUS              113
> +#define CLK_DOUT_MISC_SSS              114
> +#define CLK_DOUT_PDP_BUS               115
> +#define CLK_DOUT_PDP_VRA               116
> +#define CLK_DOUT_PERIC0_BUS            117
> +#define CLK_DOUT_PERIC0_IP             118
> +#define CLK_DOUT_PERIC1_BUS            119
> +#define CLK_DOUT_PERIC1_IP             120
> +#define CLK_DOUT_TNR_BUS               121
> +#define CLK_DOUT_TPU_BUS               122
> +#define CLK_DOUT_TPU_TPU               123
> +#define CLK_DOUT_TPU_TPUCTL            124
> +#define CLK_DOUT_TPU_UART              125
> +#define CLK_DOUT_CMU_BOOST             126
> +#define CLK_DOUT_CMU_CMUREF            127
> +#define CLK_DOUT_SHARED0_DIV2          128
> +#define CLK_DOUT_SHARED0_DIV3          129
> +#define CLK_DOUT_SHARED0_DIV4          130
> +#define CLK_DOUT_SHARED0_DIV5          131
> +#define CLK_DOUT_SHARED1_DIV2          132
> +#define CLK_DOUT_SHARED1_DIV3          133
> +#define CLK_DOUT_SHARED1_DIV4          134
> +#define CLK_DOUT_SHARED2_DIV2          135
> +#define CLK_DOUT_SHARED3_DIV2          136
> +
> +/* CMU_TOP Gates */
> +#define CLK_GOUT_BUS0_BOOST            137
> +#define CLK_GOUT_BUS1_BOOST            138
> +#define CLK_GOUT_BUS2_BOOST            139
> +#define CLK_GOUT_CORE_BOOST            140
> +#define CLK_GOUT_CPUCL0_BOOST          141
> +#define CLK_GOUT_CPUCL1_BOOST          142
> +#define CLK_GOUT_CPUCL2_BOOST          143
> +#define CLK_GOUT_MIF_BOOST             144
> +#define CLK_GOUT_MIF_SWITCH            145
> +#define CLK_GOUT_BO_BUS                        146
> +#define CLK_GOUT_BUS0_BUS              147
> +#define CLK_GOUT_BUS1_BUS              148
> +#define CLK_GOUT_BUS2_BUS              149
> +#define CLK_GOUT_CIS_CLK0              150
> +#define CLK_GOUT_CIS_CLK1              151
> +#define CLK_GOUT_CIS_CLK2              152
> +#define CLK_GOUT_CIS_CLK3              153
> +#define CLK_GOUT_CIS_CLK4              154
> +#define CLK_GOUT_CIS_CLK5              155
> +#define CLK_GOUT_CIS_CLK6              156
> +#define CLK_GOUT_CIS_CLK7              157
> +#define CLK_GOUT_CMU_BOOST             158
> +#define CLK_GOUT_CORE_BUS              159
> +#define CLK_GOUT_CPUCL0_DBG            160
> +#define CLK_GOUT_CPUCL0_SWITCH         161
> +#define CLK_GOUT_CPUCL1_SWITCH         162
> +#define CLK_GOUT_CPUCL2_SWITCH         163
> +#define CLK_GOUT_CSIS_BUS              164
> +#define CLK_GOUT_DISP_BUS              165
> +#define CLK_GOUT_DNS_BUS               166
> +#define CLK_GOUT_DPU_BUS               167
> +#define CLK_GOUT_EH_BUS                        168
> +#define CLK_GOUT_G2D_G2D               169
> +#define CLK_GOUT_G2D_MSCL              170
> +#define CLK_GOUT_G3AA_G3AA             171
> +#define CLK_GOUT_G3D_BUSD              172
> +#define CLK_GOUT_G3D_GLB               173
> +#define CLK_GOUT_G3D_SWITCH            174
> +#define CLK_GOUT_GDC_GDC0              175
> +#define CLK_GOUT_GDC_GDC1              176
> +#define CLK_GOUT_GDC_SCSC              177
> +#define CLK_GOUT_CMU_HPM               178
> +#define CLK_GOUT_HSI0_BUS              179
> +#define CLK_GOUT_HSI0_DPGTC            180
> +#define CLK_GOUT_HSI0_USB31DRD         181
> +#define CLK_GOUT_HSI0_USBDPDGB         182
> +#define CLK_GOUT_HSI1_BUS              183
> +#define CLK_GOUT_HSI1_PCIE             184
> +#define CLK_GOUT_HSI2_BUS              185
> +#define CLK_GOUT_HSI2_MMC_CARD         186
> +#define CLK_GOUT_HSI2_PCIE             187
> +#define CLK_GOUT_HSI2_UFS_EMBD         188
> +#define CLK_GOUT_IPP_BUS               189
> +#define CLK_GOUT_ITP_BUS               190
> +#define CLK_GOUT_MCSC_ITSC             191
> +#define CLK_GOUT_MCSC_MCSC             192
> +#define CLK_GOUT_MFC_MFC               193
> +#define CLK_GOUT_MIF_BUSP              194
> +#define CLK_GOUT_MISC_BUS              195
> +#define CLK_GOUT_MISC_SSS              196
> +#define CLK_GOUT_PDP_BUS               197
> +#define CLK_GOUT_PDP_VRA               298
> +#define CLK_GOUT_G3AA                  299
> +#define CLK_GOUT_PERIC0_BUS            200
> +#define CLK_GOUT_PERIC0_IP             201
> +#define CLK_GOUT_PERIC1_BUS            202
> +#define CLK_GOUT_PERIC1_IP             203
> +#define CLK_GOUT_TNR_BUS               204
> +#define CLK_GOUT_TOP_CMUREF            205
> +#define CLK_GOUT_TPU_BUS               206
> +#define CLK_GOUT_TPU_TPU               207
> +#define CLK_GOUT_TPU_TPUCTL            208
> +#define CLK_GOUT_TPU_UART              209
> +
> +/* CMU_APM */
> +#define CLK_MOUT_APM_FUNC                                              1
> +#define CLK_MOUT_APM_FUNCSRC                                           2
> +#define CLK_DOUT_APM_BOOST                                             3
> +#define CLK_DOUT_APM_USI0_UART                                         4
> +#define CLK_DOUT_APM_USI0_USI                                          5
> +#define CLK_DOUT_APM_USI1_UART                                         6
> +#define CLK_GOUT_APM_APM_CMU_APM_IPCLKPORT_PCLK                                7
> +#define CLK_GOUT_BUS0_BOOST_OPTION1                                    8
> +#define CLK_GOUT_CMU_BOOST_OPTION1                                     9
> +#define CLK_GOUT_CORE_BOOST_OPTION1                                    10
> +#define CLK_GOUT_APM_FUNC                                              11
> +#define CLK_GOUT_APM_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK                   12
> +#define CLK_GOUT_APM_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK               13
> +#define CLK_GOUT_APM_APBIF_PMU_ALIVE_IPCLKPORT_PCLK                    14
> +#define CLK_GOUT_APM_APBIF_RTC_IPCLKPORT_PCLK                          15
> +#define CLK_GOUT_APM_APBIF_TRTC_IPCLKPORT_PCLK                         16
> +#define CLK_GOUT_APM_APM_USI0_UART_IPCLKPORT_IPCLK                     17
> +#define CLK_GOUT_APM_APM_USI0_UART_IPCLKPORT_PCLK                      18
> +#define CLK_GOUT_APM_APM_USI0_USI_IPCLKPORT_IPCLK                      19
> +#define CLK_GOUT_APM_APM_USI0_USI_IPCLKPORT_PCLK                       20
> +#define CLK_GOUT_APM_APM_USI1_UART_IPCLKPORT_IPCLK                     21
> +#define CLK_GOUT_APM_APM_USI1_UART_IPCLKPORT_PCLK                      22
> +#define CLK_GOUT_APM_D_TZPC_APM_IPCLKPORT_PCLK                         23
> +#define CLK_GOUT_APM_GPC_APM_IPCLKPORT_PCLK                            24
> +#define CLK_GOUT_APM_GREBEINTEGRATION_IPCLKPORT_HCLK                   25
> +#define CLK_GOUT_APM_INTMEM_IPCLKPORT_ACLK                             26
> +#define CLK_GOUT_APM_INTMEM_IPCLKPORT_PCLK                             27
> +#define CLK_GOUT_APM_LHM_AXI_G_SWD_IPCLKPORT_I_CLK                     28
> +#define CLK_GOUT_APM_LHM_AXI_P_AOCAPM_IPCLKPORT_I_CLK                  29
> +#define CLK_GOUT_APM_LHM_AXI_P_APM_IPCLKPORT_I_CLK                     30
> +#define CLK_GOUT_APM_LHS_AXI_D_APM_IPCLKPORT_I_CLK                     31
> +#define CLK_GOUT_APM_LHS_AXI_G_DBGCORE_IPCLKPORT_I_CLK                 32
> +#define CLK_GOUT_APM_LHS_AXI_G_SCAN2DRAM_IPCLKPORT_I_CLK               33
> +#define CLK_GOUT_APM_MAILBOX_APM_AOC_IPCLKPORT_PCLK                    34
> +#define CLK_GOUT_APM_MAILBOX_APM_AP_IPCLKPORT_PCLK                     35
> +#define CLK_GOUT_APM_MAILBOX_APM_GSA_IPCLKPORT_PCLK                    36
> +#define CLK_GOUT_APM_MAILBOX_APM_SWD_IPCLKPORT_PCLK                    37
> +#define CLK_GOUT_APM_MAILBOX_APM_TPU_IPCLKPORT_PCLK                    38
> +#define CLK_GOUT_APM_MAILBOX_AP_AOC_IPCLKPORT_PCLK                     39
> +#define CLK_GOUT_APM_MAILBOX_AP_DBGCORE_IPCLKPORT_PCLK         40

This value (40) is not aligned with the rest of values.

> +#define CLK_GOUT_APM_PMU_INTR_GEN_IPCLKPORT_PCLK                       41
> +#define CLK_GOUT_APM_ROM_CRC32_HOST_IPCLKPORT_ACLK                     42
> +#define CLK_GOUT_APM_ROM_CRC32_HOST_IPCLKPORT_PCLK                     43
> +#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_BUS_IPCLKPORT_CLK                        44
> +#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_USI0_UART_IPCLKPORT_CLK          45
> +#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_USI0_USI_IPCLKPORT_CLK           46
> +#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_USI1_UART_IPCLKPORT_CLK          47
> +#define CLK_GOUT_APM_SPEEDY_APM_IPCLKPORT_PCLK                         48
> +#define CLK_GOUT_APM_SPEEDY_SUB_APM_IPCLKPORT_PCLK                     49
> +#define CLK_GOUT_APM_SSMT_D_APM_IPCLKPORT_ACLK                         50
> +#define CLK_GOUT_APM_SSMT_D_APM_IPCLKPORT_PCLK                         51
> +#define CLK_GOUT_APM_SSMT_G_DBGCORE_IPCLKPORT_ACLK                     52
> +#define CLK_GOUT_APM_SSMT_G_DBGCORE_IPCLKPORT_PCLK                     53
> +#define CLK_GOUT_APM_SS_DBGCORE_IPCLKPORT_SS_DBGCORE_IPCLKPORT_HCLK    54
> +#define CLK_GOUT_APM_SYSMMU_D_APM_IPCLKPORT_CLK_S2                     55
> +#define CLK_GOUT_APM_SYSREG_APM_IPCLKPORT_PCLK                         56
> +#define CLK_GOUT_APM_UASC_APM_IPCLKPORT_ACLK                           57
> +#define CLK_GOUT_APM_UASC_APM_IPCLKPORT_PCLK                           58
> +#define CLK_GOUT_APM_UASC_DBGCORE_IPCLKPORT_ACLK                       59
> +#define CLK_GOUT_APM_UASC_DBGCORE_IPCLKPORT_PCLK                       60
> +#define CLK_GOUT_APM_UASC_G_SWD_IPCLKPORT_ACLK                         61
> +#define CLK_GOUT_APM_UASC_G_SWD_IPCLKPORT_PCLK                         62
> +#define CLK_GOUT_APM_UASC_P_AOCAPM_IPCLKPORT_ACLK                      63
> +#define CLK_GOUT_APM_UASC_P_AOCAPM_IPCLKPORT_PCLK                      64
> +#define CLK_GOUT_APM_UASC_P_APM_IPCLKPORT_ACLK                         65
> +#define CLK_GOUT_APM_UASC_P_APM_IPCLKPORT_PCLK                         66
> +#define CLK_GOUT_APM_WDT_APM_IPCLKPORT_PCLK                            67
> +#define CLK_GOUT_APM_XIU_DP_APM_IPCLKPORT_ACLK                         68
> +#define CLK_APM_PLL_DIV2_APM                                           69
> +#define CLK_APM_PLL_DIV4_APM                                           70
> +#define CLK_APM_PLL_DIV16_APM                                          71
> +
> +/* CMU_MISC */
> +

This empty line can be removed, for consistency with the rest of
similar comments in this file.

> +#define CLK_MOUT_MISC_BUS_USER                                 1
> +#define CLK_MOUT_MISC_SSS_USER                                 2
> +#define CLK_MOUT_MISC_GIC                                      3
> +#define CLK_DOUT_MISC_BUSP                                     4
> +#define CLK_DOUT_MISC_GIC                                      5
> +#define CLK_GOUT_MISC_MISC_CMU_MISC_IPCLKPORT_PCLK             6
> +#define CLK_GOUT_MISC_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK          7
> +#define CLK_GOUT_MISC_OTP_CON_BISR_IPCLKPORT_I_OSCCLK          8
> +#define CLK_GOUT_MISC_OTP_CON_TOP_IPCLKPORT_I_OSCCLK           9
> +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_OSCCLK_IPCLKPORT_CLK   10
> +#define CLK_GOUT_MISC_ADM_AHB_SSS_IPCLKPORT_HCLKM              11
> +#define CLK_GOUT_MISC_AD_APB_DIT_IPCLKPORT_PCLKM               12
> +#define CLK_GOUT_MISC_AD_APB_PUF_IPCLKPORT_PCLKM               13
> +#define CLK_GOUT_MISC_DIT_IPCLKPORT_ICLKL2A                    14
> +#define CLK_GOUT_MISC_D_TZPC_MISC_IPCLKPORT_PCLK               15
> +#define CLK_GOUT_MISC_GIC_IPCLKPORT_GICCLK                     16
> +#define CLK_GOUT_MISC_GPC_MISC_IPCLKPORT_PCLK                  17
> +#define CLK_GOUT_MISC_LHM_AST_ICC_CPUGIC_IPCLKPORT_I_CLK       18
> +#define CLK_GOUT_MISC_LHM_AXI_D_SSS_IPCLKPORT_I_CLK            19
> +#define CLK_GOUT_MISC_LHM_AXI_P_GIC_IPCLKPORT_I_CLK            20
> +#define CLK_GOUT_MISC_LHM_AXI_P_MISC_IPCLKPORT_I_CLK           21
> +#define CLK_GOUT_MISC_LHS_ACEL_D_MISC_IPCLKPORT_I_CLK          22
> +#define CLK_GOUT_MISC_LHS_AST_IRI_GICCPU_IPCLKPORT_I_CLK       23
> +#define CLK_GOUT_MISC_LHS_AXI_D_SSS_IPCLKPORT_I_CLK            24
> +#define CLK_GOUT_MISC_MCT_IPCLKPORT_PCLK                       25
> +#define CLK_GOUT_MISC_OTP_CON_BIRA_IPCLKPORT_PCLK              26
> +#define CLK_GOUT_MISC_OTP_CON_BISR_IPCLKPORT_PCLK              27
> +#define CLK_GOUT_MISC_OTP_CON_TOP_IPCLKPORT_PCLK               28
> +#define CLK_GOUT_MISC_PDMA_IPCLKPORT_ACLK                      29
> +#define CLK_GOUT_MISC_PPMU_DMA_IPCLKPORT_ACLK                  30
> +#define CLK_GOUT_MISC_PPMU_MISC_IPCLKPORT_ACLK                 31
> +#define CLK_GOUT_MISC_PPMU_MISC_IPCLKPORT_PCLK                 32
> +#define CLK_GOUT_MISC_PUF_IPCLKPORT_I_CLK                      33
> +#define CLK_GOUT_MISC_QE_DIT_IPCLKPORT_ACLK                    34
> +#define CLK_GOUT_MISC_QE_DIT_IPCLKPORT_PCLK                    35
> +#define CLK_GOUT_MISC_QE_PDMA_IPCLKPORT_ACLK                   36
> +#define CLK_GOUT_MISC_QE_PDMA_IPCLKPORT_PCLK                   37
> +#define CLK_GOUT_MISC_QE_PPMU_DMA_IPCLKPORT_ACLK               38
> +#define CLK_GOUT_MISC_QE_PPMU_DMA_IPCLKPORT_PCLK               39
> +#define CLK_GOUT_MISC_QE_RTIC_IPCLKPORT_ACLK                   40
> +#define CLK_GOUT_MISC_QE_RTIC_IPCLKPORT_PCLK                   41
> +#define CLK_GOUT_MISC_QE_SPDMA_IPCLKPORT_ACLK                  42
> +#define CLK_GOUT_MISC_QE_SPDMA_IPCLKPORT_PCLK                  43
> +#define CLK_GOUT_MISC_QE_SSS_IPCLKPORT_ACLK                    44
> +#define CLK_GOUT_MISC_QE_SSS_IPCLKPORT_PCLK                    45
> +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_BUSD_IPCLKPORT_CLK     46
> +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_BUSP_IPCLKPORT_CLK     47
> +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_GIC_IPCLKPORT_CLK      48
> +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_SSS_IPCLKPORT_CLK      49
> +#define CLK_GOUT_MISC_RTIC_IPCLKPORT_I_ACLK                    50
> +#define CLK_GOUT_MISC_RTIC_IPCLKPORT_I_PCLK                    51
> +#define CLK_GOUT_MISC_SPDMA_IPCLKPORT_ACLK                     52
> +#define CLK_GOUT_MISC_SSMT_DIT_IPCLKPORT_ACLK                  53
> +#define CLK_GOUT_MISC_SSMT_DIT_IPCLKPORT_PCLK                  54
> +#define CLK_GOUT_MISC_SSMT_PDMA_IPCLKPORT_ACLK                 55
> +#define CLK_GOUT_MISC_SSMT_PDMA_IPCLKPORT_PCLK                 56
> +#define CLK_GOUT_MISC_SSMT_PPMU_DMA_IPCLKPORT_ACLK             57
> +#define CLK_GOUT_MISC_SSMT_PPMU_DMA_IPCLKPORT_PCLK             58
> +#define CLK_GOUT_MISC_SSMT_RTIC_IPCLKPORT_ACLK                 59
> +#define CLK_GOUT_MISC_SSMT_RTIC_IPCLKPORT_PCLK                 60
> +#define CLK_GOUT_MISC_SSMT_SPDMA_IPCLKPORT_ACLK                        61
> +#define CLK_GOUT_MISC_SSMT_SPDMA_IPCLKPORT_PCLK                        62
> +#define CLK_GOUT_MISC_SSMT_SSS_IPCLKPORT_ACLK                  63
> +#define CLK_GOUT_MISC_SSMT_SSS_IPCLKPORT_PCLK                  64
> +#define CLK_GOUT_MISC_SSS_IPCLKPORT_I_ACLK                     65
> +#define CLK_GOUT_MISC_SSS_IPCLKPORT_I_PCLK                     66
> +#define CLK_GOUT_MISC_SYSMMU_MISC_IPCLKPORT_CLK_S2             67
> +#define CLK_GOUT_MISC_SYSMMU_SSS_IPCLKPORT_CLK_S1              68
> +#define CLK_GOUT_MISC_SYSREG_MISC_IPCLKPORT_PCLK               69
> +#define CLK_GOUT_MISC_TMU_SUB_IPCLKPORT_PCLK                   70
> +#define CLK_GOUT_MISC_TMU_TOP_IPCLKPORT_PCLK                   71
> +#define CLK_GOUT_MISC_WDT_CLUSTER0_IPCLKPORT_PCLK              72
> +#define CLK_GOUT_MISC_WDT_CLUSTER1_IPCLKPORT_PCLK              73
> +#define CLK_GOUT_MISC_XIU_D_MISC_IPCLKPORT_ACLK                        74
> +
> +#endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From semen.protsenko at linaro.org  Fri Dec  1 12:13:13 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 14:13:13 -0600
Subject: [PATCH v5 04/20] dt-bindings: watchdog: Document Google gs101
 watchdog bindings
In-Reply-To: <20231201160925.3136868-5-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-5-peter.griffin@linaro.org>
Message-ID: <CAPLW+4nNuRXB8a6M0dmWhFZYkSu62M_nAW3aBeV5wfedVLkraw@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:10?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Add the "google,gs101-wdt" compatible to the dt-schema documentation.
>
> gs101 SoC has two CPU clusters and each cluster has its own dedicated
> watchdog timer (similar to exynos850 and exynosautov9 SoCs).
>
> These WDT instances are controlled using different bits in PMU
> registers.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  .../devicetree/bindings/watchdog/samsung-wdt.yaml         | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
> index 8fb6656ba0c2..57468c2c5ece 100644
> --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
> @@ -17,6 +17,7 @@ description: |+
>  properties:
>    compatible:
>      enum:
> +      - google,gs101-wdt                      # for Google gs101
>        - samsung,s3c2410-wdt                   # for S3C2410
>        - samsung,s3c6410-wdt                   # for S3C6410, S5PV210 and Exynos4
>        - samsung,exynos5250-wdt                # for Exynos5250
> @@ -42,13 +43,14 @@ properties:
>    samsung,cluster-index:
>      $ref: /schemas/types.yaml#/definitions/uint32
>      description:
> -      Index of CPU cluster on which watchdog is running (in case of Exynos850)
> +      Index of CPU cluster on which watchdog is running (in case of Exynos850
> +      or Google gs101).
>
>    samsung,syscon-phandle:
>      $ref: /schemas/types.yaml#/definitions/phandle
>      description:
>        Phandle to the PMU system controller node (in case of Exynos5250,
> -      Exynos5420, Exynos7 and Exynos850).
> +      Exynos5420, Exynos7, Exynos850 and gs101).
>
>  required:
>    - compatible
> @@ -64,6 +66,7 @@ allOf:
>          compatible:
>            contains:
>              enum:
> +              - google,gs101-wdt
>                - samsung,exynos5250-wdt
>                - samsung,exynos5420-wdt
>                - samsung,exynos7-wdt
> @@ -77,6 +80,7 @@ allOf:
>          compatible:
>            contains:
>              enum:
> +              - google,gs101-wdt
>                - samsung,exynos850-wdt
>                - samsung,exynosautov9-wdt
>      then:
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From semen.protsenko at linaro.org  Fri Dec  1 12:22:14 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 14:22:14 -0600
Subject: [PATCH v5 05/20] dt-bindings: arm: google: Add bindings for
 Google ARM platforms
In-Reply-To: <20231201160925.3136868-6-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-6-peter.griffin@linaro.org>
Message-ID: <CAPLW+4mm8+U=wnXRfRG7QQHh02tiS3uo3Fw9ywYaCumV1qPB=g@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:10?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> This introduces bindings and dt-schema for the Google tensor SoCs.
> Currently just gs101 and pixel 6 are supported.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> Reviewed-by: Rob Herring <robh at kernel.org>
> ---

Other than spelling comments below:

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  .../devicetree/bindings/arm/google.yaml       | 53 +++++++++++++++++++
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> new file mode 100644
> index 000000000000..be191e70192d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/google.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/google.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Google Tensor platforms
> +
> +maintainers:
> +  - Peter Griffin <peter.griffin at linaro.org>
> +
> +description: |
> +  ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
> +  devices.
> +
> +  Currently upstream this is devices using "gs101" SoC which is found in Pixel
> +  6, Pixel 6 Pro and Pixel 6a.
> +
> +  Google have a few different names for the SoC.

Suggest removing period, or replacing it with colon.

> +  - Marketing name ("Tensor")
> +  - Codename ("Whitechapel")
> +  - SoC ID ("gs101")
> +  - Die ID ("S5P9845");

Semicolon seems off here.

> +
> +  Likewise there are a couple of names for the actual device
> +  - Marketing name ("Pixel 6")
> +  - Codename ("Oriole")
> +
> +  Devicetrees should use the lowercased SoC ID and lowercased board codename.

period -> comma

> +  e.g. gs101 and gs101-oriole

Missing period character.

> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +      - description: Google Pixel 6 / Oriole
> +        items:
> +          - enum:
> +              - google,gs101-oriole
> +          - const: google,gs101
> +
> +  # Bootloader requires empty ect node to be present
> +  ect:
> +    type: object
> +    additionalProperties: false
> +
> +required:
> +  - ect
> +
> +additionalProperties: true
> +
> +...
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From semen.protsenko at linaro.org  Fri Dec  1 12:25:13 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 14:25:13 -0600
Subject: [PATCH v5 07/20] dt-bindings: pinctrl: samsung: add
 gs101-wakeup-eint compatible
In-Reply-To: <20231201160925.3136868-8-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-8-peter.griffin@linaro.org>
Message-ID: <CAPLW+4kMHhh2++F9pU3VSxBo9H-r+79XB8eSc9yi+DR48C=8vQ@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:10?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
> where more than one pin controller can do external wake-up interrupt.
> So add a dedicated compatible for it.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> index 2bafa867aea2..de2209f8ba00 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> @@ -44,6 +44,7 @@ properties:
>            - const: samsung,exynos7-wakeup-eint
>        - items:
>            - enum:
> +              - google,gs101-wakeup-eint
>                - samsung,exynosautov9-wakeup-eint
>                - samsung,exynosautov920-wakeup-eint
>            - const: samsung,exynos850-wakeup-eint

(to myself): I wonder why exynos850 isn't in the enum above.

> @@ -111,6 +112,7 @@ allOf:
>          compatible:
>            contains:
>              enum:
> +              - google,gs101-wakeup-eint
>                - samsung,exynos850-wakeup-eint
>      then:
>        properties:
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From semen.protsenko at linaro.org  Fri Dec  1 12:39:25 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 14:39:25 -0600
Subject: [PATCH v5 10/20] dt-bindings: soc: samsung: usi: add
 google,gs101-usi compatible
In-Reply-To: <20231201160925.3136868-11-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-11-peter.griffin@linaro.org>
Message-ID: <CAPLW+4n+Gg6yzFeKVw+p5M-Lxznt8X-jrNQ9NoJojdDhvjiFHQ@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
>
> Add google,gs101-usi dedicated compatible for representing USI of Google
> GS101 SoC.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> index 61be1f2ddbe7..a10a438d89f0 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> @@ -28,6 +28,9 @@ properties:
>                - samsung,exynosautov9-usi
>                - samsung,exynosautov920-usi
>            - const: samsung,exynos850-usi
> +      - items:
> +          - const: google,gs101-usi
> +          - const: samsung,exynos850-usi
>        - enum:
>            - samsung,exynos850-usi

Krzysztof, Peter: can you please point me out the doc which explains
the need to have all those enums/consts here repeating for exynos850?
I kinda forgot why it's needed, can't find any documentation, and now
it just looks confusing to me.

>
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From heiko at sntech.de  Fri Dec  1 12:56:27 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Fri, 01 Dec 2023 21:56:27 +0100
Subject: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
In-Reply-To: <ZWo9ecC45DZaqVJJ@livingston.pivistrello.it>
References: <20231201191228.343230-1-heiko@sntech.de>
 <bf5c7806-7405-4728-bb10-7913368f62a0@gmail.com>
 <ZWo9ecC45DZaqVJJ@livingston.pivistrello.it>
Message-ID: <4075500.2IRrRt1zHL@diego>

Hi,

Am Freitag, 1. Dezember 2023, 21:09:29 CET schrieb Francesco Dolcini:
> On Fri, Dec 01, 2023 at 11:57:53AM -0800, Florian Fainelli wrote:
> > +Francesco,
> > 
> > On 12/1/23 11:12, Heiko Stuebner wrote:
> > > From: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > 
> > > Boards using socs like the rk3588 can use up to 10 uarts, so the default
> > > of 4 is way too low. Therefore increase the maximum number to 10.
> Do you have an actual need of 10, e.g. an existing board with 10 uarts
> enabled supported by the mainline kernel? Just thinking at the last arm64 SoC I
> am working with it should be 12 if we use this as a metric.

The rk3588 can do 10 (0-9), the board I'm working on is using up to uart7 (aka 8 uarts).
Reasoning below in the 3rd paragraph.


> > > SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
> > > data structures to prepare before registering them. This option can stay
> > > at its default value of 4 since for one it can be changed via a boot
> > > parameter 8250.nr_uarts but also since
> > > commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")
> > > 
> > > the kernel can register uarts dynamically that are above the
> > > SERIAL_8250_RUNTIME_UARTS threshold.
> > > 
> > > Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
> > 
> > There is a competing patch set from Francesco being submitted as well:
> > https://lore.kernel.org/all/20231201171544.1901-1-francesco at dolcini.it/
> >
> > looks like some coordination is necessary.

Thanks Florian for catching this coincidence.


> Yep, thanks Florian.
> 
> Heiko: should I include your needs in my patch? It looks like these are the
> days of the 8250 uart, I sent my patch just one day before yours.

yeah, I was surprised by the time overlap as well.

After reading up on NR_UARTS and NR_RUNTIME_UARTS I opted for going with
the maximum possible.

>From what I understood, increasing the runtime-uart-number would incur
overhead in terms of prepared data structures. But the core NR_UARTS
only seems to limit the actual maximum number of uarts in the system.

With the somewhat recent patch named above, even those can still be
registered without bad effects, so I opted with increasing the NR_UARTS
to the maximum to expect at some point, least the next board then needs
yet another patch.
But left the runtime number alone to not create overhead.


So TL;DR:
I could live with the 8 from your original patch, but I guess would prefer
going with a safer value, so the 10 or your 12 from above.

Because I guess if a controller is present, someone will use it
eventually ;-).


Heiko




From heiko at sntech.de  Fri Dec  1 13:03:07 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Fri, 01 Dec 2023 22:03:07 +0100
Subject: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
In-Reply-To: <4075500.2IRrRt1zHL@diego>
References: <20231201191228.343230-1-heiko@sntech.de>
 <ZWo9ecC45DZaqVJJ@livingston.pivistrello.it> <4075500.2IRrRt1zHL@diego>
Message-ID: <3923943.BzM5BlMlMQ@diego>

Am Freitag, 1. Dezember 2023, 21:56:27 CET schrieb Heiko St?bner:
> Hi,
> 
> Am Freitag, 1. Dezember 2023, 21:09:29 CET schrieb Francesco Dolcini:
> > On Fri, Dec 01, 2023 at 11:57:53AM -0800, Florian Fainelli wrote:
> > > +Francesco,
> > > 
> > > On 12/1/23 11:12, Heiko Stuebner wrote:
> > > > From: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > > 
> > > > Boards using socs like the rk3588 can use up to 10 uarts, so the default
> > > > of 4 is way too low. Therefore increase the maximum number to 10.
> > Do you have an actual need of 10, e.g. an existing board with 10 uarts
> > enabled supported by the mainline kernel? Just thinking at the last arm64 SoC I
> > am working with it should be 12 if we use this as a metric.
> 
> The rk3588 can do 10 (0-9), the board I'm working on is using up to uart7 (aka 8 uarts).
> Reasoning below in the 3rd paragraph.
> 
> 
> > > > SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
> > > > data structures to prepare before registering them. This option can stay
> > > > at its default value of 4 since for one it can be changed via a boot
> > > > parameter 8250.nr_uarts but also since
> > > > commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")
> > > > 
> > > > the kernel can register uarts dynamically that are above the
> > > > SERIAL_8250_RUNTIME_UARTS threshold.
> > > > 
> > > > Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > 
> > > There is a competing patch set from Francesco being submitted as well:
> > > https://lore.kernel.org/all/20231201171544.1901-1-francesco at dolcini.it/
> > >
> > > looks like some coordination is necessary.
> 
> Thanks Florian for catching this coincidence.
> 
> 
> > Yep, thanks Florian.
> > 
> > Heiko: should I include your needs in my patch? It looks like these are the
> > days of the 8250 uart, I sent my patch just one day before yours.
> 
> yeah, I was surprised by the time overlap as well.
> 
> After reading up on NR_UARTS and NR_RUNTIME_UARTS I opted for going with
> the maximum possible.
> 
> From what I understood, increasing the runtime-uart-number would incur
> overhead in terms of prepared data structures. But the core NR_UARTS
> only seems to limit the actual maximum number of uarts in the system.
> 
> With the somewhat recent patch named above, even those can still be
> registered without bad effects, so I opted with increasing the NR_UARTS
> to the maximum to expect at some point, least the next board then needs
> yet another patch.
> But left the runtime number alone to not create overhead.
> 
> 
> So TL;DR:
> I could live with the 8 from your original patch, but I guess would prefer
> going with a safer value, so the 10 or your 12 from above.
> 
> Because I guess if a controller is present, someone will use it
> eventually ;-).

and looking at other rk3588 boards the indiedroid-nova actually
uses the uart9 (aka the 10th uart) ;-)

Also the turing-rk1 and orangepi-5-plus as well.





From francesco at dolcini.it  Fri Dec  1 13:12:51 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri, 1 Dec 2023 22:12:51 +0100
Subject: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
In-Reply-To: <3923943.BzM5BlMlMQ@diego>
References: <20231201191228.343230-1-heiko@sntech.de>
 <ZWo9ecC45DZaqVJJ@livingston.pivistrello.it>
 <4075500.2IRrRt1zHL@diego>
 <3923943.BzM5BlMlMQ@diego>
Message-ID: <ZWpMU0fA8OYmcqdq@livingston.pivistrello.it>

On Fri, Dec 01, 2023 at 10:03:07PM +0100, Heiko St?bner wrote:
> Am Freitag, 1. Dezember 2023, 21:56:27 CET schrieb Heiko St?bner:
> > Hi,
> > 
> > Am Freitag, 1. Dezember 2023, 21:09:29 CET schrieb Francesco Dolcini:
> > > On Fri, Dec 01, 2023 at 11:57:53AM -0800, Florian Fainelli wrote:
> > > > +Francesco,
> > > > 
> > > > On 12/1/23 11:12, Heiko Stuebner wrote:
> > > > > From: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > > > 
> > > > > Boards using socs like the rk3588 can use up to 10 uarts, so the default
> > > > > of 4 is way too low. Therefore increase the maximum number to 10.
> > > Do you have an actual need of 10, e.g. an existing board with 10 uarts
> > > enabled supported by the mainline kernel? Just thinking at the last arm64 SoC I
> > > am working with it should be 12 if we use this as a metric.
> > 
> > The rk3588 can do 10 (0-9), the board I'm working on is using up to uart7 (aka 8 uarts).
> > Reasoning below in the 3rd paragraph.
> > 
> > 
> > > > > SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
> > > > > data structures to prepare before registering them. This option can stay
> > > > > at its default value of 4 since for one it can be changed via a boot
> > > > > parameter 8250.nr_uarts but also since
> > > > > commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")
> > > > > 
> > > > > the kernel can register uarts dynamically that are above the
> > > > > SERIAL_8250_RUNTIME_UARTS threshold.
> > > > > 
> > > > > Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > > 
> > > > There is a competing patch set from Francesco being submitted as well:
> > > > https://lore.kernel.org/all/20231201171544.1901-1-francesco at dolcini.it/
> > > >
> > > > looks like some coordination is necessary.
> > 
> > Thanks Florian for catching this coincidence.
> > 
> > 
> > > Yep, thanks Florian.
> > > 
> > > Heiko: should I include your needs in my patch? It looks like these are the
> > > days of the 8250 uart, I sent my patch just one day before yours.
> > 
> > yeah, I was surprised by the time overlap as well.
> > 
> > After reading up on NR_UARTS and NR_RUNTIME_UARTS I opted for going with
> > the maximum possible.
> > 
> > From what I understood, increasing the runtime-uart-number would incur
> > overhead in terms of prepared data structures. But the core NR_UARTS
> > only seems to limit the actual maximum number of uarts in the system.
> > 
> > With the somewhat recent patch named above, even those can still be
> > registered without bad effects, so I opted with increasing the NR_UARTS
> > to the maximum to expect at some point, least the next board then needs
> > yet another patch.
> > But left the runtime number alone to not create overhead.
> > 
> > 
> > So TL;DR:
> > I could live with the 8 from your original patch, but I guess would prefer
> > going with a safer value, so the 10 or your 12 from above.
> > 
> > Because I guess if a controller is present, someone will use it
> > eventually ;-).
> 
> and looking at other rk3588 boards the indiedroid-nova actually
> uses the uart9 (aka the 10th uart) ;-)

I think this is not relevant. It uses only 2 uart in total, it should just
works with the actual config.

Francesco



From konrad.dybcio at linaro.org  Fri Dec  1 13:34:22 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Fri, 1 Dec 2023 22:34:22 +0100
Subject: [PATCH V4 3/5] arm64: dts: qcom: Add base X1E80100 dtsi and the
 QCP dts
In-Reply-To: <20231130192619.29702-4-quic_sibis@quicinc.com>
References: <20231130192619.29702-1-quic_sibis@quicinc.com>
 <20231130192619.29702-4-quic_sibis@quicinc.com>
Message-ID: <24c6be96-fa79-46d9-be17-9eb198e215e3@linaro.org>

On 30.11.2023 20:26, Sibi Sankar wrote:
> From: Rajendra Nayak <quic_rjendra at quicinc.com>
> 
> Add base dtsi and QCP board (Qualcomm Compute Platform) dts file for
> X1E80100 SoC, describing the CPUs, GCC and RPMHCC clock controllers,
> geni UART, interrupt controller, TLMM, reserved memory, interconnects,
> SMMU and LLCC nodes.
> 
> Co-developed-by: Abel Vesa <abel.vesa at linaro.org>
> Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
> Signed-off-by: Rajendra Nayak <quic_rjendra at quicinc.com>
> Co-developed-by: Sibi Sankar <quic_sibis at quicinc.com>
> Signed-off-by: Sibi Sankar <quic_sibis at quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio at linaro.org>

Konrad


From ben.wolsieffer at hefring.com  Fri Dec  1 13:40:14 2023
From: ben.wolsieffer at hefring.com (Ben Wolsieffer)
Date: Fri,  1 Dec 2023 16:40:14 -0500
Subject: [PATCH] spi: stm32: enable controller before asserting CS
Message-ID: <20231201214014.2539031-1-ben.wolsieffer@hefring.com>

On the STM32F4/7, the SPI pins float while the controller is disabled.
Currently, the controller is enabled in the transfer_one() callback,
which runs after CS is asserted. Therefore, there is a period where the
SPI pins are floating while CS is asserted, making it possible for stray
signals to disrupt communications. An analogous problem occurs at the
end of the transfer when the controller is disabled before CS is
released.

This problem can be reliably observed by enabling the pull-up (if
CPOL=0) or pull-down (if CPOL=1) on the clock pin. This will cause two
extra unintended clock edges per transfer, when the controller is
enabled and disabled.

This patch fixes the bug by enabling the controller in prepare_message()
and disabling it in unprepare_message(), which are called while CS is
not asserted.

Note that bug is likely not present on the STM32H7, because it supports
the AFCNTR bit (and this driver sets it), which keeps the SPI pins
driven even while the controller is disabled.

This patch has been tested on an STM32F746 with a MAX14830 UART
expander.

Signed-off-by: Ben Wolsieffer <ben.wolsieffer at hefring.com>
---
 drivers/spi/spi-stm32.c | 14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index 94df3836834c..885f53a51441 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -948,10 +948,8 @@ static irqreturn_t stm32fx_spi_irq_event(int irq, void *dev_id)
 static irqreturn_t stm32fx_spi_irq_thread(int irq, void *dev_id)
 {
 	struct spi_controller *ctrl = dev_id;
-	struct stm32_spi *spi = spi_controller_get_devdata(ctrl);
 
 	spi_finalize_current_transfer(ctrl);
-	stm32fx_spi_disable(spi);
 
 	return IRQ_HANDLED;
 }
@@ -1118,6 +1116,8 @@ static int stm32_spi_prepare_msg(struct spi_controller *ctrl,
 			 ~clrb) | setb,
 			spi->base + spi->cfg->regs->cpol.reg);
 
+	stm32_spi_enable(spi);
+
 	spin_unlock_irqrestore(&spi->lock, flags);
 
 	return 0;
@@ -1135,7 +1135,6 @@ static void stm32fx_spi_dma_tx_cb(void *data)
 
 	if (spi->cur_comm == SPI_SIMPLEX_TX || spi->cur_comm == SPI_3WIRE_TX) {
 		spi_finalize_current_transfer(spi->ctrl);
-		stm32fx_spi_disable(spi);
 	}
 }
 
@@ -1150,7 +1149,6 @@ static void stm32_spi_dma_rx_cb(void *data)
 	struct stm32_spi *spi = data;
 
 	spi_finalize_current_transfer(spi->ctrl);
-	spi->cfg->disable(spi);
 }
 
 /**
@@ -1235,8 +1233,6 @@ static int stm32fx_spi_transfer_one_irq(struct stm32_spi *spi)
 
 	stm32_spi_set_bits(spi, STM32FX_SPI_CR2, cr2);
 
-	stm32_spi_enable(spi);
-
 	/* starting data transfer when buffer is loaded */
 	if (spi->tx_buf)
 		spi->cfg->write_tx(spi);
@@ -1273,8 +1269,6 @@ static int stm32h7_spi_transfer_one_irq(struct stm32_spi *spi)
 
 	spin_lock_irqsave(&spi->lock, flags);
 
-	stm32_spi_enable(spi);
-
 	/* Be sure to have data in fifo before starting data transfer */
 	if (spi->tx_buf)
 		stm32h7_spi_write_txfifo(spi);
@@ -1306,8 +1300,6 @@ static void stm32fx_spi_transfer_one_dma_start(struct stm32_spi *spi)
 		 */
 		stm32_spi_set_bits(spi, STM32FX_SPI_CR2, STM32FX_SPI_CR2_ERRIE);
 	}
-
-	stm32_spi_enable(spi);
 }
 
 /**
@@ -1341,8 +1333,6 @@ static void stm32h7_spi_transfer_one_dma_start(struct stm32_spi *spi)
 
 	stm32_spi_set_bits(spi, STM32H7_SPI_IER, ier);
 
-	stm32_spi_enable(spi);
-
 	if (STM32_SPI_MASTER_MODE(spi))
 		stm32_spi_set_bits(spi, STM32H7_SPI_CR1, STM32H7_SPI_CR1_CSTART);
 }
-- 
2.42.1



From broonie at kernel.org  Fri Dec  1 13:50:33 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 1 Dec 2023 21:50:33 +0000
Subject: [PATCH] spi: stm32: enable controller before asserting CS
In-Reply-To: <20231201214014.2539031-1-ben.wolsieffer@hefring.com>
References: <20231201214014.2539031-1-ben.wolsieffer@hefring.com>
Message-ID: <b070eb2a-05d7-4e6a-8de9-15179045d192@sirena.org.uk>

On Fri, Dec 01, 2023 at 04:40:14PM -0500, Ben Wolsieffer wrote:

> This patch fixes the bug by enabling the controller in prepare_message()
> and disabling it in unprepare_message(), which are called while CS is
> not asserted.

This feels like it'd be a good fit for moving to runtime PM - that way
we avoid bouncing the controller on and off between messages which is
probably better anyway.  The driver already does pinctrl management for
the device there.

> Note that bug is likely not present on the STM32H7, because it supports
> the AFCNTR bit (and this driver sets it), which keeps the SPI pins
> driven even while the controller is disabled.

It also occurs to me that this isn't going to work for devices which
chip select inverted - for them we can't stop driving chip select at all
since they need it held high when idle.  There aren't that many such
devices and it'd loose us the PM which is rather awkward...  I guess
that's an incremental issue with a more invasive fix though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/dacafb53/attachment.sig>

From willmcvicker at google.com  Fri Dec  1 14:40:31 2023
From: willmcvicker at google.com (William McVicker)
Date: Fri, 1 Dec 2023 14:40:31 -0800
Subject: [PATCH v5 00/20]  Add minimal Tensor/GS101 SoC support and
 Oriole/Pixel6 board
In-Reply-To: <20231201160925.3136868-1-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
Message-ID: <ZWpg31AEwd-C8F-R@google.com>

On 12/01/2023, Peter Griffin wrote:
> Hi folks,
> 
> Thanks to everyone who reviewed the previous rounds. V5 incorporates
> the review feedback received so far, and is rebased onto linux-next as
> per Krzysztof request to incorporate all his dt-binding changes for
> exynos.
> 
> As this series spans multiple subsytems the expectation is that Krzysztof
> will apply the whole series through the Samsung SoC tree. If the relevant
> subsystem maintainers can give a acked-by or reviewed-by on the relevant
> patches that would be most appreciated!
> 
> This series adds initial SoC support for the GS101 SoC and also initial board
> support for Pixel 6 phone (Oriole).
> 
> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> and therefore lots of the low level Exynos drivers can be re-used.
> 
> The support added in this series consists of:
> * cpus
> * pinctrl
> * CCF implementation of cmu_top, cmu_misc & cmu_apm
> * watchdog
> * USI uart
> * gpio
> 
> This is enough to boot through to a busybox initramfs and shell using an
> upstream kernel though :) More platform support will be added over the
> following weeks and months.
> 
> For further information on how to build and flash the upstream kernel on your
> Pixel 6, with a prebuilt busybox initramfs please refer to the script and
> README.md here:
> 
> https://git.codelinaro.org/linaro/googlelt/pixelscripts
> 
> Note: Booting without a dtbo works with some versions of the bootloader
> but crashes on others. Later versions aren't necessarily better. You can
> get the bootloader version with `fastboot getvar version-bootloader`
> Known good bootloader versions are: -
> - slider-1.3-11000330
> - slider-1.2-9152140
> Known to crash without dtbo
> - slider-1.3-10780582
> 
> kind regards,
> 
> Peter.
> 
> lore v4: https://lore.kernel.org/linux-arm-kernel/20231120212037.911774-1-peter.griffin at linaro.org/T/
> pw   v3: https://patchwork.kernel.org/project/linux-samsung-soc/cover/20231011184823.443959-1-peter.griffin at linaro.org/
> lore v2: https://lore.kernel.org/all/20231010224928.2296997-1-peter.griffin at linaro.org/
> lore v1: https://lore.kernel.org/linux-arm-kernel/20231005155618.700312-1-peter.griffin at linaro.org/
> 
> Changes since v4:
>  - clk-gs101: order cmu_top by register address, fix incorrect mux widths,
>    add missing mux/div/gates (Andre)
>  - google,gs101.h: add missing space in comment (Andre)
>  - ckl-gs101:google,gs101.h add all remaining gates for cmu_misc and cmu_apm
>  - update pmu dt labels (Krzysztof)
>  - Remove uart16 rts/tx gpio definitions (Krzysztof)
>  - Fixup various dts cosmetic nits (using consts, alignments,
>    names) (Sam/Krzysztof)
>  - Add more specific compatibles for arm cpu's and pmu (Sam)
>  - Use address-cells 1 and ranges property for SoC addresses (Sam)
>  - Encapsulate uart node in USI node (Sam)
>  - Remove earlycon from bootargs
>  - s3c2410_wdt: Reword QUIRK_HAS_DBGACK_BIT docs and add comment (Guenter)
>  - s3c2410_wdt: Reorder DBGACK_MASK functionality first, gs101
>    SoC second (Sam/Krzysztof)
>  
> Changes since v3:
>  - Add reviewed-by and tested-by tags
>  - google,gs101-clock.yaml: move Required to before Allof,
>    enum for cmu*top/misc (Krzysztof)
>  - samsung-wdt.yaml: stick to 80chars (Sam)
>  - google.yaml - remove new line
>  - samsung,pinctrl-wakeup-interrupt: sort alphabetically (RobH)
>  - gs101-oriole.dts: update gpio-keys pinctrl-0 phandle for keys (Stephen)
>  - samsung,exynos-sysreg.yaml - Alphabetical order (RobH)
>  - pinctrl-exynos: update/move comments, slight cosmetic changes (Sam)
>  - samsung_tty.c: update to generic drv_data name/macro (Arnd)
>  - samsung_uart.yaml: make samsung,uart-fifosize required for gs101-uart (Arnd)
>  - pinctrl-exynos: Remove eint irqs from alive pin controller node (Peter/Rob)
>  - Fixup kernel test robot unused const variable warnings
>  - clk-gs101: Update to mout_cmu_eh_bus to CLK_CON_MUX_MUX_CLKCMU_EH_BUS
>    (Chanwoo)
>  - clk-gs101: Update g3aa gout/dout/mout names to g3aa_g3aa for
>    consistency (Chanwoo)
>  - Remove .eint_gpio_init() cb on alive, alive_far, gsacore & gsactrl
>    banks (Sam)
>  - s3c2410_wdt: Drop windowed watchdog mode for now (Peter)
>  - s3c2410_wdt: Separate gs101 SoC support from dbgack feature (Sam)
>  - Move dts to arch/arm64/boot/dts/exynos/google directory (Krzysztof)
> 
> Changes since v2:
>  - Fixup pinctrl at 174d0000: interrupts: [..] is too long DTC warning (Tudor)
>  - Add missing windowed watchdog code (Guenter)
>  - Fixup UART YAML bindings error (Krzysztof)
>  - gs101.dtsi add missing serial_0 alias (me)
>  - samsung_tty.c: fixup gs101_serial_drv_data so fifosize is obtained from DT
>  
> Changes since v1:
>  - Remove irq/gs101.h and replace macros with irq numbers globally
>  - exynos-pmu - keep alphabetical order
>  - add cmu_apm to clock bindings documentation
>  - sysreg bindings - remove superfluous `google,gs101-sysreg`
>  - watchdog bindings - Alphanumerical order, update gs201 comment
>  - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
>  - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
>  - samsung,pinctrl- add google,gs101-wakeup-eint compatible
>  - clk-pll: fixup typos
>  - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
>  - clk-gs101: fix alphabetical order
>  - clk-gs101: cmu_apm: fixup typo and missing empty entry
>  - clk-gs101: cmu_misc: remove clocks that were being registered twice
>  - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON
>    bitfield
>  - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins
>    as well
>  - pinctrl: gs101: rename bank_type_6/7 structs to be more specific,
>    split from filter
>  - watchdog: s3c2410_wdt: remove dev_info prints
>  - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node
>    name, blank lines add SoC node, split dts and dtsi into separate patches,
>    remove 'DVT' suffix
>  - gs101-oriole.dtso: Remove overlay until board_id is documented properly
>  - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
>  - gpio-keys: update linux,code to use input-event-code macros
>  - add dedicated gs101-uart compatible
> 
> Peter Griffin (19):
>   dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
>   dt-bindings: clock: Add Google gs101 clock management unit bindings
>   dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
>     compatibles to GS101
>   dt-bindings: watchdog: Document Google gs101 watchdog bindings
>   dt-bindings: arm: google: Add bindings for Google ARM platforms
>   dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
>   dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
>   dt-bindings: serial: samsung: Add google-gs101-uart compatible
>   dt-bindings: serial: samsung: Make samsung,uart-fifosize required
>     property
>   clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
>   clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm support
>   pinctrl: samsung: Add filter selection support for alive banks
>   pinctrl: samsung: Add gs101 SoC pinctrl configuration
>   watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bit
>   watchdog: s3c2410_wdt: Add support for Google gs101 SoC
>   tty: serial: samsung: Add gs101 compatible and common
>     fifoszdt_serial_drv_data
>   arm64: dts: exynos: google: Add initial Google gs101 SoC support
>   arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
>   MAINTAINERS: add entry for Google Tensor SoC
> 
> Tudor Ambarus (1):
>   dt-bindings: soc: samsung: usi: add google,gs101-usi compatible
> 
>  .../devicetree/bindings/arm/google.yaml       |   53 +
>  .../bindings/clock/google,gs101-clock.yaml    |  110 +
>  .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
>  .../bindings/pinctrl/samsung,pinctrl.yaml     |    1 +
>  .../bindings/serial/samsung_uart.yaml         |   11 +
>  .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
>  .../bindings/soc/samsung/exynos-usi.yaml      |    3 +
>  .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
>  .../bindings/watchdog/samsung-wdt.yaml        |    8 +-
>  MAINTAINERS                                   |   10 +
>  arch/arm64/boot/dts/exynos/Makefile           |    2 +
>  arch/arm64/boot/dts/exynos/google/Makefile    |    4 +
>  .../boot/dts/exynos/google/gs101-oriole.dts   |  105 +
>  .../boot/dts/exynos/google/gs101-pinctrl.dtsi | 1250 +++++++++
>  .../boot/dts/exynos/google/gs101-pinctrl.h    |   33 +
>  arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  476 ++++
>  drivers/clk/samsung/Makefile                  |    1 +
>  drivers/clk/samsung/clk-gs101.c               | 2495 +++++++++++++++++
>  drivers/clk/samsung/clk-pll.c                 |    6 +
>  drivers/clk/samsung/clk-pll.h                 |    3 +
>  .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  159 ++
>  drivers/pinctrl/samsung/pinctrl-exynos.c      |   91 +-
>  drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
>  drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
>  drivers/pinctrl/samsung/pinctrl-samsung.h     |   23 +
>  drivers/tty/serial/samsung_tty.c              |   16 +
>  drivers/watchdog/s3c2410_wdt.c                |   74 +-
>  include/dt-bindings/clock/google,gs101.h      |  392 +++
>  28 files changed, 5370 insertions(+), 11 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
>  create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>  create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi
>  create mode 100644 drivers/clk/samsung/clk-gs101.c
>  create mode 100644 include/dt-bindings/clock/google,gs101.h
> 
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 

Thanks Peter for the updated patch series! I've gone through and reviewed the
changes and tested them on my Oriole device. I was able to boot to the busybox
console and verify the appropriate drivers probed.

Great work!

Regards,
Will



From justin.chen at broadcom.com  Fri Dec  1 14:59:45 2023
From: justin.chen at broadcom.com (Justin Chen)
Date: Fri, 1 Dec 2023 14:59:45 -0800
Subject: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
In-Reply-To: <20231201130702.2824115c@gandalf.local.home>
References: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
 <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
 <81af85b4-5274-4362-9413-890425c60524@broadcom.com>
 <20231201130702.2824115c@gandalf.local.home>
Message-ID: <4597db06-dabc-4bb2-9f24-bd30e07ff86d@broadcom.com>



On 12/1/23 10:07 AM, Steven Rostedt wrote:
> On Fri, 1 Dec 2023 09:25:59 -0800
> Justin Chen <justin.chen at broadcom.com> wrote:
> 
>>> It appears the sub instruction at 0x6dd0 correctly accounts for the
>>> extra 8 bytes, so the frame pointer is valid. So it is our assumption
>>> that there are no gaps between the stack frames is invalid.
>>
>> Thanks for the assistance. The gap between the stack frame depends on
>> the function. Most do not have a gap. Some have 8 (as shown above), some
>> have 12. A single assumption here is not going to work. I'm having a
>> hard time finding out the reasoning for this gap. I tried disabling a
>> bunch of gcc flags as well as -O2 and the gap still exists.
> 
> That code was originally added because of some strange things that gcc did
> with mcount (for example, it made a copy of the stack frame that it passed
> to mcount, where the function graph tracer replaced the copy of the return
> stack making the shadow stack go out of sync and crash). This was very hard
> to debug and I added this code to detect it if it happened again.
> 
> Well it's been over a decade since that happened (2009).
> 
>    71e308a239c09 ("function-graph: add stack frame test")
> 
> I'm happy assuming that the compiler folks are aware of our tricks with
> hijacking return calls and I don't expect it to happen again. We can just
> rip out those checks. That is, if it's only causing false positives, I
> don't think it's worth keeping around.
> 
> Has it detected any real issues on the Arm platforms?
> 
> -- Steve

I am not familiar enough to make a call. But from my limited testing 
with ARM, I didn't see any issues. If you would like me to, I can submit 
a patch to remove the check entirely. Or maybe only disable it for ARM?

Thanks,
Justin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231201/bc8ea37a/attachment-0001.p7s>

From ben.wolsieffer at hefring.com  Fri Dec  1 15:11:36 2023
From: ben.wolsieffer at hefring.com (Ben Wolsieffer)
Date: Fri, 1 Dec 2023 18:11:36 -0500
Subject: [PATCH] spi: stm32: enable controller before asserting CS
In-Reply-To: <b070eb2a-05d7-4e6a-8de9-15179045d192@sirena.org.uk>
References: <20231201214014.2539031-1-ben.wolsieffer@hefring.com>
 <b070eb2a-05d7-4e6a-8de9-15179045d192@sirena.org.uk>
Message-ID: <ZWpoKEcM0ZeYAsBa@dell-precision-5540>

On Fri, Dec 01, 2023 at 09:50:33PM +0000, Mark Brown wrote:
> On Fri, Dec 01, 2023 at 04:40:14PM -0500, Ben Wolsieffer wrote:
> 
> This feels like it'd be a good fit for moving to runtime PM - that way
> we avoid bouncing the controller on and off between messages which is
> probably better anyway.  The driver already does pinctrl management for
> the device there.

Yes, that probably makes sense. There are a few bits that can only be
configured while the controller is disabled, but it doesn't look like
that applies to any of the ones set in stm32_spi_prepare_msg().

I'm a little hesitant to make big changes to the driver since I can only
test them on an STM32F7 though.

> It also occurs to me that this isn't going to work for devices which
> chip select inverted - for them we can't stop driving chip select at all
> since they need it held high when idle.  There aren't that many such
> devices and it'd loose us the PM which is rather awkward...  I guess
> that's an incremental issue with a more invasive fix though.

The driver only supports GPIO chip select rather than native, so I don't
think this is a problem. Also, I don't think there's any difference
between inverted or uninverted here. They both either need to be driven
all the time or have pull-up/downs.

Ben


From nm at ti.com  Fri Dec  1 15:26:14 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 1 Dec 2023 17:26:14 -0600
Subject: [PATCH v2] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <ZWo5kVMoLTzST6F5@livingston.pivistrello.it>
References: <20231201171544.1901-1-francesco@dolcini.it>
 <20231201191958.kmwkpmttmebsas47@kooky>
 <ZWo5kVMoLTzST6F5@livingston.pivistrello.it>
Message-ID: <20231201232614.jvj4d5nu7j2xf5ia@ability>

On 20:52-20231201, Francesco Dolcini wrote:
> On Fri, Dec 01, 2023 at 01:19:58PM -0600, Nishanth Menon wrote:
> > On 18:15-20231201, Francesco Dolcini wrote:
> > > Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
> > > is not adequate for embedded systems that use SoCs where it's common to
> > > have a large number of serial ports.
> > > 
> > > No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
> > > ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
> > > 
> > > The need to increase this value was noticed while working with Toradex
> > > Verdin AM62, this board has 4 serial UART instances available to the user
> > > plus an internal one that is connected to a Bluetooth module. Without this
> > > change the fifth UART connected to the BT module is not instantiated and BT
> > > is not working.
> > > 
> > > Instead of increasing the number to the bare minimum (5) that would be
> > > required to solve this specific issue, we increase this to 8 which seems a
> > > more reasonable number to have in the defconfig and should cover more valid
> > > use cases.
> > 
> > To address Arnd's concern on size increase, it will be good to add:
> 
> I can and I will add it in a v3 - it takes less time to do it than reply to
> this email and thanks for taking the time to provide the actual data.
> 
> With that said my understanding is that the goal of the arm64 defconfig is
> to enable the supported arm64 hardware and the related kernel development.
> It's not supposed to be a minimal config in size nor an optimal
> configuration from the performance point of view. It's a single
> configuration that includes support for each and every platform [1]
> supported by Linux arm64 ...
> 
> To me Arnd was just stating a fact, not raising a concern that was supposed
> to be addressed (just correct me if I'm wrong, of course).
> 
> [1] well, apart AMD Pensando and Bitmain, at the moment, but you get the
> point, I'm sure ;-).
> 

Hehe, thanks Francesco.

Arnd, my memory was a bit right on the topic though.. .. I think we
had gone down a similar road before in trying to increase the number
of 8250 UARTs [1] but without this strong a reason.. Been a while, I
think our v3 is much stronger case now.

[1] https://lore.kernel.org/all/CAK8P3a2VSBvOn1o+q1PYZaQ6LS9U4cz+DZGuDbisHkwNs2dAAw at mail.gmail.com/#t
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From william at wkennington.com  Fri Dec  1 15:51:35 2023
From: william at wkennington.com (William Kennington)
Date: Fri, 1 Dec 2023 15:51:35 -0800
Subject: [PATCH v2] ARM: npcm: Add CPU hotplug callbacks for kexec support
In-Reply-To: <20231102101009.15104-1-william@wkennington.com>
References: <20231102002453.1299195-1-william@wkennington.com> <20231102101009.15104-1-william@wkennington.com>
Message-ID: <CAD_4BXgmCdc_H-XfmGnW3fa6H=cbONma6QzUiofNVZWJtcBwOg@mail.gmail.com>

On Thu, Nov 2, 2023 at 3:10?AM William A. Kennington III
<william at wkennington.com> wrote:
>
> From: Brian Ma <chma0 at nuvoton.com>
>
> Add callbacks required for kexec to function. The NPCM7xx does
> not expose controls for powering down CPU cores, so just wait in idle
> loop.
>
> Signed-off-by: Brian Ma <chma0 at nuvoton.com>
> Signed-off-by: William A. Kennington III <william at wkennington.com>
> ---
>  arch/arm/mach-npcm/platsmp.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/mach-npcm/platsmp.c b/arch/arm/mach-npcm/platsmp.c
> index 41891d3aa124..6cc7b5894f08 100644
> --- a/arch/arm/mach-npcm/platsmp.c
> +++ b/arch/arm/mach-npcm/platsmp.c
> @@ -69,10 +69,27 @@ static void __init npcm7xx_smp_prepare_cpus(unsigned int max_cpus)
>
>         iounmap(scu_base);
>  }
> +#ifdef CONFIG_HOTPLUG_CPU
> +static void npcm7xx_cpu_die(unsigned int cpu)
> +{
> +       while (1)
> +               cpu_do_idle();
> +}
> +
> +static int npcm7xx_cpu_kill(unsigned int l_cpu)
> +{
> +       return 1;
> +}
> +#endif
> +
>
>  static struct smp_operations npcm7xx_smp_ops __initdata = {
>         .smp_prepare_cpus = npcm7xx_smp_prepare_cpus,
>         .smp_boot_secondary = npcm7xx_smp_boot_secondary,
> +#ifdef CONFIG_HOTPLUG_CPU
> +       .cpu_die                        = npcm7xx_cpu_die,
> +       .cpu_kill                       = npcm7xx_cpu_kill,
> +#endif
>  };
>
>  CPU_METHOD_OF_DECLARE(npcm7xx_smp, "nuvoton,npcm750-smp", &npcm7xx_smp_ops);
> --
> 2.42.0.820.g83a721a137-goog
>'

Mind taking another look? This should be updated accordingly.


From willmcvicker at google.com  Fri Dec  1 15:55:24 2023
From: willmcvicker at google.com (William McVicker)
Date: Fri, 1 Dec 2023 15:55:24 -0800
Subject: [PATCH v5 13/20] pinctrl: samsung: Add filter selection support
 for alive banks
In-Reply-To: <20231201160925.3136868-14-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-14-peter.griffin@linaro.org>
Message-ID: <ZWpybAkHVYGzWKL0@google.com>

On 12/01/2023, Peter Griffin wrote:
> Newer Exynos SoCs have a filter selection register on alive bank pins.
> This allows the selection of a digital or delay filter for each pin. If
> the filter selection register is not available then the default filter
> (digital) is applied.
> 
> On suspend we apply the analog filter to all pins in the bank (as the
> digital filter relies on a clock). On resume the digital filter is
> reapplied to all pins in the bank. The digital filter is working via
> clock and has an adjustable filter delay register bitfield, whereas
> the analog filter uses a fixed delay.
> 
> The filter determines to what extent signal fluctuations received through
> the pad are considered glitches.
> 
> The code path can be exercised using
> echo mem > /sys/power/state
> And then wake the device using a eint gpio
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Tested-by: Will McVicker <willmcvicker at google.com>

--

I verified boot and that the pinctrl driver is probing. When I tested

  echo mem > /sys/power/state

I wasn't able to re-wake the device (not sure how to send an eint gpio on
a phone form factor). I tried with no_console_suspend but that hits a SError
Interrupt (likely due to a PMU secure register access). Let me know if there's
anything else I should test out.

Thanks,
Will

> ---
>  drivers/pinctrl/samsung/pinctrl-exynos.c  | 89 ++++++++++++++++++++++-
>  drivers/pinctrl/samsung/pinctrl-exynos.h  |  7 ++
>  drivers/pinctrl/samsung/pinctrl-samsung.c |  2 +
>  drivers/pinctrl/samsung/pinctrl-samsung.h | 22 ++++++
>  4 files changed, 119 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index 6b58ec84e34b..56fc11a1fe2f 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -269,6 +269,71 @@ struct exynos_eint_gpio_save {
>  	u32 eint_mask;
>  };
>  
> +/*
> + * Set the desired filter (digital or analog delay) to every pin in
> + * the bank. Note the filter selection bitfield is only found on alive
> + * banks. The filter determines to what extent signal fluctuations
> + * received through the pad are considered glitches.
> + */
> +static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
> +				   struct samsung_pin_bank *bank, int filter)
> +{
> +	unsigned int flt_reg, flt_con = 0;
> +	unsigned int val, shift;
> +	int i;
> +	int loop_cnt;
> +
> +	/*
> +	 * The FLTCON register has the following layout
> +	 *
> +	 * BitfieldName[PinNum][Bit:Bit]
> +	 * FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
> +	 * FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
> +	 * FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
> +	 * FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
> +	 *
> +	 * FLT_EN	0x0 = Disable, 0x1=Enable
> +	 * FLT_SEL	0x0 = Delay filter, 0x1 Digital filter
> +	 * FLT_WIDTH	Filtering width. Valid when FLT_SEL is 0x1
> +	 */
> +
> +	flt_con |= EXYNOS9_FLTCON_EN;
> +
> +	if (filter)
> +		flt_con |= EXYNOS9_FLTCON_DIGITAL;
> +
> +	flt_reg = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
> +
> +	/*
> +	 * If nr_pins > 4, we should set FLTCON0 register fully.
> +	 * (pin0 ~ 3). So loop 4 times in case of FLTCON0.
> +	 */
> +	if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN)
> +		loop_cnt = EXYNOS9_FLTCON_NR_PIN;
> +	else
> +		loop_cnt = bank->nr_pins;
> +
> +	val = readl(d->virt_base + flt_reg);
> +	for (i = 0; i < loop_cnt; i++) {
> +		shift = i * EXYNOS9_FLTCON_LEN;
> +		val &= ~(EXYNOS9_FLTCON_MASK << shift);
> +		val |= (flt_con << shift);
> +	}
> +	writel(val, d->virt_base + flt_reg);
> +
> +	/* Loop for FLTCON1 pin 4 ~ 7 */
> +	if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN) {
> +		loop_cnt = (bank->nr_pins - EXYNOS9_FLTCON_NR_PIN);
> +		val = readl(d->virt_base + flt_reg + 0x4);
> +		for (i = 0; i < loop_cnt; i++) {
> +			shift = i * EXYNOS9_FLTCON_LEN;
> +			val &= ~(EXYNOS9_FLTCON_MASK << shift);
> +			val |= (flt_con << shift);
> +		}
> +		writel(val, d->virt_base + flt_reg + 0x4);
> +	}
> +}
> +
>  /*
>   * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
>   * @d: driver data of samsung pinctrl driver.
> @@ -321,6 +386,10 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
>  			goto err_domains;
>  		}
>  
> +		/* Set Delay Analog Filter */
> +		if (bank->fltcon_type != FLT_DEFAULT)
> +			exynos_eint_flt_config(d, bank,
> +					       EXYNOS9_FLTCON_DELAY);
>  	}
>  
>  	return 0;
> @@ -555,6 +624,11 @@ __init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
>  		if (bank->eint_type != EINT_TYPE_WKUP)
>  			continue;
>  
> +		/* Set Digital Filter */
> +		if (bank->fltcon_type != FLT_DEFAULT)
> +			exynos_eint_flt_config(d, bank,
> +					       EXYNOS9_FLTCON_DIGITAL);
> +
>  		bank->irq_chip = devm_kmemdup(dev, irq_chip, sizeof(*irq_chip),
>  					      GFP_KERNEL);
>  		if (!bank->irq_chip) {
> @@ -658,6 +732,7 @@ static void exynos_pinctrl_suspend_bank(
>  void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
>  {
>  	struct samsung_pin_bank *bank = drvdata->pin_banks;
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
>  	struct exynos_irq_chip *irq_chip = NULL;
>  	int i;
>  
> @@ -665,6 +740,10 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
>  		if (bank->eint_type == EINT_TYPE_GPIO)
>  			exynos_pinctrl_suspend_bank(drvdata, bank);
>  		else if (bank->eint_type == EINT_TYPE_WKUP) {
> +			/* Setting Delay (Analog) Filter */
> +			if (bank->fltcon_type != FLT_DEFAULT)
> +				exynos_eint_flt_config(d, bank,
> +						       EXYNOS9_FLTCON_DELAY);
>  			if (!irq_chip) {
>  				irq_chip = bank->irq_chip;
>  				irq_chip->set_eint_wakeup_mask(drvdata,
> @@ -707,11 +786,19 @@ static void exynos_pinctrl_resume_bank(
>  void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
>  {
>  	struct samsung_pin_bank *bank = drvdata->pin_banks;
> +	struct samsung_pinctrl_drv_data *d = bank->drvdata;
>  	int i;
>  
>  	for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
> -		if (bank->eint_type == EINT_TYPE_GPIO)
> +		if (bank->eint_type == EINT_TYPE_GPIO) {
>  			exynos_pinctrl_resume_bank(drvdata, bank);
> +		} else if (bank->eint_type == EINT_TYPE_WKUP ||
> +			   bank->eint_type == EINT_TYPE_WKUP_MUX) {
> +			/* Set Digital Filter */
> +			if (bank->fltcon_type != FLT_DEFAULT)
> +				exynos_eint_flt_config(d, bank,
> +						       EXYNOS9_FLTCON_DIGITAL);
> +		}
>  }
>  
>  static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
> index 3ac52c2cf998..e2799ff1b5e9 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
> @@ -50,6 +50,13 @@
>  
>  #define EXYNOS_EINT_MAX_PER_BANK	8
>  #define EXYNOS_EINT_NR_WKUP_EINT
> +/* EINT filter configuration */
> +#define EXYNOS9_FLTCON_EN		BIT(7)
> +#define EXYNOS9_FLTCON_DIGITAL		BIT(6)
> +#define EXYNOS9_FLTCON_DELAY		(0 << 6)
> +#define EXYNOS9_FLTCON_MASK		0xff
> +#define EXYNOS9_FLTCON_LEN		8
> +#define EXYNOS9_FLTCON_NR_PIN		4
>  
>  #define EXYNOS_PIN_BANK_EINTN(pins, reg, id)		\
>  	{						\
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 79babbb39ced..50c360b4753a 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -1105,6 +1105,8 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
>  		bank->eint_func = bdata->eint_func;
>  		bank->eint_type = bdata->eint_type;
>  		bank->eint_mask = bdata->eint_mask;
> +		bank->fltcon_type = bdata->fltcon_type;
> +		bank->fltcon_offset = bdata->fltcon_offset;
>  		bank->eint_offset = bdata->eint_offset;
>  		bank->name = bdata->name;
>  
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> index 9b3db50adef3..5fab3885a7d7 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> @@ -82,6 +82,20 @@ enum eint_type {
>  	EINT_TYPE_WKUP_MUX,
>  };
>  
> +/**
> + * enum fltcon_type - filter selection
> + * @FLT_DEFAULT: filter not selectable, default digital filter
> + * @FLT_SELECT: filter selectable (digital or delay)
> + *
> + * Some banks on newer Exynos based SoCs have a selectable filter on alive
> + * banks of 'analog/delay' or 'digital'. If the filter selection register is
> + * not available then the default filter is used (digital).
> + */
> +enum fltcon_type {
> +	FLT_DEFAULT,
> +	FLT_SELECTABLE,
> +};
> +
>  /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
>  #define PIN_NAME_LENGTH	10
>  
> @@ -122,6 +136,8 @@ struct samsung_pin_bank_type {
>   * @eint_type: type of the external interrupt supported by the bank.
>   * @eint_mask: bit mask of pins which support EINT function.
>   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> + * @fltcon_type: whether the filter (delay/digital) is selectable
> + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
>   * @name: name to be prefixed for each pin in this pin bank.
>   */
>  struct samsung_pin_bank_data {
> @@ -133,6 +149,8 @@ struct samsung_pin_bank_data {
>  	enum eint_type	eint_type;
>  	u32		eint_mask;
>  	u32		eint_offset;
> +	enum fltcon_type fltcon_type;
> +	u32		fltcon_offset;
>  	const char	*name;
>  };
>  
> @@ -147,6 +165,8 @@ struct samsung_pin_bank_data {
>   * @eint_type: type of the external interrupt supported by the bank.
>   * @eint_mask: bit mask of pins which support EINT function.
>   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> + * @fltcon_type: whether the filter (delay/digital) is selectable
> + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
>   * @name: name to be prefixed for each pin in this pin bank.
>   * @id: id of the bank, propagated to the pin range.
>   * @pin_base: starting pin number of the bank.
> @@ -170,6 +190,8 @@ struct samsung_pin_bank {
>  	enum eint_type	eint_type;
>  	u32		eint_mask;
>  	u32		eint_offset;
> +	enum fltcon_type fltcon_type;
> +	u32		fltcon_offset;
>  	const char	*name;
>  	u32		id;
>  
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 


From willmcvicker at google.com  Fri Dec  1 15:57:40 2023
From: willmcvicker at google.com (William McVicker)
Date: Fri, 1 Dec 2023 15:57:40 -0800
Subject: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl
 configuration
In-Reply-To: <20231201160925.3136868-15-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-15-peter.griffin@linaro.org>
Message-ID: <ZWpy9EChMRswXxv3@google.com>

On 12/01/2023, Peter Griffin wrote:
> Add support for the pin-controller found on the gs101 SoC used in
> Pixel 6 phones.
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Tested-by: Will McVicker <willmcvicker at google.com>

---

I verified boot and that the pinctrl probes.

Regards,
Will

> ---
>  .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 159 ++++++++++++++++++
>  drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
>  drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
>  drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
>  drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
>  5 files changed, 198 insertions(+)
> 
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> index cb965cf93705..e1a0668ecb16 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> @@ -796,3 +796,162 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
>  	.ctrl		= fsd_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
>  };
> +
> +/*
> + * bank type for non-alive type
> + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
> + * (CONPDN bit field: 2, PUDPDN bit field: 4)
> + */
> +static struct samsung_pin_bank_type gs101_bank_type_off  = {
> +	.fld_width = { 4, 1, 4, 4, 2, 4, },
> +	.reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
> +};
> +
> +/*
> + * bank type for alive type
> + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
> + */
> +static const struct samsung_pin_bank_type gs101_bank_type_alive = {
> +	.fld_width = { 4, 1, 4, 4, },
> +	.reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
> +};
> +
> +/* pin banks of gs101 pin-controller (ALIVE) */
> +static const struct samsung_pin_bank_data gs101_pin_alive[] = {
> +	EXYNOS9_PIN_BANK_EINTW(8, 0x0, "gpa0", 0x00, 0x00),
> +	EXYNOS9_PIN_BANK_EINTW(7, 0x20, "gpa1", 0x04, 0x08),
> +	EXYNOS9_PIN_BANK_EINTW(5, 0x40, "gpa2", 0x08, 0x10),
> +	EXYNOS9_PIN_BANK_EINTW(4, 0x60, "gpa3", 0x0c, 0x18),
> +	EXYNOS9_PIN_BANK_EINTW(4, 0x80, "gpa4", 0x10, 0x1c),
> +	EXYNOS9_PIN_BANK_EINTW(7, 0xa0, "gpa5", 0x14, 0x20),
> +	EXYNOS9_PIN_BANK_EINTW(8, 0xc0, "gpa9", 0x18, 0x28),
> +	EXYNOS9_PIN_BANK_EINTW(2, 0xe0, "gpa10", 0x1c, 0x30),
> +};
> +
> +/* pin banks of gs101 pin-controller (FAR_ALIVE) */
> +static const struct samsung_pin_bank_data gs101_pin_far_alive[] = {
> +	EXYNOS9_PIN_BANK_EINTW(8, 0x0, "gpa6", 0x00, 0x00),
> +	EXYNOS9_PIN_BANK_EINTW(4, 0x20, "gpa7", 0x04, 0x08),
> +	EXYNOS9_PIN_BANK_EINTW(8, 0x40, "gpa8", 0x08, 0x0c),
> +	EXYNOS9_PIN_BANK_EINTW(2, 0x60, "gpa11", 0x0c, 0x14),
> +};
> +
> +/* pin banks of gs101 pin-controller (GSACORE) */
> +static const struct samsung_pin_bank_data gs101_pin_gsacore[] = {
> +	EXYNOS9_PIN_BANK_EINTG(2, 0x0, "gps0", 0x00, 0x00),
> +	EXYNOS9_PIN_BANK_EINTG(8, 0x20, "gps1", 0x04, 0x04),
> +	EXYNOS9_PIN_BANK_EINTG(3, 0x40, "gps2", 0x08, 0x0c),
> +};
> +
> +/* pin banks of gs101 pin-controller (GSACTRL) */
> +static const struct samsung_pin_bank_data gs101_pin_gsactrl[] = {
> +	EXYNOS9_PIN_BANK_EINTW(6, 0x0, "gps3", 0x00, 0x00),
> +};
> +
> +/* pin banks of gs101 pin-controller (PERIC0) */
> +static const struct samsung_pin_bank_data gs101_pin_peric0[] = {
> +	EXYNOS9_PIN_BANK_EINTG(5, 0x0, "gpp0", 0x00, 0x00),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x20, "gpp1", 0x04, 0x08),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x40, "gpp2", 0x08, 0x0c),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0x60, "gpp3", 0x0c, 0x10),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x80, "gpp4", 0x10, 0x14),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0xa0, "gpp5", 0x14, 0x18),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0xc0, "gpp6", 0x18, 0x1c),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0xe0, "gpp7", 0x1c, 0x20),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x100, "gpp8", 0x20, 0x24),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0x120, "gpp9", 0x24, 0x28),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x140, "gpp10", 0x28, 0x2c),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0x160, "gpp11", 0x2c, 0x30),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x180, "gpp12", 0x30, 0x34),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0x1a0, "gpp13", 0x34, 0x38),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x1c0, "gpp14", 0x38, 0x3c),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0x1e0, "gpp15", 0x3c, 0x40),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x200, "gpp16", 0x40, 0x44),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0x220, "gpp17", 0x44, 0x48),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x240, "gpp18", 0x48, 0x4c),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x260, "gpp19", 0x4c, 0x50),
> +};
> +
> +/* pin banks of gs101 pin-controller (PERIC1) */
> +static const struct samsung_pin_bank_data gs101_pin_peric1[] = {
> +	EXYNOS9_PIN_BANK_EINTG(8, 0x0, "gpp20", 0x00, 0x00),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x20, "gpp21", 0x04, 0x08),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0x40, "gpp22", 0x08, 0x0c),
> +	EXYNOS9_PIN_BANK_EINTG(8, 0x60, "gpp23", 0x0c, 0x10),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0x80, "gpp24", 0x10, 0x18),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0xa0, "gpp25", 0x14, 0x1c),
> +	EXYNOS9_PIN_BANK_EINTG(5, 0xc0, "gpp26", 0x18, 0x20),
> +	EXYNOS9_PIN_BANK_EINTG(4, 0xe0, "gpp27", 0x1c, 0x28),
> +};
> +
> +/* pin banks of gs101 pin-controller (HSI1) */
> +static const struct samsung_pin_bank_data gs101_pin_hsi1[] = {
> +	EXYNOS9_PIN_BANK_EINTG(6, 0x0, "gph0", 0x00, 0x00),
> +	EXYNOS9_PIN_BANK_EINTG(7, 0x20, "gph1", 0x04, 0x08),
> +};
> +
> +/* pin banks of gs101 pin-controller (HSI2) */
> +static const struct samsung_pin_bank_data gs101_pin_hsi2[] = {
> +	EXYNOS9_PIN_BANK_EINTG(6, 0x0, "gph2", 0x00, 0x00),
> +	EXYNOS9_PIN_BANK_EINTG(2, 0x20, "gph3", 0x04, 0x08),
> +	EXYNOS9_PIN_BANK_EINTG(6, 0x40, "gph4", 0x08, 0x0c),
> +};
> +
> +static const struct samsung_pin_ctrl gs101_pin_ctrl[] __initconst = {
> +	{
> +		/* pin banks of gs101 pin-controller (ALIVE) */
> +		.pin_banks	= gs101_pin_alive,
> +		.nr_banks	= ARRAY_SIZE(gs101_pin_alive),
> +		.eint_wkup_init = exynos_eint_wkup_init,
> +		.suspend	= exynos_pinctrl_suspend,
> +		.resume		= exynos_pinctrl_resume,
> +	}, {
> +		/* pin banks of gs101 pin-controller (FAR_ALIVE) */
> +		.pin_banks	= gs101_pin_far_alive,
> +		.nr_banks	= ARRAY_SIZE(gs101_pin_far_alive),
> +		.eint_wkup_init = exynos_eint_wkup_init,
> +		.suspend	= exynos_pinctrl_suspend,
> +		.resume		= exynos_pinctrl_resume,
> +	}, {
> +		/* pin banks of gs101 pin-controller (GSACORE) */
> +		.pin_banks	= gs101_pin_gsacore,
> +		.nr_banks	= ARRAY_SIZE(gs101_pin_gsacore),
> +	}, {
> +		/* pin banks of gs101 pin-controller (GSACTRL) */
> +		.pin_banks	= gs101_pin_gsactrl,
> +		.nr_banks	= ARRAY_SIZE(gs101_pin_gsactrl),
> +	}, {
> +		/* pin banks of gs101 pin-controller (PERIC0) */
> +		.pin_banks	= gs101_pin_peric0,
> +		.nr_banks	= ARRAY_SIZE(gs101_pin_peric0),
> +		.eint_gpio_init = exynos_eint_gpio_init,
> +		.suspend	= exynos_pinctrl_suspend,
> +		.resume		= exynos_pinctrl_resume,
> +	}, {
> +		/* pin banks of gs101 pin-controller (PERIC1) */
> +		.pin_banks	= gs101_pin_peric1,
> +		.nr_banks	= ARRAY_SIZE(gs101_pin_peric1),
> +		.eint_gpio_init = exynos_eint_gpio_init,
> +		.suspend	= exynos_pinctrl_suspend,
> +		.resume	= exynos_pinctrl_resume,
> +	}, {
> +		/* pin banks of gs101 pin-controller (HSI1) */
> +		.pin_banks	= gs101_pin_hsi1,
> +		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi1),
> +		.eint_gpio_init = exynos_eint_gpio_init,
> +		.suspend	= exynos_pinctrl_suspend,
> +		.resume		= exynos_pinctrl_resume,
> +	}, {
> +		/* pin banks of gs101 pin-controller (HSI2) */
> +		.pin_banks	= gs101_pin_hsi2,
> +		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi2),
> +		.eint_gpio_init = exynos_eint_gpio_init,
> +		.suspend	= exynos_pinctrl_suspend,
> +		.resume		= exynos_pinctrl_resume,
> +	},
> +};
> +
> +const struct samsung_pinctrl_of_match_data gs101_of_data __initconst = {
> +	.ctrl		= gs101_pin_ctrl,
> +	.num_ctrl	= ARRAY_SIZE(gs101_pin_ctrl),
> +};
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index 56fc11a1fe2f..75b9cf72ce73 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -537,6 +537,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
>  			.data = &exynos7_wkup_irq_chip },
>  	{ .compatible = "samsung,exynosautov9-wakeup-eint",
>  			.data = &exynos7_wkup_irq_chip },
> +	{ .compatible = "google,gs101-wakeup-eint",
> +			.data = &exynos7_wkup_irq_chip },
>  	{ }
>  };
>  
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
> index e2799ff1b5e9..1ffc90db079d 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
> @@ -147,6 +147,40 @@
>  		.name		= id				\
>  	}
>  
> +#define EXYNOS9_PIN_BANK_EINTN(types, pins, reg, id)	\
> +	{						\
> +		.type		= &types,		\
> +		.pctl_offset	= reg,			\
> +		.nr_pins	= pins,			\
> +		.eint_type	= EINT_TYPE_NONE,	\
> +		.fltcon_type	= FLT_DEFAULT		\
> +		.name		= id			\
> +	}
> +
> +#define EXYNOS9_PIN_BANK_EINTG(pins, reg, id, offs, fltcon_offs) \
> +	{						\
> +		.type		= &gs101_bank_type_off,	\
> +		.pctl_offset	= reg,			\
> +		.nr_pins	= pins,			\
> +		.eint_type	= EINT_TYPE_GPIO,	\
> +		.eint_offset	= offs,			\
> +		.fltcon_type    = FLT_DEFAULT,		\
> +		.fltcon_offset	= fltcon_offs,		\
> +		.name		= id			\
> +	}
> +
> +#define EXYNOS9_PIN_BANK_EINTW(pins, reg, id, offs, fltcon_offs) \
> +	{							\
> +		.type		= &gs101_bank_type_alive,	\
> +		.pctl_offset	= reg,				\
> +		.nr_pins	= pins,				\
> +		.eint_type	= EINT_TYPE_WKUP,		\
> +		.eint_offset	= offs,				\
> +		.fltcon_type    = FLT_SELECTABLE,		\
> +		.fltcon_offset	= fltcon_offs,			\
> +		.name		= id				\
> +	}
> +
>  /**
>   * struct exynos_weint_data: irq specific data for all the wakeup interrupts
>   * generated by the external wakeup interrupt controller.
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 50c360b4753a..982a5702714c 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -1323,6 +1323,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
>  		.data = &exynosautov9_of_data },
>  	{ .compatible = "tesla,fsd-pinctrl",
>  		.data = &fsd_of_data },
> +	{ .compatible = "google,gs101-pinctrl",
> +		.data = &gs101_of_data },
>  #endif
>  #ifdef CONFIG_PINCTRL_S3C64XX
>  	{ .compatible = "samsung,s3c64xx-pinctrl",
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> index 5fab3885a7d7..f6856290608c 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> @@ -373,6 +373,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
>  extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
>  extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
>  extern const struct samsung_pinctrl_of_match_data fsd_of_data;
> +extern const struct samsung_pinctrl_of_match_data gs101_of_data;
>  extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
>  extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
>  extern const struct samsung_pinctrl_of_match_data s3c2416_of_data;
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 
> -- 
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe at android.com.
> 


From willmcvicker at google.com  Fri Dec  1 15:59:02 2023
From: willmcvicker at google.com (William McVicker)
Date: Fri, 1 Dec 2023 15:59:02 -0800
Subject: [PATCH v5 15/20] watchdog: s3c2410_wdt: Add support for WTCON
 register DBGACK_MASK bit
In-Reply-To: <20231201160925.3136868-16-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-16-peter.griffin@linaro.org>
Message-ID: <ZWpzRtmMY2y8Fs5-@google.com>

On 12/01/2023, Peter Griffin wrote:
> The WDT uses the CPU core signal DBGACK to determine whether the SoC
> is running in debug mode or not. If the DBGACK signal is asserted and
> DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
> (disabled).
> 
> Presence of the DBGACK_MASK bit is determined by adding a new
> QUIRK_HAS_DBGACK_BIT quirk.
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Tested-by: Will McVicker <willmcvicker at google.com>

---

I verified boot to a busybox console and that the watchdog probes.

Regards,
Will

> ---
>  drivers/watchdog/s3c2410_wdt.c | 27 ++++++++++++++++++++++++---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> index 0b4bd883ff28..39f3489e41d6 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -34,9 +34,10 @@
>  
>  #define S3C2410_WTCNT_MAXCNT	0xffff
>  
> -#define S3C2410_WTCON_RSTEN	(1 << 0)
> -#define S3C2410_WTCON_INTEN	(1 << 2)
> -#define S3C2410_WTCON_ENABLE	(1 << 5)
> +#define S3C2410_WTCON_RSTEN		(1 << 0)
> +#define S3C2410_WTCON_INTEN		(1 << 2)
> +#define S3C2410_WTCON_ENABLE		(1 << 5)
> +#define S3C2410_WTCON_DBGACK_MASK	(1 << 16)
>  
>  #define S3C2410_WTCON_DIV16	(0 << 3)
>  #define S3C2410_WTCON_DIV32	(1 << 3)
> @@ -100,12 +101,17 @@
>   * %QUIRK_HAS_PMU_CNT_EN: PMU block has some register (e.g. CLUSTERx_NONCPU_OUT)
>   * with "watchdog counter enable" bit. That bit should be set to make watchdog
>   * counter running.
> + *
> + * %QUIRK_HAS_DBGACK_BIT: WTCON register has DBGACK_MASK bit. Setting the
> + * DBGACK_MASK bit disables the watchdog outputs when the SoC is in debug mode.
> + * Debug mode is determined by the DBGACK CPU signal.
>   */
>  #define QUIRK_HAS_WTCLRINT_REG			(1 << 0)
>  #define QUIRK_HAS_PMU_MASK_RESET		(1 << 1)
>  #define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
>  #define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
>  #define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
> +#define QUIRK_HAS_DBGACK_BIT			(1 << 5)
>  
>  /* These quirks require that we have a PMU register map */
>  #define QUIRKS_HAVE_PMUREG \
> @@ -375,6 +381,19 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
>  	return 0;
>  }
>  
> +static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt)
> +{
> +	unsigned long wtcon;
> +
> +	if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
> +		return;
> +
> +	/*  disable watchdog outputs if CPU is in debug mode */
> +	wtcon = readl(wdt->reg_base + S3C2410_WTCON);
> +	wtcon |= S3C2410_WTCON_DBGACK_MASK;
> +	writel(wtcon, wdt->reg_base + S3C2410_WTCON);
> +}
> +
>  static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
>  {
>  	struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
> @@ -700,6 +719,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
>  	wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
>  	wdt->wdt_device.parent = dev;
>  
> +	s3c2410wdt_mask_dbgack(wdt);
> +
>  	/*
>  	 * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
>  	 * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 


From willmcvicker at google.com  Fri Dec  1 15:59:37 2023
From: willmcvicker at google.com (William McVicker)
Date: Fri, 1 Dec 2023 15:59:37 -0800
Subject: [PATCH v5 16/20] watchdog: s3c2410_wdt: Add support for Google
 gs101 SoC
In-Reply-To: <20231201160925.3136868-17-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-17-peter.griffin@linaro.org>
Message-ID: <ZWpzaQ4uLNFXCr8q@google.com>

On 12/01/2023, Peter Griffin wrote:
> This patch adds the compatibles and drvdata for the Google
> gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.
> 
> Similar to Exynos850 it has two watchdog instances, one for
> each cluster and has some control bits in PMU registers.
> 
> gs101 also has the dbgack_mask bit in wtcon register, so
> we also enable QUIRK_HAS_DBGACK_BIT.
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Tested-by: Will McVicker <willmcvicker at google.com>

---

I verified boot to a busybox console and that the watchdog probes.

Regards,
Will

> ---
>  drivers/watchdog/s3c2410_wdt.c | 47 ++++++++++++++++++++++++++++++----
>  1 file changed, 42 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> index 39f3489e41d6..c1ae71574457 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -68,6 +68,13 @@
>  #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
>  #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
>  
> +#define GS_CLUSTER0_NONCPU_OUT			0x1220
> +#define GS_CLUSTER1_NONCPU_OUT			0x1420
> +#define GS_CLUSTER0_NONCPU_INT_EN		0x1244
> +#define GS_CLUSTER1_NONCPU_INT_EN		0x1444
> +#define GS_CLUSTER2_NONCPU_INT_EN		0x1644
> +#define GS_RST_STAT_REG_OFFSET			0x3B44
> +
>  /**
>   * DOC: Quirk flags for different Samsung watchdog IP-cores
>   *
> @@ -269,6 +276,30 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
>  		  QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
>  };
>  
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
> +	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 0,
> +	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
> +	.cnt_en_bit = 8,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT,
> +};
> +
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
> +	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 1,
> +	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
> +	.cnt_en_bit = 7,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT,
> +};
> +
>  static const struct of_device_id s3c2410_wdt_match[] = {
>  	{ .compatible = "samsung,s3c2410-wdt",
>  	  .data = &drv_data_s3c2410 },
> @@ -284,6 +315,8 @@ static const struct of_device_id s3c2410_wdt_match[] = {
>  	  .data = &drv_data_exynos850_cl0 },
>  	{ .compatible = "samsung,exynosautov9-wdt",
>  	  .data = &drv_data_exynosautov9_cl0 },
> +	{ .compatible = "google,gs101-wdt",
> +	  .data = &drv_data_gs101_cl0 },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
> @@ -604,9 +637,10 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>  	}
>  
>  #ifdef CONFIG_OF
> -	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
> +	/* Choose Exynos850/ExynosAutov9/gs101 driver data w.r.t. cluster index */
>  	if (variant == &drv_data_exynos850_cl0 ||
> -	    variant == &drv_data_exynosautov9_cl0) {
> +	    variant == &drv_data_exynosautov9_cl0 ||
> +	    variant == &drv_data_gs101_cl0) {
>  		u32 index;
>  		int err;
>  
> @@ -619,9 +653,12 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>  		case 0:
>  			break;
>  		case 1:
> -			variant = (variant == &drv_data_exynos850_cl0) ?
> -				&drv_data_exynos850_cl1 :
> -				&drv_data_exynosautov9_cl1;
> +			if (variant == &drv_data_exynos850_cl0)
> +				variant = &drv_data_exynos850_cl1;
> +			else if (variant == &drv_data_exynosautov9_cl0)
> +				variant = &drv_data_exynosautov9_cl1;
> +			else if (variant == &drv_data_gs101_cl0)
> +				variant = &drv_data_gs101_cl1;
>  			break;
>  		default:
>  			return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 


From willmcvicker at google.com  Fri Dec  1 16:01:40 2023
From: willmcvicker at google.com (William McVicker)
Date: Fri, 1 Dec 2023 16:01:40 -0800
Subject: [PATCH v5 17/20] tty: serial: samsung: Add gs101 compatible and
 common fifoszdt_serial_drv_data
In-Reply-To: <20231201160925.3136868-18-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-18-peter.griffin@linaro.org>
Message-ID: <ZWpz5L2g4SB2cdVD@google.com>

On 12/01/2023, Peter Griffin wrote:
> Add serial driver data for Google Tensor gs101 SoC and a common
> fifoszdt_serial_drv_data that can be used by platforms that specify the
> samsung,uart-fifosize DT property.
> 
> A corresponding dt-bindings patch updates the yaml to ensure
> samsung,uart-fifosize is a required property.
> 
> Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Reviewed-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Tested-by: Will McVicker <willmcvicker at google.com>

---

I verified boot to a busybox console with kernel logs printed to the serial
port.

Regards,
Will

> ---
>  drivers/tty/serial/samsung_tty.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> index 1b0c2b467a30..f8d98f1006de 100644
> --- a/drivers/tty/serial/samsung_tty.c
> +++ b/drivers/tty/serial/samsung_tty.c
> @@ -2490,14 +2490,25 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
>  	.fifosize = { 256, 64, 64, 64 },
>  };
>  
> +/*
> + * Common drv_data struct for platforms that specify uart,fifosize in
> + * device tree.
> + */
> +static const struct s3c24xx_serial_drv_data exynos_fifoszdt_serial_drv_data = {
> +	EXYNOS_COMMON_SERIAL_DRV_DATA(),
> +	.fifosize = { 0 },
> +};
> +
>  #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
>  #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
>  #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
> +#define EXYNOS_FIFOSZDT_DRV_DATA (&exynos_fifoszdt_serial_drv_data)
>  
>  #else
>  #define EXYNOS4210_SERIAL_DRV_DATA NULL
>  #define EXYNOS5433_SERIAL_DRV_DATA NULL
>  #define EXYNOS850_SERIAL_DRV_DATA NULL
> +#define EXYNOS_FIFOSZDT_DRV_DATA NULL
>  #endif
>  
>  #ifdef CONFIG_ARCH_APPLE
> @@ -2581,6 +2592,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
>  	}, {
>  		.name		= "artpec8-uart",
>  		.driver_data	= (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
> +	}, {
> +		.name		= "gs101-uart",
> +		.driver_data	= (kernel_ulong_t)EXYNOS_FIFOSZDT_DRV_DATA,
>  	},
>  	{ },
>  };
> @@ -2602,6 +2616,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
>  		.data = EXYNOS850_SERIAL_DRV_DATA },
>  	{ .compatible = "axis,artpec8-uart",
>  		.data = ARTPEC8_SERIAL_DRV_DATA },
> +	{ .compatible = "google,gs101-uart",
> +		.data = EXYNOS_FIFOSZDT_DRV_DATA },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 


From willmcvicker at google.com  Fri Dec  1 16:03:04 2023
From: willmcvicker at google.com (William McVicker)
Date: Fri, 1 Dec 2023 16:03:04 -0800
Subject: [PATCH v5 18/20] arm64: dts: exynos: google: Add initial Google
 gs101 SoC support
In-Reply-To: <20231201160925.3136868-19-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-19-peter.griffin@linaro.org>
Message-ID: <ZWp0OPfW3x61XFD2@google.com>

On 12/01/2023, Peter Griffin wrote:
> Google gs101 SoC is ARMv8 mobile SoC found in the Pixel 6,
> (oriole) Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
> phones. It features:
> * 4xA55 little cluster
> * 2xA76 Mid cluster
> * 2xX1 Big cluster
> 
> This commit adds the basic device tree for gs101 (SoC).
> Further platform support will be added over time.
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Tested-by: Will McVicker <willmcvicker at google.com>

--

Verified boot to a busybox console on my oriole device.

Thanks,
Will

> ---
>  .../boot/dts/exynos/google/gs101-pinctrl.dtsi | 1250 +++++++++++++++++
>  .../boot/dts/exynos/google/gs101-pinctrl.h    |   33 +
>  arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  476 +++++++
>  3 files changed, 1759 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi
> 
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
> new file mode 100644
> index 000000000000..8c0f0cf75edb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
> @@ -0,0 +1,1250 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * GS101 SoC pin-mux and pin-config device tree source
> + *
> + * Copyright 2019-2023 Google LLC
> + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> + */
> +
> +#include "gs101-pinctrl.h"
> +
> +&pinctrl_gpio_alive {
> +	gpa0: gpa0-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa1: gpa1-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa2: gpa2-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa3: gpa3-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa4: gpa4-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa5: gpa5-gpio-bank  {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa9: gpa9-gpio-bank  {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa10: gpa10-gpio-bank  {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	uart15_bus: uart15-bus-pins {
> +		samsung,pins = "gpa2-3", "gpa2-4";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	uart16_bus: uart16-bus-pins {
> +		samsung,pins = "gpa3-0", "gpa3-1", "gpa3-2", "gpa3-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	uart17_bus: uart17-bus-pins {
> +		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2", "gpa4-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi15_bus: spi15-bus-pins {
> +		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi15_cs: spi15-cs-pins {
> +		samsung,pins = "gpa4-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +};
> +
> +&pinctrl_far_alive {
> +	gpa6: gpa6-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa7: gpa7-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa8: gpa8-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +
> +	gpa11: gpa11-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH 0>,
> +			     <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH 0>;
> +	};
> +};
> +
> +&pinctrl_gsacore {
> +	gps0: gps0-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gps1: gps1-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gps2: gps2-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +};
> +
> +&pinctrl_gsactrl {
> +	gps3: gps3-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +};
> +
> +&pinctrl_hsi1 {
> +	gph0: gph0-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gph1: gph1-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	pcie0_clkreq: pcie0-clkreq-pins{
> +		samsung,pins = "gph0-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +		samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
> +	};
> +
> +	pcie0_perst: pcie0-perst-pins {
> +		samsung,pins = "gph0-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +	};
> +};
> +
> +&pinctrl_hsi2 {
> +	gph2: gph2-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gph3: gph3-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gph4: gph4-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	sd2_clk: sd2-clk-pins {
> +		samsung,pins = "gph4-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +	};
> +
> +	sd2_cmd: sd2-cmd-pins {
> +		samsung,pins = "gph4-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +	};
> +
> +	sd2_bus1: sd2-bus-width1-pins {
> +		samsung,pins = "gph4-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +	};
> +
> +	sd2_bus4: sd2-bus-width4-pins {
> +		samsung,pins = "gph4-3", "gph4-4", "gph4-5";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +	};
> +
> +	sd2_clk_fast_slew_rate_1x: sd2-clk-fast-slew-rate-1x-pins {
> +		samsung,pins = "gph4-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	sd2_clk_fast_slew_rate_2x: sd2-clk-fast-slew-rate-2x-pins {
> +		samsung,pins = "gph4-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sd2_clk_fast_slew_rate_3x: sd2-clk-fast-slew-rate-3x-pins {
> +		samsung,pins = "gph4-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +	};
> +
> +	sd2_clk_fast_slew_rate_4x: sd2-clk-fast-slew-rate-4x-pins {
> +		samsung,pins = "gph4-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +	};
> +
> +	ufs_rst_n: ufs-rst-n-pins {
> +		samsung,pins = "gph3-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	ufs_refclk_out: ufs-refclk-out-pins {
> +		samsung,pins = "gph3-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	pcie1_clkreq: pcie1-clkreq-pins {
> +		samsung,pins = "gph2-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +		samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
> +	};
> +
> +	pcie1_perst: pcie1-perst-pins {
> +		samsung,pins = "gph2-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +	};
> +};
> +
> +&pinctrl_peric0 {
> +	gpp0: gpp0-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp1: gpp1-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp2: gpp2-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp3: gpp3-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp4: gpp4-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp5: gpp5-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp6: gpp6-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp7: gpp7-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp8: gpp8-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp9: gpp9-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp10: gpp10-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp11: gpp11-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp12: gpp12-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp13: gpp13-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp14: gpp14-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp15: gpp15-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp16: gpp16-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp17: gpp17-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp18: gpp18-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp19: gpp19-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	/* USI_PERIC0_UART_DBG */
> +	uart0_bus: uart0-bus-pins {
> +		samsung,pins = "gpp1-2", "gpp1-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	disp_te_pri_on: disp-te-pri-on-pins {
> +		samsung,pins = "gpp0-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +	};
> +
> +	disp_te_pri_off: disp-te-pri-off-pins {
> +		samsung,pins = "gpp0-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
> +	};
> +
> +	disp_te_sec_on: disp-te-sec-on-pins {
> +		samsung,pins = "gpp0-4";
> +		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +	};
> +
> +	disp_te_sec_off: disp-te-sec-off-pins {
> +		samsung,pins = "gpp0-4";
> +		samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
> +	};
> +
> +	sensor_mclk1_out: sensor-mclk1-out-pins {
> +		samsung,pins = "gpp3-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk1_fn: sensor-mclk1-fn-pins {
> +		samsung,pins = "gpp3-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk2_out: sensor-mclk2-out-pins {
> +		samsung,pins = "gpp5-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk2_fn: sensor-mclk2-fn-pins {
> +		samsung,pins = "gpp5-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk3_out: sensor-mclk3-out-pins {
> +		samsung,pins = "gpp7-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk3_fn: sensor-mclk3-fn-pins {
> +		samsung,pins = "gpp7-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk4_out: sensor-mclk4-out-pins {
> +		samsung,pins = "gpp9-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk4_fn: sensor-mclk4-fn-pins {
> +		samsung,pins = "gpp9-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk5_out: sensor-mclk5-out-pins {
> +		samsung,pins = "gpp11-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk5_fn: sensor-mclk5-fn-pins {
> +		samsung,pins = "gpp11-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk6_out: sensor-mclk6-out-pins {
> +		samsung,pins = "gpp13-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk6_fn: sensor-mclk6-fn-pins {
> +		samsung,pins = "gpp13-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk7_out: sensor-mclk7-out-pins {
> +		samsung,pins = "gpp15-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk7_fn: sensor-mclk7-fn-pins {
> +		samsung,pins = "gpp15-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk8_out: sensor-mclk8-out-pins {
> +		samsung,pins = "gpp17-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	sensor_mclk8_fn: sensor-mclk8-fn-pins {
> +		samsung,pins = "gpp17-0";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +	};
> +
> +	hsi2c14_bus: hsi2c14-bus-pins {
> +		samsung,pins = "gpp18-0", "gpp18-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart14_bus_single: uart14-bus-pins {
> +		samsung,pins = "gpp18-0", "gpp18-1",
> +			       "gpp18-2", "gpp18-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi14_bus: spi14-bus-pins {
> +		samsung,pins = "gpp18-0", "gpp18-1", "gpp18-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi14_cs: spi14-cs-pins {
> +		samsung,pins = "gpp18-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi14_cs_func: spi14-cs-func-pins {
> +		samsung,pins = "gpp18-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c8_bus: hsi2c8-bus-pins {
> +		samsung,pins = "gpp16-0", "gpp16-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +		samsung,pin-pud-pdn = <GS101_PIN_PDN_OUT0>;
> +	};
> +
> +	uart8_bus_single: uart8-bus-pins {
> +		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2",
> +			       "gpp16-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi8_bus: spi8-bus-pins {
> +		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi8_cs: spi8-cs-pins {
> +		samsung,pins = "gpp16-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi8_cs_func: spi8-cs-func-pins {
> +		samsung,pins = "gpp16-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c7_bus: hsi2c7-bus-pins {
> +		samsung,pins = "gpp14-0", "gpp14-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart7_bus_single: uart7-bus-pins {
> +		samsung,pins = "gpp14-0", "gpp14-1",
> +			       "gpp14-2", "gpp14-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi7_bus: spi7-bus-pins {
> +		samsung,pins = "gpp14-0", "gpp14-1", "gpp14-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi7_cs: spi7-cs-pins {
> +		samsung,pins = "gpp14-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi7_cs_func: spi7-cs-func-pins {
> +		samsung,pins = "gpp14-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c6_bus: hsi2c6-bus-pins {
> +		samsung,pins = "gpp12-0", "gpp12-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart6_bus_single: uart6-bus-pins {
> +		samsung,pins = "gpp12-0", "gpp12-1",
> +			       "gpp12-2", "gpp12-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi6_bus: spi6-bus-pins {
> +		samsung,pins = "gpp12-0", "gpp12-1", "gpp12-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi6_cs: spi6-cs-pins {
> +		samsung,pins = "gpp12-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi6_cs_func: spi6-cs-func-pins {
> +		samsung,pins = "gpp12-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c5_bus: hsi2c5-bus-pins {
> +		samsung,pins = "gpp10-0", "gpp10-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart5_bus_single: uart5-bus-pins {
> +		samsung,pins = "gpp10-0", "gpp10-1",
> +			       "gpp10-2", "gpp10-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi5_bus: spi5-bus-pins {
> +		samsung,pins = "gpp10-0", "gpp10-1", "gpp10-2";
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi5_cs_func: spi5-cs-func-pins {
> +		samsung,pins = "gpp10-3";
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	hsi2c4_bus: hsi2c4-bus-pins {
> +		samsung,pins = "gpp8-0", "gpp8-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart4_bus_single: uart4-bus-pins {
> +		samsung,pins = "gpp8-0", "gpp8-1",
> +			       "gpp8-2", "gpp8-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi4_bus: spi4-bus-pins {
> +		samsung,pins = "gpp8-0", "gpp8-1", "gpp8-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi4_cs: spi4-cs-pins {
> +		samsung,pins = "gpp8-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi4_cs_func: spi4-cs-func-pins {
> +		samsung,pins = "gpp8-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c3_bus: hsi2c3-bus-pins {
> +		samsung,pins = "gpp6-0", "gpp6-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart3_bus_single: uart3-bus-pins {
> +		samsung,pins = "gpp6-0", "gpp6-1",
> +			       "gpp6-2", "gpp6-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi3_bus: spi3-bus-pins {
> +		samsung,pins = "gpp6-0", "gpp6-1", "gpp6-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi3_cs: spi3-cs-pins {
> +		samsung,pins = "gpp6-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi3_cs_func: spi3-cs-func-pins {
> +		samsung,pins = "gpp6-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c2_bus: hsi2c2-bus-pins {
> +		samsung,pins = "gpp4-0", "gpp4-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart2_bus_single: uart2-bus-pins {
> +		samsung,pins = "gpp4-0", "gpp4-1",
> +			       "gpp4-2", "gpp4-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi2_bus: spi2-bus-pins {
> +		samsung,pins = "gpp4-0", "gpp4-1", "gpp4-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi2_cs: spi2-cs-pins {
> +		samsung,pins = "gpp4-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi2_cs_func: spi2-cs-func-pins {
> +		samsung,pins = "gpp4-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c1_bus: hsi2c1-bus-pins {
> +		samsung,pins = "gpp2-0", "gpp2-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart1_bus_single: uart1-bus-pins {
> +		samsung,pins = "gpp2-0", "gpp2-1",
> +			       "gpp2-2", "gpp2-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi1_bus: spi1-bus-pins {
> +		samsung,pins = "gpp2-0", "gpp2-1", "gpp2-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi1_cs: spi1-cs-pins {
> +		samsung,pins = "gpp2-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi1_cs_func: spi1-cs-func-pins {
> +		samsung,pins = "gpp2-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +};
> +
> +&pinctrl_peric1 {
> +	gpp20: gpp20-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp21: gpp21-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp22: gpp22-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp23: gpp23-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp24: gpp24-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp25: gpp25-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp26: gpp26-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	gpp27: gpp27-gpio-bank {
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +	};
> +
> +	hsi2c13_bus: hsi2c13-bus-pins  {
> +		samsung,pins = "gpp25-0", "gpp25-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart13_bus_single: uart13-bus-pins {
> +		samsung,pins = "gpp25-0", "gpp25-1",
> +			       "gpp25-2", "gpp25-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi13_bus: spi13-bus-pins {
> +		samsung,pins = "gpp25-0", "gpp25-1", "gpp25-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi13_cs: spi13-cs-pins {
> +		samsung,pins = "gpp25-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi13_cs_func: spi13-cs-func-pins {
> +		samsung,pins = "gpp25-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c12_bus: hsi2c12-bus-pins {
> +		samsung,pins = "gpp23-4", "gpp23-5";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart12_bus_single: uart12-bus-pins {
> +		samsung,pins = "gpp23-4", "gpp23-5",
> +			       "gpp23-6", "gpp23-7";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi12_bus: spi12-bus-pins {
> +		samsung,pins = "gpp23-4", "gpp23-5", "gpp23-6";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi14_cs2: spi14-cs2-pins {
> +		samsung,pins = "gpp23-6";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi12_cs: spi12-cs-pins {
> +		samsung,pins = "gpp23-7";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi12_cs_func: spi12-cs-func-pins {
> +		samsung,pins = "gpp23-7";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c11_bus: hsi2c11-bus-pins {
> +		samsung,pins = "gpp23-0", "gpp23-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart11_bus_single: uart11-bus-pins {
> +		samsung,pins = "gpp23-0", "gpp23-1",
> +			       "gpp23-2", "gpp23-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi11_bus: spi11-bus-pins {
> +		samsung,pins = "gpp23-0", "gpp23-1", "gpp23-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi11_cs: spi11-cs-pins {
> +		samsung,pins = "gpp23-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi11_cs_func: spi11-cs-func-pins {
> +		samsung,pins = "gpp23-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c10_bus: hsi2c10-bus-pins {
> +		samsung,pins = "gpp21-0", "gpp21-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart10_bus_single: uart10-bus-pins {
> +		samsung,pins = "gpp21-0", "gpp21-1",
> +			       "gpp21-2", "gpp21-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi10_bus: spi10-bus-pins {
> +		samsung,pins = "gpp21-0", "gpp21-1", "gpp21-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi10_cs: spi10-cs-pins {
> +		samsung,pins = "gpp21-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi10_cs_func: spi10-cs-func-pins {
> +		samsung,pins = "gpp21-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c9_bus: hsi2c9-bus-pins {
> +		samsung,pins = "gpp20-4", "gpp20-5";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart9_bus_single: uart9-bus-pins {
> +		samsung,pins = "gpp20-4", "gpp20-5",
> +			       "gpp20-6", "gpp20-7";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi9_bus: spi9-bus-pins {
> +		samsung,pins = "gpp20-4", "gpp20-5", "gpp20-6";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi9_cs: spi9-cs-pins {
> +		samsung,pins = "gpp20-7";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi9_cs_func: spi9-cs-func-pins {
> +		samsung,pins = "gpp20-7";
> +		samsung,pin-function = <GS101_PIN_FUNC_2>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	hsi2c0_bus: hsi2c0-bus-pins {
> +		samsung,pins = "gpp20-0", "gpp20-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	uart0_bus_single: uart0-bus-pins {
> +		samsung,pins = "gpp20-0", "gpp20-1",
> +			       "gpp20-2", "gpp20-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +	};
> +
> +	spi0_bus: spi0-bus-pins {
> +		samsung,pins = "gpp20-0", "gpp20-1", "gpp20-2";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi0_cs: spi0-cs-pins {
> +		samsung,pins = "gpp20-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	spi0_cs_func: spi0-cs-func-pins {
> +		samsung,pins = "gpp20-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_3>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +};
> +
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> new file mode 100644
> index 000000000000..853505e45b60
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Pinctrl binding constants for GS101
> + *
> + * Copyright (c) 2020-2023 Google, LLC.
> + */
> +
> +#ifndef __DT_BINDINGS_PINCTRL_GS101_H__
> +#define __DT_BINDINGS_PINCTRL_GS101_H__
> +
> +#define GS101_PIN_PULL_NONE		0
> +#define GS101_PIN_PULL_DOWN		1
> +#define GS101_PIN_PULL_UP		3
> +
> +/* Pin function in power down mode */
> +#define GS101_PIN_PDN_OUT0		0
> +#define GS101_PIN_PDN_OUT1		1
> +#define GS101_PIN_PDN_INPUT		2
> +#define GS101_PIN_PDN_PREV		3
> +
> +/* GS101 drive strengths */
> +#define GS101_PIN_DRV_2_5_MA		0
> +#define GS101_PIN_DRV_5_MA		1
> +#define GS101_PIN_DRV_7_5_MA		2
> +#define GS101_PIN_DRV_10_MA		3
> +
> +#define GS101_PIN_FUNC_INPUT		0
> +#define GS101_PIN_FUNC_OUTPUT		1
> +#define GS101_PIN_FUNC_2		2
> +#define GS101_PIN_FUNC_3		3
> +#define GS101_PIN_FUNC_EINT		0xf
> +
> +#endif /* __DT_BINDINGS_PINCTRL_GS101_H__ */
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> new file mode 100644
> index 000000000000..40f6654a23f2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -0,0 +1,476 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * GS101 SoC
> + *
> + * Copyright 2019-2023 Google LLC
> + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> + */
> +
> +#include <dt-bindings/clock/google,gs101.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/soc/samsung,exynos-usi.h>
> +
> +/ {
> +	compatible = "google,gs101";
> +	#address-cells = <2>;
> +	#size-cells = <1>;
> +
> +	interrupt-parent = <&gic>;
> +
> +	aliases {
> +		pinctrl0 = &pinctrl_gpio_alive;
> +		pinctrl1 = &pinctrl_far_alive;
> +		pinctrl2 = &pinctrl_gsacore;
> +		pinctrl3 = &pinctrl_gsactrl;
> +		pinctrl4 = &pinctrl_peric0;
> +		pinctrl5 = &pinctrl_peric1;
> +		pinctrl6 = &pinctrl_hsi1;
> +		pinctrl7 = &pinctrl_hsi2;
> +		serial0 = &serial_0;
> +	};
> +
> +	pmu-0 {
> +		compatible = "arm,cortex-a55-pmu";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
> +	};
> +
> +	pmu-1 {
> +		compatible = "arm,cortex-a76-pmu";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
> +	};
> +
> +	pmu-2 {
> +		compatible = "arm,cortex-x1-pmu";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster2>;
> +	};
> +
> +	pmu-3 {
> +		compatible = "arm,dsu-pmu";
> +		interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH 0>;
> +		cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
> +		       <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
> +	};
> +
> +	/* TODO replace with CCF clock */
> +	dummy_clk: oscillator {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <12345>;
> +		clock-output-names = "pclk";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu-map {
> +			cluster0 {
> +				core0 {
> +					cpu = <&cpu0>;
> +				};
> +				core1 {
> +					cpu = <&cpu1>;
> +				};
> +				core2 {
> +					cpu = <&cpu2>;
> +				};
> +				core3 {
> +					cpu = <&cpu3>;
> +				};
> +			};
> +
> +			cluster1 {
> +				core0 {
> +					cpu = <&cpu4>;
> +				};
> +				core1 {
> +					cpu = <&cpu5>;
> +				};
> +			};
> +
> +			cluster2 {
> +				core0 {
> +					cpu = <&cpu6>;
> +				};
> +				core1 {
> +					cpu = <&cpu7>;
> +				};
> +			};
> +		};
> +
> +		cpu0: cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0000>;
> +			enable-method = "psci";
> +			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
> +			capacity-dmips-mhz = <250>;
> +			dynamic-power-coefficient = <70>;
> +		};
> +
> +		cpu1: cpu at 100 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0100>;
> +			enable-method = "psci";
> +			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
> +			capacity-dmips-mhz = <250>;
> +			dynamic-power-coefficient = <70>;
> +		};
> +
> +		cpu2: cpu at 200 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0200>;
> +			enable-method = "psci";
> +			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
> +			capacity-dmips-mhz = <250>;
> +			dynamic-power-coefficient = <70>;
> +		};
> +
> +		cpu3: cpu at 300 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0300>;
> +			enable-method = "psci";
> +			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
> +			capacity-dmips-mhz = <250>;
> +			dynamic-power-coefficient = <70>;
> +		};
> +
> +		cpu4: cpu at 400 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a76";
> +			reg = <0x0400>;
> +			enable-method = "psci";
> +			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
> +			capacity-dmips-mhz = <620>;
> +			dynamic-power-coefficient = <284>;
> +		};
> +
> +		cpu5: cpu at 500 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a76";
> +			reg = <0x0500>;
> +			enable-method = "psci";
> +			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
> +			capacity-dmips-mhz = <620>;
> +			dynamic-power-coefficient = <284>;
> +		};
> +
> +		cpu6: cpu at 600 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-x1";
> +			reg = <0x0600>;
> +			enable-method = "psci";
> +			cpu-idle-states =  <&HERA_CPU_SLEEP>;
> +			capacity-dmips-mhz = <1024>;
> +			dynamic-power-coefficient = <650>;
> +		};
> +
> +		cpu7: cpu at 700 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-x1";
> +			reg = <0x0700>;
> +			enable-method = "psci";
> +			cpu-idle-states =  <&HERA_CPU_SLEEP>;
> +			capacity-dmips-mhz = <1024>;
> +			dynamic-power-coefficient = <650>;
> +		};
> +
> +		idle-states {
> +			entry-method = "psci";
> +
> +			ANANKE_CPU_SLEEP: cpu-ananke-sleep {
> +				idle-state-name = "c2";
> +				compatible = "arm,idle-state";
> +				arm,psci-suspend-param = <0x0010000>;
> +				entry-latency-us = <70>;
> +				exit-latency-us = <160>;
> +				min-residency-us = <2000>;
> +			};
> +
> +			ENYO_CPU_SLEEP: cpu-enyo-sleep {
> +				idle-state-name = "c2";
> +				compatible = "arm,idle-state";
> +				arm,psci-suspend-param = <0x0010000>;
> +				entry-latency-us = <150>;
> +				exit-latency-us = <190>;
> +				min-residency-us = <2500>;
> +			};
> +
> +			HERA_CPU_SLEEP: cpu-hera-sleep {
> +				idle-state-name = "c2";
> +				compatible = "arm,idle-state";
> +				arm,psci-suspend-param = <0x0010000>;
> +				entry-latency-us = <235>;
> +				exit-latency-us = <220>;
> +				min-residency-us = <3500>;
> +			};
> +		};
> +	};
> +
> +	/* ect node is required to be present by bootloader */
> +	ect {
> +	};
> +
> +	ext_24_5m: clock-1 {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-output-names = "oscclk";
> +	};
> +
> +	ext_200m: clock-2 {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-output-names = "ext-200m";
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-1.0";
> +		method = "smc";
> +	};
> +
> +	reserved_memory: reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		gsa_reserved_protected: gsa at 90200000 {
> +			reg = <0x0 0x90200000 0x400000>;
> +			no-map;
> +		};
> +
> +		tpu_fw_reserved: tpu-fw at 93000000 {
> +			reg = <0x0 0x93000000 0x1000000>;
> +			no-map;
> +		};
> +
> +		aoc_reserve: aoc at 94000000 {
> +			reg = <0x0 0x94000000 0x03000000>;
> +			no-map;
> +		};
> +
> +		abl_reserved: abl at f8800000 {
> +			reg = <0x0 0xf8800000 0x02000000>;
> +			no-map;
> +		};
> +
> +		dss_log_reserved: dss-log-reserved at fd3f0000 {
> +			reg = <0x0 0xfd3f0000 0x0000e000>;
> +			no-map;
> +		};
> +
> +		debug_kinfo_reserved: debug-kinfo-reserved at fd3fe000 {
> +			reg = <0x0 0xfd3fe000 0x00001000>;
> +			no-map;
> +		};
> +
> +		bldr_log_reserved: bldr-log-reserved at fd800000 {
> +			reg = <0x0 0xfd800000 0x00100000>;
> +			no-map;
> +		};
> +
> +		bldr_log_hist_reserved: bldr-log-hist-reserved at fd900000 {
> +			reg = <0x0 0xfd900000 0x00002000>;
> +			no-map;
> +		};
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts =
> +		   <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> +		   <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> +		   <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> +		   <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>;
> +		clock-frequency = <24576000>;
> +	};
> +
> +	soc: soc at 0 {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges = <0x0 0x0 0x0 0x40000000>;
> +
> +		cmu_misc: clock-controller at 10010000 {
> +			compatible = "google,gs101-cmu-misc";
> +			reg = <0x10010000 0x8000>;
> +			#clock-cells = <1>;
> +			clocks =  <&ext_24_5m>, <&cmu_top CLK_DOUT_MISC_BUS>;
> +			clock-names = "oscclk", "dout_cmu_misc_bus";
> +		};
> +
> +		watchdog_cl0: watchdog at 10060000 {
> +			compatible = "google,gs101-wdt";
> +			reg = <0x10060000 0x100>;
> +			interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH 0>;
> +			clocks =
> +			  <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0_IPCLKPORT_PCLK>,
> +			  <&ext_24_5m>;
> +			clock-names = "watchdog", "watchdog_src";
> +			samsung,syscon-phandle = <&pmu_system_controller>;
> +			samsung,cluster-index = <0>;
> +			status = "disabled";
> +		};
> +
> +		watchdog_cl1: watchdog at 10070000 {
> +			compatible = "google,gs101-wdt";
> +			reg = <0x10070000 0x100>;
> +			interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH 0>;
> +			clocks =
> +			  <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1_IPCLKPORT_PCLK>,
> +			  <&ext_24_5m>;
> +			clock-names = "watchdog", "watchdog_src";
> +			samsung,syscon-phandle = <&pmu_system_controller>;
> +			samsung,cluster-index = <1>;
> +			status = "disabled";
> +		};
> +
> +		gic: interrupt-controller at 10400000 {
> +			compatible = "arm,gic-v3";
> +			#interrupt-cells = <4>;
> +			interrupt-controller;
> +			reg = <0x10400000 0x10000>, /* GICD */
> +			      <0x10440000 0x100000>;/* GICR * 8 */
> +			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
> +
> +			ppi-partitions {
> +				ppi_cluster0: interrupt-partition-0 {
> +					affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
> +				};
> +
> +				ppi_cluster1: interrupt-partition-1 {
> +					affinity = <&cpu4 &cpu5>;
> +				};
> +
> +				ppi_cluster2: interrupt-partition-2 {
> +					affinity = <&cpu6 &cpu7>;
> +				};
> +			};
> +		};
> +
> +		sysreg_peric0: syscon at 10820000 {
> +			compatible = "google,gs101-peric0-sysreg", "syscon";
> +			reg = <0x10820000 0x10000>;
> +		};
> +
> +		pinctrl_peric0: pinctrl at 10840000 {
> +			compatible = "google,gs101-pinctrl";
> +			reg = <0x10840000 0x00001000>;
> +			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> +		};
> +
> +		usi_uart: usi at 10a000c0 {
> +			compatible = "google,gs101-usi",
> +				     "samsung,exynos850-usi";
> +			reg = <0x10a000c0 0x20>;
> +			samsung,sysreg = <&sysreg_peric0 0x1020>;
> +			samsung,mode = <USI_V2_UART>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			ranges;
> +			clocks = <&dummy_clk>, <&dummy_clk>;
> +			clock-names = "pclk", "ipclk";
> +			status = "disabled";
> +
> +			serial_0: serial at 10a00000 {
> +				compatible = "google,gs101-uart";
> +				reg = <0x10a00000 0xc0>;
> +				reg-io-width = <4>;
> +				samsung,uart-fifosize = <256>;
> +				interrupts = <GIC_SPI 634
> +					      IRQ_TYPE_LEVEL_HIGH 0>;
> +				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
> +				clock-names = "uart", "clk_uart_baud0";
> +				status = "disabled";
> +			};
> +		};
> +
> +		pinctrl_peric1: pinctrl at 10c40000 {
> +			compatible = "google,gs101-pinctrl";
> +			reg = <0x10C40000 0x00001000>;
> +			interrupts = <GIC_SPI 644 IRQ_TYPE_LEVEL_HIGH 0>;
> +		};
> +
> +		sysreg_peric1: syscon at 10c20000 {
> +			compatible = "google,gs101-peric1-sysreg", "syscon";
> +			reg = <0x10C20000 0x10000>;
> +		};
> +
> +		pinctrl_hsi1: pinctrl at 11840000 {
> +			compatible = "google,gs101-pinctrl";
> +			reg = <0x11840000 0x00001000>;
> +			interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH 0>;
> +		};
> +
> +		pinctrl_hsi2: pinctrl at 14440000 {
> +			compatible = "google,gs101-pinctrl";
> +			reg = <0x14440000 0x00001000>;
> +			interrupts = <GIC_SPI 503 IRQ_TYPE_LEVEL_HIGH 0>;
> +		};
> +
> +		cmu_apm: clock-controller at 17400000 {
> +			compatible = "google,gs101-cmu-apm";
> +			reg = <0x17400000 0x8000>;
> +			#clock-cells = <1>;
> +
> +			clocks = <&ext_24_5m>;
> +			clock-names = "oscclk";
> +		};
> +
> +		sysreg_apm: syscon at 174204e0 {
> +			compatible = "google,gs101-apm-sysreg", "syscon";
> +			reg = <0x174204e0 0x1000>;
> +		};
> +
> +		pmu_system_controller: system-controller at 17460000 {
> +			compatible = "google,gs101-pmu", "syscon";
> +			reg = <0x17460000 0x10000>;
> +		};
> +
> +		pinctrl_gpio_alive: pinctrl at 174d0000 {
> +			compatible = "google,gs101-pinctrl";
> +			reg = <0x174d0000 0x00001000>;
> +
> +			wakeup-interrupt-controller {
> +				compatible = "google,gs101-wakeup-eint",
> +					     "samsung,exynos850-wakeup-eint",
> +					     "samsung,exynos7-wakeup-eint";
> +			};
> +		};
> +
> +		pinctrl_far_alive: pinctrl at 174e0000 {
> +			compatible = "google,gs101-pinctrl";
> +			reg = <0x174e0000 0x00001000>;
> +
> +			wakeup-interrupt-controller {
> +				compatible = "google,gs101-wakeup-eint",
> +					     "samsung,exynos850-wakeup-eint",
> +					     "samsung,exynos7-wakeup-eint";
> +			};
> +		};
> +
> +		pinctrl_gsactrl: pinctrl at 17940000 {
> +			compatible = "google,gs101-pinctrl";
> +			reg = <0x17940000 0x00001000>;
> +		};
> +
> +		pinctrl_gsacore: pinctrl at 17a80000 {
> +			compatible = "google,gs101-pinctrl";
> +			reg = <0x17a80000 0x00001000>;
> +		};
> +
> +		cmu_top: clock-controller at 1e080000 {
> +			compatible = "google,gs101-cmu-top";
> +			reg = <0x1e080000 0x8000>;
> +			#clock-cells = <1>;
> +
> +			clocks = <&ext_24_5m>;
> +			clock-names = "oscclk";
> +		};
> +	};
> +};
> +
> +#include "gs101-pinctrl.dtsi"
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 
> -- 
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe at android.com.
> 


From willmcvicker at google.com  Fri Dec  1 16:03:37 2023
From: willmcvicker at google.com (William McVicker)
Date: Fri, 1 Dec 2023 16:03:37 -0800
Subject: [PATCH v5 19/20] arm64: dts: exynos: google: Add initial
 Oriole/pixel 6 board support
In-Reply-To: <20231201160925.3136868-20-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-20-peter.griffin@linaro.org>
Message-ID: <ZWp0WapGiXZLn5xn@google.com>

On 12/01/2023, Peter Griffin wrote:
> Add initial board support for the Pixel 6 phone code named Oriole. This
> has been tested with a minimal busybox initramfs and boots to a shell.
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Tested-by: Will McVicker <willmcvicker at google.com>

--

Verified boot to a busybox console on my oriole device.

Thanks,
Will

> ---
>  arch/arm64/boot/dts/exynos/Makefile           |   2 +
>  arch/arm64/boot/dts/exynos/google/Makefile    |   4 +
>  .../boot/dts/exynos/google/gs101-oriole.dts   | 105 ++++++++++++++++++
>  3 files changed, 111 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> 
> diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
> index 6e4ba69268e5..44c24a8ad9e1 100644
> --- a/arch/arm64/boot/dts/exynos/Makefile
> +++ b/arch/arm64/boot/dts/exynos/Makefile
> @@ -1,4 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
> +subdir-y += google
> +
>  dtb-$(CONFIG_ARCH_EXYNOS) += \
>  	exynos5433-tm2.dtb		\
>  	exynos5433-tm2e.dtb		\
> diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
> new file mode 100644
> index 000000000000..0a6d5e1fe4ee
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +dtb-$(CONFIG_ARCH_EXYNOS) += \
> +	gs101-oriole.dtb \
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> new file mode 100644
> index 000000000000..6abd00fa337e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Oriole Device Tree
> + *
> + * Copyright 2021-2023 Google,LLC
> + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "gs101-pinctrl.h"
> +#include "gs101.dtsi"
> +
> +/ {
> +	model = "Oriole";
> +	compatible = "google,gs101-oriole", "google,gs101";
> +
> +	aliases {
> +		serial0 = &serial_0;
> +	};
> +
> +	chosen {
> +		/* Bootloader expects bootargs specified otherwise it crashes */
> +		bootargs = "";
> +		stdout-path = &serial_0;
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&key_voldown>, <&key_volup>, <&key_power>;
> +
> +		button-vol-down {
> +			label = "KEY_VOLUMEDOWN";
> +			linux,code = <KEY_VOLUMEDOWN>;
> +			gpios = <&gpa7 3 GPIO_ACTIVE_LOW>;
> +			wakeup-source;
> +		};
> +
> +		button-vol-up {
> +			label = "KEY_VOLUMEUP";
> +			linux,code = <KEY_VOLUMEUP>;
> +			gpios = <&gpa8 1 GPIO_ACTIVE_LOW>;
> +			wakeup-source;
> +		};
> +
> +		button-power {
> +			label = "KEY_POWER";
> +			linux,code = <KEY_POWER>;
> +			gpios = <&gpa10 1 GPIO_ACTIVE_LOW>;
> +			wakeup-source;
> +		};
> +	};
> +};
> +
> +&ext_24_5m {
> +	clock-frequency = <24576000>;
> +};
> +
> +&ext_200m {
> +	clock-frequency = <200000000>;
> +};
> +
> +&pinctrl_far_alive {
> +	key_voldown: key-voldown-pins {
> +		samsung,pins = "gpa7-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	key_volup: key-volup-pins {
> +		samsung,pins = "gpa8-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +};
> +
> +&pinctrl_gpio_alive {
> +	key_power: key-power-pins {
> +		samsung,pins = "gpa10-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +};
> +
> +&serial_0 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_bus>;
> +};
> +
> +&usi_uart {
> +	status = "okay";
> +	samsung,clkreq-on; /* needed for UART mode */
> +};
> +
> +&watchdog_cl0 {
> +	timeout-sec = <30>;
> +	status = "okay";
> +};
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 


From gnstark at salutedevices.com  Fri Dec  1 16:05:13 2023
From: gnstark at salutedevices.com (George Stark)
Date: Sat, 2 Dec 2023 03:05:13 +0300
Subject: [PATCH v2 1/1] iio: adc: meson: add separate config for axg SoC
 family
In-Reply-To: <20231201180811.00002783@Huawei.com>
References: <20231122074741.154228-1-gnstark@salutedevices.com>
 <20231125172508.2a2242bf@jic23-huawei>
 <ca18c346-94f3-4c4c-a540-57509b879b04@salutedevices.com>
 <20231201180811.00002783@Huawei.com>
Message-ID: <2cd319fe-f1f8-4855-badb-cf7dd1f6160a@salutedevices.com>

Hello Jonathan

On 12/1/23 21:08, Jonathan Cameron wrote:
> On Mon, 27 Nov 2023 22:17:33 +0300
> George Stark <gnstark at salutedevices.com> wrote:
> 
>> Hello Jonathan
>>
>> Thanks for the review.
>>
>> On 11/25/23 20:25, Jonathan Cameron wrote:
>>> On Wed, 22 Nov 2023 10:47:41 +0300
>>> George Stark <gnstark at salutedevices.com> wrote:
>>>    
>>>> According to Amlogic custom kernels ADC of axg SoC family has
>>>> vref_select and requires this setting to work nominally and thus
>>>> needs a separate config.
>>>>
>>>> Signed-off-by: George Stark <gnstark at salutedevices.com>
>>>> Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
>>>
>>> Is this a fix?  If so, please provide a fixes tag.
>> Actually yes, these changes could be done in the patch that introduced
>> new configuration parameters.
>>
>>> Or is it aligning with the vendor kernels and we don't know if
>>> it's strictly necessary or not?
>> I do know it's necessary if we want kernel driver to be independent from
>> ADC initialization in vendor u-boot code. I have Amlogic a113x device
>> (axg family) and can provide test results w and w/o this patch.
> 
> Definitely best to not rely on firmware.
> 
> So send a Fixes tag for this and I'll apply it as a fix
> (you get to figure out which patch it fixed :)

The patch is ready :)

https://lore.kernel.org/lkml/20231127235558.71995-1-gnstark at salutedevices.com/


> 
> Jonathan
> 
>>
>>>    
>>>> ---
>>>>    drivers/iio/adc/meson_saradc.c | 16 +++++++++++++++-
>>>>    1 file changed, 15 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
>>>> index db280da9edbf..34555a85f131 100644
>>>> --- a/drivers/iio/adc/meson_saradc.c
>>>> +++ b/drivers/iio/adc/meson_saradc.c
>>>> @@ -1242,6 +1242,20 @@ static const struct meson_sar_adc_param meson_sar_adc_gxl_param = {
>>>>    	.cmv_select = 1,
>>>>    };
>>>>    
>>>> +static const struct meson_sar_adc_param meson_sar_adc_axg_param = {
>>>> +	.has_bl30_integration = true,
>>>> +	.clock_rate = 1200000,
>>>> +	.bandgap_reg = MESON_SAR_ADC_REG11,
>>>> +	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
>>>> +	.resolution = 12,
>>>> +	.disable_ring_counter = 1,
>>>> +	.has_reg11 = true,
>>>> +	.vref_volatge = 1,
>>>> +	.has_vref_select = true,
>>>> +	.vref_select = VREF_VDDA,
>>>> +	.cmv_select = 1,
>>>> +};
>>>> +
>>>>    static const struct meson_sar_adc_param meson_sar_adc_g12a_param = {
>>>>    	.has_bl30_integration = false,
>>>>    	.clock_rate = 1200000,
>>>> @@ -1286,7 +1300,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
>>>>    };
>>>>    
>>>>    static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
>>>> -	.param = &meson_sar_adc_gxl_param,
>>>> +	.param = &meson_sar_adc_axg_param,
>>>>    	.name = "meson-axg-saradc",
>>>>    };
>>>>      
>>>    
>>
> 

-- 
Best regards
George


From pr-tracker-bot at kernel.org  Fri Dec  1 16:05:50 2023
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Sat, 02 Dec 2023 00:05:50 +0000
Subject: [GIT PULL] arm64 fix for 6.7-rc4
In-Reply-To: <ZWodVqC4gvcASpba@arm.com>
References: <ZWodVqC4gvcASpba@arm.com>
Message-ID: <170147555074.9445.3114194944879210462.pr-tracker-bot@kernel.org>

The pull request you sent on Fri, 1 Dec 2023 17:52:22 +0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/35f84584806e4e127a667221c592f8ae248132f6

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From semen.protsenko at linaro.org  Fri Dec  1 16:22:24 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 18:22:24 -0600
Subject: [PATCH v5 13/20] pinctrl: samsung: Add filter selection support
 for alive banks
In-Reply-To: <20231201160925.3136868-14-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-14-peter.griffin@linaro.org>
Message-ID: <CAPLW+4nJCabQhyGrTKZhKG40Z9ysRq7Zms413JrhZKzeYzad5w@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Newer Exynos SoCs have a filter selection register on alive bank pins.
> This allows the selection of a digital or delay filter for each pin. If
> the filter selection register is not available then the default filter
> (digital) is applied.
>
> On suspend we apply the analog filter to all pins in the bank (as the
> digital filter relies on a clock). On resume the digital filter is
> reapplied to all pins in the bank. The digital filter is working via
> clock and has an adjustable filter delay register bitfield, whereas
> the analog filter uses a fixed delay.
>
> The filter determines to what extent signal fluctuations received through
> the pad are considered glitches.
>
> The code path can be exercised using
> echo mem > /sys/power/state
> And then wake the device using a eint gpio

Period.

>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  drivers/pinctrl/samsung/pinctrl-exynos.c  | 89 ++++++++++++++++++++++-
>  drivers/pinctrl/samsung/pinctrl-exynos.h  |  7 ++
>  drivers/pinctrl/samsung/pinctrl-samsung.c |  2 +
>  drivers/pinctrl/samsung/pinctrl-samsung.h | 22 ++++++
>  4 files changed, 119 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index 6b58ec84e34b..56fc11a1fe2f 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -269,6 +269,71 @@ struct exynos_eint_gpio_save {
>         u32 eint_mask;
>  };
>
> +/*
> + * Set the desired filter (digital or analog delay) to every pin in
> + * the bank. Note the filter selection bitfield is only found on alive
> + * banks. The filter determines to what extent signal fluctuations
> + * received through the pad are considered glitches.
> + */
> +static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
> +                                  struct samsung_pin_bank *bank, int filter)
> +{
> +       unsigned int flt_reg, flt_con = 0;
> +       unsigned int val, shift;
> +       int i;
> +       int loop_cnt;
> +
> +       /*
> +        * The FLTCON register has the following layout
> +        *
> +        * BitfieldName[PinNum][Bit:Bit]
> +        * FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
> +        * FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
> +        * FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
> +        * FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
> +        *
> +        * FLT_EN       0x0 = Disable, 0x1=Enable
> +        * FLT_SEL      0x0 = Delay filter, 0x1 Digital filter
> +        * FLT_WIDTH    Filtering width. Valid when FLT_SEL is 0x1
> +        */
> +
> +       flt_con |= EXYNOS9_FLTCON_EN;
> +
> +       if (filter)
> +               flt_con |= EXYNOS9_FLTCON_DIGITAL;
> +
> +       flt_reg = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
> +
> +       /*
> +        * If nr_pins > 4, we should set FLTCON0 register fully.
> +        * (pin0 ~ 3). So loop 4 times in case of FLTCON0.
> +        */
> +       if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN)
> +               loop_cnt = EXYNOS9_FLTCON_NR_PIN;
> +       else
> +               loop_cnt = bank->nr_pins;
> +
> +       val = readl(d->virt_base + flt_reg);
> +       for (i = 0; i < loop_cnt; i++) {
> +               shift = i * EXYNOS9_FLTCON_LEN;
> +               val &= ~(EXYNOS9_FLTCON_MASK << shift);
> +               val |= (flt_con << shift);
> +       }
> +       writel(val, d->virt_base + flt_reg);
> +
> +       /* Loop for FLTCON1 pin 4 ~ 7 */
> +       if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN) {
> +               loop_cnt = (bank->nr_pins - EXYNOS9_FLTCON_NR_PIN);
> +               val = readl(d->virt_base + flt_reg + 0x4);
> +               for (i = 0; i < loop_cnt; i++) {
> +                       shift = i * EXYNOS9_FLTCON_LEN;
> +                       val &= ~(EXYNOS9_FLTCON_MASK << shift);
> +                       val |= (flt_con << shift);
> +               }
> +               writel(val, d->virt_base + flt_reg + 0x4);
> +       }
> +}
> +

This whole function needs a refactoring. Do you think below code looks better?

8<----------------------------------------------------------------->8
static void exynos_eint_update_flt_reg(void __iomem *reg, int cnt, int con)
{
    unsigned int val, shift;
    int i;

    val = readl(reg);
    for (i = 0; i < cnt; i++) {
        shift = i * EXYNOS9_FLTCON_LEN;
        val &= ~(EXYNOS9_FLTCON_MASK << shift);
        val |= con << shift;
    }
    writel(val, reg);
}

/*
 * Set the desired filter (digital or analog delay) to every pin in the bank.
 * Note the filter selection bitfield is only found on alive banks. The filter
 * determines to what extent signal fluctuations received through the pad are
 * considered glitches.
 *
 * The FLTCON register has the following layout:
 *
 *     BitfieldName[PinNum][Bit:Bit]
 *     FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
 *     FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
 *     FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
 *     FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
 *
 * FLT_EN    0x0 = Disable, 0x1 = Enable
 * FLT_SEL    0x0 = Delay filter, 0x1 = Digital filter
 * FLT_WIDTH    Filtering width. Valid when FLT_SEL is 0x1
 */
static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
                   struct samsung_pin_bank *bank, int filter)
{
    unsigned int off = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
    unsigned int con = EXYNOS9_FLTCON_EN | filter;
    void __iomem *reg = d->virt_base + off;
    u8 n = bank->nr_pins;

    if (bank->fltcon_type == FLT_DEFAULT)
        return;

    /*
     * If nr_pins > 4, we should set FLTCON0 register fully (pin0~3).
     * So loop 4 times in case of FLTCON0. Loop for FLTCON1 pin4~7.
     */
    if (n <= 4) {
        exynos_eint_update_flt_reg(reg, n, con);
    } else {
        exynos_eint_update_flt_reg(reg, 4, con);
        exynos_eint_update_flt_reg(reg + 0x4, n - 4, con);
    }
}
8<----------------------------------------------------------------->8

(the code is only to illustrate the idea, I never tested it).

>  /*
>   * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
>   * @d: driver data of samsung pinctrl driver.
> @@ -321,6 +386,10 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
>                         goto err_domains;
>                 }
>
> +               /* Set Delay Analog Filter */

The code below looks quite self-explanatory to. Maybe remove all
comments like this? If you don't think exynos_eint_flt_config() is
clear, maybe rename it to exynos_eint_set_filter().

> +               if (bank->fltcon_type != FLT_DEFAULT)
> +                       exynos_eint_flt_config(d, bank,
> +                                              EXYNOS9_FLTCON_DELAY);

It fits the previous line just fine, no need to break the line.

Also, if you use the refactored version of exynos_eint_flt_config() I
mentioned above, you can drop all 'if' conditions like this.

>         }
>
>         return 0;
> @@ -555,6 +624,11 @@ __init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
>                 if (bank->eint_type != EINT_TYPE_WKUP)
>                         continue;
>
> +               /* Set Digital Filter */
> +               if (bank->fltcon_type != FLT_DEFAULT)
> +                       exynos_eint_flt_config(d, bank,
> +                                              EXYNOS9_FLTCON_DIGITAL);

Ditto: no need to break the line, remove the comment. If you use the
refactored function, you can drop 'if'.

> +
>                 bank->irq_chip = devm_kmemdup(dev, irq_chip, sizeof(*irq_chip),
>                                               GFP_KERNEL);
>                 if (!bank->irq_chip) {
> @@ -658,6 +732,7 @@ static void exynos_pinctrl_suspend_bank(
>  void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
>  {
>         struct samsung_pin_bank *bank = drvdata->pin_banks;
> +       struct samsung_pinctrl_drv_data *d = bank->drvdata;
>         struct exynos_irq_chip *irq_chip = NULL;
>         int i;
>
> @@ -665,6 +740,10 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
>                 if (bank->eint_type == EINT_TYPE_GPIO)
>                         exynos_pinctrl_suspend_bank(drvdata, bank);
>                 else if (bank->eint_type == EINT_TYPE_WKUP) {
> +                       /* Setting Delay (Analog) Filter */
> +                       if (bank->fltcon_type != FLT_DEFAULT)
> +                               exynos_eint_flt_config(d, bank,
> +                                                      EXYNOS9_FLTCON_DELAY);

Ditto: no need to break the line, remove the comment. If you use the
refactored function, you can drop 'if'.

>                         if (!irq_chip) {
>                                 irq_chip = bank->irq_chip;
>                                 irq_chip->set_eint_wakeup_mask(drvdata,
> @@ -707,11 +786,19 @@ static void exynos_pinctrl_resume_bank(
>  void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
>  {
>         struct samsung_pin_bank *bank = drvdata->pin_banks;
> +       struct samsung_pinctrl_drv_data *d = bank->drvdata;
>         int i;
>
>         for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
> -               if (bank->eint_type == EINT_TYPE_GPIO)
> +               if (bank->eint_type == EINT_TYPE_GPIO) {
>                         exynos_pinctrl_resume_bank(drvdata, bank);
> +               } else if (bank->eint_type == EINT_TYPE_WKUP ||
> +                          bank->eint_type == EINT_TYPE_WKUP_MUX) {
> +                       /* Set Digital Filter */
> +                       if (bank->fltcon_type != FLT_DEFAULT)
> +                               exynos_eint_flt_config(d, bank,
> +                                                      EXYNOS9_FLTCON_DIGITAL);

Ditto: remove the comment, and if you use the refactored function, you
can drop 'if'; also there will be no need to break the line.

> +               }
>  }
>
>  static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
> index 3ac52c2cf998..e2799ff1b5e9 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
> @@ -50,6 +50,13 @@
>
>  #define EXYNOS_EINT_MAX_PER_BANK       8
>  #define EXYNOS_EINT_NR_WKUP_EINT

Maybe add an empty line here?

> +/* EINT filter configuration */
> +#define EXYNOS9_FLTCON_EN              BIT(7)
> +#define EXYNOS9_FLTCON_DIGITAL         BIT(6)
> +#define EXYNOS9_FLTCON_DELAY           (0 << 6)
> +#define EXYNOS9_FLTCON_MASK            0xff
> +#define EXYNOS9_FLTCON_LEN             8
> +#define EXYNOS9_FLTCON_NR_PIN          4

I'd say drop this one and just hard-code it where needed?

>
>  #define EXYNOS_PIN_BANK_EINTN(pins, reg, id)           \
>         {                                               \
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 79babbb39ced..50c360b4753a 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -1105,6 +1105,8 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
>                 bank->eint_func = bdata->eint_func;
>                 bank->eint_type = bdata->eint_type;
>                 bank->eint_mask = bdata->eint_mask;
> +               bank->fltcon_type = bdata->fltcon_type;
> +               bank->fltcon_offset = bdata->fltcon_offset;
>                 bank->eint_offset = bdata->eint_offset;
>                 bank->name = bdata->name;
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> index 9b3db50adef3..5fab3885a7d7 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> @@ -82,6 +82,20 @@ enum eint_type {
>         EINT_TYPE_WKUP_MUX,
>  };
>
> +/**
> + * enum fltcon_type - filter selection
> + * @FLT_DEFAULT: filter not selectable, default digital filter
> + * @FLT_SELECT: filter selectable (digital or delay)
> + *
> + * Some banks on newer Exynos based SoCs have a selectable filter on alive
> + * banks of 'analog/delay' or 'digital'. If the filter selection register is
> + * not available then the default filter is used (digital).
> + */
> +enum fltcon_type {
> +       FLT_DEFAULT,
> +       FLT_SELECTABLE,
> +};

Is there any benefit of having this enum over replacing it with just a
bool field (e.g. 'bool flt_selectable')?

> +
>  /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
>  #define PIN_NAME_LENGTH        10
>
> @@ -122,6 +136,8 @@ struct samsung_pin_bank_type {
>   * @eint_type: type of the external interrupt supported by the bank.
>   * @eint_mask: bit mask of pins which support EINT function.
>   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> + * @fltcon_type: whether the filter (delay/digital) is selectable
> + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
>   * @name: name to be prefixed for each pin in this pin bank.
>   */
>  struct samsung_pin_bank_data {
> @@ -133,6 +149,8 @@ struct samsung_pin_bank_data {
>         enum eint_type  eint_type;
>         u32             eint_mask;
>         u32             eint_offset;
> +       enum fltcon_type fltcon_type;
> +       u32             fltcon_offset;
>         const char      *name;
>  };
>
> @@ -147,6 +165,8 @@ struct samsung_pin_bank_data {
>   * @eint_type: type of the external interrupt supported by the bank.
>   * @eint_mask: bit mask of pins which support EINT function.
>   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> + * @fltcon_type: whether the filter (delay/digital) is selectable
> + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
>   * @name: name to be prefixed for each pin in this pin bank.
>   * @id: id of the bank, propagated to the pin range.
>   * @pin_base: starting pin number of the bank.
> @@ -170,6 +190,8 @@ struct samsung_pin_bank {
>         enum eint_type  eint_type;
>         u32             eint_mask;
>         u32             eint_offset;
> +       enum fltcon_type fltcon_type;
> +       u32             fltcon_offset;
>         const char      *name;
>         u32             id;
>
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From renze at rnplus.nl  Fri Dec  1 16:38:44 2023
From: renze at rnplus.nl (Renze Nicolai)
Date: Sat,  2 Dec 2023 01:38:44 +0100
Subject: [PATCH v3 1/2] dt-bindings: arm: aspeed: add Asrock X570D4U board
In-Reply-To: <20231202003908.3635695-1-renze@rnplus.nl>
References: <20231202003908.3635695-1-renze@rnplus.nl>
Message-ID: <20231202003908.3635695-2-renze@rnplus.nl>

Document Asrock X570D4U compatible.

Signed-off-by: Renze Nicolai <renze at rnplus.nl>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 749ee54a3ff8..81ed678905fa 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -36,6 +36,7 @@ properties:
               - aspeed,ast2500-evb
               - asrock,e3c246d4i-bmc
               - asrock,romed8hm3-bmc
+              - asrock,x570d4u-bmc
               - bytedance,g220a-bmc
               - facebook,cmm-bmc
               - facebook,minipack-bmc
-- 
2.43.0



From renze at rnplus.nl  Fri Dec  1 16:38:43 2023
From: renze at rnplus.nl (Renze Nicolai)
Date: Sat,  2 Dec 2023 01:38:43 +0100
Subject: [PATCH v3 0/2] ARM: dts: aspeed: asrock: Add ASRock X570D4U BMC
Message-ID: <20231202003908.3635695-1-renze@rnplus.nl>

Hello,

These patches add a device-tree (and a bindings update) for the
Aspeed BMC on the ASRock X570D4U, so that it can be added as a
supported OpenBMC platform.

Changes since v2:
  - Renamed leds to led-0 and led-1 to match Documentation/devicetree/bindings/leds/leds-gpio.yaml
  - Added aliasses and labels for the i2c-mux on i2c bus 4
  - Added the missing blank line between the ehci1 and uhci nodes

Greetings,
Renze Nicolai

Renze Nicolai (2):
  dt-bindings: arm: aspeed: add Asrock X570D4U board
  ARM: dts: aspeed: asrock: Add ASRock X570D4U BMC

 .../bindings/arm/aspeed/aspeed.yaml           |   1 +
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-asrock-x570d4u.dts  | 377 ++++++++++++++++++
 3 files changed, 379 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts

-- 
2.43.0



From renze at rnplus.nl  Fri Dec  1 16:38:45 2023
From: renze at rnplus.nl (Renze Nicolai)
Date: Sat,  2 Dec 2023 01:38:45 +0100
Subject: [PATCH v3 2/2] ARM: dts: aspeed: asrock: Add ASRock X570D4U BMC
In-Reply-To: <20231202003908.3635695-1-renze@rnplus.nl>
References: <20231202003908.3635695-1-renze@rnplus.nl>
Message-ID: <20231202003908.3635695-3-renze@rnplus.nl>

This is a relatively low-cost AST2500-based Amd Ryzen 5000 Series
micro-ATX board that we hope can provide a decent platform for OpenBMC
development.

This initial device-tree provides the necessary configuration for
basic BMC functionality such as serial console, KVM support
and POST code snooping.

Signed-off-by: Renze Nicolai <renze at rnplus.nl>
---
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-asrock-x570d4u.dts  | 377 ++++++++++++++++++
 2 files changed, 378 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts

diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index d3ac20e316d0..2205bd079d0c 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -10,6 +10,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-arm-stardragon4800-rep2.dtb \
 	aspeed-bmc-asrock-e3c246d4i.dtb \
 	aspeed-bmc-asrock-romed8hm3.dtb \
+	aspeed-bmc-asrock-x570d4u.dtb \
 	aspeed-bmc-bytedance-g220a.dtb \
 	aspeed-bmc-delta-ahe50dc.dtb \
 	aspeed-bmc-facebook-bletchley.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
new file mode 100644
index 000000000000..3c975bc41ae7
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
@@ -0,0 +1,377 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+#include "aspeed-g5.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "Asrock Rack X570D4U BMC";
+	compatible = "asrock,x570d4u-bmc", "aspeed,ast2500";
+
+	aliases {
+		i2c40 = &i2c4mux0ch0;
+		i2c41 = &i2c4mux0ch1;
+		i2c42 = &i2c4mux0ch2;
+		i2c43 = &i2c4mux0ch3;
+	};
+
+	chosen {
+		stdout-path = &uart5;
+	};
+
+	memory at 80000000 {
+		reg = <0x80000000 0x20000000>;
+	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		pci_memory: region at 9a000000 {
+			no-map;
+			reg = <0x9a000000 0x00010000>; /* 64K */
+		};
+
+		video_engine_memory: jpegbuffer {
+			size = <0x02800000>;	/* 40M */
+			alignment = <0x01000000>;
+			compatible = "shared-dma-pool";
+			reusable;
+		};
+
+		gfx_memory: framebuffer {
+			size = <0x01000000>;
+			alignment = <0x01000000>;
+			compatible = "shared-dma-pool";
+			reusable;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			/* led-heartbeat-n */
+			gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_LOW>;
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_HEARTBEAT;
+			linux,default-trigger = "timer";
+		};
+
+		led-1 {
+			/* led-fault-n */
+			gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
+			color = <LED_COLOR_ID_AMBER>;
+			function = LED_FUNCTION_FAULT;
+			panic-indicator;
+		};
+	};
+
+	iio-hwmon {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 0>, <&adc 1>, <&adc 2>, <&adc 3>, <&adc 4>,
+			<&adc 5>, <&adc 6>, <&adc 7>, <&adc 8>, <&adc 9>,
+			<&adc 10>, <&adc 11>, <&adc 12>;
+	};
+};
+
+&gpio {
+	status = "okay";
+	gpio-line-names =
+	/*A0-A3*/       "status-locatorled-n",                    "",                      "button-nmi-n",          "",
+	/*A4-A7*/       "",                                       "",                      "",                      "",
+	/*B0-B3*/       "input-bios-post-cmplt-n",                "",                      "",                      "",
+	/*B4-B7*/       "",                                       "",                      "",                      "",
+	/*C0-C3*/       "",                                       "",                      "",                      "",
+	/*C4-C7*/       "",                                       "",                      "control-locatorbutton", "",
+	/*D0-D3*/       "button-power",                           "control-power",         "button-reset",          "control-reset",
+	/*D4-D7*/       "",                                       "",                      "",                      "",
+	/*E0-E3*/       "",                                       "",                      "",                      "",
+	/*E4-E7*/       "",                                       "",                      "",                      "",
+	/*F0-F3*/       "",                                       "",                      "",                      "",
+	/*F4-F7*/       "",                                       "",                      "",                      "",
+	/*G0-G3*/       "output-rtc-battery-voltage-read-enable", "input-id0",             "input-id1",             "input-id2",
+	/*G4-G7*/       "input-alert1-n",                         "input-alert2-n",        "input-alert3-n",        "",
+	/*H0-H3*/       "",                                       "",                      "",                      "",
+	/*H4-H7*/       "input-mfg",                              "",                      "led-heartbeat-n",       "input-caseopen",
+	/*I0-I3*/       "",                                       "",                      "",                      "",
+	/*I4-I7*/       "",                                       "",                      "",                      "",
+	/*J0-J3*/       "output-bmc-ready",                       "",                      "",                      "",
+	/*J4-J7*/       "",                                       "",                      "",                      "",
+	/*K0-K3*/       "",                                       "",                      "",                      "",
+	/*K4-K7*/       "",                                       "",                      "",                      "",
+	/*L0-L3*/       "",                                       "",                      "",                      "",
+	/*L4-L7*/       "",                                       "",                      "",                      "",
+	/*M0-M3*/       "",                                       "",                      "",                      "",
+	/*M4-M7*/       "",                                       "",                      "",                      "",
+	/*N0-N3*/       "",                                       "",                      "",                      "",
+	/*N4-N7*/       "",                                       "",                      "",                      "",
+	/*O0-O3*/       "",                                       "",                      "",                      "",
+	/*O4-O7*/       "",                                       "",                      "",                      "",
+	/*P0-P3*/       "",                                       "",                      "",                      "",
+	/*P4-P7*/       "",                                       "",                      "",                      "",
+	/*Q0-Q3*/       "",                                       "",                      "",                      "",
+	/*Q4-Q7*/       "",                                       "",                      "",                      "",
+	/*R0-R3*/       "",                                       "",                      "",                      "",
+	/*R4-R7*/       "",                                       "",                      "",                      "",
+	/*S0-S3*/       "input-bmc-pchhot-n",                     "",                      "",                      "",
+	/*S4-S7*/       "",                                       "",                      "",                      "",
+	/*T0-T3*/       "",                                       "",                      "",                      "",
+	/*T4-T7*/       "",                                       "",                      "",                      "",
+	/*U0-U3*/       "",                                       "",                      "",                      "",
+	/*U4-U7*/       "",                                       "",                      "",                      "",
+	/*V0-V3*/       "",                                       "",                      "",                      "",
+	/*V4-V7*/       "",                                       "",                      "",                      "",
+	/*W0-W3*/       "",                                       "",                      "",                      "",
+	/*W4-W7*/       "",                                       "",                      "",                      "",
+	/*X0-X3*/       "",                                       "",                      "",                      "",
+	/*X4-X7*/       "",                                       "",                      "",                      "",
+	/*Y0-Y3*/       "",                                       "",                      "",                      "",
+	/*Y4-Y7*/       "",                                       "",                      "",                      "",
+	/*Z0-Z3*/       "",                                       "",                      "led-fault-n",           "output-bmc-throttle-n",
+	/*Z4-Z7*/       "",                                       "",                      "",                      "",
+	/*AA0-AA3*/     "input-cpu1-thermtrip-latch-n",           "",                      "input-cpu1-prochot-n",  "",
+	/*AA4-AC7*/     "",                                       "",                      "",                      "",
+	/*AB0-AB3*/     "",                                       "",                      "",                      "",
+	/*AB4-AC7*/     "",                                       "",                      "",                      "",
+	/*AC0-AC3*/     "",                                       "",                      "",                      "",
+	/*AC4-AC7*/     "",                                       "",                      "",                      "";
+};
+
+&fmc {
+	status = "okay";
+	flash at 0 {
+		status = "okay";
+		label = "bmc";
+		m25p,fast-read;
+		spi-max-frequency = <10000000>;
+#include "openbmc-flash-layout-64.dtsi"
+	};
+};
+
+&uart5 {
+	status = "okay";
+};
+
+&vuart {
+	status = "okay";
+};
+
+&mac0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rgmii1_default &pinctrl_mdio1_default>;
+
+	nvmem-cells = <&eth0_macaddress>;
+	nvmem-cell-names = "mac-address";
+};
+
+&mac1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rmii2_default &pinctrl_mdio2_default>;
+	use-ncsi;
+
+	nvmem-cells = <&eth1_macaddress>;
+	nvmem-cell-names = "mac-address";
+};
+
+&i2c0 {
+	/* SMBus on auxiliary panel header (AUX_PANEL1) */
+	status = "okay";
+};
+
+&i2c1 {
+	status = "okay";
+
+	w83773g at 4c {
+		compatible = "nuvoton,w83773g";
+		reg = <0x4c>;
+	};
+};
+
+&i2c2 {
+	/* PSU SMBus (PSU_SMB1) */
+	status = "okay";
+};
+
+&i2c3 {
+	status = "okay";
+};
+
+&i2c4 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9545";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c4mux0ch0: i2c at 0 {
+			/* SMBus on PCI express 16x slot */
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+
+		i2c4mux0ch1: i2c at 1 {
+			/* SMBus on PCI express 8x slot */
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+
+		i2c4mux0ch2: i2c at 2 {
+			/* Unknown */
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+
+		i2c4mux0ch3: i2c at 3 {
+			/* SMBus on PCI express 1x slot */
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+	};
+};
+
+&i2c5 {
+	status = "okay";
+};
+
+&i2c7 {
+	/* FRU and SPD EEPROM SMBus */
+	status = "okay";
+
+	eeprom at 57 {
+		compatible = "st,24c128", "atmel,24c128";
+		reg = <0x57>;
+		pagesize = <16>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		eth0_macaddress: macaddress at 3f80 {
+			reg = <0x3f80 6>;
+		};
+
+		eth1_macaddress: macaddress at 3f88 {
+			reg = <0x3f88 6>;
+		};
+	};
+};
+
+&gfx {
+	status = "okay";
+};
+
+&pinctrl {
+	aspeed,external-nodes = <&gfx &lhc>;
+};
+
+&vhub {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&uhci {
+	status = "okay";
+};
+
+&kcs3 {
+	aspeed,lpc-io-reg = <0xca2>;
+	status = "okay";
+};
+
+&lpc_ctrl {
+	status = "okay";
+};
+
+&lpc_snoop {
+	status = "okay";
+	snoop-ports = <0x80>;
+};
+
+&p2a {
+	status = "okay";
+	memory-region = <&pci_memory>;
+};
+
+&video {
+	status = "okay";
+	memory-region = <&video_engine_memory>;
+};
+
+&pwm_tacho {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm0_default
+				&pinctrl_pwm1_default
+				&pinctrl_pwm2_default
+				&pinctrl_pwm3_default
+				&pinctrl_pwm4_default
+				&pinctrl_pwm5_default>;
+
+	fan at 0 {
+		/* FAN1 (4-pin) */
+		reg = <0x00>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x00>;
+	};
+
+	fan at 1 {
+		/* FAN2 (4-pin) */
+		reg = <0x01>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x01>;
+	};
+
+	fan at 2 {
+		/* FAN3 (4-pin) */
+		reg = <0x02>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x02>;
+	};
+
+	fan at 3 {
+		/* FAN4 (6-pin) */
+		reg = <0x03>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x04 0x0b>;
+	};
+
+	fan at 4 {
+		/* FAN6 (6-pin) */
+		reg = <0x04>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x06 0x0d>;
+	};
+
+	fan at 5 {
+		/* FAN5 (6-pin) */
+		reg = <0x05>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x05 0x0c>;
+	};
+};
+
+&adc {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc0_default
+				&pinctrl_adc1_default
+				&pinctrl_adc2_default
+				&pinctrl_adc3_default
+				&pinctrl_adc4_default
+				&pinctrl_adc5_default
+				&pinctrl_adc6_default
+				&pinctrl_adc7_default
+				&pinctrl_adc8_default
+				&pinctrl_adc9_default
+				&pinctrl_adc10_default
+				&pinctrl_adc11_default
+				&pinctrl_adc12_default
+				&pinctrl_adc13_default
+				&pinctrl_adc14_default
+				&pinctrl_adc15_default>;
+};
-- 
2.43.0



From semen.protsenko at linaro.org  Fri Dec  1 16:40:09 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 18:40:09 -0600
Subject: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <20231201160925.3136868-15-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-15-peter.griffin@linaro.org>
Message-ID: <CAPLW+4kBOWFPx3Hr-=UoLWvRxCorzBY9RCOiBhfkKcU0LAa21Q@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Add support for the pin-controller found on the gs101 SoC used in
> Pixel 6 phones.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 159 ++++++++++++++++++
>  drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
>  drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
>  drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
>  drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
>  5 files changed, 198 insertions(+)
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> index cb965cf93705..e1a0668ecb16 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> @@ -796,3 +796,162 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
>         .ctrl           = fsd_pin_ctrl,
>         .num_ctrl       = ARRAY_SIZE(fsd_pin_ctrl),
>  };
> +
> +/*
> + * bank type for non-alive type
> + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
> + * (CONPDN bit field: 2, PUDPDN bit field: 4)
> + */
> +static struct samsung_pin_bank_type gs101_bank_type_off  = {
> +       .fld_width = { 4, 1, 4, 4, 2, 4, },
> +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
> +};

This is just the same as exynos850_bank_type_off (100% duplication).
Here is what I suggest. Now that it's obvious there is some common
platform for moder Exynos SoCs, and it's probably Exynos9, I'd suggest
next course of action (if maintainers agree):
  1. Remove this one
  2. Rename exynos850_bank_type_off to exynos9_bank_type_off
  3. Use it for both gs101 and exynos850

Does it make sense?

> +
> +/*
> + * bank type for alive type
> + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
> + */
> +static const struct samsung_pin_bank_type gs101_bank_type_alive = {
> +       .fld_width = { 4, 1, 4, 4, },
> +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
> +};

Ditto, it's a duplication of exynos850_bank_type_alive .

> +
> +/* pin banks of gs101 pin-controller (ALIVE) */
> +static const struct samsung_pin_bank_data gs101_pin_alive[] = {
> +       EXYNOS9_PIN_BANK_EINTW(8, 0x0, "gpa0", 0x00, 0x00),
> +       EXYNOS9_PIN_BANK_EINTW(7, 0x20, "gpa1", 0x04, 0x08),
> +       EXYNOS9_PIN_BANK_EINTW(5, 0x40, "gpa2", 0x08, 0x10),
> +       EXYNOS9_PIN_BANK_EINTW(4, 0x60, "gpa3", 0x0c, 0x18),
> +       EXYNOS9_PIN_BANK_EINTW(4, 0x80, "gpa4", 0x10, 0x1c),
> +       EXYNOS9_PIN_BANK_EINTW(7, 0xa0, "gpa5", 0x14, 0x20),
> +       EXYNOS9_PIN_BANK_EINTW(8, 0xc0, "gpa9", 0x18, 0x28),
> +       EXYNOS9_PIN_BANK_EINTW(2, 0xe0, "gpa10", 0x1c, 0x30),
> +};
> +
> +/* pin banks of gs101 pin-controller (FAR_ALIVE) */
> +static const struct samsung_pin_bank_data gs101_pin_far_alive[] = {
> +       EXYNOS9_PIN_BANK_EINTW(8, 0x0, "gpa6", 0x00, 0x00),
> +       EXYNOS9_PIN_BANK_EINTW(4, 0x20, "gpa7", 0x04, 0x08),
> +       EXYNOS9_PIN_BANK_EINTW(8, 0x40, "gpa8", 0x08, 0x0c),
> +       EXYNOS9_PIN_BANK_EINTW(2, 0x60, "gpa11", 0x0c, 0x14),
> +};
> +
> +/* pin banks of gs101 pin-controller (GSACORE) */
> +static const struct samsung_pin_bank_data gs101_pin_gsacore[] = {
> +       EXYNOS9_PIN_BANK_EINTG(2, 0x0, "gps0", 0x00, 0x00),
> +       EXYNOS9_PIN_BANK_EINTG(8, 0x20, "gps1", 0x04, 0x04),
> +       EXYNOS9_PIN_BANK_EINTG(3, 0x40, "gps2", 0x08, 0x0c),
> +};
> +
> +/* pin banks of gs101 pin-controller (GSACTRL) */
> +static const struct samsung_pin_bank_data gs101_pin_gsactrl[] = {
> +       EXYNOS9_PIN_BANK_EINTW(6, 0x0, "gps3", 0x00, 0x00),
> +};
> +
> +/* pin banks of gs101 pin-controller (PERIC0) */
> +static const struct samsung_pin_bank_data gs101_pin_peric0[] = {
> +       EXYNOS9_PIN_BANK_EINTG(5, 0x0, "gpp0", 0x00, 0x00),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x20, "gpp1", 0x04, 0x08),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x40, "gpp2", 0x08, 0x0c),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0x60, "gpp3", 0x0c, 0x10),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x80, "gpp4", 0x10, 0x14),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0xa0, "gpp5", 0x14, 0x18),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0xc0, "gpp6", 0x18, 0x1c),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0xe0, "gpp7", 0x1c, 0x20),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x100, "gpp8", 0x20, 0x24),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0x120, "gpp9", 0x24, 0x28),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x140, "gpp10", 0x28, 0x2c),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0x160, "gpp11", 0x2c, 0x30),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x180, "gpp12", 0x30, 0x34),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0x1a0, "gpp13", 0x34, 0x38),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x1c0, "gpp14", 0x38, 0x3c),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0x1e0, "gpp15", 0x3c, 0x40),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x200, "gpp16", 0x40, 0x44),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0x220, "gpp17", 0x44, 0x48),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x240, "gpp18", 0x48, 0x4c),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x260, "gpp19", 0x4c, 0x50),
> +};
> +
> +/* pin banks of gs101 pin-controller (PERIC1) */
> +static const struct samsung_pin_bank_data gs101_pin_peric1[] = {
> +       EXYNOS9_PIN_BANK_EINTG(8, 0x0, "gpp20", 0x00, 0x00),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x20, "gpp21", 0x04, 0x08),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0x40, "gpp22", 0x08, 0x0c),
> +       EXYNOS9_PIN_BANK_EINTG(8, 0x60, "gpp23", 0x0c, 0x10),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0x80, "gpp24", 0x10, 0x18),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0xa0, "gpp25", 0x14, 0x1c),
> +       EXYNOS9_PIN_BANK_EINTG(5, 0xc0, "gpp26", 0x18, 0x20),
> +       EXYNOS9_PIN_BANK_EINTG(4, 0xe0, "gpp27", 0x1c, 0x28),
> +};
> +
> +/* pin banks of gs101 pin-controller (HSI1) */
> +static const struct samsung_pin_bank_data gs101_pin_hsi1[] = {
> +       EXYNOS9_PIN_BANK_EINTG(6, 0x0, "gph0", 0x00, 0x00),
> +       EXYNOS9_PIN_BANK_EINTG(7, 0x20, "gph1", 0x04, 0x08),
> +};
> +
> +/* pin banks of gs101 pin-controller (HSI2) */
> +static const struct samsung_pin_bank_data gs101_pin_hsi2[] = {
> +       EXYNOS9_PIN_BANK_EINTG(6, 0x0, "gph2", 0x00, 0x00),
> +       EXYNOS9_PIN_BANK_EINTG(2, 0x20, "gph3", 0x04, 0x08),
> +       EXYNOS9_PIN_BANK_EINTG(6, 0x40, "gph4", 0x08, 0x0c),
> +};
> +
> +static const struct samsung_pin_ctrl gs101_pin_ctrl[] __initconst = {
> +       {
> +               /* pin banks of gs101 pin-controller (ALIVE) */
> +               .pin_banks      = gs101_pin_alive,
> +               .nr_banks       = ARRAY_SIZE(gs101_pin_alive),
> +               .eint_wkup_init = exynos_eint_wkup_init,
> +               .suspend        = exynos_pinctrl_suspend,
> +               .resume         = exynos_pinctrl_resume,
> +       }, {
> +               /* pin banks of gs101 pin-controller (FAR_ALIVE) */
> +               .pin_banks      = gs101_pin_far_alive,
> +               .nr_banks       = ARRAY_SIZE(gs101_pin_far_alive),
> +               .eint_wkup_init = exynos_eint_wkup_init,
> +               .suspend        = exynos_pinctrl_suspend,
> +               .resume         = exynos_pinctrl_resume,
> +       }, {
> +               /* pin banks of gs101 pin-controller (GSACORE) */
> +               .pin_banks      = gs101_pin_gsacore,
> +               .nr_banks       = ARRAY_SIZE(gs101_pin_gsacore),
> +       }, {
> +               /* pin banks of gs101 pin-controller (GSACTRL) */
> +               .pin_banks      = gs101_pin_gsactrl,
> +               .nr_banks       = ARRAY_SIZE(gs101_pin_gsactrl),
> +       }, {
> +               /* pin banks of gs101 pin-controller (PERIC0) */
> +               .pin_banks      = gs101_pin_peric0,
> +               .nr_banks       = ARRAY_SIZE(gs101_pin_peric0),
> +               .eint_gpio_init = exynos_eint_gpio_init,
> +               .suspend        = exynos_pinctrl_suspend,
> +               .resume         = exynos_pinctrl_resume,
> +       }, {
> +               /* pin banks of gs101 pin-controller (PERIC1) */
> +               .pin_banks      = gs101_pin_peric1,
> +               .nr_banks       = ARRAY_SIZE(gs101_pin_peric1),
> +               .eint_gpio_init = exynos_eint_gpio_init,
> +               .suspend        = exynos_pinctrl_suspend,
> +               .resume = exynos_pinctrl_resume,
> +       }, {
> +               /* pin banks of gs101 pin-controller (HSI1) */
> +               .pin_banks      = gs101_pin_hsi1,
> +               .nr_banks       = ARRAY_SIZE(gs101_pin_hsi1),
> +               .eint_gpio_init = exynos_eint_gpio_init,
> +               .suspend        = exynos_pinctrl_suspend,
> +               .resume         = exynos_pinctrl_resume,
> +       }, {
> +               /* pin banks of gs101 pin-controller (HSI2) */
> +               .pin_banks      = gs101_pin_hsi2,
> +               .nr_banks       = ARRAY_SIZE(gs101_pin_hsi2),
> +               .eint_gpio_init = exynos_eint_gpio_init,
> +               .suspend        = exynos_pinctrl_suspend,
> +               .resume         = exynos_pinctrl_resume,
> +       },
> +};
> +
> +const struct samsung_pinctrl_of_match_data gs101_of_data __initconst = {
> +       .ctrl           = gs101_pin_ctrl,
> +       .num_ctrl       = ARRAY_SIZE(gs101_pin_ctrl),
> +};
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index 56fc11a1fe2f..75b9cf72ce73 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -537,6 +537,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
>                         .data = &exynos7_wkup_irq_chip },
>         { .compatible = "samsung,exynosautov9-wakeup-eint",
>                         .data = &exynos7_wkup_irq_chip },
> +       { .compatible = "google,gs101-wakeup-eint",
> +                       .data = &exynos7_wkup_irq_chip },
>         { }
>  };
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
> index e2799ff1b5e9..1ffc90db079d 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
> @@ -147,6 +147,40 @@
>                 .name           = id                            \
>         }
>
> +#define EXYNOS9_PIN_BANK_EINTN(types, pins, reg, id)   \
> +       {                                               \
> +               .type           = &types,               \
> +               .pctl_offset    = reg,                  \
> +               .nr_pins        = pins,                 \
> +               .eint_type      = EINT_TYPE_NONE,       \
> +               .fltcon_type    = FLT_DEFAULT           \
> +               .name           = id                    \
> +       }

Where exactly it is used? What is 'types'? Moreover, it doesn't look
very different from EXYNOS850_PIN_BANK_EINTN() -- just because I
created EXYNOS850_PIN_BANK_EINTN() exactly from this downstream macro.
I was strictly prohibited adding EXYNOS9_* stuff back at the time. But
now I guess it should be apparent we are actually dealing with Exynos9
common platform. So I suggest renaming EXYNOS850_PIN_BANK_EINTN() to
EXYNOS9_PIN_BANK_EINTN().

> +
> +#define EXYNOS9_PIN_BANK_EINTG(pins, reg, id, offs, fltcon_offs) \
> +       {                                               \
> +               .type           = &gs101_bank_type_off, \
> +               .pctl_offset    = reg,                  \
> +               .nr_pins        = pins,                 \
> +               .eint_type      = EINT_TYPE_GPIO,       \
> +               .eint_offset    = offs,                 \
> +               .fltcon_type    = FLT_DEFAULT,          \
> +               .fltcon_offset  = fltcon_offs,          \
> +               .name           = id                    \
> +       }

Ditto. Please add filter fields to EXYNOS850_PIN_BANK_EINTG() instead
of adding pretty much the same macro (it is the same, I created
EXYNOS850_PIN_BANK_EINTG() from exactly this macro). Also I suggest
renaming EXYNOS850_PIN_BANK_EINTG() to EXYNOS9_PIN_BANK_EINTG(), to
avoid confusion. If you need any help with reworking Exynos850 pinctrl
correspondingly, please let me know.

> +
> +#define EXYNOS9_PIN_BANK_EINTW(pins, reg, id, offs, fltcon_offs) \
> +       {                                                       \
> +               .type           = &gs101_bank_type_alive,       \
> +               .pctl_offset    = reg,                          \
> +               .nr_pins        = pins,                         \
> +               .eint_type      = EINT_TYPE_WKUP,               \
> +               .eint_offset    = offs,                         \
> +               .fltcon_type    = FLT_SELECTABLE,               \
> +               .fltcon_offset  = fltcon_offs,                  \
> +               .name           = id                            \
> +       }

Ditto.

> +
>  /**
>   * struct exynos_weint_data: irq specific data for all the wakeup interrupts
>   * generated by the external wakeup interrupt controller.
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 50c360b4753a..982a5702714c 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -1323,6 +1323,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
>                 .data = &exynosautov9_of_data },
>         { .compatible = "tesla,fsd-pinctrl",
>                 .data = &fsd_of_data },
> +       { .compatible = "google,gs101-pinctrl",
> +               .data = &gs101_of_data },
>  #endif
>  #ifdef CONFIG_PINCTRL_S3C64XX
>         { .compatible = "samsung,s3c64xx-pinctrl",
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> index 5fab3885a7d7..f6856290608c 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> @@ -373,6 +373,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
>  extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
>  extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
>  extern const struct samsung_pinctrl_of_match_data fsd_of_data;
> +extern const struct samsung_pinctrl_of_match_data gs101_of_data;
>  extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
>  extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
>  extern const struct samsung_pinctrl_of_match_data s3c2416_of_data;
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From renze at rnplus.nl  Fri Dec  1 16:44:17 2023
From: renze at rnplus.nl (Renze Nicolai)
Date: Sat, 02 Dec 2023 01:44:17 +0100
Subject: [PATCH v3 0/2] ARM: dts: aspeed: asrock: Add ASRock X570D4U BMC
In-Reply-To: <20231202003908.3635695-1-renze@rnplus.nl>
References: <20231202003908.3635695-1-renze@rnplus.nl>
Message-ID: <12332130.O9o76ZdvQC@werkpc>

Hello again,

A small addition to my cover letter for v3 of the patch:

I forgot to mention in the changelog from v2 to v3 that I also modified the 
tachometer configuration to correctly map the tachometer inputs to the fan 
headers on the board.

Greetings,
Renze Nicolai

On Saturday, December 2, 2023 1:38:43 AM CET you wrote:
> Hello,
> 
> These patches add a device-tree (and a bindings update) for the
> Aspeed BMC on the ASRock X570D4U, so that it can be added as a
> supported OpenBMC platform.
> 
> Changes since v2:
>   - Renamed leds to led-0 and led-1 to match
> Documentation/devicetree/bindings/leds/leds-gpio.yaml - Added aliasses and
> labels for the i2c-mux on i2c bus 4
>   - Added the missing blank line between the ehci1 and uhci nodes
> 
> Greetings,
> Renze Nicolai
> 
> Renze Nicolai (2):
>   dt-bindings: arm: aspeed: add Asrock X570D4U board
>   ARM: dts: aspeed: asrock: Add ASRock X570D4U BMC
> 
>  .../bindings/arm/aspeed/aspeed.yaml           |   1 +
>  arch/arm/boot/dts/aspeed/Makefile             |   1 +
>  .../dts/aspeed/aspeed-bmc-asrock-x570d4u.dts  | 377 ++++++++++++++++++
>  3 files changed, 379 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts






From seanjc at google.com  Fri Dec  1 16:51:55 2023
From: seanjc at google.com (Sean Christopherson)
Date: Fri, 1 Dec 2023 16:51:55 -0800
Subject: [PATCH 05/26] vfio: KVM: Pass get/put helpers from KVM to VFIO,
 don't do circular lookup
In-Reply-To: <20230918160258.GL13795@ziepe.ca>
References: <20230916003118.2540661-1-seanjc@google.com> <20230916003118.2540661-6-seanjc@google.com>
 <20230918152110.GI13795@ziepe.ca> <ZQhxpesyXeG+qbS6@google.com> <20230918160258.GL13795@ziepe.ca>
Message-ID: <ZWp_q1w01NCZi8KX@google.com>

On Mon, Sep 18, 2023, Jason Gunthorpe wrote:
> On Mon, Sep 18, 2023 at 08:49:57AM -0700, Sean Christopherson wrote:
> > On Mon, Sep 18, 2023, Jason Gunthorpe wrote:
> > > On Fri, Sep 15, 2023 at 05:30:57PM -0700, Sean Christopherson wrote:
> > > > Explicitly pass KVM's get/put helpers to VFIO when attaching a VM to
> > > > VFIO instead of having VFIO do a symbol lookup back into KVM.  Having both
> > > > KVM and VFIO do symbol lookups increases the overall complexity and places
> > > > an unnecessary dependency on KVM (from VFIO) without adding any value.
> > > > 
> > > > Signed-off-by: Sean Christopherson <seanjc at google.com>
> > > > ---
> > > >  drivers/vfio/vfio.h      |  2 ++
> > > >  drivers/vfio/vfio_main.c | 74 +++++++++++++++++++---------------------
> > > >  include/linux/vfio.h     |  4 ++-
> > > >  virt/kvm/vfio.c          |  9 +++--
> > > >  4 files changed, 47 insertions(+), 42 deletions(-)
> > > 
> > > I don't mind this, but Christoph had disliked my prior attempt to do
> > > this with function pointers..
> > > 
> > > The get can be inlined, IIRC, what about putting a pointer to the put
> > > inside the kvm struct?
> > 
> > That wouldn't allow us to achieve our goal, which is to hide the details of
> > "struct kvm" from VFIO (and the rest of the kernel).
> 
> > What's the objection to handing VFIO a function pointer?
> 
> Hmm, looks like it was this thread:
> 
>  https://lore.kernel.org/r/0-v1-33906a626da1+16b0-vfio_kvm_no_group_jgg at nvidia.com
> 
> Your rational looks a little better to me.
> 
> > > The the normal kvm get/put don't have to exported symbols at all?
> > 
> > The export of kvm_get_kvm_safe() can go away (I forgot to do that in this series),
> > but kvm_get_kvm() will hang around as it's needed by KVM sub-modules (PPC and x86),
> > KVMGT (x86), and drivers/s390/crypto/vfio_ap_ops.c (no idea what to call that beast).
> 
> My thought would be to keep it as an inline, there should be some way
> to do that without breaking your desire to hide the bulk of the kvm
> struct content. Like put the refcount as the first element in the
> struct and just don't ifdef it away?.

That doesn't work because of the need to invoke kvm_destroy_vm() when the last
reference is put, i.e. all of kvm_destroy_vm() would need to be inlined (LOL) or
VFIO would need to do a symbol lookup on kvm_destroy_vm(), which puts back us at
square one.

There's one more wrinkle: this patch is buggy in that it doesn't ensure the liveliness
of KVM-the-module, i.e. nothing prevents userspace from unloading kvm.ko while VFIO
still holds a reference to a kvm structure, and so invoking ->put_kvm() could jump
into freed code.  To fix that, KVM would also need to pass along a module pointer :-(

One thought would be to have vac.ko (tentative name), which is the "base" module
that will hold the KVM/virtualization bits that need to be singletons, i.e. can't
be per-KVM, provide the symbols needed for VFIO to manage references.  But that
just ends up moving the module reference trickiness into VAC+KVM, e.g. vac.ko would
still need to be handed a function pointer in order to call back into the correct
kvm.ko code.

Hrm, but I suspect the vac.ko <=> kvm.ko interactions will need to deal with
module shenanigans anyways, and the shenanigans would only affect crazy people
like us that actually want multiple KVM modules.

I'll plan on going that route.  The very worst case scenario is that it just punts
this conversation down to a possibile future.  Dropping this patch and the previous
prep patch won't meaningful affect the goals of this series, as only kvm_get_kvm_safe()
and kvm_get_kvm() would need to be exposed outside of #ifdef __KVM__.  Then we can
figure out what to do with them if/when the whole multi-KVM thing comes along.


From semen.protsenko at linaro.org  Fri Dec  1 16:53:46 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 18:53:46 -0600
Subject: [PATCH v5 15/20] watchdog: s3c2410_wdt: Add support for WTCON
 register DBGACK_MASK bit
In-Reply-To: <20231201160925.3136868-16-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-16-peter.griffin@linaro.org>
Message-ID: <CAPLW+4=2aK-XJ69cTBzwhQF8s3E9in-NFkK3h43L7C+oieqyDg@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> The WDT uses the CPU core signal DBGACK to determine whether the SoC
> is running in debug mode or not. If the DBGACK signal is asserted and
> DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
> (disabled).
>
> Presence of the DBGACK_MASK bit is determined by adding a new
> QUIRK_HAS_DBGACK_BIT quirk.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  drivers/watchdog/s3c2410_wdt.c | 27 ++++++++++++++++++++++++---
>  1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> index 0b4bd883ff28..39f3489e41d6 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -34,9 +34,10 @@
>
>  #define S3C2410_WTCNT_MAXCNT   0xffff
>
> -#define S3C2410_WTCON_RSTEN    (1 << 0)
> -#define S3C2410_WTCON_INTEN    (1 << 2)
> -#define S3C2410_WTCON_ENABLE   (1 << 5)
> +#define S3C2410_WTCON_RSTEN            (1 << 0)
> +#define S3C2410_WTCON_INTEN            (1 << 2)
> +#define S3C2410_WTCON_ENABLE           (1 << 5)
> +#define S3C2410_WTCON_DBGACK_MASK      (1 << 16)

Suggest using BIT() macro. Btw, checkpatch with --strict option
suggests it too :)

>
>  #define S3C2410_WTCON_DIV16    (0 << 3)
>  #define S3C2410_WTCON_DIV32    (1 << 3)
> @@ -100,12 +101,17 @@
>   * %QUIRK_HAS_PMU_CNT_EN: PMU block has some register (e.g. CLUSTERx_NONCPU_OUT)
>   * with "watchdog counter enable" bit. That bit should be set to make watchdog
>   * counter running.
> + *
> + * %QUIRK_HAS_DBGACK_BIT: WTCON register has DBGACK_MASK bit. Setting the
> + * DBGACK_MASK bit disables the watchdog outputs when the SoC is in debug mode.
> + * Debug mode is determined by the DBGACK CPU signal.
>   */
>  #define QUIRK_HAS_WTCLRINT_REG                 (1 << 0)
>  #define QUIRK_HAS_PMU_MASK_RESET               (1 << 1)
>  #define QUIRK_HAS_PMU_RST_STAT                 (1 << 2)
>  #define QUIRK_HAS_PMU_AUTO_DISABLE             (1 << 3)
>  #define QUIRK_HAS_PMU_CNT_EN                   (1 << 4)
> +#define QUIRK_HAS_DBGACK_BIT                   (1 << 5)
>
>  /* These quirks require that we have a PMU register map */
>  #define QUIRKS_HAVE_PMUREG \
> @@ -375,6 +381,19 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
>         return 0;
>  }
>
> +static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt)
> +{
> +       unsigned long wtcon;
> +
> +       if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
> +               return;
> +
> +       /*  disable watchdog outputs if CPU is in debug mode */

Double whitespace in the comment. Also, I'd move this comment up to
the function declaration.

Other than that:

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

> +       wtcon = readl(wdt->reg_base + S3C2410_WTCON);
> +       wtcon |= S3C2410_WTCON_DBGACK_MASK;
> +       writel(wtcon, wdt->reg_base + S3C2410_WTCON);
> +}
> +
>  static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
>  {
>         struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
> @@ -700,6 +719,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
>         wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
>         wdt->wdt_device.parent = dev;
>
> +       s3c2410wdt_mask_dbgack(wdt);
> +
>         /*
>          * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
>          * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From dianders at chromium.org  Fri Dec  1 16:56:08 2023
From: dianders at chromium.org (Doug Anderson)
Date: Fri, 1 Dec 2023 16:56:08 -0800
Subject: [RFC PATCH v3 1/5] of: dynamic: Add of_changeset_update_prop_string
In-Reply-To: <20231128084236.157152-2-wenst@chromium.org>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-2-wenst@chromium.org>
Message-ID: <CAD=FV=V_v11eZ6+3gUwOvdWGNM9owG7zCK5EiezTY7RJ3eaEMw@mail.gmail.com>

Hi,

On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> @@ -1039,3 +1039,50 @@ int of_changeset_add_prop_u32_array(struct of_changeset *ocs,
>         return ret;
>  }
>  EXPORT_SYMBOL_GPL(of_changeset_add_prop_u32_array);
> +
> +static int of_changeset_update_prop_helper(struct of_changeset *ocs,
> +                                          struct device_node *np,
> +                                          const struct property *pp)
> +{
> +       struct property *new_pp;
> +       int ret;
> +
> +       new_pp = __of_prop_dup(pp, GFP_KERNEL);
> +       if (!new_pp)
> +               return -ENOMEM;
> +
> +       ret = of_changeset_update_property(ocs, np, new_pp);
> +       if (ret) {
> +               kfree(new_pp->name);
> +               kfree(new_pp->value);
> +               kfree(new_pp);

Given that this is the 3rd copy of the freeing logic, does it make
sense to make __of_prop_free() that's documented to free what was
returned by __of_prop_dupe()?


From dianders at chromium.org  Fri Dec  1 16:57:46 2023
From: dianders at chromium.org (Doug Anderson)
Date: Fri, 1 Dec 2023 16:57:46 -0800
Subject: [RFC PATCH v3 2/5] i2c: of: Introduce component probe function
In-Reply-To: <20231128084236.157152-3-wenst@chromium.org>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-3-wenst@chromium.org>
Message-ID: <CAD=FV=U_+iQJtV0Wii89DQT1V_fJCeS9wcqA8EJAs-hmmmLLLg@mail.gmail.com>

Hi,

On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> @@ -217,4 +217,114 @@ static int of_i2c_notify(struct notifier_block *nb, unsigned long action,
>  struct notifier_block i2c_of_notifier = {
>         .notifier_call = of_i2c_notify,
>  };
> +
> +/*
> + * Some devices, such as Google Hana Chromebooks, are produced by multiple
> + * vendors each using their preferred components. Such components are all
> + * in the device tree. Instead of having all of them enabled and having each
> + * driver separately try and probe its device while fighting over shared
> + * resources, they can be marked as "fail-needs-probe" and have a prober
> + * figure out which one is actually used beforehand.
> + *
> + * This prober assumes such drop-in parts are on the same I2C bus, have
> + * non-conflicting addresses, and can be directly probed by seeing which
> + * address responds.
> + *
> + * TODO:
> + * - Support handling common regulators and GPIOs.

IMO you should prototype how you're going to handle regulators and
GPIOs before finalizing the design. I was going to write that you
should just document that it was up to the caller to power things up
before calling this function, but then I realized that the caller
would have to duplicate much of this function in order to do so. In
the very least they'd have to find the nodes of the relevant devices
so that they could grab regulators and/or GPIOs. In order to avoid
this duplication, would the design need to change? Perhaps this would
be as simple as adding a callback function here that's called with all
of the nodes before probing? If that's right, it would be nice to have
that callback from the beginning so we don't need two variants of the
function...

> + * - Support I2C muxes
> + */
> +
> +/**
> + * i2c_of_probe_component() - probe for devices of "type" on the same i2c bus
> + * @dev: &struct device of the caller, only used for dev_* printk messages
> + * @type: a string to match the device node name prefix to probe for
> + *
> + * Probe for possible I2C components of the same "type" on the same I2C bus
> + * that have their status marked as "fail".

Should document these current limitations with the code:

* Assumes that across the entire device tree the only instances of
nodes named "type" are ones we're trying to handle second sourcing
for. In other words if we're searching for "touchscreen" then all
nodes named "touchscreen" are ones that need to be probed.

* Assumes that there is exactly one group of each "type". In other
words, if we're searching for "touchscreen" then exactly one
touchscreen will be enabled across the whole tree.

Obviously those could be relaxed with more code, but that's the
current limitation and it makes the code easier to understand with
that context.


> + */
> +int i2c_of_probe_component(struct device *dev, const char *type)
> +{
> +       struct device_node *node, *i2c_node;
> +       struct i2c_adapter *i2c;
> +       struct of_changeset *ocs = NULL;
> +       int ret;
> +
> +       node = of_find_node_by_name(NULL, type);
> +       if (!node)
> +               return dev_err_probe(dev, -ENODEV, "Could not find %s device node\n", type);
> +
> +       i2c_node = of_get_next_parent(node);
> +       if (!of_node_name_eq(i2c_node, "i2c")) {
> +               of_node_put(i2c_node);
> +               return dev_err_probe(dev, -EINVAL, "%s device isn't on I2C bus\n", type);
> +       }

Personally I'd skip checking for the "i2c" node name. Just rely on
of_get_i2c_adapter_by_node() returning an error.

Oh, I guess you have this because you need to tell the difference
between -EINVAL and -EPROBE_DEFER? It feels like instead you could use
the firmware node to lookup a device more generically. If a device
isn't associated with the node at all then you return -EPROBE_DEFER.
Otherwise if it's associated but not an i2c device then you return
-EINVAL. I guess maybe it doesn't make a huge difference, but it
somehow feels less fragile than relying on the node name being "i2c".
Maybe I just haven't had enough DT Kool-Aid.

One thing this made me wonder is if of_get_i2c_adapter_by_node() is
race free anyway. Can't that return you a device that hasn't finished
probing yet? I see:

- i2c_register_adapter()
-- device_register()
--- device_add()
---- bus_add_device()
---- bus_probe_device()

As soon as bus_add_device() is called then it will be in
"klist_devices" and I believe i2c_find_device_by_fwnode() will be able
to find it. However, it hasn't necessarily been probed yet. I think
that means calling i2c_smbus_xfer() on it might not work yet...


One last thing is that you should check to make sure that the i2c
adapter is not marked "disabled". ...otherwise I think you'd end up
constantly trying again and again...


> +       for_each_child_of_node(i2c_node, node) {
> +               if (!of_node_name_prefix(node, type))
> +                       continue;
> +               if (of_device_is_available(node)) {
> +                       /*
> +                        * Device tree has component already enabled. Either the
> +                        * device tree isn't supported or we already probed once.

I guess the "already probed once" is somewhat expected if more than
one type of second source component is defined and we end up deferring
the second one? We don't undo the resolution of the first one and
probably don't keep track of the fact that it succeeded?

Probably should be added to the function comments that this is an
expected/normal case?


> +                        */
> +                       of_node_put(node);
> +                       of_node_put(i2c_node);
> +                       return 0;
> +               }
> +       }
> +
> +       i2c = of_get_i2c_adapter_by_node(i2c_node);
> +       if (!i2c) {
> +               of_node_put(i2c_node);
> +               return dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> +       }
> +
> +       ret = 0;

Why init ret to 0?


> +       for_each_child_of_node(i2c_node, node) {
> +               union i2c_smbus_data data;
> +               u32 addr;
> +
> +               if (!of_node_name_prefix(node, type))
> +                       continue;
> +               if (of_property_read_u32(node, "reg", &addr))
> +                       continue;
> +               if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)

I'd be tempted to say that the caller should be able to pass in a
function pointer here so they could use an alternative method to probe
instead of i2c_smbus_xfer(), though you'd want to make it easy to
default to i2c_smbus_xfer(). I could imagine someone might need a
different way to probe. For instance if you had two touchscreens both
at the same "reg" but that had different "hid-descr-addr" then this
could be important.


> +                       continue;
> +

Put the "break" right here. You've found the device and that was the
point of the loop.

Once you do that then the error handling makes a little more sense. It
was weird that the error handling was jumped through from inside the
loop...


> +               dev_info(dev, "Enabling %pOF\n", node);
> +
> +               ocs = kzalloc(sizeof(*ocs), GFP_KERNEL);
> +               if (!ocs) {
> +                       ret = -ENOMEM;
> +                       goto err_put_node;

I think this error path (and some others) miss "i2c_put_adapter()" and
"of_node_put(i2c_node)"


From dianders at chromium.org  Fri Dec  1 16:58:34 2023
From: dianders at chromium.org (Doug Anderson)
Date: Fri, 1 Dec 2023 16:58:34 -0800
Subject: [RFC PATCH v3 4/5] arm64: dts: mediatek: mt8173-elm-hana: Mark
 touchscreens and trackpads as fail
In-Reply-To: <20231128084236.157152-5-wenst@chromium.org>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-5-wenst@chromium.org>
Message-ID: <CAD=FV=W01gfxV6RN2o6CVS7jjf8qgKP-jUy9Bp94d2hWzVC48A@mail.gmail.com>

Hi,

On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> @@ -44,6 +46,7 @@ trackpad2: trackpad at 2c {
>                 reg = <0x2c>;
>                 hid-descr-addr = <0x0020>;
>                 wakeup-source;
> +               status = "fail-needs-probe";

While doing this, you could also remove the hack where the trackpad
IRQ pinctrl is listed under i2c4.


From semen.protsenko at linaro.org  Fri Dec  1 17:02:35 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 19:02:35 -0600
Subject: [PATCH v5 16/20] watchdog: s3c2410_wdt: Add support for Google
 gs101 SoC
In-Reply-To: <20231201160925.3136868-17-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-17-peter.griffin@linaro.org>
Message-ID: <CAPLW+4mxzu4d_9i=ouDGtnSRMbhibfBnT5aXhkC4cGEC1bm6Bw@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> This patch adds the compatibles and drvdata for the Google
> gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.
>
> Similar to Exynos850 it has two watchdog instances, one for
> each cluster and has some control bits in PMU registers.
>
> gs101 also has the dbgack_mask bit in wtcon register, so
> we also enable QUIRK_HAS_DBGACK_BIT.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  drivers/watchdog/s3c2410_wdt.c | 47 ++++++++++++++++++++++++++++++----
>  1 file changed, 42 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> index 39f3489e41d6..c1ae71574457 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -68,6 +68,13 @@
>  #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT     25
>  #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT     24
>
> +#define GS_CLUSTER0_NONCPU_OUT                 0x1220
> +#define GS_CLUSTER1_NONCPU_OUT                 0x1420
> +#define GS_CLUSTER0_NONCPU_INT_EN              0x1244
> +#define GS_CLUSTER1_NONCPU_INT_EN              0x1444
> +#define GS_CLUSTER2_NONCPU_INT_EN              0x1644
> +#define GS_RST_STAT_REG_OFFSET                 0x3B44
> +
>  /**
>   * DOC: Quirk flags for different Samsung watchdog IP-cores
>   *
> @@ -269,6 +276,30 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
>                   QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
>  };
>
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
> +       .mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
> +       .mask_bit = 2,
> +       .mask_reset_inv = true,
> +       .rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +       .rst_stat_bit = 0,
> +       .cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
> +       .cnt_en_bit = 8,
> +       .quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |

Please keep it at 80 characters limit.

> +                 QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT,
> +};
> +
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
> +       .mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
> +       .mask_bit = 2,
> +       .mask_reset_inv = true,
> +       .rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +       .rst_stat_bit = 1,
> +       .cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
> +       .cnt_en_bit = 7,
> +       .quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |

Please keep it at 80 characters limit.

> +                 QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT,
> +};
> +
>  static const struct of_device_id s3c2410_wdt_match[] = {
>         { .compatible = "samsung,s3c2410-wdt",
>           .data = &drv_data_s3c2410 },
> @@ -284,6 +315,8 @@ static const struct of_device_id s3c2410_wdt_match[] = {
>           .data = &drv_data_exynos850_cl0 },
>         { .compatible = "samsung,exynosautov9-wdt",
>           .data = &drv_data_exynosautov9_cl0 },
> +       { .compatible = "google,gs101-wdt",
> +         .data = &drv_data_gs101_cl0 },
>         {},
>  };
>  MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
> @@ -604,9 +637,10 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>         }
>
>  #ifdef CONFIG_OF
> -       /* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
> +       /* Choose Exynos850/ExynosAutov9/gs101 driver data w.r.t. cluster index */

Please keep it at 80 characters limit. Also, maybe just make it more
generic and mention "Exynos9 platforms" instead of listing all SoCs?

Other than that:

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>


>         if (variant == &drv_data_exynos850_cl0 ||
> -           variant == &drv_data_exynosautov9_cl0) {
> +           variant == &drv_data_exynosautov9_cl0 ||
> +           variant == &drv_data_gs101_cl0) {
>                 u32 index;
>                 int err;
>
> @@ -619,9 +653,12 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>                 case 0:
>                         break;
>                 case 1:
> -                       variant = (variant == &drv_data_exynos850_cl0) ?
> -                               &drv_data_exynos850_cl1 :
> -                               &drv_data_exynosautov9_cl1;
> +                       if (variant == &drv_data_exynos850_cl0)
> +                               variant = &drv_data_exynos850_cl1;
> +                       else if (variant == &drv_data_exynosautov9_cl0)
> +                               variant = &drv_data_exynosautov9_cl1;
> +                       else if (variant == &drv_data_gs101_cl0)
> +                               variant = &drv_data_gs101_cl1;
>                         break;
>                 default:
>                         return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From dianders at chromium.org  Fri Dec  1 16:58:20 2023
From: dianders at chromium.org (Doug Anderson)
Date: Fri, 1 Dec 2023 16:58:20 -0800
Subject: [RFC PATCH v3 3/5] platform/chrome: Introduce device tree
 hardware prober
In-Reply-To: <20231128084236.157152-4-wenst@chromium.org>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-4-wenst@chromium.org>
Message-ID: <CAD=FV=XV0+G=uFBE_n6WFGVW2szGcKToZgCNTdSrNf3LVk9MOQ@mail.gmail.com>

Hi,

On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> @@ -61,6 +61,17 @@ config CHROMEOS_TBMC
>           To compile this driver as a module, choose M here: the
>           module will be called chromeos_tbmc.
>
> +config CHROMEOS_OF_HW_PROBER
> +       bool "ChromeOS Device Tree Hardware Prober"

Any reason that it can't be a module?


> +       depends on OF
> +       depends on I2C
> +       select OF_DYNAMIC
> +       default OF

You probably don't want "default OF". This means that everyone will
automatically get this new driver enabled which is unlikely to be
right.


> +static int chromeos_of_hw_prober_probe(struct platform_device *pdev)
> +{
> +       for (size_t i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
> +               if (of_machine_is_compatible(hw_prober_platforms[i].compatible)) {
> +                       int ret;
> +
> +                       ret = hw_prober_platforms[i].prober(&pdev->dev,
> +                                                           hw_prober_platforms[i].data);
> +                       if (ret)

Should it only check for -EPROBE_DEFER here? ...and then maybe warn
for other cases and go through the loop? If there's some error
enabling the touchscreen I'd still want the trackpad to probe...


> +                               return ret;
> +               }
> +
> +       return 0;

Random thought: once we get here, the driver is useless / just wasting
memory. Any way to have it freed? ;-)


From semen.protsenko at linaro.org  Fri Dec  1 17:09:30 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 19:09:30 -0600
Subject: [PATCH v5 17/20] tty: serial: samsung: Add gs101 compatible and
 common fifoszdt_serial_drv_data
In-Reply-To: <20231201160925.3136868-18-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-18-peter.griffin@linaro.org>
Message-ID: <CAPLW+4mGykKdYuhjcpYQwk7cabo0mFv6Qo3UedcrVcLvMkww_Q@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Add serial driver data for Google Tensor gs101 SoC and a common
> fifoszdt_serial_drv_data that can be used by platforms that specify the
> samsung,uart-fifosize DT property.
>
> A corresponding dt-bindings patch updates the yaml to ensure
> samsung,uart-fifosize is a required property.
>
> Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Reviewed-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  drivers/tty/serial/samsung_tty.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> index 1b0c2b467a30..f8d98f1006de 100644
> --- a/drivers/tty/serial/samsung_tty.c
> +++ b/drivers/tty/serial/samsung_tty.c
> @@ -2490,14 +2490,25 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
>         .fifosize = { 256, 64, 64, 64 },
>  };
>
> +/*
> + * Common drv_data struct for platforms that specify uart,fifosize in
> + * device tree.

Isn't it "samsung,uart-fifosize"? Or it was intended this way?

Other than this, LGTM (my R-b tag is already present in this patch).

> + */
> +static const struct s3c24xx_serial_drv_data exynos_fifoszdt_serial_drv_data = {
> +       EXYNOS_COMMON_SERIAL_DRV_DATA(),
> +       .fifosize = { 0 },
> +};
> +
>  #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
>  #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
>  #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
> +#define EXYNOS_FIFOSZDT_DRV_DATA (&exynos_fifoszdt_serial_drv_data)
>
>  #else
>  #define EXYNOS4210_SERIAL_DRV_DATA NULL
>  #define EXYNOS5433_SERIAL_DRV_DATA NULL
>  #define EXYNOS850_SERIAL_DRV_DATA NULL
> +#define EXYNOS_FIFOSZDT_DRV_DATA NULL
>  #endif
>
>  #ifdef CONFIG_ARCH_APPLE
> @@ -2581,6 +2592,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
>         }, {
>                 .name           = "artpec8-uart",
>                 .driver_data    = (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
> +       }, {
> +               .name           = "gs101-uart",
> +               .driver_data    = (kernel_ulong_t)EXYNOS_FIFOSZDT_DRV_DATA,
>         },
>         { },
>  };
> @@ -2602,6 +2616,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
>                 .data = EXYNOS850_SERIAL_DRV_DATA },
>         { .compatible = "axis,artpec8-uart",
>                 .data = ARTPEC8_SERIAL_DRV_DATA },
> +       { .compatible = "google,gs101-uart",
> +               .data = EXYNOS_FIFOSZDT_DRV_DATA },
>         {},
>  };
>  MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From alim.akhtar at samsung.com  Fri Dec  1 17:36:53 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Sat, 2 Dec 2023 07:06:53 +0530
Subject: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl
 configuration
In-Reply-To: <CAPLW+4kBOWFPx3Hr-=UoLWvRxCorzBY9RCOiBhfkKcU0LAa21Q@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
	<20231201160925.3136868-15-peter.griffin@linaro.org>
	<CGME20231202004026epcas5p4d3947d7bb99e54f70ca37272cfdc5e55@epcas5p4.samsung.com>
	<CAPLW+4kBOWFPx3Hr-=UoLWvRxCorzBY9RCOiBhfkKcU0LAa21Q@mail.gmail.com>
Message-ID: <000001da24c0$0b83aab0$228b0010$@samsung.com>



> -----Original Message-----
> From: Sam Protsenko <semen.protsenko at linaro.org>
> Sent: Saturday, December 2, 2023 6:10 AM
> To: Peter Griffin <peter.griffin at linaro.org>
> Cc: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> will at kernel.org; arnd at arndb.de; olof at lixom.net;
> gregkh at linuxfoundation.org; jirislaby at kernel.org;
> cw00.choi at samsung.com; alim.akhtar at samsung.com;
> tudor.ambarus at linaro.org; andre.draszik at linaro.org;
> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> team at android.com; linux-serial at vger.kernel.org
> Subject: Re: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl
> configuration
> 
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org>
> wrote:
> >
> > Add support for the pin-controller found on the gs101 SoC used in
> > Pixel 6 phones.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 159 ++++++++++++++++++
> >  drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
> >  drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
> >  drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
> >  drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
> >  5 files changed, 198 insertions(+)
> >
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > index cb965cf93705..e1a0668ecb16 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > @@ -796,3 +796,162 @@ const struct samsung_pinctrl_of_match_data
> fsd_of_data __initconst = {
> >         .ctrl           = fsd_pin_ctrl,
> >         .num_ctrl       = ARRAY_SIZE(fsd_pin_ctrl),
> >  };
> > +
> > +/*
> > + * bank type for non-alive type
> > + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit
> > +field: 4)
> > + * (CONPDN bit field: 2, PUDPDN bit field: 4)  */ static struct
> > +samsung_pin_bank_type gs101_bank_type_off  = {
> > +       .fld_width = { 4, 1, 4, 4, 2, 4, },
> > +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, }, };
> 
> This is just the same as exynos850_bank_type_off (100% duplication).
> Here is what I suggest. Now that it's obvious there is some common platform
> for moder Exynos SoCs, and it's probably Exynos9, I'd suggest next course of
> action (if maintainers agree):
>   1. Remove this one
>   2. Rename exynos850_bank_type_off to exynos9_bank_type_off
>   3. Use it for both gs101 and exynos850
> 
> Does it make sense?
> 
My opinion is to reuse exynos850 for gs101 (wherever applicable), same philosophy was historically followed in this file.
That way (using exynos850 for gs101) things will be simple. 
Adding exynos9_* is not adding any benefit, rather it create confusion.

> > +
> > +/*
> > + * bank type for alive type
> > + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit
> > +field: 4)  */ static const struct samsung_pin_bank_type
> > +gs101_bank_type_alive = {
> > +       .fld_width = { 4, 1, 4, 4, },
> > +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, }, };
[...]




From hsinyi at chromium.org  Fri Dec  1 17:44:42 2023
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Fri, 1 Dec 2023 17:44:42 -0800
Subject: [PATCH v2 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <20231201070719.1229447-7-wenst@chromium.org>
References: <20231201070719.1229447-1-wenst@chromium.org> <20231201070719.1229447-7-wenst@chromium.org>
Message-ID: <CAJMQK-iPT6p1izqQCHmJD2+E_RmnDKQfxsgMetnKtwNgLUmx1A@mail.gmail.com>

On Fri, Dec 1, 2023 at 5:39?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> Krabby design.
>
> Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> convertible device with touchscreen and stylus.
>
> Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> device. It does not have a touchscreen or stylus.
>
> The two devices both have two variants. The difference is a second
> source touchpad controller that shares the same address as the original,
> but is incompatible.
>
> The extra SKU IDs for the Tentacruel devices map to different sensor
> components attached to the Embedded Controller. These are not visible
> to the main processor.
>
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> ---
> Changes since v1:
> - Reorder SKU numbers in descending order.
> - Fixed pinconfig node names
> - Moved pinctrl-* properties after interrupts-*
> - Switched to interrupts-extended for external components
> - Marked ADSP as explicitly disabled, with a comment explaining that it
>   stalls the system
> - Renamed "touchpad" to "trackpad"
> - Dropped bogus "no-laneswap" property from it6505 node
> - Moved "realtek,jd-src" property to after all the regulator supplies
> - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> - Renamed "vgpu" regulator name to allow coupling, with a comment
>   containing the name used in the design
> - Renamed "cr50" node name to "tpm"
> - Moved trackpad_pins reference up to i2c2; workaround for second source
>   component resource sharing.
> - Fix copyright year
> - Fixed touchscreen supply name
>
>  arch/arm64/boot/dts/mediatek/Makefile         |    4 +
>  .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
>  .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
>  .../mt8186-corsola-tentacool-sku327683.dts    |   26 +
>  .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
>  .../mt8186-corsola-tentacruel-sku262148.dts   |   28 +
>  .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
>  7 files changed, 2007 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index e6e7592a3645..442af61b1305 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile

<snip>

> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> new file mode 100644
> index 000000000000..2e4d8df978c1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2023 Google LLC
> + */
> +
> +#include "mt8186-corsola-tentacool-sku327681.dts"
> +
> +/ {
> +       compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
> +};
> +
> +/* This variant replaces only the touchpad controller. */
> +&i2c2 {
> +       /delete-node/ touchpad at 15;

corsola.dtsi has this node named trackpad at 15.

> +
> +       touchpad at 15 {
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&trackpad_pin>;
> +               compatible = "hid-over-i2c";
> +               reg = <0x15>;
> +               interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +               hid-descr-addr = <0x0001>;
> +               vdd-supply = <&pp3300_s3>;
> +               wakeup-source;
> +       };
> +};

<snip>

> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> new file mode 100644
> index 000000000000..7841046084dc
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2023 Google LLC
> + */
> +
> +#include "mt8186-corsola-tentacruel-sku262144.dts"
> +
> +/ {
> +       compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> +                    "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> +                    "google,tentacruel", "mediatek,mt8186";
> +};
> +
> +/* This variant replaces only the touchpad controller. */
> +&i2c2 {
> +       /delete-node/ touchpad at 15;
> +

ditto.

> +       touchpad at 15 {
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&trackpad_pin>;
> +               compatible = "hid-over-i2c";
> +               reg = <0x15>;
> +               interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +               hid-descr-addr = <0x0001>;
> +               vdd-supply = <&pp3300_s3>;
> +               wakeup-source;
> +       };
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> new file mode 100644
> index 000000000000..c5446b18783d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> @@ -0,0 +1,1719 @@

<snip>

> +
> +&i2c2 {
> +       pinctrl-names = "default";
> +       /*
> +        * Trackpad pin put here to work around second source components
> +        * sharing the pinmux
> +        */
> +       pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
> +       clock-frequency = <400000>;
> +       i2c-scl-internal-delay-ns = <10000>;
> +       status = "okay";
> +
> +       trackpad at 15 {
> +               compatible = "elan,ekth3000";
> +               reg = <0x15>;
> +               interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +               vcc-supply = <&pp3300_s3>;
> +               wakeup-source;
> +       };
> +};
> +

<snip>


From semen.protsenko at linaro.org  Fri Dec  1 17:54:18 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 19:54:18 -0600
Subject: [PATCH v5 18/20] arm64: dts: exynos: google: Add initial Google
 gs101 SoC support
In-Reply-To: <20231201160925.3136868-19-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-19-peter.griffin@linaro.org>
Message-ID: <CAPLW+4ki_GUAnor4sTanXFLzKrAB9JpxK98PED1fUY-MLCzUdA@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Google gs101 SoC is ARMv8 mobile SoC found in the Pixel 6,
> (oriole) Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
> phones. It features:
> * 4xA55 little cluster
> * 2xA76 Mid cluster
> * 2xX1 Big cluster
>
> This commit adds the basic device tree for gs101 (SoC).
> Further platform support will be added over time.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  .../boot/dts/exynos/google/gs101-pinctrl.dtsi | 1250 +++++++++++++++++
>  .../boot/dts/exynos/google/gs101-pinctrl.h    |   33 +
>  arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  476 +++++++
>  3 files changed, 1759 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
> new file mode 100644
> index 000000000000..8c0f0cf75edb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
> @@ -0,0 +1,1250 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * GS101 SoC pin-mux and pin-config device tree source
> + *
> + * Copyright 2019-2023 Google LLC
> + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> + */
> +
> +#include "gs101-pinctrl.h"
> +
> +&pinctrl_gpio_alive {
> +       gpa0: gpa0-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupt-parent = <&gic>;
> +               interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa1: gpa1-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupt-parent = <&gic>;
> +               interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa2: gpa2-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupt-parent = <&gic>;
> +               interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa3: gpa3-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupt-parent = <&gic>;
> +               interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa4: gpa4-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupt-parent = <&gic>;
> +               interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa5: gpa5-gpio-bank  {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa9: gpa9-gpio-bank  {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa10: gpa10-gpio-bank  {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       uart15_bus: uart15-bus-pins {
> +               samsung,pins = "gpa2-3", "gpa2-4";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       uart16_bus: uart16-bus-pins {
> +               samsung,pins = "gpa3-0", "gpa3-1", "gpa3-2", "gpa3-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       uart17_bus: uart17-bus-pins {
> +               samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2", "gpa4-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi15_bus: spi15-bus-pins {
> +               samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi15_cs: spi15-cs-pins {
> +               samsung,pins = "gpa4-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +};
> +
> +&pinctrl_far_alive {
> +       gpa6: gpa6-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupt-parent = <&gic>;
> +               interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa7: gpa7-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupt-parent = <&gic>;
> +               interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa8: gpa8-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupt-parent = <&gic>;
> +               interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +
> +       gpa11: gpa11-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +               interrupt-parent = <&gic>;
> +               interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH 0>,
> +                            <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH 0>;
> +       };
> +};
> +
> +&pinctrl_gsacore {
> +       gps0: gps0-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gps1: gps1-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gps2: gps2-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +};
> +
> +&pinctrl_gsactrl {
> +       gps3: gps3-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +};
> +
> +&pinctrl_hsi1 {
> +       gph0: gph0-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gph1: gph1-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       pcie0_clkreq: pcie0-clkreq-pins{
> +               samsung,pins = "gph0-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +               samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +               samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +               samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
> +       };
> +
> +       pcie0_perst: pcie0-perst-pins {
> +               samsung,pins = "gph0-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +               samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +       };
> +};
> +
> +&pinctrl_hsi2 {
> +       gph2: gph2-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gph3: gph3-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gph4: gph4-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       sd2_clk: sd2-clk-pins {
> +               samsung,pins = "gph4-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +       };
> +
> +       sd2_cmd: sd2-cmd-pins {
> +               samsung,pins = "gph4-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +               samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +       };
> +
> +       sd2_bus1: sd2-bus-width1-pins {
> +               samsung,pins = "gph4-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +               samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +       };
> +
> +       sd2_bus4: sd2-bus-width4-pins {
> +               samsung,pins = "gph4-3", "gph4-4", "gph4-5";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +               samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +       };
> +
> +       sd2_clk_fast_slew_rate_1x: sd2-clk-fast-slew-rate-1x-pins {
> +               samsung,pins = "gph4-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       sd2_clk_fast_slew_rate_2x: sd2-clk-fast-slew-rate-2x-pins {
> +               samsung,pins = "gph4-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sd2_clk_fast_slew_rate_3x: sd2-clk-fast-slew-rate-3x-pins {
> +               samsung,pins = "gph4-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
> +       };
> +
> +       sd2_clk_fast_slew_rate_4x: sd2-clk-fast-slew-rate-4x-pins {
> +               samsung,pins = "gph4-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +       };
> +
> +       ufs_rst_n: ufs-rst-n-pins {
> +               samsung,pins = "gph3-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +               samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       ufs_refclk_out: ufs-refclk-out-pins {
> +               samsung,pins = "gph3-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +               samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       pcie1_clkreq: pcie1-clkreq-pins {
> +               samsung,pins = "gph2-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_UP>;
> +               samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +               samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +               samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
> +       };
> +
> +       pcie1_perst: pcie1-perst-pins {
> +               samsung,pins = "gph2-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
> +               samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +       };
> +};
> +
> +&pinctrl_peric0 {
> +       gpp0: gpp0-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp1: gpp1-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp2: gpp2-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp3: gpp3-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp4: gpp4-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp5: gpp5-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp6: gpp6-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp7: gpp7-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp8: gpp8-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp9: gpp9-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp10: gpp10-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp11: gpp11-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp12: gpp12-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp13: gpp13-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp14: gpp14-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp15: gpp15-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp16: gpp16-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp17: gpp17-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp18: gpp18-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp19: gpp19-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       /* USI_PERIC0_UART_DBG */
> +       uart0_bus: uart0-bus-pins {
> +               samsung,pins = "gpp1-2", "gpp1-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       disp_te_pri_on: disp-te-pri-on-pins {
> +               samsung,pins = "gpp0-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +       };
> +
> +       disp_te_pri_off: disp-te-pri-off-pins {
> +               samsung,pins = "gpp0-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
> +       };
> +
> +       disp_te_sec_on: disp-te-sec-on-pins {
> +               samsung,pins = "gpp0-4";
> +               samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +       };
> +
> +       disp_te_sec_off: disp-te-sec-off-pins {
> +               samsung,pins = "gpp0-4";
> +               samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
> +       };
> +
> +       sensor_mclk1_out: sensor-mclk1-out-pins {
> +               samsung,pins = "gpp3-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk1_fn: sensor-mclk1-fn-pins {
> +               samsung,pins = "gpp3-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk2_out: sensor-mclk2-out-pins {
> +               samsung,pins = "gpp5-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk2_fn: sensor-mclk2-fn-pins {
> +               samsung,pins = "gpp5-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk3_out: sensor-mclk3-out-pins {
> +               samsung,pins = "gpp7-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk3_fn: sensor-mclk3-fn-pins {
> +               samsung,pins = "gpp7-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk4_out: sensor-mclk4-out-pins {
> +               samsung,pins = "gpp9-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk4_fn: sensor-mclk4-fn-pins {
> +               samsung,pins = "gpp9-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk5_out: sensor-mclk5-out-pins {
> +               samsung,pins = "gpp11-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk5_fn: sensor-mclk5-fn-pins {
> +               samsung,pins = "gpp11-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk6_out: sensor-mclk6-out-pins {
> +               samsung,pins = "gpp13-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk6_fn: sensor-mclk6-fn-pins {
> +               samsung,pins = "gpp13-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk7_out: sensor-mclk7-out-pins {
> +               samsung,pins = "gpp15-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk7_fn: sensor-mclk7-fn-pins {
> +               samsung,pins = "gpp15-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk8_out: sensor-mclk8-out-pins {
> +               samsung,pins = "gpp17-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       sensor_mclk8_fn: sensor-mclk8-fn-pins {
> +               samsung,pins = "gpp17-0";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
> +       };
> +
> +       hsi2c14_bus: hsi2c14-bus-pins {
> +               samsung,pins = "gpp18-0", "gpp18-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart14_bus_single: uart14-bus-pins {
> +               samsung,pins = "gpp18-0", "gpp18-1",
> +                              "gpp18-2", "gpp18-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi14_bus: spi14-bus-pins {
> +               samsung,pins = "gpp18-0", "gpp18-1", "gpp18-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi14_cs: spi14-cs-pins {
> +               samsung,pins = "gpp18-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi14_cs_func: spi14-cs-func-pins {
> +               samsung,pins = "gpp18-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c8_bus: hsi2c8-bus-pins {
> +               samsung,pins = "gpp16-0", "gpp16-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +               samsung,pin-pud-pdn = <GS101_PIN_PDN_OUT0>;
> +       };
> +
> +       uart8_bus_single: uart8-bus-pins {
> +               samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2",
> +                              "gpp16-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi8_bus: spi8-bus-pins {
> +               samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi8_cs: spi8-cs-pins {
> +               samsung,pins = "gpp16-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi8_cs_func: spi8-cs-func-pins {
> +               samsung,pins = "gpp16-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c7_bus: hsi2c7-bus-pins {
> +               samsung,pins = "gpp14-0", "gpp14-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart7_bus_single: uart7-bus-pins {
> +               samsung,pins = "gpp14-0", "gpp14-1",
> +                              "gpp14-2", "gpp14-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi7_bus: spi7-bus-pins {
> +               samsung,pins = "gpp14-0", "gpp14-1", "gpp14-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi7_cs: spi7-cs-pins {
> +               samsung,pins = "gpp14-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi7_cs_func: spi7-cs-func-pins {
> +               samsung,pins = "gpp14-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c6_bus: hsi2c6-bus-pins {
> +               samsung,pins = "gpp12-0", "gpp12-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart6_bus_single: uart6-bus-pins {
> +               samsung,pins = "gpp12-0", "gpp12-1",
> +                              "gpp12-2", "gpp12-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi6_bus: spi6-bus-pins {
> +               samsung,pins = "gpp12-0", "gpp12-1", "gpp12-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi6_cs: spi6-cs-pins {
> +               samsung,pins = "gpp12-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi6_cs_func: spi6-cs-func-pins {
> +               samsung,pins = "gpp12-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c5_bus: hsi2c5-bus-pins {
> +               samsung,pins = "gpp10-0", "gpp10-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart5_bus_single: uart5-bus-pins {
> +               samsung,pins = "gpp10-0", "gpp10-1",
> +                              "gpp10-2", "gpp10-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi5_bus: spi5-bus-pins {
> +               samsung,pins = "gpp10-0", "gpp10-1", "gpp10-2";
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +               samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi5_cs_func: spi5-cs-func-pins {
> +               samsung,pins = "gpp10-3";
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
> +               samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       hsi2c4_bus: hsi2c4-bus-pins {
> +               samsung,pins = "gpp8-0", "gpp8-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart4_bus_single: uart4-bus-pins {
> +               samsung,pins = "gpp8-0", "gpp8-1",
> +                              "gpp8-2", "gpp8-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi4_bus: spi4-bus-pins {
> +               samsung,pins = "gpp8-0", "gpp8-1", "gpp8-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi4_cs: spi4-cs-pins {
> +               samsung,pins = "gpp8-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi4_cs_func: spi4-cs-func-pins {
> +               samsung,pins = "gpp8-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c3_bus: hsi2c3-bus-pins {
> +               samsung,pins = "gpp6-0", "gpp6-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart3_bus_single: uart3-bus-pins {
> +               samsung,pins = "gpp6-0", "gpp6-1",
> +                              "gpp6-2", "gpp6-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi3_bus: spi3-bus-pins {
> +               samsung,pins = "gpp6-0", "gpp6-1", "gpp6-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi3_cs: spi3-cs-pins {
> +               samsung,pins = "gpp6-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi3_cs_func: spi3-cs-func-pins {
> +               samsung,pins = "gpp6-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c2_bus: hsi2c2-bus-pins {
> +               samsung,pins = "gpp4-0", "gpp4-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart2_bus_single: uart2-bus-pins {
> +               samsung,pins = "gpp4-0", "gpp4-1",
> +                              "gpp4-2", "gpp4-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi2_bus: spi2-bus-pins {
> +               samsung,pins = "gpp4-0", "gpp4-1", "gpp4-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi2_cs: spi2-cs-pins {
> +               samsung,pins = "gpp4-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi2_cs_func: spi2-cs-func-pins {
> +               samsung,pins = "gpp4-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c1_bus: hsi2c1-bus-pins {
> +               samsung,pins = "gpp2-0", "gpp2-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart1_bus_single: uart1-bus-pins {
> +               samsung,pins = "gpp2-0", "gpp2-1",
> +                              "gpp2-2", "gpp2-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi1_bus: spi1-bus-pins {
> +               samsung,pins = "gpp2-0", "gpp2-1", "gpp2-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi1_cs: spi1-cs-pins {
> +               samsung,pins = "gpp2-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi1_cs_func: spi1-cs-func-pins {
> +               samsung,pins = "gpp2-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +};
> +
> +&pinctrl_peric1 {
> +       gpp20: gpp20-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp21: gpp21-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp22: gpp22-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp23: gpp23-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp24: gpp24-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp25: gpp25-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp26: gpp26-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       gpp27: gpp27-gpio-bank {
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +               interrupt-controller;
> +               #interrupt-cells = <2>;
> +       };
> +
> +       hsi2c13_bus: hsi2c13-bus-pins  {
> +               samsung,pins = "gpp25-0", "gpp25-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart13_bus_single: uart13-bus-pins {
> +               samsung,pins = "gpp25-0", "gpp25-1",
> +                              "gpp25-2", "gpp25-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi13_bus: spi13-bus-pins {
> +               samsung,pins = "gpp25-0", "gpp25-1", "gpp25-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi13_cs: spi13-cs-pins {
> +               samsung,pins = "gpp25-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi13_cs_func: spi13-cs-func-pins {
> +               samsung,pins = "gpp25-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c12_bus: hsi2c12-bus-pins {
> +               samsung,pins = "gpp23-4", "gpp23-5";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart12_bus_single: uart12-bus-pins {
> +               samsung,pins = "gpp23-4", "gpp23-5",
> +                              "gpp23-6", "gpp23-7";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi12_bus: spi12-bus-pins {
> +               samsung,pins = "gpp23-4", "gpp23-5", "gpp23-6";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi14_cs2: spi14-cs2-pins {
> +               samsung,pins = "gpp23-6";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi12_cs: spi12-cs-pins {
> +               samsung,pins = "gpp23-7";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi12_cs_func: spi12-cs-func-pins {
> +               samsung,pins = "gpp23-7";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c11_bus: hsi2c11-bus-pins {
> +               samsung,pins = "gpp23-0", "gpp23-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart11_bus_single: uart11-bus-pins {
> +               samsung,pins = "gpp23-0", "gpp23-1",
> +                              "gpp23-2", "gpp23-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi11_bus: spi11-bus-pins {
> +               samsung,pins = "gpp23-0", "gpp23-1", "gpp23-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi11_cs: spi11-cs-pins {
> +               samsung,pins = "gpp23-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi11_cs_func: spi11-cs-func-pins {
> +               samsung,pins = "gpp23-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c10_bus: hsi2c10-bus-pins {
> +               samsung,pins = "gpp21-0", "gpp21-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart10_bus_single: uart10-bus-pins {
> +               samsung,pins = "gpp21-0", "gpp21-1",
> +                              "gpp21-2", "gpp21-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi10_bus: spi10-bus-pins {
> +               samsung,pins = "gpp21-0", "gpp21-1", "gpp21-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi10_cs: spi10-cs-pins {
> +               samsung,pins = "gpp21-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi10_cs_func: spi10-cs-func-pins {
> +               samsung,pins = "gpp21-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c9_bus: hsi2c9-bus-pins {
> +               samsung,pins = "gpp20-4", "gpp20-5";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart9_bus_single: uart9-bus-pins {
> +               samsung,pins = "gpp20-4", "gpp20-5",
> +                              "gpp20-6", "gpp20-7";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi9_bus: spi9-bus-pins {
> +               samsung,pins = "gpp20-4", "gpp20-5", "gpp20-6";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi9_cs: spi9-cs-pins {
> +               samsung,pins = "gpp20-7";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi9_cs_func: spi9-cs-func-pins {
> +               samsung,pins = "gpp20-7";
> +               samsung,pin-function = <GS101_PIN_FUNC_2>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       hsi2c0_bus: hsi2c0-bus-pins {
> +               samsung,pins = "gpp20-0", "gpp20-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       uart0_bus_single: uart0-bus-pins {
> +               samsung,pins = "gpp20-0", "gpp20-1",
> +                              "gpp20-2", "gpp20-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +       };
> +
> +       spi0_bus: spi0-bus-pins {
> +               samsung,pins = "gpp20-0", "gpp20-1", "gpp20-2";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi0_cs: spi0-cs-pins {
> +               samsung,pins = "gpp20-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       spi0_cs_func: spi0-cs-func-pins {
> +               samsung,pins = "gpp20-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +};
> +

Nitpick: this empty line is not needed.


> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> new file mode 100644
> index 000000000000..853505e45b60
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Pinctrl binding constants for GS101
> + *
> + * Copyright (c) 2020-2023 Google, LLC.
> + */
> +
> +#ifndef __DT_BINDINGS_PINCTRL_GS101_H__
> +#define __DT_BINDINGS_PINCTRL_GS101_H__
> +
> +#define GS101_PIN_PULL_NONE            0
> +#define GS101_PIN_PULL_DOWN            1
> +#define GS101_PIN_PULL_UP              3
> +
> +/* Pin function in power down mode */
> +#define GS101_PIN_PDN_OUT0             0
> +#define GS101_PIN_PDN_OUT1             1
> +#define GS101_PIN_PDN_INPUT            2
> +#define GS101_PIN_PDN_PREV             3
> +
> +/* GS101 drive strengths */
> +#define GS101_PIN_DRV_2_5_MA           0
> +#define GS101_PIN_DRV_5_MA             1
> +#define GS101_PIN_DRV_7_5_MA           2
> +#define GS101_PIN_DRV_10_MA            3
> +
> +#define GS101_PIN_FUNC_INPUT           0
> +#define GS101_PIN_FUNC_OUTPUT          1
> +#define GS101_PIN_FUNC_2               2
> +#define GS101_PIN_FUNC_3               3
> +#define GS101_PIN_FUNC_EINT            0xf
> +

Still feels fishy to me that it was decided to have this file instead
of re-using existing Exynos constants. For example, in Exynos850 I
used common constants and it was ok, but it's not ok for this SoC,
althought they look *identical* in a sense of pinctrl. And all those
constants already exist, also identical. So I wonder why something
like this shouldn't be done for Exynos850 as well. But ok.

> +#endif /* __DT_BINDINGS_PINCTRL_GS101_H__ */
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> new file mode 100644
> index 000000000000..40f6654a23f2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -0,0 +1,476 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * GS101 SoC
> + *
> + * Copyright 2019-2023 Google LLC
> + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> + */
> +
> +#include <dt-bindings/clock/google,gs101.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/soc/samsung,exynos-usi.h>
> +
> +/ {
> +       compatible = "google,gs101";
> +       #address-cells = <2>;
> +       #size-cells = <1>;
> +
> +       interrupt-parent = <&gic>;
> +
> +       aliases {
> +               pinctrl0 = &pinctrl_gpio_alive;
> +               pinctrl1 = &pinctrl_far_alive;
> +               pinctrl2 = &pinctrl_gsacore;
> +               pinctrl3 = &pinctrl_gsactrl;
> +               pinctrl4 = &pinctrl_peric0;
> +               pinctrl5 = &pinctrl_peric1;
> +               pinctrl6 = &pinctrl_hsi1;
> +               pinctrl7 = &pinctrl_hsi2;
> +               serial0 = &serial_0;

Please check commit f4324583cd4d ("arm64: dts: exynos: move aliases to
board in Exynos850"). At least for Exynos850 the serial alias was
moved to the board dts by Krzysztof.

> +       };
> +
> +       pmu-0 {
> +               compatible = "arm,cortex-a55-pmu";
> +               interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
> +       };
> +
> +       pmu-1 {
> +               compatible = "arm,cortex-a76-pmu";
> +               interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
> +       };
> +
> +       pmu-2 {
> +               compatible = "arm,cortex-x1-pmu";
> +               interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster2>;
> +       };
> +
> +       pmu-3 {
> +               compatible = "arm,dsu-pmu";
> +               interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH 0>;
> +               cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
> +                      <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
> +       };
> +
> +       /* TODO replace with CCF clock */
> +       dummy_clk: oscillator {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <12345>;
> +               clock-output-names = "pclk";
> +       };

Don't you already have real USI/UART clocks implemented in your clock driver?

> +
> +       cpus {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               cpu-map {
> +                       cluster0 {
> +                               core0 {
> +                                       cpu = <&cpu0>;
> +                               };
> +                               core1 {
> +                                       cpu = <&cpu1>;
> +                               };
> +                               core2 {
> +                                       cpu = <&cpu2>;
> +                               };
> +                               core3 {
> +                                       cpu = <&cpu3>;
> +                               };
> +                       };
> +
> +                       cluster1 {
> +                               core0 {
> +                                       cpu = <&cpu4>;
> +                               };
> +                               core1 {
> +                                       cpu = <&cpu5>;
> +                               };
> +                       };
> +
> +                       cluster2 {
> +                               core0 {
> +                                       cpu = <&cpu6>;
> +                               };
> +                               core1 {
> +                                       cpu = <&cpu7>;
> +                               };
> +                       };
> +               };
> +
> +               cpu0: cpu at 0 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a55";
> +                       reg = <0x0000>;
> +                       enable-method = "psci";
> +                       cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
> +                       capacity-dmips-mhz = <250>;
> +                       dynamic-power-coefficient = <70>;
> +               };
> +
> +               cpu1: cpu at 100 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a55";
> +                       reg = <0x0100>;
> +                       enable-method = "psci";
> +                       cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
> +                       capacity-dmips-mhz = <250>;
> +                       dynamic-power-coefficient = <70>;
> +               };
> +
> +               cpu2: cpu at 200 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a55";
> +                       reg = <0x0200>;
> +                       enable-method = "psci";
> +                       cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
> +                       capacity-dmips-mhz = <250>;
> +                       dynamic-power-coefficient = <70>;
> +               };
> +
> +               cpu3: cpu at 300 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a55";
> +                       reg = <0x0300>;
> +                       enable-method = "psci";
> +                       cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
> +                       capacity-dmips-mhz = <250>;
> +                       dynamic-power-coefficient = <70>;
> +               };
> +
> +               cpu4: cpu at 400 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a76";
> +                       reg = <0x0400>;
> +                       enable-method = "psci";
> +                       cpu-idle-states =  <&ENYO_CPU_SLEEP>;
> +                       capacity-dmips-mhz = <620>;
> +                       dynamic-power-coefficient = <284>;
> +               };
> +
> +               cpu5: cpu at 500 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-a76";
> +                       reg = <0x0500>;
> +                       enable-method = "psci";
> +                       cpu-idle-states =  <&ENYO_CPU_SLEEP>;
> +                       capacity-dmips-mhz = <620>;
> +                       dynamic-power-coefficient = <284>;
> +               };
> +
> +               cpu6: cpu at 600 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-x1";
> +                       reg = <0x0600>;
> +                       enable-method = "psci";
> +                       cpu-idle-states =  <&HERA_CPU_SLEEP>;
> +                       capacity-dmips-mhz = <1024>;
> +                       dynamic-power-coefficient = <650>;
> +               };
> +
> +               cpu7: cpu at 700 {
> +                       device_type = "cpu";
> +                       compatible = "arm,cortex-x1";
> +                       reg = <0x0700>;
> +                       enable-method = "psci";
> +                       cpu-idle-states =  <&HERA_CPU_SLEEP>;
> +                       capacity-dmips-mhz = <1024>;
> +                       dynamic-power-coefficient = <650>;
> +               };
> +
> +               idle-states {
> +                       entry-method = "psci";
> +
> +                       ANANKE_CPU_SLEEP: cpu-ananke-sleep {
> +                               idle-state-name = "c2";
> +                               compatible = "arm,idle-state";
> +                               arm,psci-suspend-param = <0x0010000>;
> +                               entry-latency-us = <70>;
> +                               exit-latency-us = <160>;
> +                               min-residency-us = <2000>;
> +                       };
> +
> +                       ENYO_CPU_SLEEP: cpu-enyo-sleep {
> +                               idle-state-name = "c2";
> +                               compatible = "arm,idle-state";
> +                               arm,psci-suspend-param = <0x0010000>;
> +                               entry-latency-us = <150>;
> +                               exit-latency-us = <190>;
> +                               min-residency-us = <2500>;
> +                       };
> +
> +                       HERA_CPU_SLEEP: cpu-hera-sleep {
> +                               idle-state-name = "c2";
> +                               compatible = "arm,idle-state";
> +                               arm,psci-suspend-param = <0x0010000>;
> +                               entry-latency-us = <235>;
> +                               exit-latency-us = <220>;
> +                               min-residency-us = <3500>;
> +                       };
> +               };
> +       };
> +
> +       /* ect node is required to be present by bootloader */
> +       ect {
> +       };
> +
> +       ext_24_5m: clock-1 {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-output-names = "oscclk";
> +       };
> +
> +       ext_200m: clock-2 {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-output-names = "ext-200m";
> +       };
> +
> +       psci {
> +               compatible = "arm,psci-1.0";
> +               method = "smc";
> +       };
> +
> +       reserved_memory: reserved-memory {
> +               #address-cells = <2>;
> +               #size-cells = <1>;
> +               ranges;
> +
> +               gsa_reserved_protected: gsa at 90200000 {
> +                       reg = <0x0 0x90200000 0x400000>;
> +                       no-map;
> +               };
> +
> +               tpu_fw_reserved: tpu-fw at 93000000 {
> +                       reg = <0x0 0x93000000 0x1000000>;
> +                       no-map;
> +               };
> +
> +               aoc_reserve: aoc at 94000000 {
> +                       reg = <0x0 0x94000000 0x03000000>;
> +                       no-map;
> +               };
> +
> +               abl_reserved: abl at f8800000 {
> +                       reg = <0x0 0xf8800000 0x02000000>;
> +                       no-map;
> +               };
> +
> +               dss_log_reserved: dss-log-reserved at fd3f0000 {
> +                       reg = <0x0 0xfd3f0000 0x0000e000>;
> +                       no-map;
> +               };
> +
> +               debug_kinfo_reserved: debug-kinfo-reserved at fd3fe000 {
> +                       reg = <0x0 0xfd3fe000 0x00001000>;
> +                       no-map;
> +               };
> +
> +               bldr_log_reserved: bldr-log-reserved at fd800000 {
> +                       reg = <0x0 0xfd800000 0x00100000>;
> +                       no-map;
> +               };
> +
> +               bldr_log_hist_reserved: bldr-log-hist-reserved at fd900000 {
> +                       reg = <0x0 0xfd900000 0x00002000>;
> +                       no-map;
> +               };
> +       };
> +
> +       timer {
> +               compatible = "arm,armv8-timer";
> +               interrupts =
> +                  <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> +                  <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> +                  <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> +                  <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>;
> +               clock-frequency = <24576000>;
> +       };
> +
> +       soc: soc at 0 {
> +               compatible = "simple-bus";
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges = <0x0 0x0 0x0 0x40000000>;
> +
> +               cmu_misc: clock-controller at 10010000 {
> +                       compatible = "google,gs101-cmu-misc";
> +                       reg = <0x10010000 0x8000>;
> +                       #clock-cells = <1>;
> +                       clocks =  <&ext_24_5m>, <&cmu_top CLK_DOUT_MISC_BUS>;
> +                       clock-names = "oscclk", "dout_cmu_misc_bus";
> +               };
> +
> +               watchdog_cl0: watchdog at 10060000 {
> +                       compatible = "google,gs101-wdt";
> +                       reg = <0x10060000 0x100>;
> +                       interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH 0>;
> +                       clocks =
> +                         <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0_IPCLKPORT_PCLK>,
> +                         <&ext_24_5m>;
> +                       clock-names = "watchdog", "watchdog_src";
> +                       samsung,syscon-phandle = <&pmu_system_controller>;
> +                       samsung,cluster-index = <0>;
> +                       status = "disabled";
> +               };

Krzysztof, can you please advice which scheme is preferred right now:
sorting by name or by address? I saw your patch for dts style doc, but
just want to know the current state of affairs.

> +
> +               watchdog_cl1: watchdog at 10070000 {
> +                       compatible = "google,gs101-wdt";
> +                       reg = <0x10070000 0x100>;
> +                       interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH 0>;
> +                       clocks =
> +                         <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1_IPCLKPORT_PCLK>,
> +                         <&ext_24_5m>;
> +                       clock-names = "watchdog", "watchdog_src";
> +                       samsung,syscon-phandle = <&pmu_system_controller>;
> +                       samsung,cluster-index = <1>;
> +                       status = "disabled";
> +               };
> +
> +               gic: interrupt-controller at 10400000 {
> +                       compatible = "arm,gic-v3";
> +                       #interrupt-cells = <4>;
> +                       interrupt-controller;
> +                       reg = <0x10400000 0x10000>, /* GICD */
> +                             <0x10440000 0x100000>;/* GICR * 8 */
> +                       interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
> +
> +                       ppi-partitions {
> +                               ppi_cluster0: interrupt-partition-0 {
> +                                       affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
> +                               };
> +
> +                               ppi_cluster1: interrupt-partition-1 {
> +                                       affinity = <&cpu4 &cpu5>;
> +                               };
> +
> +                               ppi_cluster2: interrupt-partition-2 {
> +                                       affinity = <&cpu6 &cpu7>;
> +                               };
> +                       };
> +               };
> +
> +               sysreg_peric0: syscon at 10820000 {
> +                       compatible = "google,gs101-peric0-sysreg", "syscon";
> +                       reg = <0x10820000 0x10000>;
> +               };
> +
> +               pinctrl_peric0: pinctrl at 10840000 {
> +                       compatible = "google,gs101-pinctrl";
> +                       reg = <0x10840000 0x00001000>;
> +                       interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> +               };
> +
> +               usi_uart: usi at 10a000c0 {
> +                       compatible = "google,gs101-usi",

I can't see this compatible in USI driver. Does it make sense to add it there?

> +                                    "samsung,exynos850-usi";
> +                       reg = <0x10a000c0 0x20>;
> +                       samsung,sysreg = <&sysreg_peric0 0x1020>;
> +                       samsung,mode = <USI_V2_UART>;
> +                       #address-cells = <1>;
> +                       #size-cells = <1>;
> +                       ranges;
> +                       clocks = <&dummy_clk>, <&dummy_clk>;

The same concern as above. I think I saw those clocks already
implemented in gs101 clock driver.

> +                       clock-names = "pclk", "ipclk";
> +                       status = "disabled";
> +
> +                       serial_0: serial at 10a00000 {
> +                               compatible = "google,gs101-uart";
> +                               reg = <0x10a00000 0xc0>;
> +                               reg-io-width = <4>;
> +                               samsung,uart-fifosize = <256>;
> +                               interrupts = <GIC_SPI 634
> +                                             IRQ_TYPE_LEVEL_HIGH 0>;
> +                               clocks = <&dummy_clk 0>, <&dummy_clk 0>;

Ditto.

> +                               clock-names = "uart", "clk_uart_baud0";
> +                               status = "disabled";
> +                       };
> +               };
> +
> +               pinctrl_peric1: pinctrl at 10c40000 {
> +                       compatible = "google,gs101-pinctrl";
> +                       reg = <0x10C40000 0x00001000>;
> +                       interrupts = <GIC_SPI 644 IRQ_TYPE_LEVEL_HIGH 0>;
> +               };
> +
> +               sysreg_peric1: syscon at 10c20000 {
> +                       compatible = "google,gs101-peric1-sysreg", "syscon";
> +                       reg = <0x10C20000 0x10000>;
> +               };
> +
> +               pinctrl_hsi1: pinctrl at 11840000 {
> +                       compatible = "google,gs101-pinctrl";
> +                       reg = <0x11840000 0x00001000>;
> +                       interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH 0>;
> +               };
> +
> +               pinctrl_hsi2: pinctrl at 14440000 {
> +                       compatible = "google,gs101-pinctrl";
> +                       reg = <0x14440000 0x00001000>;
> +                       interrupts = <GIC_SPI 503 IRQ_TYPE_LEVEL_HIGH 0>;
> +               };
> +
> +               cmu_apm: clock-controller at 17400000 {
> +                       compatible = "google,gs101-cmu-apm";
> +                       reg = <0x17400000 0x8000>;
> +                       #clock-cells = <1>;
> +
> +                       clocks = <&ext_24_5m>;
> +                       clock-names = "oscclk";

Doesn't CMU_APM take any clocks from CMU_TOP?

> +               };
> +
> +               sysreg_apm: syscon at 174204e0 {
> +                       compatible = "google,gs101-apm-sysreg", "syscon";
> +                       reg = <0x174204e0 0x1000>;
> +               };
> +
> +               pmu_system_controller: system-controller at 17460000 {
> +                       compatible = "google,gs101-pmu", "syscon";
> +                       reg = <0x17460000 0x10000>;
> +               };

Just a suggestion: it might be relatively simple to add syscon-reboot
node in pmu_system_controller, and it might just work. One more
feature for free! :)

> +
> +               pinctrl_gpio_alive: pinctrl at 174d0000 {
> +                       compatible = "google,gs101-pinctrl";
> +                       reg = <0x174d0000 0x00001000>;
> +
> +                       wakeup-interrupt-controller {
> +                               compatible = "google,gs101-wakeup-eint",
> +                                            "samsung,exynos850-wakeup-eint",
> +                                            "samsung,exynos7-wakeup-eint";
> +                       };
> +               };
> +
> +               pinctrl_far_alive: pinctrl at 174e0000 {
> +                       compatible = "google,gs101-pinctrl";
> +                       reg = <0x174e0000 0x00001000>;
> +
> +                       wakeup-interrupt-controller {
> +                               compatible = "google,gs101-wakeup-eint",
> +                                            "samsung,exynos850-wakeup-eint",
> +                                            "samsung,exynos7-wakeup-eint";
> +                       };
> +               };
> +
> +               pinctrl_gsactrl: pinctrl at 17940000 {
> +                       compatible = "google,gs101-pinctrl";
> +                       reg = <0x17940000 0x00001000>;
> +               };
> +
> +               pinctrl_gsacore: pinctrl at 17a80000 {
> +                       compatible = "google,gs101-pinctrl";
> +                       reg = <0x17a80000 0x00001000>;
> +               };
> +
> +               cmu_top: clock-controller at 1e080000 {
> +                       compatible = "google,gs101-cmu-top";
> +                       reg = <0x1e080000 0x8000>;
> +                       #clock-cells = <1>;
> +
> +                       clocks = <&ext_24_5m>;
> +                       clock-names = "oscclk";
> +               };
> +       };
> +};
> +
> +#include "gs101-pinctrl.dtsi"
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From semen.protsenko at linaro.org  Fri Dec  1 17:58:52 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 19:58:52 -0600
Subject: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <000001da24c0$0b83aab0$228b0010$@samsung.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-15-peter.griffin@linaro.org> <CGME20231202004026epcas5p4d3947d7bb99e54f70ca37272cfdc5e55@epcas5p4.samsung.com>
 <CAPLW+4kBOWFPx3Hr-=UoLWvRxCorzBY9RCOiBhfkKcU0LAa21Q@mail.gmail.com> <000001da24c0$0b83aab0$228b0010$@samsung.com>
Message-ID: <CAPLW+4mJ8yEwC8iJdhbiDC8sikAb1BMtGs_OLAAHczkE6U+J=w@mail.gmail.com>

On Fri, Dec 1, 2023 at 7:37?PM Alim Akhtar <alim.akhtar at samsung.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Sam Protsenko <semen.protsenko at linaro.org>
> > Sent: Saturday, December 2, 2023 6:10 AM
> > To: Peter Griffin <peter.griffin at linaro.org>
> > Cc: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> > mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> > tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> > wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> > will at kernel.org; arnd at arndb.de; olof at lixom.net;
> > gregkh at linuxfoundation.org; jirislaby at kernel.org;
> > cw00.choi at samsung.com; alim.akhtar at samsung.com;
> > tudor.ambarus at linaro.org; andre.draszik at linaro.org;
> > saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> > samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> > gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> > team at android.com; linux-serial at vger.kernel.org
> > Subject: Re: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl
> > configuration
> >
> > On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org>
> > wrote:
> > >
> > > Add support for the pin-controller found on the gs101 SoC used in
> > > Pixel 6 phones.
> > >
> > > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > > ---
> > >  .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 159 ++++++++++++++++++
> > >  drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
> > >  drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
> > >  drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
> > >  drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
> > >  5 files changed, 198 insertions(+)
> > >
> > > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > > b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > > index cb965cf93705..e1a0668ecb16 100644
> > > --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > > +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > > @@ -796,3 +796,162 @@ const struct samsung_pinctrl_of_match_data
> > fsd_of_data __initconst = {
> > >         .ctrl           = fsd_pin_ctrl,
> > >         .num_ctrl       = ARRAY_SIZE(fsd_pin_ctrl),
> > >  };
> > > +
> > > +/*
> > > + * bank type for non-alive type
> > > + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit
> > > +field: 4)
> > > + * (CONPDN bit field: 2, PUDPDN bit field: 4)  */ static struct
> > > +samsung_pin_bank_type gs101_bank_type_off  = {
> > > +       .fld_width = { 4, 1, 4, 4, 2, 4, },
> > > +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, }, };
> >
> > This is just the same as exynos850_bank_type_off (100% duplication).
> > Here is what I suggest. Now that it's obvious there is some common platform
> > for moder Exynos SoCs, and it's probably Exynos9, I'd suggest next course of
> > action (if maintainers agree):
> >   1. Remove this one
> >   2. Rename exynos850_bank_type_off to exynos9_bank_type_off
> >   3. Use it for both gs101 and exynos850
> >
> > Does it make sense?
> >
> My opinion is to reuse exynos850 for gs101 (wherever applicable), same philosophy was historically followed in this file.
> That way (using exynos850 for gs101) things will be simple.
> Adding exynos9_* is not adding any benefit, rather it create confusion.
>

Yes. But why not also rename exynos850_* to exynos9_*? I've a feeling
that a lot of modern Exynos SoCs have the same pin bank configuration.
Wouldn't it be better to use exynos9_ prefix for all such SoCs than
exynos850_*? Because Exynos9 is a family, but Exynos850 is a
particular SoC from that family.

> > > +
> > > +/*
> > > + * bank type for alive type
> > > + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit
> > > +field: 4)  */ static const struct samsung_pin_bank_type
> > > +gs101_bank_type_alive = {
> > > +       .fld_width = { 4, 1, 4, 4, },
> > > +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, }, };
> [...]
>
>


From Wenbin.Mei at mediatek.com  Fri Dec  1 18:04:59 2023
From: Wenbin.Mei at mediatek.com (=?utf-8?B?V2VuYmluIE1laSAo5qKF5paH5b2sKQ==?=)
Date: Sat, 2 Dec 2023 02:04:59 +0000
Subject: [PATCH v3] mmc: mtk-sd: Increase the verbosity of
 msdc_track_cmd_data
In-Reply-To: <20231201102747.3854573-1-treapking@chromium.org>
References: <20231201102747.3854573-1-treapking@chromium.org>
Message-ID: <00568ba8c40d034bfe6ba08f25b114f2b2955308.camel@mediatek.com>

On Fri, 2023-12-01 at 18:26 +0800, Pin-yen Lin wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  This log message is necessary for debugging, so enable it by default
> to
> debug issues that are hard to reproduce locally.
> 
> Signed-off-by: Pin-yen Lin <treapking at chromium.org>
> 
Reviewed-by: Wenbin Mei <wenbin.mei at mediatek.com>
> ---
> 
> Changes in v3:
> - Only print the warning when -ETIMEDOUT or not in tuning process
> 
> Changes in v2:
> - Use dev_warn() instead of dev_err()
> 
>  drivers/mmc/host/mtk-sd.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 97f7c3d4be6e..6ae5e0a9fca9 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -1149,9 +1149,11 @@ static void msdc_recheck_sdio_irq(struct
> msdc_host *host)
>  
>  static void msdc_track_cmd_data(struct msdc_host *host, struct
> mmc_command *cmd)
>  {
> -	if (host->error)
> -		dev_dbg(host->dev, "%s: cmd=%d arg=%08X; host-
> >error=0x%08X\n",
> -			__func__, cmd->opcode, cmd->arg, host->error);
> +	if (host->error &&
> +	    ((!mmc_op_tuning(cmd->opcode) && !host->hs400_tuning) ||
> +	     cmd->error == -ETIMEDOUT))
> +		dev_warn(host->dev, "%s: cmd=%d arg=%08X; host-
> >error=0x%08X\n",
> +			 __func__, cmd->opcode, cmd->arg, host->error);
>  }
>  
>  static void msdc_request_done(struct msdc_host *host, struct
> mmc_request *mrq)
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 

From festevam at gmail.com  Fri Dec  1 18:27:01 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 1 Dec 2023 23:27:01 -0300
Subject: [PATCH] media: nxp: isi: Check whether pad is non-NULL before access
In-Reply-To: <20231201150614.63300-1-marex@denx.de>
References: <20231201150614.63300-1-marex@denx.de>
Message-ID: <CAOMZO5BssVez71=uCYd0XhL02xd1TrUyTzCc1fq_sWfENLaoTA@mail.gmail.com>

On Fri, Dec 1, 2023 at 12:06?PM Marek Vasut <marex at denx.de> wrote:

>         pad = media_pad_remote_pad_first(&xbar->pads[sink_pad]);
> -       sd = media_entity_to_v4l2_subdev(pad->entity);
> +       if (!pad) {
> +               dev_dbg(xbar->isi->dev,

Maybe dev_err() here instead?

Anyway:

Reviewed-by: Fabio Estevam <festevam at gmail.com>


From semen.protsenko at linaro.org  Fri Dec  1 18:28:01 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 1 Dec 2023 20:28:01 -0600
Subject: [PATCH v5 19/20] arm64: dts: exynos: google: Add initial
 Oriole/pixel 6 board support
In-Reply-To: <20231201160925.3136868-20-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org> <20231201160925.3136868-20-peter.griffin@linaro.org>
Message-ID: <CAPLW+4mOmQM+Hy-kUKn9onU25-ycgj4CWfAK+-vZVH+yw=FhtQ@mail.gmail.com>

On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Add initial board support for the Pixel 6 phone code named Oriole. This
> has been tested with a minimal busybox initramfs and boots to a shell.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  arch/arm64/boot/dts/exynos/Makefile           |   2 +
>  arch/arm64/boot/dts/exynos/google/Makefile    |   4 +
>  .../boot/dts/exynos/google/gs101-oriole.dts   | 105 ++++++++++++++++++
>  3 files changed, 111 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>
> diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
> index 6e4ba69268e5..44c24a8ad9e1 100644
> --- a/arch/arm64/boot/dts/exynos/Makefile
> +++ b/arch/arm64/boot/dts/exynos/Makefile
> @@ -1,4 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
> +subdir-y += google
> +
>  dtb-$(CONFIG_ARCH_EXYNOS) += \
>         exynos5433-tm2.dtb              \
>         exynos5433-tm2e.dtb             \
> diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
> new file mode 100644
> index 000000000000..0a6d5e1fe4ee
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +dtb-$(CONFIG_ARCH_EXYNOS) += \
> +       gs101-oriole.dtb \
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> new file mode 100644
> index 000000000000..6abd00fa337e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Oriole Device Tree
> + *
> + * Copyright 2021-2023 Google,LLC

Space after comma. Maybe also make this line consistent for all added
files. Checking existing files, it's usually spelled "Copyright (C)
<years>, Google LLC."

Btw, I forgot to mention in my review for PATCH #18: please double
check the commit message, there are some issues with punctuation
there.

> + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "gs101-pinctrl.h"
> +#include "gs101.dtsi"
> +
> +/ {
> +       model = "Oriole";
> +       compatible = "google,gs101-oriole", "google,gs101";
> +
> +       aliases {
> +               serial0 = &serial_0;
> +       };
> +
> +       chosen {
> +               /* Bootloader expects bootargs specified otherwise it crashes */

Just wanted to say: I think you are doing a great job with this
platform, and I can only imagine how hard it can be when you can't
actually tinker with the bootloader source code. But I do appreciate
that you was able to minimize stuff like earlycon, ect, etc :) And
this one actually LGTM.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

> +               bootargs = "";
> +               stdout-path = &serial_0;
> +       };
> +
> +       gpio-keys {
> +               compatible = "gpio-keys";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&key_voldown>, <&key_volup>, <&key_power>;
> +
> +               button-vol-down {
> +                       label = "KEY_VOLUMEDOWN";
> +                       linux,code = <KEY_VOLUMEDOWN>;
> +                       gpios = <&gpa7 3 GPIO_ACTIVE_LOW>;
> +                       wakeup-source;
> +               };
> +
> +               button-vol-up {
> +                       label = "KEY_VOLUMEUP";
> +                       linux,code = <KEY_VOLUMEUP>;
> +                       gpios = <&gpa8 1 GPIO_ACTIVE_LOW>;
> +                       wakeup-source;
> +               };
> +
> +               button-power {
> +                       label = "KEY_POWER";
> +                       linux,code = <KEY_POWER>;
> +                       gpios = <&gpa10 1 GPIO_ACTIVE_LOW>;
> +                       wakeup-source;
> +               };
> +       };
> +};
> +
> +&ext_24_5m {
> +       clock-frequency = <24576000>;
> +};
> +
> +&ext_200m {
> +       clock-frequency = <200000000>;
> +};
> +
> +&pinctrl_far_alive {
> +       key_voldown: key-voldown-pins {
> +               samsung,pins = "gpa7-3";
> +               samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +
> +       key_volup: key-volup-pins {
> +               samsung,pins = "gpa8-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +};
> +
> +&pinctrl_gpio_alive {
> +       key_power: key-power-pins {
> +               samsung,pins = "gpa10-1";
> +               samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +       };
> +};
> +
> +&serial_0 {
> +       status = "okay";
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&uart0_bus>;
> +};
> +
> +&usi_uart {
> +       status = "okay";
> +       samsung,clkreq-on; /* needed for UART mode */
> +};
> +
> +&watchdog_cl0 {
> +       timeout-sec = <30>;
> +       status = "okay";
> +};
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From kuba at kernel.org  Fri Dec  1 19:28:46 2023
From: kuba at kernel.org (Jakub Kicinski)
Date: Fri, 1 Dec 2023 19:28:46 -0800
Subject: [PATCH bpf-next 1/3] xsk: add launch time support to XDP Tx
 metadata
In-Reply-To: <20231130162028.852006-2-yoong.siang.song@intel.com>
References: <20231130162028.852006-1-yoong.siang.song@intel.com>
	<20231130162028.852006-2-yoong.siang.song@intel.com>
Message-ID: <20231201192846.15c9e64e@kernel.org>

On Fri,  1 Dec 2023 00:20:26 +0800 Song Yoong Siang wrote:
> +        name: launch-time
> +        doc:
> +          HW Time-Based Scheduling (TBS) is supported by the driver.

Does this mean fifo "gating" or HW can do reordering?


From sjg at chromium.org  Fri Dec  1 19:54:40 2023
From: sjg at chromium.org (Simon Glass)
Date: Fri,  1 Dec 2023 20:54:40 -0700
Subject: [PATCH v9 0/2] arm64: Add a build target for Flat Image Tree
Message-ID: <20231202035511.487946-1-sjg@chromium.org>

Flat Image Tree (FIT) is a widely used file format for packaging a
kernel and associated devicetree files[1]. It is not specific to any
one bootloader, as it is supported by U-Boot, coreboot, Linuxboot,
Tianocore and Barebox.

This series adds support for building a FIT as part of the kernel
build. This makes it easy to try out the kernel - just load the FIT
onto your tftp server and it will run automatically on any supported
arm64 board.

The script is written in Python, since it is easy to build a FIT using
the Python libfdt bindings. For now, no attempt is made to compress
files in parallel, so building the 900-odd files takes a while, about
6 seconds with my testing.

The series also includes a few minor clean-up patches.

[1] https://github.com/open-source-firmware/flat-image-tree

Changes in v9:
- Move the compression control into Makefile.lib

Changes in v8:
- Drop compatible string in FDT node
- Correct sorting of MAINTAINERS to before ARM64 PORT
- Turn compress part of the make_fit.py comment in to a sentence
- Add two blank lines before parse_args() and setup_fit()
- Use 'image.fit: dtbs' instead of BUILD_DTBS var
- Use '$(<D)/dts' instead of '$(dir $<)dts'
- Add 'mkimage' details Documentation/process/changes.rst
- Allow changing the compression used
- Tweak cover letter since there is only one clean-up patch

Changes in v7:
- Drop the kbuild tag
- Add Image as a dependency of image.fit
- Drop kbuild tag
- Add dependency on dtbs
- Drop unnecessary path separator for dtbs
- Rebase to -next

Changes in v6:
- Drop the unwanted .gz suffix

Changes in v5:
- Drop patch previously applied
- Correct compression rule which was broken in v4

Changes in v4:
- Use single quotes for UIMAGE_NAME

Changes in v3:
- Drop temporary file image.itk
- Drop patch 'Use double quotes for image name'
- Drop double quotes in use of UIMAGE_NAME
- Drop unnecessary CONFIG_EFI_ZBOOT condition for help
- Avoid hard-coding "arm64" for the DT architecture

Changes in v2:
- Drop patch previously applied
- Add .gitignore file
- Move fit rule to Makefile.lib using an intermediate file
- Drop dependency on CONFIG_EFI_ZBOOT
- Pick up .dtb files separately from the kernel
- Correct pylint too-many-args warning for write_kernel()
- Include the kernel image in the file count
- Add a pointer to the FIT spec and mention of its wide industry usage
- Mention the kernel version in the FIT description

Simon Glass (2):
  arm64: Add BOOT_TARGETS variable
  arm64: boot: Support Flat Image Tree

 Documentation/process/changes.rst |   9 +
 MAINTAINERS                       |   7 +
 arch/arm64/Makefile               |  11 +-
 arch/arm64/boot/.gitignore        |   1 +
 arch/arm64/boot/Makefile          |   6 +-
 scripts/Makefile.lib              |  16 ++
 scripts/make_fit.py               | 291 ++++++++++++++++++++++++++++++
 7 files changed, 338 insertions(+), 3 deletions(-)
 create mode 100755 scripts/make_fit.py

-- 
2.43.0.rc2.451.g8631bc7472-goog



From sjg at chromium.org  Fri Dec  1 19:54:41 2023
From: sjg at chromium.org (Simon Glass)
Date: Fri,  1 Dec 2023 20:54:41 -0700
Subject: [PATCH v9 1/2] arm64: Add BOOT_TARGETS variable
In-Reply-To: <20231202035511.487946-1-sjg@chromium.org>
References: <20231202035511.487946-1-sjg@chromium.org>
Message-ID: <20231202035511.487946-2-sjg@chromium.org>

Add a new variable containing a list of possible targets. Mark them as
phony. This matches the approach taken for arch/arm

Signed-off-by: Simon Glass <sjg at chromium.org>
---

(no changes since v7)

Changes in v7:
- Drop the kbuild tag

Changes in v6:
- Drop the unwanted .gz suffix

 arch/arm64/Makefile | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 9a2d3723cd0f..1bd4fae6e806 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -150,6 +150,10 @@ libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
 # Default target when executing plain make
 boot		:= arch/arm64/boot
 
+BOOT_TARGETS	:= Image vmlinuz.efi
+
+PHONY += $(BOOT_TARGETS)
+
 ifeq ($(CONFIG_EFI_ZBOOT),)
 KBUILD_IMAGE	:= $(boot)/Image.gz
 else
@@ -159,7 +163,7 @@ endif
 all:	$(notdir $(KBUILD_IMAGE))
 
 vmlinuz.efi: Image
-Image vmlinuz.efi: vmlinux
+$(BOOT_TARGETS): vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
 Image.%: Image
-- 
2.43.0.rc2.451.g8631bc7472-goog



From sjg at chromium.org  Fri Dec  1 19:54:42 2023
From: sjg at chromium.org (Simon Glass)
Date: Fri,  1 Dec 2023 20:54:42 -0700
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231202035511.487946-1-sjg@chromium.org>
References: <20231202035511.487946-1-sjg@chromium.org>
Message-ID: <20231202035511.487946-3-sjg@chromium.org>

Add a script which produces a Flat Image Tree (FIT), a single file
containing the built kernel and associated devicetree files.
Compression defaults to gzip which gives a good balance of size and
performance.

The files compress from about 86MB to 24MB using this approach.

The FIT can be used by bootloaders which support it, such as U-Boot
and Linuxboot. It permits automatic selection of the correct
devicetree, matching the compatible string of the running board with
the closest compatible string in the FIT. There is no need for
filenames or other workarounds.

Add a 'make image.fit' build target for arm64, as well. Use
FIT_COMPRESSION to select a different algorithm.

The FIT can be examined using 'dumpimage -l'.

This features requires pylibfdt (use 'pip install libfdt'). It also
requires compression utilities for the algorithm being used. Supported
compression options are the same as the Image.xxx files. For now there
is no way to change the compression other than by editing the rule for
$(obj)/image.fit

While FIT supports a ramdisk / initrd, no attempt is made to support
this here, since it must be built separately from the Linux build.

Signed-off-by: Simon Glass <sjg at chromium.org>
---

Changes in v9:
- Move the compression control into Makefile.lib

Changes in v8:
- Drop compatible string in FDT node
- Correct sorting of MAINTAINERS to before ARM64 PORT
- Turn compress part of the make_fit.py comment in to a sentence
- Add two blank lines before parse_args() and setup_fit()
- Use 'image.fit: dtbs' instead of BUILD_DTBS var
- Use '$(<D)/dts' instead of '$(dir $<)dts'
- Add 'mkimage' details Documentation/process/changes.rst
- Allow changing the compression used
- Tweak cover letter since there is only one clean-up patch

Changes in v7:
- Add Image as a dependency of image.fit
- Drop kbuild tag
- Add dependency on dtbs
- Drop unnecessary path separator for dtbs
- Rebase to -next

Changes in v5:
- Drop patch previously applied
- Correct compression rule which was broken in v4

Changes in v4:
- Use single quotes for UIMAGE_NAME

Changes in v3:
- Drop temporary file image.itk
- Drop patch 'Use double quotes for image name'
- Drop double quotes in use of UIMAGE_NAME
- Drop unnecessary CONFIG_EFI_ZBOOT condition for help
- Avoid hard-coding "arm64" for the DT architecture

Changes in v2:
- Drop patch previously applied
- Add .gitignore file
- Move fit rule to Makefile.lib using an intermediate file
- Drop dependency on CONFIG_EFI_ZBOOT
- Pick up .dtb files separately from the kernel
- Correct pylint too-many-args warning for write_kernel()
- Include the kernel image in the file count
- Add a pointer to the FIT spec and mention of its wide industry usage
- Mention the kernel version in the FIT description

 Documentation/process/changes.rst |   9 +
 MAINTAINERS                       |   7 +
 arch/arm64/Makefile               |   7 +-
 arch/arm64/boot/.gitignore        |   1 +
 arch/arm64/boot/Makefile          |   6 +-
 scripts/Makefile.lib              |  16 ++
 scripts/make_fit.py               | 291 ++++++++++++++++++++++++++++++
 7 files changed, 334 insertions(+), 3 deletions(-)
 create mode 100755 scripts/make_fit.py

diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index bb96ca0f774b..cad51bd5bd62 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -62,6 +62,7 @@ Sphinx\ [#f1]_         1.7              sphinx-build --version
 cpio                   any              cpio --version
 GNU tar                1.28             tar --version
 gtags (optional)       6.6.5            gtags --version
+mkimage (optional)     2017.01          mkimage --version
 ====================== ===============  ========================================
 
 .. [#f1] Sphinx is needed only to build the Kernel documentation
@@ -189,6 +190,14 @@ The kernel build requires GNU GLOBAL version 6.6.5 or later to generate
 tag files through ``make gtags``.  This is due to its use of the gtags
 ``-C (--directory)`` flag.
 
+mkimage
+-------
+
+This tool is used when building a Flat Image Tree (FIT), commonly used on ARM
+platforms. The tool is available via the ``u-boot-tools`` package or can be
+built from the U-Boot source code. See the instructions at
+https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
+
 System utilities
 ****************
 
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d46229fe21b..d2d17f0d6e64 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3037,6 +3037,13 @@ F:	drivers/mmc/host/sdhci-of-arasan.c
 N:	zynq
 N:	xilinx
 
+ARM64 FIT SUPPORT
+M:	Simon Glass <sjg at chromium.org>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	arch/arm64/boot/Makefile
+F:	scripts/make_fit.py
+
 ARM64 PORT (AARCH64 ARCHITECTURE)
 M:	Catalin Marinas <catalin.marinas at arm.com>
 M:	Will Deacon <will at kernel.org>
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 1bd4fae6e806..6b893dc454b7 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -150,7 +150,7 @@ libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
 # Default target when executing plain make
 boot		:= arch/arm64/boot
 
-BOOT_TARGETS	:= Image vmlinuz.efi
+BOOT_TARGETS	:= Image vmlinuz.efi image.fit
 
 PHONY += $(BOOT_TARGETS)
 
@@ -162,7 +162,9 @@ endif
 
 all:	$(notdir $(KBUILD_IMAGE))
 
-vmlinuz.efi: Image
+image.fit: dtbs
+
+vmlinuz.efi image.fit: Image
 $(BOOT_TARGETS): vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
@@ -215,6 +217,7 @@ virtconfig:
 define archhelp
   echo  '* Image.gz      - Compressed kernel image (arch/$(ARCH)/boot/Image.gz)'
   echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
+  echo  '  image.fit     - Flat Image Tree (arch/$(ARCH)/boot/image.fit)'
   echo  '  install       - Install uncompressed kernel'
   echo  '  zinstall      - Install compressed kernel'
   echo  '                  Install using (your) ~/bin/installkernel or'
diff --git a/arch/arm64/boot/.gitignore b/arch/arm64/boot/.gitignore
index af5dc61f8b43..abaae9de1bdd 100644
--- a/arch/arm64/boot/.gitignore
+++ b/arch/arm64/boot/.gitignore
@@ -2,3 +2,4 @@
 Image
 Image.gz
 vmlinuz*
+image.fit
diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
index 1761f5972443..b835c0880d1c 100644
--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
@@ -16,7 +16,8 @@
 
 OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
 
-targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo Image.zst
+targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo \
+	Image.zst image.fit
 
 $(obj)/Image: vmlinux FORCE
 	$(call if_changed,objcopy)
@@ -39,6 +40,9 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
 $(obj)/Image.zst: $(obj)/Image FORCE
 	$(call if_changed,zstd)
 
+$(obj)/image.fit: $(obj)/Image FORCE
+	$(call cmd,fit)
+
 EFI_ZBOOT_PAYLOAD	:= Image
 EFI_ZBOOT_BFD_TARGET	:= elf64-littleaarch64
 EFI_ZBOOT_MACH_TYPE	:= ARM64
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 1a965fe68e01..1c60d594932c 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -496,6 +496,22 @@ quiet_cmd_uimage = UIMAGE  $@
 			-a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \
 			-n '$(UIMAGE_NAME)' -d $< $@
 
+# Flat Image Tree (FIT)
+# This allows for packaging of a kernel and all devicetrees files, using
+# compression.
+# ---------------------------------------------------------------------------
+
+MAKE_FIT := $(srctree)/scripts/make_fit.py
+
+# Use this to override the compression algorithm
+FIT_COMPRESSION ?= gzip
+
+quiet_cmd_fit = FIT     $@
+      cmd_fit = $(MAKE_FIT) -f $@ --arch $(UIMAGE_ARCH) --os linux \
+			--name '$(UIMAGE_NAME)' \
+			--compress $(FIT_COMPRESSION) -k $< \
+			$(<D)/dts
+
 # XZ
 # ---------------------------------------------------------------------------
 # Use xzkern to compress the kernel image and xzmisc to compress other things.
diff --git a/scripts/make_fit.py b/scripts/make_fit.py
new file mode 100755
index 000000000000..e616b0d7a84a
--- /dev/null
+++ b/scripts/make_fit.py
@@ -0,0 +1,291 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright 2023 Google LLC
+# Written by Simon Glass <sjg at chromium.org>
+#
+
+"""Build a FIT containing a lot of devicetree files
+
+Usage:
+    make_fit.py -A arm64 -n 'Linux-6.6' -O linux
+        -f arch/arm64/boot/image.fit -k /tmp/kern/arch/arm64/boot/image.itk
+        /tmp/kern/arch/arm64/boot/dts/ -E -c gzip
+
+Creates a FIT containing the supplied kernel and a directory containing the
+devicetree files.
+
+Use -E to generate an external FIT (where the data is placed after the
+FIT data structure). This allows parsing of the data without loading
+the entire FIT.
+
+Use -c to compress the data, using bzip2, gzip, lz4, lzma, lzo and
+zstd algorithms.
+
+The resulting FIT can be booted by bootloaders which support FIT, such
+as U-Boot, Linuxboot, Tianocore, etc.
+
+Note that this tool does not yet support adding a ramdisk / initrd.
+"""
+
+import argparse
+import collections
+import os
+import subprocess
+import sys
+import tempfile
+import time
+
+import libfdt
+
+
+# Tool extension and the name of the command-line tools
+CompTool = collections.namedtuple('CompTool', 'ext,tools')
+
+COMP_TOOLS = {
+    'bzip2': CompTool('.bz2', 'bzip2'),
+    'gzip': CompTool('.gz', 'pigz,gzip'),
+    'lz4': CompTool('.lz4', 'lz4'),
+    'lzma': CompTool('.lzma', 'lzma'),
+    'lzo': CompTool('.lzo', 'lzop'),
+    'zstd': CompTool('.zstd', 'zstd'),
+}
+
+
+def parse_args():
+    """Parse the program ArgumentParser
+
+    Returns:
+        Namespace object containing the arguments
+    """
+    epilog = 'Build a FIT from a directory tree containing .dtb files'
+    parser = argparse.ArgumentParser(epilog=epilog)
+    parser.add_argument('-A', '--arch', type=str, required=True,
+          help='Specifies the architecture')
+    parser.add_argument('-c', '--compress', type=str, default='none',
+          help='Specifies the compression')
+    parser.add_argument('-E', '--external', action='store_true',
+          help='Convert the FIT to use external data')
+    parser.add_argument('-n', '--name', type=str, required=True,
+          help='Specifies the name')
+    parser.add_argument('-O', '--os', type=str, required=True,
+          help='Specifies the operating system')
+    parser.add_argument('-f', '--fit', type=str, required=True,
+          help='Specifies the output file (.fit)')
+    parser.add_argument('-k', '--kernel', type=str, required=True,
+          help='Specifies the (uncompressed) kernel input file (.itk)')
+    parser.add_argument('srcdir', type=str, nargs='*',
+          help='Specifies the directory tree that contains .dtb files')
+
+    return parser.parse_args()
+
+
+def setup_fit(fsw, name):
+    """Make a start on writing the FIT
+
+    Outputs the root properties and the 'images' node
+
+    Args:
+        fsw (libfdt.FdtSw): Object to use for writing
+        name (str): Name of kernel image
+    """
+    fsw.INC_SIZE = 65536
+    fsw.finish_reservemap()
+    fsw.begin_node('')
+    fsw.property_string('description', f'{name} with devicetree set')
+    fsw.property_u32('#address-cells', 1)
+
+    fsw.property_u32('timestamp', int(time.time()))
+    fsw.begin_node('images')
+
+
+def write_kernel(fsw, data, args):
+    """Write out the kernel image
+
+    Writes a kernel node along with the required properties
+
+    Args:
+        fsw (libfdt.FdtSw): Object to use for writing
+        data (bytes): Data to write (possibly compressed)
+        args (Namespace): Contains necessary strings:
+            arch: FIT architecture, e.g. 'arm64'
+            fit_os: Operating Systems, e.g. 'linux'
+            name: Name of OS, e.g. 'Linux-6.6.0-rc7'
+            compress: Compression algorithm to use, e.g. 'gzip'
+    """
+    with fsw.add_node('kernel'):
+        fsw.property_string('description', args.name)
+        fsw.property_string('type', 'kernel_noload')
+        fsw.property_string('arch', args.arch)
+        fsw.property_string('os', args.os)
+        fsw.property_string('compression', args.compress)
+        fsw.property('data', data)
+        fsw.property_u32('load', 0)
+        fsw.property_u32('entry', 0)
+
+
+def finish_fit(fsw, entries):
+    """Finish the FIT ready for use
+
+    Writes the /configurations node and subnodes
+
+    Args:
+        fsw (libfdt.FdtSw): Object to use for writing
+        entries (list of tuple): List of configurations:
+            str: Description of model
+            str: Compatible stringlist
+    """
+    fsw.end_node()
+    seq = 0
+    with fsw.add_node('configurations'):
+        for model, compat in entries:
+            seq += 1
+            with fsw.add_node(f'conf-{seq}'):
+                fsw.property('compatible', bytes(compat))
+                fsw.property_string('description', model)
+                fsw.property_string('fdt', f'fdt-{seq}')
+                fsw.property_string('kernel', 'kernel')
+    fsw.end_node()
+
+
+def compress_data(inf, compress):
+    """Compress data using a selected algorithm
+
+    Args:
+        inf (IOBase): Filename containing the data to compress
+        compress (str): Compression algorithm, e.g. 'gzip'
+
+    Return:
+        bytes: Compressed data
+    """
+    if compress == 'none':
+        return inf.read()
+
+    comp = COMP_TOOLS.get(compress)
+    if not comp:
+        raise ValueError(f"Unknown compression algorithm '{compress}'")
+
+    with tempfile.NamedTemporaryFile() as comp_fname:
+        with open(comp_fname.name, 'wb') as outf:
+            done = False
+            for tool in comp.tools.split(','):
+                try:
+                    subprocess.call([tool, '-c'], stdin=inf, stdout=outf)
+                    done = True
+                    break
+                except FileNotFoundError:
+                    pass
+            if not done:
+                raise ValueError(f'Missing tool(s): {comp.tools}\n')
+            with open(comp_fname.name, 'rb') as compf:
+                comp_data = compf.read()
+    return comp_data
+
+
+def output_dtb(fsw, seq, fname, arch, compress):
+    """Write out a single devicetree to the FIT
+
+    Args:
+        fsw (libfdt.FdtSw): Object to use for writing
+        seq (int): Sequence number (1 for first)
+        fmame (str): Filename containing the DTB
+        arch: FIT architecture, e.g. 'arm64'
+        compress (str): Compressed algorithm, e.g. 'gzip'
+
+    Returns:
+        tuple:
+            str: Model name
+            bytes: Compatible stringlist
+    """
+    with fsw.add_node(f'fdt-{seq}'):
+        # Get the compatible / model information
+        with open(fname, 'rb') as inf:
+            data = inf.read()
+        fdt = libfdt.FdtRo(data)
+        model = fdt.getprop(0, 'model').as_str()
+        compat = fdt.getprop(0, 'compatible')
+
+        fsw.property_string('description', model)
+        fsw.property_string('type', 'flat_dt')
+        fsw.property_string('arch', arch)
+        fsw.property_string('compression', compress)
+        fsw.property('compatible', bytes(compat))
+
+        with open(fname, 'rb') as inf:
+            compressed = compress_data(inf, compress)
+        fsw.property('data', compressed)
+    return model, compat
+
+
+def build_fit(args):
+    """Build the FIT from the provided files and arguments
+
+    Args:
+        args (Namespace): Program arguments
+
+    Returns:
+        tuple:
+            bytes: FIT data
+            int: Number of configurations generated
+            size: Total uncompressed size of data
+    """
+    fsw = libfdt.FdtSw()
+    setup_fit(fsw, args.name)
+    seq = 0
+    size = 0
+    entries = []
+
+    # Handle the kernel
+    with open(args.kernel, 'rb') as inf:
+        comp_data = compress_data(inf, args.compress)
+    size += os.path.getsize(args.kernel)
+    write_kernel(fsw, comp_data, args)
+
+    for path in args.srcdir:
+        # Handle devicetree files
+        if os.path.isdir(path):
+            for dirpath, _, fnames in os.walk(path):
+                for fname in fnames:
+                    if os.path.splitext(fname)[1] != '.dtb':
+                        continue
+                    pathname = os.path.join(dirpath, fname)
+                    seq += 1
+                    size += os.path.getsize(pathname)
+                    model, compat = output_dtb(fsw, seq, pathname,
+                                               args.arch, args.compress)
+                    entries.append([model, compat])
+
+    finish_fit(fsw, entries)
+
+    # Include the kernel itself in the returned file count
+    return fsw.as_fdt().as_bytearray(), seq + 1, size
+
+
+def run_make_fit():
+    """Run the tool's main logic"""
+    args = parse_args()
+
+    out_data, count, size = build_fit(args)
+    with open(args.fit, 'wb') as outf:
+        outf.write(out_data)
+
+    ext_fit_size = None
+    if args.external:
+        mkimage = os.environ.get('MKIMAGE', 'mkimage')
+        subprocess.check_call([mkimage, '-E', '-F', args.fit],
+                              stdout=subprocess.DEVNULL)
+
+        with open(args.fit, 'rb') as inf:
+            data = inf.read()
+        ext_fit = libfdt.FdtRo(data)
+        ext_fit_size = ext_fit.totalsize()
+
+    comp_size = len(out_data)
+    print(f'FIT size {comp_size:#x}/{comp_size / 1024 / 1024:.1f} MB', end='')
+    if ext_fit_size:
+        print(f', header {ext_fit_size:#x}/{ext_fit_size / 1024:.1f} KB', end='')
+    print(f', {count} files, uncompressed {size / 1024 / 1024:.1f} MB')
+
+
+if __name__ == "__main__":
+    sys.exit(run_make_fit())
-- 
2.43.0.rc2.451.g8631bc7472-goog



From kuba at kernel.org  Fri Dec  1 20:11:46 2023
From: kuba at kernel.org (Jakub Kicinski)
Date: Fri, 1 Dec 2023 20:11:46 -0800
Subject: [PATCH] [net/ethernet] arc_emac: Add error handling in
 emac_rockchip_probe
In-Reply-To: <20231130031318.35850-1-liuhaoran14@163.com>
References: <20231130031318.35850-1-liuhaoran14@163.com>
Message-ID: <20231201201146.12aa16df@kernel.org>

On Wed, 29 Nov 2023 19:13:18 -0800 Haoran Liu wrote:
> Although the error addressed by this patch may not occur in the current
> environment, I still suggest implementing these error handling routines
> if the function is not highly time-sensitive. As the environment evolves
> or the code gets reused in different contexts, there's a possibility that
> these errors might occur. Addressing them now can prevent potential
> debugging efforts in the future, which could be quite resource-intensive.

Please skip this pointless boilerplate.

>  	match = of_match_node(emac_rockchip_dt_ids, dev->of_node);
> +	if (!match) {
> +		dev_err(dev, "No matching device found\n");
> +		return -ENODEV;

"device" and ENODEV are not right here.
-- 
pw-bot: cr


From marex at denx.de  Fri Dec  1 22:44:47 2023
From: marex at denx.de (Marek Vasut)
Date: Sat, 2 Dec 2023 07:44:47 +0100
Subject: [PATCH] media: nxp: isi: Check whether pad is non-NULL before
 access
In-Reply-To: <CAOMZO5BssVez71=uCYd0XhL02xd1TrUyTzCc1fq_sWfENLaoTA@mail.gmail.com>
References: <20231201150614.63300-1-marex@denx.de>
 <CAOMZO5BssVez71=uCYd0XhL02xd1TrUyTzCc1fq_sWfENLaoTA@mail.gmail.com>
Message-ID: <890ae113-7c7f-4214-9b00-ce00fc570567@denx.de>

On 12/2/23 03:27, Fabio Estevam wrote:
> On Fri, Dec 1, 2023 at 12:06?PM Marek Vasut <marex at denx.de> wrote:
> 
>>          pad = media_pad_remote_pad_first(&xbar->pads[sink_pad]);
>> -       sd = media_entity_to_v4l2_subdev(pad->entity);
>> +       if (!pad) {
>> +               dev_dbg(xbar->isi->dev,
> 
> Maybe dev_err() here instead?

That dev_dbg() is aligned with the prints in the rest of the function 
and it's not like kernel should do dev_err() into kernel log every time 
userspace does something wrong.

> Anyway:
> 
> Reviewed-by: Fabio Estevam <festevam at gmail.com>

Thanks !


From ardb at kernel.org  Fri Dec  1 22:53:58 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Sat, 2 Dec 2023 07:53:58 +0100
Subject: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
In-Reply-To: <4597db06-dabc-4bb2-9f24-bd30e07ff86d@broadcom.com>
References: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
 <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
 <81af85b4-5274-4362-9413-890425c60524@broadcom.com> <20231201130702.2824115c@gandalf.local.home>
 <4597db06-dabc-4bb2-9f24-bd30e07ff86d@broadcom.com>
Message-ID: <CAMj1kXFMy0=DP3-Ycsj+XCHWxvqNqddBkEm71Nrr-m9gVca21w@mail.gmail.com>

On Fri, 1 Dec 2023 at 23:59, Justin Chen <justin.chen at broadcom.com> wrote:
>
>
>
> On 12/1/23 10:07 AM, Steven Rostedt wrote:
> > On Fri, 1 Dec 2023 09:25:59 -0800
> > Justin Chen <justin.chen at broadcom.com> wrote:
> >
> >>> It appears the sub instruction at 0x6dd0 correctly accounts for the
> >>> extra 8 bytes, so the frame pointer is valid. So it is our assumption
> >>> that there are no gaps between the stack frames is invalid.
> >>
> >> Thanks for the assistance. The gap between the stack frame depends on
> >> the function. Most do not have a gap. Some have 8 (as shown above), some
> >> have 12. A single assumption here is not going to work. I'm having a
> >> hard time finding out the reasoning for this gap. I tried disabling a
> >> bunch of gcc flags as well as -O2 and the gap still exists.
> >
> > That code was originally added because of some strange things that gcc did
> > with mcount (for example, it made a copy of the stack frame that it passed
> > to mcount, where the function graph tracer replaced the copy of the return
> > stack making the shadow stack go out of sync and crash). This was very hard
> > to debug and I added this code to detect it if it happened again.
> >
> > Well it's been over a decade since that happened (2009).
> >
> >    71e308a239c09 ("function-graph: add stack frame test")
> >
> > I'm happy assuming that the compiler folks are aware of our tricks with
> > hijacking return calls and I don't expect it to happen again. We can just
> > rip out those checks. That is, if it's only causing false positives, I
> > don't think it's worth keeping around.
> >
> > Has it detected any real issues on the Arm platforms?
> >
> > -- Steve
>
> I am not familiar enough to make a call. But from my limited testing
> with ARM, I didn't see any issues. If you would like me to, I can submit
> a patch to remove the check entirely. Or maybe only disable it for ARM?
>

Please try the fix I proposed first.


From cfsworks at gmail.com  Fri Dec  1 23:12:12 2023
From: cfsworks at gmail.com (Sam Edwards)
Date: Fri,  1 Dec 2023 23:12:12 -0800
Subject: [PATCH] arm64: dts: rockchip: Fix Turing RK1 interrupt pinctrls
Message-ID: <20231202071212.1606800-1-CFSworks@gmail.com>

The pinctrls for the hym8563 interrupt line and fan-tach input
were both mistakenly defined as `pcfg_pull_none`. As these are
active-low signals (level-triggered, in the hym8563 case) which
may not be driven at times, these should really be pull-up. The
lack of any bias results in spurious interrupts.

Fix this by modifying the `rockchip,pins` properties as necessary
to enable the pull-up resistors.

Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
Signed-off-by: Sam Edwards <CFSworks at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
index b517debf2b54..bbb6d38cd159 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
@@ -294,13 +294,13 @@ &pcie3x4 {
 &pinctrl {
 	fan {
 		fan_int: fan-int {
-			rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+			rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
 		};
 	};
 
 	hym8563 {
 		hym8563_int: hym8563-int {
-			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
 		};
 	};
 
-- 
2.41.0



From arinc.unal at arinc9.com  Sat Dec  2 00:29:18 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Sat, 2 Dec 2023 11:29:18 +0300
Subject: [PATCH net-next 01/15] net: dsa: mt7530: always trap frames to
 active CPU port on MT7530
In-Reply-To: <ZVjLj6/iCL/muzmH@shell.armlinux.org.uk>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-2-arinc.unal@arinc9.com>
 <ZVjLj6/iCL/muzmH@shell.armlinux.org.uk>
Message-ID: <ffaa26b3-eb25-47cc-8891-fe3cbcc724da@arinc9.com>

On 18.11.2023 17:34, Russell King (Oracle) wrote:
> On Sat, Nov 18, 2023 at 03:31:51PM +0300, Ar?n? ?NAL wrote:
>> +	/* Set the CPU port to trap frames to for MT7530. Trapped frames will be
>> +	 * forwarded to the numerically smallest CPU port which the DSA conduit
>> +	 * interface its affine to is up.
>> +	 */
>> +	if (priv->id != ID_MT7530 && priv->id != ID_MT7621)
>> +		return;
>> +
>> +	if (operational)
>> +		priv->active_cpu_ports |= BIT(cpu_dp->index);
>> +	else
>> +		priv->active_cpu_ports &= ~BIT(cpu_dp->index);
>> +
>> +	if (priv->active_cpu_ports)
>> +		mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, CPU_EN |
>> +			   CPU_PORT(__ffs(priv->active_cpu_ports)));
> 
> I would be tempted to write this as:
> 
> 	mask = BIT(cpu_dp->index);
> 
> 	if (operational)
> 		priv->active_cpu_ports |= mask;
> 	else
> 		priv->active_cpu_ports &= ~mask;
> 
> Now, what happens when active_cpu_ports is zero? Doesn't that mean there
> is no active CPU port? In which case, wouldn't disabling the CPU port
> direction be appropriate, such as:
> 
> 	if (priv->active_cpu_ports)
> 		val = CPU_EN | CPU_PORT(__ffs(priv->active_cpu_ports));
> 	else
> 		val = 0;
> 
> 	mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val);	
> 
> ?

In practice, it doesn't seem to matter. The CPU_EN bit enables the CPU port
defined on CPU_PORT_MASK which is used for trapping frames. No active CPU
ports would mean that all the DSA conduits are down. In that case, all the
user ports will be down also. So there won't be any traffic. But disabling
it is of course more appropriate here.

> 
>>   struct mt7530_priv {
>>   	struct device		*dev;
>> @@ -786,6 +787,7 @@ struct mt7530_priv {
>>   	struct irq_domain *irq_domain;
>>   	u32 irq_enable;
>>   	int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii);
>> +	unsigned long active_cpu_ports;
> 
> So this will be 32 or 64 bit in size. Presumably you know how many CPU
> ports there can be, which looking at this code must be less than 8 as
> CPU_PORT_MASK is only 3 bits in size. So, maybe use a u8, and check
> that cpu_dp->index <= 7 ?

Aren't there other mechanisms to check that cpu_dp->index is a valid port?
At least with phylink_get_caps(), only ports lower than 7 will have proper
interface modes allowed.

Here's the code after you and Vladimir's review:

static void
mt753x_conduit_state_change(struct dsa_switch *ds,
			    const struct net_device *conduit,
			    bool operational)
{
	struct dsa_port *cpu_dp = conduit->dsa_ptr;
	struct mt7530_priv *priv = ds->priv;
	u8 mask;
	int val;

	/* Set the CPU port to trap frames to for MT7530. Trapped frames will be
	 * forwarded to the numerically smallest CPU port which the DSA conduit
	 * interface its affine to is up.
	 */
	if (priv->id != ID_MT7530 && priv->id != ID_MT7621)
		return;

	mask = BIT(cpu_dp->index);

	if (operational)
		priv->active_cpu_ports |= mask;
	else
		priv->active_cpu_ports &= ~mask;

	if (priv->active_cpu_ports)
		val = CPU_EN | CPU_PORT(__ffs(priv->active_cpu_ports));
	else
		val = 0;

	mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val);
}

struct mt7530_priv {
	[...]
	u8 active_cpu_ports;
};

> 
> I would also suggest moving irq_enable after create_sgmii, to avoid
> holes in the struct.

Sorry, I've got no idea about this. Could you explain why would there
possibly be holes in the struct with the current ordering of the members of
the mt7530_priv structure?

Ar?n?


From arinc.unal at arinc9.com  Sat Dec  2 00:36:03 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Sat, 2 Dec 2023 11:36:03 +0300
Subject: [PATCH net-next 05/15] net: dsa: mt7530: improve code path for
 setting up port 5
In-Reply-To: <ZVjNJ0nf7Mp0kHzH@shell.armlinux.org.uk>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-6-arinc.unal@arinc9.com>
 <ZVjNJ0nf7Mp0kHzH@shell.armlinux.org.uk>
Message-ID: <5e95a436-189f-412e-b409-89a003003292@arinc9.com>

On 18.11.2023 17:41, Russell King (Oracle) wrote:
> On Sat, Nov 18, 2023 at 03:31:55PM +0300, Ar?n? ?NAL wrote:
>> There're two code paths for setting up port 5:
>>
>> mt7530_setup()
>> -> mt7530_setup_port5()
>>
>> mt753x_phylink_mac_config()
>> -> mt753x_mac_config()
>>     -> mt7530_mac_config()
>>        -> mt7530_setup_port5()
>>
>> Currently mt7530_setup_port5() from mt7530_setup() always runs. If port 5
>> is used as a CPU, DSA, or user port, mt7530_setup_port5() from
>> mt753x_phylink_mac_config() won't run. That is because priv->p5_interface
>> set on mt7530_setup_port5() will match state->interface on
>> mt753x_phylink_mac_config() which will stop running mt7530_setup_port5()
>> again.
>>
>> Therefore, mt7530_setup_port5() will never run from
>> mt753x_phylink_mac_config().
>>
>> Address this by not running mt7530_setup_port5() from mt7530_setup() if
>> port 5 is used as a CPU, DSA, or user port. This driver isn't in the
>> dsa_switches_apply_workarounds[] array so phylink will always be present.
>>
>> For the cases of PHY muxing or the port being disabled, call
>> mt7530_setup_port5() from mt7530_setup(). mt7530_setup_port5() from
>> mt753x_phylink_mac_config() won't run when port 5 is disabled or used for
>> PHY muxing as port 5 won't be defined on the devicetree.
> 
> ... and this should state why this needs to happen - in other words,
> the commit message should state why is it critical that port 5 is
> always setup.

Actually, port 5 must not always be setup. With patch 7, I explain this
while preventing mt7530_setup_port5() from running if port 5 is disabled.

Ar?n?


From arinc.unal at arinc9.com  Sat Dec  2 00:45:42 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Sat, 2 Dec 2023 11:45:42 +0300
Subject: [PATCH net-next 07/15] net: dsa: mt7530: do not run
 mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <20231121185358.GA16629@kernel.org>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-8-arinc.unal@arinc9.com>
 <20231121185358.GA16629@kernel.org>
Message-ID: <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>

Hi Simon.

On 21.11.2023 21:53, Simon Horman wrote:
> On Sat, Nov 18, 2023 at 03:31:57PM +0300, Ar?n? ?NAL wrote:
>> There's no need to run all the code on mt7530_setup_port5() if port 5 is
>> disabled. The only case for calling mt7530_setup_port5() from
>> mt7530_setup() is when PHY muxing is enabled. That is because port 5 is not
>> defined as a port on the devicetree, therefore, it cannot be controlled by
>> phylink.
>>
>> Because of this, run mt7530_setup_port5() if priv->p5_intf_sel is
>> P5_INTF_SEL_PHY_P0 or P5_INTF_SEL_PHY_P4. Remove the P5_DISABLED case from
>> mt7530_setup_port5().
>>
>> Stop initialising the interface variable as the remaining cases will always
>> call mt7530_setup_port5() with it initialised.
>>
>> Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
>> Reviewed-by: Vladimir Oltean <olteanv at gmail.com>
>> ---
>>   drivers/net/dsa/mt7530.c | 9 +++------
>>   1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
>> index fc87ec817672..1aab4c3f28b0 100644
>> --- a/drivers/net/dsa/mt7530.c
>> +++ b/drivers/net/dsa/mt7530.c
>> @@ -942,9 +942,6 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
>>   		/* MT7530_P5_MODE_GMAC: P5 -> External phy or 2nd GMAC */
>>   		val &= ~MHWTRAP_P5_DIS;
>>   		break;
>> -	case P5_DISABLED:
>> -		interface = PHY_INTERFACE_MODE_NA;
>> -		break;
>>   	default:
>>   		dev_err(ds->dev, "Unsupported p5_intf_sel %d\n",
>>   			priv->p5_intf_sel);
>> @@ -2313,8 +2310,6 @@ mt7530_setup(struct dsa_switch *ds)
>>   		 * Set priv->p5_intf_sel to the appropriate value if PHY muxing
>>   		 * is detected.
>>   		 */
>> -		interface = PHY_INTERFACE_MODE_NA;
>> -
>>   		for_each_child_of_node(dn, mac_np) {
>>   			if (!of_device_is_compatible(mac_np,
>>   						     "mediatek,eth-mac"))
>> @@ -2346,7 +2341,9 @@ mt7530_setup(struct dsa_switch *ds)
>>   			break;
>>   		}
>>   
>> -		mt7530_setup_port5(ds, interface);
>> +		if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 ||
>> +		    priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
>> +			mt7530_setup_port5(ds, interface);
> 
> Hi Ar?n?,
> 
> It appears that interface is now uninitialised here.
> 
> Flagged by Smatch.

I'm not sure why it doesn't catch that for mt7530_setup_port5() to run
here, priv->p5_intf_sel must be either P5_INTF_SEL_PHY_P0 or
P5_INTF_SEL_PHY_P4. And for that to happen, the interface variable will be
initialised.

for_each_child_of_node(dn, mac_np) {
	if (!of_device_is_compatible(mac_np,
				     "mediatek,eth-mac"))
		continue;

	ret = of_property_read_u32(mac_np, "reg", &id);
	if (ret < 0 || id != 1)
		continue;

	phy_node = of_parse_phandle(mac_np, "phy-handle", 0);
	if (!phy_node)
		continue;

	if (phy_node->parent == priv->dev->of_node->parent) {
		ret = of_get_phy_mode(mac_np, &interface);
		if (ret && ret != -ENODEV) {
			of_node_put(mac_np);
			of_node_put(phy_node);
			return ret;
		}
		id = of_mdio_parse_addr(ds->dev, phy_node);
		if (id == 0)
			priv->p5_intf_sel = P5_INTF_SEL_PHY_P0;
		if (id == 4)
			priv->p5_intf_sel = P5_INTF_SEL_PHY_P4;
	}
	of_node_put(mac_np);
	of_node_put(phy_node);
	break;
}

if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 ||
     priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
	mt7530_setup_port5(ds, interface);

Ar?n?


From justin.chen at broadcom.com  Sat Dec  2 00:49:07 2023
From: justin.chen at broadcom.com (Justin Chen)
Date: Sat, 2 Dec 2023 00:49:07 -0800
Subject: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
In-Reply-To: <CAMj1kXFMy0=DP3-Ycsj+XCHWxvqNqddBkEm71Nrr-m9gVca21w@mail.gmail.com>
References: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
 <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
 <81af85b4-5274-4362-9413-890425c60524@broadcom.com>
 <20231201130702.2824115c@gandalf.local.home>
 <4597db06-dabc-4bb2-9f24-bd30e07ff86d@broadcom.com>
 <CAMj1kXFMy0=DP3-Ycsj+XCHWxvqNqddBkEm71Nrr-m9gVca21w@mail.gmail.com>
Message-ID: <dc1dd584-1970-4460-b76c-3cd9300a23e4@broadcom.com>



On 12/1/23 10:53 PM, Ard Biesheuvel wrote:
> On Fri, 1 Dec 2023 at 23:59, Justin Chen <justin.chen at broadcom.com> wrote:
>>
>>
>>
>> On 12/1/23 10:07 AM, Steven Rostedt wrote:
>>> On Fri, 1 Dec 2023 09:25:59 -0800
>>> Justin Chen <justin.chen at broadcom.com> wrote:
>>>
>>>>> It appears the sub instruction at 0x6dd0 correctly accounts for the
>>>>> extra 8 bytes, so the frame pointer is valid. So it is our assumption
>>>>> that there are no gaps between the stack frames is invalid.
>>>>
>>>> Thanks for the assistance. The gap between the stack frame depends on
>>>> the function. Most do not have a gap. Some have 8 (as shown above), some
>>>> have 12. A single assumption here is not going to work. I'm having a
>>>> hard time finding out the reasoning for this gap. I tried disabling a
>>>> bunch of gcc flags as well as -O2 and the gap still exists.
>>>
>>> That code was originally added because of some strange things that gcc did
>>> with mcount (for example, it made a copy of the stack frame that it passed
>>> to mcount, where the function graph tracer replaced the copy of the return
>>> stack making the shadow stack go out of sync and crash). This was very hard
>>> to debug and I added this code to detect it if it happened again.
>>>
>>> Well it's been over a decade since that happened (2009).
>>>
>>>     71e308a239c09 ("function-graph: add stack frame test")
>>>
>>> I'm happy assuming that the compiler folks are aware of our tricks with
>>> hijacking return calls and I don't expect it to happen again. We can just
>>> rip out those checks. That is, if it's only causing false positives, I
>>> don't think it's worth keeping around.
>>>
>>> Has it detected any real issues on the Arm platforms?
>>>
>>> -- Steve
>>
>> I am not familiar enough to make a call. But from my limited testing
>> with ARM, I didn't see any issues. If you would like me to, I can submit
>> a patch to remove the check entirely. Or maybe only disable it for ARM?
>>
> 
> Please try the fix I proposed first.

Just tested it. Seems to do the trick. Either solution works for me.

FWIW I also experimented with LLVM, looks like function_graph just 
crashes regardless of the issue being discussed. The disassemble of 
LLVM[1] does something completely different.

Thanks,
Justin

[1]
LLVM dump
c0c6faa0 <sk_getsockopt>:
c0c6faa0: f0 4f 2d e9   push    {r4, r5, r6, r7, r8, r9, r10, r11, lr}
c0c6faa4: 1c b0 8d e2   add     r11, sp, #28
c0c6faa8: ac d0 4d e2   sub     sp, sp, #172
c0c6faac: 00 70 a0 e1   mov     r7, r0
c0c6fab0: c8 0c 04 e3   movw    r0, #19656
c0c6fab4: 80 02 4c e3   movt    r0, #49792
c0c6fab8: 03 50 a0 e1   mov     r5, r3
c0c6fabc: 00 00 90 e5   ldr     r0, [r0]
c0c6fac0: 02 a0 a0 e1   mov     r10, r2
c0c6fac4: 20 00 0b e5   str     r0, [r11, #-32]
c0c6fac8: 00 40 2d e9   stmdb   sp!, {lr}
c0c6facc: 4b 8b d6 eb   bl      0xc0212800 <__gnu_mcount_nc> @ imm = 
#-10867412
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231202/fe7cc9bf/attachment.p7s>

From s-vadapalli at ti.com  Sat Dec  2 00:50:15 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Sat, 2 Dec 2023 14:20:15 +0530
Subject: [PATCH v4] PCI: Cadence: Clear the ARI Capability Next Function Number of the last function
Message-ID: <20231202085015.3048516-1-s-vadapalli@ti.com>

From: Jasko-EXT Wojciech <wojciech.jasko-EXT at continental-corporation.com>

Next Function Number field in ARI Capability Register for last function
must be zero by default as per the PCIe specification, indicating there
is no next higher number function but that's not happening in our case,
so this patch clears the Next Function Number field for last function used.

Signed-off-by: Jasko-EXT Wojciech <wojciech.jasko-EXT at continental-corporation.com>
Signed-off-by: Achal Verma <a-verma1 at ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr at ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---

Hello,

This patch is based on linux-next tagged next-20231201.

v3:
https://patchwork.kernel.org/project/linux-pci/patch/20230316071156.200888-1-a-verma1 at ti.com/
Changes since v3: - Rebased on next-20231201.
- Collected Reviewed-by tag from Vignesh Raghavendra <vigneshr at ti.com>.

Regards,
Siddharth.

 drivers/pci/controller/cadence/pcie-cadence-ep.c | 14 +++++++++++++-
 drivers/pci/controller/cadence/pcie-cadence.h    |  6 ++++++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 3142feb8ac19..2dd4d7027659 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -566,7 +566,8 @@ static int cdns_pcie_ep_start(struct pci_epc *epc)
 	struct cdns_pcie *pcie = &ep->pcie;
 	struct device *dev = pcie->dev;
 	int max_epfs = sizeof(epc->function_num_map) * 8;
-	int ret, value, epf;
+	int ret, epf, last_fn;
+	u32 reg, value;
 
 	/*
 	 * BIT(0) is hardwired to 1, hence function 0 is always enabled
@@ -574,6 +575,17 @@ static int cdns_pcie_ep_start(struct pci_epc *epc)
 	 */
 	cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, epc->function_num_map);
 
+	/*
+	 * Next function field in ARI_CAP_AND_CTR register for last function
+	 * should be 0.
+	 * Clearing Next Function Number field for the last function used.
+	 */
+	last_fn = find_last_bit(&epc->function_num_map, BITS_PER_LONG);
+	reg     = CDNS_PCIE_CORE_PF_I_ARI_CAP_AND_CTRL(last_fn);
+	value  = cdns_pcie_readl(pcie, reg);
+	value &= ~CDNS_PCIE_ARI_CAP_NFN_MASK;
+	cdns_pcie_writel(pcie, reg, value);
+
 	if (ep->quirk_disable_flr) {
 		for (epf = 0; epf < max_epfs; epf++) {
 			if (!(epc->function_num_map & BIT(epf)))
diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
index 373cb50fcd15..9c16745582eb 100644
--- a/drivers/pci/controller/cadence/pcie-cadence.h
+++ b/drivers/pci/controller/cadence/pcie-cadence.h
@@ -130,6 +130,12 @@
 #define CDNS_PCIE_EP_FUNC_DEV_CAP_OFFSET	0xc0
 #define CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET	0x200
 
+/*
+ * Endpoint PF Registers
+ */
+#define CDNS_PCIE_CORE_PF_I_ARI_CAP_AND_CTRL(fn)	(0x144 + (fn) * 0x1000)
+#define CDNS_PCIE_ARI_CAP_NFN_MASK	GENMASK(15, 8)
+
 /*
  * Root Port Registers (PCI configuration space for the root port function)
  */
-- 
2.34.1



From arinc.unal at arinc9.com  Sat Dec  2 00:52:13 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Sat, 2 Dec 2023 11:52:13 +0300
Subject: [PATCH net-next 00/15] MT7530 DSA subdriver improvements
In-Reply-To: <20231118123205.266819-1-arinc.unal@arinc9.com>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
Message-ID: <45221d69-a780-4e81-b4c3-db1b9894a1db@arinc9.com>

Can I receive reviews for patches 6, 12, 13, 14, and 15?

Thanks.
Ar?n?


From ardb at kernel.org  Sat Dec  2 01:26:54 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Sat, 2 Dec 2023 10:26:54 +0100
Subject: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
In-Reply-To: <dc1dd584-1970-4460-b76c-3cd9300a23e4@broadcom.com>
References: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
 <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
 <81af85b4-5274-4362-9413-890425c60524@broadcom.com> <20231201130702.2824115c@gandalf.local.home>
 <4597db06-dabc-4bb2-9f24-bd30e07ff86d@broadcom.com> <CAMj1kXFMy0=DP3-Ycsj+XCHWxvqNqddBkEm71Nrr-m9gVca21w@mail.gmail.com>
 <dc1dd584-1970-4460-b76c-3cd9300a23e4@broadcom.com>
Message-ID: <CAMj1kXFRknpr+gASm-mMcWzLqVQnWXf3UK+SbD3ouMgdOtCAzA@mail.gmail.com>

On Sat, 2 Dec 2023 at 09:49, Justin Chen <justin.chen at broadcom.com> wrote:
>
>
>
> On 12/1/23 10:53 PM, Ard Biesheuvel wrote:
> > On Fri, 1 Dec 2023 at 23:59, Justin Chen <justin.chen at broadcom.com> wrote:
> >>
> >>
> >>
> >> On 12/1/23 10:07 AM, Steven Rostedt wrote:
> >>> On Fri, 1 Dec 2023 09:25:59 -0800
> >>> Justin Chen <justin.chen at broadcom.com> wrote:
> >>>
> >>>>> It appears the sub instruction at 0x6dd0 correctly accounts for the
> >>>>> extra 8 bytes, so the frame pointer is valid. So it is our assumption
> >>>>> that there are no gaps between the stack frames is invalid.
> >>>>
> >>>> Thanks for the assistance. The gap between the stack frame depends on
> >>>> the function. Most do not have a gap. Some have 8 (as shown above), some
> >>>> have 12. A single assumption here is not going to work. I'm having a
> >>>> hard time finding out the reasoning for this gap. I tried disabling a
> >>>> bunch of gcc flags as well as -O2 and the gap still exists.
> >>>
> >>> That code was originally added because of some strange things that gcc did
> >>> with mcount (for example, it made a copy of the stack frame that it passed
> >>> to mcount, where the function graph tracer replaced the copy of the return
> >>> stack making the shadow stack go out of sync and crash). This was very hard
> >>> to debug and I added this code to detect it if it happened again.
> >>>
> >>> Well it's been over a decade since that happened (2009).
> >>>
> >>>     71e308a239c09 ("function-graph: add stack frame test")
> >>>
> >>> I'm happy assuming that the compiler folks are aware of our tricks with
> >>> hijacking return calls and I don't expect it to happen again. We can just
> >>> rip out those checks. That is, if it's only causing false positives, I
> >>> don't think it's worth keeping around.
> >>>
> >>> Has it detected any real issues on the Arm platforms?
> >>>
> >>> -- Steve
> >>
> >> I am not familiar enough to make a call. But from my limited testing
> >> with ARM, I didn't see any issues. If you would like me to, I can submit
> >> a patch to remove the check entirely. Or maybe only disable it for ARM?
> >>
> >
> > Please try the fix I proposed first.
>
> Just tested it. Seems to do the trick.

Thanks

> Either solution works for me.
>

Given that this discussion is taking place in the context of the
report of an issue identified by GRAPH_FP_TEST, I don't see how
removing that would be a reasonable conclusion.

> FWIW I also experimented with LLVM, looks like function_graph just
> crashes regardless of the issue being discussed. The disassemble of
> LLVM[1] does something completely different.
>


LLVM does not support CONFIG_UNWINDER_FRAME_POINTER so the fact that
the prologue looks different is expected.

In the case below, the FP {r11} is correctly made to point to a {r11,
lr} tuple on the stack, so the codegen is correct AFAICT. But IIRC we
rely on unwind information for ftrace in this case, not the frame
pointer.

Could you be more specific about the crash?


>
> [1]
> LLVM dump
> c0c6faa0 <sk_getsockopt>:
> c0c6faa0: f0 4f 2d e9   push    {r4, r5, r6, r7, r8, r9, r10, r11, lr}
> c0c6faa4: 1c b0 8d e2   add     r11, sp, #28
> c0c6faa8: ac d0 4d e2   sub     sp, sp, #172
> c0c6faac: 00 70 a0 e1   mov     r7, r0
> c0c6fab0: c8 0c 04 e3   movw    r0, #19656
> c0c6fab4: 80 02 4c e3   movt    r0, #49792
> c0c6fab8: 03 50 a0 e1   mov     r5, r3
> c0c6fabc: 00 00 90 e5   ldr     r0, [r0]
> c0c6fac0: 02 a0 a0 e1   mov     r10, r2
> c0c6fac4: 20 00 0b e5   str     r0, [r11, #-32]
> c0c6fac8: 00 40 2d e9   stmdb   sp!, {lr}
> c0c6facc: 4b 8b d6 eb   bl      0xc0212800 <__gnu_mcount_nc> @ imm =
> #-10867412


From linux at armlinux.org.uk  Sat Dec  2 01:30:26 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Sat, 2 Dec 2023 09:30:26 +0000
Subject: [PATCH net-next 07/15] net: dsa: mt7530: do not run
 mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-8-arinc.unal@arinc9.com>
 <20231121185358.GA16629@kernel.org>
 <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
Message-ID: <ZWr5MiiR1OQujoGG@shell.armlinux.org.uk>

On Sat, Dec 02, 2023 at 11:45:42AM +0300, Ar?n? ?NAL wrote:
> Hi Simon.
> 
> On 21.11.2023 21:53, Simon Horman wrote:
> > On Sat, Nov 18, 2023 at 03:31:57PM +0300, Ar?n? ?NAL wrote:
> > > There's no need to run all the code on mt7530_setup_port5() if port 5 is
> > > disabled. The only case for calling mt7530_setup_port5() from
> > > mt7530_setup() is when PHY muxing is enabled. That is because port 5 is not
> > > defined as a port on the devicetree, therefore, it cannot be controlled by
> > > phylink.
> > > 
> > > Because of this, run mt7530_setup_port5() if priv->p5_intf_sel is
> > > P5_INTF_SEL_PHY_P0 or P5_INTF_SEL_PHY_P4. Remove the P5_DISABLED case from
> > > mt7530_setup_port5().
> > > 
> > > Stop initialising the interface variable as the remaining cases will always
> > > call mt7530_setup_port5() with it initialised.
> > > 
> > > Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
> > > Reviewed-by: Vladimir Oltean <olteanv at gmail.com>
> > > ---
> > >   drivers/net/dsa/mt7530.c | 9 +++------
> > >   1 file changed, 3 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> > > index fc87ec817672..1aab4c3f28b0 100644
> > > --- a/drivers/net/dsa/mt7530.c
> > > +++ b/drivers/net/dsa/mt7530.c
> > > @@ -942,9 +942,6 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
> > >   		/* MT7530_P5_MODE_GMAC: P5 -> External phy or 2nd GMAC */
> > >   		val &= ~MHWTRAP_P5_DIS;
> > >   		break;
> > > -	case P5_DISABLED:
> > > -		interface = PHY_INTERFACE_MODE_NA;
> > > -		break;
> > >   	default:
> > >   		dev_err(ds->dev, "Unsupported p5_intf_sel %d\n",
> > >   			priv->p5_intf_sel);
> > > @@ -2313,8 +2310,6 @@ mt7530_setup(struct dsa_switch *ds)
> > >   		 * Set priv->p5_intf_sel to the appropriate value if PHY muxing
> > >   		 * is detected.
> > >   		 */
> > > -		interface = PHY_INTERFACE_MODE_NA;
> > > -
> > >   		for_each_child_of_node(dn, mac_np) {
> > >   			if (!of_device_is_compatible(mac_np,
> > >   						     "mediatek,eth-mac"))
> > > @@ -2346,7 +2341,9 @@ mt7530_setup(struct dsa_switch *ds)
> > >   			break;
> > >   		}
> > > -		mt7530_setup_port5(ds, interface);
> > > +		if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 ||
> > > +		    priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
> > > +			mt7530_setup_port5(ds, interface);
> > 
> > Hi Ar?n?,
> > 
> > It appears that interface is now uninitialised here.
> > 
> > Flagged by Smatch.
> 
> I'm not sure why it doesn't catch that for mt7530_setup_port5() to run
> here, priv->p5_intf_sel must be either P5_INTF_SEL_PHY_P0 or
> P5_INTF_SEL_PHY_P4. And for that to happen, the interface variable will be
> initialised.

It's probably due to the complexities involved in analysing the values
of variables, especially when they're in structures that are passed in.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From francesco at dolcini.it  Sat Dec  2 03:51:03 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Sat, 2 Dec 2023 12:51:03 +0100
Subject: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
In-Reply-To: <4075500.2IRrRt1zHL@diego>
References: <20231201191228.343230-1-heiko@sntech.de>
 <bf5c7806-7405-4728-bb10-7913368f62a0@gmail.com>
 <ZWo9ecC45DZaqVJJ@livingston.pivistrello.it>
 <4075500.2IRrRt1zHL@diego>
Message-ID: <ZWsaJ-3bWZbjtFiz@livingston.pivistrello.it>

On Fri, Dec 01, 2023 at 09:56:27PM +0100, Heiko St?bner wrote:
> Hi,
> 
> Am Freitag, 1. Dezember 2023, 21:09:29 CET schrieb Francesco Dolcini:
> > On Fri, Dec 01, 2023 at 11:57:53AM -0800, Florian Fainelli wrote:
> > > +Francesco,
> > > 
> > > On 12/1/23 11:12, Heiko Stuebner wrote:
> > > > From: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > > 
> > > > Boards using socs like the rk3588 can use up to 10 uarts, so the default
> > > > of 4 is way too low. Therefore increase the maximum number to 10.
> > Do you have an actual need of 10, e.g. an existing board with 10 uarts
> > enabled supported by the mainline kernel? Just thinking at the last arm64 SoC I
> > am working with it should be 12 if we use this as a metric.
> 
> The rk3588 can do 10 (0-9), the board I'm working on is using up to uart7 (aka 8 uarts).
> Reasoning below in the 3rd paragraph.
> 
> 
> > > > SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
> > > > data structures to prepare before registering them. This option can stay
> > > > at its default value of 4 since for one it can be changed via a boot
> > > > parameter 8250.nr_uarts but also since
> > > > commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")
> > > > 
> > > > the kernel can register uarts dynamically that are above the
> > > > SERIAL_8250_RUNTIME_UARTS threshold.
> > > > 
> > > > Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > 
> > > There is a competing patch set from Francesco being submitted as well:
> > > https://lore.kernel.org/all/20231201171544.1901-1-francesco at dolcini.it/
> > >
> > > looks like some coordination is necessary.
> 
> 
> So TL;DR:
> I could live with the 8 from your original patch, but I guess would prefer
> going with a safer value, so the 10 or your 12 from above.
> 
> Because I guess if a controller is present, someone will use it
> eventually ;-).

There was an explicit push back on this approach from Arnd, see
https://lore.kernel.org/all/CAK8P3a2VSBvOn1o+q1PYZaQ6LS9U4cz+DZGuDbisHkwNs2dAAw at mail.gmail.com/

I would propose that we stay with my current proposal of 8.

Francesco




From heiko at sntech.de  Sat Dec  2 04:12:32 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sat, 02 Dec 2023 13:12:32 +0100
Subject: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
In-Reply-To: <ZWsaJ-3bWZbjtFiz@livingston.pivistrello.it>
References: <20231201191228.343230-1-heiko@sntech.de> <4075500.2IRrRt1zHL@diego>
 <ZWsaJ-3bWZbjtFiz@livingston.pivistrello.it>
Message-ID: <3898725.Zkmt1EvEu4@diego>

Am Samstag, 2. Dezember 2023, 12:51:03 CET schrieb Francesco Dolcini:
> On Fri, Dec 01, 2023 at 09:56:27PM +0100, Heiko St?bner wrote:
> > Hi,
> > 
> > Am Freitag, 1. Dezember 2023, 21:09:29 CET schrieb Francesco Dolcini:
> > > On Fri, Dec 01, 2023 at 11:57:53AM -0800, Florian Fainelli wrote:
> > > > +Francesco,
> > > > 
> > > > On 12/1/23 11:12, Heiko Stuebner wrote:
> > > > > From: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > > > 
> > > > > Boards using socs like the rk3588 can use up to 10 uarts, so the default
> > > > > of 4 is way too low. Therefore increase the maximum number to 10.
> > > Do you have an actual need of 10, e.g. an existing board with 10 uarts
> > > enabled supported by the mainline kernel? Just thinking at the last arm64 SoC I
> > > am working with it should be 12 if we use this as a metric.
> > 
> > The rk3588 can do 10 (0-9), the board I'm working on is using up to uart7 (aka 8 uarts).
> > Reasoning below in the 3rd paragraph.
> > 
> > 
> > > > > SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
> > > > > data structures to prepare before registering them. This option can stay
> > > > > at its default value of 4 since for one it can be changed via a boot
> > > > > parameter 8250.nr_uarts but also since
> > > > > commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")
> > > > > 
> > > > > the kernel can register uarts dynamically that are above the
> > > > > SERIAL_8250_RUNTIME_UARTS threshold.
> > > > > 
> > > > > Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > > 
> > > > There is a competing patch set from Francesco being submitted as well:
> > > > https://lore.kernel.org/all/20231201171544.1901-1-francesco at dolcini.it/
> > > >
> > > > looks like some coordination is necessary.
> > 
> > 
> > So TL;DR:
> > I could live with the 8 from your original patch, but I guess would prefer
> > going with a safer value, so the 10 or your 12 from above.
> > 
> > Because I guess if a controller is present, someone will use it
> > eventually ;-).
> 
> There was an explicit push back on this approach from Arnd, see
> https://lore.kernel.org/all/CAK8P3a2VSBvOn1o+q1PYZaQ6LS9U4cz+DZGuDbisHkwNs2dAAw at mail.gmail.com/

aliases really are a matter of difficult discussions ;-)
I.e. Krzysztof's argument some days ago was

	"No, this should be per-board to match board labeling/schematics."

https://lore.kernel.org/all/813224c2-398d-4c2d-8909-1839ce63be60 at linaro.org/

And on Rockchip socs everyting from soc manual, board schematics down to
the description of pin headers use the uart controller number so people will
expect uart9 to be ttyS9 on the system as well.


> I would propose that we stay with my current proposal of 8.

But ok we can go this route, simply as the current board I'm working on
only use 8, so I can leave that "fight" to someone else ;-)


Heiko




From maz at kernel.org  Sat Dec  2 04:20:31 2023
From: maz at kernel.org (Marc Zyngier)
Date: Sat, 02 Dec 2023 12:20:31 +0000
Subject: [RFC PATCH] KVM: arm/arm64: GICv4: Support shared VLPI
In-Reply-To: <952bd5dc-dd20-acc3-d77e-c9b14e5728d3@huawei.com>
References: <20231102143507.840-1-jiangkunkun@huawei.com>
	<87msvt6cc7.wl-maz@kernel.org>
	<1fb8353e-e9c4-2570-c2ca-ec537c18ac4d@huawei.com>
	<86edh228xx.wl-maz@kernel.org>
	<952bd5dc-dd20-acc3-d77e-c9b14e5728d3@huawei.com>
Message-ID: <87fs0k94og.wl-maz@kernel.org>

Hi Kunkun,

On Wed, 08 Nov 2023 09:45:51 +0000,
Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> 
> Hi Marc,
> 
> On 2023/11/6 23:33, Marc Zyngier wrote:
> > On Mon, 06 Nov 2023 14:59:01 +0000,
> > Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> >> The virtio-pci driver write entry1-6
> >> massage.data in the msix-table and trap to QEMU for processing. The
> >> massage.data is as follow:
> >>> entry-0 0
> >>> entry-1 1
> >>> entry-2 1
> >>> entry-3 1
> >>> entry-4 1
> >>> entry-5 1
> >>> entry-6 1
> > Urgh... is vp_modern_queue_vector() used in your configuration? This
> > is ... terrible.
> I encountered this problem using the 4.19 version kernel, but not the
> 5.10 version. This vp_modern_queue_vector() function does not exist
> in 4.19, but it uses 'vp_iowrite16(msix_vec, &cfg->queue_msix_vector)',
> the same as vp_modern_queue_vector().
> 
> In the past two days, I learned about the virtio driver and made some
> new discoveries. When 'num_queues' is greater than maxcpus, it will
> fall back into MSI-X with one shared for queues. The two patches[1],
> submitted by Dongli, limits the number of hw queues used by
> virtio-blk/virtio-scsi by 'nr_cpu_ids'. The two patches were merged
> in 5.1-rc2. And the patch related virtio-blk was merged into the 4.19
> stable branch.The patch related virtio-scsi was not merged.
> [1]
> https://lore.kernel.org/all/1553682995-5682-1-git-send-email-dongli.zhang at oracle.com/
> 
> This is the earliest discussion.
> https://lore.kernel.org/all/e4afe4c5-0262-4500-aeec-60f30734b4fc at default/
> 
> I don't know if there are other circumstances that would cause it to
> fall back into MSI-X with one shared for queues. At least the hack
> method is possible.
> > I wonder if PCIe actually allows this sort of thing.
> Do you think the virtio driver should be modified?

I think the virtio driver should stop messing with the MSI-X
configuration behind the kernel's back. For example, what happens if
the kernel needs to do a disable_irq() on the "shared" interrupt? It
will mask the interrupt in *one* of the vectors, and the interrupt
will still be screaming.

This is terribly broken, even on x86.

> > In any case, this sort of behaviour breaks so many thing in KVM's
> > implementation that I'd recommend you disable GICv4 until we have a
> > good solution for that.
> There seems to be no restriction in the GIC specification that multiple
> host irqs cannot be mapped to the same vlpi. Or maybe I didn't notice.
> Do you think there are any risks?

Please see 5.2.10 ("Restrictions for INTID mapping rules"), which
clearly forbids the case we have here: "Maps multiple EventID-DeviceID
combinations to the same virtual LPI INTID-vPEID.".

> GICv3 does not have this issue, but is this configuration legal?

With GICv3, the ITS doesn't see multiple mappings to the same
LPI. Each DeviceID/EventID pair has its own LPI, and KVM will just see
the injection callback from VFIO.

Honestly, the virtio driver is broken (irrespective of the
architecture), and incompatible with the GIC architecture.

	M.

-- 
Without deviation from the norm, progress is not possible.


From quic_cang at quicinc.com  Sat Dec  2 04:36:06 2023
From: quic_cang at quicinc.com (Can Guo)
Date: Sat,  2 Dec 2023 04:36:06 -0800
Subject: [PATCH v8 00/10] Enable HS-G5 support on SM8550
Message-ID: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>

This series enables HS-G5 support on SM8550.

This series is rebased on below changes from Mani -
https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-1-manivannan.sadhasivam at linaro.org/
https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-2-manivannan.sadhasivam at linaro.org/

This series is tested on below HW combinations -
SM8550 MTP + UFS4.0
SM8550 QRD + UFS3.1
SM8450 MTP + UFS3.1 (for regression test)
SM8350 MTP + UFS3.1 (for regression test)

Note that during reboot test on above platforms, I occasinally hit PA (PHY)
error during the 2nd init, this is not related with this series. A fix for
this is mentioned in below patchwork -

https://patchwork.kernel.org/project/linux-scsi/patch/1698145815-17396-1-git-send-email-quic_ziqichen at quicinc.com/

Also note that on platforms, which have two sets of UFS PHY settings are
provided (say G4 and no-G4, G5 and no-G5). The two sets of PHY settings are
basically programming different values to different registers, mixing the
two sets and/or overwriting one set with another set is definitely not
blessed by UFS PHY designers. For SM8550, this series will make sure we
honor the rule. However, for old targets Mani and I will fix them in
another series in future.

v7 -> v8:
In "scsi: ufs: ufs-qcom: Add support for UFS device version detection", fixed a BUG introduced from v6 -> v7. The spare register is added since HW ver 5, although reading the spare register on HW ver 4 is just getting 0x0, to be on the safe side, we are exluding HW ver 4.

v6 -> v7:
1. Rebased on linux-next, based SM8650 PHY settings are merged there, no changes to patches for UFS driver
2. Addressed comments from Mani

v5 -> v6:
1. Rebased on scsi-queue-6.8
2. Addressed comments from Dmitry and Mani in patches to phy-qcom-qmp-ufs.c

v4 -> v5:
Removed two useless debug prints in patch #9

v3 -> v4:
Used .tbls_hs_overlay array instead of adding more tables with different names like .tbls_hs_g5

v2 -> v3:
1. Addressed comments from Andrew, Mani and Bart in patch #1
2. Added patch #2 as per request from Andrew and Mani
3. Added patch #4 to fix a common issue on old targets, it is not necessary
   for this series, but put in this series only because it would be easier
   to maintain and no need to rebase
4. Addressed comments from Dmitry and Mani in patches to phy-qcom-qmp-ufs.c

v1 -> v2:
1. Removed 2 changes which were exposing power info in sysfs
2. Removed 1 change which was moving data structs to phy-qcom-qmp-ufs.h
3. Added one new change (the 1st one) to clean up usage of ufs_dev_params based on comments from Mani
4. Adjusted the logic of UFS device version detection according to comments from Mani:
	4.1 For HW version < 0x5, go through dual init
 	4.2 For HW version >= 0x5
		a. If UFS device version is populated, one init is required
		b. If UFS device version is not populated, go through dual init

Bao D. Nguyen (1):
  scsi: ufs: ufs-qcom: Add support for UFS device version detection

Can Guo (9):
  scsi: ufs: host: Rename structure ufs_dev_params to ufs_host_params
  scsi: ufs: ufs-qcom: No need to set hs_rate after
    ufshcd_init_host_param()
  scsi: ufs: ufs-qcom: Setup host power mode during init
  scsi: ufs: ufs-qcom: Allow the first init start with the maximum
    supported gear
  scsi: ufs: ufs-qcom: Limit HS-G5 Rate-A to hosts with HW version 5
  scsi: ufs: ufs-qcom: Set initial PHY gear to max HS gear for HW ver 4
    and newer
  scsi: ufs: ufs-qcom: Check return value of phy_set_mode_ext()
  phy: qualcomm: phy-qcom-qmp-ufs: Rectify SM8550 UFS HS-G4 PHY Settings
  phy: qualcomm: phy-qcom-qmp-ufs: Add High Speed Gear 5 support for
    SM8550

 drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h     |   2 +
 drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h |   2 +
 .../qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h    |   9 +
 drivers/phy/qualcomm/phy-qcom-qmp-ufs.c            | 191 ++++++++++++++++++---
 drivers/ufs/host/ufs-exynos.c                      |   7 +-
 drivers/ufs/host/ufs-hisi.c                        |  11 +-
 drivers/ufs/host/ufs-mediatek.c                    |  12 +-
 drivers/ufs/host/ufs-qcom.c                        |  97 ++++++++---
 drivers/ufs/host/ufs-qcom.h                        |   7 +-
 drivers/ufs/host/ufshcd-pltfrm.c                   |  69 ++++----
 drivers/ufs/host/ufshcd-pltfrm.h                   |  10 +-
 11 files changed, 309 insertions(+), 108 deletions(-)

-- 
2.7.4



From quic_cang at quicinc.com  Sat Dec  2 04:36:07 2023
From: quic_cang at quicinc.com (Can Guo)
Date: Sat,  2 Dec 2023 04:36:07 -0800
Subject: [PATCH v8 01/10] scsi: ufs: host: Rename structure ufs_dev_params to ufs_host_params
In-Reply-To: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
References: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
Message-ID: <1701520577-31163-2-git-send-email-quic_cang@quicinc.com>

Structure ufs_dev_params is actually used in UFS host vendor drivers to
declare host specific power mode parameters, like ufs_<vendor>_params or
host_cap, which makes the code not very straightforward to read. Rename the
structure ufs_dev_params to ufs_host_params and unify the declarations in
all vendor drivers to host_params.

In addition, rename the two functions ufshcd_init_pwr_dev_param() and
ufshcd_get_pwr_dev_param() which work based on the ufs_host_params to
ufshcd_init_host_params() and ufshcd_negotiate_pwr_params() respectively to
avoid confusions.

This change does not change any functionalities or logic.

Acked-by: Andrew Halaney <ahalaney at redhat.com>
Reviewed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
Reviewed-by: Bart Van Assche <bvanassche at acm.org>
Signed-off-by: Can Guo <quic_cang at quicinc.com>
---
 drivers/ufs/host/ufs-exynos.c    |  7 ++--
 drivers/ufs/host/ufs-hisi.c      | 11 +++----
 drivers/ufs/host/ufs-mediatek.c  | 12 +++----
 drivers/ufs/host/ufs-qcom.c      | 12 +++----
 drivers/ufs/host/ufshcd-pltfrm.c | 69 ++++++++++++++++++++--------------------
 drivers/ufs/host/ufshcd-pltfrm.h | 10 +++---
 6 files changed, 57 insertions(+), 64 deletions(-)

diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c
index 71bd6db..734d40f 100644
--- a/drivers/ufs/host/ufs-exynos.c
+++ b/drivers/ufs/host/ufs-exynos.c
@@ -765,7 +765,7 @@ static int exynos_ufs_pre_pwr_mode(struct ufs_hba *hba,
 {
 	struct exynos_ufs *ufs = ufshcd_get_variant(hba);
 	struct phy *generic_phy = ufs->phy;
-	struct ufs_dev_params ufs_exynos_cap;
+	struct ufs_host_params host_params;
 	int ret;
 
 	if (!dev_req_params) {
@@ -774,10 +774,9 @@ static int exynos_ufs_pre_pwr_mode(struct ufs_hba *hba,
 		goto out;
 	}
 
-	ufshcd_init_pwr_dev_param(&ufs_exynos_cap);
+	ufshcd_init_host_params(&host_params);
 
-	ret = ufshcd_get_pwr_dev_param(&ufs_exynos_cap,
-				       dev_max_params, dev_req_params);
+	ret = ufshcd_negotiate_pwr_params(&host_params, dev_max_params, dev_req_params);
 	if (ret) {
 		pr_err("%s: failed to determine capabilities\n", __func__);
 		goto out;
diff --git a/drivers/ufs/host/ufs-hisi.c b/drivers/ufs/host/ufs-hisi.c
index 0229ac0..5ee73ff 100644
--- a/drivers/ufs/host/ufs-hisi.c
+++ b/drivers/ufs/host/ufs-hisi.c
@@ -293,9 +293,9 @@ static int ufs_hisi_link_startup_notify(struct ufs_hba *hba,
 	return err;
 }
 
-static void ufs_hisi_set_dev_cap(struct ufs_dev_params *hisi_param)
+static void ufs_hisi_set_dev_cap(struct ufs_host_params *host_params)
 {
-	ufshcd_init_pwr_dev_param(hisi_param);
+	ufshcd_init_host_params(host_params);
 }
 
 static void ufs_hisi_pwr_change_pre_change(struct ufs_hba *hba)
@@ -365,7 +365,7 @@ static int ufs_hisi_pwr_change_notify(struct ufs_hba *hba,
 				       struct ufs_pa_layer_attr *dev_max_params,
 				       struct ufs_pa_layer_attr *dev_req_params)
 {
-	struct ufs_dev_params ufs_hisi_cap;
+	struct ufs_host_params host_params;
 	int ret = 0;
 
 	if (!dev_req_params) {
@@ -377,9 +377,8 @@ static int ufs_hisi_pwr_change_notify(struct ufs_hba *hba,
 
 	switch (status) {
 	case PRE_CHANGE:
-		ufs_hisi_set_dev_cap(&ufs_hisi_cap);
-		ret = ufshcd_get_pwr_dev_param(&ufs_hisi_cap,
-					       dev_max_params, dev_req_params);
+		ufs_hisi_set_dev_cap(&host_params);
+		ret = ufshcd_negotiate_pwr_params(&host_params, dev_max_params, dev_req_params);
 		if (ret) {
 			dev_err(hba->dev,
 			    "%s: failed to determine capabilities\n", __func__);
diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index fc61790..776bca4 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -996,16 +996,14 @@ static int ufs_mtk_pre_pwr_change(struct ufs_hba *hba,
 				  struct ufs_pa_layer_attr *dev_req_params)
 {
 	struct ufs_mtk_host *host = ufshcd_get_variant(hba);
-	struct ufs_dev_params host_cap;
+	struct ufs_host_params host_params;
 	int ret;
 
-	ufshcd_init_pwr_dev_param(&host_cap);
-	host_cap.hs_rx_gear = UFS_HS_G5;
-	host_cap.hs_tx_gear = UFS_HS_G5;
+	ufshcd_init_host_params(&host_params);
+	host_params.hs_rx_gear = UFS_HS_G5;
+	host_params.hs_tx_gear = UFS_HS_G5;
 
-	ret = ufshcd_get_pwr_dev_param(&host_cap,
-				       dev_max_params,
-				       dev_req_params);
+	ret = ufshcd_negotiate_pwr_params(&host_params, dev_max_params, dev_req_params);
 	if (ret) {
 		pr_info("%s: failed to determine capabilities\n",
 			__func__);
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 96cb8b5..197c5a5 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -898,7 +898,7 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
 				struct ufs_pa_layer_attr *dev_req_params)
 {
 	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
-	struct ufs_dev_params ufs_qcom_cap;
+	struct ufs_host_params host_params;
 	int ret = 0;
 
 	if (!dev_req_params) {
@@ -908,15 +908,13 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
 
 	switch (status) {
 	case PRE_CHANGE:
-		ufshcd_init_pwr_dev_param(&ufs_qcom_cap);
-		ufs_qcom_cap.hs_rate = UFS_QCOM_LIMIT_HS_RATE;
+		ufshcd_init_host_params(&host_params);
+		host_params.hs_rate = UFS_QCOM_LIMIT_HS_RATE;
 
 		/* This driver only supports symmetic gear setting i.e., hs_tx_gear == hs_rx_gear */
-		ufs_qcom_cap.hs_tx_gear = ufs_qcom_cap.hs_rx_gear = ufs_qcom_get_hs_gear(hba);
+		host_params.hs_tx_gear = host_params.hs_rx_gear = ufs_qcom_get_hs_gear(hba);
 
-		ret = ufshcd_get_pwr_dev_param(&ufs_qcom_cap,
-					       dev_max_params,
-					       dev_req_params);
+		ret = ufshcd_negotiate_pwr_params(&host_params, dev_max_params, dev_req_params);
 		if (ret) {
 			dev_err(hba->dev, "%s: failed to determine capabilities\n",
 					__func__);
diff --git a/drivers/ufs/host/ufshcd-pltfrm.c b/drivers/ufs/host/ufshcd-pltfrm.c
index da2558e..1633edc 100644
--- a/drivers/ufs/host/ufshcd-pltfrm.c
+++ b/drivers/ufs/host/ufshcd-pltfrm.c
@@ -285,61 +285,60 @@ static int ufshcd_parse_operating_points(struct ufs_hba *hba)
 }
 
 /**
- * ufshcd_get_pwr_dev_param - get finally agreed attributes for
- *                            power mode change
- * @pltfrm_param: pointer to platform parameters
+ * ufshcd_negotiate_pwr_params - find power mode settings that are supported by
+				both the controller and the device
+ * @host_params: pointer to host parameters
  * @dev_max: pointer to device attributes
  * @agreed_pwr: returned agreed attributes
  *
  * Return: 0 on success, non-zero value on failure.
  */
-int ufshcd_get_pwr_dev_param(const struct ufs_dev_params *pltfrm_param,
-			     const struct ufs_pa_layer_attr *dev_max,
-			     struct ufs_pa_layer_attr *agreed_pwr)
+int ufshcd_negotiate_pwr_params(const struct ufs_host_params *host_params,
+				const struct ufs_pa_layer_attr *dev_max,
+				struct ufs_pa_layer_attr *agreed_pwr)
 {
-	int min_pltfrm_gear;
+	int min_host_gear;
 	int min_dev_gear;
 	bool is_dev_sup_hs = false;
-	bool is_pltfrm_max_hs = false;
+	bool is_host_max_hs = false;
 
 	if (dev_max->pwr_rx == FAST_MODE)
 		is_dev_sup_hs = true;
 
-	if (pltfrm_param->desired_working_mode == UFS_HS_MODE) {
-		is_pltfrm_max_hs = true;
-		min_pltfrm_gear = min_t(u32, pltfrm_param->hs_rx_gear,
-					pltfrm_param->hs_tx_gear);
+	if (host_params->desired_working_mode == UFS_HS_MODE) {
+		is_host_max_hs = true;
+		min_host_gear = min_t(u32, host_params->hs_rx_gear,
+					host_params->hs_tx_gear);
 	} else {
-		min_pltfrm_gear = min_t(u32, pltfrm_param->pwm_rx_gear,
-					pltfrm_param->pwm_tx_gear);
+		min_host_gear = min_t(u32, host_params->pwm_rx_gear,
+					host_params->pwm_tx_gear);
 	}
 
 	/*
-	 * device doesn't support HS but
-	 * pltfrm_param->desired_working_mode is HS,
-	 * thus device and pltfrm_param don't agree
+	 * device doesn't support HS but host_params->desired_working_mode is HS,
+	 * thus device and host_params don't agree
 	 */
-	if (!is_dev_sup_hs && is_pltfrm_max_hs) {
+	if (!is_dev_sup_hs && is_host_max_hs) {
 		pr_info("%s: device doesn't support HS\n",
 			__func__);
 		return -ENOTSUPP;
-	} else if (is_dev_sup_hs && is_pltfrm_max_hs) {
+	} else if (is_dev_sup_hs && is_host_max_hs) {
 		/*
 		 * since device supports HS, it supports FAST_MODE.
-		 * since pltfrm_param->desired_working_mode is also HS
+		 * since host_params->desired_working_mode is also HS
 		 * then final decision (FAST/FASTAUTO) is done according
 		 * to pltfrm_params as it is the restricting factor
 		 */
-		agreed_pwr->pwr_rx = pltfrm_param->rx_pwr_hs;
+		agreed_pwr->pwr_rx = host_params->rx_pwr_hs;
 		agreed_pwr->pwr_tx = agreed_pwr->pwr_rx;
 	} else {
 		/*
-		 * here pltfrm_param->desired_working_mode is PWM.
+		 * here host_params->desired_working_mode is PWM.
 		 * it doesn't matter whether device supports HS or PWM,
-		 * in both cases pltfrm_param->desired_working_mode will
+		 * in both cases host_params->desired_working_mode will
 		 * determine the mode
 		 */
-		agreed_pwr->pwr_rx = pltfrm_param->rx_pwr_pwm;
+		agreed_pwr->pwr_rx = host_params->rx_pwr_pwm;
 		agreed_pwr->pwr_tx = agreed_pwr->pwr_rx;
 	}
 
@@ -349,9 +348,9 @@ int ufshcd_get_pwr_dev_param(const struct ufs_dev_params *pltfrm_param,
 	 * the same decision will be made for rx
 	 */
 	agreed_pwr->lane_tx = min_t(u32, dev_max->lane_tx,
-				    pltfrm_param->tx_lanes);
+				    host_params->tx_lanes);
 	agreed_pwr->lane_rx = min_t(u32, dev_max->lane_rx,
-				    pltfrm_param->rx_lanes);
+				    host_params->rx_lanes);
 
 	/* device maximum gear is the minimum between device rx and tx gears */
 	min_dev_gear = min_t(u32, dev_max->gear_rx, dev_max->gear_tx);
@@ -364,26 +363,26 @@ int ufshcd_get_pwr_dev_param(const struct ufs_dev_params *pltfrm_param,
 	 * what is the gear, as it is the one that also decided previously what
 	 * pwr the device will be configured to.
 	 */
-	if ((is_dev_sup_hs && is_pltfrm_max_hs) ||
-	    (!is_dev_sup_hs && !is_pltfrm_max_hs)) {
+	if ((is_dev_sup_hs && is_host_max_hs) ||
+	    (!is_dev_sup_hs && !is_host_max_hs)) {
 		agreed_pwr->gear_rx =
-			min_t(u32, min_dev_gear, min_pltfrm_gear);
+			min_t(u32, min_dev_gear, min_host_gear);
 	} else if (!is_dev_sup_hs) {
 		agreed_pwr->gear_rx = min_dev_gear;
 	} else {
-		agreed_pwr->gear_rx = min_pltfrm_gear;
+		agreed_pwr->gear_rx = min_host_gear;
 	}
 	agreed_pwr->gear_tx = agreed_pwr->gear_rx;
 
-	agreed_pwr->hs_rate = pltfrm_param->hs_rate;
+	agreed_pwr->hs_rate = host_params->hs_rate;
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(ufshcd_get_pwr_dev_param);
+EXPORT_SYMBOL_GPL(ufshcd_negotiate_pwr_params);
 
-void ufshcd_init_pwr_dev_param(struct ufs_dev_params *dev_param)
+void ufshcd_init_host_params(struct ufs_host_params *host_params)
 {
-	*dev_param = (struct ufs_dev_params){
+	*host_params = (struct ufs_host_params){
 		.tx_lanes = UFS_LANE_2,
 		.rx_lanes = UFS_LANE_2,
 		.hs_rx_gear = UFS_HS_G3,
@@ -398,7 +397,7 @@ void ufshcd_init_pwr_dev_param(struct ufs_dev_params *dev_param)
 		.desired_working_mode = UFS_HS_MODE,
 	};
 }
-EXPORT_SYMBOL_GPL(ufshcd_init_pwr_dev_param);
+EXPORT_SYMBOL_GPL(ufshcd_init_host_params);
 
 /**
  * ufshcd_pltfrm_init - probe routine of the driver
diff --git a/drivers/ufs/host/ufshcd-pltfrm.h b/drivers/ufs/host/ufshcd-pltfrm.h
index a86a3ad..df387be 100644
--- a/drivers/ufs/host/ufshcd-pltfrm.h
+++ b/drivers/ufs/host/ufshcd-pltfrm.h
@@ -10,7 +10,7 @@
 #define UFS_PWM_MODE 1
 #define UFS_HS_MODE  2
 
-struct ufs_dev_params {
+struct ufs_host_params {
 	u32 pwm_rx_gear;        /* pwm rx gear to work in */
 	u32 pwm_tx_gear;        /* pwm tx gear to work in */
 	u32 hs_rx_gear;         /* hs rx gear to work in */
@@ -25,10 +25,10 @@ struct ufs_dev_params {
 	u32 desired_working_mode;
 };
 
-int ufshcd_get_pwr_dev_param(const struct ufs_dev_params *dev_param,
-			     const struct ufs_pa_layer_attr *dev_max,
-			     struct ufs_pa_layer_attr *agreed_pwr);
-void ufshcd_init_pwr_dev_param(struct ufs_dev_params *dev_param);
+int ufshcd_negotiate_pwr_params(const struct ufs_host_params *host_params,
+				const struct ufs_pa_layer_attr *dev_max,
+				struct ufs_pa_layer_attr *agreed_pwr);
+void ufshcd_init_host_params(struct ufs_host_params *host_params);
 int ufshcd_pltfrm_init(struct platform_device *pdev,
 		       const struct ufs_hba_variant_ops *vops);
 int ufshcd_populate_vreg(struct device *dev, const char *name,
-- 
2.7.4



From knaerzche at gmail.com  Sat Dec  2 04:41:57 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 13:41:57 +0100
Subject: [PATCH v2 0/2] Add GMAC for RK3128
Message-ID: <20231202124158.65615-2-knaerzche@gmail.com>

RK3128's GMAC is already supported by the Rockchip's glue for dwmac
driver, so this series basically adds the respective nodes in the SoC DT
and the enablements for XPI-3128 board.

Note: These patches are based on maintainers repo.

Changes in v2:
 - use phy reset-timings according to the datasheet
 - added rx-fifo-depth and rx-fifo-depth for gmac

Alex Bee (2):
  ARM: dts: rockchip: Add gmac node for RK3128
  ARM: dts: rockchip: Enable gmac for XPI-3128

 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 28 +++++++++++++++++++
 arch/arm/boot/dts/rockchip/rk3128.dtsi        | 28 +++++++++++++++++++
 2 files changed, 56 insertions(+)


base-commit: fd610e604837936440ef7c64ab6998b004631647
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 04:41:58 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 13:41:58 +0100
Subject: [PATCH v2 1/2] ARM: dts: rockchip: Add gmac node for RK3128
In-Reply-To: <20231202124158.65615-2-knaerzche@gmail.com>
References: <20231202124158.65615-2-knaerzche@gmail.com>
Message-ID: <20231202124158.65615-3-knaerzche@gmail.com>

RK3128's gmac is based on Synopsys Ethernet GMAC IP core.
Add it to the devicetree.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128.dtsi | 28 ++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 4e8b38604ecd..c0c9f0eaffa3 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -525,6 +525,34 @@ pdma: dma-controller at 20078000 {
 		#dma-cells = <1>;
 	};
 
+	gmac: ethernet at 2008c000 {
+		compatible = "rockchip,rk3128-gmac";
+		reg = <0x2008c000 0x4000>;
+		interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "macirq", "eth_wake_irq";
+		clocks = <&cru SCLK_MAC>,
+			 <&cru SCLK_MAC_RX>, <&cru SCLK_MAC_TX>,
+			 <&cru SCLK_MAC_REF>, <&cru SCLK_MAC_REFOUT>,
+			 <&cru ACLK_GMAC>, <&cru PCLK_GMAC>;
+		clock-names = "stmmaceth",
+			      "mac_clk_rx", "mac_clk_tx",
+			      "clk_mac_ref", "clk_mac_refout",
+			      "aclk_mac", "pclk_mac";
+		resets = <&cru SRST_GMAC>;
+		reset-names = "stmmaceth";
+		rockchip,grf = <&grf>;
+		rx-fifo-depth = <4096>;
+		tx-fifo-depth = <2048>;
+		status = "disabled";
+
+		mdio: mdio {
+			compatible = "snps,dwmac-mdio";
+			#address-cells = <0x1>;
+			#size-cells = <0x0>;
+		};
+	};
+
 	pinctrl: pinctrl {
 		compatible = "rockchip,rk3128-pinctrl";
 		rockchip,grf = <&grf>;
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 04:41:59 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 13:41:59 +0100
Subject: [PATCH v2 2/2] ARM: dts: rockchip: Enable gmac for XPI-3128
In-Reply-To: <20231202124158.65615-2-knaerzche@gmail.com>
References: <20231202124158.65615-2-knaerzche@gmail.com>
Message-ID: <20231202124158.65615-4-knaerzche@gmail.com>

Add the required properties and enable the gmac node for XPI-3128 board.

The minimum reset timing requirements for the phy have been taken from
DP83848J's datasheet [0]

[0] https://www.ti.com/lit/ds/symlink/dp83848j.pdf

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index 61b9f069c8a2..e979425f11a0 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -11,6 +11,7 @@ / {
 	compatible = "geniatech,xpi-3128", "rockchip,rk3128";
 
 	aliases {
+		ethernet0 = &gmac;
 		gpio0 = &gpio0;
 		gpio1 = &gpio1;
 		gpio2 = &gpio2;
@@ -255,6 +256,18 @@ &emmc {
 	status = "okay";
 };
 
+&gmac {
+	clock_in_out = "output";
+	phy-supply = <&vcc_lan>;
+	phy-mode = "rmii";
+	phy-handle = <&phy0>;
+	assigned-clocks = <&cru SCLK_MAC_SRC>;
+	assigned-clock-rates= <50000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rmii_pins>;
+	status = "okay";
+};
+
 &gpio0 {
 	gpio-line-names = /* GPIO0 A0-A7 */
 			  "", "", "HEADER_5", "HEADER_3",
@@ -315,6 +328,21 @@ &gpio3 {
 			  "", "", "", "";
 };
 
+&mdio {
+	phy0: ethernet-phy at 1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+		max-speed = <100>;
+		/* T2.2.4 min. 1 us */
+		reset-assert-us = <10>;
+		/* T2.2.1 + T2.2.2 + T2.2.3 min. 6.05 us */
+		reset-deassert-us = <20>;
+		reset-gpios = <&gpio2 RK_PD0 GPIO_ACTIVE_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&dp83848c_rst>;
+	};
+};
+
 &pinctrl {
 	dp83848c {
 		dp83848c_rst: dp83848c-rst {
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 04:51:39 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 13:51:39 +0100
Subject: [PATCH v2 0/5] Add power-controller and gpu for RK3128
Message-ID: <20231202125144.66052-1-knaerzche@gmail.com>

The first patch in this series fixes the pm-domain driver and adds
power-domains which are currently missing. This touches the ABI which is
not and was never used until now. Not all of them are used yet, but when
the power-controller is added to the DT in patch 2 the ABI should not
be changed again.
Patch 3-5 are adding the the gpu compatible to dt-bindings, adding the gpu
node and the respective operating points to SoC DT and finally enabling it
for XPI-3128 board.

Note: DT patches are based on maintainer's repo.

Alex Bee (5):
  pmdomain: rockchip: Add missing powerdomains for RK3128
  ARM: dts: rockchip: Add power-controller for RK3128
  dt-bindings: gpu: mali-utgard: Add Rockchip RK3128 compatible
  ARM: dts: rockchip: Add GPU node for RK3128
  ARM: dts: rockchip: Enable GPU for XPI-3128

 .../bindings/gpu/arm,mali-utgard.yaml         |   1 +
 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts |   5 +
 arch/arm/boot/dts/rockchip/rk3128.dtsi        | 145 ++++++++++++++++++
 drivers/pmdomain/rockchip/pm-domains.c        |  13 +-
 include/dt-bindings/power/rk3128-power.h      |   3 +
 5 files changed, 162 insertions(+), 5 deletions(-)


base-commit: fd610e604837936440ef7c64ab6998b004631647
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 04:51:40 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 13:51:40 +0100
Subject: [PATCH v2 1/5] pmdomain: rockchip: Add missing powerdomains for RK3128
In-Reply-To: <20231202125144.66052-1-knaerzche@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com>
Message-ID: <20231202125144.66052-2-knaerzche@gmail.com>

For RK3128 the powerdomains PD_PERI, PD_SYS and PD_CRYPTO are currently
missing.
Add them.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 drivers/pmdomain/rockchip/pm-domains.c   | 13 ++++++++-----
 include/dt-bindings/power/rk3128-power.h |  3 +++
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
index 9b76b62869d0..62ba4129f6bb 100644
--- a/drivers/pmdomain/rockchip/pm-domains.c
+++ b/drivers/pmdomain/rockchip/pm-domains.c
@@ -998,11 +998,14 @@ static const struct rockchip_domain_info rk3066_pm_domains[] = {
 };
 
 static const struct rockchip_domain_info rk3128_pm_domains[] = {
-	[RK3128_PD_CORE]	= DOMAIN_RK3288("core",  BIT(0), BIT(0), BIT(4), false),
-	[RK3128_PD_MSCH]	= DOMAIN_RK3288("msch",  0,      0,      BIT(6), true),
-	[RK3128_PD_VIO]		= DOMAIN_RK3288("vio",   BIT(3), BIT(3), BIT(2), false),
-	[RK3128_PD_VIDEO]	= DOMAIN_RK3288("video", BIT(2), BIT(2), BIT(1), false),
-	[RK3128_PD_GPU]		= DOMAIN_RK3288("gpu",   BIT(1), BIT(1), BIT(3), false),
+	[RK3128_PD_CORE]	= DOMAIN_RK3288("core",   BIT(0), BIT(0), BIT(4), false),
+	[RK3128_PD_MSCH]	= DOMAIN_RK3288("msch",   0,      0,      BIT(6), true),
+	[RK3128_PD_VIO]		= DOMAIN_RK3288("vio",    BIT(3), BIT(3), BIT(2), false),
+	[RK3128_PD_VIDEO]	= DOMAIN_RK3288("video",  BIT(2), BIT(2), BIT(1), false),
+	[RK3128_PD_GPU]		= DOMAIN_RK3288("gpu",    BIT(1), BIT(1), BIT(3), false),
+	[RK3128_PD_PERI]	= DOMAIN_RK3288("peri",   0,      0,      BIT(0), false),
+	[RK3128_PD_SYS]		= DOMAIN_RK3288("sys",    0,      0,      BIT(5), true),
+	[RK3128_PD_CRYPTO]	= DOMAIN_RK3288("crypto", 0,      0,      BIT(7), false),
 };
 
 static const struct rockchip_domain_info rk3188_pm_domains[] = {
diff --git a/include/dt-bindings/power/rk3128-power.h b/include/dt-bindings/power/rk3128-power.h
index c051dc3108db..68af6c68c272 100644
--- a/include/dt-bindings/power/rk3128-power.h
+++ b/include/dt-bindings/power/rk3128-power.h
@@ -10,5 +10,8 @@
 #define RK3128_PD_VIDEO		2
 #define RK3128_PD_GPU		3
 #define RK3128_PD_MSCH		4
+#define RK3128_PD_PERI		5
+#define RK3128_PD_SYS		6
+#define RK3128_PD_CRYPTO	7
 
 #endif
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 04:51:43 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 13:51:43 +0100
Subject: [PATCH v2 4/5] ARM: dts: rockchip: Add GPU node for RK3128
In-Reply-To: <20231202125144.66052-1-knaerzche@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com>
Message-ID: <20231202125144.66052-5-knaerzche@gmail.com>

RK3128 SoCs have Mali400 MP2 GPU.
Add the respective device tree node and the correspondending opp-table.

The frequencies and voltages of the opp-table have been taken from
downstream kernel.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128.dtsi | 44 ++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index b72905db04f7..b05ee3d926aa 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -101,6 +101,27 @@ opp-1200000000 {
 		};
 	};
 
+	gpu_opp_table: opp-table-1 {
+		compatible = "operating-points-v2";
+
+		opp-200000000 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <975000 975000 1250000>;
+		};
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+			opp-microvolt = <1050000 1050000 1250000>;
+		};
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <1150000 1150000 1250000>;
+		};
+		opp-480000000 {
+			opp-hz = /bits/ 64 <480000000>;
+			opp-microvolt = <1250000 1250000 1250000>;
+		};
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
@@ -131,6 +152,29 @@ smp-sram at 0 {
 		};
 	};
 
+	gpu: gpu at 10090000 {
+		compatible = "rockchip,rk3128-mali", "arm,mali-400";
+		reg = <0x10090000 0x10000>;
+		interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp",
+				  "gpmmu",
+				  "pp0",
+				  "ppmmu0",
+				  "pp1",
+				  "ppmmu1";
+		clocks = <&cru ACLK_GPU>, <&cru ACLK_GPU>;
+		clock-names = "bus", "core";
+		power-domains = <&power RK3128_PD_GPU>;
+		resets = <&cru SRST_GPU>;
+		operating-points-v2 = <&gpu_opp_table>;
+		status = "disabled";
+	};
+
 	pmu: syscon at 100a0000 {
 		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
 		reg = <0x100a0000 0x1000>;
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 04:51:42 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 13:51:42 +0100
Subject: [PATCH v2 3/5] dt-bindings: gpu: mali-utgard: Add Rockchip RK3128 compatible
In-Reply-To: <20231202125144.66052-1-knaerzche@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com>
Message-ID: <20231202125144.66052-4-knaerzche@gmail.com>

Rockchip RK312x SoC family has a Mali400 MP2.
Add a compatible for it.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
index 0fae1ef013be..abd4aa335fbc 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
@@ -29,6 +29,7 @@ properties:
               - allwinner,sun50i-a64-mali
               - rockchip,rk3036-mali
               - rockchip,rk3066-mali
+              - rockchip,rk3128-mali
               - rockchip,rk3188-mali
               - rockchip,rk3228-mali
               - samsung,exynos4210-mali
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 04:51:41 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 13:51:41 +0100
Subject: [PATCH v2 2/5] ARM: dts: rockchip: Add power-controller for RK3128
In-Reply-To: <20231202125144.66052-1-knaerzche@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com>
Message-ID: <20231202125144.66052-3-knaerzche@gmail.com>

Add power controller and qos nodes for RK3128 in order to use
them as powerdomains.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128.dtsi | 101 +++++++++++++++++++++++++
 1 file changed, 101 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 4e8b38604ecd..b72905db04f7 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -8,6 +8,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/power/rk3128-power.h>
 
 / {
 	compatible = "rockchip,rk3128";
@@ -133,6 +134,106 @@ smp-sram at 0 {
 	pmu: syscon at 100a0000 {
 		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
 		reg = <0x100a0000 0x1000>;
+
+		power: power-controller {
+			compatible = "rockchip,rk3128-power-controller";
+			#power-domain-cells = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			power-domain at RK3128_PD_VIO {
+				reg = <RK3128_PD_VIO>;
+				clocks = <&cru ACLK_CIF>,
+					 <&cru HCLK_CIF>,
+					 <&cru DCLK_EBC>,
+					 <&cru HCLK_EBC>,
+					 <&cru ACLK_IEP>,
+					 <&cru HCLK_IEP>,
+					 <&cru ACLK_LCDC0>,
+					 <&cru HCLK_LCDC0>,
+					 <&cru PCLK_MIPI>,
+					 <&cru ACLK_RGA>,
+					 <&cru HCLK_RGA>,
+					 <&cru ACLK_VIO0>,
+					 <&cru ACLK_VIO1>,
+					 <&cru HCLK_VIO>,
+					 <&cru HCLK_VIO_H2P>,
+					 <&cru DCLK_VOP>,
+					 <&cru SCLK_VOP>;
+				pm_qos = <&qos_ebc>,
+					 <&qos_iep>,
+					 <&qos_lcdc>,
+					 <&qos_rga>,
+					 <&qos_vip>;
+				#power-domain-cells = <0>;
+			};
+
+			power-domain at RK3128_PD_VIDEO {
+				reg = <RK3128_PD_VIDEO>;
+				clocks = <&cru ACLK_VDPU>,
+					 <&cru HCLK_VDPU>,
+					 <&cru ACLK_VEPU>,
+					 <&cru HCLK_VEPU>,
+					 <&cru SCLK_HEVC_CORE>;
+				pm_qos = <&qos_vpu>;
+				#power-domain-cells = <0>;
+			};
+
+			power-domain at RK3128_PD_GPU {
+				reg = <RK3128_PD_GPU>;
+				clocks = <&cru ACLK_GPU>;
+				pm_qos = <&qos_gpu>;
+				#power-domain-cells = <0>;
+			};
+
+			power-domain at RK3128_PD_CRYPTO {
+				reg = <RK3128_PD_CRYPTO>;
+				clocks = <&cru HCLK_CRYPTO>,
+					 <&cru SCLK_CRYPTO>;
+				pm_qos = <&qos_crypto>;
+				#power-domain-cells = <0>;
+			};
+		};
+	};
+
+	qos_crypto: qos at 10128080 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x10128080 0x20>;
+	};
+
+	qos_gpu: qos at 1012d000 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012d000 0x20>;
+	};
+
+	qos_vpu: qos at 1012e000 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012e000 0x20>;
+	};
+
+	qos_rga: qos at 1012f000 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f000 0x20>;
+	};
+
+	qos_ebc: qos at 1012f080 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f080 0x20>;
+	};
+
+	qos_iep: qos at 1012f100 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f100 0x20>;
+	};
+
+	qos_lcdc: qos at 1012f180 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f180 0x20>;
+	};
+
+	qos_vip: qos at 1012f200 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f200 0x20>;
 	};
 
 	gic: interrupt-controller at 10139000 {
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 04:51:44 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 13:51:44 +0100
Subject: [PATCH v2 5/5] ARM: dts: rockchip: Enable GPU for XPI-3128
In-Reply-To: <20231202125144.66052-1-knaerzche@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com>
Message-ID: <20231202125144.66052-6-knaerzche@gmail.com>

Add the supply and enable gpu node for XPI-3128 board.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index 61b9f069c8a2..0a8ead0bfe09 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -315,6 +315,11 @@ &gpio3 {
 			  "", "", "", "";
 };
 
+&gpu {
+	mali-supply = <&vdd_log>;
+	status = "okay";
+};
+
 &pinctrl {
 	dp83848c {
 		dp83848c_rst: dp83848c-rst {
-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Sat Dec  2 05:04:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 2 Dec 2023 14:04:32 +0100
Subject: [PATCH v3] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <20231201-thrive-gully-5260ab07b352@spud>
References: <20231125184422.12315-1-krzysztof.kozlowski@linaro.org>
 <20231201-thrive-gully-5260ab07b352@spud>
Message-ID: <695b4402-5e0f-4b4b-9848-16d8f8956cf4@linaro.org>

On 01/12/2023 17:46, Conor Dooley wrote:
> On Sat, Nov 25, 2023 at 07:44:22PM +0100, Krzysztof Kozlowski wrote:
>> +Indentation
>> +-----------
>> +
>> +1. Use indentation according to :ref:`codingstyle`.
> 
> One thing Jonathan mentioned before to me was to drop this :ref: stuff.
> | > +:ref:`devicetree-abi` more information on the ABI.
> | 
> | ...can just be written as "Please see
> | Documentation/devicetree/bindings/ABI.rst".  The cross-reference link
> | will be generated as expected, and readers of the plain-text docs don't
> | have to go grepping to find the reference.
> https://lore.kernel.org/all/87bki23rbx.fsf at meer.lwn.net/
> 

Sure, indeed it's better for plain-text readers.

Best regards,
Krzysztof



From knaerzche at gmail.com  Sat Dec  2 05:05:07 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 14:05:07 +0100
Subject: [PATCH] ARM: dts: rockchip: Move uart aliases to SoC dtsi for RK3128
In-Reply-To: <20231202130506.66738-2-knaerzche@gmail.com>
References: <20231202130506.66738-2-knaerzche@gmail.com>
Message-ID: <20231202130506.66738-5-knaerzche@gmail.com>

SoC TRM, SoC datasheet and board schematics always refer to the
same uart numbers - even if not all are used for a specific board.
In order to not have to re-define them for every board move the
aliases to SoC dtsi for RK3128 like it's being done for all other
Rockchip ARM SoCs.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 3 +--
 arch/arm/boot/dts/rockchip/rk3128.dtsi         | 3 +++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index b448e2b96e08..6e46e839de39 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -13,7 +13,6 @@ / {
 	aliases {
 		mmc0 = &emmc;
 		mmc1 = &sdmmc;
-		serial0 = &uart1;
 	};
 
 	memory at 60000000 {
@@ -22,7 +21,7 @@ memory at 60000000 {
 	};
 
 	chosen {
-		stdout-path = "serial0:115200n8";
+		stdout-path = &uart1;
 	};
 
 	adc-keys {
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index dc149d98cf9e..edf90ebd7ff9 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -24,6 +24,9 @@ aliases {
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
 		i2c3 = &i2c3;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
 	};
 
 	arm-pmu {
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 05:05:05 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 14:05:05 +0100
Subject: [PATCH 1/3] ARM: dts: rockchip: Move gpio aliases to SoC dtsi for RK3128
In-Reply-To: <20231202130506.66738-2-knaerzche@gmail.com>
References: <20231202130506.66738-2-knaerzche@gmail.com>
Message-ID: <20231202130506.66738-3-knaerzche@gmail.com>

SoC TRM, SoC datasheet and board schematics always refer to the
same gpio numbers - even if not all are used for a specific board.
In order to not have to re-define them for every board move the
aliases to SoC dtsi for RK3128 like it's being done for most other
Rockchip ARM SoCs.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128-evb.dts      | 4 ----
 arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 4 ----
 arch/arm/boot/dts/rockchip/rk3128.dtsi         | 7 +++++++
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-evb.dts b/arch/arm/boot/dts/rockchip/rk3128-evb.dts
index c38f42497cbd..776a483cc26b 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-evb.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-evb.dts
@@ -12,10 +12,6 @@ / {
 	compatible = "rockchip,rk3128-evb", "rockchip,rk3128";
 
 	aliases {
-		gpio0 = &gpio0;
-		gpio1 = &gpio1;
-		gpio2 = &gpio2;
-		gpio3 = &gpio3;
 		i2c1 = &i2c1;
 		mmc0 = &emmc;
 	};
diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index 61b9f069c8a2..b448e2b96e08 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -11,10 +11,6 @@ / {
 	compatible = "geniatech,xpi-3128", "rockchip,rk3128";
 
 	aliases {
-		gpio0 = &gpio0;
-		gpio1 = &gpio1;
-		gpio2 = &gpio2;
-		gpio3 = &gpio3;
 		mmc0 = &emmc;
 		mmc1 = &sdmmc;
 		serial0 = &uart1;
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 4e8b38604ecd..5b751284d6ca 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -15,6 +15,13 @@ / {
 	#address-cells = <1>;
 	#size-cells = <1>;
 
+	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+	};
+
 	arm-pmu {
 		compatible = "arm,cortex-a7-pmu";
 		interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 05:05:04 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 14:05:04 +0100
Subject: [PATCH 0/3] Move core bus and gpio aliases to SoC dtsi for RK3128
Message-ID: <20231202130506.66738-2-knaerzche@gmail.com>

Following up the recent discussion [0] about where aliases can be/should be
placed this series moves gpio, i2c and uart aliases to SoC dtsi for RK3128.

Note: This patches are based on maintainter's repo.

[0] https://lore.kernel.org/all/b0c637f5-5abf-420b-8b02-839eba68799e at linaro.org/T/#m94aebb23a29b015d94b250a70b675febdaa902ea

Alex Bee (3):
  ARM: dts: rockchip: Move gpio aliases to SoC dtsi for RK3128
  ARM: dts: rockchip: Move i2c aliases to SoC dtsi for RK3128
  ARM: dts: rockchip: Move uart aliases to SoC dtsi for RK3128

 arch/arm/boot/dts/rockchip/rk3128-evb.dts      |  5 -----
 arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts |  7 +------
 arch/arm/boot/dts/rockchip/rk3128.dtsi         | 14 ++++++++++++++
 3 files changed, 15 insertions(+), 11 deletions(-)


base-commit: fd610e604837936440ef7c64ab6998b004631647
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec  2 05:05:06 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat,  2 Dec 2023 14:05:06 +0100
Subject: [PATCH 2/3] ARM: dts: rockchip: Move i2c aliases to SoC dtsi for RK3128
In-Reply-To: <20231202130506.66738-2-knaerzche@gmail.com>
References: <20231202130506.66738-2-knaerzche@gmail.com>
Message-ID: <20231202130506.66738-4-knaerzche@gmail.com>

SoC TRM, SoC datasheet and board schematics always refer to the
same i2c numbers - even if not all are used for a specific board.
In order to not have to re-define them for every board move the
aliases to SoC dtsi for RK3128 like it's being done for all other
Rockchip ARM SoCs.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128-evb.dts | 1 -
 arch/arm/boot/dts/rockchip/rk3128.dtsi    | 4 ++++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-evb.dts b/arch/arm/boot/dts/rockchip/rk3128-evb.dts
index 776a483cc26b..c7ab7fcdb436 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-evb.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-evb.dts
@@ -12,7 +12,6 @@ / {
 	compatible = "rockchip,rk3128-evb", "rockchip,rk3128";
 
 	aliases {
-		i2c1 = &i2c1;
 		mmc0 = &emmc;
 	};
 
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 5b751284d6ca..dc149d98cf9e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -20,6 +20,10 @@ aliases {
 		gpio1 = &gpio1;
 		gpio2 = &gpio2;
 		gpio3 = &gpio3;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
 	};
 
 	arm-pmu {
-- 
2.43.0



From willemdebruijn.kernel at gmail.com  Sat Dec  2 06:15:42 2023
From: willemdebruijn.kernel at gmail.com (Willem de Bruijn)
Date: Sat, 02 Dec 2023 09:15:42 -0500
Subject: [PATCH bpf-next v2 0/3] xsk: TX metadata txtime support
In-Reply-To: <179a4581-f7df-4eb1-ab67-8d65f856a2fe@kernel.org>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <d4f99931-442c-4cd7-b3cf-80d8681a2986@kernel.org>
 <PH0PR11MB58306C2E50009A6E22F9DAD3D881A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <6569f71bad00d_138af5294d@willemb.c.googlers.com.notmuch>
 <179a4581-f7df-4eb1-ab67-8d65f856a2fe@kernel.org>
Message-ID: <656b3c0ebb103_1a6a2c2947d@willemb.c.googlers.com.notmuch>

Jesper Dangaard Brouer wrote:
> 
> 
> On 12/1/23 16:09, Willem de Bruijn wrote:
> > Song, Yoong Siang wrote:
> >> On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer <hawk at kernel.org> wrote:
> >>> On 12/1/23 07:24, Song Yoong Siang wrote:
> >>>> This series expands XDP TX metadata framework to include ETF HW offload.
> >>>>
> >>>> Changes since v1:
> >>>> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF)
> >>>> - rename launch-time to txtime
> >>>>
> >>>
> >>> I strongly disagree with this renaming (sorry to disagree with Willem).
> >>>
> >>> The i210 and i225 chips call this LaunchTime in their programmers
> >>> datasheets, and even in the driver code[1].
> >>>
> >>> Using this "txtime" name in the code is also confusing, because how can
> >>> people reading the code know the difference between:
> >>>   - tmo_request_timestamp and tmo_request_txtime
> >>>
> >>
> >> Hi Jesper and Willem,
> >>
> >> How about using "launch_time" for the flag/variable and
> >> "Earliest TxTime First" for the description/comments?
> > 
> 
> I don't follow why you are calling the feature:
>   - "Earliest TxTime First" (ETF).
>   - AFAIK this just reference an qdisc name (that most don't know exists)
> 
> 
> > I don't particularly care which term we use, as long as we're
> > consistent. Especially, don't keep introducing new synonyms.
> > 
> > The fact that one happens to be one vendor's marketing term does not
> > make it preferable, IMHO. On the contrary.
> >
> 
> These kind of hardware features are defined as part of Time Sensitive
> Networking (TSN).
> I believe these TSN features are defined as part of IEEE 802.1Qbv (2015)
> and according to Wikipedia[2] incorporated into IEEE 802.1Q.
> 
> [2] https://en.wikipedia.org/wiki/Time-Sensitive_Networking
> 
> 
> > SO_TXTIME is in the ABI, and EDT has been used publicly in kernel
> > patches and conference talks, e.g., Van Jacobson's Netdev 0x12
> > keynote. Those are vendor agnostic commonly used terms.
> > 
> 
> I agree that EDT (Earliest Departure Time) have become a thing and term
> in our community.
> We could associate this feature with this.
> I do fear what hardware behavior will be it if I e.g. ask it to send a
> packet 2 sec in the future on i225 which max support 1 sec.
> Will hardware send it at 1 sec?
> Because then I'm violating the *Earliest* Departure Time.

That should definitely not happen. At least not on a device that
implements EDT semantics.

This relates to Jakub's question in the previous thread on whether
this mechanism allows out-of-order transmission or maintains FIFO
behavior. That really is device specific.

Older devices only support this for low rate (PTP) and with a small
fixed number of outstanding requests. For pacing offload, devices need
to support up to linerate and out-of-order.

I don't think we want to enforce either in software, as the hardware
is already out there. But it would be good if drivers can somehow
label these capabilities. Including programmable horizon.

It is up to the qdisc to ensure that it does not pass packets to the
device beyond its horizon.

ETF and FQ already have a concept of horizon. And a way to queue
errors for packets out of bound (SO_EE_CODE_TXTIME_..).

> 
> > But as long as Launch Time is not an Intel only trademark, fine to
> > select that.
> 
> The IEEE 802.1Qbv is sometimes called Time-Aware Shaper (TAS), but I
> don't like to for us to name this after this.  This features is simply
> taking advantage of exposing one of the hardware building blocks
> (controlling/setting packet "launch time") that can be used for
> implementing a TAS.
> 
> I like the name "launch time" because it doesn't get easily confused
> with other timestamps, and intuitively describes packet will be send at
> a specific time (likely in future).
> 
> --Jesper

Understood on your point that txtime and tx_timestamp are too similar.
As said, I don't care strongly. Launch time sounds fine to me. Others
can speak up if they disagree.

I take launch time as a less strict than EDT: it is a request to send
at a certain time, with no strict definition on uncertainty. While EDT
more strictly ensures that a packet is not sent before the timestamp.


From heiko at sntech.de  Sat Dec  2 07:51:56 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sat, 02 Dec 2023 16:51:56 +0100
Subject: [PATCH v2 2/5] ARM: dts: rockchip: Add power-controller for RK3128
In-Reply-To: <20231202125144.66052-3-knaerzche@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com>
 <20231202125144.66052-3-knaerzche@gmail.com>
Message-ID: <6926340.F8r316W7xa@diego>

Hi Alex,

Am Samstag, 2. Dezember 2023, 13:51:41 CET schrieb Alex Bee:
> Add power controller and qos nodes for RK3128 in order to use
> them as powerdomains.

does the power-domain controller work with the incomplete set of
pm-domains too?

What I have in mind is
- adding the power-controller node with the existing set of power-domains
- the gpu pm-domain is in there
- adding the gpu parts


And a second series with
- patch1 from here
- a dts patch adding the additional pm-domains to rk3128.dtsi
- I guess patch1 also should be split into a patch adding the binding-ids
  and a separate patch for the code addition.


Heiko

> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> ---
>  arch/arm/boot/dts/rockchip/rk3128.dtsi | 101 +++++++++++++++++++++++++
>  1 file changed, 101 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
> index 4e8b38604ecd..b72905db04f7 100644
> --- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
> @@ -8,6 +8,7 @@
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>  #include <dt-bindings/interrupt-controller/irq.h>
>  #include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/power/rk3128-power.h>
>  
>  / {
>  	compatible = "rockchip,rk3128";
> @@ -133,6 +134,106 @@ smp-sram at 0 {
>  	pmu: syscon at 100a0000 {
>  		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
>  		reg = <0x100a0000 0x1000>;
> +
> +		power: power-controller {
> +			compatible = "rockchip,rk3128-power-controller";
> +			#power-domain-cells = <1>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			power-domain at RK3128_PD_VIO {
> +				reg = <RK3128_PD_VIO>;
> +				clocks = <&cru ACLK_CIF>,
> +					 <&cru HCLK_CIF>,
> +					 <&cru DCLK_EBC>,
> +					 <&cru HCLK_EBC>,
> +					 <&cru ACLK_IEP>,
> +					 <&cru HCLK_IEP>,
> +					 <&cru ACLK_LCDC0>,
> +					 <&cru HCLK_LCDC0>,
> +					 <&cru PCLK_MIPI>,
> +					 <&cru ACLK_RGA>,
> +					 <&cru HCLK_RGA>,
> +					 <&cru ACLK_VIO0>,
> +					 <&cru ACLK_VIO1>,
> +					 <&cru HCLK_VIO>,
> +					 <&cru HCLK_VIO_H2P>,
> +					 <&cru DCLK_VOP>,
> +					 <&cru SCLK_VOP>;
> +				pm_qos = <&qos_ebc>,
> +					 <&qos_iep>,
> +					 <&qos_lcdc>,
> +					 <&qos_rga>,
> +					 <&qos_vip>;
> +				#power-domain-cells = <0>;
> +			};
> +
> +			power-domain at RK3128_PD_VIDEO {
> +				reg = <RK3128_PD_VIDEO>;
> +				clocks = <&cru ACLK_VDPU>,
> +					 <&cru HCLK_VDPU>,
> +					 <&cru ACLK_VEPU>,
> +					 <&cru HCLK_VEPU>,
> +					 <&cru SCLK_HEVC_CORE>;
> +				pm_qos = <&qos_vpu>;
> +				#power-domain-cells = <0>;
> +			};
> +
> +			power-domain at RK3128_PD_GPU {
> +				reg = <RK3128_PD_GPU>;
> +				clocks = <&cru ACLK_GPU>;
> +				pm_qos = <&qos_gpu>;
> +				#power-domain-cells = <0>;
> +			};
> +
> +			power-domain at RK3128_PD_CRYPTO {
> +				reg = <RK3128_PD_CRYPTO>;
> +				clocks = <&cru HCLK_CRYPTO>,
> +					 <&cru SCLK_CRYPTO>;
> +				pm_qos = <&qos_crypto>;
> +				#power-domain-cells = <0>;
> +			};
> +		};
> +	};
> +
> +	qos_crypto: qos at 10128080 {
> +		compatible = "rockchip,rk3128-qos", "syscon";
> +		reg = <0x10128080 0x20>;
> +	};
> +
> +	qos_gpu: qos at 1012d000 {
> +		compatible = "rockchip,rk3128-qos", "syscon";
> +		reg = <0x1012d000 0x20>;
> +	};
> +
> +	qos_vpu: qos at 1012e000 {
> +		compatible = "rockchip,rk3128-qos", "syscon";
> +		reg = <0x1012e000 0x20>;
> +	};
> +
> +	qos_rga: qos at 1012f000 {
> +		compatible = "rockchip,rk3128-qos", "syscon";
> +		reg = <0x1012f000 0x20>;
> +	};
> +
> +	qos_ebc: qos at 1012f080 {
> +		compatible = "rockchip,rk3128-qos", "syscon";
> +		reg = <0x1012f080 0x20>;
> +	};
> +
> +	qos_iep: qos at 1012f100 {
> +		compatible = "rockchip,rk3128-qos", "syscon";
> +		reg = <0x1012f100 0x20>;
> +	};
> +
> +	qos_lcdc: qos at 1012f180 {
> +		compatible = "rockchip,rk3128-qos", "syscon";
> +		reg = <0x1012f180 0x20>;
> +	};
> +
> +	qos_vip: qos at 1012f200 {
> +		compatible = "rockchip,rk3128-qos", "syscon";
> +		reg = <0x1012f200 0x20>;
>  	};
>  
>  	gic: interrupt-controller at 10139000 {
> 






From heiko at sntech.de  Sat Dec  2 07:57:18 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sat,  2 Dec 2023 16:57:18 +0100
Subject: (subset) [PATCH v2 0/5] Add power-controller and gpu for RK3128
In-Reply-To: <20231202125144.66052-1-knaerzche@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com>
Message-ID: <170153263025.376455.12737085983971621612.b4-ty@sntech.de>

On Sat, 2 Dec 2023 13:51:39 +0100, Alex Bee wrote:
> The first patch in this series fixes the pm-domain driver and adds
> power-domains which are currently missing. This touches the ABI which is
> not and was never used until now. Not all of them are used yet, but when
> the power-controller is added to the DT in patch 2 the ABI should not
> be changed again.
> Patch 3-5 are adding the the gpu compatible to dt-bindings, adding the gpu
> node and the respective operating points to SoC DT and finally enabling it
> for XPI-3128 board.
> 
> [...]

Applied, thanks!

[3/5] dt-bindings: gpu: mali-utgard: Add Rockchip RK3128 compatible
      commit: 5d86c15c3171c3ecebd84d53e30d9812b5591c84

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From knaerzche at gmail.com  Sat Dec  2 08:36:15 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 2 Dec 2023 17:36:15 +0100
Subject: [PATCH v2 2/5] ARM: dts: rockchip: Add power-controller for
 RK3128
In-Reply-To: <6926340.F8r316W7xa@diego>
References: <20231202125144.66052-1-knaerzche@gmail.com>
 <20231202125144.66052-3-knaerzche@gmail.com> <6926340.F8r316W7xa@diego>
Message-ID: <7a6eed43-477a-48a4-bd64-4528da920ffd@gmail.com>

Hi Heiko,

Am 02.12.23 um 16:51 schrieb Heiko St?bner:
> Hi Alex,
>
> Am Samstag, 2. Dezember 2023, 13:51:41 CET schrieb Alex Bee:
>> Add power controller and qos nodes for RK3128 in order to use
>> them as powerdomains.
> does the power-domain controller work with the incomplete set of
> pm-domains too?

Yes, it does - the missing domains can request idle only and can't be 
powered on/off - if no one requests idle they are just up all the time.

> What I have in mind is
> - adding the power-controller node with the existing set of power-domains
> - the gpu pm-domain is in there
> - adding the gpu parts

My main concern about adding them later was the change of the ABI after 
they've been exposed in the SoC DT. If that's not an issue - sure: I can 
add them in a separate series.

>
>
> And a second series with
> - patch1 from here
> - a dts patch adding the additional pm-domains to rk3128.dtsi
> - I guess patch1 also should be split into a patch adding the binding-ids
>    and a separate patch for the code addition.

Yeah, I noticed this also :)

Regards,

Alex

>
>
> Heiko
>
>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>> ---
>>   arch/arm/boot/dts/rockchip/rk3128.dtsi | 101 +++++++++++++++++++++++++
>>   1 file changed, 101 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>> index 4e8b38604ecd..b72905db04f7 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>> @@ -8,6 +8,7 @@
>>   #include <dt-bindings/interrupt-controller/arm-gic.h>
>>   #include <dt-bindings/interrupt-controller/irq.h>
>>   #include <dt-bindings/pinctrl/rockchip.h>
>> +#include <dt-bindings/power/rk3128-power.h>
>>   
>>   / {
>>   	compatible = "rockchip,rk3128";
>> @@ -133,6 +134,106 @@ smp-sram at 0 {
>>   	pmu: syscon at 100a0000 {
>>   		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
>>   		reg = <0x100a0000 0x1000>;
>> +
>> +		power: power-controller {
>> +			compatible = "rockchip,rk3128-power-controller";
>> +			#power-domain-cells = <1>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			power-domain at RK3128_PD_VIO {
>> +				reg = <RK3128_PD_VIO>;
>> +				clocks = <&cru ACLK_CIF>,
>> +					 <&cru HCLK_CIF>,
>> +					 <&cru DCLK_EBC>,
>> +					 <&cru HCLK_EBC>,
>> +					 <&cru ACLK_IEP>,
>> +					 <&cru HCLK_IEP>,
>> +					 <&cru ACLK_LCDC0>,
>> +					 <&cru HCLK_LCDC0>,
>> +					 <&cru PCLK_MIPI>,
>> +					 <&cru ACLK_RGA>,
>> +					 <&cru HCLK_RGA>,
>> +					 <&cru ACLK_VIO0>,
>> +					 <&cru ACLK_VIO1>,
>> +					 <&cru HCLK_VIO>,
>> +					 <&cru HCLK_VIO_H2P>,
>> +					 <&cru DCLK_VOP>,
>> +					 <&cru SCLK_VOP>;
>> +				pm_qos = <&qos_ebc>,
>> +					 <&qos_iep>,
>> +					 <&qos_lcdc>,
>> +					 <&qos_rga>,
>> +					 <&qos_vip>;
>> +				#power-domain-cells = <0>;
>> +			};
>> +
>> +			power-domain at RK3128_PD_VIDEO {
>> +				reg = <RK3128_PD_VIDEO>;
>> +				clocks = <&cru ACLK_VDPU>,
>> +					 <&cru HCLK_VDPU>,
>> +					 <&cru ACLK_VEPU>,
>> +					 <&cru HCLK_VEPU>,
>> +					 <&cru SCLK_HEVC_CORE>;
>> +				pm_qos = <&qos_vpu>;
>> +				#power-domain-cells = <0>;
>> +			};
>> +
>> +			power-domain at RK3128_PD_GPU {
>> +				reg = <RK3128_PD_GPU>;
>> +				clocks = <&cru ACLK_GPU>;
>> +				pm_qos = <&qos_gpu>;
>> +				#power-domain-cells = <0>;
>> +			};
>> +
>> +			power-domain at RK3128_PD_CRYPTO {
>> +				reg = <RK3128_PD_CRYPTO>;
>> +				clocks = <&cru HCLK_CRYPTO>,
>> +					 <&cru SCLK_CRYPTO>;
>> +				pm_qos = <&qos_crypto>;
>> +				#power-domain-cells = <0>;
>> +			};
>> +		};
>> +	};
>> +
>> +	qos_crypto: qos at 10128080 {
>> +		compatible = "rockchip,rk3128-qos", "syscon";
>> +		reg = <0x10128080 0x20>;
>> +	};
>> +
>> +	qos_gpu: qos at 1012d000 {
>> +		compatible = "rockchip,rk3128-qos", "syscon";
>> +		reg = <0x1012d000 0x20>;
>> +	};
>> +
>> +	qos_vpu: qos at 1012e000 {
>> +		compatible = "rockchip,rk3128-qos", "syscon";
>> +		reg = <0x1012e000 0x20>;
>> +	};
>> +
>> +	qos_rga: qos at 1012f000 {
>> +		compatible = "rockchip,rk3128-qos", "syscon";
>> +		reg = <0x1012f000 0x20>;
>> +	};
>> +
>> +	qos_ebc: qos at 1012f080 {
>> +		compatible = "rockchip,rk3128-qos", "syscon";
>> +		reg = <0x1012f080 0x20>;
>> +	};
>> +
>> +	qos_iep: qos at 1012f100 {
>> +		compatible = "rockchip,rk3128-qos", "syscon";
>> +		reg = <0x1012f100 0x20>;
>> +	};
>> +
>> +	qos_lcdc: qos at 1012f180 {
>> +		compatible = "rockchip,rk3128-qos", "syscon";
>> +		reg = <0x1012f180 0x20>;
>> +	};
>> +
>> +	qos_vip: qos at 1012f200 {
>> +		compatible = "rockchip,rk3128-qos", "syscon";
>> +		reg = <0x1012f200 0x20>;
>>   	};
>>   
>>   	gic: interrupt-controller at 10139000 {
>>
>
>
>


From heiko at sntech.de  Sat Dec  2 08:36:31 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sat,  2 Dec 2023 17:36:31 +0100
Subject: [PATCH] arm64: dts: rockchip: Fix Turing RK1 interrupt pinctrls
In-Reply-To: <20231202071212.1606800-1-CFSworks@gmail.com>
References: <20231202071212.1606800-1-CFSworks@gmail.com>
Message-ID: <170153497984.380580.16625087945958405832.b4-ty@sntech.de>

On Fri, 1 Dec 2023 23:12:12 -0800, Sam Edwards wrote:
> The pinctrls for the hym8563 interrupt line and fan-tach input
> were both mistakenly defined as `pcfg_pull_none`. As these are
> active-low signals (level-triggered, in the hym8563 case) which
> may not be driven at times, these should really be pull-up. The
> lack of any bias results in spurious interrupts.
> 
> Fix this by modifying the `rockchip,pins` properties as necessary
> to enable the pull-up resistors.
> 
> [...]

Applied, thanks!

[1/1] arm64: dts: rockchip: Fix Turing RK1 interrupt pinctrls
      commit: 9f6acd2b4dfef81dcc45486ac704cf602c88db02

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Sat Dec  2 08:36:32 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sat,  2 Dec 2023 17:36:32 +0100
Subject: [PATCH v2 0/2] Add GMAC for RK3128
In-Reply-To: <20231202124158.65615-2-knaerzche@gmail.com>
References: <20231202124158.65615-2-knaerzche@gmail.com>
Message-ID: <170153497985.380580.2053954762522949902.b4-ty@sntech.de>

On Sat, 2 Dec 2023 13:41:57 +0100, Alex Bee wrote:
> RK3128's GMAC is already supported by the Rockchip's glue for dwmac
> driver, so this series basically adds the respective nodes in the SoC DT
> and the enablements for XPI-3128 board.
> 
> Note: These patches are based on maintainers repo.
> 
> Changes in v2:
>  - use phy reset-timings according to the datasheet
>  - added rx-fifo-depth and rx-fifo-depth for gmac
> 
> [...]

Applied, thanks!

[1/2] ARM: dts: rockchip: Add gmac node for RK3128
      commit: 3d880c31d40d30328cb550523adadf1466e7c686
[2/2] ARM: dts: rockchip: Enable gmac for XPI-3128
      commit: b47c0b9ed3eb31c8efb8f8be3bca32d6ced5fd52

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From sjg at chromium.org  Sat Dec  2 08:36:43 2023
From: sjg at chromium.org (Simon Glass)
Date: Sat, 2 Dec 2023 09:36:43 -0700
Subject: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <5e8f42f8-2b03-4033-b6d2-9b3139f081d5@pengutronix.de>
References: <20231129172200.430674-1-sjg@chromium.org> <20231129172200.430674-3-sjg@chromium.org>
 <30f32467-51ea-47de-a272-38e074f4060b@pengutronix.de> <CAPnjgZ25xoXsi74XYY0E8ucQiowQqPdZgUHrfVNAYWKZEYODHg@mail.gmail.com>
 <875f0dbc-1d78-4901-91b2-6ad152bcea5a@pengutronix.de> <CAPnjgZ0UCkm5QCx+JXe1ggSshozPnOLB6cN=UoJyMn6S4wfFkg@mail.gmail.com>
 <06281f7c-e0f2-405c-95a9-0f7e9e84a7f6@pengutronix.de> <CAPnjgZ2TT+0BvbjwfnGLQ3EPEXnLW6f1epiFdaBHRYaSAn5xsA@mail.gmail.com>
 <8fbc81b1-31ab-46b0-87f4-b8bd8e8e2b47@pengutronix.de> <CAPnjgZ1iyxk0bb56QR10N5aSphRYhLsw7Ly=z2i6rQCxP_AYPw@mail.gmail.com>
 <5e8f42f8-2b03-4033-b6d2-9b3139f081d5@pengutronix.de>
Message-ID: <CAPnjgZ2RjNzqJTRZSWvuscQhs+f8CG=fDcEO=qKXNeQLP53LnQ@mail.gmail.com>

Hi Ahmad,

On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
>
> Hello Simon,
>
> On 30.11.23 21:30, Simon Glass wrote:
> > On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> >> On 29.11.23 20:44, Simon Glass wrote:
> >>> On Wed, 29 Nov 2023 at 12:33, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> >>>>
> >>>> On 29.11.23 20:27, Simon Glass wrote:
> >>>>> On Wed, 29 Nov 2023 at 12:15, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> >>>>>> On 29.11.23 20:02, Simon Glass wrote:
> >>>>>>> On Wed, 29 Nov 2023 at 11:59, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> >>>>>>>> The specification says that this is the root U-Boot compatible,
> >>>>>>>> which I presume to mean the top-level compatible, which makes sense to me.
> >>>>>>>>
> >>>>>>>> The code here though adds all compatible strings from the device tree though,
> >>>>>>>> is this intended?
> >>>>>>>
> >>>>>>> Yes, since it saves needing to read in each DT just to get the
> >>>>>>> compatible stringlist.
> >>>>>>
> >>>>>> The spec reads as if only one string (root) is supposed to be in the list.
> >>>>>> The script adds all compatibles though. This is not really useful as a bootloader
> >>>>>> that's compatible with e.g. fsl,imx8mm would just take the first device tree
> >>>>>> with that SoC, which is most likely to be wrong. It would be better to just
> >>>>>> specify the top-level compatible, so the bootloader fails instead of taking
> >>>>>> the first DT it finds.
> >>>>>
> >>>>> We do need to have a list, since we have to support different board revs, etc.
> >>>>
> >>>> Can you give me an example? The way I see it, a bootloader with
> >>>> compatible "vendor,board" and a FIT with configuration with compatibles:
> >>>>
> >>>>   "vendor,board-rev-a", "vendor,board"
> >>>>   "vendor,board-rev-b", "vendor,board"
> >>>>
> >>>> would just result in the bootloader booting the first configuration, even if
> >>>> the device is actually rev-b.
> >>>
> >>> You need to find the best match, not just any match. This is
> >>> documented in the function comment for fit_conf_find_compat().
> >>
> >> In my above example, both configuration are equally good.
> >> Can you give me an example where it makes sense to have multiple
> >> compatibles automatically extracted from the device tree compatible?
> >>
> >> The way I see it having more than one compatible here just has
> >> downsides.
> >
> > I don't have an example to hand, but this is the required mechanism of
> > FIT. This feature has been in place for many years and is used by
> > ChromeOS, at least.
>
> I see the utility of a FIT configuration with
>
>     compatible = "vendor,board-rev-a", "vendor,board-rev-b";
>
> I fail to see a utility for a configuration with
>
>     compatible = "vendor,board", "vendor,SoM", "vendor,SoC";
>
> Any configuration that ends up being booted because "vendor,SoC" was matched is
> most likely doomed to fail. Therefore, I would suggest that only the top level
> configuration is written into the FIT configurations automatically.

Firstly, I am not an expert on this.

Say you have a board with variants. The compatible string in U-Boot
may be something like:

"google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
"rockchip,rk3288";

If you then have several FIT configurations, they may be something like:

"google,veyron-brain-rev0", "google,veyron-brain", "google,veyron",
"rockchip,rk3288";
"google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
"rockchip,rk3288";
"google,veyron-brain-rev2", "google,veyron-brain", "google,veyron",
"rockchip,rk3288";

You want to choose the second one, since it is a better match than the others.

+Doug Anderson who knows a lot more about this than me.

Regards,
Simon


From heiko at sntech.de  Sat Dec  2 09:46:56 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sat, 02 Dec 2023 18:46:56 +0100
Subject: [PATCH v2 2/5] ARM: dts: rockchip: Add power-controller for RK3128
In-Reply-To: <7a6eed43-477a-48a4-bd64-4528da920ffd@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com> <6926340.F8r316W7xa@diego>
 <7a6eed43-477a-48a4-bd64-4528da920ffd@gmail.com>
Message-ID: <4891026.6YUMPnJmAY@diego>

Hi Alex,

Am Samstag, 2. Dezember 2023, 17:36:15 CET schrieb Alex Bee:
> Am 02.12.23 um 16:51 schrieb Heiko St?bner:
> > Am Samstag, 2. Dezember 2023, 13:51:41 CET schrieb Alex Bee:
> >> Add power controller and qos nodes for RK3128 in order to use
> >> them as powerdomains.
> > does the power-domain controller work with the incomplete set of
> > pm-domains too?
> 
> Yes, it does - the missing domains can request idle only and can't be 
> powered on/off - if no one requests idle they are just up all the time.
> 
> > What I have in mind is
> > - adding the power-controller node with the existing set of power-domains
> > - the gpu pm-domain is in there
> > - adding the gpu parts
> 
> My main concern about adding them later was the change of the ABI after 
> they've been exposed in the SoC DT. If that's not an issue - sure: I can 
> add them in a separate series.

An ABI change would be _changing_ the domain-ids in the rk3128-power.h
I think :-) .

Right now the existing domain ids in the header are already exposed to the
world, so someone could already use them, but not the new ones.



Heiko

> > And a second series with
> > - patch1 from here
> > - a dts patch adding the additional pm-domains to rk3128.dtsi
> > - I guess patch1 also should be split into a patch adding the binding-ids
> >    and a separate patch for the code addition.
> 
> Yeah, I noticed this also :)
> 
> Regards,
> 
> Alex
> 
> >
> >
> > Heiko
> >
> >> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> >> ---
> >>   arch/arm/boot/dts/rockchip/rk3128.dtsi | 101 +++++++++++++++++++++++++
> >>   1 file changed, 101 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
> >> index 4e8b38604ecd..b72905db04f7 100644
> >> --- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
> >> +++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
> >> @@ -8,6 +8,7 @@
> >>   #include <dt-bindings/interrupt-controller/arm-gic.h>
> >>   #include <dt-bindings/interrupt-controller/irq.h>
> >>   #include <dt-bindings/pinctrl/rockchip.h>
> >> +#include <dt-bindings/power/rk3128-power.h>
> >>   
> >>   / {
> >>   	compatible = "rockchip,rk3128";
> >> @@ -133,6 +134,106 @@ smp-sram at 0 {
> >>   	pmu: syscon at 100a0000 {
> >>   		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
> >>   		reg = <0x100a0000 0x1000>;
> >> +
> >> +		power: power-controller {
> >> +			compatible = "rockchip,rk3128-power-controller";
> >> +			#power-domain-cells = <1>;
> >> +			#address-cells = <1>;
> >> +			#size-cells = <0>;
> >> +
> >> +			power-domain at RK3128_PD_VIO {
> >> +				reg = <RK3128_PD_VIO>;
> >> +				clocks = <&cru ACLK_CIF>,
> >> +					 <&cru HCLK_CIF>,
> >> +					 <&cru DCLK_EBC>,
> >> +					 <&cru HCLK_EBC>,
> >> +					 <&cru ACLK_IEP>,
> >> +					 <&cru HCLK_IEP>,
> >> +					 <&cru ACLK_LCDC0>,
> >> +					 <&cru HCLK_LCDC0>,
> >> +					 <&cru PCLK_MIPI>,
> >> +					 <&cru ACLK_RGA>,
> >> +					 <&cru HCLK_RGA>,
> >> +					 <&cru ACLK_VIO0>,
> >> +					 <&cru ACLK_VIO1>,
> >> +					 <&cru HCLK_VIO>,
> >> +					 <&cru HCLK_VIO_H2P>,
> >> +					 <&cru DCLK_VOP>,
> >> +					 <&cru SCLK_VOP>;
> >> +				pm_qos = <&qos_ebc>,
> >> +					 <&qos_iep>,
> >> +					 <&qos_lcdc>,
> >> +					 <&qos_rga>,
> >> +					 <&qos_vip>;
> >> +				#power-domain-cells = <0>;
> >> +			};
> >> +
> >> +			power-domain at RK3128_PD_VIDEO {
> >> +				reg = <RK3128_PD_VIDEO>;
> >> +				clocks = <&cru ACLK_VDPU>,
> >> +					 <&cru HCLK_VDPU>,
> >> +					 <&cru ACLK_VEPU>,
> >> +					 <&cru HCLK_VEPU>,
> >> +					 <&cru SCLK_HEVC_CORE>;
> >> +				pm_qos = <&qos_vpu>;
> >> +				#power-domain-cells = <0>;
> >> +			};
> >> +
> >> +			power-domain at RK3128_PD_GPU {
> >> +				reg = <RK3128_PD_GPU>;
> >> +				clocks = <&cru ACLK_GPU>;
> >> +				pm_qos = <&qos_gpu>;
> >> +				#power-domain-cells = <0>;
> >> +			};
> >> +
> >> +			power-domain at RK3128_PD_CRYPTO {
> >> +				reg = <RK3128_PD_CRYPTO>;
> >> +				clocks = <&cru HCLK_CRYPTO>,
> >> +					 <&cru SCLK_CRYPTO>;
> >> +				pm_qos = <&qos_crypto>;
> >> +				#power-domain-cells = <0>;
> >> +			};
> >> +		};
> >> +	};
> >> +
> >> +	qos_crypto: qos at 10128080 {
> >> +		compatible = "rockchip,rk3128-qos", "syscon";
> >> +		reg = <0x10128080 0x20>;
> >> +	};
> >> +
> >> +	qos_gpu: qos at 1012d000 {
> >> +		compatible = "rockchip,rk3128-qos", "syscon";
> >> +		reg = <0x1012d000 0x20>;
> >> +	};
> >> +
> >> +	qos_vpu: qos at 1012e000 {
> >> +		compatible = "rockchip,rk3128-qos", "syscon";
> >> +		reg = <0x1012e000 0x20>;
> >> +	};
> >> +
> >> +	qos_rga: qos at 1012f000 {
> >> +		compatible = "rockchip,rk3128-qos", "syscon";
> >> +		reg = <0x1012f000 0x20>;
> >> +	};
> >> +
> >> +	qos_ebc: qos at 1012f080 {
> >> +		compatible = "rockchip,rk3128-qos", "syscon";
> >> +		reg = <0x1012f080 0x20>;
> >> +	};
> >> +
> >> +	qos_iep: qos at 1012f100 {
> >> +		compatible = "rockchip,rk3128-qos", "syscon";
> >> +		reg = <0x1012f100 0x20>;
> >> +	};
> >> +
> >> +	qos_lcdc: qos at 1012f180 {
> >> +		compatible = "rockchip,rk3128-qos", "syscon";
> >> +		reg = <0x1012f180 0x20>;
> >> +	};
> >> +
> >> +	qos_vip: qos at 1012f200 {
> >> +		compatible = "rockchip,rk3128-qos", "syscon";
> >> +		reg = <0x1012f200 0x20>;
> >>   	};
> >>   
> >>   	gic: interrupt-controller at 10139000 {
> >>
> >
> >
> >
> 






From justin.chen at broadcom.com  Sat Dec  2 09:49:09 2023
From: justin.chen at broadcom.com (Justin Chen)
Date: Sat, 2 Dec 2023 09:49:09 -0800
Subject: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
In-Reply-To: <CAMj1kXFRknpr+gASm-mMcWzLqVQnWXf3UK+SbD3ouMgdOtCAzA@mail.gmail.com>
References: <d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com>
 <CAMj1kXGST7uH530hB0i-rzisNesNrUGsJ5a5eC9805Udi5msrQ@mail.gmail.com>
 <81af85b4-5274-4362-9413-890425c60524@broadcom.com>
 <20231201130702.2824115c@gandalf.local.home>
 <4597db06-dabc-4bb2-9f24-bd30e07ff86d@broadcom.com>
 <CAMj1kXFMy0=DP3-Ycsj+XCHWxvqNqddBkEm71Nrr-m9gVca21w@mail.gmail.com>
 <dc1dd584-1970-4460-b76c-3cd9300a23e4@broadcom.com>
 <CAMj1kXFRknpr+gASm-mMcWzLqVQnWXf3UK+SbD3ouMgdOtCAzA@mail.gmail.com>
Message-ID: <3eac92e6-da44-4217-a2de-b8d142d2cab1@broadcom.com>



On 12/2/2023 1:26 AM, Ard Biesheuvel wrote:
> On Sat, 2 Dec 2023 at 09:49, Justin Chen <justin.chen at broadcom.com> wrote:
>>
>>
>>
>> On 12/1/23 10:53 PM, Ard Biesheuvel wrote:
>>> On Fri, 1 Dec 2023 at 23:59, Justin Chen <justin.chen at broadcom.com> wrote:
>>>>
>>>>
>>>>
>>>> On 12/1/23 10:07 AM, Steven Rostedt wrote:
>>>>> On Fri, 1 Dec 2023 09:25:59 -0800
>>>>> Justin Chen <justin.chen at broadcom.com> wrote:
>>>>>
>>>>>>> It appears the sub instruction at 0x6dd0 correctly accounts for the
>>>>>>> extra 8 bytes, so the frame pointer is valid. So it is our assumption
>>>>>>> that there are no gaps between the stack frames is invalid.
>>>>>>
>>>>>> Thanks for the assistance. The gap between the stack frame depends on
>>>>>> the function. Most do not have a gap. Some have 8 (as shown above), some
>>>>>> have 12. A single assumption here is not going to work. I'm having a
>>>>>> hard time finding out the reasoning for this gap. I tried disabling a
>>>>>> bunch of gcc flags as well as -O2 and the gap still exists.
>>>>>
>>>>> That code was originally added because of some strange things that gcc did
>>>>> with mcount (for example, it made a copy of the stack frame that it passed
>>>>> to mcount, where the function graph tracer replaced the copy of the return
>>>>> stack making the shadow stack go out of sync and crash). This was very hard
>>>>> to debug and I added this code to detect it if it happened again.
>>>>>
>>>>> Well it's been over a decade since that happened (2009).
>>>>>
>>>>>      71e308a239c09 ("function-graph: add stack frame test")
>>>>>
>>>>> I'm happy assuming that the compiler folks are aware of our tricks with
>>>>> hijacking return calls and I don't expect it to happen again. We can just
>>>>> rip out those checks. That is, if it's only causing false positives, I
>>>>> don't think it's worth keeping around.
>>>>>
>>>>> Has it detected any real issues on the Arm platforms?
>>>>>
>>>>> -- Steve
>>>>
>>>> I am not familiar enough to make a call. But from my limited testing
>>>> with ARM, I didn't see any issues. If you would like me to, I can submit
>>>> a patch to remove the check entirely. Or maybe only disable it for ARM?
>>>>
>>>
>>> Please try the fix I proposed first.
>>
>> Just tested it. Seems to do the trick.
> 
> Thanks
> 
>> Either solution works for me.
>>
> 
> Given that this discussion is taking place in the context of the
> report of an issue identified by GRAPH_FP_TEST, I don't see how
> removing that would be a reasonable conclusion.
> 

Fair enough. I will submit a patch. Thanks for the help.

>> FWIW I also experimented with LLVM, looks like function_graph just
>> crashes regardless of the issue being discussed. The disassemble of
>> LLVM[1] does something completely different.
>>
> 
> 
> LLVM does not support CONFIG_UNWINDER_FRAME_POINTER so the fact that
> the prologue looks different is expected.
> 
> In the case below, the FP {r11} is correctly made to point to a {r11,
> lr} tuple on the stack, so the codegen is correct AFAICT. But IIRC we
> rely on unwind information for ftrace in this case, not the frame
> pointer.
> 
> Could you be more specific about the crash?
>

It just hangs with no prints. I can instrument the hang and see what I 
can find.

Justin

> 
>>
>> [1]
>> LLVM dump
>> c0c6faa0 <sk_getsockopt>:
>> c0c6faa0: f0 4f 2d e9   push    {r4, r5, r6, r7, r8, r9, r10, r11, lr}
>> c0c6faa4: 1c b0 8d e2   add     r11, sp, #28
>> c0c6faa8: ac d0 4d e2   sub     sp, sp, #172
>> c0c6faac: 00 70 a0 e1   mov     r7, r0
>> c0c6fab0: c8 0c 04 e3   movw    r0, #19656
>> c0c6fab4: 80 02 4c e3   movt    r0, #49792
>> c0c6fab8: 03 50 a0 e1   mov     r5, r3
>> c0c6fabc: 00 00 90 e5   ldr     r0, [r0]
>> c0c6fac0: 02 a0 a0 e1   mov     r10, r2
>> c0c6fac4: 20 00 0b e5   str     r0, [r11, #-32]
>> c0c6fac8: 00 40 2d e9   stmdb   sp!, {lr}
>> c0c6facc: 4b 8b d6 eb   bl      0xc0212800 <__gnu_mcount_nc> @ imm =
>> #-10867412
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231202/b066b24b/attachment.p7s>

From jbx6244 at gmail.com  Sat Dec  2 10:22:01 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 2 Dec 2023 19:22:01 +0100
Subject: [PATCH v1 1/2] ARM: dts: rockchip: add gpio alias for gpio dt nodes
Message-ID: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>

Rockchip SoC TRM, SoC datasheet and board schematics always refer to
the same gpio numbers - even if not all are used for a specific board.
In order to not have to re-define them for every board add the
aliases to SoC dtsi files.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---

Changed V1:
  rebase
  remove rk3066 gpio5 alias
---
 arch/arm/boot/dts/rockchip/rk3036.dtsi  | 3 +++
 arch/arm/boot/dts/rockchip/rk3066a.dtsi | 5 +++++
 arch/arm/boot/dts/rockchip/rk322x.dtsi  | 4 ++++
 arch/arm/boot/dts/rockchip/rk3288.dtsi  | 9 +++++++++
 arch/arm/boot/dts/rockchip/rk3xxx.dtsi  | 4 ++++
 5 files changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
index 78686fc72ce6..8aa2e0864fed 100644
--- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
@@ -17,6 +17,9 @@ / {
 	interrupt-parent = <&gic>;

 	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
diff --git a/arch/arm/boot/dts/rockchip/rk3066a.dtsi b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
index de9915d946f7..30139f21de64 100644
--- a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
@@ -13,6 +13,11 @@
 / {
 	compatible = "rockchip,rk3066a";

+	aliases {
+		gpio4 = &gpio4;
+		gpio6 = &gpio6;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi b/arch/arm/boot/dts/rockchip/rk322x.dtsi
index a721744cbfd1..831561fc1814 100644
--- a/arch/arm/boot/dts/rockchip/rk322x.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk322x.dtsi
@@ -15,6 +15,10 @@ / {
 	interrupt-parent = <&gic>;

 	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
 		serial0 = &uart0;
 		serial1 = &uart1;
 		serial2 = &uart2;
diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi b/arch/arm/boot/dts/rockchip/rk3288.dtsi
index cb9cdaddffd4..ead343dc3df1 100644
--- a/arch/arm/boot/dts/rockchip/rk3288.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3288.dtsi
@@ -19,6 +19,15 @@ / {

 	aliases {
 		ethernet0 = &gmac;
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
+		gpio5 = &gpio5;
+		gpio6 = &gpio6;
+		gpio7 = &gpio7;
+		gpio8 = &gpio8;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
diff --git a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
index cb4e42ede56a..f37137f298d5 100644
--- a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
@@ -16,6 +16,10 @@ / {

 	aliases {
 		ethernet0 = &emac;
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
--
2.39.2



From jbx6244 at gmail.com  Sat Dec  2 10:22:58 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 2 Dec 2023 19:22:58 +0100
Subject: [PATCH v1 2/2] arm64: dts: rockchip: add gpio alias for gpio dt nodes
In-Reply-To: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
References: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
Message-ID: <56daeead-1d35-44bb-00c0-614b84a986de@gmail.com>

Rockchip SoC TRM, SoC datasheet and board schematics always refer to
the same gpio numbers - even if not all are used for a specific board.
In order to not have to re-define them for every board add the
aliases to SoC dtsi files.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3308.dtsi | 5 +++++
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
 4 files changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
index 2ae4bb7d5e62..cfc0a87b5195 100644
--- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
@@ -20,6 +20,11 @@ / {
 	#size-cells = <2>;

 	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index e18f7c1c0724..76ea18bf11a0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -20,6 +20,10 @@ / {
 	#size-cells = <2>;

 	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
 		serial0 = &uart0;
 		serial1 = &uart1;
 		serial2 = &uart2;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index a4c5aaf1f457..fc7e3f2bc786 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -20,6 +20,10 @@ / {

 	aliases {
 		ethernet0 = &gmac;
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index da0dfb237f85..dec2705d035d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -20,6 +20,11 @@ / {

 	aliases {
 		ethernet0 = &gmac;
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
--
2.39.2



From keescook at chromium.org  Sat Dec  2 12:32:23 2023
From: keescook at chromium.org (Kees Cook)
Date: Sat,  2 Dec 2023 12:32:23 -0800
Subject: [PATCH][next] atags_proc: Add __counted_by for struct buffer and use struct_size()
In-Reply-To: <ZSVHurzo/4aFQcT3@work>
References: <ZSVHurzo/4aFQcT3@work>
Message-ID: <170154914064.179444.11376018592445133931.b4-ty@chromium.org>

On Tue, 10 Oct 2023 06:46:50 -0600, Gustavo A. R. Silva wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
> array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
> 
> While there, use struct_size() helper, instead of the open-coded
> version, to calculate the size for the allocation of the whole
> flexible structure, including of course, the flexible-array member.
> 
> [...]

Applied to for-next/hardening, thanks!

[1/1] atags_proc: Add __counted_by for struct buffer and use struct_size()
      https://git.kernel.org/kees/c/ac7110d883ff

Take care,

-- 
Kees Cook



From keescook at chromium.org  Sat Dec  2 13:27:54 2023
From: keescook at chromium.org (Kees Cook)
Date: Sat, 2 Dec 2023 13:27:54 -0800
Subject: [PATCH][next] wifi: mt76: mt7996: Use DECLARE_FLEX_ARRAY() and
 fix -Warray-bounds warnings
In-Reply-To: <ZVaCNAohuieMmdq9@work>
References: <ZVaCNAohuieMmdq9@work>
Message-ID: <202312021326.D3504C1@keescook>

On Thu, Nov 16, 2023 at 02:57:24PM -0600, Gustavo A. R. Silva wrote:
> Transform zero-length arrays `adm_stat` and `msdu_cnt` into proper
> flexible-array members in anonymous union in `struct
> mt7996_mcu_all_sta_info_event` via the DECLARE_FLEX_ARRAY()
> helper; and fix multiple -Warray-bounds warnings:
> 
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:483:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:490:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:492:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:469:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:477:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:479:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> 
> This results in no differences in binary output, helps with the ongoing
> efforts to globally enable -Warray-bounds.
> 
> Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org>

*thread ping*

Can wireless folks please pick this patch up?

-Kees

> ---
>  drivers/net/wireless/mediatek/mt76/mt7996/mcu.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
> index a88f6af323da..9f516f796d63 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
> @@ -163,19 +163,19 @@ struct mt7996_mcu_all_sta_info_event {
>  	u8 rsv3[2];
>  
>  	union {
> -		struct {
> +		DECLARE_FLEX_ARRAY(struct {
>  			__le16 wlan_idx;
>  			u8 rsv[2];
>  			__le32 tx_bytes[IEEE80211_NUM_ACS];
>  			__le32 rx_bytes[IEEE80211_NUM_ACS];
> -		} adm_stat[0];
> +		}, adm_stat);
>  
> -		struct {
> +		DECLARE_FLEX_ARRAY(struct {
>  			__le16 wlan_idx;
>  			u8 rsv[2];
>  			__le32 tx_msdu_cnt;
>  			__le32 rx_msdu_cnt;
> -		} msdu_cnt[0];
> +		}, msdu_cnt);
>  	};
>  } __packed;
>  
> -- 
> 2.34.1
> 

-- 
Kees Cook


From david at ixit.cz  Sat Dec  2 14:29:01 2023
From: david at ixit.cz (David Heidelberg)
Date: Sat,  2 Dec 2023 23:29:01 +0100
Subject: [PATCH v3 2/5] arm64: dts: imx8mq-phanbell: make dts use gpio-fan matrix instead of array
In-Reply-To: <20231202222934.137191-1-david@ixit.cz>
References: <20231202222934.137191-1-david@ixit.cz>
Message-ID: <20231202222934.137191-2-david@ixit.cz>

No functional changes.

Adjust to comply with dt-schema requirements
and make possible to validate values.

Signed-off-by: David Heidelberg <david at ixit.cz>
---
 arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts b/arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts
index a3b9d615a3b4..e34045d10a12 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts
@@ -39,7 +39,7 @@ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
 
 	fan: gpio-fan {
 		compatible = "gpio-fan";
-		gpio-fan,speed-map = <0 0 8600 1>;
+		gpio-fan,speed-map = <0 0>, <8600 1>;
 		gpios = <&gpio3 5 GPIO_ACTIVE_HIGH>;
 		#cooling-cells = <2>;
 		pinctrl-names = "default";
-- 
2.42.0



From david at ixit.cz  Sat Dec  2 14:29:02 2023
From: david at ixit.cz (David Heidelberg)
Date: Sat,  2 Dec 2023 23:29:02 +0100
Subject: [PATCH v3 3/5] arm64: dts: rockchip: make dts use gpio-fan matrix instead of array
In-Reply-To: <20231202222934.137191-1-david@ixit.cz>
References: <20231202222934.137191-1-david@ixit.cz>
Message-ID: <20231202222934.137191-3-david@ixit.cz>

No functional changes.

Adjust to comply with dt-schema requirements
and make possible to validate values.

Acked-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: David Heidelberg <david at ixit.cz>
---
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi  | 2 +-
 arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index e6ac292ce645..69dd3568b84e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -44,7 +44,7 @@ dc_12v: dc-12v {
 	fan0: gpio-fan {
 		#cooling-cells = <2>;
 		compatible = "gpio-fan";
-		gpio-fan,speed-map = <0 0 3000 1>;
+		gpio-fan,speed-map = <0 0>, <3000 1>;
 		gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>;
 		status = "okay";
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
index 854d02b46e6f..59843a7a199c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
@@ -31,8 +31,9 @@ gmac1_clkin: external-gmac1-clock {
 	fan: gpio_fan {
 		compatible = "gpio-fan";
 		gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <0    0
-				      4500 1>;
+		gpio-fan,speed-map =
+				<   0 0>,
+				<4500 1>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&fan_en_h>;
 		#cooling-cells = <2>;
-- 
2.42.0



From david at ixit.cz  Sat Dec  2 14:29:04 2023
From: david at ixit.cz (David Heidelberg)
Date: Sat,  2 Dec 2023 23:29:04 +0100
Subject: [PATCH v3 5/5] ARM: dts: marvell: make dts use gpio-fan matrix instead of array
In-Reply-To: <20231202222934.137191-1-david@ixit.cz>
References: <20231202222934.137191-1-david@ixit.cz>
Message-ID: <20231202222934.137191-5-david@ixit.cz>

No functional changes.

Adjust to comply with dt-schema requirements
and make possible to validate values.

Acked-by: Simon Guinot <simon.guinot at sequanux.org>
Signed-off-by: David Heidelberg <david at ixit.cz>
---
 arch/arm/boot/dts/marvell/armada-370-rd.dts   |   2 +-
 .../marvell/armada-370-seagate-nas-2bay.dts   |   8 +-
 .../marvell/armada-370-seagate-nas-4bay.dts   |   8 +-
 .../marvell/armada-370-synology-ds213j.dts    |  16 +--
 .../dts/marvell/armada-385-synology-ds116.dts |  16 +--
 arch/arm/boot/dts/marvell/armada-388-gp.dts   |   4 +-
 arch/arm/boot/dts/marvell/kirkwood-dnskw.dtsi |   6 +-
 .../marvell/kirkwood-linkstation-6282.dtsi    |   9 +-
 .../marvell/kirkwood-linkstation-lswxl.dts    |   9 +-
 arch/arm/boot/dts/marvell/kirkwood-lsxl.dtsi  |   9 +-
 arch/arm/boot/dts/marvell/kirkwood-ns2max.dts |  18 ++--
 .../arm/boot/dts/marvell/kirkwood-ns2mini.dts |  18 ++--
 .../boot/dts/marvell/kirkwood-synology.dtsi   | 102 +++++++++---------
 .../dts/marvell/mvebu-linkstation-fan.dtsi    |   8 +-
 14 files changed, 121 insertions(+), 112 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-370-rd.dts b/arch/arm/boot/dts/marvell/armada-370-rd.dts
index b459a670f615..4b5789b73dac 100644
--- a/arch/arm/boot/dts/marvell/armada-370-rd.dts
+++ b/arch/arm/boot/dts/marvell/armada-370-rd.dts
@@ -95,7 +95,7 @@ button {
 			gpio-fan {
 				compatible = "gpio-fan";
 				gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
-				gpio-fan,speed-map = <0 0 3000 1>;
+				gpio-fan,speed-map = <0 0>, <3000 1>;
 				pinctrl-0 = <&fan_pins>;
 				pinctrl-names = "default";
 			};
diff --git a/arch/arm/boot/dts/marvell/armada-370-seagate-nas-2bay.dts b/arch/arm/boot/dts/marvell/armada-370-seagate-nas-2bay.dts
index 8dd242e668e6..6ec3dd3337f4 100644
--- a/arch/arm/boot/dts/marvell/armada-370-seagate-nas-2bay.dts
+++ b/arch/arm/boot/dts/marvell/armada-370-seagate-nas-2bay.dts
@@ -25,9 +25,9 @@ / {
 
 	gpio-fan {
 		gpio-fan,speed-map =
-			<   0 3
-			  950 2
-			 1400 1
-			 1800 0>;
+			<   0 3>,
+			< 950 2>,
+			<1400 1>,
+			<1800 0>;
 	};
 };
diff --git a/arch/arm/boot/dts/marvell/armada-370-seagate-nas-4bay.dts b/arch/arm/boot/dts/marvell/armada-370-seagate-nas-4bay.dts
index 370ca9c43247..3011578a3124 100644
--- a/arch/arm/boot/dts/marvell/armada-370-seagate-nas-4bay.dts
+++ b/arch/arm/boot/dts/marvell/armada-370-seagate-nas-4bay.dts
@@ -106,10 +106,10 @@ NS_V2_LED_ON   1 0
 
 	gpio-fan {
 		gpio-fan,speed-map =
-			<   0 3
-			  800 2
-			  1050 1
-			  1300 0>;
+			<   0 3>,
+			< 800 2>,
+			<1050 1>,
+			<1300 0>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/marvell/armada-370-synology-ds213j.dts b/arch/arm/boot/dts/marvell/armada-370-synology-ds213j.dts
index b07d11d1f124..02599a3e9816 100644
--- a/arch/arm/boot/dts/marvell/armada-370-synology-ds213j.dts
+++ b/arch/arm/boot/dts/marvell/armada-370-synology-ds213j.dts
@@ -113,14 +113,14 @@ gpio-fan-32-38 {
 			 &gpio2  0 GPIO_ACTIVE_HIGH
 			 &gpio2  1 GPIO_ACTIVE_HIGH>;
 		alarm-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <    0 0
-				       1000 1
-				       1150 2
-				       1350 4
-				       1500 3
-				       1650 5
-				       1750 6
-				       1900 7 >;
+		gpio-fan,speed-map = <   0 0>,
+				     <1000 1>,
+				     <1150 2>,
+				     <1350 4>,
+				     <1500 3>,
+				     <1650 5>,
+				     <1750 6>,
+				     <1900 7>;
 	};
 
 	gpio-leds {
diff --git a/arch/arm/boot/dts/marvell/armada-385-synology-ds116.dts b/arch/arm/boot/dts/marvell/armada-385-synology-ds116.dts
index ea91ff964d94..6caa5c50175a 100644
--- a/arch/arm/boot/dts/marvell/armada-385-synology-ds116.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-synology-ds116.dts
@@ -131,14 +131,14 @@ gpio-fan {
 			gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>,
 				<&gpio1 17 GPIO_ACTIVE_HIGH>,
 				<&gpio1 16 GPIO_ACTIVE_HIGH>;
-			gpio-fan,speed-map = <   0 0
-					      1500 1
-					      2500 2
-					      3000 3
-					      3400 4
-					      3700 5
-					      3900 6
-					      4000 7>;
+			gpio-fan,speed-map = <   0 0>,
+					     <1500 1>,
+					     <2500 2>,
+					     <3000 3>,
+					     <3400 4>,
+					     <3700 5>,
+					     <3900 6>,
+					     <4000 7>;
 			#cooling-cells = <2>;
 		};
 
diff --git a/arch/arm/boot/dts/marvell/armada-388-gp.dts b/arch/arm/boot/dts/marvell/armada-388-gp.dts
index e2ba50520b6b..1de0a172aa5f 100644
--- a/arch/arm/boot/dts/marvell/armada-388-gp.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-gp.dts
@@ -237,8 +237,8 @@ pcie at 3,0 {
 		gpio-fan {
 			compatible = "gpio-fan";
 			gpios = <&expander1 3 GPIO_ACTIVE_HIGH>;
-			gpio-fan,speed-map = <	 0 0
-					      3000 1>;
+			gpio-fan,speed-map = <	 0 0>,
+					     <3000 1>;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/marvell/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/marvell/kirkwood-dnskw.dtsi
index eb917462b219..0738eb679fcd 100644
--- a/arch/arm/boot/dts/marvell/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/marvell/kirkwood-dnskw.dtsi
@@ -38,9 +38,9 @@ gpio_fan {
 		pinctrl-names = "default";
 		gpios = <&gpio1 14 GPIO_ACTIVE_HIGH
 			 &gpio1 13 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <0    0
-				      3000 1
-				      6000 2>;
+		gpio-fan,speed-map = <0    0>,
+				     <3000 1>,
+				     <6000 2>;
 	};
 
 	gpio_poweroff {
diff --git a/arch/arm/boot/dts/marvell/kirkwood-linkstation-6282.dtsi b/arch/arm/boot/dts/marvell/kirkwood-linkstation-6282.dtsi
index 377b6e970259..dfac2045a1eb 100644
--- a/arch/arm/boot/dts/marvell/kirkwood-linkstation-6282.dtsi
+++ b/arch/arm/boot/dts/marvell/kirkwood-linkstation-6282.dtsi
@@ -118,10 +118,11 @@ gpio_fan {
 		gpios = <&gpio0 17 GPIO_ACTIVE_LOW
 			 &gpio0 16 GPIO_ACTIVE_LOW>;
 
-		gpio-fan,speed-map = <0 3
-				1500 2
-				3250 1
-				5000 0>;
+		gpio-fan,speed-map =
+				<   0 3>,
+				<1500 2>,
+				<3250 1>,
+				<5000 0>;
 
 		alarm-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
 	};
diff --git a/arch/arm/boot/dts/marvell/kirkwood-linkstation-lswxl.dts b/arch/arm/boot/dts/marvell/kirkwood-linkstation-lswxl.dts
index c6024b569423..0425df8cb91c 100644
--- a/arch/arm/boot/dts/marvell/kirkwood-linkstation-lswxl.dts
+++ b/arch/arm/boot/dts/marvell/kirkwood-linkstation-lswxl.dts
@@ -69,10 +69,11 @@ gpio_fan {
 		gpios = <&gpio1 16 GPIO_ACTIVE_LOW
 			 &gpio1 15 GPIO_ACTIVE_LOW>;
 
-		gpio-fan,speed-map = <0 3
-				1500 2
-				3250 1
-				5000 0>;
+		gpio-fan,speed-map =
+				<   0 3>,
+				<1500 2>,
+				<3250 1>,
+				<5000 0>;
 
 		alarm-gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
 	};
diff --git a/arch/arm/boot/dts/marvell/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/marvell/kirkwood-lsxl.dtsi
index 88b70ba1c8fe..f80af24b9e90 100644
--- a/arch/arm/boot/dts/marvell/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/marvell/kirkwood-lsxl.dtsi
@@ -172,10 +172,11 @@ gpio_fan {
 		pinctrl-names = "default";
 		gpios = <&gpio0 19 GPIO_ACTIVE_LOW
 		         &gpio0 18 GPIO_ACTIVE_LOW>;
-		gpio-fan,speed-map = <0    3
-		                      1500 2
-		                      3250 1
-		                      5000 0>;
+		gpio-fan,speed-map =
+				<0    3>,
+				<1500 2>,
+				<3250 1>,
+				<5000 0>;
 		alarm-gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
 	};
 
diff --git a/arch/arm/boot/dts/marvell/kirkwood-ns2max.dts b/arch/arm/boot/dts/marvell/kirkwood-ns2max.dts
index c0a087e77408..044958bc55da 100644
--- a/arch/arm/boot/dts/marvell/kirkwood-ns2max.dts
+++ b/arch/arm/boot/dts/marvell/kirkwood-ns2max.dts
@@ -29,15 +29,15 @@ &gpio0  7 GPIO_ACTIVE_LOW
 			 &gpio1  1 GPIO_ACTIVE_LOW
 			 &gpio0 23 GPIO_ACTIVE_LOW>;
 		gpio-fan,speed-map =
-			<   0  0
-			 1500 15
-			 1700 14
-			 1800 13
-			 2100 12
-			 3100 11
-			 3300 10
-			 4300  9
-			 5500  8>;
+			<   0  0>,
+			<1500 15>,
+			<1700 14>,
+			<1800 13>,
+			<2100 12>,
+			<3100 11>,
+			<3300 10>,
+			<4300  9>,
+			<5500  8>;
 		alarm-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
 	};
 
diff --git a/arch/arm/boot/dts/marvell/kirkwood-ns2mini.dts b/arch/arm/boot/dts/marvell/kirkwood-ns2mini.dts
index 5b9fa14b6428..3fbe008f9141 100644
--- a/arch/arm/boot/dts/marvell/kirkwood-ns2mini.dts
+++ b/arch/arm/boot/dts/marvell/kirkwood-ns2mini.dts
@@ -30,15 +30,15 @@ &gpio0  7 GPIO_ACTIVE_LOW
 			 &gpio1  1 GPIO_ACTIVE_LOW
 			 &gpio0 23 GPIO_ACTIVE_LOW>;
 		gpio-fan,speed-map =
-			<   0  0
-			 3000 15
-			 3180 14
-			 4140 13
-			 4570 12
-			 6760 11
-			 7140 10
-			 7980  9
-			 9200  8>;
+			<   0  0>,
+			<3000 15>,
+			<3180 14>,
+			<4140 13>,
+			<4570 12>,
+			<6760 11>,
+			<7140 10>,
+			<7980  9>,
+			<9200  8>;
 		alarm-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
 	};
 
diff --git a/arch/arm/boot/dts/marvell/kirkwood-synology.dtsi b/arch/arm/boot/dts/marvell/kirkwood-synology.dtsi
index 9b6666020cdd..20964eb48fd7 100644
--- a/arch/arm/boot/dts/marvell/kirkwood-synology.dtsi
+++ b/arch/arm/boot/dts/marvell/kirkwood-synology.dtsi
@@ -286,14 +286,15 @@ gpio-fan-150-32-35 {
 		gpios = <&gpio1 0 GPIO_ACTIVE_HIGH
 			 &gpio1 1 GPIO_ACTIVE_HIGH
 			 &gpio1 2 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <    0 0
-				       2200 1
-				       2500 2
-				       3000 4
-				       3300 3
-				       3700 5
-				       3800 6
-				       4200 7 >;
+		gpio-fan,speed-map =
+				<   0 0>,
+				<2200 1>,
+				<2500 2>,
+				<3000 4>,
+				<3300 3>,
+				<3700 5>,
+				<3800 6>,
+				<4200 7>;
 	};
 
 	gpio-fan-150-15-18 {
@@ -306,14 +307,15 @@ gpio-fan-150-15-18 {
 			 &gpio0 16 GPIO_ACTIVE_HIGH
 			 &gpio0 17 GPIO_ACTIVE_HIGH>;
 		alarm-gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <    0 0
-				       2200 1
-				       2500 2
-				       3000 4
-				       3300 3
-				       3700 5
-				       3800 6
-				       4200 7 >;
+		gpio-fan,speed-map =
+				<   0 0>,
+				<2200 1>,
+				<2500 2>,
+				<3000 4>,
+				<3300 3>,
+				<3700 5>,
+				<3800 6>,
+				<4200 7>;
 	};
 
 	gpio-fan-100-32-35 {
@@ -326,14 +328,15 @@ gpio-fan-100-32-35 {
 			 &gpio1 1 GPIO_ACTIVE_HIGH
 			 &gpio1 2 GPIO_ACTIVE_HIGH>;
 		alarm-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <    0 0
-				       2500 1
-				       3100 2
-				       3800 3
-				       4600 4
-				       4800 5
-				       4900 6
-				       5000 7 >;
+		gpio-fan,speed-map =
+				<   0 0>,
+				<2500 1>,
+				<3100 2>,
+				<3800 3>,
+				<4600 4>,
+				<4800 5>,
+				<4900 6>,
+				<5000 7>;
 	};
 
 	gpio-fan-100-15-18 {
@@ -346,14 +349,15 @@ gpio-fan-100-15-18 {
 			 &gpio0 16 GPIO_ACTIVE_HIGH
 			 &gpio0 17 GPIO_ACTIVE_HIGH>;
 		alarm-gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <    0 0
-				       2500 1
-				       3100 2
-				       3800 3
-				       4600 4
-				       4800 5
-				       4900 6
-				       5000 7 >;
+		gpio-fan,speed-map =
+				<   0 0>,
+				<2500 1>,
+				<3100 2>,
+				<3800 3>,
+				<4600 4>,
+				<4800 5>,
+				<4900 6>,
+				<5000 7>;
 	};
 
 	gpio-fan-100-15-35-1 {
@@ -366,14 +370,15 @@ gpio-fan-100-15-35-1 {
 			 &gpio0 16 GPIO_ACTIVE_HIGH
 			 &gpio0 17 GPIO_ACTIVE_HIGH>;
 		alarm-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <    0 0
-				       2500 1
-				       3100 2
-				       3800 3
-				       4600 4
-				       4800 5
-				       4900 6
-				       5000 7 >;
+		gpio-fan,speed-map =
+				<   0 0>,
+				<2500 1>,
+				<3100 2>,
+				<3800 3>,
+				<4600 4>,
+				<4800 5>,
+				<4900 6>,
+				<5000 7>;
 	};
 
 	gpio-fan-100-15-35-3 {
@@ -388,14 +393,15 @@ &gpio0 16 GPIO_ACTIVE_HIGH
 		alarm-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH
 			       &gpio1 12 GPIO_ACTIVE_HIGH
 			       &gpio1 13 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <    0 0
-				       2500 1
-				       3100 2
-				       3800 3
-				       4600 4
-				       4800 5
-				       4900 6
-				       5000 7 >;
+		gpio-fan,speed-map =
+				<   0 0>,
+				<2500 1>,
+				<3100 2>,
+				<3800 3>,
+				<4600 4>,
+				<4800 5>,
+				<4900 6>,
+				<5000 7>;
 	};
 
 	gpio-leds-alarm-12 {
diff --git a/arch/arm/boot/dts/marvell/mvebu-linkstation-fan.dtsi b/arch/arm/boot/dts/marvell/mvebu-linkstation-fan.dtsi
index e172029a0c4d..a260c42dbda3 100644
--- a/arch/arm/boot/dts/marvell/mvebu-linkstation-fan.dtsi
+++ b/arch/arm/boot/dts/marvell/mvebu-linkstation-fan.dtsi
@@ -50,10 +50,10 @@ gpio_fan {
 		pinctrl-names = "default";
 
 		gpio-fan,speed-map =
-			<0		3
-			1500	2
-			3250	1
-			5000	0>;
+			<   0 3>,
+			<1500 2>,
+			<3250 1>,
+			<5000 0>;
 	};
 };
 
-- 
2.42.0



From andrew at lunn.ch  Sat Dec  2 14:42:48 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 2 Dec 2023 23:42:48 +0100
Subject: [PATCH v3 5/5] ARM: dts: marvell: make dts use gpio-fan matrix
 instead of array
In-Reply-To: <20231202222934.137191-5-david@ixit.cz>
References: <20231202222934.137191-1-david@ixit.cz>
 <20231202222934.137191-5-david@ixit.cz>
Message-ID: <cb86b7bd-7dec-42dd-8d90-fa0eea321ae1@lunn.ch>

On Sat, Dec 02, 2023 at 11:29:04PM +0100, David Heidelberg wrote:
> No functional changes.
> 
> Adjust to comply with dt-schema requirements
> and make possible to validate values.
> 
> Acked-by: Simon Guinot <simon.guinot at sequanux.org>
> Signed-off-by: David Heidelberg <david at ixit.cz>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From wahrenst at gmx.net  Sat Dec  2 15:22:16 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Sun,  3 Dec 2023 00:22:16 +0100
Subject: [PATCH V3 2/3] usb: xhci: xhci-plat: Add support for BCM2711
In-Reply-To: <20231202232217.89652-1-wahrenst@gmx.net>
References: <20231202232217.89652-1-wahrenst@gmx.net>
Message-ID: <20231202232217.89652-3-wahrenst@gmx.net>

With the introduction of a BCM2711 specific compatible, this also
needs to be added to the xHCI driver.

Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
 drivers/usb/host/xhci-plat.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index b93161374293..bc5e8f4cdadf 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -129,6 +129,9 @@ static const struct of_device_id usb_xhci_of_match[] = {
 	}, {
 		.compatible = "brcm,xhci-brcm-v2",
 		.data = &xhci_plat_brcm,
+	}, {
+		.compatible = "brcm,bcm2711-xhci",
+		.data = &xhci_plat_brcm,
 	}, {
 		.compatible = "brcm,bcm7445-xhci",
 		.data = &xhci_plat_brcm,
--
2.34.1



From wahrenst at gmx.net  Sat Dec  2 15:22:17 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Sun,  3 Dec 2023 00:22:17 +0100
Subject: [PATCH V3 3/3] ARM: dts: bcm2711: Add BCM2711 xHCI support
In-Reply-To: <20231202232217.89652-1-wahrenst@gmx.net>
References: <20231202232217.89652-1-wahrenst@gmx.net>
Message-ID: <20231202232217.89652-4-wahrenst@gmx.net>

The BCM2711 SoC also has a mostly generic xHCI. The USB port is
currently only usable on the Compute Module 4 (e.g. via IO board).
Because DWC2 and xHCI share the same PHY, we let the bootloader
enable it on demand.

Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
 arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi |  5 +++++
 arch/arm/boot/dts/broadcom/bcm2711.dtsi     | 14 ++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi b/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi
index 98817a6675b9..d233a191c139 100644
--- a/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include "bcm2835-rpi.dtsi"

+#include <dt-bindings/power/raspberrypi-power.h>
 #include <dt-bindings/reset/raspberrypi,firmware-reset.h>

 / {
@@ -76,3 +77,7 @@ &v3d {
 &vchiq {
 	interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
 };
+
+&xhci {
+	power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2711.dtsi b/arch/arm/boot/dts/broadcom/bcm2711.dtsi
index 4a379a14966d..ed5ef36e08ff 100644
--- a/arch/arm/boot/dts/broadcom/bcm2711.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm2711.dtsi
@@ -604,6 +604,20 @@ genet_mdio: mdio at e14 {
 			};
 		};

+		xhci: usb at 7e9c0000 {
+			compatible = "brcm,bcm2711-xhci";
+			reg = <0x0 0x7e9c0000 0x100000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+			/* DWC2 and this IP block share the same USB PHY,
+			 * enabling both at the same time results in lockups.
+			 * So keep this node disabled and let the bootloader
+			 * decide which interface should be enabled.
+			 */
+			status = "disabled";
+		};
+
 		v3d: gpu at 7ec00000 {
 			compatible = "brcm,2711-v3d";
 			reg = <0x0 0x7ec00000 0x4000>,
--
2.34.1



From wahrenst at gmx.net  Sat Dec  2 15:22:14 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Sun,  3 Dec 2023 00:22:14 +0100
Subject: [PATCH V3 0/3] ARM: dts: bcm2711: Add BCM2711 xHCI support
Message-ID: <20231202232217.89652-1-wahrenst@gmx.net>

In contrast to the Raspberry Pi 4, the Compute Module 4 or the IO board
does not have a VL805 USB 3.0 host controller, which is connected via
PCIe. Instead, the BCM2711 on the Compute Module provides the built-in
xHCI.

Changes in V3:
- introduce a new compatible for BCM2711 in order to make the
  power domain dependency SoC specific, which also results in
  a driver change

Changes in V2:
- adjust xHCI compatible as suggested by Justin & Florian
- keep xHCI disabled in order to let the bootloader decide which
  USB block should be enabled, which result in a drop of patch 3

Stefan Wahren (3):
  dt-bindings: usb: xhci: add support for BCM2711
  usb: xhci: xhci-plat: Add support for BCM2711
  ARM: dts: bcm2711: Add BCM2711 xHCI support

 .../devicetree/bindings/usb/generic-xhci.yaml | 21 ++++++++++++++++---
 arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi   |  5 +++++
 arch/arm/boot/dts/broadcom/bcm2711.dtsi       | 14 +++++++++++++
 drivers/usb/host/xhci-plat.c                  |  3 +++
 4 files changed, 40 insertions(+), 3 deletions(-)

--
2.34.1



From wahrenst at gmx.net  Sat Dec  2 15:22:15 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Sun,  3 Dec 2023 00:22:15 +0100
Subject: [PATCH V3 1/3] dt-bindings: usb: xhci: add support for BCM2711
In-Reply-To: <20231202232217.89652-1-wahrenst@gmx.net>
References: <20231202232217.89652-1-wahrenst@gmx.net>
Message-ID: <20231202232217.89652-2-wahrenst@gmx.net>

The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
but also requires a power domain. So introduce a new compatible
and the specific constraints. Since the key allOf can only occur
once, merge the reference below.

Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
 .../devicetree/bindings/usb/generic-xhci.yaml | 21 ++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
index 594ebb3ee432..b6e10b0a3c24 100644
--- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
@@ -9,9 +9,6 @@ title: USB xHCI Controller
 maintainers:
   - Mathias Nyman <mathias.nyman at intel.com>

-allOf:
-  - $ref: usb-xhci.yaml#
-
 properties:
   compatible:
     oneOf:
@@ -28,6 +25,7 @@ properties:
       - description: Broadcom STB SoCs with xHCI
         enum:
           - brcm,xhci-brcm-v2
+          - brcm,bcm2711-xhci
           - brcm,bcm7445-xhci
       - description: Generic xHCI device
         const: xhci-platform
@@ -49,6 +47,9 @@ properties:
       - const: core
       - const: reg

+  power-domains:
+    maxItems: 1
+
 unevaluatedProperties: false

 required:
@@ -56,6 +57,20 @@ required:
   - reg
   - interrupts

+allOf:
+  - $ref: usb-xhci.yaml#
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: brcm,bcm2711-xhci
+    then:
+      required:
+        - power-domains
+    else:
+      properties:
+        power-domains: false
+
 examples:
   - |
     usb at f0931000 {
--
2.34.1



From bp at alien8.de  Sat Dec  2 15:23:19 2023
From: bp at alien8.de (Borislav Petkov)
Date: Sun, 3 Dec 2023 00:23:19 +0100
Subject: [PATCH v2 3/4] mm: Change ghes code to allow poison of
 non-struct pfn
In-Reply-To: <20231123003513.24292-4-ankita@nvidia.com>
References: <20231123003513.24292-1-ankita@nvidia.com>
 <20231123003513.24292-4-ankita@nvidia.com>
Message-ID: <20231202232319.GAZWu8Z6gsLp1kI5Dw@fat_crate.local>

On Thu, Nov 23, 2023 at 06:05:11AM +0530, ankita at nvidia.com wrote:
> -	pfn = PHYS_PFN(physical_addr);
> -	if (!pfn_valid(pfn) && !arch_is_platform_page(physical_addr)) {
> -		pr_warn_ratelimited(FW_WARN GHES_PFX
> -		"Invalid address in generic error data: %#llx\n",
> -		physical_addr);
> -		return false;
> -	}

You don't just remove a pfn valid test just because your weird device
can't stomach it - you extend it, like

  3ad6fd77a2d6 ("x86/sgx: Add check for SGX pages to ghes_do_memory_failure()")

did, for example.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette


From tsunghan.tw at gmail.com  Sat Dec  2 17:18:04 2023
From: tsunghan.tw at gmail.com (Tsung-Han Lin)
Date: Sun,  3 Dec 2023 09:18:04 +0800
Subject: [PATCH] Dcoumentation/arch/arm64: fix typo
Message-ID: <20231203011804.27694-1-tsunghan.tw@gmail.com>

Should be 'if' here.

Signed-off-by: Tsung-Han Lin <tsunghan.tw at gmail.com>
---
 Documentation/arch/arm64/arm-acpi.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/arch/arm64/arm-acpi.rst b/Documentation/arch/arm64/arm-acpi.rst
index a46c34fa9604..e59e4505d0d9 100644
--- a/Documentation/arch/arm64/arm-acpi.rst
+++ b/Documentation/arch/arm64/arm-acpi.rst
@@ -130,7 +130,7 @@ When an Arm system boots, it can either have DT information, ACPI tables,
 or in some very unusual cases, both.  If no command line parameters are used,
 the kernel will try to use DT for device enumeration; if there is no DT
 present, the kernel will try to use ACPI tables, but only if they are present.
-In neither is available, the kernel will not boot.  If acpi=force is used
+If neither is available, the kernel will not boot.  If acpi=force is used
 on the command line, the kernel will attempt to use ACPI tables first, but
 fall back to DT if there are no ACPI tables present.  The basic idea is that
 the kernel will not fail to boot unless it absolutely has no other choice.
--
2.34.1



From bagasdotme at gmail.com  Sat Dec  2 18:49:33 2023
From: bagasdotme at gmail.com (Bagas Sanjaya)
Date: Sun, 3 Dec 2023 09:49:33 +0700
Subject: [PATCH] Dcoumentation/arch/arm64: fix typo
In-Reply-To: <20231203011804.27694-1-tsunghan.tw@gmail.com>
References: <20231203011804.27694-1-tsunghan.tw@gmail.com>
Message-ID: <ZWvsvXYm5LgaSGLZ@archie.me>

On Sun, Dec 03, 2023 at 09:18:04AM +0800, Tsung-Han Lin wrote:
> Should be 'if' here.
> 
> Signed-off-by: Tsung-Han Lin <tsunghan.tw at gmail.com>
> ---
>  Documentation/arch/arm64/arm-acpi.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/arch/arm64/arm-acpi.rst b/Documentation/arch/arm64/arm-acpi.rst
> index a46c34fa9604..e59e4505d0d9 100644
> --- a/Documentation/arch/arm64/arm-acpi.rst
> +++ b/Documentation/arch/arm64/arm-acpi.rst
> @@ -130,7 +130,7 @@ When an Arm system boots, it can either have DT information, ACPI tables,
>  or in some very unusual cases, both.  If no command line parameters are used,
>  the kernel will try to use DT for device enumeration; if there is no DT
>  present, the kernel will try to use ACPI tables, but only if they are present.
> -In neither is available, the kernel will not boot.  If acpi=force is used
> +If neither is available, the kernel will not boot.  If acpi=force is used
>  on the command line, the kernel will attempt to use ACPI tables first, but
>  fall back to DT if there are no ACPI tables present.  The basic idea is that
>  the kernel will not fail to boot unless it absolutely has no other choice.

LGTM, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme at gmail.com>

-- 
An old man doll... just what I always wanted! - Clara
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231203/0acae37e/attachment.sig>

From andersson at kernel.org  Sat Dec  2 20:09:24 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Sat, 2 Dec 2023 20:09:24 -0800
Subject: [PATCH 3/6] arm64: dts: qcom: sm8550: Add GPU nodes
In-Reply-To: <6504d0d8-3087-4990-a8f3-1517eb68707b@linaro.org>
References: <20231127-topic-a7xx_dt-v1-0-a228b8122ebf@linaro.org>
 <20231127-topic-a7xx_dt-v1-3-a228b8122ebf@linaro.org>
 <6504d0d8-3087-4990-a8f3-1517eb68707b@linaro.org>
Message-ID: <y23kmalezyvwcd42jacpoksl7vh2p77e2we3jlbsfiszojmodd@uxlpmdyi3cuq>

On Mon, Nov 27, 2023 at 05:21:30PM +0100, Konrad Dybcio wrote:
> On 27.11.2023 17:20, Konrad Dybcio wrote:
> > Add the required nodes to support the A740 GPU.
> > 
> > Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
> > ---
> >  arch/arm64/boot/dts/qcom/sm8550.dtsi | 166 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 166 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > index 7bafb3d88d69..8f6641c58b3b 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > @@ -2841,6 +2841,172 @@ dispcc: clock-controller at af00000 {
> >  			#power-domain-cells = <1>;
> >  		};
> >  
> > +		gpu: gpu at 3d00000 {
> > +			compatible = "qcom,adreno-740.1", "qcom,adreno";
> The milisecond I pressed "send" I realized this is not the correct revision
> of this patch.. The compatible needs to change.
> 

I could have corrected it while applying the patch if you only included
the revision here...

Looking forward to v2.

Regards,
Bjorn


From andersson at kernel.org  Sat Dec  2 20:54:35 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Sat,  2 Dec 2023 20:54:35 -0800
Subject: (subset) [PATCH v3 00/12] RB1/QCM2290 features
In-Reply-To: <20231125-topic-rb1_feat-v3-0-4cbb567743bb@linaro.org>
References: <20231125-topic-rb1_feat-v3-0-4cbb567743bb@linaro.org>
Message-ID: <170157925828.1717511.10065827987884757444.b4-ty@kernel.org>


On Wed, 29 Nov 2023 15:43:57 +0100, Konrad Dybcio wrote:
> This series brings:
> - interconnect plumbing
> - display setup
> 
> for QCM2290/QRB2210 and
> 
> - CAN bus controller
> - HDMI display
> - wifi fw variant name
> 
> [...]

Applied, thanks!

[06/12] arm64: dts: qcom: sc7180: Add the missing MDSS icc path
        commit: 8786398f8686d1a4267ab52f830b25f17e6d62fc
[07/12] arm64: dts: qcom: sc7280: Add the missing MDSS icc path
        commit: c657056d99878c8a8ea84d5d4a9101bcb90b47f2
[08/12] arm64: dts: qcom: qcm2290: Add display nodes
        commit: a2b32096709dbf4af02675d98356a9d3ad86ff05
[09/12] arm64: dts: qcom: qcm2290: Hook up interconnects
        commit: 5b970ff0193d67da4a8d2d5fda50dd8ddb50a71e
[10/12] arm64: dts: qcom: qrb2210-rb1: Set up HDMI
        commit: 616eda24edd48b8b56516886c51d211fbfd2679b
[11/12] arm64: dts: qcom: qrb2210-rb1: Enable CAN bus controller
        commit: 252bc7ad359478dba8d77bce9502f2cc7bb547a3
[12/12] arm64: dts: qcom: qrb2210-rb1: add wifi variant property
        commit: b6a56a5a25d6273729b2b5139d58e3d390318ed2

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From tmaimon77 at gmail.com  Sun Dec  3 00:03:26 2023
From: tmaimon77 at gmail.com (Tomer Maimon)
Date: Sun, 3 Dec 2023 10:03:26 +0200
Subject: [PATCH v2] ARM: npcm: Add CPU hotplug callbacks for kexec support
In-Reply-To: <CAD_4BXgmCdc_H-XfmGnW3fa6H=cbONma6QzUiofNVZWJtcBwOg@mail.gmail.com>
References: <20231102002453.1299195-1-william@wkennington.com>
 <20231102101009.15104-1-william@wkennington.com> <CAD_4BXgmCdc_H-XfmGnW3fa6H=cbONma6QzUiofNVZWJtcBwOg@mail.gmail.com>
Message-ID: <CAP6Zq1gG8d8AEPQZ0izrYdY66fxE3ec57jFDzBK5q6Zrji74qA@mail.gmail.com>

Hi William,

On Sat, 2 Dec 2023 at 01:51, William Kennington <william at wkennington.com> wrote:
>
> On Thu, Nov 2, 2023 at 3:10?AM William A. Kennington III
> <william at wkennington.com> wrote:
> >
> > From: Brian Ma <chma0 at nuvoton.com>
> >
> > Add callbacks required for kexec to function. The NPCM7xx does
> > not expose controls for powering down CPU cores, so just wait in idle
> > loop.
> >
> > Signed-off-by: Brian Ma <chma0 at nuvoton.com>
> > Signed-off-by: William A. Kennington III <william at wkennington.com>
> > ---
> >  arch/arm/mach-npcm/platsmp.c | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/arch/arm/mach-npcm/platsmp.c b/arch/arm/mach-npcm/platsmp.c
> > index 41891d3aa124..6cc7b5894f08 100644
> > --- a/arch/arm/mach-npcm/platsmp.c
> > +++ b/arch/arm/mach-npcm/platsmp.c
> > @@ -69,10 +69,27 @@ static void __init npcm7xx_smp_prepare_cpus(unsigned int max_cpus)
> >
> >         iounmap(scu_base);
> >  }
> > +#ifdef CONFIG_HOTPLUG_CPU
> > +static void npcm7xx_cpu_die(unsigned int cpu)
> > +{
> > +       while (1)
> > +               cpu_do_idle();
> > +}
> > +
> > +static int npcm7xx_cpu_kill(unsigned int l_cpu)
> > +{
> > +       return 1;
> > +}
> > +#endif
> > +
> >
> >  static struct smp_operations npcm7xx_smp_ops __initdata = {
> >         .smp_prepare_cpus = npcm7xx_smp_prepare_cpus,
> >         .smp_boot_secondary = npcm7xx_smp_boot_secondary,
> > +#ifdef CONFIG_HOTPLUG_CPU
> > +       .cpu_die                        = npcm7xx_cpu_die,
> > +       .cpu_kill                       = npcm7xx_cpu_kill,
> > +#endif
> >  };
> >
> >  CPU_METHOD_OF_DECLARE(npcm7xx_smp, "nuvoton,npcm750-smp", &npcm7xx_smp_ops);
> > --
> > 2.42.0.820.g83a721a137-goog
> >'
>
> Mind taking another look? This should be updated accordingly.

Reviewed-by: Tomer Maimon <tmaimon77 at gmail.com>

Best regards,

Tomer


From yoong.siang.song at intel.com  Sun Dec  3 00:58:05 2023
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Sun, 3 Dec 2023 08:58:05 +0000
Subject: [PATCH bpf-next 1/3] xsk: add launch time support to XDP Tx
 metadata
In-Reply-To: <20231201192846.15c9e64e@kernel.org>
References: <20231130162028.852006-1-yoong.siang.song@intel.com>
	<20231130162028.852006-2-yoong.siang.song@intel.com>
 <20231201192846.15c9e64e@kernel.org>
Message-ID: <PH0PR11MB5830B462F82BFFE7E8958B64D887A@PH0PR11MB5830.namprd11.prod.outlook.com>

On Saturday, December 2, 2023 11:29 AM, Jakub Kicinski wrote:
>On Fri,  1 Dec 2023 00:20:26 +0800 Song Yoong Siang wrote:
>> +        name: launch-time
>> +        doc:
>> +          HW Time-Based Scheduling (TBS) is supported by the driver.
>
>Does this mean fifo "gating" or HW can do reordering?

Yes, HW will do reordering according to the value of launch time.
 


From yoong.siang.song at intel.com  Sun Dec  3 01:16:55 2023
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Sun, 3 Dec 2023 09:16:55 +0000
Subject: [PATCH bpf-next v2 0/3] xsk: TX metadata txtime support
In-Reply-To: <656b3c0ebb103_1a6a2c2947d@willemb.c.googlers.com.notmuch>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <d4f99931-442c-4cd7-b3cf-80d8681a2986@kernel.org>
 <PH0PR11MB58306C2E50009A6E22F9DAD3D881A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <6569f71bad00d_138af5294d@willemb.c.googlers.com.notmuch>
 <179a4581-f7df-4eb1-ab67-8d65f856a2fe@kernel.org>
 <656b3c0ebb103_1a6a2c2947d@willemb.c.googlers.com.notmuch>
Message-ID: <PH0PR11MB5830F6B01E7F06A5337E214AD887A@PH0PR11MB5830.namprd11.prod.outlook.com>

On Saturday, December 2, 2023 10:16 PM, Willem de Bruijn wrote:
>Jesper Dangaard Brouer wrote:
>>
>>
>> On 12/1/23 16:09, Willem de Bruijn wrote:
>> > Song, Yoong Siang wrote:
>> >> On Friday, December 1, 2023 6:46 PM, Jesper Dangaard Brouer
><hawk at kernel.org> wrote:
>> >>> On 12/1/23 07:24, Song Yoong Siang wrote:
>> >>>> This series expands XDP TX metadata framework to include ETF HW offload.
>> >>>>
>> >>>> Changes since v1:
>> >>>> - rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF)
>> >>>> - rename launch-time to txtime
>> >>>>
>> >>>
>> >>> I strongly disagree with this renaming (sorry to disagree with Willem).
>> >>>
>> >>> The i210 and i225 chips call this LaunchTime in their programmers
>> >>> datasheets, and even in the driver code[1].
>> >>>
>> >>> Using this "txtime" name in the code is also confusing, because how can
>> >>> people reading the code know the difference between:
>> >>>   - tmo_request_timestamp and tmo_request_txtime
>> >>>
>> >>
>> >> Hi Jesper and Willem,
>> >>
>> >> How about using "launch_time" for the flag/variable and
>> >> "Earliest TxTime First" for the description/comments?
>> >
>>
>> I don't follow why you are calling the feature:
>>   - "Earliest TxTime First" (ETF).
>>   - AFAIK this just reference an qdisc name (that most don't know exists)
>>
>>
>> > I don't particularly care which term we use, as long as we're
>> > consistent. Especially, don't keep introducing new synonyms.
>> >
>> > The fact that one happens to be one vendor's marketing term does not
>> > make it preferable, IMHO. On the contrary.
>> >
>>
>> These kind of hardware features are defined as part of Time Sensitive
>> Networking (TSN).
>> I believe these TSN features are defined as part of IEEE 802.1Qbv (2015)
>> and according to Wikipedia[2] incorporated into IEEE 802.1Q.
>>
>> [2] https://en.wikipedia.org/wiki/Time-Sensitive_Networking
>>
>>
>> > SO_TXTIME is in the ABI, and EDT has been used publicly in kernel
>> > patches and conference talks, e.g., Van Jacobson's Netdev 0x12
>> > keynote. Those are vendor agnostic commonly used terms.
>> >
>>
>> I agree that EDT (Earliest Departure Time) have become a thing and term
>> in our community.
>> We could associate this feature with this.
>> I do fear what hardware behavior will be it if I e.g. ask it to send a
>> packet 2 sec in the future on i225 which max support 1 sec.
>> Will hardware send it at 1 sec?
>> Because then I'm violating the *Earliest* Departure Time.
>
>That should definitely not happen. At least not on a device that
>implements EDT semantics.
>
>This relates to Jakub's question in the previous thread on whether
>this mechanism allows out-of-order transmission or maintains FIFO
>behavior. That really is device specific.
>
>Older devices only support this for low rate (PTP) and with a small
>fixed number of outstanding requests. For pacing offload, devices need
>to support up to linerate and out-of-order.
>
>I don't think we want to enforce either in software, as the hardware
>is already out there. But it would be good if drivers can somehow
>label these capabilities. Including programmable horizon.
>
>It is up to the qdisc to ensure that it does not pass packets to the
>device beyond its horizon.
>
>ETF and FQ already have a concept of horizon. And a way to queue
>errors for packets out of bound (SO_EE_CODE_TXTIME_..).
>
>>
>> > But as long as Launch Time is not an Intel only trademark, fine to
>> > select that.
>>
>> The IEEE 802.1Qbv is sometimes called Time-Aware Shaper (TAS), but I
>> don't like to for us to name this after this.  This features is simply
>> taking advantage of exposing one of the hardware building blocks
>> (controlling/setting packet "launch time") that can be used for
>> implementing a TAS.
>>
>> I like the name "launch time" because it doesn't get easily confused
>> with other timestamps, and intuitively describes packet will be send at
>> a specific time (likely in future).
>>
>> --Jesper
>
>Understood on your point that txtime and tx_timestamp are too similar.
>As said, I don't care strongly. Launch time sounds fine to me. Others
>can speak up if they disagree.
>
>I take launch time as a less strict than EDT: it is a request to send
>at a certain time, with no strict definition on uncertainty. While EDT
>more strictly ensures that a packet is not sent before the timestamp.

Thanks for the deep discussion and information. I agree with launch time too.
I will submit v3 with launch time so that others can review on the
new naming and provide their feedback. 

From yoong.siang.song at intel.com  Sun Dec  3 02:11:01 2023
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Sun, 3 Dec 2023 10:11:01 +0000
Subject: [PATCH bpf-next v2 2/3] net: stmmac: Add txtime support to XDP ZC
In-Reply-To: <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <20231201062421.1074768-3-yoong.siang.song@intel.com>
 <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org>
Message-ID: <PH0PR11MB5830F08AC202C42501D986C0D887A@PH0PR11MB5830.namprd11.prod.outlook.com>

On Friday, December 1, 2023 11:02 PM, Jesper Dangaard Brouer wrote:
>On 12/1/23 07:24, Song Yoong Siang wrote:
>> This patch enables txtime support to XDP zero copy via XDP Tx
>> metadata framework.
>>
>> Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
>> ---
>>   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
>>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++
>>   2 files changed, 15 insertions(+)
>
>I think we need to see other drivers using this new feature to evaluate
>if API is sane.
>
>I suggest implementing this for igc driver (chip i225) and also for igb
>(i210 chip) that both support this kind of LaunchTime feature in HW.
>
>The API and stmmac driver takes a u64 as time.
>I'm wondering how this applies to i210 that[1] have 25-bit for
>LaunchTime (with 32 nanosec granularity) limiting LaunchTime max 0.5
>second into the future.
>And i225 that [1] have 30-bit max 1 second into the future.
>
>
>[1]
>https://github.com/xdp-project/xdp-
>project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org

I am using u64 for launch time because existing EDT framework is using it.
Refer to struct sk_buff below. Both u64 and ktime_t can be used as launch time.
I choose u64 because ktime_t often requires additional type conversion and
we didn't expect negative value of time.

include/linux/skbuff.h-744- *   @tstamp: Time we arrived/left
include/linux/skbuff.h:745- *   @skb_mstamp_ns: (aka @tstamp) earliest departure time; start point
include/linux/skbuff.h-746- *           for retransmit timer
--
include/linux/skbuff.h-880-     union {
include/linux/skbuff.h-881-             ktime_t         tstamp;
include/linux/skbuff.h:882-             u64             skb_mstamp_ns; /* earliest departure time */
include/linux/skbuff.h-883-     };

tstamp/skb_mstamp_ns are used by various drivers for launch time support
on normal packet, so I think u64 should be "friendly" to all the drivers. For an
example, igc driver will take launch time from tstamp and recalculate it 
accordingly (i225 expect user to program "delta time" instead of "time" into
HW register).

drivers/net/ethernet/intel/igc/igc_main.c-1602- txtime = skb->tstamp;
drivers/net/ethernet/intel/igc/igc_main.c-1603- skb->tstamp = ktime_set(0, 0);
drivers/net/ethernet/intel/igc/igc_main.c:1604- launch_time = igc_tx_launchtime(tx_ring, txtime, &first_flag, &insert_empty);

Do you think this is enough to say the API is sane?


From conor at kernel.org  Sun Dec  3 03:06:43 2023
From: conor at kernel.org (Conor Dooley)
Date: Sun, 3 Dec 2023 11:06:43 +0000
Subject: [PATCH V3 1/3] dt-bindings: usb: xhci: add support for BCM2711
In-Reply-To: <20231202232217.89652-2-wahrenst@gmx.net>
References: <20231202232217.89652-1-wahrenst@gmx.net>
 <20231202232217.89652-2-wahrenst@gmx.net>
Message-ID: <20231203-chair-zen-afb8b280ca2f@spud>

On Sun, Dec 03, 2023 at 12:22:15AM +0100, Stefan Wahren wrote:
> The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
> but also requires a power domain. So introduce a new compatible
> and the specific constraints. Since the key allOf can only occur
> once, merge the reference below.
> 
> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>

Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> ---
>  .../devicetree/bindings/usb/generic-xhci.yaml | 21 ++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> index 594ebb3ee432..b6e10b0a3c24 100644
> --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> @@ -9,9 +9,6 @@ title: USB xHCI Controller
>  maintainers:
>    - Mathias Nyman <mathias.nyman at intel.com>
> 
> -allOf:
> -  - $ref: usb-xhci.yaml#
> -
>  properties:
>    compatible:
>      oneOf:
> @@ -28,6 +25,7 @@ properties:
>        - description: Broadcom STB SoCs with xHCI
>          enum:
>            - brcm,xhci-brcm-v2
> +          - brcm,bcm2711-xhci
>            - brcm,bcm7445-xhci
>        - description: Generic xHCI device
>          const: xhci-platform
> @@ -49,6 +47,9 @@ properties:
>        - const: core
>        - const: reg
> 
> +  power-domains:
> +    maxItems: 1
> +
>  unevaluatedProperties: false
> 
>  required:
> @@ -56,6 +57,20 @@ required:
>    - reg
>    - interrupts
> 
> +allOf:
> +  - $ref: usb-xhci.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: brcm,bcm2711-xhci
> +    then:
> +      required:
> +        - power-domains
> +    else:
> +      properties:
> +        power-domains: false
> +
>  examples:
>    - |
>      usb at f0931000 {
> --
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231203/77de2718/attachment.sig>

From conor at kernel.org  Sun Dec  3 03:11:09 2023
From: conor at kernel.org (Conor Dooley)
Date: Sun, 3 Dec 2023 11:11:09 +0000
Subject: [PATCH V3 1/3] dt-bindings: usb: xhci: add support for BCM2711
In-Reply-To: <20231203-chair-zen-afb8b280ca2f@spud>
References: <20231202232217.89652-1-wahrenst@gmx.net>
 <20231202232217.89652-2-wahrenst@gmx.net>
 <20231203-chair-zen-afb8b280ca2f@spud>
Message-ID: <20231203-traffic-aide-cb03afdb3546@spud>

On Sun, Dec 03, 2023 at 11:06:43AM +0000, Conor Dooley wrote:
> On Sun, Dec 03, 2023 at 12:22:15AM +0100, Stefan Wahren wrote:
> > The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
> > but also requires a power domain.
Hmm
This & the driver change makes it look like your compatible setup should
be `compatible = "brcm,bcm2711-xhci", "brcm,xhci-brcm-v2";.
If the pattern in this patch was repeated, we'd have to modify the
driver like your 2nd patch does for each and new broadcom system that
needs the power domain.


> > So introduce a new compatible
> > and the specific constraints. Since the key allOf can only occur
> > once, merge the reference below.
> > 
> > Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
> 
> Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
> 
> Cheers,
> Conor.
> 
> > ---
> >  .../devicetree/bindings/usb/generic-xhci.yaml | 21 ++++++++++++++++---
> >  1 file changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > index 594ebb3ee432..b6e10b0a3c24 100644
> > --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > @@ -9,9 +9,6 @@ title: USB xHCI Controller
> >  maintainers:
> >    - Mathias Nyman <mathias.nyman at intel.com>
> > 
> > -allOf:
> > -  - $ref: usb-xhci.yaml#
> > -
> >  properties:
> >    compatible:
> >      oneOf:
> > @@ -28,6 +25,7 @@ properties:
> >        - description: Broadcom STB SoCs with xHCI
> >          enum:
> >            - brcm,xhci-brcm-v2
> > +          - brcm,bcm2711-xhci
> >            - brcm,bcm7445-xhci
> >        - description: Generic xHCI device
> >          const: xhci-platform
> > @@ -49,6 +47,9 @@ properties:
> >        - const: core
> >        - const: reg
> > 
> > +  power-domains:
> > +    maxItems: 1
> > +
> >  unevaluatedProperties: false
> > 
> >  required:
> > @@ -56,6 +57,20 @@ required:
> >    - reg
> >    - interrupts
> > 
> > +allOf:
> > +  - $ref: usb-xhci.yaml#
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: brcm,bcm2711-xhci
> > +    then:
> > +      required:
> > +        - power-domains
> > +    else:
> > +      properties:
> > +        power-domains: false
> > +
> >  examples:
> >    - |
> >      usb at f0931000 {
> > --
> > 2.34.1
> > 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231203/a2f387ea/attachment-0001.sig>

From dmitry.baryshkov at linaro.org  Sun Dec  3 03:26:23 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sun,  3 Dec 2023 14:26:23 +0300
Subject: [PATCH v3 00/12] RB1/QCM2290 features
In-Reply-To: <20231125-topic-rb1_feat-v3-0-4cbb567743bb@linaro.org>
References: <20231125-topic-rb1_feat-v3-0-4cbb567743bb@linaro.org>
Message-ID: <170160265544.1305159.7127586815591334441.b4-ty@linaro.org>


On Wed, 29 Nov 2023 15:43:57 +0100, Konrad Dybcio wrote:
> This series brings:
> - interconnect plumbing
> - display setup
> 
> for QCM2290/QRB2210 and
> 
> - CAN bus controller
> - HDMI display
> - wifi fw variant name
> 
> [...]

Applied, thanks!

[01/12] dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat
        https://gitlab.freedesktop.org/lumag/msm/-/commit/25daacc60394
[02/12] dt-bindings: display: msm: Add reg bus and rotator interconnects
        https://gitlab.freedesktop.org/lumag/msm/-/commit/a1ed5860efd3

Best regards,
-- 
Dmitry Baryshkov <dmitry.baryshkov at linaro.org>


From conor at kernel.org  Sun Dec  3 03:26:50 2023
From: conor at kernel.org (Conor Dooley)
Date: Sun, 3 Dec 2023 11:26:50 +0000
Subject: [PATCH 1/2] dt-bindings: arm: rockchip: Add Theobroma-Systems
 Jaguar SBC
In-Reply-To: <20231201191103.343097-2-heiko@sntech.de>
References: <20231201191103.343097-1-heiko@sntech.de>
 <20231201191103.343097-2-heiko@sntech.de>
Message-ID: <20231203-landlady-capped-2d2b0f6c26b8@spud>

On Fri, Dec 01, 2023 at 08:11:02PM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner at cherry.de>
> 
> Add the binding for the Jaguar board from Theobroma-Systems.
> 

Acked-by: Conor Dooley <conor.dooley at microchip.com>

> Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>

GL chief :)
Conor.

> ---
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 5f7c6c4aad8f..44181a36c5d5 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -875,6 +875,11 @@ properties:
>            - const: tsd,rk3399-puma-haikou
>            - const: rockchip,rk3399
>  
> +      - description: Theobroma Systems RK3588-SBC Jaguar
> +        items:
> +          - const: tsd,rk3588-jaguar
> +          - const: rockchip,rk3588
> +
>        - description: Tronsmart Orion R68 Meta
>          items:
>            - const: tronsmart,orion-r68-meta
> -- 
> 2.39.2
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231203/4a8b1b1f/attachment.sig>

From alexandru.elisei at arm.com  Sun Dec  3 04:14:30 2023
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Sun, 3 Dec 2023 12:14:30 +0000
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <20231129084424.GA2988384@tiffany>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <CGME20231119165840epcas2p2c99f1dd358f716c103c16f47cc23bf2a@epcas2p2.samsung.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com>
 <20231129084424.GA2988384@tiffany>
Message-ID: <ZWxxJipc2STxHHKn@raptor>

Hi,

On Wed, Nov 29, 2023 at 05:44:24PM +0900, Hyesoo Yu wrote:
> Hello.
> 
> On Sun, Nov 19, 2023 at 04:57:05PM +0000, Alexandru Elisei wrote:
> > Allow the kernel to get the size and location of the MTE tag storage
> > regions from the DTB. This memory is marked as reserved for now.
> > 
> > The DTB node for the tag storage region is defined as:
> > 
> >         tags0: tag-storage at 8f8000000 {
> >                 compatible = "arm,mte-tag-storage";
> >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> >                 block-size = <0x1000>;
> >                 memory = <&memory0>;	// Associated tagged memory node
> >         };
> >
> 
> How about using compatible = "shared-dma-pool" like below ?
> 
> &reserved_memory {
> 	tags0: tag0 at 8f8000000 {
> 		compatible = "arm,mte-tag-storage";
>         	reg = <0x08 0xf8000000 0x00 0x4000000>;
> 	};
> }
> 
> tag-storage {
>         compatible = "arm,mte-tag-storage";
> 	memory-region = <&tag>;
>         memory = <&memory0>;
> 	block-size = <0x1000>;
> }
> 
> And then, the activation of CMA would be performed in the CMA code.
> We just can get the region information from memory-region and allocate it directly
> like alloc_contig_range, take_page_off_buddy. It seems like we can remove a lots of code.

Played with reserved_mem a bit. I don't think that's the correct path
forward.

The location of the tag storage is a hardware property, independent of how
Linux is configured.

early_init_fdt_scan_reserved_mem() is called from arm64_memblock_init(),
**after** the kernel enforces an upper address for various reasons. One of
the reasons can be that it's been compiled with 39 bits VA.

After early_init_fdt_scan_reserved_mem() returns, the kernel sets the
maximum address, stored in the variable "high_memory".

What can happen is that tag storage is present at an address above the
maximum addressable by the kernel, and the CMA code will trigger an
unrecovrable page fault.

I was able to trigger this with the dts change:

diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
index 60472d65a355..201359d014e4 100644
--- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
+++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
@@ -183,6 +183,13 @@ vram: vram at 18000000 {
                        reg = <0x00000000 0x18000000 0 0x00800000>;
                        no-map;
                };
+
+
+               linux,cma {
+                       compatible = "shared-dma-pool";
+                       reg = <0x100 0x0 0x00 0x4000000>;
+                       reusable;
+               };
        };

        gic: interrupt-controller at 2f000000 {

And the error I got:

[    0.000000] Reserved memory: created CMA memory pool at 0x0000010000000000, size 64 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000] OF: reserved mem: 0x0000010000000000..0x0000010003ffffff (65536 KiB) map reusable linux,cma
[..]
[    0.793193] WARNING: CPU: 0 PID: 1 at mm/cma.c:111 cma_init_reserved_areas+0xa8/0x378
[..]
[    0.806945] Unable to handle kernel paging request at virtual address 00000001fe000000
[    0.807277] Mem abort info:
[    0.807277]   ESR = 0x0000000096000005
[    0.807693]   EC = 0x25: DABT (current EL), IL = 32 bits
[    0.808110]   SET = 0, FnV = 0
[    0.808443]   EA = 0, S1PTW = 0
[    0.808526]   FSC = 0x05: level 1 translation fault
[    0.808943] Data abort info:
[    0.808943]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[    0.809360]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    0.809776]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    0.810221] [00000001fe000000] user address but active_mm is swapper
[..]
[    0.820887] Call trace:
[    0.821027]  cma_init_reserved_areas+0xc4/0x378
[    0.821443]  do_one_initcall+0x7c/0x1c0
[    0.821860]  kernel_init_freeable+0x1bc/0x284
[    0.822277]  kernel_init+0x24/0x1dc
[    0.822693]  ret_from_fork+0x10/0x20
[    0.823554] Code: 9127a29a cb813321 d37ae421 8b030020 (f8636822)
[    0.823554] ---[ end trace 0000000000000000 ]---
[    0.824360] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    0.824443] SMP: stopping secondary CPUs
[    0.825193] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

Should reserved mem check if the reserved memory is actually addressable by
the kernel if it's not "no-map"? Should cma fail gracefully if
!pfn_valid(base_pfn)? Shold early_init_fdt_scan_reserved_mem() be moved
because arm64_bootmem_init()? I don't have the answer to any of those. And
I got a kernel panic because the kernel cannot address that memory (39 bits
VA). I don't know what would happen if the upper limit is reduced for
another reason.

What I think should happen:

1. Add the tag storage memory before any limits are enforced by
arm64_bootmem_init().

2. Call cma_declare_contiguous_nid() after arm64_bootmem_init(), because
the function will check the memory limit.

3. Have an arch initcall that checks that the CMA regions corresponding to
the tag storage have been activated successfully (cma_init_reserved_areas()
is a core initcall). If not, then don't enable tag storage.

How does that sound to you?

Thanks,
Alex

> 
> > The tag storage region represents the largest contiguous memory region that
> > holds all the tags for the associated contiguous memory region which can be
> > tagged. For example, for a 32GB contiguous tagged memory the corresponding
> > tag storage region is 1GB of contiguous memory, not two adjacent 512M of
> > tag storage memory.
> > 
> > "block-size" represents the minimum multiple of 4K of tag storage where all
> > the tags stored in the block correspond to a contiguous memory region. This
> > is needed for platforms where the memory controller interleaves tag writes
> > to memory. For example, if the memory controller interleaves tag writes for
> > 256KB of contiguous memory across 8K of tag storage (2-way interleave),
> > then the correct value for "block-size" is 0x2000. This value is a hardware
> > property, independent of the selected kernel page size.
> >
> 
> Is it considered for kernel page size like 16K page, 64K page ? The comment says
> it should be a multiple of 4K, but it should be a multiple of the "page size" more accurately.
> Please let me know if there's anything I misunderstood. :-)
> 
> 
> > Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
> > ---
> >  arch/arm64/Kconfig                       |  12 ++
> >  arch/arm64/include/asm/mte_tag_storage.h |  15 ++
> >  arch/arm64/kernel/Makefile               |   1 +
> >  arch/arm64/kernel/mte_tag_storage.c      | 256 +++++++++++++++++++++++
> >  arch/arm64/kernel/setup.c                |   7 +
> >  5 files changed, 291 insertions(+)
> >  create mode 100644 arch/arm64/include/asm/mte_tag_storage.h
> >  create mode 100644 arch/arm64/kernel/mte_tag_storage.c
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 7b071a00425d..fe8276fdc7a8 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -2062,6 +2062,18 @@ config ARM64_MTE
> >  
> >  	  Documentation/arch/arm64/memory-tagging-extension.rst.
> >  
> > +if ARM64_MTE
> > +config ARM64_MTE_TAG_STORAGE
> > +	bool "Dynamic MTE tag storage management"
> > +	help
> > +	  Adds support for dynamic management of the memory used by the hardware
> > +	  for storing MTE tags. This memory, unlike normal memory, cannot be
> > +	  tagged. When it is used to store tags for another memory location it
> > +	  cannot be used for any type of allocation.
> > +
> > +	  If unsure, say N
> > +endif # ARM64_MTE
> > +
> >  endmenu # "ARMv8.5 architectural features"
> >  
> >  menu "ARMv8.7 architectural features"
> > diff --git a/arch/arm64/include/asm/mte_tag_storage.h b/arch/arm64/include/asm/mte_tag_storage.h
> > new file mode 100644
> > index 000000000000..8f86c4f9a7c3
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/mte_tag_storage.h
> > @@ -0,0 +1,15 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2023 ARM Ltd.
> > + */
> > +#ifndef __ASM_MTE_TAG_STORAGE_H
> > +#define __ASM_MTE_TAG_STORAGE_H
> > +
> > +#ifdef CONFIG_ARM64_MTE_TAG_STORAGE
> > +void mte_tag_storage_init(void);
> > +#else
> > +static inline void mte_tag_storage_init(void)
> > +{
> > +}
> > +#endif /* CONFIG_ARM64_MTE_TAG_STORAGE */
> > +#endif /* __ASM_MTE_TAG_STORAGE_H  */
> > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> > index d95b3d6b471a..5f031bf9f8f1 100644
> > --- a/arch/arm64/kernel/Makefile
> > +++ b/arch/arm64/kernel/Makefile
> > @@ -70,6 +70,7 @@ obj-$(CONFIG_CRASH_CORE)		+= crash_core.o
> >  obj-$(CONFIG_ARM_SDE_INTERFACE)		+= sdei.o
> >  obj-$(CONFIG_ARM64_PTR_AUTH)		+= pointer_auth.o
> >  obj-$(CONFIG_ARM64_MTE)			+= mte.o
> > +obj-$(CONFIG_ARM64_MTE_TAG_STORAGE)	+= mte_tag_storage.o
> >  obj-y					+= vdso-wrap.o
> >  obj-$(CONFIG_COMPAT_VDSO)		+= vdso32-wrap.o
> >  obj-$(CONFIG_UNWIND_PATCH_PAC_INTO_SCS)	+= patch-scs.o
> > diff --git a/arch/arm64/kernel/mte_tag_storage.c b/arch/arm64/kernel/mte_tag_storage.c
> > new file mode 100644
> > index 000000000000..fa6267ef8392
> > --- /dev/null
> > +++ b/arch/arm64/kernel/mte_tag_storage.c
> > @@ -0,0 +1,256 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Support for dynamic tag storage.
> > + *
> > + * Copyright (C) 2023 ARM Ltd.
> > + */
> > +
> > +#include <linux/memblock.h>
> > +#include <linux/mm.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of_fdt.h>
> > +#include <linux/range.h>
> > +#include <linux/string.h>
> > +#include <linux/xarray.h>
> > +
> > +#include <asm/mte_tag_storage.h>
> > +
> > +struct tag_region {
> > +	struct range mem_range;	/* Memory associated with the tag storage, in PFNs. */
> > +	struct range tag_range;	/* Tag storage memory, in PFNs. */
> > +	u32 block_size;		/* Tag block size, in pages. */
> > +};
> > +
> > +#define MAX_TAG_REGIONS	32
> > +
> > +static struct tag_region tag_regions[MAX_TAG_REGIONS];
> > +static int num_tag_regions;
> > +
> > +static int __init tag_storage_of_flat_get_range(unsigned long node, const __be32 *reg,
> > +						int reg_len, struct range *range)
> > +{
> > +	int addr_cells = dt_root_addr_cells;
> > +	int size_cells = dt_root_size_cells;
> > +	u64 size;
> > +
> > +	if (reg_len / 4 > addr_cells + size_cells)
> > +		return -EINVAL;
> > +
> > +	range->start = PHYS_PFN(of_read_number(reg, addr_cells));
> > +	size = PHYS_PFN(of_read_number(reg + addr_cells, size_cells));
> > +	if (size == 0) {
> > +		pr_err("Invalid node");
> > +		return -EINVAL;
> > +	}
> > +	range->end = range->start + size - 1;
> > +
> > +	return 0;
> > +}
> > +
> > +static int __init tag_storage_of_flat_get_tag_range(unsigned long node,
> > +						    struct range *tag_range)
> > +{
> > +	const __be32 *reg;
> > +	int reg_len;
> > +
> > +	reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> > +	if (reg == NULL) {
> > +		pr_err("Invalid metadata node");
> > +		return -EINVAL;
> > +	}
> > +
> > +	return tag_storage_of_flat_get_range(node, reg, reg_len, tag_range);
> > +}
> > +
> > +static int __init tag_storage_of_flat_get_memory_range(unsigned long node, struct range *mem)
> > +{
> > +	const __be32 *reg;
> > +	int reg_len;
> > +
> > +	reg = of_get_flat_dt_prop(node, "linux,usable-memory", &reg_len);
> > +	if (reg == NULL)
> > +		reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> > +
> > +	if (reg == NULL) {
> > +		pr_err("Invalid memory node");
> > +		return -EINVAL;
> > +	}
> > +
> > +	return tag_storage_of_flat_get_range(node, reg, reg_len, mem);
> > +}
> > +
> > +struct find_memory_node_arg {
> > +	unsigned long node;
> > +	u32 phandle;
> > +};
> > +
> > +static int __init fdt_find_memory_node(unsigned long node, const char *uname,
> > +				       int depth, void *data)
> > +{
> > +	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> > +	struct find_memory_node_arg *arg = data;
> > +
> > +	if (depth != 1 || !type || strcmp(type, "memory") != 0)
> > +		return 0;
> > +
> > +	if (of_get_flat_dt_phandle(node) == arg->phandle) {
> > +		arg->node = node;
> > +		return 1;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int __init tag_storage_get_memory_node(unsigned long tag_node, unsigned long *mem_node)
> > +{
> > +	struct find_memory_node_arg arg = { 0 };
> > +	const __be32 *memory_prop;
> > +	u32 mem_phandle;
> > +	int ret, reg_len;
> > +
> > +	memory_prop = of_get_flat_dt_prop(tag_node, "memory", &reg_len);
> > +	if (!memory_prop) {
> > +		pr_err("Missing 'memory' property in the tag storage node");
> > +		return -EINVAL;
> > +	}
> > +
> > +	mem_phandle = be32_to_cpup(memory_prop);
> > +	arg.phandle = mem_phandle;
> > +
> > +	ret = of_scan_flat_dt(fdt_find_memory_node, &arg);
> > +	if (ret != 1) {
> > +		pr_err("Associated memory node not found");
> > +		return -EINVAL;
> > +	}
> > +
> > +	*mem_node = arg.node;
> > +
> > +	return 0;
> > +}
> > +
> > +static int __init tag_storage_of_flat_read_u32(unsigned long node, const char *propname,
> > +					       u32 *retval)
> > +{
> > +	const __be32 *reg;
> > +
> > +	reg = of_get_flat_dt_prop(node, propname, NULL);
> > +	if (!reg)
> > +		return -EINVAL;
> > +
> > +	*retval = be32_to_cpup(reg);
> > +	return 0;
> > +}
> > +
> > +static u32 __init get_block_size_pages(u32 block_size_bytes)
> > +{
> > +	u32 a = PAGE_SIZE;
> > +	u32 b = block_size_bytes;
> > +	u32 r;
> > +
> > +	/* Find greatest common divisor using the Euclidian algorithm. */
> > +	do {
> > +		r = a % b;
> > +		a = b;
> > +		b = r;
> > +	} while (b != 0);
> > +
> > +	return PHYS_PFN(PAGE_SIZE * block_size_bytes / a);
> > +}
> > +
> > +static int __init fdt_init_tag_storage(unsigned long node, const char *uname,
> > +				       int depth, void *data)
> > +{
> > +	struct tag_region *region;
> > +	unsigned long mem_node;
> > +	struct range *mem_range;
> > +	struct range *tag_range;
> > +	u32 block_size_bytes;
> > +	u32 nid = 0;
> > +	int ret;
> > +
> > +	if (depth != 1 || !strstr(uname, "tag-storage"))
> > +		return 0;
> > +
> > +	if (!of_flat_dt_is_compatible(node, "arm,mte-tag-storage"))
> > +		return 0;
> > +
> > +	if (num_tag_regions == MAX_TAG_REGIONS) {
> > +		pr_err("Maximum number of tag storage regions exceeded");
> > +		return -EINVAL;
> > +	}
> > +
> > +	region = &tag_regions[num_tag_regions];
> > +	mem_range = &region->mem_range;
> > +	tag_range = &region->tag_range;
> > +
> > +	ret = tag_storage_of_flat_get_tag_range(node, tag_range);
> > +	if (ret) {
> > +		pr_err("Invalid tag storage node");
> > +		return ret;
> > +	}
> > +
> > +	ret = tag_storage_get_memory_node(node, &mem_node);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = tag_storage_of_flat_get_memory_range(mem_node, mem_range);
> > +	if (ret) {
> > +		pr_err("Invalid address for associated data memory node");
> > +		return ret;
> > +	}
> > +
> > +	/* The tag region must exactly match the corresponding memory. */
> > +	if (range_len(tag_range) * 32 != range_len(mem_range)) {
> > +		pr_err("Tag storage region 0x%llx-0x%llx does not cover the memory region 0x%llx-0x%llx",
> > +		       PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->end),
> > +		       PFN_PHYS(mem_range->start), PFN_PHYS(mem_range->end));
> > +		return -EINVAL;
> > +	}
> > +
> > +	ret = tag_storage_of_flat_read_u32(node, "block-size", &block_size_bytes);
> > +	if (ret || block_size_bytes == 0) {
> > +		pr_err("Invalid or missing 'block-size' property");
> > +		return -EINVAL;
> > +	}
> > +	region->block_size = get_block_size_pages(block_size_bytes);
> > +	if (range_len(tag_range) % region->block_size != 0) {
> > +		pr_err("Tag storage region size 0x%llx is not a multiple of block size %u",
> > +		       PFN_PHYS(range_len(tag_range)), region->block_size);
> > +		return -EINVAL;
> > +	}
> > +
> 
> I was confused about the variable "block_size", The block size declared in the device tree is
> in bytes, but the actual block size used is in pages. I think the term "block_size" can cause
> confusion as it might be interpreted as bytes. If possible, I suggest changing the term "block_size"
> to something more readable, such as "block_nr_pages" (This is just a example!)
> 
> Thanks,
> Regards.
> 
> > +	ret = tag_storage_of_flat_read_u32(mem_node, "numa-node-id", &nid);
> > +	if (ret)
> > +		nid = numa_node_id();
> > +
> > +	ret = memblock_add_node(PFN_PHYS(tag_range->start), PFN_PHYS(range_len(tag_range)),
> > +				nid, MEMBLOCK_NONE);
> > +	if (ret) {
> > +		pr_err("Error adding tag memblock (%d)", ret);
> > +		return ret;
> > +	}
> > +	memblock_reserve(PFN_PHYS(tag_range->start), PFN_PHYS(range_len(tag_range)));
> > +
> > +	pr_info("Found tag storage region 0x%llx-0x%llx, block size %u pages",
> > +		PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->end), region->block_size);
> > +
> > +	num_tag_regions++;
> > +
> > +	return 0;
> > +}
> > +
> > +void __init mte_tag_storage_init(void)
> > +{
> > +	struct range *tag_range;
> > +	int i, ret;
> > +
> > +	ret = of_scan_flat_dt(fdt_init_tag_storage, NULL);
> > +	if (ret) {
> > +		for (i = 0; i < num_tag_regions; i++) {
> > +			tag_range = &tag_regions[i].tag_range;
> > +			memblock_remove(PFN_PHYS(tag_range->start), PFN_PHYS(range_len(tag_range)));
> > +		}
> > +		num_tag_regions = 0;
> > +		pr_info("MTE tag storage region management disabled");
> > +	}
> > +}
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 417a8a86b2db..1b77138c1aa5 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -42,6 +42,7 @@
> >  #include <asm/cpufeature.h>
> >  #include <asm/cpu_ops.h>
> >  #include <asm/kasan.h>
> > +#include <asm/mte_tag_storage.h>
> >  #include <asm/numa.h>
> >  #include <asm/scs.h>
> >  #include <asm/sections.h>
> > @@ -342,6 +343,12 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
> >  			   FW_BUG "Booted with MMU enabled!");
> >  	}
> >  
> > +	/*
> > +	 * Must be called before memory limits are enforced by
> > +	 * arm64_memblock_init().
> > +	 */
> > +	mte_tag_storage_init();
> > +
> >  	arm64_memblock_init();
> >  
> >  	paging_init();
> > -- 
> > 2.42.1
> > 
> > 




From tim at feathertop.org  Sun Dec  3 04:39:56 2023
From: tim at feathertop.org (Tim Lunn)
Date: Sun,  3 Dec 2023 23:39:56 +1100
Subject: [PATCH v3 0/8] Add support for Sonoff iHost RV1126 Smart Home Gateway
Message-ID: <20231203124004.2676174-1-tim@feathertop.org>


Sonoff iHost is gateway device designed to provide a Smart Home Hub,
most notably it includes builtin radios for Wifi, BT and Zigbee, which
make it suitable SBC for use with many of the open home automation
platforms. It is availabe in two versions, first is based on
Rockchip RV1126 and 4GB DDR4 RAM. There is a second version based off
the RV1109 dual core SoC and 2GB RAM.

Features:
- Rockchip RV1126 (or RV1109)
- 4GB DDR4
- 8GB eMMC
- microSD slot
- RMII Ethernet PHY
- 1x USB 2.0 Host
- 1x USB 2.0 OTG
- Realtek RTL8723DS WiFi/BT
- EFR32MG21 Silabs Zigbee radio
- Speaker/Microphone

This patch series adds the various device tree nodes required to
support this device. It also adds the initial dts for this device,
This work was largely based off the device trees for mainline
Edgeble Neu2 and downstream Rockchip rv1126-evb-v13 configs.
It has been adapted with relevant peripherals and GPIO pins for the
iHost.

Implemented in this series are most of the core periperhals including
Ethernet, Wifi, BT, Zigbee and RTC. Sound and USB will be added in a
later series.

Changes in v3:
- i2c: add code comment and clarify commit message further
- i2c: Collect ack by Heiko
- Move ethernet alias from rv1126.dtsi to board dtsi

Changes in v2:
- i2c: clarify commit message
- Address review comments from Heiko
- Split out rv1109.dtsi to new patch
- Collect Robh Ack for dt-bindings patch

Tim Lunn (8):
  ARM: dts: rockchip: rv1126: Add alternate UART pins
  ARM: dts: rockchip: rv1126: Serial aliases
  i2c: rk3x: Adjust mask/value offset for i2c2 on rv1126
  ARM: dts: rockchip: rv1126: Add i2c2 nodes
  ARM: dts: rockchip: rv1126: Split up rgmii1 pinctrl
  ARM: dts: rockchip: Add rv1109 SoC
  ARM: dts: Add Sonoff iHost Smart Home Hub
  dt-bindings: arm: rockchip: Add Sonoff iHost

 .../devicetree/bindings/arm/rockchip.yaml     |   7 +
 arch/arm/boot/dts/rockchip/Makefile           |   2 +
 .../boot/dts/rockchip/rv1109-sonoff-ihost.dts |  13 +
 arch/arm/boot/dts/rockchip/rv1109.dtsi        |  23 +
 .../dts/rockchip/rv1126-edgeble-neu2-io.dts   |   2 +-
 .../arm/boot/dts/rockchip/rv1126-pinctrl.dtsi |  72 +++-
 .../boot/dts/rockchip/rv1126-sonoff-ihost.dts |  13 +
 .../dts/rockchip/rv1126-sonoff-ihost.dtsi     | 408 ++++++++++++++++++
 arch/arm/boot/dts/rockchip/rv1126.dtsi        |  21 +
 drivers/i2c/busses/i2c-rk3x.c                 |   8 +-
 10 files changed, 553 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/boot/dts/rockchip/rv1109-sonoff-ihost.dts
 create mode 100644 arch/arm/boot/dts/rockchip/rv1109.dtsi
 create mode 100644 arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dts
 create mode 100644 arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi

-- 
2.40.1



From tim at feathertop.org  Sun Dec  3 04:39:57 2023
From: tim at feathertop.org (Tim Lunn)
Date: Sun,  3 Dec 2023 23:39:57 +1100
Subject: [PATCH v3 1/8] ARM: dts: rockchip: rv1126: Add alternate UART pins
In-Reply-To: <20231203124004.2676174-1-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
Message-ID: <20231203124004.2676174-2-tim@feathertop.org>

Add uart3m2_xfer and uart4m2_xfer pins for Rockchip RV1126. These are
used as serial ports for the indicator and Zigbee radio on the iHost.

Signed-off-by: Tim Lunn <tim at feathertop.org>
---

(no changes since v1)

 arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
index bb34b0c9cb4a..4f85b7b3fc4c 100644
--- a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
@@ -263,6 +263,14 @@ uart3m0_xfer: uart3m0-xfer {
 				/* uart3_tx_m0 */
 				<3 RK_PC6 4 &pcfg_pull_up>;
 		};
+		/omit-if-no-ref/
+		uart3m2_xfer: uart3m2-xfer {
+			rockchip,pins =
+				/* uart3_rx_m2 */
+				<3 RK_PA1 4 &pcfg_pull_up>,
+				/* uart3_tx_m2 */
+				<3 RK_PA0 4 &pcfg_pull_up>;
+		};
 	};
 	uart4 {
 		/omit-if-no-ref/
@@ -273,6 +281,14 @@ uart4m0_xfer: uart4m0-xfer {
 				/* uart4_tx_m0 */
 				<3 RK_PA4 4 &pcfg_pull_up>;
 		};
+		/omit-if-no-ref/
+		uart4m2_xfer: uart4m2-xfer {
+			rockchip,pins =
+				/* uart4_rx_m2 */
+				<1 RK_PD4 3 &pcfg_pull_up>,
+				/* uart4_tx_m2 */
+				<1 RK_PD5 3 &pcfg_pull_up>;
+		};
 	};
 	uart5 {
 		/omit-if-no-ref/
-- 
2.40.1



From tim at feathertop.org  Sun Dec  3 04:39:58 2023
From: tim at feathertop.org (Tim Lunn)
Date: Sun,  3 Dec 2023 23:39:58 +1100
Subject: [PATCH v3 2/8] ARM: dts: rockchip: rv1126: Serial aliases
In-Reply-To: <20231203124004.2676174-1-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
Message-ID: <20231203124004.2676174-3-tim@feathertop.org>

Add serial aliases for uart nodes so that serial devices are created

Signed-off-by: Tim Lunn <tim at feathertop.org>
---

Changes in v3:
- Add missing serial5 alias

 arch/arm/boot/dts/rockchip/rv1126.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index 9ccd1bad6229..adb11a43c5db 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -21,6 +21,12 @@ / {
 
 	aliases {
 		i2c0 = &i2c0;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
 	};
 
 	cpus {
-- 
2.40.1



From tim at feathertop.org  Sun Dec  3 04:39:59 2023
From: tim at feathertop.org (Tim Lunn)
Date: Sun,  3 Dec 2023 23:39:59 +1100
Subject: [PATCH v3 3/8] i2c: rk3x: Adjust mask/value offset for i2c2 on rv1126
In-Reply-To: <20231203124004.2676174-1-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
Message-ID: <20231203124004.2676174-4-tim@feathertop.org>

Rockchip RV1126 is using old style i2c controller, the i2c2
bus uses a non-sequential offset in the grf register for the
mask/value bits for this bus.

This patch fixes i2c2 bus on rv1126 SoCs.

Signed-off-by: Tim Lunn <tim at feathertop.org>
Acked-by: Heiko Stuebner <heiko at sntech.de>

---

Changes in v3:
- i2c: add code comment and clarify commit message further
- i2c: Collect ack by Heiko

Changes in v2:
- i2c: clarify commit message

 drivers/i2c/busses/i2c-rk3x.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index a044ca0c35a1..06fec2344575 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -1288,8 +1288,12 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
 			return -EINVAL;
 		}
 
-		/* 27+i: write mask, 11+i: value */
-		value = BIT(27 + bus_nr) | BIT(11 + bus_nr);
+		/* rv1126 i2c2 uses non-sequential write mask 20, value 4 */
+		if (i2c->soc_data == &rv1126_soc_data && bus_nr == 2)
+			value = BIT(20) | BIT(4);
+		else
+			/* 27+i: write mask, 11+i: value */
+			value = BIT(27 + bus_nr) | BIT(11 + bus_nr);
 
 		ret = regmap_write(grf, i2c->soc_data->grf_offset, value);
 		if (ret != 0) {
-- 
2.40.1



From tim at feathertop.org  Sun Dec  3 04:40:00 2023
From: tim at feathertop.org (Tim Lunn)
Date: Sun,  3 Dec 2023 23:40:00 +1100
Subject: [PATCH v3 4/8] ARM: dts: rockchip: rv1126: Add i2c2 nodes
In-Reply-To: <20231203124004.2676174-1-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
Message-ID: <20231203124004.2676174-5-tim@feathertop.org>

Add i2c2 node and i2c2_xfer pinctrl for Rockchip RV1126

Signed-off-by: Tim Lunn <tim at feathertop.org>
---

(no changes since v1)

 arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 10 ++++++++++
 arch/arm/boot/dts/rockchip/rv1126.dtsi         | 15 +++++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
index 4f85b7b3fc4c..167a48afa3a4 100644
--- a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
@@ -87,6 +87,16 @@ i2c0_xfer: i2c0-xfer {
 				<0 RK_PB5 1 &pcfg_pull_none_drv_level_0_smt>;
 		};
 	};
+	i2c2 {
+		/omit-if-no-ref/
+		i2c2_xfer: i2c2-xfer {
+			rockchip,pins =
+				/* i2c2_scl */
+				<0 RK_PC2 1 &pcfg_pull_none_drv_level_0_smt>,
+				/* i2c2_sda */
+				<0 RK_PC3 1 &pcfg_pull_none_drv_level_0_smt>;
+		};
+	};
 	pwm2 {
 		/omit-if-no-ref/
 		pwm2m0_pins: pwm2m0-pins {
diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index adb11a43c5db..bb603cae13df 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -21,6 +21,7 @@ / {
 
 	aliases {
 		i2c0 = &i2c0;
+		i2c2 = &i2c2;
 		serial0 = &uart0;
 		serial1 = &uart1;
 		serial2 = &uart2;
@@ -237,6 +238,20 @@ i2c0: i2c at ff3f0000 {
 		status = "disabled";
 	};
 
+	i2c2: i2c at ff400000 {
+		compatible = "rockchip,rv1126-i2c", "rockchip,rk3399-i2c";
+		reg = <0xff400000 0x1000>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+		rockchip,grf = <&pmugrf>;
+		clocks = <&pmucru CLK_I2C2>, <&pmucru PCLK_I2C2>;
+		clock-names = "i2c", "pclk";
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2c2_xfer>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
 	uart1: serial at ff410000 {
 		compatible = "rockchip,rv1126-uart", "snps,dw-apb-uart";
 		reg = <0xff410000 0x100>;
-- 
2.40.1



From tim at feathertop.org  Sun Dec  3 04:40:01 2023
From: tim at feathertop.org (Tim Lunn)
Date: Sun,  3 Dec 2023 23:40:01 +1100
Subject: [PATCH v3 5/8] ARM: dts: rockchip: rv1126: Split up rgmii1 pinctrl
In-Reply-To: <20231203124004.2676174-1-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
Message-ID: <20231203124004.2676174-6-tim@feathertop.org>

Split up the pinctrl definitions for rgmii1 so it can be shared
with devices using an RMII PHY.

Signed-off-by: Tim Lunn <tim at feathertop.org>
---

(no changes since v1)

 .../dts/rockchip/rv1126-edgeble-neu2-io.dts   |  2 +-
 .../arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 46 +++++++++++++------
 2 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/rockchip/rv1126-edgeble-neu2-io.dts b/arch/arm/boot/dts/rockchip/rv1126-edgeble-neu2-io.dts
index f09be8405964..0c2396b8f8db 100644
--- a/arch/arm/boot/dts/rockchip/rv1126-edgeble-neu2-io.dts
+++ b/arch/arm/boot/dts/rockchip/rv1126-edgeble-neu2-io.dts
@@ -61,7 +61,7 @@ &gmac {
 	phy-mode = "rgmii";
 	phy-supply = <&vcc_3v3>;
 	pinctrl-names = "default";
-	pinctrl-0 = <&rgmiim1_pins &clk_out_ethernetm1_pins>;
+	pinctrl-0 = <&rgmiim1_miim &rgmiim1_bus2 &rgmiim1_bus4 &clk_out_ethernetm1_pins>;
 	tx_delay = <0x2a>;
 	rx_delay = <0x1a>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
index 167a48afa3a4..06b1d7f2d858 100644
--- a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
@@ -115,36 +115,56 @@ pwm11m0_pins: pwm11m0-pins {
 	};
 	rgmii {
 		/omit-if-no-ref/
-		rgmiim1_pins: rgmiim1-pins {
+		rgmiim1_miim: rgmiim1-miim {
 			rockchip,pins =
 				/* rgmii_mdc_m1 */
 				<2 RK_PC2 2 &pcfg_pull_none>,
 				/* rgmii_mdio_m1 */
-				<2 RK_PC1 2 &pcfg_pull_none>,
-				/* rgmii_rxclk_m1 */
-				<2 RK_PD3 2 &pcfg_pull_none>,
+				<2 RK_PC1 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		rgmiim1_rxer: rgmiim1-rxer {
+			rockchip,pins =
+				/* rgmii_rxer_m1 */
+				<2 RK_PC0 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		rgmiim1_bus2: rgmiim1-bus2 {
+			rockchip,pins =
 				/* rgmii_rxd0_m1 */
 				<2 RK_PB5 2 &pcfg_pull_none>,
 				/* rgmii_rxd1_m1 */
 				<2 RK_PB6 2 &pcfg_pull_none>,
-				/* rgmii_rxd2_m1 */
-				<2 RK_PC7 2 &pcfg_pull_none>,
-				/* rgmii_rxd3_m1 */
-				<2 RK_PD0 2 &pcfg_pull_none>,
 				/* rgmii_rxdv_m1 */
 				<2 RK_PB4 2 &pcfg_pull_none>,
-				/* rgmii_txclk_m1 */
-				<2 RK_PD2 2 &pcfg_pull_none_drv_level_3>,
 				/* rgmii_txd0_m1 */
 				<2 RK_PC3 2 &pcfg_pull_none_drv_level_3>,
 				/* rgmii_txd1_m1 */
 				<2 RK_PC4 2 &pcfg_pull_none_drv_level_3>,
+				/* rgmii_txen_m1 */
+				<2 RK_PC6 2 &pcfg_pull_none_drv_level_3>;
+		};
+		/omit-if-no-ref/
+		rgmiim1_bus4: rgmiim1-bus4 {
+			rockchip,pins =
+				/* rgmii_rxclk_m1 */
+				<2 RK_PD3 2 &pcfg_pull_none>,
+				/* rgmii_rxd2_m1 */
+				<2 RK_PC7 2 &pcfg_pull_none>,
+				/* rgmii_rxd3_m1 */
+				<2 RK_PD0 2 &pcfg_pull_none>,
+				/* rgmii_txclk_m1 */
+				<2 RK_PD2 2 &pcfg_pull_none_drv_level_3>,
 				/* rgmii_txd2_m1 */
 				<2 RK_PD1 2 &pcfg_pull_none_drv_level_3>,
 				/* rgmii_txd3_m1 */
-				<2 RK_PA4 2 &pcfg_pull_none_drv_level_3>,
-				/* rgmii_txen_m1 */
-				<2 RK_PC6 2 &pcfg_pull_none_drv_level_3>;
+				<2 RK_PA4 2 &pcfg_pull_none_drv_level_3>;
+		};
+		/omit-if-no-ref/
+		rgmiim1_mclkinout: rgmiim1-mclkinout {
+			rockchip,pins =
+				/* rgmii_clk_m1 */
+				<2 RK_PB7 2 &pcfg_pull_none>;
 		};
 	};
 	sdmmc0 {
-- 
2.40.1



From tim at feathertop.org  Sun Dec  3 04:40:02 2023
From: tim at feathertop.org (Tim Lunn)
Date: Sun,  3 Dec 2023 23:40:02 +1100
Subject: [PATCH v3 6/8] ARM: dts: rockchip: Add rv1109 SoC
In-Reply-To: <20231203124004.2676174-1-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
Message-ID: <20231203124004.2676174-7-tim@feathertop.org>

The Rockchip rv1109 SoC is a dual core version of the rv1126. It is
otherwise identical and shares the same device tree config.

This patch introduces a dtsi file to drop the additional cpu nodes.
Taken from Rockchip BSP kernel.

Signed-off-by: Tim Lunn <tim at feathertop.org>

---

(no changes since v2)

Changes in v2:
- new patch

 arch/arm/boot/dts/rockchip/rv1109.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 arch/arm/boot/dts/rockchip/rv1109.dtsi

diff --git a/arch/arm/boot/dts/rockchip/rv1109.dtsi b/arch/arm/boot/dts/rockchip/rv1109.dtsi
new file mode 100644
index 000000000000..9cbaa08ab1b8
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1109.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "rv1126.dtsi"
+
+/ {
+	compatible = "rockchip,rv1109";
+
+	cpus {
+		/delete-node/ cpu at f02;
+		/delete-node/ cpu at f03;
+	};
+
+	arm-pmu {
+		interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>;
+	};
+};
-- 
2.40.1



From tim at feathertop.org  Sun Dec  3 04:40:03 2023
From: tim at feathertop.org (Tim Lunn)
Date: Sun,  3 Dec 2023 23:40:03 +1100
Subject: [PATCH v3 7/8] ARM: dts: Add Sonoff iHost Smart Home Hub
In-Reply-To: <20231203124004.2676174-1-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
Message-ID: <20231203124004.2676174-8-tim@feathertop.org>

Sonoff iHost is gateway device designed to provide a Smart Home Hub,
it is based on Rockchip RV1126. There is also a version with 2GB RAM
based off the RV1109 dual core SoC.

Features:
- Rockchip RV1126
- 4GB DDR4
- 8GB eMMC
- microSD slot
- RMII Ethernet PHY
- 1x USB 2.0 Host
- 1x USB 2.0 OTG
- Realtek RTL8723DS WiFi/BT
- EFR32MG21 Silabs Zigbee radio
- Speaker/Microphone

This patch adds the initial device tree for this device, it is largely
based off the device trees for mainline Edgeble Neu2 and downstream
Rockchip rv1126-evb-v13 configs. It has been adapted with relevant
peripheral and GPIO pins for the iHost.

Signed-off-by: Tim Lunn <tim at feathertop.org>
---

Changes in v3:
- Move ethernet alias from rv1126.dtsi to board dtsi

Changes in v2:
- Address review comments from Heiko
- Split out rv1109.dtsi to new patch

 arch/arm/boot/dts/rockchip/Makefile           |   2 +
 .../boot/dts/rockchip/rv1109-sonoff-ihost.dts |  13 +
 .../boot/dts/rockchip/rv1126-sonoff-ihost.dts |  13 +
 .../dts/rockchip/rv1126-sonoff-ihost.dtsi     | 408 ++++++++++++++++++
 4 files changed, 436 insertions(+)
 create mode 100644 arch/arm/boot/dts/rockchip/rv1109-sonoff-ihost.dts
 create mode 100644 arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dts
 create mode 100644 arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi

diff --git a/arch/arm/boot/dts/rockchip/Makefile b/arch/arm/boot/dts/rockchip/Makefile
index 0f46e18fe275..4d4533d6f407 100644
--- a/arch/arm/boot/dts/rockchip/Makefile
+++ b/arch/arm/boot/dts/rockchip/Makefile
@@ -2,7 +2,9 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rv1108-elgin-r1.dtb \
 	rv1108-evb.dtb \
+	rv1109-sonoff-ihost.dtb \
 	rv1126-edgeble-neu2-io.dtb \
+	rv1126-sonoff-ihost.dtb \
 	rk3036-evb.dtb \
 	rk3036-kylin.dtb \
 	rk3066a-bqcurie2.dtb \
diff --git a/arch/arm/boot/dts/rockchip/rv1109-sonoff-ihost.dts b/arch/arm/boot/dts/rockchip/rv1109-sonoff-ihost.dts
new file mode 100644
index 000000000000..3bfdb00ac8e1
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1109-sonoff-ihost.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+#include "rv1109.dtsi"
+#include "rv1126-sonoff-ihost.dtsi"
+
+/ {
+	model = "Sonoff iHost 2G";
+	compatible = "itead,sonoff-ihost", "rockchip,rv1109";
+};
diff --git a/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dts b/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dts
new file mode 100644
index 000000000000..106d1e42f285
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+#include "rv1126.dtsi"
+#include "rv1126-sonoff-ihost.dtsi"
+
+/ {
+	model = "Sonoff iHost 4G";
+	compatible = "itead,sonoff-ihost", "rockchip,rv1126";
+};
diff --git a/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi b/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi
new file mode 100644
index 000000000000..543b4ec8d244
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi
@@ -0,0 +1,408 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2022 Edgeble AI Technologies Pvt. Ltd.
+ */
+
+/ {
+	aliases {
+		ethernet0 = &gmac;
+		mmc0 = &emmc;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	vcc5v0_sys: regulator-vcc5v0-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+	};
+
+	sdio_pwrseq: pwrseq-sdio {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk809 1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_h>;
+		reset-gpios = <&gpio1 RK_PD0 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&cpu0 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&emmc {
+	bus-width = <8>;
+	cap-mmc-highspeed;
+	mmc-hs200-1_8v;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_rstnout>;
+	rockchip,default-sample-phase = <90>;
+	vmmc-supply = <&vcc_3v3>;
+	vqmmc-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	rk809: pmic at 20 {
+		compatible = "rockchip,rk809";
+		reg = <0x20>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB1 IRQ_TYPE_LEVEL_LOW>;
+		#clock-cells = <1>;
+		clock-output-names = "rk808-clkout1", "rk808-clkout2";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>;
+		rockchip,system-power-controller;
+		wakeup-source;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc_buck5>;
+		vcc6-supply = <&vcc_buck5>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+
+		regulators {
+			vdd_npu_vepu: DCDC_REG1 {
+				regulator-name = "vdd_npu_vepu";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-initial-mode = <0x2>;
+				regulator-min-microvolt = <650000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_arm: DCDC_REG2 {
+				regulator-name = "vdd_arm";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-initial-mode = <0x2>;
+				regulator-min-microvolt = <725000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-name = "vcc_ddr";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-initial-mode = <0x2>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc3v3_sys: DCDC_REG4 {
+				regulator-name = "vcc3v3_sys";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-initial-mode = <0x2>;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vcc_buck5: DCDC_REG5 {
+				regulator-name = "vcc_buck5";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2200000>;
+				regulator-max-microvolt = <2200000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2200000>;
+				};
+			};
+
+			vcc_0v8: LDO_REG1 {
+				regulator-name = "vcc_0v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc1v8_pmu: LDO_REG2 {
+				regulator-name = "vcc1v8_pmu";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd0v8_pmu: LDO_REG3 {
+				regulator-name = "vcc0v8_pmu";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <800000>;
+				};
+			};
+
+			vcc_1v8: LDO_REG4 {
+				regulator-name = "vcc_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_dovdd: LDO_REG5 {
+				regulator-name = "vcc_dovdd";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_dvdd: LDO_REG6 {
+				regulator-name = "vcc_dvdd";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_avdd: LDO_REG7 {
+				regulator-name = "vcc_avdd";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd: LDO_REG8 {
+				regulator-name = "vccio_sd";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_sd: LDO_REG9 {
+				regulator-name = "vcc3v3_sd";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_5v0: SWITCH_REG1 {
+				regulator-name = "vcc_5v0";
+			};
+
+			vcc_3v3: SWITCH_REG2 {
+				regulator-name = "vcc_3v3";
+				regulator-always-on;
+				regulator-boot-on;
+			};
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	pcf8563: rtc at 51 {
+		compatible = "nxp,pcf8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
+		clock-output-names = "xin32k";
+	};
+};
+
+&gmac {
+	assigned-clocks = <&cru CLK_GMAC_SRC_M1>, <&cru CLK_GMAC_SRC>,
+			  <&cru CLK_GMAC_TX_RX>;
+	assigned-clock-parents = <&cru CLK_GMAC_RGMII_M1>, <&cru CLK_GMAC_SRC_M1>,
+				 <&cru RMII_MODE_CLK>;
+	assigned-clock-rates = <0>, <50000000>;
+	clock_in_out = "output";
+	phy-handle = <&phy>;
+	phy-mode = "rmii";
+	phy-supply = <&vcc_3v3>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmiim1_miim &rgmiim1_rxer &rgmiim1_bus2 &rgmiim1_mclkinout>;
+	status = "okay";
+};
+
+&mdio {
+	phy: ethernet-phy at 0 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&eth_phy_rst>;
+		reset-active-low;
+		reset-assert-us = <50000>;
+		reset-deassert-us = <10000>;
+		reset-gpios = <&gpio2 RK_PA6 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pinctrl {
+	ethernet {
+		eth_phy_rst: eth-phy-rst {
+			rockchip,pins = <2 RK_PA6 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+	bt {
+		bt_enable: bt-enable {
+			rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_dev: bt-wake-dev {
+			rockchip,pins = <1 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_host: bt-wake-host {
+			rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		pmic_int_l: pmic-int-l {
+			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	wifi {
+		wifi_enable_h: wifi-enable-h {
+			rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pmu_io_domains {
+	pmuio0-supply = <&vcc1v8_pmu>;
+	pmuio1-supply = <&vcc3v3_sys>;
+	vccio1-supply = <&vcc_1v8>;
+	vccio2-supply = <&vccio_sd>;
+	vccio3-supply = <&vcc_1v8>;
+	vccio4-supply = <&vcc_dovdd>;
+	vccio5-supply = <&vcc_1v8>;
+	vccio6-supply = <&vcc_1v8>;
+	vccio7-supply = <&vcc_dovdd>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdio {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	max-frequency = <100000000>;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc1_clk &sdmmc1_cmd &sdmmc1_bus4>;
+	rockchip,default-sample-phase = <90>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc3v3_sys>;
+	vqmmc-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	card-detect-delay = <200>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_bus4 &sdmmc0_det>;
+	rockchip,default-sample-phase = <90>;
+	sd-uhs-sdr12;
+	sd-uhs-sdr25;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vccio_sd>;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_xfer &uart0_ctsn &uart0_rtsn>;
+	uart-has-rtscts;
+	status = "okay";
+
+	bluetooth {
+		compatible = "realtek,rtl8723ds-bt";
+		device-wake-gpios = <&gpio1 RK_PC7 GPIO_ACTIVE_HIGH>; /* BT_WAKE */
+		enable-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_HIGH>; /* BT_RST */
+		host-wake-gpios = <&gpio1 RK_PC5 GPIO_ACTIVE_HIGH>; /* BT_WAKE_HOST */
+		max-speed = <2000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_enable>, <&bt_wake_dev>, <&bt_wake_host>;
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart3m2_xfer>;
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart4m2_xfer>;
+	status = "okay";
+};
-- 
2.40.1



From tim at feathertop.org  Sun Dec  3 04:40:04 2023
From: tim at feathertop.org (Tim Lunn)
Date: Sun,  3 Dec 2023 23:40:04 +1100
Subject: [PATCH v3 8/8] dt-bindings: arm: rockchip: Add Sonoff iHost
In-Reply-To: <20231203124004.2676174-1-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
Message-ID: <20231203124004.2676174-9-tim@feathertop.org>

Sonoff iHost is a smart home hub with built in radios for wifi/bt
and Zigbee. It is based off the Rockchip RV1126 (or RV1109) SoC.

Signed-off-by: Tim Lunn <tim at feathertop.org>
Acked-by: Rob Herring <robh at kernel.org>

---

(no changes since v2)

Changes in v2:
- Collect Robh Ack for dt-bindings patch

 Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5f7c6c4aad8f..a26bbcd00deb 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -922,6 +922,13 @@ properties:
           - const: rockchip,rk3568-bpi-r2pro
           - const: rockchip,rk3568
 
+      - description: Sonoff iHost Smart Home Hub
+        items:
+          - const: itead,sonoff-ihost
+          - enum:
+              - rockchip,rv1126
+              - rockchip,rv1109
+
 additionalProperties: true
 
 ...
-- 
2.40.1



From nm at ti.com  Sun Dec  3 06:07:10 2023
From: nm at ti.com (Nishanth Menon)
Date: Sun, 3 Dec 2023 08:07:10 -0600
Subject: [PATCH] arm64: dts: ti: k3-am625-sk: Add support for WL1837
 module onboard
In-Reply-To: <20231129083433.GT5169@atomide.com>
References: <20231121122441.64385-1-tony@atomide.com>
 <20231123071015.is4sffvdkunko5ws@radar>
 <20231129083433.GT5169@atomide.com>
Message-ID: <20231203140710.irc7mmwff2b5voak@observant>

On 10:34-20231129, Tony Lindgren wrote:
> * Nishanth Menon <nm at ti.com> [231123 07:10]:
> > On 14:24-20231121, Tony Lindgren wrote:
> > > From: Vignesh Raghavendra <vigneshr at ti.com>
> > > 
> > > WL1837 WLAN card is present on the original AM625 SK board. It
> > > communicates with the SoC using 4 bit SDIO through the second instance of
> > > MMCSD.
> > > 
> > > Starting with SK-AM62B, there is a M.2 WLAN device connector instead of
> > 
> > We support AM62B-SK.
> 
> Is that with k3-am62-lp-sk.dts though? Wondering if they should have separate
> dts files for the M.2.

It has been the same dts. Separating the wlan out of the dts sounds
correct.

> 
> > > the integrated WL1837 WLAN. The M.2 connector should be handled separately
> > > in the k3-am62a.dtsi and k3-am62b.dtsi files as needed.
> > 
> > Should this rather be an overlay instead of integrated dts fixup? M2
> > connector allows for various options including the newer 33xx family[2].
> 
> Not sure if an overlay makes sense for an integrated device.. It sure makes
> sense for plug in boards though.

overlay works for both variant of devices (please see additional comment
below).

> 
> > It makes sense for the regulator etc to be on the main dts file, but I
> > am not convinced about it being integrated as part of the dts.
> 
> Yeah if AM62B-SK is supported with the same dts. My vote would be for
> separate dts files for the integrated variant to keep things simple :)

we can handle it via dtb itself

dts can remain common, the m2 is a dtso, we generate a dtbo and the
original will be an additional dtb? I think this can work out without
dts/dtsi duplication.

arch/arm64/boot/dts/ti/Makefile has previous examples of the form.

> 
> > Should we use mmc-pwrseq ?
> 
> Yes probably, I think there was some issue earlier with that but sounds like
> it's been solved already.
> 
> > Looks like we have run into an issue in BeaglePlay with wlan_en
> > being always on for loading firmware. so is there a need to keep the
> > wlan on while suspended?
> 
> If the wlan irq was on the first gpio bank, wake-up path would work for
> the wlan. But I think it's wired to a gpio bank with no wake-up capability,
> and the padconf wake related patches are still pending. So no need to keep
> the wlan enabled so far AFAIK.

I believe the issue was around the wlan firmware load itself, but i
think the mmc-pwrseq will probably help resolve it.
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From jgg at ziepe.ca  Sun Dec  3 06:07:56 2023
From: jgg at ziepe.ca (Jason Gunthorpe)
Date: Sun, 3 Dec 2023 10:07:56 -0400
Subject: [PATCH 05/26] vfio: KVM: Pass get/put helpers from KVM to VFIO,
 don't do circular lookup
In-Reply-To: <ZWp_q1w01NCZi8KX@google.com>
References: <20230916003118.2540661-1-seanjc@google.com>
 <20230916003118.2540661-6-seanjc@google.com>
 <20230918152110.GI13795@ziepe.ca>
 <ZQhxpesyXeG+qbS6@google.com>
 <20230918160258.GL13795@ziepe.ca>
 <ZWp_q1w01NCZi8KX@google.com>
Message-ID: <20231203140756.GI1489931@ziepe.ca>

On Fri, Dec 01, 2023 at 04:51:55PM -0800, Sean Christopherson wrote:

> There's one more wrinkle: this patch is buggy in that it doesn't ensure the liveliness
> of KVM-the-module, i.e. nothing prevents userspace from unloading kvm.ko while VFIO
> still holds a reference to a kvm structure, and so invoking ->put_kvm() could jump
> into freed code.  To fix that, KVM would also need to pass along a module pointer :-(

Maybe we should be refcounting the struct file not the struct kvm?

Then we don't need special helpers and it keeps the module alive correctly.

Jason


From krzysztof.kozlowski at linaro.org  Sun Dec  3 07:09:37 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 3 Dec 2023 16:09:37 +0100
Subject: [PATCH v5 10/20] dt-bindings: soc: samsung: usi: add
 google,gs101-usi compatible
In-Reply-To: <20231201160925.3136868-11-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-11-peter.griffin@linaro.org>
Message-ID: <2854a9b5-d6c8-454c-bc3b-79744e613686@linaro.org>

On 01/12/2023 17:09, Peter Griffin wrote:
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> 
> Add google,gs101-usi dedicated compatible for representing USI of Google
> GS101 SoC.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> index 61be1f2ddbe7..a10a438d89f0 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> @@ -28,6 +28,9 @@ properties:
>                - samsung,exynosautov9-usi
>                - samsung,exynosautov920-usi
>            - const: samsung,exynos850-usi
> +      - items:
> +          - const: google,gs101-usi

This should be part of previous enum.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec  3 07:10:59 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 3 Dec 2023 16:10:59 +0100
Subject: [PATCH v5 09/20] dt-bindings: serial: samsung: Make
 samsung,uart-fifosize required property
In-Reply-To: <20231201160925.3136868-10-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-10-peter.griffin@linaro.org>
Message-ID: <b4e710c0-dddb-4217-9979-21bdc20ee302@linaro.org>

On 01/12/2023 17:09, Peter Griffin wrote:
> Specifying samsung,uart-fifosize in both DT and driver static data is error
> prone and relies on driver probe order and dt aliases to be correct.
> 
> Additionally on many Exynos platforms these are (USI) universal serial
> interfaces which can be uart, spi or i2c, so it can change per board.
> 
> For google,gs101-uart and exynosautov9-uart make samsung,uart-fifosize a
> required property. For these platforms fifosize now *only* comes from DT.

I don't see ExynosAutov9 compatible in your patch.

> 
> It is hoped other Exynos platforms will also switch over time.
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  .../devicetree/bindings/serial/samsung_uart.yaml       | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index ccc3626779d9..65d5d361e8f4 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -133,6 +133,16 @@ allOf:
>              - const: uart
>              - const: clk_uart_baud0
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - google,gs101-uart
Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec  3 07:11:34 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 3 Dec 2023 16:11:34 +0100
Subject: [PATCH v5 07/20] dt-bindings: pinctrl: samsung: add
 gs101-wakeup-eint compatible
In-Reply-To: <20231201160925.3136868-8-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-8-peter.griffin@linaro.org>
Message-ID: <fedd4ec8-b4e6-472a-9bfd-063ea8b9658e@linaro.org>

On 01/12/2023 17:09, Peter Griffin wrote:
> gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
> where more than one pin controller can do external wake-up interrupt.
> So add a dedicated compatible for it.
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> index 2bafa867aea2..de2209f8ba00 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> @@ -44,6 +44,7 @@ properties:
>            - const: samsung,exynos7-wakeup-eint
>        - items:
>            - enum:
> +              - google,gs101-wakeup-eint
>                - samsung,exynosautov9-wakeup-eint
>                - samsung,exynosautov920-wakeup-eint
>            - const: samsung,exynos850-wakeup-eint
> @@ -111,6 +112,7 @@ allOf:
>          compatible:
>            contains:
>              enum:
> +              - google,gs101-wakeup-eint

Drop, not needed.

Best regards,
Krzysztof



From laurent.pinchart at ideasonboard.com  Sun Dec  3 07:34:01 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Sun, 3 Dec 2023 17:34:01 +0200
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231202035511.487946-3-sjg@chromium.org>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-3-sjg@chromium.org>
Message-ID: <20231203153401.GV8402@pendragon.ideasonboard.com>

Hi Simon,

Thank you for the patch.

On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> Add a script which produces a Flat Image Tree (FIT), a single file
> containing the built kernel and associated devicetree files.
> Compression defaults to gzip which gives a good balance of size and
> performance.
> 
> The files compress from about 86MB to 24MB using this approach.
> 
> The FIT can be used by bootloaders which support it, such as U-Boot
> and Linuxboot. It permits automatic selection of the correct
> devicetree, matching the compatible string of the running board with
> the closest compatible string in the FIT. There is no need for
> filenames or other workarounds.
> 
> Add a 'make image.fit' build target for arm64, as well. Use
> FIT_COMPRESSION to select a different algorithm.
> 
> The FIT can be examined using 'dumpimage -l'.
> 
> This features requires pylibfdt (use 'pip install libfdt'). It also
> requires compression utilities for the algorithm being used. Supported
> compression options are the same as the Image.xxx files. For now there
> is no way to change the compression other than by editing the rule for
> $(obj)/image.fit
> 
> While FIT supports a ramdisk / initrd, no attempt is made to support
> this here, since it must be built separately from the Linux build.

FIT images are very useful, so I think this is a very welcome addition
to the kernel build system. It can get tricky though: given the
versatile nature of FIT images, there can't be any
one-size-fits-them-all solution to build them, and striking the right
balance between what makes sense for the kernel and the features that
users may request will probably lead to bikeshedding. As we all love
bikeshedding, I thought I would start selfishly, with a personal use
case :-) This isn't a yak-shaving request though, I don't see any reason
to delay merging this series.

Have you envisioned building FIT images with a subset of DTBs, or adding
DTBOs ? Both would be fairly trivial extensions to this script by
extending the supported command line arguments. It would perhaps be more
difficult to integrate in the kernel build system though. This leads me
to a second question: would you consider merging extensions to this
script if they are not used by the kernel build system, but meant for
users who manually invoke the script ? More generally, is the script
meant to be used stand-alone as well, in which case its command line
arguments need to remain backward-compatible, or do you see it as being
internal to the kernel ?

> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---
> 
> Changes in v9:
> - Move the compression control into Makefile.lib
> 
> Changes in v8:
> - Drop compatible string in FDT node
> - Correct sorting of MAINTAINERS to before ARM64 PORT
> - Turn compress part of the make_fit.py comment in to a sentence
> - Add two blank lines before parse_args() and setup_fit()
> - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> - Use '$(<D)/dts' instead of '$(dir $<)dts'
> - Add 'mkimage' details Documentation/process/changes.rst
> - Allow changing the compression used
> - Tweak cover letter since there is only one clean-up patch
> 
> Changes in v7:
> - Add Image as a dependency of image.fit
> - Drop kbuild tag
> - Add dependency on dtbs
> - Drop unnecessary path separator for dtbs
> - Rebase to -next
> 
> Changes in v5:
> - Drop patch previously applied
> - Correct compression rule which was broken in v4
> 
> Changes in v4:
> - Use single quotes for UIMAGE_NAME
> 
> Changes in v3:
> - Drop temporary file image.itk
> - Drop patch 'Use double quotes for image name'
> - Drop double quotes in use of UIMAGE_NAME
> - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> - Avoid hard-coding "arm64" for the DT architecture
> 
> Changes in v2:
> - Drop patch previously applied
> - Add .gitignore file
> - Move fit rule to Makefile.lib using an intermediate file
> - Drop dependency on CONFIG_EFI_ZBOOT
> - Pick up .dtb files separately from the kernel
> - Correct pylint too-many-args warning for write_kernel()
> - Include the kernel image in the file count
> - Add a pointer to the FIT spec and mention of its wide industry usage
> - Mention the kernel version in the FIT description
> 
>  Documentation/process/changes.rst |   9 +
>  MAINTAINERS                       |   7 +
>  arch/arm64/Makefile               |   7 +-
>  arch/arm64/boot/.gitignore        |   1 +
>  arch/arm64/boot/Makefile          |   6 +-
>  scripts/Makefile.lib              |  16 ++
>  scripts/make_fit.py               | 291 ++++++++++++++++++++++++++++++
>  7 files changed, 334 insertions(+), 3 deletions(-)
>  create mode 100755 scripts/make_fit.py
> 
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index bb96ca0f774b..cad51bd5bd62 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -62,6 +62,7 @@ Sphinx\ [#f1]_         1.7              sphinx-build --version
>  cpio                   any              cpio --version
>  GNU tar                1.28             tar --version
>  gtags (optional)       6.6.5            gtags --version
> +mkimage (optional)     2017.01          mkimage --version
>  ====================== ===============  ========================================
>  
>  .. [#f1] Sphinx is needed only to build the Kernel documentation
> @@ -189,6 +190,14 @@ The kernel build requires GNU GLOBAL version 6.6.5 or later to generate
>  tag files through ``make gtags``.  This is due to its use of the gtags
>  ``-C (--directory)`` flag.
>  
> +mkimage
> +-------
> +
> +This tool is used when building a Flat Image Tree (FIT), commonly used on ARM
> +platforms. The tool is available via the ``u-boot-tools`` package or can be
> +built from the U-Boot source code. See the instructions at
> +https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
> +
>  System utilities
>  ****************
>  
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9d46229fe21b..d2d17f0d6e64 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3037,6 +3037,13 @@ F:	drivers/mmc/host/sdhci-of-arasan.c
>  N:	zynq
>  N:	xilinx
>  
> +ARM64 FIT SUPPORT
> +M:	Simon Glass <sjg at chromium.org>
> +L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S:	Maintained
> +F:	arch/arm64/boot/Makefile
> +F:	scripts/make_fit.py
> +
>  ARM64 PORT (AARCH64 ARCHITECTURE)
>  M:	Catalin Marinas <catalin.marinas at arm.com>
>  M:	Will Deacon <will at kernel.org>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 1bd4fae6e806..6b893dc454b7 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -150,7 +150,7 @@ libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>  # Default target when executing plain make
>  boot		:= arch/arm64/boot
>  
> -BOOT_TARGETS	:= Image vmlinuz.efi
> +BOOT_TARGETS	:= Image vmlinuz.efi image.fit
>  
>  PHONY += $(BOOT_TARGETS)
>  
> @@ -162,7 +162,9 @@ endif
>  
>  all:	$(notdir $(KBUILD_IMAGE))
>  
> -vmlinuz.efi: Image
> +image.fit: dtbs
> +
> +vmlinuz.efi image.fit: Image
>  $(BOOT_TARGETS): vmlinux
>  	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
>  
> @@ -215,6 +217,7 @@ virtconfig:
>  define archhelp
>    echo  '* Image.gz      - Compressed kernel image (arch/$(ARCH)/boot/Image.gz)'
>    echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
> +  echo  '  image.fit     - Flat Image Tree (arch/$(ARCH)/boot/image.fit)'
>    echo  '  install       - Install uncompressed kernel'
>    echo  '  zinstall      - Install compressed kernel'
>    echo  '                  Install using (your) ~/bin/installkernel or'
> diff --git a/arch/arm64/boot/.gitignore b/arch/arm64/boot/.gitignore
> index af5dc61f8b43..abaae9de1bdd 100644
> --- a/arch/arm64/boot/.gitignore
> +++ b/arch/arm64/boot/.gitignore
> @@ -2,3 +2,4 @@
>  Image
>  Image.gz
>  vmlinuz*
> +image.fit
> diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
> index 1761f5972443..b835c0880d1c 100644
> --- a/arch/arm64/boot/Makefile
> +++ b/arch/arm64/boot/Makefile
> @@ -16,7 +16,8 @@
>  
>  OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
>  
> -targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo Image.zst
> +targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo \
> +	Image.zst image.fit
>  
>  $(obj)/Image: vmlinux FORCE
>  	$(call if_changed,objcopy)
> @@ -39,6 +40,9 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
>  $(obj)/Image.zst: $(obj)/Image FORCE
>  	$(call if_changed,zstd)
>  
> +$(obj)/image.fit: $(obj)/Image FORCE
> +	$(call cmd,fit)
> +
>  EFI_ZBOOT_PAYLOAD	:= Image
>  EFI_ZBOOT_BFD_TARGET	:= elf64-littleaarch64
>  EFI_ZBOOT_MACH_TYPE	:= ARM64
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 1a965fe68e01..1c60d594932c 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -496,6 +496,22 @@ quiet_cmd_uimage = UIMAGE  $@
>  			-a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \
>  			-n '$(UIMAGE_NAME)' -d $< $@
>  
> +# Flat Image Tree (FIT)
> +# This allows for packaging of a kernel and all devicetrees files, using
> +# compression.
> +# ---------------------------------------------------------------------------
> +
> +MAKE_FIT := $(srctree)/scripts/make_fit.py
> +
> +# Use this to override the compression algorithm
> +FIT_COMPRESSION ?= gzip
> +
> +quiet_cmd_fit = FIT     $@
> +      cmd_fit = $(MAKE_FIT) -f $@ --arch $(UIMAGE_ARCH) --os linux \
> +			--name '$(UIMAGE_NAME)' \
> +			--compress $(FIT_COMPRESSION) -k $< \
> +			$(<D)/dts
> +
>  # XZ
>  # ---------------------------------------------------------------------------
>  # Use xzkern to compress the kernel image and xzmisc to compress other things.
> diff --git a/scripts/make_fit.py b/scripts/make_fit.py
> new file mode 100755
> index 000000000000..e616b0d7a84a
> --- /dev/null
> +++ b/scripts/make_fit.py
> @@ -0,0 +1,291 @@
> +#!/usr/bin/env python3
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright 2023 Google LLC
> +# Written by Simon Glass <sjg at chromium.org>
> +#
> +
> +"""Build a FIT containing a lot of devicetree files
> +
> +Usage:
> +    make_fit.py -A arm64 -n 'Linux-6.6' -O linux
> +        -f arch/arm64/boot/image.fit -k /tmp/kern/arch/arm64/boot/image.itk
> +        /tmp/kern/arch/arm64/boot/dts/ -E -c gzip
> +
> +Creates a FIT containing the supplied kernel and a directory containing the
> +devicetree files.
> +
> +Use -E to generate an external FIT (where the data is placed after the
> +FIT data structure). This allows parsing of the data without loading
> +the entire FIT.
> +
> +Use -c to compress the data, using bzip2, gzip, lz4, lzma, lzo and
> +zstd algorithms.
> +
> +The resulting FIT can be booted by bootloaders which support FIT, such
> +as U-Boot, Linuxboot, Tianocore, etc.
> +
> +Note that this tool does not yet support adding a ramdisk / initrd.
> +"""
> +
> +import argparse
> +import collections
> +import os
> +import subprocess
> +import sys
> +import tempfile
> +import time
> +
> +import libfdt
> +
> +
> +# Tool extension and the name of the command-line tools
> +CompTool = collections.namedtuple('CompTool', 'ext,tools')
> +
> +COMP_TOOLS = {
> +    'bzip2': CompTool('.bz2', 'bzip2'),
> +    'gzip': CompTool('.gz', 'pigz,gzip'),
> +    'lz4': CompTool('.lz4', 'lz4'),
> +    'lzma': CompTool('.lzma', 'lzma'),
> +    'lzo': CompTool('.lzo', 'lzop'),
> +    'zstd': CompTool('.zstd', 'zstd'),
> +}
> +
> +
> +def parse_args():
> +    """Parse the program ArgumentParser
> +
> +    Returns:
> +        Namespace object containing the arguments
> +    """
> +    epilog = 'Build a FIT from a directory tree containing .dtb files'
> +    parser = argparse.ArgumentParser(epilog=epilog)
> +    parser.add_argument('-A', '--arch', type=str, required=True,
> +          help='Specifies the architecture')
> +    parser.add_argument('-c', '--compress', type=str, default='none',
> +          help='Specifies the compression')
> +    parser.add_argument('-E', '--external', action='store_true',
> +          help='Convert the FIT to use external data')
> +    parser.add_argument('-n', '--name', type=str, required=True,
> +          help='Specifies the name')
> +    parser.add_argument('-O', '--os', type=str, required=True,
> +          help='Specifies the operating system')
> +    parser.add_argument('-f', '--fit', type=str, required=True,
> +          help='Specifies the output file (.fit)')
> +    parser.add_argument('-k', '--kernel', type=str, required=True,
> +          help='Specifies the (uncompressed) kernel input file (.itk)')
> +    parser.add_argument('srcdir', type=str, nargs='*',
> +          help='Specifies the directory tree that contains .dtb files')
> +
> +    return parser.parse_args()
> +
> +
> +def setup_fit(fsw, name):
> +    """Make a start on writing the FIT
> +
> +    Outputs the root properties and the 'images' node
> +
> +    Args:
> +        fsw (libfdt.FdtSw): Object to use for writing
> +        name (str): Name of kernel image
> +    """
> +    fsw.INC_SIZE = 65536
> +    fsw.finish_reservemap()
> +    fsw.begin_node('')
> +    fsw.property_string('description', f'{name} with devicetree set')
> +    fsw.property_u32('#address-cells', 1)
> +
> +    fsw.property_u32('timestamp', int(time.time()))
> +    fsw.begin_node('images')
> +
> +
> +def write_kernel(fsw, data, args):
> +    """Write out the kernel image
> +
> +    Writes a kernel node along with the required properties
> +
> +    Args:
> +        fsw (libfdt.FdtSw): Object to use for writing
> +        data (bytes): Data to write (possibly compressed)
> +        args (Namespace): Contains necessary strings:
> +            arch: FIT architecture, e.g. 'arm64'
> +            fit_os: Operating Systems, e.g. 'linux'
> +            name: Name of OS, e.g. 'Linux-6.6.0-rc7'
> +            compress: Compression algorithm to use, e.g. 'gzip'
> +    """
> +    with fsw.add_node('kernel'):
> +        fsw.property_string('description', args.name)
> +        fsw.property_string('type', 'kernel_noload')
> +        fsw.property_string('arch', args.arch)
> +        fsw.property_string('os', args.os)
> +        fsw.property_string('compression', args.compress)
> +        fsw.property('data', data)
> +        fsw.property_u32('load', 0)
> +        fsw.property_u32('entry', 0)
> +
> +
> +def finish_fit(fsw, entries):
> +    """Finish the FIT ready for use
> +
> +    Writes the /configurations node and subnodes
> +
> +    Args:
> +        fsw (libfdt.FdtSw): Object to use for writing
> +        entries (list of tuple): List of configurations:
> +            str: Description of model
> +            str: Compatible stringlist
> +    """
> +    fsw.end_node()
> +    seq = 0
> +    with fsw.add_node('configurations'):
> +        for model, compat in entries:
> +            seq += 1
> +            with fsw.add_node(f'conf-{seq}'):
> +                fsw.property('compatible', bytes(compat))
> +                fsw.property_string('description', model)
> +                fsw.property_string('fdt', f'fdt-{seq}')
> +                fsw.property_string('kernel', 'kernel')
> +    fsw.end_node()
> +
> +
> +def compress_data(inf, compress):
> +    """Compress data using a selected algorithm
> +
> +    Args:
> +        inf (IOBase): Filename containing the data to compress
> +        compress (str): Compression algorithm, e.g. 'gzip'
> +
> +    Return:
> +        bytes: Compressed data
> +    """
> +    if compress == 'none':
> +        return inf.read()
> +
> +    comp = COMP_TOOLS.get(compress)
> +    if not comp:
> +        raise ValueError(f"Unknown compression algorithm '{compress}'")
> +
> +    with tempfile.NamedTemporaryFile() as comp_fname:
> +        with open(comp_fname.name, 'wb') as outf:
> +            done = False
> +            for tool in comp.tools.split(','):
> +                try:
> +                    subprocess.call([tool, '-c'], stdin=inf, stdout=outf)
> +                    done = True
> +                    break
> +                except FileNotFoundError:
> +                    pass
> +            if not done:
> +                raise ValueError(f'Missing tool(s): {comp.tools}\n')
> +            with open(comp_fname.name, 'rb') as compf:
> +                comp_data = compf.read()
> +    return comp_data
> +
> +
> +def output_dtb(fsw, seq, fname, arch, compress):
> +    """Write out a single devicetree to the FIT
> +
> +    Args:
> +        fsw (libfdt.FdtSw): Object to use for writing
> +        seq (int): Sequence number (1 for first)
> +        fmame (str): Filename containing the DTB
> +        arch: FIT architecture, e.g. 'arm64'
> +        compress (str): Compressed algorithm, e.g. 'gzip'
> +
> +    Returns:
> +        tuple:
> +            str: Model name
> +            bytes: Compatible stringlist
> +    """
> +    with fsw.add_node(f'fdt-{seq}'):
> +        # Get the compatible / model information
> +        with open(fname, 'rb') as inf:
> +            data = inf.read()
> +        fdt = libfdt.FdtRo(data)
> +        model = fdt.getprop(0, 'model').as_str()
> +        compat = fdt.getprop(0, 'compatible')
> +
> +        fsw.property_string('description', model)
> +        fsw.property_string('type', 'flat_dt')
> +        fsw.property_string('arch', arch)
> +        fsw.property_string('compression', compress)
> +        fsw.property('compatible', bytes(compat))
> +
> +        with open(fname, 'rb') as inf:
> +            compressed = compress_data(inf, compress)
> +        fsw.property('data', compressed)
> +    return model, compat
> +
> +
> +def build_fit(args):
> +    """Build the FIT from the provided files and arguments
> +
> +    Args:
> +        args (Namespace): Program arguments
> +
> +    Returns:
> +        tuple:
> +            bytes: FIT data
> +            int: Number of configurations generated
> +            size: Total uncompressed size of data
> +    """
> +    fsw = libfdt.FdtSw()
> +    setup_fit(fsw, args.name)
> +    seq = 0
> +    size = 0
> +    entries = []
> +
> +    # Handle the kernel
> +    with open(args.kernel, 'rb') as inf:
> +        comp_data = compress_data(inf, args.compress)
> +    size += os.path.getsize(args.kernel)
> +    write_kernel(fsw, comp_data, args)
> +
> +    for path in args.srcdir:
> +        # Handle devicetree files
> +        if os.path.isdir(path):
> +            for dirpath, _, fnames in os.walk(path):
> +                for fname in fnames:
> +                    if os.path.splitext(fname)[1] != '.dtb':
> +                        continue
> +                    pathname = os.path.join(dirpath, fname)
> +                    seq += 1
> +                    size += os.path.getsize(pathname)
> +                    model, compat = output_dtb(fsw, seq, pathname,
> +                                               args.arch, args.compress)
> +                    entries.append([model, compat])
> +
> +    finish_fit(fsw, entries)
> +
> +    # Include the kernel itself in the returned file count
> +    return fsw.as_fdt().as_bytearray(), seq + 1, size
> +
> +
> +def run_make_fit():
> +    """Run the tool's main logic"""
> +    args = parse_args()
> +
> +    out_data, count, size = build_fit(args)
> +    with open(args.fit, 'wb') as outf:
> +        outf.write(out_data)
> +
> +    ext_fit_size = None
> +    if args.external:
> +        mkimage = os.environ.get('MKIMAGE', 'mkimage')
> +        subprocess.check_call([mkimage, '-E', '-F', args.fit],
> +                              stdout=subprocess.DEVNULL)
> +
> +        with open(args.fit, 'rb') as inf:
> +            data = inf.read()
> +        ext_fit = libfdt.FdtRo(data)
> +        ext_fit_size = ext_fit.totalsize()
> +
> +    comp_size = len(out_data)
> +    print(f'FIT size {comp_size:#x}/{comp_size / 1024 / 1024:.1f} MB', end='')
> +    if ext_fit_size:
> +        print(f', header {ext_fit_size:#x}/{ext_fit_size / 1024:.1f} KB', end='')
> +    print(f', {count} files, uncompressed {size / 1024 / 1024:.1f} MB')
> +
> +
> +if __name__ == "__main__":
> +    sys.exit(run_make_fit())

-- 
Regards,

Laurent Pinchart


From knaerzche at gmail.com  Sun Dec  3 08:05:47 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sun, 3 Dec 2023 17:05:47 +0100
Subject: [PATCH v2 2/5] ARM: dts: rockchip: Add power-controller for
 RK3128
In-Reply-To: <4891026.6YUMPnJmAY@diego>
References: <20231202125144.66052-1-knaerzche@gmail.com>
 <6926340.F8r316W7xa@diego> <7a6eed43-477a-48a4-bd64-4528da920ffd@gmail.com>
 <4891026.6YUMPnJmAY@diego>
Message-ID: <4dec2316-f840-44ab-a07a-3d7f0e5e6d8f@gmail.com>

Hi Heiko,

Am 02.12.23 um 18:46 schrieb Heiko St?bner:
> Hi Alex,
>
> Am Samstag, 2. Dezember 2023, 17:36:15 CET schrieb Alex Bee:
>> Am 02.12.23 um 16:51 schrieb Heiko St?bner:
>>> Am Samstag, 2. Dezember 2023, 13:51:41 CET schrieb Alex Bee:
>>>> Add power controller and qos nodes for RK3128 in order to use
>>>> them as powerdomains.
>>> does the power-domain controller work with the incomplete set of
>>> pm-domains too?
>> Yes, it does - the missing domains can request idle only and can't be
>> powered on/off - if no one requests idle they are just up all the time.
>>
>>> What I have in mind is
>>> - adding the power-controller node with the existing set of power-domains
>>> - the gpu pm-domain is in there
>>> - adding the gpu parts
>> My main concern about adding them later was the change of the ABI after
>> they've been exposed in the SoC DT. If that's not an issue - sure: I can
>> add them in a separate series.
> An ABI change would be _changing_ the domain-ids in the rk3128-power.h
> I think :-) .
Well, an addition is still a change.
> Right now the existing domain ids in the header are already exposed to the
> world, so someone could already use them, but not the new ones.

I'm fully aware that nothing would ever hard fail anywhere if the new 
domain ids get added later.

Nevertheless we start using here an ABI which is known to be incomplete. 
For no reason, as the patches (which I am now asked to remove from this 
series) for completion are already there (here).

Anyway, if you prefer it this way: I'm pleased to do so.

Alex

>
> Heiko
>
>>> And a second series with
>>> - patch1 from here
>>> - a dts patch adding the additional pm-domains to rk3128.dtsi
>>> - I guess patch1 also should be split into a patch adding the binding-ids
>>>     and a separate patch for the code addition.
>> Yeah, I noticed this also :)
>>
>> Regards,
>>
>> Alex
>>
>>>
>>> Heiko
>>>
>>>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>>>> ---
>>>>    arch/arm/boot/dts/rockchip/rk3128.dtsi | 101 +++++++++++++++++++++++++
>>>>    1 file changed, 101 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>>>> index 4e8b38604ecd..b72905db04f7 100644
>>>> --- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
>>>> +++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>>>> @@ -8,6 +8,7 @@
>>>>    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>    #include <dt-bindings/interrupt-controller/irq.h>
>>>>    #include <dt-bindings/pinctrl/rockchip.h>
>>>> +#include <dt-bindings/power/rk3128-power.h>
>>>>    
>>>>    / {
>>>>    	compatible = "rockchip,rk3128";
>>>> @@ -133,6 +134,106 @@ smp-sram at 0 {
>>>>    	pmu: syscon at 100a0000 {
>>>>    		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
>>>>    		reg = <0x100a0000 0x1000>;
>>>> +
>>>> +		power: power-controller {
>>>> +			compatible = "rockchip,rk3128-power-controller";
>>>> +			#power-domain-cells = <1>;
>>>> +			#address-cells = <1>;
>>>> +			#size-cells = <0>;
>>>> +
>>>> +			power-domain at RK3128_PD_VIO {
>>>> +				reg = <RK3128_PD_VIO>;
>>>> +				clocks = <&cru ACLK_CIF>,
>>>> +					 <&cru HCLK_CIF>,
>>>> +					 <&cru DCLK_EBC>,
>>>> +					 <&cru HCLK_EBC>,
>>>> +					 <&cru ACLK_IEP>,
>>>> +					 <&cru HCLK_IEP>,
>>>> +					 <&cru ACLK_LCDC0>,
>>>> +					 <&cru HCLK_LCDC0>,
>>>> +					 <&cru PCLK_MIPI>,
>>>> +					 <&cru ACLK_RGA>,
>>>> +					 <&cru HCLK_RGA>,
>>>> +					 <&cru ACLK_VIO0>,
>>>> +					 <&cru ACLK_VIO1>,
>>>> +					 <&cru HCLK_VIO>,
>>>> +					 <&cru HCLK_VIO_H2P>,
>>>> +					 <&cru DCLK_VOP>,
>>>> +					 <&cru SCLK_VOP>;
>>>> +				pm_qos = <&qos_ebc>,
>>>> +					 <&qos_iep>,
>>>> +					 <&qos_lcdc>,
>>>> +					 <&qos_rga>,
>>>> +					 <&qos_vip>;
>>>> +				#power-domain-cells = <0>;
>>>> +			};
>>>> +
>>>> +			power-domain at RK3128_PD_VIDEO {
>>>> +				reg = <RK3128_PD_VIDEO>;
>>>> +				clocks = <&cru ACLK_VDPU>,
>>>> +					 <&cru HCLK_VDPU>,
>>>> +					 <&cru ACLK_VEPU>,
>>>> +					 <&cru HCLK_VEPU>,
>>>> +					 <&cru SCLK_HEVC_CORE>;
>>>> +				pm_qos = <&qos_vpu>;
>>>> +				#power-domain-cells = <0>;
>>>> +			};
>>>> +
>>>> +			power-domain at RK3128_PD_GPU {
>>>> +				reg = <RK3128_PD_GPU>;
>>>> +				clocks = <&cru ACLK_GPU>;
>>>> +				pm_qos = <&qos_gpu>;
>>>> +				#power-domain-cells = <0>;
>>>> +			};
>>>> +
>>>> +			power-domain at RK3128_PD_CRYPTO {
>>>> +				reg = <RK3128_PD_CRYPTO>;
>>>> +				clocks = <&cru HCLK_CRYPTO>,
>>>> +					 <&cru SCLK_CRYPTO>;
>>>> +				pm_qos = <&qos_crypto>;
>>>> +				#power-domain-cells = <0>;
>>>> +			};
>>>> +		};
>>>> +	};
>>>> +
>>>> +	qos_crypto: qos at 10128080 {
>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>> +		reg = <0x10128080 0x20>;
>>>> +	};
>>>> +
>>>> +	qos_gpu: qos at 1012d000 {
>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>> +		reg = <0x1012d000 0x20>;
>>>> +	};
>>>> +
>>>> +	qos_vpu: qos at 1012e000 {
>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>> +		reg = <0x1012e000 0x20>;
>>>> +	};
>>>> +
>>>> +	qos_rga: qos at 1012f000 {
>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>> +		reg = <0x1012f000 0x20>;
>>>> +	};
>>>> +
>>>> +	qos_ebc: qos at 1012f080 {
>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>> +		reg = <0x1012f080 0x20>;
>>>> +	};
>>>> +
>>>> +	qos_iep: qos at 1012f100 {
>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>> +		reg = <0x1012f100 0x20>;
>>>> +	};
>>>> +
>>>> +	qos_lcdc: qos at 1012f180 {
>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>> +		reg = <0x1012f180 0x20>;
>>>> +	};
>>>> +
>>>> +	qos_vip: qos at 1012f200 {
>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>> +		reg = <0x1012f200 0x20>;
>>>>    	};
>>>>    
>>>>    	gic: interrupt-controller at 10139000 {
>>>>
>>>
>>>
>
>
>


From heiko at sntech.de  Sun Dec  3 08:42:52 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sun, 03 Dec 2023 17:42:52 +0100
Subject: [PATCH v2 2/5] ARM: dts: rockchip: Add power-controller for RK3128
In-Reply-To: <4dec2316-f840-44ab-a07a-3d7f0e5e6d8f@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com> <4891026.6YUMPnJmAY@diego>
 <4dec2316-f840-44ab-a07a-3d7f0e5e6d8f@gmail.com>
Message-ID: <9588573.jRhZ6ZUK3Y@diego>

Hi Alex,

Am Sonntag, 3. Dezember 2023, 17:05:47 CET schrieb Alex Bee:
> Am 02.12.23 um 18:46 schrieb Heiko St?bner:
> > Am Samstag, 2. Dezember 2023, 17:36:15 CET schrieb Alex Bee:
> >> Am 02.12.23 um 16:51 schrieb Heiko St?bner:
> >>> Am Samstag, 2. Dezember 2023, 13:51:41 CET schrieb Alex Bee:
> >>>> Add power controller and qos nodes for RK3128 in order to use
> >>>> them as powerdomains.
> >>> does the power-domain controller work with the incomplete set of
> >>> pm-domains too?
> >> Yes, it does - the missing domains can request idle only and can't be
> >> powered on/off - if no one requests idle they are just up all the time.
> >>
> >>> What I have in mind is
> >>> - adding the power-controller node with the existing set of power-domains
> >>> - the gpu pm-domain is in there
> >>> - adding the gpu parts
> >> My main concern about adding them later was the change of the ABI after
> >> they've been exposed in the SoC DT. If that's not an issue - sure: I can
> >> add them in a separate series.
> > An ABI change would be _changing_ the domain-ids in the rk3128-power.h
> > I think :-) .
> Well, an addition is still a change.
> > Right now the existing domain ids in the header are already exposed to the
> > world, so someone could already use them, but not the new ones.
> 
> I'm fully aware that nothing would ever hard fail anywhere if the new 
> domain ids get added later.
> 
> Nevertheless we start using here an ABI which is known to be incomplete. 
> For no reason, as the patches (which I am now asked to remove from this 
> series) for completion are already there (here).
> 
> Anyway, if you prefer it this way: I'm pleased to do so.

I was more thinking of accelerating the gpu-part of the series, as that
really is just waiting for the power-domain node that already has driver
support and domain-ids present.

It looks like you're feeling more strongly about that though, so I'll
definitly not pressure you ;-) .

But I guess the split into IDs and driver change should still be
done, especially as the dt-binding-header likely will want an Ack
from the DT maintainers.

And the power-domain change will go through the new pmdomain
subsystem.


Heiko


> >>> And a second series with
> >>> - patch1 from here
> >>> - a dts patch adding the additional pm-domains to rk3128.dtsi
> >>> - I guess patch1 also should be split into a patch adding the binding-ids
> >>>     and a separate patch for the code addition.
> >> Yeah, I noticed this also :)
> >>
> >> Regards,
> >>
> >> Alex
> >>
> >>>
> >>> Heiko
> >>>
> >>>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> >>>> ---
> >>>>    arch/arm/boot/dts/rockchip/rk3128.dtsi | 101 +++++++++++++++++++++++++
> >>>>    1 file changed, 101 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
> >>>> index 4e8b38604ecd..b72905db04f7 100644
> >>>> --- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
> >>>> +++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
> >>>> @@ -8,6 +8,7 @@
> >>>>    #include <dt-bindings/interrupt-controller/arm-gic.h>
> >>>>    #include <dt-bindings/interrupt-controller/irq.h>
> >>>>    #include <dt-bindings/pinctrl/rockchip.h>
> >>>> +#include <dt-bindings/power/rk3128-power.h>
> >>>>    
> >>>>    / {
> >>>>    	compatible = "rockchip,rk3128";
> >>>> @@ -133,6 +134,106 @@ smp-sram at 0 {
> >>>>    	pmu: syscon at 100a0000 {
> >>>>    		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
> >>>>    		reg = <0x100a0000 0x1000>;
> >>>> +
> >>>> +		power: power-controller {
> >>>> +			compatible = "rockchip,rk3128-power-controller";
> >>>> +			#power-domain-cells = <1>;
> >>>> +			#address-cells = <1>;
> >>>> +			#size-cells = <0>;
> >>>> +
> >>>> +			power-domain at RK3128_PD_VIO {
> >>>> +				reg = <RK3128_PD_VIO>;
> >>>> +				clocks = <&cru ACLK_CIF>,
> >>>> +					 <&cru HCLK_CIF>,
> >>>> +					 <&cru DCLK_EBC>,
> >>>> +					 <&cru HCLK_EBC>,
> >>>> +					 <&cru ACLK_IEP>,
> >>>> +					 <&cru HCLK_IEP>,
> >>>> +					 <&cru ACLK_LCDC0>,
> >>>> +					 <&cru HCLK_LCDC0>,
> >>>> +					 <&cru PCLK_MIPI>,
> >>>> +					 <&cru ACLK_RGA>,
> >>>> +					 <&cru HCLK_RGA>,
> >>>> +					 <&cru ACLK_VIO0>,
> >>>> +					 <&cru ACLK_VIO1>,
> >>>> +					 <&cru HCLK_VIO>,
> >>>> +					 <&cru HCLK_VIO_H2P>,
> >>>> +					 <&cru DCLK_VOP>,
> >>>> +					 <&cru SCLK_VOP>;
> >>>> +				pm_qos = <&qos_ebc>,
> >>>> +					 <&qos_iep>,
> >>>> +					 <&qos_lcdc>,
> >>>> +					 <&qos_rga>,
> >>>> +					 <&qos_vip>;
> >>>> +				#power-domain-cells = <0>;
> >>>> +			};
> >>>> +
> >>>> +			power-domain at RK3128_PD_VIDEO {
> >>>> +				reg = <RK3128_PD_VIDEO>;
> >>>> +				clocks = <&cru ACLK_VDPU>,
> >>>> +					 <&cru HCLK_VDPU>,
> >>>> +					 <&cru ACLK_VEPU>,
> >>>> +					 <&cru HCLK_VEPU>,
> >>>> +					 <&cru SCLK_HEVC_CORE>;
> >>>> +				pm_qos = <&qos_vpu>;
> >>>> +				#power-domain-cells = <0>;
> >>>> +			};
> >>>> +
> >>>> +			power-domain at RK3128_PD_GPU {
> >>>> +				reg = <RK3128_PD_GPU>;
> >>>> +				clocks = <&cru ACLK_GPU>;
> >>>> +				pm_qos = <&qos_gpu>;
> >>>> +				#power-domain-cells = <0>;
> >>>> +			};
> >>>> +
> >>>> +			power-domain at RK3128_PD_CRYPTO {
> >>>> +				reg = <RK3128_PD_CRYPTO>;
> >>>> +				clocks = <&cru HCLK_CRYPTO>,
> >>>> +					 <&cru SCLK_CRYPTO>;
> >>>> +				pm_qos = <&qos_crypto>;
> >>>> +				#power-domain-cells = <0>;
> >>>> +			};
> >>>> +		};
> >>>> +	};
> >>>> +
> >>>> +	qos_crypto: qos at 10128080 {
> >>>> +		compatible = "rockchip,rk3128-qos", "syscon";
> >>>> +		reg = <0x10128080 0x20>;
> >>>> +	};
> >>>> +
> >>>> +	qos_gpu: qos at 1012d000 {
> >>>> +		compatible = "rockchip,rk3128-qos", "syscon";
> >>>> +		reg = <0x1012d000 0x20>;
> >>>> +	};
> >>>> +
> >>>> +	qos_vpu: qos at 1012e000 {
> >>>> +		compatible = "rockchip,rk3128-qos", "syscon";
> >>>> +		reg = <0x1012e000 0x20>;
> >>>> +	};
> >>>> +
> >>>> +	qos_rga: qos at 1012f000 {
> >>>> +		compatible = "rockchip,rk3128-qos", "syscon";
> >>>> +		reg = <0x1012f000 0x20>;
> >>>> +	};
> >>>> +
> >>>> +	qos_ebc: qos at 1012f080 {
> >>>> +		compatible = "rockchip,rk3128-qos", "syscon";
> >>>> +		reg = <0x1012f080 0x20>;
> >>>> +	};
> >>>> +
> >>>> +	qos_iep: qos at 1012f100 {
> >>>> +		compatible = "rockchip,rk3128-qos", "syscon";
> >>>> +		reg = <0x1012f100 0x20>;
> >>>> +	};
> >>>> +
> >>>> +	qos_lcdc: qos at 1012f180 {
> >>>> +		compatible = "rockchip,rk3128-qos", "syscon";
> >>>> +		reg = <0x1012f180 0x20>;
> >>>> +	};
> >>>> +
> >>>> +	qos_vip: qos at 1012f200 {
> >>>> +		compatible = "rockchip,rk3128-qos", "syscon";
> >>>> +		reg = <0x1012f200 0x20>;
> >>>>    	};
> >>>>    
> >>>>    	gic: interrupt-controller at 10139000 {
> >>>>
> >>>
> >>>
> >
> >
> >
> 






From yoong.siang.song at intel.com  Sun Dec  3 08:51:26 2023
From: yoong.siang.song at intel.com (Song Yoong Siang)
Date: Mon,  4 Dec 2023 00:51:26 +0800
Subject: [PATCH bpf-next v3 0/3] xsk: TX metadata Launch Time support
Message-ID: <20231203165129.1740512-1-yoong.siang.song@intel.com>

This series expands XDP TX metadata framework to include ETF HW offload.

Changes since v1: (Willem)
- rename Time-Based Scheduling (TBS) to Earliest TxTime First (ETF)
- rename launch-time to txtime

Changes since v2: (Jesper & Willem)
- rename to use launch time
- change the default launch time in xdp_hw_metadata apps from 1s to 0.1s
  because some NICs do not support such a large future time.

v1: https://patchwork.kernel.org/project/netdevbpf/cover/20231130162028.852006-1-yoong.siang.song at intel.com/
v2: https://patchwork.kernel.org/project/netdevbpf/cover/20231201062421.1074768-1-yoong.siang.song at intel.com/

Song Yoong Siang (3):
  xsk: add Launch Time HW offload to XDP Tx metadata
  net: stmmac: add Launch Time support to XDP ZC
  selftests/bpf: add Launch Time request to xdp_hw_metadata

 Documentation/netlink/specs/netdev.yaml       |  4 ++++
 Documentation/networking/xsk-tx-metadata.rst  |  4 ++++
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  2 ++
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++
 include/net/xdp_sock.h                        | 10 ++++++++++
 include/net/xdp_sock_drv.h                    |  1 +
 include/uapi/linux/if_xdp.h                   |  9 +++++++++
 include/uapi/linux/netdev.h                   |  3 +++
 net/core/netdev-genl.c                        |  2 ++
 net/xdp/xsk.c                                 |  3 +++
 tools/include/uapi/linux/if_xdp.h             |  9 +++++++++
 tools/include/uapi/linux/netdev.h             |  3 +++
 tools/net/ynl/generated/netdev-user.c         |  1 +
 tools/testing/selftests/bpf/xdp_hw_metadata.c | 19 ++++++++++++++++++-
 14 files changed, 82 insertions(+), 1 deletion(-)

-- 
2.34.1



From yoong.siang.song at intel.com  Sun Dec  3 08:51:27 2023
From: yoong.siang.song at intel.com (Song Yoong Siang)
Date: Mon,  4 Dec 2023 00:51:27 +0800
Subject: [PATCH bpf-next v3 1/3] xsk: add Launch Time HW offload to XDP Tx metadata
In-Reply-To: <20231203165129.1740512-1-yoong.siang.song@intel.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
Message-ID: <20231203165129.1740512-2-yoong.siang.song@intel.com>

This patch extends the XDP Tx metadata framework so that user can requests
Launch Time hardware offload, where the NIC will schedule the packet for
transmission at a pre-determined time called launch time. The value of
launch time is communicated from user space to Ethernet driver via
launch_time field of struct xsk_tx_metadata.

Suggested-by: Stanislav Fomichev <sdf at google.com>
Signed-off-by: Song Yoong Siang <yoong.siang.song at intel.com>
---
 Documentation/netlink/specs/netdev.yaml      |  4 ++++
 Documentation/networking/xsk-tx-metadata.rst |  4 ++++
 include/net/xdp_sock.h                       | 10 ++++++++++
 include/net/xdp_sock_drv.h                   |  1 +
 include/uapi/linux/if_xdp.h                  |  9 +++++++++
 include/uapi/linux/netdev.h                  |  3 +++
 net/core/netdev-genl.c                       |  2 ++
 net/xdp/xsk.c                                |  3 +++
 tools/include/uapi/linux/if_xdp.h            |  9 +++++++++
 tools/include/uapi/linux/netdev.h            |  3 +++
 tools/net/ynl/generated/netdev-user.c        |  1 +
 11 files changed, 49 insertions(+)

diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/netlink/specs/netdev.yaml
index eef6358ec587..a8bec7ddbdb0 100644
--- a/Documentation/netlink/specs/netdev.yaml
+++ b/Documentation/netlink/specs/netdev.yaml
@@ -66,6 +66,10 @@ definitions:
         name: tx-checksum
         doc:
           L3 checksum HW offload is supported by the driver.
+      -
+        name: launch-time
+        doc:
+          Launch Time HW offload is supported by the driver.
 
 attribute-sets:
   -
diff --git a/Documentation/networking/xsk-tx-metadata.rst b/Documentation/networking/xsk-tx-metadata.rst
index 97ecfa480d00..6d53e191d4ae 100644
--- a/Documentation/networking/xsk-tx-metadata.rst
+++ b/Documentation/networking/xsk-tx-metadata.rst
@@ -44,6 +44,9 @@ The flags field enables the particular offload:
   checksum. ``csum_start`` specifies byte offset of where the checksumming
   should start and ``csum_offset`` specifies byte offset where the
   device should store the computed checksum.
+- ``XDP_TXMD_FLAGS_LAUNCH_TIME``: requests Launch Time HW offload to
+  launch the packet at a pre-determined time. ``launch_time`` indicates
+  the time which the NIC should schedule the packet for transmission.
 
 Besides the flags above, in order to trigger the offloads, the first
 packet's ``struct xdp_desc`` descriptor should set ``XDP_TX_METADATA``
@@ -68,6 +71,7 @@ Refer to ``xsk-flags`` features bitmask in
 
 - ``tx-timestamp``: device supports ``XDP_TXMD_FLAGS_TIMESTAMP``
 - ``tx-checksum``: device supports ``XDP_TXMD_FLAGS_CHECKSUM``
+- ``launch-time``: device supports ``XDP_TXMD_FLAGS_LAUNCH_TIME``
 
 See ``tools/net/ynl/samples/netdev.c`` on how to query this information.
 
diff --git a/include/net/xdp_sock.h b/include/net/xdp_sock.h
index 3cb4dc9bd70e..516baa8a3b1f 100644
--- a/include/net/xdp_sock.h
+++ b/include/net/xdp_sock.h
@@ -110,11 +110,16 @@ struct xdp_sock {
  *     indicates position where checksumming should start.
  *     csum_offset indicates position where checksum should be stored.
  *
+ * void (*tmo_request_launch_time)(u64 launch_time, void *priv)
+ *     Called when AF_XDP frame requested Launch Time HW offload support.
+ *     launch_time indicates the time which the NIC should schedule the packet for
+ *     transmission.
  */
 struct xsk_tx_metadata_ops {
 	void	(*tmo_request_timestamp)(void *priv);
 	u64	(*tmo_fill_timestamp)(void *priv);
 	void	(*tmo_request_checksum)(u16 csum_start, u16 csum_offset, void *priv);
+	void	(*tmo_request_launch_time)(u64 launch_time, void *priv);
 };
 
 #ifdef CONFIG_XDP_SOCKETS
@@ -170,6 +175,11 @@ static inline void xsk_tx_metadata_request(const struct xsk_tx_metadata *meta,
 		if (meta->flags & XDP_TXMD_FLAGS_CHECKSUM)
 			ops->tmo_request_checksum(meta->request.csum_start,
 						  meta->request.csum_offset, priv);
+
+	if (ops->tmo_request_launch_time)
+		if (meta->flags & XDP_TXMD_FLAGS_LAUNCH_TIME)
+			ops->tmo_request_launch_time(meta->request.launch_time,
+						     priv);
 }
 
 /**
diff --git a/include/net/xdp_sock_drv.h b/include/net/xdp_sock_drv.h
index 81e02de3f453..5b88559e956b 100644
--- a/include/net/xdp_sock_drv.h
+++ b/include/net/xdp_sock_drv.h
@@ -168,6 +168,7 @@ static inline void *xsk_buff_raw_get_data(struct xsk_buff_pool *pool, u64 addr)
 #define XDP_TXMD_FLAGS_VALID ( \
 		XDP_TXMD_FLAGS_TIMESTAMP | \
 		XDP_TXMD_FLAGS_CHECKSUM | \
+		XDP_TXMD_FLAGS_LAUNCH_TIME | \
 	0)
 
 static inline bool xsk_buff_valid_tx_metadata(struct xsk_tx_metadata *meta)
diff --git a/include/uapi/linux/if_xdp.h b/include/uapi/linux/if_xdp.h
index d31698410410..e81bed455ec1 100644
--- a/include/uapi/linux/if_xdp.h
+++ b/include/uapi/linux/if_xdp.h
@@ -123,6 +123,12 @@ struct xdp_options {
  */
 #define XDP_TXMD_FLAGS_CHECKSUM			(1 << 1)
 
+/* Request Launch Time HW offload to launch the packet at a pre-determined time.
+ * The time which the NIC should schedule the packet for transmission is
+ * communicated via launch_time field of struct xsk_tx_metadata.
+ */
+#define XDP_TXMD_FLAGS_LAUNCH_TIME		(1 << 2)
+
 /* AF_XDP offloads request. 'request' union member is consumed by the driver
  * when the packet is being transmitted. 'completion' union member is
  * filled by the driver when the transmit completion arrives.
@@ -138,6 +144,9 @@ struct xsk_tx_metadata {
 			__u16 csum_start;
 			/* Offset from csum_start where checksum should be stored. */
 			__u16 csum_offset;
+
+			/* XDP_TXMD_FLAGS_LAUNCH_TIME */
+			__u64 launch_time;
 		} request;
 
 		struct {
diff --git a/include/uapi/linux/netdev.h b/include/uapi/linux/netdev.h
index 6244c0164976..b77baf1cffd7 100644
--- a/include/uapi/linux/netdev.h
+++ b/include/uapi/linux/netdev.h
@@ -56,10 +56,13 @@ enum netdev_xdp_rx_metadata {
  *   by the driver.
  * @NETDEV_XSK_FLAGS_TX_CHECKSUM: L3 checksum HW offload is supported by the
  *   driver.
+ * @NETDEV_XSK_FLAGS_LAUNCH_TIME: Launch Time HW offload is supported by the
+ *   driver.
  */
 enum netdev_xsk_flags {
 	NETDEV_XSK_FLAGS_TX_TIMESTAMP = 1,
 	NETDEV_XSK_FLAGS_TX_CHECKSUM = 2,
+	NETDEV_XSK_FLAGS_LAUNCH_TIME = 3,
 };
 
 enum {
diff --git a/net/core/netdev-genl.c b/net/core/netdev-genl.c
index 10f2124e9e23..c38521269b4e 100644
--- a/net/core/netdev-genl.c
+++ b/net/core/netdev-genl.c
@@ -33,6 +33,8 @@ XDP_METADATA_KFUNC_xxx
 			xsk_features |= NETDEV_XSK_FLAGS_TX_TIMESTAMP;
 		if (netdev->xsk_tx_metadata_ops->tmo_request_checksum)
 			xsk_features |= NETDEV_XSK_FLAGS_TX_CHECKSUM;
+		if (netdev->xsk_tx_metadata_ops->tmo_request_launch_time)
+			xsk_features |= NETDEV_XSK_FLAGS_LAUNCH_TIME;
 	}
 
 	if (nla_put_u32(rsp, NETDEV_A_DEV_IFINDEX, netdev->ifindex) ||
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index 281d49b4fca4..ad98ac6adb43 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -751,6 +751,9 @@ static struct sk_buff *xsk_build_skb(struct xdp_sock *xs,
 						goto free_err;
 				}
 			}
+
+			if (meta->flags & XDP_TXMD_FLAGS_LAUNCH_TIME)
+				skb->skb_mstamp_ns = meta->request.launch_time;
 		}
 	}
 
diff --git a/tools/include/uapi/linux/if_xdp.h b/tools/include/uapi/linux/if_xdp.h
index 638c606dfa74..b9c5eeef0bfb 100644
--- a/tools/include/uapi/linux/if_xdp.h
+++ b/tools/include/uapi/linux/if_xdp.h
@@ -123,6 +123,12 @@ struct xdp_options {
  */
 #define XDP_TXMD_FLAGS_CHECKSUM			(1 << 1)
 
+/* Request Launch Time HW offload to launch the packet at a pre-determined time.
+ * The time which the NIC should schedule the packet for transmission is
+ * communicated via launch_time field of struct xsk_tx_metadata.
+ */
+#define XDP_TXMD_FLAGS_LAUNCH_TIME		(1 << 2)
+
 /* AF_XDP offloads request. 'request' union member is consumed by the driver
  * when the packet is being transmitted. 'completion' union member is
  * filled by the driver when the transmit completion arrives.
@@ -138,6 +144,9 @@ struct xsk_tx_metadata {
 			__u16 csum_start;
 			/* Offset from csum_start where checksum should be stored. */
 			__u16 csum_offset;
+
+			/* XDP_TXMD_FLAGS_LAUNCH_TIME */
+			__u64 launch_time;
 		} request;
 
 		struct {
diff --git a/tools/include/uapi/linux/netdev.h b/tools/include/uapi/linux/netdev.h
index 6244c0164976..b77baf1cffd7 100644
--- a/tools/include/uapi/linux/netdev.h
+++ b/tools/include/uapi/linux/netdev.h
@@ -56,10 +56,13 @@ enum netdev_xdp_rx_metadata {
  *   by the driver.
  * @NETDEV_XSK_FLAGS_TX_CHECKSUM: L3 checksum HW offload is supported by the
  *   driver.
+ * @NETDEV_XSK_FLAGS_LAUNCH_TIME: Launch Time HW offload is supported by the
+ *   driver.
  */
 enum netdev_xsk_flags {
 	NETDEV_XSK_FLAGS_TX_TIMESTAMP = 1,
 	NETDEV_XSK_FLAGS_TX_CHECKSUM = 2,
+	NETDEV_XSK_FLAGS_LAUNCH_TIME = 3,
 };
 
 enum {
diff --git a/tools/net/ynl/generated/netdev-user.c b/tools/net/ynl/generated/netdev-user.c
index 3b9dee94d4ce..5f20b23b64ba 100644
--- a/tools/net/ynl/generated/netdev-user.c
+++ b/tools/net/ynl/generated/netdev-user.c
@@ -66,6 +66,7 @@ const char *netdev_xdp_rx_metadata_str(enum netdev_xdp_rx_metadata value)
 static const char * const netdev_xsk_flags_strmap[] = {
 	[0] = "tx-timestamp",
 	[1] = "tx-checksum",
+	[2] = "launch-time"
 };
 
 const char *netdev_xsk_flags_str(enum netdev_xsk_flags value)
-- 
2.34.1



From yoong.siang.song at intel.com  Sun Dec  3 08:51:28 2023
From: yoong.siang.song at intel.com (Song Yoong Siang)
Date: Mon,  4 Dec 2023 00:51:28 +0800
Subject: [PATCH bpf-next v3 2/3] net: stmmac: add Launch Time support to XDP ZC
In-Reply-To: <20231203165129.1740512-1-yoong.siang.song@intel.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
Message-ID: <20231203165129.1740512-3-yoong.siang.song@intel.com>

This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
copy via XDP Tx metadata framework.

Signed-off-by: Song Yoong Siang <yoong.siang.song at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 686c94c2e8a7..e8538af6e207 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -105,6 +105,8 @@ struct stmmac_metadata_request {
 	struct stmmac_priv *priv;
 	struct dma_desc *tx_desc;
 	bool *set_ic;
+	struct dma_edesc *edesc;
+	int tbs;
 };
 
 struct stmmac_xsk_tx_complete {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c2ac88aaffed..1fe80bfae24b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2465,9 +2465,20 @@ static u64 stmmac_xsk_fill_timestamp(void *_priv)
 	return 0;
 }
 
+static void stmmac_xsk_request_launch_time(u64 launch_time, void *_priv)
+{
+	struct stmmac_metadata_request *meta_req = _priv;
+	struct timespec64 ts = ns_to_timespec64(launch_time);
+
+	if (meta_req->tbs & STMMAC_TBS_EN)
+		stmmac_set_desc_tbs(meta_req->priv, meta_req->edesc, ts.tv_sec,
+				    ts.tv_nsec);
+}
+
 static const struct xsk_tx_metadata_ops stmmac_xsk_tx_metadata_ops = {
 	.tmo_request_timestamp		= stmmac_xsk_request_timestamp,
 	.tmo_fill_timestamp		= stmmac_xsk_fill_timestamp,
+	.tmo_request_launch_time	= stmmac_xsk_request_launch_time,
 };
 
 static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)
@@ -2545,6 +2556,8 @@ static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)
 		meta_req.priv = priv;
 		meta_req.tx_desc = tx_desc;
 		meta_req.set_ic = &set_ic;
+		meta_req.tbs = tx_q->tbs;
+		meta_req.edesc = &tx_q->dma_entx[entry];
 		xsk_tx_metadata_request(meta, &stmmac_xsk_tx_metadata_ops,
 					&meta_req);
 		if (set_ic) {
-- 
2.34.1



From yoong.siang.song at intel.com  Sun Dec  3 08:51:29 2023
From: yoong.siang.song at intel.com (Song Yoong Siang)
Date: Mon,  4 Dec 2023 00:51:29 +0800
Subject: [PATCH bpf-next v3 3/3] selftests/bpf: add Launch Time request to xdp_hw_metadata
In-Reply-To: <20231203165129.1740512-1-yoong.siang.song@intel.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
Message-ID: <20231203165129.1740512-4-yoong.siang.song@intel.com>

This patch adds Launch Time hw offload request to xdp_hw_metadata. User can
configure the delta of HW launch time to HW RX-time by using "-l" argument.
The default delta is set to 0.1 second.

This patch is tested with stmmac on Intel Tiger Lake platform. Refer to
result below, the delta between pre-determined launch time and actual HW
transmit complete time is around 24 us.

$ sudo ./xdp_hw_metadata eth0
...
xsk_ring_cons__peek: 1
0x55e577c3a7a8: rx_desc[0]->addr=80100 addr=80100 comp_addr=80100 EoP
No rx_hash err=-95
HW RX-time:   1677762523393813392 (sec:1677762523.3938) delta to User RX-time sec:0.0003 (259.290 usec)
XDP RX-time:   1677762523394050576 (sec:1677762523.3941) delta to User RX-time sec:0.0000 (22.106 usec)
0x55e577c3a7a8: ping-pong with csum=5619 (want 8626) csum_start=34 csum_offset=6
HW RX-time:   1677762523393813392 (sec:1677762523.3938) delta to HW Launch-time sec:0.1000 (100000.000 usec)
0x55e577c3a7a8: complete tx idx=0 addr=18
HW Launch-time:   1677762523493813392 (sec:1677762523.4938) delta to HW TX-complete-time sec:0.0000 (24.181 usec)
HW TX-complete-time:   1677762523493837573 (sec:1677762523.4938) delta to User TX-complete-time sec:0.0007 (737.636 usec)
XDP RX-time:   1677762523394050576 (sec:1677762523.3941) delta to User TX-complete-time sec:0.1005 (100524.633 usec)
HW RX-time:   1677762523393813392 (sec:1677762523.3938) delta to HW TX-complete-time sec:0.1000 (100024.181 usec)
0x55e577c3a7a8: complete rx idx=128 addr=80100

$ sudo ./xdp_hw_metadata eth0 -l 10000000
...
poll: 1 (0) skip=17 fail=0 redir=17
xsk_ring_cons__peek: 1
0x558336d397a8: rx_desc[15]->addr=9e100 addr=9e100 comp_addr=9e100 EoP
No rx_hash err=-95
HW RX-time:   1677762699254666655 (sec:1677762699.2547) delta to User RX-time sec:0.0003 (256.928 usec)
XDP RX-time:   1677762699254901232 (sec:1677762699.2549) delta to User RX-time sec:0.0000 (22.351 usec)
0x558336d397a8: ping-pong with csum=5619 (want 8626) csum_start=34 csum_offset=6
HW RX-time:   1677762699254666655 (sec:1677762699.2547) delta to HW Launch-time sec:0.0100 (10000.000 usec)
0x558336d397a8: complete tx idx=15 addr=f018
HW Launch-time:   1677762699264666655 (sec:1677762699.2647) delta to HW TX-complete-time sec:0.0000 (24.307 usec)
HW TX-complete-time:   1677762699264690962 (sec:1677762699.2647) delta to User TX-complete-time sec:0.0003 (309.901 usec)
XDP RX-time:   1677762699254901232 (sec:1677762699.2549) delta to User TX-complete-time sec:0.0101 (10099.631 usec)
HW RX-time:   1677762699254666655 (sec:1677762699.2547) delta to HW TX-complete-time sec:0.0100 (10024.307 usec)
0x558336d397a8: complete rx idx=143 addr=9e100

Signed-off-by: Song Yoong Siang <yoong.siang.song at intel.com>
---
 tools/testing/selftests/bpf/xdp_hw_metadata.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/xdp_hw_metadata.c b/tools/testing/selftests/bpf/xdp_hw_metadata.c
index 3291625ba4fb..3e238bb310b7 100644
--- a/tools/testing/selftests/bpf/xdp_hw_metadata.c
+++ b/tools/testing/selftests/bpf/xdp_hw_metadata.c
@@ -13,6 +13,7 @@
  * - UDP 9091 packets trigger TX reply
  * - TX HW timestamp is requested and reported back upon completion
  * - TX checksum is requested
+ * - HW launch time is set for transmission
  */
 
 #include <test_progs.h>
@@ -61,6 +62,8 @@ int rxq;
 bool skip_tx;
 __u64 last_hw_rx_timestamp;
 __u64 last_xdp_rx_timestamp;
+__u64 last_launch_time;
+__u64 launch_time_delta_to_hw_rx_timestamp = 100000000; /* 0.1 second */
 
 void test__fail(void) { /* for network_helpers.c */ }
 
@@ -274,6 +277,8 @@ static bool complete_tx(struct xsk *xsk, clockid_t clock_id)
 	if (meta->completion.tx_timestamp) {
 		__u64 ref_tstamp = gettime(clock_id);
 
+		print_tstamp_delta("HW Launch-time", "HW TX-complete-time",
+				   last_launch_time, meta->completion.tx_timestamp);
 		print_tstamp_delta("HW TX-complete-time", "User TX-complete-time",
 				   meta->completion.tx_timestamp, ref_tstamp);
 		print_tstamp_delta("XDP RX-time", "User TX-complete-time",
@@ -371,6 +376,14 @@ static void ping_pong(struct xsk *xsk, void *rx_packet, clockid_t clock_id)
 	       xsk, ntohs(udph->check), ntohs(want_csum),
 	       meta->request.csum_start, meta->request.csum_offset);
 
+	/* Set the value of launch time */
+	meta->flags |= XDP_TXMD_FLAGS_LAUNCH_TIME;
+	meta->request.launch_time = last_hw_rx_timestamp +
+				    launch_time_delta_to_hw_rx_timestamp;
+	last_launch_time = meta->request.launch_time;
+	print_tstamp_delta("HW RX-time", "HW Launch-time", last_hw_rx_timestamp,
+			   meta->request.launch_time);
+
 	memcpy(data, rx_packet, len); /* don't share umem chunk for simplicity */
 	tx_desc->options |= XDP_TX_METADATA;
 	tx_desc->len = len;
@@ -595,6 +608,7 @@ static void print_usage(void)
 		"  -h    Display this help and exit\n\n"
 		"  -m    Enable multi-buffer XDP for larger MTU\n"
 		"  -r    Don't generate AF_XDP reply (rx metadata only)\n"
+		"  -l    Delta of HW Launch-time to HW RX-time in ns (default: 0.1s)\n"
 		"Generate test packets on the other machine with:\n"
 		"  echo -n xdp | nc -u -q1 <dst_ip> 9091\n";
 
@@ -605,7 +619,7 @@ static void read_args(int argc, char *argv[])
 {
 	int opt;
 
-	while ((opt = getopt(argc, argv, "chmr")) != -1) {
+	while ((opt = getopt(argc, argv, "chmrl:")) != -1) {
 		switch (opt) {
 		case 'c':
 			bind_flags &= ~XDP_USE_NEED_WAKEUP;
@@ -621,6 +635,9 @@ static void read_args(int argc, char *argv[])
 		case 'r':
 			skip_tx = true;
 			break;
+		case 'l':
+			launch_time_delta_to_hw_rx_timestamp = atoll(optarg);
+			break;
 		case '?':
 			if (isprint(optopt))
 				fprintf(stderr, "Unknown option: -%c\n", optopt);
-- 
2.34.1



From wahrenst at gmx.net  Sun Dec  3 08:56:24 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Sun, 3 Dec 2023 17:56:24 +0100
Subject: [PATCH V3 1/3] dt-bindings: usb: xhci: add support for BCM2711
In-Reply-To: <20231203-traffic-aide-cb03afdb3546@spud>
References: <20231202232217.89652-1-wahrenst@gmx.net>
 <20231202232217.89652-2-wahrenst@gmx.net>
 <20231203-chair-zen-afb8b280ca2f@spud>
 <20231203-traffic-aide-cb03afdb3546@spud>
Message-ID: <7dd529a0-ebee-4f3b-879b-c7b1033cfdb9@gmx.net>

Hi,

Am 03.12.23 um 12:11 schrieb Conor Dooley:
> On Sun, Dec 03, 2023 at 11:06:43AM +0000, Conor Dooley wrote:
>> On Sun, Dec 03, 2023 at 12:22:15AM +0100, Stefan Wahren wrote:
>>> The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
>>> but also requires a power domain.
> Hmm
> This & the driver change makes it look like your compatible setup should
> be `compatible = "brcm,bcm2711-xhci", "brcm,xhci-brcm-v2";.
i don't have insight into the hardware, but the fact that the other
Broadcom SoC didn't require a power domain before let me think we
shouldn't do this. Otherwise this binding was broken before. But Justin
and Florian could clarify this.
> If the pattern in this patch was repeated, we'd have to modify the
> driver like your 2nd patch does for each and new broadcom system that
> needs the power domain.
 From my understanding the DT compatible should be specific as possible.
This is what i did, especially because the Raspberry Pi boards tends to
needs some quirks.

Best regards
>
>
>>> So introduce a new compatible
>>> and the specific constraints. Since the key allOf can only occur
>>> once, merge the reference below.
>>>
>>> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
>> Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
>>
>> Cheers,
>> Conor.
>>
>>> ---
>>>   .../devicetree/bindings/usb/generic-xhci.yaml | 21 ++++++++++++++++---
>>>   1 file changed, 18 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
>>> index 594ebb3ee432..b6e10b0a3c24 100644
>>> --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
>>> @@ -9,9 +9,6 @@ title: USB xHCI Controller
>>>   maintainers:
>>>     - Mathias Nyman <mathias.nyman at intel.com>
>>>
>>> -allOf:
>>> -  - $ref: usb-xhci.yaml#
>>> -
>>>   properties:
>>>     compatible:
>>>       oneOf:
>>> @@ -28,6 +25,7 @@ properties:
>>>         - description: Broadcom STB SoCs with xHCI
>>>           enum:
>>>             - brcm,xhci-brcm-v2
>>> +          - brcm,bcm2711-xhci
>>>             - brcm,bcm7445-xhci
>>>         - description: Generic xHCI device
>>>           const: xhci-platform
>>> @@ -49,6 +47,9 @@ properties:
>>>         - const: core
>>>         - const: reg
>>>
>>> +  power-domains:
>>> +    maxItems: 1
>>> +
>>>   unevaluatedProperties: false
>>>
>>>   required:
>>> @@ -56,6 +57,20 @@ required:
>>>     - reg
>>>     - interrupts
>>>
>>> +allOf:
>>> +  - $ref: usb-xhci.yaml#
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            const: brcm,bcm2711-xhci
>>> +    then:
>>> +      required:
>>> +        - power-domains
>>> +    else:
>>> +      properties:
>>> +        power-domains: false
>>> +
>>>   examples:
>>>     - |
>>>       usb at f0931000 {
>>> --
>>> 2.34.1
>>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From laurent.pinchart at ideasonboard.com  Sun Dec  3 08:59:59 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Sun, 3 Dec 2023 18:59:59 +0200
Subject: [PATCH] media: nxp: isi: Check whether pad is non-NULL before
 access
In-Reply-To: <20231201150614.63300-1-marex@denx.de>
References: <20231201150614.63300-1-marex@denx.de>
Message-ID: <20231203165959.GA22111@pendragon.ideasonboard.com>

Hi Marek,

Thank you for the patch.

On Fri, Dec 01, 2023 at 04:06:04PM +0100, Marek Vasut wrote:
> The pad can be NULL if media controller routing is not set up correctly.
> Check whether the pad is NULL before using it, otherwise it is possible
> to achieve NULL pointer dereference.

Could you share more information about how to misconfigure the routing ?

> Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
> Signed-off-by: Marek Vasut <marex at denx.de>
> ---
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Cc: Mauro Carvalho Chehab <mchehab at kernel.org>
> Cc: NXP Linux Team <linux-imx at nxp.com>
> Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> Cc: Sascha Hauer <s.hauer at pengutronix.de>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-media at vger.kernel.org
> ---
>  drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> index 792f031e032ae..44354931cf8a1 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> @@ -160,8 +160,14 @@ mxc_isi_crossbar_xlate_streams(struct mxc_isi_crossbar *xbar,
>  	}
>  
>  	pad = media_pad_remote_pad_first(&xbar->pads[sink_pad]);
> -	sd = media_entity_to_v4l2_subdev(pad->entity);
> +	if (!pad) {
> +		dev_dbg(xbar->isi->dev,
> +			"no pad connected to crossbar input %u\n",
> +			sink_pad);
> +		return ERR_PTR(-EPIPE);
> +	}
>  
> +	sd = media_entity_to_v4l2_subdev(pad->entity);
>  	if (!sd) {
>  		dev_dbg(xbar->isi->dev,
>  			"no entity connected to crossbar input %u\n",

-- 
Regards,

Laurent Pinchart


From laurent.pinchart at ideasonboard.com  Sun Dec  3 09:00:57 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Sun, 3 Dec 2023 19:00:57 +0200
Subject: [PATCH] media: nxp: isi: Check whether pad is non-NULL before
 access
In-Reply-To: <890ae113-7c7f-4214-9b00-ce00fc570567@denx.de>
References: <20231201150614.63300-1-marex@denx.de>
 <CAOMZO5BssVez71=uCYd0XhL02xd1TrUyTzCc1fq_sWfENLaoTA@mail.gmail.com>
 <890ae113-7c7f-4214-9b00-ce00fc570567@denx.de>
Message-ID: <20231203170057.GB22111@pendragon.ideasonboard.com>

On Sat, Dec 02, 2023 at 07:44:47AM +0100, Marek Vasut wrote:
> On 12/2/23 03:27, Fabio Estevam wrote:
> > On Fri, Dec 1, 2023 at 12:06?PM Marek Vasut <marex at denx.de> wrote:
> > 
> >>          pad = media_pad_remote_pad_first(&xbar->pads[sink_pad]);
> >> -       sd = media_entity_to_v4l2_subdev(pad->entity);
> >> +       if (!pad) {
> >> +               dev_dbg(xbar->isi->dev,
> > 
> > Maybe dev_err() here instead?
> 
> That dev_dbg() is aligned with the prints in the rest of the function 
> and it's not like kernel should do dev_err() into kernel log every time 
> userspace does something wrong.

We usually use dev_dbg() for errors that can be easily triggered from
userspace, to avoid giving unpriviledged processes an easy way to flood
the kernel log.

> > Anyway:
> > 
> > Reviewed-by: Fabio Estevam <festevam at gmail.com>
> 
> Thanks !

-- 
Regards,

Laurent Pinchart


From krzysztof.kozlowski at linaro.org  Sun Dec  3 09:46:22 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun,  3 Dec 2023 18:46:22 +0100
Subject: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
Message-ID: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>

Document preferred coding style for Devicetree sources (DTS and DTSI),
to bring consistency among all (sub)architectures and ease in reviews.

Cc: Andrew Davis <afd at ti.com>
cc: Andrew Lunn <andrew at lunn.ch>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Bjorn Andersson <andersson at kernel.org>
Cc: Chen-Yu Tsai <wens at kernel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Cc: Jonathan Corbet <corbet at lwn.net>
Cc: Matthias Brugger <matthias.bgg at gmail.com>
Cc: Michal Simek <michal.simek at amd.com>
Cc: Neil Armstrong <neil.armstrong at linaro.org>
Cc: Nishanth Menon <nm at ti.com>
Cc: Olof Johansson <olof at lixom.net>
Cc: Rafa? Mi?ecki <zajec5 at gmail.com>
Acked-by: Neil Armstrong <neil.armstrong at linaro.org>
Acked-by: Heiko Stuebner <heiko at sntech.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Acked-by: Konrad Dybcio <konradybcio at kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

Merging idea: Rob/DT bindings

Changes in v4
=============
1. Drop label at the top (Jon)
2. Grammar fixes (Laurent, Dragan)
3. "Unless a bus defines differently, unit addresses shall ..." (Rob)
4. Use hex in example of dma-controller (Andrew)
5. Example: soc@ -> soc at 0
6. Reverse points 2 and 3 in "Indentation" (Andrew)
7. Use full path to coding style doc (Conor)

Changes in v3
=============
1. should->shall (Angelo)
2. Comments // -> /* (Angelo, Michal)
3. Use imaginary example in "Order of Properties in Device Node"
   (Angelo)
4. Added paragraphs for three sections with justifications of chosen
   style.
5. Allow two style of ordering overrides in board DTS: alphabetically or
   by order of DTSI (Rob).
6. I did not incorporate feedback about, due to lack of consensus and my
   disagreement:
   a. SoM being DTS without DTSI in "Organizing DTSI and DTS"

Changes in v2
=============
1. Hopefully incorporate entire feedback from comments:
a. Fix \ { => / { (Rob)
b. Name: dts-coding-style (Rob)
c. Exceptions for ordering nodes by name for Renesas and pinctrl (Geert,
   Konrad)
d. Ordering properties by common/vendor (Rob)
e. Array entries in <> (Rob)

2. New chapter: Organizing DTSI and DTS

3. Several grammar fixes (missing articles)

Cc: linux-rockchip at lists.infradead.org
Cc: linux-mediatek at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-amlogic at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-arm-msm at vger.kernel.org
Cc: workflows at vger.kernel.org
Cc: linux-doc at vger.kernel.org
---
 .../devicetree/bindings/dts-coding-style.rst  | 196 ++++++++++++++++++
 Documentation/devicetree/bindings/index.rst   |   1 +
 2 files changed, 197 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dts-coding-style.rst

diff --git a/Documentation/devicetree/bindings/dts-coding-style.rst b/Documentation/devicetree/bindings/dts-coding-style.rst
new file mode 100644
index 000000000000..ffd7617f95fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/dts-coding-style.rst
@@ -0,0 +1,196 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Devicetree Sources (DTS) Coding Style
+=====================================
+
+When writing Devicetree Sources (DTS) please observe below guidelines.  They
+should be considered complementary to any rules expressed already in
+the Devicetree Specification and the dtc compiler (including W=1 and W=2
+builds).
+
+Individual architectures and subarchitectures can define additional rules,
+making the coding style stricter.
+
+Naming and Valid Characters
+---------------------------
+
+The Devicetree Specification allows a broad range of characters in node
+and property names, but this coding style narrows the range down to achieve
+better code readability.
+
+1. Node and property names can use only the following characters:
+
+   * Lowercase characters: [a-z]
+   * Digits: [0-9]
+   * Dash: -
+
+2. Labels can use only the following characters:
+
+   * Lowercase characters: [a-z]
+   * Digits: [0-9]
+   * Underscore: _
+
+3. Unless a bus defines differently, unit addresses shall use lowercase
+   hexadecimal digits, without leading zeros (padding).
+
+4. Hex values in properties, e.g. "reg", shall use lowercase hex.  The address
+   part can be padded with leading zeros.
+
+Example::
+
+	gpi_dma2: dma-controller at a00000 {
+		compatible = "qcom,sm8550-gpi-dma", "qcom,sm6350-gpi-dma";
+		reg = <0x0 0x00a00000 0x0 0x60000>;
+	}
+
+Order of Nodes
+--------------
+
+1. Nodes on any bus, thus using unit addresses for children, shall be
+   ordered by unit address in ascending order.
+   Alternatively for some subarchitectures, nodes of the same type can be
+   grouped together, e.g. all I2C controllers one after another even if this
+   breaks unit address ordering.
+
+2. Nodes without unit addresses shall be ordered alpha-numerically by the node
+   name.  For a few node types, they can be ordered by the main property, e.g.
+   pin configuration states ordered by value of "pins" property.
+
+3. When extending nodes in the board DTS via &label, the entries shall be
+   ordered either alpha-numerically or by keeping the order from DTSI, where
+   the choice depends on the subarchitecture.
+
+The above-described ordering rules are easy to enforce during review, reduce
+chances of conflicts for simultaneous additions of new nodes to a file and help
+in navigating through the DTS source.
+
+Example::
+
+	/* SoC DTSI */
+
+	/ {
+		cpus {
+			/* ... */
+		};
+
+		psci {
+			/* ... */
+		};
+
+		soc at 0 {
+			dma: dma-controller at 10000 {
+				/* ... */
+			};
+
+			clk: clock-controller at 80000 {
+				/* ... */
+			};
+		};
+	};
+
+	/* Board DTS - alphabetical order */
+
+	&clk {
+		/* ... */
+	};
+
+	&dma {
+		/* ... */
+	};
+
+	/* Board DTS - alternative order, keep as DTSI */
+
+	&dma {
+		/* ... */
+	};
+
+	&clk {
+		/* ... */
+	};
+
+Order of Properties in Device Node
+----------------------------------
+
+The following order of properties in device nodes is preferred:
+
+1. compatible
+2. reg
+3. ranges
+4. Standard/common properties (defined by common bindings, e.g. without
+   vendor-prefixes)
+5. Vendor-specific properties
+6. status (if applicable)
+7. Child nodes, where each node is preceded with a blank line
+
+The "status" property is by default "okay", thus it can be omitted.
+
+The above-described ordering follows this approach:
+
+1. Most important properties start the node: compatible then bus addressing to
+   match unit address.
+2. Each node will have common properties in similar place.
+3. Status is the last information to annotate that device node is or is not
+   finished (board resources are needed).
+
+Example::
+
+	/* SoC DTSI */
+
+	device_node: device-class at 6789abc {
+		compatible = "vendor,device";
+		reg = <0x0 0x06789abc 0x0 0xa123>;
+		ranges = <0x0 0x0 0x06789abc 0x1000>;
+		#dma-cells = <1>;
+		clocks = <&clock_controller 0>, <&clock_controller 1>;
+		clock-names = "bus", "host";
+		vendor,custom-property = <2>;
+		status = "disabled";
+
+		child_node: child-class at 100 {
+			reg = <0x100 0x200>;
+			/* ... */
+		};
+	};
+
+	/* Board DTS */
+
+	&device_node {
+		vdd-supply = <&board_vreg1>;
+		status = "okay";
+	}
+
+Indentation
+-----------
+
+1. Use indentation according to Documentation/process/coding-style.rst.
+2. Each entry in arrays with multiple cells, e.g. "reg" with two IO addresses,
+   shall be enclosed in <>.
+3. For arrays spanning across lines, it is preferred to align the continued
+   entries with opening < from the first line.
+
+Example::
+
+	thermal-sensor at c271000 {
+		compatible = "qcom,sm8550-tsens", "qcom,tsens-v2";
+		reg = <0x0 0x0c271000 0x0 0x1000>,
+		      <0x0 0x0c222000 0x0 0x1000>;
+	};
+
+Organizing DTSI and DTS
+-----------------------
+
+The DTSI and DTS files shall be organized in a way representing the common,
+reusable parts of hardware.  Typically, this means organizing DTSI and DTS files
+into several files:
+
+1. DTSI with contents of the entire SoC, without nodes for hardware not present
+   on the SoC.
+2. If applicable: DTSI with common or re-usable parts of the hardware, e.g.
+   entire System-on-Module.
+3. DTS representing the board.
+
+Hardware components that are present on the board shall be placed in the
+board DTS, not in the SoC or SoM DTSI.  A partial exception is a common
+external reference SoC input clock, which could be coded as a fixed-clock in
+the SoC DTSI with its frequency provided by each board DTS.
diff --git a/Documentation/devicetree/bindings/index.rst b/Documentation/devicetree/bindings/index.rst
index d9002a3a0abb..cc1fbdc05657 100644
--- a/Documentation/devicetree/bindings/index.rst
+++ b/Documentation/devicetree/bindings/index.rst
@@ -4,6 +4,7 @@
    :maxdepth: 1
 
    ABI
+   dts-coding-style
    writing-bindings
    writing-schema
    submitting-patches
-- 
2.34.1



From francesco at dolcini.it  Sun Dec  3 10:40:30 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Sun, 3 Dec 2023 19:40:30 +0100
Subject: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
References: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
Message-ID: <ZWzLns9CPK3xeTzG@livingston.pivistrello.it>

Hello Krzysztof,

On Sun, Dec 03, 2023 at 06:46:22PM +0100, Krzysztof Kozlowski wrote:
> Document preferred coding style for Devicetree sources (DTS and DTSI),
> to bring consistency among all (sub)architectures and ease in reviews.
> 
> Cc: Andrew Davis <afd at ti.com>
> cc: Andrew Lunn <andrew at lunn.ch>
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Bjorn Andersson <andersson at kernel.org>
> Cc: Chen-Yu Tsai <wens at kernel.org>
> Cc: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> Cc: Jonathan Corbet <corbet at lwn.net>
> Cc: Matthias Brugger <matthias.bgg at gmail.com>
> Cc: Michal Simek <michal.simek at amd.com>
> Cc: Neil Armstrong <neil.armstrong at linaro.org>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Olof Johansson <olof at lixom.net>
> Cc: Rafa? Mi?ecki <zajec5 at gmail.com>
> Acked-by: Neil Armstrong <neil.armstrong at linaro.org>
> Acked-by: Heiko Stuebner <heiko at sntech.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Acked-by: Konrad Dybcio <konradybcio at kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Reviewed-by: Francesco Dolcini <francesco.dolcini at toradex.com>

Francesco



From andi.shyti at kernel.org  Sun Dec  3 11:06:20 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Sun, 3 Dec 2023 20:06:20 +0100
Subject: [PATCH v3 3/8] i2c: rk3x: Adjust mask/value offset for i2c2 on
 rv1126
In-Reply-To: <20231203124004.2676174-4-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
 <20231203124004.2676174-4-tim@feathertop.org>
Message-ID: <20231203190620.26of3xrcoosnpicb@zenone.zhora.eu>

Hi Tim,

On Sun, Dec 03, 2023 at 11:39:59PM +1100, Tim Lunn wrote:
> Rockchip RV1126 is using old style i2c controller, the i2c2
> bus uses a non-sequential offset in the grf register for the
> mask/value bits for this bus.
> 
> This patch fixes i2c2 bus on rv1126 SoCs.
> 
> Signed-off-by: Tim Lunn <tim at feathertop.org>
> Acked-by: Heiko Stuebner <heiko at sntech.de>

Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Thanks,
Andi


From yury.norov at gmail.com  Sun Dec  3 11:32:40 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Sun,  3 Dec 2023 11:32:40 -0800
Subject: [PATCH v2 08/35] perf/arm: optimize opencoded atomic find_bit() API
In-Reply-To: <20231203193307.542794-1-yury.norov@gmail.com>
References: <20231203192422.539300-1-yury.norov@gmail.com>
 <20231203193307.542794-1-yury.norov@gmail.com>
Message-ID: <20231203193307.542794-7-yury.norov@gmail.com>

Switch subsystem to use atomic find_bit() or atomic iterators as
appropriate.

CC: Will Deacon <will at kernel.org>
Signed-off-by: Yury Norov <yury.norov at gmail.com>
---
 drivers/perf/arm-cci.c        | 24 ++++++------------------
 drivers/perf/arm-ccn.c        | 10 ++--------
 drivers/perf/arm_dmc620_pmu.c |  9 ++-------
 drivers/perf/arm_pmuv3.c      |  8 ++------
 4 files changed, 12 insertions(+), 39 deletions(-)

diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
index 61de861eaf91..cb15b4cee5f7 100644
--- a/drivers/perf/arm-cci.c
+++ b/drivers/perf/arm-cci.c
@@ -320,12 +320,9 @@ static int cci400_get_event_idx(struct cci_pmu *cci_pmu,
 		return CCI400_PMU_CYCLE_CNTR_IDX;
 	}
 
-	for (idx = CCI400_PMU_CNTR0_IDX; idx <= CCI_PMU_CNTR_LAST(cci_pmu); ++idx)
-		if (!test_and_set_bit(idx, hw->used_mask))
-			return idx;
-
-	/* No counters available */
-	return -EAGAIN;
+	idx = find_and_set_next_bit(hw->used_mask, CCI_PMU_CNTR_LAST(cci_pmu) + 1,
+							CCI400_PMU_CNTR0_IDX);
+	return idx < CCI_PMU_CNTR_LAST(cci_pmu) + 1 ? idx : -EAGAIN;
 }
 
 static int cci400_validate_hw_event(struct cci_pmu *cci_pmu, unsigned long hw_event)
@@ -802,13 +799,8 @@ static int pmu_get_event_idx(struct cci_pmu_hw_events *hw, struct perf_event *ev
 	if (cci_pmu->model->get_event_idx)
 		return cci_pmu->model->get_event_idx(cci_pmu, hw, cci_event);
 
-	/* Generic code to find an unused idx from the mask */
-	for (idx = 0; idx <= CCI_PMU_CNTR_LAST(cci_pmu); idx++)
-		if (!test_and_set_bit(idx, hw->used_mask))
-			return idx;
-
-	/* No counters available */
-	return -EAGAIN;
+	idx = find_and_set_bit(hw->used_mask, CCI_PMU_CNTR_LAST(cci_pmu) + 1);
+	return idx < CCI_PMU_CNTR_LAST(cci_pmu) + 1 ? idx : -EAGAIN;
 }
 
 static int pmu_map_event(struct perf_event *event)
@@ -861,12 +853,8 @@ static void pmu_free_irq(struct cci_pmu *cci_pmu)
 {
 	int i;
 
-	for (i = 0; i < cci_pmu->nr_irqs; i++) {
-		if (!test_and_clear_bit(i, &cci_pmu->active_irqs))
-			continue;
-
+	for_each_test_and_clear_bit(i, &cci_pmu->active_irqs, cci_pmu->nr_irqs)
 		free_irq(cci_pmu->irqs[i], cci_pmu);
-	}
 }
 
 static u32 pmu_read_counter(struct perf_event *event)
diff --git a/drivers/perf/arm-ccn.c b/drivers/perf/arm-ccn.c
index 728d13d8e98a..d657701b1f23 100644
--- a/drivers/perf/arm-ccn.c
+++ b/drivers/perf/arm-ccn.c
@@ -589,15 +589,9 @@ static const struct attribute_group *arm_ccn_pmu_attr_groups[] = {
 
 static int arm_ccn_pmu_alloc_bit(unsigned long *bitmap, unsigned long size)
 {
-	int bit;
-
-	do {
-		bit = find_first_zero_bit(bitmap, size);
-		if (bit >= size)
-			return -EAGAIN;
-	} while (test_and_set_bit(bit, bitmap));
+	int bit = find_and_set_bit(bitmap, size);
 
-	return bit;
+	return bit < size ? bit : -EAGAIN;
 }
 
 /* All RN-I and RN-D nodes have identical PMUs */
diff --git a/drivers/perf/arm_dmc620_pmu.c b/drivers/perf/arm_dmc620_pmu.c
index 30cea6859574..e41c84dabc3e 100644
--- a/drivers/perf/arm_dmc620_pmu.c
+++ b/drivers/perf/arm_dmc620_pmu.c
@@ -303,13 +303,8 @@ static int dmc620_get_event_idx(struct perf_event *event)
 		end_idx = DMC620_PMU_MAX_COUNTERS;
 	}
 
-	for (idx = start_idx; idx < end_idx; ++idx) {
-		if (!test_and_set_bit(idx, dmc620_pmu->used_mask))
-			return idx;
-	}
-
-	/* The counters are all in use. */
-	return -EAGAIN;
+	idx = find_and_set_next_bit(dmc620_pmu->used_mask, end_idx, start_idx);
+	return idx < end_idx ? idx : -EAGAIN;
 }
 
 static inline
diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 6ca7be05229c..f046ad9e71f1 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -825,13 +825,9 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
 static int armv8pmu_get_single_idx(struct pmu_hw_events *cpuc,
 				    struct arm_pmu *cpu_pmu)
 {
-	int idx;
+	int idx = find_and_set_next_bit(cpuc->used_mask, cpu_pmu->num_events, ARMV8_IDX_COUNTER0);
 
-	for (idx = ARMV8_IDX_COUNTER0; idx < cpu_pmu->num_events; idx++) {
-		if (!test_and_set_bit(idx, cpuc->used_mask))
-			return idx;
-	}
-	return -EAGAIN;
+	return idx < cpu_pmu->num_events ? idx : -EAGAIN;
 }
 
 static int armv8pmu_get_chain_idx(struct pmu_hw_events *cpuc,
-- 
2.40.1



From yury.norov at gmail.com  Sun Dec  3 11:32:41 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Sun,  3 Dec 2023 11:32:41 -0800
Subject: [PATCH v2 09/35] drivers/perf: optimize ali_drw_get_counter_idx() by using find_bit()
In-Reply-To: <20231203193307.542794-1-yury.norov@gmail.com>
References: <20231203192422.539300-1-yury.norov@gmail.com>
 <20231203193307.542794-1-yury.norov@gmail.com>
Message-ID: <20231203193307.542794-8-yury.norov@gmail.com>

The function searches used_mask for a set bit in a for-loop bit by bit.
We can do it faster by using atomic find_and_set_bit().

Signed-off-by: Yury Norov <yury.norov at gmail.com>
Acked-by: Will Deacon <will at kernel.org>
---
 drivers/perf/alibaba_uncore_drw_pmu.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_uncore_drw_pmu.c
index 19d459a36be5..2a3b7701d568 100644
--- a/drivers/perf/alibaba_uncore_drw_pmu.c
+++ b/drivers/perf/alibaba_uncore_drw_pmu.c
@@ -274,15 +274,9 @@ static const struct attribute_group *ali_drw_pmu_attr_groups[] = {
 static int ali_drw_get_counter_idx(struct perf_event *event)
 {
 	struct ali_drw_pmu *drw_pmu = to_ali_drw_pmu(event->pmu);
-	int idx;
+	int idx = find_and_set_bit(drw_pmu->used_mask, ALI_DRW_PMU_COMMON_MAX_COUNTERS);
 
-	for (idx = 0; idx < ALI_DRW_PMU_COMMON_MAX_COUNTERS; ++idx) {
-		if (!test_and_set_bit(idx, drw_pmu->used_mask))
-			return idx;
-	}
-
-	/* The counters are all in use. */
-	return -EBUSY;
+	return idx < ALI_DRW_PMU_COMMON_MAX_COUNTERS ? idx : -EBUSY;
 }
 
 static u64 ali_drw_pmu_read_counter(struct perf_event *event)
-- 
2.40.1



From yury.norov at gmail.com  Sun Dec  3 11:32:51 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Sun,  3 Dec 2023 11:32:51 -0800
Subject: [PATCH v2 19/35] iommu: use atomic find_bit() API where appropriate
In-Reply-To: <20231203193307.542794-1-yury.norov@gmail.com>
References: <20231203192422.539300-1-yury.norov@gmail.com>
 <20231203193307.542794-1-yury.norov@gmail.com>
Message-ID: <20231203193307.542794-18-yury.norov@gmail.com>

Switch opencoded find_and_set_next_bit() in __arm_smmu_alloc_bitmap()
and msm_iommu_alloc_ctx() to use dedicated API, and make them nice
one-liner wrappers.

While here, refactor msm_iommu_attach_dev() and msm_iommu_alloc_ctx()
so that error codes don't mismatch.

Signed-off-by: Yury Norov <yury.norov at gmail.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu.h | 10 ++--------
 drivers/iommu/msm_iommu.c             | 18 ++++--------------
 2 files changed, 6 insertions(+), 22 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 703fd5817ec1..004a4704ebf1 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -453,15 +453,9 @@ struct arm_smmu_impl {
 
 static inline int __arm_smmu_alloc_bitmap(unsigned long *map, int start, int end)
 {
-	int idx;
+	int idx = find_and_set_next_bit(map, end, start);
 
-	do {
-		idx = find_next_zero_bit(map, end, start);
-		if (idx == end)
-			return -ENOSPC;
-	} while (test_and_set_bit(idx, map));
-
-	return idx;
+	return idx < end ? idx : -ENOSPC;
 }
 
 static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index f86af9815d6f..67124f4228b1 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -185,17 +185,9 @@ static const struct iommu_flush_ops msm_iommu_flush_ops = {
 	.tlb_add_page = __flush_iotlb_page,
 };
 
-static int msm_iommu_alloc_ctx(unsigned long *map, int start, int end)
+static int msm_iommu_alloc_ctx(struct msm_iommu_dev *iommu)
 {
-	int idx;
-
-	do {
-		idx = find_next_zero_bit(map, end, start);
-		if (idx == end)
-			return -ENOSPC;
-	} while (test_and_set_bit(idx, map));
-
-	return idx;
+	return find_and_set_bit(iommu->context_map, iommu->ncb);
 }
 
 static void msm_iommu_free_ctx(unsigned long *map, int idx)
@@ -418,10 +410,8 @@ static int msm_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
 					ret = -EEXIST;
 					goto fail;
 				}
-				master->num =
-					msm_iommu_alloc_ctx(iommu->context_map,
-							    0, iommu->ncb);
-				if (IS_ERR_VALUE(master->num)) {
+				master->num = msm_iommu_alloc_ctx(iommu);
+				if (master->num >= iommu->ncb) {
 					ret = -ENODEV;
 					goto fail;
 				}
-- 
2.40.1



From heiko at sntech.de  Sun Dec  3 11:48:43 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sun, 03 Dec 2023 20:48:43 +0100
Subject: [PATCH v3 3/8] i2c: rk3x: Adjust mask/value offset for i2c2 on rv1126
In-Reply-To: <20231203190620.26of3xrcoosnpicb@zenone.zhora.eu>
References: <20231203124004.2676174-1-tim@feathertop.org>
 <20231203124004.2676174-4-tim@feathertop.org>
 <20231203190620.26of3xrcoosnpicb@zenone.zhora.eu>
Message-ID: <4413905.22IY78Rhhi@diego>

Hi Andi,

Am Sonntag, 3. Dezember 2023, 20:06:20 CET schrieb Andi Shyti:
> Hi Tim,
> 
> On Sun, Dec 03, 2023 at 11:39:59PM +1100, Tim Lunn wrote:
> > Rockchip RV1126 is using old style i2c controller, the i2c2
> > bus uses a non-sequential offset in the grf register for the
> > mask/value bits for this bus.
> > 
> > This patch fixes i2c2 bus on rv1126 SoCs.
> > 
> > Signed-off-by: Tim Lunn <tim at feathertop.org>
> > Acked-by: Heiko Stuebner <heiko at sntech.de>
> 
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

you're listed as the maintainer for the i2c busses,
are you going to pick this one patch yourself?
Or do you expect a different handling?

I.e. it doesn't really tie into the dts patches and everything will come
together nicely in linux-next and during the next merge-window.

Thanks
Heiko




From dsimic at manjaro.org  Sun Dec  3 12:12:17 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Sun, 03 Dec 2023 21:12:17 +0100
Subject: [PATCH v3] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <83b413441a953e8f2bc56adf09511a80@manjaro.org>
References: <20231125184422.12315-1-krzysztof.kozlowski@linaro.org>
 <63ec18b2758a9e385f446fb00b60ee69@manjaro.org>
 <0bcc0679-b883-4435-8843-cc830122c0e1@linaro.org>
 <83b413441a953e8f2bc56adf09511a80@manjaro.org>
Message-ID: <7021717e2e747b9c119b7c5091b60bdf@manjaro.org>

Just a brief reminder about my suggestions below, which seemingly didn't 
find their way into the v4.  At least the first one, which improves the 
opening sentence, is worth including, IMHO.


On 2023-11-29 12:37, Dragan Simic wrote:
> On 2023-11-29 11:43, Krzysztof Kozlowski wrote:
>> On 28/11/2023 21:00, Dragan Simic wrote:
>>> 
>>> I went through the language of the entire patch, after the notice 
>>> that
>>> the v4 would no longer accept language improvements.  My wording- and
>>> grammar-related suggestions are available inline below.
>> 
>> Thanks. I want to finish this at some point and it might not happen if
>> grammar fixes will be coming every patch revision. Then after we 
>> finish
>> review, new feedback will appear about using British or American
>> spelling (which reminds me old quote/email about which variant of
>> English is most popular in Linux kernel: the incorrect one).
> 
> Ah, that's a good one. :)  Basically, both English variants should be
> fine, but a single document should obviously use only one variant.
> 
>>>> +=====================================
>>>> +Devicetree Sources (DTS) Coding Style
>>>> +=====================================
>>>> +
>>>> +When writing Devicetree Sources (DTS) please observe below 
>>>> guidelines.
>>>>  They
>>> 
>>> The sentence above should be replaced with: "The following guidelines
>>> are to be followed when writing Devicetree Source (DTS) files."
>> 
>> Are you sure? It's passive and I was taught it is discouraged for
>> writing. See for example:
>> https://www.hamilton.edu/academics/centers/writing/seven-sins-of-writing/1
> 
> Hmm, you're right, passive voice is usually not the best choice.
> Here's my take two for the suggested replacement sentence, which is
> actually a simplified version:
> 
> "This document contains the guidelines for writing Devicetree Source
> (DTS) files."
> 
>>>> +should be considered complementary to any rules expressed already 
>>>> in
>>>> Devicetree
>>>> +Specification and dtc compiler (including W=1 and W=2 builds).
>>> 
>>> A definite article ("the") should be added before "Devicetree
>> 
>> ack
>> 
>>> Specification" and "dtc".  Also, "Specification" in "Devicetree
>>> Specification" should be capitalized.
>> 
>> It was.
> 
> Oh, sorry, I see now.  IIRC, it wasn't capitalized in some places, so
> I made a mistake here.
> 
>>>> +
>>>> +Individual architectures and sub-architectures can add additional
>>>> rules, making
>>>> +the style stricter.
>>> 
>>> "Sub-architectures" should be replaced with "subarchitectures".  "Can
>> 
>> A hint, you can write such review feedback as:
>> s/sub-architectures/subarchitectures/
> 
> Sure, but I specifically wanted to be less terse, as a way to be 
> respectful.
> 
>> BTW, my language spelling points "subarchitectures" as mistake, but
>> sure, ack.
> 
> Using hyphens or not is almost always debatable, but modern English in
> general leans toward not using them.
> 
>>>> +3. Unit addresses shall use lowercase hex, without leading zeros
>>>> (padding).
>>> 
>>> "Lowercase hex" should be replaced with "lowercase hexadecimal 
>>> digits".
>>> 
>>>> +
>>>> +4. Hex values in properties, e.g. "reg", shall use lowercase hex.  
>>>> The
>>>> address
>>>> +   part can be padded with leading zeros.
>>> 
>>> "Hex values" should be replaced with "Hexadecimal values".  
>>> "Lowercase
>>> hex" should be replaced with "lowercase hexadecimal digits".
>> 
>> ack, but that's quite picky. We are (software) engineers so we are
>> supposed to know the slang.
> 
> Sure, but this document is of a bit formal nature, so using slightly
> more formal language can only be helpful.
> 
>>>> +2. Nodes without unit addresses shall be ordered alpha-numerically 
>>>> by
>>>> the node
>>>> +   name.  For a few types of nodes, they can be ordered by the main
>>>> property
>>>> +   (e.g. pin configuration states ordered by value of "pins"
>>>> property).
>>> 
>>> "Alpha-numerically" should be replaced with "alphabetically".
>> 
>> Are you sure? Does alphabetical order include numbers?
> 
> That's a good question, which also crossed my mind while writing the
> suggestions down.  A more correct word would be "lexicographically",
> with something like ", with the already defined valid characters
> making the symbol set and the ACSII character set defining the
> ordering, " serving as an additional explanation.
> 
> This would be a rather formal, but also very precise definition of the
> applied ordering.
> 
>>>> +3. When extending nodes in the board DTS via &label, the entries 
>>>> shall
>>>> be
>>>> +   ordered either alpha-numerically or by keeping the order from 
>>>> DTSI
>>>> (choice
>>>> +   depending on sub-architecture).
>>> 
>>> "Alpha-numerically" should be replaced with "alphabetically".
>> 
>> Similar concern
> 
> I agree.  We could use "lexicographically" instead, with the precise
> definition already established earlier in the document.
> 
>>>> +board DTS, not in the SoC or SoM DTSI.  A partial exception is a
>>>> common
>>>> +external reference SoC-input clock, which could be coded as a
>>>> fixed-clock in
>>> 
>>> "SoC-input" should be replaced with "SoC input".
>> 
>> ack, thanks!
> 
> Thank you once again for working on this document!


From dsimic at manjaro.org  Sun Dec  3 12:25:54 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Sun, 03 Dec 2023 21:25:54 +0100
Subject: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
References: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
Message-ID: <2223b302fc43959a61578aae9cc3a15a@manjaro.org>

> +Order of Properties in Device Node
> +----------------------------------
> +
> +The following order of properties in device nodes is preferred:
> +
> +1. compatible
> +2. reg
> +3. ranges
> +4. Standard/common properties (defined by common bindings, e.g. 
> without
> +   vendor-prefixes)
> +5. Vendor-specific properties
> +6. status (if applicable)
> +7. Child nodes, where each node is preceded with a blank line

Another small suggestion...  It would be good to put the property names 
found in the list items, such as "compatible" and "status", into 
quotation marks, to make it obvious what they are.  That way, the list 
would also be more consistent with the property names mentioned in the 
sentence right below.

> +
> +The "status" property is by default "okay", thus it can be omitted.
> +
> +The above-described ordering follows this approach:
> +
> +1. Most important properties start the node: compatible then bus 
> addressing to
> +   match unit address.
> +2. Each node will have common properties in similar place.
> +3. Status is the last information to annotate that device node is or 
> is not
> +   finished (board resources are needed).


From peter.griffin at linaro.org  Sun Dec  3 12:59:28 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sun, 3 Dec 2023 20:59:28 +0000
Subject: [PATCH v5 02/20] dt-bindings: clock: Add Google gs101 clock
 management unit bindings
In-Reply-To: <CAPLW+4m=A5-+izcOiYghpBOSmQORjGfjX+fgc2jeQ1jezHosMw@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-3-peter.griffin@linaro.org> <CAPLW+4m=A5-+izcOiYghpBOSmQORjGfjX+fgc2jeQ1jezHosMw@mail.gmail.com>
Message-ID: <CADrjBPqGBEDC9PXEJKzUBY407fuFqD4YndJqJZsJ=CjfkyE7Uw@mail.gmail.com>

Hi Sam,

Thanks for the review.

On Fri, 1 Dec 2023 at 20:11, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:10?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > Provide dt-schema documentation for Google gs101 SoC clock controller.
> > Currently this adds support for cmu_top, cmu_misc and cmu_apm.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
>
> Except for my nitpicks below (very minor, can be ignored):
>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

Thanks! If a v6 is required I will fixup these nitpicks as well.
>
> >  .../bindings/clock/google,gs101-clock.yaml    | 110 +++++
> >  include/dt-bindings/clock/google,gs101.h      | 392 ++++++++++++++++++
> >  2 files changed, 502 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >  create mode 100644 include/dt-bindings/clock/google,gs101.h
> >
> > diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> > new file mode 100644
> > index 000000000000..4612886fcc15
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> > @@ -0,0 +1,110 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/google,gs101-clock.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Google GS101 SoC clock controller
> > +
> > +maintainers:
> > +  - Peter Griffin <peter.griffin at linaro.org>
> > +
> > +description: |
> > +  Google GS101 clock controller is comprised of several CMU units, generating
> > +  clocks for different domains. Those CMU units are modeled as separate device
> > +  tree nodes, and might depend on each other. The root clock in that clock tree
> > +  is OSCCLK (24.576 MHz). That external clock must be defined as a fixed-rate
> > +  clock in dts.
> > +
> > +  CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
> > +  dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP.
> > +
> > +  Each clock is assigned an identifier and client nodes can use this identifier
> > +  to specify the clock which they consume. All clocks available for usage
> > +  in clock consumer nodes are defined as preprocessor macros in
> > +  'dt-bindings/clock/gs101.h' header.
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - google,gs101-cmu-top
> > +      - google,gs101-cmu-apm
> > +      - google,gs101-cmu-misc
> > +
> > +  clocks:
> > +    minItems: 1
> > +    maxItems: 2
> > +
> > +  clock-names:
> > +    minItems: 1
> > +    maxItems: 2
> > +
> > +  "#clock-cells":
> > +    const: 1
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +required:
> > +  - compatible
> > +  - "#clock-cells"
> > +  - clocks
> > +  - clock-names
> > +  - reg
> > +
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - google,gs101-cmu-top
> > +              - google,gs101-cmu-apm
> > +    then:
> > +      properties:
> > +        clocks:
> > +          items:
> > +            - description: External reference clock (24.576 MHz)
> > +
> > +        clock-names:
> > +          items:
> > +            - const: oscclk
> > +
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: google,gs101-cmu-misc
> > +
> > +    then:
> > +      properties:
> > +        clocks:
> > +          items:
> > +            - description: External reference clock (24.576 MHz)
> > +            - description: Misc bus clock (from CMU_TOP)
> > +
> > +        clock-names:
> > +          items:
> > +            - const: oscclk
> > +            - const: dout_cmu_misc_bus
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  # Clock controller node for CMU_TOP
> > +  - |
> > +    #include <dt-bindings/clock/google,gs101.h>
>
> Not really needed for the particular example below, but I guess it's
> ok to have it here for the reference.
>
> > +    soc {
> > +        #address-cells = <2>;
> > +        #size-cells = <1>;
> > +
> > +        cmu_top: clock-controller at 1e080000 {
> > +            compatible = "google,gs101-cmu-top";
> > +            reg = <0x0 0x1e080000 0x8000>;
>
> Having 0x0 here doesn't match how it's done in gs101.dtsi in this
> series. If you remove it, then above soc node and its properties can
> be removed too.

Good spot! Seems I forgot to update the example when switching to
address-cells = <1>

>
> > +            #clock-cells = <1>;
> > +            clocks = <&ext_24_5m>;
> > +            clock-names = "oscclk";
> > +        };
> > +    };
> > +
> > +...
> > diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
> > new file mode 100644
> > index 000000000000..9f280f74578a
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/google,gs101.h
> > @@ -0,0 +1,392 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > +/*
> > + * Copyright (C) 2023 Linaro Ltd.
> > + * Author: Peter Griffin <peter.griffin at linaro.org>
> > + *
> > + * Device Tree binding constants for Google gs101 clock controller.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
> > +#define _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
> > +
> > +/* CMU_TOP PLL */
> > +#define CLK_FOUT_SHARED0_PLL           1
> > +#define CLK_FOUT_SHARED1_PLL           2
> > +#define CLK_FOUT_SHARED2_PLL           3
> > +#define CLK_FOUT_SHARED3_PLL           4
> > +#define CLK_FOUT_SPARE_PLL             5
> > +
> > +/* CMU_TOP MUX */
> > +#define CLK_MOUT_SHARED0_PLL           6
> > +#define CLK_MOUT_SHARED1_PLL           7
> > +#define CLK_MOUT_SHARED2_PLL           8
> > +#define CLK_MOUT_SHARED3_PLL           9
> > +#define CLK_MOUT_SPARE_PLL             10
> > +#define CLK_MOUT_BO_BUS                        11
> > +#define CLK_MOUT_BUS0_BUS              12
> > +#define CLK_MOUT_BUS1_BUS              13
> > +#define CLK_MOUT_BUS2_BUS              14
> > +#define CLK_MOUT_CIS_CLK0              15
> > +#define CLK_MOUT_CIS_CLK1              16
> > +#define CLK_MOUT_CIS_CLK2              17
> > +#define CLK_MOUT_CIS_CLK3              18
> > +#define CLK_MOUT_CIS_CLK4              19
> > +#define CLK_MOUT_CIS_CLK5              20
> > +#define CLK_MOUT_CIS_CLK6              21
> > +#define CLK_MOUT_CIS_CLK7              22
> > +#define CLK_MOUT_CMU_BOOST             23
> > +#define CLK_MOUT_BOOST_OPTION1         24
> > +#define CLK_MOUT_CORE_BUS              25
> > +#define CLK_MOUT_CPUCL0_DBG            26
> > +#define CLK_MOUT_CPUCL0_SWITCH         27
> > +#define CLK_MOUT_CPUCL1_SWITCH         28
> > +#define CLK_MOUT_CPUCL2_SWITCH         29
> > +#define CLK_MOUT_CSIS_BUS              30
> > +#define CLK_MOUT_DISP_BUS              31
> > +#define CLK_MOUT_DNS_BUS               32
> > +#define CLK_MOUT_DPU_BUS               33
> > +#define CLK_MOUT_EH_BUS                        34
> > +#define CLK_MOUT_G2D_G2D               35
> > +#define CLK_MOUT_G2D_MSCL              36
> > +#define CLK_MOUT_G3AA_G3AA             37
> > +#define CLK_MOUT_G3D_BUSD              38
> > +#define CLK_MOUT_G3D_GLB               39
> > +#define CLK_MOUT_G3D_SWITCH            40
> > +#define CLK_MOUT_GDC_GDC0              41
> > +#define CLK_MOUT_GDC_GDC1              42
> > +#define CLK_MOUT_GDC_SCSC              43
> > +#define CLK_MOUT_CMU_HPM               44
> > +#define CLK_MOUT_HSI0_BUS              45
> > +#define CLK_MOUT_HSI0_DPGTC            46
> > +#define CLK_MOUT_HSI0_USB31DRD         47
> > +#define CLK_MOUT_HSI0_USBDPDGB         48
> > +#define CLK_MOUT_HSI1_BUS              49
> > +#define CLK_MOUT_HSI1_PCIE             50
> > +#define CLK_MOUT_HSI2_BUS              51
> > +#define CLK_MOUT_HSI2_MMC_CARD         52
> > +#define CLK_MOUT_HSI2_PCIE             53
> > +#define CLK_MOUT_HSI2_UFS_EMBD         54
> > +#define CLK_MOUT_IPP_BUS               55
> > +#define CLK_MOUT_ITP_BUS               56
> > +#define CLK_MOUT_MCSC_ITSC             57
> > +#define CLK_MOUT_MCSC_MCSC             58
> > +#define CLK_MOUT_MFC_MFC               59
> > +#define CLK_MOUT_MIF_BUSP              60
> > +#define CLK_MOUT_MIF_SWITCH            61
> > +#define CLK_MOUT_MISC_BUS              62
> > +#define CLK_MOUT_MISC_SSS              63
> > +#define CLK_MOUT_PDP_BUS               64
> > +#define CLK_MOUT_PDP_VRA               65
> > +#define CLK_MOUT_PERIC0_BUS            66
> > +#define CLK_MOUT_PERIC0_IP             67
> > +#define CLK_MOUT_PERIC1_BUS            68
> > +#define CLK_MOUT_PERIC1_IP             69
> > +#define CLK_MOUT_TNR_BUS               70
> > +#define CLK_MOUT_TOP_BOOST_OPTION1     71
> > +#define CLK_MOUT_TOP_CMUREF            72
> > +#define CLK_MOUT_TPU_BUS               73
> > +#define CLK_MOUT_TPU_TPU               74
> > +#define CLK_MOUT_TPU_TPUCTL            75
> > +#define CLK_MOUT_TPU_UART              76
> > +#define CLK_MOUT_CMU_CMUREF            77
> > +
> > +/* CMU_TOP Dividers */
> > +#define CLK_DOUT_BO_BUS                        78
> > +#define CLK_DOUT_BUS0_BUS              79
> > +#define CLK_DOUT_BUS1_BUS              80
> > +#define CLK_DOUT_BUS2_BUS              81
> > +#define CLK_DOUT_CIS_CLK0              82
> > +#define CLK_DOUT_CIS_CLK1              83
> > +#define CLK_DOUT_CIS_CLK2              84
> > +#define CLK_DOUT_CIS_CLK3              85
> > +#define CLK_DOUT_CIS_CLK4              86
> > +#define CLK_DOUT_CIS_CLK5              87
> > +#define CLK_DOUT_CIS_CLK6              88
> > +#define CLK_DOUT_CIS_CLK7              89
> > +#define CLK_DOUT_CORE_BUS              90
> > +#define CLK_DOUT_CPUCL0_DBG            91
> > +#define CLK_DOUT_CPUCL0_SWITCH         92
> > +#define CLK_DOUT_CPUCL1_SWITCH         93
> > +#define CLK_DOUT_CPUCL2_SWITCH         94
> > +#define CLK_DOUT_CSIS_BUS              95
> > +#define CLK_DOUT_DISP_BUS              96
> > +#define CLK_DOUT_DNS_BUS               97
> > +#define CLK_DOUT_DPU_BUS               98
> > +#define CLK_DOUT_EH_BUS                        99
> > +#define CLK_DOUT_G2D_G2D               100
> > +#define CLK_DOUT_G2D_MSCL              101
> > +#define CLK_DOUT_G3AA_G3AA             102
> > +#define CLK_DOUT_G3D_BUSD              103
> > +#define CLK_DOUT_G3D_GLB               104
> > +#define CLK_DOUT_G3D_SWITCH            105
> > +#define CLK_DOUT_GDC_GDC0              106
> > +#define CLK_DOUT_GDC_GDC1              107
> > +#define CLK_DOUT_GDC_SCSC              108
> > +#define CLK_DOUT_CMU_HPM               109
> > +#define CLK_DOUT_HSI0_BUS              110
> > +#define CLK_DOUT_HSI0_DPGTC            111
> > +#define CLK_DOUT_HSI0_USB31DRD         112
> > +#define CLK_DOUT_HSI0_USBDPDGB         113
> > +#define CLK_DOUT_HSI1_BUS              114
> > +#define CLK_DOUT_HSI1_PCIE             115
> > +#define CLK_DOUT_HSI2_BUS              116
> > +#define CLK_DOUT_HSI2_MMC_CARD         117
> > +#define CLK_DOUT_HSI2_PCIE             118
> > +#define CLK_DOUT_HSI2_UFS_EMBD         119
> > +#define CLK_DOUT_IPP_BUS               107
> > +#define CLK_DOUT_ITP_BUS               108
> > +#define CLK_DOUT_MCSC_ITSC             109
> > +#define CLK_DOUT_MCSC_MCSC             110
> > +#define CLK_DOUT_MFC_MFC               111
> > +#define CLK_DOUT_MIF_BUSP              112
> > +#define CLK_DOUT_MISC_BUS              113
> > +#define CLK_DOUT_MISC_SSS              114
> > +#define CLK_DOUT_PDP_BUS               115
> > +#define CLK_DOUT_PDP_VRA               116
> > +#define CLK_DOUT_PERIC0_BUS            117
> > +#define CLK_DOUT_PERIC0_IP             118
> > +#define CLK_DOUT_PERIC1_BUS            119
> > +#define CLK_DOUT_PERIC1_IP             120
> > +#define CLK_DOUT_TNR_BUS               121
> > +#define CLK_DOUT_TPU_BUS               122
> > +#define CLK_DOUT_TPU_TPU               123
> > +#define CLK_DOUT_TPU_TPUCTL            124
> > +#define CLK_DOUT_TPU_UART              125
> > +#define CLK_DOUT_CMU_BOOST             126
> > +#define CLK_DOUT_CMU_CMUREF            127
> > +#define CLK_DOUT_SHARED0_DIV2          128
> > +#define CLK_DOUT_SHARED0_DIV3          129
> > +#define CLK_DOUT_SHARED0_DIV4          130
> > +#define CLK_DOUT_SHARED0_DIV5          131
> > +#define CLK_DOUT_SHARED1_DIV2          132
> > +#define CLK_DOUT_SHARED1_DIV3          133
> > +#define CLK_DOUT_SHARED1_DIV4          134
> > +#define CLK_DOUT_SHARED2_DIV2          135
> > +#define CLK_DOUT_SHARED3_DIV2          136
> > +
> > +/* CMU_TOP Gates */
> > +#define CLK_GOUT_BUS0_BOOST            137
> > +#define CLK_GOUT_BUS1_BOOST            138
> > +#define CLK_GOUT_BUS2_BOOST            139
> > +#define CLK_GOUT_CORE_BOOST            140
> > +#define CLK_GOUT_CPUCL0_BOOST          141
> > +#define CLK_GOUT_CPUCL1_BOOST          142
> > +#define CLK_GOUT_CPUCL2_BOOST          143
> > +#define CLK_GOUT_MIF_BOOST             144
> > +#define CLK_GOUT_MIF_SWITCH            145
> > +#define CLK_GOUT_BO_BUS                        146
> > +#define CLK_GOUT_BUS0_BUS              147
> > +#define CLK_GOUT_BUS1_BUS              148
> > +#define CLK_GOUT_BUS2_BUS              149
> > +#define CLK_GOUT_CIS_CLK0              150
> > +#define CLK_GOUT_CIS_CLK1              151
> > +#define CLK_GOUT_CIS_CLK2              152
> > +#define CLK_GOUT_CIS_CLK3              153
> > +#define CLK_GOUT_CIS_CLK4              154
> > +#define CLK_GOUT_CIS_CLK5              155
> > +#define CLK_GOUT_CIS_CLK6              156
> > +#define CLK_GOUT_CIS_CLK7              157
> > +#define CLK_GOUT_CMU_BOOST             158
> > +#define CLK_GOUT_CORE_BUS              159
> > +#define CLK_GOUT_CPUCL0_DBG            160
> > +#define CLK_GOUT_CPUCL0_SWITCH         161
> > +#define CLK_GOUT_CPUCL1_SWITCH         162
> > +#define CLK_GOUT_CPUCL2_SWITCH         163
> > +#define CLK_GOUT_CSIS_BUS              164
> > +#define CLK_GOUT_DISP_BUS              165
> > +#define CLK_GOUT_DNS_BUS               166
> > +#define CLK_GOUT_DPU_BUS               167
> > +#define CLK_GOUT_EH_BUS                        168
> > +#define CLK_GOUT_G2D_G2D               169
> > +#define CLK_GOUT_G2D_MSCL              170
> > +#define CLK_GOUT_G3AA_G3AA             171
> > +#define CLK_GOUT_G3D_BUSD              172
> > +#define CLK_GOUT_G3D_GLB               173
> > +#define CLK_GOUT_G3D_SWITCH            174
> > +#define CLK_GOUT_GDC_GDC0              175
> > +#define CLK_GOUT_GDC_GDC1              176
> > +#define CLK_GOUT_GDC_SCSC              177
> > +#define CLK_GOUT_CMU_HPM               178
> > +#define CLK_GOUT_HSI0_BUS              179
> > +#define CLK_GOUT_HSI0_DPGTC            180
> > +#define CLK_GOUT_HSI0_USB31DRD         181
> > +#define CLK_GOUT_HSI0_USBDPDGB         182
> > +#define CLK_GOUT_HSI1_BUS              183
> > +#define CLK_GOUT_HSI1_PCIE             184
> > +#define CLK_GOUT_HSI2_BUS              185
> > +#define CLK_GOUT_HSI2_MMC_CARD         186
> > +#define CLK_GOUT_HSI2_PCIE             187
> > +#define CLK_GOUT_HSI2_UFS_EMBD         188
> > +#define CLK_GOUT_IPP_BUS               189
> > +#define CLK_GOUT_ITP_BUS               190
> > +#define CLK_GOUT_MCSC_ITSC             191
> > +#define CLK_GOUT_MCSC_MCSC             192
> > +#define CLK_GOUT_MFC_MFC               193
> > +#define CLK_GOUT_MIF_BUSP              194
> > +#define CLK_GOUT_MISC_BUS              195
> > +#define CLK_GOUT_MISC_SSS              196
> > +#define CLK_GOUT_PDP_BUS               197
> > +#define CLK_GOUT_PDP_VRA               298
> > +#define CLK_GOUT_G3AA                  299
> > +#define CLK_GOUT_PERIC0_BUS            200
> > +#define CLK_GOUT_PERIC0_IP             201
> > +#define CLK_GOUT_PERIC1_BUS            202
> > +#define CLK_GOUT_PERIC1_IP             203
> > +#define CLK_GOUT_TNR_BUS               204
> > +#define CLK_GOUT_TOP_CMUREF            205
> > +#define CLK_GOUT_TPU_BUS               206
> > +#define CLK_GOUT_TPU_TPU               207
> > +#define CLK_GOUT_TPU_TPUCTL            208
> > +#define CLK_GOUT_TPU_UART              209
> > +
> > +/* CMU_APM */
> > +#define CLK_MOUT_APM_FUNC                                              1
> > +#define CLK_MOUT_APM_FUNCSRC                                           2
> > +#define CLK_DOUT_APM_BOOST                                             3
> > +#define CLK_DOUT_APM_USI0_UART                                         4
> > +#define CLK_DOUT_APM_USI0_USI                                          5
> > +#define CLK_DOUT_APM_USI1_UART                                         6
> > +#define CLK_GOUT_APM_APM_CMU_APM_IPCLKPORT_PCLK                                7
> > +#define CLK_GOUT_BUS0_BOOST_OPTION1                                    8
> > +#define CLK_GOUT_CMU_BOOST_OPTION1                                     9
> > +#define CLK_GOUT_CORE_BOOST_OPTION1                                    10
> > +#define CLK_GOUT_APM_FUNC                                              11
> > +#define CLK_GOUT_APM_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK                   12
> > +#define CLK_GOUT_APM_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK               13
> > +#define CLK_GOUT_APM_APBIF_PMU_ALIVE_IPCLKPORT_PCLK                    14
> > +#define CLK_GOUT_APM_APBIF_RTC_IPCLKPORT_PCLK                          15
> > +#define CLK_GOUT_APM_APBIF_TRTC_IPCLKPORT_PCLK                         16
> > +#define CLK_GOUT_APM_APM_USI0_UART_IPCLKPORT_IPCLK                     17
> > +#define CLK_GOUT_APM_APM_USI0_UART_IPCLKPORT_PCLK                      18
> > +#define CLK_GOUT_APM_APM_USI0_USI_IPCLKPORT_IPCLK                      19
> > +#define CLK_GOUT_APM_APM_USI0_USI_IPCLKPORT_PCLK                       20
> > +#define CLK_GOUT_APM_APM_USI1_UART_IPCLKPORT_IPCLK                     21
> > +#define CLK_GOUT_APM_APM_USI1_UART_IPCLKPORT_PCLK                      22
> > +#define CLK_GOUT_APM_D_TZPC_APM_IPCLKPORT_PCLK                         23
> > +#define CLK_GOUT_APM_GPC_APM_IPCLKPORT_PCLK                            24
> > +#define CLK_GOUT_APM_GREBEINTEGRATION_IPCLKPORT_HCLK                   25
> > +#define CLK_GOUT_APM_INTMEM_IPCLKPORT_ACLK                             26
> > +#define CLK_GOUT_APM_INTMEM_IPCLKPORT_PCLK                             27
> > +#define CLK_GOUT_APM_LHM_AXI_G_SWD_IPCLKPORT_I_CLK                     28
> > +#define CLK_GOUT_APM_LHM_AXI_P_AOCAPM_IPCLKPORT_I_CLK                  29
> > +#define CLK_GOUT_APM_LHM_AXI_P_APM_IPCLKPORT_I_CLK                     30
> > +#define CLK_GOUT_APM_LHS_AXI_D_APM_IPCLKPORT_I_CLK                     31
> > +#define CLK_GOUT_APM_LHS_AXI_G_DBGCORE_IPCLKPORT_I_CLK                 32
> > +#define CLK_GOUT_APM_LHS_AXI_G_SCAN2DRAM_IPCLKPORT_I_CLK               33
> > +#define CLK_GOUT_APM_MAILBOX_APM_AOC_IPCLKPORT_PCLK                    34
> > +#define CLK_GOUT_APM_MAILBOX_APM_AP_IPCLKPORT_PCLK                     35
> > +#define CLK_GOUT_APM_MAILBOX_APM_GSA_IPCLKPORT_PCLK                    36
> > +#define CLK_GOUT_APM_MAILBOX_APM_SWD_IPCLKPORT_PCLK                    37
> > +#define CLK_GOUT_APM_MAILBOX_APM_TPU_IPCLKPORT_PCLK                    38
> > +#define CLK_GOUT_APM_MAILBOX_AP_AOC_IPCLKPORT_PCLK                     39
> > +#define CLK_GOUT_APM_MAILBOX_AP_DBGCORE_IPCLKPORT_PCLK         40
>
> This value (40) is not aligned with the rest of values.

Will fix

>
> > +#define CLK_GOUT_APM_PMU_INTR_GEN_IPCLKPORT_PCLK                       41
> > +#define CLK_GOUT_APM_ROM_CRC32_HOST_IPCLKPORT_ACLK                     42
> > +#define CLK_GOUT_APM_ROM_CRC32_HOST_IPCLKPORT_PCLK                     43
> > +#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_BUS_IPCLKPORT_CLK                        44
> > +#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_USI0_UART_IPCLKPORT_CLK          45
> > +#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_USI0_USI_IPCLKPORT_CLK           46
> > +#define CLK_GOUT_APM_RSTNSYNC_CLK_APM_USI1_UART_IPCLKPORT_CLK          47
> > +#define CLK_GOUT_APM_SPEEDY_APM_IPCLKPORT_PCLK                         48
> > +#define CLK_GOUT_APM_SPEEDY_SUB_APM_IPCLKPORT_PCLK                     49
> > +#define CLK_GOUT_APM_SSMT_D_APM_IPCLKPORT_ACLK                         50
> > +#define CLK_GOUT_APM_SSMT_D_APM_IPCLKPORT_PCLK                         51
> > +#define CLK_GOUT_APM_SSMT_G_DBGCORE_IPCLKPORT_ACLK                     52
> > +#define CLK_GOUT_APM_SSMT_G_DBGCORE_IPCLKPORT_PCLK                     53
> > +#define CLK_GOUT_APM_SS_DBGCORE_IPCLKPORT_SS_DBGCORE_IPCLKPORT_HCLK    54
> > +#define CLK_GOUT_APM_SYSMMU_D_APM_IPCLKPORT_CLK_S2                     55
> > +#define CLK_GOUT_APM_SYSREG_APM_IPCLKPORT_PCLK                         56
> > +#define CLK_GOUT_APM_UASC_APM_IPCLKPORT_ACLK                           57
> > +#define CLK_GOUT_APM_UASC_APM_IPCLKPORT_PCLK                           58
> > +#define CLK_GOUT_APM_UASC_DBGCORE_IPCLKPORT_ACLK                       59
> > +#define CLK_GOUT_APM_UASC_DBGCORE_IPCLKPORT_PCLK                       60
> > +#define CLK_GOUT_APM_UASC_G_SWD_IPCLKPORT_ACLK                         61
> > +#define CLK_GOUT_APM_UASC_G_SWD_IPCLKPORT_PCLK                         62
> > +#define CLK_GOUT_APM_UASC_P_AOCAPM_IPCLKPORT_ACLK                      63
> > +#define CLK_GOUT_APM_UASC_P_AOCAPM_IPCLKPORT_PCLK                      64
> > +#define CLK_GOUT_APM_UASC_P_APM_IPCLKPORT_ACLK                         65
> > +#define CLK_GOUT_APM_UASC_P_APM_IPCLKPORT_PCLK                         66
> > +#define CLK_GOUT_APM_WDT_APM_IPCLKPORT_PCLK                            67
> > +#define CLK_GOUT_APM_XIU_DP_APM_IPCLKPORT_ACLK                         68
> > +#define CLK_APM_PLL_DIV2_APM                                           69
> > +#define CLK_APM_PLL_DIV4_APM                                           70
> > +#define CLK_APM_PLL_DIV16_APM                                          71
> > +
> > +/* CMU_MISC */
> > +
>
> This empty line can be removed, for consistency with the rest of
> similar comments in this file.

Will fix

regards,

Peter.
>
> > +#define CLK_MOUT_MISC_BUS_USER                                 1
> > +#define CLK_MOUT_MISC_SSS_USER                                 2
> > +#define CLK_MOUT_MISC_GIC                                      3
> > +#define CLK_DOUT_MISC_BUSP                                     4
> > +#define CLK_DOUT_MISC_GIC                                      5
> > +#define CLK_GOUT_MISC_MISC_CMU_MISC_IPCLKPORT_PCLK             6
> > +#define CLK_GOUT_MISC_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK          7
> > +#define CLK_GOUT_MISC_OTP_CON_BISR_IPCLKPORT_I_OSCCLK          8
> > +#define CLK_GOUT_MISC_OTP_CON_TOP_IPCLKPORT_I_OSCCLK           9
> > +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_OSCCLK_IPCLKPORT_CLK   10
> > +#define CLK_GOUT_MISC_ADM_AHB_SSS_IPCLKPORT_HCLKM              11
> > +#define CLK_GOUT_MISC_AD_APB_DIT_IPCLKPORT_PCLKM               12
> > +#define CLK_GOUT_MISC_AD_APB_PUF_IPCLKPORT_PCLKM               13
> > +#define CLK_GOUT_MISC_DIT_IPCLKPORT_ICLKL2A                    14
> > +#define CLK_GOUT_MISC_D_TZPC_MISC_IPCLKPORT_PCLK               15
> > +#define CLK_GOUT_MISC_GIC_IPCLKPORT_GICCLK                     16
> > +#define CLK_GOUT_MISC_GPC_MISC_IPCLKPORT_PCLK                  17
> > +#define CLK_GOUT_MISC_LHM_AST_ICC_CPUGIC_IPCLKPORT_I_CLK       18
> > +#define CLK_GOUT_MISC_LHM_AXI_D_SSS_IPCLKPORT_I_CLK            19
> > +#define CLK_GOUT_MISC_LHM_AXI_P_GIC_IPCLKPORT_I_CLK            20
> > +#define CLK_GOUT_MISC_LHM_AXI_P_MISC_IPCLKPORT_I_CLK           21
> > +#define CLK_GOUT_MISC_LHS_ACEL_D_MISC_IPCLKPORT_I_CLK          22
> > +#define CLK_GOUT_MISC_LHS_AST_IRI_GICCPU_IPCLKPORT_I_CLK       23
> > +#define CLK_GOUT_MISC_LHS_AXI_D_SSS_IPCLKPORT_I_CLK            24
> > +#define CLK_GOUT_MISC_MCT_IPCLKPORT_PCLK                       25
> > +#define CLK_GOUT_MISC_OTP_CON_BIRA_IPCLKPORT_PCLK              26
> > +#define CLK_GOUT_MISC_OTP_CON_BISR_IPCLKPORT_PCLK              27
> > +#define CLK_GOUT_MISC_OTP_CON_TOP_IPCLKPORT_PCLK               28
> > +#define CLK_GOUT_MISC_PDMA_IPCLKPORT_ACLK                      29
> > +#define CLK_GOUT_MISC_PPMU_DMA_IPCLKPORT_ACLK                  30
> > +#define CLK_GOUT_MISC_PPMU_MISC_IPCLKPORT_ACLK                 31
> > +#define CLK_GOUT_MISC_PPMU_MISC_IPCLKPORT_PCLK                 32
> > +#define CLK_GOUT_MISC_PUF_IPCLKPORT_I_CLK                      33
> > +#define CLK_GOUT_MISC_QE_DIT_IPCLKPORT_ACLK                    34
> > +#define CLK_GOUT_MISC_QE_DIT_IPCLKPORT_PCLK                    35
> > +#define CLK_GOUT_MISC_QE_PDMA_IPCLKPORT_ACLK                   36
> > +#define CLK_GOUT_MISC_QE_PDMA_IPCLKPORT_PCLK                   37
> > +#define CLK_GOUT_MISC_QE_PPMU_DMA_IPCLKPORT_ACLK               38
> > +#define CLK_GOUT_MISC_QE_PPMU_DMA_IPCLKPORT_PCLK               39
> > +#define CLK_GOUT_MISC_QE_RTIC_IPCLKPORT_ACLK                   40
> > +#define CLK_GOUT_MISC_QE_RTIC_IPCLKPORT_PCLK                   41
> > +#define CLK_GOUT_MISC_QE_SPDMA_IPCLKPORT_ACLK                  42
> > +#define CLK_GOUT_MISC_QE_SPDMA_IPCLKPORT_PCLK                  43
> > +#define CLK_GOUT_MISC_QE_SSS_IPCLKPORT_ACLK                    44
> > +#define CLK_GOUT_MISC_QE_SSS_IPCLKPORT_PCLK                    45
> > +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_BUSD_IPCLKPORT_CLK     46
> > +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_BUSP_IPCLKPORT_CLK     47
> > +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_GIC_IPCLKPORT_CLK      48
> > +#define CLK_GOUT_MISC_RSTNSYNC_CLK_MISC_SSS_IPCLKPORT_CLK      49
> > +#define CLK_GOUT_MISC_RTIC_IPCLKPORT_I_ACLK                    50
> > +#define CLK_GOUT_MISC_RTIC_IPCLKPORT_I_PCLK                    51
> > +#define CLK_GOUT_MISC_SPDMA_IPCLKPORT_ACLK                     52
> > +#define CLK_GOUT_MISC_SSMT_DIT_IPCLKPORT_ACLK                  53
> > +#define CLK_GOUT_MISC_SSMT_DIT_IPCLKPORT_PCLK                  54
> > +#define CLK_GOUT_MISC_SSMT_PDMA_IPCLKPORT_ACLK                 55
> > +#define CLK_GOUT_MISC_SSMT_PDMA_IPCLKPORT_PCLK                 56
> > +#define CLK_GOUT_MISC_SSMT_PPMU_DMA_IPCLKPORT_ACLK             57
> > +#define CLK_GOUT_MISC_SSMT_PPMU_DMA_IPCLKPORT_PCLK             58
> > +#define CLK_GOUT_MISC_SSMT_RTIC_IPCLKPORT_ACLK                 59
> > +#define CLK_GOUT_MISC_SSMT_RTIC_IPCLKPORT_PCLK                 60
> > +#define CLK_GOUT_MISC_SSMT_SPDMA_IPCLKPORT_ACLK                        61
> > +#define CLK_GOUT_MISC_SSMT_SPDMA_IPCLKPORT_PCLK                        62
> > +#define CLK_GOUT_MISC_SSMT_SSS_IPCLKPORT_ACLK                  63
> > +#define CLK_GOUT_MISC_SSMT_SSS_IPCLKPORT_PCLK                  64
> > +#define CLK_GOUT_MISC_SSS_IPCLKPORT_I_ACLK                     65
> > +#define CLK_GOUT_MISC_SSS_IPCLKPORT_I_PCLK                     66
> > +#define CLK_GOUT_MISC_SYSMMU_MISC_IPCLKPORT_CLK_S2             67
> > +#define CLK_GOUT_MISC_SYSMMU_SSS_IPCLKPORT_CLK_S1              68
> > +#define CLK_GOUT_MISC_SYSREG_MISC_IPCLKPORT_PCLK               69
> > +#define CLK_GOUT_MISC_TMU_SUB_IPCLKPORT_PCLK                   70
> > +#define CLK_GOUT_MISC_TMU_TOP_IPCLKPORT_PCLK                   71
> > +#define CLK_GOUT_MISC_WDT_CLUSTER0_IPCLKPORT_PCLK              72
> > +#define CLK_GOUT_MISC_WDT_CLUSTER1_IPCLKPORT_PCLK              73
> > +#define CLK_GOUT_MISC_XIU_D_MISC_IPCLKPORT_ACLK                        74
> > +
> > +#endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >


From peter.griffin at linaro.org  Sun Dec  3 13:13:03 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sun, 3 Dec 2023 21:13:03 +0000
Subject: [PATCH v5 05/20] dt-bindings: arm: google: Add bindings for
 Google ARM platforms
In-Reply-To: <CAPLW+4mm8+U=wnXRfRG7QQHh02tiS3uo3Fw9ywYaCumV1qPB=g@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-6-peter.griffin@linaro.org> <CAPLW+4mm8+U=wnXRfRG7QQHh02tiS3uo3Fw9ywYaCumV1qPB=g@mail.gmail.com>
Message-ID: <CADrjBPqgZsE1v5KTiqfqhraX2skx5b6=5zbsojup+M3r2G_f3w@mail.gmail.com>

Hi Sam,

Thanks for the review.

On Fri, 1 Dec 2023 at 20:22, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:10?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > This introduces bindings and dt-schema for the Google tensor SoCs.
> > Currently just gs101 and pixel 6 are supported.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > Reviewed-by: Rob Herring <robh at kernel.org>
> > ---
>
> Other than spelling comments below:
>
> git st
>
> >  .../devicetree/bindings/arm/google.yaml       | 53 +++++++++++++++++++
> >  1 file changed, 53 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> > new file mode 100644
> > index 000000000000..be191e70192d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/google.yaml
> > @@ -0,0 +1,53 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/google.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Google Tensor platforms
> > +
> > +maintainers:
> > +  - Peter Griffin <peter.griffin at linaro.org>
> > +
> > +description: |
> > +  ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
> > +  devices.
> > +
> > +  Currently upstream this is devices using "gs101" SoC which is found in Pixel
> > +  6, Pixel 6 Pro and Pixel 6a.
> > +
> > +  Google have a few different names for the SoC.
>
> Suggest removing period, or replacing it with colon.

will fix
>
> > +  - Marketing name ("Tensor")
> > +  - Codename ("Whitechapel")
> > +  - SoC ID ("gs101")
> > +  - Die ID ("S5P9845");
>
> Semicolon seems off here.

will fix

>
> > +
> > +  Likewise there are a couple of names for the actual device
> > +  - Marketing name ("Pixel 6")
> > +  - Codename ("Oriole")
> > +
> > +  Devicetrees should use the lowercased SoC ID and lowercased board codename.
>
> period -> comma
>
> > +  e.g. gs101 and gs101-oriole
>
> Missing period character.

will fix

Peter
>
> > +
> > +properties:
> > +  $nodename:
> > +    const: '/'
> > +  compatible:
> > +    oneOf:
> > +      - description: Google Pixel 6 / Oriole
> > +        items:
> > +          - enum:
> > +              - google,gs101-oriole
> > +          - const: google,gs101
> > +
> > +  # Bootloader requires empty ect node to be present
> > +  ect:
> > +    type: object
> > +    additionalProperties: false
> > +
> > +required:
> > +  - ect
> > +
> > +additionalProperties: true
> > +
> > +...
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >


From peter.griffin at linaro.org  Sun Dec  3 13:21:14 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sun, 3 Dec 2023 21:21:14 +0000
Subject: [PATCH v5 07/20] dt-bindings: pinctrl: samsung: add
 gs101-wakeup-eint compatible
In-Reply-To: <fedd4ec8-b4e6-472a-9bfd-063ea8b9658e@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-8-peter.griffin@linaro.org> <fedd4ec8-b4e6-472a-9bfd-063ea8b9658e@linaro.org>
Message-ID: <CADrjBPrqWKdhiL8TCcBC3ohLAwrAZiRwtA8Yg0q4gkrf9qrKqw@mail.gmail.com>

Hi Krzysztof,

Thanks for the review.

On Sun, 3 Dec 2023 at 15:11, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 01/12/2023 17:09, Peter Griffin wrote:
> > gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
> > where more than one pin controller can do external wake-up interrupt.
> > So add a dedicated compatible for it.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> > index 2bafa867aea2..de2209f8ba00 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> > +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> > @@ -44,6 +44,7 @@ properties:
> >            - const: samsung,exynos7-wakeup-eint
> >        - items:
> >            - enum:
> > +              - google,gs101-wakeup-eint
> >                - samsung,exynosautov9-wakeup-eint
> >                - samsung,exynosautov920-wakeup-eint
> >            - const: samsung,exynos850-wakeup-eint
> > @@ -111,6 +112,7 @@ allOf:
> >          compatible:
> >            contains:
> >              enum:
> > +              - google,gs101-wakeup-eint
>
> Drop, not needed.

Will fix

Peter.


From peter.griffin at linaro.org  Sun Dec  3 13:31:41 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sun, 3 Dec 2023 21:31:41 +0000
Subject: [PATCH v5 09/20] dt-bindings: serial: samsung: Make
 samsung,uart-fifosize required property
In-Reply-To: <59b949a0-5aeb-4f01-8789-cb305513b626@app.fastmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-10-peter.griffin@linaro.org> <59b949a0-5aeb-4f01-8789-cb305513b626@app.fastmail.com>
Message-ID: <CADrjBPoeLLcoDuLdkVhO4C_8qFAvFSu2igNPP09RXagiJpPsig@mail.gmail.com>

Hi Arnd,

On Fri, 1 Dec 2023 at 16:39, Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Fri, Dec 1, 2023, at 17:09, Peter Griffin wrote:
> >
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - google,gs101-uart
> > +    then:
> > +      required:
> > +        - samsung,uart-fifosize
> > +
>
> Is there a way to reverse the list and make the property
> required for anything that is not explicitly enumerated?

I'm not aware of a way to do that, but I'm by no means an expert with
json schema. Krzysztof or Rob may know of a way.

I presume your rationale is any newly added platform would get a DTC
warning if they didn't add the samsung,uart-fifosize property?

Krzysztof and Rob also had concerns in the previous series about ABI
breakage on existing platforms, which is why this was only made
required for google,gs101-uart.

regards,

Peter


From aford173 at gmail.com  Sun Dec  3 13:32:52 2023
From: aford173 at gmail.com (Adam Ford)
Date: Sun, 3 Dec 2023 15:32:52 -0600
Subject: [PATCH v4 11/11] media: rkisp1: Add UYVY as an output format
In-Reply-To: <20231129092759.242641-12-paul.elder@ideasonboard.com>
References: <20231129092759.242641-1-paul.elder@ideasonboard.com> <20231129092759.242641-12-paul.elder@ideasonboard.com>
Message-ID: <CAHCN7xLihh_r=zn+2EsqZvsOumeJY52DHmrkVv0+A7Grib8AhQ@mail.gmail.com>

On Wed, Nov 29, 2023 at 3:29?AM Paul Elder <paul.elder at ideasonboard.com> wrote:
>
> Add support for UYVY as an output format. The uv_swap bit in the
> MI_XTD_FORMAT_CTRL register that is used for the NV formats does not
> work for packed YUV formats. Thus, UYVY support is implemented via
> byte-swapping. This method clearly does not work for implementing
> support for YVYU and VYUY.
>
> Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> ---
>  .../platform/rockchip/rkisp1/rkisp1-capture.c | 41 +++++++++++++++++++
>  1 file changed, 41 insertions(+)


Paul,

I tested this patch series from one of the older submissions and I was
able to get it working, but I could not get the video to capture to
work no matter what resolution or video format I tried.  Each time, I
get the same error message:  rkisp1 32e10000.isp: start pipeline
failed -32

Do you have an example of how you configured the pipeline and how you
invoked the video capture?

thanks

adam

>
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> index a352893308b6..b50b044d22af 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> @@ -97,6 +97,12 @@ static const struct rkisp1_capture_fmt_cfg rkisp1_mp_fmts[] = {
>                 .uv_swap = 0,
>                 .write_format = RKISP1_MI_CTRL_MP_WRITE_YUVINT,
>                 .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
> +       }, {
> +               .fourcc = V4L2_PIX_FMT_UYVY,
> +               .uv_swap = 0,
> +               .yc_swap = 1,
> +               .write_format = RKISP1_MI_CTRL_MP_WRITE_YUVINT,
> +               .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
>         }, {
>                 .fourcc = V4L2_PIX_FMT_YUV422P,
>                 .uv_swap = 0,
> @@ -231,6 +237,13 @@ static const struct rkisp1_capture_fmt_cfg rkisp1_sp_fmts[] = {
>                 .write_format = RKISP1_MI_CTRL_SP_WRITE_INT,
>                 .output_format = RKISP1_MI_CTRL_SP_OUTPUT_YUV422,
>                 .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
> +       }, {
> +               .fourcc = V4L2_PIX_FMT_UYVY,
> +               .uv_swap = 0,
> +               .yc_swap = 1,
> +               .write_format = RKISP1_MI_CTRL_SP_WRITE_INT,
> +               .output_format = RKISP1_MI_CTRL_SP_OUTPUT_YUV422,
> +               .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
>         }, {
>                 .fourcc = V4L2_PIX_FMT_YUV422P,
>                 .uv_swap = 0,
> @@ -464,6 +477,20 @@ static void rkisp1_mp_config(struct rkisp1_capture *cap)
>                 rkisp1_write(rkisp1, RKISP1_CIF_MI_XTD_FORMAT_CTRL, reg);
>         }
>
> +       /*
> +        * U/V swapping with the MI_XTD_FORMAT_CTRL register only works for
> +        * NV12/NV21 and NV16/NV61, so instead use byte swap to support UYVY.
> +        * YVYU and VYUY cannot be supported with this method.
> +        */
> +       if (rkisp1->info->features & RKISP1_FEATURE_MI_OUTPUT_ALIGN) {
> +               reg = rkisp1_read(rkisp1, RKISP1_CIF_MI_OUTPUT_ALIGN_FORMAT);
> +               if (cap->pix.cfg->yc_swap)
> +                       reg |= RKISP1_CIF_OUTPUT_ALIGN_FORMAT_MP_BYTE_SWAP_BYTES;
> +               else
> +                       reg &= ~RKISP1_CIF_OUTPUT_ALIGN_FORMAT_MP_BYTE_SWAP_BYTES;
> +               rkisp1_write(rkisp1, RKISP1_CIF_MI_OUTPUT_ALIGN_FORMAT, reg);
> +       }
> +
>         rkisp1_mi_config_ctrl(cap);
>
>         reg = rkisp1_read(rkisp1, RKISP1_CIF_MI_CTRL);
> @@ -507,6 +534,20 @@ static void rkisp1_sp_config(struct rkisp1_capture *cap)
>                 rkisp1_write(rkisp1, RKISP1_CIF_MI_XTD_FORMAT_CTRL, reg);
>         }
>
> +       /*
> +        * U/V swapping with the MI_XTD_FORMAT_CTRL register only works for
> +        * NV12/NV21 and NV16/NV61, so instead use byte swap to support UYVY.
> +        * YVYU and VYUY cannot be supported with this method.
> +        */
> +       if (rkisp1->info->features & RKISP1_FEATURE_MI_OUTPUT_ALIGN) {
> +               reg = rkisp1_read(rkisp1, RKISP1_CIF_MI_OUTPUT_ALIGN_FORMAT);
> +               if (cap->pix.cfg->yc_swap)
> +                       reg |= RKISP1_CIF_OUTPUT_ALIGN_FORMAT_SP_BYTE_SWAP_BYTES;
> +               else
> +                       reg &= ~RKISP1_CIF_OUTPUT_ALIGN_FORMAT_SP_BYTE_SWAP_BYTES;
> +               rkisp1_write(rkisp1, RKISP1_CIF_MI_OUTPUT_ALIGN_FORMAT, reg);
> +       }
> +
>         rkisp1_mi_config_ctrl(cap);
>
>         mi_ctrl = rkisp1_read(rkisp1, RKISP1_CIF_MI_CTRL);
> --
> 2.39.2
>


From peter.griffin at linaro.org  Sun Dec  3 13:39:43 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sun, 3 Dec 2023 21:39:43 +0000
Subject: [PATCH v5 09/20] dt-bindings: serial: samsung: Make
 samsung,uart-fifosize required property
In-Reply-To: <b4e710c0-dddb-4217-9979-21bdc20ee302@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-10-peter.griffin@linaro.org> <b4e710c0-dddb-4217-9979-21bdc20ee302@linaro.org>
Message-ID: <CADrjBPpcknRifds+WpuwmdzGxxFq-osLf7_Rn1ENjoRcXwCRxw@mail.gmail.com>

Hi Krzysztof,

On Sun, 3 Dec 2023 at 15:11, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 01/12/2023 17:09, Peter Griffin wrote:
> > Specifying samsung,uart-fifosize in both DT and driver static data is error
> > prone and relies on driver probe order and dt aliases to be correct.
> >
> > Additionally on many Exynos platforms these are (USI) universal serial
> > interfaces which can be uart, spi or i2c, so it can change per board.
> >
> > For google,gs101-uart and exynosautov9-uart make samsung,uart-fifosize a
> > required property. For these platforms fifosize now *only* comes from DT.
>
> I don't see ExynosAutov9 compatible in your patch.

I dropped exynosautov9-uart compatible from this patch due to the ABI
breakage. It seems I forgot to update the commit wording though. Will
fix.

Peter.
>
> >
> > It is hoped other Exynos platforms will also switch over time.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  .../devicetree/bindings/serial/samsung_uart.yaml       | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > index ccc3626779d9..65d5d361e8f4 100644
> > --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > @@ -133,6 +133,16 @@ allOf:
> >              - const: uart
> >              - const: clk_uart_baud0
> >
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - google,gs101-uart
> Best regards,
> Krzysztof
>


From 21cnbao at gmail.com  Sun Dec  3 13:41:27 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Mon, 4 Dec 2023 05:41:27 +0800
Subject: [PATCH v2 14/14] arm64/mm: Add ptep_get_and_clear_full() to
 optimize process teardown
In-Reply-To: <1d2f8e43-447e-4af4-96ac-1eefea7d6747@arm.com>
References: <20231115163018.1303287-15-ryan.roberts@arm.com>
 <20231128081742.39204-1-v-songbaohua@oppo.com> <207de995-6d48-41ea-8373-2f9caad9b9c3@arm.com>
 <CAGsJ_4wV-z7u5N3oLM-3kONHe0fmQwO7CSWQk9w0u0EhMroXAA@mail.gmail.com>
 <34da1e06-74da-4e45-b0b5-9c93d64eb64e@arm.com> <CAGsJ_4x78VhazGu3cA=W7Nc7yshwHTJjtFYHrCY1SOjC4__qfA@mail.gmail.com>
 <1d2f8e43-447e-4af4-96ac-1eefea7d6747@arm.com>
Message-ID: <CAGsJ_4xJ=VibK3FFGr5UHDQn+HW_o1_ZMiUjhgo8+i=UWa3UGQ@mail.gmail.com>

On Thu, Nov 30, 2023 at 8:00?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>
> >> Just because you found a pte that maps a page from a large folio, that doesn't
> >> mean that all pages from the folio are mapped, and it doesn't mean they are
> >> mapped contiguously. We have to deal with partial munmap(), partial mremap()
> >> etc. We could split in these cases (and in future it might be sensible to try),
> >> but that can fail (due to GUP). So we still have to handle the corner case.
> >>
> >> But I can imagine doing a batched version of ptep_get_and_clear(), like I did
> >> for ptep_set_wrprotects(). And I think this would be an improvement.
> >>
> >> The reason I haven't done that so far, is because ptep_get_and_clear() returns
> >> the pte value when it was cleared and that's hard to do if batching due to the
> >> storage requirement. But perhaps you could just return the logical OR of the
> >> dirty and young bits across all ptes in the batch. The caller should be able to
> >> reconstitute the rest if it needs it?
> >>
> >> What do you think?
> >
> > I really don't know why we care about the return value of ptep_get_and_clear()
> > as zap_pte_range() doesn't ask for any ret value at all. so why not totally give
> > up this kind of complex logical OR of dirty and young as they are useless in
> > this case?
>
> That's not the case in v6.7-rc1:
>
>
> static unsigned long zap_pte_range(struct mmu_gather *tlb,
>                                 struct vm_area_struct *vma, pmd_t *pmd,
>                                 unsigned long addr, unsigned long end,
>                                 struct zap_details *details)
> {
>         ...
>
>         do {
>                 pte_t ptent = ptep_get(pte);
>
>                 ...
>
>                 if (pte_present(ptent)) {
>                         ...
>
>                         ptent = ptep_get_and_clear_full(mm, addr, pte,
>                                                         tlb->fullmm);
>                         arch_check_zapped_pte(vma, ptent);
>                         tlb_remove_tlb_entry(tlb, pte, addr);
>                         zap_install_uffd_wp_if_needed(vma, addr, pte, details,
>                                                       ptent);
>                         if (unlikely(!page)) {
>                                 ksm_might_unmap_zero_page(mm, ptent);
>                                 continue;
>                         }
>
>                         delay_rmap = 0;
>                         if (!PageAnon(page)) {
>                                 if (pte_dirty(ptent)) {
>                                         set_page_dirty(page);
>                                         if (tlb_delay_rmap(tlb)) {
>                                                 delay_rmap = 1;
>                                                 force_flush = 1;
>                                         }
>                                 }
>                                 if (pte_young(ptent) && likely(vma_has_recency(vma)))
>                                         mark_page_accessed(page);
>                         }
>
>                         ...
>                 }
>
>                 ...
>         } while (pte++, addr += PAGE_SIZE, addr != end);
>
>         ...
> }
>
> Most importantly, file-backed mappings need the access/dirty bits to propagate that information back to the folio, so it will be written back to disk. x86 is also looking at the dirty bit in arch_check_zapped_pte(), and ksm is using it in ksm_might_unmap_zero_page().
>
> Probably for your use case of anon memory on arm64 on a phone, you don't need the return value. But my solution is also setting cotnpte for file-backed memory, and there are performance wins to be had there, especially for executable mappings where contpte reduces iTLB pressure. (I have other work which ensures these file-backed mappings are in correctly-sized large folios).
>
> So I don't think we can just do a clear without the get part. But I think I have a solution in the shape of clear_ptes(), as described in the other thread, which gives the characteristics you suggest.

understood. i realized OPPO's code actually also returned logic OR of
dirty and access bits while it exposes
CONTPTE to mm-core [1]:

static pte_t get_clear_flush(struct mm_struct *mm,
                             unsigned long addr,
                             pte_t *ptep,
                             unsigned long pgsize,
                             unsigned long ncontig,
                             bool flush)
{
        pte_t orig_pte = ptep_get(ptep);
        bool valid = pte_valid(orig_pte);
        unsigned long i, saddr = addr;

        for (i = 0; i < ncontig; i++, addr += pgsize, ptep++) {
                pte_t pte = ptep_get_and_clear(mm, addr, ptep);

                if (pte_dirty(pte))
                        orig_pte = pte_mkdirty(orig_pte);

                if (pte_young(pte))
                        orig_pte = pte_mkyoung(orig_pte);
        }

        if (valid && flush) {
                struct vm_area_struct vma = TLB_FLUSH_VMA(mm, 0);

                flush_tlb_range(&vma, saddr, addr);
        }
        return orig_pte;
}

static inline pte_t __cont_pte_huge_ptep_get_and_clear_flush(struct
mm_struct *mm,
                                       unsigned long addr,
                                       pte_t *ptep,
                                       bool flush)
{
        pte_t orig_pte = ptep_get(ptep);

        CHP_BUG_ON(!pte_cont(orig_pte));
        CHP_BUG_ON(!IS_ALIGNED(addr, HPAGE_CONT_PTE_SIZE));
        CHP_BUG_ON(!IS_ALIGNED(pte_pfn(orig_pte), HPAGE_CONT_PTE_NR));

        return get_clear_flush(mm, addr, ptep, PAGE_SIZE, CONT_PTES, flush);
}

[1] https://github.com/OnePlusOSS/android_kernel_oneplus_sm8550/blob/oneplus/sm8550_u_14.0.0_oneplus11/mm/cont_pte_hugepage.c#L1421

>
>
> >
> > Is it possible for us to introduce a new api like?
> >
> > bool clear_folio_ptes(folio, ptep)
> > {
> >     if(ptes are contiguous mapped) {
> >            clear all ptes all together    // this also clears all CONTPTE
> >            return true;
> >     }
> >     return false;
> > }
> >
> > in zap_pte_range():
> >
> > if (large_folio(folio) && clear_folio_ptes(folio, ptep)) {
> >          addr += nr - 1
> >          pte += nr  -1
> > } else
> >          old path.
> >
> >
> >>
> >>>
> >>> zap_pte_range is the most frequent behaviour from userspace libc heap
> >>> as i explained
> >>> before. libc can call madvise(DONTNEED) the most often. It is crucial
> >>> to performance.
> >>>
> >>> and this way can also help drop your full version by moving to full
> >>> flushing the whole
> >>> large folios? and we don't need to depend on fullmm any more?
> >>>
> >>>>
> >>>> I don't think there is any correctness issue here. But there is a problem with
> >>>> fragility, as raised by Alistair. I have some ideas on potentially how to solve
> >>>> that. I'm going to try to work on it this afternoon and will post if I get some
> >>>> confidence that it is a real solution.
> >>>>
> >>>> Thanks,
> >>>> Ryan
> >>>>
> >>>>>
> >>>>> static inline pte_t __cont_pte_huge_ptep_get_and_clear_flush(struct mm_struct *mm,
> >>>>>                                      unsigned long addr,
> >>>>>                                      pte_t *ptep,
> >>>>>                                      bool flush)
> >>>>> {
> >>>>>       pte_t orig_pte = ptep_get(ptep);
> >>>>>
> >>>>>       CHP_BUG_ON(!pte_cont(orig_pte));
> >>>>>       CHP_BUG_ON(!IS_ALIGNED(addr, HPAGE_CONT_PTE_SIZE));
> >>>>>       CHP_BUG_ON(!IS_ALIGNED(pte_pfn(orig_pte), HPAGE_CONT_PTE_NR));
> >>>>>
> >>>>>       return get_clear_flush(mm, addr, ptep, PAGE_SIZE, CONT_PTES, flush);
> >>>>> }
> >>>>>
> >>>>> [1] https://github.com/OnePlusOSS/android_kernel_oneplus_sm8550/blob/oneplus/sm8550_u_14.0.0_oneplus11/mm/memory.c#L1539
> >>>>>
> >>>>>> +     */
> >>>>>> +
> >>>>>> +    return __ptep_get_and_clear(mm, addr, ptep);
> >>>>>> +}
> >>>>>> +EXPORT_SYMBOL(contpte_ptep_get_and_clear_full);
> >>>>>> +
> >>>>>
> >>>
> >  Thanks
> >  Barry
>


From peter.griffin at linaro.org  Sun Dec  3 13:47:16 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sun, 3 Dec 2023 21:47:16 +0000
Subject: [PATCH v5 10/20] dt-bindings: soc: samsung: usi: add
 google,gs101-usi compatible
In-Reply-To: <2854a9b5-d6c8-454c-bc3b-79744e613686@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-11-peter.griffin@linaro.org> <2854a9b5-d6c8-454c-bc3b-79744e613686@linaro.org>
Message-ID: <CADrjBPofpjB7iA3u1LGy61F_0dPX40ZrtJsHd6zumTOFu3bEjg@mail.gmail.com>

Hi Krzysztof,

On Sun, 3 Dec 2023 at 15:10, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 01/12/2023 17:09, Peter Griffin wrote:
> > From: Tudor Ambarus <tudor.ambarus at linaro.org>
> >
> > Add google,gs101-usi dedicated compatible for representing USI of Google
> > GS101 SoC.
> >
> > Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> > index 61be1f2ddbe7..a10a438d89f0 100644
> > --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> > +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> > @@ -28,6 +28,9 @@ properties:
> >                - samsung,exynosautov9-usi
> >                - samsung,exynosautov920-usi
> >            - const: samsung,exynos850-usi
> > +      - items:
> > +          - const: google,gs101-usi
>
> This should be part of previous enum.

will fix,

Thanks,

Peter.


From andi.shyti at kernel.org  Sun Dec  3 13:55:30 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Sun, 3 Dec 2023 22:55:30 +0100
Subject: [PATCH v3 3/8] i2c: rk3x: Adjust mask/value offset for i2c2 on
 rv1126
In-Reply-To: <4413905.22IY78Rhhi@diego>
References: <20231203124004.2676174-1-tim@feathertop.org>
 <20231203124004.2676174-4-tim@feathertop.org>
 <20231203190620.26of3xrcoosnpicb@zenone.zhora.eu>
 <4413905.22IY78Rhhi@diego>
Message-ID: <20231203215530.mewjd7n7ltaeed3w@zenone.zhora.eu>

Hi,

On Sun, Dec 03, 2023 at 08:48:43PM +0100, Heiko St?bner wrote:
> Hi Andi,
> 
> Am Sonntag, 3. Dezember 2023, 20:06:20 CET schrieb Andi Shyti:
> > Hi Tim,
> > 
> > On Sun, Dec 03, 2023 at 11:39:59PM +1100, Tim Lunn wrote:
> > > Rockchip RV1126 is using old style i2c controller, the i2c2
> > > bus uses a non-sequential offset in the grf register for the
> > > mask/value bits for this bus.
> > > 
> > > This patch fixes i2c2 bus on rv1126 SoCs.
> > > 
> > > Signed-off-by: Tim Lunn <tim at feathertop.org>
> > > Acked-by: Heiko Stuebner <heiko at sntech.de>
> > 
> > Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
> 
> you're listed as the maintainer for the i2c busses,
> are you going to pick this one patch yourself?
> Or do you expect a different handling?
> 
> I.e. it doesn't really tie into the dts patches and everything will come
> together nicely in linux-next and during the next merge-window.

Wolfram are you going to take this?

Andi


From andi.shyti at kernel.org  Sun Dec  3 14:04:44 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Sun, 3 Dec 2023 23:04:44 +0100
Subject: [PATCH 1/1] i2c: imx: Make SDA actually optional for bus
 recovering
In-Reply-To: <20231130095751.65773-1-alexander.stein@ew.tq-group.com>
References: <20231130095751.65773-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231203220444.thaeuyqyv36hpv2y@zenone.zhora.eu>

Hi,

On Thu, Nov 30, 2023 at 10:57:51AM +0100, Alexander Stein wrote:
> Both i2c_generic_scl_recovery() and the debug output indicate that SDA is
> purely optional for bus recovery. But devm_gpiod_get() never returns NULL
> making it mandatory. Fix this my calling devm_gpiod_get_optional instead.
                               ^^^^
as Uwe pointed out, /my/by/.

I think Wolfram can fix this before taking it.

> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

otherwise:

Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Andi


From aford173 at gmail.com  Sun Dec  3 14:15:32 2023
From: aford173 at gmail.com (Adam Ford)
Date: Sun, 3 Dec 2023 16:15:32 -0600
Subject: [PATCH v4 11/11] media: rkisp1: Add UYVY as an output format
In-Reply-To: <CAHCN7xLihh_r=zn+2EsqZvsOumeJY52DHmrkVv0+A7Grib8AhQ@mail.gmail.com>
References: <20231129092759.242641-1-paul.elder@ideasonboard.com>
 <20231129092759.242641-12-paul.elder@ideasonboard.com> <CAHCN7xLihh_r=zn+2EsqZvsOumeJY52DHmrkVv0+A7Grib8AhQ@mail.gmail.com>
Message-ID: <CAHCN7xK8prNL8HGUCGpUW0-NLWvCphjGrUz_5D2CpyPFa0vG8Q@mail.gmail.com>

On Sun, Dec 3, 2023 at 3:32?PM Adam Ford <aford173 at gmail.com> wrote:
>
> On Wed, Nov 29, 2023 at 3:29?AM Paul Elder <paul.elder at ideasonboard.com> wrote:
> >
> > Add support for UYVY as an output format. The uv_swap bit in the
> > MI_XTD_FORMAT_CTRL register that is used for the NV formats does not
> > work for packed YUV formats. Thus, UYVY support is implemented via
> > byte-swapping. This method clearly does not work for implementing
> > support for YVYU and VYUY.
> >
> > Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > ---
> >  .../platform/rockchip/rkisp1/rkisp1-capture.c | 41 +++++++++++++++++++
> >  1 file changed, 41 insertions(+)
>
>
> Paul,
>
> I tested this patch series from one of the older submissions and I was
> able to get it working, but I could not get the video to capture to
> work no matter what resolution or video format I tried.  Each time, I
> get the same error message:  rkisp1 32e10000.isp: start pipeline
> failed -32
>
> Do you have an example of how you configured the pipeline and how you
> invoked the video capture?

I have it working now but I had to apply the patch [1]  provided by
Tomi in order for it to work properly

Can you send another revision with his patch included in the series?

With that, you can add

Tested-by: Adam Ford <aford173 at gmail.com> #imx8mp-beacon-kit

Thank you.

adam
[1] - https://gitlab.com/ideasonboard/nxp/linux/-/commit/d6477fe673b1c0d05d12ae21d8db9a03b07e7fea

>
> thanks
>
> adam
>
> >
> > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > index a352893308b6..b50b044d22af 100644
> > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > @@ -97,6 +97,12 @@ static const struct rkisp1_capture_fmt_cfg rkisp1_mp_fmts[] = {
> >                 .uv_swap = 0,
> >                 .write_format = RKISP1_MI_CTRL_MP_WRITE_YUVINT,
> >                 .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
> > +       }, {
> > +               .fourcc = V4L2_PIX_FMT_UYVY,
> > +               .uv_swap = 0,
> > +               .yc_swap = 1,
> > +               .write_format = RKISP1_MI_CTRL_MP_WRITE_YUVINT,
> > +               .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
> >         }, {
> >                 .fourcc = V4L2_PIX_FMT_YUV422P,
> >                 .uv_swap = 0,
> > @@ -231,6 +237,13 @@ static const struct rkisp1_capture_fmt_cfg rkisp1_sp_fmts[] = {
> >                 .write_format = RKISP1_MI_CTRL_SP_WRITE_INT,
> >                 .output_format = RKISP1_MI_CTRL_SP_OUTPUT_YUV422,
> >                 .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
> > +       }, {
> > +               .fourcc = V4L2_PIX_FMT_UYVY,
> > +               .uv_swap = 0,
> > +               .yc_swap = 1,
> > +               .write_format = RKISP1_MI_CTRL_SP_WRITE_INT,
> > +               .output_format = RKISP1_MI_CTRL_SP_OUTPUT_YUV422,
> > +               .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
> >         }, {
> >                 .fourcc = V4L2_PIX_FMT_YUV422P,
> >                 .uv_swap = 0,
> > @@ -464,6 +477,20 @@ static void rkisp1_mp_config(struct rkisp1_capture *cap)
> >                 rkisp1_write(rkisp1, RKISP1_CIF_MI_XTD_FORMAT_CTRL, reg);
> >         }
> >
> > +       /*
> > +        * U/V swapping with the MI_XTD_FORMAT_CTRL register only works for
> > +        * NV12/NV21 and NV16/NV61, so instead use byte swap to support UYVY.
> > +        * YVYU and VYUY cannot be supported with this method.
> > +        */
> > +       if (rkisp1->info->features & RKISP1_FEATURE_MI_OUTPUT_ALIGN) {
> > +               reg = rkisp1_read(rkisp1, RKISP1_CIF_MI_OUTPUT_ALIGN_FORMAT);
> > +               if (cap->pix.cfg->yc_swap)
> > +                       reg |= RKISP1_CIF_OUTPUT_ALIGN_FORMAT_MP_BYTE_SWAP_BYTES;
> > +               else
> > +                       reg &= ~RKISP1_CIF_OUTPUT_ALIGN_FORMAT_MP_BYTE_SWAP_BYTES;
> > +               rkisp1_write(rkisp1, RKISP1_CIF_MI_OUTPUT_ALIGN_FORMAT, reg);
> > +       }
> > +
> >         rkisp1_mi_config_ctrl(cap);
> >
> >         reg = rkisp1_read(rkisp1, RKISP1_CIF_MI_CTRL);
> > @@ -507,6 +534,20 @@ static void rkisp1_sp_config(struct rkisp1_capture *cap)
> >                 rkisp1_write(rkisp1, RKISP1_CIF_MI_XTD_FORMAT_CTRL, reg);
> >         }
> >
> > +       /*
> > +        * U/V swapping with the MI_XTD_FORMAT_CTRL register only works for
> > +        * NV12/NV21 and NV16/NV61, so instead use byte swap to support UYVY.
> > +        * YVYU and VYUY cannot be supported with this method.
> > +        */
> > +       if (rkisp1->info->features & RKISP1_FEATURE_MI_OUTPUT_ALIGN) {
> > +               reg = rkisp1_read(rkisp1, RKISP1_CIF_MI_OUTPUT_ALIGN_FORMAT);
> > +               if (cap->pix.cfg->yc_swap)
> > +                       reg |= RKISP1_CIF_OUTPUT_ALIGN_FORMAT_SP_BYTE_SWAP_BYTES;
> > +               else
> > +                       reg &= ~RKISP1_CIF_OUTPUT_ALIGN_FORMAT_SP_BYTE_SWAP_BYTES;
> > +               rkisp1_write(rkisp1, RKISP1_CIF_MI_OUTPUT_ALIGN_FORMAT, reg);
> > +       }
> > +
> >         rkisp1_mi_config_ctrl(cap);
> >
> >         mi_ctrl = rkisp1_read(rkisp1, RKISP1_CIF_MI_CTRL);
> > --
> > 2.39.2
> >


From sfr at canb.auug.org.au  Sun Dec  3 15:03:55 2023
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Mon, 4 Dec 2023 10:03:55 +1100
Subject: linux-next: manual merge of the qcom tree with the arm-soc tree
Message-ID: <20231204100355.0fb43204@canb.auug.org.au>

Hi all,

Today's linux-next merge of the qcom tree got a conflict in:

  arch/arm/boot/dts/qcom/Makefile

between commits:

  00400a98b2c3 ("ARM: dts: qcom: add device tree for Nokia Lumia 735")
  8677233e5913 ("ARM: dts: qcom: add device tree for Nokia Lumia 830")

from the arm-soc tree and commit:

  be0061dcbac1 ("ARM: dts: qcom: Add support for HTC One Mini 2")

from the qcom tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/boot/dts/qcom/Makefile
index a3d293e40820,c13dddd3c683..000000000000
--- a/arch/arm/boot/dts/qcom/Makefile
+++ b/arch/arm/boot/dts/qcom/Makefile
@@@ -32,8 -29,7 +32,9 @@@ dtb-$(CONFIG_ARCH_QCOM) += 
  	qcom-msm8916-samsung-e7.dtb \
  	qcom-msm8916-samsung-grandmax.dtb \
  	qcom-msm8916-samsung-serranove.dtb \
+ 	qcom-msm8926-htc-memul.dtb \
 +	qcom-msm8926-microsoft-superman-lte.dtb \
 +	qcom-msm8926-microsoft-tesla.dtb \
  	qcom-msm8960-cdp.dtb \
  	qcom-msm8960-samsung-expressatt.dtb \
  	qcom-msm8974-lge-nexus5-hammerhead.dtb \
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/69f0414c/attachment.sig>

From sfr at canb.auug.org.au  Sun Dec  3 15:08:48 2023
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Mon, 4 Dec 2023 10:08:48 +1100
Subject: linux-next: manual merge of the qcom tree with the arm-soc tree
Message-ID: <20231204100848.141cfd29@canb.auug.org.au>

Hi all,

Today's linux-next merge of the qcom tree got a conflict in:

  arch/arm/boot/dts/qcom/qcom-msm8974.dtsi

between commit:

  4960e06d386e ("ARM: dts: qcom: msm8974: sort nodes by reg")

from the arm-soc tree and commit:

  95053f6bc8ff ("ARM: dts: qcom: msm8974: Add watchdog node")

from the qcom tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
index 76006c3c4af2,f7d7e5d70f30..000000000000
--- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
@@@ -346,12 -346,14 +346,20 @@@
  			reg = <0xf9011000 0x1000>;
  		};
  
 +		saw_l2: power-controller at f9012000 {
 +			compatible = "qcom,saw2";
 +			reg = <0xf9012000 0x1000>;
 +			regulator;
 +		};
 +
+ 		watchdog at f9017000 {
+ 			compatible = "qcom,apss-wdt-msm8974", "qcom,kpss-wdt";
+ 			reg = <0xf9017000 0x1000>;
+ 			interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>,
+ 				     <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>;
+ 			clocks = <&sleep_clk>;
+ 		};
+ 
  		timer at f9020000 {
  			#address-cells = <1>;
  			#size-cells = <1>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/8ccbc275/attachment.sig>

From apopple at nvidia.com  Sun Dec  3 15:20:10 2023
From: apopple at nvidia.com (Alistair Popple)
Date: Mon, 04 Dec 2023 10:20:10 +1100
Subject: [PATCH v2 14/14] arm64/mm: Add ptep_get_and_clear_full() to
 optimize process teardown
In-Reply-To: <9631b5bd-1d10-40bf-b4eb-9df33b9a0680@arm.com>
References: <20231115163018.1303287-1-ryan.roberts@arm.com>
 <20231115163018.1303287-15-ryan.roberts@arm.com>
 <87fs0xxd5g.fsf@nvdebian.thelocal>
 <3b4f6bff-6322-4394-9efb-9c3b9ef52010@arm.com>
 <87y1eovsn5.fsf@nvdebian.thelocal>
 <8fca9ed7-f916-4abe-8284-6e3c9fa33a8c@arm.com>
 <87wmu3pro8.fsf@nvdebian.thelocal>
 <26c78fee-4b7a-4d73-9f8b-2e25bbae20e8@arm.com>
 <87o7fepdun.fsf@nvdebian.thelocal>
 <b4906e1e-8009-4097-8d17-642374a049fe@arm.com>
 <b6d4b33b-6224-444f-9542-d3cb95afd382@arm.com>
 <87leafg768.fsf@nvdebian.thelocal>
 <9631b5bd-1d10-40bf-b4eb-9df33b9a0680@arm.com>
Message-ID: <877cluc1qi.fsf@nvdebian.thelocal>


Ryan Roberts <ryan.roberts at arm.com> writes:

> On 30/11/2023 05:07, Alistair Popple wrote:
>> 
>> Ryan Roberts <ryan.roberts at arm.com> writes:
>> 
>>>>>> So if we do need to deal with racing HW, I'm pretty sure my v1 implementation is
>>>>>> buggy because it iterated through the PTEs, getting and accumulating. Then
>>>>>> iterated again, writing that final set of bits to all the PTEs. And the HW could
>>>>>> have modified the bits during those loops. I think it would be possible to fix
>>>>>> the race, but intuition says it would be expensive.
>>>>>
>>>>> So the issue as I understand it is subsequent iterations would see a
>>>>> clean PTE after the first iteration returned a dirty PTE. In
>>>>> ptep_get_and_clear_full() why couldn't you just copy the dirty/accessed
>>>>> bit (if set) from the PTE being cleared to an adjacent PTE rather than
>>>>> all the PTEs?
>>>>
>>>> The raciness I'm describing is the race between reading access/dirty from one
>>>> pte and applying it to another. But yes I like your suggestion. if we do:
>>>>
>>>> pte = __ptep_get_and_clear_full(ptep)
>>>>
>>>> on the target pte, then we have grabbed access/dirty from it in a race-free
>>>> manner. we can then loop from current pte up towards the top of the block until
>>>> we find a valid entry (and I guess wrap at the top to make us robust against
>>>> future callers clearing an an arbitrary order). Then atomically accumulate the
>>>> access/dirty bits we have just saved into that new entry. I guess that's just a
>>>> cmpxchg loop - there are already examples of how to do that correctly when
>>>> racing the TLB.
>>>>
>>>> For most entries, we will just be copying up to the next pte. For the last pte,
>>>> we would end up reading all ptes and determine we are the last one.
>>>>
>>>> What do you think?
>>>
>>> OK here is an attempt at something which solves the fragility. I think this is
>>> now robust and will always return the correct access/dirty state from
>>> ptep_get_and_clear_full() and ptep_get().
>>>
>>> But I'm not sure about performance; each call to ptep_get_and_clear_full() for
>>> each pte in a contpte block will cause a ptep_get() to gather the access/dirty
>>> bits from across the contpte block - which requires reading each pte in the
>>> contpte block. So its O(n^2) in that sense. I'll benchmark it and report back.
>>>
>>> Was this the type of thing you were thinking of, Alistair?
>> 
>> Yes, that is along the lines of what I was thinking. However I have
>> added a couple of comments inline. 
>> 
>>> --8<--
>>>  arch/arm64/include/asm/pgtable.h | 23 ++++++++-
>>>  arch/arm64/mm/contpte.c          | 81 ++++++++++++++++++++++++++++++++
>>>  arch/arm64/mm/fault.c            | 38 +++++++++------
>>>  3 files changed, 125 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>> index 9bd2f57a9e11..6c295d277784 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -851,6 +851,7 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
>>>  	return pte_pmd(pte_modify(pmd_pte(pmd), newprot));
>>>  }
>>>
>>> +extern int __ptep_set_access_flags_notlbi(pte_t *ptep, pte_t entry);
>>>  extern int __ptep_set_access_flags(struct vm_area_struct *vma,
>>>  				 unsigned long address, pte_t *ptep,
>>>  				 pte_t entry, int dirty);
>>> @@ -1145,6 +1146,8 @@ extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
>>>  extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
>>>  extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>>>  				pte_t *ptep, pte_t pte, unsigned int nr);
>>> +extern pte_t contpte_ptep_get_and_clear_full(struct mm_struct *mm,
>>> +				unsigned long addr, pte_t *ptep);
>>>  extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>>  				unsigned long addr, pte_t *ptep);
>>>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>>> @@ -1270,12 +1273,28 @@ static inline void pte_clear(struct mm_struct *mm,
>>>  	__pte_clear(mm, addr, ptep);
>>>  }
>>>
>>> +#define __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL
>>> +static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,
>>> +				unsigned long addr, pte_t *ptep, int full)
>>> +{
>>> +	pte_t orig_pte = __ptep_get(ptep);
>>> +
>>> +	if (!pte_valid_cont(orig_pte))
>>> +		return __ptep_get_and_clear(mm, addr, ptep);
>>> +
>>> +	if (!full) {
>>> +		contpte_try_unfold(mm, addr, ptep, orig_pte);
>>> +		return __ptep_get_and_clear(mm, addr, ptep);
>>> +	}
>>> +
>>> +	return contpte_ptep_get_and_clear_full(mm, addr, ptep);
>>> +}
>>> +
>>>  #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
>>>  static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
>>>  				unsigned long addr, pte_t *ptep)
>>>  {
>>> -	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>>> -	return __ptep_get_and_clear(mm, addr, ptep);
>>> +	return ptep_get_and_clear_full(mm, addr, ptep, 0);
>>>  }
>>>
>>>  #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
>>> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
>>> index 2a57df16bf58..99b211118d93 100644
>>> --- a/arch/arm64/mm/contpte.c
>>> +++ b/arch/arm64/mm/contpte.c
>>> @@ -145,6 +145,14 @@ pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte)
>>>  	for (i = 0; i < CONT_PTES; i++, ptep++) {
>>>  		pte = __ptep_get(ptep);
>>>
>>> +		/*
>>> +		 * Deal with the partial contpte_ptep_get_and_clear_full() case,
>>> +		 * where some of the ptes in the range may be cleared but others
>>> +		 * are still to do. See contpte_ptep_get_and_clear_full().
>>> +		 */
>>> +		if (!pte_valid(pte))
>>> +			continue;
>>> +
>>>  		if (pte_dirty(pte))
>>>  			orig_pte = pte_mkdirty(orig_pte);
>>>
>>> @@ -257,6 +265,79 @@ void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>>>  }
>>>  EXPORT_SYMBOL(contpte_set_ptes);
>>>
>>> +pte_t contpte_ptep_get_and_clear_full(struct mm_struct *mm,
>>> +					unsigned long addr, pte_t *ptep)
>>> +{
>>> +	/*
>>> +	 * When doing a full address space teardown, we can avoid unfolding the
>>> +	 * contiguous range, and therefore avoid the associated tlbi. Instead,
>>> +	 * just get and clear the pte. The caller is promising to call us for
>>> +	 * every pte, so every pte in the range will be cleared by the time the
>>> +	 * final tlbi is issued.
>>> +	 *
>>> +	 * This approach requires some complex hoop jumping though, as for the
>>> +	 * duration between returning from the first call to
>>> +	 * ptep_get_and_clear_full() and making the final call, the contpte
>>> +	 * block is in an intermediate state, where some ptes are cleared and
>>> +	 * others are still set with the PTE_CONT bit. If any other APIs are
>>> +	 * called for the ptes in the contpte block during that time, we have to
>>> +	 * be very careful. The core code currently interleaves calls to
>>> +	 * ptep_get_and_clear_full() with ptep_get() and so ptep_get() must be
>>> +	 * careful to ignore the cleared entries when accumulating the access
>>> +	 * and dirty bits - the same goes for ptep_get_lockless(). The only
>>> +	 * other calls we might resonably expect are to set markers in the
>>> +	 * previously cleared ptes. (We shouldn't see valid entries being set
>>> +	 * until after the tlbi, at which point we are no longer in the
>>> +	 * intermediate state). Since markers are not valid, this is safe;
>>> +	 * set_ptes() will see the old, invalid entry and will not attempt to
>>> +	 * unfold. And the new pte is also invalid so it won't attempt to fold.
>>> +	 * We shouldn't see pte markers being set for the 'full' case anyway
>>> +	 * since the address space is being torn down.
>>> +	 *
>>> +	 * The last remaining issue is returning the access/dirty bits. That
>>> +	 * info could be present in any of the ptes in the contpte block.
>>> +	 * ptep_get() will gather those bits from across the contpte block (for
>>> +	 * the remaining valid entries). So below, if the pte we are clearing
>>> +	 * has dirty or young set, we need to stash it into a pte that we are
>>> +	 * yet to clear. This allows future calls to return the correct state
>>> +	 * even when the info was stored in a different pte. Since the core-mm
>>> +	 * calls from low to high address, we prefer to stash in the last pte of
>>> +	 * the contpte block - this means we are not "dragging" the bits up
>>> +	 * through all ptes and increases the chances that we can exit early
>>> +	 * because a given pte will have neither dirty or young set.
>>> +	 */
>>> +
>>> +	pte_t orig_pte = __ptep_get_and_clear(mm, addr, ptep);
>>> +	bool dirty = pte_dirty(orig_pte);
>>> +	bool young = pte_young(orig_pte);
>>> +	pte_t *start;
>>> +
>>> +	if (!dirty && !young)
>>> +		return contpte_ptep_get(ptep, orig_pte);
>> 
>> I don't think we need to do this. If the PTE is !dirty && !young we can
>> just return it. As you say we have to assume HW can set those flags at
>> any time anyway so it doesn't get us much. This means in the common case
>> we should only run through the loop setting the dirty/young flags once
>> which should alay the performance concerns.
>
> I don't follow your logic. This is precisely the problem I was trying to solve
> vs my original (simple) attempt - we want to always report the correct
> access/dirty info. If we read one of the PTEs and neither access nor dirty are
> set, that doesn't mean its old and clean, it just means that that info is
> definitely not stored in this PTE - we need to check the others. (when the
> contiguous bit is set, the HW will only update the access/dirty bits for 1 of
> the PTEs in the contpte block).

So my concern wasn't about incorrectly returning a !young && !dirty PTE
when the CONT_PTE block was *previously* clean/old (ie. the first
ptep_get/ptep_get_and_clear_full returned clean/old) because we have to
tolerate that anyway due to HW being able to set those bits. Rather my
concern was ptep_get_and_clear_full() could implicitly clear dirty/young
bits - ie. ptep_get_and_clear_full() could return a dirty/young PTE but
the next call would not.

That's because regardless of what we do here it is just a matter of
timing if we have to assume other HW threads can set these bits at any
time. There is nothing stopping HW from doing that just after we read
them in that loop, so a block can always become dirty/young at any time.
However it shouldn't become !dirty/!young without explicit SW
intervention.

But this is all a bit of a moot point due to the discussion below.

> Also, IIRC correctly, the core-mm sets access when initially setting up the
> mapping so its not guarranteed that all but one of the PTEs in the contpte block
> have (!dirty && !young).
>
>> 
>> However I am now wondering if we're doing the wrong thing trying to hide
>> this down in the arch layer anyway. Perhaps it would be better to deal
>> with this in the core-mm code after all.
>> 
>> So how about having ptep_get_and_clear_full() clearing the PTEs for the
>> entire cont block? We know by definition all PTEs should be pointing to
>> the same folio anyway, and it seems at least zap_pte_range() would cope
>> with this just fine because subsequent iterations would just see
>> pte_none() and continue the loop. I haven't checked the other call sites
>> though, but in principal I don't see why we couldn't define
>> ptep_get_and_clear_full() as being something that clears all PTEs
>> mapping a given folio (although it might need renaming).
>
> Ahha! Yes, I've been working on a solution like this since Barry raised it
> yesterday. I have a working version, that seems to perform well. I wouldn't want
> to just clear all the PTEs in the block inside ptep_get_and_clear_full() because
> although it might work today, its fragile in the same way that my v2 version is.

Yes, agree a new helper would be needed.

> Instead, I've defined a new helper, clear_ptes(), which takes a starting pte and
> a number of ptes to clear (like set_ptes()). It returns the PTE read from the
> *first* slot, but with the access/dirty bits being accumulated from all of the
> ptes in the requested batch. Then zap_pte_range() is reworked to find
> appropriate batches (similar to how I've reworked for ptep_set_wrprotects()).
>
> I was trying to avoid introducing new helpers, but I think this is the most
> robust approach, and looks slightly more performant to, on first sight. It also
> addresses cases where full=0, which Barry says are important for madvise(DONTNEED).

I strongly agree with this approach now especially if it is equally (or
more!) performant. I get why you didn't want to intorduce new helpers
but I think doing so was making things too subtle so would like to see
this.

>> 
>> This does assume you don't need to partially unmap a page in
>> zap_pte_range (ie. end >= folio), but we're already making that
>> assumption.
>
> That's fine for full=1. But we can't make that assumption for full=0. If a VMA
> gets split for a reason that doesn't require re-setting the PTEs then a contpte
> block could straddle 2 VMAs. But the solution I describe above is robust to that.
>
> I'll finish gathering perf data then post for all 3 approaches; v2 as originally
> posted, "robust ptep_get_and_clear_full()", and clear_ptes(). Hopefully later today.

Thanks!

>> 
>>> +
>>> +	start = contpte_align_down(ptep);
>>> +	ptep = start + CONT_PTES - 1;
>>> +
>>> +	for (; ptep >= start; ptep--) {
>>> +		pte_t pte = __ptep_get(ptep);
>>> +
>>> +		if (!pte_valid(pte))
>>> +			continue;
>>> +
>>> +		if (dirty)
>>> +			pte = pte_mkdirty(pte);
>>> +
>>> +		if (young)
>>> +			pte = pte_mkyoung(pte);
>>> +
>>> +		__ptep_set_access_flags_notlbi(ptep, pte);
>>> +		return contpte_ptep_get(ptep, orig_pte);
>>> +	}
>>> +
>>> +	return orig_pte;
>>> +}
>>> +EXPORT_SYMBOL(contpte_ptep_get_and_clear_full);
>>> +
>>>  int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>>  					unsigned long addr, pte_t *ptep)
>>>  {
>>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>>> index d63f3a0a7251..b22216a8153c 100644
>>> --- a/arch/arm64/mm/fault.c
>>> +++ b/arch/arm64/mm/fault.c
>>> @@ -199,19 +199,7 @@ static void show_pte(unsigned long addr)
>>>  	pr_cont("\n");
>>>  }
>>>
>>> -/*
>>> - * This function sets the access flags (dirty, accessed), as well as write
>>> - * permission, and only to a more permissive setting.
>>> - *
>>> - * It needs to cope with hardware update of the accessed/dirty state by other
>>> - * agents in the system and can safely skip the __sync_icache_dcache() call as,
>>> - * like __set_ptes(), the PTE is never changed from no-exec to exec here.
>>> - *
>>> - * Returns whether or not the PTE actually changed.
>>> - */
>>> -int __ptep_set_access_flags(struct vm_area_struct *vma,
>>> -			    unsigned long address, pte_t *ptep,
>>> -			    pte_t entry, int dirty)
>>> +int __ptep_set_access_flags_notlbi(pte_t *ptep, pte_t entry)
>>>  {
>>>  	pteval_t old_pteval, pteval;
>>>  	pte_t pte = __ptep_get(ptep);
>>> @@ -238,10 +226,30 @@ int __ptep_set_access_flags(struct vm_area_struct *vma,
>>>  		pteval = cmpxchg_relaxed(&pte_val(*ptep), old_pteval, pteval);
>>>  	} while (pteval != old_pteval);
>>>
>>> +	return 1;
>>> +}
>>> +
>>> +/*
>>> + * This function sets the access flags (dirty, accessed), as well as write
>>> + * permission, and only to a more permissive setting.
>>> + *
>>> + * It needs to cope with hardware update of the accessed/dirty state by other
>>> + * agents in the system and can safely skip the __sync_icache_dcache() call as,
>>> + * like __set_ptes(), the PTE is never changed from no-exec to exec here.
>>> + *
>>> + * Returns whether or not the PTE actually changed.
>>> + */
>>> +int __ptep_set_access_flags(struct vm_area_struct *vma,
>>> +			    unsigned long address, pte_t *ptep,
>>> +			    pte_t entry, int dirty)
>>> +{
>>> +	int changed = __ptep_set_access_flags_notlbi(ptep, entry);
>>> +
>>>  	/* Invalidate a stale read-only entry */
>>> -	if (dirty)
>>> +	if (changed && dirty)
>>>  		flush_tlb_page(vma, address);
>>> -	return 1;
>>> +
>>> +	return changed;
>>>  }
>>>
>>>  static bool is_el1_instruction_abort(unsigned long esr)
>>> --8<--
>> 



From sfr at canb.auug.org.au  Sun Dec  3 15:30:08 2023
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Mon, 4 Dec 2023 10:30:08 +1100
Subject: linux-next: build failure after merge of the qcom tree
Message-ID: <20231204103008.7c9d1e68@canb.auug.org.au>

Hi all,

After merging the qcom tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-dempsey.dts:11:
arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-common.dtsi:12:10: fatal error: qcom-pm8226.dtsi: No such file or directory
   12 | #include "qcom-pm8226.dtsi"
      |          ^~~~~~~~~~~~~~~~~~
In file included from arch/arm/boot/dts/qcom/qcom-msm8926-microsoft-superman-lte.dts:11:
arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-common.dtsi:12:10: fatal error: qcom-pm8226.dtsi: No such file or directory
   12 | #include "qcom-pm8226.dtsi"
      |          ^~~~~~~~~~~~~~~~~~
arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts:9:10: fatal error: qcom-pm8226.dtsi: No such file or directory
    9 | #include "qcom-pm8226.dtsi"
      |          ^~~~~~~~~~~~~~~~~~
In file included from arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-makepeace.dts:11:
arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-common.dtsi:12:10: fatal error: qcom-pm8226.dtsi: No such file or directory
   12 | #include "qcom-pm8226.dtsi"
      |          ^~~~~~~~~~~~~~~~~~
In file included from arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-moneypenny.dts:11:
arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-common.dtsi:12:10: fatal error: qcom-pm8226.dtsi: No such file or directory
   12 | #include "qcom-pm8226.dtsi"
      |          ^~~~~~~~~~~~~~~~~~
In file included from arch/arm/boot/dts/qcom/qcom-msm8926-microsoft-tesla.dts:11:
arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-common.dtsi:12:10: fatal error: qcom-pm8226.dtsi: No such file or directory
   12 | #include "qcom-pm8226.dtsi"
      |          ^~~~~~~~~~~~~~~~~~

Caused by commit

  455a4c46e023 ("ARM: dts: qcom: strip prefix from PMIC files")

interacting with commits

  244281556a11 ("ARM: dts: qcom: add common dt for MSM8x26 Lumias along with Nokia Lumia 630")

from the arm-soc tree.

Since I have reverted the gcom tree for another build failure today,
I will fix this up tomorrow.

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/ba6d48b8/attachment.sig>

From xiaobo55x at gmail.com  Sun Dec  3 18:42:24 2023
From: xiaobo55x at gmail.com (Haibo Xu)
Date: Mon, 4 Dec 2023 10:42:24 +0800
Subject: [PATCH v3 9/9] KVM: riscv: selftests: Add sstc timer test
In-Reply-To: <CAJve8onhY534T=Hyncjfi4GfdZ+0D2xM+jRSaYCAWCdaKxPUcQ@mail.gmail.com>
References: <cover.1694421911.git.haibo1.xu@intel.com> <64e0637cd6f22dd7557ed44bd2242001e7830d1c.1694421911.git.haibo1.xu@intel.com>
 <20230914-d2e594e7d84503ad14036e2d@orel> <CAJve8onhY534T=Hyncjfi4GfdZ+0D2xM+jRSaYCAWCdaKxPUcQ@mail.gmail.com>
Message-ID: <CAJve8omitHDpijJaLV_wHk+5LXpsBUWF8_eTD4MeWKM-807Siw@mail.gmail.com>

On Fri, Sep 15, 2023 at 2:21?PM Haibo Xu <xiaobo55x at gmail.com> wrote:
>
> On Thu, Sep 14, 2023 at 5:52?PM Andrew Jones <ajones at ventanamicro.com> wrote:
> >
> > On Thu, Sep 14, 2023 at 09:37:03AM +0800, Haibo Xu wrote:
> > > Add a KVM selftests to validate the Sstc timer functionality.
> > > The test was ported from arm64 arch timer test.
> >
> > I just tried this test out. Running it over and over again on QEMU I see
> > it works sometimes, but it frequently fails with the
> > GUEST_ASSERT_EQ(config_iter + 1, irq_iter) assert and at least once I
> > also saw the __GUEST_ASSERT(xcnt >= cmp) assert.
> >
>
> Good catch!
>
> I can also reproduce this issue and it is a common problem for both
> arm64 and riscv because it also happens in a arm64 Qemu VM.
>
> It seems like a synchronization issue between host and guest shared
> variables. Will double check the test code.
>
> > Thanks,
> > drew

Hi Andrew,

After several rounds of regression testing, some findings:
1. The intermittent failure also happened on ARM64 Qemu VM, and even
in the initial arch_timer commit(4959d8650e9f4).
2. it didn't happen on a ARM64 HW(but a different failure occured
during stress test)
3. The failure have a close relationship with
TIMER_TEST_ERR_MARGIN_US(default 100), and after increasing
     the macro to 300, the failure couldn't reproduced in 1000 loops
stress test in RISC-V Qemu VM

So my suggestion is we can expose the TIMER_TEST_ERR_MARGIN_US
parameter as an arch_timer test arg parameter
and tune it based on a specific test environment.

What's your opinion?

Regards,
Haibo


From peter.wang at mediatek.com  Sun Dec  3 18:53:10 2023
From: peter.wang at mediatek.com (=?utf-8?B?UGV0ZXIgV2FuZyAo546L5L+h5Y+LKQ==?=)
Date: Mon, 4 Dec 2023 02:53:10 +0000
Subject: [PATCH v8 01/10] scsi: ufs: host: Rename structure ufs_dev_params
 to ufs_host_params
In-Reply-To: <1701520577-31163-2-git-send-email-quic_cang@quicinc.com>
References: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
	 <1701520577-31163-2-git-send-email-quic_cang@quicinc.com>
Message-ID: <25ad8cd317c417031c52beac8b673d953db5e56f.camel@mediatek.com>

On Sat, 2023-12-02 at 04:36 -0800, Can Guo wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  Structure ufs_dev_params is actually used in UFS host vendor drivers
> to
> declare host specific power mode parameters, like ufs_<vendor>_params
> or
> host_cap, which makes the code not very straightforward to read.
> Rename the
> structure ufs_dev_params to ufs_host_params and unify the
> declarations in
> all vendor drivers to host_params.
> 
> In addition, rename the two functions ufshcd_init_pwr_dev_param() and
> ufshcd_get_pwr_dev_param() which work based on the ufs_host_params to
> ufshcd_init_host_params() and ufshcd_negotiate_pwr_params()
> respectively to
> avoid confusions.
> 
> This change does not change any functionalities or logic.
> 

Reviewed-by: Peter Wang <peter.wang at mediatek.com>


From thiago.bauermann at linaro.org  Sun Dec  3 19:01:49 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Mon, 04 Dec 2023 00:01:49 -0300
Subject: [PATCH v7 13/39] arm64/mm: Map pages for guarded control stack
In-Reply-To: <20231122-arm64-gcs-v7-13-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-13-201c483bd775@kernel.org>
Message-ID: <87a5qqisbm.fsf@linaro.org>


Hello,

Mark Brown <broonie at kernel.org> writes:

> diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
> index 645fe60d000f..605d4e6edc1d 100644
> --- a/arch/arm64/mm/mmap.c
> +++ b/arch/arm64/mm/mmap.c
> @@ -79,9 +79,20 @@ arch_initcall(adjust_protection_map);
>  
>  pgprot_t vm_get_page_prot(unsigned long vm_flags)
>  {
> -	pteval_t prot = pgprot_val(protection_map[vm_flags &
> +	pteval_t prot;
> +
> +	/* If this is a GCS then only interpret VM_WRITE. */
> +	if (system_supports_gcs() && (vm_flags & VM_SHADOW_STACK)) {
> +		if (vm_flags & VM_WRITE)
> +			prot = _PAGE_GCS;
> +		else
> +			prot = _PAGE_GCS_RO;
> +	} else {
> +		prot = pgprot_val(protection_map[vm_flags &
>  				   (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]);
> +	}
>  
> +	/* VM_ARM64_BTI on a GCS is rejected in arch_valdiate_flags() */

s/valdiate/validate/

>  	if (vm_flags & VM_ARM64_BTI)
>  		prot |= PTE_GP;


-- 
Thiago


From wenst at chromium.org  Sun Dec  3 19:50:53 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon, 4 Dec 2023 11:50:53 +0800
Subject: [PATCH v2 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <CAJMQK-iPT6p1izqQCHmJD2+E_RmnDKQfxsgMetnKtwNgLUmx1A@mail.gmail.com>
References: <20231201070719.1229447-1-wenst@chromium.org> <20231201070719.1229447-7-wenst@chromium.org>
 <CAJMQK-iPT6p1izqQCHmJD2+E_RmnDKQfxsgMetnKtwNgLUmx1A@mail.gmail.com>
Message-ID: <CAGXv+5EpgGhBGWupsQ9oFSyMr-QTma1O38XOPYj2fZ5mpOYYhg@mail.gmail.com>

On Sat, Dec 2, 2023 at 9:45?AM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
>
> On Fri, Dec 1, 2023 at 5:39?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >
> > Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> > Krabby design.
> >
> > Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> > convertible device with touchscreen and stylus.
> >
> > Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> > device. It does not have a touchscreen or stylus.
> >
> > The two devices both have two variants. The difference is a second
> > source touchpad controller that shares the same address as the original,
> > but is incompatible.
> >
> > The extra SKU IDs for the Tentacruel devices map to different sensor
> > components attached to the Embedded Controller. These are not visible
> > to the main processor.
> >
> > Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> > ---
> > Changes since v1:
> > - Reorder SKU numbers in descending order.
> > - Fixed pinconfig node names
> > - Moved pinctrl-* properties after interrupts-*
> > - Switched to interrupts-extended for external components
> > - Marked ADSP as explicitly disabled, with a comment explaining that it
> >   stalls the system
> > - Renamed "touchpad" to "trackpad"
> > - Dropped bogus "no-laneswap" property from it6505 node
> > - Moved "realtek,jd-src" property to after all the regulator supplies
> > - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> > - Renamed "vgpu" regulator name to allow coupling, with a comment
> >   containing the name used in the design
> > - Renamed "cr50" node name to "tpm"
> > - Moved trackpad_pins reference up to i2c2; workaround for second source
> >   component resource sharing.
> > - Fix copyright year
> > - Fixed touchscreen supply name
> >
> >  arch/arm64/boot/dts/mediatek/Makefile         |    4 +
> >  .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
> >  .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
> >  .../mt8186-corsola-tentacool-sku327683.dts    |   26 +
> >  .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
> >  .../mt8186-corsola-tentacruel-sku262148.dts   |   28 +
> >  .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
> >  7 files changed, 2007 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> > index e6e7592a3645..442af61b1305 100644
> > --- a/arch/arm64/boot/dts/mediatek/Makefile
>
> <snip>
>
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > new file mode 100644
> > index 000000000000..2e4d8df978c1
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > @@ -0,0 +1,26 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2023 Google LLC
> > + */
> > +
> > +#include "mt8186-corsola-tentacool-sku327681.dts"
> > +
> > +/ {
> > +       compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
> > +};
> > +
> > +/* This variant replaces only the touchpad controller. */
> > +&i2c2 {
> > +       /delete-node/ touchpad at 15;
>
> corsola.dtsi has this node named trackpad at 15.

Thanks for spotting the error. Fixed in the next version.

> > +
> > +       touchpad at 15 {
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&trackpad_pin>;

Pinctrl also dropped in the next version.

Same for mt8186-corsola-tentacruel-sku262148.dts.


Thanks
ChenYu

> > +               compatible = "hid-over-i2c";
> > +               reg = <0x15>;
> > +               interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > +               hid-descr-addr = <0x0001>;
> > +               vdd-supply = <&pp3300_s3>;
> > +               wakeup-source;
> > +       };
> > +};
>
> <snip>
>
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > new file mode 100644
> > index 000000000000..7841046084dc
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > @@ -0,0 +1,28 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2023 Google LLC
> > + */
> > +
> > +#include "mt8186-corsola-tentacruel-sku262144.dts"
> > +
> > +/ {
> > +       compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> > +                    "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> > +                    "google,tentacruel", "mediatek,mt8186";
> > +};
> > +
> > +/* This variant replaces only the touchpad controller. */
> > +&i2c2 {
> > +       /delete-node/ touchpad at 15;
> > +
>
> ditto.
>
> > +       touchpad at 15 {
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&trackpad_pin>;
> > +               compatible = "hid-over-i2c";
> > +               reg = <0x15>;
> > +               interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > +               hid-descr-addr = <0x0001>;
> > +               vdd-supply = <&pp3300_s3>;
> > +               wakeup-source;
> > +       };
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > new file mode 100644
> > index 000000000000..c5446b18783d
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > @@ -0,0 +1,1719 @@
>
> <snip>
>
> > +
> > +&i2c2 {
> > +       pinctrl-names = "default";
> > +       /*
> > +        * Trackpad pin put here to work around second source components
> > +        * sharing the pinmux
> > +        */
> > +       pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
> > +       clock-frequency = <400000>;
> > +       i2c-scl-internal-delay-ns = <10000>;
> > +       status = "okay";
> > +
> > +       trackpad at 15 {
> > +               compatible = "elan,ekth3000";
> > +               reg = <0x15>;
> > +               interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > +               vcc-supply = <&pp3300_s3>;
> > +               wakeup-source;
> > +       };
> > +};
> > +
>
> <snip>


From anshuman.khandual at arm.com  Sun Dec  3 20:03:56 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 4 Dec 2023 09:33:56 +0530
Subject: [PATCH V15 1/8] arm64/sysreg: Add BRBE registers and fields
In-Reply-To: <fd278f4e-0632-4474-8609-7711ad725f85@sirena.org.uk>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
 <20231201053906.1261704-2-anshuman.khandual@arm.com>
 <fd278f4e-0632-4474-8609-7711ad725f85@sirena.org.uk>
Message-ID: <86f91d68-207d-40a5-9d76-1cbb80e4f210@arm.com>



On 12/1/23 22:28, Mark Brown wrote:
> On Fri, Dec 01, 2023 at 11:08:59AM +0530, Anshuman Khandual wrote:
> 
> This looks good apart from a few small omissions:
> 
>> +SysregFields BRBINFx_EL1
> 
>> +Enum	13:8		TYPE
>> +	0b000000	UNCOND_DIRECT
>> +	0b000001	INDIRECT
>> +	0b000010	DIRECT_LINK
>> +	0b000011	INDIRECT_LINK
>> +	0b000101	RET
>> +	0b000111	ERET
>> +	0b001000	COND_DIRECT
>> +	0b100001	DEBUG_HALT
>> +	0b100010	CALL
>> +	0b100011	TRAP
>> +	0b100100	SERROR
>> +	0b100110	INSN_DEBUG
>> +	0b100111	DATA_DEBUG
>> +	0b101010	ALIGN_FAULT
>> +	0b101011	INSN_FAULT
>> +	0b101100	DATA_FAULT
>> +	0b101110	IRQ
>> +	0b101111	FIQ
>> +	0b111001	DEBUG_EXIT
>> +EndEnum
> 
> DDI0601 2023-09 also defines 0b110000 as an IMPLEMENTATION DEFINED
> exception to EL3.

Should this field be just IMPDEF or IMPDEF_TRAP_EL3 sounds better ?

> 
>> +SysregFields	BRBCR_ELx
>> +Res0	63:24
>> +Field	23 	EXCEPTION
>> +Field	22 	ERTN
>> +Res0	21:9
> 
> DDI0601 2023-09 defines bit 9 as FZPSS.

Sure, will update.

> 
>> +Sysreg	BRBINFINJ_EL1	2	1	9	1	0
> 
>> +Enum	13:8		TYPE
>> +	0b000000	UNCOND_DIRECT
>> +	0b000001	INDIRECT
>> +	0b000010	DIRECT_LINK
>> +	0b000011	INDIRECT_LINK
>> +	0b000101	RET
>> +	0b000111	ERET
>> +	0b001000	COND_DIRECT
>> +	0b100001	DEBUG_HALT
>> +	0b100010	CALL
>> +	0b100011	TRAP
>> +	0b100100	SERROR
>> +	0b100110	INSN_DEBUG
>> +	0b100111	DATA_DEBUG
>> +	0b101010	ALIGN_FAULT
>> +	0b101011	INSN_FAULT
>> +	0b101100	DATA_FAULT
>> +	0b101110	IRQ
>> +	0b101111	FIQ
>> +	0b111001	DEBUG_EXIT
>> +EndEnum
> 
> DDI0601 2023-09 also defines 0b11000 as IMPLEMENTATION DEFINED exception
> to EL3.

Should this field be just IMPDEF or IMPDEF_TRAP_EL3 sounds better ?

Seems like BRBINFx_EL1 could be used for defining BRBINFINJ_EL1 as well.


From u-kumar1 at ti.com  Sun Dec  3 20:09:37 2023
From: u-kumar1 at ti.com (Kumar, Udit)
Date: Mon, 4 Dec 2023 09:39:37 +0530
Subject: [PATCH v8 0/7] Add TPS6594 PMIC support on several boards
In-Reply-To: <20231128055230.342547-1-n-francis@ti.com>
References: <20231128055230.342547-1-n-francis@ti.com>
Message-ID: <2cbb60f0-3dfc-48f2-9b61-41adf14648c7@ti.com>


On 11/28/2023 11:22 AM, Neha Malcom Francis wrote:
> TPS6594 is a Power Management IC which provides regulators and others
> features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
> PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can
> communicate through the I2C or SPI interfaces.
> TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives.

Please consider adding bootph property in avs regulator node.

Thanks

Udit


> This series adds device tree nodes for TI TPS6594 PMICs found in the
> following boards:
> - J721EXSOMXEVM:
>    Link: https://www.ti.com/tool/J721EXSOMXEVM
> - J721S2XSOMXEVM:
>    Link: https://www.ti.com/tool/J721S2XSOMXEVM
> - J7200XSOMXEVM:
>    Link: https://www.ti.com/tool/J7200XSOMXEVM
> - J784S4XEVM
>    Link: https://www.ti.com/tool/J784S4XEVM
> - SK-AM69
>    Link: https://www.ti.com/tool/SK-AM69
> - SK-TDA4VM (J721E-SK)
>    Link: https://www.ti.com/tool/SK-TDA4VM
>
> Boot Logs with required config (DONOTMERGE patch) enabled:
> https://gist.github.com/nehamalcom/f47fcd6183360ed8a146c9ba456202c3
> Boot Logs without config enabled:
> https://gist.github.com/nehamalcom/58217b100e614ae55726f314e02b5001
>
> ---
> Changes from v7:
> https://lore.kernel.org/all/20231122104513.2335757-1-n-francis at ti.com/
> - (New Patches) Add support for SK boards that have TPS6594xx PMIC
>    present (J721E-SK and AM69-SK)
> - Add DONOTMERGE defconfig patch to show test logs
>
> Changes from v6:
> https://lore.kernel.org/all/20230810-tps6594-v6-0-2b2e2399e2ef at ti.com/
> - Modify patch series to include only patches not merged (J7)
> - Add boot logs for all affected boards
>
> Changes from v5:
> https://lore.kernel.org/all/20230809-tps6594-v5-0-485fd3d63670 at ti.com
> - Range-diff: http://0x0.st/H_fD.diff
> - Reword the patch fixing interrupt ranges for mcu domain gpio intr, and
>    add Fixes: tag
> - Also fix interrupt ranges for main domain gpio intr in the same patch
> - Change pinctrl node names to end in -pins to fix dtbs_check warnings
> - (New Patch) Enable TPS6594 in defconfig
>
> Changes from v4:
> https://lore.kernel.org/all/20230727130908.10656-1-eblanc at baylibre.com/
> - Range-diff: https://0x0.st/H_L7.diff
> - Rebased on top of linux-next
> - Fix min voltage on vdd_usb_3v3 regulator (ldo2) on j721e-som
> - Use 3-hex-digit format for pinctrl values
>
> Changes from v3:
> https://lore.kernel.org/all/20230417154832.216774-1-eblanc at baylibre.com/
> - Rebased on top of v6.5-rc1.
> - Change pinctrl number for irq pin as wkup_pmx0 was split on some boards.
> - Use already present wkup_i2c0 node instead of creating a new one.
>
> Changes from v2:
> https://lore.kernel.org/lkml/20230414112843.1358067-1-eblanc at baylibre.com/
> - Change node name as per Krzysztof review.
> - Add a fix for the interrupt range of wakeup gpio used by TPS6594 pmic
>    on J784S4.
>    The interruptions of the PMIC were not working before that.
> - Remove dependencies on other patch series as that was a mistake, see
>    https://lore.kernel.org/lkml/CRYY2V3HJ0CP.96JQ18PLZB3C at burritosblues/
>
> Changes from v1:
> https://lore.kernel.org/lkml/20230329142948.833800-1-eblanc at baylibre.com/
> - Harmonize regulators names across the different boards.
> - Adjust AVS voltage range.
> - Remove some outdated comments.
> - Add PMIC to J784S4 board.
> - Compatible string modified to match dt-bindings.
> - Add gpio-controller and gpio-cells properties.
>
> Esteban Blanc (2):
>    arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
>    arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs
>
> Jerome Neanne (2):
>    arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
>    arm64: dts: ti: k3-j784s4-evm: Add support for TPS6594 PMIC
>
> Neha Malcom Francis (3):
>    arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC
>    arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs
>    DONOTMERGE: arm64: defconfig: Enable TPS6594 PMIC for J7 devices
>
>   arch/arm64/boot/dts/ti/k3-am69-sk.dts        | 100 ++++++++++
>   arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi  | 157 +++++++++++++++
>   arch/arm64/boot/dts/ti/k3-j721e-sk.dts       | 154 ++++++++++++++
>   arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi  | 163 +++++++++++++++
>   arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 199 +++++++++++++++++++
>   arch/arm64/boot/dts/ti/k3-j784s4-evm.dts     | 104 ++++++++++
>   arch/arm64/configs/defconfig                 |   2 +-
>   7 files changed, 878 insertions(+), 1 deletion(-)
>


From n-francis at ti.com  Sun Dec  3 20:12:23 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Mon, 4 Dec 2023 09:42:23 +0530
Subject: [PATCH v8 0/7] Add TPS6594 PMIC support on several boards
In-Reply-To: <2cbb60f0-3dfc-48f2-9b61-41adf14648c7@ti.com>
References: <20231128055230.342547-1-n-francis@ti.com>
 <2cbb60f0-3dfc-48f2-9b61-41adf14648c7@ti.com>
Message-ID: <9eb2010a-5039-4b51-b0f6-5f92d6d80c9c@ti.com>

Hi Udit,

On 04/12/23 09:39, Kumar, Udit wrote:
> 
> On 11/28/2023 11:22 AM, Neha Malcom Francis wrote:
>> TPS6594 is a Power Management IC which provides regulators and others
>> features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
>> PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can
>> communicate through the I2C or SPI interfaces.
>> TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives.
> 
> Please consider adding bootph property in avs regulator node.
> 
> Thanks
> 
> Udit
> 

Thanks for catching that, I'll send out v9 with the bootph property added.

> 
>> This series adds device tree nodes for TI TPS6594 PMICs found in the
>> following boards:
>> - J721EXSOMXEVM:
>> ?? Link: https://www.ti.com/tool/J721EXSOMXEVM
>> - J721S2XSOMXEVM:
>> ?? Link: https://www.ti.com/tool/J721S2XSOMXEVM
>> - J7200XSOMXEVM:
>> ?? Link: https://www.ti.com/tool/J7200XSOMXEVM
>> - J784S4XEVM
>> ?? Link: https://www.ti.com/tool/J784S4XEVM
>> - SK-AM69
>> ?? Link: https://www.ti.com/tool/SK-AM69
>> - SK-TDA4VM (J721E-SK)
>> ?? Link: https://www.ti.com/tool/SK-TDA4VM
>>
>> Boot Logs with required config (DONOTMERGE patch) enabled:
>> https://gist.github.com/nehamalcom/f47fcd6183360ed8a146c9ba456202c3
>> Boot Logs without config enabled:
>> https://gist.github.com/nehamalcom/58217b100e614ae55726f314e02b5001
>>
>> ---
>> Changes from v7:
>> https://lore.kernel.org/all/20231122104513.2335757-1-n-francis at ti.com/
>> - (New Patches) Add support for SK boards that have TPS6594xx PMIC
>> ?? present (J721E-SK and AM69-SK)
>> - Add DONOTMERGE defconfig patch to show test logs
>>
>> Changes from v6:
>> https://lore.kernel.org/all/20230810-tps6594-v6-0-2b2e2399e2ef at ti.com/
>> - Modify patch series to include only patches not merged (J7)
>> - Add boot logs for all affected boards
>>
>> Changes from v5:
>> https://lore.kernel.org/all/20230809-tps6594-v5-0-485fd3d63670 at ti.com
>> - Range-diff: http://0x0.st/H_fD.diff
>> - Reword the patch fixing interrupt ranges for mcu domain gpio intr, and
>> ?? add Fixes: tag
>> - Also fix interrupt ranges for main domain gpio intr in the same patch
>> - Change pinctrl node names to end in -pins to fix dtbs_check warnings
>> - (New Patch) Enable TPS6594 in defconfig
>>
>> Changes from v4:
>> https://lore.kernel.org/all/20230727130908.10656-1-eblanc at baylibre.com/
>> - Range-diff: https://0x0.st/H_L7.diff
>> - Rebased on top of linux-next
>> - Fix min voltage on vdd_usb_3v3 regulator (ldo2) on j721e-som
>> - Use 3-hex-digit format for pinctrl values
>>
>> Changes from v3:
>> https://lore.kernel.org/all/20230417154832.216774-1-eblanc at baylibre.com/
>> - Rebased on top of v6.5-rc1.
>> - Change pinctrl number for irq pin as wkup_pmx0 was split on some boards.
>> - Use already present wkup_i2c0 node instead of creating a new one.
>>
>> Changes from v2:
>> https://lore.kernel.org/lkml/20230414112843.1358067-1-eblanc at baylibre.com/
>> - Change node name as per Krzysztof review.
>> - Add a fix for the interrupt range of wakeup gpio used by TPS6594 pmic
>> ?? on J784S4.
>> ?? The interruptions of the PMIC were not working before that.
>> - Remove dependencies on other patch series as that was a mistake, see
>> ?? https://lore.kernel.org/lkml/CRYY2V3HJ0CP.96JQ18PLZB3C at burritosblues/
>>
>> Changes from v1:
>> https://lore.kernel.org/lkml/20230329142948.833800-1-eblanc at baylibre.com/
>> - Harmonize regulators names across the different boards.
>> - Adjust AVS voltage range.
>> - Remove some outdated comments.
>> - Add PMIC to J784S4 board.
>> - Compatible string modified to match dt-bindings.
>> - Add gpio-controller and gpio-cells properties.
>>
>> Esteban Blanc (2):
>> ?? arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
>> ?? arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs
>>
>> Jerome Neanne (2):
>> ?? arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
>> ?? arm64: dts: ti: k3-j784s4-evm: Add support for TPS6594 PMIC
>>
>> Neha Malcom Francis (3):
>> ?? arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC
>> ?? arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs
>> ?? DONOTMERGE: arm64: defconfig: Enable TPS6594 PMIC for J7 devices
>>
>> ? arch/arm64/boot/dts/ti/k3-am69-sk.dts??????? | 100 ++++++++++
>> ? arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi? | 157 +++++++++++++++
>> ? arch/arm64/boot/dts/ti/k3-j721e-sk.dts?????? | 154 ++++++++++++++
>> ? arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi? | 163 +++++++++++++++
>> ? arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 199 +++++++++++++++++++
>> ? arch/arm64/boot/dts/ti/k3-j784s4-evm.dts???? | 104 ++++++++++
>> ? arch/arm64/configs/defconfig???????????????? |?? 2 +-
>> ? 7 files changed, 878 insertions(+), 1 deletion(-)
>>

-- 
Thanking You
Neha Malcom Francis


From dan.carpenter at linaro.org  Sun Dec  3 20:12:35 2023
From: dan.carpenter at linaro.org (Dan Carpenter)
Date: Mon, 4 Dec 2023 07:12:35 +0300
Subject: [PATCH] fix comparison of unsigned expression < 0
In-Reply-To: <CA+fCnZcLwXn6crGF1E1cY3TknMaUN=H8-_hp0-cC+s8-wj95PQ@mail.gmail.com>
References: <20231128075532.110251-1-haibo.li@mediatek.com>
 <20231128172238.f80ed8dd74ab2a13eba33091@linux-foundation.org>
 <CA+fCnZcLwXn6crGF1E1cY3TknMaUN=H8-_hp0-cC+s8-wj95PQ@mail.gmail.com>
Message-ID: <ecf38b22-ee64-41e5-b9b5-c32fc1cb57bc@moroto.mountain>

On Wed, Nov 29, 2023 at 04:01:47AM +0100, Andrey Konovalov wrote:
> On Wed, Nov 29, 2023 at 2:22?AM Andrew Morton <akpm at linux-foundation.org> wrote:
> >
> > On Tue, 28 Nov 2023 15:55:32 +0800 Haibo Li <haibo.li at mediatek.com> wrote:
> >
> > > Kernel test robot reported:
> > >
> > > '''
> > > mm/kasan/report.c:637 kasan_non_canonical_hook() warn:
> > > unsigned 'addr' is never less than zero.
> > > '''
> > > The KASAN_SHADOW_OFFSET is 0 on loongarch64.
> > >
> > > To fix it,check the KASAN_SHADOW_OFFSET before do comparison.
> > >
> > > --- a/mm/kasan/report.c
> > > +++ b/mm/kasan/report.c
> > > @@ -634,10 +634,10 @@ void kasan_non_canonical_hook(unsigned long addr)
> > >  {
> > >       unsigned long orig_addr;
> > >       const char *bug_type;
> > > -
> > > +#if KASAN_SHADOW_OFFSET > 0
> > >       if (addr < KASAN_SHADOW_OFFSET)
> > >               return;
> > > -
> > > +#endif
> >
> > We'd rather not add ugly ifdefs for a simple test like this.  If we
> > replace "<" with "<=", does it fix?  I suspect that's wrong.
> 
> Changing the comparison into "<=" would be wrong.
> 

I would say that changing it to <= is seldom the correct thing.  I've
wanted to make that trigger a warning as well.

> But I actually don't think we need to fix anything here.
> 
> This issue looks quite close to a similar comparison with 0 issue
> Linus shared his opinion on here:
> 
> https://lore.kernel.org/all/Pine.LNX.4.58.0411230958260.20993 at ppc970.osdl.org/
> 
> I don't know if the common consensus with the regard to issues like
> that changed since then. But if not, perhaps we can treat this kernel
> test robot report as a false positive.

I would say that the consensus has changed somewhere around 2015 or
so.  Unsigned comparisons to zero used to be one of the most common
types of bugs in new code but now almost all subsystems have turned on
the GCC warning for this.

However, this is a Smatch warning and I agree with Linus on this.  For
example, Smatch doesn't complain about the example code the Linus
mentioned.

	if (a < 0 || a > X)

And in this case, it's a one liner fix for me to add KASAN_SHADOW_OFFSET
as an allowed macro and silence the warning.

regards,
dan carpenter


From quic_obabatun at quicinc.com  Sun Dec  3 20:13:36 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 3 Dec 2023 20:13:36 -0800
Subject: [RFC PATCH v2 3/6] of: resevred_mem: Delay allocation of memory for dynamic regions
In-Reply-To: <20231204041339.9902-1-quic_obabatun@quicinc.com>
References: <20231204041339.9902-1-quic_obabatun@quicinc.com>
Message-ID: <20231204041339.9902-4-quic_obabatun@quicinc.com>

Defer the allocation of memory for the dynamically-placed reserved
memory regions until after the statically-placed reserved memory
regions have been reserved or marked as nomap in memblock.
This is to avoid allocating from regions that will later turn out to
have been reserved by other nodes.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/fdt.c             | 18 ++++++++++++++++--
 drivers/of/of_private.h      |  1 +
 drivers/of/of_reserved_mem.c |  1 -
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 34223c249914..46adce306bbd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -613,6 +613,8 @@ void __init fdt_scan_reserved_mem_reg_nodes(void)
 static int __init fdt_scan_reserved_mem(void)
 {
 	int node, child;
+	int dynamic_nodes_cnt = 0;
+	int dynamic_nodes[MAX_RESERVED_REGIONS];
 	const void *fdt = initial_boot_params;
 
 	node = fdt_path_offset(fdt, "/reserved-memory");
@@ -634,8 +636,20 @@ static int __init fdt_scan_reserved_mem(void)
 		uname = fdt_get_name(fdt, child, NULL);
 
 		err = __reserved_mem_reserve_reg(child, uname);
-		if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL))
-			__reserved_mem_alloc_size(child, uname);
+
+		if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL)) {
+			dynamic_nodes[dynamic_nodes_cnt] = child;
+			dynamic_nodes_cnt++;
+		}
+	}
+
+	for (int i = 0; i < dynamic_nodes_cnt; i++) {
+		const char *uname;
+
+		child = dynamic_nodes[i];
+		uname = fdt_get_name(fdt, child, NULL);
+
+		__reserved_mem_alloc_size(child, uname);
 	}
 	return 0;
 }
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index f38397c7b582..57694a704b00 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -36,6 +36,7 @@ struct alias_prop {
 #endif
 
 #define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+#define MAX_RESERVED_REGIONS    64
 
 extern struct mutex of_mutex;
 extern raw_spinlock_t devtree_lock;
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 8bd8bbc3aaec..d62f1956024c 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -26,7 +26,6 @@
 
 #include "of_private.h"
 
-#define MAX_RESERVED_REGIONS	64
 static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
 static int reserved_mem_count;
 
-- 
2.17.1



From quic_obabatun at quicinc.com  Sun Dec  3 20:13:39 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 3 Dec 2023 20:13:39 -0800
Subject: [RFC PATCH v2 6/6] of: reserved_mem: Make MAX_RESERVED_REGIONS a config option
In-Reply-To: <20231204041339.9902-1-quic_obabatun@quicinc.com>
References: <20231204041339.9902-1-quic_obabatun@quicinc.com>
Message-ID: <20231204041339.9902-7-quic_obabatun@quicinc.com>

Make the value of MAX_RESERVED_REGIONS a config option which can be
modified based on user requirements.
The reserved_mem_array is required during device bootup to store the
information of the dynamically-placed reserved memory regions.
After paging_init(), this information is transferred to another
array which is dynamically allocated and used to store all the reserved
memory regions.

There is currently no obvious way to free the memory for the static
array after its contents are copied over to the dynamically allocated
array, but since the size required for the reserved_mem_array can vary
from device to device depending on the number of dynamically-placed
reserved memory regions, make the size of the array configurable in an
attempt to save some memory.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/Kconfig      | 13 +++++++++++++
 drivers/of/of_private.h |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index da9826accb1b..409ce2527461 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -102,4 +102,17 @@ config OF_OVERLAY
 config OF_NUMA
 	bool
 
+config OF_MAX_RESERVED_REGIONS
+	int "OF resvered_mem array size"
+	default "64"
+	range 1 64
+	help
+	   The reserved_mem_array is used to store information about the dynamically
+	   placed reserved memory regions before we are able to allocate the memory
+	   needed to store all the reserved memory regions defined in the DT.
+	   Because the amount of memory needed initially for this array could vary,
+	   make the size of the reserved_mem_array configurable in an attempt to
+	   save some memory when possible.
+	   if unsure, leave as default value.
+
 endif # OF
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index ef56b2ea185c..278038bce0c0 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -36,7 +36,7 @@ struct alias_prop {
 #endif
 
 #define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-#define MAX_RESERVED_REGIONS    64
+#define MAX_RESERVED_REGIONS    CONFIG_OF_MAX_RESERVED_REGIONS
 
 extern struct mutex of_mutex;
 extern raw_spinlock_t devtree_lock;
-- 
2.17.1



From quic_obabatun at quicinc.com  Sun Dec  3 20:13:38 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 3 Dec 2023 20:13:38 -0800
Subject: [RFC PATCH v2 5/6] of: reserved_mem: Add code to dynamically allocate reserved_mem array
In-Reply-To: <20231204041339.9902-1-quic_obabatun@quicinc.com>
References: <20231204041339.9902-1-quic_obabatun@quicinc.com>
Message-ID: <20231204041339.9902-6-quic_obabatun@quicinc.com>

The reserved_mem array is statically allocated with a size of
MAX_RESERVED_REGIONS(64). Therefore, if the number of reserved_mem
regions exceeds this size, there will not be enough space to store
all the data.

Therefore, extend the use of the static array by introducing a
dynamically allocated array based on the number of reserved memory
regions specified in the DT.

Before paging_init() runs, the static array is used to store the
dynamically-placed regions.
After paging_init(), memory is dynamically allocated for the
reserved_mem array, and all entries from the static array is copied
over to the new array, and all other statically-placed regions are
added in as well.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/fdt.c             | 13 +++++++---
 drivers/of/of_private.h      |  1 +
 drivers/of/of_reserved_mem.c | 48 +++++++++++++++++++++++++++++++++---
 3 files changed, 55 insertions(+), 7 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 12769dd53c34..2f1eabbd6869 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -563,8 +563,8 @@ static int __init __reserved_mem_check_root(unsigned long node)
  */
 static int __init fdt_scan_reserved_mem(void)
 {
-	int node, child;
-	int dynamic_nodes_cnt = 0;
+	int node, child, err = 0;
+	int dynamic_nodes_cnt = 0, count = 0;
 	int dynamic_nodes[MAX_RESERVED_REGIONS];
 	const void *fdt = initial_boot_params;
 
@@ -579,7 +579,6 @@ static int __init fdt_scan_reserved_mem(void)
 
 	fdt_for_each_subnode(child, fdt, node) {
 		const char *uname;
-		int err;
 
 		if (!of_fdt_device_is_available(fdt, child))
 			continue;
@@ -587,6 +586,8 @@ static int __init fdt_scan_reserved_mem(void)
 		uname = fdt_get_name(fdt, child, NULL);
 
 		err = __reserved_mem_reserve_reg(child, uname);
+		if (!err)
+			count++;
 
 		if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL)) {
 			dynamic_nodes[dynamic_nodes_cnt] = child;
@@ -600,8 +601,12 @@ static int __init fdt_scan_reserved_mem(void)
 		child = dynamic_nodes[i];
 		uname = fdt_get_name(fdt, child, NULL);
 
-		__reserved_mem_alloc_size(child, uname);
+		err = __reserved_mem_alloc_size(child, uname);
+		if (!err)
+			count++;
 	}
+	update_reserved_mem_max_cnt(count);
+
 	return 0;
 }
 
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 575e2b4119e0..ef56b2ea185c 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -179,5 +179,6 @@ static inline struct device_node *__of_get_dma_parent(const struct device_node *
 void init_reserved_mem(void);
 void dt_reserved_mem_save_node(struct device_node *node, const char *uname,
 			       phys_addr_t base, phys_addr_t size);
+void update_reserved_mem_max_cnt(int max_count);
 
 #endif /* _LINUX_OF_PRIVATE_H */
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 2ef9edcb8c93..01cd6a571dc2 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -26,7 +26,9 @@
 
 #include "of_private.h"
 
-static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
+static struct reserved_mem reserved_mem_array[MAX_RESERVED_REGIONS];
+static struct reserved_mem *reserved_mem = reserved_mem_array;
+static int total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
 static int reserved_mem_count;
 
 static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
@@ -54,6 +56,42 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
 	return err;
 }
 
+void __init update_reserved_mem_max_cnt(int max_count)
+{
+	total_reserved_mem_cnt = max_count;
+}
+
+static int alloc_reserved_mem_array(void)
+{
+	struct reserved_mem *new_array;
+	size_t alloc_size, copy_size, memset_size;
+
+	alloc_size = array_size(total_reserved_mem_cnt, sizeof(*new_array));
+	if (alloc_size == SIZE_MAX)
+		return -1;
+
+	new_array = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
+	if (!new_array)
+		return -ENOMEM;
+
+	copy_size = array_size(reserved_mem_count, sizeof(*new_array));
+	if (copy_size == SIZE_MAX)
+		goto overlow_err;
+
+	memset_size = alloc_size - copy_size;
+
+	memcpy(new_array, reserved_mem, copy_size);
+	memset(new_array + reserved_mem_count, 0, memset_size);
+
+	reserved_mem = new_array;
+	return 0;
+
+overlow_err:
+	memblock_free(new_array, alloc_size);
+	total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
+	return -1;
+}
+
 /*
  * dt_reserved_mem_save_node() - save dt node for second pass initialization
  */
@@ -62,7 +100,7 @@ void __init dt_reserved_mem_save_node(struct device_node *node, const char *unam
 {
 	struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
 
-	if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
+	if (reserved_mem_count == total_reserved_mem_cnt) {
 		pr_err("not enough space for all defined regions.\n");
 		return;
 	}
@@ -346,7 +384,11 @@ static void __init __rmem_check_for_overlap(void)
  */
 void __init init_reserved_mem(void)
 {
-	int i;
+	int i, ret;
+
+	ret = alloc_reserved_mem_array();
+	if (ret)
+		pr_err("Failed to allocate memory for reserved_mem array with err: %d", ret);
 
 	scan_reserved_mem_reg_nodes();
 
-- 
2.17.1



From quic_obabatun at quicinc.com  Sun Dec  3 20:13:37 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 3 Dec 2023 20:13:37 -0800
Subject: [RFC PATCH v2 4/6] of: reserved_mem: Add code to use unflattened DT for reserved_mem nodes
In-Reply-To: <20231204041339.9902-1-quic_obabatun@quicinc.com>
References: <20231204041339.9902-1-quic_obabatun@quicinc.com>
Message-ID: <20231204041339.9902-5-quic_obabatun@quicinc.com>

The unflattened devicetree APIs are available to be used right after
paging_init() runs. Therefore, use the unflattened devicetree APIs to
process the reserved memory regions from this point.

Using the unflattened devicetree APIs is more efficient than using the
flattened devicetree APIs.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/fdt.c                | 51 +--------------------
 drivers/of/of_private.h         |  4 +-
 drivers/of/of_reserved_mem.c    | 79 +++++++++++++++++++++++++--------
 include/linux/of_fdt.h          |  1 -
 include/linux/of_reserved_mem.h |  2 +-
 kernel/dma/coherent.c           |  4 +-
 kernel/dma/contiguous.c         |  8 ++--
 kernel/dma/swiotlb.c            | 10 ++---
 8 files changed, 76 insertions(+), 83 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 46adce306bbd..12769dd53c34 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -558,55 +558,6 @@ static int __init __reserved_mem_check_root(unsigned long node)
 	return 0;
 }
 
-/*
- * Save the reserved_mem reg nodes in the reserved_mem array
- */
-void __init fdt_scan_reserved_mem_reg_nodes(void)
-
-{
-	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
-	const void *fdt = initial_boot_params;
-	phys_addr_t base, size;
-	const __be32 *prop;
-	int node, child;
-	int len;
-
-	node = fdt_path_offset(fdt, "/reserved-memory");
-	if (node < 0) {
-		pr_err("Reserved memory: Did not find reserved-memory node\n");
-		return;
-	}
-
-	if (__reserved_mem_check_root(node) != 0) {
-		pr_err("Reserved memory: unsupported node format, ignoring\n");
-		return;
-	}
-
-	fdt_for_each_subnode(child, fdt, node) {
-		const char *uname;
-
-		prop = of_get_flat_dt_prop(child, "reg", &len);
-		if (!prop)
-			continue;
-
-		if (!of_fdt_device_is_available(fdt, child))
-			continue;
-
-		uname = fdt_get_name(fdt, child, NULL);
-		if (len && len % t_len != 0) {
-			pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
-			       uname);
-			continue;
-		}
-
-		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
-		size = dt_mem_next_cell(dt_root_size_cells, &prop);
-
-		if (size)
-			fdt_reserved_mem_save_node(child, uname, base, size);
-	}
-}
-
 /*
  * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory.
  */
@@ -1393,7 +1344,7 @@ void __init unflatten_device_tree(void)
 	unittest_unflatten_overlay_base();
 
 	/*Initialize the reserved_mem regions*/
-	fdt_init_reserved_mem();
+	init_reserved_mem();
 }
 
 /**
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 57694a704b00..575e2b4119e0 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -176,8 +176,8 @@ static inline struct device_node *__of_get_dma_parent(const struct device_node *
 }
 #endif
 
-void fdt_init_reserved_mem(void);
-void fdt_reserved_mem_save_node(unsigned long node, const char *uname,
+void init_reserved_mem(void);
+void dt_reserved_mem_save_node(struct device_node *node, const char *uname,
 			       phys_addr_t base, phys_addr_t size);
 
 #endif /* _LINUX_OF_PRIVATE_H */
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index d62f1956024c..2ef9edcb8c93 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -55,9 +55,9 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
 }
 
 /*
- * fdt_reserved_mem_save_node() - save fdt node for second pass initialization
+ * dt_reserved_mem_save_node() - save dt node for second pass initialization
  */
-void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
+void __init dt_reserved_mem_save_node(struct device_node *node, const char *uname,
 				      phys_addr_t base, phys_addr_t size)
 {
 	struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
@@ -67,7 +67,7 @@ void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
 		return;
 	}
 
-	rmem->fdt_node = node;
+	rmem->dev_node = node;
 	rmem->name = uname;
 	rmem->base = base;
 	rmem->size = size;
@@ -76,6 +76,54 @@ void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
 	return;
 }
 
+/*
+ * Save the reserved_mem reg nodes in the reserved_mem array
+ */
+static void __init scan_reserved_mem_reg_nodes(void)
+
+{
+	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
+	struct device_node *node, *child;
+	phys_addr_t base, size;
+	const __be32 *prop;
+	int len;
+
+	node = of_find_node_by_path("/reserved-memory");
+	if (node < 0) {
+		pr_err("Reserved memory: Did not find reserved-memory node\n");
+		return;
+	}
+
+	for_each_child_of_node(node, child) {
+		const char *uname;
+		struct reserved_mem *rmem;
+
+		if (!of_device_is_available(child))
+			continue;
+
+		prop = of_get_property(child, "reg", &len);
+		if (!prop) {
+			rmem = of_reserved_mem_lookup(child);
+			if (rmem)
+				rmem->dev_node = child;
+			continue;
+		}
+
+		uname = of_node_full_name(child);
+		if (len && len % t_len != 0) {
+			pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
+			       uname);
+			continue;
+		}
+
+		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+		size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+		if (size)
+			dt_reserved_mem_save_node(child, uname, base, size);
+	}
+}
+
 /*
  * __reserved_mem_alloc_in_range() - allocate reserved memory described with
  *	'alloc-ranges'. Choose bottom-up/top-down depending on nearby existing
@@ -210,7 +258,7 @@ int __init __reserved_mem_alloc_size(unsigned long node, const char *uname)
 		       uname, (unsigned long)(size / SZ_1M));
 		return -ENOMEM;
 	}
-	fdt_reserved_mem_save_node(node, uname, base, size);
+	dt_reserved_mem_save_node(NULL, uname, base, size);
 	return 0;
 }
 
@@ -230,7 +278,7 @@ static int __init __reserved_mem_init_node(struct reserved_mem *rmem)
 		reservedmem_of_init_fn initfn = i->data;
 		const char *compat = i->compatible;
 
-		if (!of_flat_dt_is_compatible(rmem->fdt_node, compat))
+		if (!of_device_is_compatible(rmem->dev_node, compat))
 			continue;
 
 		ret = initfn(rmem);
@@ -263,11 +311,6 @@ static int __init __rmem_cmp(const void *a, const void *b)
 	if (ra->size > rb->size)
 		return 1;
 
-	if (ra->fdt_node < rb->fdt_node)
-		return -1;
-	if (ra->fdt_node > rb->fdt_node)
-		return 1;
-
 	return 0;
 }
 
@@ -299,29 +342,29 @@ static void __init __rmem_check_for_overlap(void)
 }
 
 /**
- * fdt_init_reserved_mem() - allocate and init all saved reserved memory regions
+ * init_reserved_mem() - allocate and init all saved reserved memory regions
  */
-void __init fdt_init_reserved_mem(void)
+void __init init_reserved_mem(void)
 {
 	int i;
 
-	fdt_scan_reserved_mem_reg_nodes();
+	scan_reserved_mem_reg_nodes();
 
 	/* check for overlapping reserved regions */
 	__rmem_check_for_overlap();
 
 	for (i = 0; i < reserved_mem_count; i++) {
 		struct reserved_mem *rmem = &reserved_mem[i];
-		unsigned long node = rmem->fdt_node;
+		struct device_node *node = rmem->dev_node;
 		int len;
 		const __be32 *prop;
 		int err = 0;
 		bool nomap;
 
-		nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
-		prop = of_get_flat_dt_prop(node, "phandle", &len);
+		nomap = of_get_property(node, "no-map", NULL) != NULL;
+		prop = of_get_property(node, "phandle", &len);
 		if (!prop)
-			prop = of_get_flat_dt_prop(node, "linux,phandle", &len);
+			prop = of_get_property(node, "linux,phandle", &len);
 		if (prop)
 			rmem->phandle = of_read_number(prop, len/4);
 
@@ -337,7 +380,7 @@ void __init fdt_init_reserved_mem(void)
 		} else {
 			phys_addr_t end = rmem->base + rmem->size - 1;
 			bool reusable =
-				(of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
+				(of_get_property(node, "reusable", NULL)) != NULL;
 
 			pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
 				&rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 7b2a5d93d719..d69ad5bb1eb1 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -73,7 +73,6 @@ extern int early_init_dt_scan_root(void);
 extern bool early_init_dt_scan(void *params);
 extern bool early_init_dt_verify(void *params);
 extern void early_init_dt_scan_nodes(void);
-extern void fdt_scan_reserved_mem_reg_nodes(void);
 
 extern const char *of_flat_dt_get_machine_name(void);
 extern const void *of_flat_dt_match_machine(const void *default_match,
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index dc13bcd04b12..2b205ce6beb9 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -10,7 +10,7 @@ struct reserved_mem_ops;
 
 struct reserved_mem {
 	const char			*name;
-	unsigned long			fdt_node;
+	struct device_node		*dev_node;
 	unsigned long			phandle;
 	const struct reserved_mem_ops	*ops;
 	phys_addr_t			base;
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index c21abc77c53e..3eba9678dc33 100644
--- a/kernel/dma/coherent.c
+++ b/kernel/dma/coherent.c
@@ -360,9 +360,9 @@ static const struct reserved_mem_ops rmem_dma_ops = {
 
 static int __init rmem_dma_setup(struct reserved_mem *rmem)
 {
-	unsigned long node = rmem->fdt_node;
+	struct device_node *node = rmem->dev_node;
 
-	if (of_get_flat_dt_prop(node, "reusable", NULL))
+	if (of_get_property(node, "reusable", NULL))
 		return -EINVAL;
 
 #ifdef CONFIG_ARM
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index f005c66f378c..b54cf128a9d9 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -462,8 +462,8 @@ static const struct reserved_mem_ops rmem_cma_ops = {
 
 static int __init rmem_cma_setup(struct reserved_mem *rmem)
 {
-	unsigned long node = rmem->fdt_node;
-	bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
+	struct device_node *node = rmem->dev_node;
+	bool default_cma = of_get_property(node, "linux,cma-default", NULL);
 	struct cma *cma;
 	int err;
 
@@ -473,8 +473,8 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
 		return -EBUSY;
 	}
 
-	if (!of_get_flat_dt_prop(node, "reusable", NULL) ||
-	    of_get_flat_dt_prop(node, "no-map", NULL))
+	if (!of_get_property(node, "reusable", NULL) ||
+	    of_get_property(node, "no-map", NULL))
 		return -EINVAL;
 
 	if (!IS_ALIGNED(rmem->base | rmem->size, CMA_MIN_ALIGNMENT_BYTES)) {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 33d942615be5..14840a58a6e6 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -1709,12 +1709,12 @@ static const struct reserved_mem_ops rmem_swiotlb_ops = {
 
 static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
 {
-	unsigned long node = rmem->fdt_node;
+	struct device_node *node = rmem->dev_node;
 
-	if (of_get_flat_dt_prop(node, "reusable", NULL) ||
-	    of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
-	    of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
-	    of_get_flat_dt_prop(node, "no-map", NULL))
+	if (of_get_property(node, "reusable", NULL) ||
+	    of_get_property(node, "linux,cma-default", NULL) ||
+	    of_get_property(node, "linux,dma-default", NULL) ||
+	    of_get_property(node, "no-map", NULL))
 		return -EINVAL;
 
 	rmem->ops = &rmem_swiotlb_ops;
-- 
2.17.1



From quic_obabatun at quicinc.com  Sun Dec  3 20:13:33 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 3 Dec 2023 20:13:33 -0800
Subject: [RFC PATCH v2 0/6] Dynamic allocation of reserved_mem array.
Message-ID: <20231204041339.9902-1-quic_obabatun@quicinc.com>

The reserved_mem array is used to store the data of the different
reserved memory regions specified in the DT of a device.
The array stores information such as the name, node, starting address,
and size of a reserved memory region.

The array is currently statically allocated with a size of
MAX_RESERVED_REGIONS(64). This means that any system that specifies a
number of reserved memory regions greater than MAX_RESERVED_REGIONS(64)
will not have enough space to store the information for all the regions.

Therefore, this series extends the use of a static array for
reserved_mem, and introduces a dynamically allocated array using
memblock_alloc() based on the number of reserved memory regions
specified in the DT.

Memory gotten from memblock_alloc() is only writable after paging_init()
is called, but the reserved memory regions need to be reserved before
then so that the system does not create page table mappings for them.

Reserved memory regions can be divided into 2 groups.
i) Statically-placed reserved memory regions
i.e. regions defined in the DT using the @reg property.
ii) Dynamically-placed reserved memory regions.
i.e. regions specified in the DT using the @alloc_ranges
    and @size properties.

It is possible to call memblock_reserve() and memblock_mark_nomap() on
the statically-placed reserved memory regions and not need to save them
to the array until after paging_init(), but this is not possible for the
dynamically-placed reserved memory because the starting address of these
regions need to be stored somewhere after they are allocated.

Therefore, this series achieves the allocation and population of the
reserved_mem array in two steps:

1. Before paging_init()
   Before paging_init() is called, iterate through the reserved_mem
   nodes in the DT and do the following:
   - Allocate memory for dynamically-placed reserved memory regions and
     store their starting address in the static allocated reserved_mem
     array.
   - Call memblock_reserve() and memblock_mark_nomap() on all the
     reserved memory regions as needed.
   - Count the total number of reserved_mem nodes in the DT.

2. After paging_init()
   After paging_init() is called:
   - Allocate new memory for the reserved_mem array based on the number
     of reserved memory nodes in the DT.
   - Transfer all the information that was stored in the static array
     into the new array.
   - Store the rest of the reserved_mem regions in the new array.
     i.e. the statically-placed regions.

The static array is no longer needed after this point, but there is
currently no obvious way to free the memory. Therefore, the size of the
initial static array is now defined using a config option.
Because the array is used only before paging_init() to store the
dynamically-placed reserved memory regions, the required size can vary
from device to device. Therefore, scaling it can help get some memory
savings.

A possible solution to freeing the memory for the static array will be
to mark it as __initdata. This will automatically free the memory once
the init process is done running.
The reason why this is not pursued in this series is because of
the possibility of a use-after-free.
If the dynamic allocation of the reserved_mem array fails, then future
accesses of the reserved_mem array will still be referencing the static
array. When the init process ends and the memory is freed up, any
further attempts to use the reserved_mem array will result in a
use-after-free.

Note:

- The limitation to this approach is that there is still a limit of
  64 for dynamically reserved memory regions.
- Upon further review, the series might need to be split up/duplicated
  for other archs.


Oreoluwa Babatunde (6):
  of: reserved_mem: Change the order that reserved_mem regions are
    stored
  of: reserved_mem: Swicth call to unflatten_device_tree() to after
    paging_init()
  of: resevred_mem: Delay allocation of memory for dynamic regions
  of: reserved_mem: Add code to use unflattened DT for reserved_mem
    nodes
  of: reserved_mem: Add code to dynamically allocate reserved_mem array
  of: reserved_mem: Make MAX_RESERVED_REGIONS a config option

 arch/loongarch/kernel/setup.c      |   2 +-
 arch/mips/kernel/setup.c           |   3 +-
 arch/nios2/kernel/setup.c          |   4 +-
 arch/openrisc/kernel/setup.c       |   4 +-
 arch/powerpc/kernel/setup-common.c |   3 +
 arch/sh/kernel/setup.c             |   5 +-
 arch/um/kernel/dtb.c               |   1 -
 arch/um/kernel/um_arch.c           |   2 +
 arch/xtensa/kernel/setup.c         |   4 +-
 drivers/of/Kconfig                 |  13 +++
 drivers/of/fdt.c                   |  39 +++++--
 drivers/of/of_private.h            |   6 +-
 drivers/of/of_reserved_mem.c       | 175 +++++++++++++++++++++--------
 include/linux/of_reserved_mem.h    |   8 +-
 kernel/dma/coherent.c              |   4 +-
 kernel/dma/contiguous.c            |   8 +-
 kernel/dma/swiotlb.c               |  10 +-
 17 files changed, 205 insertions(+), 86 deletions(-)

-- 
2.17.1



From quic_obabatun at quicinc.com  Sun Dec  3 20:13:35 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 3 Dec 2023 20:13:35 -0800
Subject: [RFC PATCH v2 2/6] of: reserved_mem: Swicth call to unflatten_device_tree() to after paging_init()
In-Reply-To: <20231204041339.9902-1-quic_obabatun@quicinc.com>
References: <20231204041339.9902-1-quic_obabatun@quicinc.com>
Message-ID: <20231204041339.9902-3-quic_obabatun@quicinc.com>

Switch call to unflatten_device_tree() to after paging_init() on other
archs to follow new order in which the reserved_mem regions are
processed.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 arch/loongarch/kernel/setup.c      | 2 +-
 arch/mips/kernel/setup.c           | 3 ++-
 arch/nios2/kernel/setup.c          | 4 ++--
 arch/openrisc/kernel/setup.c       | 4 ++--
 arch/powerpc/kernel/setup-common.c | 3 +++
 arch/sh/kernel/setup.c             | 5 ++---
 arch/um/kernel/dtb.c               | 1 -
 arch/um/kernel/um_arch.c           | 2 ++
 arch/xtensa/kernel/setup.c         | 4 +++-
 9 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index d183a745fb85..a01051b0f9e0 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -366,7 +366,6 @@ void __init platform_init(void)
 	acpi_gbl_use_default_register_widths = false;
 	acpi_boot_table_init();
 #endif
-	unflatten_and_copy_device_tree();
 
 #ifdef CONFIG_NUMA
 	init_numa_memory();
@@ -626,6 +625,7 @@ void __init setup_arch(char **cmdline_p)
 
 	paging_init();
 
+	unflatten_and_copy_device_tree();
 #ifdef CONFIG_KASAN
 	kasan_init();
 #endif
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 2d2ca024bd47..d3b6c86a8037 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -667,7 +667,6 @@ static void __init arch_mem_init(char **cmdline_p)
 	mips_reserve_vmcore();
 
 	mips_parse_crashkernel();
-	device_tree_init();
 
 	/*
 	 * In order to reduce the possibility of kernel panic when failed to
@@ -798,6 +797,8 @@ void __init setup_arch(char **cmdline_p)
 	cpu_cache_init();
 	paging_init();
 
+	device_tree_init();
+
 	memblock_dump_all();
 
 	setup_rng_seed();
diff --git a/arch/nios2/kernel/setup.c b/arch/nios2/kernel/setup.c
index da122a5fa43b..6f1a4232b8f0 100644
--- a/arch/nios2/kernel/setup.c
+++ b/arch/nios2/kernel/setup.c
@@ -169,8 +169,6 @@ void __init setup_arch(char **cmdline_p)
 	early_init_fdt_reserve_self();
 	early_init_fdt_scan_reserved_mem();
 
-	unflatten_and_copy_device_tree();
-
 	setup_cpuinfo();
 
 	copy_exception_handler(cpuinfo.exception_addr);
@@ -189,4 +187,6 @@ void __init setup_arch(char **cmdline_p)
 	 * get kmalloc into gear
 	 */
 	paging_init();
+
+	unflatten_and_copy_device_tree();
 }
diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index 9cf7fb60441f..fcda33bdca19 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -255,8 +255,6 @@ void calibrate_delay(void)
 
 void __init setup_arch(char **cmdline_p)
 {
-	unflatten_and_copy_device_tree();
-
 	setup_cpuinfo();
 
 #ifdef CONFIG_SMP
@@ -284,6 +282,8 @@ void __init setup_arch(char **cmdline_p)
 	/* paging_init() sets up the MMU and marks all pages as reserved */
 	paging_init();
 
+	unflatten_and_copy_device_tree();
+
 	*cmdline_p = boot_command_line;
 
 	printk(KERN_INFO "OpenRISC Linux -- http://openrisc.io\n");
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 9b142b9d5187..58da58d02652 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -986,6 +986,9 @@ void __init setup_arch(char **cmdline_p)
 
 	paging_init();
 
+	/* Unflatten the device-tree passed by prom_init or kexec */
+	unflatten_device_tree();
+
 	/* Initialize the MMU context management stuff. */
 	mmu_context_init();
 
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index 3d80515298d2..2553696af21b 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -322,6 +322,8 @@ void __init setup_arch(char **cmdline_p)
 	/* Let earlyprintk output early console messages */
 	sh_early_platform_driver_probe("earlyprintk", 1, 1);
 
+	paging_init();
+
 #ifdef CONFIG_OF_EARLY_FLATTREE
 #ifdef CONFIG_USE_BUILTIN_DTB
 	unflatten_and_copy_device_tree();
@@ -329,9 +331,6 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 #endif
 #endif
-
-	paging_init();
-
 	/* Perform the machine specific initialisation */
 	if (likely(sh_mv.mv_setup))
 		sh_mv.mv_setup(cmdline_p);
diff --git a/arch/um/kernel/dtb.c b/arch/um/kernel/dtb.c
index 484141b06938..04b0ada3b929 100644
--- a/arch/um/kernel/dtb.c
+++ b/arch/um/kernel/dtb.c
@@ -26,7 +26,6 @@ void uml_dtb_init(void)
 	}
 
 	early_init_fdt_scan_reserved_mem();
-	unflatten_device_tree();
 }
 
 static int __init uml_dtb_setup(char *line, int *add)
diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
index b1bfed0c8528..fe6ecaa12ef2 100644
--- a/arch/um/kernel/um_arch.c
+++ b/arch/um/kernel/um_arch.c
@@ -7,6 +7,7 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/mm.h>
+#include <linux/of_fdt.h>
 #include <linux/ctype.h>
 #include <linux/module.h>
 #include <linux/panic_notifier.h>
@@ -421,6 +422,7 @@ void __init setup_arch(char **cmdline_p)
 	read_initrd();
 
 	paging_init();
+	unflatten_device_tree();
 	strscpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
 	*cmdline_p = command_line;
 	setup_hostinfo(host_info, sizeof host_info);
diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index bdec4a773af0..d20c56b4182e 100644
--- a/arch/xtensa/kernel/setup.c
+++ b/arch/xtensa/kernel/setup.c
@@ -355,13 +355,15 @@ void __init setup_arch(char **cmdline_p)
 	parse_early_param();
 	bootmem_init();
 	kasan_init();
-	unflatten_and_copy_device_tree();
 
 #ifdef CONFIG_SMP
 	smp_init_cpus();
 #endif
 
 	paging_init();
+
+	unflatten_and_copy_device_tree();
+
 	zones_init();
 
 #ifdef CONFIG_VT
-- 
2.17.1



From quic_obabatun at quicinc.com  Sun Dec  3 20:13:34 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 3 Dec 2023 20:13:34 -0800
Subject: [RFC PATCH v2 1/6] of: reserved_mem: Change the order that reserved_mem regions are stored
In-Reply-To: <20231204041339.9902-1-quic_obabatun@quicinc.com>
References: <20231204041339.9902-1-quic_obabatun@quicinc.com>
Message-ID: <20231204041339.9902-2-quic_obabatun@quicinc.com>

The dynamic allocation of the reserved_mem array needs to be done after
paging_init() is called because memory allocated using memblock_alloc()
is not writeable before that.

Statically-placed reserved memory regions can wait until after
paging_init() to be stored in the array because the starting address and
size information is already specified in the DT.
Dynamically-placed regions on the other hand does not have its starting
address specified in the DT because it is allocated at runtime. Hence,
the starting address of these regions need to be stored somewhere.
The allocation of dynamically-placed regions cannot be done after
paging_init() either to avoid getting regions that are already added to
the page table mappings.

Hence, change the code to:
1. Before paging_init(), allocate and store information for the
   dynamically-placed reserved memory regions.
2. After paging_init(), store the information for the statically
   placed reserved memory regions in the array.

All the regions are also reserved or marked as nomap as needed before
paging_init().

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/fdt.c                | 63 ++++++++++++++++++++++++++++-----
 drivers/of/of_reserved_mem.c    | 53 ++++++++++++---------------
 include/linux/of_fdt.h          |  1 +
 include/linux/of_reserved_mem.h |  6 ++++
 4 files changed, 84 insertions(+), 39 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bf502ba8da95..34223c249914 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -504,7 +504,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
 	phys_addr_t base, size;
 	int len;
 	const __be32 *prop;
-	int first = 1;
 	bool nomap;
 
 	prop = of_get_flat_dt_prop(node, "reg", &len);
@@ -532,10 +531,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
 			       uname, &base, (unsigned long)(size / SZ_1M));
 
 		len -= t_len;
-		if (first) {
-			fdt_reserved_mem_save_node(node, uname, base, size);
-			first = 0;
-		}
 	}
 	return 0;
 }
@@ -564,7 +559,56 @@ static int __init __reserved_mem_check_root(unsigned long node)
 }
 
 /*
- * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory
+ * Save the reserved_mem reg nodes in the reserved_mem array
+ */
+void __init fdt_scan_reserved_mem_reg_nodes(void)
+
+{
+	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
+	const void *fdt = initial_boot_params;
+	phys_addr_t base, size;
+	const __be32 *prop;
+	int node, child;
+	int len;
+
+	node = fdt_path_offset(fdt, "/reserved-memory");
+	if (node < 0) {
+		pr_err("Reserved memory: Did not find reserved-memory node\n");
+		return;
+	}
+
+	if (__reserved_mem_check_root(node) != 0) {
+		pr_err("Reserved memory: unsupported node format, ignoring\n");
+		return;
+	}
+
+	fdt_for_each_subnode(child, fdt, node) {
+		const char *uname;
+
+		prop = of_get_flat_dt_prop(child, "reg", &len);
+		if (!prop)
+			continue;
+
+		if (!of_fdt_device_is_available(fdt, child))
+			continue;
+
+		uname = fdt_get_name(fdt, child, NULL);
+		if (len && len % t_len != 0) {
+			pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
+			       uname);
+			continue;
+		}
+
+		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+		size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+		if (size)
+			fdt_reserved_mem_save_node(child, uname, base, size);
+	}
+}
+
+/*
+ * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory.
  */
 static int __init fdt_scan_reserved_mem(void)
 {
@@ -591,7 +635,7 @@ static int __init fdt_scan_reserved_mem(void)
 
 		err = __reserved_mem_reserve_reg(child, uname);
 		if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL))
-			fdt_reserved_mem_save_node(child, uname, 0, 0);
+			__reserved_mem_alloc_size(child, uname);
 	}
 	return 0;
 }
@@ -645,8 +689,6 @@ void __init early_init_fdt_scan_reserved_mem(void)
 			break;
 		memblock_reserve(base, size);
 	}
-
-	fdt_init_reserved_mem();
 }
 
 /**
@@ -1335,6 +1377,9 @@ void __init unflatten_device_tree(void)
 	of_alias_scan(early_init_dt_alloc_memory_arch);
 
 	unittest_unflatten_overlay_base();
+
+	/*Initialize the reserved_mem regions*/
+	fdt_init_reserved_mem();
 }
 
 /**
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 7ec94cfcbddb..8bd8bbc3aaec 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -132,8 +132,7 @@ static int __init __reserved_mem_alloc_in_range(phys_addr_t size,
  * __reserved_mem_alloc_size() - allocate reserved memory described by
  *	'size', 'alignment'  and 'alloc-ranges' properties.
  */
-static int __init __reserved_mem_alloc_size(unsigned long node,
-	const char *uname, phys_addr_t *res_base, phys_addr_t *res_size)
+int __init __reserved_mem_alloc_size(unsigned long node, const char *uname)
 {
 	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
 	phys_addr_t start = 0, end = 0;
@@ -212,10 +211,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node,
 		       uname, (unsigned long)(size / SZ_1M));
 		return -ENOMEM;
 	}
-
-	*res_base = base;
-	*res_size = size;
-
+	fdt_reserved_mem_save_node(node, uname, base, size);
 	return 0;
 }
 
@@ -310,6 +306,8 @@ void __init fdt_init_reserved_mem(void)
 {
 	int i;
 
+	fdt_scan_reserved_mem_reg_nodes();
+
 	/* check for overlapping reserved regions */
 	__rmem_check_for_overlap();
 
@@ -328,30 +326,25 @@ void __init fdt_init_reserved_mem(void)
 		if (prop)
 			rmem->phandle = of_read_number(prop, len/4);
 
-		if (rmem->size == 0)
-			err = __reserved_mem_alloc_size(node, rmem->name,
-						 &rmem->base, &rmem->size);
-		if (err == 0) {
-			err = __reserved_mem_init_node(rmem);
-			if (err != 0 && err != -ENOENT) {
-				pr_info("node %s compatible matching fail\n",
-					rmem->name);
-				if (nomap)
-					memblock_clear_nomap(rmem->base, rmem->size);
-				else
-					memblock_phys_free(rmem->base,
-							   rmem->size);
-			} else {
-				phys_addr_t end = rmem->base + rmem->size - 1;
-				bool reusable =
-					(of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
-
-				pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
-					&rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
-					nomap ? "nomap" : "map",
-					reusable ? "reusable" : "non-reusable",
-					rmem->name ? rmem->name : "unknown");
-			}
+		err = __reserved_mem_init_node(rmem);
+		if (err != 0 && err != -ENOENT) {
+			pr_info("node %s compatible matching fail\n",
+				rmem->name);
+			if (nomap)
+				memblock_clear_nomap(rmem->base, rmem->size);
+			else
+				memblock_phys_free(rmem->base,
+						   rmem->size);
+		} else {
+			phys_addr_t end = rmem->base + rmem->size - 1;
+			bool reusable =
+				(of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
+
+			pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
+				&rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
+				nomap ? "nomap" : "map",
+				reusable ? "reusable" : "non-reusable",
+				rmem->name ? rmem->name : "unknown");
 		}
 	}
 }
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index d69ad5bb1eb1..7b2a5d93d719 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -73,6 +73,7 @@ extern int early_init_dt_scan_root(void);
 extern bool early_init_dt_scan(void *params);
 extern bool early_init_dt_verify(void *params);
 extern void early_init_dt_scan_nodes(void);
+extern void fdt_scan_reserved_mem_reg_nodes(void);
 
 extern const char *of_flat_dt_get_machine_name(void);
 extern const void *of_flat_dt_match_machine(const void *default_match,
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index 4de2a24cadc9..dc13bcd04b12 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -38,6 +38,7 @@ int of_reserved_mem_device_init_by_name(struct device *dev,
 					struct device_node *np,
 					const char *name);
 void of_reserved_mem_device_release(struct device *dev);
+int __reserved_mem_alloc_size(unsigned long node, const char *uname);
 
 struct reserved_mem *of_reserved_mem_lookup(struct device_node *np);
 #else
@@ -60,6 +61,11 @@ static inline int of_reserved_mem_device_init_by_name(struct device *dev,
 
 static inline void of_reserved_mem_device_release(struct device *pdev) { }
 
+static inline int __reserved_mem_alloc_size(unsigned long node, const char *uname)
+{
+	return -ENOSYS;
+}
+
 static inline struct reserved_mem *of_reserved_mem_lookup(struct device_node *np)
 {
 	return NULL;
-- 
2.17.1



From quic_obabatun at quicinc.com  Sun Dec  3 20:18:25 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 3 Dec 2023 20:18:25 -0800
Subject: [RFC PATCH 1/3] of: reserved_mem: Change the order that
 reserved_mem regions are stored
In-Reply-To: <20231024193210.GA407269-robh@kernel.org>
References: <20231019184825.9712-1-quic_obabatun@quicinc.com>
 <20231019184825.9712-2-quic_obabatun@quicinc.com>
 <20231024193210.GA407269-robh@kernel.org>
Message-ID: <ef20a676-cf56-499d-bb99-ed271a1691d4@quicinc.com>


On 10/24/2023 12:32 PM, Rob Herring wrote:
> On Thu, Oct 19, 2023 at 11:48:23AM -0700, Oreoluwa Babatunde wrote:
>> The dynamic allocation of the reserved_mem array needs to be done after
>> paging_init() is called because memory allocated using memblock_alloc()
>> is not writeable before that.
>>
>> Nodes that already have their starting address specified in the DT
>> (i.e. nodes that are defined using the "reg" property) can wait until
>> after paging_init() to be stored in the array.
>> But nodes that are dynamically placed need to be reserved and saved in
>> the array before paging_init() so that page table entries are not
>> created for these regions.
>>
>> Hence, change the code to:
>> 1. Before paging_init(), allocate and store information for the
>>    dynamically placed reserved memory regions.
>> 2. After paging_init(), store the rest of the reserved memory regions
>>    which are defined with the "reg" property.
>>
>> Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
>> ---
>>  arch/arm64/kernel/setup.c       |  4 +++
>>  drivers/of/fdt.c                | 56 ++++++++++++++++++++++++++-------
>>  drivers/of/of_private.h         |  1 -
>>  drivers/of/of_reserved_mem.c    | 54 ++++++++++++++-----------------
>>  include/linux/of_fdt.h          |  1 +
>>  include/linux/of_reserved_mem.h |  9 ++++++
>>  6 files changed, 83 insertions(+), 42 deletions(-)
> Looking at this a bit more...
>
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index 417a8a86b2db..6002d3ad0b19 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -27,6 +27,8 @@
>>  #include <linux/proc_fs.h>
>>  #include <linux/memblock.h>
>>  #include <linux/of_fdt.h>
>> +#include <linux/of_reserved_mem.h>
>> +
>>  #include <linux/efi.h>
>>  #include <linux/psci.h>
>>  #include <linux/sched/task.h>
>> @@ -346,6 +348,8 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
>>  
>>  	paging_init();
>>  
>> +	fdt_init_reserved_mem();
>> +
>>  	acpi_table_upgrade();
>>  
>>  	/* Parse the ACPI tables for possible boot-time configuration */
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index bf502ba8da95..d51a1176a7b9 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -504,7 +504,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
>>  	phys_addr_t base, size;
>>  	int len;
>>  	const __be32 *prop;
>> -	int first = 1;
>>  	bool nomap;
>>  
>>  	prop = of_get_flat_dt_prop(node, "reg", &len);
>> @@ -532,10 +531,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
>>  			       uname, &base, (unsigned long)(size / SZ_1M));
>>  
>>  		len -= t_len;
>> -		if (first) {
>> -			fdt_reserved_mem_save_node(node, uname, base, size);
>> -			first = 0;
>> -		}
>>  	}
>>  	return 0;
>>  }
>> @@ -564,9 +559,44 @@ static int __init __reserved_mem_check_root(unsigned long node)
>>  }
>>  
>>  /*
>> - * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory
>> + * Save the reserved_mem reg nodes in the reserved_mem array
>>   */
>> -static int __init fdt_scan_reserved_mem(void)
>> +static void save_reserved_mem_reg_nodes(unsigned long node, const char *uname)
>> +
>> +{
>> +	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
>> +	phys_addr_t base, size;
>> +	int len;
>> +	const __be32 *prop;
>> +
>> +	prop = of_get_flat_dt_prop(node, "reg", &len);
>> +	if (!prop)
>> +		return;
>> +
>> +	if (len && len % t_len != 0) {
>> +		pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
>> +		       uname);
>> +		return;
>> +	}
>> +	base = dt_mem_next_cell(dt_root_addr_cells, &prop);
>> +	size = dt_mem_next_cell(dt_root_size_cells, &prop);
>> +
>> +	if (size)
>> +		fdt_reserved_mem_save_node(node, uname, base, size);
>> +}
>> +
>> +/*
>> + * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory.
>> + * @save_only: Option to determine what kind of fdt scan the caller is
>> + * requesting.
>> + *
>> + * The fdt is scanned twice here during device bootup. The first scan
>> + * is used to save the dynamically allocated reserved memory regions to
>> + * the reserved_mem array. The second scan is used to save the 'reg'
>> + * defined regions to the array. @save_only indicates which of the scans
>> + * the caller is requesting.
>> + */
>> +int __init fdt_scan_reserved_mem(bool save_only)
> It's generally discouraged to use flags to make a function do 2 
> different operations. Splitting it will naturally happen though with my 
> next comment.
>
>>  {
>>  	int node, child;
>>  	const void *fdt = initial_boot_params;
>> @@ -589,9 +619,14 @@ static int __init fdt_scan_reserved_mem(void)
>>  
>>  		uname = fdt_get_name(fdt, child, NULL);
>>  
>> +		if (save_only) {
>> +			save_reserved_mem_reg_nodes(child, uname);
>> +			continue;
>> +		}
>> +
>>  		err = __reserved_mem_reserve_reg(child, uname);
>>  		if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL))
>> -			fdt_reserved_mem_save_node(child, uname, 0, 0);
>> +			__reserved_mem_alloc_size(child, uname);
>>  	}
>>  	return 0;
>>  }
>> @@ -631,11 +666,12 @@ void __init early_init_fdt_scan_reserved_mem(void)
>>  {
>>  	int n;
>>  	u64 base, size;
>> +	bool save_only = false;
>>  
>>  	if (!initial_boot_params)
>>  		return;
>>  
>> -	fdt_scan_reserved_mem();
>> +	fdt_scan_reserved_mem(save_only);
>>  	fdt_reserve_elfcorehdr();
>>  
>>  	/* Process header /memreserve/ fields */
>> @@ -645,8 +681,6 @@ void __init early_init_fdt_scan_reserved_mem(void)
>>  			break;
>>  		memblock_reserve(base, size);
>>  	}
>> -
>> -	fdt_init_reserved_mem();
>>  }
>>  
>>  /**
>> diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
>> index f38397c7b582..e52b27b8392d 100644
>> --- a/drivers/of/of_private.h
>> +++ b/drivers/of/of_private.h
>> @@ -175,7 +175,6 @@ static inline struct device_node *__of_get_dma_parent(const struct device_node *
>>  }
>>  #endif
>>  
>> -void fdt_init_reserved_mem(void);
>>  void fdt_reserved_mem_save_node(unsigned long node, const char *uname,
>>  			       phys_addr_t base, phys_addr_t size);
>>  
>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>> index 7ec94cfcbddb..13e694f5e316 100644
>> --- a/drivers/of/of_reserved_mem.c
>> +++ b/drivers/of/of_reserved_mem.c
>> @@ -132,8 +132,7 @@ static int __init __reserved_mem_alloc_in_range(phys_addr_t size,
>>   * __reserved_mem_alloc_size() - allocate reserved memory described by
>>   *	'size', 'alignment'  and 'alloc-ranges' properties.
>>   */
>> -static int __init __reserved_mem_alloc_size(unsigned long node,
>> -	const char *uname, phys_addr_t *res_base, phys_addr_t *res_size)
>> +int __init __reserved_mem_alloc_size(unsigned long node, const char *uname)
>>  {
>>  	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
>>  	phys_addr_t start = 0, end = 0;
>> @@ -212,10 +211,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node,
>>  		       uname, (unsigned long)(size / SZ_1M));
>>  		return -ENOMEM;
>>  	}
>> -
>> -	*res_base = base;
>> -	*res_size = size;
>> -
>> +	fdt_reserved_mem_save_node(node, uname, base, size);
>>  	return 0;
>>  }
>>  
>> @@ -309,6 +305,9 @@ static void __init __rmem_check_for_overlap(void)
>>  void __init fdt_init_reserved_mem(void)
>>  {
>>  	int i;
>> +	bool save_only = true;
>> +
>> +	fdt_scan_reserved_mem(save_only);
> This is now called just before unflattening. Why can't it be done right 
> after unflattening instead. Then we can use the unflattened API rather 
> than the flatten API which is less efficient.
>
> Rob

Hi Rob,

My apologies for the delayed response.
I was able to implement the use of the unflattened devicetree APIs to
scan through the DT after paging_init() as per one of your comments.

Regarding your second comment, I moved the call to
fdt_init_reserved_mem() into the unflatten_device_tree() function
to remove the dependency of the DT code on the arch specific code.

This was an easy change for the arm64 arch which I am currently working
with, but some other archs needed an additional change for this to work.
I noticed that some other archs have the ordering reversed for how
paging_init() and unflatten_device_tree() are called.

These are the archs which have the call order reversed:
nios2, loongarch, mips, openrisc, powerpc, sh, um, xtensa.

Since the order in which paging_init() and fdt_init_reserved_mem() are
called is important for this series to work, moving the call to
fdt_init_reserved_mem() into the unflatten_device_tree() function would
have broken for the above mentioned architectures.

Hence, in my v2 rfc patch, I have changed the order in which
paging_init() and unflatten_device_tree() functions are called for the
above mentioned archs to make unflatten_device_tree() be called
after paging_init().

Regards,

Oreoluwa


From anshuman.khandual at arm.com  Sun Dec  3 20:26:45 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 4 Dec 2023 09:56:45 +0530
Subject: [PATCH V2 1/7] coresight: replicator: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <20231201123515.gntwvhsxd5nzojn7@bogus>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-2-anshuman.khandual@arm.com>
 <20231201123515.gntwvhsxd5nzojn7@bogus>
Message-ID: <58882cab-89ce-4554-aee4-24e70d82fc09@arm.com>



On 12/1/23 18:05, Sudeep Holla wrote:
> On Fri, Dec 01, 2023 at 11:50:47AM +0530, Anshuman Khandual wrote:
>> Add support for the dynamic replicator device in the platform driver, which
>> can then be used on ACPI based platforms. This change would now allow
>> runtime power management for repliacator devices on ACPI based systems.
>>
>> The driver would try to enable the APB clock if available. Also, rename the
>> code to reflect the fact that it now handles both static and dynamic
>> replicators.
>>
>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>> Cc: Sudeep Holla <sudeep.holla at arm.com>
> 
> Except the minor nit below which may apply also for few other patches
> in the series
> 
> Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
> Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
> 
> [...]
> 
>> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
>> index b6be73034996..64de0bee02ec 100644
>> --- a/drivers/hwtracing/coresight/coresight-replicator.c
>> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
>> @@ -38,6 +38,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>>  struct replicator_drvdata {
>>  	void __iomem		*base;
>>  	struct clk		*atclk;
>> +	struct clk		*pclk;
> 
> [minor nit] Perhaps can be documented as well ?

Sure, will add the following comment above the structure.

@pclk:    optional clock for the core parts of the replicator.


From yuji2.ishikawa at toshiba.co.jp  Sun Dec  3 20:32:40 2023
From: yuji2.ishikawa at toshiba.co.jp (yuji2.ishikawa at toshiba.co.jp)
Date: Mon, 4 Dec 2023 04:32:40 +0000
Subject: [PATCH v9 4/5] documentation: media: add documentation for
 Toshiba Visconti Video Input Interface driver
In-Reply-To: <ZV3oq0szH8JjSNsc@valkosipuli.retiisi.eu>
References: <20231012071329.2542003-1-yuji2.ishikawa@toshiba.co.jp>
 <20231012071329.2542003-5-yuji2.ishikawa@toshiba.co.jp>
 <ZV3oq0szH8JjSNsc@valkosipuli.retiisi.eu>
Message-ID: <TYAPR01MB620180FF82B8993B45FF6E0A9286A@TYAPR01MB6201.jpnprd01.prod.outlook.com>

Hello Sakari,
Thank you for your review.

> -----Original Message-----
> From: Sakari Ailus <sakari.ailus at iki.fi>
> Sent: Wednesday, November 22, 2023 8:40 PM
> To: ishikawa yuji(?? ?? ?????????????)
> <yuji2.ishikawa at toshiba.co.jp>
> Cc: Hans Verkuil <hverkuil at xs4all.nl>; Laurent Pinchart
> <laurent.pinchart at ideasonboard.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>; Rob Herring <robh+dt at kernel.org>; Krzysztof
> Kozlowski <krzysztof.kozlowski+dt at linaro.org>; Conor Dooley
> <conor+dt at kernel.org>; iwamatsu nobuhiro(?? ?? ??????????
> ???) <nobuhiro1.iwamatsu at toshiba.co.jp>; linux-media at vger.kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v9 4/5] documentation: media: add documentation for
> Toshiba Visconti Video Input Interface driver
> 
> Hi Yuji,
> 
> Thank you for the update and my apologies for not reviewing this properly
> earlier. Please see my commens below.
> 
> On Thu, Oct 12, 2023 at 04:13:28PM +0900, Yuji Ishikawa wrote:
> > Added basic description of Video Input Interface driver of Toshiba
> > Visconti architecture.
> > It includes hardware organization, structure of the driver and
> > description of vendor specific V4L2 controls to configure the embedded
> > image signal processor.
> >
> > Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
> > ---
> > Changelog v3:
> > - Newly add documentation to describe SW and HW
> >
> > Changelog v4:
> > - no change
> >
> > Changelog v5:
> > - no change
> >
> > Changelog v6:
> > - add description of CSI2RX subdevice
> > - add ordering of ioctl(S_FMT) and ioctl(S_EXT_CTRLS)
> >
> > Changelog v7:
> > - no change
> >
> > Changelog v8:
> > - add usage of V4L2_CTRL_TYPE_VISCONTI_ISP
> >
> > Changelog v9:
> > - fix warning: set reference target for keyword
> > V4L2_CTRL_TYPE_VISCONTI_ISP
> >
> >  .../driver-api/media/drivers/index.rst        |   1 +
> >  .../media/drivers/visconti-viif.rst           | 462
> ++++++++++++++++++
> >  .../media/v4l/vidioc-g-ext-ctrls.rst          |   4 +
> >  .../media/v4l/vidioc-queryctrl.rst            |   5 +
> >  .../media/videodev2.h.rst.exceptions          |   1 +
> >  5 files changed, 473 insertions(+)
> >  create mode 100644
> > Documentation/driver-api/media/drivers/visconti-viif.rst
> >
> > diff --git a/Documentation/driver-api/media/drivers/index.rst
> > b/Documentation/driver-api/media/drivers/index.rst
> > index c4123a16b5f9..5592bd99ae5c 100644
> > --- a/Documentation/driver-api/media/drivers/index.rst
> > +++ b/Documentation/driver-api/media/drivers/index.rst
> > @@ -24,6 +24,7 @@ Video4Linux (V4L) drivers
> >  	sh_mobile_ceu_camera
> >  	tuners
> >  	vimc-devel
> > +	visconti-viif
> >  	zoran
> >  	ccs/ccs
> >
> > diff --git a/Documentation/driver-api/media/drivers/visconti-viif.rst
> > b/Documentation/driver-api/media/drivers/visconti-viif.rst
> > new file mode 100644
> > index 000000000000..fd2480cbde46
> > --- /dev/null
> > +++ b/Documentation/driver-api/media/drivers/visconti-viif.rst
> > @@ -0,0 +1,462 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +============================================
> > +Visconti Video Input Interface (VIIF) Driver
> > +============================================
> > +
> > +Overview
> > +========
> > +
> > +The Visconti VIIF Hardware
> > +--------------------------
> > +
> > +The Visconti Video Input Interface (VIIF) hardware is  a proprietary
> videocapture device of Toshiba.
> > +Following function modules are integrated:
> > +
> > +* MIPI CSI2 receiver (CSI2RX)
> > +* L1 Image Signal Processor (L1ISP)
> > +
> > +  * Correction, enhancement, adjustment on RAW pictures.
> > +
> > +* L2 Image Signal Processor (L2ISP)
> > +
> > +  * Lens distortion correction
> > +  * Scaling
> > +  * Cropping
> > +
> > +* Video DMAC
> > +
> > +  * format picture (RGB, YUV, Grayscale, ...)
> > +  * write picture into DRAM
> > +
> > +Visconti5 SoC has two VIIF hardware instances.
> > +
> > +software architecture
> > +---------------------
> > +
> > +The Visconti VIIF driver is composed of following components:
> > +
> > +* (image sensor driver)
> > +* MIPI CSI2 receiver subdevice driver
> > +
> > +  * corresponding to CSI2RX
> > +
> > +* Visconti ISP subdevice driver
> > +
> > +  * corresponding to L1ISP, L2ISP (Lens distortion correction,
> > + Scaling)
> > +
> > +* Visconti Capture V4L2 device driver
> > +
> > +  * corresponding to L2ISP (Cropping) and Video DMAC
> > +  * multiple output videobuf queues
> > +
> > +    * main path0 (RGB, YUV, Grayscale, ...)
> > +    * main path1 (RGB, YUV, Grayscale, ...)
> > +    * sub path (RAW picture)
> > +
> > +::
> > +
> > +  +-----------+      +-----------+     +----------------+
> +-------------------------+
> > +  | Sensor    |      | CSI2RX    |     | ISP            |       |
> Capture MAIN PATH0      |
> > +  | subdevice | ---- | subdevice | --- | subdevice      | --+-- | V4L2 device
> |
> > +  | (IMX219)  |      | (CSI2RX)  |     | (L1ISP, L2ISP) |   |   | (L2ISP
> crop, VideoDMAC) |
> > +  +-----------+      +-----------+     +----------------+   |
> +-------------------------+
> > +                                                            |
> > +                                                            |
> +-------------------------+
> > +                                                            |   |
> Capture MAIN PATH1      |
> > +                                                            +-- |
> V4L2 device             |
> > +                                                            |   |
> (L2ISP crop, VideoDMAC) |
> > +                                                            |
> +-------------------------+
> > +                                                            |
> > +                                                            |
> +-------------------------+
> > +                                                            |   |
> Capture SUB PATH        |
> > +                                                            +-- |
> V4L2 device             |
> > +                                                                |
> (VideoDMAC)             |
> > +
> > + +-------------------------+
> > +
> > +
> > +The VIIF driver provides following device nodes for Visconti5 SoC:
> > +
> > +* VIIF0
> > +
> > +  * /dev/media0
> > +  * /dev/video0 (main path0)
> > +  * /dev/video1 (main path1)
> > +  * /dev/video2 (sub path)
> > +
> > +* VIIF1
> > +
> > +  * /dev/media1
> > +  * /dev/video3 (main path0)
> > +  * /dev/video4 (main path1)
> > +  * /dev/video5 (sub path)
> > +
> > +Use of coherent memory
> > +----------------------
> > +
> > +Visconti5 SoC has two independent DDR SDRAM controllers.
> > +Each controller is mapped to 36bit address space.
> > +
> > +Accelerator bus masters have two paths to access memory; one is
> > +directly connected to SDRAM controller, the another is connected via
> > +a cache coherency bus which keeps coherency among CPUs.
> > +
> > +From acclerators and CPUs, the address map is following:
> > +
> > +* 0x0_8000_0000 DDR0 direct access
> > +* 0x4_8000_0000 DDR0 coherency bus
> > +* 0x8_8000_0000 DDR1 direct access
> > +* 0xC_8000_0000 DDR1 coherency bus
> > +
> > +The base address can be specified with "memory" and "reserved-memory"
> > +elements in a device tree description.
> > +It's not recommended to mix direct address and coherent address.
> > +
> > +The Visconti5 VIIF driver always use only direct address to configure Video
> DMACs of the hardware.
> > +This design is to avoid great performance loss at coherency bus caused by
> massive memory access.
> > +You should not put the dma_coherent attribute to viif element in device
> tree.
> > +Cache operations are done automatically by videobuf2 driver.
> > +
> > +Tested environment
> > +------------------
> > +
> > +The Visconti VIIF driver was tested with following items:
> > +
> > +* IMX219 image sensor
> > +* IMX335 image sensor
> > +
> > +IOCTLs
> > +======
> > +
> > +Following public IOCTLs are supported
> > +
> > +* VIDIOC_QUERYCAP
> > +* VIDIOC_ENUM_FMT
> > +* VIDIOC_TRY_FMT
> > +* VIDIOC_S_FMT
> > +* VIDIOC_G_FMT
> > +* VIDIOC_ENUM_FRAMESIZES
> > +* VIDIOC_G_EXT_CTRLS
> > +* VIDIOC_S_EXT_CTRLS
> > +* VIDIOC_REQBUFS
> > +* VIDIOC_QUERYBUF
> > +* VIDIOC_QBUF
> > +* VIDIOC_EXPBUF
> > +* VIDIOC_DQBUF
> > +* VIDIOC_CREATE_BUFS
> > +* VIDIOC_PREPARE_BUF
> > +* VIDIOC_STREAMON
> > +* VIDIOC_STREAMOFF
> > +
> > +Vendor specific v4l2 controls
> > +(except for V4L2_CID_VISCONTI_VIIF_MAIN_SET_RAWPACK_MODE and
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_INPUT_MODE) should be called
> after
> > +ioctl(S_FMT) because setting the frame format may affect valid range
> > +of parameters of the controls.
> > +
> > +Vendor specific v4l2 controls
> > +=============================
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_MAIN_SET_RAWPACK_MODE:
> > +
> > +V4L2_CID_VISCONTI_VIIF_MAIN_SET_RAWPACK_MODE
> > +--------------------------------------------
> > +
> > +This control sets the format to pack multiple RAW pixel values into a word.
> > +
> > +This control accepts a __u32 value defined as `enum viif_rawpack_mode`.
> > +
> > +This control should be set before ioctl(S_FMT) and should not be changed
> after that.
> 
> Why do you need this? Doesn't the V4L2 pixelformat already explicitly define
> the format, including packing?
> 

This control value affects the unpacker between CSI2 receiver and ISP.
The rawpack mode is an option to receive from Wide-Dynamic-Range image sensors,
whose output bit width is larger than standard format (RAW20, RAW24).
For example, some WDR image sensors split 20 bit value into upper/lower 10bit values,
then put them into consective pixels to make a double-width RAW10 format image.

This option is only related to the interpretation of CSI2 input data.
Therefore, I think V4L2 pixel format (for resulting image) is not related to it.
The media bus format seems more relevant, but there is no corresponding definition to this case.

> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_INPUT_MODE:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_INPUT_MODE
> > +--------------------------------------------
> > +
> > +This control sets L1ISP preprocessing mode for RAW input images.
> > +
> > +This control accepts a `struct viif_l1_input_mode_config` instance.
> > +
> > +This control should be set before ioctl(S_FMT) and should not be changed
> after that.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_RGB_TO_Y_COEF:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_RGB_TO_Y_COEF
> > +-----------------------------------------------
> > +
> > +This control sets parameters to yield Y value from RGB pixel values.
> > +
> > +This control accepts a `struct viif_l1_rgb_to_y_coef_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AG_MODE:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AG_MODE
> > +-----------------------------------------
> > +
> > +This control sets rules of generating analog gains for each feature in L1ISP.
> > +Related features are:
> > +
> > +* Optical Black Clamp Correction (OBCC)
> > +* Defect Pixel Correction (DPC)
> > +* RAW Color Noise Reduction (RCNR)
> > +* Lens Shading Correction (LSC)
> > +* Color matrix correction (MPRO)
> > +* Image quality adjustment (VPRO)
> > +
> > +The base gain is set with V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AG
> control.
> > +
> > +This control accepts a `struct viif_l1_ag_mode_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AG:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AG
> > +------------------------------------
> > +
> > +This control sets base analog gain commonly used in L1ISP features.
> > +Analog gain for each L1ISP feature is generated from the base analog
> > +gain and a configuration via
> V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AG_MODE control.
> > +
> > +This control accepts a `struct viif_l1_ag_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_HDRE:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_HDRE
> > +--------------------------------------
> > +
> > +This controls sets parameters for HDR Expansion feature.
> > +
> > +This control accepts a `struct viif_l1_hdre_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_IMG_EXTRACTION:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_IMG_EXTRACTION
> > +------------------------------------------------
> > +
> > +This control sets black level parameters for L1ISP inputs.
> > +
> > +This control accepts a `struct viif_l1_img_extraction_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_DPC:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_DPC
> > +-------------------------------------
> > +
> > +This control sets parameters for Defect Pixel Correction.
> > +
> > +This control accepts a `struct viif_l1_dpc_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_PRESET_WHITE_BALANCE:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_PRESET_WHITE_BALANCE
> > +------------------------------------------------------
> > +
> > +This control sets parameters for white balance.
> > +
> > +This control accepts a `struct viif_l1_preset_white_balance_config`
> instance.
> > +
> > +..
> _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_RAW_COLOR_NOISE_REDUCTION:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_RAW_COLOR_NOISE_REDUCTION
> > +-----------------------------------------------------------
> > +
> > +This control sets parameters for RAW color noise reduction (RCNR) feature.
> > +
> > +This control accepts a `struct viif_l1_raw_color_noise_reduction_config`
> instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_HDRS:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_HDRS
> > +--------------------------------------
> > +
> > +This control sets parameters for HDR synthesis.
> > +
> > +This control accepts a `struct viif_l1_hdrs_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_BLACK_LEVEL_CORRECTION:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_BLACK_LEVEL_CORRECTION
> > +--------------------------------------------------------
> > +
> > +This control sets parameters for black level correction feature.
> > +
> > +This control accepts a `struct viif_l1_black_level_correction_config`
> instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_LSC:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_LSC
> > +-------------------------------------
> > +
> > +This control sets parameters for Lens Shading Correction feature.
> > +L1ISP supports 2 correction methods:
> > +
> > +* parabola shading
> > +* grid shading
> > +
> > +This control accepts a `struct viif_l1_lsc_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_MAIN_PROCESS:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_MAIN_PROCESS
> > +----------------------------------------------
> > +
> > +This controls sets parameter for the MAIN PROCESS feature which is
> composed of:
> > +
> > +* demosaic
> > +* color matrix correction
> > +
> > +This control accepts a `struct viif_l1_main_process_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AWB:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AWB
> > +-------------------------------------
> > +
> > +This control sets parameter for auto white balance feature.
> > +
> > +This control accepts a `struct viif_l1_awb_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_LOCK_AWB_GAIN:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_LOCK_AWB_GAIN
> > +-------------------------------------------
> > +
> > +This control requests enable/disable of lock for AWB gain.
> > +
> > +This control accepts a u32 value; 0 for disable lock, 1 for enable lock.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_HDRC:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_HDRC
> > +--------------------------------------
> > +
> > +This control sets parameter for HDR Compression feature.
> > +
> > +This control accepts a `struct viif_l1_hdrc_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_HDRC_LTM:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_HDRC_LTM
> > +------------------------------------------
> > +
> > +This control sets parameter for HDR Compression Local Tone Mapping
> feature.
> > +
> > +This control accepts a `struct viif_l1_hdrc_ltm_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_GAMMA:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_GAMMA
> > +---------------------------------------
> > +
> > +This control sets parameter for gamma correction at L1ISP.
> > +
> > +This control accepts a `struct viif_l1_gamma_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_IMG_QUALITY_ADJUSTMENT:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_IMG_QUALITY_ADJUSTMENT
> > +--------------------------------------------------------
> > +
> > +This control sets parameter for VPRO feature which is composed of:
> > +
> > +* luminance adjustment:
> > +
> > + * brightness adjustment
> > + * linear contrast adjusment
> > + * nonlinear contrast adjustment
> > + * luminance noise reduction
> > + * edge enhancement
> > +
> > +* chroma adjustment:
> > +
> > + * chroma suppression
> > + * color level adjustment
> > + * chroma noise reduction
> > + * coring suppression
> > + * edge chroma suppression
> > + * color noise reduction
> > +
> > +This control accepts a `struct viif_l1_img_quality_adjustment_config`
> instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AVG_LUM_GENERATION:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L1_SET_AVG_LUM_GENERATION
> > +----------------------------------------------------
> > +
> > +This control sets parameter for average luminance statistics feature.
> > +
> > +This control accepts a `struct viif_l1_avg_lum_generation_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L2_SET_UNDIST:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L2_SET_UNDIST
> > +----------------------------------------
> > +
> > +This control sets parameter for the lens undistortion feature of L2ISP.
> > +Lens undistortion parameters are defined as either or combination of
> polinomial parameter and grid table.
> > +
> > +This control accepts a `struct viif_l2_undist_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L2_SET_ROI:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L2_SET_ROI
> > +-------------------------------------
> > +
> > +This control sets dimensions of intermediate images and scaling parameter
> of L2ISP.
> > +If you want to crop the output image, you should set crop parameter
> > +to the corresponding source pad of the ISP subdevice with media-ctl tool.
> > +
> > +This control accepts a `struct viif_l2_roi_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_ISP_L2_SET_GAMMA:
> > +
> > +V4L2_CID_VISCONTI_VIIF_ISP_L2_SET_GAMMA
> > +---------------------------------------
> > +
> > +This control sets gamma parameter for L2ISP.
> > +
> > +This control accepts a `struct viif_l2_gamma_config` instance.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_CSI2RX_GET_CALIBRATION_STATUS:
> > +
> > +V4L2_CID_VISCONTI_VIIF_CSI2RX_GET_CALIBRATION_STATUS
> > +----------------------------------------------------
> > +
> > +This control provides CSI2 receiver calibration status.
> > +
> > +This control fills a `struct viif_csi2rx_cal_status` instance with current
> status.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_CSI2RX_GET_ERR_STATUS:
> > +
> > +V4L2_CID_VISCONTI_VIIF_CSI2RX_GET_ERR_STATUS
> > +--------------------------------------------
> > +
> > +This control provides CSI2 receiver error description.
> > +
> > +This control fills a `struct viif_csi2rx_err_status` instance with accumerated
> error status.
> > +Note that internal accumerated status is cleared after reading.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_GET_LAST_CAPTURE_STATUS:
> > +
> > +V4L2_CID_VISCONTI_VIIF_GET_LAST_CAPTURE_STATUS
> > +----------------------------------------------
> > +
> > +This control provides status information for the last captured frame.
> > +
> > +This control fills a `struct viif_l1_info` instance with current status.
> > +
> > +.. _V4L2_CID_VISCONTI_VIIF_GET_REPORTED_ERRORS:
> > +
> > +V4L2_CID_VISCONTI_VIIF_GET_REPORTED_ERRORS
> > +------------------------------------------
> > +
> > +This control provides error information since the last read of this control.
> > +
> > +This control fills a `struct viif_reported_errors` instance with accumerated
> error status.
> > +Note that internal accumerated status is cleared after reading.
> > +
> > +Structures
> > +==========
> > +
> > +.. kernel-doc:: include/uapi/linux/visconti_viif.h
> 
> Instead of using controls, all ISP drivers merged within five or so years use a
> parameter buffer. This could be said as being the best known approach to pass
> the parameters to the ISP. Could you do the same here?
> 

I'll try implement parameter buffer.

> > +
> > diff --git
> > a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
> > b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
> > index f9f73530a6be..2f0e4f955167 100644
> > --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
> > +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
> > @@ -295,6 +295,10 @@ still cause this situation.
> >        - ``p_av1_film_grain``
> >        - A pointer to a struct :c:type:`v4l2_ctrl_av1_film_grain`. Valid if this
> control is
> >          of type ``V4L2_CTRL_TYPE_AV1_FILM_GRAIN``.
> > +    * - void *
> > +      - ``ptr``
> > +      - A pointer to Visconti ISP control specific structure. Valid if this
> control is
> > +        of type ``V4L2_CTRL_TYPE_VISCONTI_ISP``
> >      * - void *
> >        - ``ptr``
> >        - A pointer to a compound type which can be an N-dimensional
> > array diff --git
> > a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
> > b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
> > index 4d38acafe8e1..cd57fac8bbf9 100644
> > --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
> > +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
> > @@ -549,6 +549,11 @@ See also the examples in :ref:`control`.
> >        - n/a
> >        - A struct :c:type:`v4l2_ctrl_av1_film_grain`, containing AV1 Film
> Grain
> >          parameters for stateless video decoders.
> > +    * - ``V4L2_CTRL_TYPE_VISCONTI_ISP``
> > +      - n/a
> > +      - n/a
> > +      - n/a
> > +      - Structs specific for Visconti ISP configuration controls.
> >
> >  .. raw:: latex
> >
> > diff --git
> > a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> > b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> > index 3e58aac4ef0b..dbab7527445e 100644
> > --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> > +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> > @@ -165,6 +165,7 @@ replace symbol V4L2_CTRL_TYPE_AV1_SEQUENCE
> > :c:type:`v4l2_ctrl_type`  replace symbol
> > V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY :c:type:`v4l2_ctrl_type`
> replace
> > symbol V4L2_CTRL_TYPE_AV1_FRAME :c:type:`v4l2_ctrl_type`  replace
> > symbol V4L2_CTRL_TYPE_AV1_FILM_GRAIN :c:type:`v4l2_ctrl_type`
> > +replace symbol V4L2_CTRL_TYPE_VISCONTI_ISP :c:type:`v4l2_ctrl_type`
> >
> >  # V4L2 capability defines
> >  replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
> 
> --
> Kind regards,
> 
> Sakari Ailus

Regards,
Yuji



From anshuman.khandual at arm.com  Sun Dec  3 20:48:16 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 4 Dec 2023 10:18:16 +0530
Subject: [PATCH V2 1/7] coresight: replicator: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <58882cab-89ce-4554-aee4-24e70d82fc09@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-2-anshuman.khandual@arm.com>
 <20231201123515.gntwvhsxd5nzojn7@bogus>
 <58882cab-89ce-4554-aee4-24e70d82fc09@arm.com>
Message-ID: <b9f407c7-62af-47e1-bea9-c494cdfed1e9@arm.com>



On 12/4/23 09:56, Anshuman Khandual wrote:
> 
> 
> On 12/1/23 18:05, Sudeep Holla wrote:
>> On Fri, Dec 01, 2023 at 11:50:47AM +0530, Anshuman Khandual wrote:
>>> Add support for the dynamic replicator device in the platform driver, which
>>> can then be used on ACPI based platforms. This change would now allow
>>> runtime power management for repliacator devices on ACPI based systems.
>>>
>>> The driver would try to enable the APB clock if available. Also, rename the
>>> code to reflect the fact that it now handles both static and dynamic
>>> replicators.
>>>
>>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>>
>> Except the minor nit below which may apply also for few other patches
>> in the series
>>
>> Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
>> Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
>>
>> [...]
>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
>>> index b6be73034996..64de0bee02ec 100644
>>> --- a/drivers/hwtracing/coresight/coresight-replicator.c
>>> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
>>> @@ -38,6 +38,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>>>  struct replicator_drvdata {
>>>  	void __iomem		*base;
>>>  	struct clk		*atclk;
>>> +	struct clk		*pclk;
>>
>> [minor nit] Perhaps can be documented as well ?
> 
> Sure, will add the following comment above the structure.
> 
> @pclk:    optional clock for the core parts of the replicator.

My bad, this will be the following instead.

diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index 64de0bee02ec..44b9a77ec8aa 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -31,6 +31,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
  * @base:      memory mapped base address for this component. Also indicates
  *             whether this one is programmable or not.
  * @atclk:     optional clock for the core parts of the replicator.
+ * @pclk:      APB clock if present, otherwise NULL
  * @csdev:     component vitals needed by the framework
  * @spinlock:  serialize enable/disable operations.
  * @check_idfilter_val: check if the context is lost upon clock removal.

I will update replicator, tpiu, tmc, and stm devices.

struct catu_drvdata and debug_drvdata do not have the comment section itself.


From peteryin.openbmc at gmail.com  Sun Dec  3 21:41:29 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Mon,  4 Dec 2023 13:41:29 +0800
Subject: [PATCH v4 0/2] Add Facebook Minerva Harma (AST2600) BMC
Message-ID: <20231204054131.1845775-1-peter.yin@quantatw.com>

From: Peter Yin <peteryin.openbmc at gmail.com>

Summary:
Add linux device tree entry related to Minerva Harma
specific devices connected to BMC SoC.

v3:https://lore.kernel.org/all/20231123050415.3441429-3-peteryin.openbmc at gmail.com/
v2:https://lore.kernel.org/all/cdbc75b9-3be1-4017-9bee-c8f161b6843c at linaro.org/
v1:https://lore.kernel.org/all/20231024082404.735843-3-peteryin.openbmc at gmail.com/

Change log
v3 -> v4
  - Add SGPIO line name

v2 -> v3:
  - Fixed led schema
  - Fixed i2c mux schema
  - Add BMC_READY and SGPIO_READY

v1 -> v2:
  - Add Power sensors
  - Modify ehci number
  - Add Led
  - Modify SGPIO line-name
v1:
  - Create minerva harma dts file.

Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
Peter Yin (2):
  dt-bindings: arm: aspeed: add Meta Minerva Harma board
  ARM: dts: aspeed: Minerva Harma: Add Facebook Minerva Harma (AST2600)
    BMC

 .../bindings/arm/aspeed/aspeed.yaml           |   1 +
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-facebook-harma.dts  | 595 ++++++++++++++++++
 3 files changed, 597 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts

-- 
2.25.1



From peteryin.openbmc at gmail.com  Sun Dec  3 21:41:30 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Mon,  4 Dec 2023 13:41:30 +0800
Subject: [PATCH v4 1/2] dt-bindings: arm: aspeed: add Meta Minerva Harma board
In-Reply-To: <20231204054131.1845775-1-peter.yin@quantatw.com>
References: <20231204054131.1845775-1-peter.yin@quantatw.com>
Message-ID: <20231204054131.1845775-2-peter.yin@quantatw.com>

From: Peter Yin <peteryin.openbmc at gmail.com>

Document the new compatibles used on Meta Minerva Harma.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
 Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index e17b3d66d6e5..20e3be8d8c78 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -79,6 +79,7 @@ properties:
               - facebook,elbert-bmc
               - facebook,fuji-bmc
               - facebook,greatlakes-bmc
+              - facebook,minerva-harma
               - facebook,yosemite4-bmc
               - ibm,everest-bmc
               - ibm,rainier-bmc
-- 
2.25.1



From peteryin.openbmc at gmail.com  Sun Dec  3 21:41:31 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Mon,  4 Dec 2023 13:41:31 +0800
Subject: [PATCH v4 2/2] ARM: dts: aspeed: Minerva Harma: Add Facebook Minerva Harma (AST2600) BMC
In-Reply-To: <20231204054131.1845775-1-peter.yin@quantatw.com>
References: <20231204054131.1845775-1-peter.yin@quantatw.com>
Message-ID: <20231204054131.1845775-3-peter.yin@quantatw.com>

From: Peter Yin <peteryin.openbmc at gmail.com>

Add linux device tree entry related to
Minerva Harma specific devices connected to BMC SoC.

Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-facebook-harma.dts  | 595 ++++++++++++++++++
 2 files changed, 596 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts

diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 23cbc7203a8e..dfb4905cb14d 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -19,6 +19,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-facebook-fuji.dtb \
 	aspeed-bmc-facebook-galaxy100.dtb \
 	aspeed-bmc-facebook-greatlakes.dtb \
+	aspeed-bmc-facebook-minerva-harma.dtb \
 	aspeed-bmc-facebook-minipack.dtb \
 	aspeed-bmc-facebook-tiogapass.dtb \
 	aspeed-bmc-facebook-wedge40.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
new file mode 100644
index 000000000000..5a1c14412458
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
@@ -0,0 +1,595 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2023 Facebook Inc.
+
+/dts-v1/;
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/i2c/i2c.h>
+
+/ {
+	model = "Facebook Minerva Harma";
+	compatible = "facebook,minerva-harma", "aspeed,ast2600";
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart6;
+		serial2 = &uart2;
+		serial4 = &uart5;
+
+		i2c20 = &imux20;
+		i2c21 = &imux21;
+		i2c22 = &imux22;
+		i2c23 = &imux23;
+		i2c24 = &imux24;
+		i2c25 = &imux25;
+		i2c26 = &imux26;
+		i2c27 = &imux27;
+		i2c28 = &imux28;
+		i2c29 = &imux29;
+		i2c30 = &imux30;
+		i2c31 = &imux31;
+	};
+
+	chosen {
+		stdout-path = &uart5;
+	};
+
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+
+	iio-hwmon {
+		compatible = "iio-hwmon";
+		io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+			      <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+			      <&adc1 2>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			label = "bmc_heartbeat_amber";
+			gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led-1 {
+			label = "fp_id_amber ";
+			default-state = "off";
+			gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+// HOST BIOS Debug
+&uart1 {
+	status = "okay";
+};
+
+// SOL Host Console
+&uart2 {
+	status = "okay";
+	pinctrl-0 = <>;
+};
+
+// SOL BMC Console
+&uart4 {
+	status = "okay";
+	pinctrl-0 = <>;
+};
+
+// BMC Debug Console
+&uart5 {
+	status = "okay";
+};
+
+// MTIA
+&uart6 {
+	status = "okay";
+};
+
+&uart_routing {
+	status = "okay";
+};
+
+&vuart1 {
+	status = "okay";
+	virtual;
+	port=<0x3e8>;
+	sirq = <7>;
+	sirq-polarity = <0>;
+	dma-mode;
+	dma-channel = <12>;
+};
+
+&wdt1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdtrst1_default>;
+	aspeed,reset-type = "soc";
+	aspeed,external-signal;
+	aspeed,ext-push-pull;
+	aspeed,ext-active-high;
+	aspeed,ext-pulse-duration = <256>;
+};
+
+&mac3 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rmii4_default>;
+	no-hw-checksum;
+	use-ncsi;
+	ncsi-ctrl,start-redo-probe;
+	ncsi-ctrl,no-channel-monitor;
+	mlx,multi-host;
+	ncsi-package = <1>;
+	ncsi-channel = <1>;
+	ncsi-rexmit = <1>;
+	ncsi-timeout = <2>;
+};
+
+&rtc {
+	status = "okay";
+};
+
+&fmc {
+	status = "okay";
+
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "bmc";
+		spi-max-frequency = <50000000>;
+#include "openbmc-flash-layout-128.dtsi"
+	};
+
+	flash at 1 {
+		status = "okay";
+		m25p,fast-read;
+		label = "alt-bmc";
+		spi-max-frequency = <50000000>;
+	};
+};
+
+// BIOS Flash
+&spi2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spi2_default>;
+
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "pnor";
+		spi-max-frequency = <12000000>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
+	};
+};
+
+&kcs2 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca8>;
+};
+
+&kcs3 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca2>;
+};
+
+&i2c0 {
+	status = "okay";
+
+	max31790 at 30{
+		compatible = "max31790";
+		reg = <0x30>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
+
+&i2c1 {
+	status = "okay";
+
+	tmp75 at 4b {
+		compatible = "ti,tmp75";
+		reg = <0x4b>;
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	max31790 at 30{
+		compatible = "max31790";
+		reg = <0x30>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
+
+&i2c3 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9543";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux20: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux21: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
+};
+
+&i2c4 {
+	status = "okay";
+	// PDB FRU
+	eeprom at 52 {
+		compatible = "atmel,24c64";
+		reg = <0x52>;
+	};
+
+	delta_brick at 69 {
+		compatible = "pmbus";
+		reg = <0x69>;
+	};
+};
+
+&i2c5 {
+	status = "okay";
+};
+
+&i2c6 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9543";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux22: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux23: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
+};
+
+&i2c7 {
+	status = "okay";
+};
+
+&i2c8 {
+	status = "okay";
+};
+
+&i2c9 {
+	status = "okay";
+
+	gpio at 30 {
+		compatible = "nxp,pca9555";
+		reg = <0x30>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+	gpio at 31 {
+		compatible = "nxp,pca9555";
+		reg = <0x31>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	i2c-mux at 71 {
+		compatible = "nxp,pca9546";
+		reg = <0x71>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux24: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux25: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+		imux26: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+		imux27: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+	};
+	// PTTV FRU
+	eeprom at 52 {
+		compatible = "atmel,24c64";
+		reg = <0x52>;
+	};
+};
+
+&i2c11 {
+	status = "okay";
+};
+
+&i2c12 {
+	status = "okay";
+};
+
+&i2c13 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9545";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux28: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux29: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			//MB FRU
+			eeprom at 54 {
+				compatible = "atmel,24c64";
+				reg = <0x54>;
+			};
+		};
+		imux30: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+		imux31: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+	};
+};
+
+// To Debug card
+&i2c14 {
+	status = "okay";
+	multi-master;
+
+	ipmb at 10 {
+		compatible = "ipmb-dev";
+		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+		i2c-protocol;
+	};
+};
+
+&i2c15 {
+	status = "okay";
+
+	// SCM FRU
+	eeprom at 50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+	};
+
+	// BSM FRU
+	eeprom at 56 {
+		compatible = "atmel,24c64";
+		reg = <0x56>;
+	};
+};
+
+&adc0 {
+	aspeed,int-vref-microvolt = <2500000>;
+	status = "okay";
+	pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+		&pinctrl_adc2_default &pinctrl_adc3_default
+		&pinctrl_adc4_default &pinctrl_adc5_default
+		&pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+	aspeed,int-vref-microvolt = <2500000>;
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc10_default>;
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-names = "default";
+	gpio-line-names =
+	/*A0-A7*/	"","","","","","","","",
+	/*B0-B7*/	"","","","",
+			"FM_BMC_MUX_CS_SPI_SEL_0","FM_ID_LED_N","","",
+	/*C0-C7*/	"","","","","","","","",
+	/*D0-D7*/	"","","SOL_UART_SET","","","","","",
+	/*E0-E7*/	"","","","","","","","",
+	/*F0-F7*/	"","","","","","","","",
+	/*G0-G7*/	"","","","","","","","",
+	/*H0-H7*/	"","","","","","","","",
+	/*I0-I7*/	"","","","","","","","",
+	/*J0-J7*/	"","","","","","","","",
+	/*K0-K7*/	"","","","","","","","",
+	/*L0-L7*/	"","","","","","","","",
+	/*M0-M7*/	"","","","","","","","",
+	/*N0-N7*/	"LED_POSTCODE_0","LED_POSTCODE_1",
+			"LED_POSTCODE_2","LED_POSTCODE_3",
+			"LED_POSTCODE_4","LED_POSTCODE_5",
+			"LED_POSTCODE_6","LED_POSTCODE_7",
+	/*O0-O7*/	"","","","","","","","",
+	/*P0-P7*/	"FP_SYS_PWRBTN_IN_N","BMC_SYS_PWRBTN_OUT_N",
+			"FP_RST_BTN_IN_N","","","","","",
+	/*Q0-Q7*/	"","","","","","","","",
+	/*R0-R7*/	"","","","","","","","",
+	/*S0-S7*/	"","","","","","","","",
+	/*T0-T7*/	"","","","","","","","",
+	/*U0-U7*/	"","","","","","","","",
+	/*V0-V7*/	"","","","","BAT_DETECT","","","",
+	/*W0-W7*/	"","","","","","","","",
+	/*X0-X7*/	"","","","","","","","",
+	/*Y0-Y7*/	"","","","","","","","",
+	/*Z0-Z7*/	"","","","","","","","";
+};
+
+&sgpiom0 {
+	status = "okay";
+	max-ngpios = <128>;
+	ngpios = <128>;
+	bus-frequency = <2000000>;
+	gpio-line-names =
+	/*in - out - in - out */
+	/*A0-A3 line 0-7*/
+	"FM_SCM_CABLE_PRSNT_N","FM_PWRDIS_E1S_0",
+	"FM_EXP_AUX_PWR_EN","",
+	"FM_EXP_MAIN_PWR_EN","FM_PWRDIS_E1S_1",
+	"PWRGD_EXP_PWR","",
+	/*A4-A7 line 8-15*/
+	"PWRGD_P12V_MEM","FM_MODULE_PWR_EN",
+	"PWRGD_P3V3_STBY","FM_HOST_PWRGD",
+	"PWRGD_P1V8","FM_CRD_PWRGD_L",
+	"FM_PRSNT_CPU_N","FM_SMI_ACTIVE_N",
+	/*B0-B3 line 16-23*/
+	"FM_PVDD33_S5_EN","BMC_CPU_NMI_N",
+	"RGD_PVDD33_S5","NMI_SYNC_FLOOD_N",
+	"FM_PVDD18_S5_EN","",
+	"PWRGD_PVDD18_S5","",
+	/*B4-B7 line 24-31*/
+	"PWRGD_SB_STBY_PWROK","FM_CPU_SP5R1",
+	"RST_RSMRST_PLD_N","FM_CPU_SP5R2",
+	"SYS_SCM_PWRBTN_N","FM_CPU_SP5R3",
+	"SYS_PWRBTN_N","FM_CPU_SP5R4",
+	/*C0-C3 line 32-39*/
+	"FM_SLPS5_PLD_N","FM_CPU0_SA0",
+	"FM_SLPS3_PLD_N","FM_CPU0_SA1",
+	"FM_PVDD11_S3_EN","FM_RT_CPU0_P0_LVS_EN",
+	"PWRGD_CHGK","FM_RT_CPU0_P1_LVS_EN",
+	/*C4-C7 line 40-47*/
+	"PWRGD_CHAE","FM_SMB_RT_ROM_P0_SEL",
+	"PWRGD_PVDD11_S3","FM_SMB_RT_ROM_P1_SEL",
+	"PVDDCR_CPU0_EN","FM_I3C_CPU_MUX0_OE_N",
+	"PWRGD_PVDDCR_CPU0","FM_I3C_CPU_MUX0_SEL",
+	/*D0-D3 line 48-55*/
+	"PVDDCR_CPU1_EN","FM_I3C_CPU_MUX1_OE_N",
+	"PWRGD_PVDDCR_CPU1","FM_I3C_CPU_MUX1_SEL",
+	"PVDDCR_SOC_EN","RST_BMC_N",
+	"PWRGD_PVDDCR_SOC","RST_MUX_CPU0_P0_N",
+	/*D4-D7 line 56-63*/
+	"PVDDIO_EN","RST_MUX_CPU0_P1_N",
+	"PWRGD_PVDDIO","RST_MUX_E1S_N",
+	"PLD_SYS_POWER_GOOD","RST_MUX_MB_N",
+	"FM_CPU_PWR_GOOD","RST_SMB_E1S_0_N",
+	/*E0-E3 line 64-71*/
+	"FM_PWRGD_CPU_PWROK","RST_SMB_E1S_1_N",
+	"PLD_BIOS_POST_CMPLT_N","RST_SRST_CPLD_SCM_N",
+	"FM_PRSNT_E1S_0_N","RST_USB_HUB_R_N",
+	"FM_E1S_0_EN","BMC_RST_BTN_OUT_N",
+	/*E4-E7 line 72-79*/
+	"FM_PRSNT_E1S_1_N","RST_CPU_KBRST_N",
+	"FM_E1S_1_EN","RST_PLTRST_SCM_N",
+	"FM_P0V9_RT_EN1","BMC_JTAG_MUX_SEL_0",
+	"PWRGD_P0V9_RT1","BMC_JTAG_MUX_SEL_1",
+	/*F0-F3 line 80-87*/
+	"FM_P0V9_RT_EN2","BMC_JTAG_SEL",
+	"PWRGD_P0V9_RT2","BMC_READY_N",
+	"FM_P1V8_CPU1_RT_EN","BMC_SGPIO_READY",
+	"PWRGD_P1V8_CPU1_RT","FM_RT_CPU0_P0_LVS_EN_FORCE",
+	/*F4-F7 line 88-95*/
+	"FM_MODULES_0_PRSNT1_N","FM_RT_CPU0_P1_LVS_EN_FORCE",
+	"FM_MODULES_1_PRSNT1_N","FM_BIOS_MRC_DEBUG_MSG_DIS",
+	"FM_PWRGD_MODULE","",
+	"FM_CMM_PRS_L","",
+	/*G0-G3 line 96-103*/
+	"FM_CPU_CORETYPE2","",
+	"FM_CPU_CORETYPE1","",
+	"FM_CPU_CORETYPE0","",
+	"FM_BOARD_REV_ID5","",
+	/*G4-G7 line 104-111*/
+	"FM_BOARD_REV_ID4","",
+	"FM_BOARD_REV_ID3","",
+	"FM_BOARD_REV_ID2","",
+	"FM_BOARD_REV_ID1","",
+	/*H0-H3 line 112-119*/
+	"FM_BOARD_REV_ID0","",
+	"FM_FAN_0_PWRGD_L","",
+	"FM_FAN_1_PWRGD_L","",
+	"FM_UART_SCM_BUF_0_EN","",
+	/*H4-H7 line 120-127*/
+	"FM_UART_SCM_BUF_1_EN","",
+	"FM_EXP_PRSNT3_N","",
+	"FM_EXP_PRSNT2_N","",
+	"FM_EXP_PRSNT1_N","",
+	/*I0-I3 line 128-135*/
+	"FM_EXP_PRSNT0_N","",
+	"FM_EXP_SLOT_ID1","",
+	"FM_EXP_SLOT_ID0","",
+	"FM_FORCE_POWERON_N","",
+	/*I4-I7 line 136-143*/
+	"FM_P5V_USB_SW_EN_N","",
+	"FM_JTAG_SCM_SEL","",
+	"FM_RST_CPU_RESET_N","",
+	"FM_SOL_UART_CH_SEL","",
+	/*J0-J3 line 144-151*/
+	"RST_MB_STBY_SCM_N","",
+	"","",
+	"RST_PCIE_MODULES_PERST0","",
+	"RST_ROT_CPU","",
+	/*J4-J7 line 152-159*/
+	"SLOT_ID_BCB_0","",
+	"SLOT_ID_BCB_1","",
+	"SLOT_ID_BCB_2","",
+	"SLOT_ID_BCB_3","",
+	/*K0-K3 line 160-167*/
+	"FM_RT_CPU0_P0_LVS_EN_R","",
+	"FM_RT_CPU0_P1_LVS_EN_R","",
+	"","","","",
+	/*K4-K7 line 168-175*/
+	"","","","","","","","",
+	/*L0-L3 line 176-183*/
+	"","","","","","","","",
+	/*L4-L7 line 184-191*/
+	"","","","","","","","",
+	/*M0-M3 line 192-199*/
+	"","","","","","","","",
+	/*M4-M7 line 200-207*/
+	"","","","","","","","",
+	/*N0-N3 line 208-215*/
+	"","","","","","","","",
+	/*N4-N7 line 216-223*/
+	"","","","","","","","",
+	/*O0-O3 line 224-231*/
+	"","","","","","","","",
+	/*O4-O7 line 232-239*/
+	"","","","","","","","",
+	/*P0-P3 line 240-247*/
+	"","","","","","","","",
+	/*P4-P7 line 248-255*/
+	"","","","","","","","";
+};
-- 
2.25.1



From wenst at chromium.org  Sun Dec  3 22:28:20 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon, 4 Dec 2023 14:28:20 +0800
Subject: [RFC PATCH v3 1/5] of: dynamic: Add of_changeset_update_prop_string
In-Reply-To: <CAD=FV=V_v11eZ6+3gUwOvdWGNM9owG7zCK5EiezTY7RJ3eaEMw@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-2-wenst@chromium.org>
 <CAD=FV=V_v11eZ6+3gUwOvdWGNM9owG7zCK5EiezTY7RJ3eaEMw@mail.gmail.com>
Message-ID: <CAGXv+5GiwgF4CJBPT7JucV8qEMY0jLAvT3TqRzvLjCKcVMZ0Mg@mail.gmail.com>

On Sat, Dec 2, 2023 at 9:01?AM Doug Anderson <dianders at chromium.org> wrote:
>
> Hi,
>
> On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >
> > @@ -1039,3 +1039,50 @@ int of_changeset_add_prop_u32_array(struct of_changeset *ocs,
> >         return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(of_changeset_add_prop_u32_array);
> > +
> > +static int of_changeset_update_prop_helper(struct of_changeset *ocs,
> > +                                          struct device_node *np,
> > +                                          const struct property *pp)
> > +{
> > +       struct property *new_pp;
> > +       int ret;
> > +
> > +       new_pp = __of_prop_dup(pp, GFP_KERNEL);
> > +       if (!new_pp)
> > +               return -ENOMEM;
> > +
> > +       ret = of_changeset_update_property(ocs, np, new_pp);
> > +       if (ret) {
> > +               kfree(new_pp->name);
> > +               kfree(new_pp->value);
> > +               kfree(new_pp);
>
> Given that this is the 3rd copy of the freeing logic, does it make
> sense to make __of_prop_free() that's documented to free what was
> returned by __of_prop_dupe()?

Makes sense.  There's also one in property_list_free(). I'll add a patch
for it.

ChenYu


From anshuman.khandual at arm.com  Sun Dec  3 22:48:33 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 4 Dec 2023 12:18:33 +0530
Subject: [PATCH V2 3/7] coresight: catu: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <56e9bc16-7962-46c6-858d-53aa7a6c8555@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-4-anshuman.khandual@arm.com>
 <56e9bc16-7962-46c6-858d-53aa7a6c8555@arm.com>
Message-ID: <7c7acbf5-a6d5-4fe6-92ca-c5b3be2e85af@arm.com>



On 12/1/23 19:11, Suzuki K Poulose wrote:
> Hi Anshuman,
> 
> On 01/12/2023 06:20, Anshuman Khandual wrote:
>> Add support for the catu devices in a new platform driver, which can then
>> be used on ACPI based platforms. This change would now allow runtime power
>> management for ACPI based systems. The driver would try to enable the APB
>> clock if available.
> 
> This doesn't talk about the new helper. As such I would prefer that to be a separate preparatory patch. See below.

Makes sense.

> 
>>
>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Cc: Mike Leach <mike.leach at linaro.org>
>> Cc: James Clark <james.clark at arm.com>
>> Cc: linux-acpi at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: coresight at lists.linaro.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>> ? drivers/acpi/arm64/amba.c??????????????????? |?? 1 -
>> ? drivers/hwtracing/coresight/coresight-catu.c | 130 ++++++++++++++++---
>> ? drivers/hwtracing/coresight/coresight-catu.h |?? 1 +
>> ? drivers/hwtracing/coresight/coresight-core.c |? 29 +++++
>> ? include/linux/coresight.h??????????????????? |?? 7 +
>> ? 5 files changed, 149 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
>> index afb6afb66967..587061b0fd2f 100644
>> --- a/drivers/acpi/arm64/amba.c
>> +++ b/drivers/acpi/arm64/amba.c
>> @@ -27,7 +27,6 @@ static const struct acpi_device_id amba_id_list[] = {
>> ????? {"ARMHC503", 0}, /* ARM CoreSight Debug */
>> ????? {"ARMHC979", 0}, /* ARM CoreSight TPIU */
>> ????? {"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
>> -??? {"ARMHC9CA", 0}, /* ARM CoreSight CATU */
>> ????? {"", 0},
>> ? };
>> ? diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
>> index 3949ded0d4fa..ba5ee7d158dd 100644
>> --- a/drivers/hwtracing/coresight/coresight-catu.c
>> +++ b/drivers/hwtracing/coresight/coresight-catu.c
>> @@ -7,6 +7,8 @@
>> ?? * Author: Suzuki K Poulose <suzuki.poulose at arm.com>
>> ?? */
>> ? +#include <linux/platform_device.h>
>> +#include <linux/acpi.h>
>> ? #include <linux/amba/bus.h>
>> ? #include <linux/device.h>
>> ? #include <linux/dma-mapping.h>
>> @@ -502,28 +504,20 @@ static const struct coresight_ops catu_ops = {
>> ????? .helper_ops = &catu_helper_ops,
>> ? };
>> ? -static int catu_probe(struct amba_device *adev, const struct amba_id *id)
>> +static int __catu_probe(struct device *dev, struct resource *res)
>> ? {
>> ????? int ret = 0;
>> ????? u32 dma_mask;
>> -??? struct catu_drvdata *drvdata;
>> +??? struct catu_drvdata *drvdata = dev_get_drvdata(dev);
>> ????? struct coresight_desc catu_desc;
>> ????? struct coresight_platform_data *pdata = NULL;
>> -??? struct device *dev = &adev->dev;
>> ????? void __iomem *base;
>> ? ????? catu_desc.name = coresight_alloc_device_name(&catu_devs, dev);
>> ????? if (!catu_desc.name)
>> ????????? return -ENOMEM;
>> ? -??? drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>> -??? if (!drvdata) {
>> -??????? ret = -ENOMEM;
>> -??????? goto out;
>> -??? }
>> -
>> -??? dev_set_drvdata(dev, drvdata);
>> -??? base = devm_ioremap_resource(dev, &adev->res);
>> +??? base = devm_ioremap_resource(dev, res);
>> ????? if (IS_ERR(base)) {
>> ????????? ret = PTR_ERR(base);
>> ????????? goto out;
>> @@ -568,18 +562,35 @@ static int catu_probe(struct amba_device *adev, const struct amba_id *id)
>> ????? if (IS_ERR(drvdata->csdev))
>> ????????? ret = PTR_ERR(drvdata->csdev);
>> ????? else
>> -??????? pm_runtime_put(&adev->dev);
>> +??????? pm_runtime_put(dev);
>> ? out:
>> ????? return ret;
>> ? }
>> ? -static void catu_remove(struct amba_device *adev)
>> +static int catu_probe(struct amba_device *adev, const struct amba_id *id)
>> +{
>> +??? struct catu_drvdata *drvdata;
>> +
>> +??? drvdata = devm_kzalloc(&adev->dev, sizeof(*drvdata), GFP_KERNEL);
>> +??? if (!drvdata)
>> +??????? return -ENOMEM;
>> +
>> +??? amba_set_drvdata(adev, drvdata);
>> +??? return __catu_probe(&adev->dev, &adev->res);
>> +}
>> +
>> +static void __catu_remove(struct device *dev)
>> ? {
>> -??? struct catu_drvdata *drvdata = dev_get_drvdata(&adev->dev);
>> +??? struct catu_drvdata *drvdata = dev_get_drvdata(dev);
>> ? ????? coresight_unregister(drvdata->csdev);
>> ? }
>> ? +static void catu_remove(struct amba_device *adev)
>> +{
>> +??? __catu_remove(&adev->dev);
>> +}
>> +
>> ? static struct amba_id catu_ids[] = {
>> ????? CS_AMBA_ID(0x000bb9ee),
>> ????? {},
>> @@ -598,13 +609,96 @@ static struct amba_driver catu_driver = {
>> ????? .id_table??????????? = catu_ids,
>> ? };
>> ? +static int catu_platform_probe(struct platform_device *pdev)
>> +{
>> +??? struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +??? struct catu_drvdata *drvdata;
>> +??? int ret = 0;
>> +
>> +??? drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
>> +??? if (!drvdata)
>> +??????? return -ENOMEM;
>> +
>> +??? drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
>> +??? if (IS_ERR(drvdata->pclk))
>> +??????? return -ENODEV;
>> +
>> +??? if (res) {
>> +??????? drvdata->base = devm_ioremap_resource(&pdev->dev, res);
>> +??????? if (IS_ERR(drvdata->base)) {
>> +??????????? clk_put(drvdata->pclk);
>> +??????????? return PTR_ERR(drvdata->base);
>> +??????? }
>> +??? }
>> +
>> +??? pm_runtime_get_noresume(&pdev->dev);
>> +??? pm_runtime_set_active(&pdev->dev);
>> +??? pm_runtime_enable(&pdev->dev);
>> +
>> +??? dev_set_drvdata(&pdev->dev, drvdata);
>> +??? ret = __catu_probe(&pdev->dev, res);
>> +??? if (ret) {
>> +??????? pm_runtime_put_noidle(&pdev->dev);
>> +??????? pm_runtime_disable(&pdev->dev);
>> +??? }
>> +??? return ret;
>> +}
>> +
>> +static int catu_platform_remove(struct platform_device *pdev)
>> +{
>> +??? __catu_remove(&pdev->dev);
>> +??? return 0;
>> +}
>> +
>> +#ifdef CONFIG_PM
>> +static int catu_runtime_suspend(struct device *dev)
>> +{
>> +??? struct catu_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> +??? if (drvdata->pclk && !IS_ERR_OR_NULL(drvdata->pclk))
> 
> Only the second part is needed. IS_ERR_OR_NULL() already checks for NULL.

Actually, the first check here should be for valid drvdata instead,
ensuring that subsequent de-referencing for drvdata->pclk does not
crash. Will do this replacement for all affected patches.

> 
>> +??????? clk_disable_unprepare(drvdata->pclk);
>> +??? return 0;
>> +}
>> +
>> +static int catu_runtime_resume(struct device *dev)
>> +{
>> +??? struct catu_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> +??? if (drvdata->pclk && !IS_ERR_OR_NULL(drvdata->pclk))
> 
> Same here.
> 
>> +??????? clk_prepare_enable(drvdata->pclk);
>> +??? return 0;
>> +}
>> +#endif
>> +
>> +static const struct dev_pm_ops catu_dev_pm_ops = {
>> +??? SET_RUNTIME_PM_OPS(catu_runtime_suspend, catu_runtime_resume, NULL)
>> +};
>> +
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id catu_acpi_ids[] = {
>> +??? {"ARMHC9CA", 0}, /* ARM CoreSight CATU */
>> +??? {},
>> +};
>> +
>> +MODULE_DEVICE_TABLE(acpi, catu_acpi_ids);
>> +#endif
>> +
>> +static struct platform_driver catu_platform_driver = {
>> +??? .probe??? = catu_platform_probe,
>> +??? .remove??? = catu_platform_remove,
>> +??? .driver??? = {
>> +??????? .name??????????? = "coresight-catu-platform",
>> +??????? .acpi_match_table??? = ACPI_PTR(catu_acpi_ids),
>> +??????? .suppress_bind_attrs??? = true,
>> +??????? .pm??????????? = &catu_dev_pm_ops,
>> +??? },
>> +};
>> +
>> ? static int __init catu_init(void)
>> ? {
>> ????? int ret;
>> ? -??? ret = amba_driver_register(&catu_driver);
>> -??? if (ret)
>> -??????? pr_info("Error registering catu driver\n");
>> +??? ret = coresight_init_driver("catu", &catu_driver, &catu_platform_driver);
>> ????? tmc_etr_set_catu_ops(&etr_catu_buf_ops);
>> ????? return ret;
>> ? }
>> @@ -612,7 +706,7 @@ static int __init catu_init(void)
>> ? static void __exit catu_exit(void)
>> ? {
>> ????? tmc_etr_remove_catu_ops();
>> -??? amba_driver_unregister(&catu_driver);
>> +??? coresight_remove_driver(&catu_driver, &catu_platform_driver);
>> ? }
>> ? ? module_init(catu_init);
>> diff --git a/drivers/hwtracing/coresight/coresight-catu.h b/drivers/hwtracing/coresight/coresight-catu.h
>> index 442e034bbfba..141feac1c14b 100644
>> --- a/drivers/hwtracing/coresight/coresight-catu.h
>> +++ b/drivers/hwtracing/coresight/coresight-catu.h
>> @@ -61,6 +61,7 @@
>> ? #define CATU_IRQEN_OFF??????? 0x0
>> ? ? struct catu_drvdata {
>> +??? struct clk *pclk;
>> ????? void __iomem *base;
>> ????? struct coresight_device *csdev;
>> ????? int irq;
>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
>> index 9fabe00a40d6..ede9b0723f95 100644
>> --- a/drivers/hwtracing/coresight/coresight-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>> @@ -1833,6 +1833,35 @@ static void __exit coresight_exit(void)
>> ? module_init(coresight_init);
>> ? module_exit(coresight_exit);
>> ? 
> 
> ---8>---
> 
>> +int coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
>> +????????????? struct platform_driver *pdev_drv)
>> +{
>> +??? int ret;
>> +
>> +??? ret = amba_driver_register(amba_drv);
>> +??? if (ret) {
>> +??????? pr_err("%s: error registering AMBA driver\n", drv);
>> +??????? return ret;
>> +??? }
>> +
>> +??? ret = platform_driver_register(pdev_drv);
>> +??? if (!ret)
>> +??????? return 0;
>> +
>> +??? pr_err("%s: error registering platform driver\n", drv);
>> +??? amba_driver_unregister(amba_drv);
>> +??? return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(coresight_init_driver);
>> +
>> +void coresight_remove_driver(struct amba_driver *amba_drv,
>> +???????????????? struct platform_driver *pdev_drv)
>> +{
>> +??? amba_driver_unregister(amba_drv);
>> +??? platform_driver_unregister(pdev_drv);
>> +}
>> +EXPORT_SYMBOL_GPL(coresight_remove_driver);
> 
> Please could we split this into a separate patch itself ? Also, can we not use them for the other components ? funnel, replicator ?

Sure, will split the helpers addition along with their header changes
into a separate patch at the beginning of this series, and then use
them for funnel and replicator devices in subsequent patches.

> 
> 
>> +
>> ? MODULE_LICENSE("GPL v2");
>> ? MODULE_AUTHOR("Pratik Patel <pratikp at codeaurora.org>");
>> ? MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier at linaro.org>");
>> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
>> index a269fffaf991..be7fe3793763 100644
>> --- a/include/linux/coresight.h
>> +++ b/include/linux/coresight.h
>> @@ -12,6 +12,8 @@
>> ? #include <linux/io.h>
>> ? #include <linux/perf_event.h>
>> ? #include <linux/sched.h>
>> +#include <linux/amba/bus.h>
>> +#include <linux/platform_device.h>
>> ? ? /* Peripheral id registers (0xFD0-0xFEC) */
>> ? #define CORESIGHT_PERIPHIDR4??? 0xfd0
>> @@ -597,6 +599,11 @@ void coresight_relaxed_write64(struct coresight_device *csdev,
>> ???????????????????? u64 val, u32 offset);
>> ? void coresight_write64(struct coresight_device *csdev, u64 val, u32 offset);
>> ? +int coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
>> +????????????? struct platform_driver *pdev_drv);
>> +
>> +void coresight_remove_driver(struct amba_driver *amba_drv,
>> +???????????????? struct platform_driver *pdev_drv);
>> ? #else
>> ? static inline struct coresight_device *
>> ? coresight_register(struct coresight_desc *desc) { return NULL; }
> 
> 
> Suzuki


From wenst at chromium.org  Sun Dec  3 22:59:29 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon, 4 Dec 2023 14:59:29 +0800
Subject: [RFC PATCH v3 4/5] arm64: dts: mediatek: mt8173-elm-hana: Mark
 touchscreens and trackpads as fail
In-Reply-To: <CAD=FV=W01gfxV6RN2o6CVS7jjf8qgKP-jUy9Bp94d2hWzVC48A@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-5-wenst@chromium.org>
 <CAD=FV=W01gfxV6RN2o6CVS7jjf8qgKP-jUy9Bp94d2hWzVC48A@mail.gmail.com>
Message-ID: <CAGXv+5E+R292XsOFSL-j0KJMmVJjWtxMRgCK8besP7mo6NDOWA@mail.gmail.com>

On Sat, Dec 2, 2023 at 8:58?AM Doug Anderson <dianders at chromium.org> wrote:
>
> Hi,
>
> On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >
> > @@ -44,6 +46,7 @@ trackpad2: trackpad at 2c {
> >                 reg = <0x2c>;
> >                 hid-descr-addr = <0x0020>;
> >                 wakeup-source;
> > +               status = "fail-needs-probe";
>
> While doing this, you could also remove the hack where the trackpad
> IRQ pinctrl is listed under i2c4.

Sure. I do think we can do away with it though. According to at least one
schematic, the interrupt line has pull-ups on both sides of the voltage
shifter.

BTW, The touchscreen doesn't have pinctrl entries. This has pull-ups on
both sides of the voltage shifter as well.

ChenYu


From wenst at chromium.org  Sun Dec  3 23:24:42 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon, 4 Dec 2023 15:24:42 +0800
Subject: [RFC PATCH v3 3/5] platform/chrome: Introduce device tree
 hardware prober
In-Reply-To: <CAD=FV=XV0+G=uFBE_n6WFGVW2szGcKToZgCNTdSrNf3LVk9MOQ@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-4-wenst@chromium.org>
 <CAD=FV=XV0+G=uFBE_n6WFGVW2szGcKToZgCNTdSrNf3LVk9MOQ@mail.gmail.com>
Message-ID: <CAGXv+5Hz3wfjCRa2AiOQgOv7zo8bzAmtG=a=jWJhO2MZNrFtpw@mail.gmail.com>

On Sat, Dec 2, 2023 at 8:58?AM Doug Anderson <dianders at chromium.org> wrote:
>
> Hi,
>
> On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >
> > @@ -61,6 +61,17 @@ config CHROMEOS_TBMC
> >           To compile this driver as a module, choose M here: the
> >           module will be called chromeos_tbmc.
> >
> > +config CHROMEOS_OF_HW_PROBER
> > +       bool "ChromeOS Device Tree Hardware Prober"
>
> Any reason that it can't be a module?

No technical one. However if it's a module, the user has to manually load
it. So I think it's more of a usability thing.

OOTH I think this needs to be a module if I2C is built as a module.
Somehow I had thought of it at one point but then it slipped my mind.

> > +       depends on OF
> > +       depends on I2C
> > +       select OF_DYNAMIC
> > +       default OF
>
> You probably don't want "default OF". This means that everyone will
> automatically get this new driver enabled which is unlikely to be
> right.

I thought this whole section was guarded behind KCONFIG_CHROME_PLATFORMS.
So if the user has CHROME_PLATFORMS enabled and has OF enabled, they
likely need the prober.

> > +static int chromeos_of_hw_prober_probe(struct platform_device *pdev)
> > +{
> > +       for (size_t i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
> > +               if (of_machine_is_compatible(hw_prober_platforms[i].compatible)) {
> > +                       int ret;
> > +
> > +                       ret = hw_prober_platforms[i].prober(&pdev->dev,
> > +                                                           hw_prober_platforms[i].data);
> > +                       if (ret)
>
> Should it only check for -EPROBE_DEFER here? ...and then maybe warn
> for other cases and go through the loop? If there's some error
> enabling the touchscreen I'd still want the trackpad to probe...

Makes sense. However there's no extra information to give in the
warning though.

> > +                               return ret;
> > +               }
> > +
> > +       return 0;
>
> Random thought: once we get here, the driver is useless / just wasting
> memory. Any way to have it freed? ;-)

I don't think there is a good way to do that, except maybe marking all
the functions as __init? But that likely doesn't work in combination
with deferred probing (say the i2c driver is a module).

ChenYu


From mihai.sain at microchip.com  Sun Dec  3 23:25:37 2023
From: mihai.sain at microchip.com (Mihai Sain)
Date: Mon, 4 Dec 2023 09:25:37 +0200
Subject: [PATCH] ARM: dts: microchip: sama5d27_wlsom1_ek: Remove mmc-ddr-3_3v property from sdmmc0 node
Message-ID: <20231204072537.2991-1-mihai.sain@microchip.com>

On board the sdmmc0 interface is wired to a SD Card socket.
According with mmc-controller bindings, the mmc-ddr-3_3v property
is used for eMMC devices to enable high-speed DDR mode (3.3V I/O).
Remove the mmc-ddr-3_3v property from sdmmc0 node.

Signed-off-by: Mihai Sain <mihai.sain at microchip.com>
---
 arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
index e055b9e2fe34..15239834d886 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
@@ -197,7 +197,6 @@ qspi1_flash: flash at 0 {
 
 &sdmmc0 {
 	bus-width = <4>;
-	mmc-ddr-3_3v;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_sdmmc0_default>;
 	status = "okay";
-- 
2.43.0



From claudiu.beznea at tuxon.dev  Sun Dec  3 23:34:16 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Mon, 4 Dec 2023 09:34:16 +0200
Subject: [PATCH 04/14] clk: renesas: r9a08g045-cpg: Add clock and reset
 support for ETH0 and ETH1
In-Reply-To: <CAMuHMdWwn8xcKX3vgawtGqksuMM3CKZx=3k6EKP3kDFZxbocdA@mail.gmail.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-5-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdWwn8xcKX3vgawtGqksuMM3CKZx=3k6EKP3kDFZxbocdA@mail.gmail.com>
Message-ID: <abbf8d0b-b766-4734-b4e9-a963e1dc8810@tuxon.dev>

Hi, Geert,

On 01.12.2023 17:59, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> RZ/G3S has 2 Gigabit Ethernet interfaces available. Add clock and reset
>> support for both of them.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> Thanks for your patch!
> 
>> --- a/drivers/clk/renesas/r9a08g045-cpg.c
>> +++ b/drivers/clk/renesas/r9a08g045-cpg.c
>> @@ -217,6 +219,16 @@ static const struct rzg2l_mod_clk r9a08g045_mod_clks[] = {
>>                                         MSTOP(PERI_COM, BIT(11))),
>>         DEF_MOD("sdhi2_aclk",           R9A08G045_SDHI2_ACLK, R9A08G045_CLK_P1, 0x554, 11,
>>                                         MSTOP(PERI_COM, BIT(11))),
>> +       DEF_COUPLED("eth0_axi",         R9A08G045_ETH0_CLK_AXI, R9A08G045_CLK_M0, 0x57c, 0,
>> +                                       MSTOP(PERI_COM, BIT(2))),
>> +       DEF_COUPLED("eth0_chi",         R9A08G045_ETH0_CLK_CHI, R9A08G045_CLK_ZT, 0x57c, 0,
>> +                                       MSTOP(PERI_COM, BIT(2))),
>> +       DEF_MOD("eth0_refclk",          R9A08G045_ETH0_REFCLK, R9A08G045_CLK_HP, 0x57c, 8, 0),
>> +       DEF_COUPLED("eth1_axi",         R9A08G045_ETH1_CLK_AXI, R9A08G045_CLK_M0, 0x57c, 1,
>> +                                       MSTOP(PERI_COM, BIT(3))),
>> +       DEF_COUPLED("eth1_chi",         R9A08G045_ETH1_CLK_CHI, R9A08G045_CLK_ZT, 0x57c, 1,
>> +                                       MSTOP(PERI_COM, BIT(3))),
>> +       DEF_MOD("eth1_refclk",          R9A08G045_ETH1_REFCLK, R9A08G045_CLK_HP, 0x57c, 9, 0),
>>         DEF_MOD("scif0_clk_pck",        R9A08G045_SCIF0_CLK_PCK, R9A08G045_CLK_P0, 0x584, 0,
>>                                         MSTOP(MCPU2, BIT(1))),
>>         DEF_MOD("gpio_hclk",            R9A08G045_GPIO_HCLK, R9A08G045_OSCCLK, 0x598, 0, 0),
> 
> LGTM, pending the MSTOP() part.
> 
> Is the MSTOP() handling needed to function? IIUIC, all modules are
> enabled
> out of reset.

MSTOP is not needed for Ethernet to work. Indeed, all modules are enabled
out of reset.

> If it is not needed, I can take this patch and remove the MSTOP() part.

It's OK for me. Thank you for handling this.

Anyway, let me know if you encounter issues with it so I can resend it.

Thank you,
Claudiu Beznea

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 


From claudiu.beznea at tuxon.dev  Sun Dec  3 23:37:59 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Mon, 4 Dec 2023 09:37:59 +0200
Subject: [PATCH 05/14] pinctrl: renesas: rzg2l: Move arg in the main
 function block
In-Reply-To: <CAMuHMdWJJ=pjY5YFG=UxL+rWhYtWKicjbGUj-7KC1tgaz4tB3Q@mail.gmail.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-6-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdWJJ=pjY5YFG=UxL+rWhYtWKicjbGUj-7KC1tgaz4tB3Q@mail.gmail.com>
Message-ID: <f2282f18-e789-4f1e-a321-4c744c952537@tuxon.dev>



On 01.12.2023 18:15, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> Move arg in the main block of the function as this is used by 3 out of 4
>> case blocks of switch-case. In this way some lines of code are removed.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> Thanks for your patch!
> 
>>  drivers/pinctrl/renesas/pinctrl-rzg2l.c | 11 ++++++-----
>>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> Unfortunately your claim is not really backed by the diffstat.
> What about moving index, too?

Sure, I can move it, too.

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 


From claudiu.beznea at tuxon.dev  Sun Dec  3 23:41:51 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Mon, 4 Dec 2023 09:41:51 +0200
Subject: [PATCH 10/14] arm64: renesas: r9a08g045: Add Ethernet nodes
In-Reply-To: <CAMuHMdW9Unpw7NQOGWd4SeFV8XgvRYTKTXnt9Tsagb3Q3U9tNA@mail.gmail.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-11-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdW9Unpw7NQOGWd4SeFV8XgvRYTKTXnt9Tsagb3Q3U9tNA@mail.gmail.com>
Message-ID: <96dd3f54-9560-4587-b4e8-bf75422ff5ef@tuxon.dev>

Hi, Geert,

On 01.12.2023 19:35, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> Add Ethernet nodes available on RZ/G3S (R9A08G045).
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
> Thanks for your patch!
> 
>> --- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
>> @@ -149,6 +149,38 @@ sdhi2: mmc at 11c20000 {
>>                         status = "disabled";
>>                 };
>>
>> +               eth0: ethernet at 11c30000 {
>> +                       compatible = "renesas,r9a08g045-gbeth", "renesas,rzg2l-gbeth";
>> +                       reg = <0 0x11c30000 0 0x10000>;
>> +                       interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
>> +                                    <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
>> +                                    <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
>> +                       interrupt-names = "mux", "fil", "arp_ns";
>> +                       clocks = <&cpg CPG_MOD R9A08G045_ETH0_CLK_AXI>,
>> +                                <&cpg CPG_MOD R9A08G045_ETH0_CLK_CHI>,
>> +                                <&cpg CPG_MOD R9A08G045_ETH0_REFCLK>;
>> +                       clock-names = "axi", "chi", "refclk";
>> +                       resets = <&cpg R9A08G045_ETH0_RST_HW_N>;
>> +                       power-domains = <&cpg>;
> 
> Perhaps add a default phy mode, like on other SoCs?
> 
>     phy-mode = "rgmii"';

I skipped this (even it was available on the other SoCs) as I consider the
phy-mode is board specific.

> 
> Also missing:
> 
>     #address-cells = <1>;
>     #size-cells = <0>;

Same for these.

> 
>> +                       status = "disabled";
>> +               };
> 
> Same comments for eth1.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 


From krzysztof.kozlowski at linaro.org  Sun Dec  3 23:49:50 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 08:49:50 +0100
Subject: [PATCH v4 00/23] pinctrl: Convert struct group_desc to use struct
 pingroup
In-Reply-To: <CACRpkdZAriTP3iOgmwvoAH-3-aO_ugoEkBHE7mHH5YLxhMXSXg@mail.gmail.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <CACRpkdZAriTP3iOgmwvoAH-3-aO_ugoEkBHE7mHH5YLxhMXSXg@mail.gmail.com>
Message-ID: <b2175abe-b989-4b77-891e-67e8240ba0be@linaro.org>

On 01/12/2023 15:05, Linus Walleij wrote:
> On Wed, Nov 29, 2023 at 5:15?PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> 
>> The struct group_desc has a lot of duplication with struct pingroup.
>> Deduplicate that by embeddind the latter in the former and convert
>> users.
>>
>> Linus, assuming everything is fine, I can push this to my tree.
>> Or you can apply it (assumming all CIs and people are happy with
>> the series).
> 
> I applied the series to devel so we get some rotation in linux-next,
> augmenting the relevant commit messages as discussed!
> 

... and this next fails to build on standard defconfig:
https://krzk.eu/#/builders/76/builds/420/steps/9/logs/stdio

I did not bisect yet, so I am just guessing that error looks like
something introduced here.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec  3 23:51:15 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 08:51:15 +0100
Subject: [PATCH v4 00/23] pinctrl: Convert struct group_desc to use struct
 pingroup
In-Reply-To: <b2175abe-b989-4b77-891e-67e8240ba0be@linaro.org>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <CACRpkdZAriTP3iOgmwvoAH-3-aO_ugoEkBHE7mHH5YLxhMXSXg@mail.gmail.com>
 <b2175abe-b989-4b77-891e-67e8240ba0be@linaro.org>
Message-ID: <ed981149-5d96-43a9-9534-c1e52443a983@linaro.org>

On 04/12/2023 08:49, Krzysztof Kozlowski wrote:
> On 01/12/2023 15:05, Linus Walleij wrote:
>> On Wed, Nov 29, 2023 at 5:15?PM Andy Shevchenko
>> <andriy.shevchenko at linux.intel.com> wrote:
>>
>>> The struct group_desc has a lot of duplication with struct pingroup.
>>> Deduplicate that by embeddind the latter in the former and convert
>>> users.
>>>
>>> Linus, assuming everything is fine, I can push this to my tree.
>>> Or you can apply it (assumming all CIs and people are happy with
>>> the series).
>>
>> I applied the series to devel so we get some rotation in linux-next,
>> augmenting the relevant commit messages as discussed!
>>
> 
> ... and this next fails to build on standard defconfig:
> https://krzk.eu/#/builders/76/builds/420/steps/9/logs/stdio
> 
> I did not bisect yet, so I am just guessing that error looks like
> something introduced here.

One more for arm32 defconfig:
https://krzk.eu/#/builders/5/builds/2532/steps/9/logs/stdio

Best regards,
Krzysztof



From wenst at chromium.org  Sun Dec  3 23:53:31 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon, 4 Dec 2023 15:53:31 +0800
Subject: [RFC PATCH v3 3/5] platform/chrome: Introduce device tree
 hardware prober
In-Reply-To: <CAGXv+5Hz3wfjCRa2AiOQgOv7zo8bzAmtG=a=jWJhO2MZNrFtpw@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-4-wenst@chromium.org>
 <CAD=FV=XV0+G=uFBE_n6WFGVW2szGcKToZgCNTdSrNf3LVk9MOQ@mail.gmail.com> <CAGXv+5Hz3wfjCRa2AiOQgOv7zo8bzAmtG=a=jWJhO2MZNrFtpw@mail.gmail.com>
Message-ID: <CAGXv+5HQeXPyRVFXaPKwX6GDoeMVM0Sneqk4CJx1AWGYT-mAEg@mail.gmail.com>

On Mon, Dec 4, 2023 at 3:24?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> On Sat, Dec 2, 2023 at 8:58?AM Doug Anderson <dianders at chromium.org> wrote:
> >
> > Hi,
> >
> > On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
> > >
> > > @@ -61,6 +61,17 @@ config CHROMEOS_TBMC
> > >           To compile this driver as a module, choose M here: the
> > >           module will be called chromeos_tbmc.
> > >
> > > +config CHROMEOS_OF_HW_PROBER
> > > +       bool "ChromeOS Device Tree Hardware Prober"
> >
> > Any reason that it can't be a module?
>
> No technical one. However if it's a module, the user has to manually load
> it. So I think it's more of a usability thing.

We could probably manually add module aliases. I thought about aliases
against the machine compatibles, but there doesn't seem to be a device
for it to trigger. Or target something common to ChromeOS devices like
the EC? It's really hacky though.

ChenYu

> OOTH I think this needs to be a module if I2C is built as a module.
> Somehow I had thought of it at one point but then it slipped my mind.
>
> > > +       depends on OF
> > > +       depends on I2C
> > > +       select OF_DYNAMIC
> > > +       default OF
> >
> > You probably don't want "default OF". This means that everyone will
> > automatically get this new driver enabled which is unlikely to be
> > right.
>
> I thought this whole section was guarded behind KCONFIG_CHROME_PLATFORMS.
> So if the user has CHROME_PLATFORMS enabled and has OF enabled, they
> likely need the prober.
>
> > > +static int chromeos_of_hw_prober_probe(struct platform_device *pdev)
> > > +{
> > > +       for (size_t i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
> > > +               if (of_machine_is_compatible(hw_prober_platforms[i].compatible)) {
> > > +                       int ret;
> > > +
> > > +                       ret = hw_prober_platforms[i].prober(&pdev->dev,
> > > +                                                           hw_prober_platforms[i].data);
> > > +                       if (ret)
> >
> > Should it only check for -EPROBE_DEFER here? ...and then maybe warn
> > for other cases and go through the loop? If there's some error
> > enabling the touchscreen I'd still want the trackpad to probe...
>
> Makes sense. However there's no extra information to give in the
> warning though.
>
> > > +                               return ret;
> > > +               }
> > > +
> > > +       return 0;
> >
> > Random thought: once we get here, the driver is useless / just wasting
> > memory. Any way to have it freed? ;-)
>
> I don't think there is a good way to do that, except maybe marking all
> the functions as __init? But that likely doesn't work in combination
> with deferred probing (say the i2c driver is a module).
>
> ChenYu


From geert at linux-m68k.org  Mon Dec  4 00:02:12 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 4 Dec 2023 09:02:12 +0100
Subject: [PATCH 10/14] arm64: renesas: r9a08g045: Add Ethernet nodes
In-Reply-To: <96dd3f54-9560-4587-b4e8-bf75422ff5ef@tuxon.dev>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-11-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdW9Unpw7NQOGWd4SeFV8XgvRYTKTXnt9Tsagb3Q3U9tNA@mail.gmail.com> <96dd3f54-9560-4587-b4e8-bf75422ff5ef@tuxon.dev>
Message-ID: <CAMuHMdWGbEhBdzK4Swu4uX05vX7H2Ow4uE1C=JVNOrdcbZYL=A@mail.gmail.com>

Hi Claudiu,

On Mon, Dec 4, 2023 at 8:41?AM claudiu beznea <claudiu.beznea at tuxon.dev> wrote:
> On 01.12.2023 19:35, Geert Uytterhoeven wrote:
> > On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> >> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>
> >> Add Ethernet nodes available on RZ/G3S (R9A08G045).
> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
> >> +++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
> >> @@ -149,6 +149,38 @@ sdhi2: mmc at 11c20000 {
> >>                         status = "disabled";
> >>                 };
> >>
> >> +               eth0: ethernet at 11c30000 {
> >> +                       compatible = "renesas,r9a08g045-gbeth", "renesas,rzg2l-gbeth";
> >> +                       reg = <0 0x11c30000 0 0x10000>;
> >> +                       interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
> >> +                                    <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> >> +                                    <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
> >> +                       interrupt-names = "mux", "fil", "arp_ns";
> >> +                       clocks = <&cpg CPG_MOD R9A08G045_ETH0_CLK_AXI>,
> >> +                                <&cpg CPG_MOD R9A08G045_ETH0_CLK_CHI>,
> >> +                                <&cpg CPG_MOD R9A08G045_ETH0_REFCLK>;
> >> +                       clock-names = "axi", "chi", "refclk";
> >> +                       resets = <&cpg R9A08G045_ETH0_RST_HW_N>;
> >> +                       power-domains = <&cpg>;
> >
> > Perhaps add a default phy mode, like on other SoCs?
> >
> >     phy-mode = "rgmii"';
>
> I skipped this (even it was available on the other SoCs) as I consider the
> phy-mode is board specific.

IC.  Still, it's good to have some consistency across boards.

> > Also missing:
> >
> >     #address-cells = <1>;
> >     #size-cells = <0>;
>
> Same for these.

These are required, and always have the same values, so it makes more
sense to have them in the SoC .dtsi file, once.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From peteryin.openbmc at gmail.com  Mon Dec  4 00:10:27 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Mon,  4 Dec 2023 16:10:27 +0800
Subject: [PATCH v5 0/2] Add Facebook Minerva Harma (AST2600) BMC
Message-ID: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>

Summary:
Add linux device tree entry related to Minerva Harma
specific devices connected to BMC SoC.

v4:https://lore.kernel.org/all/20231204054131.1845775-3-peter.yin at quantatw.com/
v3:https://lore.kernel.org/all/20231123050415.3441429-3-peteryin.openbmc at gmail.com/
v2:https://lore.kernel.org/all/cdbc75b9-3be1-4017-9bee-c8f161b6843c at linaro.org/
v1:https://lore.kernel.org/all/20231024082404.735843-3-peteryin.openbmc at gmail.com/

Change log
v4 -> v5
  - Rename document and file from minerva-harma to harma. 

v3 -> v4
  - Add SGPIO line name.

v2 -> v3:
  - Fixed led schema.
  - Fixed i2c mux schema.
  - Add BMC_READY and SGPIO_READY.

v1 -> v2:
  - Add Power sensors.
  - Modify ehci number.
  - Add Led.
  - Modify SGPIO line-name.
v1:
  - Create minerva harma dts file.

Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
Peter Yin (2):
  dt-bindings: arm: aspeed: add Meta Harma board
  ARM: dts: aspeed: Harma: Add Facebook Harma (AST2600) BMC

 .../bindings/arm/aspeed/aspeed.yaml           |   1 +
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-facebook-harma.dts  | 595 ++++++++++++++++++
 3 files changed, 597 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts

-- 
2.25.1



From peteryin.openbmc at gmail.com  Mon Dec  4 00:10:28 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Mon,  4 Dec 2023 16:10:28 +0800
Subject: [PATCH v5 1/2] dt-bindings: arm: aspeed: add Meta Harma board
In-Reply-To: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
References: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
Message-ID: <20231204081029.2272626-2-peteryin.openbmc@gmail.com>

Document the new compatibles used on Meta Harma.

Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
 Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index e17b3d66d6e55..fac3cda3f4870 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -79,6 +79,7 @@ properties:
               - facebook,elbert-bmc
               - facebook,fuji-bmc
               - facebook,greatlakes-bmc
+              - facebook,harma-bmc
               - facebook,yosemite4-bmc
               - ibm,everest-bmc
               - ibm,rainier-bmc
-- 
2.25.1



From peteryin.openbmc at gmail.com  Mon Dec  4 00:10:29 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Mon,  4 Dec 2023 16:10:29 +0800
Subject: [PATCH v5 2/2] ARM: dts: aspeed: Harma: Add Facebook Harma (AST2600) BMC
In-Reply-To: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
References: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
Message-ID: <20231204081029.2272626-3-peteryin.openbmc@gmail.com>

Add linux device tree entry related to
Harma specific devices connected to BMC SoC.

Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-facebook-harma.dts  | 595 ++++++++++++++++++
 2 files changed, 596 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts

diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 23cbc7203a8e3..92ba3208d2a27 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -19,6 +19,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-facebook-fuji.dtb \
 	aspeed-bmc-facebook-galaxy100.dtb \
 	aspeed-bmc-facebook-greatlakes.dtb \
+	aspeed-bmc-facebook-harma.dtb \
 	aspeed-bmc-facebook-minipack.dtb \
 	aspeed-bmc-facebook-tiogapass.dtb \
 	aspeed-bmc-facebook-wedge40.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
new file mode 100644
index 0000000000000..86c7937674b46
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
@@ -0,0 +1,595 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2023 Facebook Inc.
+
+/dts-v1/;
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/i2c/i2c.h>
+
+/ {
+	model = "Facebook Harma";
+	compatible = "facebook,harma-bmc", "aspeed,ast2600";
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart6;
+		serial2 = &uart2;
+		serial4 = &uart5;
+
+		i2c20 = &imux20;
+		i2c21 = &imux21;
+		i2c22 = &imux22;
+		i2c23 = &imux23;
+		i2c24 = &imux24;
+		i2c25 = &imux25;
+		i2c26 = &imux26;
+		i2c27 = &imux27;
+		i2c28 = &imux28;
+		i2c29 = &imux29;
+		i2c30 = &imux30;
+		i2c31 = &imux31;
+	};
+
+	chosen {
+		stdout-path = &uart5;
+	};
+
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+
+	iio-hwmon {
+		compatible = "iio-hwmon";
+		io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+			      <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+			      <&adc1 2>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			label = "bmc_heartbeat_amber";
+			gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led-1 {
+			label = "fp_id_amber ";
+			default-state = "off";
+			gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+// HOST BIOS Debug
+&uart1 {
+	status = "okay";
+};
+
+// SOL Host Console
+&uart2 {
+	status = "okay";
+	pinctrl-0 = <>;
+};
+
+// SOL BMC Console
+&uart4 {
+	status = "okay";
+	pinctrl-0 = <>;
+};
+
+// BMC Debug Console
+&uart5 {
+	status = "okay";
+};
+
+// MTIA
+&uart6 {
+	status = "okay";
+};
+
+&uart_routing {
+	status = "okay";
+};
+
+&vuart1 {
+	status = "okay";
+	virtual;
+	port=<0x3e8>;
+	sirq = <7>;
+	sirq-polarity = <0>;
+	dma-mode;
+	dma-channel = <12>;
+};
+
+&wdt1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdtrst1_default>;
+	aspeed,reset-type = "soc";
+	aspeed,external-signal;
+	aspeed,ext-push-pull;
+	aspeed,ext-active-high;
+	aspeed,ext-pulse-duration = <256>;
+};
+
+&mac3 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rmii4_default>;
+	no-hw-checksum;
+	use-ncsi;
+	ncsi-ctrl,start-redo-probe;
+	ncsi-ctrl,no-channel-monitor;
+	mlx,multi-host;
+	ncsi-package = <1>;
+	ncsi-channel = <1>;
+	ncsi-rexmit = <1>;
+	ncsi-timeout = <2>;
+};
+
+&rtc {
+	status = "okay";
+};
+
+&fmc {
+	status = "okay";
+
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "bmc";
+		spi-max-frequency = <50000000>;
+#include "openbmc-flash-layout-128.dtsi"
+	};
+
+	flash at 1 {
+		status = "okay";
+		m25p,fast-read;
+		label = "alt-bmc";
+		spi-max-frequency = <50000000>;
+	};
+};
+
+// BIOS Flash
+&spi2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spi2_default>;
+
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "pnor";
+		spi-max-frequency = <12000000>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
+	};
+};
+
+&kcs2 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca8>;
+};
+
+&kcs3 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca2>;
+};
+
+&i2c0 {
+	status = "okay";
+
+	max31790 at 30{
+		compatible = "max31790";
+		reg = <0x30>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
+
+&i2c1 {
+	status = "okay";
+
+	tmp75 at 4b {
+		compatible = "ti,tmp75";
+		reg = <0x4b>;
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	max31790 at 30{
+		compatible = "max31790";
+		reg = <0x30>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
+
+&i2c3 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9543";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux20: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux21: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
+};
+
+&i2c4 {
+	status = "okay";
+	// PDB FRU
+	eeprom at 52 {
+		compatible = "atmel,24c64";
+		reg = <0x52>;
+	};
+
+	delta_brick at 69 {
+		compatible = "pmbus";
+		reg = <0x69>;
+	};
+};
+
+&i2c5 {
+	status = "okay";
+};
+
+&i2c6 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9543";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux22: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux23: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
+};
+
+&i2c7 {
+	status = "okay";
+};
+
+&i2c8 {
+	status = "okay";
+};
+
+&i2c9 {
+	status = "okay";
+
+	gpio at 30 {
+		compatible = "nxp,pca9555";
+		reg = <0x30>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+	gpio at 31 {
+		compatible = "nxp,pca9555";
+		reg = <0x31>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	i2c-mux at 71 {
+		compatible = "nxp,pca9546";
+		reg = <0x71>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux24: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux25: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+		imux26: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+		imux27: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+	};
+	// PTTV FRU
+	eeprom at 52 {
+		compatible = "atmel,24c64";
+		reg = <0x52>;
+	};
+};
+
+&i2c11 {
+	status = "okay";
+};
+
+&i2c12 {
+	status = "okay";
+};
+
+&i2c13 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9545";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux28: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux29: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			//MB FRU
+			eeprom at 54 {
+				compatible = "atmel,24c64";
+				reg = <0x54>;
+			};
+		};
+		imux30: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+		imux31: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+	};
+};
+
+// To Debug card
+&i2c14 {
+	status = "okay";
+	multi-master;
+
+	ipmb at 10 {
+		compatible = "ipmb-dev";
+		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+		i2c-protocol;
+	};
+};
+
+&i2c15 {
+	status = "okay";
+
+	// SCM FRU
+	eeprom at 50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+	};
+
+	// BSM FRU
+	eeprom at 56 {
+		compatible = "atmel,24c64";
+		reg = <0x56>;
+	};
+};
+
+&adc0 {
+	aspeed,int-vref-microvolt = <2500000>;
+	status = "okay";
+	pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+		&pinctrl_adc2_default &pinctrl_adc3_default
+		&pinctrl_adc4_default &pinctrl_adc5_default
+		&pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+	aspeed,int-vref-microvolt = <2500000>;
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc10_default>;
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-names = "default";
+	gpio-line-names =
+	/*A0-A7*/	"","","","","","","","",
+	/*B0-B7*/	"","","","",
+			"FM_BMC_MUX_CS_SPI_SEL_0","FM_ID_LED_N","","",
+	/*C0-C7*/	"","","","","","","","",
+	/*D0-D7*/	"","","SOL_UART_SET","","","","","",
+	/*E0-E7*/	"","","","","","","","",
+	/*F0-F7*/	"","","","","","","","",
+	/*G0-G7*/	"","","","","","","","",
+	/*H0-H7*/	"","","","","","","","",
+	/*I0-I7*/	"","","","","","","","",
+	/*J0-J7*/	"","","","","","","","",
+	/*K0-K7*/	"","","","","","","","",
+	/*L0-L7*/	"","","","","","","","",
+	/*M0-M7*/	"","","","","","","","",
+	/*N0-N7*/	"LED_POSTCODE_0","LED_POSTCODE_1",
+			"LED_POSTCODE_2","LED_POSTCODE_3",
+			"LED_POSTCODE_4","LED_POSTCODE_5",
+			"LED_POSTCODE_6","LED_POSTCODE_7",
+	/*O0-O7*/	"","","","","","","","",
+	/*P0-P7*/	"FP_SYS_PWRBTN_IN_N","BMC_SYS_PWRBTN_OUT_N",
+			"FP_RST_BTN_IN_N","","","","","",
+	/*Q0-Q7*/	"","","","","","","","",
+	/*R0-R7*/	"","","","","","","","",
+	/*S0-S7*/	"","","","","","","","",
+	/*T0-T7*/	"","","","","","","","",
+	/*U0-U7*/	"","","","","","","","",
+	/*V0-V7*/	"","","","","BAT_DETECT","","","",
+	/*W0-W7*/	"","","","","","","","",
+	/*X0-X7*/	"","","","","","","","",
+	/*Y0-Y7*/	"","","","","","","","",
+	/*Z0-Z7*/	"","","","","","","","";
+};
+
+&sgpiom0 {
+	status = "okay";
+	max-ngpios = <128>;
+	ngpios = <128>;
+	bus-frequency = <2000000>;
+	gpio-line-names =
+	/*in - out - in - out */
+	/*A0-A3 line 0-7*/
+	"FM_SCM_CABLE_PRSNT_N","FM_PWRDIS_E1S_0",
+	"FM_EXP_AUX_PWR_EN","",
+	"FM_EXP_MAIN_PWR_EN","FM_PWRDIS_E1S_1",
+	"PWRGD_EXP_PWR","",
+	/*A4-A7 line 8-15*/
+	"PWRGD_P12V_MEM","FM_MODULE_PWR_EN",
+	"PWRGD_P3V3_STBY","FM_HOST_PWRGD",
+	"PWRGD_P1V8","FM_CRD_PWRGD_L",
+	"FM_PRSNT_CPU_N","FM_SMI_ACTIVE_N",
+	/*B0-B3 line 16-23*/
+	"FM_PVDD33_S5_EN","BMC_CPU_NMI_N",
+	"RGD_PVDD33_S5","NMI_SYNC_FLOOD_N",
+	"FM_PVDD18_S5_EN","",
+	"PWRGD_PVDD18_S5","",
+	/*B4-B7 line 24-31*/
+	"PWRGD_SB_STBY_PWROK","FM_CPU_SP5R1",
+	"RST_RSMRST_PLD_N","FM_CPU_SP5R2",
+	"SYS_SCM_PWRBTN_N","FM_CPU_SP5R3",
+	"SYS_PWRBTN_N","FM_CPU_SP5R4",
+	/*C0-C3 line 32-39*/
+	"FM_SLPS5_PLD_N","FM_CPU0_SA0",
+	"FM_SLPS3_PLD_N","FM_CPU0_SA1",
+	"FM_PVDD11_S3_EN","FM_RT_CPU0_P0_LVS_EN",
+	"PWRGD_CHGK","FM_RT_CPU0_P1_LVS_EN",
+	/*C4-C7 line 40-47*/
+	"PWRGD_CHAE","FM_SMB_RT_ROM_P0_SEL",
+	"PWRGD_PVDD11_S3","FM_SMB_RT_ROM_P1_SEL",
+	"PVDDCR_CPU0_EN","FM_I3C_CPU_MUX0_OE_N",
+	"PWRGD_PVDDCR_CPU0","FM_I3C_CPU_MUX0_SEL",
+	/*D0-D3 line 48-55*/
+	"PVDDCR_CPU1_EN","FM_I3C_CPU_MUX1_OE_N",
+	"PWRGD_PVDDCR_CPU1","FM_I3C_CPU_MUX1_SEL",
+	"PVDDCR_SOC_EN","RST_BMC_N",
+	"PWRGD_PVDDCR_SOC","RST_MUX_CPU0_P0_N",
+	/*D4-D7 line 56-63*/
+	"PVDDIO_EN","RST_MUX_CPU0_P1_N",
+	"PWRGD_PVDDIO","RST_MUX_E1S_N",
+	"PLD_SYS_POWER_GOOD","RST_MUX_MB_N",
+	"FM_CPU_PWR_GOOD","RST_SMB_E1S_0_N",
+	/*E0-E3 line 64-71*/
+	"FM_PWRGD_CPU_PWROK","RST_SMB_E1S_1_N",
+	"PLD_BIOS_POST_CMPLT_N","RST_SRST_CPLD_SCM_N",
+	"FM_PRSNT_E1S_0_N","RST_USB_HUB_R_N",
+	"FM_E1S_0_EN","BMC_RST_BTN_OUT_N",
+	/*E4-E7 line 72-79*/
+	"FM_PRSNT_E1S_1_N","RST_CPU_KBRST_N",
+	"FM_E1S_1_EN","RST_PLTRST_SCM_N",
+	"FM_P0V9_RT_EN1","BMC_JTAG_MUX_SEL_0",
+	"PWRGD_P0V9_RT1","BMC_JTAG_MUX_SEL_1",
+	/*F0-F3 line 80-87*/
+	"FM_P0V9_RT_EN2","BMC_JTAG_SEL",
+	"PWRGD_P0V9_RT2","BMC_READY_N",
+	"FM_P1V8_CPU1_RT_EN","BMC_SGPIO_READY",
+	"PWRGD_P1V8_CPU1_RT","FM_RT_CPU0_P0_LVS_EN_FORCE",
+	/*F4-F7 line 88-95*/
+	"FM_MODULES_0_PRSNT1_N","FM_RT_CPU0_P1_LVS_EN_FORCE",
+	"FM_MODULES_1_PRSNT1_N","FM_BIOS_MRC_DEBUG_MSG_DIS",
+	"FM_PWRGD_MODULE","",
+	"FM_CMM_PRS_L","",
+	/*G0-G3 line 96-103*/
+	"FM_CPU_CORETYPE2","",
+	"FM_CPU_CORETYPE1","",
+	"FM_CPU_CORETYPE0","",
+	"FM_BOARD_REV_ID5","",
+	/*G4-G7 line 104-111*/
+	"FM_BOARD_REV_ID4","",
+	"FM_BOARD_REV_ID3","",
+	"FM_BOARD_REV_ID2","",
+	"FM_BOARD_REV_ID1","",
+	/*H0-H3 line 112-119*/
+	"FM_BOARD_REV_ID0","",
+	"FM_FAN_0_PWRGD_L","",
+	"FM_FAN_1_PWRGD_L","",
+	"FM_UART_SCM_BUF_0_EN","",
+	/*H4-H7 line 120-127*/
+	"FM_UART_SCM_BUF_1_EN","",
+	"FM_EXP_PRSNT3_N","",
+	"FM_EXP_PRSNT2_N","",
+	"FM_EXP_PRSNT1_N","",
+	/*I0-I3 line 128-135*/
+	"FM_EXP_PRSNT0_N","",
+	"FM_EXP_SLOT_ID1","",
+	"FM_EXP_SLOT_ID0","",
+	"FM_FORCE_POWERON_N","",
+	/*I4-I7 line 136-143*/
+	"FM_P5V_USB_SW_EN_N","",
+	"FM_JTAG_SCM_SEL","",
+	"FM_RST_CPU_RESET_N","",
+	"FM_SOL_UART_CH_SEL","",
+	/*J0-J3 line 144-151*/
+	"RST_MB_STBY_SCM_N","",
+	"","",
+	"RST_PCIE_MODULES_PERST0","",
+	"RST_ROT_CPU","",
+	/*J4-J7 line 152-159*/
+	"SLOT_ID_BCB_0","",
+	"SLOT_ID_BCB_1","",
+	"SLOT_ID_BCB_2","",
+	"SLOT_ID_BCB_3","",
+	/*K0-K3 line 160-167*/
+	"FM_RT_CPU0_P0_LVS_EN_R","",
+	"FM_RT_CPU0_P1_LVS_EN_R","",
+	"","","","",
+	/*K4-K7 line 168-175*/
+	"","","","","","","","",
+	/*L0-L3 line 176-183*/
+	"","","","","","","","",
+	/*L4-L7 line 184-191*/
+	"","","","","","","","",
+	/*M0-M3 line 192-199*/
+	"","","","","","","","",
+	/*M4-M7 line 200-207*/
+	"","","","","","","","",
+	/*N0-N3 line 208-215*/
+	"","","","","","","","",
+	/*N4-N7 line 216-223*/
+	"","","","","","","","",
+	/*O0-O3 line 224-231*/
+	"","","","","","","","",
+	/*O4-O7 line 232-239*/
+	"","","","","","","","",
+	/*P0-P3 line 240-247*/
+	"","","","","","","","",
+	/*P4-P7 line 248-255*/
+	"","","","","","","","";
+};
-- 
2.25.1



From maz at kernel.org  Mon Dec  4 00:15:27 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 08:15:27 +0000
Subject: [PATCH V15 0/8] arm64/perf: Enable branch stack sampling
In-Reply-To: <20231201053906.1261704-1-anshuman.khandual@arm.com>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
Message-ID: <86wmtubcyo.wl-maz@kernel.org>

On Fri, 01 Dec 2023 05:38:58 +0000,
Anshuman Khandual <anshuman.khandual at arm.com> wrote:
> 
> This series enables perf branch stack sampling support on arm64 platform
> via a new arch feature called Branch Record Buffer Extension (BRBE). All
> the relevant register definitions could be accessed here.
> 
> https://developer.arm.com/documentation/ddi0601/2021-12/AArch64-Registers
> 
> This series applies on 6.7-rc3 after the following series from James Clark.
> 
> https://lore.kernel.org/all/20231019165510.1966367-1-james.clark at arm.com/

Please don't base a series on another one. I haven't looked at James
series yet, and dealing with conflict is my business.

You should base it on -rc3, full stop. If there is a dependency, make
it explicit and include a prefix of the other series you depend on.

	M.

-- 
Without deviation from the norm, progress is not possible.


From krzysztof.kozlowski at linaro.org  Mon Dec  4 00:20:43 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 09:20:43 +0100
Subject: [PATCH v5 0/2] Add Facebook Minerva Harma (AST2600) BMC
In-Reply-To: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
References: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
Message-ID: <fddcbad4-5368-4c2a-ba87-f4c4326a8385@linaro.org>

On 04/12/2023 09:10, Peter Yin wrote:
> Summary:
> Add linux device tree entry related to Minerva Harma
> specific devices connected to BMC SoC.
> 
> v4:https://lore.kernel.org/all/20231204054131.1845775-3-peter.yin at quantatw.com/
> v3:https://lore.kernel.org/all/20231123050415.3441429-3-peteryin.openbmc at gmail.com/
> v2:https://lore.kernel.org/all/cdbc75b9-3be1-4017-9bee-c8f161b6843c at linaro.org/
> v1:https://lore.kernel.org/all/20231024082404.735843-3-peteryin.openbmc at gmail.com/
> 
> Change log
> v4 -> v5
>   - Rename document and file from minerva-harma to harma. 

You must explain that you dropped people's review for some reason.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec  4 00:20:48 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 09:20:48 +0100
Subject: [PATCH v5 1/2] dt-bindings: arm: aspeed: add Meta Harma board
In-Reply-To: <20231204081029.2272626-2-peteryin.openbmc@gmail.com>
References: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
 <20231204081029.2272626-2-peteryin.openbmc@gmail.com>
Message-ID: <64fe71a3-a106-4a23-acd6-a9a37bb0cd0f@linaro.org>

On 04/12/2023 09:10, Peter Yin wrote:
> Document the new compatibles used on Meta Harma.
> 
> Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
> ---
>  Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From s-vadapalli at ti.com  Mon Dec  4 00:21:07 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 4 Dec 2023 13:51:07 +0530
Subject: [PATCH 0/4] Add APIs to request TX/RX DMA channels by ID
In-Reply-To: <ed1d0221-d0ee-4a7d-8955-d5973027d113@gmail.com>
References: <20231114083906.3143548-1-s-vadapalli@ti.com>
 <9d465de4-3930-4856-9d8e-7deb567a628f@gmail.com>
 <c693efec-ab67-44bb-8871-a40dc408f278@ti.com>
 <ed1d0221-d0ee-4a7d-8955-d5973027d113@gmail.com>
Message-ID: <a4ca48fb-2e87-494a-bc71-8970d7f8c6a0@ti.com>

Hello P?ter,

On 22/11/23 20:52, P?ter Ujfalusi wrote:
> Hi Siddharth,
> 
> On 17/11/2023 07:55, Siddharth Vadapalli wrote:
>>> I would really like to follow a standard binding since what will happen
>>> if the firmware will start to provision channels/flows for DMAengine
>>> users? It is not that simple to hack that around.
>>
>> Please consider the following use-case for which the APIs are being added by
>> this series. I apologize for not explaining the idea behind the APIs in more
>> detail earlier.
>>
>> Firmware running on a remote core is in control of a peripheral (CPSW Ethernet
>> Switch for example) and shares the peripheral across software running on
>> different cores. The control path between the Firmware and the Clients on
>> various cores is via RPMsg, while the data path used by the Clients is the DMA
>> Channels. In the example where Clients send data to the shared peripheral over
>> DMA, the Clients send RPMsg based requests to the Firmware to obtain the
>> allocated thead IDs. Firmware allocates the thread IDs by making a request to
>> TISCI Resource Manager followed by sharing the thread IDs to the Clients.
>>
>> In such use cases, the Linux Client is probed by RPMsg endpoint discovery over
>> the RPMsg bus. Therefore, there is no device-tree corresponding to the Client
>> device. The Client knows the DMA Channel IDs as well as the RX Flow details from
>> the Firmware. Knowing these details, the Client can request the configuration of
>> the TX and RX Channels/Flows by using the DMA APIs which this series adds.
> 
> I see, so the CPSW will be probed in a similar way as USB peripherals
> for example? The CPSW does not have a DT entry at all? Is this correct?

I apologize for the delayed response. Yes, the CPSW instance which shall be in
control of Firmware running on the remote core will not have a DT entry. The
Linux Client driver shall be probed when the Firmware announces its endpoint
over the RPMsg bus, which the Client driver shall register with the RPMsg framework.

> 
>> Please let me know in case of any suggestions for an implementation which shall
>> address the above use-case.
> 
> How does the driver knows how to request a DMA resource from the remote
> core? How that scales with different SoCs and even with changes in the
> firmware?

After getting probed, the Client driver communicates with Firmware via RPMsg,
requesting details of the allocated resources including the TX Channels and RX
Flows. Knowing these parameters, the Client driver can use the newly added DMA
APIs to request TX Channel and RX Flows by IDs. The only dependency here is that
the Client driver needs to know which DMA instance to request these resources
from. That information is hard coded in the driver's data in the form of the
compatible used for the DMA instance, thereby allowing the Client driver to get
a reference to the DMA controller node using the of_find_compatible_node() API.

Since all the resource allocation information comes from Firmware, the
device-specific details will be hard coded in the Firmware while the Client
driver can be used across all K3 SoCs which have the same DMA APIs.

> 
> You are right, this is in a grey area. The DMA channel as it is
> controlled by the remote processor, it lends a thread to clients on
> other cores (like Linux) via RPMsg.
> Well, it is similar to how non DT is working in a way.
> 
> This CPSW type is not yet supported mainline, right?

Yes, it is not yet supported in mainline. This series is a dependency for
upstreaming the Client driver.

-- 
Regards,
Siddharth.


From maz at kernel.org  Mon Dec  4 00:22:25 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 08:22:25 +0000
Subject: [PATCH V15 2/8] KVM: arm64: Prevent guest accesses into BRBE system registers/instructions
In-Reply-To: <20231201053906.1261704-3-anshuman.khandual@arm.com>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
	<20231201053906.1261704-3-anshuman.khandual@arm.com>
Message-ID: <86v89ebcn2.wl-maz@kernel.org>

On Fri, 01 Dec 2023 05:39:00 +0000,
Anshuman Khandual <anshuman.khandual at arm.com> wrote:
> 
> Currently BRBE feature is not supported in a guest environment. This hides
> BRBE feature availability via masking ID_AA64DFR0_EL1.BRBE field. This also
> blocks guest accesses into BRBE system registers and instructions as if the
> underlying hardware never implemented FEAT_BRBE feature.
> 
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: Oliver Upton <oliver.upton at linux.dev>
> Cc: James Morse <james.morse at arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: kvmarm at lists.linux.dev
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
>  arch/arm64/kvm/sys_regs.c | 130 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 130 insertions(+)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 4735e1b37fb3..42701065b3cd 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1583,6 +1583,9 @@ static u64 read_sanitised_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
>  	/* Hide SPE from guests */
>  	val &= ~ID_AA64DFR0_EL1_PMSVer_MASK;
>  
> +	/* Hide BRBE from guests */
> +	val &= ~ID_AA64DFR0_EL1_BRBE_MASK;
> +
>  	return val;
>  }
>  
> @@ -2042,6 +2045,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  	{ SYS_DESC(SYS_DC_CISW), access_dcsw },
>  	{ SYS_DESC(SYS_DC_CIGSW), access_dcgsw },
>  	{ SYS_DESC(SYS_DC_CIGDSW), access_dcgsw },
> +	{ SYS_DESC(OP_BRB_IALL), undef_access },
> +	{ SYS_DESC(OP_BRB_INJ), undef_access },
>  
>  	DBG_BCR_BVR_WCR_WVR_EL1(0),
>  	DBG_BCR_BVR_WCR_WVR_EL1(1),
> @@ -2072,6 +2077,131 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  	{ SYS_DESC(SYS_DBGCLAIMCLR_EL1), trap_raz_wi },
>  	{ SYS_DESC(SYS_DBGAUTHSTATUS_EL1), trap_dbgauthstatus_el1 },
>  
> +	/*
> +	 * BRBE branch record sysreg address space is interleaved between
> +	 * corresponding BRBINF<N>_EL1, BRBSRC<N>_EL1, and BRBTGT<N>_EL1.
> +	 */
> +	{ SYS_DESC(SYS_BRBINF0_EL1), undef_access },
> +	{ SYS_DESC(SYS_BRBSRC0_EL1), undef_access },
> +	{ SYS_DESC(SYS_BRBTGT0_EL1), undef_access },
> +	{ SYS_DESC(SYS_BRBINF16_EL1), undef_access },
> +	{ SYS_DESC(SYS_BRBSRC16_EL1), undef_access },
> +	{ SYS_DESC(SYS_BRBTGT16_EL1), undef_access },

Surely we can do better than this wall of text. Please look at what we
do for the debug registers, and adopt a similar pattern. This should
result in one line per group of 3 registers.

What is the plan for KVM support beyond this?

	M.

-- 
Without deviation from the norm, progress is not possible.


From alexander.stein at ew.tq-group.com  Mon Dec  4 00:35:00 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 04 Dec 2023 09:35:00 +0100
Subject: [PATCH 1/1] i2c: imx: Make SDA actually optional for bus recovering
In-Reply-To: <20231203220444.thaeuyqyv36hpv2y@zenone.zhora.eu>
References: <20231130095751.65773-1-alexander.stein@ew.tq-group.com> <20231203220444.thaeuyqyv36hpv2y@zenone.zhora.eu>
Message-ID: <12335412.O9o76ZdvQC@steina-w>

Hi,

Am Sonntag, 3. Dezember 2023, 23:04:44 CET schrieb Andi Shyti:
> Hi,
> 
> On Thu, Nov 30, 2023 at 10:57:51AM +0100, Alexander Stein wrote:
> > Both i2c_generic_scl_recovery() and the debug output indicate that SDA is
> > purely optional for bus recovery. But devm_gpiod_get() never returns NULL
> > making it mandatory. Fix this my calling devm_gpiod_get_optional instead.
> 
>                                ^^^^
> as Uwe pointed out, /my/by/.
> 
> I think Wolfram can fix this before taking it.
> 
> > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> 
> otherwise:
> 
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Thanks. Let me know if I should send a v2.

Best regards,
Alexander
-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From kvalo at kernel.org  Mon Dec  4 00:37:50 2023
From: kvalo at kernel.org (Kalle Valo)
Date: Mon, 04 Dec 2023 10:37:50 +0200
Subject: [PATCH][next] wifi: mt76: mt7996: Use DECLARE_FLEX_ARRAY() and
 fix -Warray-bounds warnings
In-Reply-To: <202312021326.D3504C1@keescook> (Kees Cook's message of "Sat, 2
	Dec 2023 13:27:54 -0800")
References: <ZVaCNAohuieMmdq9@work> <202312021326.D3504C1@keescook>
Message-ID: <87zfyqqs69.fsf@kernel.org>

Kees Cook <keescook at chromium.org> writes:

> On Thu, Nov 16, 2023 at 02:57:24PM -0600, Gustavo A. R. Silva wrote:
>
>> Transform zero-length arrays `adm_stat` and `msdu_cnt` into proper
>> flexible-array members in anonymous union in `struct
>> mt7996_mcu_all_sta_info_event` via the DECLARE_FLEX_ARRAY()
>> helper; and fix multiple -Warray-bounds warnings:
>> 
>> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:483:61: warning:
>> array subscript <unknown> is outside array bounds of 'struct
>> <anonymous>[0]' [-Warray-bounds=]
>> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:490:58: warning:
>> array subscript <unknown> is outside array bounds of 'struct
>> <anonymous>[0]' [-Warray-bounds=]
>> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:492:58: warning:
>> array subscript <unknown> is outside array bounds of 'struct
>> <anonymous>[0]' [-Warray-bounds=]
>> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:469:61: warning:
>> array subscript <unknown> is outside array bounds of 'struct
>> <anonymous>[0]' [-Warray-bounds=]
>> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:477:66: warning:
>> array subscript <unknown> is outside array bounds of 'struct
>> <anonymous>[0]' [-Warray-bounds=]
>> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:479:66: warning:
>> array subscript <unknown> is outside array bounds of 'struct
>> <anonymous>[0]' [-Warray-bounds=]
>> 
>> This results in no differences in binary output, helps with the ongoing
>> efforts to globally enable -Warray-bounds.
>> 
>> Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org>
>
> *thread ping*
>
> Can wireless folks please pick this patch up?

Ok, I assigned this to me on patchwork now. Felix, please let me know if
you prefer to take this to your tree instead.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From claudiu.beznea at tuxon.dev  Mon Dec  4 00:38:20 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Mon, 4 Dec 2023 10:38:20 +0200
Subject: [PATCH 10/14] arm64: renesas: r9a08g045: Add Ethernet nodes
In-Reply-To: <CAMuHMdWGbEhBdzK4Swu4uX05vX7H2Ow4uE1C=JVNOrdcbZYL=A@mail.gmail.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-11-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdW9Unpw7NQOGWd4SeFV8XgvRYTKTXnt9Tsagb3Q3U9tNA@mail.gmail.com>
 <96dd3f54-9560-4587-b4e8-bf75422ff5ef@tuxon.dev>
 <CAMuHMdWGbEhBdzK4Swu4uX05vX7H2Ow4uE1C=JVNOrdcbZYL=A@mail.gmail.com>
Message-ID: <b3701927-e41a-44d8-8f91-da245b76f532@tuxon.dev>



On 04.12.2023 10:02, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Mon, Dec 4, 2023 at 8:41?AM claudiu beznea <claudiu.beznea at tuxon.dev> wrote:
>> On 01.12.2023 19:35, Geert Uytterhoeven wrote:
>>> On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
>>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>>
>>>> Add Ethernet nodes available on RZ/G3S (R9A08G045).
>>>>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>
>>> Thanks for your patch!
>>>
>>>> --- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
>>>> +++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
>>>> @@ -149,6 +149,38 @@ sdhi2: mmc at 11c20000 {
>>>>                         status = "disabled";
>>>>                 };
>>>>
>>>> +               eth0: ethernet at 11c30000 {
>>>> +                       compatible = "renesas,r9a08g045-gbeth", "renesas,rzg2l-gbeth";
>>>> +                       reg = <0 0x11c30000 0 0x10000>;
>>>> +                       interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
>>>> +                                    <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
>>>> +                                    <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
>>>> +                       interrupt-names = "mux", "fil", "arp_ns";
>>>> +                       clocks = <&cpg CPG_MOD R9A08G045_ETH0_CLK_AXI>,
>>>> +                                <&cpg CPG_MOD R9A08G045_ETH0_CLK_CHI>,
>>>> +                                <&cpg CPG_MOD R9A08G045_ETH0_REFCLK>;
>>>> +                       clock-names = "axi", "chi", "refclk";
>>>> +                       resets = <&cpg R9A08G045_ETH0_RST_HW_N>;
>>>> +                       power-domains = <&cpg>;
>>>
>>> Perhaps add a default phy mode, like on other SoCs?
>>>
>>>     phy-mode = "rgmii"';
>>
>> I skipped this (even it was available on the other SoCs) as I consider the
>> phy-mode is board specific.
> 
> IC.  Still, it's good to have some consistency across boards.
> 
>>> Also missing:
>>>
>>>     #address-cells = <1>;
>>>     #size-cells = <0>;
>>
>> Same for these.
> 
> These are required, and always have the same values, so it makes more
> sense to have them in the SoC .dtsi file, once.

I remember I had a compilation warning with an Ethernet controller
configured with fixed-link having #address-cells, #size-cells. With
fixed-link these were not needed.

Anyway... I'll keep all in dtsi if you prefer it this way.

Thank you,
Claudiu Beznea

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 


From tony at atomide.com  Mon Dec  4 00:38:25 2023
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 4 Dec 2023 10:38:25 +0200
Subject: [PATCH] arm64: dts: ti: k3-am625-sk: Add support for WL1837
 module onboard
In-Reply-To: <20231203140710.irc7mmwff2b5voak@observant>
References: <20231121122441.64385-1-tony@atomide.com>
 <20231123071015.is4sffvdkunko5ws@radar>
 <20231129083433.GT5169@atomide.com>
 <20231203140710.irc7mmwff2b5voak@observant>
Message-ID: <20231204083825.GL5169@atomide.com>

* Nishanth Menon <nm at ti.com> [231203 14:07]:
> dts can remain common, the m2 is a dtso, we generate a dtbo and the
> original will be an additional dtb? I think this can work out without
> dts/dtsi duplication.

That sounds good to me, I'll take a look.

> arch/arm64/boot/dts/ti/Makefile has previous examples of the form.

OK

> I believe the issue was around the wlan firmware load itself, but i
> think the mmc-pwrseq will probably help resolve it.

Yes mmc-pwrseq makes sense.

Regards,

Tony


From jasowang at redhat.com  Mon Dec  4 00:39:00 2023
From: jasowang at redhat.com (Jason Wang)
Date: Mon, 4 Dec 2023 16:39:00 +0800
Subject: [RFC PATCH] KVM: arm/arm64: GICv4: Support shared VLPI
In-Reply-To: <87fs0k94og.wl-maz@kernel.org>
References: <20231102143507.840-1-jiangkunkun@huawei.com> <87msvt6cc7.wl-maz@kernel.org>
 <1fb8353e-e9c4-2570-c2ca-ec537c18ac4d@huawei.com> <86edh228xx.wl-maz@kernel.org>
 <952bd5dc-dd20-acc3-d77e-c9b14e5728d3@huawei.com> <87fs0k94og.wl-maz@kernel.org>
Message-ID: <CACGkMEt5sapZjpyBSM5oX_=k1AcefEe5D4wtX=HqtHy4AD3j_g@mail.gmail.com>

On Sat, Dec 2, 2023 at 8:20?PM Marc Zyngier <maz at kernel.org> wrote:
>
> Hi Kunkun,
>
> On Wed, 08 Nov 2023 09:45:51 +0000,
> Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> >
> > Hi Marc,
> >
> > On 2023/11/6 23:33, Marc Zyngier wrote:
> > > On Mon, 06 Nov 2023 14:59:01 +0000,
> > > Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> > >> The virtio-pci driver write entry1-6
> > >> massage.data in the msix-table and trap to QEMU for processing. The
> > >> massage.data is as follow:
> > >>> entry-0 0
> > >>> entry-1 1
> > >>> entry-2 1
> > >>> entry-3 1
> > >>> entry-4 1
> > >>> entry-5 1
> > >>> entry-6 1

It looks like a bug from the driver. It should only use vector 0 and 1
in this case.

Could you please check the queue_msix_vector for each queue in this case?

> > > Urgh... is vp_modern_queue_vector() used in your configuration? This
> > > is ... terrible.
> > I encountered this problem using the 4.19 version kernel, but not the
> > 5.10 version. This vp_modern_queue_vector() function does not exist
> > in 4.19, but it uses 'vp_iowrite16(msix_vec, &cfg->queue_msix_vector)',
> > the same as vp_modern_queue_vector().
> >
> > In the past two days, I learned about the virtio driver and made some
> > new discoveries. When 'num_queues' is greater than maxcpus, it will
> > fall back into MSI-X with one shared for queues. The two patches[1],
> > submitted by Dongli, limits the number of hw queues used by
> > virtio-blk/virtio-scsi by 'nr_cpu_ids'. The two patches were merged
> > in 5.1-rc2. And the patch related virtio-blk was merged into the 4.19
> > stable branch.The patch related virtio-scsi was not merged.
> > [1]
> > https://lore.kernel.org/all/1553682995-5682-1-git-send-email-dongli.zhang at oracle.com/
> >
> > This is the earliest discussion.
> > https://lore.kernel.org/all/e4afe4c5-0262-4500-aeec-60f30734b4fc at default/
> >
> > I don't know if there are other circumstances that would cause it to
> > fall back into MSI-X with one shared for queues. At least the hack
> > method is possible.
> > > I wonder if PCIe actually allows this sort of thing.
> > Do you think the virtio driver should be modified?
>
> I think the virtio driver should stop messing with the MSI-X
> configuration behind the kernel's back. For example, what happens if
> the kernel needs to do a disable_irq() on the "shared" interrupt? It
> will mask the interrupt in *one* of the vectors, and the interrupt
> will still be screaming.
>
> This is terribly broken, even on x86.

Let's try to see the queue_msix_vector. A correct implemented device
should not try to use a vector more than 1.

>
> > > In any case, this sort of behaviour breaks so many thing in KVM's
> > > implementation that I'd recommend you disable GICv4 until we have a
> > > good solution for that.
> > There seems to be no restriction in the GIC specification that multiple
> > host irqs cannot be mapped to the same vlpi. Or maybe I didn't notice.
> > Do you think there are any risks?
>
> Please see 5.2.10 ("Restrictions for INTID mapping rules"), which
> clearly forbids the case we have here: "Maps multiple EventID-DeviceID
> combinations to the same virtual LPI INTID-vPEID.".
>
> > GICv3 does not have this issue, but is this configuration legal?
>
> With GICv3, the ITS doesn't see multiple mappings to the same
> LPI. Each DeviceID/EventID pair has its own LPI, and KVM will just see
> the injection callback from VFIO.
>
> Honestly, the virtio driver is broken (irrespective of the
> architecture), and incompatible with the GIC architecture.

No matter how the driver is written, the host/KVM should be able to
survive from that.

Thanks

>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.
>



From wenst at chromium.org  Mon Dec  4 00:40:02 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:02 +0800
Subject: [PATCH v3 0/9] arm64: dts: mediatek: Add MT8186 Corsola Chromebooks
Message-ID: <20231204084012.2281292-1-wenst@chromium.org>

Hi everyone,

This is v3 of the MT8186 Chromebook device tree series.

Changes since v2:
- Picked up Conor's ack
- Renamed remaining "touchpad" nodes to "trackpad"
- Dropped pinctrl from tentacruel/tentacool second source trackpad

Changes since v1:
- Reorder SKU numbers in descending order.
- Fixed pinconfig node names
- Moved pinctrl-* properties after interrupts-*
- Switched to interrupts-extended for external components
- Marked ADSP as explicitly disabled, with a comment explaining that it
  stalls the system
- Renamed "touchpad" to "trackpad"
- Dropped bogus "no-laneswap" property from it6505 node
- Moved "realtek,jd-src" property to after all the regulator supplies
- Switched to macros for MT6366 regulator "regulator-allowed-modes"
- Renamed "vgpu" regulator name to allow coupling, with a comment
  containing the name used in the design
- Renamed "cr50" node name to "tpm"
- Moved trackpad_pins reference up to i2c2; workaround for second source
  component resource sharing.
- Fix copyright year
- Fixed touchscreen supply name
- Mark missing components as disabled instead of deleting the node
- Dropped reset-gpios from touchscreen nodes
- Drop status = "okay", which is the default


This series adds device trees for the various MT8186 Chromebooks that
were initially released. These are the Tentacruel / Tentacool devices
released by ASUS, and the Steelix / Rusty / Magneton devices released
by Lenovo. The device trees are taken from the downstream ChromeOS v5.15
kernel, ported to mainline and cleaned up.

Corsola is the Google codename given to the MT8186 platform. This
platform has two reference designs, Krabby and Kingler. Kingler was not
used in any actual product, and is therefor not included. Steelix is
an alternative design put forward and is effectively a mix-and-match of
the two reference designs.

Most of the core design is shared between the variants. The differences
are on which external components, such as the display bridges, are used.

Patch 1 cleans up the current list of MediaTek boards. The entries are
reordered by SoC model first, then by board name.

Patch 2 through 5 add DT binding entries for the Tentacruel/Tentacool,
Steelix, Rusty, and Magneton Chromebooks.

Patch 6 through 9 add board device tree files for these devices. Patch 6
also adds the corsola dtsi file for the commonalities between the designs,
as well as a dtsi file for the krabby reference design.

Currently external display support is missing. Audio is not working, as
enabling the audio DSP causes my test systems to hang.

Please have a look and test if possible.


Regards
ChenYu

Chen-Yu Tsai (9):
  dt-bindings: arm: mediatek: Sort entries by SoC then board compatibles
  dt-bindings: arm: mediatek: Add MT8186 Tentacruel / Tentacool
    Chromebooks
  dt-bindings: arm: mediatek: Add MT8186 Steelix Chromebook
  dt-bindings: arm: mediatek: Add MT8186 Rusty Chromebook
  dt-bindings: arm: mediatek: Add MT8186 Magneton Chromebooks
  arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel /
    Tentacool
  arm64: dts: mediatek: Introduce MT8186 Steelix
  arm64: dts: mediatek: Add MT8186 Steelix platform based Rusty
  arm64: dts: mediatek: Add MT8186 Magneton Chromebooks

 .../devicetree/bindings/arm/mediatek.yaml     |  180 +-
 arch/arm64/boot/dts/mediatek/Makefile         |   10 +
 .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
 .../mt8186-corsola-magneton-sku393216.dts     |   39 +
 .../mt8186-corsola-magneton-sku393217.dts     |   39 +
 .../mt8186-corsola-magneton-sku393218.dts     |   26 +
 .../mt8186-corsola-rusty-sku196608.dts        |   26 +
 .../mt8186-corsola-steelix-sku131072.dts      |   18 +
 .../mt8186-corsola-steelix-sku131073.dts      |   18 +
 .../dts/mediatek/mt8186-corsola-steelix.dtsi  |  195 ++
 .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
 .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
 .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
 .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
 .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
 15 files changed, 2489 insertions(+), 61 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi

-- 
2.43.0.rc2.451.g8631bc7472-goog



From wenst at chromium.org  Mon Dec  4 00:40:03 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:03 +0800
Subject: [PATCH v3 1/9] dt-bindings: arm: mediatek: Sort entries by SoC then board compatibles
In-Reply-To: <20231204084012.2281292-1-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
Message-ID: <20231204084012.2281292-2-wenst@chromium.org>

Some of the new MediaTek board entries were inserted in a chronological
order, or just randomly. This makes it harder to search for an entry.

Sort the entries by first grouping by SoC, then sorting by board
compatible strings. Also add a comment at the top asking people to do
the same.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>

---
Changes since v2:
- none
Changes since v1:
- none

 .../devicetree/bindings/arm/mediatek.yaml     | 123 +++++++++---------
 1 file changed, 62 insertions(+), 61 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index a5999b3afc35..60337b439744 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -17,6 +17,7 @@ properties:
     const: '/'
   compatible:
     oneOf:
+      # Sort by SoC (last) compatible, then board compatible
       - items:
           - enum:
               - mediatek,mt2701-evb
@@ -129,71 +130,10 @@ properties:
           - enum:
               - mediatek,mt8173-evb
           - const: mediatek,mt8173
-      - items:
-          - enum:
-              - mediatek,mt8183-evb
-          - const: mediatek,mt8183
-      - description: Google Hayato rev5
-        items:
-          - const: google,hayato-rev5-sku2
-          - const: google,hayato-sku2
-          - const: google,hayato
-          - const: mediatek,mt8192
-      - description: Google Hayato
-        items:
-          - const: google,hayato-rev1
-          - const: google,hayato
-          - const: mediatek,mt8192
-      - description: Google Spherion rev4 (Acer Chromebook 514)
-        items:
-          - const: google,spherion-rev4
-          - const: google,spherion
-          - const: mediatek,mt8192
-      - description: Google Spherion (Acer Chromebook 514)
-        items:
-          - const: google,spherion-rev3
-          - const: google,spherion-rev2
-          - const: google,spherion-rev1
-          - const: google,spherion-rev0
-          - const: google,spherion
-          - const: mediatek,mt8192
-      - description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H)
-        items:
-          - enum:
-              - google,tomato-rev2
-              - google,tomato-rev1
-          - const: google,tomato
-          - const: mediatek,mt8195
-      - description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H)
-        items:
-          - const: google,tomato-rev4
-          - const: google,tomato-rev3
-          - const: google,tomato
-          - const: mediatek,mt8195
-      - items:
-          - enum:
-              - mediatek,mt8186-evb
-          - const: mediatek,mt8186
-      - items:
-          - enum:
-              - mediatek,mt8192-evb
-          - const: mediatek,mt8192
-      - items:
-          - enum:
-              - mediatek,mt8195-demo
-              - mediatek,mt8195-evb
-          - const: mediatek,mt8195
       - description: Google Burnet (HP Chromebook x360 11MK G3 EE)
         items:
           - const: google,burnet
           - const: mediatek,mt8183
-      - description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
-        items:
-          - enum:
-              - google,krane-sku0
-              - google,krane-sku176
-          - const: google,krane
-          - const: mediatek,mt8183
       - description: Google Cozmo (Acer Chromebook 314)
         items:
           - const: google,cozmo
@@ -244,6 +184,13 @@ properties:
               - google,kodama-sku32
           - const: google,kodama
           - const: mediatek,mt8183
+      - description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
+        items:
+          - enum:
+              - google,krane-sku0
+              - google,krane-sku176
+          - const: google,krane
+          - const: mediatek,mt8183
       - description: Google Willow (Acer Chromebook 311 C722/C722T)
         items:
           - enum:
@@ -251,10 +198,64 @@ properties:
               - google,willow-sku1
           - const: google,willow
           - const: mediatek,mt8183
+      - items:
+          - enum:
+              - mediatek,mt8183-evb
+          - const: mediatek,mt8183
       - items:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - items:
+          - enum:
+              - mediatek,mt8186-evb
+          - const: mediatek,mt8186
+      - description: Google Hayato
+        items:
+          - const: google,hayato-rev1
+          - const: google,hayato
+          - const: mediatek,mt8192
+      - description: Google Hayato rev5
+        items:
+          - const: google,hayato-rev5-sku2
+          - const: google,hayato-sku2
+          - const: google,hayato
+          - const: mediatek,mt8192
+      - description: Google Spherion (Acer Chromebook 514)
+        items:
+          - const: google,spherion-rev3
+          - const: google,spherion-rev2
+          - const: google,spherion-rev1
+          - const: google,spherion-rev0
+          - const: google,spherion
+          - const: mediatek,mt8192
+      - description: Google Spherion rev4 (Acer Chromebook 514)
+        items:
+          - const: google,spherion-rev4
+          - const: google,spherion
+          - const: mediatek,mt8192
+      - items:
+          - enum:
+              - mediatek,mt8192-evb
+          - const: mediatek,mt8192
+      - description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H)
+        items:
+          - enum:
+              - google,tomato-rev2
+              - google,tomato-rev1
+          - const: google,tomato
+          - const: mediatek,mt8195
+      - description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H)
+        items:
+          - const: google,tomato-rev4
+          - const: google,tomato-rev3
+          - const: google,tomato
+          - const: mediatek,mt8195
+      - items:
+          - enum:
+              - mediatek,mt8195-demo
+              - mediatek,mt8195-evb
+          - const: mediatek,mt8195
       - items:
           - enum:
               - mediatek,mt8365-evk
-- 
2.43.0.rc2.451.g8631bc7472-goog



From wenst at chromium.org  Mon Dec  4 00:40:04 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:04 +0800
Subject: [PATCH v3 2/9] dt-bindings: arm: mediatek: Add MT8186 Tentacruel / Tentacool Chromebooks
In-Reply-To: <20231204084012.2281292-1-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
Message-ID: <20231204084012.2281292-3-wenst@chromium.org>

Add entries for MT8186 based Tentacruel / Tentacool Chromebooks. The two
are based on the same board design: the former is a convertible device
with a touchscreen, stylus, and some extra buttons; the latter is a
clamshell device and lacks these additional features.

The two devices both have two variants. The difference is a second
source touchpad controller that shares the same address as the original,
but is incompatible.

The extra SKU IDs for the Tentacruel devices map to different sensor
components attached to the Embedded Controller. These are not visible
to the main processor.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.

 .../devicetree/bindings/arm/mediatek.yaml     | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 60337b439744..709a1292bca7 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -206,6 +206,32 @@ properties:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
+        items:
+          - const: google,tentacruel-sku262147
+          - const: google,tentacruel-sku262146
+          - const: google,tentacruel-sku262145
+          - const: google,tentacruel-sku262144
+          - const: google,tentacruel
+          - const: mediatek,mt8186
+      - description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
+        items:
+          - const: google,tentacruel-sku262151
+          - const: google,tentacruel-sku262150
+          - const: google,tentacruel-sku262149
+          - const: google,tentacruel-sku262148
+          - const: google,tentacruel
+          - const: mediatek,mt8186
+      - description: Google Tentacool (ASUS Chromebook CM14 CM1402C)
+        items:
+          - const: google,tentacruel-sku327681
+          - const: google,tentacruel
+          - const: mediatek,mt8186
+      - description: Google Tentacool (ASUS Chromebook CM14 CM1402C)
+        items:
+          - const: google,tentacruel-sku327683
+          - const: google,tentacruel
+          - const: mediatek,mt8186
       - items:
           - enum:
               - mediatek,mt8186-evb
-- 
2.43.0.rc2.451.g8631bc7472-goog



From wenst at chromium.org  Mon Dec  4 00:40:05 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:05 +0800
Subject: [PATCH v3 3/9] dt-bindings: arm: mediatek: Add MT8186 Steelix Chromebook
In-Reply-To: <20231204084012.2281292-1-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
Message-ID: <20231204084012.2281292-4-wenst@chromium.org>

Add an entry for the MT8186 based Steelix Chromebook, also known as the
Lenovo 300e Yoga Chromebook Gen 4.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Picked up Conor's ack
Changes since v1:
none

 Documentation/devicetree/bindings/arm/mediatek.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 709a1292bca7..95d2b430ab17 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -206,6 +206,13 @@ properties:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - description: Google Steelix (Lenovo 300e Yoga Chromebook Gen 4)
+        items:
+          - enum:
+              - google,steelix-sku131072
+              - google,steelix-sku131073
+          - const: google,steelix
+          - const: mediatek,mt8186
       - description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
         items:
           - const: google,tentacruel-sku262147
-- 
2.43.0.rc2.451.g8631bc7472-goog



From wenst at chromium.org  Mon Dec  4 00:40:06 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:06 +0800
Subject: [PATCH v3 4/9] dt-bindings: arm: mediatek: Add MT8186 Rusty Chromebook
In-Reply-To: <20231204084012.2281292-1-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
Message-ID: <20231204084012.2281292-5-wenst@chromium.org>

Add an entry for the MT8186 based Rusty Chromebook, also known as the
Lenovo 100e Chromebook Gen 4.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.

 Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 95d2b430ab17..85d394e390f0 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -206,6 +206,12 @@ properties:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - description: Google Rusty (Lenovo 100e Chromebook Gen 4)
+        items:
+          - const: google,steelix-sku196609
+          - const: google,steelix-sku196608
+          - const: google,steelix
+          - const: mediatek,mt8186
       - description: Google Steelix (Lenovo 300e Yoga Chromebook Gen 4)
         items:
           - enum:
-- 
2.43.0.rc2.451.g8631bc7472-goog



From wenst at chromium.org  Mon Dec  4 00:40:07 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:07 +0800
Subject: [PATCH v3 5/9] dt-bindings: arm: mediatek: Add MT8186 Magneton Chromebooks
In-Reply-To: <20231204084012.2281292-1-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
Message-ID: <20231204084012.2281292-6-wenst@chromium.org>

Add entries for the MT8186 based Chromebooks, also collectively known
as the Lenovo IdeaPad Slim 3 Chromebook (14M868). It is also based on
the "Steelix" design. Being a laptop instead of a convertible device,
there is no touchscreen or stylus, which is similar to Rusty. However
Magneton does not have ports on the right side of the device.

Three variants are listed separately. These use different touchscreen
controllers, or lack a touchscreen altogether.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.

 .../devicetree/bindings/arm/mediatek.yaml      | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 85d394e390f0..155ba22e2ad3 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -206,6 +206,24 @@ properties:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
+        items:
+          - const: google,steelix-sku393219
+          - const: google,steelix-sku393216
+          - const: google,steelix
+          - const: mediatek,mt8186
+      - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
+        items:
+          - const: google,steelix-sku393220
+          - const: google,steelix-sku393217
+          - const: google,steelix
+          - const: mediatek,mt8186
+      - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
+        items:
+          - const: google,steelix-sku393221
+          - const: google,steelix-sku393218
+          - const: google,steelix
+          - const: mediatek,mt8186
       - description: Google Rusty (Lenovo 100e Chromebook Gen 4)
         items:
           - const: google,steelix-sku196609
-- 
2.43.0.rc2.451.g8631bc7472-goog



From wenst at chromium.org  Mon Dec  4 00:40:09 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:09 +0800
Subject: [PATCH v3 7/9] arm64: dts: mediatek: Introduce MT8186 Steelix
In-Reply-To: <20231204084012.2281292-1-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
Message-ID: <20231204084012.2281292-8-wenst@chromium.org>

The MT8186 Steelix, also known as the Lenovo 300e Yoga Chromebook Gen 4,
is a convertible device based on a common design of the same name. The
device comes in different variants. Of them, whether a world facing
camera is integrated is the only differentiating factor between the
two device trees added. The different SKU IDs describe this alone.

The other device difference is the touchpad component used. This is
simply handled by having both possible components described in the
device tree, and letting the implementation figure out which one is
actually available. The system bootloader / firmware does not
differentiate this in that they share the same SKU IDs.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Removed trackpad_pins reference (moved to i2c2 in corsola dtsi)
- Fixed copyright year
- Renamed touchpad to trackpad

 arch/arm64/boot/dts/mediatek/Makefile         |   2 +
 .../mt8186-corsola-steelix-sku131072.dts      |  18 ++
 .../mt8186-corsola-steelix-sku131073.dts      |  18 ++
 .../dts/mediatek/mt8186-corsola-steelix.dtsi  | 195 ++++++++++++++++++
 4 files changed, 233 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 442af61b1305..7bd9471b89f9 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -43,6 +43,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131072.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131073.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
new file mode 100644
index 000000000000..eae17bca8585
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Steelix board";
+	compatible = "google,steelix-sku131072", "google,steelix",
+		     "mediatek,mt8186";
+	chassis-type = "convertible";
+};
+
+&mt6366codec {
+	mediatek,dmic-mode = <0>; /* two-wire */
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
new file mode 100644
index 000000000000..a55375b95d0d
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Steelix board";
+	compatible = "google,steelix-sku131073", "google,steelix",
+		     "mediatek,mt8186";
+	chassis-type = "convertible";
+};
+
+&mt6366codec {
+	mediatek,dmic-mode = <1>; /* one-wire */
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
new file mode 100644
index 000000000000..47262bc499ad
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/{
+	pp1000_edpbrdg: regulator-pp1000-edpbrdg {
+		compatible = "regulator-fixed";
+		regulator-name = "pp1000_edpbrdg";
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp1000_edpbrdg>;
+		enable-active-high;
+		regulator-boot-on;
+		gpio = <&pio 29 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&pp3300_z2>;
+	};
+
+	pp1800_edpbrdg_dx: regulator-pp1800-edpbrdg-dx {
+		compatible = "regulator-fixed";
+		regulator-name = "pp1800_edpbrdg_dx";
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp1800_edpbrdg>;
+		enable-active-high;
+		regulator-boot-on;
+		gpio = <&pio 30 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&mt6366_vio18_reg>;
+	};
+
+	pp3300_edp_dx: regulator-pp3300-edp-dx {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_edp_dx";
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp3300_edpbrdg>;
+		enable-active-high;
+		regulator-boot-on;
+		gpio = <&pio 31 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&pp3300_z2>;
+	};
+};
+
+&dsi_out {
+	remote-endpoint = <&anx7625_in>;
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+
+	anx_bridge: anx7625 at 58 {
+		compatible = "analogix,anx7625";
+		reg = <0x58>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&anx7625_pins>;
+		enable-gpios = <&pio 96 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>;
+		vdd10-supply = <&pp1000_edpbrdg>;
+		vdd18-supply = <&pp1800_edpbrdg_dx>;
+		vdd33-supply = <&pp3300_edp_dx>;
+		analogix,lane0-swing = /bits/ 8 <0x70 0x30>;
+		analogix,lane1-swing = /bits/ 8 <0x70 0x30>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				anx7625_in: endpoint {
+					remote-endpoint = <&dsi_out>;
+					data-lanes = <0 1 2 3>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+
+				anx7625_out: endpoint {
+					remote-endpoint = <&panel_in>;
+				};
+			};
+		};
+
+		aux-bus {
+			panel: panel {
+				compatible = "edp-panel";
+				power-supply = <&pp3300_disp_x>;
+				backlight = <&backlight_lcd0>;
+
+				port {
+					panel_in: endpoint {
+						remote-endpoint = <&anx7625_out>;
+					};
+				};
+			};
+		};
+	};
+};
+
+&i2c1 {
+	touchscreen: touchscreen at 5d {
+		compatible = "goodix,gt7375p";
+		reg = <0x5d>;
+		interrupts-extended = <&pio 12 IRQ_TYPE_EDGE_FALLING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>;
+		vdd-supply = <&pp3300_s3>;
+		goodix,no-reset-during-suspend;
+	};
+};
+
+&i2c2 {
+	i2c-scl-internal-delay-ns = <22000>;
+
+	/* second source component */
+	trackpad at 2c {
+		compatible = "hid-over-i2c";
+		reg = <0x2c>;
+		hid-descr-addr = <0x20>;
+		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
+		vdd-supply = <&pp3300_s3>;
+		wakeup-source;
+	};
+};
+
+&keyboard_controller {
+	function-row-physmap = <
+		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
+		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
+		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
+		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
+		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
+		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
+		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
+		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
+		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
+		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
+	>;
+
+	linux,keymap = <
+		MATRIX_KEY(0x00, 0x02, KEY_BACK)
+		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
+		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
+		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
+		MATRIX_KEY(0x03, 0x04, KEY_BRIGHTNESSDOWN)
+		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSUP)
+		MATRIX_KEY(0x01, 0x04, KEY_MICMUTE)
+		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
+		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
+		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
+		CROS_STD_MAIN_KEYMAP
+	>;
+};
+
+&pio {
+	anx7625_pins: anx7625-pins {
+		pins1 {
+			pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
+				 <PINMUX_GPIO98__FUNC_GPIO98>;
+			output-low;
+		};
+
+		pins2 {
+			pinmux = <PINMUX_GPIO9__FUNC_GPIO9>;
+			input-enable;
+			bias-disable;
+		};
+	};
+
+	en_pp1000_edpbrdg: pp1000-edpbrdg-en-pins {
+		pins {
+			pinmux = <PINMUX_GPIO29__FUNC_GPIO29>;
+			output-low;
+		};
+	};
+
+	en_pp1800_edpbrdg: pp1800-edpbrdg-en-pins {
+		pins {
+			pinmux = <PINMUX_GPIO30__FUNC_GPIO30>;
+			output-low;
+		};
+	};
+
+	en_pp3300_edpbrdg: pp3300-edpbrdg-en-pins {
+		pins {
+			pinmux = <PINMUX_GPIO31__FUNC_GPIO31>;
+			output-low;
+		};
+	};
+};
-- 
2.43.0.rc2.451.g8631bc7472-goog



From wenst at chromium.org  Mon Dec  4 00:40:11 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:11 +0800
Subject: [PATCH v3 9/9] arm64: dts: mediatek: Add MT8186 Magneton Chromebooks
In-Reply-To: <20231204084012.2281292-1-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
Message-ID: <20231204084012.2281292-10-wenst@chromium.org>

Add entries for the MT8186 based Chromebooks, also collectively known
as the Lenovo IdeaPad Slim 3 Chromebook (14M868). It is also based on
the "Steelix" design. Being a laptop instead of a convertible device,
there is no stylus, which is similar to Rusty. However Magneton does
not have ports on the right side of the device.

Three variants are listed separately. These use different touchscreen
controllers, or lack a touchscreen altogether.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.
- Mark missing components as disabled instead of deleting the node
- Switched to interrupts-extended in touchscreen nodes
- Dropped reset-gpios from touchscreen nodes
- Drop status = "okay", which is the default

 arch/arm64/boot/dts/mediatek/Makefile         |  3 ++
 .../mt8186-corsola-magneton-sku393216.dts     | 39 +++++++++++++++++++
 .../mt8186-corsola-magneton-sku393217.dts     | 39 +++++++++++++++++++
 .../mt8186-corsola-magneton-sku393218.dts     | 26 +++++++++++++
 4 files changed, 107 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 6b05f1f2e645..7e365e9516ab 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -43,6 +43,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-magneton-sku393216.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-magneton-sku393217.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-magneton-sku393218.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-rusty-sku196608.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131072.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131073.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts
new file mode 100644
index 000000000000..c9673381ad3b
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Magneton board";
+	compatible = "google,steelix-sku393219", "google,steelix-sku393216",
+		     "google,steelix", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+&gpio_keys {
+	status = "disabled";
+};
+
+&i2c1 {
+	touchscreen at 10 {
+		compatible = "hid-over-i2c";
+		reg = <0x10>;
+		interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		vdd-supply = <&pp3300_s3>;
+		post-power-on-delay-ms = <350>;
+		hid-descr-addr = <0x0001>;
+	};
+};
+
+&touchscreen {
+	status = "disabled";
+};
+
+&usb_c1 {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts
new file mode 100644
index 000000000000..28e3bbe56421
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Magneton board";
+	compatible = "google,steelix-sku393220", "google,steelix-sku393217",
+		     "google,steelix", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+&gpio_keys {
+	status = "disabled";
+};
+
+&i2c1 {
+	touchscreen at 40 {
+		compatible = "hid-over-i2c";
+		reg = <0x40>;
+		interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		vdd-supply = <&pp3300_s3>;
+		post-power-on-delay-ms = <450>;
+		hid-descr-addr = <0x0001>;
+	};
+};
+
+&touchscreen {
+	status = "disabled";
+};
+
+&usb_c1 {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts
new file mode 100644
index 000000000000..332894218f07
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Magneton board";
+	compatible = "google,steelix-sku393221", "google,steelix-sku393218",
+		     "google,steelix", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+&gpio_keys {
+	status = "disabled";
+};
+
+&touchscreen {
+	status = "disabled";
+};
+
+&usb_c1 {
+	status = "disabled";
+};
-- 
2.43.0.rc2.451.g8631bc7472-goog



From wenst at chromium.org  Mon Dec  4 00:40:10 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:10 +0800
Subject: [PATCH v3 8/9] arm64: dts: mediatek: Add MT8186 Steelix platform based Rusty
In-Reply-To: <20231204084012.2281292-1-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
Message-ID: <20231204084012.2281292-9-wenst@chromium.org>

MT8186 Rusty, otherwise known as the Lenovo 100e Chromebook Gen 4, is an
MT8186 based laptop. It is based on the "Steelix" design. Being a laptop
instead of a convertible device, there is no touchscreen or stylus.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.
- Mark missing components as disabled instead of deleting the node

 arch/arm64/boot/dts/mediatek/Makefile         |  1 +
 .../mt8186-corsola-rusty-sku196608.dts        | 26 +++++++++++++++++++
 2 files changed, 27 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 7bd9471b89f9..6b05f1f2e645 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -43,6 +43,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-rusty-sku196608.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131072.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131073.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts
new file mode 100644
index 000000000000..731b0d60228d
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Rusty board";
+	compatible = "google,steelix-sku196609", "google,steelix-sku196608",
+		     "google,steelix", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+&gpio_keys {
+	status = "disabled";
+};
+
+&i2c1 {
+	status = "disabled";
+};
+
+&touchscreen {
+	status = "disabled";
+};
-- 
2.43.0.rc2.451.g8631bc7472-goog



From wenst at chromium.org  Mon Dec  4 00:40:08 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon,  4 Dec 2023 16:40:08 +0800
Subject: [PATCH v3 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel / Tentacool
In-Reply-To: <20231204084012.2281292-1-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
Message-ID: <20231204084012.2281292-7-wenst@chromium.org>

Tentacruel and Tentacool are MT8186 based Chromebooks based on the
Krabby design.

Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
convertible device with touchscreen and stylus.

Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
device. It does not have a touchscreen or stylus.

The two devices both have two variants. The difference is a second
source touchpad controller that shares the same address as the original,
but is incompatible.

The extra SKU IDs for the Tentacruel devices map to different sensor
components attached to the Embedded Controller. These are not visible
to the main processor.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Picked up Conor's ack
- Rename touchpad to trackpad
- Drop pinctrl properties from trackpad in tentacruel/tentacool second
  source trackpad

Changes since v1:
- Reorder SKU numbers in descending order.
- Fixed pinconfig node names
- Moved pinctrl-* properties after interrupts-*
- Switched to interrupts-extended for external components
- Marked ADSP as explicitly disabled, with a comment explaining that it
  stalls the system
- Renamed "touchpad" to "trackpad"
- Dropped bogus "no-laneswap" property from it6505 node
- Moved "realtek,jd-src" property to after all the regulator supplies
- Switched to macros for MT6366 regulator "regulator-allowed-modes"
- Renamed "vgpu" regulator name to allow coupling, with a comment
  containing the name used in the design
- Renamed "cr50" node name to "tpm"
- Moved trackpad_pins reference up to i2c2; workaround for second source
  component resource sharing.
- Fix copyright year
- Fixed touchscreen supply name

 arch/arm64/boot/dts/mediatek/Makefile         |    4 +
 .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
 .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
 .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
 .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
 .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
 .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
 7 files changed, 2003 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index e6e7592a3645..442af61b1305 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
new file mode 100644
index 000000000000..9b2b64525961
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	aliases {
+		i2c4 = &i2c4;
+	};
+};
+
+&dsi_out {
+	remote-endpoint = <&ps8640_in>;
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+
+	ps8640: edp-bridge at 8 {
+		compatible = "parade,ps8640";
+		reg = <0x8>;
+		powerdown-gpios = <&pio 96 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&pio 98 GPIO_ACTIVE_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ps8640_pins>;
+		vdd12-supply = <&mt6366_vrf12_reg>;
+		vdd33-supply = <&mt6366_vcn33_reg>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				ps8640_in: endpoint {
+					remote-endpoint = <&dsi_out>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+
+				ps8640_out: endpoint {
+					remote-endpoint = <&panel_in>;
+				};
+			};
+		};
+
+		aux-bus {
+			panel {
+				compatible = "edp-panel";
+				power-supply = <&pp3300_disp_x>;
+				backlight = <&backlight_lcd0>;
+
+				port {
+					panel_in: endpoint {
+						remote-endpoint = <&ps8640_out>;
+					};
+				};
+			};
+		};
+	};
+};
+
+&i2c1 {
+	i2c-scl-internal-delay-ns = <10000>;
+
+	touchscreen: touchscreen at 10 {
+		compatible = "hid-over-i2c";
+		reg = <0x10>;
+		interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		post-power-on-delay-ms = <10>;
+		hid-descr-addr = <0x0001>;
+		vdd-supply = <&pp3300_s3>;
+	};
+};
+
+&i2c4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c4_pins>;
+	clock-frequency = <400000>;
+	status = "okay";
+
+	proximity at 28 {
+		compatible = "semtech,sx9324";
+		reg = <0x28>;
+		interrupts-extended = <&pio 5 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sar_sensor_pins>;
+		vdd-supply = <&mt6366_vio18_reg>;
+		svdd-supply = <&mt6366_vio18_reg>;
+		#io-channel-cells = <1>;
+	};
+};
+
+&pio {
+	i2c4_pins: i2c4-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO136__FUNC_SDA4>,
+				 <PINMUX_GPIO135__FUNC_SCL4>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	ps8640_pins: ps8640-pins {
+		pins-pwrdn-rst {
+			pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
+				 <PINMUX_GPIO98__FUNC_GPIO98>;
+			output-low;
+		};
+	};
+
+	sar_sensor_pins: sar-sensor-pins {
+		pins-irq {
+			pinmux = <PINMUX_GPIO5__FUNC_GPIO5>;
+			input-enable;
+			bias-pull-up;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
new file mode 100644
index 000000000000..9bb64353ca65
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-krabby.dtsi"
+
+/ {
+	model = "Google Tentacool board";
+	compatible = "google,tentacruel-sku327681", "google,tentacruel", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+/* Tentacool omits the pen. */
+&gpio_keys {
+	status = "disabled";
+};
+
+/* Tentacool omits the touchscreen; nothing else is on i2c1. */
+&i2c1 {
+	status = "disabled";
+};
+
+&keyboard_controller {
+	function-row-physmap = <
+		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
+		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
+		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
+		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
+		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
+		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
+		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
+		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
+		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
+		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
+	>;
+
+	linux,keymap = <
+		MATRIX_KEY(0x00, 0x02, KEY_BACK)
+		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
+		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
+		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
+		MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
+		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
+		MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
+		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
+		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
+		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
+		CROS_STD_MAIN_KEYMAP
+	>;
+};
+
+/* Tentacool omits the touchscreen. */
+&touchscreen {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
new file mode 100644
index 000000000000..c3ae6f9616c8
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2023 Google LLC
+ */
+
+#include "mt8186-corsola-tentacool-sku327681.dts"
+
+/ {
+	compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
+};
+
+/* This variant replaces only the trackpad controller. */
+&i2c2 {
+	/delete-node/ trackpad at 15;
+
+	trackpad at 15 {
+		compatible = "hid-over-i2c";
+		reg = <0x15>;
+		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
+		hid-descr-addr = <0x0001>;
+		vdd-supply = <&pp3300_s3>;
+		wakeup-source;
+	};
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
new file mode 100644
index 000000000000..26d3451a5e47
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-krabby.dtsi"
+
+/ {
+	model = "Google Tentacruel board";
+	compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
+		     "google,tentacruel-sku262145", "google,tentacruel-sku262144",
+		     "google,tentacruel", "mediatek,mt8186";
+	chassis-type = "convertible";
+};
+
+&keyboard_controller {
+	function-row-physmap = <
+		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
+		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
+		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
+		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
+		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
+		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
+		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
+		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
+		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
+		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
+	>;
+
+	linux,keymap = <
+		MATRIX_KEY(0x00, 0x02, KEY_BACK)
+		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
+		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
+		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
+		MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
+		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
+		MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
+		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
+		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
+		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
+		CROS_STD_MAIN_KEYMAP
+	>;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
new file mode 100644
index 000000000000..447b57b12b41
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2023 Google LLC
+ */
+
+#include "mt8186-corsola-tentacruel-sku262144.dts"
+
+/ {
+	compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
+		     "google,tentacruel-sku262149", "google,tentacruel-sku262148",
+		     "google,tentacruel", "mediatek,mt8186";
+};
+
+/* This variant replaces only the trackpad controller. */
+&i2c2 {
+	/delete-node/ trackpad at 15;
+
+	trackpad at 15 {
+		compatible = "hid-over-i2c";
+		reg = <0x15>;
+		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
+		hid-descr-addr = <0x0001>;
+		vdd-supply = <&pp3300_s3>;
+		wakeup-source;
+	};
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
new file mode 100644
index 000000000000..8726b2916ef1
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
@@ -0,0 +1,1719 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2022 MediaTek Inc.
+ */
+/dts-v1/;
+#include "mt8186.dtsi"
+#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
+
+/ {
+	aliases {
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c5 = &i2c5;
+		mmc0 = &mmc0;
+		mmc1 = &mmc1;
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory at 40000000 {
+		device_type = "memory";
+		/* The size should be filled in by the bootloader. */
+		reg = <0 0x40000000 0 0>;
+	};
+
+	backlight_lcd0: backlight-lcd0 {
+		compatible = "pwm-backlight";
+		pwms = <&pwm0 0 500000>;
+		power-supply = <&ppvar_sys>;
+		enable-gpios = <&pio 152 0>;
+		brightness-levels = <0 1023>;
+		num-interpolated-steps = <1023>;
+		default-brightness-level = <576>;
+	};
+
+	btsco: bt-sco {
+		compatible = "linux,bt-sco";
+		#sound-dai-cells = <0>;
+	};
+
+	dmic_codec: dmic-codec {
+		compatible = "dmic-codec";
+		num-channels = <2>;
+		wakeup-delay-ms = <50>;
+		#sound-dai-cells = <0>;
+	};
+
+	gpio_keys: gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pen_eject>;
+
+		pen_insert: pen-insert-switch {
+			label = "Pen Insert";
+			/* Insert = low, eject = high */
+			gpios = <&pio 18 GPIO_ACTIVE_LOW>;
+			linux,code = <SW_PEN_INSERTED>;
+			linux,input-type = <EV_SW>;
+			wakeup-event-action = <EV_ACT_DEASSERTED>;
+			wakeup-source;
+		};
+	};
+
+	pp1800_dpbrdg_dx: regulator-pp1800-dpbrdg-dx {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp1800_dpbrdg>;
+		regulator-name = "pp1800_dpbrdg_dx";
+		enable-active-high;
+		gpio = <&pio 39 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&mt6366_vio18_reg>;
+	};
+
+	pp3300_disp_x: regulator-pp3300-disp-x {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_disp_x";
+		pinctrl-names = "default";
+		pinctrl-0 = <&edp_panel_fixed_pins>;
+		enable-active-high;
+		regulator-boot-on;
+		gpio = <&pio 153 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&pp3300_z2>;
+	};
+
+	/* system wide LDO 3.3V power rail */
+	pp3300_z5: regulator-pp3300-ldo-z5 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_ldo_z5";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* separately switched 3.3V power rail */
+	pp3300_s3: regulator-pp3300-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_s3";
+		/* automatically sequenced by PMIC EXT_PMIC_EN2 */
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&pp3300_z2>;
+	};
+
+	/* system wide 3.3V power rail */
+	pp3300_z2: regulator-pp3300-z2 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_z2";
+		/* EN pin tied to pp4200_z2, which is controlled by EC */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* system wide 4.2V power rail */
+	pp4200_z2: regulator-pp4200-z2 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp4200_z2";
+		/* controlled by EC */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <4200000>;
+		regulator-max-microvolt = <4200000>;
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* system wide switching 5.0V power rail */
+	pp5000_z2: regulator-pp5000-z2 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp5000_z2";
+		/* controlled by EC */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* system wide semi-regulated power rail from battery or USB */
+	ppvar_sys: regulator-ppvar-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "ppvar_sys";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		adsp_dma_mem: memory at 61000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x61000000 0 0x100000>;
+			no-map;
+		};
+
+		adsp_mem: memory at 60000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x60000000 0 0xA00000>;
+			no-map;
+		};
+
+		scp_mem: memory at 50000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x50000000 0 0x10a0000>;
+			no-map;
+		};
+	};
+
+	sound: sound {
+		compatible = "mediatek,mt8186-mt6366-rt1019-rt5682s-sound";
+		pinctrl-names = "aud_clk_mosi_off",
+				"aud_clk_mosi_on",
+				"aud_clk_miso_off",
+				"aud_clk_miso_on",
+				"aud_dat_miso_off",
+				"aud_dat_miso_on",
+				"aud_dat_mosi_off",
+				"aud_dat_mosi_on",
+				"aud_gpio_i2s0_off",
+				"aud_gpio_i2s0_on",
+				"aud_gpio_i2s1_off",
+				"aud_gpio_i2s1_on",
+				"aud_gpio_i2s2_off",
+				"aud_gpio_i2s2_on",
+				"aud_gpio_i2s3_off",
+				"aud_gpio_i2s3_on",
+				"aud_gpio_tdm_off",
+				"aud_gpio_tdm_on",
+				"aud_gpio_pcm_off",
+				"aud_gpio_pcm_on",
+				"aud_gpio_dmic_sec";
+		pinctrl-0 = <&aud_clk_mosi_off>;
+		pinctrl-1 = <&aud_clk_mosi_on>;
+		pinctrl-2 = <&aud_clk_miso_off>;
+		pinctrl-3 = <&aud_clk_miso_on>;
+		pinctrl-4 = <&aud_dat_miso_off>;
+		pinctrl-5 = <&aud_dat_miso_on>;
+		pinctrl-6 = <&aud_dat_mosi_off>;
+		pinctrl-7 = <&aud_dat_mosi_on>;
+		pinctrl-8 = <&aud_gpio_i2s0_off>;
+		pinctrl-9 = <&aud_gpio_i2s0_on>;
+		pinctrl-10 = <&aud_gpio_i2s1_off>;
+		pinctrl-11 = <&aud_gpio_i2s1_on>;
+		pinctrl-12 = <&aud_gpio_i2s2_off>;
+		pinctrl-13 = <&aud_gpio_i2s2_on>;
+		pinctrl-14 = <&aud_gpio_i2s3_off>;
+		pinctrl-15 = <&aud_gpio_i2s3_on>;
+		pinctrl-16 = <&aud_gpio_tdm_off>;
+		pinctrl-17 = <&aud_gpio_tdm_on>;
+		pinctrl-18 = <&aud_gpio_pcm_off>;
+		pinctrl-19 = <&aud_gpio_pcm_on>;
+		pinctrl-20 = <&aud_gpio_dmic_sec>;
+		mediatek,adsp = <&adsp>;
+		mediatek,platform = <&afe>;
+
+		playback-codecs {
+			sound-dai = <&it6505dptx>, <&rt1019p>;
+		};
+
+		headset-codec {
+			sound-dai = <&rt5682s 0>;
+		};
+	};
+
+	rt1019p: speaker-codec {
+		compatible = "realtek,rt1019p";
+		pinctrl-names = "default";
+		pinctrl-0 = <&rt1019p_pins_default>;
+		sdb-gpios = <&pio 150 GPIO_ACTIVE_HIGH>;
+		#sound-dai-cells = <0>;
+	};
+
+	usb_p1_vbus: regulator-usb-p1-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "vbus1";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&pio 148 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&pp5000_z2>;
+	};
+
+	wifi_pwrseq: wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_pin>;
+		post-power-on-delay-ms = <50>;
+		reset-gpios = <&pio 54 GPIO_ACTIVE_LOW>;
+	};
+
+	wifi_wakeup: wifi-wakeup {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_wakeup_pin>;
+
+		wowlan-event {
+			label = "Wake on WiFi";
+			gpios = <&pio 7 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_WAKEUP>;
+			wakeup-source;
+		};
+	};
+};
+
+&adsp {
+	memory-region = <&adsp_dma_mem>, <&adsp_mem>;
+	status = "disabled"; /* causes stall */
+};
+
+&afe {
+	i2s0-share = "I2S1";
+	i2s3-share = "I2S2";
+	status = "okay";
+};
+
+&cci {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu0 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu1 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu2 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu3 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu4 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu5 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu6 {
+	proc-supply = <&mt6366_vproc11_reg>;
+};
+
+&cpu7 {
+	proc-supply = <&mt6366_vproc11_reg>;
+};
+
+&dpi {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&dpi_pins_default>;
+	pinctrl-1 = <&dpi_pins_sleep>;
+	status = "okay";
+};
+
+&dpi_out {
+	remote-endpoint = <&it6505_in>;
+};
+
+&dsi0 {
+	status = "okay";
+};
+
+&gic {
+	mediatek,broken-save-restore-fw;
+};
+
+&gpu {
+	mali-supply = <&mt6366_vgpu_reg>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+	clock-frequency = <400000>;
+	i2c-scl-internal-delay-ns = <8000>;
+	status = "okay";
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	/*
+	 * Trackpad pin put here to work around second source components
+	 * sharing the pinmux in steelix designs.
+	 */
+	pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
+	clock-frequency = <400000>;
+	i2c-scl-internal-delay-ns = <10000>;
+	status = "okay";
+
+	trackpad at 15 {
+		compatible = "elan,ekth3000";
+		reg = <0x15>;
+		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
+		vcc-supply = <&pp3300_s3>;
+		wakeup-source;
+	};
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c3_pins>;
+	clock-frequency = <100000>;
+	status = "okay";
+
+	it6505dptx: dp-bridge at 5c {
+		compatible = "ite,it6505";
+		reg = <0x5c>;
+		interrupts-extended = <&pio 8 IRQ_TYPE_LEVEL_LOW>;
+		ovdd-supply = <&mt6366_vsim2_reg>;
+		pwr18-supply = <&pp1800_dpbrdg_dx>;
+		reset-gpios = <&pio 177 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&it6505_pins>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+		#sound-dai-cells = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				it6505_in: endpoint {
+					link-frequencies = /bits/ 64 <150000000>;
+					remote-endpoint = <&dpi_out>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+			};
+		};
+	};
+};
+
+&i2c5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c5_pins>;
+	status = "okay";
+
+	rt5682s: codec at 1a {
+		compatible = "realtek,rt5682s";
+		reg = <0x1a>;
+		interrupts-extended = <&pio 17 IRQ_TYPE_EDGE_BOTH>;
+		AVDD-supply = <&mt6366_vio18_reg>;
+		DBVDD-supply = <&mt6366_vio18_reg>;
+		LDO1-IN-supply = <&mt6366_vio18_reg>;
+		MICVDD-supply = <&pp3300_z2>;
+		realtek,jd-src = <1>;
+		#sound-dai-cells = <1>;
+	};
+};
+
+&mfg0 {
+	domain-supply = <&mt6366_vsram_gpu_reg>;
+};
+
+&mfg1 {
+	domain-supply = <&mt6366_vgpu_reg>;
+};
+
+&mipi_tx0 {
+	status = "okay";
+};
+
+&mmc0 {
+	pinctrl-names = "default", "state_uhs";
+	pinctrl-0 = <&mmc0_pins_default>;
+	pinctrl-1 = <&mmc0_pins_uhs>;
+	bus-width = <8>;
+	max-frequency = <200000000>;
+	non-removable;
+	cap-mmc-highspeed;
+	mmc-hs200-1_8v;
+	mmc-hs400-1_8v;
+	supports-cqe;
+	no-sd;
+	no-sdio;
+	cap-mmc-hw-reset;
+	hs400-ds-delay = <0x11814>;
+	mediatek,hs400-ds-dly3 = <0x14>;
+	vmmc-supply = <&mt6366_vemc_reg>;
+	vqmmc-supply = <&mt6366_vio18_reg>;
+	status = "okay";
+};
+
+&mmc1 {
+	pinctrl-names = "default", "state_uhs", "state_eint";
+	pinctrl-0 = <&mmc1_pins_default>;
+	pinctrl-1 = <&mmc1_pins_uhs>;
+	pinctrl-2 = <&mmc1_pins_eint>;
+	/delete-property/ interrupts;
+	interrupt-names = "msdc", "sdio_wakeup";
+	interrupts-extended = <&gic GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH 0>,
+			      <&pio 87 IRQ_TYPE_LEVEL_LOW>;
+	bus-width = <4>;
+	max-frequency = <200000000>;
+	cap-sd-highspeed;
+	sd-uhs-sdr104;
+	sd-uhs-sdr50;
+	keep-power-in-suspend;
+	wakeup-source;
+	cap-sdio-irq;
+	no-mmc;
+	no-sd;
+	non-removable;
+	vmmc-supply = <&pp3300_s3>;
+	vqmmc-supply = <&mt6366_vio18_reg>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	status = "okay";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	bluetooth at 2 {
+		compatible = "mediatek,mt7921s-bluetooth";
+		reg = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_pins_reset>;
+		reset-gpios = <&pio 155 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&nor_flash {
+	pinctrl-names = "default";
+	pinctrl-0 = <&nor_pins_default>;
+	assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D7_D4>;
+	status = "okay";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	flash at 0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <39000000>;
+	};
+};
+
+&pio {
+	/* 185 lines */
+	gpio-line-names = "TP",
+			  "TP",
+			  "TP",
+			  "I2S0_HP_DI",
+			  "I2S3_DP_SPKR_DO",
+			  "SAR_INT_ODL",
+			  "BT_WAKE_AP_ODL",
+			  "WIFI_INT_ODL",
+			  "DPBRDG_INT_ODL",
+			  "EDPBRDG_INT_ODL",
+			  "EC_AP_HPD_OD",
+			  "TCHPAD_INT_ODL",
+			  "TCHSCR_INT_1V8_ODL",
+			  "EC_AP_INT_ODL",
+			  "EC_IN_RW_ODL",
+			  "GSC_AP_INT_ODL",
+			  /* AP_FLASH_WP_L is crossystem ABI. Rev1 schematics call it AP_WP_ODL. */
+			  "AP_FLASH_WP_L",
+			  "HP_INT_ODL",
+			  "PEN_EJECT_OD",
+			  "WCAM_PWDN_L",
+			  "WCAM_RST_L",
+			  "UCAM_SEN_EN",
+			  "UCAM_RST_L",
+			  "LTE_RESET_L",
+			  "LTE_SAR_DETECT_L",
+			  "I2S2_DP_SPK_MCK",
+			  "I2S2_DP_SPKR_BCK",
+			  "I2S2_DP_SPKR_LRCK",
+			  "I2S2_DP_SPKR_DI (TP)",
+			  "EN_PP1000_EDPBRDG",
+			  "EN_PP1800_EDPBRDG",
+			  "EN_PP3300_EDPBRDG",
+			  "UART_GSC_TX_AP_RX",
+			  "UART_AP_TX_GSC_RX",
+			  "UART_DBGCON_TX_ADSP_RX",
+			  "UART_ADSP_TX_DBGCON_RX",
+			  "EN_PP1000_DPBRDG",
+			  "TCHSCR_REPORT_DISABLE",
+			  "EN_PP3300_DPBRDG",
+			  "EN_PP1800_DPBRDG",
+			  "SPI_AP_CLK_EC",
+			  "SPI_AP_CS_EC_L",
+			  "SPI_AP_DO_EC_DI",
+			  "SPI_AP_DI_EC_DO",
+			  "SPI_AP_CLK_GSC",
+			  "SPI_AP_CS_GSC_L",
+			  "SPI_AP_DO_GSC_DI",
+			  "SPI_AP_DI_GSC_DO",
+			  "UART_DBGCON_TX_SCP_RX",
+			  "UART_SCP_TX_DBGCON_RX",
+			  "EN_PP1200_CAM_X",
+			  "EN_PP2800A_VCM_X",
+			  "EN_PP2800A_UCAM_X",
+			  "EN_PP2800A_WCAM_X",
+			  "WLAN_MODULE_RST_L",
+			  "EN_PP1200_UCAM_X",
+			  "I2S1_HP_DO",
+			  "I2S1_HP_BCK",
+			  "I2S1_HP_LRCK",
+			  "I2S1_HP_MCK",
+			  "TCHSCR_RST_1V8_L",
+			  "SPI_AP_CLK_ROM",
+			  "SPI_AP_CS_ROM_L",
+			  "SPI_AP_DO_ROM_DI",
+			  "SPI_AP_DI_ROM_DO",
+			  "NC",
+			  "NC",
+			  "EMMC_STRB",
+			  "EMMC_CLK",
+			  "EMMC_CMD",
+			  "EMMC_RST_L",
+			  "EMMC_DATA0",
+			  "EMMC_DATA1",
+			  "EMMC_DATA2",
+			  "EMMC_DATA3",
+			  "EMMC_DATA4",
+			  "EMMC_DATA5",
+			  "EMMC_DATA6",
+			  "EMMC_DATA7",
+			  "AP_KPCOL0",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "TP",
+			  "SDIO_CLK",
+			  "SDIO_CMD",
+			  "SDIO_DATA0",
+			  "SDIO_DATA1",
+			  "SDIO_DATA2",
+			  "SDIO_DATA3",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "EDPBRDG_PWREN",
+			  "BL_PWM_1V8",
+			  "EDPBRDG_RST_L",
+			  "MIPI_DPI_CLK",
+			  "MIPI_DPI_VSYNC",
+			  "MIPI_DPI_HSYNC",
+			  "MIPI_DPI_DE",
+			  "MIPI_DPI_D0",
+			  "MIPI_DPI_D1",
+			  "MIPI_DPI_D2",
+			  "MIPI_DPI_D3",
+			  "MIPI_DPI_D4",
+			  "MIPI_DPI_D5",
+			  "MIPI_DPI_D6",
+			  "MIPI_DPI_DA7",
+			  "MIPI_DPI_D8",
+			  "MIPI_DPI_D9",
+			  "MIPI_DPI_D10",
+			  "MIPI_DPI_D11",
+			  "PCM_BT_CLK",
+			  "PCM_BT_SYNC",
+			  "PCM_BT_DI",
+			  "PCM_BT_DO",
+			  "JTAG_TMS_TP",
+			  "JTAG_TCK_TP",
+			  "JTAG_TDI_TP",
+			  "JTAG_TDO_TP",
+			  "JTAG_TRSTN_TP",
+			  "CLK_24M_WCAM",
+			  "CLK_24M_UCAM",
+			  "UCAM_DET_ODL",
+			  "AP_I2C_EDPBRDG_SCL_1V8",
+			  "AP_I2C_EDPBRDG_SDA_1V8",
+			  "AP_I2C_TCHSCR_SCL_1V8",
+			  "AP_I2C_TCHSCR_SDA_1V8",
+			  "AP_I2C_TCHPAD_SCL_1V8",
+			  "AP_I2C_TCHPAD_SDA_1V8",
+			  "AP_I2C_DPBRDG_SCL_1V8",
+			  "AP_I2C_DPBRDG_SDA_1V8",
+			  "AP_I2C_WLAN_SCL_1V8",
+			  "AP_I2C_WLAN_SDA_1V8",
+			  "AP_I2C_AUD_SCL_1V8",
+			  "AP_I2C_AUD_SDA_1V8",
+			  "AP_I2C_TPM_SCL_1V8",
+			  "AP_I2C_UCAM_SDA_1V8",
+			  "AP_I2C_UCAM_SCL_1V8",
+			  "AP_I2C_UCAM_SDA_1V8",
+			  "AP_I2C_WCAM_SCL_1V8",
+			  "AP_I2C_WCAM_SDA_1V8",
+			  "SCP_I2C_SENSOR_SCL_1V8",
+			  "SCP_I2C_SENSOR_SDA_1V8",
+			  "AP_EC_WARM_RST_REQ",
+			  "AP_XHCI_INIT_DONE",
+			  "USB3_HUB_RST_L",
+			  "EN_SPKR",
+			  "BEEP_ON",
+			  "AP_EDP_BKLTEN",
+			  "EN_PP3300_DISP_X",
+			  "EN_PP3300_SDBRDG_X",
+			  "BT_KILL_1V8_L",
+			  "WIFI_KILL_1V8_L",
+			  "PWRAP_SPI0_CSN",
+			  "PWRAP_SPI0_CK",
+			  "PWRAP_SPI0_MO",
+			  "PWRAP_SPI0_MI",
+			  "SRCLKENA0",
+			  "SRCLKENA1",
+			  "SCP_VREQ_VAO",
+			  "AP_RTC_CLK32K",
+			  "AP_PMIC_WDTRST_L",
+			  "AUD_CLK_MOSI",
+			  "AUD_SYNC_MOSI",
+			  "AUD_DAT_MOSI0",
+			  "AUD_DAT_MOSI1",
+			  "AUD_CLK_MISO",
+			  "AUD_SYNC_MISO",
+			  "AUD_DAT_MISO0",
+			  "AUD_DAT_MISO1",
+			  "NC",
+			  "NC",
+			  "DPBRDG_PWREN",
+			  "DPBRDG_RST_L",
+			  "LTE_W_DISABLE_L",
+			  "LTE_SAR_DETECT_L",
+			  "EN_PP3300_LTE_X",
+			  "LTE_PWR_OFF_L",
+			  "LTE_RESET_L",
+			  "TP",
+			  "TP";
+
+	aud_clk_mosi_off: aud-clk-mosi-off-pins {
+		pins-clk-sync {
+			pinmux = <PINMUX_GPIO166__FUNC_GPIO166>,
+				 <PINMUX_GPIO167__FUNC_GPIO167>;
+			input-enable;
+			bias-pull-down;
+		};
+	};
+
+	aud_clk_mosi_on: aud-clk-mosi-on-pins {
+		pins-clk-sync {
+			pinmux = <PINMUX_GPIO166__FUNC_AUD_CLK_MOSI>,
+				 <PINMUX_GPIO167__FUNC_AUD_SYNC_MOSI>;
+		};
+	};
+
+	aud_clk_miso_off: aud-clk-miso-off-pins {
+		pins-clk-sync {
+			pinmux = <PINMUX_GPIO170__FUNC_GPIO170>,
+				 <PINMUX_GPIO171__FUNC_GPIO171>;
+			input-enable;
+			bias-pull-down;
+		};
+	};
+
+	aud_clk_miso_on: aud-clk-miso-on-pins {
+		pins-clk-sync {
+			pinmux = <PINMUX_GPIO170__FUNC_AUD_CLK_MISO>,
+				 <PINMUX_GPIO171__FUNC_AUD_SYNC_MISO>;
+		};
+	};
+
+	aud_dat_mosi_off: aud-dat-mosi-off-pins {
+		pins-dat {
+			pinmux = <PINMUX_GPIO168__FUNC_GPIO168>,
+				 <PINMUX_GPIO169__FUNC_GPIO169>;
+			input-enable;
+			bias-pull-down;
+		};
+	};
+
+	aud_dat_mosi_on: aud-dat-mosi-on-pins {
+		pins-dat {
+			pinmux = <PINMUX_GPIO168__FUNC_AUD_DAT_MOSI0>,
+				 <PINMUX_GPIO169__FUNC_AUD_DAT_MOSI1>;
+		};
+	};
+
+	aud_dat_miso_off: aud-dat-miso-off-pins {
+		pins-dat {
+			pinmux = <PINMUX_GPIO172__FUNC_GPIO172>,
+				 <PINMUX_GPIO173__FUNC_GPIO173>;
+			input-enable;
+			bias-pull-down;
+		};
+	};
+
+	aud_dat_miso_on: aud-dat-miso-on-pins {
+		pins-dat {
+			pinmux = <PINMUX_GPIO172__FUNC_AUD_DAT_MISO0>,
+				 <PINMUX_GPIO173__FUNC_AUD_DAT_MISO1>;
+			input-schmitt-enable;
+			bias-disable;
+		};
+	};
+
+	aud_gpio_i2s0_off: aud-gpio-i2s0-off-pins {
+		pins-sdata {
+			pinmux = <PINMUX_GPIO3__FUNC_GPIO3>;
+		};
+	};
+
+	aud_gpio_i2s0_on: aud-gpio-i2s0-on-pins {
+		pins-sdata {
+			pinmux = <PINMUX_GPIO3__FUNC_I2S0_DI>;
+		};
+	};
+
+	aud_gpio_i2s1_off: aud-gpio-i2s-off-pins {
+		pins-clk-sdata {
+			pinmux = <PINMUX_GPIO56__FUNC_GPIO56>,
+				 <PINMUX_GPIO57__FUNC_GPIO57>,
+				 <PINMUX_GPIO58__FUNC_GPIO58>,
+				 <PINMUX_GPIO59__FUNC_GPIO59>;
+			output-low;
+		};
+	};
+
+	aud_gpio_i2s1_on: aud-gpio-i2s1-on-pins {
+		pins-clk-sdata {
+			pinmux = <PINMUX_GPIO56__FUNC_I2S1_DO>,
+				 <PINMUX_GPIO57__FUNC_I2S1_BCK>,
+				 <PINMUX_GPIO58__FUNC_I2S1_LRCK>,
+				 <PINMUX_GPIO59__FUNC_I2S1_MCK>;
+		};
+	};
+
+	aud_gpio_i2s2_off: aud-gpio-i2s2-off-pins {
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO26__FUNC_GPIO26>,
+				 <PINMUX_GPIO27__FUNC_GPIO27>;
+			output-low;
+		};
+	};
+
+	aud_gpio_i2s2_on: aud-gpio-i2s2-on-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO26__FUNC_I2S2_BCK>,
+				 <PINMUX_GPIO27__FUNC_I2S2_LRCK>;
+			drive-strength = <4>;
+		};
+	};
+
+	aud_gpio_i2s3_off: aud-gpio-i2s3-off-pins {
+		pins-sdata {
+			pinmux = <PINMUX_GPIO4__FUNC_GPIO4>;
+			output-low;
+		};
+	};
+
+	aud_gpio_i2s3_on: aud-gpio-i2s3-on-pins {
+		pins-sdata {
+			pinmux = <PINMUX_GPIO4__FUNC_I2S3_DO>;
+			drive-strength = <4>;
+		};
+	};
+
+	aud_gpio_tdm_off: aud-gpio-tdm-off-pins { };
+
+	aud_gpio_tdm_on: aud-gpio-tdm-on-pins { };
+
+	aud_gpio_pcm_off: aud-gpio-pcm-off-pins {
+		pins-clk-sdata {
+			pinmux = <PINMUX_GPIO115__FUNC_GPIO115>,
+				 <PINMUX_GPIO116__FUNC_GPIO116>,
+				 <PINMUX_GPIO117__FUNC_GPIO117>,
+				 <PINMUX_GPIO118__FUNC_GPIO118>;
+			output-low;
+		};
+	};
+
+	aud_gpio_pcm_on: aud-gpio-pcm-on-pins {
+		pins-clk-sdata {
+			pinmux = <PINMUX_GPIO115__FUNC_PCM_CLK>,
+				 <PINMUX_GPIO116__FUNC_PCM_SYNC>,
+				 <PINMUX_GPIO117__FUNC_PCM_DI>,
+				 <PINMUX_GPIO118__FUNC_PCM_DO>;
+		};
+	};
+
+	aud_gpio_dmic_sec: aud-gpio-dmic-sec-pins {
+		pins {
+			pinmux = <PINMUX_GPIO23__FUNC_GPIO23>;
+			output-low;
+		};
+	};
+
+	bt_pins_reset: bt-reset-pins {
+		pins-bt-reset {
+			pinmux = <PINMUX_GPIO155__FUNC_GPIO155>;
+			output-high;
+		};
+	};
+
+	dpi_pins_sleep: dpi-sleep-pins {
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO103__FUNC_GPIO103>,
+				 <PINMUX_GPIO104__FUNC_GPIO104>,
+				 <PINMUX_GPIO105__FUNC_GPIO105>,
+				 <PINMUX_GPIO106__FUNC_GPIO106>,
+				 <PINMUX_GPIO107__FUNC_GPIO107>,
+				 <PINMUX_GPIO108__FUNC_GPIO108>,
+				 <PINMUX_GPIO109__FUNC_GPIO109>,
+				 <PINMUX_GPIO110__FUNC_GPIO110>,
+				 <PINMUX_GPIO111__FUNC_GPIO111>,
+				 <PINMUX_GPIO112__FUNC_GPIO112>,
+				 <PINMUX_GPIO113__FUNC_GPIO113>,
+				 <PINMUX_GPIO114__FUNC_GPIO114>,
+				 <PINMUX_GPIO101__FUNC_GPIO101>,
+				 <PINMUX_GPIO100__FUNC_GPIO100>,
+				 <PINMUX_GPIO102__FUNC_GPIO102>,
+				 <PINMUX_GPIO99__FUNC_GPIO99>;
+			drive-strength = <10>;
+			output-low;
+		};
+	};
+
+	dpi_pins_default: dpi-default-pins {
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO103__FUNC_DPI_DATA0>,
+				 <PINMUX_GPIO104__FUNC_DPI_DATA1>,
+				 <PINMUX_GPIO105__FUNC_DPI_DATA2>,
+				 <PINMUX_GPIO106__FUNC_DPI_DATA3>,
+				 <PINMUX_GPIO107__FUNC_DPI_DATA4>,
+				 <PINMUX_GPIO108__FUNC_DPI_DATA5>,
+				 <PINMUX_GPIO109__FUNC_DPI_DATA6>,
+				 <PINMUX_GPIO110__FUNC_DPI_DATA7>,
+				 <PINMUX_GPIO111__FUNC_DPI_DATA8>,
+				 <PINMUX_GPIO112__FUNC_DPI_DATA9>,
+				 <PINMUX_GPIO113__FUNC_DPI_DATA10>,
+				 <PINMUX_GPIO114__FUNC_DPI_DATA11>,
+				 <PINMUX_GPIO101__FUNC_DPI_HSYNC>,
+				 <PINMUX_GPIO100__FUNC_DPI_VSYNC>,
+				 <PINMUX_GPIO102__FUNC_DPI_DE>,
+				 <PINMUX_GPIO99__FUNC_DPI_PCLK>;
+			drive-strength = <10>;
+		};
+	};
+
+	ec_ap_int: cros-ec-int-pins {
+		pins-ec-ap-int-odl {
+			pinmux = <PINMUX_GPIO13__FUNC_GPIO13>;
+			input-enable;
+		};
+	};
+
+	edp_panel_fixed_pins: edp-panel-fixed-pins {
+		pins-vreg-en {
+			pinmux = <PINMUX_GPIO153__FUNC_GPIO153>;
+			output-high;
+		};
+	};
+
+	en_pp1800_dpbrdg: en-pp1800-dpbrdg-pins {
+		pins-vreg-en {
+			pinmux = <PINMUX_GPIO39__FUNC_GPIO39>;
+			output-low;
+		};
+	};
+
+	gsc_int: gsc-int-pins {
+		pins-gsc-ap-int-odl {
+			pinmux = <PINMUX_GPIO15__FUNC_GPIO15>;
+			input-enable;
+		};
+	};
+
+	i2c0_pins: i2c0-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO128__FUNC_SDA0>,
+				 <PINMUX_GPIO127__FUNC_SCL0>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	i2c1_pins: i2c1-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO130__FUNC_SDA1>,
+				 <PINMUX_GPIO129__FUNC_SCL1>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	i2c2_pins: i2c2-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO132__FUNC_SDA2>,
+				 <PINMUX_GPIO131__FUNC_SCL2>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	i2c3_pins: i2c3-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO134__FUNC_SDA3>,
+				 <PINMUX_GPIO133__FUNC_SCL3>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	i2c5_pins: i2c5-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO138__FUNC_SDA5>,
+				 <PINMUX_GPIO137__FUNC_SCL5>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	it6505_pins: it6505-pins {
+		pins-hpd {
+			pinmux = <PINMUX_GPIO10__FUNC_GPIO10>;
+			input-enable;
+			bias-pull-up;
+		};
+
+		pins-int {
+			pinmux = <PINMUX_GPIO8__FUNC_GPIO8>;
+			input-enable;
+			bias-pull-up;
+		};
+
+		pins-reset {
+			pinmux = <PINMUX_GPIO177__FUNC_GPIO177>;
+			output-low;
+			bias-pull-up;
+		};
+	};
+
+	mmc0_pins_default: mmc0-default-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO68__FUNC_MSDC0_CLK>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO71__FUNC_MSDC0_DAT0>,
+				 <PINMUX_GPIO72__FUNC_MSDC0_DAT1>,
+				 <PINMUX_GPIO73__FUNC_MSDC0_DAT2>,
+				 <PINMUX_GPIO74__FUNC_MSDC0_DAT3>,
+				 <PINMUX_GPIO75__FUNC_MSDC0_DAT4>,
+				 <PINMUX_GPIO76__FUNC_MSDC0_DAT5>,
+				 <PINMUX_GPIO77__FUNC_MSDC0_DAT6>,
+				 <PINMUX_GPIO78__FUNC_MSDC0_DAT7>,
+				 <PINMUX_GPIO69__FUNC_MSDC0_CMD>;
+			input-enable;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+
+		pins-rst {
+			pinmux = <PINMUX_GPIO70__FUNC_MSDC0_RSTB>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	mmc0_pins_uhs: mmc0-uhs-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO68__FUNC_MSDC0_CLK>;
+			drive-strength = <6>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO71__FUNC_MSDC0_DAT0>,
+				 <PINMUX_GPIO72__FUNC_MSDC0_DAT1>,
+				 <PINMUX_GPIO73__FUNC_MSDC0_DAT2>,
+				 <PINMUX_GPIO74__FUNC_MSDC0_DAT3>,
+				 <PINMUX_GPIO75__FUNC_MSDC0_DAT4>,
+				 <PINMUX_GPIO76__FUNC_MSDC0_DAT5>,
+				 <PINMUX_GPIO77__FUNC_MSDC0_DAT6>,
+				 <PINMUX_GPIO78__FUNC_MSDC0_DAT7>,
+				 <PINMUX_GPIO69__FUNC_MSDC0_CMD>;
+			input-enable;
+			drive-strength = <6>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+
+		pins-ds {
+			pinmux = <PINMUX_GPIO67__FUNC_MSDC0_DSL>;
+			drive-strength = <6>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-rst {
+			pinmux = <PINMUX_GPIO70__FUNC_MSDC0_RSTB>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	mmc1_pins_default: mmc1-default-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO84__FUNC_MSDC1_CLK>;
+			drive-strength = <6>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO86__FUNC_MSDC1_DAT0>,
+				 <PINMUX_GPIO87__FUNC_MSDC1_DAT1>,
+				 <PINMUX_GPIO88__FUNC_MSDC1_DAT2>,
+				 <PINMUX_GPIO89__FUNC_MSDC1_DAT3>,
+				 <PINMUX_GPIO85__FUNC_MSDC1_CMD>;
+			input-enable;
+			drive-strength = <6>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	mmc1_pins_uhs: mmc1-uhs-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO84__FUNC_MSDC1_CLK>;
+			drive-strength = <6>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO86__FUNC_MSDC1_DAT0>,
+				 <PINMUX_GPIO87__FUNC_MSDC1_DAT1>,
+				 <PINMUX_GPIO88__FUNC_MSDC1_DAT2>,
+				 <PINMUX_GPIO89__FUNC_MSDC1_DAT3>,
+				 <PINMUX_GPIO85__FUNC_MSDC1_CMD>;
+			input-enable;
+			drive-strength = <8>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	mmc1_pins_eint: mmc1-eint-pins {
+		pins-dat1 {
+			pinmux = <PINMUX_GPIO87__FUNC_GPIO87>;
+			input-enable;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	nor_pins_default: nor-default-pins {
+		pins-clk-dat {
+			pinmux = <PINMUX_GPIO63__FUNC_SPINOR_IO0>,
+				 <PINMUX_GPIO61__FUNC_SPINOR_CK>,
+				 <PINMUX_GPIO64__FUNC_SPINOR_IO1>;
+			drive-strength = <6>;
+			bias-pull-down;
+		};
+
+		pins-cs-dat {
+			pinmux = <PINMUX_GPIO62__FUNC_SPINOR_CS>,
+				 <PINMUX_GPIO65__FUNC_SPINOR_IO2>,
+				 <PINMUX_GPIO66__FUNC_SPINOR_IO3>;
+			drive-strength = <6>;
+			bias-pull-up;
+		};
+	};
+
+	pen_eject: pen-eject-pins {
+		pins {
+			pinmux = <PINMUX_GPIO18__FUNC_GPIO18>;
+			input-enable;
+			/* External pull-up. */
+			bias-disable;
+		};
+	};
+
+	pwm0_pin: disp-pwm-pins {
+		pins {
+			pinmux = <PINMUX_GPIO97__FUNC_DISP_PWM>;
+			output-high;
+		};
+	};
+
+	rt1019p_pins_default: rt1019p-default-pins {
+		pins-sdb {
+			pinmux = <PINMUX_GPIO150__FUNC_GPIO150>;
+			output-low;
+		};
+	};
+
+	scp_pins: scp-default-pins {
+		pins-scp-uart {
+			pinmux = <PINMUX_GPIO48__FUNC_TP_URXD2_AO>,
+				 <PINMUX_GPIO49__FUNC_TP_UTXD2_AO>;
+		};
+	};
+
+	spi1_pins: spi1-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO40__FUNC_SPI1_CLK_A>,
+				 <PINMUX_GPIO41__FUNC_SPI1_CSB_A>,
+				 <PINMUX_GPIO42__FUNC_SPI1_MO_A>,
+				 <PINMUX_GPIO43__FUNC_SPI1_MI_A>;
+			bias-disable;
+			input-enable;
+		};
+	};
+
+	spi2_pins: spi2-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO44__FUNC_SPI2_CLK_A>,
+				 <PINMUX_GPIO45__FUNC_GPIO45>,
+				 <PINMUX_GPIO46__FUNC_SPI2_MO_A>,
+				 <PINMUX_GPIO47__FUNC_SPI2_MI_A>;
+			bias-disable;
+			input-enable;
+		};
+	};
+
+	spmi_pins: spmi-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO183__FUNC_SPMI_SCL>,
+				 <PINMUX_GPIO184__FUNC_SPMI_SDA>;
+		};
+	};
+
+	touchscreen_pins: touchscreen-pins {
+		pins-irq {
+			pinmux = <PINMUX_GPIO12__FUNC_GPIO12>;
+			input-enable;
+			bias-pull-up;
+		};
+
+		pins-reset {
+			pinmux = <PINMUX_GPIO60__FUNC_GPIO60>;
+			output-high;
+		};
+
+		pins-report-sw {
+			pinmux = <PINMUX_GPIO37__FUNC_GPIO37>;
+			output-low;
+		};
+	};
+
+	trackpad_pin: trackpad-default-pins {
+		pins-int-n {
+			pinmux = <PINMUX_GPIO11__FUNC_GPIO11>;
+			input-enable;
+			bias-disable; /* pulled externally */
+		};
+	};
+
+	wifi_enable_pin: wifi-enable-pins {
+		pins-wifi-enable {
+			pinmux = <PINMUX_GPIO54__FUNC_GPIO54>;
+		};
+	};
+
+	wifi_wakeup_pin: wifi-wakeup-pins {
+		pins-wifi-wakeup {
+			pinmux = <PINMUX_GPIO7__FUNC_GPIO7>;
+			input-enable;
+		};
+	};
+};
+
+&pwm0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm0_pin>;
+	status = "okay";
+};
+
+&pwrap {
+	pmic {
+		compatible = "mediatek,mt6366", "mediatek,mt6358";
+		interrupt-controller;
+		interrupts-extended = <&pio 201 IRQ_TYPE_LEVEL_HIGH>;
+		#interrupt-cells = <2>;
+
+		mt6366codec: codec {
+			compatible = "mediatek,mt6366-sound", "mediatek,mt6358-sound";
+			Avdd-supply = <&mt6366_vaud28_reg>;
+			mediatek,dmic-mode = <1>; /* one-wire */
+		};
+
+		mt6366_regulators: regulators {
+			compatible = "mediatek,mt6366-regulator", "mediatek,mt6358-regulator";
+			vsys-ldo1-supply = <&pp4200_z2>;
+			vsys-ldo2-supply = <&pp4200_z2>;
+			vsys-ldo3-supply = <&pp4200_z2>;
+			vsys-vcore-supply = <&pp4200_z2>;
+			vsys-vdram1-supply = <&pp4200_z2>;
+			vsys-vgpu-supply = <&pp4200_z2>;
+			vsys-vmodem-supply = <&pp4200_z2>;
+			vsys-vpa-supply = <&pp4200_z2>;
+			vsys-vproc11-supply = <&pp4200_z2>;
+			vsys-vproc12-supply = <&pp4200_z2>;
+			vsys-vs1-supply = <&pp4200_z2>;
+			vsys-vs2-supply = <&pp4200_z2>;
+			vs1-ldo1-supply = <&mt6366_vs1_reg>;
+			vs2-ldo1-supply = <&mt6366_vdram1_reg>;
+			vs2-ldo2-supply = <&mt6366_vs2_reg>;
+			vs2-ldo3-supply = <&mt6366_vs2_reg>;
+
+			vcore {
+				regulator-name = "pp0750_dvdd_core";
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <800000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <200>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-always-on;
+			};
+
+			mt6366_vdram1_reg: vdram1 {
+				regulator-name = "pp1125_emi_vdd2";
+				regulator-min-microvolt = <1125000>;
+				regulator-max-microvolt = <1125000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <0>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-always-on;
+			};
+
+			mt6366_vgpu_reg: vgpu {
+				/*
+				 * Called "ppvar_dvdd_gpu" in the schematic.
+				 * Called "ppvar_dvdd_vgpu" here to match
+				 * regulator coupling requirements.
+				 */
+				regulator-name = "ppvar_dvdd_vgpu";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <200>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-coupled-with = <&mt6366_vsram_gpu_reg>;
+				regulator-coupled-max-spread = <10000>;
+			};
+
+			mt6366_vproc11_reg: vproc11 {
+				regulator-name = "ppvar_dvdd_proc_bc_mt6366";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <200>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-always-on;
+			};
+
+			mt6366_vproc12_reg: vproc12 {
+				regulator-name = "ppvar_dvdd_proc_lc";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <200>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-always-on;
+			};
+
+			mt6366_vs1_reg: vs1 {
+				regulator-name = "pp2000_vs1";
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <0>;
+				regulator-always-on;
+			};
+
+			mt6366_vs2_reg: vs2 {
+				regulator-name = "pp1350_vs2";
+				regulator-min-microvolt = <1350000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <0>;
+				regulator-always-on;
+			};
+
+			va12 {
+				regulator-name = "pp1200_va12";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-enable-ramp-delay = <270>;
+				regulator-always-on;
+			};
+
+			mt6366_vaud28_reg: vaud28 {
+				regulator-name = "pp2800_vaud28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vaux18_reg: vaux18 {
+				regulator-name = "pp1840_vaux18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1840000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vbif28_reg: vbif28 {
+				regulator-name = "pp2800_vbif28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vcn18_reg: vcn18 {
+				regulator-name = "pp1800_vcn18_x";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vcn28_reg: vcn28 {
+				regulator-name = "pp2800_vcn28_x";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vefuse_reg: vefuse {
+				regulator-name = "pp1800_vefuse";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vfe28_reg: vfe28 {
+				regulator-name = "pp2800_vfe28_x";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vemc_reg: vemc {
+				regulator-name = "pp3000_vemc";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <60>;
+			};
+
+			mt6366_vibr_reg: vibr {
+				regulator-name = "pp2800_vibr_x";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <60>;
+			};
+
+			mt6366_vio18_reg: vio18 {
+				regulator-name = "pp1800_vio18_s3";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <2700>;
+				regulator-always-on;
+			};
+
+			mt6366_vio28_reg: vio28 {
+				regulator-name = "pp2800_vio28_x";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vm18_reg: vm18 {
+				regulator-name = "pp1800_emi_vdd1";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1840000>;
+				regulator-enable-ramp-delay = <325>;
+				regulator-always-on;
+			};
+
+			mt6366_vmc_reg: vmc {
+				regulator-name = "pp3000_vmc";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <60>;
+			};
+
+			mt6366_vmddr_reg: vmddr {
+				regulator-name = "pm0750_emi_vmddr";
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <750000>;
+				regulator-enable-ramp-delay = <325>;
+				regulator-always-on;
+			};
+
+			mt6366_vmch_reg: vmch {
+				regulator-name = "pp3000_vmch";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <60>;
+			};
+
+			mt6366_vcn33_reg: vcn33 {
+				regulator-name = "pp3300_vcn33_x";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			vdram2 {
+				regulator-name = "pp0600_emi_vddq";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <600000>;
+				regulator-enable-ramp-delay = <3300>;
+				regulator-always-on;
+			};
+
+			mt6366_vrf12_reg: vrf12 {
+				regulator-name = "pp1200_vrf12_x";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-enable-ramp-delay = <120>;
+			};
+
+			mt6366_vrf18_reg: vrf18 {
+				regulator-name = "pp1800_vrf18_x";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <120>;
+			};
+
+			vsim1 {
+				regulator-name = "pp1860_vsim1_x";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1860000>;
+				regulator-enable-ramp-delay = <540>;
+			};
+
+			mt6366_vsim2_reg: vsim2 {
+				regulator-name = "pp2760_vsim2_x";
+				regulator-min-microvolt = <2700000>;
+				regulator-max-microvolt = <2760000>;
+				regulator-enable-ramp-delay = <540>;
+			};
+
+			mt6366_vsram_gpu_reg: vsram-gpu {
+				regulator-name = "pp0900_dvdd_sram_gpu";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <1050000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <240>;
+				regulator-coupled-with = <&mt6366_vgpu_reg>;
+				regulator-coupled-max-spread = <10000>;
+			};
+
+			mt6366_vsram_others_reg: vsram-others {
+				regulator-name = "pp0900_dvdd_sram_core";
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <240>;
+				regulator-always-on;
+			};
+
+			mt6366_vsram_proc11_reg: vsram-proc11 {
+				regulator-name = "pp0900_dvdd_sram_bc";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <1120000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <240>;
+				regulator-always-on;
+			};
+
+			mt6366_vsram_proc12_reg: vsram-proc12 {
+				regulator-name = "pp0900_dvdd_sram_lc";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <1120000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <240>;
+				regulator-always-on;
+			};
+
+			vusb {
+				regulator-name = "pp3070_vusb";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3070000>;
+				regulator-enable-ramp-delay = <270>;
+				regulator-always-on;
+			};
+
+			vxo22 {
+				regulator-name = "pp2240_vxo22";
+				regulator-min-microvolt = <2200000>;
+				regulator-max-microvolt = <2240000>;
+				regulator-enable-ramp-delay = <120>;
+				/* Feeds DCXO internally */
+				regulator-always-on;
+			};
+		};
+
+		rtc {
+			compatible = "mediatek,mt6366-rtc", "mediatek,mt6358-rtc";
+		};
+	};
+};
+
+&scp {
+	pinctrl-names = "default";
+	pinctrl-0 = <&scp_pins>;
+	firmware-name = "mediatek/mt8186/scp.img";
+	memory-region = <&scp_mem>;
+	status = "okay";
+
+	cros-ec-rpmsg {
+		compatible = "google,cros-ec-rpmsg";
+		mediatek,rpmsg-name = "cros-ec-rpmsg";
+	};
+};
+
+&spi1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi1_pins>;
+	mediatek,pad-select = <0>;
+	status = "okay";
+
+	cros_ec: ec at 0 {
+		compatible = "google,cros-ec-spi";
+		reg = <0>;
+		spi-max-frequency = <1000000>;
+		interrupts-extended = <&pio 13 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ec_ap_int>;
+
+		i2c_tunnel: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			google,remote-bus = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		typec {
+			compatible = "google,cros-ec-typec";
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			usb_c0: connector at 0 {
+				compatible = "usb-c-connector";
+				reg = <0>;
+				label = "left";
+				power-role = "dual";
+				data-role = "host";
+				try-power-role = "source";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port at 1 {
+						reg = <1>;
+
+						typec_port0: endpoint { };
+					};
+				};
+			};
+
+			usb_c1: connector at 1 {
+				compatible = "usb-c-connector";
+				reg = <1>;
+				label = "right";
+				power-role = "dual";
+				data-role = "host";
+				try-power-role = "source";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port at 1 {
+						reg = <1>;
+
+						typec_port1: endpoint { };
+					};
+				};
+			};
+		};
+	};
+};
+
+&spi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2_pins>;
+	cs-gpios = <&pio 45 GPIO_ACTIVE_LOW>;
+	mediatek,pad-select = <0>;
+	status = "okay";
+
+	tpm at 0 {
+		compatible = "google,cr50";
+		reg = <0>;
+		spi-max-frequency = <1000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gsc_int>;
+		interrupt-parent = <&pio>;
+		interrupts = <15 IRQ_TYPE_EDGE_RISING>;
+	};
+};
+
+&ssusb0 {
+	status = "okay";
+};
+
+&ssusb1 {
+	status = "okay";
+};
+
+&u3phy0 {
+	status = "okay";
+};
+
+&u3phy1 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&usb_host0 {
+	vbus-supply = <&pp3300_s3>;
+	status = "okay";
+};
+
+&usb_host1 {
+	vbus-supply = <&usb_p1_vbus>;
+	status = "okay";
+	#address-cells = <2>;
+	#size-cells = <2>;
+};
+
+&watchdog {
+	mediatek,reset-by-toprgu;
+};
+
+#include <arm/cros-ec-keyboard.dtsi>
+#include <arm/cros-ec-sbs.dtsi>
-- 
2.43.0.rc2.451.g8631bc7472-goog



From maz at kernel.org  Mon Dec  4 00:42:47 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 08:42:47 +0000
Subject: [PATCH V15 5/8] KVM: arm64: nvhe: Disable branch generation in nVHE guests
In-Reply-To: <20231201053906.1261704-6-anshuman.khandual@arm.com>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
	<20231201053906.1261704-6-anshuman.khandual@arm.com>
Message-ID: <86ttoybbp4.wl-maz@kernel.org>

On Fri, 01 Dec 2023 05:39:03 +0000,
Anshuman Khandual <anshuman.khandual at arm.com> wrote:
> 
> Disable the BRBE before we enter the guest, saving the status and enable it
> back once we get out of the guest. This is just to avoid capturing records
> in the guest kernel/userspace, which would be confusing the samples.

Why does it have to be limited to non-VHE? What protects host EL0
records from guest's EL0 execution when the host is VHE?

> 
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: Oliver Upton <oliver.upton at linux.dev>
> Cc: James Morse <james.morse at arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: kvmarm at lists.linux.dev
> Cc: linux-arm-kernel at lists.infradead.org
> CC: linux-kernel at vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
> Changes in V15:
> 
> - Dropped runtime BRBE enable for setting DEBUG_STATE_SAVE_BRBE
> - Dropped BRBFCR_EL1 from __debug_save_brbe()/__debug_restore_brbe()
> - Always save the live SYS_BRBCR_EL1 in host context and then check if
>   BRBE was enabled before resetting SYS_BRBCR_EL1 for the host
> 
>  arch/arm64/include/asm/kvm_host.h  |  4 ++++
>  arch/arm64/kvm/debug.c             |  5 +++++
>  arch/arm64/kvm/hyp/nvhe/debug-sr.c | 33 ++++++++++++++++++++++++++++++
>  3 files changed, 42 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 68421c74283a..1faa0430d8dd 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -449,6 +449,8 @@ enum vcpu_sysreg {
>  	CNTHV_CVAL_EL2,
>  	PMSCR_EL1,	/* Statistical profiling extension */
>  	TRFCR_EL1,	/* Self-hosted trace filters */
> +	BRBCR_EL1,	/* Branch Record Buffer Control Register */
> +	BRBFCR_EL1,	/* Branch Record Buffer Function Control Register */

Whose state is this? If this is limited to the host, it has no purpose
in this enum. Once you add guest support, then it will make sense.

>
>  	NR_SYS_REGS	/* Nothing after this line! */
>  };
> @@ -753,6 +755,8 @@ struct kvm_vcpu_arch {
>  #define VCPU_HYP_CONTEXT	__vcpu_single_flag(iflags, BIT(7))
>  /* Save trace filter controls */
>  #define DEBUG_STATE_SAVE_TRFCR	__vcpu_single_flag(iflags, BIT(8))
> +/* Save BRBE context if active  */
> +#define DEBUG_STATE_SAVE_BRBE	__vcpu_single_flag(iflags, BIT(9))
>  
>  /* SVE enabled for host EL0 */
>  #define HOST_SVE_ENABLED	__vcpu_single_flag(sflags, BIT(0))
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 2ab41b954512..fa46a70a9503 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -354,6 +354,10 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
>  		    !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P))
>  			vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>  	}
> +
> +	/* Check if we have BRBE implemented and available at the host */
> +	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_BRBE_SHIFT))
> +		vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_BRBE);
>  }
>  
>  void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
> @@ -361,6 +365,7 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_SPE);
>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
> +	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_BRBE);
>  }
>  
>  void kvm_etm_set_guest_trfcr(u64 trfcr_guest)
> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> index 6174f710948e..1994fc48b57c 100644
> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> @@ -93,6 +93,33 @@ static void __debug_restore_trace(struct kvm_cpu_context *host_ctxt,
>  		write_sysreg_s(ctxt_sys_reg(host_ctxt, TRFCR_EL1), SYS_TRFCR_EL1);
>  }
>  
> +static void __debug_save_brbe(struct kvm_cpu_context *host_ctxt)
> +{
> +	ctxt_sys_reg(host_ctxt, BRBCR_EL1) = read_sysreg_s(SYS_BRBCR_EL1);
> +
> +	/* Check if the BRBE is enabled */
> +	if (!(ctxt_sys_reg(host_ctxt, BRBCR_EL1) & (BRBCR_ELx_E0BRE | BRBCR_ELx_ExBRE)))
> +		return;

Why save BRBCR_EL1 if there is nothing enabled? It isn't like it can
change behind your back, can it?

> +
> +	/*
> +	 * Prohibit branch record generation while we are in guest.
> +	 * Since access to BRBCR_EL1 is trapped, the guest can't
> +	 * modify the filtering set by the host.
> +	 */
> +	write_sysreg_s(0, SYS_BRBCR_EL1);
> +	isb();

What is the point of this ISB? We're at EL2, and this only affects
EL1.

> +}
> +
> +static void __debug_restore_brbe(struct kvm_cpu_context *host_ctxt)
> +{
> +	if (!ctxt_sys_reg(host_ctxt, BRBCR_EL1))
> +		return;

So on one side you're using a flag, and on the other you're using the
*value*. You need some consistency.

> +
> +	/* Restore BRBE controls */
> +	write_sysreg_s(ctxt_sys_reg(host_ctxt, BRBCR_EL1), SYS_BRBCR_EL1);
> +	isb();

Same question.

> +}
> +
>  void __debug_save_host_buffers_nvhe(struct kvm_cpu_context *host_ctxt,
>  				    struct kvm_cpu_context *guest_ctxt)
>  {
> @@ -102,6 +129,10 @@ void __debug_save_host_buffers_nvhe(struct kvm_cpu_context *host_ctxt,
>  
>  	if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_TRFCR))
>  		__debug_save_trace(host_ctxt, guest_ctxt);
> +
> +	/* Disable BRBE branch records */
> +	if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_BRBE))
> +		__debug_save_brbe(host_ctxt);
>  }
>  
>  void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
> @@ -116,6 +147,8 @@ void __debug_restore_host_buffers_nvhe(struct kvm_cpu_context *host_ctxt,
>  		__debug_restore_spe(host_ctxt);
>  	if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_TRFCR))
>  		__debug_restore_trace(host_ctxt, guest_ctxt);
> +	if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_BRBE))
> +		__debug_restore_brbe(host_ctxt);
>  }
>  
>  void __debug_switch_to_host(struct kvm_vcpu *vcpu)

The lifetime of this flag seems bogus, specially when there is nothing
to do, which will always be the arch-majority of the executions.

	M.

-- 
Without deviation from the norm, progress is not possible.


From bhe at redhat.com  Mon Dec  4 00:43:05 2023
From: bhe at redhat.com (Baoquan He)
Date: Mon, 4 Dec 2023 16:43:05 +0800
Subject: [PATCH v3 2/7] kexec_file: print out debugging message if
 required
In-Reply-To: <81c62af671ebbfad61dd46aa056050a56bf535a2.camel@perches.com>
References: <20231130023955.5257-1-bhe@redhat.com>
 <20231130023955.5257-3-bhe@redhat.com>
 <81c62af671ebbfad61dd46aa056050a56bf535a2.camel@perches.com>
Message-ID: <ZW2RGdFFsO1yIaZm@MiWiFi-R3L-srv>

On 11/29/23 at 06:52pm, Joe Perches wrote:
> On Thu, 2023-11-30 at 10:39 +0800, Baoquan He wrote:
> > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > loading related codes.
> 
> trivia:
> 
> > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> []
> > @@ -551,9 +551,12 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
> >  		phdr->p_filesz = phdr->p_memsz = mend - mstart + 1;
> >  		phdr->p_align = 0;
> >  		ehdr->e_phnum++;
> > -		pr_debug("Crash PT_LOAD ELF header. phdr=%p vaddr=0x%llx, paddr=0x%llx, sz=0x%llx e_phnum=%d p_offset=0x%llx\n",
> > -			phdr, phdr->p_vaddr, phdr->p_paddr, phdr->p_filesz,
> > -			ehdr->e_phnum, phdr->p_offset);
> > +#ifdef CONFIG_KEXEC_FILE
> > +		kexec_dprintk("Crash PT_LOAD ELF header. phdr=%p vaddr=0x%llx, paddr=0x%llx, "
> > +			      "sz=0x%llx e_phnum=%d p_offset=0x%llx\n",
> > +			      phdr, phdr->p_vaddr, phdr->p_paddr, phdr->p_filesz,
> > +			      ehdr->e_phnum, phdr->p_offset);
> > +#endif
> 
> Perhaps run checkpatch and coalesce the format string.

Sorry for being late to reply, this comment was missed.

I broke it into two because it's a too long line and not friendly for
reading. I did notice there's such line breaking code. I can change it
if it's not suggested. Thanks for careful checking.



From hch at lst.de  Mon Dec  4 00:43:19 2023
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 4 Dec 2023 09:43:19 +0100
Subject: [PATCH 4/7] dma-mapping: Add helpers for dma_range_map bounds
In-Reply-To: <b6626985d97ddc33a23b4b9fafa881b35001547e.1701268753.git.robin.murphy@arm.com>
References: <cover.1701268753.git.robin.murphy@arm.com> <b6626985d97ddc33a23b4b9fafa881b35001547e.1701268753.git.robin.murphy@arm.com>
Message-ID: <20231204084319.GA919@lst.de>

On Wed, Nov 29, 2023 at 05:43:01PM +0000, Robin Murphy wrote:
> Several places want to compute the lower and/or upper bounds of a
> dma_range_map, so let's factor that out into reusable helpers.

As the build bot pointed out this will need a fix for the initialization
all-Fs for a 32-bit dma_addr_t, e.g. by using (dma_addr_t)-1, but
otherwise looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at lst.de  Mon Dec  4 00:44:40 2023
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 4 Dec 2023 09:44:40 +0100
Subject: [PATCH 7/7] dma-mapping: Simplify arch_setup_dma_ops()
In-Reply-To: <590a4a1b7d10fb9bb1c42ca6cd438e98e6cc94a7.1701268753.git.robin.murphy@arm.com>
References: <cover.1701268753.git.robin.murphy@arm.com> <590a4a1b7d10fb9bb1c42ca6cd438e98e6cc94a7.1701268753.git.robin.murphy@arm.com>
Message-ID: <20231204084440.GB919@lst.de>

On Wed, Nov 29, 2023 at 05:43:04PM +0000, Robin Murphy wrote:
> The dma_base, size and iommu arguments are only used by ARM, and can
> now easily be deduced from the device itself, so there's no need to pass
> them through the callchain as well.

This looks even better than the patch form Jason that only removed the
iommu argument:

Reviewed-by: Christoph Hellwig <hch at lst.de>

I wonder if it makes sense to also remove the coherent argument
by setting up dev->dma_coherent in the caller.  That would require
a pretty careful audit as we're doing a few weird things in that
area, though.



From jasowang at redhat.com  Mon Dec  4 00:47:49 2023
From: jasowang at redhat.com (Jason Wang)
Date: Mon, 4 Dec 2023 16:47:49 +0800
Subject: [RFC PATCH] KVM: arm/arm64: GICv4: Support shared VLPI
In-Reply-To: <CACGkMEt5sapZjpyBSM5oX_=k1AcefEe5D4wtX=HqtHy4AD3j_g@mail.gmail.com>
References: <20231102143507.840-1-jiangkunkun@huawei.com> <87msvt6cc7.wl-maz@kernel.org>
 <1fb8353e-e9c4-2570-c2ca-ec537c18ac4d@huawei.com> <86edh228xx.wl-maz@kernel.org>
 <952bd5dc-dd20-acc3-d77e-c9b14e5728d3@huawei.com> <87fs0k94og.wl-maz@kernel.org>
 <CACGkMEt5sapZjpyBSM5oX_=k1AcefEe5D4wtX=HqtHy4AD3j_g@mail.gmail.com>
Message-ID: <CACGkMEub4f0FWsrJzSK4e+9cC6LUNFm3vAcfSkpsp6pD=WM5qA@mail.gmail.com>

On Mon, Dec 4, 2023 at 4:39?PM Jason Wang <jasowang at redhat.com> wrote:
>
> On Sat, Dec 2, 2023 at 8:20?PM Marc Zyngier <maz at kernel.org> wrote:
> >
> > Hi Kunkun,
> >
> > On Wed, 08 Nov 2023 09:45:51 +0000,
> > Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> > >
> > > Hi Marc,
> > >
> > > On 2023/11/6 23:33, Marc Zyngier wrote:
> > > > On Mon, 06 Nov 2023 14:59:01 +0000,
> > > > Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> > > >> The virtio-pci driver write entry1-6
> > > >> massage.data in the msix-table and trap to QEMU for processing. The
> > > >> massage.data is as follow:
> > > >>> entry-0 0
> > > >>> entry-1 1
> > > >>> entry-2 1
> > > >>> entry-3 1
> > > >>> entry-4 1
> > > >>> entry-5 1
> > > >>> entry-6 1
>
> It looks like a bug from the driver. It should only use vector 0 and 1
> in this case.
>
> Could you please check the queue_msix_vector for each queue in this case?

Or did you actually mean queue_msix_vector here? I'm not familiar with
ARM but 0 doesn't seem to be a good message.data anyhow.

Thanks



From peteryin.openbmc at gmail.com  Mon Dec  4 00:46:41 2023
From: peteryin.openbmc at gmail.com (PeterYin)
Date: Mon, 4 Dec 2023 16:46:41 +0800
Subject: [PATCH v5 0/2] Add Facebook Minerva Harma (AST2600) BMC
In-Reply-To: <fddcbad4-5368-4c2a-ba87-f4c4326a8385@linaro.org>
References: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
 <fddcbad4-5368-4c2a-ba87-f4c4326a8385@linaro.org>
Message-ID: <3ff5dcd7-69a3-4098-92c6-ed1e8f0bd8f9@gmail.com>


Krzysztof Kozlowski ? 12/4/23 16:20 ??:
> On 04/12/2023 09:10, Peter Yin wrote:
>> Summary:
>> Add linux device tree entry related to Minerva Harma
>> specific devices connected to BMC SoC.
>>
>> v4:https://lore.kernel.org/all/20231204054131.1845775-3-peter.yin at quantatw.com/
>> v3:https://lore.kernel.org/all/20231123050415.3441429-3-peteryin.openbmc at gmail.com/
>> v2:https://lore.kernel.org/all/cdbc75b9-3be1-4017-9bee-c8f161b6843c at linaro.org/
>> v1:https://lore.kernel.org/all/20231024082404.735843-3-peteryin.openbmc at gmail.com/
>>
>> Change log
>> v4 -> v5
>>    - Rename document and file from minerva-harma to harma.
> 
> You must explain that you dropped people's review for some reason.
> 
> Best regards,
> Krzysztof
> 
Due to changes in the project name and content, please assist in 
reviewing it.

Thanks,
Peter.


From quic_snehshah at quicinc.com  Mon Dec  4 00:48:54 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Mon,  4 Dec 2023 14:18:54 +0530
Subject: [PATCH net-next] net: stmmac: qcom-ethqos: Add sysfs nodes for qcom ethqos
Message-ID: <20231204084854.31543-1-quic_snehshah@quicinc.com>

Add sysfs nodes to conifigure routing of specific vlan id to GVM queue.
GVM queue is not exposed to PVM stmmac, so TC ops can't configure routing.

Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
---
 .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 216 +++++++++++++++++-
 1 file changed, 215 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index d3bf42d0fceb..ea89045a90a1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -109,6 +109,8 @@ struct qcom_ethqos {
 	unsigned int num_por;
 	bool rgmii_config_loopback_en;
 	bool has_emac_ge_3;
+	int gvm_vlan_prio;
+	int gvm_queue;
 };
 
 static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
@@ -710,6 +712,214 @@ static void ethqos_ptp_clk_freq_config(struct stmmac_priv *priv)
 	netdev_dbg(priv->dev, "PTP rate %d\n", plat_dat->clk_ptp_rate);
 }
 
+static ssize_t gvm_vlan_routing_store(struct device *dev,
+				      struct device_attribute *attr,
+				      const char *user_buf, size_t size)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	struct stmmac_priv *priv;
+	struct qcom_ethqos *ethqos;
+	u32 prio;
+	s8 input = 0;
+
+	if (!netdev) {
+		pr_err("netdev is NULL\n");
+		return -EINVAL;
+	}
+
+	priv = netdev_priv(netdev);
+	if (!priv) {
+		pr_err("priv is NULL\n");
+		return -EINVAL;
+	}
+
+	ethqos = priv->plat->bsp_priv;
+	if (!ethqos) {
+		pr_err("ethqos is NULL\n");
+		return -EINVAL;
+	}
+
+	if (kstrtos8(user_buf, 0, &input)) {
+		pr_err("Error in reading option from user\n");
+		return -EINVAL;
+	}
+
+	if (input < 1 || input > 7) {
+		pr_err("Invalid option set by user\n");
+		return -EINVAL;
+	}
+
+	if (input == ethqos->gvm_vlan_prio)
+		pr_err("No effect as duplicate input\n");
+
+	ethqos->gvm_vlan_prio = input;
+	prio  = 1 << input;
+
+	stmmac_rx_queue_prio(priv, priv->hw, prio, ethqos->gvm_queue);
+
+	return size;
+}
+
+static ssize_t gvm_queue_mapping_store(struct device *dev,
+				       struct device_attribute *attr,
+				       const char *user_buf, size_t size)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	struct stmmac_priv *priv;
+	struct qcom_ethqos *ethqos;
+	u32 prio;
+	s8 input = 0;
+
+	if (!netdev) {
+		pr_err("netdev is NULL\n");
+		return -EINVAL;
+	}
+
+	priv = netdev_priv(netdev);
+	if (!priv) {
+		pr_err("priv is NULL\n");
+		return -EINVAL;
+	}
+
+	ethqos = priv->plat->bsp_priv;
+	if (!ethqos) {
+		pr_err("ethqos is NULL\n");
+		return -EINVAL;
+	}
+
+	if (kstrtos8(user_buf, 0, &input)) {
+		pr_err("Error in reading option from user\n");
+		return -EINVAL;
+	}
+
+	if (input == ethqos->gvm_queue)
+		pr_err("No effect as duplicate input\n");
+
+	ethqos->gvm_queue = input;
+	prio  = 1 << input;
+
+	return size;
+}
+
+static ssize_t gvm_queue_mapping_show(struct device *dev,
+				      struct device_attribute *attr, char *user_buf)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	struct stmmac_priv *priv;
+	struct qcom_ethqos *ethqos;
+
+	if (!netdev) {
+		pr_err("netdev is NULL\n");
+		return -EINVAL;
+	}
+
+	priv = netdev_priv(netdev);
+	if (!priv) {
+		pr_err("priv is NULL\n");
+		return -EINVAL;
+	}
+
+	ethqos = priv->plat->bsp_priv;
+	if (!ethqos) {
+		pr_err("ethqos is NULL\n");
+		return -EINVAL;
+	}
+
+	return scnprintf(user_buf, 256, "%d\n", ethqos->gvm_queue);
+}
+
+static ssize_t gvm_vlan_routing_show(struct device *dev,
+				     struct device_attribute *attr, char *user_buf)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	struct stmmac_priv *priv;
+	struct qcom_ethqos *ethqos;
+
+	if (!netdev) {
+		pr_err("netdev is NULL\n");
+		return -EINVAL;
+	}
+
+	priv = netdev_priv(netdev);
+	if (!priv) {
+		pr_err("priv is NULL\n");
+		return -EINVAL;
+	}
+
+	ethqos = priv->plat->bsp_priv;
+	if (!ethqos) {
+		pr_err("ethqos is NULL\n");
+		return -EINVAL;
+	}
+
+	return scnprintf(user_buf, 256, "%d\n", ethqos->gvm_vlan_prio);
+}
+
+static DEVICE_ATTR_RW(gvm_queue_mapping);
+
+static DEVICE_ATTR_RW(gvm_vlan_routing);
+
+static int ethqos_remove_sysfs(struct qcom_ethqos *ethqos)
+{
+	struct net_device *net_dev;
+
+	if (!ethqos) {
+		pr_err("ethqos is NULL\n");
+		return -EINVAL;
+	}
+
+	net_dev = platform_get_drvdata(ethqos->pdev);
+	if (!net_dev) {
+		pr_err("netdev is NULL\n");
+		return -EINVAL;
+	}
+
+	sysfs_remove_file(&net_dev->dev.kobj,
+			  &dev_attr_gvm_queue_mapping.attr);
+	sysfs_remove_file(&net_dev->dev.kobj,
+			  &dev_attr_gvm_vlan_routing.attr);
+
+	return 0;
+}
+
+static int ethqos_create_sysfs(struct qcom_ethqos *ethqos)
+{
+	int ret;
+	struct net_device *net_dev;
+
+	if (!ethqos) {
+		pr_err("ethqos is NULL\n");
+		return -EINVAL;
+	}
+
+	net_dev = platform_get_drvdata(ethqos->pdev);
+	if (!net_dev) {
+		pr_err("netdev is NULL\n");
+		return -EINVAL;
+	}
+
+	ret = sysfs_create_file(&net_dev->dev.kobj,
+				&dev_attr_gvm_queue_mapping.attr);
+	if (ret) {
+		pr_err("unable to create passthrough_en sysfs node\n");
+		goto fail;
+	}
+
+	ret = sysfs_create_file(&net_dev->dev.kobj,
+				&dev_attr_gvm_vlan_routing.attr);
+	if (ret) {
+		pr_err("unable to create cv2x_priority sysfs node\n");
+		goto fail;
+	}
+
+	return ret;
+
+fail:
+	ethqos_remove_sysfs(ethqos);
+
+	return ret;
+}
+
 static int qcom_ethqos_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
@@ -812,7 +1022,11 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
 		plat_dat->serdes_powerdown  = qcom_ethqos_serdes_powerdown;
 	}
 
-	return devm_stmmac_pltfr_probe(pdev, plat_dat, &stmmac_res);
+	ret = devm_stmmac_pltfr_probe(pdev, plat_dat, &stmmac_res);
+	if (ret)
+		return ret;
+
+	return ethqos_create_sysfs(ethqos);
 }
 
 static const struct of_device_id qcom_ethqos_match[] = {
-- 
2.17.1



From maz at kernel.org  Mon Dec  4 00:52:53 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 08:52:53 +0000
Subject: [RFC PATCH] KVM: arm/arm64: GICv4: Support shared VLPI
In-Reply-To: <CACGkMEt5sapZjpyBSM5oX_=k1AcefEe5D4wtX=HqtHy4AD3j_g@mail.gmail.com>
References: <20231102143507.840-1-jiangkunkun@huawei.com>
	<87msvt6cc7.wl-maz@kernel.org>
	<1fb8353e-e9c4-2570-c2ca-ec537c18ac4d@huawei.com>
	<86edh228xx.wl-maz@kernel.org>
	<952bd5dc-dd20-acc3-d77e-c9b14e5728d3@huawei.com>
	<87fs0k94og.wl-maz@kernel.org>
	<CACGkMEt5sapZjpyBSM5oX_=k1AcefEe5D4wtX=HqtHy4AD3j_g@mail.gmail.com>
Message-ID: <86sf4ibb8a.wl-maz@kernel.org>

On Mon, 04 Dec 2023 08:39:00 +0000,
Jason Wang <jasowang at redhat.com> wrote:
> 
> > Honestly, the virtio driver is broken (irrespective of the
> > architecture), and incompatible with the GIC architecture.
> 
> No matter how the driver is written, the host/KVM should be able to
> survive from that.

The host is perfectly fine, thanks for asking. The guest, however, is
in a bad shape.

	M.

-- 
Without deviation from the norm, progress is not possible.


From maz at kernel.org  Mon Dec  4 01:00:21 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 09:00:21 +0000
Subject: [RFC PATCH] KVM: arm/arm64: GICv4: Support shared VLPI
In-Reply-To: <CACGkMEub4f0FWsrJzSK4e+9cC6LUNFm3vAcfSkpsp6pD=WM5qA@mail.gmail.com>
References: <20231102143507.840-1-jiangkunkun@huawei.com>
	<87msvt6cc7.wl-maz@kernel.org>
	<1fb8353e-e9c4-2570-c2ca-ec537c18ac4d@huawei.com>
	<86edh228xx.wl-maz@kernel.org>
	<952bd5dc-dd20-acc3-d77e-c9b14e5728d3@huawei.com>
	<87fs0k94og.wl-maz@kernel.org>
	<CACGkMEt5sapZjpyBSM5oX_=k1AcefEe5D4wtX=HqtHy4AD3j_g@mail.gmail.com>
	<CACGkMEub4f0FWsrJzSK4e+9cC6LUNFm3vAcfSkpsp6pD=WM5qA@mail.gmail.com>
Message-ID: <86r0k2bavu.wl-maz@kernel.org>

On Mon, 04 Dec 2023 08:47:49 +0000,
Jason Wang <jasowang at redhat.com> wrote:
> 
> On Mon, Dec 4, 2023 at 4:39?PM Jason Wang <jasowang at redhat.com> wrote:
> >
> > On Sat, Dec 2, 2023 at 8:20?PM Marc Zyngier <maz at kernel.org> wrote:
> > >
> > > Hi Kunkun,
> > >
> > > On Wed, 08 Nov 2023 09:45:51 +0000,
> > > Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> > > >
> > > > Hi Marc,
> > > >
> > > > On 2023/11/6 23:33, Marc Zyngier wrote:
> > > > > On Mon, 06 Nov 2023 14:59:01 +0000,
> > > > > Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> > > > >> The virtio-pci driver write entry1-6
> > > > >> massage.data in the msix-table and trap to QEMU for processing. The
> > > > >> massage.data is as follow:
> > > > >>> entry-0 0
> > > > >>> entry-1 1
> > > > >>> entry-2 1
> > > > >>> entry-3 1
> > > > >>> entry-4 1
> > > > >>> entry-5 1
> > > > >>> entry-6 1
> >
> > It looks like a bug from the driver. It should only use vector 0 and 1
> > in this case.
> >
> > Could you please check the queue_msix_vector for each queue in this case?
> 
> Or did you actually mean queue_msix_vector here? I'm not familiar with
> ARM but 0 doesn't seem to be a good message.data anyhow.

Why? What's special about 0? 0 is a perfectly fine value.

	M.

-- 
Without deviation from the norm, progress is not possible.


From krzysztof.kozlowski at linaro.org  Mon Dec  4 01:06:19 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 10:06:19 +0100
Subject: [PATCH v5 0/2] Add Facebook Minerva Harma (AST2600) BMC
In-Reply-To: <3ff5dcd7-69a3-4098-92c6-ed1e8f0bd8f9@gmail.com>
References: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
 <fddcbad4-5368-4c2a-ba87-f4c4326a8385@linaro.org>
 <3ff5dcd7-69a3-4098-92c6-ed1e8f0bd8f9@gmail.com>
Message-ID: <f2519d16-1b34-4d77-be69-cf80fa3415a1@linaro.org>

On 04/12/2023 09:46, PeterYin wrote:
> 
> Krzysztof Kozlowski ? 12/4/23 16:20 ??:
>> On 04/12/2023 09:10, Peter Yin wrote:
>>> Summary:
>>> Add linux device tree entry related to Minerva Harma
>>> specific devices connected to BMC SoC.
>>>
>>> v4:https://lore.kernel.org/all/20231204054131.1845775-3-peter.yin at quantatw.com/
>>> v3:https://lore.kernel.org/all/20231123050415.3441429-3-peteryin.openbmc at gmail.com/
>>> v2:https://lore.kernel.org/all/cdbc75b9-3be1-4017-9bee-c8f161b6843c at linaro.org/
>>> v1:https://lore.kernel.org/all/20231024082404.735843-3-peteryin.openbmc at gmail.com/
>>>
>>> Change log
>>> v4 -> v5
>>>    - Rename document and file from minerva-harma to harma.
>>
>> You must explain that you dropped people's review for some reason.
>>
>> Best regards,
>> Krzysztof
>>
> Due to changes in the project name and content, please assist in 
> reviewing it.

When dropping people's tag, the patch changelog (---) should say that
you dropped people's tag.

Best regards,
Krzysztof



From geert at linux-m68k.org  Mon Dec  4 01:00:03 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 4 Dec 2023 10:00:03 +0100
Subject: [PATCH 10/14] arm64: renesas: r9a08g045: Add Ethernet nodes
In-Reply-To: <b3701927-e41a-44d8-8f91-da245b76f532@tuxon.dev>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-11-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdW9Unpw7NQOGWd4SeFV8XgvRYTKTXnt9Tsagb3Q3U9tNA@mail.gmail.com>
 <96dd3f54-9560-4587-b4e8-bf75422ff5ef@tuxon.dev> <CAMuHMdWGbEhBdzK4Swu4uX05vX7H2Ow4uE1C=JVNOrdcbZYL=A@mail.gmail.com>
 <b3701927-e41a-44d8-8f91-da245b76f532@tuxon.dev>
Message-ID: <CAMuHMdVmD7-AUn91SaOq1iOMkcGhi0WNvx8bCX3oD+xa-Bt98g@mail.gmail.com>

Hi Claudiu,

On Mon, Dec 4, 2023 at 9:38?AM claudiu beznea <claudiu.beznea at tuxon.dev> wrote:
> On 04.12.2023 10:02, Geert Uytterhoeven wrote:
> > On Mon, Dec 4, 2023 at 8:41?AM claudiu beznea <claudiu.beznea at tuxon.dev> wrote:
> >> On 01.12.2023 19:35, Geert Uytterhoeven wrote:
> >>> On Mon, Nov 20, 2023 at 8:01?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> >>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>>>
> >>>> Add Ethernet nodes available on RZ/G3S (R9A08G045).
> >>>>
> >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>>
> >>> Thanks for your patch!
> >>>
> >>>> --- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
> >>>> +++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
> >>>> @@ -149,6 +149,38 @@ sdhi2: mmc at 11c20000 {
> >>>>                         status = "disabled";
> >>>>                 };
> >>>>
> >>>> +               eth0: ethernet at 11c30000 {
> >>>> +                       compatible = "renesas,r9a08g045-gbeth", "renesas,rzg2l-gbeth";
> >>>> +                       reg = <0 0x11c30000 0 0x10000>;
> >>>> +                       interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
> >>>> +                                    <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> >>>> +                                    <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
> >>>> +                       interrupt-names = "mux", "fil", "arp_ns";
> >>>> +                       clocks = <&cpg CPG_MOD R9A08G045_ETH0_CLK_AXI>,
> >>>> +                                <&cpg CPG_MOD R9A08G045_ETH0_CLK_CHI>,
> >>>> +                                <&cpg CPG_MOD R9A08G045_ETH0_REFCLK>;
> >>>> +                       clock-names = "axi", "chi", "refclk";
> >>>> +                       resets = <&cpg R9A08G045_ETH0_RST_HW_N>;
> >>>> +                       power-domains = <&cpg>;
> >>>
> >>> Perhaps add a default phy mode, like on other SoCs?
> >>>
> >>>     phy-mode = "rgmii"';
> >>
> >> I skipped this (even it was available on the other SoCs) as I consider the
> >> phy-mode is board specific.
> >
> > IC.  Still, it's good to have some consistency across boards.
> >
> >>> Also missing:
> >>>
> >>>     #address-cells = <1>;
> >>>     #size-cells = <0>;
> >>
> >> Same for these.
> >
> > These are required, and always have the same values, so it makes more
> > sense to have them in the SoC .dtsi file, once.
>
> I remember I had a compilation warning with an Ethernet controller
> configured with fixed-link having #address-cells, #size-cells. With
> fixed-link these were not needed.

I think EtherAVB always use MDIO for management, so fixed-link is
not applicable.

> Anyway... I'll keep all in dtsi if you prefer it this way.

Yes please, thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From jasowang at redhat.com  Mon Dec  4 01:06:56 2023
From: jasowang at redhat.com (Jason Wang)
Date: Mon, 4 Dec 2023 17:06:56 +0800
Subject: [RFC PATCH] KVM: arm/arm64: GICv4: Support shared VLPI
In-Reply-To: <86r0k2bavu.wl-maz@kernel.org>
References: <20231102143507.840-1-jiangkunkun@huawei.com> <87msvt6cc7.wl-maz@kernel.org>
 <1fb8353e-e9c4-2570-c2ca-ec537c18ac4d@huawei.com> <86edh228xx.wl-maz@kernel.org>
 <952bd5dc-dd20-acc3-d77e-c9b14e5728d3@huawei.com> <87fs0k94og.wl-maz@kernel.org>
 <CACGkMEt5sapZjpyBSM5oX_=k1AcefEe5D4wtX=HqtHy4AD3j_g@mail.gmail.com>
 <CACGkMEub4f0FWsrJzSK4e+9cC6LUNFm3vAcfSkpsp6pD=WM5qA@mail.gmail.com> <86r0k2bavu.wl-maz@kernel.org>
Message-ID: <CACGkMEvLpHm+vEB80mc0QdzJkFK5bAt-gH72ypV-oOb7oJvB+A@mail.gmail.com>

On Mon, Dec 4, 2023 at 5:00?PM Marc Zyngier <maz at kernel.org> wrote:
>
> On Mon, 04 Dec 2023 08:47:49 +0000,
> Jason Wang <jasowang at redhat.com> wrote:
> >
> > On Mon, Dec 4, 2023 at 4:39?PM Jason Wang <jasowang at redhat.com> wrote:
> > >
> > > On Sat, Dec 2, 2023 at 8:20?PM Marc Zyngier <maz at kernel.org> wrote:
> > > >
> > > > Hi Kunkun,
> > > >
> > > > On Wed, 08 Nov 2023 09:45:51 +0000,
> > > > Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> > > > >
> > > > > Hi Marc,
> > > > >
> > > > > On 2023/11/6 23:33, Marc Zyngier wrote:
> > > > > > On Mon, 06 Nov 2023 14:59:01 +0000,
> > > > > > Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> > > > > >> The virtio-pci driver write entry1-6
> > > > > >> massage.data in the msix-table and trap to QEMU for processing. The
> > > > > >> massage.data is as follow:
> > > > > >>> entry-0 0
> > > > > >>> entry-1 1
> > > > > >>> entry-2 1
> > > > > >>> entry-3 1
> > > > > >>> entry-4 1
> > > > > >>> entry-5 1
> > > > > >>> entry-6 1
> > >
> > > It looks like a bug from the driver. It should only use vector 0 and 1
> > > in this case.
> > >
> > > Could you please check the queue_msix_vector for each queue in this case?
> >
> > Or did you actually mean queue_msix_vector here? I'm not familiar with
> > ARM but 0 doesn't seem to be a good message.data anyhow.
>
> Why? What's special about 0? 0 is a perfectly fine value.

Ok, looks like I mis-read it as a message.addr. So it's fine.

Thanks

>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.
>



From tzimmermann at suse.de  Mon Dec  4 01:07:49 2023
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Mon,  4 Dec 2023 10:07:49 +0100
Subject: [PATCH v2 4/8] drm/shmobile: Do not include <drm/drm_plane_helper.h>
In-Reply-To: <20231204090852.1650-1-tzimmermann@suse.de>
References: <20231204090852.1650-1-tzimmermann@suse.de>
Message-ID: <20231204090852.1650-5-tzimmermann@suse.de>

Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c b/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
index 8f9a728affde8..07ad17d24294d 100644
--- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
+++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
@@ -14,7 +14,6 @@
 #include <drm/drm_fourcc.h>
 #include <drm/drm_framebuffer.h>
 #include <drm/drm_gem_dma_helper.h>
-#include <drm/drm_plane_helper.h>
 
 #include "shmob_drm_drv.h"
 #include "shmob_drm_kms.h"
-- 
2.43.0



From tzimmermann at suse.de  Mon Dec  4 01:07:45 2023
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Mon,  4 Dec 2023 10:07:45 +0100
Subject: [PATCH v2 0/8] drm/plane-helpers: Minor clean ups
Message-ID: <20231204090852.1650-1-tzimmermann@suse.de>

Move drm_plane_helper_atomic_check() into udl, which is the only
driver using it. Remove several unnecessary include statements for
<drm/drm_plane_helper.h>.

v2:
	* fix documentation (Sui)

Thomas Zimmermann (8):
  drm/plane-helper: Move drm_plane_helper_atomic_check() into udl
  drm/amdgpu: Do not include <drm/drm_plane_helper.h>
  drm/loongson: Do not include <drm/drm_plane_helper.h>
  drm/shmobile: Do not include <drm/drm_plane_helper.h>
  drm/solomon: Do not include <drm/drm_plane_helper.h>
  drm/ofdrm: Do not include <drm/drm_plane_helper.h>
  drm/simpledrm: Do not include <drm/drm_plane_helper.h>
  drm/xlnx: Do not include <drm/drm_plane_helper.h>

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  1 -
 drivers/gpu/drm/drm_crtc_helper.c             |  7 ++--
 drivers/gpu/drm/drm_plane_helper.c            | 32 -------------------
 drivers/gpu/drm/loongson/lsdc_plane.c         |  1 -
 .../drm/renesas/shmobile/shmob_drm_plane.c    |  1 -
 drivers/gpu/drm/solomon/ssd130x.h             |  1 -
 drivers/gpu/drm/tiny/ofdrm.c                  |  1 -
 drivers/gpu/drm/tiny/simpledrm.c              |  1 -
 drivers/gpu/drm/udl/udl_modeset.c             | 19 +++++++++--
 drivers/gpu/drm/xlnx/zynqmp_kms.c             |  1 -
 include/drm/drm_plane_helper.h                |  2 --
 11 files changed, 19 insertions(+), 48 deletions(-)

-- 
2.43.0



From tzimmermann at suse.de  Mon Dec  4 01:07:51 2023
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Mon,  4 Dec 2023 10:07:51 +0100
Subject: [PATCH v2 6/8] drm/ofdrm: Do not include <drm/drm_plane_helper.h>
In-Reply-To: <20231204090852.1650-1-tzimmermann@suse.de>
References: <20231204090852.1650-1-tzimmermann@suse.de>
Message-ID: <20231204090852.1650-7-tzimmermann@suse.de>

Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
Reviewed-by: Sui Jingfeng <suijingfeng at loongson.cn>
---
 drivers/gpu/drm/tiny/ofdrm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
index 05a72473cfc65..ab89b7fc7bf61 100644
--- a/drivers/gpu/drm/tiny/ofdrm.c
+++ b/drivers/gpu/drm/tiny/ofdrm.c
@@ -19,7 +19,6 @@
 #include <drm/drm_gem_shmem_helper.h>
 #include <drm/drm_managed.h>
 #include <drm/drm_modeset_helper_vtables.h>
-#include <drm/drm_plane_helper.h>
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_simple_kms_helper.h>
 
-- 
2.43.0



From tzimmermann at suse.de  Mon Dec  4 01:07:48 2023
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Mon,  4 Dec 2023 10:07:48 +0100
Subject: [PATCH v2 3/8] drm/loongson: Do not include <drm/drm_plane_helper.h>
In-Reply-To: <20231204090852.1650-1-tzimmermann@suse.de>
References: <20231204090852.1650-1-tzimmermann@suse.de>
Message-ID: <20231204090852.1650-4-tzimmermann@suse.de>

Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
Reviewed-by: Sui Jingfeng <suijingfeng at loongson.cn>
Tested-by: Sui Jingfeng <suijingfeng at loongson.cn>
---
 drivers/gpu/drm/loongson/lsdc_plane.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/loongson/lsdc_plane.c b/drivers/gpu/drm/loongson/lsdc_plane.c
index 0d50946332229..d227a2c1dcf16 100644
--- a/drivers/gpu/drm/loongson/lsdc_plane.c
+++ b/drivers/gpu/drm/loongson/lsdc_plane.c
@@ -9,7 +9,6 @@
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_framebuffer.h>
 #include <drm/drm_gem_atomic_helper.h>
-#include <drm/drm_plane_helper.h>
 
 #include "lsdc_drv.h"
 #include "lsdc_regs.h"
-- 
2.43.0



From tzimmermann at suse.de  Mon Dec  4 01:07:53 2023
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Mon,  4 Dec 2023 10:07:53 +0100
Subject: [PATCH v2 8/8] drm/xlnx: Do not include <drm/drm_plane_helper.h>
In-Reply-To: <20231204090852.1650-1-tzimmermann@suse.de>
References: <20231204090852.1650-1-tzimmermann@suse.de>
Message-ID: <20231204090852.1650-9-tzimmermann@suse.de>

Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 drivers/gpu/drm/xlnx/zynqmp_kms.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index a7f8611be6f42..db3bb4afbfc46 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -27,7 +27,6 @@
 #include <drm/drm_managed.h>
 #include <drm/drm_mode_config.h>
 #include <drm/drm_plane.h>
-#include <drm/drm_plane_helper.h>
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_simple_kms_helper.h>
 #include <drm/drm_vblank.h>
-- 
2.43.0



From tzimmermann at suse.de  Mon Dec  4 01:07:46 2023
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Mon,  4 Dec 2023 10:07:46 +0100
Subject: [PATCH v2 1/8] drm/plane-helper: Move drm_plane_helper_atomic_check() into udl
In-Reply-To: <20231204090852.1650-1-tzimmermann@suse.de>
References: <20231204090852.1650-1-tzimmermann@suse.de>
Message-ID: <20231204090852.1650-2-tzimmermann@suse.de>

The udl driver is the only caller of drm_plane_helper_atomic_check().
Move the function into the driver. No functional changes.

v2:
	* fix documenation (Sui)

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
Acked-by: Sui Jingfeng <suijingfeng at loongson.cn>
---
 drivers/gpu/drm/drm_crtc_helper.c  |  7 ++-----
 drivers/gpu/drm/drm_plane_helper.c | 32 ------------------------------
 drivers/gpu/drm/udl/udl_modeset.c  | 19 ++++++++++++++++--
 include/drm/drm_plane_helper.h     |  2 --
 4 files changed, 19 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index a209659a996c7..2dafc39a27cb9 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -439,11 +439,8 @@ EXPORT_SYMBOL(drm_crtc_helper_set_mode);
  * @state: atomic state object
  *
  * Provides a default CRTC-state check handler for CRTCs that only have
- * one primary plane attached to it.
- *
- * This is often the case for the CRTC of simple framebuffers. See also
- * drm_plane_helper_atomic_check() for the respective plane-state check
- * helper function.
+ * one primary plane attached to it. This is often the case for the CRTC
+ * of simple framebuffers.
  *
  * RETURNS:
  * Zero on success, or an errno code otherwise.
diff --git a/drivers/gpu/drm/drm_plane_helper.c b/drivers/gpu/drm/drm_plane_helper.c
index 5e95089676ff8..7982be4b0306d 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -279,35 +279,3 @@ void drm_plane_helper_destroy(struct drm_plane *plane)
 	kfree(plane);
 }
 EXPORT_SYMBOL(drm_plane_helper_destroy);
-
-/**
- * drm_plane_helper_atomic_check() - Helper to check plane atomic-state
- * @plane: plane to check
- * @state: atomic state object
- *
- * Provides a default plane-state check handler for planes whose atomic-state
- * scale and positioning are not expected to change since the plane is always
- * a fullscreen scanout buffer.
- *
- * This is often the case for the primary plane of simple framebuffers. See
- * also drm_crtc_helper_atomic_check() for the respective CRTC-state check
- * helper function.
- *
- * RETURNS:
- * Zero on success, or an errno code otherwise.
- */
-int drm_plane_helper_atomic_check(struct drm_plane *plane, struct drm_atomic_state *state)
-{
-	struct drm_plane_state *new_plane_state = drm_atomic_get_new_plane_state(state, plane);
-	struct drm_crtc *new_crtc = new_plane_state->crtc;
-	struct drm_crtc_state *new_crtc_state = NULL;
-
-	if (new_crtc)
-		new_crtc_state = drm_atomic_get_new_crtc_state(state, new_crtc);
-
-	return drm_atomic_helper_check_plane_state(new_plane_state, new_crtc_state,
-						   DRM_PLANE_NO_SCALING,
-						   DRM_PLANE_NO_SCALING,
-						   false, false);
-}
-EXPORT_SYMBOL(drm_plane_helper_atomic_check);
diff --git a/drivers/gpu/drm/udl/udl_modeset.c b/drivers/gpu/drm/udl/udl_modeset.c
index 40876bcdd79a4..7702359c90c22 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -21,7 +21,6 @@
 #include <drm/drm_gem_framebuffer_helper.h>
 #include <drm/drm_gem_shmem_helper.h>
 #include <drm/drm_modeset_helper_vtables.h>
-#include <drm/drm_plane_helper.h>
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_vblank.h>
 
@@ -261,6 +260,22 @@ static const uint64_t udl_primary_plane_fmtmods[] = {
 	DRM_FORMAT_MOD_INVALID
 };
 
+static int udl_primary_plane_helper_atomic_check(struct drm_plane *plane,
+						 struct drm_atomic_state *state)
+{
+	struct drm_plane_state *new_plane_state = drm_atomic_get_new_plane_state(state, plane);
+	struct drm_crtc *new_crtc = new_plane_state->crtc;
+	struct drm_crtc_state *new_crtc_state = NULL;
+
+	if (new_crtc)
+		new_crtc_state = drm_atomic_get_new_crtc_state(state, new_crtc);
+
+	return drm_atomic_helper_check_plane_state(new_plane_state, new_crtc_state,
+						   DRM_PLANE_NO_SCALING,
+						   DRM_PLANE_NO_SCALING,
+						   false, false);
+}
+
 static void udl_primary_plane_helper_atomic_update(struct drm_plane *plane,
 						   struct drm_atomic_state *state)
 {
@@ -296,7 +311,7 @@ static void udl_primary_plane_helper_atomic_update(struct drm_plane *plane,
 
 static const struct drm_plane_helper_funcs udl_primary_plane_helper_funcs = {
 	DRM_GEM_SHADOW_PLANE_HELPER_FUNCS,
-	.atomic_check = drm_plane_helper_atomic_check,
+	.atomic_check = udl_primary_plane_helper_atomic_check,
 	.atomic_update = udl_primary_plane_helper_atomic_update,
 };
 
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index 3a574e8cd22f4..75f9c4830564a 100644
--- a/include/drm/drm_plane_helper.h
+++ b/include/drm/drm_plane_helper.h
@@ -26,7 +26,6 @@
 
 #include <linux/types.h>
 
-struct drm_atomic_state;
 struct drm_crtc;
 struct drm_framebuffer;
 struct drm_modeset_acquire_ctx;
@@ -42,7 +41,6 @@ int drm_plane_helper_update_primary(struct drm_plane *plane, struct drm_crtc *cr
 int drm_plane_helper_disable_primary(struct drm_plane *plane,
 				     struct drm_modeset_acquire_ctx *ctx);
 void drm_plane_helper_destroy(struct drm_plane *plane);
-int drm_plane_helper_atomic_check(struct drm_plane *plane, struct drm_atomic_state *state);
 
 /**
  * DRM_PLANE_NON_ATOMIC_FUNCS - Default plane functions for non-atomic drivers
-- 
2.43.0



From tzimmermann at suse.de  Mon Dec  4 01:07:52 2023
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Mon,  4 Dec 2023 10:07:52 +0100
Subject: [PATCH v2 7/8] drm/simpledrm: Do not include <drm/drm_plane_helper.h>
In-Reply-To: <20231204090852.1650-1-tzimmermann@suse.de>
References: <20231204090852.1650-1-tzimmermann@suse.de>
Message-ID: <20231204090852.1650-8-tzimmermann@suse.de>

Remove unnecessary include statements for <drm/drm_plane_helper.h>.
The file contains helpers for non-atomic code and should not be
required by most drivers. No functional changes.

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
Reviewed-by: Sui Jingfeng <suijingfeng at loongson.cn>
---
 drivers/gpu/drm/tiny/simpledrm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 34bbbd7b53dd9..7ce1c46176750 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -25,7 +25,6 @@
 #include <drm/drm_gem_shmem_helper.h>
 #include <drm/drm_managed.h>
 #include <drm/drm_modeset_helper_vtables.h>
-#include <drm/drm_plane_helper.h>
 #include <drm/drm_probe_helper.h>
 
 #define DRIVER_NAME	"simpledrm"
-- 
2.43.0



From peteryin.openbmc at gmail.com  Mon Dec  4 01:14:45 2023
From: peteryin.openbmc at gmail.com (PeterYin)
Date: Mon, 4 Dec 2023 17:14:45 +0800
Subject: [PATCH v5 0/2] Add Facebook Minerva Harma (AST2600) BMC
In-Reply-To: <f2519d16-1b34-4d77-be69-cf80fa3415a1@linaro.org>
References: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
 <fddcbad4-5368-4c2a-ba87-f4c4326a8385@linaro.org>
 <3ff5dcd7-69a3-4098-92c6-ed1e8f0bd8f9@gmail.com>
 <f2519d16-1b34-4d77-be69-cf80fa3415a1@linaro.org>
Message-ID: <ad6fb2a1-c376-4e03-8b18-12b228799bcc@gmail.com>



Krzysztof Kozlowski ? 12/4/23 17:06 ??:
> On 04/12/2023 09:46, PeterYin wrote:
>>
>> Krzysztof Kozlowski ? 12/4/23 16:20 ??:
>>> On 04/12/2023 09:10, Peter Yin wrote:
>>>> Summary:
>>>> Add linux device tree entry related to Minerva Harma
>>>> specific devices connected to BMC SoC.
>>>>
>>>> v4:https://lore.kernel.org/all/20231204054131.1845775-3-peter.yin at quantatw.com/
>>>> v3:https://lore.kernel.org/all/20231123050415.3441429-3-peteryin.openbmc at gmail.com/
>>>> v2:https://lore.kernel.org/all/cdbc75b9-3be1-4017-9bee-c8f161b6843c at linaro.org/
>>>> v1:https://lore.kernel.org/all/20231024082404.735843-3-peteryin.openbmc at gmail.com/
>>>>
>>>> Change log
>>>> v4 -> v5
>>>>     - Rename document and file from minerva-harma to harma.
>>>
>>> You must explain that you dropped people's review for some reason.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>> Due to changes in the project name and content, please assist in
>> reviewing it.
> 
> When dropping people's tag, the patch changelog (---) should say that
> you dropped people's tag.
> 
> Best regards,
> Krzysztof
> 
Thank you for your explanation. I will pay attention to it next time.

Thanks,
Peter.


From peteryin.openbmc at gmail.com  Mon Dec  4 01:16:58 2023
From: peteryin.openbmc at gmail.com (PeterYin)
Date: Mon, 4 Dec 2023 17:16:58 +0800
Subject: [PATCH v5 0/2] Add Facebook Minerva Harma (AST2600) BMC
In-Reply-To: <f2519d16-1b34-4d77-be69-cf80fa3415a1@linaro.org>
References: <20231204081029.2272626-1-peteryin.openbmc@gmail.com>
 <fddcbad4-5368-4c2a-ba87-f4c4326a8385@linaro.org>
 <3ff5dcd7-69a3-4098-92c6-ed1e8f0bd8f9@gmail.com>
 <f2519d16-1b34-4d77-be69-cf80fa3415a1@linaro.org>
Message-ID: <bf3f2195-2d26-4817-ac5d-1608722c23f6@gmail.com>

Krzysztof Kozlowski ? 12/4/23 17:06 ??:
> On 04/12/2023 09:46, PeterYin wrote:
>>
>> Krzysztof Kozlowski ? 12/4/23 16:20 ??:
>>> On 04/12/2023 09:10, Peter Yin wrote:
>>>> Summary:
>>>> Add linux device tree entry related to Minerva Harma
>>>> specific devices connected to BMC SoC.
>>>>
>>>> v4:https://lore.kernel.org/all/20231204054131.1845775-3-peter.yin at quantatw.com/
>>>> v3:https://lore.kernel.org/all/20231123050415.3441429-3-peteryin.openbmc at gmail.com/
>>>> v2:https://lore.kernel.org/all/cdbc75b9-3be1-4017-9bee-c8f161b6843c at linaro.org/
>>>> v1:https://lore.kernel.org/all/20231024082404.735843-3-peteryin.openbmc at gmail.com/
>>>>
>>>> Change log
>>>> v4 -> v5
>>>>     - Rename document and file from minerva-harma to harma.
>>>
>>> You must explain that you dropped people's review for some reason.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>> Due to changes in the project name and content, please assist in
>> reviewing it.
> 
> When dropping people's tag, the patch changelog (---) should say that
> you dropped people's tag.
> 
> Best regards,
> Krzysztof
> 
Thank you for your explanation. I will pay attention to it next time.

Thanks,
Peter.


From maz at kernel.org  Mon Dec  4 01:29:20 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 09:29:20 +0000
Subject: [PATCH v3 2/6] arm64: KVM: Move SPE and trace registers to the sysreg array
In-Reply-To: <20231019165510.1966367-3-james.clark@arm.com>
References: <20231019165510.1966367-1-james.clark@arm.com>
	<20231019165510.1966367-3-james.clark@arm.com>
Message-ID: <86plzmb9jj.wl-maz@kernel.org>

On Thu, 19 Oct 2023 17:55:00 +0100,
James Clark <james.clark at arm.com> wrote:
> 
> pmscr_el1 and trfcr_el1 are currently special cased in the
> host_debug_state struct, but they're just registers after all so give
> them entries in the sysreg array and refer to them through the host
> context.
> 
> Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
> Signed-off-by: James Clark <james.clark at arm.com>
> ---
>  arch/arm64/include/asm/kvm_host.h  |  6 ++--
>  arch/arm64/include/asm/kvm_hyp.h   |  4 +--
>  arch/arm64/kvm/hyp/nvhe/debug-sr.c | 44 +++++++++++++++---------------
>  arch/arm64/kvm/hyp/nvhe/switch.c   |  4 +--
>  4 files changed, 28 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 4a966c0d7373..7c82927ddaf2 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -437,6 +437,8 @@ enum vcpu_sysreg {
>  	CNTHP_CVAL_EL2,
>  	CNTHV_CTL_EL2,
>  	CNTHV_CVAL_EL2,
> +	PMSCR_EL1,	/* Statistical profiling extension */
> +	TRFCR_EL1,	/* Self-hosted trace filters */

Why this move? Are you also adding guest support for SPE?

Until you do, I don't see the need to pollute the guest's sysreg
namespace.

	M.

-- 
Without deviation from the norm, progress is not possible.


From quentin.schulz at theobroma-systems.com  Mon Dec  4 01:32:03 2023
From: quentin.schulz at theobroma-systems.com (Quentin Schulz)
Date: Mon, 4 Dec 2023 10:32:03 +0100
Subject: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
In-Reply-To: <3898725.Zkmt1EvEu4@diego>
References: <20231201191228.343230-1-heiko@sntech.de>
 <4075500.2IRrRt1zHL@diego> <ZWsaJ-3bWZbjtFiz@livingston.pivistrello.it>
 <3898725.Zkmt1EvEu4@diego>
Message-ID: <1219e055-2625-4c22-96f0-ed3ac7e40913@theobroma-systems.com>

Hi all,

On 12/2/23 13:12, Heiko St?bner wrote:
> Am Samstag, 2. Dezember 2023, 12:51:03 CET schrieb Francesco Dolcini:
>> On Fri, Dec 01, 2023 at 09:56:27PM +0100, Heiko St?bner wrote:
>>> Hi,
>>>
>>> Am Freitag, 1. Dezember 2023, 21:09:29 CET schrieb Francesco Dolcini:
>>>> On Fri, Dec 01, 2023 at 11:57:53AM -0800, Florian Fainelli wrote:
>>>>> +Francesco,
>>>>>
>>>>> On 12/1/23 11:12, Heiko Stuebner wrote:
>>>>>> From: Heiko Stuebner <heiko.stuebner at cherry.de>
>>>>>>
>>>>>> Boards using socs like the rk3588 can use up to 10 uarts, so the default
>>>>>> of 4 is way too low. Therefore increase the maximum number to 10.
>>>> Do you have an actual need of 10, e.g. an existing board with 10 uarts
>>>> enabled supported by the mainline kernel? Just thinking at the last arm64 SoC I
>>>> am working with it should be 12 if we use this as a metric.
>>>
>>> The rk3588 can do 10 (0-9), the board I'm working on is using up to uart7 (aka 8 uarts).
>>> Reasoning below in the 3rd paragraph.
>>>
>>>
>>>>>> SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
>>>>>> data structures to prepare before registering them. This option can stay
>>>>>> at its default value of 4 since for one it can be changed via a boot
>>>>>> parameter 8250.nr_uarts but also since
>>>>>> commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")
>>>>>>
>>>>>> the kernel can register uarts dynamically that are above the
>>>>>> SERIAL_8250_RUNTIME_UARTS threshold.
>>>>>>
>>>>>> Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
>>>>>
>>>>> There is a competing patch set from Francesco being submitted as well:
>>>>> https://lore.kernel.org/all/20231201171544.1901-1-francesco at dolcini.it/
>>>>>
>>>>> looks like some coordination is necessary.
>>>
>>>
>>> So TL;DR:
>>> I could live with the 8 from your original patch, but I guess would prefer
>>> going with a safer value, so the 10 or your 12 from above.
>>>
>>> Because I guess if a controller is present, someone will use it
>>> eventually ;-).
>>
>> There was an explicit push back on this approach from Arnd, see
>> https://lore.kernel.org/all/CAK8P3a2VSBvOn1o+q1PYZaQ6LS9U4cz+DZGuDbisHkwNs2dAAw at mail.gmail.com/
> 
> aliases really are a matter of difficult discussions ;-)
> I.e. Krzysztof's argument some days ago was
> 
> 	"No, this should be per-board to match board labeling/schematics."
> 
> https://lore.kernel.org/all/813224c2-398d-4c2d-8909-1839ce63be60 at linaro.org/
> 
> And on Rockchip socs everyting from soc manual, board schematics down to
> the description of pin headers use the uart controller number so people will
> expect uart9 to be ttyS9 on the system as well.
> 
> 
>> I would propose that we stay with my current proposal of 8.
> 
> But ok we can go this route, simply as the current board I'm working on
> only use 8, so I can leave that "fight" to someone else ;-)
> 

Actually, UART8 and UART9 (so the 9th and 10th controllers) are exposed 
on the Mezzanine connector and we have a HW design for a daughterboard 
using that already. So we'll eventually support it upstream as well.

So at least 10 is necessary if I understood correctly.

And yes, those are really named after their controller indices on the 
schematics. So we need the value of the symbol to be that high.

Cheers,
Quentin


From ryan.roberts at arm.com  Mon Dec  4 01:39:09 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 4 Dec 2023 09:39:09 +0000
Subject: [PATCH v2 14/14] arm64/mm: Add ptep_get_and_clear_full() to
 optimize process teardown
In-Reply-To: <877cluc1qi.fsf@nvdebian.thelocal>
References: <20231115163018.1303287-1-ryan.roberts@arm.com>
 <20231115163018.1303287-15-ryan.roberts@arm.com>
 <87fs0xxd5g.fsf@nvdebian.thelocal>
 <3b4f6bff-6322-4394-9efb-9c3b9ef52010@arm.com>
 <87y1eovsn5.fsf@nvdebian.thelocal>
 <8fca9ed7-f916-4abe-8284-6e3c9fa33a8c@arm.com>
 <87wmu3pro8.fsf@nvdebian.thelocal>
 <26c78fee-4b7a-4d73-9f8b-2e25bbae20e8@arm.com>
 <87o7fepdun.fsf@nvdebian.thelocal>
 <b4906e1e-8009-4097-8d17-642374a049fe@arm.com>
 <b6d4b33b-6224-444f-9542-d3cb95afd382@arm.com>
 <87leafg768.fsf@nvdebian.thelocal>
 <9631b5bd-1d10-40bf-b4eb-9df33b9a0680@arm.com>
 <877cluc1qi.fsf@nvdebian.thelocal>
Message-ID: <a8468725-3510-4809-b41e-5c550e58d67f@arm.com>

On 03/12/2023 23:20, Alistair Popple wrote:
> 
> Ryan Roberts <ryan.roberts at arm.com> writes:
> 
>> On 30/11/2023 05:07, Alistair Popple wrote:
>>>
>>> Ryan Roberts <ryan.roberts at arm.com> writes:
>>>
>>>>>>> So if we do need to deal with racing HW, I'm pretty sure my v1 implementation is
>>>>>>> buggy because it iterated through the PTEs, getting and accumulating. Then
>>>>>>> iterated again, writing that final set of bits to all the PTEs. And the HW could
>>>>>>> have modified the bits during those loops. I think it would be possible to fix
>>>>>>> the race, but intuition says it would be expensive.
>>>>>>
>>>>>> So the issue as I understand it is subsequent iterations would see a
>>>>>> clean PTE after the first iteration returned a dirty PTE. In
>>>>>> ptep_get_and_clear_full() why couldn't you just copy the dirty/accessed
>>>>>> bit (if set) from the PTE being cleared to an adjacent PTE rather than
>>>>>> all the PTEs?
>>>>>
>>>>> The raciness I'm describing is the race between reading access/dirty from one
>>>>> pte and applying it to another. But yes I like your suggestion. if we do:
>>>>>
>>>>> pte = __ptep_get_and_clear_full(ptep)
>>>>>
>>>>> on the target pte, then we have grabbed access/dirty from it in a race-free
>>>>> manner. we can then loop from current pte up towards the top of the block until
>>>>> we find a valid entry (and I guess wrap at the top to make us robust against
>>>>> future callers clearing an an arbitrary order). Then atomically accumulate the
>>>>> access/dirty bits we have just saved into that new entry. I guess that's just a
>>>>> cmpxchg loop - there are already examples of how to do that correctly when
>>>>> racing the TLB.
>>>>>
>>>>> For most entries, we will just be copying up to the next pte. For the last pte,
>>>>> we would end up reading all ptes and determine we are the last one.
>>>>>
>>>>> What do you think?
>>>>
>>>> OK here is an attempt at something which solves the fragility. I think this is
>>>> now robust and will always return the correct access/dirty state from
>>>> ptep_get_and_clear_full() and ptep_get().
>>>>
>>>> But I'm not sure about performance; each call to ptep_get_and_clear_full() for
>>>> each pte in a contpte block will cause a ptep_get() to gather the access/dirty
>>>> bits from across the contpte block - which requires reading each pte in the
>>>> contpte block. So its O(n^2) in that sense. I'll benchmark it and report back.
>>>>
>>>> Was this the type of thing you were thinking of, Alistair?
>>>
>>> Yes, that is along the lines of what I was thinking. However I have
>>> added a couple of comments inline. 
>>>
>>>> --8<--
>>>>  arch/arm64/include/asm/pgtable.h | 23 ++++++++-
>>>>  arch/arm64/mm/contpte.c          | 81 ++++++++++++++++++++++++++++++++
>>>>  arch/arm64/mm/fault.c            | 38 +++++++++------
>>>>  3 files changed, 125 insertions(+), 17 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>>> index 9bd2f57a9e11..6c295d277784 100644
>>>> --- a/arch/arm64/include/asm/pgtable.h
>>>> +++ b/arch/arm64/include/asm/pgtable.h
>>>> @@ -851,6 +851,7 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
>>>>  	return pte_pmd(pte_modify(pmd_pte(pmd), newprot));
>>>>  }
>>>>
>>>> +extern int __ptep_set_access_flags_notlbi(pte_t *ptep, pte_t entry);
>>>>  extern int __ptep_set_access_flags(struct vm_area_struct *vma,
>>>>  				 unsigned long address, pte_t *ptep,
>>>>  				 pte_t entry, int dirty);
>>>> @@ -1145,6 +1146,8 @@ extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
>>>>  extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
>>>>  extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>>>>  				pte_t *ptep, pte_t pte, unsigned int nr);
>>>> +extern pte_t contpte_ptep_get_and_clear_full(struct mm_struct *mm,
>>>> +				unsigned long addr, pte_t *ptep);
>>>>  extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>>>  				unsigned long addr, pte_t *ptep);
>>>>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>>>> @@ -1270,12 +1273,28 @@ static inline void pte_clear(struct mm_struct *mm,
>>>>  	__pte_clear(mm, addr, ptep);
>>>>  }
>>>>
>>>> +#define __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL
>>>> +static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,
>>>> +				unsigned long addr, pte_t *ptep, int full)
>>>> +{
>>>> +	pte_t orig_pte = __ptep_get(ptep);
>>>> +
>>>> +	if (!pte_valid_cont(orig_pte))
>>>> +		return __ptep_get_and_clear(mm, addr, ptep);
>>>> +
>>>> +	if (!full) {
>>>> +		contpte_try_unfold(mm, addr, ptep, orig_pte);
>>>> +		return __ptep_get_and_clear(mm, addr, ptep);
>>>> +	}
>>>> +
>>>> +	return contpte_ptep_get_and_clear_full(mm, addr, ptep);
>>>> +}
>>>> +
>>>>  #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
>>>>  static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
>>>>  				unsigned long addr, pte_t *ptep)
>>>>  {
>>>> -	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>>>> -	return __ptep_get_and_clear(mm, addr, ptep);
>>>> +	return ptep_get_and_clear_full(mm, addr, ptep, 0);
>>>>  }
>>>>
>>>>  #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
>>>> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
>>>> index 2a57df16bf58..99b211118d93 100644
>>>> --- a/arch/arm64/mm/contpte.c
>>>> +++ b/arch/arm64/mm/contpte.c
>>>> @@ -145,6 +145,14 @@ pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte)
>>>>  	for (i = 0; i < CONT_PTES; i++, ptep++) {
>>>>  		pte = __ptep_get(ptep);
>>>>
>>>> +		/*
>>>> +		 * Deal with the partial contpte_ptep_get_and_clear_full() case,
>>>> +		 * where some of the ptes in the range may be cleared but others
>>>> +		 * are still to do. See contpte_ptep_get_and_clear_full().
>>>> +		 */
>>>> +		if (!pte_valid(pte))
>>>> +			continue;
>>>> +
>>>>  		if (pte_dirty(pte))
>>>>  			orig_pte = pte_mkdirty(orig_pte);
>>>>
>>>> @@ -257,6 +265,79 @@ void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>>>>  }
>>>>  EXPORT_SYMBOL(contpte_set_ptes);
>>>>
>>>> +pte_t contpte_ptep_get_and_clear_full(struct mm_struct *mm,
>>>> +					unsigned long addr, pte_t *ptep)
>>>> +{
>>>> +	/*
>>>> +	 * When doing a full address space teardown, we can avoid unfolding the
>>>> +	 * contiguous range, and therefore avoid the associated tlbi. Instead,
>>>> +	 * just get and clear the pte. The caller is promising to call us for
>>>> +	 * every pte, so every pte in the range will be cleared by the time the
>>>> +	 * final tlbi is issued.
>>>> +	 *
>>>> +	 * This approach requires some complex hoop jumping though, as for the
>>>> +	 * duration between returning from the first call to
>>>> +	 * ptep_get_and_clear_full() and making the final call, the contpte
>>>> +	 * block is in an intermediate state, where some ptes are cleared and
>>>> +	 * others are still set with the PTE_CONT bit. If any other APIs are
>>>> +	 * called for the ptes in the contpte block during that time, we have to
>>>> +	 * be very careful. The core code currently interleaves calls to
>>>> +	 * ptep_get_and_clear_full() with ptep_get() and so ptep_get() must be
>>>> +	 * careful to ignore the cleared entries when accumulating the access
>>>> +	 * and dirty bits - the same goes for ptep_get_lockless(). The only
>>>> +	 * other calls we might resonably expect are to set markers in the
>>>> +	 * previously cleared ptes. (We shouldn't see valid entries being set
>>>> +	 * until after the tlbi, at which point we are no longer in the
>>>> +	 * intermediate state). Since markers are not valid, this is safe;
>>>> +	 * set_ptes() will see the old, invalid entry and will not attempt to
>>>> +	 * unfold. And the new pte is also invalid so it won't attempt to fold.
>>>> +	 * We shouldn't see pte markers being set for the 'full' case anyway
>>>> +	 * since the address space is being torn down.
>>>> +	 *
>>>> +	 * The last remaining issue is returning the access/dirty bits. That
>>>> +	 * info could be present in any of the ptes in the contpte block.
>>>> +	 * ptep_get() will gather those bits from across the contpte block (for
>>>> +	 * the remaining valid entries). So below, if the pte we are clearing
>>>> +	 * has dirty or young set, we need to stash it into a pte that we are
>>>> +	 * yet to clear. This allows future calls to return the correct state
>>>> +	 * even when the info was stored in a different pte. Since the core-mm
>>>> +	 * calls from low to high address, we prefer to stash in the last pte of
>>>> +	 * the contpte block - this means we are not "dragging" the bits up
>>>> +	 * through all ptes and increases the chances that we can exit early
>>>> +	 * because a given pte will have neither dirty or young set.
>>>> +	 */
>>>> +
>>>> +	pte_t orig_pte = __ptep_get_and_clear(mm, addr, ptep);
>>>> +	bool dirty = pte_dirty(orig_pte);
>>>> +	bool young = pte_young(orig_pte);
>>>> +	pte_t *start;
>>>> +
>>>> +	if (!dirty && !young)
>>>> +		return contpte_ptep_get(ptep, orig_pte);
>>>
>>> I don't think we need to do this. If the PTE is !dirty && !young we can
>>> just return it. As you say we have to assume HW can set those flags at
>>> any time anyway so it doesn't get us much. This means in the common case
>>> we should only run through the loop setting the dirty/young flags once
>>> which should alay the performance concerns.
>>
>> I don't follow your logic. This is precisely the problem I was trying to solve
>> vs my original (simple) attempt - we want to always report the correct
>> access/dirty info. If we read one of the PTEs and neither access nor dirty are
>> set, that doesn't mean its old and clean, it just means that that info is
>> definitely not stored in this PTE - we need to check the others. (when the
>> contiguous bit is set, the HW will only update the access/dirty bits for 1 of
>> the PTEs in the contpte block).
> 
> So my concern wasn't about incorrectly returning a !young && !dirty PTE
> when the CONT_PTE block was *previously* clean/old (ie. the first
> ptep_get/ptep_get_and_clear_full returned clean/old) because we have to
> tolerate that anyway due to HW being able to set those bits. Rather my
> concern was ptep_get_and_clear_full() could implicitly clear dirty/young
> bits - ie. ptep_get_and_clear_full() could return a dirty/young PTE but
> the next call would not.
> 
> That's because regardless of what we do here it is just a matter of
> timing if we have to assume other HW threads can set these bits at any
> time. There is nothing stopping HW from doing that just after we read
> them in that loop, so a block can always become dirty/young at any time.
> However it shouldn't become !dirty/!young without explicit SW
> intervention.
> 
> But this is all a bit of a moot point due to the discussion below.
> 
>> Also, IIRC correctly, the core-mm sets access when initially setting up the
>> mapping so its not guarranteed that all but one of the PTEs in the contpte block
>> have (!dirty && !young).
>>
>>>
>>> However I am now wondering if we're doing the wrong thing trying to hide
>>> this down in the arch layer anyway. Perhaps it would be better to deal
>>> with this in the core-mm code after all.
>>>
>>> So how about having ptep_get_and_clear_full() clearing the PTEs for the
>>> entire cont block? We know by definition all PTEs should be pointing to
>>> the same folio anyway, and it seems at least zap_pte_range() would cope
>>> with this just fine because subsequent iterations would just see
>>> pte_none() and continue the loop. I haven't checked the other call sites
>>> though, but in principal I don't see why we couldn't define
>>> ptep_get_and_clear_full() as being something that clears all PTEs
>>> mapping a given folio (although it might need renaming).
>>
>> Ahha! Yes, I've been working on a solution like this since Barry raised it
>> yesterday. I have a working version, that seems to perform well. I wouldn't want
>> to just clear all the PTEs in the block inside ptep_get_and_clear_full() because
>> although it might work today, its fragile in the same way that my v2 version is.
> 
> Yes, agree a new helper would be needed.
> 
>> Instead, I've defined a new helper, clear_ptes(), which takes a starting pte and
>> a number of ptes to clear (like set_ptes()). It returns the PTE read from the
>> *first* slot, but with the access/dirty bits being accumulated from all of the
>> ptes in the requested batch. Then zap_pte_range() is reworked to find
>> appropriate batches (similar to how I've reworked for ptep_set_wrprotects()).
>>
>> I was trying to avoid introducing new helpers, but I think this is the most
>> robust approach, and looks slightly more performant to, on first sight. It also
>> addresses cases where full=0, which Barry says are important for madvise(DONTNEED).
> 
> I strongly agree with this approach now especially if it is equally (or
> more!) performant. I get why you didn't want to intorduce new helpers
> but I think doing so was making things too subtle so would like to see
> this.
> 
>>>
>>> This does assume you don't need to partially unmap a page in
>>> zap_pte_range (ie. end >= folio), but we're already making that
>>> assumption.
>>
>> That's fine for full=1. But we can't make that assumption for full=0. If a VMA
>> gets split for a reason that doesn't require re-setting the PTEs then a contpte
>> block could straddle 2 VMAs. But the solution I describe above is robust to that.
>>
>> I'll finish gathering perf data then post for all 3 approaches; v2 as originally
>> posted, "robust ptep_get_and_clear_full()", and clear_ptes(). Hopefully later today.
> 
> Thanks!

>From the commit log of the new version, which I'll hopefully post later today:

  The following shows the results of running a kernel compilation workload
  and measuring the cost of arm64_sys_exit_group() (which at ~1.5% is a
  very small part of the overall workload).

  Benchmarks were run on Ampere Altra in 2 configs; single numa node and 2
  numa nodes (tlbis are more expensive in 2 node config).

    - baseline: v6.7-rc1 + anonfolio-v7
    - no-opt: contpte series without any attempt to optimize exit()
    - simple-ptep_get_clear_full: simple optimization to exploit full=1.
      ptep_get_clear_full() does not fully conform to its intended semantic
    - robust-ptep_get_clear_full: similar to previous but
      ptep_get_clear_full() fully conforms to its intended semantic
    - clear_ptes: optimization implemented by this patch

  | config                     | numa=1 | numa=2 |
  |----------------------------|--------|--------|
  | baseline                   |     0% |     0% |
  | no-opt                     |   190% |   768% |
  | simple-ptep_get_clear_full |     8% |    29% |
  | robust-ptep_get_clear_full |    21% |    19% |
  | clear_ptes                 |    13% |     9% |

  In all cases, the cost of arm64_sys_exit_group() increases; this is
  anticipated because there is more work to do to tear down the page
  tables. But clear_ptes() gives the smallest increase overall.

Note that "simple-ptep_get_clear_full" is the version I posted with v2.
"robust-ptep_get_clear_full" is the version I tried as part of this
conversation. And "clear_ptes" is the batched version that I think we all now
prefer (and plan to post as part of v3).

Thanks,
Ryan



From javierm at redhat.com  Mon Dec  4 01:42:01 2023
From: javierm at redhat.com (Javier Martinez Canillas)
Date: Mon, 04 Dec 2023 10:42:01 +0100
Subject: [PATCH v2 7/8] drm/simpledrm: Do not include
 <drm/drm_plane_helper.h>
In-Reply-To: <20231204090852.1650-8-tzimmermann@suse.de>
References: <20231204090852.1650-1-tzimmermann@suse.de>
 <20231204090852.1650-8-tzimmermann@suse.de>
Message-ID: <877cluxq1i.fsf@minerva.mail-host-address-is-not-set>

Thomas Zimmermann <tzimmermann at suse.de> writes:

> Remove unnecessary include statements for <drm/drm_plane_helper.h>.
> The file contains helpers for non-atomic code and should not be
> required by most drivers. No functional changes.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
> Reviewed-by: Sui Jingfeng <suijingfeng at loongson.cn>
> ---

Reviewed-by: Javier Martinez Canillas <javierm at redhat.com>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat



From mark.rutland at arm.com  Mon Dec  4 01:45:21 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 4 Dec 2023 09:45:21 +0000
Subject: [PATCH 1/2] arm: perf: Remove PMU locking
In-Reply-To: <20231115092805.737822-2-anshuman.khandual@arm.com>
References: <20231115092805.737822-1-anshuman.khandual@arm.com>
 <20231115092805.737822-2-anshuman.khandual@arm.com>
Message-ID: <ZW2fsXX-cTpjm9KA@FVFF77S0Q05N>

On Wed, Nov 15, 2023 at 02:58:04PM +0530, Anshuman Khandual wrote:
> The PMU is disabled and enabled, and the counters are programmed from
> contexts where interrupts or preemption is disabled.
> 
> The functions to toggle the PMU and to program the PMU counters access the
> registers directly and don't access data modified by the interrupt handler.
> That, and the fact that they're always called from non-preemptible
> contexts, means that we don't need to disable interrupts or use a spinlock.
> 
> This is very similar to an earlier change on arm64 platform.
> 
> commit 2a0e2a02e4b7 ("arm64: perf: Remove PMU locking").

I realise the commit message is a copy of the wording from 2a0e2a02e4b7, but
some of this isn't quite right; could we please replace that with:

| Currently the 32-bit arm PMU drivers use the pmu_hw_events::lock spinlock in
| their arm_pmu::{start,stop,enable,disable}() callbacks to protect hardware
| state and event data.
|
| This locking is not necessary as the perf core code already provides mutual
| exclusion, disabling interrupts to serialize against the IRQ handler, and
| using perf_event_context::lock to protect against concurrent modifications of
| events cross-cpu.
|
| The locking was removed from the arm64 (now PMUv3) PMU driver in commit:
|
|   2a0e2a02e4b7 ("arm64: perf: Remove PMU locking")
|
| ... and the same reasoning applies to all the 32-bit PMU drivers.
|
| Remove the locking from the 32-bit PMU drivers.

With that wording:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: Russell King <linux at armlinux.org.uk>
> Cc: linux-perf-users at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
>  arch/arm/kernel/perf_event_v6.c     | 28 ++++--------------
>  arch/arm/kernel/perf_event_v7.c     | 44 -----------------------------
>  arch/arm/kernel/perf_event_xscale.c | 44 ++++++-----------------------
>  3 files changed, 13 insertions(+), 103 deletions(-)
> 
> diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
> index 1ae99deeec54..8fc080c9e4fb 100644
> --- a/arch/arm/kernel/perf_event_v6.c
> +++ b/arch/arm/kernel/perf_event_v6.c
> @@ -268,10 +268,8 @@ static inline void armv6pmu_write_counter(struct perf_event *event, u64 value)
>  
>  static void armv6pmu_enable_event(struct perf_event *event)
>  {
> -	unsigned long val, mask, evt, flags;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> +	unsigned long val, mask, evt;
>  	struct hw_perf_event *hwc = &event->hw;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  	int idx = hwc->idx;
>  
>  	if (ARMV6_CYCLE_COUNTER == idx) {
> @@ -294,12 +292,10 @@ static void armv6pmu_enable_event(struct perf_event *event)
>  	 * Mask out the current event and set the counter to count the event
>  	 * that we're interested in.
>  	 */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = armv6_pmcr_read();
>  	val &= ~mask;
>  	val |= evt;
>  	armv6_pmcr_write(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static irqreturn_t
> @@ -362,26 +358,20 @@ armv6pmu_handle_irq(struct arm_pmu *cpu_pmu)
>  
>  static void armv6pmu_start(struct arm_pmu *cpu_pmu)
>  {
> -	unsigned long flags, val;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> +	unsigned long val;
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = armv6_pmcr_read();
>  	val |= ARMV6_PMCR_ENABLE;
>  	armv6_pmcr_write(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void armv6pmu_stop(struct arm_pmu *cpu_pmu)
>  {
> -	unsigned long flags, val;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> +	unsigned long val;
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = armv6_pmcr_read();
>  	val &= ~ARMV6_PMCR_ENABLE;
>  	armv6_pmcr_write(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static int
> @@ -419,10 +409,8 @@ static void armv6pmu_clear_event_idx(struct pmu_hw_events *cpuc,
>  
>  static void armv6pmu_disable_event(struct perf_event *event)
>  {
> -	unsigned long val, mask, evt, flags;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> +	unsigned long val, mask, evt;
>  	struct hw_perf_event *hwc = &event->hw;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  	int idx = hwc->idx;
>  
>  	if (ARMV6_CYCLE_COUNTER == idx) {
> @@ -444,20 +432,16 @@ static void armv6pmu_disable_event(struct perf_event *event)
>  	 * of ETM bus signal assertion cycles. The external reporting should
>  	 * be disabled and so this should never increment.
>  	 */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = armv6_pmcr_read();
>  	val &= ~mask;
>  	val |= evt;
>  	armv6_pmcr_write(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void armv6mpcore_pmu_disable_event(struct perf_event *event)
>  {
> -	unsigned long val, mask, flags, evt = 0;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> +	unsigned long val, mask, evt = 0;
>  	struct hw_perf_event *hwc = &event->hw;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  	int idx = hwc->idx;
>  
>  	if (ARMV6_CYCLE_COUNTER == idx) {
> @@ -475,12 +459,10 @@ static void armv6mpcore_pmu_disable_event(struct perf_event *event)
>  	 * Unlike UP ARMv6, we don't have a way of stopping the counters. We
>  	 * simply disable the interrupt reporting.
>  	 */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = armv6_pmcr_read();
>  	val &= ~mask;
>  	val |= evt;
>  	armv6_pmcr_write(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static int armv6_map_event(struct perf_event *event)
> diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
> index eb2190477da1..c890354b04e9 100644
> --- a/arch/arm/kernel/perf_event_v7.c
> +++ b/arch/arm/kernel/perf_event_v7.c
> @@ -870,10 +870,8 @@ static void armv7_pmnc_dump_regs(struct arm_pmu *cpu_pmu)
>  
>  static void armv7pmu_enable_event(struct perf_event *event)
>  {
> -	unsigned long flags;
>  	struct hw_perf_event *hwc = &event->hw;
>  	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  	int idx = hwc->idx;
>  
>  	if (!armv7_pmnc_counter_valid(cpu_pmu, idx)) {
> @@ -886,7 +884,6 @@ static void armv7pmu_enable_event(struct perf_event *event)
>  	 * Enable counter and interrupt, and set the counter to count
>  	 * the event that we're interested in.
>  	 */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  
>  	/*
>  	 * Disable counter
> @@ -910,16 +907,12 @@ static void armv7pmu_enable_event(struct perf_event *event)
>  	 * Enable counter
>  	 */
>  	armv7_pmnc_enable_counter(idx);
> -
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void armv7pmu_disable_event(struct perf_event *event)
>  {
> -	unsigned long flags;
>  	struct hw_perf_event *hwc = &event->hw;
>  	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  	int idx = hwc->idx;
>  
>  	if (!armv7_pmnc_counter_valid(cpu_pmu, idx)) {
> @@ -931,7 +924,6 @@ static void armv7pmu_disable_event(struct perf_event *event)
>  	/*
>  	 * Disable counter and interrupt
>  	 */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  
>  	/*
>  	 * Disable counter
> @@ -942,8 +934,6 @@ static void armv7pmu_disable_event(struct perf_event *event)
>  	 * Disable interrupt for this counter
>  	 */
>  	armv7_pmnc_disable_intens(idx);
> -
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static irqreturn_t armv7pmu_handle_irq(struct arm_pmu *cpu_pmu)
> @@ -1009,24 +999,14 @@ static irqreturn_t armv7pmu_handle_irq(struct arm_pmu *cpu_pmu)
>  
>  static void armv7pmu_start(struct arm_pmu *cpu_pmu)
>  {
> -	unsigned long flags;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> -
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	/* Enable all counters */
>  	armv7_pmnc_write(armv7_pmnc_read() | ARMV7_PMNC_E);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void armv7pmu_stop(struct arm_pmu *cpu_pmu)
>  {
> -	unsigned long flags;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> -
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	/* Disable all counters */
>  	armv7_pmnc_write(armv7_pmnc_read() & ~ARMV7_PMNC_E);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static int armv7pmu_get_event_idx(struct pmu_hw_events *cpuc,
> @@ -1492,14 +1472,10 @@ static void krait_clearpmu(u32 config_base)
>  
>  static void krait_pmu_disable_event(struct perf_event *event)
>  {
> -	unsigned long flags;
>  	struct hw_perf_event *hwc = &event->hw;
>  	int idx = hwc->idx;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  
>  	/* Disable counter and interrupt */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  
>  	/* Disable counter */
>  	armv7_pmnc_disable_counter(idx);
> @@ -1512,23 +1488,17 @@ static void krait_pmu_disable_event(struct perf_event *event)
>  
>  	/* Disable interrupt for this counter */
>  	armv7_pmnc_disable_intens(idx);
> -
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void krait_pmu_enable_event(struct perf_event *event)
>  {
> -	unsigned long flags;
>  	struct hw_perf_event *hwc = &event->hw;
>  	int idx = hwc->idx;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  
>  	/*
>  	 * Enable counter and interrupt, and set the counter to count
>  	 * the event that we're interested in.
>  	 */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  
>  	/* Disable counter */
>  	armv7_pmnc_disable_counter(idx);
> @@ -1548,8 +1518,6 @@ static void krait_pmu_enable_event(struct perf_event *event)
>  
>  	/* Enable counter */
>  	armv7_pmnc_enable_counter(idx);
> -
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void krait_pmu_reset(void *info)
> @@ -1825,14 +1793,10 @@ static void scorpion_clearpmu(u32 config_base)
>  
>  static void scorpion_pmu_disable_event(struct perf_event *event)
>  {
> -	unsigned long flags;
>  	struct hw_perf_event *hwc = &event->hw;
>  	int idx = hwc->idx;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  
>  	/* Disable counter and interrupt */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  
>  	/* Disable counter */
>  	armv7_pmnc_disable_counter(idx);
> @@ -1845,23 +1809,17 @@ static void scorpion_pmu_disable_event(struct perf_event *event)
>  
>  	/* Disable interrupt for this counter */
>  	armv7_pmnc_disable_intens(idx);
> -
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void scorpion_pmu_enable_event(struct perf_event *event)
>  {
> -	unsigned long flags;
>  	struct hw_perf_event *hwc = &event->hw;
>  	int idx = hwc->idx;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  
>  	/*
>  	 * Enable counter and interrupt, and set the counter to count
>  	 * the event that we're interested in.
>  	 */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  
>  	/* Disable counter */
>  	armv7_pmnc_disable_counter(idx);
> @@ -1881,8 +1839,6 @@ static void scorpion_pmu_enable_event(struct perf_event *event)
>  
>  	/* Enable counter */
>  	armv7_pmnc_enable_counter(idx);
> -
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void scorpion_pmu_reset(void *info)
> diff --git a/arch/arm/kernel/perf_event_xscale.c b/arch/arm/kernel/perf_event_xscale.c
> index f6cdcacfb96d..7a2ba1c689a7 100644
> --- a/arch/arm/kernel/perf_event_xscale.c
> +++ b/arch/arm/kernel/perf_event_xscale.c
> @@ -203,10 +203,8 @@ xscale1pmu_handle_irq(struct arm_pmu *cpu_pmu)
>  
>  static void xscale1pmu_enable_event(struct perf_event *event)
>  {
> -	unsigned long val, mask, evt, flags;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> +	unsigned long val, mask, evt;
>  	struct hw_perf_event *hwc = &event->hw;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  	int idx = hwc->idx;
>  
>  	switch (idx) {
> @@ -229,20 +227,16 @@ static void xscale1pmu_enable_event(struct perf_event *event)
>  		return;
>  	}
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = xscale1pmu_read_pmnc();
>  	val &= ~mask;
>  	val |= evt;
>  	xscale1pmu_write_pmnc(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void xscale1pmu_disable_event(struct perf_event *event)
>  {
> -	unsigned long val, mask, evt, flags;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> +	unsigned long val, mask, evt;
>  	struct hw_perf_event *hwc = &event->hw;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  	int idx = hwc->idx;
>  
>  	switch (idx) {
> @@ -263,12 +257,10 @@ static void xscale1pmu_disable_event(struct perf_event *event)
>  		return;
>  	}
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = xscale1pmu_read_pmnc();
>  	val &= ~mask;
>  	val |= evt;
>  	xscale1pmu_write_pmnc(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static int
> @@ -300,26 +292,20 @@ static void xscalepmu_clear_event_idx(struct pmu_hw_events *cpuc,
>  
>  static void xscale1pmu_start(struct arm_pmu *cpu_pmu)
>  {
> -	unsigned long flags, val;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> +	unsigned long val;
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = xscale1pmu_read_pmnc();
>  	val |= XSCALE_PMU_ENABLE;
>  	xscale1pmu_write_pmnc(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void xscale1pmu_stop(struct arm_pmu *cpu_pmu)
>  {
> -	unsigned long flags, val;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> +	unsigned long val;
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = xscale1pmu_read_pmnc();
>  	val &= ~XSCALE_PMU_ENABLE;
>  	xscale1pmu_write_pmnc(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static inline u64 xscale1pmu_read_counter(struct perf_event *event)
> @@ -549,10 +535,8 @@ xscale2pmu_handle_irq(struct arm_pmu *cpu_pmu)
>  
>  static void xscale2pmu_enable_event(struct perf_event *event)
>  {
> -	unsigned long flags, ien, evtsel;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> +	unsigned long ien, evtsel;
>  	struct hw_perf_event *hwc = &event->hw;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  	int idx = hwc->idx;
>  
>  	ien = xscale2pmu_read_int_enable();
> @@ -587,18 +571,14 @@ static void xscale2pmu_enable_event(struct perf_event *event)
>  		return;
>  	}
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	xscale2pmu_write_event_select(evtsel);
>  	xscale2pmu_write_int_enable(ien);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void xscale2pmu_disable_event(struct perf_event *event)
>  {
> -	unsigned long flags, ien, evtsel, of_flags;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> +	unsigned long ien, evtsel, of_flags;
>  	struct hw_perf_event *hwc = &event->hw;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>  	int idx = hwc->idx;
>  
>  	ien = xscale2pmu_read_int_enable();
> @@ -638,11 +618,9 @@ static void xscale2pmu_disable_event(struct perf_event *event)
>  		return;
>  	}
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	xscale2pmu_write_event_select(evtsel);
>  	xscale2pmu_write_int_enable(ien);
>  	xscale2pmu_write_overflow_flags(of_flags);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static int
> @@ -663,26 +641,20 @@ xscale2pmu_get_event_idx(struct pmu_hw_events *cpuc,
>  
>  static void xscale2pmu_start(struct arm_pmu *cpu_pmu)
>  {
> -	unsigned long flags, val;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> +	unsigned long val;
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = xscale2pmu_read_pmnc() & ~XSCALE_PMU_CNT64;
>  	val |= XSCALE_PMU_ENABLE;
>  	xscale2pmu_write_pmnc(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static void xscale2pmu_stop(struct arm_pmu *cpu_pmu)
>  {
> -	unsigned long flags, val;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> +	unsigned long val;
>  
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
>  	val = xscale2pmu_read_pmnc();
>  	val &= ~XSCALE_PMU_ENABLE;
>  	xscale2pmu_write_pmnc(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
>  static inline u64 xscale2pmu_read_counter(struct perf_event *event)
> -- 
> 2.25.1
> 


From mark.rutland at arm.com  Mon Dec  4 01:45:54 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 4 Dec 2023 09:45:54 +0000
Subject: [PATCH 2/2] drivers: perf: arm_pmu: Drop 'pmu_lock' element from
 'struct pmu_hw_events'
In-Reply-To: <20231115092805.737822-3-anshuman.khandual@arm.com>
References: <20231115092805.737822-1-anshuman.khandual@arm.com>
 <20231115092805.737822-3-anshuman.khandual@arm.com>
Message-ID: <ZW2f0kACNEp7-X-M@FVFF77S0Q05N>

On Wed, Nov 15, 2023 at 02:58:05PM +0530, Anshuman Khandual wrote:
> As 'pmu_lock' element is not being used in any ARM PMU implementation, just
> drop this from 'struct pmu_hw_events'.
> 
> Cc: Will Deacon <will at kernel.org>
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> ---
>  drivers/perf/arm_pmu.c       | 1 -
>  include/linux/perf/arm_pmu.h | 6 ------
>  2 files changed, 7 deletions(-)
> 
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index d712a19e47ac..379479b50bdd 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -893,7 +893,6 @@ struct arm_pmu *armpmu_alloc(void)
>  		struct pmu_hw_events *events;
>  
>  		events = per_cpu_ptr(pmu->hw_events, cpu);
> -		raw_spin_lock_init(&events->pmu_lock);
>  		events->percpu_pmu = pmu;
>  	}
>  
> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> index 143fbc10ecfe..e2503d48ddee 100644
> --- a/include/linux/perf/arm_pmu.h
> +++ b/include/linux/perf/arm_pmu.h
> @@ -59,12 +59,6 @@ struct pmu_hw_events {
>  	 */
>  	DECLARE_BITMAP(used_mask, ARMPMU_MAX_HWEVENTS);
>  
> -	/*
> -	 * Hardware lock to serialize accesses to PMU registers. Needed for the
> -	 * read/modify/write sequences.
> -	 */
> -	raw_spinlock_t		pmu_lock;
> -
>  	/*
>  	 * When using percpu IRQs, we need a percpu dev_id. Place it here as we
>  	 * already have to allocate this struct per cpu.
> -- 
> 2.25.1
> 


From linus.walleij at linaro.org  Mon Dec  4 01:47:17 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 4 Dec 2023 10:47:17 +0100
Subject: [PATCH v4 1/1] pinctrl: mediatek: Switch to use no-IRQ PM helpers
In-Reply-To: <20231122144744.2222207-1-andriy.shevchenko@linux.intel.com>
References: <20231122144744.2222207-1-andriy.shevchenko@linux.intel.com>
Message-ID: <CACRpkdZtCOwmVa7_vyCfs5i3GVdvopNAGA3rPyij0EeLr8e4MA@mail.gmail.com>

On Wed, Nov 22, 2023 at 3:49?PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:

> Since pm.h provides a helper for system no-IRQ PM callbacks,
> switch the driver to use it instead of open coded variant.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

Patch applied!

Yours,
Linus Walleij


From u.kleine-koenig at pengutronix.de  Mon Dec  4 01:47:39 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Mon,  4 Dec 2023 10:47:39 +0100
Subject: [PATCH 0/3] PCI: Convert to platform remove callback returning void (part II)
Message-ID: <cover.1701682617.git.u.kleine-koenig@pengutronix.de>

Hello,

back in March I sent a series[1] with the intention to convert all of
drivers/pci to .remove_new(). I missed these three drivers because my
coccinelle script didn't handle __exit_p. (The drivers don't use
__exit_p in the mean time since the follwing commits:

	200bddbb3f52 ("PCI: keystone: Don't discard .remove() callback")
	3064ef2e88c1 ("PCI: kirin: Don't discard .remove() callback")
	83a939f0fdc2 ("PCI: exynos: Don't discard .remove() callback")

.)

There are no interdependencies between these patches.

See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for an extended explanation and the eventual goal.

Best regards
Uwe

[1] https://lore.kernel.org/linux-pci/20230321193208.366561-1-u.kleine-koenig at pengutronix.de
    merged in v6.5-rc1~111^2

Uwe Kleine-K?nig (3):
  PCI: exynos: Convert to platform remove callback returning void
  PCI: keystone: Convert to platform remove callback returning void
  PCI: kirin: Convert to platform remove callback returning void

 drivers/pci/controller/dwc/pci-exynos.c   | 6 ++----
 drivers/pci/controller/dwc/pci-keystone.c | 6 ++----
 drivers/pci/controller/dwc/pcie-kirin.c   | 6 ++----
 3 files changed, 6 insertions(+), 12 deletions(-)


base-commit: 629a3b49f3f957e975253c54846090b8d5ed2e9b
-- 
2.42.0



From mark.rutland at arm.com  Mon Dec  4 01:48:09 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 4 Dec 2023 09:48:09 +0000
Subject: [PATCH 0/2] drivers: perf: arm_pmu: Drop 'pmu_lock' element from
 'struct pmu_hw_events'
In-Reply-To: <a8362015-c6e6-4d59-ba2b-67dc12bd89c8@arm.com>
References: <20231115092805.737822-1-anshuman.khandual@arm.com>
 <a8362015-c6e6-4d59-ba2b-67dc12bd89c8@arm.com>
Message-ID: <ZW2gWTfIKgHAYwSd@FVFF77S0Q05N>

On Tue, Nov 28, 2023 at 10:59:49AM +0530, Anshuman Khandual wrote:
> 
> 
> On 11/15/23 14:58, Anshuman Khandual wrote:
> > This series drops 'pmu_lock' usage from all arm platforms which had already
> > been dropped from arm64 platforms earlier via the following commit.
> > 
> > commit 2a0e2a02e4b7 ("arm64: perf: Remove PMU locking"). 
> > 
> > Afterwards, drop unused 'pmu_lock' element from 'struct pmu_hw_events'. The
> > series applies on 6.7-rc1 and has been tested on arm64. Although just build
> > tested for arm platform.
> > 
> > Cc: Mark Rutland <mark.rutland at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> > Cc: Russell King <linux at armlinux.org.uk>
> > Cc: linux-perf-users at vger.kernel.org
> > Cc: linux-kernel at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > 
> > Changes in V1:
> > 
> > - Added some build warning fixes
> 
> Hello Will/Mark,
> 
> Any updates or concerns on this series ?

The changes themselves look good to me. I'd like to tweak the commit message
for the first patch (and I've given specific wording that we can use).

Will, are you happy to fold that in when applying, or would you prefer that
Anshuman sends a v2?

Mark.


From u.kleine-koenig at pengutronix.de  Mon Dec  4 01:47:40 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Mon,  4 Dec 2023 10:47:40 +0100
Subject: [PATCH 1/3] PCI: exynos: Convert to platform remove callback returning void
In-Reply-To: <cover.1701682617.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701682617.git.u.kleine-koenig@pengutronix.de>
Message-ID: <50de44ea8931465fd9cdc821854ea761cb43adf6.1701682617.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

In the error path emit an error message replacing the (less useful)
message by the core. Apart from the improved error message there is no
change in behaviour.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pci/controller/dwc/pci-exynos.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index c6bede346932..104397ba45bd 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -375,7 +375,7 @@ static int exynos_pcie_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int exynos_pcie_remove(struct platform_device *pdev)
+static void exynos_pcie_remove(struct platform_device *pdev)
 {
 	struct exynos_pcie *ep = platform_get_drvdata(pdev);
 
@@ -385,8 +385,6 @@ static int exynos_pcie_remove(struct platform_device *pdev)
 	phy_exit(ep->phy);
 	exynos_pcie_deinit_clk_resources(ep);
 	regulator_bulk_disable(ARRAY_SIZE(ep->supplies), ep->supplies);
-
-	return 0;
 }
 
 static int exynos_pcie_suspend_noirq(struct device *dev)
@@ -431,7 +429,7 @@ static const struct of_device_id exynos_pcie_of_match[] = {
 
 static struct platform_driver exynos_pcie_driver = {
 	.probe		= exynos_pcie_probe,
-	.remove		= exynos_pcie_remove,
+	.remove_new	= exynos_pcie_remove,
 	.driver = {
 		.name	= "exynos-pcie",
 		.of_match_table = exynos_pcie_of_match,
-- 
2.42.0



From maz at kernel.org  Mon Dec  4 01:48:43 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 09:48:43 +0000
Subject: [PATCH v3 3/6] arm64: KVM: Add iflag for FEAT_TRF
In-Reply-To: <20231019165510.1966367-4-james.clark@arm.com>
References: <20231019165510.1966367-1-james.clark@arm.com>
	<20231019165510.1966367-4-james.clark@arm.com>
Message-ID: <86o7f6b8n8.wl-maz@kernel.org>

On Thu, 19 Oct 2023 17:55:01 +0100,
James Clark <james.clark at arm.com> wrote:
> 
> Add an extra iflag to signify if the TRFCR register is accessible.
> Because TRBE requires FEAT_TRF, DEBUG_STATE_SAVE_TRBE still has the same
> behavior even though it's only set when FEAT_TRF is present.
> 
> The following holes are left in struct kvm_vcpu_arch, but there aren't
> enough other 8 bit fields to rearrange it to leave any hole smaller than
> 7 bytes:
> 
>   u8                         cflags;               /*  2292     1 */
>   /* XXX 1 byte hole, try to pack */
>   u16                        iflags;               /*  2294     2 */
>   u8                         sflags;               /*  2296     1 */
>   bool                       pause;                /*  2297     1 */
>   /* XXX 6 bytes hole, try to pack */
> 
> Signed-off-by: James Clark <james.clark at arm.com>
> ---
>  arch/arm64/include/asm/kvm_host.h |  4 +++-
>  arch/arm64/kvm/debug.c            | 22 ++++++++++++++++++----
>  2 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 7c82927ddaf2..0f0bf8e641bd 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -535,7 +535,7 @@ struct kvm_vcpu_arch {
>  	u8 cflags;
>  
>  	/* Input flags to the hypervisor code, potentially cleared after use */
> -	u8 iflags;
> +	u16 iflags;
>  
>  	/* State flags for kernel bookkeeping, unused by the hypervisor code */
>  	u8 sflags;
> @@ -741,6 +741,8 @@ struct kvm_vcpu_arch {
>  #define DEBUG_STATE_SAVE_TRBE	__vcpu_single_flag(iflags, BIT(6))
>  /* vcpu running in HYP context */
>  #define VCPU_HYP_CONTEXT	__vcpu_single_flag(iflags, BIT(7))
> +/* Save trace filter controls */
> +#define DEBUG_STATE_SAVE_TRFCR	__vcpu_single_flag(iflags, BIT(8))
>  
>  /* SVE enabled for host EL0 */
>  #define HOST_SVE_ENABLED	__vcpu_single_flag(sflags, BIT(0))
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 8725291cb00a..20cdd40b3c42 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -331,14 +331,28 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
>  	    !(read_sysreg_s(SYS_PMBIDR_EL1) & BIT(PMBIDR_EL1_P_SHIFT)))
>  		vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_SPE);
>  
> -	/* Check if we have TRBE implemented and available at the host */
> -	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceBuffer_SHIFT) &&
> -	    !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P))
> -		vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
> +	/*
> +	 * Save TRFCR on nVHE if FEAT_TRF (TraceFilt) exists. This will be
> +	 * done in cases where use of TRBE doesn't completely disable trace and
> +	 * handles the exclude_host/exclude_guest rules of the trace session.

This comment provides zero information. What will be done? Under which
conditions? What are the rules?

> +	 */
> +	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceFilt_SHIFT)) {
> +		vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
> +		/*
> +		 * Check if we have TRBE implemented and available at the host. If it's
> +		 * in use at the time of guest switch it will need to be disabled and
> +		 * then restored. The architecture mandates FEAT_TRF with TRBE, so we
> +		 * only need to check for TRBE after TRF.
> +		 */
> +		if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceBuffer_SHIFT) &&
> +		    !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P))
> +			vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
> +	}

Multiple questions:

- Why is it safe to trust the local CPU's capability rather than the
  consolidated view from the cpufeature infrastructure?

- Why defer the saving of the registers if there are no changes made
  to them in the interval?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


From wenst at chromium.org  Mon Dec  4 01:52:36 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Mon, 4 Dec 2023 17:52:36 +0800
Subject: [RFC PATCH v3 2/5] i2c: of: Introduce component probe function
In-Reply-To: <CAD=FV=U_+iQJtV0Wii89DQT1V_fJCeS9wcqA8EJAs-hmmmLLLg@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-3-wenst@chromium.org>
 <CAD=FV=U_+iQJtV0Wii89DQT1V_fJCeS9wcqA8EJAs-hmmmLLLg@mail.gmail.com>
Message-ID: <CAGXv+5EpA531O1tW=h1RvK34+LMvtdve3=cNmfN=2+9t1jL_bA@mail.gmail.com>

On Sat, Dec 2, 2023 at 8:58?AM Doug Anderson <dianders at chromium.org> wrote:
>
> Hi,
>
> On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >
> > @@ -217,4 +217,114 @@ static int of_i2c_notify(struct notifier_block *nb, unsigned long action,
> >  struct notifier_block i2c_of_notifier = {
> >         .notifier_call = of_i2c_notify,
> >  };
> > +
> > +/*
> > + * Some devices, such as Google Hana Chromebooks, are produced by multiple
> > + * vendors each using their preferred components. Such components are all
> > + * in the device tree. Instead of having all of them enabled and having each
> > + * driver separately try and probe its device while fighting over shared
> > + * resources, they can be marked as "fail-needs-probe" and have a prober
> > + * figure out which one is actually used beforehand.
> > + *
> > + * This prober assumes such drop-in parts are on the same I2C bus, have
> > + * non-conflicting addresses, and can be directly probed by seeing which
> > + * address responds.
> > + *
> > + * TODO:
> > + * - Support handling common regulators and GPIOs.
>
> IMO you should prototype how you're going to handle regulators and
> GPIOs before finalizing the design. I was going to write that you
> should just document that it was up to the caller to power things up
> before calling this function, but then I realized that the caller
> would have to duplicate much of this function in order to do so. In
> the very least they'd have to find the nodes of the relevant devices
> so that they could grab regulators and/or GPIOs. In order to avoid
> this duplication, would the design need to change? Perhaps this would
> be as simple as adding a callback function here that's called with all
> of the nodes before probing? If that's right, it would be nice to have
> that callback from the beginning so we don't need two variants of the
> function...

So I think I can prototype designs with one GPIO and multiple regulators,
assuming each node has the same number of both? At least they should if
they're on the same connector.

More than one GPIO probably means there are some ordering and timing
constraints, and won't be as generic.

> > + * - Support I2C muxes
> > + */
> > +
> > +/**
> > + * i2c_of_probe_component() - probe for devices of "type" on the same i2c bus
> > + * @dev: &struct device of the caller, only used for dev_* printk messages
> > + * @type: a string to match the device node name prefix to probe for
> > + *
> > + * Probe for possible I2C components of the same "type" on the same I2C bus
> > + * that have their status marked as "fail".
>
> Should document these current limitations with the code:
>
> * Assumes that across the entire device tree the only instances of
> nodes named "type" are ones we're trying to handle second sourcing
> for. In other words if we're searching for "touchscreen" then all
> nodes named "touchscreen" are ones that need to be probed.
>
> * Assumes that there is exactly one group of each "type". In other
> words, if we're searching for "touchscreen" then exactly one
> touchscreen will be enabled across the whole tree.
>
> Obviously those could be relaxed with more code, but that's the
> current limitation and it makes the code easier to understand with
> that context.

Done.

> > + */
> > +int i2c_of_probe_component(struct device *dev, const char *type)
> > +{
> > +       struct device_node *node, *i2c_node;
> > +       struct i2c_adapter *i2c;
> > +       struct of_changeset *ocs = NULL;
> > +       int ret;
> > +
> > +       node = of_find_node_by_name(NULL, type);
> > +       if (!node)
> > +               return dev_err_probe(dev, -ENODEV, "Could not find %s device node\n", type);
> > +
> > +       i2c_node = of_get_next_parent(node);
> > +       if (!of_node_name_eq(i2c_node, "i2c")) {
> > +               of_node_put(i2c_node);
> > +               return dev_err_probe(dev, -EINVAL, "%s device isn't on I2C bus\n", type);
> > +       }
>
> Personally I'd skip checking for the "i2c" node name. Just rely on
> of_get_i2c_adapter_by_node() returning an error.
>
> Oh, I guess you have this because you need to tell the difference
> between -EINVAL and -EPROBE_DEFER? It feels like instead you could use
> the firmware node to lookup a device more generically. If a device
> isn't associated with the node at all then you return -EPROBE_DEFER.
> Otherwise if it's associated but not an i2c device then you return
> -EINVAL. I guess maybe it doesn't make a huge difference, but it
> somehow feels less fragile than relying on the node name being "i2c".
> Maybe I just haven't had enough DT Kool-Aid.

The current way it's written is to do the device tree structure checks
first before doing any driver model access. Also it needs to tell
(as you mentioned later) if the i2c adapter is "disabled" or just not
probed yet.

> One thing this made me wonder is if of_get_i2c_adapter_by_node() is
> race free anyway. Can't that return you a device that hasn't finished
> probing yet? I see:
>
> - i2c_register_adapter()
> -- device_register()
> --- device_add()
> ---- bus_add_device()
> ---- bus_probe_device()
>
> As soon as bus_add_device() is called then it will be in
> "klist_devices" and I believe i2c_find_device_by_fwnode() will be able
> to find it. However, it hasn't necessarily been probed yet. I think
> that means calling i2c_smbus_xfer() on it might not work yet...

It does look like there's a small window between the device_register()
and when the i2c adapter is ready, i.e. can't bail out on an error.

I guess it needs either a flag or some reordering of the code.

It looks like Wolfram will be at OSS JP. I'll try and have a chat about
the whole thing.

> One last thing is that you should check to make sure that the i2c
> adapter is not marked "disabled". ...otherwise I think you'd end up
> constantly trying again and again...

Yeah. I added a check for that as well.

> > +       for_each_child_of_node(i2c_node, node) {
> > +               if (!of_node_name_prefix(node, type))
> > +                       continue;
> > +               if (of_device_is_available(node)) {
> > +                       /*
> > +                        * Device tree has component already enabled. Either the
> > +                        * device tree isn't supported or we already probed once.
>
> I guess the "already probed once" is somewhat expected if more than
> one type of second source component is defined and we end up deferring
> the second one? We don't undo the resolution of the first one and
> probably don't keep track of the fact that it succeeded?

That's right.

> Probably should be added to the function comments that this is an
> expected/normal case?

Added to the Return: section of the kernel-doc.

> > +                        */
> > +                       of_node_put(node);
> > +                       of_node_put(i2c_node);
> > +                       return 0;
> > +               }
> > +       }
> > +
> > +       i2c = of_get_i2c_adapter_by_node(i2c_node);
> > +       if (!i2c) {
> > +               of_node_put(i2c_node);
> > +               return dev_err_probe(dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
> > +       }
> > +
> > +       ret = 0;
>
> Why init ret to 0?

It was requested by Andy. I believe the reason was having the initial
value used for bailout closer was better.

> > +       for_each_child_of_node(i2c_node, node) {
> > +               union i2c_smbus_data data;
> > +               u32 addr;
> > +
> > +               if (!of_node_name_prefix(node, type))
> > +                       continue;
> > +               if (of_property_read_u32(node, "reg", &addr))
> > +                       continue;
> > +               if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
>
> I'd be tempted to say that the caller should be able to pass in a
> function pointer here so they could use an alternative method to probe
> instead of i2c_smbus_xfer(), though you'd want to make it easy to
> default to i2c_smbus_xfer(). I could imagine someone might need a
> different way to probe. For instance if you had two touchscreens both
> at the same "reg" but that had different "hid-descr-addr" then this
> could be important.

I'd say the only specific probable type is hid-i2c. And that could be
generic enough that we could incorporate it here if we wanted. However
I think we want to keep the initial version a bit simpler.

> > +                       continue;
> > +
>
> Put the "break" right here. You've found the device and that was the
> point of the loop.

In its place we'd have an if (node) { <enable node> } block. I guess it
makes it easier to read still?

> Once you do that then the error handling makes a little more sense. It
> was weird that the error handling was jumped through from inside the
> loop...
>
>
> > +               dev_info(dev, "Enabling %pOF\n", node);
> > +
> > +               ocs = kzalloc(sizeof(*ocs), GFP_KERNEL);
> > +               if (!ocs) {
> > +                       ret = -ENOMEM;
> > +                       goto err_put_node;
>
> I think this error path (and some others) miss "i2c_put_adapter()" and
> "of_node_put(i2c_node)"

Right. I'll check.


Thanks
ChenYu


From linus.walleij at linaro.org  Mon Dec  4 01:53:04 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 4 Dec 2023 10:53:04 +0100
Subject: [PATCH 0/3] pinctrl: pinctrl-single: fix suspend/resume on j7200
In-Reply-To: <20231128-j7200-pinctrl-s2r-v1-0-704e7dc24460@bootlin.com>
References: <20231128-j7200-pinctrl-s2r-v1-0-704e7dc24460@bootlin.com>
Message-ID: <CACRpkdbsOxxemqe023jsE8vCxgY763CAZJ-Ru9dLTr=5-wqzBA@mail.gmail.com>

On Tue, Nov 28, 2023 at 4:35?PM Thomas Richard
<thomas.richard at bootlin.com> wrote:

> Thomas Richard (3):
>       dt-bindings: pinctrl: pinctrl-single: add ti,j7200-padconf compatible
>       pinctrl: pinctrl-single: add ti,j7200-padconf compatible

Patch 1 & 2 applied to the pin control tree, thanks!

>       arm64: dts: ti: k3-j7200: use ti,j7200-padconf compatible

Please funnel this through the SoC tree.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Mon Dec  4 01:53:41 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 4 Dec 2023 10:53:41 +0100
Subject: [PATCH 3/3] arm64: dts: ti: k3-j7200: use ti,j7200-padconf compatible
In-Reply-To: <20231128-j7200-pinctrl-s2r-v1-3-704e7dc24460@bootlin.com>
References: <20231128-j7200-pinctrl-s2r-v1-0-704e7dc24460@bootlin.com> <20231128-j7200-pinctrl-s2r-v1-3-704e7dc24460@bootlin.com>
Message-ID: <CACRpkdYndEUkC7j133LVsrFXgpujwimvxGPYfDeVTRZAWsQprQ@mail.gmail.com>

On Tue, Nov 28, 2023 at 4:35?PM Thomas Richard
<thomas.richard at bootlin.com> wrote:

> For suspend to ram on j7200, use ti,j7200-padconf compatible to save and
> restore pinctrl contexts.
>
> Signed-off-by: Thomas Richard <thomas.richard at bootlin.com>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From james.clark at arm.com  Mon Dec  4 01:57:31 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 4 Dec 2023 09:57:31 +0000
Subject: [PATCH V2 1/7] coresight: replicator: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <b9f407c7-62af-47e1-bea9-c494cdfed1e9@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-2-anshuman.khandual@arm.com>
 <20231201123515.gntwvhsxd5nzojn7@bogus>
 <58882cab-89ce-4554-aee4-24e70d82fc09@arm.com>
 <b9f407c7-62af-47e1-bea9-c494cdfed1e9@arm.com>
Message-ID: <2aec13e9-4ae3-676f-1ba8-c9e9a9241063@arm.com>



On 04/12/2023 04:48, Anshuman Khandual wrote:
> 
> 
> On 12/4/23 09:56, Anshuman Khandual wrote:
>>
>>
>> On 12/1/23 18:05, Sudeep Holla wrote:
>>> On Fri, Dec 01, 2023 at 11:50:47AM +0530, Anshuman Khandual wrote:
>>>> Add support for the dynamic replicator device in the platform driver, which
>>>> can then be used on ACPI based platforms. This change would now allow
>>>> runtime power management for repliacator devices on ACPI based systems.
>>>>
>>>> The driver would try to enable the APB clock if available. Also, rename the
>>>> code to reflect the fact that it now handles both static and dynamic
>>>> replicators.
>>>>
>>>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>>>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>>>
>>> Except the minor nit below which may apply also for few other patches
>>> in the series
>>>
>>> Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
>>> Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
>>>
>>> [...]
>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
>>>> index b6be73034996..64de0bee02ec 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-replicator.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
>>>> @@ -38,6 +38,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>>>>  struct replicator_drvdata {
>>>>  	void __iomem		*base;
>>>>  	struct clk		*atclk;
>>>> +	struct clk		*pclk;
>>>
>>> [minor nit] Perhaps can be documented as well ?
>>
>> Sure, will add the following comment above the structure.
>>
>> @pclk:    optional clock for the core parts of the replicator.
> 
> My bad, this will be the following instead.
> 
> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
> index 64de0bee02ec..44b9a77ec8aa 100644
> --- a/drivers/hwtracing/coresight/coresight-replicator.c
> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
> @@ -31,6 +31,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>   * @base:      memory mapped base address for this component. Also indicates
>   *             whether this one is programmable or not.
>   * @atclk:     optional clock for the core parts of the replicator.
> + * @pclk:      APB clock if present, otherwise NULL
>   * @csdev:     component vitals needed by the framework
>   * @spinlock:  serialize enable/disable operations.
>   * @check_idfilter_val: check if the context is lost upon clock removal.
> 
> I will update replicator, tpiu, tmc, and stm devices.
> 

funnel is missing it as well. If you build with W=1 it shows up.

> struct catu_drvdata and debug_drvdata do not have the comment section itself.
> _______________________________________________
> CoreSight mailing list -- coresight at lists.linaro.org
> To unsubscribe send an email to coresight-leave at lists.linaro.org


From maz at kernel.org  Mon Dec  4 01:59:59 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 09:59:59 +0000
Subject: [PATCH v3 4/6] arm64: KVM: Add interface to set guest value for TRFCR register
In-Reply-To: <20231019165510.1966367-5-james.clark@arm.com>
References: <20231019165510.1966367-1-james.clark@arm.com>
	<20231019165510.1966367-5-james.clark@arm.com>
Message-ID: <86msuqb84g.wl-maz@kernel.org>

On Thu, 19 Oct 2023 17:55:02 +0100,
James Clark <james.clark at arm.com> wrote:
> 
> Add an interface for the Coresight driver to use to set the value of the
> TRFCR register for the guest. This register controls the exclude
> settings for trace at different exception levels, and is used to honor
> the exclude_host and exclude_guest parameters from the Perf session.
> This will be used to later write TRFCR_EL1 on nVHE at guest switch. For
> VHE, the host trace is controlled by TRFCR_EL2 and thus we can write to
> the TRFCR_EL1 immediately. Because guest writes to the register are
> trapped, the value will persist and can't be modified.
> 
> The settings must be copied to the vCPU before each run in the same
> way that PMU events are, because the per-cpu struct isn't accessible in
> protected mode.

Then maybe we should look at a better way of sharing global data
between EL1 and EL2 instead of copying stuff ad-nauseam?

> 
> Signed-off-by: James Clark <james.clark at arm.com>
> ---
>  arch/arm64/include/asm/kvm_host.h |  3 +++
>  arch/arm64/kvm/arm.c              |  1 +
>  arch/arm64/kvm/debug.c            | 26 ++++++++++++++++++++++++++
>  3 files changed, 30 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 0f0bf8e641bd..e1852102550d 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -1125,6 +1125,8 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu);
>  void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr);
>  void kvm_clr_pmu_events(u32 clr);
>  bool kvm_set_pmuserenr(u64 val);
> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest);
> +void kvm_etm_update_vcpu_events(struct kvm_vcpu *vcpu);
>  #else
>  static inline void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr) {}
>  static inline void kvm_clr_pmu_events(u32 clr) {}
> @@ -1132,6 +1134,7 @@ static inline bool kvm_set_pmuserenr(u64 val)
>  {
>  	return false;
>  }
> +static inline void kvm_etm_set_guest_trfcr(u64 trfcr_guest) {}
>  #endif
>  
>  void kvm_vcpu_load_sysregs_vhe(struct kvm_vcpu *vcpu);
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 0f717b6a9151..e4d846f2f665 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1015,6 +1015,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>  		kvm_vgic_flush_hwstate(vcpu);
>  
>  		kvm_pmu_update_vcpu_events(vcpu);
> +		kvm_etm_update_vcpu_events(vcpu);
>  
>  		/*
>  		 * Ensure we set mode to IN_GUEST_MODE after we disable
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 20cdd40b3c42..2ab41b954512 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -23,6 +23,12 @@
>  
>  static DEFINE_PER_CPU(u64, mdcr_el2);
>  
> +/*
> + * Per CPU value for TRFCR that should be applied to any guest vcpu that may
> + * run on that core in the future.
> + */
> +static DEFINE_PER_CPU(u64, guest_trfcr);
> +
>  /**
>   * save/restore_guest_debug_regs
>   *
> @@ -356,3 +362,23 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
>  }
> +
> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest)
> +{
> +	if (has_vhe())
> +		write_sysreg_s(trfcr_guest, SYS_TRFCR_EL12);
> +	else
> +		*this_cpu_ptr(&guest_trfcr) = trfcr_guest;
> +}
> +EXPORT_SYMBOL_GPL(kvm_etm_set_guest_trfcr);

How does the ETM code know what guests it impacts? Don't you have some
per-process context already?

> +
> +/*
> + * Updates the vcpu's view of the etm events for this cpu. Must be
> + * called before every vcpu run after disabling interrupts, to ensure
> + * that an interrupt cannot fire and update the structure.
> + */
> +void kvm_etm_update_vcpu_events(struct kvm_vcpu *vcpu)
> +{
> +	if (!has_vhe() && vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_TRFCR))
> +		ctxt_sys_reg(&vcpu->arch.ctxt, TRFCR_EL1) = *this_cpu_ptr(&guest_trfcr);
> +}

Why this requirement of updating it at all times? Why can't this be
done in a more lazy way, using the flags to instruct the hypervisor
what and when to load it?

	M.

-- 
Without deviation from the norm, progress is not possible.


From krzysztof.kozlowski at linaro.org  Mon Dec  4 02:04:55 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon,  4 Dec 2023 11:04:55 +0100
Subject: [PATCH] arm64: defconfig: qcom: enable X1E80100 sound card
Message-ID: <20231204100455.212567-1-krzysztof.kozlowski@linaro.org>

Enable the sound machine driver for Qualcomm X1E80100 sound card, used
on several boards with X1E80100 (e.g. X1E80100 CRD).

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

The driver and bindings were posted here:
https://lore.kernel.org/alsa-devel/20231204100116.211898-1-krzysztof.kozlowski at linaro.org/T/#t

The DTS change will be coming soon.
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e29d87008edf..d5be018cb348 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -925,6 +925,7 @@ CONFIG_SND_SOC_SDM845=m
 CONFIG_SND_SOC_SM8250=m
 CONFIG_SND_SOC_SC7180=m
 CONFIG_SND_SOC_SC7280=m
+CONFIG_SND_SOC_X1E80100=m
 CONFIG_SND_SOC_ROCKCHIP=m
 CONFIG_SND_SOC_ROCKCHIP_I2S_TDM=m
 CONFIG_SND_SOC_ROCKCHIP_SPDIF=m
-- 
2.34.1



From raphael.gallais-pou at foss.st.com  Mon Dec  4 02:11:11 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Mon, 4 Dec 2023 11:11:11 +0100
Subject: [PATCH v2 2/4] drm/stm: dsi: add pm runtime ops
In-Reply-To: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>
References: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231204101113.276368-3-raphael.gallais-pou@foss.st.com>

From: Yannick Fertre <yannick.fertre at foss.st.com>

Update control of clocks and supply thanks to the PM runtime
mechanism to avoid kernel crash during a system suspend.

Signed-off-by: Yannick Fertre <yannick.fertre at foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
Changes in v2:
	- Changed SET_RUNTIME_PM_OPS to RUNTIME_PM_OPS and removed
	__maybe_unused
---
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index b1aee43d51e9..82fff9e84345 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -11,6 +11,7 @@
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/regulator/consumer.h>
 
 #include <video/mipi_display.h>
@@ -77,6 +78,7 @@ enum dsi_color {
 struct dw_mipi_dsi_stm {
 	void __iomem *base;
 	struct clk *pllref_clk;
+	struct clk *pclk;
 	struct dw_mipi_dsi *dsi;
 	u32 hw_version;
 	int lane_min_kbps;
@@ -443,7 +445,6 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct dw_mipi_dsi_stm *dsi;
-	struct clk *pclk;
 	int ret;
 
 	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
@@ -483,21 +484,21 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
 		goto err_clk_get;
 	}
 
-	pclk = devm_clk_get(dev, "pclk");
-	if (IS_ERR(pclk)) {
-		ret = PTR_ERR(pclk);
+	dsi->pclk = devm_clk_get(dev, "pclk");
+	if (IS_ERR(dsi->pclk)) {
+		ret = PTR_ERR(dsi->pclk);
 		DRM_ERROR("Unable to get peripheral clock: %d\n", ret);
 		goto err_dsi_probe;
 	}
 
-	ret = clk_prepare_enable(pclk);
+	ret = clk_prepare_enable(dsi->pclk);
 	if (ret) {
 		DRM_ERROR("%s: Failed to enable peripheral clk\n", __func__);
 		goto err_dsi_probe;
 	}
 
 	dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
-	clk_disable_unprepare(pclk);
+	clk_disable_unprepare(dsi->pclk);
 
 	if (dsi->hw_version != HWVER_130 && dsi->hw_version != HWVER_131) {
 		ret = -ENODEV;
@@ -551,6 +552,7 @@ static int dw_mipi_dsi_stm_suspend(struct device *dev)
 	DRM_DEBUG_DRIVER("\n");
 
 	clk_disable_unprepare(dsi->pllref_clk);
+	clk_disable_unprepare(dsi->pclk);
 	regulator_disable(dsi->vdd_supply);
 
 	return 0;
@@ -569,8 +571,16 @@ static int dw_mipi_dsi_stm_resume(struct device *dev)
 		return ret;
 	}
 
+	ret = clk_prepare_enable(dsi->pclk);
+	if (ret) {
+		regulator_disable(dsi->vdd_supply);
+		DRM_ERROR("Failed to enable pclk: %d\n", ret);
+		return ret;
+	}
+
 	ret = clk_prepare_enable(dsi->pllref_clk);
 	if (ret) {
+		clk_disable_unprepare(dsi->pclk);
 		regulator_disable(dsi->vdd_supply);
 		DRM_ERROR("Failed to enable pllref_clk: %d\n", ret);
 		return ret;
@@ -582,6 +592,8 @@ static int dw_mipi_dsi_stm_resume(struct device *dev)
 static const struct dev_pm_ops dw_mipi_dsi_stm_pm_ops = {
 	SYSTEM_SLEEP_PM_OPS(dw_mipi_dsi_stm_suspend,
 			    dw_mipi_dsi_stm_resume)
+	RUNTIME_PM_OPS(dw_mipi_dsi_stm_suspend,
+		       dw_mipi_dsi_stm_resume, NULL)
 };
 
 static struct platform_driver dw_mipi_dsi_stm_driver = {
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Mon Dec  4 02:11:09 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Mon, 4 Dec 2023 11:11:09 +0100
Subject: [PATCH v2 0/4] Update STM DSI PHY driver
Message-ID: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>

This patch series aims to add several features of the dw-mipi-dsi phy
driver that are missing or need to be updated.

First patch update a PM macro.

Second patch adds runtime PM functionality to the driver.

Third patch adds a clock provider generated by the PHY itself.  As
explained in the commit log of the second patch, a clock declaration is
missing.  Since this clock is parent of 'dsi_k', it leads to an orphan
clock.  Most importantly this patch is an anticipation for future
versions of the DSI PHY, and its inclusion within the display subsystem
and the DRM framework.

Last patch fixes a corner effect introduced previously.  Since 'dsi' and
'dsi_k' are gated by the same bit on the same register, both reference
work as peripheral clock in the device-tree.

---
Changes in v2:
	- Added patch 1/4 to use SYSTEM_SLEEP_PM_OPS instead of old macro
	  and removed __maybe_used for accordingly
	- Changed SET_RUNTIME_PM_OPS to RUNTIME_PM_OPS

Raphael Gallais-Pou (3):
  drm/stm: dsi: use new SYSTEM_SLEEP_PM_OPS() macro
  drm/stm: dsi: expose DSI PHY internal clock
  arm: dts: st: fix DSI peripheral clock on stm32mp15 boards

Yannick Fertre (1):
  drm/stm: dsi: add pm runtime ops

 arch/arm/boot/dts/st/stm32mp157.dtsi          |   2 +-
 arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts |   2 +-
 arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts |   2 +-
 arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts |   2 +-
 arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts |   2 +-
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c         | 278 +++++++++++++++---
 6 files changed, 242 insertions(+), 46 deletions(-)

-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Mon Dec  4 02:11:10 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Mon, 4 Dec 2023 11:11:10 +0100
Subject: [PATCH v2 1/4] drm/stm: dsi: use new SYSTEM_SLEEP_PM_OPS() macro
In-Reply-To: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>
References: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231204101113.276368-2-raphael.gallais-pou@foss.st.com>

Use RUNTIME_PM_OPS() instead of the old SET_SYSTEM_SLEEP_PM_OPS().
This means we don't need  __maybe_unused on the functions.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index d5f8c923d7bc..b1aee43d51e9 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -544,7 +544,7 @@ static void dw_mipi_dsi_stm_remove(struct platform_device *pdev)
 	regulator_disable(dsi->vdd_supply);
 }
 
-static int __maybe_unused dw_mipi_dsi_stm_suspend(struct device *dev)
+static int dw_mipi_dsi_stm_suspend(struct device *dev)
 {
 	struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
 
@@ -556,7 +556,7 @@ static int __maybe_unused dw_mipi_dsi_stm_suspend(struct device *dev)
 	return 0;
 }
 
-static int __maybe_unused dw_mipi_dsi_stm_resume(struct device *dev)
+static int dw_mipi_dsi_stm_resume(struct device *dev)
 {
 	struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
 	int ret;
@@ -580,8 +580,8 @@ static int __maybe_unused dw_mipi_dsi_stm_resume(struct device *dev)
 }
 
 static const struct dev_pm_ops dw_mipi_dsi_stm_pm_ops = {
-	SET_SYSTEM_SLEEP_PM_OPS(dw_mipi_dsi_stm_suspend,
-				dw_mipi_dsi_stm_resume)
+	SYSTEM_SLEEP_PM_OPS(dw_mipi_dsi_stm_suspend,
+			    dw_mipi_dsi_stm_resume)
 };
 
 static struct platform_driver dw_mipi_dsi_stm_driver = {
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Mon Dec  4 02:11:12 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Mon, 4 Dec 2023 11:11:12 +0100
Subject: [PATCH v2 3/4] drm/stm: dsi: expose DSI PHY internal clock
In-Reply-To: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>
References: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231204101113.276368-4-raphael.gallais-pou@foss.st.com>

	DSISRC __________
	               __\_
	              |    \
	pll4_p_ck   ->|  1  |____dsi_k
	ck_dsi_phy  ->|  0  |
	              |____/

A DSI clock is missing in the clock framework. Looking at the
clk_summary, it appears that 'ck_dsi_phy' is not implemented. Since the
DSI kernel clock is based on the internal DSI pll. The common clock
driver can not directly expose this 'ck_dsi_phy' clock because it does
not contain any common registers with the DSI. Thus it needs to be done
directly within the DSI phy driver.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 246 ++++++++++++++++++++++----
 1 file changed, 215 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 82fff9e84345..283f546a7198 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -7,7 +7,9 @@
  */
 
 #include <linux/clk.h>
+#include <linux/clk-provider.h>
 #include <linux/iopoll.h>
+#include <linux/kernel.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
@@ -77,9 +79,12 @@ enum dsi_color {
 
 struct dw_mipi_dsi_stm {
 	void __iomem *base;
+	struct device *dev;
 	struct clk *pllref_clk;
 	struct clk *pclk;
+	struct clk_hw txbyte_clk;
 	struct dw_mipi_dsi *dsi;
+	struct dw_mipi_dsi_plat_data pdata;
 	u32 hw_version;
 	int lane_min_kbps;
 	int lane_max_kbps;
@@ -196,29 +201,198 @@ static int dsi_pll_get_params(struct dw_mipi_dsi_stm *dsi,
 	return 0;
 }
 
-static int dw_mipi_dsi_phy_init(void *priv_data)
+#define clk_to_dw_mipi_dsi_stm(clk) \
+	container_of(clk, struct dw_mipi_dsi_stm, txbyte_clk)
+
+static void dw_mipi_dsi_clk_disable(struct clk_hw *clk)
 {
-	struct dw_mipi_dsi_stm *dsi = priv_data;
+	struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(clk);
+
+	DRM_DEBUG_DRIVER("\n");
+
+	/* Disable the DSI PLL */
+	dsi_clear(dsi, DSI_WRPCR, WRPCR_PLLEN);
+
+	/* Disable the regulator */
+	dsi_clear(dsi, DSI_WRPCR, WRPCR_REGEN | WRPCR_BGREN);
+}
+
+static int dw_mipi_dsi_clk_enable(struct clk_hw *clk)
+{
+	struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(clk);
 	u32 val;
 	int ret;
 
+	DRM_DEBUG_DRIVER("\n");
+
 	/* Enable the regulator */
 	dsi_set(dsi, DSI_WRPCR, WRPCR_REGEN | WRPCR_BGREN);
-	ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
-				 SLEEP_US, TIMEOUT_US);
+	ret = readl_poll_timeout_atomic(dsi->base + DSI_WISR, val, val & WISR_RRS,
+					SLEEP_US, TIMEOUT_US);
 	if (ret)
 		DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
 
 	/* Enable the DSI PLL & wait for its lock */
 	dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
-	ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
-				 SLEEP_US, TIMEOUT_US);
+	ret = readl_poll_timeout_atomic(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
+					SLEEP_US, TIMEOUT_US);
 	if (ret)
 		DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
 
 	return 0;
 }
 
+static int dw_mipi_dsi_clk_is_enabled(struct clk_hw *hw)
+{
+	struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+
+	return dsi_read(dsi, DSI_WRPCR) & WRPCR_PLLEN;
+}
+
+static unsigned long dw_mipi_dsi_clk_recalc_rate(struct clk_hw *hw,
+						 unsigned long parent_rate)
+{
+	struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+	unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+	u32 val;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	pll_in_khz = (unsigned int)(parent_rate / 1000);
+
+	val = dsi_read(dsi, DSI_WRPCR);
+
+	idf = (val & WRPCR_IDF) >> 11;
+	if (!idf)
+		idf = 1;
+	ndiv = (val & WRPCR_NDIV) >> 2;
+	odf = int_pow(2, (val & WRPCR_ODF) >> 16);
+
+	/* Get the adjusted pll out value */
+	pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
+
+	return (unsigned long)pll_out_khz * 1000;
+}
+
+static long dw_mipi_dsi_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+				       unsigned long *parent_rate)
+{
+	struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+	unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+	int ret;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	pll_in_khz = (unsigned int)(*parent_rate / 1000);
+
+	/* Compute best pll parameters */
+	idf = 0;
+	ndiv = 0;
+	odf = 0;
+
+	ret = dsi_pll_get_params(dsi, pll_in_khz, rate / 1000,
+				 &idf, &ndiv, &odf);
+	if (ret)
+		DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
+
+	/* Get the adjusted pll out value */
+	pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
+
+	return pll_out_khz * 1000;
+}
+
+static int dw_mipi_dsi_clk_set_rate(struct clk_hw *hw, unsigned long rate,
+				    unsigned long parent_rate)
+{
+	struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+	unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+	int ret;
+	u32 val;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	pll_in_khz = (unsigned int)(parent_rate / 1000);
+
+	/* Compute best pll parameters */
+	idf = 0;
+	ndiv = 0;
+	odf = 0;
+
+	ret = dsi_pll_get_params(dsi, pll_in_khz, rate / 1000, &idf, &ndiv, &odf);
+	if (ret)
+		DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
+
+	/* Get the adjusted pll out value */
+	pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
+
+	/* Set the PLL division factors */
+	dsi_update_bits(dsi, DSI_WRPCR,	WRPCR_NDIV | WRPCR_IDF | WRPCR_ODF,
+			(ndiv << 2) | (idf << 11) | ((ffs(odf) - 1) << 16));
+
+	/* Compute uix4 & set the bit period in high-speed mode */
+	val = 4000000 / pll_out_khz;
+	dsi_update_bits(dsi, DSI_WPCR0, WPCR0_UIX4, val);
+
+	return 0;
+}
+
+static void dw_mipi_dsi_clk_unregister(void *data)
+{
+	struct dw_mipi_dsi_stm *dsi = data;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	of_clk_del_provider(dsi->dev->of_node);
+	clk_hw_unregister(&dsi->txbyte_clk);
+}
+
+static const struct clk_ops dw_mipi_dsi_stm_clk_ops = {
+	.enable = dw_mipi_dsi_clk_enable,
+	.disable = dw_mipi_dsi_clk_disable,
+	.is_enabled = dw_mipi_dsi_clk_is_enabled,
+	.recalc_rate = dw_mipi_dsi_clk_recalc_rate,
+	.round_rate = dw_mipi_dsi_clk_round_rate,
+	.set_rate = dw_mipi_dsi_clk_set_rate,
+};
+
+static struct clk_init_data cdata_init = {
+	.name = "ck_dsi_phy",
+	.ops = &dw_mipi_dsi_stm_clk_ops,
+	.parent_names = (const char * []) {"ck_hse"},
+	.num_parents = 1,
+};
+
+static int dw_mipi_dsi_clk_register(struct dw_mipi_dsi_stm *dsi,
+				    struct device *dev)
+{
+	struct device_node *node = dev->of_node;
+	int ret;
+
+	DRM_DEBUG_DRIVER("Registering clk\n");
+
+	dsi->txbyte_clk.init = &cdata_init;
+
+	ret = clk_hw_register(dev, &dsi->txbyte_clk);
+	if (ret)
+		return ret;
+
+	ret = of_clk_add_hw_provider(node, of_clk_hw_simple_get,
+				     &dsi->txbyte_clk);
+	if (ret)
+		clk_hw_unregister(&dsi->txbyte_clk);
+
+	return ret;
+}
+
+static int dw_mipi_dsi_phy_init(void *priv_data)
+{
+	struct dw_mipi_dsi_stm *dsi = priv_data;
+	int ret;
+
+	ret = clk_prepare_enable(dsi->txbyte_clk.clk);
+	return ret;
+}
+
 static void dw_mipi_dsi_phy_power_on(void *priv_data)
 {
 	struct dw_mipi_dsi_stm *dsi = priv_data;
@@ -235,6 +409,8 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
 
 	DRM_DEBUG_DRIVER("\n");
 
+	clk_disable_unprepare(dsi->txbyte_clk.clk);
+
 	/* Disable the DSI wrapper */
 	dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
 }
@@ -245,9 +421,8 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
 			  unsigned int *lane_mbps)
 {
 	struct dw_mipi_dsi_stm *dsi = priv_data;
-	unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+	unsigned int pll_in_khz, pll_out_khz;
 	int ret, bpp;
-	u32 val;
 
 	pll_in_khz = (unsigned int)(clk_get_rate(dsi->pllref_clk) / 1000);
 
@@ -268,25 +443,10 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
 		DRM_WARN("Warning min phy mbps is used\n");
 	}
 
-	/* Compute best pll parameters */
-	idf = 0;
-	ndiv = 0;
-	odf = 0;
-	ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
-				 &idf, &ndiv, &odf);
+	ret = clk_set_rate((dsi->txbyte_clk.clk), pll_out_khz * 1000);
 	if (ret)
-		DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
-
-	/* Get the adjusted pll out value */
-	pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
-
-	/* Set the PLL division factors */
-	dsi_update_bits(dsi, DSI_WRPCR,	WRPCR_NDIV | WRPCR_IDF | WRPCR_ODF,
-			(ndiv << 2) | (idf << 11) | ((ffs(odf) - 1) << 16));
-
-	/* Compute uix4 & set the bit period in high-speed mode */
-	val = 4000000 / pll_out_khz;
-	dsi_update_bits(dsi, DSI_WPCR0, WPCR0_UIX4, val);
+		DRM_DEBUG_DRIVER("ERROR Could not set rate of %d to %s clk->name",
+				 pll_out_khz, clk_hw_get_name(&dsi->txbyte_clk));
 
 	/* Select video mode by resetting DSIM bit */
 	dsi_clear(dsi, DSI_WCFGR, WCFGR_DSIM);
@@ -445,6 +605,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct dw_mipi_dsi_stm *dsi;
+	const struct dw_mipi_dsi_plat_data *pdata = of_device_get_match_data(dev);
 	int ret;
 
 	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
@@ -514,18 +675,40 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
 		dsi->lane_max_kbps *= 2;
 	}
 
-	dw_mipi_dsi_stm_plat_data.base = dsi->base;
-	dw_mipi_dsi_stm_plat_data.priv_data = dsi;
+	dsi->pdata = *pdata;
+	dsi->pdata.base = dsi->base;
+	dsi->pdata.priv_data = dsi;
+
+	dsi->pdata.max_data_lanes = 2;
+	dsi->pdata.phy_ops = &dw_mipi_dsi_stm_phy_ops;
 
 	platform_set_drvdata(pdev, dsi);
 
-	dsi->dsi = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
+	dsi->dsi = dw_mipi_dsi_probe(pdev, &dsi->pdata);
 	if (IS_ERR(dsi->dsi)) {
 		ret = PTR_ERR(dsi->dsi);
 		dev_err_probe(dev, ret, "Failed to initialize mipi dsi host\n");
 		goto err_dsi_probe;
 	}
 
+	/*
+	 * We need to wait for the generic bridge to probe before enabling and
+	 * register the internal pixel clock.
+	 */
+	ret = clk_prepare_enable(dsi->pclk);
+	if (ret) {
+		DRM_ERROR("%s: Failed to enable peripheral clk\n", __func__);
+		goto err_dsi_probe;
+	}
+
+	ret = dw_mipi_dsi_clk_register(dsi, dev);
+	if (ret) {
+		DRM_ERROR("Failed to register DSI pixel clock: %d\n", ret);
+		goto err_dsi_probe;
+	}
+
+	clk_disable_unprepare(dsi->pclk);
+
 	return 0;
 
 err_dsi_probe:
@@ -542,12 +725,13 @@ static void dw_mipi_dsi_stm_remove(struct platform_device *pdev)
 
 	dw_mipi_dsi_remove(dsi->dsi);
 	clk_disable_unprepare(dsi->pllref_clk);
+	dw_mipi_dsi_clk_unregister(dsi);
 	regulator_disable(dsi->vdd_supply);
 }
 
 static int dw_mipi_dsi_stm_suspend(struct device *dev)
 {
-	struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
+	struct dw_mipi_dsi_stm *dsi = dev_get_drvdata(dev);
 
 	DRM_DEBUG_DRIVER("\n");
 
@@ -560,7 +744,7 @@ static int dw_mipi_dsi_stm_suspend(struct device *dev)
 
 static int dw_mipi_dsi_stm_resume(struct device *dev)
 {
-	struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
+	struct dw_mipi_dsi_stm *dsi = dev_get_drvdata(dev);
 	int ret;
 
 	DRM_DEBUG_DRIVER("\n");
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Mon Dec  4 02:11:13 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Mon, 4 Dec 2023 11:11:13 +0100
Subject: [PATCH v2 4/4] arm: dts: st: fix DSI peripheral clock on stm32mp15 boards
In-Reply-To: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>
References: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231204101113.276368-5-raphael.gallais-pou@foss.st.com>

In RCC driver, 'DSI_K' is a kernel clock while 'DSI' has pclk4 as parent
clock, which means that it is an APB peripheral clock. Swap the clocks
in the DSI peripheral clock reference.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 arch/arm/boot/dts/st/stm32mp157.dtsi          | 2 +-
 arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts | 2 +-
 arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts | 2 +-
 arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts | 2 +-
 arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/st/stm32mp157.dtsi b/arch/arm/boot/dts/st/stm32mp157.dtsi
index 6197d878894d..97cd24227cef 100644
--- a/arch/arm/boot/dts/st/stm32mp157.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp157.dtsi
@@ -20,7 +20,7 @@ gpu: gpu at 59000000 {
 		dsi: dsi at 5a000000 {
 			compatible = "st,stm32-dsi";
 			reg = <0x5a000000 0x800>;
-			clocks = <&rcc DSI_K>, <&clk_hse>, <&rcc DSI_PX>;
+			clocks = <&rcc DSI>, <&clk_hse>, <&rcc DSI_PX>;
 			clock-names = "pclk", "ref", "px_clk";
 			phy-dsi-supply = <&reg18>;
 			resets = <&rcc DSI_R>;
diff --git a/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts b/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
index afcd6285890c..8634699cc65e 100644
--- a/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
@@ -30,7 +30,7 @@ &cpu1 {
 };
 
 &dsi {
-	clocks = <&rcc DSI_K>, <&scmi_clk CK_SCMI_HSE>, <&rcc DSI_PX>;
+	clocks = <&rcc DSI>, <&scmi_clk CK_SCMI_HSE>, <&rcc DSI_PX>;
 };
 
 &gpioz {
diff --git a/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts b/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
index 39358d902000..3a897fa7e167 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
@@ -36,7 +36,7 @@ &cryp1 {
 
 &dsi {
 	phy-dsi-supply = <&scmi_reg18>;
-	clocks = <&rcc DSI_K>, <&scmi_clk CK_SCMI_HSE>, <&rcc DSI_PX>;
+	clocks = <&rcc DSI>, <&scmi_clk CK_SCMI_HSE>, <&rcc DSI_PX>;
 };
 
 &gpioz {
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts b/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
index 07ea765a4553..29d6465b1fe6 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
@@ -35,7 +35,7 @@ &cryp1 {
 };
 
 &dsi {
-	clocks = <&rcc DSI_K>, <&scmi_clk CK_SCMI_HSE>, <&rcc DSI_PX>;
+	clocks = <&rcc DSI>, <&scmi_clk CK_SCMI_HSE>, <&rcc DSI_PX>;
 };
 
 &gpioz {
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts b/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
index 813086ec2489..5acb78f0a084 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
@@ -37,7 +37,7 @@ &cryp1 {
 
 &dsi {
 	phy-dsi-supply = <&scmi_reg18>;
-	clocks = <&rcc DSI_K>, <&scmi_clk CK_SCMI_HSE>, <&rcc DSI_PX>;
+	clocks = <&rcc DSI>, <&scmi_clk CK_SCMI_HSE>, <&rcc DSI_PX>;
 };
 
 &gpioz {
-- 
2.25.1



From hawk at kernel.org  Mon Dec  4 02:16:48 2023
From: hawk at kernel.org (Jesper Dangaard Brouer)
Date: Mon, 4 Dec 2023 11:16:48 +0100
Subject: [PATCH bpf-next v3 3/3] selftests/bpf: add Launch Time request to
 xdp_hw_metadata
In-Reply-To: <20231203165129.1740512-4-yoong.siang.song@intel.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-4-yoong.siang.song@intel.com>
Message-ID: <8e20031c-83cb-4927-ab6a-e6b4840e1e42@kernel.org>



On 12/3/23 17:51, Song Yoong Siang wrote:
> This patch is tested with stmmac on Intel Tiger Lake platform. Refer to
> result below, the delta between pre-determined launch time and actual HW
> transmit complete time is around 24 us.

Is there any NIC setup (e.g. ethtool/qdisc) requirements to enable HW 
for this feature?

--Jesper


From ryan.roberts at arm.com  Mon Dec  4 02:20:17 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:17 +0000
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
Message-ID: <20231204102027.57185-1-ryan.roberts@arm.com>

Hi All,

A new week, a new version, a new name... This is v8 of a series to implement
multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
and "large anonymous folios"). Matthew objected to "small huge" so hopefully
this fares better.

The objective of this is to improve performance by allocating larger chunks of
memory during anonymous page faults:

1) Since SW (the kernel) is dealing with larger chunks of memory than base
   pages, there are efficiency savings to be had; fewer page faults, batched PTE
   and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
   overhead. This should benefit all architectures.
2) Since we are now mapping physically contiguous chunks of memory, we can take
   advantage of HW TLB compression techniques. A reduction in TLB pressure
   speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
   TLB entries; "the contiguous bit" (architectural) and HPA (uarch).

This version changes the name and tidies up some of the kernel code and test
code, based on feedback against v7 (see change log for details).

By default, the existing behaviour (and performance) is maintained. The user
must explicitly enable multi-size THP to see the performance benefit. This is
done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
David for the suggestion)! This interface is inspired by the existing
per-hugepage-size sysfs interface used by hugetlb, provides full backwards
compatibility with the existing PMD-size THP interface, and provides a base for
future extensibility. See [8] for detailed discussion of the interface.

This series is based on mm-unstable (715b67adf4c8).


Prerequisites
=============

Some work items identified as being prerequisites are listed on page 3 at [9].
The summary is:

| item                          | status                  |
|:------------------------------|:------------------------|
| mlock                         | In mainline (v6.7)      |
| madvise                       | In mainline (v6.6)      |
| compaction                    | v1 posted [10]          |
| numa balancing                | Investigated: see below |
| user-triggered page migration | In mainline (v6.7)      |
| khugepaged collapse           | In mainline (NOP)       |

On NUMA balancing, which currently ignores any PTE-mapped THPs it encounters,
John Hubbard has investigated this and concluded that it is A) not clear at the
moment what a better policy might be for PTE-mapped THP and B) questions whether
this should really be considered a prerequisite given no regression is caused
for the default "multi-size THP disabled" case, and there is no correctness
issue when it is enabled - its just a potential for non-optimal performance.

If there are no disagreements about removing numa balancing from the list (none
were raised when I first posted this comment against v7), then that just leaves
compaction which is in review on list at the moment.

I really would like to get this series (and its remaining comapction
prerequisite) in for v6.8. I accept that it may be a bit optimistic at this
point, but lets see where we get to with review?


Testing
=======

The series includes patches for mm selftests to enlighten the cow and khugepaged
tests to explicitly test with multi-size THP, in the same way that PMD-sized
THP is tested. The new tests all pass, and no regressions are observed in the mm
selftest suite. I've also run my usual kernel compilation and java script
benchmarks without any issues.

Refer to my performance numbers posted with v6 [6]. (These are for multi-size
THP only - they do not include the arm64 contpte follow-on series).

John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
some workloads at [11]. (Observed using v6 of this series as well as the arm64
contpte series).

Kefeng Wang at Huawei has also indicated he sees improvements at [12] although
there are some latency regressions also.


Changes since v7 [7]
====================

  - Renamed "small-sized THP" -> "multi-size THP" in commit logs
  - Added various Reviewed-by/Tested-by tags (Barry, David, Alistair)
  - Patch 3:
      - Fine-tuned transhuge documentation multi-size THP (JohnH)
      - Converted hugepage_global_enabled() and hugepage_global_always() macros
        to static inline functions (JohnH)
      - Renamed hugepage_vma_check() to thp_vma_allowable_orders() (JohnH)
      - Renamed transhuge_vma_suitable() to thp_vma_suitable_orders() (JohnH)
      - Renamed "global" enabled sysfs file option to "inherit" (JohnH)
  - Patch 9:
      - cow selftest: Renamed param size -> thpsize (David)
      - cow selftest: Changed test fail to assert() (David)
      - cow selftest: Log PMD size separately from all the supported THP sizes
        (David)
  - Patch 10:
      - cow selftest: No longer special case pmdsize; keep all THP sizes in
        thpsizes[]


Changes since v6 [6]
====================

  - Refactored vmf_pte_range_changed() to remove uffd special-case (suggested by
    JohnH)
  - Dropped accounting patch (#3 in v6) (suggested by DavidH)
      - Continue to account *PMD-sized* THP only for now
      - Can add more counters in future if needed
      - Page cache large folios haven't needed any new counters yet
  - Pivot to sysfs ABI proposed by DavidH
      - per-size directories in a similar shape to that used by hugetlb
  - Dropped "recommend" keyword patch (#6 in v6) (suggested by DavidH, Yu Zhou)
      - For now, users need to understand implicitly which sizes are beneficial
        to their HW/SW
  - Dropped arch_wants_pte_order() patch (#7 in v6)
      - No longer needed due to dropping patch "recommend" keyword patch
  - Enlightened khugepaged mm selftest to explicitly test with small-size THP
  - Scrubbed commit logs to use "small-sized THP" consistently (suggested by
    DavidH)


Changes since v5 [5]
====================

  - Added accounting for PTE-mapped THPs (patch 3)
  - Added runtime control mechanism via sysfs as extension to THP (patch 4)
  - Minor refactoring of alloc_anon_folio() to integrate with runtime controls
  - Stripped out hardcoded policy for allocation order; its now all user space
    controlled (although user space can request "recommend" which will configure
    the HW-preferred order)


Changes since v4 [4]
====================

  - Removed "arm64: mm: Override arch_wants_pte_order()" patch; arm64
    now uses the default order-3 size. I have moved this patch over to
    the contpte series.
  - Added "mm: Allow deferred splitting of arbitrary large anon folios" back
    into series. I originally removed this at v2 to add to a separate series,
    but that series has transformed significantly and it no longer fits, so
    bringing it back here.
  - Reintroduced dependency on set_ptes(); Originally dropped this at v2, but
    set_ptes() is in mm-unstable now.
  - Updated policy for when to allocate LAF; only fallback to order-0 if
    MADV_NOHUGEPAGE is present or if THP disabled via prctl; no longer rely on
    sysfs's never/madvise/always knob.
  - Fallback to order-0 whenever uffd is armed for the vma, not just when
    uffd-wp is set on the pte.
  - alloc_anon_folio() now returns `struct folio *`, where errors are encoded
    with ERR_PTR().

  The last 3 changes were proposed by Yu Zhao - thanks!


Changes since v3 [3]
====================

  - Renamed feature from FLEXIBLE_THP to LARGE_ANON_FOLIO.
  - Removed `flexthp_unhinted_max` boot parameter. Discussion concluded that a
    sysctl is preferable but we will wait until real workload needs it.
  - Fixed uninitialized `addr` on read fault path in do_anonymous_page().
  - Added mm selftests for large anon folios in cow test suite.


Changes since v2 [2]
====================

  - Dropped commit "Allow deferred splitting of arbitrary large anon folios"
      - Huang, Ying suggested the "batch zap" work (which I dropped from this
        series after v1) is a prerequisite for merging FLXEIBLE_THP, so I've
        moved the deferred split patch to a separate series along with the batch
        zap changes. I plan to submit this series early next week.
  - Changed folio order fallback policy
      - We no longer iterate from preferred to 0 looking for acceptable policy
      - Instead we iterate through preferred, PAGE_ALLOC_COSTLY_ORDER and 0 only
  - Removed vma parameter from arch_wants_pte_order()
  - Added command line parameter `flexthp_unhinted_max`
      - clamps preferred order when vma hasn't explicitly opted-in to THP
  - Never allocate large folio for MADV_NOHUGEPAGE vma (or when THP is disabled
    for process or system).
  - Simplified implementation and integration with do_anonymous_page()
  - Removed dependency on set_ptes()


Changes since v1 [1]
====================

  - removed changes to arch-dependent vma_alloc_zeroed_movable_folio()
  - replaced with arch-independent alloc_anon_folio()
      - follows THP allocation approach
  - no longer retry with intermediate orders if allocation fails
      - fallback directly to order-0
  - remove folio_add_new_anon_rmap_range() patch
      - instead add its new functionality to folio_add_new_anon_rmap()
  - remove batch-zap pte mappings optimization patch
      - remove enabler folio_remove_rmap_range() patch too
      - These offer real perf improvement so will submit separately
  - simplify Kconfig
      - single FLEXIBLE_THP option, which is independent of arch
      - depends on TRANSPARENT_HUGEPAGE
      - when enabled default to max anon folio size of 64K unless arch
        explicitly overrides
  - simplify changes to do_anonymous_page():
      - no more retry loop


[1] https://lore.kernel.org/linux-mm/20230626171430.3167004-1-ryan.roberts at arm.com/
[2] https://lore.kernel.org/linux-mm/20230703135330.1865927-1-ryan.roberts at arm.com/
[3] https://lore.kernel.org/linux-mm/20230714160407.4142030-1-ryan.roberts at arm.com/
[4] https://lore.kernel.org/linux-mm/20230726095146.2826796-1-ryan.roberts at arm.com/
[5] https://lore.kernel.org/linux-mm/20230810142942.3169679-1-ryan.roberts at arm.com/
[6] https://lore.kernel.org/linux-mm/20230929114421.3761121-1-ryan.roberts at arm.com/
[7] https://lore.kernel.org/linux-mm/20231122162950.3854897-1-ryan.roberts at arm.com/
[8] https://lore.kernel.org/linux-mm/6d89fdc9-ef55-d44e-bf12-fafff318aef8 at redhat.com/
[9] https://drive.google.com/file/d/1GnfYFpr7_c1kA41liRUW5YtCb8Cj18Ud/view?usp=sharing&resourcekey=0-U1Mj3-RhLD1JV6EThpyPyA
[10] https://lore.kernel.org/linux-mm/20231113170157.280181-1-zi.yan at sent.com/
[11] https://lore.kernel.org/linux-mm/c507308d-bdd4-5f9e-d4ff-e96e4520be85 at nvidia.com/
[12] https://lore.kernel.org/linux-mm/479b3e2b-456d-46c1-9677-38f6c95a0be8 at huawei.com/


Thanks,
Ryan

Ryan Roberts (10):
  mm: Allow deferred splitting of arbitrary anon large folios
  mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()
  mm: thp: Introduce multi-size THP sysfs interface
  mm: thp: Support allocation of anonymous multi-size THP
  selftests/mm/kugepaged: Restore thp settings at exit
  selftests/mm: Factor out thp settings management
  selftests/mm: Support multi-size THP interface in thp_settings
  selftests/mm/khugepaged: Enlighten for multi-size THP
  selftests/mm/cow: Generalize do_run_with_thp() helper
  selftests/mm/cow: Add tests for anonymous multi-size THP

 Documentation/admin-guide/mm/transhuge.rst |  97 ++++-
 Documentation/filesystems/proc.rst         |   6 +-
 fs/proc/task_mmu.c                         |   3 +-
 include/linux/huge_mm.h                    | 116 ++++--
 mm/huge_memory.c                           | 268 ++++++++++++--
 mm/khugepaged.c                            |  20 +-
 mm/memory.c                                | 114 +++++-
 mm/page_vma_mapped.c                       |   3 +-
 mm/rmap.c                                  |  32 +-
 tools/testing/selftests/mm/Makefile        |   4 +-
 tools/testing/selftests/mm/cow.c           | 185 +++++++---
 tools/testing/selftests/mm/khugepaged.c    | 410 ++++-----------------
 tools/testing/selftests/mm/run_vmtests.sh  |   2 +
 tools/testing/selftests/mm/thp_settings.c  | 349 ++++++++++++++++++
 tools/testing/selftests/mm/thp_settings.h  |  80 ++++
 15 files changed, 1177 insertions(+), 512 deletions(-)
 create mode 100644 tools/testing/selftests/mm/thp_settings.c
 create mode 100644 tools/testing/selftests/mm/thp_settings.h

--
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:20 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:20 +0000
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs interface
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-4-ryan.roberts@arm.com>

In preparation for adding support for anonymous multi-size THP,
introduce new sysfs structure that will be used to control the new
behaviours. A new directory is added under transparent_hugepage for each
supported THP size, and contains an `enabled` file, which can be set to
"inherit" (to inherit the global setting), "always", "madvise" or
"never". For now, the kernel still only supports PMD-sized anonymous
THP, so only 1 directory is populated.

The first half of the change converts transhuge_vma_suitable() and
hugepage_vma_check() so that they take a bitfield of orders for which
the user wants to determine support, and the functions filter out all
the orders that can't be supported, given the current sysfs
configuration and the VMA dimensions. If there is only 1 order set in
the input then the output can continue to be treated like a boolean;
this is the case for most call sites. The resulting functions are
renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
respectively.

The second half of the change implements the new sysfs interface. It has
been done so that each supported THP size has a `struct thpsize`, which
describes the relevant metadata and is itself a kobject. This is pretty
minimal for now, but should make it easy to add new per-thpsize files to
the interface if needed in future (e.g. per-size defrag). Rather than
keep the `enabled` state directly in the struct thpsize, I've elected to
directly encode it into huge_anon_orders_[always|madvise|inherit]
bitfields since this reduces the amount of work required in
thp_vma_allowable_orders() which is called for every page fault.

See Documentation/admin-guide/mm/transhuge.rst, as modified by this
commit, for details of how the new sysfs interface works.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 Documentation/admin-guide/mm/transhuge.rst |  97 ++++++--
 Documentation/filesystems/proc.rst         |   6 +-
 fs/proc/task_mmu.c                         |   3 +-
 include/linux/huge_mm.h                    | 114 ++++++---
 mm/huge_memory.c                           | 268 +++++++++++++++++++--
 mm/khugepaged.c                            |  20 +-
 mm/memory.c                                |   8 +-
 mm/page_vma_mapped.c                       |   3 +-
 8 files changed, 423 insertions(+), 96 deletions(-)

diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
index b0cc8243e093..04eb45a2f940 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -45,10 +45,25 @@ components:
    the two is using hugepages just because of the fact the TLB miss is
    going to run faster.
 
+Modern kernels support "multi-size THP" (mTHP), which introduces the
+ability to allocate memory in blocks that are bigger than a base page
+but smaller than traditional PMD-size (as described above), in
+increments of a power-of-2 number of pages. mTHP can back anonymous
+memory (for example 16K, 32K, 64K, etc). These THPs continue to be
+PTE-mapped, but in many cases can still provide similar benefits to
+those outlined above: Page faults are significantly reduced (by a
+factor of e.g. 4, 8, 16, etc), but latency spikes are much less
+prominent because the size of each page isn't as huge as the PMD-sized
+variant and there is less memory to clear in each page fault. Some
+architectures also employ TLB compression mechanisms to squeeze more
+entries in when a set of PTEs are virtually and physically contiguous
+and approporiately aligned. In this case, TLB misses will occur less
+often.
+
 THP can be enabled system wide or restricted to certain tasks or even
 memory ranges inside task's address space. Unless THP is completely
 disabled, there is ``khugepaged`` daemon that scans memory and
-collapses sequences of basic pages into huge pages.
+collapses sequences of basic pages into PMD-sized huge pages.
 
 The THP behaviour is controlled via :ref:`sysfs <thp_sysfs>`
 interface and using madvise(2) and prctl(2) system calls.
@@ -95,12 +110,40 @@ Global THP controls
 Transparent Hugepage Support for anonymous memory can be entirely disabled
 (mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE
 regions (to avoid the risk of consuming more memory resources) or enabled
-system wide. This can be achieved with one of::
+system wide. This can be achieved per-supported-THP-size with one of::
+
+	echo always >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+	echo madvise >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+	echo never >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+
+where <size> is the hugepage size being addressed, the available sizes
+for which vary by system.
+
+For example::
+
+	echo always >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
+
+Alternatively it is possible to specify that a given hugepage size
+will inherit the top-level "enabled" value::
+
+	echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+
+For example::
+
+	echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
+
+The top-level setting (for use with "inherit") can be set by issuing
+one of the following commands::
 
 	echo always >/sys/kernel/mm/transparent_hugepage/enabled
 	echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
 	echo never >/sys/kernel/mm/transparent_hugepage/enabled
 
+By default, PMD-sized hugepages have enabled="inherit" and all other
+hugepage sizes have enabled="never". If enabling multiple hugepage
+sizes, the kernel will select the most appropriate enabled size for a
+given allocation.
+
 It's also possible to limit defrag efforts in the VM to generate
 anonymous hugepages in case they're not immediately free to madvise
 regions or to never try to defrag memory and simply fallback to regular
@@ -146,25 +189,34 @@ madvise
 never
 	should be self-explanatory.
 
-By default kernel tries to use huge zero page on read page fault to
-anonymous mapping. It's possible to disable huge zero page by writing 0
-or enable it back by writing 1::
+By default kernel tries to use huge, PMD-mappable zero page on read
+page fault to anonymous mapping. It's possible to disable huge zero
+page by writing 0 or enable it back by writing 1::
 
 	echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page
 	echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
 
-Some userspace (such as a test program, or an optimized memory allocation
-library) may want to know the size (in bytes) of a transparent hugepage::
+Some userspace (such as a test program, or an optimized memory
+allocation library) may want to know the size (in bytes) of a
+PMD-mappable transparent hugepage::
 
 	cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
 
-khugepaged will be automatically started when
-transparent_hugepage/enabled is set to "always" or "madvise, and it'll
-be automatically shutdown if it's set to "never".
+khugepaged will be automatically started when one or more hugepage
+sizes are enabled (either by directly setting "always" or "madvise",
+or by setting "inherit" while the top-level enabled is set to "always"
+or "madvise"), and it'll be automatically shutdown when the last
+hugepage size is disabled (either by directly setting "never", or by
+setting "inherit" while the top-level enabled is set to "never").
 
 Khugepaged controls
 -------------------
 
+.. note::
+   khugepaged currently only searches for opportunities to collapse to
+   PMD-sized THP and no attempt is made to collapse to other THP
+   sizes.
+
 khugepaged runs usually at low frequency so while one may not want to
 invoke defrag algorithms synchronously during the page faults, it
 should be worth invoking defrag at least in khugepaged. However it's
@@ -282,19 +334,26 @@ force
 Need of application restart
 ===========================
 
-The transparent_hugepage/enabled values and tmpfs mount option only affect
-future behavior. So to make them effective you need to restart any
-application that could have been using hugepages. This also applies to the
-regions registered in khugepaged.
+The transparent_hugepage/enabled and
+transparent_hugepage/hugepages-<size>kB/enabled values and tmpfs mount
+option only affect future behavior. So to make them effective you need
+to restart any application that could have been using hugepages. This
+also applies to the regions registered in khugepaged.
 
 Monitoring usage
 ================
 
-The number of anonymous transparent huge pages currently used by the
+.. note::
+   Currently the below counters only record events relating to
+   PMD-sized THP. Events relating to other THP sizes are not included.
+
+The number of PMD-sized anonymous transparent huge pages currently used by the
 system is available by reading the AnonHugePages field in ``/proc/meminfo``.
-To identify what applications are using anonymous transparent huge pages,
-it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages fields
-for each mapping.
+To identify what applications are using PMD-sized anonymous transparent huge
+pages, it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages
+fields for each mapping. (Note that AnonHugePages only applies to traditional
+PMD-sized THP for historical reasons and should have been called
+AnonHugePmdMapped).
 
 The number of file transparent huge pages mapped to userspace is available
 by reading ShmemPmdMapped and ShmemHugePages fields in ``/proc/meminfo``.
@@ -413,7 +472,7 @@ for huge pages.
 Optimizing the applications
 ===========================
 
-To be guaranteed that the kernel will map a 2M page immediately in any
+To be guaranteed that the kernel will map a THP immediately in any
 memory region, the mmap region has to be hugepage naturally
 aligned. posix_memalign() can provide that guarantee.
 
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 49ef12df631b..104c6d047d9b 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -528,9 +528,9 @@ replaced by copy-on-write) part of the underlying shmem object out on swap.
 does not take into account swapped out page of underlying shmem objects.
 "Locked" indicates whether the mapping is locked in memory or not.
 
-"THPeligible" indicates whether the mapping is eligible for allocating THP
-pages as well as the THP is PMD mappable or not - 1 if true, 0 otherwise.
-It just shows the current status.
+"THPeligible" indicates whether the mapping is eligible for allocating
+naturally aligned THP pages of any currently enabled size. 1 if true, 0
+otherwise.
 
 "VmFlags" field deserves a separate description. This member represents the
 kernel flags associated with the particular virtual memory area in two letter
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index d19924bf0a39..79855e1c5b57 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -865,7 +865,8 @@ static int show_smap(struct seq_file *m, void *v)
 	__show_smap(m, &mss, false);
 
 	seq_printf(m, "THPeligible:    %8u\n",
-		   hugepage_vma_check(vma, vma->vm_flags, true, false, true));
+		   !!thp_vma_allowable_orders(vma, vma->vm_flags, true, false,
+					      true, THP_ORDERS_ALL));
 
 	if (arch_pkeys_enabled())
 		seq_printf(m, "ProtectionKey:  %8u\n", vma_pkey(vma));
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index fa0350b0812a..bd0eadd3befb 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -67,6 +67,21 @@ extern struct kobj_attribute shmem_enabled_attr;
 #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
 #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
 
+/*
+ * Mask of all large folio orders supported for anonymous THP.
+ */
+#define THP_ORDERS_ALL_ANON	BIT(PMD_ORDER)
+
+/*
+ * Mask of all large folio orders supported for file THP.
+ */
+#define THP_ORDERS_ALL_FILE	(BIT(PMD_ORDER) | BIT(PUD_ORDER))
+
+/*
+ * Mask of all large folio orders supported for THP.
+ */
+#define THP_ORDERS_ALL		(THP_ORDERS_ALL_ANON | THP_ORDERS_ALL_FILE)
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 #define HPAGE_PMD_SHIFT PMD_SHIFT
 #define HPAGE_PMD_SIZE	((1UL) << HPAGE_PMD_SHIFT)
@@ -78,42 +93,64 @@ extern struct kobj_attribute shmem_enabled_attr;
 
 extern unsigned long transparent_hugepage_flags;
 
-#define hugepage_flags_enabled()					       \
-	(transparent_hugepage_flags &				       \
-	 ((1<<TRANSPARENT_HUGEPAGE_FLAG) |		       \
-	  (1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG)))
-#define hugepage_flags_always()				\
-	(transparent_hugepage_flags &			\
-	 (1<<TRANSPARENT_HUGEPAGE_FLAG))
+bool hugepage_flags_enabled(void);
+
+static inline int first_order(unsigned long orders)
+{
+	return fls_long(orders) - 1;
+}
+
+static inline int next_order(unsigned long *orders, int prev)
+{
+	*orders &= ~BIT(prev);
+	return first_order(*orders);
+}
 
 /*
- * Do the below checks:
+ * Filter the bitfield of input orders by doing the below checks:
  *   - For file vma, check if the linear page offset of vma is
- *     HPAGE_PMD_NR aligned within the file.  The hugepage is
+ *     hpage_size-aligned within the file.  The hugepage is
  *     guaranteed to be hugepage-aligned within the file, but we must
- *     check that the PMD-aligned addresses in the VMA map to
- *     PMD-aligned offsets within the file, else the hugepage will
- *     not be PMD-mappable.
- *   - For all vmas, check if the haddr is in an aligned HPAGE_PMD_SIZE
+ *     check that the hpage_size-aligned addresses in the VMA map to
+ *     hpage_size-aligned offsets within the file, else the hugepage will
+ *     not be mappable.
+ *   - For all vmas, check if the haddr is in an aligned hpage_size
  *     area.
+ * All orders that pass the checks are returned as a bitfield.
  */
-static inline bool transhuge_vma_suitable(struct vm_area_struct *vma,
-		unsigned long addr)
-{
-	unsigned long haddr;
-
-	/* Don't have to check pgoff for anonymous vma */
-	if (!vma_is_anonymous(vma)) {
-		if (!IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) - vma->vm_pgoff,
-				HPAGE_PMD_NR))
-			return false;
+static inline unsigned long thp_vma_suitable_orders(struct vm_area_struct *vma,
+		unsigned long addr, unsigned long orders)
+{
+	int order;
+
+	/*
+	 * Iterate over orders, highest to lowest, removing orders that don't
+	 * meet alignment requirements from the set. Exit loop at first order
+	 * that meets requirements, since all lower orders must also meet
+	 * requirements.
+	 */
+
+	order = first_order(orders);
+
+	while (orders) {
+		unsigned long hpage_size = PAGE_SIZE << order;
+		unsigned long haddr = ALIGN_DOWN(addr, hpage_size);
+
+		if (haddr >= vma->vm_start &&
+		    haddr + hpage_size <= vma->vm_end) {
+			if (!vma_is_anonymous(vma)) {
+				if (IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) -
+						vma->vm_pgoff,
+						hpage_size >> PAGE_SHIFT))
+					break;
+			} else
+				break;
+		}
+
+		order = next_order(&orders, order);
 	}
 
-	haddr = addr & HPAGE_PMD_MASK;
-
-	if (haddr < vma->vm_start || haddr + HPAGE_PMD_SIZE > vma->vm_end)
-		return false;
-	return true;
+	return orders;
 }
 
 static inline bool file_thp_enabled(struct vm_area_struct *vma)
@@ -130,8 +167,10 @@ static inline bool file_thp_enabled(struct vm_area_struct *vma)
 	       !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
 }
 
-bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
-			bool smaps, bool in_pf, bool enforce_sysfs);
+unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
+				       unsigned long vm_flags, bool smaps,
+				       bool in_pf, bool enforce_sysfs,
+				       unsigned long orders);
 
 #define transparent_hugepage_use_zero_page()				\
 	(transparent_hugepage_flags &					\
@@ -267,17 +306,18 @@ static inline bool folio_test_pmd_mappable(struct folio *folio)
 	return false;
 }
 
-static inline bool transhuge_vma_suitable(struct vm_area_struct *vma,
-		unsigned long addr)
+static inline unsigned long thp_vma_suitable_orders(struct vm_area_struct *vma,
+		unsigned long addr, unsigned long orders)
 {
-	return false;
+	return 0;
 }
 
-static inline bool hugepage_vma_check(struct vm_area_struct *vma,
-				      unsigned long vm_flags, bool smaps,
-				      bool in_pf, bool enforce_sysfs)
+static inline unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
+					unsigned long vm_flags, bool smaps,
+					bool in_pf, bool enforce_sysfs,
+					unsigned long orders)
 {
-	return false;
+	return 0;
 }
 
 static inline void folio_prep_large_rmappable(struct folio *folio) {}
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 8a65e2cb6126..da70ae13be5e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -74,12 +74,65 @@ static unsigned long deferred_split_scan(struct shrinker *shrink,
 static atomic_t huge_zero_refcount;
 struct page *huge_zero_page __read_mostly;
 unsigned long huge_zero_pfn __read_mostly = ~0UL;
+static unsigned long huge_anon_orders_always __read_mostly;
+static unsigned long huge_anon_orders_madvise __read_mostly;
+static unsigned long huge_anon_orders_inherit __read_mostly;
 
-bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
-			bool smaps, bool in_pf, bool enforce_sysfs)
+static inline bool hugepage_global_enabled(void)
 {
+	return transparent_hugepage_flags &
+			((1<<TRANSPARENT_HUGEPAGE_FLAG) |
+			(1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG));
+}
+
+static inline bool hugepage_global_always(void)
+{
+	return transparent_hugepage_flags &
+			(1<<TRANSPARENT_HUGEPAGE_FLAG);
+}
+
+bool hugepage_flags_enabled(void)
+{
+	/*
+	 * We cover both the anon and the file-backed case here; we must return
+	 * true if globally enabled, even when all anon sizes are set to never.
+	 * So we don't need to look at huge_anon_orders_inherit.
+	 */
+	return hugepage_global_enabled() ||
+	       huge_anon_orders_always ||
+	       huge_anon_orders_madvise;
+}
+
+/**
+ * thp_vma_allowable_orders - determine hugepage orders that are allowed for vma
+ * @vma:  the vm area to check
+ * @vm_flags: use these vm_flags instead of vma->vm_flags
+ * @smaps: whether answer will be used for smaps file
+ * @in_pf: whether answer will be used by page fault handler
+ * @enforce_sysfs: whether sysfs config should be taken into account
+ * @orders: bitfield of all orders to consider
+ *
+ * Calculates the intersection of the requested hugepage orders and the allowed
+ * hugepage orders for the provided vma. Permitted orders are encoded as a set
+ * bit at the corresponding bit position (bit-2 corresponds to order-2, bit-3
+ * corresponds to order-3, etc). Order-0 is never considered a hugepage order.
+ *
+ * Return: bitfield of orders allowed for hugepage in the vma. 0 if no hugepage
+ * orders are allowed.
+ */
+unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
+				       unsigned long vm_flags, bool smaps,
+				       bool in_pf, bool enforce_sysfs,
+				       unsigned long orders)
+{
+	/* Check the intersection of requested and supported orders. */
+	orders &= vma_is_anonymous(vma) ?
+			THP_ORDERS_ALL_ANON : THP_ORDERS_ALL_FILE;
+	if (!orders)
+		return 0;
+
 	if (!vma->vm_mm)		/* vdso */
-		return false;
+		return 0;
 
 	/*
 	 * Explicitly disabled through madvise or prctl, or some
@@ -88,16 +141,16 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
 	 * */
 	if ((vm_flags & VM_NOHUGEPAGE) ||
 	    test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
-		return false;
+		return 0;
 	/*
 	 * If the hardware/firmware marked hugepage support disabled.
 	 */
 	if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED))
-		return false;
+		return 0;
 
 	/* khugepaged doesn't collapse DAX vma, but page fault is fine. */
 	if (vma_is_dax(vma))
-		return in_pf;
+		return in_pf ? orders : 0;
 
 	/*
 	 * khugepaged special VMA and hugetlb VMA.
@@ -105,17 +158,29 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
 	 * VM_MIXEDMAP set.
 	 */
 	if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
-		return false;
+		return 0;
 
 	/*
-	 * Check alignment for file vma and size for both file and anon vma.
+	 * Check alignment for file vma and size for both file and anon vma by
+	 * filtering out the unsuitable orders.
 	 *
 	 * Skip the check for page fault. Huge fault does the check in fault
-	 * handlers. And this check is not suitable for huge PUD fault.
+	 * handlers.
 	 */
-	if (!in_pf &&
-	    !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
-		return false;
+	if (!in_pf) {
+		int order = first_order(orders);
+		unsigned long addr;
+
+		while (orders) {
+			addr = vma->vm_end - (PAGE_SIZE << order);
+			if (thp_vma_suitable_orders(vma, addr, BIT(order)))
+				break;
+			order = next_order(&orders, order);
+		}
+
+		if (!orders)
+			return 0;
+	}
 
 	/*
 	 * Enabled via shmem mount options or sysfs settings.
@@ -124,13 +189,27 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
 	 */
 	if (!in_pf && shmem_file(vma->vm_file))
 		return shmem_is_huge(file_inode(vma->vm_file), vma->vm_pgoff,
-				     !enforce_sysfs, vma->vm_mm, vm_flags);
+				     !enforce_sysfs, vma->vm_mm, vm_flags)
+			? orders : 0;
 
 	/* Enforce sysfs THP requirements as necessary */
-	if (enforce_sysfs &&
-	    (!hugepage_flags_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
-					   !hugepage_flags_always())))
-		return false;
+	if (enforce_sysfs) {
+		if (vma_is_anonymous(vma)) {
+			unsigned long mask = READ_ONCE(huge_anon_orders_always);
+
+			if (vm_flags & VM_HUGEPAGE)
+				mask |= READ_ONCE(huge_anon_orders_madvise);
+			if (hugepage_global_always() ||
+			   ((vm_flags & VM_HUGEPAGE) && hugepage_global_enabled()))
+				mask |= READ_ONCE(huge_anon_orders_inherit);
+
+			orders &= mask;
+			if (!orders)
+				return 0;
+		} else if (!hugepage_global_enabled() ||
+			  (!(vm_flags & VM_HUGEPAGE) && !hugepage_global_always()))
+			return 0;
+	}
 
 	if (!vma_is_anonymous(vma)) {
 		/*
@@ -138,15 +217,15 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
 		 * in fault path.
 		 */
 		if (((in_pf || smaps)) && vma->vm_ops->huge_fault)
-			return true;
+			return orders;
 		/* Only regular file is valid in collapse path */
 		if (((!in_pf || smaps)) && file_thp_enabled(vma))
-			return true;
-		return false;
+			return orders;
+		return 0;
 	}
 
 	if (vma_is_temporary_stack(vma))
-		return false;
+		return 0;
 
 	/*
 	 * THPeligible bit of smaps should show 1 for proper VMAs even
@@ -156,9 +235,9 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
 	 * the first page fault.
 	 */
 	if (!vma->anon_vma)
-		return (smaps || in_pf);
+		return (smaps || in_pf) ? orders : 0;
 
-	return true;
+	return orders;
 }
 
 static bool get_huge_zero_page(void)
@@ -412,9 +491,127 @@ static const struct attribute_group hugepage_attr_group = {
 	.attrs = hugepage_attr,
 };
 
+static void hugepage_exit_sysfs(struct kobject *hugepage_kobj);
+static void thpsize_release(struct kobject *kobj);
+static LIST_HEAD(thpsize_list);
+
+struct thpsize {
+	struct kobject kobj;
+	struct list_head node;
+	int order;
+};
+
+#define to_thpsize(kobj) container_of(kobj, struct thpsize, kobj)
+
+static ssize_t thpsize_enabled_show(struct kobject *kobj,
+				    struct kobj_attribute *attr, char *buf)
+{
+	int order = to_thpsize(kobj)->order;
+	const char *output;
+
+	if (test_bit(order, &huge_anon_orders_always))
+		output = "[always] inherit madvise never";
+	else if (test_bit(order, &huge_anon_orders_inherit))
+		output = "always [inherit] madvise never";
+	else if (test_bit(order, &huge_anon_orders_madvise))
+		output = "always inherit [madvise] never";
+	else
+		output = "always inherit madvise [never]";
+
+	return sysfs_emit(buf, "%s\n", output);
+}
+
+static ssize_t thpsize_enabled_store(struct kobject *kobj,
+				     struct kobj_attribute *attr,
+				     const char *buf, size_t count)
+{
+	int order = to_thpsize(kobj)->order;
+	ssize_t ret = count;
+
+	if (sysfs_streq(buf, "always")) {
+		set_bit(order, &huge_anon_orders_always);
+		clear_bit(order, &huge_anon_orders_inherit);
+		clear_bit(order, &huge_anon_orders_madvise);
+	} else if (sysfs_streq(buf, "inherit")) {
+		set_bit(order, &huge_anon_orders_inherit);
+		clear_bit(order, &huge_anon_orders_always);
+		clear_bit(order, &huge_anon_orders_madvise);
+	} else if (sysfs_streq(buf, "madvise")) {
+		set_bit(order, &huge_anon_orders_madvise);
+		clear_bit(order, &huge_anon_orders_always);
+		clear_bit(order, &huge_anon_orders_inherit);
+	} else if (sysfs_streq(buf, "never")) {
+		clear_bit(order, &huge_anon_orders_always);
+		clear_bit(order, &huge_anon_orders_inherit);
+		clear_bit(order, &huge_anon_orders_madvise);
+	} else
+		ret = -EINVAL;
+
+	return ret;
+}
+
+static struct kobj_attribute thpsize_enabled_attr =
+	__ATTR(enabled, 0644, thpsize_enabled_show, thpsize_enabled_store);
+
+static struct attribute *thpsize_attrs[] = {
+	&thpsize_enabled_attr.attr,
+	NULL,
+};
+
+static const struct attribute_group thpsize_attr_group = {
+	.attrs = thpsize_attrs,
+};
+
+static const struct kobj_type thpsize_ktype = {
+	.release = &thpsize_release,
+	.sysfs_ops = &kobj_sysfs_ops,
+};
+
+static struct thpsize *thpsize_create(int order, struct kobject *parent)
+{
+	unsigned long size = (PAGE_SIZE << order) / SZ_1K;
+	struct thpsize *thpsize;
+	int ret;
+
+	thpsize = kzalloc(sizeof(*thpsize), GFP_KERNEL);
+	if (!thpsize)
+		return ERR_PTR(-ENOMEM);
+
+	ret = kobject_init_and_add(&thpsize->kobj, &thpsize_ktype, parent,
+				   "hugepages-%lukB", size);
+	if (ret) {
+		kfree(thpsize);
+		return ERR_PTR(ret);
+	}
+
+	ret = sysfs_create_group(&thpsize->kobj, &thpsize_attr_group);
+	if (ret) {
+		kobject_put(&thpsize->kobj);
+		return ERR_PTR(ret);
+	}
+
+	thpsize->order = order;
+	return thpsize;
+}
+
+static void thpsize_release(struct kobject *kobj)
+{
+	kfree(to_thpsize(kobj));
+}
+
 static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
 {
 	int err;
+	struct thpsize *thpsize;
+	unsigned long orders;
+	int order;
+
+	/*
+	 * Default to setting PMD-sized THP to inherit the global setting and
+	 * disable all other sizes. powerpc's PMD_ORDER isn't a compile-time
+	 * constant so we have to do this here.
+	 */
+	huge_anon_orders_inherit = BIT(PMD_ORDER);
 
 	*hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
 	if (unlikely(!*hugepage_kobj)) {
@@ -434,8 +631,24 @@ static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
 		goto remove_hp_group;
 	}
 
+	orders = THP_ORDERS_ALL_ANON;
+	order = first_order(orders);
+	while (orders) {
+		thpsize = thpsize_create(order, *hugepage_kobj);
+		if (IS_ERR(thpsize)) {
+			pr_err("failed to create thpsize for order %d\n", order);
+			err = PTR_ERR(thpsize);
+			goto remove_all;
+		}
+		list_add(&thpsize->node, &thpsize_list);
+		order = next_order(&orders, order);
+	}
+
 	return 0;
 
+remove_all:
+	hugepage_exit_sysfs(*hugepage_kobj);
+	return err;
 remove_hp_group:
 	sysfs_remove_group(*hugepage_kobj, &hugepage_attr_group);
 delete_obj:
@@ -445,6 +658,13 @@ static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
 
 static void __init hugepage_exit_sysfs(struct kobject *hugepage_kobj)
 {
+	struct thpsize *thpsize, *tmp;
+
+	list_for_each_entry_safe(thpsize, tmp, &thpsize_list, node) {
+		list_del(&thpsize->node);
+		kobject_put(&thpsize->kobj);
+	}
+
 	sysfs_remove_group(hugepage_kobj, &khugepaged_attr_group);
 	sysfs_remove_group(hugepage_kobj, &hugepage_attr_group);
 	kobject_put(hugepage_kobj);
@@ -811,7 +1031,7 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf)
 	struct folio *folio;
 	unsigned long haddr = vmf->address & HPAGE_PMD_MASK;
 
-	if (!transhuge_vma_suitable(vma, haddr))
+	if (!thp_vma_suitable_orders(vma, haddr, BIT(PMD_ORDER)))
 		return VM_FAULT_FALLBACK;
 	if (unlikely(anon_vma_prepare(vma)))
 		return VM_FAULT_OOM;
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 0da6937572cf..3aee6de526f8 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -446,7 +446,8 @@ void khugepaged_enter_vma(struct vm_area_struct *vma,
 {
 	if (!test_bit(MMF_VM_HUGEPAGE, &vma->vm_mm->flags) &&
 	    hugepage_flags_enabled()) {
-		if (hugepage_vma_check(vma, vm_flags, false, false, true))
+		if (thp_vma_allowable_orders(vma, vm_flags, false, false, true,
+					     BIT(PMD_ORDER)))
 			__khugepaged_enter(vma->vm_mm);
 	}
 }
@@ -922,16 +923,16 @@ static int hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address,
 	if (!vma)
 		return SCAN_VMA_NULL;
 
-	if (!transhuge_vma_suitable(vma, address))
+	if (!thp_vma_suitable_orders(vma, address, BIT(PMD_ORDER)))
 		return SCAN_ADDRESS_RANGE;
-	if (!hugepage_vma_check(vma, vma->vm_flags, false, false,
-				cc->is_khugepaged))
+	if (!thp_vma_allowable_orders(vma, vma->vm_flags, false, false,
+				      cc->is_khugepaged, BIT(PMD_ORDER)))
 		return SCAN_VMA_CHECK;
 	/*
 	 * Anon VMA expected, the address may be unmapped then
 	 * remapped to file after khugepaged reaquired the mmap_lock.
 	 *
-	 * hugepage_vma_check may return true for qualified file
+	 * thp_vma_allowable_orders may return true for qualified file
 	 * vmas.
 	 */
 	if (expect_anon && (!(*vmap)->anon_vma || !vma_is_anonymous(*vmap)))
@@ -1506,7 +1507,8 @@ int collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr,
 	 * and map it by a PMD, regardless of sysfs THP settings. As such, let's
 	 * analogously elide sysfs THP settings here.
 	 */
-	if (!hugepage_vma_check(vma, vma->vm_flags, false, false, false))
+	if (!thp_vma_allowable_orders(vma, vma->vm_flags, false, false, false,
+				      BIT(PMD_ORDER)))
 		return SCAN_VMA_CHECK;
 
 	/* Keep pmd pgtable for uffd-wp; see comment in retract_page_tables() */
@@ -2371,7 +2373,8 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
 			progress++;
 			break;
 		}
-		if (!hugepage_vma_check(vma, vma->vm_flags, false, false, true)) {
+		if (!thp_vma_allowable_orders(vma, vma->vm_flags, false, false,
+					      true, BIT(PMD_ORDER))) {
 skip:
 			progress++;
 			continue;
@@ -2708,7 +2711,8 @@ int madvise_collapse(struct vm_area_struct *vma, struct vm_area_struct **prev,
 
 	*prev = vma;
 
-	if (!hugepage_vma_check(vma, vma->vm_flags, false, false, false))
+	if (!thp_vma_allowable_orders(vma, vma->vm_flags, false, false, false,
+				      BIT(PMD_ORDER)))
 		return -EINVAL;
 
 	cc = kmalloc(sizeof(*cc), GFP_KERNEL);
diff --git a/mm/memory.c b/mm/memory.c
index 99582b188ed2..3ceeb0f45bf5 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4322,7 +4322,7 @@ vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
 	pmd_t entry;
 	vm_fault_t ret = VM_FAULT_FALLBACK;
 
-	if (!transhuge_vma_suitable(vma, haddr))
+	if (!thp_vma_suitable_orders(vma, haddr, BIT(PMD_ORDER)))
 		return ret;
 
 	page = compound_head(page);
@@ -5116,7 +5116,8 @@ static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma,
 		return VM_FAULT_OOM;
 retry_pud:
 	if (pud_none(*vmf.pud) &&
-	    hugepage_vma_check(vma, vm_flags, false, true, true)) {
+	    thp_vma_allowable_orders(vma, vm_flags, false, true, true,
+				     BIT(PUD_ORDER))) {
 		ret = create_huge_pud(&vmf);
 		if (!(ret & VM_FAULT_FALLBACK))
 			return ret;
@@ -5150,7 +5151,8 @@ static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma,
 		goto retry_pud;
 
 	if (pmd_none(*vmf.pmd) &&
-	    hugepage_vma_check(vma, vm_flags, false, true, true)) {
+	    thp_vma_allowable_orders(vma, vm_flags, false, true, true,
+				     BIT(PMD_ORDER))) {
 		ret = create_huge_pmd(&vmf);
 		if (!(ret & VM_FAULT_FALLBACK))
 			return ret;
diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
index e0b368e545ed..64da127cc267 100644
--- a/mm/page_vma_mapped.c
+++ b/mm/page_vma_mapped.c
@@ -268,7 +268,8 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
 			 * cleared *pmd but not decremented compound_mapcount().
 			 */
 			if ((pvmw->flags & PVMW_SYNC) &&
-			    transhuge_vma_suitable(vma, pvmw->address) &&
+			    thp_vma_suitable_orders(vma, pvmw->address,
+						    BIT(PMD_ORDER)) &&
 			    (pvmw->nr_pages >= HPAGE_PMD_NR)) {
 				spinlock_t *ptl = pmd_lock(mm, pvmw->pmd);
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:21 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:21 +0000
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous multi-size THP
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-5-ryan.roberts@arm.com>

Introduce the logic to allow THP to be configured (through the new sysfs
interface we just added) to allocate large folios to back anonymous
memory, which are larger than the base page size but smaller than
PMD-size. We call this new THP extension "multi-size THP" (mTHP).

mTHP continues to be PTE-mapped, but in many cases can still provide
similar benefits to traditional PMD-sized THP: Page faults are
significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
the configured order), but latency spikes are much less prominent
because the size of each page isn't as huge as the PMD-sized variant and
there is less memory to clear in each page fault. The number of per-page
operations (e.g. ref counting, rmap management, lru list management) are
also significantly reduced since those ops now become per-folio.

Some architectures also employ TLB compression mechanisms to squeeze
more entries in when a set of PTEs are virtually and physically
contiguous and approporiately aligned. In this case, TLB misses will
occur less often.

The new behaviour is disabled by default, but can be enabled at runtime
by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
(see documentation in previous commit). The long term aim is to change
the default to include suitable lower orders, but there are some risks
around internal fragmentation that need to be better understood first.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 include/linux/huge_mm.h |   6 ++-
 mm/memory.c             | 106 ++++++++++++++++++++++++++++++++++++----
 2 files changed, 101 insertions(+), 11 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index bd0eadd3befb..91a53b9835a4 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
 #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
 
 /*
- * Mask of all large folio orders supported for anonymous THP.
+ * Mask of all large folio orders supported for anonymous THP; all orders up to
+ * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
+ * (which is a limitation of the THP implementation).
  */
-#define THP_ORDERS_ALL_ANON	BIT(PMD_ORDER)
+#define THP_ORDERS_ALL_ANON	((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
 
 /*
  * Mask of all large folio orders supported for file THP.
diff --git a/mm/memory.c b/mm/memory.c
index 3ceeb0f45bf5..bf7e93813018 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
 	return ret;
 }
 
+static bool pte_range_none(pte_t *pte, int nr_pages)
+{
+	int i;
+
+	for (i = 0; i < nr_pages; i++) {
+		if (!pte_none(ptep_get_lockless(pte + i)))
+			return false;
+	}
+
+	return true;
+}
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+static struct folio *alloc_anon_folio(struct vm_fault *vmf)
+{
+	gfp_t gfp;
+	pte_t *pte;
+	unsigned long addr;
+	struct folio *folio;
+	struct vm_area_struct *vma = vmf->vma;
+	unsigned long orders;
+	int order;
+
+	/*
+	 * If uffd is active for the vma we need per-page fault fidelity to
+	 * maintain the uffd semantics.
+	 */
+	if (userfaultfd_armed(vma))
+		goto fallback;
+
+	/*
+	 * Get a list of all the (large) orders below PMD_ORDER that are enabled
+	 * for this vma. Then filter out the orders that can't be allocated over
+	 * the faulting address and still be fully contained in the vma.
+	 */
+	orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
+					  BIT(PMD_ORDER) - 1);
+	orders = thp_vma_suitable_orders(vma, vmf->address, orders);
+
+	if (!orders)
+		goto fallback;
+
+	pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
+	if (!pte)
+		return ERR_PTR(-EAGAIN);
+
+	order = first_order(orders);
+	while (orders) {
+		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
+		vmf->pte = pte + pte_index(addr);
+		if (pte_range_none(vmf->pte, 1 << order))
+			break;
+		order = next_order(&orders, order);
+	}
+
+	vmf->pte = NULL;
+	pte_unmap(pte);
+
+	gfp = vma_thp_gfp_mask(vma);
+
+	while (orders) {
+		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
+		folio = vma_alloc_folio(gfp, order, vma, addr, true);
+		if (folio) {
+			clear_huge_page(&folio->page, addr, 1 << order);
+			return folio;
+		}
+		order = next_order(&orders, order);
+	}
+
+fallback:
+	return vma_alloc_zeroed_movable_folio(vma, vmf->address);
+}
+#else
+#define alloc_anon_folio(vmf) \
+		vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
+#endif
+
 /*
  * We enter with non-exclusive mmap_lock (to exclude vma changes,
  * but allow concurrent faults), and pte mapped but not yet locked.
@@ -4132,6 +4210,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
  */
 static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 {
+	int i;
+	int nr_pages = 1;
+	unsigned long addr = vmf->address;
 	bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
 	struct vm_area_struct *vma = vmf->vma;
 	struct folio *folio;
@@ -4176,10 +4257,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 	/* Allocate our own private page. */
 	if (unlikely(anon_vma_prepare(vma)))
 		goto oom;
-	folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
+	folio = alloc_anon_folio(vmf);
+	if (IS_ERR(folio))
+		return 0;
 	if (!folio)
 		goto oom;
 
+	nr_pages = folio_nr_pages(folio);
+	addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
+
 	if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
 		goto oom_free_page;
 	folio_throttle_swaprate(folio, GFP_KERNEL);
@@ -4196,12 +4282,13 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 	if (vma->vm_flags & VM_WRITE)
 		entry = pte_mkwrite(pte_mkdirty(entry), vma);
 
-	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
-			&vmf->ptl);
+	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
 	if (!vmf->pte)
 		goto release;
-	if (vmf_pte_changed(vmf)) {
-		update_mmu_tlb(vma, vmf->address, vmf->pte);
+	if ((nr_pages == 1 && vmf_pte_changed(vmf)) ||
+	    (nr_pages  > 1 && !pte_range_none(vmf->pte, nr_pages))) {
+		for (i = 0; i < nr_pages; i++)
+			update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);
 		goto release;
 	}
 
@@ -4216,16 +4303,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 		return handle_userfault(vmf, VM_UFFD_MISSING);
 	}
 
-	inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
-	folio_add_new_anon_rmap(folio, vma, vmf->address);
+	folio_ref_add(folio, nr_pages - 1);
+	add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
+	folio_add_new_anon_rmap(folio, vma, addr);
 	folio_add_lru_vma(folio, vma);
 setpte:
 	if (uffd_wp)
 		entry = pte_mkuffd_wp(entry);
-	set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
+	set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
 
 	/* No need to invalidate - it was non-present before */
-	update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
+	update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
 unlock:
 	if (vmf->pte)
 		pte_unmap_unlock(vmf->pte, vmf->ptl);
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:18 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:18 +0000
Subject: [PATCH v8 01/10] mm: Allow deferred splitting of arbitrary anon large folios
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-2-ryan.roberts@arm.com>

In preparation for the introduction of anonymous multi-size THP, we
would like to be able to split them when they have unmapped subpages, in
order to free those unused pages under memory pressure. So remove the
artificial requirement that the large folio needed to be at least
PMD-sized.

Reviewed-by: Yu Zhao <yuzhao at google.com>
Reviewed-by: Yin Fengwei <fengwei.yin at intel.com>
Reviewed-by: Matthew Wilcox (Oracle) <willy at infradead.org>
Reviewed-by: David Hildenbrand <david at redhat.com>
Reviewed-by: Barry Song <v-songbaohua at oppo.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 mm/rmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index de9426ad0f1b..2a1e45e6419f 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1518,11 +1518,11 @@ void page_remove_rmap(struct page *page, struct vm_area_struct *vma,
 		__lruvec_stat_mod_folio(folio, idx, -nr);
 
 		/*
-		 * Queue anon THP for deferred split if at least one
+		 * Queue anon large folio for deferred split if at least one
 		 * page of the folio is unmapped and at least one page
 		 * is still mapped.
 		 */
-		if (folio_test_pmd_mappable(folio) && folio_test_anon(folio))
+		if (folio_test_large(folio) && folio_test_anon(folio))
 			if (!compound || nr < nr_pmdmapped)
 				deferred_split_folio(folio);
 	}
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:19 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:19 +0000
Subject: [PATCH v8 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-3-ryan.roberts@arm.com>

In preparation for supporting anonymous multi-size THP, improve
folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be
passed to it. In this case, all contained pages are accounted using the
order-0 folio (or base page) scheme.

Reviewed-by: Yu Zhao <yuzhao at google.com>
Reviewed-by: Yin Fengwei <fengwei.yin at intel.com>
Reviewed-by: David Hildenbrand <david at redhat.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 mm/rmap.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index 2a1e45e6419f..846fc79f3ca9 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma,
  * This means the inc-and-test can be bypassed.
  * The folio does not have to be locked.
  *
- * If the folio is large, it is accounted as a THP.  As the folio
+ * If the folio is pmd-mappable, it is accounted as a THP.  As the folio
  * is new, it's assumed to be mapped exclusively by a single process.
  */
 void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
 		unsigned long address)
 {
-	int nr;
+	int nr = folio_nr_pages(folio);
 
-	VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
+	VM_BUG_ON_VMA(address < vma->vm_start ||
+			address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
 	__folio_set_swapbacked(folio);
+	__folio_set_anon(folio, vma, address, true);
 
-	if (likely(!folio_test_pmd_mappable(folio))) {
+	if (likely(!folio_test_large(folio))) {
 		/* increment count (starts at -1) */
 		atomic_set(&folio->_mapcount, 0);
-		nr = 1;
+		SetPageAnonExclusive(&folio->page);
+	} else if (!folio_test_pmd_mappable(folio)) {
+		int i;
+
+		for (i = 0; i < nr; i++) {
+			struct page *page = folio_page(folio, i);
+
+			/* increment count (starts at -1) */
+			atomic_set(&page->_mapcount, 0);
+			SetPageAnonExclusive(page);
+		}
+
+		atomic_set(&folio->_nr_pages_mapped, nr);
 	} else {
 		/* increment count (starts at -1) */
 		atomic_set(&folio->_entire_mapcount, 0);
 		atomic_set(&folio->_nr_pages_mapped, COMPOUND_MAPPED);
-		nr = folio_nr_pages(folio);
+		SetPageAnonExclusive(&folio->page);
 		__lruvec_stat_mod_folio(folio, NR_ANON_THPS, nr);
 	}
 
 	__lruvec_stat_mod_folio(folio, NR_ANON_MAPPED, nr);
-	__folio_set_anon(folio, vma, address, true);
-	SetPageAnonExclusive(&folio->page);
 }
 
 /**
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:22 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:22 +0000
Subject: [PATCH v8 05/10] selftests/mm/kugepaged: Restore thp settings at exit
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-6-ryan.roberts@arm.com>

Previously, the saved thp settings would be restored upon a signal or at
the natural end of the test suite. But there are some tests that
directly call exit() upon failure. In this case, the thp settings were
not being restored, which could then influence other tests.

Fix this by installing an atexit() handler to do the actual restore. The
signal handler can now just call exit() and the atexit handler is
invoked.

Reviewed-by: Alistair Popple <apopple at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/khugepaged.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
index 030667cb5533..fc47a1c4944c 100644
--- a/tools/testing/selftests/mm/khugepaged.c
+++ b/tools/testing/selftests/mm/khugepaged.c
@@ -374,18 +374,22 @@ static void pop_settings(void)
 	write_settings(current_settings());
 }
 
-static void restore_settings(int sig)
+static void restore_settings_atexit(void)
 {
 	if (skip_settings_restore)
-		goto out;
+		return;
 
 	printf("Restore THP and khugepaged settings...");
 	write_settings(&saved_settings);
 	success("OK");
-	if (sig)
-		exit(EXIT_FAILURE);
-out:
-	exit(exit_status);
+
+	skip_settings_restore = true;
+}
+
+static void restore_settings(int sig)
+{
+	/* exit() will invoke the restore_settings_atexit handler. */
+	exit(sig ? EXIT_FAILURE : exit_status);
 }
 
 static void save_settings(void)
@@ -415,6 +419,7 @@ static void save_settings(void)
 
 	success("OK");
 
+	atexit(restore_settings_atexit);
 	signal(SIGTERM, restore_settings);
 	signal(SIGINT, restore_settings);
 	signal(SIGHUP, restore_settings);
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:23 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:23 +0000
Subject: [PATCH v8 06/10] selftests/mm: Factor out thp settings management
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-7-ryan.roberts@arm.com>

The khugepaged test has a useful framework for save/restore/pop/push of
all thp settings via the sysfs interface. This will be useful to
explicitly control multi-size THP settings in other tests, so let's
move it out of khugepaged and into its own thp_settings.[c|h] utility.

Tested-by: Alistair Popple <apopple at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/Makefile       |   4 +-
 tools/testing/selftests/mm/khugepaged.c   | 346 ++--------------------
 tools/testing/selftests/mm/thp_settings.c | 296 ++++++++++++++++++
 tools/testing/selftests/mm/thp_settings.h |  71 +++++
 4 files changed, 391 insertions(+), 326 deletions(-)
 create mode 100644 tools/testing/selftests/mm/thp_settings.c
 create mode 100644 tools/testing/selftests/mm/thp_settings.h

diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile
index dede0bcf97a3..2453add65d12 100644
--- a/tools/testing/selftests/mm/Makefile
+++ b/tools/testing/selftests/mm/Makefile
@@ -117,8 +117,8 @@ TEST_FILES += va_high_addr_switch.sh
 
 include ../lib.mk
 
-$(TEST_GEN_PROGS): vm_util.c
-$(TEST_GEN_FILES): vm_util.c
+$(TEST_GEN_PROGS): vm_util.c thp_settings.c
+$(TEST_GEN_FILES): vm_util.c thp_settings.c
 
 $(OUTPUT)/uffd-stress: uffd-common.c
 $(OUTPUT)/uffd-unit-tests: uffd-common.c
diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
index fc47a1c4944c..b15e7fd70176 100644
--- a/tools/testing/selftests/mm/khugepaged.c
+++ b/tools/testing/selftests/mm/khugepaged.c
@@ -22,13 +22,13 @@
 #include "linux/magic.h"
 
 #include "vm_util.h"
+#include "thp_settings.h"
 
 #define BASE_ADDR ((void *)(1UL << 30))
 static unsigned long hpage_pmd_size;
 static unsigned long page_size;
 static int hpage_pmd_nr;
 
-#define THP_SYSFS "/sys/kernel/mm/transparent_hugepage/"
 #define PID_SMAPS "/proc/self/smaps"
 #define TEST_FILE "collapse_test_file"
 
@@ -71,78 +71,7 @@ struct file_info {
 };
 
 static struct file_info finfo;
-
-enum thp_enabled {
-	THP_ALWAYS,
-	THP_MADVISE,
-	THP_NEVER,
-};
-
-static const char *thp_enabled_strings[] = {
-	"always",
-	"madvise",
-	"never",
-	NULL
-};
-
-enum thp_defrag {
-	THP_DEFRAG_ALWAYS,
-	THP_DEFRAG_DEFER,
-	THP_DEFRAG_DEFER_MADVISE,
-	THP_DEFRAG_MADVISE,
-	THP_DEFRAG_NEVER,
-};
-
-static const char *thp_defrag_strings[] = {
-	"always",
-	"defer",
-	"defer+madvise",
-	"madvise",
-	"never",
-	NULL
-};
-
-enum shmem_enabled {
-	SHMEM_ALWAYS,
-	SHMEM_WITHIN_SIZE,
-	SHMEM_ADVISE,
-	SHMEM_NEVER,
-	SHMEM_DENY,
-	SHMEM_FORCE,
-};
-
-static const char *shmem_enabled_strings[] = {
-	"always",
-	"within_size",
-	"advise",
-	"never",
-	"deny",
-	"force",
-	NULL
-};
-
-struct khugepaged_settings {
-	bool defrag;
-	unsigned int alloc_sleep_millisecs;
-	unsigned int scan_sleep_millisecs;
-	unsigned int max_ptes_none;
-	unsigned int max_ptes_swap;
-	unsigned int max_ptes_shared;
-	unsigned long pages_to_scan;
-};
-
-struct settings {
-	enum thp_enabled thp_enabled;
-	enum thp_defrag thp_defrag;
-	enum shmem_enabled shmem_enabled;
-	bool use_zero_page;
-	struct khugepaged_settings khugepaged;
-	unsigned long read_ahead_kb;
-};
-
-static struct settings saved_settings;
 static bool skip_settings_restore;
-
 static int exit_status;
 
 static void success(const char *msg)
@@ -161,226 +90,13 @@ static void skip(const char *msg)
 	printf(" \e[33m%s\e[0m\n", msg);
 }
 
-static int read_file(const char *path, char *buf, size_t buflen)
-{
-	int fd;
-	ssize_t numread;
-
-	fd = open(path, O_RDONLY);
-	if (fd == -1)
-		return 0;
-
-	numread = read(fd, buf, buflen - 1);
-	if (numread < 1) {
-		close(fd);
-		return 0;
-	}
-
-	buf[numread] = '\0';
-	close(fd);
-
-	return (unsigned int) numread;
-}
-
-static int write_file(const char *path, const char *buf, size_t buflen)
-{
-	int fd;
-	ssize_t numwritten;
-
-	fd = open(path, O_WRONLY);
-	if (fd == -1) {
-		printf("open(%s)\n", path);
-		exit(EXIT_FAILURE);
-		return 0;
-	}
-
-	numwritten = write(fd, buf, buflen - 1);
-	close(fd);
-	if (numwritten < 1) {
-		printf("write(%s)\n", buf);
-		exit(EXIT_FAILURE);
-		return 0;
-	}
-
-	return (unsigned int) numwritten;
-}
-
-static int read_string(const char *name, const char *strings[])
-{
-	char path[PATH_MAX];
-	char buf[256];
-	char *c;
-	int ret;
-
-	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
-	if (ret >= PATH_MAX) {
-		printf("%s: Pathname is too long\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-
-	if (!read_file(path, buf, sizeof(buf))) {
-		perror(path);
-		exit(EXIT_FAILURE);
-	}
-
-	c = strchr(buf, '[');
-	if (!c) {
-		printf("%s: Parse failure\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-
-	c++;
-	memmove(buf, c, sizeof(buf) - (c - buf));
-
-	c = strchr(buf, ']');
-	if (!c) {
-		printf("%s: Parse failure\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-	*c = '\0';
-
-	ret = 0;
-	while (strings[ret]) {
-		if (!strcmp(strings[ret], buf))
-			return ret;
-		ret++;
-	}
-
-	printf("Failed to parse %s\n", name);
-	exit(EXIT_FAILURE);
-}
-
-static void write_string(const char *name, const char *val)
-{
-	char path[PATH_MAX];
-	int ret;
-
-	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
-	if (ret >= PATH_MAX) {
-		printf("%s: Pathname is too long\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-
-	if (!write_file(path, val, strlen(val) + 1)) {
-		perror(path);
-		exit(EXIT_FAILURE);
-	}
-}
-
-static const unsigned long _read_num(const char *path)
-{
-	char buf[21];
-
-	if (read_file(path, buf, sizeof(buf)) < 0) {
-		perror("read_file(read_num)");
-		exit(EXIT_FAILURE);
-	}
-
-	return strtoul(buf, NULL, 10);
-}
-
-static const unsigned long read_num(const char *name)
-{
-	char path[PATH_MAX];
-	int ret;
-
-	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
-	if (ret >= PATH_MAX) {
-		printf("%s: Pathname is too long\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-	return _read_num(path);
-}
-
-static void _write_num(const char *path, unsigned long num)
-{
-	char buf[21];
-
-	sprintf(buf, "%ld", num);
-	if (!write_file(path, buf, strlen(buf) + 1)) {
-		perror(path);
-		exit(EXIT_FAILURE);
-	}
-}
-
-static void write_num(const char *name, unsigned long num)
-{
-	char path[PATH_MAX];
-	int ret;
-
-	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
-	if (ret >= PATH_MAX) {
-		printf("%s: Pathname is too long\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-	_write_num(path, num);
-}
-
-static void write_settings(struct settings *settings)
-{
-	struct khugepaged_settings *khugepaged = &settings->khugepaged;
-
-	write_string("enabled", thp_enabled_strings[settings->thp_enabled]);
-	write_string("defrag", thp_defrag_strings[settings->thp_defrag]);
-	write_string("shmem_enabled",
-			shmem_enabled_strings[settings->shmem_enabled]);
-	write_num("use_zero_page", settings->use_zero_page);
-
-	write_num("khugepaged/defrag", khugepaged->defrag);
-	write_num("khugepaged/alloc_sleep_millisecs",
-			khugepaged->alloc_sleep_millisecs);
-	write_num("khugepaged/scan_sleep_millisecs",
-			khugepaged->scan_sleep_millisecs);
-	write_num("khugepaged/max_ptes_none", khugepaged->max_ptes_none);
-	write_num("khugepaged/max_ptes_swap", khugepaged->max_ptes_swap);
-	write_num("khugepaged/max_ptes_shared", khugepaged->max_ptes_shared);
-	write_num("khugepaged/pages_to_scan", khugepaged->pages_to_scan);
-
-	if (file_ops && finfo.type == VMA_FILE)
-		_write_num(finfo.dev_queue_read_ahead_path,
-			   settings->read_ahead_kb);
-}
-
-#define MAX_SETTINGS_DEPTH 4
-static struct settings settings_stack[MAX_SETTINGS_DEPTH];
-static int settings_index;
-
-static struct settings *current_settings(void)
-{
-	if (!settings_index) {
-		printf("Fail: No settings set");
-		exit(EXIT_FAILURE);
-	}
-	return settings_stack + settings_index - 1;
-}
-
-static void push_settings(struct settings *settings)
-{
-	if (settings_index >= MAX_SETTINGS_DEPTH) {
-		printf("Fail: Settings stack exceeded");
-		exit(EXIT_FAILURE);
-	}
-	settings_stack[settings_index++] = *settings;
-	write_settings(current_settings());
-}
-
-static void pop_settings(void)
-{
-	if (settings_index <= 0) {
-		printf("Fail: Settings stack empty");
-		exit(EXIT_FAILURE);
-	}
-	--settings_index;
-	write_settings(current_settings());
-}
-
 static void restore_settings_atexit(void)
 {
 	if (skip_settings_restore)
 		return;
 
 	printf("Restore THP and khugepaged settings...");
-	write_settings(&saved_settings);
+	thp_restore_settings();
 	success("OK");
 
 	skip_settings_restore = true;
@@ -395,27 +111,9 @@ static void restore_settings(int sig)
 static void save_settings(void)
 {
 	printf("Save THP and khugepaged settings...");
-	saved_settings = (struct settings) {
-		.thp_enabled = read_string("enabled", thp_enabled_strings),
-		.thp_defrag = read_string("defrag", thp_defrag_strings),
-		.shmem_enabled =
-			read_string("shmem_enabled", shmem_enabled_strings),
-		.use_zero_page = read_num("use_zero_page"),
-	};
-	saved_settings.khugepaged = (struct khugepaged_settings) {
-		.defrag = read_num("khugepaged/defrag"),
-		.alloc_sleep_millisecs =
-			read_num("khugepaged/alloc_sleep_millisecs"),
-		.scan_sleep_millisecs =
-			read_num("khugepaged/scan_sleep_millisecs"),
-		.max_ptes_none = read_num("khugepaged/max_ptes_none"),
-		.max_ptes_swap = read_num("khugepaged/max_ptes_swap"),
-		.max_ptes_shared = read_num("khugepaged/max_ptes_shared"),
-		.pages_to_scan = read_num("khugepaged/pages_to_scan"),
-	};
 	if (file_ops && finfo.type == VMA_FILE)
-		saved_settings.read_ahead_kb =
-				_read_num(finfo.dev_queue_read_ahead_path);
+		thp_set_read_ahead_path(finfo.dev_queue_read_ahead_path);
+	thp_save_settings();
 
 	success("OK");
 
@@ -798,7 +496,7 @@ static void __madvise_collapse(const char *msg, char *p, int nr_hpages,
 			       struct mem_ops *ops, bool expect)
 {
 	int ret;
-	struct settings settings = *current_settings();
+	struct thp_settings settings = *thp_current_settings();
 
 	printf("%s...", msg);
 
@@ -808,7 +506,7 @@ static void __madvise_collapse(const char *msg, char *p, int nr_hpages,
 	 */
 	settings.thp_enabled = THP_NEVER;
 	settings.shmem_enabled = SHMEM_NEVER;
-	push_settings(&settings);
+	thp_push_settings(&settings);
 
 	/* Clear VM_NOHUGEPAGE */
 	madvise(p, nr_hpages * hpage_pmd_size, MADV_HUGEPAGE);
@@ -820,7 +518,7 @@ static void __madvise_collapse(const char *msg, char *p, int nr_hpages,
 	else
 		success("OK");
 
-	pop_settings();
+	thp_pop_settings();
 }
 
 static void madvise_collapse(const char *msg, char *p, int nr_hpages,
@@ -850,13 +548,13 @@ static bool wait_for_scan(const char *msg, char *p, int nr_hpages,
 	madvise(p, nr_hpages * hpage_pmd_size, MADV_HUGEPAGE);
 
 	/* Wait until the second full_scan completed */
-	full_scans = read_num("khugepaged/full_scans") + 2;
+	full_scans = thp_read_num("khugepaged/full_scans") + 2;
 
 	printf("%s...", msg);
 	while (timeout--) {
 		if (ops->check_huge(p, nr_hpages))
 			break;
-		if (read_num("khugepaged/full_scans") >= full_scans)
+		if (thp_read_num("khugepaged/full_scans") >= full_scans)
 			break;
 		printf(".");
 		usleep(TICK);
@@ -911,11 +609,11 @@ static bool is_tmpfs(struct mem_ops *ops)
 
 static void alloc_at_fault(void)
 {
-	struct settings settings = *current_settings();
+	struct thp_settings settings = *thp_current_settings();
 	char *p;
 
 	settings.thp_enabled = THP_ALWAYS;
-	push_settings(&settings);
+	thp_push_settings(&settings);
 
 	p = alloc_mapping(1);
 	*p = 1;
@@ -925,7 +623,7 @@ static void alloc_at_fault(void)
 	else
 		fail("Fail");
 
-	pop_settings();
+	thp_pop_settings();
 
 	madvise(p, page_size, MADV_DONTNEED);
 	printf("Split huge PMD on MADV_DONTNEED...");
@@ -973,11 +671,11 @@ static void collapse_single_pte_entry(struct collapse_context *c, struct mem_ops
 static void collapse_max_ptes_none(struct collapse_context *c, struct mem_ops *ops)
 {
 	int max_ptes_none = hpage_pmd_nr / 2;
-	struct settings settings = *current_settings();
+	struct thp_settings settings = *thp_current_settings();
 	void *p;
 
 	settings.khugepaged.max_ptes_none = max_ptes_none;
-	push_settings(&settings);
+	thp_push_settings(&settings);
 
 	p = ops->setup_area(1);
 
@@ -1002,7 +700,7 @@ static void collapse_max_ptes_none(struct collapse_context *c, struct mem_ops *o
 	}
 skip:
 	ops->cleanup_area(p, hpage_pmd_size);
-	pop_settings();
+	thp_pop_settings();
 }
 
 static void collapse_swapin_single_pte(struct collapse_context *c, struct mem_ops *ops)
@@ -1033,7 +731,7 @@ static void collapse_swapin_single_pte(struct collapse_context *c, struct mem_op
 
 static void collapse_max_ptes_swap(struct collapse_context *c, struct mem_ops *ops)
 {
-	int max_ptes_swap = read_num("khugepaged/max_ptes_swap");
+	int max_ptes_swap = thp_read_num("khugepaged/max_ptes_swap");
 	void *p;
 
 	p = ops->setup_area(1);
@@ -1250,11 +948,11 @@ static void collapse_fork_compound(struct collapse_context *c, struct mem_ops *o
 			fail("Fail");
 		ops->fault(p, 0, page_size);
 
-		write_num("khugepaged/max_ptes_shared", hpage_pmd_nr - 1);
+		thp_write_num("khugepaged/max_ptes_shared", hpage_pmd_nr - 1);
 		c->collapse("Collapse PTE table full of compound pages in child",
 			    p, 1, ops, true);
-		write_num("khugepaged/max_ptes_shared",
-			  current_settings()->khugepaged.max_ptes_shared);
+		thp_write_num("khugepaged/max_ptes_shared",
+			  thp_current_settings()->khugepaged.max_ptes_shared);
 
 		validate_memory(p, 0, hpage_pmd_size);
 		ops->cleanup_area(p, hpage_pmd_size);
@@ -1275,7 +973,7 @@ static void collapse_fork_compound(struct collapse_context *c, struct mem_ops *o
 
 static void collapse_max_ptes_shared(struct collapse_context *c, struct mem_ops *ops)
 {
-	int max_ptes_shared = read_num("khugepaged/max_ptes_shared");
+	int max_ptes_shared = thp_read_num("khugepaged/max_ptes_shared");
 	int wstatus;
 	void *p;
 
@@ -1443,7 +1141,7 @@ static void parse_test_type(int argc, const char **argv)
 
 int main(int argc, const char **argv)
 {
-	struct settings default_settings = {
+	struct thp_settings default_settings = {
 		.thp_enabled = THP_MADVISE,
 		.thp_defrag = THP_DEFRAG_ALWAYS,
 		.shmem_enabled = SHMEM_ADVISE,
@@ -1484,7 +1182,7 @@ int main(int argc, const char **argv)
 	default_settings.khugepaged.pages_to_scan = hpage_pmd_nr * 8;
 
 	save_settings();
-	push_settings(&default_settings);
+	thp_push_settings(&default_settings);
 
 	alloc_at_fault();
 
diff --git a/tools/testing/selftests/mm/thp_settings.c b/tools/testing/selftests/mm/thp_settings.c
new file mode 100644
index 000000000000..5e8ec792cac7
--- /dev/null
+++ b/tools/testing/selftests/mm/thp_settings.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <fcntl.h>
+#include <limits.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#include "thp_settings.h"
+
+#define THP_SYSFS "/sys/kernel/mm/transparent_hugepage/"
+#define MAX_SETTINGS_DEPTH 4
+static struct thp_settings settings_stack[MAX_SETTINGS_DEPTH];
+static int settings_index;
+static struct thp_settings saved_settings;
+static char dev_queue_read_ahead_path[PATH_MAX];
+
+static const char * const thp_enabled_strings[] = {
+	"always",
+	"madvise",
+	"never",
+	NULL
+};
+
+static const char * const thp_defrag_strings[] = {
+	"always",
+	"defer",
+	"defer+madvise",
+	"madvise",
+	"never",
+	NULL
+};
+
+static const char * const shmem_enabled_strings[] = {
+	"always",
+	"within_size",
+	"advise",
+	"never",
+	"deny",
+	"force",
+	NULL
+};
+
+int read_file(const char *path, char *buf, size_t buflen)
+{
+	int fd;
+	ssize_t numread;
+
+	fd = open(path, O_RDONLY);
+	if (fd == -1)
+		return 0;
+
+	numread = read(fd, buf, buflen - 1);
+	if (numread < 1) {
+		close(fd);
+		return 0;
+	}
+
+	buf[numread] = '\0';
+	close(fd);
+
+	return (unsigned int) numread;
+}
+
+int write_file(const char *path, const char *buf, size_t buflen)
+{
+	int fd;
+	ssize_t numwritten;
+
+	fd = open(path, O_WRONLY);
+	if (fd == -1) {
+		printf("open(%s)\n", path);
+		exit(EXIT_FAILURE);
+		return 0;
+	}
+
+	numwritten = write(fd, buf, buflen - 1);
+	close(fd);
+	if (numwritten < 1) {
+		printf("write(%s)\n", buf);
+		exit(EXIT_FAILURE);
+		return 0;
+	}
+
+	return (unsigned int) numwritten;
+}
+
+const unsigned long read_num(const char *path)
+{
+	char buf[21];
+
+	if (read_file(path, buf, sizeof(buf)) < 0) {
+		perror("read_file()");
+		exit(EXIT_FAILURE);
+	}
+
+	return strtoul(buf, NULL, 10);
+}
+
+void write_num(const char *path, unsigned long num)
+{
+	char buf[21];
+
+	sprintf(buf, "%ld", num);
+	if (!write_file(path, buf, strlen(buf) + 1)) {
+		perror(path);
+		exit(EXIT_FAILURE);
+	}
+}
+
+int thp_read_string(const char *name, const char * const strings[])
+{
+	char path[PATH_MAX];
+	char buf[256];
+	char *c;
+	int ret;
+
+	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
+	if (ret >= PATH_MAX) {
+		printf("%s: Pathname is too long\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+
+	if (!read_file(path, buf, sizeof(buf))) {
+		perror(path);
+		exit(EXIT_FAILURE);
+	}
+
+	c = strchr(buf, '[');
+	if (!c) {
+		printf("%s: Parse failure\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+
+	c++;
+	memmove(buf, c, sizeof(buf) - (c - buf));
+
+	c = strchr(buf, ']');
+	if (!c) {
+		printf("%s: Parse failure\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+	*c = '\0';
+
+	ret = 0;
+	while (strings[ret]) {
+		if (!strcmp(strings[ret], buf))
+			return ret;
+		ret++;
+	}
+
+	printf("Failed to parse %s\n", name);
+	exit(EXIT_FAILURE);
+}
+
+void thp_write_string(const char *name, const char *val)
+{
+	char path[PATH_MAX];
+	int ret;
+
+	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
+	if (ret >= PATH_MAX) {
+		printf("%s: Pathname is too long\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+
+	if (!write_file(path, val, strlen(val) + 1)) {
+		perror(path);
+		exit(EXIT_FAILURE);
+	}
+}
+
+const unsigned long thp_read_num(const char *name)
+{
+	char path[PATH_MAX];
+	int ret;
+
+	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
+	if (ret >= PATH_MAX) {
+		printf("%s: Pathname is too long\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+	return read_num(path);
+}
+
+void thp_write_num(const char *name, unsigned long num)
+{
+	char path[PATH_MAX];
+	int ret;
+
+	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
+	if (ret >= PATH_MAX) {
+		printf("%s: Pathname is too long\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+	write_num(path, num);
+}
+
+void thp_read_settings(struct thp_settings *settings)
+{
+	*settings = (struct thp_settings) {
+		.thp_enabled = thp_read_string("enabled", thp_enabled_strings),
+		.thp_defrag = thp_read_string("defrag", thp_defrag_strings),
+		.shmem_enabled =
+			thp_read_string("shmem_enabled", shmem_enabled_strings),
+		.use_zero_page = thp_read_num("use_zero_page"),
+	};
+	settings->khugepaged = (struct khugepaged_settings) {
+		.defrag = thp_read_num("khugepaged/defrag"),
+		.alloc_sleep_millisecs =
+			thp_read_num("khugepaged/alloc_sleep_millisecs"),
+		.scan_sleep_millisecs =
+			thp_read_num("khugepaged/scan_sleep_millisecs"),
+		.max_ptes_none = thp_read_num("khugepaged/max_ptes_none"),
+		.max_ptes_swap = thp_read_num("khugepaged/max_ptes_swap"),
+		.max_ptes_shared = thp_read_num("khugepaged/max_ptes_shared"),
+		.pages_to_scan = thp_read_num("khugepaged/pages_to_scan"),
+	};
+	if (dev_queue_read_ahead_path[0])
+		settings->read_ahead_kb = read_num(dev_queue_read_ahead_path);
+}
+
+void thp_write_settings(struct thp_settings *settings)
+{
+	struct khugepaged_settings *khugepaged = &settings->khugepaged;
+
+	thp_write_string("enabled", thp_enabled_strings[settings->thp_enabled]);
+	thp_write_string("defrag", thp_defrag_strings[settings->thp_defrag]);
+	thp_write_string("shmem_enabled",
+			shmem_enabled_strings[settings->shmem_enabled]);
+	thp_write_num("use_zero_page", settings->use_zero_page);
+
+	thp_write_num("khugepaged/defrag", khugepaged->defrag);
+	thp_write_num("khugepaged/alloc_sleep_millisecs",
+			khugepaged->alloc_sleep_millisecs);
+	thp_write_num("khugepaged/scan_sleep_millisecs",
+			khugepaged->scan_sleep_millisecs);
+	thp_write_num("khugepaged/max_ptes_none", khugepaged->max_ptes_none);
+	thp_write_num("khugepaged/max_ptes_swap", khugepaged->max_ptes_swap);
+	thp_write_num("khugepaged/max_ptes_shared", khugepaged->max_ptes_shared);
+	thp_write_num("khugepaged/pages_to_scan", khugepaged->pages_to_scan);
+
+	if (dev_queue_read_ahead_path[0])
+		write_num(dev_queue_read_ahead_path, settings->read_ahead_kb);
+}
+
+struct thp_settings *thp_current_settings(void)
+{
+	if (!settings_index) {
+		printf("Fail: No settings set");
+		exit(EXIT_FAILURE);
+	}
+	return settings_stack + settings_index - 1;
+}
+
+void thp_push_settings(struct thp_settings *settings)
+{
+	if (settings_index >= MAX_SETTINGS_DEPTH) {
+		printf("Fail: Settings stack exceeded");
+		exit(EXIT_FAILURE);
+	}
+	settings_stack[settings_index++] = *settings;
+	thp_write_settings(thp_current_settings());
+}
+
+void thp_pop_settings(void)
+{
+	if (settings_index <= 0) {
+		printf("Fail: Settings stack empty");
+		exit(EXIT_FAILURE);
+	}
+	--settings_index;
+	thp_write_settings(thp_current_settings());
+}
+
+void thp_restore_settings(void)
+{
+	thp_write_settings(&saved_settings);
+}
+
+void thp_save_settings(void)
+{
+	thp_read_settings(&saved_settings);
+}
+
+void thp_set_read_ahead_path(char *path)
+{
+	if (!path) {
+		dev_queue_read_ahead_path[0] = '\0';
+		return;
+	}
+
+	strncpy(dev_queue_read_ahead_path, path,
+		sizeof(dev_queue_read_ahead_path));
+	dev_queue_read_ahead_path[sizeof(dev_queue_read_ahead_path) - 1] = '\0';
+}
diff --git a/tools/testing/selftests/mm/thp_settings.h b/tools/testing/selftests/mm/thp_settings.h
new file mode 100644
index 000000000000..ff3d98c30617
--- /dev/null
+++ b/tools/testing/selftests/mm/thp_settings.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __THP_SETTINGS_H__
+#define __THP_SETTINGS_H__
+
+#include <stdbool.h>
+#include <stddef.h>
+#include <stdint.h>
+
+enum thp_enabled {
+	THP_ALWAYS,
+	THP_MADVISE,
+	THP_NEVER,
+};
+
+enum thp_defrag {
+	THP_DEFRAG_ALWAYS,
+	THP_DEFRAG_DEFER,
+	THP_DEFRAG_DEFER_MADVISE,
+	THP_DEFRAG_MADVISE,
+	THP_DEFRAG_NEVER,
+};
+
+enum shmem_enabled {
+	SHMEM_ALWAYS,
+	SHMEM_WITHIN_SIZE,
+	SHMEM_ADVISE,
+	SHMEM_NEVER,
+	SHMEM_DENY,
+	SHMEM_FORCE,
+};
+
+struct khugepaged_settings {
+	bool defrag;
+	unsigned int alloc_sleep_millisecs;
+	unsigned int scan_sleep_millisecs;
+	unsigned int max_ptes_none;
+	unsigned int max_ptes_swap;
+	unsigned int max_ptes_shared;
+	unsigned long pages_to_scan;
+};
+
+struct thp_settings {
+	enum thp_enabled thp_enabled;
+	enum thp_defrag thp_defrag;
+	enum shmem_enabled shmem_enabled;
+	bool use_zero_page;
+	struct khugepaged_settings khugepaged;
+	unsigned long read_ahead_kb;
+};
+
+int read_file(const char *path, char *buf, size_t buflen);
+int write_file(const char *path, const char *buf, size_t buflen);
+const unsigned long read_num(const char *path);
+void write_num(const char *path, unsigned long num);
+
+int thp_read_string(const char *name, const char * const strings[]);
+void thp_write_string(const char *name, const char *val);
+const unsigned long thp_read_num(const char *name);
+void thp_write_num(const char *name, unsigned long num);
+
+void thp_write_settings(struct thp_settings *settings);
+void thp_read_settings(struct thp_settings *settings);
+struct thp_settings *thp_current_settings(void);
+void thp_push_settings(struct thp_settings *settings);
+void thp_pop_settings(void);
+void thp_restore_settings(void);
+void thp_save_settings(void);
+
+void thp_set_read_ahead_path(char *path);
+
+#endif /* __THP_SETTINGS_H__ */
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:24 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:24 +0000
Subject: [PATCH v8 07/10] selftests/mm: Support multi-size THP interface in thp_settings
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-8-ryan.roberts@arm.com>

Save and restore the new per-size hugepage enabled setting, if available
on the running kernel.

Since the number of per-size directories is not fixed, solve this as
simply as possible by catering for a maximum number in the thp_settings
struct (20). Each array index is the order. The value of THP_NEVER is
changed to 0 so that all of these new settings default to THP_NEVER and
the user only needs to fill in the ones they want to enable.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/khugepaged.c   |  3 ++
 tools/testing/selftests/mm/thp_settings.c | 55 ++++++++++++++++++++++-
 tools/testing/selftests/mm/thp_settings.h | 11 ++++-
 3 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
index b15e7fd70176..7bd3baa9d34b 100644
--- a/tools/testing/selftests/mm/khugepaged.c
+++ b/tools/testing/selftests/mm/khugepaged.c
@@ -1141,6 +1141,7 @@ static void parse_test_type(int argc, const char **argv)
 
 int main(int argc, const char **argv)
 {
+	int hpage_pmd_order;
 	struct thp_settings default_settings = {
 		.thp_enabled = THP_MADVISE,
 		.thp_defrag = THP_DEFRAG_ALWAYS,
@@ -1175,11 +1176,13 @@ int main(int argc, const char **argv)
 		exit(EXIT_FAILURE);
 	}
 	hpage_pmd_nr = hpage_pmd_size / page_size;
+	hpage_pmd_order = __builtin_ctz(hpage_pmd_nr);
 
 	default_settings.khugepaged.max_ptes_none = hpage_pmd_nr - 1;
 	default_settings.khugepaged.max_ptes_swap = hpage_pmd_nr / 8;
 	default_settings.khugepaged.max_ptes_shared = hpage_pmd_nr / 2;
 	default_settings.khugepaged.pages_to_scan = hpage_pmd_nr * 8;
+	default_settings.hugepages[hpage_pmd_order].enabled = THP_INHERIT;
 
 	save_settings();
 	thp_push_settings(&default_settings);
diff --git a/tools/testing/selftests/mm/thp_settings.c b/tools/testing/selftests/mm/thp_settings.c
index 5e8ec792cac7..a4163438108e 100644
--- a/tools/testing/selftests/mm/thp_settings.c
+++ b/tools/testing/selftests/mm/thp_settings.c
@@ -16,9 +16,10 @@ static struct thp_settings saved_settings;
 static char dev_queue_read_ahead_path[PATH_MAX];
 
 static const char * const thp_enabled_strings[] = {
+	"never",
 	"always",
+	"inherit",
 	"madvise",
-	"never",
 	NULL
 };
 
@@ -198,6 +199,10 @@ void thp_write_num(const char *name, unsigned long num)
 
 void thp_read_settings(struct thp_settings *settings)
 {
+	unsigned long orders = thp_supported_orders();
+	char path[PATH_MAX];
+	int i;
+
 	*settings = (struct thp_settings) {
 		.thp_enabled = thp_read_string("enabled", thp_enabled_strings),
 		.thp_defrag = thp_read_string("defrag", thp_defrag_strings),
@@ -218,11 +223,26 @@ void thp_read_settings(struct thp_settings *settings)
 	};
 	if (dev_queue_read_ahead_path[0])
 		settings->read_ahead_kb = read_num(dev_queue_read_ahead_path);
+
+	for (i = 0; i < NR_ORDERS; i++) {
+		if (!((1 << i) & orders)) {
+			settings->hugepages[i].enabled = THP_NEVER;
+			continue;
+		}
+		snprintf(path, PATH_MAX, "hugepages-%ukB/enabled",
+			(getpagesize() >> 10) << i);
+		settings->hugepages[i].enabled =
+			thp_read_string(path, thp_enabled_strings);
+	}
 }
 
 void thp_write_settings(struct thp_settings *settings)
 {
 	struct khugepaged_settings *khugepaged = &settings->khugepaged;
+	unsigned long orders = thp_supported_orders();
+	char path[PATH_MAX];
+	int enabled;
+	int i;
 
 	thp_write_string("enabled", thp_enabled_strings[settings->thp_enabled]);
 	thp_write_string("defrag", thp_defrag_strings[settings->thp_defrag]);
@@ -242,6 +262,15 @@ void thp_write_settings(struct thp_settings *settings)
 
 	if (dev_queue_read_ahead_path[0])
 		write_num(dev_queue_read_ahead_path, settings->read_ahead_kb);
+
+	for (i = 0; i < NR_ORDERS; i++) {
+		if (!((1 << i) & orders))
+			continue;
+		snprintf(path, PATH_MAX, "hugepages-%ukB/enabled",
+			(getpagesize() >> 10) << i);
+		enabled = settings->hugepages[i].enabled;
+		thp_write_string(path, thp_enabled_strings[enabled]);
+	}
 }
 
 struct thp_settings *thp_current_settings(void)
@@ -294,3 +323,27 @@ void thp_set_read_ahead_path(char *path)
 		sizeof(dev_queue_read_ahead_path));
 	dev_queue_read_ahead_path[sizeof(dev_queue_read_ahead_path) - 1] = '\0';
 }
+
+unsigned long thp_supported_orders(void)
+{
+	unsigned long orders = 0;
+	char path[PATH_MAX];
+	char buf[256];
+	int ret;
+	int i;
+
+	for (i = 0; i < NR_ORDERS; i++) {
+		ret = snprintf(path, PATH_MAX, THP_SYSFS "hugepages-%ukB/enabled",
+			(getpagesize() >> 10) << i);
+		if (ret >= PATH_MAX) {
+			printf("%s: Pathname is too long\n", __func__);
+			exit(EXIT_FAILURE);
+		}
+
+		ret = read_file(path, buf, sizeof(buf));
+		if (ret)
+			orders |= 1UL << i;
+	}
+
+	return orders;
+}
diff --git a/tools/testing/selftests/mm/thp_settings.h b/tools/testing/selftests/mm/thp_settings.h
index ff3d98c30617..71cbff05f4c7 100644
--- a/tools/testing/selftests/mm/thp_settings.h
+++ b/tools/testing/selftests/mm/thp_settings.h
@@ -7,9 +7,10 @@
 #include <stdint.h>
 
 enum thp_enabled {
+	THP_NEVER,
 	THP_ALWAYS,
+	THP_INHERIT,
 	THP_MADVISE,
-	THP_NEVER,
 };
 
 enum thp_defrag {
@@ -29,6 +30,12 @@ enum shmem_enabled {
 	SHMEM_FORCE,
 };
 
+#define NR_ORDERS 20
+
+struct hugepages_settings {
+	enum thp_enabled enabled;
+};
+
 struct khugepaged_settings {
 	bool defrag;
 	unsigned int alloc_sleep_millisecs;
@@ -46,6 +53,7 @@ struct thp_settings {
 	bool use_zero_page;
 	struct khugepaged_settings khugepaged;
 	unsigned long read_ahead_kb;
+	struct hugepages_settings hugepages[NR_ORDERS];
 };
 
 int read_file(const char *path, char *buf, size_t buflen);
@@ -67,5 +75,6 @@ void thp_restore_settings(void);
 void thp_save_settings(void);
 
 void thp_set_read_ahead_path(char *path);
+unsigned long thp_supported_orders(void);
 
 #endif /* __THP_SETTINGS_H__ */
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:25 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:25 +0000
Subject: [PATCH v8 08/10] selftests/mm/khugepaged: Enlighten for multi-size THP
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-9-ryan.roberts@arm.com>

The `collapse_max_ptes_none` test was previously failing when a THP size
less than PMD-size had enabled="always". The root cause is because the
test faults in 1 page less than the threshold it set for collapsing. But
when THP is enabled always, we "over allocate" and therefore the
threshold is passed, and collapse unexpectedly succeeds.

Solve this by enlightening khugepaged selftest. Add a command line
option to pass in the desired THP size that should be used for all
anonymous allocations. The harness will then explicitly configure a THP
size as requested and modify the `collapse_max_ptes_none` test so that
it faults in the threshold minus the number of pages in the configured
THP size. If no command line option is provided, default to order 0, as
per previous behaviour.

I chose to use an order in the command line interface, since this makes
the interface agnostic of base page size, making it easier to invoke
from run_vmtests.sh.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/khugepaged.c   | 48 +++++++++++++++++------
 tools/testing/selftests/mm/run_vmtests.sh |  2 +
 2 files changed, 39 insertions(+), 11 deletions(-)

diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
index 7bd3baa9d34b..829320a519e7 100644
--- a/tools/testing/selftests/mm/khugepaged.c
+++ b/tools/testing/selftests/mm/khugepaged.c
@@ -28,6 +28,7 @@
 static unsigned long hpage_pmd_size;
 static unsigned long page_size;
 static int hpage_pmd_nr;
+static int anon_order;
 
 #define PID_SMAPS "/proc/self/smaps"
 #define TEST_FILE "collapse_test_file"
@@ -607,6 +608,11 @@ static bool is_tmpfs(struct mem_ops *ops)
 	return ops == &__file_ops && finfo.type == VMA_SHMEM;
 }
 
+static bool is_anon(struct mem_ops *ops)
+{
+	return ops == &__anon_ops;
+}
+
 static void alloc_at_fault(void)
 {
 	struct thp_settings settings = *thp_current_settings();
@@ -673,6 +679,7 @@ static void collapse_max_ptes_none(struct collapse_context *c, struct mem_ops *o
 	int max_ptes_none = hpage_pmd_nr / 2;
 	struct thp_settings settings = *thp_current_settings();
 	void *p;
+	int fault_nr_pages = is_anon(ops) ? 1 << anon_order : 1;
 
 	settings.khugepaged.max_ptes_none = max_ptes_none;
 	thp_push_settings(&settings);
@@ -686,10 +693,10 @@ static void collapse_max_ptes_none(struct collapse_context *c, struct mem_ops *o
 		goto skip;
 	}
 
-	ops->fault(p, 0, (hpage_pmd_nr - max_ptes_none - 1) * page_size);
+	ops->fault(p, 0, (hpage_pmd_nr - max_ptes_none - fault_nr_pages) * page_size);
 	c->collapse("Maybe collapse with max_ptes_none exceeded", p, 1,
 		    ops, !c->enforce_pte_scan_limits);
-	validate_memory(p, 0, (hpage_pmd_nr - max_ptes_none - 1) * page_size);
+	validate_memory(p, 0, (hpage_pmd_nr - max_ptes_none - fault_nr_pages) * page_size);
 
 	if (c->enforce_pte_scan_limits) {
 		ops->fault(p, 0, (hpage_pmd_nr - max_ptes_none) * page_size);
@@ -1076,7 +1083,7 @@ static void madvise_retracted_page_tables(struct collapse_context *c,
 
 static void usage(void)
 {
-	fprintf(stderr, "\nUsage: ./khugepaged <test type> [dir]\n\n");
+	fprintf(stderr, "\nUsage: ./khugepaged [OPTIONS] <test type> [dir]\n\n");
 	fprintf(stderr, "\t<test type>\t: <context>:<mem_type>\n");
 	fprintf(stderr, "\t<context>\t: [all|khugepaged|madvise]\n");
 	fprintf(stderr, "\t<mem_type>\t: [all|anon|file|shmem]\n");
@@ -1085,15 +1092,34 @@ static void usage(void)
 	fprintf(stderr,	"\tCONFIG_READ_ONLY_THP_FOR_FS=y\n");
 	fprintf(stderr, "\n\tif [dir] is a (sub)directory of a tmpfs mount, tmpfs must be\n");
 	fprintf(stderr,	"\tmounted with huge=madvise option for khugepaged tests to work\n");
+	fprintf(stderr,	"\n\tSupported Options:\n");
+	fprintf(stderr,	"\t\t-h: This help message.\n");
+	fprintf(stderr,	"\t\t-s: mTHP size, expressed as page order.\n");
+	fprintf(stderr,	"\t\t    Defaults to 0. Use this size for anon allocations.\n");
 	exit(1);
 }
 
-static void parse_test_type(int argc, const char **argv)
+static void parse_test_type(int argc, char **argv)
 {
+	int opt;
 	char *buf;
 	const char *token;
 
-	if (argc == 1) {
+	while ((opt = getopt(argc, argv, "s:h")) != -1) {
+		switch (opt) {
+		case 's':
+			anon_order = atoi(optarg);
+			break;
+		case 'h':
+		default:
+			usage();
+		}
+	}
+
+	argv += optind;
+	argc -= optind;
+
+	if (argc == 0) {
 		/* Backwards compatibility */
 		khugepaged_context =  &__khugepaged_context;
 		madvise_context =  &__madvise_context;
@@ -1101,7 +1127,7 @@ static void parse_test_type(int argc, const char **argv)
 		return;
 	}
 
-	buf = strdup(argv[1]);
+	buf = strdup(argv[0]);
 	token = strsep(&buf, ":");
 
 	if (!strcmp(token, "all")) {
@@ -1135,11 +1161,13 @@ static void parse_test_type(int argc, const char **argv)
 	if (!file_ops)
 		return;
 
-	if (argc != 3)
+	if (argc != 2)
 		usage();
+
+	get_finfo(argv[1]);
 }
 
-int main(int argc, const char **argv)
+int main(int argc, char **argv)
 {
 	int hpage_pmd_order;
 	struct thp_settings default_settings = {
@@ -1164,9 +1192,6 @@ int main(int argc, const char **argv)
 
 	parse_test_type(argc, argv);
 
-	if (file_ops)
-		get_finfo(argv[2]);
-
 	setbuf(stdout, NULL);
 
 	page_size = getpagesize();
@@ -1183,6 +1208,7 @@ int main(int argc, const char **argv)
 	default_settings.khugepaged.max_ptes_shared = hpage_pmd_nr / 2;
 	default_settings.khugepaged.pages_to_scan = hpage_pmd_nr * 8;
 	default_settings.hugepages[hpage_pmd_order].enabled = THP_INHERIT;
+	default_settings.hugepages[anon_order].enabled = THP_ALWAYS;
 
 	save_settings();
 	thp_push_settings(&default_settings);
diff --git a/tools/testing/selftests/mm/run_vmtests.sh b/tools/testing/selftests/mm/run_vmtests.sh
index c0212258b852..87f513f5cf91 100755
--- a/tools/testing/selftests/mm/run_vmtests.sh
+++ b/tools/testing/selftests/mm/run_vmtests.sh
@@ -357,6 +357,8 @@ CATEGORY="cow" run_test ./cow
 
 CATEGORY="thp" run_test ./khugepaged
 
+CATEGORY="thp" run_test ./khugepaged -s 2
+
 CATEGORY="thp" run_test ./transhuge-stress -d 20
 
 CATEGORY="thp" run_test ./split_huge_page_test
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:27 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:27 +0000
Subject: [PATCH v8 10/10] selftests/mm/cow: Add tests for anonymous multi-size THP
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-11-ryan.roberts@arm.com>

Add tests similar to the existing PMD-sized THP tests, but which operate
on memory backed by (PTE-mapped) multi-size THP. This reuses all the
existing infrastructure. If the test suite detects that multi-size THP
is not supported by the kernel, the new tests are skipped.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/cow.c | 84 +++++++++++++++++++++++++++-----
 1 file changed, 72 insertions(+), 12 deletions(-)

diff --git a/tools/testing/selftests/mm/cow.c b/tools/testing/selftests/mm/cow.c
index 4d0b5a125d3c..37b4d7d28ae9 100644
--- a/tools/testing/selftests/mm/cow.c
+++ b/tools/testing/selftests/mm/cow.c
@@ -29,15 +29,49 @@
 #include "../../../../mm/gup_test.h"
 #include "../kselftest.h"
 #include "vm_util.h"
+#include "thp_settings.h"
 
 static size_t pagesize;
 static int pagemap_fd;
 static size_t pmdsize;
+static int nr_thpsizes;
+static size_t thpsizes[20];
 static int nr_hugetlbsizes;
 static size_t hugetlbsizes[10];
 static int gup_fd;
 static bool has_huge_zeropage;
 
+static int sz2ord(size_t size)
+{
+	return __builtin_ctzll(size / pagesize);
+}
+
+static int detect_thp_sizes(size_t sizes[], int max)
+{
+	int count = 0;
+	unsigned long orders;
+	size_t kb;
+	int i;
+
+	/* thp not supported at all. */
+	if (!pmdsize)
+		return 0;
+
+	orders = 1UL << sz2ord(pmdsize);
+	orders |= thp_supported_orders();
+
+	for (i = 0; orders && count < max; i++) {
+		if (!(orders & (1UL << i)))
+			continue;
+		orders &= ~(1UL << i);
+		kb = (pagesize >> 10) << i;
+		sizes[count++] = kb * 1024;
+		ksft_print_msg("[INFO] detected THP size: %zu KiB\n", kb);
+	}
+
+	return count;
+}
+
 static void detect_huge_zeropage(void)
 {
 	int fd = open("/sys/kernel/mm/transparent_hugepage/use_zero_page",
@@ -1101,15 +1135,27 @@ static void run_anon_test_case(struct test_case const *test_case)
 
 	run_with_base_page(test_case->fn, test_case->desc);
 	run_with_base_page_swap(test_case->fn, test_case->desc);
-	if (pmdsize) {
-		run_with_thp(test_case->fn, test_case->desc, pmdsize);
-		run_with_thp_swap(test_case->fn, test_case->desc, pmdsize);
-		run_with_pte_mapped_thp(test_case->fn, test_case->desc, pmdsize);
-		run_with_pte_mapped_thp_swap(test_case->fn, test_case->desc, pmdsize);
-		run_with_single_pte_of_thp(test_case->fn, test_case->desc, pmdsize);
-		run_with_single_pte_of_thp_swap(test_case->fn, test_case->desc, pmdsize);
-		run_with_partial_mremap_thp(test_case->fn, test_case->desc, pmdsize);
-		run_with_partial_shared_thp(test_case->fn, test_case->desc, pmdsize);
+	for (i = 0; i < nr_thpsizes; i++) {
+		size_t size = thpsizes[i];
+		struct thp_settings settings = *thp_current_settings();
+
+		settings.hugepages[sz2ord(pmdsize)].enabled = THP_NEVER;
+		settings.hugepages[sz2ord(size)].enabled = THP_ALWAYS;
+		thp_push_settings(&settings);
+
+		if (size == pmdsize) {
+			run_with_thp(test_case->fn, test_case->desc, size);
+			run_with_thp_swap(test_case->fn, test_case->desc, size);
+		}
+
+		run_with_pte_mapped_thp(test_case->fn, test_case->desc, size);
+		run_with_pte_mapped_thp_swap(test_case->fn, test_case->desc, size);
+		run_with_single_pte_of_thp(test_case->fn, test_case->desc, size);
+		run_with_single_pte_of_thp_swap(test_case->fn, test_case->desc, size);
+		run_with_partial_mremap_thp(test_case->fn, test_case->desc, size);
+		run_with_partial_shared_thp(test_case->fn, test_case->desc, size);
+
+		thp_pop_settings();
 	}
 	for (i = 0; i < nr_hugetlbsizes; i++)
 		run_with_hugetlb(test_case->fn, test_case->desc,
@@ -1130,8 +1176,9 @@ static int tests_per_anon_test_case(void)
 {
 	int tests = 2 + nr_hugetlbsizes;
 
+	tests += 6 * nr_thpsizes;
 	if (pmdsize)
-		tests += 8;
+		tests += 2;
 	return tests;
 }
 
@@ -1689,15 +1736,23 @@ static int tests_per_non_anon_test_case(void)
 int main(int argc, char **argv)
 {
 	int err;
+	struct thp_settings default_settings;
 
 	pagesize = getpagesize();
 	pmdsize = read_pmd_pagesize();
 	if (pmdsize) {
+		/* Only if THP is supported. */
+		thp_read_settings(&default_settings);
+		default_settings.hugepages[sz2ord(pmdsize)].enabled = THP_INHERIT;
+		thp_save_settings();
+		thp_push_settings(&default_settings);
+
 		ksft_print_msg("[INFO] detected PMD size: %zu KiB\n",
 			       pmdsize / 1024);
-		ksft_print_msg("[INFO] detected THP size: %zu KiB\n",
-			       pmdsize / 1024);
+
+		nr_thpsizes = detect_thp_sizes(thpsizes, ARRAY_SIZE(thpsizes));
 	}
+
 	nr_hugetlbsizes = detect_hugetlb_page_sizes(hugetlbsizes,
 						    ARRAY_SIZE(hugetlbsizes));
 	detect_huge_zeropage();
@@ -1716,6 +1771,11 @@ int main(int argc, char **argv)
 	run_anon_thp_test_cases();
 	run_non_anon_test_cases();
 
+	if (pmdsize) {
+		/* Only if THP is supported. */
+		thp_restore_settings();
+	}
+
 	err = ksft_get_fail_cnt();
 	if (err)
 		ksft_exit_fail_msg("%d out of %d tests failed\n",
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:20:26 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:20:26 +0000
Subject: [PATCH v8 09/10] selftests/mm/cow: Generalize do_run_with_thp() helper
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204102027.57185-10-ryan.roberts@arm.com>

do_run_with_thp() prepares (PMD-sized) THP memory into different states
before running tests. With the introduction of multi-size THP, we would
like to reuse this logic to also test those smaller THP sizes. So let's
add a thpsize parameter which tells the function what size THP it should
operate on.

A separate commit will utilize this change to add new tests for
multi-size THP, where available.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/cow.c | 121 +++++++++++++++++--------------
 1 file changed, 67 insertions(+), 54 deletions(-)

diff --git a/tools/testing/selftests/mm/cow.c b/tools/testing/selftests/mm/cow.c
index 7324ce5363c0..4d0b5a125d3c 100644
--- a/tools/testing/selftests/mm/cow.c
+++ b/tools/testing/selftests/mm/cow.c
@@ -32,7 +32,7 @@
 
 static size_t pagesize;
 static int pagemap_fd;
-static size_t thpsize;
+static size_t pmdsize;
 static int nr_hugetlbsizes;
 static size_t hugetlbsizes[10];
 static int gup_fd;
@@ -734,7 +734,7 @@ enum thp_run {
 	THP_RUN_PARTIAL_SHARED,
 };
 
-static void do_run_with_thp(test_fn fn, enum thp_run thp_run)
+static void do_run_with_thp(test_fn fn, enum thp_run thp_run, size_t thpsize)
 {
 	char *mem, *mmap_mem, *tmp, *mremap_mem = MAP_FAILED;
 	size_t size, mmap_size, mremap_size;
@@ -759,11 +759,11 @@ static void do_run_with_thp(test_fn fn, enum thp_run thp_run)
 	}
 
 	/*
-	 * Try to populate a THP. Touch the first sub-page and test if we get
-	 * another sub-page populated automatically.
+	 * Try to populate a THP. Touch the first sub-page and test if
+	 * we get the last sub-page populated automatically.
 	 */
 	mem[0] = 0;
-	if (!pagemap_is_populated(pagemap_fd, mem + pagesize)) {
+	if (!pagemap_is_populated(pagemap_fd, mem + thpsize - pagesize)) {
 		ksft_test_result_skip("Did not get a THP populated\n");
 		goto munmap;
 	}
@@ -773,12 +773,14 @@ static void do_run_with_thp(test_fn fn, enum thp_run thp_run)
 	switch (thp_run) {
 	case THP_RUN_PMD:
 	case THP_RUN_PMD_SWAPOUT:
+		assert(thpsize == pmdsize);
 		break;
 	case THP_RUN_PTE:
 	case THP_RUN_PTE_SWAPOUT:
 		/*
 		 * Trigger PTE-mapping the THP by temporarily mapping a single
-		 * subpage R/O.
+		 * subpage R/O. This is a noop if the THP is not pmdsize (and
+		 * therefore already PTE-mapped).
 		 */
 		ret = mprotect(mem + pagesize, pagesize, PROT_READ);
 		if (ret) {
@@ -875,52 +877,60 @@ static void do_run_with_thp(test_fn fn, enum thp_run thp_run)
 		munmap(mremap_mem, mremap_size);
 }
 
-static void run_with_thp(test_fn fn, const char *desc)
+static void run_with_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PMD);
+	ksft_print_msg("[RUN] %s ... with THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PMD, size);
 }
 
-static void run_with_thp_swap(test_fn fn, const char *desc)
+static void run_with_thp_swap(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with swapped-out THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PMD_SWAPOUT);
+	ksft_print_msg("[RUN] %s ... with swapped-out THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PMD_SWAPOUT, size);
 }
 
-static void run_with_pte_mapped_thp(test_fn fn, const char *desc)
+static void run_with_pte_mapped_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with PTE-mapped THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PTE);
+	ksft_print_msg("[RUN] %s ... with PTE-mapped THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PTE, size);
 }
 
-static void run_with_pte_mapped_thp_swap(test_fn fn, const char *desc)
+static void run_with_pte_mapped_thp_swap(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with swapped-out, PTE-mapped THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PTE_SWAPOUT);
+	ksft_print_msg("[RUN] %s ... with swapped-out, PTE-mapped THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PTE_SWAPOUT, size);
 }
 
-static void run_with_single_pte_of_thp(test_fn fn, const char *desc)
+static void run_with_single_pte_of_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with single PTE of THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_SINGLE_PTE);
+	ksft_print_msg("[RUN] %s ... with single PTE of THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_SINGLE_PTE, size);
 }
 
-static void run_with_single_pte_of_thp_swap(test_fn fn, const char *desc)
+static void run_with_single_pte_of_thp_swap(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with single PTE of swapped-out THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_SINGLE_PTE_SWAPOUT);
+	ksft_print_msg("[RUN] %s ... with single PTE of swapped-out THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_SINGLE_PTE_SWAPOUT, size);
 }
 
-static void run_with_partial_mremap_thp(test_fn fn, const char *desc)
+static void run_with_partial_mremap_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with partially mremap()'ed THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PARTIAL_MREMAP);
+	ksft_print_msg("[RUN] %s ... with partially mremap()'ed THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PARTIAL_MREMAP, size);
 }
 
-static void run_with_partial_shared_thp(test_fn fn, const char *desc)
+static void run_with_partial_shared_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with partially shared THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PARTIAL_SHARED);
+	ksft_print_msg("[RUN] %s ... with partially shared THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PARTIAL_SHARED, size);
 }
 
 static void run_with_hugetlb(test_fn fn, const char *desc, size_t hugetlbsize)
@@ -1091,15 +1101,15 @@ static void run_anon_test_case(struct test_case const *test_case)
 
 	run_with_base_page(test_case->fn, test_case->desc);
 	run_with_base_page_swap(test_case->fn, test_case->desc);
-	if (thpsize) {
-		run_with_thp(test_case->fn, test_case->desc);
-		run_with_thp_swap(test_case->fn, test_case->desc);
-		run_with_pte_mapped_thp(test_case->fn, test_case->desc);
-		run_with_pte_mapped_thp_swap(test_case->fn, test_case->desc);
-		run_with_single_pte_of_thp(test_case->fn, test_case->desc);
-		run_with_single_pte_of_thp_swap(test_case->fn, test_case->desc);
-		run_with_partial_mremap_thp(test_case->fn, test_case->desc);
-		run_with_partial_shared_thp(test_case->fn, test_case->desc);
+	if (pmdsize) {
+		run_with_thp(test_case->fn, test_case->desc, pmdsize);
+		run_with_thp_swap(test_case->fn, test_case->desc, pmdsize);
+		run_with_pte_mapped_thp(test_case->fn, test_case->desc, pmdsize);
+		run_with_pte_mapped_thp_swap(test_case->fn, test_case->desc, pmdsize);
+		run_with_single_pte_of_thp(test_case->fn, test_case->desc, pmdsize);
+		run_with_single_pte_of_thp_swap(test_case->fn, test_case->desc, pmdsize);
+		run_with_partial_mremap_thp(test_case->fn, test_case->desc, pmdsize);
+		run_with_partial_shared_thp(test_case->fn, test_case->desc, pmdsize);
 	}
 	for (i = 0; i < nr_hugetlbsizes; i++)
 		run_with_hugetlb(test_case->fn, test_case->desc,
@@ -1120,7 +1130,7 @@ static int tests_per_anon_test_case(void)
 {
 	int tests = 2 + nr_hugetlbsizes;
 
-	if (thpsize)
+	if (pmdsize)
 		tests += 8;
 	return tests;
 }
@@ -1329,7 +1339,7 @@ static void run_anon_thp_test_cases(void)
 {
 	int i;
 
-	if (!thpsize)
+	if (!pmdsize)
 		return;
 
 	ksft_print_msg("[INFO] Anonymous THP tests\n");
@@ -1338,13 +1348,13 @@ static void run_anon_thp_test_cases(void)
 		struct test_case const *test_case = &anon_thp_test_cases[i];
 
 		ksft_print_msg("[RUN] %s\n", test_case->desc);
-		do_run_with_thp(test_case->fn, THP_RUN_PMD);
+		do_run_with_thp(test_case->fn, THP_RUN_PMD, pmdsize);
 	}
 }
 
 static int tests_per_anon_thp_test_case(void)
 {
-	return thpsize ? 1 : 0;
+	return pmdsize ? 1 : 0;
 }
 
 typedef void (*non_anon_test_fn)(char *mem, const char *smem, size_t size);
@@ -1419,7 +1429,7 @@ static void run_with_huge_zeropage(non_anon_test_fn fn, const char *desc)
 	}
 
 	/* For alignment purposes, we need twice the thp size. */
-	mmap_size = 2 * thpsize;
+	mmap_size = 2 * pmdsize;
 	mmap_mem = mmap(NULL, mmap_size, PROT_READ | PROT_WRITE,
 			MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
 	if (mmap_mem == MAP_FAILED) {
@@ -1434,11 +1444,11 @@ static void run_with_huge_zeropage(non_anon_test_fn fn, const char *desc)
 	}
 
 	/* We need a THP-aligned memory area. */
-	mem = (char *)(((uintptr_t)mmap_mem + thpsize) & ~(thpsize - 1));
-	smem = (char *)(((uintptr_t)mmap_smem + thpsize) & ~(thpsize - 1));
+	mem = (char *)(((uintptr_t)mmap_mem + pmdsize) & ~(pmdsize - 1));
+	smem = (char *)(((uintptr_t)mmap_smem + pmdsize) & ~(pmdsize - 1));
 
-	ret = madvise(mem, thpsize, MADV_HUGEPAGE);
-	ret |= madvise(smem, thpsize, MADV_HUGEPAGE);
+	ret = madvise(mem, pmdsize, MADV_HUGEPAGE);
+	ret |= madvise(smem, pmdsize, MADV_HUGEPAGE);
 	if (ret) {
 		ksft_test_result_fail("MADV_HUGEPAGE failed\n");
 		goto munmap;
@@ -1457,7 +1467,7 @@ static void run_with_huge_zeropage(non_anon_test_fn fn, const char *desc)
 		goto munmap;
 	}
 
-	fn(mem, smem, thpsize);
+	fn(mem, smem, pmdsize);
 munmap:
 	munmap(mmap_mem, mmap_size);
 	if (mmap_smem != MAP_FAILED)
@@ -1650,7 +1660,7 @@ static void run_non_anon_test_case(struct non_anon_test_case const *test_case)
 	run_with_zeropage(test_case->fn, test_case->desc);
 	run_with_memfd(test_case->fn, test_case->desc);
 	run_with_tmpfile(test_case->fn, test_case->desc);
-	if (thpsize)
+	if (pmdsize)
 		run_with_huge_zeropage(test_case->fn, test_case->desc);
 	for (i = 0; i < nr_hugetlbsizes; i++)
 		run_with_memfd_hugetlb(test_case->fn, test_case->desc,
@@ -1671,7 +1681,7 @@ static int tests_per_non_anon_test_case(void)
 {
 	int tests = 3 + nr_hugetlbsizes;
 
-	if (thpsize)
+	if (pmdsize)
 		tests += 1;
 	return tests;
 }
@@ -1681,10 +1691,13 @@ int main(int argc, char **argv)
 	int err;
 
 	pagesize = getpagesize();
-	thpsize = read_pmd_pagesize();
-	if (thpsize)
+	pmdsize = read_pmd_pagesize();
+	if (pmdsize) {
+		ksft_print_msg("[INFO] detected PMD size: %zu KiB\n",
+			       pmdsize / 1024);
 		ksft_print_msg("[INFO] detected THP size: %zu KiB\n",
-			       thpsize / 1024);
+			       pmdsize / 1024);
+	}
 	nr_hugetlbsizes = detect_hugetlb_page_sizes(hugetlbsizes,
 						    ARRAY_SIZE(hugetlbsizes));
 	detect_huge_zeropage();
-- 
2.25.1



From james.clark at arm.com  Mon Dec  4 02:23:49 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 4 Dec 2023 10:23:49 +0000
Subject: [PATCH V2 6/7] coresight: stm: Move ACPI support from AMBA driver
 to platform driver
In-Reply-To: <20231201062053.1268492-7-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-7-anshuman.khandual@arm.com>
Message-ID: <0adc3a16-0fc4-2a25-cd48-4667881b9490@arm.com>



On 01/12/2023 06:20, Anshuman Khandual wrote:
> Add support for the stm devices in the platform driver, which can then be
> used on ACPI based platforms. This change would now allow runtime power
> management for ACPI based systems. The driver would try to enable the APB
> clock if available.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Cc: Mike Leach <mike.leach at linaro.org>
> Cc: James Clark <james.clark at arm.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> Cc: linux-acpi at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: coresight at lists.linaro.org
> Cc: linux-stm32 at st-md-mailman.stormreply.com
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
[...]
>  
> -module_amba_driver(stm_driver);
> +static int stm_platform_probe(struct platform_device *pdev)
> +{
> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	int ret = 0;
> +
> +	pm_runtime_get_noresume(&pdev->dev);
> +	pm_runtime_set_active(&pdev->dev);
> +	pm_runtime_enable(&pdev->dev);
> +
> +	ret = __stm_probe(&pdev->dev, res, NULL);

Very minor nit, but this used to print this:

  coresight stm0: STM500 initialized

And now it prints this:

  coresight stm0: (null) initialized

(null) kind of makes it look a little bit like something has gone wrong.
Maybe we could just put "initialised" if you don't have a string from ACPI?


From maxime.chevallier at bootlin.com  Mon Dec  4 02:36:40 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Mon, 4 Dec 2023 11:36:40 +0100
Subject: [RFC PATCH net-next v3 06/13] netlink: specs: add phy-index as
 a header parameter
In-Reply-To: <20231201163704.1306431-7-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
	<20231201163704.1306431-7-maxime.chevallier@bootlin.com>
Message-ID: <20231204113640.508ac88b@device.home>

Hi Jakub,

On Fri,  1 Dec 2023 17:36:56 +0100
Maxime Chevallier <maxime.chevallier at bootlin.com> wrote:

> Update the spec to take the newly introduced phy-index as a generic
> request parameter, and bump the generated ethtool-user.c|h accordingly.

Just saw
https://lore.kernel.org/netdev/20231202211759.343719-1-kuba at kernel.org/

I'll drop the ethtool-user stuff from next versions then, sorry for the
noise

Maxime


From hawk at kernel.org  Mon Dec  4 02:36:30 2023
From: hawk at kernel.org (Jesper Dangaard Brouer)
Date: Mon, 4 Dec 2023 11:36:30 +0100
Subject: [PATCH bpf-next v3 2/3] net: stmmac: add Launch Time support to
 XDP ZC
In-Reply-To: <20231203165129.1740512-3-yoong.siang.song@intel.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com>
Message-ID: <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>



On 12/3/23 17:51, Song Yoong Siang wrote:
> This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> copy via XDP Tx metadata framework.
> 
> Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> ---
>   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++

As requested before, I think we need to see another driver implementing 
this.

I propose driver igc and chip i225.

The interesting thing for me is to see how the LaunchTime max 1 second
into the future[1] is handled code wise. One suggestion is to add a 
section to Documentation/networking/xsk-tx-metadata.rst per driver that 
mentions/documents these different hardware limitations.  It is natural 
that different types of hardware have limitations.  This is a close-to 
hardware-level abstraction/API, and IMHO as long as we document the 
limitations we can expose this API without too many limitations for more 
capable hardware.

  [1] 
https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org#setup-code-driver-igb

This stmmac driver and Intel Tiger Lake CPU must also have some limit on 
how long into the future it will/can schedule packets?


People from xdp-hints list must make their voice hear if they want i210 
and igb driver support, because it have even-more hardware limitations, 
see [1] (E.g. only TX queue 0 and 1 supports LaunchTime). BUT I know 
some have this hardware in production and might be motivated to get a 
functioning driver with this feature?

--Jesper


From maxime.chevallier at bootlin.com  Mon Dec  4 02:37:32 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Mon, 4 Dec 2023 11:37:32 +0100
Subject: [RFC PATCH net-next v3 08/13] netlink: specs: add ethnl PHY_GET
 command set
In-Reply-To: <20231201163704.1306431-9-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
	<20231201163704.1306431-9-maxime.chevallier@bootlin.com>
Message-ID: <20231204113732.052e1b78@device.home>

Hi all,

On Fri,  1 Dec 2023 17:36:58 +0100
Maxime Chevallier <maxime.chevallier at bootlin.com> wrote:

> The PHY_GET command, supporting both DUMP and GET operations, is used to
> retrieve the list of PHYs connected to a netdevice, and get topology
> information to know where exactly it sits on the physical link.
> 
> Add the netlink specs corresponding to that command, and bump the
> ethtool-user.c|h autogenerated files.

Same as for patch 06, I'll drop the ethtool-user stuff for next version.

Maxime


From r-gunasekaran at ti.com  Mon Dec  4 02:38:12 2023
From: r-gunasekaran at ti.com (Ravi Gunasekaran)
Date: Mon, 4 Dec 2023 16:08:12 +0530
Subject: [PATCH] arm64: defconfig: Enable TI_ICSSG_PRUETH
In-Reply-To: <20231128084537.3946895-1-danishanwar@ti.com>
References: <20231128084537.3946895-1-danishanwar@ti.com>
Message-ID: <72148985-6ed3-85d3-1a67-56e6cb25ac6c@ti.com>



On 11/28/23 2:15 PM, MD Danish Anwar wrote:
> The Programmable Real-time Unit and Industrial Communication Subsystem
> Gigabit (PRU_ICSSG) is a low-latency microcontroller subsystem in the TI
> K3 SoCs such as AM654x, AM64x. This subsystem is provided for the use
> cases like implementation of custom peripheral interfaces, offloading of
> tasks from the other processor cores of the SoC, etc.
> 
> Currently AM654x-EVM uses ICSSG driver.
> 
> Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 5ad2b841aafc..145ee4858c50 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -368,6 +368,7 @@ CONFIG_SNI_NETSEC=y
>  CONFIG_STMMAC_ETH=m
>  CONFIG_DWMAC_TEGRA=m
>  CONFIG_TI_K3_AM65_CPSW_NUSS=y
> +CONFIG_TI_ICSSG_PRUETH=m
>  CONFIG_QCOM_IPA=m
>  CONFIG_MESON_GXL_PHY=m
>  CONFIG_AQUANTIA_PHY=y

Reviewed-by: Ravi Gunasekaran <r-gunasekaran at ti.com>

-- 
Regards,
Ravi


From james.clark at arm.com  Mon Dec  4 02:42:10 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 4 Dec 2023 10:42:10 +0000
Subject: [PATCH V2 5/7] coresight: tmc: Move ACPI support from AMBA driver
 to platform driver
In-Reply-To: <20231201062053.1268492-6-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-6-anshuman.khandual@arm.com>
Message-ID: <12a9c5da-4b96-78de-4007-211989bdcfa3@arm.com>



On 01/12/2023 06:20, Anshuman Khandual wrote:
> Add support for the tmc devices in the platform driver, which can then be
> used on ACPI based platforms. This change would now allow runtime power
> management for ACPI based systems. The driver would try to enable the APB
> clock if available.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Cc: Mike Leach <mike.leach at linaro.org>
> Cc: James Clark <james.clark at arm.com>
> Cc: linux-acpi at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: coresight at lists.linaro.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
>  drivers/acpi/arm64/amba.c                     |   2 -
>  .../hwtracing/coresight/coresight-tmc-core.c  | 130 +++++++++++++++---
>  drivers/hwtracing/coresight/coresight-tmc.h   |   1 +
>  3 files changed, 115 insertions(+), 18 deletions(-)
> 
[...]
> -static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
> +static int __tmc_probe(struct device *dev, struct resource *res, void *dev_caps)
>  {
>  	int ret = 0;
>  	u32 devid;
>  	void __iomem *base;
> -	struct device *dev = &adev->dev;
>  	struct coresight_platform_data *pdata = NULL;
> -	struct tmc_drvdata *drvdata;
> -	struct resource *res = &adev->res;
> +	struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
>  	struct coresight_desc desc = { 0 };
>  	struct coresight_dev_list *dev_list = NULL;
>  
>  	ret = -ENOMEM;
> -	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> -	if (!drvdata)
> -		goto out;
> -
> -	dev_set_drvdata(dev, drvdata);
>  
>  	/* Validity for the resource is already checked by the AMBA core */
>  	base = devm_ioremap_resource(dev, res);
> @@ -487,8 +482,7 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
>  		desc.type = CORESIGHT_DEV_TYPE_SINK;
>  		desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM;
>  		desc.ops = &tmc_etr_cs_ops;
> -		ret = tmc_etr_setup_caps(dev, devid,
> -					 coresight_get_uci_data(id));
> +		ret = tmc_etr_setup_caps(dev, devid, dev_caps);
>  		if (ret)
>  			goto out;
[...]
> -module_amba_driver(tmc_driver);
> +static int tmc_platform_probe(struct platform_device *pdev)
> +{
> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	struct tmc_drvdata *drvdata;
> +	int ret = 0;
> +
> +	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (!drvdata)
> +		return -ENOMEM;
> +
> +	drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
> +	if (IS_ERR(drvdata->pclk))
> +		return -ENODEV;
> +
> +	dev_set_drvdata(&pdev->dev, drvdata);
> +	pm_runtime_get_noresume(&pdev->dev);
> +	pm_runtime_set_active(&pdev->dev);
> +	pm_runtime_enable(&pdev->dev);
> +
> +	ret = __tmc_probe(&pdev->dev, res, NULL);

What effect does passing NULL here have? It seems like the dev_caps did
something useful when it's set to CORESIGHT_SOC_600_ETR_CAPS. Maybe
Suzuki knows as he added it?


From suzuki.poulose at arm.com  Mon Dec  4 02:50:42 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 4 Dec 2023 10:50:42 +0000
Subject: [PATCH V2 5/7] coresight: tmc: Move ACPI support from AMBA driver
 to platform driver
In-Reply-To: <12a9c5da-4b96-78de-4007-211989bdcfa3@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-6-anshuman.khandual@arm.com>
 <12a9c5da-4b96-78de-4007-211989bdcfa3@arm.com>
Message-ID: <d24b5a25-1a1b-4de5-95ff-c49ca8f8101c@arm.com>

On 04/12/2023 10:42, James Clark wrote:
> 
> 
> On 01/12/2023 06:20, Anshuman Khandual wrote:
>> Add support for the tmc devices in the platform driver, which can then be
>> used on ACPI based platforms. This change would now allow runtime power
>> management for ACPI based systems. The driver would try to enable the APB
>> clock if available.
>>
>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Cc: Mike Leach <mike.leach at linaro.org>
>> Cc: James Clark <james.clark at arm.com>
>> Cc: linux-acpi at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: coresight at lists.linaro.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>>   drivers/acpi/arm64/amba.c                     |   2 -
>>   .../hwtracing/coresight/coresight-tmc-core.c  | 130 +++++++++++++++---
>>   drivers/hwtracing/coresight/coresight-tmc.h   |   1 +
>>   3 files changed, 115 insertions(+), 18 deletions(-)
>>
> [...]
>> -static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
>> +static int __tmc_probe(struct device *dev, struct resource *res, void *dev_caps)
>>   {
>>   	int ret = 0;
>>   	u32 devid;
>>   	void __iomem *base;
>> -	struct device *dev = &adev->dev;
>>   	struct coresight_platform_data *pdata = NULL;
>> -	struct tmc_drvdata *drvdata;
>> -	struct resource *res = &adev->res;
>> +	struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
>>   	struct coresight_desc desc = { 0 };
>>   	struct coresight_dev_list *dev_list = NULL;
>>   
>>   	ret = -ENOMEM;
>> -	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>> -	if (!drvdata)
>> -		goto out;
>> -
>> -	dev_set_drvdata(dev, drvdata);
>>   
>>   	/* Validity for the resource is already checked by the AMBA core */
>>   	base = devm_ioremap_resource(dev, res);
>> @@ -487,8 +482,7 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
>>   		desc.type = CORESIGHT_DEV_TYPE_SINK;
>>   		desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM;
>>   		desc.ops = &tmc_etr_cs_ops;
>> -		ret = tmc_etr_setup_caps(dev, devid,
>> -					 coresight_get_uci_data(id));
>> +		ret = tmc_etr_setup_caps(dev, devid, dev_caps);
>>   		if (ret)
>>   			goto out;
> [...]
>> -module_amba_driver(tmc_driver);
>> +static int tmc_platform_probe(struct platform_device *pdev)
>> +{
>> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +	struct tmc_drvdata *drvdata;
>> +	int ret = 0;
>> +
>> +	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
>> +	if (!drvdata)
>> +		return -ENOMEM;
>> +
>> +	drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
>> +	if (IS_ERR(drvdata->pclk))
>> +		return -ENODEV;
>> +
>> +	dev_set_drvdata(&pdev->dev, drvdata);
>> +	pm_runtime_get_noresume(&pdev->dev);
>> +	pm_runtime_set_active(&pdev->dev);
>> +	pm_runtime_enable(&pdev->dev);
>> +
>> +	ret = __tmc_probe(&pdev->dev, res, NULL);
> 
> What effect does passing NULL here have? It seems like the dev_caps did
> something useful when it's set to CORESIGHT_SOC_600_ETR_CAPS. Maybe
> Suzuki knows as he added it?

That was supposed to initialise the capabilities of the TMC-ETR, which
are not discoverable by ID registers. (e.g., SAVE restore of RRP/RWP).
I guess, we could get rid of that cap and use the "PID" register match
to figure out the capabilities.

Suzuki




From james.clark at arm.com  Mon Dec  4 02:54:15 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 4 Dec 2023 10:54:15 +0000
Subject: [PATCH V2 5/7] coresight: tmc: Move ACPI support from AMBA driver
 to platform driver
In-Reply-To: <20231201062053.1268492-6-anshuman.khandual@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-6-anshuman.khandual@arm.com>
Message-ID: <fe5c82d1-8b7d-6701-4e19-9019f23d9c7b@arm.com>



On 01/12/2023 06:20, Anshuman Khandual wrote:
> Add support for the tmc devices in the platform driver, which can then be
> used on ACPI based platforms. This change would now allow runtime power
> management for ACPI based systems. The driver would try to enable the APB
> clock if available.
> 
[...]
> -module_amba_driver(tmc_driver);
> +static int tmc_platform_probe(struct platform_device *pdev)
> +{
> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	struct tmc_drvdata *drvdata;
> +	int ret = 0;
> +
> +	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (!drvdata)
> +		return -ENOMEM;
> +
> +	drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
> +	if (IS_ERR(drvdata->pclk))
> +		return -ENODEV;
> +
> +	dev_set_drvdata(&pdev->dev, drvdata);
> +	pm_runtime_get_noresume(&pdev->dev);
> +	pm_runtime_set_active(&pdev->dev);
> +	pm_runtime_enable(&pdev->dev);
> +
> +	ret = __tmc_probe(&pdev->dev, res, NULL);
> +	if (ret) {
> +		pm_runtime_put_noidle(&pdev->dev);
> +		pm_runtime_disable(&pdev->dev);
> +	}

I'm not sure if these pm_runtime()s are right because there is already a
put inside of __tmc_probe() if it fails. If you unload and then reload
all the coresight modules with these patches you get these errors which
are new:

  coresight-tpiu-platform ARMHC979:00: Unbalanced pm_runtime_enable!
  CSCFG registered etm0
  coresight etm0: CPU0: etm v4.2 initialized
  CSCFG registered etm1
  coresight etm1: CPU1: etm v4.2 initialized
  CSCFG registered etm2
  coresight etm2: CPU2: etm v4.2 initialized
  CSCFG registered etm3
  coresight etm3: CPU3: etm v4.2 initialized
  coresight-tmc-platform ARMHC97C:00: Unbalanced pm_runtime_enable!
  coresight-tmc-platform ARMHC97C:01: Unbalanced pm_runtime_enable!
  coresight-tmc-platform ARMHC97C:02: Unbalanced pm_runtime_enable!
  coresight-tmc-platform ARMHC97C:03: Unbalanced pm_runtime_enable!

It might be worth testing all of these pm_runtime()s, including the
error case ones, because loading and unloading the modules doesn't even
include the error scenarios, so there are probably more bad ones in
there too.


From ryan.roberts at arm.com  Mon Dec  4 02:54:25 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:25 +0000
Subject: [PATCH v3 00/15] Transparent Contiguous PTEs for User Mappings
Message-ID: <20231204105440.61448-1-ryan.roberts@arm.com>

Hi All,

This is v3 of a series to opportunistically and transparently use contpte
mappings (set the contiguous bit in ptes) for user memory when those mappings
meet the requirements. It is part of a wider effort to improve performance by
allocating and mapping variable-sized blocks of memory (folios). One aim is for
the 4K kernel to approach the performance of the 16K kernel, but without
breaking compatibility and without the associated increase in memory. Another
aim is to benefit the 16K and 64K kernels by enabling 2M THP, since this is the
contpte size for those kernels. We have good performance data that demonstrates
both aims are being met (see below).

Of course this is only one half of the change. We require the mapped physical
memory to be the correct size and alignment for this to actually be useful (i.e.
64K for 4K pages, or 2M for 16K/64K pages). Fortunately folios are solving this
problem for us. Filesystems that support it (XFS, AFS, EROFS, tmpfs, ...) will
allocate large folios up to the PMD size today, and more filesystems are coming.
And the other half of my work, to enable "multi-size THP" (large folios) for
anonymous memory, makes contpte sized folios prevalent for anonymous memory too
[3].

Optimistically, I would really like to get this series merged for v6.8; there is
a chance that the multi-size THP series will also get merged for that version
(although at this point pretty small). But even if it doesn't, this series still
benefits file-backed memory from the file systems that support large folios so
shouldn't be held up for it. Additionally I've got data that shows this series
adds no regression when the system has no appropriate large folios.

All dependecies listed against v1 are now resolved; This series applies cleanly
against v6.7-rc1.

Note that the first two patchs are for core-mm and provides the refactoring to
make some crucial optimizations possible - which are then implemented in patches
14 and 15. The remaining patches are arm64-specific.

Testing
=======

I've tested this series together with multi-size THP [3] on both Ampere Altra
(bare metal) and Apple M2 (VM):
  - mm selftests (inc new tests written for multi-size THP); no regressions
  - Speedometer Java script benchmark in Chromium web browser; no issues
  - Kernel compilation; no issues
  - Various tests under high memory pressure with swap enabled; no issues


Performance
===========

John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
some workloads at [4], when using 64K base page kernel.

You can also see the original performance results I posted against v1 [1] which
are still valid.

I've additionally run the kernel compilation and speedometer benchmarks on a
system with multi-size THP disabled and large folio support for file-backed
memory intentionally disabled; I see no change in performance in this case (i.e.
no regression when this change is "present but not useful").


Changes since v2 [2]
====================

  - Removed contpte_ptep_get_and_clear_full() optimisation for exit() (v2#14),
    and replaced with a batch-clearing approach using a new arch helper,
    clear_ptes() (v3#2 and v3#15) (Alistair and Barry)
  - (v2#1 / v3#1)
      - Fixed folio refcounting so that refcount >= mapcount always (DavidH)
      - Reworked batch demarcation to avoid pte_pgprot() (DavidH)
      - Reverted return semantic of copy_present_page() and instead fix it up in
        copy_present_ptes() (Alistair)
      - Removed page_cont_mapped_vaddr() and replaced with simpler logic
        (Alistair)
      - Made batch accounting clearer in copy_pte_range() (Alistair)
  - (v2#12 / v3#13)
      - Renamed contpte_fold() -> contpte_convert() and hoisted setting/
        clearing CONT_PTE bit to higher level (Alistair)


Changes since v1 [1]
====================

  - Export contpte_* symbols so that modules can continue to call inline
    functions (e.g. ptep_get) which may now call the contpte_* functions (thanks
    to JohnH)
  - Use pte_valid() instead of pte_present() where sensible (thanks to Catalin)
  - Factor out (pte_valid() && pte_cont()) into new pte_valid_cont() helper
    (thanks to Catalin)
  - Fixed bug in contpte_ptep_set_access_flags() where TLBIs were missed (thanks
    to Catalin)
  - Added ARM64_CONTPTE expert Kconfig (enabled by default) (thanks to Anshuman)
  - Simplified contpte_ptep_get_and_clear_full()
  - Improved various code comments


[1] https://lore.kernel.org/linux-arm-kernel/20230622144210.2623299-1-ryan.roberts at arm.com/
[2] https://lore.kernel.org/linux-arm-kernel/20231115163018.1303287-1-ryan.roberts at arm.com/
[3] https://lore.kernel.org/linux-arm-kernel/20231204102027.57185-1-ryan.roberts at arm.com/
[4] https://lore.kernel.org/linux-mm/c507308d-bdd4-5f9e-d4ff-e96e4520be85 at nvidia.com/


Thanks,
Ryan

Ryan Roberts (15):
  mm: Batch-copy PTE ranges during fork()
  mm: Batch-clear PTE ranges during zap_pte_range()
  arm64/mm: set_pte(): New layer to manage contig bit
  arm64/mm: set_ptes()/set_pte_at(): New layer to manage contig bit
  arm64/mm: pte_clear(): New layer to manage contig bit
  arm64/mm: ptep_get_and_clear(): New layer to manage contig bit
  arm64/mm: ptep_test_and_clear_young(): New layer to manage contig bit
  arm64/mm: ptep_clear_flush_young(): New layer to manage contig bit
  arm64/mm: ptep_set_wrprotect(): New layer to manage contig bit
  arm64/mm: ptep_set_access_flags(): New layer to manage contig bit
  arm64/mm: ptep_get(): New layer to manage contig bit
  arm64/mm: Split __flush_tlb_range() to elide trailing DSB
  arm64/mm: Wire up PTE_CONT for user mappings
  arm64/mm: Implement ptep_set_wrprotects() to optimize fork()
  arm64/mm: Implement clear_ptes() to optimize exit()

 arch/arm64/Kconfig                |  10 +-
 arch/arm64/include/asm/pgtable.h  | 343 ++++++++++++++++++++---
 arch/arm64/include/asm/tlbflush.h |  13 +-
 arch/arm64/kernel/efi.c           |   4 +-
 arch/arm64/kernel/mte.c           |   2 +-
 arch/arm64/kvm/guest.c            |   2 +-
 arch/arm64/mm/Makefile            |   1 +
 arch/arm64/mm/contpte.c           | 436 ++++++++++++++++++++++++++++++
 arch/arm64/mm/fault.c             |  12 +-
 arch/arm64/mm/fixmap.c            |   4 +-
 arch/arm64/mm/hugetlbpage.c       |  40 +--
 arch/arm64/mm/kasan_init.c        |   6 +-
 arch/arm64/mm/mmu.c               |  16 +-
 arch/arm64/mm/pageattr.c          |   6 +-
 arch/arm64/mm/trans_pgd.c         |   6 +-
 include/asm-generic/tlb.h         |   9 +
 include/linux/pgtable.h           |  39 +++
 mm/memory.c                       | 258 +++++++++++++-----
 mm/mmu_gather.c                   |  14 +
 19 files changed, 1067 insertions(+), 154 deletions(-)
 create mode 100644 arch/arm64/mm/contpte.c

--
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:26 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:26 +0000
Subject: [PATCH v3 01/15] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-2-ryan.roberts@arm.com>

Convert copy_pte_range() to copy a set of ptes in a batch. A given batch
maps a physically contiguous block of memory, all belonging to the same
folio. This will likely improve performance by a tiny amount due to
batching the folio reference count management and calling set_ptes()
rather than making individual calls to set_pte_at().

However, the primary motivation for this change is to reduce the number
of tlb maintenance operations that the arm64 backend has to perform
during fork, as it is about to add transparent support for the
"contiguous bit" in its ptes. By write-protecting the parent using the
new ptep_set_wrprotects() (note the 's' at the end) function, the
backend can avoid having to unfold contig ranges of PTEs, which is
expensive, when all ptes in the range are being write-protected.
Similarly, by using set_ptes() rather than set_pte_at() to set up ptes
in the child, the backend does not need to fold a contiguous range once
they are all populated - they can be initially populated as a contiguous
range in the first place.

This change addresses the core-mm refactoring only, and introduces
ptep_set_wrprotects() with a default implementation that calls
ptep_set_wrprotect() for each pte in the range. A separate change will
implement ptep_set_wrprotects() in the arm64 backend to realize the
performance improvement as part of the work to enable contpte mappings.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 include/linux/pgtable.h |  13 +++
 mm/memory.c             | 195 ++++++++++++++++++++++++++++++----------
 2 files changed, 162 insertions(+), 46 deletions(-)

diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index af7639c3b0a3..1c50f8a0fdde 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -622,6 +622,19 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres
 }
 #endif
 
+#ifndef ptep_set_wrprotects
+struct mm_struct;
+static inline void ptep_set_wrprotects(struct mm_struct *mm,
+				unsigned long address, pte_t *ptep,
+				unsigned int nr)
+{
+	unsigned int i;
+
+	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
+		ptep_set_wrprotect(mm, address, ptep);
+}
+#endif
+
 /*
  * On some architectures hardware does not set page access bit when accessing
  * memory page, it is responsibility of software setting this bit. It brings
diff --git a/mm/memory.c b/mm/memory.c
index 1f18ed4a5497..8a87a488950c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -924,68 +924,162 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
 	return 0;
 }
 
+static int folio_nr_pages_cont_mapped(struct folio *folio,
+				      struct page *page, pte_t *pte,
+				      unsigned long addr, unsigned long end,
+				      pte_t ptent, bool enforce_uffd_wp,
+				      int *dirty_nr, int *writable_nr)
+{
+	int floops;
+	int i;
+	unsigned long pfn;
+	bool prot_none;
+	bool uffd_wp;
+
+	if (!folio_test_large(folio))
+		return 1;
+
+	/*
+	 * Loop either to `end` or to end of folio if its contiguously mapped,
+	 * whichever is smaller.
+	 */
+	floops = (end - addr) >> PAGE_SHIFT;
+	floops = min_t(int, floops,
+		       folio_pfn(folio_next(folio)) - page_to_pfn(page));
+
+	pfn = page_to_pfn(page);
+	prot_none = pte_protnone(ptent);
+	uffd_wp = pte_uffd_wp(ptent);
+
+	*dirty_nr = !!pte_dirty(ptent);
+	*writable_nr = !!pte_write(ptent);
+
+	pfn++;
+	pte++;
+
+	for (i = 1; i < floops; i++) {
+		ptent = ptep_get(pte);
+
+		if (!pte_present(ptent) || pte_pfn(ptent) != pfn ||
+		    prot_none != pte_protnone(ptent) ||
+		    (enforce_uffd_wp && uffd_wp != pte_uffd_wp(ptent)))
+			break;
+
+		if (pte_dirty(ptent))
+			(*dirty_nr)++;
+		if (pte_write(ptent))
+			(*writable_nr)++;
+
+		pfn++;
+		pte++;
+	}
+
+	return i;
+}
+
 /*
- * Copy one pte.  Returns 0 if succeeded, or -EAGAIN if one preallocated page
- * is required to copy this pte.
+ * Copy set of contiguous ptes.  Returns number of ptes copied if succeeded
+ * (always gte 1), or -EAGAIN if one preallocated page is required to copy the
+ * first pte.
  */
 static inline int
-copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
-		 pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
-		 struct folio **prealloc)
+copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
+		  pte_t *dst_pte, pte_t *src_pte,
+		  unsigned long addr, unsigned long end,
+		  int *rss, struct folio **prealloc)
 {
 	struct mm_struct *src_mm = src_vma->vm_mm;
 	unsigned long vm_flags = src_vma->vm_flags;
 	pte_t pte = ptep_get(src_pte);
 	struct page *page;
 	struct folio *folio;
+	int nr = 1;
+	bool anon = false;
+	bool enforce_uffd_wp = userfaultfd_wp(dst_vma);
+	int nr_dirty = !!pte_dirty(pte);
+	int nr_writable = !!pte_write(pte);
+	int i, ret;
 
 	page = vm_normal_page(src_vma, addr, pte);
-	if (page)
+	if (page) {
 		folio = page_folio(page);
-	if (page && folio_test_anon(folio)) {
-		/*
-		 * If this page may have been pinned by the parent process,
-		 * copy the page immediately for the child so that we'll always
-		 * guarantee the pinned page won't be randomly replaced in the
-		 * future.
-		 */
-		folio_get(folio);
-		if (unlikely(page_try_dup_anon_rmap(page, false, src_vma))) {
-			/* Page may be pinned, we have to copy. */
-			folio_put(folio);
-			return copy_present_page(dst_vma, src_vma, dst_pte, src_pte,
-						 addr, rss, prealloc, page);
+		anon = folio_test_anon(folio);
+		nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
+						pte, enforce_uffd_wp, &nr_dirty,
+						&nr_writable);
+		folio_ref_add(folio, nr);
+
+		for (i = 0; i < nr; i++, page++) {
+			if (anon) {
+				/*
+				 * If this page may have been pinned by the
+				 * parent process, copy the page immediately for
+				 * the child so that we'll always guarantee the
+				 * pinned page won't be randomly replaced in the
+				 * future.
+				 */
+				if (unlikely(page_try_dup_anon_rmap(
+						page, false, src_vma))) {
+					if (i != 0)
+						break;
+					/* Page may be pinned, we have to copy. */
+					folio_ref_sub(folio, nr);
+					ret = copy_present_page(
+						dst_vma, src_vma, dst_pte,
+						src_pte, addr, rss, prealloc,
+						page);
+					return ret == 0 ? 1 : ret;
+				}
+				rss[MM_ANONPAGES]++;
+				VM_BUG_ON(PageAnonExclusive(page));
+			} else {
+				page_dup_file_rmap(page, false);
+				rss[mm_counter_file(page)]++;
+			}
 		}
-		rss[MM_ANONPAGES]++;
-	} else if (page) {
-		folio_get(folio);
-		page_dup_file_rmap(page, false);
-		rss[mm_counter_file(page)]++;
-	}
 
-	/*
-	 * If it's a COW mapping, write protect it both
-	 * in the parent and the child
-	 */
-	if (is_cow_mapping(vm_flags) && pte_write(pte)) {
-		ptep_set_wrprotect(src_mm, addr, src_pte);
-		pte = pte_wrprotect(pte);
+		if (i < nr) {
+			folio_ref_sub(folio, nr - i);
+			nr = i;
+		}
 	}
-	VM_BUG_ON(page && folio_test_anon(folio) && PageAnonExclusive(page));
 
 	/*
-	 * If it's a shared mapping, mark it clean in
-	 * the child
+	 * If it's a shared mapping, mark it clean and write protected in the
+	 * child, and rely on a write fault to fix up the permissions. This
+	 * allows determining batch size without having to consider RO/RW
+	 * permissions. As an optimization, skip wrprotect if all ptes in the
+	 * batch have the same permissions.
+	 *
+	 * If its a private (CoW) mapping, mark it dirty in the child if _any_
+	 * of the parent mappings in the block were marked dirty. The contiguous
+	 * block of mappings are all backed by the same folio, so if any are
+	 * dirty then the whole folio is dirty. This allows determining batch
+	 * size without having to consider the dirty bit. Further, write protect
+	 * it both in the parent and the child so that a future write will cause
+	 * a CoW. As as an optimization, skip the wrprotect if all the ptes in
+	 * the batch are already readonly.
 	 */
-	if (vm_flags & VM_SHARED)
+	if (vm_flags & VM_SHARED) {
 		pte = pte_mkclean(pte);
-	pte = pte_mkold(pte);
+		if (nr_writable > 0 && nr_writable < nr)
+			pte = pte_wrprotect(pte);
+	} else {
+		if (nr_dirty)
+			pte = pte_mkdirty(pte);
+		if (nr_writable) {
+			ptep_set_wrprotects(src_mm, addr, src_pte, nr);
+			pte = pte_wrprotect(pte);
+		}
+	}
 
-	if (!userfaultfd_wp(dst_vma))
+	pte = pte_mkold(pte);
+	pte = pte_clear_soft_dirty(pte);
+	if (!enforce_uffd_wp)
 		pte = pte_clear_uffd_wp(pte);
 
-	set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte);
-	return 0;
+	set_ptes(dst_vma->vm_mm, addr, dst_pte, pte, nr);
+	return nr;
 }
 
 static inline struct folio *page_copy_prealloc(struct mm_struct *src_mm,
@@ -1021,6 +1115,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	int rss[NR_MM_COUNTERS];
 	swp_entry_t entry = (swp_entry_t){0};
 	struct folio *prealloc = NULL;
+	int nr_ptes;
 
 again:
 	progress = 0;
@@ -1051,6 +1146,8 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	arch_enter_lazy_mmu_mode();
 
 	do {
+		nr_ptes = 1;
+
 		/*
 		 * We are holding two locks at this point - either of them
 		 * could generate latencies in another task on another CPU.
@@ -1086,16 +1183,21 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 			 * the now present pte.
 			 */
 			WARN_ON_ONCE(ret != -ENOENT);
+			ret = 0;
 		}
-		/* copy_present_pte() will clear `*prealloc' if consumed */
-		ret = copy_present_pte(dst_vma, src_vma, dst_pte, src_pte,
-				       addr, rss, &prealloc);
+		/* copy_present_ptes() will clear `*prealloc' if consumed */
+		nr_ptes = copy_present_ptes(dst_vma, src_vma, dst_pte, src_pte,
+					    addr, end, rss, &prealloc);
+
 		/*
 		 * If we need a pre-allocated page for this pte, drop the
 		 * locks, allocate, and try again.
 		 */
-		if (unlikely(ret == -EAGAIN))
+		if (unlikely(nr_ptes == -EAGAIN)) {
+			ret = -EAGAIN;
 			break;
+		}
+
 		if (unlikely(prealloc)) {
 			/*
 			 * pre-alloc page cannot be reused by next time so as
@@ -1106,8 +1208,9 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 			folio_put(prealloc);
 			prealloc = NULL;
 		}
-		progress += 8;
-	} while (dst_pte++, src_pte++, addr += PAGE_SIZE, addr != end);
+		progress += 8 * nr_ptes;
+	} while (dst_pte += nr_ptes, src_pte += nr_ptes,
+		 addr += PAGE_SIZE * nr_ptes, addr != end);
 
 	arch_leave_lazy_mmu_mode();
 	pte_unmap_unlock(orig_src_pte, src_ptl);
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:28 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:28 +0000
Subject: [PATCH v3 03/15] arm64/mm: set_pte(): New layer to manage contig bit
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-4-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 12 ++++++++----
 arch/arm64/kernel/efi.c          |  2 +-
 arch/arm64/mm/fixmap.c           |  2 +-
 arch/arm64/mm/kasan_init.c       |  4 ++--
 arch/arm64/mm/mmu.c              |  2 +-
 arch/arm64/mm/pageattr.c         |  2 +-
 arch/arm64/mm/trans_pgd.c        |  4 ++--
 7 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b19a8aee684c..650d4f4bb6dc 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -93,7 +93,8 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
 	__pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
 
 #define pte_none(pte)		(!pte_val(pte))
-#define pte_clear(mm,addr,ptep)	set_pte(ptep, __pte(0))
+#define pte_clear(mm, addr, ptep) \
+				__set_pte(ptep, __pte(0))
 #define pte_page(pte)		(pfn_to_page(pte_pfn(pte)))
 
 /*
@@ -261,7 +262,7 @@ static inline pte_t pte_mkdevmap(pte_t pte)
 	return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
 }
 
-static inline void set_pte(pte_t *ptep, pte_t pte)
+static inline void __set_pte(pte_t *ptep, pte_t pte)
 {
 	WRITE_ONCE(*ptep, pte);
 
@@ -350,7 +351,7 @@ static inline void set_ptes(struct mm_struct *mm,
 
 	for (;;) {
 		__check_safe_pte_update(mm, ptep, pte);
-		set_pte(ptep, pte);
+		__set_pte(ptep, pte);
 		if (--nr == 0)
 			break;
 		ptep++;
@@ -534,7 +535,7 @@ static inline void __set_pte_at(struct mm_struct *mm,
 {
 	__sync_cache_and_tags(pte, nr);
 	__check_safe_pte_update(mm, ptep, pte);
-	set_pte(ptep, pte);
+	__set_pte(ptep, pte);
 }
 
 static inline void set_pmd_at(struct mm_struct *mm, unsigned long addr,
@@ -1118,6 +1119,9 @@ extern pte_t ptep_modify_prot_start(struct vm_area_struct *vma,
 extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 				    unsigned long addr, pte_t *ptep,
 				    pte_t old_pte, pte_t new_pte);
+
+#define set_pte					__set_pte
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_H */
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 0228001347be..44288a12fc6c 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -111,7 +111,7 @@ static int __init set_permissions(pte_t *ptep, unsigned long addr, void *data)
 		pte = set_pte_bit(pte, __pgprot(PTE_PXN));
 	else if (system_supports_bti_kernel() && spd->has_bti)
 		pte = set_pte_bit(pte, __pgprot(PTE_GP));
-	set_pte(ptep, pte);
+	__set_pte(ptep, pte);
 	return 0;
 }
 
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index c0a3301203bd..51cd4501816d 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -121,7 +121,7 @@ void __set_fixmap(enum fixed_addresses idx,
 	ptep = fixmap_pte(addr);
 
 	if (pgprot_val(flags)) {
-		set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, flags));
+		__set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, flags));
 	} else {
 		pte_clear(&init_mm, addr, ptep);
 		flush_tlb_kernel_range(addr, addr+PAGE_SIZE);
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 555285ebd5af..5eade712e9e5 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -112,7 +112,7 @@ static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
 		if (!early)
 			memset(__va(page_phys), KASAN_SHADOW_INIT, PAGE_SIZE);
 		next = addr + PAGE_SIZE;
-		set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
+		__set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
 	} while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep)));
 }
 
@@ -266,7 +266,7 @@ static void __init kasan_init_shadow(void)
 	 * so we should make sure that it maps the zero page read-only.
 	 */
 	for (i = 0; i < PTRS_PER_PTE; i++)
-		set_pte(&kasan_early_shadow_pte[i],
+		__set_pte(&kasan_early_shadow_pte[i],
 			pfn_pte(sym_to_pfn(kasan_early_shadow_page),
 				PAGE_KERNEL_RO));
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 15f6347d23b6..e884279b268e 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -178,7 +178,7 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 	do {
 		pte_t old_pte = READ_ONCE(*ptep);
 
-		set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
+		__set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
 
 		/*
 		 * After the PTE entry has been populated once, we
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 8e2017ba5f1b..057097acf9e0 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -41,7 +41,7 @@ static int change_page_range(pte_t *ptep, unsigned long addr, void *data)
 	pte = clear_pte_bit(pte, cdata->clear_mask);
 	pte = set_pte_bit(pte, cdata->set_mask);
 
-	set_pte(ptep, pte);
+	__set_pte(ptep, pte);
 	return 0;
 }
 
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 7b14df3c6477..230b607cf881 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -41,7 +41,7 @@ static void _copy_pte(pte_t *dst_ptep, pte_t *src_ptep, unsigned long addr)
 		 * read only (code, rodata). Clear the RDONLY bit from
 		 * the temporary mappings we use during restore.
 		 */
-		set_pte(dst_ptep, pte_mkwrite_novma(pte));
+		__set_pte(dst_ptep, pte_mkwrite_novma(pte));
 	} else if ((debug_pagealloc_enabled() ||
 		   is_kfence_address((void *)addr)) && !pte_none(pte)) {
 		/*
@@ -55,7 +55,7 @@ static void _copy_pte(pte_t *dst_ptep, pte_t *src_ptep, unsigned long addr)
 		 */
 		BUG_ON(!pfn_valid(pte_pfn(pte)));
 
-		set_pte(dst_ptep, pte_mkpresent(pte_mkwrite_novma(pte)));
+		__set_pte(dst_ptep, pte_mkpresent(pte_mkwrite_novma(pte)));
 	}
 }
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:27 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:27 +0000
Subject: [PATCH v3 02/15] mm: Batch-clear PTE ranges during zap_pte_range()
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-3-ryan.roberts@arm.com>

Convert zap_pte_range() to clear a set of ptes in a batch. A given batch
maps a physically contiguous block of memory, all belonging to the same
folio. This will likely improve performance by a tiny amount due to
removing duplicate calls to mark the folio dirty and accessed. And also
provides us with a future opportunity to batch the rmap removal.

However, the primary motivation for this change is to reduce the number
of tlb maintenance operations that the arm64 backend has to perform
during exit and other syscalls that cause zap_pte_range() (e.g. munmap,
madvise(DONTNEED), etc.), as it is about to add transparent support for
the "contiguous bit" in its ptes. By clearing ptes using the new
clear_ptes() API, the backend doesn't have to perform an expensive
unfold operation when a PTE being cleared is part of a contpte block.
Instead it can just clear the whole block immediately.

This change addresses the core-mm refactoring only, and introduces
clear_ptes() with a default implementation that calls
ptep_get_and_clear_full() for each pte in the range. Note that this API
returns the pte at the beginning of the batch, but with the dirty and
young bits set if ANY of the ptes in the cleared batch had those bits
set; this information is applied to the folio by the core-mm. Given the
batch is garranteed to cover only a single folio, collapsing this state
does not lose any useful information.

A separate change will implement clear_ptes() in the arm64 backend to
realize the performance improvement as part of the work to enable
contpte mappings.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 include/asm-generic/tlb.h |  9 ++++++
 include/linux/pgtable.h   | 26 ++++++++++++++++
 mm/memory.c               | 63 ++++++++++++++++++++++++++-------------
 mm/mmu_gather.c           | 14 +++++++++
 4 files changed, 92 insertions(+), 20 deletions(-)

diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 129a3a759976..b84ba3aa1f6e 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -75,6 +75,9 @@
  *    boolean indicating if the queue is (now) full and a call to
  *    tlb_flush_mmu() is required.
  *
+ *    tlb_get_guaranteed_space() returns the minimum garanteed number of pages
+ *    that can be queued without overflow.
+ *
  *    tlb_remove_page() and tlb_remove_page_size() imply the call to
  *    tlb_flush_mmu() when required and has no return value.
  *
@@ -263,6 +266,7 @@ struct mmu_gather_batch {
 extern bool __tlb_remove_page_size(struct mmu_gather *tlb,
 				   struct encoded_page *page,
 				   int page_size);
+extern unsigned int tlb_get_guaranteed_space(struct mmu_gather *tlb);
 
 #ifdef CONFIG_SMP
 /*
@@ -273,6 +277,11 @@ extern bool __tlb_remove_page_size(struct mmu_gather *tlb,
 extern void tlb_flush_rmaps(struct mmu_gather *tlb, struct vm_area_struct *vma);
 #endif
 
+#else
+static inline unsigned int tlb_get_guaranteed_space(struct mmu_gather *tlb)
+{
+	return 1;
+}
 #endif
 
 /*
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 1c50f8a0fdde..e998080eb7ae 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -635,6 +635,32 @@ static inline void ptep_set_wrprotects(struct mm_struct *mm,
 }
 #endif
 
+#ifndef clear_ptes
+struct mm_struct;
+static inline pte_t clear_ptes(struct mm_struct *mm,
+				unsigned long address, pte_t *ptep,
+				int full, unsigned int nr)
+{
+	unsigned int i;
+	pte_t pte;
+	pte_t orig_pte = ptep_get_and_clear_full(mm, address, ptep, full);
+
+	for (i = 1; i < nr; i++) {
+		address += PAGE_SIZE;
+		ptep++;
+		pte = ptep_get_and_clear_full(mm, address, ptep, full);
+
+		if (pte_dirty(pte))
+			orig_pte = pte_mkdirty(orig_pte);
+
+		if (pte_young(pte))
+			orig_pte = pte_mkyoung(orig_pte);
+	}
+
+	return orig_pte;
+}
+#endif
+
 /*
  * On some architectures hardware does not set page access bit when accessing
  * memory page, it is responsibility of software setting this bit. It brings
diff --git a/mm/memory.c b/mm/memory.c
index 8a87a488950c..60f030700a3f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1515,6 +1515,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 	pte_t *start_pte;
 	pte_t *pte;
 	swp_entry_t entry;
+	int nr;
 
 	tlb_change_page_size(tlb, PAGE_SIZE);
 	init_rss_vec(rss);
@@ -1527,6 +1528,9 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 	do {
 		pte_t ptent = ptep_get(pte);
 		struct page *page;
+		int i;
+
+		nr = 1;
 
 		if (pte_none(ptent))
 			continue;
@@ -1535,45 +1539,64 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 			break;
 
 		if (pte_present(ptent)) {
-			unsigned int delay_rmap;
+			unsigned int delay_rmap = 0;
+			bool tlb_full = false;
+			struct folio *folio = NULL;
 
 			page = vm_normal_page(vma, addr, ptent);
 			if (unlikely(!should_zap_page(details, page)))
 				continue;
-			ptent = ptep_get_and_clear_full(mm, addr, pte,
-							tlb->fullmm);
+
+			if (likely(page)) {
+				folio = page_folio(page);
+				nr = folio_nr_pages_cont_mapped(folio, page,
+							pte, addr, end,
+							ptent, true, &i, &i);
+				nr = min_t(int, nr, tlb_get_guaranteed_space(tlb));
+			}
+
+			ptent = clear_ptes(mm, addr, pte, tlb->fullmm, nr);
 			arch_check_zapped_pte(vma, ptent);
-			tlb_remove_tlb_entry(tlb, pte, addr);
-			zap_install_uffd_wp_if_needed(vma, addr, pte, details,
-						      ptent);
+
+			for (i = 0; i < nr; i++) {
+				unsigned long subaddr = addr + PAGE_SIZE * i;
+
+				tlb_remove_tlb_entry(tlb, &pte[i], subaddr);
+				zap_install_uffd_wp_if_needed(vma, subaddr,
+						&pte[i], details, ptent);
+			}
 			if (unlikely(!page)) {
 				ksm_might_unmap_zero_page(mm, ptent);
 				continue;
 			}
 
-			delay_rmap = 0;
-			if (!PageAnon(page)) {
+			if (!folio_test_anon(folio)) {
 				if (pte_dirty(ptent)) {
-					set_page_dirty(page);
+					folio_mark_dirty(folio);
 					if (tlb_delay_rmap(tlb)) {
 						delay_rmap = 1;
 						force_flush = 1;
 					}
 				}
 				if (pte_young(ptent) && likely(vma_has_recency(vma)))
-					mark_page_accessed(page);
+					folio_mark_accessed(folio);
 			}
-			rss[mm_counter(page)]--;
-			if (!delay_rmap) {
-				page_remove_rmap(page, vma, false);
-				if (unlikely(page_mapcount(page) < 0))
-					print_bad_pte(vma, addr, ptent, page);
+			for (i = 0; i < nr; i++, page++) {
+				rss[mm_counter(page)]--;
+				if (!delay_rmap) {
+					page_remove_rmap(page, vma, false);
+					if (unlikely(page_mapcount(page) < 0))
+						print_bad_pte(vma, addr, ptent, page);
+				}
+				if (unlikely(__tlb_remove_page(tlb, page, delay_rmap))) {
+					tlb_full = true;
+					force_flush = 1;
+					addr += PAGE_SIZE * (i + 1);
+					break;
+				}
 			}
-			if (unlikely(__tlb_remove_page(tlb, page, delay_rmap))) {
-				force_flush = 1;
-				addr += PAGE_SIZE;
+			if (unlikely(tlb_full))
 				break;
-			}
 			continue;
 		}
 
@@ -1624,7 +1647,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 		}
 		pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
 		zap_install_uffd_wp_if_needed(vma, addr, pte, details, ptent);
-	} while (pte++, addr += PAGE_SIZE, addr != end);
+	} while (pte += nr, addr += PAGE_SIZE * nr, addr != end);
 
 	add_mm_rss_vec(mm, rss);
 	arch_leave_lazy_mmu_mode();
diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
index 4f559f4ddd21..57b4d5f0dfa4 100644
--- a/mm/mmu_gather.c
+++ b/mm/mmu_gather.c
@@ -47,6 +47,20 @@ static bool tlb_next_batch(struct mmu_gather *tlb)
 	return true;
 }
 
+unsigned int tlb_get_guaranteed_space(struct mmu_gather *tlb)
+{
+	struct mmu_gather_batch *batch = tlb->active;
+	unsigned int nr_next = 0;
+
+	/* Allocate next batch so we can guarrantee at least one batch. */
+	if (tlb_next_batch(tlb)) {
+		tlb->active = batch;
+		nr_next = batch->next->max;
+	}
+
+	return batch->max - batch->nr + nr_next;
+}
+
 #ifdef CONFIG_SMP
 static void tlb_flush_rmap_batch(struct mmu_gather_batch *batch, struct vm_area_struct *vma)
 {
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:29 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:29 +0000
Subject: [PATCH v3 04/15] arm64/mm: set_ptes()/set_pte_at(): New layer to manage contig bit
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-5-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

set_pte_at() is a core macro that forwards to set_ptes() (with nr=1).
Instead of creating a __set_pte_at() internal macro, convert all arch
users to use set_ptes()/__set_ptes() directly, as appropriate. Callers
in hugetlb may benefit from calling __set_ptes() once for their whole
range rather than managing their own loop. This is left for future
improvement.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 10 +++++-----
 arch/arm64/kernel/mte.c          |  2 +-
 arch/arm64/kvm/guest.c           |  2 +-
 arch/arm64/mm/fault.c            |  2 +-
 arch/arm64/mm/hugetlbpage.c      | 10 +++++-----
 5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 650d4f4bb6dc..323ec91add60 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -342,9 +342,9 @@ static inline void __sync_cache_and_tags(pte_t pte, unsigned int nr_pages)
 		mte_sync_tags(pte, nr_pages);
 }
 
-static inline void set_ptes(struct mm_struct *mm,
-			    unsigned long __always_unused addr,
-			    pte_t *ptep, pte_t pte, unsigned int nr)
+static inline void __set_ptes(struct mm_struct *mm,
+			      unsigned long __always_unused addr,
+			      pte_t *ptep, pte_t pte, unsigned int nr)
 {
 	page_table_check_ptes_set(mm, ptep, pte, nr);
 	__sync_cache_and_tags(pte, nr);
@@ -358,7 +358,6 @@ static inline void set_ptes(struct mm_struct *mm,
 		pte_val(pte) += PAGE_SIZE;
 	}
 }
-#define set_ptes set_ptes
 
 /*
  * Huge pte definitions.
@@ -1067,7 +1066,7 @@ static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
 #endif /* CONFIG_ARM64_MTE */
 
 /*
- * On AArch64, the cache coherency is handled via the set_pte_at() function.
+ * On AArch64, the cache coherency is handled via the __set_ptes() function.
  */
 static inline void update_mmu_cache_range(struct vm_fault *vmf,
 		struct vm_area_struct *vma, unsigned long addr, pte_t *ptep,
@@ -1121,6 +1120,7 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 				    pte_t old_pte, pte_t new_pte);
 
 #define set_pte					__set_pte
+#define set_ptes				__set_ptes
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index a41ef3213e1e..dcdcccd40891 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -67,7 +67,7 @@ int memcmp_pages(struct page *page1, struct page *page2)
 	/*
 	 * If the page content is identical but at least one of the pages is
 	 * tagged, return non-zero to avoid KSM merging. If only one of the
-	 * pages is tagged, set_pte_at() may zero or change the tags of the
+	 * pages is tagged, __set_ptes() may zero or change the tags of the
 	 * other page via mte_sync_tags().
 	 */
 	if (page_mte_tagged(page1) || page_mte_tagged(page2))
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index aaf1d4939739..629145fd3161 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -1072,7 +1072,7 @@ int kvm_vm_ioctl_mte_copy_tags(struct kvm *kvm,
 		} else {
 			/*
 			 * Only locking to serialise with a concurrent
-			 * set_pte_at() in the VMM but still overriding the
+			 * __set_ptes() in the VMM but still overriding the
 			 * tags, hence ignoring the return value.
 			 */
 			try_page_mte_tagging(page);
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 460d799e1296..a287c1dea871 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -205,7 +205,7 @@ static void show_pte(unsigned long addr)
  *
  * It needs to cope with hardware update of the accessed/dirty state by other
  * agents in the system and can safely skip the __sync_icache_dcache() call as,
- * like set_pte_at(), the PTE is never changed from no-exec to exec here.
+ * like __set_ptes(), the PTE is never changed from no-exec to exec here.
  *
  * Returns whether or not the PTE actually changed.
  */
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index f5aae342632c..741cb53672fd 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -254,12 +254,12 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
 
 	if (!pte_present(pte)) {
 		for (i = 0; i < ncontig; i++, ptep++, addr += pgsize)
-			set_pte_at(mm, addr, ptep, pte);
+			__set_ptes(mm, addr, ptep, pte, 1);
 		return;
 	}
 
 	if (!pte_cont(pte)) {
-		set_pte_at(mm, addr, ptep, pte);
+		__set_ptes(mm, addr, ptep, pte, 1);
 		return;
 	}
 
@@ -270,7 +270,7 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
 	clear_flush(mm, addr, ptep, pgsize, ncontig);
 
 	for (i = 0; i < ncontig; i++, ptep++, addr += pgsize, pfn += dpfn)
-		set_pte_at(mm, addr, ptep, pfn_pte(pfn, hugeprot));
+		__set_ptes(mm, addr, ptep, pfn_pte(pfn, hugeprot), 1);
 }
 
 pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
@@ -478,7 +478,7 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
 
 	hugeprot = pte_pgprot(pte);
 	for (i = 0; i < ncontig; i++, ptep++, addr += pgsize, pfn += dpfn)
-		set_pte_at(mm, addr, ptep, pfn_pte(pfn, hugeprot));
+		__set_ptes(mm, addr, ptep, pfn_pte(pfn, hugeprot), 1);
 
 	return 1;
 }
@@ -507,7 +507,7 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
 	pfn = pte_pfn(pte);
 
 	for (i = 0; i < ncontig; i++, ptep++, addr += pgsize, pfn += dpfn)
-		set_pte_at(mm, addr, ptep, pfn_pte(pfn, hugeprot));
+		__set_ptes(mm, addr, ptep, pfn_pte(pfn, hugeprot), 1);
 }
 
 pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:33 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:33 +0000
Subject: [PATCH v3 08/15] arm64/mm: ptep_clear_flush_young(): New layer to manage contig bit
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-9-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 9b4a9909fd5b..fc1005222ee4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -138,7 +138,7 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
  * so that we don't erroneously return false for pages that have been
  * remapped as PROT_NONE but are yet to be flushed from the TLB.
  * Note that we can't make any assumptions based on the state of the access
- * flag, since ptep_clear_flush_young() elides a DSB when invalidating the
+ * flag, since __ptep_clear_flush_young() elides a DSB when invalidating the
  * TLB.
  */
 #define pte_accessible(mm, pte)	\
@@ -904,8 +904,7 @@ static inline int __ptep_test_and_clear_young(struct vm_area_struct *vma,
 	return pte_young(pte);
 }
 
-#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
-static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
+static inline int __ptep_clear_flush_young(struct vm_area_struct *vma,
 					 unsigned long address, pte_t *ptep)
 {
 	int young = __ptep_test_and_clear_young(vma, address, ptep);
@@ -1119,6 +1118,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define ptep_get_and_clear			__ptep_get_and_clear
 #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
 #define ptep_test_and_clear_young		__ptep_test_and_clear_young
+#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
+#define ptep_clear_flush_young			__ptep_clear_flush_young
 
 #endif /* !__ASSEMBLY__ */
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:34 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:34 +0000
Subject: [PATCH v3 09/15] arm64/mm: ptep_set_wrprotect(): New layer to manage contig bit
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-10-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 10 ++++++----
 arch/arm64/mm/hugetlbpage.c      |  2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index fc1005222ee4..423cc32b2777 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -958,11 +958,11 @@ static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
 /*
- * ptep_set_wrprotect - mark read-only while trasferring potential hardware
+ * __ptep_set_wrprotect - mark read-only while trasferring potential hardware
  * dirty status (PTE_DBM && !PTE_RDONLY) to the software PTE_DIRTY bit.
  */
-#define __HAVE_ARCH_PTEP_SET_WRPROTECT
-static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, pte_t *ptep)
+static inline void __ptep_set_wrprotect(struct mm_struct *mm,
+					unsigned long address, pte_t *ptep)
 {
 	pte_t old_pte, pte;
 
@@ -980,7 +980,7 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres
 static inline void pmdp_set_wrprotect(struct mm_struct *mm,
 				      unsigned long address, pmd_t *pmdp)
 {
-	ptep_set_wrprotect(mm, address, (pte_t *)pmdp);
+	__ptep_set_wrprotect(mm, address, (pte_t *)pmdp);
 }
 
 #define pmdp_establish pmdp_establish
@@ -1120,6 +1120,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define ptep_test_and_clear_young		__ptep_test_and_clear_young
 #define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
 #define ptep_clear_flush_young			__ptep_clear_flush_young
+#define __HAVE_ARCH_PTEP_SET_WRPROTECT
+#define ptep_set_wrprotect			__ptep_set_wrprotect
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index c2a753541d13..952462820d9d 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -493,7 +493,7 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
 	pte_t pte;
 
 	if (!pte_cont(READ_ONCE(*ptep))) {
-		ptep_set_wrprotect(mm, addr, ptep);
+		__ptep_set_wrprotect(mm, addr, ptep);
 		return;
 	}
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:35 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:35 +0000
Subject: [PATCH v3 10/15] arm64/mm: ptep_set_access_flags(): New layer to manage contig bit
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-11-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 10 ++++++----
 arch/arm64/mm/fault.c            |  6 +++---
 arch/arm64/mm/hugetlbpage.c      |  2 +-
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 423cc32b2777..85010c2d4dfa 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -312,7 +312,7 @@ static inline void __check_safe_pte_update(struct mm_struct *mm, pte_t *ptep,
 
 	/*
 	 * Check for potential race with hardware updates of the pte
-	 * (ptep_set_access_flags safely changes valid ptes without going
+	 * (__ptep_set_access_flags safely changes valid ptes without going
 	 * through an invalid entry).
 	 */
 	VM_WARN_ONCE(!pte_young(pte),
@@ -842,8 +842,7 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
 	return pte_pmd(pte_modify(pmd_pte(pmd), newprot));
 }
 
-#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
-extern int ptep_set_access_flags(struct vm_area_struct *vma,
+extern int __ptep_set_access_flags(struct vm_area_struct *vma,
 				 unsigned long address, pte_t *ptep,
 				 pte_t entry, int dirty);
 
@@ -853,7 +852,8 @@ static inline int pmdp_set_access_flags(struct vm_area_struct *vma,
 					unsigned long address, pmd_t *pmdp,
 					pmd_t entry, int dirty)
 {
-	return ptep_set_access_flags(vma, address, (pte_t *)pmdp, pmd_pte(entry), dirty);
+	return __ptep_set_access_flags(vma, address, (pte_t *)pmdp,
+							pmd_pte(entry), dirty);
 }
 
 static inline int pud_devmap(pud_t pud)
@@ -1122,6 +1122,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define ptep_clear_flush_young			__ptep_clear_flush_young
 #define __HAVE_ARCH_PTEP_SET_WRPROTECT
 #define ptep_set_wrprotect			__ptep_set_wrprotect
+#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
+#define ptep_set_access_flags			__ptep_set_access_flags
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a287c1dea871..7cebd9847aae 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -209,9 +209,9 @@ static void show_pte(unsigned long addr)
  *
  * Returns whether or not the PTE actually changed.
  */
-int ptep_set_access_flags(struct vm_area_struct *vma,
-			  unsigned long address, pte_t *ptep,
-			  pte_t entry, int dirty)
+int __ptep_set_access_flags(struct vm_area_struct *vma,
+			    unsigned long address, pte_t *ptep,
+			    pte_t entry, int dirty)
 {
 	pteval_t old_pteval, pteval;
 	pte_t pte = READ_ONCE(*ptep);
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 952462820d9d..627a9717e98c 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -459,7 +459,7 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
 	pte_t orig_pte;
 
 	if (!pte_cont(pte))
-		return ptep_set_access_flags(vma, addr, ptep, pte, dirty);
+		return __ptep_set_access_flags(vma, addr, ptep, pte, dirty);
 
 	ncontig = find_num_contig(mm, addr, ptep, &pgsize);
 	dpfn = pgsize >> PAGE_SHIFT;
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:36 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:36 +0000
Subject: [PATCH v3 11/15] arm64/mm: ptep_get(): New layer to manage contig bit
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-12-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

arm64 did not previously define an arch-specific ptep_get(), so override
the default version in the arch code, and also define the private
__ptep_get() version. Currently they both do the same thing that the
default version does (READ_ONCE()). Some arch users (hugetlb) were
already using ptep_get() so convert those to the private API. While
other callsites were doing direct READ_ONCE(), so convert those to use
the appropriate (public/private) API too.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 12 +++++++++---
 arch/arm64/kernel/efi.c          |  2 +-
 arch/arm64/mm/fault.c            |  4 ++--
 arch/arm64/mm/hugetlbpage.c      | 18 +++++++++---------
 arch/arm64/mm/kasan_init.c       |  2 +-
 arch/arm64/mm/mmu.c              | 12 ++++++------
 arch/arm64/mm/pageattr.c         |  4 ++--
 arch/arm64/mm/trans_pgd.c        |  2 +-
 8 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 85010c2d4dfa..6930c14f062f 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -276,6 +276,11 @@ static inline void __set_pte(pte_t *ptep, pte_t pte)
 	}
 }
 
+static inline pte_t __ptep_get(pte_t *ptep)
+{
+	return READ_ONCE(*ptep);
+}
+
 extern void __sync_icache_dcache(pte_t pteval);
 bool pgattr_change_is_safe(u64 old, u64 new);
 
@@ -303,7 +308,7 @@ static inline void __check_safe_pte_update(struct mm_struct *mm, pte_t *ptep,
 	if (!IS_ENABLED(CONFIG_DEBUG_VM))
 		return;
 
-	old_pte = READ_ONCE(*ptep);
+	old_pte = __ptep_get(ptep);
 
 	if (!pte_valid(old_pte) || !pte_valid(pte))
 		return;
@@ -893,7 +898,7 @@ static inline int __ptep_test_and_clear_young(struct vm_area_struct *vma,
 {
 	pte_t old_pte, pte;
 
-	pte = READ_ONCE(*ptep);
+	pte = __ptep_get(ptep);
 	do {
 		old_pte = pte;
 		pte = pte_mkold(pte);
@@ -966,7 +971,7 @@ static inline void __ptep_set_wrprotect(struct mm_struct *mm,
 {
 	pte_t old_pte, pte;
 
-	pte = READ_ONCE(*ptep);
+	pte = __ptep_get(ptep);
 	do {
 		old_pte = pte;
 		pte = pte_wrprotect(pte);
@@ -1111,6 +1116,7 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 				    unsigned long addr, pte_t *ptep,
 				    pte_t old_pte, pte_t new_pte);
 
+#define ptep_get				__ptep_get
 #define set_pte					__set_pte
 #define set_ptes				__set_ptes
 #define pte_clear				__pte_clear
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 44288a12fc6c..9afcc690fe73 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -103,7 +103,7 @@ static int __init set_permissions(pte_t *ptep, unsigned long addr, void *data)
 {
 	struct set_perm_data *spd = data;
 	const efi_memory_desc_t *md = spd->md;
-	pte_t pte = READ_ONCE(*ptep);
+	pte_t pte = __ptep_get(ptep);
 
 	if (md->attribute & EFI_MEMORY_RO)
 		pte = set_pte_bit(pte, __pgprot(PTE_RDONLY));
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 7cebd9847aae..d63f3a0a7251 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -191,7 +191,7 @@ static void show_pte(unsigned long addr)
 		if (!ptep)
 			break;
 
-		pte = READ_ONCE(*ptep);
+		pte = __ptep_get(ptep);
 		pr_cont(", pte=%016llx", pte_val(pte));
 		pte_unmap(ptep);
 	} while(0);
@@ -214,7 +214,7 @@ int __ptep_set_access_flags(struct vm_area_struct *vma,
 			    pte_t entry, int dirty)
 {
 	pteval_t old_pteval, pteval;
-	pte_t pte = READ_ONCE(*ptep);
+	pte_t pte = __ptep_get(ptep);
 
 	if (pte_same(pte, entry))
 		return 0;
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 627a9717e98c..52fb767607e0 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -152,14 +152,14 @@ pte_t huge_ptep_get(pte_t *ptep)
 {
 	int ncontig, i;
 	size_t pgsize;
-	pte_t orig_pte = ptep_get(ptep);
+	pte_t orig_pte = __ptep_get(ptep);
 
 	if (!pte_present(orig_pte) || !pte_cont(orig_pte))
 		return orig_pte;
 
 	ncontig = num_contig_ptes(page_size(pte_page(orig_pte)), &pgsize);
 	for (i = 0; i < ncontig; i++, ptep++) {
-		pte_t pte = ptep_get(ptep);
+		pte_t pte = __ptep_get(ptep);
 
 		if (pte_dirty(pte))
 			orig_pte = pte_mkdirty(orig_pte);
@@ -184,7 +184,7 @@ static pte_t get_clear_contig(struct mm_struct *mm,
 			     unsigned long pgsize,
 			     unsigned long ncontig)
 {
-	pte_t orig_pte = ptep_get(ptep);
+	pte_t orig_pte = __ptep_get(ptep);
 	unsigned long i;
 
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++) {
@@ -408,7 +408,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
 {
 	int ncontig;
 	size_t pgsize;
-	pte_t orig_pte = ptep_get(ptep);
+	pte_t orig_pte = __ptep_get(ptep);
 
 	if (!pte_cont(orig_pte))
 		return __ptep_get_and_clear(mm, addr, ptep);
@@ -431,11 +431,11 @@ static int __cont_access_flags_changed(pte_t *ptep, pte_t pte, int ncontig)
 {
 	int i;
 
-	if (pte_write(pte) != pte_write(ptep_get(ptep)))
+	if (pte_write(pte) != pte_write(__ptep_get(ptep)))
 		return 1;
 
 	for (i = 0; i < ncontig; i++) {
-		pte_t orig_pte = ptep_get(ptep + i);
+		pte_t orig_pte = __ptep_get(ptep + i);
 
 		if (pte_dirty(pte) != pte_dirty(orig_pte))
 			return 1;
@@ -492,7 +492,7 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
 	size_t pgsize;
 	pte_t pte;
 
-	if (!pte_cont(READ_ONCE(*ptep))) {
+	if (!pte_cont(__ptep_get(ptep))) {
 		__ptep_set_wrprotect(mm, addr, ptep);
 		return;
 	}
@@ -517,7 +517,7 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
 	size_t pgsize;
 	int ncontig;
 
-	if (!pte_cont(READ_ONCE(*ptep)))
+	if (!pte_cont(__ptep_get(ptep)))
 		return ptep_clear_flush(vma, addr, ptep);
 
 	ncontig = find_num_contig(mm, addr, ptep, &pgsize);
@@ -550,7 +550,7 @@ pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr
 		 * when the permission changes from executable to non-executable
 		 * in cases where cpu is affected with errata #2645198.
 		 */
-		if (pte_user_exec(READ_ONCE(*ptep)))
+		if (pte_user_exec(__ptep_get(ptep)))
 			return huge_ptep_clear_flush(vma, addr, ptep);
 	}
 	return huge_ptep_get_and_clear(vma->vm_mm, addr, ptep);
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 5eade712e9e5..5274c317d775 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -113,7 +113,7 @@ static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
 			memset(__va(page_phys), KASAN_SHADOW_INIT, PAGE_SIZE);
 		next = addr + PAGE_SIZE;
 		__set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
-	} while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep)));
+	} while (ptep++, addr = next, addr != end && pte_none(__ptep_get(ptep)));
 }
 
 static void __init kasan_pmd_populate(pud_t *pudp, unsigned long addr,
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 080e9b50f595..784f1e312447 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -176,7 +176,7 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 
 	ptep = pte_set_fixmap_offset(pmdp, addr);
 	do {
-		pte_t old_pte = READ_ONCE(*ptep);
+		pte_t old_pte = __ptep_get(ptep);
 
 		__set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
 
@@ -185,7 +185,7 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 		 * only allow updates to the permission attributes.
 		 */
 		BUG_ON(!pgattr_change_is_safe(pte_val(old_pte),
-					      READ_ONCE(pte_val(*ptep))));
+					      pte_val(__ptep_get(ptep))));
 
 		phys += PAGE_SIZE;
 	} while (ptep++, addr += PAGE_SIZE, addr != end);
@@ -854,7 +854,7 @@ static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
 
 	do {
 		ptep = pte_offset_kernel(pmdp, addr);
-		pte = READ_ONCE(*ptep);
+		pte = __ptep_get(ptep);
 		if (pte_none(pte))
 			continue;
 
@@ -987,7 +987,7 @@ static void free_empty_pte_table(pmd_t *pmdp, unsigned long addr,
 
 	do {
 		ptep = pte_offset_kernel(pmdp, addr);
-		pte = READ_ONCE(*ptep);
+		pte = __ptep_get(ptep);
 
 		/*
 		 * This is just a sanity check here which verifies that
@@ -1006,7 +1006,7 @@ static void free_empty_pte_table(pmd_t *pmdp, unsigned long addr,
 	 */
 	ptep = pte_offset_kernel(pmdp, 0UL);
 	for (i = 0; i < PTRS_PER_PTE; i++) {
-		if (!pte_none(READ_ONCE(ptep[i])))
+		if (!pte_none(__ptep_get(&ptep[i])))
 			return;
 	}
 
@@ -1475,7 +1475,7 @@ pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr, pte
 		 * when the permission changes from executable to non-executable
 		 * in cases where cpu is affected with errata #2645198.
 		 */
-		if (pte_user_exec(READ_ONCE(*ptep)))
+		if (pte_user_exec(ptep_get(ptep)))
 			return ptep_clear_flush(vma, addr, ptep);
 	}
 	return ptep_get_and_clear(vma->vm_mm, addr, ptep);
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 057097acf9e0..624b0b0982e3 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -36,7 +36,7 @@ bool can_set_direct_map(void)
 static int change_page_range(pte_t *ptep, unsigned long addr, void *data)
 {
 	struct page_change_data *cdata = data;
-	pte_t pte = READ_ONCE(*ptep);
+	pte_t pte = __ptep_get(ptep);
 
 	pte = clear_pte_bit(pte, cdata->clear_mask);
 	pte = set_pte_bit(pte, cdata->set_mask);
@@ -246,5 +246,5 @@ bool kernel_page_present(struct page *page)
 		return true;
 
 	ptep = pte_offset_kernel(pmdp, addr);
-	return pte_valid(READ_ONCE(*ptep));
+	return pte_valid(__ptep_get(ptep));
 }
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 230b607cf881..5139a28130c0 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -33,7 +33,7 @@ static void *trans_alloc(struct trans_pgd_info *info)
 
 static void _copy_pte(pte_t *dst_ptep, pte_t *src_ptep, unsigned long addr)
 {
-	pte_t pte = READ_ONCE(*src_ptep);
+	pte_t pte = __ptep_get(src_ptep);
 
 	if (pte_valid(pte)) {
 		/*
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:37 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:37 +0000
Subject: [PATCH v3 12/15] arm64/mm: Split __flush_tlb_range() to elide trailing DSB
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-13-ryan.roberts@arm.com>

Split __flush_tlb_range() into __flush_tlb_range_nosync() +
__flush_tlb_range(), in the same way as the existing flush_tlb_page()
arrangement. This allows calling __flush_tlb_range_nosync() to elide the
trailing DSB. Forthcoming "contpte" code will take advantage of this
when clearing the young bit from a contiguous range of ptes.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/tlbflush.h | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index bb2c2833a987..925ef3bdf9ed 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -399,7 +399,7 @@ do {									\
 #define __flush_s2_tlb_range_op(op, start, pages, stride, tlb_level) \
 	__flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false)
 
-static inline void __flush_tlb_range(struct vm_area_struct *vma,
+static inline void __flush_tlb_range_nosync(struct vm_area_struct *vma,
 				     unsigned long start, unsigned long end,
 				     unsigned long stride, bool last_level,
 				     int tlb_level)
@@ -431,10 +431,19 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
 	else
 		__flush_tlb_range_op(vae1is, start, pages, stride, asid, tlb_level, true);
 
-	dsb(ish);
 	mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, start, end);
 }
 
+static inline void __flush_tlb_range(struct vm_area_struct *vma,
+				     unsigned long start, unsigned long end,
+				     unsigned long stride, bool last_level,
+				     int tlb_level)
+{
+	__flush_tlb_range_nosync(vma, start, end, stride,
+				 last_level, tlb_level);
+	dsb(ish);
+}
+
 static inline void flush_tlb_range(struct vm_area_struct *vma,
 				   unsigned long start, unsigned long end)
 {
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:30 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:30 +0000
Subject: [PATCH v3 05/15] arm64/mm: pte_clear(): New layer to manage contig bit
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-6-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 3 ++-
 arch/arm64/mm/fixmap.c           | 2 +-
 arch/arm64/mm/hugetlbpage.c      | 2 +-
 arch/arm64/mm/mmu.c              | 2 +-
 4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 323ec91add60..1464e990580a 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -93,7 +93,7 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
 	__pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
 
 #define pte_none(pte)		(!pte_val(pte))
-#define pte_clear(mm, addr, ptep) \
+#define __pte_clear(mm, addr, ptep) \
 				__set_pte(ptep, __pte(0))
 #define pte_page(pte)		(pfn_to_page(pte_pfn(pte)))
 
@@ -1121,6 +1121,7 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 
 #define set_pte					__set_pte
 #define set_ptes				__set_ptes
+#define pte_clear				__pte_clear
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index 51cd4501816d..bfc02568805a 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -123,7 +123,7 @@ void __set_fixmap(enum fixed_addresses idx,
 	if (pgprot_val(flags)) {
 		__set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, flags));
 	} else {
-		pte_clear(&init_mm, addr, ptep);
+		__pte_clear(&init_mm, addr, ptep);
 		flush_tlb_kernel_range(addr, addr+PAGE_SIZE);
 	}
 }
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 741cb53672fd..510b2d4b89a9 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -400,7 +400,7 @@ void huge_pte_clear(struct mm_struct *mm, unsigned long addr,
 	ncontig = num_contig_ptes(sz, &pgsize);
 
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++)
-		pte_clear(mm, addr, ptep);
+		__pte_clear(mm, addr, ptep);
 }
 
 pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index e884279b268e..080e9b50f595 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -859,7 +859,7 @@ static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
 			continue;
 
 		WARN_ON(!pte_present(pte));
-		pte_clear(&init_mm, addr, ptep);
+		__pte_clear(&init_mm, addr, ptep);
 		flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
 		if (free_mapped)
 			free_hotplug_page_range(pte_page(pte),
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:31 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:31 +0000
Subject: [PATCH v3 06/15] arm64/mm: ptep_get_and_clear(): New layer to manage contig bit
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-7-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 5 +++--
 arch/arm64/mm/hugetlbpage.c      | 6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 1464e990580a..994597a0bb0f 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -941,8 +941,7 @@ static inline int pmdp_test_and_clear_young(struct vm_area_struct *vma,
 }
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
-#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
-static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
+static inline pte_t __ptep_get_and_clear(struct mm_struct *mm,
 				       unsigned long address, pte_t *ptep)
 {
 	pte_t pte = __pte(xchg_relaxed(&pte_val(*ptep), 0));
@@ -1122,6 +1121,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define set_pte					__set_pte
 #define set_ptes				__set_ptes
 #define pte_clear				__pte_clear
+#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
+#define ptep_get_and_clear			__ptep_get_and_clear
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 510b2d4b89a9..c2a753541d13 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -188,7 +188,7 @@ static pte_t get_clear_contig(struct mm_struct *mm,
 	unsigned long i;
 
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++) {
-		pte_t pte = ptep_get_and_clear(mm, addr, ptep);
+		pte_t pte = __ptep_get_and_clear(mm, addr, ptep);
 
 		/*
 		 * If HW_AFDBM is enabled, then the HW could turn on
@@ -236,7 +236,7 @@ static void clear_flush(struct mm_struct *mm,
 	unsigned long i, saddr = addr;
 
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++)
-		ptep_clear(mm, addr, ptep);
+		__ptep_get_and_clear(mm, addr, ptep);
 
 	flush_tlb_range(&vma, saddr, addr);
 }
@@ -411,7 +411,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
 	pte_t orig_pte = ptep_get(ptep);
 
 	if (!pte_cont(orig_pte))
-		return ptep_get_and_clear(mm, addr, ptep);
+		return __ptep_get_and_clear(mm, addr, ptep);
 
 	ncontig = find_num_contig(mm, addr, ptep, &pgsize);
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:32 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:32 +0000
Subject: [PATCH v3 07/15] arm64/mm: ptep_test_and_clear_young(): New layer to manage contig bit
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-8-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 994597a0bb0f..9b4a9909fd5b 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -887,8 +887,9 @@ static inline bool pud_user_accessible_page(pud_t pud)
 /*
  * Atomic pte/pmd modifications.
  */
-#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
-static inline int __ptep_test_and_clear_young(pte_t *ptep)
+static inline int __ptep_test_and_clear_young(struct vm_area_struct *vma,
+					      unsigned long address,
+					      pte_t *ptep)
 {
 	pte_t old_pte, pte;
 
@@ -903,18 +904,11 @@ static inline int __ptep_test_and_clear_young(pte_t *ptep)
 	return pte_young(pte);
 }
 
-static inline int ptep_test_and_clear_young(struct vm_area_struct *vma,
-					    unsigned long address,
-					    pte_t *ptep)
-{
-	return __ptep_test_and_clear_young(ptep);
-}
-
 #define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
 static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
 					 unsigned long address, pte_t *ptep)
 {
-	int young = ptep_test_and_clear_young(vma, address, ptep);
+	int young = __ptep_test_and_clear_young(vma, address, ptep);
 
 	if (young) {
 		/*
@@ -937,7 +931,7 @@ static inline int pmdp_test_and_clear_young(struct vm_area_struct *vma,
 					    unsigned long address,
 					    pmd_t *pmdp)
 {
-	return ptep_test_and_clear_young(vma, address, (pte_t *)pmdp);
+	return __ptep_test_and_clear_young(vma, address, (pte_t *)pmdp);
 }
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
@@ -1123,6 +1117,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define pte_clear				__pte_clear
 #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
 #define ptep_get_and_clear			__ptep_get_and_clear
+#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
+#define ptep_test_and_clear_young		__ptep_test_and_clear_young
 
 #endif /* !__ASSEMBLY__ */
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:39 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:39 +0000
Subject: [PATCH v3 14/15] arm64/mm: Implement ptep_set_wrprotects() to optimize fork()
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-15-ryan.roberts@arm.com>

With the core-mm changes in place to batch-copy ptes during fork, we can
take advantage of this in arm64 to greatly reduce the number of tlbis we
have to issue, and recover the lost fork performance incured when adding
support for transparent contiguous ptes.

If we are write-protecting a whole contig range, we can apply the
write-protection to the whole range and know that it won't change
whether the range should have the contiguous bit set or not. For ranges
smaller than the contig range, we will still have to unfold, apply the
write-protection, then fold if the change now means the range is
foldable.

This optimization is possible thanks to the tightening of the Arm ARM in
respect to the definition and behaviour when 'Misprogramming the
Contiguous bit'. See section D21194 at
https://developer.arm.com/documentation/102105/latest/

Performance tested with the following test written for the will-it-scale
framework:

-------

char *testcase_description = "fork and exit";

void testcase(unsigned long long *iterations, unsigned long nr)
{
	int pid;
	char *mem;

	mem = malloc(SZ_128M);
	assert(mem);
	memset(mem, 1, SZ_128M);

	while (1) {
		pid = fork();
		assert(pid >= 0);

		if (!pid)
			exit(0);

		waitpid(pid, NULL, 0);

		(*iterations)++;
	}
}

-------

I see huge performance regression when PTE_CONT support was added, then
the regression is mostly fixed with the addition of this change. The
following shows regression relative to before PTE_CONT was enabled
(bigger negative value is bigger regression):

|   cpus |   before opt |   after opt |
|-------:|-------------:|------------:|
|      1 |       -10.4% |       -5.2% |
|      8 |       -15.4% |       -3.5% |
|     16 |       -38.7% |       -3.7% |
|     24 |       -57.0% |       -4.4% |
|     32 |       -65.8% |       -5.4% |

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 30 ++++++++++++++++++++---
 arch/arm64/mm/contpte.c          | 42 ++++++++++++++++++++++++++++++++
 2 files changed, 69 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 15bc9cf1eef4..9bd2f57a9e11 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -984,6 +984,16 @@ static inline void __ptep_set_wrprotect(struct mm_struct *mm,
 	} while (pte_val(pte) != pte_val(old_pte));
 }
 
+static inline void __ptep_set_wrprotects(struct mm_struct *mm,
+					unsigned long address, pte_t *ptep,
+					unsigned int nr)
+{
+	unsigned int i;
+
+	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
+		__ptep_set_wrprotect(mm, address, ptep);
+}
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 #define __HAVE_ARCH_PMDP_SET_WRPROTECT
 static inline void pmdp_set_wrprotect(struct mm_struct *mm,
@@ -1139,6 +1149,8 @@ extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
 				unsigned long addr, pte_t *ptep);
 extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
 				unsigned long addr, pte_t *ptep);
+extern void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, unsigned int nr);
 extern int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
 				unsigned long addr, pte_t *ptep,
 				pte_t entry, int dirty);
@@ -1290,13 +1302,25 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
 	return contpte_ptep_clear_flush_young(vma, addr, ptep);
 }
 
+#define ptep_set_wrprotects ptep_set_wrprotects
+static inline void ptep_set_wrprotects(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, unsigned int nr)
+{
+	if (!contpte_is_enabled(mm))
+		__ptep_set_wrprotects(mm, addr, ptep, nr);
+	else if (nr == 1) {
+		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+		__ptep_set_wrprotects(mm, addr, ptep, 1);
+		contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
+	} else
+		contpte_set_wrprotects(mm, addr, ptep, nr);
+}
+
 #define __HAVE_ARCH_PTEP_SET_WRPROTECT
 static inline void ptep_set_wrprotect(struct mm_struct *mm,
 				unsigned long addr, pte_t *ptep)
 {
-	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
-	__ptep_set_wrprotect(mm, addr, ptep);
-	contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
+	ptep_set_wrprotects(mm, addr, ptep, 1);
 }
 
 #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
index e079ec61d7d1..2a57df16bf58 100644
--- a/arch/arm64/mm/contpte.c
+++ b/arch/arm64/mm/contpte.c
@@ -303,6 +303,48 @@ int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL(contpte_ptep_clear_flush_young);
 
+void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
+					pte_t *ptep, unsigned int nr)
+{
+	unsigned long next;
+	unsigned long end = addr + (nr << PAGE_SHIFT);
+
+	do {
+		next = pte_cont_addr_end(addr, end);
+		nr = (next - addr) >> PAGE_SHIFT;
+
+		/*
+		 * If wrprotecting an entire contig range, we can avoid
+		 * unfolding. Just set wrprotect and wait for the later
+		 * mmu_gather flush to invalidate the tlb. Until the flush, the
+		 * page may or may not be wrprotected. After the flush, it is
+		 * guarranteed wrprotected. If its a partial range though, we
+		 * must unfold, because we can't have a case where CONT_PTE is
+		 * set but wrprotect applies to a subset of the PTEs; this would
+		 * cause it to continue to be unpredictable after the flush.
+		 */
+		if (nr != CONT_PTES)
+			contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+
+		__ptep_set_wrprotects(mm, addr, ptep, nr);
+
+		addr = next;
+		ptep += nr;
+
+		/*
+		 * If applying to a partial contig range, the change could have
+		 * made the range foldable. Use the last pte in the range we
+		 * just set for comparison, since contpte_try_fold() only
+		 * triggers when acting on the last pte in the contig range.
+		 */
+		if (nr != CONT_PTES)
+			contpte_try_fold(mm, addr - PAGE_SIZE, ptep - 1,
+					 __ptep_get(ptep - 1));
+
+	} while (addr != end);
+}
+EXPORT_SYMBOL(contpte_set_wrprotects);
+
 int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
 					unsigned long addr, pte_t *ptep,
 					pte_t entry, int dirty)
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:38 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:38 +0000
Subject: [PATCH v3 13/15] arm64/mm: Wire up PTE_CONT for user mappings
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-14-ryan.roberts@arm.com>

With the ptep API sufficiently refactored, we can now introduce a new
"contpte" API layer, which transparently manages the PTE_CONT bit for
user mappings. Whenever it detects a set of PTEs that meet the
requirements for a contiguous range, the PTEs are re-painted with the
PTE_CONT bit. Use of contpte mappings is intended to be transparent to
the core-mm, which continues to interact with individual ptes.

Since a contpte block only has a single access and dirty bit, the
semantic here changes slightly; when getting a pte (e.g. ptep_get())
that is part of a contpte mapping, the access and dirty information are
pulled from the block (so all ptes in the block return the same
access/dirty info). When changing the access/dirty info on a pte (e.g.
ptep_set_access_flags()) that is part of a contpte mapping, this change
will affect the whole contpte block. This is works fine in practice
since we guarrantee that only a single folio is mapped by a contpte
block, and the core-mm tracks access/dirty information per folio.

This initial change provides a baseline that can be optimized in future
commits. That said, fold/unfold operations (which imply tlb
invalidation) are avoided where possible with a few tricks for
access/dirty bit management. Write-protect modifications for contpte
mappings are currently non-optimal, and incure a regression in fork()
performance. This will be addressed in follow-up changes.

In order for the public functions, which used to be pure inline, to
continue to be callable by modules, export all the contpte_* symbols
that are now called by those public inline functions.

The feature is enabled/disabled with the ARM64_CONTPTE Kconfig parameter
at build time. It defaults to enabled as long as its dependency,
TRANSPARENT_HUGEPAGE is also enabled. The core-mm depends upon
TRANSPARENT_HUGEPAGE to be able to allocate large folios, so if its not
enabled, then there is no chance of meeting the physical contiguity
requirement for contpte mappings.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/Kconfig               |  10 +-
 arch/arm64/include/asm/pgtable.h | 202 ++++++++++++++++++
 arch/arm64/mm/Makefile           |   1 +
 arch/arm64/mm/contpte.c          | 352 +++++++++++++++++++++++++++++++
 4 files changed, 564 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/mm/contpte.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..de76e484ff3a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2209,6 +2209,15 @@ config UNWIND_PATCH_PAC_INTO_SCS
 	select UNWIND_TABLES
 	select DYNAMIC_SCS
 
+config ARM64_CONTPTE
+	bool "Contiguous PTE mappings for user memory" if EXPERT
+	depends on TRANSPARENT_HUGEPAGE
+	default y
+	help
+	  When enabled, user mappings are configured using the PTE contiguous
+	  bit, for any mappings that meet the size and alignment requirements.
+	  This reduces TLB pressure and improves performance.
+
 endmenu # "Kernel Features"
 
 menu "Boot options"
@@ -2318,4 +2327,3 @@ endmenu # "CPU Power Management"
 source "drivers/acpi/Kconfig"
 
 source "arch/arm64/kvm/Kconfig"
-
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 6930c14f062f..15bc9cf1eef4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -133,6 +133,10 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
  */
 #define pte_valid_not_user(pte) \
 	((pte_val(pte) & (PTE_VALID | PTE_USER | PTE_UXN)) == (PTE_VALID | PTE_UXN))
+/*
+ * Returns true if the pte is valid and has the contiguous bit set.
+ */
+#define pte_valid_cont(pte)	(pte_valid(pte) && pte_cont(pte))
 /*
  * Could the pte be present in the TLB? We must check mm_tlb_flush_pending
  * so that we don't erroneously return false for pages that have been
@@ -1116,6 +1120,202 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 				    unsigned long addr, pte_t *ptep,
 				    pte_t old_pte, pte_t new_pte);
 
+#ifdef CONFIG_ARM64_CONTPTE
+
+/*
+ * The contpte APIs are used to transparently manage the contiguous bit in ptes
+ * where it is possible and makes sense to do so. The PTE_CONT bit is considered
+ * a private implementation detail of the public ptep API (see below).
+ */
+extern void __contpte_try_fold(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte);
+extern void __contpte_try_unfold(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte);
+extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
+extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
+extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte, unsigned int nr);
+extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep);
+extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep);
+extern int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep,
+				pte_t entry, int dirty);
+
+static inline pte_t *contpte_align_down(pte_t *ptep)
+{
+	return (pte_t *)(ALIGN_DOWN((unsigned long)ptep >> 3, CONT_PTES) << 3);
+}
+
+static inline bool contpte_is_enabled(struct mm_struct *mm)
+{
+	/*
+	 * Don't attempt to apply the contig bit to kernel mappings, because
+	 * dynamically adding/removing the contig bit can cause page faults.
+	 * These racing faults are ok for user space, since they get serialized
+	 * on the PTL. But kernel mappings can't tolerate faults.
+	 */
+
+	return mm != &init_mm;
+}
+
+static inline void contpte_try_fold(struct mm_struct *mm, unsigned long addr,
+					pte_t *ptep, pte_t pte)
+{
+	/*
+	 * Only bother trying if both the virtual and physical addresses are
+	 * aligned and correspond to the last entry in a contig range. The core
+	 * code mostly modifies ranges from low to high, so this is the likely
+	 * the last modification in the contig range, so a good time to fold.
+	 * We can't fold special mappings, because there is no associated folio.
+	 */
+
+	bool valign = ((unsigned long)ptep >> 3) % CONT_PTES == CONT_PTES - 1;
+	bool palign = pte_pfn(pte) % CONT_PTES == CONT_PTES - 1;
+
+	if (contpte_is_enabled(mm) && valign && palign &&
+	    pte_valid(pte) && !pte_cont(pte) && !pte_special(pte))
+		__contpte_try_fold(mm, addr, ptep, pte);
+}
+
+static inline void contpte_try_unfold(struct mm_struct *mm, unsigned long addr,
+					pte_t *ptep, pte_t pte)
+{
+	if (contpte_is_enabled(mm) && pte_valid_cont(pte))
+		__contpte_try_unfold(mm, addr, ptep, pte);
+}
+
+/*
+ * The below functions constitute the public API that arm64 presents to the
+ * core-mm to manipulate PTE entries within the their page tables (or at least
+ * this is the subset of the API that arm64 needs to implement). These public
+ * versions will automatically and transparently apply the contiguous bit where
+ * it makes sense to do so. Therefore any users that are contig-aware (e.g.
+ * hugetlb, kernel mapper) should NOT use these APIs, but instead use the
+ * private versions, which are prefixed with double underscore. All of these
+ * APIs except for ptep_get_lockless() are expected to be called with the PTL
+ * held.
+ */
+
+#define ptep_get ptep_get
+static inline pte_t ptep_get(pte_t *ptep)
+{
+	pte_t pte = __ptep_get(ptep);
+
+	if (!pte_valid_cont(pte))
+		return pte;
+
+	return contpte_ptep_get(ptep, pte);
+}
+
+#define ptep_get_lockless ptep_get_lockless
+static inline pte_t ptep_get_lockless(pte_t *ptep)
+{
+	pte_t pte = __ptep_get(ptep);
+
+	if (!pte_valid_cont(pte))
+		return pte;
+
+	return contpte_ptep_get_lockless(ptep);
+}
+
+static inline void set_pte(pte_t *ptep, pte_t pte)
+{
+	/*
+	 * We don't have the mm or vaddr so cannot unfold or fold contig entries
+	 * (since it requires tlb maintenance). set_pte() is not used in core
+	 * code, so this should never even be called. Regardless do our best to
+	 * service any call and emit a warning if there is any attempt to set a
+	 * pte on top of an existing contig range.
+	 */
+	pte_t orig_pte = __ptep_get(ptep);
+
+	WARN_ON_ONCE(pte_valid_cont(orig_pte));
+	__set_pte(ptep, pte_mknoncont(pte));
+}
+
+#define set_ptes set_ptes
+static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte, unsigned int nr)
+{
+	pte = pte_mknoncont(pte);
+
+	if (!contpte_is_enabled(mm))
+		__set_ptes(mm, addr, ptep, pte, nr);
+	else if (nr == 1) {
+		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+		__set_ptes(mm, addr, ptep, pte, nr);
+		contpte_try_fold(mm, addr, ptep, pte);
+	} else
+		contpte_set_ptes(mm, addr, ptep, pte, nr);
+}
+
+static inline void pte_clear(struct mm_struct *mm,
+				unsigned long addr, pte_t *ptep)
+{
+	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+	__pte_clear(mm, addr, ptep);
+}
+
+#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
+static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
+				unsigned long addr, pte_t *ptep)
+{
+	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+	return __ptep_get_and_clear(mm, addr, ptep);
+}
+
+#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
+static inline int ptep_test_and_clear_young(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep)
+{
+	pte_t orig_pte = __ptep_get(ptep);
+
+	if (!pte_valid_cont(orig_pte))
+		return __ptep_test_and_clear_young(vma, addr, ptep);
+
+	return contpte_ptep_test_and_clear_young(vma, addr, ptep);
+}
+
+#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
+static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep)
+{
+	pte_t orig_pte = __ptep_get(ptep);
+
+	if (!pte_valid_cont(orig_pte))
+		return __ptep_clear_flush_young(vma, addr, ptep);
+
+	return contpte_ptep_clear_flush_young(vma, addr, ptep);
+}
+
+#define __HAVE_ARCH_PTEP_SET_WRPROTECT
+static inline void ptep_set_wrprotect(struct mm_struct *mm,
+				unsigned long addr, pte_t *ptep)
+{
+	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+	__ptep_set_wrprotect(mm, addr, ptep);
+	contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
+}
+
+#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
+static inline int ptep_set_access_flags(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep,
+				pte_t entry, int dirty)
+{
+	pte_t orig_pte = __ptep_get(ptep);
+
+	entry = pte_mknoncont(entry);
+
+	if (!pte_valid_cont(orig_pte))
+		return __ptep_set_access_flags(vma, addr, ptep, entry, dirty);
+
+	return contpte_ptep_set_access_flags(vma, addr, ptep, entry, dirty);
+}
+
+#else /* CONFIG_ARM64_CONTPTE */
+
 #define ptep_get				__ptep_get
 #define set_pte					__set_pte
 #define set_ptes				__set_ptes
@@ -1131,6 +1331,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 #define ptep_set_access_flags			__ptep_set_access_flags
 
+#endif /* CONFIG_ARM64_CONTPTE */
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_H */
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index dbd1bc95967d..60454256945b 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -3,6 +3,7 @@ obj-y				:= dma-mapping.o extable.o fault.o init.o \
 				   cache.o copypage.o flush.o \
 				   ioremap.o mmap.o pgd.o mmu.o \
 				   context.o proc.o pageattr.o fixmap.o
+obj-$(CONFIG_ARM64_CONTPTE)	+= contpte.o
 obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
 obj-$(CONFIG_PTDUMP_CORE)	+= ptdump.o
 obj-$(CONFIG_PTDUMP_DEBUGFS)	+= ptdump_debugfs.o
diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
new file mode 100644
index 000000000000..e079ec61d7d1
--- /dev/null
+++ b/arch/arm64/mm/contpte.c
@@ -0,0 +1,352 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 ARM Ltd.
+ */
+
+#include <linux/mm.h>
+#include <linux/export.h>
+#include <asm/tlbflush.h>
+
+static void ptep_clear_flush_range(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, int nr)
+{
+	struct vm_area_struct vma = TLB_FLUSH_VMA(mm, 0);
+	unsigned long start_addr = addr;
+	int i;
+
+	for (i = 0; i < nr; i++, ptep++, addr += PAGE_SIZE)
+		__pte_clear(mm, addr, ptep);
+
+	__flush_tlb_range(&vma, start_addr, addr, PAGE_SIZE, true, 3);
+}
+
+static bool ptep_any_valid(pte_t *ptep, int nr)
+{
+	int i;
+
+	for (i = 0; i < nr; i++, ptep++) {
+		if (pte_valid(__ptep_get(ptep)))
+			return true;
+	}
+
+	return false;
+}
+
+static void contpte_convert(struct mm_struct *mm, unsigned long addr,
+			    pte_t *ptep, pte_t pte)
+{
+	struct vm_area_struct vma = TLB_FLUSH_VMA(mm, 0);
+	unsigned long start_addr;
+	pte_t *start_ptep;
+	int i;
+
+	start_ptep = ptep = contpte_align_down(ptep);
+	start_addr = addr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+	pte = pfn_pte(ALIGN_DOWN(pte_pfn(pte), CONT_PTES), pte_pgprot(pte));
+
+	for (i = 0; i < CONT_PTES; i++, ptep++, addr += PAGE_SIZE) {
+		pte_t ptent = __ptep_get_and_clear(mm, addr, ptep);
+
+		if (pte_dirty(ptent))
+			pte = pte_mkdirty(pte);
+
+		if (pte_young(ptent))
+			pte = pte_mkyoung(pte);
+	}
+
+	__flush_tlb_range(&vma, start_addr, addr, PAGE_SIZE, true, 3);
+
+	__set_ptes(mm, start_addr, start_ptep, pte, CONT_PTES);
+}
+
+void __contpte_try_fold(struct mm_struct *mm, unsigned long addr,
+			pte_t *ptep, pte_t pte)
+{
+	/*
+	 * We have already checked that the virtual and pysical addresses are
+	 * correctly aligned for a contpte mapping in contpte_try_fold() so the
+	 * remaining checks are to ensure that the contpte range is fully
+	 * covered by a single folio, and ensure that all the ptes are valid
+	 * with contiguous PFNs and matching prots. We ignore the state of the
+	 * access and dirty bits for the purpose of deciding if its a contiguous
+	 * range; the folding process will generate a single contpte entry which
+	 * has a single access and dirty bit. Those 2 bits are the logical OR of
+	 * their respective bits in the constituent pte entries. In order to
+	 * ensure the contpte range is covered by a single folio, we must
+	 * recover the folio from the pfn, but special mappings don't have a
+	 * folio backing them. Fortunately contpte_try_fold() already checked
+	 * that the pte is not special - we never try to fold special mappings.
+	 * Note we can't use vm_normal_page() for this since we don't have the
+	 * vma.
+	 */
+
+	struct page *page = pte_page(pte);
+	struct folio *folio = page_folio(page);
+	unsigned long folio_saddr = addr - (page - &folio->page) * PAGE_SIZE;
+	unsigned long folio_eaddr = folio_saddr + folio_nr_pages(folio) * PAGE_SIZE;
+	unsigned long cont_saddr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+	unsigned long cont_eaddr = cont_saddr + CONT_PTE_SIZE;
+	unsigned long pfn;
+	pgprot_t prot;
+	pte_t subpte;
+	pte_t *orig_ptep;
+	int i;
+
+	if (folio_saddr > cont_saddr || folio_eaddr < cont_eaddr)
+		return;
+
+	pfn = pte_pfn(pte) - ((addr - cont_saddr) >> PAGE_SHIFT);
+	prot = pte_pgprot(pte_mkold(pte_mkclean(pte)));
+	orig_ptep = ptep;
+	ptep = contpte_align_down(ptep);
+
+	for (i = 0; i < CONT_PTES; i++, ptep++, pfn++) {
+		subpte = __ptep_get(ptep);
+		subpte = pte_mkold(pte_mkclean(subpte));
+
+		if (!pte_valid(subpte) ||
+		    pte_pfn(subpte) != pfn ||
+		    pgprot_val(pte_pgprot(subpte)) != pgprot_val(prot))
+			return;
+	}
+
+	pte = pte_mkcont(pte);
+	contpte_convert(mm, addr, orig_ptep, pte);
+}
+EXPORT_SYMBOL(__contpte_try_fold);
+
+void __contpte_try_unfold(struct mm_struct *mm, unsigned long addr,
+			pte_t *ptep, pte_t pte)
+{
+	/*
+	 * We have already checked that the ptes are contiguous in
+	 * contpte_try_unfold(), so we can unfold unconditionally here.
+	 */
+
+	pte = pte_mknoncont(pte);
+	contpte_convert(mm, addr, ptep, pte);
+}
+EXPORT_SYMBOL(__contpte_try_unfold);
+
+pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte)
+{
+	/*
+	 * Gather access/dirty bits, which may be populated in any of the ptes
+	 * of the contig range. We are guarranteed to be holding the PTL, so any
+	 * contiguous range cannot be unfolded or otherwise modified under our
+	 * feet.
+	 */
+
+	pte_t pte;
+	int i;
+
+	ptep = contpte_align_down(ptep);
+
+	for (i = 0; i < CONT_PTES; i++, ptep++) {
+		pte = __ptep_get(ptep);
+
+		if (pte_dirty(pte))
+			orig_pte = pte_mkdirty(orig_pte);
+
+		if (pte_young(pte))
+			orig_pte = pte_mkyoung(orig_pte);
+	}
+
+	return orig_pte;
+}
+EXPORT_SYMBOL(contpte_ptep_get);
+
+pte_t contpte_ptep_get_lockless(pte_t *orig_ptep)
+{
+	/*
+	 * Gather access/dirty bits, which may be populated in any of the ptes
+	 * of the contig range. We may not be holding the PTL, so any contiguous
+	 * range may be unfolded/modified/refolded under our feet. Therefore we
+	 * ensure we read a _consistent_ contpte range by checking that all ptes
+	 * in the range are valid and have CONT_PTE set, that all pfns are
+	 * contiguous and that all pgprots are the same (ignoring access/dirty).
+	 * If we find a pte that is not consistent, then we must be racing with
+	 * an update so start again. If the target pte does not have CONT_PTE
+	 * set then that is considered consistent on its own because it is not
+	 * part of a contpte range.
+	 */
+
+	pte_t orig_pte;
+	pgprot_t orig_prot;
+	pte_t *ptep;
+	unsigned long pfn;
+	pte_t pte;
+	pgprot_t prot;
+	int i;
+
+retry:
+	orig_pte = __ptep_get(orig_ptep);
+
+	if (!pte_valid_cont(orig_pte))
+		return orig_pte;
+
+	orig_prot = pte_pgprot(pte_mkold(pte_mkclean(orig_pte)));
+	ptep = contpte_align_down(orig_ptep);
+	pfn = pte_pfn(orig_pte) - (orig_ptep - ptep);
+
+	for (i = 0; i < CONT_PTES; i++, ptep++, pfn++) {
+		pte = __ptep_get(ptep);
+		prot = pte_pgprot(pte_mkold(pte_mkclean(pte)));
+
+		if (!pte_valid_cont(pte) ||
+		   pte_pfn(pte) != pfn ||
+		   pgprot_val(prot) != pgprot_val(orig_prot))
+			goto retry;
+
+		if (pte_dirty(pte))
+			orig_pte = pte_mkdirty(orig_pte);
+
+		if (pte_young(pte))
+			orig_pte = pte_mkyoung(orig_pte);
+	}
+
+	return orig_pte;
+}
+EXPORT_SYMBOL(contpte_ptep_get_lockless);
+
+void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
+					pte_t *ptep, pte_t pte, unsigned int nr)
+{
+	unsigned long next;
+	unsigned long end = addr + (nr << PAGE_SHIFT);
+	unsigned long pfn = pte_pfn(pte);
+	pgprot_t prot = pte_pgprot(pte);
+	pte_t orig_pte;
+
+	do {
+		next = pte_cont_addr_end(addr, end);
+		nr = (next - addr) >> PAGE_SHIFT;
+		pte = pfn_pte(pfn, prot);
+
+		if (((addr | next | (pfn << PAGE_SHIFT)) & ~CONT_PTE_MASK) == 0)
+			pte = pte_mkcont(pte);
+		else
+			pte = pte_mknoncont(pte);
+
+		/*
+		 * If operating on a partial contiguous range then we must first
+		 * unfold the contiguous range if it was previously folded.
+		 * Otherwise we could end up with overlapping tlb entries.
+		 */
+		if (nr != CONT_PTES)
+			contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+
+		/*
+		 * If we are replacing ptes that were contiguous or if the new
+		 * ptes are contiguous and any of the ptes being replaced are
+		 * valid, we need to clear and flush the range to prevent
+		 * overlapping tlb entries.
+		 */
+		orig_pte = __ptep_get(ptep);
+		if (pte_valid_cont(orig_pte) ||
+		    (pte_cont(pte) && ptep_any_valid(ptep, nr)))
+			ptep_clear_flush_range(mm, addr, ptep, nr);
+
+		__set_ptes(mm, addr, ptep, pte, nr);
+
+		addr = next;
+		ptep += nr;
+		pfn += nr;
+
+	} while (addr != end);
+}
+EXPORT_SYMBOL(contpte_set_ptes);
+
+int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
+					unsigned long addr, pte_t *ptep)
+{
+	/*
+	 * ptep_clear_flush_young() technically requires us to clear the access
+	 * flag for a _single_ pte. However, the core-mm code actually tracks
+	 * access/dirty per folio, not per page. And since we only create a
+	 * contig range when the range is covered by a single folio, we can get
+	 * away with clearing young for the whole contig range here, so we avoid
+	 * having to unfold.
+	 */
+
+	int i;
+	int young = 0;
+
+	ptep = contpte_align_down(ptep);
+	addr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+
+	for (i = 0; i < CONT_PTES; i++, ptep++, addr += PAGE_SIZE)
+		young |= __ptep_test_and_clear_young(vma, addr, ptep);
+
+	return young;
+}
+EXPORT_SYMBOL(contpte_ptep_test_and_clear_young);
+
+int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
+					unsigned long addr, pte_t *ptep)
+{
+	int young;
+
+	young = contpte_ptep_test_and_clear_young(vma, addr, ptep);
+
+	if (young) {
+		/*
+		 * See comment in __ptep_clear_flush_young(); same rationale for
+		 * eliding the trailing DSB applies here.
+		 */
+		addr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+		__flush_tlb_range_nosync(vma, addr, addr + CONT_PTE_SIZE,
+					 PAGE_SIZE, true, 3);
+	}
+
+	return young;
+}
+EXPORT_SYMBOL(contpte_ptep_clear_flush_young);
+
+int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
+					unsigned long addr, pte_t *ptep,
+					pte_t entry, int dirty)
+{
+	pte_t orig_pte;
+	int i;
+	unsigned long start_addr;
+
+	/*
+	 * Gather the access/dirty bits for the contiguous range. If nothing has
+	 * changed, its a noop.
+	 */
+	orig_pte = ptep_get(ptep);
+	if (pte_val(orig_pte) == pte_val(entry))
+		return 0;
+
+	/*
+	 * We can fix up access/dirty bits without having to unfold/fold the
+	 * contig range. But if the write bit is changing, we need to go through
+	 * the full unfold/fold cycle.
+	 */
+	if (pte_write(orig_pte) == pte_write(entry)) {
+		/*
+		 * For HW access management, we technically only need to update
+		 * the flag on a single pte in the range. But for SW access
+		 * management, we need to update all the ptes to prevent extra
+		 * faults. Avoid per-page tlb flush in __ptep_set_access_flags()
+		 * and instead flush the whole range at the end.
+		 */
+		ptep = contpte_align_down(ptep);
+		start_addr = addr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+
+		for (i = 0; i < CONT_PTES; i++, ptep++, addr += PAGE_SIZE)
+			__ptep_set_access_flags(vma, addr, ptep, entry, 0);
+
+		if (dirty)
+			__flush_tlb_range(vma, start_addr, addr,
+							PAGE_SIZE, true, 3);
+	} else {
+		__contpte_try_unfold(vma->vm_mm, addr, ptep, orig_pte);
+		__ptep_set_access_flags(vma, addr, ptep, entry, dirty);
+		contpte_try_fold(vma->vm_mm, addr, ptep, entry);
+	}
+
+	return 1;
+}
+EXPORT_SYMBOL(contpte_ptep_set_access_flags);
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec  4 02:54:40 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon,  4 Dec 2023 10:54:40 +0000
Subject: [PATCH v3 15/15] arm64/mm: Implement clear_ptes() to optimize exit()
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <20231204105440.61448-16-ryan.roberts@arm.com>

With the core-mm changes in place to batch-clear ptes during
zap_pte_range(), we can take advantage of this in arm64 to greatly
reduce the number of tlbis we have to issue, and recover the lost exit
performance incured when adding support for transparent contiguous ptes.

If we are clearing a whole contpte range, we can elide first unfolding
that range and save the tlbis. We just clear the whole range.

The following shows the results of running a kernel compilation workload
and measuring the cost of arm64_sys_exit_group() (which at ~1.5% is a
very small part of the overall workload).

Benchmarks were run on Ampere Altra in 2 configs; single numa node and 2
numa nodes (tlbis are more expensive in 2 node config).

 - baseline: v6.7-rc1 + anonfolio-v7
 - no-opt: contpte series without any attempt to optimize exit()
 - simple-ptep_get_clear_full: simple optimization to exploit full=1.
   ptep_get_clear_full() does not fully conform to its intended semantic
 - robust-ptep_get_clear_full: similar to previous but
   ptep_get_clear_full() fully conforms to its intended semantic
 - clear_ptes: optimization implemented by this patch

| config                     | numa=1 | numa=2 |
|----------------------------|--------|--------|
| baseline                   |     0% |     0% |
| no-opt                     |   190% |   768% |
| simple-ptep_get_clear_full |     8% |    29% |
| robust-ptep_get_clear_full |    21% |    19% |
| clear_ptes                 |    13% |     9% |

In all cases, the cost of arm64_sys_exit_group() increases; this is
anticipated because there is more work to do to tear down the page
tables. But clear_ptes() gives the smallest increase overall.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 32 ++++++++++++++++++++++++
 arch/arm64/mm/contpte.c          | 42 ++++++++++++++++++++++++++++++++
 2 files changed, 74 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 9bd2f57a9e11..ff6b3cc9e819 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -1145,6 +1145,8 @@ extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
 extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
 extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
 				pte_t *ptep, pte_t pte, unsigned int nr);
+extern pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, unsigned int nr);
 extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
 				unsigned long addr, pte_t *ptep);
 extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
@@ -1270,6 +1272,36 @@ static inline void pte_clear(struct mm_struct *mm,
 	__pte_clear(mm, addr, ptep);
 }
 
+#define clear_ptes clear_ptes
+static inline pte_t clear_ptes(struct mm_struct *mm,
+				unsigned long addr, pte_t *ptep, int full,
+				unsigned int nr)
+{
+	pte_t pte;
+
+	if (!contpte_is_enabled(mm)) {
+		unsigned int i;
+		pte_t tail;
+
+		pte = __ptep_get_and_clear(mm, addr, ptep);
+		for (i = 1; i < nr; i++) {
+			addr += PAGE_SIZE;
+			ptep++;
+			tail = __ptep_get_and_clear(mm, addr, ptep);
+			if (pte_dirty(tail))
+				pte = pte_mkdirty(pte);
+			if (pte_young(tail))
+				pte = pte_mkyoung(pte);
+		}
+	} else if (nr == 1) {
+		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+		pte = __ptep_get_and_clear(mm, addr, ptep);
+	} else
+		pte = contpte_clear_ptes(mm, addr, ptep, nr);
+
+	return pte;
+}
+
 #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
 static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
 				unsigned long addr, pte_t *ptep)
diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
index 2a57df16bf58..34b43bde3fcd 100644
--- a/arch/arm64/mm/contpte.c
+++ b/arch/arm64/mm/contpte.c
@@ -257,6 +257,48 @@ void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
 }
 EXPORT_SYMBOL(contpte_set_ptes);
 
+pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
+					unsigned int nr)
+{
+	/*
+	 * If we cover a partial contpte block at the beginning or end of the
+	 * batch, unfold if currently folded. This makes it safe to clear some
+	 * of the entries while keeping others. contpte blocks in the middle of
+	 * the range, which are fully covered don't need to be unfolded because
+	 * we will clear the full block.
+	 */
+
+	unsigned int i;
+	pte_t pte;
+	pte_t tail;
+
+	if (ptep != contpte_align_down(ptep) || nr < CONT_PTES)
+		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+
+	if (ptep + nr != contpte_align_down(ptep + nr))
+		contpte_try_unfold(mm, addr + PAGE_SIZE * (nr - 1),
+				   ptep + nr - 1,
+				   __ptep_get(ptep + nr - 1));
+
+	pte = __ptep_get_and_clear(mm, addr, ptep);
+
+	for (i = 1; i < nr; i++) {
+		addr += PAGE_SIZE;
+		ptep++;
+
+		tail = __ptep_get_and_clear(mm, addr, ptep);
+
+		if (pte_dirty(tail))
+			pte = pte_mkdirty(pte);
+
+		if (pte_young(tail))
+			pte = pte_mkyoung(pte);
+	}
+
+	return pte;
+}
+EXPORT_SYMBOL(contpte_clear_ptes);
+
 int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
 					unsigned long addr, pte_t *ptep)
 {
-- 
2.25.1



From jic23 at kernel.org  Mon Dec  4 02:57:30 2023
From: jic23 at kernel.org (Jonathan Cameron)
Date: Mon, 4 Dec 2023 10:57:30 +0000
Subject: [PATCH v3 1/1] iio: adc: meson: add separate config for axg SoC
 family
In-Reply-To: <20231127235558.71995-1-gnstark@salutedevices.com>
References: <20231127235558.71995-1-gnstark@salutedevices.com>
Message-ID: <20231204105730.49623b12@jic23-huawei>

On Tue, 28 Nov 2023 02:55:58 +0300
George Stark <gnstark at salutedevices.com> wrote:

> According to Amlogic custom kernels ADC of axg SoC family has
> vref_select and requires this setting to work nominally and thus
> needs a separate config.
> 
> Fixes: 90c6241860bf ("iio: adc: meson: init voltage control bits")
> Signed-off-by: George Stark <gnstark at salutedevices.com>
> Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
Applied to the fixes-togreg branch of iio.git and marked for stable.

Thanks,

jonathan

> ---
>  drivers/iio/adc/meson_saradc.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index db280da9edbf..34555a85f131 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -1242,6 +1242,20 @@ static const struct meson_sar_adc_param meson_sar_adc_gxl_param = {
>  	.cmv_select = 1,
>  };
>  
> +static const struct meson_sar_adc_param meson_sar_adc_axg_param = {
> +	.has_bl30_integration = true,
> +	.clock_rate = 1200000,
> +	.bandgap_reg = MESON_SAR_ADC_REG11,
> +	.regmap_config = &meson_sar_adc_regmap_config_gxbb,
> +	.resolution = 12,
> +	.disable_ring_counter = 1,
> +	.has_reg11 = true,
> +	.vref_volatge = 1,
> +	.has_vref_select = true,
> +	.vref_select = VREF_VDDA,
> +	.cmv_select = 1,
> +};
> +
>  static const struct meson_sar_adc_param meson_sar_adc_g12a_param = {
>  	.has_bl30_integration = false,
>  	.clock_rate = 1200000,
> @@ -1286,7 +1300,7 @@ static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
>  };
>  
>  static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> -	.param = &meson_sar_adc_gxl_param,
> +	.param = &meson_sar_adc_axg_param,
>  	.name = "meson-axg-saradc",
>  };
>  



From manivannan.sadhasivam at linaro.org  Mon Dec  4 02:59:31 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Mon, 4 Dec 2023 16:29:31 +0530
Subject: [PATCH v5 2/4] PCI: layerscape: Add suspend/resume for ls1021a
In-Reply-To: <20231201161712.1645987-3-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
 <20231201161712.1645987-3-Frank.Li@nxp.com>
Message-ID: <20231204105931.GB35383@thinkpad>

On Fri, Dec 01, 2023 at 11:17:10AM -0500, Frank Li wrote:
> Add suspend/resume support for Layerscape LS1021a.
> 
> In the suspend path, PME_Turn_Off message is sent to the endpoint to
> transition the link to L2/L3_Ready state. In this SoC, there is no way to
> check if the controller has received the PME_To_Ack from the endpoint or
> not. So to be on the safer side, the driver just waits for
> PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF
> bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3
> state depending on the VAUX supply.
> 
> In the resume path, the link is brought back from L2 to L0 by doing a
> software reset.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>

One comment below. With that addressed,

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>

> ---
> 
> Notes:
>     Change from v4 to v5
>     - update comit message
>     - remove a empty line
>     - use comments
>     /* Reset the PEX wrapper to bring the link out of L2 */
>     - pci->pp.ops = pcie->drvdata->ops,
>     ls_pcie_host_ops to the "ops" member of layerscape_drvdata.
>     - don't set pcie->scfg = NULL at error path
>     
>     Change from v3 to v4
>     - update commit message.
>     - it is reset a glue logic part for PCI controller.
>     - use regmap_write_bits() to reduce code change.
>     
>     Change from v2 to v3
>     - update according to mani's feedback
>     change from v1 to v2
>     - change subject 'a' to 'A'
> 
>  drivers/pci/controller/dwc/pci-layerscape.c | 81 ++++++++++++++++++++-
>  1 file changed, 80 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> index aea89926bcc4f..8bdaae9be7d56 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -35,11 +35,19 @@
>  #define PF_MCR_PTOMR		BIT(0)
>  #define PF_MCR_EXL2S		BIT(1)
>  
> +/* LS1021A PEXn PM Write Control Register */
> +#define SCFG_PEXPMWRCR(idx)	(0x5c + (idx) * 0x64)
> +#define PMXMTTURNOFF		BIT(31)
> +#define SCFG_PEXSFTRSTCR	0x190
> +#define PEXSR(idx)		BIT(idx)
> +
>  #define PCIE_IATU_NUM		6
>  
>  struct ls_pcie_drvdata {
>  	const u32 pf_off;
> +	const struct dw_pcie_host_ops *ops;
>  	int (*exit_from_l2)(struct dw_pcie_rp *pp);
> +	bool scfg_support;
>  	bool pm_support;
>  };
>  
> @@ -47,6 +55,8 @@ struct ls_pcie {
>  	struct dw_pcie *pci;
>  	const struct ls_pcie_drvdata *drvdata;
>  	void __iomem *pf_base;
> +	struct regmap *scfg;
> +	int index;
>  	bool big_endian;
>  };
>  
> @@ -171,18 +181,70 @@ static int ls_pcie_host_init(struct dw_pcie_rp *pp)
>  	return 0;
>  }
>  
> +static void scfg_pcie_send_turnoff_msg(struct regmap *scfg, u32 reg, u32 mask)
> +{
> +	/* Send PME_Turn_Off message */
> +	regmap_write_bits(scfg, reg, mask, mask);
> +
> +	/*
> +	 * There is no specific register to check for PME_To_Ack from endpoint.
> +	 * So on the safe side, wait for PCIE_PME_TO_L2_TIMEOUT_US.
> +	 */
> +	mdelay(PCIE_PME_TO_L2_TIMEOUT_US/1000);
> +
> +	/*
> +	 * Layerscape hardware reference manual recommends clearing the PMXMTTURNOFF bit
> +	 * to complete the PME_Turn_Off handshake.
> +	 */
> +	regmap_write_bits(scfg, reg, mask, 0);
> +}
> +
> +static void ls1021a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct ls_pcie *pcie = to_ls_pcie(pci);
> +
> +	scfg_pcie_send_turnoff_msg(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), PMXMTTURNOFF);
> +}
> +
> +static int scfg_pcie_exit_from_l2(struct regmap *scfg, u32 reg, u32 mask)
> +{
> +	/* Reset the PEX wrapper to bring the link out of L2 */
> +	regmap_write_bits(scfg, reg, mask, mask);
> +	regmap_write_bits(scfg, reg, mask, 0);
> +
> +	return 0;
> +}
> +
> +static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct ls_pcie *pcie = to_ls_pcie(pci);
> +
> +	return scfg_pcie_exit_from_l2(pcie->scfg, SCFG_PEXSFTRSTCR, PEXSR(pcie->index));
> +}
> +
>  static const struct dw_pcie_host_ops ls_pcie_host_ops = {
>  	.host_init = ls_pcie_host_init,
>  	.pme_turn_off = ls_pcie_send_turnoff_msg,
>  };
>  
> +static const struct dw_pcie_host_ops ls1021a_pcie_host_ops = {
> +	.host_init = ls_pcie_host_init,
> +	.pme_turn_off = ls1021a_pcie_send_turnoff_msg,
> +};
> +
>  static const struct ls_pcie_drvdata ls1021a_drvdata = {
> -	.pm_support = false,
> +	.pm_support = true,
> +	.scfg_support = true,
> +	.ops = &ls1021a_pcie_host_ops,
> +	.exit_from_l2 = ls1021a_pcie_exit_from_l2,
>  };
>  
>  static const struct ls_pcie_drvdata layerscape_drvdata = {
>  	.pf_off = 0xc0000,
>  	.pm_support = true,
> +	.ops = &ls_pcie_host_ops;
>  	.exit_from_l2 = ls_pcie_exit_from_l2,
>  };
>  
> @@ -205,6 +267,8 @@ static int ls_pcie_probe(struct platform_device *pdev)
>  	struct dw_pcie *pci;
>  	struct ls_pcie *pcie;
>  	struct resource *dbi_base;
> +	u32 index[2];
> +	int ret;
>  
>  	pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
>  	if (!pcie)
> @@ -220,6 +284,7 @@ static int ls_pcie_probe(struct platform_device *pdev)
>  	pci->pp.ops = &ls_pcie_host_ops;

This should be removed now.

- Mani

>  
>  	pcie->pci = pci;
> +	pci->pp.ops = pcie->drvdata->ops;
>  
>  	dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
>  	pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> @@ -230,6 +295,20 @@ static int ls_pcie_probe(struct platform_device *pdev)
>  
>  	pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
>  
> +	if (pcie->drvdata->scfg_support) {
> +		pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node, "fsl,pcie-scfg");
> +		if (IS_ERR(pcie->scfg)) {
> +			dev_err(dev, "No syscfg phandle specified\n");
> +			return PTR_ERR(pcie->scfg);
> +		}
> +
> +		ret = of_property_read_u32_array(dev->of_node, "fsl,pcie-scfg", index, 2);
> +		if (ret)
> +			return ret;
> +
> +		pcie->index = index[1];
> +	}
> +
>  	if (!ls_pcie_is_bridge(pcie))
>  		return -ENODEV;
>  
> -- 
> 2.34.1
> 

-- 
????????? ????????


From christophe.leroy at csgroup.eu  Mon Dec  4 03:01:25 2023
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Mon, 4 Dec 2023 12:01:25 +0100
Subject: [PATCH v2 01/14] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <20231115133743.674690dc78041768b79fadd9@linux-foundation.org>
References: <20231115163018.1303287-1-ryan.roberts@arm.com>
 <20231115163018.1303287-2-ryan.roberts@arm.com>
 <20231115133743.674690dc78041768b79fadd9@linux-foundation.org>
Message-ID: <0d8c1623-8ab5-4d60-9989-1a7f712f40cd@csgroup.eu>



Le 15/11/2023 ? 22:37, Andrew Morton a ?crit?:
> On Wed, 15 Nov 2023 16:30:05 +0000 Ryan Roberts <ryan.roberts at arm.com> wrote:
> 
>> However, the primary motivation for this change is to reduce the number
>> of tlb maintenance operations that the arm64 backend has to perform
>> during fork
> 
> Do you have a feeling for how much performance improved due to this?
> 
> Are there other architectures which might similarly benefit?  By
> implementing ptep_set_wrprotects(), it appears.  If so, what sort of
> gains might they see?
> 

I think powerpc 8xx would benefit.

We have 16k hugepages which are implemented with 4 identical PTE which 
have the _PAGE_SPS bit set. _PAGE_SPS says it is a 16k page.

We have 512k hugepages which are implemented with 128 identical PTE 
which have _PAGE_HUGE bit set. _PAGE_HUGE tells it is a 512k page.

FWIW, PMD size is 4M and there is no 4M page size so no way to implement 
leaf PMD huge pages.

Christophe


From manivannan.sadhasivam at linaro.org  Mon Dec  4 03:02:24 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Mon, 4 Dec 2023 16:32:24 +0530
Subject: [PATCH v5 3/4] PCI: layerscape(ep): Rename pf_* as pf_lut_*
In-Reply-To: <20231201161712.1645987-4-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
 <20231201161712.1645987-4-Frank.Li@nxp.com>
Message-ID: <20231204110224.GC35383@thinkpad>

On Fri, Dec 01, 2023 at 11:17:11AM -0500, Frank Li wrote:
> 'pf' and 'lut' is just difference name in difference chips, but basic it is
> a MMIO base address plus an offset.
> 
> Rename it to avoid duplicate pf_* and lut_* in driver.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>

One comment below. With that addressed,

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>

> ---
> 
> Notes:
>     pf_lut is better than pf_* or lut* because some chip use 'pf', some chip
>     use 'lut'.
>     
>     Change from v4 to v5
>     - rename layerscape-ep code also
>     change from v1 to v4
>     - new patch at v3
> 
>  .../pci/controller/dwc/pci-layerscape-ep.c    | 16 ++++-----
>  drivers/pci/controller/dwc/pci-layerscape.c   | 36 +++++++++----------
>  2 files changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index 3d3c50ef4b6ff..2ca339f938a86 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -49,7 +49,7 @@ struct ls_pcie_ep {
>  	bool				big_endian;
>  };
>  
> -static u32 ls_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
> +static u32 ls_pcie_pf_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
>  {
>  	struct dw_pcie *pci = pcie->pci;
>  
> @@ -59,7 +59,7 @@ static u32 ls_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
>  		return ioread32(pci->dbi_base + offset);
>  }
>  
> -static void ls_lut_writel(struct ls_pcie_ep *pcie, u32 offset, u32 value)
> +static void ls_pcie_pf_lut_writel(struct ls_pcie_ep *pcie, u32 offset, u32 value)
>  {
>  	struct dw_pcie *pci = pcie->pci;
>  
> @@ -76,8 +76,8 @@ static irqreturn_t ls_pcie_ep_event_handler(int irq, void *dev_id)
>  	u32 val, cfg;
>  	u8 offset;
>  
> -	val = ls_lut_readl(pcie, PEX_PF0_PME_MES_DR);
> -	ls_lut_writel(pcie, PEX_PF0_PME_MES_DR, val);
> +	val = ls_pcie_pf_lut_readl(pcie, PEX_PF0_PME_MES_DR);
> +	ls_pcie_pf_lut_writel(pcie, PEX_PF0_PME_MES_DR, val);
>  
>  	if (!val)
>  		return IRQ_NONE;
> @@ -96,9 +96,9 @@ static irqreturn_t ls_pcie_ep_event_handler(int irq, void *dev_id)
>  		dw_pcie_writel_dbi(pci, offset + PCI_EXP_LNKCAP, pcie->lnkcap);
>  		dw_pcie_dbi_ro_wr_dis(pci);
>  
> -		cfg = ls_lut_readl(pcie, PEX_PF0_CONFIG);
> +		cfg = ls_pcie_pf_lut_readl(pcie, PEX_PF0_CONFIG);
>  		cfg |= PEX_PF0_CFG_READY;
> -		ls_lut_writel(pcie, PEX_PF0_CONFIG, cfg);
> +		ls_pcie_pf_lut_writel(pcie, PEX_PF0_CONFIG, cfg);
>  		dw_pcie_ep_linkup(&pci->ep);
>  
>  		dev_dbg(pci->dev, "Link up\n");
> @@ -130,10 +130,10 @@ static int ls_pcie_ep_interrupt_init(struct ls_pcie_ep *pcie,
>  	}
>  
>  	/* Enable interrupts */
> -	val = ls_lut_readl(pcie, PEX_PF0_PME_MES_IER);
> +	val = ls_pcie_pf_lut_readl(pcie, PEX_PF0_PME_MES_IER);
>  	val |=  PEX_PF0_PME_MES_IER_LDDIE | PEX_PF0_PME_MES_IER_HRDIE |
>  		PEX_PF0_PME_MES_IER_LUDIE;
> -	ls_lut_writel(pcie, PEX_PF0_PME_MES_IER, val);
> +	ls_pcie_pf_lut_writel(pcie, PEX_PF0_PME_MES_IER, val);
>  
>  	return 0;
>  }
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> index 8bdaae9be7d56..a9151e98fde6f 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -44,7 +44,7 @@
>  #define PCIE_IATU_NUM		6
>  
>  struct ls_pcie_drvdata {
> -	const u32 pf_off;
> +	const u32 pf_lut_off;
>  	const struct dw_pcie_host_ops *ops;
>  	int (*exit_from_l2)(struct dw_pcie_rp *pp);
>  	bool scfg_support;
> @@ -54,13 +54,13 @@ struct ls_pcie_drvdata {
>  struct ls_pcie {
>  	struct dw_pcie *pci;
>  	const struct ls_pcie_drvdata *drvdata;
> -	void __iomem *pf_base;
> +	void __iomem *pf_lut_base;
>  	struct regmap *scfg;
>  	int index;
>  	bool big_endian;
>  };
>  
> -#define ls_pcie_pf_readl_addr(addr)	ls_pcie_pf_readl(pcie, addr)
> +#define ls_pcie_pf_lut_readl_addr(addr)	ls_pcie_pf_lut_readl(pcie, addr)
>  #define to_ls_pcie(x)	dev_get_drvdata((x)->dev)
>  
>  static bool ls_pcie_is_bridge(struct ls_pcie *pcie)
> @@ -101,20 +101,20 @@ static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
>  	iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR);
>  }
>  
> -static u32 ls_pcie_pf_readl(struct ls_pcie *pcie, u32 off)
> +static u32 ls_pcie_pf_lut_readl(struct ls_pcie *pcie, u32 off)
>  {
>  	if (pcie->big_endian)
> -		return ioread32be(pcie->pf_base + off);
> +		return ioread32be(pcie->pf_lut_base + off);
>  
> -	return ioread32(pcie->pf_base + off);
> +	return ioread32(pcie->pf_lut_base + off);
>  }
>  
> -static void ls_pcie_pf_writel(struct ls_pcie *pcie, u32 off, u32 val)
> +static void ls_pcie_pf_lut_writel(struct ls_pcie *pcie, u32 off, u32 val)
>  {
>  	if (pcie->big_endian)
> -		iowrite32be(val, pcie->pf_base + off);
> +		iowrite32be(val, pcie->pf_lut_base + off);
>  	else
> -		iowrite32(val, pcie->pf_base + off);
> +		iowrite32(val, pcie->pf_lut_base + off);
>  }
>  
>  static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
> @@ -124,11 +124,11 @@ static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
>  	u32 val;
>  	int ret;
>  
> -	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_PF_MCR);
>  	val |= PF_MCR_PTOMR;
> -	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_PF_MCR, val);
>  
> -	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
> +	ret = readx_poll_timeout(ls_pcie_pf_lut_readl_addr, LS_PCIE_PF_MCR,
>  				 val, !(val & PF_MCR_PTOMR),
>  				 PCIE_PME_TO_L2_TIMEOUT_US/10,
>  				 PCIE_PME_TO_L2_TIMEOUT_US);
> @@ -147,15 +147,15 @@ static int ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
>  	 * Set PF_MCR_EXL2S bit in LS_PCIE_PF_MCR register for the link
>  	 * to exit L2 state.
>  	 */
> -	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_PF_MCR);
>  	val |= PF_MCR_EXL2S;
> -	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_PF_MCR, val);
>  
>  	/*
>  	 * L2 exit timeout of 10ms is not defined in the specifications,
>  	 * it was chosen based on empirical observations.
>  	 */
> -	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
> +	ret = readx_poll_timeout(ls_pcie_pf_lut_readl_addr, LS_PCIE_PF_MCR,
>  				 val, !(val & PF_MCR_EXL2S),
>  				 1000,
>  				 10000);
> @@ -242,9 +242,9 @@ static const struct ls_pcie_drvdata ls1021a_drvdata = {
>  };
>  
>  static const struct ls_pcie_drvdata layerscape_drvdata = {
> -	.pf_off = 0xc0000,
> +	.pf_lut_off = 0xc0000,
>  	.pm_support = true,
> -	.ops = &ls_pcie_host_ops;
> +	.ops = &ls_pcie_host_ops,

This change should be part of the previous patch.

- Mani

>  	.exit_from_l2 = ls_pcie_exit_from_l2,
>  };
>  
> @@ -293,7 +293,7 @@ static int ls_pcie_probe(struct platform_device *pdev)
>  
>  	pcie->big_endian = of_property_read_bool(dev->of_node, "big-endian");
>  
> -	pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
> +	pcie->pf_lut_base = pci->dbi_base + pcie->drvdata->pf_lut_off;
>  
>  	if (pcie->drvdata->scfg_support) {
>  		pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node, "fsl,pcie-scfg");
> -- 
> 2.34.1
> 

-- 
????????? ????????


From maz at kernel.org  Mon Dec  4 03:03:24 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 11:03:24 +0000
Subject: [PATCH v3 00/25] Permission Overlay Extension
In-Reply-To: <20231124163510.1835740-1-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
Message-ID: <86jzpub56r.wl-maz@kernel.org>

Hi Joey,

On Fri, 24 Nov 2023 16:34:45 +0000,
Joey Gouly <joey.gouly at arm.com> wrote:
> 
> Hello everyone,
> 
> This series implements the Permission Overlay Extension introduced in 2022
> VMSA enhancements [1]. It is based on v6.7-rc2.
> 
> Changes since v2[2]:
> 	# Added ptrace support and selftest
> 	# Add missing POR_EL0 initialisation in fork/clone
> 	# Rebase onto v6.7-rc2
> 	# Add r-bs
> 
> The Permission Overlay Extension allows to constrain permissions on memory
> regions. This can be used from userspace (EL0) without a system call or TLB
> invalidation.

I have given this series a few more thoughts, and came to the
conclusion that is it still incomplete on the KVM front:

* FEAT_S1POE often comes together with FEAT_S2POE. For obvious
  reasons, we cannot afford to let the guest play with S2POR_EL1, nor
  do we want to advertise FEAT_S2POE to the guest.

  You will need to add some additional FGT for this, and mask out
  FEAT_S2POE from the guest's view of the ID registers.

* letting the guest play with POE comes with some interesting strings
  attached: a guest that has started on a POE-enabled host cannot be
  migrated to one that doesn't have POE. which means that the POE
  registers should only be visible to the host userspace if enabled in
  the guest's ID registers, and thus only context-switched in these
  conditions. They should otherwise UNDEF.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


From manivannan.sadhasivam at linaro.org  Mon Dec  4 03:03:50 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Mon, 4 Dec 2023 16:33:50 +0530
Subject: [PATCH v5 4/4] PCI: layerscape: Add suspend/resume for ls1043a
In-Reply-To: <20231201161712.1645987-5-Frank.Li@nxp.com>
References: <20231201161712.1645987-1-Frank.Li@nxp.com>
 <20231201161712.1645987-5-Frank.Li@nxp.com>
Message-ID: <20231204110350.GD35383@thinkpad>

On Fri, Dec 01, 2023 at 11:17:12AM -0500, Frank Li wrote:
> Add suspend/resume support for Layerscape LS1043a.
> 
> In the suspend path, PME_Turn_Off message is sent to the endpoint to
> transition the link to L2/L3_Ready state. In this SoC, there is no way to
> check if the controller has received the PME_To_Ack from the endpoint or
> not. So to be on the safer side, the driver just waits for
> PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF
> bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3
> state depending on the VAUX supply.
> 
> In the resume path, the link is brought back from L2 to L0 by doing a
> software reset.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>

- Mani

> ---
> 
> Notes:
>     Change from v4 to v5
>     - update commit message
>     - use comments
>     /* Reset the PEX wrapper to bring the link out of L2 */
>     
>     Change from v3 to v4
>     - Call scfg_pcie_send_turnoff_msg() shared with ls1021a
>     - update commit message
>     
>     Change from v2 to v3
>     - Remove ls_pcie_lut_readl(writel) function
>     
>     Change from v1 to v2
>     - Update subject 'a' to 'A'
> 
>  drivers/pci/controller/dwc/pci-layerscape.c | 63 ++++++++++++++++++++-
>  1 file changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> index a9151e98fde6f..715365e91f8ef 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -41,6 +41,15 @@
>  #define SCFG_PEXSFTRSTCR	0x190
>  #define PEXSR(idx)		BIT(idx)
>  
> +/* LS1043A PEX PME control register */
> +#define SCFG_PEXPMECR		0x144
> +#define PEXPME(idx)		BIT(31 - (idx) * 4)
> +
> +/* LS1043A PEX LUT debug register */
> +#define LS_PCIE_LDBG	0x7fc
> +#define LDBG_SR		BIT(30)
> +#define LDBG_WE		BIT(31)
> +
>  #define PCIE_IATU_NUM		6
>  
>  struct ls_pcie_drvdata {
> @@ -224,6 +233,45 @@ static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
>  	return scfg_pcie_exit_from_l2(pcie->scfg, SCFG_PEXSFTRSTCR, PEXSR(pcie->index));
>  }
>  
> +static void ls1043a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct ls_pcie *pcie = to_ls_pcie(pci);
> +
> +	scfg_pcie_send_turnoff_msg(pcie->scfg, SCFG_PEXPMECR, PEXPME(pcie->index));
> +}
> +
> +static int ls1043a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct ls_pcie *pcie = to_ls_pcie(pci);
> +	u32 val;
> +
> +	/*
> +	 * Reset the PEX wrapper to bring the link out of L2.
> +	 * LDBG_WE: allows the user to have write access to the PEXDBG[SR] for both setting and
> +	 *	    clearing the soft reset on the PEX module.
> +	 * LDBG_SR: When SR is set to 1, the PEX module enters soft reset.
> +	 */
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
> +	val |= LDBG_WE;
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
> +
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
> +	val |= LDBG_SR;
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
> +
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
> +	val &= ~LDBG_SR;
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
> +
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
> +	val &= ~LDBG_WE;
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
> +
> +	return 0;
> +}
> +
>  static const struct dw_pcie_host_ops ls_pcie_host_ops = {
>  	.host_init = ls_pcie_host_init,
>  	.pme_turn_off = ls_pcie_send_turnoff_msg,
> @@ -241,6 +289,19 @@ static const struct ls_pcie_drvdata ls1021a_drvdata = {
>  	.exit_from_l2 = ls1021a_pcie_exit_from_l2,
>  };
>  
> +static const struct dw_pcie_host_ops ls1043a_pcie_host_ops = {
> +	.host_init = ls_pcie_host_init,
> +	.pme_turn_off = ls1043a_pcie_send_turnoff_msg,
> +};
> +
> +static const struct ls_pcie_drvdata ls1043a_drvdata = {
> +	.pf_lut_off = 0x10000,
> +	.pm_support = true,
> +	.scfg_support = true,
> +	.ops = &ls1043a_pcie_host_ops,
> +	.exit_from_l2 = ls1043a_pcie_exit_from_l2,
> +};
> +
>  static const struct ls_pcie_drvdata layerscape_drvdata = {
>  	.pf_lut_off = 0xc0000,
>  	.pm_support = true,
> @@ -252,7 +313,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
>  	{ .compatible = "fsl,ls1012a-pcie", .data = &layerscape_drvdata },
>  	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021a_drvdata },
>  	{ .compatible = "fsl,ls1028a-pcie", .data = &layerscape_drvdata },
> -	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1021a_drvdata },
> +	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043a_drvdata },
>  	{ .compatible = "fsl,ls1046a-pcie", .data = &layerscape_drvdata },
>  	{ .compatible = "fsl,ls2080a-pcie", .data = &layerscape_drvdata },
>  	{ .compatible = "fsl,ls2085a-pcie", .data = &layerscape_drvdata },
> -- 
> 2.34.1
> 

-- 
????????? ????????


From o.rempel at pengutronix.de  Mon Dec  4 03:04:41 2023
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Mon, 4 Dec 2023 12:04:41 +0100
Subject: [PATCH 1/1] i2c: imx: Make SDA actually optional for bus
 recovering
In-Reply-To: <20231130095751.65773-1-alexander.stein@ew.tq-group.com>
References: <20231130095751.65773-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231204110441.GA981228@pengutronix.de>

On Thu, Nov 30, 2023 at 10:57:51AM +0100, Alexander Stein wrote:
> Both i2c_generic_scl_recovery() and the debug output indicate that SDA is
> purely optional for bus recovery. But devm_gpiod_get() never returns NULL
> making it mandatory. Fix this my calling devm_gpiod_get_optional instead.
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

Reviewed-by: Oleksij Rempel <o.rempel at pengutronix.de>
Acked-by: Oleksij Rempel <o.rempel at pengutronix.de>

> ---
>  drivers/i2c/busses/i2c-imx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 1775a79aeba2a..88a053987403c 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1401,7 +1401,7 @@ static int i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
>  			PINCTRL_STATE_DEFAULT);
>  	i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
>  			"gpio");
> -	rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
> +	rinfo->sda_gpiod = devm_gpiod_get_optional(&pdev->dev, "sda", GPIOD_IN);
>  	rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
>  
>  	if (PTR_ERR(rinfo->sda_gpiod) == -EPROBE_DEFER ||
> -- 
> 2.34.1
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From hejunhao3 at huawei.com  Mon Dec  4 03:04:25 2023
From: hejunhao3 at huawei.com (Junhao He)
Date: Mon, 4 Dec 2023 19:04:25 +0800
Subject: [PATCH] drivers/perf: hisi: Fix some event id for HiSilicon UC pmu
Message-ID: <20231204110425.20354-1-hejunhao3@huawei.com>

Some event id of HiSilicon uncore UC PMU driver is incorrect, fix them.

Fixes: 312eca95e28d ("drivers/perf: hisi: Add support for HiSilicon UC PMU driver")
Signed-off-by: Junhao He <hejunhao3 at huawei.com>
---
 drivers/perf/hisilicon/hisi_uncore_uc_pmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/perf/hisilicon/hisi_uncore_uc_pmu.c b/drivers/perf/hisilicon/hisi_uncore_uc_pmu.c
index 63da05e5831c..636fb79647c8 100644
--- a/drivers/perf/hisilicon/hisi_uncore_uc_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_uc_pmu.c
@@ -383,8 +383,8 @@ static struct attribute *hisi_uc_pmu_events_attr[] = {
 	HISI_PMU_EVENT_ATTR(cpu_rd,		0x10),
 	HISI_PMU_EVENT_ATTR(cpu_rd64,		0x17),
 	HISI_PMU_EVENT_ATTR(cpu_rs64,		0x19),
-	HISI_PMU_EVENT_ATTR(cpu_mru,		0x1a),
-	HISI_PMU_EVENT_ATTR(cycles,		0x9c),
+	HISI_PMU_EVENT_ATTR(cpu_mru,		0x1c),
+	HISI_PMU_EVENT_ATTR(cycles,		0x95),
 	HISI_PMU_EVENT_ATTR(spipe_hit,		0xb3),
 	HISI_PMU_EVENT_ATTR(hpipe_hit,		0xdb),
 	HISI_PMU_EVENT_ATTR(cring_rxdat_cnt,	0xfa),
-- 
2.33.0



From ajones at ventanamicro.com  Mon Dec  4 03:32:24 2023
From: ajones at ventanamicro.com (Andrew Jones)
Date: Mon, 4 Dec 2023 12:32:24 +0100
Subject: [PATCH v3 9/9] KVM: riscv: selftests: Add sstc timer test
In-Reply-To: <CAJve8omitHDpijJaLV_wHk+5LXpsBUWF8_eTD4MeWKM-807Siw@mail.gmail.com>
References: <cover.1694421911.git.haibo1.xu@intel.com>
 <64e0637cd6f22dd7557ed44bd2242001e7830d1c.1694421911.git.haibo1.xu@intel.com>
 <20230914-d2e594e7d84503ad14036e2d@orel>
 <CAJve8onhY534T=Hyncjfi4GfdZ+0D2xM+jRSaYCAWCdaKxPUcQ@mail.gmail.com>
 <CAJve8omitHDpijJaLV_wHk+5LXpsBUWF8_eTD4MeWKM-807Siw@mail.gmail.com>
Message-ID: <20231204-980c95cca344f718ac6a48b6@orel>

On Mon, Dec 04, 2023 at 10:42:24AM +0800, Haibo Xu wrote:
> On Fri, Sep 15, 2023 at 2:21?PM Haibo Xu <xiaobo55x at gmail.com> wrote:
> >
> > On Thu, Sep 14, 2023 at 5:52?PM Andrew Jones <ajones at ventanamicro.com> wrote:
> > >
> > > On Thu, Sep 14, 2023 at 09:37:03AM +0800, Haibo Xu wrote:
> > > > Add a KVM selftests to validate the Sstc timer functionality.
> > > > The test was ported from arm64 arch timer test.
> > >
> > > I just tried this test out. Running it over and over again on QEMU I see
> > > it works sometimes, but it frequently fails with the
> > > GUEST_ASSERT_EQ(config_iter + 1, irq_iter) assert and at least once I
> > > also saw the __GUEST_ASSERT(xcnt >= cmp) assert.
> > >
> >
> > Good catch!
> >
> > I can also reproduce this issue and it is a common problem for both
> > arm64 and riscv because it also happens in a arm64 Qemu VM.
> >
> > It seems like a synchronization issue between host and guest shared
> > variables. Will double check the test code.
> >
> > > Thanks,
> > > drew
> 
> Hi Andrew,
> 
> After several rounds of regression testing, some findings:
> 1. The intermittent failure also happened on ARM64 Qemu VM, and even
> in the initial arch_timer commit(4959d8650e9f4).
> 2. it didn't happen on a ARM64 HW(but a different failure occured
> during stress test)
> 3. The failure have a close relationship with
> TIMER_TEST_ERR_MARGIN_US(default 100), and after increasing
>      the macro to 300, the failure couldn't reproduced in 1000 loops
> stress test in RISC-V Qemu VM
> 
> So my suggestion is we can expose the TIMER_TEST_ERR_MARGIN_US
> parameter as an arch_timer test arg parameter
> and tune it based on a specific test environment.
> 
> What's your opinion?

The concept of "timeout for an interrupt to arrive" is always going to
leave us exposed to random failures. Your suggestion of making the
timeout user configurable is probably the best we can do. I would
suggest also adding more descriptive failure text and a hint about
trying to adjust the timeout.

Or, one thing we do in kvm-unit-tests, is to reduce typical delays while
allowing expected delays to be longer by looping over a shorter delay and
a non-fatal check, i.e.

 pass = false;
 for (i = 0; i < 10; i++) {
   udelay(100);
   if (check(...)) {
      pass = true;
      break;
   }
 }
 assert(pass);

We could try that approach here too.

Thanks,
drew


From heiko at sntech.de  Mon Dec  4 03:36:43 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 04 Dec 2023 12:36:43 +0100
Subject: [PATCH v3 3/8] i2c: rk3x: Adjust mask/value offset for i2c2 on rv1126
In-Reply-To: <20231203215530.mewjd7n7ltaeed3w@zenone.zhora.eu>
References: <20231203124004.2676174-1-tim@feathertop.org> <4413905.22IY78Rhhi@diego>
 <20231203215530.mewjd7n7ltaeed3w@zenone.zhora.eu>
Message-ID: <4850448.MsWZr2WtbB@diego>

Am Sonntag, 3. Dezember 2023, 22:55:30 CET schrieb Andi Shyti:
> Hi,
> 
> On Sun, Dec 03, 2023 at 08:48:43PM +0100, Heiko St?bner wrote:
> > Hi Andi,
> > 
> > Am Sonntag, 3. Dezember 2023, 20:06:20 CET schrieb Andi Shyti:
> > > Hi Tim,
> > > 
> > > On Sun, Dec 03, 2023 at 11:39:59PM +1100, Tim Lunn wrote:
> > > > Rockchip RV1126 is using old style i2c controller, the i2c2
> > > > bus uses a non-sequential offset in the grf register for the
> > > > mask/value bits for this bus.
> > > > 
> > > > This patch fixes i2c2 bus on rv1126 SoCs.
> > > > 
> > > > Signed-off-by: Tim Lunn <tim at feathertop.org>
> > > > Acked-by: Heiko Stuebner <heiko at sntech.de>
> > > 
> > > Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
> > 
> > you're listed as the maintainer for the i2c busses,
> > are you going to pick this one patch yourself?
> > Or do you expect a different handling?
> > 
> > I.e. it doesn't really tie into the dts patches and everything will come
> > together nicely in linux-next and during the next merge-window.
> 
> Wolfram are you going to take this?

I was going by get_maintainer.pl showing
Andi Shyti <andi.shyti at kernel.org> (maintainer:I2C SUBSYSTEM HOST DRIVERS)

hence the question :-)




From anshuman.khandual at arm.com  Mon Dec  4 03:37:30 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 4 Dec 2023 17:07:30 +0530
Subject: [PATCH V2 1/7] coresight: replicator: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <2aec13e9-4ae3-676f-1ba8-c9e9a9241063@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-2-anshuman.khandual@arm.com>
 <20231201123515.gntwvhsxd5nzojn7@bogus>
 <58882cab-89ce-4554-aee4-24e70d82fc09@arm.com>
 <b9f407c7-62af-47e1-bea9-c494cdfed1e9@arm.com>
 <2aec13e9-4ae3-676f-1ba8-c9e9a9241063@arm.com>
Message-ID: <dbcd6fa5-1385-41d7-905e-d77b536c5d33@arm.com>



On 12/4/23 15:27, James Clark wrote:
> 
> On 04/12/2023 04:48, Anshuman Khandual wrote:
>>
>> On 12/4/23 09:56, Anshuman Khandual wrote:
>>>
>>> On 12/1/23 18:05, Sudeep Holla wrote:
>>>> On Fri, Dec 01, 2023 at 11:50:47AM +0530, Anshuman Khandual wrote:
>>>>> Add support for the dynamic replicator device in the platform driver, which
>>>>> can then be used on ACPI based platforms. This change would now allow
>>>>> runtime power management for repliacator devices on ACPI based systems.
>>>>>
>>>>> The driver would try to enable the APB clock if available. Also, rename the
>>>>> code to reflect the fact that it now handles both static and dynamic
>>>>> replicators.
>>>>>
>>>>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>>>>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>>>> Except the minor nit below which may apply also for few other patches
>>>> in the series
>>>>
>>>> Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
>>>> Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
>>>>> index b6be73034996..64de0bee02ec 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-replicator.c
>>>>> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
>>>>> @@ -38,6 +38,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>>>>>  struct replicator_drvdata {
>>>>>  	void __iomem		*base;
>>>>>  	struct clk		*atclk;
>>>>> +	struct clk		*pclk;
>>>> [minor nit] Perhaps can be documented as well ?
>>> Sure, will add the following comment above the structure.
>>>
>>> @pclk:    optional clock for the core parts of the replicator.
>> My bad, this will be the following instead.
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
>> index 64de0bee02ec..44b9a77ec8aa 100644
>> --- a/drivers/hwtracing/coresight/coresight-replicator.c
>> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
>> @@ -31,6 +31,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>>   * @base:      memory mapped base address for this component. Also indicates
>>   *             whether this one is programmable or not.
>>   * @atclk:     optional clock for the core parts of the replicator.
>> + * @pclk:      APB clock if present, otherwise NULL
>>   * @csdev:     component vitals needed by the framework
>>   * @spinlock:  serialize enable/disable operations.
>>   * @check_idfilter_val: check if the context is lost upon clock removal.
>>
>> I will update replicator, tpiu, tmc, and stm devices.
>>
> funnel is missing it as well. If you build with W=1 it shows up.

Updated, done.


From m.szyprowski at samsung.com  Mon Dec  4 03:40:38 2023
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Mon, 4 Dec 2023 12:40:38 +0100
Subject: [PATCH v4 12/23] pinctrl: mediatek: Make use of
 PINCTRL_GROUP_DESC()
In-Reply-To: <20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
	<20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
	<CGME20231204114039eucas1p29c6f8a162191e58ff658d3a1c44429bf@eucas1p2.samsung.com>
Message-ID: <9e4e65de-7234-4234-8091-796277a1f1c5@samsung.com>

On 29.11.2023 17:06, Andy Shevchenko wrote:
> Make use of PINCTRL_GROUP_DESC() instead of open coding it.
>
> Signed-off-by: Andy Shevchenko<andriy.shevchenko at linux.intel.com>

This patch landed in linux-next as commit 1949e4630c3b ("pinctrl: 
mediatek: Make use of PINCTRL_GROUP_DESC()"). Unfortunately it causes a 
build break of ARM64 arch with standard defconfig.

> ---
>   drivers/pinctrl/mediatek/pinctrl-moore.h | 7 +------
>   drivers/pinctrl/mediatek/pinctrl-paris.h | 7 +------
>   2 files changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.h b/drivers/pinctrl/mediatek/pinctrl-moore.h
> index e1b4b82b9d3d..22ef1ffbcdcb 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-moore.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-moore.h
> @@ -38,12 +38,7 @@
>   	}
>   
>   #define PINCTRL_PIN_GROUP(name, id)			\
> -	{						\
> -		name,					\
> -		id##_pins,				\
> -		ARRAY_SIZE(id##_pins),			\
> -		id##_funcs,				\
> -	}
> +	PINCTRL_GROUP_DESC(name, id##_pins, ARRAY_SIZE(id##_pins), id##_funcs)
>   int mtk_moore_pinctrl_probe(struct platform_device *pdev,
>   			    const struct mtk_pin_soc *soc);
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.h b/drivers/pinctrl/mediatek/pinctrl-paris.h
> index 8762ac599329..f208a904c4a8 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.h
> @@ -50,12 +50,7 @@
>   	}
>   
>   #define PINCTRL_PIN_GROUP(name, id)			\
> -	{						\
> -		name,					\
> -		id##_pins,				\
> -		ARRAY_SIZE(id##_pins),			\
> -		id##_funcs,				\
> -	}
> +	PINCTRL_GROUP_DESC(name, id##_pins, ARRAY_SIZE(id##_pins), id##_funcs)
>   
>   int mtk_paris_pinctrl_probe(struct platform_device *pdev);


PINCTRL_GROUP_DESC() macro from drivers/pinctrl/core.h contains a cast 
to (struct group_desc), what breaks users of the above macros.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From sudeep.holla at arm.com  Mon Dec  4 03:40:43 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon, 4 Dec 2023 11:40:43 +0000
Subject: [PATCH V2 5/7] coresight: tmc: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <fe5c82d1-8b7d-6701-4e19-9019f23d9c7b@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-6-anshuman.khandual@arm.com>
 <fe5c82d1-8b7d-6701-4e19-9019f23d9c7b@arm.com>
Message-ID: <ZW26u_2pHz9bNoTx@bogus>

On Mon, Dec 04, 2023 at 10:54:15AM +0000, James Clark wrote:
>
>
> On 01/12/2023 06:20, Anshuman Khandual wrote:
> > Add support for the tmc devices in the platform driver, which can then be
> > used on ACPI based platforms. This change would now allow runtime power
> > management for ACPI based systems. The driver would try to enable the APB
> > clock if available.
> >
> [...]
> > -module_amba_driver(tmc_driver);
> > +static int tmc_platform_probe(struct platform_device *pdev)
> > +{
> > +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	struct tmc_drvdata *drvdata;
> > +	int ret = 0;
> > +
> > +	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
> > +	if (!drvdata)
> > +		return -ENOMEM;
> > +
> > +	drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
> > +	if (IS_ERR(drvdata->pclk))
> > +		return -ENODEV;
> > +
> > +	dev_set_drvdata(&pdev->dev, drvdata);
> > +	pm_runtime_get_noresume(&pdev->dev);
> > +	pm_runtime_set_active(&pdev->dev);
> > +	pm_runtime_enable(&pdev->dev);
> > +
> > +	ret = __tmc_probe(&pdev->dev, res, NULL);
> > +	if (ret) {
> > +		pm_runtime_put_noidle(&pdev->dev);
> > +		pm_runtime_disable(&pdev->dev);
> > +	}
>
> I'm not sure if these pm_runtime()s are right because there is already a
> put inside of __tmc_probe() if it fails. If you unload and then reload
> all the coresight modules with these patches you get these errors which
> are new:
>

Ah good find. I have just tested with ACPI and these modules as built-in
to be more specific.

--
Regards,
Sudeep


From angelogioacchino.delregno at collabora.com  Mon Dec  4 03:43:25 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 12:43:25 +0100
Subject: [PATCH v3] mmc: mtk-sd: Increase the verbosity of
 msdc_track_cmd_data
In-Reply-To: <20231201102747.3854573-1-treapking@chromium.org>
References: <20231201102747.3854573-1-treapking@chromium.org>
Message-ID: <73a0847d-09e0-4587-bd76-164b2b4d8aa7@collabora.com>

Il 01/12/23 11:26, Pin-yen Lin ha scritto:
> This log message is necessary for debugging, so enable it by default to
> debug issues that are hard to reproduce locally.
> 
> Signed-off-by: Pin-yen Lin <treapking at chromium.org>
> 

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From anshuman.khandual at arm.com  Mon Dec  4 03:50:49 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 4 Dec 2023 17:20:49 +0530
Subject: [PATCH V2 6/7] coresight: stm: Move ACPI support from AMBA driver
 to platform driver
In-Reply-To: <0adc3a16-0fc4-2a25-cd48-4667881b9490@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-7-anshuman.khandual@arm.com>
 <0adc3a16-0fc4-2a25-cd48-4667881b9490@arm.com>
Message-ID: <e53cec31-9452-4c2a-a3a1-b6ef33be8e22@arm.com>



On 12/4/23 15:53, James Clark wrote:
> 
> 
> On 01/12/2023 06:20, Anshuman Khandual wrote:
>> Add support for the stm devices in the platform driver, which can then be
>> used on ACPI based platforms. This change would now allow runtime power
>> management for ACPI based systems. The driver would try to enable the APB
>> clock if available.
>>
>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Cc: Mike Leach <mike.leach at linaro.org>
>> Cc: James Clark <james.clark at arm.com>
>> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
>> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
>> Cc: linux-acpi at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: coresight at lists.linaro.org
>> Cc: linux-stm32 at st-md-mailman.stormreply.com
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
> [...]
>>  
>> -module_amba_driver(stm_driver);
>> +static int stm_platform_probe(struct platform_device *pdev)
>> +{
>> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +	int ret = 0;
>> +
>> +	pm_runtime_get_noresume(&pdev->dev);
>> +	pm_runtime_set_active(&pdev->dev);
>> +	pm_runtime_enable(&pdev->dev);
>> +
>> +	ret = __stm_probe(&pdev->dev, res, NULL);
> 
> Very minor nit, but this used to print this:
> 
>   coresight stm0: STM500 initialized
> 
> And now it prints this:
> 
>   coresight stm0: (null) initialized
> 
> (null) kind of makes it look a little bit like something has gone wrong.
> Maybe we could just put "initialised" if you don't have a string from ACPI?

__stm_probe() gets called from both AMBA and platform driver paths. Even though
a NULL check inside dev_info(..."%s initialized\n",...) could be added, but how
to differentiate it from a scenario when coresight_get_uci_data() returns NULL ?


From u.kleine-koenig at pengutronix.de  Mon Dec  4 03:51:30 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 4 Dec 2023 12:51:30 +0100
Subject: [PATCH v2] pwm: atmel: add missing clk_disable_unprepare()
In-Reply-To: <f08d820b-cef3-bc9d-69ce-fc6d3f65a550@microchip.com>
References: <20230902063232.22620-1-Hari.PrasathGE@microchip.com>
 <f15da804-206b-be53-b59e-06a3edfa0e96@wanadoo.fr>
 <f08d820b-cef3-bc9d-69ce-fc6d3f65a550@microchip.com>
Message-ID: <20231204115130.d46fuficobdfs4yn@pengutronix.de>

Hello Hari,

On Wed, Sep 06, 2023 at 06:15:36AM +0000, Hari.PrasathGE at microchip.com wrote:
> Thank you, I admit that I have messes up this part. Its been quite a 
> while sending patches upstream and I seem to have forgotten the basics. 
> I will take time to send the v3 paying more attention to these small 
> details.

You never followed up with the promised v3. Is this still on your radar?
Would be great to get this addressed as it fixes a clk imbalance, right?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/05aa17a7/attachment.sig>

From florian.bezdeka at siemens.com  Mon Dec  4 03:54:56 2023
From: florian.bezdeka at siemens.com (Florian Bezdeka)
Date: Mon, 04 Dec 2023 12:54:56 +0100
Subject: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC
In-Reply-To: <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
	 <20231203165129.1740512-3-yoong.siang.song@intel.com>
	 <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
Message-ID: <8602c88c98fd722db8e164a1520c56aebfa64db7.camel@siemens.com>

On Mon, 2023-12-04 at 11:36 +0100, Jesper Dangaard Brouer wrote:
> On 12/3/23 17:51, Song Yoong Siang wrote:
> > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > copy via XDP Tx metadata framework.
> > 
> > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > ---
> >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> 
> As requested before, I think we need to see another driver implementing 
> this.
> 
> I propose driver igc and chip i225.

igc support would be really nice and highly appreciated. There are a
lot of tests running here with that chip (i225/i226) / driver (igc)
combination. Let me know if we can support somehow, testing included.

> 
> The interesting thing for me is to see how the LaunchTime max 1 second
> into the future[1] is handled code wise. One suggestion is to add a 
> section to Documentation/networking/xsk-tx-metadata.rst per driver that 
> mentions/documents these different hardware limitations.  It is natural 
> that different types of hardware have limitations.  This is a close-to 
> hardware-level abstraction/API, and IMHO as long as we document the 
> limitations we can expose this API without too many limitations for more 
> capable hardware.
> 
>   [1] 
> https://github.com/xdp-project/xdp-project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org#setup-code-driver-igb
> 
> This stmmac driver and Intel Tiger Lake CPU must also have some limit on 
> how long into the future it will/can schedule packets?
> 
> 
> People from xdp-hints list must make their voice hear if they want i210 
> and igb driver support, because it have even-more hardware limitations, 
> see [1] (E.g. only TX queue 0 and 1 supports LaunchTime). BUT I know 
> some have this hardware in production and might be motivated to get a 
> functioning driver with this feature?

i210 support would be nice, that would allow us to compare some test
setups with different NICs. In addition it would simplify some test
setups. For now, IMHO igc is more important.

> 
> --Jesper



From eugen.hristev at collabora.com  Mon Dec  4 03:55:06 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Mon, 4 Dec 2023 13:55:06 +0200
Subject: [PATCH v3 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <20231204084012.2281292-7-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-7-wenst@chromium.org>
Message-ID: <4a7c0cd5-d705-4369-90dd-92d6a27c4723@collabora.com>

Hello Chen-Yu,

On 12/4/23 10:40, Chen-Yu Tsai wrote:
> Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> Krabby design.
> 
> Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> convertible device with touchscreen and stylus.
> 
> Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> device. It does not have a touchscreen or stylus.
> 
> The two devices both have two variants. The difference is a second
> source touchpad controller that shares the same address as the original,
> but is incompatible.
> 
> The extra SKU IDs for the Tentacruel devices map to different sensor
> components attached to the Embedded Controller. These are not visible
> to the main processor.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>
> ---
> Changes since v2:
> - Picked up Conor's ack
> - Rename touchpad to trackpad
> - Drop pinctrl properties from trackpad in tentacruel/tentacool second
>   source trackpad
> 
> Changes since v1:
> - Reorder SKU numbers in descending order.
> - Fixed pinconfig node names
> - Moved pinctrl-* properties after interrupts-*
> - Switched to interrupts-extended for external components
> - Marked ADSP as explicitly disabled, with a comment explaining that it
>   stalls the system
> - Renamed "touchpad" to "trackpad"
> - Dropped bogus "no-laneswap" property from it6505 node
> - Moved "realtek,jd-src" property to after all the regulator supplies
> - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> - Renamed "vgpu" regulator name to allow coupling, with a comment
>   containing the name used in the design
> - Renamed "cr50" node name to "tpm"
> - Moved trackpad_pins reference up to i2c2; workaround for second source
>   component resource sharing.
> - Fix copyright year
> - Fixed touchscreen supply name
> 
>  arch/arm64/boot/dts/mediatek/Makefile         |    4 +
>  .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
>  .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
>  .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
>  .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
>  .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
>  .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
>  7 files changed, 2003 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> 
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index e6e7592a3645..442af61b1305 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> new file mode 100644
> index 000000000000..9b2b64525961
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> @@ -0,0 +1,129 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +	aliases {
> +		i2c4 = &i2c4;
> +	};
> +};
> +
> +&dsi_out {
> +	remote-endpoint = <&ps8640_in>;
> +};
> +
> +&i2c0 {
> +	clock-frequency = <400000>;
> +
> +	ps8640: edp-bridge at 8 {
> +		compatible = "parade,ps8640";
> +		reg = <0x8>;
> +		powerdown-gpios = <&pio 96 GPIO_ACTIVE_LOW>;
> +		reset-gpios = <&pio 98 GPIO_ACTIVE_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&ps8640_pins>;
> +		vdd12-supply = <&mt6366_vrf12_reg>;
> +		vdd33-supply = <&mt6366_vcn33_reg>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +
> +				ps8640_in: endpoint {
> +					remote-endpoint = <&dsi_out>;
> +				};
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +
> +				ps8640_out: endpoint {
> +					remote-endpoint = <&panel_in>;
> +				};
> +			};
> +		};
> +
> +		aux-bus {
> +			panel {
> +				compatible = "edp-panel";
> +				power-supply = <&pp3300_disp_x>;
> +				backlight = <&backlight_lcd0>;
> +
> +				port {
> +					panel_in: endpoint {
> +						remote-endpoint = <&ps8640_out>;
> +					};
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&i2c1 {
> +	i2c-scl-internal-delay-ns = <10000>;
> +
> +	touchscreen: touchscreen at 10 {
> +		compatible = "hid-over-i2c";
> +		reg = <0x10>;
> +		interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&touchscreen_pins>;
> +		post-power-on-delay-ms = <10>;
> +		hid-descr-addr = <0x0001>;
> +		vdd-supply = <&pp3300_s3>;
> +	};
> +};
> +
> +&i2c4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c4_pins>;
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	proximity at 28 {
> +		compatible = "semtech,sx9324";
> +		reg = <0x28>;
> +		interrupts-extended = <&pio 5 IRQ_TYPE_LEVEL_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&sar_sensor_pins>;
> +		vdd-supply = <&mt6366_vio18_reg>;
> +		svdd-supply = <&mt6366_vio18_reg>;
> +		#io-channel-cells = <1>;
> +	};
> +};
> +
> +&pio {
> +	i2c4_pins: i2c4-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO136__FUNC_SDA4>,
> +				 <PINMUX_GPIO135__FUNC_SCL4>;
> +			bias-disable;
> +			drive-strength = <4>;
> +			input-enable;
> +		};
> +	};
> +
> +	ps8640_pins: ps8640-pins {
> +		pins-pwrdn-rst {
> +			pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
> +				 <PINMUX_GPIO98__FUNC_GPIO98>;
> +			output-low;
> +		};
> +	};
> +
> +	sar_sensor_pins: sar-sensor-pins {
> +		pins-irq {
> +			pinmux = <PINMUX_GPIO5__FUNC_GPIO5>;
> +			input-enable;
> +			bias-pull-up;
> +		};
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> new file mode 100644
> index 000000000000..9bb64353ca65
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> @@ -0,0 +1,57 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola-krabby.dtsi"
> +
> +/ {
> +	model = "Google Tentacool board";
> +	compatible = "google,tentacruel-sku327681", "google,tentacruel", "mediatek,mt8186";
> +	chassis-type = "laptop";
> +};
> +
> +/* Tentacool omits the pen. */
> +&gpio_keys {
> +	status = "disabled";
> +};
> +
> +/* Tentacool omits the touchscreen; nothing else is on i2c1. */
> +&i2c1 {
> +	status = "disabled";
> +};
> +
> +&keyboard_controller {
> +	function-row-physmap = <
> +		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
> +		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
> +		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
> +		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
> +		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
> +		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
> +		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
> +		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
> +		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
> +		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
> +	>;
> +
> +	linux,keymap = <
> +		MATRIX_KEY(0x00, 0x02, KEY_BACK)
> +		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> +		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> +		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> +		MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> +		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> +		MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> +		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> +		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> +		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> +		CROS_STD_MAIN_KEYMAP
> +	>;
> +};
> +
> +/* Tentacool omits the touchscreen. */
> +&touchscreen {
> +	status = "disabled";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> new file mode 100644
> index 000000000000..c3ae6f9616c8
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2023 Google LLC
> + */
> +
> +#include "mt8186-corsola-tentacool-sku327681.dts"
> +
> +/ {
> +	compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
> +};
> +
> +/* This variant replaces only the trackpad controller. */
> +&i2c2 {
> +	/delete-node/ trackpad at 15;
> +
> +	trackpad at 15 {
> +		compatible = "hid-over-i2c";
> +		reg = <0x15>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		hid-descr-addr = <0x0001>;
> +		vdd-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> new file mode 100644
> index 000000000000..26d3451a5e47
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> @@ -0,0 +1,44 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola-krabby.dtsi"
> +
> +/ {
> +	model = "Google Tentacruel board";
> +	compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
> +		     "google,tentacruel-sku262145", "google,tentacruel-sku262144",
> +		     "google,tentacruel", "mediatek,mt8186";
> +	chassis-type = "convertible";
> +};
> +
> +&keyboard_controller {
> +	function-row-physmap = <
> +		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
> +		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
> +		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
> +		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
> +		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
> +		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
> +		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
> +		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
> +		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
> +		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
> +	>;
> +
> +	linux,keymap = <
> +		MATRIX_KEY(0x00, 0x02, KEY_BACK)
> +		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> +		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> +		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> +		MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> +		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> +		MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> +		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> +		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> +		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> +		CROS_STD_MAIN_KEYMAP
> +	>;
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> new file mode 100644
> index 000000000000..447b57b12b41
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2023 Google LLC
> + */
> +
> +#include "mt8186-corsola-tentacruel-sku262144.dts"
> +
> +/ {
> +	compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> +		     "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> +		     "google,tentacruel", "mediatek,mt8186";
> +};
> +
> +/* This variant replaces only the trackpad controller. */
> +&i2c2 {
> +	/delete-node/ trackpad at 15;
> +
> +	trackpad at 15 {
> +		compatible = "hid-over-i2c";
> +		reg = <0x15>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		hid-descr-addr = <0x0001>;
> +		vdd-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> new file mode 100644
> index 000000000000..8726b2916ef1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> @@ -0,0 +1,1719 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (C) 2022 MediaTek Inc.
> + */
> +/dts-v1/;
> +#include "mt8186.dtsi"
> +#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/input/gpio-keys.h>
> +#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
> +
> +/ {
> +	aliases {
> +		i2c0 = &i2c0;
> +		i2c1 = &i2c1;
> +		i2c2 = &i2c2;
> +		i2c3 = &i2c3;
> +		i2c5 = &i2c5;
> +		mmc0 = &mmc0;
> +		mmc1 = &mmc1;
> +		serial0 = &uart0;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	memory at 40000000 {
> +		device_type = "memory";
> +		/* The size should be filled in by the bootloader. */
> +		reg = <0 0x40000000 0 0>;
> +	};
> +
> +	backlight_lcd0: backlight-lcd0 {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm0 0 500000>;
> +		power-supply = <&ppvar_sys>;
> +		enable-gpios = <&pio 152 0>;
> +		brightness-levels = <0 1023>;
> +		num-interpolated-steps = <1023>;
> +		default-brightness-level = <576>;
> +	};
> +
> +	btsco: bt-sco {
> +		compatible = "linux,bt-sco";
> +		#sound-dai-cells = <0>;
> +	};
> +
> +	dmic_codec: dmic-codec {
> +		compatible = "dmic-codec";
> +		num-channels = <2>;
> +		wakeup-delay-ms = <50>;
> +		#sound-dai-cells = <0>;
> +	};
> +
> +	gpio_keys: gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pen_eject>;
> +
> +		pen_insert: pen-insert-switch {
> +			label = "Pen Insert";
> +			/* Insert = low, eject = high */
> +			gpios = <&pio 18 GPIO_ACTIVE_LOW>;
> +			linux,code = <SW_PEN_INSERTED>;
> +			linux,input-type = <EV_SW>;
> +			wakeup-event-action = <EV_ACT_DEASSERTED>;
> +			wakeup-source;
> +		};
> +	};
> +
> +	pp1800_dpbrdg_dx: regulator-pp1800-dpbrdg-dx {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&en_pp1800_dpbrdg>;
> +		regulator-name = "pp1800_dpbrdg_dx";
> +		enable-active-high;
> +		gpio = <&pio 39 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&mt6366_vio18_reg>;
> +	};
> +
> +	pp3300_disp_x: regulator-pp3300-disp-x {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp3300_disp_x";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&edp_panel_fixed_pins>;
> +		enable-active-high;
> +		regulator-boot-on;
> +		gpio = <&pio 153 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&pp3300_z2>;
> +	};
> +
> +	/* system wide LDO 3.3V power rail */
> +	pp3300_z5: regulator-pp3300-ldo-z5 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp3300_ldo_z5";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&ppvar_sys>;
> +	};
> +
> +	/* separately switched 3.3V power rail */
> +	pp3300_s3: regulator-pp3300-s3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp3300_s3";
> +		/* automatically sequenced by PMIC EXT_PMIC_EN2 */
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&pp3300_z2>;
> +	};
> +
> +	/* system wide 3.3V power rail */
> +	pp3300_z2: regulator-pp3300-z2 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp3300_z2";
> +		/* EN pin tied to pp4200_z2, which is controlled by EC */
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&ppvar_sys>;
> +	};
> +
> +	/* system wide 4.2V power rail */
> +	pp4200_z2: regulator-pp4200-z2 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp4200_z2";
> +		/* controlled by EC */
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <4200000>;
> +		regulator-max-microvolt = <4200000>;
> +		vin-supply = <&ppvar_sys>;
> +	};
> +
> +	/* system wide switching 5.0V power rail */
> +	pp5000_z2: regulator-pp5000-z2 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp5000_z2";
> +		/* controlled by EC */
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&ppvar_sys>;
> +	};
> +
> +	/* system wide semi-regulated power rail from battery or USB */
> +	ppvar_sys: regulator-ppvar-sys {
> +		compatible = "regulator-fixed";
> +		regulator-name = "ppvar_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +
> +	reserved_memory: reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		adsp_dma_mem: memory at 61000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0 0x61000000 0 0x100000>;
> +			no-map;
> +		};
> +
> +		adsp_mem: memory at 60000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0 0x60000000 0 0xA00000>;
> +			no-map;
> +		};
> +
> +		scp_mem: memory at 50000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0 0x50000000 0 0x10a0000>;
> +			no-map;
> +		};
> +	};
> +
> +	sound: sound {
> +		compatible = "mediatek,mt8186-mt6366-rt1019-rt5682s-sound";
> +		pinctrl-names = "aud_clk_mosi_off",
> +				"aud_clk_mosi_on",
> +				"aud_clk_miso_off",
> +				"aud_clk_miso_on",
> +				"aud_dat_miso_off",
> +				"aud_dat_miso_on",
> +				"aud_dat_mosi_off",
> +				"aud_dat_mosi_on",
> +				"aud_gpio_i2s0_off",
> +				"aud_gpio_i2s0_on",
> +				"aud_gpio_i2s1_off",
> +				"aud_gpio_i2s1_on",
> +				"aud_gpio_i2s2_off",
> +				"aud_gpio_i2s2_on",
> +				"aud_gpio_i2s3_off",
> +				"aud_gpio_i2s3_on",
> +				"aud_gpio_tdm_off",
> +				"aud_gpio_tdm_on",
> +				"aud_gpio_pcm_off",
> +				"aud_gpio_pcm_on",
> +				"aud_gpio_dmic_sec";
> +		pinctrl-0 = <&aud_clk_mosi_off>;
> +		pinctrl-1 = <&aud_clk_mosi_on>;
> +		pinctrl-2 = <&aud_clk_miso_off>;
> +		pinctrl-3 = <&aud_clk_miso_on>;
> +		pinctrl-4 = <&aud_dat_miso_off>;
> +		pinctrl-5 = <&aud_dat_miso_on>;
> +		pinctrl-6 = <&aud_dat_mosi_off>;
> +		pinctrl-7 = <&aud_dat_mosi_on>;
> +		pinctrl-8 = <&aud_gpio_i2s0_off>;
> +		pinctrl-9 = <&aud_gpio_i2s0_on>;
> +		pinctrl-10 = <&aud_gpio_i2s1_off>;
> +		pinctrl-11 = <&aud_gpio_i2s1_on>;
> +		pinctrl-12 = <&aud_gpio_i2s2_off>;
> +		pinctrl-13 = <&aud_gpio_i2s2_on>;
> +		pinctrl-14 = <&aud_gpio_i2s3_off>;
> +		pinctrl-15 = <&aud_gpio_i2s3_on>;
> +		pinctrl-16 = <&aud_gpio_tdm_off>;
> +		pinctrl-17 = <&aud_gpio_tdm_on>;

These two above bring errors, as discussed

> +		pinctrl-18 = <&aud_gpio_pcm_off>;
> +		pinctrl-19 = <&aud_gpio_pcm_on>;
> +		pinctrl-20 = <&aud_gpio_dmic_sec>;
> +		mediatek,adsp = <&adsp>;
> +		mediatek,platform = <&afe>;
> +
> +		playback-codecs {
> +			sound-dai = <&it6505dptx>, <&rt1019p>;
> +		};
> +
> +		headset-codec {
> +			sound-dai = <&rt5682s 0>;
> +		};
> +	};
> +
> +	rt1019p: speaker-codec {
> +		compatible = "realtek,rt1019p";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&rt1019p_pins_default>;
> +		sdb-gpios = <&pio 150 GPIO_ACTIVE_HIGH>;
> +		#sound-dai-cells = <0>;
> +	};
> +
> +	usb_p1_vbus: regulator-usb-p1-vbus {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vbus1";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		enable-active-high;
> +		gpio = <&pio 148 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&pp5000_z2>;
> +	};
> +
> +	wifi_pwrseq: wifi-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_enable_pin>;
> +		post-power-on-delay-ms = <50>;
> +		reset-gpios = <&pio 54 GPIO_ACTIVE_LOW>;
> +	};
> +
> +	wifi_wakeup: wifi-wakeup {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_wakeup_pin>;
> +
> +		wowlan-event {
> +			label = "Wake on WiFi";
> +			gpios = <&pio 7 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_WAKEUP>;
> +			wakeup-source;
> +		};
> +	};
> +};
> +
> +&adsp {
> +	memory-region = <&adsp_dma_mem>, <&adsp_mem>;
> +	status = "disabled"; /* causes stall */
> +};
> +
> +&afe {
> +	i2s0-share = "I2S1";
> +	i2s3-share = "I2S2";

These i2sX-share are not documented.

> +	status = "okay";
> +};
> +
> +&cci {
> +	proc-supply = <&mt6366_vproc12_reg>;
> +};
> +
> +&cpu0 {
> +	proc-supply = <&mt6366_vproc12_reg>;
> +};
> +
> +&cpu1 {
> +	proc-supply = <&mt6366_vproc12_reg>;
> +};
> +
> +&cpu2 {
> +	proc-supply = <&mt6366_vproc12_reg>;
> +};
> +
> +&cpu3 {
> +	proc-supply = <&mt6366_vproc12_reg>;
> +};
> +
> +&cpu4 {
> +	proc-supply = <&mt6366_vproc12_reg>;
> +};
> +
> +&cpu5 {
> +	proc-supply = <&mt6366_vproc12_reg>;
> +};
> +
> +&cpu6 {
> +	proc-supply = <&mt6366_vproc11_reg>;
> +};
> +
> +&cpu7 {
> +	proc-supply = <&mt6366_vproc11_reg>;
> +};
> +
> +&dpi {
> +	pinctrl-names = "default", "sleep";
> +	pinctrl-0 = <&dpi_pins_default>;
> +	pinctrl-1 = <&dpi_pins_sleep>;
> +	status = "okay";
> +};
> +
> +&dpi_out {
> +	remote-endpoint = <&it6505_in>;
> +};
> +
> +&dsi0 {
> +	status = "okay";
> +};
> +
> +&gic {
> +	mediatek,broken-save-restore-fw;
> +};
> +
> +&gpu {
> +	mali-supply = <&mt6366_vgpu_reg>;
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c0_pins>;
> +	status = "okay";
> +};
> +
> +&i2c1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c1_pins>;
> +	clock-frequency = <400000>;
> +	i2c-scl-internal-delay-ns = <8000>;
> +	status = "okay";
> +};
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	/*
> +	 * Trackpad pin put here to work around second source components
> +	 * sharing the pinmux in steelix designs.
> +	 */
> +	pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;

While this makes things better, it's not correct. The i2c2 bus does not use the
trackpad pin. I would believe a better way is to have a node that holds both
trackpads and claims the pin for both at once. And that node not being the i2c bus
as there could be more devices on the bus and the pin would be taken regardless of
any trackpad probing , which is not right.
Another option is to disable parallel probing for the trackpads, such that when one
fails to probe, the pin is released and can be taken by the other one.


> +	clock-frequency = <400000>;
> +	i2c-scl-internal-delay-ns = <10000>;
> +	status = "okay";
> +
> +	trackpad at 15 {
> +		compatible = "elan,ekth3000";
> +		reg = <0x15>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		vcc-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};
> +
> +&i2c3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c3_pins>;
> +	clock-frequency = <100000>;
> +	status = "okay";
> +
> +	it6505dptx: dp-bridge at 5c {
> +		compatible = "ite,it6505";
> +		reg = <0x5c>;
> +		interrupts-extended = <&pio 8 IRQ_TYPE_LEVEL_LOW>;
> +		ovdd-supply = <&mt6366_vsim2_reg>;
> +		pwr18-supply = <&pp1800_dpbrdg_dx>;
> +		reset-gpios = <&pio 177 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&it6505_pins>;
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		#sound-dai-cells = <0>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +
> +				it6505_in: endpoint {
> +					link-frequencies = /bits/ 64 <150000000>;
> +					remote-endpoint = <&dpi_out>;
> +				};
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +			};
> +		};
> +	};
> +};
> +
> +&i2c5 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c5_pins>;
> +	status = "okay";
> +
> +	rt5682s: codec at 1a {
> +		compatible = "realtek,rt5682s";
> +		reg = <0x1a>;
> +		interrupts-extended = <&pio 17 IRQ_TYPE_EDGE_BOTH>;
> +		AVDD-supply = <&mt6366_vio18_reg>;
> +		DBVDD-supply = <&mt6366_vio18_reg>;
> +		LDO1-IN-supply = <&mt6366_vio18_reg>;
> +		MICVDD-supply = <&pp3300_z2>;
> +		realtek,jd-src = <1>;
> +		#sound-dai-cells = <1>;
> +	};
> +};
> +
> +&mfg0 {
> +	domain-supply = <&mt6366_vsram_gpu_reg>;
> +};
> +
> +&mfg1 {
> +	domain-supply = <&mt6366_vgpu_reg>;
> +};
> +
> +&mipi_tx0 {
> +	status = "okay";
> +};
> +
> +&mmc0 {
> +	pinctrl-names = "default", "state_uhs";
> +	pinctrl-0 = <&mmc0_pins_default>;
> +	pinctrl-1 = <&mmc0_pins_uhs>;
> +	bus-width = <8>;
> +	max-frequency = <200000000>;
> +	non-removable;
> +	cap-mmc-highspeed;
> +	mmc-hs200-1_8v;
> +	mmc-hs400-1_8v;
> +	supports-cqe;
> +	no-sd;
> +	no-sdio;
> +	cap-mmc-hw-reset;
> +	hs400-ds-delay = <0x11814>;
> +	mediatek,hs400-ds-dly3 = <0x14>;
> +	vmmc-supply = <&mt6366_vemc_reg>;
> +	vqmmc-supply = <&mt6366_vio18_reg>;
> +	status = "okay";
> +};
> +
> +&mmc1 {
> +	pinctrl-names = "default", "state_uhs", "state_eint";
> +	pinctrl-0 = <&mmc1_pins_default>;
> +	pinctrl-1 = <&mmc1_pins_uhs>;
> +	pinctrl-2 = <&mmc1_pins_eint>;
> +	/delete-property/ interrupts;
> +	interrupt-names = "msdc", "sdio_wakeup";
> +	interrupts-extended = <&gic GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH 0>,
> +			      <&pio 87 IRQ_TYPE_LEVEL_LOW>;
> +	bus-width = <4>;
> +	max-frequency = <200000000>;
> +	cap-sd-highspeed;
> +	sd-uhs-sdr104;
> +	sd-uhs-sdr50;
> +	keep-power-in-suspend;
> +	wakeup-source;
> +	cap-sdio-irq;
> +	no-mmc;
> +	no-sd;
> +	non-removable;
> +	vmmc-supply = <&pp3300_s3>;
> +	vqmmc-supply = <&mt6366_vio18_reg>;
> +	mmc-pwrseq = <&wifi_pwrseq>;
> +	status = "okay";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	bluetooth at 2 {
> +		compatible = "mediatek,mt7921s-bluetooth";
> +		reg = <2>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bt_pins_reset>;
> +		reset-gpios = <&pio 155 GPIO_ACTIVE_LOW>;
> +	};
> +};
> +
> +&nor_flash {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&nor_pins_default>;
> +	assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D7_D4>;
> +	status = "okay";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	flash at 0 {
> +		compatible = "jedec,spi-nor";
> +		reg = <0>;
> +		spi-max-frequency = <39000000>;
> +	};
> +};
> +
> +&pio {
> +	/* 185 lines */
> +	gpio-line-names = "TP",
> +			  "TP",
> +			  "TP",
> +			  "I2S0_HP_DI",
> +			  "I2S3_DP_SPKR_DO",
> +			  "SAR_INT_ODL",
> +			  "BT_WAKE_AP_ODL",
> +			  "WIFI_INT_ODL",
> +			  "DPBRDG_INT_ODL",
> +			  "EDPBRDG_INT_ODL",
> +			  "EC_AP_HPD_OD",
> +			  "TCHPAD_INT_ODL",
> +			  "TCHSCR_INT_1V8_ODL",
> +			  "EC_AP_INT_ODL",
> +			  "EC_IN_RW_ODL",
> +			  "GSC_AP_INT_ODL",
> +			  /* AP_FLASH_WP_L is crossystem ABI. Rev1 schematics call it AP_WP_ODL. */
> +			  "AP_FLASH_WP_L",
> +			  "HP_INT_ODL",
> +			  "PEN_EJECT_OD",
> +			  "WCAM_PWDN_L",
> +			  "WCAM_RST_L",
> +			  "UCAM_SEN_EN",
> +			  "UCAM_RST_L",
> +			  "LTE_RESET_L",
> +			  "LTE_SAR_DETECT_L",
> +			  "I2S2_DP_SPK_MCK",
> +			  "I2S2_DP_SPKR_BCK",
> +			  "I2S2_DP_SPKR_LRCK",
> +			  "I2S2_DP_SPKR_DI (TP)",
> +			  "EN_PP1000_EDPBRDG",
> +			  "EN_PP1800_EDPBRDG",
> +			  "EN_PP3300_EDPBRDG",
> +			  "UART_GSC_TX_AP_RX",
> +			  "UART_AP_TX_GSC_RX",
> +			  "UART_DBGCON_TX_ADSP_RX",
> +			  "UART_ADSP_TX_DBGCON_RX",
> +			  "EN_PP1000_DPBRDG",
> +			  "TCHSCR_REPORT_DISABLE",
> +			  "EN_PP3300_DPBRDG",
> +			  "EN_PP1800_DPBRDG",
> +			  "SPI_AP_CLK_EC",
> +			  "SPI_AP_CS_EC_L",
> +			  "SPI_AP_DO_EC_DI",
> +			  "SPI_AP_DI_EC_DO",
> +			  "SPI_AP_CLK_GSC",
> +			  "SPI_AP_CS_GSC_L",
> +			  "SPI_AP_DO_GSC_DI",
> +			  "SPI_AP_DI_GSC_DO",
> +			  "UART_DBGCON_TX_SCP_RX",
> +			  "UART_SCP_TX_DBGCON_RX",
> +			  "EN_PP1200_CAM_X",
> +			  "EN_PP2800A_VCM_X",
> +			  "EN_PP2800A_UCAM_X",
> +			  "EN_PP2800A_WCAM_X",
> +			  "WLAN_MODULE_RST_L",
> +			  "EN_PP1200_UCAM_X",
> +			  "I2S1_HP_DO",
> +			  "I2S1_HP_BCK",
> +			  "I2S1_HP_LRCK",
> +			  "I2S1_HP_MCK",
> +			  "TCHSCR_RST_1V8_L",
> +			  "SPI_AP_CLK_ROM",
> +			  "SPI_AP_CS_ROM_L",
> +			  "SPI_AP_DO_ROM_DI",
> +			  "SPI_AP_DI_ROM_DO",
> +			  "NC",
> +			  "NC",
> +			  "EMMC_STRB",
> +			  "EMMC_CLK",
> +			  "EMMC_CMD",
> +			  "EMMC_RST_L",
> +			  "EMMC_DATA0",
> +			  "EMMC_DATA1",
> +			  "EMMC_DATA2",
> +			  "EMMC_DATA3",
> +			  "EMMC_DATA4",
> +			  "EMMC_DATA5",
> +			  "EMMC_DATA6",
> +			  "EMMC_DATA7",
> +			  "AP_KPCOL0",
> +			  "NC",
> +			  "NC",
> +			  "NC",
> +			  "TP",
> +			  "SDIO_CLK",
> +			  "SDIO_CMD",
> +			  "SDIO_DATA0",
> +			  "SDIO_DATA1",
> +			  "SDIO_DATA2",
> +			  "SDIO_DATA3",
> +			  "NC",
> +			  "NC",
> +			  "NC",
> +			  "NC",
> +			  "NC",
> +			  "NC",
> +			  "EDPBRDG_PWREN",
> +			  "BL_PWM_1V8",
> +			  "EDPBRDG_RST_L",
> +			  "MIPI_DPI_CLK",
> +			  "MIPI_DPI_VSYNC",
> +			  "MIPI_DPI_HSYNC",
> +			  "MIPI_DPI_DE",
> +			  "MIPI_DPI_D0",
> +			  "MIPI_DPI_D1",
> +			  "MIPI_DPI_D2",
> +			  "MIPI_DPI_D3",
> +			  "MIPI_DPI_D4",
> +			  "MIPI_DPI_D5",
> +			  "MIPI_DPI_D6",
> +			  "MIPI_DPI_DA7",
> +			  "MIPI_DPI_D8",
> +			  "MIPI_DPI_D9",
> +			  "MIPI_DPI_D10",
> +			  "MIPI_DPI_D11",
> +			  "PCM_BT_CLK",
> +			  "PCM_BT_SYNC",
> +			  "PCM_BT_DI",
> +			  "PCM_BT_DO",
> +			  "JTAG_TMS_TP",
> +			  "JTAG_TCK_TP",
> +			  "JTAG_TDI_TP",
> +			  "JTAG_TDO_TP",
> +			  "JTAG_TRSTN_TP",
> +			  "CLK_24M_WCAM",
> +			  "CLK_24M_UCAM",
> +			  "UCAM_DET_ODL",
> +			  "AP_I2C_EDPBRDG_SCL_1V8",
> +			  "AP_I2C_EDPBRDG_SDA_1V8",
> +			  "AP_I2C_TCHSCR_SCL_1V8",
> +			  "AP_I2C_TCHSCR_SDA_1V8",
> +			  "AP_I2C_TCHPAD_SCL_1V8",
> +			  "AP_I2C_TCHPAD_SDA_1V8",
> +			  "AP_I2C_DPBRDG_SCL_1V8",
> +			  "AP_I2C_DPBRDG_SDA_1V8",
> +			  "AP_I2C_WLAN_SCL_1V8",
> +			  "AP_I2C_WLAN_SDA_1V8",
> +			  "AP_I2C_AUD_SCL_1V8",
> +			  "AP_I2C_AUD_SDA_1V8",
> +			  "AP_I2C_TPM_SCL_1V8",
> +			  "AP_I2C_UCAM_SDA_1V8",
> +			  "AP_I2C_UCAM_SCL_1V8",
> +			  "AP_I2C_UCAM_SDA_1V8",
> +			  "AP_I2C_WCAM_SCL_1V8",
> +			  "AP_I2C_WCAM_SDA_1V8",
> +			  "SCP_I2C_SENSOR_SCL_1V8",
> +			  "SCP_I2C_SENSOR_SDA_1V8",
> +			  "AP_EC_WARM_RST_REQ",
> +			  "AP_XHCI_INIT_DONE",
> +			  "USB3_HUB_RST_L",
> +			  "EN_SPKR",
> +			  "BEEP_ON",
> +			  "AP_EDP_BKLTEN",
> +			  "EN_PP3300_DISP_X",
> +			  "EN_PP3300_SDBRDG_X",
> +			  "BT_KILL_1V8_L",
> +			  "WIFI_KILL_1V8_L",
> +			  "PWRAP_SPI0_CSN",
> +			  "PWRAP_SPI0_CK",
> +			  "PWRAP_SPI0_MO",
> +			  "PWRAP_SPI0_MI",
> +			  "SRCLKENA0",
> +			  "SRCLKENA1",
> +			  "SCP_VREQ_VAO",
> +			  "AP_RTC_CLK32K",
> +			  "AP_PMIC_WDTRST_L",
> +			  "AUD_CLK_MOSI",
> +			  "AUD_SYNC_MOSI",
> +			  "AUD_DAT_MOSI0",
> +			  "AUD_DAT_MOSI1",
> +			  "AUD_CLK_MISO",
> +			  "AUD_SYNC_MISO",
> +			  "AUD_DAT_MISO0",
> +			  "AUD_DAT_MISO1",
> +			  "NC",
> +			  "NC",
> +			  "DPBRDG_PWREN",
> +			  "DPBRDG_RST_L",
> +			  "LTE_W_DISABLE_L",
> +			  "LTE_SAR_DETECT_L",
> +			  "EN_PP3300_LTE_X",
> +			  "LTE_PWR_OFF_L",
> +			  "LTE_RESET_L",
> +			  "TP",
> +			  "TP";
> +
> +	aud_clk_mosi_off: aud-clk-mosi-off-pins {
> +		pins-clk-sync {
> +			pinmux = <PINMUX_GPIO166__FUNC_GPIO166>,
> +				 <PINMUX_GPIO167__FUNC_GPIO167>;
> +			input-enable;
> +			bias-pull-down;
> +		};
> +	};
> +
> +	aud_clk_mosi_on: aud-clk-mosi-on-pins {
> +		pins-clk-sync {
> +			pinmux = <PINMUX_GPIO166__FUNC_AUD_CLK_MOSI>,
> +				 <PINMUX_GPIO167__FUNC_AUD_SYNC_MOSI>;
> +		};
> +	};
> +
> +	aud_clk_miso_off: aud-clk-miso-off-pins {
> +		pins-clk-sync {
> +			pinmux = <PINMUX_GPIO170__FUNC_GPIO170>,
> +				 <PINMUX_GPIO171__FUNC_GPIO171>;
> +			input-enable;
> +			bias-pull-down;
> +		};
> +	};
> +
> +	aud_clk_miso_on: aud-clk-miso-on-pins {
> +		pins-clk-sync {
> +			pinmux = <PINMUX_GPIO170__FUNC_AUD_CLK_MISO>,
> +				 <PINMUX_GPIO171__FUNC_AUD_SYNC_MISO>;
> +		};
> +	};
> +
> +	aud_dat_mosi_off: aud-dat-mosi-off-pins {
> +		pins-dat {
> +			pinmux = <PINMUX_GPIO168__FUNC_GPIO168>,
> +				 <PINMUX_GPIO169__FUNC_GPIO169>;
> +			input-enable;
> +			bias-pull-down;
> +		};
> +	};
> +
> +	aud_dat_mosi_on: aud-dat-mosi-on-pins {
> +		pins-dat {
> +			pinmux = <PINMUX_GPIO168__FUNC_AUD_DAT_MOSI0>,
> +				 <PINMUX_GPIO169__FUNC_AUD_DAT_MOSI1>;
> +		};
> +	};
> +
> +	aud_dat_miso_off: aud-dat-miso-off-pins {
> +		pins-dat {
> +			pinmux = <PINMUX_GPIO172__FUNC_GPIO172>,
> +				 <PINMUX_GPIO173__FUNC_GPIO173>;
> +			input-enable;
> +			bias-pull-down;
> +		};
> +	};
> +
> +	aud_dat_miso_on: aud-dat-miso-on-pins {
> +		pins-dat {
> +			pinmux = <PINMUX_GPIO172__FUNC_AUD_DAT_MISO0>,
> +				 <PINMUX_GPIO173__FUNC_AUD_DAT_MISO1>;
> +			input-schmitt-enable;
> +			bias-disable;
> +		};
> +	};
> +
> +	aud_gpio_i2s0_off: aud-gpio-i2s0-off-pins {
> +		pins-sdata {
> +			pinmux = <PINMUX_GPIO3__FUNC_GPIO3>;
> +		};
> +	};
> +
> +	aud_gpio_i2s0_on: aud-gpio-i2s0-on-pins {
> +		pins-sdata {
> +			pinmux = <PINMUX_GPIO3__FUNC_I2S0_DI>;
> +		};
> +	};
> +
> +	aud_gpio_i2s1_off: aud-gpio-i2s-off-pins {
> +		pins-clk-sdata {
> +			pinmux = <PINMUX_GPIO56__FUNC_GPIO56>,
> +				 <PINMUX_GPIO57__FUNC_GPIO57>,
> +				 <PINMUX_GPIO58__FUNC_GPIO58>,
> +				 <PINMUX_GPIO59__FUNC_GPIO59>;
> +			output-low;
> +		};
> +	};
> +
> +	aud_gpio_i2s1_on: aud-gpio-i2s1-on-pins {
> +		pins-clk-sdata {
> +			pinmux = <PINMUX_GPIO56__FUNC_I2S1_DO>,
> +				 <PINMUX_GPIO57__FUNC_I2S1_BCK>,
> +				 <PINMUX_GPIO58__FUNC_I2S1_LRCK>,
> +				 <PINMUX_GPIO59__FUNC_I2S1_MCK>;
> +		};
> +	};
> +
> +	aud_gpio_i2s2_off: aud-gpio-i2s2-off-pins {
> +		pins-cmd-dat {
> +			pinmux = <PINMUX_GPIO26__FUNC_GPIO26>,
> +				 <PINMUX_GPIO27__FUNC_GPIO27>;
> +			output-low;
> +		};
> +	};
> +
> +	aud_gpio_i2s2_on: aud-gpio-i2s2-on-pins {
> +		pins-clk {
> +			pinmux = <PINMUX_GPIO26__FUNC_I2S2_BCK>,
> +				 <PINMUX_GPIO27__FUNC_I2S2_LRCK>;
> +			drive-strength = <4>;
> +		};
> +	};
> +
> +	aud_gpio_i2s3_off: aud-gpio-i2s3-off-pins {
> +		pins-sdata {
> +			pinmux = <PINMUX_GPIO4__FUNC_GPIO4>;
> +			output-low;
> +		};
> +	};
> +
> +	aud_gpio_i2s3_on: aud-gpio-i2s3-on-pins {
> +		pins-sdata {
> +			pinmux = <PINMUX_GPIO4__FUNC_I2S3_DO>;
> +			drive-strength = <4>;
> +		};
> +	};
> +
> +	aud_gpio_tdm_off: aud-gpio-tdm-off-pins { };
> +
> +	aud_gpio_tdm_on: aud-gpio-tdm-on-pins { };

Guess have to remove these two empty pinctrls.
> +
> +	aud_gpio_pcm_off: aud-gpio-pcm-off-pins {
> +		pins-clk-sdata {
> +			pinmux = <PINMUX_GPIO115__FUNC_GPIO115>,
> +				 <PINMUX_GPIO116__FUNC_GPIO116>,
> +				 <PINMUX_GPIO117__FUNC_GPIO117>,
> +				 <PINMUX_GPIO118__FUNC_GPIO118>;
> +			output-low;
> +		};
> +	};
> +
> +	aud_gpio_pcm_on: aud-gpio-pcm-on-pins {
> +		pins-clk-sdata {
> +			pinmux = <PINMUX_GPIO115__FUNC_PCM_CLK>,
> +				 <PINMUX_GPIO116__FUNC_PCM_SYNC>,
> +				 <PINMUX_GPIO117__FUNC_PCM_DI>,
> +				 <PINMUX_GPIO118__FUNC_PCM_DO>;
> +		};
> +	};
> +
> +	aud_gpio_dmic_sec: aud-gpio-dmic-sec-pins {
> +		pins {
> +			pinmux = <PINMUX_GPIO23__FUNC_GPIO23>;
> +			output-low;
> +		};
> +	};
> +
> +	bt_pins_reset: bt-reset-pins {
> +		pins-bt-reset {
> +			pinmux = <PINMUX_GPIO155__FUNC_GPIO155>;
> +			output-high;
> +		};
> +	};
> +
> +	dpi_pins_sleep: dpi-sleep-pins {
> +		pins-cmd-dat {
> +			pinmux = <PINMUX_GPIO103__FUNC_GPIO103>,
> +				 <PINMUX_GPIO104__FUNC_GPIO104>,
> +				 <PINMUX_GPIO105__FUNC_GPIO105>,
> +				 <PINMUX_GPIO106__FUNC_GPIO106>,
> +				 <PINMUX_GPIO107__FUNC_GPIO107>,
> +				 <PINMUX_GPIO108__FUNC_GPIO108>,
> +				 <PINMUX_GPIO109__FUNC_GPIO109>,
> +				 <PINMUX_GPIO110__FUNC_GPIO110>,
> +				 <PINMUX_GPIO111__FUNC_GPIO111>,
> +				 <PINMUX_GPIO112__FUNC_GPIO112>,
> +				 <PINMUX_GPIO113__FUNC_GPIO113>,
> +				 <PINMUX_GPIO114__FUNC_GPIO114>,
> +				 <PINMUX_GPIO101__FUNC_GPIO101>,
> +				 <PINMUX_GPIO100__FUNC_GPIO100>,
> +				 <PINMUX_GPIO102__FUNC_GPIO102>,
> +				 <PINMUX_GPIO99__FUNC_GPIO99>;
> +			drive-strength = <10>;
> +			output-low;
> +		};
> +	};
> +
> +	dpi_pins_default: dpi-default-pins {
> +		pins-cmd-dat {
> +			pinmux = <PINMUX_GPIO103__FUNC_DPI_DATA0>,
> +				 <PINMUX_GPIO104__FUNC_DPI_DATA1>,
> +				 <PINMUX_GPIO105__FUNC_DPI_DATA2>,
> +				 <PINMUX_GPIO106__FUNC_DPI_DATA3>,
> +				 <PINMUX_GPIO107__FUNC_DPI_DATA4>,
> +				 <PINMUX_GPIO108__FUNC_DPI_DATA5>,
> +				 <PINMUX_GPIO109__FUNC_DPI_DATA6>,
> +				 <PINMUX_GPIO110__FUNC_DPI_DATA7>,
> +				 <PINMUX_GPIO111__FUNC_DPI_DATA8>,
> +				 <PINMUX_GPIO112__FUNC_DPI_DATA9>,
> +				 <PINMUX_GPIO113__FUNC_DPI_DATA10>,
> +				 <PINMUX_GPIO114__FUNC_DPI_DATA11>,
> +				 <PINMUX_GPIO101__FUNC_DPI_HSYNC>,
> +				 <PINMUX_GPIO100__FUNC_DPI_VSYNC>,
> +				 <PINMUX_GPIO102__FUNC_DPI_DE>,
> +				 <PINMUX_GPIO99__FUNC_DPI_PCLK>;
> +			drive-strength = <10>;
> +		};
> +	};
> +
> +	ec_ap_int: cros-ec-int-pins {
> +		pins-ec-ap-int-odl {
> +			pinmux = <PINMUX_GPIO13__FUNC_GPIO13>;
> +			input-enable;
> +		};
> +	};
> +
> +	edp_panel_fixed_pins: edp-panel-fixed-pins {
> +		pins-vreg-en {
> +			pinmux = <PINMUX_GPIO153__FUNC_GPIO153>;
> +			output-high;
> +		};
> +	};
> +
> +	en_pp1800_dpbrdg: en-pp1800-dpbrdg-pins {
> +		pins-vreg-en {
> +			pinmux = <PINMUX_GPIO39__FUNC_GPIO39>;
> +			output-low;
> +		};
> +	};
> +
> +	gsc_int: gsc-int-pins {
> +		pins-gsc-ap-int-odl {
> +			pinmux = <PINMUX_GPIO15__FUNC_GPIO15>;
> +			input-enable;
> +		};
> +	};
> +
> +	i2c0_pins: i2c0-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO128__FUNC_SDA0>,
> +				 <PINMUX_GPIO127__FUNC_SCL0>;
> +			bias-disable;
> +			drive-strength = <4>;
> +			input-enable;
> +		};
> +	};
> +
> +	i2c1_pins: i2c1-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO130__FUNC_SDA1>,
> +				 <PINMUX_GPIO129__FUNC_SCL1>;
> +			bias-disable;
> +			drive-strength = <4>;
> +			input-enable;
> +		};
> +	};
> +
> +	i2c2_pins: i2c2-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO132__FUNC_SDA2>,
> +				 <PINMUX_GPIO131__FUNC_SCL2>;
> +			bias-disable;
> +			drive-strength = <4>;
> +			input-enable;
> +		};
> +	};
> +
> +	i2c3_pins: i2c3-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO134__FUNC_SDA3>,
> +				 <PINMUX_GPIO133__FUNC_SCL3>;
> +			bias-disable;
> +			drive-strength = <4>;
> +			input-enable;
> +		};
> +	};
> +
> +	i2c5_pins: i2c5-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO138__FUNC_SDA5>,
> +				 <PINMUX_GPIO137__FUNC_SCL5>;
> +			bias-disable;
> +			drive-strength = <4>;
> +			input-enable;
> +		};
> +	};
> +
> +	it6505_pins: it6505-pins {
> +		pins-hpd {
> +			pinmux = <PINMUX_GPIO10__FUNC_GPIO10>;
> +			input-enable;
> +			bias-pull-up;
> +		};
> +
> +		pins-int {
> +			pinmux = <PINMUX_GPIO8__FUNC_GPIO8>;
> +			input-enable;
> +			bias-pull-up;
> +		};
> +
> +		pins-reset {
> +			pinmux = <PINMUX_GPIO177__FUNC_GPIO177>;
> +			output-low;
> +			bias-pull-up;
> +		};
> +	};
> +
> +	mmc0_pins_default: mmc0-default-pins {
> +		pins-clk {
> +			pinmux = <PINMUX_GPIO68__FUNC_MSDC0_CLK>;
> +			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> +		};
> +
> +		pins-cmd-dat {
> +			pinmux = <PINMUX_GPIO71__FUNC_MSDC0_DAT0>,
> +				 <PINMUX_GPIO72__FUNC_MSDC0_DAT1>,
> +				 <PINMUX_GPIO73__FUNC_MSDC0_DAT2>,
> +				 <PINMUX_GPIO74__FUNC_MSDC0_DAT3>,
> +				 <PINMUX_GPIO75__FUNC_MSDC0_DAT4>,
> +				 <PINMUX_GPIO76__FUNC_MSDC0_DAT5>,
> +				 <PINMUX_GPIO77__FUNC_MSDC0_DAT6>,
> +				 <PINMUX_GPIO78__FUNC_MSDC0_DAT7>,
> +				 <PINMUX_GPIO69__FUNC_MSDC0_CMD>;
> +			input-enable;
> +			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> +		};
> +
> +		pins-rst {
> +			pinmux = <PINMUX_GPIO70__FUNC_MSDC0_RSTB>;
> +			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> +		};
> +	};
> +
> +	mmc0_pins_uhs: mmc0-uhs-pins {
> +		pins-clk {
> +			pinmux = <PINMUX_GPIO68__FUNC_MSDC0_CLK>;
> +			drive-strength = <6>;
> +			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> +		};
> +
> +		pins-cmd-dat {
> +			pinmux = <PINMUX_GPIO71__FUNC_MSDC0_DAT0>,
> +				 <PINMUX_GPIO72__FUNC_MSDC0_DAT1>,
> +				 <PINMUX_GPIO73__FUNC_MSDC0_DAT2>,
> +				 <PINMUX_GPIO74__FUNC_MSDC0_DAT3>,
> +				 <PINMUX_GPIO75__FUNC_MSDC0_DAT4>,
> +				 <PINMUX_GPIO76__FUNC_MSDC0_DAT5>,
> +				 <PINMUX_GPIO77__FUNC_MSDC0_DAT6>,
> +				 <PINMUX_GPIO78__FUNC_MSDC0_DAT7>,
> +				 <PINMUX_GPIO69__FUNC_MSDC0_CMD>;
> +			input-enable;
> +			drive-strength = <6>;
> +			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> +		};
> +
> +		pins-ds {
> +			pinmux = <PINMUX_GPIO67__FUNC_MSDC0_DSL>;
> +			drive-strength = <6>;
> +			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> +		};
> +
> +		pins-rst {
> +			pinmux = <PINMUX_GPIO70__FUNC_MSDC0_RSTB>;
> +			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> +		};
> +	};
> +
> +	mmc1_pins_default: mmc1-default-pins {
> +		pins-clk {
> +			pinmux = <PINMUX_GPIO84__FUNC_MSDC1_CLK>;
> +			drive-strength = <6>;
> +			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> +		};
> +
> +		pins-cmd-dat {
> +			pinmux = <PINMUX_GPIO86__FUNC_MSDC1_DAT0>,
> +				 <PINMUX_GPIO87__FUNC_MSDC1_DAT1>,
> +				 <PINMUX_GPIO88__FUNC_MSDC1_DAT2>,
> +				 <PINMUX_GPIO89__FUNC_MSDC1_DAT3>,
> +				 <PINMUX_GPIO85__FUNC_MSDC1_CMD>;
> +			input-enable;
> +			drive-strength = <6>;
> +			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> +		};
> +	};
> +
> +	mmc1_pins_uhs: mmc1-uhs-pins {
> +		pins-clk {
> +			pinmux = <PINMUX_GPIO84__FUNC_MSDC1_CLK>;
> +			drive-strength = <6>;
> +			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> +		};
> +
> +		pins-cmd-dat {
> +			pinmux = <PINMUX_GPIO86__FUNC_MSDC1_DAT0>,
> +				 <PINMUX_GPIO87__FUNC_MSDC1_DAT1>,
> +				 <PINMUX_GPIO88__FUNC_MSDC1_DAT2>,
> +				 <PINMUX_GPIO89__FUNC_MSDC1_DAT3>,
> +				 <PINMUX_GPIO85__FUNC_MSDC1_CMD>;
> +			input-enable;
> +			drive-strength = <8>;
> +			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> +		};
> +	};
> +
> +	mmc1_pins_eint: mmc1-eint-pins {
> +		pins-dat1 {
> +			pinmux = <PINMUX_GPIO87__FUNC_GPIO87>;
> +			input-enable;
> +			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> +		};
> +	};
> +
> +	nor_pins_default: nor-default-pins {
> +		pins-clk-dat {
> +			pinmux = <PINMUX_GPIO63__FUNC_SPINOR_IO0>,
> +				 <PINMUX_GPIO61__FUNC_SPINOR_CK>,
> +				 <PINMUX_GPIO64__FUNC_SPINOR_IO1>;
> +			drive-strength = <6>;
> +			bias-pull-down;
> +		};
> +
> +		pins-cs-dat {
> +			pinmux = <PINMUX_GPIO62__FUNC_SPINOR_CS>,
> +				 <PINMUX_GPIO65__FUNC_SPINOR_IO2>,
> +				 <PINMUX_GPIO66__FUNC_SPINOR_IO3>;
> +			drive-strength = <6>;
> +			bias-pull-up;
> +		};
> +	};
> +
> +	pen_eject: pen-eject-pins {
> +		pins {
> +			pinmux = <PINMUX_GPIO18__FUNC_GPIO18>;
> +			input-enable;
> +			/* External pull-up. */
> +			bias-disable;
> +		};
> +	};
> +
> +	pwm0_pin: disp-pwm-pins {
> +		pins {
> +			pinmux = <PINMUX_GPIO97__FUNC_DISP_PWM>;
> +			output-high;
> +		};
> +	};
> +
> +	rt1019p_pins_default: rt1019p-default-pins {
> +		pins-sdb {
> +			pinmux = <PINMUX_GPIO150__FUNC_GPIO150>;
> +			output-low;
> +		};
> +	};
> +
> +	scp_pins: scp-default-pins {
> +		pins-scp-uart {
> +			pinmux = <PINMUX_GPIO48__FUNC_TP_URXD2_AO>,
> +				 <PINMUX_GPIO49__FUNC_TP_UTXD2_AO>;
> +		};
> +	};
> +
> +	spi1_pins: spi1-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO40__FUNC_SPI1_CLK_A>,
> +				 <PINMUX_GPIO41__FUNC_SPI1_CSB_A>,
> +				 <PINMUX_GPIO42__FUNC_SPI1_MO_A>,
> +				 <PINMUX_GPIO43__FUNC_SPI1_MI_A>;
> +			bias-disable;
> +			input-enable;
> +		};
> +	};
> +
> +	spi2_pins: spi2-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO44__FUNC_SPI2_CLK_A>,
> +				 <PINMUX_GPIO45__FUNC_GPIO45>,
> +				 <PINMUX_GPIO46__FUNC_SPI2_MO_A>,
> +				 <PINMUX_GPIO47__FUNC_SPI2_MI_A>;
> +			bias-disable;
> +			input-enable;
> +		};
> +	};
> +
> +	spmi_pins: spmi-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO183__FUNC_SPMI_SCL>,
> +				 <PINMUX_GPIO184__FUNC_SPMI_SDA>;
> +		};
> +	};
> +
> +	touchscreen_pins: touchscreen-pins {
> +		pins-irq {
> +			pinmux = <PINMUX_GPIO12__FUNC_GPIO12>;
> +			input-enable;
> +			bias-pull-up;
> +		};
> +
> +		pins-reset {
> +			pinmux = <PINMUX_GPIO60__FUNC_GPIO60>;
> +			output-high;
> +		};
> +
> +		pins-report-sw {
> +			pinmux = <PINMUX_GPIO37__FUNC_GPIO37>;
> +			output-low;
> +		};
> +	};
> +
> +	trackpad_pin: trackpad-default-pins {
> +		pins-int-n {
> +			pinmux = <PINMUX_GPIO11__FUNC_GPIO11>;
> +			input-enable;
> +			bias-disable; /* pulled externally */
> +		};
> +	};
> +
> +	wifi_enable_pin: wifi-enable-pins {
> +		pins-wifi-enable {
> +			pinmux = <PINMUX_GPIO54__FUNC_GPIO54>;
> +		};
> +	};
> +
> +	wifi_wakeup_pin: wifi-wakeup-pins {
> +		pins-wifi-wakeup {
> +			pinmux = <PINMUX_GPIO7__FUNC_GPIO7>;
> +			input-enable;
> +		};
> +	};
> +};
> +
> +&pwm0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pwm0_pin>;
> +	status = "okay";
> +};
> +
> +&pwrap {
> +	pmic {
> +		compatible = "mediatek,mt6366", "mediatek,mt6358";
> +		interrupt-controller;
> +		interrupts-extended = <&pio 201 IRQ_TYPE_LEVEL_HIGH>;
> +		#interrupt-cells = <2>;
> +
> +		mt6366codec: codec {
> +			compatible = "mediatek,mt6366-sound", "mediatek,mt6358-sound";
> +			Avdd-supply = <&mt6366_vaud28_reg>;
> +			mediatek,dmic-mode = <1>; /* one-wire */
> +		};
> +
> +		mt6366_regulators: regulators {
> +			compatible = "mediatek,mt6366-regulator", "mediatek,mt6358-regulator";
> +			vsys-ldo1-supply = <&pp4200_z2>;
> +			vsys-ldo2-supply = <&pp4200_z2>;
> +			vsys-ldo3-supply = <&pp4200_z2>;
> +			vsys-vcore-supply = <&pp4200_z2>;
> +			vsys-vdram1-supply = <&pp4200_z2>;
> +			vsys-vgpu-supply = <&pp4200_z2>;
> +			vsys-vmodem-supply = <&pp4200_z2>;
> +			vsys-vpa-supply = <&pp4200_z2>;
> +			vsys-vproc11-supply = <&pp4200_z2>;
> +			vsys-vproc12-supply = <&pp4200_z2>;
> +			vsys-vs1-supply = <&pp4200_z2>;
> +			vsys-vs2-supply = <&pp4200_z2>;
> +			vs1-ldo1-supply = <&mt6366_vs1_reg>;
> +			vs2-ldo1-supply = <&mt6366_vdram1_reg>;
> +			vs2-ldo2-supply = <&mt6366_vs2_reg>;
> +			vs2-ldo3-supply = <&mt6366_vs2_reg>;
> +
> +			vcore {
> +				regulator-name = "pp0750_dvdd_core";
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <800000>;
> +				regulator-ramp-delay = <6250>;
> +				regulator-enable-ramp-delay = <200>;
> +				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
> +							   MT6397_BUCK_MODE_FORCE_PWM>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vdram1_reg: vdram1 {
> +				regulator-name = "pp1125_emi_vdd2";
> +				regulator-min-microvolt = <1125000>;
> +				regulator-max-microvolt = <1125000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-enable-ramp-delay = <0>;
> +				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
> +							   MT6397_BUCK_MODE_FORCE_PWM>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vgpu_reg: vgpu {
> +				/*
> +				 * Called "ppvar_dvdd_gpu" in the schematic.
> +				 * Called "ppvar_dvdd_vgpu" here to match
> +				 * regulator coupling requirements.
> +				 */
> +				regulator-name = "ppvar_dvdd_vgpu";
> +				regulator-min-microvolt = <600000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-ramp-delay = <6250>;
> +				regulator-enable-ramp-delay = <200>;
> +				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
> +							   MT6397_BUCK_MODE_FORCE_PWM>;
> +				regulator-coupled-with = <&mt6366_vsram_gpu_reg>;
> +				regulator-coupled-max-spread = <10000>;
> +			};
> +
> +			mt6366_vproc11_reg: vproc11 {
> +				regulator-name = "ppvar_dvdd_proc_bc_mt6366";
> +				regulator-min-microvolt = <600000>;
> +				regulator-max-microvolt = <1200000>;
> +				regulator-ramp-delay = <6250>;
> +				regulator-enable-ramp-delay = <200>;
> +				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
> +							   MT6397_BUCK_MODE_FORCE_PWM>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vproc12_reg: vproc12 {
> +				regulator-name = "ppvar_dvdd_proc_lc";
> +				regulator-min-microvolt = <600000>;
> +				regulator-max-microvolt = <1200000>;
> +				regulator-ramp-delay = <6250>;
> +				regulator-enable-ramp-delay = <200>;
> +				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
> +							   MT6397_BUCK_MODE_FORCE_PWM>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vs1_reg: vs1 {
> +				regulator-name = "pp2000_vs1";
> +				regulator-min-microvolt = <2000000>;
> +				regulator-max-microvolt = <2000000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-enable-ramp-delay = <0>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vs2_reg: vs2 {
> +				regulator-name = "pp1350_vs2";
> +				regulator-min-microvolt = <1350000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-enable-ramp-delay = <0>;
> +				regulator-always-on;
> +			};
> +
> +			va12 {
> +				regulator-name = "pp1200_va12";
> +				regulator-min-microvolt = <1200000>;
> +				regulator-max-microvolt = <1200000>;
> +				regulator-enable-ramp-delay = <270>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vaud28_reg: vaud28 {
> +				regulator-name = "pp2800_vaud28";
> +				regulator-min-microvolt = <2800000>;
> +				regulator-max-microvolt = <2800000>;
> +				regulator-enable-ramp-delay = <270>;
> +			};
> +
> +			mt6366_vaux18_reg: vaux18 {
> +				regulator-name = "pp1840_vaux18";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1840000>;
> +				regulator-enable-ramp-delay = <270>;
> +			};
> +
> +			mt6366_vbif28_reg: vbif28 {
> +				regulator-name = "pp2800_vbif28";
> +				regulator-min-microvolt = <2800000>;
> +				regulator-max-microvolt = <2800000>;
> +				regulator-enable-ramp-delay = <270>;
> +			};
> +
> +			mt6366_vcn18_reg: vcn18 {
> +				regulator-name = "pp1800_vcn18_x";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-enable-ramp-delay = <270>;
> +			};
> +
> +			mt6366_vcn28_reg: vcn28 {
> +				regulator-name = "pp2800_vcn28_x";
> +				regulator-min-microvolt = <2800000>;
> +				regulator-max-microvolt = <2800000>;
> +				regulator-enable-ramp-delay = <270>;
> +			};
> +
> +			mt6366_vefuse_reg: vefuse {
> +				regulator-name = "pp1800_vefuse";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-enable-ramp-delay = <270>;
> +			};
> +
> +			mt6366_vfe28_reg: vfe28 {
> +				regulator-name = "pp2800_vfe28_x";
> +				regulator-min-microvolt = <2800000>;
> +				regulator-max-microvolt = <2800000>;
> +				regulator-enable-ramp-delay = <270>;
> +			};
> +
> +			mt6366_vemc_reg: vemc {
> +				regulator-name = "pp3000_vemc";
> +				regulator-min-microvolt = <3000000>;
> +				regulator-max-microvolt = <3000000>;
> +				regulator-enable-ramp-delay = <60>;
> +			};
> +
> +			mt6366_vibr_reg: vibr {
> +				regulator-name = "pp2800_vibr_x";
> +				regulator-min-microvolt = <2800000>;
> +				regulator-max-microvolt = <2800000>;
> +				regulator-enable-ramp-delay = <60>;
> +			};
> +
> +			mt6366_vio18_reg: vio18 {
> +				regulator-name = "pp1800_vio18_s3";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-enable-ramp-delay = <2700>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vio28_reg: vio28 {
> +				regulator-name = "pp2800_vio28_x";
> +				regulator-min-microvolt = <2800000>;
> +				regulator-max-microvolt = <2800000>;
> +				regulator-enable-ramp-delay = <270>;
> +			};
> +
> +			mt6366_vm18_reg: vm18 {
> +				regulator-name = "pp1800_emi_vdd1";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1840000>;
> +				regulator-enable-ramp-delay = <325>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vmc_reg: vmc {
> +				regulator-name = "pp3000_vmc";
> +				regulator-min-microvolt = <3000000>;
> +				regulator-max-microvolt = <3000000>;
> +				regulator-enable-ramp-delay = <60>;
> +			};
> +
> +			mt6366_vmddr_reg: vmddr {
> +				regulator-name = "pm0750_emi_vmddr";
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-enable-ramp-delay = <325>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vmch_reg: vmch {
> +				regulator-name = "pp3000_vmch";
> +				regulator-min-microvolt = <3000000>;
> +				regulator-max-microvolt = <3000000>;
> +				regulator-enable-ramp-delay = <60>;
> +			};
> +
> +			mt6366_vcn33_reg: vcn33 {
> +				regulator-name = "pp3300_vcn33_x";
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-enable-ramp-delay = <270>;
> +			};
> +
> +			vdram2 {
> +				regulator-name = "pp0600_emi_vddq";
> +				regulator-min-microvolt = <600000>;
> +				regulator-max-microvolt = <600000>;
> +				regulator-enable-ramp-delay = <3300>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vrf12_reg: vrf12 {
> +				regulator-name = "pp1200_vrf12_x";
> +				regulator-min-microvolt = <1200000>;
> +				regulator-max-microvolt = <1200000>;
> +				regulator-enable-ramp-delay = <120>;
> +			};
> +
> +			mt6366_vrf18_reg: vrf18 {
> +				regulator-name = "pp1800_vrf18_x";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-enable-ramp-delay = <120>;
> +			};
> +
> +			vsim1 {
> +				regulator-name = "pp1860_vsim1_x";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1860000>;
> +				regulator-enable-ramp-delay = <540>;
> +			};
> +
> +			mt6366_vsim2_reg: vsim2 {
> +				regulator-name = "pp2760_vsim2_x";
> +				regulator-min-microvolt = <2700000>;
> +				regulator-max-microvolt = <2760000>;
> +				regulator-enable-ramp-delay = <540>;
> +			};
> +
> +			mt6366_vsram_gpu_reg: vsram-gpu {
> +				regulator-name = "pp0900_dvdd_sram_gpu";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <1050000>;
> +				regulator-ramp-delay = <6250>;
> +				regulator-enable-ramp-delay = <240>;
> +				regulator-coupled-with = <&mt6366_vgpu_reg>;
> +				regulator-coupled-max-spread = <10000>;
> +			};
> +
> +			mt6366_vsram_others_reg: vsram-others {
> +				regulator-name = "pp0900_dvdd_sram_core";
> +				regulator-min-microvolt = <900000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-ramp-delay = <6250>;
> +				regulator-enable-ramp-delay = <240>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vsram_proc11_reg: vsram-proc11 {
> +				regulator-name = "pp0900_dvdd_sram_bc";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <1120000>;
> +				regulator-ramp-delay = <6250>;
> +				regulator-enable-ramp-delay = <240>;
> +				regulator-always-on;
> +			};
> +
> +			mt6366_vsram_proc12_reg: vsram-proc12 {
> +				regulator-name = "pp0900_dvdd_sram_lc";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <1120000>;
> +				regulator-ramp-delay = <6250>;
> +				regulator-enable-ramp-delay = <240>;
> +				regulator-always-on;
> +			};
> +
> +			vusb {
> +				regulator-name = "pp3070_vusb";
> +				regulator-min-microvolt = <3000000>;
> +				regulator-max-microvolt = <3070000>;
> +				regulator-enable-ramp-delay = <270>;
> +				regulator-always-on;
> +			};
> +
> +			vxo22 {
> +				regulator-name = "pp2240_vxo22";
> +				regulator-min-microvolt = <2200000>;
> +				regulator-max-microvolt = <2240000>;
> +				regulator-enable-ramp-delay = <120>;
> +				/* Feeds DCXO internally */
> +				regulator-always-on;
> +			};
> +		};
> +
> +		rtc {
> +			compatible = "mediatek,mt6366-rtc", "mediatek,mt6358-rtc";
> +		};
> +	};
> +};
> +
> +&scp {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&scp_pins>;
> +	firmware-name = "mediatek/mt8186/scp.img";
> +	memory-region = <&scp_mem>;
> +	status = "okay";
> +
> +	cros-ec-rpmsg {
> +		compatible = "google,cros-ec-rpmsg";
> +		mediatek,rpmsg-name = "cros-ec-rpmsg";
> +	};
> +};
> +
> +&spi1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi1_pins>;
> +	mediatek,pad-select = <0>;
> +	status = "okay";
> +
> +	cros_ec: ec at 0 {
> +		compatible = "google,cros-ec-spi";
> +		reg = <0>;
> +		spi-max-frequency = <1000000>;
> +		interrupts-extended = <&pio 13 IRQ_TYPE_LEVEL_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&ec_ap_int>;
> +
> +		i2c_tunnel: i2c-tunnel {
> +			compatible = "google,cros-ec-i2c-tunnel";
> +			google,remote-bus = <1>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		typec {
> +			compatible = "google,cros-ec-typec";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			usb_c0: connector at 0 {
> +				compatible = "usb-c-connector";
> +				reg = <0>;
> +				label = "left";
> +				power-role = "dual";
> +				data-role = "host";
> +				try-power-role = "source";
> +
> +				ports {
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +
> +					port at 1 {
> +						reg = <1>;
> +
> +						typec_port0: endpoint { };
> +					};
> +				};
> +			};
> +
> +			usb_c1: connector at 1 {
> +				compatible = "usb-c-connector";
> +				reg = <1>;
> +				label = "right";
> +				power-role = "dual";
> +				data-role = "host";
> +				try-power-role = "source";
> +
> +				ports {
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +
> +					port at 1 {
> +						reg = <1>;
> +
> +						typec_port1: endpoint { };
> +					};
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&spi2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi2_pins>;
> +	cs-gpios = <&pio 45 GPIO_ACTIVE_LOW>;
> +	mediatek,pad-select = <0>;
> +	status = "okay";
> +
> +	tpm at 0 {
> +		compatible = "google,cr50";
> +		reg = <0>;
> +		spi-max-frequency = <1000000>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gsc_int>;
> +		interrupt-parent = <&pio>;
> +		interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> +	};
> +};
> +
> +&ssusb0 {
> +	status = "okay";
> +};
> +
> +&ssusb1 {
> +	status = "okay";
> +};
> +
> +&u3phy0 {
> +	status = "okay";
> +};
> +
> +&u3phy1 {
> +	status = "okay";
> +};
> +
> +&uart0 {
> +	status = "okay";
> +};
> +
> +&usb_host0 {
> +	vbus-supply = <&pp3300_s3>;
> +	status = "okay";
> +};
> +
> +&usb_host1 {
> +	vbus-supply = <&usb_p1_vbus>;
> +	status = "okay";
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +};
> +
> +&watchdog {
> +	mediatek,reset-by-toprgu;
> +};
> +
> +#include <arm/cros-ec-keyboard.dtsi>
> +#include <arm/cros-ec-sbs.dtsi>



From sudeep.holla at arm.com  Mon Dec  4 03:58:06 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon, 4 Dec 2023 11:58:06 +0000
Subject: [PATCH V2 6/7] coresight: stm: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <0adc3a16-0fc4-2a25-cd48-4667881b9490@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-7-anshuman.khandual@arm.com>
 <0adc3a16-0fc4-2a25-cd48-4667881b9490@arm.com>
Message-ID: <ZW2-zuTtV5GxaiFH@bogus>

On Mon, Dec 04, 2023 at 10:23:49AM +0000, James Clark wrote:
> 
> On 01/12/2023 06:20, Anshuman Khandual wrote:
> > Add support for the stm devices in the platform driver, which can then be
> > used on ACPI based platforms. This change would now allow runtime power
> > management for ACPI based systems. The driver would try to enable the APB
> > clock if available.
> > 
> > Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> > Cc: Sudeep Holla <sudeep.holla at arm.com>
> > Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> > Cc: Mike Leach <mike.leach at linaro.org>
> > Cc: James Clark <james.clark at arm.com>
> > Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> > Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> > Cc: linux-acpi at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-kernel at vger.kernel.org
> > Cc: coresight at lists.linaro.org
> > Cc: linux-stm32 at st-md-mailman.stormreply.com
> > Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> > ---
> [...]
> >  
> > -module_amba_driver(stm_driver);
> > +static int stm_platform_probe(struct platform_device *pdev)
> > +{
> > +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	int ret = 0;
> > +
> > +	pm_runtime_get_noresume(&pdev->dev);
> > +	pm_runtime_set_active(&pdev->dev);
> > +	pm_runtime_enable(&pdev->dev);
> > +
> > +	ret = __stm_probe(&pdev->dev, res, NULL);
> 
> Very minor nit, but this used to print this:
> 
>   coresight stm0: STM500 initialized
> 
> And now it prints this:
> 
>   coresight stm0: (null) initialized
> 
> (null) kind of makes it look a little bit like something has gone wrong.
> Maybe we could just put "initialised" if you don't have a string from ACPI?

Ah right, I too noticed this and forgot to mention. Just add a generic
"STM" string for ACPI if we don't have a way to identify exact IP ?

--
Regards,
Sudeep


From mark.rutland at arm.com  Mon Dec  4 03:58:47 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon,  4 Dec 2023 11:58:47 +0000
Subject: [PATCH] drivers/perf: pmuv3: don't expose SW_INCR event in sysfs
Message-ID: <20231204115847.2993026-1-mark.rutland@arm.com>

The SW_INCR event is somewhat unusual, and depends on the specific HW
counter that it is programmed into. When programmed into PMEVCNTR<n>,
SW_INCR will count any writes to PMSWINC_EL0 with bit n set, ignoring
writes to SW_INCR with bit n clear.

Event rotation means that there's no fixed relationship between
perf_events and HW counters, so this isn't all that useful.

Further, we program PMUSERENR.{SW,EN}=={0,0}, which causes EL0 writes to
PMSWINC_EL0 to be trapped and handled as UNDEFINED, resulting in a
SIGILL to userspace.

Given that, it's not a good idea to expose SW_INCR in sysfs. Hide it as
we did for CHAIN back in commit:

  4ba2578fa7b55701 ("arm64: perf: don't expose CHAIN event in sysfs")

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Will Deacon <will at kernel.org>
---
 drivers/perf/arm_pmuv3.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 6ca7be05229c1..0e80fdc9f9cad 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -169,7 +169,11 @@ armv8pmu_events_sysfs_show(struct device *dev,
 	PMU_EVENT_ATTR_ID(name, armv8pmu_events_sysfs_show, config)
 
 static struct attribute *armv8_pmuv3_event_attrs[] = {
-	ARMV8_EVENT_ATTR(sw_incr, ARMV8_PMUV3_PERFCTR_SW_INCR),
+	/*
+	 * Don't expose the sw_incr event in /sys. It's not usable as writes to
+	 * PMSWINC_EL0 will trap as PMUSERENR.{SW,EN}=={0,0} and event rotation
+	 * means we don't have a fixed event<->counter relationship regardless.
+	 */
 	ARMV8_EVENT_ATTR(l1i_cache_refill, ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL),
 	ARMV8_EVENT_ATTR(l1i_tlb_refill, ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL),
 	ARMV8_EVENT_ATTR(l1d_cache_refill, ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL),
-- 
2.30.2



From naresh.kamboju at linaro.org  Mon Dec  4 04:03:26 2023
From: naresh.kamboju at linaro.org (Naresh Kamboju)
Date: Mon, 4 Dec 2023 17:33:26 +0530
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error: instruction
 variant requires ARMv6 or later
Message-ID: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>

Following build errors noticed on Linux next-20231204 tag with clang-nightly
for arm and arm64.

## Test Regressions (compared to next-20231201)
* arm64, build
  - clang-nightly-defconfig
  - clang-nightly-defconfig-40bc7ee5
  - clang-nightly-lkftconfig
  - clang-nightly-lkftconfig-kselftest

* arm, build
  - clang-nightly-allnoconfig
  - clang-nightly-axm55xx_defconfig
  - clang-nightly-bcm2835_defconfig
  - clang-nightly-clps711x_defconfig
  - clang-nightly-defconfig
  - clang-nightly-exynos_defconfig
  - clang-nightly-imx_v6_v7_defconfig
  - clang-nightly-keystone_defconfig
  - clang-nightly-lkftconfig
  - clang-nightly-lkftconfig-kselftest
  - clang-nightly-omap2plus_defconfig
  - clang-nightly-pxa910_defconfig
  - clang-nightly-s3c6400_defconfig
  - clang-nightly-s5pv210_defconfig
  - clang-nightly-sama5_defconfig
  - clang-nightly-shmobile_defconfig
  - clang-nightly-tinyconfig
  - clang-nightly-u8500_defconfig
  - clang-nightly-vexpress_defconfig


Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>


Build log on arm64:
---------
In file included from lib/vdso/gettimeofday.c:5:
In file included from include/vdso/datapage.h:135:
arch/arm64/include/asm/vdso/compat_gettimeofday.h:152:15: error:
instruction variant requires ARMv6 or later
  152 |         asm volatile("mov %0, %1" : "=r"(ret) : "r"(_vdso_data));
      |                      ^
<inline asm>:1:2: note: instantiated into assembly here
    1 |         mov r4, r1
      |         ^
In file included from <built-in>:3:
lib/vdso/gettimeofday.c:139:3: error: invalid instruction
  139 |                 smp_rmb();
      |                 ^

Build log on arm:
---------
In file included from arch/arm/vfp/vfpmodule.c:23:
arch/arm/include/asm/cp15.h:101:2: error: instruction requires: data-barriers
  101 |         isb();
      |         ^


Links:
arm64
 - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20231204/testrun/21471527/suite/build/test/clang-nightly-defconfig/details/

arm
 - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20231204/testrun/21471941/suite/build/test/clang-nightly-exynos_defconfig/log
 - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20231204/testrun/21471941/suite/build/test/clang-nightly-exynos_defconfig/details/



--
Linaro LKFT
https://lkft.linaro.org


From naresh.kamboju at linaro.org  Mon Dec  4 04:08:36 2023
From: naresh.kamboju at linaro.org (Naresh Kamboju)
Date: Mon, 4 Dec 2023 17:38:36 +0530
Subject: arm: gcc-8: drivers/pinctrl/mediatek/../core.h:211:21: error:
 initializer element is not constant (struct group_desc)
Message-ID: <CA+G9fYs1g2Pt=DQeaJC+3ZJTeMwKAs9GuGJ9k6BcwKwEXcn5kQ@mail.gmail.com>

Following build errors noticed on Linux next-20231204 tag with gcc-8 toolchain
for arm and arm64.

## Test Regressions (compared to next-20231201)
* arm, build
  - gcc-8-defconfig

* arm64, build
  - gcc-8-defconfig

Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>

Build log arm and arm64:
------------
In file included from drivers/pinctrl/mediatek/pinctrl-moore.h:21,
                 from drivers/pinctrl/mediatek/pinctrl-mt7623.c:11:
drivers/pinctrl/mediatek/../core.h:211:21: error: initializer element
is not constant
 (struct group_desc) {      \
                     ^

Links:
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2Z43zPIMN6vxVKd9rKJFdOKXpox/
 - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20231204/testrun/21472198/suite/build/test/gcc-8-defconfig/details/
 - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20231204/testrun/21472585/suite/build/test/gcc-8-defconfig/details/
 - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20231204/testrun/21472800/suite/build/test/gcc-8-defconfig/history/

Steps to reproduce:
---------------
# tuxmake --runtime podman --target-arch arm64 --toolchain gcc-8
--kconfig defconfig



--
Linaro LKFT
https://lkft.linaro.org


From angelogioacchino.delregno at collabora.com  Mon Dec  4 04:13:04 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 13:13:04 +0100
Subject: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
References: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
Message-ID: <d03bf5b8-d4d7-4080-9af4-17b31ef6c72b@collabora.com>

Il 03/12/23 18:46, Krzysztof Kozlowski ha scritto:
> Document preferred coding style for Devicetree sources (DTS and DTSI),
> to bring consistency among all (sub)architectures and ease in reviews.
> 
> Cc: Andrew Davis <afd at ti.com>
> cc: Andrew Lunn <andrew at lunn.ch>
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Bjorn Andersson <andersson at kernel.org>
> Cc: Chen-Yu Tsai <wens at kernel.org>
> Cc: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> Cc: Jonathan Corbet <corbet at lwn.net>
> Cc: Matthias Brugger <matthias.bgg at gmail.com>
> Cc: Michal Simek <michal.simek at amd.com>
> Cc: Neil Armstrong <neil.armstrong at linaro.org>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Olof Johansson <olof at lixom.net>
> Cc: Rafa? Mi?ecki <zajec5 at gmail.com>
> Acked-by: Neil Armstrong <neil.armstrong at linaro.org>
> Acked-by: Heiko Stuebner <heiko at sntech.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Acked-by: Konrad Dybcio <konradybcio at kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>

Thumbs up!


From donald.robson at imgtec.com  Mon Dec  4 04:15:22 2023
From: donald.robson at imgtec.com (Donald Robson)
Date: Mon,  4 Dec 2023 12:15:22 +0000
Subject: [PATCH] arm64: dts: ti: k3-am62-main: Add GPU device node
Message-ID: <20231204121522.47862-1-donald.robson@imgtec.com>

From: Sarah Walker <sarah.walker at imgtec.com>

Add the Series AXE GPU node to the AM62 device tree.

Signed-off-by: Sarah Walker <sarah.walker at imgtec.com>
Signed-off-by: Donald Robson <donald.robson at imgtec.com>
---
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index e5c64c86d1d5..4338fd8ab2d7 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -965,4 +965,13 @@ mcasp2: audio-controller at 2b20000 {
 		power-domains = <&k3_pds 192 TI_SCI_PD_EXCLUSIVE>;
 		status = "disabled";
 	};
+
+	gpu: gpu at fd00000 {
+		compatible = "ti,am62-gpu", "img,img-axe";
+		reg = <0x00 0x0fd00000 0x00 0x20000>;
+		clocks = <&k3_clks 187 0>;
+		clock-names = "core";
+		interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+		power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>;
+	};
 };
-- 
2.25.1



From broonie at kernel.org  Mon Dec  4 04:18:26 2023
From: broonie at kernel.org (Mark Brown)
Date: Mon, 4 Dec 2023 12:18:26 +0000
Subject: [PATCH V15 1/8] arm64/sysreg: Add BRBE registers and fields
In-Reply-To: <86f91d68-207d-40a5-9d76-1cbb80e4f210@arm.com>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
 <20231201053906.1261704-2-anshuman.khandual@arm.com>
 <fd278f4e-0632-4474-8609-7711ad725f85@sirena.org.uk>
 <86f91d68-207d-40a5-9d76-1cbb80e4f210@arm.com>
Message-ID: <85fdf472-d979-4b11-95fb-5a738aa2bb9c@sirena.org.uk>

On Mon, Dec 04, 2023 at 09:33:56AM +0530, Anshuman Khandual wrote:
> On 12/1/23 22:28, Mark Brown wrote:
> > On Fri, Dec 01, 2023 at 11:08:59AM +0530, Anshuman Khandual wrote:

> >> +SysregFields BRBINFx_EL1
> >> +Enum	13:8		TYPE

> > DDI0601 2023-09 also defines 0b110000 as an IMPLEMENTATION DEFINED
> > exception to EL3.

> Should this field be just IMPDEF or IMPDEF_TRAP_EL3 sounds better ?

I don't have a strong opinon either way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/5744b699/attachment.sig>

From gregkh at linuxfoundation.org  Sun Dec  3 23:07:47 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 4 Dec 2023 08:07:47 +0100
Subject: [PATCH v2 1/2] staging: vc04_services: Use %p to log pointer
 address
In-Reply-To: <20231128202007.489294-2-umang.jain@ideasonboard.com>
References: <20231128202007.489294-1-umang.jain@ideasonboard.com>
 <20231128202007.489294-2-umang.jain@ideasonboard.com>
Message-ID: <2023120430-calibrate-defender-cee4@gregkh>

On Wed, Nov 29, 2023 at 01:50:06AM +0530, Umang Jain wrote:
> Solves the following Smatch warnings:
> service_callback() warn: argument 7 to %lx specifier is cast from pointer
> service_callback() warn: argument 11 to %lx specifier is cast from pointer
> service_callback() warn: argument 12 to %lx specifier is cast from pointer
> service_callback() warn: argument 13 to %lx specifier is cast from pointer
> 
> %p will print the hashed pointer to dynamic debug.
> In order to print the unmodified pointer address, one can use the
> `no_hash_pointers` via kernel parameters.
> 
> Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
> ---
>  .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c  | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)

Does not apply to my tree, is it because I just took your other patch?

thanks,

greg k-h


From gregkh at linuxfoundation.org  Sun Dec  3 23:08:27 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 4 Dec 2023 08:08:27 +0100
Subject: [PATCH v2 0/2] staging: vc04_services: Use %p to log pointer
In-Reply-To: <20231128202007.489294-1-umang.jain@ideasonboard.com>
References: <20231128202007.489294-1-umang.jain@ideasonboard.com>
Message-ID: <2023120459-irregular-cost-1785@gregkh>

On Wed, Nov 29, 2023 at 01:50:05AM +0530, Umang Jain wrote:
> %lx is used to print the unmodified pointer address for debugging.
> %p will print the hashed pointer address to avoid leaking information
> about kernel memory layout to userspace. But when `no_hash_pointers`
> is passed as kernel parameter, unmodified pointer address will be
> printed.
> 
> Hence, drop %lx in favour of %p. For debugging purposes, one can
> easily depend on `no_hash_pointers`.
> 
> This also solves the following smatch warnings:
> service_callback() warn: argument 7 to %lx specifier is cast from pointer
> service_callback() warn: argument 11 to %lx specifier is cast from pointer
> service_callback() warn: argument 12 to %lx specifier is cast from pointer
> service_callback() warn: argument 13 to %lx specifier is cast from pointer
> vchiq_release() warn: argument 7 to %lx specifier is cast from pointer
> 
> Changes in v2:
> - Built/Rebased on top of:
>   [PATCH v2 0/5] staging: vc04_services: Drop custom logging
> 
> Umang Jain (2):
>   staging: vc04_services: Use %p to log pointer address
>   staging: vc04_services: Use %p to log pointer address

You have 2 different patches that do different things, yet have the
identical subject lines.  That needs to be fixed up before I can take
them.

thanks,

greg k-h


From broonie at kernel.org  Mon Dec  4 04:33:49 2023
From: broonie at kernel.org (Mark Brown)
Date: Mon, 04 Dec 2023 12:33:49 +0000
Subject: [PATCH v2 00/10] ASoC: Convert Cirrus codecs to GPIO
 descriptors
In-Reply-To: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
References: <20231201-descriptors-sound-cirrus-v2-0-ee9f9d4655eb@linaro.org>
Message-ID: <170169322951.40199.8768531493970964376.b4-ty@kernel.org>

On Fri, 01 Dec 2023 14:20:29 +0100, Linus Walleij wrote:
> This series walks over the Cirrus Logic ASoC drivers and
> clean out the use of legacy GPIO numbers and legacy
> GPIO APIs.
> 
> The CS4271 affects an ASoC driver for EP93xx which Nikita is
> actively working on moving over to device tree, so I don't
> know about that patch specifically, but I think the collision
> would be max "the file was deleted".
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[01/10] ASoC: cs35l32: Drop legacy include
        commit: f8dd1f89bd5ecbfcc547ee5b222a4b9ddb0a0160
[02/10] ASoC: cs35l33: Fix GPIO name and drop legacy include
        commit: 50678d339d670a92658e5538ebee30447c88ccb3
[03/10] ASoC: cs35l34: Fix GPIO name and drop legacy include
        commit: a6122b0b4211d132934ef99e7b737910e6d54d2f
[04/10] ASoC: cs35l35: Drop legacy includes
        commit: 490d2d9f190a9a6125495ac4d833fa0af41763d0
[05/10] ASoC: cs35l36: Drop legacy includes
        commit: 194ef700d4e255686173a03b65e15cac637cc15a
[06/10] ASoC: cs4271: Convert to GPIO descriptors
        commit: 42d1178d223ba9498c1ed40a5fc243a43d35ec97
[07/10] ASoC: cirrus: edb93xx: Drop legacy include
        commit: b191a524b225a3acd7528c3fa8ebeb15302c979b
[08/10] ASoC: cs42l42: Drop legacy include
        commit: 0ec65e8e2219a91987cbb041387d94d40cab38b2
[09/10] ASoC: cs43130: Drop legacy includes
        commit: c6324cafd8370c2254f90a33b7327c45e7a58bbd
[10/10] ASoC: cs4349: Drop legacy include
        commit: 9c16cfe42d9fbfd258a3928b4a054d6b3ef932b0

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From krzk at kernel.org  Mon Dec  4 04:38:14 2023
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 13:38:14 +0100
Subject: [PATCH v4 12/23] pinctrl: mediatek: Make use of
 PINCTRL_GROUP_DESC()
In-Reply-To: <6161d2f2-f112-4a53-8e6b-0956c0fa2cbe@samsung.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
 <CGME20231204114016eucas1p2689bcb5a8e754555ae5821ac6cabe7e9@eucas1p2.samsung.com>
 <6161d2f2-f112-4a53-8e6b-0956c0fa2cbe@samsung.com>
Message-ID: <2af7b90c-797c-4557-8186-bebe23a69ce6@kernel.org>

On 04/12/2023 12:40, Marek Szyprowski wrote:
> On 29.11.2023 17:06, Andy Shevchenko wrote:
>> Make use of PINCTRL_GROUP_DESC() instead of open coding it.
>>
>> Signed-off-by: Andy Shevchenko<andriy.shevchenko at linux.intel.com>
> 
> This patch landed in linux-next as commit 1949e4630c3b ("pinctrl: 
> mediatek: Make use of PINCTRL_GROUP_DESC()"). Unfortunately it causes a 
> build break of ARM64 arch with standard defconfig.

Not only arm64, but also arm32. Defconfigs, so something completely
standard. This wasn't compiled which is quite surprising because cross
building defconfigs is trivial, not even mentioning testing your trees
with LKP. :(

https://lore.kernel.org/all/ed981149-5d96-43a9-9534-c1e52443a983 at linaro.org/

Best regards,
Krzysztof



From broonie at kernel.org  Mon Dec  4 04:43:42 2023
From: broonie at kernel.org (Mark Brown)
Date: Mon, 4 Dec 2023 12:43:42 +0000
Subject: [PATCH] spi: stm32: enable controller before asserting CS
In-Reply-To: <ZWpoKEcM0ZeYAsBa@dell-precision-5540>
References: <20231201214014.2539031-1-ben.wolsieffer@hefring.com>
 <b070eb2a-05d7-4e6a-8de9-15179045d192@sirena.org.uk>
 <ZWpoKEcM0ZeYAsBa@dell-precision-5540>
Message-ID: <9aa5e049-bd1c-41a6-b9b8-037ebb4f54b8@sirena.org.uk>

On Fri, Dec 01, 2023 at 06:11:36PM -0500, Ben Wolsieffer wrote:
> On Fri, Dec 01, 2023 at 09:50:33PM +0000, Mark Brown wrote:
> > On Fri, Dec 01, 2023 at 04:40:14PM -0500, Ben Wolsieffer wrote:

> > This feels like it'd be a good fit for moving to runtime PM - that way
> > we avoid bouncing the controller on and off between messages which is
> > probably better anyway.  The driver already does pinctrl management for
> > the device there.

> Yes, that probably makes sense. There are a few bits that can only be
> configured while the controller is disabled, but it doesn't look like
> that applies to any of the ones set in stm32_spi_prepare_msg().

> I'm a little hesitant to make big changes to the driver since I can only
> test them on an STM32F7 though.

It doesn't seem much more complex than what you're already proposing.

> > It also occurs to me that this isn't going to work for devices which
> > chip select inverted - for them we can't stop driving chip select at all
> > since they need it held high when idle.  There aren't that many such
> > devices and it'd loose us the PM which is rather awkward...  I guess
> > that's an incremental issue with a more invasive fix though.

> The driver only supports GPIO chip select rather than native, so I don't
> think this is a problem. Also, I don't think there's any difference

So mentioning the drive seems a bit confusing then?

> between inverted or uninverted here. They both either need to be driven
> all the time or have pull-up/downs.

It's a lot more likely you'll get away with things one way or another
for a missing pull down.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/b508d370/attachment.sig>

From robin.murphy at arm.com  Mon Dec  4 04:54:53 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 4 Dec 2023 12:54:53 +0000
Subject: [PATCH 7/7] dma-mapping: Simplify arch_setup_dma_ops()
In-Reply-To: <20231204084440.GB919@lst.de>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <590a4a1b7d10fb9bb1c42ca6cd438e98e6cc94a7.1701268753.git.robin.murphy@arm.com>
 <20231204084440.GB919@lst.de>
Message-ID: <4c55f016-ae17-4ba1-aa39-3b96f11bdb5a@arm.com>

On 04/12/2023 8:44 am, Christoph Hellwig wrote:
> On Wed, Nov 29, 2023 at 05:43:04PM +0000, Robin Murphy wrote:
>> The dma_base, size and iommu arguments are only used by ARM, and can
>> now easily be deduced from the device itself, so there's no need to pass
>> them through the callchain as well.
> 
> This looks even better than the patch form Jason that only removed the
> iommu argument:
> 
> Reviewed-by: Christoph Hellwig <hch at lst.de>
> 
> I wonder if it makes sense to also remove the coherent argument
> by setting up dev->dma_coherent in the caller.  That would require
> a pretty careful audit as we're doing a few weird things in that
> area, though.

Yeah, it crossed my mind too, but then I remembered we have at least the 
ARM stuff which may have already set a platform-specific value for 
dev->dma_coherent to take precedence over the firmware value, thus still 
needs to differentiate between the two at this point. Leaving the 
established argument in place seems neater IMO than having to go back to 
arch-specific mechanisms for that and any other similar tricks.

Thanks,
Robin.


From konrad.dybcio at linaro.org  Mon Dec  4 04:55:20 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Mon, 04 Dec 2023 13:55:20 +0100
Subject: [PATCH v2 1/6] dt-bindings: arm-smmu: Document SM8[45]50 GPU SMMU
In-Reply-To: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
Message-ID: <20231127-topic-a7xx_dt-v2-1-2a437588e563@linaro.org>

SM8450 and SM8550 both use a Qualcomm-modified MMU500 for their GPU.
In both cases, it requires a set of clocks to be enabled. Describe that.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
 .../devicetree/bindings/iommu/arm,smmu.yaml        | 48 +++++++++++++++++++++-
 1 file changed, 46 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index aa9e1c0895a5..19dba93a7654 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -89,6 +89,8 @@ properties:
               - qcom,sm8150-smmu-500
               - qcom,sm8250-smmu-500
               - qcom,sm8350-smmu-500
+              - qcom,sm8450-smmu-500
+              - qcom,sm8550-smmu-500
           - const: qcom,adreno-smmu
           - const: qcom,smmu-500
           - const: arm,mmu-500
@@ -453,6 +455,50 @@ allOf:
             - description: Voter clock required for HLOS SMMU access
             - description: Interface clock required for register access
 
+  - if:
+      properties:
+        compatible:
+          const: qcom,sm8450-smmu-500
+    then:
+      properties:
+        clock-names:
+          items:
+            - const: gmu
+            - const: hub
+            - const: hlos
+            - const: bus
+            - const: iface
+            - const: ahb
+
+        clocks:
+          items:
+            - description: GMU clock
+            - description: GPU HUB clock
+            - description: HLOS vote clock
+            - description: GPU memory bus clock
+            - description: GPU SNoC bus clock
+            - description: GPU AHB clock
+
+  - if:
+      properties:
+        compatible:
+          const: qcom,sm8550-smmu-500
+    then:
+      properties:
+        clock-names:
+          items:
+            - const: hlos
+            - const: bus
+            - const: iface
+            - const: ahb
+
+        clocks:
+          items:
+            - description: HLOS vote clock
+            - description: GPU memory bus clock
+            - description: GPU SNoC bus clock
+            - description: GPU AHB clock
+
   # Disallow clocks for all other platforms with specific compatibles
   - if:
       properties:
@@ -473,8 +519,6 @@ allOf:
               - qcom,sm6350-smmu-500
               - qcom,sm6375-smmu-500
               - qcom,sm8350-smmu-500
-              - qcom,sm8450-smmu-500
-              - qcom,sm8550-smmu-500
     then:
       properties:
         clock-names: false

-- 
2.43.0



From konrad.dybcio at linaro.org  Mon Dec  4 04:55:19 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Mon, 04 Dec 2023 13:55:19 +0100
Subject: [PATCH v2 0/6] SM8450 / SM8550 Adreno
Message-ID: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>

Following the merging of related bindings, driver and mesa changes, enable
the GPU on both of these platforms.

P1 for Will/iommu, rest for qcom

Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
Changes in v2:
- Sort nodes better in 8550dtsi
- Fix the 8550 GPU chip ID
- Pick up tags
- Link to v1: https://lore.kernel.org/r/20231127-topic-a7xx_dt-v1-0-a228b8122ebf at linaro.org

---
Konrad Dybcio (6):
      dt-bindings: arm-smmu: Document SM8[45]50 GPU SMMU
      arm64: dts: qcom: sm8450: Add GPU nodes
      arm64: dts: qcom: sm8550: Add GPU nodes
      arm64: dts: qcom: sm8550-qrd: Enable the A740 GPU
      arm64: dts: qcom: sm8550-mtp: Enable the A740 GPU
      arm64: dts: qcom: sm8450-hdk: Enable the A730 GPU

 .../devicetree/bindings/iommu/arm,smmu.yaml        |  48 ++++-
 arch/arm64/boot/dts/qcom/sm8450-hdk.dts            |   8 +
 arch/arm64/boot/dts/qcom/sm8450.dtsi               | 202 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sm8550-mtp.dts            |   8 +
 arch/arm64/boot/dts/qcom/sm8550-qrd.dts            |   8 +
 arch/arm64/boot/dts/qcom/sm8550.dtsi               | 166 +++++++++++++++++
 6 files changed, 438 insertions(+), 2 deletions(-)
---
base-commit: 629a3b49f3f957e975253c54846090b8d5ed2e9b
change-id: 20231127-topic-a7xx_dt-feee4142edda

Best regards,
-- 
Konrad Dybcio <konrad.dybcio at linaro.org>



From konrad.dybcio at linaro.org  Mon Dec  4 04:55:21 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Mon, 04 Dec 2023 13:55:21 +0100
Subject: [PATCH v2 2/6] arm64: dts: qcom: sm8450: Add GPU nodes
In-Reply-To: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
Message-ID: <20231127-topic-a7xx_dt-v2-2-2a437588e563@linaro.org>

Add the required nodes to support the A730 GPU.

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 202 +++++++++++++++++++++++++++++++++++
 1 file changed, 202 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index bde9c1093384..e9664672c160 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -8,6 +8,7 @@
 #include <dt-bindings/clock/qcom,rpmh.h>
 #include <dt-bindings/clock/qcom,sm8450-camcc.h>
 #include <dt-bindings/clock/qcom,sm8450-dispcc.h>
+#include <dt-bindings/clock/qcom,sm8450-gpucc.h>
 #include <dt-bindings/clock/qcom,sm8450-videocc.h>
 #include <dt-bindings/dma/qcom-gpi.h>
 #include <dt-bindings/firmware/qcom,scm.h>
@@ -18,6 +19,7 @@
 #include <dt-bindings/power/qcom-rpmpd.h>
 #include <dt-bindings/interconnect/qcom,icc.h>
 #include <dt-bindings/interconnect/qcom,sm8450.h>
+#include <dt-bindings/reset/qcom,sm8450-gpucc.h>
 #include <dt-bindings/soc/qcom,gpr.h>
 #include <dt-bindings/soc/qcom,rpmh-rsc.h>
 #include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
@@ -2019,6 +2021,206 @@ tcsr: syscon at 1fc0000 {
 			reg = <0x0 0x1fc0000 0x0 0x30000>;
 		};
 
+		gpu: gpu at 3d00000 {
+			compatible = "qcom,adreno-730.1", "qcom,adreno";
+			reg = <0x0 0x03d00000 0x0 0x40000>,
+			      <0x0 0x03d9e000 0x0 0x1000>,
+			      <0x0 0x03d61000 0x0 0x800>;
+			reg-names = "kgsl_3d0_reg_memory",
+				    "cx_mem",
+				    "cx_dbgc";
+
+			interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+			iommus = <&adreno_smmu 0 0x400>,
+				 <&adreno_smmu 1 0x400>;
+
+			operating-points-v2 = <&gpu_opp_table>;
+
+			qcom,gmu = <&gmu>;
+
+			status = "disabled";
+
+			zap-shader {
+				memory-region = <&gpu_micro_code_mem>;
+			};
+
+			gpu_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				opp-818000000 {
+					opp-hz = /bits/ 64 <818000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
+				};
+
+				opp-791000000 {
+					opp-hz = /bits/ 64 <791000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
+				};
+
+				opp-734000000 {
+					opp-hz = /bits/ 64 <734000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+				};
+
+				opp-640000000 {
+					opp-hz = /bits/ 64 <640000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_SVS_L2>;
+				};
+
+				opp-599000000 {
+					opp-hz = /bits/ 64 <599000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+				};
+
+				opp-545000000 {
+					opp-hz = /bits/ 64 <545000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_SVS_L0>;
+				};
+
+				opp-492000000 {
+					opp-hz = /bits/ 64 <492000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+				};
+
+				opp-421000000 {
+					opp-hz = /bits/ 64 <421000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L1>;
+				};
+
+				opp-350000000 {
+					opp-hz = /bits/ 64 <350000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+				};
+
+				opp-317000000 {
+					opp-hz = /bits/ 64 <317000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+				};
+
+				opp-285000000 {
+					opp-hz = /bits/ 64 <285000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+				};
+
+				opp-220000000 {
+					opp-hz = /bits/ 64 <220000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+				};
+			};
+		};
+
+		gmu: gmu at 3d6a000 {
+			compatible = "qcom,adreno-gmu-730.1", "qcom,adreno-gmu";
+			reg = <0x0 0x03d6a000 0x0 0x35000>,
+			      <0x0 0x03d50000 0x0 0x10000>,
+			      <0x0 0x0b290000 0x0 0x10000>;
+			reg-names = "gmu", "rscc", "gmu_pdc";
+
+			interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "hfi", "gmu";
+
+			clocks = <&gpucc GPU_CC_AHB_CLK>,
+				 <&gpucc GPU_CC_CX_GMU_CLK>,
+				 <&gpucc GPU_CC_CXO_CLK>,
+				 <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+				 <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+				 <&gpucc GPU_CC_HUB_CX_INT_CLK>,
+				 <&gpucc GPU_CC_DEMET_CLK>;
+			clock-names = "ahb",
+				      "gmu",
+				      "cxo",
+				      "axi",
+				      "memnoc",
+				      "hub",
+				      "demet";
+
+			power-domains = <&gpucc GPU_CX_GDSC>,
+					<&gpucc GPU_GX_GDSC>;
+			power-domain-names = "cx",
+					     "gx";
+
+			iommus = <&adreno_smmu 5 0x400>;
+
+			qcom,qmp = <&aoss_qmp>;
+
+			operating-points-v2 = <&gmu_opp_table>;
+
+			gmu_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				opp-500000000 {
+					opp-hz = /bits/ 64 <500000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+				};
+
+				opp-200000000 {
+					opp-hz = /bits/ 64 <200000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+				};
+			};
+		};
+
+		gpucc: clock-controller at 3d90000 {
+			compatible = "qcom,sm8450-gpucc";
+			reg = <0x0 0x03d90000 0x0 0xa000>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>,
+				 <&gcc GCC_GPU_GPLL0_CLK_SRC>,
+				 <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+			#power-domain-cells = <1>;
+		};
+
+		adreno_smmu: iommu at 3da0000 {
+			compatible = "qcom,sm8450-smmu-500", "qcom,adreno-smmu",
+				     "qcom,smmu-500", "arm,mmu-500";
+			reg = <0x0 0x03da0000 0x0 0x40000>;
+			#iommu-cells = <2>;
+			#global-interrupts = <1>;
+			interrupts = <GIC_SPI 673 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 678 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 679 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 680 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 681 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 682 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 683 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 684 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 685 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 686 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 687 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 476 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 574 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 575 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 576 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 577 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 659 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 661 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 664 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 665 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 666 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 668 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 669 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 699 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 700 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
+				 <&gpucc GPU_CC_HUB_CX_INT_CLK>,
+				 <&gpucc GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK>,
+				 <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+				 <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>,
+				 <&gpucc GPU_CC_AHB_CLK>;
+			clock-names = "gmu",
+				      "hub",
+				      "hlos",
+				      "bus",
+				      "iface",
+				      "ahb";
+			power-domains = <&gpucc GPU_CX_GDSC>;
+			dma-coherent;
+		};
+
 		usb_1_hsphy: phy at 88e3000 {
 			compatible = "qcom,sm8450-usb-hs-phy",
 				     "qcom,usb-snps-hs-7nm-phy";

-- 
2.43.0



From konrad.dybcio at linaro.org  Mon Dec  4 04:55:24 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Mon, 04 Dec 2023 13:55:24 +0100
Subject: [PATCH v2 5/6] arm64: dts: qcom: sm8550-mtp: Enable the A740 GPU
In-Reply-To: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
Message-ID: <20231127-topic-a7xx_dt-v2-5-2a437588e563@linaro.org>

Enable the GPU and provide a path for the ZAP blob.

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8550-mtp.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8550-mtp.dts b/arch/arm64/boot/dts/qcom/sm8550-mtp.dts
index 9a70875028b7..52244e9bfdee 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-mtp.dts
@@ -512,6 +512,14 @@ vreg_l3g_1p2: ldo3 {
 	};
 };
 
+&gpu {
+	status = "okay";
+
+	zap-shader {
+		firmware-name = "qcom/sm8550/a740_zap.mbn";
+	};
+};
+
 &i2c_master_hub_0 {
 	status = "okay";
 };

-- 
2.43.0



From konrad.dybcio at linaro.org  Mon Dec  4 04:55:22 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Mon, 04 Dec 2023 13:55:22 +0100
Subject: [PATCH v2 3/6] arm64: dts: qcom: sm8550: Add GPU nodes
In-Reply-To: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
Message-ID: <20231127-topic-a7xx_dt-v2-3-2a437588e563@linaro.org>

Add the required nodes to support the A740 GPU.

Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 166 +++++++++++++++++++++++++++++++++++
 1 file changed, 166 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 7bafb3d88d69..8f59085c804d 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -1984,6 +1984,128 @@ tcsr: clock-controller at 1fc0000 {
 			#reset-cells = <1>;
 		};
 
+		gpu: gpu at 3d00000 {
+			compatible = "qcom,adreno-43050a01", "qcom,adreno";
+			reg = <0x0 0x03d00000 0x0 0x40000>,
+			      <0x0 0x03d9e000 0x0 0x1000>,
+			      <0x0 0x03d61000 0x0 0x800>;
+			reg-names = "kgsl_3d0_reg_memory",
+				    "cx_mem",
+				    "cx_dbgc";
+
+			interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+			iommus = <&adreno_smmu 0 0x0>,
+				 <&adreno_smmu 1 0x0>;
+
+			operating-points-v2 = <&gpu_opp_table>;
+
+			qcom,gmu = <&gmu>;
+
+			status = "disabled";
+
+			zap-shader {
+				memory-region = <&gpu_micro_code_mem>;
+			};
+
+			/* Speedbin needs more work on A740+, keep only lower freqs */
+			gpu_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				opp-680000000 {
+					opp-hz = /bits/ 64 <680000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+				};
+
+				opp-615000000 {
+					opp-hz = /bits/ 64 <615000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_SVS_L0>;
+				};
+
+				opp-550000000 {
+					opp-hz = /bits/ 64 <550000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+				};
+
+				opp-475000000 {
+					opp-hz = /bits/ 64 <475000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L1>;
+				};
+
+				opp-401000000 {
+					opp-hz = /bits/ 64 <401000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+				};
+
+				opp-348000000 {
+					opp-hz = /bits/ 64 <348000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D0>;
+				};
+
+				opp-295000000 {
+					opp-hz = /bits/ 64 <295000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+				};
+
+				opp-220000000 {
+					opp-hz = /bits/ 64 <220000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D2>;
+				};
+			};
+		};
+
+		gmu: gmu at 3d6a000 {
+			compatible = "qcom,adreno-gmu-740.1", "qcom,adreno-gmu";
+			reg = <0x0 0x03d6a000 0x0 0x35000>,
+			      <0x0 0x03d50000 0x0 0x10000>,
+			      <0x0 0x0b280000 0x0 0x10000>;
+			reg-names = "gmu", "rscc", "gmu_pdc";
+
+			interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "hfi", "gmu";
+
+			clocks = <&gpucc GPU_CC_AHB_CLK>,
+				 <&gpucc GPU_CC_CX_GMU_CLK>,
+				 <&gpucc GPU_CC_CXO_CLK>,
+				 <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+				 <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+				 <&gpucc GPU_CC_HUB_CX_INT_CLK>,
+				 <&gpucc GPU_CC_DEMET_CLK>;
+			clock-names = "ahb",
+				      "gmu",
+				      "cxo",
+				      "axi",
+				      "memnoc",
+				      "hub",
+				      "demet";
+
+			power-domains = <&gpucc GPU_CC_CX_GDSC>,
+					<&gpucc GPU_CC_GX_GDSC>;
+			power-domain-names = "cx",
+					     "gx";
+
+			iommus = <&adreno_smmu 5 0x0>;
+
+			qcom,qmp = <&aoss_qmp>;
+
+			operating-points-v2 = <&gmu_opp_table>;
+
+			gmu_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				opp-500000000 {
+					opp-hz = /bits/ 64 <500000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+				};
+
+				opp-200000000 {
+					opp-hz = /bits/ 64 <200000000>;
+					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+				};
+			};
+		};
+
 		gpucc: clock-controller at 3d90000 {
 			compatible = "qcom,sm8550-gpucc";
 			reg = <0 0x03d90000 0 0xa000>;
@@ -1995,6 +2117,50 @@ gpucc: clock-controller at 3d90000 {
 			#power-domain-cells = <1>;
 		};
 
+		adreno_smmu: iommu at 3da0000 {
+			compatible = "qcom,sm8550-smmu-500", "qcom,adreno-smmu",
+				     "qcom,smmu-500", "arm,mmu-500";
+			reg = <0x0 0x03da0000 0x0 0x40000>;
+			#iommu-cells = <2>;
+			#global-interrupts = <1>;
+			interrupts = <GIC_SPI 673 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 677 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 678 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 679 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 680 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 681 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 682 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 683 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 684 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 685 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 686 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 687 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 476 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 574 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 575 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 576 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 577 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 659 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 661 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 664 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 665 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 666 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 668 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 669 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 699 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&gpucc GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK>,
+				 <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+				 <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>,
+				 <&gpucc GPU_CC_AHB_CLK>;
+			clock-names = "hlos",
+				      "bus",
+				      "iface",
+				      "ahb";
+			power-domains = <&gpucc GPU_CC_CX_GDSC>;
+			dma-coherent;
+		};
+
 		remoteproc_mpss: remoteproc at 4080000 {
 			compatible = "qcom,sm8550-mpss-pas";
 			reg = <0x0 0x04080000 0x0 0x4040>;

-- 
2.43.0



From konrad.dybcio at linaro.org  Mon Dec  4 04:55:23 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Mon, 04 Dec 2023 13:55:23 +0100
Subject: [PATCH v2 4/6] arm64: dts: qcom: sm8550-qrd: Enable the A740 GPU
In-Reply-To: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
Message-ID: <20231127-topic-a7xx_dt-v2-4-2a437588e563@linaro.org>

Enable the GPU and provide a path for the ZAP blob.

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
index eef811def39b..9fe51d308675 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
@@ -596,6 +596,14 @@ &gcc {
 		 <&usb_dp_qmpphy QMP_USB43DP_USB3_PIPE_CLK>;
 };
 
+&gpu {
+	status = "okay";
+
+	zap-shader {
+		firmware-name = "qcom/sm8550/a740_zap.mbn";
+	};
+};
+
 &lpass_tlmm {
 	spkr_1_sd_n_active: spkr-1-sd-n-active-state {
 		pins = "gpio17";

-- 
2.43.0



From konrad.dybcio at linaro.org  Mon Dec  4 04:55:25 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Mon, 04 Dec 2023 13:55:25 +0100
Subject: [PATCH v2 6/6] arm64: dts: qcom: sm8450-hdk: Enable the A730 GPU
In-Reply-To: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
Message-ID: <20231127-topic-a7xx_dt-v2-6-2a437588e563@linaro.org>

Enable the GPU and provide a path for the ZAP blob.

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8450-hdk.dts b/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
index 20153d08edde..a20d5d76af35 100644
--- a/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
@@ -580,6 +580,14 @@ &dispcc {
 	status = "okay";
 };
 
+&gpu {
+	status = "okay";
+
+	zap-shader {
+		firmware-name = "qcom/sm8450/a730_zap.mbn";
+	};
+};
+
 &i2c9 {
 	clock-frequency = <400000>;
 	status = "okay";

-- 
2.43.0



From neil.armstrong at linaro.org  Mon Dec  4 04:56:54 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 4 Dec 2023 13:56:54 +0100
Subject: [PATCH v2 4/6] arm64: dts: qcom: sm8550-qrd: Enable the A740 GPU
In-Reply-To: <20231127-topic-a7xx_dt-v2-4-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
 <20231127-topic-a7xx_dt-v2-4-2a437588e563@linaro.org>
Message-ID: <771bdf58-31ac-48b7-8b49-3034426634da@linaro.org>

On 04/12/2023 13:55, Konrad Dybcio wrote:
> Enable the GPU and provide a path for the ZAP blob.
> 
> Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>
> Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
> ---
>   arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
> index eef811def39b..9fe51d308675 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
> @@ -596,6 +596,14 @@ &gcc {
>   		 <&usb_dp_qmpphy QMP_USB43DP_USB3_PIPE_CLK>;
>   };
>   
> +&gpu {
> +	status = "okay";
> +
> +	zap-shader {
> +		firmware-name = "qcom/sm8550/a740_zap.mbn";
> +	};
> +};
> +
>   &lpass_tlmm {
>   	spkr_1_sd_n_active: spkr-1-sd-n-active-state {
>   		pins = "gpio17";
> 

Tested-by: Neil Armstrong <neil.armstrong at linaro.org> # on SM8550-QRD


From neil.armstrong at linaro.org  Mon Dec  4 04:57:03 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 4 Dec 2023 13:57:03 +0100
Subject: [PATCH v2 3/6] arm64: dts: qcom: sm8550: Add GPU nodes
In-Reply-To: <20231127-topic-a7xx_dt-v2-3-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
 <20231127-topic-a7xx_dt-v2-3-2a437588e563@linaro.org>
Message-ID: <b52212f4-39a9-474c-87ea-72f6d08a8388@linaro.org>

On 04/12/2023 13:55, Konrad Dybcio wrote:
> Add the required nodes to support the A740 GPU.
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
> ---
>   arch/arm64/boot/dts/qcom/sm8550.dtsi | 166 +++++++++++++++++++++++++++++++++++
>   1 file changed, 166 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index 7bafb3d88d69..8f59085c804d 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -1984,6 +1984,128 @@ tcsr: clock-controller at 1fc0000 {
>   			#reset-cells = <1>;
>   		};
>   
> +		gpu: gpu at 3d00000 {
> +			compatible = "qcom,adreno-43050a01", "qcom,adreno";
> +			reg = <0x0 0x03d00000 0x0 0x40000>,
> +			      <0x0 0x03d9e000 0x0 0x1000>,
> +			      <0x0 0x03d61000 0x0 0x800>;
> +			reg-names = "kgsl_3d0_reg_memory",
> +				    "cx_mem",
> +				    "cx_dbgc";
> +
> +			interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
> +
> +			iommus = <&adreno_smmu 0 0x0>,
> +				 <&adreno_smmu 1 0x0>;
> +
> +			operating-points-v2 = <&gpu_opp_table>;
> +
> +			qcom,gmu = <&gmu>;
> +
> +			status = "disabled";
> +
> +			zap-shader {
> +				memory-region = <&gpu_micro_code_mem>;
> +			};
> +
> +			/* Speedbin needs more work on A740+, keep only lower freqs */
> +			gpu_opp_table: opp-table {
> +				compatible = "operating-points-v2";
> +
> +				opp-680000000 {
> +					opp-hz = /bits/ 64 <680000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
> +				};
> +
> +				opp-615000000 {
> +					opp-hz = /bits/ 64 <615000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_SVS_L0>;
> +				};
> +
> +				opp-550000000 {
> +					opp-hz = /bits/ 64 <550000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
> +				};
> +
> +				opp-475000000 {
> +					opp-hz = /bits/ 64 <475000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L1>;
> +				};
> +
> +				opp-401000000 {
> +					opp-hz = /bits/ 64 <401000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
> +				};
> +
> +				opp-348000000 {
> +					opp-hz = /bits/ 64 <348000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D0>;
> +				};
> +
> +				opp-295000000 {
> +					opp-hz = /bits/ 64 <295000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
> +				};
> +
> +				opp-220000000 {
> +					opp-hz = /bits/ 64 <220000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D2>;
> +				};
> +			};
> +		};
> +
> +		gmu: gmu at 3d6a000 {
> +			compatible = "qcom,adreno-gmu-740.1", "qcom,adreno-gmu";
> +			reg = <0x0 0x03d6a000 0x0 0x35000>,
> +			      <0x0 0x03d50000 0x0 0x10000>,
> +			      <0x0 0x0b280000 0x0 0x10000>;
> +			reg-names = "gmu", "rscc", "gmu_pdc";
> +
> +			interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "hfi", "gmu";
> +
> +			clocks = <&gpucc GPU_CC_AHB_CLK>,
> +				 <&gpucc GPU_CC_CX_GMU_CLK>,
> +				 <&gpucc GPU_CC_CXO_CLK>,
> +				 <&gcc GCC_DDRSS_GPU_AXI_CLK>,
> +				 <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
> +				 <&gpucc GPU_CC_HUB_CX_INT_CLK>,
> +				 <&gpucc GPU_CC_DEMET_CLK>;
> +			clock-names = "ahb",
> +				      "gmu",
> +				      "cxo",
> +				      "axi",
> +				      "memnoc",
> +				      "hub",
> +				      "demet";
> +
> +			power-domains = <&gpucc GPU_CC_CX_GDSC>,
> +					<&gpucc GPU_CC_GX_GDSC>;
> +			power-domain-names = "cx",
> +					     "gx";
> +
> +			iommus = <&adreno_smmu 5 0x0>;
> +
> +			qcom,qmp = <&aoss_qmp>;
> +
> +			operating-points-v2 = <&gmu_opp_table>;
> +
> +			gmu_opp_table: opp-table {
> +				compatible = "operating-points-v2";
> +
> +				opp-500000000 {
> +					opp-hz = /bits/ 64 <500000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
> +				};
> +
> +				opp-200000000 {
> +					opp-hz = /bits/ 64 <200000000>;
> +					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
> +				};
> +			};
> +		};
> +
>   		gpucc: clock-controller at 3d90000 {
>   			compatible = "qcom,sm8550-gpucc";
>   			reg = <0 0x03d90000 0 0xa000>;
> @@ -1995,6 +2117,50 @@ gpucc: clock-controller at 3d90000 {
>   			#power-domain-cells = <1>;
>   		};
>   
> +		adreno_smmu: iommu at 3da0000 {
> +			compatible = "qcom,sm8550-smmu-500", "qcom,adreno-smmu",
> +				     "qcom,smmu-500", "arm,mmu-500";
> +			reg = <0x0 0x03da0000 0x0 0x40000>;
> +			#iommu-cells = <2>;
> +			#global-interrupts = <1>;
> +			interrupts = <GIC_SPI 673 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 677 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 678 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 679 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 680 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 681 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 682 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 683 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 684 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 685 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 686 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 687 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 476 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 574 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 575 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 576 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 577 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 659 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 661 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 664 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 665 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 666 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 668 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 669 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 699 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&gpucc GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK>,
> +				 <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
> +				 <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>,
> +				 <&gpucc GPU_CC_AHB_CLK>;
> +			clock-names = "hlos",
> +				      "bus",
> +				      "iface",
> +				      "ahb";
> +			power-domains = <&gpucc GPU_CC_CX_GDSC>;
> +			dma-coherent;
> +		};
> +
>   		remoteproc_mpss: remoteproc at 4080000 {
>   			compatible = "qcom,sm8550-mpss-pas";
>   			reg = <0x0 0x04080000 0x0 0x4040>;
> 

Tested-by: Neil Armstrong <neil.armstrong at linaro.org> # on SM8550-QRD


From neil.armstrong at linaro.org  Mon Dec  4 05:01:47 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 04 Dec 2023 14:01:47 +0100
Subject: [PATCH] arm64: defconfig: enable GPU clock controller for
 SM8[45]50
Message-ID: <20231204-topic-sm8x50-upstream-gpucc-defconfig-v1-1-e615df0c4af9@linaro.org>

Enable GPU Clock Controller for SM8450 and SM8550 to allow using
Adreno GPU on these SoCs.

Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
---
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5ad2b841aafc..56aebbdcdd40 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1266,6 +1266,8 @@ CONFIG_SM_TCSRCC_8550=y
 CONFIG_SM_GPUCC_6115=m
 CONFIG_SM_GPUCC_8150=y
 CONFIG_SM_GPUCC_8250=y
+CONFIG_SM_GPUCC_8450=y
+CONFIG_SM_GPUCC_8550=y
 CONFIG_SM_VIDEOCC_8250=y
 CONFIG_QCOM_HFPLL=y
 CONFIG_CLK_GFM_LPASS_SM8250=m

---
base-commit: 9046d05c6ad632a271fc4173624e26f396975a80
change-id: 20231204-topic-sm8x50-upstream-gpucc-defconfig-3e3dc264be08

Best regards,
-- 
Neil Armstrong <neil.armstrong at linaro.org>



From nm at ti.com  Mon Dec  4 05:08:46 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 07:08:46 -0600
Subject: [PATCH] arm64: dts: ti: k3-am62-main: Add GPU device node
In-Reply-To: <20231204121522.47862-1-donald.robson@imgtec.com>
References: <20231204121522.47862-1-donald.robson@imgtec.com>
Message-ID: <20231204130846.m4fhrphg7vfnky3f@brute>

On 12:15-20231204, Donald Robson wrote:
> From: Sarah Walker <sarah.walker at imgtec.com>
> 
> Add the Series AXE GPU node to the AM62 device tree.
> 
> Signed-off-by: Sarah Walker <sarah.walker at imgtec.com>
> Signed-off-by: Donald Robson <donald.robson at imgtec.com>
> ---
>  arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> index e5c64c86d1d5..4338fd8ab2d7 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> @@ -965,4 +965,13 @@ mcasp2: audio-controller at 2b20000 {
>  		power-domains = <&k3_pds 192 TI_SCI_PD_EXCLUSIVE>;
>  		status = "disabled";
>  	};
> +
> +	gpu: gpu at fd00000 {
> +		compatible = "ti,am62-gpu", "img,img-axe";
> +		reg = <0x00 0x0fd00000 0x00 0x20000>;
> +		clocks = <&k3_clks 187 0>;
> +		clock-names = "core";
> +		interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
> +		power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>;
> +	};
>  };
> -- 
> 2.25.1
> 

Please also add a patch to enable GPU in the default armv8 defconfig as a
kernel module.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From yuzenghui at huawei.com  Mon Dec  4 05:09:22 2023
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Mon, 4 Dec 2023 21:09:22 +0800
Subject: [PATCH v2 0/3] arm64: Drop support for VPIPT i-cache policy
In-Reply-To: <20231127172613.1490283-1-maz@kernel.org>
References: <20231127172613.1490283-1-maz@kernel.org>
Message-ID: <6f859b31-dcbe-148d-cfde-e6119553b072@huawei.com>

On 2023/11/28 1:26, Marc Zyngier wrote:
> ARMv8.2 introduced support for VPIPT i-caches, the V standing for
> VMID-tagged. Although this looks like a reasonable idea, no
> implementation has ever made it into the wild.
> 
> Linux has supported this for over 6 years (amusingly, just as the
> architecture was dropping support for AVIVT i-caches), but we had no
> way to even test it, and it is likely that this code was just
> bit-rotting.
> 
> However, in a recent breakthrough (XML drop 2023-09, tagged as
> d55f5af8e09052abe92a02adf820deea2eaed717), the architecture has
> finally been purged of this option, making VIPT and PIPT the only two
> valid options.
> 
> This really means this code is just dead code. Nobody will ever come
> up with such an implementation, and we can just get rid of it.
> 
> Most of the impact is on KVM, where we drop a few large comment blocks
> (and a bit of code), while the core arch code loses the detection code
> itself.
> 
> Marc Zyngier (3):
>   KVM: arm64: Remove VPIPT I-cache handling
>   arm64: Kill detection of VPIPT i-cache policy
>   arm64: Rename reserved values for CTR_EL0.L1Ip

Series looks good to me.  With Anshuman's comment addressed,

Reviewed-by: Zenghui Yu <yuzenghui at huawei.com>


From andriy.shevchenko at linux.intel.com  Mon Dec  4 05:10:05 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 4 Dec 2023 15:10:05 +0200
Subject: [PATCH v4 12/23] pinctrl: mediatek: Make use of
 PINCTRL_GROUP_DESC()
In-Reply-To: <9e4e65de-7234-4234-8091-796277a1f1c5@samsung.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
 <CGME20231204114039eucas1p29c6f8a162191e58ff658d3a1c44429bf@eucas1p2.samsung.com>
 <9e4e65de-7234-4234-8091-796277a1f1c5@samsung.com>
Message-ID: <ZW3PrSQWyZvvhN66@smile.fi.intel.com>

On Mon, Dec 04, 2023 at 12:40:38PM +0100, Marek Szyprowski wrote:
> On 29.11.2023 17:06, Andy Shevchenko wrote:
> > Make use of PINCTRL_GROUP_DESC() instead of open coding it.

> PINCTRL_GROUP_DESC() macro from drivers/pinctrl/core.h contains a cast
> to (struct group_desc), what breaks users of the above macros.

There is no cast (*).
Thanks for report, I will check.

But this was v4 of the series and LKP actually sent a positive feedback.
Besides that I have tested this locally with modules enabled.

*) It's a compound literal, _not_ a cast.
   Taking above into consideration I'm wondering what compilers
   are in use?

-- 
With Best Regards,
Andy Shevchenko




From james.clark at arm.com  Mon Dec  4 05:17:10 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 4 Dec 2023 13:17:10 +0000
Subject: [PATCH V2 6/7] coresight: stm: Move ACPI support from AMBA driver
 to platform driver
In-Reply-To: <e53cec31-9452-4c2a-a3a1-b6ef33be8e22@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-7-anshuman.khandual@arm.com>
 <0adc3a16-0fc4-2a25-cd48-4667881b9490@arm.com>
 <e53cec31-9452-4c2a-a3a1-b6ef33be8e22@arm.com>
Message-ID: <7825dcd4-94e1-7a5f-b388-90e748dfc47f@arm.com>



On 04/12/2023 11:50, Anshuman Khandual wrote:
> 
> 
> On 12/4/23 15:53, James Clark wrote:
>>
>>
>> On 01/12/2023 06:20, Anshuman Khandual wrote:
>>> Add support for the stm devices in the platform driver, which can then be
>>> used on ACPI based platforms. This change would now allow runtime power
>>> management for ACPI based systems. The driver would try to enable the APB
>>> clock if available.
>>>
>>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>>> Cc: Mike Leach <mike.leach at linaro.org>
>>> Cc: James Clark <james.clark at arm.com>
>>> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
>>> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
>>> Cc: linux-acpi at vger.kernel.org
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: linux-kernel at vger.kernel.org
>>> Cc: coresight at lists.linaro.org
>>> Cc: linux-stm32 at st-md-mailman.stormreply.com
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>> ---
>> [...]
>>>  
>>> -module_amba_driver(stm_driver);
>>> +static int stm_platform_probe(struct platform_device *pdev)
>>> +{
>>> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +	int ret = 0;
>>> +
>>> +	pm_runtime_get_noresume(&pdev->dev);
>>> +	pm_runtime_set_active(&pdev->dev);
>>> +	pm_runtime_enable(&pdev->dev);
>>> +
>>> +	ret = __stm_probe(&pdev->dev, res, NULL);
>>
>> Very minor nit, but this used to print this:
>>
>>   coresight stm0: STM500 initialized
>>
>> And now it prints this:
>>
>>   coresight stm0: (null) initialized
>>
>> (null) kind of makes it look a little bit like something has gone wrong.
>> Maybe we could just put "initialised" if you don't have a string from ACPI?
> 
> __stm_probe() gets called from both AMBA and platform driver paths. Even though
> a NULL check inside dev_info(..."%s initialized\n",...) could be added, but how
> to differentiate it from a scenario when coresight_get_uci_data() returns NULL ?

Sudeep's suggestion seems ok, just add a hard coded string instead of
the NULL. And keep the coresight_get_uci_data() the same.


From krzk at kernel.org  Mon Dec  4 05:18:56 2023
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 14:18:56 +0100
Subject: [PATCH v4 12/23] pinctrl: mediatek: Make use of
 PINCTRL_GROUP_DESC()
In-Reply-To: <ZW3PrSQWyZvvhN66@smile.fi.intel.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
 <CGME20231204114039eucas1p29c6f8a162191e58ff658d3a1c44429bf@eucas1p2.samsung.com>
 <9e4e65de-7234-4234-8091-796277a1f1c5@samsung.com>
 <ZW3PrSQWyZvvhN66@smile.fi.intel.com>
Message-ID: <b21b3f93-62d6-462b-8a2f-7b6f5532b417@kernel.org>

On 04/12/2023 14:10, Andy Shevchenko wrote:
> On Mon, Dec 04, 2023 at 12:40:38PM +0100, Marek Szyprowski wrote:
>> On 29.11.2023 17:06, Andy Shevchenko wrote:
>>> Make use of PINCTRL_GROUP_DESC() instead of open coding it.
> 
>> PINCTRL_GROUP_DESC() macro from drivers/pinctrl/core.h contains a cast
>> to (struct group_desc), what breaks users of the above macros.
> 
> There is no cast (*).
> Thanks for report, I will check.
> 
> But this was v4 of the series and LKP actually sent a positive feedback.
> Besides that I have tested this locally with modules enabled.
> 
> *) It's a compound literal, _not_ a cast.
>    Taking above into consideration I'm wondering what compilers
>    are in use?

In my case: standard provided by Ubuntu 22.04, so: gcc version 11.4.0
(Ubuntu 11.4.0-1ubuntu1~22.04)


Best regards,
Krzysztof



From geert at linux-m68k.org  Mon Dec  4 05:19:10 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 4 Dec 2023 14:19:10 +0100
Subject: [PATCH v4 12/23] pinctrl: mediatek: Make use of PINCTRL_GROUP_DESC()
In-Reply-To: <ZW3PrSQWyZvvhN66@smile.fi.intel.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
 <CGME20231204114039eucas1p29c6f8a162191e58ff658d3a1c44429bf@eucas1p2.samsung.com>
 <9e4e65de-7234-4234-8091-796277a1f1c5@samsung.com> <ZW3PrSQWyZvvhN66@smile.fi.intel.com>
Message-ID: <CAMuHMdU-E7jemjAS0EunWFPq1LfF9vcNE+50ah4WH9oD1TXYew@mail.gmail.com>

Hi Andy,

On Mon, Dec 4, 2023 at 2:10?PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
> On Mon, Dec 04, 2023 at 12:40:38PM +0100, Marek Szyprowski wrote:
> > On 29.11.2023 17:06, Andy Shevchenko wrote:
> > > Make use of PINCTRL_GROUP_DESC() instead of open coding it.
>
> > PINCTRL_GROUP_DESC() macro from drivers/pinctrl/core.h contains a cast
> > to (struct group_desc), what breaks users of the above macros.
>
> There is no cast (*).
> Thanks for report, I will check.
>
> But this was v4 of the series and LKP actually sent a positive feedback.
> Besides that I have tested this locally with modules enabled.
>
> *) It's a compound literal, _not_ a cast.
>    Taking above into consideration I'm wondering what compilers
>    are in use?

kisskb reported the following m68k failures to me:
    linux-next/m68k-allmodconfig/m68k-gcc8
    linux-next/m68k-allmodconfig/m68k-gcc11
    linux-next/m68k-allmodconfig/m68k-gcc12

However, according to [1], linux-next/m68k-allmodconfig/m68k-gcc13
did succeed, so I guess you are using gcc13?

[1] http://kisskb.ellerman.id.au/kisskb/head/629a3b49f3f957e975253c54846090b8d5ed2e9b/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From krzk at kernel.org  Mon Dec  4 05:20:10 2023
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 14:20:10 +0100
Subject: [PATCH v4 12/23] pinctrl: mediatek: Make use of
 PINCTRL_GROUP_DESC()
In-Reply-To: <b21b3f93-62d6-462b-8a2f-7b6f5532b417@kernel.org>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
 <CGME20231204114039eucas1p29c6f8a162191e58ff658d3a1c44429bf@eucas1p2.samsung.com>
 <9e4e65de-7234-4234-8091-796277a1f1c5@samsung.com>
 <ZW3PrSQWyZvvhN66@smile.fi.intel.com>
 <b21b3f93-62d6-462b-8a2f-7b6f5532b417@kernel.org>
Message-ID: <de0a2345-864c-4dff-b965-e6600983011a@kernel.org>

On 04/12/2023 14:18, Krzysztof Kozlowski wrote:
> On 04/12/2023 14:10, Andy Shevchenko wrote:
>> On Mon, Dec 04, 2023 at 12:40:38PM +0100, Marek Szyprowski wrote:
>>> On 29.11.2023 17:06, Andy Shevchenko wrote:
>>>> Make use of PINCTRL_GROUP_DESC() instead of open coding it.
>>
>>> PINCTRL_GROUP_DESC() macro from drivers/pinctrl/core.h contains a cast
>>> to (struct group_desc), what breaks users of the above macros.
>>
>> There is no cast (*).
>> Thanks for report, I will check.
>>
>> But this was v4 of the series and LKP actually sent a positive feedback.
>> Besides that I have tested this locally with modules enabled.
>>
>> *) It's a compound literal, _not_ a cast.
>>    Taking above into consideration I'm wondering what compilers
>>    are in use?
> 
> In my case: standard provided by Ubuntu 22.04, so: gcc version 11.4.0
> (Ubuntu 11.4.0-1ubuntu1~22.04)

This was from my local machine. The ones used on the server are
mentioned in one of the steps:

https://krzk.eu/#/builders/5/builds/2532/steps/5/logs/property_changes

Best regards,
Krzysztof



From nm at ti.com  Mon Dec  4 05:21:03 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 07:21:03 -0600
Subject: [PATCH] arm64: dts: ti: k3-am654-icssg2: Enable PHY interrupts
 for ICSSG2
In-Reply-To: <20231120063159.539306-1-s-vadapalli@ti.com>
References: <20231120063159.539306-1-s-vadapalli@ti.com>
Message-ID: <20231204132103.ikkxjz3yxz3ynq6s@demystify>

On 12:01-20231120, Siddharth Vadapalli wrote:
> Enable interrupt mode of operation of the DP83867 Ethernet PHY which is
> used by ICSSG2. The DP83867 PHY driver already supports interrupt handling
> for interrupts generated by the PHY. Thus, add the necessary device-tree
> support to enable it.
> 
> Since the GPIO1_87 line is muxed with EXT_REFCLK1 and SYNC1_OUT, update
> the pinmux to select GPIO1_87 for routing the interrupt.
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> ---
> 
> This patch is based on linux-next tagged next-20231120.
> 
> Regards,
> Siddharth.
> 
>  arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
> index ec8cf20ca3ac..9f723592d0f4 100644
> --- a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
> +++ b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
> @@ -124,21 +124,34 @@ AM65X_IOPAD(0x0088, PIN_INPUT, 2) /* (AG17) PRG2_PRU0_GPO4.PRG2_RGMII1_RX_CTL */
>  	};
>  };
>  
> +&main_pmx1 {
> +	/* Select GPIO1_87 for ICSSG2 PHY interrupt */
> +	icssg2_phy_irq_pins_default: icssg2-phy-irq-default-pins {
> +		pinctrl-single,pins = <
> +			AM65X_IOPAD(0x0014, PIN_INPUT, 7) /* (A22) EXT_REFCLK1.GPIO1_87 */
> +		>;
> +	};
> +};
> +
>  &icssg2_mdio {
>  	status = "okay";
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&icssg2_mdio_pins_default>;
> +	pinctrl-names = "default", "icssg2-phy-irq";
> +	pinctrl-0 = <&icssg2_mdio_pins_default>, <&icssg2_phy_irq_pins_default>;

why should the pins be part of mdio pinctrl instead of phy?

>  	#address-cells = <1>;
>  	#size-cells = <0>;
>  
>  	icssg2_phy0: ethernet-phy at 0 {
>  		reg = <0>;
> +		interrupt-parent = <&main_gpio1>;
> +		interrupts = <87 0x2>;
>  		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>  		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
>  	};
>  
>  	icssg2_phy1: ethernet-phy at 3 {
>  		reg = <3>;
> +		interrupt-parent = <&main_gpio1>;
> +		interrupts = <87 0x2>;

Shouldn't you be using macros for interrupt level like IRQ_TYPE_EDGE_FALLING?

>  		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>  		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
>  	};
> -- 
> 2.34.1
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From glider at google.com  Mon Dec  4 05:28:09 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 4 Dec 2023 14:28:09 +0100
Subject: [PATCH v12 1/3] lib/bitmap: add bitmap_{read,write}()
In-Reply-To: <20231109151106.2385155-1-glider@google.com>
References: <20231109151106.2385155-1-glider@google.com>
Message-ID: <CAG_fn=U7EV0ohaNFRwQ83cvwVn-Fer1pHXOjPevbP_XpYGDCYA@mail.gmail.com>

On Thu, Nov 9, 2023 at 4:11?PM Alexander Potapenko <glider at google.com> wrote:
>
> From: Syed Nayyar Waris <syednwaris at gmail.com>
>
> The two new functions allow reading/writing values of length up to
> BITS_PER_LONG bits at arbitrary position in the bitmap.
>
> The code was taken from "bitops: Introduce the for_each_set_clump macro"
> by Syed Nayyar Waris with a number of changes and simplifications:
>  - instead of using roundup(), which adds an unnecessary dependency
>    on <linux/math.h>, we calculate space as BITS_PER_LONG-offset;
>  - indentation is reduced by not using else-clauses (suggested by
>    checkpatch for bitmap_get_value());
>  - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read()
>    and bitmap_write();
>  - some redundant computations are omitted.
>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <william.gray at linaro.org>
> Link: https://lore.kernel.org/lkml/fe12eedf3666f4af5138de0e70b67a07c7f40338.1592224129.git.syednwaris at gmail.com/
> Suggested-by: Yury Norov <yury.norov at gmail.com>
> Co-developed-by: Alexander Potapenko <glider at google.com>
> Signed-off-by: Alexander Potapenko <glider at google.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

Yury, Andy, do you think anything else is needed for this series?
If not, whom should we ask to take it?


From geert+renesas at glider.be  Mon Dec  4 05:32:03 2023
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon,  4 Dec 2023 14:32:03 +0100
Subject: [PATCH] soc: renesas: Remove duplicate setup of soc_device_attribute.family
Message-ID: <4c5e4d0d1819028466748ed684254fec41aae816.1701696627.git.geert+renesas@glider.be>

As of commit 3f84aa5ec052dba9 ("base: soc: populate machine name in
soc_device_register if empty") in v6.4, soc_device_register() fills in
soc_device_attribute.family when it is still empty.  Hence the identical
code in renesas_soc_init() doing the same can be removed.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
To be queued in renesas-devel for v6.8.

 drivers/soc/renesas/renesas-soc.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
index 3d8e18923bddebf9..67de980ec4244c41 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -487,10 +487,6 @@ static int __init renesas_soc_init(void)
 		return -ENOMEM;
 	}
 
-	np = of_find_node_by_path("/");
-	of_property_read_string(np, "model", &soc_dev_attr->machine);
-	of_node_put(np);
-
 	soc_dev_attr->family = kstrdup_const(family->name, GFP_KERNEL);
 	soc_dev_attr->soc_id = kstrdup_const(soc_id, GFP_KERNEL);
 
-- 
2.34.1



From andriy.shevchenko at linux.intel.com  Mon Dec  4 05:32:23 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 4 Dec 2023 15:32:23 +0200
Subject: [PATCH v4 12/23] pinctrl: mediatek: Make use of
 PINCTRL_GROUP_DESC()
In-Reply-To: <CAMuHMdU-E7jemjAS0EunWFPq1LfF9vcNE+50ah4WH9oD1TXYew@mail.gmail.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
 <CGME20231204114039eucas1p29c6f8a162191e58ff658d3a1c44429bf@eucas1p2.samsung.com>
 <9e4e65de-7234-4234-8091-796277a1f1c5@samsung.com>
 <ZW3PrSQWyZvvhN66@smile.fi.intel.com>
 <CAMuHMdU-E7jemjAS0EunWFPq1LfF9vcNE+50ah4WH9oD1TXYew@mail.gmail.com>
Message-ID: <ZW3U5-LBqWiyxB6-@smile.fi.intel.com>

On Mon, Dec 04, 2023 at 02:19:10PM +0100, Geert Uytterhoeven wrote:
> Hi Andy,
> 
> On Mon, Dec 4, 2023 at 2:10?PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Mon, Dec 04, 2023 at 12:40:38PM +0100, Marek Szyprowski wrote:
> > > On 29.11.2023 17:06, Andy Shevchenko wrote:
> > > > Make use of PINCTRL_GROUP_DESC() instead of open coding it.
> >
> > > PINCTRL_GROUP_DESC() macro from drivers/pinctrl/core.h contains a cast
> > > to (struct group_desc), what breaks users of the above macros.
> >
> > There is no cast (*).
> > Thanks for report, I will check.
> >
> > But this was v4 of the series and LKP actually sent a positive feedback.
> > Besides that I have tested this locally with modules enabled.
> >
> > *) It's a compound literal, _not_ a cast.
> >    Taking above into consideration I'm wondering what compilers
> >    are in use?
> 
> kisskb reported the following m68k failures to me:
>     linux-next/m68k-allmodconfig/m68k-gcc8
>     linux-next/m68k-allmodconfig/m68k-gcc11
>     linux-next/m68k-allmodconfig/m68k-gcc12
> 
> However, according to [1], linux-next/m68k-allmodconfig/m68k-gcc13
> did succeed, so I guess you are using gcc13?

Yes, I compiled with these:

$ gcc --version
gcc (Debian 13.2.0-5) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang --version
Debian clang version 16.0.6 (16)
	Target: x86_64-pc-linux-gnu
	Thread model: posix
	InstalledDir: /usr/bin


-- 
With Best Regards,
Andy Shevchenko




From geert at linux-m68k.org  Mon Dec  4 05:39:37 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 4 Dec 2023 14:39:37 +0100
Subject: [PATCH v4 12/23] pinctrl: mediatek: Make use of PINCTRL_GROUP_DESC()
In-Reply-To: <ZW3U5-LBqWiyxB6-@smile.fi.intel.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
 <CGME20231204114039eucas1p29c6f8a162191e58ff658d3a1c44429bf@eucas1p2.samsung.com>
 <9e4e65de-7234-4234-8091-796277a1f1c5@samsung.com> <ZW3PrSQWyZvvhN66@smile.fi.intel.com>
 <CAMuHMdU-E7jemjAS0EunWFPq1LfF9vcNE+50ah4WH9oD1TXYew@mail.gmail.com> <ZW3U5-LBqWiyxB6-@smile.fi.intel.com>
Message-ID: <CAMuHMdVz=dLaBt-Td0UdOOs79ju7UfX_2vUcy8Kdeo9aSP+edw@mail.gmail.com>

Hi Andy,

On Mon, Dec 4, 2023 at 2:32?PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
> On Mon, Dec 04, 2023 at 02:19:10PM +0100, Geert Uytterhoeven wrote:
> > On Mon, Dec 4, 2023 at 2:10?PM Andy Shevchenko
> > <andriy.shevchenko at linux.intel.com> wrote:
> > > On Mon, Dec 04, 2023 at 12:40:38PM +0100, Marek Szyprowski wrote:
> > > > On 29.11.2023 17:06, Andy Shevchenko wrote:
> > > > > Make use of PINCTRL_GROUP_DESC() instead of open coding it.
> > >
> > > > PINCTRL_GROUP_DESC() macro from drivers/pinctrl/core.h contains a cast
> > > > to (struct group_desc), what breaks users of the above macros.
> > >
> > > There is no cast (*).
> > > Thanks for report, I will check.
> > >
> > > But this was v4 of the series and LKP actually sent a positive feedback.
> > > Besides that I have tested this locally with modules enabled.
> > >
> > > *) It's a compound literal, _not_ a cast.
> > >    Taking above into consideration I'm wondering what compilers
> > >    are in use?
> >
> > kisskb reported the following m68k failures to me:
> >     linux-next/m68k-allmodconfig/m68k-gcc8
> >     linux-next/m68k-allmodconfig/m68k-gcc11
> >     linux-next/m68k-allmodconfig/m68k-gcc12
> >
> > However, according to [1], linux-next/m68k-allmodconfig/m68k-gcc13
> > did succeed, so I guess you are using gcc13?
>
> Yes, I compiled with these:
>
> $ gcc --version
> gcc (Debian 13.2.0-5) 13.2.0

Time to install and try an older version ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From nm at ti.com  Mon Dec  4 05:44:11 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 07:44:11 -0600
Subject: [PATCH] arm64: dts: ti: phycore-am64: Add R5F DMA Region and
 Mailboxes
In-Reply-To: <5effa700-480b-4030-8335-304ebc4444b7@phytec.de>
References: <20231102201216.3771589-1-ggiordano@phytec.com>
 <20231103001707.2ktwfgtqegpfiijy@subpanel>
 <5effa700-480b-4030-8335-304ebc4444b7@phytec.de>
Message-ID: <20231204134411.jp3kgateozajxlyh@parameter>

On 10:00-20231103, Wadim Egorov wrote:
> Hi Nishanth,
> 
> Am 03.11.23 um 01:17 schrieb Nishanth Menon:
> > On 13:12-20231102, Garrett Giordano wrote:
> > > Communication between the R5F subsystem and Linux takes place using DMA
> > > memory regions and mailboxes. Here we add DT nodes for the memory
> > > regions and mailboxes to facilitate communication between the R5
> > > clusters and Linux as remoteproc will fail to start if no memory
> > > regions or mailboxes are provided.
> > > 
> > > Fixes: c48ac0efe6d7 ("arm64: dts: ti: Add support for phyBOARD-Electra-AM642")
> > is this fixes? Sounds more or less like rproc support is added in?
> 
> I would say it is also a fix, as the R5 cores are enabled by default at the
> SoC level devicetree and also require mboxes & memory regions to be
> configured. The docs mention both as mandatory.
> 
> Otherwise, we will encounter errors such as
> 
> ? platform 78000000.r5f: device does not have reserved memory regions, ret =
> -22
> 

Please repost this, for some reason, the patch[1] does not appear[2] in the
archives and b4 drops out.

[1] https://lore.kernel.org/all/5effa700-480b-4030-8335-304ebc4444b7 at phytec.de/
[2] https://lore.kernel.org/all/20231102201216.3771589-1-ggiordano at phytec.com/
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From sudeep.holla at arm.com  Mon Dec  4 05:46:05 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  4 Dec 2023 13:46:05 +0000
Subject: [PATCH 1/2] firmware: arm_scmi: Fix frequency truncation by promoting multiplier to u64
In-Reply-To: <20231130204343.503076-1-sudeep.holla@arm.com>
References: <20231130204343.503076-1-sudeep.holla@arm.com>
Message-ID: <170169746209.29716.16597269014104395598.b4-ty@arm.com>

On Thu, 30 Nov 2023 20:43:42 +0000, Sudeep Holla wrote:
> Fix the frequency truncation for all values equal to or greater 4GHz by
> updating the multiplier 'mult_factor' to u64 type. It is also possible
> that the multiplier itself can be greater than or equal to 2^32. So we need
> to also fix the equation computing the value of the multiplier.
>

Applied to sudeep.holla/linux (for-next/scmi/fixes), thanks!

[1/2] firmware: arm_scmi: Fix frequency truncation by promoting multiplier to u64
      (Applied changing u64 to unsigned long to fix armv7 build)
      https://git.kernel.org/sudeep.holla/c/8e3c98d9187e
[2/2] firmware: arm_scmi: Fix possible frequency truncation when using level indexing mode
      https://git.kernel.org/sudeep.holla/c/77f5032e94f2
--
Regards,
Sudeep



From sudeep.holla at arm.com  Mon Dec  4 05:47:22 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  4 Dec 2023 13:47:22 +0000
Subject: [GIT PULL] firmware: arm_scmi: Fixes for v6.7
Message-ID: <20231204134724.30465-1-sudeep.holla@arm.com>

Hi ARM SoC Team,

Please pull !

Regards,
Sudeep

-->8

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-fixes-6.7

for you to fetch changes up to 77f5032e94f244ba08db51e17ca8f37bd7ff9acb:

  firmware: arm_scmi: Fix possible frequency truncation when using level indexing mode (2023-12-04 12:33:44 +0000)

----------------------------------------------------------------
Arm SCMI fixes for v6.7

A fix for possible truncation/overflow in the frequency computations
as both the performance value and the multiplier are 32bit values.

----------------------------------------------------------------
Sudeep Holla (2):
      firmware: arm_scmi: Fix frequency truncation by promoting multiplier type
      firmware: arm_scmi: Fix possible frequency truncation when using level indexing mode

 drivers/firmware/arm_scmi/perf.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)


From sudeep.holla at arm.com  Mon Dec  4 05:49:12 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  4 Dec 2023 13:49:12 +0000
Subject: [PATCH] firmware: arm_scmi: Add protocol versioning checks
In-Reply-To: <20231201135858.2367651-1-cristian.marussi@arm.com>
References: <20231201135858.2367651-1-cristian.marussi@arm.com>
Message-ID: <170169770105.30728.4184748461867553378.b4-ty@arm.com>

On Fri, 01 Dec 2023 13:58:58 +0000, Cristian Marussi wrote:
> Platform and agent supported protocols versions do not necessarily match.
>
> When talking to an older platform SCMI server, supporting only older
> protocol versions, the kernel SCMI agent will downgrade the version of
> the used protocol to match the platform one and avoid compatibility issues.
>
> In the case, instead, in which the agent happens to communicate with a
> newer platform server which can support newer protocol versions unknown to
> the agent, and potentially backward incompatible, the agent currently
> carries on, silently, in a best-effort approach.
>
> [...]

Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!

[1/1] firmware: arm_scmi: Add protocol versioning checks
      https://git.kernel.org/sudeep.holla/c/b5efc28a754d
--
Regards,
Sudeep



From nm at ti.com  Mon Dec  4 05:51:03 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 07:51:03 -0600
Subject: [Upstream] [PATCH 1/3] arm64: dts: ti:
 k3-am625-phyboard-lyra-rdk: Lower I2C1 frequency
In-Reply-To: <bd5284ec-6f25-464a-9ee7-4c50496482f1@phytec.de>
References: <20231129183817.2327259-1-ggiordano@phytec.com>
 <bd5284ec-6f25-464a-9ee7-4c50496482f1@phytec.de>
Message-ID: <20231204135103.rqb6r4iddvashtgl@autistic>

On 13:07-20231130, Wadim Egorov wrote:
> 
> Am 29.11.23 um 19:38 schrieb Garrett Giordano:
> > The gpio-expander on i2c-1 has a maximum frequency of 100kHz. Update our
> > main_i2c1 frequency to allow the nxp,pcf8574 gpio-expander to function
> > properly.
> > 
> > Signed-off-by: Garrett Giordano <ggiordano at phytec.com>
> 
> For all three patches,
> 
> Reviewed-by: Wadim Egorov <w.egorov at phytec.de>
> 
> 
> > ---
> >   arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
> > index a438baf542c2..171354b13e33 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
> > +++ b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
> > @@ -187,7 +187,7 @@ cpsw3g_phy3: ethernet-phy at 3 {
> >   &main_i2c1 {
> >   	pinctrl-names = "default";
> >   	pinctrl-0 = <&main_i2c1_pins_default>;
> > -	clock-frequency = <400000>;
> > +	clock-frequency = <100000>;
> >   	status = "okay";
> >   	gpio_exp: gpio-expander at 21 {


Please resubmit the patches - the archives don't seem to have a copy
and b4 drops out. Also, when doing that, please pick up the reviews.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From sudeep.holla at arm.com  Mon Dec  4 05:55:14 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  4 Dec 2023 13:55:14 +0000
Subject: (subset) [PATCH 0/3] firmware: arm_scmi: Miscellaneous fixes and opp count increase
In-Reply-To: <20231129065748.19871-1-quic_sibis@quicinc.com>
References: <20231129065748.19871-1-quic_sibis@quicinc.com>
Message-ID: <170169805641.32343.17556834929598900222.b4-ty@arm.com>

On Wed, 29 Nov 2023 12:27:45 +0530, Sibi Sankar wrote:
> The patch series includes bug fixes identified while testing the
> performance protocol on the X1E80100 SoC. It also includes an
> increase of the maximum opps count to the next log level.
>
> base tree: next-20231129
>
> Sibi Sankar (3):
>   firmware: arm_scmi: Fix null pointer dereference during fastchannel init
>   firmware: arm_scmi: Fix freq/power truncation in the perf protocol
>   firmware: arm_scmi: Increase the maximum opp count
>
> [...]

Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!

[1/3] firmware: arm_scmi: Fix null pointer dereference during fastchannel init
      https://git.kernel.org/sudeep.holla/c/3cc12bb83e67
[3/3] firmware: arm_scmi: Increase the maximum opp count
      https://git.kernel.org/sudeep.holla/c/c3f17d5f89fc
--
Regards,
Sudeep



From eugen.hristev at collabora.com  Mon Dec  4 05:55:33 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Mon,  4 Dec 2023 15:55:33 +0200
Subject: [PATCH] arm64: dts: mediatek: mt8186: fix address warning for ADSP mailboxes
Message-ID: <20231204135533.21327-1-eugen.hristev@collabora.com>

Fix warnings reported by dtbs_check :

arch/arm64/boot/dts/mediatek/mt8186.dtsi:1163.35-1168.5: Warning (simple_bus_reg):
 /soc/mailbox at 10686000: simple-bus unit address format error, expected "10686100"
arch/arm64/boot/dts/mediatek/mt8186.dtsi:1170.35-1175.5: Warning (simple_bus_reg):
 /soc/mailbox at 10687000: simple-bus unit address format error, expected "10687100"

by having the right bus address as node name.

Fixes: 379cf0e639ae ("arm64: dts: mediatek: mt8186: Add ADSP mailbox nodes")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index d57d8ed487b8..ae06f987ac3b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1160,14 +1160,14 @@ adsp: adsp at 10680000 {
 			status = "disabled";
 		};
 
-		adsp_mailbox0: mailbox at 10686000 {
+		adsp_mailbox0: mailbox at 10686100 {
 			compatible = "mediatek,mt8186-adsp-mbox";
 			#mbox-cells = <0>;
 			reg = <0 0x10686100 0 0x1000>;
 			interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH 0>;
 		};
 
-		adsp_mailbox1: mailbox at 10687000 {
+		adsp_mailbox1: mailbox at 10687100 {
 			compatible = "mediatek,mt8186-adsp-mbox";
 			#mbox-cells = <0>;
 			reg = <0 0x10687100 0 0x1000>;
-- 
2.34.1



From mark.rutland at arm.com  Mon Dec  4 06:12:10 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 4 Dec 2023 14:12:10 +0000
Subject: [PATCH v6 02/41] arm64: mm: Take potential load offset into
 account when KASLR is off
In-Reply-To: <20231129111555.3594833-45-ardb@google.com>
References: <20231129111555.3594833-43-ardb@google.com>
 <20231129111555.3594833-45-ardb@google.com>
Message-ID: <ZW3eOoVTotfNXIJo@FVFF77S0Q05N>

On Wed, Nov 29, 2023 at 12:15:58PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> 
> We enable CONFIG_RELOCATABLE even when CONFIG_RANDOMIZE_BASE is
> disabled, and this permits the loader (i.e., EFI) to place the kernel
> anywhere in physical memory as long as the base address is 64k aligned.

I don't think that case is something we actually intend to permit today:

(a) When CONFIG_RANDOMIZE_BASE=n, the EFI stub will load the kernel at SZ_2M
    alignment. We initialize efi_nokaslr to !IS_ENABLED(CONFIG_RANDOMIZE_BASE),
    and so arm64's efi_get_kimg_min_align() will return SZ_2M.

    ... unless I'm missing something there?

(b) We don't expose anything in the Image header such that an external
    bootloader (i.e. not the EFI stub) can decide that 64K alignment is
    sufficient. It would be unsound for a bootloader to load the kernel at less
    than 2M alignment.

(c) We never documented 64K alignment as being permitted. In booting.txt we say
    "The Image must be placed text_offset bytes from a 2MB aligned base address
    anywhere in usable system RAM and called there.", with no mention of a
    relaxation down to 64K.

... so I don't think this patch is necessary, unless it's going to make
something else simpler later in the series?

Mark.

> This means that the 'KASLR' case described in the header that defines
> the size of the statically allocated page tables could take effect even
> when CONFIG_RANDMIZE_BASE=n. So check for CONFIG_RELOCATABLE instead.
> 
> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> ---
>  arch/arm64/include/asm/kernel-pgtable.h | 27 +++++---------------
>  1 file changed, 6 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
> index 85d26143faa5..83ddb14b95a5 100644
> --- a/arch/arm64/include/asm/kernel-pgtable.h
> +++ b/arch/arm64/include/asm/kernel-pgtable.h
> @@ -37,27 +37,12 @@
>  
>  
>  /*
> - * If KASLR is enabled, then an offset K is added to the kernel address
> - * space. The bottom 21 bits of this offset are zero to guarantee 2MB
> - * alignment for PA and VA.
> - *
> - * For each pagetable level of the swapper, we know that the shift will
> - * be larger than 21 (for the 4KB granule case we use section maps thus
> - * the smallest shift is actually 30) thus there is the possibility that
> - * KASLR can increase the number of pagetable entries by 1, so we make
> - * room for this extra entry.
> - *
> - * Note KASLR cannot increase the number of required entries for a level
> - * by more than one because it increments both the virtual start and end
> - * addresses equally (the extra entry comes from the case where the end
> - * address is just pushed over a boundary and the start address isn't).
> + * A relocatable kernel may execute from an address that differs from the one at
> + * which it was linked. In the worst case, its runtime placement may intersect
> + * with two adjacent PGDIR entries, which means that an additional page table
> + * may be needed at each subordinate level.
>   */
> -
> -#ifdef CONFIG_RANDOMIZE_BASE
> -#define EARLY_KASLR	(1)
> -#else
> -#define EARLY_KASLR	(0)
> -#endif
> +#define EXTRA_PAGE	__is_defined(CONFIG_RELOCATABLE)
>  
>  #define SPAN_NR_ENTRIES(vstart, vend, shift) \
>  	((((vend) - 1) >> (shift)) - ((vstart) >> (shift)) + 1)
> @@ -83,7 +68,7 @@
>  			+ EARLY_PGDS((vstart), (vend), add) 	/* each PGDIR needs a next level page table */	\
>  			+ EARLY_PUDS((vstart), (vend), add)	/* each PUD needs a next level page table */	\
>  			+ EARLY_PMDS((vstart), (vend), add))	/* each PMD needs a next level page table */
> -#define INIT_DIR_SIZE (PAGE_SIZE * EARLY_PAGES(KIMAGE_VADDR, _end, EARLY_KASLR))
> +#define INIT_DIR_SIZE (PAGE_SIZE * EARLY_PAGES(KIMAGE_VADDR, _end, EXTRA_PAGE))
>  
>  /* the initial ID map may need two extra pages if it needs to be extended */
>  #if VA_BITS < 48
> -- 
> 2.43.0.rc1.413.gea7ed67945-goog
> 


From yury.norov at gmail.com  Mon Dec  4 06:22:20 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Mon, 4 Dec 2023 06:22:20 -0800
Subject: [PATCH v12 1/3] lib/bitmap: add bitmap_{read,write}()
In-Reply-To: <CAG_fn=U7EV0ohaNFRwQ83cvwVn-Fer1pHXOjPevbP_XpYGDCYA@mail.gmail.com>
References: <20231109151106.2385155-1-glider@google.com>
 <CAG_fn=U7EV0ohaNFRwQ83cvwVn-Fer1pHXOjPevbP_XpYGDCYA@mail.gmail.com>
Message-ID: <ZW3gnNbnzpZwtrMa@yury-ThinkPad>

On Mon, Dec 04, 2023 at 02:28:09PM +0100, Alexander Potapenko wrote:
> On Thu, Nov 9, 2023 at 4:11?PM Alexander Potapenko <glider at google.com> wrote:
> >
> > From: Syed Nayyar Waris <syednwaris at gmail.com>
> >
> > The two new functions allow reading/writing values of length up to
> > BITS_PER_LONG bits at arbitrary position in the bitmap.
> >
> > The code was taken from "bitops: Introduce the for_each_set_clump macro"
> > by Syed Nayyar Waris with a number of changes and simplifications:
> >  - instead of using roundup(), which adds an unnecessary dependency
> >    on <linux/math.h>, we calculate space as BITS_PER_LONG-offset;
> >  - indentation is reduced by not using else-clauses (suggested by
> >    checkpatch for bitmap_get_value());
> >  - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read()
> >    and bitmap_write();
> >  - some redundant computations are omitted.
> >
> > Cc: Arnd Bergmann <arnd at arndb.de>
> > Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
> > Signed-off-by: William Breathitt Gray <william.gray at linaro.org>
> > Link: https://lore.kernel.org/lkml/fe12eedf3666f4af5138de0e70b67a07c7f40338.1592224129.git.syednwaris at gmail.com/
> > Suggested-by: Yury Norov <yury.norov at gmail.com>
> > Co-developed-by: Alexander Potapenko <glider at google.com>
> > Signed-off-by: Alexander Potapenko <glider at google.com>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> 
> Yury, Andy, do you think anything else is needed for this series?
> If not, whom should we ask to take it?

I probably need to revisit it, but generally it looks OK.

But I can't take new API without having real users. Now that your MTE
series is delayed, and Alexander's 'ip_tunnel flags' is not moving as
well, there's non-zero chance to merge dead code.

If you want it to be merged, I'd advise you to walk through the kernel
sources and find good cases where bitmap_read() and bitmap_write() can
be used. Then append this series with such conversions, and I'll be
able to move it.

Thanks,
Yury


From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:27:45 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:27:45 +0100
Subject: [PATCH v3 8/9] arm64: dts: mediatek: Add MT8186 Steelix platform
 based Rusty
In-Reply-To: <20231204084012.2281292-9-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-9-wenst@chromium.org>
Message-ID: <ec4b992d-5761-44fb-bce5-91b1a8813f82@collabora.com>

Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> MT8186 Rusty, otherwise known as the Lenovo 100e Chromebook Gen 4, is an
> MT8186 based laptop. It is based on the "Steelix" design. Being a laptop
> instead of a convertible device, there is no touchscreen or stylus.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:27:44 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:27:44 +0100
Subject: [PATCH v3 9/9] arm64: dts: mediatek: Add MT8186 Magneton
 Chromebooks
In-Reply-To: <20231204084012.2281292-10-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-10-wenst@chromium.org>
Message-ID: <e68dddc4-7175-4457-9882-6403b09a1e8b@collabora.com>

Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> Add entries for the MT8186 based Chromebooks, also collectively known
> as the Lenovo IdeaPad Slim 3 Chromebook (14M868). It is also based on
> the "Steelix" design. Being a laptop instead of a convertible device,
> there is no stylus, which is similar to Rusty. However Magneton does
> not have ports on the right side of the device.
> 
> Three variants are listed separately. These use different touchscreen
> controllers, or lack a touchscreen altogether.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:27:48 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:27:48 +0100
Subject: [PATCH v3 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <20231204084012.2281292-7-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-7-wenst@chromium.org>
Message-ID: <ab7988af-e7f9-433d-b35e-138f79ce82c0@collabora.com>

Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> Krabby design.
> 
> Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> convertible device with touchscreen and stylus.
> 
> Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> device. It does not have a touchscreen or stylus.
> 
> The two devices both have two variants. The difference is a second
> source touchpad controller that shares the same address as the original,
> but is incompatible.
> 
> The extra SKU IDs for the Tentacruel devices map to different sensor
> components attached to the Embedded Controller. These are not visible
> to the main processor.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>
> ---
> Changes since v2:
> - Picked up Conor's ack
> - Rename touchpad to trackpad
> - Drop pinctrl properties from trackpad in tentacruel/tentacool second
>    source trackpad
> 
> Changes since v1:
> - Reorder SKU numbers in descending order.
> - Fixed pinconfig node names
> - Moved pinctrl-* properties after interrupts-*
> - Switched to interrupts-extended for external components
> - Marked ADSP as explicitly disabled, with a comment explaining that it
>    stalls the system
> - Renamed "touchpad" to "trackpad"
> - Dropped bogus "no-laneswap" property from it6505 node
> - Moved "realtek,jd-src" property to after all the regulator supplies
> - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> - Renamed "vgpu" regulator name to allow coupling, with a comment
>    containing the name used in the design
> - Renamed "cr50" node name to "tpm"
> - Moved trackpad_pins reference up to i2c2; workaround for second source
>    component resource sharing.
> - Fix copyright year
> - Fixed touchscreen supply name
> 
>   arch/arm64/boot/dts/mediatek/Makefile         |    4 +
>   .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
>   .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
>   .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
>   .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
>   .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
>   .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
>   7 files changed, 2003 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> 
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index e6e7592a3645..442af61b1305 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> new file mode 100644
> index 000000000000..9b2b64525961
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> @@ -0,0 +1,129 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +	aliases {
> +		i2c4 = &i2c4;
> +	};
> +};
> +
> +&dsi_out {
> +	remote-endpoint = <&ps8640_in>;
> +};
> +
> +&i2c0 {
> +	clock-frequency = <400000>;
> +
> +	ps8640: edp-bridge at 8 {
> +		compatible = "parade,ps8640";
> +		reg = <0x8>;
> +		powerdown-gpios = <&pio 96 GPIO_ACTIVE_LOW>;
> +		reset-gpios = <&pio 98 GPIO_ACTIVE_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&ps8640_pins>;
> +		vdd12-supply = <&mt6366_vrf12_reg>;
> +		vdd33-supply = <&mt6366_vcn33_reg>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +
> +				ps8640_in: endpoint {
> +					remote-endpoint = <&dsi_out>;
> +				};
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +
> +				ps8640_out: endpoint {
> +					remote-endpoint = <&panel_in>;
> +				};
> +			};
> +		};
> +
> +		aux-bus {
> +			panel {
> +				compatible = "edp-panel";
> +				power-supply = <&pp3300_disp_x>;
> +				backlight = <&backlight_lcd0>;
> +
> +				port {
> +					panel_in: endpoint {
> +						remote-endpoint = <&ps8640_out>;
> +					};
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&i2c1 {
> +	i2c-scl-internal-delay-ns = <10000>;
> +
> +	touchscreen: touchscreen at 10 {
> +		compatible = "hid-over-i2c";
> +		reg = <0x10>;
> +		interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&touchscreen_pins>;
> +		post-power-on-delay-ms = <10>;
> +		hid-descr-addr = <0x0001>;
> +		vdd-supply = <&pp3300_s3>;
> +	};
> +};
> +
> +&i2c4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c4_pins>;
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	proximity at 28 {
> +		compatible = "semtech,sx9324";
> +		reg = <0x28>;
> +		interrupts-extended = <&pio 5 IRQ_TYPE_LEVEL_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&sar_sensor_pins>;
> +		vdd-supply = <&mt6366_vio18_reg>;
> +		svdd-supply = <&mt6366_vio18_reg>;
> +		#io-channel-cells = <1>;

 From the newest DTS coding style document:

The following order of properties in device nodes is preferred:

1. compatible
2. reg
3. ranges
4. Standard/common properties (defined by common bindings, e.g. without
    vendor-prefixes)
5. Vendor-specific properties
6. status (if applicable)
7. Child nodes, where each node is preceded with a blank line

The "status" property is by default "okay", thus it can be omitted.

The above-described ordering follows this approach:

1. Most important properties start the node: compatible then bus addressing to
    match unit address.
2. Each node will have common properties in similar place.
3. Status is the last information to annotate that device node is or is not
    finished (board resources are needed).


#io-channel-cells goes after `reg` (same for the other instances) :-)

> +	};
> +};
> +
> +&pio {
> +	i2c4_pins: i2c4-pins {
> +		pins-bus {
> +			pinmux = <PINMUX_GPIO136__FUNC_SDA4>,
> +				 <PINMUX_GPIO135__FUNC_SCL4>;
> +			bias-disable;
> +			drive-strength = <4>;
> +			input-enable;
> +		};
> +	};
> +
> +	ps8640_pins: ps8640-pins {
> +		pins-pwrdn-rst {
> +			pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
> +				 <PINMUX_GPIO98__FUNC_GPIO98>;
> +			output-low;
> +		};
> +	};
> +
> +	sar_sensor_pins: sar-sensor-pins {
> +		pins-irq {
> +			pinmux = <PINMUX_GPIO5__FUNC_GPIO5>;
> +			input-enable;
> +			bias-pull-up;
> +		};
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> new file mode 100644
> index 000000000000..9bb64353ca65
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> @@ -0,0 +1,57 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola-krabby.dtsi"
> +
> +/ {
> +	model = "Google Tentacool board";
> +	compatible = "google,tentacruel-sku327681", "google,tentacruel", "mediatek,mt8186";
> +	chassis-type = "laptop";
> +};
> +
> +/* Tentacool omits the pen. */
> +&gpio_keys {
> +	status = "disabled";
> +};
> +
> +/* Tentacool omits the touchscreen; nothing else is on i2c1. */
> +&i2c1 {
> +	status = "disabled";
> +};
> +
> +&keyboard_controller {
> +	function-row-physmap = <
> +		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
> +		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
> +		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
> +		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
> +		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
> +		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
> +		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
> +		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
> +		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
> +		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
> +	>;
> +
> +	linux,keymap = <
> +		MATRIX_KEY(0x00, 0x02, KEY_BACK)
> +		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> +		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> +		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> +		MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> +		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> +		MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> +		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> +		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> +		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> +		CROS_STD_MAIN_KEYMAP
> +	>;
> +};
> +
> +/* Tentacool omits the touchscreen. */
> +&touchscreen {
> +	status = "disabled";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> new file mode 100644
> index 000000000000..c3ae6f9616c8
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2023 Google LLC
> + */
> +
> +#include "mt8186-corsola-tentacool-sku327681.dts"
> +
> +/ {
> +	compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
> +};
> +
> +/* This variant replaces only the trackpad controller. */
> +&i2c2 {
> +	/delete-node/ trackpad at 15;

Why are you deleting the trackpad at 15 node?

You can simply override the compatible, or actually omit the compatible string
in the *.dtsi file, and set just that in each board *.dts.

dtsi:
	trackpad_a: trackpad at 15 {
		/* Compatible is set in each board dts */
		reg, interrupts, others
	}

dts:

&trackpad_a {
	compatible = "elan,ekth3000";
};


other dts:

&trackpad_a {
	compatible = "hid-over-i2c";
};

> +
> +	trackpad at 15 {
> +		compatible = "hid-over-i2c";
> +		reg = <0x15>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		hid-descr-addr = <0x0001>;
> +		vdd-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> new file mode 100644
> index 000000000000..26d3451a5e47
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> @@ -0,0 +1,44 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola-krabby.dtsi"
> +
> +/ {
> +	model = "Google Tentacruel board";
> +	compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
> +		     "google,tentacruel-sku262145", "google,tentacruel-sku262144",
> +		     "google,tentacruel", "mediatek,mt8186";
> +	chassis-type = "convertible";
> +};
> +
> +&keyboard_controller {
> +	function-row-physmap = <
> +		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
> +		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
> +		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
> +		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
> +		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
> +		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
> +		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
> +		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
> +		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
> +		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
> +	>;
> +
> +	linux,keymap = <
> +		MATRIX_KEY(0x00, 0x02, KEY_BACK)
> +		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> +		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> +		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> +		MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> +		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> +		MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> +		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> +		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> +		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> +		CROS_STD_MAIN_KEYMAP
> +	>;
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> new file mode 100644
> index 000000000000..447b57b12b41
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2023 Google LLC
> + */
> +
> +#include "mt8186-corsola-tentacruel-sku262144.dts"
> +
> +/ {
> +	compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> +		     "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> +		     "google,tentacruel", "mediatek,mt8186";
> +};
> +
> +/* This variant replaces only the trackpad controller. */
> +&i2c2 {
> +	/delete-node/ trackpad at 15;
> +
> +	trackpad at 15 {
> +		compatible = "hid-over-i2c";
> +		reg = <0x15>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		hid-descr-addr = <0x0001>;
> +		vdd-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> new file mode 100644
> index 000000000000..8726b2916ef1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> @@ -0,0 +1,1719 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (C) 2022 MediaTek Inc.
> + */
> +/dts-v1/;
> +#include "mt8186.dtsi"
> +#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/input/gpio-keys.h>
> +#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
> +
> +/ {
> +	aliases {
> +		i2c0 = &i2c0;
> +		i2c1 = &i2c1;
> +		i2c2 = &i2c2;
> +		i2c3 = &i2c3;
> +		i2c5 = &i2c5;
> +		mmc0 = &mmc0;
> +		mmc1 = &mmc1;
> +		serial0 = &uart0;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	memory at 40000000 {
> +		device_type = "memory";
> +		/* The size should be filled in by the bootloader. */
> +		reg = <0 0x40000000 0 0>;
> +	};
> +
> +	backlight_lcd0: backlight-lcd0 {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm0 0 500000>;
> +		power-supply = <&ppvar_sys>;
> +		enable-gpios = <&pio 152 0>;
> +		brightness-levels = <0 1023>;
> +		num-interpolated-steps = <1023>;
> +		default-brightness-level = <576>;
> +	};
> +
> +	btsco: bt-sco {

Do you really need the phandle to bt-sco?

Also, this node describes a codec, so: "bt-sco-codec" please!

> +		compatible = "linux,bt-sco";
> +		#sound-dai-cells = <0>;
> +	};
> +
> +	dmic_codec: dmic-codec {

This phandle is unused...

..snip..

> +
> +&adsp {
> +	memory-region = <&adsp_dma_mem>, <&adsp_mem>;
> +	status = "disabled"; /* causes stall */

This is a firmware issue: once the correct firmware is uploaded to linux-firmware
the dsp node can get enabled... so it we make sure that this happens before this
devicetree gets picked, we can avoid a second commit enabling audio.

After all, since we *want to* use the Xtensa DSP for audio, without it booted
sound won't work *anyway*.... so having the firmware in place can also be seen
as a direct dependency of the entire audio functionality.

P.S.: The FW that is distributed with ChromeOS works just fine!

> +};
> +
> +&afe {
> +	i2s0-share = "I2S1";
> +	i2s3-share = "I2S2";
> +	status = "okay";
> +};
> +

..snip..

> +&i2c2 {
> +	pinctrl-names = "default";
> +	/*
> +	 * Trackpad pin put here to work around second source components
> +	 * sharing the pinmux in steelix designs.
> +	 */
> +	pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;

There's no choice for now... even if this is not beautiful to see... but it's still
ok for me because we can revisit this later when the HW Prober mechanism will be
upstreamed.

> +	clock-frequency = <400000>;
> +	i2c-scl-internal-delay-ns = <10000>;
> +	status = "okay";
> +
> +	trackpad at 15 {
> +		compatible = "elan,ekth3000";
> +		reg = <0x15>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		vcc-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};
> +

Thanks,
Angelo



From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:27:46 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:27:46 +0100
Subject: [PATCH v3 7/9] arm64: dts: mediatek: Introduce MT8186 Steelix
In-Reply-To: <20231204084012.2281292-8-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-8-wenst@chromium.org>
Message-ID: <7bed2f95-6fa6-4387-900b-82906eca3941@collabora.com>

Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> The MT8186 Steelix, also known as the Lenovo 300e Yoga Chromebook Gen 4,
> is a convertible device based on a common design of the same name. The
> device comes in different variants. Of them, whether a world facing
> camera is integrated is the only differentiating factor between the
> two device trees added. The different SKU IDs describe this alone.
> 
> The other device difference is the touchpad component used. This is
> simply handled by having both possible components described in the
> device tree, and letting the implementation figure out which one is
> actually available. The system bootloader / firmware does not
> differentiate this in that they share the same SKU IDs.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>
> ---
> Changes since v2:
> - Picked up Conor's ack
> 
> Changes since v1:
> - Removed trackpad_pins reference (moved to i2c2 in corsola dtsi)
> - Fixed copyright year
> - Renamed touchpad to trackpad
> 
>   arch/arm64/boot/dts/mediatek/Makefile         |   2 +
>   .../mt8186-corsola-steelix-sku131072.dts      |  18 ++
>   .../mt8186-corsola-steelix-sku131073.dts      |  18 ++
>   .../dts/mediatek/mt8186-corsola-steelix.dtsi  | 195 ++++++++++++++++++
>   4 files changed, 233 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
> 
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index 442af61b1305..7bd9471b89f9 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -43,6 +43,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131072.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131073.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
> new file mode 100644
> index 000000000000..eae17bca8585
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola-steelix.dtsi"
> +
> +/ {
> +	model = "Google Steelix board";
> +	compatible = "google,steelix-sku131072", "google,steelix",
> +		     "mediatek,mt8186";
> +	chassis-type = "convertible";
> +};
> +
> +&mt6366codec {
> +	mediatek,dmic-mode = <0>; /* two-wire */
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
> new file mode 100644
> index 000000000000..a55375b95d0d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola-steelix.dtsi"
> +
> +/ {
> +	model = "Google Steelix board";
> +	compatible = "google,steelix-sku131073", "google,steelix",
> +		     "mediatek,mt8186";
> +	chassis-type = "convertible";
> +};
> +
> +&mt6366codec {
> +	mediatek,dmic-mode = <1>; /* one-wire */
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
> new file mode 100644
> index 000000000000..47262bc499ad
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +
> +/{
> +	pp1000_edpbrdg: regulator-pp1000-edpbrdg {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp1000_edpbrdg";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&en_pp1000_edpbrdg>;
> +		enable-active-high;
> +		regulator-boot-on;
> +		gpio = <&pio 29 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&pp3300_z2>;
> +	};
> +
> +	pp1800_edpbrdg_dx: regulator-pp1800-edpbrdg-dx {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp1800_edpbrdg_dx";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&en_pp1800_edpbrdg>;
> +		enable-active-high;
> +		regulator-boot-on;
> +		gpio = <&pio 30 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&mt6366_vio18_reg>;
> +	};
> +
> +	pp3300_edp_dx: regulator-pp3300-edp-dx {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp3300_edp_dx";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&en_pp3300_edpbrdg>;
> +		enable-active-high;
> +		regulator-boot-on;
> +		gpio = <&pio 31 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&pp3300_z2>;
> +	};
> +};
> +
> +&dsi_out {
> +	remote-endpoint = <&anx7625_in>;
> +};
> +
> +&i2c0 {
> +	clock-frequency = <400000>;
> +
> +	anx_bridge: anx7625 at 58 {
> +		compatible = "analogix,anx7625";
> +		reg = <0x58>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&anx7625_pins>;
> +		enable-gpios = <&pio 96 GPIO_ACTIVE_HIGH>;
> +		reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>;
> +		vdd10-supply = <&pp1000_edpbrdg>;
> +		vdd18-supply = <&pp1800_edpbrdg_dx>;
> +		vdd33-supply = <&pp3300_edp_dx>;
> +		analogix,lane0-swing = /bits/ 8 <0x70 0x30>;
> +		analogix,lane1-swing = /bits/ 8 <0x70 0x30>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +
> +				anx7625_in: endpoint {
> +					remote-endpoint = <&dsi_out>;
> +					data-lanes = <0 1 2 3>;
> +				};
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +
> +				anx7625_out: endpoint {
> +					remote-endpoint = <&panel_in>;
> +				};
> +			};
> +		};
> +
> +		aux-bus {
> +			panel: panel {
> +				compatible = "edp-panel";
> +				power-supply = <&pp3300_disp_x>;
> +				backlight = <&backlight_lcd0>;
> +
> +				port {
> +					panel_in: endpoint {
> +						remote-endpoint = <&anx7625_out>;
> +					};
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&i2c1 {
> +	touchscreen: touchscreen at 5d {
> +		compatible = "goodix,gt7375p";
> +		reg = <0x5d>;
> +		interrupts-extended = <&pio 12 IRQ_TYPE_EDGE_FALLING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&touchscreen_pins>;
> +		reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>;
> +		vdd-supply = <&pp3300_s3>;
> +		goodix,no-reset-during-suspend;
> +	};
> +};
> +
> +&i2c2 {
> +	i2c-scl-internal-delay-ns = <22000>;
> +
> +	/* second source component */
> +	trackpad at 2c {
> +		compatible = "hid-over-i2c";
> +		reg = <0x2c>;
> +		hid-descr-addr = <0x20>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		vdd-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};
> +
> +&keyboard_controller {
> +	function-row-physmap = <
> +		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
> +		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
> +		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
> +		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
> +		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
> +		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
> +		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
> +		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
> +		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
> +		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
> +	>;
> +
> +	linux,keymap = <
> +		MATRIX_KEY(0x00, 0x02, KEY_BACK)
> +		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> +		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> +		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> +		MATRIX_KEY(0x03, 0x04, KEY_BRIGHTNESSDOWN)
> +		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSUP)
> +		MATRIX_KEY(0x01, 0x04, KEY_MICMUTE)
> +		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> +		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> +		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> +		CROS_STD_MAIN_KEYMAP
> +	>;
> +};
> +
> +&pio {
> +	anx7625_pins: anx7625-pins {
> +		pins1 {

en-rst-pins

> +			pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
> +				 <PINMUX_GPIO98__FUNC_GPIO98>;
> +			output-low;
> +		};
> +
> +		pins2 {

GPIO9 is not referenced anywhere, what is it for?

> +			pinmux = <PINMUX_GPIO9__FUNC_GPIO9>;
> +			input-enable;
> +			bias-disable;
> +		};
> +	};
> +
> +	en_pp1000_edpbrdg: pp1000-edpbrdg-en-pins {

pp1000-edpbrdg-pins {
	en-pins {

"Same" for the other two vreg en pins.

Cheers,
Angelo


From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:27:53 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:27:53 +0100
Subject: [PATCH v3 5/9] dt-bindings: arm: mediatek: Add MT8186 Magneton
 Chromebooks
In-Reply-To: <20231204084012.2281292-6-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-6-wenst@chromium.org>
Message-ID: <6261c914-fc03-42d7-8237-75f3b59deb5d@collabora.com>

Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> Add entries for the MT8186 based Chromebooks, also collectively known
> as the Lenovo IdeaPad Slim 3 Chromebook (14M868). It is also based on
> the "Steelix" design. Being a laptop instead of a convertible device,
> there is no touchscreen or stylus, which is similar to Rusty. However
> Magneton does not have ports on the right side of the device.
> 
> Three variants are listed separately. These use different touchscreen
> controllers, or lack a touchscreen altogether.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:27:54 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:27:54 +0100
Subject: [PATCH v3 4/9] dt-bindings: arm: mediatek: Add MT8186 Rusty
 Chromebook
In-Reply-To: <20231204084012.2281292-5-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-5-wenst@chromium.org>
Message-ID: <ce1bd340-cfc5-47ba-849b-1ee429b75c1a@collabora.com>

Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> Add an entry for the MT8186 based Rusty Chromebook, also known as the
> Lenovo 100e Chromebook Gen 4.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:27:57 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:27:57 +0100
Subject: [PATCH v3 3/9] dt-bindings: arm: mediatek: Add MT8186 Steelix
 Chromebook
In-Reply-To: <20231204084012.2281292-4-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-4-wenst@chromium.org>
Message-ID: <a05e75ec-a175-4662-9612-b88cf6529a75@collabora.com>

Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> Add an entry for the MT8186 based Steelix Chromebook, also known as the
> Lenovo 300e Yoga Chromebook Gen 4.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:27:58 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:27:58 +0100
Subject: [PATCH v3 2/9] dt-bindings: arm: mediatek: Add MT8186 Tentacruel
 / Tentacool Chromebooks
In-Reply-To: <20231204084012.2281292-3-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-3-wenst@chromium.org>
Message-ID: <3f97b10d-6def-4c77-8382-e1c56e8f16a2@collabora.com>

Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> Add entries for MT8186 based Tentacruel / Tentacool Chromebooks. The two
> are based on the same board design: the former is a convertible device
> with a touchscreen, stylus, and some extra buttons; the latter is a
> clamshell device and lacks these additional features.
> 
> The two devices both have two variants. The difference is a second
> source touchpad controller that shares the same address as the original,
> but is incompatible.
> 
> The extra SKU IDs for the Tentacruel devices map to different sensor
> components attached to the Embedded Controller. These are not visible
> to the main processor.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:28:00 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:28:00 +0100
Subject: [PATCH v3 1/9] dt-bindings: arm: mediatek: Sort entries by SoC
 then board compatibles
In-Reply-To: <20231204084012.2281292-2-wenst@chromium.org>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-2-wenst@chromium.org>
Message-ID: <b8623f65-45f5-4ce6-8b0c-eaf5e820fd26@collabora.com>

Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> Some of the new MediaTek board entries were inserted in a chronological
> order, or just randomly. This makes it harder to search for an entry.
> 
> Sort the entries by first grouping by SoC, then sorting by board
> compatible strings. Also add a comment at the top asking people to do
> the same.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From angelogioacchino.delregno at collabora.com  Mon Dec  4 06:30:06 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 4 Dec 2023 15:30:06 +0100
Subject: [PATCH] arm64: dts: mediatek: mt8186: fix address warning for
 ADSP mailboxes
In-Reply-To: <20231204135533.21327-1-eugen.hristev@collabora.com>
References: <20231204135533.21327-1-eugen.hristev@collabora.com>
Message-ID: <1d4432c3-c929-4521-991d-22c92fc74a53@collabora.com>

Il 04/12/23 14:55, Eugen Hristev ha scritto:
> Fix warnings reported by dtbs_check :
> 
> arch/arm64/boot/dts/mediatek/mt8186.dtsi:1163.35-1168.5: Warning (simple_bus_reg):
>   /soc/mailbox at 10686000: simple-bus unit address format error, expected "10686100"
> arch/arm64/boot/dts/mediatek/mt8186.dtsi:1170.35-1175.5: Warning (simple_bus_reg):
>   /soc/mailbox at 10687000: simple-bus unit address format error, expected "10687100"
> 
> by having the right bus address as node name.
> 
> Fixes: 379cf0e639ae ("arm64: dts: mediatek: mt8186: Add ADSP mailbox nodes")
> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From quic_mnaresh at quicinc.com  Mon Dec  4 06:30:58 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Mon, 4 Dec 2023 20:00:58 +0530
Subject: [PATCH V2 0/3] Add CPU latency QoS support for ufs driver
Message-ID: <20231204143101.64163-1-quic_mnaresh@quicinc.com>

Add CPU latency QoS support for ufs driver. This improves random io
performance by 15% for ufs.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 37101.3
	Random Write(IPOS) | 41065.13

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 42943.4
	Random Write(IPOS) | 46784.9
(Improvement % with PM QoS = ~15%).

This patch is based on below patch by Stanley Chu [1]. 
Moving the PM QoS code to ufshcd.c and making it generic.

[1] https://lore.kernel.org/r/20220623035052.18802-8-stanley.chu at mediatek.com

Changes from v1:
- Addressed bvanassche comments to have the code in core ufshcd
- Design is changed from per-device PM QoS to CPU latency QoS based support
- Reverted existing PM QoS feature from MEDIATEK UFS driver
- Added PM QoS capability for both QCOM and MEDIATEK SoCs

Maramaina Naresh (3):
  ufs: core: Add CPU latency QoS support for ufs driver
  ufs: ufs-mediatek: Enable CPU latency PM QoS support for MEDIATEK SoC
  ufs: ufs-qcom: Enable CPU latency QoS support for QCOM SoC

 drivers/ufs/core/ufshcd-priv.h  |  8 +++++
 drivers/ufs/core/ufshcd.c       | 62 +++++++++++++++++++++++++++++++++
 drivers/ufs/host/ufs-mediatek.c | 20 ++---------
 drivers/ufs/host/ufs-mediatek.h |  3 --
 drivers/ufs/host/ufs-qcom.c     |  1 +
 include/ufs/ufshcd.h            | 16 +++++++++
 6 files changed, 90 insertions(+), 20 deletions(-)

-- 
2.34.1



From quic_mnaresh at quicinc.com  Mon Dec  4 06:30:59 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Mon, 4 Dec 2023 20:00:59 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs driver
In-Reply-To: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
Message-ID: <20231204143101.64163-2-quic_mnaresh@quicinc.com>

Register ufs driver to CPU latency PM QoS framework can improves
ufs device random io performance.

PM QoS initialization will insert new QoS request into the CPU
latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
value.

UFS driver will vote for performance mode on scale up and power
save mode for scale down.

If clock scaling feature is not enabled then voting will be based
on clock on or off condition.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 41065.13
	Random Read(IPOS)  | 37101.3

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 46784.9
	Random Read(IPOS)  | 42943.4
(Improvement % with PM QoS = ~15%).

Co-developed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall at quicinc.com>
Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/core/ufshcd-priv.h |  8 +++++
 drivers/ufs/core/ufshcd.c      | 62 ++++++++++++++++++++++++++++++++++
 include/ufs/ufshcd.h           | 16 +++++++++
 3 files changed, 86 insertions(+)

diff --git a/drivers/ufs/core/ufshcd-priv.h b/drivers/ufs/core/ufshcd-priv.h
index f42d99ce5bf1..536805f6c4e1 100644
--- a/drivers/ufs/core/ufshcd-priv.h
+++ b/drivers/ufs/core/ufshcd-priv.h
@@ -241,6 +241,14 @@ static inline void ufshcd_vops_config_scaling_param(struct ufs_hba *hba,
 		hba->vops->config_scaling_param(hba, p, data);
 }
 
+static inline u32 ufshcd_vops_config_qos_vote(struct ufs_hba *hba)
+{
+	if (hba->vops && hba->vops->config_qos_vote)
+		return hba->vops->config_qos_vote(hba);
+
+	return UFSHCD_QOS_DEFAULT_VOTE;
+}
+
 static inline void ufshcd_vops_reinit_notify(struct ufs_hba *hba)
 {
 	if (hba->vops && hba->vops->reinit_notify)
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index ae9936fc6ffb..13370febd2b5 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1001,6 +1001,20 @@ static bool ufshcd_is_unipro_pa_params_tuning_req(struct ufs_hba *hba)
 	return ufshcd_get_local_unipro_ver(hba) < UFS_UNIPRO_VER_1_6;
 }
 
+/**
+ * ufshcd_pm_qos_perf - vote for PM QoS performance or power save mode
+ * @hba: per adapter instance
+ * @on: If True, vote for perf PM QoS mode otherwise power save mode
+ */
+static void ufshcd_pm_qos_perf(struct ufs_hba *hba, bool on)
+{
+	if (!hba->pm_qos_init)
+		return;
+
+	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? hba->qos_vote
+							: PM_QOS_DEFAULT_VALUE);
+}
+
 /**
  * ufshcd_set_clk_freq - set UFS controller clock frequencies
  * @hba: per adapter instance
@@ -1153,6 +1167,10 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, unsigned long freq,
 	trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
 			(scale_up ? "up" : "down"),
 			ktime_to_us(ktime_sub(ktime_get(), start)), ret);
+
+	if (!ret)
+		ufshcd_pm_qos_perf(hba, scale_up);
+
 	return ret;
 }
 
@@ -9204,6 +9222,8 @@ static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
 	if (ret)
 		return ret;
 
+	if (!ufshcd_is_clkscaling_supported(hba))
+		ufshcd_pm_qos_perf(hba, on);
 out:
 	if (ret) {
 		list_for_each_entry(clki, head, list) {
@@ -9296,6 +9316,45 @@ static int ufshcd_init_clocks(struct ufs_hba *hba)
 	return ret;
 }
 
+/**
+ * ufshcd_pm_qos_init - initialize PM QoS instance
+ * @hba: per adapter instance
+ */
+static void ufshcd_pm_qos_init(struct ufs_hba *hba)
+{
+	if (!(hba->caps & UFSHCD_CAP_PM_QOS))
+		return;
+
+	/*
+	 * called to configure PM QoS vote value for UFS host,
+	 * expecting qos vote return value from caller else
+	 * default vote value will be return.
+	 */
+	hba->qos_vote = ufshcd_vops_config_qos_vote(hba);
+	cpu_latency_qos_add_request(&hba->pm_qos_req,
+					PM_QOS_DEFAULT_VALUE);
+
+	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
+		hba->pm_qos_init = true;
+
+	dev_dbg(hba->dev, "%s: QoS %s, qos_vote: %u\n", __func__,
+		hba->pm_qos_init ? "initialized" : "uninitialized",
+		hba->qos_vote);
+}
+
+/**
+ * ufshcd_pm_qos_exit - remove instance from PM QoS
+ * @hba: per adapter instance
+ */
+static void ufshcd_pm_qos_exit(struct ufs_hba *hba)
+{
+	if (!hba->pm_qos_init)
+		return;
+
+	cpu_latency_qos_remove_request(&hba->pm_qos_req);
+	hba->pm_qos_init = false;
+}
+
 static int ufshcd_variant_hba_init(struct ufs_hba *hba)
 {
 	int err = 0;
@@ -9381,6 +9440,7 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
 static void ufshcd_hba_exit(struct ufs_hba *hba)
 {
 	if (hba->is_powered) {
+		ufshcd_pm_qos_exit(hba);
 		ufshcd_exit_clk_scaling(hba);
 		ufshcd_exit_clk_gating(hba);
 		if (hba->eh_wq)
@@ -10030,6 +10090,7 @@ static int ufshcd_suspend(struct ufs_hba *hba)
 	ufshcd_vreg_set_lpm(hba);
 	/* Put the host controller in low power mode if possible */
 	ufshcd_hba_vreg_set_lpm(hba);
+	ufshcd_pm_qos_perf(hba, false);
 	return ret;
 }
 
@@ -10576,6 +10637,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 	ufs_sysfs_add_nodes(hba->dev);
 
 	device_enable_async_suspend(dev);
+	ufshcd_pm_qos_init(hba);
 	return 0;
 
 free_tmf_queue:
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index d862c8ddce03..e9f2bad8934e 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -320,6 +320,9 @@ struct ufs_pwr_mode_info {
  * @phy_initialization: used to initialize phys
  * @device_reset: called to issue a reset pulse on the UFS device
  * @config_scaling_param: called to configure clock scaling parameters
+ * @config_qos_vote: called to configure PM QoS vote value for UFS host,
+ *		     expecting qos vote return value from caller else
+		     default vote value will be return
  * @program_key: program or evict an inline encryption key
  * @event_notify: called to notify important events
  * @reinit_notify: called to notify reinit of UFSHCD during max gear switch
@@ -362,6 +365,7 @@ struct ufs_hba_variant_ops {
 	void	(*config_scaling_param)(struct ufs_hba *hba,
 				struct devfreq_dev_profile *profile,
 				struct devfreq_simple_ondemand_data *data);
+	u32	(*config_qos_vote)(struct ufs_hba *hba);
 	int	(*program_key)(struct ufs_hba *hba,
 			       const union ufs_crypto_cfg_entry *cfg, int slot);
 	void	(*event_notify)(struct ufs_hba *hba,
@@ -720,6 +724,11 @@ enum ufshcd_caps {
 	 * WriteBooster when scaling the clock down.
 	 */
 	UFSHCD_CAP_WB_WITH_CLK_SCALING			= 1 << 12,
+
+	/* This capability allows the host controller driver to use the PM QoS
+	 * feature.
+	 */
+	UFSHCD_CAP_PM_QOS				= 1 << 13,
 };
 
 struct ufs_hba_variant_params {
@@ -793,6 +802,8 @@ enum ufshcd_mcq_opr {
 	OPR_MAX,
 };
 
+#define UFSHCD_QOS_DEFAULT_VOTE 0
+
 /**
  * struct ufs_hba - per adapter private structure
  * @mmio_base: UFSHCI base register address
@@ -912,6 +923,8 @@ enum ufshcd_mcq_opr {
  * @mcq_base: Multi circular queue registers base address
  * @uhq: array of supported hardware queues
  * @dev_cmd_queue: Queue for issuing device management commands
+ * @pm_qos_req: PM QoS request handle
+ * @pm_qos_init: flag to check if pm qos init completed
  */
 struct ufs_hba {
 	void __iomem *mmio_base;
@@ -1076,6 +1089,9 @@ struct ufs_hba {
 	struct ufs_hw_queue *uhq;
 	struct ufs_hw_queue *dev_cmd_queue;
 	struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
+	struct pm_qos_request pm_qos_req;
+	bool pm_qos_init;
+	u32 qos_vote;
 };
 
 /**
-- 
2.34.1



From quic_mnaresh at quicinc.com  Mon Dec  4 06:31:01 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Mon, 4 Dec 2023 20:01:01 +0530
Subject: [PATCH V2 3/3] ufs: ufs-qcom: Enable CPU latency QoS support for QCOM SoC
In-Reply-To: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
Message-ID: <20231204143101.64163-4-quic_mnaresh@quicinc.com>

Enable CPU latency PM QoS capability support for QCOM SoC.

Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/host/ufs-qcom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 96cb8b5b4e66..3211cccce933 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -1061,6 +1061,7 @@ static void ufs_qcom_set_caps(struct ufs_hba *hba)
 	hba->caps |= UFSHCD_CAP_WB_EN;
 	hba->caps |= UFSHCD_CAP_AGGR_POWER_COLLAPSE;
 	hba->caps |= UFSHCD_CAP_RPM_AUTOSUSPEND;
+	hba->caps |= UFSHCD_CAP_PM_QOS;
 
 	if (host->hw_ver.major >= 0x2) {
 		host->caps = UFS_QCOM_CAP_QUNIPRO |
-- 
2.34.1



From linus.walleij at linaro.org  Mon Dec  4 06:35:35 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 4 Dec 2023 15:35:35 +0100
Subject: [PATCH v4 00/23] pinctrl: Convert struct group_desc to use struct pingroup
In-Reply-To: <b2175abe-b989-4b77-891e-67e8240ba0be@linaro.org>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <CACRpkdZAriTP3iOgmwvoAH-3-aO_ugoEkBHE7mHH5YLxhMXSXg@mail.gmail.com> <b2175abe-b989-4b77-891e-67e8240ba0be@linaro.org>
Message-ID: <CACRpkdaTKAwCN_dbcAn_qKLi2R15=BzJjpg85XtL=Ap6ORSgUQ@mail.gmail.com>

On Mon, Dec 4, 2023 at 8:49?AM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
> On 01/12/2023 15:05, Linus Walleij wrote:
> > On Wed, Nov 29, 2023 at 5:15?PM Andy Shevchenko
> > <andriy.shevchenko at linux.intel.com> wrote:
> >
> >> The struct group_desc has a lot of duplication with struct pingroup.
> >> Deduplicate that by embeddind the latter in the former and convert
> >> users.
> >>
> >> Linus, assuming everything is fine, I can push this to my tree.
> >> Or you can apply it (assumming all CIs and people are happy with
> >> the series).
> >
> > I applied the series to devel so we get some rotation in linux-next,
> > augmenting the relevant commit messages as discussed!
> >
>
> ... and this next fails to build on standard defconfig:
> https://krzk.eu/#/builders/76/builds/420/steps/9/logs/stdio
>
> I did not bisect yet, so I am just guessing that error looks like
> something introduced here.

Ooops how unfortunate.

I actually thought the autobuilders grabbing patches from the mail lists
would have warned.

I dropped the majority of the patches (not the preparatory patches)
from my tree again, rinse and repeat.

Yours,
Linus Walleij


From quic_mnaresh at quicinc.com  Mon Dec  4 06:31:00 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Mon, 4 Dec 2023 20:01:00 +0530
Subject: [PATCH V2 2/3] ufs: ufs-mediatek: Enable CPU latency PM QoS support for MEDIATEK SoC
In-Reply-To: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
Message-ID: <20231204143101.64163-3-quic_mnaresh@quicinc.com>

Revert the existing PM QoS feature from MEDIATEK UFS driver as similar
PM QoS feature implementation is moved to core ufshcd and also enable
CPU latency PM QoS capability for MEDIATEK SoC.

Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/host/ufs-mediatek.c | 20 +++-----------------
 drivers/ufs/host/ufs-mediatek.h |  3 ---
 2 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index fc61790d289b..d8ece88103b9 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -17,7 +17,6 @@
 #include <linux/of_platform.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
-#include <linux/pm_qos.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
@@ -626,21 +625,9 @@ static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
 	dev_info(hba->dev, "caps: 0x%x", host->caps);
 }
 
-static void ufs_mtk_boost_pm_qos(struct ufs_hba *hba, bool boost)
-{
-	struct ufs_mtk_host *host = ufshcd_get_variant(hba);
-
-	if (!host || !host->pm_qos_init)
-		return;
-
-	cpu_latency_qos_update_request(&host->pm_qos_req,
-				       boost ? 0 : PM_QOS_DEFAULT_VALUE);
-}
-
 static void ufs_mtk_scale_perf(struct ufs_hba *hba, bool scale_up)
 {
 	ufs_mtk_boost_crypt(hba, scale_up);
-	ufs_mtk_boost_pm_qos(hba, scale_up);
 }
 
 static void ufs_mtk_pwr_ctrl(struct ufs_hba *hba, bool on)
@@ -937,6 +924,9 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 	/* Enable clk scaling*/
 	hba->caps |= UFSHCD_CAP_CLK_SCALING;
 
+	/* Enable PM QoS */
+	hba->caps |= UFSHCD_CAP_PM_QOS;
+
 	hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
 	hba->quirks |= UFSHCD_QUIRK_MCQ_BROKEN_INTR;
 	hba->quirks |= UFSHCD_QUIRK_MCQ_BROKEN_RTC;
@@ -959,10 +949,6 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
 	host->ip_ver = ufshcd_readl(hba, REG_UFS_MTK_IP_VER);
 
-	/* Initialize pm-qos request */
-	cpu_latency_qos_add_request(&host->pm_qos_req, PM_QOS_DEFAULT_VALUE);
-	host->pm_qos_init = true;
-
 	goto out;
 
 out_variant_clear:
diff --git a/drivers/ufs/host/ufs-mediatek.h b/drivers/ufs/host/ufs-mediatek.h
index f76e80d91729..38eab95b0f79 100644
--- a/drivers/ufs/host/ufs-mediatek.h
+++ b/drivers/ufs/host/ufs-mediatek.h
@@ -7,7 +7,6 @@
 #define _UFS_MEDIATEK_H
 
 #include <linux/bitops.h>
-#include <linux/pm_qos.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
 
 /*
@@ -167,7 +166,6 @@ struct ufs_mtk_mcq_intr_info {
 
 struct ufs_mtk_host {
 	struct phy *mphy;
-	struct pm_qos_request pm_qos_req;
 	struct regulator *reg_va09;
 	struct reset_control *hci_reset;
 	struct reset_control *unipro_reset;
@@ -178,7 +176,6 @@ struct ufs_mtk_host {
 	struct ufs_mtk_hw_ver hw_ver;
 	enum ufs_mtk_host_caps caps;
 	bool mphy_powered_on;
-	bool pm_qos_init;
 	bool unipro_lpm;
 	bool ref_clk_enabled;
 	u16 ref_clk_ungating_wait_us;
-- 
2.34.1



From maz at kernel.org  Mon Dec  4 06:36:03 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon,  4 Dec 2023 14:36:03 +0000
Subject: [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy
Message-ID: <20231204143606.1806432-1-maz@kernel.org>

ARMv8.2 introduced support for VPIPT i-caches, the V standing for
VMID-tagged. Although this looked like a reasonable idea, no
implementation has ever made it into the wild.

Linux has supported this for over 6 years (amusingly, just as the
architecture was dropping support for AIVIVT i-caches), but we had no
way to even test it, and it is likely that this code was just
bit-rotting.

However, in a recent breakthrough (XML drop 2023-09, tagged as
d55f5af8e09052abe92a02adf820deea2eaed717), the architecture has
finally been purged of this option, making VIPT and PIPT the only two
valid options.

This really means this code is just dead code. Nobody will ever come
up with such an implementation, and we can just get rid of it.

Most of the impact is on KVM, where we drop a few large comment blocks
(and a bit of code), while the core arch code loses the detection code
itself.

* From v2:
  - Fix reserved naming for RESERVED_AIVIVT
  - Collected RBs from Anshuman an Zenghui

Marc Zyngier (3):
  KVM: arm64: Remove VPIPT I-cache handling
  arm64: Kill detection of VPIPT i-cache policy
  arm64: Rename reserved values for CTR_EL0.L1Ip

 arch/arm64/include/asm/cache.h   |  6 ----
 arch/arm64/include/asm/kvm_mmu.h |  7 ----
 arch/arm64/kernel/cpuinfo.c      |  5 ---
 arch/arm64/kvm/hyp/nvhe/pkvm.c   |  2 +-
 arch/arm64/kvm/hyp/nvhe/tlb.c    | 61 --------------------------------
 arch/arm64/kvm/hyp/vhe/tlb.c     | 13 -------
 arch/arm64/tools/sysreg          |  5 +--
 7 files changed, 4 insertions(+), 95 deletions(-)

-- 
2.39.2



From maz at kernel.org  Mon Dec  4 06:36:04 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon,  4 Dec 2023 14:36:04 +0000
Subject: [PATCH v3 1/3] KVM: arm64: Remove VPIPT I-cache handling
In-Reply-To: <20231204143606.1806432-1-maz@kernel.org>
References: <20231204143606.1806432-1-maz@kernel.org>
Message-ID: <20231204143606.1806432-2-maz@kernel.org>

We have some special handling for VPIPT I-cache in critical parts
of the cache and TLB maintenance. Remove it.

Reviewed-by: Zenghui Yu <yuzenghui at huawei.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/include/asm/kvm_mmu.h |  7 ----
 arch/arm64/kvm/hyp/nvhe/pkvm.c   |  2 +-
 arch/arm64/kvm/hyp/nvhe/tlb.c    | 61 --------------------------------
 arch/arm64/kvm/hyp/vhe/tlb.c     | 13 -------
 4 files changed, 1 insertion(+), 82 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 49e0d4b36bd0..e3e793d0ec30 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -243,13 +243,6 @@ static inline size_t __invalidate_icache_max_range(void)
 
 static inline void __invalidate_icache_guest_page(void *va, size_t size)
 {
-	/*
-	 * VPIPT I-cache maintenance must be done from EL2. See comment in the
-	 * nVHE flavor of __kvm_tlb_flush_vmid_ipa().
-	 */
-	if (icache_is_vpipt() && read_sysreg(CurrentEL) != CurrentEL_EL2)
-		return;
-
 	/*
 	 * Blow the whole I-cache if it is aliasing (i.e. VIPT) or the
 	 * invalidation range exceeds our arbitrary limit on invadations by
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 9d23a51d7f75..b29f15418c0a 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -12,7 +12,7 @@
 #include <nvhe/pkvm.h>
 #include <nvhe/trap_handler.h>
 
-/* Used by icache_is_vpipt(). */
+/* Used by icache_is_aliasing(). */
 unsigned long __icache_flags;
 
 /* Used by kvm_get_vttbr(). */
diff --git a/arch/arm64/kvm/hyp/nvhe/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
index 1b265713d6be..a60fb13e2192 100644
--- a/arch/arm64/kvm/hyp/nvhe/tlb.c
+++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
@@ -105,28 +105,6 @@ void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu,
 	dsb(ish);
 	isb();
 
-	/*
-	 * If the host is running at EL1 and we have a VPIPT I-cache,
-	 * then we must perform I-cache maintenance at EL2 in order for
-	 * it to have an effect on the guest. Since the guest cannot hit
-	 * I-cache lines allocated with a different VMID, we don't need
-	 * to worry about junk out of guest reset (we nuke the I-cache on
-	 * VMID rollover), but we do need to be careful when remapping
-	 * executable pages for the same guest. This can happen when KSM
-	 * takes a CoW fault on an executable page, copies the page into
-	 * a page that was previously mapped in the guest and then needs
-	 * to invalidate the guest view of the I-cache for that page
-	 * from EL1. To solve this, we invalidate the entire I-cache when
-	 * unmapping a page from a guest if we have a VPIPT I-cache but
-	 * the host is running at EL1. As above, we could do better if
-	 * we had the VA.
-	 *
-	 * The moral of this story is: if you have a VPIPT I-cache, then
-	 * you should be running with VHE enabled.
-	 */
-	if (icache_is_vpipt())
-		icache_inval_all_pou();
-
 	__tlb_switch_to_host(&cxt);
 }
 
@@ -157,28 +135,6 @@ void __kvm_tlb_flush_vmid_ipa_nsh(struct kvm_s2_mmu *mmu,
 	dsb(nsh);
 	isb();
 
-	/*
-	 * If the host is running at EL1 and we have a VPIPT I-cache,
-	 * then we must perform I-cache maintenance at EL2 in order for
-	 * it to have an effect on the guest. Since the guest cannot hit
-	 * I-cache lines allocated with a different VMID, we don't need
-	 * to worry about junk out of guest reset (we nuke the I-cache on
-	 * VMID rollover), but we do need to be careful when remapping
-	 * executable pages for the same guest. This can happen when KSM
-	 * takes a CoW fault on an executable page, copies the page into
-	 * a page that was previously mapped in the guest and then needs
-	 * to invalidate the guest view of the I-cache for that page
-	 * from EL1. To solve this, we invalidate the entire I-cache when
-	 * unmapping a page from a guest if we have a VPIPT I-cache but
-	 * the host is running at EL1. As above, we could do better if
-	 * we had the VA.
-	 *
-	 * The moral of this story is: if you have a VPIPT I-cache, then
-	 * you should be running with VHE enabled.
-	 */
-	if (icache_is_vpipt())
-		icache_inval_all_pou();
-
 	__tlb_switch_to_host(&cxt);
 }
 
@@ -205,10 +161,6 @@ void __kvm_tlb_flush_vmid_range(struct kvm_s2_mmu *mmu,
 	dsb(ish);
 	isb();
 
-	/* See the comment in __kvm_tlb_flush_vmid_ipa() */
-	if (icache_is_vpipt())
-		icache_inval_all_pou();
-
 	__tlb_switch_to_host(&cxt);
 }
 
@@ -246,18 +198,5 @@ void __kvm_flush_vm_context(void)
 	/* Same remark as in __tlb_switch_to_guest() */
 	dsb(ish);
 	__tlbi(alle1is);
-
-	/*
-	 * VIPT and PIPT caches are not affected by VMID, so no maintenance
-	 * is necessary across a VMID rollover.
-	 *
-	 * VPIPT caches constrain lookup and maintenance to the active VMID,
-	 * so we need to invalidate lines with a stale VMID to avoid an ABA
-	 * race after multiple rollovers.
-	 *
-	 */
-	if (icache_is_vpipt())
-		asm volatile("ic ialluis");
-
 	dsb(ish);
 }
diff --git a/arch/arm64/kvm/hyp/vhe/tlb.c b/arch/arm64/kvm/hyp/vhe/tlb.c
index b636b4111dbf..b32e2940df7d 100644
--- a/arch/arm64/kvm/hyp/vhe/tlb.c
+++ b/arch/arm64/kvm/hyp/vhe/tlb.c
@@ -216,18 +216,5 @@ void __kvm_flush_vm_context(void)
 {
 	dsb(ishst);
 	__tlbi(alle1is);
-
-	/*
-	 * VIPT and PIPT caches are not affected by VMID, so no maintenance
-	 * is necessary across a VMID rollover.
-	 *
-	 * VPIPT caches constrain lookup and maintenance to the active VMID,
-	 * so we need to invalidate lines with a stale VMID to avoid an ABA
-	 * race after multiple rollovers.
-	 *
-	 */
-	if (icache_is_vpipt())
-		asm volatile("ic ialluis");
-
 	dsb(ish);
 }
-- 
2.39.2



From maz at kernel.org  Mon Dec  4 06:36:06 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon,  4 Dec 2023 14:36:06 +0000
Subject: [PATCH v3 3/3] arm64: Rename reserved values for CTR_EL0.L1Ip
In-Reply-To: <20231204143606.1806432-1-maz@kernel.org>
References: <20231204143606.1806432-1-maz@kernel.org>
Message-ID: <20231204143606.1806432-4-maz@kernel.org>

We now have *two* values for CTR_EL0.L1Ip that are reserved.
Which makes things a bit awkward. In order to lift the ambiguity,
rename RESERVED (0b01) to RESERVED_AIVIVT, and VPIPT (0b00) to
RESERVED_VPIPT.

This makes it clear which of these meant what, and I'm sure
archeologists will find it useful...

Reviewed-by: Zenghui Yu <yuzenghui at huawei.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/tools/sysreg | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 96cbeeab4eec..c5af75b23187 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2004,9 +2004,10 @@ Field	27:24	CWG
 Field	23:20	ERG
 Field	19:16	DminLine
 Enum	15:14	L1Ip
-	0b00	VPIPT
+	# This was named as VPIPT in the ARM but now documented as reserved
+	0b00	RESERVED_VPIPT
 	# This is named as AIVIVT in the ARM but documented as reserved
-	0b01	RESERVED
+	0b01	RESERVED_AIVIVT
 	0b10	VIPT
 	0b11	PIPT
 EndEnum
-- 
2.39.2



From maz at kernel.org  Mon Dec  4 06:36:05 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon,  4 Dec 2023 14:36:05 +0000
Subject: [PATCH v3 2/3] arm64: Kill detection of VPIPT i-cache policy
In-Reply-To: <20231204143606.1806432-1-maz@kernel.org>
References: <20231204143606.1806432-1-maz@kernel.org>
Message-ID: <20231204143606.1806432-3-maz@kernel.org>

Since the kernel will never run on a system with the VPIPT i-cache
policy, drop the detection code altogether.

Reviewed-by: Zenghui Yu <yuzenghui at huawei.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/include/asm/cache.h | 6 ------
 arch/arm64/kernel/cpuinfo.c    | 5 -----
 2 files changed, 11 deletions(-)

diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index ceb368d33bf4..06a4670bdb0b 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -58,7 +58,6 @@ static inline unsigned int arch_slab_minalign(void)
 #define CTR_L1IP(ctr)		SYS_FIELD_GET(CTR_EL0, L1Ip, ctr)
 
 #define ICACHEF_ALIASING	0
-#define ICACHEF_VPIPT		1
 extern unsigned long __icache_flags;
 
 /*
@@ -70,11 +69,6 @@ static inline int icache_is_aliasing(void)
 	return test_bit(ICACHEF_ALIASING, &__icache_flags);
 }
 
-static __always_inline int icache_is_vpipt(void)
-{
-	return test_bit(ICACHEF_VPIPT, &__icache_flags);
-}
-
 static inline u32 cache_type_cwg(void)
 {
 	return SYS_FIELD_GET(CTR_EL0, CWG, read_cpuid_cachetype());
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index a257da7b56fe..47043c0d95ec 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -36,8 +36,6 @@ static struct cpuinfo_arm64 boot_cpu_data;
 static inline const char *icache_policy_str(int l1ip)
 {
 	switch (l1ip) {
-	case CTR_EL0_L1Ip_VPIPT:
-		return "VPIPT";
 	case CTR_EL0_L1Ip_VIPT:
 		return "VIPT";
 	case CTR_EL0_L1Ip_PIPT:
@@ -388,9 +386,6 @@ static void cpuinfo_detect_icache_policy(struct cpuinfo_arm64 *info)
 	switch (l1ip) {
 	case CTR_EL0_L1Ip_PIPT:
 		break;
-	case CTR_EL0_L1Ip_VPIPT:
-		set_bit(ICACHEF_VPIPT, &__icache_flags);
-		break;
 	case CTR_EL0_L1Ip_VIPT:
 	default:
 		/* Assume aliasing */
-- 
2.39.2



From jgg at nvidia.com  Mon Dec  4 06:36:50 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Mon, 4 Dec 2023 10:36:50 -0400
Subject: [PATCH v2 3/4] mm: Change ghes code to allow poison of
 non-struct pfn
In-Reply-To: <20231202232319.GAZWu8Z6gsLp1kI5Dw@fat_crate.local>
References: <20231123003513.24292-1-ankita@nvidia.com>
 <20231123003513.24292-4-ankita@nvidia.com>
 <20231202232319.GAZWu8Z6gsLp1kI5Dw@fat_crate.local>
Message-ID: <20231204143650.GB1493156@nvidia.com>

On Sun, Dec 03, 2023 at 12:23:19AM +0100, Borislav Petkov wrote:
> On Thu, Nov 23, 2023 at 06:05:11AM +0530, ankita at nvidia.com wrote:
> > -	pfn = PHYS_PFN(physical_addr);
> > -	if (!pfn_valid(pfn) && !arch_is_platform_page(physical_addr)) {
> > -		pr_warn_ratelimited(FW_WARN GHES_PFX
> > -		"Invalid address in generic error data: %#llx\n",
> > -		physical_addr);
> > -		return false;
> > -	}
> 
> You don't just remove a pfn valid test just because your weird device
> can't stomach it - you extend it, like

It wasn't removed. patch 1 moved it to memory_failure() where it makes
a lot more sense.

Jason


From mark.rutland at arm.com  Mon Dec  4 06:37:58 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 4 Dec 2023 14:37:58 +0000
Subject: [PATCH v6 03/41] arm64: mm: get rid of kimage_vaddr global
 variable
In-Reply-To: <2fabeac2-a1c1-4e10-b7f5-33de8d502e4d@arm.com>
References: <20231129111555.3594833-43-ardb@google.com>
 <20231129111555.3594833-46-ardb@google.com>
 <2fabeac2-a1c1-4e10-b7f5-33de8d502e4d@arm.com>
Message-ID: <ZW3kRg9a30FTe1ru@FVFF77S0Q05N>

On Thu, Nov 30, 2023 at 11:08:59AM +0530, Anshuman Khandual wrote:
> 
> 
> On 11/29/23 16:45, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb at kernel.org>
> > 
> > We store the address of _text in kimage_vaddr, but since commit
> > 09e3c22a86f6889d ("arm64: Use a variable to store non-global mappings
> > decision"), we no longer reference this variable from modules so we no
> > longer need to export it.
> > 
> > In fact, we don't need it at all so let's just get rid of it.
> > 
> > Acked-by: Mark Rutland <mark.rutland at arm.com>
> > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> 
> There is a checkpatch.pl error for this patch.
> 
> --------
> ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' -
> ie: 'commit 09e3c22a86f6 ("arm64: Use a variable to store non-global mappings decision")'
> #6: 
> We store the address of _text in kimage_vaddr, but since commit
> --------

That looks like a spurious warning. Ard wrote:

  [...] commit 09e3c22a86f6889d ("arm64: Use a variable to store non-global
  mappings decision"), [...]

... which is 'commit <16 chars of sha1> ("<title line>")', just as the
checkpatch message says.

Clearly, this checkpatch warning isn't helpful.

Regardless of whether the warning is spurious, please use judgement for
checkpatch warnings. They're not always a hard rule to be followed.

Mark.


From linus.walleij at linaro.org  Mon Dec  4 06:38:43 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 4 Dec 2023 15:38:43 +0100
Subject: [PATCH v4 00/23] pinctrl: Convert struct group_desc to use struct pingroup
In-Reply-To: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
Message-ID: <CACRpkdZhpXcx2FZYKM69j3x4dP5Nu-=3sXW+BQAw3k6c5aRrWw@mail.gmail.com>

Hi Andy,

due to compile errors on arm32 and arm64 I had to drop most of the
patches again but I kept the preparatory patches so your
patch stack don't need to be so deep.

On Wed, Nov 29, 2023 at 5:15?PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:

> Andy Shevchenko (23):
>   pinctrl: qcom: lpass-lpi: Replace kernel.h with what is being used
>   pinctrl: qcom: lpass-lpi: Remove unused member in struct lpi_pingroup
>   pinctrl: equilibrium: Unshadow error code of
>     of_property_count_u32_elems()
>   pinctrl: equilibrium: Use temporary variable to hold pins
>   pinctrl: imx: Use temporary variable to hold pins

I kept these.

>   pinctrl: core: Make pins const unsigned int pointer in struct
>     group_desc
>   pinctrl: equilibrium: Convert to use struct pingroup
>   pinctrl: keembay: Convert to use struct pingroup
>   pinctrl: nuvoton: Convert to use struct pingroup and
>     PINCTRL_PINGROUP()
>   pinctrl: core: Add a convenient define PINCTRL_GROUP_DESC()
>   pinctrl: ingenic: Make use of PINCTRL_GROUP_DESC()
>   pinctrl: mediatek: Make use of PINCTRL_GROUP_DESC()
>   pinctrl: core: Embed struct pingroup into struct group_desc
>   pinctrl: bcm: Convert to use grp member
>   pinctrl: equilibrium: Convert to use grp member
>   pinctrl: imx: Convert to use grp member
>   pinctrl: ingenic: Convert to use grp member
>   pinctrl: keembay: Convert to use grp member
>   pinctrl: mediatek: Convert to use grp member
>   pinctrl: renesas: Convert to use grp member
>   pinctrl: starfive: Convert to use grp member
>   pinctrl: core: Remove unused members from struct group_desc

I dropped these (because they all cross-depend...)

>   pinctrl: Convert unsigned to unsigned int

I kept this one.

Yours,
Linus Walleij


From linux.amoon at gmail.com  Mon Dec  4 06:44:26 2023
From: linux.amoon at gmail.com (Anand Moon)
Date: Mon,  4 Dec 2023 20:14:26 +0530
Subject: [PATCH v6 2/2] arm64: dts: amlogic: Used onboard usb hub reset on odroid n2
In-Reply-To: <20231204144429.45197-1-linux.amoon@gmail.com>
References: <20231204144429.45197-1-linux.amoon@gmail.com>
Message-ID: <20231204144429.45197-3-linux.amoon@gmail.com>

On Odroid n2/n2+ previously use gpio-hog to reset the usb hub,
switch to used on-board usb hub reset to enable the usb hub
and enable power to hub.

Signed-off-by: Anand Moon <linux.amoon at gmail.com>
---
V6:none
V5:none
V4:none
V3:none
V2:none
V1:none
---
 .../dts/amlogic/meson-g12b-odroid-n2.dtsi     | 36 ++++++++++++-------
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
index 91c9769fda20..9e671444eca6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
@@ -31,6 +31,30 @@ hub_5v: regulator-hub_5v {
 		enable-active-high;
 	};
 
+	/* USB hub supports both USB 2.0 and USB 3.0 root hub */
+	usb-hub {
+		dr_mode = "host";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		/* 2.0 hub on port 1 */
+		hub_2_0: hub at 1 {
+			compatible = "usb5e3,610";
+			reg = <1>;
+			peer-hub = <&hub_3_0>;
+			vdd-supply = <&usb_pwr_en>;
+		};
+
+		/* 3.0 hub on port 4 */
+		hub_3_0: hub at 2 {
+			compatible = "usb5e3,620";
+			reg = <2>;
+			peer-hub = <&hub_2_0>;
+			reset-gpios = <&gpio GPIOH_4 GPIO_ACTIVE_LOW>;
+			vdd-supply = <&vcc_5v>;
+		};
+	};
+
 	sound {
 		compatible = "amlogic,axg-sound-card";
 		model = "ODROID-N2";
@@ -234,18 +258,6 @@ &gpio {
 		"PIN_3",  /* GPIOX_17 */
 		"PIN_5",  /* GPIOX_18 */
 		"PIN_36"; /* GPIOX_19 */
-	/*
-	 * WARNING: The USB Hub on the Odroid-N2 needs a reset signal
-	 * to be turned high in order to be detected by the USB Controller
-	 * This signal should be handled by a USB specific power sequence
-	 * in order to reset the Hub when USB bus is powered down.
-	 */
-	usb-hub-hog {
-		gpio-hog;
-		gpios = <GPIOH_4 GPIO_ACTIVE_HIGH>;
-		output-high;
-		line-name = "usb-hub-reset";
-	};
 };
 
 &i2c3 {
-- 
2.42.0



From mark.rutland at arm.com  Mon Dec  4 06:44:56 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 4 Dec 2023 14:44:56 +0000
Subject: [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy
In-Reply-To: <20231204143606.1806432-1-maz@kernel.org>
References: <20231204143606.1806432-1-maz@kernel.org>
Message-ID: <ZW3l6Bq7ortEGB8I@FVFF77S0Q05N>

On Mon, Dec 04, 2023 at 02:36:03PM +0000, Marc Zyngier wrote:
> ARMv8.2 introduced support for VPIPT i-caches, the V standing for
> VMID-tagged. Although this looked like a reasonable idea, no
> implementation has ever made it into the wild.
> 
> Linux has supported this for over 6 years (amusingly, just as the
> architecture was dropping support for AIVIVT i-caches), but we had no
> way to even test it, and it is likely that this code was just
> bit-rotting.
> 
> However, in a recent breakthrough (XML drop 2023-09, tagged as
> d55f5af8e09052abe92a02adf820deea2eaed717), the architecture has
> finally been purged of this option, making VIPT and PIPT the only two
> valid options.
> 
> This really means this code is just dead code. Nobody will ever come
> up with such an implementation, and we can just get rid of it.
> 
> Most of the impact is on KVM, where we drop a few large comment blocks
> (and a bit of code), while the core arch code loses the detection code
> itself.
> 
> * From v2:
>   - Fix reserved naming for RESERVED_AIVIVT
>   - Collected RBs from Anshuman an Zenghui
> 
> Marc Zyngier (3):
>   KVM: arm64: Remove VPIPT I-cache handling
>   arm64: Kill detection of VPIPT i-cache policy
>   arm64: Rename reserved values for CTR_EL0.L1Ip

For the series:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Looking forward, we can/should probably replace __icache_flags with a single
ICACHE_NOALIASING or ICACHE_PIPT cpucap, which'd get rid of a bunch of
duplicated logic and make that more sound in the case of races around cpu
onlining.

Mark.

> 
>  arch/arm64/include/asm/cache.h   |  6 ----
>  arch/arm64/include/asm/kvm_mmu.h |  7 ----
>  arch/arm64/kernel/cpuinfo.c      |  5 ---
>  arch/arm64/kvm/hyp/nvhe/pkvm.c   |  2 +-
>  arch/arm64/kvm/hyp/nvhe/tlb.c    | 61 --------------------------------
>  arch/arm64/kvm/hyp/vhe/tlb.c     | 13 -------
>  arch/arm64/tools/sysreg          |  5 +--
>  7 files changed, 4 insertions(+), 95 deletions(-)
> 
> -- 
> 2.39.2
> 
> 


From andriy.shevchenko at linux.intel.com  Mon Dec  4 06:49:28 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 4 Dec 2023 16:49:28 +0200
Subject: [PATCH v4 00/23] pinctrl: Convert struct group_desc to use
 struct pingroup
In-Reply-To: <CACRpkdZhpXcx2FZYKM69j3x4dP5Nu-=3sXW+BQAw3k6c5aRrWw@mail.gmail.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <CACRpkdZhpXcx2FZYKM69j3x4dP5Nu-=3sXW+BQAw3k6c5aRrWw@mail.gmail.com>
Message-ID: <ZW3m-KDhs39i0E5n@smile.fi.intel.com>

On Mon, Dec 04, 2023 at 03:38:43PM +0100, Linus Walleij wrote:
> Hi Andy,
> 
> due to compile errors on arm32 and arm64 I had to drop most of the
> patches again but I kept the preparatory patches so your
> patch stack don't need to be so deep.

Thank you!

...

> >   pinctrl: core: Make pins const unsigned int pointer in struct
> >     group_desc
> >   pinctrl: equilibrium: Convert to use struct pingroup
> >   pinctrl: keembay: Convert to use struct pingroup
> >   pinctrl: nuvoton: Convert to use struct pingroup and
> >     PINCTRL_PINGROUP()

Hmm... Why these to be dropped?

> >   pinctrl: core: Add a convenient define PINCTRL_GROUP_DESC()
> >   pinctrl: ingenic: Make use of PINCTRL_GROUP_DESC()
> >   pinctrl: mediatek: Make use of PINCTRL_GROUP_DESC()
> >   pinctrl: core: Embed struct pingroup into struct group_desc
> >   pinctrl: bcm: Convert to use grp member
> >   pinctrl: equilibrium: Convert to use grp member
> >   pinctrl: imx: Convert to use grp member
> >   pinctrl: ingenic: Convert to use grp member
> >   pinctrl: keembay: Convert to use grp member
> >   pinctrl: mediatek: Convert to use grp member
> >   pinctrl: renesas: Convert to use grp member
> >   pinctrl: starfive: Convert to use grp member
> >   pinctrl: core: Remove unused members from struct group_desc
> 
> I dropped these (because they all cross-depend...)

-- 
With Best Regards,
Andy Shevchenko




From willemdebruijn.kernel at gmail.com  Mon Dec  4 06:54:40 2023
From: willemdebruijn.kernel at gmail.com (Willem de Bruijn)
Date: Mon, 04 Dec 2023 09:54:40 -0500
Subject: [PATCH bpf-next v3 2/3] net: stmmac: add Launch Time support to
 XDP ZC
In-Reply-To: <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com>
 <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
Message-ID: <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>

Jesper Dangaard Brouer wrote:
> 
> 
> On 12/3/23 17:51, Song Yoong Siang wrote:
> > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > copy via XDP Tx metadata framework.
> > 
> > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > ---
> >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> 
> As requested before, I think we need to see another driver implementing 
> this.
> 
> I propose driver igc and chip i225.
> 
> The interesting thing for me is to see how the LaunchTime max 1 second
> into the future[1] is handled code wise. One suggestion is to add a 
> section to Documentation/networking/xsk-tx-metadata.rst per driver that 
> mentions/documents these different hardware limitations.  It is natural 
> that different types of hardware have limitations.  This is a close-to 
> hardware-level abstraction/API, and IMHO as long as we document the 
> limitations we can expose this API without too many limitations for more 
> capable hardware.

I would assume that the kfunc will fail when a value is passed that
cannot be programmed.

What is being implemented here already exists for qdiscs. The FQ
qdisc takes a horizon attribute and

    "
    when a packet is beyond the horizon
        at enqueue() time:
        - either drop the packet (default policy)
        - or cap its delivery time to the horizon.
    "
    commit 39d010504e6b ("net_sched: sch_fq: add horizon attribute")

Having the admin manually configure this on the qdisc based on
off-line knowledge of the device is more fragile than if the device
would somehow signal its limit to the stack.

But I don't think we should add enforcement of that as a requirement
for this xdp extension of pacing.


From willemdebruijn.kernel at gmail.com  Mon Dec  4 06:57:47 2023
From: willemdebruijn.kernel at gmail.com (Willem de Bruijn)
Date: Mon, 04 Dec 2023 09:57:47 -0500
Subject: [PATCH bpf-next v2 2/3] net: stmmac: Add txtime support to XDP ZC
In-Reply-To: <PH0PR11MB5830F08AC202C42501D986C0D887A@PH0PR11MB5830.namprd11.prod.outlook.com>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <20231201062421.1074768-3-yoong.siang.song@intel.com>
 <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org>
 <PH0PR11MB5830F08AC202C42501D986C0D887A@PH0PR11MB5830.namprd11.prod.outlook.com>
Message-ID: <656de8eb14c24_2e983e29435@willemb.c.googlers.com.notmuch>

Song, Yoong Siang wrote:
> On Friday, December 1, 2023 11:02 PM, Jesper Dangaard Brouer wrote:
> >On 12/1/23 07:24, Song Yoong Siang wrote:
> >> This patch enables txtime support to XDP zero copy via XDP Tx
> >> metadata framework.
> >>
> >> Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> >> ---
> >>   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> >>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++
> >>   2 files changed, 15 insertions(+)
> >
> >I think we need to see other drivers using this new feature to evaluate
> >if API is sane.
> >
> >I suggest implementing this for igc driver (chip i225) and also for igb
> >(i210 chip) that both support this kind of LaunchTime feature in HW.
> >
> >The API and stmmac driver takes a u64 as time.
> >I'm wondering how this applies to i210 that[1] have 25-bit for
> >LaunchTime (with 32 nanosec granularity) limiting LaunchTime max 0.5
> >second into the future.
> >And i225 that [1] have 30-bit max 1 second into the future.
> >
> >
> >[1]
> >https://github.com/xdp-project/xdp-
> >project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org
> 
> I am using u64 for launch time because existing EDT framework is using it.
> Refer to struct sk_buff below. Both u64 and ktime_t can be used as launch time.
> I choose u64 because ktime_t often requires additional type conversion and
> we didn't expect negative value of time.
> 
> include/linux/skbuff.h-744- *   @tstamp: Time we arrived/left
> include/linux/skbuff.h:745- *   @skb_mstamp_ns: (aka @tstamp) earliest departure time; start point
> include/linux/skbuff.h-746- *           for retransmit timer
> --
> include/linux/skbuff.h-880-     union {
> include/linux/skbuff.h-881-             ktime_t         tstamp;
> include/linux/skbuff.h:882-             u64             skb_mstamp_ns; /* earliest departure time */
> include/linux/skbuff.h-883-     };
> 
> tstamp/skb_mstamp_ns are used by various drivers for launch time support
> on normal packet, so I think u64 should be "friendly" to all the drivers. For an
> example, igc driver will take launch time from tstamp and recalculate it 
> accordingly (i225 expect user to program "delta time" instead of "time" into
> HW register).
> 
> drivers/net/ethernet/intel/igc/igc_main.c-1602- txtime = skb->tstamp;
> drivers/net/ethernet/intel/igc/igc_main.c-1603- skb->tstamp = ktime_set(0, 0);
> drivers/net/ethernet/intel/igc/igc_main.c:1604- launch_time = igc_tx_launchtime(tx_ring, txtime, &first_flag, &insert_empty);
> 
> Do you think this is enough to say the API is sane?

u64 nsec sounds sane to be. It must be made explicit with clock source
it is against.

Some applications could want to do the conversion from a clock source
to raw NIC cycle counter in userspace or BPF and program the raw
value. So it may be worthwhile to add an clock source argument -- even
if initially only CLOCK_MONOTONIC is supported.

See tools/testing/selftests/net/so_txtime.sh for how the FQ and ETF
qdiscs already disagree on the clock source that they use. 




From willemdebruijn.kernel at gmail.com  Mon Dec  4 06:59:31 2023
From: willemdebruijn.kernel at gmail.com (Willem de Bruijn)
Date: Mon, 04 Dec 2023 09:59:31 -0500
Subject: [PATCH bpf-next v3 3/3] selftests/bpf: add Launch Time request to
 xdp_hw_metadata
In-Reply-To: <8e20031c-83cb-4927-ab6a-e6b4840e1e42@kernel.org>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-4-yoong.siang.song@intel.com>
 <8e20031c-83cb-4927-ab6a-e6b4840e1e42@kernel.org>
Message-ID: <656de953bcc82_2e983e2949a@willemb.c.googlers.com.notmuch>

Jesper Dangaard Brouer wrote:
> 
> 
> On 12/3/23 17:51, Song Yoong Siang wrote:
> > This patch is tested with stmmac on Intel Tiger Lake platform. Refer to
> > result below, the delta between pre-determined launch time and actual HW
> > transmit complete time is around 24 us.
> 
> Is there any NIC setup (e.g. ethtool/qdisc) requirements to enable HW 
> for this feature?

Judging from how we currently use this with FQ and ETF, no.

See for instance tools/testing/selftests/net/so_txtime.sh



From arnd at arndb.de  Mon Dec  4 07:11:11 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 04 Dec 2023 16:11:11 +0100
Subject: arm: gcc-8: drivers/pinctrl/mediatek/../core.h:211:21: error: initializer
 element is not constant (struct group_desc)
In-Reply-To: <CA+G9fYs1g2Pt=DQeaJC+3ZJTeMwKAs9GuGJ9k6BcwKwEXcn5kQ@mail.gmail.com>
References: <CA+G9fYs1g2Pt=DQeaJC+3ZJTeMwKAs9GuGJ9k6BcwKwEXcn5kQ@mail.gmail.com>
Message-ID: <ad6afb94-e221-4adb-a942-af59f5d7b92f@app.fastmail.com>

On Mon, Dec 4, 2023, at 13:08, Naresh Kamboju wrote:
> Following build errors noticed on Linux next-20231204 tag with gcc-8 toolchain
> for arm and arm64.
>
> ## Test Regressions (compared to next-20231201)
> * arm, build
>   - gcc-8-defconfig
>
> * arm64, build
>   - gcc-8-defconfig
>
> Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
>
> Build log arm and arm64:
> ------------
> In file included from drivers/pinctrl/mediatek/pinctrl-moore.h:21,
>                  from drivers/pinctrl/mediatek/pinctrl-mt7623.c:11:
> drivers/pinctrl/mediatek/../core.h:211:21: error: initializer element
> is not constant
>  (struct group_desc) {      \


This apparently comes from c0c8dd0a7773 ("pinctrl: core: Add a
convenient define PINCTRL_GROUP_DESC()") and following patches
from Andy Shevchenko (added to Cc).

I also checked different compiler versions and found that the
new code works fine with gcc-13.2.0, but not with gcc-12 or
older.

      Arnd


From krzysztof.kozlowski at linaro.org  Mon Dec  4 07:11:48 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 16:11:48 +0100
Subject: [PATCH v3] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <7021717e2e747b9c119b7c5091b60bdf@manjaro.org>
References: <20231125184422.12315-1-krzysztof.kozlowski@linaro.org>
 <63ec18b2758a9e385f446fb00b60ee69@manjaro.org>
 <0bcc0679-b883-4435-8843-cc830122c0e1@linaro.org>
 <83b413441a953e8f2bc56adf09511a80@manjaro.org>
 <7021717e2e747b9c119b7c5091b60bdf@manjaro.org>
Message-ID: <95bb3618-496d-4b55-a2f7-1b4200cbe420@linaro.org>

On 03/12/2023 21:12, Dragan Simic wrote:
> Just a brief reminder about my suggestions below, which seemingly didn't 
> find their way into the v4.  At least the first one, which improves the 
> opening sentence, is worth including, IMHO.
> 

I applied almost all your suggestions, except few which I disagreed with
in my replies.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec  4 07:15:57 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 4 Dec 2023 16:15:57 +0100
Subject: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <2223b302fc43959a61578aae9cc3a15a@manjaro.org>
References: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
 <2223b302fc43959a61578aae9cc3a15a@manjaro.org>
Message-ID: <1d6625f0-1c69-46ea-86d1-c4adabfeefad@linaro.org>

On 03/12/2023 21:25, Dragan Simic wrote:
>> +Order of Properties in Device Node
>> +----------------------------------
>> +
>> +The following order of properties in device nodes is preferred:
>> +
>> +1. compatible
>> +2. reg
>> +3. ranges
>> +4. Standard/common properties (defined by common bindings, e.g. 
>> without
>> +   vendor-prefixes)
>> +5. Vendor-specific properties
>> +6. status (if applicable)
>> +7. Child nodes, where each node is preceded with a blank line
> 
> Another small suggestion...  It would be good to put the property names 
> found in the list items, such as "compatible" and "status", into 
> quotation marks, to make it obvious what they are.  That way, the list 
> would also be more consistent with the property names mentioned in the 
> sentence right below.

If there is going to be new version, I'll implement it. Otherwise it is
pickiness over style, not content essence.

Best regards,
Krzysztof



From andriy.shevchenko at linux.intel.com  Mon Dec  4 07:20:32 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 4 Dec 2023 17:20:32 +0200
Subject: arm: gcc-8: drivers/pinctrl/mediatek/../core.h:211:21: error:
 initializer element is not constant (struct group_desc)
In-Reply-To: <ad6afb94-e221-4adb-a942-af59f5d7b92f@app.fastmail.com>
References: <CA+G9fYs1g2Pt=DQeaJC+3ZJTeMwKAs9GuGJ9k6BcwKwEXcn5kQ@mail.gmail.com>
 <ad6afb94-e221-4adb-a942-af59f5d7b92f@app.fastmail.com>
Message-ID: <ZW3uQFWeogUhwuA9@smile.fi.intel.com>

On Mon, Dec 04, 2023 at 04:11:11PM +0100, Arnd Bergmann wrote:
> On Mon, Dec 4, 2023, at 13:08, Naresh Kamboju wrote:
> > Following build errors noticed on Linux next-20231204 tag with gcc-8 toolchain
> > for arm and arm64.
> >
> > ## Test Regressions (compared to next-20231201)
> > * arm, build
> >   - gcc-8-defconfig
> >
> > * arm64, build
> >   - gcc-8-defconfig
> >
> > Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
> >
> > Build log arm and arm64:
> > ------------
> > In file included from drivers/pinctrl/mediatek/pinctrl-moore.h:21,
> >                  from drivers/pinctrl/mediatek/pinctrl-mt7623.c:11:
> > drivers/pinctrl/mediatek/../core.h:211:21: error: initializer element
> > is not constant
> >  (struct group_desc) {      \
> 
> This apparently comes from c0c8dd0a7773 ("pinctrl: core: Add a
> convenient define PINCTRL_GROUP_DESC()") and following patches
> from Andy Shevchenko (added to Cc).
> 
> I also checked different compiler versions and found that the
> new code works fine with gcc-13.2.0, but not with gcc-12 or
> older.

Thank you, Linus already dropped problematic changes.

-- 
With Best Regards,
Andy Shevchenko




From knaerzche at gmail.com  Mon Dec  4 07:23:26 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon, 4 Dec 2023 16:23:26 +0100
Subject: [PATCH v2 2/5] ARM: dts: rockchip: Add power-controller for
 RK3128
In-Reply-To: <9588573.jRhZ6ZUK3Y@diego>
References: <20231202125144.66052-1-knaerzche@gmail.com>
 <4891026.6YUMPnJmAY@diego> <4dec2316-f840-44ab-a07a-3d7f0e5e6d8f@gmail.com>
 <9588573.jRhZ6ZUK3Y@diego>
Message-ID: <e58f5aa5-a4d4-4334-a7ff-aa139ec7166f@gmail.com>

Hi Heiko,

Am 03.12.23 um 17:42 schrieb Heiko St?bner:
> Hi Alex,
>
> Am Sonntag, 3. Dezember 2023, 17:05:47 CET schrieb Alex Bee:
>> Am 02.12.23 um 18:46 schrieb Heiko St?bner:
>>> Am Samstag, 2. Dezember 2023, 17:36:15 CET schrieb Alex Bee:
>>>> Am 02.12.23 um 16:51 schrieb Heiko St?bner:
>>>>> Am Samstag, 2. Dezember 2023, 13:51:41 CET schrieb Alex Bee:
>>>>>> Add power controller and qos nodes for RK3128 in order to use
>>>>>> them as powerdomains.
>>>>> does the power-domain controller work with the incomplete set of
>>>>> pm-domains too?
>>>> Yes, it does - the missing domains can request idle only and can't be
>>>> powered on/off - if no one requests idle they are just up all the time.
>>>>
>>>>> What I have in mind is
>>>>> - adding the power-controller node with the existing set of power-domains
>>>>> - the gpu pm-domain is in there
>>>>> - adding the gpu parts
>>>> My main concern about adding them later was the change of the ABI after
>>>> they've been exposed in the SoC DT. If that's not an issue - sure: I can
>>>> add them in a separate series.
>>> An ABI change would be _changing_ the domain-ids in the rk3128-power.h
>>> I think :-) .
>> Well, an addition is still a change.
>>> Right now the existing domain ids in the header are already exposed to the
>>> world, so someone could already use them, but not the new ones.
>> I'm fully aware that nothing would ever hard fail anywhere if the new
>> domain ids get added later.
>>
>> Nevertheless we start using here an ABI which is known to be incomplete.
>> For no reason, as the patches (which I am now asked to remove from this
>> series) for completion are already there (here).
>>
>> Anyway, if you prefer it this way: I'm pleased to do so.
> I was more thinking of accelerating the gpu-part of the series, as that
> really is just waiting for the power-domain node that already has driver
> support and domain-ids present.
>
> It looks like you're feeling more strongly about that though, so I'll
> definitly not pressure you ;-) .

I'm really not insisting on this - I just didn't understand why you 
would want this. And honestly I haven't considered merging timeline as 
an argument.

So sure: Let's get the low hanging fruits merged for 6.8. Having the 
power domains in the DT will also help for my upcoming hdmi / vop series.

Alex

>
> But I guess the split into IDs and driver change should still be
> done, especially as the dt-binding-header likely will want an Ack
> from the DT maintainers.
>
> And the power-domain change will go through the new pmdomain
> subsystem.
>
>
> Heiko
>
>
>>>>> And a second series with
>>>>> - patch1 from here
>>>>> - a dts patch adding the additional pm-domains to rk3128.dtsi
>>>>> - I guess patch1 also should be split into a patch adding the binding-ids
>>>>>      and a separate patch for the code addition.
>>>> Yeah, I noticed this also :)
>>>>
>>>> Regards,
>>>>
>>>> Alex
>>>>
>>>>> Heiko
>>>>>
>>>>>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>>>>>> ---
>>>>>>     arch/arm/boot/dts/rockchip/rk3128.dtsi | 101 +++++++++++++++++++++++++
>>>>>>     1 file changed, 101 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>>>>>> index 4e8b38604ecd..b72905db04f7 100644
>>>>>> --- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
>>>>>> +++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>>>>>> @@ -8,6 +8,7 @@
>>>>>>     #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>>>     #include <dt-bindings/interrupt-controller/irq.h>
>>>>>>     #include <dt-bindings/pinctrl/rockchip.h>
>>>>>> +#include <dt-bindings/power/rk3128-power.h>
>>>>>>     
>>>>>>     / {
>>>>>>     	compatible = "rockchip,rk3128";
>>>>>> @@ -133,6 +134,106 @@ smp-sram at 0 {
>>>>>>     	pmu: syscon at 100a0000 {
>>>>>>     		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
>>>>>>     		reg = <0x100a0000 0x1000>;
>>>>>> +
>>>>>> +		power: power-controller {
>>>>>> +			compatible = "rockchip,rk3128-power-controller";
>>>>>> +			#power-domain-cells = <1>;
>>>>>> +			#address-cells = <1>;
>>>>>> +			#size-cells = <0>;
>>>>>> +
>>>>>> +			power-domain at RK3128_PD_VIO {
>>>>>> +				reg = <RK3128_PD_VIO>;
>>>>>> +				clocks = <&cru ACLK_CIF>,
>>>>>> +					 <&cru HCLK_CIF>,
>>>>>> +					 <&cru DCLK_EBC>,
>>>>>> +					 <&cru HCLK_EBC>,
>>>>>> +					 <&cru ACLK_IEP>,
>>>>>> +					 <&cru HCLK_IEP>,
>>>>>> +					 <&cru ACLK_LCDC0>,
>>>>>> +					 <&cru HCLK_LCDC0>,
>>>>>> +					 <&cru PCLK_MIPI>,
>>>>>> +					 <&cru ACLK_RGA>,
>>>>>> +					 <&cru HCLK_RGA>,
>>>>>> +					 <&cru ACLK_VIO0>,
>>>>>> +					 <&cru ACLK_VIO1>,
>>>>>> +					 <&cru HCLK_VIO>,
>>>>>> +					 <&cru HCLK_VIO_H2P>,
>>>>>> +					 <&cru DCLK_VOP>,
>>>>>> +					 <&cru SCLK_VOP>;
>>>>>> +				pm_qos = <&qos_ebc>,
>>>>>> +					 <&qos_iep>,
>>>>>> +					 <&qos_lcdc>,
>>>>>> +					 <&qos_rga>,
>>>>>> +					 <&qos_vip>;
>>>>>> +				#power-domain-cells = <0>;
>>>>>> +			};
>>>>>> +
>>>>>> +			power-domain at RK3128_PD_VIDEO {
>>>>>> +				reg = <RK3128_PD_VIDEO>;
>>>>>> +				clocks = <&cru ACLK_VDPU>,
>>>>>> +					 <&cru HCLK_VDPU>,
>>>>>> +					 <&cru ACLK_VEPU>,
>>>>>> +					 <&cru HCLK_VEPU>,
>>>>>> +					 <&cru SCLK_HEVC_CORE>;
>>>>>> +				pm_qos = <&qos_vpu>;
>>>>>> +				#power-domain-cells = <0>;
>>>>>> +			};
>>>>>> +
>>>>>> +			power-domain at RK3128_PD_GPU {
>>>>>> +				reg = <RK3128_PD_GPU>;
>>>>>> +				clocks = <&cru ACLK_GPU>;
>>>>>> +				pm_qos = <&qos_gpu>;
>>>>>> +				#power-domain-cells = <0>;
>>>>>> +			};
>>>>>> +
>>>>>> +			power-domain at RK3128_PD_CRYPTO {
>>>>>> +				reg = <RK3128_PD_CRYPTO>;
>>>>>> +				clocks = <&cru HCLK_CRYPTO>,
>>>>>> +					 <&cru SCLK_CRYPTO>;
>>>>>> +				pm_qos = <&qos_crypto>;
>>>>>> +				#power-domain-cells = <0>;
>>>>>> +			};
>>>>>> +		};
>>>>>> +	};
>>>>>> +
>>>>>> +	qos_crypto: qos at 10128080 {
>>>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>>>> +		reg = <0x10128080 0x20>;
>>>>>> +	};
>>>>>> +
>>>>>> +	qos_gpu: qos at 1012d000 {
>>>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>>>> +		reg = <0x1012d000 0x20>;
>>>>>> +	};
>>>>>> +
>>>>>> +	qos_vpu: qos at 1012e000 {
>>>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>>>> +		reg = <0x1012e000 0x20>;
>>>>>> +	};
>>>>>> +
>>>>>> +	qos_rga: qos at 1012f000 {
>>>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>>>> +		reg = <0x1012f000 0x20>;
>>>>>> +	};
>>>>>> +
>>>>>> +	qos_ebc: qos at 1012f080 {
>>>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>>>> +		reg = <0x1012f080 0x20>;
>>>>>> +	};
>>>>>> +
>>>>>> +	qos_iep: qos at 1012f100 {
>>>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>>>> +		reg = <0x1012f100 0x20>;
>>>>>> +	};
>>>>>> +
>>>>>> +	qos_lcdc: qos at 1012f180 {
>>>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>>>> +		reg = <0x1012f180 0x20>;
>>>>>> +	};
>>>>>> +
>>>>>> +	qos_vip: qos at 1012f200 {
>>>>>> +		compatible = "rockchip,rk3128-qos", "syscon";
>>>>>> +		reg = <0x1012f200 0x20>;
>>>>>>     	};
>>>>>>     
>>>>>>     	gic: interrupt-controller at 10139000 {
>>>>>>
>>>>>
>>>
>>>
>
>
>


From arnd at arndb.de  Mon Dec  4 07:25:31 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 04 Dec 2023 16:25:31 +0100
Subject: [PATCH v2] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <20231201232614.jvj4d5nu7j2xf5ia@ability>
References: <20231201171544.1901-1-francesco@dolcini.it>
 <20231201191958.kmwkpmttmebsas47@kooky>
 <ZWo5kVMoLTzST6F5@livingston.pivistrello.it>
 <20231201232614.jvj4d5nu7j2xf5ia@ability>
Message-ID: <b1ed5744-5262-492b-af26-96c70982ab1e@app.fastmail.com>

On Sat, Dec 2, 2023, at 00:26, Nishanth Menon wrote:
> On 20:52-20231201, Francesco Dolcini wrote:
>> On Fri, Dec 01, 2023 at 01:19:58PM -0600, Nishanth Menon wrote:
>> > On 18:15-20231201, Francesco Dolcini wrote:
>> To me Arnd was just stating a fact, not raising a concern that was supposed
>> to be addressed (just correct me if I'm wrong, of course).
>> 
>> [1] well, apart AMD Pensando and Bitmain, at the moment, but you get the
>> point, I'm sure ;-).
>> 
>
> Hehe, thanks Francesco.
>
> Arnd, my memory was a bit right on the topic though.. .. I think we
> had gone down a similar road before in trying to increase the number
> of 8250 UARTs [1] but without this strong a reason.. Been a while, I
> think our v3 is much stronger case now.
>
> [1] 
> https://lore.kernel.org/all/CAK8P3a2VSBvOn1o+q1PYZaQ6LS9U4cz+DZGuDbisHkwNs2dAAw at mail.gmail.com/#t

I think in that case the problem was that the aliases were
done in the .dtsi file but enabled in the board specific .dts,
which would be pointless and confusing.

If we have a board that actually wires up more uarts to connectors
or devices, can clearly raise the compile time limit to whatever
that needs.

       Arnd


From knaerzche at gmail.com  Mon Dec  4 07:35:46 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon,  4 Dec 2023 16:35:46 +0100
Subject: [PATCH v3 2/3] ARM: dts: rockchip: Add GPU node for RK3128
In-Reply-To: <20231204153547.97877-1-knaerzche@gmail.com>
References: <20231204153547.97877-1-knaerzche@gmail.com>
Message-ID: <20231204153547.97877-3-knaerzche@gmail.com>

RK3128 SoCs have Mali400 MP2 GPU.
Add the respective device tree node and the correspondending opp-table.

The frequencies and voltages of the opp-table have been taken from
downstream kernel.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128.dtsi | 44 ++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 0676d8b22a1e..414b690f96e4 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -101,6 +101,27 @@ opp-1200000000 {
 		};
 	};
 
+	gpu_opp_table: opp-table-1 {
+		compatible = "operating-points-v2";
+
+		opp-200000000 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <975000 975000 1250000>;
+		};
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+			opp-microvolt = <1050000 1050000 1250000>;
+		};
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <1150000 1150000 1250000>;
+		};
+		opp-480000000 {
+			opp-hz = /bits/ 64 <480000000>;
+			opp-microvolt = <1250000 1250000 1250000>;
+		};
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
@@ -131,6 +152,29 @@ smp-sram at 0 {
 		};
 	};
 
+	gpu: gpu at 10090000 {
+		compatible = "rockchip,rk3128-mali", "arm,mali-400";
+		reg = <0x10090000 0x10000>;
+		interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp",
+				  "gpmmu",
+				  "pp0",
+				  "ppmmu0",
+				  "pp1",
+				  "ppmmu1";
+		clocks = <&cru ACLK_GPU>, <&cru ACLK_GPU>;
+		clock-names = "bus", "core";
+		operating-points-v2 = <&gpu_opp_table>;
+		resets = <&cru SRST_GPU>;
+		power-domains = <&power RK3128_PD_GPU>;
+		status = "disabled";
+	};
+
 	pmu: syscon at 100a0000 {
 		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
 		reg = <0x100a0000 0x1000>;
-- 
2.43.0



From knaerzche at gmail.com  Mon Dec  4 07:35:44 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon,  4 Dec 2023 16:35:44 +0100
Subject: [PATCH v3 0/3] Add power-controller and gpu for RK3128
Message-ID: <20231204153547.97877-1-knaerzche@gmail.com>

This series adds the power-controller and the gpu to RK3128's SoC
devicetree - both are already supported by the respective drivers.
Patch 3 enables the gpu for XPI-3128 board.

changes in v3:
 - dropped patches for not-yet needed power domains
 - dropped dt-bindings patches which was already merged

Alex Bee (3):
  ARM: dts: rockchip: Add power-controller for RK3128
  ARM: dts: rockchip: Add GPU node for RK3128
  ARM: dts: rockchip: Enable GPU for XPI-3128

 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts |   5 +
 arch/arm/boot/dts/rockchip/rk3128.dtsi        | 132 ++++++++++++++++++
 2 files changed, 137 insertions(+)

-- 
2.43.0



From knaerzche at gmail.com  Mon Dec  4 07:35:45 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon,  4 Dec 2023 16:35:45 +0100
Subject: [PATCH v3 1/3] ARM: dts: rockchip: Add power-controller for RK3128
In-Reply-To: <20231204153547.97877-1-knaerzche@gmail.com>
References: <20231204153547.97877-1-knaerzche@gmail.com>
Message-ID: <20231204153547.97877-2-knaerzche@gmail.com>

Add power controller and qos nodes for RK3128 in order to use
them as powerdomains.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128.dtsi | 88 ++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index c0c9f0eaffa3..0676d8b22a1e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -8,6 +8,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/power/rk3128-power.h>
 
 / {
 	compatible = "rockchip,rk3128";
@@ -133,6 +134,93 @@ smp-sram at 0 {
 	pmu: syscon at 100a0000 {
 		compatible = "rockchip,rk3128-pmu", "syscon", "simple-mfd";
 		reg = <0x100a0000 0x1000>;
+
+		power: power-controller {
+			compatible = "rockchip,rk3128-power-controller";
+			#power-domain-cells = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			power-domain at RK3128_PD_VIO {
+				reg = <RK3128_PD_VIO>;
+				clocks = <&cru ACLK_CIF>,
+					 <&cru HCLK_CIF>,
+					 <&cru DCLK_EBC>,
+					 <&cru HCLK_EBC>,
+					 <&cru ACLK_IEP>,
+					 <&cru HCLK_IEP>,
+					 <&cru ACLK_LCDC0>,
+					 <&cru HCLK_LCDC0>,
+					 <&cru PCLK_MIPI>,
+					 <&cru ACLK_RGA>,
+					 <&cru HCLK_RGA>,
+					 <&cru ACLK_VIO0>,
+					 <&cru ACLK_VIO1>,
+					 <&cru HCLK_VIO>,
+					 <&cru HCLK_VIO_H2P>,
+					 <&cru DCLK_VOP>,
+					 <&cru SCLK_VOP>;
+				pm_qos = <&qos_ebc>,
+					 <&qos_iep>,
+					 <&qos_lcdc>,
+					 <&qos_rga>,
+					 <&qos_vip>;
+				#power-domain-cells = <0>;
+			};
+
+			power-domain at RK3128_PD_VIDEO {
+				reg = <RK3128_PD_VIDEO>;
+				clocks = <&cru ACLK_VDPU>,
+					 <&cru HCLK_VDPU>,
+					 <&cru ACLK_VEPU>,
+					 <&cru HCLK_VEPU>,
+					 <&cru SCLK_HEVC_CORE>;
+				pm_qos = <&qos_vpu>;
+				#power-domain-cells = <0>;
+			};
+
+			power-domain at RK3128_PD_GPU {
+				reg = <RK3128_PD_GPU>;
+				clocks = <&cru ACLK_GPU>;
+				pm_qos = <&qos_gpu>;
+				#power-domain-cells = <0>;
+			};
+		};
+	};
+
+	qos_gpu: qos at 1012d000 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012d000 0x20>;
+	};
+
+	qos_vpu: qos at 1012e000 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012e000 0x20>;
+	};
+
+	qos_rga: qos at 1012f000 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f000 0x20>;
+	};
+
+	qos_ebc: qos at 1012f080 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f080 0x20>;
+	};
+
+	qos_iep: qos at 1012f100 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f100 0x20>;
+	};
+
+	qos_lcdc: qos at 1012f180 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f180 0x20>;
+	};
+
+	qos_vip: qos at 1012f200 {
+		compatible = "rockchip,rk3128-qos", "syscon";
+		reg = <0x1012f200 0x20>;
 	};
 
 	gic: interrupt-controller at 10139000 {
-- 
2.43.0



From knaerzche at gmail.com  Mon Dec  4 07:35:47 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon,  4 Dec 2023 16:35:47 +0100
Subject: [PATCH v3 3/3] ARM: dts: rockchip: Enable GPU for XPI-3128
In-Reply-To: <20231204153547.97877-1-knaerzche@gmail.com>
References: <20231204153547.97877-1-knaerzche@gmail.com>
Message-ID: <20231204153547.97877-4-knaerzche@gmail.com>

Add the supply and enable gpu node for XPI-3128 board.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index e979425f11a0..de497f6e9456 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -328,6 +328,11 @@ &gpio3 {
 			  "", "", "", "";
 };
 
+&gpu {
+	mali-supply = <&vdd_log>;
+	status = "okay";
+};
+
 &mdio {
 	phy0: ethernet-phy at 1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
-- 
2.43.0



From bp at alien8.de  Mon Dec  4 07:36:46 2023
From: bp at alien8.de (Borislav Petkov)
Date: Mon, 4 Dec 2023 16:36:46 +0100
Subject: [PATCH v2 3/4] mm: Change ghes code to allow poison of
 non-struct pfn
In-Reply-To: <20231204143650.GB1493156@nvidia.com>
References: <20231123003513.24292-1-ankita@nvidia.com>
 <20231123003513.24292-4-ankita@nvidia.com>
 <20231202232319.GAZWu8Z6gsLp1kI5Dw@fat_crate.local>
 <20231204143650.GB1493156@nvidia.com>
Message-ID: <20231204153646.GCZW3yDgal3gztpDRY@fat_crate.local>

On Mon, Dec 04, 2023 at 10:36:50AM -0400, Jason Gunthorpe wrote:
> It wasn't removed. patch 1 moved it to memory_failure() where it makes
> a lot more sense.

Why is this a separate patch then?


-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette


From bhe at redhat.com  Mon Dec  4 07:38:05 2023
From: bhe at redhat.com (Baoquan He)
Date: Mon, 4 Dec 2023 23:38:05 +0800
Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <20231201-blog-blasphemy-985d2665903c@wendy>
References: <20231130023955.5257-1-bhe@redhat.com>
 <20231130023955.5257-6-bhe@redhat.com>
 <20231201-blog-blasphemy-985d2665903c@wendy>
Message-ID: <ZW3yXWJ7rTrtZzyg@MiWiFi-R3L-srv>

On 12/01/23 at 10:38am, Conor Dooley wrote:
> On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
> 
> $subject has a typo in the arch bit :)

Indeed, will fix if need report. Thanks for careful checking.

> 
> > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > loading related codes.
> 
> Commit messages should be understandable in isolation, but this only
> explains (part of) what is obvious in the diff. Why is this change
> being made?

The purpose has been detailedly described in cover letter and patch 1
log. Andrew has picked these patches into his tree and grabbed the cover
letter log into the relevant commit for people's later checking. All
these seven patches will be present in mainline together. This is common
way when posting patch series? Please let me know if I misunderstand
anything.
> 
> > 
> > And also remove kexec_image_info() because the content has been printed
> > out in generic code.
> > 
> > Signed-off-by: Baoquan He <bhe at redhat.com>
> > ---
> >  arch/riscv/kernel/elf_kexec.c     | 11 ++++++-----
> >  arch/riscv/kernel/machine_kexec.c | 26 --------------------------
> >  2 files changed, 6 insertions(+), 31 deletions(-)
> > 
> > diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> > index e60fbd8660c4..5bd1ec3341fe 100644
> > --- a/arch/riscv/kernel/elf_kexec.c
> > +++ b/arch/riscv/kernel/elf_kexec.c
> > @@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> >  	if (ret)
> >  		goto out;
> >  	kernel_start = image->start;
> > -	pr_notice("The entry point of kernel at 0x%lx\n", image->start);
> >  
> >  	/* Add the kernel binary to the image */
> >  	ret = riscv_kexec_elf_load(image, &ehdr, &elf_info,
> > @@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> >  		image->elf_load_addr = kbuf.mem;
> >  		image->elf_headers_sz = headers_sz;
> >  
> > -		pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > -			 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > +		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > +			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> >  
> >  		/* Setup cmdline for kdump kernel case */
> >  		modified_cmdline = setup_kdump_cmdline(image, cmdline,
> > @@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> >  		pr_err("Error loading purgatory ret=%d\n", ret);
> >  		goto out;
> >  	}
> > +	kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem);
> > +
> >  	ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry",
> >  					     &kernel_start,
> >  					     sizeof(kernel_start), 0);
> > @@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> >  		if (ret)
> >  			goto out;
> >  		initrd_pbase = kbuf.mem;
> 
> > -		pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase);
> > +		kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase);
> 
> This is not a pr_debug().
> 
> >  	}
> >  
> >  	/* Add the DTB to the image */
> > @@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> >  	}
> >  	/* Cache the fdt buffer address for memory cleanup */
> >  	image->arch.fdt = fdt;
> 
> > -	pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem);
> > +	kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem);
> 
> Neither is this. Why are they being moved from pr_notice()?

You are right. 

While always printing out the loaded location of purgatory and
device tree doesn't make sense. It will be confusing when users
see these even when they do normal kexec/kdump loading. It should be
changed to pr_debug().

Which way do you suggest?
1) change it back to pr_debug(), fix it in another patch;
2) keep it as is in the patch;

Thanks
Baoquan



From ardb at kernel.org  Mon Dec  4 07:40:42 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Mon, 4 Dec 2023 16:40:42 +0100
Subject: [PATCH v6 02/41] arm64: mm: Take potential load offset into
 account when KASLR is off
In-Reply-To: <ZW3eOoVTotfNXIJo@FVFF77S0Q05N>
References: <20231129111555.3594833-43-ardb@google.com> <20231129111555.3594833-45-ardb@google.com>
 <ZW3eOoVTotfNXIJo@FVFF77S0Q05N>
Message-ID: <CAMj1kXEvqLMm=FqXjy37JKEqR6qPE=gVh8mGdJuHb+F3zLt0Tg@mail.gmail.com>

On Mon, 4 Dec 2023 at 15:12, Mark Rutland <mark.rutland at arm.com> wrote:
>
> On Wed, Nov 29, 2023 at 12:15:58PM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb at kernel.org>
> >
> > We enable CONFIG_RELOCATABLE even when CONFIG_RANDOMIZE_BASE is
> > disabled, and this permits the loader (i.e., EFI) to place the kernel
> > anywhere in physical memory as long as the base address is 64k aligned.
>
> I don't think that case is something we actually intend to permit today:
>
> (a) When CONFIG_RANDOMIZE_BASE=n, the EFI stub will load the kernel at SZ_2M
>     alignment. We initialize efi_nokaslr to !IS_ENABLED(CONFIG_RANDOMIZE_BASE),
>     and so arm64's efi_get_kimg_min_align() will return SZ_2M.
>
>     ... unless I'm missing something there?
>
> (b) We don't expose anything in the Image header such that an external
>     bootloader (i.e. not the EFI stub) can decide that 64K alignment is
>     sufficient. It would be unsound for a bootloader to load the kernel at less
>     than 2M alignment.
>
> (c) We never documented 64K alignment as being permitted. In booting.txt we say
>     "The Image must be placed text_offset bytes from a 2MB aligned base address
>     anywhere in usable system RAM and called there.", with no mention of a
>     relaxation down to 64K.
>
> ... so I don't think this patch is necessary, unless it's going to make
> something else simpler later in the series?
>

Your analysis is correct afaict, and I got things confused as to
whether/how EFI will relocate the image.

However, we do have a quirk that permits loading with a hard coded
TEXT_OFFSET of 512k even if the TEXT_OFFSET in the header is 0x0. This
is the reason why we enabled CONFIG_RELOCATABLE without
CONFIG_RANDOMIZE_BASE by default.

I think that ultimately, the fact that CONFIG_RELOCATABLE can be
enabled without CONFIG_RANDOMIZE_BASE is sufficient grounds to add
this extra space.


From broonie at kernel.org  Mon Dec  4 07:47:16 2023
From: broonie at kernel.org (Mark Brown)
Date: Mon, 04 Dec 2023 15:47:16 +0000
Subject: [PATCH v2 0/2] spi: spl022: fix sleeping in interrupt context
In-Reply-To: <cover.1701274975.git.namcao@linutronix.de>
References: <cover.1701274975.git.namcao@linutronix.de>
Message-ID: <170170483664.64566.7462447970982303814.b4-ty@kernel.org>

On Wed, 29 Nov 2023 17:31:54 +0100, Nam Cao wrote:
> While running the spl022, I got the following warning:
> BUG: sleeping function called from invalid context at drivers/spi/spi.c:1428
> 
> This is because between spi transfers, spi_transfer_delay_exec() (who
> may sleep if the delay is >10us) is called in interrupt context. This is
> a problem for anyone who runs this driver and need more than 10us delay.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/2] spi: introduce SPI_TRANS_FAIL_IO for error reporting
      commit: 39cefd85098d12439586824c39f8e1948fac186d
[2/2] spi: spl022: switch to use default spi_transfer_one_message()
      commit: 9b2ef250b31d46f7ef522bd1bd84942f998bb3f9

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From david at redhat.com  Mon Dec  4 07:47:17 2023
From: david at redhat.com (David Hildenbrand)
Date: Mon, 4 Dec 2023 16:47:17 +0100
Subject: [PATCH v3 01/15] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <20231204105440.61448-2-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-2-ryan.roberts@arm.com>
Message-ID: <a12ce4f8-feb0-4e35-8f55-9270fe5a808b@redhat.com>

On 04.12.23 11:54, Ryan Roberts wrote:
> Convert copy_pte_range() to copy a set of ptes in a batch. A given batch
> maps a physically contiguous block of memory, all belonging to the same
> folio. This will likely improve performance by a tiny amount due to
> batching the folio reference count management and calling set_ptes()
> rather than making individual calls to set_pte_at().
> 
> However, the primary motivation for this change is to reduce the number
> of tlb maintenance operations that the arm64 backend has to perform
> during fork, as it is about to add transparent support for the
> "contiguous bit" in its ptes. By write-protecting the parent using the
> new ptep_set_wrprotects() (note the 's' at the end) function, the
> backend can avoid having to unfold contig ranges of PTEs, which is
> expensive, when all ptes in the range are being write-protected.
> Similarly, by using set_ptes() rather than set_pte_at() to set up ptes
> in the child, the backend does not need to fold a contiguous range once
> they are all populated - they can be initially populated as a contiguous
> range in the first place.
> 
> This change addresses the core-mm refactoring only, and introduces
> ptep_set_wrprotects() with a default implementation that calls
> ptep_set_wrprotect() for each pte in the range. A separate change will
> implement ptep_set_wrprotects() in the arm64 backend to realize the
> performance improvement as part of the work to enable contpte mappings.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>   include/linux/pgtable.h |  13 +++
>   mm/memory.c             | 195 ++++++++++++++++++++++++++++++----------
>   2 files changed, 162 insertions(+), 46 deletions(-)
> 
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index af7639c3b0a3..1c50f8a0fdde 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -622,6 +622,19 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres
>   }
>   #endif
>   
> +#ifndef ptep_set_wrprotects
> +struct mm_struct;
> +static inline void ptep_set_wrprotects(struct mm_struct *mm,
> +				unsigned long address, pte_t *ptep,
> +				unsigned int nr)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
> +		ptep_set_wrprotect(mm, address, ptep);
> +}
> +#endif
> +
>   /*
>    * On some architectures hardware does not set page access bit when accessing
>    * memory page, it is responsibility of software setting this bit. It brings
> diff --git a/mm/memory.c b/mm/memory.c
> index 1f18ed4a5497..8a87a488950c 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -924,68 +924,162 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
>   	return 0;
>   }
>   
> +static int folio_nr_pages_cont_mapped(struct folio *folio,
> +				      struct page *page, pte_t *pte,
> +				      unsigned long addr, unsigned long end,
> +				      pte_t ptent, bool enforce_uffd_wp,
> +				      int *dirty_nr, int *writable_nr)
> +{
> +	int floops;
> +	int i;
> +	unsigned long pfn;
> +	bool prot_none;
> +	bool uffd_wp;
> +
> +	if (!folio_test_large(folio))
> +		return 1;
> +
> +	/*
> +	 * Loop either to `end` or to end of folio if its contiguously mapped,
> +	 * whichever is smaller.
> +	 */
> +	floops = (end - addr) >> PAGE_SHIFT;
> +	floops = min_t(int, floops,
> +		       folio_pfn(folio_next(folio)) - page_to_pfn(page));
> +
> +	pfn = page_to_pfn(page);
> +	prot_none = pte_protnone(ptent);
> +	uffd_wp = pte_uffd_wp(ptent);
> +
> +	*dirty_nr = !!pte_dirty(ptent);
> +	*writable_nr = !!pte_write(ptent);
> +
> +	pfn++;
> +	pte++;
> +
> +	for (i = 1; i < floops; i++) {
> +		ptent = ptep_get(pte);
> +
> +		if (!pte_present(ptent) || pte_pfn(ptent) != pfn ||
> +		    prot_none != pte_protnone(ptent) ||
> +		    (enforce_uffd_wp && uffd_wp != pte_uffd_wp(ptent)))
> +			break;
> +
> +		if (pte_dirty(ptent))
> +			(*dirty_nr)++;
> +		if (pte_write(ptent))
> +			(*writable_nr)++;
> +
> +		pfn++;
> +		pte++;
> +	}
> +
> +	return i;
> +}
> +
>   /*
> - * Copy one pte.  Returns 0 if succeeded, or -EAGAIN if one preallocated page
> - * is required to copy this pte.
> + * Copy set of contiguous ptes.  Returns number of ptes copied if succeeded
> + * (always gte 1), or -EAGAIN if one preallocated page is required to copy the
> + * first pte.
>    */
>   static inline int
> -copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
> -		 pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
> -		 struct folio **prealloc)
> +copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
> +		  pte_t *dst_pte, pte_t *src_pte,
> +		  unsigned long addr, unsigned long end,
> +		  int *rss, struct folio **prealloc)
>   {
>   	struct mm_struct *src_mm = src_vma->vm_mm;
>   	unsigned long vm_flags = src_vma->vm_flags;
>   	pte_t pte = ptep_get(src_pte);
>   	struct page *page;
>   	struct folio *folio;
> +	int nr = 1;
> +	bool anon = false;
> +	bool enforce_uffd_wp = userfaultfd_wp(dst_vma);
> +	int nr_dirty = !!pte_dirty(pte);
> +	int nr_writable = !!pte_write(pte);
> +	int i, ret;
>   
>   	page = vm_normal_page(src_vma, addr, pte);
> -	if (page)
> +	if (page) {
>   		folio = page_folio(page);
> -	if (page && folio_test_anon(folio)) {
> -		/*
> -		 * If this page may have been pinned by the parent process,
> -		 * copy the page immediately for the child so that we'll always
> -		 * guarantee the pinned page won't be randomly replaced in the
> -		 * future.
> -		 */
> -		folio_get(folio);
> -		if (unlikely(page_try_dup_anon_rmap(page, false, src_vma))) {
> -			/* Page may be pinned, we have to copy. */
> -			folio_put(folio);
> -			return copy_present_page(dst_vma, src_vma, dst_pte, src_pte,
> -						 addr, rss, prealloc, page);
> +		anon = folio_test_anon(folio);
> +		nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
> +						pte, enforce_uffd_wp, &nr_dirty,
> +						&nr_writable);
> +		folio_ref_add(folio, nr);
> +
> +		for (i = 0; i < nr; i++, page++) {
> +			if (anon) {
> +				/*
> +				 * If this page may have been pinned by the
> +				 * parent process, copy the page immediately for
> +				 * the child so that we'll always guarantee the
> +				 * pinned page won't be randomly replaced in the
> +				 * future.
> +				 */
> +				if (unlikely(page_try_dup_anon_rmap(
> +						page, false, src_vma))) {
> +					if (i != 0)
> +						break;
> +					/* Page may be pinned, we have to copy. */
> +					folio_ref_sub(folio, nr);
> +					ret = copy_present_page(
> +						dst_vma, src_vma, dst_pte,
> +						src_pte, addr, rss, prealloc,
> +						page);
> +					return ret == 0 ? 1 : ret;
> +				}
> +				rss[MM_ANONPAGES]++;
> +				VM_BUG_ON(PageAnonExclusive(page));
> +			} else {
> +				page_dup_file_rmap(page, false);
> +				rss[mm_counter_file(page)]++;
> +			}
>   		}
> -		rss[MM_ANONPAGES]++;
> -	} else if (page) {
> -		folio_get(folio);
> -		page_dup_file_rmap(page, false);
> -		rss[mm_counter_file(page)]++;
> -	}

This likely looks a lot neater if you keep the existing structure.

For example, you can simply have on the !anon path

} else if (page) {
	folio = page_folio(page);
	nr = folio_nr_pages_cont_mapped ...
	folio_ref_add(folio, nr);
	for (i = 0; i < nr; i++, page++)
		page_dup_file_rmap(page, false);
	rss[mm_counter_file(&folio->page)] += nr;
}

-- 
Cheers,

David / dhildenb



From louis.chauvet at bootlin.com  Mon Dec  4 07:49:03 2023
From: louis.chauvet at bootlin.com (Louis Chauvet)
Date: Mon,  4 Dec 2023 16:49:03 +0100
Subject: [PATCH] spi: atmel: Fix clock issue when using devices with different polarities
Message-ID: <20231204154903.11607-1-louis.chauvet@bootlin.com>

The current Atmel SPI controller driver (v2) behaves incorrectly when
using two SPI devices with different clock polarities and GPIO CS.

When switching from one device to another, the controller driver first
enables the CS and then applies whatever configuration suits the targeted
device (typically, the polarities). The side effect of such order is the
apparition of a spurious clock edge after enabling the CS when the clock
polarity needs to be inverted wrt. the previous configuration of the
controller.

This parasitic clock edge is problematic when the SPI device uses that edge
for internal processing, which is perfectly legitimate given that its CS
was asserted. Indeed, devices such as HVS8080 driven by driver gpio-sr in
the kernel are shift registers and will process this first clock edge to
perform a first register shift. In this case, the first bit gets lost and
the whole data block that will later be read by the kernel is all shifted
by one.

    Current behavior:
      The actual switching of the clock polarity only occurs after the CS
      when the controller sends the first message:

    CLK ------------\   /-\ /-\
                    |   | | | |    . . .
                    \---/ \-/ \
    CS  -----\
             |
             \------------------

             ^      ^   ^
             |      |   |
             |      |   Actual clock of the message sent
             |      |
             |      Change of clock polarity, which occurs with the first
             |      write to the bus. This edge occurs when the CS is
             |      already asserted, and can be interpreted as
             |      the first clock edge by the receiver.
             |
             GPIO CS toggle

This issue is specific to this controller because while the SPI core
performs the operations in the right order, the controller however does
not. In practice, the controller only applies the clock configuration right
before the first transmission.

So this is not a problem when using the controller's dedicated CS, as the
controller does things correctly, but it becomes a problem when you need to
change the clock polarity and use an external GPIO for the CS.

One possible approach to solve this problem is to send a dummy message
before actually activating the CS, so that the controller applies the clock
polarity beforehand.

New behavior:

CLK     ------\      /-\     /-\      /-\     /-\
              |      | | ... | |      | | ... | |
              \------/ \-   -/ \------/ \-   -/ \------

CS      -\/-----------------------\
         ||                       |
         \/                       \---------------------
         ^    ^       ^           ^    ^
         |    |       |           |    |
         |    |       |           |    Expected clock cycles when
         |    |       |           |    sending the message
         |    |       |           |
         |    |       |           Actual GPIO CS activation, occurs inside
         |    |       |           the driver
         |    |       |
         |    |       Dummy message, to trigger clock polarity
         |    |       reconfiguration. This message is not received and
         |    |       processed by the device because CS is low.
         |    |
         |    Change of clock polarity, forced by the dummy message. This
         |    time, the edge is not detected by the receiver.
         |
         This small spike in CS activation is due to the fact that the
         spi-core activates the CS gpio before calling the driver's
         set_cs callback, which deactivates this gpio again until the
         clock polarity is correct.

To avoid having to systematically send a dummy packet, the driver keeps
track of the clock's current polarity. In this way, it only sends the dummy
packet when necessary, ensuring that the clock will have the correct
polarity when the CS is toggled.

There could be two hardware problems with this patch:
1- Maybe the small CS activation peak can confuse SPI devices
2- If on a design, a single wire is used to select two devices depending
on its state, the dummy message may disturb them.

Fixes: 5ee36c989831 ("spi: atmel_spi update chipselect handling")
Cc: stable at vger.kernel.org
Signed-off-by: Louis Chauvet <louis.chauvet at bootlin.com>
---
A possible solution to avoid the small CS spike could be to hack the
spi core and swap the blocks managing the gpiod (spi.c:971-987) with the
one calling the set_cs callback (spi.c:989-991). This way, the controller
will send the dummy message before the CS is actually activated. This
solution may have side effects on other drivers; I don't know if there are
drivers depending on the current order.

We could also introduce a flag to limit this reordering to controller
drivers requesting it.
---
 drivers/spi/spi-atmel.c | 82 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 81 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 6aa8adbe4170..23050ebb778a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -22,6 +22,7 @@
 #include <linux/gpio/consumer.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/pm_runtime.h>
+#include <linux/iopoll.h>
 #include <trace/events/spi.h>
 
 /* SPI register offsets */
@@ -279,6 +280,7 @@ struct atmel_spi {
 	bool			keep_cs;
 
 	u32			fifo_size;
+	bool			last_polarity;
 	u8			native_cs_free;
 	u8			native_cs_for_gpio;
 };
@@ -291,6 +293,22 @@ struct atmel_spi_device {
 #define SPI_MAX_DMA_XFER	65535 /* true for both PDC and DMA */
 #define INVALID_DMA_ADDRESS	0xffffffff
 
+/*
+ * This frequency can be anything supported by the controller, but to avoid
+ * unnecessary delay, the highest possible frequency is chosen.
+ *
+ * This frequency is the highest possible which is not interfering with other
+ * chip select registers (see Note for Serial Clock Bit Rate configuration in
+ * Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16, page 1283)
+ */
+#define DUMMY_MSG_FREQUENCY	0x02
+/*
+ * 8 bits is the minimum data the controller is capable of sending.
+ *
+ * This message can be anything as it should not be treated by any SPI device.
+ */
+#define DUMMY_MSG		0xAA
+
 /*
  * Version 2 of the SPI controller has
  *  - CR.LASTXFER
@@ -304,6 +322,43 @@ static bool atmel_spi_is_v2(struct atmel_spi *as)
 	return as->caps.is_spi2;
 }
 
+/*
+ * Send a dummy message.
+ *
+ * This is sometimes needed when using a CS GPIO to force clock transition when
+ * switching between devices with different polarities.
+ */
+static void atmel_spi_send_dummy(struct atmel_spi *as, struct spi_device *spi, int chip_select)
+{
+	u32 status;
+	u32 csr;
+
+	/*
+	 * Set a clock frequency to allow sending message on SPI bus.
+	 * The frequency here can be anything, but is needed for
+	 * the controller to send the data.
+	 */
+	csr = spi_readl(as, CSR0 + 4 * chip_select);
+	csr = SPI_BFINS(SCBR, DUMMY_MSG_FREQUENCY, csr);
+	spi_writel(as, CSR0 + 4 * chip_select, csr);
+
+	/*
+	 * Read all data coming from SPI bus, needed to be able to send
+	 * the message.
+	 */
+	spi_readl(as, RDR);
+	while (spi_readl(as, SR) & SPI_BIT(RDRF)) {
+		spi_readl(as, RDR);
+		cpu_relax();
+	}
+
+	spi_writel(as, TDR, DUMMY_MSG);
+
+	readl_poll_timeout_atomic(as->regs + SPI_SR, status,
+				  (status & SPI_BIT(TXEMPTY)), 1, 1000);
+}
+
+
 /*
  * Earlier SPI controllers (e.g. on at91rm9200) have a design bug whereby
  * they assume that spi slave device state will not change on deselect, so
@@ -320,11 +375,17 @@ static bool atmel_spi_is_v2(struct atmel_spi *as)
  * Master on Chip Select 0.")  No workaround exists for that ... so for
  * nCS0 on that chip, we (a) don't use the GPIO, (b) can't support CS_HIGH,
  * and (c) will trigger that first erratum in some cases.
+ *
+ * When changing the clock polarity, the SPI controller waits for the next
+ * transmission to enforce the default clock state. This may be an issue when
+ * using a GPIO as Chip Select: the clock level is applied only when the first
+ * packet is sent, once the CS has already been asserted. The workaround is to
+ * avoid this by sending a first (dummy) message before toggling the CS state.
  */
-
 static void cs_activate(struct atmel_spi *as, struct spi_device *spi)
 {
 	struct atmel_spi_device *asd = spi->controller_state;
+	bool new_polarity;
 	int chip_select;
 	u32 mr;
 
@@ -353,6 +414,25 @@ static void cs_activate(struct atmel_spi *as, struct spi_device *spi)
 		}
 
 		mr = spi_readl(as, MR);
+
+		/*
+		 * Ensures the clock polarity is valid before we actually
+		 * assert the CS to avoid spurious clock edges to be
+		 * processed by the spi devices.
+		 */
+		if (spi_get_csgpiod(spi, 0)) {
+			new_polarity = (asd->csr & SPI_BIT(CPOL)) != 0;
+			if (new_polarity != as->last_polarity) {
+				/*
+				 * Need to disable the GPIO before sending the dummy
+				 * message because it is already set by the spi core.
+				 */
+				gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), 0);
+				atmel_spi_send_dummy(as, spi, chip_select);
+				as->last_polarity = new_polarity;
+				gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), 1);
+			}
+		}
 	} else {
 		u32 cpol = (spi->mode & SPI_CPOL) ? SPI_BIT(CPOL) : 0;
 		int i;
-- 
2.41.0



From ankita at nvidia.com  Mon Dec  4 07:54:52 2023
From: ankita at nvidia.com (Ankit Agrawal)
Date: Mon, 4 Dec 2023 15:54:52 +0000
Subject: [PATCH v2 3/4] mm: Change ghes code to allow poison of non-struct
 pfn
In-Reply-To: <20231204153646.GCZW3yDgal3gztpDRY@fat_crate.local>
References: <20231123003513.24292-1-ankita@nvidia.com>
 <20231123003513.24292-4-ankita@nvidia.com>
 <20231202232319.GAZWu8Z6gsLp1kI5Dw@fat_crate.local>
 <20231204143650.GB1493156@nvidia.com>
 <20231204153646.GCZW3yDgal3gztpDRY@fat_crate.local>
Message-ID: <BY5PR12MB3763A85483534C7FD50529C8B086A@BY5PR12MB3763.namprd12.prod.outlook.com>

>> It wasn't removed. patch 1 moved it to memory_failure() where it makes
>> a lot more sense.
>
> Why is this a separate patch then?

This was done to keep ghes code separate from the memory failure code.
I can merge them if that is preferable.

From jgg at nvidia.com  Mon Dec  4 07:55:54 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Mon, 4 Dec 2023 11:55:54 -0400
Subject: [PATCH v2 3/4] mm: Change ghes code to allow poison of
 non-struct pfn
In-Reply-To: <BY5PR12MB3763A85483534C7FD50529C8B086A@BY5PR12MB3763.namprd12.prod.outlook.com>
References: <20231123003513.24292-1-ankita@nvidia.com>
 <20231123003513.24292-4-ankita@nvidia.com>
 <20231202232319.GAZWu8Z6gsLp1kI5Dw@fat_crate.local>
 <20231204143650.GB1493156@nvidia.com>
 <20231204153646.GCZW3yDgal3gztpDRY@fat_crate.local>
 <BY5PR12MB3763A85483534C7FD50529C8B086A@BY5PR12MB3763.namprd12.prod.outlook.com>
Message-ID: <20231204155554.GG1493156@nvidia.com>

On Mon, Dec 04, 2023 at 03:54:52PM +0000, Ankit Agrawal wrote:
> >> It wasn't removed. patch 1 moved it to memory_failure() where it makes
> >> a lot more sense.
> >
> > Why is this a separate patch then?
> 
> This was done to keep ghes code separate from the memory failure code.
> I can merge them if that is preferable.

A single patch to move just this code could be a good idea

Jason


From aleksander.lobakin at intel.com  Mon Dec  4 07:54:47 2023
From: aleksander.lobakin at intel.com (Alexander Lobakin)
Date: Mon, 4 Dec 2023 16:54:47 +0100
Subject: [PATCH v12 1/3] lib/bitmap: add bitmap_{read,write}()
In-Reply-To: <ZW3gnNbnzpZwtrMa@yury-ThinkPad>
References: <20231109151106.2385155-1-glider@google.com>
 <CAG_fn=U7EV0ohaNFRwQ83cvwVn-Fer1pHXOjPevbP_XpYGDCYA@mail.gmail.com>
 <ZW3gnNbnzpZwtrMa@yury-ThinkPad>
Message-ID: <ee9b60fb-8c79-44d8-8f4b-63db7e34b596@intel.com>

From: Yury Norov <yury.norov at gmail.com>
Date: Mon, 4 Dec 2023 06:22:20 -0800

> On Mon, Dec 04, 2023 at 02:28:09PM +0100, Alexander Potapenko wrote:
>> On Thu, Nov 9, 2023 at 4:11?PM Alexander Potapenko <glider at google.com> wrote:
>>>
>>> From: Syed Nayyar Waris <syednwaris at gmail.com>
>>>
>>> The two new functions allow reading/writing values of length up to
>>> BITS_PER_LONG bits at arbitrary position in the bitmap.
>>>
>>> The code was taken from "bitops: Introduce the for_each_set_clump macro"
>>> by Syed Nayyar Waris with a number of changes and simplifications:
>>>  - instead of using roundup(), which adds an unnecessary dependency
>>>    on <linux/math.h>, we calculate space as BITS_PER_LONG-offset;
>>>  - indentation is reduced by not using else-clauses (suggested by
>>>    checkpatch for bitmap_get_value());
>>>  - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read()
>>>    and bitmap_write();
>>>  - some redundant computations are omitted.
>>>
>>> Cc: Arnd Bergmann <arnd at arndb.de>
>>> Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
>>> Signed-off-by: William Breathitt Gray <william.gray at linaro.org>
>>> Link: https://lore.kernel.org/lkml/fe12eedf3666f4af5138de0e70b67a07c7f40338.1592224129.git.syednwaris at gmail.com/
>>> Suggested-by: Yury Norov <yury.norov at gmail.com>
>>> Co-developed-by: Alexander Potapenko <glider at google.com>
>>> Signed-off-by: Alexander Potapenko <glider at google.com>
>>> Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
>>
>> Yury, Andy, do you think anything else is needed for this series?
>> If not, whom should we ask to take it?
> 
> I probably need to revisit it, but generally it looks OK.
> 
> But I can't take new API without having real users. Now that your MTE
> series is delayed, and Alexander's 'ip_tunnel flags' is not moving as
> well, there's non-zero chance to merge dead code.

One of the PFCP developers had a quick vacation, we'll send PFCP with
the ip_tunnel bitmap conversion this week.
I'll tell Jakub he'd need to pull boys' tree :D

> 
> If you want it to be merged, I'd advise you to walk through the kernel
> sources and find good cases where bitmap_read() and bitmap_write() can
> be used. Then append this series with such conversions, and I'll be
> able to move it.
> 
> Thanks,
> Yury

Thanks,
Olek


From david at redhat.com  Mon Dec  4 08:00:05 2023
From: david at redhat.com (David Hildenbrand)
Date: Mon, 4 Dec 2023 17:00:05 +0100
Subject: [PATCH v3 01/15] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <a12ce4f8-feb0-4e35-8f55-9270fe5a808b@redhat.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-2-ryan.roberts@arm.com>
 <a12ce4f8-feb0-4e35-8f55-9270fe5a808b@redhat.com>
Message-ID: <104de2d6-ecf9-4b0c-a982-5bd8e1aea758@redhat.com>

On 04.12.23 16:47, David Hildenbrand wrote:
> On 04.12.23 11:54, Ryan Roberts wrote:
>> Convert copy_pte_range() to copy a set of ptes in a batch. A given batch
>> maps a physically contiguous block of memory, all belonging to the same
>> folio. This will likely improve performance by a tiny amount due to
>> batching the folio reference count management and calling set_ptes()
>> rather than making individual calls to set_pte_at().
>>
>> However, the primary motivation for this change is to reduce the number
>> of tlb maintenance operations that the arm64 backend has to perform
>> during fork, as it is about to add transparent support for the
>> "contiguous bit" in its ptes. By write-protecting the parent using the
>> new ptep_set_wrprotects() (note the 's' at the end) function, the
>> backend can avoid having to unfold contig ranges of PTEs, which is
>> expensive, when all ptes in the range are being write-protected.
>> Similarly, by using set_ptes() rather than set_pte_at() to set up ptes
>> in the child, the backend does not need to fold a contiguous range once
>> they are all populated - they can be initially populated as a contiguous
>> range in the first place.
>>
>> This change addresses the core-mm refactoring only, and introduces
>> ptep_set_wrprotects() with a default implementation that calls
>> ptep_set_wrprotect() for each pte in the range. A separate change will
>> implement ptep_set_wrprotects() in the arm64 backend to realize the
>> performance improvement as part of the work to enable contpte mappings.
>>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
>>    include/linux/pgtable.h |  13 +++
>>    mm/memory.c             | 195 ++++++++++++++++++++++++++++++----------
>>    2 files changed, 162 insertions(+), 46 deletions(-)
>>
>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>> index af7639c3b0a3..1c50f8a0fdde 100644
>> --- a/include/linux/pgtable.h
>> +++ b/include/linux/pgtable.h
>> @@ -622,6 +622,19 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres
>>    }
>>    #endif
>>    
>> +#ifndef ptep_set_wrprotects
>> +struct mm_struct;
>> +static inline void ptep_set_wrprotects(struct mm_struct *mm,
>> +				unsigned long address, pte_t *ptep,
>> +				unsigned int nr)
>> +{
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
>> +		ptep_set_wrprotect(mm, address, ptep);
>> +}
>> +#endif
>> +
>>    /*
>>     * On some architectures hardware does not set page access bit when accessing
>>     * memory page, it is responsibility of software setting this bit. It brings
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 1f18ed4a5497..8a87a488950c 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -924,68 +924,162 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
>>    	return 0;
>>    }
>>    
>> +static int folio_nr_pages_cont_mapped(struct folio *folio,
>> +				      struct page *page, pte_t *pte,
>> +				      unsigned long addr, unsigned long end,
>> +				      pte_t ptent, bool enforce_uffd_wp,
>> +				      int *dirty_nr, int *writable_nr)
>> +{
>> +	int floops;
>> +	int i;
>> +	unsigned long pfn;
>> +	bool prot_none;
>> +	bool uffd_wp;
>> +
>> +	if (!folio_test_large(folio))
>> +		return 1;
>> +
>> +	/*
>> +	 * Loop either to `end` or to end of folio if its contiguously mapped,
>> +	 * whichever is smaller.
>> +	 */
>> +	floops = (end - addr) >> PAGE_SHIFT;
>> +	floops = min_t(int, floops,
>> +		       folio_pfn(folio_next(folio)) - page_to_pfn(page));
>> +
>> +	pfn = page_to_pfn(page);
>> +	prot_none = pte_protnone(ptent);
>> +	uffd_wp = pte_uffd_wp(ptent);
>> +
>> +	*dirty_nr = !!pte_dirty(ptent);
>> +	*writable_nr = !!pte_write(ptent);
>> +
>> +	pfn++;
>> +	pte++;
>> +
>> +	for (i = 1; i < floops; i++) {
>> +		ptent = ptep_get(pte);
>> +
>> +		if (!pte_present(ptent) || pte_pfn(ptent) != pfn ||
>> +		    prot_none != pte_protnone(ptent) ||
>> +		    (enforce_uffd_wp && uffd_wp != pte_uffd_wp(ptent)))
>> +			break;
>> +
>> +		if (pte_dirty(ptent))
>> +			(*dirty_nr)++;
>> +		if (pte_write(ptent))
>> +			(*writable_nr)++;
>> +
>> +		pfn++;
>> +		pte++;
>> +	}
>> +
>> +	return i;
>> +}
>> +
>>    /*
>> - * Copy one pte.  Returns 0 if succeeded, or -EAGAIN if one preallocated page
>> - * is required to copy this pte.
>> + * Copy set of contiguous ptes.  Returns number of ptes copied if succeeded
>> + * (always gte 1), or -EAGAIN if one preallocated page is required to copy the
>> + * first pte.
>>     */
>>    static inline int
>> -copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>> -		 pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
>> -		 struct folio **prealloc)
>> +copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>> +		  pte_t *dst_pte, pte_t *src_pte,
>> +		  unsigned long addr, unsigned long end,
>> +		  int *rss, struct folio **prealloc)
>>    {
>>    	struct mm_struct *src_mm = src_vma->vm_mm;
>>    	unsigned long vm_flags = src_vma->vm_flags;
>>    	pte_t pte = ptep_get(src_pte);
>>    	struct page *page;
>>    	struct folio *folio;
>> +	int nr = 1;
>> +	bool anon = false;
>> +	bool enforce_uffd_wp = userfaultfd_wp(dst_vma);
>> +	int nr_dirty = !!pte_dirty(pte);
>> +	int nr_writable = !!pte_write(pte);
>> +	int i, ret;
>>    
>>    	page = vm_normal_page(src_vma, addr, pte);
>> -	if (page)
>> +	if (page) {
>>    		folio = page_folio(page);
>> -	if (page && folio_test_anon(folio)) {
>> -		/*
>> -		 * If this page may have been pinned by the parent process,
>> -		 * copy the page immediately for the child so that we'll always
>> -		 * guarantee the pinned page won't be randomly replaced in the
>> -		 * future.
>> -		 */
>> -		folio_get(folio);
>> -		if (unlikely(page_try_dup_anon_rmap(page, false, src_vma))) {
>> -			/* Page may be pinned, we have to copy. */
>> -			folio_put(folio);
>> -			return copy_present_page(dst_vma, src_vma, dst_pte, src_pte,
>> -						 addr, rss, prealloc, page);
>> +		anon = folio_test_anon(folio);
>> +		nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
>> +						pte, enforce_uffd_wp, &nr_dirty,
>> +						&nr_writable);
>> +		folio_ref_add(folio, nr);
>> +
>> +		for (i = 0; i < nr; i++, page++) {
>> +			if (anon) {
>> +				/*
>> +				 * If this page may have been pinned by the
>> +				 * parent process, copy the page immediately for
>> +				 * the child so that we'll always guarantee the
>> +				 * pinned page won't be randomly replaced in the
>> +				 * future.
>> +				 */
>> +				if (unlikely(page_try_dup_anon_rmap(
>> +						page, false, src_vma))) {
>> +					if (i != 0)
>> +						break;
>> +					/* Page may be pinned, we have to copy. */
>> +					folio_ref_sub(folio, nr);
>> +					ret = copy_present_page(
>> +						dst_vma, src_vma, dst_pte,
>> +						src_pte, addr, rss, prealloc,
>> +						page);
>> +					return ret == 0 ? 1 : ret;
>> +				}
>> +				rss[MM_ANONPAGES]++;
>> +				VM_BUG_ON(PageAnonExclusive(page));
>> +			} else {
>> +				page_dup_file_rmap(page, false);
>> +				rss[mm_counter_file(page)]++;
>> +			}
>>    		}
>> -		rss[MM_ANONPAGES]++;
>> -	} else if (page) {
>> -		folio_get(folio);
>> -		page_dup_file_rmap(page, false);
>> -		rss[mm_counter_file(page)]++;
>> -	}
> 
> This likely looks a lot neater if you keep the existing structure.
> 
> For example, you can simply have on the !anon path
> 
> } else if (page) {
> 	folio = page_folio(page);
> 	nr = folio_nr_pages_cont_mapped ...
> 	folio_ref_add(folio, nr);
> 	for (i = 0; i < nr; i++, page++)
> 		page_dup_file_rmap(page, false);
> 	rss[mm_counter_file(&folio->page)] += nr;
> }
> 

With rmap batching from [1] -- rebased+changed on top of that -- we could turn
that into an effective (untested):

         if (page && folio_test_anon(folio)) {
+               nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
+                                               pte, enforce_uffd_wp, &nr_dirty,
+                                               &nr_writable);
                 /*
                  * If this page may have been pinned by the parent process,
                  * copy the page immediately for the child so that we'll always
                  * guarantee the pinned page won't be randomly replaced in the
                  * future.
                  */
-               folio_get(folio);
-               if (unlikely(folio_try_dup_anon_rmap_pte(folio, page, src_vma))) {
+               folio_ref_add(folio, nr);
+               if (unlikely(folio_try_dup_anon_rmap_ptes(folio, page, nr, src_vma))) {
                         /* Page may be pinned, we have to copy. */
-                       folio_put(folio);
-                       return copy_present_page(dst_vma, src_vma, dst_pte, src_pte,
-                                                addr, rss, prealloc, page);
+                       folio_ref_sub(folio, nr);
+                       ret = copy_present_page(dst_vma, src_vma, dst_pte,
+                                               src_pte, addr, rss, prealloc,
+                                               page);
+                       return ret == 0 ? 1 : ret;
                 }
-               rss[MM_ANONPAGES]++;
+               rss[MM_ANONPAGES] += nr;
         } else if (page) {
-               folio_get(folio);
-               folio_dup_file_rmap_pte(folio, page);
-               rss[mm_counter_file(page)]++;
+               nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
+                                               pte, enforce_uffd_wp, &nr_dirty,
+                                               &nr_writable);
+               folio_ref_add(folio, nr);
+               folio_dup_file_rmap_ptes(folio, page, nr);
+               rss[mm_counter_file(page)] += nr;
         }


We'll have to test performance, but it could be that we want to specialize
more on !folio_test_large(). That code is very performance-sensitive.


[1] https://lkml.kernel.org/r/20231204142146.91437-1-david at redhat.com

-- 
Cheers,

David / dhildenb



From andriy.shevchenko at linux.intel.com  Mon Dec  4 08:02:19 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 4 Dec 2023 18:02:19 +0200
Subject: [PATCH v4 12/23] pinctrl: mediatek: Make use of
 PINCTRL_GROUP_DESC()
In-Reply-To: <CAMuHMdVz=dLaBt-Td0UdOOs79ju7UfX_2vUcy8Kdeo9aSP+edw@mail.gmail.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <20231129161459.1002323-13-andriy.shevchenko@linux.intel.com>
 <CGME20231204114039eucas1p29c6f8a162191e58ff658d3a1c44429bf@eucas1p2.samsung.com>
 <9e4e65de-7234-4234-8091-796277a1f1c5@samsung.com>
 <ZW3PrSQWyZvvhN66@smile.fi.intel.com>
 <CAMuHMdU-E7jemjAS0EunWFPq1LfF9vcNE+50ah4WH9oD1TXYew@mail.gmail.com>
 <ZW3U5-LBqWiyxB6-@smile.fi.intel.com>
 <CAMuHMdVz=dLaBt-Td0UdOOs79ju7UfX_2vUcy8Kdeo9aSP+edw@mail.gmail.com>
Message-ID: <ZW34C47rt80Ng8SA@smile.fi.intel.com>

On Mon, Dec 04, 2023 at 02:39:37PM +0100, Geert Uytterhoeven wrote:
> On Mon, Dec 4, 2023 at 2:32?PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Mon, Dec 04, 2023 at 02:19:10PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Dec 4, 2023 at 2:10?PM Andy Shevchenko
> > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > On Mon, Dec 04, 2023 at 12:40:38PM +0100, Marek Szyprowski wrote:
> > > > > On 29.11.2023 17:06, Andy Shevchenko wrote:
> > > > > > Make use of PINCTRL_GROUP_DESC() instead of open coding it.
> > > >
> > > > > PINCTRL_GROUP_DESC() macro from drivers/pinctrl/core.h contains a cast
> > > > > to (struct group_desc), what breaks users of the above macros.
> > > >
> > > > There is no cast (*).
> > > > Thanks for report, I will check.
> > > >
> > > > But this was v4 of the series and LKP actually sent a positive feedback.
> > > > Besides that I have tested this locally with modules enabled.
> > > >
> > > > *) It's a compound literal, _not_ a cast.
> > > >    Taking above into consideration I'm wondering what compilers
> > > >    are in use?
> > >
> > > kisskb reported the following m68k failures to me:
> > >     linux-next/m68k-allmodconfig/m68k-gcc8
> > >     linux-next/m68k-allmodconfig/m68k-gcc11
> > >     linux-next/m68k-allmodconfig/m68k-gcc12
> > >
> > > However, according to [1], linux-next/m68k-allmodconfig/m68k-gcc13
> > > did succeed, so I guess you are using gcc13?
> >
> > Yes, I compiled with these:
> >
> > $ gcc --version
> > gcc (Debian 13.2.0-5) 13.2.0
> 
> Time to install and try an older version ;-)

Yeah, compound literals seems the often-to-break topic (as per GCC bugzilla).
Tried with GCC 8 for ARM64 and indeed it doesn't build it well.

-- 
With Best Regards,
Andy Shevchenko




From Naohiro.Aota at wdc.com  Mon Dec  4 08:03:47 2023
From: Naohiro.Aota at wdc.com (Naohiro Aota)
Date: Mon, 4 Dec 2023 16:03:47 +0000
Subject: Performance drop due to alloc_workqueue() misuse and recent change
Message-ID: <dbu6wiwu3sdhmhikb2w6lns7b27gbobfavhjj57kwi2quafgwl@htjcc5oikcr3>

Recently, commit 636b927eba5b ("workqueue: Make unbound workqueues to use
per-cpu pool_workqueues") changed WQ_UNBOUND workqueue's behavior. It
changed the meaning of alloc_workqueue()'s max_active from an upper limit
imposed per NUMA node to a limit per CPU. As a result, massive number of
workers can be running at the same time, especially if the workqueue user
thinks the max_active is a global limit.

Actually, it is already written it is per-CPU limit in the documentation
before the commit. However, several callers seem to misuse max_active,
maybe thinking it is a global limit. It is an unexpected behavior change
for them.

For example, these callers set max_active = num_online_cpus(), which is a
suspicious limit applying to per-CPU. This config means we can have nr_cpu
* nr_cpu active tasks working at the same time.

fs/f2fs/data.c: sbi->post_read_wq = alloc_workqueue("f2fs_post_read_wq",
fs/f2fs/data.c-                                          WQ_UNBOUND | WQ_HIGHPRI,
fs/f2fs/data.c-                                          num_online_cpus());

fs/crypto/crypto.c:     fscrypt_read_workqueue = alloc_workqueue("fscrypt_read_queue",
fs/crypto/crypto.c-                                              WQ_UNBOUND | WQ_HIGHPRI,
fs/crypto/crypto.c-                                              num_online_cpus());

fs/verity/verify.c:     fsverity_read_workqueue = alloc_workqueue("fsverity_read_queue",
fs/verity/verify.c-                                               WQ_HIGHPRI,
fs/verity/verify.c-                                               num_online_cpus());

drivers/crypto/hisilicon/qm.c:  qm->wq = alloc_workqueue("%s", WQ_HIGHPRI | WQ_MEM_RECLAIM |
drivers/crypto/hisilicon/qm.c-                           WQ_UNBOUND, num_online_cpus(),
drivers/crypto/hisilicon/qm.c-                           pci_name(qm->pdev));

block/blk-crypto-fallback.c:    blk_crypto_wq = alloc_workqueue("blk_crypto_wq",
block/blk-crypto-fallback.c-                                    WQ_UNBOUND | WQ_HIGHPRI |
block/blk-crypto-fallback.c-                                    WQ_MEM_RECLAIM, num_online_cpus());

drivers/md/dm-crypt.c:          cc->crypt_queue = alloc_workqueue("kcryptd/%s",
drivers/md/dm-crypt.c-                                            WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM | WQ_UNBOUND,
drivers/md/dm-crypt.c-                                            num_online_cpus(), devname);

Furthermore, the change affects performance in a certain case.

Btrfs creates several WQ_UNBOUND workqueues with a default max_active =
min(NRCPUS + 2, 8). As my machine has 96 CPUs with NUMA disabled, this
max_active config allows running over 700 active works. Before the commit,
it is limited to 8 if NUMA is disabled or limited to 16 if NUMA nodes is 2.

I reverted the workqueue code back to before the commit, and I ran the
following fio command on RAID0 btrfs on 6 SSDs.

fio --group_reporting --eta=always --eta-interval=30s --eta-newline=30s \
    --rw=write --fallocate=none \
    --direct=1 --ioengine=libaio --iodepth=32 \
    --filesize=100G \
    --blocksize=64k \
    --time_based --runtime=300s \
    --end_fsync=1 \
    --directory=${MNT} \
    --name=writer --numjobs=32

By changing workqueue's max_active, the result varies.

- wq max_active=8   (intended limit by btrfs?)
  WRITE: bw=2495MiB/s (2616MB/s), 2495MiB/s-2495MiB/s (2616MB/s-2616MB/s), io=753GiB (808GB), run=308953-308953msec
- wq max_active=16  (actual limit on 2 NUMA nodes setup)
  WRITE: bw=1736MiB/s (1820MB/s), 1736MiB/s-1736MiB/s (1820MB/s-1820MB/s), io=670GiB (720GB), run=395532-395532msec
- wq max_active=768 (simulating current limit)
  WRITE: bw=1276MiB/s (1338MB/s), 1276MiB/s-1276MiB/s (1338MB/s-1338MB/s), io=375GiB (403GB), run=300984-300984msec

The current performance is slower than the previous limit (max_active=16)
by 27%, or it is 50% slower than the intended limit.  The performance drop
might be due to contention of the btrfs-endio-write works. There are over
700 kworker instances were created and 100 works are on the 'D' state
competing for a lock.

More specifically, I tested the same workload on the commit.

- At commit 636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu pool_workqueues")
  WRITE: bw=1191MiB/s (1249MB/s), 1191MiB/s-1191MiB/s (1249MB/s-1249MB/s), io=350GiB (376GB), run=300714-300714msec
- At the previous commit = 4cbfd3de73 ("workqueue: Call wq_update_unbound_numa() on all CPUs in NUMA node on CPU hotplug")
  WRITE: bw=1747MiB/s (1832MB/s), 1747MiB/s-1747MiB/s (1832MB/s-1832MB/s), io=748GiB (803GB), run=438134-438134msec

So, it is -31.8% performance down with the commit.

In summary, we misuse max_active, considering it is a global limit. And,
the recent commit introduced a huge performance drop in some cases.  We
need to review alloc_workqueue() usage to check if its max_active setting
is proper or not.

From dianders at chromium.org  Mon Dec  4 08:03:44 2023
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 4 Dec 2023 08:03:44 -0800
Subject: [RFC PATCH v3 2/5] i2c: of: Introduce component probe function
In-Reply-To: <CAGXv+5EpA531O1tW=h1RvK34+LMvtdve3=cNmfN=2+9t1jL_bA@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-3-wenst@chromium.org>
 <CAD=FV=U_+iQJtV0Wii89DQT1V_fJCeS9wcqA8EJAs-hmmmLLLg@mail.gmail.com> <CAGXv+5EpA531O1tW=h1RvK34+LMvtdve3=cNmfN=2+9t1jL_bA@mail.gmail.com>
Message-ID: <CAD=FV=WtvPUD+tXv0GghreG3w5yWedeHTYzhk-LNzf94fJ6B_Q@mail.gmail.com>

Hi,

On Mon, Dec 4, 2023 at 1:53?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> > IMO you should prototype how you're going to handle regulators and
> > GPIOs before finalizing the design. I was going to write that you
> > should just document that it was up to the caller to power things up
> > before calling this function, but then I realized that the caller
> > would have to duplicate much of this function in order to do so. In
> > the very least they'd have to find the nodes of the relevant devices
> > so that they could grab regulators and/or GPIOs. In order to avoid
> > this duplication, would the design need to change? Perhaps this would
> > be as simple as adding a callback function here that's called with all
> > of the nodes before probing? If that's right, it would be nice to have
> > that callback from the beginning so we don't need two variants of the
> > function...
>
> So I think I can prototype designs with one GPIO and multiple regulators,
> assuming each node has the same number of both? At least they should if
> they're on the same connector.
>
> More than one GPIO probably means there are some ordering and timing
> constraints, and won't be as generic.

I was hoping to see a prototype of how this could work in the
non-generic case where the board needed a custom function to power
things up. It seems like we'd still want to be able to use your code
for probing.


> > > +       for_each_child_of_node(i2c_node, node) {
> > > +               union i2c_smbus_data data;
> > > +               u32 addr;
> > > +
> > > +               if (!of_node_name_prefix(node, type))
> > > +                       continue;
> > > +               if (of_property_read_u32(node, "reg", &addr))
> > > +                       continue;
> > > +               if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
> >
> > I'd be tempted to say that the caller should be able to pass in a
> > function pointer here so they could use an alternative method to probe
> > instead of i2c_smbus_xfer(), though you'd want to make it easy to
> > default to i2c_smbus_xfer(). I could imagine someone might need a
> > different way to probe. For instance if you had two touchscreens both
> > at the same "reg" but that had different "hid-descr-addr" then this
> > could be important.
>
> I'd say the only specific probable type is hid-i2c. And that could be
> generic enough that we could incorporate it here if we wanted. However
> I think we want to keep the initial version a bit simpler.

I don't mind if the initial version is simpler, but I'd love to
understand how this will grow. It doesn't feel terrible to take in a
function pointer that will probe the device and then provide a
function that callers could pass in that simply did the simple
i2c_smbus_xfer().


> > > +                       continue;
> > > +
> >
> > Put the "break" right here. You've found the device and that was the
> > point of the loop.
>
> In its place we'd have an if (node) { <enable node> } block. I guess it
> makes it easier to read still?

...or perhaps an "if (!node) goto exit" block and then you don't need
indentation? Essentially the loop becomes the implementation: "node =
find_the_one_that_exists(...)".

-Doug


From Frank.Li at nxp.com  Mon Dec  4 08:08:25 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon,  4 Dec 2023 11:08:25 -0500
Subject: [PATCH v6 0/4] PCI: layerscape: Add suspend/resume support for ls1043 and ls1021
Message-ID: <20231204160829.2498703-1-Frank.Li@nxp.com>

Add suspend/resume support for ls1043 and ls1021.

Change log see each patch

Frank Li (4):
  PCI: layerscape: Add function pointer for exit_from_l2()
  PCI: layerscape: Add suspend/resume for ls1021a
  PCI: layerscape(ep): Rename pf_* as pf_lut_*
  PCI: layerscape: Add suspend/resume for ls1043a

 .../pci/controller/dwc/pci-layerscape-ep.c    |  16 +-
 drivers/pci/controller/dwc/pci-layerscape.c   | 191 +++++++++++++++---
 2 files changed, 176 insertions(+), 31 deletions(-)

-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec  4 08:08:26 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon,  4 Dec 2023 11:08:26 -0500
Subject: [PATCH v6 1/4] PCI: layerscape: Add function pointer for exit_from_l2()
In-Reply-To: <20231204160829.2498703-1-Frank.Li@nxp.com>
References: <20231204160829.2498703-1-Frank.Li@nxp.com>
Message-ID: <20231204160829.2498703-2-Frank.Li@nxp.com>

Since difference SoCs require different sequence for exiting L2, let's add
a separate "exit_from_l2()" callback. This callback can be used to execute
SoC specific sequence.

Change ls_pcie_exit_from_l2() return value from void to int. Return error
if exit_from_l2() failure at exit resume flow.

Acked-by: Roy Zang <Roy.Zang at nxp.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v6
    - none
    Change from v3 to v4
    - update commit message
      Add mani's review by tag
    Change from v2 to v3
    - fixed according to mani's feedback
      1. update commit message
      2. move dw_pcie_host_ops to next patch
      3. check return value from exit_from_l2()
    Change from v1 to v2
    - change subject 'a' to 'A'
    
    Change from v1 to v2
    - change subject 'a' to 'A'

 drivers/pci/controller/dwc/pci-layerscape.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 37956e09c65bd..aea89926bcc4f 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -39,6 +39,7 @@
 
 struct ls_pcie_drvdata {
 	const u32 pf_off;
+	int (*exit_from_l2)(struct dw_pcie_rp *pp);
 	bool pm_support;
 };
 
@@ -125,7 +126,7 @@ static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
 		dev_err(pcie->pci->dev, "PME_Turn_off timeout\n");
 }
 
-static void ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
+static int ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
 {
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
 	struct ls_pcie *pcie = to_ls_pcie(pci);
@@ -150,6 +151,8 @@ static void ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
 				 10000);
 	if (ret)
 		dev_err(pcie->pci->dev, "L2 exit timeout\n");
+
+	return ret;
 }
 
 static int ls_pcie_host_init(struct dw_pcie_rp *pp)
@@ -180,6 +183,7 @@ static const struct ls_pcie_drvdata ls1021a_drvdata = {
 static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.pf_off = 0xc0000,
 	.pm_support = true,
+	.exit_from_l2 = ls_pcie_exit_from_l2,
 };
 
 static const struct of_device_id ls_pcie_of_match[] = {
@@ -247,11 +251,14 @@ static int ls_pcie_suspend_noirq(struct device *dev)
 static int ls_pcie_resume_noirq(struct device *dev)
 {
 	struct ls_pcie *pcie = dev_get_drvdata(dev);
+	int ret;
 
 	if (!pcie->drvdata->pm_support)
 		return 0;
 
-	ls_pcie_exit_from_l2(&pcie->pci->pp);
+	ret = pcie->drvdata->exit_from_l2(&pcie->pci->pp);
+	if (ret)
+		return ret;
 
 	return dw_pcie_resume_noirq(pcie->pci);
 }
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec  4 08:08:27 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon,  4 Dec 2023 11:08:27 -0500
Subject: [PATCH v6 2/4] PCI: layerscape: Add suspend/resume for ls1021a
In-Reply-To: <20231204160829.2498703-1-Frank.Li@nxp.com>
References: <20231204160829.2498703-1-Frank.Li@nxp.com>
Message-ID: <20231204160829.2498703-3-Frank.Li@nxp.com>

Add suspend/resume support for Layerscape LS1021a.

In the suspend path, PME_Turn_Off message is sent to the endpoint to
transition the link to L2/L3_Ready state. In this SoC, there is no way to
check if the controller has received the PME_To_Ack from the endpoint or
not. So to be on the safer side, the driver just waits for
PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF
bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3
state depending on the VAUX supply.

In the resume path, the link is brought back from L2 to L0 by doing a
software reset.

Acked-by: Roy Zang <Roy.Zang at nxp.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v5 to v6
    - remove reduntant pci->pp.ops = &ls_pcie_host_ops;
    Change from v4 to v5
    - update comit message
    - remove a empty line
    - use comments
    /* Reset the PEX wrapper to bring the link out of L2 */
    - pci->pp.ops = pcie->drvdata->ops,
    ls_pcie_host_ops to the "ops" member of layerscape_drvdata.
    - don't set pcie->scfg = NULL at error path
    
    Change from v3 to v4
    - update commit message.
    - it is reset a glue logic part for PCI controller.
    - use regmap_write_bits() to reduce code change.
    
    Change from v2 to v3
    - update according to mani's feedback
    change from v1 to v2
    - change subject 'a' to 'A'

 drivers/pci/controller/dwc/pci-layerscape.c | 83 ++++++++++++++++++++-
 1 file changed, 80 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index aea89926bcc4f..711563777aeba 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -35,11 +35,19 @@
 #define PF_MCR_PTOMR		BIT(0)
 #define PF_MCR_EXL2S		BIT(1)
 
+/* LS1021A PEXn PM Write Control Register */
+#define SCFG_PEXPMWRCR(idx)	(0x5c + (idx) * 0x64)
+#define PMXMTTURNOFF		BIT(31)
+#define SCFG_PEXSFTRSTCR	0x190
+#define PEXSR(idx)		BIT(idx)
+
 #define PCIE_IATU_NUM		6
 
 struct ls_pcie_drvdata {
 	const u32 pf_off;
+	const struct dw_pcie_host_ops *ops;
 	int (*exit_from_l2)(struct dw_pcie_rp *pp);
+	bool scfg_support;
 	bool pm_support;
 };
 
@@ -47,6 +55,8 @@ struct ls_pcie {
 	struct dw_pcie *pci;
 	const struct ls_pcie_drvdata *drvdata;
 	void __iomem *pf_base;
+	struct regmap *scfg;
+	int index;
 	bool big_endian;
 };
 
@@ -171,18 +181,70 @@ static int ls_pcie_host_init(struct dw_pcie_rp *pp)
 	return 0;
 }
 
+static void scfg_pcie_send_turnoff_msg(struct regmap *scfg, u32 reg, u32 mask)
+{
+	/* Send PME_Turn_Off message */
+	regmap_write_bits(scfg, reg, mask, mask);
+
+	/*
+	 * There is no specific register to check for PME_To_Ack from endpoint.
+	 * So on the safe side, wait for PCIE_PME_TO_L2_TIMEOUT_US.
+	 */
+	mdelay(PCIE_PME_TO_L2_TIMEOUT_US/1000);
+
+	/*
+	 * Layerscape hardware reference manual recommends clearing the PMXMTTURNOFF bit
+	 * to complete the PME_Turn_Off handshake.
+	 */
+	regmap_write_bits(scfg, reg, mask, 0);
+}
+
+static void ls1021a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct ls_pcie *pcie = to_ls_pcie(pci);
+
+	scfg_pcie_send_turnoff_msg(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), PMXMTTURNOFF);
+}
+
+static int scfg_pcie_exit_from_l2(struct regmap *scfg, u32 reg, u32 mask)
+{
+	/* Reset the PEX wrapper to bring the link out of L2 */
+	regmap_write_bits(scfg, reg, mask, mask);
+	regmap_write_bits(scfg, reg, mask, 0);
+
+	return 0;
+}
+
+static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct ls_pcie *pcie = to_ls_pcie(pci);
+
+	return scfg_pcie_exit_from_l2(pcie->scfg, SCFG_PEXSFTRSTCR, PEXSR(pcie->index));
+}
+
 static const struct dw_pcie_host_ops ls_pcie_host_ops = {
 	.host_init = ls_pcie_host_init,
 	.pme_turn_off = ls_pcie_send_turnoff_msg,
 };
 
+static const struct dw_pcie_host_ops ls1021a_pcie_host_ops = {
+	.host_init = ls_pcie_host_init,
+	.pme_turn_off = ls1021a_pcie_send_turnoff_msg,
+};
+
 static const struct ls_pcie_drvdata ls1021a_drvdata = {
-	.pm_support = false,
+	.pm_support = true,
+	.scfg_support = true,
+	.ops = &ls1021a_pcie_host_ops,
+	.exit_from_l2 = ls1021a_pcie_exit_from_l2,
 };
 
 static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.pf_off = 0xc0000,
 	.pm_support = true,
+	.ops = &ls_pcie_host_ops,
 	.exit_from_l2 = ls_pcie_exit_from_l2,
 };
 
@@ -205,6 +267,8 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	struct dw_pcie *pci;
 	struct ls_pcie *pcie;
 	struct resource *dbi_base;
+	u32 index[2];
+	int ret;
 
 	pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
 	if (!pcie)
@@ -217,9 +281,8 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	pcie->drvdata = of_device_get_match_data(dev);
 
 	pci->dev = dev;
-	pci->pp.ops = &ls_pcie_host_ops;
-
 	pcie->pci = pci;
+	pci->pp.ops = pcie->drvdata->ops;
 
 	dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
 	pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
@@ -230,6 +293,20 @@ static int ls_pcie_probe(struct platform_device *pdev)
 
 	pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
 
+	if (pcie->drvdata->scfg_support) {
+		pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node, "fsl,pcie-scfg");
+		if (IS_ERR(pcie->scfg)) {
+			dev_err(dev, "No syscfg phandle specified\n");
+			return PTR_ERR(pcie->scfg);
+		}
+
+		ret = of_property_read_u32_array(dev->of_node, "fsl,pcie-scfg", index, 2);
+		if (ret)
+			return ret;
+
+		pcie->index = index[1];
+	}
+
 	if (!ls_pcie_is_bridge(pcie))
 		return -ENODEV;
 
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec  4 08:08:28 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon,  4 Dec 2023 11:08:28 -0500
Subject: [PATCH v6 3/4] PCI: layerscape(ep): Rename pf_* as pf_lut_*
In-Reply-To: <20231204160829.2498703-1-Frank.Li@nxp.com>
References: <20231204160829.2498703-1-Frank.Li@nxp.com>
Message-ID: <20231204160829.2498703-4-Frank.Li@nxp.com>

'pf' and 'lut' is just difference name in difference chips, but basic it is
a MMIO base address plus an offset.

Rename it to avoid duplicate pf_* and lut_* in driver.

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
Acked-by: Roy Zang <Roy.Zang at nxp.com>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    pf_lut is better than pf_* or lut* because some chip use 'pf', some chip
    use 'lut'.
    
    Change from v5 to v6
    move to previous patch
    -> -	.ops = &ls_pcie_host_ops;
    > +	.ops = &ls_pcie_host_ops,
    
    Change from v4 to v5
    - rename layerscape-ep code also
    change from v1 to v4
    - new patch at v3

 .../pci/controller/dwc/pci-layerscape-ep.c    | 16 ++++-----
 drivers/pci/controller/dwc/pci-layerscape.c   | 34 +++++++++----------
 2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index 3d3c50ef4b6ff..2ca339f938a86 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -49,7 +49,7 @@ struct ls_pcie_ep {
 	bool				big_endian;
 };
 
-static u32 ls_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
+static u32 ls_pcie_pf_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
 {
 	struct dw_pcie *pci = pcie->pci;
 
@@ -59,7 +59,7 @@ static u32 ls_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
 		return ioread32(pci->dbi_base + offset);
 }
 
-static void ls_lut_writel(struct ls_pcie_ep *pcie, u32 offset, u32 value)
+static void ls_pcie_pf_lut_writel(struct ls_pcie_ep *pcie, u32 offset, u32 value)
 {
 	struct dw_pcie *pci = pcie->pci;
 
@@ -76,8 +76,8 @@ static irqreturn_t ls_pcie_ep_event_handler(int irq, void *dev_id)
 	u32 val, cfg;
 	u8 offset;
 
-	val = ls_lut_readl(pcie, PEX_PF0_PME_MES_DR);
-	ls_lut_writel(pcie, PEX_PF0_PME_MES_DR, val);
+	val = ls_pcie_pf_lut_readl(pcie, PEX_PF0_PME_MES_DR);
+	ls_pcie_pf_lut_writel(pcie, PEX_PF0_PME_MES_DR, val);
 
 	if (!val)
 		return IRQ_NONE;
@@ -96,9 +96,9 @@ static irqreturn_t ls_pcie_ep_event_handler(int irq, void *dev_id)
 		dw_pcie_writel_dbi(pci, offset + PCI_EXP_LNKCAP, pcie->lnkcap);
 		dw_pcie_dbi_ro_wr_dis(pci);
 
-		cfg = ls_lut_readl(pcie, PEX_PF0_CONFIG);
+		cfg = ls_pcie_pf_lut_readl(pcie, PEX_PF0_CONFIG);
 		cfg |= PEX_PF0_CFG_READY;
-		ls_lut_writel(pcie, PEX_PF0_CONFIG, cfg);
+		ls_pcie_pf_lut_writel(pcie, PEX_PF0_CONFIG, cfg);
 		dw_pcie_ep_linkup(&pci->ep);
 
 		dev_dbg(pci->dev, "Link up\n");
@@ -130,10 +130,10 @@ static int ls_pcie_ep_interrupt_init(struct ls_pcie_ep *pcie,
 	}
 
 	/* Enable interrupts */
-	val = ls_lut_readl(pcie, PEX_PF0_PME_MES_IER);
+	val = ls_pcie_pf_lut_readl(pcie, PEX_PF0_PME_MES_IER);
 	val |=  PEX_PF0_PME_MES_IER_LDDIE | PEX_PF0_PME_MES_IER_HRDIE |
 		PEX_PF0_PME_MES_IER_LUDIE;
-	ls_lut_writel(pcie, PEX_PF0_PME_MES_IER, val);
+	ls_pcie_pf_lut_writel(pcie, PEX_PF0_PME_MES_IER, val);
 
 	return 0;
 }
diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 711563777aeba..f3dfb70066fb7 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -44,7 +44,7 @@
 #define PCIE_IATU_NUM		6
 
 struct ls_pcie_drvdata {
-	const u32 pf_off;
+	const u32 pf_lut_off;
 	const struct dw_pcie_host_ops *ops;
 	int (*exit_from_l2)(struct dw_pcie_rp *pp);
 	bool scfg_support;
@@ -54,13 +54,13 @@ struct ls_pcie_drvdata {
 struct ls_pcie {
 	struct dw_pcie *pci;
 	const struct ls_pcie_drvdata *drvdata;
-	void __iomem *pf_base;
+	void __iomem *pf_lut_base;
 	struct regmap *scfg;
 	int index;
 	bool big_endian;
 };
 
-#define ls_pcie_pf_readl_addr(addr)	ls_pcie_pf_readl(pcie, addr)
+#define ls_pcie_pf_lut_readl_addr(addr)	ls_pcie_pf_lut_readl(pcie, addr)
 #define to_ls_pcie(x)	dev_get_drvdata((x)->dev)
 
 static bool ls_pcie_is_bridge(struct ls_pcie *pcie)
@@ -101,20 +101,20 @@ static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
 	iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR);
 }
 
-static u32 ls_pcie_pf_readl(struct ls_pcie *pcie, u32 off)
+static u32 ls_pcie_pf_lut_readl(struct ls_pcie *pcie, u32 off)
 {
 	if (pcie->big_endian)
-		return ioread32be(pcie->pf_base + off);
+		return ioread32be(pcie->pf_lut_base + off);
 
-	return ioread32(pcie->pf_base + off);
+	return ioread32(pcie->pf_lut_base + off);
 }
 
-static void ls_pcie_pf_writel(struct ls_pcie *pcie, u32 off, u32 val)
+static void ls_pcie_pf_lut_writel(struct ls_pcie *pcie, u32 off, u32 val)
 {
 	if (pcie->big_endian)
-		iowrite32be(val, pcie->pf_base + off);
+		iowrite32be(val, pcie->pf_lut_base + off);
 	else
-		iowrite32(val, pcie->pf_base + off);
+		iowrite32(val, pcie->pf_lut_base + off);
 }
 
 static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
@@ -124,11 +124,11 @@ static void ls_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
 	u32 val;
 	int ret;
 
-	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_PF_MCR);
 	val |= PF_MCR_PTOMR;
-	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_PF_MCR, val);
 
-	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
+	ret = readx_poll_timeout(ls_pcie_pf_lut_readl_addr, LS_PCIE_PF_MCR,
 				 val, !(val & PF_MCR_PTOMR),
 				 PCIE_PME_TO_L2_TIMEOUT_US/10,
 				 PCIE_PME_TO_L2_TIMEOUT_US);
@@ -147,15 +147,15 @@ static int ls_pcie_exit_from_l2(struct dw_pcie_rp *pp)
 	 * Set PF_MCR_EXL2S bit in LS_PCIE_PF_MCR register for the link
 	 * to exit L2 state.
 	 */
-	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_PF_MCR);
 	val |= PF_MCR_EXL2S;
-	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_PF_MCR, val);
 
 	/*
 	 * L2 exit timeout of 10ms is not defined in the specifications,
 	 * it was chosen based on empirical observations.
 	 */
-	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
+	ret = readx_poll_timeout(ls_pcie_pf_lut_readl_addr, LS_PCIE_PF_MCR,
 				 val, !(val & PF_MCR_EXL2S),
 				 1000,
 				 10000);
@@ -242,7 +242,7 @@ static const struct ls_pcie_drvdata ls1021a_drvdata = {
 };
 
 static const struct ls_pcie_drvdata layerscape_drvdata = {
-	.pf_off = 0xc0000,
+	.pf_lut_off = 0xc0000,
 	.pm_support = true,
 	.ops = &ls_pcie_host_ops,
 	.exit_from_l2 = ls_pcie_exit_from_l2,
@@ -291,7 +291,7 @@ static int ls_pcie_probe(struct platform_device *pdev)
 
 	pcie->big_endian = of_property_read_bool(dev->of_node, "big-endian");
 
-	pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
+	pcie->pf_lut_base = pci->dbi_base + pcie->drvdata->pf_lut_off;
 
 	if (pcie->drvdata->scfg_support) {
 		pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node, "fsl,pcie-scfg");
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec  4 08:08:29 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon,  4 Dec 2023 11:08:29 -0500
Subject: [PATCH v6 4/4] PCI: layerscape: Add suspend/resume for ls1043a
In-Reply-To: <20231204160829.2498703-1-Frank.Li@nxp.com>
References: <20231204160829.2498703-1-Frank.Li@nxp.com>
Message-ID: <20231204160829.2498703-5-Frank.Li@nxp.com>

Add suspend/resume support for Layerscape LS1043a.

In the suspend path, PME_Turn_Off message is sent to the endpoint to
transition the link to L2/L3_Ready state. In this SoC, there is no way to
check if the controller has received the PME_To_Ack from the endpoint or
not. So to be on the safer side, the driver just waits for
PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF
bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3
state depending on the VAUX supply.

In the resume path, the link is brought back from L2 to L0 by doing a
software reset.

Acked-by: Roy Zang <Roy.Zang at nxp.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Chagne from v5 to v6
    - none
    Change from v4 to v5
    - update commit message
    - use comments
    /* Reset the PEX wrapper to bring the link out of L2 */
    
    Change from v3 to v4
    - Call scfg_pcie_send_turnoff_msg() shared with ls1021a
    - update commit message
    
    Change from v2 to v3
    - Remove ls_pcie_lut_readl(writel) function
    
    Change from v1 to v2
    - Update subject 'a' to 'A'

 drivers/pci/controller/dwc/pci-layerscape.c | 63 ++++++++++++++++++++-
 1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index f3dfb70066fb7..7cdada200de7e 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -41,6 +41,15 @@
 #define SCFG_PEXSFTRSTCR	0x190
 #define PEXSR(idx)		BIT(idx)
 
+/* LS1043A PEX PME control register */
+#define SCFG_PEXPMECR		0x144
+#define PEXPME(idx)		BIT(31 - (idx) * 4)
+
+/* LS1043A PEX LUT debug register */
+#define LS_PCIE_LDBG	0x7fc
+#define LDBG_SR		BIT(30)
+#define LDBG_WE		BIT(31)
+
 #define PCIE_IATU_NUM		6
 
 struct ls_pcie_drvdata {
@@ -224,6 +233,45 @@ static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
 	return scfg_pcie_exit_from_l2(pcie->scfg, SCFG_PEXSFTRSTCR, PEXSR(pcie->index));
 }
 
+static void ls1043a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct ls_pcie *pcie = to_ls_pcie(pci);
+
+	scfg_pcie_send_turnoff_msg(pcie->scfg, SCFG_PEXPMECR, PEXPME(pcie->index));
+}
+
+static int ls1043a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct ls_pcie *pcie = to_ls_pcie(pci);
+	u32 val;
+
+	/*
+	 * Reset the PEX wrapper to bring the link out of L2.
+	 * LDBG_WE: allows the user to have write access to the PEXDBG[SR] for both setting and
+	 *	    clearing the soft reset on the PEX module.
+	 * LDBG_SR: When SR is set to 1, the PEX module enters soft reset.
+	 */
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
+	val |= LDBG_WE;
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
+	val |= LDBG_SR;
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
+	val &= ~LDBG_SR;
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
+	val &= ~LDBG_WE;
+	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	return 0;
+}
+
 static const struct dw_pcie_host_ops ls_pcie_host_ops = {
 	.host_init = ls_pcie_host_init,
 	.pme_turn_off = ls_pcie_send_turnoff_msg,
@@ -241,6 +289,19 @@ static const struct ls_pcie_drvdata ls1021a_drvdata = {
 	.exit_from_l2 = ls1021a_pcie_exit_from_l2,
 };
 
+static const struct dw_pcie_host_ops ls1043a_pcie_host_ops = {
+	.host_init = ls_pcie_host_init,
+	.pme_turn_off = ls1043a_pcie_send_turnoff_msg,
+};
+
+static const struct ls_pcie_drvdata ls1043a_drvdata = {
+	.pf_lut_off = 0x10000,
+	.pm_support = true,
+	.scfg_support = true,
+	.ops = &ls1043a_pcie_host_ops,
+	.exit_from_l2 = ls1043a_pcie_exit_from_l2,
+};
+
 static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.pf_lut_off = 0xc0000,
 	.pm_support = true,
@@ -252,7 +313,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
 	{ .compatible = "fsl,ls1012a-pcie", .data = &layerscape_drvdata },
 	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021a_drvdata },
 	{ .compatible = "fsl,ls1028a-pcie", .data = &layerscape_drvdata },
-	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1021a_drvdata },
+	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043a_drvdata },
 	{ .compatible = "fsl,ls1046a-pcie", .data = &layerscape_drvdata },
 	{ .compatible = "fsl,ls2080a-pcie", .data = &layerscape_drvdata },
 	{ .compatible = "fsl,ls2085a-pcie", .data = &layerscape_drvdata },
-- 
2.34.1



From conor at kernel.org  Mon Dec  4 08:14:45 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 4 Dec 2023 16:14:45 +0000
Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <ZW3yXWJ7rTrtZzyg@MiWiFi-R3L-srv>
References: <20231130023955.5257-1-bhe@redhat.com>
 <20231130023955.5257-6-bhe@redhat.com>
 <20231201-blog-blasphemy-985d2665903c@wendy>
 <ZW3yXWJ7rTrtZzyg@MiWiFi-R3L-srv>
Message-ID: <20231204-liftoff-enclosure-d3e3daf0ab6e@spud>

On Mon, Dec 04, 2023 at 11:38:05PM +0800, Baoquan He wrote:
> On 12/01/23 at 10:38am, Conor Dooley wrote:
> > On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
> > 
> > $subject has a typo in the arch bit :)
> 
> Indeed, will fix if need report. Thanks for careful checking.
> 
> > 
> > > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > > loading related codes.
> > 
> > Commit messages should be understandable in isolation, but this only
> > explains (part of) what is obvious in the diff. Why is this change
> > being made?
> 
> The purpose has been detailedly described in cover letter and patch 1
> log. Andrew has picked these patches into his tree and grabbed the cover
> letter log into the relevant commit for people's later checking. All
> these seven patches will be present in mainline together. This is common
> way when posting patch series? Please let me know if I misunderstand
> anything.

Each patch having a commit message that explains why a change is being
made is the expectation. It is especially useful to explain the why
here, since it is not just a mechanical conversion of pr_debug()s as the
commit message suggests.

> > 
> > > 
> > > And also remove kexec_image_info() because the content has been printed
> > > out in generic code.
> > > 
> > > Signed-off-by: Baoquan He <bhe at redhat.com>
> > > ---
> > >  arch/riscv/kernel/elf_kexec.c     | 11 ++++++-----
> > >  arch/riscv/kernel/machine_kexec.c | 26 --------------------------
> > >  2 files changed, 6 insertions(+), 31 deletions(-)
> > > 
> > > diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> > > index e60fbd8660c4..5bd1ec3341fe 100644
> > > --- a/arch/riscv/kernel/elf_kexec.c
> > > +++ b/arch/riscv/kernel/elf_kexec.c
> > > @@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > >  	if (ret)
> > >  		goto out;
> > >  	kernel_start = image->start;
> > > -	pr_notice("The entry point of kernel at 0x%lx\n", image->start);
> > >  
> > >  	/* Add the kernel binary to the image */
> > >  	ret = riscv_kexec_elf_load(image, &ehdr, &elf_info,
> > > @@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > >  		image->elf_load_addr = kbuf.mem;
> > >  		image->elf_headers_sz = headers_sz;
> > >  
> > > -		pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > -			 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > +		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > +			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > >  
> > >  		/* Setup cmdline for kdump kernel case */
> > >  		modified_cmdline = setup_kdump_cmdline(image, cmdline,
> > > @@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > >  		pr_err("Error loading purgatory ret=%d\n", ret);
> > >  		goto out;
> > >  	}
> > > +	kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem);
> > > +
> > >  	ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry",
> > >  					     &kernel_start,
> > >  					     sizeof(kernel_start), 0);
> > > @@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > >  		if (ret)
> > >  			goto out;
> > >  		initrd_pbase = kbuf.mem;
> > 
> > > -		pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > +		kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase);
> > 
> > This is not a pr_debug().
> > 
> > >  	}
> > >  
> > >  	/* Add the DTB to the image */
> > > @@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > >  	}
> > >  	/* Cache the fdt buffer address for memory cleanup */
> > >  	image->arch.fdt = fdt;
> > 
> > > -	pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > +	kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem);
> > 
> > Neither is this. Why are they being moved from pr_notice()?
> 
> You are right. 
> 
> While always printing out the loaded location of purgatory and
> device tree doesn't make sense. It will be confusing when users
> see these even when they do normal kexec/kdump loading. It should be
> changed to pr_debug().
> 
> Which way do you suggest?
> 1) change it back to pr_debug(), fix it in another patch;
> 2) keep it as is in the patch;

Personally I think it is fine to change them all in one patch, but the
rationale for converting pr_notice() to your new debug infrastructure
needs to be in the commit message.

Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/ddd7efa2/attachment.sig>

From alexdeucher at gmail.com  Mon Dec  4 08:15:49 2023
From: alexdeucher at gmail.com (Alex Deucher)
Date: Mon, 4 Dec 2023 11:15:49 -0500
Subject: [PATCH v2 0/8] drm/plane-helpers: Minor clean ups
In-Reply-To: <20231204090852.1650-1-tzimmermann@suse.de>
References: <20231204090852.1650-1-tzimmermann@suse.de>
Message-ID: <CADnq5_PRqcugQHibGbhGb2LvnJ5uEtLFqOf=HQOf8_8zthgt2Q@mail.gmail.com>

On Mon, Dec 4, 2023 at 4:09?AM Thomas Zimmermann <tzimmermann at suse.de> wrote:
>
> Move drm_plane_helper_atomic_check() into udl, which is the only
> driver using it. Remove several unnecessary include statements for
> <drm/drm_plane_helper.h>.
>
> v2:
>         * fix documentation (Sui)
>
> Thomas Zimmermann (8):
>   drm/plane-helper: Move drm_plane_helper_atomic_check() into udl
>   drm/amdgpu: Do not include <drm/drm_plane_helper.h>
>   drm/loongson: Do not include <drm/drm_plane_helper.h>
>   drm/shmobile: Do not include <drm/drm_plane_helper.h>
>   drm/solomon: Do not include <drm/drm_plane_helper.h>
>   drm/ofdrm: Do not include <drm/drm_plane_helper.h>
>   drm/simpledrm: Do not include <drm/drm_plane_helper.h>
>   drm/xlnx: Do not include <drm/drm_plane_helper.h>

Series is:
Reviewed-by: Alex Deucher <alexander.deucher at amd.com>

>
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  1 -
>  drivers/gpu/drm/drm_crtc_helper.c             |  7 ++--
>  drivers/gpu/drm/drm_plane_helper.c            | 32 -------------------
>  drivers/gpu/drm/loongson/lsdc_plane.c         |  1 -
>  .../drm/renesas/shmobile/shmob_drm_plane.c    |  1 -
>  drivers/gpu/drm/solomon/ssd130x.h             |  1 -
>  drivers/gpu/drm/tiny/ofdrm.c                  |  1 -
>  drivers/gpu/drm/tiny/simpledrm.c              |  1 -
>  drivers/gpu/drm/udl/udl_modeset.c             | 19 +++++++++--
>  drivers/gpu/drm/xlnx/zynqmp_kms.c             |  1 -
>  include/drm/drm_plane_helper.h                |  2 --
>  11 files changed, 19 insertions(+), 48 deletions(-)
>
> --
> 2.43.0
>


From james.clark at arm.com  Mon Dec  4 08:17:43 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 4 Dec 2023 16:17:43 +0000
Subject: [PATCH v3 2/6] arm64: KVM: Move SPE and trace registers to the
 sysreg array
In-Reply-To: <86plzmb9jj.wl-maz@kernel.org>
References: <20231019165510.1966367-1-james.clark@arm.com>
 <20231019165510.1966367-3-james.clark@arm.com> <86plzmb9jj.wl-maz@kernel.org>
Message-ID: <1aca6009-9943-d0ee-0fa9-b88b33fd0540@arm.com>



On 04/12/2023 09:29, Marc Zyngier wrote:
> On Thu, 19 Oct 2023 17:55:00 +0100,
> James Clark <james.clark at arm.com> wrote:
>>
>> pmscr_el1 and trfcr_el1 are currently special cased in the
>> host_debug_state struct, but they're just registers after all so give
>> them entries in the sysreg array and refer to them through the host
>> context.
>>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Signed-off-by: James Clark <james.clark at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_host.h  |  6 ++--
>>  arch/arm64/include/asm/kvm_hyp.h   |  4 +--
>>  arch/arm64/kvm/hyp/nvhe/debug-sr.c | 44 +++++++++++++++---------------
>>  arch/arm64/kvm/hyp/nvhe/switch.c   |  4 +--
>>  4 files changed, 28 insertions(+), 30 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 4a966c0d7373..7c82927ddaf2 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -437,6 +437,8 @@ enum vcpu_sysreg {
>>  	CNTHP_CVAL_EL2,
>>  	CNTHV_CTL_EL2,
>>  	CNTHV_CVAL_EL2,
>> +	PMSCR_EL1,	/* Statistical profiling extension */
>> +	TRFCR_EL1,	/* Self-hosted trace filters */
> 
> Why this move? Are you also adding guest support for SPE?
> 
> Until you do, I don't see the need to pollute the guest's sysreg
> namespace.
> 
> 	M.
> 

Ah ok yes, I think I misunderstood your previous review comment. You're
right I don't touch SPE and it's only ever for the host so I can leave
it where it was in struct host_debug_state.

James


From dsimic at manjaro.org  Mon Dec  4 08:19:59 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Mon, 04 Dec 2023 17:19:59 +0100
Subject: [PATCH v3] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <95bb3618-496d-4b55-a2f7-1b4200cbe420@linaro.org>
References: <20231125184422.12315-1-krzysztof.kozlowski@linaro.org>
 <63ec18b2758a9e385f446fb00b60ee69@manjaro.org>
 <0bcc0679-b883-4435-8843-cc830122c0e1@linaro.org>
 <83b413441a953e8f2bc56adf09511a80@manjaro.org>
 <7021717e2e747b9c119b7c5091b60bdf@manjaro.org>
 <95bb3618-496d-4b55-a2f7-1b4200cbe420@linaro.org>
Message-ID: <619db272718a608ac211266aa2fd05aa@manjaro.org>

On 2023-12-04 16:11, Krzysztof Kozlowski wrote:
> On 03/12/2023 21:12, Dragan Simic wrote:
>> Just a brief reminder about my suggestions below, which seemingly 
>> didn't
>> find their way into the v4.  At least the first one, which improves 
>> the
>> opening sentence, is worth including, IMHO.
>> 
> 
> I applied almost all your suggestions, except few which I disagreed 
> with
> in my replies.

Sure, but I got no response from you after I replied and offered 
different versions of the few suggestions you disagreed with.  I mean, 
none of those are too important, except the one about the opening 
sentence, which is currently a bit awkward, so it might be good to have 
it improved as suggested.  It's the opening sentence after all. :)


From lkp at intel.com  Mon Dec  4 08:26:57 2023
From: lkp at intel.com (kernel test robot)
Date: Tue, 5 Dec 2023 00:26:57 +0800
Subject: [PATCH net-next v3 5/8] net: qualcomm: ipqess: add bridge
 offloading features to the IPQESS driver
In-Reply-To: <20231114105600.1012056-6-romain.gantois@bootlin.com>
References: <20231114105600.1012056-6-romain.gantois@bootlin.com>
Message-ID: <202312042338.JK8rFU7w-lkp@intel.com>

Hi Romain,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Romain-Gantois/dt-bindings-net-Introduce-the-Qualcomm-IPQESS-Ethernet-switch/20231114-185953
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231114105600.1012056-6-romain.gantois%40bootlin.com
patch subject: [PATCH net-next v3 5/8] net: qualcomm: ipqess: add bridge offloading features to the IPQESS driver
config: arc-randconfig-r112-20231116 (https://download.01.org/0day-ci/archive/20231204/202312042338.JK8rFU7w-lkp at intel.com/config)
compiler: arc-elf-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231204/202312042338.JK8rFU7w-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312042338.JK8rFU7w-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/net/dsa/qca/qca8k-8xxx.c:1982:5: sparse: sparse: symbol 'qca8k_dsa_port_fdb_dump' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:1988:6: sparse: sparse: symbol 'qca8k_dsa_port_stp_state_set' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:1995:6: sparse: sparse: symbol 'qca8k_dsa_port_fast_age' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2000:5: sparse: sparse: symbol 'qca8k_dsa_set_ageing_time' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2005:5: sparse: sparse: symbol 'qca8k_dsa_port_vlan_filtering' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2012:5: sparse: sparse: symbol 'qca8k_dsa_vlan_add' was not declared. Should it be static?

vim +/qca8k_dsa_port_fdb_dump +1982 drivers/net/dsa/qca/qca8k-8xxx.c

  1981	
> 1982	int qca8k_dsa_port_fdb_dump(struct dsa_switch *ds, int port,
  1983				    dsa_fdb_dump_cb_t *cb, void *data)
  1984	{
  1985		return qca8k_port_fdb_dump(ds->priv, port, cb, data);
  1986	}
  1987	
> 1988	void qca8k_dsa_port_stp_state_set(struct dsa_switch *ds, int port,
  1989					  u8 state)
  1990	{
  1991		qca8k_port_stp_state_set(ds->priv, port, state,
  1992					 dsa_to_port(ds, port)->learning, true);
  1993	}
  1994	
> 1995	void qca8k_dsa_port_fast_age(struct dsa_switch *ds, int port)
  1996	{
  1997		qca8k_port_fast_age(ds->priv, port);
  1998	}
  1999	
> 2000	int qca8k_dsa_set_ageing_time(struct dsa_switch *ds, unsigned int msecs)
  2001	{
  2002		return qca8k_set_ageing_time(ds->priv, msecs);
  2003	}
  2004	
> 2005	int qca8k_dsa_port_vlan_filtering(struct dsa_switch *ds, int port,
  2006					  bool vlan_filtering,
  2007					  struct netlink_ext_ack *extack)
  2008	{
  2009		return qca8k_port_vlan_filtering(ds->priv, port, vlan_filtering);
  2010	}
  2011	
> 2012	int qca8k_dsa_vlan_add(struct dsa_switch *ds, int port,
  2013			       const struct switchdev_obj_port_vlan *vlan,
  2014			       struct netlink_ext_ack *extack)
  2015	{
  2016		return qca8k_port_vlan_add(ds->priv, port, vlan, extack);
  2017	}
  2018	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From andersson at kernel.org  Mon Dec  4 08:31:57 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Mon, 4 Dec 2023 08:31:57 -0800
Subject: [PATCH net-next] net: stmmac: qcom-ethqos: Add sysfs nodes for
 qcom ethqos
In-Reply-To: <20231204084854.31543-1-quic_snehshah@quicinc.com>
References: <20231204084854.31543-1-quic_snehshah@quicinc.com>
Message-ID: <t36qr4ihbwf73sghpy4an6udbzbuz3nuksyvbpg6p2mfqgojnh@ktqjuwkuvigd>

On Mon, Dec 04, 2023 at 02:18:54PM +0530, Sneh Shah wrote:
> Add sysfs nodes to conifigure routing of specific vlan id to GVM queue.
> GVM queue is not exposed to PVM stmmac, so TC ops can't configure routing.
> 

Perhaps I'm just not familiar enough with the details of stmmac, but can
you please describe what PVM and GVM is?

Regards,
Bjorn

> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> ---
>  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 216 +++++++++++++++++-
>  1 file changed, 215 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index d3bf42d0fceb..ea89045a90a1 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -109,6 +109,8 @@ struct qcom_ethqos {
>  	unsigned int num_por;
>  	bool rgmii_config_loopback_en;
>  	bool has_emac_ge_3;
> +	int gvm_vlan_prio;
> +	int gvm_queue;
>  };
>  
>  static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
> @@ -710,6 +712,214 @@ static void ethqos_ptp_clk_freq_config(struct stmmac_priv *priv)
>  	netdev_dbg(priv->dev, "PTP rate %d\n", plat_dat->clk_ptp_rate);
>  }
>  
> +static ssize_t gvm_vlan_routing_store(struct device *dev,
> +				      struct device_attribute *attr,
> +				      const char *user_buf, size_t size)
> +{
> +	struct net_device *netdev = to_net_dev(dev);
> +	struct stmmac_priv *priv;
> +	struct qcom_ethqos *ethqos;
> +	u32 prio;
> +	s8 input = 0;
> +
> +	if (!netdev) {
> +		pr_err("netdev is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	priv = netdev_priv(netdev);
> +	if (!priv) {
> +		pr_err("priv is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	ethqos = priv->plat->bsp_priv;
> +	if (!ethqos) {
> +		pr_err("ethqos is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	if (kstrtos8(user_buf, 0, &input)) {
> +		pr_err("Error in reading option from user\n");
> +		return -EINVAL;
> +	}
> +
> +	if (input < 1 || input > 7) {
> +		pr_err("Invalid option set by user\n");
> +		return -EINVAL;
> +	}
> +
> +	if (input == ethqos->gvm_vlan_prio)
> +		pr_err("No effect as duplicate input\n");
> +
> +	ethqos->gvm_vlan_prio = input;
> +	prio  = 1 << input;
> +
> +	stmmac_rx_queue_prio(priv, priv->hw, prio, ethqos->gvm_queue);
> +
> +	return size;
> +}
> +
> +static ssize_t gvm_queue_mapping_store(struct device *dev,
> +				       struct device_attribute *attr,
> +				       const char *user_buf, size_t size)
> +{
> +	struct net_device *netdev = to_net_dev(dev);
> +	struct stmmac_priv *priv;
> +	struct qcom_ethqos *ethqos;
> +	u32 prio;
> +	s8 input = 0;
> +
> +	if (!netdev) {
> +		pr_err("netdev is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	priv = netdev_priv(netdev);
> +	if (!priv) {
> +		pr_err("priv is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	ethqos = priv->plat->bsp_priv;
> +	if (!ethqos) {
> +		pr_err("ethqos is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	if (kstrtos8(user_buf, 0, &input)) {
> +		pr_err("Error in reading option from user\n");
> +		return -EINVAL;
> +	}
> +
> +	if (input == ethqos->gvm_queue)
> +		pr_err("No effect as duplicate input\n");
> +
> +	ethqos->gvm_queue = input;
> +	prio  = 1 << input;
> +
> +	return size;
> +}
> +
> +static ssize_t gvm_queue_mapping_show(struct device *dev,
> +				      struct device_attribute *attr, char *user_buf)
> +{
> +	struct net_device *netdev = to_net_dev(dev);
> +	struct stmmac_priv *priv;
> +	struct qcom_ethqos *ethqos;
> +
> +	if (!netdev) {
> +		pr_err("netdev is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	priv = netdev_priv(netdev);
> +	if (!priv) {
> +		pr_err("priv is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	ethqos = priv->plat->bsp_priv;
> +	if (!ethqos) {
> +		pr_err("ethqos is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	return scnprintf(user_buf, 256, "%d\n", ethqos->gvm_queue);
> +}
> +
> +static ssize_t gvm_vlan_routing_show(struct device *dev,
> +				     struct device_attribute *attr, char *user_buf)
> +{
> +	struct net_device *netdev = to_net_dev(dev);
> +	struct stmmac_priv *priv;
> +	struct qcom_ethqos *ethqos;
> +
> +	if (!netdev) {
> +		pr_err("netdev is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	priv = netdev_priv(netdev);
> +	if (!priv) {
> +		pr_err("priv is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	ethqos = priv->plat->bsp_priv;
> +	if (!ethqos) {
> +		pr_err("ethqos is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	return scnprintf(user_buf, 256, "%d\n", ethqos->gvm_vlan_prio);
> +}
> +
> +static DEVICE_ATTR_RW(gvm_queue_mapping);
> +
> +static DEVICE_ATTR_RW(gvm_vlan_routing);
> +
> +static int ethqos_remove_sysfs(struct qcom_ethqos *ethqos)
> +{
> +	struct net_device *net_dev;
> +
> +	if (!ethqos) {
> +		pr_err("ethqos is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	net_dev = platform_get_drvdata(ethqos->pdev);
> +	if (!net_dev) {
> +		pr_err("netdev is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	sysfs_remove_file(&net_dev->dev.kobj,
> +			  &dev_attr_gvm_queue_mapping.attr);
> +	sysfs_remove_file(&net_dev->dev.kobj,
> +			  &dev_attr_gvm_vlan_routing.attr);
> +
> +	return 0;
> +}
> +
> +static int ethqos_create_sysfs(struct qcom_ethqos *ethqos)
> +{
> +	int ret;
> +	struct net_device *net_dev;
> +
> +	if (!ethqos) {
> +		pr_err("ethqos is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	net_dev = platform_get_drvdata(ethqos->pdev);
> +	if (!net_dev) {
> +		pr_err("netdev is NULL\n");
> +		return -EINVAL;
> +	}
> +
> +	ret = sysfs_create_file(&net_dev->dev.kobj,
> +				&dev_attr_gvm_queue_mapping.attr);
> +	if (ret) {
> +		pr_err("unable to create passthrough_en sysfs node\n");
> +		goto fail;
> +	}
> +
> +	ret = sysfs_create_file(&net_dev->dev.kobj,
> +				&dev_attr_gvm_vlan_routing.attr);
> +	if (ret) {
> +		pr_err("unable to create cv2x_priority sysfs node\n");
> +		goto fail;
> +	}
> +
> +	return ret;
> +
> +fail:
> +	ethqos_remove_sysfs(ethqos);
> +
> +	return ret;
> +}
> +
>  static int qcom_ethqos_probe(struct platform_device *pdev)
>  {
>  	struct device_node *np = pdev->dev.of_node;
> @@ -812,7 +1022,11 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
>  		plat_dat->serdes_powerdown  = qcom_ethqos_serdes_powerdown;
>  	}
>  
> -	return devm_stmmac_pltfr_probe(pdev, plat_dat, &stmmac_res);
> +	ret = devm_stmmac_pltfr_probe(pdev, plat_dat, &stmmac_res);
> +	if (ret)
> +		return ret;
> +
> +	return ethqos_create_sysfs(ethqos);
>  }
>  
>  static const struct of_device_id qcom_ethqos_match[] = {
> -- 
> 2.17.1
> 
> 


From bb at ti.com  Mon Dec  4 08:31:24 2023
From: bb at ti.com (Bryan Brattlof)
Date: Mon, 4 Dec 2023 10:31:24 -0600
Subject: [PATCH] arm64: dts: ti: k3-am65: Add AM652 DTSI file
In-Reply-To: <20231117165330.98472-1-afd@ti.com>
References: <20231117165330.98472-1-afd@ti.com>
Message-ID: <20231204163124.efdhd3mxmgwfcn3s@bryanbrattlof.com>

Hi Andrew!

On November 17, 2023 thus sayeth Andrew Davis:
> The AM652 is basically a AM654 but with 2 cores instead of 4. Add
> a DTSI file for AM652 matching AM654 except this core difference.
> 
> This removes the need to remove the extra cores from AM654 manually
> in DT files for boards that use the AM652 variant. Do that for
> the IOT2050 boards here.
> 
> Signed-off-by: Andrew Davis <afd at ti.com>

Reviewed-by: Bryan Brattlof <bb at ti.com>

> ---
>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   |  1 -
>  arch/arm64/boot/dts/ti/k3-am652.dtsi          | 74 +++++++++++++++++++
>  .../ti/k3-am6528-iot2050-basic-common.dtsi    | 11 +--
>  .../ti/k3-am6548-iot2050-advanced-common.dtsi |  1 +
>  4 files changed, 76 insertions(+), 11 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/ti/k3-am652.dtsi

Yeah this is a much cleaner approach than adding or deleting cores in 
the board files

~Bryan



From dianders at chromium.org  Mon Dec  4 08:50:01 2023
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 4 Dec 2023 08:50:01 -0800
Subject: [RFC PATCH v3 4/5] arm64: dts: mediatek: mt8173-elm-hana: Mark
 touchscreens and trackpads as fail
In-Reply-To: <CAGXv+5E+R292XsOFSL-j0KJMmVJjWtxMRgCK8besP7mo6NDOWA@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-5-wenst@chromium.org>
 <CAD=FV=W01gfxV6RN2o6CVS7jjf8qgKP-jUy9Bp94d2hWzVC48A@mail.gmail.com> <CAGXv+5E+R292XsOFSL-j0KJMmVJjWtxMRgCK8besP7mo6NDOWA@mail.gmail.com>
Message-ID: <CAD=FV=UQkAjgMuR85cPikNtCxsODWPWs7cibOcOoNGdjSSvF8Q@mail.gmail.com>

Hi,

On Sun, Dec 3, 2023 at 10:59?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> On Sat, Dec 2, 2023 at 8:58?AM Doug Anderson <dianders at chromium.org> wrote:
> >
> > Hi,
> >
> > On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
> > >
> > > @@ -44,6 +46,7 @@ trackpad2: trackpad at 2c {
> > >                 reg = <0x2c>;
> > >                 hid-descr-addr = <0x0020>;
> > >                 wakeup-source;
> > > +               status = "fail-needs-probe";
> >
> > While doing this, you could also remove the hack where the trackpad
> > IRQ pinctrl is listed under i2c4.
>
> Sure. I do think we can do away with it though. According to at least one
> schematic, the interrupt line has pull-ups on both sides of the voltage
> shifter.
>
> BTW, The touchscreen doesn't have pinctrl entries. This has pull-ups on
> both sides of the voltage shifter as well.

I dunno if the convention is different on Mediatek boards, but at
least on boards I've been involved with in the past we've always put
pinctrl entries just to make things explicit. This meant that we
didn't rely on the firmware/bootrom/defaults to leave pulls in any
particular state. ...otherwise those external pull-ups could be
fighting with internal pull-downs, right?

-Doug


From conor at kernel.org  Mon Dec  4 09:04:26 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 4 Dec 2023 17:04:26 +0000
Subject: [PATCH V3 1/3] dt-bindings: usb: xhci: add support for BCM2711
In-Reply-To: <7dd529a0-ebee-4f3b-879b-c7b1033cfdb9@gmx.net>
References: <20231202232217.89652-1-wahrenst@gmx.net>
 <20231202232217.89652-2-wahrenst@gmx.net>
 <20231203-chair-zen-afb8b280ca2f@spud>
 <20231203-traffic-aide-cb03afdb3546@spud>
 <7dd529a0-ebee-4f3b-879b-c7b1033cfdb9@gmx.net>
Message-ID: <20231204-sevenfold-slashing-bb7ea3419c92@spud>

On Sun, Dec 03, 2023 at 05:56:24PM +0100, Stefan Wahren wrote:
> Hi,
> 
> Am 03.12.23 um 12:11 schrieb Conor Dooley:
> > On Sun, Dec 03, 2023 at 11:06:43AM +0000, Conor Dooley wrote:
> > > On Sun, Dec 03, 2023 at 12:22:15AM +0100, Stefan Wahren wrote:
> > > > The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
> > > > but also requires a power domain.
> > Hmm
> > This & the driver change makes it look like your compatible setup should
> > be `compatible = "brcm,bcm2711-xhci", "brcm,xhci-brcm-v2";.
> i don't have insight into the hardware, but the fact that the other
> Broadcom SoC didn't require a power domain before let me think we
> shouldn't do this. Otherwise this binding was broken before. But Justin
> and Florian could clarify this.
> > If the pattern in this patch was repeated, we'd have to modify the
> > driver like your 2nd patch does for each and new broadcom system that
> > needs the power domain.
> From my understanding the DT compatible should be specific as possible.

Note that I am suggesting have 2 compatibles. One specific, falling back
to the existing generic one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/7c309316/attachment.sig>

From david at redhat.com  Mon Dec  4 09:27:08 2023
From: david at redhat.com (David Hildenbrand)
Date: Mon, 4 Dec 2023 18:27:08 +0100
Subject: [PATCH v3 01/15] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <104de2d6-ecf9-4b0c-a982-5bd8e1aea758@redhat.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-2-ryan.roberts@arm.com>
 <a12ce4f8-feb0-4e35-8f55-9270fe5a808b@redhat.com>
 <104de2d6-ecf9-4b0c-a982-5bd8e1aea758@redhat.com>
Message-ID: <5b8b9f8c-8e9b-42a5-b8b2-9b96903f3ada@redhat.com>

> 
> With rmap batching from [1] -- rebased+changed on top of that -- we could turn
> that into an effective (untested):
> 
>           if (page && folio_test_anon(folio)) {
> +               nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
> +                                               pte, enforce_uffd_wp, &nr_dirty,
> +                                               &nr_writable);
>                   /*
>                    * If this page may have been pinned by the parent process,
>                    * copy the page immediately for the child so that we'll always
>                    * guarantee the pinned page won't be randomly replaced in the
>                    * future.
>                    */
> -               folio_get(folio);
> -               if (unlikely(folio_try_dup_anon_rmap_pte(folio, page, src_vma))) {
> +               folio_ref_add(folio, nr);
> +               if (unlikely(folio_try_dup_anon_rmap_ptes(folio, page, nr, src_vma))) {
>                           /* Page may be pinned, we have to copy. */
> -                       folio_put(folio);
> -                       return copy_present_page(dst_vma, src_vma, dst_pte, src_pte,
> -                                                addr, rss, prealloc, page);
> +                       folio_ref_sub(folio, nr);
> +                       ret = copy_present_page(dst_vma, src_vma, dst_pte,
> +                                               src_pte, addr, rss, prealloc,
> +                                               page);
> +                       return ret == 0 ? 1 : ret;
>                   }
> -               rss[MM_ANONPAGES]++;
> +               rss[MM_ANONPAGES] += nr;
>           } else if (page) {
> -               folio_get(folio);
> -               folio_dup_file_rmap_pte(folio, page);
> -               rss[mm_counter_file(page)]++;
> +               nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
> +                                               pte, enforce_uffd_wp, &nr_dirty,
> +                                               &nr_writable);
> +               folio_ref_add(folio, nr);
> +               folio_dup_file_rmap_ptes(folio, page, nr);
> +               rss[mm_counter_file(page)] += nr;
>           }
> 
> 
> We'll have to test performance, but it could be that we want to specialize
> more on !folio_test_large(). That code is very performance-sensitive.
> 
> 
> [1] https://lkml.kernel.org/r/20231204142146.91437-1-david at redhat.com

So, on top of [1] without rmap batching but with a slightly modified 
version of yours (that keeps the existing code structure as pointed out 
and e.g., updates counter updates), running my fork() microbenchmark 
with a 1 GiB of memory:

Compared to [1], with all order-0 pages it gets 13--14% _slower_ and 
with all PTE-mapped THP (order-9) it gets ~29--30% _faster_.

So looks like we really want to have a completely seprate code path for 
"!folio_test_large()" to keep that case as fast as possible. And 
"Likely" we want to use "likely(!folio_test_large()". ;)

Performing rmap batching on top of that code only slightly (another 1% 
or so) improves performance in the PTE-mapped THP (order-9) case right 
now, in contrast to other rmap batching. Reason is as all rmap code gets 
inlined here and we're only doing subpage mapcount updates + PAE handling.

-- 
Cheers,

David / dhildenb



From catalin.marinas at arm.com  Mon Dec  4 09:31:47 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 4 Dec 2023 17:31:47 +0000
Subject: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64
In-Reply-To: <20231127134505.GI436702@nvidia.com>
References: <cover.1700766072.git.leon@kernel.org>
 <c3ae87aea7660c3d266905c19d10d8de0f9fb779.1700766072.git.leon@kernel.org>
 <ZWB373y5XuZDultf@FVFF77S0Q05N>
 <20231124122352.GB436702@nvidia.com>
 <ZWSOwT2OyMXD1lmo@arm.com>
 <20231127134505.GI436702@nvidia.com>
Message-ID: <ZW4NAzI_jvwoq8dL@arm.com>

On Mon, Nov 27, 2023 at 09:45:05AM -0400, Jason Gunthorpe wrote:
> On Mon, Nov 27, 2023 at 12:42:41PM +0000, Catalin Marinas wrote:
> > > > What's the actual requirement here? Is this just for performance?
> > > 
> > > Yes, just performance.
> > 
> > Do you have any rough numbers (percentage)? It's highly
> > microarchitecture-dependent until we get the ST64B instruction.
> 
> The current C code is an open coded store loop. The kernel does 250
> tries and measures if any one of them succeeds to combine.
> 
> On x86, and older ARM cores we see that 100% of the time at least 1 in
> 250 tries succeeds.
> 
> With the new CPU cores we see more like 9 out of 10 time there are 0
> in 250 tries that succeed. Ie we can go thousands of times without
> seeing any successful WC combine.
> 
> The STP block brings it back to 100% of the time 1 in 250 succeed.

That's a bit confusing to me: 1 in 250 succeeding is still pretty rare.
But I guess what your benchmark says is that at least 1 succeeded to
write-combine and it might as well be all 250 tries. It's more
interesting to see if there's actual performance gain in real-world
traffic, not just some artificial benchmark (I may have misunderstood
your numbers above).

> However, in userspace we have long been using ST4 to create a
> single-instruction 64 byte store on ARM64. As far as I know this is
> highly reliable. I don't have direct data on the STP configuration.

Personally I'd optimise the mempcy_toio() arm64 implementation to do
STPs if the alignment is right (like we do for classic memcpy()).
There's a slight overhead for alignment checking but I suspect it would
be lost as long as you can get the write-combining. Not sure whether the
interspersed reads in memcpy_toio() would somehow prevent the
write-combining.

A memcpy_toio_64() can use the new ST64B instruction if available or
fall back to memcpy_toio() on arm64. It should also have the DGH
instruction (io_stop_wc()) but only if falling back to classic
memcpy_toio(). We don't need DGH with ST64B.

> > More of a bike-shedding, I wonder whether the __iowrite*_copy()
> > semantics are better suited for what you need in terms of ordering (not
> > that mempcy_toio() to Normal NC memory gives us any ordering).
> 
> I have the same remark I gave to Niklas, this does not require
> alignment or an exact 64 byte size. It was clearly made to support WC
> stores since Pathscale did it, but I don't see this mapping nicely to
> the future 64 byte store instructions are we getting.

As above, I'd suggest just using memcpy_toio() as a fallback if ST64B is
not available.

> We could name it __iowrite512_copy() if that makes more sense?

I've been thinking at the __iowrite*_copy() and these also take a
'count' argument. I assume in this instance we don't really need one, so
it's just additional overhead (more like API clutter, I doubt it makes
much difference for performance). I'd say just stick to the
mempcy_toio_64() but have the io_stop_wc() inside this function as we
won't need it with ST64B.

Well, unless someone has a better name for this function.

-- 
Catalin


From conor at kernel.org  Mon Dec  4 09:33:26 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 4 Dec 2023 17:33:26 +0000
Subject: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
References: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231204-ladder-walnut-795fedf363d1@spud>

On Sun, Dec 03, 2023 at 06:46:22PM +0100, Krzysztof Kozlowski wrote:
> Document preferred coding style for Devicetree sources (DTS and DTSI),
> to bring consistency among all (sub)architectures and ease in reviews.
> 
> Cc: Andrew Davis <afd at ti.com>
> cc: Andrew Lunn <andrew at lunn.ch>
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Bjorn Andersson <andersson at kernel.org>
> Cc: Chen-Yu Tsai <wens at kernel.org>
> Cc: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> Cc: Jonathan Corbet <corbet at lwn.net>
> Cc: Matthias Brugger <matthias.bgg at gmail.com>
> Cc: Michal Simek <michal.simek at amd.com>
> Cc: Neil Armstrong <neil.armstrong at linaro.org>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Olof Johansson <olof at lixom.net>
> Cc: Rafa? Mi?ecki <zajec5 at gmail.com>
> Acked-by: Neil Armstrong <neil.armstrong at linaro.org>
> Acked-by: Heiko Stuebner <heiko at sntech.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Acked-by: Konrad Dybcio <konradybcio at kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

The advice here seems pretty reasonable, and it is nice to have
something written. Thanks for working on it.

Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/8871db31/attachment.sig>

From jbx6244 at gmail.com  Mon Dec  4 09:39:03 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 4 Dec 2023 18:39:03 +0100
Subject: [PATCH v1 1/3] dt-bindings: drm: rockchip: convert
 inno_hdmi-rockchip.txt to yaml
Message-ID: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>

Convert inno_hdmi-rockchip.txt to yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---

Note for rob+dt:
  Used enum to "soon" be able to add "rockchip,rk3128-inno-hdmi"

Changed V1:
  Rename file to more common layout
  Add/fix hdmi_out port example
---
 .../display/rockchip/inno_hdmi-rockchip.txt   |  49 ---------
 .../display/rockchip/rockchip,inno-hdmi.yaml  | 103 ++++++++++++++++++
 2 files changed, 103 insertions(+), 49 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
 create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml

diff --git a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
deleted file mode 100644
index cec21714f0e0..000000000000
--- a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Rockchip specific extensions to the Innosilicon HDMI
-================================
-
-Required properties:
-- compatible:
-	"rockchip,rk3036-inno-hdmi";
-- reg:
-	Physical base address and length of the controller's registers.
-- clocks, clock-names:
-	Phandle to hdmi controller clock, name should be "pclk"
-- interrupts:
-	HDMI interrupt number
-- ports:
-	Contain one port node with endpoint definitions as defined in
-	Documentation/devicetree/bindings/graph.txt.
-- pinctrl-0, pinctrl-name:
-	Switch the iomux of HPD/CEC pins to HDMI function.
-
-Example:
-hdmi: hdmi at 20034000 {
-	compatible = "rockchip,rk3036-inno-hdmi";
-	reg = <0x20034000 0x4000>;
-	interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
-	clocks = <&cru  PCLK_HDMI>;
-	clock-names = "pclk";
-	pinctrl-names = "default";
-	pinctrl-0 = <&hdmi_ctl>;
-
-	hdmi_in: port {
-		#address-cells = <1>;
-		#size-cells = <0>;
-		hdmi_in_lcdc: endpoint at 0 {
-			reg = <0>;
-			remote-endpoint = <&lcdc_out_hdmi>;
-		};
-	};
-};
-
-&pinctrl {
-	hdmi {
-		hdmi_ctl: hdmi-ctl {
-			rockchip,pins = <1 8  RK_FUNC_1 &pcfg_pull_none>,
-					<1 9  RK_FUNC_1 &pcfg_pull_none>,
-					<1 10 RK_FUNC_1 &pcfg_pull_none>,
-					<1 11 RK_FUNC_1 &pcfg_pull_none>;
-		};
-	};
-
-};
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
new file mode 100644
index 000000000000..96889c86849a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,inno-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Innosilicon HDMI controller
+
+maintainers:
+  - Sandy Huang <hjc at rock-chips.com>
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    enum:
+      - rockchip,rk3036-inno-hdmi
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    const: pclk
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port at 0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description:
+          Port node with one endpoint connected to a vop node.
+
+      port at 1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description:
+          Port node with one endpoint connected to a hdmi-connector node.
+
+    required:
+      - port at 0
+      - port at 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - pinctrl-0
+  - pinctrl-names
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3036-cru.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/pinctrl/rockchip.h>
+    hdmi: hdmi at 20034000 {
+      compatible = "rockchip,rk3036-inno-hdmi";
+      reg = <0x20034000 0x4000>;
+      interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+      clocks = <&cru  PCLK_HDMI>;
+      clock-names = "pclk";
+      pinctrl-names = "default";
+      pinctrl-0 = <&hdmi_ctl>;
+
+      ports {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        hdmi_in: port at 0 {
+          reg = <0>;
+          hdmi_in_vop: endpoint {
+            remote-endpoint = <&vop_out_hdmi>;
+          };
+        };
+
+        hdmi_out: port at 1 {
+          reg = <1>;
+          hdmi_out_con: endpoint {
+            remote-endpoint = <&hdmi_con_in>;
+          };
+        };
+      };
+    };
+
+    pinctrl {
+      hdmi {
+        hdmi_ctl: hdmi-ctl {
+          rockchip,pins = <1 RK_PB0 1 &pcfg_pull_none>,
+                          <1 RK_PB1 1 &pcfg_pull_none>,
+                          <1 RK_PB2 1 &pcfg_pull_none>,
+                          <1 RK_PB3 1 &pcfg_pull_none>;
+        };
+      };
+    };
--
2.39.2



From jbx6244 at gmail.com  Mon Dec  4 09:40:27 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 4 Dec 2023 18:40:27 +0100
Subject: [PATCH v1 2/3] ARM: dts: rockchip: rk3036: fix hdmi ports node
In-Reply-To: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
References: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
Message-ID: <9a2afac1-ed5c-382d-02b0-b2f5f1af3abb@gmail.com>

Fix hdmi ports node so that it matches the
rockchip,inno-hdmi.yaml binding.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3036.dtsi | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
index 8aa2e0864fed..2b00109bea6a 100644
--- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
@@ -405,12 +405,20 @@ hdmi: hdmi at 20034000 {
 		pinctrl-0 = <&hdmi_ctl>;
 		status = "disabled";

-		hdmi_in: port {
+		ports {
 			#address-cells = <1>;
 			#size-cells = <0>;
-			hdmi_in_vop: endpoint at 0 {
+
+			hdmi_in: port at 0 {
 				reg = <0>;
-				remote-endpoint = <&vop_out_hdmi>;
+
+				hdmi_in_vop: endpoint {
+					remote-endpoint = <&vop_out_hdmi>;
+				};
+			};
+
+			hdmi_out: port at 1 {
+				reg = <1>;
 			};
 		};
 	};
--
2.39.2



From jbx6244 at gmail.com  Mon Dec  4 09:40:58 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 4 Dec 2023 18:40:58 +0100
Subject: [PATCH v1 3/3] ARM: dts: rockchip: rk3036-kylin: add hdmi-connector
 node
In-Reply-To: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
References: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
Message-ID: <f5bc182b-f9b6-26a8-8649-19ce33e3c0e1@gmail.com>

Add hdmi-connector node to comply with the inno_hdmi binding.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3036-kylin.dts | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
index 67e1e04139e7..a213333be011 100644
--- a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
@@ -13,6 +13,17 @@ memory at 60000000 {
 		reg = <0x60000000 0x20000000>;
 	};

+	hdmi_con: hdmi-con {
+		compatible = "hdmi-connector";
+		type = "c";
+
+		port {
+			hdmi_con_in: endpoint {
+				remote-endpoint = <&hdmi_out_con>;
+			};
+		};
+	};
+
 	leds: gpio-leds {
 		compatible = "gpio-leds";

@@ -110,6 +121,12 @@ &hdmi {
 	status = "okay";
 };

+&hdmi_out {
+	hdmi_out_con: endpoint {
+		remote-endpoint = <&hdmi_con_in>;
+	};
+};
+
 &i2c1 {
 	clock-frequency = <400000>;

--
2.39.2



From daniel.lezcano at linaro.org  Mon Dec  4 09:42:19 2023
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 4 Dec 2023 18:42:19 +0100
Subject: [PATCH] clocksource: timer-ti-dm: Fix make W=n kerneldoc warnings
In-Reply-To: <20231114072930.40615-1-tony@atomide.com>
References: <20231114072930.40615-1-tony@atomide.com>
Message-ID: <8a71b223-defb-4c30-b34d-d024eccbf86c@linaro.org>

On 14/11/2023 08:29, Tony Lindgren wrote:
> Kernel test robot reports of kerneldoc related warnings that happen with
> make W=n for "parameter or member not described".
> 
> These were caused by changes to function parameter names with
> earlier commits where the kerneldoc parts were not updated.
> 
> Fixes: 49cd16bb573e ("clocksource/drivers/timer-ti-dm: Simplify register writes with dmtimer_write()")
> Fixes: a6e543f61531 ("clocksource/drivers/timer-ti-dm: Move struct omap_dm_timer fields to driver")
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202311040403.DzIiBuwU-lkp at intel.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202311040606.XL5OcR9O-lkp at intel.com/
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---

Applied, thanks

-- 
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From florian.fainelli at broadcom.com  Mon Dec  4 09:49:41 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Mon, 4 Dec 2023 09:49:41 -0800
Subject: [PATCH V3 1/3] dt-bindings: usb: xhci: add support for BCM2711
In-Reply-To: <20231204-sevenfold-slashing-bb7ea3419c92@spud>
References: <20231202232217.89652-1-wahrenst@gmx.net>
 <20231202232217.89652-2-wahrenst@gmx.net>
 <20231203-chair-zen-afb8b280ca2f@spud>
 <20231203-traffic-aide-cb03afdb3546@spud>
 <7dd529a0-ebee-4f3b-879b-c7b1033cfdb9@gmx.net>
 <20231204-sevenfold-slashing-bb7ea3419c92@spud>
Message-ID: <0f7fa9f1-2337-428f-8a76-a5b4cac30677@broadcom.com>

On 12/4/23 09:04, Conor Dooley wrote:
> On Sun, Dec 03, 2023 at 05:56:24PM +0100, Stefan Wahren wrote:
>> Hi,
>>
>> Am 03.12.23 um 12:11 schrieb Conor Dooley:
>>> On Sun, Dec 03, 2023 at 11:06:43AM +0000, Conor Dooley wrote:
>>>> On Sun, Dec 03, 2023 at 12:22:15AM +0100, Stefan Wahren wrote:
>>>>> The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
>>>>> but also requires a power domain.
>>> Hmm
>>> This & the driver change makes it look like your compatible setup should
>>> be `compatible = "brcm,bcm2711-xhci", "brcm,xhci-brcm-v2";.
>> i don't have insight into the hardware, but the fact that the other
>> Broadcom SoC didn't require a power domain before let me think we
>> shouldn't do this. Otherwise this binding was broken before. But Justin
>> and Florian could clarify this.

That seems to me like the right approach, the XHCI controller in 2711 is 
tied to a power domain, however that is not the case for other Broadcom 
STB SoCs.

>>> If the pattern in this patch was repeated, we'd have to modify the
>>> driver like your 2nd patch does for each and new broadcom system that
>>> needs the power domain.
>>  From my understanding the DT compatible should be specific as possible.
> 
> Note that I am suggesting have 2 compatibles. One specific, falling back
> to the existing generic one.

We could do that, yes.
-- 
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/02aa8565/attachment.p7s>

From andre.draszik at linaro.org  Mon Dec  4 09:51:43 2023
From: andre.draszik at linaro.org (=?ISO-8859-1?Q?Andr=E9?= Draszik)
Date: Mon, 04 Dec 2023 17:51:43 +0000
Subject: [PATCH v5 12/20] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <20231201160925.3136868-13-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
	 <20231201160925.3136868-13-peter.griffin@linaro.org>
Message-ID: <20bf05b9d9ccc5c11ef17500ac7a97c46dd46a9a.camel@linaro.org>

On Fri, 2023-12-01 at 16:09 +0000, Peter Griffin wrote:
> cmu_top is the top level clock management unit which contains PLLs, muxes,
> dividers and gates that feed the other clock management units.
> 
> cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> APM module.
> 
> Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> Tested-by: Will McVicker <willmcvicker at google.com>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
> ?drivers/clk/samsung/Makefile??? |??? 1 +
> ?drivers/clk/samsung/clk-gs101.c | 2495 +++++++++++++++++++++++++++++++
> ?2 files changed, 2496 insertions(+)
> ?create mode 100644 drivers/clk/samsung/clk-gs101.c
> 
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index ebbeacabe88f..3056944a5a54 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos7.o
> ?obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos7885.o
> ?obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos850.o
> ?obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynosautov9.o
> +obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-gs101.o
> ?obj-$(CONFIG_S3C64XX_COMMON_CLK)	+= clk-s3c64xx.o
> ?obj-$(CONFIG_S5PV210_COMMON_CLK)	+= clk-s5pv210.o clk-s5pv210-audss.o
> ?obj-$(CONFIG_TESLA_FSD_COMMON_CLK)	+= clk-fsd.o
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> new file mode 100644
> index 000000000000..6bd233a7ab63
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -0,0 +1,2495 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + * Author: Peter Griffin <peter.griffin at linaro.org>
> + *
> + * Common Clock Framework support for GS101.
> + */
> [...]
> +
> +/* List of parent clocks for Muxes in CMU_TOP: for CMU_HSI0 */
> +PNAME(mout_cmu_hsi0_usb31drd_p)	= { "oscclk", "dout_shared2_div2" };
> +
> +PNAME(mout_cmu_hsi0_bus_p)	= { "dout_shared0_div4", "dout_shared1_div4",
> +				??? "dout_shared2_div2", "dout_shared3_div2",
> +				??? "fout_spare_pll" };

This should also be updated....
 
> [...]
> +	MUX(CLK_MOUT_HSI0_BUS, "mout_cmu_hsi0_bus", mout_cmu_hsi0_bus_p,
> +	??? CLK_CON_MUX_MUX_CLKCMU_HSI0_BUS, 0, 3),

...because we have 8 possibilities now.

(I didn't check the other parents, but you mentioned you updated field widths
in other registers, too, so maybe need to double check the parent strings as well)


Cheers,
Andre'



From dianders at chromium.org  Mon Dec  4 09:52:56 2023
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 4 Dec 2023 09:52:56 -0800
Subject: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAPnjgZ2RjNzqJTRZSWvuscQhs+f8CG=fDcEO=qKXNeQLP53LnQ@mail.gmail.com>
References: <20231129172200.430674-1-sjg@chromium.org> <20231129172200.430674-3-sjg@chromium.org>
 <30f32467-51ea-47de-a272-38e074f4060b@pengutronix.de> <CAPnjgZ25xoXsi74XYY0E8ucQiowQqPdZgUHrfVNAYWKZEYODHg@mail.gmail.com>
 <875f0dbc-1d78-4901-91b2-6ad152bcea5a@pengutronix.de> <CAPnjgZ0UCkm5QCx+JXe1ggSshozPnOLB6cN=UoJyMn6S4wfFkg@mail.gmail.com>
 <06281f7c-e0f2-405c-95a9-0f7e9e84a7f6@pengutronix.de> <CAPnjgZ2TT+0BvbjwfnGLQ3EPEXnLW6f1epiFdaBHRYaSAn5xsA@mail.gmail.com>
 <8fbc81b1-31ab-46b0-87f4-b8bd8e8e2b47@pengutronix.de> <CAPnjgZ1iyxk0bb56QR10N5aSphRYhLsw7Ly=z2i6rQCxP_AYPw@mail.gmail.com>
 <5e8f42f8-2b03-4033-b6d2-9b3139f081d5@pengutronix.de> <CAPnjgZ2RjNzqJTRZSWvuscQhs+f8CG=fDcEO=qKXNeQLP53LnQ@mail.gmail.com>
Message-ID: <CAD=FV=WXQrbnjeVOLp--vmLzScvW9VLFRu+apSY4WnL9JFk-AQ@mail.gmail.com>

Hi,

On Sat, Dec 2, 2023 at 8:37?AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Ahmad,
>
> On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> >
> > Hello Simon,
> >
> > On 30.11.23 21:30, Simon Glass wrote:
> > > On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> > >> On 29.11.23 20:44, Simon Glass wrote:
> > >>> On Wed, 29 Nov 2023 at 12:33, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> > >>>>
> > >>>> On 29.11.23 20:27, Simon Glass wrote:
> > >>>>> On Wed, 29 Nov 2023 at 12:15, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> > >>>>>> On 29.11.23 20:02, Simon Glass wrote:
> > >>>>>>> On Wed, 29 Nov 2023 at 11:59, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> > >>>>>>>> The specification says that this is the root U-Boot compatible,
> > >>>>>>>> which I presume to mean the top-level compatible, which makes sense to me.
> > >>>>>>>>
> > >>>>>>>> The code here though adds all compatible strings from the device tree though,
> > >>>>>>>> is this intended?
> > >>>>>>>
> > >>>>>>> Yes, since it saves needing to read in each DT just to get the
> > >>>>>>> compatible stringlist.
> > >>>>>>
> > >>>>>> The spec reads as if only one string (root) is supposed to be in the list.
> > >>>>>> The script adds all compatibles though. This is not really useful as a bootloader
> > >>>>>> that's compatible with e.g. fsl,imx8mm would just take the first device tree
> > >>>>>> with that SoC, which is most likely to be wrong. It would be better to just
> > >>>>>> specify the top-level compatible, so the bootloader fails instead of taking
> > >>>>>> the first DT it finds.
> > >>>>>
> > >>>>> We do need to have a list, since we have to support different board revs, etc.
> > >>>>
> > >>>> Can you give me an example? The way I see it, a bootloader with
> > >>>> compatible "vendor,board" and a FIT with configuration with compatibles:
> > >>>>
> > >>>>   "vendor,board-rev-a", "vendor,board"
> > >>>>   "vendor,board-rev-b", "vendor,board"
> > >>>>
> > >>>> would just result in the bootloader booting the first configuration, even if
> > >>>> the device is actually rev-b.
> > >>>
> > >>> You need to find the best match, not just any match. This is
> > >>> documented in the function comment for fit_conf_find_compat().
> > >>
> > >> In my above example, both configuration are equally good.
> > >> Can you give me an example where it makes sense to have multiple
> > >> compatibles automatically extracted from the device tree compatible?
> > >>
> > >> The way I see it having more than one compatible here just has
> > >> downsides.
> > >
> > > I don't have an example to hand, but this is the required mechanism of
> > > FIT. This feature has been in place for many years and is used by
> > > ChromeOS, at least.
> >
> > I see the utility of a FIT configuration with
> >
> >     compatible = "vendor,board-rev-a", "vendor,board-rev-b";
> >
> > I fail to see a utility for a configuration with
> >
> >     compatible = "vendor,board", "vendor,SoM", "vendor,SoC";
> >
> > Any configuration that ends up being booted because "vendor,SoC" was matched is
> > most likely doomed to fail. Therefore, I would suggest that only the top level
> > configuration is written into the FIT configurations automatically.
>
> Firstly, I am not an expert on this.
>
> Say you have a board with variants. The compatible string in U-Boot
> may be something like:
>
> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
> "rockchip,rk3288";
>
> If you then have several FIT configurations, they may be something like:
>
> "google,veyron-brain-rev0", "google,veyron-brain", "google,veyron",
> "rockchip,rk3288";
> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
> "rockchip,rk3288";
> "google,veyron-brain-rev2", "google,veyron-brain", "google,veyron",
> "rockchip,rk3288";
>
> You want to choose the second one, since it is a better match than the others.
>
> +Doug Anderson who knows a lot more about this than me.

Hopefully this is all explained by:

https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html


From sjg at chromium.org  Mon Dec  4 09:59:44 2023
From: sjg at chromium.org (Simon Glass)
Date: Mon, 4 Dec 2023 10:59:44 -0700
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231203153401.GV8402@pendragon.ideasonboard.com>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com>
Message-ID: <CAPnjgZ0XWDO90cq_h6V_EoOX+kmGLBRZwgT5RURCwQBQFONDYg@mail.gmail.com>

Hi Laurent,

On Sun, 3 Dec 2023 at 08:33, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>
> Hi Simon,
>
> Thank you for the patch.
>
> On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> >
> > The files compress from about 86MB to 24MB using this approach.
> >
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> >
> > Add a 'make image.fit' build target for arm64, as well. Use
> > FIT_COMPRESSION to select a different algorithm.
> >
> > The FIT can be examined using 'dumpimage -l'.
> >
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> >
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
>
> FIT images are very useful, so I think this is a very welcome addition
> to the kernel build system. It can get tricky though: given the
> versatile nature of FIT images, there can't be any
> one-size-fits-them-all solution to build them, and striking the right
> balance between what makes sense for the kernel and the features that
> users may request will probably lead to bikeshedding. As we all love
> bikeshedding, I thought I would start selfishly, with a personal use
> case :-) This isn't a yak-shaving request though, I don't see any reason
> to delay merging this series.

OK, sounds good!

>
> Have you envisioned building FIT images with a subset of DTBs, or adding
> DTBOs ? Both would be fairly trivial extensions to this script by
> extending the supported command line arguments. It would perhaps be more
> difficult to integrate in the kernel build system though. This leads me
> to a second question: would you consider merging extensions to this
> script if they are not used by the kernel build system, but meant for
> users who manually invoke the script ? More generally, is the script
> meant to be used stand-alone as well, in which case its command line
> arguments need to remain backward-compatible, or do you see it as being
> internal to the kernel ?

The script as written is internal to the kernel, but I am sure it
could be expanded in some ways. I am waiting to see it merged before
worrying too much about what might happen in the future!

[..]

Regards,
Simon


From tj at kernel.org  Mon Dec  4 10:07:07 2023
From: tj at kernel.org (Tejun Heo)
Date: Mon, 4 Dec 2023 08:07:07 -1000
Subject: Performance drop due to alloc_workqueue() misuse and recent
 change
In-Reply-To: <dbu6wiwu3sdhmhikb2w6lns7b27gbobfavhjj57kwi2quafgwl@htjcc5oikcr3>
References: <dbu6wiwu3sdhmhikb2w6lns7b27gbobfavhjj57kwi2quafgwl@htjcc5oikcr3>
Message-ID: <ZW4VS3Z0auYCjg-W@slm.duckdns.org>

Hello,

On Mon, Dec 04, 2023 at 04:03:47PM +0000, Naohiro Aota wrote:
> Recently, commit 636b927eba5b ("workqueue: Make unbound workqueues to use
> per-cpu pool_workqueues") changed WQ_UNBOUND workqueue's behavior. It
> changed the meaning of alloc_workqueue()'s max_active from an upper limit
> imposed per NUMA node to a limit per CPU. As a result, massive number of
> workers can be running at the same time, especially if the workqueue user
> thinks the max_active is a global limit.
> 
> Actually, it is already written it is per-CPU limit in the documentation
> before the commit. However, several callers seem to misuse max_active,
> maybe thinking it is a global limit. It is an unexpected behavior change
> for them.

Right, and the behavior has been like that for a very long time and there
was no other way to achieve reasonable level of concurrency, so the current
situation is expected.

> For example, these callers set max_active = num_online_cpus(), which is a
> suspicious limit applying to per-CPU. This config means we can have nr_cpu
> * nr_cpu active tasks working at the same time.

Yeah, that sounds like a good indicator.

> fs/f2fs/data.c: sbi->post_read_wq = alloc_workqueue("f2fs_post_read_wq",
> fs/f2fs/data.c-                                          WQ_UNBOUND | WQ_HIGHPRI,
> fs/f2fs/data.c-                                          num_online_cpus());
> 
> fs/crypto/crypto.c:     fscrypt_read_workqueue = alloc_workqueue("fscrypt_read_queue",
> fs/crypto/crypto.c-                                              WQ_UNBOUND | WQ_HIGHPRI,
> fs/crypto/crypto.c-                                              num_online_cpus());
> 
> fs/verity/verify.c:     fsverity_read_workqueue = alloc_workqueue("fsverity_read_queue",
> fs/verity/verify.c-                                               WQ_HIGHPRI,
> fs/verity/verify.c-                                               num_online_cpus());
> 
> drivers/crypto/hisilicon/qm.c:  qm->wq = alloc_workqueue("%s", WQ_HIGHPRI | WQ_MEM_RECLAIM |
> drivers/crypto/hisilicon/qm.c-                           WQ_UNBOUND, num_online_cpus(),
> drivers/crypto/hisilicon/qm.c-                           pci_name(qm->pdev));
> 
> block/blk-crypto-fallback.c:    blk_crypto_wq = alloc_workqueue("blk_crypto_wq",
> block/blk-crypto-fallback.c-                                    WQ_UNBOUND | WQ_HIGHPRI |
> block/blk-crypto-fallback.c-                                    WQ_MEM_RECLAIM, num_online_cpus());
> 
> drivers/md/dm-crypt.c:          cc->crypt_queue = alloc_workqueue("kcryptd/%s",
> drivers/md/dm-crypt.c-                                            WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM | WQ_UNBOUND,
> drivers/md/dm-crypt.c-                                            num_online_cpus(), devname);

Most of these work items are CPU bound but not completley so. e.g.
kcrypt_crypt_write_continue() does wait_for_completion(), so setting
max_active to 1 likely isn't what they want either. They mostly want some
reasonable system-wide concurrency limit w.r.t. the CPU count while keeping
some level of flexibility in terms of task placement.

The previous max_active wasn't great for this because its meaning changed
depending on the number of nodes. Now, the meaning doesn't change but it's
not really useful for the above purpose. It's only useful for avoiding
melting the system completely.

One way to go about it is to declare that concurrency level management for
unbound workqueue is on users but that seems not ideal given many use cases
would want it anyway.

Let me think it over but I think the right way to go about it is going the
other direction - ie. making max_active apply to the whole system regardless
of the number of nodes / ccx's / whatever.

> Furthermore, the change affects performance in a certain case.
> 
> Btrfs creates several WQ_UNBOUND workqueues with a default max_active =
> min(NRCPUS + 2, 8). As my machine has 96 CPUs with NUMA disabled, this
> max_active config allows running over 700 active works. Before the commit,
> it is limited to 8 if NUMA is disabled or limited to 16 if NUMA nodes is 2.
> 
> I reverted the workqueue code back to before the commit, and I ran the
> following fio command on RAID0 btrfs on 6 SSDs.
> 
> fio --group_reporting --eta=always --eta-interval=30s --eta-newline=30s \
>     --rw=write --fallocate=none \
>     --direct=1 --ioengine=libaio --iodepth=32 \
>     --filesize=100G \
>     --blocksize=64k \
>     --time_based --runtime=300s \
>     --end_fsync=1 \
>     --directory=${MNT} \
>     --name=writer --numjobs=32
> 
> By changing workqueue's max_active, the result varies.
> 
> - wq max_active=8   (intended limit by btrfs?)
>   WRITE: bw=2495MiB/s (2616MB/s), 2495MiB/s-2495MiB/s (2616MB/s-2616MB/s), io=753GiB (808GB), run=308953-308953msec
> - wq max_active=16  (actual limit on 2 NUMA nodes setup)
>   WRITE: bw=1736MiB/s (1820MB/s), 1736MiB/s-1736MiB/s (1820MB/s-1820MB/s), io=670GiB (720GB), run=395532-395532msec
> - wq max_active=768 (simulating current limit)
>   WRITE: bw=1276MiB/s (1338MB/s), 1276MiB/s-1276MiB/s (1338MB/s-1338MB/s), io=375GiB (403GB), run=300984-300984msec
> 
> The current performance is slower than the previous limit (max_active=16)
> by 27%, or it is 50% slower than the intended limit.  The performance drop
> might be due to contention of the btrfs-endio-write works. There are over
> 700 kworker instances were created and 100 works are on the 'D' state
> competing for a lock.
> 
> More specifically, I tested the same workload on the commit.
> 
> - At commit 636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu pool_workqueues")
>   WRITE: bw=1191MiB/s (1249MB/s), 1191MiB/s-1191MiB/s (1249MB/s-1249MB/s), io=350GiB (376GB), run=300714-300714msec
> - At the previous commit = 4cbfd3de73 ("workqueue: Call wq_update_unbound_numa() on all CPUs in NUMA node on CPU hotplug")
>   WRITE: bw=1747MiB/s (1832MB/s), 1747MiB/s-1747MiB/s (1832MB/s-1832MB/s), io=748GiB (803GB), run=438134-438134msec
> 
> So, it is -31.8% performance down with the commit.
> 
> In summary, we misuse max_active, considering it is a global limit. And,
> the recent commit introduced a huge performance drop in some cases.  We
> need to review alloc_workqueue() usage to check if its max_active setting
> is proper or not.

Thanks a lot for the report. I think it's a lot more reasonable to assume
that max_active is global for unbound workqueues. The current workqueue
behavior is not very intuitive or useful. I'll try to find something more
reasonable. Thanks for the report and analysis. Much appreciated.

Thanks.

-- 
tejun


From nathan at kernel.org  Mon Dec  4 10:13:04 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Mon, 4 Dec 2023 11:13:04 -0700
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error:
 instruction variant requires ARMv6 or later
In-Reply-To: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
Message-ID: <20231204181304.GA2043538@dev-arch.thelio-3990X>

Hi Naresh,

On Mon, Dec 04, 2023 at 05:33:26PM +0530, Naresh Kamboju wrote:
> Following build errors noticed on Linux next-20231204 tag with clang-nightly
> for arm and arm64.
> 
> ## Test Regressions (compared to next-20231201)
> * arm64, build
>   - clang-nightly-defconfig
>   - clang-nightly-defconfig-40bc7ee5
>   - clang-nightly-lkftconfig
>   - clang-nightly-lkftconfig-kselftest
> 
> * arm, build
>   - clang-nightly-allnoconfig
>   - clang-nightly-axm55xx_defconfig
>   - clang-nightly-bcm2835_defconfig
>   - clang-nightly-clps711x_defconfig
>   - clang-nightly-defconfig
>   - clang-nightly-exynos_defconfig
>   - clang-nightly-imx_v6_v7_defconfig
>   - clang-nightly-keystone_defconfig
>   - clang-nightly-lkftconfig
>   - clang-nightly-lkftconfig-kselftest
>   - clang-nightly-omap2plus_defconfig
>   - clang-nightly-pxa910_defconfig
>   - clang-nightly-s3c6400_defconfig
>   - clang-nightly-s5pv210_defconfig
>   - clang-nightly-sama5_defconfig
>   - clang-nightly-shmobile_defconfig
>   - clang-nightly-tinyconfig
>   - clang-nightly-u8500_defconfig
>   - clang-nightly-vexpress_defconfig
> 
> 
> Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
> 
> 
> Build log on arm64:
> ---------
> In file included from lib/vdso/gettimeofday.c:5:
> In file included from include/vdso/datapage.h:135:
> arch/arm64/include/asm/vdso/compat_gettimeofday.h:152:15: error:
> instruction variant requires ARMv6 or later
>   152 |         asm volatile("mov %0, %1" : "=r"(ret) : "r"(_vdso_data));
>       |                      ^
> <inline asm>:1:2: note: instantiated into assembly here
>     1 |         mov r4, r1
>       |         ^
> In file included from <built-in>:3:
> lib/vdso/gettimeofday.c:139:3: error: invalid instruction
>   139 |                 smp_rmb();
>       |                 ^
> 
> Build log on arm:
> ---------
> In file included from arch/arm/vfp/vfpmodule.c:23:
> arch/arm/include/asm/cp15.h:101:2: error: instruction requires: data-barriers
>   101 |         isb();
>       |         ^

This is caused by a change to Debian's LLVM that changes the internal
defaults of the arm-linux-gnueabi and arm-linux-gnueabihf tuples:

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/907baf024b9a5a1626893d9e731b6c79ccf45c87

We use arm-linux-gnueabi for the kernel (see scripts/Makefile.clang) so
now we have a hardcoded armv5te CPU, even if we are building for armv7
or such.

I am still investigating into what (if anything) can be done to resolve
this on the kernel side. We could potentially revert commit
ddc72c9659b5 ("kbuild: clang: do not use CROSS_COMPILE for target
triple") but I am not sure that will save us from that change, as
tuxmake's CROSS_COMPILE=arm-linux-gnueabihf will cause us to have an
armv7 CPU even though we may not be building for armv7.

Cheers,
Nathan


From nm at ti.com  Mon Dec  4 10:13:36 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 12:13:36 -0600
Subject: [PATCH v2 3/3] arm64: dts: ti: add verdin am62 mallow board
In-Reply-To: <20231201145551.23337-4-francesco@dolcini.it>
References: <20231201145551.23337-1-francesco@dolcini.it>
 <20231201145551.23337-4-francesco@dolcini.it>
Message-ID: <20231204181336.scm2fgfyyzpr2u7t@dimmer>

On 15:55-20231201, Francesco Dolcini wrote:
> From: Joao Paulo Goncalves <joao.goncalves at toradex.com>

[...]

> +
> +	tpm at 1 {
> +		compatible = "infineon,slb9670", "tcg,tpm_tis-spi";

arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dtb: /bus at f0000/spi at 20110000/tpm at 1: failed to match any schema with compatible: ['infineon,slb9670', 'tcg,tpm_tis-spi']
arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dtb: /bus at f0000/spi at 20110000/tpm at 1: failed to match any schema with compatible: ['infineon,slb9670', 'tcg,tpm_tis-spi']

We should either drop this node OR introduce bindings and later
introduce this series.

Yes, I know there are other places where the compatible is already used
arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts
arch/arm64/boot/dts/xilinx/zynqmp-sm-k26-revA.dts
etc.. But, unfortunately, I'd rather see the binding
Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt
transition over to yaml prior to picking things up. (NOTE: the same
rules apply to TI devs as well..)

> +		reg = <1>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_qspi1_dqs_gpio>;
> +		interrupt-parent = <&main_gpio1>;
> +		interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
> +		spi-max-frequency = <18500000>;

[...]
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From linux at armlinux.org.uk  Mon Dec  4 10:23:02 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Mon, 4 Dec 2023 18:23:02 +0000
Subject: [RFC PATCH v3 00/39] ACPI/arm64: add support for virtual
 cpuhotplug
In-Reply-To: <CAJZ5v0j-73_+9U3ngDAf9w1ADDhBTKctJdWboqUk-okH2TQGyg@mail.gmail.com>
References: <ZTffkAdOqL2pI2la@shell.armlinux.org.uk>
 <CAJZ5v0j-73_+9U3ngDAf9w1ADDhBTKctJdWboqUk-okH2TQGyg@mail.gmail.com>
Message-ID: <ZW4ZBkj2oCmxv55T@shell.armlinux.org.uk>

On Tue, Oct 24, 2023 at 08:26:58PM +0200, Rafael J. Wysocki wrote:
> On Tue, Oct 24, 2023 at 5:15?PM Russell King (Oracle)
> <linux at armlinux.org.uk> wrote:
> >
> > Hi,
> >
> > I'm posting James' patch set updated with most of the review comments
> > from his RFC v2 series back in September. Individual patches have a
> > changelog attached at the bottom of the commit message. Those which
> > I have finished updating have my S-o-b on them, those which still have
> > outstanding review comments from RFC v2 do not. In some of these cases
> > I've asked questions and am waiting for responses.
> >
> > I'm posting this as RFC v3 because there's still some unaddressed
> > comments and it's clearly not ready for merging. Even if it was ready
> > to be merged, it is too late in this development cycle to be taking
> > this change in, so there would be little point posting it non-RFC.
> > Also James stated that he's waiting for confirmation from the
> > Kubernetes/Kata folk - I have no idea what the status is there.
> >
> > I will be sending each patch individually to a wider audience
> > appropriate for that patch - apologies to those missing out on this
> > cover message. I have added more mailing lists to the series with the
> > exception of the acpica list in a hope of this cover message also
> > reaching those folk.
> >
> > The changes that aren't included are:
> >
> > 1. Updates for my patch that was merged via Thomas (thanks!):
> >    c4dd854f740c cpu-hotplug: Provide prototypes for arch CPU registration
> >    rather than having this change spread through James' patches.
> >
> > 2. New patch - simplification of PA-RISC's smp_prepare_boot_cpu()
> >
> > 3. Moved "ACPI: Use the acpi_device_is_present() helper in more places"
> >    and "ACPI: Rename acpi_scan_device_not_present() to be about
> >    enumeration" to the beginning of the series - these two patches are
> >    already queued up for merging into 6.7.
> >
> > 4. Moved "arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into
> >    a helper" to the beginning of the series, which has been submitted,
> >    but as yet the fate of that posting isn't known.
> >
> > The first four patches in this series are provided for completness only.
> >
> > There is an additional patch in James' git tree that isn't in the set
> > of patches that James posted: "ACPI: processor: Only call
> > arch_unregister_cpu() if HOTPLUG_CPU is selected" which looks to me to
> > be a workaround for arch_unregister_cpu() being under the ifdef. I've
> > commented on this on the RFC v2 posting making a suggestion, but as yet
> > haven't had any response.
> >
> > I've included almost all of James' original covering body below the
> > diffstat.
> >
> > The reason that I'm doing this is to help move this code forward so
> > hopefully it can be merged - which is why I have been keen to dig out
> > from James' patches anything that can be merged and submit it
> > separately, since this is a feature for which some users have a
> > definite need for.
> 
> I've gone through the series and there is at least one thing in it
> that concerns me a lot and some others that at least appear to be
> really questionable.
> 
> I need more time to send comments which I'm not going to do before the
> 6.7 merge window (sorry), but from what I can say right now, this is
> not looking good.

Hi Rafael,

Will you be able to send your comments, so that we can find out what
your other concerns are please? I'm getting questions from interested
parties who want to know what your concerns are.

Nothing much has changed to the ACPI changes, so I think it's still
valid to have the comments back for this.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From afd at ti.com  Mon Dec  4 10:22:38 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:38 -0600
Subject: [PATCH RFC 03/10] ARM: dts: omap4: Add device tree entry for SGX GPU
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-4-afd@ti.com>

Add SGX GPU device entry to base OMAP4 dtsi file.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi b/arch/arm/boot/dts/ti/omap/omap4.dtsi
index 2bbff9032be3e..559b2bfe4ca7c 100644
--- a/arch/arm/boot/dts/ti/omap/omap4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi
@@ -501,10 +501,11 @@ sgx_module: target-module at 56000000 {
 			#size-cells = <1>;
 			ranges = <0 0x56000000 0x2000000>;
 
-			/*
-			 * Closed source PowerVR driver, no child device
-			 * binding or driver in mainline
-			 */
+			gpu at 0 {
+				compatible = "ti,omap4430-gpu", "img,powervr-sgx540";
+				reg = <0x0 0x2000000>; /* 32MB */
+				interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+			};
 		};
 
 		/*
-- 
2.39.2



From afd at ti.com  Mon Dec  4 10:22:37 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:37 -0600
Subject: [PATCH RFC 02/10] ARM: dts: omap3: Add device tree entry for SGX GPU
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-3-afd@ti.com>

Add SGX GPU device entries to base OMAP3 dtsi files.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 arch/arm/boot/dts/ti/omap/am3517.dtsi   | 11 ++++++-----
 arch/arm/boot/dts/ti/omap/omap34xx.dtsi | 11 ++++++-----
 arch/arm/boot/dts/ti/omap/omap36xx.dtsi |  9 +++++----
 3 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/ti/omap/am3517.dtsi b/arch/arm/boot/dts/ti/omap/am3517.dtsi
index 77e58e686fb17..19aad715dff70 100644
--- a/arch/arm/boot/dts/ti/omap/am3517.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am3517.dtsi
@@ -162,12 +162,13 @@ sgx_module: target-module at 50000000 {
 			clock-names = "fck", "ick";
 			#address-cells = <1>;
 			#size-cells = <1>;
-			ranges = <0 0x50000000 0x4000>;
+			ranges = <0 0x50000000 0x10000>;
 
-			/*
-			 * Closed source PowerVR driver, no child device
-			 * binding or driver in mainline
-			 */
+			gpu at 0 {
+				compatible = "ti,omap3430-gpu", "img,powervr-sgx530";
+				reg = <0x0 0x10000>; /* 64kB */
+				interrupts = <21>;
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/ti/omap/omap34xx.dtsi b/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
index fc7233ac183a8..acdd0ee34421d 100644
--- a/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
@@ -164,12 +164,13 @@ sgx_module: target-module at 50000000 {
 			clock-names = "fck", "ick";
 			#address-cells = <1>;
 			#size-cells = <1>;
-			ranges = <0 0x50000000 0x4000>;
+			ranges = <0 0x50000000 0x10000>;
 
-			/*
-			 * Closed source PowerVR driver, no child device
-			 * binding or driver in mainline
-			 */
+			gpu at 0 {
+				compatible = "ti,omap3430-gpu", "img,powervr-sgx530";
+				reg = <0x0 0x10000>; /* 64kB */
+				interrupts = <21>;
+			};
 		};
 	};
 
diff --git a/arch/arm/boot/dts/ti/omap/omap36xx.dtsi b/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
index e6d8070c1bf88..c3d79ecd56e39 100644
--- a/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
@@ -211,10 +211,11 @@ sgx_module: target-module at 50000000 {
 			#size-cells = <1>;
 			ranges = <0 0x50000000 0x2000000>;
 
-			/*
-			 * Closed source PowerVR driver, no child device
-			 * binding or driver in mainline
-			 */
+			gpu at 0 {
+				compatible = "ti,omap3630-gpu", "img,powervr-sgx530";
+				reg = <0x0 0x2000000>; /* 32MB */
+				interrupts = <21>;
+			};
 		};
 	};
 
-- 
2.39.2



From afd at ti.com  Mon Dec  4 10:22:44 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:44 -0600
Subject: [PATCH RFC 09/10] ARM: dts: sun6i: Add device tree entry for SGX GPU
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-10-afd@ti.com>

Add SGX GPU device entry to base sun6i-a31 dtsi file.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 arch/arm/boot/dts/allwinner/sun6i-a31.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi b/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
index 5cce4918f84c9..e6998783b89aa 100644
--- a/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
@@ -962,6 +962,15 @@ mdio: mdio {
 			};
 		};
 
+		gpu: gpu at 1c40000 {
+			compatible = "allwinner,sun6i-a31-gpu", "img,powervr-sgx544";
+			reg = <0x01c40000 0x10000>;
+			interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_GPU_CORE>, <&ccu CLK_GPU_MEMORY>;
+			clock-names = "core", "mem";
+			status = "disabled";
+		};
+
 		crypto: crypto-engine at 1c15000 {
 			compatible = "allwinner,sun6i-a31-crypto",
 				     "allwinner,sun4i-a10-crypto";
-- 
2.39.2



From afd at ti.com  Mon Dec  4 10:22:43 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:43 -0600
Subject: [PATCH RFC 08/10] arm64: dts: ti: k3-am654-main: Add device tree entry for SGX GPU
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-9-afd@ti.com>

Add SGX GPU device entry to base AM654 dtsi file.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 29048d6577cf6..d3431aca41026 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -1044,6 +1044,13 @@ dss_ports: ports {
 		};
 	};
 
+	gpu: gpu at 7000000 {
+		compatible = "ti,am6548-gpu", "img,powervr-sgx544";
+		reg = <0x0 0x7000000 0x0 0x10000>;
+		interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+		power-domains = <&k3_pds 65 TI_SCI_PD_EXCLUSIVE>;
+	};
+
 	ehrpwm0: pwm at 3000000 {
 		compatible = "ti,am654-ehrpwm", "ti,am3352-ehrpwm";
 		#pwm-cells = <3>;
-- 
2.39.2



From afd at ti.com  Mon Dec  4 10:22:39 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:39 -0600
Subject: [PATCH RFC 04/10] ARM: dts: omap5: Add device tree entry for SGX GPU
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-5-afd@ti.com>

Add SGX GPU device entry to base OMAP5 dtsi file.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 arch/arm/boot/dts/ti/omap/omap5.dtsi | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/ti/omap/omap5.dtsi b/arch/arm/boot/dts/ti/omap/omap5.dtsi
index bac6fa8387936..6a66214ad0e2f 100644
--- a/arch/arm/boot/dts/ti/omap/omap5.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap5.dtsi
@@ -453,10 +453,11 @@ target-module at 56000000 {
 			#size-cells = <1>;
 			ranges = <0 0x56000000 0x2000000>;
 
-			/*
-			 * Closed source PowerVR driver, no child device
-			 * binding or driver in mainline
-			 */
+			gpu at 0 {
+				compatible = "ti,omap5432-gpu", "img,powervr-sgx544";
+				reg = <0x0 0x2000000>; /* 32MB */
+				interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+			};
 		};
 
 		target-module at 58000000 {
-- 
2.39.2



From afd at ti.com  Mon Dec  4 10:22:35 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:35 -0600
Subject: [PATCH RFC 00/10] Device tree support for Imagination Series5 GPU
Message-ID: <20231204182245.33683-1-afd@ti.com>

Hello all,

I know this has been tried before[0], but given the recent upstreaming of
the Series6+ GPU bindings I figured it might be time to give the Series5
bindings another try.

While there is currently no mainline driver for these binding, there is an
open source out-of-tree kernel-side driver available[1]. Having a stable
and upstream binding for these devices allows us to describe this hardware
in device tree.

This is my vision for how these bindings should look, along with some
example uses in several SoC DT files. The compatible names have been
updated to match what was decided on for Series6+, but otherwise most
is the same as we have been using in our vendor tree for many years.

Thanks,
Andrew

Based on next-20231204.

[0]: https://lkml.org/lkml/2020/4/24/1222
[1]: https://github.com/openpvrsgx-devgroup

Andrew Davis (10):
  dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
  ARM: dts: omap3: Add device tree entry for SGX GPU
  ARM: dts: omap4: Add device tree entry for SGX GPU
  ARM: dts: omap5: Add device tree entry for SGX GPU
  ARM: dts: AM33xx: Add device tree entry for SGX GPU
  ARM: dts: AM437x: Add device tree entry for SGX GPU
  ARM: dts: DRA7xx: Add device tree entry for SGX GPU
  arm64: dts: ti: k3-am654-main: Add device tree entry for SGX GPU
  ARM: dts: sun6i: Add device tree entry for SGX GPU
  MIPS: DTS: jz4780: Add device tree entry for SGX GPU

 .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
 arch/arm/boot/dts/allwinner/sun6i-a31.dtsi    |  9 +++
 arch/arm/boot/dts/ti/omap/am33xx.dtsi         |  9 +--
 arch/arm/boot/dts/ti/omap/am3517.dtsi         | 11 +--
 arch/arm/boot/dts/ti/omap/am4372.dtsi         |  6 ++
 arch/arm/boot/dts/ti/omap/dra7.dtsi           |  9 ++-
 arch/arm/boot/dts/ti/omap/omap34xx.dtsi       | 11 +--
 arch/arm/boot/dts/ti/omap/omap36xx.dtsi       |  9 +--
 arch/arm/boot/dts/ti/omap/omap4.dtsi          |  9 +--
 arch/arm/boot/dts/ti/omap/omap5.dtsi          |  9 +--
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi      |  7 ++
 arch/mips/boot/dts/ingenic/jz4780.dtsi        | 11 +++
 12 files changed, 136 insertions(+), 33 deletions(-)

-- 
2.39.2



From afd at ti.com  Mon Dec  4 10:22:36 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:36 -0600
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-2-afd@ti.com>

The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
multiple vendors. Describe how the SGX GPU is integrated in these SoC,
including register space and interrupts. Clocks, reset, and power domain
information is SoC specific.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
 1 file changed, 63 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
index a13298f1a1827..9f036891dad0b 100644
--- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
+++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
@@ -11,11 +11,33 @@ maintainers:
   - Frank Binns <frank.binns at imgtec.com>
 
 properties:
+  $nodename:
+    pattern: '^gpu@[a-f0-9]+$'
+
   compatible:
-    items:
-      - enum:
-          - ti,am62-gpu
-      - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
+    oneOf:
+      - items:
+          - enum:
+              - ti,am62-gpu
+          - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
+      - items:
+          - enum:
+              - ti,omap3430-gpu # Rev 121
+              - ti,omap3630-gpu # Rev 125
+          - const: img,powervr-sgx530
+      - items:
+          - enum:
+              - ingenic,jz4780-gpu # Rev 130
+              - ti,omap4430-gpu # Rev 120
+          - const: img,powervr-sgx540
+      - items:
+          - enum:
+              - allwinner,sun6i-a31-gpu # MP2 Rev 115
+              - ti,omap4470-gpu # MP1 Rev 112
+              - ti,omap5432-gpu # MP2 Rev 105
+              - ti,am5728-gpu # MP2 Rev 116
+              - ti,am6548-gpu # MP1 Rev 117
+          - const: img,powervr-sgx544
 
   reg:
     maxItems: 1
@@ -40,8 +62,6 @@ properties:
 required:
   - compatible
   - reg
-  - clocks
-  - clock-names
   - interrupts
 
 additionalProperties: false
@@ -56,6 +76,43 @@ allOf:
       properties:
         clocks:
           maxItems: 1
+      required:
+        - clocks
+        - clock-names
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: ti,am654-sgx544
+    then:
+      properties:
+        power-domains:
+          minItems: 1
+      required:
+        - power-domains
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: allwinner,sun6i-a31-gpu
+    then:
+      properties:
+        clocks:
+          minItems: 2
+        clock-names:
+          minItems: 2
+      required:
+        - clocks
+        - clock-names
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: ingenic,jz4780-gpu
+    then:
+      required:
+        - clocks
+        - clock-names
 
 examples:
   - |
-- 
2.39.2



From afd at ti.com  Mon Dec  4 10:22:42 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:42 -0600
Subject: [PATCH RFC 07/10] ARM: dts: DRA7xx: Add device tree entry for SGX GPU
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-8-afd@ti.com>

Add SGX GPU device entry to base DRA7x dtsi file.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 arch/arm/boot/dts/ti/omap/dra7.dtsi | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ti/omap/dra7.dtsi b/arch/arm/boot/dts/ti/omap/dra7.dtsi
index 6509c742fb58c..8527643cb69a8 100644
--- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
@@ -850,12 +850,19 @@ target-module at 56000000 {
 					<SYSC_IDLE_SMART>;
 			ti,sysc-sidle = <SYSC_IDLE_FORCE>,
 					<SYSC_IDLE_NO>,
-					<SYSC_IDLE_SMART>;
+					<SYSC_IDLE_SMART>,
+					<SYSC_IDLE_SMART_WKUP>;
 			clocks = <&gpu_clkctrl DRA7_GPU_CLKCTRL 0>;
 			clock-names = "fck";
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges = <0 0x56000000 0x2000000>;
+
+			gpu at 0 {
+				compatible = "ti,am5728-gpu", "img,powervr-sgx544";
+				reg = <0x0 0x10000>; /* 64kB */
+				interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+			};
 		};
 
 		crossbar_mpu: crossbar at 4a002a48 {
-- 
2.39.2



From afd at ti.com  Mon Dec  4 10:22:40 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:40 -0600
Subject: [PATCH RFC 05/10] ARM: dts: AM33xx: Add device tree entry for SGX GPU
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-6-afd@ti.com>

Add SGX GPU device entry to base AM33xx dtsi file.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 arch/arm/boot/dts/ti/omap/am33xx.dtsi | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/ti/omap/am33xx.dtsi b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
index 1a2cd5baf4021..1868aef16687f 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
@@ -639,10 +639,11 @@ target-module at 56000000 {
 			#size-cells = <1>;
 			ranges = <0 0x56000000 0x1000000>;
 
-			/*
-			 * Closed source PowerVR driver, no child device
-			 * binding or driver in mainline
-			 */
+			gpu at 0 {
+				compatible = "ti,omap3630-gpu", "img,powervr-sgx530";
+				reg = <0x0 0x10000>; /* 64kB */
+				interrupts = <37>;
+			};
 		};
 	};
 };
-- 
2.39.2



From irogers at google.com  Mon Dec  4 10:23:29 2023
From: irogers at google.com (Ian Rogers)
Date: Mon,  4 Dec 2023 10:23:29 -0800
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup isn't set
Message-ID: <20231204182330.654255-1-irogers@google.com>

A metric is default by having "Default" within its groups. The default
metricgroup name needn't be set and this can result in segv in
default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
that assume it has a value when there is a Default metric group. To
avoid the segv initialize the value to "".

Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
Signed-off-by: Ian Rogers <irogers at google.com>
---
 tools/perf/util/metricgroup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 0484736d9fe4..ca3e0404f187 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -225,7 +225,7 @@ static struct metric *metric__new(const struct pmu_metric *pm,
 
 	m->pmu = pm->pmu ?: "cpu";
 	m->metric_name = pm->metric_name;
-	m->default_metricgroup_name = pm->default_metricgroup_name;
+	m->default_metricgroup_name = pm->default_metricgroup_name ?: "";
 	m->modifier = NULL;
 	if (modifier) {
 		m->modifier = strdup(modifier);
-- 
2.43.0.rc2.451.g8631bc7472-goog



From irogers at google.com  Mon Dec  4 10:23:30 2023
From: irogers at google.com (Ian Rogers)
Date: Mon,  4 Dec 2023 10:23:30 -0800
Subject: [PATCH v1 2/2] perf vendor events arm64: Fix default AmpereOne metrics
In-Reply-To: <20231204182330.654255-1-irogers@google.com>
References: <20231204182330.654255-1-irogers@google.com>
Message-ID: <20231204182330.654255-2-irogers@google.com>

Add default metric group name for TopdownL1 metrics.

Fixes: 59faeaf80d02 ("perf vendor events arm64: Fix for AmpereOne metrics")
Signed-off-by: Ian Rogers <irogers at google.com>
---
 tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json
index e2848a9d4848..afcdad58ef89 100644
--- a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json
+++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json
@@ -231,6 +231,7 @@
         "MetricName": "slots_lost_misspeculation_fraction",
         "MetricExpr": "100 * ((OP_SPEC - OP_RETIRED) / (CPU_CYCLES * #slots))",
         "BriefDescription": "Fraction of slots lost due to misspeculation",
+        "DefaultMetricgroupName": "TopdownL1",
         "MetricGroup": "Default;TopdownL1",
         "ScaleUnit": "1percent of slots"
     },
@@ -238,6 +239,7 @@
         "MetricName": "retired_fraction",
         "MetricExpr": "100 * (OP_RETIRED / (CPU_CYCLES * #slots))",
         "BriefDescription": "Fraction of slots retiring, useful work",
+        "DefaultMetricgroupName": "TopdownL1",
         "MetricGroup": "Default;TopdownL1",
 	"ScaleUnit": "1percent of slots"
     },
-- 
2.43.0.rc2.451.g8631bc7472-goog



From jgg at nvidia.com  Mon Dec  4 10:23:30 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Mon, 4 Dec 2023 14:23:30 -0400
Subject: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64
In-Reply-To: <ZW4NAzI_jvwoq8dL@arm.com>
References: <cover.1700766072.git.leon@kernel.org>
 <c3ae87aea7660c3d266905c19d10d8de0f9fb779.1700766072.git.leon@kernel.org>
 <ZWB373y5XuZDultf@FVFF77S0Q05N>
 <20231124122352.GB436702@nvidia.com>
 <ZWSOwT2OyMXD1lmo@arm.com>
 <20231127134505.GI436702@nvidia.com>
 <ZW4NAzI_jvwoq8dL@arm.com>
Message-ID: <20231204182330.GK1493156@nvidia.com>

On Mon, Dec 04, 2023 at 05:31:47PM +0000, Catalin Marinas wrote:
> On Mon, Nov 27, 2023 at 09:45:05AM -0400, Jason Gunthorpe wrote:
> > On Mon, Nov 27, 2023 at 12:42:41PM +0000, Catalin Marinas wrote:
> > > > > What's the actual requirement here? Is this just for performance?
> > > > 
> > > > Yes, just performance.
> > > 
> > > Do you have any rough numbers (percentage)? It's highly
> > > microarchitecture-dependent until we get the ST64B instruction.
> > 
> > The current C code is an open coded store loop. The kernel does 250
> > tries and measures if any one of them succeeds to combine.
> > 
> > On x86, and older ARM cores we see that 100% of the time at least 1 in
> > 250 tries succeeds.
> > 
> > With the new CPU cores we see more like 9 out of 10 time there are 0
> > in 250 tries that succeed. Ie we can go thousands of times without
> > seeing any successful WC combine.
> > 
> > The STP block brings it back to 100% of the time 1 in 250 succeed.
> 
> That's a bit confusing to me: 1 in 250 succeeding is still pretty rare.
> But I guess what your benchmark says is that at least 1 succeeded to
> write-combine and it might as well be all 250 tries. It's more
> interesting to see if there's actual performance gain in real-world
> traffic, not just some artificial benchmark (I may have misunderstood
> your numbers above).

Yes, I just don't have better data available to say that 250/250
succeeded, but we expect that is the case.

We have now something like 20 years experiance with write combining
performance on x86 systems. It brings real world gains in real word
HPC applications.

Indeed, the reason this even came up was because one of our existing
applications was performing unexpectedly badly on these ARM64 servers.

We even have data showing that having the CPU do all the write
combining steps and then fail to get writecombining is notably slower
than just assuming no write combining. It is why we go through the
trouble to test the physical HW.

> > However, in userspace we have long been using ST4 to create a
> > single-instruction 64 byte store on ARM64. As far as I know this is
> > highly reliable. I don't have direct data on the STP configuration.
> 
> Personally I'd optimise the mempcy_toio() arm64 implementation to do
> STPs if the alignment is right (like we do for classic memcpy()).
> There's a slight overhead for alignment checking but I suspect it would
> be lost as long as you can get the write-combining. Not sure whether the
> interspersed reads in memcpy_toio() would somehow prevent the
> write-combining.

I understand on these new CPUs anything other than a block of
contiguous STPs is risky to break the WC. I was told we should not
have any loads between them.

So we can't just update memcpy_toio to optimize a 128 bit store
variant like memcpy might. We actually need a special case just for 64
byte.

IMHO it does not look good as the chance any existing callers can use
this optmized 64B path is probably small, but everyone has to pay the
costs to check for it.

I also would not do this on x86 - Pathscale apparently decided the
needed special __iowrite*_copy() things to actually make this work on
xome x86 systems - I'm very leary to change x86 stuff away from the 64
bit copy loopw we know works already on x86.

IMHO encoding the alignment expectation in the API is best, especially
since this is typically a performance path.

> A memcpy_toio_64() can use the new ST64B instruction if available or
> fall back to memcpy_toio() on arm64. It should also have the DGH
> instruction (io_stop_wc()) but only if falling back to classic
> memcpy_toio(). We don't need DGH with ST64B.

I'm told it is problematic, something about ST64B not working with
NORMAL_NC.

We could fold the DGH into the helper though. IHMO I'd like to see how
ST64B actually gets implemented before doing that. If the note about
the NORMAL_NC is true then we need a lot more infrastructure to
actually use it.

Also in a future ST64B world we are going to see HW start relying on
large TLPs, not just being an optional performance win. To my mind it
makes more sense that there is an API that guarantees a large TLP or
oops. We really don't want an automatic fallback to memcpy.

Jason


From afd at ti.com  Mon Dec  4 10:22:45 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:45 -0600
Subject: [PATCH RFC 10/10] MIPS: DTS: jz4780: Add device tree entry for SGX GPU
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-11-afd@ti.com>

Add SGX GPU device entry to base jz4780 dtsi file.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 18affff85ce38..5ea6833f5e872 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -460,6 +460,17 @@ hdmi: hdmi at 10180000 {
 		status = "disabled";
 	};
 
+	gpu: gpu at 13040000 {
+		compatible = "ingenic,jz4780-gpu", "img,powervr-sgx540";
+		reg = <0x13040000 0x4000>;
+
+		clocks = <&cgu JZ4780_CLK_GPU>;
+		clock-names = "core";
+
+		interrupt-parent = <&intc>;
+		interrupts = <63>;
+	};
+
 	lcdc0: lcdc0 at 13050000 {
 		compatible = "ingenic,jz4780-lcd";
 		reg = <0x13050000 0x1800>;
-- 
2.39.2



From afd at ti.com  Mon Dec  4 10:22:41 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 4 Dec 2023 12:22:41 -0600
Subject: [PATCH RFC 06/10] ARM: dts: AM437x: Add device tree entry for SGX GPU
In-Reply-To: <20231204182245.33683-1-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
Message-ID: <20231204182245.33683-7-afd@ti.com>

Add SGX GPU device entry to base AM437x dtsi file.

Signed-off-by: Andrew Davis <afd at ti.com>
---
 arch/arm/boot/dts/ti/omap/am4372.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/ti/omap/am4372.dtsi b/arch/arm/boot/dts/ti/omap/am4372.dtsi
index 9d2c064534f7d..5fd1b380ece62 100644
--- a/arch/arm/boot/dts/ti/omap/am4372.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am4372.dtsi
@@ -719,6 +719,12 @@ target-module at 56000000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges = <0 0x56000000 0x1000000>;
+
+			gpu at 0 {
+				compatible = "ti,omap3630-gpu", "img,powervr-sgx530";
+				reg = <0x0 0x10000>; /* 64kB */
+				interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+			};
 		};
 	};
 };
-- 
2.39.2



From linux at armlinux.org.uk  Mon Dec  4 10:26:15 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Mon, 4 Dec 2023 18:26:15 +0000
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error:
 instruction variant requires ARMv6 or later
In-Reply-To: <20231204181304.GA2043538@dev-arch.thelio-3990X>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
 <20231204181304.GA2043538@dev-arch.thelio-3990X>
Message-ID: <ZW4Zx4olPp0Owz0a@shell.armlinux.org.uk>

On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote:
> Hi Naresh,
> 
> On Mon, Dec 04, 2023 at 05:33:26PM +0530, Naresh Kamboju wrote:
> > Following build errors noticed on Linux next-20231204 tag with clang-nightly
> > for arm and arm64.
> > 
> > ## Test Regressions (compared to next-20231201)
> > * arm64, build
> >   - clang-nightly-defconfig
> >   - clang-nightly-defconfig-40bc7ee5
> >   - clang-nightly-lkftconfig
> >   - clang-nightly-lkftconfig-kselftest
> > 
> > * arm, build
> >   - clang-nightly-allnoconfig
> >   - clang-nightly-axm55xx_defconfig
> >   - clang-nightly-bcm2835_defconfig
> >   - clang-nightly-clps711x_defconfig
> >   - clang-nightly-defconfig
> >   - clang-nightly-exynos_defconfig
> >   - clang-nightly-imx_v6_v7_defconfig
> >   - clang-nightly-keystone_defconfig
> >   - clang-nightly-lkftconfig
> >   - clang-nightly-lkftconfig-kselftest
> >   - clang-nightly-omap2plus_defconfig
> >   - clang-nightly-pxa910_defconfig
> >   - clang-nightly-s3c6400_defconfig
> >   - clang-nightly-s5pv210_defconfig
> >   - clang-nightly-sama5_defconfig
> >   - clang-nightly-shmobile_defconfig
> >   - clang-nightly-tinyconfig
> >   - clang-nightly-u8500_defconfig
> >   - clang-nightly-vexpress_defconfig
> > 
> > 
> > Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
> > 
> > 
> > Build log on arm64:
> > ---------
> > In file included from lib/vdso/gettimeofday.c:5:
> > In file included from include/vdso/datapage.h:135:
> > arch/arm64/include/asm/vdso/compat_gettimeofday.h:152:15: error:
> > instruction variant requires ARMv6 or later
> >   152 |         asm volatile("mov %0, %1" : "=r"(ret) : "r"(_vdso_data));
> >       |                      ^
> > <inline asm>:1:2: note: instantiated into assembly here
> >     1 |         mov r4, r1
> >       |         ^

I have to wonder why Clang is complaining about "mov r4, r1" because
that certainly should not require "ARMv6 or later". On the face of it,
this to me looks like a bug in Clang.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From maz at kernel.org  Mon Dec  4 10:26:25 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 04 Dec 2023 18:26:25 +0000
Subject: [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy
In-Reply-To: <ZW3l6Bq7ortEGB8I@FVFF77S0Q05N>
References: <20231204143606.1806432-1-maz@kernel.org>
	<ZW3l6Bq7ortEGB8I@FVFF77S0Q05N>
Message-ID: <86h6kxbz8u.wl-maz@kernel.org>

On Mon, 04 Dec 2023 14:44:56 +0000,
Mark Rutland <mark.rutland at arm.com> wrote:
> 
> On Mon, Dec 04, 2023 at 02:36:03PM +0000, Marc Zyngier wrote:
> > ARMv8.2 introduced support for VPIPT i-caches, the V standing for
> > VMID-tagged. Although this looked like a reasonable idea, no
> > implementation has ever made it into the wild.
> > 
> > Linux has supported this for over 6 years (amusingly, just as the
> > architecture was dropping support for AIVIVT i-caches), but we had no
> > way to even test it, and it is likely that this code was just
> > bit-rotting.
> > 
> > However, in a recent breakthrough (XML drop 2023-09, tagged as
> > d55f5af8e09052abe92a02adf820deea2eaed717), the architecture has
> > finally been purged of this option, making VIPT and PIPT the only two
> > valid options.
> > 
> > This really means this code is just dead code. Nobody will ever come
> > up with such an implementation, and we can just get rid of it.
> > 
> > Most of the impact is on KVM, where we drop a few large comment blocks
> > (and a bit of code), while the core arch code loses the detection code
> > itself.
> > 
> > * From v2:
> >   - Fix reserved naming for RESERVED_AIVIVT
> >   - Collected RBs from Anshuman an Zenghui
> > 
> > Marc Zyngier (3):
> >   KVM: arm64: Remove VPIPT I-cache handling
> >   arm64: Kill detection of VPIPT i-cache policy
> >   arm64: Rename reserved values for CTR_EL0.L1Ip
> 
> For the series:
> 
> Acked-by: Mark Rutland <mark.rutland at arm.com>

Thanks.

> Looking forward, we can/should probably replace __icache_flags with a single
> ICACHE_NOALIASING or ICACHE_PIPT cpucap, which'd get rid of a bunch of
> duplicated logic and make that more sound in the case of races around cpu
> onlining.

As long as we refuse VIPT CPUs coming up late (i.e. after we have
patched the kernel to set ICACHE_PIPT), it should be doable. I guess
we already have this restriction as userspace is able to probe the
I-cache policy anyway.

How about the patch below (tested in a guest with a bunch of hacks to
expose different L1Ip values)?

Thanks,

	M.

From 8f88afb0b317213dcbf18ea460a508bfccc18568 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <maz at kernel.org>
Date: Mon, 4 Dec 2023 18:09:40 +0000
Subject: [PATCH] arm64: Make icache detection a cpu capability

Now that we only have two icache policies, we are in a good position
to make the whole detection business more robust.

Let's replace __icache_flags by a single capability (ICACHE_PIPT),
and use this if all CPUs are indeed PIPT. It means we can rely on
existing logic to mandate that a VIPT CPU coming up late will be
denied booting, which is the safe thing to do.

This also leads to some nice cleanups in pKVM, and KVM as a whole
can use ARM64_ICACHE_PIPT as a final cap.

Suggested-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/include/asm/cache.h   |  9 ++-------
 arch/arm64/include/asm/kvm_hyp.h |  1 -
 arch/arm64/include/asm/kvm_mmu.h |  2 +-
 arch/arm64/kernel/cpufeature.c   |  7 +++++++
 arch/arm64/kernel/cpuinfo.c      | 34 --------------------------------
 arch/arm64/kvm/arm.c             |  1 -
 arch/arm64/kvm/hyp/nvhe/pkvm.c   |  3 ---
 arch/arm64/tools/cpucaps         |  1 +
 arch/arm64/tools/sysreg          |  2 +-
 9 files changed, 12 insertions(+), 48 deletions(-)

diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 06a4670bdb0b..8ef9522a6151 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -37,9 +37,9 @@
 
 #ifndef __ASSEMBLY__
 
-#include <linux/bitops.h>
 #include <linux/kasan-enabled.h>
 
+#include <asm/cpufeature.h>
 #include <asm/cputype.h>
 #include <asm/mte-def.h>
 #include <asm/sysreg.h>
@@ -55,18 +55,13 @@ static inline unsigned int arch_slab_minalign(void)
 #define arch_slab_minalign() arch_slab_minalign()
 #endif
 
-#define CTR_L1IP(ctr)		SYS_FIELD_GET(CTR_EL0, L1Ip, ctr)
-
-#define ICACHEF_ALIASING	0
-extern unsigned long __icache_flags;
-
 /*
  * Whilst the D-side always behaves as PIPT on AArch64, aliasing is
  * permitted in the I-cache.
  */
 static inline int icache_is_aliasing(void)
 {
-	return test_bit(ICACHEF_ALIASING, &__icache_flags);
+	return !cpus_have_cap(ARM64_ICACHE_PIPT);
 }
 
 static inline u32 cache_type_cwg(void)
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 145ce73fc16c..7ad70f9865fd 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -140,7 +140,6 @@ extern u64 kvm_nvhe_sym(id_aa64mmfr1_el1_sys_val);
 extern u64 kvm_nvhe_sym(id_aa64mmfr2_el1_sys_val);
 extern u64 kvm_nvhe_sym(id_aa64smfr0_el1_sys_val);
 
-extern unsigned long kvm_nvhe_sym(__icache_flags);
 extern unsigned int kvm_nvhe_sym(kvm_arm_vmid_bits);
 
 #endif /* __ARM64_KVM_HYP_H__ */
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index e3e793d0ec30..ab86c2f025cf 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -248,7 +248,7 @@ static inline void __invalidate_icache_guest_page(void *va, size_t size)
 	 * invalidation range exceeds our arbitrary limit on invadations by
 	 * cache line.
 	 */
-	if (icache_is_aliasing() || size > __invalidate_icache_max_range())
+	if (!cpus_have_final_cap(ARM64_ICACHE_PIPT) || size > __invalidate_icache_max_range())
 		icache_inval_all_pou();
 	else
 		icache_inval_pou((unsigned long)va, (unsigned long)va + size);
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 646591c67e7a..73a37176676e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2272,6 +2272,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
 		.matches = has_always,
 	},
+	{
+		.desc = "PIPT I-cache policy",
+		.capability = ARM64_ICACHE_PIPT,
+		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+		.matches = has_cpuid_feature,
+		ARM64_CPUID_FIELDS(CTR_EL0, L1Ip, PIPT)
+	},
 	{
 		.desc = "GIC system register CPU interface",
 		.capability = ARM64_HAS_GIC_CPUIF_SYSREGS,
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 47043c0d95ec..a4ea331fb6d4 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -33,20 +33,6 @@
 DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
 static struct cpuinfo_arm64 boot_cpu_data;
 
-static inline const char *icache_policy_str(int l1ip)
-{
-	switch (l1ip) {
-	case CTR_EL0_L1Ip_VIPT:
-		return "VIPT";
-	case CTR_EL0_L1Ip_PIPT:
-		return "PIPT";
-	default:
-		return "RESERVED/UNKNOWN";
-	}
-}
-
-unsigned long __icache_flags;
-
 static const char *const hwcap_str[] = {
 	[KERNEL_HWCAP_FP]		= "fp",
 	[KERNEL_HWCAP_ASIMD]		= "asimd",
@@ -378,24 +364,6 @@ static int __init cpuinfo_regs_init(void)
 }
 device_initcall(cpuinfo_regs_init);
 
-static void cpuinfo_detect_icache_policy(struct cpuinfo_arm64 *info)
-{
-	unsigned int cpu = smp_processor_id();
-	u32 l1ip = CTR_L1IP(info->reg_ctr);
-
-	switch (l1ip) {
-	case CTR_EL0_L1Ip_PIPT:
-		break;
-	case CTR_EL0_L1Ip_VIPT:
-	default:
-		/* Assume aliasing */
-		set_bit(ICACHEF_ALIASING, &__icache_flags);
-		break;
-	}
-
-	pr_info("Detected %s I-cache on CPU%d\n", icache_policy_str(l1ip), cpu);
-}
-
 static void __cpuinfo_store_cpu_32bit(struct cpuinfo_32bit *info)
 {
 	info->reg_id_dfr0 = read_cpuid(ID_DFR0_EL1);
@@ -457,8 +425,6 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
 
 	if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0))
 		__cpuinfo_store_cpu_32bit(&info->aarch32);
-
-	cpuinfo_detect_icache_policy(info);
 }
 
 void cpuinfo_store_cpu(void)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index e5f75f1f1085..a5f71165cd5c 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -2242,7 +2242,6 @@ static void kvm_hyp_init_symbols(void)
 	kvm_nvhe_sym(id_aa64mmfr1_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1);
 	kvm_nvhe_sym(id_aa64mmfr2_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64MMFR2_EL1);
 	kvm_nvhe_sym(id_aa64smfr0_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64SMFR0_EL1);
-	kvm_nvhe_sym(__icache_flags) = __icache_flags;
 	kvm_nvhe_sym(kvm_arm_vmid_bits) = kvm_arm_vmid_bits;
 }
 
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index b29f15418c0a..187ce5720697 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -12,9 +12,6 @@
 #include <nvhe/pkvm.h>
 #include <nvhe/trap_handler.h>
 
-/* Used by icache_is_aliasing(). */
-unsigned long __icache_flags;
-
 /* Used by kvm_get_vttbr(). */
 unsigned int kvm_arm_vmid_bits;
 
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index b98c38288a9d..9c6313cd6f5e 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -53,6 +53,7 @@ HAS_TLB_RANGE
 HAS_VIRT_HOST_EXTN
 HAS_WFXT
 HW_DBM
+ICACHE_PIPT
 KVM_HVHE
 KVM_PROTECTED_MODE
 MISMATCHED_CACHE_TYPE
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index c5af75b23187..db8c96841138 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2003,7 +2003,7 @@ Field	28	IDC
 Field	27:24	CWG
 Field	23:20	ERG
 Field	19:16	DminLine
-Enum	15:14	L1Ip
+UnsignedEnum	15:14	L1Ip
 	# This was named as VPIPT in the ARM but now documented as reserved
 	0b00	RESERVED_VPIPT
 	# This is named as AIVIVT in the ARM but documented as reserved
-- 
2.39.2


-- 
Without deviation from the norm, progress is not possible.


From u.kleine-koenig at pengutronix.de  Mon Dec  4 10:30:46 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Mon,  4 Dec 2023 19:30:46 +0100
Subject: [PATCH net-next v2 6/9] net: wan/ixp4xx_hss: Convert to platform remove callback returning void
In-Reply-To: <cover.1701713943.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701713943.git.u.kleine-koenig@pengutronix.de>
Message-ID: <b0488fa6181a47668e5737905ae7adc8d7cd055e.1701713943.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Link: https://lore.kernel.org/r/20231117095922.876489-8-u.kleine-koenig at pengutronix.de
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/net/wan/ixp4xx_hss.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c
index b09f4c235142..931c5ca79ea5 100644
--- a/drivers/net/wan/ixp4xx_hss.c
+++ b/drivers/net/wan/ixp4xx_hss.c
@@ -1522,20 +1522,19 @@ static int ixp4xx_hss_probe(struct platform_device *pdev)
 	return err;
 }
 
-static int ixp4xx_hss_remove(struct platform_device *pdev)
+static void ixp4xx_hss_remove(struct platform_device *pdev)
 {
 	struct port *port = platform_get_drvdata(pdev);
 
 	unregister_hdlc_device(port->netdev);
 	free_netdev(port->netdev);
 	npe_release(port->npe);
-	return 0;
 }
 
 static struct platform_driver ixp4xx_hss_driver = {
 	.driver.name	= DRV_NAME,
 	.probe		= ixp4xx_hss_probe,
-	.remove		= ixp4xx_hss_remove,
+	.remove_new	= ixp4xx_hss_remove,
 };
 module_platform_driver(ixp4xx_hss_driver);
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Mon Dec  4 10:30:40 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Mon,  4 Dec 2023 19:30:40 +0100
Subject: [PATCH net-next v2 0/9] net*: Convert to platform remove callback returning void
Message-ID: <cover.1701713943.git.u.kleine-koenig@pengutronix.de>

Hello,

(implicit) v1 of this series can be found at
https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koenig at pengutronix.de.
Changes since then:

 - Dropped patch #1 as Alex objected. Patch #1 (was #2 before) now
   converts ipa to remove_new() and introduces an error message in the
   error path that failed before.

 - Rebased to today's next

 - Add the tags received in the previous round.

Uwe Kleine-K?nig (9):
  net: ipa: Convert to platform remove callback returning void
  net: fjes: Convert to platform remove callback returning void
  net: pcs: rzn1-miic: Convert to platform remove callback returning
    void
  net: sfp: Convert to platform remove callback returning void
  net: wan/fsl_ucc_hdlc: Convert to platform remove callback returning
    void
  net: wan/ixp4xx_hss: Convert to platform remove callback returning
    void
  net: wwan: qcom_bam_dmux: Convert to platform remove callback
    returning void
  ieee802154: fakelb: Convert to platform remove callback returning void
  ieee802154: hwsim: Convert to platform remove callback returning void

 drivers/net/fjes/fjes_main.c             |  6 ++---
 drivers/net/ieee802154/fakelb.c          |  5 ++--
 drivers/net/ieee802154/mac802154_hwsim.c |  6 ++---
 drivers/net/ipa/ipa_main.c               | 29 +++++++++++-------------
 drivers/net/pcs/pcs-rzn1-miic.c          |  6 ++---
 drivers/net/phy/sfp.c                    |  6 ++---
 drivers/net/wan/fsl_ucc_hdlc.c           |  6 ++---
 drivers/net/wan/ixp4xx_hss.c             |  5 ++--
 drivers/net/wwan/qcom_bam_dmux.c         |  6 ++---
 9 files changed, 29 insertions(+), 46 deletions(-)


base-commit: 629a3b49f3f957e975253c54846090b8d5ed2e9b
-- 
2.42.0



From francesco at dolcini.it  Mon Dec  4 10:36:40 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Mon, 4 Dec 2023 19:36:40 +0100
Subject: [PATCH v2 3/3] arm64: dts: ti: add verdin am62 mallow board
In-Reply-To: <20231204181336.scm2fgfyyzpr2u7t@dimmer>
References: <20231201145551.23337-1-francesco@dolcini.it>
 <20231201145551.23337-4-francesco@dolcini.it>
 <20231204181336.scm2fgfyyzpr2u7t@dimmer>
Message-ID: <ZW4cONRWiRoOiaVd@francesco-nb.int.toradex.com>

Hello Nishanth,

On Mon, Dec 04, 2023 at 12:13:36PM -0600, Nishanth Menon wrote:
> On 15:55-20231201, Francesco Dolcini wrote:
> > From: Joao Paulo Goncalves <joao.goncalves at toradex.com>
> 
> [...]
> 
> > +
> > +	tpm at 1 {
> > +		compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
> 
> arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dtb: /bus at f0000/spi at 20110000/tpm at 1: failed to match any schema with compatible: ['infineon,slb9670', 'tcg,tpm_tis-spi']
> arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dtb: /bus at f0000/spi at 20110000/tpm at 1: failed to match any schema with compatible: ['infineon,slb9670', 'tcg,tpm_tis-spi']
> 
> We should either drop this node OR introduce bindings and later
> introduce this series.
> 
> Yes, I know there are other places where the compatible is already used
> arch/arm64/boot/dts/freescale/imx8mm-phyboard-polis-rdk.dts
> arch/arm64/boot/dts/xilinx/zynqmp-sm-k26-revA.dts1G
> etc.. But, unfortunately, I'd rather see the binding
> Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt
> transition over to yaml prior to picking things up. (NOTE: the same
> rules apply to TI devs as well..)

I disagree (and I also know that in the end is your call to take patches
or not and I will just accept your decision whatever it is).

What you are asking here is to not use any binding that was not already
converted from txt to yaml, I do not think it is fair to force this
decision just for TI DT files.

I'd like also to add that a conversion to yaml of this binding is in the
work [1] and this DT is compliant with it.

What's DT maintainers opinion on this matter? Rob recently provided
feedback on TPM bindings txt to yaml conversion so it should be fresh on
his mind.

Francesco

[1] https://lore.kernel.org/all/cover.1701093036.git.lukas at wunner.de/


From lkp at intel.com  Mon Dec  4 10:37:08 2023
From: lkp at intel.com (kernel test robot)
Date: Tue, 5 Dec 2023 02:37:08 +0800
Subject: [PATCH v2] coresight: Make current W=1 warnings default
In-Reply-To: <20231115162834.355598-1-james.clark@arm.com>
References: <20231115162834.355598-1-james.clark@arm.com>
Message-ID: <202312050158.FKpxuafP-lkp@intel.com>

Hi James,

kernel test robot noticed the following build warnings:

[auto build test WARNING on atorgue-stm32/stm32-next]
[also build test WARNING on linus/master v6.7-rc4 next-20231204]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/James-Clark/coresight-Make-current-W-1-warnings-default/20231116-004818
base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
patch link:    https://lore.kernel.org/r/20231115162834.355598-1-james.clark%40arm.com
patch subject: [PATCH v2] coresight: Make current W=1 warnings default
config: arm-randconfig-r131-20231117 (https://download.01.org/0day-ci/archive/20231205/202312050158.FKpxuafP-lkp at intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231205/202312050158.FKpxuafP-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312050158.FKpxuafP-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/hwtracing/coresight/coresight-etb10.c:840:17: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-etb10.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
--
>> drivers/hwtracing/coresight/coresight-funnel.c:395:17: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-funnel.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/slab.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
--
>> drivers/hwtracing/coresight/coresight-tpdm.c:242:17: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-tpdm.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false

vim +840 drivers/hwtracing/coresight/coresight-etb10.c

   834	
   835	static const struct amba_id etb_ids[] = {
   836		{
   837			.id	= 0x000bb907,
   838			.mask	= 0x000fffff,
   839		},
 > 840		{ 0, 0, 0 },
   841	};
   842	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From catalin.marinas at arm.com  Mon Dec  4 10:40:25 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 4 Dec 2023 18:40:25 +0000
Subject: [PATCH v3 01/25] arm64/sysreg: add system register POR_EL{0,1}
In-Reply-To: <20231124163510.1835740-2-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-2-joey.gouly@arm.com>
Message-ID: <ZW4dGfKnwNifyNIx@arm.com>

On Fri, Nov 24, 2023 at 04:34:46PM +0000, Joey Gouly wrote:
> Add POR_EL{0,1} according to DDI0601 2023-03.
> 
> Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Reviewed-by: Mark Brown <broonie at kernel.org>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From catalin.marinas at arm.com  Mon Dec  4 10:41:54 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 4 Dec 2023 18:41:54 +0000
Subject: [PATCH v3 02/25] arm64/sysreg: update CPACR_EL1 register
In-Reply-To: <20231124163510.1835740-3-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-3-joey.gouly@arm.com>
Message-ID: <ZW4dctSY-gCM-SmR@arm.com>

On Fri, Nov 24, 2023 at 04:34:47PM +0000, Joey Gouly wrote:
> Add E0POE bit that traps accesses to POR_EL0 from EL0.

Nitpick: s/traps/enables/

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From catalin.marinas at arm.com  Mon Dec  4 10:46:40 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 4 Dec 2023 18:46:40 +0000
Subject: [PATCH v3 03/25] arm64: cpufeature: add Permission Overlay
 Extension cpucap
In-Reply-To: <20231124163510.1835740-4-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-4-joey.gouly@arm.com>
Message-ID: <ZW4ekJ8pxwWTmVFC@arm.com>

On Fri, Nov 24, 2023 at 04:34:48PM +0000, Joey Gouly wrote:
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2078,6 +2078,22 @@ config ARM64_EPAN
>  	  if the cpu does not implement the feature.
>  endmenu # "ARMv8.7 architectural features"
>  
> +menu "ARMv8.9 architectural features"
> +config ARM64_POE
> +	prompt "Permission Overlay Extension"
> +	def_bool y
> +	help
> +	  The Permission Overlay Extension is used to implement Memory
> +	  Protection Keys. Memory Protection Keys provides a mechanism for
> +	  enforcing page-based protections, but without requiring modification
> +	  of the page tables when an application changes protection domains.
> +
> +	  For details, see Documentation/core-api/protection-keys.rst
> +
> +	  If unsure, say y.
> +
> +endmenu # "ARMv8.9 architectural features"

I agree with Mark, we typically leave the Kconfig option towards the end
of the series.

> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 646591c67e7a..00b6d516ed3f 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -2731,6 +2731,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.matches = has_cpuid_feature,
>  		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP)
>  	},
> +#ifdef CONFIG_ARM64_POE
> +	{
> +		.desc = "Stage-1 Permission Overlay Extension (S1POE)",
> +		.capability = ARM64_HAS_S1POE,
> +		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,
> +		.matches = has_cpuid_feature,
> +		ARM64_CPUID_FIELDS(ID_AA64MMFR3_EL1, S1POE, IMP)
> +	},
> +#endif

Keeping the #ifdef here is ok, it won't be defined at this point.

-- 
Catalin


From cl at linux.com  Mon Dec  4 10:49:24 2023
From: cl at linux.com (Christoph Lameter (Ampere))
Date: Mon, 4 Dec 2023 10:49:24 -0800 (PST)
Subject: [PATCH] ARM64: Dynamicaly allocate cpumasks and increase supported
 CPUs to 512 (was: CONFIG_MAXSMP to allow up to 512 cpus)
In-Reply-To: <01d7531b-3d5c-989d-58ac-60861249fd3e@linux.com>
References: <6a854175-5f89-c754-17b8-deda18447f1f@gentwo.org> <52b8a7d8-aa4c-46db-a7f5-f36c92ad5380@arm.com> <01d7531b-3d5c-989d-58ac-60861249fd3e@linux.com>
Message-ID: <8c21b27a-fbab-890d-40d2-ba460b0e3900@linux.com>

New version of the patch after feedback from Catalin:


From: Christoph Lameter (Ampere) <cl at linux.com>
Subject: [PATCH] ARM64: Dynamicaly allocate cpumasks and increase supported CPUs to 512

Ampere Computing develops high end ARM processor that support an ever
increasing number of processors. The default 256 processors are
not enough for our newer products. The default is used by
distros and therefore our customers cannot use distro kernels because
the number of processors is not supported.

One of the objections against earlier patches to increase the limit
was that the memory use becomes too high. There is a feature called
CPUMASK_OFFSTACK that configures the cpumasks in the kernel to be
dynamically allocated. This was used in the X86 architecture in the
past to enable support for larger CPU configurations up to 8k cpus.

With that is becomes possible to dynamically size the allocation of
the cpu bitmaps depending on the quantity of processors detected on
bootup.

This patch enables that logic if more than 256 processors
are configured and increases the default to 512 processors.

Further increases may be needed if ARM processor vendors start
supporting more processors. Given the current inflationary trends
in core counts from multiple processor manufacturers this may occur.

Signed-off-by: Christoph Lameter (Ampere) <cl at linux.com>

Index: linux/arch/arm64/Kconfig
===================================================================
--- linux.orig/arch/arm64/Kconfig
+++ linux/arch/arm64/Kconfig
@@ -1407,7 +1407,21 @@ config SCHED_SMT
  config NR_CPUS
  	int "Maximum number of CPUs (2-4096)"
  	range 2 4096
-	default "256"
+	default 512
+
+#
+# Determines the placement of cpumasks.
+#
+# With CPUMASK_OFFSTACK the cpumasks are dynamically allocated.
+# Useful for machines with lots of core because it avoids increasing
+# the size of many of the data structures in the kernel.
+#
+# If this is off then the cpumasks have a static sizes and are
+# embedded within data structures.
+#
+config CPUMASK_OFFSTACK
+	def_bool y
+	depends on NR_CPUS > 256

  config HOTPLUG_CPU
  	bool "Support for hot-pluggable CPUs"


From quic_obabatun at quicinc.com  Mon Dec  4 10:54:56 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Mon, 4 Dec 2023 10:54:56 -0800
Subject: [RFC PATCH v2 0/6] Dynamic allocation of reserved_mem array.
In-Reply-To: <20231204041339.9902-1-quic_obabatun@quicinc.com>
References: <20231204041339.9902-1-quic_obabatun@quicinc.com>
Message-ID: <6602b327-f0a6-4eb5-860f-bf91cbfdff41@quicinc.com>


On 12/3/2023 8:13 PM, Oreoluwa Babatunde wrote:
> The reserved_mem array is used to store the data of the different
> reserved memory regions specified in the DT of a device.
> The array stores information such as the name, node, starting address,
> and size of a reserved memory region.
>
> The array is currently statically allocated with a size of
> MAX_RESERVED_REGIONS(64). This means that any system that specifies a
> number of reserved memory regions greater than MAX_RESERVED_REGIONS(64)
> will not have enough space to store the information for all the regions.
>
> Therefore, this series extends the use of a static array for
> reserved_mem, and introduces a dynamically allocated array using
> memblock_alloc() based on the number of reserved memory regions
> specified in the DT.
>
> Memory gotten from memblock_alloc() is only writable after paging_init()
> is called, but the reserved memory regions need to be reserved before
> then so that the system does not create page table mappings for them.
>
> Reserved memory regions can be divided into 2 groups.
> i) Statically-placed reserved memory regions
> i.e. regions defined in the DT using the @reg property.
> ii) Dynamically-placed reserved memory regions.
> i.e. regions specified in the DT using the @alloc_ranges
>     and @size properties.
>
> It is possible to call memblock_reserve() and memblock_mark_nomap() on
> the statically-placed reserved memory regions and not need to save them
> to the array until after paging_init(), but this is not possible for the
> dynamically-placed reserved memory because the starting address of these
> regions need to be stored somewhere after they are allocated.
>
> Therefore, this series achieves the allocation and population of the
> reserved_mem array in two steps:
>
> 1. Before paging_init()
>    Before paging_init() is called, iterate through the reserved_mem
>    nodes in the DT and do the following:
>    - Allocate memory for dynamically-placed reserved memory regions and
>      store their starting address in the static allocated reserved_mem
>      array.
>    - Call memblock_reserve() and memblock_mark_nomap() on all the
>      reserved memory regions as needed.
>    - Count the total number of reserved_mem nodes in the DT.
>
> 2. After paging_init()
>    After paging_init() is called:
>    - Allocate new memory for the reserved_mem array based on the number
>      of reserved memory nodes in the DT.
>    - Transfer all the information that was stored in the static array
>      into the new array.
>    - Store the rest of the reserved_mem regions in the new array.
>      i.e. the statically-placed regions.
>
> The static array is no longer needed after this point, but there is
> currently no obvious way to free the memory. Therefore, the size of the
> initial static array is now defined using a config option.
> Because the array is used only before paging_init() to store the
> dynamically-placed reserved memory regions, the required size can vary
> from device to device. Therefore, scaling it can help get some memory
> savings.
>
> A possible solution to freeing the memory for the static array will be
> to mark it as __initdata. This will automatically free the memory once
> the init process is done running.
> The reason why this is not pursued in this series is because of
> the possibility of a use-after-free.
> If the dynamic allocation of the reserved_mem array fails, then future
> accesses of the reserved_mem array will still be referencing the static
> array. When the init process ends and the memory is freed up, any
> further attempts to use the reserved_mem array will result in a
> use-after-free.
>
> Note:
>
> - The limitation to this approach is that there is still a limit of
>   64 for dynamically reserved memory regions.
> - Upon further review, the series might need to be split up/duplicated
>   for other archs.
>
>
> Oreoluwa Babatunde (6):
>   of: reserved_mem: Change the order that reserved_mem regions are
>     stored
>   of: reserved_mem: Swicth call to unflatten_device_tree() to after
>     paging_init()
>   of: resevred_mem: Delay allocation of memory for dynamic regions
>   of: reserved_mem: Add code to use unflattened DT for reserved_mem
>     nodes
>   of: reserved_mem: Add code to dynamically allocate reserved_mem array
>   of: reserved_mem: Make MAX_RESERVED_REGIONS a config option
>
>  arch/loongarch/kernel/setup.c      |   2 +-
>  arch/mips/kernel/setup.c           |   3 +-
>  arch/nios2/kernel/setup.c          |   4 +-
>  arch/openrisc/kernel/setup.c       |   4 +-
>  arch/powerpc/kernel/setup-common.c |   3 +
>  arch/sh/kernel/setup.c             |   5 +-
>  arch/um/kernel/dtb.c               |   1 -
>  arch/um/kernel/um_arch.c           |   2 +
>  arch/xtensa/kernel/setup.c         |   4 +-
>  drivers/of/Kconfig                 |  13 +++
>  drivers/of/fdt.c                   |  39 +++++--
>  drivers/of/of_private.h            |   6 +-
>  drivers/of/of_reserved_mem.c       | 175 +++++++++++++++++++++--------
>  include/linux/of_reserved_mem.h    |   8 +-
>  kernel/dma/coherent.c              |   4 +-
>  kernel/dma/contiguous.c            |   8 +-
>  kernel/dma/swiotlb.c               |  10 +-
>  17 files changed, 205 insertions(+), 86 deletions(-)
re-sending this to include maintainers for the other
archs.

Regards,

Oreoluwa



From quic_obabatun at quicinc.com  Mon Dec  4 10:54:08 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Mon, 4 Dec 2023 10:54:08 -0800
Subject: [RFC PATCH v2 5/6] of: reserved_mem: Add code to dynamically allocate reserved_mem array
In-Reply-To: <20231204185409.19615-1-quic_obabatun@quicinc.com>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
Message-ID: <20231204185409.19615-6-quic_obabatun@quicinc.com>

The reserved_mem array is statically allocated with a size of
MAX_RESERVED_REGIONS(64). Therefore, if the number of reserved_mem
regions exceeds this size, there will not be enough space to store
all the data.

Therefore, extend the use of the static array by introducing a
dynamically allocated array based on the number of reserved memory
regions specified in the DT.

Before paging_init() runs, the static array is used to store the
dynamically-placed regions.
After paging_init(), memory is dynamically allocated for the
reserved_mem array, and all entries from the static array is copied
over to the new array, and all other statically-placed regions are
added in as well.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/fdt.c             | 13 +++++++---
 drivers/of/of_private.h      |  1 +
 drivers/of/of_reserved_mem.c | 48 +++++++++++++++++++++++++++++++++---
 3 files changed, 55 insertions(+), 7 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 12769dd53c34..2f1eabbd6869 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -563,8 +563,8 @@ static int __init __reserved_mem_check_root(unsigned long node)
  */
 static int __init fdt_scan_reserved_mem(void)
 {
-	int node, child;
-	int dynamic_nodes_cnt = 0;
+	int node, child, err = 0;
+	int dynamic_nodes_cnt = 0, count = 0;
 	int dynamic_nodes[MAX_RESERVED_REGIONS];
 	const void *fdt = initial_boot_params;
 
@@ -579,7 +579,6 @@ static int __init fdt_scan_reserved_mem(void)
 
 	fdt_for_each_subnode(child, fdt, node) {
 		const char *uname;
-		int err;
 
 		if (!of_fdt_device_is_available(fdt, child))
 			continue;
@@ -587,6 +586,8 @@ static int __init fdt_scan_reserved_mem(void)
 		uname = fdt_get_name(fdt, child, NULL);
 
 		err = __reserved_mem_reserve_reg(child, uname);
+		if (!err)
+			count++;
 
 		if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL)) {
 			dynamic_nodes[dynamic_nodes_cnt] = child;
@@ -600,8 +601,12 @@ static int __init fdt_scan_reserved_mem(void)
 		child = dynamic_nodes[i];
 		uname = fdt_get_name(fdt, child, NULL);
 
-		__reserved_mem_alloc_size(child, uname);
+		err = __reserved_mem_alloc_size(child, uname);
+		if (!err)
+			count++;
 	}
+	update_reserved_mem_max_cnt(count);
+
 	return 0;
 }
 
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 575e2b4119e0..ef56b2ea185c 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -179,5 +179,6 @@ static inline struct device_node *__of_get_dma_parent(const struct device_node *
 void init_reserved_mem(void);
 void dt_reserved_mem_save_node(struct device_node *node, const char *uname,
 			       phys_addr_t base, phys_addr_t size);
+void update_reserved_mem_max_cnt(int max_count);
 
 #endif /* _LINUX_OF_PRIVATE_H */
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 2ef9edcb8c93..01cd6a571dc2 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -26,7 +26,9 @@
 
 #include "of_private.h"
 
-static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
+static struct reserved_mem reserved_mem_array[MAX_RESERVED_REGIONS];
+static struct reserved_mem *reserved_mem = reserved_mem_array;
+static int total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
 static int reserved_mem_count;
 
 static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
@@ -54,6 +56,42 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
 	return err;
 }
 
+void __init update_reserved_mem_max_cnt(int max_count)
+{
+	total_reserved_mem_cnt = max_count;
+}
+
+static int alloc_reserved_mem_array(void)
+{
+	struct reserved_mem *new_array;
+	size_t alloc_size, copy_size, memset_size;
+
+	alloc_size = array_size(total_reserved_mem_cnt, sizeof(*new_array));
+	if (alloc_size == SIZE_MAX)
+		return -1;
+
+	new_array = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
+	if (!new_array)
+		return -ENOMEM;
+
+	copy_size = array_size(reserved_mem_count, sizeof(*new_array));
+	if (copy_size == SIZE_MAX)
+		goto overlow_err;
+
+	memset_size = alloc_size - copy_size;
+
+	memcpy(new_array, reserved_mem, copy_size);
+	memset(new_array + reserved_mem_count, 0, memset_size);
+
+	reserved_mem = new_array;
+	return 0;
+
+overlow_err:
+	memblock_free(new_array, alloc_size);
+	total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
+	return -1;
+}
+
 /*
  * dt_reserved_mem_save_node() - save dt node for second pass initialization
  */
@@ -62,7 +100,7 @@ void __init dt_reserved_mem_save_node(struct device_node *node, const char *unam
 {
 	struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
 
-	if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
+	if (reserved_mem_count == total_reserved_mem_cnt) {
 		pr_err("not enough space for all defined regions.\n");
 		return;
 	}
@@ -346,7 +384,11 @@ static void __init __rmem_check_for_overlap(void)
  */
 void __init init_reserved_mem(void)
 {
-	int i;
+	int i, ret;
+
+	ret = alloc_reserved_mem_array();
+	if (ret)
+		pr_err("Failed to allocate memory for reserved_mem array with err: %d", ret);
 
 	scan_reserved_mem_reg_nodes();
 
-- 
2.17.1



From quic_obabatun at quicinc.com  Mon Dec  4 10:54:04 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Mon, 4 Dec 2023 10:54:04 -0800
Subject: [RFC PATCH v2 1/6] of: reserved_mem: Change the order that reserved_mem regions are stored
In-Reply-To: <20231204185409.19615-1-quic_obabatun@quicinc.com>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
Message-ID: <20231204185409.19615-2-quic_obabatun@quicinc.com>

The dynamic allocation of the reserved_mem array needs to be done after
paging_init() is called because memory allocated using memblock_alloc()
is not writeable before that.

Statically-placed reserved memory regions can wait until after
paging_init() to be stored in the array because the starting address and
size information is already specified in the DT.
Dynamically-placed regions on the other hand does not have its starting
address specified in the DT because it is allocated at runtime. Hence,
the starting address of these regions need to be stored somewhere.
The allocation of dynamically-placed regions cannot be done after
paging_init() either to avoid getting regions that are already added to
the page table mappings.

Hence, change the code to:
1. Before paging_init(), allocate and store information for the
   dynamically-placed reserved memory regions.
2. After paging_init(), store the information for the statically
   placed reserved memory regions in the array.

All the regions are also reserved or marked as nomap as needed before
paging_init().

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/fdt.c                | 63 ++++++++++++++++++++++++++++-----
 drivers/of/of_reserved_mem.c    | 53 ++++++++++++---------------
 include/linux/of_fdt.h          |  1 +
 include/linux/of_reserved_mem.h |  6 ++++
 4 files changed, 84 insertions(+), 39 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bf502ba8da95..34223c249914 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -504,7 +504,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
 	phys_addr_t base, size;
 	int len;
 	const __be32 *prop;
-	int first = 1;
 	bool nomap;
 
 	prop = of_get_flat_dt_prop(node, "reg", &len);
@@ -532,10 +531,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
 			       uname, &base, (unsigned long)(size / SZ_1M));
 
 		len -= t_len;
-		if (first) {
-			fdt_reserved_mem_save_node(node, uname, base, size);
-			first = 0;
-		}
 	}
 	return 0;
 }
@@ -564,7 +559,56 @@ static int __init __reserved_mem_check_root(unsigned long node)
 }
 
 /*
- * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory
+ * Save the reserved_mem reg nodes in the reserved_mem array
+ */
+void __init fdt_scan_reserved_mem_reg_nodes(void)
+
+{
+	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
+	const void *fdt = initial_boot_params;
+	phys_addr_t base, size;
+	const __be32 *prop;
+	int node, child;
+	int len;
+
+	node = fdt_path_offset(fdt, "/reserved-memory");
+	if (node < 0) {
+		pr_err("Reserved memory: Did not find reserved-memory node\n");
+		return;
+	}
+
+	if (__reserved_mem_check_root(node) != 0) {
+		pr_err("Reserved memory: unsupported node format, ignoring\n");
+		return;
+	}
+
+	fdt_for_each_subnode(child, fdt, node) {
+		const char *uname;
+
+		prop = of_get_flat_dt_prop(child, "reg", &len);
+		if (!prop)
+			continue;
+
+		if (!of_fdt_device_is_available(fdt, child))
+			continue;
+
+		uname = fdt_get_name(fdt, child, NULL);
+		if (len && len % t_len != 0) {
+			pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
+			       uname);
+			continue;
+		}
+
+		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+		size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+		if (size)
+			fdt_reserved_mem_save_node(child, uname, base, size);
+	}
+}
+
+/*
+ * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory.
  */
 static int __init fdt_scan_reserved_mem(void)
 {
@@ -591,7 +635,7 @@ static int __init fdt_scan_reserved_mem(void)
 
 		err = __reserved_mem_reserve_reg(child, uname);
 		if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL))
-			fdt_reserved_mem_save_node(child, uname, 0, 0);
+			__reserved_mem_alloc_size(child, uname);
 	}
 	return 0;
 }
@@ -645,8 +689,6 @@ void __init early_init_fdt_scan_reserved_mem(void)
 			break;
 		memblock_reserve(base, size);
 	}
-
-	fdt_init_reserved_mem();
 }
 
 /**
@@ -1335,6 +1377,9 @@ void __init unflatten_device_tree(void)
 	of_alias_scan(early_init_dt_alloc_memory_arch);
 
 	unittest_unflatten_overlay_base();
+
+	/*Initialize the reserved_mem regions*/
+	fdt_init_reserved_mem();
 }
 
 /**
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 7ec94cfcbddb..8bd8bbc3aaec 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -132,8 +132,7 @@ static int __init __reserved_mem_alloc_in_range(phys_addr_t size,
  * __reserved_mem_alloc_size() - allocate reserved memory described by
  *	'size', 'alignment'  and 'alloc-ranges' properties.
  */
-static int __init __reserved_mem_alloc_size(unsigned long node,
-	const char *uname, phys_addr_t *res_base, phys_addr_t *res_size)
+int __init __reserved_mem_alloc_size(unsigned long node, const char *uname)
 {
 	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
 	phys_addr_t start = 0, end = 0;
@@ -212,10 +211,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node,
 		       uname, (unsigned long)(size / SZ_1M));
 		return -ENOMEM;
 	}
-
-	*res_base = base;
-	*res_size = size;
-
+	fdt_reserved_mem_save_node(node, uname, base, size);
 	return 0;
 }
 
@@ -310,6 +306,8 @@ void __init fdt_init_reserved_mem(void)
 {
 	int i;
 
+	fdt_scan_reserved_mem_reg_nodes();
+
 	/* check for overlapping reserved regions */
 	__rmem_check_for_overlap();
 
@@ -328,30 +326,25 @@ void __init fdt_init_reserved_mem(void)
 		if (prop)
 			rmem->phandle = of_read_number(prop, len/4);
 
-		if (rmem->size == 0)
-			err = __reserved_mem_alloc_size(node, rmem->name,
-						 &rmem->base, &rmem->size);
-		if (err == 0) {
-			err = __reserved_mem_init_node(rmem);
-			if (err != 0 && err != -ENOENT) {
-				pr_info("node %s compatible matching fail\n",
-					rmem->name);
-				if (nomap)
-					memblock_clear_nomap(rmem->base, rmem->size);
-				else
-					memblock_phys_free(rmem->base,
-							   rmem->size);
-			} else {
-				phys_addr_t end = rmem->base + rmem->size - 1;
-				bool reusable =
-					(of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
-
-				pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
-					&rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
-					nomap ? "nomap" : "map",
-					reusable ? "reusable" : "non-reusable",
-					rmem->name ? rmem->name : "unknown");
-			}
+		err = __reserved_mem_init_node(rmem);
+		if (err != 0 && err != -ENOENT) {
+			pr_info("node %s compatible matching fail\n",
+				rmem->name);
+			if (nomap)
+				memblock_clear_nomap(rmem->base, rmem->size);
+			else
+				memblock_phys_free(rmem->base,
+						   rmem->size);
+		} else {
+			phys_addr_t end = rmem->base + rmem->size - 1;
+			bool reusable =
+				(of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
+
+			pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
+				&rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
+				nomap ? "nomap" : "map",
+				reusable ? "reusable" : "non-reusable",
+				rmem->name ? rmem->name : "unknown");
 		}
 	}
 }
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index d69ad5bb1eb1..7b2a5d93d719 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -73,6 +73,7 @@ extern int early_init_dt_scan_root(void);
 extern bool early_init_dt_scan(void *params);
 extern bool early_init_dt_verify(void *params);
 extern void early_init_dt_scan_nodes(void);
+extern void fdt_scan_reserved_mem_reg_nodes(void);
 
 extern const char *of_flat_dt_get_machine_name(void);
 extern const void *of_flat_dt_match_machine(const void *default_match,
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index 4de2a24cadc9..dc13bcd04b12 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -38,6 +38,7 @@ int of_reserved_mem_device_init_by_name(struct device *dev,
 					struct device_node *np,
 					const char *name);
 void of_reserved_mem_device_release(struct device *dev);
+int __reserved_mem_alloc_size(unsigned long node, const char *uname);
 
 struct reserved_mem *of_reserved_mem_lookup(struct device_node *np);
 #else
@@ -60,6 +61,11 @@ static inline int of_reserved_mem_device_init_by_name(struct device *dev,
 
 static inline void of_reserved_mem_device_release(struct device *pdev) { }
 
+static inline int __reserved_mem_alloc_size(unsigned long node, const char *uname)
+{
+	return -ENOSYS;
+}
+
 static inline struct reserved_mem *of_reserved_mem_lookup(struct device_node *np)
 {
 	return NULL;
-- 
2.17.1



From quic_obabatun at quicinc.com  Mon Dec  4 10:54:06 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Mon, 4 Dec 2023 10:54:06 -0800
Subject: [RFC PATCH v2 3/6] of: resevred_mem: Delay allocation of memory for dynamic regions
In-Reply-To: <20231204185409.19615-1-quic_obabatun@quicinc.com>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
Message-ID: <20231204185409.19615-4-quic_obabatun@quicinc.com>

Defer the allocation of memory for the dynamically-placed reserved
memory regions until after the statically-placed reserved memory
regions have been reserved or marked as nomap in memblock.
This is to avoid allocating from regions that will later turn out to
have been reserved by other nodes.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/fdt.c             | 18 ++++++++++++++++--
 drivers/of/of_private.h      |  1 +
 drivers/of/of_reserved_mem.c |  1 -
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 34223c249914..46adce306bbd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -613,6 +613,8 @@ void __init fdt_scan_reserved_mem_reg_nodes(void)
 static int __init fdt_scan_reserved_mem(void)
 {
 	int node, child;
+	int dynamic_nodes_cnt = 0;
+	int dynamic_nodes[MAX_RESERVED_REGIONS];
 	const void *fdt = initial_boot_params;
 
 	node = fdt_path_offset(fdt, "/reserved-memory");
@@ -634,8 +636,20 @@ static int __init fdt_scan_reserved_mem(void)
 		uname = fdt_get_name(fdt, child, NULL);
 
 		err = __reserved_mem_reserve_reg(child, uname);
-		if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL))
-			__reserved_mem_alloc_size(child, uname);
+
+		if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL)) {
+			dynamic_nodes[dynamic_nodes_cnt] = child;
+			dynamic_nodes_cnt++;
+		}
+	}
+
+	for (int i = 0; i < dynamic_nodes_cnt; i++) {
+		const char *uname;
+
+		child = dynamic_nodes[i];
+		uname = fdt_get_name(fdt, child, NULL);
+
+		__reserved_mem_alloc_size(child, uname);
 	}
 	return 0;
 }
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index f38397c7b582..57694a704b00 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -36,6 +36,7 @@ struct alias_prop {
 #endif
 
 #define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+#define MAX_RESERVED_REGIONS    64
 
 extern struct mutex of_mutex;
 extern raw_spinlock_t devtree_lock;
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 8bd8bbc3aaec..d62f1956024c 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -26,7 +26,6 @@
 
 #include "of_private.h"
 
-#define MAX_RESERVED_REGIONS	64
 static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
 static int reserved_mem_count;
 
-- 
2.17.1



From quic_obabatun at quicinc.com  Mon Dec  4 10:54:03 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Mon, 4 Dec 2023 10:54:03 -0800
Subject: [RFC PATCH v2 0/6] Dynamic allocation of reserved_mem array.
Message-ID: <20231204185409.19615-1-quic_obabatun@quicinc.com>

The reserved_mem array is used to store the data of the different
reserved memory regions specified in the DT of a device.
The array stores information such as the name, node, starting address,
and size of a reserved memory region.

The array is currently statically allocated with a size of
MAX_RESERVED_REGIONS(64). This means that any system that specifies a
number of reserved memory regions greater than MAX_RESERVED_REGIONS(64)
will not have enough space to store the information for all the regions.

Therefore, this series extends the use of a static array for
reserved_mem, and introduces a dynamically allocated array using
memblock_alloc() based on the number of reserved memory regions
specified in the DT.

Memory gotten from memblock_alloc() is only writable after paging_init()
is called, but the reserved memory regions need to be reserved before
then so that the system does not create page table mappings for them.

Reserved memory regions can be divided into 2 groups.
i) Statically-placed reserved memory regions
i.e. regions defined in the DT using the @reg property.
ii) Dynamically-placed reserved memory regions.
i.e. regions specified in the DT using the @alloc_ranges
    and @size properties.

It is possible to call memblock_reserve() and memblock_mark_nomap() on
the statically-placed reserved memory regions and not need to save them
to the array until after paging_init(), but this is not possible for the
dynamically-placed reserved memory because the starting address of these
regions need to be stored somewhere after they are allocated.

Therefore, this series achieves the allocation and population of the
reserved_mem array in two steps:

1. Before paging_init()
   Before paging_init() is called, iterate through the reserved_mem
   nodes in the DT and do the following:
   - Allocate memory for dynamically-placed reserved memory regions and
     store their starting address in the static allocated reserved_mem
     array.
   - Call memblock_reserve() and memblock_mark_nomap() on all the
     reserved memory regions as needed.
   - Count the total number of reserved_mem nodes in the DT.

2. After paging_init()
   After paging_init() is called:
   - Allocate new memory for the reserved_mem array based on the number
     of reserved memory nodes in the DT.
   - Transfer all the information that was stored in the static array
     into the new array.
   - Store the rest of the reserved_mem regions in the new array.
     i.e. the statically-placed regions.

The static array is no longer needed after this point, but there is
currently no obvious way to free the memory. Therefore, the size of the
initial static array is now defined using a config option.
Because the array is used only before paging_init() to store the
dynamically-placed reserved memory regions, the required size can vary
from device to device. Therefore, scaling it can help get some memory
savings.

A possible solution to freeing the memory for the static array will be
to mark it as __initdata. This will automatically free the memory once
the init process is done running.
The reason why this is not pursued in this series is because of
the possibility of a use-after-free.
If the dynamic allocation of the reserved_mem array fails, then future
accesses of the reserved_mem array will still be referencing the static
array. When the init process ends and the memory is freed up, any
further attempts to use the reserved_mem array will result in a
use-after-free.

Note:

- The limitation to this approach is that there is still a limit of
  64 for dynamically reserved memory regions.
- Upon further review, the series might need to be split up/duplicated
  for other archs.


Oreoluwa Babatunde (6):
  of: reserved_mem: Change the order that reserved_mem regions are
    stored
  of: reserved_mem: Swicth call to unflatten_device_tree() to after
    paging_init()
  of: resevred_mem: Delay allocation of memory for dynamic regions
  of: reserved_mem: Add code to use unflattened DT for reserved_mem
    nodes
  of: reserved_mem: Add code to dynamically allocate reserved_mem array
  of: reserved_mem: Make MAX_RESERVED_REGIONS a config option

 arch/loongarch/kernel/setup.c      |   2 +-
 arch/mips/kernel/setup.c           |   3 +-
 arch/nios2/kernel/setup.c          |   4 +-
 arch/openrisc/kernel/setup.c       |   4 +-
 arch/powerpc/kernel/setup-common.c |   3 +
 arch/sh/kernel/setup.c             |   5 +-
 arch/um/kernel/dtb.c               |   1 -
 arch/um/kernel/um_arch.c           |   2 +
 arch/xtensa/kernel/setup.c         |   4 +-
 drivers/of/Kconfig                 |  13 +++
 drivers/of/fdt.c                   |  39 +++++--
 drivers/of/of_private.h            |   6 +-
 drivers/of/of_reserved_mem.c       | 175 +++++++++++++++++++++--------
 include/linux/of_reserved_mem.h    |   8 +-
 kernel/dma/coherent.c              |   4 +-
 kernel/dma/contiguous.c            |   8 +-
 kernel/dma/swiotlb.c               |  10 +-
 17 files changed, 205 insertions(+), 86 deletions(-)

-- 
2.17.1



From quic_obabatun at quicinc.com  Mon Dec  4 10:54:05 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Mon, 4 Dec 2023 10:54:05 -0800
Subject: [RFC PATCH v2 2/6] of: reserved_mem: Swicth call to unflatten_device_tree() to after paging_init()
In-Reply-To: <20231204185409.19615-1-quic_obabatun@quicinc.com>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
Message-ID: <20231204185409.19615-3-quic_obabatun@quicinc.com>

Switch call to unflatten_device_tree() to after paging_init() on other
archs to follow new order in which the reserved_mem regions are
processed.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 arch/loongarch/kernel/setup.c      | 2 +-
 arch/mips/kernel/setup.c           | 3 ++-
 arch/nios2/kernel/setup.c          | 4 ++--
 arch/openrisc/kernel/setup.c       | 4 ++--
 arch/powerpc/kernel/setup-common.c | 3 +++
 arch/sh/kernel/setup.c             | 5 ++---
 arch/um/kernel/dtb.c               | 1 -
 arch/um/kernel/um_arch.c           | 2 ++
 arch/xtensa/kernel/setup.c         | 4 +++-
 9 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index d183a745fb85..a01051b0f9e0 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -366,7 +366,6 @@ void __init platform_init(void)
 	acpi_gbl_use_default_register_widths = false;
 	acpi_boot_table_init();
 #endif
-	unflatten_and_copy_device_tree();
 
 #ifdef CONFIG_NUMA
 	init_numa_memory();
@@ -626,6 +625,7 @@ void __init setup_arch(char **cmdline_p)
 
 	paging_init();
 
+	unflatten_and_copy_device_tree();
 #ifdef CONFIG_KASAN
 	kasan_init();
 #endif
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 2d2ca024bd47..d3b6c86a8037 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -667,7 +667,6 @@ static void __init arch_mem_init(char **cmdline_p)
 	mips_reserve_vmcore();
 
 	mips_parse_crashkernel();
-	device_tree_init();
 
 	/*
 	 * In order to reduce the possibility of kernel panic when failed to
@@ -798,6 +797,8 @@ void __init setup_arch(char **cmdline_p)
 	cpu_cache_init();
 	paging_init();
 
+	device_tree_init();
+
 	memblock_dump_all();
 
 	setup_rng_seed();
diff --git a/arch/nios2/kernel/setup.c b/arch/nios2/kernel/setup.c
index da122a5fa43b..6f1a4232b8f0 100644
--- a/arch/nios2/kernel/setup.c
+++ b/arch/nios2/kernel/setup.c
@@ -169,8 +169,6 @@ void __init setup_arch(char **cmdline_p)
 	early_init_fdt_reserve_self();
 	early_init_fdt_scan_reserved_mem();
 
-	unflatten_and_copy_device_tree();
-
 	setup_cpuinfo();
 
 	copy_exception_handler(cpuinfo.exception_addr);
@@ -189,4 +187,6 @@ void __init setup_arch(char **cmdline_p)
 	 * get kmalloc into gear
 	 */
 	paging_init();
+
+	unflatten_and_copy_device_tree();
 }
diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index 9cf7fb60441f..fcda33bdca19 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -255,8 +255,6 @@ void calibrate_delay(void)
 
 void __init setup_arch(char **cmdline_p)
 {
-	unflatten_and_copy_device_tree();
-
 	setup_cpuinfo();
 
 #ifdef CONFIG_SMP
@@ -284,6 +282,8 @@ void __init setup_arch(char **cmdline_p)
 	/* paging_init() sets up the MMU and marks all pages as reserved */
 	paging_init();
 
+	unflatten_and_copy_device_tree();
+
 	*cmdline_p = boot_command_line;
 
 	printk(KERN_INFO "OpenRISC Linux -- http://openrisc.io\n");
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 9b142b9d5187..58da58d02652 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -986,6 +986,9 @@ void __init setup_arch(char **cmdline_p)
 
 	paging_init();
 
+	/* Unflatten the device-tree passed by prom_init or kexec */
+	unflatten_device_tree();
+
 	/* Initialize the MMU context management stuff. */
 	mmu_context_init();
 
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index 3d80515298d2..2553696af21b 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -322,6 +322,8 @@ void __init setup_arch(char **cmdline_p)
 	/* Let earlyprintk output early console messages */
 	sh_early_platform_driver_probe("earlyprintk", 1, 1);
 
+	paging_init();
+
 #ifdef CONFIG_OF_EARLY_FLATTREE
 #ifdef CONFIG_USE_BUILTIN_DTB
 	unflatten_and_copy_device_tree();
@@ -329,9 +331,6 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 #endif
 #endif
-
-	paging_init();
-
 	/* Perform the machine specific initialisation */
 	if (likely(sh_mv.mv_setup))
 		sh_mv.mv_setup(cmdline_p);
diff --git a/arch/um/kernel/dtb.c b/arch/um/kernel/dtb.c
index 484141b06938..04b0ada3b929 100644
--- a/arch/um/kernel/dtb.c
+++ b/arch/um/kernel/dtb.c
@@ -26,7 +26,6 @@ void uml_dtb_init(void)
 	}
 
 	early_init_fdt_scan_reserved_mem();
-	unflatten_device_tree();
 }
 
 static int __init uml_dtb_setup(char *line, int *add)
diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
index b1bfed0c8528..fe6ecaa12ef2 100644
--- a/arch/um/kernel/um_arch.c
+++ b/arch/um/kernel/um_arch.c
@@ -7,6 +7,7 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/mm.h>
+#include <linux/of_fdt.h>
 #include <linux/ctype.h>
 #include <linux/module.h>
 #include <linux/panic_notifier.h>
@@ -421,6 +422,7 @@ void __init setup_arch(char **cmdline_p)
 	read_initrd();
 
 	paging_init();
+	unflatten_device_tree();
 	strscpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
 	*cmdline_p = command_line;
 	setup_hostinfo(host_info, sizeof host_info);
diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index bdec4a773af0..d20c56b4182e 100644
--- a/arch/xtensa/kernel/setup.c
+++ b/arch/xtensa/kernel/setup.c
@@ -355,13 +355,15 @@ void __init setup_arch(char **cmdline_p)
 	parse_early_param();
 	bootmem_init();
 	kasan_init();
-	unflatten_and_copy_device_tree();
 
 #ifdef CONFIG_SMP
 	smp_init_cpus();
 #endif
 
 	paging_init();
+
+	unflatten_and_copy_device_tree();
+
 	zones_init();
 
 #ifdef CONFIG_VT
-- 
2.17.1



From quic_obabatun at quicinc.com  Mon Dec  4 10:54:07 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Mon, 4 Dec 2023 10:54:07 -0800
Subject: [RFC PATCH v2 4/6] of: reserved_mem: Add code to use unflattened DT for reserved_mem nodes
In-Reply-To: <20231204185409.19615-1-quic_obabatun@quicinc.com>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
Message-ID: <20231204185409.19615-5-quic_obabatun@quicinc.com>

The unflattened devicetree APIs are available to be used right after
paging_init() runs. Therefore, use the unflattened devicetree APIs to
process the reserved memory regions from this point.

Using the unflattened devicetree APIs is more efficient than using the
flattened devicetree APIs.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/fdt.c                | 51 +--------------------
 drivers/of/of_private.h         |  4 +-
 drivers/of/of_reserved_mem.c    | 79 +++++++++++++++++++++++++--------
 include/linux/of_fdt.h          |  1 -
 include/linux/of_reserved_mem.h |  2 +-
 kernel/dma/coherent.c           |  4 +-
 kernel/dma/contiguous.c         |  8 ++--
 kernel/dma/swiotlb.c            | 10 ++---
 8 files changed, 76 insertions(+), 83 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 46adce306bbd..12769dd53c34 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -558,55 +558,6 @@ static int __init __reserved_mem_check_root(unsigned long node)
 	return 0;
 }
 
-/*
- * Save the reserved_mem reg nodes in the reserved_mem array
- */
-void __init fdt_scan_reserved_mem_reg_nodes(void)
-
-{
-	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
-	const void *fdt = initial_boot_params;
-	phys_addr_t base, size;
-	const __be32 *prop;
-	int node, child;
-	int len;
-
-	node = fdt_path_offset(fdt, "/reserved-memory");
-	if (node < 0) {
-		pr_err("Reserved memory: Did not find reserved-memory node\n");
-		return;
-	}
-
-	if (__reserved_mem_check_root(node) != 0) {
-		pr_err("Reserved memory: unsupported node format, ignoring\n");
-		return;
-	}
-
-	fdt_for_each_subnode(child, fdt, node) {
-		const char *uname;
-
-		prop = of_get_flat_dt_prop(child, "reg", &len);
-		if (!prop)
-			continue;
-
-		if (!of_fdt_device_is_available(fdt, child))
-			continue;
-
-		uname = fdt_get_name(fdt, child, NULL);
-		if (len && len % t_len != 0) {
-			pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
-			       uname);
-			continue;
-		}
-
-		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
-		size = dt_mem_next_cell(dt_root_size_cells, &prop);
-
-		if (size)
-			fdt_reserved_mem_save_node(child, uname, base, size);
-	}
-}
-
 /*
  * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory.
  */
@@ -1393,7 +1344,7 @@ void __init unflatten_device_tree(void)
 	unittest_unflatten_overlay_base();
 
 	/*Initialize the reserved_mem regions*/
-	fdt_init_reserved_mem();
+	init_reserved_mem();
 }
 
 /**
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 57694a704b00..575e2b4119e0 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -176,8 +176,8 @@ static inline struct device_node *__of_get_dma_parent(const struct device_node *
 }
 #endif
 
-void fdt_init_reserved_mem(void);
-void fdt_reserved_mem_save_node(unsigned long node, const char *uname,
+void init_reserved_mem(void);
+void dt_reserved_mem_save_node(struct device_node *node, const char *uname,
 			       phys_addr_t base, phys_addr_t size);
 
 #endif /* _LINUX_OF_PRIVATE_H */
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index d62f1956024c..2ef9edcb8c93 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -55,9 +55,9 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
 }
 
 /*
- * fdt_reserved_mem_save_node() - save fdt node for second pass initialization
+ * dt_reserved_mem_save_node() - save dt node for second pass initialization
  */
-void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
+void __init dt_reserved_mem_save_node(struct device_node *node, const char *uname,
 				      phys_addr_t base, phys_addr_t size)
 {
 	struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
@@ -67,7 +67,7 @@ void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
 		return;
 	}
 
-	rmem->fdt_node = node;
+	rmem->dev_node = node;
 	rmem->name = uname;
 	rmem->base = base;
 	rmem->size = size;
@@ -76,6 +76,54 @@ void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
 	return;
 }
 
+/*
+ * Save the reserved_mem reg nodes in the reserved_mem array
+ */
+static void __init scan_reserved_mem_reg_nodes(void)
+
+{
+	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
+	struct device_node *node, *child;
+	phys_addr_t base, size;
+	const __be32 *prop;
+	int len;
+
+	node = of_find_node_by_path("/reserved-memory");
+	if (node < 0) {
+		pr_err("Reserved memory: Did not find reserved-memory node\n");
+		return;
+	}
+
+	for_each_child_of_node(node, child) {
+		const char *uname;
+		struct reserved_mem *rmem;
+
+		if (!of_device_is_available(child))
+			continue;
+
+		prop = of_get_property(child, "reg", &len);
+		if (!prop) {
+			rmem = of_reserved_mem_lookup(child);
+			if (rmem)
+				rmem->dev_node = child;
+			continue;
+		}
+
+		uname = of_node_full_name(child);
+		if (len && len % t_len != 0) {
+			pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
+			       uname);
+			continue;
+		}
+
+		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+		size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+		if (size)
+			dt_reserved_mem_save_node(child, uname, base, size);
+	}
+}
+
 /*
  * __reserved_mem_alloc_in_range() - allocate reserved memory described with
  *	'alloc-ranges'. Choose bottom-up/top-down depending on nearby existing
@@ -210,7 +258,7 @@ int __init __reserved_mem_alloc_size(unsigned long node, const char *uname)
 		       uname, (unsigned long)(size / SZ_1M));
 		return -ENOMEM;
 	}
-	fdt_reserved_mem_save_node(node, uname, base, size);
+	dt_reserved_mem_save_node(NULL, uname, base, size);
 	return 0;
 }
 
@@ -230,7 +278,7 @@ static int __init __reserved_mem_init_node(struct reserved_mem *rmem)
 		reservedmem_of_init_fn initfn = i->data;
 		const char *compat = i->compatible;
 
-		if (!of_flat_dt_is_compatible(rmem->fdt_node, compat))
+		if (!of_device_is_compatible(rmem->dev_node, compat))
 			continue;
 
 		ret = initfn(rmem);
@@ -263,11 +311,6 @@ static int __init __rmem_cmp(const void *a, const void *b)
 	if (ra->size > rb->size)
 		return 1;
 
-	if (ra->fdt_node < rb->fdt_node)
-		return -1;
-	if (ra->fdt_node > rb->fdt_node)
-		return 1;
-
 	return 0;
 }
 
@@ -299,29 +342,29 @@ static void __init __rmem_check_for_overlap(void)
 }
 
 /**
- * fdt_init_reserved_mem() - allocate and init all saved reserved memory regions
+ * init_reserved_mem() - allocate and init all saved reserved memory regions
  */
-void __init fdt_init_reserved_mem(void)
+void __init init_reserved_mem(void)
 {
 	int i;
 
-	fdt_scan_reserved_mem_reg_nodes();
+	scan_reserved_mem_reg_nodes();
 
 	/* check for overlapping reserved regions */
 	__rmem_check_for_overlap();
 
 	for (i = 0; i < reserved_mem_count; i++) {
 		struct reserved_mem *rmem = &reserved_mem[i];
-		unsigned long node = rmem->fdt_node;
+		struct device_node *node = rmem->dev_node;
 		int len;
 		const __be32 *prop;
 		int err = 0;
 		bool nomap;
 
-		nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
-		prop = of_get_flat_dt_prop(node, "phandle", &len);
+		nomap = of_get_property(node, "no-map", NULL) != NULL;
+		prop = of_get_property(node, "phandle", &len);
 		if (!prop)
-			prop = of_get_flat_dt_prop(node, "linux,phandle", &len);
+			prop = of_get_property(node, "linux,phandle", &len);
 		if (prop)
 			rmem->phandle = of_read_number(prop, len/4);
 
@@ -337,7 +380,7 @@ void __init fdt_init_reserved_mem(void)
 		} else {
 			phys_addr_t end = rmem->base + rmem->size - 1;
 			bool reusable =
-				(of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
+				(of_get_property(node, "reusable", NULL)) != NULL;
 
 			pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
 				&rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 7b2a5d93d719..d69ad5bb1eb1 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -73,7 +73,6 @@ extern int early_init_dt_scan_root(void);
 extern bool early_init_dt_scan(void *params);
 extern bool early_init_dt_verify(void *params);
 extern void early_init_dt_scan_nodes(void);
-extern void fdt_scan_reserved_mem_reg_nodes(void);
 
 extern const char *of_flat_dt_get_machine_name(void);
 extern const void *of_flat_dt_match_machine(const void *default_match,
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index dc13bcd04b12..2b205ce6beb9 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -10,7 +10,7 @@ struct reserved_mem_ops;
 
 struct reserved_mem {
 	const char			*name;
-	unsigned long			fdt_node;
+	struct device_node		*dev_node;
 	unsigned long			phandle;
 	const struct reserved_mem_ops	*ops;
 	phys_addr_t			base;
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index c21abc77c53e..3eba9678dc33 100644
--- a/kernel/dma/coherent.c
+++ b/kernel/dma/coherent.c
@@ -360,9 +360,9 @@ static const struct reserved_mem_ops rmem_dma_ops = {
 
 static int __init rmem_dma_setup(struct reserved_mem *rmem)
 {
-	unsigned long node = rmem->fdt_node;
+	struct device_node *node = rmem->dev_node;
 
-	if (of_get_flat_dt_prop(node, "reusable", NULL))
+	if (of_get_property(node, "reusable", NULL))
 		return -EINVAL;
 
 #ifdef CONFIG_ARM
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index f005c66f378c..b54cf128a9d9 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -462,8 +462,8 @@ static const struct reserved_mem_ops rmem_cma_ops = {
 
 static int __init rmem_cma_setup(struct reserved_mem *rmem)
 {
-	unsigned long node = rmem->fdt_node;
-	bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
+	struct device_node *node = rmem->dev_node;
+	bool default_cma = of_get_property(node, "linux,cma-default", NULL);
 	struct cma *cma;
 	int err;
 
@@ -473,8 +473,8 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
 		return -EBUSY;
 	}
 
-	if (!of_get_flat_dt_prop(node, "reusable", NULL) ||
-	    of_get_flat_dt_prop(node, "no-map", NULL))
+	if (!of_get_property(node, "reusable", NULL) ||
+	    of_get_property(node, "no-map", NULL))
 		return -EINVAL;
 
 	if (!IS_ALIGNED(rmem->base | rmem->size, CMA_MIN_ALIGNMENT_BYTES)) {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 33d942615be5..14840a58a6e6 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -1709,12 +1709,12 @@ static const struct reserved_mem_ops rmem_swiotlb_ops = {
 
 static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
 {
-	unsigned long node = rmem->fdt_node;
+	struct device_node *node = rmem->dev_node;
 
-	if (of_get_flat_dt_prop(node, "reusable", NULL) ||
-	    of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
-	    of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
-	    of_get_flat_dt_prop(node, "no-map", NULL))
+	if (of_get_property(node, "reusable", NULL) ||
+	    of_get_property(node, "linux,cma-default", NULL) ||
+	    of_get_property(node, "linux,dma-default", NULL) ||
+	    of_get_property(node, "no-map", NULL))
 		return -EINVAL;
 
 	rmem->ops = &rmem_swiotlb_ops;
-- 
2.17.1



From quic_obabatun at quicinc.com  Mon Dec  4 10:54:09 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Mon, 4 Dec 2023 10:54:09 -0800
Subject: [RFC PATCH v2 6/6] of: reserved_mem: Make MAX_RESERVED_REGIONS a config option
In-Reply-To: <20231204185409.19615-1-quic_obabatun@quicinc.com>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
Message-ID: <20231204185409.19615-7-quic_obabatun@quicinc.com>

Make the value of MAX_RESERVED_REGIONS a config option which can be
modified based on user requirements.
The reserved_mem_array is required during device bootup to store the
information of the dynamically-placed reserved memory regions.
After paging_init(), this information is transferred to another
array which is dynamically allocated and used to store all the reserved
memory regions.

There is currently no obvious way to free the memory for the static
array after its contents are copied over to the dynamically allocated
array, but since the size required for the reserved_mem_array can vary
from device to device depending on the number of dynamically-placed
reserved memory regions, make the size of the array configurable in an
attempt to save some memory.

Signed-off-by: Oreoluwa Babatunde <quic_obabatun at quicinc.com>
---
 drivers/of/Kconfig      | 13 +++++++++++++
 drivers/of/of_private.h |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index da9826accb1b..409ce2527461 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -102,4 +102,17 @@ config OF_OVERLAY
 config OF_NUMA
 	bool
 
+config OF_MAX_RESERVED_REGIONS
+	int "OF resvered_mem array size"
+	default "64"
+	range 1 64
+	help
+	   The reserved_mem_array is used to store information about the dynamically
+	   placed reserved memory regions before we are able to allocate the memory
+	   needed to store all the reserved memory regions defined in the DT.
+	   Because the amount of memory needed initially for this array could vary,
+	   make the size of the reserved_mem_array configurable in an attempt to
+	   save some memory when possible.
+	   if unsure, leave as default value.
+
 endif # OF
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index ef56b2ea185c..278038bce0c0 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -36,7 +36,7 @@ struct alias_prop {
 #endif
 
 #define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-#define MAX_RESERVED_REGIONS    64
+#define MAX_RESERVED_REGIONS    CONFIG_OF_MAX_RESERVED_REGIONS
 
 extern struct mutex of_mutex;
 extern raw_spinlock_t devtree_lock;
-- 
2.17.1



From knaerzche at gmail.com  Mon Dec  4 10:56:45 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon, 4 Dec 2023 19:56:45 +0100
Subject: [PATCH v1 1/3] dt-bindings: drm: rockchip: convert
 inno_hdmi-rockchip.txt to yaml
In-Reply-To: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
References: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
Message-ID: <3f235189-da75-4e9d-ad68-8cbebca12f6d@gmail.com>

Hi Johan,
Am 04.12.23 um 18:39 schrieb Johan Jonker:
> Convert inno_hdmi-rockchip.txt to yaml.
Nice - I'm having something very similar on my queue :)
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> 
> Note for rob+dt:
>    Used enum to "soon" be able to add "rockchip,rk3128-inno-hdmi"
Yeah, actually I'm planning to submit it really soon (if timne allows).
> 
> Changed V1:
>    Rename file to more common layout
>    Add/fix hdmi_out port example
> ---
>   .../display/rockchip/inno_hdmi-rockchip.txt   |  49 ---------
>   .../display/rockchip/rockchip,inno-hdmi.yaml  | 103 ++++++++++++++++++
>   2 files changed, 103 insertions(+), 49 deletions(-)
>   delete mode 100644 Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>   create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
> deleted file mode 100644
> index cec21714f0e0..000000000000
> --- a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
> +++ /dev/null
> @@ -1,49 +0,0 @@
> -Rockchip specific extensions to the Innosilicon HDMI
> -================================
> -
> -Required properties:
> -- compatible:
> -	"rockchip,rk3036-inno-hdmi";
> -- reg:
> -	Physical base address and length of the controller's registers.
> -- clocks, clock-names:
> -	Phandle to hdmi controller clock, name should be "pclk"
> -- interrupts:
> -	HDMI interrupt number
> -- ports:
> -	Contain one port node with endpoint definitions as defined in
> -	Documentation/devicetree/bindings/graph.txt.
> -- pinctrl-0, pinctrl-name:
> -	Switch the iomux of HPD/CEC pins to HDMI function.
> -
> -Example:
> -hdmi: hdmi at 20034000 {
> -	compatible = "rockchip,rk3036-inno-hdmi";
> -	reg = <0x20034000 0x4000>;
> -	interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
> -	clocks = <&cru  PCLK_HDMI>;
> -	clock-names = "pclk";
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&hdmi_ctl>;
> -
> -	hdmi_in: port {
> -		#address-cells = <1>;
> -		#size-cells = <0>;
> -		hdmi_in_lcdc: endpoint at 0 {
> -			reg = <0>;
> -			remote-endpoint = <&lcdc_out_hdmi>;
> -		};
> -	};
> -};
> -
> -&pinctrl {
> -	hdmi {
> -		hdmi_ctl: hdmi-ctl {
> -			rockchip,pins = <1 8  RK_FUNC_1 &pcfg_pull_none>,
> -					<1 9  RK_FUNC_1 &pcfg_pull_none>,
> -					<1 10 RK_FUNC_1 &pcfg_pull_none>,
> -					<1 11 RK_FUNC_1 &pcfg_pull_none>;
> -		};
> -	};
> -
> -};
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> new file mode 100644
> index 000000000000..96889c86849a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/rockchip/rockchip,inno-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip Innosilicon HDMI controller
> +
> +maintainers:
> +  - Sandy Huang <hjc at rock-chips.com>
> +  - Heiko Stuebner <heiko at sntech.de>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - rockchip,rk3036-inno-hdmi
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
The interrupts/clock description exists already in the txt-bindings - so 
how about:

+    items:
+      - descrition: ....
> +
> +  clock-names:
> +    const: pclk
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port at 0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description:
> +          Port node with one endpoint connected to a vop node.
> +
> +      port at 1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description:
> +          Port node with one endpoint connected to a hdmi-connector node.
> +
> +    required:
> +      - port at 0
> +      - port at 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - pinctrl-0
> +  - pinctrl-names
> +  - ports
> +
> +additionalProperties: false
Did you check that with dtbs_check? RK3036's SoC dtsi also contains a

  rockchip,grf = <&grf>;

and I'm not seeing this removed in this series.

It would be great if that would added here to as requirement
for RK3036 too  (and updated in the example)
Even if it is beyond a pure txt to yaml conversion: RK3036 needs to set 
HDMI polarities in GRF.

Regards,
Alex
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3036-cru.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/pinctrl/rockchip.h>
> +    hdmi: hdmi at 20034000 {
> +      compatible = "rockchip,rk3036-inno-hdmi";
> +      reg = <0x20034000 0x4000>;
> +      interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
> +      clocks = <&cru  PCLK_HDMI>;
> +      clock-names = "pclk";
> +      pinctrl-names = "default";
> +      pinctrl-0 = <&hdmi_ctl>;
> +
> +      ports {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        hdmi_in: port at 0 {
> +          reg = <0>;
> +          hdmi_in_vop: endpoint {
> +            remote-endpoint = <&vop_out_hdmi>;
> +          };
> +        };
> +
> +        hdmi_out: port at 1 {
> +          reg = <1>;
> +          hdmi_out_con: endpoint {
> +            remote-endpoint = <&hdmi_con_in>;
> +          };
> +        };
> +      };
> +    };
> +
> +    pinctrl {
> +      hdmi {
> +        hdmi_ctl: hdmi-ctl {
> +          rockchip,pins = <1 RK_PB0 1 &pcfg_pull_none>,
> +                          <1 RK_PB1 1 &pcfg_pull_none>,
> +                          <1 RK_PB2 1 &pcfg_pull_none>,
> +                          <1 RK_PB3 1 &pcfg_pull_none>;
> +        };
> +      };
> +    };
> --
> 2.39.2
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip



From bvanassche at acm.org  Mon Dec  4 11:00:36 2023
From: bvanassche at acm.org (Bart Van Assche)
Date: Mon, 4 Dec 2023 11:00:36 -0800
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231204143101.64163-2-quic_mnaresh@quicinc.com>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
Message-ID: <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>

On 12/4/23 06:30, Maramaina Naresh wrote:
> +	u32	(*config_qos_vote)(struct ufs_hba *hba);

Please remove the above callback since this patch series does not
introduce any instances of this callback.

> +
> +	/* This capability allows the host controller driver to use the PM QoS
> +	 * feature.
> +	 */
> +	UFSHCD_CAP_PM_QOS				= 1 << 13,
>   };

Why does it depend on the host driver whether or not PM QoS is
enabled? Why isn't it enabled unconditionally?

> + * @pm_qos_req: PM QoS request handle
> + * @pm_qos_init: flag to check if pm qos init completed
>    */

Documentation for pm_qos_init is missing.

>   struct ufs_hba {
>   	void __iomem *mmio_base;
> @@ -1076,6 +1089,9 @@ struct ufs_hba {
>   	struct ufs_hw_queue *uhq;
>   	struct ufs_hw_queue *dev_cmd_queue;
>   	struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
> +	struct pm_qos_request pm_qos_req;
> +	bool pm_qos_init;
> +	u32 qos_vote;

Please rename "pm_qos_init" into "pm_qos_initialized".

Thanks,

Bart.



From irogers at google.com  Mon Dec  4 11:02:31 2023
From: irogers at google.com (Ian Rogers)
Date: Mon, 4 Dec 2023 11:02:31 -0800
Subject: [PATCH 1/3] perf vendor events arm64: AmpereOne: Add missing
 DefaultMetricgroupName fields
In-Reply-To: <20231201021550.1109196-2-ilkka@os.amperecomputing.com>
References: <20231201021550.1109196-1-ilkka@os.amperecomputing.com> <20231201021550.1109196-2-ilkka@os.amperecomputing.com>
Message-ID: <CAP-5=fWr0bmqZjyYiBuMuCD+sPCULmF_q7hU4J8ouvcvwb5Z6w@mail.gmail.com>

On Thu, Nov 30, 2023 at 6:16?PM Ilkka Koskinen
<ilkka at os.amperecomputing.com> wrote:
>
> AmpereOne metrics were missing DefaultMetricgroupName from metrics with
> "Default" in group name resulting perf to segfault. Add the missing
> field to address the issue.
>
> Fixes: 59faeaf80d02 ("perf vendor events arm64: Fix for AmpereOne metrics")
> Signed-off-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>

Sorry, I just stumbled across this and sent a fix too.
https://lore.kernel.org/lkml/20231204182330.654255-1-irogers at google.com/
The patches are identical so I'd suggest taking this one and the first
patch in my changes.

Reviewed-by: Ian Rogers <irogers at google.com>

Thanks,
Ian

> ---
>  tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json
> index e2848a9d4848..afcdad58ef89 100644
> --- a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json
> +++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json
> @@ -231,6 +231,7 @@
>          "MetricName": "slots_lost_misspeculation_fraction",
>          "MetricExpr": "100 * ((OP_SPEC - OP_RETIRED) / (CPU_CYCLES * #slots))",
>          "BriefDescription": "Fraction of slots lost due to misspeculation",
> +        "DefaultMetricgroupName": "TopdownL1",
>          "MetricGroup": "Default;TopdownL1",
>          "ScaleUnit": "1percent of slots"
>      },
> @@ -238,6 +239,7 @@
>          "MetricName": "retired_fraction",
>          "MetricExpr": "100 * (OP_RETIRED / (CPU_CYCLES * #slots))",
>          "BriefDescription": "Fraction of slots retiring, useful work",
> +        "DefaultMetricgroupName": "TopdownL1",
>          "MetricGroup": "Default;TopdownL1",
>         "ScaleUnit": "1percent of slots"
>      },
> --
> 2.41.0
>


From irogers at google.com  Mon Dec  4 11:03:07 2023
From: irogers at google.com (Ian Rogers)
Date: Mon, 4 Dec 2023 11:03:07 -0800
Subject: [PATCH 2/3] perf vendor events arm64: AmpereOne: Rename
 BPU_FLUSH_MEM_FAULT to GPC_FLUSH_MEM_FAULT
In-Reply-To: <20231201021550.1109196-3-ilkka@os.amperecomputing.com>
References: <20231201021550.1109196-1-ilkka@os.amperecomputing.com> <20231201021550.1109196-3-ilkka@os.amperecomputing.com>
Message-ID: <CAP-5=fWKjRORSVh65cm+RMknS_-K=XQC2ew1VVaakvoX1X6CKw@mail.gmail.com>

On Thu, Nov 30, 2023 at 6:16?PM Ilkka Koskinen
<ilkka at os.amperecomputing.com> wrote:
>
> The documentation wrongly called the event as BPU_FLUSH_MEM_FAULT and now
> has been fixed. Correct the name in the perf tool as well.
>
> Fixes: a9650b7f6fc0 ("perf vendor events arm64: Add AmpereOne core PMU events")
> Signed-off-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>

Reviewed-by: Ian Rogers <irogers at google.com>

Thanks,
Ian

> ---
>  .../pmu-events/arch/arm64/ampere/ampereone/core-imp-def.json    | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/core-imp-def.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/core-imp-def.json
> index 88b23b85e33c..879ff21e0b17 100644
> --- a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/core-imp-def.json
> +++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/core-imp-def.json
> @@ -110,7 +110,7 @@
>      {
>          "PublicDescription": "Flushes due to memory hazards",
>          "EventCode": "0x121",
> -        "EventName": "BPU_FLUSH_MEM_FAULT",
> +        "EventName": "GPC_FLUSH_MEM_FAULT",
>          "BriefDescription": "Flushes due to memory hazards"
>      },
>      {
> --
> 2.41.0
>


From irogers at google.com  Mon Dec  4 11:07:33 2023
From: irogers at google.com (Ian Rogers)
Date: Mon, 4 Dec 2023 11:07:33 -0800
Subject: [PATCH 3/3] perf vendor events arm64: AmpereOneX: Add core PMU
 events and metrics
In-Reply-To: <20231201021550.1109196-4-ilkka@os.amperecomputing.com>
References: <20231201021550.1109196-1-ilkka@os.amperecomputing.com> <20231201021550.1109196-4-ilkka@os.amperecomputing.com>
Message-ID: <CAP-5=fUEsLQ+kqh4eo_5mcrEe_tHJ=t4CAxd7Um7aD8T+t4yTw@mail.gmail.com>

On Thu, Nov 30, 2023 at 6:16?PM Ilkka Koskinen
<ilkka at os.amperecomputing.com> wrote:
>
> Add JSON files for AmpereOneX core PMU events and metrics.
>
> Signed-off-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>

Reviewed-by: Ian Rogers <irogers at google.com>

Thanks,
Ian


From knaerzche at gmail.com  Mon Dec  4 11:12:47 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon, 4 Dec 2023 20:12:47 +0100
Subject: [PATCH v1 3/3] ARM: dts: rockchip: rk3036-kylin: add
 hdmi-connector node
In-Reply-To: <f5bc182b-f9b6-26a8-8649-19ce33e3c0e1@gmail.com>
References: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
 <f5bc182b-f9b6-26a8-8649-19ce33e3c0e1@gmail.com>
Message-ID: <447b1bde-584f-4eb4-8bfb-9abd3aa8b6fa@gmail.com>

Hi Johan,
Am 04.12.23 um 18:40 schrieb Johan Jonker:
> Add hdmi-connector node to comply with the inno_hdmi binding.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>   arch/arm/boot/dts/rockchip/rk3036-kylin.dts | 17 +++++++++++++++++
>   1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
> index 67e1e04139e7..a213333be011 100644
> --- a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
> +++ b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
> @@ -13,6 +13,17 @@ memory at 60000000 {
>   		reg = <0x60000000 0x20000000>;
>   	};
> 
> +	hdmi_con: hdmi-con {
> +		compatible = "hdmi-connector";
> +		type = "c";
According to [0], kylin has an A-Type HDMI port - so this should be
  +		type = "a";

[0] http://rockchip.wikidot.com/kylin

Regards,
Alex
> +
> +		port {
> +			hdmi_con_in: endpoint {
> +				remote-endpoint = <&hdmi_out_con>;
> +			};
> +		};
> +	};
> +
>   	leds: gpio-leds {
>   		compatible = "gpio-leds";
> 
> @@ -110,6 +121,12 @@ &hdmi {
>   	status = "okay";
>   };
> 
> +&hdmi_out {
> +	hdmi_out_con: endpoint {
> +		remote-endpoint = <&hdmi_con_in>;
> +	};
> +};
> +
>   &i2c1 {
>   	clock-frequency = <400000>;
> 
> --
> 2.39.2
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip



From cl at linux.com  Mon Dec  4 11:15:26 2023
From: cl at linux.com (Christoph Lameter (Ampere))
Date: Mon, 04 Dec 2023 11:15:26 -0800
Subject: [RFC 0/8] ARM64 TLB logic revision for more control and enhanced diagnostics
Message-ID: <20231204191526.913822216@linux.com>

WARNING: First draft of the patchset, tested with kernel compiles, may
corrupt your memory.

This patchset intends to aid in help debugging and scaling TLB operations
on ARM64. This is in particular desirable for ARM architectures with
large numbers of cores. What is often seen is that the mesh is flooded with
snoop traffic that is related to TLBI broadcasts.

The patchset adds the following features:

- Allow diagnostics via /proc/vmstat like already possible on X86 with the
	CONFIG_DEBUG_TLB  option.

  Some sample output:

  cat /proc/vmstat
	...
	nr_tlb_remote_flush 554104		Flushes converted to IPIs with local flushing
	nr_tlb_remote_flush_received 1312243	IPIs received to perform local flushing
	nr_tlb_local_flush_all 141837		Local flush alls
	nr_tlb_local_flush_range 571784		Local flush range
	nr_tlb_local_flush_one 8011880		Local individual page flushes
	nr_tlb_flush_all 28239			Flush alls through the mesh
	nr_tlb_flush_range 13003		Flush range through the mesh
	nr_tlb_flush_one 54764			Flush one through the mesh
	nr_tlb_skipped 0			Suppressed flush

- Tracks the cores that have used an address space. With that we can
	compute the weight of cpus that have used this address space
	to decide on how to optimally do the flushing when such an action
	is required.

- Control the TLB flushing behavior via the kernel command line and also on a running system.

    New Kernel parameter  tlb_mode=<tlb_mode>
    New sysfs setting     /sys/kernel/debug/tlb_mode

	tlb_mode is comprised of a set of flags starting at bit 10. Bit 0-9
	are used to set a boundary as to what cpu weight will lead to a mesh
	flush. If the cpu weight is lower then IPIs are send avoiding the mesh.

	Feature flags:

	Bit 10 = If the current cpu is the only one that has ever used an
			address space then perform local invalidation.
			This catches the majority of flushes on boot and
			activities of typical single threaded Unixy processes.

	Bit 11 = Enable TLB range. Various hardware has problems with TLB range.
			This allows the kernel to recognize that TLB range
			should not be used and an alternate method is to be
			used to do the flushing.

	Bit 12 = Suppress TLB flushes if the address space is unused.
			If this bit is set and a flush is requested in an
			unused address space then no flush will be performed
			since there cannot any TLB entries. If this is
			not set then perform mesh flush (just to be sure).

- Autotunes the feature flags on bootup if the user has not specified tlb_mode.
	Calculates an optimal balance between IPIs and mesh flushing
	based on the number of cpus in the system. Enables local validation
	always and tlb range flushing if the processor features indicate
	that the processor supports it.


We need a more detailed description but I hope this is enough to get started.

These issues have been discussed before in an patchset that contains a similar feature 
in 2019:

https://lore.kernel.org/linux-arm-kernel/20190617143255.10462-1-indou.takao at jp.fujitsu.com/



From akpm at linux-foundation.org  Mon Dec  4 11:30:39 2023
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 4 Dec 2023 11:30:39 -0800
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <20231204113039.42510c23455026e40c5e2a56@linux-foundation.org>

On Mon,  4 Dec 2023 10:20:17 +0000 Ryan Roberts <ryan.roberts at arm.com> wrote:

> Hi All,
> 
> 
> Prerequisites
> =============
> 
> Some work items identified as being prerequisites are listed on page 3 at [9].
> The summary is:
> 
> | item                          | status                  |
> |:------------------------------|:------------------------|
> | mlock                         | In mainline (v6.7)      |
> | madvise                       | In mainline (v6.6)      |
> | compaction                    | v1 posted [10]          |
> | numa balancing                | Investigated: see below |
> | user-triggered page migration | In mainline (v6.7)      |
> | khugepaged collapse           | In mainline (NOP)       |

What does "prerequisites" mean here?  Won't compile without?  Kernel
crashes without?  Nice-to-have-after?  Please expand on this.

I looked at [9], but access is denied.

> [9] https://drive.google.com/file/d/1GnfYFpr7_c1kA41liRUW5YtCb8Cj18Ud/view?usp=sharing&resourcekey=0-U1Mj3-RhLD1JV6EThpyPyA




From heiko at sntech.de  Mon Dec  4 11:35:15 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 04 Dec 2023 20:35:15 +0100
Subject: [PATCH v1 1/2] ARM: dts: rockchip: add gpio alias for gpio dt nodes
In-Reply-To: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
References: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
Message-ID: <62868103.matp6XCIr4@diego>

Hi Johan,

Am Samstag, 2. Dezember 2023, 19:22:01 CET schrieb Johan Jonker:
> Rockchip SoC TRM, SoC datasheet and board schematics always refer to
> the same gpio numbers - even if not all are used for a specific board.
> In order to not have to re-define them for every board add the
> aliases to SoC dtsi files.
> 
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>

patch itself looks good, but I don't understand the authorship situation.
As these two signed-off-bys are now it would suggest that you picked up
Jianqun Xu's patch, but then the author would need to be different.

Or do you want to declare this via a
Co-Developed-by: Jianqun Xu <jay.xu at rock-chips.com>


Thanks
Heiko

> ---
> 
> Changed V1:
>   rebase
>   remove rk3066 gpio5 alias
> ---
>  arch/arm/boot/dts/rockchip/rk3036.dtsi  | 3 +++
>  arch/arm/boot/dts/rockchip/rk3066a.dtsi | 5 +++++
>  arch/arm/boot/dts/rockchip/rk322x.dtsi  | 4 ++++
>  arch/arm/boot/dts/rockchip/rk3288.dtsi  | 9 +++++++++
>  arch/arm/boot/dts/rockchip/rk3xxx.dtsi  | 4 ++++
>  5 files changed, 25 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> index 78686fc72ce6..8aa2e0864fed 100644
> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> @@ -17,6 +17,9 @@ / {
>  	interrupt-parent = <&gic>;
> 
>  	aliases {
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
>  		i2c0 = &i2c0;
>  		i2c1 = &i2c1;
>  		i2c2 = &i2c2;
> diff --git a/arch/arm/boot/dts/rockchip/rk3066a.dtsi b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> index de9915d946f7..30139f21de64 100644
> --- a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> @@ -13,6 +13,11 @@
>  / {
>  	compatible = "rockchip,rk3066a";
> 
> +	aliases {
> +		gpio4 = &gpio4;
> +		gpio6 = &gpio6;
> +	};
> +
>  	cpus {
>  		#address-cells = <1>;
>  		#size-cells = <0>;
> diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi b/arch/arm/boot/dts/rockchip/rk322x.dtsi
> index a721744cbfd1..831561fc1814 100644
> --- a/arch/arm/boot/dts/rockchip/rk322x.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk322x.dtsi
> @@ -15,6 +15,10 @@ / {
>  	interrupt-parent = <&gic>;
> 
>  	aliases {
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
>  		serial0 = &uart0;
>  		serial1 = &uart1;
>  		serial2 = &uart2;
> diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi b/arch/arm/boot/dts/rockchip/rk3288.dtsi
> index cb9cdaddffd4..ead343dc3df1 100644
> --- a/arch/arm/boot/dts/rockchip/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3288.dtsi
> @@ -19,6 +19,15 @@ / {
> 
>  	aliases {
>  		ethernet0 = &gmac;
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
> +		gpio4 = &gpio4;
> +		gpio5 = &gpio5;
> +		gpio6 = &gpio6;
> +		gpio7 = &gpio7;
> +		gpio8 = &gpio8;
>  		i2c0 = &i2c0;
>  		i2c1 = &i2c1;
>  		i2c2 = &i2c2;
> diff --git a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> index cb4e42ede56a..f37137f298d5 100644
> --- a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> @@ -16,6 +16,10 @@ / {
> 
>  	aliases {
>  		ethernet0 = &emac;
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
>  		i2c0 = &i2c0;
>  		i2c1 = &i2c1;
>  		i2c2 = &i2c2;
> --
> 2.39.2
> 
> 






From acme at kernel.org  Mon Dec  4 11:41:13 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Mon, 4 Dec 2023 16:41:13 -0300
Subject: [PATCH 1/3] perf vendor events arm64: AmpereOne: Add missing
 DefaultMetricgroupName fields
In-Reply-To: <CAP-5=fWr0bmqZjyYiBuMuCD+sPCULmF_q7hU4J8ouvcvwb5Z6w@mail.gmail.com>
References: <20231201021550.1109196-1-ilkka@os.amperecomputing.com>
 <20231201021550.1109196-2-ilkka@os.amperecomputing.com>
 <CAP-5=fWr0bmqZjyYiBuMuCD+sPCULmF_q7hU4J8ouvcvwb5Z6w@mail.gmail.com>
Message-ID: <ZW4rWWiMkeLpRPXa@kernel.org>

Em Mon, Dec 04, 2023 at 11:02:31AM -0800, Ian Rogers escreveu:
> On Thu, Nov 30, 2023 at 6:16?PM Ilkka Koskinen
> <ilkka at os.amperecomputing.com> wrote:
> >
> > AmpereOne metrics were missing DefaultMetricgroupName from metrics with
> > "Default" in group name resulting perf to segfault. Add the missing
> > field to address the issue.
> >
> > Fixes: 59faeaf80d02 ("perf vendor events arm64: Fix for AmpereOne metrics")
> > Signed-off-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
> 
> Sorry, I just stumbled across this and sent a fix too.
> https://lore.kernel.org/lkml/20231204182330.654255-1-irogers at google.com/
> The patches are identical so I'd suggest taking this one and the first
> patch in my changes.
> 
> Reviewed-by: Ian Rogers <irogers at google.com>

Thanks, applied the series.

- Arnaldo


From jbx6244 at gmail.com  Mon Dec  4 11:50:43 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 4 Dec 2023 20:50:43 +0100
Subject: [PATCH v1 1/2] ARM: dts: rockchip: add gpio alias for gpio dt
 nodes
In-Reply-To: <62868103.matp6XCIr4@diego>
References: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
 <62868103.matp6XCIr4@diego>
Message-ID: <3b436dfe-832a-3c63-cf03-2ddc7aa969c3@gmail.com>



On 12/4/23 20:35, Heiko St?bner wrote:
> Hi Johan,
> 
> Am Samstag, 2. Dezember 2023, 19:22:01 CET schrieb Johan Jonker:
>> Rockchip SoC TRM, SoC datasheet and board schematics always refer to
>> the same gpio numbers - even if not all are used for a specific board.
>> In order to not have to re-define them for every board add the
>> aliases to SoC dtsi files.
>>
>> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> 

> patch itself looks good, but I don't understand the authorship situation.
> As these two signed-off-bys are now it would suggest that you picked up
> Jianqun Xu's patch, but then the author would need to be different.
> 
> Or do you want to declare this via a
> Co-Developed-by: Jianqun Xu <jay.xu at rock-chips.com>

The newer tag use of Co-Developed-by is more confusing compared to in the old days...

Patch derived from:
https://lore.kernel.org/linux-rockchip/20220909090558.3609190-2-jay.xu at rock-chips.com/

Could you add/fix what is needed without resubmitting.

Johan

> 
> 
> Thanks
> Heiko
> 
>> ---
>>
>> Changed V1:
>>   rebase
>>   remove rk3066 gpio5 alias
>> ---
>>  arch/arm/boot/dts/rockchip/rk3036.dtsi  | 3 +++
>>  arch/arm/boot/dts/rockchip/rk3066a.dtsi | 5 +++++
>>  arch/arm/boot/dts/rockchip/rk322x.dtsi  | 4 ++++
>>  arch/arm/boot/dts/rockchip/rk3288.dtsi  | 9 +++++++++
>>  arch/arm/boot/dts/rockchip/rk3xxx.dtsi  | 4 ++++
>>  5 files changed, 25 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> index 78686fc72ce6..8aa2e0864fed 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> @@ -17,6 +17,9 @@ / {
>>  	interrupt-parent = <&gic>;
>>
>>  	aliases {
>> +		gpio0 = &gpio0;
>> +		gpio1 = &gpio1;
>> +		gpio2 = &gpio2;
>>  		i2c0 = &i2c0;
>>  		i2c1 = &i2c1;
>>  		i2c2 = &i2c2;
>> diff --git a/arch/arm/boot/dts/rockchip/rk3066a.dtsi b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
>> index de9915d946f7..30139f21de64 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
>> @@ -13,6 +13,11 @@
>>  / {
>>  	compatible = "rockchip,rk3066a";
>>
>> +	aliases {
>> +		gpio4 = &gpio4;
>> +		gpio6 = &gpio6;
>> +	};
>> +
>>  	cpus {
>>  		#address-cells = <1>;
>>  		#size-cells = <0>;
>> diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi b/arch/arm/boot/dts/rockchip/rk322x.dtsi
>> index a721744cbfd1..831561fc1814 100644
>> --- a/arch/arm/boot/dts/rockchip/rk322x.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk322x.dtsi
>> @@ -15,6 +15,10 @@ / {
>>  	interrupt-parent = <&gic>;
>>
>>  	aliases {
>> +		gpio0 = &gpio0;
>> +		gpio1 = &gpio1;
>> +		gpio2 = &gpio2;
>> +		gpio3 = &gpio3;
>>  		serial0 = &uart0;
>>  		serial1 = &uart1;
>>  		serial2 = &uart2;
>> diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi b/arch/arm/boot/dts/rockchip/rk3288.dtsi
>> index cb9cdaddffd4..ead343dc3df1 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3288.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3288.dtsi
>> @@ -19,6 +19,15 @@ / {
>>
>>  	aliases {
>>  		ethernet0 = &gmac;
>> +		gpio0 = &gpio0;
>> +		gpio1 = &gpio1;
>> +		gpio2 = &gpio2;
>> +		gpio3 = &gpio3;
>> +		gpio4 = &gpio4;
>> +		gpio5 = &gpio5;
>> +		gpio6 = &gpio6;
>> +		gpio7 = &gpio7;
>> +		gpio8 = &gpio8;
>>  		i2c0 = &i2c0;
>>  		i2c1 = &i2c1;
>>  		i2c2 = &i2c2;
>> diff --git a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
>> index cb4e42ede56a..f37137f298d5 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
>> @@ -16,6 +16,10 @@ / {
>>
>>  	aliases {
>>  		ethernet0 = &emac;
>> +		gpio0 = &gpio0;
>> +		gpio1 = &gpio1;
>> +		gpio2 = &gpio2;
>> +		gpio3 = &gpio3;
>>  		i2c0 = &i2c0;
>>  		i2c1 = &i2c1;
>>  		i2c2 = &i2c2;
>> --
>> 2.39.2
>>
>>
> 
> 
> 
> 


From ben.wolsieffer at hefring.com  Mon Dec  4 11:54:00 2023
From: ben.wolsieffer at hefring.com (Ben Wolsieffer)
Date: Mon, 4 Dec 2023 14:54:00 -0500
Subject: [PATCH] spi: stm32: enable controller before asserting CS
In-Reply-To: <9aa5e049-bd1c-41a6-b9b8-037ebb4f54b8@sirena.org.uk>
References: <20231201214014.2539031-1-ben.wolsieffer@hefring.com>
 <b070eb2a-05d7-4e6a-8de9-15179045d192@sirena.org.uk>
 <ZWpoKEcM0ZeYAsBa@dell-precision-5540>
 <9aa5e049-bd1c-41a6-b9b8-037ebb4f54b8@sirena.org.uk>
Message-ID: <ZW4uWBpEc2_4JR2b@dell-precision-5540>

On Mon, Dec 04, 2023 at 12:43:42PM +0000, Mark Brown wrote:
> On Fri, Dec 01, 2023 at 06:11:36PM -0500, Ben Wolsieffer wrote:
> > On Fri, Dec 01, 2023 at 09:50:33PM +0000, Mark Brown wrote:
> > > On Fri, Dec 01, 2023 at 04:40:14PM -0500, Ben Wolsieffer wrote:
> 
> > > This feels like it'd be a good fit for moving to runtime PM - that way
> > > we avoid bouncing the controller on and off between messages which is
> > > probably better anyway.  The driver already does pinctrl management for
> > > the device there.
> 
> > Yes, that probably makes sense. There are a few bits that can only be
> > configured while the controller is disabled, but it doesn't look like
> > that applies to any of the ones set in stm32_spi_prepare_msg().
> 
> > I'm a little hesitant to make big changes to the driver since I can only
> > test them on an STM32F7 though.
> 
> It doesn't seem much more complex than what you're already proposing.

I'm working on a new patch that uses runtime PM and will submit it soon.

> > > It also occurs to me that this isn't going to work for devices which
> > > chip select inverted - for them we can't stop driving chip select at all
> > > since they need it held high when idle.  There aren't that many such
> > > devices and it'd loose us the PM which is rather awkward...  I guess
> > > that's an incremental issue with a more invasive fix though.
> 
> > The driver only supports GPIO chip select rather than native, so I don't
> > think this is a problem. Also, I don't think there's any difference
> 
> So mentioning the drive seems a bit confusing then?

Yes, I should have been more specific in the patch that only MOSI and
CLK float when the controller is disabled and that CS remains driven.



From nathan at kernel.org  Mon Dec  4 11:59:06 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Mon, 4 Dec 2023 12:59:06 -0700
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error:
 instruction variant requires ARMv6 or later
In-Reply-To: <ZW4Zx4olPp0Owz0a@shell.armlinux.org.uk>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
 <20231204181304.GA2043538@dev-arch.thelio-3990X>
 <ZW4Zx4olPp0Owz0a@shell.armlinux.org.uk>
Message-ID: <20231204195906.GA2045328@dev-arch.thelio-3990X>

On Mon, Dec 04, 2023 at 06:26:15PM +0000, Russell King (Oracle) wrote:
> On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote:
> > Hi Naresh,
> > 
> > On Mon, Dec 04, 2023 at 05:33:26PM +0530, Naresh Kamboju wrote:
> > > Following build errors noticed on Linux next-20231204 tag with clang-nightly
> > > for arm and arm64.
> > > 
> > > ## Test Regressions (compared to next-20231201)
> > > * arm64, build
> > >   - clang-nightly-defconfig
> > >   - clang-nightly-defconfig-40bc7ee5
> > >   - clang-nightly-lkftconfig
> > >   - clang-nightly-lkftconfig-kselftest
> > > 
> > > * arm, build
> > >   - clang-nightly-allnoconfig
> > >   - clang-nightly-axm55xx_defconfig
> > >   - clang-nightly-bcm2835_defconfig
> > >   - clang-nightly-clps711x_defconfig
> > >   - clang-nightly-defconfig
> > >   - clang-nightly-exynos_defconfig
> > >   - clang-nightly-imx_v6_v7_defconfig
> > >   - clang-nightly-keystone_defconfig
> > >   - clang-nightly-lkftconfig
> > >   - clang-nightly-lkftconfig-kselftest
> > >   - clang-nightly-omap2plus_defconfig
> > >   - clang-nightly-pxa910_defconfig
> > >   - clang-nightly-s3c6400_defconfig
> > >   - clang-nightly-s5pv210_defconfig
> > >   - clang-nightly-sama5_defconfig
> > >   - clang-nightly-shmobile_defconfig
> > >   - clang-nightly-tinyconfig
> > >   - clang-nightly-u8500_defconfig
> > >   - clang-nightly-vexpress_defconfig
> > > 
> > > 
> > > Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
> > > 
> > > 
> > > Build log on arm64:
> > > ---------
> > > In file included from lib/vdso/gettimeofday.c:5:
> > > In file included from include/vdso/datapage.h:135:
> > > arch/arm64/include/asm/vdso/compat_gettimeofday.h:152:15: error:
> > > instruction variant requires ARMv6 or later
> > >   152 |         asm volatile("mov %0, %1" : "=r"(ret) : "r"(_vdso_data));
> > >       |                      ^
> > > <inline asm>:1:2: note: instantiated into assembly here
> > >     1 |         mov r4, r1
> > >       |         ^
> 
> I have to wonder why Clang is complaining about "mov r4, r1" because
> that certainly should not require "ARMv6 or later". On the face of it,
> this to me looks like a bug in Clang.

This is because the compat vDSO is compiled with '-mthumb' by default
and Nick helpfully pointed out on IRC that prior to ARMv6, one of the
operands to the mov had to be a HI register, which I do see in the ARM:

  Encoding T1     ARMv6*, ARMv7 if <Rd> and <Rm> both from R0-R7
                  ARMv4T, ARMv5T*, ARMv6*, ARMv7 otherwise
  MOV<c> <Rd>, <Rm>

Cheers,
Nathan


From zajec5 at gmail.com  Mon Dec  4 12:09:05 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon,  4 Dec 2023 21:09:05 +0100
Subject: [PATCH V2 1/3] dt-bindings: vendor-prefixes: add acelink
Message-ID: <20231204200907.5687-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Acelink is a Taiwan company providing network products (routers, access
points, switches, cameras and more).

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c8..503a3caf6fc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -39,6 +39,8 @@ patternProperties:
     description: ShenZhen Asia Better Technology Ltd.
   "^acbel,.*":
     description: Acbel Polytech Inc.
+  "^acelink,.*":
+    description: Acelink Technology Co., Ltd.
   "^acer,.*":
     description: Acer Inc.
   "^acme,.*":
-- 
2.35.3



From zajec5 at gmail.com  Mon Dec  4 12:09:06 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon,  4 Dec 2023 21:09:06 +0100
Subject: [PATCH V2 2/3] dt-bindings: arm64: dts: mediatek: Add Acelink EW-7886CAX access point
In-Reply-To: <20231204200907.5687-1-zajec5@gmail.com>
References: <20231204200907.5687-1-zajec5@gmail.com>
Message-ID: <20231204200907.5687-2-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index a5999b3afc35..cfdd3317edda 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -84,6 +84,7 @@ properties:
           - const: mediatek,mt7629
       - items:
           - enum:
+              - acelink,ew-7886cax
               - bananapi,bpi-r3
               - mediatek,mt7986a-rfb
           - const: mediatek,mt7986a
-- 
2.35.3



From zajec5 at gmail.com  Mon Dec  4 12:09:07 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon,  4 Dec 2023 21:09:07 +0100
Subject: [PATCH V2 3/3] arm64: dts: mediatek: Add Acelink EW-7886CAX
In-Reply-To: <20231204200907.5687-1-zajec5@gmail.com>
References: <20231204200907.5687-1-zajec5@gmail.com>
Message-ID: <20231204200907.5687-3-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point.
It has 512 MiB of RAM, one 2.5 Gbps PoE (802.3at) Ethernet port and
on-SoC Wi-Fi.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
V2: Update coding style to follow:
    [PATCH v4] docs: dt-bindings: add DTS Coding Style document

 arch/arm64/boot/dts/mediatek/Makefile         |   1 +
 .../mediatek/mt7986a-acelink-ew-7886cax.dts   | 173 ++++++++++++++++++
 2 files changed, 174 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index e6e7592a3645..9ff2ab6c5e4d 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-acelink-ew-7886cax.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nand.dtbo
diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts b/arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts
new file mode 100644
index 000000000000..93b71465bbdf
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+
+#include "mt7986a.dtsi"
+
+/ {
+	compatible = "acelink,ew-7886cax", "mediatek,mt7986a";
+	model = "Acelink EW-7886CAX";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory at 40000000 {
+		reg = <0 0x40000000 0 0x20000000>;
+		device_type = "memory";
+	};
+
+	keys {
+		compatible = "gpio-keys";
+
+		key-restart {
+			label = "Reset";
+			gpios = <&pio 7 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_RESTART>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			function = LED_FUNCTION_STATUS;
+			color = <LED_COLOR_ID_RED>;
+			gpios = <&pio 18 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-1 {
+			function = LED_FUNCTION_STATUS;
+			color = <LED_COLOR_ID_GREEN>;
+			gpios = <&pio 19 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-2 {
+			function = LED_FUNCTION_STATUS;
+			color = <LED_COLOR_ID_BLUE>;
+			gpios = <&pio 20 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+&crypto {
+	status = "okay";
+};
+
+&eth {
+	status = "okay";
+
+	mac at 1 {
+		compatible = "mediatek,eth-mac";
+		reg = <1>;
+		phy-mode = "2500base-x";
+		phy-handle = <&phy6>;
+		nvmem-cells = <&macaddr>;
+		nvmem-cell-names = "mac-address";
+	};
+
+	mdio-bus {
+		reset-gpios = <&pio 6 GPIO_ACTIVE_LOW>;
+		reset-delay-us = <50000>;
+		reset-post-delay-us = <20000>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy6: phy at 6 {
+			compatible = "ethernet-phy-ieee802.3-c45";
+			reg = <6>;
+		};
+	};
+};
+
+&pcie_phy {
+	status = "okay";
+};
+
+&spi0 {
+	status = "okay";
+
+	flash at 0 {
+		compatible = "spi-nand";
+		reg = <0>;
+		#address-cells = <1>;
+		#size-cells = <1>
+		spi-max-frequency = <52000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
+
+		partitions: partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition at 0 {
+				reg = <0x0 0x100000>;
+				label = "bootloader";
+				read-only;
+			};
+
+			partition at 100000 {
+				reg = <0x100000 0x80000>;
+				label = "u-boot-env";
+			};
+
+			partition at 180000 {
+				compatible = "nvmem-cells";
+				reg = <0x180000 0x200000>;
+				label = "factory";
+				read-only;
+
+				nvmem-layout {
+					compatible = "fixed-layout";
+					#address-cells = <1>;
+					#size-cells = <1>;
+
+					eeprom: eeprom at 0 {
+						reg = <0x0 0x1000>;
+					};
+
+					macaddr: macaddr at 4 {
+						reg = <0x4 0x6>;
+					};
+				};
+			};
+
+			partition at 380000 {
+				reg = <0x380000 0x200000>;
+				label = "fip";
+			};
+
+			partition at 580000 {
+				reg = <0x580000 0x4000000>;
+				label = "ubi";
+			};
+		};
+	};
+};
+
+&trng {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&watchdog {
+	status = "okay";
+};
+
+&wifi {
+	nvmem-cells = <&eeprom>;
+	nvmem-cell-names = "eeprom";
+	status = "okay";
+};
-- 
2.35.3



From dsimic at manjaro.org  Mon Dec  4 12:10:14 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Mon, 04 Dec 2023 21:10:14 +0100
Subject: [PATCH v1 1/2] ARM: dts: rockchip: add gpio alias for gpio dt
 nodes
In-Reply-To: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
References: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
Message-ID: <8787c5328e4ce368d35c8aa376c528d0@manjaro.org>

On 2023-12-02 19:22, Johan Jonker wrote:
> Rockchip SoC TRM, SoC datasheet and board schematics always refer to
> the same gpio numbers - even if not all are used for a specific board.
> In order to not have to re-define them for every board add the
> aliases to SoC dtsi files.
> 
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>

Reviewed-by: Dragan Simic <dsimic at manjaro.org>

> ---
> 
> Changed V1:
>   rebase
>   remove rk3066 gpio5 alias
> ---
>  arch/arm/boot/dts/rockchip/rk3036.dtsi  | 3 +++
>  arch/arm/boot/dts/rockchip/rk3066a.dtsi | 5 +++++
>  arch/arm/boot/dts/rockchip/rk322x.dtsi  | 4 ++++
>  arch/arm/boot/dts/rockchip/rk3288.dtsi  | 9 +++++++++
>  arch/arm/boot/dts/rockchip/rk3xxx.dtsi  | 4 ++++
>  5 files changed, 25 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi
> b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> index 78686fc72ce6..8aa2e0864fed 100644
> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> @@ -17,6 +17,9 @@ / {
>  	interrupt-parent = <&gic>;
> 
>  	aliases {
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
>  		i2c0 = &i2c0;
>  		i2c1 = &i2c1;
>  		i2c2 = &i2c2;
> diff --git a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> index de9915d946f7..30139f21de64 100644
> --- a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> @@ -13,6 +13,11 @@
>  / {
>  	compatible = "rockchip,rk3066a";
> 
> +	aliases {
> +		gpio4 = &gpio4;
> +		gpio6 = &gpio6;
> +	};
> +
>  	cpus {
>  		#address-cells = <1>;
>  		#size-cells = <0>;
> diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi
> b/arch/arm/boot/dts/rockchip/rk322x.dtsi
> index a721744cbfd1..831561fc1814 100644
> --- a/arch/arm/boot/dts/rockchip/rk322x.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk322x.dtsi
> @@ -15,6 +15,10 @@ / {
>  	interrupt-parent = <&gic>;
> 
>  	aliases {
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
>  		serial0 = &uart0;
>  		serial1 = &uart1;
>  		serial2 = &uart2;
> diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi
> b/arch/arm/boot/dts/rockchip/rk3288.dtsi
> index cb9cdaddffd4..ead343dc3df1 100644
> --- a/arch/arm/boot/dts/rockchip/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3288.dtsi
> @@ -19,6 +19,15 @@ / {
> 
>  	aliases {
>  		ethernet0 = &gmac;
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
> +		gpio4 = &gpio4;
> +		gpio5 = &gpio5;
> +		gpio6 = &gpio6;
> +		gpio7 = &gpio7;
> +		gpio8 = &gpio8;
>  		i2c0 = &i2c0;
>  		i2c1 = &i2c1;
>  		i2c2 = &i2c2;
> diff --git a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> index cb4e42ede56a..f37137f298d5 100644
> --- a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> @@ -16,6 +16,10 @@ / {
> 
>  	aliases {
>  		ethernet0 = &emac;
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
>  		i2c0 = &i2c0;
>  		i2c1 = &i2c1;
>  		i2c2 = &i2c2;
> --
> 2.39.2
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


From dsimic at manjaro.org  Mon Dec  4 12:10:39 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Mon, 04 Dec 2023 21:10:39 +0100
Subject: [PATCH v1 2/2] arm64: dts: rockchip: add gpio alias for gpio dt
 nodes
In-Reply-To: <56daeead-1d35-44bb-00c0-614b84a986de@gmail.com>
References: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
 <56daeead-1d35-44bb-00c0-614b84a986de@gmail.com>
Message-ID: <87fcf1ed7d10c879bb0c8aa44f004dd5@manjaro.org>

On 2023-12-02 19:22, Johan Jonker wrote:
> Rockchip SoC TRM, SoC datasheet and board schematics always refer to
> the same gpio numbers - even if not all are used for a specific board.
> In order to not have to re-define them for every board add the
> aliases to SoC dtsi files.
> 
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>

Reviewed-by: Dragan Simic <dsimic at manjaro.org>

> ---
>  arch/arm64/boot/dts/rockchip/rk3308.dtsi | 5 +++++
>  arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++++
>  arch/arm64/boot/dts/rockchip/rk3368.dtsi | 4 ++++
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
>  4 files changed, 18 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> index 2ae4bb7d5e62..cfc0a87b5195 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> @@ -20,6 +20,11 @@ / {
>  	#size-cells = <2>;
> 
>  	aliases {
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
> +		gpio4 = &gpio4;
>  		i2c0 = &i2c0;
>  		i2c1 = &i2c1;
>  		i2c2 = &i2c2;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index e18f7c1c0724..76ea18bf11a0 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -20,6 +20,10 @@ / {
>  	#size-cells = <2>;
> 
>  	aliases {
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
>  		serial0 = &uart0;
>  		serial1 = &uart1;
>  		serial2 = &uart2;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> index a4c5aaf1f457..fc7e3f2bc786 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> @@ -20,6 +20,10 @@ / {
> 
>  	aliases {
>  		ethernet0 = &gmac;
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
>  		i2c0 = &i2c0;
>  		i2c1 = &i2c1;
>  		i2c2 = &i2c2;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index da0dfb237f85..dec2705d035d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -20,6 +20,11 @@ / {
> 
>  	aliases {
>  		ethernet0 = &gmac;
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
> +		gpio4 = &gpio4;
>  		i2c0 = &i2c0;
>  		i2c1 = &i2c1;
>  		i2c2 = &i2c2;
> --
> 2.39.2
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


From ben.wolsieffer at hefring.com  Mon Dec  4 12:20:55 2023
From: ben.wolsieffer at hefring.com (Ben Wolsieffer)
Date: Mon,  4 Dec 2023 15:20:55 -0500
Subject: [PATCH] spi: stm32: use runtime PM to enable/disable controller
Message-ID: <20231204202055.2895125-1-ben.wolsieffer@hefring.com>

Instead of disabling the SPI controller between each message, do it
as part of runtime PM.

The primary motivation for this change is that, on the STM32F4/7, the
MOSI and CLK pins float while the controller is disabled. CS is a
regular GPIO, and therefore always driven. Currently, the controller is
enabled in the transfer_one() callback, which runs after CS is asserted.
Therefore, there is a period where the SPI pins are floating while CS is
asserted, making it possible for stray signals to disrupt
communications. An analogous problem occurs at the end of the transfer
when the controller is disabled before CS is released.

This problem can be reliably observed by enabling the pull-up (if
CPOL=0) or pull-down (if CPOL=1) on the clock pin. This will cause two
extra unintended clock edges per transfer, when the controller is
enabled and disabled.

Note that this bug is likely not present on the STM32H7, because it
supports the AFCNTR bit (and this driver sets it), which keeps the SPI
pins driven even while the controller is disabled.

Additionally, not constantly enabling/disabling the controller should
slightly improve performance.

With this change, spi->cfg->config(spi) will be called as part of
runtime PM resume, rather than just during system resume. This was done
because this function must be called with the controller disabled, which
is no longer the case after runtime resume. The overhead of these extra
calls should be minimal.

This patch has been tested on an STM32F746 with a MAX14830 UART
expander.

Signed-off-by: Ben Wolsieffer <ben.wolsieffer at hefring.com>
---
Discussion of my original proposed fix for this bug:
https://lore.kernel.org/lkml/ZWpoKEcM0ZeYAsBa at dell-precision-5540/T/

 drivers/spi/spi-stm32.c | 60 +++++++++--------------------------------
 1 file changed, 12 insertions(+), 48 deletions(-)

diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index c831f992c8a0..25d0757278fa 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -947,10 +947,8 @@ static irqreturn_t stm32fx_spi_irq_event(int irq, void *dev_id)
 static irqreturn_t stm32fx_spi_irq_thread(int irq, void *dev_id)
 {
 	struct spi_controller *ctrl = dev_id;
-	struct stm32_spi *spi = spi_controller_get_devdata(ctrl);
 
 	spi_finalize_current_transfer(ctrl);
-	stm32fx_spi_disable(spi);
 
 	return IRQ_HANDLED;
 }
@@ -1134,7 +1132,6 @@ static void stm32fx_spi_dma_tx_cb(void *data)
 
 	if (spi->cur_comm == SPI_SIMPLEX_TX || spi->cur_comm == SPI_3WIRE_TX) {
 		spi_finalize_current_transfer(spi->ctrl);
-		stm32fx_spi_disable(spi);
 	}
 }
 
@@ -1149,7 +1146,6 @@ static void stm32_spi_dma_rx_cb(void *data)
 	struct stm32_spi *spi = data;
 
 	spi_finalize_current_transfer(spi->ctrl);
-	spi->cfg->disable(spi);
 }
 
 /**
@@ -1234,8 +1230,6 @@ static int stm32fx_spi_transfer_one_irq(struct stm32_spi *spi)
 
 	stm32_spi_set_bits(spi, STM32FX_SPI_CR2, cr2);
 
-	stm32_spi_enable(spi);
-
 	/* starting data transfer when buffer is loaded */
 	if (spi->tx_buf)
 		spi->cfg->write_tx(spi);
@@ -1272,8 +1266,6 @@ static int stm32h7_spi_transfer_one_irq(struct stm32_spi *spi)
 
 	spin_lock_irqsave(&spi->lock, flags);
 
-	stm32_spi_enable(spi);
-
 	/* Be sure to have data in fifo before starting data transfer */
 	if (spi->tx_buf)
 		stm32h7_spi_write_txfifo(spi);
@@ -1305,8 +1297,6 @@ static void stm32fx_spi_transfer_one_dma_start(struct stm32_spi *spi)
 		 */
 		stm32_spi_set_bits(spi, STM32FX_SPI_CR2, STM32FX_SPI_CR2_ERRIE);
 	}
-
-	stm32_spi_enable(spi);
 }
 
 /**
@@ -1340,8 +1330,6 @@ static void stm32h7_spi_transfer_one_dma_start(struct stm32_spi *spi)
 
 	stm32_spi_set_bits(spi, STM32H7_SPI_IER, ier);
 
-	stm32_spi_enable(spi);
-
 	if (STM32_SPI_MASTER_MODE(spi))
 		stm32_spi_set_bits(spi, STM32H7_SPI_CR1, STM32H7_SPI_CR1_CSTART);
 }
@@ -1786,21 +1774,6 @@ static int stm32_spi_transfer_one(struct spi_controller *ctrl,
 		return spi->cfg->transfer_one_irq(spi);
 }
 
-/**
- * stm32_spi_unprepare_msg - relax the hardware
- * @ctrl: controller interface
- * @msg: pointer to the spi message
- */
-static int stm32_spi_unprepare_msg(struct spi_controller *ctrl,
-				   struct spi_message *msg)
-{
-	struct stm32_spi *spi = spi_controller_get_devdata(ctrl);
-
-	spi->cfg->disable(spi);
-
-	return 0;
-}
-
 /**
  * stm32fx_spi_config - Configure SPI controller as SPI master
  * @spi: pointer to the spi controller data structure
@@ -1827,6 +1800,8 @@ static int stm32fx_spi_config(struct stm32_spi *spi)
 						 STM32FX_SPI_CR1_MSTR |
 						 STM32FX_SPI_CR1_SSM);
 
+	stm32_spi_enable(spi);
+
 	spin_unlock_irqrestore(&spi->lock, flags);
 
 	return 0;
@@ -1870,6 +1845,8 @@ static int stm32h7_spi_config(struct stm32_spi *spi)
 	stm32_spi_set_bits(spi, STM32H7_SPI_CR1, cr1);
 	stm32_spi_set_bits(spi, STM32H7_SPI_CFG2, cfg2);
 
+	stm32_spi_enable(spi);
+
 	spin_unlock_irqrestore(&spi->lock, flags);
 
 	return 0;
@@ -2066,7 +2043,6 @@ static int stm32_spi_probe(struct platform_device *pdev)
 	ctrl->use_gpio_descriptors = true;
 	ctrl->prepare_message = stm32_spi_prepare_msg;
 	ctrl->transfer_one = stm32_spi_transfer_one;
-	ctrl->unprepare_message = stm32_spi_unprepare_msg;
 	ctrl->flags = spi->cfg->flags;
 	if (STM32_SPI_DEVICE_MODE(spi))
 		ctrl->slave_abort = stm32h7_spi_device_abort;
@@ -2167,6 +2143,8 @@ static int __maybe_unused stm32_spi_runtime_suspend(struct device *dev)
 	struct spi_controller *ctrl = dev_get_drvdata(dev);
 	struct stm32_spi *spi = spi_controller_get_devdata(ctrl);
 
+	spi->cfg->disable(spi);
+
 	clk_disable_unprepare(spi->clk);
 
 	return pinctrl_pm_select_sleep_state(dev);
@@ -2182,7 +2160,11 @@ static int __maybe_unused stm32_spi_runtime_resume(struct device *dev)
 	if (ret)
 		return ret;
 
-	return clk_prepare_enable(spi->clk);
+	ret = clk_prepare_enable(spi->clk);
+	if (ret)
+		return ret;
+
+	return spi->cfg->config(spi);
 }
 
 static int __maybe_unused stm32_spi_suspend(struct device *dev)
@@ -2200,31 +2182,13 @@ static int __maybe_unused stm32_spi_suspend(struct device *dev)
 static int __maybe_unused stm32_spi_resume(struct device *dev)
 {
 	struct spi_controller *ctrl = dev_get_drvdata(dev);
-	struct stm32_spi *spi = spi_controller_get_devdata(ctrl);
 	int ret;
 
 	ret = pm_runtime_force_resume(dev);
 	if (ret)
 		return ret;
 
-	ret = spi_controller_resume(ctrl);
-	if (ret) {
-		clk_disable_unprepare(spi->clk);
-		return ret;
-	}
-
-	ret = pm_runtime_resume_and_get(dev);
-	if (ret < 0) {
-		dev_err(dev, "Unable to power device:%d\n", ret);
-		return ret;
-	}
-
-	spi->cfg->config(spi);
-
-	pm_runtime_mark_last_busy(dev);
-	pm_runtime_put_autosuspend(dev);
-
-	return 0;
+	return spi_controller_resume(ctrl);
 }
 
 static const struct dev_pm_ops stm32_spi_pm_ops = {
-- 
2.42.1



From jbx6244 at gmail.com  Mon Dec  4 12:25:27 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 4 Dec 2023 21:25:27 +0100
Subject: [PATCH v1 3/3] ARM: dts: rockchip: rk3036-kylin: add
 hdmi-connector node
In-Reply-To: <447b1bde-584f-4eb4-8bfb-9abd3aa8b6fa@gmail.com>
References: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
 <f5bc182b-f9b6-26a8-8649-19ce33e3c0e1@gmail.com>
 <447b1bde-584f-4eb4-8bfb-9abd3aa8b6fa@gmail.com>
Message-ID: <bdda61be-8e02-36f5-6261-37d4b75278ba@gmail.com>

Hi Alex, Heiko,

On 12/4/23 20:12, Alex Bee wrote:
> Hi Johan,
> Am 04.12.23 um 18:40 schrieb Johan Jonker:
>> Add hdmi-connector node to comply with the inno_hdmi binding.
>>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>> ---
>> ? arch/arm/boot/dts/rockchip/rk3036-kylin.dts | 17 +++++++++++++++++
>> ? 1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
>> index 67e1e04139e7..a213333be011 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
>> +++ b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
>> @@ -13,6 +13,17 @@ memory at 60000000 {
>> ????????? reg = <0x60000000 0x20000000>;
>> ????? };
>>
>> +??? hdmi_con: hdmi-con {
>> +??????? compatible = "hdmi-connector";
>> +??????? type = "c";


> According to [0], kylin has an A-Type HDMI port - so this should be
> ?+??????? type = "a";
> > [0] http://rockchip.wikidot.com/kylin

Not sure from the text or do I miss something...

I did look at that board picture before submitting.
Can be wrong, but to me it looks a smaller HDMI connector.

Does anyone have a Kylin picture from a different angle?
Or reference design?

Else apply and fix later? (Heiko ?)
Let me know.

Johan

> 
> Regards,
> Alex
>> +
>> +??????? port {
>> +??????????? hdmi_con_in: endpoint {
>> +??????????????? remote-endpoint = <&hdmi_out_con>;
>> +??????????? };
>> +??????? };
>> +??? };
>> +
>> ????? leds: gpio-leds {
>> ????????? compatible = "gpio-leds";
>>
>> @@ -110,6 +121,12 @@ &hdmi {
>> ????? status = "okay";
>> ? };
>>
>> +&hdmi_out {
>> +??? hdmi_out_con: endpoint {
>> +??????? remote-endpoint = <&hdmi_con_in>;
>> +??? };
>> +};
>> +
>> ? &i2c1 {
>> ????? clock-frequency = <400000>;
>>
>> -- 
>> 2.39.2
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 


From wahrenst at gmx.net  Mon Dec  4 12:27:54 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Mon, 4 Dec 2023 21:27:54 +0100
Subject: [PATCH V3 1/3] dt-bindings: usb: xhci: add support for BCM2711
In-Reply-To: <0f7fa9f1-2337-428f-8a76-a5b4cac30677@broadcom.com>
References: <20231202232217.89652-1-wahrenst@gmx.net>
 <20231202232217.89652-2-wahrenst@gmx.net>
 <20231203-chair-zen-afb8b280ca2f@spud>
 <20231203-traffic-aide-cb03afdb3546@spud>
 <7dd529a0-ebee-4f3b-879b-c7b1033cfdb9@gmx.net>
 <20231204-sevenfold-slashing-bb7ea3419c92@spud>
 <0f7fa9f1-2337-428f-8a76-a5b4cac30677@broadcom.com>
Message-ID: <c26b1792-567a-4156-8907-df3472f843eb@gmx.net>

Hi,

Am 04.12.23 um 18:49 schrieb Florian Fainelli:
> On 12/4/23 09:04, Conor Dooley wrote:
>> On Sun, Dec 03, 2023 at 05:56:24PM +0100, Stefan Wahren wrote:
>>> Hi,
>>>
>>> Am 03.12.23 um 12:11 schrieb Conor Dooley:
>>>> On Sun, Dec 03, 2023 at 11:06:43AM +0000, Conor Dooley wrote:
>>>>> On Sun, Dec 03, 2023 at 12:22:15AM +0100, Stefan Wahren wrote:
>>>>>> The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
>>>>>> but also requires a power domain.
>>>> Hmm
>>>> This & the driver change makes it look like your compatible setup
>>>> should
>>>> be `compatible = "brcm,bcm2711-xhci", "brcm,xhci-brcm-v2";.
>>> i don't have insight into the hardware, but the fact that the other
>>> Broadcom SoC didn't require a power domain before let me think we
>>> shouldn't do this. Otherwise this binding was broken before. But Justin
>>> and Florian could clarify this.
>
> That seems to me like the right approach, the XHCI controller in 2711
> is tied to a power domain, however that is not the case for other
> Broadcom STB SoCs.
before i send just another trial and error version of this series, this
what i understand:

diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
index 594ebb3ee432..6f8744d1ace7 100644
--- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
@@ -9,9 +9,6 @@ title: USB xHCI Controller
 ?maintainers:
 ?? - Mathias Nyman <mathias.nyman at intel.com>

-allOf:
-? - $ref: usb-xhci.yaml#
-
 ?properties:
 ?? compatible:
 ???? oneOf:
@@ -25,6 +22,11 @@ properties:
 ?????????????? - marvell,armada-380-xhci
 ?????????????? - marvell,armada-8k-xhci
 ?????????? - const: generic-xhci
+????? - description: Broadcom BCM2711 SoC
+??????? items:
+????????? - enum:
+????????????? - brcm,bcm2711-xhci
+????????? - const: brcm,xhci-brcm-v2
 ?????? - description: Broadcom STB SoCs with xHCI
 ???????? enum:
 ?????????? - brcm,xhci-brcm-v2
@@ -49,6 +51,9 @@ properties:
 ?????? - const: core
 ?????? - const: reg

+? power-domains:
+??? maxItems: 1
+
 ?unevaluatedProperties: false

 ?required:
@@ -56,6 +61,20 @@ required:
 ?? - reg
 ?? - interrupts

+allOf:
+? - $ref: usb-xhci.yaml#
+? - if:
+????? properties:
+??????? compatible:
+????????? contains:
+??????????? const: brcm,bcm2711-xhci
+??? then:
+????? required:
+??????? - power-domains
+??? else:
+????? properties:
+??????? power-domains: false
+
 ?examples:
 ?? - |
 ???? usb at f0931000 {




From sashal at kernel.org  Mon Dec  4 12:32:32 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  4 Dec 2023 15:32:32 -0500
Subject: [PATCH AUTOSEL 6.6 12/32] wifi: avoid offset calculation on NULL pointer
In-Reply-To: <20231204203317.2092321-1-sashal@kernel.org>
References: <20231204203317.2092321-1-sashal@kernel.org>
Message-ID: <20231204203317.2092321-12-sashal@kernel.org>

From: Michael-CY Lee <michael-cy.lee at mediatek.com>

[ Upstream commit ef5828805842204dd0259ecfc132b5916c8a77ae ]

ieee80211_he_6ghz_oper() can be passed a NULL pointer
and checks for that, but already did the calculation
to inside of it before. Move it after the check.

Signed-off-by: Michael-CY Lee <michael-cy.lee at mediatek.com>
Link: https://lore.kernel.org/r/20231122030237.31276-1-michael-cy.lee at mediatek.com
[rewrite commit message]
Signed-off-by: Johannes Berg <johannes.berg at intel.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 include/linux/ieee80211.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index b24fb80782c5a..6971bf16031f1 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -2790,12 +2790,14 @@ ieee80211_he_oper_size(const u8 *he_oper_ie)
 static inline const struct ieee80211_he_6ghz_oper *
 ieee80211_he_6ghz_oper(const struct ieee80211_he_operation *he_oper)
 {
-	const u8 *ret = (const void *)&he_oper->optional;
+	const u8 *ret;
 	u32 he_oper_params;
 
 	if (!he_oper)
 		return NULL;
 
+	ret = (const void *)&he_oper->optional;
+
 	he_oper_params = le32_to_cpu(he_oper->he_oper_params);
 
 	if (!(he_oper_params & IEEE80211_HE_OPERATION_6GHZ_OP_INFO))
-- 
2.42.0



From sashal at kernel.org  Mon Dec  4 12:34:51 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  4 Dec 2023 15:34:51 -0500
Subject: [PATCH AUTOSEL 6.1 06/17] wifi: avoid offset calculation on NULL pointer
In-Reply-To: <20231204203514.2093855-1-sashal@kernel.org>
References: <20231204203514.2093855-1-sashal@kernel.org>
Message-ID: <20231204203514.2093855-6-sashal@kernel.org>

From: Michael-CY Lee <michael-cy.lee at mediatek.com>

[ Upstream commit ef5828805842204dd0259ecfc132b5916c8a77ae ]

ieee80211_he_6ghz_oper() can be passed a NULL pointer
and checks for that, but already did the calculation
to inside of it before. Move it after the check.

Signed-off-by: Michael-CY Lee <michael-cy.lee at mediatek.com>
Link: https://lore.kernel.org/r/20231122030237.31276-1-michael-cy.lee at mediatek.com
[rewrite commit message]
Signed-off-by: Johannes Berg <johannes.berg at intel.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 include/linux/ieee80211.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 870ae4cd82029..dce105f67b4d8 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -2658,12 +2658,14 @@ ieee80211_he_oper_size(const u8 *he_oper_ie)
 static inline const struct ieee80211_he_6ghz_oper *
 ieee80211_he_6ghz_oper(const struct ieee80211_he_operation *he_oper)
 {
-	const u8 *ret = (const void *)&he_oper->optional;
+	const u8 *ret;
 	u32 he_oper_params;
 
 	if (!he_oper)
 		return NULL;
 
+	ret = (const void *)&he_oper->optional;
+
 	he_oper_params = le32_to_cpu(he_oper->he_oper_params);
 
 	if (!(he_oper_params & IEEE80211_HE_OPERATION_6GHZ_OP_INFO))
-- 
2.42.0



From ben.wolsieffer at hefring.com  Mon Dec  4 12:33:55 2023
From: ben.wolsieffer at hefring.com (Ben Wolsieffer)
Date: Mon,  4 Dec 2023 15:33:55 -0500
Subject: [PATCH 0/2] stm32: fix GPIO level interrupts
Message-ID: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>

GPIO level interrupts on the STM32 were behaving like edge interrupts.
The STM32 lacks hardware support for GPIO level interrupts, therefore
the pinctrl driver contains code to emulate them using edge interrupts,
but this was not working.

First, the STM32 EXTI interrupt controller driver lacked support for
retriggering interrupts, and second, the wrong IRQ handler was being
used because the parent interrupt was an edge interrupt.

Ben Wolsieffer (2):
  irqchip/stm32-exti: support retriggering on STM32 MCUs
  pinctrl: stm32: fix GPIO level interrupts

 drivers/irqchip/irq-stm32-exti.c      | 13 +++++++++++++
 drivers/pinctrl/stm32/pinctrl-stm32.c |  3 +++
 2 files changed, 16 insertions(+)

-- 
2.42.1



From ben.wolsieffer at hefring.com  Mon Dec  4 12:33:56 2023
From: ben.wolsieffer at hefring.com (Ben Wolsieffer)
Date: Mon,  4 Dec 2023 15:33:56 -0500
Subject: [PATCH 1/2] irqchip/stm32-exti: support retriggering on STM32 MCUs
In-Reply-To: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>
References: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>
Message-ID: <20231204203357.2897008-2-ben.wolsieffer@hefring.com>

EXTI retriggering support was missing on STM32 MCUs. Retriggering is
required to emulate GPIO level interrupts using edge interrupts in the
STM32 pinctrl driver.

Signed-off-by: Ben Wolsieffer <ben.wolsieffer at hefring.com>
---
 drivers/irqchip/irq-stm32-exti.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
index 971240e2e31b..6b3f54457812 100644
--- a/drivers/irqchip/irq-stm32-exti.c
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -328,6 +328,18 @@ static void stm32_irq_handler(struct irq_desc *desc)
 	chained_irq_exit(chip, desc);
 }
 
+static int stm32_irq_retrigger(struct irq_data *d)
+{
+	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+	struct stm32_exti_chip_data *chip_data = gc->private;
+	const struct stm32_exti_bank *stm32_bank = chip_data->reg_bank;
+	u32 mask = BIT(d->hwirq % IRQS_PER_BANK);
+
+	irq_reg_writel(gc, mask, stm32_bank->swier_ofst);
+
+	return 0;
+}
+
 static int stm32_exti_set_type(struct irq_data *d,
 			       unsigned int type, u32 *rtsr, u32 *ftsr)
 {
@@ -856,6 +868,7 @@ static int __init stm32_exti_init(const struct stm32_exti_drv_data *drv_data,
 		gc->chip_types->chip.irq_ack = stm32_irq_ack;
 		gc->chip_types->chip.irq_mask = irq_gc_mask_clr_bit;
 		gc->chip_types->chip.irq_unmask = irq_gc_mask_set_bit;
+		gc->chip_types->chip.irq_retrigger = stm32_irq_retrigger;
 		gc->chip_types->chip.irq_set_type = stm32_irq_set_type;
 		gc->chip_types->chip.irq_set_wake = irq_gc_set_wake;
 		gc->suspend = stm32_irq_suspend;
-- 
2.42.1



From ben.wolsieffer at hefring.com  Mon Dec  4 12:33:57 2023
From: ben.wolsieffer at hefring.com (Ben Wolsieffer)
Date: Mon,  4 Dec 2023 15:33:57 -0500
Subject: [PATCH 2/2] pinctrl: stm32: fix GPIO level interrupts
In-Reply-To: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>
References: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>
Message-ID: <20231204203357.2897008-3-ben.wolsieffer@hefring.com>

The STM32 doesn't support GPIO level interrupts in hardware, so the
driver tries to emulate them using edge interrupts, by retriggering the
interrupt if necessary based on the pin state after the handler
finishes.

Currently, this functionality does not work because the irqchip uses
handle_edge_irq(), which doesn't run the irq_eoi() or irq_unmask()
callbacks after handling the interrupt. This patch fixes this by using
handle_level_irq() for level interrupts, which causes irq_unmask() to be
called to retrigger the interrupt.

Signed-off-by: Ben Wolsieffer <ben.wolsieffer at hefring.com>
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 603f900e88c1..fb9532601cbb 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -348,12 +348,15 @@ static int stm32_gpio_set_type(struct irq_data *d, unsigned int type)
 	case IRQ_TYPE_EDGE_RISING:
 	case IRQ_TYPE_EDGE_FALLING:
 	case IRQ_TYPE_EDGE_BOTH:
+		irq_set_handler_locked(d, handle_edge_irq);
 		parent_type = type;
 		break;
 	case IRQ_TYPE_LEVEL_HIGH:
+		irq_set_handler_locked(d, handle_level_irq);
 		parent_type = IRQ_TYPE_EDGE_RISING;
 		break;
 	case IRQ_TYPE_LEVEL_LOW:
+		irq_set_handler_locked(d, handle_level_irq);
 		parent_type = IRQ_TYPE_EDGE_FALLING;
 		break;
 	default:
-- 
2.42.1



From conor at kernel.org  Mon Dec  4 12:42:47 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 4 Dec 2023 20:42:47 +0000
Subject: [PATCH V3 1/3] dt-bindings: usb: xhci: add support for BCM2711
In-Reply-To: <c26b1792-567a-4156-8907-df3472f843eb@gmx.net>
References: <20231202232217.89652-1-wahrenst@gmx.net>
 <20231202232217.89652-2-wahrenst@gmx.net>
 <20231203-chair-zen-afb8b280ca2f@spud>
 <20231203-traffic-aide-cb03afdb3546@spud>
 <7dd529a0-ebee-4f3b-879b-c7b1033cfdb9@gmx.net>
 <20231204-sevenfold-slashing-bb7ea3419c92@spud>
 <0f7fa9f1-2337-428f-8a76-a5b4cac30677@broadcom.com>
 <c26b1792-567a-4156-8907-df3472f843eb@gmx.net>
Message-ID: <20231204-specimen-overwrite-3e39b79293c0@spud>

On Mon, Dec 04, 2023 at 09:27:54PM +0100, Stefan Wahren wrote:
> Hi,
> 
> Am 04.12.23 um 18:49 schrieb Florian Fainelli:
> > On 12/4/23 09:04, Conor Dooley wrote:
> > > On Sun, Dec 03, 2023 at 05:56:24PM +0100, Stefan Wahren wrote:
> > > > Hi,
> > > > 
> > > > Am 03.12.23 um 12:11 schrieb Conor Dooley:
> > > > > On Sun, Dec 03, 2023 at 11:06:43AM +0000, Conor Dooley wrote:
> > > > > > On Sun, Dec 03, 2023 at 12:22:15AM +0100, Stefan Wahren wrote:
> > > > > > > The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
> > > > > > > but also requires a power domain.
> > > > > Hmm
> > > > > This & the driver change makes it look like your compatible setup
> > > > > should
> > > > > be `compatible = "brcm,bcm2711-xhci", "brcm,xhci-brcm-v2";.
> > > > i don't have insight into the hardware, but the fact that the other
> > > > Broadcom SoC didn't require a power domain before let me think we
> > > > shouldn't do this. Otherwise this binding was broken before. But Justin
> > > > and Florian could clarify this.
> > 
> > That seems to me like the right approach, the XHCI controller in 2711
> > is tied to a power domain, however that is not the case for other
> > Broadcom STB SoCs.
> before i send just another trial and error version of this series, this
> what i understand:
> 
> diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> index 594ebb3ee432..6f8744d1ace7 100644
> --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> @@ -9,9 +9,6 @@ title: USB xHCI Controller
> ?maintainers:
> ?? - Mathias Nyman <mathias.nyman at intel.com>
> 
> -allOf:
> -? - $ref: usb-xhci.yaml#
> -
> ?properties:
> ?? compatible:
> ???? oneOf:
> @@ -25,6 +22,11 @@ properties:
> ?????????????? - marvell,armada-380-xhci
> ?????????????? - marvell,armada-8k-xhci
> ?????????? - const: generic-xhci
> +????? - description: Broadcom BCM2711 SoC
> +??????? items:

The comment and enum here kinda contradict eachother.
I'd probably say "Broadcom SoCs with power domains" or just leave the
comment out altogether. But in general, yes. You can keep the tag.

Thanks,
Conor.

> +????????? - enum:
> +????????????? - brcm,bcm2711-xhci
> +????????? - const: brcm,xhci-brcm-v2
> ?????? - description: Broadcom STB SoCs with xHCI
> ???????? enum:
> ?????????? - brcm,xhci-brcm-v2
> @@ -49,6 +51,9 @@ properties:
> ?????? - const: core
> ?????? - const: reg
> 
> +? power-domains:
> +??? maxItems: 1
> +
> ?unevaluatedProperties: false
> 
> ?required:
> @@ -56,6 +61,20 @@ required:
> ?? - reg
> ?? - interrupts
> 
> +allOf:
> +? - $ref: usb-xhci.yaml#
> +? - if:
> +????? properties:
> +??????? compatible:
> +????????? contains:
> +??????????? const: brcm,bcm2711-xhci
> +??? then:
> +????? required:
> +??????? - power-domains
> +??? else:
> +????? properties:
> +??????? power-domains: false
> +
> ?examples:
> ?? - |
> ???? usb at f0931000 {
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231204/b4a7c579/attachment.sig>

From jbx6244 at gmail.com  Mon Dec  4 12:47:15 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 4 Dec 2023 21:47:15 +0100
Subject: [PATCH v1 1/3] dt-bindings: drm: rockchip: convert
 inno_hdmi-rockchip.txt to yaml
In-Reply-To: <3f235189-da75-4e9d-ad68-8cbebca12f6d@gmail.com>
References: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
 <3f235189-da75-4e9d-ad68-8cbebca12f6d@gmail.com>
Message-ID: <3331543a-73fb-3565-47c6-d3303c44ba21@gmail.com>

Hi,

On 12/4/23 19:56, Alex Bee wrote:
> Hi Johan,
> Am 04.12.23 um 18:39 schrieb Johan Jonker:
>> Convert inno_hdmi-rockchip.txt to yaml.
> Nice - I'm having something very similar on my queue :)
>>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>> ---
>>
>> Note for rob+dt:
>> ?? Used enum to "soon" be able to add "rockchip,rk3128-inno-hdmi"

> Yeah, actually I'm planning to submit it really soon (if timne allows).

;)

>>
>> Changed V1:
>> ?? Rename file to more common layout
>> ?? Add/fix hdmi_out port example
>> ---
>> ? .../display/rockchip/inno_hdmi-rockchip.txt?? |? 49 ---------
>> ? .../display/rockchip/rockchip,inno-hdmi.yaml? | 103 ++++++++++++++++++
>> ? 2 files changed, 103 insertions(+), 49 deletions(-)
>> ? delete mode 100644 Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>> ? create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>> deleted file mode 100644
>> index cec21714f0e0..000000000000
>> --- a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>> +++ /dev/null
>> @@ -1,49 +0,0 @@
>> -Rockchip specific extensions to the Innosilicon HDMI
>> -================================
>> -
>> -Required properties:
>> -- compatible:
>> -??? "rockchip,rk3036-inno-hdmi";
>> -- reg:
>> -??? Physical base address and length of the controller's registers.
>> -- clocks, clock-names:
>> -??? Phandle to hdmi controller clock, name should be "pclk"
>> -- interrupts:
>> -??? HDMI interrupt number
>> -- ports:
>> -??? Contain one port node with endpoint definitions as defined in
>> -??? Documentation/devicetree/bindings/graph.txt.
>> -- pinctrl-0, pinctrl-name:
>> -??? Switch the iomux of HPD/CEC pins to HDMI function.
>> -
>> -Example:
>> -hdmi: hdmi at 20034000 {
>> -??? compatible = "rockchip,rk3036-inno-hdmi";
>> -??? reg = <0x20034000 0x4000>;
>> -??? interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
>> -??? clocks = <&cru? PCLK_HDMI>;
>> -??? clock-names = "pclk";
>> -??? pinctrl-names = "default";
>> -??? pinctrl-0 = <&hdmi_ctl>;
>> -
>> -??? hdmi_in: port {
>> -??????? #address-cells = <1>;
>> -??????? #size-cells = <0>;
>> -??????? hdmi_in_lcdc: endpoint at 0 {
>> -??????????? reg = <0>;
>> -??????????? remote-endpoint = <&lcdc_out_hdmi>;
>> -??????? };
>> -??? };
>> -};
>> -
>> -&pinctrl {
>> -??? hdmi {
>> -??????? hdmi_ctl: hdmi-ctl {
>> -??????????? rockchip,pins = <1 8? RK_FUNC_1 &pcfg_pull_none>,
>> -??????????????????? <1 9? RK_FUNC_1 &pcfg_pull_none>,
>> -??????????????????? <1 10 RK_FUNC_1 &pcfg_pull_none>,
>> -??????????????????? <1 11 RK_FUNC_1 &pcfg_pull_none>;
>> -??????? };
>> -??? };
>> -
>> -};
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
>> new file mode 100644
>> index 000000000000..96889c86849a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
>> @@ -0,0 +1,103 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/rockchip/rockchip,inno-hdmi.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Rockchip Innosilicon HDMI controller
>> +
>> +maintainers:
>> +? - Sandy Huang <hjc at rock-chips.com>
>> +? - Heiko Stuebner <heiko at sntech.de>
>> +
>> +properties:
>> +? compatible:
>> +??? enum:
>> +????? - rockchip,rk3036-inno-hdmi
>> +
>> +? reg:
>> +??? maxItems: 1
>> +
>> +? interrupts:
>> +??? maxItems: 1
>> +
>> +? clocks:
>> +??? maxItems: 1

> The interrupts/clock description exists already in the txt-bindings - so how about:
> 
> +??? items:
> +????? - descrition: ....
>> +

It's not common to do so when there's only one clock and nothing special to mention.
Used this style for most of my conversions. 
Further rational might be given by Krzysztof and co.

>> +? clock-names:
>> +??? const: pclk
>> +
>> +? ports:
>> +??? $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +??? properties:
>> +????? port at 0:
>> +??????? $ref: /schemas/graph.yaml#/properties/port
>> +??????? description:
>> +????????? Port node with one endpoint connected to a vop node.
>> +
>> +????? port at 1:
>> +??????? $ref: /schemas/graph.yaml#/properties/port
>> +??????? description:
>> +????????? Port node with one endpoint connected to a hdmi-connector node.
>> +
>> +??? required:
>> +????? - port at 0
>> +????? - port at 1
>> +
>> +required:
>> +? - compatible
>> +? - reg
>> +? - interrupts
>> +? - clocks
>> +? - clock-names
>> +? - pinctrl-0
>> +? - pinctrl-names
>> +? - ports
>> +
>> +additionalProperties: false

> Did you check that with dtbs_check? RK3036's SoC dtsi also contains a
> 
> ?rockchip,grf = <&grf>;
> 
> and I'm not seeing this removed in this series.
> 

I did check. Currently grf is not used in a mainline driver and only in the Rockchip tree.
Choose to keep it as it is for now.

> It would be great if that would added here to as requirement
> for RK3036 too? (and updated in the example)
> Even if it is beyond a pure txt to yaml conversion: RK3036 needs to set HDMI polarities in GRF.

It's a good habit to do one action per patch. In this case we convert an exciting document.
Everyone is free to add further properties if needed.

Johan


> 
> Regards,
> Alex
>> +
>> +examples:
>> +? - |
>> +??? #include <dt-bindings/clock/rk3036-cru.h>
>> +??? #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +??? #include <dt-bindings/pinctrl/rockchip.h>
>> +??? hdmi: hdmi at 20034000 {
>> +????? compatible = "rockchip,rk3036-inno-hdmi";
>> +????? reg = <0x20034000 0x4000>;
>> +????? interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
>> +????? clocks = <&cru? PCLK_HDMI>;
>> +????? clock-names = "pclk";
>> +????? pinctrl-names = "default";
>> +????? pinctrl-0 = <&hdmi_ctl>;
>> +
>> +????? ports {
>> +??????? #address-cells = <1>;
>> +??????? #size-cells = <0>;
>> +
>> +??????? hdmi_in: port at 0 {
>> +????????? reg = <0>;
>> +????????? hdmi_in_vop: endpoint {
>> +??????????? remote-endpoint = <&vop_out_hdmi>;
>> +????????? };
>> +??????? };
>> +
>> +??????? hdmi_out: port at 1 {
>> +????????? reg = <1>;
>> +????????? hdmi_out_con: endpoint {
>> +??????????? remote-endpoint = <&hdmi_con_in>;
>> +????????? };
>> +??????? };
>> +????? };
>> +??? };
>> +
>> +??? pinctrl {
>> +????? hdmi {
>> +??????? hdmi_ctl: hdmi-ctl {
>> +????????? rockchip,pins = <1 RK_PB0 1 &pcfg_pull_none>,
>> +????????????????????????? <1 RK_PB1 1 &pcfg_pull_none>,
>> +????????????????????????? <1 RK_PB2 1 &pcfg_pull_none>,
>> +????????????????????????? <1 RK_PB3 1 &pcfg_pull_none>;
>> +??????? };
>> +????? };
>> +??? };
>> -- 
>> 2.39.2
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 


From ahalaney at redhat.com  Mon Dec  4 13:07:45 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Mon, 4 Dec 2023 15:07:45 -0600
Subject: [PATCH v2] net: stmmac: update Rx clk divider for 10M SGMII
In-Reply-To: <20231201100548.12994-1-quic_snehshah@quicinc.com>
References: <20231201100548.12994-1-quic_snehshah@quicinc.com>
Message-ID: <zf4fsrtrd736kxweputr2fulu7ffagivwi7zodctcsdg3uj6e2@iquglstf2gqb>

On Fri, Dec 01, 2023 at 03:35:48PM +0530, Sneh Shah wrote:
> SGMII 10MBPS mode needs RX clock divider to avoid drops in Rx.
> Update configure SGMII function with rx clk divider programming.
> 
> Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>

Tested-by: Andrew Halaney <ahalaney at redhat.com> # sa8775p-ride

I can confirm that without this patch traffic doesn't seem to work when
I force things in to SPEED_10 with ethtool (which required another
change to this driver in stmmac_ethtool.c to do so, which as far as I
understand Sarosh from your group will be upstreaming soon and is an
independent issue).

I am curious, I expected to see some dropped/errors output in ip link
when things weren't working. I guess the sgmii phy in the soc is
rejecting these prior to handing them to the mac? Or am I
misunderstanding how that works?

> ---
> v2 changelog:
> - Use FIELD_PREP to prepare bifield values in place of GENMASK
> - Add fixes tag
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index d3bf42d0fceb..df6ff8bcdb5c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -34,6 +34,7 @@
>  #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
>  #define RGMII_CONFIG_PROG_SWAP			BIT(1)
>  #define RGMII_CONFIG_DDR_MODE			BIT(0)
> +#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)
>  
>  /* SDCC_HC_REG_DLL_CONFIG fields */
>  #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
> @@ -617,6 +618,9 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  	case SPEED_10:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> +		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
> +			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR, 0x31),
> +			      RGMII_IO_MACRO_CONFIG);

Russell requested a comment about why you must program this every time,
I think it's a good idea too: https://lore.kernel.org/netdev/ZWch7LIqbMEaLRLW at shell.armlinux.org.uk/

Also on my wishlist is making 0x31 less magic, but Santa might not bring
that for me :)

>  		break;
>  	}
>  
> -- 
> 2.17.1
> 
> 



From nm at ti.com  Mon Dec  4 13:10:44 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:10:44 -0600
Subject: [PATCH] arm64: defconfig: Enable Toshiba TC358767 bridge
In-Reply-To: <20231030152834.18450-1-a-bhatia1@ti.com>
References: <20231030152834.18450-1-a-bhatia1@ti.com>
Message-ID: <170172423509.2630369.1879913027485559706.b4-ty@ti.com>

Hi Aradhya Bhatia,

On Mon, 30 Oct 2023 20:58:34 +0530, Aradhya Bhatia wrote:
> Siemens' SIMATIC IOT2050 platform[0], based on Texas Instruments' AM65x
> SoC[1], uses Toshiba TC358767[2] to convert DPI video to DisplayPort
> (DP) video ouput. The original DPI signals are generated by AM65x's
> Display SubSystem (DSS).
> 
> Toshiba TC358767 is also capable of other video format conversions, viz,
> DPI to (e)DP, DSI to (e)DP, and DSI to DPI.
> 
> [...]

I have applied the following to branch ti-k3-config-next on [1].
Thank you!

[1/1] arm64: defconfig: Enable Toshiba TC358767 bridge
      commit: 21a1989963b4c2d8530af9be41c4cc2f7d3b2ee8

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Mon Dec  4 13:11:06 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:11:06 -0600
Subject: [PATCH] arm64: defconfig: Enable TI_ICSSG_PRUETH
In-Reply-To: <20231128084537.3946895-1-danishanwar@ti.com>
References: <20231128084537.3946895-1-danishanwar@ti.com>
Message-ID: <170172425514.2630428.14565755849955786268.b4-ty@ti.com>

Hi MD Danish Anwar,

On Tue, 28 Nov 2023 14:15:37 +0530, MD Danish Anwar wrote:
> The Programmable Real-time Unit and Industrial Communication Subsystem
> Gigabit (PRU_ICSSG) is a low-latency microcontroller subsystem in the TI
> K3 SoCs such as AM654x, AM64x. This subsystem is provided for the use
> cases like implementation of custom peripheral interfaces, offloading of
> tasks from the other processor cores of the SoC, etc.
> 
> Currently AM654x-EVM uses ICSSG driver.
> 
> [...]

I have applied the following to branch ti-k3-config-next on [1].
Thank you!

[1/1] arm64: defconfig: Enable TI_ICSSG_PRUETH
      commit: 9fba6a55d2ff449e1d796fbda16520715158b1ee

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Mon Dec  4 13:11:58 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:11:58 -0600
Subject: [PATCH v3] arm64: defconfig: increase SERIAL_8250_NR_UARTS
In-Reply-To: <20231201195732.4931-1-francesco@dolcini.it>
References: <20231201195732.4931-1-francesco@dolcini.it>
Message-ID: <170172431132.2630525.9449114798176700175.b4-ty@ti.com>

Hi Francesco Dolcini,

On Fri, 01 Dec 2023 20:57:32 +0100, Francesco Dolcini wrote:
> Increase CONFIG_SERIAL_8250_NR_UARTS from 4 to 8, the current legacy value
> is not adequate for embedded systems that use SoCs where it's common to
> have a large number of serial ports.
> 
> No need to change CONFIG_SERIAL_8250_RUNTIME_UARTS, see commit 9d86719f8769
> ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS").
> 
> [...]

I have applied the following to branch ti-k3-config-next on [1].
Thank you!

[1/1] arm64: defconfig: increase SERIAL_8250_NR_UARTS
      commit: 7bb7d31d9e454fc0b13cb0df44c2b4d953b4a152

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Mon Dec  4 13:12:35 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:12:35 -0600
Subject: [PATCH] arm64: dts: ti: k3-am62a7-sk: Add interrupt support for IO Expander
In-Reply-To: <20231108191652.1118155-1-a-bhatia1@ti.com>
References: <20231108191652.1118155-1-a-bhatia1@ti.com>
Message-ID: <170172434163.2630706.1317896620817721868.b4-ty@ti.com>

Hi Aradhya Bhatia,

On Thu, 09 Nov 2023 00:46:52 +0530, Aradhya Bhatia wrote:
> The Hot Plug Detect (HPD) signal for the HDMI display travels from the
> on-board HDMI connector, through the IO Expander 1, and finally to the
> main_gpio1 line #23, of the SoC.
> 
> Add interrupt information for the IO Expander 1 (exp1).
> Also add pinmux info of main gpio 1, line #23.
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: ti: k3-am62a7-sk: Add interrupt support for IO Expander
      commit: e57ba268254bda25a3ddca8b7971d6ad8277e2d8

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Mon Dec  4 13:12:51 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:12:51 -0600
Subject: [PATCH 1/5] arm64: dts: ti: k3-j7200: Add chipid node to wkup_conf bus
In-Reply-To: <20231117140910.8747-1-afd@ti.com>
References: <20231117140910.8747-1-afd@ti.com>
Message-ID: <170172436341.2630814.4304040849762838946.b4-ty@ti.com>

Hi Andrew Davis,

On Fri, 17 Nov 2023 08:09:06 -0600, Andrew Davis wrote:
> Like in other K3 SoCs the chipid register is inside the wakeup
> configuration space. Move the chipid node under a new bus to
> better represent this topology and match other similar SoCs.
> 
> 

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/5] arm64: dts: ti: k3-j7200: Add chipid node to wkup_conf bus
      commit: 82277ed7db29296a2907eab91934c26c405db604
[2/5] arm64: dts: ti: k3-j784s4: Add chipid node to wkup_conf bus
      commit: 3dc5bd24181af7eb90ad764c3b303f697ebf5e87
[3/5] arm64: dts: ti: k3-j721s2: Add chipid node to wkup_conf bus
      commit: 1026355c21ebe9f7af3bb0a9422bc572c9f4ac91
[4/5] arm64: dts: ti: k3-am65: Add chipid node to wkup_conf bus
      commit: 8121e93102b0e09ff1d9589659a823b2271acf62
[5/5] arm64: dts: ti: k3-j721e: Add chipid node to wkup_conf bus
      commit: 27e5b7330fe31d0aae196f26cf251254f2b923bb

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Mon Dec  4 13:13:05 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:13:05 -0600
Subject: [PATCH v3] arm64: dts: ti: k3-am65: Add full compatible to dss-oldi-io-ctrl node
In-Reply-To: <20231117141433.9461-1-afd@ti.com>
References: <20231117141433.9461-1-afd@ti.com>
Message-ID: <170172437880.2630920.3394696212504659512.b4-ty@ti.com>

Hi Andrew Davis,

On Fri, 17 Nov 2023 08:14:33 -0600, Andrew Davis wrote:
> This matches the binding for this register region which fixes a couple
> DTS check warnings.
> 
> While here trim the leading 0s from the "reg" definition.
> 
> 

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: ti: k3-am65: Add full compatible to dss-oldi-io-ctrl node
      commit: 1a4402e14fa8fa166cd4afd435b903c7867eb7d5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Mon Dec  4 13:13:33 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:13:33 -0600
Subject: [PATCH v1] arm64: dts: k3-am625-verdin: enable Verdin UART2
In-Reply-To: <20231121160436.1032364-1-parth105105@gmail.com>
References: <20231121160436.1032364-1-parth105105@gmail.com>
Message-ID: <170172440234.2631029.8734643954913883636.b4-ty@ti.com>

Hi Parth Pancholi,

On Tue, 21 Nov 2023 17:04:36 +0100, Parth Pancholi wrote:
> Enable UART2 for AM62 based SOM's Verdin carrier boards Dahlia,
> Development and Yavia.
> Earlier Verdin UART2 was reserved by R5 DM firmware which can be now
> configured using boardcfg during U-boot compilation in the latest TI
> SDKs. In a default config, no one writes to this UART.
> 
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: k3-am625-verdin: enable Verdin UART2
      commit: 26e0124683c000c2a197204e0fdc68e553298bff

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Mon Dec  4 13:13:50 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:13:50 -0600
Subject: [PATCH 1/2] arm64: dts: ti: k3-am65: Enable SDHCI nodes at the board level
In-Reply-To: <20231117163339.89952-1-afd@ti.com>
References: <20231117163339.89952-1-afd@ti.com>
Message-ID: <170172442057.2631270.18215070503834918216.b4-ty@ti.com>

Hi Andrew Davis,

On Fri, 17 Nov 2023 10:33:38 -0600, Andrew Davis wrote:
> SDHCI nodes defined in the top-level AM65 SoC dtsi files are incomplete
> and will not be functional unless they are extended.
> 
> As the attached SD/eMMC is only known about at the board integration level,
> these nodes should only be enabled when provided with this information.
> 
> Disable the SDHCI nodes in the dtsi files and only enable the ones that
> are actually pinned out on a given board.
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/2] arm64: dts: ti: k3-am65: Enable SDHCI nodes at the board level
      commit: 006d93519db2e0eacbaeac20cf9d55a4d842a006
[2/2] arm64: dts: ti: k3-am64: Enable SDHCI nodes at the board level
      commit: 3b6345e3fcf4c93a79f396121cd0e6f98f04da13

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Mon Dec  4 13:13:59 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:13:59 -0600
Subject: [PATCH RESEND] arm64: dts: ti: k3-am62-main: Add gpio-ranges properties
In-Reply-To: <20231127112657.2692103-1-rwahl@gmx.de>
References: <20231127112657.2692103-1-rwahl@gmx.de>
Message-ID: <170172443707.2631414.6661290587601995031.b4-ty@ti.com>

Hi Ronald Wahl,

On Mon, 27 Nov 2023 12:26:57 +0100, Ronald Wahl wrote:
> On the AM62 platform we have no single 1:1 relation regarding index of
> gpio and pin controller. Actually there are some linear ranges with
> small holes inbetween. These ranges can be represented with the
> gpio-ranges device tree property. They have been extracted manually
> from the AM62x datasheet (Table 6-1. Pin Attributes).
> 
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: ti: k3-am62-main: Add gpio-ranges properties
      commit: ba78573abba7eb20190b2bb55e5cb5b55a8854fc

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Mon Dec  4 13:14:10 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 4 Dec 2023 15:14:10 -0600
Subject: [PATCH v2] arm64: dts: ti: k3-am625-beagleplay: Use UART name in pinmux name
In-Reply-To: <20231127193602.151499-1-afd@ti.com>
References: <20231127193602.151499-1-afd@ti.com>
Message-ID: <170172444812.2631504.2797072320742159946.b4-ty@ti.com>

Hi Andrew Davis,

On Mon, 27 Nov 2023 13:36:02 -0600, Andrew Davis wrote:
> The main_uart0 may not always be the console, but it will always be
> the UART0 in MAIN domain. Name the pinmux node to match. This makes
> it consistent with all other TI SoC based boards.
> 
> 

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: ti: k3-am625-beagleplay: Use UART name in pinmux name
      commit: 649e121f9301a4d275b68323a9807b762618e516

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From ggiordano at phytec.com  Mon Dec  4 13:23:04 2023
From: ggiordano at phytec.com (Garrett Giordano)
Date: Mon,  4 Dec 2023 13:23:04 -0800
Subject: [PATCH] arm64: dts: ti: phycore-am64: Add R5F DMA Region and Mailboxes
Message-ID: <20231204212304.1736306-1-ggiordano@phytec.com>

Communication between the R5F subsystem and Linux takes place using DMA
memory regions and mailboxes. Here we add DT nodes for the memory
regions and mailboxes to facilitate communication between the R5
clusters and Linux as remoteproc will fail to start if no memory
regions or mailboxes are provided.

Fixes: c48ac0efe6d7 ("arm64: dts: ti: Add support for phyBOARD-Electra-AM642")
Signed-off-by: Garrett Giordano <ggiordano at phytec.com>
---
 .../boot/dts/ti/k3-am64-phycore-som.dtsi      | 102 +++++++++++++++++-
 1 file changed, 101 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
index 1c2c8f0daca9..37a33006c1fc 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
@@ -29,7 +29,7 @@ memory at 80000000 {
 		reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
 	};
 
-	reserved-memory {
+	reserved_memory: reserved-memory {
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
@@ -39,6 +39,54 @@ secure_ddr: optee at 9e800000 {
 			alignment = <0x1000>;
 			no-map;
 		};
+
+		main_r5fss0_core0_dma_memory_region: r5f-dma-memory at a0000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa0000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss0_core0_memory_region: r5f-memory at a0100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa0100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		main_r5fss0_core1_dma_memory_region: r5f-dma-memory at a1000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa1000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss0_core1_memory_region: r5f-memory at a1100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa1100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		main_r5fss1_core0_dma_memory_region: r5f-dma-memory at a2000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa2000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss1_core0_memory_region: r5f-memory at a2100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa2100000 0x00 0xf00000>;
+			no-map;
+		};
+
+		main_r5fss1_core1_dma_memory_region: r5f-dma-memory at a3000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa3000000 0x00 0x100000>;
+			no-map;
+		};
+
+		main_r5fss1_core1_memory_region: r5f-memory at a3100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa3100000 0x00 0xf00000>;
+			no-map;
+		};
 	};
 
 	leds {
@@ -160,6 +208,34 @@ &cpsw_port2 {
 	status = "disabled";
 };
 
+&mailbox0_cluster2 {
+	status = "okay";
+
+	mbox_main_r5fss0_core0: mbox-main-r5fss0-core0 {
+		ti,mbox-rx = <0 0 2>;
+		ti,mbox-tx = <1 0 2>;
+	};
+
+	mbox_main_r5fss0_core1: mbox-main-r5fss0-core1 {
+		ti,mbox-rx = <2 0 2>;
+		ti,mbox-tx = <3 0 2>;
+	};
+};
+
+&mailbox0_cluster4 {
+	status = "okay";
+
+	mbox_main_r5fss1_core0: mbox-main-r5fss1-core0 {
+		ti,mbox-rx = <0 0 2>;
+		ti,mbox-tx = <1 0 2>;
+	};
+
+	mbox_main_r5fss1_core1: mbox-main-r5fss1-core1 {
+		ti,mbox-rx = <2 0 2>;
+		ti,mbox-tx = <3 0 2>;
+	};
+};
+
 &main_i2c0 {
 	status = "okay";
 	pinctrl-names = "default";
@@ -180,6 +256,30 @@ i2c_som_rtc: rtc at 52 {
 	};
 };
 
+&main_r5fss0_core0 {
+	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
+	memory-region = <&main_r5fss0_core0_dma_memory_region>,
+			<&main_r5fss0_core0_memory_region>;
+};
+
+&main_r5fss0_core1 {
+	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
+	memory-region = <&main_r5fss0_core1_dma_memory_region>,
+			<&main_r5fss0_core1_memory_region>;
+};
+
+&main_r5fss1_core0 {
+	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
+	memory-region = <&main_r5fss1_core0_dma_memory_region>,
+			<&main_r5fss1_core0_memory_region>;
+};
+
+&main_r5fss1_core1 {
+	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
+	memory-region = <&main_r5fss1_core1_dma_memory_region>,
+			<&main_r5fss1_core1_memory_region>;
+};
+
 &ospi0 {
 	status = "okay";
 	pinctrl-names = "default";
-- 
2.25.1



From scclevenger at os.amperecomputing.com  Mon Dec  4 13:41:32 2023
From: scclevenger at os.amperecomputing.com (Steve Clevenger)
Date: Mon, 4 Dec 2023 13:41:32 -0800
Subject: [PATCH V2] coresight: tmc: Make etr buffer mode user configurable
 from sysfs
In-Reply-To: <e7b4dce7-7197-0976-c302-a81444b712aa@os.amperecomputing.com>
References: <20230818082112.554638-1-anshuman.khandual@arm.com>
 <bedcf27e-b273-075f-3d7b-eb99b07e7c91@arm.com>
 <b2cf0173-c404-d7d6-9eb8-054e160ca4e5@os.amperecomputing.com>
 <ffa90e80-c249-42d5-26f1-dc022d91e5a9@os.amperecomputing.com>
 <391951c3-7da9-3965-acf8-f3b31f822879@os.amperecomputing.com>
 <1b2a035c-489e-ace9-f851-c1ec157ff9fa@arm.com>
 <cc1b1082-2bcb-9d76-afc7-0e12edd694f0@os.amperecomputing.com>
 <f9fddb60-6976-6d99-fcc2-8011d2fadeb7@arm.com>
 <134faf1d-d662-0e26-d9db-c98645ef6243@arm.com>
 <e7b4dce7-7197-0976-c302-a81444b712aa@os.amperecomputing.com>
Message-ID: <25f46f87-2090-46ca-9ef7-1310b4360801@os.amperecomputing.com>


Hi Suzuki,

On 9/7/2023 2:31 PM, Steve Clevenger wrote:
> 
> Hi Suzuki,
> 
> On 9/1/2023 5:22 AM, Suzuki K Poulose wrote:
>> Hi Steve
>>
>> On 30/08/2023 17:04, Suzuki K Poulose wrote:
>>> Cc: Sudeep
>>>
>>> Hi Steve
>>>
>>> On 28/08/2023 17:35, Steve Clevenger wrote:
>>>>
>>>> Hi Suzuki,
>>>>
>>>> On 8/27/2023 2:35 PM, Suzuki K Poulose wrote:
>>>>> Hi Steve
>>>>>
>>>>> On 26/08/2023 01:14, Steve Clevenger wrote:
>>>>>>
>>>>>> Unfortunately, I tested with the original patch not [PATCH V2]. I've
>>>>>> remedied this. My results below:
>>>>>>
>>>>>> [root at sut01sys-b212 linux]# cat
>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_modes_available
>>>>>> auto flat catu
>>>>>> [root at sut01sys-b212 linux]# cat
>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_mode_preferred
>>>>>> auto
>>>>>> [root at sut01sys-b212 linux]# echo "catu" >
>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_mode_preferred
>>>>>> [root at sut01sys-b212 linux]# cat
>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_mode_preferred
>>>>>> catu
>>>>>>
>>>>>> As with the V1 patch, auto defaults to catu.
>>>>>>
>>>>>> I expected to see tmc-sg (former default) as an available mode, but do
>>>>>> not. As I recall, the buffer mode defaulted to ETR scatter-gather
>>>>>> prior
>>>>>> to this patch. Must this capability now be explicitly advertised? I've
>>>>>> seen this done as "arm,scatter-gather" in device trees, but not
>>>>>> used by
>>>>>> Ampere. Perhaps someone can enlighten me.
>>>>>
>>>>> Yes, you must add that property to the TMC-ETR node (for both DT and
>>>>> ACPI). In the past, almost all of the TMC-ETRs (except Juno board)
>>>>> locked up the system while using the SG mode (due to the interconnect
>>>>> issues, something to do with the transaction). Thus, we decided to
>>>>> add a property explicitly enabling this for a given platform.
>>>>>
>>>>> When you mentioned, it was using TMC-ETR SG mode, how did you verify
>>>>> this ? Please be aware that the table allocation code etc are shared
>>>>> by both TMC-SG and CATU.
>>>>>
>>>>
>>>> You might recall how this started. I had no way to test the CATU due to
>>>> the order the ETR modes defaulted (Flat, ETR-SG, CATU). For test
>>>> purposes, I programmatically swapped the ETR-SG/CATU order and could
>>>> then verify CATU operation by the driver calling into CATU code. This
>>>
>>> So, were you using the DT based boot for the above runs ?
>>>
>>>> suggests Flat mode was bypassed, and the driver defaulted to ETR-SG
>>>> prior to this hack. This didn't offer the user any control, hence my
>>>> feature request. Note that most of the early Ampere self-hosted trace
>>>> collection used ETR-SG. Now I can't select it.
>>>
>>>
>>>>
>>>> How is this property described in the ACPI? The "ACPI for CoreSight? 1.1
>>>> Platform Design Document" (DEN0067) doesn't describe this.
>>>
>>> This is not specified in the ACPI platform design document. I can get
>>> it fixed. Ideally we need a property describing that the scatter-gather
>>> mode is safe to use.
>>
>> Looks like this is not straight forward copying of DT property. We are
>> investigating this on our side and will get back to you.

I noticed this work is queued for 6.7 (coresight-next-6.7). Do you have
an update to the ACPI platform design document Ampere can use to base an
update so the scatter-gather mode can be used?

Thanks,
Steve

>>
> 
> The intent behind my request was to have a way to SysFS configure the
> (available) ETR mode. Unless there's a change to the ACPI, the CATU is
> the only SG option for Ampere in the near term.
> 
> Thanks,
> Steve
> 
> 
>> Suzuki
>>
>>
>>>
>>> DT uses "arm,scatter-gather" property [0] and this is what we now expect
>>> in the ACPI based systems too.
>>>
>>> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml#:~:text=71-,72,-73
>>>
>>> Does it sound fine ?
>>>
>>> Suzuki
>>>
>>>>
>>>> Thanks,
>>>> Steve
>>>>
>>>>
>>>>> Kind regards
>>>>> Suzuki
>>>>>
>>>>>>
>>>>>> Steve C.
>>>>>>
>>>>>> On 8/23/2023 4:10 PM, Steve Clevenger wrote:
>>>>>>>
>>>>>>> Here's some quick feedback. My system shows two modes available; auto
>>>>>>> catu
>>>>>>>
>>>>>>> etr_buf_mode_current is writable. I expected to see tmc-sg (former
>>>>>>> default) listed in etr_buf_modes_available but it doesn't show up.
>>>>>>>
>>>>>>> Note that both the auto and catu etr_buf_mode_current settings
>>>>>>> default
>>>>>>> to catu. My understanding is auto should revert to the default
>>>>>>> behavior.
>>>>>>> On my system the default was tmc-sg.
>>>>>>>
>>>>>>> More later.
>>>>>>>
>>>>>>> [root at sut01sys-b212 kernel]# cat
>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_modes_available
>>>>>>>
>>>>>>> auto catu
>>>>>>> [root at sut01sys-b212 kernel]# cat
>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_mode_current
>>>>>>> catu
>>>>>>> [root at sut01sys-b212 kernel]# echo "catu" >
>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_mode_current
>>>>>>> [root at sut01sys-b212 kernel]# cat
>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_mode_current
>>>>>>> catu
>>>>>>>
>>>>>>> Steve C.
>>>>>>>
>>>>>>>
>>>>>>> On 8/21/2023 12:40 PM, Steve Clevenger wrote:
>>>>>>>>
>>>>>>>> Hi Suzuki,
>>>>>>>>
>>>>>>>> I may be able to test it this week. You've already pointed me at the
>>>>>>>> patch thread(s). The main holdup is I need to merge the 6.6 pending
>>>>>>>> platform work in order to use the Ampere ACPI. I couldn't get these
>>>>>>>> patches to apply directly to 6.4 last I tried.
>>>>>>>>
>>>>>>>> Steve C.
>>>>>>>>
>>>>>>>> On 8/18/2023 2:39 AM, Suzuki K Poulose wrote:
>>>>>>>>> Cc: Steve
>>>>>>>>>
>>>>>>>>> Steve,
>>>>>>>>>
>>>>>>>>> Are you able to test this with CATU ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 18/08/2023 09:21, Anshuman Khandual wrote:
>>>>>>>>>> Currently TMC-ETR automatically selects the buffer mode from all
>>>>>>>>>> available
>>>>>>>>>> methods in the following sequentially fallback manner - also in
>>>>>>>>>> that
>>>>>>>>>> order.
>>>>>>>>>>
>>>>>>>>>> 1. FLAT mode with or without IOMMU
>>>>>>>>>> 2. TMC-ETR-SG (scatter gather) mode when available
>>>>>>>>>> 3. CATU mode when available
>>>>>>>>>>
>>>>>>>>>> But this order might not be ideal for all situations. For
>>>>>>>>>> example if
>>>>>>>>>> there
>>>>>>>>>> is a CATU connected to ETR, it may be better to use TMC-ETR
>>>>>>>>>> scatter
>>>>>>>>>> gather
>>>>>>>>>> method, rather than CATU. But hard coding such order changes will
>>>>>>>>>> prevent
>>>>>>>>>> us from testing or using a particular mode. This change provides
>>>>>>>>>> following
>>>>>>>>>> new sysfs tunables for the user to control TMC-ETR buffer mode
>>>>>>>>>> explicitly,
>>>>>>>>>> if required. This adds following new sysfs files for buffer mode
>>>>>>>>>> selection
>>>>>>>>>> purpose explicitly in the user space.
>>>>>>>>>>
>>>>>>>>>> /sys/bus/coresight/devices/tmc_etr<N>/buf_modes_available
>>>>>>>>>> /sys/bus/coresight/devices/tmc_etr<N>/buf_mode_preferred
>>>>>>>>>>
>>>>>>>>>> $ cat buf_modes_available
>>>>>>>>>> auto flat tmc-sg catu??? ------------------> Supported TMC-ETR
>>>>>>>>>> buffer
>>>>>>>>>> modes
>>>>>>>>>>
>>>>>>>>>> $ echo catu > buf_mode_preferred?? -------> Explicit buffer mode
>>>>>>>>>> request
>>>>>>>>>>
>>>>>>>>>> But explicit user request has to be within supported ETR buffer
>>>>>>>>>> modes
>>>>>>>>>> only.
>>>>>>>>>> These sysfs interface files are exclussive to ETR, and hence these
>>>>>>>>>> are
>>>>>>>>>> not
>>>>>>>>>> available for other TMC devices such as ETB or ETF etc.
>>>>>>>>>>
>>>>>>>>>> A new auto' mode (i.e ETR_MODE_AUTO) has been added to help
>>>>>>>>>> fallback
>>>>>>>>>> to the
>>>>>>>>>> existing default behaviour, when user provided preferred buffer
>>>>>>>>>> mode
>>>>>>>>>> fails.
>>>>>>>>>> ETR_MODE_FLAT and ETR_MODE_AUTO are always available as preferred
>>>>>>>>>> modes.
>>>>>>>>>>
>>>>>>>>>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>>>>>>>>>> Cc: Mike Leach <mike.leach at linaro.org>
>>>>>>>>>> Cc: James Clark <james.clark at arm.com>
>>>>>>>>>> Cc: Leo Yan <leo.yan at linaro.org>
>>>>>>>>>> Cc: Alexander Shishkin <alexander.shishkin at linux.intel.com>
>>>>>>>>>> Cc: coresight at lists.linaro.org
>>>>>>>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>>>>>>>> Cc: linux-kernel at vger.kernel.org
>>>>>>>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>>>>>>>>> ---
>>>>>>>>>> This applies on v6.5-rc6
>>>>>>>>>>
>>>>>>>>>> Changes in V2:
>>>>>>>>>>
>>>>>>>>>> - Renamed sysfs file etr_buf_modes_available as
>>>>>>>>>> buf_modes_available
>>>>>>>>>> - Renamed sysfs file buf_mode_current as buf_mode_preferred
>>>>>>>>>> - Renamed etr_supports_flat_mode() as etr_can_use_flat_mode()
>>>>>>>>>> - Renamed coresight_tmc_groups[] as coresight_etf_groups[]
>>>>>>>>>> - Reused coresight_tmc_group[] for trigger_cntr and buffer_size
>>>>>>>>>> - Fallback trying ETR_MODE_AUTO when user preferred mode fails
>>>>>>>>>> - Moved ETR sysfs details into coresight-tmc-etr.c
>>>>>>>>>> - Dropped etr_can_use_flat_mode() check while offering
>>>>>>>>>> ETR_MODE_FLAT
>>>>>>>>>> in sysfs
>>>>>>>>>> - Moved struct etr_buf_hw inside coresight-tmc-etr.c
>>>>>>>>>> - Moved get_etr_buf_hw() and etr_can_use_flat_mode() inside
>>>>>>>>>> coresight-tmc-etr.c
>>>>>>>>>> - Updated month in
>>>>>>>>>> Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
>>>>>>>>>>
>>>>>>>>>> Changes in V1:
>>>>>>>>>>
>>>>>>>>>> https://lore.kernel.org/all/20230728084837.276551-1-anshuman.khandual at arm.com/
>>>>>>>>>>
>>>>>>>>>> ??? .../testing/sysfs-bus-coresight-devices-tmc?? |? 16 +++
>>>>>>>>>> ??? .../hwtracing/coresight/coresight-tmc-core.c? |? 15 ++-
>>>>>>>>>> ??? .../hwtracing/coresight/coresight-tmc-etr.c?? | 111
>>>>>>>>>> ++++++++++++++++--
>>>>>>>>>> ??? drivers/hwtracing/coresight/coresight-tmc.h?? |?? 3 +
>>>>>>>>>> ??? 4 files changed, 131 insertions(+), 14 deletions(-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Looks good to me.
>>>>>>>>>
>>>>>>>>> Suzuki
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>
>>


From ggiordano at phytec.com  Mon Dec  4 14:28:09 2023
From: ggiordano at phytec.com (Garrett Giordano)
Date: Mon,  4 Dec 2023 14:28:09 -0800
Subject: [PATCH 1/3] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Lower I2C1 frequency
Message-ID: <20231204222811.2344460-1-ggiordano@phytec.com>

The gpio-expander on i2c-1 has a maximum frequency of 100kHz. Update our
main_i2c1 frequency to allow the nxp,pcf8574 gpio-expander to function
properly.

Signed-off-by: Garrett Giordano <ggiordano at phytec.com>
---
 arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
index a438baf542c2..171354b13e33 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
@@ -187,7 +187,7 @@ cpsw3g_phy3: ethernet-phy at 3 {
 &main_i2c1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_i2c1_pins_default>;
-	clock-frequency = <400000>;
+	clock-frequency = <100000>;
 	status = "okay";
 
 	gpio_exp: gpio-expander at 21 {
-- 
2.25.1



From ggiordano at phytec.com  Mon Dec  4 14:28:10 2023
From: ggiordano at phytec.com (Garrett Giordano)
Date: Mon,  4 Dec 2023 14:28:10 -0800
Subject: [PATCH 2/3] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Add HDMI support
In-Reply-To: <20231204222811.2344460-1-ggiordano@phytec.com>
References: <20231204222811.2344460-1-ggiordano@phytec.com>
Message-ID: <20231204222811.2344460-2-ggiordano@phytec.com>

The DSS outputs DPI signals via its second video port (VP2). The DPI
output from DSS is 24 bits (RGB888) and is forwarded to an HDMI
transmitter (SIL9022) on the board.

Add pinmux for DSS DPI output and HDMI Interrupt.

Add DT nodes for SIL9022 HDMI transmitter (TX), and the HDMI connector
on the phyBOARD-Lyra.

Additionally, connect the output of DSS (VP2) with input of the HDMI TX,
and the output of HDMI TX to the input of the HDMI connector.

Signed-off-by: Garrett Giordano <ggiordano at phytec.com>
---
 .../dts/ti/k3-am625-phyboard-lyra-rdk.dts     | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
index 171354b13e33..81319d68b624 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
@@ -35,6 +35,18 @@ can_tc1: can-phy0 {
 		standby-gpios = <&gpio_exp 1 GPIO_ACTIVE_HIGH>;
 	};
 
+	hdmi0: connector-hdmi {
+		compatible = "hdmi-connector";
+		label = "hdmi";
+		type = "a";
+
+		port {
+			hdmi_connector_in: endpoint {
+				remote-endpoint = <&sii9022_out>;
+			};
+		};
+	};
+
 	keys {
 		compatible = "gpio-keys";
 		autorepeat;
@@ -93,6 +105,37 @@ AM62X_IOPAD(0x244, PIN_INPUT, 7) /* (C17) MMC1_SDWP.GPIO1_49 */
 		>;
 	};
 
+	hdmi_int_pins_default: hdmi-int-default-pins {
+		pinctrl-single,pins = <
+			AM62X_IOPAD(0x040, PIN_INPUT, 7) /* (N23) GPMC0_AD1.GPIO0_16 */
+		>;
+	};
+
+	main_dss0_pins_default: main-dss0-default-pins {
+		pinctrl-single,pins = <
+			AM62X_IOPAD(0x0b8, PIN_OUTPUT, 0) /* (U22) VOUT0_DATA0 */
+			AM62X_IOPAD(0x0bc, PIN_OUTPUT, 0) /* (V24) VOUT0_DATA1 */
+			AM62X_IOPAD(0x0e0, PIN_OUTPUT, 0) /* (V20) VOUT0_DATA10 */
+			AM62X_IOPAD(0x0e4, PIN_OUTPUT, 0) /* (AA23) VOUT0_DATA11 */
+			AM62X_IOPAD(0x0e8, PIN_OUTPUT, 0) /* (AB25) VOUT0_DATA12 */
+			AM62X_IOPAD(0x0ec, PIN_OUTPUT, 0) /* (AA24) VOUT0_DATA13 */
+			AM62X_IOPAD(0x0f0, PIN_OUTPUT, 0) /* (Y22) VOUT0_DATA14 */
+			AM62X_IOPAD(0x0f4, PIN_OUTPUT, 0) /* (AA21) VOUT0_DATA15 */
+			AM62X_IOPAD(0x0c0, PIN_OUTPUT, 0) /* (W25) VOUT0_DATA2 */
+			AM62X_IOPAD(0x0c4, PIN_OUTPUT, 0) /* (W24) VOUT0_DATA3 */
+			AM62X_IOPAD(0x0c8, PIN_OUTPUT, 0) /* (Y25) VOUT0_DATA4 */
+			AM62X_IOPAD(0x0cc, PIN_OUTPUT, 0) /* (Y24) VOUT0_DATA5 */
+			AM62X_IOPAD(0x0d0, PIN_OUTPUT, 0) /* (Y23) VOUT0_DATA6 */
+			AM62X_IOPAD(0x0d4, PIN_OUTPUT, 0) /* (AA25) VOUT0_DATA7 */
+			AM62X_IOPAD(0x0d8, PIN_OUTPUT, 0) /* (V21) VOUT0_DATA8 */
+			AM62X_IOPAD(0x0dc, PIN_OUTPUT, 0) /* (W21) VOUT0_DATA9 */
+			AM62X_IOPAD(0x0fc, PIN_OUTPUT, 0) /* (Y20) VOUT0_DE */
+			AM62X_IOPAD(0x0f8, PIN_OUTPUT, 0) /* (AB24) VOUT0_HSYNC */
+			AM62X_IOPAD(0x104, PIN_OUTPUT, 0) /* (AC24) VOUT0_PCLK */
+			AM62X_IOPAD(0x100, PIN_OUTPUT, 0) /* (AC25) VOUT0_VSYNC */
+		>;
+	};
+
 	main_i2c1_pins_default: main-i2c1-default-pins {
 		pinctrl-single,pins = <
 			AM62X_IOPAD(0x1e8, PIN_INPUT_PULLUP, 0) /* (B17) I2C1_SCL */
@@ -184,6 +227,26 @@ cpsw3g_phy3: ethernet-phy at 3 {
 	};
 };
 
+&dss {
+	pinctrl-names = "default";
+	pinctrl-0 = <&main_dss0_pins_default>;
+	status = "okay";
+};
+
+&dss_ports {
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	/* VP2: DPI/HDMI Output */
+	port at 1 {
+		reg = <1>;
+
+		dpi1_out: endpoint {
+			remote-endpoint = <&sii9022_in>;
+		};
+	};
+};
+
 &main_i2c1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_i2c1_pins_default>;
@@ -207,6 +270,37 @@ gpio_exp: gpio-expander at 21 {
 				  "GPIO6_ETH1_USER_RESET", "GPIO7_AUDIO_USER_RESET";
 	};
 
+	sii9022: bridge-hdmi at 39 {
+		compatible = "sil,sii9022";
+		reg = <0x39>;
+
+		interrupt-parent = <&main_gpio0>;
+		interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&hdmi_int_pins_default>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				sii9022_in: endpoint {
+					remote-endpoint = <&dpi1_out>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+
+				sii9022_out: endpoint {
+					remote-endpoint = <&hdmi_connector_in>;
+				};
+			};
+		};
+	};
+
 	eeprom at 51 {
 		compatible = "atmel,24c02";
 		pagesize = <16>;
-- 
2.25.1



From ggiordano at phytec.com  Mon Dec  4 14:28:11 2023
From: ggiordano at phytec.com (Garrett Giordano)
Date: Mon,  4 Dec 2023 14:28:11 -0800
Subject: [PATCH 3/3] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Remove HDMI Reset Line Name
In-Reply-To: <20231204222811.2344460-1-ggiordano@phytec.com>
References: <20231204222811.2344460-1-ggiordano@phytec.com>
Message-ID: <20231204222811.2344460-3-ggiordano@phytec.com>

The GPIO Expander has a line name defined as GPIO0_HDMI_RST. This line
is no longer associated with the HDMI Reset so we removed it.

Signed-off-by: Garrett Giordano <ggiordano at phytec.com>
---
 arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
index 81319d68b624..4bc0134c987d 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
@@ -264,7 +264,7 @@ gpio_exp: gpio-expander at 21 {
 		gpio-controller;
 		interrupt-controller;
 		#interrupt-cells = <2>;
-		gpio-line-names = "GPIO0_HDMI_RST", "GPIO1_CAN0_nEN",
+		gpio-line-names = "", "GPIO1_CAN0_nEN",
 				  "GPIO2_LED2", "GPIO3_LVDS_GPIO",
 				  "GPIO4_BUT2", "GPIO5_LVDS_BKLT_EN",
 				  "GPIO6_ETH1_USER_RESET", "GPIO7_AUDIO_USER_RESET";
-- 
2.25.1



From nathan at kernel.org  Mon Dec  4 14:33:17 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Mon, 4 Dec 2023 15:33:17 -0700
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error:
 instruction variant requires ARMv6 or later
In-Reply-To: <20231204181304.GA2043538@dev-arch.thelio-3990X>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
 <20231204181304.GA2043538@dev-arch.thelio-3990X>
Message-ID: <20231204223317.GA2053629@dev-arch.thelio-3990X>

On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote:
> Hi Naresh,
> 
> On Mon, Dec 04, 2023 at 05:33:26PM +0530, Naresh Kamboju wrote:
> > Following build errors noticed on Linux next-20231204 tag with clang-nightly
> > for arm and arm64.
> > 
> > ## Test Regressions (compared to next-20231201)
> > * arm64, build
> >   - clang-nightly-defconfig
> >   - clang-nightly-defconfig-40bc7ee5
> >   - clang-nightly-lkftconfig
> >   - clang-nightly-lkftconfig-kselftest
> > 
> > * arm, build
> >   - clang-nightly-allnoconfig
> >   - clang-nightly-axm55xx_defconfig
> >   - clang-nightly-bcm2835_defconfig
> >   - clang-nightly-clps711x_defconfig
> >   - clang-nightly-defconfig
> >   - clang-nightly-exynos_defconfig
> >   - clang-nightly-imx_v6_v7_defconfig
> >   - clang-nightly-keystone_defconfig
> >   - clang-nightly-lkftconfig
> >   - clang-nightly-lkftconfig-kselftest
> >   - clang-nightly-omap2plus_defconfig
> >   - clang-nightly-pxa910_defconfig
> >   - clang-nightly-s3c6400_defconfig
> >   - clang-nightly-s5pv210_defconfig
> >   - clang-nightly-sama5_defconfig
> >   - clang-nightly-shmobile_defconfig
> >   - clang-nightly-tinyconfig
> >   - clang-nightly-u8500_defconfig
> >   - clang-nightly-vexpress_defconfig
> > 
> > 
> > Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
> > 
> > 
> > Build log on arm64:
> > ---------
> > In file included from lib/vdso/gettimeofday.c:5:
> > In file included from include/vdso/datapage.h:135:
> > arch/arm64/include/asm/vdso/compat_gettimeofday.h:152:15: error:
> > instruction variant requires ARMv6 or later
> >   152 |         asm volatile("mov %0, %1" : "=r"(ret) : "r"(_vdso_data));
> >       |                      ^
> > <inline asm>:1:2: note: instantiated into assembly here
> >     1 |         mov r4, r1
> >       |         ^
> > In file included from <built-in>:3:
> > lib/vdso/gettimeofday.c:139:3: error: invalid instruction
> >   139 |                 smp_rmb();
> >       |                 ^
> > 
> > Build log on arm:
> > ---------
> > In file included from arch/arm/vfp/vfpmodule.c:23:
> > arch/arm/include/asm/cp15.h:101:2: error: instruction requires: data-barriers
> >   101 |         isb();
> >       |         ^
> 
> This is caused by a change to Debian's LLVM that changes the internal
> defaults of the arm-linux-gnueabi and arm-linux-gnueabihf tuples:
> 
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/907baf024b9a5a1626893d9e731b6c79ccf45c87
> 
> We use arm-linux-gnueabi for the kernel (see scripts/Makefile.clang) so
> now we have a hardcoded armv5te CPU, even if we are building for armv7
> or such.
> 
> I am still investigating into what (if anything) can be done to resolve
> this on the kernel side. We could potentially revert commit
> ddc72c9659b5 ("kbuild: clang: do not use CROSS_COMPILE for target
> triple") but I am not sure that will save us from that change, as
> tuxmake's CROSS_COMPILE=arm-linux-gnueabihf will cause us to have an
> armv7 CPU even though we may not be building for armv7.

Okay, this is a pretty awful situation the more I look into it :(

The arm64 compat vDSO build is easy enough to fix because we require use
of the integrated assembler, which means we can add '-mcpu=generic' (the
default in LLVM for those files based on my debugging) to those files
and be done with it:

diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
index 1f911a76c5af..5f5cb722cfc2 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -9,6 +9,10 @@ include $(srctree)/lib/vdso/Makefile
 ifeq ($(CONFIG_CC_IS_CLANG), y)
 CC_COMPAT ?= $(CC)
 CC_COMPAT += --target=arm-linux-gnueabi
+# Some distributions (such as Debian) change the default CPU for the
+# arm-linux-gnueabi target triple, which can break the build. Explicitly set
+# the CPU to generic, which is the default for Linux in LLVM.
+CC_COMPAT += -mcpu=generic
 else
 CC_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc
 endif

The failures for all the ARCH=arm configurations appear to be much more
difficult to fix because the default CPU value changes based on the
'-march' value, which basically means that we would have to hardcode
LLVM's default CPU logic into the kernel's Makefile, which is just not
maintainable in my opinion. Just doing a multi_v7_defconfig build of
arch/arm/ shows the value returned from ARM::getARMCPUForArch() in
llvm/lib/TargetParser/ARMTargetParser.cpp can vary between "arm7tdmi" or
"generic". Supplying '-mcpu=generic' explicitly won't work with
LLVM_IAS=0 because GNU as does not support it and clang just happily
passes it along, even though it does not do that in the implicit default
case.

Sylvestre, I strongly believe you should consider reverting that change
or give us some compiler flag that allows us to fallback to upstream
LLVM's default CPU selection logic. I think that hardcoding Debian's
architecture defintions based on the target triple into the compiler
could cause issues for other projects as well. For example,
'--target=arm-linux-gnueabi -march=armv7-a' won't actually target ARMv7:

  $ echo 'int main(void) { asm("dsb"); return 0; }' | \
        clang --target=arm-linux-gnueabi -march=armv7-a \
        -x c -c -o /dev/null -v -
  ...
   "/usr/bin/clang-17" -cc1 -triple armv7-unknown-linux-gnueabi ...
  ...

vs.

  $ echo 'int main(void) { asm("dsb"); return 0; }' | \
        clang --target=arm-linux-gnueabi -march=armv7-a \
        -x c -c -o /dev/null -v -
  ...
  "<prefix>/bin/clang-18" -cc1 -triple armv5e-unknown-linux-gnueabi ...
  ...

Cheers,
Nathan


From linus.walleij at linaro.org  Mon Dec  4 14:36:44 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 04 Dec 2023 23:36:44 +0100
Subject: [PATCH] ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support
Message-ID: <20231204-drop-11mpcore-v1-1-f96cd3938cf1@linaro.org>

This ARM11 SMP configuration was one of the first SMP configurations
the ARM kernel supported, but it has the downside of odd DMA handling,
odd cache tagging, and often (as of recent) completely broken cache
handling on the ARM RealView PB11MPCore test chips. To boot the
platform it was necessary to completely disable the cache.
When it comes to the EB 11MPCore it is unclear if this ever worked.

These reference designs are now the only ARMv6K SMP platforms.

As only reference designs of purely academic interest remain, and
since the special-cased DMA and PMU code is hard to maintain and
doesn't really work, it is not really worth our time.

Delete the ARM11MPCore support along with:

- The special DMA quirk CONFIG_DMA_CACHE_RWFO that is only used
  on ARMv6K SMP, and we are the last ARMV6K system leaving the
  building and the cache handling is awkward, so good-bye.

- The special PMU handling that was only used by ARM11MPCore.

The following is left behind:

- TIMER_OF_DECLARE(arm_twd_11mp, "arm,arm11mp-twd-timer", ...)
  in arch/arm/kernel/smp_twd.c, this is still in use by Marvell MMP3
  arch/arm/boot/dts/marvell/mmp3.dtsi

- IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", ...)
  in drivers/irqchip/irq-gic.c, this is still in use by Marvell MMP3
  arch/arm/boot/dts/marvell/mmp3.dtsi

These are unfortunate but will need to be kept around for
compatibility. New Marvell-specific compatibles should however probably
be added.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/kernel/perf_event_v6.c            | 34 ------------------------------
 arch/arm/mach-versatile/Kconfig            | 17 ---------------
 arch/arm/mach-versatile/platsmp-realview.c |  2 --
 arch/arm/mach-versatile/realview.c         |  1 -
 arch/arm/mm/Kconfig                        | 18 ----------------
 arch/arm/mm/cache-v6.S                     | 31 ---------------------------
 6 files changed, 103 deletions(-)

diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index 1ae99deeec54..3115077f6abc 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -525,40 +525,7 @@ static int armv6_1176_pmu_init(struct arm_pmu *cpu_pmu)
 	return 0;
 }
 
-/*
- * ARMv6mpcore is almost identical to single core ARMv6 with the exception
- * that some of the events have different enumerations and that there is no
- * *hack* to stop the programmable counters. To stop the counters we simply
- * disable the interrupt reporting and update the event. When unthrottling we
- * reset the period and enable the interrupt reporting.
- */
-
-static int armv6mpcore_map_event(struct perf_event *event)
-{
-	return armpmu_map_event(event, &armv6mpcore_perf_map,
-				&armv6mpcore_perf_cache_map, 0xFF);
-}
-
-static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
-{
-	cpu_pmu->name		= "armv6_11mpcore";
-	cpu_pmu->handle_irq	= armv6pmu_handle_irq;
-	cpu_pmu->enable		= armv6pmu_enable_event;
-	cpu_pmu->disable	= armv6mpcore_pmu_disable_event;
-	cpu_pmu->read_counter	= armv6pmu_read_counter;
-	cpu_pmu->write_counter	= armv6pmu_write_counter;
-	cpu_pmu->get_event_idx	= armv6pmu_get_event_idx;
-	cpu_pmu->clear_event_idx = armv6pmu_clear_event_idx;
-	cpu_pmu->start		= armv6pmu_start;
-	cpu_pmu->stop		= armv6pmu_stop;
-	cpu_pmu->map_event	= armv6mpcore_map_event;
-	cpu_pmu->num_events	= 3;
-
-	return 0;
-}
-
 static const struct of_device_id armv6_pmu_of_device_ids[] = {
-	{.compatible = "arm,arm11mpcore-pmu",	.data = armv6mpcore_pmu_init},
 	{.compatible = "arm,arm1176-pmu",	.data = armv6_1176_pmu_init},
 	{.compatible = "arm,arm1136-pmu",	.data = armv6_1136_pmu_init},
 	{ /* sentinel value */ }
@@ -568,7 +535,6 @@ static const struct pmu_probe_info armv6_pmu_probe_table[] = {
 	ARM_PMU_PROBE(ARM_CPU_PART_ARM1136, armv6_1136_pmu_init),
 	ARM_PMU_PROBE(ARM_CPU_PART_ARM1156, armv6_1156_pmu_init),
 	ARM_PMU_PROBE(ARM_CPU_PART_ARM1176, armv6_1176_pmu_init),
-	ARM_PMU_PROBE(ARM_CPU_PART_ARM11MPCORE, armv6mpcore_pmu_init),
 	{ /* sentinel value */ }
 };
 
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index b1519b4dc03a..e029270c2687 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -201,23 +201,6 @@ config REALVIEW_EB_A9MP
 	  Enable support for the Cortex-A9MPCore tile fitted to the
 	  Realview(R) Emulation Baseboard platform.
 
-config REALVIEW_EB_ARM11MP
-	bool "Support ARM11MPCore Tile"
-	depends on MACH_REALVIEW_EB && ARCH_MULTI_V6
-	select HAVE_SMP
-	help
-	  Enable support for the ARM11MPCore tile fitted to the Realview(R)
-	  Emulation Baseboard platform.
-
-config MACH_REALVIEW_PB11MP
-	bool "Support RealView(R) Platform Baseboard for ARM11MPCore"
-	depends on ARCH_MULTI_V6
-	select HAVE_SMP
-	help
-	  Include support for the ARM(R) RealView(R) Platform Baseboard for
-	  the ARM11MPCore.  This platform has an on-board ARM11MPCore and has
-	  support for PCI-E and Compact Flash.
-
 # ARMv6 CPU without K extensions, but does have the new exclusive ops
 config MACH_REALVIEW_PB1176
 	bool "Support RealView(R) Platform Baseboard for ARM1176JZF-S"
diff --git a/arch/arm/mach-versatile/platsmp-realview.c b/arch/arm/mach-versatile/platsmp-realview.c
index 5d363385c801..4c3e089ac686 100644
--- a/arch/arm/mach-versatile/platsmp-realview.c
+++ b/arch/arm/mach-versatile/platsmp-realview.c
@@ -18,7 +18,6 @@
 #define REALVIEW_SYS_FLAGSSET_OFFSET	0x30
 
 static const struct of_device_id realview_scu_match[] = {
-	{ .compatible = "arm,arm11mp-scu", },
 	{ .compatible = "arm,cortex-a9-scu", },
 	{ .compatible = "arm,cortex-a5-scu", },
 	{ }
@@ -27,7 +26,6 @@ static const struct of_device_id realview_scu_match[] = {
 static const struct of_device_id realview_syscon_match[] = {
         { .compatible = "arm,core-module-integrator", },
         { .compatible = "arm,realview-eb-syscon", },
-        { .compatible = "arm,realview-pb11mp-syscon", },
         { .compatible = "arm,realview-pbx-syscon", },
         { },
 };
diff --git a/arch/arm/mach-versatile/realview.c b/arch/arm/mach-versatile/realview.c
index a3933e2373d5..36a6f6bc4fdd 100644
--- a/arch/arm/mach-versatile/realview.c
+++ b/arch/arm/mach-versatile/realview.c
@@ -9,7 +9,6 @@
 static const char *const realview_dt_platform_compat[] __initconst = {
 	"arm,realview-eb",
 	"arm,realview-pb1176",
-	"arm,realview-pb11mp",
 	"arm,realview-pba8",
 	"arm,realview-pbx",
 	NULL,
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c164cde50243..2b6f50dd5478 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -937,24 +937,6 @@ config VDSO
 	  You must have glibc 2.22 or later for programs to seamlessly
 	  take advantage of this.
 
-config DMA_CACHE_RWFO
-	bool "Enable read/write for ownership DMA cache maintenance"
-	depends on CPU_V6K && SMP
-	default y
-	help
-	  The Snoop Control Unit on ARM11MPCore does not detect the
-	  cache maintenance operations and the dma_{map,unmap}_area()
-	  functions may leave stale cache entries on other CPUs. By
-	  enabling this option, Read or Write For Ownership in the ARMv6
-	  DMA cache maintenance functions is performed. These LDR/STR
-	  instructions change the cache line state to shared or modified
-	  so that the cache operation has the desired effect.
-
-	  Note that the workaround is only valid on processors that do
-	  not perform speculative loads into the D-cache. For such
-	  processors, if cache maintenance operations are not broadcast
-	  in hardware, other workarounds are needed (e.g. cache
-	  maintenance broadcasting in software via FIQ).
 
 config OUTER_CACHE
 	bool
diff --git a/arch/arm/mm/cache-v6.S b/arch/arm/mm/cache-v6.S
index 250c83bf7158..44211d8a296f 100644
--- a/arch/arm/mm/cache-v6.S
+++ b/arch/arm/mm/cache-v6.S
@@ -201,10 +201,6 @@ ENTRY(v6_flush_kern_dcache_area)
  *	- end     - virtual end address of region
  */
 v6_dma_inv_range:
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrb	r2, [r0]			@ read for ownership
-	strb	r2, [r0]			@ write for ownership
-#endif
 	tst	r0, #D_CACHE_LINE_SIZE - 1
 	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
 #ifdef HARVARD_CACHE
@@ -213,10 +209,6 @@ v6_dma_inv_range:
 	mcrne	p15, 0, r0, c7, c11, 1		@ clean unified line
 #endif
 	tst	r1, #D_CACHE_LINE_SIZE - 1
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrbne	r2, [r1, #-1]			@ read for ownership
-	strbne	r2, [r1, #-1]			@ write for ownership
-#endif
 	bic	r1, r1, #D_CACHE_LINE_SIZE - 1
 #ifdef HARVARD_CACHE
 	mcrne	p15, 0, r1, c7, c14, 1		@ clean & invalidate D line
@@ -231,10 +223,6 @@ v6_dma_inv_range:
 #endif
 	add	r0, r0, #D_CACHE_LINE_SIZE
 	cmp	r0, r1
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrlo	r2, [r0]			@ read for ownership
-	strlo	r2, [r0]			@ write for ownership
-#endif
 	blo	1b
 	mov	r0, #0
 	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer
@@ -248,9 +236,6 @@ v6_dma_inv_range:
 v6_dma_clean_range:
 	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
 1:
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldr	r2, [r0]			@ read for ownership
-#endif
 #ifdef HARVARD_CACHE
 	mcr	p15, 0, r0, c7, c10, 1		@ clean D line
 #else
@@ -269,10 +254,6 @@ v6_dma_clean_range:
  *	- end     - virtual end address of region
  */
 ENTRY(v6_dma_flush_range)
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrb	r2, [r0]		@ read for ownership
-	strb	r2, [r0]		@ write for ownership
-#endif
 	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
 1:
 #ifdef HARVARD_CACHE
@@ -282,10 +263,6 @@ ENTRY(v6_dma_flush_range)
 #endif
 	add	r0, r0, #D_CACHE_LINE_SIZE
 	cmp	r0, r1
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrblo	r2, [r0]			@ read for ownership
-	strblo	r2, [r0]			@ write for ownership
-#endif
 	blo	1b
 	mov	r0, #0
 	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer
@@ -301,13 +278,7 @@ ENTRY(v6_dma_map_area)
 	add	r1, r1, r0
 	teq	r2, #DMA_FROM_DEVICE
 	beq	v6_dma_inv_range
-#ifndef CONFIG_DMA_CACHE_RWFO
 	b	v6_dma_clean_range
-#else
-	teq	r2, #DMA_TO_DEVICE
-	beq	v6_dma_clean_range
-	b	v6_dma_flush_range
-#endif
 ENDPROC(v6_dma_map_area)
 
 /*
@@ -317,11 +288,9 @@ ENDPROC(v6_dma_map_area)
  *	- dir	- DMA direction
  */
 ENTRY(v6_dma_unmap_area)
-#ifndef CONFIG_DMA_CACHE_RWFO
 	add	r1, r1, r0
 	teq	r2, #DMA_TO_DEVICE
 	bne	v6_dma_inv_range
-#endif
 	ret	lr
 ENDPROC(v6_dma_unmap_area)
 

---
base-commit: d570fe67df85c84be7cc33ca9e9568d9601b494f
change-id: 20231202-drop-11mpcore-d556cc5f7d99

Best regards,
-- 
Linus Walleij <linus.walleij at linaro.org>



From sylvestre at debian.org  Mon Dec  4 14:42:02 2023
From: sylvestre at debian.org (Sylvestre Ledru)
Date: Mon, 4 Dec 2023 23:42:02 +0100
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error:
 instruction variant requires ARMv6 or later
In-Reply-To: <20231204223317.GA2053629@dev-arch.thelio-3990X>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
 <20231204181304.GA2043538@dev-arch.thelio-3990X>
 <20231204223317.GA2053629@dev-arch.thelio-3990X>
Message-ID: <c61f61c9-3bfb-4ffd-adaf-1313965b3037@debian.org>

Hello,


Le 04/12/2023 ? 23:33, Nathan Chancellor a ?crit?:
> On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote:
>> Hi Naresh,
>>
>> On Mon, Dec 04, 2023 at 05:33:26PM +0530, Naresh Kamboju wrote:
>>> Following build errors noticed on Linux next-20231204 tag with clang-nightly
>>> for arm and arm64.
>>>
>>> ## Test Regressions (compared to next-20231201)
>>> * arm64, build
>>>    - clang-nightly-defconfig
>>>    - clang-nightly-defconfig-40bc7ee5
>>>    - clang-nightly-lkftconfig
>>>    - clang-nightly-lkftconfig-kselftest
>>>
>>> * arm, build
>>>    - clang-nightly-allnoconfig
>>>    - clang-nightly-axm55xx_defconfig
>>>    - clang-nightly-bcm2835_defconfig
>>>    - clang-nightly-clps711x_defconfig
>>>    - clang-nightly-defconfig
>>>    - clang-nightly-exynos_defconfig
>>>    - clang-nightly-imx_v6_v7_defconfig
>>>    - clang-nightly-keystone_defconfig
>>>    - clang-nightly-lkftconfig
>>>    - clang-nightly-lkftconfig-kselftest
>>>    - clang-nightly-omap2plus_defconfig
>>>    - clang-nightly-pxa910_defconfig
>>>    - clang-nightly-s3c6400_defconfig
>>>    - clang-nightly-s5pv210_defconfig
>>>    - clang-nightly-sama5_defconfig
>>>    - clang-nightly-shmobile_defconfig
>>>    - clang-nightly-tinyconfig
>>>    - clang-nightly-u8500_defconfig
>>>    - clang-nightly-vexpress_defconfig
>>>
>>>
>>> Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
>>>
>>>
>>> Build log on arm64:
>>> ---------
>>> In file included from lib/vdso/gettimeofday.c:5:
>>> In file included from include/vdso/datapage.h:135:
>>> arch/arm64/include/asm/vdso/compat_gettimeofday.h:152:15: error:
>>> instruction variant requires ARMv6 or later
>>>    152 |         asm volatile("mov %0, %1" : "=r"(ret) : "r"(_vdso_data));
>>>        |                      ^
>>> <inline asm>:1:2: note: instantiated into assembly here
>>>      1 |         mov r4, r1
>>>        |         ^
>>> In file included from <built-in>:3:
>>> lib/vdso/gettimeofday.c:139:3: error: invalid instruction
>>>    139 |                 smp_rmb();
>>>        |                 ^
>>>
>>> Build log on arm:
>>> ---------
>>> In file included from arch/arm/vfp/vfpmodule.c:23:
>>> arch/arm/include/asm/cp15.h:101:2: error: instruction requires: data-barriers
>>>    101 |         isb();
>>>        |         ^
>> This is caused by a change to Debian's LLVM that changes the internal
>> defaults of the arm-linux-gnueabi and arm-linux-gnueabihf tuples:
>>
>> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/907baf024b9a5a1626893d9e731b6c79ccf45c87
>>
>> We use arm-linux-gnueabi for the kernel (see scripts/Makefile.clang) so
>> now we have a hardcoded armv5te CPU, even if we are building for armv7
>> or such.
>>
>> I am still investigating into what (if anything) can be done to resolve
>> this on the kernel side. We could potentially revert commit
>> ddc72c9659b5 ("kbuild: clang: do not use CROSS_COMPILE for target
>> triple") but I am not sure that will save us from that change, as
>> tuxmake's CROSS_COMPILE=arm-linux-gnueabihf will cause us to have an
>> armv7 CPU even though we may not be building for armv7.
> Okay, this is a pretty awful situation the more I look into it :(
>
> The arm64 compat vDSO build is easy enough to fix because we require use
> of the integrated assembler, which means we can add '-mcpu=generic' (the
> default in LLVM for those files based on my debugging) to those files
> and be done with it:
>
> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> index 1f911a76c5af..5f5cb722cfc2 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -9,6 +9,10 @@ include $(srctree)/lib/vdso/Makefile
>   ifeq ($(CONFIG_CC_IS_CLANG), y)
>   CC_COMPAT ?= $(CC)
>   CC_COMPAT += --target=arm-linux-gnueabi
> +# Some distributions (such as Debian) change the default CPU for the
> +# arm-linux-gnueabi target triple, which can break the build. Explicitly set
> +# the CPU to generic, which is the default for Linux in LLVM.
> +CC_COMPAT += -mcpu=generic
>   else
>   CC_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc
>   endif
>
> The failures for all the ARCH=arm configurations appear to be much more
> difficult to fix because the default CPU value changes based on the
> '-march' value, which basically means that we would have to hardcode
> LLVM's default CPU logic into the kernel's Makefile, which is just not
> maintainable in my opinion. Just doing a multi_v7_defconfig build of
> arch/arm/ shows the value returned from ARM::getARMCPUForArch() in
> llvm/lib/TargetParser/ARMTargetParser.cpp can vary between "arm7tdmi" or
> "generic". Supplying '-mcpu=generic' explicitly won't work with
> LLVM_IAS=0 because GNU as does not support it and clang just happily
> passes it along, even though it does not do that in the implicit default
> case.
>
> Sylvestre, I strongly believe you should consider reverting that change
> or give us some compiler flag that allows us to fallback to upstream
> LLVM's default CPU selection logic. I think that hardcoding Debian's
> architecture defintions based on the target triple into the compiler
> could cause issues for other projects as well. For example,
> '--target=arm-linux-gnueabi -march=armv7-a' won't actually target ARMv7:
>
>    $ echo 'int main(void) { asm("dsb"); return 0; }' | \
>          clang --target=arm-linux-gnueabi -march=armv7-a \
>          -x c -c -o /dev/null -v -
>    ...
>     "/usr/bin/clang-17" -cc1 -triple armv7-unknown-linux-gnueabi ...
>    ...
>
> vs.
>
>    $ echo 'int main(void) { asm("dsb"); return 0; }' | \
>          clang --target=arm-linux-gnueabi -march=armv7-a \
>          -x c -c -o /dev/null -v -
>    ...
>    "<prefix>/bin/clang-18" -cc1 -triple armv5e-unknown-linux-gnueabi ...
>    ...
>
I guess it is this patch, right?

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/97633b6d51ebc8579c5dbecd12a02fb933620620

if so, do you want me to revert it?

Thanks
S



From ilkka at os.amperecomputing.com  Mon Dec  4 14:44:54 2023
From: ilkka at os.amperecomputing.com (Ilkka Koskinen)
Date: Mon, 4 Dec 2023 14:44:54 -0800 (PST)
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <20231204182330.654255-1-irogers@google.com>
References: <20231204182330.654255-1-irogers@google.com>
Message-ID: <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>



On Mon, 4 Dec 2023, Ian Rogers wrote:
> A metric is default by having "Default" within its groups. The default
> metricgroup name needn't be set and this can result in segv in
> default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
> that assume it has a value when there is a Default metric group. To
> avoid the segv initialize the value to "".
>
> Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
> Signed-off-by: Ian Rogers <irogers at google.com>

Thanks! I was going to look for the bug but got pulled to other 
tasks. The patch looks good to me and I tested it successfully on 
AmpereOne.

   Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>


Cheers, Ilkka

> ---
> tools/perf/util/metricgroup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 0484736d9fe4..ca3e0404f187 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -225,7 +225,7 @@ static struct metric *metric__new(const struct pmu_metric *pm,
>
> 	m->pmu = pm->pmu ?: "cpu";
> 	m->metric_name = pm->metric_name;
> -	m->default_metricgroup_name = pm->default_metricgroup_name;
> +	m->default_metricgroup_name = pm->default_metricgroup_name ?: "";
> 	m->modifier = NULL;
> 	if (modifier) {
> 		m->modifier = strdup(modifier);
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
>
>


From nathan at kernel.org  Mon Dec  4 14:51:48 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Mon, 4 Dec 2023 15:51:48 -0700
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error:
 instruction variant requires ARMv6 or later
In-Reply-To: <c61f61c9-3bfb-4ffd-adaf-1313965b3037@debian.org>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
 <20231204181304.GA2043538@dev-arch.thelio-3990X>
 <20231204223317.GA2053629@dev-arch.thelio-3990X>
 <c61f61c9-3bfb-4ffd-adaf-1313965b3037@debian.org>
Message-ID: <20231204225148.GA2094126@dev-arch.thelio-3990X>

On Mon, Dec 04, 2023 at 11:42:02PM +0100, Sylvestre Ledru wrote:
> Hello,
> 
> 
> Le 04/12/2023 ? 23:33, Nathan Chancellor a ?crit?:
> > On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote:
> > > Hi Naresh,
> > > 
> > > On Mon, Dec 04, 2023 at 05:33:26PM +0530, Naresh Kamboju wrote:
> > > > Following build errors noticed on Linux next-20231204 tag with clang-nightly
> > > > for arm and arm64.
> > > > 
> > > > ## Test Regressions (compared to next-20231201)
> > > > * arm64, build
> > > >    - clang-nightly-defconfig
> > > >    - clang-nightly-defconfig-40bc7ee5
> > > >    - clang-nightly-lkftconfig
> > > >    - clang-nightly-lkftconfig-kselftest
> > > > 
> > > > * arm, build
> > > >    - clang-nightly-allnoconfig
> > > >    - clang-nightly-axm55xx_defconfig
> > > >    - clang-nightly-bcm2835_defconfig
> > > >    - clang-nightly-clps711x_defconfig
> > > >    - clang-nightly-defconfig
> > > >    - clang-nightly-exynos_defconfig
> > > >    - clang-nightly-imx_v6_v7_defconfig
> > > >    - clang-nightly-keystone_defconfig
> > > >    - clang-nightly-lkftconfig
> > > >    - clang-nightly-lkftconfig-kselftest
> > > >    - clang-nightly-omap2plus_defconfig
> > > >    - clang-nightly-pxa910_defconfig
> > > >    - clang-nightly-s3c6400_defconfig
> > > >    - clang-nightly-s5pv210_defconfig
> > > >    - clang-nightly-sama5_defconfig
> > > >    - clang-nightly-shmobile_defconfig
> > > >    - clang-nightly-tinyconfig
> > > >    - clang-nightly-u8500_defconfig
> > > >    - clang-nightly-vexpress_defconfig
> > > > 
> > > > 
> > > > Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
> > > > 
> > > > 
> > > > Build log on arm64:
> > > > ---------
> > > > In file included from lib/vdso/gettimeofday.c:5:
> > > > In file included from include/vdso/datapage.h:135:
> > > > arch/arm64/include/asm/vdso/compat_gettimeofday.h:152:15: error:
> > > > instruction variant requires ARMv6 or later
> > > >    152 |         asm volatile("mov %0, %1" : "=r"(ret) : "r"(_vdso_data));
> > > >        |                      ^
> > > > <inline asm>:1:2: note: instantiated into assembly here
> > > >      1 |         mov r4, r1
> > > >        |         ^
> > > > In file included from <built-in>:3:
> > > > lib/vdso/gettimeofday.c:139:3: error: invalid instruction
> > > >    139 |                 smp_rmb();
> > > >        |                 ^
> > > > 
> > > > Build log on arm:
> > > > ---------
> > > > In file included from arch/arm/vfp/vfpmodule.c:23:
> > > > arch/arm/include/asm/cp15.h:101:2: error: instruction requires: data-barriers
> > > >    101 |         isb();
> > > >        |         ^
> > > This is caused by a change to Debian's LLVM that changes the internal
> > > defaults of the arm-linux-gnueabi and arm-linux-gnueabihf tuples:
> > > 
> > > https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/907baf024b9a5a1626893d9e731b6c79ccf45c87
> > > 
> > > We use arm-linux-gnueabi for the kernel (see scripts/Makefile.clang) so
> > > now we have a hardcoded armv5te CPU, even if we are building for armv7
> > > or such.
> > > 
> > > I am still investigating into what (if anything) can be done to resolve
> > > this on the kernel side. We could potentially revert commit
> > > ddc72c9659b5 ("kbuild: clang: do not use CROSS_COMPILE for target
> > > triple") but I am not sure that will save us from that change, as
> > > tuxmake's CROSS_COMPILE=arm-linux-gnueabihf will cause us to have an
> > > armv7 CPU even though we may not be building for armv7.
> > Okay, this is a pretty awful situation the more I look into it :(
> > 
> > The arm64 compat vDSO build is easy enough to fix because we require use
> > of the integrated assembler, which means we can add '-mcpu=generic' (the
> > default in LLVM for those files based on my debugging) to those files
> > and be done with it:
> > 
> > diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> > index 1f911a76c5af..5f5cb722cfc2 100644
> > --- a/arch/arm64/kernel/vdso32/Makefile
> > +++ b/arch/arm64/kernel/vdso32/Makefile
> > @@ -9,6 +9,10 @@ include $(srctree)/lib/vdso/Makefile
> >   ifeq ($(CONFIG_CC_IS_CLANG), y)
> >   CC_COMPAT ?= $(CC)
> >   CC_COMPAT += --target=arm-linux-gnueabi
> > +# Some distributions (such as Debian) change the default CPU for the
> > +# arm-linux-gnueabi target triple, which can break the build. Explicitly set
> > +# the CPU to generic, which is the default for Linux in LLVM.
> > +CC_COMPAT += -mcpu=generic
> >   else
> >   CC_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc
> >   endif
> > 
> > The failures for all the ARCH=arm configurations appear to be much more
> > difficult to fix because the default CPU value changes based on the
> > '-march' value, which basically means that we would have to hardcode
> > LLVM's default CPU logic into the kernel's Makefile, which is just not
> > maintainable in my opinion. Just doing a multi_v7_defconfig build of
> > arch/arm/ shows the value returned from ARM::getARMCPUForArch() in
> > llvm/lib/TargetParser/ARMTargetParser.cpp can vary between "arm7tdmi" or
> > "generic". Supplying '-mcpu=generic' explicitly won't work with
> > LLVM_IAS=0 because GNU as does not support it and clang just happily
> > passes it along, even though it does not do that in the implicit default
> > case.
> > 
> > Sylvestre, I strongly believe you should consider reverting that change
> > or give us some compiler flag that allows us to fallback to upstream
> > LLVM's default CPU selection logic. I think that hardcoding Debian's
> > architecture defintions based on the target triple into the compiler
> > could cause issues for other projects as well. For example,
> > '--target=arm-linux-gnueabi -march=armv7-a' won't actually target ARMv7:
> > 
> >    $ echo 'int main(void) { asm("dsb"); return 0; }' | \
> >          clang --target=arm-linux-gnueabi -march=armv7-a \
> >          -x c -c -o /dev/null -v -
> >    ...
> >     "/usr/bin/clang-17" -cc1 -triple armv7-unknown-linux-gnueabi ...
> >    ...
> > 
> > vs.
> > 
> >    $ echo 'int main(void) { asm("dsb"); return 0; }' | \
> >          clang --target=arm-linux-gnueabi -march=armv7-a \
> >          -x c -c -o /dev/null -v -
> >    ...
> >    "<prefix>/bin/clang-18" -cc1 -triple armv5e-unknown-linux-gnueabi ...
> >    ...
> > 
> I guess it is this patch, right?
> 
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/97633b6d51ebc8579c5dbecd12a02fb933620620

Right, I should have made that clearer when bringing you in (I linked to
the snapshot version of that change further up in the thread).

> if so, do you want me to revert it?

Yes, I think it should be reverted.

Cheers,
Nathan


From quic_djaggi at quicinc.com  Mon Dec  4 15:50:31 2023
From: quic_djaggi at quicinc.com (Deepti Jaggi)
Date: Mon, 4 Dec 2023 15:50:31 -0800
Subject: [PATCH v6 00/13] arm64: qcom: add and enable SHM Bridge support
In-Reply-To: <20231127141600.20929-1-brgl@bgdev.pl>
References: <20231127141600.20929-1-brgl@bgdev.pl>
Message-ID: <fdd1caf6-66dc-485d-bd03-72e7ac99f571@quicinc.com>



On 11/27/2023 6:15 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> 
> This is pretty much another full rewrite of the SHM Bridge support
> series. After more on- and off-list discussions I think this time it
> will be close to the final thing though.
> 
> We've established the need for using separate pools for SCM and QSEECOM
> as well as the upcoming scminvoke driver.
> 
> It's also become clear that in order to be future-proof, the new
> allocator must be an abstraction layer of a higher level as the SHM
> Bridge will not be the only memory protection mechanism that we'll see
> upstream. Hence the rename to TrustZone Memory rather than SCM Memory
> allocator.
> 
> Also to that end: the new allocator is its own module now and provides a
> Kconfig choice menu for selecting the mode of operation (currently
> default and SHM Bridge).
> 
> Due to a high divergence from v2, I dropped all tags except for
> patch 1/15 which didn't change.
> 
> Tested on sm8550 and sa8775p with the Inline Crypto Engine and
> remoteproc.
> 
> v5 -> v6:
> Fixed two issues reported by autobuilders:
> - add a fix for memory leaks in the qseecom driver as the first patch for
>   easier backporting to the v6.6.y branch
> - explicitly cast the bus address stored in a variable of type dma_addr_t
>   to phys_addr_t expected by the genpool API
> 
> v4 -> v5:
> - fix the return value from qcom_tzmem_init() if SHM Bridge is not supported
> - remove a comment that's no longer useful
> - collect tags
> 
> v3 -> v4:
> - include linux/sizes.h for SZ_X macros
> - use dedicated RCU APIs to dereference radix tree slots
> - fix kerneldocs
> - fix the comment in patch 14/15: it's the hypervisor, not the TrustZone
>   that creates the SHM bridge
> 
> v2 -> v3:
> - restore pool management and use separate pools for different users
> - don't use the new allocator in qcom_scm_pas_init_image() as the
>   TrustZone will create an SHM bridge for us here
> - rewrite the entire series again for most part
> 
> v1 -> v2:
> - too many changes to list, it's a complete rewrite as explained above
> 
> Bartosz Golaszewski (13):
>   firmware: qcom: qseecom: fix memory leaks in error paths
>   firmware: qcom: add a dedicated TrustZone buffer allocator
>   firmware: qcom: scm: enable the TZ mem allocator
>   firmware: qcom: scm: smc: switch to using the SCM allocator
>   firmware: qcom: scm: make qcom_scm_assign_mem() use the TZ allocator
>   firmware: qcom: scm: make qcom_scm_ice_set_key() use the TZ allocator
>   firmware: qcom: scm: make qcom_scm_lmh_dcvsh() use the TZ allocator
>   firmware: qcom: scm: make qcom_scm_qseecom_app_get_id() use the TZ
>     allocator
>   firmware: qcom: qseecom: convert to using the TZ allocator
>   firmware: qcom: scm: add support for SHM bridge operations
>   firmware: qcom: tzmem: enable SHM Bridge support
>   firmware: qcom: scm: clarify the comment in qcom_scm_pas_init_image()
>   arm64: defconfig: enable SHM Bridge support for the TZ memory
>     allocator
> 
>  arch/arm64/configs/defconfig                  |   1 +
>  drivers/firmware/qcom/Kconfig                 |  30 ++
>  drivers/firmware/qcom/Makefile                |   1 +
>  .../firmware/qcom/qcom_qseecom_uefisecapp.c   | 261 +++++--------
>  drivers/firmware/qcom/qcom_scm-smc.c          |  30 +-
>  drivers/firmware/qcom/qcom_scm.c              | 179 +++++----
>  drivers/firmware/qcom/qcom_scm.h              |   6 +
>  drivers/firmware/qcom/qcom_tzmem.c            | 365 ++++++++++++++++++
>  drivers/firmware/qcom/qcom_tzmem.h            |  13 +
>  include/linux/firmware/qcom/qcom_qseecom.h    |   4 +-
>  include/linux/firmware/qcom/qcom_scm.h        |   6 +
>  include/linux/firmware/qcom/qcom_tzmem.h      |  28 ++
>  12 files changed, 669 insertions(+), 255 deletions(-)
>  create mode 100644 drivers/firmware/qcom/qcom_tzmem.c
>  create mode 100644 drivers/firmware/qcom/qcom_tzmem.h
>  create mode 100644 include/linux/firmware/qcom/qcom_tzmem.h
> 
Verified the following :
Shm Bridge creation
Successful qcom_scm_assign_mem calls using tz allocator 

Tested-by: Deepti Jaggi <quic_djaggi at quicinc.com> #sa8775p-ride


From heiko at sntech.de  Mon Dec  4 16:05:59 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 01:05:59 +0100
Subject: [PATCH v3 0/3] Add power-controller and gpu for RK3128
In-Reply-To: <20231204153547.97877-1-knaerzche@gmail.com>
References: <20231204153547.97877-1-knaerzche@gmail.com>
Message-ID: <170173468933.501889.16032345540267173122.b4-ty@sntech.de>

On Mon, 4 Dec 2023 16:35:44 +0100, Alex Bee wrote:
> This series adds the power-controller and the gpu to RK3128's SoC
> devicetree - both are already supported by the respective drivers.
> Patch 3 enables the gpu for XPI-3128 board.
> 
> changes in v3:
>  - dropped patches for not-yet needed power domains
>  - dropped dt-bindings patches which was already merged
> 
> [...]

Applied, thanks!

[1/3] ARM: dts: rockchip: Add power-controller for RK3128
      commit: 5e806176a3a57a530d0220242141b30056a70918
[2/3] ARM: dts: rockchip: Add GPU node for RK3128
      commit: 2cc98b5080f693d718cc17c136180732cc32f73b
[3/3] ARM: dts: rockchip: Enable GPU for XPI-3128
      commit: d892a562110ebe7935c60548a1a3924fb36eca5c

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Mon Dec  4 16:05:58 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 01:05:58 +0100
Subject: [PATCH 0/3] Move core bus and gpio aliases to SoC dtsi for RK3128
In-Reply-To: <20231202130506.66738-2-knaerzche@gmail.com>
References: <20231202130506.66738-2-knaerzche@gmail.com>
Message-ID: <170173468934.501889.12474504620278418598.b4-ty@sntech.de>

On Sat, 2 Dec 2023 14:05:04 +0100, Alex Bee wrote:
> Following up the recent discussion [0] about where aliases can be/should be
> placed this series moves gpio, i2c and uart aliases to SoC dtsi for RK3128.
> 
> Note: This patches are based on maintainter's repo.
> 
> [0] https://lore.kernel.org/all/b0c637f5-5abf-420b-8b02-839eba68799e at linaro.org/T/#m94aebb23a29b015d94b250a70b675febdaa902ea
> 
> [...]

Applied, thanks!

[1/3] ARM: dts: rockchip: Move gpio aliases to SoC dtsi for RK3128
      commit: 3b0422a4ce59d8afb84bd7516bf71a3c1caa7925
[2/3] ARM: dts: rockchip: Move i2c aliases to SoC dtsi for RK3128
      commit: 39732a49803cf271454416341549df09c4a2fd2f

I also applied patch 3 ... though had to pick it manually from the list
as the subject was a bit garbled (missing 3/3), so b4 did not pick it up.


Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Mon Dec  4 16:05:57 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 01:05:57 +0100
Subject: [PATCH] arm64: dts: rockchip: drop interrupt-names property from rk3588s dfi
In-Reply-To: <20231201134859.322491-1-heiko@sntech.de>
References: <20231201134859.322491-1-heiko@sntech.de>
Message-ID: <170173468935.501889.16956893001604637055.b4-ty@sntech.de>

On Fri, 1 Dec 2023 14:48:59 +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner at cherry.de>
> 
> The dfi binding does not specify interrupt names, with the interrupts
> just specifying channels 0-x. So drop the unspecified property.
> 
> 

Applied, thanks!

[1/1] arm64: dts: rockchip: drop interrupt-names property from rk3588s dfi
      commit: 815f986f33eeb06652d59d8a4d405d4fdb4e59a8

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Mon Dec  4 16:06:00 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 01:06:00 +0100
Subject: [PATCH] arm64: dts: rockchip: rk3399-gru: Fix PCI node addresses
In-Reply-To: <20231130191830.2424361-1-robh@kernel.org>
References: <20231130191830.2424361-1-robh@kernel.org>
Message-ID: <170173468936.501889.14178301756278206830.b4-ty@sntech.de>

On Thu, 30 Nov 2023 13:18:29 -0600, Rob Herring wrote:
> The rk3399-gru PCI node addresses are wrong.
> 
> In rk3399-gru-scarlet, the bus number in the address should be 0. This is
> because bus number assignment is dynamic and not known up front. For FDT,
> the bus number is simply ignored.
> 
> In rk3399-gru-chromebook, the addresses are simply invalid. The first
> "reg" entry must be the configuration space for the device. The entry
> should be all 0s except for device/slot and function numbers. The existing
> 64-bit memory space (0x83000000) entries are not valid because they must
> have the BAR address in the lower byte of the first cell.
> 
> [...]

Applied, thanks!

[1/1] arm64: dts: rockchip: rk3399-gru: Fix PCI node addresses
      commit: c13c823a78b77ea0e5f1f73112d910e259911101

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Mon Dec  4 16:06:01 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 01:06:01 +0100
Subject: (subset) [PATCH v3 0/8] Add support for Sonoff iHost RV1126 Smart Home Gateway
In-Reply-To: <20231203124004.2676174-1-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
Message-ID: <170173468934.501889.1733383840975468730.b4-ty@sntech.de>

On Sun, 3 Dec 2023 23:39:56 +1100, Tim Lunn wrote:
> Sonoff iHost is gateway device designed to provide a Smart Home Hub,
> most notably it includes builtin radios for Wifi, BT and Zigbee, which
> make it suitable SBC for use with many of the open home automation
> platforms. It is availabe in two versions, first is based on
> Rockchip RV1126 and 4GB DDR4 RAM. There is a second version based off
> the RV1109 dual core SoC and 2GB RAM.
> 
> [...]

Applied, thanks!

[1/8] ARM: dts: rockchip: rv1126: Add alternate UART pins
      commit: 86fd29b0329c95d4136a5dcef555287a0be8a038
[2/8] ARM: dts: rockchip: rv1126: Serial aliases
      commit: 30250a587bddb5265bceb9f8397c459f5cc04e0c
[4/8] ARM: dts: rockchip: rv1126: Add i2c2 nodes
      commit: 655ff5d45dc9de5e67c839af4baf47eaffed348f
[5/8] ARM: dts: rockchip: rv1126: Split up rgmii1 pinctrl
      commit: d3bab19c83c7ce24e89d9f08f09e596c39b14658
[6/8] ARM: dts: rockchip: Add rv1109 SoC
      commit: bd6f1b13b972caebf54be1fb3bc2eb9f47de9d63
[7/8] ARM: dts: Add Sonoff iHost Smart Home Hub
      commit: 0f385eea8157bcb36d30d9f96105251465bc6684
[8/8] dt-bindings: arm: rockchip: Add Sonoff iHost
      commit: 98feed126e7dcae617af3b0e76f50160806e3233

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From cl at gentwo.org  Mon Dec  4 16:25:05 2023
From: cl at gentwo.org (Christoph Lameter (Ampere))
Date: Mon, 04 Dec 2023 16:25:05 -0800
Subject: [RFC 0/8] ARM64 TLB logic revision for more control and enhanced diagnostics
Message-ID: <20231205002505.830023267@gentwo.org>

WARNING: First draft of the patchset, tested with kernel compiles, may
corrupt your memory.

This patchset intends to aid in help debugging and scaling TLB operations
on ARM64. This is in particular desirable for ARM architectures with
large numbers of cores. What is often seen is that the mesh is flooded with
snoop traffic that is related to TLBI broadcasts.

The patchset adds the following features:

- Allow diagnostics via /proc/vmstat like already possible on X86 with the
	CONFIG_DEBUG_TLB  option.

  Some sample output:

  cat /proc/vmstat
	...
	nr_tlb_remote_flush 554104		Flushes converted to IPIs with local flushing
	nr_tlb_remote_flush_received 1312243	IPIs received to perform local flushing
	nr_tlb_local_flush_all 141837		Local flush alls
	nr_tlb_local_flush_range 571784		Local flush range
	nr_tlb_local_flush_one 8011880		Local individual page flushes
	nr_tlb_flush_all 28239			Flush alls through the mesh
	nr_tlb_flush_range 13003		Flush range through the mesh
	nr_tlb_flush_one 54764			Flush one through the mesh
	nr_tlb_skipped 0			Suppressed flush

- Tracks the cores that have used an address space. With that we can
	compute the weight of cpus that have used this address space
	to decide on how to optimally do the flushing when such an action
	is required.

- Control the TLB flushing behavior via the kernel command line and also on a running system.

    New Kernel parameter  tlb_mode=<tlb_mode>
    New sysfs setting     /sys/kernel/debug/tlb_mode

	tlb_mode is comprised of a set of flags starting at bit 10. Bit 0-9
	are used to set a boundary as to what cpu weight will lead to a mesh
	flush. If the cpu weight is lower then IPIs are send avoiding the mesh.

	Feature flags:

	Bit 10 = If the current cpu is the only one that has ever used an
			address space then perform local invalidation.
			This catches the majority of flushes on boot and
			activities of typical single threaded Unixy processes.

	Bit 11 = Enable TLB range. Various hardware has problems with TLB range.
			This allows the kernel to recognize that TLB range
			should not be used and an alternate method is to be
			used to do the flushing.

	Bit 12 = Suppress TLB flushes if the address space is unused.
			If this bit is set and a flush is requested in an
			unused address space then no flush will be performed
			since there cannot any TLB entries. If this is
			not set then perform mesh flush (just to be sure).

- Autotunes the feature flags on bootup if the user has not specified tlb_mode.
	Calculates an optimal balance between IPIs and mesh flushing
	based on the number of cpus in the system. Enables local validation
	always and tlb range flushing if the processor features indicate
	that the processor supports it.


We need a more detailed description but I hope this is enough to get started.

These issues have been discussed before in an patchset that contains a similar feature 
in 2019:

https://lore.kernel.org/linux-arm-kernel/20190617143255.10462-1-indou.takao at jp.fujitsu.com/



From nicolinc at nvidia.com  Mon Dec  4 16:44:31 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 16:44:31 -0800
Subject: [PATCH v2 01/19] iommu/arm-smmu-v3: Add a type for the STE
In-Reply-To: <1-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <1-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW5yb6xSkj5zP1Fd@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:08PM -0400, Jason Gunthorpe wrote:
> Instead of passing a naked __le16 * around to represent a STE wrap it in a
> "struct arm_smmu_ste" with an array of the correct size. This makes it
> much clearer which functions will comprise the "STE API".
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nicolinc at nvidia.com  Mon Dec  4 16:45:49 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 16:45:49 -0800
Subject: [PATCH v2 02/19] iommu/arm-smmu-v3: Master cannot be NULL in
 arm_smmu_write_strtab_ent()
In-Reply-To: <2-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <2-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW5yvSwKDZtIFlNG@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:09PM -0400, Jason Gunthorpe wrote:
> The only caller is arm_smmu_install_ste_for_dev() which never has a NULL
> master. Remove the confusing if.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nicolinc at nvidia.com  Mon Dec  4 16:46:50 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 16:46:50 -0800
Subject: [PATCH v2 03/19] iommu/arm-smmu-v3: Remove ARM_SMMU_DOMAIN_NESTED
In-Reply-To: <3-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <3-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW5y+tRqmpddDNHT@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:10PM -0400, Jason Gunthorpe wrote:
> Currently this is exactly the same as ARM_SMMU_DOMAIN_S2, so just remove
> it. The ongoing work to add nesting support through iommufd will do
> something a little different.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From marex at denx.de  Mon Dec  4 16:50:57 2023
From: marex at denx.de (Marek Vasut)
Date: Tue,  5 Dec 2023 01:50:57 +0100
Subject: [PATCH] serial: imx: Fix clock imbalance
Message-ID: <20231205005108.79782-1-marex@denx.de>

Disable and unprepare the clock on every exit from probe function
after the clock were prepared and enabled to avoid enable/disable
imbalance.

Signed-off-by: Marek Vasut <marex at denx.de>
---
Cc: "Ilpo J?rvinen" <ilpo.jarvinen at linux.intel.com>
Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
Cc: Fabio Estevam <festevam at gmail.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Jiri Slaby <jirislaby at kernel.org>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
Cc: Rob Herring <robh at kernel.org>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Sergey Organov <sorganov at gmail.com>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Tom Rix <trix at redhat.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-serial at vger.kernel.org
---
 drivers/tty/serial/imx.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 52dd8a6b87603..1cce66e5d05d8 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2332,10 +2332,8 @@ static int imx_uart_probe(struct platform_device *pdev)
 	}
 
 	ret = uart_get_rs485_mode(&sport->port);
-	if (ret) {
-		clk_disable_unprepare(sport->clk_ipg);
-		return ret;
-	}
+	if (ret)
+		goto err_clk;
 
 	if (sport->port.rs485.flags & SER_RS485_ENABLED &&
 	    (!sport->have_rtscts && !sport->have_rtsgpio))
@@ -2436,7 +2434,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(&pdev->dev, "failed to request rx irq: %d\n",
 				ret);
-			return ret;
+			goto err_clk;
 		}
 
 		ret = devm_request_irq(&pdev->dev, txirq, imx_uart_txint, 0,
@@ -2444,7 +2442,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(&pdev->dev, "failed to request tx irq: %d\n",
 				ret);
-			return ret;
+			goto err_clk;
 		}
 
 		ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
@@ -2452,14 +2450,14 @@ static int imx_uart_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(&pdev->dev, "failed to request rts irq: %d\n",
 				ret);
-			return ret;
+			goto err_clk;
 		}
 	} else {
 		ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
 				       dev_name(&pdev->dev), sport);
 		if (ret) {
 			dev_err(&pdev->dev, "failed to request irq: %d\n", ret);
-			return ret;
+			goto err_clk;
 		}
 	}
 
@@ -2468,6 +2466,10 @@ static int imx_uart_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, sport);
 
 	return uart_add_one_port(&imx_uart_uart_driver, &sport->port);
+
+err_clk:
+	clk_disable_unprepare(sport->clk_ipg);
+	return ret;
 }
 
 static void imx_uart_remove(struct platform_device *pdev)
-- 
2.42.0



From 21cnbao at gmail.com  Mon Dec  4 16:58:07 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Tue, 5 Dec 2023 08:58:07 +0800
Subject: [PATCH v8 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()
In-Reply-To: <20231204102027.57185-3-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com> <20231204102027.57185-3-ryan.roberts@arm.com>
Message-ID: <CAGsJ_4yyx2+BZS1-bgbJnYJ+FByrMbOqV_Aa3A-nAm2kUtPk+A@mail.gmail.com>

On Mon, Dec 4, 2023 at 6:20?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>
> In preparation for supporting anonymous multi-size THP, improve
> folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be
> passed to it. In this case, all contained pages are accounted using the
> order-0 folio (or base page) scheme.
>
> Reviewed-by: Yu Zhao <yuzhao at google.com>
> Reviewed-by: Yin Fengwei <fengwei.yin at intel.com>
> Reviewed-by: David Hildenbrand <david at redhat.com>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>

Reviewed-by: Barry Song <v-songbaohua at oppo.com>

> ---
>  mm/rmap.c | 28 ++++++++++++++++++++--------
>  1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 2a1e45e6419f..846fc79f3ca9 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma,
>   * This means the inc-and-test can be bypassed.
>   * The folio does not have to be locked.
>   *
> - * If the folio is large, it is accounted as a THP.  As the folio
> + * If the folio is pmd-mappable, it is accounted as a THP.  As the folio
>   * is new, it's assumed to be mapped exclusively by a single process.
>   */
>  void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
>                 unsigned long address)
>  {
> -       int nr;
> +       int nr = folio_nr_pages(folio);
>
> -       VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
> +       VM_BUG_ON_VMA(address < vma->vm_start ||
> +                       address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
>         __folio_set_swapbacked(folio);
> +       __folio_set_anon(folio, vma, address, true);
>
> -       if (likely(!folio_test_pmd_mappable(folio))) {
> +       if (likely(!folio_test_large(folio))) {
>                 /* increment count (starts at -1) */
>                 atomic_set(&folio->_mapcount, 0);
> -               nr = 1;
> +               SetPageAnonExclusive(&folio->page);
> +       } else if (!folio_test_pmd_mappable(folio)) {
> +               int i;
> +
> +               for (i = 0; i < nr; i++) {
> +                       struct page *page = folio_page(folio, i);
> +
> +                       /* increment count (starts at -1) */
> +                       atomic_set(&page->_mapcount, 0);
> +                       SetPageAnonExclusive(page);
> +               }
> +
> +               atomic_set(&folio->_nr_pages_mapped, nr);
>         } else {
>                 /* increment count (starts at -1) */
>                 atomic_set(&folio->_entire_mapcount, 0);
>                 atomic_set(&folio->_nr_pages_mapped, COMPOUND_MAPPED);
> -               nr = folio_nr_pages(folio);
> +               SetPageAnonExclusive(&folio->page);
>                 __lruvec_stat_mod_folio(folio, NR_ANON_THPS, nr);
>         }
>
>         __lruvec_stat_mod_folio(folio, NR_ANON_MAPPED, nr);
> -       __folio_set_anon(folio, vma, address, true);
> -       SetPageAnonExclusive(&folio->page);
>  }
>
>  /**
> --
> 2.25.1
>


From andi.shyti at kernel.org  Mon Dec  4 17:08:16 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Tue, 5 Dec 2023 02:08:16 +0100
Subject: [PATCH v3 3/8] i2c: rk3x: Adjust mask/value offset for i2c2 on
 rv1126
In-Reply-To: <4850448.MsWZr2WtbB@diego>
References: <20231203124004.2676174-1-tim@feathertop.org>
 <4413905.22IY78Rhhi@diego>
 <20231203215530.mewjd7n7ltaeed3w@zenone.zhora.eu>
 <4850448.MsWZr2WtbB@diego>
Message-ID: <20231205010816.bza72xirj2xbufzu@zenone.zhora.eu>

Hi Heiko,

On Mon, Dec 04, 2023 at 12:36:43PM +0100, Heiko St?bner wrote:
> Am Sonntag, 3. Dezember 2023, 22:55:30 CET schrieb Andi Shyti:
> > On Sun, Dec 03, 2023 at 08:48:43PM +0100, Heiko St?bner wrote:
> > > Am Sonntag, 3. Dezember 2023, 20:06:20 CET schrieb Andi Shyti:
> > > > On Sun, Dec 03, 2023 at 11:39:59PM +1100, Tim Lunn wrote:
> > > > > Rockchip RV1126 is using old style i2c controller, the i2c2
> > > > > bus uses a non-sequential offset in the grf register for the
> > > > > mask/value bits for this bus.
> > > > > 
> > > > > This patch fixes i2c2 bus on rv1126 SoCs.
> > > > > 
> > > > > Signed-off-by: Tim Lunn <tim at feathertop.org>
> > > > > Acked-by: Heiko Stuebner <heiko at sntech.de>
> > > > 
> > > > Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
> > > 
> > > you're listed as the maintainer for the i2c busses,
> > > are you going to pick this one patch yourself?
> > > Or do you expect a different handling?
> > > 
> > > I.e. it doesn't really tie into the dts patches and everything will come
> > > together nicely in linux-next and during the next merge-window.
> > 
> > Wolfram are you going to take this?
> 
> I was going by get_maintainer.pl showing
> Andi Shyti <andi.shyti at kernel.org> (maintainer:I2C SUBSYSTEM HOST DRIVERS)
> 
> hence the question :-)

Ack, patch 3 we will take it through i2c.

Thanks,
Andi


From 21cnbao at gmail.com  Mon Dec  4 17:15:34 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Tue, 5 Dec 2023 09:15:34 +0800
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <20231204102027.57185-5-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com> <20231204102027.57185-5-ryan.roberts@arm.com>
Message-ID: <CAGsJ_4zG6W_Z-u+3QcRDn4ByoeqUXjMusNS0RotfRMSqo8RCHg@mail.gmail.com>

On Mon, Dec 4, 2023 at 6:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>
> Introduce the logic to allow THP to be configured (through the new sysfs
> interface we just added) to allocate large folios to back anonymous
> memory, which are larger than the base page size but smaller than
> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>
> mTHP continues to be PTE-mapped, but in many cases can still provide
> similar benefits to traditional PMD-sized THP: Page faults are
> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
> the configured order), but latency spikes are much less prominent
> because the size of each page isn't as huge as the PMD-sized variant and
> there is less memory to clear in each page fault. The number of per-page
> operations (e.g. ref counting, rmap management, lru list management) are
> also significantly reduced since those ops now become per-folio.
>
> Some architectures also employ TLB compression mechanisms to squeeze
> more entries in when a set of PTEs are virtually and physically
> contiguous and approporiately aligned. In this case, TLB misses will
> occur less often.
>
> The new behaviour is disabled by default, but can be enabled at runtime
> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
> (see documentation in previous commit). The long term aim is to change
> the default to include suitable lower orders, but there are some risks
> around internal fragmentation that need to be better understood first.
>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>  include/linux/huge_mm.h |   6 ++-
>  mm/memory.c             | 106 ++++++++++++++++++++++++++++++++++++----
>  2 files changed, 101 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index bd0eadd3befb..91a53b9835a4 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>  #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>
>  /*
> - * Mask of all large folio orders supported for anonymous THP.
> + * Mask of all large folio orders supported for anonymous THP; all orders up to
> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
> + * (which is a limitation of the THP implementation).
>   */
> -#define THP_ORDERS_ALL_ANON    BIT(PMD_ORDER)
> +#define THP_ORDERS_ALL_ANON    ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>
>  /*
>   * Mask of all large folio orders supported for file THP.
> diff --git a/mm/memory.c b/mm/memory.c
> index 3ceeb0f45bf5..bf7e93813018 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>         return ret;
>  }
>
> +static bool pte_range_none(pte_t *pte, int nr_pages)
> +{
> +       int i;
> +
> +       for (i = 0; i < nr_pages; i++) {
> +               if (!pte_none(ptep_get_lockless(pte + i)))
> +                       return false;
> +       }
> +
> +       return true;
> +}
> +
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
> +{
> +       gfp_t gfp;
> +       pte_t *pte;
> +       unsigned long addr;
> +       struct folio *folio;
> +       struct vm_area_struct *vma = vmf->vma;
> +       unsigned long orders;
> +       int order;
> +
> +       /*
> +        * If uffd is active for the vma we need per-page fault fidelity to
> +        * maintain the uffd semantics.
> +        */
> +       if (userfaultfd_armed(vma))
> +               goto fallback;
> +
> +       /*
> +        * Get a list of all the (large) orders below PMD_ORDER that are enabled
> +        * for this vma. Then filter out the orders that can't be allocated over
> +        * the faulting address and still be fully contained in the vma.
> +        */
> +       orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
> +                                         BIT(PMD_ORDER) - 1);
> +       orders = thp_vma_suitable_orders(vma, vmf->address, orders);
> +
> +       if (!orders)
> +               goto fallback;
> +
> +       pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
> +       if (!pte)
> +               return ERR_PTR(-EAGAIN);
> +
> +       order = first_order(orders);
> +       while (orders) {
> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> +               vmf->pte = pte + pte_index(addr);
> +               if (pte_range_none(vmf->pte, 1 << order))
> +                       break;
> +               order = next_order(&orders, order);
> +       }
> +
> +       vmf->pte = NULL;
> +       pte_unmap(pte);
> +
> +       gfp = vma_thp_gfp_mask(vma);
> +
> +       while (orders) {
> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> +               folio = vma_alloc_folio(gfp, order, vma, addr, true);
> +               if (folio) {
> +                       clear_huge_page(&folio->page, addr, 1 << order);

Minor.

Do we have to constantly clear a huge page? Is it possible to let
post_alloc_hook()
finish this job by using __GFP_ZERO/__GFP_ZEROTAGS as
vma_alloc_zeroed_movable_folio() is doing?

struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
                                                unsigned long vaddr)
{
        gfp_t flags = GFP_HIGHUSER_MOVABLE | __GFP_ZERO;

        /*
         * If the page is mapped with PROT_MTE, initialise the tags at the
         * point of allocation and page zeroing as this is usually faster than
         * separate DC ZVA and STGM.
         */
        if (vma->vm_flags & VM_MTE)
                flags |= __GFP_ZEROTAGS;

        return vma_alloc_folio(flags, 0, vma, vaddr, false);
}

> +                       return folio;
> +               }
> +               order = next_order(&orders, order);
> +       }
> +
> +fallback:
> +       return vma_alloc_zeroed_movable_folio(vma, vmf->address);
> +}
> +#else
> +#define alloc_anon_folio(vmf) \
> +               vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
> +#endif
> +
>  /*
>   * We enter with non-exclusive mmap_lock (to exclude vma changes,
>   * but allow concurrent faults), and pte mapped but not yet locked.
> @@ -4132,6 +4210,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>   */
>  static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>  {
> +       int i;
> +       int nr_pages = 1;
> +       unsigned long addr = vmf->address;
>         bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
>         struct vm_area_struct *vma = vmf->vma;
>         struct folio *folio;
> @@ -4176,10 +4257,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>         /* Allocate our own private page. */
>         if (unlikely(anon_vma_prepare(vma)))
>                 goto oom;
> -       folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
> +       folio = alloc_anon_folio(vmf);
> +       if (IS_ERR(folio))
> +               return 0;
>         if (!folio)
>                 goto oom;
>
> +       nr_pages = folio_nr_pages(folio);
> +       addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
> +
>         if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
>                 goto oom_free_page;
>         folio_throttle_swaprate(folio, GFP_KERNEL);
> @@ -4196,12 +4282,13 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>         if (vma->vm_flags & VM_WRITE)
>                 entry = pte_mkwrite(pte_mkdirty(entry), vma);
>
> -       vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
> -                       &vmf->ptl);
> +       vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
>         if (!vmf->pte)
>                 goto release;
> -       if (vmf_pte_changed(vmf)) {
> -               update_mmu_tlb(vma, vmf->address, vmf->pte);
> +       if ((nr_pages == 1 && vmf_pte_changed(vmf)) ||
> +           (nr_pages  > 1 && !pte_range_none(vmf->pte, nr_pages))) {
> +               for (i = 0; i < nr_pages; i++)
> +                       update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);
>                 goto release;
>         }
>
> @@ -4216,16 +4303,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>                 return handle_userfault(vmf, VM_UFFD_MISSING);
>         }
>
> -       inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
> -       folio_add_new_anon_rmap(folio, vma, vmf->address);
> +       folio_ref_add(folio, nr_pages - 1);
> +       add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
> +       folio_add_new_anon_rmap(folio, vma, addr);
>         folio_add_lru_vma(folio, vma);
>  setpte:
>         if (uffd_wp)
>                 entry = pte_mkuffd_wp(entry);
> -       set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
> +       set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
>
>         /* No need to invalidate - it was non-present before */
> -       update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
> +       update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
>  unlock:
>         if (vmf->pte)
>                 pte_unmap_unlock(vmf->pte, vmf->ptl);
> --
> 2.25.1
>


From Axe.Yang at mediatek.com  Mon Dec  4 17:23:21 2023
From: Axe.Yang at mediatek.com (=?utf-8?B?QXhlIFlhbmcgKOadqOejiik=?=)
Date: Tue, 5 Dec 2023 01:23:21 +0000
Subject: [PATCH v2 2/2] mmc: mediatek: extend number of tuning steps
In-Reply-To: <f14e8db1-5909-4733-99b1-2abe10c4ac7e@collabora.com>
References: <20231128070127.27442-1-axe.yang@mediatek.com>
	 <20231128070127.27442-3-axe.yang@mediatek.com>
	 <207c2f89-b1e7-448d-966f-0c403a9f9e8b@collabora.com>
	 <ea1a82b07e98fa682140c460048901a9f962be2b.camel@mediatek.com>
	 <36ba3f89-2bd0-45f0-8b61-59f5c6691427@collabora.com>
	 <61afefc47b073d63f39972031be6a4dfbd3d45af.camel@mediatek.com>
	 <f14e8db1-5909-4733-99b1-2abe10c4ac7e@collabora.com>
Message-ID: <0fccba2f81984d2448643d47f2bf63c221f9504d.camel@mediatek.com>

On Fri, 2023-12-01 at 09:53 +0100, AngeloGioacchino Del Regno wrote:
> Il 29/11/23 04:16, Axe Yang (??) ha scritto:
> > On Tue, 2023-11-28 at 11:20 +0100, AngeloGioacchino Del Regno
> > wrote:
> > > Il 28/11/23 10:38, Axe Yang (??) ha scritto:
> > > > > On Tue, 2023-11-28 at 09:53 +0100, AngeloGioacchino Del Regno
> > > > > wrote:
> > > > > Il 28/11/23 08:01, Axe Yang ha scritto:
> > > > > > Previously, during the MSDC calibration process, a full
> > > > > > clock
> > > > > > cycle
> > > > > > actually not be covered, which in some cases didn't yield
> > > > > > the
> > > > > > best
> > > > > > results and could cause CRC errors. This problem is
> > > > > > particularly
> > > > > > evident when MSDC is used as an SDIO host. In fact, MSDC
> > > > > > support
> > > > > > tuning up to a maximum of 64 steps, but by default, the
> > > > > > step
> > > > > > number
> > > > > > is 32. By increase the tuning step, we are more likely to
> > > > > > cover
> > > > > > more
> > > > > > parts of a clock cycle, and get better calibration result.
> > > > > > 
> > > > > > To illustrate, when tuning 32 steps, if the obtained window
> > > > > > has
> > > > > > a
> > > > > > hole
> > > > > > near the middle, like this: 0xffc07ff (hex), then the
> > > > > > selected
> > > > > > delay
> > > > > > will be the 6 (counting from right to left).
> > > > > > 
> > > > > > (32 <- 1)
> > > > > > 1111 1111 1100 0000 0000 0111 11(1)1 1111
> > > > > > 
> > > > > > However, if we tune 64 steps, the window obtained may look
> > > > > > like
> > > > > > this:
> > > > > > 0xfffffffffffc07ff. The final selected delay will be 44,
> > > > > > which
> > > > > > is
> > > > > > safer as it is further away from the hole:
> > > > > > 
> > > > > > (64 <- 1)
> > > > > > 1111 ... (1)111 1111 1111 1111 1111 1100 0000 0000 0111
> > > > > > 1111
> > > > > > 1111
> > > > > > 
> > > > > > In this case, delay 6 selected through 32 steps tuning is
> > > > > > obviously
> > > > > > not optimal, and this delay is closer to the hole, using it
> > > > > > would
> > > > > > easily cause CRC problems.
> > > > > > 
> > > > > > You will need to configure property "mediatek,tuning-step"
> > > > > > in
> > > > > > MSDC
> > > > > > dts node to 64 to extend the steps.
> > > > > > 
> > > > > 
> > > > > If we can run 64 tuning steps, why should we run 32?
> > > > > 
> > > > > Why isn't it just better to *always* run 64 tuning steps, on
> > > > > SoCs
> > > > > supporting that?
> > > > > 
> > > > > Thanks,
> > > > > Angelo
> > > > 
> > > > Hi Angelo,
> > > > 
> > > > That is a good question. The benefit of preserving 32 steps
> > > > tuning
> > > > is
> > > > that it can save time in certain scenarios.
> > > > 
> > > > On some platforms, when the delay selected through 64 steps
> > > > tuning
> > > > is
> > > > very close to that chosen through 32 steps, we can reduce the
> > > > tuning
> > > > step from 64 to 32. This can save time sending the tuning block
> > > > commands.
> > > > 
> > > > Thus using 32 steps tuning can save kernel boot up time.
> > > > 
> > > > Another case where time can be saved is when accessing the RPMB
> > > > partition of eMMC. Each time switch to RPMB partition, there is
> > > > a
> > > > retune action, causing a certain drop in performance. If we are
> > > > certain
> > > > that the results of 32 steps tuning are usable and we use it,
> > > > this
> > > > can
> > > > in a sense also guarantee performance when accessing the RPMB
> > > > partition.
> > > > 
> > > 
> > > Thanks for this explanation! Though, I have some more
> > > questions...
> > > 
> > > ...regarding boot up time, how much time are we talking about?
> > 
> > Luckily, I have a platform at hand that can be used for
> > experiments/
> > Below are the results from testing on this platform:
> > 
> > [    2.431993][T1200180] kworker/2:21: mtk-msdc bootdevice:
> > [name:mtk_sd&]Start tuning
> > [    2.434950][T1200180] kworker/2:21: mtk-msdc bootdevice:
> > [name:mtk_sd&]Tuning finished
> > [    2.435957][T1200180] kworker/2:21: mtk-msdc bootdevice:
> > [name:mtk_sd&]phase: [map:00000000ffffffc0] [maxlen:26] [final:19]
> > [    2.462375][T1200180] kworker/2:21: [name:mmc_core&]mmc0: new
> > HS400
> > MMC card at address 0001
> > ...
> > [    2.519863][T1300069] kworker/3:1: mtk-msdc 11250000.mmc:
> > [name:mtk_sd&]Start tuning
> > [    2.526271][T1300069] kworker/3:1: mtk-msdc 11250000.mmc:
> > [name:mtk_sd&]Tuning finished
> > [    2.527288][T1300069] kworker/3:1: mtk-msdc 11250000.mmc:
> > [name:mtk_sd&]phase: [map:ffffffffffff003f] [maxlen:48] [final:40]
> > [    2.532269][T1300069] kworker/3:1: [name:mmc_core&]mmc2: new
> > ultra
> > high speed SDR104 SDIO card at address 0001
> > 
> > As the kernel log indicates, it took 3 ms for eMMC to tune 32
> > steps,
> > while it took about 7 ms for SDIO to tune 64 steps. I have to
> > admit,
> > when it comes to saving boot up time, the benefits of reducing step
> > form 64 to 32 are quite minimal. Just as you said, especially when
> > async probe is enabled.
> > 
> 
> That's great to know, and it's *truly* nice information that you can
> put into the commit message, as this completes the analysis of this
> commit.
> 
> Can you mention that in the commit message for v4 of this commit?
> 
> "As per measurements taken on MT(xxxx), the tuning phase will take:
>   eMMC - 32 steps: ~3ms
>          64 steps: xxxx
>   SDIO - 32 steps: xxxx
>          64 steps: ~7ms
> 
Okay, will update the commit message in v4.


> ...but while this won't prolong boot times by any meaningful amount
> of time, for eMMC, it should still be preferred to use 32 steps
> tuning
> because otherwise we lose performance for RPMB I//O, which requires
> re-tuning for each access.
> "
OK, I will make SD/SDIO default to use 64 steps tuning .


> > > 
> > > I'm asking because while now I see - and agree - on using 32-
> > > steps
> > > tuning
> > > on eMMC to guarantee performance during RPMB access, as far as I
> > > know,
> > > there is no RPMB partition on SD/MicroSD cards (and, of course,
> > > SDIO
> > > devices).
> > > 
> > > If the boot performance impact isn't big, as in, up to ~100
> > > milliseconds is
> > > not big at all (especially with async probe!), we can definitely
> > > avoid the
> > > addition of a devicetree property for 32-steps tuning, hence use
> > > a
> > > dynamic
> > > selection strategy such that:
> > >    - On eMMC devices, always perform 32-steps tuning (hence no
> > > boot
> > > delay)
> > >    - On SD cards and SDIO, always perform 64-steps tuning
> > 
> > eMMC could also potentially have CRC issue if only tune 32-steps,
> > albeit with a lower likelihood. The precondition for using 32-steps
> > tuning is that it could provide roughly the same valid results as
> > using
> > 64-steps tuning. So taking everything into account, controlling the
> > tuning step as needed through the use of dts property seems to be a
> > more flixible approach.
> > 
> 
> Yes but since the only performance concern is about eMMC RPMB access,
> we could at least make this 64 steps as *default* for SD/SDIO, and
> 32 steps as default for eMMC.
> Device tree would be an override of those default values.
> 
> Can we set 64 as default for SD/SDIO, 32 as default for eMMC, and
> then use
> the device tree to override those defaults?
> 
Will update in v4.

> Angelo

From 21cnbao at gmail.com  Mon Dec  4 17:24:26 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Tue, 5 Dec 2023 09:24:26 +0800
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <CAGsJ_4zG6W_Z-u+3QcRDn4ByoeqUXjMusNS0RotfRMSqo8RCHg@mail.gmail.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com> <20231204102027.57185-5-ryan.roberts@arm.com>
 <CAGsJ_4zG6W_Z-u+3QcRDn4ByoeqUXjMusNS0RotfRMSqo8RCHg@mail.gmail.com>
Message-ID: <CAGsJ_4zYhJWGx1DnHTiDnP3h1m8_rr6ZT6fXt8pO=jzs9QZS-A@mail.gmail.com>

On Tue, Dec 5, 2023 at 9:15?AM Barry Song <21cnbao at gmail.com> wrote:
>
> On Mon, Dec 4, 2023 at 6:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
> >
> > Introduce the logic to allow THP to be configured (through the new sysfs
> > interface we just added) to allocate large folios to back anonymous
> > memory, which are larger than the base page size but smaller than
> > PMD-size. We call this new THP extension "multi-size THP" (mTHP).
> >
> > mTHP continues to be PTE-mapped, but in many cases can still provide
> > similar benefits to traditional PMD-sized THP: Page faults are
> > significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
> > the configured order), but latency spikes are much less prominent
> > because the size of each page isn't as huge as the PMD-sized variant and
> > there is less memory to clear in each page fault. The number of per-page
> > operations (e.g. ref counting, rmap management, lru list management) are
> > also significantly reduced since those ops now become per-folio.
> >
> > Some architectures also employ TLB compression mechanisms to squeeze
> > more entries in when a set of PTEs are virtually and physically
> > contiguous and approporiately aligned. In this case, TLB misses will
> > occur less often.
> >
> > The new behaviour is disabled by default, but can be enabled at runtime
> > by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
> > (see documentation in previous commit). The long term aim is to change
> > the default to include suitable lower orders, but there are some risks
> > around internal fragmentation that need to be better understood first.
> >
> > Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> > ---
> >  include/linux/huge_mm.h |   6 ++-
> >  mm/memory.c             | 106 ++++++++++++++++++++++++++++++++++++----
> >  2 files changed, 101 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index bd0eadd3befb..91a53b9835a4 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
> >  #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> >
> >  /*
> > - * Mask of all large folio orders supported for anonymous THP.
> > + * Mask of all large folio orders supported for anonymous THP; all orders up to
> > + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
> > + * (which is a limitation of the THP implementation).
> >   */
> > -#define THP_ORDERS_ALL_ANON    BIT(PMD_ORDER)
> > +#define THP_ORDERS_ALL_ANON    ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
> >
> >  /*
> >   * Mask of all large folio orders supported for file THP.
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 3ceeb0f45bf5..bf7e93813018 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >         return ret;
> >  }
> >
> > +static bool pte_range_none(pte_t *pte, int nr_pages)
> > +{
> > +       int i;
> > +
> > +       for (i = 0; i < nr_pages; i++) {
> > +               if (!pte_none(ptep_get_lockless(pte + i)))
> > +                       return false;
> > +       }
> > +
> > +       return true;
> > +}
> > +
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
> > +{
> > +       gfp_t gfp;
> > +       pte_t *pte;
> > +       unsigned long addr;
> > +       struct folio *folio;
> > +       struct vm_area_struct *vma = vmf->vma;
> > +       unsigned long orders;
> > +       int order;
> > +
> > +       /*
> > +        * If uffd is active for the vma we need per-page fault fidelity to
> > +        * maintain the uffd semantics.
> > +        */
> > +       if (userfaultfd_armed(vma))
> > +               goto fallback;
> > +
> > +       /*
> > +        * Get a list of all the (large) orders below PMD_ORDER that are enabled
> > +        * for this vma. Then filter out the orders that can't be allocated over
> > +        * the faulting address and still be fully contained in the vma.
> > +        */
> > +       orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
> > +                                         BIT(PMD_ORDER) - 1);
> > +       orders = thp_vma_suitable_orders(vma, vmf->address, orders);
> > +
> > +       if (!orders)
> > +               goto fallback;
> > +
> > +       pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
> > +       if (!pte)
> > +               return ERR_PTR(-EAGAIN);
> > +
> > +       order = first_order(orders);
> > +       while (orders) {
> > +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> > +               vmf->pte = pte + pte_index(addr);
> > +               if (pte_range_none(vmf->pte, 1 << order))
> > +                       break;
> > +               order = next_order(&orders, order);
> > +       }
> > +
> > +       vmf->pte = NULL;
> > +       pte_unmap(pte);
> > +
> > +       gfp = vma_thp_gfp_mask(vma);
> > +
> > +       while (orders) {
> > +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> > +               folio = vma_alloc_folio(gfp, order, vma, addr, true);
> > +               if (folio) {
> > +                       clear_huge_page(&folio->page, addr, 1 << order);
>
> Minor.
>
> Do we have to constantly clear a huge page? Is it possible to let
> post_alloc_hook()
> finish this job by using __GFP_ZERO/__GFP_ZEROTAGS as
> vma_alloc_zeroed_movable_folio() is doing?
>
> struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
>                                                 unsigned long vaddr)
> {
>         gfp_t flags = GFP_HIGHUSER_MOVABLE | __GFP_ZERO;
>
>         /*
>          * If the page is mapped with PROT_MTE, initialise the tags at the
>          * point of allocation and page zeroing as this is usually faster than
>          * separate DC ZVA and STGM.
>          */
>         if (vma->vm_flags & VM_MTE)
>                 flags |= __GFP_ZEROTAGS;
>
>         return vma_alloc_folio(flags, 0, vma, vaddr, false);
> }

I am asking this because Android and some other kernels might always set
CONFIG_INIT_ON_ALLOC_DEFAULT_ON, that means one more explicit
clear_page is doing a duplicated job.

when the below is true, post_alloc_hook has cleared huge_page before
vma_alloc_folio() returns the folio,

static inline bool want_init_on_alloc(gfp_t flags)
{
        if (static_branch_maybe(CONFIG_INIT_ON_ALLOC_DEFAULT_ON,
                                &init_on_alloc))
                return true;
        return flags & __GFP_ZERO;
}


>
> > +                       return folio;
> > +               }
> > +               order = next_order(&orders, order);
> > +       }
> > +
> > +fallback:
> > +       return vma_alloc_zeroed_movable_folio(vma, vmf->address);
> > +}
> > +#else
> > +#define alloc_anon_folio(vmf) \
> > +               vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
> > +#endif
> > +
> >  /*
> >   * We enter with non-exclusive mmap_lock (to exclude vma changes,
> >   * but allow concurrent faults), and pte mapped but not yet locked.
> > @@ -4132,6 +4210,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >   */
> >  static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
> >  {
> > +       int i;
> > +       int nr_pages = 1;
> > +       unsigned long addr = vmf->address;
> >         bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
> >         struct vm_area_struct *vma = vmf->vma;
> >         struct folio *folio;
> > @@ -4176,10 +4257,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
> >         /* Allocate our own private page. */
> >         if (unlikely(anon_vma_prepare(vma)))
> >                 goto oom;
> > -       folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
> > +       folio = alloc_anon_folio(vmf);
> > +       if (IS_ERR(folio))
> > +               return 0;
> >         if (!folio)
> >                 goto oom;
> >
> > +       nr_pages = folio_nr_pages(folio);
> > +       addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
> > +
> >         if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
> >                 goto oom_free_page;
> >         folio_throttle_swaprate(folio, GFP_KERNEL);
> > @@ -4196,12 +4282,13 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
> >         if (vma->vm_flags & VM_WRITE)
> >                 entry = pte_mkwrite(pte_mkdirty(entry), vma);
> >
> > -       vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
> > -                       &vmf->ptl);
> > +       vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
> >         if (!vmf->pte)
> >                 goto release;
> > -       if (vmf_pte_changed(vmf)) {
> > -               update_mmu_tlb(vma, vmf->address, vmf->pte);
> > +       if ((nr_pages == 1 && vmf_pte_changed(vmf)) ||
> > +           (nr_pages  > 1 && !pte_range_none(vmf->pte, nr_pages))) {
> > +               for (i = 0; i < nr_pages; i++)
> > +                       update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);
> >                 goto release;
> >         }
> >
> > @@ -4216,16 +4303,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
> >                 return handle_userfault(vmf, VM_UFFD_MISSING);
> >         }
> >
> > -       inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
> > -       folio_add_new_anon_rmap(folio, vma, vmf->address);
> > +       folio_ref_add(folio, nr_pages - 1);
> > +       add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
> > +       folio_add_new_anon_rmap(folio, vma, addr);
> >         folio_add_lru_vma(folio, vma);
> >  setpte:
> >         if (uffd_wp)
> >                 entry = pte_mkuffd_wp(entry);
> > -       set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
> > +       set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
> >
> >         /* No need to invalidate - it was non-present before */
> > -       update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
> > +       update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
> >  unlock:
> >         if (vmf->pte)
> >                 pte_unmap_unlock(vmf->pte, vmf->ptl);
> > --
> > 2.25.1
> >


From nicolinc at nvidia.com  Mon Dec  4 17:38:52 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 17:38:52 -0800
Subject: [PATCH v2 04/19] iommu/arm-smmu-v3: Make STE programming
 independent of the callers
In-Reply-To: <4-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW5/LCBjidzEqw4F@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:11PM -0400, Jason Gunthorpe wrote:
> As the comment in arm_smmu_write_strtab_ent() explains, this routine has
> been limited to only work correctly in certain scenarios that the caller
> must ensure. Generally the caller must put the STE into ABORT or BYPASS
> before attempting to program it to something else.
> 
> The next patches/series are going to start removing some of this logic
> from the callers, and add more complex state combinations than currently.
> 
> Thus, consolidate all the complexity here. Callers do not have to care
> about what STE transition they are doing, this function will handle
> everything optimally.
> 
> Revise arm_smmu_write_strtab_ent() so it algorithmically computes the
> required programming sequence to avoid creating an incoherent 'torn' STE
> in the HW caches. The update algorithm follows the same design that the
> driver already uses: it is safe to change bits that HW doesn't currently
> use and then do a single 64 bit update, with sync's in between.
> 
> The basic idea is to express in a bitmask what bits the HW is actually
> using based on the V and CFG bits. Based on that mask we know what STE
> changes are safe and which are disruptive. We can count how many 64 bit
> QWORDS need a disruptive update and know if a step with V=0 is required.
> 
> This gives two basic flows through the algorithm.
> 
> If only a single 64 bit quantity needs disruptive replacement:
>  - Write the target value into all currently unused bits
>  - Write the single 64 bit quantity
>  - Zero the remaining different bits
> 
> If multiple 64 bit quantities need disruptive replacement then do:
>  - Write V=0 to QWORD 0
>  - Write the entire STE except QWORD 0
>  - Write QWORD 0
> 
> With HW flushes at each step, that can be skipped if the STE didn't change
> in that step.
> 
> At this point it generates the same sequence of updates as the current
> code, except that zeroing the VMID on entry to BYPASS/ABORT will do an
> extra sync (this seems to be an existing bug).
> 
> Going forward this will use a V=0 transition instead of cycling through
> ABORT if a hitfull change is required. This seems more appropriate as ABORT
> will fail DMAs without any logging, but dropping a DMA due to transient
> V=0 is probably signaling a bug, so the C_BAD_STE is valuable.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nicolinc at nvidia.com  Mon Dec  4 17:43:59 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 17:43:59 -0800
Subject: [PATCH v2 05/19] iommu/arm-smmu-v3: Consolidate the STE
 generation for abort/bypass
In-Reply-To: <5-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <5-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6AX3z/C9bA/ZiG@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:12PM -0400, Jason Gunthorpe wrote:
> This allows writing the flow of arm_smmu_write_strtab_ent() around abort
> and bypass domains more naturally.
> 
> Note that the core code no longer supplies NULL domains, though there is
> still a flow in the driver that end up in arm_smmu_write_strtab_ent() with
> NULL. A later patch will remove it.
> 
> Remove the duplicate calculation of the STE in arm_smmu_init_bypass_stes()
> and remove the force parameter. arm_smmu_rmr_install_bypass_ste() can now
> simply invoke arm_smmu_make_bypass_ste() directly.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
 
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nicolinc at nvidia.com  Mon Dec  4 17:45:25 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 17:45:25 -0800
Subject: [PATCH v2 06/19] iommu/arm-smmu-v3: Move
 arm_smmu_rmr_install_bypass_ste()
In-Reply-To: <6-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <6-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6Atc2tHP4il8ic@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:13PM -0400, Jason Gunthorpe wrote:
> Logically arm_smmu_init_strtab_linear() is the function that allocates and
> populates the stream table with the initial value of the STEs. After this
> function returns the stream table should be fully ready.
> 
> arm_smmu_rmr_install_bypass_ste() adjusts the initial stream table to force
> any SIDs that the FW says have IOMMU_RESV_DIRECT to use bypass. This
> ensures there is no disruption to the identity mapping during boot.
> 
> Put arm_smmu_rmr_install_bypass_ste() into arm_smmu_init_strtab_linear(),
> it already executes immediately after arm_smmu_init_strtab_linear().
> 
> No functional change intended.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nicolinc at nvidia.com  Mon Dec  4 17:55:03 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 17:55:03 -0800
Subject: [PATCH v2 07/19] iommu/arm-smmu-v3: Move the STE generation for
 S1 and S2 domains into functions
In-Reply-To: <7-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <7-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6C9yepEVC1amuu@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:14PM -0400, Jason Gunthorpe wrote:
> This is preparation to move the STE calculation higher up in to the call
> chain and remove arm_smmu_write_strtab_ent(). These new functions will be
> called directly from attach_dev.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

> +static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
> +				      struct arm_smmu_master *master,
> +				      struct arm_smmu_ctx_desc_cfg *cd_table)
> +{
> +	struct arm_smmu_device *smmu = master->smmu;
> +
> +	memset(target, 0, sizeof(*target));
> +	target->data[0] = cpu_to_le64(

Nit: can add a line in-between like arm_smmu_make_s2_domain_ste does?

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>

> +static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
> +					struct arm_smmu_master *master,
> +					struct arm_smmu_domain *smmu_domain)
> +{
> +	struct arm_smmu_s2_cfg *s2_cfg = &smmu_domain->s2_cfg;
> +
> +	memset(target, 0, sizeof(*target));
> +
> +	target->data[0] = cpu_to_le64(


From nicolinc at nvidia.com  Mon Dec  4 17:58:25 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 17:58:25 -0800
Subject: [PATCH v2 08/19] iommu/arm-smmu-v3: Build the whole STE in
 arm_smmu_make_s2_domain_ste()
In-Reply-To: <8-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <8-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6DwYWTH6IN2Fdm@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:15PM -0400, Jason Gunthorpe wrote:
> Half the code was living in arm_smmu_domain_finalise_s2(), just move it
> here and take the values directly from the pgtbl_ops instead of storing
> copies.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
 
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From anshuman.khandual at arm.com  Mon Dec  4 18:04:28 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Tue, 5 Dec 2023 07:34:28 +0530
Subject: [PATCH v3 3/3] arm64: Rename reserved values for CTR_EL0.L1Ip
In-Reply-To: <20231204143606.1806432-4-maz@kernel.org>
References: <20231204143606.1806432-1-maz@kernel.org>
 <20231204143606.1806432-4-maz@kernel.org>
Message-ID: <2dfb07f4-39c3-4cfe-81ba-416c18f99b10@arm.com>



On 12/4/23 20:06, Marc Zyngier wrote:
> We now have *two* values for CTR_EL0.L1Ip that are reserved.
> Which makes things a bit awkward. In order to lift the ambiguity,
> rename RESERVED (0b01) to RESERVED_AIVIVT, and VPIPT (0b00) to
> RESERVED_VPIPT.
> 
> This makes it clear which of these meant what, and I'm sure
> archeologists will find it useful...
> 
> Reviewed-by: Zenghui Yu <yuzenghui at huawei.com>
> Signed-off-by: Marc Zyngier <maz at kernel.org>

Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>

> ---
>  arch/arm64/tools/sysreg | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 96cbeeab4eec..c5af75b23187 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -2004,9 +2004,10 @@ Field	27:24	CWG
>  Field	23:20	ERG
>  Field	19:16	DminLine
>  Enum	15:14	L1Ip
> -	0b00	VPIPT
> +	# This was named as VPIPT in the ARM but now documented as reserved
> +	0b00	RESERVED_VPIPT
>  	# This is named as AIVIVT in the ARM but documented as reserved
> -	0b01	RESERVED
> +	0b01	RESERVED_AIVIVT
>  	0b10	VIPT
>  	0b11	PIPT
>  EndEnum


From Axe.Yang at mediatek.com  Mon Dec  4 18:02:13 2023
From: Axe.Yang at mediatek.com (=?utf-8?B?QXhlIFlhbmcgKOadqOejiik=?=)
Date: Tue, 5 Dec 2023 02:02:13 +0000
Subject: [PATCH v3 2/2] mmc: mediatek: extend number of tuning steps
In-Reply-To: <27313484-10a9-4a2f-93b1-9b5ce04ad9c6@collabora.com>
References: <20231130061513.1296-1-axe.yang@mediatek.com>
	 <20231130061513.1296-3-axe.yang@mediatek.com>
	 <27313484-10a9-4a2f-93b1-9b5ce04ad9c6@collabora.com>
Message-ID: <a419295339c8126150c1e393fcc4cb6a232f07b5.camel@mediatek.com>

On Fri, 2023-12-01 at 10:02 +0100, AngeloGioacchino Del Regno wrote:
> Il 30/11/23 07:15, Axe Yang ha scritto:
> > Previously, during the MSDC calibration process, a full clock cycle
> > actually not be covered, which in some cases didn't yield the best
> > results and could cause CRC errors. This problem is particularly
> > evident when MSDC is used as an SDIO host. In fact, MSDC support
> > tuning up to a maximum of 64 steps, but by default, the step number
> > is 32. By increase the tuning step, we are more likely to cover
> > more
> > parts of a clock cycle, and get better calibration result.
> > 
> > To illustrate, when tuning 32 steps, if the obtained window has a
> > hole
> > near the middle, like this: 0xffc07ff (hex), then the selected
> > delay
> > will be the 6 (counting from right to left).
> > 
> > (32 <- 1)
> > 1111 1111 1100 0000 0000 0111 11(1)1 1111
> > 
> > However, if we tune 64 steps, the window obtained may look like
> > this:
> > 0xfffffffffffc07ff. The final selected delay will be 44, which is
> > safer as it is further away from the hole:
> > 
> > (64 <- 1)
> > 1111 ... (1)111 1111 1111 1111 1111 1100 0000 0000 0111 1111 1111
> > 
> > In this case, delay 6 selected through 32 steps tuning is obviously
> > not optimal, and this delay is closer to the hole, using it would
> > easily cause CRC problems.
> > 
> > You will need to configure property "mediatek,tuning-step" in MSDC
> > dts node to 64 to extend the steps.
> > 
> > Signed-off-by: Axe Yang <axe.yang at mediatek.com>
> > ---
> >   drivers/mmc/host/mtk-sd.c | 155 ++++++++++++++++++++++++++-------
> > -----
> >   1 file changed, 107 insertions(+), 48 deletions(-)
> > 
> > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> > index 97f7c3d4be6e..4cd306b3b295 100644
> > --- a/drivers/mmc/host/mtk-sd.c
> > +++ b/drivers/mmc/host/mtk-sd.c
> > @@ -252,12 +252,16 @@
> >   
> >   #define MSDC_PAD_TUNE_DATWRDLY	  GENMASK(4, 0)		/*
> > RW */
> >   #define MSDC_PAD_TUNE_DATRRDLY	  GENMASK(12, 8)	/* RW */
> > +#define MSDC_PAD_TUNE_DATRRDLY2	  GENMASK(12, 8)	/* RW */
> >   #define MSDC_PAD_TUNE_CMDRDLY	  GENMASK(20, 16)	/* RW */
> > +#define MSDC_PAD_TUNE_CMDRDLY2	  GENMASK(20, 16)	/* RW */
> >   #define MSDC_PAD_TUNE_CMDRRDLY	  GENMASK(26, 22)	/* RW */
> >   #define MSDC_PAD_TUNE_CLKTDLY	  GENMASK(31, 27)	/* RW */
> >   #define MSDC_PAD_TUNE_RXDLYSEL	  BIT(15)   /* RW */
> >   #define MSDC_PAD_TUNE_RD_SEL	  BIT(13)   /* RW */
> >   #define MSDC_PAD_TUNE_CMD_SEL	  BIT(21)   /* RW */
> > +#define MSDC_PAD_TUNE_RD2_SEL	  BIT(13)   /* RW */
> > +#define MSDC_PAD_TUNE_CMD2_SEL	  BIT(21)   /* RW */
> >   
> >   #define PAD_DS_TUNE_DLY_SEL       BIT(0)	  /* RW */
> >   #define PAD_DS_TUNE_DLY1	  GENMASK(6, 2)   /* RW */
> > @@ -325,7 +329,8 @@
> >   
> >   #define DEFAULT_DEBOUNCE	(8)	/* 8 cycles CD debounce */
> >   
> > -#define PAD_DELAY_MAX	32 /* PAD delay cells */
> > +#define PAD_DELAY_HALF	32 /* PAD delay cells */
> > +#define PAD_DELAY_FULL	64
> >   /*---------------------------------------------------------------
> > -----------*/
> >   /* Descriptor
> > Structure                                                     */
> >   /*---------------------------------------------------------------
> > -----------*/
> > @@ -461,6 +466,7 @@ struct msdc_host {
> >   	u32 hs400_ds_dly3;
> >   	u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104
> > */
> >   	u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
> > +	u32 tuning_step;
> >   	bool hs400_cmd_resp_sel_rising;
> >   				 /* cmd response sample selection for
> > HS400 */
> >   	bool hs400_mode;	/* current eMMC will run at hs400 mode */
> > @@ -1615,7 +1621,7 @@ static irqreturn_t msdc_cmdq_irq(struct
> > msdc_host *host, u32 intsts)
> >   	}
> >   
> >   	if (cmd_err || dat_err) {
> > -		dev_err(host->dev, "cmd_err = %d, dat_err =%d, intsts =
> > 0x%x",
> > +		dev_err(host->dev, "cmd_err = %d, dat_err = %d, intsts
> > = 0x%x",
> >   			cmd_err, dat_err, intsts);
> >   	}
> >   
> > @@ -1780,10 +1786,20 @@ static void msdc_init_hw(struct msdc_host
> > *host)
> >   				     DATA_K_VALUE_SEL);
> >   			sdr_set_bits(host->top_base + EMMC_TOP_CMD,
> >   				     PAD_CMD_RD_RXDLY_SEL);
> > +			if (host->tuning_step > PAD_DELAY_HALF) {
> > +				sdr_set_bits(host->top_base +
> > EMMC_TOP_CONTROL,
> > +					     PAD_DAT_RD_RXDLY2_SEL);
> > +				sdr_set_bits(host->top_base +
> > EMMC_TOP_CMD,
> > +					     PAD_CMD_RD_RXDLY2_SEL);
> > +			}
> >   		} else {
> >   			sdr_set_bits(host->base + tune_reg,
> >   				     MSDC_PAD_TUNE_RD_SEL |
> >   				     MSDC_PAD_TUNE_CMD_SEL);
> > +			if (host->tuning_step > PAD_DELAY_HALF)
> > +				sdr_set_bits(host->base + tune_reg + 4,
> 
> `tune_reg + 4` is a different register, please define it.
> 
The tune_reg is not a fixed register address, it is defined in
compatible structures. So using the offset here will make the code more
consise. The offset of registers related to 64 steps tuning is fixed
relative to 32-steps tuning regsiter, the offset is always 4.

However. using the magic number '4' here directly is not ideal. I think
I can improve this part of code by defining '4' as a macro. What do you
think about it? If you insist on redifning the registers, I can do it,
but it will make the code a bit more complex than it is now.


> Also, I can't find this in MT8192, MT8195 - as those bits seem to be
> undefined,
> so, which SoCs are actually compatible with this change?

Sorry, which bits are you talking about? 
This change compatible for all SoCs. In fact, MSDC has always supported
64 step tuning.


> 
> 
> > +					     MSDC_PAD_TUNE_RD2_SEL |
> > +					     MSDC_PAD_TUNE_CMD2_SEL);
> >   		}
> >   	} else {
> >   		/* choose clock tune */
> > @@ -1925,24 +1941,24 @@ static void msdc_ops_set_ios(struct
> > mmc_host *mmc, struct mmc_ios *ios)
> >   		msdc_set_mclk(host, ios->timing, ios->clock);
> >   }
> >   
> > -static u32 test_delay_bit(u32 delay, u32 bit)
> > +static u64 test_delay_bit(u64 delay, u32 bit)
> >   {
> > -	bit %= PAD_DELAY_MAX;
> > -	return delay & BIT(bit);
> > +	bit %= PAD_DELAY_FULL;
> > +	return delay & BIT_ULL(bit);
> >   }
> >   
> > -static int get_delay_len(u32 delay, u32 start_bit)
> > +static int get_delay_len(u64 delay, u32 start_bit)
> >   {
> >   	int i;
> >   
> > -	for (i = 0; i < (PAD_DELAY_MAX - start_bit); i++) {
> > +	for (i = 0; i < (PAD_DELAY_FULL - start_bit); i++) {
> >   		if (test_delay_bit(delay, start_bit + i) == 0)
> >   			return i;
> >   	}
> > -	return PAD_DELAY_MAX - start_bit;
> > +	return PAD_DELAY_FULL - start_bit;
> >   }
> >   
> > -static struct msdc_delay_phase get_best_delay(struct msdc_host
> > *host, u32 delay)
> > +static struct msdc_delay_phase get_best_delay(struct msdc_host
> > *host, u64 delay)
> >   {
> >   	int start = 0, len = 0;
> >   	int start_final = 0, len_final = 0;
> > @@ -1950,28 +1966,28 @@ static struct msdc_delay_phase
> > get_best_delay(struct msdc_host *host, u32 delay)
> >   	struct msdc_delay_phase delay_phase = { 0, };
> >   
> >   	if (delay == 0) {
> > -		dev_err(host->dev, "phase error: [map:%x]\n", delay);
> > +		dev_err(host->dev, "phase error: [map:%016llx]\n",
> > delay);
> >   		delay_phase.final_phase = final_phase;
> >   		return delay_phase;
> >   	}
> >   
> > -	while (start < PAD_DELAY_MAX) {
> > +	while (start < PAD_DELAY_FULL) {
> >   		len = get_delay_len(delay, start);
> >   		if (len_final < len) {
> >   			start_final = start;
> >   			len_final = len;
> >   		}
> >   		start += len ? len : 1;
> > -		if (len >= 12 && start_final < 4)
> > +		if (!upper_32_bits(delay) && len >= 12 && start_final <
> > 4)
> >   			break;
> >   	}
> >   
> >   	/* The rule is that to find the smallest delay cell */
> >   	if (start_final == 0)
> > -		final_phase = (start_final + len_final / 3) %
> > PAD_DELAY_MAX;
> > +		final_phase = (start_final + len_final / 3) %
> > PAD_DELAY_FULL;
> >   	else
> > -		final_phase = (start_final + len_final / 2) %
> > PAD_DELAY_MAX;
> > -	dev_dbg(host->dev, "phase: [map:%x] [maxlen:%d] [final:%d]\n",
> > +		final_phase = (start_final + len_final / 2) %
> > PAD_DELAY_FULL;
> > +	dev_dbg(host->dev, "phase: [map:%016llx] [maxlen:%d]
> > [final:%d]\n",
> >   		delay, len_final, final_phase);
> >   
> >   	delay_phase.maxlen = len_final;
> > @@ -1984,30 +2000,68 @@ static inline void
> > msdc_set_cmd_delay(struct msdc_host *host, u32 value)
> >   {
> >   	u32 tune_reg = host->dev_comp->pad_tune_reg;
> >   
> > -	if (host->top_base)
> > -		sdr_set_field(host->top_base + EMMC_TOP_CMD,
> > PAD_CMD_RXDLY,
> > -			      value);
> > -	else
> > -		sdr_set_field(host->base + tune_reg,
> > MSDC_PAD_TUNE_CMDRDLY,
> > -			      value);
> > +	if (host->top_base) {
> > +		if (value < PAD_DELAY_HALF) {
> > +			sdr_set_field(host->top_base + EMMC_TOP_CMD,
> > PAD_CMD_RXDLY,
> > +				      value);
> 
> This goes up to 92 columns, and it's fine, so fits in one line and
> it's more
> readable like that.
> 
> I know that's not your fault, but since you're actually touching
> those lines
> it's a good occasion to also do that (not only here) :-)
> 
Sure, will update this part in v4, and thanks for your meticulous
review.

Regards,
Axe
> Angelo

From nicolinc at nvidia.com  Mon Dec  4 18:13:47 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 18:13:47 -0800
Subject: [PATCH v2 10/19] iommu/arm-smmu-v3: Compute the STE only once
 for each master
In-Reply-To: <10-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <10-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6HWwkxY4N/gaTr@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:17PM -0400, Jason Gunthorpe wrote:
> Currently arm_smmu_install_ste_for_dev() iterates over every SID and
> computes from scratch an identical STE. Every SID should have the same STE
> contents. Turn this inside out so that the STE is supplied by the caller
> and arm_smmu_install_ste_for_dev() simply installs it to every SID.
> 
> This is possible now that the STE generation does not inform what sequence
> should be used to program it.
> 
> This allows splitting the STE calculation up according to the call site,
> which following patches will make use of, and removes the confusing NULL
> domain special case that only supported arm_smmu_detach_dev().
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nicolinc at nvidia.com  Mon Dec  4 18:16:43 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 18:16:43 -0800
Subject: [PATCH v2 09/19] iommu/arm-smmu-v3: Hold arm_smmu_asid_lock
 during all of attach_dev
In-Reply-To: <9-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <9-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6IC/gSOViGrGIG@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:16PM -0400, Jason Gunthorpe wrote:
> The BTM support wants to be able to change the ASID of any smmu_domain.
> When it goes to do this it holds the arm_smmu_asid_lock and iterates over
> the target domain's devices list.
> 
> During attach of a S1 domain we must ensure that the devices list and
> CD are in sync, otherwise we could miss CD updates or a parallel CD update
> could push an out of date CD.
> 
> This is pretty complicated, and works today because arm_smmu_detach_dev()
> remove the CD table from the STE before working on the CD entries.
> 
> The next patch will allow the CD table to remain in the STE so solve this
> racy by holding the lock for a longer period. The lock covers both of the
> changes to the device list and the CD table entries.
> 
> Move arm_smmu_detach_dev() till after we have initialized the domain so
> the lock can be held for less time.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
 
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From anshuman.khandual at arm.com  Mon Dec  4 18:26:16 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Tue, 5 Dec 2023 07:56:16 +0530
Subject: [PATCH v6 03/41] arm64: mm: get rid of kimage_vaddr global
 variable
In-Reply-To: <ZW3kRg9a30FTe1ru@FVFF77S0Q05N>
References: <20231129111555.3594833-43-ardb@google.com>
 <20231129111555.3594833-46-ardb@google.com>
 <2fabeac2-a1c1-4e10-b7f5-33de8d502e4d@arm.com>
 <ZW3kRg9a30FTe1ru@FVFF77S0Q05N>
Message-ID: <1df51909-1b2a-4a42-973d-af9bcdfb8e6e@arm.com>



On 12/4/23 20:07, Mark Rutland wrote:
> On Thu, Nov 30, 2023 at 11:08:59AM +0530, Anshuman Khandual wrote:
>>
>>
>> On 11/29/23 16:45, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb at kernel.org>
>>>
>>> We store the address of _text in kimage_vaddr, but since commit
>>> 09e3c22a86f6889d ("arm64: Use a variable to store non-global mappings
>>> decision"), we no longer reference this variable from modules so we no
>>> longer need to export it.
>>>
>>> In fact, we don't need it at all so let's just get rid of it.
>>>
>>> Acked-by: Mark Rutland <mark.rutland at arm.com>
>>> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
>>
>> There is a checkpatch.pl error for this patch.
>>
>> --------
>> ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' -
>> ie: 'commit 09e3c22a86f6 ("arm64: Use a variable to store non-global mappings decision")'
>> #6: 
>> We store the address of _text in kimage_vaddr, but since commit
>> --------
> 
> That looks like a spurious warning. Ard wrote:
> 
>   [...] commit 09e3c22a86f6889d ("arm64: Use a variable to store non-global
>   mappings decision"), [...]
> 
> ... which is 'commit <16 chars of sha1> ("<title line>")', just as the
> checkpatch message says.

Although it does not make any difference TBH, sometimes moving 'commit'
before the SHA string on the same line just removes the warning. That
line break might be the trigger.

> 
> Clearly, this checkpatch warning isn't helpful.
> 
> Regardless of whether the warning is spurious, please use judgement for
> checkpatch warnings. They're not always a hard rule to be followed.
> 
> Mark.


From patchwork-bot+netdevbpf at kernel.org  Mon Dec  4 18:40:25 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Tue, 05 Dec 2023 02:40:25 +0000
Subject: [PATCH v4] net: stmmac: fix FPE events losing
In-Reply-To: <CY5PR12MB637225A7CF529D5BE0FBE59CBF81A@CY5PR12MB6372.namprd12.prod.outlook.com>
References: <CY5PR12MB637225A7CF529D5BE0FBE59CBF81A@CY5PR12MB6372.namprd12.prod.outlook.com>
Message-ID: <170174402518.31470.16495979069997859149.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba at kernel.org>:

On Fri, 1 Dec 2023 03:22:03 +0000 you wrote:
> The status bits of register MAC_FPE_CTRL_STS are clear on read. Using
> 32-bit read for MAC_FPE_CTRL_STS in dwmac5_fpe_configure() and
> dwmac5_fpe_send_mpacket() clear the status bits. Then the stmmac interrupt
> handler missing FPE event status and leads to FPE handshaking failure and
> retries.
> To avoid clear status bits of MAC_FPE_CTRL_STS in dwmac5_fpe_configure()
> and dwmac5_fpe_send_mpacket(), add fpe_csr to stmmac_fpe_cfg structure to
> cache the control bits of MAC_FPE_CTRL_STS and to avoid reading
> MAC_FPE_CTRL_STS in those methods.
> 
> [...]

Here is the summary with links:
  - [v4] net: stmmac: fix FPE events losing
    https://git.kernel.org/netdev/net/c/37e4b8df27bc

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From nicolinc at nvidia.com  Mon Dec  4 18:46:01 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 18:46:01 -0800
Subject: [PATCH v2 11/19] iommu/arm-smmu-v3: Do not change the STE twice
 during arm_smmu_attach_dev()
In-Reply-To: <11-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <11-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6ObRW5BWbGH7RL@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:18PM -0400, Jason Gunthorpe wrote:
> This was needed because the STE code required the STE to be in
> ABORT/BYPASS inorder to program a cdtable or S2 STE. Now that the STE code
> can automatically handle all transitions we can remove this step
> from the attach_dev flow.
> 
> A few small bugs exist because of this:
> 
> 1) If the core code does BLOCKED -> UNMANAGED with disable_bypass=false
>    then there will be a moment where the STE points at BYPASS. Since
>    this can be done by VFIO/IOMMUFD it is a small security race.
> 
> 2) If the core code does IDENTITY -> DMA then any IOMMU_RESV_DIRECT
>    regions will temporarily become BLOCKED. We'd like drivers to
>    work in a way that allows IOMMU_RESV_DIRECT to be continuously
>    functional during these transitions.
> 
> Make arm_smmu_release_device() put the STE back to the correct
> ABORT/BYPASS setting. Fix a bug where a IOMMU_RESV_DIRECT was ignored on
> this path.
> 
> Notice this subtly depends on the prior arm_smmu_asid_lock change as the
> STE must be put to non-paging before removing the device for the linked
> list to avoid races with arm_smmu_share_asid().
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From patchwork-bot+netdevbpf at kernel.org  Mon Dec  4 18:50:25 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Tue, 05 Dec 2023 02:50:25 +0000
Subject: [PATCH net-next v2 0/3] net: stmmac: EST implementation
In-Reply-To: <20231201055252.1302-1-rohan.g.thomas@intel.com>
References: <20231201055252.1302-1-rohan.g.thomas@intel.com>
Message-ID: <170174462502.4521.5357100428466208009.git-patchwork-notify@kernel.org>

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba at kernel.org>:

On Fri,  1 Dec 2023 13:52:49 +0800 you wrote:
> Hi,
> This patchset extends EST interrupt handling support to DWXGMAC IP
> followed by refactoring of EST implementation. Added a separate
> module for EST and moved all EST related functions to the new module.
> 
> Also added support for EST cycle-time-extension.
> 
> [...]

Here is the summary with links:
  - [net-next,v2,1/3] net: stmmac: xgmac: EST interrupts handling
    https://git.kernel.org/netdev/net-next/c/58f3240b3b93
  - [net-next,v2,2/3] net: stmmac: Refactor EST implementation
    https://git.kernel.org/netdev/net-next/c/c3f3b97238f6
  - [net-next,v2,3/3] net: stmmac: Add support for EST cycle-time-extension
    https://git.kernel.org/netdev/net-next/c/9e95505fecb6

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From nicolinc at nvidia.com  Mon Dec  4 19:03:12 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 19:03:12 -0800
Subject: [PATCH v2 10/27] iommu/arm-smmu-v3: Move the CD generation for
 SVA into a function
In-Reply-To: <10-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
References: <0-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
 <10-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <ZW6S8CPK5UQ1mYpa@Asurada-Nvidia>

On Wed, Nov 01, 2023 at 08:36:28PM -0300, Jason Gunthorpe wrote:
> Pull all the calculations for building the CD table entry for a mmu_struct
> into arm_smmu_make_sva_cd().
> 
> Call it in the two places installing the SVA CD table entry.
> 
> Open code the last caller of arm_smmu_update_ctx_desc_devices() and remove
> the function.
> 
> Remove arm_smmu_write_ctx_desc() since all callers are gone.

It seems that there are still two lines of comments mentioning
arm_smmu_write_ctx_desc that should be removed or updated too?

Nicolin


From 21cnbao at gmail.com  Mon Dec  4 19:28:51 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Tue, 5 Dec 2023 16:28:51 +1300
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <CAGsJ_4yfq8Y4vaxiP95Mrn-Oa0=3aY8kAzS6Ojd+eL-ViRr+DA@mail.gmail.com>

On Mon, Dec 4, 2023 at 11:20?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>
> Hi All,
>
> A new week, a new version, a new name... This is v8 of a series to implement
> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
> this fares better.
>
> The objective of this is to improve performance by allocating larger chunks of
> memory during anonymous page faults:
>
> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>    pages, there are efficiency savings to be had; fewer page faults, batched PTE
>    and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>    overhead. This should benefit all architectures.
> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>    advantage of HW TLB compression techniques. A reduction in TLB pressure
>    speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>    TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
>
> This version changes the name and tidies up some of the kernel code and test
> code, based on feedback against v7 (see change log for details).
>
> By default, the existing behaviour (and performance) is maintained. The user
> must explicitly enable multi-size THP to see the performance benefit. This is
> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
> David for the suggestion)! This interface is inspired by the existing
> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
> compatibility with the existing PMD-size THP interface, and provides a base for
> future extensibility. See [8] for detailed discussion of the interface.
>
> This series is based on mm-unstable (715b67adf4c8).
>
>
> Prerequisites
> =============
>
> Some work items identified as being prerequisites are listed on page 3 at [9].
> The summary is:
>
> | item                          | status                  |
> |:------------------------------|:------------------------|
> | mlock                         | In mainline (v6.7)      |
> | madvise                       | In mainline (v6.6)      |
> | compaction                    | v1 posted [10]          |
> | numa balancing                | Investigated: see below |
> | user-triggered page migration | In mainline (v6.7)      |
> | khugepaged collapse           | In mainline (NOP)       |
>
> On NUMA balancing, which currently ignores any PTE-mapped THPs it encounters,
> John Hubbard has investigated this and concluded that it is A) not clear at the
> moment what a better policy might be for PTE-mapped THP and B) questions whether
> this should really be considered a prerequisite given no regression is caused
> for the default "multi-size THP disabled" case, and there is no correctness
> issue when it is enabled - its just a potential for non-optimal performance.
>
> If there are no disagreements about removing numa balancing from the list (none
> were raised when I first posted this comment against v7), then that just leaves
> compaction which is in review on list at the moment.
>
> I really would like to get this series (and its remaining comapction
> prerequisite) in for v6.8. I accept that it may be a bit optimistic at this
> point, but lets see where we get to with review?
>

Hi Ryan,

A question but i don't think it should block this series,  do we have any plan
to extend /proc/meminfo, /proc/pid/smaps, /proc/vmstat to present some
information regarding the new multi-size THP.

e.g how many folios in each-size for the system, how many multi-size folios LRU,
how many large folios in each VMA etc.

In products and labs, we need some health monitors to make sure the system
status is visible and works as expected. right now, i feel i am like
blindly exploring
the system without those statistics.

>
> Testing
> =======
>
> The series includes patches for mm selftests to enlighten the cow and khugepaged
> tests to explicitly test with multi-size THP, in the same way that PMD-sized
> THP is tested. The new tests all pass, and no regressions are observed in the mm
> selftest suite. I've also run my usual kernel compilation and java script
> benchmarks without any issues.
>
> Refer to my performance numbers posted with v6 [6]. (These are for multi-size
> THP only - they do not include the arm64 contpte follow-on series).
>
> John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
> some workloads at [11]. (Observed using v6 of this series as well as the arm64
> contpte series).
>
> Kefeng Wang at Huawei has also indicated he sees improvements at [12] although
> there are some latency regressions also.
>
>
> Changes since v7 [7]
> ====================
>
>   - Renamed "small-sized THP" -> "multi-size THP" in commit logs
>   - Added various Reviewed-by/Tested-by tags (Barry, David, Alistair)
>   - Patch 3:
>       - Fine-tuned transhuge documentation multi-size THP (JohnH)
>       - Converted hugepage_global_enabled() and hugepage_global_always() macros
>         to static inline functions (JohnH)
>       - Renamed hugepage_vma_check() to thp_vma_allowable_orders() (JohnH)
>       - Renamed transhuge_vma_suitable() to thp_vma_suitable_orders() (JohnH)
>       - Renamed "global" enabled sysfs file option to "inherit" (JohnH)
>   - Patch 9:
>       - cow selftest: Renamed param size -> thpsize (David)
>       - cow selftest: Changed test fail to assert() (David)
>       - cow selftest: Log PMD size separately from all the supported THP sizes
>         (David)
>   - Patch 10:
>       - cow selftest: No longer special case pmdsize; keep all THP sizes in
>         thpsizes[]
>
>
> Changes since v6 [6]
> ====================
>
>   - Refactored vmf_pte_range_changed() to remove uffd special-case (suggested by
>     JohnH)
>   - Dropped accounting patch (#3 in v6) (suggested by DavidH)
>       - Continue to account *PMD-sized* THP only for now
>       - Can add more counters in future if needed
>       - Page cache large folios haven't needed any new counters yet
>   - Pivot to sysfs ABI proposed by DavidH
>       - per-size directories in a similar shape to that used by hugetlb
>   - Dropped "recommend" keyword patch (#6 in v6) (suggested by DavidH, Yu Zhou)
>       - For now, users need to understand implicitly which sizes are beneficial
>         to their HW/SW
>   - Dropped arch_wants_pte_order() patch (#7 in v6)
>       - No longer needed due to dropping patch "recommend" keyword patch
>   - Enlightened khugepaged mm selftest to explicitly test with small-size THP
>   - Scrubbed commit logs to use "small-sized THP" consistently (suggested by
>     DavidH)
>
>
> Changes since v5 [5]
> ====================
>
>   - Added accounting for PTE-mapped THPs (patch 3)
>   - Added runtime control mechanism via sysfs as extension to THP (patch 4)
>   - Minor refactoring of alloc_anon_folio() to integrate with runtime controls
>   - Stripped out hardcoded policy for allocation order; its now all user space
>     controlled (although user space can request "recommend" which will configure
>     the HW-preferred order)
>
>
> Changes since v4 [4]
> ====================
>
>   - Removed "arm64: mm: Override arch_wants_pte_order()" patch; arm64
>     now uses the default order-3 size. I have moved this patch over to
>     the contpte series.
>   - Added "mm: Allow deferred splitting of arbitrary large anon folios" back
>     into series. I originally removed this at v2 to add to a separate series,
>     but that series has transformed significantly and it no longer fits, so
>     bringing it back here.
>   - Reintroduced dependency on set_ptes(); Originally dropped this at v2, but
>     set_ptes() is in mm-unstable now.
>   - Updated policy for when to allocate LAF; only fallback to order-0 if
>     MADV_NOHUGEPAGE is present or if THP disabled via prctl; no longer rely on
>     sysfs's never/madvise/always knob.
>   - Fallback to order-0 whenever uffd is armed for the vma, not just when
>     uffd-wp is set on the pte.
>   - alloc_anon_folio() now returns `struct folio *`, where errors are encoded
>     with ERR_PTR().
>
>   The last 3 changes were proposed by Yu Zhao - thanks!
>
>
> Changes since v3 [3]
> ====================
>
>   - Renamed feature from FLEXIBLE_THP to LARGE_ANON_FOLIO.
>   - Removed `flexthp_unhinted_max` boot parameter. Discussion concluded that a
>     sysctl is preferable but we will wait until real workload needs it.
>   - Fixed uninitialized `addr` on read fault path in do_anonymous_page().
>   - Added mm selftests for large anon folios in cow test suite.
>
>
> Changes since v2 [2]
> ====================
>
>   - Dropped commit "Allow deferred splitting of arbitrary large anon folios"
>       - Huang, Ying suggested the "batch zap" work (which I dropped from this
>         series after v1) is a prerequisite for merging FLXEIBLE_THP, so I've
>         moved the deferred split patch to a separate series along with the batch
>         zap changes. I plan to submit this series early next week.
>   - Changed folio order fallback policy
>       - We no longer iterate from preferred to 0 looking for acceptable policy
>       - Instead we iterate through preferred, PAGE_ALLOC_COSTLY_ORDER and 0 only
>   - Removed vma parameter from arch_wants_pte_order()
>   - Added command line parameter `flexthp_unhinted_max`
>       - clamps preferred order when vma hasn't explicitly opted-in to THP
>   - Never allocate large folio for MADV_NOHUGEPAGE vma (or when THP is disabled
>     for process or system).
>   - Simplified implementation and integration with do_anonymous_page()
>   - Removed dependency on set_ptes()
>
>
> Changes since v1 [1]
> ====================
>
>   - removed changes to arch-dependent vma_alloc_zeroed_movable_folio()
>   - replaced with arch-independent alloc_anon_folio()
>       - follows THP allocation approach
>   - no longer retry with intermediate orders if allocation fails
>       - fallback directly to order-0
>   - remove folio_add_new_anon_rmap_range() patch
>       - instead add its new functionality to folio_add_new_anon_rmap()
>   - remove batch-zap pte mappings optimization patch
>       - remove enabler folio_remove_rmap_range() patch too
>       - These offer real perf improvement so will submit separately
>   - simplify Kconfig
>       - single FLEXIBLE_THP option, which is independent of arch
>       - depends on TRANSPARENT_HUGEPAGE
>       - when enabled default to max anon folio size of 64K unless arch
>         explicitly overrides
>   - simplify changes to do_anonymous_page():
>       - no more retry loop
>
>
> [1] https://lore.kernel.org/linux-mm/20230626171430.3167004-1-ryan.roberts at arm.com/
> [2] https://lore.kernel.org/linux-mm/20230703135330.1865927-1-ryan.roberts at arm.com/
> [3] https://lore.kernel.org/linux-mm/20230714160407.4142030-1-ryan.roberts at arm.com/
> [4] https://lore.kernel.org/linux-mm/20230726095146.2826796-1-ryan.roberts at arm.com/
> [5] https://lore.kernel.org/linux-mm/20230810142942.3169679-1-ryan.roberts at arm.com/
> [6] https://lore.kernel.org/linux-mm/20230929114421.3761121-1-ryan.roberts at arm.com/
> [7] https://lore.kernel.org/linux-mm/20231122162950.3854897-1-ryan.roberts at arm.com/
> [8] https://lore.kernel.org/linux-mm/6d89fdc9-ef55-d44e-bf12-fafff318aef8 at redhat.com/
> [9] https://drive.google.com/file/d/1GnfYFpr7_c1kA41liRUW5YtCb8Cj18Ud/view?usp=sharing&resourcekey=0-U1Mj3-RhLD1JV6EThpyPyA
> [10] https://lore.kernel.org/linux-mm/20231113170157.280181-1-zi.yan at sent.com/
> [11] https://lore.kernel.org/linux-mm/c507308d-bdd4-5f9e-d4ff-e96e4520be85 at nvidia.com/
> [12] https://lore.kernel.org/linux-mm/479b3e2b-456d-46c1-9677-38f6c95a0be8 at huawei.com/
>
>
> Thanks,
> Ryan
>
> Ryan Roberts (10):
>   mm: Allow deferred splitting of arbitrary anon large folios
>   mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()
>   mm: thp: Introduce multi-size THP sysfs interface
>   mm: thp: Support allocation of anonymous multi-size THP
>   selftests/mm/kugepaged: Restore thp settings at exit
>   selftests/mm: Factor out thp settings management
>   selftests/mm: Support multi-size THP interface in thp_settings
>   selftests/mm/khugepaged: Enlighten for multi-size THP
>   selftests/mm/cow: Generalize do_run_with_thp() helper
>   selftests/mm/cow: Add tests for anonymous multi-size THP
>
>  Documentation/admin-guide/mm/transhuge.rst |  97 ++++-
>  Documentation/filesystems/proc.rst         |   6 +-
>  fs/proc/task_mmu.c                         |   3 +-
>  include/linux/huge_mm.h                    | 116 ++++--
>  mm/huge_memory.c                           | 268 ++++++++++++--
>  mm/khugepaged.c                            |  20 +-
>  mm/memory.c                                | 114 +++++-
>  mm/page_vma_mapped.c                       |   3 +-
>  mm/rmap.c                                  |  32 +-
>  tools/testing/selftests/mm/Makefile        |   4 +-
>  tools/testing/selftests/mm/cow.c           | 185 +++++++---
>  tools/testing/selftests/mm/khugepaged.c    | 410 ++++-----------------
>  tools/testing/selftests/mm/run_vmtests.sh  |   2 +
>  tools/testing/selftests/mm/thp_settings.c  | 349 ++++++++++++++++++
>  tools/testing/selftests/mm/thp_settings.h  |  80 ++++
>  15 files changed, 1177 insertions(+), 512 deletions(-)
>  create mode 100644 tools/testing/selftests/mm/thp_settings.c
>  create mode 100644 tools/testing/selftests/mm/thp_settings.h
>
> --
> 2.25.1
>

Thanks
Barry


From ankita at nvidia.com  Mon Dec  4 19:30:15 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Tue, 5 Dec 2023 09:00:15 +0530
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
Message-ID: <20231205033015.10044-1-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

Currently, KVM for ARM64 maps at stage 2 memory that is considered device
(i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting
overrides (as per the ARM architecture [1]) any device MMIO mapping
present at stage 1, resulting in a set-up whereby a guest operating
system cannot determine device MMIO mapping memory attributes on its
own but it is always overridden by the KVM stage 2 default.

This set-up does not allow guest operating systems to select device
memory attributes independently from KVM stage-2 mappings
(refer to [1], "Combining stage 1 and stage 2 memory type attributes"),
which turns out to be an issue in that guest operating systems
(e.g. Linux) may request to map devices MMIO regions with memory
attributes that guarantee better performance (e.g. gathering
attribute - that for some devices can generate larger PCIe memory
writes TLPs) and specific operations (e.g. unaligned transactions)
such as the NormalNC memory type.

The default device stage 2 mapping was chosen in KVM for ARM64 since
it was considered safer (i.e. it would not allow guests to trigger
uncontained failures ultimately crashing the machine) but this
turned out to be asynchronous (SError) defeating the purpose.

Failures containability is a property of the platform and is independent
from the memory type used for MMIO device memory mappings.

Actually, DEVICE_nGnRE memory type is even more problematic than
Normal-NC memory type in terms of faults containability in that e.g.
aborts triggered on DEVICE_nGnRE loads cannot be made, architecturally,
synchronous (i.e. that would imply that the processor should issue at
most 1 load transaction at a time - it cannot pipeline them - otherwise
the synchronous abort semantics would break the no-speculation attribute
attached to DEVICE_XXX memory).

This means that regardless of the combined stage1+stage2 mappings a
platform is safe if and only if device transactions cannot trigger
uncontained failures and that in turn relies on platform capabilities
and the device type being assigned (i.e. PCIe AER/DPC error containment
and RAS architecture[3]); therefore the default KVM device stage 2
memory attributes play no role in making device assignment safer
for a given platform (if the platform design adheres to design
guidelines outlined in [3]) and therefore can be relaxed.

For all these reasons, relax the KVM stage 2 device memory attributes
from DEVICE_nGnRE to Normal-NC. Add a new kvm_pgtable_prot flag for
Normal-NC.

The Normal-NC was chosen over a different Normal memory type default
at stage-2 (e.g. Normal Write-through) to avoid cache allocation/snooping.

Relaxing S2 KVM device MMIO mappings to Normal-NC is not expected to
trigger any issue on guest device reclaim use cases either (i.e. device
MMIO unmap followed by a device reset) at least for PCIe devices, in that
in PCIe a device reset is architected and carried out through PCI config
space transactions that are naturally ordered with respect to MMIO
transactions according to the PCI ordering rules.

Having Normal-NC S2 default puts guests in control (thanks to
stage1+stage2 combined memory attributes rules [1]) of device MMIO
regions memory mappings, according to the rules described in [1]
and summarized here ([(S1) - stage1], [(S2) - stage 2]):

S1           |  S2           | Result
NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>

It is worth noting that currently, to map devices MMIO space to user
space in a device pass-through use case the VFIO framework applies memory
attributes derived from pgprot_noncached() settings applied to VMAs, which
result in device-nGnRnE memory attributes for the stage-1 VMM mappings.

This means that a userspace mapping for device MMIO space carried
out with the current VFIO framework and a guest OS mapping for the same
MMIO space may result in a mismatched alias as described in [2].

Defaulting KVM device stage-2 mappings to Normal-NC attributes does not
change anything in this respect, in that the mismatched aliases would
only affect (refer to [2] for a detailed explanation) ordering between
the userspace and GuestOS mappings resulting stream of transactions
(i.e. it does not cause loss of property for either stream of
transactions on its own), which is harmless given that the userspace
and GuestOS access to the device is carried out through independent
transactions streams.

[1] section D8.5 - DDI0487_I_a_a-profile_architecture_reference_manual.pdf
[2] section B2.8 - DDI0487_I_a_a-profile_architecture_reference_manual.pdf
[3] sections 1.7.7.3/1.8.5.2/appendix C - DEN0029H_SBSA_7.1.pdf

Applied over next-20231201

History
=======
v1 -> v2
- Updated commit log to the one posted by
  Lorenzo Pieralisi <lpieralisi at kernel.org> (Thanks!)
- Added new flag to represent the NORMAL_NC setting. Updated
  stage2_set_prot_attr() to handle new flag.

v1 Link:
https://lore.kernel.org/all/20230907181459.18145-3-ankita at nvidia.com/

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>

---
 arch/arm64/include/asm/kvm_pgtable.h |  2 ++
 arch/arm64/include/asm/memory.h      |  2 ++
 arch/arm64/kvm/hyp/pgtable.c         | 11 +++++++++--
 arch/arm64/kvm/mmu.c                 |  4 ++--
 4 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index cfdf40f734b1..19278dfe7978 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -197,6 +197,7 @@ enum kvm_pgtable_stage2_flags {
  * @KVM_PGTABLE_PROT_W:		Write permission.
  * @KVM_PGTABLE_PROT_R:		Read permission.
  * @KVM_PGTABLE_PROT_DEVICE:	Device attributes.
+ * @KVM_PGTABLE_PROT_NORMAL_NC:	Normal noncacheable attributes.
  * @KVM_PGTABLE_PROT_SW0:	Software bit 0.
  * @KVM_PGTABLE_PROT_SW1:	Software bit 1.
  * @KVM_PGTABLE_PROT_SW2:	Software bit 2.
@@ -208,6 +209,7 @@ enum kvm_pgtable_prot {
 	KVM_PGTABLE_PROT_R			= BIT(2),
 
 	KVM_PGTABLE_PROT_DEVICE			= BIT(3),
+	KVM_PGTABLE_PROT_NORMAL_NC		= BIT(4),
 
 	KVM_PGTABLE_PROT_SW0			= BIT(55),
 	KVM_PGTABLE_PROT_SW1			= BIT(56),
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index fde4186cc387..c247e5f29d5a 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -147,6 +147,7 @@
  * Memory types for Stage-2 translation
  */
 #define MT_S2_NORMAL		0xf
+#define MT_S2_NORMAL_NC		0x5
 #define MT_S2_DEVICE_nGnRE	0x1
 
 /*
@@ -154,6 +155,7 @@
  * Stage-2 enforces Normal-WB and Device-nGnRE
  */
 #define MT_S2_FWB_NORMAL	6
+#define MT_S2_FWB_NORMAL_NC	5
 #define MT_S2_FWB_DEVICE_nGnRE	1
 
 #ifdef CONFIG_ARM64_4K_PAGES
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index c651df904fe3..d4835d553c61 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -718,10 +718,17 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
 				kvm_pte_t *ptep)
 {
 	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
-	kvm_pte_t attr = device ? KVM_S2_MEMATTR(pgt, DEVICE_nGnRE) :
-			    KVM_S2_MEMATTR(pgt, NORMAL);
+	bool normal_nc = prot & KVM_PGTABLE_PROT_NORMAL_NC;
+	kvm_pte_t attr;
 	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
 
+	if (device)
+		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
+	else if (normal_nc)
+		attr = KVM_S2_MEMATTR(pgt, NORMAL_NC);
+	else
+		attr = KVM_S2_MEMATTR(pgt, NORMAL);
+
 	if (!(prot & KVM_PGTABLE_PROT_X))
 		attr |= KVM_PTE_LEAF_ATTR_HI_S2_XN;
 	else if (device)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index d14504821b79..1cb302457d3f 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1071,7 +1071,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
 	struct kvm_mmu_memory_cache cache = { .gfp_zero = __GFP_ZERO };
 	struct kvm_s2_mmu *mmu = &kvm->arch.mmu;
 	struct kvm_pgtable *pgt = mmu->pgt;
-	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_DEVICE |
+	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_NORMAL_NC |
 				     KVM_PGTABLE_PROT_R |
 				     (writable ? KVM_PGTABLE_PROT_W : 0);
 
@@ -1558,7 +1558,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 		prot |= KVM_PGTABLE_PROT_X;
 
 	if (device)
-		prot |= KVM_PGTABLE_PROT_DEVICE;
+		prot |= KVM_PGTABLE_PROT_NORMAL_NC;
 	else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
 		prot |= KVM_PGTABLE_PROT_X;
 
-- 
2.17.1



From namhyung at kernel.org  Mon Dec  4 19:33:18 2023
From: namhyung at kernel.org (Namhyung Kim)
Date: Mon, 4 Dec 2023 19:33:18 -0800
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
References: <20231204182330.654255-1-irogers@google.com> <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
Message-ID: <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com>

Hello,

On Mon, Dec 4, 2023 at 2:45?PM Ilkka Koskinen
<ilkka at os.amperecomputing.com> wrote:
>
>
>
> On Mon, 4 Dec 2023, Ian Rogers wrote:
> > A metric is default by having "Default" within its groups. The default
> > metricgroup name needn't be set and this can result in segv in
> > default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
> > that assume it has a value when there is a Default metric group. To
> > avoid the segv initialize the value to "".
> >
> > Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
> > Signed-off-by: Ian Rogers <irogers at google.com>
>
> Thanks! I was going to look for the bug but got pulled to other
> tasks. The patch looks good to me and I tested it successfully on
> AmpereOne.
>
>    Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>

Looks like it needs to go through perf-tools for v6.7.
Ian, do you think this one is enough?

Thanks,
Namhyung


From jhubbard at nvidia.com  Mon Dec  4 19:37:34 2023
From: jhubbard at nvidia.com (John Hubbard)
Date: Mon, 4 Dec 2023 19:37:34 -0800
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <2be046e1-ef95-4244-ae23-e56071ae1218@nvidia.com>

On 12/4/23 02:20, Ryan Roberts wrote:
> Hi All,
> 
> A new week, a new version, a new name... This is v8 of a series to implement
> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
> this fares better.
> 
> The objective of this is to improve performance by allocating larger chunks of
> memory during anonymous page faults:
> 
> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>     pages, there are efficiency savings to be had; fewer page faults, batched PTE
>     and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>     overhead. This should benefit all architectures.
> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>     advantage of HW TLB compression techniques. A reduction in TLB pressure
>     speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>     TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
> 
> This version changes the name and tidies up some of the kernel code and test
> code, based on feedback against v7 (see change log for details).

Using a couple of Armv8 systems, I've tested this patchset. I applied it
to top of tree (Linux 6.7-rc4), on top of your latest contig pte series
[1].

With those two patchsets applied, the mm selftests look OK--or at least
as OK as they normally do. I compared test runs between THP/mTHP set to
"always", vs "never", to verify that there were no new test failures.
Details: specifically, I set one particular page size (2 MB) to
"inherit", and then toggled /sys/kernel/mm/transparent_hugepage/enabled
between "always" and "never".

I also re-ran my usual compute/AI benchmark, and I'm still seeing the
same 10x performance improvement that I reported for the v6 patchset.

So for this patchset and for [1] as well, please feel free to add:

Tested-by: John Hubbard <jhubbard at nvidia.com>


[1] https://lore.kernel.org/all/20231204105440.61448-1-ryan.roberts at arm.com/


thanks,
-- 
John Hubbard
NVIDIA

> 
> By default, the existing behaviour (and performance) is maintained. The user
> must explicitly enable multi-size THP to see the performance benefit. This is
> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
> David for the suggestion)! This interface is inspired by the existing
> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
> compatibility with the existing PMD-size THP interface, and provides a base for
> future extensibility. See [8] for detailed discussion of the interface.
> 
> This series is based on mm-unstable (715b67adf4c8).
> 
> 
> Prerequisites
> =============
> 
> Some work items identified as being prerequisites are listed on page 3 at [9].
> The summary is:
> 
> | item                          | status                  |
> |:------------------------------|:------------------------|
> | mlock                         | In mainline (v6.7)      |
> | madvise                       | In mainline (v6.6)      |
> | compaction                    | v1 posted [10]          |
> | numa balancing                | Investigated: see below |
> | user-triggered page migration | In mainline (v6.7)      |
> | khugepaged collapse           | In mainline (NOP)       |
> 
> On NUMA balancing, which currently ignores any PTE-mapped THPs it encounters,
> John Hubbard has investigated this and concluded that it is A) not clear at the
> moment what a better policy might be for PTE-mapped THP and B) questions whether
> this should really be considered a prerequisite given no regression is caused
> for the default "multi-size THP disabled" case, and there is no correctness
> issue when it is enabled - its just a potential for non-optimal performance.
> 
> If there are no disagreements about removing numa balancing from the list (none
> were raised when I first posted this comment against v7), then that just leaves
> compaction which is in review on list at the moment.
> 
> I really would like to get this series (and its remaining comapction
> prerequisite) in for v6.8. I accept that it may be a bit optimistic at this
> point, but lets see where we get to with review?
> 
> 
> Testing
> =======
> 
> The series includes patches for mm selftests to enlighten the cow and khugepaged
> tests to explicitly test with multi-size THP, in the same way that PMD-sized
> THP is tested. The new tests all pass, and no regressions are observed in the mm
> selftest suite. I've also run my usual kernel compilation and java script
> benchmarks without any issues.
> 
> Refer to my performance numbers posted with v6 [6]. (These are for multi-size
> THP only - they do not include the arm64 contpte follow-on series).
> 
> John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
> some workloads at [11]. (Observed using v6 of this series as well as the arm64
> contpte series).
> 
> Kefeng Wang at Huawei has also indicated he sees improvements at [12] although
> there are some latency regressions also.
> 
> 
> Changes since v7 [7]
> ====================
> 
>    - Renamed "small-sized THP" -> "multi-size THP" in commit logs
>    - Added various Reviewed-by/Tested-by tags (Barry, David, Alistair)
>    - Patch 3:
>        - Fine-tuned transhuge documentation multi-size THP (JohnH)
>        - Converted hugepage_global_enabled() and hugepage_global_always() macros
>          to static inline functions (JohnH)
>        - Renamed hugepage_vma_check() to thp_vma_allowable_orders() (JohnH)
>        - Renamed transhuge_vma_suitable() to thp_vma_suitable_orders() (JohnH)
>        - Renamed "global" enabled sysfs file option to "inherit" (JohnH)
>    - Patch 9:
>        - cow selftest: Renamed param size -> thpsize (David)
>        - cow selftest: Changed test fail to assert() (David)
>        - cow selftest: Log PMD size separately from all the supported THP sizes
>          (David)
>    - Patch 10:
>        - cow selftest: No longer special case pmdsize; keep all THP sizes in
>          thpsizes[]
> 
> 
> Changes since v6 [6]
> ====================
> 
>    - Refactored vmf_pte_range_changed() to remove uffd special-case (suggested by
>      JohnH)
>    - Dropped accounting patch (#3 in v6) (suggested by DavidH)
>        - Continue to account *PMD-sized* THP only for now
>        - Can add more counters in future if needed
>        - Page cache large folios haven't needed any new counters yet
>    - Pivot to sysfs ABI proposed by DavidH
>        - per-size directories in a similar shape to that used by hugetlb
>    - Dropped "recommend" keyword patch (#6 in v6) (suggested by DavidH, Yu Zhou)
>        - For now, users need to understand implicitly which sizes are beneficial
>          to their HW/SW
>    - Dropped arch_wants_pte_order() patch (#7 in v6)
>        - No longer needed due to dropping patch "recommend" keyword patch
>    - Enlightened khugepaged mm selftest to explicitly test with small-size THP
>    - Scrubbed commit logs to use "small-sized THP" consistently (suggested by
>      DavidH)
> 
> 
> Changes since v5 [5]
> ====================
> 
>    - Added accounting for PTE-mapped THPs (patch 3)
>    - Added runtime control mechanism via sysfs as extension to THP (patch 4)
>    - Minor refactoring of alloc_anon_folio() to integrate with runtime controls
>    - Stripped out hardcoded policy for allocation order; its now all user space
>      controlled (although user space can request "recommend" which will configure
>      the HW-preferred order)
> 
> 
> Changes since v4 [4]
> ====================
> 
>    - Removed "arm64: mm: Override arch_wants_pte_order()" patch; arm64
>      now uses the default order-3 size. I have moved this patch over to
>      the contpte series.
>    - Added "mm: Allow deferred splitting of arbitrary large anon folios" back
>      into series. I originally removed this at v2 to add to a separate series,
>      but that series has transformed significantly and it no longer fits, so
>      bringing it back here.
>    - Reintroduced dependency on set_ptes(); Originally dropped this at v2, but
>      set_ptes() is in mm-unstable now.
>    - Updated policy for when to allocate LAF; only fallback to order-0 if
>      MADV_NOHUGEPAGE is present or if THP disabled via prctl; no longer rely on
>      sysfs's never/madvise/always knob.
>    - Fallback to order-0 whenever uffd is armed for the vma, not just when
>      uffd-wp is set on the pte.
>    - alloc_anon_folio() now returns `struct folio *`, where errors are encoded
>      with ERR_PTR().
> 
>    The last 3 changes were proposed by Yu Zhao - thanks!
> 
> 
> Changes since v3 [3]
> ====================
> 
>    - Renamed feature from FLEXIBLE_THP to LARGE_ANON_FOLIO.
>    - Removed `flexthp_unhinted_max` boot parameter. Discussion concluded that a
>      sysctl is preferable but we will wait until real workload needs it.
>    - Fixed uninitialized `addr` on read fault path in do_anonymous_page().
>    - Added mm selftests for large anon folios in cow test suite.
> 
> 
> Changes since v2 [2]
> ====================
> 
>    - Dropped commit "Allow deferred splitting of arbitrary large anon folios"
>        - Huang, Ying suggested the "batch zap" work (which I dropped from this
>          series after v1) is a prerequisite for merging FLXEIBLE_THP, so I've
>          moved the deferred split patch to a separate series along with the batch
>          zap changes. I plan to submit this series early next week.
>    - Changed folio order fallback policy
>        - We no longer iterate from preferred to 0 looking for acceptable policy
>        - Instead we iterate through preferred, PAGE_ALLOC_COSTLY_ORDER and 0 only
>    - Removed vma parameter from arch_wants_pte_order()
>    - Added command line parameter `flexthp_unhinted_max`
>        - clamps preferred order when vma hasn't explicitly opted-in to THP
>    - Never allocate large folio for MADV_NOHUGEPAGE vma (or when THP is disabled
>      for process or system).
>    - Simplified implementation and integration with do_anonymous_page()
>    - Removed dependency on set_ptes()
> 
> 
> Changes since v1 [1]
> ====================
> 
>    - removed changes to arch-dependent vma_alloc_zeroed_movable_folio()
>    - replaced with arch-independent alloc_anon_folio()
>        - follows THP allocation approach
>    - no longer retry with intermediate orders if allocation fails
>        - fallback directly to order-0
>    - remove folio_add_new_anon_rmap_range() patch
>        - instead add its new functionality to folio_add_new_anon_rmap()
>    - remove batch-zap pte mappings optimization patch
>        - remove enabler folio_remove_rmap_range() patch too
>        - These offer real perf improvement so will submit separately
>    - simplify Kconfig
>        - single FLEXIBLE_THP option, which is independent of arch
>        - depends on TRANSPARENT_HUGEPAGE
>        - when enabled default to max anon folio size of 64K unless arch
>          explicitly overrides
>    - simplify changes to do_anonymous_page():
>        - no more retry loop
> 
> 
> [1] https://lore.kernel.org/linux-mm/20230626171430.3167004-1-ryan.roberts at arm.com/
> [2] https://lore.kernel.org/linux-mm/20230703135330.1865927-1-ryan.roberts at arm.com/
> [3] https://lore.kernel.org/linux-mm/20230714160407.4142030-1-ryan.roberts at arm.com/
> [4] https://lore.kernel.org/linux-mm/20230726095146.2826796-1-ryan.roberts at arm.com/
> [5] https://lore.kernel.org/linux-mm/20230810142942.3169679-1-ryan.roberts at arm.com/
> [6] https://lore.kernel.org/linux-mm/20230929114421.3761121-1-ryan.roberts at arm.com/
> [7] https://lore.kernel.org/linux-mm/20231122162950.3854897-1-ryan.roberts at arm.com/
> [8] https://lore.kernel.org/linux-mm/6d89fdc9-ef55-d44e-bf12-fafff318aef8 at redhat.com/
> [9] https://drive.google.com/file/d/1GnfYFpr7_c1kA41liRUW5YtCb8Cj18Ud/view?usp=sharing&resourcekey=0-U1Mj3-RhLD1JV6EThpyPyA
> [10] https://lore.kernel.org/linux-mm/20231113170157.280181-1-zi.yan at sent.com/
> [11] https://lore.kernel.org/linux-mm/c507308d-bdd4-5f9e-d4ff-e96e4520be85 at nvidia.com/
> [12] https://lore.kernel.org/linux-mm/479b3e2b-456d-46c1-9677-38f6c95a0be8 at huawei.com/
> 
> 
> Thanks,
> Ryan
> 
> Ryan Roberts (10):
>    mm: Allow deferred splitting of arbitrary anon large folios
>    mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()
>    mm: thp: Introduce multi-size THP sysfs interface
>    mm: thp: Support allocation of anonymous multi-size THP
>    selftests/mm/kugepaged: Restore thp settings at exit
>    selftests/mm: Factor out thp settings management
>    selftests/mm: Support multi-size THP interface in thp_settings
>    selftests/mm/khugepaged: Enlighten for multi-size THP
>    selftests/mm/cow: Generalize do_run_with_thp() helper
>    selftests/mm/cow: Add tests for anonymous multi-size THP
> 
>   Documentation/admin-guide/mm/transhuge.rst |  97 ++++-
>   Documentation/filesystems/proc.rst         |   6 +-
>   fs/proc/task_mmu.c                         |   3 +-
>   include/linux/huge_mm.h                    | 116 ++++--
>   mm/huge_memory.c                           | 268 ++++++++++++--
>   mm/khugepaged.c                            |  20 +-
>   mm/memory.c                                | 114 +++++-
>   mm/page_vma_mapped.c                       |   3 +-
>   mm/rmap.c                                  |  32 +-
>   tools/testing/selftests/mm/Makefile        |   4 +-
>   tools/testing/selftests/mm/cow.c           | 185 +++++++---
>   tools/testing/selftests/mm/khugepaged.c    | 410 ++++-----------------
>   tools/testing/selftests/mm/run_vmtests.sh  |   2 +
>   tools/testing/selftests/mm/thp_settings.c  | 349 ++++++++++++++++++
>   tools/testing/selftests/mm/thp_settings.h  |  80 ++++
>   15 files changed, 1177 insertions(+), 512 deletions(-)
>   create mode 100644 tools/testing/selftests/mm/thp_settings.c
>   create mode 100644 tools/testing/selftests/mm/thp_settings.h
> 
> --
> 2.25.1
> 




From nicolinc at nvidia.com  Mon Dec  4 19:38:41 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 19:38:41 -0800
Subject: [PATCH v2 12/19] iommu/arm-smmu-v3: Put writing the context
 descriptor in the right order
In-Reply-To: <12-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <12-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6bQTvu1EoGaV08@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:19PM -0400, Jason Gunthorpe wrote:
> Get closer to the IOMMU API ideal that changes between domains can be
> hitless. The ordering for the CD table entry is not entirely clean from
> this perspective.
> 
> When switching away from a STE with a CD table programmed in it we should
> write the new STE first, then clear any old data in the CD entry.
> 
> If we are programming a CD table for the first time to a STE then the CD
> entry should be programmed before the STE is loaded.
> 
> If we are replacing a CD table entry when the STE already points at the CD
> entry then we just need to do the make/break sequence.
> 
> Lift this code out of arm_smmu_detach_dev() so it can all be sequenced
> properly. The only other caller is arm_smmu_release_device() and it is
> going to free the cdtable anyhow, so it doesn't matter what is in it.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From jhubbard at nvidia.com  Mon Dec  4 19:41:02 2023
From: jhubbard at nvidia.com (John Hubbard)
Date: Mon, 4 Dec 2023 19:41:02 -0800
Subject: [PATCH v3 00/15] Transparent Contiguous PTEs for User Mappings
In-Reply-To: <20231204105440.61448-1-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
Message-ID: <ea345a14-0a39-425c-a2df-d163ca948f57@nvidia.com>

On 12/4/23 02:54, Ryan Roberts wrote:
> Hi All,
> 
> This is v3 of a series to opportunistically and transparently use contpte
> mappings (set the contiguous bit in ptes) for user memory when those mappings
> meet the requirements. It is part of a wider effort to improve performance by
> allocating and mapping variable-sized blocks of memory (folios). One aim is for
> the 4K kernel to approach the performance of the 16K kernel, but without
> breaking compatibility and without the associated increase in memory. Another
> aim is to benefit the 16K and 64K kernels by enabling 2M THP, since this is the
> contpte size for those kernels. We have good performance data that demonstrates
> both aims are being met (see below).
> 
> Of course this is only one half of the change. We require the mapped physical
> memory to be the correct size and alignment for this to actually be useful (i.e.
> 64K for 4K pages, or 2M for 16K/64K pages). Fortunately folios are solving this
> problem for us. Filesystems that support it (XFS, AFS, EROFS, tmpfs, ...) will
> allocate large folios up to the PMD size today, and more filesystems are coming.
> And the other half of my work, to enable "multi-size THP" (large folios) for
> anonymous memory, makes contpte sized folios prevalent for anonymous memory too
> [3].
> 

Hi Ryan,

Using a couple of Armv8 systems, I've tested this patchset. Details are in my
reply to the mTHP patchset [1].

So for this patchset, please feel free to add:

Tested-by: John Hubbard <jhubbard at nvidia.com>


[1] https://lore.kernel.org/all/2be046e1-ef95-4244-ae23-e56071ae1218 at nvidia.com/


thanks,
-- 
John Hubbard
NVIDIA

> Optimistically, I would really like to get this series merged for v6.8; there is
> a chance that the multi-size THP series will also get merged for that version
> (although at this point pretty small). But even if it doesn't, this series still
> benefits file-backed memory from the file systems that support large folios so
> shouldn't be held up for it. Additionally I've got data that shows this series
> adds no regression when the system has no appropriate large folios.
> 
> All dependecies listed against v1 are now resolved; This series applies cleanly
> against v6.7-rc1.
> 
> Note that the first two patchs are for core-mm and provides the refactoring to
> make some crucial optimizations possible - which are then implemented in patches
> 14 and 15. The remaining patches are arm64-specific.
> 
> Testing
> =======
> 
> I've tested this series together with multi-size THP [3] on both Ampere Altra
> (bare metal) and Apple M2 (VM):
>    - mm selftests (inc new tests written for multi-size THP); no regressions
>    - Speedometer Java script benchmark in Chromium web browser; no issues
>    - Kernel compilation; no issues
>    - Various tests under high memory pressure with swap enabled; no issues
> 
> 
> Performance
> ===========
> 
> John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
> some workloads at [4], when using 64K base page kernel.
> 
> You can also see the original performance results I posted against v1 [1] which
> are still valid.
> 
> I've additionally run the kernel compilation and speedometer benchmarks on a
> system with multi-size THP disabled and large folio support for file-backed
> memory intentionally disabled; I see no change in performance in this case (i.e.
> no regression when this change is "present but not useful").
> 
> 
> Changes since v2 [2]
> ====================
> 
>    - Removed contpte_ptep_get_and_clear_full() optimisation for exit() (v2#14),
>      and replaced with a batch-clearing approach using a new arch helper,
>      clear_ptes() (v3#2 and v3#15) (Alistair and Barry)
>    - (v2#1 / v3#1)
>        - Fixed folio refcounting so that refcount >= mapcount always (DavidH)
>        - Reworked batch demarcation to avoid pte_pgprot() (DavidH)
>        - Reverted return semantic of copy_present_page() and instead fix it up in
>          copy_present_ptes() (Alistair)
>        - Removed page_cont_mapped_vaddr() and replaced with simpler logic
>          (Alistair)
>        - Made batch accounting clearer in copy_pte_range() (Alistair)
>    - (v2#12 / v3#13)
>        - Renamed contpte_fold() -> contpte_convert() and hoisted setting/
>          clearing CONT_PTE bit to higher level (Alistair)
> 
> 
> Changes since v1 [1]
> ====================
> 
>    - Export contpte_* symbols so that modules can continue to call inline
>      functions (e.g. ptep_get) which may now call the contpte_* functions (thanks
>      to JohnH)
>    - Use pte_valid() instead of pte_present() where sensible (thanks to Catalin)
>    - Factor out (pte_valid() && pte_cont()) into new pte_valid_cont() helper
>      (thanks to Catalin)
>    - Fixed bug in contpte_ptep_set_access_flags() where TLBIs were missed (thanks
>      to Catalin)
>    - Added ARM64_CONTPTE expert Kconfig (enabled by default) (thanks to Anshuman)
>    - Simplified contpte_ptep_get_and_clear_full()
>    - Improved various code comments
> 
> 
> [1] https://lore.kernel.org/linux-arm-kernel/20230622144210.2623299-1-ryan.roberts at arm.com/
> [2] https://lore.kernel.org/linux-arm-kernel/20231115163018.1303287-1-ryan.roberts at arm.com/
> [3] https://lore.kernel.org/linux-arm-kernel/20231204102027.57185-1-ryan.roberts at arm.com/
> [4] https://lore.kernel.org/linux-mm/c507308d-bdd4-5f9e-d4ff-e96e4520be85 at nvidia.com/
> 
> 
> Thanks,
> Ryan
> 
> Ryan Roberts (15):
>    mm: Batch-copy PTE ranges during fork()
>    mm: Batch-clear PTE ranges during zap_pte_range()
>    arm64/mm: set_pte(): New layer to manage contig bit
>    arm64/mm: set_ptes()/set_pte_at(): New layer to manage contig bit
>    arm64/mm: pte_clear(): New layer to manage contig bit
>    arm64/mm: ptep_get_and_clear(): New layer to manage contig bit
>    arm64/mm: ptep_test_and_clear_young(): New layer to manage contig bit
>    arm64/mm: ptep_clear_flush_young(): New layer to manage contig bit
>    arm64/mm: ptep_set_wrprotect(): New layer to manage contig bit
>    arm64/mm: ptep_set_access_flags(): New layer to manage contig bit
>    arm64/mm: ptep_get(): New layer to manage contig bit
>    arm64/mm: Split __flush_tlb_range() to elide trailing DSB
>    arm64/mm: Wire up PTE_CONT for user mappings
>    arm64/mm: Implement ptep_set_wrprotects() to optimize fork()
>    arm64/mm: Implement clear_ptes() to optimize exit()
> 
>   arch/arm64/Kconfig                |  10 +-
>   arch/arm64/include/asm/pgtable.h  | 343 ++++++++++++++++++++---
>   arch/arm64/include/asm/tlbflush.h |  13 +-
>   arch/arm64/kernel/efi.c           |   4 +-
>   arch/arm64/kernel/mte.c           |   2 +-
>   arch/arm64/kvm/guest.c            |   2 +-
>   arch/arm64/mm/Makefile            |   1 +
>   arch/arm64/mm/contpte.c           | 436 ++++++++++++++++++++++++++++++
>   arch/arm64/mm/fault.c             |  12 +-
>   arch/arm64/mm/fixmap.c            |   4 +-
>   arch/arm64/mm/hugetlbpage.c       |  40 +--
>   arch/arm64/mm/kasan_init.c        |   6 +-
>   arch/arm64/mm/mmu.c               |  16 +-
>   arch/arm64/mm/pageattr.c          |   6 +-
>   arch/arm64/mm/trans_pgd.c         |   6 +-
>   include/asm-generic/tlb.h         |   9 +
>   include/linux/pgtable.h           |  39 +++
>   mm/memory.c                       | 258 +++++++++++++-----
>   mm/mmu_gather.c                   |  14 +
>   19 files changed, 1067 insertions(+), 154 deletions(-)
>   create mode 100644 arch/arm64/mm/contpte.c
> 
> --
> 2.25.1
> 




From nicolinc at nvidia.com  Mon Dec  4 19:54:16 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 19:54:16 -0800
Subject: [PATCH v2 00/19] Update SMMUv3 to the modern iommu API (part 1/3)
In-Reply-To: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6e6H4BGVWw7C9o@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:07PM -0400, Jason Gunthorpe wrote:
 
> Overall this takes the approach of turning the STE/CD programming upside
> down where the CD/STE value is computed right at a driver callback
> function and then pushed down into programming logic. The programming
> logic hides the details of the required CD/STE tear-less update. This
> makes the CD/STE functions independent of the arm_smmu_domain which makes
> it fairly straightforward to untangle all the different call chains, and
> add news ones.
> 
> Further, this frees the arm_smmu_domain related logic from keeping track
> of what state the STE/CD is currently in so it can carefully sequence the
> correct update. There are many new update pairs that are subtly introduced
> as the work progresses.
> 
> The locking to support BTM via arm_smmu_asid_lock is a bit subtle right
> now and patches throughout this work adjust and tighten this so that it is
> clearer and doesn't get broken.
> 
> Once the lower STE layers no longer need to touch arm_smmu_domain we can
> isolate struct arm_smmu_domain to be only used for PAGING domains, audit
> all the to_smmu_domain() calls to be only in PAGING domain ops, and
> introduce the normal global static BLOCKED/IDENTITY domains using the new
> STE infrastructure. Part 2 will ultimately migrate SVA over to use
> arm_smmu_domain as well.
> 
> All parts are on github:
> 
>  https://github.com/jgunthorpe/linux/commits/smmuv3_newapi

Ran sanity with part-1 alone, covering S1 Translate and SVA cases.

And ran more functional tests with part-2 and part-3 (nested) in
the repo above, covering host-level S1 Translate, S1DSS_BYPASS +
SVA, and guest VM (stage-2 alone, and stage-1+2 with S1DSS_SSID0
and S1DSS_BYPASS). These should test quite a list of combinations
against the STE updating algorithm.

Tested-by: Nicolin Chen <nicolinc at nvidia.com>


From anshuman.khandual at arm.com  Mon Dec  4 19:56:30 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Tue, 5 Dec 2023 09:26:30 +0530
Subject: [PATCH V2 5/7] coresight: tmc: Move ACPI support from AMBA driver
 to platform driver
In-Reply-To: <fe5c82d1-8b7d-6701-4e19-9019f23d9c7b@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-6-anshuman.khandual@arm.com>
 <fe5c82d1-8b7d-6701-4e19-9019f23d9c7b@arm.com>
Message-ID: <604b5b56-9f48-434e-b328-0b9616b47ec8@arm.com>

On 12/4/23 16:24, James Clark wrote:
> 
> 
> On 01/12/2023 06:20, Anshuman Khandual wrote:
>> Add support for the tmc devices in the platform driver, which can then be
>> used on ACPI based platforms. This change would now allow runtime power
>> management for ACPI based systems. The driver would try to enable the APB
>> clock if available.
>>
> [...]
>> -module_amba_driver(tmc_driver);
>> +static int tmc_platform_probe(struct platform_device *pdev)
>> +{
>> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +	struct tmc_drvdata *drvdata;
>> +	int ret = 0;
>> +
>> +	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
>> +	if (!drvdata)
>> +		return -ENOMEM;
>> +
>> +	drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
>> +	if (IS_ERR(drvdata->pclk))
>> +		return -ENODEV;
>> +
>> +	dev_set_drvdata(&pdev->dev, drvdata);
>> +	pm_runtime_get_noresume(&pdev->dev);
>> +	pm_runtime_set_active(&pdev->dev);
>> +	pm_runtime_enable(&pdev->dev);
>> +
>> +	ret = __tmc_probe(&pdev->dev, res, NULL);
>> +	if (ret) {
>> +		pm_runtime_put_noidle(&pdev->dev);
>> +		pm_runtime_disable(&pdev->dev);
>> +	}
> 
> I'm not sure if these pm_runtime()s are right because there is already a
> put inside of __tmc_probe() if it fails. If you unload and then reload

Actually there is a pm_runtime_put() on the success path, not when it
fails. So pm_runtime_put() gets called when __tmc_probe() returns 0.

__tmc_probe()
{
	....
        ret = misc_register(&drvdata->miscdev);
        if (ret)
                coresight_unregister(drvdata->csdev);
        else
                pm_runtime_put(dev);
out:
        return ret;
}

tmc_platform_probe()
{
	....
        pm_runtime_get_noresume(&pdev->dev);
        pm_runtime_set_active(&pdev->dev);
        pm_runtime_enable(&pdev->dev);

        ret = __tmc_probe(&pdev->dev, res, NULL);
        if (ret) {
                pm_runtime_put_noidle(&pdev->dev);
                pm_runtime_disable(&pdev->dev);
        }
        return ret;
}

tmc_probe()
{
	....
	return __tmc_probe(&adev->dev, &adev->res, coresight_get_uci_data(id));
}

Currently pm_runtime_put() gets called

- In success path both for AMBA and platform drivers
- In error path only for platform driver

Although the problem might be with pm_runtime_disable() instead

- pm_runtime_disable() is not required in the platform driver probe() path
- But might be required in tmc_platform_remove() along with a clk_put()

> all the coresight modules with these patches you get these errors which
> are new:
> 
>   coresight-tpiu-platform ARMHC979:00: Unbalanced pm_runtime_enable!

The code is similar in TPIU platform driver as well.

>   CSCFG registered etm0
>   coresight etm0: CPU0: etm v4.2 initialized
>   CSCFG registered etm1
>   coresight etm1: CPU1: etm v4.2 initialized
>   CSCFG registered etm2
>   coresight etm2: CPU2: etm v4.2 initialized
>   CSCFG registered etm3
>   coresight etm3: CPU3: etm v4.2 initialized
>   coresight-tmc-platform ARMHC97C:00: Unbalanced pm_runtime_enable!
>   coresight-tmc-platform ARMHC97C:01: Unbalanced pm_runtime_enable!
>   coresight-tmc-platform ARMHC97C:02: Unbalanced pm_runtime_enable!
>   coresight-tmc-platform ARMHC97C:03: Unbalanced pm_runtime_enable!
> 
> It might be worth testing all of these pm_runtime()s, including the
> error case ones, because loading and unloading the modules doesn't even
> include the error scenarios, so there are probably more bad ones in
> there too.
The code is very similar in CATU, STM as well but debug_platform_remove()
seems to be doing this right.

I am not very familiar with all the power management aspects in coresight,
please do let me know if I missing something here.


From yangyicong at huawei.com  Mon Dec  4 19:56:32 2023
From: yangyicong at huawei.com (Yicong Yang)
Date: Tue, 5 Dec 2023 11:56:32 +0800
Subject: [PATCH] drivers/perf: hisi: Fix some event id for HiSilicon UC
 pmu
In-Reply-To: <20231204110425.20354-1-hejunhao3@huawei.com>
References: <20231204110425.20354-1-hejunhao3@huawei.com>
Message-ID: <ead56142-e0a5-d061-b8f9-02add7a3b211@huawei.com>

On 2023/12/4 19:04, Junhao He wrote:
> Some event id of HiSilicon uncore UC PMU driver is incorrect, fix them.
> 
> Fixes: 312eca95e28d ("drivers/perf: hisi: Add support for HiSilicon UC PMU driver")
> Signed-off-by: Junhao He <hejunhao3 at huawei.com>

Reviewed-by: Yicong Yang <yangyicong at hisilicon.com>

> ---
>  drivers/perf/hisilicon/hisi_uncore_uc_pmu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/perf/hisilicon/hisi_uncore_uc_pmu.c b/drivers/perf/hisilicon/hisi_uncore_uc_pmu.c
> index 63da05e5831c..636fb79647c8 100644
> --- a/drivers/perf/hisilicon/hisi_uncore_uc_pmu.c
> +++ b/drivers/perf/hisilicon/hisi_uncore_uc_pmu.c
> @@ -383,8 +383,8 @@ static struct attribute *hisi_uc_pmu_events_attr[] = {
>  	HISI_PMU_EVENT_ATTR(cpu_rd,		0x10),
>  	HISI_PMU_EVENT_ATTR(cpu_rd64,		0x17),
>  	HISI_PMU_EVENT_ATTR(cpu_rs64,		0x19),
> -	HISI_PMU_EVENT_ATTR(cpu_mru,		0x1a),
> -	HISI_PMU_EVENT_ATTR(cycles,		0x9c),
> +	HISI_PMU_EVENT_ATTR(cpu_mru,		0x1c),
> +	HISI_PMU_EVENT_ATTR(cycles,		0x95),
>  	HISI_PMU_EVENT_ATTR(spipe_hit,		0xb3),
>  	HISI_PMU_EVENT_ATTR(hpipe_hit,		0xdb),
>  	HISI_PMU_EVENT_ATTR(cring_rxdat_cnt,	0xfa),
> 


From nicolinc at nvidia.com  Mon Dec  4 19:56:31 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 19:56:31 -0800
Subject: [PATCH v2 13/19] iommu/arm-smmu-v3: Pass smmu_domain to
 arm_enable/disable_ats()
In-Reply-To: <13-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <13-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6fbyD8VEq7u69/@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:20PM -0400, Jason Gunthorpe wrote:
> The caller already has the domain, just pass it in. A following patch will
> remove master->domain.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
 
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From fancer.lancer at gmail.com  Mon Dec  4 20:02:26 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue, 5 Dec 2023 07:02:26 +0300
Subject: [PATCH net-next v2 0/3] net: stmmac: EST implementation
In-Reply-To: <20231201055252.1302-1-rohan.g.thomas@intel.com>
References: <20231201055252.1302-1-rohan.g.thomas@intel.com>
Message-ID: <d3e5i54yw5vqcnn67lw6jflgxgkqlsk3witwufoeqfqcf66p5u@7cnxjf2ddaf2>

Hi Rohan

On Fri, Dec 01, 2023 at 01:52:49PM +0800, Rohan G Thomas wrote:
> Hi,
> This patchset extends EST interrupt handling support to DWXGMAC IP
> followed by refactoring of EST implementation. Added a separate
> module for EST and moved all EST related functions to the new module.
> 
> Also added support for EST cycle-time-extension.
> 
> changelog v2:
> * Refactor EST implementation as suggested by Serge and Jakub
> * Added support for EST cycle-time-extension

Thanks for the update and especially for keeping your promise in
refactoring the EST code. The series has already been merged in, but
anyway here is my tag:

Reviewed-by: Serge Semin <fancer.lancer at gmail.com>

* which at least for Patch 1 you must have forgotten to add since v1
* seeing the patch hasn't changed.

Regarding the multiplier and the MTL_EST_Status.BTRL field width info
you submitted earlier:

On Fri, Dec 01, 2023 at 14:49:09PM +0800, Rohan G Thomas wrote:
> Managed to get DWC_ether_qos_relnotes.pdf for v5.20a and v5.30a. But I couldn't
> find anything related to this. So for refactoring, I'm keeping the logic as in
> the upstream code to avoid any regression.
>
>>
>> Also please double check that your DW QoS Eth v5.30a for sure states that
>> MTL_EST_CONTROL.PTOV contains value multiplied by _6_. So we wouldn't
>> be wasting time trying to workaround a more complex problem than we
>> already have.
>
> Yes, I checked this again. For DW QoS Eth v5.30a the multiplier for
> MTL_EST_CONTROL.PTOV is _9_ as per the databook.
>
> Also noticed a similar difference for MTL_EST_Status.BTRL field length. As per
> the upstream code and DW QoS Eth v5.10a databook this field covers bit 8 to bit
> 11. But for the xgmac IP and DW QoS Eth v5.30a databook this field covers bit 8
> to bit 15. Again nothing mentioned in the release notes. Here also I'm keeping
> the logic as in the upstream code to avoid any regression.

Thank you for digging into the problem. It's strange that Synopsys
hasn't mentioned about so many EST CSRs changes in the Release Notes.
Anyway if nothing in there my next step would have been to reach
somebody from Synopsys to clarify the situation and find out the
reason of the change. But seeing it's an additional burden and vendors
reply not that swiftly as we would wish I guess the best choice would
be indeed keeping the semantics as is, at least until somebody finds
that problem critical.

-Serge(y)

> 
> Rohan G Thomas (3):
>   net: stmmac: xgmac: EST interrupts handling
>   net: stmmac: Refactor EST implementation
>   net: stmmac: Add support for EST cycle-time-extension
> 
>  drivers/net/ethernet/stmicro/stmmac/Makefile  |   2 +-
>  drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
>  .../net/ethernet/stmicro/stmmac/dwmac4_core.c |   4 -
>  drivers/net/ethernet/stmicro/stmmac/dwmac5.c  | 137 ---------------
>  drivers/net/ethernet/stmicro/stmmac/dwmac5.h  |  51 ------
>  .../net/ethernet/stmicro/stmmac/dwxgmac2.h    |  16 --
>  .../ethernet/stmicro/stmmac/dwxgmac2_core.c   |  53 ------
>  drivers/net/ethernet/stmicro/stmmac/hwif.c    |  21 +++
>  drivers/net/ethernet/stmicro/stmmac/hwif.h    |  22 ++-
>  drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   1 +
>  .../net/ethernet/stmicro/stmmac/stmmac_est.c  | 165 ++++++++++++++++++
>  .../net/ethernet/stmicro/stmmac/stmmac_est.h  |  64 +++++++
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c |   2 +-
>  .../net/ethernet/stmicro/stmmac/stmmac_ptp.c  |   4 +-
>  .../net/ethernet/stmicro/stmmac/stmmac_tc.c   |   8 +-
>  15 files changed, 276 insertions(+), 275 deletions(-)
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_est.c
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_est.h
> 
> -- 
> 2.26.2
> 


From nicolinc at nvidia.com  Mon Dec  4 20:05:38 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 20:05:38 -0800
Subject: [PATCH v2 16/19] iommu/arm-smmu-v3: Add a global static BLOCKED
 domain
In-Reply-To: <16-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <16-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6hkodzHPqXkLCL@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:23PM -0400, Jason Gunthorpe wrote:
> Using the same design as the IDENTITY domain install an
> STRTAB_STE_0_CFG_ABORT STE.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
 
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nicolinc at nvidia.com  Mon Dec  4 20:07:46 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 20:07:46 -0800
Subject: [PATCH v2 17/19] iommu/arm-smmu-v3: Use the identity/blocked
 domain during release
In-Reply-To: <17-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <17-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6iEnsgseEJkHE1@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:24PM -0400, Jason Gunthorpe wrote:
> Consolidate some more core by having release call
> arm_smmu_attach_dev_identity/blocked() instead of open coding this.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From raag.jadav at intel.com  Mon Dec  4 20:10:50 2023
From: raag.jadav at intel.com (Raag Jadav)
Date: Tue, 5 Dec 2023 06:10:50 +0200
Subject: [PATCH v3 0/5] Support _UID matching for integer types
In-Reply-To: <20231123100617.28020-1-raag.jadav@intel.com>
References: <20231123100617.28020-1-raag.jadav@intel.com>
Message-ID: <ZW6iyu4qF0V7wCXG@black.fi.intel.com>

On Thu, Nov 23, 2023 at 03:36:12PM +0530, Raag Jadav wrote:
> This series updates the standard ACPI helpers to support _UID matching
> for both integer and string types, and uses them in a couple of places.
> 
> Changes since v2:
> - Drop __builtin functions to reduce complexity (Rafael)
> - Update tags
> 
> Changes since v1:
> - Fix build errors

Bump.

Anything I can do to move this forward?

Raag


From 21cnbao at gmail.com  Mon Dec  4 20:21:09 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Tue, 5 Dec 2023 17:21:09 +1300
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs interface
In-Reply-To: <20231204102027.57185-4-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com> <20231204102027.57185-4-ryan.roberts@arm.com>
Message-ID: <CAGsJ_4zU6pHOwEzCQxo9UWUFmHZp0pvfgF4pKbkFfDPCRyFwyw@mail.gmail.com>

On Mon, Dec 4, 2023 at 11:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>
> In preparation for adding support for anonymous multi-size THP,
> introduce new sysfs structure that will be used to control the new
> behaviours. A new directory is added under transparent_hugepage for each
> supported THP size, and contains an `enabled` file, which can be set to
> "inherit" (to inherit the global setting), "always", "madvise" or
> "never". For now, the kernel still only supports PMD-sized anonymous
> THP, so only 1 directory is populated.
>
> The first half of the change converts transhuge_vma_suitable() and
> hugepage_vma_check() so that they take a bitfield of orders for which
> the user wants to determine support, and the functions filter out all
> the orders that can't be supported, given the current sysfs
> configuration and the VMA dimensions. If there is only 1 order set in
> the input then the output can continue to be treated like a boolean;
> this is the case for most call sites. The resulting functions are
> renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
> respectively.
>
> The second half of the change implements the new sysfs interface. It has
> been done so that each supported THP size has a `struct thpsize`, which
> describes the relevant metadata and is itself a kobject. This is pretty
> minimal for now, but should make it easy to add new per-thpsize files to
> the interface if needed in future (e.g. per-size defrag). Rather than
> keep the `enabled` state directly in the struct thpsize, I've elected to
> directly encode it into huge_anon_orders_[always|madvise|inherit]
> bitfields since this reduces the amount of work required in
> thp_vma_allowable_orders() which is called for every page fault.
>
> See Documentation/admin-guide/mm/transhuge.rst, as modified by this
> commit, for details of how the new sysfs interface works.
>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>

Reviewed-by: Barry Song <v-songbaohua at oppo.com>

> -khugepaged will be automatically started when
> -transparent_hugepage/enabled is set to "always" or "madvise, and it'll
> -be automatically shutdown if it's set to "never".
> +khugepaged will be automatically started when one or more hugepage
> +sizes are enabled (either by directly setting "always" or "madvise",
> +or by setting "inherit" while the top-level enabled is set to "always"
> +or "madvise"), and it'll be automatically shutdown when the last
> +hugepage size is disabled (either by directly setting "never", or by
> +setting "inherit" while the top-level enabled is set to "never").
>
>  Khugepaged controls
>  -------------------
>
> +.. note::
> +   khugepaged currently only searches for opportunities to collapse to
> +   PMD-sized THP and no attempt is made to collapse to other THP
> +   sizes.

For small-size THP, collapse is probably a bad idea. we like a one-shot
try in Android especially we are using a 64KB and less large folio size. if
PF succeeds in getting large folios, we map large folios, otherwise we
give up as those memories can be quite unstably swapped-out, swapped-in
and madvised to be DONTNEED.

too many compactions will increase power consumption and decrease UI
response.

Thanks
Barry


From irogers at google.com  Mon Dec  4 20:25:20 2023
From: irogers at google.com (Ian Rogers)
Date: Mon, 4 Dec 2023 20:25:20 -0800
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com>
References: <20231204182330.654255-1-irogers@google.com> <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
 <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com>
Message-ID: <CAP-5=fUBGLPdFn4EfwoAamQ=5nX3LOM1v8LZk2ExEDckm+6fhw@mail.gmail.com>

On Mon, Dec 4, 2023 at 7:33?PM Namhyung Kim <namhyung at kernel.org> wrote:
>
> Hello,
>
> On Mon, Dec 4, 2023 at 2:45?PM Ilkka Koskinen
> <ilkka at os.amperecomputing.com> wrote:
> >
> >
> >
> > On Mon, 4 Dec 2023, Ian Rogers wrote:
> > > A metric is default by having "Default" within its groups. The default
> > > metricgroup name needn't be set and this can result in segv in
> > > default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
> > > that assume it has a value when there is a Default metric group. To
> > > avoid the segv initialize the value to "".
> > >
> > > Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
> > > Signed-off-by: Ian Rogers <irogers at google.com>
> >
> > Thanks! I was going to look for the bug but got pulled to other
> > tasks. The patch looks good to me and I tested it successfully on
> > AmpereOne.
> >
> >    Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
>
> Looks like it needs to go through perf-tools for v6.7.
> Ian, do you think this one is enough?

>From a user's pov the json fix is nicer as otherwise perf stat output
for the relevant metrics lacks a heading on the left. This fix is
smaller. I'm easy about which to take :-)

Thanks,
Ian

> Thanks,
> Namhyung


From nicolinc at nvidia.com  Mon Dec  4 20:28:23 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 20:28:23 -0800
Subject: [PATCH v2 15/19] iommu/arm-smmu-v3: Add a global static IDENTITY
 domain
In-Reply-To: <15-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <15-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6m54yS2rpk65kE@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:22PM -0400, Jason Gunthorpe wrote:
> @@ -2592,13 +2578,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
>  			arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
>  						      NULL);
>  		break;
> -	case ARM_SMMU_DOMAIN_BYPASS:
> -		arm_smmu_make_bypass_ste(&target);
> -		arm_smmu_install_ste_for_dev(master, &target);
> -		if (master->cd_table.cdtab)
> -			arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
> -						      NULL);
> -		break;
>  	}
>  
>  	arm_smmu_enable_ats(master, smmu_domain);
> @@ -2614,6 +2593,60 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
>  	return ret;
>  }
>  
> +static int arm_smmu_attach_dev_ste(struct device *dev,
> +				   struct arm_smmu_ste *ste)
> +{
> +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> +
> +	if (arm_smmu_master_sva_enabled(master))
> +		return -EBUSY;
> +
> +	/*
> +	 * Do not allow any ASID to be changed while are working on the STE,
> +	 * otherwise we could miss invalidations.
> +	 */
> +	mutex_lock(&arm_smmu_asid_lock);
> +
> +	/*
> +	 * The SMMU does not support enabling ATS with bypass/abort. When the
> +	 * STE is in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests
> +	 * and Translated transactions are denied as though ATS is disabled for
> +	 * the stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
> +	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
> +	 */
> +	arm_smmu_detach_dev(master);
> +
> +	arm_smmu_install_ste_for_dev(master, ste);
> +	mutex_unlock(&arm_smmu_asid_lock);
> +
> +	/*
> +	 * This has to be done after removing the master from the
> +	 * arm_smmu_domain->devices to avoid races updating the same context
> +	 * descriptor from arm_smmu_share_asid().
> +	 */
> +	if (master->cd_table.cdtab)
> +		arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);
 
This arm_smmu_write_ctx_desc was previously within the asid lock
protection, yet now it's moved out of that?


From nicolinc at nvidia.com  Mon Dec  4 20:40:52 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 20:40:52 -0800
Subject: [PATCH v2 19/19] iommu/arm-smmu-v3: Convert to
 domain_alloc_paging()
In-Reply-To: <19-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <19-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6p1AFRiGaiZMb+@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:26PM -0400, Jason Gunthorpe wrote:
> Now that the BLOCKED and IDENTITY behaviors are managed with their own
> domains change to the domain_alloc_paging() op.
> 
> For now SVA remains using the old interface, eventually it will get its
> own op that can pass in the device and mm_struct which will let us have a
> sane lifetime for the mmu_notifier.
> 
> Call arm_smmu_domain_finalise() early if dev is available.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nicolinc at nvidia.com  Mon Dec  4 20:42:15 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 20:42:15 -0800
Subject: [PATCH v2 18/19] iommu/arm-smmu-v3: Pass arm_smmu_domain and
 arm_smmu_device to finalize
In-Reply-To: <18-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <18-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6qJ4hLBkIIyaMi@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:25PM -0400, Jason Gunthorpe wrote:
> Instead of putting container_of() casts in the internals, use the proper
> type in this call chain. This makes it easier to check that the two global
> static domains are not leaking into call chains they should not.
> 
> Passing the smmu avoids the only caller from having to set it and unset it
> in the error path.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nicolinc at nvidia.com  Mon Dec  4 20:47:25 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Mon, 4 Dec 2023 20:47:25 -0800
Subject: [PATCH v2 14/19] iommu/arm-smmu-v3: Remove
 arm_smmu_master->domain
In-Reply-To: <14-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <14-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <ZW6rXddeJ9Z3VU/7@Asurada-Nvidia>

On Mon, Nov 13, 2023 at 01:53:21PM -0400, Jason Gunthorpe wrote:
> Introducing global statics which are of type struct iommu_domain, not
> struct arm_smmu_domain makes it difficult to retain
> arm_smmu_master->domain, as it can no longer point to an IDENTITY or
> BLOCKED domain.
> 
> The only place that uses the value is arm_smmu_detach_dev(). Change things
> to work like other drivers and call iommu_get_domain_for_dev() to obtain
> the current domain.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>

The new version on the github looks good to me.

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From r-gunasekaran at ti.com  Mon Dec  4 21:12:16 2023
From: r-gunasekaran at ti.com (Ravi Gunasekaran)
Date: Tue, 5 Dec 2023 10:42:16 +0530
Subject: [PATCH v13 3/5] PCI: j721e: Add per platform maximum lane
 settings
In-Reply-To: <20231128054402.2155183-4-s-vadapalli@ti.com>
References: <20231128054402.2155183-1-s-vadapalli@ti.com>
 <20231128054402.2155183-4-s-vadapalli@ti.com>
Message-ID: <bcafa1d8-1e19-6599-f5b2-16be3671bd19@ti.com>



On 11/28/23 11:14 AM, Siddharth Vadapalli wrote:
> From: Matt Ranostay <mranostay at ti.com>
> 
> Various platforms have different maximum amount of lanes that can be
> selected. Add max_lanes to struct j721e_pcie to allow for detection of this
> which is needed to calculate the needed bitmask size for the possible lane
> count.
> 
> Signed-off-by: Matt Ranostay <mranostay at ti.com>
> Signed-off-by: Achal Verma <a-verma1 at ti.com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> ---
>  drivers/pci/controller/cadence/pci-j721e.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index 2c87e7728a65..63c758b14314 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -47,8 +47,6 @@ enum link_status {
>  
>  #define GENERATION_SEL_MASK		GENMASK(1, 0)
>  
> -#define MAX_LANES			2
> -
>  struct j721e_pcie {
>  	struct cdns_pcie	*cdns_pcie;
>  	struct clk		*refclk;
> @@ -71,6 +69,7 @@ struct j721e_pcie_data {
>  	unsigned int		quirk_disable_flr:1;
>  	u32			linkdown_irq_regfield;
>  	unsigned int		byte_access_allowed:1;
> +	unsigned int		max_lanes;
>  };
>  
>  static inline u32 j721e_pcie_user_readl(struct j721e_pcie *pcie, u32 offset)
> @@ -290,11 +289,13 @@ static const struct j721e_pcie_data j721e_pcie_rc_data = {
>  	.quirk_retrain_flag = true,
>  	.byte_access_allowed = false,
>  	.linkdown_irq_regfield = LINK_DOWN,
> +	.max_lanes = 2,
>  };
>  
>  static const struct j721e_pcie_data j721e_pcie_ep_data = {
>  	.mode = PCI_MODE_EP,
>  	.linkdown_irq_regfield = LINK_DOWN,
> +	.max_lanes = 2,
>  };
>  
>  static const struct j721e_pcie_data j7200_pcie_rc_data = {
> @@ -302,23 +303,27 @@ static const struct j721e_pcie_data j7200_pcie_rc_data = {
>  	.quirk_detect_quiet_flag = true,
>  	.linkdown_irq_regfield = J7200_LINK_DOWN,
>  	.byte_access_allowed = true,
> +	.max_lanes = 2,
>  };
>  
>  static const struct j721e_pcie_data j7200_pcie_ep_data = {
>  	.mode = PCI_MODE_EP,
>  	.quirk_detect_quiet_flag = true,
>  	.quirk_disable_flr = true,
> +	.max_lanes = 2,
>  };
>  
>  static const struct j721e_pcie_data am64_pcie_rc_data = {
>  	.mode = PCI_MODE_RC,
>  	.linkdown_irq_regfield = J7200_LINK_DOWN,
>  	.byte_access_allowed = true,
> +	.max_lanes = 1,
>  };
>  
>  static const struct j721e_pcie_data am64_pcie_ep_data = {
>  	.mode = PCI_MODE_EP,
>  	.linkdown_irq_regfield = J7200_LINK_DOWN,
> +	.max_lanes = 1,
>  };
>  
>  static const struct of_device_id of_j721e_pcie_match[] = {
> @@ -432,8 +437,10 @@ static int j721e_pcie_probe(struct platform_device *pdev)
>  	pcie->user_cfg_base = base;
>  
>  	ret = of_property_read_u32(node, "num-lanes", &num_lanes);
> -	if (ret || num_lanes > MAX_LANES)
> +	if (ret || num_lanes > data->max_lanes) {
> +		dev_warn(dev, "num-lanes property not provided or invalid, setting num-lanes to 1\n");
>  		num_lanes = 1;
> +	}
>  	pcie->num_lanes = num_lanes;
>  
>  	if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(48)))

Reviewed-by: Ravi Gunasekaran <r-gunasekaran at ti.com>

-- 
Regards,
Ravi


From anshuman.khandual at arm.com  Mon Dec  4 21:20:19 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Tue, 5 Dec 2023 10:50:19 +0530
Subject: [PATCH V2 6/7] coresight: stm: Move ACPI support from AMBA driver
 to platform driver
In-Reply-To: <7825dcd4-94e1-7a5f-b388-90e748dfc47f@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-7-anshuman.khandual@arm.com>
 <0adc3a16-0fc4-2a25-cd48-4667881b9490@arm.com>
 <e53cec31-9452-4c2a-a3a1-b6ef33be8e22@arm.com>
 <7825dcd4-94e1-7a5f-b388-90e748dfc47f@arm.com>
Message-ID: <81cad3a6-a080-424c-ad0b-0f08c4fe51a2@arm.com>



On 12/4/23 18:47, James Clark wrote:
> 
> 
> On 04/12/2023 11:50, Anshuman Khandual wrote:
>>
>>
>> On 12/4/23 15:53, James Clark wrote:
>>>
>>>
>>> On 01/12/2023 06:20, Anshuman Khandual wrote:
>>>> Add support for the stm devices in the platform driver, which can then be
>>>> used on ACPI based platforms. This change would now allow runtime power
>>>> management for ACPI based systems. The driver would try to enable the APB
>>>> clock if available.
>>>>
>>>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>>>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>>>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>>>> Cc: Mike Leach <mike.leach at linaro.org>
>>>> Cc: James Clark <james.clark at arm.com>
>>>> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
>>>> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
>>>> Cc: linux-acpi at vger.kernel.org
>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>> Cc: linux-kernel at vger.kernel.org
>>>> Cc: coresight at lists.linaro.org
>>>> Cc: linux-stm32 at st-md-mailman.stormreply.com
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>>> ---
>>> [...]
>>>>  
>>>> -module_amba_driver(stm_driver);
>>>> +static int stm_platform_probe(struct platform_device *pdev)
>>>> +{
>>>> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> +	int ret = 0;
>>>> +
>>>> +	pm_runtime_get_noresume(&pdev->dev);
>>>> +	pm_runtime_set_active(&pdev->dev);
>>>> +	pm_runtime_enable(&pdev->dev);
>>>> +
>>>> +	ret = __stm_probe(&pdev->dev, res, NULL);
>>>
>>> Very minor nit, but this used to print this:
>>>
>>>   coresight stm0: STM500 initialized
>>>
>>> And now it prints this:
>>>
>>>   coresight stm0: (null) initialized
>>>
>>> (null) kind of makes it look a little bit like something has gone wrong.
>>> Maybe we could just put "initialised" if you don't have a string from ACPI?
>>
>> __stm_probe() gets called from both AMBA and platform driver paths. Even though
>> a NULL check inside dev_info(..."%s initialized\n",...) could be added, but how
>> to differentiate it from a scenario when coresight_get_uci_data() returns NULL ?
> 
> Sudeep's suggestion seems ok, just add a hard coded string instead of
> the NULL. And keep the coresight_get_uci_data() the same.

Something like this works ?

diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index 3387ebc9d8ab..2b6834c4cac6 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -906,7 +906,7 @@ static int __stm_probe(struct device *dev, struct resource *res, void *dev_caps)
        pm_runtime_put(dev);
 
        dev_info(&drvdata->csdev->dev, "%s initialized\n",
-                (char *)dev_caps);
+                dev_caps ? (char *)dev_caps: "STM");
        return 0;
 
 cs_unregister:



From adrian.hunter at intel.com  Mon Dec  4 21:36:27 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Tue, 5 Dec 2023 07:36:27 +0200
Subject: [PATCH RFC 2/3] perf/x86/intel/pt: Add support for pause_resume()
In-Reply-To: <07c9b3be-676a-f7f8-d1d2-94ce3abcb61b@arm.com>
References: <20231123121851.10826-1-adrian.hunter@intel.com>
 <20231123121851.10826-3-adrian.hunter@intel.com>
 <c63808b2-2049-da18-f0af-5dff2bc87cd2@arm.com>
 <20231129105836.GF30650@noisy.programming.kicks-ass.net>
 <842ce784-fbd2-4667-a5f7-aaa10a1108dc@intel.com>
 <20231129122320.GH30650@noisy.programming.kicks-ass.net>
 <07c9b3be-676a-f7f8-d1d2-94ce3abcb61b@arm.com>
Message-ID: <d60c3bed-2280-4305-948a-cbb63674060b@intel.com>

On 30/11/23 12:07, James Clark wrote:
> 
> 
> On 29/11/2023 12:23, Peter Zijlstra wrote:
>> On Wed, Nov 29, 2023 at 01:15:43PM +0200, Adrian Hunter wrote:
>>> On 29/11/23 12:58, Peter Zijlstra wrote:
>>>> On Wed, Nov 29, 2023 at 09:53:39AM +0000, James Clark wrote:
>>>>> On 23/11/2023 12:18, Adrian Hunter wrote:
>>>>
>>>>>> +static void pt_event_pause_resume(struct perf_event *event)
>>>>>> +{
>>>>>> +	if (event->aux_paused)
>>>>>> +		pt_config_stop(event);
>>>>>> +	else if (!event->hw.state)
>>>>>> +		pt_config_start(event);
>>>>>> +}
>>>>>
>>>>> It seems like having a single pause/resume callback rather than separate
>>>>> pause and resume ones pushes some of the event state management into the
>>>>> individual drivers and would be prone to code duplication and divergent
>>>>> behavior.
>>>>>
>>>>> Would it be possible to move the conditions from here into the core code
>>>>> and call separate functions instead?
>>>>>
>>>>>> +
>>>>>>  static void pt_event_start(struct perf_event *event, int mode)
>>>>>>  {
>>>>>>  	struct hw_perf_event *hwc = &event->hw;
>>>>>> @@ -1798,6 +1809,7 @@ static __init int pt_init(void)
>>>>>>  	pt_pmu.pmu.del			 = pt_event_del;
>>>>>>  	pt_pmu.pmu.start		 = pt_event_start;
>>>>>>  	pt_pmu.pmu.stop			 = pt_event_stop;
>>>>>> +	pt_pmu.pmu.pause_resume		 = pt_event_pause_resume;
>>>>>
>>>>> The general idea seems ok to me. Is there a reason to not use the
>>>>> existing start() stop() callbacks, rather than adding a new one?
>>>>>
>>>>> I assume it's intended to be something like an optimisation where you
>>>>> can turn it on and off without having to do the full setup, teardown and
>>>>> emit an AUX record because you know the process being traced never gets
>>>>> switched out?
>>>>
>>>> So the actual scheduling uses ->add() / ->del(), the ->start() /
>>>> ->stop() methods are something that can be used after ->add() and before
>>>> ->del() to 'temporarily' pause things.
>>>>
>>>> Pretty much exactly what is required here I think. We currently use this
>>>> for PMI throttling and adaptive frequency stuff, but there is no reason
>>>> it could not also be used for this.
>>>>
>>>> As is, we don't track the paused state across ->del() / ->add(), but
>>>> perhaps that can be fixed. We can easily add more PERF_EF_ / PERF_HES_
>>>> bits to manage things.
>>>>
>>>>
>>>
>>> I am not sure stop / start play nice with NMI's from other events e.g.
>>>
>>> PMC NMI wants to pause or resume AUX but what if AUX event is currently
>>> being processed in ->stop() or ->start()?  Or maybe that can't happen?
>>
>> I think that can happen, and pt_event_stop() can actually handle some of
>> that, while your pause_resume() thing, which uses pt_config_stop() does
>> not.
>>
>> But yes, I think that if you add pt_event_{stop,start}() calls from
>> *other* events their PMI, then you get to deal with more 'fun'.
>>
>> Something like:
>>
>>   perf_addr_filters_adjust()
>>     __perf_addr_filters_adjust()
>>       perf_event_stop()
>>         __perf_event_stop()
>> 	  event->pmu->stop()
>> 	  <NMI>
>> 	    ...
>> 	    perf_event_overflow()
>> 	      pt_event->pmu->stop()
>> 	  </NMI>
>> 	  event->pmu->start() // whoopsie!
>>
>> Should now be possible.
>>
>> I think what you want to do is rename pt->handle_nmi into pt->stop_count
>> and make it a counter, then ->stop() increments it, and ->start()
>> decrements it and everybody ensures the thing doesn't get restart while
>> !0 etc..
>>
>> I suspect you need to guard the generic part of this feature with a new
>> PERF_PMU_CAP_ flag and then have the coresight/etc. people opt-in once
>> they've audited things.
>>
>> James, does that work for you?
>>
> 
> Yep I think that would work.
> 
> If I understand it with the stop_count counter, to be able to support
> the new CAP, every device would basically have to implement a similar
> counter?
> 
> Would it be possible to do that reference counting on the outside of
> start() and stop() in the core code? So that a device only ever sees one
> call to start and one call to stop and doesn't need to do any extra
> tracking?

stop_counter does not seem right for pauses and resumes because they
should not accumulate.  We want:

	pause	stop
	pause
	resume	start
	resume

not:

	pause	stop
	pause
	resume
	resume	start

Also stop_counter has issues like:

	stop_counter 0 -> 1
	<NMI>
		stop_counter 1 -> 0
		start()
	</NMI>
	stop()	<- stop_counter is now out of sync

or:

	stop_counter 1 -> 0
	<NMI>
		stop_counter 0 -> 1
		stop()
	</NMI>
	start()	<- stop_counter is now out of sync

Also Intel PT implementation uses low-level start / stop
for pause / resume, which can be made not to conflict with
regular start / stop because they only toggle TRACEEN bit.


From lkp at intel.com  Mon Dec  4 21:53:09 2023
From: lkp at intel.com (kernel test robot)
Date: Tue, 5 Dec 2023 13:53:09 +0800
Subject: [PATCH net-next] net: stmmac: qcom-ethqos: Add sysfs nodes for
 qcom ethqos
In-Reply-To: <20231204084854.31543-1-quic_snehshah@quicinc.com>
References: <20231204084854.31543-1-quic_snehshah@quicinc.com>
Message-ID: <202312051347.L3L2pNLv-lkp@intel.com>

Hi Sneh,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Sneh-Shah/net-stmmac-qcom-ethqos-Add-sysfs-nodes-for-qcom-ethqos/20231204-165232
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231204084854.31543-1-quic_snehshah%40quicinc.com
patch subject: [PATCH net-next] net: stmmac: qcom-ethqos: Add sysfs nodes for qcom ethqos
config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20231205/202312051347.L3L2pNLv-lkp at intel.com/config)
compiler: alpha-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231205/202312051347.L3L2pNLv-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312051347.L3L2pNLv-lkp at intel.com/

All warnings (new ones prefixed by >>):

   drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c: In function 'gvm_queue_mapping_store':
>> drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c:770:13: warning: variable 'prio' set but not used [-Wunused-but-set-variable]
     770 |         u32 prio;
         |             ^~~~


vim +/prio +770 drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c

   762	
   763	static ssize_t gvm_queue_mapping_store(struct device *dev,
   764					       struct device_attribute *attr,
   765					       const char *user_buf, size_t size)
   766	{
   767		struct net_device *netdev = to_net_dev(dev);
   768		struct stmmac_priv *priv;
   769		struct qcom_ethqos *ethqos;
 > 770		u32 prio;
   771		s8 input = 0;
   772	
   773		if (!netdev) {
   774			pr_err("netdev is NULL\n");
   775			return -EINVAL;
   776		}
   777	
   778		priv = netdev_priv(netdev);
   779		if (!priv) {
   780			pr_err("priv is NULL\n");
   781			return -EINVAL;
   782		}
   783	
   784		ethqos = priv->plat->bsp_priv;
   785		if (!ethqos) {
   786			pr_err("ethqos is NULL\n");
   787			return -EINVAL;
   788		}
   789	
   790		if (kstrtos8(user_buf, 0, &input)) {
   791			pr_err("Error in reading option from user\n");
   792			return -EINVAL;
   793		}
   794	
   795		if (input == ethqos->gvm_queue)
   796			pr_err("No effect as duplicate input\n");
   797	
   798		ethqos->gvm_queue = input;
   799		prio  = 1 << input;
   800	
   801		return size;
   802	}
   803	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From quic_mnaresh at quicinc.com  Mon Dec  4 21:58:51 2023
From: quic_mnaresh at quicinc.com (Naresh Maramaina)
Date: Tue, 5 Dec 2023 11:28:51 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
Message-ID: <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>

On 12/5/2023 12:30 AM, Bart Van Assche wrote:
> On 12/4/23 06:30, Maramaina Naresh wrote:
>> +??? u32??? (*config_qos_vote)(struct ufs_hba *hba);
> 
> Please remove the above callback since this patch series does not
> introduce any instances of this callback.
> 

Sure Bart, i will take care of this comment in next patch set.
If some SoC vendor have a different qos vote value then this callback 
can be added in future.

>> +
>> +??? /* This capability allows the host controller driver to use the 
>> PM QoS
>> +???? * feature.
>> +???? */
>> +??? UFSHCD_CAP_PM_QOS??????????????? = 1 << 13,
>> ? };
> 
> Why does it depend on the host driver whether or not PM QoS is
> enabled? Why isn't it enabled unconditionally?

For some platform vendors power KPI might be more important than random 
io KPI. Hence this flag is disabled by default and can be enabled based 
on platform requirement.

> 
>> + * @pm_qos_req: PM QoS request handle
>> + * @pm_qos_init: flag to check if pm qos init completed
>> ?? */
> 
> Documentation for pm_qos_init is missing.
> 
Sorry, i didn't get your comment, i have already added documentation for 
@pm_qos_init, @pm_qos_req variable as above. Do you want me to add this 
information some where else as well?



>> ? struct ufs_hba {
>> ????? void __iomem *mmio_base;
>> @@ -1076,6 +1089,9 @@ struct ufs_hba {
>> ????? struct ufs_hw_queue *uhq;
>> ????? struct ufs_hw_queue *dev_cmd_queue;
>> ????? struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
>> +??? struct pm_qos_request pm_qos_req;
>> +??? bool pm_qos_init;
>> +??? u32 qos_vote;
> 
> Please rename "pm_qos_init" into "pm_qos_initialized".
> 

Sure Bart, i will take care of this comment in next patch set.

> Thanks,
> 
> Bart.
> 

Thanks,
Naresh.


From quic_sibis at quicinc.com  Mon Dec  4 22:23:59 2023
From: quic_sibis at quicinc.com (Sibi Sankar)
Date: Tue, 5 Dec 2023 11:53:59 +0530
Subject: [PATCH V5 1/5] dt-bindings: arm: cpus: Add qcom,oryon compatible
In-Reply-To: <20231205062403.14848-1-quic_sibis@quicinc.com>
References: <20231205062403.14848-1-quic_sibis@quicinc.com>
Message-ID: <20231205062403.14848-2-quic_sibis@quicinc.com>

From: Rajendra Nayak <quic_rjendra at quicinc.com>

Oryon is the custom ARM CPU core implementation used in Qualcomm's
X1E80100 SoC, document it.

Signed-off-by: Rajendra Nayak <quic_rjendra at quicinc.com>
Co-developed-by: Sibi Sankar <quic_sibis at quicinc.com>
Signed-off-by: Sibi Sankar <quic_sibis at quicinc.com>
---
 Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index ffd526363fda..cc5a21b47e26 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -198,6 +198,7 @@ properties:
       - qcom,kryo660
       - qcom,kryo685
       - qcom,kryo780
+      - qcom,oryon
       - qcom,scorpion
 
   enable-method:
-- 
2.17.1



From quic_sibis at quicinc.com  Mon Dec  4 22:23:58 2023
From: quic_sibis at quicinc.com (Sibi Sankar)
Date: Tue, 5 Dec 2023 11:53:58 +0530
Subject: [PATCH V5 0/5] dts: qcom: Introduce X1E80100 platforms device tree
Message-ID: <20231205062403.14848-1-quic_sibis@quicinc.com>

This series adds the initial (clocks, pinctrl, rpmhpd, regulator, interconnect,
CPU, SoC and board compatibles) device tree support to boot to shell on the
Qualcomm X1E80100 platform, aka Snapdragon X Elite.

Our v1 post of the patchsets adding support for Snapdragon X Elite SoC had
the part number sc8380xp which is now updated to the new part number x1e80100
based on the new branding scheme and refers to the exact same SoC.

V5:
* Rename gcc config to CLK_X1E80100_GCC [Krzysztof/Abel/Bryan].
* Pickup Rbs.

V4:
* Have separate cluster_pd for each cluster. [Konrad]

V3:
* Add more detail to the commit msg describing Oryon. [Rob]
* Add smem compatible and tcsr_hw nodes. [Abel]
* Re-name l2-cache, remove hyphen in reserved region. [Konrad]
* Describe certain secure gpios as unused. [Konrad]
* Pickup Rbs.

v2:
* Update the part number from sc8380xp to x1e80100.
* Fixup ordering in the SoC/board bindings. [Krzysztof]
* Add pdc node and add wakeup tlmm parent. [Rajendra]
* Add cpu/cluster idle states. [Bjorn]
* Document reserved gpios. [Konrad]
* Remove L1 and add missing props to L2. [Konrad]
* Remove region suffix. [Konrad]
* Append digits to gcc node. [Konrad]
* Add ICC_TAGS instead of leaving it unspecified. [Konrad]
* Remove double space. [Konrad]
* Leave the size index of memory node untouched. [Konrad]
* Override the serial uart with "qcom,geni-debug-uart" in the board files. [Rajendra]
* Add additional details to patch 5 commit message. [Konrad/Krzysztof]

Dependencies:
clks: https://lore.kernel.org/lkml/20231117092737.28362-1-quic_sibis at quicinc.com/
llcc: https://lore.kernel.org/lkml/20231117095315.2087-1-quic_sibis at quicinc.com/
misc-bindings: https://lore.kernel.org/lkml/20231117105635.343-1-quic_sibis at quicinc.com/

Release Link: https://www.qualcomm.com/news/releases/2023/10/qualcomm-unleashes-snapdragon-x-elite--the-ai-super-charged-plat


Abel Vesa (1):
  arm64: dts: qcom: x1e80100: Add Compute Reference Device

Rajendra Nayak (4):
  dt-bindings: arm: cpus: Add qcom,oryon compatible
  dt-bindings: arm: qcom: Document X1E80100 SoC and boards
  arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts
  arm64: defconfig: Enable X1E80100 SoC base configs

 .../devicetree/bindings/arm/cpus.yaml         |    1 +
 .../devicetree/bindings/arm/qcom.yaml         |    8 +
 arch/arm64/boot/dts/qcom/Makefile             |    2 +
 arch/arm64/boot/dts/qcom/x1e80100-crd.dts     |  426 ++
 arch/arm64/boot/dts/qcom/x1e80100-qcp.dts     |  401 ++
 arch/arm64/boot/dts/qcom/x1e80100.dtsi        | 3527 +++++++++++++++++
 arch/arm64/configs/defconfig                  |    3 +
 7 files changed, 4368 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/x1e80100-crd.dts
 create mode 100644 arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/x1e80100.dtsi

-- 
2.17.1



From quic_sibis at quicinc.com  Mon Dec  4 22:24:00 2023
From: quic_sibis at quicinc.com (Sibi Sankar)
Date: Tue, 5 Dec 2023 11:54:00 +0530
Subject: [PATCH V5 2/5] dt-bindings: arm: qcom: Document X1E80100 SoC and boards
In-Reply-To: <20231205062403.14848-1-quic_sibis@quicinc.com>
References: <20231205062403.14848-1-quic_sibis@quicinc.com>
Message-ID: <20231205062403.14848-3-quic_sibis@quicinc.com>

From: Rajendra Nayak <quic_rjendra at quicinc.com>

Document the X1E80100 SoC binding and also the boards using it.
Also document the new board id qcp (Qualcomm Compute Platform).

Signed-off-by: Rajendra Nayak <quic_rjendra at quicinc.com>
Co-developed-by: Sibi Sankar <quic_sibis at quicinc.com>
Signed-off-by: Sibi Sankar <quic_sibis at quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index e09745a802fd..f62ce85fc9b9 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -87,6 +87,7 @@ description: |
         sm8350
         sm8450
         sm8550
+        x1e80100
 
   The 'board' element must be one of the following strings:
 
@@ -96,6 +97,7 @@ description: |
         idp
         liquid
         mtp
+        qcp
         qrd
         rb2
         ride
@@ -1038,6 +1040,12 @@ properties:
               - qcom,sm8550-qrd
           - const: qcom,sm8550
 
+      - items:
+          - enum:
+              - qcom,x1e80100-crd
+              - qcom,x1e80100-qcp
+          - const: qcom,x1e80100
+
   # Board compatibles go above
 
   qcom,msm-id:
-- 
2.17.1



From quic_sibis at quicinc.com  Mon Dec  4 22:24:02 2023
From: quic_sibis at quicinc.com (Sibi Sankar)
Date: Tue, 5 Dec 2023 11:54:02 +0530
Subject: [PATCH V5 4/5] arm64: dts: qcom: x1e80100: Add Compute Reference Device
In-Reply-To: <20231205062403.14848-1-quic_sibis@quicinc.com>
References: <20231205062403.14848-1-quic_sibis@quicinc.com>
Message-ID: <20231205062403.14848-5-quic_sibis@quicinc.com>

From: Abel Vesa <abel.vesa at linaro.org>

Add basic support for X1E80100 CRD board dts, which allows it to boot
to a shell.

Signed-off-by: Abel Vesa <abel.vesa at linaro.org>
Signed-off-by: Rajendra Nayak <quic_rjendra at quicinc.com>
Co-developed-by: Sibi Sankar <quic_sibis at quicinc.com>
Signed-off-by: Sibi Sankar <quic_sibis at quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
 arch/arm64/boot/dts/qcom/Makefile         |   1 +
 arch/arm64/boot/dts/qcom/x1e80100-crd.dts | 426 ++++++++++++++++++++++
 2 files changed, 427 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/x1e80100-crd.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index af59897c21f0..9bced8d74dc0 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -234,4 +234,5 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sm8450-sony-xperia-nagara-pdx223.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8450-sony-xperia-nagara-pdx224.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8550-qrd.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-crd.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-qcp.dtb
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
new file mode 100644
index 000000000000..c209ae59c6b5
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
@@ -0,0 +1,426 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "x1e80100.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. X1E80100 CRD";
+	compatible = "qcom,x1e80100-crd", "qcom,x1e80100";
+
+	aliases {
+		serial0 = &uart21;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	vph_pwr: vph-pwr-regulator {
+		compatible = "regulator-fixed";
+
+		regulator-name = "vph_pwr";
+		regulator-min-microvolt = <3700000>;
+		regulator-max-microvolt = <3700000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vreg_edp_3p3: regulator-edp-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_EDP_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&edp_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+&apps_rsc {
+	regulators-0 {
+		compatible = "qcom,pm8550-rpmh-regulators";
+		qcom,pmic-id = "b";
+
+		vdd-bob1-supply = <&vph_pwr>;
+		vdd-bob2-supply = <&vph_pwr>;
+		vdd-l1-supply = <&vreg_s4c_1p8>;
+		vdd-l2-l13-l14-supply = <&vreg_bob1>;
+		vdd-l4-supply = <&vreg_s4c_1p8>;
+		vdd-l5-l16-supply = <&vreg_bob1>;
+		vdd-l6-l7-supply = <&vreg_bob2>;
+		vdd-l8-l9-supply = <&vreg_bob1>;
+		vdd-l10-supply = <&vreg_s4c_1p8>;
+		vdd-l12-supply = <&vreg_s5j_1p2>;
+		vdd-l15-supply = <&vreg_s4c_1p8>;
+		vdd-l17-supply = <&vreg_bob2>;
+
+		vreg_bob1: bob1 {
+			regulator-name = "vreg_bob1";
+			regulator-min-microvolt = <3008000>;
+			regulator-max-microvolt = <3960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_bob2: bob2 {
+			regulator-name = "vreg_bob2";
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1b_1p8: ldo1 {
+			regulator-name = "vreg_l1b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2b_3p0: ldo2 {
+			regulator-name = "vreg_l2b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l4b_1p8: ldo4 {
+			regulator-name = "vreg_l4b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5b_3p0: ldo5 {
+			regulator-name = "vreg_l5b_3p0";
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6b_1p8: ldo6 {
+			regulator-name = "vreg_l6b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7b_2p8: ldo7 {
+			regulator-name = "vreg_l7b_2p8";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8b_3p0: ldo8 {
+			regulator-name = "vreg_l8b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9b_2p9: ldo9 {
+			regulator-name = "vreg_l9b_2p9";
+			regulator-min-microvolt = <2960000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l10b_1p8: ldo10 {
+			regulator-name = "vreg_l10b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l12b_1p2: ldo12 {
+			regulator-name = "vreg_l12b_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l13b_3p0: ldo13 {
+			regulator-name = "vreg_l13b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l14b_3p0: ldo14 {
+			regulator-name = "vreg_l14b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l15b_1p8: ldo15 {
+			regulator-name = "vreg_l15b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l16b_2p9: ldo16 {
+			regulator-name = "vreg_l16b_2p9";
+			regulator-min-microvolt = <2912000>;
+			regulator-max-microvolt = <2912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l17b_2p5: ldo17 {
+			regulator-name = "vreg_l17b_2p5";
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <2504000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-1 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vdd-l1-supply = <&vreg_s5j_1p2>;
+		vdd-l2-supply = <&vreg_s1f_0p7>;
+		vdd-l3-supply = <&vreg_s1f_0p7>;
+		vdd-s4-supply = <&vph_pwr>;
+
+		vreg_s4c_1p8: smps4 {
+			regulator-name = "vreg_s4c_1p8";
+			regulator-min-microvolt = <1856000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1c_1p2: ldo1 {
+			regulator-name = "vreg_l1c_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2c_0p8: ldo2 {
+			regulator-name = "vreg_l2c_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3c_0p8: ldo3 {
+			regulator-name = "vreg_l3c_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-2 {
+		compatible = "qcom,pmc8380-rpmh-regulators";
+		qcom,pmic-id = "d";
+
+		vdd-l1-supply = <&vreg_s1f_0p7>;
+		vdd-l2-supply = <&vreg_s1f_0p7>;
+		vdd-l3-supply = <&vreg_s4c_1p8>;
+		vdd-s1-supply = <&vph_pwr>;
+
+		vreg_l1d_0p8: ldo1 {
+			regulator-name = "vreg_l1d_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2d_0p9: ldo2 {
+			regulator-name = "vreg_l2d_0p9";
+			regulator-min-microvolt = <912000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3d_1p8: ldo3 {
+			regulator-name = "vreg_l3d_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-3 {
+		compatible = "qcom,pmc8380-rpmh-regulators";
+		qcom,pmic-id = "e";
+
+		vdd-l2-supply = <&vreg_s1f_0p7>;
+		vdd-l3-supply = <&vreg_s5j_1p2>;
+
+		vreg_l2e_0p8: ldo2 {
+			regulator-name = "vreg_l2e_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3e_1p2: ldo3 {
+			regulator-name = "vreg_l3e_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-4 {
+		compatible = "qcom,pmc8380-rpmh-regulators";
+		qcom,pmic-id = "f";
+
+		vdd-l1-supply = <&vreg_s5j_1p2>;
+		vdd-l2-supply = <&vreg_s5j_1p2>;
+		vdd-l3-supply = <&vreg_s5j_1p2>;
+		vdd-s1-supply = <&vph_pwr>;
+
+		vreg_s1f_0p7: smps1 {
+			regulator-name = "vreg_s1f_0p7";
+			regulator-min-microvolt = <700000>;
+			regulator-max-microvolt = <1100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1f_1p0: ldo1 {
+			regulator-name = "vreg_l1f_1p0";
+			regulator-min-microvolt = <1024000>;
+			regulator-max-microvolt = <1024000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2f_1p0: ldo2 {
+			regulator-name = "vreg_l2f_1p0";
+			regulator-min-microvolt = <1024000>;
+			regulator-max-microvolt = <1024000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3f_1p0: ldo3 {
+			regulator-name = "vreg_l3f_1p0";
+			regulator-min-microvolt = <1024000>;
+			regulator-max-microvolt = <1024000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-6 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "i";
+
+		vdd-l1-supply = <&vreg_s4c_1p8>;
+		vdd-l2-supply = <&vreg_s5j_1p2>;
+		vdd-l3-supply = <&vreg_s1f_0p7>;
+		vdd-s1-supply = <&vph_pwr>;
+		vdd-s2-supply = <&vph_pwr>;
+
+		vreg_s1i_0p9: smps1 {
+			regulator-name = "vreg_s1i_0p9";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s2i_1p0: smps2 {
+			regulator-name = "vreg_s2i_1p0";
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1i_1p8: ldo1 {
+			regulator-name = "vreg_l1i_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2i_1p2: ldo2 {
+			regulator-name = "vreg_l2i_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3i_0p8: ldo3 {
+			regulator-name = "vreg_l3i_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-7 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "j";
+
+		vdd-l1-supply = <&vreg_s1f_0p7>;
+		vdd-l2-supply = <&vreg_s5j_1p2>;
+		vdd-l3-supply = <&vreg_s1f_0p7>;
+		vdd-s5-supply = <&vph_pwr>;
+
+		vreg_s5j_1p2: smps5 {
+			regulator-name = "vreg_s5j_1p2";
+			regulator-min-microvolt = <1256000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1j_0p8: ldo1 {
+			regulator-name = "vreg_l1j_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2j_1p2: ldo2 {
+			regulator-name = "vreg_l2j_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3j_0p8: ldo3 {
+			regulator-name = "vreg_l3j_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+};
+
+&qupv3_2 {
+	status = "okay";
+};
+
+&tlmm {
+	gpio-reserved-ranges = <34 2>, /* Unused */
+			       <44 4>, /* SPI (TPM) */
+			       <238 1>; /* UFS Reset */
+
+	edp_reg_en: edp-reg-en-state {
+		pins = "gpio70";
+		function = "gpio";
+		drive-strength = <16>;
+		bias-disable;
+	};
+};
+
+&uart21 {
+	compatible = "qcom,geni-debug-uart";
+	status = "okay";
+};
-- 
2.17.1



From quic_sibis at quicinc.com  Mon Dec  4 22:24:03 2023
From: quic_sibis at quicinc.com (Sibi Sankar)
Date: Tue, 5 Dec 2023 11:54:03 +0530
Subject: [PATCH V5 5/5] arm64: defconfig: Enable X1E80100 SoC base configs
In-Reply-To: <20231205062403.14848-1-quic_sibis@quicinc.com>
References: <20231205062403.14848-1-quic_sibis@quicinc.com>
Message-ID: <20231205062403.14848-6-quic_sibis@quicinc.com>

From: Rajendra Nayak <quic_rjendra at quicinc.com>

Enable GCC, Pinctrl and Interconnect configs for Qualcomm's X1E80100 SoC
which is required to boot X1E80100 QCP/CRD boards to a console shell. The
configs are required to be marked as builtin and not modules due to the
console driver dependencies.

Signed-off-by: Rajendra Nayak <quic_rjendra at quicinc.com>
Co-developed-by: Sibi Sankar <quic_sibis at quicinc.com>
Signed-off-by: Sibi Sankar <quic_sibis at quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---

v5:
* Rename gcc config to CLK_X1E80100_GCC [Krzysztof/Abel/Bryan].

 arch/arm64/configs/defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 3e7832c64708..ffaa9f9fa10f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -616,6 +616,7 @@ CONFIG_PINCTRL_SM8450_LPASS_LPI=m
 CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
 CONFIG_PINCTRL_SM8550=y
 CONFIG_PINCTRL_SM8550_LPASS_LPI=m
+CONFIG_PINCTRL_X1E80100=y
 CONFIG_PINCTRL_LPASS_LPI=m
 CONFIG_GPIO_AGGREGATOR=m
 CONFIG_GPIO_ALTERA=m
@@ -1220,6 +1221,7 @@ CONFIG_COMMON_CLK_MT8192_SCP_ADSP=y
 CONFIG_COMMON_CLK_MT8192_VDECSYS=y
 CONFIG_COMMON_CLK_MT8192_VENCSYS=y
 CONFIG_COMMON_CLK_QCOM=y
+CONFIG_CLK_X1E80100_GCC=y
 CONFIG_QCOM_A53PLL=y
 CONFIG_QCOM_CLK_APCS_MSM8916=y
 CONFIG_QCOM_CLK_APCC_MSM8996=y
@@ -1528,6 +1530,7 @@ CONFIG_INTERCONNECT_QCOM_SM8250=m
 CONFIG_INTERCONNECT_QCOM_SM8350=m
 CONFIG_INTERCONNECT_QCOM_SM8450=y
 CONFIG_INTERCONNECT_QCOM_SM8550=y
+CONFIG_INTERCONNECT_QCOM_X1E80100=y
 CONFIG_COUNTER=m
 CONFIG_RZ_MTU3_CNT=m
 CONFIG_HTE=y
-- 
2.17.1



From arnd at arndb.de  Mon Dec  4 22:34:40 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 05 Dec 2023 07:34:40 +0100
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error: instruction
 variant requires ARMv6 or later
In-Reply-To: <20231204223317.GA2053629@dev-arch.thelio-3990X>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
 <20231204181304.GA2043538@dev-arch.thelio-3990X>
 <20231204223317.GA2053629@dev-arch.thelio-3990X>
Message-ID: <36a25113-731c-4b28-a695-f3fbb0996d6e@app.fastmail.com>

On Mon, Dec 4, 2023, at 23:33, Nathan Chancellor wrote:
> On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote:
> 
>> I am still investigating into what (if anything) can be done to resolve
>> this on the kernel side. We could potentially revert commit
>> ddc72c9659b5 ("kbuild: clang: do not use CROSS_COMPILE for target
>> triple") but I am not sure that will save us from that change, as
>> tuxmake's CROSS_COMPILE=arm-linux-gnueabihf will cause us to have an
>> armv7 CPU even though we may not be building for armv7.
>
> Okay, this is a pretty awful situation the more I look into it :(
>
> The arm64 compat vDSO build is easy enough to fix because we require use
> of the integrated assembler, which means we can add '-mcpu=generic' (the
> default in LLVM for those files based on my debugging) to those files
> and be done with it:
>
> diff --git a/arch/arm64/kernel/vdso32/Makefile 
> b/arch/arm64/kernel/vdso32/Makefile
> index 1f911a76c5af..5f5cb722cfc2 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -9,6 +9,10 @@ include $(srctree)/lib/vdso/Makefile
>  ifeq ($(CONFIG_CC_IS_CLANG), y)
>  CC_COMPAT ?= $(CC)
>  CC_COMPAT += --target=arm-linux-gnueabi
> +# Some distributions (such as Debian) change the default CPU for the
> +# arm-linux-gnueabi target triple, which can break the build. 
> Explicitly set
> +# the CPU to generic, which is the default for Linux in LLVM.
> +CC_COMPAT += -mcpu=generic
>  else
>  CC_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc
>  endif

I'm still trying to follow what is actually going on. I
see that we pass

VDSO_CAFLAGS += -march=armv8-a

which is meant to tell the compiler that we want it to
use ARMv8 compatible instructions. Is the problem that
clang ignores this flag, or do we not pass it correctly?

I would have expected -march=armv8-a to be better than
-mcpu=generic here, as it allows the compiler to use
a wider set of instructions that is still guaranteed to
be available on everything it will run on.

> Sylvestre, I strongly believe you should consider reverting that change
> or give us some compiler flag that allows us to fallback to upstream
> LLVM's default CPU selection logic. I think that hardcoding Debian's
> architecture defintions based on the target triple into the compiler
> could cause issues for other projects as well. For example,
> '--target=arm-linux-gnueabi -march=armv7-a' won't actually target ARMv7:
>
>   $ echo 'int main(void) { asm("dsb"); return 0; }' | \
>         clang --target=arm-linux-gnueabi -march=armv7-a \
>         -x c -c -o /dev/null -v -
>   ...
>    "/usr/bin/clang-17" -cc1 -triple armv7-unknown-linux-gnueabi ...
>   ...
>
> vs.
>
>   $ echo 'int main(void) { asm("dsb"); return 0; }' | \
>         clang --target=arm-linux-gnueabi -march=armv7-a \
>         -x c -c -o /dev/null -v -
>   ...
>   "<prefix>/bin/clang-18" -cc1 -triple armv5e-unknown-linux-gnueabi ...
>   ...

Right, the kernel definitely relies on -march= taking
precedence over the default CPU, the same way that we
tell the compiler to pick a non-default endianess or ABI.

    Arnd


From umang.jain at ideasonboard.com  Mon Dec  4 22:39:41 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Tue, 5 Dec 2023 12:09:41 +0530
Subject: [PATCH v2 0/5] staging: vc04_services: Drop custom logging
In-Reply-To: <42cd081f-bee9-49ff-b8f6-17ec58f43058@gmx.net>
References: <20231128201926.489269-1-umang.jain@ideasonboard.com>
 <42cd081f-bee9-49ff-b8f6-17ec58f43058@gmx.net>
Message-ID: <a87efe94-b3fb-a360-dfcd-db2097b89d6f@ideasonboard.com>

Hi Stefan,

On 11/29/23 4:56 AM, Stefan Wahren wrote:
> Hi Umang,
>
> Am 28.11.23 um 21:19 schrieb Umang Jain:
>> This series also removes the vchiq_log_* macro and makes use of 
>> dev_dbg()
>> directly.
> sorry, i didn't had the time to follow the logging discussion, but the
> following commits:
>
> staging: vc04: Convert vchiq_log_error() to use dynamic debug
> staging: vc04: Convert vchiq_log_warning() to use dynamic debug
> staging: vc04: Convert(and rename) vchiq_log_info() to use dynamic debug
>
> changed the logging behavior. I don't think it's intended to move
> everything to dev_dbg.
>
> I would expected the following mapping:
> vchiq_log_error -> dev_err
> vchiq_log_warning -> dev_warn

For this I agree,
> vchiq_log_info -> dev_info

However, I think vchiq_log_info and vchiq_log_debug should be moved to 
dev_dbg.

Otherwise, I think they'll spew a ton of information to dmesg by default.
>>
>> Patch 1/5 is fix. It prevents passing NULL to one of vchiq_log_error().
>> The function there in question, does not have any users as of
>> now. However, it is going to be used by the vc-sm-cma and bcm2835-isp
>> drivers (posted on list for review [1]). There was discussion on v1,
>> whether I should drop and add the function later, however, didn't
>> conclude.
>>
>> Patch 2/5 removes vchiq_log_error() macro
>> Patch 3/5 removes vchiq_log_warning() macro
>> Patch 4/5 removes vchiq_log_trace() macro
>> Patch 5/5 removes vchiq_log_debug() macro
>>
>> This completes the following TODO item:
>>
>> ```
>> * Cleanup logging mechanism
>>
>> The driver should probably be using the standard kernel logging 
>> mechanisms
>> such as dev_info, dev_dbg, and friends.
>> ```
>>
>> [1]: 
>> https://lore.kernel.org/linux-media/20231109210309.638594-1-umang.jain at ideasonboard.com/
>>
>> Changes in v2:
>> - Separate out one fixup patch from v1 (Patch 1/9)and send separately
>> - Drop usage of log_type() and log_category() helpers. Directly use
>> ?? dev_dbg() as suggested by Greg KH.
>> - Drop __func__ annotation from all logs. Dynamic debug has 'f'
>> ?? decorator flag which can be used instead of manual __func__
>> - Reword commit messages.
>>
>> Umang Jain (5):
>> ?? staging: vc04_services: Do not pass NULL to vchiq_log_error()
>> ?? staging: vc04_services: Drop vchiq_log_error() in favour of dev_dbg
>> ?? staging: vc04_services: Drop vchiq_log_warning() in favour of dev_dbg
>> ?? staging: vc04_services: Drop vchiq_log_trace() in favour of dev_dbg
>> ?? staging: vc04_services: Drop vchiq_log_debug() in favour of dev_dbg
>>
>> ? drivers/staging/vc04_services/interface/TODO? |?? 5 -
>> ? .../interface/vchiq_arm/vchiq_arm.c?????????? | 176 ++++----
>> ? .../interface/vchiq_arm/vchiq_connected.c???? |?? 8 +-
>> ? .../interface/vchiq_arm/vchiq_connected.h???? |?? 4 +-
>> ? .../interface/vchiq_arm/vchiq_core.c????????? | 402 +++++++++---------
>> ? .../interface/vchiq_arm/vchiq_core.h????????? |? 38 --
>> ? .../interface/vchiq_arm/vchiq_dev.c?????????? |? 92 ++--
>> ? 7 files changed, 315 insertions(+), 410 deletions(-)
>>
>



From miquel.raynal at bootlin.com  Mon Dec  4 22:51:10 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Tue, 5 Dec 2023 07:51:10 +0100
Subject: [PATCH net-next v2 0/9] net*: Convert to platform remove
 callback returning void
In-Reply-To: <cover.1701713943.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701713943.git.u.kleine-koenig@pengutronix.de>
Message-ID: <20231205075110.795b88d2@xps-13>

Hi Uwe,

u.kleine-koenig at pengutronix.de wrote on Mon,  4 Dec 2023 19:30:40 +0100:

> Hello,
> 
> (implicit) v1 of this series can be found at
> https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koenig at pengutronix.de.
> Changes since then:
> 
>  - Dropped patch #1 as Alex objected. Patch #1 (was #2 before) now
>    converts ipa to remove_new() and introduces an error message in the
>    error path that failed before.
> 
>  - Rebased to today's next
> 
>  - Add the tags received in the previous round.
> 
> Uwe Kleine-K?nig (9):
>   net: ipa: Convert to platform remove callback returning void
>   net: fjes: Convert to platform remove callback returning void
>   net: pcs: rzn1-miic: Convert to platform remove callback returning
>     void
>   net: sfp: Convert to platform remove callback returning void
>   net: wan/fsl_ucc_hdlc: Convert to platform remove callback returning
>     void
>   net: wan/ixp4xx_hss: Convert to platform remove callback returning
>     void
>   net: wwan: qcom_bam_dmux: Convert to platform remove callback
>     returning void
>   ieee802154: fakelb: Convert to platform remove callback returning void
>   ieee802154: hwsim: Convert to platform remove callback returning void

FYI, I plan on taking patches 8 and 9 through wpan-next.

Thanks,
Miqu?l


From mripard at kernel.org  Mon Dec  4 22:57:58 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Tue, 5 Dec 2023 07:57:58 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231204182245.33683-2-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
Message-ID: <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>

On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
> including register space and interrupts. Clocks, reset, and power domain
> information is SoC specific.
> 
> Signed-off-by: Andrew Davis <afd at ti.com>
> ---
>  .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
>  1 file changed, 63 insertions(+), 6 deletions(-)

I think it would be best to have a separate file for this, img,sgx.yaml
maybe?

Maxime

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/14ae433e/attachment.sig>

From arnd at arndb.de  Mon Dec  4 22:59:32 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 05 Dec 2023 07:59:32 +0100
Subject: [PATCH] ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support
In-Reply-To: <20231204-drop-11mpcore-v1-1-f96cd3938cf1@linaro.org>
References: <20231204-drop-11mpcore-v1-1-f96cd3938cf1@linaro.org>
Message-ID: <93cc5193-aa1b-4df8-8d00-c3149c33b7e7@app.fastmail.com>

On Mon, Dec 4, 2023, at 23:36, Linus Walleij wrote:
> This ARM11 SMP configuration was one of the first SMP configurations
> the ARM kernel supported, but it has the downside of odd DMA handling,
> odd cache tagging, and often (as of recent) completely broken cache
> handling on the ARM RealView PB11MPCore test chips. To boot the
> platform it was necessary to completely disable the cache.
> When it comes to the EB 11MPCore it is unclear if this ever worked.
>
> These reference designs are now the only ARMv6K SMP platforms.
>
> As only reference designs of purely academic interest remain, and
> since the special-cased DMA and PMU code is hard to maintain and
> doesn't really work, it is not really worth our time.
>
> Delete the ARM11MPCore support along with:
>
> - The special DMA quirk CONFIG_DMA_CACHE_RWFO that is only used
>   on ARMv6K SMP, and we are the last ARMV6K system leaving the
>   building and the cache handling is awkward, so good-bye.
>
> - The special PMU handling that was only used by ARM11MPCore.
>
> The following is left behind:
>
> - TIMER_OF_DECLARE(arm_twd_11mp, "arm,arm11mp-twd-timer", ...)
>   in arch/arm/kernel/smp_twd.c, this is still in use by Marvell MMP3
>   arch/arm/boot/dts/marvell/mmp3.dtsi
>
> - IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", ...)
>   in drivers/irqchip/irq-gic.c, this is still in use by Marvell MMP3
>   arch/arm/boot/dts/marvell/mmp3.dtsi
>
> These are unfortunate but will need to be kept around for
> compatibility. New Marvell-specific compatibles should however probably
> be added.
>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

This looks good to me (one small issue below), thanks for the cleanup!

Reviewed-by: Arnd Bergmann <arnd at arndb.de>

>  arch/arm/kernel/perf_event_v6.c            | 34 ------------------------------
>  arch/arm/mach-versatile/Kconfig            | 17 ---------------
>  arch/arm/mach-versatile/platsmp-realview.c |  2 --
>  arch/arm/mach-versatile/realview.c         |  1 -
>  arch/arm/mm/Kconfig                        | 18 ----------------
>  arch/arm/mm/cache-v6.S                     | 31 ---------------------------
>  6 files changed, 103 deletions(-)

Russell, this touches both mach-versatile and core Arm
code, any preference for how we should merge it (provided
you are happy with the changes)?

I'm fine with the combined change going through your
tree or mine, or splitting it up.

--- a/arch/arm/mach-versatile/platsmp-realview.c
+++ b/arch/arm/mach-versatile/platsmp-realview.c
@@ -18,7 +18,6 @@
 #define REALVIEW_SYS_FLAGSSET_OFFSET	0x30
 
 static const struct of_device_id realview_scu_match[] = {
-	{ .compatible = "arm,arm11mp-scu", },
 	{ .compatible = "arm,cortex-a9-scu", },
 	{ .compatible = "arm,cortex-a5-scu", },
 	{ }

I see that the arm,arm11mp-scu device is provided by
arm-realview-eb-mp.dtsi, which in turn gets included
by both arm-realview-eb-11mp.dts and arm-realview-eb-a9mp.dts,
so the Cortex-A9 dtb ends up with the wrong compatible
string at the moment.

The driver doesn't care either way, and we can easily
change the dtsi file use the Cortex-A9 compatibles
later, but I think we probably want to leave the
platsmp code to match the old string as well for
compatibility with old dtb files.

     Arnd


From krzysztof.kozlowski at linaro.org  Mon Dec  4 23:10:09 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 5 Dec 2023 08:10:09 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231204182245.33683-2-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
Message-ID: <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>

On 04/12/2023 19:22, Andrew Davis wrote:
> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
> including register space and interrupts. Clocks, reset, and power domain
> information is SoC specific.
> 
> Signed-off-by: Andrew Davis <afd at ti.com>
> ---
>  .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
>  1 file changed, 63 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> index a13298f1a1827..9f036891dad0b 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> @@ -11,11 +11,33 @@ maintainers:
>    - Frank Binns <frank.binns at imgtec.com>
>  
>  properties:
> +  $nodename:
> +    pattern: '^gpu@[a-f0-9]+$'

Why? We do not enforce it in other bindings.

> +
>    compatible:
> -    items:
> -      - enum:
> -          - ti,am62-gpu
> -      - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
> +    oneOf:
> +      - items:
> +          - enum:
> +              - ti,am62-gpu
> +          - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
> +      - items:
> +          - enum:
> +              - ti,omap3430-gpu # Rev 121
> +              - ti,omap3630-gpu # Rev 125
> +          - const: img,powervr-sgx530
> +      - items:
> +          - enum:
> +              - ingenic,jz4780-gpu # Rev 130
> +              - ti,omap4430-gpu # Rev 120
> +          - const: img,powervr-sgx540
> +      - items:
> +          - enum:
> +              - allwinner,sun6i-a31-gpu # MP2 Rev 115
> +              - ti,omap4470-gpu # MP1 Rev 112
> +              - ti,omap5432-gpu # MP2 Rev 105
> +              - ti,am5728-gpu # MP2 Rev 116
> +              - ti,am6548-gpu # MP1 Rev 117
> +          - const: img,powervr-sgx544
>  
>    reg:
>      maxItems: 1
> @@ -40,8 +62,6 @@ properties:
>  required:
>    - compatible
>    - reg
> -  - clocks
> -  - clock-names

I don't think so... How can you run without clocks?

>    - interrupts
>  
>  additionalProperties: false
> @@ -56,6 +76,43 @@ allOf:
>        properties:
>          clocks:
>            maxItems: 1
> +      required:
> +        - clocks
> +        - clock-names

You need to define the clocks for your variants or disallow them. The
original code should be fixed as well and make the clocks fixed for all
img-axe cases.



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec  4 23:19:45 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 5 Dec 2023 08:19:45 +0100
Subject: [PATCH v5 18/20] arm64: dts: exynos: google: Add initial Google
 gs101 SoC support
In-Reply-To: <CAPLW+4ki_GUAnor4sTanXFLzKrAB9JpxK98PED1fUY-MLCzUdA@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-19-peter.griffin@linaro.org>
 <CAPLW+4ki_GUAnor4sTanXFLzKrAB9JpxK98PED1fUY-MLCzUdA@mail.gmail.com>
Message-ID: <8596c2a7-b3f6-4f8c-9529-91c1d6fc5716@linaro.org>

On 02/12/2023 02:54, Sam Protsenko wrote:
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>>
>> Google gs101 SoC is ARMv8 mobile SoC found in the Pixel 6,
>> (oriole) Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
>> phones. It features:
>> * 4xA55 little cluster
>> * 2xA76 Mid cluster
>> * 2xX1 Big cluster
>>
>> This commit adds the basic device tree for gs101 (SoC).
>> Further platform support will be added over time.
>>
>> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
>> ---

...

>> +
>> +               watchdog_cl0: watchdog at 10060000 {
>> +                       compatible = "google,gs101-wdt";
>> +                       reg = <0x10060000 0x100>;
>> +                       interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH 0>;
>> +                       clocks =
>> +                         <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0_IPCLKPORT_PCLK>,
>> +                         <&ext_24_5m>;
>> +                       clock-names = "watchdog", "watchdog_src";
>> +                       samsung,syscon-phandle = <&pmu_system_controller>;
>> +                       samsung,cluster-index = <0>;
>> +                       status = "disabled";
>> +               };
> 
> Krzysztof, can you please advice which scheme is preferred right now:
> sorting by name or by address? I saw your patch for dts style doc, but
> just want to know the current state of affairs.

Use coding style, so sorting by unit address in DTSI and by
label/phandle of overrides in DTS.

Coding style was not yet applied, but I don't see any objections to it
so it is just a matter of days.

Best regards,
Krzysztof



From u.kleine-koenig at pengutronix.de  Mon Dec  4 23:39:11 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 5 Dec 2023 08:39:11 +0100
Subject: [PATCH net-next v2 0/9] net*: Convert to platform remove
 callback returning void
In-Reply-To: <20231205075110.795b88d2@xps-13>
References: <cover.1701713943.git.u.kleine-koenig@pengutronix.de>
 <20231205075110.795b88d2@xps-13>
Message-ID: <20231205073911.e6nphzhc6yjan5vu@pengutronix.de>

Hello Miquel,

On Tue, Dec 05, 2023 at 07:51:10AM +0100, Miquel Raynal wrote:
> u.kleine-koenig at pengutronix.de wrote on Mon,  4 Dec 2023 19:30:40 +0100:
> > (implicit) v1 of this series can be found at
> > https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koenig at pengutronix.de.
> > Changes since then:
> > 
> >  - Dropped patch #1 as Alex objected. Patch #1 (was #2 before) now
> >    converts ipa to remove_new() and introduces an error message in the
> >    error path that failed before.
> > 
> >  - Rebased to today's next
> > 
> >  - Add the tags received in the previous round.
> > 
> > Uwe Kleine-K?nig (9):
> >   net: ipa: Convert to platform remove callback returning void
> >   net: fjes: Convert to platform remove callback returning void
> >   net: pcs: rzn1-miic: Convert to platform remove callback returning
> >     void
> >   net: sfp: Convert to platform remove callback returning void
> >   net: wan/fsl_ucc_hdlc: Convert to platform remove callback returning
> >     void
> >   net: wan/ixp4xx_hss: Convert to platform remove callback returning
> >     void
> >   net: wwan: qcom_bam_dmux: Convert to platform remove callback
> >     returning void
> >   ieee802154: fakelb: Convert to platform remove callback returning void
> >   ieee802154: hwsim: Convert to platform remove callback returning void
> 
> FYI, I plan on taking patches 8 and 9 through wpan-next.

I forgot to mention explicitly that there are no interdependencies in
this series. So each maintainer picking up up their patches is fine.

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/15b627a3/attachment-0001.sig>

From miquel.raynal at bootlin.com  Mon Dec  4 23:50:46 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Tue, 5 Dec 2023 08:50:46 +0100
Subject: [PATCH net-next v2 0/9] net*: Convert to platform remove
 callback returning void
In-Reply-To: <20231205073911.e6nphzhc6yjan5vu@pengutronix.de>
References: <cover.1701713943.git.u.kleine-koenig@pengutronix.de>
	<20231205075110.795b88d2@xps-13>
	<20231205073911.e6nphzhc6yjan5vu@pengutronix.de>
Message-ID: <20231205085046.7307ca9b@xps-13>

Hello Uwe,

u.kleine-koenig at pengutronix.de wrote on Tue, 5 Dec 2023 08:39:11 +0100:

> Hello Miquel,
> 
> On Tue, Dec 05, 2023 at 07:51:10AM +0100, Miquel Raynal wrote:
> > u.kleine-koenig at pengutronix.de wrote on Mon,  4 Dec 2023 19:30:40 +0100:  
> > > (implicit) v1 of this series can be found at
> > > https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koenig at pengutronix.de.
> > > Changes since then:
> > > 
> > >  - Dropped patch #1 as Alex objected. Patch #1 (was #2 before) now
> > >    converts ipa to remove_new() and introduces an error message in the
> > >    error path that failed before.
> > > 
> > >  - Rebased to today's next
> > > 
> > >  - Add the tags received in the previous round.
> > > 
> > > Uwe Kleine-K?nig (9):
> > >   net: ipa: Convert to platform remove callback returning void
> > >   net: fjes: Convert to platform remove callback returning void
> > >   net: pcs: rzn1-miic: Convert to platform remove callback returning
> > >     void
> > >   net: sfp: Convert to platform remove callback returning void
> > >   net: wan/fsl_ucc_hdlc: Convert to platform remove callback returning
> > >     void
> > >   net: wan/ixp4xx_hss: Convert to platform remove callback returning
> > >     void
> > >   net: wwan: qcom_bam_dmux: Convert to platform remove callback
> > >     returning void
> > >   ieee802154: fakelb: Convert to platform remove callback returning void
> > >   ieee802154: hwsim: Convert to platform remove callback returning void  
> > 
> > FYI, I plan on taking patches 8 and 9 through wpan-next.  
> 
> I forgot to mention explicitly that there are no interdependencies in
> this series. So each maintainer picking up up their patches is fine.

Yes, no problem, it was quick to figure out.

Thanks,
Miqu?l


From andre.draszik at linaro.org  Mon Dec  4 23:52:22 2023
From: andre.draszik at linaro.org (=?ISO-8859-1?Q?Andr=E9?= Draszik)
Date: Tue, 05 Dec 2023 07:52:22 +0000
Subject: [PATCH v5 12/20] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <20231201160925.3136868-13-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
	 <20231201160925.3136868-13-peter.griffin@linaro.org>
Message-ID: <5e9c0b1c5885775a7bc32ef59cb09a2a93d4cbe1.camel@linaro.org>

Hi Pete,

On Fri, 2023-12-01 at 16:09 +0000, Peter Griffin wrote:
> cmu_top is the top level clock management unit which contains PLLs, muxes,
> dividers and gates that feed the other clock management units.
> 
> cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> APM module.
> 
> Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> Tested-by: Will McVicker <willmcvicker at google.com>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
> ?drivers/clk/samsung/Makefile??? |??? 1 +
> ?drivers/clk/samsung/clk-gs101.c | 2495 +++++++++++++++++++++++++++++++
> ?2 files changed, 2496 insertions(+)
> ?create mode 100644 drivers/clk/samsung/clk-gs101.c
> 
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index ebbeacabe88f..3056944a5a54 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos7.o
> ?obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos7885.o
> ?obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos850.o
> ?obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynosautov9.o
> +obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-gs101.o
> ?obj-$(CONFIG_S3C64XX_COMMON_CLK)	+= clk-s3c64xx.o
> ?obj-$(CONFIG_S5PV210_COMMON_CLK)	+= clk-s5pv210.o clk-s5pv210-audss.o
> ?obj-$(CONFIG_TESLA_FSD_COMMON_CLK)	+= clk-fsd.o
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> new file mode 100644
> index 000000000000..6bd233a7ab63
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -0,0 +1,2495 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + * Author: Peter Griffin <peter.griffin at linaro.org>
> + *
> + * Common Clock Framework support for GS101.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +
> +#include <dt-bindings/clock/google,gs101.h>
> +
> +#include "clk.h"
> +#include "clk-exynos-arm64.h"
> +
> +/* NOTE: Must be equal to the last clock ID increased by one */
> +#define TOP_NR_CLK	(CLK_GOUT_TPU_UART + 1)
> +#define APM_NR_CLK	(CLK_APM_PLL_DIV16_APM + 1)
> +#define MISC_NR_CLK	(CLK_GOUT_MISC_XIU_D_MISC_IPCLKPORT_ACLK + 1)
> +
> +/* ---- CMU_TOP ------------------------------------------------------------- */
> +
> [...]
> +
> +/* ---- CMU_APM ------------------------------------------------------------- */
> [..]
> +
> +/* ---- CMU_MISC ------------------------------------------------------------- */

nit - the CMU_MISC comment here is an outlier.

> [..]
> +
> +/* ---- platform_driver ----------------------------------------------------- */
> +
> [...]

Cheers,
Andre'



From tony at atomide.com  Mon Dec  4 23:56:57 2023
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 5 Dec 2023 09:56:57 +0200
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
Message-ID: <20231205075657.GN5169@atomide.com>

* Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> [231205 07:10]:
> On 04/12/2023 19:22, Andrew Davis wrote:
> > @@ -56,6 +76,43 @@ allOf:
> >        properties:
> >          clocks:
> >            maxItems: 1
> > +      required:
> > +        - clocks
> > +        - clock-names
> 
> You need to define the clocks for your variants or disallow them. The
> original code should be fixed as well and make the clocks fixed for all
> img-axe cases.

To clarify, the clocks may be optional as they can be hardwired and coming
from the interconnect target wrapper module and enabled with runtime PM.

Regards,

Tony


From xiaobo55x at gmail.com  Mon Dec  4 23:58:02 2023
From: xiaobo55x at gmail.com (Haibo Xu)
Date: Tue, 5 Dec 2023 15:58:02 +0800
Subject: [PATCH v3 9/9] KVM: riscv: selftests: Add sstc timer test
In-Reply-To: <20231204-980c95cca344f718ac6a48b6@orel>
References: <cover.1694421911.git.haibo1.xu@intel.com> <64e0637cd6f22dd7557ed44bd2242001e7830d1c.1694421911.git.haibo1.xu@intel.com>
 <20230914-d2e594e7d84503ad14036e2d@orel> <CAJve8onhY534T=Hyncjfi4GfdZ+0D2xM+jRSaYCAWCdaKxPUcQ@mail.gmail.com>
 <CAJve8omitHDpijJaLV_wHk+5LXpsBUWF8_eTD4MeWKM-807Siw@mail.gmail.com> <20231204-980c95cca344f718ac6a48b6@orel>
Message-ID: <CAJve8okwyPwY3AZcA31=aoc1tyZN7hx_5AmF0KMmn-bZ1VnyHA@mail.gmail.com>

On Mon, Dec 4, 2023 at 7:32?PM Andrew Jones <ajones at ventanamicro.com> wrote:
>
> On Mon, Dec 04, 2023 at 10:42:24AM +0800, Haibo Xu wrote:
> > On Fri, Sep 15, 2023 at 2:21?PM Haibo Xu <xiaobo55x at gmail.com> wrote:
> > >
> > > On Thu, Sep 14, 2023 at 5:52?PM Andrew Jones <ajones at ventanamicro.com> wrote:
> > > >
> > > > On Thu, Sep 14, 2023 at 09:37:03AM +0800, Haibo Xu wrote:
> > > > > Add a KVM selftests to validate the Sstc timer functionality.
> > > > > The test was ported from arm64 arch timer test.
> > > >
> > > > I just tried this test out. Running it over and over again on QEMU I see
> > > > it works sometimes, but it frequently fails with the
> > > > GUEST_ASSERT_EQ(config_iter + 1, irq_iter) assert and at least once I
> > > > also saw the __GUEST_ASSERT(xcnt >= cmp) assert.
> > > >
> > >
> > > Good catch!
> > >
> > > I can also reproduce this issue and it is a common problem for both
> > > arm64 and riscv because it also happens in a arm64 Qemu VM.
> > >
> > > It seems like a synchronization issue between host and guest shared
> > > variables. Will double check the test code.
> > >
> > > > Thanks,
> > > > drew
> >
> > Hi Andrew,
> >
> > After several rounds of regression testing, some findings:
> > 1. The intermittent failure also happened on ARM64 Qemu VM, and even
> > in the initial arch_timer commit(4959d8650e9f4).
> > 2. it didn't happen on a ARM64 HW(but a different failure occured
> > during stress test)
> > 3. The failure have a close relationship with
> > TIMER_TEST_ERR_MARGIN_US(default 100), and after increasing
> >      the macro to 300, the failure couldn't reproduced in 1000 loops
> > stress test in RISC-V Qemu VM
> >
> > So my suggestion is we can expose the TIMER_TEST_ERR_MARGIN_US
> > parameter as an arch_timer test arg parameter
> > and tune it based on a specific test environment.
> >
> > What's your opinion?
>
> The concept of "timeout for an interrupt to arrive" is always going to
> leave us exposed to random failures. Your suggestion of making the
> timeout user configurable is probably the best we can do. I would
> suggest also adding more descriptive failure text and a hint about
> trying to adjust the timeout.
>
> Or, one thing we do in kvm-unit-tests, is to reduce typical delays while
> allowing expected delays to be longer by looping over a shorter delay and
> a non-fatal check, i.e.
>
>  pass = false;
>  for (i = 0; i < 10; i++) {
>    udelay(100);
>    if (check(...)) {
>       pass = true;
>       break;
>    }
>  }
>  assert(pass);
>
> We could try that approach here too.
>
> Thanks,
> drew

Thanks for the feedback, I will send out patch set v4 soon!


From krzysztof.kozlowski at linaro.org  Tue Dec  5 00:03:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 5 Dec 2023 09:03:08 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231205075657.GN5169@atomide.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
 <20231205075657.GN5169@atomide.com>
Message-ID: <df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>

On 05/12/2023 08:56, Tony Lindgren wrote:
> * Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> [231205 07:10]:
>> On 04/12/2023 19:22, Andrew Davis wrote:
>>> @@ -56,6 +76,43 @@ allOf:
>>>        properties:
>>>          clocks:
>>>            maxItems: 1
>>> +      required:
>>> +        - clocks
>>> +        - clock-names
>>
>> You need to define the clocks for your variants or disallow them. The
>> original code should be fixed as well and make the clocks fixed for all
>> img-axe cases.
> 
> To clarify, the clocks may be optional as they can be hardwired and coming
> from the interconnect target wrapper module and enabled with runtime PM.

What does runtime PM have to do with it? If runtime PM enables clocks,
these are real signals and not optional.

The bindings is quite unspecific in that matter which is not what we
want usually. If you have implementation which does not have these
clocks exposed, then disallow them.

Just don't make it floating like it is in existing binding and how
Andrew continues for new devices.

Best regards,
Krzysztof



From andre.draszik at linaro.org  Tue Dec  5 00:09:28 2023
From: andre.draszik at linaro.org (=?ISO-8859-1?Q?Andr=E9?= Draszik)
Date: Tue, 05 Dec 2023 08:09:28 +0000
Subject: [PATCH v5 12/20] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <CAPLW+4nAwWBHkAe2Wg2b+URsgN8ienPh14L=Fu8PUxf4gxq0ow@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
	 <20231201160925.3136868-13-peter.griffin@linaro.org>
	 <CAPLW+4nAwWBHkAe2Wg2b+URsgN8ienPh14L=Fu8PUxf4gxq0ow@mail.gmail.com>
Message-ID: <860ca122a08bbce70b27d8880c621f0d12ddd2a5.camel@linaro.org>

Hi Sam,

On Fri, 2023-12-01 at 16:40 -0600, Sam Protsenko wrote:
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> > 
> > [...]
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_ACLK???????????????????? 0x20b8
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_PCLK???????????????????? 0x20bc
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SS_DBGCORE_IPCLKPORT_SS_DBGCORE_IPCLKPORT_HCLK??? 0x20c0
> 
> As I understand, all those parts like IPCLKPORT, BLK, UID (RSTNSYNC
> probably too) -- they don't really mean anything in the context of the
> driver, just noise. And if you remove those -- there won't be any
> conflicts with other names, because those bits are not the unique
> parts. Following the TRM letter for letter in this case just makes
> things extremely long without adding any value IMHO. For example, that
> name above might be:
> 
> ??? CLK_CON_GAT_GOUT_APM_SS_DBGCORE_SS_DBGCORE_HCLK
> 
> or even
> 
> ??? CLK_CON_GAT_GOUT_APM_SS_DBGCORE_HCLK
> 
> would be fine.
> 
> In clk-exynos850 driver I removed all those parts, because they make
> it pretty much impossible to read both the driver and dts. And yeah,
> because those names consequenty lead to very long string names, dts
> will be hard to read too, which is even worse. But again, that's only
> my IMHO.

The advantage of keeping the same name as in the data sheet is that then it's easy to
correlate between driver and hardware and future / other hardware.
By arbitrarily diverging from the TRM you make life much harder for yourself when you
have to look at this again in 12 months time after you've forgotten your name mangling
approach; you also make it harder for everybody to review the driver or to use the
driver as a reference in the future for other hardware, as nobody except you knows
what kind of name-mangling was applied and which register (or clock in this case) is
really meant.


Cheers,
Andre'



From tomi.valkeinen at ideasonboard.com  Tue Dec  5 00:09:31 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 05 Dec 2023 10:09:31 +0200
Subject: [PATCH 0/4] media: rkisp1: Fix IRQ related issues
Message-ID: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>

These fix a few IRQ related issues I noticed when testing i.MX8MP. These
are based on Paul's recently sent "[PATCH v4 00/11] media: rkisp1: Add
support for i.MX8MP" series, but could also be rebased on top of
mainline if needed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
Tomi Valkeinen (4):
      media: rkisp1: Store IRQ lines
      media: rkisp1: Fix IRQ handler return values
      media: rkisp1: Fix IRQ handling due to shared interrupts
      media: rkisp1: Fix IRQ disable race issue

 .../platform/rockchip/rkisp1/rkisp1-capture.c      |  3 ++
 .../media/platform/rockchip/rkisp1/rkisp1-common.h | 13 ++++-
 .../media/platform/rockchip/rkisp1/rkisp1-csi.c    | 17 ++++++-
 .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 58 ++++++++++++++++++----
 .../media/platform/rockchip/rkisp1/rkisp1-isp.c    | 23 +++++++--
 5 files changed, 100 insertions(+), 14 deletions(-)
---
base-commit: dd19f89b915c203d49e3b23ca02446d4fb05d955
change-id: 20231205-rkisp-irq-fix-e123a8a6732f

Best regards,
-- 
Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>



From tomi.valkeinen at ideasonboard.com  Tue Dec  5 00:09:33 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 05 Dec 2023 10:09:33 +0200
Subject: [PATCH 2/4] media: rkisp1: Fix IRQ handler return values
In-Reply-To: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
Message-ID: <20231205-rkisp-irq-fix-v1-2-f4045c74ba45@ideasonboard.com>

The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an
irqreturn_t value, but rkisp1_isr() ignores those values and always
returns IRQ_HANDLED.

Fix this by collecting the return values, and returning IRQ_HANDLED or
IRQ_NONE as appropriate.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index 76f93614b4cf..1d60f4b8bd09 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -445,17 +445,27 @@ static int rkisp1_entities_register(struct rkisp1_device *rkisp1)
 
 static irqreturn_t rkisp1_isr(int irq, void *ctx)
 {
+	irqreturn_t ret;
+
 	/*
 	 * Call rkisp1_capture_isr() first to handle the frame that
 	 * potentially completed using the current frame_sequence number before
 	 * it is potentially incremented by rkisp1_isp_isr() in the vertical
 	 * sync.
 	 */
-	rkisp1_capture_isr(irq, ctx);
-	rkisp1_isp_isr(irq, ctx);
-	rkisp1_csi_isr(irq, ctx);
 
-	return IRQ_HANDLED;
+	ret = IRQ_NONE;
+
+	if (rkisp1_capture_isr(irq, ctx) == IRQ_HANDLED)
+		ret = IRQ_HANDLED;
+
+	if (rkisp1_isp_isr(irq, ctx) == IRQ_HANDLED)
+		ret = IRQ_HANDLED;
+
+	if (rkisp1_csi_isr(irq, ctx) == IRQ_HANDLED)
+		ret = IRQ_HANDLED;
+
+	return ret;
 }
 
 static const char * const px30_isp_clks[] = {

-- 
2.34.1



From tomi.valkeinen at ideasonboard.com  Tue Dec  5 00:09:35 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 05 Dec 2023 10:09:35 +0200
Subject: [PATCH 4/4] media: rkisp1: Fix IRQ disable race issue
In-Reply-To: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
Message-ID: <20231205-rkisp-irq-fix-v1-4-f4045c74ba45@ideasonboard.com>

In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
interrupts and then apparently assumes that the interrupt handler won't
be running, and proceeds in the stop procedure. This is not the case, as
the interrupt handler can already be running, which would lead to the
ISP being disabled while the interrupt handler handling a captured
frame.

It is not clear to me if this problem causes a real issue, but shutting
down the ISP while an interrupt handler is running sounds rather bad.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c | 14 +++++++++++++-
 drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 20 +++++++++++++++++---
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
index f6b54654b435..f0cef766fc0c 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
@@ -125,8 +125,20 @@ static void rkisp1_csi_disable(struct rkisp1_csi *csi)
 	struct rkisp1_device *rkisp1 = csi->rkisp1;
 	u32 val;
 
-	/* Mask and clear interrupts. */
+	/* Mask MIPI interrupts. */
 	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_IMSC, 0);
+
+	/* Flush posted writes */
+	rkisp1_read(rkisp1, RKISP1_CIF_MIPI_IMSC);
+
+	/*
+	 * Wait until the IRQ handler has ended. The IRQ handler may get called
+	 * even after this, but it will return immediately as the MIPI
+	 * interrupts have been masked.
+	 */
+	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MIPI]);
+
+	/* Clear MIPI interrupt status */
 	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_ICR, ~0);
 
 	val = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_CTRL);
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
index d6b8786661ad..a6dd497c884c 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
@@ -364,11 +364,25 @@ static void rkisp1_isp_stop(struct rkisp1_isp *isp)
 	 * ISP(mi) stop in mi frame end -> Stop ISP(mipi) ->
 	 * Stop ISP(isp) ->wait for ISP isp off
 	 */
-	/* stop and clear MI and ISP interrupts */
-	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
-	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
 
+	/* Mask MI and ISP interrupts */
+	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
 	rkisp1_write(rkisp1, RKISP1_CIF_MI_IMSC, 0);
+
+	/* Flush posted writes */
+	rkisp1_read(rkisp1, RKISP1_CIF_MI_IMSC);
+
+	/*
+	 * Wait until the IRQ handler has ended. The IRQ handler may get called
+	 * even after this, but it will return immediately as the MI and ISP
+	 * interrupts have been masked.
+	 */
+	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_ISP]);
+	if (rkisp1->irqs[RKISP1_IRQ_ISP] != rkisp1->irqs[RKISP1_IRQ_MI])
+		synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MI]);
+
+	/* Clear MI and ISP interrupt status */
+	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
 	rkisp1_write(rkisp1, RKISP1_CIF_MI_ICR, ~0);
 
 	/* stop ISP */

-- 
2.34.1



From tomi.valkeinen at ideasonboard.com  Tue Dec  5 00:09:32 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 05 Dec 2023 10:09:32 +0200
Subject: [PATCH 1/4] media: rkisp1: Store IRQ lines
In-Reply-To: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
Message-ID: <20231205-rkisp-irq-fix-v1-1-f4045c74ba45@ideasonboard.com>

Store the IRQ lines used by the driver for easy access. These are needed
in future patches which fix IRQ race issues.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 .../media/platform/rockchip/rkisp1/rkisp1-common.h    | 11 ++++++++++-
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c   | 19 ++++++++++++++-----
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
index 960ab89c659b..ec28907d978e 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
@@ -62,6 +62,14 @@ struct regmap;
 						 RKISP1_CIF_ISP_EXP_END |	\
 						 RKISP1_CIF_ISP_HIST_MEASURE_RDY)
 
+/* IRQ lines */
+enum rkisp1_irq_line {
+	RKISP1_IRQ_ISP = 0,
+	RKISP1_IRQ_MI,
+	RKISP1_IRQ_MIPI,
+	RKISP1_NUM_IRQS,
+};
+
 /* enum for the resizer pads */
 enum rkisp1_rsz_pad {
 	RKISP1_RSZ_PAD_SINK,
@@ -437,7 +445,6 @@ struct rkisp1_debug {
  * struct rkisp1_device - ISP platform device
  *
  * @base_addr:	   base register address
- * @irq:	   the irq number
  * @dev:	   a pointer to the struct device
  * @clk_size:	   number of clocks
  * @clks:	   array of clocks
@@ -457,6 +464,7 @@ struct rkisp1_debug {
  * @stream_lock:   serializes {start/stop}_streaming callbacks between the capture devices.
  * @debug:	   debug params to be exposed on debugfs
  * @info:	   version-specific ISP information
+ * @irqs:          IRQ line numbers
  */
 struct rkisp1_device {
 	void __iomem *base_addr;
@@ -479,6 +487,7 @@ struct rkisp1_device {
 	struct mutex stream_lock; /* serialize {start/stop}_streaming cb between capture devices */
 	struct rkisp1_debug debug;
 	const struct rkisp1_info *info;
+	int irqs[RKISP1_NUM_IRQS];
 };
 
 /*
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index 2b9886fd0800..76f93614b4cf 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -115,6 +115,7 @@
 struct rkisp1_isr_data {
 	const char *name;
 	irqreturn_t (*isr)(int irq, void *ctx);
+	u32 line_mask;
 };
 
 /* ----------------------------------------------------------------------------
@@ -465,9 +466,9 @@ static const char * const px30_isp_clks[] = {
 };
 
 static const struct rkisp1_isr_data px30_isp_isrs[] = {
-	{ "isp", rkisp1_isp_isr },
-	{ "mi", rkisp1_capture_isr },
-	{ "mipi", rkisp1_csi_isr },
+	{ "isp", rkisp1_isp_isr, BIT(RKISP1_IRQ_ISP) },
+	{ "mi", rkisp1_capture_isr, BIT(RKISP1_IRQ_MI) },
+	{ "mipi", rkisp1_csi_isr, BIT(RKISP1_IRQ_MIPI) },
 };
 
 static const struct rkisp1_info px30_isp_info = {
@@ -488,7 +489,7 @@ static const char * const rk3399_isp_clks[] = {
 };
 
 static const struct rkisp1_isr_data rk3399_isp_isrs[] = {
-	{ NULL, rkisp1_isr },
+	{ NULL, rkisp1_isr, BIT(RKISP1_IRQ_ISP) | BIT(RKISP1_IRQ_MI) | BIT(RKISP1_IRQ_MIPI) },
 };
 
 static const struct rkisp1_info rk3399_isp_info = {
@@ -509,7 +510,7 @@ static const char * const imx8mp_isp_clks[] = {
 };
 
 static const struct rkisp1_isr_data imx8mp_isp_isrs[] = {
-	{ NULL, rkisp1_isr },
+	{ NULL, rkisp1_isr, BIT(RKISP1_IRQ_ISP) | BIT(RKISP1_IRQ_MI) | BIT(RKISP1_IRQ_MIPI) },
 };
 
 static const struct rkisp1_info imx8mp_isp_info = {
@@ -566,6 +567,9 @@ static int rkisp1_probe(struct platform_device *pdev)
 	if (IS_ERR(rkisp1->base_addr))
 		return PTR_ERR(rkisp1->base_addr);
 
+	for (unsigned int il = 0; il < RKISP1_NUM_IRQS; ++il)
+		rkisp1->irqs[il] = -1;
+
 	for (i = 0; i < info->isr_size; i++) {
 		irq = info->isrs[i].name
 		    ? platform_get_irq_byname(pdev, info->isrs[i].name)
@@ -573,6 +577,11 @@ static int rkisp1_probe(struct platform_device *pdev)
 		if (irq < 0)
 			return irq;
 
+		for (unsigned int il = 0; il < RKISP1_NUM_IRQS; ++il) {
+			if (info->isrs[i].line_mask & BIT(il))
+				rkisp1->irqs[il] = irq;
+		}
+
 		ret = devm_request_irq(dev, irq, info->isrs[i].isr, IRQF_SHARED,
 				       dev_driver_string(dev), dev);
 		if (ret) {

-- 
2.34.1



From tomi.valkeinen at ideasonboard.com  Tue Dec  5 00:09:34 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 05 Dec 2023 10:09:34 +0200
Subject: [PATCH 3/4] media: rkisp1: Fix IRQ handling due to shared
 interrupts
In-Reply-To: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
Message-ID: <20231205-rkisp-irq-fix-v1-3-f4045c74ba45@ideasonboard.com>

The driver requests the interrupts as IRQF_SHARED, so the interrupt
handlers can be called at any time. If such a call happens while the ISP
is powered down, the SoC will hang as the driver tries to access the
ISP registers.

Fix this by adding a new field, 'irqs_enabled', which is used to bail
out from the interrupt handler when the ISP is not operational.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 .../media/platform/rockchip/rkisp1/rkisp1-capture.c |  3 +++
 .../media/platform/rockchip/rkisp1/rkisp1-common.h  |  2 ++
 drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c |  3 +++
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 21 +++++++++++++++++++++
 drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c |  3 +++
 5 files changed, 32 insertions(+)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index b50b044d22af..e92067897f28 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -779,6 +779,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
 	unsigned int i;
 	u32 status;
 
+	if (!rkisp1->irqs_enabled)
+		return IRQ_NONE;
+
 	status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
 	if (!status)
 		return IRQ_NONE;
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
index ec28907d978e..7f97fdf6e24c 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
@@ -465,6 +465,7 @@ struct rkisp1_debug {
  * @debug:	   debug params to be exposed on debugfs
  * @info:	   version-specific ISP information
  * @irqs:          IRQ line numbers
+ * @irqs_enabled:  the hardware is enabled and can cause interrupts
  */
 struct rkisp1_device {
 	void __iomem *base_addr;
@@ -488,6 +489,7 @@ struct rkisp1_device {
 	struct rkisp1_debug debug;
 	const struct rkisp1_info *info;
 	int irqs[RKISP1_NUM_IRQS];
+	bool irqs_enabled;
 };
 
 /*
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
index 47f4353a1784..f6b54654b435 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
@@ -184,6 +184,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
 	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
 	u32 val, status;
 
+	if (!rkisp1->irqs_enabled)
+		return IRQ_NONE;
+
 	status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
 	if (!status)
 		return IRQ_NONE;
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index 1d60f4b8bd09..fbe03f7864e3 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -306,6 +306,23 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
 {
 	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
 
+	rkisp1->irqs_enabled = false;
+	/* Make sure the IRQ handler will see the above */
+	mb();
+
+	/*
+	 * Wait until any running IRQ handler has returned. The IRQ handler
+	 * may get called even after this (as it's a shared interrupt line)
+	 * but the 'irqs_enabled' flag will make the handler return immediately.
+	 */
+	for (unsigned int i = 0; i < RKISP1_NUM_IRQS; ++i) {
+		if (rkisp1->irqs[i] == -1)
+			continue;
+
+		if (i == 0 || rkisp1->irqs[i - 1] != rkisp1->irqs[i])
+			synchronize_irq(rkisp1->irqs[i]);
+	}
+
 	clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
 	return pinctrl_pm_select_sleep_state(dev);
 }
@@ -322,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
 	if (ret)
 		return ret;
 
+	rkisp1->irqs_enabled = true;
+	/* Make sure the IRQ handler will see the above */
+	mb();
+
 	return 0;
 }
 
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
index dafbfd230542..d6b8786661ad 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
@@ -1082,6 +1082,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
 	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
 	u32 status, isp_err;
 
+	if (!rkisp1->irqs_enabled)
+		return IRQ_NONE;
+
 	status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
 	if (!status)
 		return IRQ_NONE;

-- 
2.34.1



From tony at atomide.com  Tue Dec  5 00:10:31 2023
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 5 Dec 2023 10:10:31 +0200
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
 <20231205075657.GN5169@atomide.com>
 <df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>
Message-ID: <20231205081031.GO5169@atomide.com>

* Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> [231205 08:03]:
> What does runtime PM have to do with it? If runtime PM enables clocks,
> these are real signals and not optional.

Runtime PM propagates to the parent device.

Regards,

Tony


From krzysztof.kozlowski at linaro.org  Tue Dec  5 00:16:28 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 5 Dec 2023 09:16:28 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231205081031.GO5169@atomide.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
 <20231205075657.GN5169@atomide.com>
 <df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>
 <20231205081031.GO5169@atomide.com>
Message-ID: <efcd64f4-00d2-4671-af3a-e27764f70e8d@linaro.org>

On 05/12/2023 09:10, Tony Lindgren wrote:
> * Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> [231205 08:03]:
>> What does runtime PM have to do with it? If runtime PM enables clocks,
>> these are real signals and not optional.
> 
> Runtime PM propagates to the parent device.

Then it is not really relevant to the hardware talk here, unless you put
this device clocks in parent node, but then it's just wrong hardware
description.

Best regards,
Krzysztof



From hns at goldelico.com  Tue Dec  5 00:17:55 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Tue, 5 Dec 2023 09:17:55 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231204182245.33683-2-afd@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
Message-ID: <CFF198DA-5C42-425E-86F4-759629489ECB@goldelico.com>

Hi Andrew,

> Am 04.12.2023 um 19:22 schrieb Andrew Davis <afd at ti.com>:
> 
> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> multiple vendors.

Great and thanks for the new attempt to get at least the Device Tree side
upstream. Really appreciated!

> Describe how the SGX GPU is integrated in these SoC,
> including register space and interrupts.

> Clocks, reset, and power domain
> information is SoC specific.

Indeed. This makes it understandable why you did not directly
take our scheme from the openpvrsgx project.

> 
> Signed-off-by: Andrew Davis <afd at ti.com>
> ---
> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
> 1 file changed, 63 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> index a13298f1a1827..9f036891dad0b 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> @@ -11,11 +11,33 @@ maintainers:
>   - Frank Binns <frank.binns at imgtec.com>
> 
> properties:
> +  $nodename:
> +    pattern: '^gpu@[a-f0-9]+$'
> +
>   compatible:
> -    items:
> -      - enum:
> -          - ti,am62-gpu
> -      - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
> +    oneOf:
> +      - items:
> +          - enum:
> +              - ti,am62-gpu
> +          - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
> +      - items:
> +          - enum:
> +              - ti,omap3430-gpu # Rev 121
> +              - ti,omap3630-gpu # Rev 125

Is the "Rev 121" and "Rev 125" a property of the SoC integration (clock/reset/power
hookup etc.) or of the integrated SGX core?

In my understanding the Revs are different variants of the SGX core (errata
fixes, instruction set, pipeline size etc.). And therefore the current driver code
has to be configured by some macros to handle such cases.

So the Rev should IMHO be part of the next line:

> +          - const: img,powervr-sgx530

+          - enum:
+              - img,powervr-sgx530-121
+              - img,powervr-sgx530-125

We have a similar definition in the openpvrsgx code.
Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";

(I don't mind about the powervr- prefix).

This would allow a generic and universal sgx driver (loaded through just matching
"img,sgx530") to handle the errata and revision specifics at runtime based on the
compatible entry ("img,sgx530-121") and know about SoC integration ("ti,omap3-sgx530-121").

And user-space can be made to load the right firmware variant based on "img,sgx530-121"

I don't know if there is some register which allows to discover the revision long
before the SGX subsystem is initialized and the firmware is up and running.

What I know is that it is possible to read out the revision after starting the firmware
but it may just echo the version number of the firmware binary provided from user-space.

> +      - items:
> +          - enum:
> +              - ingenic,jz4780-gpu # Rev 130
> +              - ti,omap4430-gpu # Rev 120
> +          - const: img,powervr-sgx540
> +      - items:
> +          - enum:
> +              - allwinner,sun6i-a31-gpu # MP2 Rev 115
> +              - ti,omap4470-gpu # MP1 Rev 112
> +              - ti,omap5432-gpu # MP2 Rev 105
> +              - ti,am5728-gpu # MP2 Rev 116
> +              - ti,am6548-gpu # MP1 Rev 117
> +          - const: img,powervr-sgx544
> 
>   reg:
>     maxItems: 1
> @@ -40,8 +62,6 @@ properties:
> required:
>   - compatible
>   - reg
> -  - clocks
> -  - clock-names
>   - interrupts
> 
> additionalProperties: false
> @@ -56,6 +76,43 @@ allOf:
>       properties:
>         clocks:
>           maxItems: 1
> +      required:
> +        - clocks
> +        - clock-names
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: ti,am654-sgx544
> +    then:
> +      properties:
> +        power-domains:
> +          minItems: 1
> +      required:
> +        - power-domains
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: allwinner,sun6i-a31-gpu
> +    then:
> +      properties:
> +        clocks:
> +          minItems: 2
> +        clock-names:
> +          minItems: 2
> +      required:
> +        - clocks
> +        - clock-names
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: ingenic,jz4780-gpu
> +    then:
> +      required:
> +        - clocks
> +        - clock-names
> 
> examples:
>   - |
> -- 
> 2.39.2
> 

BR and thanks,
Nikolaus

From hns at goldelico.com  Tue Dec  5 00:18:58 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Tue, 5 Dec 2023 09:18:58 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
Message-ID: <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>



> Am 05.12.2023 um 07:57 schrieb Maxime Ripard <mripard at kernel.org>:
> 
> On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
>> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
>> including register space and interrupts. Clocks, reset, and power domain
>> information is SoC specific.
>> 
>> Signed-off-by: Andrew Davis <afd at ti.com>
>> ---
>> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
>> 1 file changed, 63 insertions(+), 6 deletions(-)
> 
> I think it would be best to have a separate file for this, img,sgx.yaml
> maybe?

Why?

The whole family of IMG GPUs is PowerVR and SGX and Rogue are generations 5 and 6++:

https://en.wikipedia.org/wiki/PowerVR

So I would suggest to keep either img,powervr.yaml for all of them or

img,powervr-sgx.yaml
img,powervr-rogue.yaml

etc.

But as far as I can see the hardware integration into SoC (and hence description)
is quite similar so a single file should suffice.

BR,
Nikolaus

From laurent.pinchart at ideasonboard.com  Tue Dec  5 00:20:16 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 5 Dec 2023 10:20:16 +0200
Subject: [PATCH 3/4] media: rkisp1: Fix IRQ handling due to shared
 interrupts
In-Reply-To: <20231205-rkisp-irq-fix-v1-3-f4045c74ba45@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
 <20231205-rkisp-irq-fix-v1-3-f4045c74ba45@ideasonboard.com>
Message-ID: <20231205082016.GA17394@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Tue, Dec 05, 2023 at 10:09:34AM +0200, Tomi Valkeinen wrote:
> The driver requests the interrupts as IRQF_SHARED, so the interrupt
> handlers can be called at any time. If such a call happens while the ISP
> is powered down, the SoC will hang as the driver tries to access the
> ISP registers.

Is IRQF_SHARED actually needed ?

> Fix this by adding a new field, 'irqs_enabled', which is used to bail
> out from the interrupt handler when the ISP is not operational.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
>  .../media/platform/rockchip/rkisp1/rkisp1-capture.c |  3 +++
>  .../media/platform/rockchip/rkisp1/rkisp1-common.h  |  2 ++
>  drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c |  3 +++
>  drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 21 +++++++++++++++++++++
>  drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c |  3 +++
>  5 files changed, 32 insertions(+)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> index b50b044d22af..e92067897f28 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> @@ -779,6 +779,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
>  	unsigned int i;
>  	u32 status;
>  
> +	if (!rkisp1->irqs_enabled)
> +		return IRQ_NONE;
> +
>  	status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
>  	if (!status)
>  		return IRQ_NONE;
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> index ec28907d978e..7f97fdf6e24c 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> @@ -465,6 +465,7 @@ struct rkisp1_debug {
>   * @debug:	   debug params to be exposed on debugfs
>   * @info:	   version-specific ISP information
>   * @irqs:          IRQ line numbers
> + * @irqs_enabled:  the hardware is enabled and can cause interrupts
>   */
>  struct rkisp1_device {
>  	void __iomem *base_addr;
> @@ -488,6 +489,7 @@ struct rkisp1_device {
>  	struct rkisp1_debug debug;
>  	const struct rkisp1_info *info;
>  	int irqs[RKISP1_NUM_IRQS];
> +	bool irqs_enabled;
>  };
>  
>  /*
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> index 47f4353a1784..f6b54654b435 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> @@ -184,6 +184,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
>  	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>  	u32 val, status;
>  
> +	if (!rkisp1->irqs_enabled)
> +		return IRQ_NONE;
> +
>  	status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
>  	if (!status)
>  		return IRQ_NONE;
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 1d60f4b8bd09..fbe03f7864e3 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -306,6 +306,23 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
>  {
>  	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>  
> +	rkisp1->irqs_enabled = false;
> +	/* Make sure the IRQ handler will see the above */
> +	mb();
> +
> +	/*
> +	 * Wait until any running IRQ handler has returned. The IRQ handler
> +	 * may get called even after this (as it's a shared interrupt line)
> +	 * but the 'irqs_enabled' flag will make the handler return immediately.
> +	 */
> +	for (unsigned int i = 0; i < RKISP1_NUM_IRQS; ++i) {
> +		if (rkisp1->irqs[i] == -1)
> +			continue;
> +
> +		if (i == 0 || rkisp1->irqs[i - 1] != rkisp1->irqs[i])
> +			synchronize_irq(rkisp1->irqs[i]);
> +	}
> +
>  	clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
>  	return pinctrl_pm_select_sleep_state(dev);
>  }
> @@ -322,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
>  	if (ret)
>  		return ret;
>  
> +	rkisp1->irqs_enabled = true;
> +	/* Make sure the IRQ handler will see the above */
> +	mb();
> +
>  	return 0;
>  }
>  
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> index dafbfd230542..d6b8786661ad 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> @@ -1082,6 +1082,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
>  	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>  	u32 status, isp_err;
>  
> +	if (!rkisp1->irqs_enabled)
> +		return IRQ_NONE;
> +
>  	status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
>  	if (!status)
>  		return IRQ_NONE;

-- 
Regards,

Laurent Pinchart


From shawnguo at kernel.org  Tue Dec  5 00:22:33 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 16:22:33 +0800
Subject: [PATCH v1 0/2] imx6/imx8-apalis: add can power-up delay on ixora
 board
In-Reply-To: <20231020153022.57858-1-andrejs.cainikovs@gmail.com>
References: <20231020153022.57858-1-andrejs.cainikovs@gmail.com>
Message-ID: <20231205082233.GA236001@dragon>

On Fri, Oct 20, 2023 at 05:30:20PM +0200, Andrejs Cainikovs wrote:
> From: Andrejs Cainikovs <andrejs.cainikovs at toradex.com>
> 
> Newer variants of Ixora boards require a power-up delay when powering up
> the CAN transceiver of up to 1ms. This series adds mentioned delay for
> iMX6 and iMX8 Apalis SoM variants.
> 
> Andrejs Cainikovs (2):
>   arm64: dts: imx8-apalis: add can power-up delay on ixora board
>   ARM: dts: imx6q-apalis: add can power-up delay on ixora board

Applied both, thanks!


From tomi.valkeinen at ideasonboard.com  Tue Dec  5 00:22:47 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 5 Dec 2023 10:22:47 +0200
Subject: [PATCH v2 4/4] media: rkisp1: debug: Consolidate counter debugfs
 files
In-Reply-To: <20231201140433.2126011-5-paul.elder@ideasonboard.com>
References: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
 <20231201140433.2126011-5-paul.elder@ideasonboard.com>
Message-ID: <212f4a89-7135-41ca-9638-b36a474b1bfa@ideasonboard.com>

On 01/12/2023 16:04, Paul Elder wrote:
> Consolidate all the debugfs files that were each a single counter into a
> single "counters" file.
> 
> While at it, reset the counters at stream on time to make it easier for
> to interpret the values in userspace.
> 
> Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
> 
> ---
> New in v2
> 
>   .../platform/rockchip/rkisp1/rkisp1-capture.c |  2 +
>   .../platform/rockchip/rkisp1/rkisp1-common.h  |  4 ++
>   .../platform/rockchip/rkisp1/rkisp1-debug.c   | 69 ++++++++++++-------
>   3 files changed, 50 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> index c6d7e01c8949..67b2e94dfd67 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> @@ -1030,6 +1030,8 @@ rkisp1_vb2_start_streaming(struct vb2_queue *queue, unsigned int count)
>   	struct media_entity *entity = &cap->vnode.vdev.entity;
>   	int ret;
>   
> +	rkisp1_debug_reset_counters(cap->rkisp1);
> +
>   	mutex_lock(&cap->rkisp1->stream_lock);
>   
>   	ret = video_device_pipeline_start(&cap->vnode.vdev, &cap->rkisp1->pipe);
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> index be69173958a4..789259fb304a 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> @@ -599,9 +599,13 @@ int rkisp1_params_register(struct rkisp1_device *rkisp1);
>   void rkisp1_params_unregister(struct rkisp1_device *rkisp1);
>   
>   #if IS_ENABLED(CONFIG_DEBUG_FS)
> +void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1);
>   void rkisp1_debug_init(struct rkisp1_device *rkisp1);
>   void rkisp1_debug_cleanup(struct rkisp1_device *rkisp1);
>   #else
> +static inline void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1)
> +{
> +}
>   static inline void rkisp1_debug_init(struct rkisp1_device *rkisp1)
>   {
>   }
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
> index 79cda589d935..4358ed1367ed 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
> @@ -25,6 +25,11 @@ struct rkisp1_debug_register {
>   	const char * const name;
>   };
>   
> +struct rkisp1_debug_counter {
> +	const char * const name;
> +	unsigned long *value;
> +};
> +
>   #define RKISP1_DEBUG_REG(name)		{ RKISP1_CIF_##name, 0, #name }
>   #define RKISP1_DEBUG_SHD_REG(name) { \
>   	RKISP1_CIF_##name, RKISP1_CIF_##name##_SHD, #name \
> @@ -191,6 +196,43 @@ static int rkisp1_debug_input_status_show(struct seq_file *m, void *p)
>   }
>   DEFINE_SHOW_ATTRIBUTE(rkisp1_debug_input_status);
>   
> +static int rkisp1_debug_counters_show(struct seq_file *m, void *p)
> +{
> +	struct rkisp1_device *rkisp1 = m->private;
> +	struct rkisp1_debug *debug = &rkisp1->debug;
> +
> +	const struct rkisp1_debug_counter counters[] = {
> +		{ "data_loss", &debug->data_loss },
> +		{ "outform_size_err", &debug->outform_size_error },
> +		{ "img_stabilization_size_error", &debug->img_stabilization_size_error },
> +		{ "inform_size_error", &debug->inform_size_error },
> +		{ "irq_delay", &debug->irq_delay },
> +		{ "mipi_error", &debug->mipi_error },
> +		{ "stats_error", &debug->stats_error },
> +		{ "mp_stop_timeout", &debug->stop_timeout[RKISP1_MAINPATH] },
> +		{ "sp_stop_timeout", &debug->stop_timeout[RKISP1_SELFPATH] },
> +		{ "mp_frame_drop", &debug->frame_drop[RKISP1_MAINPATH] },
> +		{ "sp_frame_drop", &debug->frame_drop[RKISP1_SELFPATH] },
> +		{ "complete_frames", &debug->complete_frames },
> +		{ /* Sentinel */ },
> +	};
> +
> +	const struct rkisp1_debug_counter *counter = counters;
> +
> +	for (; counter->name; ++counter)
> +		seq_printf(m, "%s: %lu\n", counter->name, *counter->value);
> +

You could also do:

	const struct {
		const char *name;
		unsigned long value;
	} counters[] = {
		{ "data_loss", debug->data_loss },
		{ "outform_size_err", debug->outform_size_error },
		{ "img_stabilization_size_error", debug->img_stabilization_size_error },
		{ "inform_size_error", debug->inform_size_error },
		{ "irq_delay", debug->irq_delay },
		{ "mipi_error", debug->mipi_error },
		{ "stats_error", debug->stats_error },
		{ "mp_stop_timeout", debug->stop_timeout[RKISP1_MAINPATH] },
		{ "sp_stop_timeout", debug->stop_timeout[RKISP1_SELFPATH] },
		{ "mp_frame_drop", debug->frame_drop[RKISP1_MAINPATH] },
		{ "sp_frame_drop", debug->frame_drop[RKISP1_SELFPATH] },
		{ "complete_frames", debug->complete_frames },
	};

	for (unsigned int i = 0; i < ARRAY_SIZE(counters); ++i)
		seq_printf(m, "%s: %lu\n", counters[i].name, counters[i].value);

Not a big difference, but this doesn't "leak" the struct used only inside the
function, doesn't need the sentinel, and I don't see a reason to store pointers
to values, instead of just storing the values.

  Tomi

> +	return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(rkisp1_debug_counters);
> +
> +void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1)
> +{
> +	struct dentry *debugfs_dir = rkisp1->debug.debugfs_dir;
> +	memset(&rkisp1->debug, 0, sizeof(rkisp1->debug));
> +	rkisp1->debug.debugfs_dir = debugfs_dir;
> +}
> +
>   void rkisp1_debug_init(struct rkisp1_device *rkisp1)
>   {
>   	struct rkisp1_debug *debug = &rkisp1->debug;
> @@ -198,31 +240,8 @@ void rkisp1_debug_init(struct rkisp1_device *rkisp1)
>   
>   	debug->debugfs_dir = debugfs_create_dir(dev_name(rkisp1->dev), NULL);
>   
> -	debugfs_create_ulong("data_loss", 0444, debug->debugfs_dir,
> -			     &debug->data_loss);
> -	debugfs_create_ulong("outform_size_err", 0444,  debug->debugfs_dir,
> -			     &debug->outform_size_error);
> -	debugfs_create_ulong("img_stabilization_size_error", 0444,
> -			     debug->debugfs_dir,
> -			     &debug->img_stabilization_size_error);
> -	debugfs_create_ulong("inform_size_error", 0444,  debug->debugfs_dir,
> -			     &debug->inform_size_error);
> -	debugfs_create_ulong("irq_delay", 0444,  debug->debugfs_dir,
> -			     &debug->irq_delay);
> -	debugfs_create_ulong("mipi_error", 0444, debug->debugfs_dir,
> -			     &debug->mipi_error);
> -	debugfs_create_ulong("stats_error", 0444, debug->debugfs_dir,
> -			     &debug->stats_error);
> -	debugfs_create_ulong("mp_stop_timeout", 0444, debug->debugfs_dir,
> -			     &debug->stop_timeout[RKISP1_MAINPATH]);
> -	debugfs_create_ulong("sp_stop_timeout", 0444, debug->debugfs_dir,
> -			     &debug->stop_timeout[RKISP1_SELFPATH]);
> -	debugfs_create_ulong("mp_frame_drop", 0444, debug->debugfs_dir,
> -			     &debug->frame_drop[RKISP1_MAINPATH]);
> -	debugfs_create_ulong("sp_frame_drop", 0444, debug->debugfs_dir,
> -			     &debug->frame_drop[RKISP1_SELFPATH]);
> -	debugfs_create_ulong("complete_frames", 0444, debug->debugfs_dir,
> -			     &debug->complete_frames);
> +	debugfs_create_file("counters", 0444, debug->debugfs_dir, rkisp1,
> +			    &rkisp1_debug_counters_fops);
>   	debugfs_create_file("input_status", 0444, debug->debugfs_dir, rkisp1,
>   			    &rkisp1_debug_input_status_fops);
>   



From tomi.valkeinen at ideasonboard.com  Tue Dec  5 00:27:34 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 5 Dec 2023 10:27:34 +0200
Subject: [PATCH 3/4] media: rkisp1: Fix IRQ handling due to shared
 interrupts
In-Reply-To: <20231205082016.GA17394@pendragon.ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
 <20231205-rkisp-irq-fix-v1-3-f4045c74ba45@ideasonboard.com>
 <20231205082016.GA17394@pendragon.ideasonboard.com>
Message-ID: <9b28dcf7-c9a0-4d68-9197-cdcdd9f0393b@ideasonboard.com>

On 05/12/2023 10:20, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Tue, Dec 05, 2023 at 10:09:34AM +0200, Tomi Valkeinen wrote:
>> The driver requests the interrupts as IRQF_SHARED, so the interrupt
>> handlers can be called at any time. If such a call happens while the ISP
>> is powered down, the SoC will hang as the driver tries to access the
>> ISP registers.
> 
> Is IRQF_SHARED actually needed ?

I don't have any answer to that, but it seems to have always been there. 
Dropping it would simplify the code, but we can only do that if we are 
sure all the platforms the ISP is used on or will be used on won't share 
the interrupt.

  Tomi

>> Fix this by adding a new field, 'irqs_enabled', which is used to bail
>> out from the interrupt handler when the ISP is not operational.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>> ---
>>   .../media/platform/rockchip/rkisp1/rkisp1-capture.c |  3 +++
>>   .../media/platform/rockchip/rkisp1/rkisp1-common.h  |  2 ++
>>   drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c |  3 +++
>>   drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 21 +++++++++++++++++++++
>>   drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c |  3 +++
>>   5 files changed, 32 insertions(+)
>>
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
>> index b50b044d22af..e92067897f28 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
>> @@ -779,6 +779,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
>>   	unsigned int i;
>>   	u32 status;
>>   
>> +	if (!rkisp1->irqs_enabled)
>> +		return IRQ_NONE;
>> +
>>   	status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
>>   	if (!status)
>>   		return IRQ_NONE;
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
>> index ec28907d978e..7f97fdf6e24c 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
>> @@ -465,6 +465,7 @@ struct rkisp1_debug {
>>    * @debug:	   debug params to be exposed on debugfs
>>    * @info:	   version-specific ISP information
>>    * @irqs:          IRQ line numbers
>> + * @irqs_enabled:  the hardware is enabled and can cause interrupts
>>    */
>>   struct rkisp1_device {
>>   	void __iomem *base_addr;
>> @@ -488,6 +489,7 @@ struct rkisp1_device {
>>   	struct rkisp1_debug debug;
>>   	const struct rkisp1_info *info;
>>   	int irqs[RKISP1_NUM_IRQS];
>> +	bool irqs_enabled;
>>   };
>>   
>>   /*
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>> index 47f4353a1784..f6b54654b435 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>> @@ -184,6 +184,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
>>   	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>>   	u32 val, status;
>>   
>> +	if (!rkisp1->irqs_enabled)
>> +		return IRQ_NONE;
>> +
>>   	status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
>>   	if (!status)
>>   		return IRQ_NONE;
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>> index 1d60f4b8bd09..fbe03f7864e3 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>> @@ -306,6 +306,23 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
>>   {
>>   	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>>   
>> +	rkisp1->irqs_enabled = false;
>> +	/* Make sure the IRQ handler will see the above */
>> +	mb();
>> +
>> +	/*
>> +	 * Wait until any running IRQ handler has returned. The IRQ handler
>> +	 * may get called even after this (as it's a shared interrupt line)
>> +	 * but the 'irqs_enabled' flag will make the handler return immediately.
>> +	 */
>> +	for (unsigned int i = 0; i < RKISP1_NUM_IRQS; ++i) {
>> +		if (rkisp1->irqs[i] == -1)
>> +			continue;
>> +
>> +		if (i == 0 || rkisp1->irqs[i - 1] != rkisp1->irqs[i])
>> +			synchronize_irq(rkisp1->irqs[i]);
>> +	}
>> +
>>   	clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
>>   	return pinctrl_pm_select_sleep_state(dev);
>>   }
>> @@ -322,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
>>   	if (ret)
>>   		return ret;
>>   
>> +	rkisp1->irqs_enabled = true;
>> +	/* Make sure the IRQ handler will see the above */
>> +	mb();
>> +
>>   	return 0;
>>   }
>>   
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>> index dafbfd230542..d6b8786661ad 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>> @@ -1082,6 +1082,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
>>   	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>>   	u32 status, isp_err;
>>   
>> +	if (!rkisp1->irqs_enabled)
>> +		return IRQ_NONE;
>> +
>>   	status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
>>   	if (!status)
>>   		return IRQ_NONE;
> 



From tony at atomide.com  Tue Dec  5 00:30:01 2023
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 5 Dec 2023 10:30:01 +0200
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <efcd64f4-00d2-4671-af3a-e27764f70e8d@linaro.org>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
 <20231205075657.GN5169@atomide.com>
 <df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>
 <20231205081031.GO5169@atomide.com>
 <efcd64f4-00d2-4671-af3a-e27764f70e8d@linaro.org>
Message-ID: <20231205083001.GP5169@atomide.com>

* Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> [231205 08:16]:
> On 05/12/2023 09:10, Tony Lindgren wrote:
> > * Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> [231205 08:03]:
> >> What does runtime PM have to do with it? If runtime PM enables clocks,
> >> these are real signals and not optional.
> > 
> > Runtime PM propagates to the parent device.
> 
> Then it is not really relevant to the hardware talk here, unless you put
> this device clocks in parent node, but then it's just wrong hardware
> description.

No it's not. The interconnect target module may have one or more separate
devices with the same shared clocks. See for example the am3 usb module that
has usb controllers, phys and dma at target-module at 47400000 in am33xx.dtsi.

Sure the clock nodes can be there for the child IP, but they won't do
anything. And still need to be managed separately by the device driver if
added.

Regards,

Tony


From miquel.raynal at bootlin.com  Tue Dec  5 00:31:02 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Tue,  5 Dec 2023 09:31:02 +0100
Subject: [PATCH] spi: atmel: Prevent spi transfers from being killed
Message-ID: <20231205083102.16946-1-miquel.raynal@bootlin.com>

Upstream commit e0205d6203c2 ("spi: atmel: Prevent false timeouts on
long transfers") has tried to mitigate the problem of getting spi
transfers canceled because they were lasting too long. On slow buses,
transfers in the MiB range can take more than one second and thus a
calculation was added to progressively increment the timeout value. In
order to not be too problematic from a user point of view (waiting dozen
of seconds or even minutes), the wait call was turned interruptible.

Turning the wait interruptible was a mistake as what we really wanted to
do was to be able to kill a transfer. Any signal interrupting our
transfer would not be suitable at all so a second attempt was made at
turning the wait killable instead.

Link: https://lore.kernel.org/linux-spi/20231127095842.389631-1-miquel.raynal at bootlin.com/

All being well, it was reported that JFFS2 was showing a splat when
interrupting a transfer. After some more debate about whether JFFS2
should be fixed and how, it was also pointed out that the whole
consistency of the filesystem in case of parallel I/O would be
compromised. Changing JFFS2 behavior would in theory be possible but
nobody has the energy and time and knowledge to do this now, so better
prevent spi transfers to be interrupted by the user.

Partially revert the blamed commit to no longer use the interruptible
nor the killable variant of wait_for_completion().

Fixes: e0205d6203c2 ("spi: atmel: Prevent false timeouts on long transfers")
Cc: stable at vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
 drivers/spi/spi-atmel.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 0197c25f5029..54277de30161 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1333,12 +1333,10 @@ static int atmel_spi_one_transfer(struct spi_controller *host,
 		}
 
 		dma_timeout = msecs_to_jiffies(spi_controller_xfer_timeout(host, xfer));
-		ret_timeout = wait_for_completion_killable_timeout(&as->xfer_completion,
-								   dma_timeout);
-		if (ret_timeout <= 0) {
-			dev_err(&spi->dev, "spi transfer %s\n",
-				!ret_timeout ? "timeout" : "canceled");
-			as->done_status = ret_timeout < 0 ? ret_timeout : -EIO;
+		ret_timeout = wait_for_completion_timeout(&as->xfer_completion, dma_timeout);
+		if (!ret_timeout) {
+			dev_err(&spi->dev, "spi transfer timeout\n");
+			as->done_status = -EIO;
 		}
 
 		if (as->done_status)
-- 
2.34.1



From shawnguo at kernel.org  Tue Dec  5 00:33:11 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 16:33:11 +0800
Subject: [PATCH v3] arm64: dts: freescale: debix-som-a-bmb-08: Add CSI
 Power Regulators
In-Reply-To: <20231127124037.888597-1-kieran.bingham@ideasonboard.com>
References: <20231127124037.888597-1-kieran.bingham@ideasonboard.com>
Message-ID: <20231205083311.GB236001@dragon>

On Mon, Nov 27, 2023 at 12:40:34PM +0000, Kieran Bingham wrote:
> Provide the 1.8 and 3.3 volt regulators that are utilised on the Debix
> SOM BMB-08 base board.
> 
> Facilitate this by also supplying the pin control used to enable the
> regulators on the second MIPI CSI port.
> 
> Reviewed-by: Marco Felsch <m.felsch at pengutronix.de>
> Signed-off-by: Kieran Bingham <kieran.bingham at ideasonboard.com>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 00:37:06 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 16:37:06 +0800
Subject: [PATCH v2] arm64: dts: imx8mp: imx8mq: Add
 parkmode-disable-ss-quirk on DWC3
In-Reply-To: <20231106021436.1917894-1-nathan@nathanrossi.com>
References: <20231106021436.1917894-1-nathan@nathanrossi.com>
Message-ID: <20231205083706.GC236001@dragon>

On Mon, Nov 06, 2023 at 02:14:36AM +0000, Nathan Rossi wrote:
> From: Nathan Rossi <nathan.rossi at digi.com>
> 
> The i.MX8MP and i.MX8MQ devices both use the same DWC3 controller and
> are both affected by a known issue with the controller due to specific
> behaviour when park mode is enabled in SuperSpeed host mode operation.
> 
> Under heavy USB traffic from multiple endpoints the controller will
> sometimes incorrectly process transactions such that some transactions
> are lost, or the controller may hang when processing transactions. When
> the controller hangs it does not recover.
> 
> This issue is documented partially within the linux-imx vendor kernel
> which references a Synopsys STAR number 9001415732 in commits [1] and
> additional details in [2]. Those commits provide some additional
> controller internal implementation specifics around the incorrect
> behaviour of the SuperSpeed host controller operation when park mode is
> enabled.
> 
> The summary of this issue is that the host controller can incorrectly
> enter/exit park mode such that part of the controller is in a state
> which behaves as if in park mode even though it is not. In this state
> the controller incorrectly calculates the number of TRBs available which
> results in incorrect access of the internal caches causing the overwrite
> of pending requests in the cache which should have been processed but
> are ignored. This can cause the controller to drop the requests or hang
> waiting for the pending state of the dropped requests.
> 
> The workaround for this issue is to disable park mode for SuperSpeed
> operation of the controller through the GUCTL1[17] bit. This is already
> available as a quirk for the DWC3 controller and can be enabled via the
> 'snps,parkmode-disable-ss-quirk' device tree property.
> 
> It is possible to replicate this failure on an i.MX8MP EVK with a USB
> Hub connecting 4 SuperSpeed USB flash drives. Performing continuous
> small read operations (dd if=/dev/sd... of=/dev/null bs=16) on the block
> devices will result in device errors initially and will eventually
> result in the controller hanging.
> 
>   [13240.896936] xhci-hcd xhci-hcd.0.auto: WARN Event TRB for slot 4 ep 2 with no TDs queued?
>   [13240.990708] usb 2-1.3: reset SuperSpeed USB device number 5 using xhci-hcd
>   [13241.015582] sd 2:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
>   [13241.025198] sd 2:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
>   [13241.032949] I/O error, dev sdc, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 25 prio class 2
>   [13272.150710] usb 2-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
>   [13272.175469] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=DRIVER_OK cmd_age=31s
>   [13272.185365] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00
>   [13272.193385] I/O error, dev sdb, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 2
>   [13434.846556] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command
>   [13434.854592] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
>   [13434.862553] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
> 
> [1] https://github.com/nxp-imx/linux-imx/commit/97a5349d936b08cf301730b59e4e8855283f815c
> [2] https://github.com/nxp-imx/linux-imx/commit/b4b5cbc5a12d7c3b920d1d7cba0ada3379e4e42b
> 
> Fixes: fb8587a2c165 ("arm64: dtsi: imx8mp: add usb nodes")
> Fixes: ad37549cb5dc ("arm64: dts: imx8mq: add USB nodes")
> Signed-off-by: Nathan Rossi <nathan.rossi at digi.com>
> Reviewed-by: Fabio Estevam <festevam at gmail.com>

Applied, thanks!


From umang.jain at ideasonboard.com  Tue Dec  5 00:41:53 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Tue,  5 Dec 2023 14:11:53 +0530
Subject: [PATCH v3 0/4] staging: vc04_services: Drop custom logging
Message-ID: <20231205084157.73819-1-umang.jain@ideasonboard.com>

This series also removes the vchiq_log_* macro and makes use of dev_*()
logging helpers directly.

Patch 1/4 removes vchiq_log_error() macro
Patch 2/4 removes vchiq_log_warning() macro
Patch 3/4 removes vchiq_log_trace() macro
Patch 4/4 removes vchiq_log_debug() macro

This completes the following TODO item:

```
* Cleanup logging mechanism

The driver should probably be using the standard kernel logging mechanisms
such as dev_info, dev_dbg, and friends.
```

Changes in v3:
- vchiq_log_error() will log to dev_err
- vchiq_log_warn() will log to dev_warn
- vchiq_log_trace() will log to dev_dbg

Changes in v2:
- Separate out one fixup patch from v1 (Patch 1/9)and send separately
- Drop usage of log_type() and log_category() helpers. Directly use
  dev_dbg() as suggested by Greg KH.
- Drop __func__ annotation from all logs. Dynamic debug has 'f'
  decorator flag which can be used instead of manual __func__
- Reword commit messages.

Umang Jain (4):
  staging: vc04_services: Drop vchiq_log_error() in favour of dev_err
  staging: vc04_services: Drop vchiq_log_warning() in favour of dev_warn
  staging: vc04_services: Drop vchiq_log_trace() in favour of dev_dbg
  staging: vc04_services: Drop vchiq_log_debug() in favour of dev_dbg

 drivers/staging/vc04_services/interface/TODO  |   5 -
 .../interface/vchiq_arm/vchiq_arm.c           | 178 ++++----
 .../interface/vchiq_arm/vchiq_connected.c     |   6 +-
 .../interface/vchiq_arm/vchiq_core.c          | 403 +++++++++---------
 .../interface/vchiq_arm/vchiq_core.h          |  38 --
 .../interface/vchiq_arm/vchiq_dev.c           |  92 ++--
 6 files changed, 314 insertions(+), 408 deletions(-)

-- 
2.41.0



From umang.jain at ideasonboard.com  Tue Dec  5 00:41:54 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Tue,  5 Dec 2023 14:11:54 +0530
Subject: [PATCH v3 1/4] staging: vc04_services: Drop vchiq_log_error() in favour of dev_err
In-Reply-To: <20231205084157.73819-1-umang.jain@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
Message-ID: <20231205084157.73819-2-umang.jain@ideasonboard.com>

Drop vchiq_log_error() macro which wraps dev_dbg(). Introduce the usage
of dev_err() directly.

Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
---
 .../interface/vchiq_arm/vchiq_arm.c           |  50 ++++----
 .../interface/vchiq_arm/vchiq_connected.c     |   6 +-
 .../interface/vchiq_arm/vchiq_core.c          | 113 +++++++++---------
 .../interface/vchiq_arm/vchiq_core.h          |   4 -
 .../interface/vchiq_arm/vchiq_dev.c           |  45 ++++---
 5 files changed, 101 insertions(+), 117 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 7978fb6dc4fb..b403400edd8e 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -683,8 +683,7 @@ int vchiq_initialise(struct vchiq_instance **instance_out)
 		usleep_range(500, 600);
 	}
 	if (i == VCHIQ_INIT_RETRIES) {
-		vchiq_log_error(state->dev, VCHIQ_CORE, "%s: videocore not initialized\n",
-				__func__);
+		dev_err(state->dev, "core: %s: Videocore not initialized\n", __func__);
 		ret = -ENOTCONN;
 		goto failed;
 	} else if (i > 0) {
@@ -694,8 +693,7 @@ int vchiq_initialise(struct vchiq_instance **instance_out)
 
 	instance = kzalloc(sizeof(*instance), GFP_KERNEL);
 	if (!instance) {
-		vchiq_log_error(state->dev, VCHIQ_CORE,
-				"%s: error allocating vchiq instance\n", __func__);
+		dev_err(state->dev, "core: %s: Cannot allocate vchiq instance\n", __func__);
 		ret = -ENOMEM;
 		goto failed;
 	}
@@ -967,8 +965,7 @@ vchiq_blocking_bulk_transfer(struct vchiq_instance *instance, unsigned int handl
 	} else {
 		waiter = kzalloc(sizeof(*waiter), GFP_KERNEL);
 		if (!waiter) {
-			vchiq_log_error(service->state->dev, VCHIQ_CORE,
-					"%s - out of memory", __func__);
+			dev_err(service->state->dev, "core: %s: - Out of memory\n", __func__);
 			return -ENOMEM;
 		}
 	}
@@ -1290,8 +1287,8 @@ vchiq_keepalive_vchiq_callback(struct vchiq_instance *instance,
 			       struct vchiq_header *header,
 			       unsigned int service_user, void *bulk_user)
 {
-	vchiq_log_error(instance->state->dev, VCHIQ_SUSPEND,
-			"%s callback reason %d", __func__, reason);
+	dev_err(instance->state->dev, "suspend: %s: callback reason %d\n",
+		__func__, reason);
 	return 0;
 }
 
@@ -1315,22 +1312,20 @@ vchiq_keepalive_thread_func(void *v)
 
 	ret = vchiq_initialise(&instance);
 	if (ret) {
-		vchiq_log_error(state->dev, VCHIQ_SUSPEND,
-				"%s vchiq_initialise failed %d", __func__, ret);
+		dev_err(state->dev, "suspend: %s: vchiq_initialise failed %d\n", __func__, ret);
 		goto exit;
 	}
 
 	status = vchiq_connect(instance);
 	if (status) {
-		vchiq_log_error(state->dev, VCHIQ_SUSPEND,
-				"%s vchiq_connect failed %d", __func__, status);
+		dev_err(state->dev, "suspend: %s: vchiq_connect failed %d\n", __func__, status);
 		goto shutdown;
 	}
 
 	status = vchiq_add_service(instance, &params, &ka_handle);
 	if (status) {
-		vchiq_log_error(state->dev, VCHIQ_SUSPEND,
-				"%s vchiq_open_service failed %d", __func__, status);
+		dev_err(state->dev, "suspend: %s: vchiq_open_service failed %d\n",
+			__func__, status);
 		goto shutdown;
 	}
 
@@ -1338,8 +1333,7 @@ vchiq_keepalive_thread_func(void *v)
 		long rc = 0, uc = 0;
 
 		if (wait_for_completion_interruptible(&arm_state->ka_evt)) {
-			vchiq_log_error(state->dev, VCHIQ_SUSPEND,
-					"%s interrupted", __func__);
+			dev_err(state->dev, "suspend: %s: interrupted\n", __func__);
 			flush_signals(current);
 			continue;
 		}
@@ -1359,16 +1353,15 @@ vchiq_keepalive_thread_func(void *v)
 			atomic_inc(&arm_state->ka_use_ack_count);
 			status = vchiq_use_service(instance, ka_handle);
 			if (status) {
-				vchiq_log_error(state->dev, VCHIQ_SUSPEND,
-						"%s vchiq_use_service error %d", __func__, status);
+				dev_err(state->dev, "suspend: %s: vchiq_use_service error %d\n",
+					__func__, status);
 			}
 		}
 		while (rc--) {
 			status = vchiq_release_service(instance, ka_handle);
 			if (status) {
-				vchiq_log_error(state->dev, VCHIQ_SUSPEND,
-						"%s vchiq_release_service error %d", __func__,
-						status);
+				dev_err(state->dev, "suspend: %s: vchiq_release_service error %d\n",
+					__func__, status);
 			}
 		}
 	}
@@ -1403,7 +1396,7 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
 			 service->client_id);
 		entity_uc = &service->service_use_count;
 	} else {
-		vchiq_log_error(state->dev, VCHIQ_SUSPEND, "%s null service ptr", __func__);
+		dev_err(state->dev, "suspend: %s: null service ptr\n", __func__);
 		ret = -EINVAL;
 		goto out;
 	}
@@ -1686,10 +1679,10 @@ vchiq_check_service(struct vchiq_service *service)
 	read_unlock_bh(&arm_state->susp_res_lock);
 
 	if (ret) {
-		vchiq_log_error(service->state->dev, VCHIQ_SUSPEND,
-				"%s ERROR - %p4cc:%d service count %d, state count %d", __func__,
-				&service->base.fourcc, service->client_id,
-				service->service_use_count, arm_state->videocore_use_count);
+		dev_err(service->state->dev,
+			"suspend: %s:  %p4cc:%d service count %d, state count %d\n",
+			__func__, &service->base.fourcc, service->client_id,
+			service->service_use_count, arm_state->videocore_use_count);
 		vchiq_dump_service_use_state(service->state);
 	}
 out:
@@ -1722,9 +1715,8 @@ void vchiq_platform_conn_state_changed(struct vchiq_state *state,
 					      (void *)state,
 					      threadname);
 	if (IS_ERR(arm_state->ka_thread)) {
-		vchiq_log_error(state->dev, VCHIQ_SUSPEND,
-				"vchiq: FATAL: couldn't create thread %s",
-				threadname);
+		dev_err(state->dev, "suspend: Couldn't create thread %s\n",
+			threadname);
 	} else {
 		wake_up_process(arm_state->ka_thread);
 	}
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
index 21f9fa1a1713..3cad13f09e37 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
@@ -39,9 +39,9 @@ void vchiq_add_connected_callback(struct vchiq_device *device, void (*callback)(
 		callback();
 	} else {
 		if (g_num_deferred_callbacks >= MAX_CALLBACKS) {
-			vchiq_log_error(&device->dev, VCHIQ_CORE,
-					"There already %d callback registered - please increase MAX_CALLBACKS",
-					g_num_deferred_callbacks);
+			dev_err(&device->dev,
+				"core: There already %d callback registered - please increase MAX_CALLBACKS\n",
+				g_num_deferred_callbacks);
 		} else {
 			g_deferred_callback[g_num_deferred_callbacks] =
 				callback;
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index e0022acb4c58..63f412815a32 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -741,10 +741,10 @@ process_free_data_message(struct vchiq_state *state, u32 *service_found,
 		 */
 		complete(&quota->quota_event);
 	} else if (count == 0) {
-		vchiq_log_error(state->dev, VCHIQ_CORE,
-				"service %d message_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)",
-				port, quota->message_use_count, header, msgid, header->msgid,
-				header->size);
+		dev_err(state->dev,
+			"core: service %d message_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)\n",
+			port, quota->message_use_count, header, msgid,
+			header->msgid, header->size);
 		WARN(1, "invalid message use count\n");
 	}
 	if (!BITSET_IS_SET(service_found, port)) {
@@ -766,9 +766,9 @@ process_free_data_message(struct vchiq_state *state, u32 *service_found,
 			vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: pfq:%d %x@%pK - slot_use->%d",
 					state->id, port, header->size, header, count - 1);
 		} else {
-			vchiq_log_error(state->dev, VCHIQ_CORE,
-					"service %d slot_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)",
-					port, count, header, msgid, header->msgid, header->size);
+			dev_err(state->dev,
+				"core: service %d slot_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)\n",
+				port, count, header, msgid, header->msgid, header->size);
 			WARN(1, "bad slot use count\n");
 		}
 	}
@@ -831,9 +831,9 @@ process_free_queue(struct vchiq_state *state, u32 *service_found,
 
 			pos += calc_stride(header->size);
 			if (pos > VCHIQ_SLOT_SIZE) {
-				vchiq_log_error(state->dev, VCHIQ_CORE,
-						"pfq - pos %x: header %pK, msgid %x, header->msgid %x, header->size %x",
-						pos, header, msgid, header->msgid, header->size);
+				dev_err(state->dev,
+					"core: pfq - pos %x: header %pK, msgid %x, header->msgid %x, header->size %x\n",
+					pos, header, msgid, header->msgid, header->size);
 				WARN(1, "invalid slot position\n");
 			}
 		}
@@ -1167,8 +1167,8 @@ queue_message_sync(struct vchiq_state *state, struct vchiq_service *service,
 		int oldmsgid = header->msgid;
 
 		if (oldmsgid != VCHIQ_MSGID_PADDING)
-			vchiq_log_error(state->dev, VCHIQ_CORE, "%d: qms - msgid %x, not PADDING",
-					state->id, oldmsgid);
+			dev_err(state->dev, "core: %d: qms - msgid %x, not PADDING\n",
+				state->id, oldmsgid);
 	}
 
 	vchiq_log_debug(state->dev, VCHIQ_SYNC,
@@ -1616,10 +1616,10 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 		}
 
 		if (!service) {
-			vchiq_log_error(state->dev, VCHIQ_CORE,
-					"%d: prs %s@%pK (%d->%d) - invalid/closed service %d",
-					state->id, msg_type_str(type), header, remoteport,
-					localport, localport);
+			dev_err(state->dev,
+				"core: %d: prs %s@%pK (%d->%d) - invalid/closed service %d\n",
+				state->id, msg_type_str(type), header, remoteport,
+				localport, localport);
 			goto skip_message;
 		}
 		break;
@@ -1640,9 +1640,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 
 	if (((unsigned long)header & VCHIQ_SLOT_MASK) +
 	    calc_stride(size) > VCHIQ_SLOT_SIZE) {
-		vchiq_log_error(state->dev, VCHIQ_CORE,
-				"header %pK (msgid %x) - size %x too big for slot",
-				header, (unsigned int)msgid, (unsigned int)size);
+		dev_err(state->dev, "core: header %pK (msgid %x) - size %x too big for slot\n",
+			header, (unsigned int)msgid, (unsigned int)size);
 		WARN(1, "oversized for slot\n");
 	}
 
@@ -1668,8 +1667,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 			set_service_state(service, VCHIQ_SRVSTATE_OPEN);
 			complete(&service->remove_event);
 		} else {
-			vchiq_log_error(state->dev, VCHIQ_CORE, "OPENACK received in state %s",
-					srvstate_names[service->srvstate]);
+			dev_err(state->dev, "core: OPENACK received in state %s\n",
+				srvstate_names[service->srvstate]);
 		}
 		break;
 	case VCHIQ_MSG_CLOSE:
@@ -1740,11 +1739,10 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 			}
 			if ((int)(queue->remote_insert -
 				queue->local_insert) >= 0) {
-				vchiq_log_error(state->dev, VCHIQ_CORE,
-						"%d: prs %s@%pK (%d->%d) unexpected (ri=%d,li=%d)",
-						state->id, msg_type_str(type), header, remoteport,
-						localport, queue->remote_insert,
-						queue->local_insert);
+				dev_err(state->dev,
+					"core: %d: prs %s@%pK (%d->%d) unexpected (ri=%d,li=%d)\n",
+					state->id, msg_type_str(type), header, remoteport,
+					localport, queue->remote_insert, queue->local_insert);
 				mutex_unlock(&service->bulk_mutex);
 				break;
 			}
@@ -1790,8 +1788,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs PAUSE@%pK,%x",
 				state->id, header, size);
 		if (state->conn_state == VCHIQ_CONNSTATE_PAUSED) {
-			vchiq_log_error(state->dev, VCHIQ_CORE,
-					"%d: PAUSE received in state PAUSED", state->id);
+			dev_err(state->dev, "core: %d: PAUSE received in state PAUSED\n",
+				state->id);
 			break;
 		}
 		if (state->conn_state != VCHIQ_CONNSTATE_PAUSE_SENT) {
@@ -1821,8 +1819,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 		break;
 
 	default:
-		vchiq_log_error(state->dev, VCHIQ_CORE, "%d: prs invalid msgid %x@%pK,%x",
-				state->id, msgid, header, size);
+		dev_err(state->dev, "core: %d: prs invalid msgid %x@%pK,%x\n",
+			state->id, msgid, header, size);
 		WARN(1, "invalid message\n");
 		break;
 	}
@@ -1932,7 +1930,7 @@ handle_poll(struct vchiq_state *state)
 			 * since the PAUSE should have flushed
 			 * through outstanding messages.
 			 */
-			vchiq_log_error(state->dev, VCHIQ_CORE, "Failed to send RESUME message");
+			dev_err(state->dev, "core: Failed to send RESUME message\n");
 		}
 		break;
 	default:
@@ -2032,10 +2030,10 @@ sync_func(void *v)
 		service = find_service_by_port(state, localport);
 
 		if (!service) {
-			vchiq_log_error(state->dev, VCHIQ_SYNC,
-					"%d: sf %s@%pK (%d->%d) - invalid/closed service %d",
-					state->id, msg_type_str(type), header,
-					remoteport, localport, localport);
+			dev_err(state->dev,
+				"sync: %d: sf %s@%pK (%d->%d) - invalid/closed service %d\n",
+				state->id, msg_type_str(type), header, remoteport,
+				localport, localport);
 			release_message_sync(state, header);
 			continue;
 		}
@@ -2077,15 +2075,15 @@ sync_func(void *v)
 			    (service->srvstate == VCHIQ_SRVSTATE_OPENSYNC)) {
 				if (make_service_callback(service, VCHIQ_MESSAGE_AVAILABLE, header,
 							  NULL) == -EAGAIN)
-					vchiq_log_error(state->dev, VCHIQ_SYNC,
-							"synchronous callback to service %d returns -EAGAIN",
-							localport);
+					dev_err(state->dev,
+						"sync: error: synchronous callback to service %d returns -EAGAIN\n",
+						localport);
 			}
 			break;
 
 		default:
-			vchiq_log_error(state->dev, VCHIQ_SYNC, "%d: sf unexpected msgid %x@%pK,%x",
-					state->id, msgid, header, size);
+			dev_err(state->dev, "sync: error: %d: sf unexpected msgid %x@%pK,%x\n",
+				state->id, msgid, header, size);
 			release_message_sync(state, header);
 			break;
 		}
@@ -2118,8 +2116,8 @@ vchiq_init_slots(struct device *dev, void *mem_base, int mem_size)
 	num_slots -= first_data_slot;
 
 	if (num_slots < 4) {
-		vchiq_log_error(dev, VCHIQ_CORE, "%s - insufficient memory %x bytes",
-				__func__, mem_size);
+		dev_err(dev, "core: %s: Insufficient memory %x bytes\n",
+			__func__, mem_size);
 		return NULL;
 	}
 
@@ -2500,11 +2498,10 @@ vchiq_open_service_internal(struct vchiq_service *service, int client_id)
 	} else if ((service->srvstate != VCHIQ_SRVSTATE_OPEN) &&
 		   (service->srvstate != VCHIQ_SRVSTATE_OPENSYNC)) {
 		if (service->srvstate != VCHIQ_SRVSTATE_CLOSEWAIT)
-			vchiq_log_error(service->state->dev, VCHIQ_CORE,
-					"%d: osi - srvstate = %s (ref %u)",
-					service->state->id,
-					srvstate_names[service->srvstate],
-					kref_read(&service->ref_count));
+			dev_err(service->state->dev,
+				"core: %d: osi - srvstate = %s (ref %u)\n",
+				service->state->id, srvstate_names[service->srvstate],
+				kref_read(&service->ref_count));
 		status = -EINVAL;
 		VCHIQ_SERVICE_STATS_INC(service, error_count);
 		vchiq_release_service_internal(service);
@@ -2565,9 +2562,9 @@ release_service_messages(struct vchiq_service *service)
 			}
 			pos += calc_stride(header->size);
 			if (pos > VCHIQ_SLOT_SIZE) {
-				vchiq_log_error(state->dev, VCHIQ_CORE,
-						"fsi - pos %x: header %pK, msgid %x, header->msgid %x, header->size %x",
-						pos, header, msgid, header->msgid, header->size);
+				dev_err(state->dev,
+					"core: fsi - pos %x: header %pK, msgid %x, header->msgid %x, header->size %x\n",
+					pos, header, msgid, header->msgid, header->size);
 				WARN(1, "invalid slot position\n");
 			}
 		}
@@ -2621,8 +2618,8 @@ close_service_complete(struct vchiq_service *service, int failstate)
 	case VCHIQ_SRVSTATE_LISTENING:
 		break;
 	default:
-		vchiq_log_error(service->state->dev, VCHIQ_CORE, "%s(%x) called in state %s",
-				__func__, service->handle, srvstate_names[service->srvstate]);
+		dev_err(service->state->dev, "core: (%x) called in state %s\n",
+			service->handle, srvstate_names[service->srvstate]);
 		WARN(1, "%s in unexpected state\n", __func__);
 		return -EINVAL;
 	}
@@ -2677,8 +2674,8 @@ vchiq_close_service_internal(struct vchiq_service *service, int close_recvd)
 	case VCHIQ_SRVSTATE_LISTENING:
 	case VCHIQ_SRVSTATE_CLOSEWAIT:
 		if (close_recvd) {
-			vchiq_log_error(state->dev, VCHIQ_CORE, "%s(1) called in state %s",
-					__func__, srvstate_names[service->srvstate]);
+			dev_err(state->dev, "core: (1) called in state %s\n",
+				srvstate_names[service->srvstate]);
 		} else if (is_server) {
 			if (service->srvstate == VCHIQ_SRVSTATE_LISTENING) {
 				status = -EINVAL;
@@ -2765,8 +2762,8 @@ vchiq_close_service_internal(struct vchiq_service *service, int close_recvd)
 		break;
 
 	default:
-		vchiq_log_error(state->dev, VCHIQ_CORE, "%s(%d) called in state %s", __func__,
-				close_recvd, srvstate_names[service->srvstate]);
+		dev_err(state->dev, "core: (%d) called in state %s\n",
+			close_recvd, srvstate_names[service->srvstate]);
 		break;
 	}
 
@@ -2805,8 +2802,8 @@ vchiq_free_service_internal(struct vchiq_service *service)
 	case VCHIQ_SRVSTATE_CLOSEWAIT:
 		break;
 	default:
-		vchiq_log_error(state->dev, VCHIQ_CORE, "%d: fsi - (%d) in state %s", state->id,
-				service->localport, srvstate_names[service->srvstate]);
+		dev_err(state->dev, "core: %d: fsi - (%d) in state %s\n",
+			state->id, service->localport, srvstate_names[service->srvstate]);
 		return;
 	}
 
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
index 564b5c707267..d7dcd17e4bff 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
@@ -53,10 +53,6 @@ static inline const char *log_category_str(enum vchiq_log_category c)
 	return strings[c];
 };
 
-#ifndef vchiq_log_error
-#define vchiq_log_error(dev, cat, fmt, ...) \
-	do { dev_dbg(dev, "%s error: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
-#endif
 #ifndef vchiq_log_warning
 #define vchiq_log_warning(dev, cat, fmt, ...) \
 	do { dev_dbg(dev, "%s warning: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
index 307a2d76cbb7..ba287cb4c87b 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
@@ -271,9 +271,9 @@ static int vchiq_ioc_dequeue_message(struct vchiq_instance *instance,
 			ret = -EFAULT;
 		}
 	} else {
-		vchiq_log_error(service->state->dev, VCHIQ_ARM,
-				"header %pK: bufsize %x < size %x",
-				header, args->bufsize, header->size);
+		dev_err(service->state->dev,
+			"arm: header %pK: bufsize %x < size %x\n",
+			header, args->bufsize, header->size);
 		WARN(1, "invalid size\n");
 		ret = -EMSGSIZE;
 	}
@@ -318,8 +318,8 @@ static int vchiq_irq_queue_bulk_tx_rx(struct vchiq_instance *instance,
 		}
 		mutex_unlock(&instance->bulk_waiter_list_mutex);
 		if (!waiter) {
-			vchiq_log_error(service->state->dev, VCHIQ_ARM,
-					"no bulk_waiter found for pid %d", current->pid);
+			dev_err(service->state->dev,
+				"arm: no bulk_waiter found for pid %d\n", current->pid);
 			ret = -ESRCH;
 			goto out;
 		}
@@ -501,10 +501,10 @@ static int vchiq_ioc_await_completion(struct vchiq_instance *instance,
 			msglen = header->size + sizeof(struct vchiq_header);
 			/* This must be a VCHIQ-style service */
 			if (args->msgbufsize < msglen) {
-				vchiq_log_error(service->state->dev, VCHIQ_ARM,
-						"header %pK: msgbufsize %x < msglen %x",
-						header, args->msgbufsize, msglen);
-						WARN(1, "invalid message size\n");
+				dev_err(service->state->dev,
+					"arm: header %pK: msgbufsize %x < msglen %x\n",
+					header, args->msgbufsize, msglen);
+				WARN(1, "invalid message size\n");
 				if (ret == 0)
 					ret = -EMSGSIZE;
 				break;
@@ -618,9 +618,9 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 		}
 		rc = mutex_lock_killable(&instance->state->mutex);
 		if (rc) {
-			vchiq_log_error(instance->state->dev, VCHIQ_ARM,
-					"vchiq: connect: could not lock mutex for state %d: %d",
-					instance->state->id, rc);
+			dev_err(instance->state->dev,
+				"arm: vchiq: connect: could not lock mutex for state %d: %d\n",
+				instance->state->id, rc);
 			ret = -EINTR;
 			break;
 		}
@@ -630,8 +630,8 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 		if (!status)
 			instance->connected = 1;
 		else
-			vchiq_log_error(instance->state->dev, VCHIQ_ARM,
-					"vchiq: could not connect: %d", status);
+			dev_err(instance->state->dev,
+				"arm: vchiq: could not connect: %d\n", status);
 		break;
 
 	case VCHIQ_IOC_CREATE_SERVICE: {
@@ -700,13 +700,13 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 				vchiq_use_service_internal(service) :
 				vchiq_release_service_internal(service);
 			if (ret) {
-				vchiq_log_error(instance->state->dev, VCHIQ_SUSPEND,
-						"%s: cmd %s returned error %ld for service %p4cc:%03d",
-						__func__, (cmd == VCHIQ_IOC_USE_SERVICE) ?
-						"VCHIQ_IOC_USE_SERVICE" :
-						"VCHIQ_IOC_RELEASE_SERVICE",
-						ret, &service->base.fourcc,
-						service->client_id);
+				dev_err(instance->state->dev,
+					"suspend: cmd %s returned error %ld for service %p4cc:%03d\n",
+					(cmd == VCHIQ_IOC_USE_SERVICE) ?
+					"VCHIQ_IOC_USE_SERVICE" :
+					"VCHIQ_IOC_RELEASE_SERVICE",
+					ret, &service->base.fourcc,
+					service->client_id);
 			}
 		} else {
 			ret = -EINVAL;
@@ -1173,8 +1173,7 @@ static int vchiq_open(struct inode *inode, struct file *file)
 	vchiq_log_debug(state->dev, VCHIQ_ARM, "vchiq_open");
 
 	if (!state) {
-		vchiq_log_error(state->dev, VCHIQ_ARM,
-				"vchiq has no connection to VideoCore");
+		dev_err(state->dev, "arm: vchiq has no connection to VideoCore\n");
 		return -ENOTCONN;
 	}
 
-- 
2.41.0



From umang.jain at ideasonboard.com  Tue Dec  5 00:41:55 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Tue,  5 Dec 2023 14:11:55 +0530
Subject: [PATCH v3 2/4] staging: vc04_services: Drop vchiq_log_warning() in favour of dev_warn
In-Reply-To: <20231205084157.73819-1-umang.jain@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
Message-ID: <20231205084157.73819-3-umang.jain@ideasonboard.com>

Drop vchiq_log_warning() macro which wraps dev_dbg(). Introduce the usage
of dev_warn() directly.

Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
---
 .../interface/vchiq_arm/vchiq_arm.c           | 30 +++++++++----------
 .../interface/vchiq_arm/vchiq_core.c          | 30 +++++++++----------
 .../interface/vchiq_arm/vchiq_core.h          |  4 ---
 3 files changed, 29 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index b403400edd8e..56326b59a718 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -687,8 +687,8 @@ int vchiq_initialise(struct vchiq_instance **instance_out)
 		ret = -ENOTCONN;
 		goto failed;
 	} else if (i > 0) {
-		vchiq_log_warning(state->dev, VCHIQ_CORE,
-				  "%s: videocore initialized after %d retries\n", __func__, i);
+		dev_warn(state->dev, "core: %s: videocore initialized after %d retries\n",
+			 __func__, i);
 	}
 
 	instance = kzalloc(sizeof(*instance), GFP_KERNEL);
@@ -1644,20 +1644,19 @@ vchiq_dump_service_use_state(struct vchiq_state *state)
 	read_unlock_bh(&arm_state->susp_res_lock);
 
 	if (only_nonzero)
-		vchiq_log_warning(state->dev, VCHIQ_SUSPEND,
-				  "Too many active services (%d). Only dumping up to first %d services with non-zero use-count",
-				  active_services, found);
+		dev_warn(state->dev,
+			 "suspend: Too many active services (%d). Only dumping up to first %d services with non-zero use-count\n",
+			 active_services, found);
 
 	for (i = 0; i < found; i++) {
-		vchiq_log_warning(state->dev, VCHIQ_SUSPEND,
-				  "%p4cc:%d service count %d %s",
-				  &service_data[i].fourcc,
-				  service_data[i].clientid, service_data[i].use_count,
-				  service_data[i].use_count ? nz : "");
+		dev_warn(state->dev,
+			 "suspend: %p4cc:%d service count %d %s\n",
+			 &service_data[i].fourcc,
+			 service_data[i].clientid, service_data[i].use_count,
+			 service_data[i].use_count ? nz : "");
 	}
-	vchiq_log_warning(state->dev, VCHIQ_SUSPEND, "VCHIQ use count %d", peer_count);
-	vchiq_log_warning(state->dev, VCHIQ_SUSPEND, "Overall vchiq instance use count %d",
-			  vc_use_count);
+	dev_warn(state->dev, "suspend: VCHIQ use count %d\n", peer_count);
+	dev_warn(state->dev, "suspend: Overall vchiq instance use count %d\n", vc_use_count);
 
 	kfree(service_data);
 }
@@ -1771,8 +1770,7 @@ static int vchiq_probe(struct platform_device *pdev)
 	 */
 	err = vchiq_register_chrdev(&pdev->dev);
 	if (err) {
-		vchiq_log_warning(&pdev->dev, VCHIQ_ARM,
-				  "Failed to initialize vchiq cdev");
+		dev_warn(&pdev->dev, "arm: Failed to initialize vchiq cdev\n");
 		goto error_exit;
 	}
 
@@ -1782,7 +1780,7 @@ static int vchiq_probe(struct platform_device *pdev)
 	return 0;
 
 failed_platform_init:
-	vchiq_log_warning(&pdev->dev, VCHIQ_ARM, "could not initialize vchiq platform");
+	dev_warn(&pdev->dev, "arm: Could not initialize vchiq platform\n");
 error_exit:
 	return err;
 }
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 63f412815a32..2fd793954001 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -465,9 +465,9 @@ make_service_callback(struct vchiq_service *service, enum vchiq_reason reason,
 	status = service->base.callback(service->instance, reason, header, service->handle,
 					bulk_userdata);
 	if (status && (status != -EAGAIN)) {
-		vchiq_log_warning(service->state->dev, VCHIQ_CORE,
-				  "%d: ignoring ERROR from callback to service %x",
-				  service->state->id, service->handle);
+		dev_warn(service->state->dev,
+			 "core: %d: ignoring ERROR from callback to service %x\n",
+			 service->state->id, service->handle);
 		status = 0;
 	}
 
@@ -1609,10 +1609,10 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 				vchiq_service_put(service);
 			service = get_connected_service(state, remoteport);
 			if (service)
-				vchiq_log_warning(state->dev, VCHIQ_CORE,
-						  "%d: prs %s@%pK (%d->%d) - found connected service %d",
-						  state->id, msg_type_str(type), header,
-						  remoteport, localport, service->localport);
+				dev_warn(state->dev,
+					 "core: %d: prs %s@%pK (%d->%d) - found connected service %d\n",
+					 state->id, msg_type_str(type), header,
+					 remoteport, localport, service->localport);
 		}
 
 		if (!service) {
@@ -2903,10 +2903,10 @@ vchiq_close_service(struct vchiq_instance *instance, unsigned int handle)
 		    (service->srvstate == VCHIQ_SRVSTATE_OPEN))
 			break;
 
-		vchiq_log_warning(service->state->dev, VCHIQ_CORE,
-				  "%d: close_service:%d - waiting in state %s",
-				  service->state->id, service->localport,
-				  srvstate_names[service->srvstate]);
+		dev_warn(service->state->dev,
+			 "core: %d: close_service:%d - waiting in state %s\n",
+			 service->state->id, service->localport,
+			 srvstate_names[service->srvstate]);
 	}
 
 	if (!status &&
@@ -2964,10 +2964,10 @@ vchiq_remove_service(struct vchiq_instance *instance, unsigned int handle)
 		    (service->srvstate == VCHIQ_SRVSTATE_OPEN))
 			break;
 
-		vchiq_log_warning(service->state->dev, VCHIQ_CORE,
-				  "%d: remove_service:%d - waiting in state %s",
-				  service->state->id, service->localport,
-				  srvstate_names[service->srvstate]);
+		dev_warn(service->state->dev,
+			 "core: %d: remove_service:%d - waiting in state %s\n",
+			 service->state->id, service->localport,
+			 srvstate_names[service->srvstate]);
 	}
 
 	if (!status && (service->srvstate != VCHIQ_SRVSTATE_FREE))
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
index d7dcd17e4bff..bc980a001711 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
@@ -53,10 +53,6 @@ static inline const char *log_category_str(enum vchiq_log_category c)
 	return strings[c];
 };
 
-#ifndef vchiq_log_warning
-#define vchiq_log_warning(dev, cat, fmt, ...) \
-	do { dev_dbg(dev, "%s warning: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
-#endif
 #ifndef vchiq_log_debug
 #define vchiq_log_debug(dev, cat, fmt, ...) \
 	do { dev_dbg(dev, "%s debug: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
-- 
2.41.0



From umang.jain at ideasonboard.com  Tue Dec  5 00:41:56 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Tue,  5 Dec 2023 14:11:56 +0530
Subject: [PATCH v3 3/4] staging: vc04_services: Drop vchiq_log_trace() in favour of dev_dbg
In-Reply-To: <20231205084157.73819-1-umang.jain@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
Message-ID: <20231205084157.73819-4-umang.jain@ideasonboard.com>

Drop vchiq_log_trace() macro which wraps dev_dbg(). Introduce the usage
of dev_dbg() directly.

Meanwhile at it, drop the usage of __func__ from the logs.
Dynamic debug supports this via the 'f'  decorator flag.

Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
---
 .../interface/vchiq_arm/vchiq_arm.c           |  53 ++++-----
 .../interface/vchiq_arm/vchiq_core.c          | 101 +++++++++---------
 .../interface/vchiq_arm/vchiq_core.h          |   4 -
 .../interface/vchiq_arm/vchiq_dev.c           |  15 ++-
 4 files changed, 78 insertions(+), 95 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 56326b59a718..e337b8387647 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -255,8 +255,7 @@ create_pagelist(struct vchiq_instance *instance, char *buf, char __user *ubuf,
 	pagelist = dma_alloc_coherent(instance->state->dev, pagelist_size, &dma_addr,
 				      GFP_KERNEL);
 
-	vchiq_log_trace(instance->state->dev, VCHIQ_ARM,
-			"%s - %pK", __func__, pagelist);
+	dev_dbg(instance->state->dev, "arm: %pK\n", pagelist);
 
 	if (!pagelist)
 		return NULL;
@@ -407,8 +406,7 @@ free_pagelist(struct vchiq_instance *instance, struct vchiq_pagelist_info *pagel
 	struct page **pages = pagelistinfo->pages;
 	unsigned int num_pages = pagelistinfo->num_pages;
 
-	vchiq_log_trace(instance->state->dev, VCHIQ_ARM,
-			"%s - %pK, %d", __func__, pagelistinfo->pagelist, actual);
+	dev_dbg(instance->state->dev, "arm: %pK, %d\n", pagelistinfo->pagelist, actual);
 
 	/*
 	 * NOTE: dma_unmap_sg must be called before the
@@ -708,8 +706,7 @@ int vchiq_initialise(struct vchiq_instance **instance_out)
 	ret = 0;
 
 failed:
-	vchiq_log_trace(state->dev, VCHIQ_CORE,
-			"%s(%p): returning %d", __func__, instance, ret);
+	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, ret);
 
 	return ret;
 }
@@ -742,8 +739,7 @@ int vchiq_shutdown(struct vchiq_instance *instance)
 
 	mutex_unlock(&state->mutex);
 
-	vchiq_log_trace(state->dev, VCHIQ_CORE,
-			"%s(%p): returning %d", __func__, instance, status);
+	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, status);
 
 	free_bulk_waiter(instance);
 	kfree(instance);
@@ -763,8 +759,8 @@ int vchiq_connect(struct vchiq_instance *instance)
 	struct vchiq_state *state = instance->state;
 
 	if (mutex_lock_killable(&state->mutex)) {
-		vchiq_log_trace(state->dev, VCHIQ_CORE,
-				"%s: call to mutex_lock failed", __func__);
+		dev_dbg(state->dev,
+			"core: call to mutex_lock failed\n");
 		status = -EAGAIN;
 		goto failed;
 	}
@@ -776,8 +772,7 @@ int vchiq_connect(struct vchiq_instance *instance)
 	mutex_unlock(&state->mutex);
 
 failed:
-	vchiq_log_trace(state->dev, VCHIQ_CORE,
-			"%s(%p): returning %d", __func__, instance, status);
+	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, status);
 
 	return status;
 }
@@ -808,8 +803,7 @@ vchiq_add_service(struct vchiq_instance *instance,
 		status = -EINVAL;
 	}
 
-	vchiq_log_trace(state->dev, VCHIQ_CORE,
-			"%s(%p): returning %d", __func__, instance, status);
+	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, status);
 
 	return status;
 }
@@ -840,8 +834,7 @@ vchiq_open_service(struct vchiq_instance *instance,
 	}
 
 failed:
-	vchiq_log_trace(state->dev, VCHIQ_CORE,
-			"%s(%p): returning %d", __func__, instance, status);
+	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, status);
 
 	return status;
 }
@@ -1010,8 +1003,7 @@ add_completion(struct vchiq_instance *instance, enum vchiq_reason reason,
 	while ((insert - instance->completion_remove) >= MAX_COMPLETIONS) {
 		/* Out of space - wait for the client */
 		DEBUG_TRACE(SERVICE_CALLBACK_LINE);
-		vchiq_log_trace(instance->state->dev, VCHIQ_CORE,
-				"%s - completion queue full", __func__);
+		dev_dbg(instance->state->dev, "core: completion queue full\n");
 		DEBUG_COUNT(COMPLETION_QUEUE_FULL_COUNT);
 		if (wait_for_completion_interruptible(&instance->remove_event)) {
 			vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
@@ -1099,11 +1091,11 @@ service_callback(struct vchiq_instance *instance, enum vchiq_reason reason,
 	vchiq_service_get(service);
 	rcu_read_unlock();
 
-	vchiq_log_trace(service->state->dev, VCHIQ_ARM,
-			"%s - service %lx(%d,%p), reason %d, header %lx, instance %lx, bulk_userdata %lx",
-			__func__, (unsigned long)user_service, service->localport,
-			user_service->userdata, reason, (unsigned long)header,
-			(unsigned long)instance, (unsigned long)bulk_userdata);
+	dev_dbg(service->state->dev,
+		"arm: service %lx(%d,%p), reason %d, header %lx, instance %lx, bulk_userdata %lx\n",
+		(unsigned long)user_service, service->localport,
+		user_service->userdata, reason, (unsigned long)header,
+		(unsigned long)instance, (unsigned long)bulk_userdata);
 
 	if (header && user_service->is_vchi) {
 		spin_lock(&msg_queue_spinlock);
@@ -1112,8 +1104,7 @@ service_callback(struct vchiq_instance *instance, enum vchiq_reason reason,
 			spin_unlock(&msg_queue_spinlock);
 			DEBUG_TRACE(SERVICE_CALLBACK_LINE);
 			DEBUG_COUNT(MSG_QUEUE_FULL_COUNT);
-			vchiq_log_trace(service->state->dev, VCHIQ_ARM,
-					"%s - msg queue full", __func__);
+			dev_dbg(service->state->dev, "arm: msg queue full\n");
 			/*
 			 * If there is no MESSAGE_AVAILABLE in the completion
 			 * queue, add one
@@ -1405,8 +1396,8 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
 	local_uc = ++arm_state->videocore_use_count;
 	++(*entity_uc);
 
-	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s %s count %d, state count %d",
-			__func__, entity, *entity_uc, local_uc);
+	dev_dbg(state->dev, "suspend: %s count %d, state count %d\n",
+		entity, *entity_uc, local_uc);
 
 	write_unlock_bh(&arm_state->susp_res_lock);
 
@@ -1425,7 +1416,7 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
 	}
 
 out:
-	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s exit %d", __func__, ret);
+	dev_dbg(state->dev, "suspend: exit %d\n", ret);
 	return ret;
 }
 
@@ -1463,14 +1454,14 @@ vchiq_release_internal(struct vchiq_state *state, struct vchiq_service *service)
 	--arm_state->videocore_use_count;
 	--(*entity_uc);
 
-	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s %s count %d, state count %d",
-			__func__, entity, *entity_uc, arm_state->videocore_use_count);
+	dev_dbg(state->dev, "suspend: %s count %d, state count %d\n",
+		entity, *entity_uc, arm_state->videocore_use_count);
 
 unlock:
 	write_unlock_bh(&arm_state->susp_res_lock);
 
 out:
-	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s exit %d", __func__, ret);
+	dev_dbg(state->dev, "suspend: exit %d\n", ret);
 	return ret;
 }
 
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 2fd793954001..d197e4504bd4 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -459,9 +459,9 @@ make_service_callback(struct vchiq_service *service, enum vchiq_reason reason,
 {
 	int status;
 
-	vchiq_log_trace(service->state->dev, VCHIQ_CORE, "%d: callback:%d (%s, %pK, %pK)",
-			service->state->id, service->localport, reason_names[reason],
-			header, bulk_userdata);
+	dev_dbg(service->state->dev, "core: %d: callback:%d (%s, %pK, %pK)\n",
+		service->state->id, service->localport, reason_names[reason],
+		header, bulk_userdata);
 	status = service->base.callback(service->instance, reason, header, service->handle,
 					bulk_userdata);
 	if (status && (status != -EAGAIN)) {
@@ -763,8 +763,8 @@ process_free_data_message(struct vchiq_state *state, u32 *service_found,
 			 * it has dropped below its quota
 			 */
 			complete(&quota->quota_event);
-			vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: pfq:%d %x@%pK - slot_use->%d",
-					state->id, port, header->size, header, count - 1);
+			dev_dbg(state->dev, "core: %d: pfq:%d %x@%pK - slot_use->%d\n",
+				state->id, port, header->size, header, count - 1);
 		} else {
 			dev_err(state->dev,
 				"core: service %d slot_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)\n",
@@ -809,9 +809,9 @@ process_free_queue(struct vchiq_state *state, u32 *service_found,
 		 */
 		rmb();
 
-		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: pfq %d=%pK %x %x",
-				state->id, slot_index, data, local->slot_queue_recycle,
-				slot_queue_available);
+		dev_dbg(state->dev, "core: %d: pfq %d=%pK %x %x\n",
+			state->id, slot_index, data, local->slot_queue_recycle,
+			slot_queue_available);
 
 		/* Initialise the bitmask for services which have used this slot */
 		memset(service_found, 0, length);
@@ -980,10 +980,10 @@ queue_message(struct vchiq_state *state, struct vchiq_service *service,
 		       ((tx_end_index != quota->previous_tx_index) &&
 			(quota->slot_use_count == quota->slot_quota))) {
 			spin_unlock(&quota_spinlock);
-			vchiq_log_trace(state->dev, VCHIQ_CORE,
-					"%d: qm:%d %s,%zx - quota stall (msg %d, slot %d)",
-					state->id, service->localport, msg_type_str(type), size,
-					quota->message_use_count, quota->slot_use_count);
+			dev_dbg(state->dev,
+				"core: %d: qm:%d %s,%zx - quota stall (msg %d, slot %d)\n",
+				state->id, service->localport, msg_type_str(type), size,
+				quota->message_use_count, quota->slot_use_count);
 			VCHIQ_SERVICE_STATS_INC(service, quota_stalls);
 			mutex_unlock(&state->slot_mutex);
 			if (wait_for_completion_interruptible(&quota->quota_event))
@@ -1073,10 +1073,9 @@ queue_message(struct vchiq_state *state, struct vchiq_service *service,
 		spin_unlock(&quota_spinlock);
 
 		if (slot_use_count)
-			vchiq_log_trace(state->dev, VCHIQ_CORE,
-					"%d: qm:%d %s,%zx - slot_use->%d (hdr %p)", state->id,
-					service->localport, msg_type_str(VCHIQ_MSG_TYPE(msgid)),
-					size, slot_use_count, header);
+			dev_dbg(state->dev, "core: %d: qm:%d %s,%zx - slot_use->%d (hdr %p)\n",
+				state->id, service->localport, msg_type_str(VCHIQ_MSG_TYPE(msgid)),
+				size, slot_use_count, header);
 
 		VCHIQ_SERVICE_STATS_INC(service, ctrl_tx_count);
 		VCHIQ_SERVICE_STATS_ADD(service, ctrl_tx_bytes, size);
@@ -1205,11 +1204,11 @@ queue_message_sync(struct vchiq_state *state, struct vchiq_service *service,
 	svc_fourcc = service ? service->base.fourcc
 			     : VCHIQ_MAKE_FOURCC('?', '?', '?', '?');
 
-	vchiq_log_trace(state->dev, VCHIQ_SYNC,
-			"Sent Sync Msg %s(%u) to %p4cc s:%u d:%d len:%d",
-			msg_type_str(VCHIQ_MSG_TYPE(msgid)), VCHIQ_MSG_TYPE(msgid),
-			&svc_fourcc, VCHIQ_MSG_SRCPORT(msgid),
-			VCHIQ_MSG_DSTPORT(msgid), size);
+	dev_dbg(state->dev,
+		"sync: Sent Sync Msg %s(%u) to %p4cc s:%u d:%d len:%d\n",
+		msg_type_str(VCHIQ_MSG_TYPE(msgid)), VCHIQ_MSG_TYPE(msgid),
+		&svc_fourcc, VCHIQ_MSG_SRCPORT(msgid),
+		VCHIQ_MSG_DSTPORT(msgid), size);
 
 	remote_event_signal(&state->remote->sync_trigger);
 
@@ -1298,11 +1297,11 @@ notify_bulks(struct vchiq_service *service, struct vchiq_bulk_queue *queue,
 {
 	int status = 0;
 
-	vchiq_log_trace(service->state->dev, VCHIQ_CORE,
-			"%d: nb:%d %cx - p=%x rn=%x r=%x",
-			service->state->id, service->localport,
-			(queue == &service->bulk_tx) ? 't' : 'r',
-			queue->process, queue->remote_notify, queue->remove);
+	dev_dbg(service->state->dev,
+		"core: %d: nb:%d %cx - p=%x rn=%x r=%x\n",
+		service->state->id, service->localport,
+		(queue == &service->bulk_tx) ? 't' : 'r',
+		queue->process, queue->remote_notify, queue->remove);
 
 	queue->remote_notify = queue->process;
 
@@ -1425,11 +1424,11 @@ abort_outstanding_bulks(struct vchiq_service *service,
 {
 	int is_tx = (queue == &service->bulk_tx);
 
-	vchiq_log_trace(service->state->dev, VCHIQ_CORE,
-			"%d: aob:%d %cx - li=%x ri=%x p=%x",
-			service->state->id, service->localport,
-			is_tx ? 't' : 'r', queue->local_insert,
-			queue->remote_insert, queue->process);
+	dev_dbg(service->state->dev,
+		"core: %d: aob:%d %cx - li=%x ri=%x p=%x\n",
+		service->state->id, service->localport,
+		is_tx ? 't' : 'r', queue->local_insert,
+		queue->remote_insert, queue->process);
 
 	WARN_ON((int)(queue->local_insert - queue->process) < 0);
 	WARN_ON((int)(queue->remote_insert - queue->process) < 0);
@@ -1764,10 +1763,10 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 					state->id, msg_type_str(type), header, remoteport,
 					localport, bulk->actual, &bulk->data);
 
-			vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs:%d %cx li=%x ri=%x p=%x",
-					state->id, localport,
-					(type == VCHIQ_MSG_BULK_RX_DONE) ? 'r' : 't',
-					queue->local_insert, queue->remote_insert, queue->process);
+			dev_dbg(state->dev, "core: %d: prs:%d %cx li=%x ri=%x p=%x\n",
+				state->id, localport,
+				(type == VCHIQ_MSG_BULK_RX_DONE) ? 'r' : 't',
+				queue->local_insert, queue->remote_insert, queue->process);
 
 			DEBUG_TRACE(PARSE_LINE);
 			WARN_ON(queue->process == queue->local_insert);
@@ -1780,13 +1779,13 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 		}
 		break;
 	case VCHIQ_MSG_PADDING:
-		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs PADDING@%pK,%x",
-				state->id, header, size);
+		dev_dbg(state->dev, "core: %d: prs PADDING@%pK,%x\n",
+			state->id, header, size);
 		break;
 	case VCHIQ_MSG_PAUSE:
 		/* If initiated, signal the application thread */
-		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs PAUSE@%pK,%x",
-				state->id, header, size);
+		dev_dbg(state->dev, "core: %d: prs PAUSE@%pK,%x\n",
+			state->id, header, size);
 		if (state->conn_state == VCHIQ_CONNSTATE_PAUSED) {
 			dev_err(state->dev, "core: %d: PAUSE received in state PAUSED\n",
 				state->id);
@@ -1802,8 +1801,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 		vchiq_set_conn_state(state, VCHIQ_CONNSTATE_PAUSED);
 		break;
 	case VCHIQ_MSG_RESUME:
-		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs RESUME@%pK,%x",
-				state->id, header, size);
+		dev_dbg(state->dev, "core: %d: prs RESUME@%pK,%x\n",
+			state->id, header, size);
 		/* Release the slot mutex */
 		mutex_unlock(&state->slot_mutex);
 		vchiq_set_conn_state(state, VCHIQ_CONNSTATE_CONNECTED);
@@ -2040,10 +2039,8 @@ sync_func(void *v)
 
 		svc_fourcc = service->base.fourcc;
 
-		vchiq_log_trace(state->dev, VCHIQ_SYNC,
-				"Rcvd Msg %s from %p4cc s:%d d:%d len:%d",
-				msg_type_str(type), &svc_fourcc,
-				remoteport, localport, size);
+		dev_dbg(state->dev, "sync: Rcvd Msg %s from %p4cc s:%d d:%d len:%d\n",
+			msg_type_str(type), &svc_fourcc, remoteport, localport, size);
 		if (size > 0)
 			vchiq_log_dump_mem(state->dev, "Rcvd", 0, header->data, min(16, size));
 
@@ -2068,8 +2065,8 @@ sync_func(void *v)
 			break;
 
 		case VCHIQ_MSG_DATA:
-			vchiq_log_trace(state->dev, VCHIQ_SYNC, "%d: sf DATA@%pK,%x (%d->%d)",
-					state->id, header, size, remoteport, localport);
+			dev_dbg(state->dev, "sync: %d: sf DATA@%pK,%x (%d->%d)\n",
+				state->id, header, size, remoteport, localport);
 
 			if ((service->remoteport == remoteport) &&
 			    (service->srvstate == VCHIQ_SRVSTATE_OPENSYNC)) {
@@ -3111,9 +3108,9 @@ int vchiq_bulk_transfer(struct vchiq_instance *instance, unsigned int handle,
 	mutex_unlock(&state->slot_mutex);
 	mutex_unlock(&service->bulk_mutex);
 
-	vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: bt:%d %cx li=%x ri=%x p=%x",
-			state->id, service->localport, dir_char, queue->local_insert,
-			queue->remote_insert, queue->process);
+	dev_dbg(state->dev, "core: %d: bt:%d %cx li=%x ri=%x p=%x\n",
+		state->id, service->localport, dir_char, queue->local_insert,
+		queue->remote_insert, queue->process);
 
 waiting:
 	vchiq_service_put(service);
@@ -3579,9 +3576,9 @@ void vchiq_log_dump_mem(struct device *dev, const char *label, u32 addr,
 		*s++ = '\0';
 
 		if (label && (*label != '\0'))
-			vchiq_log_trace(dev, VCHIQ_CORE, "%s: %08x: %s", label, addr, line_buf);
+			dev_dbg(dev, "core: %s: %08x: %s\n", label, addr, line_buf);
 		else
-			vchiq_log_trace(dev, VCHIQ_CORE, "%s: %08x: %s", label, addr, line_buf);
+			dev_dbg(dev, "core: %s: %08x: %s\n", label, addr, line_buf);
 
 		addr += 16;
 		mem += 16;
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
index bc980a001711..36e34a7fc628 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
@@ -57,10 +57,6 @@ static inline const char *log_category_str(enum vchiq_log_category c)
 #define vchiq_log_debug(dev, cat, fmt, ...) \
 	do { dev_dbg(dev, "%s debug: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
 #endif
-#ifndef vchiq_log_trace
-#define vchiq_log_trace(dev, cat, fmt, ...) \
-	do { dev_dbg(dev, "%s trace: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
-#endif
 
 #define VCHIQ_SLOT_MASK        (VCHIQ_SLOT_SIZE - 1)
 #define VCHIQ_SLOT_QUEUE_MASK  (VCHIQ_MAX_SLOTS_PER_SIDE - 1)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
index ba287cb4c87b..38841c9d8ef9 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
@@ -582,10 +582,9 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 	long ret = 0;
 	int i, rc;
 
-	vchiq_log_trace(instance->state->dev, VCHIQ_ARM,
-			"%s - instance %pK, cmd %s, arg %lx", __func__, instance,
-			((_IOC_TYPE(cmd) == VCHIQ_IOC_MAGIC) && (_IOC_NR(cmd) <= VCHIQ_IOC_MAX)) ?
-			ioctl_names[_IOC_NR(cmd)] : "<invalid>", arg);
+	dev_dbg(instance->state->dev, "arm: instance %pK, cmd %s, arg %lx\n", instance,
+		((_IOC_TYPE(cmd) == VCHIQ_IOC_MAGIC) && (_IOC_NR(cmd) <= VCHIQ_IOC_MAX)) ?
+		ioctl_names[_IOC_NR(cmd)] : "<invalid>", arg);
 
 	switch (cmd) {
 	case VCHIQ_IOC_SHUTDOWN:
@@ -873,10 +872,10 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 				instance, (_IOC_NR(cmd) <= VCHIQ_IOC_MAX) ?
 				ioctl_names[_IOC_NR(cmd)] : "<invalid>", status, ret);
 	} else {
-		vchiq_log_trace(instance->state->dev, VCHIQ_ARM,
-				"  ioctl instance %pK, cmd %s -> status %d, %ld",
-				instance, (_IOC_NR(cmd) <= VCHIQ_IOC_MAX) ?
-				ioctl_names[_IOC_NR(cmd)] : "<invalid>", status, ret);
+		dev_dbg(instance->state->dev,
+			"arm: ioctl instance %pK, cmd %s -> status %d\n, %ld\n",
+			instance, (_IOC_NR(cmd) <= VCHIQ_IOC_MAX) ?
+			ioctl_names[_IOC_NR(cmd)] : "<invalid>", status, ret);
 	}
 
 	return ret;
-- 
2.41.0



From umang.jain at ideasonboard.com  Tue Dec  5 00:41:57 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Tue,  5 Dec 2023 14:11:57 +0530
Subject: [PATCH v3 4/4] staging: vc04_services: Drop vchiq_log_debug() in favour of dev_dbg
In-Reply-To: <20231205084157.73819-1-umang.jain@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
Message-ID: <20231205084157.73819-5-umang.jain@ideasonboard.com>

Drop vchiq_log_debug() macro which wraps dev_dbg(). Introduce the usage
of dev_dbg() directly.

Meanwhile at it, drop the usage of __func__ from the logs.
Dynamic debug supports this via the 'f'  decorator flag.

Remove the entry from TODO regarding custom logging. VC04 is now
aligned according to the standard kernel logging mechanisms.

Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
---
 drivers/staging/vc04_services/interface/TODO  |   5 -
 .../interface/vchiq_arm/vchiq_arm.c           |  45 +++--
 .../interface/vchiq_arm/vchiq_core.c          | 159 ++++++++----------
 .../interface/vchiq_arm/vchiq_core.h          |  26 ---
 .../interface/vchiq_arm/vchiq_dev.c           |  32 ++--
 5 files changed, 106 insertions(+), 161 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/TODO b/drivers/staging/vc04_services/interface/TODO
index 6d9d4a800aa7..05eb5140d096 100644
--- a/drivers/staging/vc04_services/interface/TODO
+++ b/drivers/staging/vc04_services/interface/TODO
@@ -23,11 +23,6 @@ should properly handle a module unload. This also includes that all
 resources must be freed (kthreads, debugfs entries, ...) and global
 variables avoided.
 
-* Cleanup logging mechanism
-
-The driver should probably be using the standard kernel logging mechanisms
-such as dev_info, dev_dbg, and friends.
-
 * Documentation
 
 A short top-down description of this driver's architecture (function of
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index e337b8387647..4b4ff469d3a3 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -310,9 +310,8 @@ create_pagelist(struct vchiq_instance *instance, char *buf, char __user *ubuf,
 						   type == PAGELIST_READ, pages);
 
 		if (actual_pages != num_pages) {
-			vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-					"%s - only %d/%d pages locked",
-					__func__, actual_pages, num_pages);
+			dev_dbg(instance->state->dev, "arm: Only %d/%d pages locked\n",
+				actual_pages, num_pages);
 
 			/* This is probably due to the process being killed */
 			if (actual_pages > 0)
@@ -554,8 +553,8 @@ static int vchiq_platform_init(struct platform_device *pdev, struct vchiq_state
 		return -ENXIO;
 	}
 
-	vchiq_log_debug(&pdev->dev, VCHIQ_ARM, "vchiq_init - done (slots %pK, phys %pad)",
-			vchiq_slot_zero, &slot_phys);
+	dev_dbg(&pdev->dev, "arm: vchiq_init - done (slots %pK, phys %pad)\n",
+		vchiq_slot_zero, &slot_phys);
 
 	vchiq_call_connected_callbacks();
 
@@ -719,9 +718,9 @@ void free_bulk_waiter(struct vchiq_instance *instance)
 	list_for_each_entry_safe(waiter, next,
 				 &instance->bulk_waiter_list, list) {
 		list_del(&waiter->list);
-		vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-				"bulk_waiter - cleaned up %pK for pid %d",
-				waiter, waiter->pid);
+		dev_dbg(instance->state->dev,
+			"arm: bulk_waiter - cleaned up %pK for pid %d\n",
+			waiter, waiter->pid);
 		kfree(waiter);
 	}
 }
@@ -981,9 +980,8 @@ vchiq_blocking_bulk_transfer(struct vchiq_instance *instance, unsigned int handl
 		mutex_lock(&instance->bulk_waiter_list_mutex);
 		list_add(&waiter->list, &instance->bulk_waiter_list);
 		mutex_unlock(&instance->bulk_waiter_list_mutex);
-		vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-				"saved bulk_waiter %pK for pid %d", waiter,
-				current->pid);
+		dev_dbg(instance->state->dev, "arm: saved bulk_waiter %pK for pid %d\n",
+			waiter, current->pid);
 	}
 
 	return status;
@@ -1006,12 +1004,10 @@ add_completion(struct vchiq_instance *instance, enum vchiq_reason reason,
 		dev_dbg(instance->state->dev, "core: completion queue full\n");
 		DEBUG_COUNT(COMPLETION_QUEUE_FULL_COUNT);
 		if (wait_for_completion_interruptible(&instance->remove_event)) {
-			vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-					"service_callback interrupted");
+			dev_dbg(instance->state->dev, "arm: service_callback interrupted\n");
 			return -EAGAIN;
 		} else if (instance->closing) {
-			vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-					"service_callback closing");
+			dev_dbg(instance->state->dev, "arm: service_callback closing\n");
 			return 0;
 		}
 		DEBUG_TRACE(SERVICE_CALLBACK_LINE);
@@ -1113,8 +1109,8 @@ service_callback(struct vchiq_instance *instance, enum vchiq_reason reason,
 				instance->completion_remove) < 0) {
 				int status;
 
-				vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-						"Inserting extra MESSAGE_AVAILABLE");
+				dev_dbg(instance->state->dev,
+					"arm: Inserting extra MESSAGE_AVAILABLE\n");
 				DEBUG_TRACE(SERVICE_CALLBACK_LINE);
 				status = add_completion(instance, reason, NULL, user_service,
 							bulk_userdata);
@@ -1127,14 +1123,12 @@ service_callback(struct vchiq_instance *instance, enum vchiq_reason reason,
 
 			DEBUG_TRACE(SERVICE_CALLBACK_LINE);
 			if (wait_for_completion_interruptible(&user_service->remove_event)) {
-				vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-						"%s interrupted", __func__);
+				dev_dbg(instance->state->dev, "arm: interrupted\n");
 				DEBUG_TRACE(SERVICE_CALLBACK_LINE);
 				vchiq_service_put(service);
 				return -EAGAIN;
 			} else if (instance->closing) {
-				vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-						"%s closing", __func__);
+				dev_dbg(instance->state->dev, "arm: closing\n");
 				DEBUG_TRACE(SERVICE_CALLBACK_LINE);
 				vchiq_service_put(service);
 				return -EINVAL;
@@ -1686,8 +1680,8 @@ void vchiq_platform_conn_state_changed(struct vchiq_state *state,
 	struct vchiq_arm_state *arm_state = vchiq_platform_get_arm_state(state);
 	char threadname[16];
 
-	vchiq_log_debug(state->dev, VCHIQ_SUSPEND, "%d: %s->%s", state->id,
-			get_conn_state_name(oldstate), get_conn_state_name(newstate));
+	dev_dbg(state->dev, "suspend: %d: %s->%s\n",
+		state->id, get_conn_state_name(oldstate), get_conn_state_name(newstate));
 	if (state->conn_state != VCHIQ_CONNSTATE_CONNECTED)
 		return;
 
@@ -1751,9 +1745,8 @@ static int vchiq_probe(struct platform_device *pdev)
 
 	vchiq_debugfs_init();
 
-	vchiq_log_debug(&pdev->dev, VCHIQ_ARM,
-			"vchiq: platform initialised - version %d (min %d)",
-			VCHIQ_VERSION, VCHIQ_VERSION_MIN);
+	dev_dbg(&pdev->dev, "arm: platform initialised - version %d (min %d)\n",
+		VCHIQ_VERSION, VCHIQ_VERSION_MIN);
 
 	/*
 	 * Simply exit on error since the function handles cleanup in
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index d197e4504bd4..76c27778154a 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -217,10 +217,10 @@ static const char *msg_type_str(unsigned int msg_type)
 static inline void
 set_service_state(struct vchiq_service *service, int newstate)
 {
-	vchiq_log_debug(service->state->dev, VCHIQ_CORE, "%d: srv:%d %s->%s",
-			service->state->id, service->localport,
-			srvstate_names[service->srvstate],
-			srvstate_names[newstate]);
+	dev_dbg(service->state->dev, "core: %d: srv:%d %s->%s\n",
+		service->state->id, service->localport,
+		srvstate_names[service->srvstate],
+		srvstate_names[newstate]);
 	service->srvstate = newstate;
 }
 
@@ -245,8 +245,7 @@ find_service_by_handle(struct vchiq_instance *instance, unsigned int handle)
 		return service;
 	}
 	rcu_read_unlock();
-	vchiq_log_debug(instance->state->dev, VCHIQ_CORE,
-			"Invalid service handle 0x%x", handle);
+	dev_dbg(instance->state->dev, "core: Invalid service handle 0x%x\n", handle);
 	return NULL;
 }
 
@@ -266,8 +265,7 @@ find_service_by_port(struct vchiq_state *state, unsigned int localport)
 		}
 		rcu_read_unlock();
 	}
-	vchiq_log_debug(state->dev, VCHIQ_CORE,
-			"Invalid port %u", localport);
+	dev_dbg(state->dev, "core: Invalid port %u\n", localport);
 	return NULL;
 }
 
@@ -287,8 +285,7 @@ find_service_for_instance(struct vchiq_instance *instance, unsigned int handle)
 		return service;
 	}
 	rcu_read_unlock();
-	vchiq_log_debug(instance->state->dev, VCHIQ_CORE,
-			"Invalid service handle 0x%x", handle);
+	dev_dbg(instance->state->dev, "core: Invalid service handle 0x%x\n", handle);
 	return NULL;
 }
 
@@ -310,8 +307,7 @@ find_closed_service_for_instance(struct vchiq_instance *instance, unsigned int h
 		return service;
 	}
 	rcu_read_unlock();
-	vchiq_log_debug(instance->state->dev, VCHIQ_CORE,
-			"Invalid service handle 0x%x", handle);
+	dev_dbg(instance->state->dev, "core: Invalid service handle 0x%x\n", handle);
 	return service;
 }
 
@@ -482,8 +478,8 @@ vchiq_set_conn_state(struct vchiq_state *state, enum vchiq_connstate newstate)
 {
 	enum vchiq_connstate oldstate = state->conn_state;
 
-	vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: %s->%s", state->id, conn_state_names[oldstate],
-			conn_state_names[newstate]);
+	dev_dbg(state->dev, "core: %d: %s->%s\n",
+		state->id, conn_state_names[oldstate], conn_state_names[newstate]);
 	state->conn_state = newstate;
 	vchiq_platform_conn_state_changed(state, oldstate, newstate);
 }
@@ -1023,9 +1019,9 @@ queue_message(struct vchiq_state *state, struct vchiq_service *service,
 		int tx_end_index;
 		int slot_use_count;
 
-		vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: qm %s@%pK,%zx (%d->%d)", state->id,
-				msg_type_str(VCHIQ_MSG_TYPE(msgid)), header, size,
-				VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid));
+		dev_dbg(state->dev, "core: %d: qm %s@%pK,%zx (%d->%d)\n",
+			state->id, msg_type_str(VCHIQ_MSG_TYPE(msgid)), header, size,
+			VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid));
 
 		WARN_ON(flags & (QMFLAGS_NO_MUTEX_LOCK |
 				 QMFLAGS_NO_MUTEX_UNLOCK));
@@ -1080,9 +1076,9 @@ queue_message(struct vchiq_state *state, struct vchiq_service *service,
 		VCHIQ_SERVICE_STATS_INC(service, ctrl_tx_count);
 		VCHIQ_SERVICE_STATS_ADD(service, ctrl_tx_bytes, size);
 	} else {
-		vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: qm %s@%pK,%zx (%d->%d)", state->id,
-				msg_type_str(VCHIQ_MSG_TYPE(msgid)), header, size,
-				VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid));
+		dev_dbg(state->dev, "core: %d: qm %s@%pK,%zx (%d->%d)\n",
+			state->id, msg_type_str(VCHIQ_MSG_TYPE(msgid)), header, size,
+			VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid));
 		if (size != 0) {
 			/*
 			 * It is assumed for now that this code path
@@ -1110,11 +1106,9 @@ queue_message(struct vchiq_state *state, struct vchiq_service *service,
 			? service->base.fourcc
 			: VCHIQ_MAKE_FOURCC('?', '?', '?', '?');
 
-		vchiq_log_debug(state->dev, VCHIQ_CORE_MSG,
-				"Sent Msg %s(%u) to %p4cc s:%u d:%d len:%zu",
-				msg_type_str(VCHIQ_MSG_TYPE(msgid)), VCHIQ_MSG_TYPE(msgid),
-				&svc_fourcc, VCHIQ_MSG_SRCPORT(msgid),
-				VCHIQ_MSG_DSTPORT(msgid), size);
+		dev_dbg(state->dev, "core_msg: Sent Msg %s(%u) to %p4cc s:%u d:%d len:%zu\n",
+			msg_type_str(VCHIQ_MSG_TYPE(msgid)), VCHIQ_MSG_TYPE(msgid),
+			&svc_fourcc, VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid), size);
 	}
 
 	/* Make sure the new header is visible to the peer. */
@@ -1170,11 +1164,9 @@ queue_message_sync(struct vchiq_state *state, struct vchiq_service *service,
 				state->id, oldmsgid);
 	}
 
-	vchiq_log_debug(state->dev, VCHIQ_SYNC,
-			"%d: qms %s@%pK,%x (%d->%d)", state->id,
-			msg_type_str(VCHIQ_MSG_TYPE(msgid)),
-			header, size, VCHIQ_MSG_SRCPORT(msgid),
-			VCHIQ_MSG_DSTPORT(msgid));
+	dev_dbg(state->dev, "sync: %d: qms %s@%pK,%x (%d->%d)\n",
+		state->id, msg_type_str(VCHIQ_MSG_TYPE(msgid)), header, size,
+		VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid));
 
 	callback_result =
 		copy_message_data(copy_callback, context,
@@ -1260,9 +1252,9 @@ release_slot(struct vchiq_state *state, struct vchiq_slot_info *slot_info,
 			VCHIQ_SLOT_QUEUE_MASK] =
 			SLOT_INDEX_FROM_INFO(state, slot_info);
 		state->remote->slot_queue_recycle = slot_queue_recycle + 1;
-		vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: %s %d - recycle->%x",
-				state->id, __func__, SLOT_INDEX_FROM_INFO(state, slot_info),
-				state->remote->slot_queue_recycle);
+		dev_dbg(state->dev, "core: %d: %d - recycle->%x\n",
+			state->id, SLOT_INDEX_FROM_INFO(state, slot_info),
+			state->remote->slot_queue_recycle);
 
 		/*
 		 * A write barrier is necessary, but remote_event_signal
@@ -1381,8 +1373,8 @@ poll_services_of_group(struct vchiq_state *state, int group)
 
 		service_flags = atomic_xchg(&service->poll_flags, 0);
 		if (service_flags & BIT(VCHIQ_POLL_REMOVE)) {
-			vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: ps - remove %d<->%d",
-					state->id, service->localport, service->remoteport);
+			dev_dbg(state->dev, "core: %d: ps - remove %d<->%d\n",
+				state->id, service->localport, service->remoteport);
 
 			/*
 			 * Make it look like a client, because
@@ -1394,8 +1386,8 @@ poll_services_of_group(struct vchiq_state *state, int group)
 			if (vchiq_close_service_internal(service, NO_CLOSE_RECVD))
 				request_poll(state, service, VCHIQ_POLL_REMOVE);
 		} else if (service_flags & BIT(VCHIQ_POLL_TERMINATE)) {
-			vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: ps - terminate %d<->%d",
-					state->id, service->localport, service->remoteport);
+			dev_dbg(state->dev, "core: %d: ps - terminate %d<->%d\n",
+				state->id, service->localport, service->remoteport);
 			if (vchiq_close_service_internal(service, NO_CLOSE_RECVD))
 				request_poll(state, service, VCHIQ_POLL_TERMINATE);
 		}
@@ -1447,11 +1439,11 @@ abort_outstanding_bulks(struct vchiq_service *service,
 		if (queue->process != queue->local_insert) {
 			vchiq_complete_bulk(service->instance, bulk);
 
-			vchiq_log_debug(service->state->dev, VCHIQ_CORE_MSG,
-					"%s %p4cc d:%d ABORTED - tx len:%d, rx len:%d",
-					is_tx ? "Send Bulk to" : "Recv Bulk from",
-					&service->base.fourcc,
-					service->remoteport, bulk->size, bulk->remote_size);
+			dev_dbg(service->state->dev,
+				"core_msg: %s %p4cc d:%d ABORTED - tx len:%d, rx len:%d\n",
+				is_tx ? "Send Bulk to" : "Recv Bulk from",
+				&service->base.fourcc,
+				service->remoteport, bulk->size, bulk->remote_size);
 		} else {
 			/* fabricate a matching dummy bulk */
 			bulk->data = 0;
@@ -1484,8 +1476,8 @@ parse_open(struct vchiq_state *state, struct vchiq_header *header)
 
 	payload = (struct vchiq_open_payload *)header->data;
 	fourcc = payload->fourcc;
-	vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: prs OPEN@%pK (%d->'%p4cc')",
-			state->id, header, localport, &fourcc);
+	dev_dbg(state->dev, "core: %d: prs OPEN@%pK (%d->'%p4cc')\n",
+		state->id, header, localport, &fourcc);
 
 	service = get_listening_service(state, fourcc);
 	if (!service)
@@ -1630,10 +1622,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 	svc_fourcc = service ? service->base.fourcc
 			     : VCHIQ_MAKE_FOURCC('?', '?', '?', '?');
 
-	vchiq_log_debug(state->dev, VCHIQ_CORE_MSG,
-			"Rcvd Msg %s(%u) from %p4cc s:%d d:%d len:%d",
-			msg_type_str(type), type, &svc_fourcc,
-			remoteport, localport, size);
+	dev_dbg(state->dev, "core_msg: Rcvd Msg %s(%u) from %p4cc s:%d d:%d len:%d\n",
+		msg_type_str(type), type, &svc_fourcc, remoteport, localport, size);
 	if (size > 0)
 		vchiq_log_dump_mem(state->dev, "Rcvd", 0, header->data, min(16, size));
 
@@ -1657,10 +1647,10 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 				header->data;
 			service->peer_version = payload->version;
 		}
-		vchiq_log_debug(state->dev, VCHIQ_CORE,
-				"%d: prs OPENACK@%pK,%x (%d->%d) v:%d",
-				state->id, header, size, remoteport, localport,
-				service->peer_version);
+		dev_dbg(state->dev,
+			"core: %d: prs OPENACK@%pK,%x (%d->%d) v:%d\n",
+			state->id, header, size, remoteport, localport,
+			service->peer_version);
 		if (service->srvstate == VCHIQ_SRVSTATE_OPENING) {
 			service->remoteport = remoteport;
 			set_service_state(service, VCHIQ_SRVSTATE_OPEN);
@@ -1673,21 +1663,20 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 	case VCHIQ_MSG_CLOSE:
 		WARN_ON(size); /* There should be no data */
 
-		vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: prs CLOSE@%pK (%d->%d)",
-				state->id, header, remoteport, localport);
+		dev_dbg(state->dev, "core: %d: prs CLOSE@%pK (%d->%d)\n",
+			state->id, header, remoteport, localport);
 
 		mark_service_closing_internal(service, 1);
 
 		if (vchiq_close_service_internal(service, CLOSE_RECVD) == -EAGAIN)
 			goto bail_not_ready;
 
-		vchiq_log_debug(state->dev, VCHIQ_CORE, "Close Service %p4cc s:%u d:%d",
-				&service->base.fourcc,
-				service->localport, service->remoteport);
+		dev_dbg(state->dev, "core: Close Service %p4cc s:%u d:%d\n",
+			&service->base.fourcc, service->localport, service->remoteport);
 		break;
 	case VCHIQ_MSG_DATA:
-		vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: prs DATA@%pK,%x (%d->%d)",
-				state->id, header, size, remoteport, localport);
+		dev_dbg(state->dev, "core: %d: prs DATA@%pK,%x (%d->%d)\n",
+			state->id, header, size, remoteport, localport);
 
 		if ((service->remoteport == remoteport) &&
 		    (service->srvstate == VCHIQ_SRVSTATE_OPEN)) {
@@ -1706,8 +1695,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 		}
 		break;
 	case VCHIQ_MSG_CONNECT:
-		vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: prs CONNECT@%pK",
-				state->id, header);
+		dev_dbg(state->dev, "core: %d: prs CONNECT@%pK\n",
+			state->id, header);
 		state->version_common =	((struct vchiq_slot_zero *)
 					 state->slot_data)->version;
 		complete(&state->connect);
@@ -1758,10 +1747,9 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
 			bulk->actual = *(int *)header->data;
 			queue->remote_insert++;
 
-			vchiq_log_debug(state->dev, VCHIQ_CORE,
-					"%d: prs %s@%pK (%d->%d) %x@%pad",
-					state->id, msg_type_str(type), header, remoteport,
-					localport, bulk->actual, &bulk->data);
+			dev_dbg(state->dev, "core: %d: prs %s@%pK (%d->%d) %x@%pad\n",
+				state->id, msg_type_str(type), header, remoteport,
+				localport, bulk->actual, &bulk->data);
 
 			dev_dbg(state->dev, "core: %d: prs:%d %cx li=%x ri=%x p=%x\n",
 				state->id, localport,
@@ -2052,9 +2040,9 @@ sync_func(void *v)
 					header->data;
 				service->peer_version = payload->version;
 			}
-			vchiq_log_debug(state->dev, VCHIQ_SYNC, "%d: sf OPENACK@%pK,%x (%d->%d) v:%d",
-					state->id, header, size, remoteport, localport,
-					service->peer_version);
+			dev_err(state->dev, "sync: %d: sf OPENACK@%pK,%x (%d->%d) v:%d\n",
+				state->id, header, size, remoteport, localport,
+				service->peer_version);
 			if (service->srvstate == VCHIQ_SRVSTATE_OPENING) {
 				service->remoteport = remoteport;
 				set_service_state(service, VCHIQ_SRVSTATE_OPENSYNC);
@@ -2456,9 +2444,9 @@ vchiq_add_service_internal(struct vchiq_state *state,
 	/* Bring this service online */
 	set_service_state(service, srvstate);
 
-	vchiq_log_debug(state->dev, VCHIQ_CORE_MSG, "%s Service %p4cc SrcPort:%d",
-			(srvstate == VCHIQ_SRVSTATE_OPENING) ? "Open" : "Add",
-			&params->fourcc, service->localport);
+	dev_dbg(state->dev, "core_msg: %s Service %p4cc SrcPort:%d\n",
+		(srvstate == VCHIQ_SRVSTATE_OPENING) ? "Open" : "Add",
+		&params->fourcc, service->localport);
 
 	/* Don't unlock the service - leave it with a ref_count of 1. */
 
@@ -2553,8 +2541,7 @@ release_service_messages(struct vchiq_service *service)
 			int port = VCHIQ_MSG_DSTPORT(msgid);
 
 			if ((port == service->localport) && (msgid & VCHIQ_MSGID_CLAIMED)) {
-				vchiq_log_debug(state->dev, VCHIQ_CORE,
-						"  fsi - hdr %pK", header);
+				dev_dbg(state->dev, "core:  fsi - hdr %pK\n", header);
 				release_slot(state, slot_info, header, NULL);
 			}
 			pos += calc_stride(header->size);
@@ -2662,8 +2649,9 @@ vchiq_close_service_internal(struct vchiq_service *service, int close_recvd)
 	int close_id = MAKE_CLOSE(service->localport,
 				  VCHIQ_MSG_DSTPORT(service->remoteport));
 
-	vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: csi:%d,%d (%s)", service->state->id,
-			service->localport, close_recvd, srvstate_names[service->srvstate]);
+	dev_dbg(state->dev, "core: %d: csi:%d,%d (%s)\n",
+		service->state->id, service->localport, close_recvd,
+		srvstate_names[service->srvstate]);
 
 	switch (service->srvstate) {
 	case VCHIQ_SRVSTATE_CLOSED:
@@ -2773,8 +2761,8 @@ vchiq_terminate_service_internal(struct vchiq_service *service)
 {
 	struct vchiq_state *state = service->state;
 
-	vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: tsi - (%d<->%d)", state->id,
-			service->localport, service->remoteport);
+	dev_dbg(state->dev, "core: %d: tsi - (%d<->%d)\n",
+		state->id, service->localport, service->remoteport);
 
 	mark_service_closing(service);
 
@@ -2788,8 +2776,7 @@ vchiq_free_service_internal(struct vchiq_service *service)
 {
 	struct vchiq_state *state = service->state;
 
-	vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: fsi - (%d)",
-			state->id, service->localport);
+	dev_dbg(state->dev, "core: %d: fsi - (%d)\n", state->id, service->localport);
 
 	switch (service->srvstate) {
 	case VCHIQ_SRVSTATE_OPENING:
@@ -2869,8 +2856,8 @@ vchiq_close_service(struct vchiq_instance *instance, unsigned int handle)
 	if (!service)
 		return -EINVAL;
 
-	vchiq_log_debug(service->state->dev, VCHIQ_CORE, "%d: close_service:%d",
-			service->state->id, service->localport);
+	dev_dbg(service->state->dev, "core: %d: close_service:%d\n",
+		service->state->id, service->localport);
 
 	if ((service->srvstate == VCHIQ_SRVSTATE_FREE) ||
 	    (service->srvstate == VCHIQ_SRVSTATE_LISTENING) ||
@@ -2927,8 +2914,8 @@ vchiq_remove_service(struct vchiq_instance *instance, unsigned int handle)
 	if (!service)
 		return -EINVAL;
 
-	vchiq_log_debug(service->state->dev, VCHIQ_CORE, "%d: remove_service:%d",
-			service->state->id, service->localport);
+	dev_dbg(service->state->dev, "core: %d: remove_service:%d\n",
+		service->state->id, service->localport);
 
 	if (service->srvstate == VCHIQ_SRVSTATE_FREE) {
 		vchiq_service_put(service);
@@ -3071,9 +3058,9 @@ int vchiq_bulk_transfer(struct vchiq_instance *instance, unsigned int handle,
 	 */
 	wmb();
 
-	vchiq_log_debug(state->dev, VCHIQ_CORE, "%d: bt (%d->%d) %cx %x@%pad %pK",
-			state->id, service->localport, service->remoteport,
-			dir_char, size, &bulk->data, userdata);
+	dev_dbg(state->dev, "core: %d: bt (%d->%d) %cx %x@%pad %pK\n",
+		state->id, service->localport, service->remoteport,
+		dir_char, size, &bulk->data, userdata);
 
 	/*
 	 * The slot mutex must be held when the service is being closed, so
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
index 36e34a7fc628..c8527551b58c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
@@ -32,32 +32,6 @@
 #define VCHIQ_SLOT_SIZE     4096
 #define VCHIQ_MAX_MSG_SIZE  (VCHIQ_SLOT_SIZE - sizeof(struct vchiq_header))
 
-enum vchiq_log_category {
-	VCHIQ_ARM,
-	VCHIQ_CORE,
-	VCHIQ_CORE_MSG,
-	VCHIQ_SYNC,
-	VCHIQ_SUSPEND,
-};
-
-static inline const char *log_category_str(enum vchiq_log_category c)
-{
-	static const char * const strings[] = {
-		"vchiq_arm",
-		"vchiq_core",
-		"vchiq_core_msg",
-		"vchiq_sync",
-		"vchiq_suspend",
-	};
-
-	return strings[c];
-};
-
-#ifndef vchiq_log_debug
-#define vchiq_log_debug(dev, cat, fmt, ...) \
-	do { dev_dbg(dev, "%s debug: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
-#endif
-
 #define VCHIQ_SLOT_MASK        (VCHIQ_SLOT_SIZE - 1)
 #define VCHIQ_SLOT_QUEUE_MASK  (VCHIQ_MAX_SLOTS_PER_SIDE - 1)
 #define VCHIQ_SLOT_ZERO_SLOTS  DIV_ROUND_UP(sizeof(struct vchiq_slot_zero), \
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
index 38841c9d8ef9..68c8897c504c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
@@ -47,9 +47,8 @@ user_service_free(void *userdata)
 
 static void close_delivered(struct user_service *user_service)
 {
-	vchiq_log_debug(user_service->service->state->dev, VCHIQ_ARM,
-			"%s(handle=%x)",
-			__func__, user_service->service->handle);
+	dev_dbg(user_service->service->state->dev,
+		"arm: (handle=%x)\n", user_service->service->handle);
 
 	if (user_service->close_pending) {
 		/* Allow the underlying service to be culled */
@@ -235,8 +234,7 @@ static int vchiq_ioc_dequeue_message(struct vchiq_instance *instance,
 			spin_unlock(&msg_queue_spinlock);
 			DEBUG_TRACE(DEQUEUE_MESSAGE_LINE);
 			if (wait_for_completion_interruptible(&user_service->insert_event)) {
-				vchiq_log_debug(service->state->dev, VCHIQ_ARM,
-						"DEQUEUE_MESSAGE interrupted");
+				dev_dbg(service->state->dev, "arm: DEQUEUE_MESSAGE interrupted\n");
 				ret = -EINTR;
 				break;
 			}
@@ -323,8 +321,8 @@ static int vchiq_irq_queue_bulk_tx_rx(struct vchiq_instance *instance,
 			ret = -ESRCH;
 			goto out;
 		}
-		vchiq_log_debug(service->state->dev, VCHIQ_ARM,
-				"found bulk_waiter %pK for pid %d", waiter, current->pid);
+		dev_dbg(service->state->dev, "arm: found bulk_waiter %pK for pid %d\n",
+			waiter, current->pid);
 		userdata = &waiter->bulk_waiter;
 	} else {
 		userdata = args->userdata;
@@ -355,8 +353,8 @@ static int vchiq_irq_queue_bulk_tx_rx(struct vchiq_instance *instance,
 		mutex_lock(&instance->bulk_waiter_list_mutex);
 		list_add(&waiter->list, &instance->bulk_waiter_list);
 		mutex_unlock(&instance->bulk_waiter_list_mutex);
-		vchiq_log_debug(service->state->dev, VCHIQ_ARM,
-				"saved bulk_waiter %pK for pid %d", waiter, current->pid);
+		dev_dbg(service->state->dev, "arm: saved bulk_waiter %pK for pid %d\n",
+			waiter, current->pid);
 
 		ret = put_user(mode_waiting, mode);
 	}
@@ -455,8 +453,7 @@ static int vchiq_ioc_await_completion(struct vchiq_instance *instance,
 		mutex_lock(&instance->completion_mutex);
 		if (rc) {
 			DEBUG_TRACE(AWAIT_COMPLETION_LINE);
-			vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-					"AWAIT_COMPLETION interrupted");
+			dev_dbg(instance->state->dev, "arm: AWAIT_COMPLETION interrupted\n");
 			ret = -EINTR;
 			goto out;
 		}
@@ -867,10 +864,10 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 	}
 
 	if (!status && (ret < 0) && (ret != -EINTR) && (ret != -EWOULDBLOCK)) {
-		vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
-				"  ioctl instance %pK, cmd %s -> status %d, %ld",
-				instance, (_IOC_NR(cmd) <= VCHIQ_IOC_MAX) ?
-				ioctl_names[_IOC_NR(cmd)] : "<invalid>", status, ret);
+		dev_dbg(instance->state->dev,
+			"arm: ioctl instance %pK, cmd %s -> status %d, %ld\n",
+			instance, (_IOC_NR(cmd) <= VCHIQ_IOC_MAX) ?
+			ioctl_names[_IOC_NR(cmd)] : "<invalid>", status, ret);
 	} else {
 		dev_dbg(instance->state->dev,
 			"arm: ioctl instance %pK, cmd %s -> status %d\n, %ld\n",
@@ -1169,7 +1166,7 @@ static int vchiq_open(struct inode *inode, struct file *file)
 	struct vchiq_state *state = vchiq_get_state();
 	struct vchiq_instance *instance;
 
-	vchiq_log_debug(state->dev, VCHIQ_ARM, "vchiq_open");
+	dev_dbg(state->dev, "arm: vchiq open\n");
 
 	if (!state) {
 		dev_err(state->dev, "arm: vchiq has no connection to VideoCore\n");
@@ -1204,8 +1201,7 @@ static int vchiq_release(struct inode *inode, struct file *file)
 	int ret = 0;
 	int i;
 
-	vchiq_log_debug(state->dev, VCHIQ_ARM, "%s: instance=%lx", __func__,
-			(unsigned long)instance);
+	dev_dbg(state->dev, "arm: instance=%lx\n", (unsigned long)instance);
 
 	if (!state) {
 		ret = -EPERM;
-- 
2.41.0



From krzysztof.kozlowski at linaro.org  Tue Dec  5 00:45:44 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 5 Dec 2023 09:45:44 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231205083001.GP5169@atomide.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
 <20231205075657.GN5169@atomide.com>
 <df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>
 <20231205081031.GO5169@atomide.com>
 <efcd64f4-00d2-4671-af3a-e27764f70e8d@linaro.org>
 <20231205083001.GP5169@atomide.com>
Message-ID: <27f2e3a3-0791-4278-adb2-55ed76820a3a@linaro.org>

On 05/12/2023 09:30, Tony Lindgren wrote:
> * Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> [231205 08:16]:
>> On 05/12/2023 09:10, Tony Lindgren wrote:
>>> * Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> [231205 08:03]:
>>>> What does runtime PM have to do with it? If runtime PM enables clocks,
>>>> these are real signals and not optional.
>>>
>>> Runtime PM propagates to the parent device.
>>
>> Then it is not really relevant to the hardware talk here, unless you put
>> this device clocks in parent node, but then it's just wrong hardware
>> description.
> 
> No it's not. The interconnect target module may have one or more separate

Interconnects are not parents of devices, so I still don't get why do
you bring it here.

> devices with the same shared clocks. See for example the am3 usb module that
> has usb controllers, phys and dma at target-module at 47400000 in am33xx.dtsi.

There is no interconnect-cells there, so why do we talk about
interconnect here?

> 
> Sure the clock nodes can be there for the child IP, but they won't do
> anything. And still need to be managed separately by the device driver if
> added.

So if OS does not have runtime PM, the bindings are wrong? Bindings
should not depend on some particular feature of some particular OS.

Best regards,
Krzysztof



From andreas at kemnade.info  Tue Dec  5 01:02:46 2023
From: andreas at kemnade.info (Andreas Kemnade)
Date: Tue, 5 Dec 2023 10:02:46 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX
 GPUs
In-Reply-To: <27f2e3a3-0791-4278-adb2-55ed76820a3a@linaro.org>
References: <20231204182245.33683-1-afd@ti.com>
	<20231204182245.33683-2-afd@ti.com>
	<b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
	<20231205075657.GN5169@atomide.com>
	<df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>
	<20231205081031.GO5169@atomide.com>
	<efcd64f4-00d2-4671-af3a-e27764f70e8d@linaro.org>
	<20231205083001.GP5169@atomide.com>
	<27f2e3a3-0791-4278-adb2-55ed76820a3a@linaro.org>
Message-ID: <20231205100246.5db0d6a1@aktux>

On Tue, 5 Dec 2023 09:45:44 +0100
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

> > Sure the clock nodes can be there for the child IP, but they won't do
> > anything. And still need to be managed separately by the device driver if
> > added.  
> 
> So if OS does not have runtime PM, the bindings are wrong? Bindings
> should not depend on some particular feature of some particular OS.

Any user of the devicetree sees that there is a parent and the parent needs
to be enabled by some mechanism.
E.g. I2c devices do not specify the clocks of the parent (the i2c master)

Maybe it is just more fine-grained on omap.

look e.g. at ti/omap/omap4-l4.dtsi
there are target-module at xxxx
with the devices as a child and a clock in the parent.

Regards,
Andreas


From james.clark at arm.com  Tue Dec  5 01:11:03 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 5 Dec 2023 09:11:03 +0000
Subject: [PATCH v2] coresight: Make current W=1 warnings default
In-Reply-To: <202312050158.FKpxuafP-lkp@intel.com>
References: <20231115162834.355598-1-james.clark@arm.com>
 <202312050158.FKpxuafP-lkp@intel.com>
Message-ID: <4615fe3e-7f11-d8c6-596b-32833db458d2@arm.com>



On 04/12/2023 18:37, kernel test robot wrote:
> Hi James,
> 
> kernel test robot noticed the following build warnings:
> 
> [auto build test WARNING on atorgue-stm32/stm32-next]
> [also build test WARNING on linus/master v6.7-rc4 next-20231204]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/James-Clark/coresight-Make-current-W-1-warnings-default/20231116-004818
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
> patch link:    https://lore.kernel.org/r/20231115162834.355598-1-james.clark%40arm.com
> patch subject: [PATCH v2] coresight: Make current W=1 warnings default
> config: arm-randconfig-r131-20231117 (https://download.01.org/0day-ci/archive/20231205/202312050158.FKpxuafP-lkp at intel.com/config)
> compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
> reproduce: (https://download.01.org/0day-ci/archive/20231205/202312050158.FKpxuafP-lkp at intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp at intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202312050158.FKpxuafP-lkp at intel.com/
> 
> sparse warnings: (new ones prefixed by >>)
>>> drivers/hwtracing/coresight/coresight-etb10.c:840:17: sparse: sparse: Using plain integer as NULL pointer
>    drivers/hwtracing/coresight/coresight-etb10.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
>    include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
> --
>>> drivers/hwtracing/coresight/coresight-funnel.c:395:17: sparse: sparse: Using plain integer as NULL pointer
>    drivers/hwtracing/coresight/coresight-funnel.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/slab.h, ...):
>    include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
> --
>>> drivers/hwtracing/coresight/coresight-tpdm.c:242:17: sparse: sparse: Using plain integer as NULL pointer
>    drivers/hwtracing/coresight/coresight-tpdm.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
>    include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
> 
> vim +840 drivers/hwtracing/coresight/coresight-etb10.c
> 
>    834	
>    835	static const struct amba_id etb_ids[] = {
>    836		{
>    837			.id	= 0x000bb907,
>    838			.mask	= 0x000fffff,
>    839		},
>  > 840		{ 0, 0, 0 },
>    841	};
>    842	
> 

This should already be fixed in V3 here:

https://lore.kernel.org/linux-arm-kernel/20231123120459.287578-1-james.clark at arm.com/


From krzysztof.kozlowski at linaro.org  Tue Dec  5 01:16:22 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 5 Dec 2023 10:16:22 +0100
Subject: (subset) [PATCH 00/17] dt-bindings: samsung: add specific
 compatibles for existing SoC
In-Reply-To: <20231128205841.al23ra5s34rn3muj@pengutronix.de>
References: <20231108104343.24192-1-krzysztof.kozlowski@linaro.org>
 <170119374454.445690.515311393756577368.b4-ty@gmail.com>
 <20231128205841.al23ra5s34rn3muj@pengutronix.de>
Message-ID: <369dfa0c-315d-47a9-81fc-c166c9632bac@linaro.org>

On 28/11/2023 21:58, Uwe Kleine-K?nig wrote:
> On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
>>
>> On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
>>> Merging
>>> =======
>>> I propose to take entire patchset through my tree (Samsung SoC), because:
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>>> 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
>>>    they will touch the same lines in some of the DT bindings (not all, though).
>>>    It is reasonable for me to take the bindings for the new SoCs, to have clean
>>>    `make dtbs_check` on the new DTS.
>>> 2. Having it together helps me to have clean `make dtbs_check` within my tree
>>>    on the existing DTS.
>>> 3. No drivers are affected by this change.
>>> 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
>>>    follow up patchsets.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
>>         commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f
> 
> You didn't honor (or even comment) Krzysztof's proposal to take the
> whole patchset via his tree (marked above). Was there some off-list
> agreement?
> 

It was also written in the PWM patch itself (under changelog ---) and
expressed with my "applied" response when I took everything. I am
sending now another set, also touching PWM.

Best regards,
Krzysztof



From maz at kernel.org  Tue Dec  5 01:21:28 2023
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 05 Dec 2023 09:21:28 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
In-Reply-To: <20231205033015.10044-1-ankita@nvidia.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
Message-ID: <86fs0hatt3.wl-maz@kernel.org>

+ Shameer

On Tue, 05 Dec 2023 03:30:15 +0000,
<ankita at nvidia.com> wrote:
> 
> From: Ankit Agrawal <ankita at nvidia.com>
> 
> Currently, KVM for ARM64 maps at stage 2 memory that is considered device
> (i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting
> overrides (as per the ARM architecture [1]) any device MMIO mapping
> present at stage 1, resulting in a set-up whereby a guest operating
> system cannot determine device MMIO mapping memory attributes on its
> own but it is always overridden by the KVM stage 2 default.
> 
> This set-up does not allow guest operating systems to select device
> memory attributes independently from KVM stage-2 mappings
> (refer to [1], "Combining stage 1 and stage 2 memory type attributes"),
> which turns out to be an issue in that guest operating systems
> (e.g. Linux) may request to map devices MMIO regions with memory
> attributes that guarantee better performance (e.g. gathering
> attribute - that for some devices can generate larger PCIe memory
> writes TLPs) and specific operations (e.g. unaligned transactions)
> such as the NormalNC memory type.
> 
> The default device stage 2 mapping was chosen in KVM for ARM64 since
> it was considered safer (i.e. it would not allow guests to trigger
> uncontained failures ultimately crashing the machine) but this
> turned out to be asynchronous (SError) defeating the purpose.
> 
> Failures containability is a property of the platform and is independent
> from the memory type used for MMIO device memory mappings.
> 
> Actually, DEVICE_nGnRE memory type is even more problematic than
> Normal-NC memory type in terms of faults containability in that e.g.
> aborts triggered on DEVICE_nGnRE loads cannot be made, architecturally,
> synchronous (i.e. that would imply that the processor should issue at
> most 1 load transaction at a time - it cannot pipeline them - otherwise
> the synchronous abort semantics would break the no-speculation attribute
> attached to DEVICE_XXX memory).
> 
> This means that regardless of the combined stage1+stage2 mappings a
> platform is safe if and only if device transactions cannot trigger
> uncontained failures and that in turn relies on platform capabilities
> and the device type being assigned (i.e. PCIe AER/DPC error containment
> and RAS architecture[3]); therefore the default KVM device stage 2
> memory attributes play no role in making device assignment safer
> for a given platform (if the platform design adheres to design
> guidelines outlined in [3]) and therefore can be relaxed.
> 
> For all these reasons, relax the KVM stage 2 device memory attributes
> from DEVICE_nGnRE to Normal-NC. Add a new kvm_pgtable_prot flag for
> Normal-NC.
> 
> The Normal-NC was chosen over a different Normal memory type default
> at stage-2 (e.g. Normal Write-through) to avoid cache allocation/snooping.
> 
> Relaxing S2 KVM device MMIO mappings to Normal-NC is not expected to
> trigger any issue on guest device reclaim use cases either (i.e. device
> MMIO unmap followed by a device reset) at least for PCIe devices, in that
> in PCIe a device reset is architected and carried out through PCI config
> space transactions that are naturally ordered with respect to MMIO
> transactions according to the PCI ordering rules.
> 
> Having Normal-NC S2 default puts guests in control (thanks to
> stage1+stage2 combined memory attributes rules [1]) of device MMIO
> regions memory mappings, according to the rules described in [1]
> and summarized here ([(S1) - stage1], [(S2) - stage 2]):
> 
> S1           |  S2           | Result
> NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
> NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
> NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
> DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>
> 
> It is worth noting that currently, to map devices MMIO space to user
> space in a device pass-through use case the VFIO framework applies memory
> attributes derived from pgprot_noncached() settings applied to VMAs, which
> result in device-nGnRnE memory attributes for the stage-1 VMM mappings.
> 
> This means that a userspace mapping for device MMIO space carried
> out with the current VFIO framework and a guest OS mapping for the same
> MMIO space may result in a mismatched alias as described in [2].
> 
> Defaulting KVM device stage-2 mappings to Normal-NC attributes does not
> change anything in this respect, in that the mismatched aliases would
> only affect (refer to [2] for a detailed explanation) ordering between
> the userspace and GuestOS mappings resulting stream of transactions
> (i.e. it does not cause loss of property for either stream of
> transactions on its own), which is harmless given that the userspace
> and GuestOS access to the device is carried out through independent
> transactions streams.
> 
> [1] section D8.5 - DDI0487_I_a_a-profile_architecture_reference_manual.pdf
> [2] section B2.8 - DDI0487_I_a_a-profile_architecture_reference_manual.pdf

Can you please quote the latest specs?

> [3] sections 1.7.7.3/1.8.5.2/appendix C - DEN0029H_SBSA_7.1.pdf
> 
> Applied over next-20231201
> 
> History
> =======
> v1 -> v2
> - Updated commit log to the one posted by
>   Lorenzo Pieralisi <lpieralisi at kernel.org> (Thanks!)
> - Added new flag to represent the NORMAL_NC setting. Updated
>   stage2_set_prot_attr() to handle new flag.
> 
> v1 Link:
> https://lore.kernel.org/all/20230907181459.18145-3-ankita at nvidia.com/
> 
> Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
> Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> Tested-by: Ankit Agrawal <ankita at nvidia.com>

Despite the considerable increase in the commit message length, a
number of questions are left unanswered:

- Shameer reported a regression on non-FWB systems, breaking device
  assignment:

  https://lore.kernel.org/all/af13ed63dc9a4f26a6c958ebfa77d78a at huawei.com/

  How has this been addressed?

- Will had unanswered questions in another part of the thread:

  https://lore.kernel.org/all/20231013092954.GB13524 at willie-the-truck/

  Can someone please help concluding it?

> 
> ---
>  arch/arm64/include/asm/kvm_pgtable.h |  2 ++
>  arch/arm64/include/asm/memory.h      |  2 ++
>  arch/arm64/kvm/hyp/pgtable.c         | 11 +++++++++--
>  arch/arm64/kvm/mmu.c                 |  4 ++--
>  4 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index cfdf40f734b1..19278dfe7978 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -197,6 +197,7 @@ enum kvm_pgtable_stage2_flags {
>   * @KVM_PGTABLE_PROT_W:		Write permission.
>   * @KVM_PGTABLE_PROT_R:		Read permission.
>   * @KVM_PGTABLE_PROT_DEVICE:	Device attributes.
> + * @KVM_PGTABLE_PROT_NORMAL_NC:	Normal noncacheable attributes.
>   * @KVM_PGTABLE_PROT_SW0:	Software bit 0.
>   * @KVM_PGTABLE_PROT_SW1:	Software bit 1.
>   * @KVM_PGTABLE_PROT_SW2:	Software bit 2.
> @@ -208,6 +209,7 @@ enum kvm_pgtable_prot {
>  	KVM_PGTABLE_PROT_R			= BIT(2),
>  
>  	KVM_PGTABLE_PROT_DEVICE			= BIT(3),
> +	KVM_PGTABLE_PROT_NORMAL_NC		= BIT(4),
>  
>  	KVM_PGTABLE_PROT_SW0			= BIT(55),
>  	KVM_PGTABLE_PROT_SW1			= BIT(56),
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index fde4186cc387..c247e5f29d5a 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -147,6 +147,7 @@
>   * Memory types for Stage-2 translation
>   */
>  #define MT_S2_NORMAL		0xf
> +#define MT_S2_NORMAL_NC		0x5
>  #define MT_S2_DEVICE_nGnRE	0x1
>  
>  /*
> @@ -154,6 +155,7 @@
>   * Stage-2 enforces Normal-WB and Device-nGnRE
>   */
>  #define MT_S2_FWB_NORMAL	6
> +#define MT_S2_FWB_NORMAL_NC	5
>  #define MT_S2_FWB_DEVICE_nGnRE	1
>  
>  #ifdef CONFIG_ARM64_4K_PAGES
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index c651df904fe3..d4835d553c61 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -718,10 +718,17 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
>  				kvm_pte_t *ptep)
>  {
>  	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
> -	kvm_pte_t attr = device ? KVM_S2_MEMATTR(pgt, DEVICE_nGnRE) :
> -			    KVM_S2_MEMATTR(pgt, NORMAL);
> +	bool normal_nc = prot & KVM_PGTABLE_PROT_NORMAL_NC;
> +	kvm_pte_t attr;
>  	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
>  
> +	if (device)
> +		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
> +	else if (normal_nc)
> +		attr = KVM_S2_MEMATTR(pgt, NORMAL_NC);
> +	else
> +		attr = KVM_S2_MEMATTR(pgt, NORMAL);
> +
>  	if (!(prot & KVM_PGTABLE_PROT_X))
>  		attr |= KVM_PTE_LEAF_ATTR_HI_S2_XN;
>  	else if (device)
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index d14504821b79..1cb302457d3f 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1071,7 +1071,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>  	struct kvm_mmu_memory_cache cache = { .gfp_zero = __GFP_ZERO };
>  	struct kvm_s2_mmu *mmu = &kvm->arch.mmu;
>  	struct kvm_pgtable *pgt = mmu->pgt;
> -	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_DEVICE |
> +	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_NORMAL_NC |
>  				     KVM_PGTABLE_PROT_R |
>  				     (writable ? KVM_PGTABLE_PROT_W : 0);

Doesn't this affect the GICv2 VCPU interface, which is effectively a
shared peripheral, now allowing a guest to affect another guest's
interrupt distribution? If that is the case, this needs to be fixed.

In general, I don't think this should be a blanket statement, but be
limited to devices that we presume can deal with this (i.e. PCIe, and
not much else).

>
> @@ -1558,7 +1558,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  		prot |= KVM_PGTABLE_PROT_X;
>  
>  	if (device)
> -		prot |= KVM_PGTABLE_PROT_DEVICE;
> +		prot |= KVM_PGTABLE_PROT_NORMAL_NC;
>  	else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
>  		prot |= KVM_PGTABLE_PROT_X;
>  

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


From krzysztof.kozlowski at linaro.org  Tue Dec  5 01:22:23 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue,  5 Dec 2023 10:22:23 +0100
Subject: [PATCH 0/6] dt-bindings: samsung: continued - add specific compatibles for Tesla FSD Hi,
Message-ID: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>

Merging
=======
I propose to take entire patchset through my tree (Samsung SoC), because:
1. I already took similar work this cycle:
   https://lore.kernel.org/all/169997520487.6747.17671551558724027958.b4-ty at linaro.org/
2. Two new SoCs are coming (Google GS101 and ExynosAutov920) and they might
   touch the same lines.  It is reasonable for me to take the bindings for the new
   SoCs, to have clean `make dtbs_check` on the new DTS.
3. Having it together helps me to have clean `make dtbs_check` within my tree
   on the existing DTS.
4. No drivers are affected by this change.

If folks agree, please kindly Ack the patches.

Description
===========
See:
https://lore.kernel.org/all/20231108104343.24192-1-krzysztof.kozlowski at linaro.org/

Best regards,
Krzysztof

Krzysztof Kozlowski (6):
  dt-bindings: i2c: exynos5: add specific compatible for Tesla FSD
  dt-bindings: pwm: samsung: add specific compatible for Tesla FSD
  dt-bindings: serial: samsung: add specific compatible for Tesla FSD
  dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla
    FSD
  dt-bindings: watchdog: samsung: add specific compatible for Tesla FSD
  arm64: dts: fsd: add specific compatibles for Tesla FSD

 .../devicetree/bindings/i2c/i2c-exynos5.yaml  |  1 +
 .../devicetree/bindings/pwm/pwm-samsung.yaml  |  1 +
 .../bindings/serial/samsung_uart.yaml         |  1 +
 .../bindings/soc/samsung/exynos-pmu.yaml      |  1 +
 .../bindings/watchdog/samsung-wdt.yaml        | 21 +++++++-----
 arch/arm64/boot/dts/tesla/fsd.dtsi            | 32 +++++++++----------
 6 files changed, 33 insertions(+), 24 deletions(-)

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Tue Dec  5 01:22:24 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue,  5 Dec 2023 10:22:24 +0100
Subject: [PATCH 1/6] dt-bindings: i2c: exynos5: add specific compatible for Tesla FSD
In-Reply-To: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231205092229.19135-2-krzysztof.kozlowski@linaro.org>

Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
others it reuses several devices from older designs.  Historically we
kept the old (block's) compatible only.  This works fine and there is no
bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add Tesla FSD compatible specific to be used with an existing fallback.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
index c1f5d2cb7709..df9c57bca2a8 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
@@ -29,6 +29,7 @@ properties:
       - items:
           - enum:
               - samsung,exynos5433-hsi2c
+              - tesla,fsd-hsi2c
           - const: samsung,exynos7-hsi2c
       - items:
           - enum:
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Tue Dec  5 01:22:25 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue,  5 Dec 2023 10:22:25 +0100
Subject: [PATCH 2/6] dt-bindings: pwm: samsung: add specific compatible for Tesla FSD
In-Reply-To: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231205092229.19135-3-krzysztof.kozlowski@linaro.org>

Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
others it reuses several devices from older designs.  Historically we
kept the old (block's) compatible only.  This works fine and there is no
bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add Tesla FSD compatible specific to be used with an existing fallback.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 Documentation/devicetree/bindings/pwm/pwm-samsung.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
index 16de6434693b..17a2b927af33 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
@@ -33,6 +33,7 @@ properties:
               - samsung,exynos7-pwm
               - samsung,exynosautov9-pwm
               - samsung,exynosautov920-pwm
+              - tesla,fsd-pwm
           - const: samsung,exynos4210-pwm
 
   reg:
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Tue Dec  5 01:22:26 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue,  5 Dec 2023 10:22:26 +0100
Subject: [PATCH 3/6] dt-bindings: serial: samsung: add specific compatible for Tesla FSD
In-Reply-To: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231205092229.19135-4-krzysztof.kozlowski@linaro.org>

Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
others it reuses several devices from older designs.  Historically we
kept the old (block's) compatible only.  This works fine and there is no
bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add Tesla FSD compatible specific to be used with an existing fallback.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 Documentation/devicetree/bindings/serial/samsung_uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index e32c1b462836..4b6fc82c2edf 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -29,6 +29,7 @@ properties:
       - items:
           - enum:
               - samsung,exynos7-uart
+              - tesla,fsd-uart
           - const: samsung,exynos4210-uart
       - items:
           - enum:
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Tue Dec  5 01:22:27 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue,  5 Dec 2023 10:22:27 +0100
Subject: [PATCH 4/6] dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla FSD
In-Reply-To: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231205092229.19135-5-krzysztof.kozlowski@linaro.org>

Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
others it reuses several devices from older designs.  Historically we
kept the old (block's) compatible only.  This works fine and there is no
bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add Tesla FSD compatible specific to be used with an existing fallback.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 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 28e2cb50d85e..65f77442ff23 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -53,6 +53,7 @@ properties:
               - samsung,exynos7885-pmu
               - samsung,exynosautov9-pmu
               - samsung,exynosautov920-pmu
+              - tesla,fsd-pmu
           - const: samsung,exynos7-pmu
           - const: syscon
       - items:
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Tue Dec  5 01:22:28 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue,  5 Dec 2023 10:22:28 +0100
Subject: [PATCH 5/6] dt-bindings: watchdog: samsung: add specific compatible for Tesla FSD
In-Reply-To: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231205092229.19135-6-krzysztof.kozlowski@linaro.org>

Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
others it reuses several devices from older designs.  Historically we
kept the old (block's) compatible only.  This works fine and there is no
bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add Tesla FSD compatible specific to be used with an existing fallback.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 .../bindings/watchdog/samsung-wdt.yaml        | 21 ++++++++++++-------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
index 8fb6656ba0c2..ea2d206b05ab 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -16,14 +16,19 @@ description: |+
 
 properties:
   compatible:
-    enum:
-      - samsung,s3c2410-wdt                   # for S3C2410
-      - samsung,s3c6410-wdt                   # for S3C6410, S5PV210 and Exynos4
-      - samsung,exynos5250-wdt                # for Exynos5250
-      - samsung,exynos5420-wdt                # for Exynos5420
-      - samsung,exynos7-wdt                   # for Exynos7
-      - samsung,exynos850-wdt                 # for Exynos850
-      - samsung,exynosautov9-wdt              # for Exynosautov9
+    oneOf:
+      - enum:
+          - samsung,s3c2410-wdt                   # for S3C2410
+          - samsung,s3c6410-wdt                   # for S3C6410, S5PV210 and Exynos4
+          - samsung,exynos5250-wdt                # for Exynos5250
+          - samsung,exynos5420-wdt                # for Exynos5420
+          - samsung,exynos7-wdt                   # for Exynos7
+          - samsung,exynos850-wdt                 # for Exynos850
+          - samsung,exynosautov9-wdt              # for Exynosautov9
+      - items:
+          - enum:
+              - tesla,fsd-wdt
+          - const: samsung,exynos7-wdt
 
   reg:
     maxItems: 1
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Tue Dec  5 01:22:29 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue,  5 Dec 2023 10:22:29 +0100
Subject: [PATCH 6/6] arm64: dts: fsd: add specific compatibles for Tesla FSD
In-Reply-To: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231205092229.19135-7-krzysztof.kozlowski@linaro.org>

Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
others it reuses several devices from older designs.  Historically we
kept the old (block's) compatible only.  This works fine and there is no
bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add Tesla FSD compatible specific to be used with an existing fallback.
This will also help reviews of new code using existing DTS as template.
No functional impact on Linux drivers behavior.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 arch/arm64/boot/dts/tesla/fsd.dtsi | 32 +++++++++++++++---------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/boot/dts/tesla/fsd.dtsi b/arch/arm64/boot/dts/tesla/fsd.dtsi
index bb50a9f7db4a..9db162afc834 100644
--- a/arch/arm64/boot/dts/tesla/fsd.dtsi
+++ b/arch/arm64/boot/dts/tesla/fsd.dtsi
@@ -581,7 +581,7 @@ pdma1: dma-controller at 14290000 {
 		};
 
 		serial_0: serial at 14180000 {
-			compatible = "samsung,exynos4210-uart";
+			compatible = "tesla,fsd-uart", "samsung,exynos4210-uart";
 			reg = <0x0 0x14180000 0x0 0x100>;
 			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
 			dmas = <&pdma1 1>, <&pdma1 0>;
@@ -593,7 +593,7 @@ serial_0: serial at 14180000 {
 		};
 
 		serial_1: serial at 14190000 {
-			compatible = "samsung,exynos4210-uart";
+			compatible = "tesla,fsd-uart", "samsung,exynos4210-uart";
 			reg = <0x0 0x14190000 0x0 0x100>;
 			interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
 			dmas = <&pdma1 3>, <&pdma1 2>;
@@ -605,12 +605,12 @@ serial_1: serial at 14190000 {
 		};
 
 		pmu_system_controller: system-controller at 11400000 {
-			compatible = "samsung,exynos7-pmu", "syscon";
+			compatible = "tesla,fsd-pmu", "samsung,exynos7-pmu", "syscon";
 			reg = <0x0 0x11400000 0x0 0x5000>;
 		};
 
 		watchdog_0: watchdog at 100a0000 {
-			compatible = "samsung,exynos7-wdt";
+			compatible = "tesla,fsd-wdt", "samsung,exynos7-wdt";
 			reg = <0x0 0x100a0000 0x0 0x100>;
 			interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>;
 			samsung,syscon-phandle = <&pmu_system_controller>;
@@ -619,7 +619,7 @@ watchdog_0: watchdog at 100a0000 {
 		};
 
 		watchdog_1: watchdog at 100b0000 {
-			compatible = "samsung,exynos7-wdt";
+			compatible = "tesla,fsd-wdt", "samsung,exynos7-wdt";
 			reg = <0x0 0x100b0000 0x0 0x100>;
 			interrupts = <GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>;
 			samsung,syscon-phandle = <&pmu_system_controller>;
@@ -628,7 +628,7 @@ watchdog_1: watchdog at 100b0000 {
 		};
 
 		watchdog_2: watchdog at 100c0000 {
-			compatible = "samsung,exynos7-wdt";
+			compatible = "tesla,fsd-wdt", "samsung,exynos7-wdt";
 			reg = <0x0 0x100c0000 0x0 0x100>;
 			interrupts = <GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>;
 			samsung,syscon-phandle = <&pmu_system_controller>;
@@ -637,7 +637,7 @@ watchdog_2: watchdog at 100c0000 {
 		};
 
 		pwm_0: pwm at 14100000 {
-			compatible = "samsung,exynos4210-pwm";
+			compatible = "tesla,fsd-pwm", "samsung,exynos4210-pwm";
 			reg = <0x0 0x14100000 0x0 0x100>;
 			samsung,pwm-outputs = <0>, <1>, <2>, <3>;
 			#pwm-cells = <3>;
@@ -647,7 +647,7 @@ pwm_0: pwm at 14100000 {
 		};
 
 		pwm_1: pwm at 14110000 {
-			compatible = "samsung,exynos4210-pwm";
+			compatible = "tesla,fsd-pwm", "samsung,exynos4210-pwm";
 			reg = <0x0 0x14110000 0x0 0x100>;
 			samsung,pwm-outputs = <0>, <1>, <2>, <3>;
 			#pwm-cells = <3>;
@@ -657,7 +657,7 @@ pwm_1: pwm at 14110000 {
 		};
 
 		hsi2c_0: i2c at 14200000 {
-			compatible = "samsung,exynos7-hsi2c";
+			compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
 			reg = <0x0 0x14200000 0x0 0x1000>;
 			interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
@@ -670,7 +670,7 @@ hsi2c_0: i2c at 14200000 {
 		};
 
 		hsi2c_1: i2c at 14210000 {
-			compatible = "samsung,exynos7-hsi2c";
+			compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
 			reg = <0x0 0x14210000 0x0 0x1000>;
 			interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
@@ -683,7 +683,7 @@ hsi2c_1: i2c at 14210000 {
 		};
 
 		hsi2c_2: i2c at 14220000 {
-			compatible = "samsung,exynos7-hsi2c";
+			compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
 			reg = <0x0 0x14220000 0x0 0x1000>;
 			interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
@@ -696,7 +696,7 @@ hsi2c_2: i2c at 14220000 {
 		};
 
 		hsi2c_3: i2c at 14230000 {
-			compatible = "samsung,exynos7-hsi2c";
+			compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
 			reg = <0x0 0x14230000 0x0 0x1000>;
 			interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
@@ -709,7 +709,7 @@ hsi2c_3: i2c at 14230000 {
 		};
 
 		hsi2c_4: i2c at 14240000 {
-			compatible = "samsung,exynos7-hsi2c";
+			compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
 			reg = <0x0 0x14240000 0x0 0x1000>;
 			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
@@ -722,7 +722,7 @@ hsi2c_4: i2c at 14240000 {
 		};
 
 		hsi2c_5: i2c at 14250000 {
-			compatible = "samsung,exynos7-hsi2c";
+			compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
 			reg = <0x0 0x14250000 0x0 0x1000>;
 			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
@@ -735,7 +735,7 @@ hsi2c_5: i2c at 14250000 {
 		};
 
 		hsi2c_6: i2c at 14260000 {
-			compatible = "samsung,exynos7-hsi2c";
+			compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
 			reg = <0x0 0x14260000 0x0 0x1000>;
 			interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
@@ -748,7 +748,7 @@ hsi2c_6: i2c at 14260000 {
 		};
 
 		hsi2c_7: i2c at 14270000 {
-			compatible = "samsung,exynos7-hsi2c";
+			compatible = "tesla,fsd-hsi2c", "samsung,exynos7-hsi2c";
 			reg = <0x0 0x14270000 0x0 0x1000>;
 			interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
-- 
2.34.1



From richard at nod.at  Tue Dec  5 01:22:56 2023
From: richard at nod.at (Richard Weinberger)
Date: Tue, 5 Dec 2023 10:22:56 +0100 (CET)
Subject: [PATCH] spi: atmel: Prevent spi transfers from being killed
In-Reply-To: <20231205083102.16946-1-miquel.raynal@bootlin.com>
References: <20231205083102.16946-1-miquel.raynal@bootlin.com>
Message-ID: <1788823860.72909.1701768176780.JavaMail.zimbra@nod.at>

----- Urspr?ngliche Mail -----
> Von: "Miquel Raynal" <miquel.raynal at bootlin.com>
> All being well, it was reported that JFFS2 was showing a splat when
> interrupting a transfer. After some more debate about whether JFFS2
> should be fixed and how, it was also pointed out that the whole
> consistency of the filesystem in case of parallel I/O would be
> compromised. Changing JFFS2 behavior would in theory be possible but
> nobody has the energy and time and knowledge to do this now, so better
> prevent spi transfers to be interrupted by the user.

Well, it's not really an JFFS2 issue.
The real problem is, that with the said change anyone can abort an IO.
Usually file systems assume that an IO can only fail in fatal situations.
That's why UBIFS, for example, switches immediately to read-only mode.
So, an unprivileged user can force UBIFS into read-only mode, which is a
local DoS attack vector.

JFFS2, on the other hand, dies a different death. If you abort one IO,
another IO path can still be active and will violate the order of written
data.

Long story short, aborting pure user inflicted IO is fine. This is the "dd"
use case.
But as soon a filesystem is on top, things get complicated.

Maybe it is possible to teach the SPI subsystem whether an IO comes from spidev
or the kernel itself?

Thanks,
//richard


From ronald.wahl at raritan.com  Tue Dec  5 01:23:19 2023
From: ronald.wahl at raritan.com (Ronald Wahl)
Date: Tue, 5 Dec 2023 10:23:19 +0100
Subject: [PATCH] spi: atmel: Prevent spi transfers from being killed
In-Reply-To: <20231205083102.16946-1-miquel.raynal@bootlin.com>
References: <20231205083102.16946-1-miquel.raynal@bootlin.com>
Message-ID: <011847b9-fa03-4361-837b-155d58bf0729@raritan.com>

On 05.12.23 09:31, Miquel Raynal wrote:
> Upstream commit e0205d6203c2 ("spi: atmel: Prevent false timeouts on
> long transfers") has tried to mitigate the problem of getting spi
> transfers canceled because they were lasting too long. On slow buses,
> transfers in the MiB range can take more than one second and thus a
> calculation was added to progressively increment the timeout value. In
> order to not be too problematic from a user point of view (waiting dozen
> of seconds or even minutes), the wait call was turned interruptible.
>
> Turning the wait interruptible was a mistake as what we really wanted to
> do was to be able to kill a transfer. Any signal interrupting our
> transfer would not be suitable at all so a second attempt was made at
> turning the wait killable instead.
>
> Link: https://lore.kernel.org/linux-spi/20231127095842.389631-1-miquel.raynal at bootlin.com/
>
> All being well, it was reported that JFFS2 was showing a splat when
> interrupting a transfer. After some more debate about whether JFFS2
> should be fixed and how, it was also pointed out that the whole
> consistency of the filesystem in case of parallel I/O would be
> compromised. Changing JFFS2 behavior would in theory be possible but
> nobody has the energy and time and knowledge to do this now, so better
> prevent spi transfers to be interrupted by the user.
>
> Partially revert the blamed commit to no longer use the interruptible
> nor the killable variant of wait_for_completion().
>
> Fixes: e0205d6203c2 ("spi: atmel: Prevent false timeouts on long transfers")
> Cc: stable at vger.kernel.org

Tested-by: Ronald Wahl <ronald.wahl at raritan.com>

> Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>
> ---
>   drivers/spi/spi-atmel.c | 10 ++++------
>   1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 0197c25f5029..54277de30161 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1333,12 +1333,10 @@ static int atmel_spi_one_transfer(struct spi_controller *host,
>               }
>
>               dma_timeout = msecs_to_jiffies(spi_controller_xfer_timeout(host, xfer));
> -             ret_timeout = wait_for_completion_killable_timeout(&as->xfer_completion,
> -                                                                dma_timeout);
> -             if (ret_timeout <= 0) {
> -                     dev_err(&spi->dev, "spi transfer %s\n",
> -                             !ret_timeout ? "timeout" : "canceled");
> -                     as->done_status = ret_timeout < 0 ? ret_timeout : -EIO;
> +             ret_timeout = wait_for_completion_timeout(&as->xfer_completion, dma_timeout);
> +             if (!ret_timeout) {
> +                     dev_err(&spi->dev, "spi transfer timeout\n");
> +                     as->done_status = -EIO;
>               }
>
>               if (as->done_status)


________________________________

Ce message, ainsi que tous les fichiers joints ? ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas ?tre divulgu?es. Si vous n'?tes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier imm?diatement ? son exp?diteur, et de d?truire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autoris?e, directe ou indirecte, de tout ou partie de ce message, est strictement interdite.


This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden.


From krzysztof.kozlowski at linaro.org  Tue Dec  5 01:27:56 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 5 Dec 2023 10:27:56 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231205100246.5db0d6a1@aktux>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
 <20231205075657.GN5169@atomide.com>
 <df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>
 <20231205081031.GO5169@atomide.com>
 <efcd64f4-00d2-4671-af3a-e27764f70e8d@linaro.org>
 <20231205083001.GP5169@atomide.com>
 <27f2e3a3-0791-4278-adb2-55ed76820a3a@linaro.org>
 <20231205100246.5db0d6a1@aktux>
Message-ID: <78a81d54-f12c-401e-9a26-5125eb0b1c65@linaro.org>

On 05/12/2023 10:02, Andreas Kemnade wrote:
> On Tue, 5 Dec 2023 09:45:44 +0100
> Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> 
>>> Sure the clock nodes can be there for the child IP, but they won't do
>>> anything. And still need to be managed separately by the device driver if
>>> added.  
>>
>> So if OS does not have runtime PM, the bindings are wrong? Bindings
>> should not depend on some particular feature of some particular OS.
> 
> Any user of the devicetree sees that there is a parent and the parent needs
> to be enabled by some mechanism.
> E.g. I2c devices do not specify the clocks of the parent (the i2c master)

If you use this analogy, then compare it with an I2C device which has
these clock inputs. Such device must have clocks in the bindings.

> 
> Maybe it is just more fine-grained on omap.
> 
> look e.g. at ti/omap/omap4-l4.dtsi
> there are target-module at xxxx
> with the devices as a child and a clock in the parent.

Not related to runtime PM...

Best regards,
Krzysztof



From miquel.raynal at bootlin.com  Tue Dec  5 01:28:21 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Tue, 5 Dec 2023 10:28:21 +0100
Subject: [PATCH] spi: atmel: Prevent spi transfers from being killed
In-Reply-To: <1788823860.72909.1701768176780.JavaMail.zimbra@nod.at>
References: <20231205083102.16946-1-miquel.raynal@bootlin.com>
	<1788823860.72909.1701768176780.JavaMail.zimbra@nod.at>
Message-ID: <20231205102821.224ccbe6@xps-13>

Hi Richard,

richard at nod.at wrote on Tue, 5 Dec 2023 10:22:56 +0100 (CET):

> ----- Urspr?ngliche Mail -----
> > Von: "Miquel Raynal" <miquel.raynal at bootlin.com>
> > All being well, it was reported that JFFS2 was showing a splat when
> > interrupting a transfer. After some more debate about whether JFFS2
> > should be fixed and how, it was also pointed out that the whole
> > consistency of the filesystem in case of parallel I/O would be
> > compromised. Changing JFFS2 behavior would in theory be possible but
> > nobody has the energy and time and knowledge to do this now, so better
> > prevent spi transfers to be interrupted by the user.  
> 
> Well, it's not really an JFFS2 issue.
> The real problem is, that with the said change anyone can abort an IO.
> Usually file systems assume that an IO can only fail in fatal situations.
> That's why UBIFS, for example, switches immediately to read-only mode.
> So, an unprivileged user can force UBIFS into read-only mode, which is a
> local DoS attack vector.

Right.

> JFFS2, on the other hand, dies a different death. If you abort one IO,
> another IO path can still be active and will violate the order of written
> data.
> 
> Long story short, aborting pure user inflicted IO is fine. This is the "dd"
> use case.
> But as soon a filesystem is on top, things get complicated.
> 
> Maybe it is possible to teach the SPI subsystem whether an IO comes from spidev
> or the kernel itself?

Well, it would only partially fix the problem, I was playing with a
spi-nor or spi-nand chip (don't remember) which was supported in the
kernel, just making big reads/writes (without fs, at this time). I
don't think deliberating on whether the driver requesting the transfer
is in the kernel or in userspace matters, but whether there is a
filesystem on top or not. But TBH I don't think this can be solved
without ugly hacks...

Thanks,
Miqu?l


From ryan.roberts at arm.com  Tue Dec  5 01:34:23 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 5 Dec 2023 09:34:23 +0000
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <20231204113039.42510c23455026e40c5e2a56@linux-foundation.org>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204113039.42510c23455026e40c5e2a56@linux-foundation.org>
Message-ID: <2de0617e-d1d7-49ec-9cb8-206eaf37caed@arm.com>

On 04/12/2023 19:30, Andrew Morton wrote:
> On Mon,  4 Dec 2023 10:20:17 +0000 Ryan Roberts <ryan.roberts at arm.com> wrote:
> 
>> Hi All,
>>
>>
>> Prerequisites
>> =============
>>
>> Some work items identified as being prerequisites are listed on page 3 at [9].
>> The summary is:
>>
>> | item                          | status                  |
>> |:------------------------------|:------------------------|
>> | mlock                         | In mainline (v6.7)      |
>> | madvise                       | In mainline (v6.6)      |
>> | compaction                    | v1 posted [10]          |
>> | numa balancing                | Investigated: see below |
>> | user-triggered page migration | In mainline (v6.7)      |
>> | khugepaged collapse           | In mainline (NOP)       |
> 
> What does "prerequisites" mean here?  Won't compile without?  Kernel
> crashes without?  Nice-to-have-after?  Please expand on this.

Short answer: It's supposed to mean things that either need to be done to prevent the mm from regressing (both correctness and performance) when multi-size THP is present but disabled, or things that need to be done to make the mm robust (but not neccessarily optimially performant) when multi-size THP is enabled. But in reality, all of the things on the list could really be reclassified as "nice-to-have-after", IMHO; their absence will neither cause compilation nor runtime errors.

Longer answer: When I first started looking at this, I was advised that there were likely a number of corners which made assumptions about large folios always being PMD-sized, and if not found and fixed, could lead to stability issues. At the time I was also pursuing a strategy of multi-size THP being a compile-time feature with no runtime control, so I decided it was important for multi-size THP to not effectively disable other features (e.g. various madvise ops used to ignore PTE-mapped large folios). This list represents all the things that I could find based on code review, as well as things suggested by others, and in the end, they all fall into that last category of "PTE-mapped large folios efectively disable existing features". But given we now have runtime controls to opt-in to multi-size THP, I'm not sure we need to classify these as prerequisites. But I didn't want to unilaterally make that decision, given this list has previously been discussed and agreed by others.

It's also worth noting that in the case of compaction, that's already a problem for large folios in the page cache; large folios will be skipped.

> 
> I looked at [9], but access is denied.

Sorry about that; its owned by David Rientjes so I can't fix that for you. It's a PDF of a slide with the following table:

+-------------------------------+------------------------------------------------------------------------+--------------+--------------------+
| Item                          | Description                                                            | Assignee     | Status             |
+-------------------------------+------------------------------------------------------------------------+--------------+--------------------+
| mlock                         | Large, pte-mapped folios are ignored when mlock is requested.          | Yin, Fengwei | In mainline (v6.7) |
|                               | Code comment for mlock_vma_folio() says "...filter out pte mappings    |              |                    |
|                               | of THPs which cannot be consistently counted: a pte mapping of the     |              |                    |
|                               | THP head cannot be distinguished by the page alone."                   |              |                    |
| madvise                       | MADV_COLD, MADV_PAGEOUT, MADV_FREE: For large folios, code assumes     | Yin, Fengwei | In mainline (v6.6) |
|                               | exclusive only if mapcount==1, else skips remainder of operation.      |              |                    |
|                               | For large, pte-mapped folios, exclusive folios can have mapcount       |              |                    |
|                               | upto nr_pages and still be exclusive. Even better; don't split         |              |                    |
|                               | the folio if it fits entirely within the range.                        |              |                    |
| compaction                    | Raised at LSFMM: Compaction skips non-order-0 pages.                   | Zi Yan       | v1 posted          |
|                               | Already problem for page-cache pages today.                            |              |                    |
| numa balancing                | Large, pte-mapped folios are ignored by numa-balancing code. Commit    | John Hubbard | Investigated:      |
|                               | comment (e81c480): "We're going to have THP mapped with PTEs. It       |              | Not prerequisite   |
|                               | will confuse numabalancing. Let's skip them for now."                  |              |                    |
| user-triggered page migration | mm/migrate.c (migrate_pages syscall) We don't want to migrate folio    | Kefeng Wang  | In mainline (v6.7) |
|                               | that is shared.                                                        |              |                    |
| khugepaged collapse           | collapse small-sized THP to PMD-sized THP in khugepaged/MADV_COLLAPSE. | Ryan Roberts | In mainline (NOP)  |
|                               | Kirill thinks khugepage should already be able to collapse             |              |                    |
|                               | small large folios to PMD-sized THP; verification required.            |              |                    |
+-------------------------------+------------------------------------------------------------------------+--------------+--------------------+

Thanks,
Ryan

> 
>> [9] https://drive.google.com/file/d/1GnfYFpr7_c1kA41liRUW5YtCb8Cj18Ud/view?usp=sharing&resourcekey=0-U1Mj3-RhLD1JV6EThpyPyA
> 
> 



From n-francis at ti.com  Tue Dec  5 01:34:32 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Tue, 5 Dec 2023 15:04:32 +0530
Subject: [PATCH v9 0/7] Add TPS6594 PMIC support on several boards
Message-ID: <20231205093439.2298296-1-n-francis@ti.com>

TPS6594 is a Power Management IC which provides regulators and others
features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can
communicate through the I2C or SPI interfaces.
TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives.

This series adds device tree nodes for TI TPS6594 PMICs found in the
following boards:
- J721EXSOMXEVM:
  Link: https://www.ti.com/tool/J721EXSOMXEVM
- J721S2XSOMXEVM:
  Link: https://www.ti.com/tool/J721S2XSOMXEVM
- J7200XSOMXEVM:
  Link: https://www.ti.com/tool/J7200XSOMXEVM
- J784S4XEVM
  Link: https://www.ti.com/tool/J784S4XEVM
- SK-AM69
  Link: https://www.ti.com/tool/SK-AM69
- SK-TDA4VM (J721E-SK)
  Link: https://www.ti.com/tool/SK-TDA4VM

Boot Logs with required config (DONOTMERGE patch) enabled:
https://gist.github.com/nehamalcom/f47fcd6183360ed8a146c9ba456202c3
Boot Logs without config enabled:
https://gist.github.com/nehamalcom/58217b100e614ae55726f314e02b5001

---
Changes from v8:
https://lore.kernel.org/all/20231128055230.342547-4-n-francis at ti.com/
- added bootph-pre-ram to AVS regulator (Udit)
- keeping boot logs and Tested-by tags the same (no effect to kernel)

Changes from v7:
https://lore.kernel.org/all/20231122104513.2335757-1-n-francis at ti.com/
- (New Patches) Add support for SK boards that have TPS6594xx PMIC
  present (J721E-SK and AM69-SK) (Nishanth)
- Add DONOTMERGE defconfig patch to show test logs

Changes from v6:
https://lore.kernel.org/all/20230810-tps6594-v6-0-2b2e2399e2ef at ti.com/
- Modify patch series to include only patches not merged (J7)
- Add boot logs for all affected boards

Changes from v5:
https://lore.kernel.org/all/20230809-tps6594-v5-0-485fd3d63670 at ti.com
- Range-diff: http://0x0.st/H_fD.diff
- Reword the patch fixing interrupt ranges for mcu domain gpio intr, and
  add Fixes: tag
- Also fix interrupt ranges for main domain gpio intr in the same patch
- Change pinctrl node names to end in -pins to fix dtbs_check warnings
- (New Patch) Enable TPS6594 in defconfig

Changes from v4:
https://lore.kernel.org/all/20230727130908.10656-1-eblanc at baylibre.com/
- Range-diff: https://0x0.st/H_L7.diff
- Rebased on top of linux-next
- Fix min voltage on vdd_usb_3v3 regulator (ldo2) on j721e-som
- Use 3-hex-digit format for pinctrl values

Changes from v3:
https://lore.kernel.org/all/20230417154832.216774-1-eblanc at baylibre.com/
- Rebased on top of v6.5-rc1.
- Change pinctrl number for irq pin as wkup_pmx0 was split on some boards.
- Use already present wkup_i2c0 node instead of creating a new one.

Changes from v2:
https://lore.kernel.org/lkml/20230414112843.1358067-1-eblanc at baylibre.com/
- Change node name as per Krzysztof review.
- Add a fix for the interrupt range of wakeup gpio used by TPS6594 pmic
  on J784S4.
  The interruptions of the PMIC were not working before that.
- Remove dependencies on other patch series as that was a mistake, see
  https://lore.kernel.org/lkml/CRYY2V3HJ0CP.96JQ18PLZB3C at burritosblues/

Changes from v1:
https://lore.kernel.org/lkml/20230329142948.833800-1-eblanc at baylibre.com/
- Harmonize regulators names across the different boards.
- Adjust AVS voltage range.
- Remove some outdated comments.
- Add PMIC to J784S4 board.
- Compatible string modified to match dt-bindings.
- Add gpio-controller and gpio-cells properties.


Esteban Blanc (2):
  arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
  arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs

Jerome Neanne (2):
  arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
  arm64: dts: ti: k3-j784s4-evm: Add support for TPS6594 PMIC

Neha Malcom Francis (3):
  arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC
  arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs
  DONOTMERGE: arm64: defconfig: Enable TPS6594 PMIC for J7 devices

 arch/arm64/boot/dts/ti/k3-am69-sk.dts        | 100 +++++++++
 arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi  | 161 +++++++++++++++
 arch/arm64/boot/dts/ti/k3-j721e-sk.dts       | 158 +++++++++++++++
 arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi  | 167 +++++++++++++++
 arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 203 +++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-j784s4-evm.dts     | 104 ++++++++++
 arch/arm64/configs/defconfig                 |   2 +-
 7 files changed, 894 insertions(+), 1 deletion(-)

-- 
2.34.1



From n-francis at ti.com  Tue Dec  5 01:34:33 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Tue, 5 Dec 2023 15:04:33 +0530
Subject: [PATCH v9 1/7] arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
In-Reply-To: <20231205093439.2298296-1-n-francis@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
Message-ID: <20231205093439.2298296-2-n-francis@ti.com>

From: Esteban Blanc <eblanc at baylibre.com>

This patch adds support for TPS6594 PMIC family on wakup I2C0 bus.
Theses devices provides regulators (bucks and LDOs), but also
GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
which monitors the SoC error output signal, and a PFSM
(Pre-configurable Finite State Machine) which manages the
operational modes of the PMIC.

Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
Signed-off-by: Jai Luthra <j-luthra at ti.com>
Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 161 ++++++++++++++++++++
 1 file changed, 161 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
index 5a300d4c8ba0..327db681199c 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
@@ -127,6 +127,14 @@ J721E_WKUP_IOPAD(0x9c, PIN_INPUT_PULLUP, 0) /* (H21) WKUP_I2C0_SDA */
 	};
 };
 
+&wkup_pmx3 {
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		pinctrl-single,pins = <
+			J721E_WKUP_IOPAD(0x01c, PIN_INPUT, 7) /* (E18) WKUP_GPIO0_84 */
+		>;
+	};
+};
+
 &main_pmx0 {
 	main_i2c0_pins_default: main-i2c0-default-pins {
 		pinctrl-single,pins = <
@@ -255,6 +263,7 @@ exp_som: gpio at 21 {
 };
 
 &wkup_i2c0 {
+	bootph-pre-ram;
 	status = "okay";
 	pinctrl-names = "default";
 	pinctrl-0 = <&wkup_i2c0_pins_default>;
@@ -264,6 +273,158 @@ eeprom at 50 {
 		compatible = "atmel,24c256";
 		reg = <0x50>;
 	};
+
+	tps659414: pmic at 48 {
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		ti,primary-pmic;
+		system-power-controller;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <84 IRQ_TYPE_EDGE_FALLING>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck1-supply = <&vsys_3v3>;
+		buck2-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bucka1: buck1 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka2: buck2 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka3: buck3 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_phyio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd1_lpddr4_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vda_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vdd_wk_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_pll_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	lp876441: pmic at 4c {
+		bootph-pre-ram;
+		compatible = "ti,lp8764-q1";
+		reg = <0x4c>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <84 IRQ_TYPE_EDGE_FALLING>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck1-supply = <&vsys_3v3>;
+		buck2-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+
+		regulators: regulators {
+			bootph-pre-ram;
+			buckb1: buck1 {
+				bootph-pre-ram;
+				regulator-name = "vdd_cpu_avs";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <900000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			buckb2: buck2 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb3: buck3 {
+				regulator-name = "vdd_core_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb4: buck4 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &ospi0 {
-- 
2.34.1



From n-francis at ti.com  Tue Dec  5 01:34:34 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Tue, 5 Dec 2023 15:04:34 +0530
Subject: [PATCH v9 2/7] arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs
In-Reply-To: <20231205093439.2298296-1-n-francis@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
Message-ID: <20231205093439.2298296-3-n-francis@ti.com>

From: Esteban Blanc <eblanc at baylibre.com>

This patch adds support for TPS6594 PMIC family on wakup I2C0 bus.
Theses devices provides regulators (bucks and LDOs), but also
GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
which monitors the SoC error output signal, and a PFSM
(Pre-configurable Finite State Machine) which manages the
operational modes of the PMIC.

Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
Signed-off-by: Jai Luthra <j-luthra at ti.com>
Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 203 +++++++++++++++++++
 1 file changed, 203 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
index dcad372620b1..86f2416dfc02 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
@@ -172,6 +172,16 @@ J721S2_WKUP_IOPAD(0x004, PIN_INPUT, 0) /* (E20) MCU_OSPI0_LBCLKO */
 	};
 };
 
+&wkup_pmx1 {
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		bootph-pre-ram;
+		pinctrl-single,pins = <
+			/* (C21) MCU_OSPI1_CSn1.WKUP_GPIO0_39 */
+			J721S2_WKUP_IOPAD(0x028, PIN_INPUT, 7)
+		>;
+	};
+};
+
 &wkup_pmx2 {
 	wkup_i2c0_pins_default: wkup-i2c0-default-pins {
 		pinctrl-single,pins = <
@@ -208,6 +218,199 @@ eeprom at 50 {
 		compatible = "atmel,24c256";
 		reg = <0x50>;
 	};
+
+	tps659411: pmic at 48 {
+		bootph-pre-ram;
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		ti,primary-pmic;
+		system-power-controller;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck1234-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bootph-pre-ram;
+			bucka1234: buck1234 {
+				bootph-pre-ram;
+				regulator-name = "vdd_cpu_avs";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <900000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd_mcuwk_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcu_gpioret_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	tps659414: pmic at 4c {
+		compatible = "ti,tps6594-q1";
+		reg = <0x4c>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck1-supply = <&vsys_3v3>;
+		buck2-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			buckb1: buck1 {
+				regulator-name = "vdd_io_1v8_reg";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			buckb2: buck2 {
+				regulator-name = "vdd_fpd_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb3: buck3 {
+				regulator-name = "vdd_phy_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb4: buck4 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb5: buck5 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob1: ldo1 {
+				regulator-name = "vdd_wk_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob2: ldo2 {
+				regulator-name = "vdd_gpioret_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob3: ldo3 {
+				regulator-name = "vda_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob4: ldo4 {
+				regulator-name = "vda_pll_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	lp876411: pmic at 58 {
+		compatible = "ti,lp8764-q1";
+		reg = <0x58>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck1234-supply = <&vsys_3v3>;
+
+		regulators {
+			buckc1234: buck1234 {
+				regulator-name = "vdd_core_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &main_i2c0 {
-- 
2.34.1



From n-francis at ti.com  Tue Dec  5 01:34:35 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Tue, 5 Dec 2023 15:04:35 +0530
Subject: [PATCH v9 3/7] arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
In-Reply-To: <20231205093439.2298296-1-n-francis@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
Message-ID: <20231205093439.2298296-4-n-francis@ti.com>

From: Jerome Neanne <jneanne at baylibre.com>

This patch adds support for TPS6594 PMIC family on wakup I2C0 bus.
Theses devices provides regulators (bucks and LDOs), but also
GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
which monitors the SoC error output signal, and a PFSM
(Pre-configurable Finite State Machine) which manages the
operational modes of the PMIC.

Signed-off-by: Jerome Neanne <jneanne at baylibre.com>
Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
Signed-off-by: Jai Luthra <j-luthra at ti.com>
Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi | 167 ++++++++++++++++++++
 1 file changed, 167 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
index 7f0686c2ce37..901e34c6a131 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
@@ -152,6 +152,13 @@ J721E_WKUP_IOPAD(0xfc, PIN_INPUT_PULLUP, 0) /* (H24) WKUP_I2C0_SDA */
 		>;
 	};
 
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		bootph-pre-ram;
+		pinctrl-single,pins = <
+			J721E_WKUP_IOPAD(0x0d4, PIN_INPUT, 7) /* (G26) WKUP_GPIO0_9 */
+		>;
+	};
+
 	mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-default-pins {
 		pinctrl-single,pins = <
 			J721E_WKUP_IOPAD(0x0000, PIN_OUTPUT, 0) /* MCU_OSPI0_CLK */
@@ -199,6 +206,166 @@ eeprom at 50 {
 		compatible = "atmel,24c256";
 		reg = <0x50>;
 	};
+
+	tps659413: pmic at 48 {
+		bootph-pre-ram;
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+		ti,primary-pmic;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck12-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bootph-pre-ram;
+			bucka12: buck12 {
+				bootph-pre-ram;
+				regulator-name = "vdd_cpu_avs";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <900000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka3: buck3 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_phyio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd1_lpddr4_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vdda_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	tps659411: pmic at 4c {
+		compatible = "ti,tps6594-q1";
+		reg = <0x4c>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck1234-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			buckb1234: buck1234 {
+				regulator-name = "vdd_core_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb5: buck5 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob1: ldo1 {
+				regulator-name = "vdd_sd_dv";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob2: ldo2 {
+				regulator-name = "vdd_usb_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob3: ldo3 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob4: ldo4 {
+				regulator-name = "vda_pll_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &ospi0 {
-- 
2.34.1



From n-francis at ti.com  Tue Dec  5 01:34:36 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Tue, 5 Dec 2023 15:04:36 +0530
Subject: [PATCH v9 4/7] arm64: dts: ti: k3-j784s4-evm: Add support for TPS6594 PMIC
In-Reply-To: <20231205093439.2298296-1-n-francis@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
Message-ID: <20231205093439.2298296-5-n-francis@ti.com>

From: Jerome Neanne <jneanne at baylibre.com>

This patch adds support for TPS6593 PMIC on wkup I2C0 bus.
This device provides regulators (bucks and LDOs), but also
GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
which monitors the SoC error output signal, and a PFSM
(Pre-configurable Finite State Machine) which manages the
operational modes of the PMIC.

Signed-off-by: Jerome Neanne <jneanne at baylibre.com>
Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
Signed-off-by: Jai Luthra <j-luthra at ti.com>
Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 104 +++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
index f1f4c8634ab6..dbc75af48774 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
@@ -273,6 +273,10 @@ dp0_connector_in: endpoint {
 	};
 };
 
+&wkup_gpio0 {
+	status = "okay";
+};
+
 &main_pmx0 {
 	bootph-all;
 	main_uart8_pins_default: main-uart8-default-pins {
@@ -407,6 +411,17 @@ J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
 	};
 };
 
+&wkup_pmx1 {
+	status = "okay";
+
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		pinctrl-single,pins = <
+			/* (G33) MCU_OSPI1_CSn1.WKUP_GPIO0_39 */
+			J784S4_WKUP_IOPAD(0x028, PIN_INPUT, 7)
+		>;
+	};
+};
+
 &wkup_pmx0 {
 	bootph-all;
 	mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-default-pins {
@@ -471,6 +486,95 @@ eeprom at 50 {
 		compatible = "atmel,24c256";
 		reg = <0x50>;
 	};
+
+	tps659413: pmic at 48 {
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+		ti,primary-pmic;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck12-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bucka12: buck12 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka3: buck3 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcuio_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vds_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &mcu_uart0 {
-- 
2.34.1



From sudeep.holla at arm.com  Tue Dec  5 01:35:08 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue, 5 Dec 2023 09:35:08 +0000
Subject: [PATCH V2 6/7] coresight: stm: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <81cad3a6-a080-424c-ad0b-0f08c4fe51a2@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-7-anshuman.khandual@arm.com>
 <0adc3a16-0fc4-2a25-cd48-4667881b9490@arm.com>
 <e53cec31-9452-4c2a-a3a1-b6ef33be8e22@arm.com>
 <7825dcd4-94e1-7a5f-b388-90e748dfc47f@arm.com>
 <81cad3a6-a080-424c-ad0b-0f08c4fe51a2@arm.com>
Message-ID: <ZW7uzBS2diyEKldn@bogus>

On Tue, Dec 05, 2023 at 10:50:19AM +0530, Anshuman Khandual wrote:
> Something like this works ?
> 
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> index 3387ebc9d8ab..2b6834c4cac6 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -906,7 +906,7 @@ static int __stm_probe(struct device *dev, struct resource *res, void *dev_caps)
>         pm_runtime_put(dev);
>  
>         dev_info(&drvdata->csdev->dev, "%s initialized\n",
> -                (char *)dev_caps);
> +                dev_caps ? (char *)dev_caps: "STM");
>         return 0;
>  
>  cs_unregister:

Yes, looks good to me.

-- 
Regards,
Sudeep


From n-francis at ti.com  Tue Dec  5 01:34:37 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Tue, 5 Dec 2023 15:04:37 +0530
Subject: [PATCH v9 5/7] arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC
In-Reply-To: <20231205093439.2298296-1-n-francis@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
Message-ID: <20231205093439.2298296-6-n-francis@ti.com>

This patch adds support for TPS6594 PMIC on wkup I2C0 bus. This device
provides regulators (bucks and LDOs), but also GPIOs, a RTC, a watchdog,
an ESM (Error Signal Monitor) which monitors the SoC error output
signal, and a PFSM (Pre-configurable Finite State Machine) which manages
the operational modes of the PMIC.

Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
Tested-by: Manorit Chawdhry <m-chawdhry at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am69-sk.dts | 100 ++++++++++++++++++++++++++
 1 file changed, 100 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
index 9868c7049bfb..dec27acb4e96 100644
--- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
@@ -431,6 +431,17 @@ J784S4_IOPAD(0x000, PIN_INPUT, 7) /* (AN35) EXTINTN.GPIO0_0 */
 	};
 };
 
+&wkup_pmx1 {
+	status = "okay";
+
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		pinctrl-single,pins = <
+			/* (AA37) MCU_ADC1_AIN4.WKUP_GPIO0_83 */
+			J784S4_WKUP_IOPAD(0x12c, PIN_INPUT, 7)
+		>;
+	};
+};
+
 &wkup_pmx2 {
 	bootph-all;
 	wkup_uart0_pins_default: wkup-uart0-default-pins {
@@ -631,6 +642,95 @@ eeprom at 51 {
 		compatible = "atmel,24c512";
 		reg = <0x51>;
 	};
+
+	tps659413: pmic at 48 {
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+		ti,primary-pmic;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck12-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bucka12: buck12 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka3: buck3 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcuio_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vds_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &wkup_gpio0 {
-- 
2.34.1



From n-francis at ti.com  Tue Dec  5 01:34:38 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Tue, 5 Dec 2023 15:04:38 +0530
Subject: [PATCH v9 6/7] arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs
In-Reply-To: <20231205093439.2298296-1-n-francis@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
Message-ID: <20231205093439.2298296-7-n-francis@ti.com>

This patch adds support for TPS6594 PMIC family on wakeup I2C0 bus.
These devices provide regulators (bucks and LDOs), but also GPIOs, a
RTC, a watchdog, an ESM (Error Signal Monitor) which monitors the SoC
error output signal, and a PFSM (Pre-configurable Finite State Machine)
which manages the operational modes of the PMIC.

Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 158 +++++++++++++++++++++++++
 1 file changed, 158 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
index 42fe8eee9ec8..e600825f7e78 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
@@ -459,6 +459,13 @@ J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3) EXT_REFCLK1.GPIO1_12 */
 };
 
 &wkup_pmx0 {
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		bootph-pre-ram;
+		pinctrl-single,pins = <
+			J721E_WKUP_IOPAD(0x0cc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
+		>;
+	};
+
 	mcu_cpsw_pins_default: mcu-cpsw-default-pins {
 		pinctrl-single,pins = <
 			J721E_WKUP_IOPAD(0x84, PIN_INPUT, 0) /* (B24) MCU_RGMII1_RD0 */
@@ -560,6 +567,157 @@ eeprom at 51 {
 		compatible = "atmel,24c512";
 		reg = <0x51>;
 	};
+
+	tps659413: pmic at 48 {
+		bootph-pre-ram;
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+		ti,primary-pmic;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck123-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bootph-pre-ram;
+			bucka123: buck123 {
+				bootph-pre-ram;
+				regulator-name = "vdd_cpu_avs";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <900000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_phyio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd1_lpddr4_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vdda_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	tps659411: pmic at 4c {
+		compatible = "ti,tps6594-q1";
+		reg = <0x4c>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		buck1234-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			buckb1234: buck1234 {
+				regulator-name = "vdd_core_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb5: buck5 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob1: ldo1 {
+				regulator-name = "vdd_sd_dv";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob2: ldo2 {
+				regulator-name = "vdd_usb_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob3: ldo3 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob4: ldo4 {
+				regulator-name = "vda_pll_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &mcu_uart0 {
-- 
2.34.1



From n-francis at ti.com  Tue Dec  5 01:34:39 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Tue, 5 Dec 2023 15:04:39 +0530
Subject: [PATCH v9 7/7] DONOTMERGE: arm64: defconfig: Enable TPS6594 PMIC for J7 devices
In-Reply-To: <20231205093439.2298296-1-n-francis@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
Message-ID: <20231205093439.2298296-8-n-francis@ti.com>

J7 (J721E-EVM, J721E-SK, J721S2, AM68-SK, J784S4, AM69-SK) devices use
TPS6594x PMIC (interfaced over I2C) to power the SoC and various other
peripherals on the board [1].

Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/configs/defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b60aa1f89343..682251135267 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -727,7 +727,7 @@ CONFIG_MFD_SEC_CORE=y
 CONFIG_MFD_SL28CPLD=y
 CONFIG_RZ_MTU3=y
 CONFIG_MFD_TPS65219=y
-CONFIG_MFD_TPS6594_I2C=m
+CONFIG_MFD_TPS6594_I2C=y
 CONFIG_MFD_TI_AM335X_TSCADC=m
 CONFIG_MFD_ROHM_BD718XX=y
 CONFIG_MFD_WCD934X=m
-- 
2.34.1



From u.kleine-koenig at pengutronix.de  Tue Dec  5 01:41:18 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 5 Dec 2023 10:41:18 +0100
Subject: [PATCH 2/6] dt-bindings: pwm: samsung: add specific compatible
 for Tesla FSD
In-Reply-To: <20231205092229.19135-3-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
 <20231205092229.19135-3-krzysztof.kozlowski@linaro.org>
Message-ID: <20231205094118.jmzeyf23rv6gdiin@pengutronix.de>

Hello,

On Tue, Dec 05, 2023 at 10:22:25AM +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs.  Historically we
> kept the old (block's) compatible only.  This works fine and there is no
> bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add Tesla FSD compatible specific to be used with an existing fallback.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Acked-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/77a94b26/attachment.sig>

From andreas at kemnade.info  Tue Dec  5 01:43:43 2023
From: andreas at kemnade.info (Andreas Kemnade)
Date: Tue, 5 Dec 2023 10:43:43 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX
 GPUs
In-Reply-To: <78a81d54-f12c-401e-9a26-5125eb0b1c65@linaro.org>
References: <20231204182245.33683-1-afd@ti.com>
	<20231204182245.33683-2-afd@ti.com>
	<b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
	<20231205075657.GN5169@atomide.com>
	<df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>
	<20231205081031.GO5169@atomide.com>
	<efcd64f4-00d2-4671-af3a-e27764f70e8d@linaro.org>
	<20231205083001.GP5169@atomide.com>
	<27f2e3a3-0791-4278-adb2-55ed76820a3a@linaro.org>
	<20231205100246.5db0d6a1@aktux>
	<78a81d54-f12c-401e-9a26-5125eb0b1c65@linaro.org>
Message-ID: <20231205104343.2e3c4105@aktux>

On Tue, 5 Dec 2023 10:27:56 +0100
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

> On 05/12/2023 10:02, Andreas Kemnade wrote:
> > On Tue, 5 Dec 2023 09:45:44 +0100
> > Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> >   
> >>> Sure the clock nodes can be there for the child IP, but they won't do
> >>> anything. And still need to be managed separately by the device driver if
> >>> added.    
> >>
> >> So if OS does not have runtime PM, the bindings are wrong? Bindings
> >> should not depend on some particular feature of some particular OS.  
> > 
> > Any user of the devicetree sees that there is a parent and the parent needs
> > to be enabled by some mechanism.
> > E.g. I2c devices do not specify the clocks of the parent (the i2c master)  
> 
> If you use this analogy, then compare it with an I2C device which has
> these clock inputs. Such device must have clocks in the bindings.
> 
I would see target-module = i2c master.

Well, if there is a variant of the i2c device which does not require
external clocks and a variant which requires it, then clock can be
optional.

> > 
> > Maybe it is just more fine-grained on omap.
> > 
> > look e.g. at ti/omap/omap4-l4.dtsi
> > there are target-module at xxxx
> > with the devices as a child and a clock in the parent.  
> 
> Not related to runtime PM...
> 
Well, runtime PM is just the linux-specific mechanism to enable the
resources needed by the parent, so yes, it is not related... As said,
another OS can have another mechanism.

But anyways, the target module specifies resources which are required.

Regards,
Andreas


From linus.walleij at linaro.org  Tue Dec  5 01:47:43 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 5 Dec 2023 10:47:43 +0100
Subject: [PATCH] ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support
In-Reply-To: <93cc5193-aa1b-4df8-8d00-c3149c33b7e7@app.fastmail.com>
References: <20231204-drop-11mpcore-v1-1-f96cd3938cf1@linaro.org> <93cc5193-aa1b-4df8-8d00-c3149c33b7e7@app.fastmail.com>
Message-ID: <CACRpkdYcCh8TNBW-UJ1WhH-7sQMAw6xjx1FV6+bWGi2VmsTQHA@mail.gmail.com>

On Tue, Dec 5, 2023 at 8:00?AM Arnd Bergmann <arnd at arndb.de> wrote:

>  static const struct of_device_id realview_scu_match[] = {
> -       { .compatible = "arm,arm11mp-scu", },
>         { .compatible = "arm,cortex-a9-scu", },
>         { .compatible = "arm,cortex-a5-scu", },
>         { }
>
> I see that the arm,arm11mp-scu device is provided by
> arm-realview-eb-mp.dtsi, which in turn gets included
> by both arm-realview-eb-11mp.dts and arm-realview-eb-a9mp.dts,
> so the Cortex-A9 dtb ends up with the wrong compatible
> string at the moment.

Aha I need to make a separate DTS patch for that.

As stated in the commit message I don't know if RealView EB
is working very well on real hardware, I have only ever tested
it in QEMU.

> The driver doesn't care either way, and we can easily
> change the dtsi file use the Cortex-A9 compatibles
> later, but I think we probably want to leave the
> platsmp code to match the old string as well for
> compatibility with old dtb files.

The patch deletes the support for RealView EB ARM11MPCore
Kconfig as well so it should go I think? Or am I missing
something?

The Marvell MMP3 is also defining the "arm,arm11mp-scu"
but it's not using it for anything so I think it's just some bogus
copypaste error (Lubomir can maybe fill in) and should have its
own compatible.

BTW is the Marvell PJ4B a descendant of the XScale PXA? I
never manage to follow the lineage of these things.

Yours,
Linus Walleij


From ryan.roberts at arm.com  Tue Dec  5 01:50:14 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 5 Dec 2023 09:50:14 +0000
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <CAGsJ_4zU6pHOwEzCQxo9UWUFmHZp0pvfgF4pKbkFfDPCRyFwyw@mail.gmail.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
 <CAGsJ_4zU6pHOwEzCQxo9UWUFmHZp0pvfgF4pKbkFfDPCRyFwyw@mail.gmail.com>
Message-ID: <8adbde1c-970b-4a26-81b0-91b913c4850b@arm.com>

On 05/12/2023 04:21, Barry Song wrote:
> On Mon, Dec 4, 2023 at 11:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>>
>> In preparation for adding support for anonymous multi-size THP,
>> introduce new sysfs structure that will be used to control the new
>> behaviours. A new directory is added under transparent_hugepage for each
>> supported THP size, and contains an `enabled` file, which can be set to
>> "inherit" (to inherit the global setting), "always", "madvise" or
>> "never". For now, the kernel still only supports PMD-sized anonymous
>> THP, so only 1 directory is populated.
>>
>> The first half of the change converts transhuge_vma_suitable() and
>> hugepage_vma_check() so that they take a bitfield of orders for which
>> the user wants to determine support, and the functions filter out all
>> the orders that can't be supported, given the current sysfs
>> configuration and the VMA dimensions. If there is only 1 order set in
>> the input then the output can continue to be treated like a boolean;
>> this is the case for most call sites. The resulting functions are
>> renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
>> respectively.
>>
>> The second half of the change implements the new sysfs interface. It has
>> been done so that each supported THP size has a `struct thpsize`, which
>> describes the relevant metadata and is itself a kobject. This is pretty
>> minimal for now, but should make it easy to add new per-thpsize files to
>> the interface if needed in future (e.g. per-size defrag). Rather than
>> keep the `enabled` state directly in the struct thpsize, I've elected to
>> directly encode it into huge_anon_orders_[always|madvise|inherit]
>> bitfields since this reduces the amount of work required in
>> thp_vma_allowable_orders() which is called for every page fault.
>>
>> See Documentation/admin-guide/mm/transhuge.rst, as modified by this
>> commit, for details of how the new sysfs interface works.
>>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> 
> Reviewed-by: Barry Song <v-songbaohua at oppo.com>

Thanks!

> 
>> -khugepaged will be automatically started when
>> -transparent_hugepage/enabled is set to "always" or "madvise, and it'll
>> -be automatically shutdown if it's set to "never".
>> +khugepaged will be automatically started when one or more hugepage
>> +sizes are enabled (either by directly setting "always" or "madvise",
>> +or by setting "inherit" while the top-level enabled is set to "always"
>> +or "madvise"), and it'll be automatically shutdown when the last
>> +hugepage size is disabled (either by directly setting "never", or by
>> +setting "inherit" while the top-level enabled is set to "never").
>>
>>  Khugepaged controls
>>  -------------------
>>
>> +.. note::
>> +   khugepaged currently only searches for opportunities to collapse to
>> +   PMD-sized THP and no attempt is made to collapse to other THP
>> +   sizes.
> 
> For small-size THP, collapse is probably a bad idea. we like a one-shot
> try in Android especially we are using a 64KB and less large folio size. if
> PF succeeds in getting large folios, we map large folios, otherwise we
> give up as those memories can be quite unstably swapped-out, swapped-in
> and madvised to be DONTNEED.
> 
> too many compactions will increase power consumption and decrease UI
> response.

Understood; that's very useful information for the Android context. Multiple
people have made comments about eventually needing khugepaged (or something
similar) support in the server context though to async collapse to contpte size.
Actually one suggestion was a user space daemon that scans and collapses with
MADV_COLLAPSE. I suspect the key will be to ensure whatever solution we go for
is flexible and can be enabled/disabled/configured for the different environments.

> 
> Thanks
> Barry



From james.clark at arm.com  Tue Dec  5 01:54:58 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 5 Dec 2023 09:54:58 +0000
Subject: [PATCH v3 4/6] arm64: KVM: Add interface to set guest value for
 TRFCR register
In-Reply-To: <86msuqb84g.wl-maz@kernel.org>
References: <20231019165510.1966367-1-james.clark@arm.com>
 <20231019165510.1966367-5-james.clark@arm.com> <86msuqb84g.wl-maz@kernel.org>
Message-ID: <ce9caa4a-273f-4272-9c58-81b3e4d535de@arm.com>



On 04/12/2023 09:59, Marc Zyngier wrote:
> On Thu, 19 Oct 2023 17:55:02 +0100,
> James Clark <james.clark at arm.com> wrote:
>>
>> Add an interface for the Coresight driver to use to set the value of the
>> TRFCR register for the guest. This register controls the exclude
>> settings for trace at different exception levels, and is used to honor
>> the exclude_host and exclude_guest parameters from the Perf session.
>> This will be used to later write TRFCR_EL1 on nVHE at guest switch. For
>> VHE, the host trace is controlled by TRFCR_EL2 and thus we can write to
>> the TRFCR_EL1 immediately. Because guest writes to the register are
>> trapped, the value will persist and can't be modified.
>>
>> The settings must be copied to the vCPU before each run in the same
>> way that PMU events are, because the per-cpu struct isn't accessible in
>> protected mode.
> 
> Then maybe we should look at a better way of sharing global data
> between EL1 and EL2 instead of copying stuff ad-nauseam?
> 

That probably makes sense, I can have a look into that.

>>
>> Signed-off-by: James Clark <james.clark at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_host.h |  3 +++
>>  arch/arm64/kvm/arm.c              |  1 +
>>  arch/arm64/kvm/debug.c            | 26 ++++++++++++++++++++++++++
>>  3 files changed, 30 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 0f0bf8e641bd..e1852102550d 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -1125,6 +1125,8 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu);
>>  void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr);
>>  void kvm_clr_pmu_events(u32 clr);
>>  bool kvm_set_pmuserenr(u64 val);
>> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest);
>> +void kvm_etm_update_vcpu_events(struct kvm_vcpu *vcpu);
>>  #else
>>  static inline void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr) {}
>>  static inline void kvm_clr_pmu_events(u32 clr) {}
>> @@ -1132,6 +1134,7 @@ static inline bool kvm_set_pmuserenr(u64 val)
>>  {
>>  	return false;
>>  }
>> +static inline void kvm_etm_set_guest_trfcr(u64 trfcr_guest) {}
>>  #endif
>>  
>>  void kvm_vcpu_load_sysregs_vhe(struct kvm_vcpu *vcpu);
>> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
>> index 0f717b6a9151..e4d846f2f665 100644
>> --- a/arch/arm64/kvm/arm.c
>> +++ b/arch/arm64/kvm/arm.c
>> @@ -1015,6 +1015,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>>  		kvm_vgic_flush_hwstate(vcpu);
>>  
>>  		kvm_pmu_update_vcpu_events(vcpu);
>> +		kvm_etm_update_vcpu_events(vcpu);
>>  
>>  		/*
>>  		 * Ensure we set mode to IN_GUEST_MODE after we disable
>> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
>> index 20cdd40b3c42..2ab41b954512 100644
>> --- a/arch/arm64/kvm/debug.c
>> +++ b/arch/arm64/kvm/debug.c
>> @@ -23,6 +23,12 @@
>>  
>>  static DEFINE_PER_CPU(u64, mdcr_el2);
>>  
>> +/*
>> + * Per CPU value for TRFCR that should be applied to any guest vcpu that may
>> + * run on that core in the future.
>> + */
>> +static DEFINE_PER_CPU(u64, guest_trfcr);
>> +
>>  /**
>>   * save/restore_guest_debug_regs
>>   *
>> @@ -356,3 +362,23 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
>>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
>>  }
>> +
>> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest)
>> +{
>> +	if (has_vhe())
>> +		write_sysreg_s(trfcr_guest, SYS_TRFCR_EL12);
>> +	else
>> +		*this_cpu_ptr(&guest_trfcr) = trfcr_guest;
>> +}
>> +EXPORT_SYMBOL_GPL(kvm_etm_set_guest_trfcr);
> 
> How does the ETM code know what guests it impacts? Don't you have some
> per-process context already?
> 

It doesn't know what guests it impacts, it just does it blindly based on
host CPU and whatever guest might run on the CPU in the future. PMU
events are the same.

We do have per-process context for per-process sessions, so if that was
the VM process we might have been able to do something with that info.
But we also have per-cpu sessions that would trace anything that runs on
that CPU, so to be able to support that mode I think it has to be done
without knowing about any guest.

>> +
>> +/*
>> + * Updates the vcpu's view of the etm events for this cpu. Must be
>> + * called before every vcpu run after disabling interrupts, to ensure
>> + * that an interrupt cannot fire and update the structure.
>> + */
>> +void kvm_etm_update_vcpu_events(struct kvm_vcpu *vcpu)
>> +{
>> +	if (!has_vhe() && vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_TRFCR))
>> +		ctxt_sys_reg(&vcpu->arch.ctxt, TRFCR_EL1) = *this_cpu_ptr(&guest_trfcr);
>> +}
> 
> Why this requirement of updating it at all times? Why can't this be
> done in a more lazy way, using the flags to instruct the hypervisor
> what and when to load it?
> 
> 	M.
> 

I could probably add a flag that gets set if the guest value should be
different to the host value. I was just trying to keep it simple and in
terms of just what the registers should be.

The PMU one has something similar where it doesn't write anything if
kvm_pmu_switch_needed() is false, but that's only on the path where the
host sets the events, it still always does the copy in
kvm_pmu_update_vcpu_events() before the guest switch.

I suppose if I make the change to have the shared global data then the
copy isn't needed and this function and kvm_pmu_update_vcpu_events()
will just get deleted.

Thanks
James


From david at redhat.com  Tue Dec  5 01:57:41 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 10:57:41 +0100
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <8adbde1c-970b-4a26-81b0-91b913c4850b@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
 <CAGsJ_4zU6pHOwEzCQxo9UWUFmHZp0pvfgF4pKbkFfDPCRyFwyw@mail.gmail.com>
 <8adbde1c-970b-4a26-81b0-91b913c4850b@arm.com>
Message-ID: <c97d60cc-6c31-4da1-b519-86516008bb4c@redhat.com>

On 05.12.23 10:50, Ryan Roberts wrote:
> On 05/12/2023 04:21, Barry Song wrote:
>> On Mon, Dec 4, 2023 at 11:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>>>
>>> In preparation for adding support for anonymous multi-size THP,
>>> introduce new sysfs structure that will be used to control the new
>>> behaviours. A new directory is added under transparent_hugepage for each
>>> supported THP size, and contains an `enabled` file, which can be set to
>>> "inherit" (to inherit the global setting), "always", "madvise" or
>>> "never". For now, the kernel still only supports PMD-sized anonymous
>>> THP, so only 1 directory is populated.
>>>
>>> The first half of the change converts transhuge_vma_suitable() and
>>> hugepage_vma_check() so that they take a bitfield of orders for which
>>> the user wants to determine support, and the functions filter out all
>>> the orders that can't be supported, given the current sysfs
>>> configuration and the VMA dimensions. If there is only 1 order set in
>>> the input then the output can continue to be treated like a boolean;
>>> this is the case for most call sites. The resulting functions are
>>> renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
>>> respectively.
>>>
>>> The second half of the change implements the new sysfs interface. It has
>>> been done so that each supported THP size has a `struct thpsize`, which
>>> describes the relevant metadata and is itself a kobject. This is pretty
>>> minimal for now, but should make it easy to add new per-thpsize files to
>>> the interface if needed in future (e.g. per-size defrag). Rather than
>>> keep the `enabled` state directly in the struct thpsize, I've elected to
>>> directly encode it into huge_anon_orders_[always|madvise|inherit]
>>> bitfields since this reduces the amount of work required in
>>> thp_vma_allowable_orders() which is called for every page fault.
>>>
>>> See Documentation/admin-guide/mm/transhuge.rst, as modified by this
>>> commit, for details of how the new sysfs interface works.
>>>
>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>
>> Reviewed-by: Barry Song <v-songbaohua at oppo.com>
> 
> Thanks!
> 
>>
>>> -khugepaged will be automatically started when
>>> -transparent_hugepage/enabled is set to "always" or "madvise, and it'll
>>> -be automatically shutdown if it's set to "never".
>>> +khugepaged will be automatically started when one or more hugepage
>>> +sizes are enabled (either by directly setting "always" or "madvise",
>>> +or by setting "inherit" while the top-level enabled is set to "always"
>>> +or "madvise"), and it'll be automatically shutdown when the last
>>> +hugepage size is disabled (either by directly setting "never", or by
>>> +setting "inherit" while the top-level enabled is set to "never").
>>>
>>>   Khugepaged controls
>>>   -------------------
>>>
>>> +.. note::
>>> +   khugepaged currently only searches for opportunities to collapse to
>>> +   PMD-sized THP and no attempt is made to collapse to other THP
>>> +   sizes.
>>
>> For small-size THP, collapse is probably a bad idea. we like a one-shot
>> try in Android especially we are using a 64KB and less large folio size. if
>> PF succeeds in getting large folios, we map large folios, otherwise we
>> give up as those memories can be quite unstably swapped-out, swapped-in
>> and madvised to be DONTNEED.
>>
>> too many compactions will increase power consumption and decrease UI
>> response.
> 
> Understood; that's very useful information for the Android context. Multiple
> people have made comments about eventually needing khugepaged (or something
> similar) support in the server context though to async collapse to contpte size.
> Actually one suggestion was a user space daemon that scans and collapses with
> MADV_COLLAPSE. I suspect the key will be to ensure whatever solution we go for
> is flexible and can be enabled/disabled/configured for the different environments.

There certainly is interest for 2 MiB THP on arm64 64k where the THP 
size would normally be 512 MiB. In that scenario, khugepaged makes 
perfect sense.

-- 
Cheers,

David / dhildenb



From david at redhat.com  Tue Dec  5 01:59:55 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 10:59:55 +0100
Subject: [PATCH v8 09/10] selftests/mm/cow: Generalize do_run_with_thp()
 helper
In-Reply-To: <20231204102027.57185-10-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-10-ryan.roberts@arm.com>
Message-ID: <90b48085-9499-4449-8ee1-a1643ebc3016@redhat.com>

On 04.12.23 11:20, Ryan Roberts wrote:
> do_run_with_thp() prepares (PMD-sized) THP memory into different states
> before running tests. With the introduction of multi-size THP, we would
> like to reuse this logic to also test those smaller THP sizes. So let's
> add a thpsize parameter which tells the function what size THP it should
> operate on.
> 
> A separate commit will utilize this change to add new tests for
> multi-size THP, where available.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---

Reviewed-by: David Hildenbrand <david at redhat.com>

-- 
Cheers,

David / dhildenb



From suzuki.poulose at arm.com  Tue Dec  5 02:05:15 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 5 Dec 2023 10:05:15 +0000
Subject: [PATCH v3 3/6] arm64: KVM: Add iflag for FEAT_TRF
In-Reply-To: <86o7f6b8n8.wl-maz@kernel.org>
References: <20231019165510.1966367-1-james.clark@arm.com>
 <20231019165510.1966367-4-james.clark@arm.com> <86o7f6b8n8.wl-maz@kernel.org>
Message-ID: <6576da2f-4427-43ab-91e5-40508bf1e128@arm.com>

On 04/12/2023 09:48, Marc Zyngier wrote:
> On Thu, 19 Oct 2023 17:55:01 +0100,
> James Clark <james.clark at arm.com> wrote:
>>
>> Add an extra iflag to signify if the TRFCR register is accessible.
>> Because TRBE requires FEAT_TRF, DEBUG_STATE_SAVE_TRBE still has the same
>> behavior even though it's only set when FEAT_TRF is present.
>>
>> The following holes are left in struct kvm_vcpu_arch, but there aren't
>> enough other 8 bit fields to rearrange it to leave any hole smaller than
>> 7 bytes:
>>
>>    u8                         cflags;               /*  2292     1 */
>>    /* XXX 1 byte hole, try to pack */
>>    u16                        iflags;               /*  2294     2 */
>>    u8                         sflags;               /*  2296     1 */
>>    bool                       pause;                /*  2297     1 */
>>    /* XXX 6 bytes hole, try to pack */
>>
>> Signed-off-by: James Clark <james.clark at arm.com>
>> ---
>>   arch/arm64/include/asm/kvm_host.h |  4 +++-
>>   arch/arm64/kvm/debug.c            | 22 ++++++++++++++++++----
>>   2 files changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 7c82927ddaf2..0f0bf8e641bd 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -535,7 +535,7 @@ struct kvm_vcpu_arch {
>>   	u8 cflags;
>>   
>>   	/* Input flags to the hypervisor code, potentially cleared after use */
>> -	u8 iflags;
>> +	u16 iflags;
>>   
>>   	/* State flags for kernel bookkeeping, unused by the hypervisor code */
>>   	u8 sflags;
>> @@ -741,6 +741,8 @@ struct kvm_vcpu_arch {
>>   #define DEBUG_STATE_SAVE_TRBE	__vcpu_single_flag(iflags, BIT(6))
>>   /* vcpu running in HYP context */
>>   #define VCPU_HYP_CONTEXT	__vcpu_single_flag(iflags, BIT(7))
>> +/* Save trace filter controls */
>> +#define DEBUG_STATE_SAVE_TRFCR	__vcpu_single_flag(iflags, BIT(8))
>>   
>>   /* SVE enabled for host EL0 */
>>   #define HOST_SVE_ENABLED	__vcpu_single_flag(sflags, BIT(0))
>> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
>> index 8725291cb00a..20cdd40b3c42 100644
>> --- a/arch/arm64/kvm/debug.c
>> +++ b/arch/arm64/kvm/debug.c
>> @@ -331,14 +331,28 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
>>   	    !(read_sysreg_s(SYS_PMBIDR_EL1) & BIT(PMBIDR_EL1_P_SHIFT)))
>>   		vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_SPE);
>>   
>> -	/* Check if we have TRBE implemented and available at the host */
>> -	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceBuffer_SHIFT) &&
>> -	    !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P))
>> -		vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>> +	/*
>> +	 * Save TRFCR on nVHE if FEAT_TRF (TraceFilt) exists. This will be
>> +	 * done in cases where use of TRBE doesn't completely disable trace and
>> +	 * handles the exclude_host/exclude_guest rules of the trace session.
> 
> This comment provides zero information. What will be done? Under which
> conditions? What are the rules?
> 
>> +	 */
>> +	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceFilt_SHIFT)) {
>> +		vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
>> +		/*
>> +		 * Check if we have TRBE implemented and available at the host. If it's
>> +		 * in use at the time of guest switch it will need to be disabled and
>> +		 * then restored. The architecture mandates FEAT_TRF with TRBE, so we
>> +		 * only need to check for TRBE after TRF.
>> +		 */
>> +		if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceBuffer_SHIFT) &&
>> +		    !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P))
>> +			vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>> +	}
> 
> Multiple questions:
> 
> - Why is it safe to trust the local CPU's capability rather than the
>    consolidated view from the cpufeature infrastructure?

The coresight driver is capable of handling heterogeneous systems. i.e., 
some CPUs may not have FEAT_TRF or FEAT_TRBE. This could be for various
reasons (e.g., CPU Erratum disabling TRBE, though not used now). It 
already needs to treat each CPU differently (due to the capabilities
of the ETM).

That said, we could reject events with exclude_guest/exclude_host flags
on CPUs that do not support FEAT_TRF. But that doesn't solve checking
the local capability.

Suzuki


> 
> - Why defer the saving of the registers if there are no changes made
>    to them in the interval?
> 
> Thanks,
> 
> 	M.
> 



From suzuki.poulose at arm.com  Tue Dec  5 02:18:24 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 5 Dec 2023 10:18:24 +0000
Subject: [PATCH V2 6/7] coresight: stm: Move ACPI support from AMBA driver
 to platform driver
In-Reply-To: <81cad3a6-a080-424c-ad0b-0f08c4fe51a2@arm.com>
References: <20231201062053.1268492-1-anshuman.khandual@arm.com>
 <20231201062053.1268492-7-anshuman.khandual@arm.com>
 <0adc3a16-0fc4-2a25-cd48-4667881b9490@arm.com>
 <e53cec31-9452-4c2a-a3a1-b6ef33be8e22@arm.com>
 <7825dcd4-94e1-7a5f-b388-90e748dfc47f@arm.com>
 <81cad3a6-a080-424c-ad0b-0f08c4fe51a2@arm.com>
Message-ID: <5cbe90e1-e140-455a-8cc7-c5ebece64170@arm.com>

On 05/12/2023 05:20, Anshuman Khandual wrote:
> 
> 
> On 12/4/23 18:47, James Clark wrote:
>>
>>
>> On 04/12/2023 11:50, Anshuman Khandual wrote:
>>>
>>>
>>> On 12/4/23 15:53, James Clark wrote:
>>>>
>>>>
>>>> On 01/12/2023 06:20, Anshuman Khandual wrote:
>>>>> Add support for the stm devices in the platform driver, which can then be
>>>>> used on ACPI based platforms. This change would now allow runtime power
>>>>> management for ACPI based systems. The driver would try to enable the APB
>>>>> clock if available.
>>>>>
>>>>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>>>>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>>>>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>>>>> Cc: Mike Leach <mike.leach at linaro.org>
>>>>> Cc: James Clark <james.clark at arm.com>
>>>>> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
>>>>> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
>>>>> Cc: linux-acpi at vger.kernel.org
>>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>>> Cc: linux-kernel at vger.kernel.org
>>>>> Cc: coresight at lists.linaro.org
>>>>> Cc: linux-stm32 at st-md-mailman.stormreply.com
>>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>>>> ---
>>>> [...]
>>>>>   
>>>>> -module_amba_driver(stm_driver);
>>>>> +static int stm_platform_probe(struct platform_device *pdev)
>>>>> +{
>>>>> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>> +	int ret = 0;
>>>>> +
>>>>> +	pm_runtime_get_noresume(&pdev->dev);
>>>>> +	pm_runtime_set_active(&pdev->dev);
>>>>> +	pm_runtime_enable(&pdev->dev);
>>>>> +
>>>>> +	ret = __stm_probe(&pdev->dev, res, NULL);
>>>>
>>>> Very minor nit, but this used to print this:
>>>>
>>>>    coresight stm0: STM500 initialized
>>>>
>>>> And now it prints this:
>>>>
>>>>    coresight stm0: (null) initialized
>>>>
>>>> (null) kind of makes it look a little bit like something has gone wrong.
>>>> Maybe we could just put "initialised" if you don't have a string from ACPI?
>>>
>>> __stm_probe() gets called from both AMBA and platform driver paths. Even though
>>> a NULL check inside dev_info(..."%s initialized\n",...) could be added, but how
>>> to differentiate it from a scenario when coresight_get_uci_data() returns NULL ?
>>
>> Sudeep's suggestion seems ok, just add a hard coded string instead of
>> the NULL. And keep the coresight_get_uci_data() the same.
> 
> Something like this works ?
> 
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> index 3387ebc9d8ab..2b6834c4cac6 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -906,7 +906,7 @@ static int __stm_probe(struct device *dev, struct resource *res, void *dev_caps)
>          pm_runtime_put(dev);
>   
>          dev_info(&drvdata->csdev->dev, "%s initialized\n",
> -                (char *)dev_caps);
> +                dev_caps ? (char *)dev_caps: "STM");
>          return 0;
>   

Please could stop abusing the private data for storing the name ? 
Instead, we could read the PID of the device and use a table to map
it to the name and use that instead ?

Suzuki


>   cs_unregister:
> 



From tabba at google.com  Tue Dec  5 02:22:42 2023
From: tabba at google.com (Fuad Tabba)
Date: Tue,  5 Dec 2023 10:22:42 +0000
Subject: [PATCH v1 0/6] KVM: arm64: Fixes to fine grain traps and pKVM traps
Message-ID: <20231205102248.1915895-1-tabba@google.com>

This patch series has fixes, updates, and code for validating
fine grain trap register masks, as well as some fixes to feature
trapping in pKVM.

New fine grain trap (FGT) bits have been defined in the latest
Arm Architecture System Registers xml specification (2023-09)
[*], so the code is updated to reflect them. Moreover, some of
the already-defined masks overlap with res0, which this series
fixes. It also adds FGT register masks that weren't defined
earlier, as well as build time validation that the bits of the
various masks are all accounted for and without overlap.

Based on 6.7-rc4.

Cheers,
/fuad

[*] https://developer.arm.com/downloads/-/exploration-tools

Fuad Tabba (6):
  KVM: arm64: Update and fix FGT register masks
  KVM: arm64: Add bit masks for HAFGRTR_EL2
  KVM: arm64: Add build validation for trap mask values
  KVM: arm64: Calculate FGT RES0 Bits
  KVM: arm64: Trap external trace for protected VMs
  KVM: arm64: Mark features as supported for protected VMs

 arch/arm64/include/asm/kvm_arm.h              | 56 +++++++++++--------
 arch/arm64/kvm/hyp/include/hyp/switch.h       | 16 ++++++
 .../arm64/kvm/hyp/include/nvhe/fixed_config.h |  4 +-
 arch/arm64/kvm/hyp/nvhe/pkvm.c                |  4 ++
 arch/arm64/tools/sysreg                       |  5 +-
 5 files changed, 59 insertions(+), 26 deletions(-)


base-commit: 33cc938e65a98f1d29d0a18403dbbee050dcad9a
-- 
2.43.0.rc2.451.g8631bc7472-goog



From angelogioacchino.delregno at collabora.com  Tue Dec  5 02:22:46 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 5 Dec 2023 11:22:46 +0100
Subject: [RFC PATCH v3 4/5] arm64: dts: mediatek: mt8173-elm-hana: Mark
 touchscreens and trackpads as fail
In-Reply-To: <CAD=FV=UQkAjgMuR85cPikNtCxsODWPWs7cibOcOoNGdjSSvF8Q@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org>
 <20231128084236.157152-5-wenst@chromium.org>
 <CAD=FV=W01gfxV6RN2o6CVS7jjf8qgKP-jUy9Bp94d2hWzVC48A@mail.gmail.com>
 <CAGXv+5E+R292XsOFSL-j0KJMmVJjWtxMRgCK8besP7mo6NDOWA@mail.gmail.com>
 <CAD=FV=UQkAjgMuR85cPikNtCxsODWPWs7cibOcOoNGdjSSvF8Q@mail.gmail.com>
Message-ID: <3700f05f-2411-4422-972f-f3df690efb84@collabora.com>

Il 04/12/23 17:50, Doug Anderson ha scritto:
> Hi,
> 
> On Sun, Dec 3, 2023 at 10:59?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>>
>> On Sat, Dec 2, 2023 at 8:58?AM Doug Anderson <dianders at chromium.org> wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
>>>>
>>>> @@ -44,6 +46,7 @@ trackpad2: trackpad at 2c {
>>>>                  reg = <0x2c>;
>>>>                  hid-descr-addr = <0x0020>;
>>>>                  wakeup-source;
>>>> +               status = "fail-needs-probe";
>>>
>>> While doing this, you could also remove the hack where the trackpad
>>> IRQ pinctrl is listed under i2c4.
>>
>> Sure. I do think we can do away with it though. According to at least one
>> schematic, the interrupt line has pull-ups on both sides of the voltage
>> shifter.
>>
>> BTW, The touchscreen doesn't have pinctrl entries. This has pull-ups on
>> both sides of the voltage shifter as well.
> 
> I dunno if the convention is different on Mediatek boards, but at
> least on boards I've been involved with in the past we've always put
> pinctrl entries just to make things explicit. This meant that we
> didn't rely on the firmware/bootrom/defaults to leave pulls in any
> particular state. ...otherwise those external pull-ups could be
> fighting with internal pull-downs, right?
> 

MediaTek boards aren't special and there's no good reason for those to rely on
firmware/bootrom/defaults - so there is no good reason to avoid declaring any
relevant pinctrl entry.

Cheers,
Angelo



From tabba at google.com  Tue Dec  5 02:22:43 2023
From: tabba at google.com (Fuad Tabba)
Date: Tue,  5 Dec 2023 10:22:43 +0000
Subject: [PATCH v1 1/6] KVM: arm64: Update and fix FGT register masks
In-Reply-To: <20231205102248.1915895-1-tabba@google.com>
References: <20231205102248.1915895-1-tabba@google.com>
Message-ID: <20231205102248.1915895-2-tabba@google.com>

New trap bits have been defined in the latest Arm Architecture
System Registers xml specification [*]. Moreover, the existing
definitions of some of the mask and the res0 bits overlap, which
could be wrong, confusing, or potentially both.

Update the bits to represent the latest spec (as of this patch),
and ensure that the existing bits are consistent.

[*] https://developer.arm.com/downloads/-/exploration-tools

Fixes: 0fd76865006d ("KVM: arm64: Add nPIR{E0}_EL1 to HFG traps")
Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 39 ++++++++++++++++++++------------
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index b85f46a73e21..b1061647e837 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -344,36 +344,45 @@
  * Once we get to a point where the two describe the same thing, we'll
  * merge the definitions. One day.
  */
-#define __HFGRTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51))
+#define __HFGRTR_EL2_RES0	BIT(51)
 #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
-#define __HFGRTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
+#define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
 
-#define __HFGWTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51) |	\
-				 BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
-				 GENMASK(26, 25) | BIT(21) | BIT(18) |	\
+#define __HFGWTR_EL2_RES0	(BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
+				 BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
 				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
-#define __HFGWTR_EL2_MASK	GENMASK(49, 0)
-#define __HFGWTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
+#define __HFGWTR_EL2_MASK	(GENMASK(49, 47) | GENMASK(45, 43) | \
+				 BIT(41) | GENMASK(39, 29) | BIT(27) | \
+				 GENMASK(24, 22) | GENMASK(20, 19) | \
+				 GENMASK(17, 16) | GENMASK(13, 11) | \
+				 GENMASK(8, 3) | GENMASK(1, 0))
+#define __HFGWTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
 
-#define __HFGITR_EL2_RES0	GENMASK(63, 57)
-#define __HFGITR_EL2_MASK	GENMASK(54, 0)
-#define __HFGITR_EL2_nMASK	GENMASK(56, 55)
+#define __HFGITR_EL2_RES0	(BIT(63) | BIT(61))
+#define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
+#define __HFGITR_EL2_nMASK	GENMASK(59, 55)
 
 #define __HDFGRTR_EL2_RES0	(BIT(49) | BIT(42) | GENMASK(39, 38) |	\
 				 GENMASK(21, 20) | BIT(8))
-#define __HDFGRTR_EL2_MASK	~__HDFGRTR_EL2_nMASK
+#define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
+				 GENMASK(41, 40) | GENMASK(37, 22) | \
+				 GENMASK(19, 9) | GENMASK(7, 0))
 #define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
 
 #define __HDFGWTR_EL2_RES0	(BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
 				 BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
 				 BIT(22) | BIT(9) | BIT(6))
-#define __HDFGWTR_EL2_MASK	~__HDFGWTR_EL2_nMASK
+#define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
+				 GENMASK(46, 44) | GENMASK(42, 41) | \
+				 GENMASK(37, 35) | GENMASK(33, 31) | \
+				 GENMASK(29, 23) | GENMASK(21, 10) | \
+				 GENMASK(8, 7) | GENMASK(5, 0))
 #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
 
 /* Similar definitions for HCRX_EL2 */
-#define __HCRX_EL2_RES0		(GENMASK(63, 16) | GENMASK(13, 12))
-#define __HCRX_EL2_MASK		(0)
-#define __HCRX_EL2_nMASK	(GENMASK(15, 14) | GENMASK(4, 0))
+#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
+#define __HCRX_EL2_MASK		(BIT(6))
+#define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
 
 /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
 #define HPFAR_MASK	(~UL(0xf))
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Tue Dec  5 02:22:44 2023
From: tabba at google.com (Fuad Tabba)
Date: Tue,  5 Dec 2023 10:22:44 +0000
Subject: [PATCH v1 2/6] KVM: arm64: Add bit masks for HAFGRTR_EL2
In-Reply-To: <20231205102248.1915895-1-tabba@google.com>
References: <20231205102248.1915895-1-tabba@google.com>
Message-ID: <20231205102248.1915895-3-tabba@google.com>

The HAFGRTR_EL2 register isn't used yet, but it will be in future
patches. It's also the only FGT register remaining (not including
FGT2 registers).

Add the masks for completeness and future patches. The definition
is from the latest Arm Architecture System Registers xml
specification [*].

[*] https://developer.arm.com/downloads/-/exploration-tools

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index b1061647e837..b0dc3249d5cd 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -379,6 +379,10 @@
 				 GENMASK(8, 7) | GENMASK(5, 0))
 #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
 
+#define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
+#define __HAFGRTR_EL2_MASK	(GENMASK(49, 17) | GENMASK(4, 0))
+#define __HAFGRTR_EL2_nMASK	0UL
+
 /* Similar definitions for HCRX_EL2 */
 #define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
 #define __HCRX_EL2_MASK		(BIT(6))
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Tue Dec  5 02:22:45 2023
From: tabba at google.com (Fuad Tabba)
Date: Tue,  5 Dec 2023 10:22:45 +0000
Subject: [PATCH v1 3/6] KVM: arm64: Add build validation for trap mask values
In-Reply-To: <20231205102248.1915895-1-tabba@google.com>
References: <20231205102248.1915895-1-tabba@google.com>
Message-ID: <20231205102248.1915895-4-tabba@google.com>

These checks help ensure that all the bits are accounted for, and
that there hasn't been a transcribing error from the spec.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/include/hyp/switch.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index f99d8af0b9af..2c6e8cbbd081 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -79,6 +79,16 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
 		clr |= ~hfg & __ ## reg ## _nMASK; 			\
 	} while(0)
 
+/*
+ * Validate the fine grain trap masks.
+ * Check that the masks do not overlap and that all bits are accounted for.
+ */
+#define CHECK_FGT_MASKS(reg)							\
+	do {									\
+		BUILD_BUG_ON((__ ## reg ## _MASK) & (__ ## reg ## _nMASK));	\
+		BUILD_BUG_ON(~((__ ## reg ## _RES0) ^ (__ ## reg ## _MASK) ^	\
+			       (__ ## reg ## _nMASK)));				\
+	} while(0)
 
 static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 {
@@ -86,6 +96,14 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 	u64 r_clr = 0, w_clr = 0, r_set = 0, w_set = 0, tmp;
 	u64 r_val, w_val;
 
+	CHECK_FGT_MASKS(HFGRTR_EL2);
+	CHECK_FGT_MASKS(HFGWTR_EL2);
+	CHECK_FGT_MASKS(HFGITR_EL2);
+	CHECK_FGT_MASKS(HDFGRTR_EL2);
+	CHECK_FGT_MASKS(HDFGWTR_EL2);
+	CHECK_FGT_MASKS(HAFGRTR_EL2);
+	CHECK_FGT_MASKS(HCRX_EL2);
+
 	if (!cpus_have_final_cap(ARM64_HAS_FGT))
 		return;
 
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Tue Dec  5 02:22:46 2023
From: tabba at google.com (Fuad Tabba)
Date: Tue,  5 Dec 2023 10:22:46 +0000
Subject: [PATCH v1 4/6] KVM: arm64: Calculate FGT RES0 Bits
In-Reply-To: <20231205102248.1915895-1-tabba@google.com>
References: <20231205102248.1915895-1-tabba@google.com>
Message-ID: <20231205102248.1915895-5-tabba@google.com>

All FGT reserved bits are res0, and they are the ones remaining
after accounting for all defined trap bits. Now that we have full
coverage of the trap bits, calculate the res0 bits based on the
other bits.

No functional change intended.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h        | 19 +++++++------------
 arch/arm64/kvm/hyp/include/hyp/switch.h |  2 --
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index b0dc3249d5cd..44bbbb4110d3 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -344,49 +344,44 @@
  * Once we get to a point where the two describe the same thing, we'll
  * merge the definitions. One day.
  */
-#define __HFGRTR_EL2_RES0	BIT(51)
 #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
 #define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
+#define __HFGRTR_EL2_RES0	~(__HFGRTR_EL2_MASK | __HFGRTR_EL2_nMASK)
 
-#define __HFGWTR_EL2_RES0	(BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
-				 BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
-				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
 #define __HFGWTR_EL2_MASK	(GENMASK(49, 47) | GENMASK(45, 43) | \
 				 BIT(41) | GENMASK(39, 29) | BIT(27) | \
 				 GENMASK(24, 22) | GENMASK(20, 19) | \
 				 GENMASK(17, 16) | GENMASK(13, 11) | \
 				 GENMASK(8, 3) | GENMASK(1, 0))
 #define __HFGWTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
+#define __HFGWTR_EL2_RES0	~(__HFGWTR_EL2_MASK | __HFGWTR_EL2_nMASK)
 
-#define __HFGITR_EL2_RES0	(BIT(63) | BIT(61))
 #define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
 #define __HFGITR_EL2_nMASK	GENMASK(59, 55)
+#define __HFGITR_EL2_RES0	~(__HFGITR_EL2_MASK | __HFGITR_EL2_nMASK)
 
-#define __HDFGRTR_EL2_RES0	(BIT(49) | BIT(42) | GENMASK(39, 38) |	\
-				 GENMASK(21, 20) | BIT(8))
 #define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
 				 GENMASK(41, 40) | GENMASK(37, 22) | \
 				 GENMASK(19, 9) | GENMASK(7, 0))
 #define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
+#define __HDFGRTR_EL2_RES0	~(__HDFGRTR_EL2_MASK | __HDFGRTR_EL2_nMASK)
 
-#define __HDFGWTR_EL2_RES0	(BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
-				 BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
-				 BIT(22) | BIT(9) | BIT(6))
 #define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
 				 GENMASK(46, 44) | GENMASK(42, 41) | \
 				 GENMASK(37, 35) | GENMASK(33, 31) | \
 				 GENMASK(29, 23) | GENMASK(21, 10) | \
 				 GENMASK(8, 7) | GENMASK(5, 0))
 #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
+#define __HDFGWTR_EL2_RES0	~(__HDFGWTR_EL2_MASK | __HDFGWTR_EL2_nMASK)
 
-#define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
 #define __HAFGRTR_EL2_MASK	(GENMASK(49, 17) | GENMASK(4, 0))
 #define __HAFGRTR_EL2_nMASK	0UL
+#define __HAFGRTR_EL2_RES0	~(__HAFGRTR_EL2_MASK | __HAFGRTR_EL2_nMASK)
 
 /* Similar definitions for HCRX_EL2 */
-#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
 #define __HCRX_EL2_MASK		(BIT(6))
 #define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
+#define __HCRX_EL2_RES0         ~(__HCRX_EL2_MASK | __HCRX_EL2_nMASK)
 
 /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
 #define HPFAR_MASK	(~UL(0xf))
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 2c6e8cbbd081..bf045dc32996 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -86,8 +86,6 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
 #define CHECK_FGT_MASKS(reg)							\
 	do {									\
 		BUILD_BUG_ON((__ ## reg ## _MASK) & (__ ## reg ## _nMASK));	\
-		BUILD_BUG_ON(~((__ ## reg ## _RES0) ^ (__ ## reg ## _MASK) ^	\
-			       (__ ## reg ## _nMASK)));				\
 	} while(0)
 
 static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Tue Dec  5 02:22:47 2023
From: tabba at google.com (Fuad Tabba)
Date: Tue,  5 Dec 2023 10:22:47 +0000
Subject: [PATCH v1 5/6] KVM: arm64: Trap external trace for protected VMs
In-Reply-To: <20231205102248.1915895-1-tabba@google.com>
References: <20231205102248.1915895-1-tabba@google.com>
Message-ID: <20231205102248.1915895-6-tabba@google.com>

pKVM does not support external trace for protected VMs.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++++
 arch/arm64/tools/sysreg        | 5 ++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 9d23a51d7f75..84b5c3f387d8 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -136,6 +136,10 @@ static void pvm_init_traps_aa64dfr0(struct kvm_vcpu *vcpu)
 			cptr_set |= CPTR_EL2_TTA;
 	}
 
+	/* Trap External Trace */
+	if (!FIELD_GET(ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_ExtTrcBuff), feature_ids))
+		mdcr_clear |= MDCR_EL2_E2TB_MASK << MDCR_EL2_E2TB_SHIFT;
+
 	vcpu->arch.mdcr_el2 |= mdcr_set;
 	vcpu->arch.mdcr_el2 &= ~mdcr_clear;
 	vcpu->arch.cptr_el2 |= cptr_set;
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 96cbeeab4eec..02e1a4290fa5 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1115,7 +1115,10 @@ Enum	63:60	HPMN0
 	0b0000	UNPREDICTABLE
 	0b0001	DEF
 EndEnum
-Res0	59:56
+UnsignedEnum	59:56	ExtTrcBuff
+	0b0000	NI
+	0b0001	IMP
+EndEnum
 UnsignedEnum	55:52	BRBE
 	0b0000	NI
 	0b0001	IMP
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Tue Dec  5 02:22:48 2023
From: tabba at google.com (Fuad Tabba)
Date: Tue,  5 Dec 2023 10:22:48 +0000
Subject: [PATCH v1 6/6] KVM: arm64: Mark features as supported for protected VMs
In-Reply-To: <20231205102248.1915895-1-tabba@google.com>
References: <20231205102248.1915895-1-tabba@google.com>
Message-ID: <20231205102248.1915895-7-tabba@google.com>

Add features supported for protected VMs to the allow list.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/include/nvhe/fixed_config.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
index e91922daa8ca..e628541585fc 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
@@ -101,6 +101,7 @@
  * - Privileged Access Never
  * - SError interrupt exceptions from speculative reads
  * - Enhanced Translation Synchronization
+ * - Control for cache maintenance permission
  */
 #define PVM_ID_AA64MMFR1_ALLOW (\
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_HAFDBS) | \
@@ -108,7 +109,8 @@
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_HPDS) | \
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_PAN) | \
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_SpecSEI) | \
-	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_ETS) \
+	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_ETS) | \
+	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_CMOW) \
 	)
 
 /*
-- 
2.43.0.rc2.451.g8631bc7472-goog



From arnd at arndb.de  Tue Dec  5 02:32:03 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 05 Dec 2023 11:32:03 +0100
Subject: [PATCH] ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support
In-Reply-To: <CACRpkdYcCh8TNBW-UJ1WhH-7sQMAw6xjx1FV6+bWGi2VmsTQHA@mail.gmail.com>
References: <20231204-drop-11mpcore-v1-1-f96cd3938cf1@linaro.org>
 <93cc5193-aa1b-4df8-8d00-c3149c33b7e7@app.fastmail.com>
 <CACRpkdYcCh8TNBW-UJ1WhH-7sQMAw6xjx1FV6+bWGi2VmsTQHA@mail.gmail.com>
Message-ID: <5b0eb64c-fb0c-4bb1-a10e-733d496ac2be@app.fastmail.com>

On Tue, Dec 5, 2023, at 10:47, Linus Walleij wrote:
> On Tue, Dec 5, 2023 at 8:00?AM Arnd Bergmann <arnd at arndb.de> wrote:
>
>>  static const struct of_device_id realview_scu_match[] = {
>> -       { .compatible = "arm,arm11mp-scu", },
>>         { .compatible = "arm,cortex-a9-scu", },
>>         { .compatible = "arm,cortex-a5-scu", },
>>         { }
>>
>> I see that the arm,arm11mp-scu device is provided by
>> arm-realview-eb-mp.dtsi, which in turn gets included
>> by both arm-realview-eb-11mp.dts and arm-realview-eb-a9mp.dts,
>> so the Cortex-A9 dtb ends up with the wrong compatible
>> string at the moment.
>
> Aha I need to make a separate DTS patch for that.
>
> As stated in the commit message I don't know if RealView EB
> is working very well on real hardware, I have only ever tested
> it in QEMU.

I think that is true for most users, and I see that
the Cortex-A9 variant of RealView EB doesn't even
have a separate qemu model other than possibly
"qemu-system-arm -M realview-eb-mpcore -cpu cortex-a9".

In this case, the easiest solution is probably to
kill off CONFIG_REALVIEW_EB_A9MP and its dts file
as well, since that is even less likely to have any
users.

>> The driver doesn't care either way, and we can easily
>> change the dtsi file use the Cortex-A9 compatibles
>> later, but I think we probably want to leave the
>> platsmp code to match the old string as well for
>> compatibility with old dtb files.
>
> The patch deletes the support for RealView EB ARM11MPCore
> Kconfig as well so it should go I think? Or am I missing
> something?

I was talking about EB_A9MP, not EB_ARM11MP here.

> The Marvell MMP3 is also defining the "arm,arm11mp-scu"
> but it's not using it for anything so I think it's just some bogus
> copypaste error (Lubomir can maybe fill in) and should have its
> own compatible.

Right, my impression is that these bits of MMP3
are all copied from realview.

> BTW is the Marvell PJ4B a descendant of the XScale PXA? I
> never manage to follow the lineage of these things.

Not really: while the MMP SoC design is a follow-up to
Intel PXA (using XScale), the later Marvell PXA and MMP
switched over the Sheeva line of CPU cores that
originally came from Marvell Orion/Kirkwood. The earlier
cores were ARMv5 and some even supported Intel's iWMMXt
FPU, the later PJ4 ones were ARMv7 with VFP but were
based on the same microarchitecture.

     Arnd


From fancer.lancer at gmail.com  Tue Dec  5 02:35:32 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue,  5 Dec 2023 13:35:32 +0300
Subject: [PATCH net-next 11/16] net: pcs: xpcs: Change xpcs_create_mdiodev() suffix to "byaddr"
In-Reply-To: <20231205103559.9605-1-fancer.lancer@gmail.com>
References: <20231205103559.9605-1-fancer.lancer@gmail.com>
Message-ID: <20231205103559.9605-12-fancer.lancer@gmail.com>

The fwnode-based way of creating XPCS descriptor is about to be added. In
order to have a function name distinguishable from the already implemented
xpcs_create_mdiodev() method convert the later name to be
xpcs_create_byaddr() which BTW better describes the method semantic in
anyway.

Signed-off-by: Serge Semin <fancer.lancer at gmail.com>
---
 drivers/net/dsa/sja1105/sja1105_mdio.c            | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 2 +-
 drivers/net/pcs/pcs-xpcs.c                        | 6 +++---
 include/linux/pcs/pcs-xpcs.h                      | 4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/dsa/sja1105/sja1105_mdio.c b/drivers/net/dsa/sja1105/sja1105_mdio.c
index 833e55e4b961..9101079e365d 100644
--- a/drivers/net/dsa/sja1105/sja1105_mdio.c
+++ b/drivers/net/dsa/sja1105/sja1105_mdio.c
@@ -409,7 +409,7 @@ static int sja1105_mdiobus_pcs_register(struct sja1105_private *priv)
 		    priv->phy_mode[port] != PHY_INTERFACE_MODE_2500BASEX)
 			continue;
 
-		xpcs = xpcs_create_mdiodev(bus, port, priv->phy_mode[port]);
+		xpcs = xpcs_create_byaddr(bus, port, priv->phy_mode[port]);
 		if (IS_ERR(xpcs)) {
 			rc = PTR_ERR(xpcs);
 			goto out_pcs_free;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index fa9e7e7040b9..aa75e4f1e212 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -507,7 +507,7 @@ int stmmac_xpcs_setup(struct mii_bus *bus)
 
 	/* Try to probe the XPCS by scanning all addresses. */
 	for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
-		xpcs = xpcs_create_mdiodev(bus, addr, mode);
+		xpcs = xpcs_create_byaddr(bus, addr, mode);
 		if (IS_ERR(xpcs))
 			continue;
 
diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index 183a37929b60..e376e255f1d3 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -1511,8 +1511,8 @@ static struct dw_xpcs *xpcs_create(struct mdio_device *mdiodev,
 	return ERR_PTR(ret);
 }
 
-struct dw_xpcs *xpcs_create_mdiodev(struct mii_bus *bus, int addr,
-				    phy_interface_t interface)
+struct dw_xpcs *xpcs_create_byaddr(struct mii_bus *bus, int addr,
+				   phy_interface_t interface)
 {
 	struct mdio_device *mdiodev;
 	struct dw_xpcs *xpcs;
@@ -1535,7 +1535,7 @@ struct dw_xpcs *xpcs_create_mdiodev(struct mii_bus *bus, int addr,
 
 	return xpcs;
 }
-EXPORT_SYMBOL_GPL(xpcs_create_mdiodev);
+EXPORT_SYMBOL_GPL(xpcs_create_byaddr);
 
 void xpcs_destroy(struct dw_xpcs *xpcs)
 {
diff --git a/include/linux/pcs/pcs-xpcs.h b/include/linux/pcs/pcs-xpcs.h
index 53adbffb4c0a..b11bbb5e820a 100644
--- a/include/linux/pcs/pcs-xpcs.h
+++ b/include/linux/pcs/pcs-xpcs.h
@@ -73,8 +73,8 @@ int xpcs_do_config(struct dw_xpcs *xpcs, phy_interface_t interface,
 void xpcs_get_interfaces(struct dw_xpcs *xpcs, unsigned long *interfaces);
 int xpcs_config_eee(struct dw_xpcs *xpcs, int mult_fact_100ns,
 		    int enable);
-struct dw_xpcs *xpcs_create_mdiodev(struct mii_bus *bus, int addr,
-				    phy_interface_t interface);
+struct dw_xpcs *xpcs_create_byaddr(struct mii_bus *bus, int addr,
+				   phy_interface_t interface);
 void xpcs_destroy(struct dw_xpcs *xpcs);
 
 #endif /* __LINUX_PCS_XPCS_H */
-- 
2.42.1



From fancer.lancer at gmail.com  Tue Dec  5 02:35:34 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue,  5 Dec 2023 13:35:34 +0300
Subject: [PATCH net-next 13/16] net: stmmac: intel: Register generic MDIO device
In-Reply-To: <20231205103559.9605-1-fancer.lancer@gmail.com>
References: <20231205103559.9605-1-fancer.lancer@gmail.com>
Message-ID: <20231205103559.9605-14-fancer.lancer@gmail.com>

The DW XPCS driver has been updated to being bindable with the respective
MDIO device registered during the MDIO bus probe procedure. As an example
of using that feature let's convert the Intel mGBE low-level driver to
registering the MDIO-device board info. Thus the registered DW XPCS device
will be a subject of the fine-tunings performed during the MDIO-device
probe procedures.

Signed-off-by: Serge Semin <fancer.lancer at gmail.com>
---
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 31 ++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 60283543ffc8..7642c11abc59 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -4,6 +4,7 @@
 
 #include <linux/clk-provider.h>
 #include <linux/pci.h>
+#include <linux/phy.h>
 #include <linux/dmi.h>
 #include "dwmac-intel.h"
 #include "dwmac4.h"
@@ -585,6 +586,28 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 	/* Intel mgbe SGMII interface uses pcs-xcps */
 	if (plat->phy_interface == PHY_INTERFACE_MODE_SGMII ||
 	    plat->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+		struct mdio_board_info *xpcs_info;
+
+		xpcs_info = devm_kzalloc(&pdev->dev,
+					 sizeof(*xpcs_info) + MII_BUS_ID_SIZE,
+					 GFP_KERNEL);
+		if (!xpcs_info) {
+			ret = -ENOMEM;
+			goto err_alloc_info;
+		}
+
+		xpcs_info->bus_id = (void *)xpcs_info + sizeof(*xpcs_info);
+		snprintf((char *)xpcs_info->bus_id, MII_BUS_ID_SIZE,
+			 "stmmac-%x", plat->bus_id);
+
+		snprintf(xpcs_info->modalias, MDIO_NAME_SIZE, "dwxpcs");
+
+		xpcs_info->mdio_addr = INTEL_MGBE_XPCS_ADDR;
+
+		ret = mdiobus_register_board_info(xpcs_info, 1);
+		if (ret)
+			goto err_alloc_info;
+
 		plat->mdio_bus_data->has_xpcs = true;
 		plat->mdio_bus_data->xpcs_an_inband = true;
 	}
@@ -600,7 +623,7 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 		fwnode_handle_put(fixed_node);
 	}
 
-	/* Ensure mdio bus scan skips intel serdes and pcs-xpcs */
+	/* Ensure mdio bus PHY-scan skips intel serdes and pcs-xpcs */
 	plat->mdio_bus_data->phy_mask = 1 << INTEL_MGBE_ADHOC_ADDR;
 	plat->mdio_bus_data->phy_mask |= 1 << INTEL_MGBE_XPCS_ADDR;
 
@@ -618,6 +641,12 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 	plat->msi_tx_base_vec = 1;
 
 	return 0;
+
+err_alloc_info:
+	clk_disable_unprepare(clk);
+	clk_unregister_fixed_rate(clk);
+
+	return ret;
 }
 
 static int ehl_common_data(struct pci_dev *pdev,
-- 
2.42.1



From fancer.lancer at gmail.com  Tue Dec  5 02:35:35 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue,  5 Dec 2023 13:35:35 +0300
Subject: [PATCH net-next 14/16] net: stmmac: Pass netdev to XPCS setup function
In-Reply-To: <20231205103559.9605-1-fancer.lancer@gmail.com>
References: <20231205103559.9605-1-fancer.lancer@gmail.com>
Message-ID: <20231205103559.9605-15-fancer.lancer@gmail.com>

It's possible to have the XPCS device accessible over a dedicated
management interface which makes the XPCS device available over the MMIO
space. In that case the management interface will be registered as a
separate MDIO bus and the DW xGMAC device will be equipped with the
"pcs-handle" property pointing to the XPCS device instead of
auto-detecting it on the internal MDIO bus. In such configurations the SMA
interface (embedded into the DW xGMAC MDIO interface) might be absent.
Thus passing the MII bus interface handler to the stmmac_xpcs_setup()
method won't let us reach the externally supplied XPCS device especially
if the SMA bus isn't configured. Let's fix it by converting the
stmmac_xpcs_setup(struct mii_bus *bus) prototype to
stmmac_xpcs_setup(struct net_device *ndev).

Note this is a preparation patch before adding the support of the XPCS
devices specified via the "pcs-handle" property.

Signed-off-by: Serge Semin <fancer.lancer at gmail.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h      | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 5 ++---
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index cd7a9768de5f..d8a1c84880c5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -343,7 +343,7 @@ enum stmmac_state {
 int stmmac_mdio_unregister(struct net_device *ndev);
 int stmmac_mdio_register(struct net_device *ndev);
 int stmmac_mdio_reset(struct mii_bus *mii);
-int stmmac_xpcs_setup(struct mii_bus *mii);
+int stmmac_xpcs_setup(struct net_device *ndev);
 void stmmac_set_ethtool_ops(struct net_device *netdev);
 
 int stmmac_init_tstamp_counter(struct stmmac_priv *priv, u32 systime_flags);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3e50fd53a617..c3641db00f96 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7605,7 +7605,7 @@ int stmmac_dvr_probe(struct device *device,
 		priv->plat->speed_mode_2500(ndev, priv->plat->bsp_priv);
 
 	if (priv->plat->mdio_bus_data && priv->plat->mdio_bus_data->has_xpcs) {
-		ret = stmmac_xpcs_setup(priv->mii);
+		ret = stmmac_xpcs_setup(ndev);
 		if (ret)
 			goto error_xpcs_setup;
 	}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index aa75e4f1e212..e6133510e28d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -495,9 +495,8 @@ int stmmac_mdio_reset(struct mii_bus *bus)
 	return 0;
 }
 
-int stmmac_xpcs_setup(struct mii_bus *bus)
+int stmmac_xpcs_setup(struct net_device *ndev)
 {
-	struct net_device *ndev = bus->priv;
 	struct stmmac_priv *priv;
 	struct dw_xpcs *xpcs;
 	int mode, addr;
@@ -507,7 +506,7 @@ int stmmac_xpcs_setup(struct mii_bus *bus)
 
 	/* Try to probe the XPCS by scanning all addresses. */
 	for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
-		xpcs = xpcs_create_byaddr(bus, addr, mode);
+		xpcs = xpcs_create_byaddr(priv->mii, addr, mode);
 		if (IS_ERR(xpcs))
 			continue;
 
-- 
2.42.1



From fancer.lancer at gmail.com  Tue Dec  5 02:35:36 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue,  5 Dec 2023 13:35:36 +0300
Subject: [PATCH net-next 15/16] net: stmmac: Add dedicated XPCS cleanup method
In-Reply-To: <20231205103559.9605-1-fancer.lancer@gmail.com>
References: <20231205103559.9605-1-fancer.lancer@gmail.com>
Message-ID: <20231205103559.9605-16-fancer.lancer@gmail.com>

Currently the XPCS handler destruction is performed in the
stmmac_mdio_unregister() method. It doesn't look well because the handler
isn't originally created in the corresponding protagonist
stmmac_mdio_unregister(), but in the stmmac_xpcs_setup() function. In
order to have a bit more coherent MDIO and XPCS setup/cleanup procedures
let's move the DW XPCS destruction to the dedicated stmmac_xpcs_clean()
method.

Note besides of that this change is a preparation to adding the PCS device
supplied by means of the "pcs-handle" property. It's required since DW
XPCS IP-core can be synthesized embedded into the chip with directly
accessible CSRs. In that case the SMA interface can be absent so no
corresponding MDIO bus will be registered.

Signed-off-by: Serge Semin <fancer.lancer at gmail.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  1 +
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  6 +++++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 14 +++++++++++---
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index d8a1c84880c5..1709de519813 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -344,6 +344,7 @@ int stmmac_mdio_unregister(struct net_device *ndev);
 int stmmac_mdio_register(struct net_device *ndev);
 int stmmac_mdio_reset(struct mii_bus *mii);
 int stmmac_xpcs_setup(struct net_device *ndev);
+void stmmac_xpcs_clean(struct net_device *ndev);
 void stmmac_set_ethtool_ops(struct net_device *netdev);
 
 int stmmac_init_tstamp_counter(struct stmmac_priv *priv, u32 systime_flags);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c3641db00f96..379552240ac9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7639,8 +7639,9 @@ int stmmac_dvr_probe(struct device *device,
 
 error_netdev_register:
 	phylink_destroy(priv->phylink);
-error_xpcs_setup:
 error_phy_setup:
+	stmmac_xpcs_clean(ndev);
+error_xpcs_setup:
 	if (priv->hw->pcs != STMMAC_PCS_TBI &&
 	    priv->hw->pcs != STMMAC_PCS_RTBI)
 		stmmac_mdio_unregister(ndev);
@@ -7682,6 +7683,9 @@ void stmmac_dvr_remove(struct device *dev)
 	if (priv->plat->stmmac_rst)
 		reset_control_assert(priv->plat->stmmac_rst);
 	reset_control_assert(priv->plat->stmmac_ahb_rst);
+
+	stmmac_xpcs_clean(ndev);
+
 	if (priv->hw->pcs != STMMAC_PCS_TBI &&
 	    priv->hw->pcs != STMMAC_PCS_RTBI)
 		stmmac_mdio_unregister(ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index e6133510e28d..101fa50c3c96 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -522,6 +522,17 @@ int stmmac_xpcs_setup(struct net_device *ndev)
 	return 0;
 }
 
+void stmmac_xpcs_clean(struct net_device *ndev)
+{
+	struct stmmac_priv *priv = netdev_priv(ndev);
+
+	if (!priv->hw->xpcs)
+		return;
+
+	xpcs_destroy(priv->hw->xpcs);
+	priv->hw->xpcs = NULL;
+}
+
 /**
  * stmmac_mdio_register
  * @ndev: net device structure
@@ -674,9 +685,6 @@ int stmmac_mdio_unregister(struct net_device *ndev)
 	if (!priv->mii)
 		return 0;
 
-	if (priv->hw->xpcs)
-		xpcs_destroy(priv->hw->xpcs);
-
 	mdiobus_unregister(priv->mii);
 	priv->mii->priv = NULL;
 	mdiobus_free(priv->mii);
-- 
2.42.1



From fancer.lancer at gmail.com  Tue Dec  5 02:35:37 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue,  5 Dec 2023 13:35:37 +0300
Subject: [PATCH net-next 16/16] net: stmmac: Add externally detected DW XPCS support
In-Reply-To: <20231205103559.9605-1-fancer.lancer@gmail.com>
References: <20231205103559.9605-1-fancer.lancer@gmail.com>
Message-ID: <20231205103559.9605-17-fancer.lancer@gmail.com>

It's possible to have the DW XPCS device accessible over an external bus
(external MDIO or DW XPCS management interface). Thus it will be futile to
try to detect the device on the local SMA interface. Besides such platform
setup isn't supported by the STMMAC driver anyway since the
stmmac_mdio_bus_data instance might not be created and even if it is there
is no code path which would set the stmmac_mdio_bus_data.has_xpcs flag
thus activating the XPCS device setup.

So in order to solve the denoted problem a pretty much standard approach
is implemented: DT "pcs-handle" property is used to get the phandle
referencing the DT-node describing the DW XPCS device; device node will be
parsed by the xpcs_create_bynode() method implemented in the DW XPCS
driver in a way as it's done for PHY-node; the node is used to find the
MDIO-device instance, which in its turn will be used to create the XPCS
descriptor.

Note as a nice side effect of the provided change the conditional
stmmac_xpcs_setup() method execution can be converted to the conditional
statements implemented in the function itself. Thus the stmmac_open() will
turn to look a bit simpler meanwhile stmmac_xpcs_setup() will provide the
optional XPCS device semantic.

Signed-off-by: Serge Semin <fancer.lancer at gmail.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  8 ++---
 .../net/ethernet/stmicro/stmmac/stmmac_mdio.c | 34 ++++++++++++-------
 2 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 379552240ac9..a33ba00d091d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7604,11 +7604,9 @@ int stmmac_dvr_probe(struct device *device,
 	if (priv->plat->speed_mode_2500)
 		priv->plat->speed_mode_2500(ndev, priv->plat->bsp_priv);
 
-	if (priv->plat->mdio_bus_data && priv->plat->mdio_bus_data->has_xpcs) {
-		ret = stmmac_xpcs_setup(ndev);
-		if (ret)
-			goto error_xpcs_setup;
-	}
+	ret = stmmac_xpcs_setup(ndev);
+	if (ret)
+		goto error_xpcs_setup;
 
 	ret = stmmac_phy_setup(priv);
 	if (ret) {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 101fa50c3c96..b906be363b61 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -499,25 +499,33 @@ int stmmac_xpcs_setup(struct net_device *ndev)
 {
 	struct stmmac_priv *priv;
 	struct dw_xpcs *xpcs;
-	int mode, addr;
+	int ret, mode, addr;
 
 	priv = netdev_priv(ndev);
 	mode = priv->plat->phy_interface;
 
-	/* Try to probe the XPCS by scanning all addresses. */
-	for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
-		xpcs = xpcs_create_byaddr(priv->mii, addr, mode);
-		if (IS_ERR(xpcs))
-			continue;
-
-		priv->hw->xpcs = xpcs;
-		break;
+	/* If PCS-node is specified use it to create the XPCS descriptor */
+	if (fwnode_property_present(priv->plat->port_node, "pcs-handle")) {
+		xpcs = xpcs_create_bynode(priv->plat->port_node, mode);
+		ret = PTR_ERR_OR_ZERO(xpcs);
+	} else if (priv->plat->mdio_bus_data && priv->plat->mdio_bus_data->has_xpcs) {
+		/* Try to probe the XPCS by scanning all addresses */
+		for (ret = -ENODEV, addr = 0; addr < PHY_MAX_ADDR; addr++) {
+			xpcs = xpcs_create_byaddr(priv->mii, addr, mode);
+			if (IS_ERR(xpcs))
+				continue;
+
+			ret = 0;
+			break;
+		}
+	} else {
+		return 0;
 	}
 
-	if (!priv->hw->xpcs) {
-		dev_warn(priv->device, "No xPCS found\n");
-		return -ENODEV;
-	}
+	if (ret)
+		return dev_err_probe(priv->device, ret, "No xPCS found\n");
+
+	priv->hw->xpcs = xpcs;
 
 	return 0;
 }
-- 
2.42.1



From ryan.roberts at arm.com  Tue Dec  5 02:48:28 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 5 Dec 2023 10:48:28 +0000
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <CAGsJ_4zYhJWGx1DnHTiDnP3h1m8_rr6ZT6fXt8pO=jzs9QZS-A@mail.gmail.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <CAGsJ_4zG6W_Z-u+3QcRDn4ByoeqUXjMusNS0RotfRMSqo8RCHg@mail.gmail.com>
 <CAGsJ_4zYhJWGx1DnHTiDnP3h1m8_rr6ZT6fXt8pO=jzs9QZS-A@mail.gmail.com>
Message-ID: <5216caaf-1fcf-4715-99c3-521e2a1cc756@arm.com>

On 05/12/2023 01:24, Barry Song wrote:
> On Tue, Dec 5, 2023 at 9:15?AM Barry Song <21cnbao at gmail.com> wrote:
>>
>> On Mon, Dec 4, 2023 at 6:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>>>
>>> Introduce the logic to allow THP to be configured (through the new sysfs
>>> interface we just added) to allocate large folios to back anonymous
>>> memory, which are larger than the base page size but smaller than
>>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>>>
>>> mTHP continues to be PTE-mapped, but in many cases can still provide
>>> similar benefits to traditional PMD-sized THP: Page faults are
>>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
>>> the configured order), but latency spikes are much less prominent
>>> because the size of each page isn't as huge as the PMD-sized variant and
>>> there is less memory to clear in each page fault. The number of per-page
>>> operations (e.g. ref counting, rmap management, lru list management) are
>>> also significantly reduced since those ops now become per-folio.
>>>
>>> Some architectures also employ TLB compression mechanisms to squeeze
>>> more entries in when a set of PTEs are virtually and physically
>>> contiguous and approporiately aligned. In this case, TLB misses will
>>> occur less often.
>>>
>>> The new behaviour is disabled by default, but can be enabled at runtime
>>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
>>> (see documentation in previous commit). The long term aim is to change
>>> the default to include suitable lower orders, but there are some risks
>>> around internal fragmentation that need to be better understood first.
>>>
>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>> ---
>>>  include/linux/huge_mm.h |   6 ++-
>>>  mm/memory.c             | 106 ++++++++++++++++++++++++++++++++++++----
>>>  2 files changed, 101 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>> index bd0eadd3befb..91a53b9835a4 100644
>>> --- a/include/linux/huge_mm.h
>>> +++ b/include/linux/huge_mm.h
>>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>>>  #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>>>
>>>  /*
>>> - * Mask of all large folio orders supported for anonymous THP.
>>> + * Mask of all large folio orders supported for anonymous THP; all orders up to
>>> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
>>> + * (which is a limitation of the THP implementation).
>>>   */
>>> -#define THP_ORDERS_ALL_ANON    BIT(PMD_ORDER)
>>> +#define THP_ORDERS_ALL_ANON    ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>>>
>>>  /*
>>>   * Mask of all large folio orders supported for file THP.
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index 3ceeb0f45bf5..bf7e93813018 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>         return ret;
>>>  }
>>>
>>> +static bool pte_range_none(pte_t *pte, int nr_pages)
>>> +{
>>> +       int i;
>>> +
>>> +       for (i = 0; i < nr_pages; i++) {
>>> +               if (!pte_none(ptep_get_lockless(pte + i)))
>>> +                       return false;
>>> +       }
>>> +
>>> +       return true;
>>> +}
>>> +
>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>>> +{
>>> +       gfp_t gfp;
>>> +       pte_t *pte;
>>> +       unsigned long addr;
>>> +       struct folio *folio;
>>> +       struct vm_area_struct *vma = vmf->vma;
>>> +       unsigned long orders;
>>> +       int order;
>>> +
>>> +       /*
>>> +        * If uffd is active for the vma we need per-page fault fidelity to
>>> +        * maintain the uffd semantics.
>>> +        */
>>> +       if (userfaultfd_armed(vma))
>>> +               goto fallback;
>>> +
>>> +       /*
>>> +        * Get a list of all the (large) orders below PMD_ORDER that are enabled
>>> +        * for this vma. Then filter out the orders that can't be allocated over
>>> +        * the faulting address and still be fully contained in the vma.
>>> +        */
>>> +       orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
>>> +                                         BIT(PMD_ORDER) - 1);
>>> +       orders = thp_vma_suitable_orders(vma, vmf->address, orders);
>>> +
>>> +       if (!orders)
>>> +               goto fallback;
>>> +
>>> +       pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>> +       if (!pte)
>>> +               return ERR_PTR(-EAGAIN);
>>> +
>>> +       order = first_order(orders);
>>> +       while (orders) {
>>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>> +               vmf->pte = pte + pte_index(addr);
>>> +               if (pte_range_none(vmf->pte, 1 << order))
>>> +                       break;
>>> +               order = next_order(&orders, order);
>>> +       }
>>> +
>>> +       vmf->pte = NULL;
>>> +       pte_unmap(pte);
>>> +
>>> +       gfp = vma_thp_gfp_mask(vma);
>>> +
>>> +       while (orders) {
>>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>> +               folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>> +               if (folio) {
>>> +                       clear_huge_page(&folio->page, addr, 1 << order);
>>
>> Minor.
>>
>> Do we have to constantly clear a huge page? Is it possible to let
>> post_alloc_hook()
>> finish this job by using __GFP_ZERO/__GFP_ZEROTAGS as
>> vma_alloc_zeroed_movable_folio() is doing?

I'm currently following the same allocation pattern as is done for PMD-sized
THP. In earlier versions of this patch I was trying to be smarter and use the
__GFP_ZERO/__GFP_ZEROTAGS as you suggest, but I was advised to keep it simple
and follow the existing pattern.

I have a vague recollection __GFP_ZERO is not preferred for large folios because
of some issue with virtually indexed caches? (Matthew: did I see you mention
that in some other context?)

That said, I wasn't aware that Android ships with
CONFIG_INIT_ON_ALLOC_DEFAULT_ON (I thought it was only used as a debug option),
so I can see the potential for some overhead reduction here.

Options:

 1) leave it as is and accept the duplicated clearing
 2) Pass __GFP_ZERO and remove clear_huge_page()
 3) define __GFP_SKIP_ZERO even when kasan is not enabled and pass it down so
    clear_huge_page() is the only clear
 4) make clear_huge_page() conditional on !want_init_on_alloc()

I prefer option 4. What do you think?

As an aside, I've also noticed that clear_huge_page() should take vmf->address
so that it clears the faulting page last to keep the cache hot. If we decide on
an option that keeps clear_huge_page(), I'll also make that change.

Thanks,
Ryan

>>
>> struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
>>                                                 unsigned long vaddr)
>> {
>>         gfp_t flags = GFP_HIGHUSER_MOVABLE | __GFP_ZERO;
>>
>>         /*
>>          * If the page is mapped with PROT_MTE, initialise the tags at the
>>          * point of allocation and page zeroing as this is usually faster than
>>          * separate DC ZVA and STGM.
>>          */
>>         if (vma->vm_flags & VM_MTE)
>>                 flags |= __GFP_ZEROTAGS;
>>
>>         return vma_alloc_folio(flags, 0, vma, vaddr, false);
>> }
> 
> I am asking this because Android and some other kernels might always set
> CONFIG_INIT_ON_ALLOC_DEFAULT_ON, that means one more explicit
> clear_page is doing a duplicated job.
> 
> when the below is true, post_alloc_hook has cleared huge_page before
> vma_alloc_folio() returns the folio,
> 
> static inline bool want_init_on_alloc(gfp_t flags)
> {
>         if (static_branch_maybe(CONFIG_INIT_ON_ALLOC_DEFAULT_ON,
>                                 &init_on_alloc))
>                 return true;
>         return flags & __GFP_ZERO;
> }
> 
> 
>>
>>> +                       return folio;
>>> +               }
>>> +               order = next_order(&orders, order);
>>> +       }
>>> +
>>> +fallback:
>>> +       return vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>> +}
>>> +#else
>>> +#define alloc_anon_folio(vmf) \
>>> +               vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
>>> +#endif
>>> +
>>>  /*
>>>   * We enter with non-exclusive mmap_lock (to exclude vma changes,
>>>   * but allow concurrent faults), and pte mapped but not yet locked.
>>> @@ -4132,6 +4210,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>   */
>>>  static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>  {
>>> +       int i;
>>> +       int nr_pages = 1;
>>> +       unsigned long addr = vmf->address;
>>>         bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
>>>         struct vm_area_struct *vma = vmf->vma;
>>>         struct folio *folio;
>>> @@ -4176,10 +4257,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>         /* Allocate our own private page. */
>>>         if (unlikely(anon_vma_prepare(vma)))
>>>                 goto oom;
>>> -       folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>> +       folio = alloc_anon_folio(vmf);
>>> +       if (IS_ERR(folio))
>>> +               return 0;
>>>         if (!folio)
>>>                 goto oom;
>>>
>>> +       nr_pages = folio_nr_pages(folio);
>>> +       addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
>>> +
>>>         if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
>>>                 goto oom_free_page;
>>>         folio_throttle_swaprate(folio, GFP_KERNEL);
>>> @@ -4196,12 +4282,13 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>         if (vma->vm_flags & VM_WRITE)
>>>                 entry = pte_mkwrite(pte_mkdirty(entry), vma);
>>>
>>> -       vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
>>> -                       &vmf->ptl);
>>> +       vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
>>>         if (!vmf->pte)
>>>                 goto release;
>>> -       if (vmf_pte_changed(vmf)) {
>>> -               update_mmu_tlb(vma, vmf->address, vmf->pte);
>>> +       if ((nr_pages == 1 && vmf_pte_changed(vmf)) ||
>>> +           (nr_pages  > 1 && !pte_range_none(vmf->pte, nr_pages))) {
>>> +               for (i = 0; i < nr_pages; i++)
>>> +                       update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);
>>>                 goto release;
>>>         }
>>>
>>> @@ -4216,16 +4303,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>                 return handle_userfault(vmf, VM_UFFD_MISSING);
>>>         }
>>>
>>> -       inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
>>> -       folio_add_new_anon_rmap(folio, vma, vmf->address);
>>> +       folio_ref_add(folio, nr_pages - 1);
>>> +       add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
>>> +       folio_add_new_anon_rmap(folio, vma, addr);
>>>         folio_add_lru_vma(folio, vma);
>>>  setpte:
>>>         if (uffd_wp)
>>>                 entry = pte_mkuffd_wp(entry);
>>> -       set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
>>> +       set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
>>>
>>>         /* No need to invalidate - it was non-present before */
>>> -       update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
>>> +       update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
>>>  unlock:
>>>         if (vmf->pte)
>>>                 pte_unmap_unlock(vmf->pte, vmf->ptl);
>>> --
>>> 2.25.1
>>>



From ryan.roberts at arm.com  Tue Dec  5 02:50:15 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 5 Dec 2023 10:50:15 +0000
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <c97d60cc-6c31-4da1-b519-86516008bb4c@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
 <CAGsJ_4zU6pHOwEzCQxo9UWUFmHZp0pvfgF4pKbkFfDPCRyFwyw@mail.gmail.com>
 <8adbde1c-970b-4a26-81b0-91b913c4850b@arm.com>
 <c97d60cc-6c31-4da1-b519-86516008bb4c@redhat.com>
Message-ID: <075826b4-2df8-4460-a8f2-c0581d098cff@arm.com>

On 05/12/2023 09:57, David Hildenbrand wrote:
> On 05.12.23 10:50, Ryan Roberts wrote:
>> On 05/12/2023 04:21, Barry Song wrote:
>>> On Mon, Dec 4, 2023 at 11:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>>>>
>>>> In preparation for adding support for anonymous multi-size THP,
>>>> introduce new sysfs structure that will be used to control the new
>>>> behaviours. A new directory is added under transparent_hugepage for each
>>>> supported THP size, and contains an `enabled` file, which can be set to
>>>> "inherit" (to inherit the global setting), "always", "madvise" or
>>>> "never". For now, the kernel still only supports PMD-sized anonymous
>>>> THP, so only 1 directory is populated.
>>>>
>>>> The first half of the change converts transhuge_vma_suitable() and
>>>> hugepage_vma_check() so that they take a bitfield of orders for which
>>>> the user wants to determine support, and the functions filter out all
>>>> the orders that can't be supported, given the current sysfs
>>>> configuration and the VMA dimensions. If there is only 1 order set in
>>>> the input then the output can continue to be treated like a boolean;
>>>> this is the case for most call sites. The resulting functions are
>>>> renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
>>>> respectively.
>>>>
>>>> The second half of the change implements the new sysfs interface. It has
>>>> been done so that each supported THP size has a `struct thpsize`, which
>>>> describes the relevant metadata and is itself a kobject. This is pretty
>>>> minimal for now, but should make it easy to add new per-thpsize files to
>>>> the interface if needed in future (e.g. per-size defrag). Rather than
>>>> keep the `enabled` state directly in the struct thpsize, I've elected to
>>>> directly encode it into huge_anon_orders_[always|madvise|inherit]
>>>> bitfields since this reduces the amount of work required in
>>>> thp_vma_allowable_orders() which is called for every page fault.
>>>>
>>>> See Documentation/admin-guide/mm/transhuge.rst, as modified by this
>>>> commit, for details of how the new sysfs interface works.
>>>>
>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>
>>> Reviewed-by: Barry Song <v-songbaohua at oppo.com>
>>
>> Thanks!
>>
>>>
>>>> -khugepaged will be automatically started when
>>>> -transparent_hugepage/enabled is set to "always" or "madvise, and it'll
>>>> -be automatically shutdown if it's set to "never".
>>>> +khugepaged will be automatically started when one or more hugepage
>>>> +sizes are enabled (either by directly setting "always" or "madvise",
>>>> +or by setting "inherit" while the top-level enabled is set to "always"
>>>> +or "madvise"), and it'll be automatically shutdown when the last
>>>> +hugepage size is disabled (either by directly setting "never", or by
>>>> +setting "inherit" while the top-level enabled is set to "never").
>>>>
>>>> ? Khugepaged controls
>>>> ? -------------------
>>>>
>>>> +.. note::
>>>> +?? khugepaged currently only searches for opportunities to collapse to
>>>> +?? PMD-sized THP and no attempt is made to collapse to other THP
>>>> +?? sizes.
>>>
>>> For small-size THP, collapse is probably a bad idea. we like a one-shot
>>> try in Android especially we are using a 64KB and less large folio size. if
>>> PF succeeds in getting large folios, we map large folios, otherwise we
>>> give up as those memories can be quite unstably swapped-out, swapped-in
>>> and madvised to be DONTNEED.
>>>
>>> too many compactions will increase power consumption and decrease UI
>>> response.
>>
>> Understood; that's very useful information for the Android context. Multiple
>> people have made comments about eventually needing khugepaged (or something
>> similar) support in the server context though to async collapse to contpte size.
>> Actually one suggestion was a user space daemon that scans and collapses with
>> MADV_COLLAPSE. I suspect the key will be to ensure whatever solution we go for
>> is flexible and can be enabled/disabled/configured for the different
>> environments.
> 
> There certainly is interest for 2 MiB THP on arm64 64k where the THP size would
> normally be 512 MiB. In that scenario, khugepaged makes perfect sense.

Indeed



From dario.binacchi at amarulasolutions.com  Tue Dec  5 02:52:47 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Tue,  5 Dec 2023 11:52:47 +0100
Subject: [PATCH v4 00/10] Add displays support for bsh-smm-s2/pro boards
Message-ID: <20231205105341.4100896-1-dario.binacchi@amarulasolutions.com>

The series adds drivers for the displays used by bsh-smm-s2/pro boards.
This required applying some patches to the samsung-dsim driver and the
drm_bridge.c module.

Changes in v4:
- Set the reset gpio to low in a single operation
- Remove duplicated code for prepare/unprepare callbacks
- Add 'Reviewed-by; tag of Neil Armstrong

Changes in v3:
- Add 'Reviewed-by' tag of Krzysztof Kozlowski.
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Drop power-supply
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties
- Adjust the timings of the panel reset
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Dario Binacchi (4):
  drm/bridge: Fix bridge disable logic
  drm/bridge: Fix a use case in the bridge disable logic
  drm: bridge: samsung-dsim: enter display mode in the enable() callback
  drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Michael Trimarchi (6):
  dt-bindings: display: panel: Add synaptics r63353 panel controller
  drm/panel: Add Synaptics R63353 panel driver
  dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  drm/panel: Add Ilitek ILI9805 panel driver
  drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup

 .../display/panel/ilitek,ili9805.yaml         |  62 +++
 .../display/panel/synaptics,r63353.yaml       |  61 +++
 MAINTAINERS                                   |  12 +
 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++
 drivers/gpu/drm/bridge/samsung-dsim.c         |  14 +-
 drivers/gpu/drm/drm_bridge.c                  |   9 +-
 drivers/gpu/drm/panel/Kconfig                 |  18 +
 drivers/gpu/drm/panel/Makefile                |   2 +
 drivers/gpu/drm/panel/panel-ilitek-ili9805.c  | 406 ++++++++++++++++++
 .../gpu/drm/panel/panel-synaptics-r63353.c    | 363 ++++++++++++++++
 11 files changed, 1062 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
 create mode 100644 Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9805.c
 create mode 100644 drivers/gpu/drm/panel/panel-synaptics-r63353.c

-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Tue Dec  5 02:52:57 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Tue,  5 Dec 2023 11:52:57 +0100
Subject: [PATCH v4 10/10] arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup
In-Reply-To: <20231205105341.4100896-1-dario.binacchi@amarulasolutions.com>
References: <20231205105341.4100896-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231205105341.4100896-11-dario.binacchi@amarulasolutions.com>

From: Michael Trimarchi <michael at amarulasolutions.com>

Add the display and nodes required for its operation.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>

---

(no changes since v3)

Changes in v3:
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++++++++++++++
 2 files changed, 122 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
index 22a754d438f1..bbb07c650da9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
@@ -7,6 +7,7 @@
 /dts-v1/;
 
 #include "imx8mn.dtsi"
+#include "imx8mn-bsh-smm-s2-display.dtsi"
 
 / {
 	chosen {
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
new file mode 100644
index 000000000000..f0a924cbe548
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 BSH
+ */
+
+/ {
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm1 0 700000 0>;	/* 700000 ns = 1337Hz */
+		brightness-levels = <0 100>;
+		num-interpolated-steps = <100>;
+		default-brightness-level = <50>;
+		status = "okay";
+	};
+
+	reg_3v3_dvdd: regulator-3v3-O3 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_dvdd>;
+		regulator-name = "3v3-dvdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
+	};
+
+	reg_v3v3_avdd: regulator-3v3-O2 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_avdd>;
+		regulator-name = "3v3-avdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 5 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pwm1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_bl>;
+};
+
+&lcdif {
+	status = "okay";
+	assigned-clocks = <&clk IMX8MN_VIDEO_PLL1>;
+	assigned-clock-rates = <594000000>;
+};
+
+&pgc_dispmix {
+	assigned-clocks = <&clk IMX8MN_CLK_DISP_AXI>, <&clk IMX8MN_CLK_DISP_APB>;
+	assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_1000M>, <&clk IMX8MN_SYS_PLL1_800M>;
+	assigned-clock-rates = <500000000>, <200000000>;
+};
+
+&mipi_dsi {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+	samsung,esc-clock-frequency = <20000000>;
+	samsung,pll-clock-frequency = <12000000>;
+
+	panel at 0 {
+		compatible = "sharp,ls068b3sx02", "syna,r63353";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel>;
+		reg = <0>;
+
+		backlight = <&backlight>;
+		dvdd-supply = <&reg_3v3_dvdd>;
+		avdd-supply = <&reg_v3v3_avdd>;
+		reset-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+
+		port {
+			panel_in: endpoint {
+				remote-endpoint = <&mipi_dsi_out>;
+			};
+		};
+
+	};
+
+	ports {
+		port at 1 {
+			reg = <1>;
+			mipi_dsi_out: endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+	};
+};
+
+&gpu {
+	status = "okay";
+};
+
+&iomuxc {
+
+	/* This is for both PWM and voltage regulators for display */
+	pinctrl_bl: pwm1grp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO01_PWM1_OUT	0x16
+		>;
+	};
+
+	pinctrl_panel: panelgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_SAI3_RXC_GPIO4_IO29	0x16	/* panel reset */
+		>;
+	};
+
+	pinctrl_dvdd: dvddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x16	/* VDD 3V3_VO3 */
+		>;
+	};
+
+	pinctrl_avdd: avddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO05_GPIO1_IO5	0x16	/* VDD 3V3_VO2 */
+		>;
+	};
+};
-- 
2.43.0



From mark.rutland at arm.com  Tue Dec  5 03:03:16 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 5 Dec 2023 11:03:16 +0000
Subject: [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy
In-Reply-To: <86h6kxbz8u.wl-maz@kernel.org>
References: <20231204143606.1806432-1-maz@kernel.org>
 <ZW3l6Bq7ortEGB8I@FVFF77S0Q05N>
 <86h6kxbz8u.wl-maz@kernel.org>
Message-ID: <ZW8DXGQCSWO1wB2m@FVFF77S0Q05N>

On Mon, Dec 04, 2023 at 06:26:25PM +0000, Marc Zyngier wrote:
> On Mon, 04 Dec 2023 14:44:56 +0000,
> Mark Rutland <mark.rutland at arm.com> wrote:
> > 
> > On Mon, Dec 04, 2023 at 02:36:03PM +0000, Marc Zyngier wrote:
> > > ARMv8.2 introduced support for VPIPT i-caches, the V standing for
> > > VMID-tagged. Although this looked like a reasonable idea, no
> > > implementation has ever made it into the wild.
> > > 
> > > Linux has supported this for over 6 years (amusingly, just as the
> > > architecture was dropping support for AIVIVT i-caches), but we had no
> > > way to even test it, and it is likely that this code was just
> > > bit-rotting.
> > > 
> > > However, in a recent breakthrough (XML drop 2023-09, tagged as
> > > d55f5af8e09052abe92a02adf820deea2eaed717), the architecture has
> > > finally been purged of this option, making VIPT and PIPT the only two
> > > valid options.
> > > 
> > > This really means this code is just dead code. Nobody will ever come
> > > up with such an implementation, and we can just get rid of it.
> > > 
> > > Most of the impact is on KVM, where we drop a few large comment blocks
> > > (and a bit of code), while the core arch code loses the detection code
> > > itself.
> > > 
> > > * From v2:
> > >   - Fix reserved naming for RESERVED_AIVIVT
> > >   - Collected RBs from Anshuman an Zenghui
> > > 
> > > Marc Zyngier (3):
> > >   KVM: arm64: Remove VPIPT I-cache handling
> > >   arm64: Kill detection of VPIPT i-cache policy
> > >   arm64: Rename reserved values for CTR_EL0.L1Ip
> > 
> > For the series:
> > 
> > Acked-by: Mark Rutland <mark.rutland at arm.com>
> 
> Thanks.
> 
> > Looking forward, we can/should probably replace __icache_flags with a single
> > ICACHE_NOALIASING or ICACHE_PIPT cpucap, which'd get rid of a bunch of
> > duplicated logic and make that more sound in the case of races around cpu
> > onlining.
> 
> As long as we refuse VIPT CPUs coming up late (i.e. after we have
> patched the kernel to set ICACHE_PIPT), it should be doable. I guess
> we already have this restriction as userspace is able to probe the
> I-cache policy anyway.
> 
> How about the patch below (tested in a guest with a bunch of hacks to
> expose different L1Ip values)?

That's roughly what I was thinking; the diff looks good, minor comments below.

> 
> Thanks,
> 
> 	M.
> 
> From 8f88afb0b317213dcbf18ea460a508bfccc18568 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <maz at kernel.org>
> Date: Mon, 4 Dec 2023 18:09:40 +0000
> Subject: [PATCH] arm64: Make icache detection a cpu capability
> 
> Now that we only have two icache policies, we are in a good position
> to make the whole detection business more robust.
> 
> Let's replace __icache_flags by a single capability (ICACHE_PIPT),
> and use this if all CPUs are indeed PIPT. It means we can rely on
> existing logic to mandate that a VIPT CPU coming up late will be
> denied booting, which is the safe thing to do.
> 
> This also leads to some nice cleanups in pKVM, and KVM as a whole
> can use ARM64_ICACHE_PIPT as a final cap.
> 
> Suggested-by: Mark Rutland <mark.rutland at arm.com>
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm64/include/asm/cache.h   |  9 ++-------
>  arch/arm64/include/asm/kvm_hyp.h |  1 -
>  arch/arm64/include/asm/kvm_mmu.h |  2 +-
>  arch/arm64/kernel/cpufeature.c   |  7 +++++++
>  arch/arm64/kernel/cpuinfo.c      | 34 --------------------------------
>  arch/arm64/kvm/arm.c             |  1 -
>  arch/arm64/kvm/hyp/nvhe/pkvm.c   |  3 ---
>  arch/arm64/tools/cpucaps         |  1 +
>  arch/arm64/tools/sysreg          |  2 +-
>  9 files changed, 12 insertions(+), 48 deletions(-)

Nice diffstat!

[...]

>  /*
>   * Whilst the D-side always behaves as PIPT on AArch64, aliasing is
>   * permitted in the I-cache.
>   */
>  static inline int icache_is_aliasing(void)
>  {
> -	return test_bit(ICACHEF_ALIASING, &__icache_flags);
> +	return !cpus_have_cap(ARM64_ICACHE_PIPT);
>  }

It might be nicer to use alternative_has_cap_{likely,unlikely}(...) for
consistency with other cap checks, though that won't matter for hyp code and I
don't think the likely/unlikely part particularly matters either.

[...]

> -static void cpuinfo_detect_icache_policy(struct cpuinfo_arm64 *info)
> -{
> -	unsigned int cpu = smp_processor_id();
> -	u32 l1ip = CTR_L1IP(info->reg_ctr);
> -
> -	switch (l1ip) {
> -	case CTR_EL0_L1Ip_PIPT:
> -		break;
> -	case CTR_EL0_L1Ip_VIPT:
> -	default:
> -		/* Assume aliasing */
> -		set_bit(ICACHEF_ALIASING, &__icache_flags);
> -		break;
> -	}
> -
> -	pr_info("Detected %s I-cache on CPU%d\n", icache_policy_str(l1ip), cpu);
> -}

Not printing this for each CPU is a nice bonus!

[...]

> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index c5af75b23187..db8c96841138 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -2003,7 +2003,7 @@ Field	28	IDC
>  Field	27:24	CWG
>  Field	23:20	ERG
>  Field	19:16	DminLine
> -Enum	15:14	L1Ip
> +UnsignedEnum	15:14	L1Ip
>  	# This was named as VPIPT in the ARM but now documented as reserved
>  	0b00	RESERVED_VPIPT
>  	# This is named as AIVIVT in the ARM but documented as reserved

I was initially surprised by the use of UnsignedEnum, but given PIPT is 0b11, I
can see that works. Otherwise, we can keep this as an enum and use a helper
that checks for an exact match.

Mark.


From ionela.voinescu at arm.com  Tue Dec  5 03:05:09 2023
From: ionela.voinescu at arm.com (Ionela Voinescu)
Date: Tue, 5 Dec 2023 11:05:09 +0000
Subject: [PATCH v2 2/2] cpufreq: Wire-up arch-flavored freq info into
 cpufreq_verify_current_freq
In-Reply-To: <3e6077bb-907c-057f-0896-d0a5814a4229@nvidia.com>
References: <20231127160838.1403404-1-beata.michalska@arm.com>
 <20231127160838.1403404-3-beata.michalska@arm.com>
 <ZWXy0h/fFfQh+Rhy@arm.com>
 <3e6077bb-907c-057f-0896-d0a5814a4229@nvidia.com>
Message-ID: <ZW8D5TfSwuJfdYeD@arm.com>

Hi Sumit,

On Friday 01 Dec 2023 at 18:32:10 (+0530), Sumit Gupta wrote:
> Hi Ionela,
> 
> > > --- a/drivers/cpufreq/cpufreq.c
> > > +++ b/drivers/cpufreq/cpufreq.c
> > > @@ -1756,7 +1756,8 @@ static unsigned int cpufreq_verify_current_freq(struct cpufreq_policy *policy, b
> > >   {
> > >        unsigned int new_freq;
> > > 
> > > -     new_freq = cpufreq_driver->get(policy->cpu);
> > > +     new_freq = arch_freq_get_on_cpu(policy->cpu);
> > > +     new_freq = new_freq ?: cpufreq_driver->get(policy->cpu);
> > 
> > Given that arch_freq_get_on_cpu() is an average frequency, it does not
> > seem right to me to trigger the sync & update process of
> > cpufreq_verify_current_freq() based on it.
> > 
> > cpufreq_verify_current_freq() will at least modify the internal state of
> > the policy and send PRE and POST notifications, if not do a full frequency
> > update, based on this average frequency, which is likely different from
> > the current frequency, even beyond the 1MHz threshold.
> > 
> > While I believe it's okay to return this average frequency in
> > cpuinfo_cur_freq, I don't think it should be used as an indication of
> > an accurate current frequency, which is what
> > cpufreq_verify_current_freq() expects.
> > 
> > Sumit, can you give more details on the issue at [1] and why this change
> > fixes it?
> > 
> > [1] https://lore.kernel.org/lkml/6a5710f6-bfbb-5dfd-11cd-0cd02220cee7 at nvidia.com/
> > 
> > Thank you,
> > Ionela.
> > 
> cpufreq_verify_current_freq() also updates 'policy->cur' in POST
> notification if the frequency from hardware has more delta (out of sync).
> 
> As the value from 'cpufreq_driver->get()' is not reliable due to [1],
> calling the 'get' hook can update the 'policy->cur' with a wrong value when
> governor starts in cpufreq_start_governor().
> And if the frequency is never changed after the governor starts during
> boot e.g. when performance governor is set as default, then
> 'scaling_cur_freq' always returns wrong value.
> 
> Instead, the arch_freq_get_on_cpu() API updates 'policy->cur' with a more
> stable freq value.
> 
> [1] https://lore.kernel.org/lkml/20230418113459.12860-7-sumitg at nvidia.com/

Got it, many thanks! 

As the code is right now in v2, arch_freq_get_on_cpu() is called on
show_scaling_cur_freq(), so the problem you describe would not show up.
policy->cur would still be incorrect, but 'scaling_cur_freq' would
return the value from arch_freq_get_on_cpu().

Would it be enough if arch_freq_get_on_cpu() gets also called from
show_cpuinfo_cur_freq() instead of cpufreq_verify_current_freq()?

Thanks,
Ionela.

> 
> Best regards,
> Sumit Gupta
> 
> > >        if (!new_freq)
> > >                return 0;
> > > 
> > > --
> > > 2.25.1
> > > 


From ryan.roberts at arm.com  Tue Dec  5 03:05:35 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 5 Dec 2023 11:05:35 +0000
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <CAGsJ_4yfq8Y4vaxiP95Mrn-Oa0=3aY8kAzS6Ojd+eL-ViRr+DA@mail.gmail.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <CAGsJ_4yfq8Y4vaxiP95Mrn-Oa0=3aY8kAzS6Ojd+eL-ViRr+DA@mail.gmail.com>
Message-ID: <c82f15f2-1e66-442c-b95d-ce2ae50fb37e@arm.com>

On 05/12/2023 03:28, Barry Song wrote:
> On Mon, Dec 4, 2023 at 11:20?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>>
>> Hi All,
>>
>> A new week, a new version, a new name... This is v8 of a series to implement
>> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
>> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
>> this fares better.
>>
>> The objective of this is to improve performance by allocating larger chunks of
>> memory during anonymous page faults:
>>
>> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>>    pages, there are efficiency savings to be had; fewer page faults, batched PTE
>>    and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>>    overhead. This should benefit all architectures.
>> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>>    advantage of HW TLB compression techniques. A reduction in TLB pressure
>>    speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>>    TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
>>
>> This version changes the name and tidies up some of the kernel code and test
>> code, based on feedback against v7 (see change log for details).
>>
>> By default, the existing behaviour (and performance) is maintained. The user
>> must explicitly enable multi-size THP to see the performance benefit. This is
>> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
>> David for the suggestion)! This interface is inspired by the existing
>> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
>> compatibility with the existing PMD-size THP interface, and provides a base for
>> future extensibility. See [8] for detailed discussion of the interface.
>>
>> This series is based on mm-unstable (715b67adf4c8).
>>
>>
>> Prerequisites
>> =============
>>
>> Some work items identified as being prerequisites are listed on page 3 at [9].
>> The summary is:
>>
>> | item                          | status                  |
>> |:------------------------------|:------------------------|
>> | mlock                         | In mainline (v6.7)      |
>> | madvise                       | In mainline (v6.6)      |
>> | compaction                    | v1 posted [10]          |
>> | numa balancing                | Investigated: see below |
>> | user-triggered page migration | In mainline (v6.7)      |
>> | khugepaged collapse           | In mainline (NOP)       |
>>
>> On NUMA balancing, which currently ignores any PTE-mapped THPs it encounters,
>> John Hubbard has investigated this and concluded that it is A) not clear at the
>> moment what a better policy might be for PTE-mapped THP and B) questions whether
>> this should really be considered a prerequisite given no regression is caused
>> for the default "multi-size THP disabled" case, and there is no correctness
>> issue when it is enabled - its just a potential for non-optimal performance.
>>
>> If there are no disagreements about removing numa balancing from the list (none
>> were raised when I first posted this comment against v7), then that just leaves
>> compaction which is in review on list at the moment.
>>
>> I really would like to get this series (and its remaining comapction
>> prerequisite) in for v6.8. I accept that it may be a bit optimistic at this
>> point, but lets see where we get to with review?
>>
> 
> Hi Ryan,
> 
> A question but i don't think it should block this series,  do we have any plan
> to extend /proc/meminfo, /proc/pid/smaps, /proc/vmstat to present some
> information regarding the new multi-size THP.
> 
> e.g how many folios in each-size for the system, how many multi-size folios LRU,
> how many large folios in each VMA etc.
> 
> In products and labs, we need some health monitors to make sure the system
> status is visible and works as expected. right now, i feel i am like
> blindly exploring
> the system without those statistics.

Yes it's definitely on the list. I had a patch in v6 that added various stats.
But after discussion with David, it became clear there were a few issues with
the implementation and I ripped it out. We also decided that since the page
cache already uses large folios and we don't have counters for those, we could
probably live (initially at least) without counters for multi-size THP too. But
you are the second person to raise this in as many weeks, so clearly this should
be at the top of the list for enhancements after this initial merge.

For now, you can parse /proc/<pid>/pagemap to see how well multi-size THP is
being utilized. That's not a simple interface though. Yu Zhou shared a Python
script a while back. I wonder if there is value in tidying that up and putting
it in tools/mm in the short term?

There were 2 main issues with the previous implementation:

1) What should the semantic of a counter be? Because a PTE-mapped THP can be
partially unmapped or mremapped. So should we count number of pages from a folio
of a given size that are mapped (easy) or should we only count when the whole
folio is contiguously mapped? (I'm sure there are many other semantics we could
consider). The latter is not easy to spot at the moment - perhaps the work David
has been doing on tidying up the rmap functions might help?

2) How should we expose the info? There has been pushback for extending files in
sysfs that expose multiple pieces of data, so David has suggested that in the
long term it might be good to completely redesign the stats interface.

It's certainly something that needs a lot more discussion - input encouraged!

Thanks,
Ryan


> 
>>
>> Testing
>> =======
>>
>> The series includes patches for mm selftests to enlighten the cow and khugepaged
>> tests to explicitly test with multi-size THP, in the same way that PMD-sized
>> THP is tested. The new tests all pass, and no regressions are observed in the mm
>> selftest suite. I've also run my usual kernel compilation and java script
>> benchmarks without any issues.
>>
>> Refer to my performance numbers posted with v6 [6]. (These are for multi-size
>> THP only - they do not include the arm64 contpte follow-on series).
>>
>> John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
>> some workloads at [11]. (Observed using v6 of this series as well as the arm64
>> contpte series).
>>
>> Kefeng Wang at Huawei has also indicated he sees improvements at [12] although
>> there are some latency regressions also.
>>
>>
>> Changes since v7 [7]
>> ====================
>>
>>   - Renamed "small-sized THP" -> "multi-size THP" in commit logs
>>   - Added various Reviewed-by/Tested-by tags (Barry, David, Alistair)
>>   - Patch 3:
>>       - Fine-tuned transhuge documentation multi-size THP (JohnH)
>>       - Converted hugepage_global_enabled() and hugepage_global_always() macros
>>         to static inline functions (JohnH)
>>       - Renamed hugepage_vma_check() to thp_vma_allowable_orders() (JohnH)
>>       - Renamed transhuge_vma_suitable() to thp_vma_suitable_orders() (JohnH)
>>       - Renamed "global" enabled sysfs file option to "inherit" (JohnH)
>>   - Patch 9:
>>       - cow selftest: Renamed param size -> thpsize (David)
>>       - cow selftest: Changed test fail to assert() (David)
>>       - cow selftest: Log PMD size separately from all the supported THP sizes
>>         (David)
>>   - Patch 10:
>>       - cow selftest: No longer special case pmdsize; keep all THP sizes in
>>         thpsizes[]
>>
>>
>> Changes since v6 [6]
>> ====================
>>
>>   - Refactored vmf_pte_range_changed() to remove uffd special-case (suggested by
>>     JohnH)
>>   - Dropped accounting patch (#3 in v6) (suggested by DavidH)
>>       - Continue to account *PMD-sized* THP only for now
>>       - Can add more counters in future if needed
>>       - Page cache large folios haven't needed any new counters yet
>>   - Pivot to sysfs ABI proposed by DavidH
>>       - per-size directories in a similar shape to that used by hugetlb
>>   - Dropped "recommend" keyword patch (#6 in v6) (suggested by DavidH, Yu Zhou)
>>       - For now, users need to understand implicitly which sizes are beneficial
>>         to their HW/SW
>>   - Dropped arch_wants_pte_order() patch (#7 in v6)
>>       - No longer needed due to dropping patch "recommend" keyword patch
>>   - Enlightened khugepaged mm selftest to explicitly test with small-size THP
>>   - Scrubbed commit logs to use "small-sized THP" consistently (suggested by
>>     DavidH)
>>
>>
>> Changes since v5 [5]
>> ====================
>>
>>   - Added accounting for PTE-mapped THPs (patch 3)
>>   - Added runtime control mechanism via sysfs as extension to THP (patch 4)
>>   - Minor refactoring of alloc_anon_folio() to integrate with runtime controls
>>   - Stripped out hardcoded policy for allocation order; its now all user space
>>     controlled (although user space can request "recommend" which will configure
>>     the HW-preferred order)
>>
>>
>> Changes since v4 [4]
>> ====================
>>
>>   - Removed "arm64: mm: Override arch_wants_pte_order()" patch; arm64
>>     now uses the default order-3 size. I have moved this patch over to
>>     the contpte series.
>>   - Added "mm: Allow deferred splitting of arbitrary large anon folios" back
>>     into series. I originally removed this at v2 to add to a separate series,
>>     but that series has transformed significantly and it no longer fits, so
>>     bringing it back here.
>>   - Reintroduced dependency on set_ptes(); Originally dropped this at v2, but
>>     set_ptes() is in mm-unstable now.
>>   - Updated policy for when to allocate LAF; only fallback to order-0 if
>>     MADV_NOHUGEPAGE is present or if THP disabled via prctl; no longer rely on
>>     sysfs's never/madvise/always knob.
>>   - Fallback to order-0 whenever uffd is armed for the vma, not just when
>>     uffd-wp is set on the pte.
>>   - alloc_anon_folio() now returns `struct folio *`, where errors are encoded
>>     with ERR_PTR().
>>
>>   The last 3 changes were proposed by Yu Zhao - thanks!
>>
>>
>> Changes since v3 [3]
>> ====================
>>
>>   - Renamed feature from FLEXIBLE_THP to LARGE_ANON_FOLIO.
>>   - Removed `flexthp_unhinted_max` boot parameter. Discussion concluded that a
>>     sysctl is preferable but we will wait until real workload needs it.
>>   - Fixed uninitialized `addr` on read fault path in do_anonymous_page().
>>   - Added mm selftests for large anon folios in cow test suite.
>>
>>
>> Changes since v2 [2]
>> ====================
>>
>>   - Dropped commit "Allow deferred splitting of arbitrary large anon folios"
>>       - Huang, Ying suggested the "batch zap" work (which I dropped from this
>>         series after v1) is a prerequisite for merging FLXEIBLE_THP, so I've
>>         moved the deferred split patch to a separate series along with the batch
>>         zap changes. I plan to submit this series early next week.
>>   - Changed folio order fallback policy
>>       - We no longer iterate from preferred to 0 looking for acceptable policy
>>       - Instead we iterate through preferred, PAGE_ALLOC_COSTLY_ORDER and 0 only
>>   - Removed vma parameter from arch_wants_pte_order()
>>   - Added command line parameter `flexthp_unhinted_max`
>>       - clamps preferred order when vma hasn't explicitly opted-in to THP
>>   - Never allocate large folio for MADV_NOHUGEPAGE vma (or when THP is disabled
>>     for process or system).
>>   - Simplified implementation and integration with do_anonymous_page()
>>   - Removed dependency on set_ptes()
>>
>>
>> Changes since v1 [1]
>> ====================
>>
>>   - removed changes to arch-dependent vma_alloc_zeroed_movable_folio()
>>   - replaced with arch-independent alloc_anon_folio()
>>       - follows THP allocation approach
>>   - no longer retry with intermediate orders if allocation fails
>>       - fallback directly to order-0
>>   - remove folio_add_new_anon_rmap_range() patch
>>       - instead add its new functionality to folio_add_new_anon_rmap()
>>   - remove batch-zap pte mappings optimization patch
>>       - remove enabler folio_remove_rmap_range() patch too
>>       - These offer real perf improvement so will submit separately
>>   - simplify Kconfig
>>       - single FLEXIBLE_THP option, which is independent of arch
>>       - depends on TRANSPARENT_HUGEPAGE
>>       - when enabled default to max anon folio size of 64K unless arch
>>         explicitly overrides
>>   - simplify changes to do_anonymous_page():
>>       - no more retry loop
>>
>>
>> [1] https://lore.kernel.org/linux-mm/20230626171430.3167004-1-ryan.roberts at arm.com/
>> [2] https://lore.kernel.org/linux-mm/20230703135330.1865927-1-ryan.roberts at arm.com/
>> [3] https://lore.kernel.org/linux-mm/20230714160407.4142030-1-ryan.roberts at arm.com/
>> [4] https://lore.kernel.org/linux-mm/20230726095146.2826796-1-ryan.roberts at arm.com/
>> [5] https://lore.kernel.org/linux-mm/20230810142942.3169679-1-ryan.roberts at arm.com/
>> [6] https://lore.kernel.org/linux-mm/20230929114421.3761121-1-ryan.roberts at arm.com/
>> [7] https://lore.kernel.org/linux-mm/20231122162950.3854897-1-ryan.roberts at arm.com/
>> [8] https://lore.kernel.org/linux-mm/6d89fdc9-ef55-d44e-bf12-fafff318aef8 at redhat.com/
>> [9] https://drive.google.com/file/d/1GnfYFpr7_c1kA41liRUW5YtCb8Cj18Ud/view?usp=sharing&resourcekey=0-U1Mj3-RhLD1JV6EThpyPyA
>> [10] https://lore.kernel.org/linux-mm/20231113170157.280181-1-zi.yan at sent.com/
>> [11] https://lore.kernel.org/linux-mm/c507308d-bdd4-5f9e-d4ff-e96e4520be85 at nvidia.com/
>> [12] https://lore.kernel.org/linux-mm/479b3e2b-456d-46c1-9677-38f6c95a0be8 at huawei.com/
>>
>>
>> Thanks,
>> Ryan
>>
>> Ryan Roberts (10):
>>   mm: Allow deferred splitting of arbitrary anon large folios
>>   mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()
>>   mm: thp: Introduce multi-size THP sysfs interface
>>   mm: thp: Support allocation of anonymous multi-size THP
>>   selftests/mm/kugepaged: Restore thp settings at exit
>>   selftests/mm: Factor out thp settings management
>>   selftests/mm: Support multi-size THP interface in thp_settings
>>   selftests/mm/khugepaged: Enlighten for multi-size THP
>>   selftests/mm/cow: Generalize do_run_with_thp() helper
>>   selftests/mm/cow: Add tests for anonymous multi-size THP
>>
>>  Documentation/admin-guide/mm/transhuge.rst |  97 ++++-
>>  Documentation/filesystems/proc.rst         |   6 +-
>>  fs/proc/task_mmu.c                         |   3 +-
>>  include/linux/huge_mm.h                    | 116 ++++--
>>  mm/huge_memory.c                           | 268 ++++++++++++--
>>  mm/khugepaged.c                            |  20 +-
>>  mm/memory.c                                | 114 +++++-
>>  mm/page_vma_mapped.c                       |   3 +-
>>  mm/rmap.c                                  |  32 +-
>>  tools/testing/selftests/mm/Makefile        |   4 +-
>>  tools/testing/selftests/mm/cow.c           | 185 +++++++---
>>  tools/testing/selftests/mm/khugepaged.c    | 410 ++++-----------------
>>  tools/testing/selftests/mm/run_vmtests.sh  |   2 +
>>  tools/testing/selftests/mm/thp_settings.c  | 349 ++++++++++++++++++
>>  tools/testing/selftests/mm/thp_settings.h  |  80 ++++
>>  15 files changed, 1177 insertions(+), 512 deletions(-)
>>  create mode 100644 tools/testing/selftests/mm/thp_settings.c
>>  create mode 100644 tools/testing/selftests/mm/thp_settings.h
>>
>> --
>> 2.25.1
>>
> 
> Thanks
> Barry



From mark.rutland at arm.com  Tue Dec  5 03:11:52 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 5 Dec 2023 11:11:52 +0000
Subject: [PATCH] ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support
In-Reply-To: <20231204-drop-11mpcore-v1-1-f96cd3938cf1@linaro.org>
References: <20231204-drop-11mpcore-v1-1-f96cd3938cf1@linaro.org>
Message-ID: <ZW8FeHURhRDGUEWn@FVFF77S0Q05N>

On Mon, Dec 04, 2023 at 11:36:44PM +0100, Linus Walleij wrote:
> This ARM11 SMP configuration was one of the first SMP configurations
> the ARM kernel supported, but it has the downside of odd DMA handling,
> odd cache tagging, and often (as of recent) completely broken cache
> handling on the ARM RealView PB11MPCore test chips. To boot the
> platform it was necessary to completely disable the cache.
> When it comes to the EB 11MPCore it is unclear if this ever worked.
> 
> These reference designs are now the only ARMv6K SMP platforms.
> 
> As only reference designs of purely academic interest remain, and
> since the special-cased DMA and PMU code is hard to maintain and
> doesn't really work, it is not really worth our time.
> 
> Delete the ARM11MPCore support along with:
> 
> - The special DMA quirk CONFIG_DMA_CACHE_RWFO that is only used
>   on ARMv6K SMP, and we are the last ARMV6K system leaving the
>   building and the cache handling is awkward, so good-bye.
> 
> - The special PMU handling that was only used by ARM11MPCore.
> 
> The following is left behind:
> 
> - TIMER_OF_DECLARE(arm_twd_11mp, "arm,arm11mp-twd-timer", ...)
>   in arch/arm/kernel/smp_twd.c, this is still in use by Marvell MMP3
>   arch/arm/boot/dts/marvell/mmp3.dtsi
> 
> - IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", ...)
>   in drivers/irqchip/irq-gic.c, this is still in use by Marvell MMP3
>   arch/arm/boot/dts/marvell/mmp3.dtsi
> 
> These are unfortunate but will need to be kept around for
> compatibility. New Marvell-specific compatibles should however probably
> be added.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  arch/arm/kernel/perf_event_v6.c            | 34 ------------------------------
>  arch/arm/mach-versatile/Kconfig            | 17 ---------------
>  arch/arm/mach-versatile/platsmp-realview.c |  2 --
>  arch/arm/mach-versatile/realview.c         |  1 -
>  arch/arm/mm/Kconfig                        | 18 ----------------
>  arch/arm/mm/cache-v6.S                     | 31 ---------------------------
>  6 files changed, 103 deletions(-)

This looks good to me, so FWIW:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> 
> diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
> index 1ae99deeec54..3115077f6abc 100644
> --- a/arch/arm/kernel/perf_event_v6.c
> +++ b/arch/arm/kernel/perf_event_v6.c
> @@ -525,40 +525,7 @@ static int armv6_1176_pmu_init(struct arm_pmu *cpu_pmu)
>  	return 0;
>  }
>  
> -/*
> - * ARMv6mpcore is almost identical to single core ARMv6 with the exception
> - * that some of the events have different enumerations and that there is no
> - * *hack* to stop the programmable counters. To stop the counters we simply
> - * disable the interrupt reporting and update the event. When unthrottling we
> - * reset the period and enable the interrupt reporting.
> - */
> -
> -static int armv6mpcore_map_event(struct perf_event *event)
> -{
> -	return armpmu_map_event(event, &armv6mpcore_perf_map,
> -				&armv6mpcore_perf_cache_map, 0xFF);
> -}
> -
> -static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
> -{
> -	cpu_pmu->name		= "armv6_11mpcore";
> -	cpu_pmu->handle_irq	= armv6pmu_handle_irq;
> -	cpu_pmu->enable		= armv6pmu_enable_event;
> -	cpu_pmu->disable	= armv6mpcore_pmu_disable_event;
> -	cpu_pmu->read_counter	= armv6pmu_read_counter;
> -	cpu_pmu->write_counter	= armv6pmu_write_counter;
> -	cpu_pmu->get_event_idx	= armv6pmu_get_event_idx;
> -	cpu_pmu->clear_event_idx = armv6pmu_clear_event_idx;
> -	cpu_pmu->start		= armv6pmu_start;
> -	cpu_pmu->stop		= armv6pmu_stop;
> -	cpu_pmu->map_event	= armv6mpcore_map_event;
> -	cpu_pmu->num_events	= 3;
> -
> -	return 0;
> -}
> -
>  static const struct of_device_id armv6_pmu_of_device_ids[] = {
> -	{.compatible = "arm,arm11mpcore-pmu",	.data = armv6mpcore_pmu_init},
>  	{.compatible = "arm,arm1176-pmu",	.data = armv6_1176_pmu_init},
>  	{.compatible = "arm,arm1136-pmu",	.data = armv6_1136_pmu_init},
>  	{ /* sentinel value */ }
> @@ -568,7 +535,6 @@ static const struct pmu_probe_info armv6_pmu_probe_table[] = {
>  	ARM_PMU_PROBE(ARM_CPU_PART_ARM1136, armv6_1136_pmu_init),
>  	ARM_PMU_PROBE(ARM_CPU_PART_ARM1156, armv6_1156_pmu_init),
>  	ARM_PMU_PROBE(ARM_CPU_PART_ARM1176, armv6_1176_pmu_init),
> -	ARM_PMU_PROBE(ARM_CPU_PART_ARM11MPCORE, armv6mpcore_pmu_init),
>  	{ /* sentinel value */ }
>  };
>  
> diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
> index b1519b4dc03a..e029270c2687 100644
> --- a/arch/arm/mach-versatile/Kconfig
> +++ b/arch/arm/mach-versatile/Kconfig
> @@ -201,23 +201,6 @@ config REALVIEW_EB_A9MP
>  	  Enable support for the Cortex-A9MPCore tile fitted to the
>  	  Realview(R) Emulation Baseboard platform.
>  
> -config REALVIEW_EB_ARM11MP
> -	bool "Support ARM11MPCore Tile"
> -	depends on MACH_REALVIEW_EB && ARCH_MULTI_V6
> -	select HAVE_SMP
> -	help
> -	  Enable support for the ARM11MPCore tile fitted to the Realview(R)
> -	  Emulation Baseboard platform.
> -
> -config MACH_REALVIEW_PB11MP
> -	bool "Support RealView(R) Platform Baseboard for ARM11MPCore"
> -	depends on ARCH_MULTI_V6
> -	select HAVE_SMP
> -	help
> -	  Include support for the ARM(R) RealView(R) Platform Baseboard for
> -	  the ARM11MPCore.  This platform has an on-board ARM11MPCore and has
> -	  support for PCI-E and Compact Flash.
> -
>  # ARMv6 CPU without K extensions, but does have the new exclusive ops
>  config MACH_REALVIEW_PB1176
>  	bool "Support RealView(R) Platform Baseboard for ARM1176JZF-S"
> diff --git a/arch/arm/mach-versatile/platsmp-realview.c b/arch/arm/mach-versatile/platsmp-realview.c
> index 5d363385c801..4c3e089ac686 100644
> --- a/arch/arm/mach-versatile/platsmp-realview.c
> +++ b/arch/arm/mach-versatile/platsmp-realview.c
> @@ -18,7 +18,6 @@
>  #define REALVIEW_SYS_FLAGSSET_OFFSET	0x30
>  
>  static const struct of_device_id realview_scu_match[] = {
> -	{ .compatible = "arm,arm11mp-scu", },
>  	{ .compatible = "arm,cortex-a9-scu", },
>  	{ .compatible = "arm,cortex-a5-scu", },
>  	{ }
> @@ -27,7 +26,6 @@ static const struct of_device_id realview_scu_match[] = {
>  static const struct of_device_id realview_syscon_match[] = {
>          { .compatible = "arm,core-module-integrator", },
>          { .compatible = "arm,realview-eb-syscon", },
> -        { .compatible = "arm,realview-pb11mp-syscon", },
>          { .compatible = "arm,realview-pbx-syscon", },
>          { },
>  };
> diff --git a/arch/arm/mach-versatile/realview.c b/arch/arm/mach-versatile/realview.c
> index a3933e2373d5..36a6f6bc4fdd 100644
> --- a/arch/arm/mach-versatile/realview.c
> +++ b/arch/arm/mach-versatile/realview.c
> @@ -9,7 +9,6 @@
>  static const char *const realview_dt_platform_compat[] __initconst = {
>  	"arm,realview-eb",
>  	"arm,realview-pb1176",
> -	"arm,realview-pb11mp",
>  	"arm,realview-pba8",
>  	"arm,realview-pbx",
>  	NULL,
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index c164cde50243..2b6f50dd5478 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -937,24 +937,6 @@ config VDSO
>  	  You must have glibc 2.22 or later for programs to seamlessly
>  	  take advantage of this.
>  
> -config DMA_CACHE_RWFO
> -	bool "Enable read/write for ownership DMA cache maintenance"
> -	depends on CPU_V6K && SMP
> -	default y
> -	help
> -	  The Snoop Control Unit on ARM11MPCore does not detect the
> -	  cache maintenance operations and the dma_{map,unmap}_area()
> -	  functions may leave stale cache entries on other CPUs. By
> -	  enabling this option, Read or Write For Ownership in the ARMv6
> -	  DMA cache maintenance functions is performed. These LDR/STR
> -	  instructions change the cache line state to shared or modified
> -	  so that the cache operation has the desired effect.
> -
> -	  Note that the workaround is only valid on processors that do
> -	  not perform speculative loads into the D-cache. For such
> -	  processors, if cache maintenance operations are not broadcast
> -	  in hardware, other workarounds are needed (e.g. cache
> -	  maintenance broadcasting in software via FIQ).
>  
>  config OUTER_CACHE
>  	bool
> diff --git a/arch/arm/mm/cache-v6.S b/arch/arm/mm/cache-v6.S
> index 250c83bf7158..44211d8a296f 100644
> --- a/arch/arm/mm/cache-v6.S
> +++ b/arch/arm/mm/cache-v6.S
> @@ -201,10 +201,6 @@ ENTRY(v6_flush_kern_dcache_area)
>   *	- end     - virtual end address of region
>   */
>  v6_dma_inv_range:
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrb	r2, [r0]			@ read for ownership
> -	strb	r2, [r0]			@ write for ownership
> -#endif
>  	tst	r0, #D_CACHE_LINE_SIZE - 1
>  	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
>  #ifdef HARVARD_CACHE
> @@ -213,10 +209,6 @@ v6_dma_inv_range:
>  	mcrne	p15, 0, r0, c7, c11, 1		@ clean unified line
>  #endif
>  	tst	r1, #D_CACHE_LINE_SIZE - 1
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrbne	r2, [r1, #-1]			@ read for ownership
> -	strbne	r2, [r1, #-1]			@ write for ownership
> -#endif
>  	bic	r1, r1, #D_CACHE_LINE_SIZE - 1
>  #ifdef HARVARD_CACHE
>  	mcrne	p15, 0, r1, c7, c14, 1		@ clean & invalidate D line
> @@ -231,10 +223,6 @@ v6_dma_inv_range:
>  #endif
>  	add	r0, r0, #D_CACHE_LINE_SIZE
>  	cmp	r0, r1
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrlo	r2, [r0]			@ read for ownership
> -	strlo	r2, [r0]			@ write for ownership
> -#endif
>  	blo	1b
>  	mov	r0, #0
>  	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer
> @@ -248,9 +236,6 @@ v6_dma_inv_range:
>  v6_dma_clean_range:
>  	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
>  1:
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldr	r2, [r0]			@ read for ownership
> -#endif
>  #ifdef HARVARD_CACHE
>  	mcr	p15, 0, r0, c7, c10, 1		@ clean D line
>  #else
> @@ -269,10 +254,6 @@ v6_dma_clean_range:
>   *	- end     - virtual end address of region
>   */
>  ENTRY(v6_dma_flush_range)
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrb	r2, [r0]		@ read for ownership
> -	strb	r2, [r0]		@ write for ownership
> -#endif
>  	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
>  1:
>  #ifdef HARVARD_CACHE
> @@ -282,10 +263,6 @@ ENTRY(v6_dma_flush_range)
>  #endif
>  	add	r0, r0, #D_CACHE_LINE_SIZE
>  	cmp	r0, r1
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrblo	r2, [r0]			@ read for ownership
> -	strblo	r2, [r0]			@ write for ownership
> -#endif
>  	blo	1b
>  	mov	r0, #0
>  	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer
> @@ -301,13 +278,7 @@ ENTRY(v6_dma_map_area)
>  	add	r1, r1, r0
>  	teq	r2, #DMA_FROM_DEVICE
>  	beq	v6_dma_inv_range
> -#ifndef CONFIG_DMA_CACHE_RWFO
>  	b	v6_dma_clean_range
> -#else
> -	teq	r2, #DMA_TO_DEVICE
> -	beq	v6_dma_clean_range
> -	b	v6_dma_flush_range
> -#endif
>  ENDPROC(v6_dma_map_area)
>  
>  /*
> @@ -317,11 +288,9 @@ ENDPROC(v6_dma_map_area)
>   *	- dir	- DMA direction
>   */
>  ENTRY(v6_dma_unmap_area)
> -#ifndef CONFIG_DMA_CACHE_RWFO
>  	add	r1, r1, r0
>  	teq	r2, #DMA_TO_DEVICE
>  	bne	v6_dma_inv_range
> -#endif
>  	ret	lr
>  ENDPROC(v6_dma_unmap_area)
>  
> 
> ---
> base-commit: d570fe67df85c84be7cc33ca9e9568d9601b494f
> change-id: 20231202-drop-11mpcore-d556cc5f7d99
> 
> Best regards,
> -- 
> Linus Walleij <linus.walleij at linaro.org>
> 


From ryan.roberts at arm.com  Tue Dec  5 03:13:18 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 5 Dec 2023 11:13:18 +0000
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <2be046e1-ef95-4244-ae23-e56071ae1218@nvidia.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <2be046e1-ef95-4244-ae23-e56071ae1218@nvidia.com>
Message-ID: <888e20e4-6073-426c-9159-e359c758d78a@arm.com>

On 05/12/2023 03:37, John Hubbard wrote:
> On 12/4/23 02:20, Ryan Roberts wrote:
>> Hi All,
>>
>> A new week, a new version, a new name... This is v8 of a series to implement
>> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
>> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
>> this fares better.
>>
>> The objective of this is to improve performance by allocating larger chunks of
>> memory during anonymous page faults:
>>
>> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>> ??? pages, there are efficiency savings to be had; fewer page faults, batched PTE
>> ??? and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>> ??? overhead. This should benefit all architectures.
>> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>> ??? advantage of HW TLB compression techniques. A reduction in TLB pressure
>> ??? speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>> ??? TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
>>
>> This version changes the name and tidies up some of the kernel code and test
>> code, based on feedback against v7 (see change log for details).
> 
> Using a couple of Armv8 systems, I've tested this patchset. I applied it
> to top of tree (Linux 6.7-rc4), on top of your latest contig pte series
> [1].
> 
> With those two patchsets applied, the mm selftests look OK--or at least
> as OK as they normally do. I compared test runs between THP/mTHP set to
> "always", vs "never", to verify that there were no new test failures.
> Details: specifically, I set one particular page size (2 MB) to
> "inherit", and then toggled /sys/kernel/mm/transparent_hugepage/enabled
> between "always" and "never".

Excellent - I'm guessing this was for 64K base pages?

> 
> I also re-ran my usual compute/AI benchmark, and I'm still seeing the
> same 10x performance improvement that I reported for the v6 patchset.
> 
> So for this patchset and for [1] as well, please feel free to add:
> 
> Tested-by: John Hubbard <jhubbard at nvidia.com>

Thanks!

> 
> 
> [1] https://lore.kernel.org/all/20231204105440.61448-1-ryan.roberts at arm.com/
> 
> 
> thanks,



From alexander.sverdlin at siemens.com  Tue Dec  5 03:15:51 2023
From: alexander.sverdlin at siemens.com (Sverdlin, Alexander)
Date: Tue, 5 Dec 2023 11:15:51 +0000
Subject: [PATCH] arm64: dts: ti: k3-am62-main: Add GPU device node
In-Reply-To: <20231204121522.47862-1-donald.robson@imgtec.com>
References: <20231204121522.47862-1-donald.robson@imgtec.com>
Message-ID: <c20b213534667337f08b75a6c325fafec6526135.camel@siemens.com>

Hi Donald, Sarah et al,

thanks for the patch!

On Mon, 2023-12-04 at 12:15 +0000, Donald Robson wrote:
> From: Sarah Walker <sarah.walker at imgtec.com>
> 
> Add the Series AXE GPU node to the AM62 device tree.
> 
> Signed-off-by: Sarah Walker <sarah.walker at imgtec.com>
> Signed-off-by: Donald Robson <donald.robson at imgtec.com>

powervr fd00000.gpu: [drm] loaded firmware powervr/rogue_33.15.11.3_v1.fw
powervr fd00000.gpu: [drm] FW version v1.0 (build 6503725 OS)
[drm] Initialized powervr 1.0.0 20230904 for fd00000.gpu on minor 0

In general it allows the driver to be probed on TI AM625 EK, so
Tested-by: Alexander Sverdlin <alexander.sverdlin at siemens.com>

But I'm not sure if you maybe want to disable it by default like
other HW blocks for the (potential) boards which don't have video at all.

> ---
> ?arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 9 +++++++++
> ?1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> index e5c64c86d1d5..4338fd8ab2d7 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> @@ -965,4 +965,13 @@ mcasp2: audio-controller at 2b20000 {
> ????????????????power-domains = <&k3_pds 192 TI_SCI_PD_EXCLUSIVE>;
> ????????????????status = "disabled";
> ????????};
> +
> +???????gpu: gpu at fd00000 {
> +???????????????compatible = "ti,am62-gpu", "img,img-axe";
> +???????????????reg = <0x00 0x0fd00000 0x00 0x20000>;
> +???????????????clocks = <&k3_clks 187 0>;
> +???????????????clock-names = "core";
> +???????????????interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
> +???????????????power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>;
> +???????};
> ?};

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

From a.fatoum at pengutronix.de  Tue Dec  5 03:15:58 2023
From: a.fatoum at pengutronix.de (Ahmad Fatoum)
Date: Tue, 5 Dec 2023 12:15:58 +0100
Subject: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAD=FV=WXQrbnjeVOLp--vmLzScvW9VLFRu+apSY4WnL9JFk-AQ@mail.gmail.com>
References: <20231129172200.430674-1-sjg@chromium.org>
 <20231129172200.430674-3-sjg@chromium.org>
 <30f32467-51ea-47de-a272-38e074f4060b@pengutronix.de>
 <CAPnjgZ25xoXsi74XYY0E8ucQiowQqPdZgUHrfVNAYWKZEYODHg@mail.gmail.com>
 <875f0dbc-1d78-4901-91b2-6ad152bcea5a@pengutronix.de>
 <CAPnjgZ0UCkm5QCx+JXe1ggSshozPnOLB6cN=UoJyMn6S4wfFkg@mail.gmail.com>
 <06281f7c-e0f2-405c-95a9-0f7e9e84a7f6@pengutronix.de>
 <CAPnjgZ2TT+0BvbjwfnGLQ3EPEXnLW6f1epiFdaBHRYaSAn5xsA@mail.gmail.com>
 <8fbc81b1-31ab-46b0-87f4-b8bd8e8e2b47@pengutronix.de>
 <CAPnjgZ1iyxk0bb56QR10N5aSphRYhLsw7Ly=z2i6rQCxP_AYPw@mail.gmail.com>
 <5e8f42f8-2b03-4033-b6d2-9b3139f081d5@pengutronix.de>
 <CAPnjgZ2RjNzqJTRZSWvuscQhs+f8CG=fDcEO=qKXNeQLP53LnQ@mail.gmail.com>
 <CAD=FV=WXQrbnjeVOLp--vmLzScvW9VLFRu+apSY4WnL9JFk-AQ@mail.gmail.com>
Message-ID: <653b592b-bd6a-48f8-acca-c617c5c8c1a3@pengutronix.de>

Hello,

On 04.12.23 18:52, Doug Anderson wrote:> On Sat, Dec 2, 2023 at 8:37?AM Simon Glass <sjg at chromium.org> wrote:
>> On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
>>> On 30.11.23 21:30, Simon Glass wrote:
>>>> On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
>>>>> On 29.11.23 20:44, Simon Glass wrote:
>>>> I don't have an example to hand, but this is the required mechanism of
>>>> FIT. This feature has been in place for many years and is used by
>>>> ChromeOS, at least.
>>>
>>> I see the utility of a FIT configuration with
>>>
>>>     compatible = "vendor,board-rev-a", "vendor,board-rev-b";
>>>
>>> I fail to see a utility for a configuration with
>>>
>>>     compatible = "vendor,board", "vendor,SoM", "vendor,SoC";
>>>
>>> Any configuration that ends up being booted because "vendor,SoC" was matched is
>>> most likely doomed to fail. Therefore, I would suggest that only the top level
>>> configuration is written into the FIT configurations automatically.
>>
>> Firstly, I am not an expert on this.
>>
>> Say you have a board with variants. The compatible string in U-Boot
>> may be something like:
>>
>> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
>> "rockchip,rk3288";
>>
>> If you then have several FIT configurations, they may be something like:
>>
>> "google,veyron-brain-rev0", "google,veyron-brain", "google,veyron",
>> "rockchip,rk3288";
>> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
>> "rockchip,rk3288";
>> "google,veyron-brain-rev2", "google,veyron-brain", "google,veyron",
>> "rockchip,rk3288";
>>
>> You want to choose the second one, since it is a better match than the others.

Now imagine, you are building a kernel that has no DT support for the Veyron,
but instead has support for the Phytec RK3288 PCM-947:

  phytec,rk3288-pcm-947", "phytec,rk3288-phycore-som", "rockchip,rk3288

As far as I understand U-Boot code, A veyron U-Boot would boot the Phytec DT
if CONFIG_FIT_BEST_MATCH is set, although it's a bad match and a boot failure
should rather have occurred.

>> +Doug Anderson who knows a lot more about this than me.
> 
> Hopefully this is all explained by:
> 
> https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html

Thanks Doug, this was helpful. The missing information to me was that
depthcharge only compares the top-level board compatible in addition
to runtime generated board compatibles, unlike what U-Boot seems to do.

barebox only compares its top-level compatible against the FIT configuration
compatibles, so adding a full compatible list to the configuration nodes as done
by this series should be ok there as well. I think U-Boot could run into
issues though as described above.

Out of curiosity: I only heard about Depthcharge before as exploitation toolkit
for U-Boot. Can you point me at some documentation on what the Depthcharge bootloader
does what U-Boot (which was presumably used before?) doesn't?

Thanks,
Ahmad

> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



From david at redhat.com  Tue Dec  5 03:16:13 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 12:16:13 +0100
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <5216caaf-1fcf-4715-99c3-521e2a1cc756@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <CAGsJ_4zG6W_Z-u+3QcRDn4ByoeqUXjMusNS0RotfRMSqo8RCHg@mail.gmail.com>
 <CAGsJ_4zYhJWGx1DnHTiDnP3h1m8_rr6ZT6fXt8pO=jzs9QZS-A@mail.gmail.com>
 <5216caaf-1fcf-4715-99c3-521e2a1cc756@arm.com>
Message-ID: <20c867c9-9206-47b5-baf4-ddb748a43370@redhat.com>

On 05.12.23 11:48, Ryan Roberts wrote:
> On 05/12/2023 01:24, Barry Song wrote:
>> On Tue, Dec 5, 2023 at 9:15?AM Barry Song <21cnbao at gmail.com> wrote:
>>>
>>> On Mon, Dec 4, 2023 at 6:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>>>>
>>>> Introduce the logic to allow THP to be configured (through the new sysfs
>>>> interface we just added) to allocate large folios to back anonymous
>>>> memory, which are larger than the base page size but smaller than
>>>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>>>>
>>>> mTHP continues to be PTE-mapped, but in many cases can still provide
>>>> similar benefits to traditional PMD-sized THP: Page faults are
>>>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
>>>> the configured order), but latency spikes are much less prominent
>>>> because the size of each page isn't as huge as the PMD-sized variant and
>>>> there is less memory to clear in each page fault. The number of per-page
>>>> operations (e.g. ref counting, rmap management, lru list management) are
>>>> also significantly reduced since those ops now become per-folio.
>>>>
>>>> Some architectures also employ TLB compression mechanisms to squeeze
>>>> more entries in when a set of PTEs are virtually and physically
>>>> contiguous and approporiately aligned. In this case, TLB misses will
>>>> occur less often.
>>>>
>>>> The new behaviour is disabled by default, but can be enabled at runtime
>>>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
>>>> (see documentation in previous commit). The long term aim is to change
>>>> the default to include suitable lower orders, but there are some risks
>>>> around internal fragmentation that need to be better understood first.
>>>>
>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>> ---
>>>>   include/linux/huge_mm.h |   6 ++-
>>>>   mm/memory.c             | 106 ++++++++++++++++++++++++++++++++++++----
>>>>   2 files changed, 101 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>>> index bd0eadd3befb..91a53b9835a4 100644
>>>> --- a/include/linux/huge_mm.h
>>>> +++ b/include/linux/huge_mm.h
>>>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>>>>   #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>>>>
>>>>   /*
>>>> - * Mask of all large folio orders supported for anonymous THP.
>>>> + * Mask of all large folio orders supported for anonymous THP; all orders up to
>>>> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
>>>> + * (which is a limitation of the THP implementation).
>>>>    */
>>>> -#define THP_ORDERS_ALL_ANON    BIT(PMD_ORDER)
>>>> +#define THP_ORDERS_ALL_ANON    ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>>>>
>>>>   /*
>>>>    * Mask of all large folio orders supported for file THP.
>>>> diff --git a/mm/memory.c b/mm/memory.c
>>>> index 3ceeb0f45bf5..bf7e93813018 100644
>>>> --- a/mm/memory.c
>>>> +++ b/mm/memory.c
>>>> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>>          return ret;
>>>>   }
>>>>
>>>> +static bool pte_range_none(pte_t *pte, int nr_pages)
>>>> +{
>>>> +       int i;
>>>> +
>>>> +       for (i = 0; i < nr_pages; i++) {
>>>> +               if (!pte_none(ptep_get_lockless(pte + i)))
>>>> +                       return false;
>>>> +       }
>>>> +
>>>> +       return true;
>>>> +}
>>>> +
>>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>>>> +{
>>>> +       gfp_t gfp;
>>>> +       pte_t *pte;
>>>> +       unsigned long addr;
>>>> +       struct folio *folio;
>>>> +       struct vm_area_struct *vma = vmf->vma;
>>>> +       unsigned long orders;
>>>> +       int order;
>>>> +
>>>> +       /*
>>>> +        * If uffd is active for the vma we need per-page fault fidelity to
>>>> +        * maintain the uffd semantics.
>>>> +        */
>>>> +       if (userfaultfd_armed(vma))
>>>> +               goto fallback;
>>>> +
>>>> +       /*
>>>> +        * Get a list of all the (large) orders below PMD_ORDER that are enabled
>>>> +        * for this vma. Then filter out the orders that can't be allocated over
>>>> +        * the faulting address and still be fully contained in the vma.
>>>> +        */
>>>> +       orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
>>>> +                                         BIT(PMD_ORDER) - 1);
>>>> +       orders = thp_vma_suitable_orders(vma, vmf->address, orders);
>>>> +
>>>> +       if (!orders)
>>>> +               goto fallback;
>>>> +
>>>> +       pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>>> +       if (!pte)
>>>> +               return ERR_PTR(-EAGAIN);
>>>> +
>>>> +       order = first_order(orders);
>>>> +       while (orders) {
>>>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>> +               vmf->pte = pte + pte_index(addr);
>>>> +               if (pte_range_none(vmf->pte, 1 << order))
>>>> +                       break;
>>>> +               order = next_order(&orders, order);
>>>> +       }
>>>> +
>>>> +       vmf->pte = NULL;
>>>> +       pte_unmap(pte);
>>>> +
>>>> +       gfp = vma_thp_gfp_mask(vma);
>>>> +
>>>> +       while (orders) {
>>>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>> +               folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>>> +               if (folio) {
>>>> +                       clear_huge_page(&folio->page, addr, 1 << order);
>>>
>>> Minor.
>>>
>>> Do we have to constantly clear a huge page? Is it possible to let
>>> post_alloc_hook()
>>> finish this job by using __GFP_ZERO/__GFP_ZEROTAGS as
>>> vma_alloc_zeroed_movable_folio() is doing?
> 
> I'm currently following the same allocation pattern as is done for PMD-sized
> THP. In earlier versions of this patch I was trying to be smarter and use the
> __GFP_ZERO/__GFP_ZEROTAGS as you suggest, but I was advised to keep it simple
> and follow the existing pattern.

Yes, this should be optimized on top IMHO.

-- 
Cheers,

David / dhildenb



From maz at kernel.org  Tue Dec  5 03:19:58 2023
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 05 Dec 2023 11:19:58 +0000
Subject: [PATCH v1 1/6] KVM: arm64: Update and fix FGT register masks
In-Reply-To: <20231205102248.1915895-2-tabba@google.com>
References: <20231205102248.1915895-1-tabba@google.com>
	<20231205102248.1915895-2-tabba@google.com>
Message-ID: <86edg0c2w1.wl-maz@kernel.org>

On Tue, 05 Dec 2023 10:22:43 +0000,
Fuad Tabba <tabba at google.com> wrote:
> 
> New trap bits have been defined in the latest Arm Architecture
> System Registers xml specification [*]. Moreover, the existing
> definitions of some of the mask and the res0 bits overlap, which

nit: s/res0/RES0/

> could be wrong, confusing, or potentially both.
> 
> Update the bits to represent the latest spec (as of this patch),
> and ensure that the existing bits are consistent.
> 
> [*] https://developer.arm.com/downloads/-/exploration-tools

Please indicate which version of the XML you are referring to (it
changes on average every 3 months).

> 
> Fixes: 0fd76865006d ("KVM: arm64: Add nPIR{E0}_EL1 to HFG traps")
> Signed-off-by: Fuad Tabba <tabba at google.com>
> ---
>  arch/arm64/include/asm/kvm_arm.h | 39 ++++++++++++++++++++------------
>  1 file changed, 24 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index b85f46a73e21..b1061647e837 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -344,36 +344,45 @@
>   * Once we get to a point where the two describe the same thing, we'll
>   * merge the definitions. One day.
>   */
> -#define __HFGRTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51))
> +#define __HFGRTR_EL2_RES0	BIT(51)

If we are now using the current architectural definition for RES0, can
we please move over to the generated values, as indicated in the above
comment?

>  #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
> -#define __HFGRTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> +#define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
>  
> -#define __HFGWTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51) |	\
> -				 BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
> -				 GENMASK(26, 25) | BIT(21) | BIT(18) |	\
> +#define __HFGWTR_EL2_RES0	(BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
> +				 BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
>  				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
> -#define __HFGWTR_EL2_MASK	GENMASK(49, 0)
> -#define __HFGWTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> +#define __HFGWTR_EL2_MASK	(GENMASK(49, 47) | GENMASK(45, 43) | \
> +				 BIT(41) | GENMASK(39, 29) | BIT(27) | \
> +				 GENMASK(24, 22) | GENMASK(20, 19) | \
> +				 GENMASK(17, 16) | GENMASK(13, 11) | \
> +				 GENMASK(8, 3) | GENMASK(1, 0))
> +#define __HFGWTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
>  
> -#define __HFGITR_EL2_RES0	GENMASK(63, 57)
> -#define __HFGITR_EL2_MASK	GENMASK(54, 0)
> -#define __HFGITR_EL2_nMASK	GENMASK(56, 55)
> +#define __HFGITR_EL2_RES0	(BIT(63) | BIT(61))
> +#define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
> +#define __HFGITR_EL2_nMASK	GENMASK(59, 55)
>  
>  #define __HDFGRTR_EL2_RES0	(BIT(49) | BIT(42) | GENMASK(39, 38) |	\
>  				 GENMASK(21, 20) | BIT(8))
> -#define __HDFGRTR_EL2_MASK	~__HDFGRTR_EL2_nMASK
> +#define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
> +				 GENMASK(41, 40) | GENMASK(37, 22) | \
> +				 GENMASK(19, 9) | GENMASK(7, 0))
>  #define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
>  
>  #define __HDFGWTR_EL2_RES0	(BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
>  				 BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
>  				 BIT(22) | BIT(9) | BIT(6))
> -#define __HDFGWTR_EL2_MASK	~__HDFGWTR_EL2_nMASK
> +#define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
> +				 GENMASK(46, 44) | GENMASK(42, 41) | \
> +				 GENMASK(37, 35) | GENMASK(33, 31) | \
> +				 GENMASK(29, 23) | GENMASK(21, 10) | \
> +				 GENMASK(8, 7) | GENMASK(5, 0))
>  #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
>  
>  /* Similar definitions for HCRX_EL2 */
> -#define __HCRX_EL2_RES0		(GENMASK(63, 16) | GENMASK(13, 12))
> -#define __HCRX_EL2_MASK		(0)
> -#define __HCRX_EL2_nMASK	(GENMASK(15, 14) | GENMASK(4, 0))
> +#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
> +#define __HCRX_EL2_MASK		(BIT(6))
> +#define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
>  
>  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
>  #define HPFAR_MASK	(~UL(0xf))

The main driver for not following the latest and greatest version
published in the architecture (including the FGT2 stuff) was to limit
the amount of work we need to do in NV.

Can you please update the FGT tables in emulated-nested.c so that we
have a matching description of the added bits? This also overlaps with
the work Joey is doing on POE, so there is scope for collaboration
between you two here.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


From Donald.Robson at imgtec.com  Tue Dec  5 03:26:04 2023
From: Donald.Robson at imgtec.com (Donald Robson)
Date: Tue, 5 Dec 2023 11:26:04 +0000
Subject: [PATCH] arm64: dts: ti: k3-am62-main: Add GPU device node
In-Reply-To: <c20b213534667337f08b75a6c325fafec6526135.camel@siemens.com>
References: <20231204121522.47862-1-donald.robson@imgtec.com>
	 <c20b213534667337f08b75a6c325fafec6526135.camel@siemens.com>
Message-ID: <6e71745a9258ecd384261369656dd05da5ab10fa.camel@imgtec.com>

Hello Alexander,

On Tue, 2023-12-05 at 11:15 +0000, Sverdlin, Alexander wrote:
> Hi Donald, Sarah et al,
> 
> thanks for the patch!
> 
> On Mon, 2023-12-04 at 12:15 +0000, Donald Robson wrote:
> > From: Sarah Walker <sarah.walker at imgtec.com>
> > 
> > Add the Series AXE GPU node to the AM62 device tree.
> > 
> > Signed-off-by: Sarah Walker <sarah.walker at imgtec.com>
> > Signed-off-by: Donald Robson <donald.robson at imgtec.com>
> 
> powervr fd00000.gpu: [drm] loaded firmware powervr/rogue_33.15.11.3_v1.fw
> powervr fd00000.gpu: [drm] FW version v1.0 (build 6503725 OS)
> [drm] Initialized powervr 1.0.0 20230904 for fd00000.gpu on minor 0
> 
> In general it allows the driver to be probed on TI AM625 EK, so
> Tested-by: Alexander Sverdlin <alexander.sverdlin at siemens.com>

Thanks!

> 
> But I'm not sure if you maybe want to disable it by default like
> other HW blocks for the (potential) boards which don't have video at all.

Nor I. I guess it should still be enabled so it can be used for compute?

Thanks,
Donald

> 
> > ---
> >  arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> > index e5c64c86d1d5..4338fd8ab2d7 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> > +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> > @@ -965,4 +965,13 @@ mcasp2: audio-controller at 2b20000 {
> >                 power-domains = <&k3_pds 192 TI_SCI_PD_EXCLUSIVE>;
> >                 status = "disabled";
> >         };
> > +
> > +       gpu: gpu at fd00000 {
> > +               compatible = "ti,am62-gpu", "img,img-axe";
> > +               reg = <0x00 0x0fd00000 0x00 0x20000>;
> > +               clocks = <&k3_clks 187 0>;
> > +               clock-names = "core";
> > +               interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
> > +               power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>;
> > +       };
> >  };

From ryan.roberts at arm.com  Tue Dec  5 03:30:56 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 5 Dec 2023 11:30:56 +0000
Subject: [PATCH v3 01/15] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <5b8b9f8c-8e9b-42a5-b8b2-9b96903f3ada@redhat.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-2-ryan.roberts@arm.com>
 <a12ce4f8-feb0-4e35-8f55-9270fe5a808b@redhat.com>
 <104de2d6-ecf9-4b0c-a982-5bd8e1aea758@redhat.com>
 <5b8b9f8c-8e9b-42a5-b8b2-9b96903f3ada@redhat.com>
Message-ID: <a81dc390-8b10-4ce9-b72f-57f253e77af3@arm.com>

On 04/12/2023 17:27, David Hildenbrand wrote:
>>
>> With rmap batching from [1] -- rebased+changed on top of that -- we could turn
>> that into an effective (untested):
>>
>> ????????? if (page && folio_test_anon(folio)) {
>> +?????????????? nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
>> +?????????????????????????????????????????????? pte, enforce_uffd_wp, &nr_dirty,
>> +?????????????????????????????????????????????? &nr_writable);
>> ????????????????? /*
>> ?????????????????? * If this page may have been pinned by the parent process,
>> ?????????????????? * copy the page immediately for the child so that we'll always
>> ?????????????????? * guarantee the pinned page won't be randomly replaced in the
>> ?????????????????? * future.
>> ?????????????????? */
>> -?????????????? folio_get(folio);
>> -?????????????? if (unlikely(folio_try_dup_anon_rmap_pte(folio, page,
>> src_vma))) {
>> +?????????????? folio_ref_add(folio, nr);
>> +?????????????? if (unlikely(folio_try_dup_anon_rmap_ptes(folio, page, nr,
>> src_vma))) {
>> ????????????????????????? /* Page may be pinned, we have to copy. */
>> -?????????????????????? folio_put(folio);
>> -?????????????????????? return copy_present_page(dst_vma, src_vma, dst_pte,
>> src_pte,
>> -??????????????????????????????????????????????? addr, rss, prealloc, page);
>> +?????????????????????? folio_ref_sub(folio, nr);
>> +?????????????????????? ret = copy_present_page(dst_vma, src_vma, dst_pte,
>> +?????????????????????????????????????????????? src_pte, addr, rss, prealloc,
>> +?????????????????????????????????????????????? page);
>> +?????????????????????? return ret == 0 ? 1 : ret;
>> ????????????????? }
>> -?????????????? rss[MM_ANONPAGES]++;
>> +?????????????? rss[MM_ANONPAGES] += nr;
>> ????????? } else if (page) {
>> -?????????????? folio_get(folio);
>> -?????????????? folio_dup_file_rmap_pte(folio, page);
>> -?????????????? rss[mm_counter_file(page)]++;
>> +?????????????? nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
>> +?????????????????????????????????????????????? pte, enforce_uffd_wp, &nr_dirty,
>> +?????????????????????????????????????????????? &nr_writable);
>> +?????????????? folio_ref_add(folio, nr);
>> +?????????????? folio_dup_file_rmap_ptes(folio, page, nr);
>> +?????????????? rss[mm_counter_file(page)] += nr;
>> ????????? }
>>
>>
>> We'll have to test performance, but it could be that we want to specialize
>> more on !folio_test_large(). That code is very performance-sensitive.
>>
>>
>> [1] https://lkml.kernel.org/r/20231204142146.91437-1-david at redhat.com
> 
> So, on top of [1] without rmap batching but with a slightly modified version of

Can you clarify what you mean by "without rmap batching"? I thought [1]
implicitly adds rmap batching? (e.g. folio_dup_file_rmap_ptes(), which you've
added in the code snippet above).

> yours (that keeps the existing code structure as pointed out and e.g., updates
> counter updates), running my fork() microbenchmark with a 1 GiB of memory:
> 
> Compared to [1], with all order-0 pages it gets 13--14% _slower_ and with all
> PTE-mapped THP (order-9) it gets ~29--30% _faster_.

What test are you running - I'd like to reproduce if possible, since it sounds
like I've got some work to do to remove the order-0 regression.

> 
> So looks like we really want to have a completely seprate code path for
> "!folio_test_large()" to keep that case as fast as possible. And "Likely" we
> want to use "likely(!folio_test_large()". ;)

Yuk, but fair enough. If I can repro the perf numbers, I'll have a go a
reworking this.

I think you're also implicitly suggesting that this change needs to depend on
[1]? Which is a shame...

I guess I should also go through a similar exercise for patch 2 in this series.

> 
> Performing rmap batching on top of that code only slightly (another 1% or so)
> improves performance in the PTE-mapped THP (order-9) case right now, in contrast
> to other rmap batching. Reason is as all rmap code gets inlined here and we're
> only doing subpage mapcount updates + PAE handling.
> 



From peter.griffin at linaro.org  Tue Dec  5 03:34:18 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Tue, 5 Dec 2023 11:34:18 +0000
Subject: [PATCH v5 13/20] pinctrl: samsung: Add filter selection support
 for alive banks
In-Reply-To: <CAPLW+4nJCabQhyGrTKZhKG40Z9ysRq7Zms413JrhZKzeYzad5w@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-14-peter.griffin@linaro.org> <CAPLW+4nJCabQhyGrTKZhKG40Z9ysRq7Zms413JrhZKzeYzad5w@mail.gmail.com>
Message-ID: <CADrjBPrq_CTzZsP+5cqpNkkyVYHu9Yey0AF+m4VxcSEz+Z+wrQ@mail.gmail.com>

Hi Sam,

Thanks for your review.

On Sat, 2 Dec 2023 at 00:22, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > Newer Exynos SoCs have a filter selection register on alive bank pins.
> > This allows the selection of a digital or delay filter for each pin. If
> > the filter selection register is not available then the default filter
> > (digital) is applied.
> >
> > On suspend we apply the analog filter to all pins in the bank (as the
> > digital filter relies on a clock). On resume the digital filter is
> > reapplied to all pins in the bank. The digital filter is working via
> > clock and has an adjustable filter delay register bitfield, whereas
> > the analog filter uses a fixed delay.
> >
> > The filter determines to what extent signal fluctuations received through
> > the pad are considered glitches.
> >
> > The code path can be exercised using
> > echo mem > /sys/power/state
> > And then wake the device using a eint gpio
>
> Period.

Will fix

>
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  drivers/pinctrl/samsung/pinctrl-exynos.c  | 89 ++++++++++++++++++++++-
> >  drivers/pinctrl/samsung/pinctrl-exynos.h  |  7 ++
> >  drivers/pinctrl/samsung/pinctrl-samsung.c |  2 +
> >  drivers/pinctrl/samsung/pinctrl-samsung.h | 22 ++++++
> >  4 files changed, 119 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > index 6b58ec84e34b..56fc11a1fe2f 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > @@ -269,6 +269,71 @@ struct exynos_eint_gpio_save {
> >         u32 eint_mask;
> >  };
> >
> > +/*
> > + * Set the desired filter (digital or analog delay) to every pin in
> > + * the bank. Note the filter selection bitfield is only found on alive
> > + * banks. The filter determines to what extent signal fluctuations
> > + * received through the pad are considered glitches.
> > + */
> > +static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
> > +                                  struct samsung_pin_bank *bank, int filter)
> > +{
> > +       unsigned int flt_reg, flt_con = 0;
> > +       unsigned int val, shift;
> > +       int i;
> > +       int loop_cnt;
> > +
> > +       /*
> > +        * The FLTCON register has the following layout
> > +        *
> > +        * BitfieldName[PinNum][Bit:Bit]
> > +        * FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
> > +        * FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
> > +        * FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
> > +        * FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
> > +        *
> > +        * FLT_EN       0x0 = Disable, 0x1=Enable
> > +        * FLT_SEL      0x0 = Delay filter, 0x1 Digital filter
> > +        * FLT_WIDTH    Filtering width. Valid when FLT_SEL is 0x1
> > +        */
> > +
> > +       flt_con |= EXYNOS9_FLTCON_EN;
> > +
> > +       if (filter)
> > +               flt_con |= EXYNOS9_FLTCON_DIGITAL;
> > +
> > +       flt_reg = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
> > +
> > +       /*
> > +        * If nr_pins > 4, we should set FLTCON0 register fully.
> > +        * (pin0 ~ 3). So loop 4 times in case of FLTCON0.
> > +        */
> > +       if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN)
> > +               loop_cnt = EXYNOS9_FLTCON_NR_PIN;
> > +       else
> > +               loop_cnt = bank->nr_pins;
> > +
> > +       val = readl(d->virt_base + flt_reg);
> > +       for (i = 0; i < loop_cnt; i++) {
> > +               shift = i * EXYNOS9_FLTCON_LEN;
> > +               val &= ~(EXYNOS9_FLTCON_MASK << shift);
> > +               val |= (flt_con << shift);
> > +       }
> > +       writel(val, d->virt_base + flt_reg);
> > +
> > +       /* Loop for FLTCON1 pin 4 ~ 7 */
> > +       if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN) {
> > +               loop_cnt = (bank->nr_pins - EXYNOS9_FLTCON_NR_PIN);
> > +               val = readl(d->virt_base + flt_reg + 0x4);
> > +               for (i = 0; i < loop_cnt; i++) {
> > +                       shift = i * EXYNOS9_FLTCON_LEN;
> > +                       val &= ~(EXYNOS9_FLTCON_MASK << shift);
> > +                       val |= (flt_con << shift);
> > +               }
> > +               writel(val, d->virt_base + flt_reg + 0x4);
> > +       }
> > +}
> > +
>
> This whole function needs a refactoring. Do you think below code looks better?

Yes it does!
>
> 8<----------------------------------------------------------------->8
> static void exynos_eint_update_flt_reg(void __iomem *reg, int cnt, int con)
> {
>     unsigned int val, shift;
>     int i;
>
>     val = readl(reg);
>     for (i = 0; i < cnt; i++) {
>         shift = i * EXYNOS9_FLTCON_LEN;
>         val &= ~(EXYNOS9_FLTCON_MASK << shift);
>         val |= con << shift;
>     }
>     writel(val, reg);
> }
>
> /*
>  * Set the desired filter (digital or analog delay) to every pin in the bank.
>  * Note the filter selection bitfield is only found on alive banks. The filter
>  * determines to what extent signal fluctuations received through the pad are
>  * considered glitches.
>  *
>  * The FLTCON register has the following layout:
>  *
>  *     BitfieldName[PinNum][Bit:Bit]
>  *     FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
>  *     FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
>  *     FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
>  *     FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
>  *
>  * FLT_EN    0x0 = Disable, 0x1 = Enable
>  * FLT_SEL    0x0 = Delay filter, 0x1 = Digital filter
>  * FLT_WIDTH    Filtering width. Valid when FLT_SEL is 0x1
>  */
> static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
>                    struct samsung_pin_bank *bank, int filter)
> {
>     unsigned int off = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
>     unsigned int con = EXYNOS9_FLTCON_EN | filter;
>     void __iomem *reg = d->virt_base + off;
>     u8 n = bank->nr_pins;
>
>     if (bank->fltcon_type == FLT_DEFAULT)
>         return;
>
>     /*
>      * If nr_pins > 4, we should set FLTCON0 register fully (pin0~3).
>      * So loop 4 times in case of FLTCON0. Loop for FLTCON1 pin4~7.
>      */
>     if (n <= 4) {
>         exynos_eint_update_flt_reg(reg, n, con);
>     } else {
>         exynos_eint_update_flt_reg(reg, 4, con);
>         exynos_eint_update_flt_reg(reg + 0x4, n - 4, con);
>     }
> }
> 8<----------------------------------------------------------------->8
>
> (the code is only to illustrate the idea, I never tested it).

I can refactor it along those lines.

>
> >  /*
> >   * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
> >   * @d: driver data of samsung pinctrl driver.
> > @@ -321,6 +386,10 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
> >                         goto err_domains;
> >                 }
> >
> > +               /* Set Delay Analog Filter */
>
> The code below looks quite self-explanatory to. Maybe remove all
> comments like this? If you don't think exynos_eint_flt_config() is
> clear, maybe rename it to exynos_eint_set_filter().

Ok, I will update the function name to exynos_eint_set_filter() and
remove the comments.

>
> > +               if (bank->fltcon_type != FLT_DEFAULT)
> > +                       exynos_eint_flt_config(d, bank,
> > +                                              EXYNOS9_FLTCON_DELAY);
>
> It fits the previous line just fine, no need to break the line.
>
> Also, if you use the refactored version of exynos_eint_flt_config() I
> mentioned above, you can drop all 'if' conditions like this.

Will fix

>
> >         }
> >
> >         return 0;
> > @@ -555,6 +624,11 @@ __init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
> >                 if (bank->eint_type != EINT_TYPE_WKUP)
> >                         continue;
> >
> > +               /* Set Digital Filter */
> > +               if (bank->fltcon_type != FLT_DEFAULT)
> > +                       exynos_eint_flt_config(d, bank,
> > +                                              EXYNOS9_FLTCON_DIGITAL);
>
> Ditto: no need to break the line, remove the comment. If you use the
> refactored function, you can drop 'if'.

will fix

>
> > +
> >                 bank->irq_chip = devm_kmemdup(dev, irq_chip, sizeof(*irq_chip),
> >                                               GFP_KERNEL);
> >                 if (!bank->irq_chip) {
> > @@ -658,6 +732,7 @@ static void exynos_pinctrl_suspend_bank(
> >  void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
> >  {
> >         struct samsung_pin_bank *bank = drvdata->pin_banks;
> > +       struct samsung_pinctrl_drv_data *d = bank->drvdata;
> >         struct exynos_irq_chip *irq_chip = NULL;
> >         int i;
> >
> > @@ -665,6 +740,10 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
> >                 if (bank->eint_type == EINT_TYPE_GPIO)
> >                         exynos_pinctrl_suspend_bank(drvdata, bank);
> >                 else if (bank->eint_type == EINT_TYPE_WKUP) {
> > +                       /* Setting Delay (Analog) Filter */
> > +                       if (bank->fltcon_type != FLT_DEFAULT)
> > +                               exynos_eint_flt_config(d, bank,
> > +                                                      EXYNOS9_FLTCON_DELAY);
>
> Ditto: no need to break the line, remove the comment. If you use the
> refactored function, you can drop 'if'.

Will fix
>
> >                         if (!irq_chip) {
> >                                 irq_chip = bank->irq_chip;
> >                                 irq_chip->set_eint_wakeup_mask(drvdata,
> > @@ -707,11 +786,19 @@ static void exynos_pinctrl_resume_bank(
> >  void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
> >  {
> >         struct samsung_pin_bank *bank = drvdata->pin_banks;
> > +       struct samsung_pinctrl_drv_data *d = bank->drvdata;
> >         int i;
> >
> >         for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
> > -               if (bank->eint_type == EINT_TYPE_GPIO)
> > +               if (bank->eint_type == EINT_TYPE_GPIO) {
> >                         exynos_pinctrl_resume_bank(drvdata, bank);
> > +               } else if (bank->eint_type == EINT_TYPE_WKUP ||
> > +                          bank->eint_type == EINT_TYPE_WKUP_MUX) {
> > +                       /* Set Digital Filter */
> > +                       if (bank->fltcon_type != FLT_DEFAULT)
> > +                               exynos_eint_flt_config(d, bank,
> > +                                                      EXYNOS9_FLTCON_DIGITAL);
>
> Ditto: remove the comment, and if you use the refactored function, you
> can drop 'if'; also there will be no need to break the line.

Will fix
>
> > +               }
> >  }
> >
> >  static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
> > index 3ac52c2cf998..e2799ff1b5e9 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
> > @@ -50,6 +50,13 @@
> >
> >  #define EXYNOS_EINT_MAX_PER_BANK       8
> >  #define EXYNOS_EINT_NR_WKUP_EINT
>
> Maybe add an empty line here?

Will fix
>
> > +/* EINT filter configuration */
> > +#define EXYNOS9_FLTCON_EN              BIT(7)
> > +#define EXYNOS9_FLTCON_DIGITAL         BIT(6)
> > +#define EXYNOS9_FLTCON_DELAY           (0 << 6)
> > +#define EXYNOS9_FLTCON_MASK            0xff
> > +#define EXYNOS9_FLTCON_LEN             8
> > +#define EXYNOS9_FLTCON_NR_PIN          4
>
> I'd say drop this one and just hard-code it where needed?

Ok, will drop.

>
> >
> >  #define EXYNOS_PIN_BANK_EINTN(pins, reg, id)           \
> >         {                                               \
> > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > index 79babbb39ced..50c360b4753a 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > @@ -1105,6 +1105,8 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
> >                 bank->eint_func = bdata->eint_func;
> >                 bank->eint_type = bdata->eint_type;
> >                 bank->eint_mask = bdata->eint_mask;
> > +               bank->fltcon_type = bdata->fltcon_type;
> > +               bank->fltcon_offset = bdata->fltcon_offset;
> >                 bank->eint_offset = bdata->eint_offset;
> >                 bank->name = bdata->name;
> >
> > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> > index 9b3db50adef3..5fab3885a7d7 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> > @@ -82,6 +82,20 @@ enum eint_type {
> >         EINT_TYPE_WKUP_MUX,
> >  };
> >
> > +/**
> > + * enum fltcon_type - filter selection
> > + * @FLT_DEFAULT: filter not selectable, default digital filter
> > + * @FLT_SELECT: filter selectable (digital or delay)
> > + *
> > + * Some banks on newer Exynos based SoCs have a selectable filter on alive
> > + * banks of 'analog/delay' or 'digital'. If the filter selection register is
> > + * not available then the default filter is used (digital).
> > + */
> > +enum fltcon_type {
> > +       FLT_DEFAULT,
> > +       FLT_SELECTABLE,
> > +};
>
> Is there any benefit of having this enum over replacing it with just a
> bool field (e.g. 'bool flt_selectable')?

I thought it made it clearer at the callee sites which filter was
being set, but I can update to a bool if that's what you prefer.

regards,

Peter.

>
> > +
> >  /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
> >  #define PIN_NAME_LENGTH        10
> >
> > @@ -122,6 +136,8 @@ struct samsung_pin_bank_type {
> >   * @eint_type: type of the external interrupt supported by the bank.
> >   * @eint_mask: bit mask of pins which support EINT function.
> >   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> > + * @fltcon_type: whether the filter (delay/digital) is selectable
> > + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
> >   * @name: name to be prefixed for each pin in this pin bank.
> >   */
> >  struct samsung_pin_bank_data {
> > @@ -133,6 +149,8 @@ struct samsung_pin_bank_data {
> >         enum eint_type  eint_type;
> >         u32             eint_mask;
> >         u32             eint_offset;
> > +       enum fltcon_type fltcon_type;
> > +       u32             fltcon_offset;
> >         const char      *name;
> >  };
> >
> > @@ -147,6 +165,8 @@ struct samsung_pin_bank_data {
> >   * @eint_type: type of the external interrupt supported by the bank.
> >   * @eint_mask: bit mask of pins which support EINT function.
> >   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> > + * @fltcon_type: whether the filter (delay/digital) is selectable
> > + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
> >   * @name: name to be prefixed for each pin in this pin bank.
> >   * @id: id of the bank, propagated to the pin range.
> >   * @pin_base: starting pin number of the bank.
> > @@ -170,6 +190,8 @@ struct samsung_pin_bank {
> >         enum eint_type  eint_type;
> >         u32             eint_mask;
> >         u32             eint_offset;
> > +       enum fltcon_type fltcon_type;
> > +       u32             fltcon_offset;
> >         const char      *name;
> >         u32             id;
> >
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >


From linyunsheng at huawei.com  Tue Dec  5 03:34:38 2023
From: linyunsheng at huawei.com (Yunsheng Lin)
Date: Tue, 5 Dec 2023 19:34:38 +0800
Subject: [PATCH net-next 0/6] remove page frag implementation in vhost_net
Message-ID: <20231205113444.63015-1-linyunsheng@huawei.com>

Currently there are three implementations for page frag:

1. mm/page_alloc.c: net stack seems to be using it in the
   rx part with 'struct page_frag_cache' and the main API
   being page_frag_alloc_align().
2. net/core/sock.c: net stack seems to be using it in the
   tx part with 'struct page_frag' and the main API being
   skb_page_frag_refill().
3. drivers/vhost/net.c: vhost seems to be using it to build
   xdp frame, and it's implementation seems to be a mix of
   the above two.

This patch tries to unfiy the page frag implementation a
little bit by unifying gfp bit for order 3 page allocation
and replacing page frag implementation in vhost.c with the
one in page_alloc.c.

After this patchset, we are not only able to unify the page
frag implementation a little, but also able to have about
0.5% performance boost testing by using the vhost_net_test
introduced in the last patch.

Before this patchset:
Performance counter stats for './vhost_net_test' (10 runs):

     305325.78 msec task-clock                       #    1.738 CPUs utilized               ( +-  0.12% )
       1048668      context-switches                 #    3.435 K/sec                       ( +-  0.00% )
            11      cpu-migrations                   #    0.036 /sec                        ( +- 17.64% )
            33      page-faults                      #    0.108 /sec                        ( +-  0.49% )
  244651819491      cycles                           #    0.801 GHz                         ( +-  0.43% )  (64)
   64714638024      stalled-cycles-frontend          #   26.45% frontend cycles idle        ( +-  2.19% )  (67)
   30774313491      stalled-cycles-backend           #   12.58% backend cycles idle         ( +-  7.68% )  (70)
  201749748680      instructions                     #    0.82  insn per cycle
                                              #    0.32  stalled cycles per insn     ( +-  0.41% )  (66.76%)
   65494787909      branches                         #  214.508 M/sec                       ( +-  0.35% )  (64)
    4284111313      branch-misses                    #    6.54% of all branches             ( +-  0.45% )  (66)

       175.699 +- 0.189 seconds time elapsed  ( +-  0.11% )


After this patchset:
Performance counter stats for './vhost_net_test' (10 runs):

     303974.38 msec task-clock                       #    1.739 CPUs utilized               ( +-  0.14% )
       1048807      context-switches                 #    3.450 K/sec                       ( +-  0.00% )
            14      cpu-migrations                   #    0.046 /sec                        ( +- 12.86% )
            33      page-faults                      #    0.109 /sec                        ( +-  0.46% )
  251289376347      cycles                           #    0.827 GHz                         ( +-  0.32% )  (60)
   67885175415      stalled-cycles-frontend          #   27.01% frontend cycles idle        ( +-  0.48% )  (63)
   27809282600      stalled-cycles-backend           #   11.07% backend cycles idle         ( +-  0.36% )  (71)
  195543234672      instructions                     #    0.78  insn per cycle
                                              #    0.35  stalled cycles per insn     ( +-  0.29% )  (69.04%)
   62423183552      branches                         #  205.357 M/sec                       ( +-  0.48% )  (67)
    4135666632      branch-misses                    #    6.63% of all branches             ( +-  0.63% )  (67)

       174.764 +- 0.214 seconds time elapsed  ( +-  0.12% )

Changelog:
V1: Fix some typo, drop RFC tag and rebase on latest net-next.

Yunsheng Lin (6):
  mm/page_alloc: modify page_frag_alloc_align() to accept align as an
    argument
  page_frag: unify gfp bit for order 3 page allocation
  mm/page_alloc: use initial zero offset for page_frag_alloc_align()
  vhost/net: remove vhost_net_page_frag_refill()
  net: introduce page_frag_cache_drain()
  tools: virtio: introduce vhost_net_test

 drivers/net/ethernet/google/gve/gve_main.c |  11 +-
 drivers/net/ethernet/mediatek/mtk_wed_wo.c |  17 +-
 drivers/nvme/host/tcp.c                    |   7 +-
 drivers/nvme/target/tcp.c                  |   4 +-
 drivers/vhost/net.c                        |  91 ++---
 include/linux/gfp.h                        |   6 +-
 include/linux/skbuff.h                     |  22 +-
 mm/page_alloc.c                            |  48 ++-
 net/core/skbuff.c                          |  14 +-
 net/core/sock.c                            |   2 +-
 tools/virtio/Makefile                      |   8 +-
 tools/virtio/vhost_net_test.c              | 441 +++++++++++++++++++++
 12 files changed, 524 insertions(+), 147 deletions(-)
 create mode 100644 tools/virtio/vhost_net_test.c

-- 
2.33.0



From linyunsheng at huawei.com  Tue Dec  5 03:34:43 2023
From: linyunsheng at huawei.com (Yunsheng Lin)
Date: Tue, 5 Dec 2023 19:34:43 +0800
Subject: [PATCH net-next 5/6] net: introduce page_frag_cache_drain()
In-Reply-To: <20231205113444.63015-1-linyunsheng@huawei.com>
References: <20231205113444.63015-1-linyunsheng@huawei.com>
Message-ID: <20231205113444.63015-6-linyunsheng@huawei.com>

When draining a page_frag_cache, most user are doing
the similar steps, so introduce an API to avoid code
duplication.

Signed-off-by: Yunsheng Lin <linyunsheng at huawei.com>
---
 drivers/net/ethernet/google/gve/gve_main.c | 11 ++---------
 drivers/net/ethernet/mediatek/mtk_wed_wo.c | 17 ++---------------
 drivers/nvme/host/tcp.c                    |  7 +------
 drivers/nvme/target/tcp.c                  |  4 +---
 drivers/vhost/net.c                        |  4 +---
 include/linux/gfp.h                        |  2 ++
 mm/page_alloc.c                            | 10 ++++++++++
 7 files changed, 19 insertions(+), 36 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 619bf63ec935..d976190b0f4d 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -1278,17 +1278,10 @@ static void gve_unreg_xdp_info(struct gve_priv *priv)
 
 static void gve_drain_page_cache(struct gve_priv *priv)
 {
-	struct page_frag_cache *nc;
 	int i;
 
-	for (i = 0; i < priv->rx_cfg.num_queues; i++) {
-		nc = &priv->rx[i].page_cache;
-		if (nc->va) {
-			__page_frag_cache_drain(virt_to_page(nc->va),
-						nc->pagecnt_bias);
-			nc->va = NULL;
-		}
-	}
+	for (i = 0; i < priv->rx_cfg.num_queues; i++)
+		page_frag_cache_drain(&priv->rx[i].page_cache);
 }
 
 static int gve_open(struct net_device *dev)
diff --git a/drivers/net/ethernet/mediatek/mtk_wed_wo.c b/drivers/net/ethernet/mediatek/mtk_wed_wo.c
index 7ffbd4fca881..df0a3ceaf59b 100644
--- a/drivers/net/ethernet/mediatek/mtk_wed_wo.c
+++ b/drivers/net/ethernet/mediatek/mtk_wed_wo.c
@@ -286,7 +286,6 @@ mtk_wed_wo_queue_free(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 static void
 mtk_wed_wo_queue_tx_clean(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 {
-	struct page *page;
 	int i;
 
 	for (i = 0; i < q->n_desc; i++) {
@@ -298,19 +297,12 @@ mtk_wed_wo_queue_tx_clean(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 		entry->buf = NULL;
 	}
 
-	if (!q->cache.va)
-		return;
-
-	page = virt_to_page(q->cache.va);
-	__page_frag_cache_drain(page, q->cache.pagecnt_bias);
-	memset(&q->cache, 0, sizeof(q->cache));
+	page_frag_cache_drain(&q->cache);
 }
 
 static void
 mtk_wed_wo_queue_rx_clean(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 {
-	struct page *page;
-
 	for (;;) {
 		void *buf = mtk_wed_wo_dequeue(wo, q, NULL, true);
 
@@ -320,12 +312,7 @@ mtk_wed_wo_queue_rx_clean(struct mtk_wed_wo *wo, struct mtk_wed_wo_queue *q)
 		skb_free_frag(buf);
 	}
 
-	if (!q->cache.va)
-		return;
-
-	page = virt_to_page(q->cache.va);
-	__page_frag_cache_drain(page, q->cache.pagecnt_bias);
-	memset(&q->cache, 0, sizeof(q->cache));
+	page_frag_cache_drain(&q->cache);
 }
 
 static void
diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index d79811cfa0ce..1c85e1398e4e 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -1344,7 +1344,6 @@ static int nvme_tcp_alloc_async_req(struct nvme_tcp_ctrl *ctrl)
 
 static void nvme_tcp_free_queue(struct nvme_ctrl *nctrl, int qid)
 {
-	struct page *page;
 	struct nvme_tcp_ctrl *ctrl = to_tcp_ctrl(nctrl);
 	struct nvme_tcp_queue *queue = &ctrl->queues[qid];
 	unsigned int noreclaim_flag;
@@ -1355,11 +1354,7 @@ static void nvme_tcp_free_queue(struct nvme_ctrl *nctrl, int qid)
 	if (queue->hdr_digest || queue->data_digest)
 		nvme_tcp_free_crypto(queue);
 
-	if (queue->pf_cache.va) {
-		page = virt_to_head_page(queue->pf_cache.va);
-		__page_frag_cache_drain(page, queue->pf_cache.pagecnt_bias);
-		queue->pf_cache.va = NULL;
-	}
+	page_frag_cache_drain(&queue->pf_cache);
 
 	noreclaim_flag = memalloc_noreclaim_save();
 	/* ->sock will be released by fput() */
diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
index 4cc27856aa8f..11237557cfc5 100644
--- a/drivers/nvme/target/tcp.c
+++ b/drivers/nvme/target/tcp.c
@@ -1576,7 +1576,6 @@ static void nvmet_tcp_free_cmd_data_in_buffers(struct nvmet_tcp_queue *queue)
 
 static void nvmet_tcp_release_queue_work(struct work_struct *w)
 {
-	struct page *page;
 	struct nvmet_tcp_queue *queue =
 		container_of(w, struct nvmet_tcp_queue, release_work);
 
@@ -1600,8 +1599,7 @@ static void nvmet_tcp_release_queue_work(struct work_struct *w)
 	if (queue->hdr_digest || queue->data_digest)
 		nvmet_tcp_free_crypto(queue);
 	ida_free(&nvmet_tcp_queue_ida, queue->idx);
-	page = virt_to_head_page(queue->pf_cache.va);
-	__page_frag_cache_drain(page, queue->pf_cache.pagecnt_bias);
+	page_frag_cache_drain(&queue->pf_cache);
 	kfree(queue);
 }
 
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 805e11d598e4..4b2fcb228a0a 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1386,9 +1386,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)
 	kfree(n->vqs[VHOST_NET_VQ_RX].rxq.queue);
 	kfree(n->vqs[VHOST_NET_VQ_TX].xdp);
 	kfree(n->dev.vqs);
-	if (n->pf_cache.va)
-		__page_frag_cache_drain(virt_to_head_page(n->pf_cache.va),
-					n->pf_cache.pagecnt_bias);
+	page_frag_cache_drain(&n->pf_cache);
 	kvfree(n);
 	return 0;
 }
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index bbd75976541e..03ba079655d3 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -316,6 +316,8 @@ extern void *page_frag_alloc_align(struct page_frag_cache *nc,
 				   unsigned int fragsz, gfp_t gfp_mask,
 				   unsigned int align);
 
+void page_frag_cache_drain(struct page_frag_cache *nc);
+
 static inline void *page_frag_alloc(struct page_frag_cache *nc,
 			     unsigned int fragsz, gfp_t gfp_mask)
 {
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 083e0c38fb62..5a0e68edcb05 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4716,6 +4716,16 @@ void __page_frag_cache_drain(struct page *page, unsigned int count)
 }
 EXPORT_SYMBOL(__page_frag_cache_drain);
 
+void page_frag_cache_drain(struct page_frag_cache *nc)
+{
+	if (!nc->va)
+		return;
+
+	__page_frag_cache_drain(virt_to_head_page(nc->va), nc->pagecnt_bias);
+	nc->va = NULL;
+}
+EXPORT_SYMBOL(page_frag_cache_drain);
+
 void *page_frag_alloc_align(struct page_frag_cache *nc,
 		      unsigned int fragsz, gfp_t gfp_mask,
 		      unsigned int align)
-- 
2.33.0



From donald.robson at imgtec.com  Tue Dec  5 03:39:31 2023
From: donald.robson at imgtec.com (Donald Robson)
Date: Tue,  5 Dec 2023 11:39:31 +0000
Subject: [PATCH v2 0/2] Enable PowerVR driver for TI AM62x
Message-ID: <cover.1701773390.git.donald.robson@imgtec.com>

These patches enable the new open source PowerVR driver for TI AM62x SoCs,
currently the only one supported.

Changes since v1:
- Added patch 1 for arm64 defconfig (requested by Nishanth Menon)

Donald Robson (1):
  arm64: defconfig: enable DRM_POWERVR

Sarah Walker (1):
  arm64: dts: ti: k3-am62-main: Add GPU device node

 arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 9 +++++++++
 arch/arm64/configs/defconfig             | 1 +
 2 files changed, 10 insertions(+)

-- 
2.25.1



From donald.robson at imgtec.com  Tue Dec  5 03:39:33 2023
From: donald.robson at imgtec.com (Donald Robson)
Date: Tue,  5 Dec 2023 11:39:33 +0000
Subject: [PATCH v2 2/2] arm64: dts: ti: k3-am62-main: Add GPU device node
In-Reply-To: <cover.1701773390.git.donald.robson@imgtec.com>
References: <cover.1701773390.git.donald.robson@imgtec.com>
Message-ID: <7088cc032374ae517191b1dadf5bb5f0440eac81.1701773390.git.donald.robson@imgtec.com>

From: Sarah Walker <sarah.walker at imgtec.com>

Add the Series AXE GPU node to the AM62 device tree.

Tested-by: Alexander Sverdlin <alexander.sverdlin at siemens.com>
Signed-off-by: Sarah Walker <sarah.walker at imgtec.com>
Signed-off-by: Donald Robson <donald.robson at imgtec.com>
---
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index e5c64c86d1d5..4338fd8ab2d7 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -965,4 +965,13 @@ mcasp2: audio-controller at 2b20000 {
 		power-domains = <&k3_pds 192 TI_SCI_PD_EXCLUSIVE>;
 		status = "disabled";
 	};
+
+	gpu: gpu at fd00000 {
+		compatible = "ti,am62-gpu", "img,img-axe";
+		reg = <0x00 0x0fd00000 0x00 0x20000>;
+		clocks = <&k3_clks 187 0>;
+		clock-names = "core";
+		interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+		power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>;
+	};
 };
-- 
2.25.1



From donald.robson at imgtec.com  Tue Dec  5 03:39:32 2023
From: donald.robson at imgtec.com (Donald Robson)
Date: Tue,  5 Dec 2023 11:39:32 +0000
Subject: [PATCH v2 1/2] arm64: defconfig: enable DRM_POWERVR
In-Reply-To: <cover.1701773390.git.donald.robson@imgtec.com>
References: <cover.1701773390.git.donald.robson@imgtec.com>
Message-ID: <2f6af3ebfe9e36c80c03de2dcc2e940dd5dc2c4b.1701773390.git.donald.robson@imgtec.com>

Enable the PowerVR DRM driver, as it's used for the GPU in platforms using the
TI AM62x SoCs, such as the TI SK-AM62 and BeaglePlay (2023).

Signed-off-by: Donald Robson <donald.robson at imgtec.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b60aa1f89343..85e55b13b114 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -885,6 +885,7 @@ CONFIG_DRM_PL111=m
 CONFIG_DRM_LIMA=m
 CONFIG_DRM_PANFROST=m
 CONFIG_DRM_TIDSS=m
+CONFIG_DRM_POWERVR=m
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_EFI=y
-- 
2.25.1



From catalin.marinas at arm.com  Tue Dec  5 03:40:47 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 5 Dec 2023 11:40:47 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <86fs0hatt3.wl-maz@kernel.org>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
Message-ID: <ZW8MP2tDt4_9ROBz@arm.com>

+ Lorenzo, he really needs to be on this thread.

On Tue, Dec 05, 2023 at 09:21:28AM +0000, Marc Zyngier wrote:
> On Tue, 05 Dec 2023 03:30:15 +0000,
> <ankita at nvidia.com> wrote:
> > From: Ankit Agrawal <ankita at nvidia.com>
> > 
> > Currently, KVM for ARM64 maps at stage 2 memory that is considered device
> > (i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting
> > overrides (as per the ARM architecture [1]) any device MMIO mapping
> > present at stage 1, resulting in a set-up whereby a guest operating
> > system cannot determine device MMIO mapping memory attributes on its
> > own but it is always overridden by the KVM stage 2 default.
[...]
> Despite the considerable increase in the commit message length, a
> number of questions are left unanswered:
> 
> - Shameer reported a regression on non-FWB systems, breaking device
>   assignment:
> 
>   https://lore.kernel.org/all/af13ed63dc9a4f26a6c958ebfa77d78a at huawei.com/

This referred to the first patch in the old series which was trying to
make the Stage 2 cacheable based on the vma attributes. That patch has
been dropped for now. It would be good if Shameer confirms this was the
problem.

> - Will had unanswered questions in another part of the thread:
> 
>   https://lore.kernel.org/all/20231013092954.GB13524 at willie-the-truck/
> 
>   Can someone please help concluding it?

Is this about reclaiming the device? I think we concluded that we can't
generalise this beyond PCIe, though not sure there was any formal
statement to that thread. The other point Will had was around stating
in the commit message why we only relax this to Normal NC. I haven't
checked the commit message yet, it needs careful reading ;).

> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index d14504821b79..1cb302457d3f 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -1071,7 +1071,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> >  	struct kvm_mmu_memory_cache cache = { .gfp_zero = __GFP_ZERO };
> >  	struct kvm_s2_mmu *mmu = &kvm->arch.mmu;
> >  	struct kvm_pgtable *pgt = mmu->pgt;
> > -	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_DEVICE |
> > +	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_NORMAL_NC |
> >  				     KVM_PGTABLE_PROT_R |
> >  				     (writable ? KVM_PGTABLE_PROT_W : 0);
> 
> Doesn't this affect the GICv2 VCPU interface, which is effectively a
> shared peripheral, now allowing a guest to affect another guest's
> interrupt distribution? If that is the case, this needs to be fixed.
> 
> In general, I don't think this should be a blanket statement, but be
> limited to devices that we presume can deal with this (i.e. PCIe, and
> not much else).

Based on other on-list and off-line discussions, I came to the same
conclusion that we can't relax this beyond PCIe. How we do this, it's up
for debate. Some ideas:

- something in the vfio-pci driver like a new VM_* flag that KVM can
  consume (hard sell for an arch-specific thing)

- changing the vfio-pci driver to allow WC and NC mappings (x86
  terminology) with additional knowledge about what it can safely map
  as NC. KVM would mimic the vma attributes (it doesn't eliminate the
  alias though, the guest can always go for Device while the VMM for
  Normal)

- some per-SoC pfn ranges that are permitted as Normal NC. Can the arch
  code figure out where these PCIe BARs are or is it only the vfio-pci
  driver? I guess we can sort something out around the PCIe but I'm not
  familiar with this subsystem. The alternative is some "safe" ranges in
  firmware tables, assuming the firmware configures the PCIe BARs
  location

-- 
Catalin


From mripard at kernel.org  Tue Dec  5 03:43:33 2023
From: mripard at kernel.org (mripard at kernel.org)
Date: Tue, 5 Dec 2023 12:43:33 +0100
Subject: [PATCH] arm64: dts: ti: k3-am62-main: Add GPU device node
In-Reply-To: <6e71745a9258ecd384261369656dd05da5ab10fa.camel@imgtec.com>
References: <20231204121522.47862-1-donald.robson@imgtec.com>
 <c20b213534667337f08b75a6c325fafec6526135.camel@siemens.com>
 <6e71745a9258ecd384261369656dd05da5ab10fa.camel@imgtec.com>
Message-ID: <jjndcpbk7g6quyusdd3yz42gjh7szkzyj4wlrs3tjl7bh6nmvn@ge5i75ywjtv7>

On Tue, Dec 05, 2023 at 11:26:04AM +0000, Donald Robson wrote:
> Hello Alexander,
> 
> On Tue, 2023-12-05 at 11:15 +0000, Sverdlin, Alexander wrote:
> > Hi Donald, Sarah et al,
> > 
> > thanks for the patch!
> > 
> > On Mon, 2023-12-04 at 12:15 +0000, Donald Robson wrote:
> > > From: Sarah Walker <sarah.walker at imgtec.com>
> > > 
> > > Add the Series AXE GPU node to the AM62 device tree.
> > > 
> > > Signed-off-by: Sarah Walker <sarah.walker at imgtec.com>
> > > Signed-off-by: Donald Robson <donald.robson at imgtec.com>
> > 
> > powervr fd00000.gpu: [drm] loaded firmware powervr/rogue_33.15.11.3_v1.fw
> > powervr fd00000.gpu: [drm] FW version v1.0 (build 6503725 OS)
> > [drm] Initialized powervr 1.0.0 20230904 for fd00000.gpu on minor 0
> > 
> > In general it allows the driver to be probed on TI AM625 EK, so
> > Tested-by: Alexander Sverdlin <alexander.sverdlin at siemens.com>
> 
> Thanks!
> 
> > 
> > But I'm not sure if you maybe want to disable it by default like
> > other HW blocks for the (potential) boards which don't have video at all.
> 
> Nor I. I guess it should still be enabled so it can be used for compute?

It's standalone and doesn't require any additional (or external)
resources that boards could just ignore.

So there's no real reason to disable it, ever.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/44990204/attachment.sig>

From a.fatoum at pengutronix.de  Tue Dec  5 03:48:35 2023
From: a.fatoum at pengutronix.de (Ahmad Fatoum)
Date: Tue, 5 Dec 2023 12:48:35 +0100
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231202035511.487946-3-sjg@chromium.org>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-3-sjg@chromium.org>
Message-ID: <92a3e3b4-6f4d-4ca4-947f-db905f328d4c@pengutronix.de>

Hello Simon,

On 02.12.23 04:54, Simon Glass wrote:
> Add a script which produces a Flat Image Tree (FIT), a single file
> containing the built kernel and associated devicetree files.
> Compression defaults to gzip which gives a good balance of size and
> performance.
> 
> The files compress from about 86MB to 24MB using this approach.
> 
> The FIT can be used by bootloaders which support it, such as U-Boot
> and Linuxboot. It permits automatic selection of the correct
> devicetree, matching the compatible string of the running board with
> the closest compatible string in the FIT. There is no need for
> filenames or other workarounds.
> 
> Add a 'make image.fit' build target for arm64, as well. Use
> FIT_COMPRESSION to select a different algorithm.
> 
> The FIT can be examined using 'dumpimage -l'.
> 
> This features requires pylibfdt (use 'pip install libfdt'). It also
> requires compression utilities for the algorithm being used. Supported
> compression options are the same as the Image.xxx files. For now there
> is no way to change the compression other than by editing the rule for
> $(obj)/image.fit
> 
> While FIT supports a ramdisk / initrd, no attempt is made to support
> this here, since it must be built separately from the Linux build.
> 
> Signed-off-by: Simon Glass <sjg at chromium.org>

kernel_noload support is now in barebox next branch and I tested this
series against it:

Tested-by: Ahmad Fatoum <a.fatoum at pengutronix.de> # barebox

> +"""Build a FIT containing a lot of devicetree files
> +
> +Usage:
> +    make_fit.py -A arm64 -n 'Linux-6.6' -O linux
> +        -f arch/arm64/boot/image.fit -k /tmp/kern/arch/arm64/boot/image.itk
> +        /tmp/kern/arch/arm64/boot/dts/ -E -c gzip
> +
> +Creates a FIT containing the supplied kernel and a directory containing the
> +devicetree files.
> +
> +Use -E to generate an external FIT (where the data is placed after the
> +FIT data structure). This allows parsing of the data without loading
> +the entire FIT.
> +
> +Use -c to compress the data, using bzip2, gzip, lz4, lzma, lzo and
> +zstd algorithms.
> +
> +The resulting FIT can be booted by bootloaders which support FIT, such
> +as U-Boot, Linuxboot, Tianocore, etc.

Feel free to add barebox to the list. Did you check whether Linuxboot and
Tianocore support kernel_noload?

> +        fsw.property_u32('load', 0)
> +        fsw.property_u32('entry', 0)

I still think load and entry dummy values are confusing and should be dropped.

> +    with fsw.add_node(f'fdt-{seq}'):
> +        # Get the compatible / model information
> +        with open(fname, 'rb') as inf:
> +            data = inf.read()
> +        fdt = libfdt.FdtRo(data)
> +        model = fdt.getprop(0, 'model').as_str()
> +        compat = fdt.getprop(0, 'compatible')
> +
> +        fsw.property_string('description', model)
> +        fsw.property_string('type', 'flat_dt')
> +        fsw.property_string('arch', arch)
> +        fsw.property_string('compression', compress)
> +        fsw.property('compatible', bytes(compat))
> +
> +        with open(fname, 'rb') as inf:
> +            compressed = compress_data(inf, compress)
> +        fsw.property('data', compressed)
> +    return model, compat

After Doug's elaboration, extracting multiple compatibles is fine by me.

Cheers,
Ahmad

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



From catalin.marinas at arm.com  Tue Dec  5 03:48:57 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 5 Dec 2023 11:48:57 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231205033015.10044-1-ankita@nvidia.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
Message-ID: <ZW8OKZHpXeVjoNo6@arm.com>

On Tue, Dec 05, 2023 at 09:00:15AM +0530, ankita at nvidia.com wrote:
> From: Ankit Agrawal <ankita at nvidia.com>
> 
> Currently, KVM for ARM64 maps at stage 2 memory that is considered device
> (i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting
> overrides (as per the ARM architecture [1]) any device MMIO mapping
> present at stage 1, resulting in a set-up whereby a guest operating
> system cannot determine device MMIO mapping memory attributes on its
> own but it is always overridden by the KVM stage 2 default.
> 
> This set-up does not allow guest operating systems to select device
> memory attributes independently from KVM stage-2 mappings
> (refer to [1], "Combining stage 1 and stage 2 memory type attributes"),
> which turns out to be an issue in that guest operating systems
> (e.g. Linux) may request to map devices MMIO regions with memory
> attributes that guarantee better performance (e.g. gathering
> attribute - that for some devices can generate larger PCIe memory
> writes TLPs) and specific operations (e.g. unaligned transactions)
> such as the NormalNC memory type.
> 
> The default device stage 2 mapping was chosen in KVM for ARM64 since
> it was considered safer (i.e. it would not allow guests to trigger
> uncontained failures ultimately crashing the machine) but this
> turned out to be asynchronous (SError) defeating the purpose.
> 
> Failures containability is a property of the platform and is independent
> from the memory type used for MMIO device memory mappings.
> 
> Actually, DEVICE_nGnRE memory type is even more problematic than
> Normal-NC memory type in terms of faults containability in that e.g.
> aborts triggered on DEVICE_nGnRE loads cannot be made, architecturally,
> synchronous (i.e. that would imply that the processor should issue at
> most 1 load transaction at a time - it cannot pipeline them - otherwise
> the synchronous abort semantics would break the no-speculation attribute
> attached to DEVICE_XXX memory).
> 
> This means that regardless of the combined stage1+stage2 mappings a
> platform is safe if and only if device transactions cannot trigger
> uncontained failures and that in turn relies on platform capabilities
> and the device type being assigned (i.e. PCIe AER/DPC error containment
> and RAS architecture[3]); therefore the default KVM device stage 2
> memory attributes play no role in making device assignment safer
> for a given platform (if the platform design adheres to design
> guidelines outlined in [3]) and therefore can be relaxed.
> 
> For all these reasons, relax the KVM stage 2 device memory attributes
> from DEVICE_nGnRE to Normal-NC. Add a new kvm_pgtable_prot flag for
> Normal-NC.
> 
> The Normal-NC was chosen over a different Normal memory type default
> at stage-2 (e.g. Normal Write-through) to avoid cache allocation/snooping.
> 
> Relaxing S2 KVM device MMIO mappings to Normal-NC is not expected to
> trigger any issue on guest device reclaim use cases either (i.e. device
> MMIO unmap followed by a device reset) at least for PCIe devices, in that
> in PCIe a device reset is architected and carried out through PCI config
> space transactions that are naturally ordered with respect to MMIO
> transactions according to the PCI ordering rules.
> 
> Having Normal-NC S2 default puts guests in control (thanks to
> stage1+stage2 combined memory attributes rules [1]) of device MMIO
> regions memory mappings, according to the rules described in [1]
> and summarized here ([(S1) - stage1], [(S2) - stage 2]):
> 
> S1           |  S2           | Result
> NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
> NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
> NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
> DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>
> 
> It is worth noting that currently, to map devices MMIO space to user
> space in a device pass-through use case the VFIO framework applies memory
> attributes derived from pgprot_noncached() settings applied to VMAs, which
> result in device-nGnRnE memory attributes for the stage-1 VMM mappings.
> 
> This means that a userspace mapping for device MMIO space carried
> out with the current VFIO framework and a guest OS mapping for the same
> MMIO space may result in a mismatched alias as described in [2].
> 
> Defaulting KVM device stage-2 mappings to Normal-NC attributes does not
> change anything in this respect, in that the mismatched aliases would
> only affect (refer to [2] for a detailed explanation) ordering between
> the userspace and GuestOS mappings resulting stream of transactions
> (i.e. it does not cause loss of property for either stream of
> transactions on its own), which is harmless given that the userspace
> and GuestOS access to the device is carried out through independent
> transactions streams.
> 
> [1] section D8.5 - DDI0487_I_a_a-profile_architecture_reference_manual.pdf
> [2] section B2.8 - DDI0487_I_a_a-profile_architecture_reference_manual.pdf
> [3] sections 1.7.7.3/1.8.5.2/appendix C - DEN0029H_SBSA_7.1.pdf
> 
> Applied over next-20231201
> 
> History
> =======
> v1 -> v2
> - Updated commit log to the one posted by
>   Lorenzo Pieralisi <lpieralisi at kernel.org> (Thanks!)
> - Added new flag to represent the NORMAL_NC setting. Updated
>   stage2_set_prot_attr() to handle new flag.
> 
> v1 Link:
> https://lore.kernel.org/all/20230907181459.18145-3-ankita at nvidia.com/
> 
> Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
> Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>

In the light of having to keep this relaxation only for PCIe devices, I
will withdraw my Ack until we come to a conclusion.

Thanks.

-- 
Catalin


From tabba at google.com  Tue Dec  5 03:48:35 2023
From: tabba at google.com (Fuad Tabba)
Date: Tue, 5 Dec 2023 11:48:35 +0000
Subject: [PATCH v1 1/6] KVM: arm64: Update and fix FGT register masks
In-Reply-To: <86edg0c2w1.wl-maz@kernel.org>
References: <20231205102248.1915895-1-tabba@google.com> <20231205102248.1915895-2-tabba@google.com>
 <86edg0c2w1.wl-maz@kernel.org>
Message-ID: <CA+EHjTwEkmRCRJsBkwv9nYzcfBPdAApXoFQBVViM3uF2FbsEig@mail.gmail.com>

Hi Marc,

On Tue, Dec 5, 2023 at 11:20?AM Marc Zyngier <maz at kernel.org> wrote:
>
> On Tue, 05 Dec 2023 10:22:43 +0000,
> Fuad Tabba <tabba at google.com> wrote:
> >
> > New trap bits have been defined in the latest Arm Architecture
> > System Registers xml specification [*]. Moreover, the existing
> > definitions of some of the mask and the res0 bits overlap, which
>
> nit: s/res0/RES0/

Ack

> > could be wrong, confusing, or potentially both.
> >
> > Update the bits to represent the latest spec (as of this patch),
> > and ensure that the existing bits are consistent.
> >
> > [*] https://developer.arm.com/downloads/-/exploration-tools
>
> Please indicate which version of the XML you are referring to (it
> changes on average every 3 months).

Ack

> >
> > Fixes: 0fd76865006d ("KVM: arm64: Add nPIR{E0}_EL1 to HFG traps")
> > Signed-off-by: Fuad Tabba <tabba at google.com>
> > ---
> >  arch/arm64/include/asm/kvm_arm.h | 39 ++++++++++++++++++++------------
> >  1 file changed, 24 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> > index b85f46a73e21..b1061647e837 100644
> > --- a/arch/arm64/include/asm/kvm_arm.h
> > +++ b/arch/arm64/include/asm/kvm_arm.h
> > @@ -344,36 +344,45 @@
> >   * Once we get to a point where the two describe the same thing, we'll
> >   * merge the definitions. One day.
> >   */
> > -#define __HFGRTR_EL2_RES0    (GENMASK(63, 56) | GENMASK(53, 51))
> > +#define __HFGRTR_EL2_RES0    BIT(51)
>
> If we are now using the current architectural definition for RES0, can
> we please move over to the generated values, as indicated in the above
> comment?

I'd missed the generated definitions. I thought that the comment was
referring to the read and write version of the registers. Will fix
that.

> >  #define __HFGRTR_EL2_MASK    GENMASK(49, 0)
> > -#define __HFGRTR_EL2_nMASK   (GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> > +#define __HFGRTR_EL2_nMASK   (GENMASK(63, 52) | BIT(50))
> >
> > -#define __HFGWTR_EL2_RES0    (GENMASK(63, 56) | GENMASK(53, 51) |    \
> > -                              BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
> > -                              GENMASK(26, 25) | BIT(21) | BIT(18) |  \
> > +#define __HFGWTR_EL2_RES0    (BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
> > +                              BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
> >                                GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
> > -#define __HFGWTR_EL2_MASK    GENMASK(49, 0)
> > -#define __HFGWTR_EL2_nMASK   (GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> > +#define __HFGWTR_EL2_MASK    (GENMASK(49, 47) | GENMASK(45, 43) | \
> > +                              BIT(41) | GENMASK(39, 29) | BIT(27) | \
> > +                              GENMASK(24, 22) | GENMASK(20, 19) | \
> > +                              GENMASK(17, 16) | GENMASK(13, 11) | \
> > +                              GENMASK(8, 3) | GENMASK(1, 0))
> > +#define __HFGWTR_EL2_nMASK   (GENMASK(63, 52) | BIT(50))
> >
> > -#define __HFGITR_EL2_RES0    GENMASK(63, 57)
> > -#define __HFGITR_EL2_MASK    GENMASK(54, 0)
> > -#define __HFGITR_EL2_nMASK   GENMASK(56, 55)
> > +#define __HFGITR_EL2_RES0    (BIT(63) | BIT(61))
> > +#define __HFGITR_EL2_MASK    (BIT(62) | BIT(60) | GENMASK(54, 0))
> > +#define __HFGITR_EL2_nMASK   GENMASK(59, 55)
> >
> >  #define __HDFGRTR_EL2_RES0   (BIT(49) | BIT(42) | GENMASK(39, 38) |  \
> >                                GENMASK(21, 20) | BIT(8))
> > -#define __HDFGRTR_EL2_MASK   ~__HDFGRTR_EL2_nMASK
> > +#define __HDFGRTR_EL2_MASK   (BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
> > +                              GENMASK(41, 40) | GENMASK(37, 22) | \
> > +                              GENMASK(19, 9) | GENMASK(7, 0))
> >  #define __HDFGRTR_EL2_nMASK  GENMASK(62, 59)
> >
> >  #define __HDFGWTR_EL2_RES0   (BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
> >                                BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
> >                                BIT(22) | BIT(9) | BIT(6))
> > -#define __HDFGWTR_EL2_MASK   ~__HDFGWTR_EL2_nMASK
> > +#define __HDFGWTR_EL2_MASK   (GENMASK(57, 52) | GENMASK(50, 48) | \
> > +                              GENMASK(46, 44) | GENMASK(42, 41) | \
> > +                              GENMASK(37, 35) | GENMASK(33, 31) | \
> > +                              GENMASK(29, 23) | GENMASK(21, 10) | \
> > +                              GENMASK(8, 7) | GENMASK(5, 0))
> >  #define __HDFGWTR_EL2_nMASK  GENMASK(62, 60)
> >
> >  /* Similar definitions for HCRX_EL2 */
> > -#define __HCRX_EL2_RES0              (GENMASK(63, 16) | GENMASK(13, 12))
> > -#define __HCRX_EL2_MASK              (0)
> > -#define __HCRX_EL2_nMASK     (GENMASK(15, 14) | GENMASK(4, 0))
> > +#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
> > +#define __HCRX_EL2_MASK              (BIT(6))
> > +#define __HCRX_EL2_nMASK     (GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
> >
> >  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
> >  #define HPFAR_MASK   (~UL(0xf))
>
> The main driver for not following the latest and greatest version
> published in the architecture (including the FGT2 stuff) was to limit
> the amount of work we need to do in NV.
>
> Can you please update the FGT tables in emulated-nested.c so that we
> have a matching description of the added bits? This also overlaps with
> the work Joey is doing on POE, so there is scope for collaboration
> between you two here.

Will do.

Cheers,
/fuad

> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.


From p.zabel at pengutronix.de  Tue Dec  5 03:49:19 2023
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 05 Dec 2023 12:49:19 +0100
Subject: [PATCH v3 058/108] pwm: imx27: Make use of devm_pwmchip_alloc()
 function
In-Reply-To: <20231121134901.208535-59-u.kleine-koenig@pengutronix.de>
References: <20231121134901.208535-1-u.kleine-koenig@pengutronix.de>
	 <20231121134901.208535-59-u.kleine-koenig@pengutronix.de>
Message-ID: <95b1df79f6830eb7d886bcd7099354ad38218e31.camel@pengutronix.de>

Hi Uwe,

On Di, 2023-11-21 at 14:50 +0100, Uwe Kleine-K?nig wrote:
> This prepares the pwm-imx27 driver to further changes of the pwm core
> outlined in the commit introducing devm_pwmchip_alloc(). There is no
> intended semantical change and the driver should behave as before.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  drivers/pwm/pwm-imx27.c | 20 +++++++++++---------
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> index 5d796453519a..52ac65e40e35 100644
> --- a/drivers/pwm/pwm-imx27.c
> +++ b/drivers/pwm/pwm-imx27.c
[...]
> @@ -93,7 +92,10 @@ struct pwm_imx27_chip {
>  	unsigned int duty_cycle;
>  };
>  
> -#define to_pwm_imx27_chip(chip)	container_of(chip, struct pwm_imx27_chip, chip)
> +static inline struct pwm_imx27_chip *to_pwm_imx27_chip(struct pwm_chip *chip)
> +{
> +	return pwmchip_priv(chip);
> +}
>  
>  static int pwm_imx27_clk_prepare_enable(struct pwm_imx27_chip *imx)
>  {
> @@ -306,13 +308,15 @@ MODULE_DEVICE_TABLE(of, pwm_imx27_dt_ids);
>  
>  static int pwm_imx27_probe(struct platform_device *pdev)
>  {
> +	struct pwm_chip *chip;
>  	struct pwm_imx27_chip *imx;
>  	int ret;
>  	u32 pwmcr;
>  
> -	imx = devm_kzalloc(&pdev->dev, sizeof(*imx), GFP_KERNEL);
> -	if (imx == NULL)
> -		return -ENOMEM;
> +	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*imx));
> +	if (IS_ERR(chip))
> +		return PTR_ERR(chip);
> +	imx = pwmchip_priv(chip);

Please use to_pwm_imx27_chip() here. Otherwise,

Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>

regards
Philipp


From aford173 at gmail.com  Tue Dec  5 03:49:30 2023
From: aford173 at gmail.com (Adam Ford)
Date: Tue, 5 Dec 2023 05:49:30 -0600
Subject: [PATCH 3/4] media: rkisp1: Fix IRQ handling due to shared interrupts
In-Reply-To: <9b28dcf7-c9a0-4d68-9197-cdcdd9f0393b@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
 <20231205-rkisp-irq-fix-v1-3-f4045c74ba45@ideasonboard.com>
 <20231205082016.GA17394@pendragon.ideasonboard.com> <9b28dcf7-c9a0-4d68-9197-cdcdd9f0393b@ideasonboard.com>
Message-ID: <CAHCN7xKdCixYtFE=NrfLiLNjZrV5Xrg27fMMTrdA_7-Tg9Ujfg@mail.gmail.com>

On Tue, Dec 5, 2023 at 2:27?AM Tomi Valkeinen
<tomi.valkeinen at ideasonboard.com> wrote:
>
> On 05/12/2023 10:20, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thank you for the patch.
> >
> > On Tue, Dec 05, 2023 at 10:09:34AM +0200, Tomi Valkeinen wrote:
> >> The driver requests the interrupts as IRQF_SHARED, so the interrupt
> >> handlers can be called at any time. If such a call happens while the ISP
> >> is powered down, the SoC will hang as the driver tries to access the
> >> ISP registers.
> >
> > Is IRQF_SHARED actually needed ?
>
> I don't have any answer to that, but it seems to have always been there.
> Dropping it would simplify the code, but we can only do that if we are
> sure all the platforms the ISP is used on or will be used on won't share
> the interrupt.

I can't speak for the Rockchip, but from what I can see, the imx8mp
has multiple causes for Interrupt 74 and  75, but they all appear to
be ISP1 and ISP2 related.

adam
>
>   Tomi
>
> >> Fix this by adding a new field, 'irqs_enabled', which is used to bail
> >> out from the interrupt handler when the ISP is not operational.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> >> ---
> >>   .../media/platform/rockchip/rkisp1/rkisp1-capture.c |  3 +++
> >>   .../media/platform/rockchip/rkisp1/rkisp1-common.h  |  2 ++
> >>   drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c |  3 +++
> >>   drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 21 +++++++++++++++++++++
> >>   drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c |  3 +++
> >>   5 files changed, 32 insertions(+)
> >>
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> >> index b50b044d22af..e92067897f28 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> >> @@ -779,6 +779,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
> >>      unsigned int i;
> >>      u32 status;
> >>
> >> +    if (!rkisp1->irqs_enabled)
> >> +            return IRQ_NONE;
> >> +
> >>      status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
> >>      if (!status)
> >>              return IRQ_NONE;
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> >> index ec28907d978e..7f97fdf6e24c 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> >> @@ -465,6 +465,7 @@ struct rkisp1_debug {
> >>    * @debug:    debug params to be exposed on debugfs
> >>    * @info:     version-specific ISP information
> >>    * @irqs:          IRQ line numbers
> >> + * @irqs_enabled:  the hardware is enabled and can cause interrupts
> >>    */
> >>   struct rkisp1_device {
> >>      void __iomem *base_addr;
> >> @@ -488,6 +489,7 @@ struct rkisp1_device {
> >>      struct rkisp1_debug debug;
> >>      const struct rkisp1_info *info;
> >>      int irqs[RKISP1_NUM_IRQS];
> >> +    bool irqs_enabled;
> >>   };
> >>
> >>   /*
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> >> index 47f4353a1784..f6b54654b435 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> >> @@ -184,6 +184,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
> >>      struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
> >>      u32 val, status;
> >>
> >> +    if (!rkisp1->irqs_enabled)
> >> +            return IRQ_NONE;
> >> +
> >>      status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
> >>      if (!status)
> >>              return IRQ_NONE;
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> index 1d60f4b8bd09..fbe03f7864e3 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> @@ -306,6 +306,23 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
> >>   {
> >>      struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
> >>
> >> +    rkisp1->irqs_enabled = false;
> >> +    /* Make sure the IRQ handler will see the above */
> >> +    mb();
> >> +
> >> +    /*
> >> +     * Wait until any running IRQ handler has returned. The IRQ handler
> >> +     * may get called even after this (as it's a shared interrupt line)
> >> +     * but the 'irqs_enabled' flag will make the handler return immediately.
> >> +     */
> >> +    for (unsigned int i = 0; i < RKISP1_NUM_IRQS; ++i) {
> >> +            if (rkisp1->irqs[i] == -1)
> >> +                    continue;
> >> +
> >> +            if (i == 0 || rkisp1->irqs[i - 1] != rkisp1->irqs[i])
> >> +                    synchronize_irq(rkisp1->irqs[i]);
> >> +    }
> >> +
> >>      clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
> >>      return pinctrl_pm_select_sleep_state(dev);
> >>   }
> >> @@ -322,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
> >>      if (ret)
> >>              return ret;
> >>
> >> +    rkisp1->irqs_enabled = true;
> >> +    /* Make sure the IRQ handler will see the above */
> >> +    mb();
> >> +
> >>      return 0;
> >>   }
> >>
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> >> index dafbfd230542..d6b8786661ad 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> >> @@ -1082,6 +1082,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
> >>      struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
> >>      u32 status, isp_err;
> >>
> >> +    if (!rkisp1->irqs_enabled)
> >> +            return IRQ_NONE;
> >> +
> >>      status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
> >>      if (!status)
> >>              return IRQ_NONE;
> >
>


From maz at kernel.org  Tue Dec  5 03:53:20 2023
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 05 Dec 2023 11:53:20 +0000
Subject: [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy
In-Reply-To: <ZW8DXGQCSWO1wB2m@FVFF77S0Q05N>
References: <20231204143606.1806432-1-maz@kernel.org>
	<ZW3l6Bq7ortEGB8I@FVFF77S0Q05N>
	<86h6kxbz8u.wl-maz@kernel.org>
	<ZW8DXGQCSWO1wB2m@FVFF77S0Q05N>
Message-ID: <86cyvkc1cf.wl-maz@kernel.org>

On Tue, 05 Dec 2023 11:03:16 +0000,
Mark Rutland <mark.rutland at arm.com> wrote:
> 
> On Mon, Dec 04, 2023 at 06:26:25PM +0000, Marc Zyngier wrote:
> > How about the patch below (tested in a guest with a bunch of hacks to
> > expose different L1Ip values)?
> 
> That's roughly what I was thinking; the diff looks good, minor comments below.
> 
> [...]
> 
> >  /*
> >   * Whilst the D-side always behaves as PIPT on AArch64, aliasing is
> >   * permitted in the I-cache.
> >   */
> >  static inline int icache_is_aliasing(void)
> >  {
> > -	return test_bit(ICACHEF_ALIASING, &__icache_flags);
> > +	return !cpus_have_cap(ARM64_ICACHE_PIPT);
> >  }
> 
> It might be nicer to use alternative_has_cap_{likely,unlikely}(...) for
> consistency with other cap checks, though that won't matter for hyp code and I
> don't think the likely/unlikely part particularly matters either.

Right, this should be marginally better. I was initially worried of
the cap not being configured yet, but since we start by assuming VIPT
and only flip to PIPT once we have seen all CPUs, this stays correct
by construction.

> [...]
> 
> > diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> > index c5af75b23187..db8c96841138 100644
> > --- a/arch/arm64/tools/sysreg
> > +++ b/arch/arm64/tools/sysreg
> > @@ -2003,7 +2003,7 @@ Field	28	IDC
> >  Field	27:24	CWG
> >  Field	23:20	ERG
> >  Field	19:16	DminLine
> > -Enum	15:14	L1Ip
> > +UnsignedEnum	15:14	L1Ip
> >  	# This was named as VPIPT in the ARM but now documented as reserved
> >  	0b00	RESERVED_VPIPT
> >  	# This is named as AIVIVT in the ARM but documented as reserved
> 
> I was initially surprised by the use of UnsignedEnum, but given PIPT is 0b11, I
> can see that works. Otherwise, we can keep this as an enum and use a helper
> that checks for an exact match.

Yeah, I hesitated either way, but maybe the helper approach is
cleaner.  I'll give it a go and repost this patch.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


From aford173 at gmail.com  Tue Dec  5 03:57:48 2023
From: aford173 at gmail.com (Adam Ford)
Date: Tue, 5 Dec 2023 05:57:48 -0600
Subject: [PATCH 2/4] media: rkisp1: Fix IRQ handler return values
In-Reply-To: <20231205-rkisp-irq-fix-v1-2-f4045c74ba45@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com> <20231205-rkisp-irq-fix-v1-2-f4045c74ba45@ideasonboard.com>
Message-ID: <CAHCN7xJqw-hSD7rWfxFq5NWnF+=RrpCWR+js9358jAL0_WzVFw@mail.gmail.com>

On Tue, Dec 5, 2023 at 2:10?AM Tomi Valkeinen
<tomi.valkeinen at ideasonboard.com> wrote:
>
> The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an
> irqreturn_t value, but rkisp1_isr() ignores those values and always
> returns IRQ_HANDLED.
>
> Fix this by collecting the return values, and returning IRQ_HANDLED or
> IRQ_NONE as appropriate.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
>  drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 76f93614b4cf..1d60f4b8bd09 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -445,17 +445,27 @@ static int rkisp1_entities_register(struct rkisp1_device *rkisp1)
>
>  static irqreturn_t rkisp1_isr(int irq, void *ctx)
>  {
> +       irqreturn_t ret;
> +
>         /*
>          * Call rkisp1_capture_isr() first to handle the frame that
>          * potentially completed using the current frame_sequence number before
>          * it is potentially incremented by rkisp1_isp_isr() in the vertical
>          * sync.
>          */
> -       rkisp1_capture_isr(irq, ctx);
> -       rkisp1_isp_isr(irq, ctx);
> -       rkisp1_csi_isr(irq, ctx);
>
> -       return IRQ_HANDLED;
> +       ret = IRQ_NONE;
> +
> +       if (rkisp1_capture_isr(irq, ctx) == IRQ_HANDLED)
> +               ret = IRQ_HANDLED;
> +
> +       if (rkisp1_isp_isr(irq, ctx) == IRQ_HANDLED)
> +               ret = IRQ_HANDLED;
> +
> +       if (rkisp1_csi_isr(irq, ctx) == IRQ_HANDLED)
> +               ret = IRQ_HANDLED;
> +

It seems like we're throwing away the value of ret each time the
subsequent if statement is evaluated.  Whether or not they return
didn't matter before, and the only one that seems using the return
code is the last one.

Wouldn't it be simpler to use ret = rkisp1_capture_isr(irq, ctx), ret
= rkisp1_isp_isr(irq, ctx) and ret = rkisp1_csi_isr(irq, ctx) if we
care about the return code?

How do you expect this to return if one of the first two don't return
IRQ_HANDLED?

adam

> +       return ret;
>  }
>
>  static const char * const px30_isp_clks[] = {
>
> --
> 2.34.1
>


From rafael at kernel.org  Tue Dec  5 03:58:44 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Tue, 5 Dec 2023 12:58:44 +0100
Subject: [PATCH v3 0/5] Support _UID matching for integer types
In-Reply-To: <ZW6iyu4qF0V7wCXG@black.fi.intel.com>
References: <20231123100617.28020-1-raag.jadav@intel.com> <ZW6iyu4qF0V7wCXG@black.fi.intel.com>
Message-ID: <CAJZ5v0iCjD7hwBmFVZ7VcN=FMXhbTJ4Gvm=7X5tXBg3g0j1puA@mail.gmail.com>

On Tue, Dec 5, 2023 at 5:11?AM Raag Jadav <raag.jadav at intel.com> wrote:
>
> On Thu, Nov 23, 2023 at 03:36:12PM +0530, Raag Jadav wrote:
> > This series updates the standard ACPI helpers to support _UID matching
> > for both integer and string types, and uses them in a couple of places.
> >
> > Changes since v2:
> > - Drop __builtin functions to reduce complexity (Rafael)
> > - Update tags
> >
> > Changes since v1:
> > - Fix build errors
>
> Bump.
>
> Anything I can do to move this forward?

It is on my list of pending material, I'll get to it this week (I think).

Thanks!


From laurent.pinchart at ideasonboard.com  Tue Dec  5 04:02:10 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 5 Dec 2023 14:02:10 +0200
Subject: [PATCH 3/4] media: rkisp1: Fix IRQ handling due to shared
 interrupts
In-Reply-To: <CAHCN7xKdCixYtFE=NrfLiLNjZrV5Xrg27fMMTrdA_7-Tg9Ujfg@mail.gmail.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
 <20231205-rkisp-irq-fix-v1-3-f4045c74ba45@ideasonboard.com>
 <20231205082016.GA17394@pendragon.ideasonboard.com>
 <9b28dcf7-c9a0-4d68-9197-cdcdd9f0393b@ideasonboard.com>
 <CAHCN7xKdCixYtFE=NrfLiLNjZrV5Xrg27fMMTrdA_7-Tg9Ujfg@mail.gmail.com>
Message-ID: <20231205120210.GC17394@pendragon.ideasonboard.com>

On Tue, Dec 05, 2023 at 05:49:30AM -0600, Adam Ford wrote:
> On Tue, Dec 5, 2023 at 2:27?AM Tomi Valkeinen wrote:
> > On 05/12/2023 10:20, Laurent Pinchart wrote:
> > > On Tue, Dec 05, 2023 at 10:09:34AM +0200, Tomi Valkeinen wrote:
> > >> The driver requests the interrupts as IRQF_SHARED, so the interrupt
> > >> handlers can be called at any time. If such a call happens while the ISP
> > >> is powered down, the SoC will hang as the driver tries to access the
> > >> ISP registers.
> > >
> > > Is IRQF_SHARED actually needed ?
> >
> > I don't have any answer to that, but it seems to have always been there.
> > Dropping it would simplify the code, but we can only do that if we are
> > sure all the platforms the ISP is used on or will be used on won't share
> > the interrupt.
> 
> I can't speak for the Rockchip, but from what I can see, the imx8mp
> has multiple causes for Interrupt 74 and  75, but they all appear to
> be ISP1 and ISP2 related.

The ISP has multiple interrupt lines. In some SoCs, they're all wired to
a single line of the IRQ controller (e.g. RK3399 and i.MX8MP), while
other SoCs use separate interrupts (e.g. PX30). I have checked the PX30,
RK3399 and i.MX8MP datasheets, and the ISP interrupts are not shared
with any other peripheral. I think it's thus safe to drop IRQF_SHARED.

> > >> Fix this by adding a new field, 'irqs_enabled', which is used to bail
> > >> out from the interrupt handler when the ISP is not operational.
> > >>
> > >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> > >> ---
> > >>   .../media/platform/rockchip/rkisp1/rkisp1-capture.c |  3 +++
> > >>   .../media/platform/rockchip/rkisp1/rkisp1-common.h  |  2 ++
> > >>   drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c |  3 +++
> > >>   drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 21 +++++++++++++++++++++
> > >>   drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c |  3 +++
> > >>   5 files changed, 32 insertions(+)
> > >>
> > >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > >> index b50b044d22af..e92067897f28 100644
> > >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > >> @@ -779,6 +779,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
> > >>      unsigned int i;
> > >>      u32 status;
> > >>
> > >> +    if (!rkisp1->irqs_enabled)
> > >> +            return IRQ_NONE;
> > >> +
> > >>      status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
> > >>      if (!status)
> > >>              return IRQ_NONE;
> > >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> > >> index ec28907d978e..7f97fdf6e24c 100644
> > >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> > >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> > >> @@ -465,6 +465,7 @@ struct rkisp1_debug {
> > >>    * @debug:    debug params to be exposed on debugfs
> > >>    * @info:     version-specific ISP information
> > >>    * @irqs:          IRQ line numbers
> > >> + * @irqs_enabled:  the hardware is enabled and can cause interrupts
> > >>    */
> > >>   struct rkisp1_device {
> > >>      void __iomem *base_addr;
> > >> @@ -488,6 +489,7 @@ struct rkisp1_device {
> > >>      struct rkisp1_debug debug;
> > >>      const struct rkisp1_info *info;
> > >>      int irqs[RKISP1_NUM_IRQS];
> > >> +    bool irqs_enabled;
> > >>   };
> > >>
> > >>   /*
> > >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> > >> index 47f4353a1784..f6b54654b435 100644
> > >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> > >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> > >> @@ -184,6 +184,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
> > >>      struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
> > >>      u32 val, status;
> > >>
> > >> +    if (!rkisp1->irqs_enabled)
> > >> +            return IRQ_NONE;
> > >> +
> > >>      status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
> > >>      if (!status)
> > >>              return IRQ_NONE;
> > >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> > >> index 1d60f4b8bd09..fbe03f7864e3 100644
> > >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> > >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> > >> @@ -306,6 +306,23 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
> > >>   {
> > >>      struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
> > >>
> > >> +    rkisp1->irqs_enabled = false;
> > >> +    /* Make sure the IRQ handler will see the above */
> > >> +    mb();
> > >> +
> > >> +    /*
> > >> +     * Wait until any running IRQ handler has returned. The IRQ handler
> > >> +     * may get called even after this (as it's a shared interrupt line)
> > >> +     * but the 'irqs_enabled' flag will make the handler return immediately.
> > >> +     */
> > >> +    for (unsigned int i = 0; i < RKISP1_NUM_IRQS; ++i) {
> > >> +            if (rkisp1->irqs[i] == -1)
> > >> +                    continue;
> > >> +
> > >> +            if (i == 0 || rkisp1->irqs[i - 1] != rkisp1->irqs[i])
> > >> +                    synchronize_irq(rkisp1->irqs[i]);
> > >> +    }
> > >> +
> > >>      clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
> > >>      return pinctrl_pm_select_sleep_state(dev);
> > >>   }
> > >> @@ -322,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
> > >>      if (ret)
> > >>              return ret;
> > >>
> > >> +    rkisp1->irqs_enabled = true;
> > >> +    /* Make sure the IRQ handler will see the above */
> > >> +    mb();
> > >> +
> > >>      return 0;
> > >>   }
> > >>
> > >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> > >> index dafbfd230542..d6b8786661ad 100644
> > >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> > >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> > >> @@ -1082,6 +1082,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
> > >>      struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
> > >>      u32 status, isp_err;
> > >>
> > >> +    if (!rkisp1->irqs_enabled)
> > >> +            return IRQ_NONE;
> > >> +
> > >>      status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
> > >>      if (!status)
> > >>              return IRQ_NONE;

-- 
Regards,

Laurent Pinchart


From tomi.valkeinen at ideasonboard.com  Tue Dec  5 04:02:44 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 5 Dec 2023 14:02:44 +0200
Subject: [PATCH 2/4] media: rkisp1: Fix IRQ handler return values
In-Reply-To: <CAHCN7xJqw-hSD7rWfxFq5NWnF+=RrpCWR+js9358jAL0_WzVFw@mail.gmail.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
 <20231205-rkisp-irq-fix-v1-2-f4045c74ba45@ideasonboard.com>
 <CAHCN7xJqw-hSD7rWfxFq5NWnF+=RrpCWR+js9358jAL0_WzVFw@mail.gmail.com>
Message-ID: <b61d7adb-5b45-4366-a98c-d0de91d409c8@ideasonboard.com>

On 05/12/2023 13:57, Adam Ford wrote:
> On Tue, Dec 5, 2023 at 2:10?AM Tomi Valkeinen
> <tomi.valkeinen at ideasonboard.com> wrote:
>>
>> The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an
>> irqreturn_t value, but rkisp1_isr() ignores those values and always
>> returns IRQ_HANDLED.
>>
>> Fix this by collecting the return values, and returning IRQ_HANDLED or
>> IRQ_NONE as appropriate.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>> ---
>>   drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 18 ++++++++++++++----
>>   1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>> index 76f93614b4cf..1d60f4b8bd09 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>> @@ -445,17 +445,27 @@ static int rkisp1_entities_register(struct rkisp1_device *rkisp1)
>>
>>   static irqreturn_t rkisp1_isr(int irq, void *ctx)
>>   {
>> +       irqreturn_t ret;
>> +
>>          /*
>>           * Call rkisp1_capture_isr() first to handle the frame that
>>           * potentially completed using the current frame_sequence number before
>>           * it is potentially incremented by rkisp1_isp_isr() in the vertical
>>           * sync.
>>           */
>> -       rkisp1_capture_isr(irq, ctx);
>> -       rkisp1_isp_isr(irq, ctx);
>> -       rkisp1_csi_isr(irq, ctx);
>>
>> -       return IRQ_HANDLED;
>> +       ret = IRQ_NONE;
>> +
>> +       if (rkisp1_capture_isr(irq, ctx) == IRQ_HANDLED)
>> +               ret = IRQ_HANDLED;
>> +
>> +       if (rkisp1_isp_isr(irq, ctx) == IRQ_HANDLED)
>> +               ret = IRQ_HANDLED;
>> +
>> +       if (rkisp1_csi_isr(irq, ctx) == IRQ_HANDLED)
>> +               ret = IRQ_HANDLED;
>> +
> 
> It seems like we're throwing away the value of ret each time the
> subsequent if statement is evaluated.  Whether or not they return
> didn't matter before, and the only one that seems using the return
> code is the last one.
> 
> Wouldn't it be simpler to use ret = rkisp1_capture_isr(irq, ctx), ret
> = rkisp1_isp_isr(irq, ctx) and ret = rkisp1_csi_isr(irq, ctx) if we
> care about the return code?
> 
> How do you expect this to return if one of the first two don't return
> IRQ_HANDLED?

I'm sorry, I don't quite follow what you mean. Can you elaborate a bit?

We want the rkisp1_isr() to return IRQ_NONE if none of the sub-handlers 
handled the interrupt. Otherwise, if any of the sub-handlers return 
IRQ_HANDLED, rkisp1_isr() returns IRQ_HANDLED.

  Tomi



From david at redhat.com  Tue Dec  5 04:04:15 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 13:04:15 +0100
Subject: [PATCH v3 01/15] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <a81dc390-8b10-4ce9-b72f-57f253e77af3@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-2-ryan.roberts@arm.com>
 <a12ce4f8-feb0-4e35-8f55-9270fe5a808b@redhat.com>
 <104de2d6-ecf9-4b0c-a982-5bd8e1aea758@redhat.com>
 <5b8b9f8c-8e9b-42a5-b8b2-9b96903f3ada@redhat.com>
 <a81dc390-8b10-4ce9-b72f-57f253e77af3@arm.com>
Message-ID: <df99bb4e-f69d-4d94-baa5-2fc336df1a7b@redhat.com>

On 05.12.23 12:30, Ryan Roberts wrote:
> On 04/12/2023 17:27, David Hildenbrand wrote:
>>>
>>> With rmap batching from [1] -- rebased+changed on top of that -- we could turn
>>> that into an effective (untested):
>>>
>>>  ????????? if (page && folio_test_anon(folio)) {
>>> +?????????????? nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
>>> +?????????????????????????????????????????????? pte, enforce_uffd_wp, &nr_dirty,
>>> +?????????????????????????????????????????????? &nr_writable);
>>>  ????????????????? /*
>>>  ?????????????????? * If this page may have been pinned by the parent process,
>>>  ?????????????????? * copy the page immediately for the child so that we'll always
>>>  ?????????????????? * guarantee the pinned page won't be randomly replaced in the
>>>  ?????????????????? * future.
>>>  ?????????????????? */
>>> -?????????????? folio_get(folio);
>>> -?????????????? if (unlikely(folio_try_dup_anon_rmap_pte(folio, page,
>>> src_vma))) {
>>> +?????????????? folio_ref_add(folio, nr);
>>> +?????????????? if (unlikely(folio_try_dup_anon_rmap_ptes(folio, page, nr,
>>> src_vma))) {
>>>  ????????????????????????? /* Page may be pinned, we have to copy. */
>>> -?????????????????????? folio_put(folio);
>>> -?????????????????????? return copy_present_page(dst_vma, src_vma, dst_pte,
>>> src_pte,
>>> -??????????????????????????????????????????????? addr, rss, prealloc, page);
>>> +?????????????????????? folio_ref_sub(folio, nr);
>>> +?????????????????????? ret = copy_present_page(dst_vma, src_vma, dst_pte,
>>> +?????????????????????????????????????????????? src_pte, addr, rss, prealloc,
>>> +?????????????????????????????????????????????? page);
>>> +?????????????????????? return ret == 0 ? 1 : ret;
>>>  ????????????????? }
>>> -?????????????? rss[MM_ANONPAGES]++;
>>> +?????????????? rss[MM_ANONPAGES] += nr;
>>>  ????????? } else if (page) {
>>> -?????????????? folio_get(folio);
>>> -?????????????? folio_dup_file_rmap_pte(folio, page);
>>> -?????????????? rss[mm_counter_file(page)]++;
>>> +?????????????? nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
>>> +?????????????????????????????????????????????? pte, enforce_uffd_wp, &nr_dirty,
>>> +?????????????????????????????????????????????? &nr_writable);
>>> +?????????????? folio_ref_add(folio, nr);
>>> +?????????????? folio_dup_file_rmap_ptes(folio, page, nr);
>>> +?????????????? rss[mm_counter_file(page)] += nr;
>>>  ????????? }
>>>
>>>
>>> We'll have to test performance, but it could be that we want to specialize
>>> more on !folio_test_large(). That code is very performance-sensitive.
>>>
>>>
>>> [1] https://lkml.kernel.org/r/20231204142146.91437-1-david at redhat.com
>>
>> So, on top of [1] without rmap batching but with a slightly modified version of
> 
> Can you clarify what you mean by "without rmap batching"? I thought [1]
> implicitly adds rmap batching? (e.g. folio_dup_file_rmap_ptes(), which you've
> added in the code snippet above).

Not calling the batched variants but essentially doing what your code 
does (with some minor improvements, like updating the rss counters only 
once).

The snipped above is only linked below. I had the performance numbers 
for [1] ready, so I gave it a test on top of that.

To keep it simple, you might just benchmark w and w/o your patches.

> 
>> yours (that keeps the existing code structure as pointed out and e.g., updates
>> counter updates), running my fork() microbenchmark with a 1 GiB of memory:
>>
>> Compared to [1], with all order-0 pages it gets 13--14% _slower_ and with all
>> PTE-mapped THP (order-9) it gets ~29--30% _faster_.
> 
> What test are you running - I'd like to reproduce if possible, since it sounds
> like I've got some work to do to remove the order-0 regression.

Essentially just allocating 1 GiB of memory an measuring how long it 
takes to call fork().

order-0 benchmarks:

https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/order-0-benchmarks.c?ref_type=heads

e.g.,: $ ./order-0-benchmarks fork 100


pte-mapped-thp benchmarks:

https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/pte-mapped-thp-benchmarks.c?ref_type=heads

e.g.,: $ ./pte-mapped-thp-benchmarks fork 100


Ideally, pin to one CPU and get stable performance numbers by disabling 
SMT+turbo etc.

> 
>>
>> So looks like we really want to have a completely seprate code path for
>> "!folio_test_large()" to keep that case as fast as possible. And "Likely" we
>> want to use "likely(!folio_test_large()". ;)
> 
> Yuk, but fair enough. If I can repro the perf numbers, I'll have a go a
> reworking this.
> 
> I think you're also implicitly suggesting that this change needs to depend on
> [1]? Which is a shame...

Not necessarily. It certainly cleans up the code, but we can do that in 
any order reasonable.

> 
> I guess I should also go through a similar exercise for patch 2 in this series.


Yes. There are "unmap" and "pte-dontneed" benchmarks contained in both 
files above.

-- 
Cheers,

David / dhildenb



From laurent.pinchart at ideasonboard.com  Tue Dec  5 04:04:41 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 5 Dec 2023 14:04:41 +0200
Subject: [PATCH 2/4] media: rkisp1: Fix IRQ handler return values
In-Reply-To: <20231205-rkisp-irq-fix-v1-2-f4045c74ba45@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
 <20231205-rkisp-irq-fix-v1-2-f4045c74ba45@ideasonboard.com>
Message-ID: <20231205120441.GD17394@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Tue, Dec 05, 2023 at 10:09:33AM +0200, Tomi Valkeinen wrote:
> The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an
> irqreturn_t value, but rkisp1_isr() ignores those values and always
> returns IRQ_HANDLED.
> 
> Fix this by collecting the return values, and returning IRQ_HANDLED or
> IRQ_NONE as appropriate.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
>  drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 76f93614b4cf..1d60f4b8bd09 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -445,17 +445,27 @@ static int rkisp1_entities_register(struct rkisp1_device *rkisp1)
>  
>  static irqreturn_t rkisp1_isr(int irq, void *ctx)
>  {
> +	irqreturn_t ret;

	irqreturn_t ret = IRQ_NONE;

> +
>  	/*
>  	 * Call rkisp1_capture_isr() first to handle the frame that
>  	 * potentially completed using the current frame_sequence number before
>  	 * it is potentially incremented by rkisp1_isp_isr() in the vertical
>  	 * sync.
>  	 */
> -	rkisp1_capture_isr(irq, ctx);
> -	rkisp1_isp_isr(irq, ctx);
> -	rkisp1_csi_isr(irq, ctx);
>  
> -	return IRQ_HANDLED;
> +	ret = IRQ_NONE;

And drop this.

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> +
> +	if (rkisp1_capture_isr(irq, ctx) == IRQ_HANDLED)
> +		ret = IRQ_HANDLED;
> +
> +	if (rkisp1_isp_isr(irq, ctx) == IRQ_HANDLED)
> +		ret = IRQ_HANDLED;
> +
> +	if (rkisp1_csi_isr(irq, ctx) == IRQ_HANDLED)
> +		ret = IRQ_HANDLED;
> +
> +	return ret;
>  }
>  
>  static const char * const px30_isp_clks[] = {

-- 
Regards,

Laurent Pinchart


From laurent.pinchart at ideasonboard.com  Tue Dec  5 04:13:55 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 5 Dec 2023 14:13:55 +0200
Subject: [PATCH 4/4] media: rkisp1: Fix IRQ disable race issue
In-Reply-To: <20231205-rkisp-irq-fix-v1-4-f4045c74ba45@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
 <20231205-rkisp-irq-fix-v1-4-f4045c74ba45@ideasonboard.com>
Message-ID: <20231205121355.GE17394@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Tue, Dec 05, 2023 at 10:09:35AM +0200, Tomi Valkeinen wrote:
> In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
> interrupts and then apparently assumes that the interrupt handler won't
> be running, and proceeds in the stop procedure. This is not the case, as
> the interrupt handler can already be running, which would lead to the
> ISP being disabled while the interrupt handler handling a captured
> frame.
> 
> It is not clear to me if this problem causes a real issue, but shutting
> down the ISP while an interrupt handler is running sounds rather bad.

Agreed.

> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
>  drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c | 14 +++++++++++++-
>  drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 20 +++++++++++++++++---
>  2 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> index f6b54654b435..f0cef766fc0c 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> @@ -125,8 +125,20 @@ static void rkisp1_csi_disable(struct rkisp1_csi *csi)
>  	struct rkisp1_device *rkisp1 = csi->rkisp1;
>  	u32 val;
>  
> -	/* Mask and clear interrupts. */
> +	/* Mask MIPI interrupts. */
>  	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_IMSC, 0);
> +
> +	/* Flush posted writes */
> +	rkisp1_read(rkisp1, RKISP1_CIF_MIPI_IMSC);
> +
> +	/*
> +	 * Wait until the IRQ handler has ended. The IRQ handler may get called
> +	 * even after this, but it will return immediately as the MIPI
> +	 * interrupts have been masked.
> +	 */

This comment will need to be updated if patch 3/4 gets replaced by a
patch that drops IRQF_SHARED.

> +	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MIPI]);
> +
> +	/* Clear MIPI interrupt status */
>  	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_ICR, ~0);
>  
>  	val = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_CTRL);
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> index d6b8786661ad..a6dd497c884c 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> @@ -364,11 +364,25 @@ static void rkisp1_isp_stop(struct rkisp1_isp *isp)
>  	 * ISP(mi) stop in mi frame end -> Stop ISP(mipi) ->
>  	 * Stop ISP(isp) ->wait for ISP isp off
>  	 */
> -	/* stop and clear MI and ISP interrupts */
> -	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
> -	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
>  
> +	/* Mask MI and ISP interrupts */
> +	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
>  	rkisp1_write(rkisp1, RKISP1_CIF_MI_IMSC, 0);
> +
> +	/* Flush posted writes */
> +	rkisp1_read(rkisp1, RKISP1_CIF_MI_IMSC);
> +
> +	/*
> +	 * Wait until the IRQ handler has ended. The IRQ handler may get called
> +	 * even after this, but it will return immediately as the MI and ISP
> +	 * interrupts have been masked.
> +	 */

Same here.

> +	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_ISP]);
> +	if (rkisp1->irqs[RKISP1_IRQ_ISP] != rkisp1->irqs[RKISP1_IRQ_MI])
> +		synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MI]);

It would be nice if we could avoid the double synchronize_irq() for
platforms where RKISP1_IRQ_MIPI and RKISP1_IRQ_ISP are identical, but I
understand that would be difficult.

> +
> +	/* Clear MI and ISP interrupt status */
> +	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
>  	rkisp1_write(rkisp1, RKISP1_CIF_MI_ICR, ~0);
>  
>  	/* stop ISP */

-- 
Regards,

Laurent Pinchart


From u.kleine-koenig at pengutronix.de  Tue Dec  5 04:14:04 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 5 Dec 2023 13:14:04 +0100
Subject: [PATCH v3 058/108] pwm: imx27: Make use of devm_pwmchip_alloc()
 function
In-Reply-To: <95b1df79f6830eb7d886bcd7099354ad38218e31.camel@pengutronix.de>
References: <20231121134901.208535-1-u.kleine-koenig@pengutronix.de>
 <20231121134901.208535-59-u.kleine-koenig@pengutronix.de>
 <95b1df79f6830eb7d886bcd7099354ad38218e31.camel@pengutronix.de>
Message-ID: <20231205121404.djhpn5t3gylebfyc@pengutronix.de>

Hello Philipp,

On Tue, Dec 05, 2023 at 12:49:19PM +0100, Philipp Zabel wrote:
> On Di, 2023-11-21 at 14:50 +0100, Uwe Kleine-K?nig wrote:
> > @@ -306,13 +308,15 @@ MODULE_DEVICE_TABLE(of, pwm_imx27_dt_ids);
> >  
> >  static int pwm_imx27_probe(struct platform_device *pdev)
> >  {
> > +	struct pwm_chip *chip;
> >  	struct pwm_imx27_chip *imx;
> >  	int ret;
> >  	u32 pwmcr;
> >  
> > -	imx = devm_kzalloc(&pdev->dev, sizeof(*imx), GFP_KERNEL);
> > -	if (imx == NULL)
> > -		return -ENOMEM;
> > +	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*imx));
> > +	if (IS_ERR(chip))
> > +		return PTR_ERR(chip);
> > +	imx = pwmchip_priv(chip);
> 
> Please use to_pwm_imx27_chip() here. Otherwise,
> 
> Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>

Thanks. This is already fixed in my tree for this and a few other
drivers. Currently the patch looks as follows:

	https://git.pengutronix.de/cgit/ukl/linux/commit/?h=pwm-lifetime-tracking&id=4fa8c8a8661fa6d91de0368693d4a92907fb5359

The only other changes since this v3 is the usage of
pwmchip_get_drvdata() instead of pwmchip_priv(). Can I keep your
Reviewed-by for this new variant?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/9c516f0c/attachment.sig>

From shawnguo at kernel.org  Tue Dec  5 04:14:51 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 20:14:51 +0800
Subject: [PATCH v1] ARM: dts: imx: tqma7: add lm75a sensor (rev. 01xxx)
In-Reply-To: <20231102231130.13ca0513@pcn112>
References: <20231102231130.13ca0513@pcn112>
Message-ID: <20231205121451.GD236001@dragon>

On Thu, Nov 02, 2023 at 11:11:30PM +0100, Jo?o Rodrigues wrote:
> From: Jo?o Rodrigues <jrodrigues at ubimet.com>
> 
> TQMa7x (revision 01xxx) uses a LM75A temperature sensor.
> The two sensors use different I2C addresses, so we can set both sensors
> simultaneously.
> 
> Signed-off-by: Jo?o Rodrigues <jrodrigues at ubimet.com>

Applied, thanks!


From u.kleine-koenig at pengutronix.de  Tue Dec  5 04:26:19 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue,  5 Dec 2023 13:26:19 +0100
Subject: [PATCH 4/8] regulator: stm32-vrefbuf: Convert to platform remove callback returning void
In-Reply-To: <cover.1701778038.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701778038.git.u.kleine-koenig@pengutronix.de>
Message-ID: <2e96cf99c8d97b728d891a745e8f94ee39fbfee8.1701778038.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/regulator/stm32-vrefbuf.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/stm32-vrefbuf.c b/drivers/regulator/stm32-vrefbuf.c
index 717144cbe0f9..40855105dd33 100644
--- a/drivers/regulator/stm32-vrefbuf.c
+++ b/drivers/regulator/stm32-vrefbuf.c
@@ -233,7 +233,7 @@ static int stm32_vrefbuf_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int stm32_vrefbuf_remove(struct platform_device *pdev)
+static void stm32_vrefbuf_remove(struct platform_device *pdev)
 {
 	struct regulator_dev *rdev = platform_get_drvdata(pdev);
 	struct stm32_vrefbuf *priv = rdev_get_drvdata(rdev);
@@ -244,8 +244,6 @@ static int stm32_vrefbuf_remove(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_put_noidle(&pdev->dev);
-
-	return 0;
 };
 
 static int __maybe_unused stm32_vrefbuf_runtime_suspend(struct device *dev)
@@ -282,7 +280,7 @@ MODULE_DEVICE_TABLE(of, stm32_vrefbuf_of_match);
 
 static struct platform_driver stm32_vrefbuf_driver = {
 	.probe = stm32_vrefbuf_probe,
-	.remove = stm32_vrefbuf_remove,
+	.remove_new = stm32_vrefbuf_remove,
 	.driver = {
 		.name  = "stm32-vrefbuf",
 		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Tue Dec  5 04:26:15 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue,  5 Dec 2023 13:26:15 +0100
Subject: [PATCH 0/8] regulator: Convert to platform remove callback returning void
Message-ID: <cover.1701778038.git.u.kleine-koenig@pengutronix.de>

Hello,

this series converts all drivers below drivers/regulator to struct
platform_driver::remove_new(). See commit 5c5a7680e67b ("platform:
Provide a remove callback that returns no value") for an extended
explanation and the eventual goal.

All conversations are trivial, because all .remove() callbacks returned
zero unconditionally.

There are no interdependencies between these patches, so they could be
picked up individually. However I'd expect them to go in all together
via Mark's regulator tree.

Best regards
Uwe

Uwe Kleine-K?nig (8):
  regulator: arizona-ldo1: Convert to platform remove callback returning
    void
  regulator: bd9571mwv: Convert to platform remove callback returning
    void
  regulator: db8500-prcmu: Convert to platform remove callback returning
    void
  regulator: stm32-vrefbuf: Convert to platform remove callback
    returning void
  regulator: uniphier: Convert to platform remove callback returning
    void
  regulator: userspace-consumer: Convert to platform remove callback
    returning void
  regulator: virtual: Convert to platform remove callback returning void
  regulator: wm8350: Convert to platform remove callback returning void

 drivers/regulator/arizona-ldo1.c        | 8 +++-----
 drivers/regulator/bd9571mwv-regulator.c | 5 ++---
 drivers/regulator/db8500-prcmu.c        | 6 ++----
 drivers/regulator/stm32-vrefbuf.c       | 6 ++----
 drivers/regulator/uniphier-regulator.c  | 6 ++----
 drivers/regulator/userspace-consumer.c  | 6 ++----
 drivers/regulator/virtual.c             | 6 ++----
 drivers/regulator/wm8350-regulator.c    | 6 ++----
 8 files changed, 17 insertions(+), 32 deletions(-)


base-commit: 0f5f12ac05f36f117e793656c3f560625e927f1b
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Tue Dec  5 04:26:20 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue,  5 Dec 2023 13:26:20 +0100
Subject: [PATCH 5/8] regulator: uniphier: Convert to platform remove callback returning void
In-Reply-To: <cover.1701778038.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701778038.git.u.kleine-koenig@pengutronix.de>
Message-ID: <ced2a73a1aeca3f33d4b194e4dbe2672ad84a50a.1701778038.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/regulator/uniphier-regulator.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/uniphier-regulator.c b/drivers/regulator/uniphier-regulator.c
index 1d8304b88bd6..5f868042392f 100644
--- a/drivers/regulator/uniphier-regulator.c
+++ b/drivers/regulator/uniphier-regulator.c
@@ -115,7 +115,7 @@ static int uniphier_regulator_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int uniphier_regulator_remove(struct platform_device *pdev)
+static void uniphier_regulator_remove(struct platform_device *pdev)
 {
 	struct uniphier_regulator_priv *priv = platform_get_drvdata(pdev);
 	int i;
@@ -124,8 +124,6 @@ static int uniphier_regulator_remove(struct platform_device *pdev)
 		reset_control_assert(priv->rst[i]);
 
 	clk_bulk_disable_unprepare(priv->data->nclks, priv->clk);
-
-	return 0;
 }
 
 /* USB3 controller data */
@@ -209,7 +207,7 @@ MODULE_DEVICE_TABLE(of, uniphier_regulator_match);
 
 static struct platform_driver uniphier_regulator_driver = {
 	.probe = uniphier_regulator_probe,
-	.remove = uniphier_regulator_remove,
+	.remove_new = uniphier_regulator_remove,
 	.driver = {
 		.name  = "uniphier-regulator",
 		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
-- 
2.42.0



From shawnguo at kernel.org  Tue Dec  5 04:27:56 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 20:27:56 +0800
Subject: [PATCH v4 3/3] arm64: dts: freescale: introduce rve-gateway board
In-Reply-To: <20231103142831.2116163-4-hugo@hugovil.com>
References: <20231103142831.2116163-1-hugo@hugovil.com>
 <20231103142831.2116163-4-hugo@hugovil.com>
Message-ID: <20231205122756.GE236001@dragon>

On Fri, Nov 03, 2023 at 10:28:31AM -0400, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> 
> The RVE gateway board is based on a Variscite VAR-SOM-NANO,
> with a NXP MX8MN nano CPU.
> 
> Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> ---
>  arch/arm64/boot/dts/freescale/Makefile        |   1 +
>  .../boot/dts/freescale/imx8mn-rve-gateway.dts | 282 ++++++++++++++++++
>  2 files changed, 283 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts
> 
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 300049037eb0..c99da779ef7b 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mn-bsh-smm-s2pro.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr3l-evk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mn-rve-gateway.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-tqma8mqnl-mba8mx.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-var-som-symphony.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-venice-gw7902.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts b/arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts
> new file mode 100644
> index 000000000000..186f54fd06c6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts
> @@ -0,0 +1,282 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2023 DimOnOff
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/usb/pd.h>
> +#include "imx8mn-var-som.dtsi"
> +
> +/ {
> +	model = "RVE gateway";
> +	compatible = "rve,rve-gateway", "variscite,var-som-mx8mn", "fsl,imx8mn";
> +
> +	crystal_duart_24m: crystal-duart-24m {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <24000000>;
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> +		key-enter {
> +			label = "enter";
> +			gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_ENTER>;
> +		};
> +
> +		key-exit {
> +			label = "exit";
> +			gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_ESC>;
> +		};
> +	};
> +
> +	lcd {
> +		compatible = "hit,hd44780";
> +		display-height-chars = <2>;
> +		display-width-chars = <20>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_lcd>;
> +		data-gpios = <&gpio5  1 GPIO_ACTIVE_HIGH>,
> +			     <&gpio1  6 GPIO_ACTIVE_HIGH>,
> +			     <&gpio1 14 GPIO_ACTIVE_HIGH>,
> +			     <&gpio4 28 GPIO_ACTIVE_HIGH>,
> +			     <&gpio5 24 GPIO_ACTIVE_HIGH>,
> +			     <&gpio5  2 GPIO_ACTIVE_HIGH>,
> +			     <&gpio1 12 GPIO_ACTIVE_HIGH>,
> +			     <&gpio5 25 GPIO_ACTIVE_HIGH>;
> +		enable-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
> +		rs-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> +		rw-gpios = <&gpio4 27 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	reg_3p3v: regulator-3p3v {
> +		compatible = "regulator-fixed";
> +		regulator-name = "3P3V";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-always-on;
> +	};
> +
> +	/* Bourns PEC12R rotary encoder, 24 steps. */
> +	rotary: rotary-encoder {
> +		compatible = "rotary-encoder";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_rotary>;
> +		gpios = <&gpio1  5 GPIO_ACTIVE_LOW>, /* A */
> +			<&gpio3 21 GPIO_ACTIVE_LOW>; /* B */
> +		linux,axis = <0>; /* REL_X */
> +		rotary-encoder,encoding = "gray";
> +		rotary-encoder,relative-axis;
> +	};
> +};
> +
> +&ecspi1 {
> +	cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
> +
> +	duart1: serial at 0 {
> +		compatible = "nxp,sc16is752";
> +		reg = <0>;
> +		spi-rx-bus-width = <1>;
> +		spi-tx-bus-width = <1>;
> +		spi-max-frequency = <4000000>;
> +		clocks = <&crystal_duart_24m>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <22 IRQ_TYPE_EDGE_FALLING>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		gpio-line-names = "RADIO0", "RADIO1", "RADIO2", "RADIO3",
> +		"RADIO4", "RADIO_RESET", "TP12", "TP11";

Can we add some indent to get the line aligned with the first " above?
There are a few such lines that could be improved.

Shawn

> +		linux,rs485-enabled-at-boot-time;
> +		rs485-rts-active-low;
> +	};
> +
> +	/delete-node/ touchscreen at 0;
> +};
> +
> +&ecspi2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi2>;
> +	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
> +	/delete-property/ dmas;
> +	/delete-property/ dma-names;
> +	status = "okay";
> +
> +	duart2: serial at 0 {
> +		compatible = "nxp,sc16is752";
> +		reg = <0>;
> +		spi-rx-bus-width = <1>;
> +		spi-tx-bus-width = <1>;
> +		spi-max-frequency = <4000000>;
> +		clocks = <&crystal_duart_24m>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		gpio-line-names = "LED_B_USER", "LED_R_USER", "LED_G_USER",
> +		"GPIO_EXT3", "GPIO_EXT2", "GPIO_EXT1", "GPIO_EXT0", "TP13";
> +		linux,rs485-enabled-at-boot-time;
> +		rs485-rts-active-low;
> +	};
> +};
> +
> +/* Configure PWM pins in GPIO mode: */
> +&gpio5 {
> +	gpio-line-names = "", "", "", "PWM3", "PWM2", "PWM1";
> +};
> +
> +&gpu {
> +	status = "disabled";
> +};
> +
> +&i2c2 {
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +	status = "okay";
> +
> +	/* Carrier board EEPROM */
> +	eeprom_cb: eeprom at 56 {
> +		compatible = "atmel,24c04";
> +		reg = <0x56>;
> +		pagesize = <16>;
> +		vcc-supply = <&reg_3p3v>;
> +	};
> +
> +	lm75: sensor at 48 {
> +		compatible = "st,stlm75";
> +		reg = <0x48>;
> +		vs-supply = <&reg_3p3v>;
> +	};
> +
> +	mcp7940: rtc at 6f {
> +		compatible = "microchip,mcp7940x";
> +		reg = <0x6f>;
> +	};
> +};
> +
> +&i2c3 {
> +	codec at 1a {
> +		status = "disabled";
> +	};
> +};
> +
> +&i2c4 {
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c4>;
> +	status = "okay";
> +
> +	pcf8574_1: gpio at 38 {
> +		compatible = "nxp,pcf8574";
> +		reg = <0x38>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		gpio-line-names = "LED_B_COMM3", "LED_R_COMM3", "LED_G_COMM3",
> +		"TP14", "TP15", "LED_G_COMM4", "LED_R_COMM4", "LED_B_COMM4";
> +	};
> +
> +	pcf8574_2: gpio at 39 {
> +		compatible = "nxp,pcf8574";
> +		reg = <0x39>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		gpio-line-names = "LED_B_COMM2", "LED_G_COMM2", "LED_B_COMM1",
> +		"LED_R_COMM2", "LED_R_COMM1", "LED_G_COMM1", "TP16", "TP17";
> +	};
> +};
> +
> +/* Bluetooth */
> +&uart2 {
> +	status = "disabled";
> +};
> +
> +&usbotg1 {
> +	dr_mode = "host";
> +	disable-over-current;
> +	status = "okay";
> +};
> +
> +/* SD interface on expansion connector. */
> +&usdhc2 {
> +	vmmc-supply = <&reg_3p3v>;
> +	cd-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
> +};
> +
> +&iomuxc {
> +	pinctrl_ecspi1: ecspi1grp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK	0x13
> +			MX8MN_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI	0x13
> +			MX8MN_IOMUXC_ECSPI1_MISO_ECSPI1_MISO	0x13
> +			MX8MN_IOMUXC_ECSPI1_SS0_GPIO5_IO9	0x13 /* SS0 */
> +			MX8MN_IOMUXC_SAI5_RXD1_GPIO3_IO22	0x13 /* SC16 IRQ */
> +		>;
> +	};
> +
> +	pinctrl_ecspi2: ecspi2grp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK	0x13
> +			MX8MN_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI	0x13
> +			MX8MN_IOMUXC_ECSPI2_MISO_ECSPI2_MISO	0x13
> +			MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13	0x13 /* SS0 */
> +			MX8MN_IOMUXC_SAI5_RXC_GPIO3_IO20	0x13 /* SC16 IRQ */
> +		>;
> +	};
> +
> +	pinctrl_gpio_keys: gpiokeysgrp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1	0xc6 /* Enter */
> +			MX8MN_IOMUXC_SAI5_RXD2_GPIO3_IO23	0xc6 /* Exit */
> +		>;
> +	};
> +
> +	pinctrl_i2c2: i2c2grp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_I2C2_SCL_I2C2_SCL		0x400001c3
> +			MX8MN_IOMUXC_I2C2_SDA_I2C2_SDA		0x400001c3
> +		>;
> +	};
> +
> +	pinctrl_i2c4: i2c4grp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_I2C4_SCL_I2C4_SCL		0x400001c3
> +			MX8MN_IOMUXC_I2C4_SDA_I2C4_SDA		0x400001c3
> +		>;
> +	};
> +
> +	pinctrl_lcd: lcdgrp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_SAI3_TXD_GPIO5_IO1		0x00000156 /* D0 */
> +			MX8MN_IOMUXC_GPIO1_IO06_GPIO1_IO6	0x00000156 /* D1 */
> +			MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14	0x00000156 /* D2 */
> +			MX8MN_IOMUXC_SAI3_RXFS_GPIO4_IO28	0x00000156 /* D3 */
> +			MX8MN_IOMUXC_UART2_RXD_GPIO5_IO24	0x00000156 /* D4 */
> +			MX8MN_IOMUXC_SAI3_MCLK_GPIO5_IO2	0x00000156 /* D5 */
> +			MX8MN_IOMUXC_GPIO1_IO12_GPIO1_IO12	0x00000156 /* D6 */
> +			MX8MN_IOMUXC_UART2_TXD_GPIO5_IO25	0x00000156 /* D7 */
> +			MX8MN_IOMUXC_UART1_TXD_GPIO5_IO23	0x00000156 /* E */
> +			MX8MN_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x00000156 /* RS */
> +			MX8MN_IOMUXC_SAI2_MCLK_GPIO4_IO27	0x00000156 /* R/W */
> +		>;
> +	};
> +
> +	pinctrl_rotary: rotarygrp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_GPIO1_IO05_GPIO1_IO5	0x00000156 /* A */
> +			MX8MN_IOMUXC_SAI5_RXD0_GPIO3_IO21	0x00000156 /* B */
> +		>;
> +	};
> +
> +	/* Override Card Detect function GPIO value (GPIO1_IO10) from SOM: */
> +	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_GPIO1_IO13_GPIO1_IO13	0x41
> +		>;
> +	};
> +};
> -- 
> 2.39.2
> 


From shawnguo at kernel.org  Tue Dec  5 04:29:26 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 20:29:26 +0800
Subject: [PATCH] ARM: dts: imx6ul-pico: Describe the Ethernet PHY clock
In-Reply-To: <20231105133219.954696-1-festevam@gmail.com>
References: <20231105133219.954696-1-festevam@gmail.com>
Message-ID: <20231205122926.GF236001@dragon>

On Sun, Nov 05, 2023 at 10:32:19AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Since commit c7e73b5051d6 ("ARM: imx: mach-imx6ul: remove 14x14 EVK
> specific PHY fixup")thet Ethernet PHY is no longer configured via code
> in board file.
> 
> This caused Ethernet to stop working.
> 
> Fix this problem by describing the clocks and clock-names to the
> Ethernet PHY node so that the KSZ8081 chip can be clocked correctly.
> 
> Fixes: c7e73b5051d6 ("ARM: imx: mach-imx6ul: remove 14x14 EVK specific PHY fixup")
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 04:32:38 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 20:32:38 +0800
Subject: [PATCH v2 2/3] arm64: dts: freescale: imx8-ss-lsio: Fix
 #pwm-cells
In-Reply-To: <20231106151326.812099-3-alexander.stein@ew.tq-group.com>
References: <20231106151326.812099-1-alexander.stein@ew.tq-group.com>
 <20231106151326.812099-3-alexander.stein@ew.tq-group.com>
Message-ID: <20231205123238.GG236001@dragon>

On Mon, Nov 06, 2023 at 04:13:25PM +0100, Alexander Stein wrote:
> i.MX8QM/QXP supports inverted PWM output, thus #pwm-cells needs to be set
> to 3.
> 
> Fixes: a05c329644d81 ("arm64: dts: freescale: imx8-ss-lsio: add support for lsio_pwm0-3")
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 04:32:58 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 20:32:58 +0800
Subject: [PATCH v2 3/3] arm64: dts: freescale: imx8-ss-dma: Fix #pwm-cells
In-Reply-To: <20231106151326.812099-4-alexander.stein@ew.tq-group.com>
References: <20231106151326.812099-1-alexander.stein@ew.tq-group.com>
 <20231106151326.812099-4-alexander.stein@ew.tq-group.com>
Message-ID: <20231205123258.GH236001@dragon>

On Mon, Nov 06, 2023 at 04:13:26PM +0100, Alexander Stein wrote:
> i.MX8QXP supports inverted PWM output, thus #pwm-cells needs to be set
> to 3.
> 
> Fixes: f1d6a6b991ef9 ("arm64: dts: imx8qxp: add adma_pwm in adma")
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Applied, thanks!


From aford173 at gmail.com  Tue Dec  5 04:35:08 2023
From: aford173 at gmail.com (Adam Ford)
Date: Tue, 5 Dec 2023 06:35:08 -0600
Subject: [PATCH 2/4] media: rkisp1: Fix IRQ handler return values
In-Reply-To: <b61d7adb-5b45-4366-a98c-d0de91d409c8@ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
 <20231205-rkisp-irq-fix-v1-2-f4045c74ba45@ideasonboard.com>
 <CAHCN7xJqw-hSD7rWfxFq5NWnF+=RrpCWR+js9358jAL0_WzVFw@mail.gmail.com> <b61d7adb-5b45-4366-a98c-d0de91d409c8@ideasonboard.com>
Message-ID: <CAHCN7xJcYACscBHExh6n-kAKofrk=E2VTncm8Y_ZmWjcj_yzPA@mail.gmail.com>

On Tue, Dec 5, 2023 at 6:02?AM Tomi Valkeinen
<tomi.valkeinen at ideasonboard.com> wrote:
>
> On 05/12/2023 13:57, Adam Ford wrote:
> > On Tue, Dec 5, 2023 at 2:10?AM Tomi Valkeinen
> > <tomi.valkeinen at ideasonboard.com> wrote:
> >>
> >> The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an
> >> irqreturn_t value, but rkisp1_isr() ignores those values and always
> >> returns IRQ_HANDLED.
> >>
> >> Fix this by collecting the return values, and returning IRQ_HANDLED or
> >> IRQ_NONE as appropriate.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> >> ---
> >>   drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 18 ++++++++++++++----
> >>   1 file changed, 14 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> index 76f93614b4cf..1d60f4b8bd09 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> @@ -445,17 +445,27 @@ static int rkisp1_entities_register(struct rkisp1_device *rkisp1)
> >>
> >>   static irqreturn_t rkisp1_isr(int irq, void *ctx)
> >>   {
> >> +       irqreturn_t ret;
> >> +
> >>          /*
> >>           * Call rkisp1_capture_isr() first to handle the frame that
> >>           * potentially completed using the current frame_sequence number before
> >>           * it is potentially incremented by rkisp1_isp_isr() in the vertical
> >>           * sync.
> >>           */
> >> -       rkisp1_capture_isr(irq, ctx);
> >> -       rkisp1_isp_isr(irq, ctx);
> >> -       rkisp1_csi_isr(irq, ctx);
> >>
> >> -       return IRQ_HANDLED;
> >> +       ret = IRQ_NONE;
> >> +
> >> +       if (rkisp1_capture_isr(irq, ctx) == IRQ_HANDLED)
> >> +               ret = IRQ_HANDLED;
> >> +
> >> +       if (rkisp1_isp_isr(irq, ctx) == IRQ_HANDLED)
> >> +               ret = IRQ_HANDLED;
> >> +
> >> +       if (rkisp1_csi_isr(irq, ctx) == IRQ_HANDLED)
> >> +               ret = IRQ_HANDLED;
> >> +
> >
> > It seems like we're throwing away the value of ret each time the
> > subsequent if statement is evaluated.  Whether or not they return
> > didn't matter before, and the only one that seems using the return
> > code is the last one.
> >
> > Wouldn't it be simpler to use ret = rkisp1_capture_isr(irq, ctx), ret
> > = rkisp1_isp_isr(irq, ctx) and ret = rkisp1_csi_isr(irq, ctx) if we
> > care about the return code?
> >
> > How do you expect this to return if one of the first two don't return
> > IRQ_HANDLED?
>
> I'm sorry, I don't quite follow what you mean. Can you elaborate a bit?
>
> We want the rkisp1_isr() to return IRQ_NONE if none of the sub-handlers
> handled the interrupt. Otherwise, if any of the sub-handlers return
> IRQ_HANDLED, rkisp1_isr() returns IRQ_HANDLED.

OK.  I understand your explanation.  I retract my comment.  I'll try
to test this series tonight on my imx8mp

adam


>
>   Tomi
>


From thierry.reding at gmail.com  Tue Dec  5 04:36:05 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 5 Dec 2023 13:36:05 +0100
Subject: (subset) [PATCH 00/17] dt-bindings: samsung: add specific
 compatibles for existing SoC
In-Reply-To: <20231128205841.al23ra5s34rn3muj@pengutronix.de>
References: <20231108104343.24192-1-krzysztof.kozlowski@linaro.org>
 <170119374454.445690.515311393756577368.b4-ty@gmail.com>
 <20231128205841.al23ra5s34rn3muj@pengutronix.de>
Message-ID: <ZW8ZNZ_FJSV8fq-U@orome.fritz.box>

On Tue, Nov 28, 2023 at 09:58:41PM +0100, Uwe Kleine-K?nig wrote:
> On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
> > 
> > On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
> > > Merging
> > > =======
> > > I propose to take entire patchset through my tree (Samsung SoC), because:
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> > > 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
> > >    they will touch the same lines in some of the DT bindings (not all, though).
> > >    It is reasonable for me to take the bindings for the new SoCs, to have clean
> > >    `make dtbs_check` on the new DTS.
> > > 2. Having it together helps me to have clean `make dtbs_check` within my tree
> > >    on the existing DTS.
> > > 3. No drivers are affected by this change.
> > > 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
> > >    follow up patchsets.
> > > 
> > > [...]
> > 
> > Applied, thanks!
> > 
> > [12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
> >         commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f
> 
> You didn't honor (or even comment) Krzysztof's proposal to take the
> whole patchset via his tree (marked above). Was there some off-list
> agreement?

I had read all that and then looking at patchwork saw that you had
marked all other patches in the series as "handled-elsewhere" and only
this one was left as "new", so I assumed that, well, everything else was
handled elsewhere and I was supposed to pick this one up...

I'll drop this one.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/6db03300/attachment.sig>

From shawnguo at kernel.org  Tue Dec  5 04:36:17 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 20:36:17 +0800
Subject: [PATCH 1/3] dt-bindings: pwm: imx-pwm: Add constraints for
 #pwm-cells
In-Reply-To: <20231106095205.231210-2-alexander.stein@ew.tq-group.com>
References: <20231106095205.231210-1-alexander.stein@ew.tq-group.com>
 <20231106095205.231210-2-alexander.stein@ew.tq-group.com>
Message-ID: <20231205123617.GI236001@dragon>

On Mon, Nov 06, 2023 at 10:52:03AM +0100, Alexander Stein wrote:
> Only fsl,imx1-pwm comptabile devices use #pwm-cells = <2>. Newer SoCs
> supportinverted PWM output, thus #pwm-cells needs to be set to 3.
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

As suggested by Uwe, I picked this up too.

Shawn


From shawnguo at kernel.org  Tue Dec  5 04:37:39 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 5 Dec 2023 20:37:39 +0800
Subject: [PATCH 1/3] dt-bindings: pwm: imx-pwm: Add constraints for #pwm-cells
In-Reply-To: <20231205123617.GI236001@dragon>
References: <20231106095205.231210-1-alexander.stein@ew.tq-group.com>
 <20231106095205.231210-2-alexander.stein@ew.tq-group.com> <20231205123617.GI236001@dragon>
Message-ID: <CAJBJ56Jkc+iy4wCvY=jr3OwQ_nXdDSezkjfJaejmhWDoTDEyLQ@mail.gmail.com>

On Tue, Dec 5, 2023 at 8:36?PM Shawn Guo <shawnguo at kernel.org> wrote:
>
> On Mon, Nov 06, 2023 at 10:52:03AM +0100, Alexander Stein wrote:
> > Only fsl,imx1-pwm comptabile devices use #pwm-cells = <2>. Newer SoCs
> > supportinverted PWM output, thus #pwm-cells needs to be set to 3.
> >
> > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
>
> As suggested by Uwe, I picked this up too.

Sorry, I picked v2 up actually.

Shawn


From p.zabel at pengutronix.de  Tue Dec  5 04:50:26 2023
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 05 Dec 2023 13:50:26 +0100
Subject: [PATCH v3 058/108] pwm: imx27: Make use of devm_pwmchip_alloc()
 function
In-Reply-To: <20231205121404.djhpn5t3gylebfyc@pengutronix.de>
References: <20231121134901.208535-1-u.kleine-koenig@pengutronix.de>
	 <20231121134901.208535-59-u.kleine-koenig@pengutronix.de>
	 <95b1df79f6830eb7d886bcd7099354ad38218e31.camel@pengutronix.de>
	 <20231205121404.djhpn5t3gylebfyc@pengutronix.de>
Message-ID: <b501d70ce1bcfc7586d195f54a8fec73f9dcfcf0.camel@pengutronix.de>

On Di, 2023-12-05 at 13:14 +0100, Uwe Kleine-K?nig wrote:
> Hello Philipp,
> 
> On Tue, Dec 05, 2023 at 12:49:19PM +0100, Philipp Zabel wrote:
> > On Di, 2023-11-21 at 14:50 +0100, Uwe Kleine-K?nig wrote:
> > > @@ -306,13 +308,15 @@ MODULE_DEVICE_TABLE(of, pwm_imx27_dt_ids);
> > >  
> > >  static int pwm_imx27_probe(struct platform_device *pdev)
> > >  {
> > > +	struct pwm_chip *chip;
> > >  	struct pwm_imx27_chip *imx;
> > >  	int ret;
> > >  	u32 pwmcr;
> > >  
> > > -	imx = devm_kzalloc(&pdev->dev, sizeof(*imx), GFP_KERNEL);
> > > -	if (imx == NULL)
> > > -		return -ENOMEM;
> > > +	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*imx));
> > > +	if (IS_ERR(chip))
> > > +		return PTR_ERR(chip);
> > > +	imx = pwmchip_priv(chip);
> > 
> > Please use to_pwm_imx27_chip() here. Otherwise,
> > 
> > Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> 
> Thanks. This is already fixed in my tree for this and a few other
> drivers. Currently the patch looks as follows:
> 
> 	https://git.pengutronix.de/cgit/ukl/linux/commit/?h=pwm-lifetime-tracking&id=4fa8c8a8661fa6d91de0368693d4a92907fb5359
> 
> The only other changes since this v3 is the usage of
> pwmchip_get_drvdata() instead of pwmchip_priv(). Can I keep your
> Reviewed-by for this new variant?

Yes.

regards
Philipp


From festevam at gmail.com  Tue Dec  5 04:57:31 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue,  5 Dec 2023 09:57:31 -0300
Subject: [PATCH] ARM: dts: imx23/28: Remove unneeded "fsl,mxs-gpio"
Message-ID: <20231205125731.2008490-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

According to gpio-mxs.yaml, only "fsl,imx23-gpio" or "fsl,imx28-gpio"
are valid compatible strings.

This fixes the following dt-schema warnings:

imx23-evk.dtb: pinctrl at 80018000: gpio at 0:compatible: ['fsl,imx23-gpio', 'fsl,mxs-gpio'] is too long
	from schema $id: http://devicetree.org/schemas/gpio/gpio-mxs.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/mxs/imx23.dtsi |  6 +++---
 arch/arm/boot/dts/nxp/mxs/imx28.dtsi | 10 +++++-----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/mxs/imx23.dtsi b/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
index fdf18b7cb2f6..60bd88585bb4 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
+++ b/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
@@ -110,7 +110,7 @@ pinctrl at 80018000 {
 				reg = <0x80018000 0x2000>;
 
 				gpio0: gpio at 0 {
-					compatible = "fsl,imx23-gpio", "fsl,mxs-gpio";
+					compatible = "fsl,imx23-gpio";
 					reg = <0>;
 					interrupts = <16>;
 					gpio-controller;
@@ -120,7 +120,7 @@ gpio0: gpio at 0 {
 				};
 
 				gpio1: gpio at 1 {
-					compatible = "fsl,imx23-gpio", "fsl,mxs-gpio";
+					compatible = "fsl,imx23-gpio";
 					reg = <1>;
 					interrupts = <17>;
 					gpio-controller;
@@ -130,7 +130,7 @@ gpio1: gpio at 1 {
 				};
 
 				gpio2: gpio at 2 {
-					compatible = "fsl,imx23-gpio", "fsl,mxs-gpio";
+					compatible = "fsl,imx23-gpio";
 					reg = <2>;
 					interrupts = <18>;
 					gpio-controller;
diff --git a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
index 6932d23fb29d..409952feec2c 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
+++ b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
@@ -164,7 +164,7 @@ pinctrl: pinctrl at 80018000 {
 				reg = <0x80018000 0x2000>;
 
 				gpio0: gpio at 0 {
-					compatible = "fsl,imx28-gpio", "fsl,mxs-gpio";
+					compatible = "fsl,imx28-gpio";
 					reg = <0>;
 					interrupts = <127>;
 					gpio-controller;
@@ -174,7 +174,7 @@ gpio0: gpio at 0 {
 				};
 
 				gpio1: gpio at 1 {
-					compatible = "fsl,imx28-gpio", "fsl,mxs-gpio";
+					compatible = "fsl,imx28-gpio";
 					reg = <1>;
 					interrupts = <126>;
 					gpio-controller;
@@ -184,7 +184,7 @@ gpio1: gpio at 1 {
 				};
 
 				gpio2: gpio at 2 {
-					compatible = "fsl,imx28-gpio", "fsl,mxs-gpio";
+					compatible = "fsl,imx28-gpio";
 					reg = <2>;
 					interrupts = <125>;
 					gpio-controller;
@@ -194,7 +194,7 @@ gpio2: gpio at 2 {
 				};
 
 				gpio3: gpio at 3 {
-					compatible = "fsl,imx28-gpio", "fsl,mxs-gpio";
+					compatible = "fsl,imx28-gpio";
 					reg = <3>;
 					interrupts = <124>;
 					gpio-controller;
@@ -204,7 +204,7 @@ gpio3: gpio at 3 {
 				};
 
 				gpio4: gpio at 4 {
-					compatible = "fsl,imx28-gpio", "fsl,mxs-gpio";
+					compatible = "fsl,imx28-gpio";
 					reg = <4>;
 					interrupts = <123>;
 					gpio-controller;
-- 
2.34.1



From jgg at nvidia.com  Tue Dec  5 05:05:17 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 09:05:17 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZW8MP2tDt4_9ROBz@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
Message-ID: <20231205130517.GD2692119@nvidia.com>

On Tue, Dec 05, 2023 at 11:40:47AM +0000, Catalin Marinas wrote:
> > - Will had unanswered questions in another part of the thread:
> > 
> >   https://lore.kernel.org/all/20231013092954.GB13524 at willie-the-truck/
> > 
> >   Can someone please help concluding it?
> 
> Is this about reclaiming the device? I think we concluded that we can't
> generalise this beyond PCIe, though not sure there was any formal
> statement to that thread. The other point Will had was around stating
> in the commit message why we only relax this to Normal NC. I haven't
> checked the commit message yet, it needs careful reading ;).

Not quite, we said reclaiming is VFIO's problem and if VFIO can't
reliably reclaim a device it shouldn't create it in the first place.

Again, I think alot of this is trying to take VFIO problems into KVM.

VFIO devices should not exist if they pose a harm to the system. If
VFIO decided to create the devices anyhow (eg admin override or
something) then it is not KVM's job to do any further enforcement.

Remember, the feedback we got from the CPU architects was that even
DEVICE_* will experience an uncontained failure if the device tiggers
an error response in shipping ARM IP.

The reason PCIe is safe is because the PCI bridge does not generate
errors in the first place!

Thus, the way a platform device can actually be safe is if it too
never generates errors in the first place! Obviously this approach
works just as well with NORMAL_NC.

If a platform device does generate errors then we shouldn't expect
containment at all, and the memory type has no bearing on the
safety. The correct answer is to block these platform devices from
VFIO/KVM/etc because they can trigger uncontained failures.

If you have learned something different then please share it..

IOW, what is the practical scenario where DEVICE_* has contained
errors but NORMAL_NC does not?

Jason


From will at kernel.org  Tue Dec  5 05:14:14 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 5 Dec 2023 13:14:14 +0000
Subject: [PATCH v6 2/3] arm64: perf: Add support for event counting
 threshold
In-Reply-To: <20231124102857.1106453-3-james.clark@arm.com>
References: <20231124102857.1106453-1-james.clark@arm.com>
 <20231124102857.1106453-3-james.clark@arm.com>
Message-ID: <20231205131414.GA18119@willie-the-truck>

On Fri, Nov 24, 2023 at 10:28:56AM +0000, James Clark wrote:
> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index 1d40d794f5e4..eb1ef84e1dbb 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -15,6 +15,7 @@
>  #include <clocksource/arm_arch_timer.h>
>  
>  #include <linux/acpi.h>
> +#include <linux/bitfield.h>
>  #include <linux/clocksource.h>
>  #include <linux/of.h>
>  #include <linux/perf/arm_pmu.h>
> @@ -294,9 +295,20 @@ static const struct attribute_group armv8_pmuv3_events_attr_group = {
>  	.is_visible = armv8pmu_event_attr_is_visible,
>  };
>  
> +#define THRESHOLD_LOW		2
> +#define THRESHOLD_HIGH		13
> +#define THRESHOLD_CNT		14
> +#define THRESHOLD_CMP_LO	15
> +#define THRESHOLD_CMP_HI	16

Do you think THWIDTH might extend beyond 12 bits in future? If so, it might
be worth juggling these bits around a bit so it's not sandwiched between
'rdpmc' and 'threshold_compare'. I defer to your judgement, however.

>  PMU_FORMAT_ATTR(event, "config:0-15");
>  PMU_FORMAT_ATTR(long, "config1:0");
>  PMU_FORMAT_ATTR(rdpmc, "config1:1");
> +PMU_FORMAT_ATTR(threshold, "config1:" __stringify(THRESHOLD_LOW) "-"
> +				      __stringify(THRESHOLD_HIGH));
> +PMU_FORMAT_ATTR(threshold_compare, "config1:" __stringify(THRESHOLD_CMP_LO) "-"
> +					      __stringify(THRESHOLD_CMP_HI));
> +PMU_FORMAT_ATTR(threshold_count, "config1:" __stringify(THRESHOLD_CNT));
>  
>  static int sysctl_perf_user_access __read_mostly;
>  
> @@ -310,10 +322,33 @@ static inline bool armv8pmu_event_want_user_access(struct perf_event *event)
>  	return event->attr.config1 & 0x2;
>  }
>  
> +static inline u32 armv8pmu_event_threshold(struct perf_event_attr *attr)
> +{
> +	return FIELD_GET(GENMASK(THRESHOLD_HIGH, THRESHOLD_LOW), attr->config1);
> +}
> +
> +static inline u8 armv8pmu_event_threshold_control(struct perf_event_attr *attr)

You can drop the 'inline's for these functions (and, in fact, this whole
file could do with that cleanup :)

> +{
> +	u8 th_compare = FIELD_GET(GENMASK(THRESHOLD_CMP_HI, THRESHOLD_CMP_LO),
> +				  attr->config1);
> +	u8 th_count = FIELD_GET(BIT(THRESHOLD_CNT), attr->config1);

I think this is correct, but you might want to look at how we handle this
in the SPE driver as I think it ends up looking cleaner and makes it pretty
obvious which bits correspond to the user ABI (i.e. config fields) and which
bits are part of architectural registers. I'm not saying you have to do it
that way, but please take a look if you haven't already.

> +	/*
> +	 * The count bit is always the bottom bit of the full control field, and
> +	 * the comparison is the upper two bits, but it's not explicitly
> +	 * labelled in the Arm ARM. For the Perf interface we split it into two
> +	 * fields, so reconstruct it here.
> +	 */
> +	return (th_compare << 1) | th_count;
> +}
> +
>  static struct attribute *armv8_pmuv3_format_attrs[] = {
>  	&format_attr_event.attr,
>  	&format_attr_long.attr,
>  	&format_attr_rdpmc.attr,
> +	&format_attr_threshold.attr,
> +	&format_attr_threshold_compare.attr,
> +	&format_attr_threshold_count.attr,
>  	NULL,
>  };
>  
> @@ -365,10 +400,38 @@ static ssize_t bus_width_show(struct device *dev, struct device_attribute *attr,
>  
>  static DEVICE_ATTR_RO(bus_width);
>  
> +static u32 threshold_max(struct arm_pmu *cpu_pmu)
> +{
> +	/*
> +	 * PMMIR.THWIDTH is readable and non-zero on aarch32, but it would be
> +	 * impossible to write the threshold in the upper 32 bits of PMEVTYPER.
> +	 */
> +	if (IS_ENABLED(CONFIG_ARM))
> +		return 0;
> +
> +	/*
> +	 * The largest value that can be written to PMEVTYPER<n>_EL0.TH is
> +	 * (2 ^ PMMIR.THWIDTH) - 1.
> +	 */
> +	return (1 << FIELD_GET(ARMV8_PMU_THWIDTH, cpu_pmu->reg_pmmir)) - 1;
> +}
> +
> +static ssize_t threshold_max_show(struct device *dev,
> +				  struct device_attribute *attr, char *page)
> +{
> +	struct pmu *pmu = dev_get_drvdata(dev);
> +	struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
> +
> +	return sysfs_emit(page, "0x%08x\n", threshold_max(cpu_pmu));
> +}
> +
> +static DEVICE_ATTR_RO(threshold_max);
> +
>  static struct attribute *armv8_pmuv3_caps_attrs[] = {
>  	&dev_attr_slots.attr,
>  	&dev_attr_bus_slots.attr,
>  	&dev_attr_bus_width.attr,
> +	&dev_attr_threshold_max.attr,
>  	NULL,
>  };
>  
> @@ -552,7 +615,7 @@ static void armv8pmu_write_counter(struct perf_event *event, u64 value)
>  		armv8pmu_write_hw_counter(event, value);
>  }
>  
> -static inline void armv8pmu_write_evtype(int idx, u32 val)
> +static inline void armv8pmu_write_evtype(int idx, unsigned long val)
>  {
>  	u32 counter = ARMV8_IDX_TO_COUNTER(idx);
>  	unsigned long mask = ARMV8_PMU_EVTYPE_EVENT |
> @@ -921,6 +984,10 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>  				     struct perf_event_attr *attr)
>  {
>  	unsigned long config_base = 0;
> +	struct perf_event *perf_event = container_of(attr, struct perf_event,
> +						     attr);
> +	struct arm_pmu *cpu_pmu = to_arm_pmu(perf_event->pmu);
> +	u32 th, th_max;
>  
>  	if (attr->exclude_idle)
>  		return -EPERM;
> @@ -952,6 +1019,21 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>  	if (attr->exclude_user)
>  		config_base |= ARMV8_PMU_EXCLUDE_EL0;
>  
> +	/*
> +	 * Insert event counting threshold (FEAT_PMUv3_TH) values. If
> +	 * FEAT_PMUv3_TH isn't implemented, then THWIDTH (threshold_max) will be
> +	 * 0 and no values will be written.
> +	 */
> +	th_max = threshold_max(cpu_pmu);
> +	if (IS_ENABLED(CONFIG_ARM64) && th_max) {

Why is the IS_ENABLED() check needed here?

> +		th = min(armv8pmu_event_threshold(attr), th_max);
> +		if (th) {

Why is it useful to take the minimum here? If userspace asks for a value
bigger than the maximum support threshold, shouldn't we return an error
rather than silently clamp it?

> +			config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TH, th);
> +			config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TC,
> +						  armv8pmu_event_threshold_control(attr));
> +		}
> +	}
> +
>  	/*
>  	 * Install the filter into config_base as this is used to
>  	 * construct the event type.
> diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
> index ddd1fec86739..ccbc0f9a74d8 100644
> --- a/include/linux/perf/arm_pmuv3.h
> +++ b/include/linux/perf/arm_pmuv3.h
> @@ -258,6 +258,7 @@
>  #define ARMV8_PMU_BUS_SLOTS_MASK 0xff
>  #define ARMV8_PMU_BUS_WIDTH_SHIFT 16
>  #define ARMV8_PMU_BUS_WIDTH_MASK 0xf
> +#define ARMV8_PMU_THWIDTH GENMASK(23, 20)

It's a bit messy having a mixture of GENMASK and MASK/SHIFT pairs. Please
can you either update what's there to use GENMASK, or use SHIFT/MASK for the
new addition?

Will


From angelogioacchino.delregno at collabora.com  Tue Dec  5 05:15:19 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 5 Dec 2023 14:15:19 +0100
Subject: [PATCH V2 2/3] dt-bindings: arm64: dts: mediatek: Add Acelink
 EW-7886CAX access point
In-Reply-To: <20231204200907.5687-2-zajec5@gmail.com>
References: <20231204200907.5687-1-zajec5@gmail.com>
 <20231204200907.5687-2-zajec5@gmail.com>
Message-ID: <6e6cd1d0-c46e-496a-9a31-c1ecd75bf34f@collabora.com>

Il 04/12/23 21:09, Rafa? Mi?ecki ha scritto:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Tue Dec  5 05:16:23 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 5 Dec 2023 14:16:23 +0100
Subject: [PATCH V2 3/3] arm64: dts: mediatek: Add Acelink EW-7886CAX
In-Reply-To: <20231204200907.5687-3-zajec5@gmail.com>
References: <20231204200907.5687-1-zajec5@gmail.com>
 <20231204200907.5687-3-zajec5@gmail.com>
Message-ID: <b1b4da61-6c35-4f8d-b3f3-efa50548e0d5@collabora.com>

Il 04/12/23 21:09, Rafa? Mi?ecki ha scritto:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point.
> It has 512 MiB of RAM, one 2.5 Gbps PoE (802.3at) Ethernet port and
> on-SoC Wi-Fi.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Tue Dec  5 05:17:17 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 5 Dec 2023 14:17:17 +0100
Subject: [PATCH V2 3/3] arm64: dts: mediatek: Add Acelink EW-7886CAX
In-Reply-To: <20231204200907.5687-3-zajec5@gmail.com>
References: <20231204200907.5687-1-zajec5@gmail.com>
 <20231204200907.5687-3-zajec5@gmail.com>
Message-ID: <4e3c38b0-c366-46e6-a0ce-6b1ff25c5452@collabora.com>

Il 04/12/23 21:09, Rafa? Mi?ecki ha scritto:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point.
> It has 512 MiB of RAM, one 2.5 Gbps PoE (802.3at) Ethernet port and
> on-SoC Wi-Fi.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From festevam at gmail.com  Tue Dec  5 05:18:38 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue,  5 Dec 2023 10:18:38 -0300
Subject: [PATCH] ARM: dts: imx28-lwe: Pass device_type to the memory node
Message-ID: <20231205131838.2013872-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per memory.yaml, 'device_type' is a required property.

Pass it to fix the following dt-schema warning:

imx28-xea.dtb: /: memory at 40000000: 'device_type' is a required property
	from schema $id: http://devicetree.org/schemas/memory.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/mxs/imx28-lwe.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-lwe.dtsi b/arch/arm/boot/dts/nxp/mxs/imx28-lwe.dtsi
index bb971e660db8..69fcb0dde940 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28-lwe.dtsi
+++ b/arch/arm/boot/dts/nxp/mxs/imx28-lwe.dtsi
@@ -18,6 +18,7 @@ chosen {
 
 	memory at 40000000 {
 		reg = <0x40000000 0x08000000>;
+		device_type = "memory";
 	};
 
 	reg_3v3: regulator-reg-3v3 {
-- 
2.34.1



From angelogioacchino.delregno at collabora.com  Tue Dec  5 05:24:00 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 5 Dec 2023 14:24:00 +0100
Subject: [PATCH v3 2/2] mmc: mediatek: extend number of tuning steps
In-Reply-To: <a419295339c8126150c1e393fcc4cb6a232f07b5.camel@mediatek.com>
References: <20231130061513.1296-1-axe.yang@mediatek.com>
 <20231130061513.1296-3-axe.yang@mediatek.com>
 <27313484-10a9-4a2f-93b1-9b5ce04ad9c6@collabora.com>
 <a419295339c8126150c1e393fcc4cb6a232f07b5.camel@mediatek.com>
Message-ID: <e85cc03e-616f-4d72-8234-f65741047df5@collabora.com>

Il 05/12/23 03:02, Axe Yang (??) ha scritto:
> On Fri, 2023-12-01 at 10:02 +0100, AngeloGioacchino Del Regno wrote:
>> Il 30/11/23 07:15, Axe Yang ha scritto:
>>> Previously, during the MSDC calibration process, a full clock cycle
>>> actually not be covered, which in some cases didn't yield the best
>>> results and could cause CRC errors. This problem is particularly
>>> evident when MSDC is used as an SDIO host. In fact, MSDC support
>>> tuning up to a maximum of 64 steps, but by default, the step number
>>> is 32. By increase the tuning step, we are more likely to cover
>>> more
>>> parts of a clock cycle, and get better calibration result.
>>>
>>> To illustrate, when tuning 32 steps, if the obtained window has a
>>> hole
>>> near the middle, like this: 0xffc07ff (hex), then the selected
>>> delay
>>> will be the 6 (counting from right to left).
>>>
>>> (32 <- 1)
>>> 1111 1111 1100 0000 0000 0111 11(1)1 1111
>>>
>>> However, if we tune 64 steps, the window obtained may look like
>>> this:
>>> 0xfffffffffffc07ff. The final selected delay will be 44, which is
>>> safer as it is further away from the hole:
>>>
>>> (64 <- 1)
>>> 1111 ... (1)111 1111 1111 1111 1111 1100 0000 0000 0111 1111 1111
>>>
>>> In this case, delay 6 selected through 32 steps tuning is obviously
>>> not optimal, and this delay is closer to the hole, using it would
>>> easily cause CRC problems.
>>>
>>> You will need to configure property "mediatek,tuning-step" in MSDC
>>> dts node to 64 to extend the steps.
>>>
>>> Signed-off-by: Axe Yang <axe.yang at mediatek.com>
>>> ---
>>>    drivers/mmc/host/mtk-sd.c | 155 ++++++++++++++++++++++++++-------
>>> -----
>>>    1 file changed, 107 insertions(+), 48 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
>>> index 97f7c3d4be6e..4cd306b3b295 100644
>>> --- a/drivers/mmc/host/mtk-sd.c
>>> +++ b/drivers/mmc/host/mtk-sd.c
>>> @@ -252,12 +252,16 @@
>>>    
>>>    #define MSDC_PAD_TUNE_DATWRDLY	  GENMASK(4, 0)		/*
>>> RW */
>>>    #define MSDC_PAD_TUNE_DATRRDLY	  GENMASK(12, 8)	/* RW */
>>> +#define MSDC_PAD_TUNE_DATRRDLY2	  GENMASK(12, 8)	/* RW */
>>>    #define MSDC_PAD_TUNE_CMDRDLY	  GENMASK(20, 16)	/* RW */
>>> +#define MSDC_PAD_TUNE_CMDRDLY2	  GENMASK(20, 16)	/* RW */
>>>    #define MSDC_PAD_TUNE_CMDRRDLY	  GENMASK(26, 22)	/* RW */
>>>    #define MSDC_PAD_TUNE_CLKTDLY	  GENMASK(31, 27)	/* RW */
>>>    #define MSDC_PAD_TUNE_RXDLYSEL	  BIT(15)   /* RW */
>>>    #define MSDC_PAD_TUNE_RD_SEL	  BIT(13)   /* RW */
>>>    #define MSDC_PAD_TUNE_CMD_SEL	  BIT(21)   /* RW */
>>> +#define MSDC_PAD_TUNE_RD2_SEL	  BIT(13)   /* RW */
>>> +#define MSDC_PAD_TUNE_CMD2_SEL	  BIT(21)   /* RW */
>>>    
>>>    #define PAD_DS_TUNE_DLY_SEL       BIT(0)	  /* RW */
>>>    #define PAD_DS_TUNE_DLY1	  GENMASK(6, 2)   /* RW */
>>> @@ -325,7 +329,8 @@
>>>    
>>>    #define DEFAULT_DEBOUNCE	(8)	/* 8 cycles CD debounce */
>>>    
>>> -#define PAD_DELAY_MAX	32 /* PAD delay cells */
>>> +#define PAD_DELAY_HALF	32 /* PAD delay cells */
>>> +#define PAD_DELAY_FULL	64
>>>    /*---------------------------------------------------------------
>>> -----------*/
>>>    /* Descriptor
>>> Structure                                                     */
>>>    /*---------------------------------------------------------------
>>> -----------*/
>>> @@ -461,6 +466,7 @@ struct msdc_host {
>>>    	u32 hs400_ds_dly3;
>>>    	u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104
>>> */
>>>    	u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
>>> +	u32 tuning_step;
>>>    	bool hs400_cmd_resp_sel_rising;
>>>    				 /* cmd response sample selection for
>>> HS400 */
>>>    	bool hs400_mode;	/* current eMMC will run at hs400 mode */
>>> @@ -1615,7 +1621,7 @@ static irqreturn_t msdc_cmdq_irq(struct
>>> msdc_host *host, u32 intsts)
>>>    	}
>>>    
>>>    	if (cmd_err || dat_err) {
>>> -		dev_err(host->dev, "cmd_err = %d, dat_err =%d, intsts =
>>> 0x%x",
>>> +		dev_err(host->dev, "cmd_err = %d, dat_err = %d, intsts
>>> = 0x%x",
>>>    			cmd_err, dat_err, intsts);
>>>    	}
>>>    
>>> @@ -1780,10 +1786,20 @@ static void msdc_init_hw(struct msdc_host
>>> *host)
>>>    				     DATA_K_VALUE_SEL);
>>>    			sdr_set_bits(host->top_base + EMMC_TOP_CMD,
>>>    				     PAD_CMD_RD_RXDLY_SEL);
>>> +			if (host->tuning_step > PAD_DELAY_HALF) {
>>> +				sdr_set_bits(host->top_base +
>>> EMMC_TOP_CONTROL,
>>> +					     PAD_DAT_RD_RXDLY2_SEL);
>>> +				sdr_set_bits(host->top_base +
>>> EMMC_TOP_CMD,
>>> +					     PAD_CMD_RD_RXDLY2_SEL);
>>> +			}
>>>    		} else {
>>>    			sdr_set_bits(host->base + tune_reg,
>>>    				     MSDC_PAD_TUNE_RD_SEL |
>>>    				     MSDC_PAD_TUNE_CMD_SEL);
>>> +			if (host->tuning_step > PAD_DELAY_HALF)
>>> +				sdr_set_bits(host->base + tune_reg + 4,
>>
>> `tune_reg + 4` is a different register, please define it.
>>
> The tune_reg is not a fixed register address, it is defined in
> compatible structures. So using the offset here will make the code more
> consise. The offset of registers related to 64 steps tuning is fixed
> relative to 32-steps tuning regsiter, the offset is always 4.
> 
> However. using the magic number '4' here directly is not ideal. I think
> I can improve this part of code by defining '4' as a macro. What do you
> think about it? If you insist on redifning the registers, I can do it,
> but it will make the code a bit more complex than it is now.
> 
> 
>> Also, I can't find this in MT8192, MT8195 - as those bits seem to be
>> undefined,
>> so, which SoCs are actually compatible with this change?
> 
> Sorry, which bits are you talking about?
> This change compatible for all SoCs. In fact, MSDC has always supported
> 64 step tuning.
> 
> 

Sorry, found it under a slightly different name. Nevermind.

>>
>>
>>> +					     MSDC_PAD_TUNE_RD2_SEL |
>>> +					     MSDC_PAD_TUNE_CMD2_SEL);
>>>    		}
>>>    	} else {
>>>    		/* choose clock tune */
>>> @@ -1925,24 +1941,24 @@ static void msdc_ops_set_ios(struct
>>> mmc_host *mmc, struct mmc_ios *ios)
>>>    		msdc_set_mclk(host, ios->timing, ios->clock);
>>>    }
>>>    
>>> -static u32 test_delay_bit(u32 delay, u32 bit)
>>> +static u64 test_delay_bit(u64 delay, u32 bit)
>>>    {
>>> -	bit %= PAD_DELAY_MAX;
>>> -	return delay & BIT(bit);
>>> +	bit %= PAD_DELAY_FULL;
>>> +	return delay & BIT_ULL(bit);
>>>    }
>>>    
>>> -static int get_delay_len(u32 delay, u32 start_bit)
>>> +static int get_delay_len(u64 delay, u32 start_bit)
>>>    {
>>>    	int i;
>>>    
>>> -	for (i = 0; i < (PAD_DELAY_MAX - start_bit); i++) {
>>> +	for (i = 0; i < (PAD_DELAY_FULL - start_bit); i++) {
>>>    		if (test_delay_bit(delay, start_bit + i) == 0)
>>>    			return i;
>>>    	}
>>> -	return PAD_DELAY_MAX - start_bit;
>>> +	return PAD_DELAY_FULL - start_bit;
>>>    }
>>>    
>>> -static struct msdc_delay_phase get_best_delay(struct msdc_host
>>> *host, u32 delay)
>>> +static struct msdc_delay_phase get_best_delay(struct msdc_host
>>> *host, u64 delay)
>>>    {
>>>    	int start = 0, len = 0;
>>>    	int start_final = 0, len_final = 0;
>>> @@ -1950,28 +1966,28 @@ static struct msdc_delay_phase
>>> get_best_delay(struct msdc_host *host, u32 delay)
>>>    	struct msdc_delay_phase delay_phase = { 0, };
>>>    
>>>    	if (delay == 0) {
>>> -		dev_err(host->dev, "phase error: [map:%x]\n", delay);
>>> +		dev_err(host->dev, "phase error: [map:%016llx]\n",
>>> delay);
>>>    		delay_phase.final_phase = final_phase;
>>>    		return delay_phase;
>>>    	}
>>>    
>>> -	while (start < PAD_DELAY_MAX) {
>>> +	while (start < PAD_DELAY_FULL) {
>>>    		len = get_delay_len(delay, start);
>>>    		if (len_final < len) {
>>>    			start_final = start;
>>>    			len_final = len;
>>>    		}
>>>    		start += len ? len : 1;
>>> -		if (len >= 12 && start_final < 4)
>>> +		if (!upper_32_bits(delay) && len >= 12 && start_final <
>>> 4)
>>>    			break;
>>>    	}
>>>    
>>>    	/* The rule is that to find the smallest delay cell */
>>>    	if (start_final == 0)
>>> -		final_phase = (start_final + len_final / 3) %
>>> PAD_DELAY_MAX;
>>> +		final_phase = (start_final + len_final / 3) %
>>> PAD_DELAY_FULL;
>>>    	else
>>> -		final_phase = (start_final + len_final / 2) %
>>> PAD_DELAY_MAX;
>>> -	dev_dbg(host->dev, "phase: [map:%x] [maxlen:%d] [final:%d]\n",
>>> +		final_phase = (start_final + len_final / 2) %
>>> PAD_DELAY_FULL;
>>> +	dev_dbg(host->dev, "phase: [map:%016llx] [maxlen:%d]
>>> [final:%d]\n",
>>>    		delay, len_final, final_phase);
>>>    
>>>    	delay_phase.maxlen = len_final;
>>> @@ -1984,30 +2000,68 @@ static inline void
>>> msdc_set_cmd_delay(struct msdc_host *host, u32 value)
>>>    {
>>>    	u32 tune_reg = host->dev_comp->pad_tune_reg;
>>>    
>>> -	if (host->top_base)
>>> -		sdr_set_field(host->top_base + EMMC_TOP_CMD,
>>> PAD_CMD_RXDLY,
>>> -			      value);
>>> -	else
>>> -		sdr_set_field(host->base + tune_reg,
>>> MSDC_PAD_TUNE_CMDRDLY,
>>> -			      value);
>>> +	if (host->top_base) {
>>> +		if (value < PAD_DELAY_HALF) {
>>> +			sdr_set_field(host->top_base + EMMC_TOP_CMD,
>>> PAD_CMD_RXDLY,
>>> +				      value);
>>
>> This goes up to 92 columns, and it's fine, so fits in one line and
>> it's more
>> readable like that.
>>
>> I know that's not your fault, but since you're actually touching
>> those lines
>> it's a good occasion to also do that (not only here) :-)
>>
> Sure, will update this part in v4, and thanks for your meticulous
> review.
> 

Thank you!
Angelo



From eauger at redhat.com  Tue Dec  5 05:25:27 2023
From: eauger at redhat.com (Eric Auger)
Date: Tue, 5 Dec 2023 14:25:27 +0100
Subject: [PATCH v2 14/19] iommu/arm-smmu-v3: Remove
 arm_smmu_master->domain
In-Reply-To: <20231130120340.GA1124924@nvidia.com>
References: <14-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <6fff20dd-46d5-4974-a4a5-fb4e7a59ce44@redhat.com>
 <20231130120340.GA1124924@nvidia.com>
Message-ID: <8bed7afd-d180-4b71-8211-e3fb7a653b8a@redhat.com>

Hi Jason,

On 11/30/23 13:03, Jason Gunthorpe wrote:
> On Mon, Nov 27, 2023 at 06:14:30PM +0100, Eric Auger wrote:
>> Hi Jason,
>>
>> On 11/13/23 18:53, Jason Gunthorpe wrote:
>>> Introducing global statics which are of type struct iommu_domain, not
>>> struct arm_smmu_domain makes it difficult to retain
>>> arm_smmu_master->domain, as it can no longer point to an IDENTITY or
>>> BLOCKED domain.
>>>
>>> The only place that uses the value is arm_smmu_detach_dev(). Change things
>>> to work like other drivers and call iommu_get_domain_for_dev() to obtain
>>> the current domain.
>>>
>>> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
>>
>> This patch introduces a crash on my machine. See below.
> 
> Ah, your system must have multi-device groups
> 
> The master->domain was subtly protecting the domain_head to ensure
> we don't touch it unless it is already in a domain list. This issue is
> solved in part 2 (iommu/arm-smmu-v3: Make smmu_domain->devices into an
> allocated list) which removes the domain_head.
> 
> This hunk should fix this patch. I updated the github

I confirm that the hunk hereafter fixes the crash.

Thanks

Eric
> 
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 23dda64722ea17..102e13b65bcdec 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2491,7 +2491,7 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master)
>  	arm_smmu_disable_ats(master, smmu_domain);
>  
>  	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
> -	list_del(&master->domain_head);
> +	list_del_init(&master->domain_head);
>  	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
>  
>  	master->ats_enabled = false;
> @@ -2606,7 +2606,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
>  
>  out_list_del:
>  	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
> -	list_del(&master->domain_head);
> +	list_del_init(&master->domain_head);
>  	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
>  
>  out_unlock:
> @@ -2810,6 +2810,7 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
>  	master->dev = dev;
>  	master->smmu = smmu;
>  	INIT_LIST_HEAD(&master->bonds);
> +	INIT_LIST_HEAD(&master->domain_head);
>  	dev_iommu_priv_set(dev, master);
>  
>  	ret = arm_smmu_insert_master(smmu, master);
> 
> 
> 
> Thank!!
> Jason
> 



From festevam at gmail.com  Tue Dec  5 05:27:35 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue,  5 Dec 2023 10:27:35 -0300
Subject: [PATCH] ARM: dts: imx28-xea: Pass the 'model' property
Message-ID: <20231205132735.2016022-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per root-node.yaml, 'model' is a required property.

Pass it to fix the following dt-schema warning:

imx28-xea.dtb: /: 'model' is a required property
	from schema $id: http://devicetree.org/schemas/root-node.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/mxs/imx28-xea.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
index a400c108f66a..cc54a0390f8c 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
+++ b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
@@ -8,6 +8,7 @@
 #include "imx28-lwe.dtsi"
 
 / {
+	model = "Liebherr Xea board";
 	compatible = "lwn,imx28-xea", "fsl,imx28";
 };
 
-- 
2.34.1



From lpieralisi at kernel.org  Tue Dec  5 05:28:12 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Tue, 5 Dec 2023 14:28:12 +0100
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZW8MP2tDt4_9ROBz@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
Message-ID: <ZW8lbK88bgdmBgl9@lpieralisi>

[+James]

On Tue, Dec 05, 2023 at 11:40:47AM +0000, Catalin Marinas wrote:

[...]

> > - Will had unanswered questions in another part of the thread:
> > 
> >   https://lore.kernel.org/all/20231013092954.GB13524 at willie-the-truck/
> > 
> >   Can someone please help concluding it?
> 
> Is this about reclaiming the device? I think we concluded that we can't
> generalise this beyond PCIe, though not sure there was any formal
> statement to that thread. The other point Will had was around stating
> in the commit message why we only relax this to Normal NC. I haven't
> checked the commit message yet, it needs careful reading ;).

1) Reclaiming the device: I wrote a section that was reported in this
   commit log hunk:

   "Relaxing S2 KVM device MMIO mappings to Normal-NC is not expected to
   trigger any issue on guest device reclaim use cases either (i.e.
   device MMIO unmap followed by a device reset) at least for PCIe
   devices, in that in PCIe a device reset is architected and carried
   out through PCI config space transactions that are naturally ordered
   with respect to MMIO transactions according to the PCI ordering
   rules."

   It is not too verbose on purpose - I thought it is too
   complicated to express the details in a commit log but
   we can elaborate on that if it is beneficial, probably
   in /Documentation, not in the log itself.

2) On FWB: I added a full section to the log I posted here:

   https://lore.kernel.org/all/ZUz78gFPgMupew+m at lpieralisi

   but I think Ankit trimmed it and I can't certainly blame anyone
   for that, it is a commit log, it is already hard to digest as it is.

I added James because I think that most of the points I made in the logs
are really RAS related (and without him I would not have understood half
of them :)). It would be very beneficial to everyone to have those
added to kernel documentation - especially to express in architectural
terms why this it is a safe change to make (at least for PCIe devices).

I am happy to work on the documentation changes - let's just agree what
should be done next.

Thanks,
Lorenzo

> > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > index d14504821b79..1cb302457d3f 100644
> > > --- a/arch/arm64/kvm/mmu.c
> > > +++ b/arch/arm64/kvm/mmu.c
> > > @@ -1071,7 +1071,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> > >  	struct kvm_mmu_memory_cache cache = { .gfp_zero = __GFP_ZERO };
> > >  	struct kvm_s2_mmu *mmu = &kvm->arch.mmu;
> > >  	struct kvm_pgtable *pgt = mmu->pgt;
> > > -	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_DEVICE |
> > > +	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_NORMAL_NC |
> > >  				     KVM_PGTABLE_PROT_R |
> > >  				     (writable ? KVM_PGTABLE_PROT_W : 0);
> > 
> > Doesn't this affect the GICv2 VCPU interface, which is effectively a
> > shared peripheral, now allowing a guest to affect another guest's
> > interrupt distribution? If that is the case, this needs to be fixed.
> > 
> > In general, I don't think this should be a blanket statement, but be
> > limited to devices that we presume can deal with this (i.e. PCIe, and
> > not much else).
> 
> Based on other on-list and off-line discussions, I came to the same
> conclusion that we can't relax this beyond PCIe. How we do this, it's up
> for debate. Some ideas:
> 
> - something in the vfio-pci driver like a new VM_* flag that KVM can
>   consume (hard sell for an arch-specific thing)
> 
> - changing the vfio-pci driver to allow WC and NC mappings (x86
>   terminology) with additional knowledge about what it can safely map
>   as NC. KVM would mimic the vma attributes (it doesn't eliminate the
>   alias though, the guest can always go for Device while the VMM for
>   Normal)
> 
> - some per-SoC pfn ranges that are permitted as Normal NC. Can the arch
>   code figure out where these PCIe BARs are or is it only the vfio-pci
>   driver? I guess we can sort something out around the PCIe but I'm not
>   familiar with this subsystem. The alternative is some "safe" ranges in
>   firmware tables, assuming the firmware configures the PCIe BARs
>   location
> 
> -- 
> Catalin


From mripard at kernel.org  Tue Dec  5 05:29:27 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Tue, 5 Dec 2023 14:29:27 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
Message-ID: <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>

Hi,

On Tue, Dec 05, 2023 at 09:18:58AM +0100, H. Nikolaus Schaller wrote:
> > Am 05.12.2023 um 07:57 schrieb Maxime Ripard <mripard at kernel.org>:
> > 
> > On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
> >> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> >> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
> >> including register space and interrupts. Clocks, reset, and power domain
> >> information is SoC specific.
> >> 
> >> Signed-off-by: Andrew Davis <afd at ti.com>
> >> ---
> >> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
> >> 1 file changed, 63 insertions(+), 6 deletions(-)
> > 
> > I think it would be best to have a separate file for this, img,sgx.yaml
> > maybe?
> 
> Why?

Because it's more convenient?

> The whole family of IMG GPUs is PowerVR and SGX and Rogue are generations 5 and 6++:
> 
> https://en.wikipedia.org/wiki/PowerVR

That's not really relevant as far as bindings go. We have multiple
binding files for devices of the same generation, or single bindings
covering multiple generations.

The important part is that every compatible is documented. It doesn't
really matter how or where.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/6bb2c345/attachment-0001.sig>

From maz at kernel.org  Tue Dec  5 05:31:48 2023
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  5 Dec 2023 13:31:48 +0000
Subject: [PATCH] arm64: Make icache detection a cpu capability
Message-ID: <20231205133148.2011836-1-maz@kernel.org>

Now that we only have two icache policies, we are in a good position
to make the whole detection business more robust.

Let's replace __icache_flags by a single capability (ICACHE_PIPT),
and use this if all CPUs are indeed PIPT. It means we can rely on
existing logic to mandate that a VIPT CPU coming up late will be
denied booting, which is the safe thing to do.

This also leads to some nice cleanups in pKVM. Additionally,
cache_is_aliasing() is made __always_inline in order to avoid
surprisees in the nVHE hypervisor object.

Suggested-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---

Notes:
    Applies on top of my previous VPIPT removal series.

 arch/arm64/include/asm/cache.h   | 11 +++-------
 arch/arm64/include/asm/kvm_hyp.h |  1 -
 arch/arm64/kernel/cpufeature.c   | 36 +++++++++++++++++++-------------
 arch/arm64/kernel/cpuinfo.c      | 34 ------------------------------
 arch/arm64/kvm/arm.c             |  1 -
 arch/arm64/kvm/hyp/nvhe/pkvm.c   |  3 ---
 arch/arm64/tools/cpucaps         |  1 +
 7 files changed, 25 insertions(+), 62 deletions(-)

diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 06a4670bdb0b..70bd32600e5e 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -37,9 +37,9 @@
 
 #ifndef __ASSEMBLY__
 
-#include <linux/bitops.h>
 #include <linux/kasan-enabled.h>
 
+#include <asm/cpufeature.h>
 #include <asm/cputype.h>
 #include <asm/mte-def.h>
 #include <asm/sysreg.h>
@@ -55,18 +55,13 @@ static inline unsigned int arch_slab_minalign(void)
 #define arch_slab_minalign() arch_slab_minalign()
 #endif
 
-#define CTR_L1IP(ctr)		SYS_FIELD_GET(CTR_EL0, L1Ip, ctr)
-
-#define ICACHEF_ALIASING	0
-extern unsigned long __icache_flags;
-
 /*
  * Whilst the D-side always behaves as PIPT on AArch64, aliasing is
  * permitted in the I-cache.
  */
-static inline int icache_is_aliasing(void)
+static __always_inline int icache_is_aliasing(void)
 {
-	return test_bit(ICACHEF_ALIASING, &__icache_flags);
+	return !alternative_has_cap_likely(ARM64_ICACHE_PIPT);
 }
 
 static inline u32 cache_type_cwg(void)
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 145ce73fc16c..7ad70f9865fd 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -140,7 +140,6 @@ extern u64 kvm_nvhe_sym(id_aa64mmfr1_el1_sys_val);
 extern u64 kvm_nvhe_sym(id_aa64mmfr2_el1_sys_val);
 extern u64 kvm_nvhe_sym(id_aa64smfr0_el1_sys_val);
 
-extern unsigned long kvm_nvhe_sym(__icache_flags);
 extern unsigned int kvm_nvhe_sym(kvm_arm_vmid_bits);
 
 #endif /* __ARM64_KVM_HYP_H__ */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 646591c67e7a..1ee844dd7529 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1594,17 +1594,18 @@ static bool has_no_hw_prefetch(const struct arm64_cpu_capabilities *entry, int _
 		MIDR_CPU_VAR_REV(1, MIDR_REVISION_MASK));
 }
 
-static bool has_cache_idc(const struct arm64_cpu_capabilities *entry,
-			  int scope)
+static u64 get_scoped_ctr_el0(int scope)
 {
-	u64 ctr;
-
 	if (scope == SCOPE_SYSTEM)
-		ctr = arm64_ftr_reg_ctrel0.sys_val;
-	else
-		ctr = read_cpuid_effective_cachetype();
+		return arm64_ftr_reg_ctrel0.sys_val;
 
-	return ctr & BIT(CTR_EL0_IDC_SHIFT);
+	return read_cpuid_effective_cachetype();
+}
+
+static bool has_cache_idc(const struct arm64_cpu_capabilities *entry,
+			  int scope)
+{
+	return get_scoped_ctr_el0(scope) & BIT(CTR_EL0_IDC_SHIFT);
 }
 
 static void cpu_emulate_effective_ctr(const struct arm64_cpu_capabilities *__unused)
@@ -1622,14 +1623,13 @@ static void cpu_emulate_effective_ctr(const struct arm64_cpu_capabilities *__unu
 static bool has_cache_dic(const struct arm64_cpu_capabilities *entry,
 			  int scope)
 {
-	u64 ctr;
-
-	if (scope == SCOPE_SYSTEM)
-		ctr = arm64_ftr_reg_ctrel0.sys_val;
-	else
-		ctr = read_cpuid_cachetype();
+	return get_scoped_ctr_el0(scope) & BIT(CTR_EL0_DIC_SHIFT);
+}
 
-	return ctr & BIT(CTR_EL0_DIC_SHIFT);
+static bool has_pipt_icache(const struct arm64_cpu_capabilities *entry,
+			    int scope)
+{
+	return FIELD_GET(CTR_EL0_L1Ip_MASK, get_scoped_ctr_el0(scope)) == CTR_EL0_L1Ip_PIPT;
 }
 
 static bool __maybe_unused
@@ -2272,6 +2272,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
 		.matches = has_always,
 	},
+	{
+		.desc = "PIPT I-cache policy",
+		.capability = ARM64_ICACHE_PIPT,
+		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+		.matches = has_pipt_icache,
+	},
 	{
 		.desc = "GIC system register CPU interface",
 		.capability = ARM64_HAS_GIC_CPUIF_SYSREGS,
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 47043c0d95ec..a4ea331fb6d4 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -33,20 +33,6 @@
 DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
 static struct cpuinfo_arm64 boot_cpu_data;
 
-static inline const char *icache_policy_str(int l1ip)
-{
-	switch (l1ip) {
-	case CTR_EL0_L1Ip_VIPT:
-		return "VIPT";
-	case CTR_EL0_L1Ip_PIPT:
-		return "PIPT";
-	default:
-		return "RESERVED/UNKNOWN";
-	}
-}
-
-unsigned long __icache_flags;
-
 static const char *const hwcap_str[] = {
 	[KERNEL_HWCAP_FP]		= "fp",
 	[KERNEL_HWCAP_ASIMD]		= "asimd",
@@ -378,24 +364,6 @@ static int __init cpuinfo_regs_init(void)
 }
 device_initcall(cpuinfo_regs_init);
 
-static void cpuinfo_detect_icache_policy(struct cpuinfo_arm64 *info)
-{
-	unsigned int cpu = smp_processor_id();
-	u32 l1ip = CTR_L1IP(info->reg_ctr);
-
-	switch (l1ip) {
-	case CTR_EL0_L1Ip_PIPT:
-		break;
-	case CTR_EL0_L1Ip_VIPT:
-	default:
-		/* Assume aliasing */
-		set_bit(ICACHEF_ALIASING, &__icache_flags);
-		break;
-	}
-
-	pr_info("Detected %s I-cache on CPU%d\n", icache_policy_str(l1ip), cpu);
-}
-
 static void __cpuinfo_store_cpu_32bit(struct cpuinfo_32bit *info)
 {
 	info->reg_id_dfr0 = read_cpuid(ID_DFR0_EL1);
@@ -457,8 +425,6 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
 
 	if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0))
 		__cpuinfo_store_cpu_32bit(&info->aarch32);
-
-	cpuinfo_detect_icache_policy(info);
 }
 
 void cpuinfo_store_cpu(void)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index e5f75f1f1085..a5f71165cd5c 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -2242,7 +2242,6 @@ static void kvm_hyp_init_symbols(void)
 	kvm_nvhe_sym(id_aa64mmfr1_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1);
 	kvm_nvhe_sym(id_aa64mmfr2_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64MMFR2_EL1);
 	kvm_nvhe_sym(id_aa64smfr0_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64SMFR0_EL1);
-	kvm_nvhe_sym(__icache_flags) = __icache_flags;
 	kvm_nvhe_sym(kvm_arm_vmid_bits) = kvm_arm_vmid_bits;
 }
 
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index b29f15418c0a..187ce5720697 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -12,9 +12,6 @@
 #include <nvhe/pkvm.h>
 #include <nvhe/trap_handler.h>
 
-/* Used by icache_is_aliasing(). */
-unsigned long __icache_flags;
-
 /* Used by kvm_get_vttbr(). */
 unsigned int kvm_arm_vmid_bits;
 
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index b98c38288a9d..9c6313cd6f5e 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -53,6 +53,7 @@ HAS_TLB_RANGE
 HAS_VIRT_HOST_EXTN
 HAS_WFXT
 HW_DBM
+ICACHE_PIPT
 KVM_HVHE
 KVM_PROTECTED_MODE
 MISMATCHED_CACHE_TYPE
-- 
2.39.2



From knaerzche at gmail.com  Tue Dec  5 05:33:01 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 5 Dec 2023 14:33:01 +0100
Subject: [PATCH 0/3] Move core bus and gpio aliases to SoC dtsi for RK3128
In-Reply-To: <170173468934.501889.12474504620278418598.b4-ty@sntech.de>
References: <20231202130506.66738-2-knaerzche@gmail.com>
 <170173468934.501889.12474504620278418598.b4-ty@sntech.de>
Message-ID: <7bc1ba43-98cc-47ce-8d58-b4f4081c84b7@gmail.com>

Hi Heiko,

Am 05.12.23 um 01:05 schrieb Heiko Stuebner:
> On Sat, 2 Dec 2023 14:05:04 +0100, Alex Bee wrote:
>> Following up the recent discussion [0] about where aliases can be/should be
>> placed this series moves gpio, i2c and uart aliases to SoC dtsi for RK3128.
>>
>> Note: This patches are based on maintainter's repo.
>>
>> [0] https://lore.kernel.org/all/b0c637f5-5abf-420b-8b02-839eba68799e at linaro.org/T/#m94aebb23a29b015d94b250a70b675febdaa902ea
>>
>> [...]
> Applied, thanks!
>
> [1/3] ARM: dts: rockchip: Move gpio aliases to SoC dtsi for RK3128
>        commit: 3b0422a4ce59d8afb84bd7516bf71a3c1caa7925
> [2/3] ARM: dts: rockchip: Move i2c aliases to SoC dtsi for RK3128
>        commit: 39732a49803cf271454416341549df09c4a2fd2f
>
> I also applied patch 3 ... though had to pick it manually from the list
> as the subject was a bit garbled (missing 3/3), so b4 did not pick it up.

Thanks and sorry for the mess.

Not sure how I managed to get this done :) Will double check next time 
before submitting.

Alex

>
> Best regards,


From hns at goldelico.com  Tue Dec  5 05:50:08 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Tue, 5 Dec 2023 14:50:08 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
Message-ID: <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>

Hi,

> Am 05.12.2023 um 14:29 schrieb Maxime Ripard <mripard at kernel.org>:
> 
> Hi,
> 
> On Tue, Dec 05, 2023 at 09:18:58AM +0100, H. Nikolaus Schaller wrote:
>>> Am 05.12.2023 um 07:57 schrieb Maxime Ripard <mripard at kernel.org>:
>>> 
>>> On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
>>>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
>>>> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
>>>> including register space and interrupts. Clocks, reset, and power domain
>>>> information is SoC specific.
>>>> 
>>>> Signed-off-by: Andrew Davis <afd at ti.com>
>>>> ---
>>>> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
>>>> 1 file changed, 63 insertions(+), 6 deletions(-)
>>> 
>>> I think it would be best to have a separate file for this, img,sgx.yaml
>>> maybe?
>> 
>> Why?
> 
> Because it's more convenient?

Is it?

>> The whole family of IMG GPUs is PowerVR and SGX and Rogue are generations 5 and 6++:
>> 
>> https://en.wikipedia.org/wiki/PowerVR
> 
> That's not really relevant as far as bindings go.

But maybe for choosing binding file names. Well they are machine readable
but sometimes humans work with them.

> We have multiple
> binding files for devices of the same generation, or single bindings
> covering multiple generations.
> 
> The important part is that every compatible is documented. It doesn't
> really matter how or where.

Yes, and that is why I would find it more convenient to have a single
"img,powervr.yaml" for all variations unless it becomes filled with
unrelated stuff (which isn't as far as I see).

BR, Nikolaus

From lkp at intel.com  Tue Dec  5 05:53:57 2023
From: lkp at intel.com (kernel test robot)
Date: Tue, 5 Dec 2023 21:53:57 +0800
Subject: [PATCH 5/7] arm64: dts: st: add all 8 i2c nodes on stm32mp251
In-Reply-To: <20231129125920.1702497-6-alain.volmat@foss.st.com>
References: <20231129125920.1702497-6-alain.volmat@foss.st.com>
Message-ID: <202312052114.dqhaFgjJ-lkp@intel.com>

Hi Alain,

kernel test robot noticed the following build errors:

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on atorgue-stm32/stm32-next robh/for-next linus/master v6.7-rc4 next-20231205]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Alain-Volmat/i2c-stm32f7-perform-most-of-irq-job-in-threaded-handler/20231129-210806
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
patch link:    https://lore.kernel.org/r/20231129125920.1702497-6-alain.volmat%40foss.st.com
patch subject: [PATCH 5/7] arm64: dts: st: add all 8 i2c nodes on stm32mp251
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20231205/202312052114.dqhaFgjJ-lkp at intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231205/202312052114.dqhaFgjJ-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312052114.dqhaFgjJ-lkp at intel.com/

All errors (new ones prefixed by >>):

>> Error: arch/arm64/boot/dts/st/stm32mp251.dtsi:134.20-21 syntax error
   FATAL ERROR: Unable to parse input tree

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From abel.vesa at linaro.org  Tue Dec  5 05:58:23 2023
From: abel.vesa at linaro.org (Abel Vesa)
Date: Tue,  5 Dec 2023 15:58:23 +0200
Subject: [PATCH V4 1/2] dt-bindings: clock: support i.MX93 Analog clock module
In-Reply-To: <20231121063446.155300-1-peng.fan@oss.nxp.com>
References: <20231121063446.155300-1-peng.fan@oss.nxp.com>
Message-ID: <170178465116.22654.4507616023393071038.b4-ty@linaro.org>


On Tue, 21 Nov 2023 14:34:45 +0800, Peng Fan (OSS) wrote:
> Support i.MX93 Analog module which contains PLL and OSC for Clock
> Controller Module
> 
> 

Applied, thanks!

[1/2] dt-bindings: clock: support i.MX93 Analog clock module
      commit: d24ffddd1071dd3bb348b010f1f9b780722ae90f

Best regards,
-- 
Abel Vesa <abel.vesa at linaro.org>


From ryan.roberts at arm.com  Tue Dec  5 06:16:53 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 5 Dec 2023 14:16:53 +0000
Subject: [PATCH v3 01/15] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <df99bb4e-f69d-4d94-baa5-2fc336df1a7b@redhat.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-2-ryan.roberts@arm.com>
 <a12ce4f8-feb0-4e35-8f55-9270fe5a808b@redhat.com>
 <104de2d6-ecf9-4b0c-a982-5bd8e1aea758@redhat.com>
 <5b8b9f8c-8e9b-42a5-b8b2-9b96903f3ada@redhat.com>
 <a81dc390-8b10-4ce9-b72f-57f253e77af3@arm.com>
 <df99bb4e-f69d-4d94-baa5-2fc336df1a7b@redhat.com>
Message-ID: <0b48135a-a44b-4b5a-a33b-abd3a3b47ff8@arm.com>

On 05/12/2023 12:04, David Hildenbrand wrote:
> On 05.12.23 12:30, Ryan Roberts wrote:
>> On 04/12/2023 17:27, David Hildenbrand wrote:
>>>>
>>>> With rmap batching from [1] -- rebased+changed on top of that -- we could turn
>>>> that into an effective (untested):
>>>>
>>>> ?????????? if (page && folio_test_anon(folio)) {
>>>> +?????????????? nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr,
>>>> end,
>>>> +?????????????????????????????????????????????? pte, enforce_uffd_wp,
>>>> &nr_dirty,
>>>> +?????????????????????????????????????????????? &nr_writable);
>>>> ?????????????????? /*
>>>> ??????????????????? * If this page may have been pinned by the parent process,
>>>> ??????????????????? * copy the page immediately for the child so that we'll
>>>> always
>>>> ??????????????????? * guarantee the pinned page won't be randomly replaced
>>>> in the
>>>> ??????????????????? * future.
>>>> ??????????????????? */
>>>> -?????????????? folio_get(folio);
>>>> -?????????????? if (unlikely(folio_try_dup_anon_rmap_pte(folio, page,
>>>> src_vma))) {
>>>> +?????????????? folio_ref_add(folio, nr);
>>>> +?????????????? if (unlikely(folio_try_dup_anon_rmap_ptes(folio, page, nr,
>>>> src_vma))) {
>>>> ?????????????????????????? /* Page may be pinned, we have to copy. */
>>>> -?????????????????????? folio_put(folio);
>>>> -?????????????????????? return copy_present_page(dst_vma, src_vma, dst_pte,
>>>> src_pte,
>>>> -??????????????????????????????????????????????? addr, rss, prealloc, page);
>>>> +?????????????????????? folio_ref_sub(folio, nr);
>>>> +?????????????????????? ret = copy_present_page(dst_vma, src_vma, dst_pte,
>>>> +?????????????????????????????????????????????? src_pte, addr, rss, prealloc,
>>>> +?????????????????????????????????????????????? page);
>>>> +?????????????????????? return ret == 0 ? 1 : ret;
>>>> ?????????????????? }
>>>> -?????????????? rss[MM_ANONPAGES]++;
>>>> +?????????????? rss[MM_ANONPAGES] += nr;
>>>> ?????????? } else if (page) {
>>>> -?????????????? folio_get(folio);
>>>> -?????????????? folio_dup_file_rmap_pte(folio, page);
>>>> -?????????????? rss[mm_counter_file(page)]++;
>>>> +?????????????? nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr,
>>>> end,
>>>> +?????????????????????????????????????????????? pte, enforce_uffd_wp,
>>>> &nr_dirty,
>>>> +?????????????????????????????????????????????? &nr_writable);
>>>> +?????????????? folio_ref_add(folio, nr);
>>>> +?????????????? folio_dup_file_rmap_ptes(folio, page, nr);
>>>> +?????????????? rss[mm_counter_file(page)] += nr;
>>>> ?????????? }
>>>>
>>>>
>>>> We'll have to test performance, but it could be that we want to specialize
>>>> more on !folio_test_large(). That code is very performance-sensitive.
>>>>
>>>>
>>>> [1] https://lkml.kernel.org/r/20231204142146.91437-1-david at redhat.com
>>>
>>> So, on top of [1] without rmap batching but with a slightly modified version of
>>
>> Can you clarify what you mean by "without rmap batching"? I thought [1]
>> implicitly adds rmap batching? (e.g. folio_dup_file_rmap_ptes(), which you've
>> added in the code snippet above).
> 
> Not calling the batched variants but essentially doing what your code does (with
> some minor improvements, like updating the rss counters only once).
> 
> The snipped above is only linked below. I had the performance numbers for [1]
> ready, so I gave it a test on top of that.
> 
> To keep it simple, you might just benchmark w and w/o your patches.
> 
>>
>>> yours (that keeps the existing code structure as pointed out and e.g., updates
>>> counter updates), running my fork() microbenchmark with a 1 GiB of memory:
>>>
>>> Compared to [1], with all order-0 pages it gets 13--14% _slower_ and with all
>>> PTE-mapped THP (order-9) it gets ~29--30% _faster_.
>>
>> What test are you running - I'd like to reproduce if possible, since it sounds
>> like I've got some work to do to remove the order-0 regression.
> 
> Essentially just allocating 1 GiB of memory an measuring how long it takes to
> call fork().
> 
> order-0 benchmarks:
> 
> https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/order-0-benchmarks.c?ref_type=heads
> 
> e.g.,: $ ./order-0-benchmarks fork 100
> 
> 
> pte-mapped-thp benchmarks:
> 
> https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/pte-mapped-thp-benchmarks.c?ref_type=heads
> 
> e.g.,: $ ./pte-mapped-thp-benchmarks fork 100
> 
> 
> Ideally, pin to one CPU and get stable performance numbers by disabling
> SMT+turbo etc.

This is great - thanks! I'll get to work...

> 
>>
>>>
>>> So looks like we really want to have a completely seprate code path for
>>> "!folio_test_large()" to keep that case as fast as possible. And "Likely" we
>>> want to use "likely(!folio_test_large()". ;)
>>
>> Yuk, but fair enough. If I can repro the perf numbers, I'll have a go a
>> reworking this.
>>
>> I think you're also implicitly suggesting that this change needs to depend on
>> [1]? Which is a shame...
> 
> Not necessarily. It certainly cleans up the code, but we can do that in any
> order reasonable.
> 
>>
>> I guess I should also go through a similar exercise for patch 2 in this series.
> 
> 
> Yes. There are "unmap" and "pte-dontneed" benchmarks contained in both files above.
> 



From shameerali.kolothum.thodi at huawei.com  Tue Dec  5 06:16:51 2023
From: shameerali.kolothum.thodi at huawei.com (Shameerali Kolothum Thodi)
Date: Tue, 5 Dec 2023 14:16:51 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZW8MP2tDt4_9ROBz@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org> <ZW8MP2tDt4_9ROBz@arm.com>
Message-ID: <296657c5b09f46a1ac6e4d993fbc0875@huawei.com>



> -----Original Message-----
> From: Catalin Marinas <catalin.marinas at arm.com>
> Sent: Tuesday, December 5, 2023 11:41 AM
> To: Marc Zyngier <maz at kernel.org>
> Cc: ankita at nvidia.com; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi at huawei.com>; jgg at nvidia.com;
> oliver.upton at linux.dev; suzuki.poulose at arm.com; yuzenghui
> <yuzenghui at huawei.com>; will at kernel.org; ardb at kernel.org; akpm at linux-
> foundation.org; gshan at redhat.com; aniketa at nvidia.com; cjia at nvidia.com;
> kwankhede at nvidia.com; targupta at nvidia.com; vsethi at nvidia.com;
> acurrid at nvidia.com; apopple at nvidia.com; jhubbard at nvidia.com;
> danw at nvidia.com; mochs at nvidia.com; kvmarm at lists.linux.dev;
> kvm at vger.kernel.org; lpieralisi at kernel.org; linux-kernel at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_*
> and NORMAL_NC for IO memory
> 
> + Lorenzo, he really needs to be on this thread.
> 
> On Tue, Dec 05, 2023 at 09:21:28AM +0000, Marc Zyngier wrote:
> > On Tue, 05 Dec 2023 03:30:15 +0000,
> > <ankita at nvidia.com> wrote:
> > > From: Ankit Agrawal <ankita at nvidia.com>
> > >
> > > Currently, KVM for ARM64 maps at stage 2 memory that is considered
> device
> > > (i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting
> > > overrides (as per the ARM architecture [1]) any device MMIO mapping
> > > present at stage 1, resulting in a set-up whereby a guest operating
> > > system cannot determine device MMIO mapping memory attributes on
> its
> > > own but it is always overridden by the KVM stage 2 default.
> [...]
> > Despite the considerable increase in the commit message length, a
> > number of questions are left unanswered:
> >
> > - Shameer reported a regression on non-FWB systems, breaking device
> >   assignment:
> >
> >
> https://lore.kernel.org/all/af13ed63dc9a4f26a6c958ebfa77d78a at huawei.co
> m/
> 
> This referred to the first patch in the old series which was trying to
> make the Stage 2 cacheable based on the vma attributes. That patch has
> been dropped for now. It would be good if Shameer confirms this was the
> problem.
>

Yes, that was related to the first patch. We will soon test this on both FWB and
non-FWB platforms and report back.

Thanks,
Shameer



From wangkefeng.wang at huawei.com  Tue Dec  5 06:19:06 2023
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Tue, 5 Dec 2023 22:19:06 +0800
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <b8f5a47a-af1e-44ed-a89b-460d0be56d2c@huawei.com>



On 2023/12/4 18:20, Ryan Roberts wrote:
> Hi All,
> 
> A new week, a new version, a new name... This is v8 of a series to implement
> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
> this fares better.
> 
> The objective of this is to improve performance by allocating larger chunks of
> memory during anonymous page faults:
> 
> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>     pages, there are efficiency savings to be had; fewer page faults, batched PTE
>     and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>     overhead. This should benefit all architectures.
> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>     advantage of HW TLB compression techniques. A reduction in TLB pressure
>     speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>     TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
> 
> This version changes the name and tidies up some of the kernel code and test
> code, based on feedback against v7 (see change log for details).
> 
> By default, the existing behaviour (and performance) is maintained. The user
> must explicitly enable multi-size THP to see the performance benefit. This is
> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
> David for the suggestion)! This interface is inspired by the existing
> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
> compatibility with the existing PMD-size THP interface, and provides a base for
> future extensibility. See [8] for detailed discussion of the interface.
> 
> This series is based on mm-unstable (715b67adf4c8).
> 
> 
> Prerequisites
> =============
> 
> Some work items identified as being prerequisites are listed on page 3 at [9].
> The summary is:
> 
> | item                          | status                  |
> |:------------------------------|:------------------------|
> | mlock                         | In mainline (v6.7)      |
> | madvise                       | In mainline (v6.6)      |
> | compaction                    | v1 posted [10]          |
> | numa balancing                | Investigated: see below |
> | user-triggered page migration | In mainline (v6.7)      |
> | khugepaged collapse           | In mainline (NOP)       |
> 
> On NUMA balancing, which currently ignores any PTE-mapped THPs it encounters,
> John Hubbard has investigated this and concluded that it is A) not clear at the
> moment what a better policy might be for PTE-mapped THP and B) questions whether
> this should really be considered a prerequisite given no regression is caused
> for the default "multi-size THP disabled" case, and there is no correctness
> issue when it is enabled - its just a potential for non-optimal performance.
> 
> If there are no disagreements about removing numa balancing from the list (none
> were raised when I first posted this comment against v7), then that just leaves
> compaction which is in review on list at the moment.
> 
> I really would like to get this series (and its remaining comapction
> prerequisite) in for v6.8. I accept that it may be a bit optimistic at this
> point, but lets see where we get to with review?
> 
> 
> Testing
> =======
> 
> The series includes patches for mm selftests to enlighten the cow and khugepaged
> tests to explicitly test with multi-size THP, in the same way that PMD-sized
> THP is tested. The new tests all pass, and no regressions are observed in the mm
> selftest suite. I've also run my usual kernel compilation and java script
> benchmarks without any issues.
> 
> Refer to my performance numbers posted with v6 [6]. (These are for multi-size
> THP only - they do not include the arm64 contpte follow-on series).
> 
> John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
> some workloads at [11]. (Observed using v6 of this series as well as the arm64
> contpte series).
> 
> Kefeng Wang at Huawei has also indicated he sees improvements at [12] although
> there are some latency regressions also.

Hi Ryan,

Here is some test results based on v6.7-rc1 +
[PATCH v7 00/10] Small-sized THP for anonymous memory +
[PATCH v2 00/14] Transparent Contiguous PTEs for User Mappings

case1: basepage 64K
case2: basepage 4K + thp=64k + PAGE_ALLOC_COSTLY_ORDER = 3
case3: basepage 4K + thp=64k + PAGE_ALLOC_COSTLY_ORDER = 4

The results is compared with basepage 4K on Kunpeng920.

Note,
- The test based on ext4 filesystem and THP=2M is disabled.
- The results were not analyzed, it is for reference only,
   as some values of test items are not consistent.

1) Unixbench 1core
Index_Values_1core                       case1       case2    case3
Dhrystone_2_using_register_variables     0.28%      0.39%     0.17%
Double-Precision_Whetstone              -0.01%      0.00%     0.00%
Execl_Throughput                        *21.13%*    2.16%     3.01%
File_Copy_1024_bufsize_2000_maxblocks   -0.51%     *8.33%*   *8.76%*
File_Copy_256_bufsize_500_maxblocks      0.78%     *11.89%*  *10.85%*
File_Copy_4096_bufsize_8000_maxblocks    7.42%      7.27%    *10.66%*
Pipe_Throughput                         -0.24%     *6.82%*   *5.08%*
Pipe-based_Context_Switching             1.38%     *13.49%*  *9.91%*
Process_Creation                        *32.46%*    4.30%    *8.54%*
Shell_Scripts_(1_concurrent)            *31.67%*    1.92%     2.60%
Shell_Scripts_(8_concurrent)            *40.59%*    1.30%    *5.29%*
System_Call_Overhead                     3.92%     *8.13%     2.96%

System_Benchmarks_Index_Score           10.66%      5.39%     5.58%

For 1core,
- case1 wins on Execl_Throughput/Process_Creation/Shell_Scripts
   a lot, and score higher 10.66% vs basepage 4K.
- case2/3 wins on File_Copy/Pipe and score higher 5%+ than basepage 4K,
   also case3 looks better on Shell_Scripts_(8_concurrent) than case2.

2) Unixbench 128core
Index_Values_128core                    case1     case2     case3
Dhrystone_2_using_register_variables    2.07%    -0.03%    -0.11%
Double-Precision_Whetstone             -0.03%     0.00%    0.00%
Execl_Throughput                       *39.28%*  -4.23%    1.93%
File_Copy_1024_bufsize_2000_maxblocks   5.46%     1.30%    4.20%
File_Copy_256_bufsize_500_maxblocks    -8.89%    *6.56%   *5.02%*
File_Copy_4096_bufsize_8000_maxblocks   3.43%   *-5.46%*   0.56%
Pipe_Throughput                         3.80%    *7.69%   *7.80%*
Pipe-based_Context_Switching           *7.62%*    0.95%    4.69%
Process_Creation                       *28.11%*  -2.79%    2.40%
Shell_Scripts_(1_concurrent)           *39.68%*   1.86%   *5.30%*
Shell_Scripts_(8_concurrent)           *41.35%*   2.49%   *7.16%*
System_Call_Overhead                   -1.55%    -0.04%   *8.23%*

System_Benchmarks_Index_Score          12.08%     0.63%    3.88%

For 128core,
- case1 wins on Execl_Throughput/Process_Creation/Shell_Scripts
   a lot, also good at Pipe-based_Context_Switching, and score higher
   12.08% vs basepage 4K.
- case2/case3 wins on File_Copy_256/Pipe_Throughput, but case2 is
   not better than basepage 4K, case3 wins 3.88%.

3) Lmbench Processor_processes
Processor_Processes    case1      case2      case3
null_call              1.76%      0.40%     0.65%
null_io               -0.76%     -0.38%    -0.23%
stat                 *-16.09%*  *-12.49%*   4.22%
open_close            -2.69%      4.51%     3.21%
slct_TCP              -0.56%      0.00%    -0.44%
sig_inst              -1.54%      0.73%     0.70%
sig_hndl              -2.85%      0.01%     1.85%
fork_proc            *23.31%*     8.77%    -5.42%
exec_proc            *13.22%*    -0.30%     1.09%
sh_proc              *14.04%*    -0.10%     1.09%

- case1 is much better than basepage 4K, same as Unixbench test,
   case2 is better on fork_proc, but case3 is worse
- note: the variance of fork/exec/sh is bigger than others

4) Lmbench Context_switching_ctxsw
Context_switching_ctxsw  case1     case2         case3
2p/0K                   -12.16%    -5.29%       -1.86%
2p/16K                  -11.26%    -3.71%       -4.53%
2p/64K                  -2.60%      3.84%       -1.98%
8p/16K                  -7.56%     -1.21%       -0.88%
8p/64K                   5.10%      4.88%        1.19%
16p/16K                 -5.81%     -2.44%       -3.84%
16p/64K                  4.29%     -1.94%       -2.50%
- case1/2/3 worse than basepage 4K and case1 is the worst.

4) Lmbench Local_latencies
Local_latencies      case1      case2     case3
Pipe                -9.23%      0.58%    -4.34%
AF_UNIX             -5.34%     -1.76%     3.03%
UDP                 -6.70%     -5.96%    -9.81%
TCP                 -7.95%     -7.58%    -5.63%
TCP_conn            -213.99%   -227.78%  -659.67%
- TCP_conn is very unreliable, ignore it
- case1/2/3 slower than basepage 4K

5) Lmbench File_&_VM_latencies
File_&_VM_latencies    case1     case2        case3
10K_File_Create        2.60%    -0.52%         2.66%
10K_File_Delete       -2.91%    -5.20%        -2.11%
10K_File_Create       10.23%     1.18%         0.12%
10K_File_Delete      -17.76%    -2.97%        -1.49%
Mmap_Latency         *63.05%*    2.57%        -0.96%
Prot_Fault            10.41%    -3.21%       *-19.11%*
Page_Fault          *-132.01%*   2.35%        -0.79%
100fd_selct          -1.20%      0.10%         0.31%
- case1 is very good at Mmap_Latency and not good at Page_fault
- case2/3 slower on Prot_Faul/10K_FILE_Delete vs basepage 4k,
   the rest doesn't look much different.

6) Lmbench Local_bandwidths
Local_bandwidths    case1   case2       case3
Pipe               265.22%   15.44%     11.33%
AF_UNIX            13.41%   -2.66%      2.63%
TCP               -1.30%     25.90%     2.48%
File_reread        14.79%    31.52%    -14.16%
Mmap_reread        27.47%    49.00%    -0.11%
Bcopy(libc)        2.58%     2.45%      2.46%
Bcopy(hand)        25.78%    22.56%     22.68%
Mem_read           38.26%    36.80%     36.49%
Mem_write          10.93%    3.44%      3.12%

- case1 is very good at bandwidth, case2 is better than basepage 4k
   but lower than case1, case3 is bad at File_reread

7)Lmbench Memory_latencies
Memory_latencies    case1     case2     case3
L1_$                0.02%     0.00%    -0.03%
L2_$               -1.56%    -2.65%    -1.25%
Main_mem           50.82%     32.51%    33.47%
Rand_mem           15.29%    -8.79%    -8.80%

- case1 also good at Main/Rand mem access latencies,
- case2/case3 is better at Main_mem, but worse at Rand_mem.

Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>









From will at kernel.org  Tue Dec  5 06:21:28 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 5 Dec 2023 14:21:28 +0000
Subject: [PATCH v11 4/5] drivers/perf: add DesignWare PCIe PMU driver
In-Reply-To: <2d52f588-f584-4c01-8f41-227815a54e41@suswa.mountain>
References: <20231121013400.18367-5-xueshuai@linux.alibaba.com>
 <2d52f588-f584-4c01-8f41-227815a54e41@suswa.mountain>
Message-ID: <20231205142128.GA18450@willie-the-truck>

On Sat, Nov 25, 2023 at 10:06:39AM +0300, Dan Carpenter wrote:
> Hi Shuai,
> 
> kernel test robot noticed the following build warnings:
> 
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Shuai-Xue/docs-perf-Add-description-for-Synopsys-DesignWare-PCIe-PMU-driver/20231121-093713
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
> patch link:    https://lore.kernel.org/r/20231121013400.18367-5-xueshuai%40linux.alibaba.com
> patch subject: [PATCH v11 4/5] drivers/perf: add DesignWare PCIe PMU driver
> config: x86_64-randconfig-r071-20231123 (https://download.01.org/0day-ci/archive/20231124/202311241906.0ymlLjyo-lkp at intel.com/config)
> compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
> reproduce: (https://download.01.org/0day-ci/archive/20231124/202311241906.0ymlLjyo-lkp at intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp at intel.com>
> | Reported-by: Dan Carpenter <error27 at gmail.com>
> | Closes: https://lore.kernel.org/r/202311241906.0ymlLjyo-lkp at intel.com/
> 
> smatch warnings:
> drivers/perf/dwc_pcie_pmu.c:352 dwc_pcie_pmu_event_update() error: uninitialized symbol 'now'.
> 
> vim +/now +352 drivers/perf/dwc_pcie_pmu.c
> 
> 3481798a4ec51d1 Shuai Xue 2023-11-21  338  static void dwc_pcie_pmu_event_update(struct perf_event *event)
> 3481798a4ec51d1 Shuai Xue 2023-11-21  339  {
> 3481798a4ec51d1 Shuai Xue 2023-11-21  340  	struct hw_perf_event *hwc = &event->hw;
> 3481798a4ec51d1 Shuai Xue 2023-11-21  341  	enum dwc_pcie_event_type type = DWC_PCIE_EVENT_TYPE(event);
> 3481798a4ec51d1 Shuai Xue 2023-11-21  342  	u64 delta, prev, now;
> 3481798a4ec51d1 Shuai Xue 2023-11-21  343  
> 3481798a4ec51d1 Shuai Xue 2023-11-21  344  	do {
> 3481798a4ec51d1 Shuai Xue 2023-11-21  345  		prev = local64_read(&hwc->prev_count);
> 3481798a4ec51d1 Shuai Xue 2023-11-21  346  
> 3481798a4ec51d1 Shuai Xue 2023-11-21  347  		if (type == DWC_PCIE_LANE_EVENT)
> 3481798a4ec51d1 Shuai Xue 2023-11-21  348  			now = dwc_pcie_pmu_read_lane_event_counter(event);
> 3481798a4ec51d1 Shuai Xue 2023-11-21  349  		else if (type == DWC_PCIE_TIME_BASE_EVENT)
> 3481798a4ec51d1 Shuai Xue 2023-11-21  350  			now = dwc_pcie_pmu_read_time_based_counter(event);
> 
> uninitialized on else path.
> 
> 3481798a4ec51d1 Shuai Xue 2023-11-21  351  
> 3481798a4ec51d1 Shuai Xue 2023-11-21 @352  	} while (local64_cmpxchg(&hwc->prev_count, prev, now) != prev);

Shuai, any chance you can address this please? I think the event validation
logic means that the type is only ever one of the cases you handle, so
you probably just want to either initialise 'now' to 0 or WARN and return
early if the type is unknown.

Will


From broonie at kernel.org  Tue Dec  5 06:24:44 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 14:24:44 +0000
Subject: [PATCH] kselftest/arm64: Log SVCR when the SME tests barf
Message-ID: <20231205-arm64-kselftest-log-svcr-v1-1-b77abd9ee7f3@kernel.org>

On failure we log the actual and expected value of the register we detect
a mismatch in. For SME one obvious potential source of corruption would be
if we had corrupted SVCR since changes in streaming mode will reset the
register values, log the value to aid in understanding issues.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 tools/testing/selftests/arm64/fp/sve-test.S | 10 ++++++++++
 tools/testing/selftests/arm64/fp/za-test.S  |  6 ++++++
 tools/testing/selftests/arm64/fp/zt-test.S  |  5 +++++
 3 files changed, 21 insertions(+)

diff --git a/tools/testing/selftests/arm64/fp/sve-test.S b/tools/testing/selftests/arm64/fp/sve-test.S
index 547d077e3517..fff60e2a25ad 100644
--- a/tools/testing/selftests/arm64/fp/sve-test.S
+++ b/tools/testing/selftests/arm64/fp/sve-test.S
@@ -515,6 +515,10 @@ function barf
 	mov	x11, x1	// actual data
 	mov	x12, x2	// data size
 
+#ifdef SSVE
+	mrs	x13, S3_3_C4_C2_2
+#endif
+
 	puts	"Mismatch: PID="
 	mov	x0, x20
 	bl	putdec
@@ -534,6 +538,12 @@ function barf
 	bl	dumphex
 	puts	"]\n"
 
+#ifdef SSVE
+	puts	"\tSVCR: "
+	mov	x0, x13
+	bl	putdecn
+#endif
+
 	mov	x8, #__NR_getpid
 	svc	#0
 // fpsimd.c acitivty log dump hack
diff --git a/tools/testing/selftests/arm64/fp/za-test.S b/tools/testing/selftests/arm64/fp/za-test.S
index 9dcd70911397..095b45531640 100644
--- a/tools/testing/selftests/arm64/fp/za-test.S
+++ b/tools/testing/selftests/arm64/fp/za-test.S
@@ -333,6 +333,9 @@ function barf
 //	mov	w8, #__NR_exit
 //	svc	#0
 // end hack
+
+	mrs	x13, S3_3_C4_C2_2
+
 	smstop
 	mov	x10, x0	// expected data
 	mov	x11, x1	// actual data
@@ -356,6 +359,9 @@ function barf
 	mov	x1, x12
 	bl	dumphex
 	puts	"]\n"
+	puts	"\tSVCR: "
+	mov	x0, x13
+	bl	putdecn
 
 	mov	x8, #__NR_getpid
 	svc	#0
diff --git a/tools/testing/selftests/arm64/fp/zt-test.S b/tools/testing/selftests/arm64/fp/zt-test.S
index d63286397638..b5c81e81a379 100644
--- a/tools/testing/selftests/arm64/fp/zt-test.S
+++ b/tools/testing/selftests/arm64/fp/zt-test.S
@@ -267,6 +267,8 @@ function barf
 //	mov	w8, #__NR_exit
 //	svc	#0
 // end hack
+
+	mrs	x13, S3_3_C4_C2_2
 	smstop
 	mov	x10, x0	// expected data
 	mov	x11, x1	// actual data
@@ -287,6 +289,9 @@ function barf
 	mov	x1, x12
 	bl	dumphex
 	puts	"]\n"
+	puts	"\tSVCR: "
+	mov	x0, x13
+	bl	putdecn
 
 	mov	x8, #__NR_getpid
 	svc	#0

---
base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab
change-id: 20231204-arm64-kselftest-log-svcr-372a210520ae

Best regards,
-- 
Mark Brown <broonie at kernel.org>



From jgg at nvidia.com  Tue Dec  5 06:35:26 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 10:35:26 -0400
Subject: [PATCH v2 07/19] iommu/arm-smmu-v3: Move the STE generation for
 S1 and S2 domains into functions
In-Reply-To: <ZW6C9yepEVC1amuu@Asurada-Nvidia>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <7-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <ZW6C9yepEVC1amuu@Asurada-Nvidia>
Message-ID: <20231205143526.GA2787277@nvidia.com>

On Mon, Dec 04, 2023 at 05:55:03PM -0800, Nicolin Chen wrote:
> On Mon, Nov 13, 2023 at 01:53:14PM -0400, Jason Gunthorpe wrote:
> > This is preparation to move the STE calculation higher up in to the call
> > chain and remove arm_smmu_write_strtab_ent(). These new functions will be
> > called directly from attach_dev.
> > 
> > Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
> 
> > +static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
> > +				      struct arm_smmu_master *master,
> > +				      struct arm_smmu_ctx_desc_cfg *cd_table)
> > +{
> > +	struct arm_smmu_device *smmu = master->smmu;
> > +
> > +	memset(target, 0, sizeof(*target));
> > +	target->data[0] = cpu_to_le64(
> 
> Nit: can add a line in-between like arm_smmu_make_s2_domain_ste does?

I removed the line since the arm_smmu_make_abort_ste/bypass functions
also had no line

Thanks,
Jason


From hugo at hugovil.com  Tue Dec  5 06:36:51 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Tue, 5 Dec 2023 09:36:51 -0500
Subject: [PATCH v4 3/3] arm64: dts: freescale: introduce rve-gateway
 board
In-Reply-To: <20231205122756.GE236001@dragon>
References: <20231103142831.2116163-1-hugo@hugovil.com>
	<20231103142831.2116163-4-hugo@hugovil.com>
	<20231205122756.GE236001@dragon>
Message-ID: <20231205093651.9d0cb90acad8668e004398f1@hugovil.com>

On Tue, 5 Dec 2023 20:27:56 +0800
Shawn Guo <shawnguo at kernel.org> wrote:

> On Fri, Nov 03, 2023 at 10:28:31AM -0400, Hugo Villeneuve wrote:
> > From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> > 
> > The RVE gateway board is based on a Variscite VAR-SOM-NANO,
> > with a NXP MX8MN nano CPU.
> > 
> > Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> > ---
> >  arch/arm64/boot/dts/freescale/Makefile        |   1 +
> >  .../boot/dts/freescale/imx8mn-rve-gateway.dts | 282 ++++++++++++++++++
> >  2 files changed, 283 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts
> > 
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> > index 300049037eb0..c99da779ef7b 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mn-bsh-smm-s2pro.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr3l-evk.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
> > +dtb-$(CONFIG_ARCH_MXC) += imx8mn-rve-gateway.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mn-tqma8mqnl-mba8mx.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mn-var-som-symphony.dtb
> >  dtb-$(CONFIG_ARCH_MXC) += imx8mn-venice-gw7902.dtb
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts b/arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts
> > new file mode 100644
> > index 000000000000..186f54fd06c6
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts
> > @@ -0,0 +1,282 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2023 DimOnOff
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/usb/pd.h>
> > +#include "imx8mn-var-som.dtsi"
> > +
> > +/ {
> > +	model = "RVE gateway";
> > +	compatible = "rve,rve-gateway", "variscite,var-som-mx8mn", "fsl,imx8mn";
> > +
> > +	crystal_duart_24m: crystal-duart-24m {
> > +		compatible = "fixed-clock";
> > +		#clock-cells = <0>;
> > +		clock-frequency = <24000000>;
> > +	};
> > +
> > +	gpio-keys {
> > +		compatible = "gpio-keys";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_gpio_keys>;
> > +
> > +		key-enter {
> > +			label = "enter";
> > +			gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
> > +			linux,code = <KEY_ENTER>;
> > +		};
> > +
> > +		key-exit {
> > +			label = "exit";
> > +			gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
> > +			linux,code = <KEY_ESC>;
> > +		};
> > +	};
> > +
> > +	lcd {
> > +		compatible = "hit,hd44780";
> > +		display-height-chars = <2>;
> > +		display-width-chars = <20>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_lcd>;
> > +		data-gpios = <&gpio5  1 GPIO_ACTIVE_HIGH>,
> > +			     <&gpio1  6 GPIO_ACTIVE_HIGH>,
> > +			     <&gpio1 14 GPIO_ACTIVE_HIGH>,
> > +			     <&gpio4 28 GPIO_ACTIVE_HIGH>,
> > +			     <&gpio5 24 GPIO_ACTIVE_HIGH>,
> > +			     <&gpio5  2 GPIO_ACTIVE_HIGH>,
> > +			     <&gpio1 12 GPIO_ACTIVE_HIGH>,
> > +			     <&gpio5 25 GPIO_ACTIVE_HIGH>;
> > +		enable-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
> > +		rs-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> > +		rw-gpios = <&gpio4 27 GPIO_ACTIVE_HIGH>;
> > +	};
> > +
> > +	reg_3p3v: regulator-3p3v {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "3P3V";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		regulator-always-on;
> > +	};
> > +
> > +	/* Bourns PEC12R rotary encoder, 24 steps. */
> > +	rotary: rotary-encoder {
> > +		compatible = "rotary-encoder";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_rotary>;
> > +		gpios = <&gpio1  5 GPIO_ACTIVE_LOW>, /* A */
> > +			<&gpio3 21 GPIO_ACTIVE_LOW>; /* B */
> > +		linux,axis = <0>; /* REL_X */
> > +		rotary-encoder,encoding = "gray";
> > +		rotary-encoder,relative-axis;
> > +	};
> > +};
> > +
> > +&ecspi1 {
> > +	cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
> > +
> > +	duart1: serial at 0 {
> > +		compatible = "nxp,sc16is752";
> > +		reg = <0>;
> > +		spi-rx-bus-width = <1>;
> > +		spi-tx-bus-width = <1>;
> > +		spi-max-frequency = <4000000>;
> > +		clocks = <&crystal_duart_24m>;
> > +		interrupt-parent = <&gpio3>;
> > +		interrupts = <22 IRQ_TYPE_EDGE_FALLING>;
> > +		gpio-controller;
> > +		#gpio-cells = <2>;
> > +		gpio-line-names = "RADIO0", "RADIO1", "RADIO2", "RADIO3",
> > +		"RADIO4", "RADIO_RESET", "TP12", "TP11";
> 
> Can we add some indent to get the line aligned with the first " above?
> There are a few such lines that could be improved.

Hi,
Sure, will do for V5.

Hugo.


> 
> Shawn
> 
> > +		linux,rs485-enabled-at-boot-time;
> > +		rs485-rts-active-low;
> > +	};
> > +
> > +	/delete-node/ touchscreen at 0;
> > +};
> > +
> > +&ecspi2 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_ecspi2>;
> > +	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
> > +	/delete-property/ dmas;
> > +	/delete-property/ dma-names;
> > +	status = "okay";
> > +
> > +	duart2: serial at 0 {
> > +		compatible = "nxp,sc16is752";
> > +		reg = <0>;
> > +		spi-rx-bus-width = <1>;
> > +		spi-tx-bus-width = <1>;
> > +		spi-max-frequency = <4000000>;
> > +		clocks = <&crystal_duart_24m>;
> > +		interrupt-parent = <&gpio3>;
> > +		interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
> > +		gpio-controller;
> > +		#gpio-cells = <2>;
> > +		gpio-line-names = "LED_B_USER", "LED_R_USER", "LED_G_USER",
> > +		"GPIO_EXT3", "GPIO_EXT2", "GPIO_EXT1", "GPIO_EXT0", "TP13";
> > +		linux,rs485-enabled-at-boot-time;
> > +		rs485-rts-active-low;
> > +	};
> > +};
> > +
> > +/* Configure PWM pins in GPIO mode: */
> > +&gpio5 {
> > +	gpio-line-names = "", "", "", "PWM3", "PWM2", "PWM1";
> > +};
> > +
> > +&gpu {
> > +	status = "disabled";
> > +};
> > +
> > +&i2c2 {
> > +	clock-frequency = <400000>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_i2c2>;
> > +	status = "okay";
> > +
> > +	/* Carrier board EEPROM */
> > +	eeprom_cb: eeprom at 56 {
> > +		compatible = "atmel,24c04";
> > +		reg = <0x56>;
> > +		pagesize = <16>;
> > +		vcc-supply = <&reg_3p3v>;
> > +	};
> > +
> > +	lm75: sensor at 48 {
> > +		compatible = "st,stlm75";
> > +		reg = <0x48>;
> > +		vs-supply = <&reg_3p3v>;
> > +	};
> > +
> > +	mcp7940: rtc at 6f {
> > +		compatible = "microchip,mcp7940x";
> > +		reg = <0x6f>;
> > +	};
> > +};
> > +
> > +&i2c3 {
> > +	codec at 1a {
> > +		status = "disabled";
> > +	};
> > +};
> > +
> > +&i2c4 {
> > +	clock-frequency = <400000>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_i2c4>;
> > +	status = "okay";
> > +
> > +	pcf8574_1: gpio at 38 {
> > +		compatible = "nxp,pcf8574";
> > +		reg = <0x38>;
> > +		gpio-controller;
> > +		#gpio-cells = <2>;
> > +		gpio-line-names = "LED_B_COMM3", "LED_R_COMM3", "LED_G_COMM3",
> > +		"TP14", "TP15", "LED_G_COMM4", "LED_R_COMM4", "LED_B_COMM4";
> > +	};
> > +
> > +	pcf8574_2: gpio at 39 {
> > +		compatible = "nxp,pcf8574";
> > +		reg = <0x39>;
> > +		gpio-controller;
> > +		#gpio-cells = <2>;
> > +		gpio-line-names = "LED_B_COMM2", "LED_G_COMM2", "LED_B_COMM1",
> > +		"LED_R_COMM2", "LED_R_COMM1", "LED_G_COMM1", "TP16", "TP17";
> > +	};
> > +};
> > +
> > +/* Bluetooth */
> > +&uart2 {
> > +	status = "disabled";
> > +};
> > +
> > +&usbotg1 {
> > +	dr_mode = "host";
> > +	disable-over-current;
> > +	status = "okay";
> > +};
> > +
> > +/* SD interface on expansion connector. */
> > +&usdhc2 {
> > +	vmmc-supply = <&reg_3p3v>;
> > +	cd-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
> > +};
> > +
> > +&iomuxc {
> > +	pinctrl_ecspi1: ecspi1grp {
> > +		fsl,pins = <
> > +			MX8MN_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK	0x13
> > +			MX8MN_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI	0x13
> > +			MX8MN_IOMUXC_ECSPI1_MISO_ECSPI1_MISO	0x13
> > +			MX8MN_IOMUXC_ECSPI1_SS0_GPIO5_IO9	0x13 /* SS0 */
> > +			MX8MN_IOMUXC_SAI5_RXD1_GPIO3_IO22	0x13 /* SC16 IRQ */
> > +		>;
> > +	};
> > +
> > +	pinctrl_ecspi2: ecspi2grp {
> > +		fsl,pins = <
> > +			MX8MN_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK	0x13
> > +			MX8MN_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI	0x13
> > +			MX8MN_IOMUXC_ECSPI2_MISO_ECSPI2_MISO	0x13
> > +			MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13	0x13 /* SS0 */
> > +			MX8MN_IOMUXC_SAI5_RXC_GPIO3_IO20	0x13 /* SC16 IRQ */
> > +		>;
> > +	};
> > +
> > +	pinctrl_gpio_keys: gpiokeysgrp {
> > +		fsl,pins = <
> > +			MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1	0xc6 /* Enter */
> > +			MX8MN_IOMUXC_SAI5_RXD2_GPIO3_IO23	0xc6 /* Exit */
> > +		>;
> > +	};
> > +
> > +	pinctrl_i2c2: i2c2grp {
> > +		fsl,pins = <
> > +			MX8MN_IOMUXC_I2C2_SCL_I2C2_SCL		0x400001c3
> > +			MX8MN_IOMUXC_I2C2_SDA_I2C2_SDA		0x400001c3
> > +		>;
> > +	};
> > +
> > +	pinctrl_i2c4: i2c4grp {
> > +		fsl,pins = <
> > +			MX8MN_IOMUXC_I2C4_SCL_I2C4_SCL		0x400001c3
> > +			MX8MN_IOMUXC_I2C4_SDA_I2C4_SDA		0x400001c3
> > +		>;
> > +	};
> > +
> > +	pinctrl_lcd: lcdgrp {
> > +		fsl,pins = <
> > +			MX8MN_IOMUXC_SAI3_TXD_GPIO5_IO1		0x00000156 /* D0 */
> > +			MX8MN_IOMUXC_GPIO1_IO06_GPIO1_IO6	0x00000156 /* D1 */
> > +			MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14	0x00000156 /* D2 */
> > +			MX8MN_IOMUXC_SAI3_RXFS_GPIO4_IO28	0x00000156 /* D3 */
> > +			MX8MN_IOMUXC_UART2_RXD_GPIO5_IO24	0x00000156 /* D4 */
> > +			MX8MN_IOMUXC_SAI3_MCLK_GPIO5_IO2	0x00000156 /* D5 */
> > +			MX8MN_IOMUXC_GPIO1_IO12_GPIO1_IO12	0x00000156 /* D6 */
> > +			MX8MN_IOMUXC_UART2_TXD_GPIO5_IO25	0x00000156 /* D7 */
> > +			MX8MN_IOMUXC_UART1_TXD_GPIO5_IO23	0x00000156 /* E */
> > +			MX8MN_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x00000156 /* RS */
> > +			MX8MN_IOMUXC_SAI2_MCLK_GPIO4_IO27	0x00000156 /* R/W */
> > +		>;
> > +	};
> > +
> > +	pinctrl_rotary: rotarygrp {
> > +		fsl,pins = <
> > +			MX8MN_IOMUXC_GPIO1_IO05_GPIO1_IO5	0x00000156 /* A */
> > +			MX8MN_IOMUXC_SAI5_RXD0_GPIO3_IO21	0x00000156 /* B */
> > +		>;
> > +	};
> > +
> > +	/* Override Card Detect function GPIO value (GPIO1_IO10) from SOM: */
> > +	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
> > +		fsl,pins = <
> > +			MX8MN_IOMUXC_GPIO1_IO13_GPIO1_IO13	0x41
> > +		>;
> > +	};
> > +};
> > -- 
> > 2.39.2
> > 


-- 
Hugo Villeneuve


From lpieralisi at kernel.org  Tue Dec  5 06:37:13 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Tue, 5 Dec 2023 15:37:13 +0100
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231205130517.GD2692119@nvidia.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
Message-ID: <ZW81mT4WqKqtLnid@lpieralisi>

On Tue, Dec 05, 2023 at 09:05:17AM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 05, 2023 at 11:40:47AM +0000, Catalin Marinas wrote:
> > > - Will had unanswered questions in another part of the thread:
> > > 
> > >   https://lore.kernel.org/all/20231013092954.GB13524 at willie-the-truck/
> > > 
> > >   Can someone please help concluding it?
> > 
> > Is this about reclaiming the device? I think we concluded that we can't
> > generalise this beyond PCIe, though not sure there was any formal
> > statement to that thread. The other point Will had was around stating
> > in the commit message why we only relax this to Normal NC. I haven't
> > checked the commit message yet, it needs careful reading ;).
> 
> Not quite, we said reclaiming is VFIO's problem and if VFIO can't
> reliably reclaim a device it shouldn't create it in the first place.

I think that as far as device reclaiming was concerned the question
posed was related to memory attributes of transactions for guest
mappings and the related grouping/ordering with device reset MMIO
transactions - it was not (or wasn't only) about error containment.

Thanks,
Lorenzo


From jgg at nvidia.com  Tue Dec  5 06:37:42 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 10:37:42 -0400
Subject: [PATCH v2 15/19] iommu/arm-smmu-v3: Add a global static IDENTITY
 domain
In-Reply-To: <ZW6m54yS2rpk65kE@Asurada-Nvidia>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <15-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <ZW6m54yS2rpk65kE@Asurada-Nvidia>
Message-ID: <20231205143742.GB2787277@nvidia.com>

On Mon, Dec 04, 2023 at 08:28:23PM -0800, Nicolin Chen wrote:

> > +static int arm_smmu_attach_dev_ste(struct device *dev,
> > +				   struct arm_smmu_ste *ste)
> > +{
> > +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > +
> > +	if (arm_smmu_master_sva_enabled(master))
> > +		return -EBUSY;
> > +
> > +	/*
> > +	 * Do not allow any ASID to be changed while are working on the STE,
> > +	 * otherwise we could miss invalidations.
> > +	 */
> > +	mutex_lock(&arm_smmu_asid_lock);
> > +
> > +	/*
> > +	 * The SMMU does not support enabling ATS with bypass/abort. When the
> > +	 * STE is in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests
> > +	 * and Translated transactions are denied as though ATS is disabled for
> > +	 * the stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
> > +	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
> > +	 */
> > +	arm_smmu_detach_dev(master);
> > +
> > +	arm_smmu_install_ste_for_dev(master, ste);
> > +	mutex_unlock(&arm_smmu_asid_lock);
> > +
> > +	/*
> > +	 * This has to be done after removing the master from the
> > +	 * arm_smmu_domain->devices to avoid races updating the same context
> > +	 * descriptor from arm_smmu_share_asid().
> > +	 */
> > +	if (master->cd_table.cdtab)
> > +		arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);
>  
> This arm_smmu_write_ctx_desc was previously within the asid lock
> protection, yet now it's moved out of that?

Yes, arm_smmu_write_ctx_desc() updates a CD table entry and that does
not need ASID lock protection. The ASID lock exists because of the BTM
code rewriting STEs asyncronously.

Jason


From harry.wentland at amd.com  Tue Dec  5 06:41:29 2023
From: harry.wentland at amd.com (Harry Wentland)
Date: Tue, 5 Dec 2023 09:41:29 -0500
Subject: [PATCH v2 2/8] drm/amdgpu: Do not include
 <drm/drm_plane_helper.h>
In-Reply-To: <20231204090852.1650-3-tzimmermann@suse.de>
References: <20231204090852.1650-1-tzimmermann@suse.de>
 <20231204090852.1650-3-tzimmermann@suse.de>
Message-ID: <f339bfd5-8748-464a-b6ca-188778ed4371@amd.com>

On 2023-12-04 04:07, Thomas Zimmermann wrote:
> Remove unnecessary include statements for <drm/drm_plane_helper.h>.
> The file contains helpers for non-atomic code and should not be
> required by most drivers. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>

Reviewed-by: Harry Wentland <harry.wentland at amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index aa43f1761acd3..b8c3a9b104a41 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -92,7 +92,6 @@
>  #include <drm/drm_vblank.h>
>  #include <drm/drm_audio_component.h>
>  #include <drm/drm_gem_atomic_helper.h>
> -#include <drm/drm_plane_helper.h>
>  
>  #include <acpi/video.h>
>  



From yoong.siang.song at intel.com  Tue Dec  5 06:43:31 2023
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Tue, 5 Dec 2023 14:43:31 +0000
Subject: [PATCH bpf-next v2 2/3] net: stmmac: Add txtime support to XDP ZC
In-Reply-To: <656de8eb14c24_2e983e29435@willemb.c.googlers.com.notmuch>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <20231201062421.1074768-3-yoong.siang.song@intel.com>
 <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org>
 <PH0PR11MB5830F08AC202C42501D986C0D887A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <656de8eb14c24_2e983e29435@willemb.c.googlers.com.notmuch>
Message-ID: <PH0PR11MB58305C7D394FD264F1634819D885A@PH0PR11MB5830.namprd11.prod.outlook.com>

On Monday, December 4, 2023 10:58 PM, Willem de Bruijn wrote:
>Song, Yoong Siang wrote:
>> On Friday, December 1, 2023 11:02 PM, Jesper Dangaard Brouer wrote:
>> >On 12/1/23 07:24, Song Yoong Siang wrote:
>> >> This patch enables txtime support to XDP zero copy via XDP Tx
>> >> metadata framework.
>> >>
>> >> Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
>> >> ---
>> >>   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
>> >>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++
>> >>   2 files changed, 15 insertions(+)
>> >
>> >I think we need to see other drivers using this new feature to evaluate
>> >if API is sane.
>> >
>> >I suggest implementing this for igc driver (chip i225) and also for igb
>> >(i210 chip) that both support this kind of LaunchTime feature in HW.
>> >
>> >The API and stmmac driver takes a u64 as time.
>> >I'm wondering how this applies to i210 that[1] have 25-bit for
>> >LaunchTime (with 32 nanosec granularity) limiting LaunchTime max 0.5
>> >second into the future.
>> >And i225 that [1] have 30-bit max 1 second into the future.
>> >
>> >
>> >[1]
>> >https://github.com/xdp-project/xdp-
>> >project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org
>>
>> I am using u64 for launch time because existing EDT framework is using it.
>> Refer to struct sk_buff below. Both u64 and ktime_t can be used as launch time.
>> I choose u64 because ktime_t often requires additional type conversion and
>> we didn't expect negative value of time.
>>
>> include/linux/skbuff.h-744- *   @tstamp: Time we arrived/left
>> include/linux/skbuff.h:745- *   @skb_mstamp_ns: (aka @tstamp) earliest departure
>time; start point
>> include/linux/skbuff.h-746- *           for retransmit timer
>> --
>> include/linux/skbuff.h-880-     union {
>> include/linux/skbuff.h-881-             ktime_t         tstamp;
>> include/linux/skbuff.h:882-             u64             skb_mstamp_ns; /* earliest departure
>time */
>> include/linux/skbuff.h-883-     };
>>
>> tstamp/skb_mstamp_ns are used by various drivers for launch time support
>> on normal packet, so I think u64 should be "friendly" to all the drivers. For an
>> example, igc driver will take launch time from tstamp and recalculate it
>> accordingly (i225 expect user to program "delta time" instead of "time" into
>> HW register).
>>
>> drivers/net/ethernet/intel/igc/igc_main.c-1602- txtime = skb->tstamp;
>> drivers/net/ethernet/intel/igc/igc_main.c-1603- skb->tstamp = ktime_set(0, 0);
>> drivers/net/ethernet/intel/igc/igc_main.c:1604- launch_time =
>igc_tx_launchtime(tx_ring, txtime, &first_flag, &insert_empty);
>>
>> Do you think this is enough to say the API is sane?
>
>u64 nsec sounds sane to be. It must be made explicit with clock source
>it is against.
>

The u64 launch time should base on NIC PTP hardware clock (PHC).
I will add documentation saying which clock source it is against

>Some applications could want to do the conversion from a clock source
>to raw NIC cycle counter in userspace or BPF and program the raw
>value. So it may be worthwhile to add an clock source argument -- even
>if initially only CLOCK_MONOTONIC is supported.

Sorry, not so understand your suggestion on adding clock source argument.
Are you suggesting to add clock source for the selftest xdp_hw_metadata apps?
IMHO, no need to add clock source as the clock source for launch time
should always base on NIC PHC.

>
>See tools/testing/selftests/net/so_txtime.sh for how the FQ and ETF
>qdiscs already disagree on the clock source that they use.
>


 

From jgg at nvidia.com  Tue Dec  5 06:44:17 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 10:44:17 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZW81mT4WqKqtLnid@lpieralisi>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW81mT4WqKqtLnid@lpieralisi>
Message-ID: <20231205144417.GE2692119@nvidia.com>

On Tue, Dec 05, 2023 at 03:37:13PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Dec 05, 2023 at 09:05:17AM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 05, 2023 at 11:40:47AM +0000, Catalin Marinas wrote:
> > > > - Will had unanswered questions in another part of the thread:
> > > > 
> > > >   https://lore.kernel.org/all/20231013092954.GB13524 at willie-the-truck/
> > > > 
> > > >   Can someone please help concluding it?
> > > 
> > > Is this about reclaiming the device? I think we concluded that we can't
> > > generalise this beyond PCIe, though not sure there was any formal
> > > statement to that thread. The other point Will had was around stating
> > > in the commit message why we only relax this to Normal NC. I haven't
> > > checked the commit message yet, it needs careful reading ;).
> > 
> > Not quite, we said reclaiming is VFIO's problem and if VFIO can't
> > reliably reclaim a device it shouldn't create it in the first place.
> 
> I think that as far as device reclaiming was concerned the question
> posed was related to memory attributes of transactions for guest
> mappings and the related grouping/ordering with device reset MMIO
> transactions - it was not (or wasn't only) about error containment.

Yes. It is VFIO that issues the reset, it is VFIO that must provide
the ordering under the assumption that NORMAL_NC was used.

Jason


From festevam at gmail.com  Tue Dec  5 06:47:12 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue,  5 Dec 2023 11:47:12 -0300
Subject: [PATCH 1/2] ARM: mxs: Do not search for "fsl,clkctrl"
Message-ID: <20231205144713.2053916-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The "fsl,clkctrl" compatible string is not documented.

It is used only to find the base address of the clock controller.

Instead of searching for an undocumented compatible string, search
for "fsl,imx23-clkctrl" and "fsl,imx28-clkctrl".

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/mach-mxs/mach-mxs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index 3faf9a1e3e36..6e017fa306c8 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -356,7 +356,9 @@ static int __init mxs_restart_init(void)
 {
 	struct device_node *np;
 
-	np = of_find_compatible_node(NULL, NULL, "fsl,clkctrl");
+	np = of_find_compatible_node(NULL, NULL, "fsl,imx23-clkctrl");
+	if (!np)
+		np = of_find_compatible_node(NULL, NULL, "fsl,imx28-clkctrl");
 	reset_addr = of_iomap(np, 0);
 	if (!reset_addr)
 		return -ENODEV;
-- 
2.34.1



From festevam at gmail.com  Tue Dec  5 06:47:13 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue,  5 Dec 2023 11:47:13 -0300
Subject: [PATCH 2/2] ARM: dts: imx23/28: Remove undocumented "fsl,clkctrl"
In-Reply-To: <20231205144713.2053916-1-festevam@gmail.com>
References: <20231205144713.2053916-1-festevam@gmail.com>
Message-ID: <20231205144713.2053916-2-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per imx23-clock.yaml and imx28-clock.yaml, fsl,clkctrl is not a valid
compatible string.

Remove it to fix the following dt-schema warning:

imx28-evk.dtb: clkctrl at 80040000: compatible: ['fsl,imx28-clkctrl', 'fsl,clkctrl'] is too long
	from schema $id: http://devicetree.org/schemas/clock/imx28-clock.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/mxs/imx23.dtsi | 2 +-
 arch/arm/boot/dts/nxp/mxs/imx28.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/mxs/imx23.dtsi b/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
index fdf18b7cb2f6..69e65e218afe 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
+++ b/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
@@ -484,7 +484,7 @@ apbx at 80040000 {
 			ranges;
 
 			clks: clkctrl at 80040000 {
-				compatible = "fsl,imx23-clkctrl", "fsl,clkctrl";
+				compatible = "fsl,imx23-clkctrl";
 				reg = <0x80040000 0x2000>;
 				#clock-cells = <1>;
 			};
diff --git a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
index 6932d23fb29d..39b59619eb2e 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
+++ b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
@@ -1100,7 +1100,7 @@ apbx at 80040000 {
 			ranges;
 
 			clks: clkctrl at 80040000 {
-				compatible = "fsl,imx28-clkctrl", "fsl,clkctrl";
+				compatible = "fsl,imx28-clkctrl";
 				reg = <0x80040000 0x2000>;
 				#clock-cells = <1>;
 			};
-- 
2.34.1



From jgg at nvidia.com  Tue Dec  5 06:48:57 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 10:48:57 -0400
Subject: [PATCH v2 10/27] iommu/arm-smmu-v3: Move the CD generation for
 SVA into a function
In-Reply-To: <ZW6S8CPK5UQ1mYpa@Asurada-Nvidia>
References: <0-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
 <10-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
 <ZW6S8CPK5UQ1mYpa@Asurada-Nvidia>
Message-ID: <20231205144857.GC2787277@nvidia.com>

On Mon, Dec 04, 2023 at 07:03:12PM -0800, Nicolin Chen wrote:
> On Wed, Nov 01, 2023 at 08:36:28PM -0300, Jason Gunthorpe wrote:
> > Pull all the calculations for building the CD table entry for a mmu_struct
> > into arm_smmu_make_sva_cd().
> > 
> > Call it in the two places installing the SVA CD table entry.
> > 
> > Open code the last caller of arm_smmu_update_ctx_desc_devices() and remove
> > the function.
> > 
> > Remove arm_smmu_write_ctx_desc() since all callers are gone.
> 
> It seems that there are still two lines of comments mentioning
> arm_smmu_write_ctx_desc that should be removed or updated too?

Yes, like this then:

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 50911116460669..824e725f905d71 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1109,7 +1109,7 @@ static void arm_smmu_write_cd_l1_desc(__le64 *dst,
 	u64 val = (l1_desc->l2ptr_dma & CTXDESC_L1_DESC_L2PTR_MASK) |
 		  CTXDESC_L1_DESC_V;
 
-	/* See comment in arm_smmu_write_ctx_desc() */
+	/* The HW has 64 bit atomicity with stores to the L2 CD table */
 	WRITE_ONCE(*dst, cpu_to_le64(val));
 }
 
@@ -1343,7 +1343,7 @@ arm_smmu_write_strtab_l1_desc(__le64 *dst, struct arm_smmu_strtab_l1_desc *desc)
 	val |= FIELD_PREP(STRTAB_L1_DESC_SPAN, desc->span);
 	val |= desc->l2ptr_dma & STRTAB_L1_DESC_L2PTR_MASK;
 
-	/* See comment in arm_smmu_write_ctx_desc() */
+	/* The HW has 64 bit atomicity with stores to the L2 STE table */
 	WRITE_ONCE(*dst, cpu_to_le64(val));
 }
 
Thanks,
Jason


From festevam at gmail.com  Tue Dec  5 06:53:35 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue,  5 Dec 2023 11:53:35 -0300
Subject: [PATCH] ARM: dts: imx28-tx28: Pass #sound-dai-cells
Message-ID: <20231205145335.2055549-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per sgtl5000.yaml, '#sound-dai-cells' is a required property.

Pass it to fix the following dt-schema warning:

imx28-tx28.dtb: sgtl5000 at a: '#sound-dai-cells' is a required property
	from schema $id: http://devicetree.org/schemas/sound/sgtl5000.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts b/arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts
index 153e4017951d..5485fe118dc4 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts
+++ b/arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts
@@ -260,6 +260,7 @@ &i2c0 {
 	sgtl5000: sgtl5000 at a {
 		compatible = "fsl,sgtl5000";
 		reg = <0x0a>;
+		#sound-dai-cells = <0>;
 		VDDA-supply = <&reg_2p5v>;
 		VDDIO-supply = <&reg_3p3v>;
 		clocks = <&mclk>;
-- 
2.34.1



From yoong.siang.song at intel.com  Tue Dec  5 06:55:17 2023
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Tue, 5 Dec 2023 14:55:17 +0000
Subject: [xdp-hints] Re: [PATCH bpf-next v3 3/3] selftests/bpf: add Launch
 Time request to xdp_hw_metadata
In-Reply-To: <656de953bcc82_2e983e2949a@willemb.c.googlers.com.notmuch>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-4-yoong.siang.song@intel.com>
 <8e20031c-83cb-4927-ab6a-e6b4840e1e42@kernel.org>
 <656de953bcc82_2e983e2949a@willemb.c.googlers.com.notmuch>
Message-ID: <PH0PR11MB5830D9440635CE0E4164BD43D885A@PH0PR11MB5830.namprd11.prod.outlook.com>

On Monday, December 4, 2023 11:00 PM, Willem de Bruijn wrote:
>Jesper Dangaard Brouer wrote:
>>
>>
>> On 12/3/23 17:51, Song Yoong Siang wrote:
>> > This patch is tested with stmmac on Intel Tiger Lake platform. Refer to
>> > result below, the delta between pre-determined launch time and actual HW
>> > transmit complete time is around 24 us.
>>
>> Is there any NIC setup (e.g. ethtool/qdisc) requirements to enable HW
>> for this feature?
>
>Judging from how we currently use this with FQ and ETF, no.
>
>See for instance tools/testing/selftests/net/so_txtime.sh

For stmmac, we need to enable per queue launch time support
by using tc qdisc etf offload command.
I believe igc also using the same way.
I will add into documentation to make it clear that
XDP_TXMD_FLAGS_LAUNCH_TIME only used to pass the
launch time value, not enable launch time feature.
  

From willemdebruijn.kernel at gmail.com  Tue Dec  5 06:55:18 2023
From: willemdebruijn.kernel at gmail.com (Willem de Bruijn)
Date: Tue, 05 Dec 2023 09:55:18 -0500
Subject: [PATCH bpf-next v2 2/3] net: stmmac: Add txtime support to XDP ZC
In-Reply-To: <PH0PR11MB58305C7D394FD264F1634819D885A@PH0PR11MB5830.namprd11.prod.outlook.com>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <20231201062421.1074768-3-yoong.siang.song@intel.com>
 <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org>
 <PH0PR11MB5830F08AC202C42501D986C0D887A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <656de8eb14c24_2e983e29435@willemb.c.googlers.com.notmuch>
 <PH0PR11MB58305C7D394FD264F1634819D885A@PH0PR11MB5830.namprd11.prod.outlook.com>
Message-ID: <656f39d668439_3dd6422949e@willemb.c.googlers.com.notmuch>

Song, Yoong Siang wrote:
> On Monday, December 4, 2023 10:58 PM, Willem de Bruijn wrote:
> >Song, Yoong Siang wrote:
> >> On Friday, December 1, 2023 11:02 PM, Jesper Dangaard Brouer wrote:
> >> >On 12/1/23 07:24, Song Yoong Siang wrote:
> >> >> This patch enables txtime support to XDP zero copy via XDP Tx
> >> >> metadata framework.
> >> >>
> >> >> Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> >> >> ---
> >> >>   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> >> >>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++
> >> >>   2 files changed, 15 insertions(+)
> >> >
> >> >I think we need to see other drivers using this new feature to evaluate
> >> >if API is sane.
> >> >
> >> >I suggest implementing this for igc driver (chip i225) and also for igb
> >> >(i210 chip) that both support this kind of LaunchTime feature in HW.
> >> >
> >> >The API and stmmac driver takes a u64 as time.
> >> >I'm wondering how this applies to i210 that[1] have 25-bit for
> >> >LaunchTime (with 32 nanosec granularity) limiting LaunchTime max 0.5
> >> >second into the future.
> >> >And i225 that [1] have 30-bit max 1 second into the future.
> >> >
> >> >
> >> >[1]
> >> >https://github.com/xdp-project/xdp-
> >> >project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org
> >>
> >> I am using u64 for launch time because existing EDT framework is using it.
> >> Refer to struct sk_buff below. Both u64 and ktime_t can be used as launch time.
> >> I choose u64 because ktime_t often requires additional type conversion and
> >> we didn't expect negative value of time.
> >>
> >> include/linux/skbuff.h-744- *   @tstamp: Time we arrived/left
> >> include/linux/skbuff.h:745- *   @skb_mstamp_ns: (aka @tstamp) earliest departure
> >time; start point
> >> include/linux/skbuff.h-746- *           for retransmit timer
> >> --
> >> include/linux/skbuff.h-880-     union {
> >> include/linux/skbuff.h-881-             ktime_t         tstamp;
> >> include/linux/skbuff.h:882-             u64             skb_mstamp_ns; /* earliest departure
> >time */
> >> include/linux/skbuff.h-883-     };
> >>
> >> tstamp/skb_mstamp_ns are used by various drivers for launch time support
> >> on normal packet, so I think u64 should be "friendly" to all the drivers. For an
> >> example, igc driver will take launch time from tstamp and recalculate it
> >> accordingly (i225 expect user to program "delta time" instead of "time" into
> >> HW register).
> >>
> >> drivers/net/ethernet/intel/igc/igc_main.c-1602- txtime = skb->tstamp;
> >> drivers/net/ethernet/intel/igc/igc_main.c-1603- skb->tstamp = ktime_set(0, 0);
> >> drivers/net/ethernet/intel/igc/igc_main.c:1604- launch_time =
> >igc_tx_launchtime(tx_ring, txtime, &first_flag, &insert_empty);
> >>
> >> Do you think this is enough to say the API is sane?
> >
> >u64 nsec sounds sane to be. It must be made explicit with clock source
> >it is against.
> >
> 
> The u64 launch time should base on NIC PTP hardware clock (PHC).
> I will add documentation saying which clock source it is against

It's not that obvious to me that that is the right and only choice.
See below.
 
> >Some applications could want to do the conversion from a clock source
> >to raw NIC cycle counter in userspace or BPF and program the raw
> >value. So it may be worthwhile to add an clock source argument -- even
> >if initially only CLOCK_MONOTONIC is supported.
> 
> Sorry, not so understand your suggestion on adding clock source argument.
> Are you suggesting to add clock source for the selftest xdp_hw_metadata apps?
> IMHO, no need to add clock source as the clock source for launch time
> should always base on NIC PHC.

This is not how FQ and ETF qdiscs pass timestamps to drivers today.

Those are in CLOCK_MONOTONIC or CLOCK_TAI. The driver is expected to
convert from that to its descriptor format, both to the reduced bit
width and the NIC PHC.

See also for instance how sch_etf has an explicit q->clock_id match,
and SO_TXTIME added an sk_clock_id for the same purpose: to agree on
which clock source is being used.


From nathan at kernel.org  Tue Dec  5 07:04:17 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Tue, 5 Dec 2023 08:04:17 -0700
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error:
 instruction variant requires ARMv6 or later
In-Reply-To: <36a25113-731c-4b28-a695-f3fbb0996d6e@app.fastmail.com>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
 <20231204181304.GA2043538@dev-arch.thelio-3990X>
 <20231204223317.GA2053629@dev-arch.thelio-3990X>
 <36a25113-731c-4b28-a695-f3fbb0996d6e@app.fastmail.com>
Message-ID: <20231205150417.GA349053@dev-arch.thelio-3990X>

On Tue, Dec 05, 2023 at 07:34:40AM +0100, Arnd Bergmann wrote:
> On Mon, Dec 4, 2023, at 23:33, Nathan Chancellor wrote:
> > On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote:
> > 
> >> I am still investigating into what (if anything) can be done to resolve
> >> this on the kernel side. We could potentially revert commit
> >> ddc72c9659b5 ("kbuild: clang: do not use CROSS_COMPILE for target
> >> triple") but I am not sure that will save us from that change, as
> >> tuxmake's CROSS_COMPILE=arm-linux-gnueabihf will cause us to have an
> >> armv7 CPU even though we may not be building for armv7.
> >
> > Okay, this is a pretty awful situation the more I look into it :(
> >
> > The arm64 compat vDSO build is easy enough to fix because we require use
> > of the integrated assembler, which means we can add '-mcpu=generic' (the
> > default in LLVM for those files based on my debugging) to those files
> > and be done with it:
> >
> > diff --git a/arch/arm64/kernel/vdso32/Makefile 
> > b/arch/arm64/kernel/vdso32/Makefile
> > index 1f911a76c5af..5f5cb722cfc2 100644
> > --- a/arch/arm64/kernel/vdso32/Makefile
> > +++ b/arch/arm64/kernel/vdso32/Makefile
> > @@ -9,6 +9,10 @@ include $(srctree)/lib/vdso/Makefile
> >  ifeq ($(CONFIG_CC_IS_CLANG), y)
> >  CC_COMPAT ?= $(CC)
> >  CC_COMPAT += --target=arm-linux-gnueabi
> > +# Some distributions (such as Debian) change the default CPU for the
> > +# arm-linux-gnueabi target triple, which can break the build. 
> > Explicitly set
> > +# the CPU to generic, which is the default for Linux in LLVM.
> > +CC_COMPAT += -mcpu=generic
> >  else
> >  CC_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc
> >  endif
> 
> I'm still trying to follow what is actually going on. I
> see that we pass
> 
> VDSO_CAFLAGS += -march=armv8-a
> 
> which is meant to tell the compiler that we want it to
> use ARMv8 compatible instructions. Is the problem that
> clang ignores this flag, or do we not pass it correctly?
> 
> I would have expected -march=armv8-a to be better than
> -mcpu=generic here, as it allows the compiler to use
> a wider set of instructions that is still guaranteed to
> be available on everything it will run on.

I should have made it clearer in that message that adding
'-mcpu=generic' was only to avoid the logic added by that Debian LLVM
change, not because I believe the kernel is doing something incorrectly
now. From what I could tell following through LLVM's code, '-march='
determines the default CPU, which is then used to further inform the
full target triple and by overriding the CPU where that patch did, it
was just blowing away the user's request. By providing an '-mcpu='
option explicitly, it would avoid the default selection logic and we
would get what we asked for.

> > Sylvestre, I strongly believe you should consider reverting that change
> > or give us some compiler flag that allows us to fallback to upstream
> > LLVM's default CPU selection logic. I think that hardcoding Debian's
> > architecture defintions based on the target triple into the compiler
> > could cause issues for other projects as well. For example,
> > '--target=arm-linux-gnueabi -march=armv7-a' won't actually target ARMv7:
> >
> >   $ echo 'int main(void) { asm("dsb"); return 0; }' | \
> >         clang --target=arm-linux-gnueabi -march=armv7-a \
> >         -x c -c -o /dev/null -v -
> >   ...
> >    "/usr/bin/clang-17" -cc1 -triple armv7-unknown-linux-gnueabi ...
> >   ...
> >
> > vs.
> >
> >   $ echo 'int main(void) { asm("dsb"); return 0; }' | \
> >         clang --target=arm-linux-gnueabi -march=armv7-a \
> >         -x c -c -o /dev/null -v -
> >   ...
> >   "<prefix>/bin/clang-18" -cc1 -triple armv5e-unknown-linux-gnueabi ...
> >   ...
> 
> Right, the kernel definitely relies on -march= taking
> precedence over the default CPU, the same way that we
> tell the compiler to pick a non-default endianess or ABI.

Agreed, I have yet to test the new version of the patch but I see you
and Ard have given input on it, so hopefully it does not have any
problems like this.

Cheers,
Nathan


From james.clark at arm.com  Tue Dec  5 07:05:05 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 5 Dec 2023 15:05:05 +0000
Subject: [PATCH v6 2/3] arm64: perf: Add support for event counting
 threshold
In-Reply-To: <20231205131414.GA18119@willie-the-truck>
References: <20231124102857.1106453-1-james.clark@arm.com>
 <20231124102857.1106453-3-james.clark@arm.com>
 <20231205131414.GA18119@willie-the-truck>
Message-ID: <1a74fef6-7f51-a518-4258-5f693b56add9@arm.com>



On 05/12/2023 13:14, Will Deacon wrote:
> On Fri, Nov 24, 2023 at 10:28:56AM +0000, James Clark wrote:
>> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
>> index 1d40d794f5e4..eb1ef84e1dbb 100644
>> --- a/drivers/perf/arm_pmuv3.c
>> +++ b/drivers/perf/arm_pmuv3.c
>> @@ -15,6 +15,7 @@
>>  #include <clocksource/arm_arch_timer.h>
>>  
>>  #include <linux/acpi.h>
>> +#include <linux/bitfield.h>
>>  #include <linux/clocksource.h>
>>  #include <linux/of.h>
>>  #include <linux/perf/arm_pmu.h>
>> @@ -294,9 +295,20 @@ static const struct attribute_group armv8_pmuv3_events_attr_group = {
>>  	.is_visible = armv8pmu_event_attr_is_visible,
>>  };
>>  
>> +#define THRESHOLD_LOW		2
>> +#define THRESHOLD_HIGH		13
>> +#define THRESHOLD_CNT		14
>> +#define THRESHOLD_CMP_LO	15
>> +#define THRESHOLD_CMP_HI	16
> 
> Do you think THWIDTH might extend beyond 12 bits in future? If so, it might
> be worth juggling these bits around a bit so it's not sandwiched between
> 'rdpmc' and 'threshold_compare'. I defer to your judgement, however.
> 

It's possible, both PMMIR.THWIDTH and PMEVTYPER.TH currently have unused
bits above them. I can easily move threshold to the end, I suppose that
covers us at least until someone adds a new field above that.

>>  PMU_FORMAT_ATTR(event, "config:0-15");
>>  PMU_FORMAT_ATTR(long, "config1:0");
>>  PMU_FORMAT_ATTR(rdpmc, "config1:1");
>> +PMU_FORMAT_ATTR(threshold, "config1:" __stringify(THRESHOLD_LOW) "-"
>> +				      __stringify(THRESHOLD_HIGH));
>> +PMU_FORMAT_ATTR(threshold_compare, "config1:" __stringify(THRESHOLD_CMP_LO) "-"
>> +					      __stringify(THRESHOLD_CMP_HI));
>> +PMU_FORMAT_ATTR(threshold_count, "config1:" __stringify(THRESHOLD_CNT));
>>  
>>  static int sysctl_perf_user_access __read_mostly;
>>  
>> @@ -310,10 +322,33 @@ static inline bool armv8pmu_event_want_user_access(struct perf_event *event)
>>  	return event->attr.config1 & 0x2;
>>  }
>>  
>> +static inline u32 armv8pmu_event_threshold(struct perf_event_attr *attr)
>> +{
>> +	return FIELD_GET(GENMASK(THRESHOLD_HIGH, THRESHOLD_LOW), attr->config1);
>> +}
>> +
>> +static inline u8 armv8pmu_event_threshold_control(struct perf_event_attr *attr)
> 
> You can drop the 'inline's for these functions (and, in fact, this whole
> file could do with that cleanup :)
> 

Will do.

>> +{
>> +	u8 th_compare = FIELD_GET(GENMASK(THRESHOLD_CMP_HI, THRESHOLD_CMP_LO),
>> +				  attr->config1);
>> +	u8 th_count = FIELD_GET(BIT(THRESHOLD_CNT), attr->config1);
> 
> I think this is correct, but you might want to look at how we handle this
> in the SPE driver as I think it ends up looking cleaner and makes it pretty
> obvious which bits correspond to the user ABI (i.e. config fields) and which
> bits are part of architectural registers. I'm not saying you have to do it
> that way, but please take a look if you haven't already.
> 

Yeah I could take the GEN_PMU_FORMAT_ATTR() etc macros out of there and
re-use them here too. And also for the other existing configs in
arm_pmuv3.c.

>> +	/*
>> +	 * The count bit is always the bottom bit of the full control field, and
>> +	 * the comparison is the upper two bits, but it's not explicitly
>> +	 * labelled in the Arm ARM. For the Perf interface we split it into two
>> +	 * fields, so reconstruct it here.
>> +	 */
>> +	return (th_compare << 1) | th_count;
>> +}
>> +
>>  static struct attribute *armv8_pmuv3_format_attrs[] = {
>>  	&format_attr_event.attr,
>>  	&format_attr_long.attr,
>>  	&format_attr_rdpmc.attr,
>> +	&format_attr_threshold.attr,
>> +	&format_attr_threshold_compare.attr,
>> +	&format_attr_threshold_count.attr,
>>  	NULL,
>>  };
>>  
>> @@ -365,10 +400,38 @@ static ssize_t bus_width_show(struct device *dev, struct device_attribute *attr,
>>  
>>  static DEVICE_ATTR_RO(bus_width);
>>  
>> +static u32 threshold_max(struct arm_pmu *cpu_pmu)
>> +{
>> +	/*
>> +	 * PMMIR.THWIDTH is readable and non-zero on aarch32, but it would be
>> +	 * impossible to write the threshold in the upper 32 bits of PMEVTYPER.
>> +	 */
>> +	if (IS_ENABLED(CONFIG_ARM))
>> +		return 0;
>> +
>> +	/*
>> +	 * The largest value that can be written to PMEVTYPER<n>_EL0.TH is
>> +	 * (2 ^ PMMIR.THWIDTH) - 1.
>> +	 */
>> +	return (1 << FIELD_GET(ARMV8_PMU_THWIDTH, cpu_pmu->reg_pmmir)) - 1;
>> +}
>> +
>> +static ssize_t threshold_max_show(struct device *dev,
>> +				  struct device_attribute *attr, char *page)
>> +{
>> +	struct pmu *pmu = dev_get_drvdata(dev);
>> +	struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
>> +
>> +	return sysfs_emit(page, "0x%08x\n", threshold_max(cpu_pmu));
>> +}
>> +
>> +static DEVICE_ATTR_RO(threshold_max);
>> +
>>  static struct attribute *armv8_pmuv3_caps_attrs[] = {
>>  	&dev_attr_slots.attr,
>>  	&dev_attr_bus_slots.attr,
>>  	&dev_attr_bus_width.attr,
>> +	&dev_attr_threshold_max.attr,
>>  	NULL,
>>  };
>>  
>> @@ -552,7 +615,7 @@ static void armv8pmu_write_counter(struct perf_event *event, u64 value)
>>  		armv8pmu_write_hw_counter(event, value);
>>  }
>>  
>> -static inline void armv8pmu_write_evtype(int idx, u32 val)
>> +static inline void armv8pmu_write_evtype(int idx, unsigned long val)
>>  {
>>  	u32 counter = ARMV8_IDX_TO_COUNTER(idx);
>>  	unsigned long mask = ARMV8_PMU_EVTYPE_EVENT |
>> @@ -921,6 +984,10 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>>  				     struct perf_event_attr *attr)
>>  {
>>  	unsigned long config_base = 0;
>> +	struct perf_event *perf_event = container_of(attr, struct perf_event,
>> +						     attr);
>> +	struct arm_pmu *cpu_pmu = to_arm_pmu(perf_event->pmu);
>> +	u32 th, th_max;
>>  
>>  	if (attr->exclude_idle)
>>  		return -EPERM;
>> @@ -952,6 +1019,21 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>>  	if (attr->exclude_user)
>>  		config_base |= ARMV8_PMU_EXCLUDE_EL0;
>>  
>> +	/*
>> +	 * Insert event counting threshold (FEAT_PMUv3_TH) values. If
>> +	 * FEAT_PMUv3_TH isn't implemented, then THWIDTH (threshold_max) will be
>> +	 * 0 and no values will be written.
>> +	 */
>> +	th_max = threshold_max(cpu_pmu);
>> +	if (IS_ENABLED(CONFIG_ARM64) && th_max) {
> 
> Why is the IS_ENABLED() check needed here?
> 

The FIELD_PREP() below would cause a compilation error on arm32 because
TH and TC are above 32 bits. I can add a comment.

>> +		th = min(armv8pmu_event_threshold(attr), th_max);
>> +		if (th) {
> 
> Why is it useful to take the minimum here? If userspace asks for a value
> bigger than the maximum support threshold, shouldn't we return an error
> rather than silently clamp it?
> 

I think it probably was just so I didn't have to think about what would
happen when the value varied between cores.

But you're right, it looks like I can add a validation function to
struct arm_pmu and call it from armpmu_event_init(). armpmu->map_event()
and armpmu->set_event_filter() are already called from there so I think
the validation could technically be added to one of those, but that's
probably a bit hacky. I don't know if you have any preference for where
the threshold validation should happen?

>> +			config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TH, th);
>> +			config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TC,
>> +						  armv8pmu_event_threshold_control(attr));
>> +		}
>> +	}
>> +
>>  	/*
>>  	 * Install the filter into config_base as this is used to
>>  	 * construct the event type.
>> diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
>> index ddd1fec86739..ccbc0f9a74d8 100644
>> --- a/include/linux/perf/arm_pmuv3.h
>> +++ b/include/linux/perf/arm_pmuv3.h
>> @@ -258,6 +258,7 @@
>>  #define ARMV8_PMU_BUS_SLOTS_MASK 0xff
>>  #define ARMV8_PMU_BUS_WIDTH_SHIFT 16
>>  #define ARMV8_PMU_BUS_WIDTH_MASK 0xf
>> +#define ARMV8_PMU_THWIDTH GENMASK(23, 20)
> 
> It's a bit messy having a mixture of GENMASK and MASK/SHIFT pairs. Please
> can you either update what's there to use GENMASK, or use SHIFT/MASK for the
> new addition?
> 
> Will
> 

Yep will do. Thanks for the review.

James


From hugo at hugovil.com  Tue Dec  5 07:08:11 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Tue,  5 Dec 2023 10:08:11 -0500
Subject: [PATCH v5 0/3] board: imx8mn-rve-gateway: add support for RVE gateway board
Message-ID: <20231205150814.344883-1-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Hello,
this patch series add support for the RVE gateway board.

Thank you.

Link: [v1] https://lore.kernel.org/all/20231101144303.2653464-1-hugo at hugovil.com/
           https://lore.kernel.org/all/20231101144057.2653271-1-hugo at hugovil.com/
      [v2] https://lore.kernel.org/all/20231101183549.2960083-1-hugo at hugovil.com/
      [v3] https://lore.kernel.org/all/20231102193121.1676000-1-hugo at hugovil.com/
      [v4] https://lore.kernel.org/all/20231103142831.2116163-1-hugo at hugovil.com/

Changes for V2:
- Combine separate patches as a series. Start series at 2 to avoid confusion.

Changes for V3:
- Fix coding style / indentation
- Change vmmc supply for usdhc2 node
- Disable uart2 node instead of removing it.
- Remove MAINTAINERS board entry
- Add SOM compatible string
- Drop some status = "okay"

Changes for V4:
- Fix dtbs_check warning for compatible string "rve,rve-gateway"
  (remove acked by tag because of that change)

Changes for V5:
- Fix indentation for gpio-line-names
- Add Krzysztof "Reviewed-by" tag for patch 2

Hugo Villeneuve (3):
  dt-bindings: vendor-prefixes: add rve
  dt-bindings: arm: fsl: add RVE gateway board
  arm64: dts: freescale: introduce rve-gateway board

 .../devicetree/bindings/arm/fsl.yaml          |   4 +-
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../boot/dts/freescale/imx8mn-rve-gateway.dts | 285 ++++++++++++++++++
 4 files changed, 291 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts


base-commit: bee0e7762ad2c6025b9f5245c040fcc36ef2bde8
-- 
2.39.2



From hugo at hugovil.com  Tue Dec  5 07:08:12 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Tue,  5 Dec 2023 10:08:12 -0500
Subject: [PATCH v5 1/3] dt-bindings: vendor-prefixes: add rve
In-Reply-To: <20231205150814.344883-1-hugo@hugovil.com>
References: <20231205150814.344883-1-hugo@hugovil.com>
Message-ID: <20231205150814.344883-2-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Add vendor prefix for Recharge V?hicule ?lectrique (RVE), which
manufactures electric vehicle chargers infrastructure components.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c8..71dcd6240a99 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1179,6 +1179,8 @@ patternProperties:
     description: Shenzhen Roofull Technology Co, Ltd
   "^roseapplepi,.*":
     description: RoseapplePi.org
+  "^rve,.*":
+    description: Recharge V?hicule ?lectrique (RVE) inc.
   "^saef,.*":
     description: Saef Technology Limited
   "^samsung,.*":
-- 
2.39.2



From hugo at hugovil.com  Tue Dec  5 07:08:13 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Tue,  5 Dec 2023 10:08:13 -0500
Subject: [PATCH v5 2/3] dt-bindings: arm: fsl: add RVE gateway board
In-Reply-To: <20231205150814.344883-1-hugo@hugovil.com>
References: <20231205150814.344883-1-hugo@hugovil.com>
Message-ID: <20231205150814.344883-3-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Add DT compatible string for RVE gateway board based on a Variscite
VAR-SOM-NANO with a NXP MX8MN nano CPU.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 32b195852a75..5b98a17b65b5 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1022,7 +1022,9 @@ properties:
 
       - description: Variscite VAR-SOM-MX8MN based boards
         items:
-          - const: variscite,var-som-mx8mn-symphony
+          - enum:
+              - rve,rve-gateway # i.MX8MN RVE Gateway Board
+              - variscite,var-som-mx8mn-symphony
           - const: variscite,var-som-mx8mn
           - const: fsl,imx8mn
 
-- 
2.39.2



From hugo at hugovil.com  Tue Dec  5 07:08:14 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Tue,  5 Dec 2023 10:08:14 -0500
Subject: [PATCH v5 3/3] arm64: dts: freescale: introduce rve-gateway board
In-Reply-To: <20231205150814.344883-1-hugo@hugovil.com>
References: <20231205150814.344883-1-hugo@hugovil.com>
Message-ID: <20231205150814.344883-4-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

The RVE gateway board is based on a Variscite VAR-SOM-NANO,
with a NXP MX8MN nano CPU.

Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
---
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../boot/dts/freescale/imx8mn-rve-gateway.dts | 285 ++++++++++++++++++
 2 files changed, 286 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 300049037eb0..c99da779ef7b 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -98,6 +98,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mn-bsh-smm-s2pro.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr3l-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mn-rve-gateway.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-tqma8mqnl-mba8mx.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-var-som-symphony.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-venice-gw7902.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts b/arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts
new file mode 100644
index 000000000000..1b633bd1ebb6
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts
@@ -0,0 +1,285 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2023 DimOnOff
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx8mn-var-som.dtsi"
+
+/ {
+	model = "RVE gateway";
+	compatible = "rve,rve-gateway", "variscite,var-som-mx8mn", "fsl,imx8mn";
+
+	crystal_duart_24m: crystal-duart-24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpio_keys>;
+
+		key-enter {
+			label = "enter";
+			gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_ENTER>;
+		};
+
+		key-exit {
+			label = "exit";
+			gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_ESC>;
+		};
+	};
+
+	lcd {
+		compatible = "hit,hd44780";
+		display-height-chars = <2>;
+		display-width-chars = <20>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_lcd>;
+		data-gpios = <&gpio5  1 GPIO_ACTIVE_HIGH>,
+			     <&gpio1  6 GPIO_ACTIVE_HIGH>,
+			     <&gpio1 14 GPIO_ACTIVE_HIGH>,
+			     <&gpio4 28 GPIO_ACTIVE_HIGH>,
+			     <&gpio5 24 GPIO_ACTIVE_HIGH>,
+			     <&gpio5  2 GPIO_ACTIVE_HIGH>,
+			     <&gpio1 12 GPIO_ACTIVE_HIGH>,
+			     <&gpio5 25 GPIO_ACTIVE_HIGH>;
+		enable-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
+		rs-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+		rw-gpios = <&gpio4 27 GPIO_ACTIVE_HIGH>;
+	};
+
+	reg_3p3v: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "3P3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	/* Bourns PEC12R rotary encoder, 24 steps. */
+	rotary: rotary-encoder {
+		compatible = "rotary-encoder";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_rotary>;
+		gpios = <&gpio1  5 GPIO_ACTIVE_LOW>, /* A */
+			<&gpio3 21 GPIO_ACTIVE_LOW>; /* B */
+		linux,axis = <0>; /* REL_X */
+		rotary-encoder,encoding = "gray";
+		rotary-encoder,relative-axis;
+	};
+};
+
+&ecspi1 {
+	cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
+
+	duart1: serial at 0 {
+		compatible = "nxp,sc16is752";
+		reg = <0>;
+		spi-rx-bus-width = <1>;
+		spi-tx-bus-width = <1>;
+		spi-max-frequency = <4000000>;
+		clocks = <&crystal_duart_24m>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <22 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names = "RADIO0", "RADIO1", "RADIO2", "RADIO3",
+				  "RADIO4", "RADIO_RESET", "TP12", "TP11";
+		linux,rs485-enabled-at-boot-time;
+		rs485-rts-active-low;
+	};
+
+	/delete-node/ touchscreen at 0;
+};
+
+&ecspi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi2>;
+	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+	/delete-property/ dmas;
+	/delete-property/ dma-names;
+	status = "okay";
+
+	duart2: serial at 0 {
+		compatible = "nxp,sc16is752";
+		reg = <0>;
+		spi-rx-bus-width = <1>;
+		spi-tx-bus-width = <1>;
+		spi-max-frequency = <4000000>;
+		clocks = <&crystal_duart_24m>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names = "LED_B_USER", "LED_R_USER", "LED_G_USER",
+				  "GPIO_EXT3", "GPIO_EXT2", "GPIO_EXT1",
+				  "GPIO_EXT0", "TP13";
+		linux,rs485-enabled-at-boot-time;
+		rs485-rts-active-low;
+	};
+};
+
+/* Configure PWM pins in GPIO mode: */
+&gpio5 {
+	gpio-line-names = "", "", "", "PWM3", "PWM2", "PWM1";
+};
+
+&gpu {
+	status = "disabled";
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	/* Carrier board EEPROM */
+	eeprom_cb: eeprom at 56 {
+		compatible = "atmel,24c04";
+		reg = <0x56>;
+		pagesize = <16>;
+		vcc-supply = <&reg_3p3v>;
+	};
+
+	lm75: sensor at 48 {
+		compatible = "st,stlm75";
+		reg = <0x48>;
+		vs-supply = <&reg_3p3v>;
+	};
+
+	mcp7940: rtc at 6f {
+		compatible = "microchip,mcp7940x";
+		reg = <0x6f>;
+	};
+};
+
+&i2c3 {
+	codec at 1a {
+		status = "disabled";
+	};
+};
+
+&i2c4 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c4>;
+	status = "okay";
+
+	pcf8574_1: gpio at 38 {
+		compatible = "nxp,pcf8574";
+		reg = <0x38>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names = "LED_B_COMM3", "LED_R_COMM3", "LED_G_COMM3",
+				  "TP14", "TP15", "LED_G_COMM4", "LED_R_COMM4",
+				  "LED_B_COMM4";
+	};
+
+	pcf8574_2: gpio at 39 {
+		compatible = "nxp,pcf8574";
+		reg = <0x39>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names = "LED_B_COMM2", "LED_G_COMM2", "LED_B_COMM1",
+				  "LED_R_COMM2", "LED_R_COMM1", "LED_G_COMM1",
+				  "TP16", "TP17";
+	};
+};
+
+/* Bluetooth */
+&uart2 {
+	status = "disabled";
+};
+
+&usbotg1 {
+	dr_mode = "host";
+	disable-over-current;
+	status = "okay";
+};
+
+/* SD interface on expansion connector. */
+&usdhc2 {
+	vmmc-supply = <&reg_3p3v>;
+	cd-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
+};
+
+&iomuxc {
+	pinctrl_ecspi1: ecspi1grp {
+		fsl,pins = <
+			MX8MN_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK	0x13
+			MX8MN_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI	0x13
+			MX8MN_IOMUXC_ECSPI1_MISO_ECSPI1_MISO	0x13
+			MX8MN_IOMUXC_ECSPI1_SS0_GPIO5_IO9	0x13 /* SS0 */
+			MX8MN_IOMUXC_SAI5_RXD1_GPIO3_IO22	0x13 /* SC16 IRQ */
+		>;
+	};
+
+	pinctrl_ecspi2: ecspi2grp {
+		fsl,pins = <
+			MX8MN_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK	0x13
+			MX8MN_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI	0x13
+			MX8MN_IOMUXC_ECSPI2_MISO_ECSPI2_MISO	0x13
+			MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13	0x13 /* SS0 */
+			MX8MN_IOMUXC_SAI5_RXC_GPIO3_IO20	0x13 /* SC16 IRQ */
+		>;
+	};
+
+	pinctrl_gpio_keys: gpiokeysgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO01_GPIO1_IO1	0xc6 /* Enter */
+			MX8MN_IOMUXC_SAI5_RXD2_GPIO3_IO23	0xc6 /* Exit */
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX8MN_IOMUXC_I2C2_SCL_I2C2_SCL		0x400001c3
+			MX8MN_IOMUXC_I2C2_SDA_I2C2_SDA		0x400001c3
+		>;
+	};
+
+	pinctrl_i2c4: i2c4grp {
+		fsl,pins = <
+			MX8MN_IOMUXC_I2C4_SCL_I2C4_SCL		0x400001c3
+			MX8MN_IOMUXC_I2C4_SDA_I2C4_SDA		0x400001c3
+		>;
+	};
+
+	pinctrl_lcd: lcdgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_SAI3_TXD_GPIO5_IO1		0x00000156 /* D0 */
+			MX8MN_IOMUXC_GPIO1_IO06_GPIO1_IO6	0x00000156 /* D1 */
+			MX8MN_IOMUXC_GPIO1_IO14_GPIO1_IO14	0x00000156 /* D2 */
+			MX8MN_IOMUXC_SAI3_RXFS_GPIO4_IO28	0x00000156 /* D3 */
+			MX8MN_IOMUXC_UART2_RXD_GPIO5_IO24	0x00000156 /* D4 */
+			MX8MN_IOMUXC_SAI3_MCLK_GPIO5_IO2	0x00000156 /* D5 */
+			MX8MN_IOMUXC_GPIO1_IO12_GPIO1_IO12	0x00000156 /* D6 */
+			MX8MN_IOMUXC_UART2_TXD_GPIO5_IO25	0x00000156 /* D7 */
+			MX8MN_IOMUXC_UART1_TXD_GPIO5_IO23	0x00000156 /* E */
+			MX8MN_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x00000156 /* RS */
+			MX8MN_IOMUXC_SAI2_MCLK_GPIO4_IO27	0x00000156 /* R/W */
+		>;
+	};
+
+	pinctrl_rotary: rotarygrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO05_GPIO1_IO5	0x00000156 /* A */
+			MX8MN_IOMUXC_SAI5_RXD0_GPIO3_IO21	0x00000156 /* B */
+		>;
+	};
+
+	/* Override Card Detect function GPIO value (GPIO1_IO10) from SOM: */
+	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO13_GPIO1_IO13	0x41
+		>;
+	};
+};
-- 
2.39.2



From andrew at lunn.ch  Tue Dec  5 07:08:30 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 5 Dec 2023 16:08:30 +0100
Subject: [PATCH net-next] net: stmmac: qcom-ethqos: Add sysfs nodes for
 qcom ethqos
In-Reply-To: <20231204084854.31543-1-quic_snehshah@quicinc.com>
References: <20231204084854.31543-1-quic_snehshah@quicinc.com>
Message-ID: <3e4a1b9c-ed0f-466e-ba11-fc5b7ef308a1@lunn.ch>

On Mon, Dec 04, 2023 at 02:18:54PM +0530, Sneh Shah wrote:
> Add sysfs nodes to conifigure routing of specific vlan id to GVM queue.
> GVM queue is not exposed to PVM stmmac, so TC ops can't configure routing.

Adding files in /sysfs has ~0 chance of being accepted.

As requested, please explain what all these different hardware blocks
are, and what you are trying to achieve. We can then recommend the
correct interface.

    Andrew

---
pw-bot: cr


From nm at ti.com  Tue Dec  5 07:12:35 2023
From: nm at ti.com (Nishanth Menon)
Date: Tue, 5 Dec 2023 09:12:35 -0600
Subject: [PATCH 1/3] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Lower
 I2C1 frequency
In-Reply-To: <20231204222811.2344460-1-ggiordano@phytec.com>
References: <20231204222811.2344460-1-ggiordano@phytec.com>
Message-ID: <20231205151235.y6qb7pzvrar24opm@regally>

On 14:28-20231204, Garrett Giordano wrote:
> The gpio-expander on i2c-1 has a maximum frequency of 100kHz. Update our
> main_i2c1 frequency to allow the nxp,pcf8574 gpio-expander to function
> properly.
> 
> Signed-off-by: Garrett Giordano <ggiordano at phytec.com>
> ---
>  arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
> index a438baf542c2..171354b13e33 100644
> --- a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
> @@ -187,7 +187,7 @@ cpsw3g_phy3: ethernet-phy at 3 {
>  &main_i2c1 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&main_i2c1_pins_default>;
> -	clock-frequency = <400000>;
> +	clock-frequency = <100000>;
>  	status = "okay";
>  
>  	gpio_exp: gpio-expander at 21 {
> -- 
> 2.25.1
> 
https://lore.kernel.org/all/bd5284ec-6f25-464a-9ee7-4c50496482f1 at phytec.de/

please make sure to pick up the previous Reviewed-by when you post an
update of your series.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From adiupina at astralinux.ru  Tue Dec  5 07:12:20 2023
From: adiupina at astralinux.ru (Alexandra Diupina)
Date: Tue,  5 Dec 2023 18:12:20 +0300
Subject: [PATCH v2] cpufreq: scmi: process the result of devm_of_clk_add_hw_provider()
In-Reply-To: <2e919694-e124-4864-aa02-01d47495032b@wanadoo.fr>
Message-ID: <20231205151220.18463-1-adiupina@astralinux.ru>

devm_of_clk_add_hw_provider() may return an errno, so
add a return value check

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider")
Signed-off-by: Alexandra Diupina <adiupina at astralinux.ru>
---
v2: replace dev_err() with dev_err_probe() as 
Christophe JAILLET <christophe.jaillet at wanadoo.fr> suggested
 drivers/cpufreq/scmi-cpufreq.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index c8a7ccc42c16..4ee23f4ebf4a 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -334,8 +334,11 @@ static int scmi_cpufreq_probe(struct scmi_device *sdev)
 
 #ifdef CONFIG_COMMON_CLK
 	/* dummy clock provider as needed by OPP if clocks property is used */
-	if (of_property_present(dev->of_node, "#clock-cells"))
-		devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get, NULL);
+	if (of_property_present(dev->of_node, "#clock-cells")) {
+		ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get, NULL);
+		if (ret)
+			return dev_err_probe(dev, ret, "%s: registering clock provider failed\n", __func__);
+	}
 #endif
 
 	ret = cpufreq_register_driver(&scmi_cpufreq_driver);
-- 
2.30.2



From sylvestre at debian.org  Tue Dec  5 07:13:29 2023
From: sylvestre at debian.org (Sylvestre Ledru)
Date: Tue, 5 Dec 2023 16:13:29 +0100
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error:
 instruction variant requires ARMv6 or later
In-Reply-To: <20231205150417.GA349053@dev-arch.thelio-3990X>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
 <20231204181304.GA2043538@dev-arch.thelio-3990X>
 <20231204223317.GA2053629@dev-arch.thelio-3990X>
 <36a25113-731c-4b28-a695-f3fbb0996d6e@app.fastmail.com>
 <20231205150417.GA349053@dev-arch.thelio-3990X>
Message-ID: <3523ca62-be8b-4b08-8d0c-5b97ece9aad8@debian.org>

Le 05/12/2023 ? 16:04, Nathan Chancellor a ?crit?:
> On Tue, Dec 05, 2023 at 07:34:40AM +0100, Arnd Bergmann wrote:
>> On Mon, Dec 4, 2023, at 23:33, Nathan Chancellor wrote:
>>> On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote:
>>>
>>>> I am still investigating into what (if anything) can be done to resolve
>>>> this on the kernel side. We could potentially revert commit
>>>> ddc72c9659b5 ("kbuild: clang: do not use CROSS_COMPILE for target
>>>> triple") but I am not sure that will save us from that change, as
>>>> tuxmake's CROSS_COMPILE=arm-linux-gnueabihf will cause us to have an
>>>> armv7 CPU even though we may not be building for armv7.
>>>
>>> Okay, this is a pretty awful situation the more I look into it :(
>>>
>>> The arm64 compat vDSO build is easy enough to fix because we require use
>>> of the integrated assembler, which means we can add '-mcpu=generic' (the
>>> default in LLVM for those files based on my debugging) to those files
>>> and be done with it:
>>>
>>> diff --git a/arch/arm64/kernel/vdso32/Makefile
>>> b/arch/arm64/kernel/vdso32/Makefile
>>> index 1f911a76c5af..5f5cb722cfc2 100644
>>> --- a/arch/arm64/kernel/vdso32/Makefile
>>> +++ b/arch/arm64/kernel/vdso32/Makefile
>>> @@ -9,6 +9,10 @@ include $(srctree)/lib/vdso/Makefile
>>>   ifeq ($(CONFIG_CC_IS_CLANG), y)
>>>   CC_COMPAT ?= $(CC)
>>>   CC_COMPAT += --target=arm-linux-gnueabi
>>> +# Some distributions (such as Debian) change the default CPU for the
>>> +# arm-linux-gnueabi target triple, which can break the build.
>>> Explicitly set
>>> +# the CPU to generic, which is the default for Linux in LLVM.
>>> +CC_COMPAT += -mcpu=generic
>>>   else
>>>   CC_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc
>>>   endif
>>
>> I'm still trying to follow what is actually going on. I
>> see that we pass
>>
>> VDSO_CAFLAGS += -march=armv8-a
>>
>> which is meant to tell the compiler that we want it to
>> use ARMv8 compatible instructions. Is the problem that
>> clang ignores this flag, or do we not pass it correctly?
>>
>> I would have expected -march=armv8-a to be better than
>> -mcpu=generic here, as it allows the compiler to use
>> a wider set of instructions that is still guaranteed to
>> be available on everything it will run on.
> 
> I should have made it clearer in that message that adding
> '-mcpu=generic' was only to avoid the logic added by that Debian LLVM
> change, not because I believe the kernel is doing something incorrectly
> now. From what I could tell following through LLVM's code, '-march='
> determines the default CPU, which is then used to further inform the
> full target triple and by overriding the CPU where that patch did, it
> was just blowing away the user's request. By providing an '-mcpu='
> option explicitly, it would avoid the default selection logic and we
> would get what we asked for.
> 
>>> Sylvestre, I strongly believe you should consider reverting that change
>>> or give us some compiler flag that allows us to fallback to upstream
>>> LLVM's default CPU selection logic. I think that hardcoding Debian's
>>> architecture defintions based on the target triple into the compiler
>>> could cause issues for other projects as well. For example,
>>> '--target=arm-linux-gnueabi -march=armv7-a' won't actually target ARMv7:
>>>
>>>    $ echo 'int main(void) { asm("dsb"); return 0; }' | \
>>>          clang --target=arm-linux-gnueabi -march=armv7-a \
>>>          -x c -c -o /dev/null -v -
>>>    ...
>>>     "/usr/bin/clang-17" -cc1 -triple armv7-unknown-linux-gnueabi ...
>>>    ...
>>>
>>> vs.
>>>
>>>    $ echo 'int main(void) { asm("dsb"); return 0; }' | \
>>>          clang --target=arm-linux-gnueabi -march=armv7-a \
>>>          -x c -c -o /dev/null -v -
>>>    ...
>>>    "<prefix>/bin/clang-18" -cc1 -triple armv5e-unknown-linux-gnueabi ...
>>>    ...
>>
>> Right, the kernel definitely relies on -march= taking
>> precedence over the default CPU, the same way that we
>> tell the compiler to pick a non-default endianess or ABI.
> 
> Agreed, I have yet to test the new version of the patch but I see you
> and Ard have given input on it, so hopefully it does not have any
> problems like this.

Matthias, as cc, pushed a potential fix for debian/ubuntu packages!
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/01a06b481e5a2610c7387149b58978c3ec281f2c

Cheers,
Sylvestre



From will at kernel.org  Tue Dec  5 07:16:27 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:27 +0000
Subject: [PATCH 0/2] drivers: perf: arm_pmu: Drop 'pmu_lock' element from 'struct pmu_hw_events'
In-Reply-To: <20231115092805.737822-1-anshuman.khandual@arm.com>
References: <20231115092805.737822-1-anshuman.khandual@arm.com>
Message-ID: <170178008886.1061392.10642726925666459219.b4-ty@kernel.org>

On Wed, 15 Nov 2023 14:58:03 +0530, Anshuman Khandual wrote:
> This series drops 'pmu_lock' usage from all arm platforms which had already
> been dropped from arm64 platforms earlier via the following commit.
> 
> commit 2a0e2a02e4b7 ("arm64: perf: Remove PMU locking").
> 
> Afterwards, drop unused 'pmu_lock' element from 'struct pmu_hw_events'. The
> series applies on 6.7-rc1 and has been tested on arm64. Although just build
> tested for arm platform.
> 
> [...]

Applied to will (for-next/perf), thanks!

[1/2] arm: perf: Remove PMU locking
      https://git.kernel.org/will/c/5cd7da19cb97
[2/2] drivers: perf: arm_pmu: Drop 'pmu_lock' element from 'struct pmu_hw_events'
      https://git.kernel.org/will/c/118eb89b1e7f

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:28 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:28 +0000
Subject: [PATCH V2 RESEND] drivers: perf: arm_pmuv3: Add new macro PMUV3_INIT_MAP_EVENT()
In-Reply-To: <20231114061656.337231-1-anshuman.khandual@arm.com>
References: <20231114061656.337231-1-anshuman.khandual@arm.com>
Message-ID: <170177961082.1060333.9015278022225472341.b4-ty@kernel.org>

On Tue, 14 Nov 2023 11:46:56 +0530, Anshuman Khandual wrote:
> This further compacts all remaining PMU init procedures requiring specific
> map_event functions via a new macro PMUV3_INIT_MAP_EVENT(). While here, it
> also changes generated init function names to match to those generated via
> the other macro PMUV3_INIT_SIMPLE(). This does not cause functional change.
> 
> 

Applied to will (for-next/perf), thanks!

[1/1] drivers: perf: arm_pmuv3: Add new macro PMUV3_INIT_MAP_EVENT()
      https://git.kernel.org/will/c/877806b9b41e

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:30 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:30 +0000
Subject: [PATCH] drivers/perf: pmuv3: don't expose SW_INCR event in sysfs
In-Reply-To: <20231204115847.2993026-1-mark.rutland@arm.com>
References: <20231204115847.2993026-1-mark.rutland@arm.com>
Message-ID: <170177966506.1060526.1172098093218975069.b4-ty@kernel.org>

On Mon, 4 Dec 2023 11:58:47 +0000, Mark Rutland wrote:
> The SW_INCR event is somewhat unusual, and depends on the specific HW
> counter that it is programmed into. When programmed into PMEVCNTR<n>,
> SW_INCR will count any writes to PMSWINC_EL0 with bit n set, ignoring
> writes to SW_INCR with bit n clear.
> 
> Event rotation means that there's no fixed relationship between
> perf_events and HW counters, so this isn't all that useful.
> 
> [...]

Applied to will (for-next/perf), thanks!

[1/1] drivers/perf: pmuv3: don't expose SW_INCR event in sysfs
      https://git.kernel.org/will/c/ca6f537e459e

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:29 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:29 +0000
Subject: [PATCH] drivers/perf: hisi: Fix some event id for HiSilicon UC pmu
In-Reply-To: <20231204110425.20354-1-hejunhao3@huawei.com>
References: <20231204110425.20354-1-hejunhao3@huawei.com>
Message-ID: <170177974197.1060739.15417624024644371225.b4-ty@kernel.org>

On Mon, 4 Dec 2023 19:04:25 +0800, Junhao He wrote:
> Some event id of HiSilicon uncore UC PMU driver is incorrect, fix them.
> 
> 

Applied to will (for-next/perf), thanks!

[1/1] drivers/perf: hisi: Fix some event id for HiSilicon UC pmu
      https://git.kernel.org/will/c/38bbef7240b8

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From nm at ti.com  Tue Dec  5 07:16:47 2023
From: nm at ti.com (Nishanth Menon)
Date: Tue, 5 Dec 2023 09:16:47 -0600
Subject: [PATCH v9 6/7] arm64: dts: ti: k3-j721e-sk: Add TPS6594 family
 PMICs
In-Reply-To: <20231205093439.2298296-7-n-francis@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
 <20231205093439.2298296-7-n-francis@ti.com>
Message-ID: <20231205151647.vh6rlhro7qlwoerc@knelt>

On 15:04-20231205, Neha Malcom Francis wrote:
> This patch adds support for TPS6594 PMIC family on wakeup I2C0 bus.
> These devices provide regulators (bucks and LDOs), but also GPIOs, a
> RTC, a watchdog, an ESM (Error Signal Monitor) which monitors the SoC
> error output signal, and a PFSM (Pre-configurable Finite State Machine)
> which manages the operational modes of the PMIC.
> 
> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
> ---
>  arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 158 +++++++++++++++++++++++++
>  1 file changed, 158 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
> index 42fe8eee9ec8..e600825f7e78 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
> @@ -459,6 +459,13 @@ J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3) EXT_REFCLK1.GPIO1_12 */
>  };
>  
>  &wkup_pmx0 {
> +	pmic_irq_pins_default: pmic-irq-default-pins {
> +		bootph-pre-ram;
> +		pinctrl-single,pins = <
> +			J721E_WKUP_IOPAD(0x0cc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
> +		>;
> +	};
> +
>  	mcu_cpsw_pins_default: mcu-cpsw-default-pins {
>  		pinctrl-single,pins = <
>  			J721E_WKUP_IOPAD(0x84, PIN_INPUT, 0) /* (B24) MCU_RGMII1_RD0 */
> @@ -560,6 +567,157 @@ eeprom at 51 {
>  		compatible = "atmel,24c512";
>  		reg = <0x51>;
>  	};
> +
> +	tps659413: pmic at 48 {
> +		bootph-pre-ram;

only for the leaf nodes. See
https://libera.irclog.whitequark.org/armlinux/2023-10-19

> +		compatible = "ti,tps6594-q1";
> +		reg = <0x48>;
> +		system-power-controller;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_irq_pins_default>;
> +		interrupt-parent = <&wkup_gpio0>;
> +		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
> +		ti,primary-pmic;
> +
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +		buck123-supply = <&vsys_3v3>;
> +		buck4-supply = <&vsys_3v3>;
> +		buck5-supply = <&vsys_3v3>;
> +		ldo1-supply = <&vsys_3v3>;
> +		ldo2-supply = <&vsys_3v3>;
> +		ldo3-supply = <&vsys_3v3>;
> +		ldo4-supply = <&vsys_3v3>;
> +
> +		regulators {
> +			bootph-pre-ram;
> +			bucka123: buck123 {
> +				bootph-pre-ram;
> +				regulator-name = "vdd_cpu_avs";
> +				regulator-min-microvolt = <600000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka4: buck4 {
> +				regulator-name = "vdd_mcu_0v85";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka5: buck5 {
> +				regulator-name = "vdd_phyio_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa1: ldo1 {
> +				regulator-name = "vdd1_lpddr4_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa2: ldo2 {
> +				regulator-name = "vdd_mcuio_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa3: ldo3 {
> +				regulator-name = "vdda_dll_0v8";
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa4: ldo4 {
> +				regulator-name = "vda_mcu_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +		};
> +	};
> +
> +	tps659411: pmic at 4c {
> +		compatible = "ti,tps6594-q1";
> +		reg = <0x4c>;
> +		system-power-controller;
> +		interrupt-parent = <&wkup_gpio0>;
> +		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
> +
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +		buck1234-supply = <&vsys_3v3>;
> +		buck5-supply = <&vsys_3v3>;
> +		ldo1-supply = <&vsys_3v3>;
> +		ldo2-supply = <&vsys_3v3>;
> +		ldo3-supply = <&vsys_3v3>;
> +		ldo4-supply = <&vsys_3v3>;
> +
> +		regulators {
> +			buckb1234: buck1234 {
> +				regulator-name = "vdd_core_0v8";
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			buckb5: buck5 {
> +				regulator-name = "vdd_ram_0v85";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldob1: ldo1 {
> +				regulator-name = "vdd_sd_dv";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldob2: ldo2 {
> +				regulator-name = "vdd_usb_3v3";
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldob3: ldo3 {
> +				regulator-name = "vdd_io_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldob4: ldo4 {
> +				regulator-name = "vda_pll_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +		};
> +	};
>  };
>  
>  &mcu_uart0 {
> -- 
> 2.34.1
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From will at kernel.org  Tue Dec  5 07:16:32 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:32 +0000
Subject: [PATCH] arm64: vdso32: rename 32-bit debug vdso to vdso32.so.dbg
In-Reply-To: <20231117125620.1058300-1-masahiroy@kernel.org>
References: <20231117125620.1058300-1-masahiroy@kernel.org>
Message-ID: <170177699377.3454535.14962966962244524648.b4-ty@kernel.org>

On Fri, 17 Nov 2023 21:56:19 +0900, Masahiro Yamada wrote:
> 'make vdso_install' renames arch/arm64/kernel/vdso32/vdso.so.dbg to
> vdso32.so during installation, which allows 64-bit and 32-bit vdso
> files to be installed in the same directory.
> 
> However, arm64 is the only architecture that requires this renaming.
> 
> To simplify the vdso_install logic, rename the in-tree vdso file so
> its base name matches the installed file name.
> 
> [...]

Applied to arm64 (for-next/kbuild), thanks!

[1/1] arm64: vdso32: rename 32-bit debug vdso to vdso32.so.dbg
      https://git.kernel.org/arm64/c/a099bec7a810

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:31 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:31 +0000
Subject: [PATCH] arm64: replace <asm-generic/export.h> with <linux/export.h>
In-Reply-To: <20231126151045.1556686-1-masahiroy@kernel.org>
References: <20231126151045.1556686-1-masahiroy@kernel.org>
Message-ID: <170178637204.13485.9657121759443285683.b4-ty@kernel.org>

On Mon, 27 Nov 2023 00:10:45 +0900, Masahiro Yamada wrote:
> Commit ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
> deprecated <asm-generic/export.h>, which is now a wrapper of
> <linux/export.h>.
> 
> Replace #include <asm-generic/export.h> with #include <linux/export.h>.
> 
> 
> [...]

Applied to arm64 (for-next/kbuild), thanks!

[1/1] arm64: replace <asm-generic/export.h> with <linux/export.h>
      https://git.kernel.org/arm64/c/8fd7588fd4ee

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:33 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:33 +0000
Subject: [PATCH] arm64: Get rid of ARM64_HAS_NO_HW_PREFETCH
In-Reply-To: <20231122133754.1240687-1-maz@kernel.org>
References: <20231122133754.1240687-1-maz@kernel.org>
Message-ID: <170177777329.104058.13587225028994834846.b4-ty@kernel.org>

On Wed, 22 Nov 2023 13:37:54 +0000, Marc Zyngier wrote:
> Back in 2016, it was argued that implementations lacking a HW
> prefetcher could be helped by sprinkling a number of PRFM
> instructions in strategic locations.
> 
> In 2023, the one platform that presumably needed this hack is no
> longer in active use (let alone maintained), and an quick
> experiment shows dropping this hack only leads to a 0.4% drop
> on a full kernel compilation (tested on a MT30-GS0 48 CPU system).
> 
> [...]

Applied to arm64 (for-next/cpufeature), thanks!

[1/1] arm64: Get rid of ARM64_HAS_NO_HW_PREFETCH
      https://git.kernel.org/arm64/c/103423ad7e56

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:34 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:34 +0000
Subject: [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy
In-Reply-To: <20231204143606.1806432-1-maz@kernel.org>
References: <20231204143606.1806432-1-maz@kernel.org>
Message-ID: <170177628445.1801906.11394045917050132780.b4-ty@kernel.org>

On Mon, 4 Dec 2023 14:36:03 +0000, Marc Zyngier wrote:
> ARMv8.2 introduced support for VPIPT i-caches, the V standing for
> VMID-tagged. Although this looked like a reasonable idea, no
> implementation has ever made it into the wild.
> 
> Linux has supported this for over 6 years (amusingly, just as the
> architecture was dropping support for AIVIVT i-caches), but we had no
> way to even test it, and it is likely that this code was just
> bit-rotting.
> 
> [...]

Applied to arm64 (for-next/rip-vpipt), thanks!

[1/3] KVM: arm64: Remove VPIPT I-cache handling
      https://git.kernel.org/arm64/c/ced242ba9d7c
[2/3] arm64: Kill detection of VPIPT i-cache policy
      https://git.kernel.org/arm64/c/d8e12a0d3715
[3/3] arm64: Rename reserved values for CTR_EL0.L1Ip
      https://git.kernel.org/arm64/c/f35c32ca6839

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:35 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:35 +0000
Subject: [PATCH] perf/arm-cmn: Fix HN-F class_occup_id events
In-Reply-To: <5a22439de84ff188ef76674798052448eb03a3e1.1700740693.git.robin.murphy@arm.com>
References: <5a22439de84ff188ef76674798052448eb03a3e1.1700740693.git.robin.murphy@arm.com>
Message-ID: <170177862294.1058818.4996860407789168968.b4-ty@kernel.org>

On Thu, 23 Nov 2023 11:58:13 +0000, Robin Murphy wrote:
> A subtle copy-paste error managed to slip through the reorganisation
> of these patches in development, and not only give some HN-F events
> the wrong type, but use that wrong type before the subsequent patch
> defined it. Too late to fix history, but we can at least fix the bug.
> 
> 

Applied to will (for-next/perf), thanks!

[1/1] perf/arm-cmn: Fix HN-F class_occup_id events
      https://git.kernel.org/will/c/590f23b09240

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:36 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:36 +0000
Subject: [PATCH v4] arm64: irq: set the correct node for VMAP stack
In-Reply-To: <20231124031513.81548-1-shijie@os.amperecomputing.com>
References: <ZV-EA46rBJ9WK4UH@arm.com> <20231124031513.81548-1-shijie@os.amperecomputing.com>
Message-ID: <170178641072.13754.15163791015207648414.b4-ty@kernel.org>

On Fri, 24 Nov 2023 11:15:13 +0800, Huang Shijie wrote:
> In current code, init_irq_stacks() will call cpu_to_node().
> The cpu_to_node() depends on percpu "numa_node" which is initialized in:
>      arch_call_rest_init() --> rest_init() -- kernel_init()
> 	--> kernel_init_freeable() --> smp_prepare_cpus()
> 
> But init_irq_stacks() is called in init_IRQ() which is before
> arch_call_rest_init().
> 
> [...]

Applied to arm64 (for-next/mm), thanks!

[1/1] arm64: irq: set the correct node for VMAP stack
      https://git.kernel.org/arm64/c/75b5e0bf90bf

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:37 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:37 +0000
Subject: [PATCH] Dcoumentation/arch/arm64: fix typo
In-Reply-To: <20231203011804.27694-1-tsunghan.tw@gmail.com>
References: <20231203011804.27694-1-tsunghan.tw@gmail.com>
Message-ID: <170178649190.14021.17307806382838211619.b4-ty@kernel.org>

On Sun, 3 Dec 2023 09:18:04 +0800, Tsung-Han Lin wrote:
> Should be 'if' here.
> 
> 

I, err, fixed the typo in the subject when applying this...

Applied to arm64 (for-next/misc), thanks!

[1/1] Dcoumentation/arch/arm64: fix typo
      https://git.kernel.org/arm64/c/365b1900c93a

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec  5 07:16:38 2023
From: will at kernel.org (Will Deacon)
Date: Tue,  5 Dec 2023 15:16:38 +0000
Subject: [PATCH v3 1/5] perf: fsl_imx8_ddr: Add AXI ID PORT CHANNEL filter support
In-Reply-To: <20231120093317.2652866-1-xu.yang_2@nxp.com>
References: <20231120093317.2652866-1-xu.yang_2@nxp.com>
Message-ID: <170178552961.2948567.1593321424507215483.b4-ty@kernel.org>

On Mon, 20 Nov 2023 17:33:13 +0800, Xu Yang wrote:
> This is the extension of AXI ID filter.
> 
> Filter is defined with 2 configuration registers per counter 1-3 (counter
> 0 is not used for filtering and lacks these registers).
> * Counter N MASK COMP register - AXI_ID and AXI_MASKING.
> * Counter N MUX CNTL register - AXI CHANNEL and AXI PORT.
>   -- 0: address channel
>   -- 1: data channel
> 
> [...]

Applied first four patches to will (for-next/perf), thanks!

[1/5] perf: fsl_imx8_ddr: Add AXI ID PORT CHANNEL filter support
      https://git.kernel.org/will/c/afd83967e7bb
[2/5] docs/perf: Add explanation for DDR_CAP_AXI_ID_PORT_CHANNEL_FILTER quirk
      https://git.kernel.org/will/c/9745295358f4
[3/5] dt-bindings: perf: fsl-imx-ddr: Add i.MX8DXL compatible
      https://git.kernel.org/will/c/2fe44e7dcb86
[4/5] perf: fsl_imx8_ddr: Add driver support for i.MX8DXL DDR Perf
      https://git.kernel.org/will/c/46fe448ec3b7

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From nm at ti.com  Tue Dec  5 07:19:21 2023
From: nm at ti.com (Nishanth Menon)
Date: Tue, 5 Dec 2023 09:19:21 -0600
Subject: [PATCH] arm64: dts: ti: k3-am62-main: Add GPU device node
In-Reply-To: <c20b213534667337f08b75a6c325fafec6526135.camel@siemens.com>
References: <20231204121522.47862-1-donald.robson@imgtec.com>
 <c20b213534667337f08b75a6c325fafec6526135.camel@siemens.com>
Message-ID: <20231205151921.orba632qpuf2nmxf@wildness>

On 11:15-20231205, Sverdlin, Alexander wrote:
> Hi Donald, Sarah et al,
> 
> thanks for the patch!
> 
> On Mon, 2023-12-04 at 12:15 +0000, Donald Robson wrote:
> > From: Sarah Walker <sarah.walker at imgtec.com>
> > 
> > Add the Series AXE GPU node to the AM62 device tree.
> > 
> > Signed-off-by: Sarah Walker <sarah.walker at imgtec.com>
> > Signed-off-by: Donald Robson <donald.robson at imgtec.com>
> 
> powervr fd00000.gpu: [drm] loaded firmware powervr/rogue_33.15.11.3_v1.fw
> powervr fd00000.gpu: [drm] FW version v1.0 (build 6503725 OS)
> [drm] Initialized powervr 1.0.0 20230904 for fd00000.gpu on minor 0
> 
> In general it allows the driver to be probed on TI AM625 EK, so
> Tested-by: Alexander Sverdlin <alexander.sverdlin at siemens.com>
> 
> But I'm not sure if you maybe want to disable it by default like
> other HW blocks for the (potential) boards which don't have video at all.

There is no board level dependency for GPU, so only place we have
permitted status = "disabled" is when the node has specific board
interface level (pinmux...) to  be operational completely.

So, no, default shouldn't have a status = "disabled".

> 
> > ---
> > ?arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 9 +++++++++
> > ?1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> > index e5c64c86d1d5..4338fd8ab2d7 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> > +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> > @@ -965,4 +965,13 @@ mcasp2: audio-controller at 2b20000 {
> > ????????????????power-domains = <&k3_pds 192 TI_SCI_PD_EXCLUSIVE>;
> > ????????????????status = "disabled";
> > ????????};
> > +
> > +???????gpu: gpu at fd00000 {
> > +???????????????compatible = "ti,am62-gpu", "img,img-axe";
> > +???????????????reg = <0x00 0x0fd00000 0x00 0x20000>;
> > +???????????????clocks = <&k3_clks 187 0>;
> > +???????????????clock-names = "core";
> > +???????????????interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
> > +???????????????power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>;
> > +???????};
> > ?};
> 
> -- 
> Alexander Sverdlin
> Siemens AG
> www.siemens.com

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From acme at kernel.org  Tue Dec  5 07:19:53 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Tue, 5 Dec 2023 12:19:53 -0300
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
References: <20231204182330.654255-1-irogers@google.com>
 <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
Message-ID: <ZW8/mWUuctdg/8fE@kernel.org>

Em Mon, Dec 04, 2023 at 02:44:54PM -0800, Ilkka Koskinen escreveu:
> 
> 
> On Mon, 4 Dec 2023, Ian Rogers wrote:
> > A metric is default by having "Default" within its groups. The default
> > metricgroup name needn't be set and this can result in segv in
> > default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
> > that assume it has a value when there is a Default metric group. To
> > avoid the segv initialize the value to "".
> > 
> > Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
> > Signed-off-by: Ian Rogers <irogers at google.com>
> 
> Thanks! I was going to look for the bug but got pulled to other tasks. The
> patch looks good to me and I tested it successfully on AmpereOne.
> 
>   Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>

Thanks, applied to perf-tools-next.

- Arnaldo



From herve.codina at bootlin.com  Tue Dec  5 07:21:00 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:00 +0100
Subject: [PATCH v2 03/17] soc: fsl: cpm1: qmc: Fix rx channel reset
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-4-herve.codina@bootlin.com>

The qmc_chan_reset_rx() set the is_rx_stopped flag. This leads to an
inconsistent state in the following sequence.
    qmc_chan_stop()
    qmc_chan_reset()
Indeed, after the qmc_chan_reset() call, the channel must still be
stopped. Only a qmc_chan_start() call can move the channel from stopped
state to started state.

Fix the issue removing the is_rx_stopped flag setting from
qmc_chan_reset()

Fixes: 3178d58e0b97 ("soc: fsl: cpm1: Add support for QMC")
Cc: stable at vger.kernel.org
Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 3f3de1351c96..2312152a44b3 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -685,7 +685,6 @@ static void qmc_chan_reset_rx(struct qmc_chan *chan)
 		    qmc_read16(chan->s_param + QMC_SPE_RBASE));
 
 	chan->rx_pending = 0;
-	chan->is_rx_stopped = false;
 
 	spin_unlock_irqrestore(&chan->rx_lock, flags);
 }
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:20:58 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:20:58 +0100
Subject: [PATCH v2 01/17] soc: fsl: cpm1: tsa: Fix __iomem addresses declaration
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-2-herve.codina@bootlin.com>

Running sparse (make C=1) on tsa.c raises a lot of warning such as:
  --- 8< ---
  warning: incorrect type in assignment (different address spaces)
     expected void *[noderef] si_regs
     got void [noderef] __iomem *
  --- 8< ---

Indeed, some variable were declared 'type *__iomem var' instead of
'type __iomem *var'.

Use the correct declaration to remove these warnings.

Fixes: 1d4ba0b81c1c ("soc: fsl: cpm1: Add support for TSA")
Cc: stable at vger.kernel.org
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312051959.9YdRIYbg-lkp at intel.com/
Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/tsa.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/soc/fsl/qe/tsa.c b/drivers/soc/fsl/qe/tsa.c
index 3f9981335590..6c5741cf5e9d 100644
--- a/drivers/soc/fsl/qe/tsa.c
+++ b/drivers/soc/fsl/qe/tsa.c
@@ -98,9 +98,9 @@
 #define TSA_SIRP	0x10
 
 struct tsa_entries_area {
-	void *__iomem entries_start;
-	void *__iomem entries_next;
-	void *__iomem last_entry;
+	void __iomem *entries_start;
+	void __iomem *entries_next;
+	void __iomem *last_entry;
 };
 
 struct tsa_tdm {
@@ -117,8 +117,8 @@ struct tsa_tdm {
 
 struct tsa {
 	struct device *dev;
-	void *__iomem si_regs;
-	void *__iomem si_ram;
+	void __iomem *si_regs;
+	void __iomem *si_ram;
 	resource_size_t si_ram_sz;
 	spinlock_t	lock;
 	int tdms; /* TSA_TDMx ORed */
@@ -135,27 +135,27 @@ static inline struct tsa *tsa_serial_get_tsa(struct tsa_serial *tsa_serial)
 	return container_of(tsa_serial, struct tsa, serials[tsa_serial->id]);
 }
 
-static inline void tsa_write32(void *__iomem addr, u32 val)
+static inline void tsa_write32(void __iomem *addr, u32 val)
 {
 	iowrite32be(val, addr);
 }
 
-static inline void tsa_write8(void *__iomem addr, u32 val)
+static inline void tsa_write8(void __iomem *addr, u32 val)
 {
 	iowrite8(val, addr);
 }
 
-static inline u32 tsa_read32(void *__iomem addr)
+static inline u32 tsa_read32(void __iomem *addr)
 {
 	return ioread32be(addr);
 }
 
-static inline void tsa_clrbits32(void *__iomem addr, u32 clr)
+static inline void tsa_clrbits32(void __iomem *addr, u32 clr)
 {
 	tsa_write32(addr, tsa_read32(addr) & ~clr);
 }
 
-static inline void tsa_clrsetbits32(void *__iomem addr, u32 clr, u32 set)
+static inline void tsa_clrsetbits32(void __iomem *addr, u32 clr, u32 set)
 {
 	tsa_write32(addr, (tsa_read32(addr) & ~clr) | set);
 }
@@ -313,7 +313,7 @@ static u32 tsa_serial_id2csel(struct tsa *tsa, u32 serial_id)
 static int tsa_add_entry(struct tsa *tsa, struct tsa_entries_area *area,
 			 u32 count, u32 serial_id)
 {
-	void *__iomem addr;
+	void __iomem *addr;
 	u32 left;
 	u32 val;
 	u32 cnt;
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:02 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:02 +0100
Subject: [PATCH v2 05/17] soc: fsl: cpm1: qmc: Remove inline function specifiers
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-6-herve.codina@bootlin.com>

The inline function specifier is present on some functions but it is
better to let the compiler decide inlining or not these functions.

Remove inline specifiers.

Fixes: 3178d58e0b97 ("soc: fsl: cpm1: Add support for QMC")
Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Suggested-by: Andrew Lunn <andrew at lunn.ch>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 4b4832d93c9b..27f2f16deac9 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -218,37 +218,37 @@ struct qmc {
 	struct qmc_chan *chans[64];
 };
 
-static inline void qmc_write16(void __iomem *addr, u16 val)
+static void qmc_write16(void __iomem *addr, u16 val)
 {
 	iowrite16be(val, addr);
 }
 
-static inline u16 qmc_read16(void __iomem *addr)
+static u16 qmc_read16(void __iomem *addr)
 {
 	return ioread16be(addr);
 }
 
-static inline void qmc_setbits16(void __iomem *addr, u16 set)
+static void qmc_setbits16(void __iomem *addr, u16 set)
 {
 	qmc_write16(addr, qmc_read16(addr) | set);
 }
 
-static inline void qmc_clrbits16(void __iomem *addr, u16 clr)
+static void qmc_clrbits16(void __iomem *addr, u16 clr)
 {
 	qmc_write16(addr, qmc_read16(addr) & ~clr);
 }
 
-static inline void qmc_write32(void __iomem *addr, u32 val)
+static void qmc_write32(void __iomem *addr, u32 val)
 {
 	iowrite32be(val, addr);
 }
 
-static inline u32 qmc_read32(void __iomem *addr)
+static u32 qmc_read32(void __iomem *addr)
 {
 	return ioread32be(addr);
 }
 
-static inline void qmc_setbits32(void __iomem *addr, u32 set)
+static void qmc_setbits32(void __iomem *addr, u32 set)
 {
 	qmc_write32(addr, qmc_read32(addr) | set);
 }
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:20:59 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:20:59 +0100
Subject: [PATCH v2 02/17] soc: fsl: cpm1: qmc: Fix __iomem addresses declaration
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-3-herve.codina@bootlin.com>

Running sparse (make C=1) on qmc.c raises a lot of warning such as:
  ...
  warning: incorrect type in assignment (different address spaces)
     expected struct cpm_buf_desc [usertype] *[noderef] __iomem bd
     got struct cpm_buf_desc [noderef] [usertype] __iomem *txbd_free
  ...

Indeed, some variable were declared 'type *__iomem var' instead of
'type __iomem *var'.

Use the correct declaration to remove these warnings.

Fixes: 3178d58e0b97 ("soc: fsl: cpm1: Add support for QMC")
Cc: stable at vger.kernel.org
Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 92ec76c03965..3f3de1351c96 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -175,7 +175,7 @@ struct qmc_chan {
 	struct list_head list;
 	unsigned int id;
 	struct qmc *qmc;
-	void *__iomem s_param;
+	void __iomem *s_param;
 	enum qmc_mode mode;
 	u64	tx_ts_mask;
 	u64	rx_ts_mask;
@@ -203,9 +203,9 @@ struct qmc_chan {
 struct qmc {
 	struct device *dev;
 	struct tsa_serial *tsa_serial;
-	void *__iomem scc_regs;
-	void *__iomem scc_pram;
-	void *__iomem dpram;
+	void __iomem *scc_regs;
+	void __iomem *scc_pram;
+	void __iomem *dpram;
 	u16 scc_pram_offset;
 	cbd_t __iomem *bd_table;
 	dma_addr_t bd_dma_addr;
@@ -218,37 +218,37 @@ struct qmc {
 	struct qmc_chan *chans[64];
 };
 
-static inline void qmc_write16(void *__iomem addr, u16 val)
+static inline void qmc_write16(void __iomem *addr, u16 val)
 {
 	iowrite16be(val, addr);
 }
 
-static inline u16 qmc_read16(void *__iomem addr)
+static inline u16 qmc_read16(void __iomem *addr)
 {
 	return ioread16be(addr);
 }
 
-static inline void qmc_setbits16(void *__iomem addr, u16 set)
+static inline void qmc_setbits16(void __iomem *addr, u16 set)
 {
 	qmc_write16(addr, qmc_read16(addr) | set);
 }
 
-static inline void qmc_clrbits16(void *__iomem addr, u16 clr)
+static inline void qmc_clrbits16(void __iomem *addr, u16 clr)
 {
 	qmc_write16(addr, qmc_read16(addr) & ~clr);
 }
 
-static inline void qmc_write32(void *__iomem addr, u32 val)
+static inline void qmc_write32(void __iomem *addr, u32 val)
 {
 	iowrite32be(val, addr);
 }
 
-static inline u32 qmc_read32(void *__iomem addr)
+static inline u32 qmc_read32(void __iomem *addr)
 {
 	return ioread32be(addr);
 }
 
-static inline void qmc_setbits32(void *__iomem addr, u32 set)
+static inline void qmc_setbits32(void __iomem *addr, u32 set)
 {
 	qmc_write32(addr, qmc_read32(addr) | set);
 }
@@ -318,7 +318,7 @@ int qmc_chan_write_submit(struct qmc_chan *chan, dma_addr_t addr, size_t length,
 {
 	struct qmc_xfer_desc *xfer_desc;
 	unsigned long flags;
-	cbd_t *__iomem bd;
+	cbd_t __iomem *bd;
 	u16 ctrl;
 	int ret;
 
@@ -374,7 +374,7 @@ static void qmc_chan_write_done(struct qmc_chan *chan)
 	void (*complete)(void *context);
 	unsigned long flags;
 	void *context;
-	cbd_t *__iomem bd;
+	cbd_t __iomem *bd;
 	u16 ctrl;
 
 	/*
@@ -425,7 +425,7 @@ int qmc_chan_read_submit(struct qmc_chan *chan, dma_addr_t addr, size_t length,
 {
 	struct qmc_xfer_desc *xfer_desc;
 	unsigned long flags;
-	cbd_t *__iomem bd;
+	cbd_t __iomem *bd;
 	u16 ctrl;
 	int ret;
 
@@ -488,7 +488,7 @@ static void qmc_chan_read_done(struct qmc_chan *chan)
 	void (*complete)(void *context, size_t size);
 	struct qmc_xfer_desc *xfer_desc;
 	unsigned long flags;
-	cbd_t *__iomem bd;
+	cbd_t __iomem *bd;
 	void *context;
 	u16 datalen;
 	u16 ctrl;
@@ -663,7 +663,7 @@ static void qmc_chan_reset_rx(struct qmc_chan *chan)
 {
 	struct qmc_xfer_desc *xfer_desc;
 	unsigned long flags;
-	cbd_t *__iomem bd;
+	cbd_t __iomem *bd;
 	u16 ctrl;
 
 	spin_lock_irqsave(&chan->rx_lock, flags);
@@ -694,7 +694,7 @@ static void qmc_chan_reset_tx(struct qmc_chan *chan)
 {
 	struct qmc_xfer_desc *xfer_desc;
 	unsigned long flags;
-	cbd_t *__iomem bd;
+	cbd_t __iomem *bd;
 	u16 ctrl;
 
 	spin_lock_irqsave(&chan->tx_lock, flags);
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:01 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:01 +0100
Subject: [PATCH v2 04/17] soc: fsl: cpm1: qmc: Extend the API to provide Rx status
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-5-herve.codina@bootlin.com>

In HDLC mode, some status flags related to the data read transfer can be
set by the hardware and need to be known by a QMC consumer for further
analysis.

Extend the API in order to provide these transfer status flags at the
read complete() call.

In TRANSPARENT mode, these flags have no meaning. Keep only one read
complete() API and update the consumers working in transparent mode.
In this case, the newly introduced flags parameter is simply unused.

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c      | 29 +++++++++++++++++++++++++----
 include/soc/fsl/qe/qmc.h      | 15 ++++++++++++++-
 sound/soc/fsl/fsl_qmc_audio.c |  2 +-
 3 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 2312152a44b3..4b4832d93c9b 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -166,7 +166,7 @@
 struct qmc_xfer_desc {
 	union {
 		void (*tx_complete)(void *context);
-		void (*rx_complete)(void *context, size_t length);
+		void (*rx_complete)(void *context, size_t length, unsigned int flags);
 	};
 	void *context;
 };
@@ -421,7 +421,8 @@ static void qmc_chan_write_done(struct qmc_chan *chan)
 }
 
 int qmc_chan_read_submit(struct qmc_chan *chan, dma_addr_t addr, size_t length,
-			 void (*complete)(void *context, size_t length), void *context)
+			 void (*complete)(void *context, size_t length, unsigned int flags),
+			 void *context)
 {
 	struct qmc_xfer_desc *xfer_desc;
 	unsigned long flags;
@@ -454,6 +455,10 @@ int qmc_chan_read_submit(struct qmc_chan *chan, dma_addr_t addr, size_t length,
 	xfer_desc->rx_complete = complete;
 	xfer_desc->context = context;
 
+	/* Clear previous status flags */
+	ctrl &= ~(QMC_BD_RX_L | QMC_BD_RX_F | QMC_BD_RX_LG | QMC_BD_RX_NO |
+		  QMC_BD_RX_AB | QMC_BD_RX_CR);
+
 	/* Activate the descriptor */
 	ctrl |= (QMC_BD_RX_E | QMC_BD_RX_UB);
 	wmb(); /* Be sure to flush data before descriptor activation */
@@ -485,7 +490,7 @@ EXPORT_SYMBOL(qmc_chan_read_submit);
 
 static void qmc_chan_read_done(struct qmc_chan *chan)
 {
-	void (*complete)(void *context, size_t size);
+	void (*complete)(void *context, size_t size, unsigned int flags);
 	struct qmc_xfer_desc *xfer_desc;
 	unsigned long flags;
 	cbd_t __iomem *bd;
@@ -527,7 +532,23 @@ static void qmc_chan_read_done(struct qmc_chan *chan)
 
 		if (complete) {
 			spin_unlock_irqrestore(&chan->rx_lock, flags);
-			complete(context, datalen);
+
+			/*
+			 * Avoid conversion between internal hardware flags and
+			 * the software API flags.
+			 * -> Be sure that the software API flags are consistent
+			 *    with the hardware flags
+			 */
+			BUILD_BUG_ON(QMC_RX_FLAG_HDLC_LAST  != QMC_BD_RX_L);
+			BUILD_BUG_ON(QMC_RX_FLAG_HDLC_FIRST != QMC_BD_RX_F);
+			BUILD_BUG_ON(QMC_RX_FLAG_HDLC_OVF   != QMC_BD_RX_LG);
+			BUILD_BUG_ON(QMC_RX_FLAG_HDLC_UNA   != QMC_BD_RX_NO);
+			BUILD_BUG_ON(QMC_RX_FLAG_HDLC_ABORT != QMC_BD_RX_AB);
+			BUILD_BUG_ON(QMC_RX_FLAG_HDLC_CRC   != QMC_BD_RX_CR);
+
+			complete(context, datalen,
+				 ctrl & (QMC_BD_RX_L | QMC_BD_RX_F | QMC_BD_RX_LG |
+					 QMC_BD_RX_NO | QMC_BD_RX_AB | QMC_BD_RX_CR));
 			spin_lock_irqsave(&chan->rx_lock, flags);
 		}
 
diff --git a/include/soc/fsl/qe/qmc.h b/include/soc/fsl/qe/qmc.h
index 3c61a50d2ae2..6f1d6cebc9fe 100644
--- a/include/soc/fsl/qe/qmc.h
+++ b/include/soc/fsl/qe/qmc.h
@@ -9,6 +9,7 @@
 #ifndef __SOC_FSL_QMC_H__
 #define __SOC_FSL_QMC_H__
 
+#include <linux/bits.h>
 #include <linux/types.h>
 
 struct device_node;
@@ -56,8 +57,20 @@ int qmc_chan_set_param(struct qmc_chan *chan, const struct qmc_chan_param *param
 int qmc_chan_write_submit(struct qmc_chan *chan, dma_addr_t addr, size_t length,
 			  void (*complete)(void *context), void *context);
 
+/* Flags available (ORed) for read complete() flags parameter in HDLC mode.
+ * No flags are available in transparent mode and the read complete() flags
+ * parameter has no meaning in transparent mode.
+ */
+#define QMC_RX_FLAG_HDLC_LAST	BIT(11) /* Last in frame */
+#define QMC_RX_FLAG_HDLC_FIRST	BIT(10) /* First in frame */
+#define QMC_RX_FLAG_HDLC_OVF	BIT(5)  /* Data overflow */
+#define QMC_RX_FLAG_HDLC_UNA	BIT(4)  /* Unaligned (ie. bits received not multiple of 8) */
+#define QMC_RX_FLAG_HDLC_ABORT	BIT(3)  /* Received an abort sequence (seven consecutive ones) */
+#define QMC_RX_FLAG_HDLC_CRC	BIT(2)  /* CRC error */
+
 int qmc_chan_read_submit(struct qmc_chan *chan, dma_addr_t addr, size_t length,
-			 void (*complete)(void *context, size_t length),
+			 void (*complete)(void *context, size_t length,
+					  unsigned int flags),
 			 void *context);
 
 #define QMC_CHAN_READ  (1<<0)
diff --git a/sound/soc/fsl/fsl_qmc_audio.c b/sound/soc/fsl/fsl_qmc_audio.c
index 56d6b0b039a2..bfaaa451735b 100644
--- a/sound/soc/fsl/fsl_qmc_audio.c
+++ b/sound/soc/fsl/fsl_qmc_audio.c
@@ -99,7 +99,7 @@ static void qmc_audio_pcm_write_complete(void *context)
 	snd_pcm_period_elapsed(prtd->substream);
 }
 
-static void qmc_audio_pcm_read_complete(void *context, size_t length)
+static void qmc_audio_pcm_read_complete(void *context, size_t length, unsigned int flags)
 {
 	struct qmc_dai_prtd *prtd = context;
 	int ret;
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:20:57 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:20:57 +0100
Subject: [PATCH v2 00/17] Prepare the PowerQUICC QMC and TSA for the HDLC QMC driver
Message-ID: <20231205152116.122512-1-herve.codina@bootlin.com>

Hi,

This series updates PowerQUICC QMC and TSA drivers to prepare the
support for the QMC HDLC driver.

Patches were previously sent as part of a full feature series:
"Add support for QMC HDLC, framer infrastructure and PEF2256 framer" [1]

The full feature series reached the v9 iteration.
The v1 was sent the 07/25/2023 followed by the other iterations
(07/26/2023, 08/09/2023, 08/18/2023, 09/12/2023, 09/22/2023, 09/28/2023,
10/11/23, 11/15/2023) and was ready to be merged in its v8.
  https://lore.kernel.org/linux-kernel/20231025123215.5caca7d4 at kernel.org/

The lack of feedback from the Freescale SoC and the Quicc Engine
maintainers (i.e. drivers/soc/fsl/qe/ to which the QMC and TSA drivers
belong) blocks the entire full feature series.
These patches are fixes and improvements to TSA and QMC drivers.
These drivers were previously acked by Li Yang but without any feedback
from Li Yang nor Qiang Zhao the series cannot move forward.

In order to ease the review/merge, the full feature series has been
split and this series contains patches related to the PowerQUICC SoC
part (QMC and TSA).
 - Perform some fixes (patches 1 to 5)
 - Add support for child devices (patch 6)
 - Add QMC dynamic timeslot support (patches 7 to 17)

Compare to the previous iteration:
  https://lore.kernel.org/linux-kernel/20231128140818.261541-1-herve.codina at bootlin.com/
this v2 series:
- Removes a forward declaration in the driver.
- Adds kernel test robot tags as the issue was detected.
- Adds some missing Cc: stable.

Best regards,
Herv?

[1]: https://lore.kernel.org/linux-kernel/20231115144007.478111-1-herve.codina at bootlin.com/

Changes v1 -> v2:
  - Patch 1
    Add 'Reported-by: kernel test robot <lkp at intel.com>'
    Add 'Closes: https://lore.kernel.org/oe-kbuild-all/202312051959.9YdRIYbg-lkp at intel.com/'
    Add 'Cc: stable at vger.kernel.org'

  - Patch 2, 3
    Add 'Cc: stable at vger.kernel.org

  - Patch 15
    Move qmc_setup_chan_trnsync() to avoid a forward declaration.

Patches extracted:
  - Patch 1..6 : full feature series patch 1..6
  - Patch 7..17 : full feature series patch 9..19

Herve Codina (17):
  soc: fsl: cpm1: tsa: Fix __iomem addresses declaration
  soc: fsl: cpm1: qmc: Fix __iomem addresses declaration
  soc: fsl: cpm1: qmc: Fix rx channel reset
  soc: fsl: cpm1: qmc: Extend the API to provide Rx status
  soc: fsl: cpm1: qmc: Remove inline function specifiers
  soc: fsl: cpm1: qmc: Add support for child devices
  soc: fsl: cpm1: qmc: Introduce available timeslots masks
  soc: fsl: cpm1: qmc: Rename qmc_setup_tsa* to qmc_init_tsa*
  soc: fsl: cpm1: qmc: Introduce qmc_chan_setup_tsa*
  soc: fsl: cpm1: qmc: Remove no more needed checks from
    qmc_check_chans()
  soc: fsl: cpm1: qmc: Check available timeslots in qmc_check_chans()
  soc: fsl: cpm1: qmc: Add support for disabling channel TSA entries
  soc: fsl: cpm1: qmc: Split Tx and Rx TSA entries setup
  soc: fsl: cpm1: qmc: Introduce is_tsa_64rxtx flag
  soc: fsl: cpm1: qmc: Handle timeslot entries at channel start() and
    stop()
  soc: fsl: cpm1: qmc: Remove timeslots handling from setup_chan()
  soc: fsl: cpm1: qmc: Introduce functions to change timeslots at
    runtime

 drivers/soc/fsl/qe/qmc.c      | 658 ++++++++++++++++++++++++++--------
 drivers/soc/fsl/qe/tsa.c      |  22 +-
 include/soc/fsl/qe/qmc.h      |  27 +-
 sound/soc/fsl/fsl_qmc_audio.c |   2 +-
 4 files changed, 538 insertions(+), 171 deletions(-)

-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:04 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:04 +0100
Subject: [PATCH v2 07/17] soc: fsl: cpm1: qmc: Introduce available timeslots masks
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-8-herve.codina@bootlin.com>

Available timeslots masks define timeslots available for the related
channel. These timeslots are defined by the QMC binding.

Timeslots used are initialized to available timeslots but can be a
subset of available timeslots.
This prepares the dynamic timeslots management (ie. changing timeslots
at runtime).

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index e716f13669a0..0413e25d4c67 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -177,7 +177,9 @@ struct qmc_chan {
 	struct qmc *qmc;
 	void __iomem *s_param;
 	enum qmc_mode mode;
+	u64	tx_ts_mask_avail;
 	u64	tx_ts_mask;
+	u64	rx_ts_mask_avail;
 	u64	rx_ts_mask;
 	bool is_reverse_data;
 
@@ -875,7 +877,8 @@ static int qmc_of_parse_chans(struct qmc *qmc, struct device_node *np)
 			of_node_put(chan_np);
 			return ret;
 		}
-		chan->tx_ts_mask = ts_mask;
+		chan->tx_ts_mask_avail = ts_mask;
+		chan->tx_ts_mask = chan->tx_ts_mask_avail;
 
 		ret = of_property_read_u64(chan_np, "fsl,rx-ts-mask", &ts_mask);
 		if (ret) {
@@ -884,7 +887,8 @@ static int qmc_of_parse_chans(struct qmc *qmc, struct device_node *np)
 			of_node_put(chan_np);
 			return ret;
 		}
-		chan->rx_ts_mask = ts_mask;
+		chan->rx_ts_mask_avail = ts_mask;
+		chan->rx_ts_mask = chan->rx_ts_mask_avail;
 
 		mode = "transparent";
 		ret = of_property_read_string(chan_np, "fsl,operational-mode", &mode);
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:03 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:03 +0100
Subject: [PATCH v2 06/17] soc: fsl: cpm1: qmc: Add support for child devices
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-7-herve.codina@bootlin.com>

QMC child devices support is needed to avoid orphan DT nodes that use a
simple DT phandle to reference a QMC channel.

Allow to instantiate child devices and also extend the API to get the
qmc_chan using a child device.

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
---
 drivers/soc/fsl/qe/qmc.c | 91 +++++++++++++++++++++++++++++++---------
 include/soc/fsl/qe/qmc.h |  2 +
 2 files changed, 73 insertions(+), 20 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 27f2f16deac9..e716f13669a0 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -1425,8 +1425,16 @@ static int qmc_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, qmc);
 
+	/* Populate channel related devices */
+	ret = devm_of_platform_populate(qmc->dev);
+	if (ret)
+		goto err_disable_txrx;
+
 	return 0;
 
+err_disable_txrx:
+	qmc_setbits32(qmc->scc_regs + SCC_GSMRL, 0);
+
 err_disable_intr:
 	qmc_write16(qmc->scc_regs + SCC_SCCM, 0);
 
@@ -1465,26 +1473,16 @@ static struct platform_driver qmc_driver = {
 };
 module_platform_driver(qmc_driver);
 
-struct qmc_chan *qmc_chan_get_byphandle(struct device_node *np, const char *phandle_name)
+static struct qmc_chan *qmc_chan_get_from_qmc(struct device_node *qmc_np, unsigned int chan_index)
 {
-	struct of_phandle_args out_args;
 	struct platform_device *pdev;
 	struct qmc_chan *qmc_chan;
 	struct qmc *qmc;
-	int ret;
 
-	ret = of_parse_phandle_with_fixed_args(np, phandle_name, 1, 0,
-					       &out_args);
-	if (ret < 0)
-		return ERR_PTR(ret);
-
-	if (!of_match_node(qmc_driver.driver.of_match_table, out_args.np)) {
-		of_node_put(out_args.np);
+	if (!of_match_node(qmc_driver.driver.of_match_table, qmc_np))
 		return ERR_PTR(-EINVAL);
-	}
 
-	pdev = of_find_device_by_node(out_args.np);
-	of_node_put(out_args.np);
+	pdev = of_find_device_by_node(qmc_np);
 	if (!pdev)
 		return ERR_PTR(-ENODEV);
 
@@ -1494,17 +1492,12 @@ struct qmc_chan *qmc_chan_get_byphandle(struct device_node *np, const char *phan
 		return ERR_PTR(-EPROBE_DEFER);
 	}
 
-	if (out_args.args_count != 1) {
+	if (chan_index >= ARRAY_SIZE(qmc->chans)) {
 		platform_device_put(pdev);
 		return ERR_PTR(-EINVAL);
 	}
 
-	if (out_args.args[0] >= ARRAY_SIZE(qmc->chans)) {
-		platform_device_put(pdev);
-		return ERR_PTR(-EINVAL);
-	}
-
-	qmc_chan = qmc->chans[out_args.args[0]];
+	qmc_chan = qmc->chans[chan_index];
 	if (!qmc_chan) {
 		platform_device_put(pdev);
 		return ERR_PTR(-ENOENT);
@@ -1512,8 +1505,44 @@ struct qmc_chan *qmc_chan_get_byphandle(struct device_node *np, const char *phan
 
 	return qmc_chan;
 }
+
+struct qmc_chan *qmc_chan_get_byphandle(struct device_node *np, const char *phandle_name)
+{
+	struct of_phandle_args out_args;
+	struct qmc_chan *qmc_chan;
+	int ret;
+
+	ret = of_parse_phandle_with_fixed_args(np, phandle_name, 1, 0,
+					       &out_args);
+	if (ret < 0)
+		return ERR_PTR(ret);
+
+	if (out_args.args_count != 1) {
+		of_node_put(out_args.np);
+		return ERR_PTR(-EINVAL);
+	}
+
+	qmc_chan = qmc_chan_get_from_qmc(out_args.np, out_args.args[0]);
+	of_node_put(out_args.np);
+	return qmc_chan;
+}
 EXPORT_SYMBOL(qmc_chan_get_byphandle);
 
+struct qmc_chan *qmc_chan_get_bychild(struct device_node *np)
+{
+	struct device_node *qmc_np;
+	u32 chan_index;
+	int ret;
+
+	qmc_np = np->parent;
+	ret = of_property_read_u32(np, "reg", &chan_index);
+	if (ret)
+		return ERR_PTR(-EINVAL);
+
+	return qmc_chan_get_from_qmc(qmc_np, chan_index);
+}
+EXPORT_SYMBOL(qmc_chan_get_bychild);
+
 void qmc_chan_put(struct qmc_chan *chan)
 {
 	put_device(chan->qmc->dev);
@@ -1550,6 +1579,28 @@ struct qmc_chan *devm_qmc_chan_get_byphandle(struct device *dev,
 }
 EXPORT_SYMBOL(devm_qmc_chan_get_byphandle);
 
+struct qmc_chan *devm_qmc_chan_get_bychild(struct device *dev,
+					   struct device_node *np)
+{
+	struct qmc_chan *qmc_chan;
+	struct qmc_chan **dr;
+
+	dr = devres_alloc(devm_qmc_chan_release, sizeof(*dr), GFP_KERNEL);
+	if (!dr)
+		return ERR_PTR(-ENOMEM);
+
+	qmc_chan = qmc_chan_get_bychild(np);
+	if (!IS_ERR(qmc_chan)) {
+		*dr = qmc_chan;
+		devres_add(dev, dr);
+	} else {
+		devres_free(dr);
+	}
+
+	return qmc_chan;
+}
+EXPORT_SYMBOL(devm_qmc_chan_get_bychild);
+
 MODULE_AUTHOR("Herve Codina <herve.codina at bootlin.com>");
 MODULE_DESCRIPTION("CPM QMC driver");
 MODULE_LICENSE("GPL");
diff --git a/include/soc/fsl/qe/qmc.h b/include/soc/fsl/qe/qmc.h
index 6f1d6cebc9fe..166484bb4294 100644
--- a/include/soc/fsl/qe/qmc.h
+++ b/include/soc/fsl/qe/qmc.h
@@ -17,9 +17,11 @@ struct device;
 struct qmc_chan;
 
 struct qmc_chan *qmc_chan_get_byphandle(struct device_node *np, const char *phandle_name);
+struct qmc_chan *qmc_chan_get_bychild(struct device_node *np);
 void qmc_chan_put(struct qmc_chan *chan);
 struct qmc_chan *devm_qmc_chan_get_byphandle(struct device *dev, struct device_node *np,
 					     const char *phandle_name);
+struct qmc_chan *devm_qmc_chan_get_bychild(struct device *dev, struct device_node *np);
 
 enum qmc_mode {
 	QMC_TRANSPARENT,
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:05 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:05 +0100
Subject: [PATCH v2 08/17] soc: fsl: cpm1: qmc: Rename qmc_setup_tsa* to qmc_init_tsa*
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-9-herve.codina@bootlin.com>

qmc_setup_tsa* are called once at initialisation.
They initialize the QMC TSA table.
In order to introduce setup function later on for dynamic timeslots
management, rename the function to avoid later confusion.

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 0413e25d4c67..e3f2afb8fa4d 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -919,7 +919,7 @@ static int qmc_of_parse_chans(struct qmc *qmc, struct device_node *np)
 	return qmc_check_chans(qmc);
 }
 
-static int qmc_setup_tsa_64rxtx(struct qmc *qmc, const struct tsa_serial_info *info)
+static int qmc_init_tsa_64rxtx(struct qmc *qmc, const struct tsa_serial_info *info)
 {
 	struct qmc_chan *chan;
 	unsigned int i;
@@ -961,7 +961,7 @@ static int qmc_setup_tsa_64rxtx(struct qmc *qmc, const struct tsa_serial_info *i
 	return 0;
 }
 
-static int qmc_setup_tsa_32rx_32tx(struct qmc *qmc, const struct tsa_serial_info *info)
+static int qmc_init_tsa_32rx_32tx(struct qmc *qmc, const struct tsa_serial_info *info)
 {
 	struct qmc_chan *chan;
 	unsigned int i;
@@ -1019,7 +1019,7 @@ static int qmc_setup_tsa_32rx_32tx(struct qmc *qmc, const struct tsa_serial_info
 	return 0;
 }
 
-static int qmc_setup_tsa(struct qmc *qmc)
+static int qmc_init_tsa(struct qmc *qmc)
 {
 	struct tsa_serial_info info;
 	int ret;
@@ -1030,12 +1030,12 @@ static int qmc_setup_tsa(struct qmc *qmc)
 		return ret;
 
 	/*
-	 * Setup one common 64 entries table or two 32 entries (one for Tx and
-	 * one for Tx) according to assigned TS numbers.
+	 * Initialize one common 64 entries table or two 32 entries (one for Tx
+	 * and one for Tx) according to assigned TS numbers.
 	 */
 	return ((info.nb_tx_ts > 32) || (info.nb_rx_ts > 32)) ?
-		qmc_setup_tsa_64rxtx(qmc, &info) :
-		qmc_setup_tsa_32rx_32tx(qmc, &info);
+		qmc_init_tsa_64rxtx(qmc, &info) :
+		qmc_init_tsa_32rx_32tx(qmc, &info);
 }
 
 static int qmc_setup_chan_trnsync(struct qmc *qmc, struct qmc_chan *chan)
@@ -1391,7 +1391,7 @@ static int qmc_probe(struct platform_device *pdev)
 	qmc_write32(qmc->scc_pram + QMC_GBL_C_MASK32, 0xDEBB20E3);
 	qmc_write16(qmc->scc_pram + QMC_GBL_C_MASK16, 0xF0B8);
 
-	ret = qmc_setup_tsa(qmc);
+	ret = qmc_init_tsa(qmc);
 	if (ret)
 		goto err_tsa_serial_disconnect;
 
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:06 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:06 +0100
Subject: [PATCH v2 09/17] soc: fsl: cpm1: qmc: Introduce qmc_chan_setup_tsa*
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-10-herve.codina@bootlin.com>

Introduce the qmc_chan_setup_tsa* functions to setup entries related
to the given channel.
Use them during QMC channels setup.

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 161 ++++++++++++++++++++++++++++++---------
 1 file changed, 125 insertions(+), 36 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index e3f2afb8fa4d..5d7e2ecdd933 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -240,6 +240,11 @@ static void qmc_clrbits16(void __iomem *addr, u16 clr)
 	qmc_write16(addr, qmc_read16(addr) & ~clr);
 }
 
+static void qmc_clrsetbits16(void __iomem *addr, u16 clr, u16 set)
+{
+	qmc_write16(addr, (qmc_read16(addr) & ~clr) | set);
+}
+
 static void qmc_write32(void __iomem *addr, u32 val)
 {
 	iowrite32be(val, addr);
@@ -562,6 +567,122 @@ static void qmc_chan_read_done(struct qmc_chan *chan)
 	spin_unlock_irqrestore(&chan->rx_lock, flags);
 }
 
+static int qmc_chan_setup_tsa_64rxtx(struct qmc_chan *chan, const struct tsa_serial_info *info)
+{
+	unsigned int i;
+	u16 curr;
+	u16 val;
+
+	/*
+	 * Use a common Tx/Rx 64 entries table.
+	 * Tx and Rx related stuffs must be identical
+	 */
+	if (chan->tx_ts_mask != chan->rx_ts_mask) {
+		dev_err(chan->qmc->dev, "chan %u uses different Rx and Tx TS\n", chan->id);
+		return -EINVAL;
+	}
+
+	val = QMC_TSA_VALID | QMC_TSA_MASK | QMC_TSA_CHANNEL(chan->id);
+
+	/* Check entries based on Rx stuff*/
+	for (i = 0; i < info->nb_rx_ts; i++) {
+		if (!(chan->rx_ts_mask & (((u64)1) << i)))
+			continue;
+
+		curr = qmc_read16(chan->qmc->scc_pram + QMC_GBL_TSATRX + (i * 2));
+		if (curr & QMC_TSA_VALID && (curr & ~QMC_TSA_WRAP) != val) {
+			dev_err(chan->qmc->dev, "chan %u TxRx entry %d already used\n",
+				chan->id, i);
+			return -EBUSY;
+		}
+	}
+
+	/* Set entries based on Rx stuff*/
+	for (i = 0; i < info->nb_rx_ts; i++) {
+		if (!(chan->rx_ts_mask & (((u64)1) << i)))
+			continue;
+
+		qmc_clrsetbits16(chan->qmc->scc_pram + QMC_GBL_TSATRX + (i * 2),
+				 ~QMC_TSA_WRAP, val);
+	}
+
+	return 0;
+}
+
+static int qmc_chan_setup_tsa_32rx_32tx(struct qmc_chan *chan, const struct tsa_serial_info *info)
+{
+	unsigned int i;
+	u16 curr;
+	u16 val;
+
+	/* Use a Tx 32 entries table and a Rx 32 entries table */
+
+	val = QMC_TSA_VALID | QMC_TSA_MASK | QMC_TSA_CHANNEL(chan->id);
+
+	/* Check entries based on Rx stuff */
+	for (i = 0; i < info->nb_rx_ts; i++) {
+		if (!(chan->rx_ts_mask & (((u64)1) << i)))
+			continue;
+
+		curr = qmc_read16(chan->qmc->scc_pram + QMC_GBL_TSATRX + (i * 2));
+		if (curr & QMC_TSA_VALID && (curr & ~QMC_TSA_WRAP) != val) {
+			dev_err(chan->qmc->dev, "chan %u Rx entry %d already used\n",
+				chan->id, i);
+			return -EBUSY;
+		}
+	}
+	/* Check entries based on Tx stuff */
+	for (i = 0; i < info->nb_tx_ts; i++) {
+		if (!(chan->tx_ts_mask & (((u64)1) << i)))
+			continue;
+
+		curr = qmc_read16(chan->qmc->scc_pram + QMC_GBL_TSATTX + (i * 2));
+		if (curr & QMC_TSA_VALID && (curr & ~QMC_TSA_WRAP) != val) {
+			dev_err(chan->qmc->dev, "chan %u Tx entry %d already used\n",
+				chan->id, i);
+			return -EBUSY;
+		}
+	}
+
+	/* Set entries based on Rx stuff */
+	for (i = 0; i < info->nb_rx_ts; i++) {
+		if (!(chan->rx_ts_mask & (((u64)1) << i)))
+			continue;
+
+		qmc_clrsetbits16(chan->qmc->scc_pram + QMC_GBL_TSATRX + (i * 2),
+				 ~QMC_TSA_WRAP, val);
+	}
+	/* Set entries based on Tx stuff */
+	for (i = 0; i < info->nb_tx_ts; i++) {
+		if (!(chan->tx_ts_mask & (((u64)1) << i)))
+			continue;
+
+		qmc_clrsetbits16(chan->qmc->scc_pram + QMC_GBL_TSATTX + (i * 2),
+				 ~QMC_TSA_WRAP, val);
+	}
+
+	return 0;
+}
+
+static int qmc_chan_setup_tsa(struct qmc_chan *chan)
+{
+	struct tsa_serial_info info;
+	int ret;
+
+	/* Retrieve info from the TSA related serial */
+	ret = tsa_serial_get_info(chan->qmc->tsa_serial, &info);
+	if (ret)
+		return ret;
+
+	/*
+	 * Setup one common 64 entries table or two 32 entries (one for Tx
+	 * and one for Tx) according to assigned TS numbers.
+	 */
+	return ((info.nb_tx_ts > 32) || (info.nb_rx_ts > 32)) ?
+		qmc_chan_setup_tsa_64rxtx(chan, &info) :
+		qmc_chan_setup_tsa_32rx_32tx(chan, &info);
+}
+
 static int qmc_chan_command(struct qmc_chan *chan, u8 qmc_opcode)
 {
 	return cpm_command(chan->id << 2, (qmc_opcode << 4) | 0x0E);
@@ -921,7 +1042,6 @@ static int qmc_of_parse_chans(struct qmc *qmc, struct device_node *np)
 
 static int qmc_init_tsa_64rxtx(struct qmc *qmc, const struct tsa_serial_info *info)
 {
-	struct qmc_chan *chan;
 	unsigned int i;
 	u16 val;
 
@@ -935,18 +1055,6 @@ static int qmc_init_tsa_64rxtx(struct qmc *qmc, const struct tsa_serial_info *in
 	for (i = 0; i < 64; i++)
 		qmc_write16(qmc->scc_pram + QMC_GBL_TSATRX + (i * 2), 0x0000);
 
-	/* Set entries based on Rx stuff*/
-	list_for_each_entry(chan, &qmc->chan_head, list) {
-		for (i = 0; i < info->nb_rx_ts; i++) {
-			if (!(chan->rx_ts_mask & (((u64)1) << i)))
-				continue;
-
-			val = QMC_TSA_VALID | QMC_TSA_MASK |
-			      QMC_TSA_CHANNEL(chan->id);
-			qmc_write16(qmc->scc_pram + QMC_GBL_TSATRX + (i * 2), val);
-		}
-	}
-
 	/* Set Wrap bit on last entry */
 	qmc_setbits16(qmc->scc_pram + QMC_GBL_TSATRX + ((info->nb_rx_ts - 1) * 2),
 		      QMC_TSA_WRAP);
@@ -963,7 +1071,6 @@ static int qmc_init_tsa_64rxtx(struct qmc *qmc, const struct tsa_serial_info *in
 
 static int qmc_init_tsa_32rx_32tx(struct qmc *qmc, const struct tsa_serial_info *info)
 {
-	struct qmc_chan *chan;
 	unsigned int i;
 	u16 val;
 
@@ -978,28 +1085,6 @@ static int qmc_init_tsa_32rx_32tx(struct qmc *qmc, const struct tsa_serial_info
 		qmc_write16(qmc->scc_pram + QMC_GBL_TSATTX + (i * 2), 0x0000);
 	}
 
-	/* Set entries based on Rx and Tx stuff*/
-	list_for_each_entry(chan, &qmc->chan_head, list) {
-		/* Rx part */
-		for (i = 0; i < info->nb_rx_ts; i++) {
-			if (!(chan->rx_ts_mask & (((u64)1) << i)))
-				continue;
-
-			val = QMC_TSA_VALID | QMC_TSA_MASK |
-			      QMC_TSA_CHANNEL(chan->id);
-			qmc_write16(qmc->scc_pram + QMC_GBL_TSATRX + (i * 2), val);
-		}
-		/* Tx part */
-		for (i = 0; i < info->nb_tx_ts; i++) {
-			if (!(chan->tx_ts_mask & (((u64)1) << i)))
-				continue;
-
-			val = QMC_TSA_VALID | QMC_TSA_MASK |
-			      QMC_TSA_CHANNEL(chan->id);
-			qmc_write16(qmc->scc_pram + QMC_GBL_TSATTX + (i * 2), val);
-		}
-	}
-
 	/* Set Wrap bit on last entries */
 	qmc_setbits16(qmc->scc_pram + QMC_GBL_TSATRX + ((info->nb_rx_ts - 1) * 2),
 		      QMC_TSA_WRAP);
@@ -1081,6 +1166,10 @@ static int qmc_setup_chan(struct qmc *qmc, struct qmc_chan *chan)
 
 	chan->qmc = qmc;
 
+	ret = qmc_chan_setup_tsa(chan);
+	if (ret)
+		return ret;
+
 	/* Set channel specific parameter base address */
 	chan->s_param = qmc->dpram + (chan->id * 64);
 	/* 16 bd per channel (8 rx and 8 tx) */
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:07 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:07 +0100
Subject: [PATCH v2 10/17] soc: fsl: cpm1: qmc: Remove no more needed checks from qmc_check_chans()
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-11-herve.codina@bootlin.com>

The newly introduced qmc_chan_setup_tsa* functions check that the
channel entries are not already used.
These checks are also performed by qmc_check_chans() and are no more
needed.

Remove them from qmc_check_chans().

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 20 --------------------
 1 file changed, 20 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 5d7e2ecdd933..f2a71a140db7 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -884,10 +884,7 @@ EXPORT_SYMBOL(qmc_chan_reset);
 static int qmc_check_chans(struct qmc *qmc)
 {
 	struct tsa_serial_info info;
-	bool is_one_table = false;
 	struct qmc_chan *chan;
-	u64 tx_ts_mask = 0;
-	u64 rx_ts_mask = 0;
 	u64 tx_ts_assigned_mask;
 	u64 rx_ts_assigned_mask;
 	int ret;
@@ -911,7 +908,6 @@ static int qmc_check_chans(struct qmc *qmc)
 			dev_err(qmc->dev, "Number of TSA Tx/Rx TS assigned are not equal\n");
 			return -EINVAL;
 		}
-		is_one_table = true;
 	}
 
 	tx_ts_assigned_mask = info.nb_tx_ts == 64 ? U64_MAX : (((u64)1) << info.nb_tx_ts) - 1;
@@ -922,27 +918,11 @@ static int qmc_check_chans(struct qmc *qmc)
 			dev_err(qmc->dev, "chan %u uses TSA unassigned Tx TS\n", chan->id);
 			return -EINVAL;
 		}
-		if (tx_ts_mask & chan->tx_ts_mask) {
-			dev_err(qmc->dev, "chan %u uses an already used Tx TS\n", chan->id);
-			return -EINVAL;
-		}
 
 		if (chan->rx_ts_mask > rx_ts_assigned_mask) {
 			dev_err(qmc->dev, "chan %u uses TSA unassigned Rx TS\n", chan->id);
 			return -EINVAL;
 		}
-		if (rx_ts_mask & chan->rx_ts_mask) {
-			dev_err(qmc->dev, "chan %u uses an already used Rx TS\n", chan->id);
-			return -EINVAL;
-		}
-
-		if (is_one_table && (chan->tx_ts_mask != chan->rx_ts_mask)) {
-			dev_err(qmc->dev, "chan %u uses different Rx and Tx TS\n", chan->id);
-			return -EINVAL;
-		}
-
-		tx_ts_mask |= chan->tx_ts_mask;
-		rx_ts_mask |= chan->rx_ts_mask;
 	}
 
 	return 0;
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:08 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:08 +0100
Subject: [PATCH v2 11/17] soc: fsl: cpm1: qmc: Check available timeslots in qmc_check_chans()
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-12-herve.codina@bootlin.com>

The timeslots checked in qmc_check_chans() are the timeslots used.
With the introduction of the available timeslots, the used timeslots
are a subset of the available timeslots. The timeslots checked during
the qmc_check_chans() call should be the available ones.

Simply update and check the available timeslots instead of the used
timeslots in qmc_check_chans().

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index f2a71a140db7..8d71e63d0f21 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -914,13 +914,13 @@ static int qmc_check_chans(struct qmc *qmc)
 	rx_ts_assigned_mask = info.nb_rx_ts == 64 ? U64_MAX : (((u64)1) << info.nb_rx_ts) - 1;
 
 	list_for_each_entry(chan, &qmc->chan_head, list) {
-		if (chan->tx_ts_mask > tx_ts_assigned_mask) {
-			dev_err(qmc->dev, "chan %u uses TSA unassigned Tx TS\n", chan->id);
+		if (chan->tx_ts_mask_avail > tx_ts_assigned_mask) {
+			dev_err(qmc->dev, "chan %u can use TSA unassigned Tx TS\n", chan->id);
 			return -EINVAL;
 		}
 
-		if (chan->rx_ts_mask > rx_ts_assigned_mask) {
-			dev_err(qmc->dev, "chan %u uses TSA unassigned Rx TS\n", chan->id);
+		if (chan->rx_ts_mask_avail > rx_ts_assigned_mask) {
+			dev_err(qmc->dev, "chan %u can use TSA unassigned Rx TS\n", chan->id);
 			return -EINVAL;
 		}
 	}
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:09 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:09 +0100
Subject: [PATCH v2 12/17] soc: fsl: cpm1: qmc: Add support for disabling channel TSA entries
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-13-herve.codina@bootlin.com>

In order to allow runtime timeslot route changes, disabling channel TSA
entries needs to be supported.

Add support for this new feature.

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 8d71e63d0f21..c1318fad296b 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -567,7 +567,8 @@ static void qmc_chan_read_done(struct qmc_chan *chan)
 	spin_unlock_irqrestore(&chan->rx_lock, flags);
 }
 
-static int qmc_chan_setup_tsa_64rxtx(struct qmc_chan *chan, const struct tsa_serial_info *info)
+static int qmc_chan_setup_tsa_64rxtx(struct qmc_chan *chan, const struct tsa_serial_info *info,
+				     bool enable)
 {
 	unsigned int i;
 	u16 curr;
@@ -603,13 +604,14 @@ static int qmc_chan_setup_tsa_64rxtx(struct qmc_chan *chan, const struct tsa_ser
 			continue;
 
 		qmc_clrsetbits16(chan->qmc->scc_pram + QMC_GBL_TSATRX + (i * 2),
-				 ~QMC_TSA_WRAP, val);
+				 ~QMC_TSA_WRAP, enable ? val : 0x0000);
 	}
 
 	return 0;
 }
 
-static int qmc_chan_setup_tsa_32rx_32tx(struct qmc_chan *chan, const struct tsa_serial_info *info)
+static int qmc_chan_setup_tsa_32rx_32tx(struct qmc_chan *chan, const struct tsa_serial_info *info,
+					bool enable)
 {
 	unsigned int i;
 	u16 curr;
@@ -650,7 +652,7 @@ static int qmc_chan_setup_tsa_32rx_32tx(struct qmc_chan *chan, const struct tsa_
 			continue;
 
 		qmc_clrsetbits16(chan->qmc->scc_pram + QMC_GBL_TSATRX + (i * 2),
-				 ~QMC_TSA_WRAP, val);
+				 ~QMC_TSA_WRAP, enable ? val : 0x0000);
 	}
 	/* Set entries based on Tx stuff */
 	for (i = 0; i < info->nb_tx_ts; i++) {
@@ -658,13 +660,13 @@ static int qmc_chan_setup_tsa_32rx_32tx(struct qmc_chan *chan, const struct tsa_
 			continue;
 
 		qmc_clrsetbits16(chan->qmc->scc_pram + QMC_GBL_TSATTX + (i * 2),
-				 ~QMC_TSA_WRAP, val);
+				 ~QMC_TSA_WRAP, enable ? val : 0x0000);
 	}
 
 	return 0;
 }
 
-static int qmc_chan_setup_tsa(struct qmc_chan *chan)
+static int qmc_chan_setup_tsa(struct qmc_chan *chan, bool enable)
 {
 	struct tsa_serial_info info;
 	int ret;
@@ -679,8 +681,8 @@ static int qmc_chan_setup_tsa(struct qmc_chan *chan)
 	 * and one for Tx) according to assigned TS numbers.
 	 */
 	return ((info.nb_tx_ts > 32) || (info.nb_rx_ts > 32)) ?
-		qmc_chan_setup_tsa_64rxtx(chan, &info) :
-		qmc_chan_setup_tsa_32rx_32tx(chan, &info);
+		qmc_chan_setup_tsa_64rxtx(chan, &info, enable) :
+		qmc_chan_setup_tsa_32rx_32tx(chan, &info, enable);
 }
 
 static int qmc_chan_command(struct qmc_chan *chan, u8 qmc_opcode)
@@ -1146,7 +1148,7 @@ static int qmc_setup_chan(struct qmc *qmc, struct qmc_chan *chan)
 
 	chan->qmc = qmc;
 
-	ret = qmc_chan_setup_tsa(chan);
+	ret = qmc_chan_setup_tsa(chan, true);
 	if (ret)
 		return ret;
 
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:10 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:10 +0100
Subject: [PATCH v2 13/17] soc: fsl: cpm1: qmc: Split Tx and Rx TSA entries setup
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-14-herve.codina@bootlin.com>

The Tx and Rx entries for a given channel are set in one function.

In order to modify Rx entries and Tx entries independently of one other,
split this function in one for the Rx part and one for the Tx part.

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 49 ++++++++++++++++++++++++++++------------
 1 file changed, 35 insertions(+), 14 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index c1318fad296b..5ca4120779f8 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -610,14 +610,14 @@ static int qmc_chan_setup_tsa_64rxtx(struct qmc_chan *chan, const struct tsa_ser
 	return 0;
 }
 
-static int qmc_chan_setup_tsa_32rx_32tx(struct qmc_chan *chan, const struct tsa_serial_info *info,
-					bool enable)
+static int qmc_chan_setup_tsa_32rx(struct qmc_chan *chan, const struct tsa_serial_info *info,
+				   bool enable)
 {
 	unsigned int i;
 	u16 curr;
 	u16 val;
 
-	/* Use a Tx 32 entries table and a Rx 32 entries table */
+	/* Use a Rx 32 entries table */
 
 	val = QMC_TSA_VALID | QMC_TSA_MASK | QMC_TSA_CHANNEL(chan->id);
 
@@ -633,6 +633,30 @@ static int qmc_chan_setup_tsa_32rx_32tx(struct qmc_chan *chan, const struct tsa_
 			return -EBUSY;
 		}
 	}
+
+	/* Set entries based on Rx stuff */
+	for (i = 0; i < info->nb_rx_ts; i++) {
+		if (!(chan->rx_ts_mask & (((u64)1) << i)))
+			continue;
+
+		qmc_clrsetbits16(chan->qmc->scc_pram + QMC_GBL_TSATRX + (i * 2),
+				 ~QMC_TSA_WRAP, enable ? val : 0x0000);
+	}
+
+	return 0;
+}
+
+static int qmc_chan_setup_tsa_32tx(struct qmc_chan *chan, const struct tsa_serial_info *info,
+				   bool enable)
+{
+	unsigned int i;
+	u16 curr;
+	u16 val;
+
+	/* Use a Tx 32 entries table */
+
+	val = QMC_TSA_VALID | QMC_TSA_MASK | QMC_TSA_CHANNEL(chan->id);
+
 	/* Check entries based on Tx stuff */
 	for (i = 0; i < info->nb_tx_ts; i++) {
 		if (!(chan->tx_ts_mask & (((u64)1) << i)))
@@ -646,14 +670,6 @@ static int qmc_chan_setup_tsa_32rx_32tx(struct qmc_chan *chan, const struct tsa_
 		}
 	}
 
-	/* Set entries based on Rx stuff */
-	for (i = 0; i < info->nb_rx_ts; i++) {
-		if (!(chan->rx_ts_mask & (((u64)1) << i)))
-			continue;
-
-		qmc_clrsetbits16(chan->qmc->scc_pram + QMC_GBL_TSATRX + (i * 2),
-				 ~QMC_TSA_WRAP, enable ? val : 0x0000);
-	}
 	/* Set entries based on Tx stuff */
 	for (i = 0; i < info->nb_tx_ts; i++) {
 		if (!(chan->tx_ts_mask & (((u64)1) << i)))
@@ -680,9 +696,14 @@ static int qmc_chan_setup_tsa(struct qmc_chan *chan, bool enable)
 	 * Setup one common 64 entries table or two 32 entries (one for Tx
 	 * and one for Tx) according to assigned TS numbers.
 	 */
-	return ((info.nb_tx_ts > 32) || (info.nb_rx_ts > 32)) ?
-		qmc_chan_setup_tsa_64rxtx(chan, &info, enable) :
-		qmc_chan_setup_tsa_32rx_32tx(chan, &info, enable);
+	if (info.nb_tx_ts > 32 || info.nb_rx_ts > 32)
+		return qmc_chan_setup_tsa_64rxtx(chan, &info, enable);
+
+	ret = qmc_chan_setup_tsa_32rx(chan, &info, enable);
+	if (ret)
+		return ret;
+
+	return qmc_chan_setup_tsa_32tx(chan, &info, enable);
 }
 
 static int qmc_chan_command(struct qmc_chan *chan, u8 qmc_opcode)
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:11 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:11 +0100
Subject: [PATCH v2 14/17] soc: fsl: cpm1: qmc: Introduce is_tsa_64rxtx flag
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-15-herve.codina@bootlin.com>

In order to support runtime timeslot route changes, some operations will
be different according the routing table used (common Rx and Tx table or
one table for Rx and one for Tx).

The is_tsa_64rxtx flag is introduced to avoid extra computation to
determine the table format each time we need it.
It is set once at initialization.

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 5ca4120779f8..e651b3bba1ca 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -216,6 +216,7 @@ struct qmc {
 	u16 __iomem *int_curr;
 	dma_addr_t int_dma_addr;
 	size_t int_size;
+	bool is_tsa_64rxtx;
 	struct list_head chan_head;
 	struct qmc_chan *chans[64];
 };
@@ -696,7 +697,7 @@ static int qmc_chan_setup_tsa(struct qmc_chan *chan, bool enable)
 	 * Setup one common 64 entries table or two 32 entries (one for Tx
 	 * and one for Tx) according to assigned TS numbers.
 	 */
-	if (info.nb_tx_ts > 32 || info.nb_rx_ts > 32)
+	if (chan->qmc->is_tsa_64rxtx)
 		return qmc_chan_setup_tsa_64rxtx(chan, &info, enable);
 
 	ret = qmc_chan_setup_tsa_32rx(chan, &info, enable);
@@ -1053,6 +1054,7 @@ static int qmc_init_tsa_64rxtx(struct qmc *qmc, const struct tsa_serial_info *in
 	 * Everything was previously checked, Tx and Rx related stuffs are
 	 * identical -> Used Rx related stuff to build the table
 	 */
+	qmc->is_tsa_64rxtx = true;
 
 	/* Invalidate all entries */
 	for (i = 0; i < 64; i++)
@@ -1081,6 +1083,7 @@ static int qmc_init_tsa_32rx_32tx(struct qmc *qmc, const struct tsa_serial_info
 	 * Use a Tx 32 entries table and a Rx 32 entries table.
 	 * Everything was previously checked.
 	 */
+	qmc->is_tsa_64rxtx = false;
 
 	/* Invalidate all entries */
 	for (i = 0; i < 32; i++) {
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:12 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:12 +0100
Subject: [PATCH v2 15/17] soc: fsl: cpm1: qmc: Handle timeslot entries at channel start() and stop()
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-16-herve.codina@bootlin.com>

In order to support runtime timeslot route changes, enable the
channel timeslot entries at channel start() and disable them at
channel stop().

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 241 +++++++++++++++++++++++++++++++--------
 1 file changed, 195 insertions(+), 46 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index e651b3bba1ca..bc72c1bc0ec4 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -177,6 +177,7 @@ struct qmc_chan {
 	struct qmc *qmc;
 	void __iomem *s_param;
 	enum qmc_mode mode;
+	spinlock_t	ts_lock; /* Protect timeslots */
 	u64	tx_ts_mask_avail;
 	u64	tx_ts_mask;
 	u64	rx_ts_mask_avail;
@@ -265,6 +266,7 @@ static void qmc_setbits32(void __iomem *addr, u32 set)
 int qmc_chan_get_info(struct qmc_chan *chan, struct qmc_chan_info *info)
 {
 	struct tsa_serial_info tsa_info;
+	unsigned long flags;
 	int ret;
 
 	/* Retrieve info from the TSA related serial */
@@ -272,6 +274,8 @@ int qmc_chan_get_info(struct qmc_chan *chan, struct qmc_chan_info *info)
 	if (ret)
 		return ret;
 
+	spin_lock_irqsave(&chan->ts_lock, flags);
+
 	info->mode = chan->mode;
 	info->rx_fs_rate = tsa_info.rx_fs_rate;
 	info->rx_bit_rate = tsa_info.rx_bit_rate;
@@ -280,6 +284,8 @@ int qmc_chan_get_info(struct qmc_chan *chan, struct qmc_chan_info *info)
 	info->tx_bit_rate = tsa_info.tx_bit_rate;
 	info->nb_rx_ts = hweight64(chan->rx_ts_mask);
 
+	spin_unlock_irqrestore(&chan->ts_lock, flags);
+
 	return 0;
 }
 EXPORT_SYMBOL(qmc_chan_get_info);
@@ -683,6 +689,40 @@ static int qmc_chan_setup_tsa_32tx(struct qmc_chan *chan, const struct tsa_seria
 	return 0;
 }
 
+static int qmc_chan_setup_tsa_tx(struct qmc_chan *chan, bool enable)
+{
+	struct tsa_serial_info info;
+	int ret;
+
+	/* Retrieve info from the TSA related serial */
+	ret = tsa_serial_get_info(chan->qmc->tsa_serial, &info);
+	if (ret)
+		return ret;
+
+	/* Setup entries */
+	if (chan->qmc->is_tsa_64rxtx)
+		return qmc_chan_setup_tsa_64rxtx(chan, &info, enable);
+
+	return qmc_chan_setup_tsa_32tx(chan, &info, enable);
+}
+
+static int qmc_chan_setup_tsa_rx(struct qmc_chan *chan, bool enable)
+{
+	struct tsa_serial_info info;
+	int ret;
+
+	/* Retrieve info from the TSA related serial */
+	ret = tsa_serial_get_info(chan->qmc->tsa_serial, &info);
+	if (ret)
+		return ret;
+
+	/* Setup entries */
+	if (chan->qmc->is_tsa_64rxtx)
+		return qmc_chan_setup_tsa_64rxtx(chan, &info, enable);
+
+	return qmc_chan_setup_tsa_32rx(chan, &info, enable);
+}
+
 static int qmc_chan_setup_tsa(struct qmc_chan *chan, bool enable)
 {
 	struct tsa_serial_info info;
@@ -719,6 +759,12 @@ static int qmc_chan_stop_rx(struct qmc_chan *chan)
 
 	spin_lock_irqsave(&chan->rx_lock, flags);
 
+	if (chan->is_rx_stopped) {
+		/* The channel is already stopped -> simply return ok */
+		ret = 0;
+		goto end;
+	}
+
 	/* Send STOP RECEIVE command */
 	ret = qmc_chan_command(chan, 0x0);
 	if (ret) {
@@ -729,6 +775,15 @@ static int qmc_chan_stop_rx(struct qmc_chan *chan)
 
 	chan->is_rx_stopped = true;
 
+	if (!chan->qmc->is_tsa_64rxtx || chan->is_tx_stopped) {
+		ret = qmc_chan_setup_tsa_rx(chan, false);
+		if (ret) {
+			dev_err(chan->qmc->dev, "chan %u: Disable tsa entries failed (%d)\n",
+				chan->id, ret);
+			goto end;
+		}
+	}
+
 end:
 	spin_unlock_irqrestore(&chan->rx_lock, flags);
 	return ret;
@@ -741,6 +796,12 @@ static int qmc_chan_stop_tx(struct qmc_chan *chan)
 
 	spin_lock_irqsave(&chan->tx_lock, flags);
 
+	if (chan->is_tx_stopped) {
+		/* The channel is already stopped -> simply return ok */
+		ret = 0;
+		goto end;
+	}
+
 	/* Send STOP TRANSMIT command */
 	ret = qmc_chan_command(chan, 0x1);
 	if (ret) {
@@ -751,37 +812,114 @@ static int qmc_chan_stop_tx(struct qmc_chan *chan)
 
 	chan->is_tx_stopped = true;
 
+	if (!chan->qmc->is_tsa_64rxtx || chan->is_rx_stopped) {
+		ret = qmc_chan_setup_tsa_tx(chan, false);
+		if (ret) {
+			dev_err(chan->qmc->dev, "chan %u: Disable tsa entries failed (%d)\n",
+				chan->id, ret);
+			goto end;
+		}
+	}
+
 end:
 	spin_unlock_irqrestore(&chan->tx_lock, flags);
 	return ret;
 }
 
+static int qmc_chan_start_rx(struct qmc_chan *chan);
+
 int qmc_chan_stop(struct qmc_chan *chan, int direction)
 {
-	int ret;
+	bool is_rx_rollback_needed = false;
+	unsigned long flags;
+	int ret = 0;
+
+	spin_lock_irqsave(&chan->ts_lock, flags);
 
 	if (direction & QMC_CHAN_READ) {
+		is_rx_rollback_needed = !chan->is_rx_stopped;
 		ret = qmc_chan_stop_rx(chan);
 		if (ret)
-			return ret;
+			goto end;
 	}
 
 	if (direction & QMC_CHAN_WRITE) {
 		ret = qmc_chan_stop_tx(chan);
-		if (ret)
-			return ret;
+		if (ret) {
+			/* Restart rx if needed */
+			if (is_rx_rollback_needed)
+				qmc_chan_start_rx(chan);
+			goto end;
+		}
 	}
 
-	return 0;
+end:
+	spin_unlock_irqrestore(&chan->ts_lock, flags);
+	return ret;
 }
 EXPORT_SYMBOL(qmc_chan_stop);
 
-static void qmc_chan_start_rx(struct qmc_chan *chan)
+static int qmc_setup_chan_trnsync(struct qmc *qmc, struct qmc_chan *chan)
+{
+	struct tsa_serial_info info;
+	u16 first_rx, last_tx;
+	u16 trnsync;
+	int ret;
+
+	/* Retrieve info from the TSA related serial */
+	ret = tsa_serial_get_info(chan->qmc->tsa_serial, &info);
+	if (ret)
+		return ret;
+
+	/* Find the first Rx TS allocated to the channel */
+	first_rx = chan->rx_ts_mask ? __ffs64(chan->rx_ts_mask) + 1 : 0;
+
+	/* Find the last Tx TS allocated to the channel */
+	last_tx = fls64(chan->tx_ts_mask);
+
+	trnsync = 0;
+	if (info.nb_rx_ts)
+		trnsync |= QMC_SPE_TRNSYNC_RX((first_rx % info.nb_rx_ts) * 2);
+	if (info.nb_tx_ts)
+		trnsync |= QMC_SPE_TRNSYNC_TX((last_tx % info.nb_tx_ts) * 2);
+
+	qmc_write16(chan->s_param + QMC_SPE_TRNSYNC, trnsync);
+
+	dev_dbg(qmc->dev, "chan %u: trnsync=0x%04x, rx %u/%u 0x%llx, tx %u/%u 0x%llx\n",
+		chan->id, trnsync,
+		first_rx, info.nb_rx_ts, chan->rx_ts_mask,
+		last_tx, info.nb_tx_ts, chan->tx_ts_mask);
+
+	return 0;
+}
+
+static int qmc_chan_start_rx(struct qmc_chan *chan)
 {
 	unsigned long flags;
+	int ret;
 
 	spin_lock_irqsave(&chan->rx_lock, flags);
 
+	if (!chan->is_rx_stopped) {
+		/* The channel is already started -> simply return ok */
+		ret = 0;
+		goto end;
+	}
+
+	ret = qmc_chan_setup_tsa_rx(chan, true);
+	if (ret) {
+		dev_err(chan->qmc->dev, "chan %u: Enable tsa entries failed (%d)\n",
+			chan->id, ret);
+		goto end;
+	}
+
+	ret = qmc_setup_chan_trnsync(chan->qmc, chan);
+	if (ret) {
+		dev_err(chan->qmc->dev, "chan %u: setup TRNSYNC failed (%d)\n",
+			chan->id, ret);
+		goto end;
+	}
+
 	/* Restart the receiver */
 	if (chan->mode == QMC_TRANSPARENT)
 		qmc_write32(chan->s_param + QMC_SPE_ZDSTATE, 0x18000080);
@@ -792,15 +930,38 @@ static void qmc_chan_start_rx(struct qmc_chan *chan)
 
 	chan->is_rx_stopped = false;
 
+end:
 	spin_unlock_irqrestore(&chan->rx_lock, flags);
+	return ret;
 }
 
-static void qmc_chan_start_tx(struct qmc_chan *chan)
+static int qmc_chan_start_tx(struct qmc_chan *chan)
 {
 	unsigned long flags;
+	int ret;
 
 	spin_lock_irqsave(&chan->tx_lock, flags);
 
+	if (!chan->is_tx_stopped) {
+		/* The channel is already started -> simply return ok */
+		ret = 0;
+		goto end;
+	}
+
+	ret = qmc_chan_setup_tsa_tx(chan, true);
+	if (ret) {
+		dev_err(chan->qmc->dev, "chan %u: Enable tsa entries failed (%d)\n",
+			chan->id, ret);
+		goto end;
+	}
+
+	ret = qmc_setup_chan_trnsync(chan->qmc, chan);
+	if (ret) {
+		dev_err(chan->qmc->dev, "chan %u: setup TRNSYNC failed (%d)\n",
+			chan->id, ret);
+		goto end;
+	}
+
 	/*
 	 * Enable channel transmitter as it could be disabled if
 	 * qmc_chan_reset() was called.
@@ -812,18 +973,39 @@ static void qmc_chan_start_tx(struct qmc_chan *chan)
 
 	chan->is_tx_stopped = false;
 
+end:
 	spin_unlock_irqrestore(&chan->tx_lock, flags);
+	return ret;
 }
 
 int qmc_chan_start(struct qmc_chan *chan, int direction)
 {
-	if (direction & QMC_CHAN_READ)
-		qmc_chan_start_rx(chan);
+	bool is_rx_rollback_needed = false;
+	unsigned long flags;
+	int ret = 0;
 
-	if (direction & QMC_CHAN_WRITE)
-		qmc_chan_start_tx(chan);
+	spin_lock_irqsave(&chan->ts_lock, flags);
 
-	return 0;
+	if (direction & QMC_CHAN_READ) {
+		is_rx_rollback_needed = chan->is_rx_stopped;
+		ret = qmc_chan_start_rx(chan);
+		if (ret)
+			goto end;
+	}
+
+	if (direction & QMC_CHAN_WRITE) {
+		ret = qmc_chan_start_tx(chan);
+		if (ret) {
+			/* Restop rx if needed */
+			if (is_rx_rollback_needed)
+				qmc_chan_stop_rx(chan);
+			goto end;
+		}
+	}
+
+end:
+	spin_unlock_irqrestore(&chan->ts_lock, flags);
+	return ret;
 }
 EXPORT_SYMBOL(qmc_chan_start);
 
@@ -992,6 +1174,7 @@ static int qmc_of_parse_chans(struct qmc *qmc, struct device_node *np)
 		}
 
 		chan->id = chan_id;
+		spin_lock_init(&chan->ts_lock);
 		spin_lock_init(&chan->rx_lock);
 		spin_lock_init(&chan->tx_lock);
 
@@ -1129,40 +1312,6 @@ static int qmc_init_tsa(struct qmc *qmc)
 		qmc_init_tsa_32rx_32tx(qmc, &info);
 }
 
-static int qmc_setup_chan_trnsync(struct qmc *qmc, struct qmc_chan *chan)
-{
-	struct tsa_serial_info info;
-	u16 first_rx, last_tx;
-	u16 trnsync;
-	int ret;
-
-	/* Retrieve info from the TSA related serial */
-	ret = tsa_serial_get_info(chan->qmc->tsa_serial, &info);
-	if (ret)
-		return ret;
-
-	/* Find the first Rx TS allocated to the channel */
-	first_rx = chan->rx_ts_mask ? __ffs64(chan->rx_ts_mask) + 1 : 0;
-
-	/* Find the last Tx TS allocated to the channel */
-	last_tx = fls64(chan->tx_ts_mask);
-
-	trnsync = 0;
-	if (info.nb_rx_ts)
-		trnsync |= QMC_SPE_TRNSYNC_RX((first_rx % info.nb_rx_ts) * 2);
-	if (info.nb_tx_ts)
-		trnsync |= QMC_SPE_TRNSYNC_TX((last_tx % info.nb_tx_ts) * 2);
-
-	qmc_write16(chan->s_param + QMC_SPE_TRNSYNC, trnsync);
-
-	dev_dbg(qmc->dev, "chan %u: trnsync=0x%04x, rx %u/%u 0x%llx, tx %u/%u 0x%llx\n",
-		chan->id, trnsync,
-		first_rx, info.nb_rx_ts, chan->rx_ts_mask,
-		last_tx, info.nb_tx_ts, chan->tx_ts_mask);
-
-	return 0;
-}
-
 static int qmc_setup_chan(struct qmc *qmc, struct qmc_chan *chan)
 {
 	unsigned int i;
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:13 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:13 +0100
Subject: [PATCH v2 16/17] soc: fsl: cpm1: qmc: Remove timeslots handling from setup_chan()
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-17-herve.codina@bootlin.com>

Timeslots setting is done at channel start() and stop().
There is no more need to do that during setup_chan().

Simply remove timeslot setting from setup_chan().

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 28 ----------------------------
 1 file changed, 28 deletions(-)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index bc72c1bc0ec4..45d9cb40a118 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -723,30 +723,6 @@ static int qmc_chan_setup_tsa_rx(struct qmc_chan *chan, bool enable)
 	return qmc_chan_setup_tsa_32rx(chan, &info, enable);
 }
 
-static int qmc_chan_setup_tsa(struct qmc_chan *chan, bool enable)
-{
-	struct tsa_serial_info info;
-	int ret;
-
-	/* Retrieve info from the TSA related serial */
-	ret = tsa_serial_get_info(chan->qmc->tsa_serial, &info);
-	if (ret)
-		return ret;
-
-	/*
-	 * Setup one common 64 entries table or two 32 entries (one for Tx
-	 * and one for Tx) according to assigned TS numbers.
-	 */
-	if (chan->qmc->is_tsa_64rxtx)
-		return qmc_chan_setup_tsa_64rxtx(chan, &info, enable);
-
-	ret = qmc_chan_setup_tsa_32rx(chan, &info, enable);
-	if (ret)
-		return ret;
-
-	return qmc_chan_setup_tsa_32tx(chan, &info, enable);
-}
-
 static int qmc_chan_command(struct qmc_chan *chan, u8 qmc_opcode)
 {
 	return cpm_command(chan->id << 2, (qmc_opcode << 4) | 0x0E);
@@ -1321,10 +1297,6 @@ static int qmc_setup_chan(struct qmc *qmc, struct qmc_chan *chan)
 
 	chan->qmc = qmc;
 
-	ret = qmc_chan_setup_tsa(chan, true);
-	if (ret)
-		return ret;
-
 	/* Set channel specific parameter base address */
 	chan->s_param = qmc->dpram + (chan->id * 64);
 	/* 16 bd per channel (8 rx and 8 tx) */
-- 
2.43.0



From herve.codina at bootlin.com  Tue Dec  5 07:21:14 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue,  5 Dec 2023 16:21:14 +0100
Subject: [PATCH v2 17/17] soc: fsl: cpm1: qmc: Introduce functions to change timeslots at runtime
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231205152116.122512-18-herve.codina@bootlin.com>

Introduce qmc_chan_{get,set}_ts_info() function to allow timeslots
modification at runtime.

The modification is provided using qmc_chan_set_ts_info() and will be
applied on next qmc_chan_start().
qmc_chan_set_ts_info() must be called with the channel rx and/or tx
stopped.

Signed-off-by: Herve Codina <herve.codina at bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/soc/fsl/qe/qmc.c | 51 ++++++++++++++++++++++++++++++++++++++++
 include/soc/fsl/qe/qmc.h | 10 ++++++++
 2 files changed, 61 insertions(+)

diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c
index 45d9cb40a118..f498db9abe35 100644
--- a/drivers/soc/fsl/qe/qmc.c
+++ b/drivers/soc/fsl/qe/qmc.c
@@ -290,6 +290,57 @@ int qmc_chan_get_info(struct qmc_chan *chan, struct qmc_chan_info *info)
 }
 EXPORT_SYMBOL(qmc_chan_get_info);
 
+int qmc_chan_get_ts_info(struct qmc_chan *chan, struct qmc_chan_ts_info *ts_info)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&chan->ts_lock, flags);
+
+	ts_info->rx_ts_mask_avail = chan->rx_ts_mask_avail;
+	ts_info->tx_ts_mask_avail = chan->tx_ts_mask_avail;
+	ts_info->rx_ts_mask = chan->rx_ts_mask;
+	ts_info->tx_ts_mask = chan->tx_ts_mask;
+
+	spin_unlock_irqrestore(&chan->ts_lock, flags);
+
+	return 0;
+}
+EXPORT_SYMBOL(qmc_chan_get_ts_info);
+
+int qmc_chan_set_ts_info(struct qmc_chan *chan, const struct qmc_chan_ts_info *ts_info)
+{
+	unsigned long flags;
+	int ret;
+
+	/* Only a subset of available timeslots is allowed */
+	if ((ts_info->rx_ts_mask & chan->rx_ts_mask_avail) != ts_info->rx_ts_mask)
+		return -EINVAL;
+	if ((ts_info->tx_ts_mask & chan->tx_ts_mask_avail) != ts_info->tx_ts_mask)
+		return -EINVAL;
+
+	/* In case of common rx/tx table, rx/tx masks must be identical */
+	if (chan->qmc->is_tsa_64rxtx) {
+		if (ts_info->rx_ts_mask != ts_info->tx_ts_mask)
+			return -EINVAL;
+	}
+
+	spin_lock_irqsave(&chan->ts_lock, flags);
+
+	if ((chan->tx_ts_mask != ts_info->tx_ts_mask && !chan->is_tx_stopped) ||
+	    (chan->rx_ts_mask != ts_info->rx_ts_mask && !chan->is_rx_stopped)) {
+		dev_err(chan->qmc->dev, "Channel rx and/or tx not stopped\n");
+		ret = -EBUSY;
+	} else {
+		chan->tx_ts_mask = ts_info->tx_ts_mask;
+		chan->rx_ts_mask = ts_info->rx_ts_mask;
+		ret = 0;
+	}
+	spin_unlock_irqrestore(&chan->ts_lock, flags);
+
+	return ret;
+}
+EXPORT_SYMBOL(qmc_chan_set_ts_info);
+
 int qmc_chan_set_param(struct qmc_chan *chan, const struct qmc_chan_param *param)
 {
 	if (param->mode != chan->mode)
diff --git a/include/soc/fsl/qe/qmc.h b/include/soc/fsl/qe/qmc.h
index 166484bb4294..2a333fc1ea81 100644
--- a/include/soc/fsl/qe/qmc.h
+++ b/include/soc/fsl/qe/qmc.h
@@ -40,6 +40,16 @@ struct qmc_chan_info {
 
 int qmc_chan_get_info(struct qmc_chan *chan, struct qmc_chan_info *info);
 
+struct qmc_chan_ts_info {
+	u64 rx_ts_mask_avail;
+	u64 tx_ts_mask_avail;
+	u64 rx_ts_mask;
+	u64 tx_ts_mask;
+};
+
+int qmc_chan_get_ts_info(struct qmc_chan *chan, struct qmc_chan_ts_info *ts_info);
+int qmc_chan_set_ts_info(struct qmc_chan *chan, const struct qmc_chan_ts_info *ts_info);
+
 struct qmc_chan_param {
 	enum qmc_mode mode;
 	union {
-- 
2.43.0



From yoong.siang.song at intel.com  Tue Dec  5 07:25:02 2023
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Tue, 5 Dec 2023 15:25:02 +0000
Subject: [PATCH bpf-next v3 2/3] net: stmmac: add Launch Time support to
 XDP ZC
In-Reply-To: <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com>
 <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
 <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
Message-ID: <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>

On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote:
>Jesper Dangaard Brouer wrote:
>>
>>
>> On 12/3/23 17:51, Song Yoong Siang wrote:
>> > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
>> > copy via XDP Tx metadata framework.
>> >
>> > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
>> > ---
>> >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
>>
>> As requested before, I think we need to see another driver implementing
>> this.
>>
>> I propose driver igc and chip i225.

Sure. I will include igc patches in next version.

>>
>> The interesting thing for me is to see how the LaunchTime max 1 second
>> into the future[1] is handled code wise. One suggestion is to add a
>> section to Documentation/networking/xsk-tx-metadata.rst per driver that
>> mentions/documents these different hardware limitations.  It is natural
>> that different types of hardware have limitations.  This is a close-to
>> hardware-level abstraction/API, and IMHO as long as we document the
>> limitations we can expose this API without too many limitations for more
>> capable hardware.

Sure. I will try to add hardware limitations in documentation. 

>
>I would assume that the kfunc will fail when a value is passed that
>cannot be programmed.
>

In current design, the xsk_tx_metadata_request() dint got return value. 
So user won't know if their request is fail. 
It is complex to inform user which request is failing. 
Therefore, IMHO, it is good that we let driver handle the error silently. 

>What is being implemented here already exists for qdiscs. The FQ
>qdisc takes a horizon attribute and
>
>    "
>    when a packet is beyond the horizon
>        at enqueue() time:
>        - either drop the packet (default policy)
>        - or cap its delivery time to the horizon.
>    "
>    commit 39d010504e6b ("net_sched: sch_fq: add horizon attribute")
>
>Having the admin manually configure this on the qdisc based on
>off-line knowledge of the device is more fragile than if the device
>would somehow signal its limit to the stack.
>
>But I don't think we should add enforcement of that as a requirement
>for this xdp extension of pacing.

From yoong.siang.song at intel.com  Tue Dec  5 07:28:14 2023
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Tue, 5 Dec 2023 15:28:14 +0000
Subject: [PATCH bpf-next v2 2/3] net: stmmac: Add txtime support to XDP ZC
In-Reply-To: <656f39d668439_3dd6422949e@willemb.c.googlers.com.notmuch>
References: <20231201062421.1074768-1-yoong.siang.song@intel.com>
 <20231201062421.1074768-3-yoong.siang.song@intel.com>
 <5a660c0f-d3ed-47a2-b9be-098a224b8a12@kernel.org>
 <PH0PR11MB5830F08AC202C42501D986C0D887A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <656de8eb14c24_2e983e29435@willemb.c.googlers.com.notmuch>
 <PH0PR11MB58305C7D394FD264F1634819D885A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <656f39d668439_3dd6422949e@willemb.c.googlers.com.notmuch>
Message-ID: <PH0PR11MB5830AF989CBE622085C2175ED885A@PH0PR11MB5830.namprd11.prod.outlook.com>

On Tuesday, December 5, 2023 10:55 PM, Willem de Bruijn wrote:
>Song, Yoong Siang wrote:
>> On Monday, December 4, 2023 10:58 PM, Willem de Bruijn wrote:
>> >Song, Yoong Siang wrote:
>> >> On Friday, December 1, 2023 11:02 PM, Jesper Dangaard Brouer wrote:
>> >> >On 12/1/23 07:24, Song Yoong Siang wrote:
>> >> >> This patch enables txtime support to XDP zero copy via XDP Tx
>> >> >> metadata framework.
>> >> >>
>> >> >> Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
>> >> >> ---
>> >> >>   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
>> >> >>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++
>> >> >>   2 files changed, 15 insertions(+)
>> >> >
>> >> >I think we need to see other drivers using this new feature to evaluate
>> >> >if API is sane.
>> >> >
>> >> >I suggest implementing this for igc driver (chip i225) and also for igb
>> >> >(i210 chip) that both support this kind of LaunchTime feature in HW.
>> >> >
>> >> >The API and stmmac driver takes a u64 as time.
>> >> >I'm wondering how this applies to i210 that[1] have 25-bit for
>> >> >LaunchTime (with 32 nanosec granularity) limiting LaunchTime max 0.5
>> >> >second into the future.
>> >> >And i225 that [1] have 30-bit max 1 second into the future.
>> >> >
>> >> >
>> >> >[1]
>> >> >https://github.com/xdp-project/xdp-
>> >> >project/blob/master/areas/tsn/code01_follow_qdisc_TSN_offload.org
>> >>
>> >> I am using u64 for launch time because existing EDT framework is using it.
>> >> Refer to struct sk_buff below. Both u64 and ktime_t can be used as launch time.
>> >> I choose u64 because ktime_t often requires additional type conversion and
>> >> we didn't expect negative value of time.
>> >>
>> >> include/linux/skbuff.h-744- *   @tstamp: Time we arrived/left
>> >> include/linux/skbuff.h:745- *   @skb_mstamp_ns: (aka @tstamp) earliest
>departure
>> >time; start point
>> >> include/linux/skbuff.h-746- *           for retransmit timer
>> >> --
>> >> include/linux/skbuff.h-880-     union {
>> >> include/linux/skbuff.h-881-             ktime_t         tstamp;
>> >> include/linux/skbuff.h:882-             u64             skb_mstamp_ns; /* earliest
>departure
>> >time */
>> >> include/linux/skbuff.h-883-     };
>> >>
>> >> tstamp/skb_mstamp_ns are used by various drivers for launch time support
>> >> on normal packet, so I think u64 should be "friendly" to all the drivers. For an
>> >> example, igc driver will take launch time from tstamp and recalculate it
>> >> accordingly (i225 expect user to program "delta time" instead of "time" into
>> >> HW register).
>> >>
>> >> drivers/net/ethernet/intel/igc/igc_main.c-1602- txtime = skb->tstamp;
>> >> drivers/net/ethernet/intel/igc/igc_main.c-1603- skb->tstamp = ktime_set(0, 0);
>> >> drivers/net/ethernet/intel/igc/igc_main.c:1604- launch_time =
>> >igc_tx_launchtime(tx_ring, txtime, &first_flag, &insert_empty);
>> >>
>> >> Do you think this is enough to say the API is sane?
>> >
>> >u64 nsec sounds sane to be. It must be made explicit with clock source
>> >it is against.
>> >
>>
>> The u64 launch time should base on NIC PTP hardware clock (PHC).
>> I will add documentation saying which clock source it is against
>
>It's not that obvious to me that that is the right and only choice.
>See below.
>
>> >Some applications could want to do the conversion from a clock source
>> >to raw NIC cycle counter in userspace or BPF and program the raw
>> >value. So it may be worthwhile to add an clock source argument -- even
>> >if initially only CLOCK_MONOTONIC is supported.
>>
>> Sorry, not so understand your suggestion on adding clock source argument.
>> Are you suggesting to add clock source for the selftest xdp_hw_metadata apps?
>> IMHO, no need to add clock source as the clock source for launch time
>> should always base on NIC PHC.
>
>This is not how FQ and ETF qdiscs pass timestamps to drivers today.
>
>Those are in CLOCK_MONOTONIC or CLOCK_TAI. The driver is expected to
>convert from that to its descriptor format, both to the reduced bit
>width and the NIC PHC.
>
>See also for instance how sch_etf has an explicit q->clock_id match,
>and SO_TXTIME added an sk_clock_id for the same purpose: to agree on
>which clock source is being used.

I see. Thank for the explanation. I will try to add clock source arguments
In next version.

From florian.bezdeka at siemens.com  Tue Dec  5 07:34:29 2023
From: florian.bezdeka at siemens.com (Florian Bezdeka)
Date: Tue, 05 Dec 2023 16:34:29 +0100
Subject: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC
In-Reply-To: <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
	 <20231203165129.1740512-3-yoong.siang.song@intel.com>
	 <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
	 <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
	 <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>
Message-ID: <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com>

On Tue, 2023-12-05 at 15:25 +0000, Song, Yoong Siang wrote:
> On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote:
> > Jesper Dangaard Brouer wrote:
> > > 
> > > 
> > > On 12/3/23 17:51, Song Yoong Siang wrote:
> > > > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > > > copy via XDP Tx metadata framework.
> > > > 
> > > > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > > > ---
> > > >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> > > 
> > > As requested before, I think we need to see another driver implementing
> > > this.
> > > 
> > > I propose driver igc and chip i225.
> 
> Sure. I will include igc patches in next version.
> 
> > > 
> > > The interesting thing for me is to see how the LaunchTime max 1 second
> > > into the future[1] is handled code wise. One suggestion is to add a
> > > section to Documentation/networking/xsk-tx-metadata.rst per driver that
> > > mentions/documents these different hardware limitations.  It is natural
> > > that different types of hardware have limitations.  This is a close-to
> > > hardware-level abstraction/API, and IMHO as long as we document the
> > > limitations we can expose this API without too many limitations for more
> > > capable hardware.
> 
> Sure. I will try to add hardware limitations in documentation. 
> 
> > 
> > I would assume that the kfunc will fail when a value is passed that
> > cannot be programmed.
> > 
> 
> In current design, the xsk_tx_metadata_request() dint got return value. 
> So user won't know if their request is fail. 
> It is complex to inform user which request is failing. 
> Therefore, IMHO, it is good that we let driver handle the error silently.
> 

If the programmed value is invalid, the packet will be "dropped" / will
never make it to the wire, right?

That is clearly a situation that the user should be informed about. For
RT systems this normally means that something is really wrong regarding
timing / cycle overflow. Such systems have to react on that situation.

>  
> 
> > What is being implemented here already exists for qdiscs. The FQ
> > qdisc takes a horizon attribute and
> > 
> >    "
> >    when a packet is beyond the horizon
> >        at enqueue() time:
> >        - either drop the packet (default policy)
> >        - or cap its delivery time to the horizon.
> >    "
> >    commit 39d010504e6b ("net_sched: sch_fq: add horizon attribute")
> > 
> > Having the admin manually configure this on the qdisc based on
> > off-line knowledge of the device is more fragile than if the device
> > would somehow signal its limit to the stack.
> > 
> > But I don't think we should add enforcement of that as a requirement
> > for this xdp extension of pacing.



From broonie at kernel.org  Tue Dec  5 07:41:22 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 15:41:22 +0000
Subject: [PATCH] spi: atmel: Prevent spi transfers from being killed
In-Reply-To: <20231205083102.16946-1-miquel.raynal@bootlin.com>
References: <20231205083102.16946-1-miquel.raynal@bootlin.com>
Message-ID: <170179088280.846111.402175605685351431.b4-ty@kernel.org>

On Tue, 05 Dec 2023 09:31:02 +0100, Miquel Raynal wrote:
> Upstream commit e0205d6203c2 ("spi: atmel: Prevent false timeouts on
> long transfers") has tried to mitigate the problem of getting spi
> transfers canceled because they were lasting too long. On slow buses,
> transfers in the MiB range can take more than one second and thus a
> calculation was added to progressively increment the timeout value. In
> order to not be too problematic from a user point of view (waiting dozen
> of seconds or even minutes), the wait call was turned interruptible.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: atmel: Prevent spi transfers from being killed
      commit: 890188d2d7e4ac6c131ba166ca116cb315e752ee

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From joey.gouly at arm.com  Tue Dec  5 07:41:16 2023
From: joey.gouly at arm.com (Joey Gouly)
Date: Tue, 5 Dec 2023 15:41:16 +0000
Subject: [PATCH v3 00/25] Permission Overlay Extension
In-Reply-To: <86jzpub56r.wl-maz@kernel.org>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <86jzpub56r.wl-maz@kernel.org>
Message-ID: <20231205154116.GA3613610@e124191.cambridge.arm.com>

Hi Marc,

On Mon, Dec 04, 2023 at 11:03:24AM +0000, Marc Zyngier wrote:
> Hi Joey,
> 
> On Fri, 24 Nov 2023 16:34:45 +0000,
> Joey Gouly <joey.gouly at arm.com> wrote:
> > 
> > Hello everyone,
> > 
> > This series implements the Permission Overlay Extension introduced in 2022
> > VMSA enhancements [1]. It is based on v6.7-rc2.
> > 
> > Changes since v2[2]:
> > 	# Added ptrace support and selftest
> > 	# Add missing POR_EL0 initialisation in fork/clone
> > 	# Rebase onto v6.7-rc2
> > 	# Add r-bs
> > 
> > The Permission Overlay Extension allows to constrain permissions on memory
> > regions. This can be used from userspace (EL0) without a system call or TLB
> > invalidation.
> 
> I have given this series a few more thoughts, and came to the
> conclusion that is it still incomplete on the KVM front:
> 
> * FEAT_S1POE often comes together with FEAT_S2POE. For obvious
>   reasons, we cannot afford to let the guest play with S2POR_EL1, nor
>   do we want to advertise FEAT_S2POE to the guest.
> 
>   You will need to add some additional FGT for this, and mask out
>   FEAT_S2POE from the guest's view of the ID registers.

I found out last week that I had misunderstood S2POR_EL1, so yes looks like
we need to trap that. I will add that in.

> 
> * letting the guest play with POE comes with some interesting strings
>   attached: a guest that has started on a POE-enabled host cannot be
>   migrated to one that doesn't have POE. which means that the POE
>   registers should only be visible to the host userspace if enabled in
>   the guest's ID registers, and thus only context-switched in these
>   conditions. They should otherwise UNDEF.

Can you give me some clarification here?
	
	- By visible to the host userspace do you mean via the GET_ONE_REG API?
	- Currently the ID register (ID_AA64MMFR3_EL1) is not ID_WRITABLE,
	  should this series or another make it so? Currently if the host had
	  POE it's enabled in the guest, so I believe migration to a non-POE
	  host will fail?
	- For the context switch, do you mean something like:

		if (system_supports_poe() && ID_REG(MMFR3_EL1) & S1POE)
			ctxt_sys_reg(ctxt, POR_EL0)     = read_sysreg_s(SYS_POR_EL0);

	  That would need some refactoring, since I don't see how to access
	  id_regs from struct kvm_cpu_context.

Thanks,
Joey


From nm at ti.com  Tue Dec  5 07:41:23 2023
From: nm at ti.com (Nishanth Menon)
Date: Tue, 5 Dec 2023 09:41:23 -0600
Subject: [PATCH] arm64: dts: ti: k3-am65: Add AM652 DTSI file
In-Reply-To: <20231117165330.98472-1-afd@ti.com>
References: <20231117165330.98472-1-afd@ti.com>
Message-ID: <20231205154123.dy3t5xcuzj6kzm3w@thorn>

On 10:53-20231117, Andrew Davis wrote:
> The AM652 is basically a AM654 but with 2 cores instead of 4. Add
> a DTSI file for AM652 matching AM654 except this core difference.
> 
> This removes the need to remove the extra cores from AM654 manually
> in DT files for boards that use the AM652 variant. Do that for
> the IOT2050 boards here.
> 
> Signed-off-by: Andrew Davis <afd at ti.com>
> ---
>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   |  1 -
>  arch/arm64/boot/dts/ti/k3-am652.dtsi          | 74 +++++++++++++++++++
>  .../ti/k3-am6528-iot2050-basic-common.dtsi    | 11 +--
>  .../ti/k3-am6548-iot2050-advanced-common.dtsi |  1 +
>  4 files changed, 76 insertions(+), 11 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/ti/k3-am652.dtsi
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> index ba1c14a54acf4..bd5273a37b095 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi


Could you rebase to latest next? patch doesn't apply anymore.

> @@ -9,7 +9,6 @@
>   * Common bits of the IOT2050 Basic and Advanced variants, PG1 and PG2
>   */
>  
> -#include "k3-am654.dtsi"
>  #include <dt-bindings/phy/phy.h>
>  
>  / {
> diff --git a/arch/arm64/boot/dts/ti/k3-am652.dtsi b/arch/arm64/boot/dts/ti/k3-am652.dtsi
> new file mode 100644
> index 0000000000000..0f22e00faa903
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am652.dtsi
> @@ -0,0 +1,74 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM65 SoC family in Dual core configuration
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include "k3-am65.dtsi"
> +
> +/ {
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		cpu-map {
> +			cluster0: cluster0 {
> +				core0 {
> +					cpu = <&cpu0>;
> +				};
> +
> +				core1 {
> +					cpu = <&cpu1>;
> +				};
> +			};
> +		};
> +
> +		cpu0: cpu at 0 {
> +			compatible = "arm,cortex-a53";
> +			reg = <0x000>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			i-cache-size = <0x8000>;
> +			i-cache-line-size = <64>;
> +			i-cache-sets = <256>;
> +			d-cache-size = <0x8000>;
> +			d-cache-line-size = <64>;
> +			d-cache-sets = <128>;
> +			next-level-cache = <&L2_0>;
> +		};
> +
> +		cpu1: cpu at 1 {
> +			compatible = "arm,cortex-a53";
> +			reg = <0x001>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			i-cache-size = <0x8000>;
> +			i-cache-line-size = <64>;
> +			i-cache-sets = <256>;
> +			d-cache-size = <0x8000>;
> +			d-cache-line-size = <64>;
> +			d-cache-sets = <128>;
> +			next-level-cache = <&L2_0>;
> +		};
> +	};
> +
> +	L2_0: l2-cache0 {
> +		compatible = "cache";
> +		cache-level = <2>;
> +		cache-unified;
> +		cache-size = <0x80000>;
> +		cache-line-size = <64>;
> +		cache-sets = <512>;
> +		next-level-cache = <&msmc_l3>;
> +	};
> +
> +	msmc_l3: l3-cache0 {
> +		compatible = "cache";
> +		cache-level = <3>;
> +		cache-unified;
> +	};
> +
> +	thermal_zones: thermal-zones {
> +		#include "k3-am654-industrial-thermal.dtsi"
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
> index 5ab434c02ab6b..feb0eae4e6df4 100644
> --- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
> @@ -9,6 +9,7 @@
>   * Common bits of the IOT2050 Basic variant, PG1 and PG2
>   */
>  
> +#include "k3-am652.dtsi"
>  #include "k3-am65-iot2050-common.dtsi"
>  
>  / {
> @@ -17,16 +18,6 @@ memory at 80000000 {
>  		/* 1G RAM */
>  		reg = <0x00000000 0x80000000 0x00000000 0x40000000>;
>  	};
> -
> -	cpus {
> -		cpu-map {
> -			/delete-node/ cluster1;
> -		};
> -		/delete-node/ cpu at 100;
> -		/delete-node/ cpu at 101;
> -	};
> -
> -	/delete-node/ l2-cache1;
>  };
>  
>  /* eMMC */
> diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi
> index be55494b1f3fc..ff2fdc2e12e3c 100644
> --- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi
> @@ -11,6 +11,7 @@
>  
>  /dts-v1/;
>  
> +#include "k3-am654.dtsi"
>  #include "k3-am65-iot2050-common.dtsi"
>  
>  / {
> -- 
> 2.39.2
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From acme at kernel.org  Tue Dec  5 07:51:12 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Tue, 5 Dec 2023 12:51:12 -0300
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com>
References: <20231204182330.654255-1-irogers@google.com>
 <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
 <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com>
Message-ID: <ZW9G8Clxwl6bd0H6@kernel.org>

Em Mon, Dec 04, 2023 at 07:33:18PM -0800, Namhyung Kim escreveu:
> On Mon, Dec 4, 2023 at 2:45?PM Ilkka Koskinen <ilkka at os.amperecomputing.com> wrote:
> > On Mon, 4 Dec 2023, Ian Rogers wrote:
> > > A metric is default by having "Default" within its groups. The default
> > > metricgroup name needn't be set and this can result in segv in
> > > default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
> > > that assume it has a value when there is a Default metric group. To
> > > avoid the segv initialize the value to "".

> > > Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
> > > Signed-off-by: Ian Rogers <irogers at google.com>

> > Thanks! I was going to look for the bug but got pulled to other
> > tasks. The patch looks good to me and I tested it successfully on
> > AmpereOne.

> >    Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
 
> Looks like it needs to go through perf-tools for v6.7.
> Ian, do you think this one is enough?

So I had this on my local perf-tools-next, removed now, I also have some
other fixes by Ian on the tmp.perf-tools-next, please let me know what
you guys decide to have in perf-tools for v6.7 so that I can remove it
from there.

- Arnaldo


From david at redhat.com  Tue Dec  5 08:00:14 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 17:00:14 +0100
Subject: [PATCH v8 10/10] selftests/mm/cow: Add tests for anonymous
 multi-size THP
In-Reply-To: <20231204102027.57185-11-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-11-ryan.roberts@arm.com>
Message-ID: <59d9f31d-bb7d-4046-ad85-da82c0e3eec8@redhat.com>

On 04.12.23 11:20, Ryan Roberts wrote:
> Add tests similar to the existing PMD-sized THP tests, but which operate
> on memory backed by (PTE-mapped) multi-size THP. This reuses all the
> existing infrastructure. If the test suite detects that multi-size THP
> is not supported by the kernel, the new tests are skipped.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---

Reviewed-by: David Hildenbrand <david at redhat.com>

-- 
Cheers,

David / dhildenb



From yuzenghui at huawei.com  Tue Dec  5 08:01:40 2023
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Wed, 6 Dec 2023 00:01:40 +0800
Subject: [PATCH] arm64: Delete the zero_za macro
Message-ID: <20231205160140.1438-1-yuzenghui@huawei.com>

zero_za was introduced in commit ca8a4ebcff44 ("arm64/sme: Manually encode
SME instructions") but doesn't appear to have any in kernel user. Drop it.

Signed-off-by: Zenghui Yu <yuzenghui at huawei.com>
---
 arch/arm64/include/asm/fpsimdmacros.h | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm64/include/asm/fpsimdmacros.h b/arch/arm64/include/asm/fpsimdmacros.h
index cdf6a35e3994..cda81d009c9b 100644
--- a/arch/arm64/include/asm/fpsimdmacros.h
+++ b/arch/arm64/include/asm/fpsimdmacros.h
@@ -242,14 +242,6 @@
 		| (\nx << 5)
 .endm
 
-/*
- * Zero the entire ZA array
- *	ZERO ZA
- */
-.macro zero_za
-	.inst 0xc00800ff
-.endm
-
 .macro __for from:req, to:req
 	.if (\from) == (\to)
 		_for__body %\from
-- 
2.33.0



From willy at infradead.org  Tue Dec  5 08:05:50 2023
From: willy at infradead.org (Matthew Wilcox)
Date: Tue, 5 Dec 2023 16:05:50 +0000
Subject: [PATCH v6 0/9] variable-order, large folios for anonymous memory
In-Reply-To: <181a25c2-219e-4af9-9f8e-e5f514bbc4b6@arm.com>
References: <20230929114421.3761121-1-ryan.roberts@arm.com>
 <c507308d-bdd4-5f9e-d4ff-e96e4520be85@nvidia.com>
 <ZVGxkMeY50JSesaj@casper.infradead.org>
 <f1fa098b-210e-41a9-80fc-aec212976610@arm.com>
 <ZVI65lck7WqsHZwF@casper.infradead.org>
 <181a25c2-219e-4af9-9f8e-e5f514bbc4b6@arm.com>
Message-ID: <ZW9KXpsF7y5MvSlJ@casper.infradead.org>

On Tue, Nov 14, 2023 at 10:57:07AM +0000, Ryan Roberts wrote:
> On 13/11/2023 15:04, Matthew Wilcox wrote:
> > On Mon, Nov 13, 2023 at 10:19:48AM +0000, Ryan Roberts wrote:
> >> On 13/11/2023 05:18, Matthew Wilcox wrote:
> >>> My hope is to abolish the 64kB page size configuration.  ie instead of
> >>> using the mixture of page sizes that you currently are -- 64k and
> >>> 1M (right?  Order-0, and order-4)
> >>
> >> Not quite; the contpte-size for a 64K page size is 2M/order-5. (and yes, it is
> >> 64K/order-4 for a 4K page size, and 2M/order-7 for a 16K page size. I agree that
> >> intuitively you would expect the order to remain constant, but it doesn't).
> >>
> >> The "recommend" setting above will actually enable order-3 as well even though
> >> there is no HW benefit to this. So the full set of available memory sizes here is:
> >>
> >> 64K/order-0, 512K/order-3, 2M/order-5, 512M/order-13
> >>
> >>> , that 4k, 64k and 2MB (order-0,
> >>> order-4 and order-9) will provide better performance.
> >>>
> >>> Have you run any experiements with a 4kB page size?
> >>
> >> Agree that would be interesting with 64K small-sized THP enabled. And I'd love
> >> to get to a world were we universally deal in variable sized chunks of memory,
> >> aligned on 4K boundaries.
> >>
> >> In my experience though, there are still some performance benefits to 64K base
> >> page vs 4K+contpte; the page tables are more cache efficient for the former case
> >> - 64K of memory is described by 8 bytes in the former vs 8x16=128 bytes in the
> >> latter. In practice the HW will still only read 8 bytes in the latter but that's
> >> taking up a full cache line vs the former where a single cache line stores 8x
> >> 64K entries.
> > 
> > This is going to depend on your workload though -- if you're using more
> > 2MB than 64kB, you get to elide a layer of page table with 4k base,
> > rather than taking up 4 cache lines with a 64k base.
> 
> True, but again depending on workload/config, you may have few levels of lookup
> for the 64K native case in the first place because you consume more VA bits at
> each level.

Sorry, missed this email ... let's work it through.

With 4k, and a 48-bit VA space, we get 12 bits at the lowest level, then
9 bits each layer, so 4 * 9 + 12 = 48.  With a 2MB allocation, we
eliminate the bottom layer and examine three cachelines to find it (PGD
entry, PUD entry, PMD entry)

With 64k, we get 16 bits at the lowest level, then 13 bits each layer,
so 3 * 13 + 16 = 55.  With a 2MB allocation, we can't eliminate the
bottom layer, so we still have to examine three cachelines to find it
(PGD, PMD, PTE).  If you can fit into a 42-bit address space, you can
reduce it by one cache miss, but my impression is that applications
which use 21 bits of address space for a single allocation want more
address space than your average application.


From u.kleine-koenig at pengutronix.de  Tue Dec  5 08:12:18 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 5 Dec 2023 17:12:18 +0100
Subject: (subset) [PATCH 00/17] dt-bindings: samsung: add specific
 compatibles for existing SoC
In-Reply-To: <ZW8ZNZ_FJSV8fq-U@orome.fritz.box>
References: <20231108104343.24192-1-krzysztof.kozlowski@linaro.org>
 <170119374454.445690.515311393756577368.b4-ty@gmail.com>
 <20231128205841.al23ra5s34rn3muj@pengutronix.de>
 <ZW8ZNZ_FJSV8fq-U@orome.fritz.box>
Message-ID: <20231205161218.wymlzvhk4pnnkwze@pengutronix.de>

Hello Thierry,

On Tue, Dec 05, 2023 at 01:36:05PM +0100, Thierry Reding wrote:
> On Tue, Nov 28, 2023 at 09:58:41PM +0100, Uwe Kleine-K?nig wrote:
> > On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
> > > 
> > > On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
> > > > Merging
> > > > =======
> > > > I propose to take entire patchset through my tree (Samsung SoC), because:
> >     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > > > 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
> > > >    they will touch the same lines in some of the DT bindings (not all, though).
> > > >    It is reasonable for me to take the bindings for the new SoCs, to have clean
> > > >    `make dtbs_check` on the new DTS.
> > > > 2. Having it together helps me to have clean `make dtbs_check` within my tree
> > > >    on the existing DTS.
> > > > 3. No drivers are affected by this change.
> > > > 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
> > > >    follow up patchsets.
> > > > 
> > > > [...]
> > > 
> > > Applied, thanks!
> > > 
> > > [12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
> > >         commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f
> > 
> > You didn't honor (or even comment) Krzysztof's proposal to take the
> > whole patchset via his tree (marked above). Was there some off-list
> > agreement?
> 
> I had read all that and then looking at patchwork saw that you had
> marked all other patches in the series as "handled-elsewhere" and only
> this one was left as "new", so I assumed that, well, everything else was
> handled elsewhere and I was supposed to pick this one up...

I didn't mark it as handled-elsewhere, but my expectation was that you
might want to send an Ack only.

For today's series by Krzysztof I acked and marked the patch as
handled-elsewhere (together with the rest of the series that isn't pwm
related). So you have to consult your inbox if you still want to send an
Ack for that one.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/b28a341d/attachment.sig>

From afd at ti.com  Tue Dec  5 08:13:07 2023
From: afd at ti.com (Andrew Davis)
Date: Tue, 5 Dec 2023 10:13:07 -0600
Subject: [PATCH v2 1/2] arm64: dts: ti: k3-j721e-evm: Add overlay for
 PCIE0 Endpoint Mode
In-Reply-To: <20231115085204.3578616-2-s-vadapalli@ti.com>
References: <20231115085204.3578616-1-s-vadapalli@ti.com>
 <20231115085204.3578616-2-s-vadapalli@ti.com>
Message-ID: <c50f5dc2-8ab8-4213-a809-fcd4cd18589d@ti.com>

On 11/15/23 2:52 AM, Siddharth Vadapalli wrote:
> Add overlay to enable the PCIE0 instance of PCIe on J721E-EVM in
> Endpoint mode of operation.
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> ---
>   arch/arm64/boot/dts/ti/Makefile               |  3 ++
>   .../boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso    | 53 +++++++++++++++++++
>   2 files changed, 56 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
> 
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 77a347f9f47d..5620db44d4dc 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -66,6 +66,8 @@ dtb-$(CONFIG_ARCH_K3) += k3-j7200-evm.dtb
>   k3-j721e-evm-dtbs := k3-j721e-common-proc-board.dtb k3-j721e-evm-quad-port-eth-exp.dtbo
>   dtb-$(CONFIG_ARCH_K3) += k3-j721e-beagleboneai64.dtb
>   dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm.dtb
> +k3-j721e-evm-pcie0-ep-dtbs := k3-j721e-evm.dtb k3-j721e-evm-pcie0-ep.dtbo
> +dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie0-ep.dtb

Do you really need to produce this pre-combined DTB file? If you would rather
just the overlay produced which could be applied at load-time (I prefer this),
then you should do as Jai has done[0]. Add just the overlay, and test its
application using a dummy target.

Andrew

[0] https://www.spinics.net/lists/kernel/msg5015247.html

>   dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-gesi-exp-board.dtbo
>   dtb-$(CONFIG_ARCH_K3) += k3-j721e-sk.dtb
>   
> @@ -85,4 +87,5 @@ DTC_FLAGS_k3-am625-sk += -@
>   DTC_FLAGS_k3-am62-lp-sk += -@
>   DTC_FLAGS_k3-am6548-iot2050-advanced-m2 += -@
>   DTC_FLAGS_k3-j721e-common-proc-board += -@
> +DTC_FLAGS_k3-j721e-evm += -@
>   DTC_FLAGS_k3-j721s2-common-proc-board += -@
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso b/arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
> new file mode 100644
> index 000000000000..0c82a13b65a4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/**
> + * DT Overlay for enabling PCIE0 instance in Endpoint Configuration with the
> + * J7 common processor board.
> + *
> + * J7 Common Processor Board Product Link: https://www.ti.com/tool/J721EXCPXEVM
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +#include "k3-pinctrl.h"
> +
> +/*
> + * Since Root Complex and Endpoint modes are mutually exclusive
> + * disable Root Complex mode.
> + */
> +&pcie0_rc {
> +	status = "disabled";
> +};
> +
> +&cbass_main {
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +	interrupt-parent = <&gic500>;
> +
> +	pcie0_ep: pcie-ep at 2900000 {
> +		compatible = "ti,j721e-pcie-ep";
> +		reg = <0x00 0x02900000 0x00 0x1000>,
> +		      <0x00 0x02907000 0x00 0x400>,
> +		      <0x00 0x0d000000 0x00 0x00800000>,
> +		      <0x00 0x10000000 0x00 0x08000000>;
> +		reg-names = "intd_cfg", "user_cfg", "reg", "mem";
> +		interrupt-names = "link_state";
> +		interrupts = <GIC_SPI 318 IRQ_TYPE_EDGE_RISING>;
> +		ti,syscon-pcie-ctrl = <&scm_conf 0x4070>;
> +		max-link-speed = <3>;
> +		num-lanes = <1>;
> +		power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
> +		clocks = <&k3_clks 239 1>;
> +		clock-names = "fck";
> +		max-functions = /bits/ 8 <6>;
> +		max-virtual-functions = /bits/ 8 <4 4 4 4 0 0>;
> +		dma-coherent;
> +		phys = <&serdes0_pcie_link>;
> +		phy-names = "pcie-phy";
> +	};
> +};


From catalin.marinas at arm.com  Tue Dec  5 08:22:33 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 5 Dec 2023 16:22:33 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231205130517.GD2692119@nvidia.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
Message-ID: <ZW9OSe8Z9gAmM7My@arm.com>

On Tue, Dec 05, 2023 at 09:05:17AM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 05, 2023 at 11:40:47AM +0000, Catalin Marinas wrote:
> > > - Will had unanswered questions in another part of the thread:
> > > 
> > >   https://lore.kernel.org/all/20231013092954.GB13524 at willie-the-truck/
> > > 
> > >   Can someone please help concluding it?
> > 
> > Is this about reclaiming the device? I think we concluded that we can't
> > generalise this beyond PCIe, though not sure there was any formal
> > statement to that thread. The other point Will had was around stating
> > in the commit message why we only relax this to Normal NC. I haven't
> > checked the commit message yet, it needs careful reading ;).
> 
> Not quite, we said reclaiming is VFIO's problem and if VFIO can't
> reliably reclaim a device it shouldn't create it in the first place.
> 
> Again, I think alot of this is trying to take VFIO problems into KVM.
> 
> VFIO devices should not exist if they pose a harm to the system. If
> VFIO decided to create the devices anyhow (eg admin override or
> something) then it is not KVM's job to do any further enforcement.

Yeah, I made this argument in the past. But it's a fair question to ask
since the Arm world is different from x86. Just reusing an existing
driver in a different context may break its expectations. Does Normal NC
access complete by the time a TLBI (for Stage 2) and DSB (DVMsync) is
completed? It does reach some point of serialisation with subsequent
accesses to the same address but not sure how it is ordered with an
access to a different location like the config space used for reset.
Maybe it's not a problem at all or it is safe only for PCIe but it would
be good to get to the bottom of this.

Device-nGnRnE has some stronger rules around end-point completion and
that's what the vfio-pci uses. KVM, however, went for the slightly more
relaxed nGnRE variant which, at least per the Arm ARM, doesn't have
these guarantees.

> Remember, the feedback we got from the CPU architects was that even
> DEVICE_* will experience an uncontained failure if the device tiggers
> an error response in shipping ARM IP.
> 
> The reason PCIe is safe is because the PCI bridge does not generate
> errors in the first place!

That's an argument to restrict this feature to PCIe. It's really about
fewer arguments on the behaviour of other devices. Marc did raise
another issue with the GIC VCPU interface (does this even have a vma in
the host VMM?). That's a class of devices where the mapping is
context-switched, so the TLBI+DSB rules don't help.

> Thus, the way a platform device can actually be safe is if it too
> never generates errors in the first place! Obviously this approach
> works just as well with NORMAL_NC.
> 
> If a platform device does generate errors then we shouldn't expect
> containment at all, and the memory type has no bearing on the
> safety. The correct answer is to block these platform devices from
> VFIO/KVM/etc because they can trigger uncontained failures.

Assuming the error containment is sorted, there are two other issues
with other types of devices:

1. Ordering guarantees on reclaim or context switch

2. Unaligned accesses

On (2), I think PCIe is fairly clear on how the TLPs are generated, so I
wouldn't expect additional errors here. But I have no idea what AMBA/AXI
does here in general. Perhaps it's fine, I don't think we looked into it
as the focus was mostly on PCIe.

So, I think it would be easier to get this patch upstream if we limit
the change to PCIe devices for now. We may relax this further in the
future. Do you actually have a need for non-PCIe devices to support WC
in the guest or it's more about the complexity of the logic to detect
whether it's actually a PCIe BAR we are mapping into the guest? (I can
see some Arm GPU folk asking for this but those devices are not easily
virtualisable).

-- 
Catalin


From afd at ti.com  Tue Dec  5 08:23:58 2023
From: afd at ti.com (Andrew Davis)
Date: Tue, 5 Dec 2023 10:23:58 -0600
Subject: [PATCH v2] arm64: dts: ti: k3-am65: Add AM652 DTSI file
Message-ID: <20231205162358.23904-1-afd@ti.com>

The AM652 is basically a AM654 but with 2 cores instead of 4. Add
a DTSI file for AM652 matching AM654 except this core difference.

This removes the need to remove the extra cores from AM654 manually
in DT files for boards that use the AM652 variant. Do that for
the IOT2050 boards here.

Signed-off-by: Andrew Davis <afd at ti.com>
Reviewed-by: Bryan Brattlof <bb at ti.com>
---

Changes for v2:
 - Add r-b
 - Rebase on next-20231204

 .../boot/dts/ti/k3-am65-iot2050-common.dtsi   |  1 -
 arch/arm64/boot/dts/ti/k3-am652.dtsi          | 74 +++++++++++++++++++
 .../ti/k3-am6528-iot2050-basic-common.dtsi    | 11 +--
 .../ti/k3-am6548-iot2050-advanced-common.dtsi |  1 +
 4 files changed, 76 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am652.dtsi

diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
index ab1dffa5c1c6f..73ff119d85cdc 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -9,7 +9,6 @@
  * Common bits of the IOT2050 Basic and Advanced variants, PG1 and PG2
  */
 
-#include "k3-am654.dtsi"
 #include <dt-bindings/phy/phy.h>
 #include <dt-bindings/net/ti-dp83867.h>
 
diff --git a/arch/arm64/boot/dts/ti/k3-am652.dtsi b/arch/arm64/boot/dts/ti/k3-am652.dtsi
new file mode 100644
index 0000000000000..0f22e00faa903
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am652.dtsi
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM65 SoC family in Dual core configuration
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-am65.dtsi"
+
+/ {
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu-map {
+			cluster0: cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+
+				core1 {
+					cpu = <&cpu1>;
+				};
+			};
+		};
+
+		cpu0: cpu at 0 {
+			compatible = "arm,cortex-a53";
+			reg = <0x000>;
+			device_type = "cpu";
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&L2_0>;
+		};
+
+		cpu1: cpu at 1 {
+			compatible = "arm,cortex-a53";
+			reg = <0x001>;
+			device_type = "cpu";
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&L2_0>;
+		};
+	};
+
+	L2_0: l2-cache0 {
+		compatible = "cache";
+		cache-level = <2>;
+		cache-unified;
+		cache-size = <0x80000>;
+		cache-line-size = <64>;
+		cache-sets = <512>;
+		next-level-cache = <&msmc_l3>;
+	};
+
+	msmc_l3: l3-cache0 {
+		compatible = "cache";
+		cache-level = <3>;
+		cache-unified;
+	};
+
+	thermal_zones: thermal-zones {
+		#include "k3-am654-industrial-thermal.dtsi"
+	};
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
index 5ab434c02ab6b..feb0eae4e6df4 100644
--- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
@@ -9,6 +9,7 @@
  * Common bits of the IOT2050 Basic variant, PG1 and PG2
  */
 
+#include "k3-am652.dtsi"
 #include "k3-am65-iot2050-common.dtsi"
 
 / {
@@ -17,16 +18,6 @@ memory at 80000000 {
 		/* 1G RAM */
 		reg = <0x00000000 0x80000000 0x00000000 0x40000000>;
 	};
-
-	cpus {
-		cpu-map {
-			/delete-node/ cluster1;
-		};
-		/delete-node/ cpu at 100;
-		/delete-node/ cpu at 101;
-	};
-
-	/delete-node/ l2-cache1;
 };
 
 /* eMMC */
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi
index be55494b1f3fc..ff2fdc2e12e3c 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-common.dtsi
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 
+#include "k3-am654.dtsi"
 #include "k3-am65-iot2050-common.dtsi"
 
 / {
-- 
2.39.2



From catalin.marinas at arm.com  Tue Dec  5 08:24:22 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 5 Dec 2023 16:24:22 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231205144417.GE2692119@nvidia.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW81mT4WqKqtLnid@lpieralisi>
 <20231205144417.GE2692119@nvidia.com>
Message-ID: <ZW9OtrUa_fPA0_Ns@arm.com>

On Tue, Dec 05, 2023 at 10:44:17AM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 05, 2023 at 03:37:13PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, Dec 05, 2023 at 09:05:17AM -0400, Jason Gunthorpe wrote:
> > > On Tue, Dec 05, 2023 at 11:40:47AM +0000, Catalin Marinas wrote:
> > > > > - Will had unanswered questions in another part of the thread:
> > > > > 
> > > > >   https://lore.kernel.org/all/20231013092954.GB13524 at willie-the-truck/
> > > > > 
> > > > >   Can someone please help concluding it?
> > > > 
> > > > Is this about reclaiming the device? I think we concluded that we can't
> > > > generalise this beyond PCIe, though not sure there was any formal
> > > > statement to that thread. The other point Will had was around stating
> > > > in the commit message why we only relax this to Normal NC. I haven't
> > > > checked the commit message yet, it needs careful reading ;).
> > > 
> > > Not quite, we said reclaiming is VFIO's problem and if VFIO can't
> > > reliably reclaim a device it shouldn't create it in the first place.
> > 
> > I think that as far as device reclaiming was concerned the question
> > posed was related to memory attributes of transactions for guest
> > mappings and the related grouping/ordering with device reset MMIO
> > transactions - it was not (or wasn't only) about error containment.
> 
> Yes. It is VFIO that issues the reset, it is VFIO that must provide
> the ordering under the assumption that NORMAL_NC was used.

And does it? Because VFIO so far only assumes Device-nGnRnE. Do we need
to address this first before attempting to change KVM? Sorry, just
questions, trying to clear the roadblocks.

-- 
Catalin


From david at redhat.com  Tue Dec  5 08:32:30 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 17:32:30 +0100
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <20231204102027.57185-5-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
Message-ID: <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>

On 04.12.23 11:20, Ryan Roberts wrote:
> Introduce the logic to allow THP to be configured (through the new sysfs
> interface we just added) to allocate large folios to back anonymous
> memory, which are larger than the base page size but smaller than
> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
> 
> mTHP continues to be PTE-mapped, but in many cases can still provide
> similar benefits to traditional PMD-sized THP: Page faults are
> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
> the configured order), but latency spikes are much less prominent
> because the size of each page isn't as huge as the PMD-sized variant and
> there is less memory to clear in each page fault. The number of per-page
> operations (e.g. ref counting, rmap management, lru list management) are
> also significantly reduced since those ops now become per-folio.
> 
> Some architectures also employ TLB compression mechanisms to squeeze
> more entries in when a set of PTEs are virtually and physically
> contiguous and approporiately aligned. In this case, TLB misses will
> occur less often.
> 
> The new behaviour is disabled by default, but can be enabled at runtime
> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
> (see documentation in previous commit). The long term aim is to change
> the default to include suitable lower orders, but there are some risks
> around internal fragmentation that need to be better understood first.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>

In general, looks good to me, some comments/nits. And the usual "let's 
make sure we don't degrade order-0 and keep that as fast as possible" 
comment.

> ---
>   include/linux/huge_mm.h |   6 ++-
>   mm/memory.c             | 106 ++++++++++++++++++++++++++++++++++++----
>   2 files changed, 101 insertions(+), 11 deletions(-)
> 
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index bd0eadd3befb..91a53b9835a4 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>   #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>   
>   /*
> - * Mask of all large folio orders supported for anonymous THP.
> + * Mask of all large folio orders supported for anonymous THP; all orders up to
> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
> + * (which is a limitation of the THP implementation).
>    */
> -#define THP_ORDERS_ALL_ANON	BIT(PMD_ORDER)
> +#define THP_ORDERS_ALL_ANON	((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>   
>   /*
>    * Mask of all large folio orders supported for file THP.
> diff --git a/mm/memory.c b/mm/memory.c
> index 3ceeb0f45bf5..bf7e93813018 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>   	return ret;
>   }
>   
> +static bool pte_range_none(pte_t *pte, int nr_pages)
> +{
> +	int i;
> +
> +	for (i = 0; i < nr_pages; i++) {
> +		if (!pte_none(ptep_get_lockless(pte + i)))
> +			return false;
> +	}
> +
> +	return true;
> +}
> +
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
> +{
> +	gfp_t gfp;
> +	pte_t *pte;
> +	unsigned long addr;
> +	struct folio *folio;
> +	struct vm_area_struct *vma = vmf->vma;
> +	unsigned long orders;
> +	int order;

Nit: reverse christmas tree encouraged ;)

> +
> +	/*
> +	 * If uffd is active for the vma we need per-page fault fidelity to
> +	 * maintain the uffd semantics.
> +	 */
> +	if (userfaultfd_armed(vma))

Nit: unlikely()

> +		goto fallback;
> +
> +	/*
> +	 * Get a list of all the (large) orders below PMD_ORDER that are enabled
> +	 * for this vma. Then filter out the orders that can't be allocated over
> +	 * the faulting address and still be fully contained in the vma.
> +	 */
> +	orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
> +					  BIT(PMD_ORDER) - 1);
> +	orders = thp_vma_suitable_orders(vma, vmf->address, orders);

Comment: Both will eventually loop over all orders, correct? Could 
eventually be sped up in the future.

Nit: the orders = ... order = ... looks like this might deserve a helper 
function that makes this easier to read.

Nit: Why call thp_vma_suitable_orders if the orders are already 0? 
Again, some helper might be reasonable where that is handled internally.

Comment: For order-0 we'll always perform a function call to both 
thp_vma_allowable_orders() / thp_vma_suitable_orders(). We should 
perform some fast and efficient check if any <PMD THP are even enabled 
in the system / for this VMA, and in that case just fallback before 
doing more expensive checks.

> +
> +	if (!orders)
> +		goto fallback;
> +
> +	pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
> +	if (!pte)
> +		return ERR_PTR(-EAGAIN);
> +
> +	order = first_order(orders);
> +	while (orders) {
> +		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> +		vmf->pte = pte + pte_index(addr);
> +		if (pte_range_none(vmf->pte, 1 << order))
> +			break;

Comment: Likely it would make sense to scan only once and determine the 
"largest none range" around that address, having the largest suitable 
order in mind.

> +		order = next_order(&orders, order);
> +	}
> +
> +	vmf->pte = NULL;

Nit: Can you elaborate why you are messing with vmf->pte here? A simple 
helper variable will make this code look less magical. Unless I am 
missing something important :)

> +	pte_unmap(pte);
> +
> +	gfp = vma_thp_gfp_mask(vma);
> +
> +	while (orders) {
> +		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> +		folio = vma_alloc_folio(gfp, order, vma, addr, true);
> +		if (folio) {
> +			clear_huge_page(&folio->page, addr, 1 << order);
> +			return folio;
> +		}
> +		order = next_order(&orders, order);
> +	}
> +

Queestion: would it make sense to combine both loops? I suspect memory 
allocations with pte_offset_map()/kmao are problematic.

> +fallback:
> +	return vma_alloc_zeroed_movable_folio(vma, vmf->address);
> +}
> +#else
> +#define alloc_anon_folio(vmf) \
> +		vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
> +#endif
> +
>   /*
>    * We enter with non-exclusive mmap_lock (to exclude vma changes,
>    * but allow concurrent faults), and pte mapped but not yet locked.
> @@ -4132,6 +4210,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>    */
>   static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>   {
> +	int i;
> +	int nr_pages = 1;
> +	unsigned long addr = vmf->address;
>   	bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
>   	struct vm_area_struct *vma = vmf->vma;
>   	struct folio *folio;

Nit: reverse christmas tree :)

> @@ -4176,10 +4257,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>   	/* Allocate our own private page. */
>   	if (unlikely(anon_vma_prepare(vma)))
>   		goto oom;
> -	folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
> +	folio = alloc_anon_folio(vmf);
> +	if (IS_ERR(folio))
> +		return 0;
>   	if (!folio)
>   		goto oom;
>   
> +	nr_pages = folio_nr_pages(folio);
> +	addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
> +
>   	if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
>   		goto oom_free_page;
>   	folio_throttle_swaprate(folio, GFP_KERNEL);
> @@ -4196,12 +4282,13 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>   	if (vma->vm_flags & VM_WRITE)
>   		entry = pte_mkwrite(pte_mkdirty(entry), vma);
>   
> -	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
> -			&vmf->ptl);
> +	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
>   	if (!vmf->pte)
>   		goto release;
> -	if (vmf_pte_changed(vmf)) {
> -		update_mmu_tlb(vma, vmf->address, vmf->pte);
> +	if ((nr_pages == 1 && vmf_pte_changed(vmf)) ||
> +	    (nr_pages  > 1 && !pte_range_none(vmf->pte, nr_pages))) {
> +		for (i = 0; i < nr_pages; i++)
> +			update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);

Comment: separating the order-0 case from the other case might make this 
easier to read.

>   		goto release;
>   	}
>   
> @@ -4216,16 +4303,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>   		return handle_userfault(vmf, VM_UFFD_MISSING);
>   	}
>   
> -	inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
> -	folio_add_new_anon_rmap(folio, vma, vmf->address);
> +	folio_ref_add(folio, nr_pages - 1);
> +	add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
> +	folio_add_new_anon_rmap(folio, vma, addr);
>   	folio_add_lru_vma(folio, vma);
>   setpte:
>   	if (uffd_wp)
>   		entry = pte_mkuffd_wp(entry);
> -	set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
> +	set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
>   
>   	/* No need to invalidate - it was non-present before */
> -	update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
> +	update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
>   unlock:
>   	if (vmf->pte)
>   		pte_unmap_unlock(vmf->pte, vmf->ptl);

Benchmarking order-0 allocations might be interesting. There will be 
some added checks + multiple loops/conditionals for order-0 that could 
be avoided by having two separate code paths. If we can't measure a 
difference, all good.

-- 
Cheers,

David / dhildenb



From suzuki.poulose at arm.com  Tue Dec  5 08:34:52 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 5 Dec 2023 16:34:52 +0000
Subject: [PATCH v6 2/3] arm64: perf: Add support for event counting
 threshold
In-Reply-To: <1a74fef6-7f51-a518-4258-5f693b56add9@arm.com>
References: <20231124102857.1106453-1-james.clark@arm.com>
 <20231124102857.1106453-3-james.clark@arm.com>
 <20231205131414.GA18119@willie-the-truck>
 <1a74fef6-7f51-a518-4258-5f693b56add9@arm.com>
Message-ID: <0c423476-3126-4bc5-a6df-03c37f107717@arm.com>

On 05/12/2023 15:05, James Clark wrote:
> 
> 
> On 05/12/2023 13:14, Will Deacon wrote:
>> On Fri, Nov 24, 2023 at 10:28:56AM +0000, James Clark wrote:
>>> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
>>> index 1d40d794f5e4..eb1ef84e1dbb 100644
>>> --- a/drivers/perf/arm_pmuv3.c
>>> +++ b/drivers/perf/arm_pmuv3.c
>>> @@ -15,6 +15,7 @@
>>>   #include <clocksource/arm_arch_timer.h>
>>>   
>>>   #include <linux/acpi.h>
>>> +#include <linux/bitfield.h>
>>>   #include <linux/clocksource.h>
>>>   #include <linux/of.h>
>>>   #include <linux/perf/arm_pmu.h>
>>> @@ -294,9 +295,20 @@ static const struct attribute_group armv8_pmuv3_events_attr_group = {
>>>   	.is_visible = armv8pmu_event_attr_is_visible,
>>>   };
>>>   
>>> +#define THRESHOLD_LOW		2
>>> +#define THRESHOLD_HIGH		13
>>> +#define THRESHOLD_CNT		14
>>> +#define THRESHOLD_CMP_LO	15
>>> +#define THRESHOLD_CMP_HI	16
>>
>> Do you think THWIDTH might extend beyond 12 bits in future? If so, it might
>> be worth juggling these bits around a bit so it's not sandwiched between
>> 'rdpmc' and 'threshold_compare'. I defer to your judgement, however.
>>
> 
> It's possible, both PMMIR.THWIDTH and PMEVTYPER.TH currently have unused
> bits above them. I can easily move threshold to the end, I suppose that
> covers us at least until someone adds a new field above that.
> 
>>>   PMU_FORMAT_ATTR(event, "config:0-15");
>>>   PMU_FORMAT_ATTR(long, "config1:0");
>>>   PMU_FORMAT_ATTR(rdpmc, "config1:1");
>>> +PMU_FORMAT_ATTR(threshold, "config1:" __stringify(THRESHOLD_LOW) "-"
>>> +				      __stringify(THRESHOLD_HIGH));
>>> +PMU_FORMAT_ATTR(threshold_compare, "config1:" __stringify(THRESHOLD_CMP_LO) "-"
>>> +					      __stringify(THRESHOLD_CMP_HI));
>>> +PMU_FORMAT_ATTR(threshold_count, "config1:" __stringify(THRESHOLD_CNT));
>>>   
>>>   static int sysctl_perf_user_access __read_mostly;
>>>   
>>> @@ -310,10 +322,33 @@ static inline bool armv8pmu_event_want_user_access(struct perf_event *event)
>>>   	return event->attr.config1 & 0x2;
>>>   }
>>>   
>>> +static inline u32 armv8pmu_event_threshold(struct perf_event_attr *attr)
>>> +{
>>> +	return FIELD_GET(GENMASK(THRESHOLD_HIGH, THRESHOLD_LOW), attr->config1);
>>> +}
>>> +
>>> +static inline u8 armv8pmu_event_threshold_control(struct perf_event_attr *attr)
>>
>> You can drop the 'inline's for these functions (and, in fact, this whole
>> file could do with that cleanup :)
>>
> 
> Will do.
> 
>>> +{
>>> +	u8 th_compare = FIELD_GET(GENMASK(THRESHOLD_CMP_HI, THRESHOLD_CMP_LO),
>>> +				  attr->config1);
>>> +	u8 th_count = FIELD_GET(BIT(THRESHOLD_CNT), attr->config1);
>>
>> I think this is correct, but you might want to look at how we handle this
>> in the SPE driver as I think it ends up looking cleaner and makes it pretty
>> obvious which bits correspond to the user ABI (i.e. config fields) and which
>> bits are part of architectural registers. I'm not saying you have to do it
>> that way, but please take a look if you haven't already.
>>
> 
> Yeah I could take the GEN_PMU_FORMAT_ATTR() etc macros out of there and
> re-use them here too. And also for the other existing configs in
> arm_pmuv3.c.
> 
>>> +	/*
>>> +	 * The count bit is always the bottom bit of the full control field, and
>>> +	 * the comparison is the upper two bits, but it's not explicitly
>>> +	 * labelled in the Arm ARM. For the Perf interface we split it into two
>>> +	 * fields, so reconstruct it here.
>>> +	 */
>>> +	return (th_compare << 1) | th_count;
>>> +}
>>> +
>>>   static struct attribute *armv8_pmuv3_format_attrs[] = {
>>>   	&format_attr_event.attr,
>>>   	&format_attr_long.attr,
>>>   	&format_attr_rdpmc.attr,
>>> +	&format_attr_threshold.attr,
>>> +	&format_attr_threshold_compare.attr,
>>> +	&format_attr_threshold_count.attr,
>>>   	NULL,
>>>   };
>>>   
>>> @@ -365,10 +400,38 @@ static ssize_t bus_width_show(struct device *dev, struct device_attribute *attr,
>>>   
>>>   static DEVICE_ATTR_RO(bus_width);
>>>   
>>> +static u32 threshold_max(struct arm_pmu *cpu_pmu)
>>> +{
>>> +	/*
>>> +	 * PMMIR.THWIDTH is readable and non-zero on aarch32, but it would be
>>> +	 * impossible to write the threshold in the upper 32 bits of PMEVTYPER.
>>> +	 */
>>> +	if (IS_ENABLED(CONFIG_ARM))
>>> +		return 0;
>>> +
>>> +	/*
>>> +	 * The largest value that can be written to PMEVTYPER<n>_EL0.TH is
>>> +	 * (2 ^ PMMIR.THWIDTH) - 1.
>>> +	 */
>>> +	return (1 << FIELD_GET(ARMV8_PMU_THWIDTH, cpu_pmu->reg_pmmir)) - 1;
>>> +}
>>> +
>>> +static ssize_t threshold_max_show(struct device *dev,
>>> +				  struct device_attribute *attr, char *page)
>>> +{
>>> +	struct pmu *pmu = dev_get_drvdata(dev);
>>> +	struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
>>> +
>>> +	return sysfs_emit(page, "0x%08x\n", threshold_max(cpu_pmu));
>>> +}
>>> +
>>> +static DEVICE_ATTR_RO(threshold_max);
>>> +
>>>   static struct attribute *armv8_pmuv3_caps_attrs[] = {
>>>   	&dev_attr_slots.attr,
>>>   	&dev_attr_bus_slots.attr,
>>>   	&dev_attr_bus_width.attr,
>>> +	&dev_attr_threshold_max.attr,
>>>   	NULL,
>>>   };
>>>   
>>> @@ -552,7 +615,7 @@ static void armv8pmu_write_counter(struct perf_event *event, u64 value)
>>>   		armv8pmu_write_hw_counter(event, value);
>>>   }
>>>   
>>> -static inline void armv8pmu_write_evtype(int idx, u32 val)
>>> +static inline void armv8pmu_write_evtype(int idx, unsigned long val)
>>>   {
>>>   	u32 counter = ARMV8_IDX_TO_COUNTER(idx);
>>>   	unsigned long mask = ARMV8_PMU_EVTYPE_EVENT |
>>> @@ -921,6 +984,10 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>>>   				     struct perf_event_attr *attr)
>>>   {
>>>   	unsigned long config_base = 0;
>>> +	struct perf_event *perf_event = container_of(attr, struct perf_event,
>>> +						     attr);
>>> +	struct arm_pmu *cpu_pmu = to_arm_pmu(perf_event->pmu);
>>> +	u32 th, th_max;
>>>   
>>>   	if (attr->exclude_idle)
>>>   		return -EPERM;
>>> @@ -952,6 +1019,21 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>>>   	if (attr->exclude_user)
>>>   		config_base |= ARMV8_PMU_EXCLUDE_EL0;
>>>   
>>> +	/*
>>> +	 * Insert event counting threshold (FEAT_PMUv3_TH) values. If
>>> +	 * FEAT_PMUv3_TH isn't implemented, then THWIDTH (threshold_max) will be
>>> +	 * 0 and no values will be written.
>>> +	 */
>>> +	th_max = threshold_max(cpu_pmu);
>>> +	if (IS_ENABLED(CONFIG_ARM64) && th_max) {
>>
>> Why is the IS_ENABLED() check needed here?
>>
> 
> The FIELD_PREP() below would cause a compilation error on arm32 because
> TH and TC are above 32 bits. I can add a comment.
> 
>>> +		th = min(armv8pmu_event_threshold(attr), th_max);
>>> +		if (th) {
>>
>> Why is it useful to take the minimum here? If userspace asks for a value
>> bigger than the maximum support threshold, shouldn't we return an error
>> rather than silently clamp it?
>>
> 
> I think it probably was just so I didn't have to think about what would
> happen when the value varied between cores.
> 
> But you're right, it looks like I can add a validation function to
> struct arm_pmu and call it from armpmu_event_init(). armpmu->map_event()
> and armpmu->set_event_filter() are already called from there so I think
> the validation could technically be added to one of those, but that's
> probably a bit hacky. I don't know if you have any preference for where
> the threshold validation should happen?

I think the other reason was to make sure we never set those fields for
something that doesn't support the feature ? (Given th_max is set to 0
in that case). But I agree that validation is a better approach than
silently masking it.

Suzuki



> 
>>> +			config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TH, th);
>>> +			config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TC,
>>> +						  armv8pmu_event_threshold_control(attr));
>>> +		}
>>> +	}
>>> +
>>>   	/*
>>>   	 * Install the filter into config_base as this is used to
>>>   	 * construct the event type.
>>> diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
>>> index ddd1fec86739..ccbc0f9a74d8 100644
>>> --- a/include/linux/perf/arm_pmuv3.h
>>> +++ b/include/linux/perf/arm_pmuv3.h
>>> @@ -258,6 +258,7 @@
>>>   #define ARMV8_PMU_BUS_SLOTS_MASK 0xff
>>>   #define ARMV8_PMU_BUS_WIDTH_SHIFT 16
>>>   #define ARMV8_PMU_BUS_WIDTH_MASK 0xf
>>> +#define ARMV8_PMU_THWIDTH GENMASK(23, 20)
>>
>> It's a bit messy having a mixture of GENMASK and MASK/SHIFT pairs. Please
>> can you either update what's there to use GENMASK, or use SHIFT/MASK for the
>> new addition?
>>
>> Will
>>
> 
> Yep will do. Thanks for the review.
> 
> James



From david at redhat.com  Tue Dec  5 08:35:20 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 17:35:20 +0100
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
Message-ID: <1370c5b7-c914-4861-ad7a-90199723994a@redhat.com>

> Comment: Both will eventually loop over all orders, correct? Could
> eventually be sped up in the future.
> 
> Nit: the orders = ... order = ... looks like this might deserve a helper
> function that makes this easier to read.
> 
> Nit: Why call thp_vma_suitable_orders if the orders are already 0?
> Again, some helper might be reasonable where that is handled internally.
> 
> Comment: For order-0 we'll always perform a function call to both
> thp_vma_allowable_orders() / thp_vma_suitable_orders(). We should
> perform some fast and efficient check if any <PMD THP are even enabled
> in the system / for this VMA, and in that case just fallback before
> doing more expensive checks.

Correction: only a call to thp_vma_allowable_orders(). I wonder if we 
can move some of thp_vma_allowable_orders() into the header file where 
we'd just check as fast and as efficiently for "no THP < PMD_THP 
enabled" on this system.

-- 
Cheers,

David / dhildenb



From conor at kernel.org  Tue Dec  5 08:41:35 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 5 Dec 2023 16:41:35 +0000
Subject: [PATCH 0/6] dt-bindings: samsung: continued - add specific
 compatibles for Tesla FSD Hi,
In-Reply-To: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231205-outnumber-yelp-dafb6ace186e@spud>

On Tue, Dec 05, 2023 at 10:22:23AM +0100, Krzysztof Kozlowski wrote:
> Merging
> =======
> I propose to take entire patchset through my tree (Samsung SoC), because:
> 1. I already took similar work this cycle:
>    https://lore.kernel.org/all/169997520487.6747.17671551558724027958.b4-ty at linaro.org/
> 2. Two new SoCs are coming (Google GS101 and ExynosAutov920) and they might
>    touch the same lines.  It is reasonable for me to take the bindings for the new
>    SoCs, to have clean `make dtbs_check` on the new DTS.
> 3. Having it together helps me to have clean `make dtbs_check` within my tree
>    on the existing DTS.
> 4. No drivers are affected by this change.
> 
> If folks agree, please kindly Ack the patches.

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/e49f4287/attachment.sig>

From jgg at nvidia.com  Tue Dec  5 08:43:18 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 12:43:18 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZW9OSe8Z9gAmM7My@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
Message-ID: <20231205164318.GG2692119@nvidia.com>

On Tue, Dec 05, 2023 at 04:22:33PM +0000, Catalin Marinas wrote:
> Yeah, I made this argument in the past. But it's a fair question to ask
> since the Arm world is different from x86. Just reusing an existing
> driver in a different context may break its expectations. Does Normal NC
> access complete by the time a TLBI (for Stage 2) and DSB (DVMsync) is
> completed? It does reach some point of serialisation with subsequent
> accesses to the same address but not sure how it is ordered with an
> access to a different location like the config space used for reset.
> Maybe it's not a problem at all or it is safe only for PCIe but it would
> be good to get to the bottom of this.

IMHO, the answer is you can't know architecturally. The specific
vfio-platform driver must do an analysis of it's specific SOC and
determine what exactly is required to order the reset. The primary
purpose of the vfio-platform drivers is to provide this reset!

In most cases I would expect some reads from the device to be required
before the reset.

> > Remember, the feedback we got from the CPU architects was that even
> > DEVICE_* will experience an uncontained failure if the device tiggers
> > an error response in shipping ARM IP.
> > 
> > The reason PCIe is safe is because the PCI bridge does not generate
> > errors in the first place!
> 
> That's an argument to restrict this feature to PCIe. It's really about
> fewer arguments on the behaviour of other devices. Marc did raise
> another issue with the GIC VCPU interface (does this even have a vma in
> the host VMM?). That's a class of devices where the mapping is
> context-switched, so the TLBI+DSB rules don't help.

I don't know anything about the GIC VCPU interface, to give any
comment unfortunately. Since it seems there is something to fix here I
would appreciate some background..
 
When you say it is context switched do you mean kvm does a register
write on every vm entry to set the proper HW context for the vCPU?

We are worrying that register write will possibly not order after
NORMAL_NC?

> > Thus, the way a platform device can actually be safe is if it too
> > never generates errors in the first place! Obviously this approach
> > works just as well with NORMAL_NC.
> > 
> > If a platform device does generate errors then we shouldn't expect
> > containment at all, and the memory type has no bearing on the
> > safety. The correct answer is to block these platform devices from
> > VFIO/KVM/etc because they can trigger uncontained failures.
> 
> Assuming the error containment is sorted, there are two other issues
> with other types of devices:
> 
> 1. Ordering guarantees on reclaim or context switch

Solved in VFIO
 
> 2. Unaligned accesses
> 
> On (2), I think PCIe is fairly clear on how the TLPs are generated, so I
> wouldn't expect additional errors here. But I have no idea what AMBA/AXI
> does here in general. Perhaps it's fine, I don't think we looked into it
> as the focus was mostly on PCIe.

I would expect AXI devices to throw errors in all sorts of odd
cases. eg I would not be surprised at all to see carelessly built AXI
devices error if ST64B is pointed at them. At least when I was
building AXI logic years ago I was so lazy :P

This is mostly my point - if the devices under vfio-platform were not
designed to have contained errors then, IMHO, it is hard to believe
that DEVICE_X/NORMAL_NC is the only issue in that HW.

> So, I think it would be easier to get this patch upstream if we limit
> the change to PCIe devices for now. We may relax this further in the
> future. Do you actually have a need for non-PCIe devices to support WC
> in the guest or it's more about the complexity of the logic to detect
> whether it's actually a PCIe BAR we are mapping into the guest? (I can
> see some Arm GPU folk asking for this but those devices are not easily
> virtualisable).

The complexity is my concern, and the disruption to the ecosystem with
some of the ideas given.

If there was a trivial way to convey in the VMA that it is safe then
sure, no objection from me.

My worry is this has turned from fixing a real problem we have today
into a debate about theoretical issues that nobody may care about that
are very disruptive to solve.

I would turn it around and ask we find a way to restrict platform
devices when someone comes with a platform device that wants to use
secure kvm and has a single well defined HW problem that is solved by
this work.

What if we change vfio-pci to use pgprot_device() like it already
really should and say the pgprot_noncached() is enforced as
DEVICE_nGnRnE and pgprot_device() may be DEVICE_nGnRE or NORMAL_NC?
Would that be acceptable?

Jason


From heiko at sntech.de  Tue Dec  5 08:48:38 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 17:48:38 +0100
Subject: [PATCH v2 0/4] arm64: dts: rockchip: aliases for core busses in main dtsi
Message-ID: <20231205164842.556684-1-heiko@sntech.de>

Placement of aliases is cause for a lot of discussion :-).
Most recently in [0]. And while devices such as mmc controllers do have
names not following any numbers, this is different for the core
busses/devices like serial, i2c, gpio, spi.

All of those start at number 0 and increment then. And all pieces of
documentation like soc manuals, device schematics as well as pin-header
descriptions for SBCs also use these numbers to identify the controller
instance.

All previous Rockchip socs also carry those core busses in the main dtsi
so that not every board needs to have the exact same aliases defined.

changes in v2:
- reword commit messages to make move vs define explicti (Diederik)
- add review from Dragan

[0] https://lore.kernel.org/all/4762834.KRxA6XjA2N at diego/

Heiko Stuebner (4):
  arm64: dts: rockchip: move rk3588 serial aliases to soc dtsi
  arm64: dts: rockchip: add rk3588 i2c aliases to soc dtsi
  arm64: dts: rockchip: add rk3588 gpio aliases to soc dtsi
  arm64: dts: rockchip: add rk3588 spi aliases to soc dtsi

 .../dts/rockchip/rk3588-edgeble-neu6a-io.dts  |  4 ---
 .../dts/rockchip/rk3588-edgeble-neu6b-io.dts  |  4 ---
 .../boot/dts/rockchip/rk3588-evb1-v10.dts     |  1 -
 .../boot/dts/rockchip/rk3588-nanopc-t6.dts    |  1 -
 .../dts/rockchip/rk3588-orangepi-5-plus.dts   |  1 -
 .../boot/dts/rockchip/rk3588-quartzpro64.dts  |  1 -
 .../boot/dts/rockchip/rk3588-rock-5b.dts      |  1 -
 .../boot/dts/rockchip/rk3588-turing-rk1.dtsi  |  2 --
 .../dts/rockchip/rk3588s-indiedroid-nova.dts  |  1 -
 .../dts/rockchip/rk3588s-khadas-edge2.dts     |  1 -
 .../boot/dts/rockchip/rk3588s-orangepi-5.dts  |  1 -
 .../boot/dts/rockchip/rk3588s-rock-5a.dts     |  1 -
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 32 +++++++++++++++++++
 13 files changed, 32 insertions(+), 19 deletions(-)

-- 
2.39.2



From heiko at sntech.de  Tue Dec  5 08:48:42 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 17:48:42 +0100
Subject: [PATCH v2 4/4] arm64: dts: rockchip: add rk3588 spi aliases to soc dtsi
In-Reply-To: <20231205164842.556684-1-heiko@sntech.de>
References: <20231205164842.556684-1-heiko@sntech.de>
Message-ID: <20231205164842.556684-5-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

The spi controllers on rk3588 are named spi0 - spi4. Board schematics
also use these exact numbers and we want those names to also reflect
in the OS devices because everything else would just cause confusion.
Userspace spi access is a thing afterall.

To prevent each board repeating their list of spi aliases, define them
in the soc dtsi, as previous Rockchip soc like the rk356x do already.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
Reviewed-by: Dragan Simic <dsimic at manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index a59407466746..7863aded672b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -43,6 +43,11 @@ aliases {
 		serial7 = &uart7;
 		serial8 = &uart8;
 		serial9 = &uart9;
+		spi0 = &spi0;
+		spi1 = &spi1;
+		spi2 = &spi2;
+		spi3 = &spi3;
+		spi4 = &spi4;
 	};
 
 	cpus {
-- 
2.39.2



From heiko at sntech.de  Tue Dec  5 08:48:40 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 17:48:40 +0100
Subject: [PATCH v2 2/4] arm64: dts: rockchip: add rk3588 i2c aliases to soc dtsi
In-Reply-To: <20231205164842.556684-1-heiko@sntech.de>
References: <20231205164842.556684-1-heiko@sntech.de>
Message-ID: <20231205164842.556684-3-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

The i2c controllers on rk3588 are named i2c0 - i2c8. Board schematics
also use these exact numbers and we want those names to also reflect
in the OS devices because everything else would just cause confusion.
Userspace i2c access is a thing afterall.

To prevent each board repeating their list of i2c aliases, define them
in the soc dtsi, as all previous Rockchip soc do already.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
Reviewed-by: Dragan Simic <dsimic at manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index d854536a44b8..47512c39e55a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -19,6 +19,15 @@ / {
 	#size-cells = <2>;
 
 	aliases {
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+		i2c7 = &i2c7;
+		i2c8 = &i2c8;
 		serial0 = &uart0;
 		serial1 = &uart1;
 		serial2 = &uart2;
-- 
2.39.2



From heiko at sntech.de  Tue Dec  5 08:48:41 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 17:48:41 +0100
Subject: [PATCH v2 3/4] arm64: dts: rockchip: add rk3588 gpio aliases to soc dtsi
In-Reply-To: <20231205164842.556684-1-heiko@sntech.de>
References: <20231205164842.556684-1-heiko@sntech.de>
Message-ID: <20231205164842.556684-4-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

The gpio controllers on rk3588 are named gpio0 - gpio4. Board schematics
also use these exact numbers and we want those names to also reflect
in the OS devices because everything else would just cause confusion.
Userspace gpio access is a thing afterall.

To prevent each board repeating their list of gpio aliases, define them
in the soc dtsi, as previous Rockchip soc like the rk356x do already.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
Reviewed-by: Dragan Simic <dsimic at manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 47512c39e55a..a59407466746 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -19,6 +19,11 @@ / {
 	#size-cells = <2>;
 
 	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
-- 
2.39.2



From heiko at sntech.de  Tue Dec  5 08:48:39 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue,  5 Dec 2023 17:48:39 +0100
Subject: [PATCH v2 1/4] arm64: dts: rockchip: move rk3588 serial aliases to soc dtsi
In-Reply-To: <20231205164842.556684-1-heiko@sntech.de>
References: <20231205164842.556684-1-heiko@sntech.de>
Message-ID: <20231205164842.556684-2-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

The serial ports on rk3588 are named uart0 - uart9. Board schematics
also use these exact numbers and we want those names to also reflect
in the OS devices because everything else would just cause confusion.

To prevent each board repeating their list of serial aliases, move them
to the soc dtsi, as all previous Rockchip soc do already.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
Reviewed-by: Dragan Simic <dsimic at manjaro.org>
---
 .../boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts   |  4 ----
 .../boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts   |  4 ----
 arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts    |  1 -
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts   |  1 -
 .../boot/dts/rockchip/rk3588-orangepi-5-plus.dts    |  1 -
 arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts |  1 -
 arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts     |  1 -
 arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |  2 --
 .../boot/dts/rockchip/rk3588s-indiedroid-nova.dts   |  1 -
 .../boot/dts/rockchip/rk3588s-khadas-edge2.dts      |  1 -
 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts |  1 -
 arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts    |  1 -
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi           | 13 +++++++++++++
 13 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts b/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts
index b51543892078..be6a4f4f90f6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts
@@ -12,10 +12,6 @@ / {
 	compatible = "edgeble,neural-compute-module-6a-io",
 		     "edgeble,neural-compute-module-6a", "rockchip,rk3588";
 
-	aliases {
-		serial2 = &uart2;
-	};
-
 	chosen {
 		stdout-path = "serial2:1500000n8";
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts b/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts
index 9933765e4097..96a18077f26f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts
@@ -12,10 +12,6 @@ / {
 	compatible = "edgeble,neural-compute-module-6b-io",
 		     "edgeble,neural-compute-module-6b", "rockchip,rk3588";
 
-	aliases {
-		serial2 = &uart2;
-	};
-
 	chosen {
 		stdout-path = "serial2:1500000n8";
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
index b9d789d57862..a36d4fcd9b1d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
@@ -17,7 +17,6 @@ / {
 
 	aliases {
 		mmc0 = &sdhci;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
index 97af4f912828..612107615e66 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
@@ -19,7 +19,6 @@ / {
 	aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
index 298c183d6f4f..3e660ff6cd5f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
@@ -19,7 +19,6 @@ / {
 	aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
index 5c59f9571dce..c7cd57609bc2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
@@ -19,7 +19,6 @@ / {
 	aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
index 741f631db345..e302eeb6ce5a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
@@ -14,7 +14,6 @@ aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 		mmc2 = &sdio;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
index 9570b34aca2e..25a0ca73a8f7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
@@ -19,8 +19,6 @@ / {
 	aliases {
 		ethernet0 = &gmac1;
 		mmc0 = &sdhci;
-		serial2 = &uart2;
-		serial9 = &uart9;
 	};
 
 	fan: pwm-fan {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts b/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts
index 60f00ceb630e..dc677f29a9c7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts
@@ -44,7 +44,6 @@ aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 		mmc2 = &sdio;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
index 82478a452533..f53e993c785e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
@@ -12,7 +12,6 @@ / {
 
 	aliases {
 		mmc0 = &sdhci;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 8f399c4317bd..52ec9cb38f57 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -14,7 +14,6 @@ / {
 
 	aliases {
 		mmc0 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
index 8347adcbd003..73cf97062a09 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
@@ -14,7 +14,6 @@ / {
 	aliases {
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
-		serial2 = &uart2;
 	};
 
 	analog-sound {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 8aa0499f9b03..d854536a44b8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -18,6 +18,19 @@ / {
 	#address-cells = <2>;
 	#size-cells = <2>;
 
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+		serial6 = &uart6;
+		serial7 = &uart7;
+		serial8 = &uart8;
+		serial9 = &uart9;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
2.39.2



From broonie at kernel.org  Tue Dec  5 08:47:58 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:47:58 +0000
Subject: [PATCH v3 00/21] arm64: Support for 2023 DPISA extensions
Message-ID: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>

This series enables support for the data processing extensions in the
newly released 2023 architecture, this is mainly support for 8 bit
floating point formats.  Most of the extensions only introduce new
instructions and therefore only require hwcaps but there is a new EL0
visible control register FPMR used to control the 8 bit floating point
formats, we need to manage traps for this and context switch it.

The sharing of floating point save code between the host and guest
kernels slightly complicates the introduction of KVM support, we first
introduce host support with some placeholders for KVM then replace those
with the actual KVM support.

I've not added test coverage for ptrace, I've got a not quite finished
test program which exercises all the FP ptrace interfaces and their
interactions together, my plan is to cover it there rather than add
another tiny test program that duplicates the boilerplace for tracing a
target and doesn't actually run the traced program.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
Changes in v3:
- Rebase onto v6.7-rc3.
- Hook up traps for FPMR in emulate-nested.c.
- Link to v2: https://lore.kernel.org/r/20231114-arm64-2023-dpisa-v2-0-47251894f6a8 at kernel.org

Changes in v2:
- Rebase onto v6.7-rc1.
- Link to v1: https://lore.kernel.org/r/20231026-arm64-2023-dpisa-v1-0-8470dd989bb2 at kernel.org

---
Mark Brown (21):
      arm64/sysreg: Add definition for ID_AA64PFR2_EL1
      arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion for DDI0601 2023-09
      arm64/sysreg: Add definition for ID_AA64ISAR3_EL1
      arm64/sysreg: Add definition for ID_AA64FPFR0_EL1
      arm64/sysreg: Update ID_AA64SMFR0_EL1 definition for DDI0601 2023-09
      arm64/sysreg: Update SCTLR_EL1 for DDI0601 2023-09
      arm64/sysreg: Update HCRX_EL2 definition for DDI0601 2023-09
      arm64/sysreg: Add definition for FPMR
      arm64/cpufeature: Hook new identification registers up to cpufeature
      arm64/fpsimd: Enable host kernel access to FPMR
      arm64/fpsimd: Support FEAT_FPMR
      arm64/signal: Add FPMR signal handling
      arm64/ptrace: Expose FPMR via ptrace
      KVM: arm64: Add newly allocated ID registers to register descriptions
      KVM: arm64: Support FEAT_FPMR for guests
      arm64/hwcap: Define hwcaps for 2023 DPISA features
      kselftest/arm64: Handle FPMR context in generic signal frame parser
      kselftest/arm64: Add basic FPMR test
      kselftest/arm64: Add 2023 DPISA hwcap test coverage
      KVM: arm64: selftests: Document feature registers added in 2023 extensions
      KVM: arm64: selftests: Teach get-reg-list about FPMR

 Documentation/arch/arm64/elf_hwcaps.rst            |  49 +++++
 arch/arm64/include/asm/cpu.h                       |   3 +
 arch/arm64/include/asm/cpufeature.h                |   5 +
 arch/arm64/include/asm/fpsimd.h                    |   2 +
 arch/arm64/include/asm/hwcap.h                     |  15 ++
 arch/arm64/include/asm/kvm_arm.h                   |   4 +-
 arch/arm64/include/asm/kvm_host.h                  |   3 +
 arch/arm64/include/asm/processor.h                 |   2 +
 arch/arm64/include/uapi/asm/hwcap.h                |  15 ++
 arch/arm64/include/uapi/asm/sigcontext.h           |   8 +
 arch/arm64/kernel/cpufeature.c                     |  72 +++++++
 arch/arm64/kernel/cpuinfo.c                        |  18 ++
 arch/arm64/kernel/fpsimd.c                         |  13 ++
 arch/arm64/kernel/ptrace.c                         |  42 ++++
 arch/arm64/kernel/signal.c                         |  59 ++++++
 arch/arm64/kvm/emulate-nested.c                    |   9 +
 arch/arm64/kvm/fpsimd.c                            |  19 +-
 arch/arm64/kvm/hyp/include/hyp/switch.h            |   7 +-
 arch/arm64/kvm/sys_regs.c                          |  17 +-
 arch/arm64/tools/cpucaps                           |   1 +
 arch/arm64/tools/sysreg                            | 153 ++++++++++++++-
 include/uapi/linux/elf.h                           |   1 +
 tools/testing/selftests/arm64/abi/hwcap.c          | 217 +++++++++++++++++++++
 tools/testing/selftests/arm64/signal/.gitignore    |   1 +
 .../arm64/signal/testcases/fpmr_siginfo.c          |  82 ++++++++
 .../selftests/arm64/signal/testcases/testcases.c   |   8 +
 .../selftests/arm64/signal/testcases/testcases.h   |   1 +
 tools/testing/selftests/kvm/aarch64/get-reg-list.c |  11 +-
 28 files changed, 819 insertions(+), 18 deletions(-)
---
base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab
change-id: 20231003-arm64-2023-dpisa-2f3d25746474

Best regards,
-- 
Mark Brown <broonie at kernel.org>



From broonie at kernel.org  Tue Dec  5 08:47:59 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:47:59 +0000
Subject: [PATCH v3 01/21] arm64/sysreg: Add definition for ID_AA64PFR2_EL1
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-1-dbcbcd867a7f@kernel.org>

DDI0601 2023-09 defines a new system register ID_AA64PFR2_EL1 which
enumerates FPMR and some new MTE features. Add a definition of this
register.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 96cbeeab4eec..f22ade8f1fa7 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1002,6 +1002,27 @@ UnsignedEnum	3:0	BT
 EndEnum
 EndSysreg
 
+Sysreg	ID_AA64PFR2_EL1	3	0	0	4	2
+Res0	63:36
+UnsignedEnum	35:32	FPMR
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Res0	31:12
+UnsignedEnum	11:8	MTEFAR
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	7:4	MTESTOREONLY
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	3:0	MTEPERM
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+EndSysreg
+
 Sysreg	ID_AA64ZFR0_EL1	3	0	0	4	4
 Res0	63:60
 UnsignedEnum	59:56	F64MM

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:00 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:00 +0000
Subject: [PATCH v3 02/21] arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion
 for DDI0601 2023-09
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-2-dbcbcd867a7f@kernel.org>

DDI0601 2023-09 defines some new fields in previously RES0 space in
ID_AA64ISAR2_EL1, together with one new enum value. Update the system
register definition to reflect this.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index f22ade8f1fa7..27d79644e1a0 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1365,7 +1365,14 @@ EndEnum
 EndSysreg
 
 Sysreg	ID_AA64ISAR2_EL1	3	0	0	6	2
-Res0	63:56
+UnsignedEnum	63:60	ATS1A
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	59:56	LUT
+	0b0000	NI
+	0b0001	IMP
+EndEnum
 UnsignedEnum	55:52	CSSC
 	0b0000	NI
 	0b0001	IMP
@@ -1374,7 +1381,19 @@ UnsignedEnum	51:48	RPRFM
 	0b0000	NI
 	0b0001	IMP
 EndEnum
-Res0	47:32
+Res0	47:44
+UnsignedEnum	43:40	PRFMSLC
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	39:36	SYSINSTR_128
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	35:32	SYSREG_128
+	0b0000	NI
+	0b0001	IMP
+EndEnum
 UnsignedEnum	31:28	CLRBHB
 	0b0000	NI
 	0b0001	IMP
@@ -1398,6 +1417,7 @@ UnsignedEnum	15:12	APA3
 	0b0011	PAuth2
 	0b0100	FPAC
 	0b0101	FPACCOMBINE
+	0b0110	PAUTH_LR
 EndEnum
 UnsignedEnum	11:8	GPA3
 	0b0000	NI

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:01 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:01 +0000
Subject: [PATCH v3 03/21] arm64/sysreg: Add definition for ID_AA64ISAR3_EL1
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-3-dbcbcd867a7f@kernel.org>

DDI0601 2023-09 adds a new system register ID_AA64ISAR3_EL1 enumerating
new floating point and TLB invalidation features. Add a defintion for it.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 27d79644e1a0..3d623a04934c 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1433,6 +1433,23 @@ UnsignedEnum	3:0	WFxT
 EndEnum
 EndSysreg
 
+Sysreg	ID_AA64ISAR3_EL1	3	0	0	6	3
+Res0	63:12
+UnsignedEnum	11:8	TLBIW
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	7:4	FAMINMAX
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	3:0	CPA
+	0b0000	NI
+	0b0001	IMP
+	0b0010	CPA2
+EndEnum
+EndSysreg
+
 Sysreg	ID_AA64MMFR0_EL1	3	0	0	7	0
 UnsignedEnum	63:60	ECV
 	0b0000	NI

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:02 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:02 +0000
Subject: [PATCH v3 04/21] arm64/sysreg: Add definition for ID_AA64FPFR0_EL1
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-4-dbcbcd867a7f@kernel.org>

DDI0601 2023-09 defines a new feature register ID_AA64FPFR0_EL1 which
enumerates a number of FP8 related features. Add a definition for it.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 3d623a04934c..c9bb49d0ea03 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1131,6 +1131,35 @@ EndEnum
 Res0	31:0
 EndSysreg
 
+Sysreg	ID_AA64FPFR0_EL1	3	0	0	4	7
+Res0	63:32
+UnsignedEnum	31	F8CVT
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	30	F8FMA
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	29	F8DP4
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	28	F8DP2
+	0b0	NI
+	0b1	IMP
+EndEnum
+Res0	27:2
+UnsignedEnum	1	F8E4M3
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	0	F8E5M2
+	0b0	NI
+	0b1	IMP
+EndEnum
+EndSysreg
+
 Sysreg	ID_AA64DFR0_EL1	3	0	0	5	0
 Enum	63:60	HPMN0
 	0b0000	UNPREDICTABLE

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:03 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:03 +0000
Subject: [PATCH v3 05/21] arm64/sysreg: Update ID_AA64SMFR0_EL1 definition
 for DDI0601 2023-09
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-5-dbcbcd867a7f@kernel.org>

The 2023-09 release of DDI0601 defines a number of new feature enumeration
fields in ID_AA64SMFR0_EL1. Add these fields.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index c9bb49d0ea03..aee9ab4087c1 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1079,7 +1079,11 @@ UnsignedEnum	63	FA64
 	0b0	NI
 	0b1	IMP
 EndEnum
-Res0	62:60
+Res0	62:61
+UnsignedEnum	60	LUTv2
+	0b0	NI
+	0b1	IMP
+EndEnum
 UnsignedEnum	59:56	SMEver
 	0b0000	SME
 	0b0001	SME2
@@ -1107,7 +1111,14 @@ UnsignedEnum	42	F16F16
 	0b0	NI
 	0b1	IMP
 EndEnum
-Res0	41:40
+UnsignedEnum	41	F8F16
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	40	F8F32
+	0b0	NI
+	0b1	IMP
+EndEnum
 UnsignedEnum	39:36	I8I32
 	0b0000	NI
 	0b1111	IMP
@@ -1128,7 +1139,20 @@ UnsignedEnum	32	F32F32
 	0b0	NI
 	0b1	IMP
 EndEnum
-Res0	31:0
+Res0	31
+UnsignedEnum	30	SF8FMA
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	29	SF8DP4
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	28	SF8DP2
+	0b0	NI
+	0b1	IMP
+EndEnum
+Res0	27:0
 EndSysreg
 
 Sysreg	ID_AA64FPFR0_EL1	3	0	0	4	7

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:04 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:04 +0000
Subject: [PATCH v3 06/21] arm64/sysreg: Update SCTLR_EL1 for DDI0601
 2023-09
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-6-dbcbcd867a7f@kernel.org>

DDI0601 2023-09 defines some new fields in SCTLR_EL1 controlling new MTE
and floating point features. Update our sysreg definition to reflect these.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index aee9ab4087c1..eea69bb48fa7 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1791,7 +1791,8 @@ Field	63	TIDCP
 Field	62	SPINTMASK
 Field	61	NMI
 Field	60	EnTP2
-Res0	59:58
+Field	59	TCSO
+Field	58	TCSO0
 Field	57	EPAN
 Field	56	EnALS
 Field	55	EnAS0
@@ -1820,7 +1821,7 @@ EndEnum
 Field	37	ITFSB
 Field	36	BT1
 Field	35	BT0
-Res0	34
+Field	34	EnFPM
 Field	33	MSCEn
 Field	32	CMOW
 Field	31	EnIA

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:05 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:05 +0000
Subject: [PATCH v3 07/21] arm64/sysreg: Update HCRX_EL2 definition for
 DDI0601 2023-09
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-7-dbcbcd867a7f@kernel.org>

DDI0601 2023-09 defines new fields in HCRX_EL2 controlling access to new
system registers, update our definition of HCRX_EL2 to reflect this.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index eea69bb48fa7..0b1a33a77074 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2412,7 +2412,9 @@ Fields	ZCR_ELx
 EndSysreg
 
 Sysreg	HCRX_EL2	3	4	1	2	2
-Res0	63:23
+Res0	63:25
+Field	24	PACMEn
+Field	23	EnFPM
 Field	22	GCSEn
 Field	21	EnIDCP128
 Field	20	EnSDERR

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:06 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:06 +0000
Subject: [PATCH v3 08/21] arm64/sysreg: Add definition for FPMR
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-8-dbcbcd867a7f@kernel.org>

DDI0601 2023-09 defines a new sysrem register FPMR (Floating Point Mode
Register) which configures the new FP8 features. Add a definition of this
register.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 0b1a33a77074..67173576115a 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2138,6 +2138,29 @@ Field	1	ZA
 Field	0	SM
 EndSysreg
 
+Sysreg	FPMR	3	3	4	4	2
+Res0	63:38
+Field	37:32	LSCALE2
+Field	31:24	NSCALE
+Res0	23
+Field	22:16	LSCALE
+Field	15	OSC
+Field	14	OSM
+Res0	13:9
+UnsignedEnum	8:6	F8D
+	0b000	E5M2
+	0b001	E4M3
+EndEnum
+UnsignedEnum	5:3	F8S2
+	0b000	E5M2
+	0b001	E4M3
+EndEnum
+UnsignedEnum	2:0	F8S1
+	0b000	E5M2
+	0b001	E4M3
+EndEnum
+EndSysreg
+
 SysregFields	HFGxTR_EL2
 Field	63	nAMAIR2_EL1
 Field	62	nMAIR2_EL1

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:07 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:07 +0000
Subject: [PATCH v3 09/21] arm64/cpufeature: Hook new identification
 registers up to cpufeature
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-9-dbcbcd867a7f@kernel.org>

The 2023 architecture extensions have defined several new ID registers,
hook them up to the cpufeature code so we can add feature checks and hwcaps
based on their contents.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/cpu.h   |  3 +++
 arch/arm64/kernel/cpufeature.c | 28 ++++++++++++++++++++++++++++
 arch/arm64/kernel/cpuinfo.c    |  3 +++
 3 files changed, 34 insertions(+)

diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
index f3034099fd95..b99138bc3d4a 100644
--- a/arch/arm64/include/asm/cpu.h
+++ b/arch/arm64/include/asm/cpu.h
@@ -53,14 +53,17 @@ struct cpuinfo_arm64 {
 	u64		reg_id_aa64isar0;
 	u64		reg_id_aa64isar1;
 	u64		reg_id_aa64isar2;
+	u64		reg_id_aa64isar3;
 	u64		reg_id_aa64mmfr0;
 	u64		reg_id_aa64mmfr1;
 	u64		reg_id_aa64mmfr2;
 	u64		reg_id_aa64mmfr3;
 	u64		reg_id_aa64pfr0;
 	u64		reg_id_aa64pfr1;
+	u64		reg_id_aa64pfr2;
 	u64		reg_id_aa64zfr0;
 	u64		reg_id_aa64smfr0;
+	u64		reg_id_aa64fpfr0;
 
 	struct cpuinfo_32bit	aarch32;
 };
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 646591c67e7a..c8d38e5ce997 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -234,6 +234,10 @@ static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
 	ARM64_FTR_END,
 };
 
+static const struct arm64_ftr_bits ftr_id_aa64isar3[] = {
+	ARM64_FTR_END,
+};
+
 static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_EL1_CSV3_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_EL1_CSV2_SHIFT, 4, 0),
@@ -267,6 +271,10 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr1[] = {
 	ARM64_FTR_END,
 };
 
+static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
+	ARM64_FTR_END,
+};
+
 static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SVE),
 		       FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ZFR0_EL1_F64MM_SHIFT, 4, 0),
@@ -319,6 +327,10 @@ static const struct arm64_ftr_bits ftr_id_aa64smfr0[] = {
 	ARM64_FTR_END,
 };
 
+static const struct arm64_ftr_bits ftr_id_aa64fpfr0[] = {
+	ARM64_FTR_END,
+};
+
 static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_EL1_ECV_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_EL1_FGT_SHIFT, 4, 0),
@@ -702,10 +714,12 @@ static const struct __ftr_reg_entry {
 			       &id_aa64pfr0_override),
 	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64PFR1_EL1, ftr_id_aa64pfr1,
 			       &id_aa64pfr1_override),
+	ARM64_FTR_REG(SYS_ID_AA64PFR2_EL1, ftr_id_aa64pfr2),
 	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ZFR0_EL1, ftr_id_aa64zfr0,
 			       &id_aa64zfr0_override),
 	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64SMFR0_EL1, ftr_id_aa64smfr0,
 			       &id_aa64smfr0_override),
+	ARM64_FTR_REG(SYS_ID_AA64FPFR0_EL1, ftr_id_aa64fpfr0),
 
 	/* Op1 = 0, CRn = 0, CRm = 5 */
 	ARM64_FTR_REG(SYS_ID_AA64DFR0_EL1, ftr_id_aa64dfr0),
@@ -717,6 +731,7 @@ static const struct __ftr_reg_entry {
 			       &id_aa64isar1_override),
 	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ISAR2_EL1, ftr_id_aa64isar2,
 			       &id_aa64isar2_override),
+	ARM64_FTR_REG(SYS_ID_AA64ISAR3_EL1, ftr_id_aa64isar3),
 
 	/* Op1 = 0, CRn = 0, CRm = 7 */
 	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
@@ -1043,14 +1058,17 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
 	init_cpu_ftr_reg(SYS_ID_AA64ISAR0_EL1, info->reg_id_aa64isar0);
 	init_cpu_ftr_reg(SYS_ID_AA64ISAR1_EL1, info->reg_id_aa64isar1);
 	init_cpu_ftr_reg(SYS_ID_AA64ISAR2_EL1, info->reg_id_aa64isar2);
+	init_cpu_ftr_reg(SYS_ID_AA64ISAR3_EL1, info->reg_id_aa64isar3);
 	init_cpu_ftr_reg(SYS_ID_AA64MMFR0_EL1, info->reg_id_aa64mmfr0);
 	init_cpu_ftr_reg(SYS_ID_AA64MMFR1_EL1, info->reg_id_aa64mmfr1);
 	init_cpu_ftr_reg(SYS_ID_AA64MMFR2_EL1, info->reg_id_aa64mmfr2);
 	init_cpu_ftr_reg(SYS_ID_AA64MMFR3_EL1, info->reg_id_aa64mmfr3);
 	init_cpu_ftr_reg(SYS_ID_AA64PFR0_EL1, info->reg_id_aa64pfr0);
 	init_cpu_ftr_reg(SYS_ID_AA64PFR1_EL1, info->reg_id_aa64pfr1);
+	init_cpu_ftr_reg(SYS_ID_AA64PFR2_EL1, info->reg_id_aa64pfr2);
 	init_cpu_ftr_reg(SYS_ID_AA64ZFR0_EL1, info->reg_id_aa64zfr0);
 	init_cpu_ftr_reg(SYS_ID_AA64SMFR0_EL1, info->reg_id_aa64smfr0);
+	init_cpu_ftr_reg(SYS_ID_AA64FPFR0_EL1, info->reg_id_aa64fpfr0);
 
 	if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0))
 		init_32bit_cpu_features(&info->aarch32);
@@ -1291,6 +1309,8 @@ void update_cpu_features(int cpu,
 				      info->reg_id_aa64isar1, boot->reg_id_aa64isar1);
 	taint |= check_update_ftr_reg(SYS_ID_AA64ISAR2_EL1, cpu,
 				      info->reg_id_aa64isar2, boot->reg_id_aa64isar2);
+	taint |= check_update_ftr_reg(SYS_ID_AA64ISAR3_EL1, cpu,
+				      info->reg_id_aa64isar3, boot->reg_id_aa64isar3);
 
 	/*
 	 * Differing PARange support is fine as long as all peripherals and
@@ -1310,6 +1330,8 @@ void update_cpu_features(int cpu,
 				      info->reg_id_aa64pfr0, boot->reg_id_aa64pfr0);
 	taint |= check_update_ftr_reg(SYS_ID_AA64PFR1_EL1, cpu,
 				      info->reg_id_aa64pfr1, boot->reg_id_aa64pfr1);
+	taint |= check_update_ftr_reg(SYS_ID_AA64PFR2_EL1, cpu,
+				      info->reg_id_aa64pfr2, boot->reg_id_aa64pfr2);
 
 	taint |= check_update_ftr_reg(SYS_ID_AA64ZFR0_EL1, cpu,
 				      info->reg_id_aa64zfr0, boot->reg_id_aa64zfr0);
@@ -1317,6 +1339,9 @@ void update_cpu_features(int cpu,
 	taint |= check_update_ftr_reg(SYS_ID_AA64SMFR0_EL1, cpu,
 				      info->reg_id_aa64smfr0, boot->reg_id_aa64smfr0);
 
+	taint |= check_update_ftr_reg(SYS_ID_AA64FPFR0_EL1, cpu,
+				      info->reg_id_aa64fpfr0, boot->reg_id_aa64fpfr0);
+
 	/* Probe vector lengths */
 	if (IS_ENABLED(CONFIG_ARM64_SVE) &&
 	    id_aa64pfr0_sve(read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1))) {
@@ -1429,8 +1454,10 @@ u64 __read_sysreg_by_encoding(u32 sys_id)
 
 	read_sysreg_case(SYS_ID_AA64PFR0_EL1);
 	read_sysreg_case(SYS_ID_AA64PFR1_EL1);
+	read_sysreg_case(SYS_ID_AA64PFR2_EL1);
 	read_sysreg_case(SYS_ID_AA64ZFR0_EL1);
 	read_sysreg_case(SYS_ID_AA64SMFR0_EL1);
+	read_sysreg_case(SYS_ID_AA64FPFR0_EL1);
 	read_sysreg_case(SYS_ID_AA64DFR0_EL1);
 	read_sysreg_case(SYS_ID_AA64DFR1_EL1);
 	read_sysreg_case(SYS_ID_AA64MMFR0_EL1);
@@ -1440,6 +1467,7 @@ u64 __read_sysreg_by_encoding(u32 sys_id)
 	read_sysreg_case(SYS_ID_AA64ISAR0_EL1);
 	read_sysreg_case(SYS_ID_AA64ISAR1_EL1);
 	read_sysreg_case(SYS_ID_AA64ISAR2_EL1);
+	read_sysreg_case(SYS_ID_AA64ISAR3_EL1);
 
 	read_sysreg_case(SYS_CNTFRQ_EL0);
 	read_sysreg_case(SYS_CTR_EL0);
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index a257da7b56fe..8322e968fd0d 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -448,14 +448,17 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
 	info->reg_id_aa64isar0 = read_cpuid(ID_AA64ISAR0_EL1);
 	info->reg_id_aa64isar1 = read_cpuid(ID_AA64ISAR1_EL1);
 	info->reg_id_aa64isar2 = read_cpuid(ID_AA64ISAR2_EL1);
+	info->reg_id_aa64isar3 = read_cpuid(ID_AA64ISAR3_EL1);
 	info->reg_id_aa64mmfr0 = read_cpuid(ID_AA64MMFR0_EL1);
 	info->reg_id_aa64mmfr1 = read_cpuid(ID_AA64MMFR1_EL1);
 	info->reg_id_aa64mmfr2 = read_cpuid(ID_AA64MMFR2_EL1);
 	info->reg_id_aa64mmfr3 = read_cpuid(ID_AA64MMFR3_EL1);
 	info->reg_id_aa64pfr0 = read_cpuid(ID_AA64PFR0_EL1);
 	info->reg_id_aa64pfr1 = read_cpuid(ID_AA64PFR1_EL1);
+	info->reg_id_aa64pfr2 = read_cpuid(ID_AA64PFR2_EL1);
 	info->reg_id_aa64zfr0 = read_cpuid(ID_AA64ZFR0_EL1);
 	info->reg_id_aa64smfr0 = read_cpuid(ID_AA64SMFR0_EL1);
+	info->reg_id_aa64fpfr0 = read_cpuid(ID_AA64FPFR0_EL1);
 
 	if (id_aa64pfr1_mte(info->reg_id_aa64pfr1))
 		info->reg_gmid = read_cpuid(GMID_EL1);

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:08 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:08 +0000
Subject: [PATCH v3 10/21] arm64/fpsimd: Enable host kernel access to FPMR
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-10-dbcbcd867a7f@kernel.org>

FEAT_FPMR provides a new generally accessible architectural register FPMR.
This is only accessible to EL0 and EL1 when HCRX_EL2.EnFPM is set to 1,
do this when the host is running. The guest part will be done along with
context switching the new register and exposing it via guest management.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_arm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index b85f46a73e21..9f9239d86900 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -105,7 +105,7 @@
 #define HCRX_GUEST_FLAGS \
 	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | \
 	 (cpus_have_final_cap(ARM64_HAS_MOPS) ? (HCRX_EL2_MSCEn | HCRX_EL2_MCE2) : 0))
-#define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En)
+#define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM)
 
 /* TCR_EL2 Registers bits */
 #define TCR_EL2_RES1		((1U << 31) | (1 << 23))

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:09 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:09 +0000
Subject: [PATCH v3 11/21] arm64/fpsimd: Support FEAT_FPMR
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-11-dbcbcd867a7f@kernel.org>

FEAT_FPMR defines a new EL0 accessible register FPMR use to configure the
FP8 related features added to the architecture at the same time. Detect
support for this register and context switch it for EL0 when present.

Due to the sharing of responsibility for saving floating point state
between the host kernel and KVM FP8 support is not yet implemented in KVM
and a stub similar to that used for SVCR is provided for FPMR in order to
avoid bisection issues.  To make it easier to share host state with the
hypervisor we store FPMR immediately after the base floating point
state, existing usage means that it is not practical to extend that
directly.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/cpufeature.h |  5 +++++
 arch/arm64/include/asm/fpsimd.h     |  2 ++
 arch/arm64/include/asm/kvm_host.h   |  1 +
 arch/arm64/include/asm/processor.h  |  2 ++
 arch/arm64/kernel/cpufeature.c      |  9 +++++++++
 arch/arm64/kernel/fpsimd.c          | 13 +++++++++++++
 arch/arm64/kvm/fpsimd.c             |  1 +
 arch/arm64/tools/cpucaps            |  1 +
 8 files changed, 34 insertions(+)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index f6d416fe49b0..8e83cb1e6c7c 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -767,6 +767,11 @@ static __always_inline bool system_supports_tpidr2(void)
 	return system_supports_sme();
 }
 
+static __always_inline bool system_supports_fpmr(void)
+{
+	return alternative_has_cap_unlikely(ARM64_HAS_FPMR);
+}
+
 static __always_inline bool system_supports_cnp(void)
 {
 	return alternative_has_cap_unlikely(ARM64_HAS_CNP);
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index 50e5f25d3024..74afca3bd312 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -89,6 +89,7 @@ struct cpu_fp_state {
 	void *sve_state;
 	void *sme_state;
 	u64 *svcr;
+	u64 *fpmr;
 	unsigned int sve_vl;
 	unsigned int sme_vl;
 	enum fp_type *fp_type;
@@ -154,6 +155,7 @@ extern void cpu_enable_sve(const struct arm64_cpu_capabilities *__unused);
 extern void cpu_enable_sme(const struct arm64_cpu_capabilities *__unused);
 extern void cpu_enable_sme2(const struct arm64_cpu_capabilities *__unused);
 extern void cpu_enable_fa64(const struct arm64_cpu_capabilities *__unused);
+extern void cpu_enable_fpmr(const struct arm64_cpu_capabilities *__unused);
 
 extern u64 read_smcr_features(void);
 
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 824f29f04916..f8d98985a39c 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -517,6 +517,7 @@ struct kvm_vcpu_arch {
 	enum fp_type fp_type;
 	unsigned int sve_max_vl;
 	u64 svcr;
+	u64 fpmr;
 
 	/* Stage 2 paging state used by the hardware on next switch */
 	struct kvm_s2_mmu *hw_mmu;
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index e5bc54522e71..dd3a5b29f76e 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -158,6 +158,8 @@ struct thread_struct {
 		struct user_fpsimd_state fpsimd_state;
 	} uw;
 
+	u64			fpmr;		/* Adjacent to fpsimd_state for KVM */
+
 	enum fp_type		fp_type;	/* registers FPSIMD or SVE? */
 	unsigned int		fpsimd_cpu;
 	void			*sve_state;	/* SVE registers, if any */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c8d38e5ce997..ea0b680792de 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -272,6 +272,7 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr1[] = {
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_FPMR_SHIFT, 4, 0),
 	ARM64_FTR_END,
 };
 
@@ -2759,6 +2760,14 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.matches = has_cpuid_feature,
 		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP)
 	},
+	{
+		.desc = "FPMR",
+		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+		.capability = ARM64_HAS_FPMR,
+		.matches = has_cpuid_feature,
+		.cpu_enable = cpu_enable_fpmr,
+		ARM64_CPUID_FIELDS(ID_AA64PFR2_EL1, FPMR, IMP)
+	},
 	{},
 };
 
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 1559c706d32d..2a6abd6423f7 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -385,6 +385,9 @@ static void task_fpsimd_load(void)
 	WARN_ON(!system_supports_fpsimd());
 	WARN_ON(!have_cpu_fpsimd_context());
 
+	if (system_supports_fpmr())
+		write_sysreg_s(current->thread.fpmr, SYS_FPMR);
+
 	if (system_supports_sve() || system_supports_sme()) {
 		switch (current->thread.fp_type) {
 		case FP_STATE_FPSIMD:
@@ -472,6 +475,9 @@ static void fpsimd_save(void)
 	if (test_thread_flag(TIF_FOREIGN_FPSTATE))
 		return;
 
+	if (system_supports_fpmr())
+		*(last->fpmr) = read_sysreg_s(SYS_FPMR);
+
 	/*
 	 * If a task is in a syscall the ABI allows us to only
 	 * preserve the state shared with FPSIMD so don't bother
@@ -714,6 +720,12 @@ static void sve_to_fpsimd(struct task_struct *task)
 	}
 }
 
+void cpu_enable_fpmr(const struct arm64_cpu_capabilities *__always_unused p)
+{
+	write_sysreg_s(read_sysreg_s(SYS_SCTLR_EL1) | SCTLR_EL1_EnFPM_MASK,
+		       SYS_SCTLR_EL1);
+}
+
 #ifdef CONFIG_ARM64_SVE
 /*
  * Call __sve_free() directly only if you know task can't be scheduled
@@ -1671,6 +1683,7 @@ static void fpsimd_bind_task_to_cpu(void)
 	last->sve_vl = task_get_sve_vl(current);
 	last->sme_vl = task_get_sme_vl(current);
 	last->svcr = &current->thread.svcr;
+	last->fpmr = &current->thread.fpmr;
 	last->fp_type = &current->thread.fp_type;
 	last->to_save = FP_STATE_CURRENT;
 	current->thread.fpsimd_cpu = smp_processor_id();
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 8c1d0d4853df..e3e611e30e91 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -153,6 +153,7 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
 		fp_state.sve_vl = vcpu->arch.sve_max_vl;
 		fp_state.sme_state = NULL;
 		fp_state.svcr = &vcpu->arch.svcr;
+		fp_state.fpmr = &vcpu->arch.fpmr;
 		fp_state.fp_type = &vcpu->arch.fp_type;
 
 		if (vcpu_has_sve(vcpu))
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index b98c38288a9d..7a249a950bbc 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -26,6 +26,7 @@ HAS_ECV
 HAS_ECV_CNTPOFF
 HAS_EPAN
 HAS_EVT
+HAS_FPMR
 HAS_FGT
 HAS_FPSIMD
 HAS_GENERIC_AUTH

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:10 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:10 +0000
Subject: [PATCH v3 12/21] arm64/signal: Add FPMR signal handling
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-12-dbcbcd867a7f@kernel.org>

Expose FPMR in the signal context on systems where it is supported. The
kernel validates the exact size of the FPSIMD registers so we can't readily
add it to fpsimd_context without disruption.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/uapi/asm/sigcontext.h |  8 +++++
 arch/arm64/kernel/signal.c               | 59 ++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+)

diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
index f23c1dc3f002..8a45b7a411e0 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -152,6 +152,14 @@ struct tpidr2_context {
 	__u64 tpidr2;
 };
 
+/* FPMR context */
+#define FPMR_MAGIC	0x46504d52
+
+struct fpmr_context {
+	struct _aarch64_ctx head;
+	__u64 fpmr;
+};
+
 #define ZA_MAGIC	0x54366345
 
 struct za_context {
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 0e8beb3349ea..e8c808afcc8a 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -60,6 +60,7 @@ struct rt_sigframe_user_layout {
 	unsigned long tpidr2_offset;
 	unsigned long za_offset;
 	unsigned long zt_offset;
+	unsigned long fpmr_offset;
 	unsigned long extra_offset;
 	unsigned long end_offset;
 };
@@ -182,6 +183,8 @@ struct user_ctxs {
 	u32 za_size;
 	struct zt_context __user *zt;
 	u32 zt_size;
+	struct fpmr_context __user *fpmr;
+	u32 fpmr_size;
 };
 
 static int preserve_fpsimd_context(struct fpsimd_context __user *ctx)
@@ -227,6 +230,33 @@ static int restore_fpsimd_context(struct user_ctxs *user)
 	return err ? -EFAULT : 0;
 }
 
+static int preserve_fpmr_context(struct fpmr_context __user *ctx)
+{
+	int err = 0;
+
+	current->thread.fpmr = read_sysreg_s(SYS_FPMR);
+
+	__put_user_error(FPMR_MAGIC, &ctx->head.magic, err);
+	__put_user_error(sizeof(*ctx), &ctx->head.size, err);
+	__put_user_error(current->thread.fpmr, &ctx->fpmr, err);
+
+	return err;
+}
+
+static int restore_fpmr_context(struct user_ctxs *user)
+{
+	u64 fpmr;
+	int err = 0;
+
+	if (user->fpmr_size != sizeof(*user->fpmr))
+		return -EINVAL;
+
+	__get_user_error(fpmr, &user->fpmr->fpmr, err);
+	if (!err)
+		write_sysreg_s(fpmr, SYS_FPMR);
+
+	return err;
+}
 
 #ifdef CONFIG_ARM64_SVE
 
@@ -590,6 +620,7 @@ static int parse_user_sigframe(struct user_ctxs *user,
 	user->tpidr2 = NULL;
 	user->za = NULL;
 	user->zt = NULL;
+	user->fpmr = NULL;
 
 	if (!IS_ALIGNED((unsigned long)base, 16))
 		goto invalid;
@@ -684,6 +715,17 @@ static int parse_user_sigframe(struct user_ctxs *user,
 			user->zt_size = size;
 			break;
 
+		case FPMR_MAGIC:
+			if (!system_supports_fpmr())
+				goto invalid;
+
+			if (user->fpmr)
+				goto invalid;
+
+			user->fpmr = (struct fpmr_context __user *)head;
+			user->fpmr_size = size;
+			break;
+
 		case EXTRA_MAGIC:
 			if (have_extra_context)
 				goto invalid;
@@ -806,6 +848,9 @@ static int restore_sigframe(struct pt_regs *regs,
 	if (err == 0 && system_supports_tpidr2() && user.tpidr2)
 		err = restore_tpidr2_context(&user);
 
+	if (err == 0 && system_supports_fpmr() && user.fpmr)
+		err = restore_fpmr_context(&user);
+
 	if (err == 0 && system_supports_sme() && user.za)
 		err = restore_za_context(&user);
 
@@ -928,6 +973,13 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
 		}
 	}
 
+	if (system_supports_fpmr()) {
+		err = sigframe_alloc(user, &user->fpmr_offset,
+				     sizeof(struct fpmr_context));
+		if (err)
+			return err;
+	}
+
 	return sigframe_alloc_end(user);
 }
 
@@ -983,6 +1035,13 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
 		err |= preserve_tpidr2_context(tpidr2_ctx);
 	}
 
+	/* FPMR if supported */
+	if (system_supports_fpmr() && err == 0) {
+		struct fpmr_context __user *fpmr_ctx =
+			apply_user_offset(user, user->fpmr_offset);
+		err |= preserve_fpmr_context(fpmr_ctx);
+	}
+
 	/* ZA state if present */
 	if (system_supports_sme() && err == 0 && user->za_offset) {
 		struct za_context __user *za_ctx =

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:11 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:11 +0000
Subject: [PATCH v3 13/21] arm64/ptrace: Expose FPMR via ptrace
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-13-dbcbcd867a7f@kernel.org>

Add a new regset to expose FPMR via ptrace. It is not added to the FPSIMD
registers since that structure is exposed elsewhere without any allowance
for extension we don't add there.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/kernel/ptrace.c | 42 ++++++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/elf.h   |  1 +
 2 files changed, 43 insertions(+)

diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 20d7ef82de90..cfb8a4d213be 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -697,6 +697,39 @@ static int tls_set(struct task_struct *target, const struct user_regset *regset,
 	return ret;
 }
 
+static int fpmr_get(struct task_struct *target, const struct user_regset *regset,
+		   struct membuf to)
+{
+	if (!system_supports_fpmr())
+		return -EINVAL;
+
+	if (target == current)
+		fpsimd_preserve_current_state();
+
+	return membuf_store(&to, target->thread.fpmr);
+}
+
+static int fpmr_set(struct task_struct *target, const struct user_regset *regset,
+		   unsigned int pos, unsigned int count,
+		   const void *kbuf, const void __user *ubuf)
+{
+	int ret;
+	unsigned long fpmr;
+
+	if (!system_supports_fpmr())
+		return -EINVAL;
+
+	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &fpmr, 0, count);
+	if (ret)
+		return ret;
+
+	target->thread.fpmr = fpmr;
+
+	fpsimd_flush_task_state(target);
+
+	return 0;
+}
+
 static int system_call_get(struct task_struct *target,
 			   const struct user_regset *regset,
 			   struct membuf to)
@@ -1417,6 +1450,7 @@ enum aarch64_regset {
 	REGSET_HW_BREAK,
 	REGSET_HW_WATCH,
 #endif
+	REGSET_FPMR,
 	REGSET_SYSTEM_CALL,
 #ifdef CONFIG_ARM64_SVE
 	REGSET_SVE,
@@ -1495,6 +1529,14 @@ static const struct user_regset aarch64_regsets[] = {
 		.regset_get = system_call_get,
 		.set = system_call_set,
 	},
+	[REGSET_FPMR] = {
+		.core_note_type = NT_ARM_FPMR,
+		.n = 1,
+		.size = sizeof(u64),
+		.align = sizeof(u64),
+		.regset_get = fpmr_get,
+		.set = fpmr_set,
+	},
 #ifdef CONFIG_ARM64_SVE
 	[REGSET_SVE] = { /* Scalable Vector Extension */
 		.core_note_type = NT_ARM_SVE,
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index 9417309b7230..b54b313bcf07 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -440,6 +440,7 @@ typedef struct elf64_shdr {
 #define NT_ARM_SSVE	0x40b		/* ARM Streaming SVE registers */
 #define NT_ARM_ZA	0x40c		/* ARM SME ZA registers */
 #define NT_ARM_ZT	0x40d		/* ARM SME ZT registers */
+#define NT_ARM_FPMR	0x40e		/* ARM floating point mode register */
 #define NT_ARC_V2	0x600		/* ARCv2 accumulator/extra registers */
 #define NT_VMCOREDD	0x700		/* Vmcore Device Dump Note */
 #define NT_MIPS_DSP	0x800		/* MIPS DSP ASE registers */

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:12 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:12 +0000
Subject: [PATCH v3 14/21] KVM: arm64: Add newly allocated ID registers to
 register descriptions
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-14-dbcbcd867a7f@kernel.org>

The 2023 architecture extensions have allocated some new ID registers, add
them to the KVM system register descriptions so that they are visible to
guests.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/kvm/sys_regs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4735e1b37fb3..b843da5e4bb9 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2139,12 +2139,12 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 		   ID_AA64PFR0_EL1_AdvSIMD |
 		   ID_AA64PFR0_EL1_FP), },
 	ID_SANITISED(ID_AA64PFR1_EL1),
-	ID_UNALLOCATED(4,2),
+	ID_SANITISED(ID_AA64PFR2_EL1),
 	ID_UNALLOCATED(4,3),
 	ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0),
 	ID_HIDDEN(ID_AA64SMFR0_EL1),
 	ID_UNALLOCATED(4,6),
-	ID_UNALLOCATED(4,7),
+	ID_SANITISED(ID_AA64FPFR0_EL1),
 
 	/* CRm=5 */
 	{ SYS_DESC(SYS_ID_AA64DFR0_EL1),
@@ -2171,7 +2171,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	ID_WRITABLE(ID_AA64ISAR2_EL1, ~(ID_AA64ISAR2_EL1_RES0 |
 					ID_AA64ISAR2_EL1_APA3 |
 					ID_AA64ISAR2_EL1_GPA3)),
-	ID_UNALLOCATED(6,3),
+	ID_WRITABLE(ID_AA64ISAR3_EL1, ~ID_AA64ISAR3_EL1_RES0),
 	ID_UNALLOCATED(6,4),
 	ID_UNALLOCATED(6,5),
 	ID_UNALLOCATED(6,6),

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:13 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:13 +0000
Subject: [PATCH v3 15/21] KVM: arm64: Support FEAT_FPMR for guests
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-15-dbcbcd867a7f@kernel.org>

FEAT_FPMR introduces a new system register FPMR which allows configuration
of floating point behaviour, currently for FP8 specific features. Allow use
of this in guests, disabling the trap while guests are running and saving
and restoring the value along with the rest of the floating point state.
Since FPMR is stored immediately after the main floating point state we
share it with the hypervisor by adjusting the size of the shared region.

Access to FPMR is covered by both a register specific trap HCRX_EL2.EnFPM
and the overall floating point access trap so we just unconditionally
enable the FPMR specific trap and rely on the floating point access trap to
detect guest floating point usage.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_arm.h        |  2 +-
 arch/arm64/include/asm/kvm_host.h       |  4 +++-
 arch/arm64/kvm/emulate-nested.c         |  9 +++++++++
 arch/arm64/kvm/fpsimd.c                 | 20 +++++++++++++++++---
 arch/arm64/kvm/hyp/include/hyp/switch.h |  7 ++++++-
 arch/arm64/kvm/sys_regs.c               | 11 +++++++++++
 6 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 9f9239d86900..95f3b44e7c3a 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -103,7 +103,7 @@
 #define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
 
 #define HCRX_GUEST_FLAGS \
-	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | \
+	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM | \
 	 (cpus_have_final_cap(ARM64_HAS_MOPS) ? (HCRX_EL2_MSCEn | HCRX_EL2_MCE2) : 0))
 #define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM)
 
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index f8d98985a39c..9885adff06fa 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -391,6 +391,8 @@ enum vcpu_sysreg {
 	CNTP_CVAL_EL0,
 	CNTP_CTL_EL0,
 
+	FPMR,
+
 	/* Memory Tagging Extension registers */
 	RGSR_EL1,	/* Random Allocation Tag Seed Register */
 	GCR_EL1,	/* Tag Control Register */
@@ -517,7 +519,6 @@ struct kvm_vcpu_arch {
 	enum fp_type fp_type;
 	unsigned int sve_max_vl;
 	u64 svcr;
-	u64 fpmr;
 
 	/* Stage 2 paging state used by the hardware on next switch */
 	struct kvm_s2_mmu *hw_mmu;
@@ -576,6 +577,7 @@ struct kvm_vcpu_arch {
 	struct kvm_guest_debug_arch external_debug_state;
 
 	struct user_fpsimd_state *host_fpsimd_state;	/* hyp VA */
+	u64 *host_fpmr;					/* hyp VA */
 	struct task_struct *parent_task;
 
 	struct {
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index 06185216a297..802e5cde696f 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -67,6 +67,8 @@ enum cgt_group_id {
 	CGT_HCR_TTLBIS,
 	CGT_HCR_TTLBOS,
 
+	CGT_HCRX_EnFPM,
+
 	CGT_MDCR_TPMCR,
 	CGT_MDCR_TPM,
 	CGT_MDCR_TDE,
@@ -279,6 +281,12 @@ static const struct trap_bits coarse_trap_bits[] = {
 		.mask		= HCR_TTLBOS,
 		.behaviour	= BEHAVE_FORWARD_ANY,
 	},
+	[CGT_HCRX_EnFPM] = {
+		.index		= HCRX_EL2,
+		.value		= HCRX_EL2_EnFPM,
+		.mask		= HCRX_EL2_EnFPM,
+		.behaviour	= BEHAVE_FORWARD_ANY,
+	},
 	[CGT_MDCR_TPMCR] = {
 		.index		= MDCR_EL2,
 		.value		= MDCR_EL2_TPMCR,
@@ -478,6 +486,7 @@ static const struct encoding_to_trap_config encoding_to_cgt[] __initconst = {
 	SR_TRAP(SYS_AIDR_EL1,		CGT_HCR_TID1),
 	SR_TRAP(SYS_SMIDR_EL1,		CGT_HCR_TID1),
 	SR_TRAP(SYS_CTR_EL0,		CGT_HCR_TID2),
+	SR_TRAP(SYS_FPMR,		CGT_HCRX_EnFPM),
 	SR_TRAP(SYS_CCSIDR_EL1,		CGT_HCR_TID2_TID4),
 	SR_TRAP(SYS_CCSIDR2_EL1,	CGT_HCR_TID2_TID4),
 	SR_TRAP(SYS_CLIDR_EL1,		CGT_HCR_TID2_TID4),
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index e3e611e30e91..dee078625d0d 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -14,6 +14,16 @@
 #include <asm/kvm_mmu.h>
 #include <asm/sysreg.h>
 
+static void *fpsimd_share_end(struct user_fpsimd_state *fpsimd)
+{
+	void *share_end = fpsimd + 1;
+
+	if (cpus_have_final_cap(ARM64_HAS_FPMR))
+		share_end += sizeof(u64);
+
+	return share_end;
+}
+
 void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
 {
 	struct task_struct *p = vcpu->arch.parent_task;
@@ -23,7 +33,7 @@ void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
 		return;
 
 	fpsimd = &p->thread.uw.fpsimd_state;
-	kvm_unshare_hyp(fpsimd, fpsimd + 1);
+	kvm_unshare_hyp(fpsimd, fpsimd_share_end(fpsimd));
 	put_task_struct(p);
 }
 
@@ -45,11 +55,15 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
 	kvm_vcpu_unshare_task_fp(vcpu);
 
 	/* Make sure the host task fpsimd state is visible to hyp: */
-	ret = kvm_share_hyp(fpsimd, fpsimd + 1);
+	ret = kvm_share_hyp(fpsimd, fpsimd_share_end(fpsimd));
 	if (ret)
 		return ret;
 
 	vcpu->arch.host_fpsimd_state = kern_hyp_va(fpsimd);
+	if (cpus_have_final_cap(ARM64_HAS_FPMR)) {
+		WARN_ON_ONCE(&current->thread.fpmr + 1 != fpsimd_share_end(fpsimd));
+		vcpu->arch.host_fpmr = kern_hyp_va(&current->thread.fpmr);
+	}
 
 	/*
 	 * We need to keep current's task_struct pinned until its data has been
@@ -153,7 +167,7 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
 		fp_state.sve_vl = vcpu->arch.sve_max_vl;
 		fp_state.sme_state = NULL;
 		fp_state.svcr = &vcpu->arch.svcr;
-		fp_state.fpmr = &vcpu->arch.fpmr;
+		fp_state.fpmr = &__vcpu_sys_reg(vcpu, FPMR);
 		fp_state.fp_type = &vcpu->arch.fp_type;
 
 		if (vcpu_has_sve(vcpu))
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index f99d8af0b9af..a51b21a2e26f 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -339,10 +339,15 @@ static bool kvm_hyp_handle_fpsimd(struct kvm_vcpu *vcpu, u64 *exit_code)
 	isb();
 
 	/* Write out the host state if it's in the registers */
-	if (vcpu->arch.fp_state == FP_STATE_HOST_OWNED)
+	if (vcpu->arch.fp_state == FP_STATE_HOST_OWNED) {
 		__fpsimd_save_state(vcpu->arch.host_fpsimd_state);
+		if (cpus_have_final_cap(ARM64_HAS_FPMR))
+			*vcpu->arch.host_fpmr = read_sysreg_s(SYS_FPMR);
+	}
 
 	/* Restore the guest state */
+	if (cpus_have_final_cap(ARM64_HAS_FPMR))
+		write_sysreg_s(__vcpu_sys_reg(vcpu, FPMR), SYS_FPMR);
 	if (sve_guest)
 		__hyp_sve_restore_guest(vcpu);
 	else
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index b843da5e4bb9..0789fb632623 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1914,6 +1914,15 @@ static unsigned int hidden_user_visibility(const struct kvm_vcpu *vcpu,
 	.visibility = hidden_user_visibility,	\
 }
 
+static unsigned int fpmr_visibility(const struct kvm_vcpu *vcpu,
+				    const struct sys_reg_desc *rd)
+{
+	if (cpus_have_final_cap(ARM64_HAS_FPMR))
+		return 0;
+
+	return REG_HIDDEN;
+}
+
 /*
  * Since reset() callback and field val are not used for idregs, they will be
  * used for specific purposes for idregs.
@@ -2310,6 +2319,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, CSSELR_EL1 },
 	{ SYS_DESC(SYS_CTR_EL0), access_ctr },
 	{ SYS_DESC(SYS_SVCR), undef_access },
+	{ SYS_DESC(SYS_FPMR), access_rw, reset_unknown, FPMR,
+	  .visibility = fpmr_visibility },
 
 	{ PMU_SYS_REG(PMCR_EL0), .access = access_pmcr, .reset = reset_pmcr,
 	  .reg = PMCR_EL0, .get_user = get_pmcr, .set_user = set_pmcr },

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:14 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:14 +0000
Subject: [PATCH v3 16/21] arm64/hwcap: Define hwcaps for 2023 DPISA
 features
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-16-dbcbcd867a7f@kernel.org>

The 2023 architecture extensions include a large number of floating point
features, most of which simply add new instructions. Add hwcaps so that
userspace can enumerate these features.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 Documentation/arch/arm64/elf_hwcaps.rst | 49 +++++++++++++++++++++++++++++++++
 arch/arm64/include/asm/hwcap.h          | 15 ++++++++++
 arch/arm64/include/uapi/asm/hwcap.h     | 15 ++++++++++
 arch/arm64/kernel/cpufeature.c          | 35 +++++++++++++++++++++++
 arch/arm64/kernel/cpuinfo.c             | 15 ++++++++++
 5 files changed, 129 insertions(+)

diff --git a/Documentation/arch/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst
index ced7b335e2e0..448c1664879b 100644
--- a/Documentation/arch/arm64/elf_hwcaps.rst
+++ b/Documentation/arch/arm64/elf_hwcaps.rst
@@ -317,6 +317,55 @@ HWCAP2_LRCPC3
 HWCAP2_LSE128
     Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0011.
 
+HWCAP2_FPMR
+    Functionality implied by ID_AA64PFR2_EL1.FMR == 0b0001.
+
+HWCAP2_LUT
+    Functionality implied by ID_AA64ISAR2_EL1.LUT == 0b0001.
+
+HWCAP2_FAMINMAX
+    Functionality implied by ID_AA64ISAR3_EL1.FAMINMAX == 0b0001.
+
+HWCAP2_F8CVT
+    Functionality implied by ID_AA64FPFR0_EL1.F8CVT == 0b1.
+
+HWCAP2_F8FMA
+    Functionality implied by ID_AA64FPFR0_EL1.F8FMA == 0b1.
+
+HWCAP2_F8DP4
+    Functionality implied by ID_AA64FPFR0_EL1.F8DP4 == 0b1.
+
+HWCAP2_F8DP2
+    Functionality implied by ID_AA64FPFR0_EL1.F8DP2 == 0b1.
+
+HWCAP2_F8E4M3
+    Functionality implied by ID_AA64FPFR0_EL1.F8E4M3 == 0b1.
+
+HWCAP2_F8E5M2
+    Functionality implied by ID_AA64FPFR0_EL1.F8E5M2 == 0b1.
+
+HWCAP2_SME_LUTV2
+    Functionality implied by ID_AA64SMFR0_EL1.LUTv2 == 0b1.
+
+HWCAP2_SME_F8F16
+    Functionality implied by ID_AA64SMFR0_EL1.F8F16 == 0b1.
+
+HWCAP2_SME_F8F32
+    Functionality implied by ID_AA64SMFR0_EL1.F8F32 == 0b1.
+
+HWCAP2_SME_SF8FMA
+    Functionality implied by ID_AA64SMFR0_EL1.SF8FMA == 0b1.
+
+HWCAP2_SME_SF8DP4
+    Functionality implied by ID_AA64SMFR0_EL1.SF8DP4 == 0b1.
+
+HWCAP2_SME_SF8DP2
+    Functionality implied by ID_AA64SMFR0_EL1.SF8DP2 == 0b1.
+
+HWCAP2_SME_SF8DP4
+    Functionality implied by ID_AA64SMFR0_EL1.SF8DP4 == 0b1.
+
+
 4. Unused AT_HWCAP bits
 -----------------------
 
diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index cd71e09ea14d..4edd3b61df11 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -142,6 +142,21 @@
 #define KERNEL_HWCAP_SVE_B16B16		__khwcap2_feature(SVE_B16B16)
 #define KERNEL_HWCAP_LRCPC3		__khwcap2_feature(LRCPC3)
 #define KERNEL_HWCAP_LSE128		__khwcap2_feature(LSE128)
+#define KERNEL_HWCAP_FPMR		__khwcap2_feature(FPMR)
+#define KERNEL_HWCAP_LUT		__khwcap2_feature(LUT)
+#define KERNEL_HWCAP_FAMINMAX		__khwcap2_feature(FAMINMAX)
+#define KERNEL_HWCAP_F8CVT		__khwcap2_feature(F8CVT)
+#define KERNEL_HWCAP_F8FMA		__khwcap2_feature(F8FMA)
+#define KERNEL_HWCAP_F8DP4		__khwcap2_feature(F8DP4)
+#define KERNEL_HWCAP_F8DP2		__khwcap2_feature(F8DP2)
+#define KERNEL_HWCAP_F8E4M3		__khwcap2_feature(F8E4M3)
+#define KERNEL_HWCAP_F8E5M2		__khwcap2_feature(F8E5M2)
+#define KERNEL_HWCAP_SME_LUTV2		__khwcap2_feature(SME_LUTV2)
+#define KERNEL_HWCAP_SME_F8F16		__khwcap2_feature(SME_F8F16)
+#define KERNEL_HWCAP_SME_F8F32		__khwcap2_feature(SME_F8F32)
+#define KERNEL_HWCAP_SME_SF8FMA		__khwcap2_feature(SME_SF8FMA)
+#define KERNEL_HWCAP_SME_SF8DP4		__khwcap2_feature(SME_SF8DP4)
+#define KERNEL_HWCAP_SME_SF8DP2		__khwcap2_feature(SME_SF8DP2)
 
 /*
  * This yields a mask that user programs can use to figure out what
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 5023599fa278..285610e626f5 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -107,5 +107,20 @@
 #define HWCAP2_SVE_B16B16	(1UL << 45)
 #define HWCAP2_LRCPC3		(1UL << 46)
 #define HWCAP2_LSE128		(1UL << 47)
+#define HWCAP2_FPMR		(1UL << 48)
+#define HWCAP2_LUT		(1UL << 49)
+#define HWCAP2_FAMINMAX		(1UL << 50)
+#define HWCAP2_F8CVT		(1UL << 51)
+#define HWCAP2_F8FMA		(1UL << 52)
+#define HWCAP2_F8DP4		(1UL << 53)
+#define HWCAP2_F8DP2		(1UL << 54)
+#define HWCAP2_F8E4M3		(1UL << 55)
+#define HWCAP2_F8E5M2		(1UL << 56)
+#define HWCAP2_SME_LUTV2	(1UL << 57)
+#define HWCAP2_SME_F8F16	(1UL << 58)
+#define HWCAP2_SME_F8F32	(1UL << 59)
+#define HWCAP2_SME_SF8FMA	(1UL << 60)
+#define HWCAP2_SME_SF8DP4	(1UL << 61)
+#define HWCAP2_SME_SF8DP2	(1UL << 62)
 
 #endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index ea0b680792de..33e301b6e31e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -220,6 +220,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_EL1_LUT_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_EL1_CSSC_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_EL1_RPRFM_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_EL1_CLRBHB_SHIFT, 4, 0),
@@ -235,6 +236,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64isar3[] = {
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR3_EL1_FAMINMAX_SHIFT, 4, 0),
 	ARM64_FTR_END,
 };
 
@@ -303,6 +305,8 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
 static const struct arm64_ftr_bits ftr_id_aa64smfr0[] = {
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
 		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_FA64_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
+		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_LUTv2_SHIFT, 1, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
 		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_SMEver_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
@@ -315,6 +319,10 @@ static const struct arm64_ftr_bits ftr_id_aa64smfr0[] = {
 		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_B16B16_SHIFT, 1, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
 		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_F16F16_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
+		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_F8F16_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
+		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_F8F32_SHIFT, 1, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
 		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_I8I32_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
@@ -325,10 +333,22 @@ static const struct arm64_ftr_bits ftr_id_aa64smfr0[] = {
 		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_BI32I32_SHIFT, 1, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
 		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_F32F32_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
+		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_SF8FMA_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
+		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_SF8DP4_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
+		       FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_SF8DP2_SHIFT, 1, 0),
 	ARM64_FTR_END,
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64fpfr0[] = {
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8CVT_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8FMA_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8DP4_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8DP2_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8E4M3_SHIFT, 1, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8E5M2_SHIFT, 1, 0),
 	ARM64_FTR_END,
 };
 
@@ -2851,6 +2871,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
 	HWCAP_CAP(ID_AA64PFR0_EL1, AdvSIMD, IMP, CAP_HWCAP, KERNEL_HWCAP_ASIMD),
 	HWCAP_CAP(ID_AA64PFR0_EL1, AdvSIMD, FP16, CAP_HWCAP, KERNEL_HWCAP_ASIMDHP),
 	HWCAP_CAP(ID_AA64PFR0_EL1, DIT, IMP, CAP_HWCAP, KERNEL_HWCAP_DIT),
+	HWCAP_CAP(ID_AA64PFR2_EL1, FPMR, IMP, CAP_HWCAP, KERNEL_HWCAP_FPMR),
 	HWCAP_CAP(ID_AA64ISAR1_EL1, DPB, IMP, CAP_HWCAP, KERNEL_HWCAP_DCPOP),
 	HWCAP_CAP(ID_AA64ISAR1_EL1, DPB, DPB2, CAP_HWCAP, KERNEL_HWCAP_DCPODP),
 	HWCAP_CAP(ID_AA64ISAR1_EL1, JSCVT, IMP, CAP_HWCAP, KERNEL_HWCAP_JSCVT),
@@ -2864,6 +2885,8 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
 	HWCAP_CAP(ID_AA64ISAR1_EL1, BF16, EBF16, CAP_HWCAP, KERNEL_HWCAP_EBF16),
 	HWCAP_CAP(ID_AA64ISAR1_EL1, DGH, IMP, CAP_HWCAP, KERNEL_HWCAP_DGH),
 	HWCAP_CAP(ID_AA64ISAR1_EL1, I8MM, IMP, CAP_HWCAP, KERNEL_HWCAP_I8MM),
+	HWCAP_CAP(ID_AA64ISAR2_EL1, LUT, IMP, CAP_HWCAP, KERNEL_HWCAP_LUT),
+	HWCAP_CAP(ID_AA64ISAR3_EL1, FAMINMAX, IMP, CAP_HWCAP, KERNEL_HWCAP_FAMINMAX),
 	HWCAP_CAP(ID_AA64MMFR2_EL1, AT, IMP, CAP_HWCAP, KERNEL_HWCAP_USCAT),
 #ifdef CONFIG_ARM64_SVE
 	HWCAP_CAP(ID_AA64PFR0_EL1, SVE, IMP, CAP_HWCAP, KERNEL_HWCAP_SVE),
@@ -2904,6 +2927,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
 #ifdef CONFIG_ARM64_SME
 	HWCAP_CAP(ID_AA64PFR1_EL1, SME, IMP, CAP_HWCAP, KERNEL_HWCAP_SME),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, FA64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_FA64),
+	HWCAP_CAP(ID_AA64SMFR0_EL1, LUTv2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_LUTV2),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, SMEver, SME2p1, CAP_HWCAP, KERNEL_HWCAP_SME2P1),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, SMEver, SME2, CAP_HWCAP, KERNEL_HWCAP_SME2),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, I16I64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I64),
@@ -2911,12 +2935,23 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
 	HWCAP_CAP(ID_AA64SMFR0_EL1, I16I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I32),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, B16B16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16B16),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, F16F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F16),
+	HWCAP_CAP(ID_AA64SMFR0_EL1, F8F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F16),
+	HWCAP_CAP(ID_AA64SMFR0_EL1, F8F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F32),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, I8I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I8I32),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, F16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F32),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, B16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16F32),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, BI32I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_BI32I32),
 	HWCAP_CAP(ID_AA64SMFR0_EL1, F32F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F32F32),
+	HWCAP_CAP(ID_AA64SMFR0_EL1, SF8FMA, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8FMA),
+	HWCAP_CAP(ID_AA64SMFR0_EL1, SF8DP4, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP4),
+	HWCAP_CAP(ID_AA64SMFR0_EL1, SF8DP2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP2),
 #endif /* CONFIG_ARM64_SME */
+	HWCAP_CAP(ID_AA64FPFR0_EL1, F8CVT, IMP, CAP_HWCAP, KERNEL_HWCAP_F8CVT),
+	HWCAP_CAP(ID_AA64FPFR0_EL1, F8FMA, IMP, CAP_HWCAP, KERNEL_HWCAP_F8FMA),
+	HWCAP_CAP(ID_AA64FPFR0_EL1, F8DP4, IMP, CAP_HWCAP, KERNEL_HWCAP_F8DP4),
+	HWCAP_CAP(ID_AA64FPFR0_EL1, F8DP2, IMP, CAP_HWCAP, KERNEL_HWCAP_F8DP2),
+	HWCAP_CAP(ID_AA64FPFR0_EL1, F8E4M3, IMP, CAP_HWCAP, KERNEL_HWCAP_F8E4M3),
+	HWCAP_CAP(ID_AA64FPFR0_EL1, F8E5M2, IMP, CAP_HWCAP, KERNEL_HWCAP_F8E5M2),
 	{},
 };
 
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 8322e968fd0d..29155107d35d 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -130,6 +130,21 @@ static const char *const hwcap_str[] = {
 	[KERNEL_HWCAP_SVE_B16B16]	= "sveb16b16",
 	[KERNEL_HWCAP_LRCPC3]		= "lrcpc3",
 	[KERNEL_HWCAP_LSE128]		= "lse128",
+	[KERNEL_HWCAP_FPMR]		= "fpmr",
+	[KERNEL_HWCAP_LUT]		= "lut",
+	[KERNEL_HWCAP_FAMINMAX]		= "faminmax",
+	[KERNEL_HWCAP_F8CVT]		= "f8cvt",
+	[KERNEL_HWCAP_F8FMA]		= "f8fma",
+	[KERNEL_HWCAP_F8DP4]		= "f8dp4",
+	[KERNEL_HWCAP_F8DP2]		= "f8dp2",
+	[KERNEL_HWCAP_F8E4M3]		= "f8e4m3",
+	[KERNEL_HWCAP_F8E5M2]		= "f8e5m2",
+	[KERNEL_HWCAP_SME_LUTV2]	= "smelutv2",
+	[KERNEL_HWCAP_SME_F8F16]	= "smef8f16",
+	[KERNEL_HWCAP_SME_F8F32]	= "smef8f32",
+	[KERNEL_HWCAP_SME_SF8FMA]	= "smesf8fma",
+	[KERNEL_HWCAP_SME_SF8DP4]	= "smesf8dp4",
+	[KERNEL_HWCAP_SME_SF8DP2]	= "smesf8dp2",
 };
 
 #ifdef CONFIG_COMPAT

-- 
2.30.2



From robin.murphy at arm.com  Tue Dec  5 08:51:56 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue,  5 Dec 2023 16:51:56 +0000
Subject: [PATCH 3/5] perf/arm_cspmu: Simplify counter reset
In-Reply-To: <cover.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com>
Message-ID: <34ecf45f0f9a0fa34a580f162f02c23d9b849d90.1701793996.git.robin.murphy@arm.com>

arm_cspmu_reset_counters() inherently also stops them since it is
writing 0 to PMCR.E, so there should be no need to do that twice.
Also tidy up the reset routine itself for consistency with the start
and stop routines, and to be clear at first glance that it is simply
writing a constant value.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/perf/arm_cspmu/arm_cspmu.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index f7aa2ac5fd88..b64de4d800c7 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -525,11 +525,7 @@ static int arm_cspmu_alloc_attr_groups(struct arm_cspmu *cspmu)
 
 static inline void arm_cspmu_reset_counters(struct arm_cspmu *cspmu)
 {
-	u32 pmcr = 0;
-
-	pmcr |= PMCR_P;
-	pmcr |= PMCR_C;
-	writel(pmcr, cspmu->base0 + PMCR);
+	writel(PMCR_C | PMCR_P, cspmu->base0 + PMCR);
 }
 
 static inline void arm_cspmu_start_counters(struct arm_cspmu *cspmu)
@@ -1189,7 +1185,6 @@ static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
 	};
 
 	/* Hardware counter init */
-	arm_cspmu_stop_counters(cspmu);
 	arm_cspmu_reset_counters(cspmu);
 
 	ret = perf_pmu_register(&cspmu->pmu, cspmu->name, -1);
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Tue Dec  5 08:51:53 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue,  5 Dec 2023 16:51:53 +0000
Subject: [PATCH 0/5] perf/arm_cspmu: Add devicetree support
Message-ID: <cover.1701793996.git.robin.murphy@arm.com>

Hi all,

This series does a bit more cleanup and adds devicetree support for
CoreSight PMUs. The thing for which I originally wrote this has turned
out not to warrant upstream support, but others have also expressed an
interest so here it is.

Thanks,
Robin.


Robin Murphy (5):
  perf/arm_cspmu: Simplify initialisation
  perf/arm_cspmu: Simplify attribute groups
  perf/arm_cspmu: Simplify counter reset
  dt-bindings/perf: Add Arm CoreSight PMU
  perf/arm_cspmu: Add devicetree support

 .../bindings/perf/arm,coresight-pmu.yaml      |  39 +++++
 drivers/perf/arm_cspmu/arm_cspmu.c            | 155 ++++++++++--------
 drivers/perf/arm_cspmu/arm_cspmu.h            |   1 +
 drivers/perf/arm_cspmu/nvidia_cspmu.c         |   6 -
 4 files changed, 126 insertions(+), 75 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml

-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Tue Dec  5 08:51:55 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue,  5 Dec 2023 16:51:55 +0000
Subject: [PATCH 2/5] perf/arm_cspmu: Simplify attribute groups
In-Reply-To: <cover.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com>
Message-ID: <f75cacb440011df35fc476cf4be37484fd044b92.1701793996.git.robin.murphy@arm.com>

The attribute group array itself is always the same, so there's no
need to allocate it separately. Storing it directly in our instance
data saves memory and gives us one less point of failure.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/perf/arm_cspmu/arm_cspmu.c | 26 +++++++++-----------------
 drivers/perf/arm_cspmu/arm_cspmu.h |  1 +
 2 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index a3347b1287e6..f7aa2ac5fd88 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -501,23 +501,16 @@ arm_cspmu_alloc_format_attr_group(struct arm_cspmu *cspmu)
 	return format_group;
 }
 
-static struct attribute_group **
-arm_cspmu_alloc_attr_group(struct arm_cspmu *cspmu)
+static int arm_cspmu_alloc_attr_groups(struct arm_cspmu *cspmu)
 {
-	struct attribute_group **attr_groups = NULL;
-	struct device *dev = cspmu->dev;
+	const struct attribute_group **attr_groups = cspmu->attr_groups;
 	const struct arm_cspmu_impl_ops *impl_ops = &cspmu->impl.ops;
 
 	cspmu->identifier = impl_ops->get_identifier(cspmu);
 	cspmu->name = impl_ops->get_name(cspmu);
 
 	if (!cspmu->identifier || !cspmu->name)
-		return NULL;
-
-	attr_groups = devm_kcalloc(dev, 5, sizeof(struct attribute_group *),
-				   GFP_KERNEL);
-	if (!attr_groups)
-		return NULL;
+		return -ENOMEM;
 
 	attr_groups[0] = arm_cspmu_alloc_event_attr_group(cspmu);
 	attr_groups[1] = arm_cspmu_alloc_format_attr_group(cspmu);
@@ -525,9 +518,9 @@ arm_cspmu_alloc_attr_group(struct arm_cspmu *cspmu)
 	attr_groups[3] = &arm_cspmu_cpumask_attr_group;
 
 	if (!attr_groups[0] || !attr_groups[1])
-		return NULL;
+		return -ENOMEM;
 
-	return attr_groups;
+	return 0;
 }
 
 static inline void arm_cspmu_reset_counters(struct arm_cspmu *cspmu)
@@ -1166,11 +1159,10 @@ static int arm_cspmu_get_cpus(struct arm_cspmu *cspmu)
 static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
 {
 	int ret, capabilities;
-	struct attribute_group **attr_groups;
 
-	attr_groups = arm_cspmu_alloc_attr_group(cspmu);
-	if (!attr_groups)
-		return -ENOMEM;
+	ret = arm_cspmu_alloc_attr_groups(cspmu);
+	if (ret)
+		return ret;
 
 	ret = cpuhp_state_add_instance(arm_cspmu_cpuhp_state,
 				       &cspmu->cpuhp_node);
@@ -1192,7 +1184,7 @@ static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
 		.start		= arm_cspmu_start,
 		.stop		= arm_cspmu_stop,
 		.read		= arm_cspmu_read,
-		.attr_groups	= (const struct attribute_group **)attr_groups,
+		.attr_groups	= cspmu->attr_groups,
 		.capabilities	= capabilities,
 	};
 
diff --git a/drivers/perf/arm_cspmu/arm_cspmu.h b/drivers/perf/arm_cspmu/arm_cspmu.h
index 2fe723555a6b..c9163acfe810 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.h
+++ b/drivers/perf/arm_cspmu/arm_cspmu.h
@@ -157,6 +157,7 @@ struct arm_cspmu {
 	int cycle_counter_logical_idx;
 
 	struct arm_cspmu_hw_events hw_events;
+	const struct attribute_group *attr_groups[5];
 
 	struct arm_cspmu_impl impl;
 };
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Tue Dec  5 08:51:54 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue,  5 Dec 2023 16:51:54 +0000
Subject: [PATCH 1/5] perf/arm_cspmu: Simplify initialisation
In-Reply-To: <cover.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com>
Message-ID: <9842b71263a0a5e7ebb9aebb5f9ac15e1e24ff65.1701793996.git.robin.murphy@arm.com>

It's far simpler for implementations to literally override whichever
default ops they want to, by initialising to the default ops first. This
saves all the bother of checking what the impl_init_ops call has or
hasn't touched. Make the same clear distinction for the PMIIDR override
as well, in case we gain more sources for overriding that in future.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/perf/arm_cspmu/arm_cspmu.c    | 55 +++++++++++----------------
 drivers/perf/arm_cspmu/nvidia_cspmu.c |  6 ---
 2 files changed, 22 insertions(+), 39 deletions(-)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index 2cc35dded007..a3347b1287e6 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -100,13 +100,6 @@
 #define ARM_CSPMU_ACTIVE_CPU_MASK		0x0
 #define ARM_CSPMU_ASSOCIATED_CPU_MASK		0x1
 
-/* Check and use default if implementer doesn't provide attribute callback */
-#define CHECK_DEFAULT_IMPL_OPS(ops, callback)			\
-	do {							\
-		if (!ops->callback)				\
-			ops->callback = arm_cspmu_ ## callback;	\
-	} while (0)
-
 /*
  * Maximum poll count for reading counter value using high-low-high sequence.
  */
@@ -408,21 +401,32 @@ static struct arm_cspmu_impl_match *arm_cspmu_impl_match_get(u32 pmiidr)
 	return NULL;
 }
 
+#define DEFAULT_IMPL_OP(name)	.name = arm_cspmu_##name
+
 static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
 {
 	int ret = 0;
-	struct arm_cspmu_impl_ops *impl_ops = &cspmu->impl.ops;
 	struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(cspmu->dev);
 	struct arm_cspmu_impl_match *match;
 
-	/*
-	 * Get PMU implementer and product id from APMT node.
-	 * If APMT node doesn't have implementer/product id, try get it
-	 * from PMIIDR.
-	 */
-	cspmu->impl.pmiidr =
-		(apmt_node->impl_id) ? apmt_node->impl_id :
-				       readl(cspmu->base0 + PMIIDR);
+	/* Start with a default PMU implementation */
+	cspmu->impl.module = THIS_MODULE;
+	cspmu->impl.pmiidr = readl(cspmu->base0 + PMIIDR);
+	cspmu->impl.ops = (struct arm_cspmu_impl_ops) {
+		DEFAULT_IMPL_OP(get_event_attrs),
+		DEFAULT_IMPL_OP(get_format_attrs),
+		DEFAULT_IMPL_OP(get_identifier),
+		DEFAULT_IMPL_OP(get_name),
+		DEFAULT_IMPL_OP(is_cycle_counter_event),
+		DEFAULT_IMPL_OP(event_type),
+		DEFAULT_IMPL_OP(event_filter),
+		DEFAULT_IMPL_OP(set_ev_filter),
+		DEFAULT_IMPL_OP(event_attr_is_visible),
+	};
+
+	/* Firmware may override implementer/product ID from PMIIDR */
+	if (apmt_node->impl_id)
+		cspmu->impl.pmiidr = apmt_node->impl_id;
 
 	/* Find implementer specific attribute ops. */
 	match = arm_cspmu_impl_match_get(cspmu->impl.pmiidr);
@@ -450,24 +454,9 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
 		}
 
 		mutex_unlock(&arm_cspmu_lock);
+	}
 
-		if (ret)
-			return ret;
-	} else
-		cspmu->impl.module = THIS_MODULE;
-
-	/* Use default callbacks if implementer doesn't provide one. */
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_event_attrs);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_format_attrs);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_identifier);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_name);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, is_cycle_counter_event);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, event_type);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, event_filter);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, event_attr_is_visible);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, set_ev_filter);
-
-	return 0;
+	return ret;
 }
 
 static struct attribute_group *
diff --git a/drivers/perf/arm_cspmu/nvidia_cspmu.c b/drivers/perf/arm_cspmu/nvidia_cspmu.c
index 0382b702f092..5b84b701ad62 100644
--- a/drivers/perf/arm_cspmu/nvidia_cspmu.c
+++ b/drivers/perf/arm_cspmu/nvidia_cspmu.c
@@ -388,12 +388,6 @@ static int nv_cspmu_init_ops(struct arm_cspmu *cspmu)
 	impl_ops->get_format_attrs		= nv_cspmu_get_format_attrs;
 	impl_ops->get_name			= nv_cspmu_get_name;
 
-	/* Set others to NULL to use default callback. */
-	impl_ops->event_type			= NULL;
-	impl_ops->event_attr_is_visible		= NULL;
-	impl_ops->get_identifier		= NULL;
-	impl_ops->is_cycle_counter_event	= NULL;
-
 	return 0;
 }
 
-- 
2.39.2.101.g768bb238c484.dirty



From broonie at kernel.org  Tue Dec  5 08:48:15 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:15 +0000
Subject: [PATCH v3 17/21] kselftest/arm64: Handle FPMR context in generic
 signal frame parser
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-17-dbcbcd867a7f@kernel.org>

Teach the generic signal frame parsing code about the newly added FPMR
frame, avoiding warnings every time one is generated.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 tools/testing/selftests/arm64/signal/testcases/testcases.c | 8 ++++++++
 tools/testing/selftests/arm64/signal/testcases/testcases.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/tools/testing/selftests/arm64/signal/testcases/testcases.c b/tools/testing/selftests/arm64/signal/testcases/testcases.c
index 9f580b55b388..674b88cc8c39 100644
--- a/tools/testing/selftests/arm64/signal/testcases/testcases.c
+++ b/tools/testing/selftests/arm64/signal/testcases/testcases.c
@@ -209,6 +209,14 @@ bool validate_reserved(ucontext_t *uc, size_t resv_sz, char **err)
 			zt = (struct zt_context *)head;
 			new_flags |= ZT_CTX;
 			break;
+		case FPMR_MAGIC:
+			if (flags & FPMR_CTX)
+				*err = "Multiple FPMR_MAGIC";
+			else if (head->size !=
+				 sizeof(struct fpmr_context))
+				*err = "Bad size for fpmr_context";
+			new_flags |= FPMR_CTX;
+			break;
 		case EXTRA_MAGIC:
 			if (flags & EXTRA_CTX)
 				*err = "Multiple EXTRA_MAGIC";
diff --git a/tools/testing/selftests/arm64/signal/testcases/testcases.h b/tools/testing/selftests/arm64/signal/testcases/testcases.h
index a08ab0d6207a..7727126347e0 100644
--- a/tools/testing/selftests/arm64/signal/testcases/testcases.h
+++ b/tools/testing/selftests/arm64/signal/testcases/testcases.h
@@ -19,6 +19,7 @@
 #define ZA_CTX		(1 << 2)
 #define EXTRA_CTX	(1 << 3)
 #define ZT_CTX		(1 << 4)
+#define FPMR_CTX	(1 << 5)
 
 #define KSFT_BAD_MAGIC	0xdeadbeef
 

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:16 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:16 +0000
Subject: [PATCH v3 18/21] kselftest/arm64: Add basic FPMR test
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-18-dbcbcd867a7f@kernel.org>

Verify that a FPMR frame is generated on systems that support FPMR and not
generated otherwise.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 tools/testing/selftests/arm64/signal/.gitignore    |  1 +
 .../arm64/signal/testcases/fpmr_siginfo.c          | 82 ++++++++++++++++++++++
 2 files changed, 83 insertions(+)

diff --git a/tools/testing/selftests/arm64/signal/.gitignore b/tools/testing/selftests/arm64/signal/.gitignore
index 839e3a252629..1ce5b5eac386 100644
--- a/tools/testing/selftests/arm64/signal/.gitignore
+++ b/tools/testing/selftests/arm64/signal/.gitignore
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 mangle_*
 fake_sigreturn_*
+fpmr_*
 sme_*
 ssve_*
 sve_*
diff --git a/tools/testing/selftests/arm64/signal/testcases/fpmr_siginfo.c b/tools/testing/selftests/arm64/signal/testcases/fpmr_siginfo.c
new file mode 100644
index 000000000000..e9d24685e741
--- /dev/null
+++ b/tools/testing/selftests/arm64/signal/testcases/fpmr_siginfo.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 ARM Limited
+ *
+ * Verify that the FPMR register context in signal frames is set up as
+ * expected.
+ */
+
+#include <signal.h>
+#include <ucontext.h>
+#include <sys/auxv.h>
+#include <sys/prctl.h>
+#include <unistd.h>
+#include <asm/sigcontext.h>
+
+#include "test_signals_utils.h"
+#include "testcases.h"
+
+static union {
+	ucontext_t uc;
+	char buf[1024 * 128];
+} context;
+
+#define SYS_FPMR "S3_3_C4_C4_2"
+
+static uint64_t get_fpmr(void)
+{
+	uint64_t val;
+
+	asm volatile (
+		"mrs	%0, " SYS_FPMR "\n"
+		: "=r"(val)
+		:
+		: "cc");
+
+	return val;
+}
+
+int fpmr_present(struct tdescr *td, siginfo_t *si, ucontext_t *uc)
+{
+	struct _aarch64_ctx *head = GET_BUF_RESV_HEAD(context);
+	struct fpmr_context *fpmr_ctx;
+	size_t offset;
+	bool in_sigframe;
+	bool have_fpmr;
+	__u64 orig_fpmr;
+
+	have_fpmr = getauxval(AT_HWCAP2) & HWCAP2_FPMR;
+	if (have_fpmr)
+		orig_fpmr = get_fpmr();
+
+	if (!get_current_context(td, &context.uc, sizeof(context)))
+		return 1;
+
+	fpmr_ctx = (struct fpmr_context *)
+		get_header(head, FPMR_MAGIC, td->live_sz, &offset);
+
+	in_sigframe = fpmr_ctx != NULL;
+
+	fprintf(stderr, "FPMR sigframe %s on system %s FPMR\n",
+		in_sigframe ? "present" : "absent",
+		have_fpmr ? "with" : "without");
+
+	td->pass = (in_sigframe == have_fpmr);
+
+	if (have_fpmr && fpmr_ctx) {
+		if (fpmr_ctx->fpmr != orig_fpmr) {
+			fprintf(stderr, "FPMR in frame is %llx, was %llx\n",
+				fpmr_ctx->fpmr, orig_fpmr);
+			td->pass = false;
+		}
+	}
+
+	return 0;
+}
+
+struct tdescr tde = {
+	.name = "FPMR",
+	.descr = "Validate that FPMR is present as expected",
+	.timeout = 3,
+	.run = fpmr_present,
+};

-- 
2.30.2



From robin.murphy at arm.com  Tue Dec  5 08:51:57 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue,  5 Dec 2023 16:51:57 +0000
Subject: [PATCH 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <cover.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com>
Message-ID: <bbb4262065cfc906f98165cac074e86dce19599e.1701793996.git.robin.murphy@arm.com>

Add a binding for implementations of the Arm CoreSight Performance
Monitoring Unit Architecture. Not to be confused with CoreSight debug
and trace, the PMU architecture defines a standard MMIO interface for
event counters similar to the CPU PMU architecture, where the
implementation and most of its features are discoverable through ID
registers.

CC: Rob Herring <robh+dt at kernel.org>
CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
CC: Conor Dooley <conor+dt at kernel.org>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 .../bindings/perf/arm,coresight-pmu.yaml      | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml

diff --git a/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
new file mode 100644
index 000000000000..12c7b28eee35
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/arm,coresight-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Coresight Performance Monitoring Unit Architecture
+
+maintainers:
+  - Robin Murphy <robin.murphy at arm.com>
+
+properties:
+  compatible:
+    const: arm,coresight-pmu
+
+  reg:
+    items:
+      - description: Register page 0
+      - description: Register page 1 (if dual-page extension implemented)
+    minItems: 1
+
+  interrupts:
+    items:
+      - description: Overflow interrupt
+
+  cpus:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    minItems: 1
+    description: List of CPUs with which the PMU is associated, if applicable
+
+  arm,64-bit-atomic:
+    type: boolean
+    description: Register accesses are single-copy atomic at doubleword granularity
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Tue Dec  5 08:51:58 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue,  5 Dec 2023 16:51:58 +0000
Subject: [PATCH 5/5] perf/arm_cspmu: Add devicetree support
In-Reply-To: <cover.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com>
Message-ID: <7000cdf3a22afe684793863e81a1d96bbddb5db1.1701793996.git.robin.murphy@arm.com>

Hook up devicetree probing support. For now let's hope that people
implement PMIIDR properly and we don't need an override mechanism.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/perf/arm_cspmu/arm_cspmu.c | 71 +++++++++++++++++++++++-------
 1 file changed, 56 insertions(+), 15 deletions(-)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index b64de4d800c7..80b5fc417ee3 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -27,6 +27,7 @@
 #include <linux/io-64-nonatomic-lo-hi.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 #include <linux/perf_event.h>
 #include <linux/platform_device.h>
 
@@ -309,6 +310,10 @@ static const char *arm_cspmu_get_name(const struct arm_cspmu *cspmu)
 	static atomic_t pmu_idx[ACPI_APMT_NODE_TYPE_COUNT] = { 0 };
 
 	dev = cspmu->dev;
+	if (!has_acpi_companion(dev))
+		return devm_kasprintf(dev, GFP_KERNEL, PMUNAME "_%u",
+				      atomic_fetch_inc(&pmu_idx[0]));
+
 	apmt_node = arm_cspmu_apmt_node(dev);
 	pmu_type = apmt_node->type;
 
@@ -406,7 +411,6 @@ static struct arm_cspmu_impl_match *arm_cspmu_impl_match_get(u32 pmiidr)
 static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
 {
 	int ret = 0;
-	struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(cspmu->dev);
 	struct arm_cspmu_impl_match *match;
 
 	/* Start with a default PMU implementation */
@@ -425,8 +429,12 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
 	};
 
 	/* Firmware may override implementer/product ID from PMIIDR */
-	if (apmt_node->impl_id)
-		cspmu->impl.pmiidr = apmt_node->impl_id;
+	if (has_acpi_companion(cspmu->dev)) {
+		struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(cspmu->dev);
+
+		if (apmt_node->impl_id)
+			cspmu->impl.pmiidr = apmt_node->impl_id;
+	}
 
 	/* Find implementer specific attribute ops. */
 	match = arm_cspmu_impl_match_get(cspmu->impl.pmiidr);
@@ -928,7 +936,6 @@ static void arm_cspmu_read(struct perf_event *event)
 
 static struct arm_cspmu *arm_cspmu_alloc(struct platform_device *pdev)
 {
-	struct acpi_apmt_node *apmt_node;
 	struct arm_cspmu *cspmu;
 	struct device *dev = &pdev->dev;
 
@@ -939,8 +946,13 @@ static struct arm_cspmu *arm_cspmu_alloc(struct platform_device *pdev)
 	cspmu->dev = dev;
 	platform_set_drvdata(pdev, cspmu);
 
-	apmt_node = arm_cspmu_apmt_node(dev);
-	cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
+	if (has_acpi_companion(dev)) {
+		struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(dev);
+
+		cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
+	} else {
+		cspmu->has_atomic_dword = device_property_read_bool(dev, "arm,64-bit-atomic");
+	}
 
 	return cspmu;
 }
@@ -1133,11 +1145,6 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
 		}
 	}
 
-	if (cpumask_empty(&cspmu->associated_cpus)) {
-		dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
-		return -ENODEV;
-	}
-
 	return 0;
 }
 #else
@@ -1147,9 +1154,36 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
 }
 #endif
 
+static int arm_cspmu_of_get_cpus(struct arm_cspmu *cspmu)
+{
+	struct of_phandle_iterator it;
+	int ret, cpu;
+
+	of_for_each_phandle(&it, ret, cspmu->dev->of_node, "cpus", NULL, 0) {
+		cpu = of_cpu_node_to_id(it.node);
+		if (cpu < 0)
+			continue;
+		cpumask_set_cpu(cpu, &cspmu->associated_cpus);
+	}
+	return ret;
+}
+
 static int arm_cspmu_get_cpus(struct arm_cspmu *cspmu)
 {
-	return arm_cspmu_acpi_get_cpus(cspmu);
+	int ret = 0;
+
+	if (has_acpi_companion(cspmu->dev))
+		ret = arm_cspmu_acpi_get_cpus(cspmu);
+	else if (of_property_present(cspmu->dev->of_node, "cpus"))
+		ret = arm_cspmu_of_get_cpus(cspmu);
+	else
+		cpumask_copy(&cspmu->associated_cpus, cpu_possible_mask);
+
+	if (!ret && cpumask_empty(&cspmu->associated_cpus)) {
+		dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
+		ret = -ENODEV;
+	}
+	return ret;
 }
 
 static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
@@ -1246,11 +1280,18 @@ static const struct platform_device_id arm_cspmu_id[] = {
 };
 MODULE_DEVICE_TABLE(platform, arm_cspmu_id);
 
+static const struct of_device_id arm_cspmu_of_match[] = {
+	{ .compatible = "arm,coresight-pmu" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, arm_cspmu_of_match);
+
 static struct platform_driver arm_cspmu_driver = {
 	.driver = {
-			.name = DRVNAME,
-			.suppress_bind_attrs = true,
-		},
+		.name = DRVNAME,
+		.of_match_table = arm_cspmu_of_match,
+		.suppress_bind_attrs = true,
+	},
 	.probe = arm_cspmu_device_probe,
 	.remove = arm_cspmu_device_remove,
 	.id_table = arm_cspmu_id,
-- 
2.39.2.101.g768bb238c484.dirty



From broonie at kernel.org  Tue Dec  5 08:48:17 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:17 +0000
Subject: [PATCH v3 19/21] kselftest/arm64: Add 2023 DPISA hwcap test
 coverage
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-19-dbcbcd867a7f@kernel.org>

Add the hwcaps added for the 2023 DPISA extensions to the hwcaps test
program.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 tools/testing/selftests/arm64/abi/hwcap.c | 217 ++++++++++++++++++++++++++++++
 1 file changed, 217 insertions(+)

diff --git a/tools/testing/selftests/arm64/abi/hwcap.c b/tools/testing/selftests/arm64/abi/hwcap.c
index 1189e77c8152..d8909b2b535a 100644
--- a/tools/testing/selftests/arm64/abi/hwcap.c
+++ b/tools/testing/selftests/arm64/abi/hwcap.c
@@ -58,11 +58,46 @@ static void cssc_sigill(void)
 	asm volatile(".inst 0xdac01c00" : : : "x0");
 }
 
+static void f8cvt_sigill(void)
+{
+	/* FSCALE V0.4H, V0.4H, V0.4H */
+	asm volatile(".inst 0x2ec03c00");
+}
+
+static void f8dp2_sigill(void)
+{
+	/* FDOT V0.4H, V0.4H, V0.5H */
+	asm volatile(".inst 0xe40fc00");
+}
+
+static void f8dp4_sigill(void)
+{
+	/* FDOT V0.2S, V0.2S, V0.2S */
+	asm volatile(".inst 0xe00fc00");
+}
+
+static void f8fma_sigill(void)
+{
+	/* FMLALB V0.8H, V0.16B, V0.16B */
+	asm volatile(".inst 0xec0fc00");
+}
+
+static void faminmax_sigill(void)
+{
+	/* FAMIN V0.4H, V0.4H, V0.4H */
+	asm volatile(".inst 0x2ec01c00");
+}
+
 static void fp_sigill(void)
 {
 	asm volatile("fmov s0, #1");
 }
 
+static void fpmr_sigill(void)
+{
+	asm volatile("mrs x0, S3_3_C4_C4_2" : : : "x0");
+}
+
 static void ilrcpc_sigill(void)
 {
 	/* LDAPUR W0, [SP, #8] */
@@ -95,6 +130,12 @@ static void lse128_sigill(void)
 		     : "cc", "memory");
 }
 
+static void lut_sigill(void)
+{
+	/* LUTI2 V0.16B, { V0.16B }, V[0] */
+	asm volatile(".inst 0x4e801000");
+}
+
 static void mops_sigill(void)
 {
 	char dst[1], src[1];
@@ -216,6 +257,78 @@ static void smef16f16_sigill(void)
 	asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
 }
 
+static void smef8f16_sigill(void)
+{
+	/* SMSTART */
+	asm volatile("msr S0_3_C4_C7_3, xzr" : : : );
+
+	/* FDOT ZA.H[W0, 0], Z0.B-Z1.B, Z0.B-Z1.B */
+	asm volatile(".inst 0xc1a01020" : : : );
+
+	/* SMSTOP */
+	asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
+}
+
+static void smef8f32_sigill(void)
+{
+	/* SMSTART */
+	asm volatile("msr S0_3_C4_C7_3, xzr" : : : );
+
+	/* FDOT ZA.S[W0, 0], { Z0.B-Z1.B }, Z0.B[0] */
+	asm volatile(".inst 0xc1500038" : : : );
+
+	/* SMSTOP */
+	asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
+}
+
+static void smelutv2_sigill(void)
+{
+	/* SMSTART */
+	asm volatile("msr S0_3_C4_C7_3, xzr" : : : );
+
+	/* LUTI4 { Z0.B-Z3.B }, ZT0, { Z0-Z1 } */
+	asm volatile(".inst 0xc08b0000" : : : );
+
+	/* SMSTOP */
+	asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
+}
+
+static void smesf8dp2_sigill(void)
+{
+	/* SMSTART */
+	asm volatile("msr S0_3_C4_C7_3, xzr" : : : );
+
+	/* FDOT Z0.H, Z0.B, Z0.B[0] */
+	asm volatile(".inst 0x64204400" : : : );
+
+	/* SMSTOP */
+	asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
+}
+
+static void smesf8dp4_sigill(void)
+{
+	/* SMSTART */
+	asm volatile("msr S0_3_C4_C7_3, xzr" : : : );
+
+	/* FDOT Z0.S, Z0.B, Z0.B[0] */
+	asm volatile(".inst 0xc1a41C00" : : : );
+
+	/* SMSTOP */
+	asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
+}
+
+static void smesf8fma_sigill(void)
+{
+	/* SMSTART */
+	asm volatile("msr S0_3_C4_C7_3, xzr" : : : );
+
+	/* FMLALB V0.8H, V0.16B, V0.16B */
+	asm volatile(".inst 0xec0fc00");
+
+	/* SMSTOP */
+	asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
+}
+
 static void sve_sigill(void)
 {
 	/* RDVL x0, #0 */
@@ -353,6 +466,53 @@ static const struct hwcap_data {
 		.cpuinfo = "cssc",
 		.sigill_fn = cssc_sigill,
 	},
+	{
+		.name = "F8CVT",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_F8CVT,
+		.cpuinfo = "f8cvt",
+		.sigill_fn = f8cvt_sigill,
+	},
+	{
+		.name = "F8DP4",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_F8DP4,
+		.cpuinfo = "f8dp4",
+		.sigill_fn = f8dp4_sigill,
+	},
+	{
+		.name = "F8DP2",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_F8DP2,
+		.cpuinfo = "f8dp4",
+		.sigill_fn = f8dp2_sigill,
+	},
+	{
+		.name = "F8E5M2",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_F8E5M2,
+		.cpuinfo = "f8e5m2",
+	},
+	{
+		.name = "F8E4M3",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_F8E4M3,
+		.cpuinfo = "f8e4m3",
+	},
+	{
+		.name = "F8FMA",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_F8FMA,
+		.cpuinfo = "f8fma",
+		.sigill_fn = f8fma_sigill,
+	},
+	{
+		.name = "FAMINMAX",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_FAMINMAX,
+		.cpuinfo = "faminmax",
+		.sigill_fn = faminmax_sigill,
+	},
 	{
 		.name = "FP",
 		.at_hwcap = AT_HWCAP,
@@ -360,6 +520,14 @@ static const struct hwcap_data {
 		.cpuinfo = "fp",
 		.sigill_fn = fp_sigill,
 	},
+	{
+		.name = "FPMR",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_FPMR,
+		.cpuinfo = "fpmr",
+		.sigill_fn = fpmr_sigill,
+		.sigill_reliable = true,
+	},
 	{
 		.name = "JSCVT",
 		.at_hwcap = AT_HWCAP,
@@ -411,6 +579,13 @@ static const struct hwcap_data {
 		.cpuinfo = "lse128",
 		.sigill_fn = lse128_sigill,
 	},
+	{
+		.name = "LUT",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_LUT,
+		.cpuinfo = "lut",
+		.sigill_fn = lut_sigill,
+	},
 	{
 		.name = "MOPS",
 		.at_hwcap = AT_HWCAP2,
@@ -511,6 +686,48 @@ static const struct hwcap_data {
 		.cpuinfo = "smef16f16",
 		.sigill_fn = smef16f16_sigill,
 	},
+	{
+		.name = "SME F8F16",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_SME_F8F16,
+		.cpuinfo = "smef8f16",
+		.sigill_fn = smef8f16_sigill,
+	},
+	{
+		.name = "SME F8F32",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_SME_F8F32,
+		.cpuinfo = "smef8f32",
+		.sigill_fn = smef8f32_sigill,
+	},
+	{
+		.name = "SME LUTV2",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_SME_LUTV2,
+		.cpuinfo = "smelutv2",
+		.sigill_fn = smelutv2_sigill,
+	},
+	{
+		.name = "SME SF8FMA",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_SME_SF8FMA,
+		.cpuinfo = "smesf8fma",
+		.sigill_fn = smesf8fma_sigill,
+	},
+	{
+		.name = "SME SF8DP2",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_SME_SF8DP2,
+		.cpuinfo = "smesf8dp2",
+		.sigill_fn = smesf8dp2_sigill,
+	},
+	{
+		.name = "SME SF8DP4",
+		.at_hwcap = AT_HWCAP2,
+		.hwcap_bit = HWCAP2_SME_SF8DP4,
+		.cpuinfo = "smesf8dp4",
+		.sigill_fn = smesf8dp4_sigill,
+	},
 	{
 		.name = "SVE",
 		.at_hwcap = AT_HWCAP,

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:18 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:18 +0000
Subject: [PATCH v3 20/21] KVM: arm64: selftests: Document feature registers
 added in 2023 extensions
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-20-dbcbcd867a7f@kernel.org>

The 2023 architecture extensions allocated some previously usused feature
registers, add comments mapping the names in get-reg-list as we do for the
other allocated registers.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 tools/testing/selftests/kvm/aarch64/get-reg-list.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index 709d7d721760..71ea6ecec7ce 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -428,7 +428,7 @@ static __u64 base_regs[] = {
 	ARM64_SYS_REG(3, 0, 0, 4, 4),	/* ID_AA64ZFR0_EL1 */
 	ARM64_SYS_REG(3, 0, 0, 4, 5),	/* ID_AA64SMFR0_EL1 */
 	ARM64_SYS_REG(3, 0, 0, 4, 6),
-	ARM64_SYS_REG(3, 0, 0, 4, 7),
+	ARM64_SYS_REG(3, 0, 0, 4, 7),	/* ID_AA64FPFR_EL1 */
 	ARM64_SYS_REG(3, 0, 0, 5, 0),	/* ID_AA64DFR0_EL1 */
 	ARM64_SYS_REG(3, 0, 0, 5, 1),	/* ID_AA64DFR1_EL1 */
 	ARM64_SYS_REG(3, 0, 0, 5, 2),
@@ -440,7 +440,7 @@ static __u64 base_regs[] = {
 	ARM64_SYS_REG(3, 0, 0, 6, 0),	/* ID_AA64ISAR0_EL1 */
 	ARM64_SYS_REG(3, 0, 0, 6, 1),	/* ID_AA64ISAR1_EL1 */
 	ARM64_SYS_REG(3, 0, 0, 6, 2),	/* ID_AA64ISAR2_EL1 */
-	ARM64_SYS_REG(3, 0, 0, 6, 3),
+	ARM64_SYS_REG(3, 0, 0, 6, 3),	/* ID_AA64ISAR3_EL1 */
 	ARM64_SYS_REG(3, 0, 0, 6, 4),
 	ARM64_SYS_REG(3, 0, 0, 6, 5),
 	ARM64_SYS_REG(3, 0, 0, 6, 6),

-- 
2.30.2



From broonie at kernel.org  Tue Dec  5 08:48:19 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 05 Dec 2023 16:48:19 +0000
Subject: [PATCH v3 21/21] KVM: arm64: selftests: Teach get-reg-list about
 FPMR
In-Reply-To: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
Message-ID: <20231205-arm64-2023-dpisa-v3-21-dbcbcd867a7f@kernel.org>

FEAT_FPMR defines a new register FMPR which is available at all ELs and is
discovered via ID_AA64PFR2_EL1.FPMR, add this to the set of registers that
get-reg-list knows to check for with the required identification register
depdendency.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 tools/testing/selftests/kvm/aarch64/get-reg-list.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index 71ea6ecec7ce..1e43511d1440 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -40,6 +40,12 @@ static struct feature_id_reg feat_id_regs[] = {
 		ARM64_SYS_REG(3, 0, 0, 7, 3),	/* ID_AA64MMFR3_EL1 */
 		4,
 		1
+	},
+	{
+		ARM64_SYS_REG(3, 3, 4, 4, 2),	/* FPMR */
+		ARM64_SYS_REG(3, 0, 0, 4, 2),	/* ID_AA64PFR2_EL1 */
+		32,
+		1
 	}
 };
 
@@ -481,6 +487,7 @@ static __u64 base_regs[] = {
 	ARM64_SYS_REG(3, 3, 14, 2, 1),	/* CNTP_CTL_EL0 */
 	ARM64_SYS_REG(3, 3, 14, 2, 2),	/* CNTP_CVAL_EL0 */
 	ARM64_SYS_REG(3, 4, 3, 0, 0),	/* DACR32_EL2 */
+	ARM64_SYS_REG(3, 3, 4, 4, 2),	/* FPMR */
 	ARM64_SYS_REG(3, 4, 5, 0, 1),	/* IFSR32_EL2 */
 	ARM64_SYS_REG(3, 4, 5, 3, 0),	/* FPEXC32_EL2 */
 };

-- 
2.30.2



From conor at kernel.org  Tue Dec  5 08:55:42 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 5 Dec 2023 16:55:42 +0000
Subject: [PATCH v1 1/3] dt-bindings: drm: rockchip: convert
 inno_hdmi-rockchip.txt to yaml
In-Reply-To: <3331543a-73fb-3565-47c6-d3303c44ba21@gmail.com>
References: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
 <3f235189-da75-4e9d-ad68-8cbebca12f6d@gmail.com>
 <3331543a-73fb-3565-47c6-d3303c44ba21@gmail.com>
Message-ID: <20231205-agency-paralyses-2a7b6df25c66@spud>

On Mon, Dec 04, 2023 at 09:47:15PM +0100, Johan Jonker wrote:
> On 12/4/23 19:56, Alex Bee wrote:
> > Am 04.12.23 um 18:39 schrieb Johan Jonker:
> >> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> >> new file mode 100644
> >> index 000000000000..96889c86849a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> >> @@ -0,0 +1,103 @@
> >> +# SPDX-License-Identifier: GPL-2.0
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/display/rockchip/rockchip,inno-hdmi.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Rockchip Innosilicon HDMI controller
> >> +
> >> +maintainers:
> >> +? - Sandy Huang <hjc at rock-chips.com>
> >> +? - Heiko Stuebner <heiko at sntech.de>
> >> +
> >> +properties:
> >> +? compatible:
> >> +??? enum:
> >> +????? - rockchip,rk3036-inno-hdmi
> >> +
> >> +? reg:
> >> +??? maxItems: 1
> >> +
> >> +? interrupts:
> >> +??? maxItems: 1
> >> +
> >> +? clocks:
> >> +??? maxItems: 1
> 
> > The interrupts/clock description exists already in the txt-bindings - so how about:
> > 
> > +??? items:
> > +????? - descrition: ....
> >> +
> 
> It's not common to do so when there's only one clock and nothing special to mention.
> Used this style for most of my conversions. 
> Further rational might be given by Krzysztof and co.

Ye, when there is no ambiguity, having the description is not
required.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/a6d09f0f/attachment.sig>

From broonie at kernel.org  Tue Dec  5 08:56:51 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 5 Dec 2023 16:56:51 +0000
Subject: [PATCH] arm64: Delete the zero_za macro
In-Reply-To: <20231205160140.1438-1-yuzenghui@huawei.com>
References: <20231205160140.1438-1-yuzenghui@huawei.com>
Message-ID: <953cf17b-9476-4215-8c33-b4175a331181@sirena.org.uk>

On Wed, Dec 06, 2023 at 12:01:40AM +0800, Zenghui Yu wrote:
> zero_za was introduced in commit ca8a4ebcff44 ("arm64/sme: Manually encode
> SME instructions") but doesn't appear to have any in kernel user. Drop it.
> 
> Signed-off-by: Zenghui Yu <yuzenghui at huawei.com>

You're right that this isn't used, though OTOH it's not exactly doing
any harm either and as a macro doesn't inflate the image or anything.

Acked-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/957c0934/attachment.sig>

From david at redhat.com  Tue Dec  5 08:57:58 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 17:57:58 +0100
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <20231204102027.57185-4-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
Message-ID: <004ed23d-5571-4474-b7fe-7bc08817c165@redhat.com>

On 04.12.23 11:20, Ryan Roberts wrote:
> In preparation for adding support for anonymous multi-size THP,
> introduce new sysfs structure that will be used to control the new
> behaviours. A new directory is added under transparent_hugepage for each
> supported THP size, and contains an `enabled` file, which can be set to
> "inherit" (to inherit the global setting), "always", "madvise" or
> "never". For now, the kernel still only supports PMD-sized anonymous
> THP, so only 1 directory is populated.
> 
> The first half of the change converts transhuge_vma_suitable() and
> hugepage_vma_check() so that they take a bitfield of orders for which
> the user wants to determine support, and the functions filter out all
> the orders that can't be supported, given the current sysfs
> configuration and the VMA dimensions. If there is only 1 order set in
> the input then the output can continue to be treated like a boolean;
> this is the case for most call sites. The resulting functions are
> renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
> respectively.
> 
> The second half of the change implements the new sysfs interface. It has
> been done so that each supported THP size has a `struct thpsize`, which
> describes the relevant metadata and is itself a kobject. This is pretty
> minimal for now, but should make it easy to add new per-thpsize files to
> the interface if needed in future (e.g. per-size defrag). Rather than
> keep the `enabled` state directly in the struct thpsize, I've elected to
> directly encode it into huge_anon_orders_[always|madvise|inherit]
> bitfields since this reduces the amount of work required in
> thp_vma_allowable_orders() which is called for every page fault.
> 
> See Documentation/admin-guide/mm/transhuge.rst, as modified by this
> commit, for details of how the new sysfs interface works.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---

Some comments mostly regarding thp_vma_allowable_orders and friends. In 
general, LGTM. I'll have to go over the order logic once again, I got a 
bit lost once we started mixing anon and file orders.

[...]

Doc updates all looked good to me, skimming over them.

> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index fa0350b0812a..bd0eadd3befb 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h

[...]

> +static inline unsigned long thp_vma_suitable_orders(struct vm_area_struct *vma,
> +		unsigned long addr, unsigned long orders)
> +{
> +	int order;
> +
> +	/*
> +	 * Iterate over orders, highest to lowest, removing orders that don't
> +	 * meet alignment requirements from the set. Exit loop at first order
> +	 * that meets requirements, since all lower orders must also meet
> +	 * requirements.
> +	 */
> +
> +	order = first_order(orders);

nit: "highest_order" or "largest_order" would be more expressive 
regarding the actual semantics.

> +
> +	while (orders) {
> +		unsigned long hpage_size = PAGE_SIZE << order;
> +		unsigned long haddr = ALIGN_DOWN(addr, hpage_size);
> +
> +		if (haddr >= vma->vm_start &&
> +		    haddr + hpage_size <= vma->vm_end) {
> +			if (!vma_is_anonymous(vma)) {
> +				if (IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) -
> +						vma->vm_pgoff,
> +						hpage_size >> PAGE_SHIFT))
> +					break;
> +			} else
> +				break;

Comment: Codying style wants you to use if () {} else {}

But I'd recommend for the conditions:

if (haddr < vma->vm_start ||
     haddr + hpage_size > vma->vm_end)
	continue;
/* Don't have to check pgoff for anonymous vma */
if (!vma_is_anonymous(vma))
	break;
if (IS_ALIGNED((...
	break;

[...]


> +/**
> + * thp_vma_allowable_orders - determine hugepage orders that are allowed for vma
> + * @vma:  the vm area to check
> + * @vm_flags: use these vm_flags instead of vma->vm_flags
> + * @smaps: whether answer will be used for smaps file
> + * @in_pf: whether answer will be used by page fault handler
> + * @enforce_sysfs: whether sysfs config should be taken into account
> + * @orders: bitfield of all orders to consider
> + *
> + * Calculates the intersection of the requested hugepage orders and the allowed
> + * hugepage orders for the provided vma. Permitted orders are encoded as a set
> + * bit at the corresponding bit position (bit-2 corresponds to order-2, bit-3
> + * corresponds to order-3, etc). Order-0 is never considered a hugepage order.
> + *
> + * Return: bitfield of orders allowed for hugepage in the vma. 0 if no hugepage
> + * orders are allowed.
> + */
> +unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
> +				       unsigned long vm_flags, bool smaps,
> +				       bool in_pf, bool enforce_sysfs,
> +				       unsigned long orders)
> +{
> +	/* Check the intersection of requested and supported orders. */
> +	orders &= vma_is_anonymous(vma) ?
> +			THP_ORDERS_ALL_ANON : THP_ORDERS_ALL_FILE;
> +	if (!orders)
> +		return 0;

Comment: if this is called from some hot path, we might want to move as 
much as possible into a header, so we can avoid this function call here 
when e.g., THP are completely disabled etc.

> +
>   	if (!vma->vm_mm)		/* vdso */
> -		return false;
> +		return 0;
>   
>   	/*
>   	 * Explicitly disabled through madvise or prctl, or some
> @@ -88,16 +141,16 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
>   	 * */
>   	if ((vm_flags & VM_NOHUGEPAGE) ||
>   	    test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
> -		return false;
> +		return 0;
>   	/*
>   	 * If the hardware/firmware marked hugepage support disabled.
>   	 */
>   	if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED))
> -		return false;
> +		return 0;
>   
>   	/* khugepaged doesn't collapse DAX vma, but page fault is fine. */
>   	if (vma_is_dax(vma))
> -		return in_pf;
> +		return in_pf ? orders : 0;
>   
>   	/*
>   	 * khugepaged special VMA and hugetlb VMA.
> @@ -105,17 +158,29 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
>   	 * VM_MIXEDMAP set.
>   	 */
>   	if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
> -		return false;
> +		return 0;
>   
>   	/*
> -	 * Check alignment for file vma and size for both file and anon vma.
> +	 * Check alignment for file vma and size for both file and anon vma by
> +	 * filtering out the unsuitable orders.
>   	 *
>   	 * Skip the check for page fault. Huge fault does the check in fault
> -	 * handlers. And this check is not suitable for huge PUD fault.
> +	 * handlers.
>   	 */
> -	if (!in_pf &&
> -	    !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
> -		return false;
> +	if (!in_pf) {
> +		int order = first_order(orders);
> +		unsigned long addr;
> +
> +		while (orders) {
> +			addr = vma->vm_end - (PAGE_SIZE << order);
> +			if (thp_vma_suitable_orders(vma, addr, BIT(order)))
> +				break;

Comment: you'd want a "thp_vma_suitable_order" helper here. But maybe 
the compiler is smart enough to optimize the loop and everyything else out.

[...]

> +
> +static ssize_t thpsize_enabled_store(struct kobject *kobj,
> +				     struct kobj_attribute *attr,
> +				     const char *buf, size_t count)
> +{
> +	int order = to_thpsize(kobj)->order;
> +	ssize_t ret = count;
> +
> +	if (sysfs_streq(buf, "always")) {
> +		set_bit(order, &huge_anon_orders_always);
> +		clear_bit(order, &huge_anon_orders_inherit);
> +		clear_bit(order, &huge_anon_orders_madvise);
> +	} else if (sysfs_streq(buf, "inherit")) {
> +		set_bit(order, &huge_anon_orders_inherit);
> +		clear_bit(order, &huge_anon_orders_always);
> +		clear_bit(order, &huge_anon_orders_madvise);
> +	} else if (sysfs_streq(buf, "madvise")) {
> +		set_bit(order, &huge_anon_orders_madvise);
> +		clear_bit(order, &huge_anon_orders_always);
> +		clear_bit(order, &huge_anon_orders_inherit);
> +	} else if (sysfs_streq(buf, "never")) {
> +		clear_bit(order, &huge_anon_orders_always);
> +		clear_bit(order, &huge_anon_orders_inherit);
> +		clear_bit(order, &huge_anon_orders_madvise);

Note: I was wondering for a second if some concurrent cames could lead 
to an inconsistent state. I think in the worst case we'll simply end up 
with "never" on races.

[...]

>   static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
>   {
>   	int err;
> +	struct thpsize *thpsize;
> +	unsigned long orders;
> +	int order;
> +
> +	/*
> +	 * Default to setting PMD-sized THP to inherit the global setting and
> +	 * disable all other sizes. powerpc's PMD_ORDER isn't a compile-time
> +	 * constant so we have to do this here.
> +	 */
> +	huge_anon_orders_inherit = BIT(PMD_ORDER);
>   
>   	*hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
>   	if (unlikely(!*hugepage_kobj)) {
> @@ -434,8 +631,24 @@ static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
>   		goto remove_hp_group;
>   	}
>   
> +	orders = THP_ORDERS_ALL_ANON;
> +	order = first_order(orders);
> +	while (orders) {
> +		thpsize = thpsize_create(order, *hugepage_kobj);
> +		if (IS_ERR(thpsize)) {
> +			pr_err("failed to create thpsize for order %d\n", order);
> +			err = PTR_ERR(thpsize);
> +			goto remove_all;
> +		}
> +		list_add(&thpsize->node, &thpsize_list);
> +		order = next_order(&orders, order);
> +	}
> +
>   	return 0;
>   

[...]

>   	page = compound_head(page);
> @@ -5116,7 +5116,8 @@ static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma,
>   		return VM_FAULT_OOM;
>   retry_pud:
>   	if (pud_none(*vmf.pud) &&
> -	    hugepage_vma_check(vma, vm_flags, false, true, true)) {
> +	    thp_vma_allowable_orders(vma, vm_flags, false, true, true,
> +				     BIT(PUD_ORDER))) {
>   		ret = create_huge_pud(&vmf);
>   		if (!(ret & VM_FAULT_FALLBACK))
>   			return ret;
> @@ -5150,7 +5151,8 @@ static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma,
>   		goto retry_pud;
>   
>   	if (pmd_none(*vmf.pmd) &&
> -	    hugepage_vma_check(vma, vm_flags, false, true, true)) {
> +	    thp_vma_allowable_orders(vma, vm_flags, false, true, true,
> +				     BIT(PMD_ORDER))) {

Comment: A helper like "thp_vma_allowable_order(vma, PMD_ORDER)" might 
make this easier to read -- and the implemenmtation will be faster.

>   		ret = create_huge_pmd(&vmf);
>   		if (!(ret & VM_FAULT_FALLBACK))
>   			return ret;
> diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
> index e0b368e545ed..64da127cc267 100644
> --- a/mm/page_vma_mapped.c
> +++ b/mm/page_vma_mapped.c
> @@ -268,7 +268,8 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
>   			 * cleared *pmd but not decremented compound_mapcount().
>   			 */
>   			if ((pvmw->flags & PVMW_SYNC) &&
> -			    transhuge_vma_suitable(vma, pvmw->address) &&
> +			    thp_vma_suitable_orders(vma, pvmw->address,
> +						    BIT(PMD_ORDER)) &&

Comment: Similarly, a helper like "thp_vma_suitable_order(vma, 
PMD_ORDER)" might make this easier to read.

>   			    (pvmw->nr_pages >= HPAGE_PMD_NR)) {
>   				spinlock_t *ptl = pmd_lock(mm, pvmw->pmd);
>   

-- 
Cheers,

David / dhildenb



From david at redhat.com  Tue Dec  5 09:00:11 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 18:00:11 +0100
Subject: [PATCH v8 05/10] selftests/mm/kugepaged: Restore thp settings at
 exit
In-Reply-To: <20231204102027.57185-6-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-6-ryan.roberts@arm.com>
Message-ID: <22992b35-c6b6-4fcd-bfba-01a5f99198cd@redhat.com>

On 04.12.23 11:20, Ryan Roberts wrote:
> Previously, the saved thp settings would be restored upon a signal or at
> the natural end of the test suite. But there are some tests that
> directly call exit() upon failure. In this case, the thp settings were
> not being restored, which could then influence other tests.
> 
> Fix this by installing an atexit() handler to do the actual restore. The
> signal handler can now just call exit() and the atexit handler is
> invoked.
> 
> Reviewed-by: Alistair Popple <apopple at nvidia.com>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>   tools/testing/selftests/mm/khugepaged.c | 17 +++++++++++------
>   1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
> index 030667cb5533..fc47a1c4944c 100644
> --- a/tools/testing/selftests/mm/khugepaged.c
> +++ b/tools/testing/selftests/mm/khugepaged.c
> @@ -374,18 +374,22 @@ static void pop_settings(void)
>   	write_settings(current_settings());
>   }
>   
> -static void restore_settings(int sig)
> +static void restore_settings_atexit(void)
>   {
>   	if (skip_settings_restore)
> -		goto out;
> +		return;
>   
>   	printf("Restore THP and khugepaged settings...");
>   	write_settings(&saved_settings);
>   	success("OK");
> -	if (sig)
> -		exit(EXIT_FAILURE);
> -out:
> -	exit(exit_status);
> +
> +	skip_settings_restore = true;
> +}
> +
> +static void restore_settings(int sig)
> +{
> +	/* exit() will invoke the restore_settings_atexit handler. */
> +	exit(sig ? EXIT_FAILURE : exit_status);
>   }
>   
>   static void save_settings(void)
> @@ -415,6 +419,7 @@ static void save_settings(void)
>   
>   	success("OK");
>   
> +	atexit(restore_settings_atexit);
>   	signal(SIGTERM, restore_settings);
>   	signal(SIGINT, restore_settings);
>   	signal(SIGHUP, restore_settings);

Reviewed-by: David Hildenbrand <david at redhat.com>

Might similarly come in handy for the cow tests. Can be done later.

-- 
Cheers,

David / dhildenb



From maz at kernel.org  Tue Dec  5 09:01:28 2023
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 05 Dec 2023 17:01:28 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
In-Reply-To: <20231205164318.GG2692119@nvidia.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
	<86fs0hatt3.wl-maz@kernel.org>
	<ZW8MP2tDt4_9ROBz@arm.com>
	<20231205130517.GD2692119@nvidia.com>
	<ZW9OSe8Z9gAmM7My@arm.com>
	<20231205164318.GG2692119@nvidia.com>
Message-ID: <86bkb4bn2v.wl-maz@kernel.org>

On Tue, 05 Dec 2023 16:43:18 +0000,
Jason Gunthorpe <jgg at nvidia.com> wrote:
> 
> On Tue, Dec 05, 2023 at 04:22:33PM +0000, Catalin Marinas wrote:

> > That's an argument to restrict this feature to PCIe. It's really about
> > fewer arguments on the behaviour of other devices. Marc did raise
> > another issue with the GIC VCPU interface (does this even have a vma in
> > the host VMM?). That's a class of devices where the mapping is
> > context-switched, so the TLBI+DSB rules don't help.

There is no vma. The CPU interface is entirely under control of KVM.
Userspace only provides the IPA for the mapping.

> 
> I don't know anything about the GIC VCPU interface, to give any
> comment unfortunately. Since it seems there is something to fix here I
> would appreciate some background..
>  
> When you say it is context switched do you mean kvm does a register
> write on every vm entry to set the proper HW context for the vCPU?

The CPU interface is mapped in every guest S2 page tables as a per-CPU
device, and under complete control of the guest. There is no KVM
register write to that frame (unless we're proxying it, but that's for
another day).

> 
> We are worrying that register write will possibly not order after
> NORMAL_NC?

Guest maps the device as Normal-NC (because it now can), which means
that there is no control over the alignment or anything like that. The
accesses could also be reordered, and/or hit after a context switch to
another guest. Which is why KVM has so far used nGnRE as the mapping
type.

	M.

-- 
Without deviation from the norm, progress is not possible.


From david at redhat.com  Tue Dec  5 09:03:13 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 18:03:13 +0100
Subject: [PATCH v8 06/10] selftests/mm: Factor out thp settings management
In-Reply-To: <20231204102027.57185-7-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-7-ryan.roberts@arm.com>
Message-ID: <595f8ac8-01af-4808-b2b0-5688e590301a@redhat.com>

On 04.12.23 11:20, Ryan Roberts wrote:
> The khugepaged test has a useful framework for save/restore/pop/push of
> all thp settings via the sysfs interface. This will be useful to
> explicitly control multi-size THP settings in other tests, so let's
> move it out of khugepaged and into its own thp_settings.[c|h] utility.
> 
> Tested-by: Alistair Popple <apopple at nvidia.com>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---

[...]

Looks handy

Acked-by: David Hildenbrand <david at redhat.com>

-- 
Cheers,

David / dhildenb



From dianders at chromium.org  Tue Dec  5 09:06:29 2023
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 5 Dec 2023 09:06:29 -0800
Subject: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <653b592b-bd6a-48f8-acca-c617c5c8c1a3@pengutronix.de>
References: <20231129172200.430674-1-sjg@chromium.org> <20231129172200.430674-3-sjg@chromium.org>
 <30f32467-51ea-47de-a272-38e074f4060b@pengutronix.de> <CAPnjgZ25xoXsi74XYY0E8ucQiowQqPdZgUHrfVNAYWKZEYODHg@mail.gmail.com>
 <875f0dbc-1d78-4901-91b2-6ad152bcea5a@pengutronix.de> <CAPnjgZ0UCkm5QCx+JXe1ggSshozPnOLB6cN=UoJyMn6S4wfFkg@mail.gmail.com>
 <06281f7c-e0f2-405c-95a9-0f7e9e84a7f6@pengutronix.de> <CAPnjgZ2TT+0BvbjwfnGLQ3EPEXnLW6f1epiFdaBHRYaSAn5xsA@mail.gmail.com>
 <8fbc81b1-31ab-46b0-87f4-b8bd8e8e2b47@pengutronix.de> <CAPnjgZ1iyxk0bb56QR10N5aSphRYhLsw7Ly=z2i6rQCxP_AYPw@mail.gmail.com>
 <5e8f42f8-2b03-4033-b6d2-9b3139f081d5@pengutronix.de> <CAPnjgZ2RjNzqJTRZSWvuscQhs+f8CG=fDcEO=qKXNeQLP53LnQ@mail.gmail.com>
 <CAD=FV=WXQrbnjeVOLp--vmLzScvW9VLFRu+apSY4WnL9JFk-AQ@mail.gmail.com> <653b592b-bd6a-48f8-acca-c617c5c8c1a3@pengutronix.de>
Message-ID: <CAD=FV=WXCqhKpWp9mCqW+Dxv8pAUv+K9_8i-YfNGmWW4yr5Ghw@mail.gmail.com>

Hi,

On Tue, Dec 5, 2023 at 3:16?AM Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
>
> Hello,
>
> On 04.12.23 18:52, Doug Anderson wrote:> On Sat, Dec 2, 2023 at 8:37?AM Simon Glass <sjg at chromium.org> wrote:
> >> On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> >>> On 30.11.23 21:30, Simon Glass wrote:
> >>>> On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> >>>>> On 29.11.23 20:44, Simon Glass wrote:
> >>>> I don't have an example to hand, but this is the required mechanism of
> >>>> FIT. This feature has been in place for many years and is used by
> >>>> ChromeOS, at least.
> >>>
> >>> I see the utility of a FIT configuration with
> >>>
> >>>     compatible = "vendor,board-rev-a", "vendor,board-rev-b";
> >>>
> >>> I fail to see a utility for a configuration with
> >>>
> >>>     compatible = "vendor,board", "vendor,SoM", "vendor,SoC";
> >>>
> >>> Any configuration that ends up being booted because "vendor,SoC" was matched is
> >>> most likely doomed to fail. Therefore, I would suggest that only the top level
> >>> configuration is written into the FIT configurations automatically.
> >>
> >> Firstly, I am not an expert on this.
> >>
> >> Say you have a board with variants. The compatible string in U-Boot
> >> may be something like:
> >>
> >> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
> >> "rockchip,rk3288";
> >>
> >> If you then have several FIT configurations, they may be something like:
> >>
> >> "google,veyron-brain-rev0", "google,veyron-brain", "google,veyron",
> >> "rockchip,rk3288";
> >> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
> >> "rockchip,rk3288";
> >> "google,veyron-brain-rev2", "google,veyron-brain", "google,veyron",
> >> "rockchip,rk3288";
> >>
> >> You want to choose the second one, since it is a better match than the others.
>
> Now imagine, you are building a kernel that has no DT support for the Veyron,
> but instead has support for the Phytec RK3288 PCM-947:
>
>   phytec,rk3288-pcm-947", "phytec,rk3288-phycore-som", "rockchip,rk3288
>
> As far as I understand U-Boot code, A veyron U-Boot would boot the Phytec DT
> if CONFIG_FIT_BEST_MATCH is set, although it's a bad match and a boot failure
> should rather have occurred.

On depthcharge the bootloader never matches on just a SoC name.


> >> +Doug Anderson who knows a lot more about this than me.
> >
> > Hopefully this is all explained by:
> >
> > https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html
>
> Thanks Doug, this was helpful. The missing information to me was that
> depthcharge only compares the top-level board compatible in addition
> to runtime generated board compatibles, unlike what U-Boot seems to do.
>
> barebox only compares its top-level compatible against the FIT configuration
> compatibles, so adding a full compatible list to the configuration nodes as done
> by this series should be ok there as well. I think U-Boot could run into
> issues though as described above.
>
> Out of curiosity: I only heard about Depthcharge before as exploitation toolkit
> for U-Boot. Can you point me at some documentation on what the Depthcharge bootloader
> does what U-Boot (which was presumably used before?) doesn't?

I can only assume that the depthcharge you're talking about is
different. The one used by Chromebooks is basically:

https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/main

I assume you're asking: why are we using depthcharge in ChromeOS
instead of U-Boot?

There was much discussion about this back in the day. From what I
recall, part of the reason was that folks wanted the boot flow to be a
bit more standard between x86 Chromebooks and ARM Chromebooks. x86
Chromebooks were using coreboot for the initial hardware booting and
then needed a 2nd stage to actually load Linux and ended up creating
depthcharge. ...and then we switched to the same model for ARM boards.

I didn't personally make that decision and I'm also not on the
firmware team, so that's about all I'll say on the topic. ;-)

Oh, hmmm. Searching found me:

https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/custom-firmware/

...which pointed at:

https://www.chromium.org/chromium-os/2014-firmware-summit/ChromeOS%20firmware%20summit%20-%20Depthcharge.pdf

-Doug


From jgg at nvidia.com  Tue Dec  5 09:10:24 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 13:10:24 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZW9OtrUa_fPA0_Ns@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW81mT4WqKqtLnid@lpieralisi>
 <20231205144417.GE2692119@nvidia.com>
 <ZW9OtrUa_fPA0_Ns@arm.com>
Message-ID: <20231205171024.GH2692119@nvidia.com>

On Tue, Dec 05, 2023 at 04:24:22PM +0000, Catalin Marinas wrote:
> On Tue, Dec 05, 2023 at 10:44:17AM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 05, 2023 at 03:37:13PM +0100, Lorenzo Pieralisi wrote:
> > > On Tue, Dec 05, 2023 at 09:05:17AM -0400, Jason Gunthorpe wrote:
> > > > On Tue, Dec 05, 2023 at 11:40:47AM +0000, Catalin Marinas wrote:
> > > > > > - Will had unanswered questions in another part of the thread:
> > > > > > 
> > > > > >   https://lore.kernel.org/all/20231013092954.GB13524 at willie-the-truck/
> > > > > > 
> > > > > >   Can someone please help concluding it?
> > > > > 
> > > > > Is this about reclaiming the device? I think we concluded that we can't
> > > > > generalise this beyond PCIe, though not sure there was any formal
> > > > > statement to that thread. The other point Will had was around stating
> > > > > in the commit message why we only relax this to Normal NC. I haven't
> > > > > checked the commit message yet, it needs careful reading ;).
> > > > 
> > > > Not quite, we said reclaiming is VFIO's problem and if VFIO can't
> > > > reliably reclaim a device it shouldn't create it in the first place.
> > > 
> > > I think that as far as device reclaiming was concerned the question
> > > posed was related to memory attributes of transactions for guest
> > > mappings and the related grouping/ordering with device reset MMIO
> > > transactions - it was not (or wasn't only) about error containment.
> > 
> > Yes. It is VFIO that issues the reset, it is VFIO that must provide
> > the ordering under the assumption that NORMAL_NC was used.
> 
> And does it? Because VFIO so far only assumes Device-nGnRnE. Do we need
> to address this first before attempting to change KVM? Sorry, just
> questions, trying to clear the roadblocks.

There is no way to know. It is SOC specific what would be needed.

Could people have implemented their platform devices with a multi-path
bus architecture for the reset? Yes, definately. In fact, I've built
things like that. Low speed stuff like reset gets its own low speed
bus.

If that was done will NORMAL_NC vs DEVICE_nGnRnE make a difference?
I'm not sure. It depends a lot on how the SOC was designed and how
transactions flow on the high speed side. Posting writes, like PCIe
does, would destroy any practical ordering difference between the two
memory types. If the writes are not posted then the barriers in the
TLBI sequence should order it.

Fortunately, if some SOC has this issue we know how to solve it - you
must do flushing reads on all the multi-path interconnect segments to
serialize everything around the reset.

Regardless, getting this wrong is not a functional issue, it causes a
subtle time sensitive security race with VFIO close() that would be
hard to actually hit, and would already require privilege to open a
VFIO device to exploit. IOW, we don't care.

Jason


From bvanassche at acm.org  Tue Dec  5 09:11:56 2023
From: bvanassche at acm.org (Bart Van Assche)
Date: Tue, 5 Dec 2023 07:11:56 -1000
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
 <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>
Message-ID: <5e7c5c75-cb5f-4afe-9d57-b0cab01a6f26@acm.org>

On 12/4/23 21:58, Naresh Maramaina wrote:
> On 12/5/2023 12:30 AM, Bart Van Assche wrote:
>> On 12/4/23 06:30, Maramaina Naresh wrote:
>>> +??? /* This capability allows the host controller driver to use the 
>>> PM QoS
>>> +???? * feature.
>>> +???? */
>>> +??? UFSHCD_CAP_PM_QOS??????????????? = 1 << 13,
>>> ? };
>>
>> Why does it depend on the host driver whether or not PM QoS is
>> enabled? Why isn't it enabled unconditionally?
> 
> For some platform vendors power KPI might be more important than random 
> io KPI. Hence this flag is disabled by default and can be enabled based 
> on platform requirement.

How about leaving this flag out unless if a host vendor asks explicitly
for this flag?
>>
>>> + * @pm_qos_req: PM QoS request handle
>>> + * @pm_qos_init: flag to check if pm qos init completed
>>> ?? */
>>
>> Documentation for pm_qos_init is missing.
>>
> Sorry, i didn't get your comment, i have already added documentation for 
> @pm_qos_init, @pm_qos_req variable as above. Do you want me to add this 
> information some where else as well?

Oops, I meant 'qos_vote'.

Thanks,

Bart.



From sdf at google.com  Tue Dec  5 09:13:39 2023
From: sdf at google.com (Stanislav Fomichev)
Date: Tue, 5 Dec 2023 09:13:39 -0800
Subject: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC
In-Reply-To: <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com> <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
 <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
 <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com>
Message-ID: <CAKH8qBuXL8bOYtfKKPS8y=KJqouDptyciCjr0wNKVHtNj6BmqA@mail.gmail.com>

On Tue, Dec 5, 2023 at 7:34?AM Florian Bezdeka
<florian.bezdeka at siemens.com> wrote:
>
> On Tue, 2023-12-05 at 15:25 +0000, Song, Yoong Siang wrote:
> > On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote:
> > > Jesper Dangaard Brouer wrote:
> > > >
> > > >
> > > > On 12/3/23 17:51, Song Yoong Siang wrote:
> > > > > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > > > > copy via XDP Tx metadata framework.
> > > > >
> > > > > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > > > > ---
> > > > >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> > > >
> > > > As requested before, I think we need to see another driver implementing
> > > > this.
> > > >
> > > > I propose driver igc and chip i225.
> >
> > Sure. I will include igc patches in next version.
> >
> > > >
> > > > The interesting thing for me is to see how the LaunchTime max 1 second
> > > > into the future[1] is handled code wise. One suggestion is to add a
> > > > section to Documentation/networking/xsk-tx-metadata.rst per driver that
> > > > mentions/documents these different hardware limitations.  It is natural
> > > > that different types of hardware have limitations.  This is a close-to
> > > > hardware-level abstraction/API, and IMHO as long as we document the
> > > > limitations we can expose this API without too many limitations for more
> > > > capable hardware.
> >
> > Sure. I will try to add hardware limitations in documentation.
> >
> > >
> > > I would assume that the kfunc will fail when a value is passed that
> > > cannot be programmed.
> > >
> >
> > In current design, the xsk_tx_metadata_request() dint got return value.
> > So user won't know if their request is fail.
> > It is complex to inform user which request is failing.
> > Therefore, IMHO, it is good that we let driver handle the error silently.
> >
>
> If the programmed value is invalid, the packet will be "dropped" / will
> never make it to the wire, right?
>
> That is clearly a situation that the user should be informed about. For
> RT systems this normally means that something is really wrong regarding
> timing / cycle overflow. Such systems have to react on that situation.

In general, af_xdp is a bit lacking in this 'notify the user that they
somehow messed up' area :-(
For example, pushing a tx descriptor with a wrong addr/len in zc mode
will not give any visible signal back (besides driver potentially
spilling something into dmesg as it was in the mlx case).
We can probably start with having some counters for these events?


From catalin.marinas at arm.com  Tue Dec  5 09:21:27 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 5 Dec 2023 17:21:27 +0000
Subject: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64
In-Reply-To: <20231204182330.GK1493156@nvidia.com>
References: <cover.1700766072.git.leon@kernel.org>
 <c3ae87aea7660c3d266905c19d10d8de0f9fb779.1700766072.git.leon@kernel.org>
 <ZWB373y5XuZDultf@FVFF77S0Q05N>
 <20231124122352.GB436702@nvidia.com>
 <ZWSOwT2OyMXD1lmo@arm.com>
 <20231127134505.GI436702@nvidia.com>
 <ZW4NAzI_jvwoq8dL@arm.com>
 <20231204182330.GK1493156@nvidia.com>
Message-ID: <ZW9cF0ALVwgvcQMy@arm.com>

On Mon, Dec 04, 2023 at 02:23:30PM -0400, Jason Gunthorpe wrote:
> On Mon, Dec 04, 2023 at 05:31:47PM +0000, Catalin Marinas wrote:
> > Personally I'd optimise the mempcy_toio() arm64 implementation to do
> > STPs if the alignment is right (like we do for classic memcpy()).
> > There's a slight overhead for alignment checking but I suspect it would
> > be lost as long as you can get the write-combining. Not sure whether the
> > interspersed reads in memcpy_toio() would somehow prevent the
> > write-combining.
> 
> I understand on these new CPUs anything other than a block of
> contiguous STPs is risky to break the WC. I was told we should not
> have any loads between them.

Classic memcpy does similar tricks with four LDPs in a row before
starting to issue the STPs (though there are new LDPs for the next
data in-between). But that was tuned for cacheable memory, not sure
if something similar would behave well on Normal-NC memory.

> So we can't just update memcpy_toio to optimize a 128 bit store
> variant like memcpy might. We actually need a special case just for 64
> byte.
> 
> IMHO it does not look good as the chance any existing callers can use
> this optmized 64B path is probably small, but everyone has to pay the
> costs to check for it.

I don't think the cost of the check is noticeable and there are several
places where the copy goes beyond 64 bytes. It may be worth a try.

> I also would not do this on x86 - Pathscale apparently decided the
> needed special __iowrite*_copy() things to actually make this work on
> xome x86 systems - I'm very leary to change x86 stuff away from the 64
> bit copy loopw we know works already on x86.
> 
> IMHO encoding the alignment expectation in the API is best, especially
> since this is typically a performance path.

The slight downside of a __iowrite512_copy() API is that, if we follow
the 32/64 semantics, it would need the source buffer aligned. Maybe we
can document it to 64-bit alignment only rather than 512.

> > A memcpy_toio_64() can use the new ST64B instruction if available or
> > fall back to memcpy_toio() on arm64. It should also have the DGH
> > instruction (io_stop_wc()) but only if falling back to classic
> > memcpy_toio(). We don't need DGH with ST64B.
> 
> I'm told it is problematic, something about ST64B not working with
> NORMAL_NC.

Last time I checked it was meant to work on Normal-NC (not cacheable
though). That's on page 285 of the Arm ARM J.a.

> Also in a future ST64B world we are going to see HW start relying on
> large TLPs, not just being an optional performance win. To my mind it
> makes more sense that there is an API that guarantees a large TLP or
> oops. We really don't want an automatic fallback to memcpy.

We can't guarantee those large TLPs without the ST64B instructions, so
it needs to be more of a QoS aspect than correctness.

-- 
Catalin


From nathan at kernel.org  Tue Dec  5 09:21:33 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Tue, 5 Dec 2023 10:21:33 -0700
Subject: clang-nightly: vdso/compat_gettimeofday.h:152:15: error:
 instruction variant requires ARMv6 or later
In-Reply-To: <3523ca62-be8b-4b08-8d0c-5b97ece9aad8@debian.org>
References: <CA+G9fYvD72Vpfs2g8R+OJ6L8w9p_uaWbXpWMvnGAx_AOLabatw@mail.gmail.com>
 <20231204181304.GA2043538@dev-arch.thelio-3990X>
 <20231204223317.GA2053629@dev-arch.thelio-3990X>
 <36a25113-731c-4b28-a695-f3fbb0996d6e@app.fastmail.com>
 <20231205150417.GA349053@dev-arch.thelio-3990X>
 <3523ca62-be8b-4b08-8d0c-5b97ece9aad8@debian.org>
Message-ID: <20231205172133.GA462711@dev-arch.thelio-3990X>

On Tue, Dec 05, 2023 at 04:13:29PM +0100, Sylvestre Ledru wrote:
> Le 05/12/2023 ? 16:04, Nathan Chancellor a ?crit?:
> > On Tue, Dec 05, 2023 at 07:34:40AM +0100, Arnd Bergmann wrote:
> > > On Mon, Dec 4, 2023, at 23:33, Nathan Chancellor wrote:
> > > > On Mon, Dec 04, 2023 at 11:13:04AM -0700, Nathan Chancellor wrote:
> > > > 
> > > > > I am still investigating into what (if anything) can be done to resolve
> > > > > this on the kernel side. We could potentially revert commit
> > > > > ddc72c9659b5 ("kbuild: clang: do not use CROSS_COMPILE for target
> > > > > triple") but I am not sure that will save us from that change, as
> > > > > tuxmake's CROSS_COMPILE=arm-linux-gnueabihf will cause us to have an
> > > > > armv7 CPU even though we may not be building for armv7.
> > > > 
> > > > Okay, this is a pretty awful situation the more I look into it :(
> > > > 
> > > > The arm64 compat vDSO build is easy enough to fix because we require use
> > > > of the integrated assembler, which means we can add '-mcpu=generic' (the
> > > > default in LLVM for those files based on my debugging) to those files
> > > > and be done with it:
> > > > 
> > > > diff --git a/arch/arm64/kernel/vdso32/Makefile
> > > > b/arch/arm64/kernel/vdso32/Makefile
> > > > index 1f911a76c5af..5f5cb722cfc2 100644
> > > > --- a/arch/arm64/kernel/vdso32/Makefile
> > > > +++ b/arch/arm64/kernel/vdso32/Makefile
> > > > @@ -9,6 +9,10 @@ include $(srctree)/lib/vdso/Makefile
> > > >   ifeq ($(CONFIG_CC_IS_CLANG), y)
> > > >   CC_COMPAT ?= $(CC)
> > > >   CC_COMPAT += --target=arm-linux-gnueabi
> > > > +# Some distributions (such as Debian) change the default CPU for the
> > > > +# arm-linux-gnueabi target triple, which can break the build.
> > > > Explicitly set
> > > > +# the CPU to generic, which is the default for Linux in LLVM.
> > > > +CC_COMPAT += -mcpu=generic
> > > >   else
> > > >   CC_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc
> > > >   endif
> > > 
> > > I'm still trying to follow what is actually going on. I
> > > see that we pass
> > > 
> > > VDSO_CAFLAGS += -march=armv8-a
> > > 
> > > which is meant to tell the compiler that we want it to
> > > use ARMv8 compatible instructions. Is the problem that
> > > clang ignores this flag, or do we not pass it correctly?
> > > 
> > > I would have expected -march=armv8-a to be better than
> > > -mcpu=generic here, as it allows the compiler to use
> > > a wider set of instructions that is still guaranteed to
> > > be available on everything it will run on.
> > 
> > I should have made it clearer in that message that adding
> > '-mcpu=generic' was only to avoid the logic added by that Debian LLVM
> > change, not because I believe the kernel is doing something incorrectly
> > now. From what I could tell following through LLVM's code, '-march='
> > determines the default CPU, which is then used to further inform the
> > full target triple and by overriding the CPU where that patch did, it
> > was just blowing away the user's request. By providing an '-mcpu='
> > option explicitly, it would avoid the default selection logic and we
> > would get what we asked for.
> > 
> > > > Sylvestre, I strongly believe you should consider reverting that change
> > > > or give us some compiler flag that allows us to fallback to upstream
> > > > LLVM's default CPU selection logic. I think that hardcoding Debian's
> > > > architecture defintions based on the target triple into the compiler
> > > > could cause issues for other projects as well. For example,
> > > > '--target=arm-linux-gnueabi -march=armv7-a' won't actually target ARMv7:
> > > > 
> > > >    $ echo 'int main(void) { asm("dsb"); return 0; }' | \
> > > >          clang --target=arm-linux-gnueabi -march=armv7-a \
> > > >          -x c -c -o /dev/null -v -
> > > >    ...
> > > >     "/usr/bin/clang-17" -cc1 -triple armv7-unknown-linux-gnueabi ...
> > > >    ...
> > > > 
> > > > vs.
> > > > 
> > > >    $ echo 'int main(void) { asm("dsb"); return 0; }' | \
> > > >          clang --target=arm-linux-gnueabi -march=armv7-a \
> > > >          -x c -c -o /dev/null -v -
> > > >    ...
> > > >    "<prefix>/bin/clang-18" -cc1 -triple armv5e-unknown-linux-gnueabi ...
> > > >    ...
> > > 
> > > Right, the kernel definitely relies on -march= taking
> > > precedence over the default CPU, the same way that we
> > > tell the compiler to pick a non-default endianess or ABI.
> > 
> > Agreed, I have yet to test the new version of the patch but I see you
> > and Ard have given input on it, so hopefully it does not have any
> > problems like this.
> 
> Matthias, as cc, pushed a potential fix for debian/ubuntu packages!
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/01a06b481e5a2610c7387149b58978c3ec281f2c

Thanks, that version survives my basic testing of both ARCH=arm and
ARCH=arm64 defconfig. I'll holler if our full matrix explodes later (we
have another regression in LLVM right now so we are not testing the
snapshots daily at the moment).

Cheers,
Nathan


From david at redhat.com  Tue Dec  5 09:21:55 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 5 Dec 2023 18:21:55 +0100
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <20231204102027.57185-1-ryan.roberts@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
Message-ID: <8d5fdb17-c670-4814-8f48-4b90062668fc@redhat.com>

On 04.12.23 11:20, Ryan Roberts wrote:
> Hi All,
> 
> A new week, a new version, a new name... This is v8 of a series to implement
> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
> this fares better.
> 
> The objective of this is to improve performance by allocating larger chunks of
> memory during anonymous page faults:
> 
> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>     pages, there are efficiency savings to be had; fewer page faults, batched PTE
>     and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>     overhead. This should benefit all architectures.
> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>     advantage of HW TLB compression techniques. A reduction in TLB pressure
>     speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>     TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
> 
> This version changes the name and tidies up some of the kernel code and test
> code, based on feedback against v7 (see change log for details).
> 
> By default, the existing behaviour (and performance) is maintained. The user
> must explicitly enable multi-size THP to see the performance benefit. This is
> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
> David for the suggestion)! This interface is inspired by the existing
> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
> compatibility with the existing PMD-size THP interface, and provides a base for
> future extensibility. See [8] for detailed discussion of the interface.
> 
> This series is based on mm-unstable (715b67adf4c8).

I took a look at the core pieces. Some things might want some smaller 
tweaks, but nothing that should stop this from having fun in 
mm-unstable, and replacing the smaller things as we move forward.

-- 
Cheers,

David / dhildenb



From namhyung at kernel.org  Tue Dec  5 09:24:42 2023
From: namhyung at kernel.org (Namhyung Kim)
Date: Tue, 5 Dec 2023 09:24:42 -0800
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <ZW9G8Clxwl6bd0H6@kernel.org>
References: <20231204182330.654255-1-irogers@google.com> <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
 <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com> <ZW9G8Clxwl6bd0H6@kernel.org>
Message-ID: <CAM9d7ciOp_O5N1TDX0HyKavykirByAYrqzcmM-_6ZWjMv-47WQ@mail.gmail.com>

Hi Arnaldo,

On Tue, Dec 5, 2023 at 7:51?AM Arnaldo Carvalho de Melo <acme at kernel.org> wrote:
>
> Em Mon, Dec 04, 2023 at 07:33:18PM -0800, Namhyung Kim escreveu:
> > On Mon, Dec 4, 2023 at 2:45?PM Ilkka Koskinen <ilkka at os.amperecomputing.com> wrote:
> > > On Mon, 4 Dec 2023, Ian Rogers wrote:
> > > > A metric is default by having "Default" within its groups. The default
> > > > metricgroup name needn't be set and this can result in segv in
> > > > default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
> > > > that assume it has a value when there is a Default metric group. To
> > > > avoid the segv initialize the value to "".
>
> > > > Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
> > > > Signed-off-by: Ian Rogers <irogers at google.com>
>
> > > Thanks! I was going to look for the bug but got pulled to other
> > > tasks. The patch looks good to me and I tested it successfully on
> > > AmpereOne.
>
> > >    Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
>
> > Looks like it needs to go through perf-tools for v6.7.
> > Ian, do you think this one is enough?
>
> So I had this on my local perf-tools-next, removed now, I also have some
> other fixes by Ian on the tmp.perf-tools-next, please let me know what
> you guys decide to have in perf-tools for v6.7 so that I can remove it
> from there.

I think we need this one and the Ampere default-metric-group fix.

https://lore.kernel.org/r/20231201021550.1109196-2-ilkka at os.amperecomputing.com/

Also perf list JSON fix can go to v6.7.

https://lore.kernel.org/r/20231129213428.2227448-2-irogers at google.com/

Thanks,
Namhyung


From w.egorov at phytec.de  Tue Dec  5 09:26:00 2023
From: w.egorov at phytec.de (Wadim Egorov)
Date: Tue, 5 Dec 2023 18:26:00 +0100
Subject: [PATCH] arm64: dts: ti: phycore-am64: Add R5F DMA Region and
 Mailboxes
In-Reply-To: <20231204212304.1736306-1-ggiordano@phytec.com>
References: <20231204212304.1736306-1-ggiordano@phytec.com>
Message-ID: <136b3721-2ea7-488a-89cc-cc74f631f5fc@phytec.de>


Am 04.12.23 um 22:23 schrieb Garrett Giordano:
> Communication between the R5F subsystem and Linux takes place using DMA
> memory regions and mailboxes. Here we add DT nodes for the memory
> regions and mailboxes to facilitate communication between the R5
> clusters and Linux as remoteproc will fail to start if no memory
> regions or mailboxes are provided.
>
> Fixes: c48ac0efe6d7 ("arm64: dts: ti: Add support for phyBOARD-Electra-AM642")
> Signed-off-by: Garrett Giordano <ggiordano at phytec.com>

Reviewed-by: Wadim Egorov <w.egorov at phytec.de>


> ---
>   .../boot/dts/ti/k3-am64-phycore-som.dtsi      | 102 +++++++++++++++++-
>   1 file changed, 101 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
> index 1c2c8f0daca9..37a33006c1fc 100644
> --- a/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
> @@ -29,7 +29,7 @@ memory at 80000000 {
>   		reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
>   	};
>   
> -	reserved-memory {
> +	reserved_memory: reserved-memory {
>   		#address-cells = <2>;
>   		#size-cells = <2>;
>   		ranges;
> @@ -39,6 +39,54 @@ secure_ddr: optee at 9e800000 {
>   			alignment = <0x1000>;
>   			no-map;
>   		};
> +
> +		main_r5fss0_core0_dma_memory_region: r5f-dma-memory at a0000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0xa0000000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		main_r5fss0_core0_memory_region: r5f-memory at a0100000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0xa0100000 0x00 0xf00000>;
> +			no-map;
> +		};
> +
> +		main_r5fss0_core1_dma_memory_region: r5f-dma-memory at a1000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0xa1000000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		main_r5fss0_core1_memory_region: r5f-memory at a1100000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0xa1100000 0x00 0xf00000>;
> +			no-map;
> +		};
> +
> +		main_r5fss1_core0_dma_memory_region: r5f-dma-memory at a2000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0xa2000000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		main_r5fss1_core0_memory_region: r5f-memory at a2100000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0xa2100000 0x00 0xf00000>;
> +			no-map;
> +		};
> +
> +		main_r5fss1_core1_dma_memory_region: r5f-dma-memory at a3000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0xa3000000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		main_r5fss1_core1_memory_region: r5f-memory at a3100000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0xa3100000 0x00 0xf00000>;
> +			no-map;
> +		};
>   	};
>   
>   	leds {
> @@ -160,6 +208,34 @@ &cpsw_port2 {
>   	status = "disabled";
>   };
>   
> +&mailbox0_cluster2 {
> +	status = "okay";
> +
> +	mbox_main_r5fss0_core0: mbox-main-r5fss0-core0 {
> +		ti,mbox-rx = <0 0 2>;
> +		ti,mbox-tx = <1 0 2>;
> +	};
> +
> +	mbox_main_r5fss0_core1: mbox-main-r5fss0-core1 {
> +		ti,mbox-rx = <2 0 2>;
> +		ti,mbox-tx = <3 0 2>;
> +	};
> +};
> +
> +&mailbox0_cluster4 {
> +	status = "okay";
> +
> +	mbox_main_r5fss1_core0: mbox-main-r5fss1-core0 {
> +		ti,mbox-rx = <0 0 2>;
> +		ti,mbox-tx = <1 0 2>;
> +	};
> +
> +	mbox_main_r5fss1_core1: mbox-main-r5fss1-core1 {
> +		ti,mbox-rx = <2 0 2>;
> +		ti,mbox-tx = <3 0 2>;
> +	};
> +};
> +
>   &main_i2c0 {
>   	status = "okay";
>   	pinctrl-names = "default";
> @@ -180,6 +256,30 @@ i2c_som_rtc: rtc at 52 {
>   	};
>   };
>   
> +&main_r5fss0_core0 {
> +	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
> +	memory-region = <&main_r5fss0_core0_dma_memory_region>,
> +			<&main_r5fss0_core0_memory_region>;
> +};
> +
> +&main_r5fss0_core1 {
> +	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
> +	memory-region = <&main_r5fss0_core1_dma_memory_region>,
> +			<&main_r5fss0_core1_memory_region>;
> +};
> +
> +&main_r5fss1_core0 {
> +	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
> +	memory-region = <&main_r5fss1_core0_dma_memory_region>,
> +			<&main_r5fss1_core0_memory_region>;
> +};
> +
> +&main_r5fss1_core1 {
> +	mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
> +	memory-region = <&main_r5fss1_core1_dma_memory_region>,
> +			<&main_r5fss1_core1_memory_region>;
> +};
> +
>   &ospi0 {
>   	status = "okay";
>   	pinctrl-names = "default";


From nicolinc at nvidia.com  Tue Dec  5 09:25:59 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Tue, 5 Dec 2023 09:25:59 -0800
Subject: [PATCH v2 15/19] iommu/arm-smmu-v3: Add a global static IDENTITY
 domain
In-Reply-To: <20231205143742.GB2787277@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <15-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <ZW6m54yS2rpk65kE@Asurada-Nvidia>
 <20231205143742.GB2787277@nvidia.com>
Message-ID: <ZW9dJ1yzsdCjpMGm@Asurada-Nvidia>

On Tue, Dec 05, 2023 at 10:37:42AM -0400, Jason Gunthorpe wrote:
> On Mon, Dec 04, 2023 at 08:28:23PM -0800, Nicolin Chen wrote:
> 
> > > +static int arm_smmu_attach_dev_ste(struct device *dev,
> > > +				   struct arm_smmu_ste *ste)
> > > +{
> > > +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > > +
> > > +	if (arm_smmu_master_sva_enabled(master))
> > > +		return -EBUSY;
> > > +
> > > +	/*
> > > +	 * Do not allow any ASID to be changed while are working on the STE,
> > > +	 * otherwise we could miss invalidations.
> > > +	 */
> > > +	mutex_lock(&arm_smmu_asid_lock);
> > > +
> > > +	/*
> > > +	 * The SMMU does not support enabling ATS with bypass/abort. When the
> > > +	 * STE is in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests
> > > +	 * and Translated transactions are denied as though ATS is disabled for
> > > +	 * the stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
> > > +	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
> > > +	 */
> > > +	arm_smmu_detach_dev(master);
> > > +
> > > +	arm_smmu_install_ste_for_dev(master, ste);
> > > +	mutex_unlock(&arm_smmu_asid_lock);
> > > +
> > > +	/*
> > > +	 * This has to be done after removing the master from the
> > > +	 * arm_smmu_domain->devices to avoid races updating the same context
> > > +	 * descriptor from arm_smmu_share_asid().
> > > +	 */
> > > +	if (master->cd_table.cdtab)
> > > +		arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);
> >  
> > This arm_smmu_write_ctx_desc was previously within the asid lock
> > protection, yet now it's moved out of that?
> 
> Yes, arm_smmu_write_ctx_desc() updates a CD table entry and that does
> not need ASID lock protection. The ASID lock exists because of the BTM
> code rewriting STEs asyncronously.

I see. Thanks for elaborating. For this patch:

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From w.egorov at phytec.de  Tue Dec  5 09:31:47 2023
From: w.egorov at phytec.de (Wadim Egorov)
Date: Tue, 5 Dec 2023 18:31:47 +0100
Subject: [PATCH 1/3] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Lower
 I2C1 frequency
In-Reply-To: <20231204222811.2344460-1-ggiordano@phytec.com>
References: <20231204222811.2344460-1-ggiordano@phytec.com>
Message-ID: <d6f3e4e9-e622-4b2c-bd03-ab77f0552a70@phytec.de>


Am 04.12.23 um 23:28 schrieb Garrett Giordano:
> The gpio-expander on i2c-1 has a maximum frequency of 100kHz. Update our
> main_i2c1 frequency to allow the nxp,pcf8574 gpio-expander to function
> properly.
>
> Signed-off-by: Garrett Giordano <ggiordano at phytec.com>

For all three,
Reviewed-by: Wadim Egorov <w.egorov at phytec.de>


> ---
>   arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
> index a438baf542c2..171354b13e33 100644
> --- a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
> @@ -187,7 +187,7 @@ cpsw3g_phy3: ethernet-phy at 3 {
>   &main_i2c1 {
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&main_i2c1_pins_default>;
> -	clock-frequency = <400000>;
> +	clock-frequency = <100000>;
>   	status = "okay";
>   
>   	gpio_exp: gpio-expander at 21 {


From catalin.marinas at arm.com  Tue Dec  5 09:33:01 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 5 Dec 2023 17:33:01 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <86bkb4bn2v.wl-maz@kernel.org>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <86bkb4bn2v.wl-maz@kernel.org>
Message-ID: <ZW9ezSGSDIvv5MsQ@arm.com>

On Tue, Dec 05, 2023 at 05:01:28PM +0000, Marc Zyngier wrote:
> On Tue, 05 Dec 2023 16:43:18 +0000,
> Jason Gunthorpe <jgg at nvidia.com> wrote:
> > On Tue, Dec 05, 2023 at 04:22:33PM +0000, Catalin Marinas wrote:
> > > That's an argument to restrict this feature to PCIe. It's really about
> > > fewer arguments on the behaviour of other devices. Marc did raise
> > > another issue with the GIC VCPU interface (does this even have a vma in
> > > the host VMM?). That's a class of devices where the mapping is
> > > context-switched, so the TLBI+DSB rules don't help.
> 
> There is no vma. The CPU interface is entirely under control of KVM.
> Userspace only provides the IPA for the mapping.

That's good to know. We can solve the GIC issue by limiting the
relaxation to those mappings that have a user vma. Ideally we should do
this for vfio only but we don't have an easy way to convey this to KVM.

-- 
Catalin


From afd at ti.com  Tue Dec  5 09:33:06 2023
From: afd at ti.com (Andrew Davis)
Date: Tue, 5 Dec 2023 11:33:06 -0600
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <CFF198DA-5C42-425E-86F4-759629489ECB@goldelico.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <CFF198DA-5C42-425E-86F4-759629489ECB@goldelico.com>
Message-ID: <cb590a13-e0ff-49d9-8583-be613ad50dc5@ti.com>

On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
> Hi Andrew,
> 
>> Am 04.12.2023 um 19:22 schrieb Andrew Davis <afd at ti.com>:
>>
>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
>> multiple vendors.
> 
> Great and thanks for the new attempt to get at least the Device Tree side
> upstream. Really appreciated!
> 

Thanks for helping us maintain these GPUs with the OpenPVRSGX project :)

>> Describe how the SGX GPU is integrated in these SoC,
>> including register space and interrupts.
> 
>> Clocks, reset, and power domain
>> information is SoC specific.
> 
> Indeed. This makes it understandable why you did not directly
> take our scheme from the openpvrsgx project.
> 
>>
>> Signed-off-by: Andrew Davis <afd at ti.com>
>> ---
>> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
>> 1 file changed, 63 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
>> index a13298f1a1827..9f036891dad0b 100644
>> --- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
>> +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
>> @@ -11,11 +11,33 @@ maintainers:
>>    - Frank Binns <frank.binns at imgtec.com>
>>
>> properties:
>> +  $nodename:
>> +    pattern: '^gpu@[a-f0-9]+$'
>> +
>>    compatible:
>> -    items:
>> -      - enum:
>> -          - ti,am62-gpu
>> -      - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
>> +    oneOf:
>> +      - items:
>> +          - enum:
>> +              - ti,am62-gpu
>> +          - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
>> +      - items:
>> +          - enum:
>> +              - ti,omap3430-gpu # Rev 121
>> +              - ti,omap3630-gpu # Rev 125
> 
> Is the "Rev 121" and "Rev 125" a property of the SoC integration (clock/reset/power
> hookup etc.) or of the integrated SGX core?
> 

The Rev is a property of the SGX core, not the SoC integration. But it seems that
compatible string is being used to define both (as we see being debated in the other
thread on this series).

> In my understanding the Revs are different variants of the SGX core (errata
> fixes, instruction set, pipeline size etc.). And therefore the current driver code
> has to be configured by some macros to handle such cases.
> 
> So the Rev should IMHO be part of the next line:
> 
>> +          - const: img,powervr-sgx530
> 
> +          - enum:
> +              - img,powervr-sgx530-121
> +              - img,powervr-sgx530-125
> 
> We have a similar definition in the openpvrsgx code.
> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";
> 
> (I don't mind about the powervr- prefix).
> 
> This would allow a generic and universal sgx driver (loaded through just matching
> "img,sgx530") to handle the errata and revision specifics at runtime based on the
> compatible entry ("img,sgx530-121") and know about SoC integration ("ti,omap3-sgx530-121").
> 
> And user-space can be made to load the right firmware variant based on "img,sgx530-121"
> 
> I don't know if there is some register which allows to discover the revision long
> before the SGX subsystem is initialized and the firmware is up and running.
> 
> What I know is that it is possible to read out the revision after starting the firmware
> but it may just echo the version number of the firmware binary provided from user-space.
> 

We should be able to read out the revision (register EUR_CR_CORE_REVISION), the problem is
today the driver is built for a given revision at compile time. That is a software issue,
not something that we need to encode in DT. While the core ID (SGX5xx) can be also detected
(EUR_CR_CORE_ID), the location of that register changes, and so it does need encoded in
DT compatible.

The string "ti,omap3430-gpu" tells us the revision if we cannot detect it (as in the current
driver), and the SoC integration is generic anyway (just a reg and interrupt).

Andrew

>> +      - items:
>> +          - enum:
>> +              - ingenic,jz4780-gpu # Rev 130
>> +              - ti,omap4430-gpu # Rev 120
>> +          - const: img,powervr-sgx540
>> +      - items:
>> +          - enum:
>> +              - allwinner,sun6i-a31-gpu # MP2 Rev 115
>> +              - ti,omap4470-gpu # MP1 Rev 112
>> +              - ti,omap5432-gpu # MP2 Rev 105
>> +              - ti,am5728-gpu # MP2 Rev 116
>> +              - ti,am6548-gpu # MP1 Rev 117
>> +          - const: img,powervr-sgx544
>>
>>    reg:
>>      maxItems: 1
>> @@ -40,8 +62,6 @@ properties:
>> required:
>>    - compatible
>>    - reg
>> -  - clocks
>> -  - clock-names
>>    - interrupts
>>
>> additionalProperties: false
>> @@ -56,6 +76,43 @@ allOf:
>>        properties:
>>          clocks:
>>            maxItems: 1
>> +      required:
>> +        - clocks
>> +        - clock-names
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: ti,am654-sgx544
>> +    then:
>> +      properties:
>> +        power-domains:
>> +          minItems: 1
>> +      required:
>> +        - power-domains
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: allwinner,sun6i-a31-gpu
>> +    then:
>> +      properties:
>> +        clocks:
>> +          minItems: 2
>> +        clock-names:
>> +          minItems: 2
>> +      required:
>> +        - clocks
>> +        - clock-names
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: ingenic,jz4780-gpu
>> +    then:
>> +      required:
>> +        - clocks
>> +        - clock-names
>>
>> examples:
>>    - |
>> -- 
>> 2.39.2
>>
> 
> BR and thanks,
> Nikolaus


From jgg at nvidia.com  Tue Dec  5 09:42:19 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 13:42:19 -0400
Subject: [PATCH v2 15/19] iommu/arm-smmu-v3: Add a global static IDENTITY
 domain
In-Reply-To: <ZW9dJ1yzsdCjpMGm@Asurada-Nvidia>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <15-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <ZW6m54yS2rpk65kE@Asurada-Nvidia>
 <20231205143742.GB2787277@nvidia.com>
 <ZW9dJ1yzsdCjpMGm@Asurada-Nvidia>
Message-ID: <20231205174219.GI2692119@nvidia.com>

On Tue, Dec 05, 2023 at 09:25:59AM -0800, Nicolin Chen wrote:
> On Tue, Dec 05, 2023 at 10:37:42AM -0400, Jason Gunthorpe wrote:
> > On Mon, Dec 04, 2023 at 08:28:23PM -0800, Nicolin Chen wrote:
> > 
> > > > +static int arm_smmu_attach_dev_ste(struct device *dev,
> > > > +				   struct arm_smmu_ste *ste)
> > > > +{
> > > > +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > > > +
> > > > +	if (arm_smmu_master_sva_enabled(master))
> > > > +		return -EBUSY;
> > > > +
> > > > +	/*
> > > > +	 * Do not allow any ASID to be changed while are working on the STE,
> > > > +	 * otherwise we could miss invalidations.
> > > > +	 */
> > > > +	mutex_lock(&arm_smmu_asid_lock);
> > > > +
> > > > +	/*
> > > > +	 * The SMMU does not support enabling ATS with bypass/abort. When the
> > > > +	 * STE is in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests
> > > > +	 * and Translated transactions are denied as though ATS is disabled for
> > > > +	 * the stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
> > > > +	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
> > > > +	 */
> > > > +	arm_smmu_detach_dev(master);
> > > > +
> > > > +	arm_smmu_install_ste_for_dev(master, ste);
> > > > +	mutex_unlock(&arm_smmu_asid_lock);
> > > > +
> > > > +	/*
> > > > +	 * This has to be done after removing the master from the
> > > > +	 * arm_smmu_domain->devices to avoid races updating the same context
> > > > +	 * descriptor from arm_smmu_share_asid().
> > > > +	 */
> > > > +	if (master->cd_table.cdtab)
> > > > +		arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);
> > >  
> > > This arm_smmu_write_ctx_desc was previously within the asid lock
> > > protection, yet now it's moved out of that?
> > 
> > Yes, arm_smmu_write_ctx_desc() updates a CD table entry and that does
> > not need ASID lock protection. The ASID lock exists because of the BTM
> > code rewriting STEs asyncronously.
> 
> I see. Thanks for elaborating. For this patch

Actually wait, that explanation is not right..

The BTM code is changing the ASID which is done with a CD update

The ordering is OK here because the BTM code iterates over the
&smmu_domain->devices list.

The arm_smmu_detach_dev() has removed the master from the devices list
under a lock so the BTM code won't see this.

Thus there is no race between the arm_smmu_share_asid() flow and this
code, indeed we've already removed the cdtable from the STE at this
point.

Jason


From nicolinc at nvidia.com  Tue Dec  5 09:47:07 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Tue, 5 Dec 2023 09:47:07 -0800
Subject: [PATCH v2 01/27] iommu/arm-smmu-v3: Check that the RID domain is
 S1 in SVA
In-Reply-To: <1-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
References: <0-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
 <1-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <ZW9iGyHkrMmxAyvB@Asurada-Nvidia>

On Wed, Nov 01, 2023 at 08:36:19PM -0300, Jason Gunthorpe wrote:
> This code only works if the RID domain is a S1 domain and has already
> installed the cdtable.
> 
> Add a to_smmu_domain_safe() which does a robust conversion from
> struct iommu_domain to the struct arm_smmu_domain.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
 
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>


From nathan at kernel.org  Tue Dec  5 09:49:19 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Tue, 5 Dec 2023 10:49:19 -0700
Subject: [PATCH] power: reset: at91: Drop '__init' from
 at91_wakeup_status()
In-Reply-To: <20231120-fix-at91-modpost-warnings-v1-1-813671933863@kernel.org>
References: <20231120-fix-at91-modpost-warnings-v1-1-813671933863@kernel.org>
Message-ID: <20231205174919.GA535965@dev-arch.thelio-3990X>

Ping? I still see these warnings in next-20231205.

On Mon, Nov 20, 2023 at 03:35:32PM -0700, Nathan Chancellor wrote:
> When building with clang, there are two section mismatch warnings:
> 
>   WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x7c (section: .text) -> at91_wakeup_status (section: .init.text)
>   WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text)
> 
> Drop '__init' from at91_wakeup_status() to clear up the mismatch.
> 
> Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
> Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
> Signed-off-by: Nathan Chancellor <nathan at kernel.org>
> ---
> I suspect this is not visible for GCC due to inlining
> at91_wakeup_status() but I did not actually check.
> ---
>  drivers/power/reset/at91-poweroff.c      | 2 +-
>  drivers/power/reset/at91-sama5d2_shdwc.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/reset/at91-poweroff.c b/drivers/power/reset/at91-poweroff.c
> index 126e774e210c..93eece027865 100644
> --- a/drivers/power/reset/at91-poweroff.c
> +++ b/drivers/power/reset/at91-poweroff.c
> @@ -57,7 +57,7 @@ static struct shdwc {
>  	void __iomem *mpddrc_base;
>  } at91_shdwc;
>  
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
>  {
>  	const char *reason;
>  	u32 reg = readl(at91_shdwc.shdwc_base + AT91_SHDW_SR);
> diff --git a/drivers/power/reset/at91-sama5d2_shdwc.c b/drivers/power/reset/at91-sama5d2_shdwc.c
> index af95c7b39cb3..959ce0dbe91d 100644
> --- a/drivers/power/reset/at91-sama5d2_shdwc.c
> +++ b/drivers/power/reset/at91-sama5d2_shdwc.c
> @@ -107,7 +107,7 @@ static const unsigned long long sdwc_dbc_period[] = {
>  	0, 3, 32, 512, 4096, 32768,
>  };
>  
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
>  {
>  	struct shdwc *shdw = platform_get_drvdata(pdev);
>  	const struct reg_config *rcfg = shdw->rcfg;
> 
> ---
> base-commit: b55d073e6501dc6077edaa945a6dad8ac5c8bbab
> change-id: 20231120-fix-at91-modpost-warnings-beabd2bac722
> 
> Best regards,
> -- 
> Nathan Chancellor <nathan at kernel.org>
> 


From maz at kernel.org  Tue Dec  5 09:50:27 2023
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 05 Dec 2023 17:50:27 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
In-Reply-To: <ZW9ezSGSDIvv5MsQ@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
	<86fs0hatt3.wl-maz@kernel.org>
	<ZW8MP2tDt4_9ROBz@arm.com>
	<20231205130517.GD2692119@nvidia.com>
	<ZW9OSe8Z9gAmM7My@arm.com>
	<20231205164318.GG2692119@nvidia.com>
	<86bkb4bn2v.wl-maz@kernel.org>
	<ZW9ezSGSDIvv5MsQ@arm.com>
Message-ID: <86a5qobkt8.wl-maz@kernel.org>

On Tue, 05 Dec 2023 17:33:01 +0000,
Catalin Marinas <catalin.marinas at arm.com> wrote:
> 
> On Tue, Dec 05, 2023 at 05:01:28PM +0000, Marc Zyngier wrote:
> > On Tue, 05 Dec 2023 16:43:18 +0000,
> > Jason Gunthorpe <jgg at nvidia.com> wrote:
> > > On Tue, Dec 05, 2023 at 04:22:33PM +0000, Catalin Marinas wrote:
> > > > That's an argument to restrict this feature to PCIe. It's really about
> > > > fewer arguments on the behaviour of other devices. Marc did raise
> > > > another issue with the GIC VCPU interface (does this even have a vma in
> > > > the host VMM?). That's a class of devices where the mapping is
> > > > context-switched, so the TLBI+DSB rules don't help.
> > 
> > There is no vma. The CPU interface is entirely under control of KVM.
> > Userspace only provides the IPA for the mapping.
> 
> That's good to know. We can solve the GIC issue by limiting the
> relaxation to those mappings that have a user vma.

Yes, this should definitely be part of the decision.

> Ideally we should do this for vfio only but we don't have an easy
> way to convey this to KVM.

But if we want to limit this to PCIe, we'll have to find out. The
initial proposal (a long while ago) had a flag conveying some
information, and I'd definitely feel more confident having something
like that.

	M.

-- 
Without deviation from the norm, progress is not possible.


From jgg at nvidia.com  Tue Dec  5 09:51:27 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 13:51:27 -0400
Subject: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64
In-Reply-To: <ZW9cF0ALVwgvcQMy@arm.com>
References: <cover.1700766072.git.leon@kernel.org>
 <c3ae87aea7660c3d266905c19d10d8de0f9fb779.1700766072.git.leon@kernel.org>
 <ZWB373y5XuZDultf@FVFF77S0Q05N>
 <20231124122352.GB436702@nvidia.com>
 <ZWSOwT2OyMXD1lmo@arm.com>
 <20231127134505.GI436702@nvidia.com>
 <ZW4NAzI_jvwoq8dL@arm.com>
 <20231204182330.GK1493156@nvidia.com>
 <ZW9cF0ALVwgvcQMy@arm.com>
Message-ID: <20231205175127.GJ2692119@nvidia.com>

On Tue, Dec 05, 2023 at 05:21:27PM +0000, Catalin Marinas wrote:
> On Mon, Dec 04, 2023 at 02:23:30PM -0400, Jason Gunthorpe wrote:
> > On Mon, Dec 04, 2023 at 05:31:47PM +0000, Catalin Marinas wrote:
> > > Personally I'd optimise the mempcy_toio() arm64 implementation to do
> > > STPs if the alignment is right (like we do for classic memcpy()).
> > > There's a slight overhead for alignment checking but I suspect it would
> > > be lost as long as you can get the write-combining. Not sure whether the
> > > interspersed reads in memcpy_toio() would somehow prevent the
> > > write-combining.
> > 
> > I understand on these new CPUs anything other than a block of
> > contiguous STPs is risky to break the WC. I was told we should not
> > have any loads between them.
> 
> Classic memcpy does similar tricks with four LDPs in a row before
> starting to issue the STPs (though there are new LDPs for the next
> data in-between). But that was tuned for cacheable memory, not sure
> if something similar would behave well on Normal-NC memory.

Can we conclude a direction here?

1) I don't want to mess with x86 so we keep a dedicated API
   Are we agreed to call it __iowrite512_copy() and note its special
   alignment limitation?

2) You want to #define __iowrite512_copy() to memcpy_toio() on ARM and
   implement some quad STP optimization for this case?

3) A future ST64B and the x86 version would be put under
   __iowrite512_copy()?

4) A future ST64B would come with some kind of 'must do 64b copy or
   oops' to support the future HW that must have this instruction? eg
   we already see on Intel that HW must use ENQCMD and nothing else.

Agreed?

Niklas, is this OK for S390 too?

> > I'm told it is problematic, something about ST64B not working with
> > NORMAL_NC.
> 
> Last time I checked it was meant to work on Normal-NC (not cacheable
> though). That's on page 285 of the Arm ARM J.a.

This is a relief to hear!

Thanks,
Jason


From willemdebruijn.kernel at gmail.com  Tue Dec  5 10:03:46 2023
From: willemdebruijn.kernel at gmail.com (Willem de Bruijn)
Date: Tue, 05 Dec 2023 13:03:46 -0500
Subject: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC
In-Reply-To: <CAKH8qBuXL8bOYtfKKPS8y=KJqouDptyciCjr0wNKVHtNj6BmqA@mail.gmail.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com>
 <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
 <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
 <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com>
 <CAKH8qBuXL8bOYtfKKPS8y=KJqouDptyciCjr0wNKVHtNj6BmqA@mail.gmail.com>
Message-ID: <656f66023f7bd_3dd6422942a@willemb.c.googlers.com.notmuch>

Stanislav Fomichev wrote:
> On Tue, Dec 5, 2023 at 7:34?AM Florian Bezdeka
> <florian.bezdeka at siemens.com> wrote:
> >
> > On Tue, 2023-12-05 at 15:25 +0000, Song, Yoong Siang wrote:
> > > On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote:
> > > > Jesper Dangaard Brouer wrote:
> > > > >
> > > > >
> > > > > On 12/3/23 17:51, Song Yoong Siang wrote:
> > > > > > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > > > > > copy via XDP Tx metadata framework.
> > > > > >
> > > > > > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > > > > > ---
> > > > > >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> > > > >
> > > > > As requested before, I think we need to see another driver implementing
> > > > > this.
> > > > >
> > > > > I propose driver igc and chip i225.
> > >
> > > Sure. I will include igc patches in next version.
> > >
> > > > >
> > > > > The interesting thing for me is to see how the LaunchTime max 1 second
> > > > > into the future[1] is handled code wise. One suggestion is to add a
> > > > > section to Documentation/networking/xsk-tx-metadata.rst per driver that
> > > > > mentions/documents these different hardware limitations.  It is natural
> > > > > that different types of hardware have limitations.  This is a close-to
> > > > > hardware-level abstraction/API, and IMHO as long as we document the
> > > > > limitations we can expose this API without too many limitations for more
> > > > > capable hardware.
> > >
> > > Sure. I will try to add hardware limitations in documentation.
> > >
> > > >
> > > > I would assume that the kfunc will fail when a value is passed that
> > > > cannot be programmed.
> > > >
> > >
> > > In current design, the xsk_tx_metadata_request() dint got return value.
> > > So user won't know if their request is fail.
> > > It is complex to inform user which request is failing.
> > > Therefore, IMHO, it is good that we let driver handle the error silently.
> > >
> >
> > If the programmed value is invalid, the packet will be "dropped" / will
> > never make it to the wire, right?

Programmable behavior is to either drop or cap to some boundary
value, such as the farthest programmable time in the future: the
horizon. In fq:

                /* Check if packet timestamp is too far in the future. */
                if (fq_packet_beyond_horizon(skb, q, now)) {
                        if (q->horizon_drop) {
                                        q->stat_horizon_drops++;
                                        return qdisc_drop(skb, sch, to_free);
                        }
                        q->stat_horizon_caps++;
                        skb->tstamp = now + q->horizon;
                }
                fq_skb_cb(skb)->time_to_send = skb->tstamp;

Drop is the more obviously correct mode.

Programming with a clock source that the driver does not support will
then be a persistent failure.

Preferably, this driver capability can be queried beforehand (rather
than only through reading error counters afterwards).

Perhaps it should not be a driver task to convert from possibly
multiple clock sources to the device native clock. Right now, we do
use per-device timecounters for this, implemented in the driver.

As for which clocks are relevant. For PTP, I suppose the device PHC,
converted to nsec. For pacing offload, TCP uses CLOCK_MONOTONIC.

> >
> > That is clearly a situation that the user should be informed about. For
> > RT systems this normally means that something is really wrong regarding
> > timing / cycle overflow. Such systems have to react on that situation.
> 
> In general, af_xdp is a bit lacking in this 'notify the user that they
> somehow messed up' area :-(
> For example, pushing a tx descriptor with a wrong addr/len in zc mode
> will not give any visible signal back (besides driver potentially
> spilling something into dmesg as it was in the mlx case).
> We can probably start with having some counters for these events?

This is because the AF_XDP completion queue descriptor format is only
a u64 address?

Could error conditions be reported on tx completion in the metadata,
using xsk_tx_metadata_complete?



From hns at goldelico.com  Tue Dec  5 10:04:05 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Tue, 5 Dec 2023 19:04:05 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <cb590a13-e0ff-49d9-8583-be613ad50dc5@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <CFF198DA-5C42-425E-86F4-759629489ECB@goldelico.com>
 <cb590a13-e0ff-49d9-8583-be613ad50dc5@ti.com>
Message-ID: <FE0DBA5E-95A5-4C27-9F69-D1D8BDF56EC3@goldelico.com>



> Am 05.12.2023 um 18:33 schrieb Andrew Davis <afd at ti.com>:
> 
> On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
>>> +          - enum:
>>> +              - ti,omap3430-gpu # Rev 121
>>> +              - ti,omap3630-gpu # Rev 125
>> Is the "Rev 121" and "Rev 125" a property of the SoC integration (clock/reset/power
>> hookup etc.) or of the integrated SGX core?
> 
> The Rev is a property of the SGX core, not the SoC integration.

Then, it should belong there and not be a comment of the ti,omap*-gpu record.
In this way it does not seem to be a proper hardware description.

BTW: there are examples where the revision is part of the compatible string, even
if the (Linux) driver makes no use of it:

drivers/net/ethernet/xilinx/xilinx_emaclite.c

> But it seems that
> compatible string is being used to define both (as we see being debated in the other
> thread on this series).
> 
>> In my understanding the Revs are different variants of the SGX core (errata
>> fixes, instruction set, pipeline size etc.). And therefore the current driver code
>> has to be configured by some macros to handle such cases.
>> So the Rev should IMHO be part of the next line:
>>> +          - const: img,powervr-sgx530
>> +          - enum:
>> +              - img,powervr-sgx530-121
>> +              - img,powervr-sgx530-125
>> We have a similar definition in the openpvrsgx code.
>> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";
>> (I don't mind about the powervr- prefix).
>> This would allow a generic and universal sgx driver (loaded through just matching
>> "img,sgx530") to handle the errata and revision specifics at runtime based on the
>> compatible entry ("img,sgx530-121") and know about SoC integration ("ti,omap3-sgx530-121").
>> And user-space can be made to load the right firmware variant based on "img,sgx530-121"
>> I don't know if there is some register which allows to discover the revision long
>> before the SGX subsystem is initialized and the firmware is up and running.
>> What I know is that it is possible to read out the revision after starting the firmware
>> but it may just echo the version number of the firmware binary provided from user-space.
> 
> We should be able to read out the revision (register EUR_CR_CORE_REVISION), the problem is
> today the driver is built for a given revision at compile time.

Yes, that is something we had planned to get rid of for a long time by using different compatible
strings and some variant specific struct like many others drivers are doing it.
But it was a to big task so nobody did start with it.

> That is a software issue,
> not something that we need to encode in DT. While the core ID (SGX5xx) can be also detected
> (EUR_CR_CORE_ID), the location of that register changes, and so it does need encoded in
> DT compatible.

Ok, I didn't know about such registers as there is not much public information available.
Fair enough, there are some error reports about in different forums.

On the other hand we then must read out this register in more or less early initialization
stages. Even if we know this information to be static and it could be as simple as a list
of compatible strings in the driver.

> The string "ti,omap3430-gpu" tells us the revision if we cannot detect it (as in the current
> driver), and the SoC integration is generic anyway (just a reg and interrupt).

It of course tells, but may need a translation table that needs to be maintained in a
different format. Basically the same what the comments show in a non-machine readable
format.

I just wonder why the specific version can or should not become simply part of the DTS
and needs this indirection.

Basically it is a matter of openness for future (driver) development and why it needs
careful decisions.

So in other words: I would prefer to see the comments about versions encoded in the device
tree binary to make it machine readable.

BR and thanks,
Nikolaus

From tharvey at gateworks.com  Tue Dec  5 10:13:21 2023
From: tharvey at gateworks.com (Tim Harvey)
Date: Tue, 5 Dec 2023 10:13:21 -0800
Subject: [PATCH] arm64: dts: imx8mm-venice: Fix PCI bus nodes
In-Reply-To: <CAL_JsqKLFpPo8xTh_vgWvDXSY5J8tQJZh9SrkW2EiK5V_ZNeeA@mail.gmail.com>
References: <20231130191815.2421978-1-robh@kernel.org> <CAOMZO5AZNz1cRg+aYQjDmpZ75ATJQUTWmC5mx+vgaYcBL6M+2w@mail.gmail.com>
 <CAL_JsqKLFpPo8xTh_vgWvDXSY5J8tQJZh9SrkW2EiK5V_ZNeeA@mail.gmail.com>
Message-ID: <CAJ+vNU1DiFbQivka8gA1URiLMD2mWJnWSdn-77bEo8Uz0Liqcg@mail.gmail.com>

On Thu, Nov 30, 2023 at 2:33?PM Rob Herring <robh at kernel.org> wrote:
>
> On Thu, Nov 30, 2023 at 1:28?PM Fabio Estevam <festevam at gmail.com> wrote:
> >
> > Hi Rob,
> >
> > On Thu, Nov 30, 2023 at 4:18?PM Rob Herring <robh at kernel.org> wrote:
> > >
> > > The imx8mm-venice boards PCI bus nodes are a complete mess. The
> > > unit-addresses are wrong. The PCI bridge nodes are incomplete missing
> > > "device_type" and "ranges" and just wrong for "#address-cells" and
> > > "#size-cells" values.
> > >
> > > All of these issues are reported warnings if anyone bothered to pay
> > > attention. Sigh.

Rob,

Sorry about that. At the time the dt was submitted there were still so
many dt warnings it wasn't very clear what was a legitimate issue and
the PCI bindings are not that easy to understand.

> >
> > The warnings are gone in linux-next:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/freescale?h=next-20231130&id=d61c5068729a76a6183a897bcad4bf26e8d3d674
>
> Linux-next is wrong. The ethernet device should have a node name of
> 'ethernet'. The 'pcie' node name and 'device_type = "pci"' is for PCI
> buses/bridges only.

So as Fabio has tried to fix this with a patch that landed in
linux-next this patch won't apply. I'll submit one that covers your
changes.

It's always been unfortunate to have to have this level of detail in a
device-tree just to allow boot firmware to populate the mac address of
a PCI ethernet device.

Best Regards,

Tim


From khilman at kernel.org  Tue Dec  5 10:13:57 2023
From: khilman at kernel.org (Kevin Hilman)
Date: Tue, 05 Dec 2023 10:13:57 -0800
Subject: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure
 ti-sysc for wkup_uart0
In-Reply-To: <20231114073209.40756-1-tony@atomide.com>
References: <20231114073209.40756-1-tony@atomide.com>
Message-ID: <7h5y1c7c0q.fsf@baylibre.com>

Tony Lindgren <tony at atomide.com> writes:

> The devices in the wkup domain are capable of waking up the system from
> suspend. We can configure the wkup domain devices in a generic way using
> the ti-sysc interconnect target module driver like we have done with the
> earlier TI SoCs.
>
> As ti-sysc manages the SYSCONFIG related registers independent of the
> child hardware device, the wake-up configuration is also set even if
> wkup_uart0 is reserved by sysfw.
>
> The wkup_uart0 device has interconnect target module register mapping like
> dra7 wkup uart. There is a 1 MB interconnect target range with one uart IP
> block in the target module. The power domain and clock affects the whole
> interconnect target module.
>
> Note we change the functional clock name to follow the ti-sysc binding
> and use "fck" instead of "fclk".
>
> Tested-by: Dhruva Gole <d-gole at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
>
> Changes since v1:
>
> - Added Tested-by from Dhruva
>
> ---
>  arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi | 33 ++++++++++++++++++----
>  1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
> --- a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
> @@ -5,6 +5,8 @@
>   * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
>   */
>  
> +#include <dt-bindings/bus/ti-sysc.h>
> +
>  &cbass_wakeup {
>  	wkup_conf: syscon at 43000000 {
>  		bootph-all;
> @@ -21,14 +23,33 @@ chipid: chipid at 14 {
>  		};
>  	};
>  
> -	wkup_uart0: serial at 2b300000 {
> -		compatible = "ti,am64-uart", "ti,am654-uart";
> -		reg = <0x00 0x2b300000 0x00 0x100>;
> -		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> +	target-module at 2b300000 {
> +		compatible = "ti,sysc-omap2", "ti,sysc";
> +		reg = <0 0x2b300050 0 0x4>,
> +		      <0 0x2b300054 0 0x4>,
> +		      <0 0x2b300058 0 0x4>;
> +		reg-names = "rev", "sysc", "syss";
> +		ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
> +				 SYSC_OMAP2_SOFTRESET |
> +				 SYSC_OMAP2_AUTOIDLE)>;
> +		ti,sysc-sidle = <SYSC_IDLE_FORCE>,
> +				<SYSC_IDLE_NO>,
> +				<SYSC_IDLE_SMART>,
> +				<SYSC_IDLE_SMART_WKUP>;
> +		ti,syss-mask = <1>;
>  		power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
>  		clocks = <&k3_clks 114 0>;

I'm a little confused why these power-domain and clocks stay here and
are not moved under the wkup_uart0 node... 

> -		clock-names = "fclk";
> -		status = "disabled";
> +		clock-names = "fck";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges = <0 0 0x2b300000 0x100000>;
> +
> +		wkup_uart0: serial at 2b300000 {
> +			compatible = "ti,am64-uart", "ti,am654-uart";
> +			reg = <0 0x100>;
> +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";

...here.

The SCI device ID 114 is specifically for wkup_uart0[1], so it seems to
me those should be in the wkup_uart0 node.

Kevin

[1] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/devices.html


From mark.rutland at arm.com  Tue Dec  5 10:14:57 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 5 Dec 2023 18:14:57 +0000
Subject: armv8pmu: Pending overflow interrupt is discarded when perf
 event is disabled
In-Reply-To: <ZWh-sbrHJu2b-BU6@FVFF77S0Q05N>
References: <950001BD-490C-4BAC-8EEA-CDB9F7C4ADFC@amazon.com>
 <EBAF38AB-2BE5-425F-8A52-DDCB0B390309@amazon.com>
 <ZWdoNWps4izj5WJy@FVFF77S0Q05N.cambridge.arm.com>
 <ZWh2pnR_Z5-CKuZb@FVFF77S0Q05N>
 <ZWh-sbrHJu2b-BU6@FVFF77S0Q05N>
Message-ID: <ZW9ooVL32WB8U4YB@FVFF77S0Q05N>

On Thu, Nov 30, 2023 at 12:23:13PM +0000, Mark Rutland wrote:
> On Thu, Nov 30, 2023 at 11:48:54AM +0000, Mark Rutland wrote:
> > On Wed, Nov 29, 2023 at 04:35:01PM +0000, Mark Rutland wrote:
> > > Does RR set any of the perf_event_attr::exclude_* bits? If not, does RR
> > > intentionally count events that occur within the kernel?
> > 
> > Looking at the test, I see it sets perf_event_attr::exclude_kernel to 1, but
> > doesn't set perf_event_attr::exclude_host or perf_event_attr::exclude_hv. I
> > think the poorly-defined exclude_* bits are part of the problem here.
> > 
> > Using your test as-is on my ThunderX2, I can reproduce the period being longer
> > than expected by concurrently running the following in a shell:
> > 
> >   while true; do
> >     for C in $(seq 0 63); do
> >       taskset -c -p $C ${TEST_PID_HERE};
> >     done; 
> >   done > /dev/null
> > 
> > ... resulting in:
> > 
> > | [mark at gravadlaks:~]% ./counter-overflow                                     
> > | Pid 20060 running with period 10000 tolerance 1000
> > | Signal #1: last: 0, cur: 10292, max diff: 0
> > | Signal #415330: delta of 19999 is outside 10000 +/- 1000
> > | Signal #415330: last: 4153290187, cur: 4153310186, max diff: 10292
> > | Signal #489879: delta of 19998 is outside 10000 +/- 1000
> > | Signal #511842: delta of 20058 is outside 10000 +/- 1000
> > | Signal #511842: last: 5118430130, cur: 5118450188, max diff: 19999
> > 
> > However, if I modify the test to also set perf_event_attr::exclude_host=1, I do
> > not see any lost overflows after many minutes. On VHE hosts (like the
> > ThunderX2), the host kernel gets counted when perf_event_attr::exclude_host=0,
> > even if perf_event_attr::exclude_kernel=1 (which I agree is surprising), so I
> > think what's happening is the counters are counting in the host kernel, which
> > isn't what RR actually wants regardless.
> 
> > I'll continue to look at what we can do kernel-side, but I reckon it's worth
> > having RR try the other exclude bits regardless, if that's possible? It would
> > be interesting to know whether that helps you under a hypervisor.
> 
> Sorry, the above is wrong, and I do not recommend RR goes and changes its
> exclude_* settings.
> 
> I had misread the logic in armv8pmu_set_event_filter(), but looking again
> that's saner than I thought it was, and what was actually happening in my
> testing is that exclude_host also filtered host EL0 (userspace), and so the
> test received *no* overflow signals.
> 
> I'll get back to looking at how we can better capture the overflow when
> removing an event.

I've spent a couple of days on this, and I have a prototype at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=perf/overflow

The gist of that is:

* It's not viable to sample at start/stop time since we don't have all the
  usual sample state (e.g. pt_regs), which means that we have to save/restore
  the overflow status and rely on the regular interrupt handler to actually
  sample after this is restored.

* Saving/restoring the overflow status requires reworking the way we manage the
  sample period, separating the sample period from the period we program into
  HW. This part looks fairly sane, but requires some rework of all the arm_pmu
  drivers.

* We might need a couple of small changes to the perf core code (e.g. for the
  IOCTLs that mess with the period), and this change is liable to affect other
  architectures, so we'd need ot go audit that.

I reckon it's possible (with some testing and review) to get something like
this series merged, but I suspect it's too big for a stable backport.

Mark.


From wahrenst at gmx.net  Tue Dec  5 10:21:06 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 5 Dec 2023 19:21:06 +0100
Subject: [PATCH] ARM: dts: imx23/28: Remove unneeded "fsl,mxs-gpio"
In-Reply-To: <20231205125731.2008490-1-festevam@gmail.com>
References: <20231205125731.2008490-1-festevam@gmail.com>
Message-ID: <4d436243-1df4-46d9-bfc5-7041431a6375@gmx.net>

Am 05.12.23 um 13:57 schrieb Fabio Estevam:
> From: Fabio Estevam <festevam at denx.de>
>
> According to gpio-mxs.yaml, only "fsl,imx23-gpio" or "fsl,imx28-gpio"
> are valid compatible strings.
>
> This fixes the following dt-schema warnings:
>
> imx23-evk.dtb: pinctrl at 80018000: gpio at 0:compatible: ['fsl,imx23-gpio', 'fsl,mxs-gpio'] is too long
> 	from schema $id: http://devicetree.org/schemas/gpio/gpio-mxs.yaml#
>
> Signed-off-by: Fabio Estevam <festevam at denx.de>
Reviewed-by: Stefan Wahren <wahrenst at gmx.net>


From nicolinc at nvidia.com  Tue Dec  5 10:21:18 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Tue, 5 Dec 2023 10:21:18 -0800
Subject: [PATCH v2 15/19] iommu/arm-smmu-v3: Add a global static IDENTITY
 domain
In-Reply-To: <20231205174219.GI2692119@nvidia.com>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <15-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <ZW6m54yS2rpk65kE@Asurada-Nvidia>
 <20231205143742.GB2787277@nvidia.com>
 <ZW9dJ1yzsdCjpMGm@Asurada-Nvidia>
 <20231205174219.GI2692119@nvidia.com>
Message-ID: <ZW9qHsORHC5obMLS@Asurada-Nvidia>

On Tue, Dec 05, 2023 at 01:42:19PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 05, 2023 at 09:25:59AM -0800, Nicolin Chen wrote:
> > On Tue, Dec 05, 2023 at 10:37:42AM -0400, Jason Gunthorpe wrote:
> > > On Mon, Dec 04, 2023 at 08:28:23PM -0800, Nicolin Chen wrote:
> > > 
> > > > > +static int arm_smmu_attach_dev_ste(struct device *dev,
> > > > > +				   struct arm_smmu_ste *ste)
> > > > > +{
> > > > > +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > > > > +
> > > > > +	if (arm_smmu_master_sva_enabled(master))
> > > > > +		return -EBUSY;
> > > > > +
> > > > > +	/*
> > > > > +	 * Do not allow any ASID to be changed while are working on the STE,
> > > > > +	 * otherwise we could miss invalidations.
> > > > > +	 */
> > > > > +	mutex_lock(&arm_smmu_asid_lock);
> > > > > +
> > > > > +	/*
> > > > > +	 * The SMMU does not support enabling ATS with bypass/abort. When the
> > > > > +	 * STE is in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests
> > > > > +	 * and Translated transactions are denied as though ATS is disabled for
> > > > > +	 * the stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
> > > > > +	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
> > > > > +	 */
> > > > > +	arm_smmu_detach_dev(master);
> > > > > +
> > > > > +	arm_smmu_install_ste_for_dev(master, ste);
> > > > > +	mutex_unlock(&arm_smmu_asid_lock);
> > > > > +
> > > > > +	/*
> > > > > +	 * This has to be done after removing the master from the
> > > > > +	 * arm_smmu_domain->devices to avoid races updating the same context
> > > > > +	 * descriptor from arm_smmu_share_asid().
> > > > > +	 */
> > > > > +	if (master->cd_table.cdtab)
> > > > > +		arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);
> > > >  
> > > > This arm_smmu_write_ctx_desc was previously within the asid lock
> > > > protection, yet now it's moved out of that?
> > > 
> > > Yes, arm_smmu_write_ctx_desc() updates a CD table entry and that does
> > > not need ASID lock protection. The ASID lock exists because of the BTM
> > > code rewriting STEs asyncronously.
> > 
> > I see. Thanks for elaborating. For this patch
> 
> Actually wait, that explanation is not right..
> 
> The BTM code is changing the ASID which is done with a CD update
> 
> The ordering is OK here because the BTM code iterates over the
> &smmu_domain->devices list.
> 
> The arm_smmu_detach_dev() has removed the master from the devices list
> under a lock so the BTM code won't see this.
> 
> Thus there is no race between the arm_smmu_share_asid() flow and this
> code, indeed we've already removed the cdtable from the STE at this
> point.

I see. Maybe worth mentioning this in the comments above or commit
message?

Also, the arm_smmu_attach_dev_ste seems to be used by IDENTITY and
BLOCK domains only. This turns its nature to be a cleanup function
against a translate domain, while the naming sounds very generic.
I cannot think of any better name than this one, yet maybe we can
highlight this with a line of comments above the function?

Nicolin


From wahrenst at gmx.net  Tue Dec  5 10:22:14 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 5 Dec 2023 19:22:14 +0100
Subject: [PATCH] ARM: dts: imx28-lwe: Pass device_type to the memory node
In-Reply-To: <20231205131838.2013872-1-festevam@gmail.com>
References: <20231205131838.2013872-1-festevam@gmail.com>
Message-ID: <1e858267-2c75-42fa-a114-c425e8809d29@gmx.net>

Am 05.12.23 um 14:18 schrieb Fabio Estevam:
> From: Fabio Estevam <festevam at denx.de>
>
> Per memory.yaml, 'device_type' is a required property.
>
> Pass it to fix the following dt-schema warning:
>
> imx28-xea.dtb: /: memory at 40000000: 'device_type' is a required property
> 	from schema $id: http://devicetree.org/schemas/memory.yaml#
>
> Signed-off-by: Fabio Estevam <festevam at denx.de>
Reviewed-by: Stefan Wahren <wahrenst at gmx.net>


From tharvey at gateworks.com  Tue Dec  5 10:22:41 2023
From: tharvey at gateworks.com (Tim Harvey)
Date: Tue,  5 Dec 2023 10:22:41 -0800
Subject: [PATCH] arm64: dts: imx8mm-venice-gw7: Fix pci sub-nodes
Message-ID: <20231205182241.2550284-1-tharvey@gateworks.com>

Several schema warnings were fixed in commit
d61c5068729a ("arm64: dts: imx8mm-venice-gw7: Fix pci sub-nodes")
however the node names and the ethernet NIC node were not quite correct.

Fix the node names as the ethernet device should have a node name of
'ethernet' and remove the device_type, #address-cells, #size-cells, and
ranges properties that should only be on busses/bridges.

Fixes: d61c5068729a ("arm64: dts: imx8mm-venice-gw7: Fix pci sub-nodes")
Signed-off-by: Tim Harvey <tharvey at gateworks.com>
---
 .../dts/freescale/imx8mm-venice-gw72xx.dtsi    | 18 +++++++-----------
 .../dts/freescale/imx8mm-venice-gw73xx.dtsi    | 18 +++++++-----------
 .../dts/freescale/imx8mm-venice-gw7902.dts     | 10 +++-------
 3 files changed, 17 insertions(+), 29 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
index a337e8f20441..31f16f7cf37c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi
@@ -157,33 +157,29 @@ &pcie0 {
 				 <&clk IMX8MM_SYS_PLL2_250M>;
 	status = "okay";
 
-	pcie at 0,0 {
-		reg = <0x0000 0 0 0 0>;
+	pcie at 0 {
 		device_type = "pci";
+		reg = <0x0000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		ranges;
 
-		pcie at 0,0 {
-			reg = <0x0000 0 0 0 0>;
+		pcie at 0 {
 			device_type = "pci";
+			reg = <0x0000 0 0 0 0>;
 			#address-cells = <3>;
 			#size-cells = <2>;
 			ranges;
 
-			pcie at 3,0 {
-				reg = <0x1800 0 0 0 0>;
+			pcie at 3 {
 				device_type = "pci";
+				reg = <0x1800 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
 				ranges;
 
-				eth1: pcie at 0,0 {
+				eth1: ethernet at 0 {
 					reg = <0x0000 0 0 0 0>;
-					device_type = "pci";
-					#address-cells = <3>;
-					#size-cells = <2>;
-					ranges;
 
 					local-mac-address = [00 00 00 00 00 00];
 				};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi
index 2247d1c4e2af..6f5a6d91c95e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi
@@ -177,33 +177,29 @@ &pcie0 {
 				 <&clk IMX8MM_SYS_PLL2_250M>;
 	status = "okay";
 
-	pcie at 0,0 {
-		reg = <0x0000 0 0 0 0>;
+	pcie at 0 {
 		device_type = "pci";
+		reg = <0x0000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		ranges;
 
-		pcie at 0,0 {
-			reg = <0x0000 0 0 0 0>;
+		pcie at 0 {
 			device_type = "pci";
+			reg = <0x0000 0 0 0 0>;
 			#address-cells = <3>;
 			#size-cells = <2>;
 			ranges;
 
-			pcie at 4,0 {
-				reg = <0x2000 0 0 0 0>;
+			pcie at 4 {
 				device_type = "pci";
+				reg = <0x2000 0 0 0 0>;
 				#address-cells = <3>;
 				#size-cells = <2>;
 				ranges;
 
-				eth1: pcie at 0,0 {
+				eth1: ethernet at 0 {
 					reg = <0x0000 0 0 0 0>;
-					device_type = "pci";
-					#address-cells = <3>;
-					#size-cells = <2>;
-					ranges;
 
 					local-mac-address = [00 00 00 00 00 00];
 				};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7902.dts b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7902.dts
index 7ef17c2b0e9d..4bb22fdc5d2e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7902.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7902.dts
@@ -633,19 +633,15 @@ &pcie0 {
 				 <&clk IMX8MM_SYS_PLL2_250M>;
 	status = "okay";
 
-	pcie at 0,0 {
-		reg = <0x0000 0 0 0 0>;
+	pcie at 0 {
 		device_type = "pci";
+		reg = <0x0000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		ranges;
 
-		eth1: pcie at 0,0 {
+		eth1: ethernet at 0 {
 			reg = <0x0000 0 0 0 0>;
-			device_type = "pci";
-			#address-cells = <3>;
-			#size-cells = <2>;
-			ranges;
 
 			local-mac-address = [00 00 00 00 00 00];
 		};
-- 
2.25.1



From u-kumar1 at ti.com  Tue Dec  5 10:31:49 2023
From: u-kumar1 at ti.com (Kumar, Udit)
Date: Wed, 6 Dec 2023 00:01:49 +0530
Subject: [PATCH 0/3] arm64: dts: ti: Add Itap Delay Value For High Speed
 DDR
In-Reply-To: <20231201082045.790478-1-b-kapoor@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
Message-ID: <30baf959-e486-4804-947b-516e53cce6fa@ti.com>

Hi Bhavya

On 12/1/2023 1:50 PM, Bhavya Kapoor wrote:
> This Series adds Itap Delay Value for DDR52 speed mode for eMMC in
> J7200 and for DDR50 speed mode for MMCSD in J721s2 and J784s4 SoC.
>
> Rebased to next-20231201
>
> Bhavya Kapoor (3):
>    arm64: dts: ti: k3-j7200-main: Add Itap Delay Value For DDR52 speed
>      mode
>    arm64: dts: ti: k3-j721s2-main: Add Itap Delay Value For DDR50 speed
>      mode
>    arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed
>      mode

Could you confirm, after adding itap values, above modes are working 
fine apart from

mode detection.

Thanks

Udit


>   arch/arm64/boot/dts/ti/k3-j7200-main.dtsi  | 1 +
>   arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 1 +
>   arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 1 +
>   3 files changed, 3 insertions(+)
>


From wahrenst at gmx.net  Tue Dec  5 10:32:00 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 5 Dec 2023 19:32:00 +0100
Subject: [PATCH] ARM: dts: imx28-tx28: Pass #sound-dai-cells
In-Reply-To: <20231205145335.2055549-1-festevam@gmail.com>
References: <20231205145335.2055549-1-festevam@gmail.com>
Message-ID: <d2029304-ec7e-4679-aecf-bdeedcd88242@gmx.net>

Hi Fabio,

Am 05.12.23 um 15:53 schrieb Fabio Estevam:
> From: Fabio Estevam <festevam at denx.de>
>
> Per sgtl5000.yaml, '#sound-dai-cells' is a required property.
>
> Pass it to fix the following dt-schema warning:
>
> imx28-tx28.dtb: sgtl5000 at a: '#sound-dai-cells' is a required property
> 	from schema $id: http://devicetree.org/schemas/sound/sgtl5000.yaml#
>
> Signed-off-by: Fabio Estevam <festevam at denx.de>
> ---
>   arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts b/arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts
> index 153e4017951d..5485fe118dc4 100644
> --- a/arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts
> +++ b/arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts
> @@ -260,6 +260,7 @@ &i2c0 {
>   	sgtl5000: sgtl5000 at a {
this patch is fine

Reviewed-by: Stefan Wahren <wahrenst at gmx.net>

but this node name looks wrong.

It should be sgtl5000: codec at a

Regards
>   		compatible = "fsl,sgtl5000";
>   		reg = <0x0a>;
> +		#sound-dai-cells = <0>;
>   		VDDA-supply = <&reg_2p5v>;
>   		VDDIO-supply = <&reg_3p3v>;
>   		clocks = <&mclk>;



From wash at amazon.com  Tue Dec  5 10:33:54 2023
From: wash at amazon.com (Ashley, William)
Date: Tue, 5 Dec 2023 18:33:54 +0000
Subject: armv8pmu: Pending overflow interrupt is discarded when perf event is
 disabled
In-Reply-To: <ZW9ooVL32WB8U4YB@FVFF77S0Q05N>
References: <950001BD-490C-4BAC-8EEA-CDB9F7C4ADFC@amazon.com>
 <EBAF38AB-2BE5-425F-8A52-DDCB0B390309@amazon.com>
 <ZWdoNWps4izj5WJy@FVFF77S0Q05N.cambridge.arm.com>
 <ZWh2pnR_Z5-CKuZb@FVFF77S0Q05N> <ZWh-sbrHJu2b-BU6@FVFF77S0Q05N>
 <ZW9ooVL32WB8U4YB@FVFF77S0Q05N>
Message-ID: <891FE9D7-E036-4EA8-8D77-CF90C1CD54D1@amazon.com>

Mark,
Thanks for your time on this. Is there (any more of) a chance of getting a false second overflow signal with these changes? Especially for example when the counter is counting EL1, or when pseudo-nmi is enabled?


?On 12/5/23, 12:15 PM, "Mark Rutland" <mark.rutland at arm.com <mailto:mark.rutland at arm.com>> wrote:


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.






On Thu, Nov 30, 2023 at 12:23:13PM +0000, Mark Rutland wrote:
> On Thu, Nov 30, 2023 at 11:48:54AM +0000, Mark Rutland wrote:
> > On Wed, Nov 29, 2023 at 04:35:01PM +0000, Mark Rutland wrote:
> > > Does RR set any of the perf_event_attr::exclude_* bits? If not, does RR
> > > intentionally count events that occur within the kernel?
> >
> > Looking at the test, I see it sets perf_event_attr::exclude_kernel to 1, but
> > doesn't set perf_event_attr::exclude_host or perf_event_attr::exclude_hv. I
> > think the poorly-defined exclude_* bits are part of the problem here.
> >
> > Using your test as-is on my ThunderX2, I can reproduce the period being longer
> > than expected by concurrently running the following in a shell:
> >
> > while true; do
> > for C in $(seq 0 63); do
> > taskset -c -p $C ${TEST_PID_HERE};
> > done;
> > done > /dev/null
> >
> > ... resulting in:
> >
> > | [mark at gravadlaks:~]% ./counter-overflow
> > | Pid 20060 running with period 10000 tolerance 1000
> > | Signal #1: last: 0, cur: 10292, max diff: 0
> > | Signal #415330: delta of 19999 is outside 10000 +/- 1000
> > | Signal #415330: last: 4153290187, cur: 4153310186, max diff: 10292
> > | Signal #489879: delta of 19998 is outside 10000 +/- 1000
> > | Signal #511842: delta of 20058 is outside 10000 +/- 1000
> > | Signal #511842: last: 5118430130, cur: 5118450188, max diff: 19999
> >
> > However, if I modify the test to also set perf_event_attr::exclude_host=1, I do
> > not see any lost overflows after many minutes. On VHE hosts (like the
> > ThunderX2), the host kernel gets counted when perf_event_attr::exclude_host=0,
> > even if perf_event_attr::exclude_kernel=1 (which I agree is surprising), so I
> > think what's happening is the counters are counting in the host kernel, which
> > isn't what RR actually wants regardless.
>
> > I'll continue to look at what we can do kernel-side, but I reckon it's worth
> > having RR try the other exclude bits regardless, if that's possible? It would
> > be interesting to know whether that helps you under a hypervisor.
>
> Sorry, the above is wrong, and I do not recommend RR goes and changes its
> exclude_* settings.
>
> I had misread the logic in armv8pmu_set_event_filter(), but looking again
> that's saner than I thought it was, and what was actually happening in my
> testing is that exclude_host also filtered host EL0 (userspace), and so the
> test received *no* overflow signals.
>
> I'll get back to looking at how we can better capture the overflow when
> removing an event.


I've spent a couple of days on this, and I have a prototype at:


https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=perf/overflow <https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=perf/overflow>


The gist of that is:


* It's not viable to sample at start/stop time since we don't have all the
usual sample state (e.g. pt_regs), which means that we have to save/restore
the overflow status and rely on the regular interrupt handler to actually
sample after this is restored.


* Saving/restoring the overflow status requires reworking the way we manage the
sample period, separating the sample period from the period we program into
HW. This part looks fairly sane, but requires some rework of all the arm_pmu
drivers.


* We might need a couple of small changes to the perf core code (e.g. for the
IOCTLs that mess with the period), and this change is liable to affect other
architectures, so we'd need ot go audit that.


I reckon it's possible (with some testing and review) to get something like
this series merged, but I suspect it's too big for a stable backport.


Mark.




From catalin.marinas at arm.com  Tue Dec  5 10:40:42 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 5 Dec 2023 18:40:42 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <86a5qobkt8.wl-maz@kernel.org>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <86bkb4bn2v.wl-maz@kernel.org>
 <ZW9ezSGSDIvv5MsQ@arm.com>
 <86a5qobkt8.wl-maz@kernel.org>
Message-ID: <ZW9uqu7yOtyZfmvC@arm.com>

On Tue, Dec 05, 2023 at 05:50:27PM +0000, Marc Zyngier wrote:
> On Tue, 05 Dec 2023 17:33:01 +0000,
> Catalin Marinas <catalin.marinas at arm.com> wrote:
> > Ideally we should do this for vfio only but we don't have an easy
> > way to convey this to KVM.
> 
> But if we want to limit this to PCIe, we'll have to find out. The
> initial proposal (a long while ago) had a flag conveying some
> information, and I'd definitely feel more confident having something
> like that.

We can add a VM_PCI_IO in the high vma flags to be set by
vfio_pci_core_mmap(), though it limits it to 64-bit architectures. KVM
knows this is PCI and relaxes things a bit. It's not generic though if
we need this later for something else.

A question for Lorenzo: do these BARs appear in iomem_resource? We could
search that up instead of a flag, something like the page_is_ram()
helper.

-- 
Catalin


From francesco at dolcini.it  Tue Dec  5 10:46:04 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Tue,  5 Dec 2023 19:46:04 +0100
Subject: [PATCH v3 2/3] dt-bindings: arm: ti: add verdin am62 mallow board
In-Reply-To: <20231205184605.35225-1-francesco@dolcini.it>
References: <20231205184605.35225-1-francesco@dolcini.it>
Message-ID: <20231205184605.35225-3-francesco@dolcini.it>

From: Joao Paulo Goncalves <joao.goncalves at toradex.com>

Add Mallow carrier board for wifi and nonwifi variants of Toradex Verdin
AM62 SoM. Mallow is a low-cost carrier board in the Verdin family with
a small form factor and build for volume production making it ideal for
industrial and embedded applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Joao Paulo Goncalves <joao.goncalves at toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
 Documentation/devicetree/bindings/arm/ti/k3.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 03d2a0d79fb0..c6506bccfe88 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -50,6 +50,7 @@ properties:
           - enum:
               - toradex,verdin-am62-nonwifi-dahlia # Verdin AM62 Module on Dahlia
               - toradex,verdin-am62-nonwifi-dev    # Verdin AM62 Module on Verdin Development Board
+              - toradex,verdin-am62-nonwifi-mallow # Verdin AM62 Module on Mallow
               - toradex,verdin-am62-nonwifi-yavia  # Verdin AM62 Module on Yavia
           - const: toradex,verdin-am62-nonwifi     # Verdin AM62 Module without Wi-Fi / BT
           - const: toradex,verdin-am62             # Verdin AM62 Module
@@ -60,6 +61,7 @@ properties:
           - enum:
               - toradex,verdin-am62-wifi-dahlia # Verdin AM62 Wi-Fi / BT Module on Dahlia
               - toradex,verdin-am62-wifi-dev    # Verdin AM62 Wi-Fi / BT M. on Verdin Development B.
+              - toradex,verdin-am62-wifi-mallow # Verdin AM62 Wi-Fi / BT Module on Mallow
               - toradex,verdin-am62-wifi-yavia  # Verdin AM62 Wi-Fi / BT Module on Yavia
           - const: toradex,verdin-am62-wifi     # Verdin AM62 Wi-Fi / BT Module
           - const: toradex,verdin-am62          # Verdin AM62 Module
-- 
2.25.1



From francesco at dolcini.it  Tue Dec  5 10:46:05 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Tue,  5 Dec 2023 19:46:05 +0100
Subject: [PATCH v3 3/3] arm64: dts: ti: add verdin am62 mallow board
In-Reply-To: <20231205184605.35225-1-francesco@dolcini.it>
References: <20231205184605.35225-1-francesco@dolcini.it>
Message-ID: <20231205184605.35225-4-francesco@dolcini.it>

From: Joao Paulo Goncalves <joao.goncalves at toradex.com>

Add Toradex Verdin AM62 Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

Signed-off-by: Joao Paulo Goncalves <joao.goncalves at toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
v2: fixed temperature sensor compatible (s/tmp75c/tmp1075)
v3: removed TPM node
---
 arch/arm64/boot/dts/ti/Makefile               |   2 +
 .../boot/dts/ti/k3-am62-verdin-mallow.dtsi    | 188 ++++++++++++++++++
 .../dts/ti/k3-am625-verdin-nonwifi-mallow.dts |  22 ++
 .../dts/ti/k3-am625-verdin-wifi-mallow.dts    |  22 ++
 4 files changed, 234 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 77a347f9f47d..92ebf001a217 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -16,9 +16,11 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-phyboard-lyra-rdk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-sk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dev.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-mallow.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-yavia.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dev.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-mallow.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-yavia.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am62-lp-sk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am625-sk-hdmi-audio.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
new file mode 100644
index 000000000000..17b93534f658
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ *
+ * Common dtsi for Verdin AM62 SoM on Mallow carrier board
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
+ * https://www.toradex.com/products/carrier-board/mallow-carrier-board
+ */
+
+#include <dt-bindings/leds/common.h>
+
+/ {
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_qspi1_clk_gpio>,
+			    <&pinctrl_qspi1_cs_gpio>,
+			    <&pinctrl_qspi1_io0_gpio>,
+			    <&pinctrl_qspi1_io1_gpio>;
+
+		/* SODIMM 52 - USER_LED_1_RED */
+		led-0 {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <1>;
+			gpios = <&main_gpio0 0 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 54 - USER_LED_1_GREEN */
+		led-1 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <1>;
+			gpios = <&main_gpio0 11 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 56 - USER_LED_2_RED */
+		led-2 {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <2>;
+			gpios = <&main_gpio0 3 GPIO_ACTIVE_HIGH>;
+		};
+
+		/* SODIMM 58 - USER_LED_2_GREEN */
+		led-3 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_DEBUG;
+			function-enumerator = <2>;
+			gpios = <&main_gpio0 4 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+/* Verdin ETH */
+&cpsw3g {
+	status = "okay";
+};
+
+/* Verdin MDIO */
+&cpsw3g_mdio {
+	status = "okay";
+};
+
+/* Verdin ETH_1*/
+&cpsw_port1 {
+	status = "okay";
+};
+
+/* Verdin PWM_1 and PWM_2*/
+&epwm0 {
+	status = "okay";
+};
+
+/* Verdin PWM_3 DSI */
+&epwm1 {
+	status = "okay";
+};
+
+&main_gpio0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ctrl_sleep_moci>,
+		    <&pinctrl_gpio_1>,
+		    <&pinctrl_gpio_2>,
+		    <&pinctrl_gpio_3>,
+		    <&pinctrl_gpio_4>;
+};
+
+/* Verdin I2C_1 */
+&main_i2c1 {
+	status = "okay";
+
+	/* Temperature sensor */
+	sensor at 4f {
+		compatible = "ti,tmp1075";
+		reg = <0x4f>;
+	};
+
+	/* EEPROM */
+	eeprom at 57 {
+		compatible = "st,24c02", "atmel,24c02";
+		reg = <0x57>;
+		pagesize = <16>;
+	};
+};
+
+/* Verdin I2C_2 DSI */
+&main_i2c2 {
+	status = "okay";
+};
+
+/* Verdin I2C_4 CSI */
+&main_i2c3 {
+	status = "okay";
+};
+
+/* Verdin CAN_1 */
+&main_mcan0 {
+	status = "okay";
+};
+
+/* Verdin SPI_1 */
+&main_spi1 {
+	pinctrl-0 = <&pinctrl_spi1>,
+		    <&pinctrl_spi1_cs0>,
+		    <&pinctrl_qspi1_cs2_gpio>;
+	cs-gpios = <0>, <&main_gpio0 12 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+/* Verdin UART_3 */
+&main_uart0 {
+	status = "okay";
+};
+
+/* Verdin UART_1 */
+&main_uart1 {
+	status = "okay";
+};
+
+/* Verdin I2C_3_HDMI */
+&mcu_i2c0 {
+	status = "okay";
+};
+
+/* Verdin CAN_2 */
+&mcu_mcan0 {
+	status = "okay";
+};
+
+/* Verdin UART_4 */
+&mcu_uart0 {
+	status = "okay";
+};
+
+/* Verdin SD_1 */
+&sdhci1 {
+	status = "okay";
+};
+
+/* Verdin USB_1 */
+&usbss0 {
+	status = "okay";
+};
+
+&usb0 {
+	status = "okay";
+};
+
+/* Verdin USB_2 */
+&usbss1 {
+	status = "okay";
+};
+
+&usb1 {
+	status = "okay";
+};
+
+/* Verdin CTRL_WAKE1_MICO# */
+&verdin_gpio_keys {
+	status = "okay";
+};
+
+/* Verdin UART_2 */
+&wkup_uart0 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts b/arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts
new file mode 100644
index 000000000000..9cae12106e0e
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
+ * https://www.toradex.com/products/carrier-board/mallow-carrier-board
+ */
+
+/dts-v1/;
+
+#include "k3-am625.dtsi"
+#include "k3-am62-verdin.dtsi"
+#include "k3-am62-verdin-nonwifi.dtsi"
+#include "k3-am62-verdin-mallow.dtsi"
+
+/ {
+	model = "Toradex Verdin AM62 on Mallow Board";
+	compatible = "toradex,verdin-am62-nonwifi-mallow",
+		     "toradex,verdin-am62-nonwifi",
+		     "toradex,verdin-am62",
+		     "ti,am625";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts b/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts
new file mode 100644
index 000000000000..81d834b22649
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
+ * https://www.toradex.com/products/carrier-board/mallow-carrier-board
+ */
+
+/dts-v1/;
+
+#include "k3-am625.dtsi"
+#include "k3-am62-verdin.dtsi"
+#include "k3-am62-verdin-wifi.dtsi"
+#include "k3-am62-verdin-mallow.dtsi"
+
+/ {
+	model = "Toradex Verdin AM62 WB on Mallow Board";
+	compatible = "toradex,verdin-am62-wifi-mallow",
+		     "toradex,verdin-am62-wifi",
+		     "toradex,verdin-am62",
+		     "ti,am625";
+};
-- 
2.25.1



From francesco at dolcini.it  Tue Dec  5 10:46:02 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Tue,  5 Dec 2023 19:46:02 +0100
Subject: [PATCH v3 0/3]  arm64: dts: ti: add verdin am62 mallow board
Message-ID: <20231205184605.35225-1-francesco@dolcini.it>

From: Francesco Dolcini <francesco.dolcini at toradex.com>

Add Toradex Verdin AM62 Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.

https://www.toradex.com/products/carrier-board/mallow-carrier-board

v1:
 - https://lore.kernel.org/all/20231123112826.16549-1-francesco at dolcini.it/

v2:
 - https://lore.kernel.org/all/20231201145551.23337-1-francesco at dolcini.it/
 - fixed temperature sensor compatible (s/tmp75c/tmp1075)
 - add Acked-by: Krzysztof

v3:
 - remove TPM node

Joao Paulo Goncalves (3):
  arm64: dts: ti: verdin-am62: improve spi1 chip-select pinctrl
  dt-bindings: arm: ti: add verdin am62 mallow board
  arm64: dts: ti: add verdin am62 mallow board

 .../devicetree/bindings/arm/ti/k3.yaml        |   2 +
 arch/arm64/boot/dts/ti/Makefile               |   2 +
 .../boot/dts/ti/k3-am62-verdin-mallow.dtsi    | 188 ++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi    |  17 +-
 .../dts/ti/k3-am625-verdin-nonwifi-mallow.dts |  22 ++
 .../dts/ti/k3-am625-verdin-wifi-mallow.dts    |  22 ++
 6 files changed, 251 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts

-- 
2.25.1



From francesco at dolcini.it  Tue Dec  5 10:46:03 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Tue,  5 Dec 2023 19:46:03 +0100
Subject: [PATCH v3 1/3] arm64: dts: ti: verdin-am62: improve spi1 chip-select pinctrl
In-Reply-To: <20231205184605.35225-1-francesco@dolcini.it>
References: <20231205184605.35225-1-francesco@dolcini.it>
Message-ID: <20231205184605.35225-2-francesco@dolcini.it>

From: Joao Paulo Goncalves <joao.goncalves at toradex.com>

Verdin SPI_1 interface has a dedicated hardware controlled chip select
that is currently configured in the same pinctrl group as MISO/MOSI/CLK,
however it is possible that it can be used only as a standard GPIO be it
a chip select or not.

To maximize flexibility and avoid duplication in the carrier board dts
files move the SPI_1 CS in a dedicated pinctrl and also adds an
additional pinctrl to simplify using SPI_1 CS as a GPIO.

Signed-off-by: Joao Paulo Goncalves <joao.goncalves at toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
 arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
index 5db52f237253..6a06724b6d16 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
@@ -233,6 +233,13 @@ AM62X_IOPAD(0x0018, PIN_INPUT, 7) /* (F24) OSPI0_D3.GPIO0_6 */ /* SODIMM 62 */
 		>;
 	};
 
+	/* Verdin SPI_1 CS as GPIO */
+	pinctrl_qspi1_io4_gpio: main-gpio0-7-default-pins {
+		pinctrl-single,pins = <
+			AM62X_IOPAD(0x001c, PIN_INPUT, 7) /* (J23) OSPI0_D4.GPIO0_7 */ /* SODIMM 202 */
+		>;
+	};
+
 	/* Verdin QSPI_1_CS# as GPIO (conflict with Verdin QSPI_1 interface) */
 	pinctrl_qspi1_cs_gpio: main-gpio0-11-default-pins {
 		pinctrl-single,pins = <
@@ -599,12 +606,18 @@ AM62X_IOPAD(0x164, PIN_OUTPUT, 0) /* (AA19) RGMII2_TX_CTL */ /* SODIMM 211 */
 	pinctrl_spi1: main-spi1-default-pins {
 		pinctrl-single,pins = <
 			AM62X_IOPAD(0x0020, PIN_INPUT, 1) /* (J25) OSPI0_D5.SPI1_CLK */ /* SODIMM 196 */
-			AM62X_IOPAD(0x001c, PIN_INPUT, 1) /* (J23) OSPI0_D4.SPI1_CS0 */ /* SODIMM 202 */
 			AM62X_IOPAD(0x0024, PIN_INPUT, 1) /* (H25) OSPI0_D6.SPI1_D0  */ /* SODIMM 200 */
 			AM62X_IOPAD(0x0028, PIN_INPUT, 1) /* (J22) OSPI0_D7.SPI1_D1  */ /* SODIMM 198 */
 		>;
 	};
 
+	/* Verdin SPI_1 CS */
+	pinctrl_spi1_cs0: main-spi1-cs0-default-pins {
+		pinctrl-single,pins = <
+			AM62X_IOPAD(0x001c, PIN_INPUT, 1) /* (J23) OSPI0_D4.SPI1_CS0 */ /* SODIMM 202 */
+		>;
+	};
+
 	/* ETH_25MHz_CLK */
 	pinctrl_eth_clock: main-system-clkout0-default-pins {
 		pinctrl-single,pins = <
@@ -1278,7 +1291,7 @@ &main_mcan0 {
 /* Verdin SPI_1 */
 &main_spi1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_spi1>;
+	pinctrl-0 = <&pinctrl_spi1>, <&pinctrl_spi1_cs0>;
 	ti,pindir-d0-out-d1-in;
 	status = "disabled";
 };
-- 
2.25.1



From mmayer at broadcom.com  Tue Dec  5 10:47:33 2023
From: mmayer at broadcom.com (Markus Mayer)
Date: Tue,  5 Dec 2023 10:47:33 -0800
Subject: [PATCH 0/4] memory: brcmstb_dpfe: support DPFE API v4
Message-ID: <20231205184741.3092376-1-mmayer@broadcom.com>

It has become necessary to distinguish between the various DPFE API
versions by version number. Having just chip-specific compatible strings
and one generic version is no longer meeting our needs.

Also, a new DPFE API version, v4, needs to be supported by the driver.

As a result, an intermediate compatible string format is being
introduced: brcm,dpfe-cpu-v<N> where <N> represents the API version
number. This is more specific than the catch-all "brcm,dpfe-cpu" and
more generic than chip-specific compatible strings, such as
"brcm,bcm7271-dpfe-cpu".

The changes are split into several steps.

First, we update the binding and introduce the versioned compatible
strings.

Secondly, we add support for brcm,dpfe-cpu-v1 through brcm,dpfe-cpu-v3
in the driver to match existing API versions.

Thirdly, we introduce DPFE API v4.

Lastly, there is a change that isn't directly related to the
introduction of the new binding format or DPFE API v4. However, with the
increasing number of API versions, broadening compatibility can be
helpful. If registering the driver using the DT-provided compatible
string fails, the driver will try all DPFE APIs (except for v1) to see
if one might end up working. This can come in handy if the driver moves
on and learns about new API versions while Device Tree cannot be
updated.

Markus Mayer (4):
  dt-bindings: memory: additional compatible strings for Broadcom DPFE
  memory: brcmstb_dpfe: introduce version-specific compatible strings
  memory: brcmstb_dpfe: support DPFE API v4
  memory: brcmstb_dpfe: introduce best-effort API detection

 .../memory-controllers/brcm,dpfe-cpu.yaml     |  8 +-
 drivers/memory/brcmstb_dpfe.c                 | 95 ++++++++++++++++++-
 2 files changed, 100 insertions(+), 3 deletions(-)

-- 
2.43.0



From mmayer at broadcom.com  Tue Dec  5 10:47:34 2023
From: mmayer at broadcom.com (Markus Mayer)
Date: Tue,  5 Dec 2023 10:47:34 -0800
Subject: [PATCH 1/4] dt-bindings: memory: additional compatible strings for Broadcom DPFE
In-Reply-To: <20231205184741.3092376-1-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
Message-ID: <20231205184741.3092376-2-mmayer@broadcom.com>

Add versioned compatible strings for Broadcom DPFE. These take the form
brcm,dpfe-cpu-v<N> where <N> is a number from 1 to 4.

These API version related compatible strings are more specific than the
catch-all "brcm,dpfe-cpu" and more generic than chip-specific compatible
strings.

Signed-off-by: Markus Mayer <mmayer at broadcom.com>
---
 .../bindings/memory-controllers/brcm,dpfe-cpu.yaml        | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
index 08cbdcddfead..6dffa7b62baf 100644
--- a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
@@ -16,6 +16,11 @@ properties:
       - enum:
           - brcm,bcm7271-dpfe-cpu
           - brcm,bcm7268-dpfe-cpu
+      - enum:
+          - brcm,dpfe-cpu-v1
+          - brcm,dpfe-cpu-v2
+          - brcm,dpfe-cpu-v3
+          - brcm,dpfe-cpu-v4
       - const: brcm,dpfe-cpu
 
   reg:
@@ -40,7 +45,8 @@ additionalProperties: false
 examples:
   - |
     dpfe-cpu at f1132000 {
-        compatible = "brcm,bcm7271-dpfe-cpu", "brcm,dpfe-cpu";
+        compatible = "brcm,bcm7271-dpfe-cpu", "brcm,dpfe-cpu-v1",
+              "brcm,dpfe-cpu";
         reg = <0xf1132000 0x180>,
               <0xf1134000 0x1000>,
               <0xf1138000 0x4000>;
-- 
2.43.0



From mmayer at broadcom.com  Tue Dec  5 10:47:35 2023
From: mmayer at broadcom.com (Markus Mayer)
Date: Tue,  5 Dec 2023 10:47:35 -0800
Subject: [PATCH 2/4] memory: brcmstb_dpfe: introduce version-specific compatible strings
In-Reply-To: <20231205184741.3092376-1-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
Message-ID: <20231205184741.3092376-3-mmayer@broadcom.com>

Introduce compatible strings brcm,dpfe-cpu-v1 through brcm,dpfe-cpu-v3
to the Broadcom DPFE driver.

Signed-off-by: Markus Mayer <mmayer at broadcom.com>
---
 drivers/memory/brcmstb_dpfe.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index a7ab3d377206..66876b409e59 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -924,6 +924,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
 	{ .compatible = "brcm,bcm7271-dpfe-cpu", .data = &dpfe_api_old_v2 },
 	{ .compatible = "brcm,bcm7278-dpfe-cpu", .data = &dpfe_api_old_v2 },
 	{ .compatible = "brcm,bcm7211-dpfe-cpu", .data = &dpfe_api_new_v2 },
+
+	/* Match specific DCPU versions */
+	{ .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
+	{ .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
+	{ .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
+
 	/* API v3 is the default going forward */
 	{ .compatible = "brcm,dpfe-cpu", .data = &dpfe_api_v3 },
 	{}
-- 
2.43.0



From mmayer at broadcom.com  Tue Dec  5 10:47:36 2023
From: mmayer at broadcom.com (Markus Mayer)
Date: Tue,  5 Dec 2023 10:47:36 -0800
Subject: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
In-Reply-To: <20231205184741.3092376-1-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
Message-ID: <20231205184741.3092376-4-mmayer@broadcom.com>

Add support for version 4 of the DPFE API. This new version is largely
identical to version 3. The main difference is that all commands now
take the MHS version number as the first argument. Any other arguments
have been pushed down by one (i.e. what used to be arg0 in v3 is arg1 in
v4).

Signed-off-by: Markus Mayer <mmayer at broadcom.com>
---
 drivers/memory/brcmstb_dpfe.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 66876b409e59..0b0a9b85b605 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -37,6 +37,9 @@
 
 #define DRVNAME			"brcmstb-dpfe"
 
+/* Generic constants */
+#define MHS_VERSION		0x04000000
+
 /* DCPU register offsets */
 #define REG_DCPU_RESET		0x0
 #define REG_TO_DCPU_MBOX	0x10
@@ -301,6 +304,28 @@ static const struct dpfe_api dpfe_api_v3 = {
 	},
 };
 
+/* API v4 firmware commands */
+static struct dpfe_api dpfe_api_v4 = {
+	.version = 4,
+	.fw_name = NULL, /* We expect the firmware to have been downloaded! */
+	.sysfs_attrs = dpfe_v3_groups, /* Same as v3 */
+	.command = {
+		[DPFE_CMD_GET_INFO] = {
+			[MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+			[MSG_COMMAND] = 0x0101,
+			[MSG_ARG_COUNT] = 2,
+			[MSG_ARG0] = MHS_VERSION,
+			[MSG_ARG0 + 1] = 1, /* Now the 2nd argument */
+		},
+		[DPFE_CMD_GET_REFRESH] = {
+			[MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+			[MSG_COMMAND] = 0x0202,
+			[MSG_ARG_COUNT] = 1,
+			[MSG_ARG0] = MHS_VERSION,
+		},
+	},
+};
+
 static const char *get_error_text(unsigned int i)
 {
 	static const char * const error_text[] = {
@@ -929,8 +954,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
 	{ .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
 	{ .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
 	{ .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
+	{ .compatible = "brcm,dpfe-cpu-v4", .data = &dpfe_api_v4 },
 
-	/* API v3 is the default going forward */
+	/*
+	 * For historical reasons, API v3 is the default if nothing else is
+	 * specified.
+	 */
 	{ .compatible = "brcm,dpfe-cpu", .data = &dpfe_api_v3 },
 	{}
 };
-- 
2.43.0



From acme at kernel.org  Tue Dec  5 10:48:38 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Tue, 5 Dec 2023 15:48:38 -0300
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <CAM9d7ciOp_O5N1TDX0HyKavykirByAYrqzcmM-_6ZWjMv-47WQ@mail.gmail.com>
References: <20231204182330.654255-1-irogers@google.com>
 <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
 <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com>
 <ZW9G8Clxwl6bd0H6@kernel.org>
 <CAM9d7ciOp_O5N1TDX0HyKavykirByAYrqzcmM-_6ZWjMv-47WQ@mail.gmail.com>
Message-ID: <ZW9whqUEILWMdcmi@kernel.org>

Em Tue, Dec 05, 2023 at 09:24:42AM -0800, Namhyung Kim escreveu:
> Hi Arnaldo,
> 
> On Tue, Dec 5, 2023 at 7:51?AM Arnaldo Carvalho de Melo <acme at kernel.org> wrote:
> >
> > Em Mon, Dec 04, 2023 at 07:33:18PM -0800, Namhyung Kim escreveu:
> > > On Mon, Dec 4, 2023 at 2:45?PM Ilkka Koskinen <ilkka at os.amperecomputing.com> wrote:
> > > > On Mon, 4 Dec 2023, Ian Rogers wrote:
> > > > > A metric is default by having "Default" within its groups. The default
> > > > > metricgroup name needn't be set and this can result in segv in
> > > > > default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
> > > > > that assume it has a value when there is a Default metric group. To
> > > > > avoid the segv initialize the value to "".
> >
> > > > > Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
> > > > > Signed-off-by: Ian Rogers <irogers at google.com>
> >
> > > > Thanks! I was going to look for the bug but got pulled to other
> > > > tasks. The patch looks good to me and I tested it successfully on
> > > > AmpereOne.
> >
> > > >    Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
> >
> > > Looks like it needs to go through perf-tools for v6.7.
> > > Ian, do you think this one is enough?
> >
> > So I had this on my local perf-tools-next, removed now, I also have some
> > other fixes by Ian on the tmp.perf-tools-next, please let me know what
> > you guys decide to have in perf-tools for v6.7 so that I can remove it
> > from there.
> 
> I think we need this one and the Ampere default-metric-group fix.
> 
> https://lore.kernel.org/r/20231201021550.1109196-2-ilkka at os.amperecomputing.com/
> 
> Also perf list JSON fix can go to v6.7.
> 
> https://lore.kernel.org/r/20231129213428.2227448-2-irogers at google.com/

Ok, removed both, please augment the later description to:

"perf list: Fix JSON segfault by setting the used skip_fuplicate_pmus callback"

The original description was vague, improving it a bit like that helps
when just looking at the output of "git log --oneline".

Thanks,

- Arnaldo



From mmayer at broadcom.com  Tue Dec  5 10:47:37 2023
From: mmayer at broadcom.com (Markus Mayer)
Date: Tue,  5 Dec 2023 10:47:37 -0800
Subject: [PATCH 4/4] memory: brcmstb_dpfe: introduce best-effort API detection
In-Reply-To: <20231205184741.3092376-1-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
Message-ID: <20231205184741.3092376-5-mmayer@broadcom.com>

Add a best-effort probe function that tries all known DPFE versions to
see if one might actually work. This helps in cases where device tree
doesn't provide the proper version information for whatever reason. In
that case, the driver may still be able to register if one of the known
API versions ends up working.

Caveat: we have to skip "v1" during our best effort attempts. This is
due to the fact that attempting a firmware download as required by v1
will result in a memory access violation on anything but v1 hardware.
This would crash the kernel. Since we don't know the HW version, we need
to play it safe and skip v1.

Signed-off-by: Markus Mayer <mmayer at broadcom.com>
---
 drivers/memory/brcmstb_dpfe.c | 58 ++++++++++++++++++++++++++++++++++-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 0b0a9b85b605..15f4ee3b8535 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -879,6 +879,50 @@ static int brcmstb_dpfe_resume(struct platform_device *pdev)
 	return brcmstb_dpfe_download_firmware(priv);
 }
 
+static int brcmstb_dpfe_probe_best_effort(struct platform_device *pdev)
+{
+	const char versioned_compat[] = "brcm,dpfe-cpu-v";
+	const char v1_str[] = "-v1";
+	const struct of_device_id *matches;
+	const struct dpfe_api *orig_dpfe_api;
+	struct device *dev = &pdev->dev;
+	struct brcmstb_dpfe_priv *priv;
+	int ret = -ENODEV;
+
+	priv = dev_get_drvdata(dev);
+	orig_dpfe_api = priv->dpfe_api;
+	matches = dev->driver->of_match_table;
+
+	/* Loop over all compatible strings */
+	for (; matches->compatible[0]; matches++) {
+		const char *compat = matches->compatible;
+		/* Find the ones that start with "brcm,dpfe-cpu-v" */
+		if (strstr(compat, versioned_compat) == compat) {
+			char *v1_ptr = strstr(compat, v1_str);
+			/*
+			 * We must skip v1, since we don't know the hardware
+			 * version and attempting a firmware download on v2 and
+			 * newer would crash the kernel due to a memory access
+			 * violation.
+			 * We make sure to match "-v1" at the end of the string
+			 * only.
+			 */
+			if (v1_ptr && v1_ptr[sizeof(v1_str)] == '\0')
+				continue;
+			priv->dpfe_api = matches->data;
+			/* Fingers crossed... */
+			ret = brcmstb_dpfe_download_firmware(priv);
+			if (!ret)
+				return 0;
+		}
+	}
+
+	/* It didn't work, so let's clean up. */
+	priv->dpfe_api = orig_dpfe_api;
+
+	return ret;
+}
+
 static int brcmstb_dpfe_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -923,8 +967,20 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
 	}
 
 	ret = brcmstb_dpfe_download_firmware(priv);
+	if (ret && ret != -EPROBE_DEFER) {
+		/*
+		 * If the information provided by Device Tree didn't work, let's
+		 * try all known version. Maybe one will work.
+		 */
+		dev_warn(dev,
+			"DPFE v%d didn't work, reverting to best-effort\n",
+			priv->dpfe_api->version);
+		dev_warn(dev,
+			"Device Tree and / or the driver should be updated\n");
+		ret = brcmstb_dpfe_probe_best_effort(pdev);
+	}
 	if (ret)
-		return dev_err_probe(dev, ret, "Couldn't download firmware\n");
+		return dev_err_probe(dev, ret, "Unable to talk to DCPU\n");
 
 	ret = sysfs_create_groups(&pdev->dev.kobj, priv->dpfe_api->sysfs_attrs);
 	if (!ret)
-- 
2.43.0



From wahrenst at gmx.net  Tue Dec  5 10:49:09 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 5 Dec 2023 19:49:09 +0100
Subject: [PATCH 1/2] ARM: mxs: Do not search for "fsl,clkctrl"
In-Reply-To: <20231205144713.2053916-1-festevam@gmail.com>
References: <20231205144713.2053916-1-festevam@gmail.com>
Message-ID: <82b93cc9-556f-434f-a48e-2c2353fbcd09@gmx.net>

Hi Fabio,

Am 05.12.23 um 15:47 schrieb Fabio Estevam:
> From: Fabio Estevam <festevam at denx.de>
>
> The "fsl,clkctrl" compatible string is not documented.
>
> It is used only to find the base address of the clock controller.
>
> Instead of searching for an undocumented compatible string, search
> for "fsl,imx23-clkctrl" and "fsl,imx28-clkctrl".
>
> Signed-off-by: Fabio Estevam <festevam at denx.de>
> ---
>   arch/arm/mach-mxs/mach-mxs.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
> index 3faf9a1e3e36..6e017fa306c8 100644
> --- a/arch/arm/mach-mxs/mach-mxs.c
> +++ b/arch/arm/mach-mxs/mach-mxs.c
> @@ -356,7 +356,9 @@ static int __init mxs_restart_init(void)
>   {
>   	struct device_node *np;
>
> -	np = of_find_compatible_node(NULL, NULL, "fsl,clkctrl");
> +	np = of_find_compatible_node(NULL, NULL, "fsl,imx23-clkctrl");
> +	if (!np)
> +		np = of_find_compatible_node(NULL, NULL, "fsl,imx28-clkctrl");
i'm fine with getting the rid off "fsl,clkctrl", but some lines below we
search for "fsl,imx23-clkctrl" again to adjust reset_addr.

Can we avoid this unnecessary search?
>   	reset_addr = of_iomap(np, 0);
>   	if (!reset_addr)
>   		return -ENODEV;



From wahrenst at gmx.net  Tue Dec  5 10:54:01 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 5 Dec 2023 19:54:01 +0100
Subject: [PATCH 2/2] ARM: dts: imx23/28: Remove undocumented "fsl,clkctrl"
In-Reply-To: <20231205144713.2053916-2-festevam@gmail.com>
References: <20231205144713.2053916-1-festevam@gmail.com>
 <20231205144713.2053916-2-festevam@gmail.com>
Message-ID: <2e1d1c3f-07a2-4e5a-81d5-7785254a2833@gmx.net>

Hi Fabio,

Am 05.12.23 um 15:47 schrieb Fabio Estevam:
> From: Fabio Estevam <festevam at denx.de>
>
> Per imx23-clock.yaml and imx28-clock.yaml, fsl,clkctrl is not a valid
> compatible string.
>
> Remove it to fix the following dt-schema warning:
>
> imx28-evk.dtb: clkctrl at 80040000: compatible: ['fsl,imx28-clkctrl', 'fsl,clkctrl'] is too long
> 	from schema $id: http://devicetree.org/schemas/clock/imx28-clock.yaml#
>
> Signed-off-by: Fabio Estevam <festevam at denx.de>
> ---
>   arch/arm/boot/dts/nxp/mxs/imx23.dtsi | 2 +-
>   arch/arm/boot/dts/nxp/mxs/imx28.dtsi | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx23.dtsi b/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
> index fdf18b7cb2f6..69e65e218afe 100644
> --- a/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
> +++ b/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
> @@ -484,7 +484,7 @@ apbx at 80040000 {
>   			ranges;
>
>   			clks: clkctrl at 80040000 {
> -				compatible = "fsl,imx23-clkctrl", "fsl,clkctrl";
> +				compatible = "fsl,imx23-clkctrl";
this look fine:

Reviewed-by: Stefan Wahren <wahrenst at gmx.net>

Btw the node name clkctrl is also incorrect here. According to the yaml
it should be clock-controller.

Regards
>   				reg = <0x80040000 0x2000>;
>   				#clock-cells = <1>;
>   			};
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
> index 6932d23fb29d..39b59619eb2e 100644
> --- a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
> +++ b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
> @@ -1100,7 +1100,7 @@ apbx at 80040000 {
>   			ranges;
>
>   			clks: clkctrl at 80040000 {
> -				compatible = "fsl,imx28-clkctrl", "fsl,clkctrl";
> +				compatible = "fsl,imx28-clkctrl";
>   				reg = <0x80040000 0x2000>;
>   				#clock-cells = <1>;
>   			};



From festevam at gmail.com  Tue Dec  5 10:57:16 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 5 Dec 2023 15:57:16 -0300
Subject: [PATCH] arm64: dts: imx8mm-venice-gw7: Fix pci sub-nodes
In-Reply-To: <20231205182241.2550284-1-tharvey@gateworks.com>
References: <20231205182241.2550284-1-tharvey@gateworks.com>
Message-ID: <CAOMZO5AWsytgARbfMdva31Yo3nB=BkjfkhQiXHY=nmWUGe3-DQ@mail.gmail.com>

Hi Tim,

On Tue, Dec 5, 2023 at 3:22?PM Tim Harvey <tharvey at gateworks.com> wrote:
>
> Several schema warnings were fixed in commit
> d61c5068729a ("arm64: dts: imx8mm-venice-gw7: Fix pci sub-nodes")
> however the node names and the ethernet NIC node were not quite correct.
>
> Fix the node names as the ethernet device should have a node name of
> 'ethernet' and remove the device_type, #address-cells, #size-cells, and
> ranges properties that should only be on busses/bridges.

I sent this one to address the remaining issues:

https://lore.kernel.org/linux-devicetree/20231130225242.988336-1-festevam at gmail.com/


From jhubbard at nvidia.com  Tue Dec  5 10:58:18 2023
From: jhubbard at nvidia.com (John Hubbard)
Date: Tue, 5 Dec 2023 10:58:18 -0800
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <888e20e4-6073-426c-9159-e359c758d78a@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <2be046e1-ef95-4244-ae23-e56071ae1218@nvidia.com>
 <888e20e4-6073-426c-9159-e359c758d78a@arm.com>
Message-ID: <d185a516-8d27-4e16-8c26-d9cd3f3de2a0@nvidia.com>

On 12/5/23 3:13 AM, Ryan Roberts wrote:
> On 05/12/2023 03:37, John Hubbard wrote:
>> On 12/4/23 02:20, Ryan Roberts wrote:
...
>> With those two patchsets applied, the mm selftests look OK--or at least
>> as OK as they normally do. I compared test runs between THP/mTHP set to
>> "always", vs "never", to verify that there were no new test failures.
>> Details: specifically, I set one particular page size (2 MB) to
>> "inherit", and then toggled /sys/kernel/mm/transparent_hugepage/enabled
>> between "always" and "never".
> 
> Excellent - I'm guessing this was for 64K base pages?


Yes.


thanks,

-- 
John Hubbard
NVIDIA


From jgg at nvidia.com  Tue Dec  5 11:03:21 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 15:03:21 -0400
Subject: [PATCH v2 15/19] iommu/arm-smmu-v3: Add a global static IDENTITY
 domain
In-Reply-To: <ZW9qHsORHC5obMLS@Asurada-Nvidia>
References: <0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <15-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg@nvidia.com>
 <ZW6m54yS2rpk65kE@Asurada-Nvidia>
 <20231205143742.GB2787277@nvidia.com>
 <ZW9dJ1yzsdCjpMGm@Asurada-Nvidia>
 <20231205174219.GI2692119@nvidia.com>
 <ZW9qHsORHC5obMLS@Asurada-Nvidia>
Message-ID: <20231205190321.GK2692119@nvidia.com>

On Tue, Dec 05, 2023 at 10:21:18AM -0800, Nicolin Chen wrote:
> On Tue, Dec 05, 2023 at 01:42:19PM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 05, 2023 at 09:25:59AM -0800, Nicolin Chen wrote:
> > > On Tue, Dec 05, 2023 at 10:37:42AM -0400, Jason Gunthorpe wrote:
> > > > On Mon, Dec 04, 2023 at 08:28:23PM -0800, Nicolin Chen wrote:
> > > > 
> > > > > > +static int arm_smmu_attach_dev_ste(struct device *dev,
> > > > > > +				   struct arm_smmu_ste *ste)
> > > > > > +{
> > > > > > +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > > > > > +
> > > > > > +	if (arm_smmu_master_sva_enabled(master))
> > > > > > +		return -EBUSY;
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * Do not allow any ASID to be changed while are working on the STE,
> > > > > > +	 * otherwise we could miss invalidations.
> > > > > > +	 */
> > > > > > +	mutex_lock(&arm_smmu_asid_lock);
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * The SMMU does not support enabling ATS with bypass/abort. When the
> > > > > > +	 * STE is in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests
> > > > > > +	 * and Translated transactions are denied as though ATS is disabled for
> > > > > > +	 * the stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
> > > > > > +	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
> > > > > > +	 */
> > > > > > +	arm_smmu_detach_dev(master);
> > > > > > +
> > > > > > +	arm_smmu_install_ste_for_dev(master, ste);
> > > > > > +	mutex_unlock(&arm_smmu_asid_lock);
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * This has to be done after removing the master from the
> > > > > > +	 * arm_smmu_domain->devices to avoid races updating the same context
> > > > > > +	 * descriptor from arm_smmu_share_asid().
> > > > > > +	 */
> > > > > > +	if (master->cd_table.cdtab)
> > > > > > +		arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);
> > > > >  
> > > > > This arm_smmu_write_ctx_desc was previously within the asid lock
> > > > > protection, yet now it's moved out of that?
> > > > 
> > > > Yes, arm_smmu_write_ctx_desc() updates a CD table entry and that does
> > > > not need ASID lock protection. The ASID lock exists because of the BTM
> > > > code rewriting STEs asyncronously.
> > > 
> > > I see. Thanks for elaborating. For this patch
> > 
> > Actually wait, that explanation is not right..
> > 
> > The BTM code is changing the ASID which is done with a CD update
> > 
> > The ordering is OK here because the BTM code iterates over the
> > &smmu_domain->devices list.
> > 
> > The arm_smmu_detach_dev() has removed the master from the devices list
> > under a lock so the BTM code won't see this.
> > 
> > Thus there is no race between the arm_smmu_share_asid() flow and this
> > code, indeed we've already removed the cdtable from the STE at this
> > point.
> 
> I see. Maybe worth mentioning this in the comments above or commit
> message?

It does have a comment:

 +	/*
 +	 * This has to be done after removing the master from the
 +	 * arm_smmu_domain->devices to avoid races updating the same context
 +	 * descriptor from arm_smmu_share_asid().
 +	 */
 
> Also, the arm_smmu_attach_dev_ste seems to be used by IDENTITY and
> BLOCK domains only. This turns its nature to be a cleanup function
> against a translate domain, while the naming sounds very generic.
> I cannot think of any better name than this one, yet maybe we can
> highlight this with a line of comments above the function?

I would not call it a cleanup, it installs a domain-less thing via a
raw STE

Jason


From wahrenst at gmx.net  Tue Dec  5 11:03:41 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 5 Dec 2023 20:03:41 +0100
Subject: [PATCH] ARM: dts: imx28-xea: Pass the 'model' property
In-Reply-To: <20231205132735.2016022-1-festevam@gmail.com>
References: <20231205132735.2016022-1-festevam@gmail.com>
Message-ID: <4666f874-7c10-4b54-876b-a9f41ee34392@gmx.net>

Hi Fabio,

Am 05.12.23 um 14:27 schrieb Fabio Estevam:
> From: Fabio Estevam <festevam at denx.de>
>
> Per root-node.yaml, 'model' is a required property.
>
> Pass it to fix the following dt-schema warning:
>
> imx28-xea.dtb: /: 'model' is a required property
> 	from schema $id: http://devicetree.org/schemas/root-node.yaml#
>
> Signed-off-by: Fabio Estevam <festevam at denx.de>
i would consider this as a fix because every board file should have a
model, which is helpful for debugging.

Fixes: 445ae16ac1c5 ("ARM: dts: imx28: Add DTS description of imx28
based XEA board")
> ---
>   arch/arm/boot/dts/nxp/mxs/imx28-xea.dts | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> index a400c108f66a..cc54a0390f8c 100644
> --- a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> +++ b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> @@ -8,6 +8,7 @@
>   #include "imx28-lwe.dtsi"
>
>   / {
> +	model = "Liebherr Xea board";
s/Xea/XEA

Thanks
>   	compatible = "lwn,imx28-xea", "fsl,imx28";
>   };
>



From f.fainelli at gmail.com  Tue Dec  5 11:05:13 2023
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 5 Dec 2023 11:05:13 -0800
Subject: [PATCH 2/4] memory: brcmstb_dpfe: introduce version-specific
 compatible strings
In-Reply-To: <20231205184741.3092376-3-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-3-mmayer@broadcom.com>
Message-ID: <fee61230-58f9-45d5-b435-e3f76f4993e4@gmail.com>

On 12/5/23 10:47, Markus Mayer wrote:
> Introduce compatible strings brcm,dpfe-cpu-v1 through brcm,dpfe-cpu-v3
> to the Broadcom DPFE driver.
> 
> Signed-off-by: Markus Mayer <mmayer at broadcom.com>

Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian



From f.fainelli at gmail.com  Tue Dec  5 11:05:38 2023
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 5 Dec 2023 11:05:38 -0800
Subject: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
In-Reply-To: <20231205184741.3092376-4-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-4-mmayer@broadcom.com>
Message-ID: <a755a0c6-e963-4172-a4c5-df046e28b5d0@gmail.com>

On 12/5/23 10:47, Markus Mayer wrote:
> Add support for version 4 of the DPFE API. This new version is largely
> identical to version 3. The main difference is that all commands now
> take the MHS version number as the first argument. Any other arguments
> have been pushed down by one (i.e. what used to be arg0 in v3 is arg1 in
> v4).
> 
> Signed-off-by: Markus Mayer <mmayer at broadcom.com>

Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian



From f.fainelli at gmail.com  Tue Dec  5 11:06:07 2023
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 5 Dec 2023 11:06:07 -0800
Subject: [PATCH 4/4] memory: brcmstb_dpfe: introduce best-effort API
 detection
In-Reply-To: <20231205184741.3092376-5-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-5-mmayer@broadcom.com>
Message-ID: <ea67da10-0e8d-47d1-992c-484977d152b6@gmail.com>

On 12/5/23 10:47, Markus Mayer wrote:
> Add a best-effort probe function that tries all known DPFE versions to
> see if one might actually work. This helps in cases where device tree
> doesn't provide the proper version information for whatever reason. In
> that case, the driver may still be able to register if one of the known
> API versions ends up working.
> 
> Caveat: we have to skip "v1" during our best effort attempts. This is
> due to the fact that attempting a firmware download as required by v1
> will result in a memory access violation on anything but v1 hardware.
> This would crash the kernel. Since we don't know the HW version, we need
> to play it safe and skip v1.
> 
> Signed-off-by: Markus Mayer <mmayer at broadcom.com>

Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian



From peter.griffin at linaro.org  Tue Dec  5 11:10:37 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Tue, 5 Dec 2023 19:10:37 +0000
Subject: [PATCH v5 13/20] pinctrl: samsung: Add filter selection support
 for alive banks
In-Reply-To: <CADrjBPrq_CTzZsP+5cqpNkkyVYHu9Yey0AF+m4VxcSEz+Z+wrQ@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-14-peter.griffin@linaro.org> <CAPLW+4nJCabQhyGrTKZhKG40Z9ysRq7Zms413JrhZKzeYzad5w@mail.gmail.com>
 <CADrjBPrq_CTzZsP+5cqpNkkyVYHu9Yey0AF+m4VxcSEz+Z+wrQ@mail.gmail.com>
Message-ID: <CADrjBPoJ4E4cLS9sVDnu4PmgLuGGybPwg+u3fQefjuUz-60Y5w@mail.gmail.com>

Hi Sam,

On Tue, 5 Dec 2023 at 11:34, Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Hi Sam,
>
> Thanks for your review.
>
> On Sat, 2 Dec 2023 at 00:22, Sam Protsenko <semen.protsenko at linaro.org> wrote:
> >
> > On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> > >
> > > Newer Exynos SoCs have a filter selection register on alive bank pins.
> > > This allows the selection of a digital or delay filter for each pin. If
> > > the filter selection register is not available then the default filter
> > > (digital) is applied.
> > >
> > > On suspend we apply the analog filter to all pins in the bank (as the
> > > digital filter relies on a clock). On resume the digital filter is
> > > reapplied to all pins in the bank. The digital filter is working via
> > > clock and has an adjustable filter delay register bitfield, whereas
> > > the analog filter uses a fixed delay.
> > >
> > > The filter determines to what extent signal fluctuations received through
> > > the pad are considered glitches.
> > >
> > > The code path can be exercised using
> > > echo mem > /sys/power/state
> > > And then wake the device using a eint gpio
> >
> > Period.
>
> Will fix
>
> >
> > >
> > > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > > ---
> > >  drivers/pinctrl/samsung/pinctrl-exynos.c  | 89 ++++++++++++++++++++++-
> > >  drivers/pinctrl/samsung/pinctrl-exynos.h  |  7 ++
> > >  drivers/pinctrl/samsung/pinctrl-samsung.c |  2 +
> > >  drivers/pinctrl/samsung/pinctrl-samsung.h | 22 ++++++
> > >  4 files changed, 119 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > > index 6b58ec84e34b..56fc11a1fe2f 100644
> > > --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> > > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > > @@ -269,6 +269,71 @@ struct exynos_eint_gpio_save {
> > >         u32 eint_mask;
> > >  };
> > >
> > > +/*
> > > + * Set the desired filter (digital or analog delay) to every pin in
> > > + * the bank. Note the filter selection bitfield is only found on alive
> > > + * banks. The filter determines to what extent signal fluctuations
> > > + * received through the pad are considered glitches.
> > > + */
> > > +static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
> > > +                                  struct samsung_pin_bank *bank, int filter)
> > > +{
> > > +       unsigned int flt_reg, flt_con = 0;
> > > +       unsigned int val, shift;
> > > +       int i;
> > > +       int loop_cnt;
> > > +
> > > +       /*
> > > +        * The FLTCON register has the following layout
> > > +        *
> > > +        * BitfieldName[PinNum][Bit:Bit]
> > > +        * FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
> > > +        * FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
> > > +        * FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
> > > +        * FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
> > > +        *
> > > +        * FLT_EN       0x0 = Disable, 0x1=Enable
> > > +        * FLT_SEL      0x0 = Delay filter, 0x1 Digital filter
> > > +        * FLT_WIDTH    Filtering width. Valid when FLT_SEL is 0x1
> > > +        */
> > > +
> > > +       flt_con |= EXYNOS9_FLTCON_EN;
> > > +
> > > +       if (filter)
> > > +               flt_con |= EXYNOS9_FLTCON_DIGITAL;
> > > +
> > > +       flt_reg = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
> > > +
> > > +       /*
> > > +        * If nr_pins > 4, we should set FLTCON0 register fully.
> > > +        * (pin0 ~ 3). So loop 4 times in case of FLTCON0.
> > > +        */
> > > +       if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN)
> > > +               loop_cnt = EXYNOS9_FLTCON_NR_PIN;
> > > +       else
> > > +               loop_cnt = bank->nr_pins;
> > > +
> > > +       val = readl(d->virt_base + flt_reg);
> > > +       for (i = 0; i < loop_cnt; i++) {
> > > +               shift = i * EXYNOS9_FLTCON_LEN;
> > > +               val &= ~(EXYNOS9_FLTCON_MASK << shift);
> > > +               val |= (flt_con << shift);
> > > +       }
> > > +       writel(val, d->virt_base + flt_reg);
> > > +
> > > +       /* Loop for FLTCON1 pin 4 ~ 7 */
> > > +       if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN) {
> > > +               loop_cnt = (bank->nr_pins - EXYNOS9_FLTCON_NR_PIN);
> > > +               val = readl(d->virt_base + flt_reg + 0x4);
> > > +               for (i = 0; i < loop_cnt; i++) {
> > > +                       shift = i * EXYNOS9_FLTCON_LEN;
> > > +                       val &= ~(EXYNOS9_FLTCON_MASK << shift);
> > > +                       val |= (flt_con << shift);
> > > +               }
> > > +               writel(val, d->virt_base + flt_reg + 0x4);
> > > +       }
> > > +}
> > > +
> >
> > This whole function needs a refactoring. Do you think below code looks better?
>
> Yes it does!
> >
> > 8<----------------------------------------------------------------->8
> > static void exynos_eint_update_flt_reg(void __iomem *reg, int cnt, int con)
> > {
> >     unsigned int val, shift;
> >     int i;
> >
> >     val = readl(reg);
> >     for (i = 0; i < cnt; i++) {
> >         shift = i * EXYNOS9_FLTCON_LEN;
> >         val &= ~(EXYNOS9_FLTCON_MASK << shift);
> >         val |= con << shift;
> >     }
> >     writel(val, reg);
> > }
> >
> > /*
> >  * Set the desired filter (digital or analog delay) to every pin in the bank.
> >  * Note the filter selection bitfield is only found on alive banks. The filter
> >  * determines to what extent signal fluctuations received through the pad are
> >  * considered glitches.
> >  *
> >  * The FLTCON register has the following layout:
> >  *
> >  *     BitfieldName[PinNum][Bit:Bit]
> >  *     FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
> >  *     FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
> >  *     FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
> >  *     FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
> >  *
> >  * FLT_EN    0x0 = Disable, 0x1 = Enable
> >  * FLT_SEL    0x0 = Delay filter, 0x1 = Digital filter
> >  * FLT_WIDTH    Filtering width. Valid when FLT_SEL is 0x1
> >  */
> > static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
> >                    struct samsung_pin_bank *bank, int filter)
> > {
> >     unsigned int off = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
> >     unsigned int con = EXYNOS9_FLTCON_EN | filter;
> >     void __iomem *reg = d->virt_base + off;
> >     u8 n = bank->nr_pins;
> >
> >     if (bank->fltcon_type == FLT_DEFAULT)
> >         return;
> >
> >     /*
> >      * If nr_pins > 4, we should set FLTCON0 register fully (pin0~3).
> >      * So loop 4 times in case of FLTCON0. Loop for FLTCON1 pin4~7.
> >      */
> >     if (n <= 4) {
> >         exynos_eint_update_flt_reg(reg, n, con);
> >     } else {
> >         exynos_eint_update_flt_reg(reg, 4, con);
> >         exynos_eint_update_flt_reg(reg + 0x4, n - 4, con);
> >     }
> > }
> > 8<----------------------------------------------------------------->8
> >
> > (the code is only to illustrate the idea, I never tested it).
>
> I can refactor it along those lines.
>
> >
> > >  /*
> > >   * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
> > >   * @d: driver data of samsung pinctrl driver.
> > > @@ -321,6 +386,10 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
> > >                         goto err_domains;
> > >                 }
> > >
> > > +               /* Set Delay Analog Filter */
> >
> > The code below looks quite self-explanatory to. Maybe remove all
> > comments like this? If you don't think exynos_eint_flt_config() is
> > clear, maybe rename it to exynos_eint_set_filter().
>
> Ok, I will update the function name to exynos_eint_set_filter() and
> remove the comments.
>
> >
> > > +               if (bank->fltcon_type != FLT_DEFAULT)
> > > +                       exynos_eint_flt_config(d, bank,
> > > +                                              EXYNOS9_FLTCON_DELAY);
> >
> > It fits the previous line just fine, no need to break the line.
> >
> > Also, if you use the refactored version of exynos_eint_flt_config() I
> > mentioned above, you can drop all 'if' conditions like this.
>
> Will fix
>
> >
> > >         }
> > >
> > >         return 0;
> > > @@ -555,6 +624,11 @@ __init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
> > >                 if (bank->eint_type != EINT_TYPE_WKUP)
> > >                         continue;
> > >
> > > +               /* Set Digital Filter */
> > > +               if (bank->fltcon_type != FLT_DEFAULT)
> > > +                       exynos_eint_flt_config(d, bank,
> > > +                                              EXYNOS9_FLTCON_DIGITAL);
> >
> > Ditto: no need to break the line, remove the comment. If you use the
> > refactored function, you can drop 'if'.
>
> will fix
>
> >
> > > +
> > >                 bank->irq_chip = devm_kmemdup(dev, irq_chip, sizeof(*irq_chip),
> > >                                               GFP_KERNEL);
> > >                 if (!bank->irq_chip) {
> > > @@ -658,6 +732,7 @@ static void exynos_pinctrl_suspend_bank(
> > >  void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
> > >  {
> > >         struct samsung_pin_bank *bank = drvdata->pin_banks;
> > > +       struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > >         struct exynos_irq_chip *irq_chip = NULL;
> > >         int i;
> > >
> > > @@ -665,6 +740,10 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
> > >                 if (bank->eint_type == EINT_TYPE_GPIO)
> > >                         exynos_pinctrl_suspend_bank(drvdata, bank);
> > >                 else if (bank->eint_type == EINT_TYPE_WKUP) {
> > > +                       /* Setting Delay (Analog) Filter */
> > > +                       if (bank->fltcon_type != FLT_DEFAULT)
> > > +                               exynos_eint_flt_config(d, bank,
> > > +                                                      EXYNOS9_FLTCON_DELAY);
> >
> > Ditto: no need to break the line, remove the comment. If you use the
> > refactored function, you can drop 'if'.
>
> Will fix
> >
> > >                         if (!irq_chip) {
> > >                                 irq_chip = bank->irq_chip;
> > >                                 irq_chip->set_eint_wakeup_mask(drvdata,
> > > @@ -707,11 +786,19 @@ static void exynos_pinctrl_resume_bank(
> > >  void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
> > >  {
> > >         struct samsung_pin_bank *bank = drvdata->pin_banks;
> > > +       struct samsung_pinctrl_drv_data *d = bank->drvdata;
> > >         int i;
> > >
> > >         for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
> > > -               if (bank->eint_type == EINT_TYPE_GPIO)
> > > +               if (bank->eint_type == EINT_TYPE_GPIO) {
> > >                         exynos_pinctrl_resume_bank(drvdata, bank);
> > > +               } else if (bank->eint_type == EINT_TYPE_WKUP ||
> > > +                          bank->eint_type == EINT_TYPE_WKUP_MUX) {
> > > +                       /* Set Digital Filter */
> > > +                       if (bank->fltcon_type != FLT_DEFAULT)
> > > +                               exynos_eint_flt_config(d, bank,
> > > +                                                      EXYNOS9_FLTCON_DIGITAL);
> >
> > Ditto: remove the comment, and if you use the refactored function, you
> > can drop 'if'; also there will be no need to break the line.
>
> Will fix
> >
> > > +               }
> > >  }
> > >
> > >  static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
> > > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
> > > index 3ac52c2cf998..e2799ff1b5e9 100644
> > > --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
> > > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
> > > @@ -50,6 +50,13 @@
> > >
> > >  #define EXYNOS_EINT_MAX_PER_BANK       8
> > >  #define EXYNOS_EINT_NR_WKUP_EINT
> >
> > Maybe add an empty line here?
>
> Will fix
> >
> > > +/* EINT filter configuration */
> > > +#define EXYNOS9_FLTCON_EN              BIT(7)
> > > +#define EXYNOS9_FLTCON_DIGITAL         BIT(6)
> > > +#define EXYNOS9_FLTCON_DELAY           (0 << 6)
> > > +#define EXYNOS9_FLTCON_MASK            0xff
> > > +#define EXYNOS9_FLTCON_LEN             8
> > > +#define EXYNOS9_FLTCON_NR_PIN          4
> >
> > I'd say drop this one and just hard-code it where needed?
>
> Ok, will drop.
>
> >
> > >
> > >  #define EXYNOS_PIN_BANK_EINTN(pins, reg, id)           \
> > >         {                                               \
> > > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > > index 79babbb39ced..50c360b4753a 100644
> > > --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> > > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > > @@ -1105,6 +1105,8 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
> > >                 bank->eint_func = bdata->eint_func;
> > >                 bank->eint_type = bdata->eint_type;
> > >                 bank->eint_mask = bdata->eint_mask;
> > > +               bank->fltcon_type = bdata->fltcon_type;
> > > +               bank->fltcon_offset = bdata->fltcon_offset;
> > >                 bank->eint_offset = bdata->eint_offset;
> > >                 bank->name = bdata->name;
> > >
> > > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> > > index 9b3db50adef3..5fab3885a7d7 100644
> > > --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> > > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> > > @@ -82,6 +82,20 @@ enum eint_type {
> > >         EINT_TYPE_WKUP_MUX,
> > >  };
> > >
> > > +/**
> > > + * enum fltcon_type - filter selection
> > > + * @FLT_DEFAULT: filter not selectable, default digital filter
> > > + * @FLT_SELECT: filter selectable (digital or delay)
> > > + *
> > > + * Some banks on newer Exynos based SoCs have a selectable filter on alive
> > > + * banks of 'analog/delay' or 'digital'. If the filter selection register is
> > > + * not available then the default filter is used (digital).
> > > + */
> > > +enum fltcon_type {
> > > +       FLT_DEFAULT,
> > > +       FLT_SELECTABLE,
> > > +};
> >
> > Is there any benefit of having this enum over replacing it with just a
> > bool field (e.g. 'bool flt_selectable')?
>
> I thought it made it clearer at the callee sites which filter was
> being set, but I can update to a bool if that's what you prefer.

Actually that was a previous version. We actually pass
EXYNOS9_FLTCON_DELAY and EXYNOS9_FLTCON_DIGITAL now so yes enum is no
longer required.

Peter
>
> regards,
>
> Peter.
>
> >
> > > +
> > >  /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
> > >  #define PIN_NAME_LENGTH        10
> > >
> > > @@ -122,6 +136,8 @@ struct samsung_pin_bank_type {
> > >   * @eint_type: type of the external interrupt supported by the bank.
> > >   * @eint_mask: bit mask of pins which support EINT function.
> > >   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> > > + * @fltcon_type: whether the filter (delay/digital) is selectable
> > > + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
> > >   * @name: name to be prefixed for each pin in this pin bank.
> > >   */
> > >  struct samsung_pin_bank_data {
> > > @@ -133,6 +149,8 @@ struct samsung_pin_bank_data {
> > >         enum eint_type  eint_type;
> > >         u32             eint_mask;
> > >         u32             eint_offset;
> > > +       enum fltcon_type fltcon_type;
> > > +       u32             fltcon_offset;
> > >         const char      *name;
> > >  };
> > >
> > > @@ -147,6 +165,8 @@ struct samsung_pin_bank_data {
> > >   * @eint_type: type of the external interrupt supported by the bank.
> > >   * @eint_mask: bit mask of pins which support EINT function.
> > >   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> > > + * @fltcon_type: whether the filter (delay/digital) is selectable
> > > + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
> > >   * @name: name to be prefixed for each pin in this pin bank.
> > >   * @id: id of the bank, propagated to the pin range.
> > >   * @pin_base: starting pin number of the bank.
> > > @@ -170,6 +190,8 @@ struct samsung_pin_bank {
> > >         enum eint_type  eint_type;
> > >         u32             eint_mask;
> > >         u32             eint_offset;
> > > +       enum fltcon_type fltcon_type;
> > > +       u32             fltcon_offset;
> > >         const char      *name;
> > >         u32             id;
> > >
> > > --
> > > 2.43.0.rc2.451.g8631bc7472-goog
> > >


From namhyung at kernel.org  Tue Dec  5 11:10:50 2023
From: namhyung at kernel.org (Namhyung Kim)
Date: Tue, 5 Dec 2023 11:10:50 -0800
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <ZW9whqUEILWMdcmi@kernel.org>
References: <20231204182330.654255-1-irogers@google.com> <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
 <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com>
 <ZW9G8Clxwl6bd0H6@kernel.org> <CAM9d7ciOp_O5N1TDX0HyKavykirByAYrqzcmM-_6ZWjMv-47WQ@mail.gmail.com>
 <ZW9whqUEILWMdcmi@kernel.org>
Message-ID: <CAM9d7ciqm2NLt5kxjVdOP2y-KV30_CRsSjHpcQgntvNGWukx9g@mail.gmail.com>

On Tue, Dec 5, 2023 at 10:48?AM Arnaldo Carvalho de Melo
<acme at kernel.org> wrote:
>
> Em Tue, Dec 05, 2023 at 09:24:42AM -0800, Namhyung Kim escreveu:
> > Hi Arnaldo,
> >
> > On Tue, Dec 5, 2023 at 7:51?AM Arnaldo Carvalho de Melo <acme at kernel.org> wrote:
> > >
> > > Em Mon, Dec 04, 2023 at 07:33:18PM -0800, Namhyung Kim escreveu:
> > > > On Mon, Dec 4, 2023 at 2:45?PM Ilkka Koskinen <ilkka at os.amperecomputing.com> wrote:
> > > > > On Mon, 4 Dec 2023, Ian Rogers wrote:
> > > > > > A metric is default by having "Default" within its groups. The default
> > > > > > metricgroup name needn't be set and this can result in segv in
> > > > > > default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
> > > > > > that assume it has a value when there is a Default metric group. To
> > > > > > avoid the segv initialize the value to "".
> > >
> > > > > > Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
> > > > > > Signed-off-by: Ian Rogers <irogers at google.com>
> > >
> > > > > Thanks! I was going to look for the bug but got pulled to other
> > > > > tasks. The patch looks good to me and I tested it successfully on
> > > > > AmpereOne.
> > >
> > > > >    Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
> > >
> > > > Looks like it needs to go through perf-tools for v6.7.
> > > > Ian, do you think this one is enough?
> > >
> > > So I had this on my local perf-tools-next, removed now, I also have some
> > > other fixes by Ian on the tmp.perf-tools-next, please let me know what
> > > you guys decide to have in perf-tools for v6.7 so that I can remove it
> > > from there.
> >
> > I think we need this one and the Ampere default-metric-group fix.
> >
> > https://lore.kernel.org/r/20231201021550.1109196-2-ilkka at os.amperecomputing.com/
> >
> > Also perf list JSON fix can go to v6.7.
> >
> > https://lore.kernel.org/r/20231129213428.2227448-2-irogers at google.com/
>
> Ok, removed both, please augment the later description to:
>
> "perf list: Fix JSON segfault by setting the used skip_fuplicate_pmus callback"
>
> The original description was vague, improving it a bit like that helps
> when just looking at the output of "git log --oneline".

Done and pushed to tmp.perf-tools!

Thanks,
Namhyung


From jgg at nvidia.com  Tue Dec  5 11:14:45 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:45 -0400
Subject: [PATCH v3 13/19] iommu/arm-smmu-v3: Pass smmu_domain to arm_enable/disable_ats()
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <13-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

The caller already has the domain, just pass it in. A following patch will
remove master->domain.

Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 212d0ad7e5f911..e1de2799310961 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2394,12 +2394,12 @@ static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
 	return dev_is_pci(dev) && pci_ats_supported(to_pci_dev(dev));
 }
 
-static void arm_smmu_enable_ats(struct arm_smmu_master *master)
+static void arm_smmu_enable_ats(struct arm_smmu_master *master,
+				struct arm_smmu_domain *smmu_domain)
 {
 	size_t stu;
 	struct pci_dev *pdev;
 	struct arm_smmu_device *smmu = master->smmu;
-	struct arm_smmu_domain *smmu_domain = master->domain;
 
 	/* Don't enable ATS at the endpoint if it's not enabled in the STE */
 	if (!master->ats_enabled)
@@ -2415,10 +2415,9 @@ static void arm_smmu_enable_ats(struct arm_smmu_master *master)
 		dev_err(master->dev, "Failed to enable ATS (STU %zu)\n", stu);
 }
 
-static void arm_smmu_disable_ats(struct arm_smmu_master *master)
+static void arm_smmu_disable_ats(struct arm_smmu_master *master,
+				 struct arm_smmu_domain *smmu_domain)
 {
-	struct arm_smmu_domain *smmu_domain = master->domain;
-
 	if (!master->ats_enabled)
 		return;
 
@@ -2487,7 +2486,7 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 	if (!smmu_domain)
 		return;
 
-	arm_smmu_disable_ats(master);
+	arm_smmu_disable_ats(master, smmu_domain);
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
 	list_del(&master->domain_head);
@@ -2609,7 +2608,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		break;
 	}
 
-	arm_smmu_enable_ats(master);
+	arm_smmu_enable_ats(master, smmu_domain);
 	goto out_unlock;
 
 out_list_del:
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:37 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:37 -0400
Subject: [PATCH v3 05/19] iommu/arm-smmu-v3: Consolidate the STE generation for abort/bypass
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <5-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

This allows writing the flow of arm_smmu_write_strtab_ent() around abort
and bypass domains more naturally.

Note that the core code no longer supplies NULL domains, though there is
still a flow in the driver that end up in arm_smmu_write_strtab_ent() with
NULL. A later patch will remove it.

Remove the duplicate calculation of the STE in arm_smmu_init_bypass_stes()
and remove the force parameter. arm_smmu_rmr_install_bypass_ste() can now
simply invoke arm_smmu_make_bypass_ste() directly.

Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 89 +++++++++++----------
 1 file changed, 47 insertions(+), 42 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 0934f882b94e94..0a4bf1cbe42293 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1443,6 +1443,24 @@ static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
 	}
 }
 
+static void arm_smmu_make_abort_ste(struct arm_smmu_ste *target)
+{
+	memset(target, 0, sizeof(*target));
+	target->data[0] = cpu_to_le64(
+		STRTAB_STE_0_V |
+		FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_ABORT));
+}
+
+static void arm_smmu_make_bypass_ste(struct arm_smmu_ste *target)
+{
+	memset(target, 0, sizeof(*target));
+	target->data[0] = cpu_to_le64(
+		STRTAB_STE_0_V |
+		FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_BYPASS));
+	target->data[1] = cpu_to_le64(
+		FIELD_PREP(STRTAB_STE_1_SHCFG, STRTAB_STE_1_SHCFG_INCOMING));
+}
+
 static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 				      struct arm_smmu_ste *dst)
 {
@@ -1453,37 +1471,31 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 	struct arm_smmu_domain *smmu_domain = master->domain;
 	struct arm_smmu_ste target = {};
 
-	if (smmu_domain) {
-		switch (smmu_domain->stage) {
-		case ARM_SMMU_DOMAIN_S1:
-			cd_table = &master->cd_table;
-			break;
-		case ARM_SMMU_DOMAIN_S2:
-			s2_cfg = &smmu_domain->s2_cfg;
-			break;
-		default:
-			break;
-		}
+	if (!smmu_domain) {
+		if (disable_bypass)
+			arm_smmu_make_abort_ste(&target);
+		else
+			arm_smmu_make_bypass_ste(&target);
+		arm_smmu_write_ste(smmu, sid, dst, &target);
+		return;
+	}
+
+	switch (smmu_domain->stage) {
+	case ARM_SMMU_DOMAIN_S1:
+		cd_table = &master->cd_table;
+		break;
+	case ARM_SMMU_DOMAIN_S2:
+		s2_cfg = &smmu_domain->s2_cfg;
+		break;
+	case ARM_SMMU_DOMAIN_BYPASS:
+		arm_smmu_make_bypass_ste(&target);
+		arm_smmu_write_ste(smmu, sid, dst, &target);
+		return;
 	}
 
 	/* Nuke the existing STE_0 value, as we're going to rewrite it */
 	val = STRTAB_STE_0_V;
 
-	/* Bypass/fault */
-	if (!smmu_domain || !(cd_table || s2_cfg)) {
-		if (!smmu_domain && disable_bypass)
-			val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_ABORT);
-		else
-			val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_BYPASS);
-
-		target.data[0] = cpu_to_le64(val);
-		target.data[1] = cpu_to_le64(FIELD_PREP(STRTAB_STE_1_SHCFG,
-						STRTAB_STE_1_SHCFG_INCOMING));
-		target.data[2] = 0; /* Nuke the VMID */
-		arm_smmu_write_ste(smmu, sid, dst, &target);
-		return;
-	}
-
 	if (cd_table) {
 		u64 strw = smmu->features & ARM_SMMU_FEAT_E2H ?
 			STRTAB_STE_1_STRW_EL2 : STRTAB_STE_1_STRW_NSEL1;
@@ -1529,21 +1541,15 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 }
 
 static void arm_smmu_init_bypass_stes(struct arm_smmu_ste *strtab,
-				      unsigned int nent, bool force)
+				      unsigned int nent)
 {
 	unsigned int i;
-	u64 val = STRTAB_STE_0_V;
-
-	if (disable_bypass && !force)
-		val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_ABORT);
-	else
-		val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_BYPASS);
 
 	for (i = 0; i < nent; ++i) {
-		strtab->data[0] = cpu_to_le64(val);
-		strtab->data[1] = cpu_to_le64(FIELD_PREP(
-			STRTAB_STE_1_SHCFG, STRTAB_STE_1_SHCFG_INCOMING));
-		strtab->data[2] = 0;
+		if (disable_bypass)
+			arm_smmu_make_abort_ste(strtab);
+		else
+			arm_smmu_make_bypass_ste(strtab);
 		strtab++;
 	}
 }
@@ -1571,7 +1577,7 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
 		return -ENOMEM;
 	}
 
-	arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT, false);
+	arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT);
 	arm_smmu_write_strtab_l1_desc(strtab, desc);
 	return 0;
 }
@@ -3194,7 +3200,7 @@ static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
 	reg |= FIELD_PREP(STRTAB_BASE_CFG_LOG2SIZE, smmu->sid_bits);
 	cfg->strtab_base_cfg = reg;
 
-	arm_smmu_init_bypass_stes(strtab, cfg->num_l1_ents, false);
+	arm_smmu_init_bypass_stes(strtab, cfg->num_l1_ents);
 	return 0;
 }
 
@@ -3905,7 +3911,6 @@ static void arm_smmu_rmr_install_bypass_ste(struct arm_smmu_device *smmu)
 	iort_get_rmr_sids(dev_fwnode(smmu->dev), &rmr_list);
 
 	list_for_each_entry(e, &rmr_list, list) {
-		struct arm_smmu_ste *step;
 		struct iommu_iort_rmr_data *rmr;
 		int ret, i;
 
@@ -3918,8 +3923,8 @@ static void arm_smmu_rmr_install_bypass_ste(struct arm_smmu_device *smmu)
 				continue;
 			}
 
-			step = arm_smmu_get_step_for_sid(smmu, rmr->sids[i]);
-			arm_smmu_init_bypass_stes(step, 1, true);
+			arm_smmu_make_bypass_ste(
+				arm_smmu_get_step_for_sid(smmu, rmr->sids[i]));
 		}
 	}
 
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:32 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:32 -0400
Subject: [PATCH v3 00/19] Update SMMUv3 to the modern iommu API (part 1/3)
Message-ID: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

The SMMUv3 driver was originally written in 2015 when the iommu driver
facing API looked quite different. The API has evolved, especially lately,
and the driver has fallen behind.

This work aims to bring make the SMMUv3 driver the best IOMMU driver with
the most comprehensive implementation of the API. After all parts it
addresses:

 - Global static BLOCKED and IDENTITY domains with 'never fail' attach
   semantics. BLOCKED is desired for efficient VFIO.

 - Support map before attach for PAGING iommu_domains.

 - attach_dev failure does not change the HW configuration.

 - Fully hitless transitions between IDENTITY -> DMA -> IDENTITY.
   The API has IOMMU_RESV_DIRECT which is expected to be
   continuously translating.

 - Safe transitions between PAGING -> BLOCKED, do not ever temporarily
   do IDENTITY. This is required for iommufd security.

 - Full PASID API support including:
    - S1/SVA domains attached to PASIDs
    - IDENTITY/BLOCKED/S1 attached to RID
    - Change of the RID domain while PASIDs are attached

 - Streamlined SVA support using the core infrastructure

 - Hitless, whenever possible, change between two domains

 - iommufd IOMMU_GET_HW_INFO, IOMMU_HWPT_ALLOC_NEST_PARENT, and
   IOMMU_DOMAIN_NESTED support

Over all these things are going to become more accessible to iommufd, and
exposed to VMs, so it is important for the driver to have a robust
implementation of the API.

The work is split into three parts, with this part largely focusing on the
STE and building up to the BLOCKED & IDENTITY global static domains.

The second part largely focuses on the CD and builds up to having a common
PASID infrastructure that SVA and S1 domains equally use.

The third part has some random cleanups and the iommufd related parts.

Overall this takes the approach of turning the STE/CD programming upside
down where the CD/STE value is computed right at a driver callback
function and then pushed down into programming logic. The programming
logic hides the details of the required CD/STE tear-less update. This
makes the CD/STE functions independent of the arm_smmu_domain which makes
it fairly straightforward to untangle all the different call chains, and
add news ones.

Further, this frees the arm_smmu_domain related logic from keeping track
of what state the STE/CD is currently in so it can carefully sequence the
correct update. There are many new update pairs that are subtly introduced
as the work progresses.

The locking to support BTM via arm_smmu_asid_lock is a bit subtle right
now and patches throughout this work adjust and tighten this so that it is
clearer and doesn't get broken.

Once the lower STE layers no longer need to touch arm_smmu_domain we can
isolate struct arm_smmu_domain to be only used for PAGING domains, audit
all the to_smmu_domain() calls to be only in PAGING domain ops, and
introduce the normal global static BLOCKED/IDENTITY domains using the new
STE infrastructure. Part 2 will ultimately migrate SVA over to use
arm_smmu_domain as well.

All parts are on github:

 https://github.com/jgunthorpe/linux/commits/smmuv3_newapi

v3:
 - Use some local variables in arm_smmu_get_step_for_sid() for clarity
 - White space and spelling changes
 - Commit message updates
 - Keep master->domain_head initialized to avoid a list_del corruption
v2: https://lore.kernel.org/r/0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg at nvidia.com
 - Rebased on v6.7-rc1
 - Improve the comment for arm_smmu_write_entry_step()
 - Fix the botched memcmp
 - Document the spec justification for the SHCFG exclusion in used
 - Include STRTAB_STE_1_SHCFG for STRTAB_STE_0_CFG_S2_TRANS in used
 - WARN_ON for unknown STEs in used
 - Fix error unwind in arm_smmu_attach_dev()
 - Whitespace, spelling, and checkpatch related items
v1: https://lore.kernel.org/r/0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg at nvidia.com

Jason Gunthorpe (19):
  iommu/arm-smmu-v3: Add a type for the STE
  iommu/arm-smmu-v3: Master cannot be NULL in
    arm_smmu_write_strtab_ent()
  iommu/arm-smmu-v3: Remove ARM_SMMU_DOMAIN_NESTED
  iommu/arm-smmu-v3: Make STE programming independent of the callers
  iommu/arm-smmu-v3: Consolidate the STE generation for abort/bypass
  iommu/arm-smmu-v3: Move arm_smmu_rmr_install_bypass_ste()
  iommu/arm-smmu-v3: Move the STE generation for S1 and S2 domains into
    functions
  iommu/arm-smmu-v3: Build the whole STE in
    arm_smmu_make_s2_domain_ste()
  iommu/arm-smmu-v3: Hold arm_smmu_asid_lock during all of attach_dev
  iommu/arm-smmu-v3: Compute the STE only once for each master
  iommu/arm-smmu-v3: Do not change the STE twice during
    arm_smmu_attach_dev()
  iommu/arm-smmu-v3: Put writing the context descriptor in the right
    order
  iommu/arm-smmu-v3: Pass smmu_domain to arm_enable/disable_ats()
  iommu/arm-smmu-v3: Remove arm_smmu_master->domain
  iommu/arm-smmu-v3: Add a global static IDENTITY domain
  iommu/arm-smmu-v3: Add a global static BLOCKED domain
  iommu/arm-smmu-v3: Use the identity/blocked domain during release
  iommu/arm-smmu-v3: Pass arm_smmu_domain and arm_smmu_device to
    finalize
  iommu/arm-smmu-v3: Convert to domain_alloc_paging()

 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 729 +++++++++++++-------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  12 +-
 2 files changed, 477 insertions(+), 264 deletions(-)


base-commit: ca7fcaff577c92d85f0e05cc7be79759155fe328
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:44 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:44 -0400
Subject: [PATCH v3 12/19] iommu/arm-smmu-v3: Put writing the context descriptor in the right order
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <12-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Get closer to the IOMMU API ideal that changes between domains can be
hitless. The ordering for the CD table entry is not entirely clean from
this perspective.

When switching away from a STE with a CD table programmed in it we should
write the new STE first, then clear any old data in the CD entry.

If we are programming a CD table for the first time to a STE then the CD
entry should be programmed before the STE is loaded.

If we are replacing a CD table entry when the STE already points at the CD
entry then we just need to do the make/break sequence.

Lift this code out of arm_smmu_detach_dev() so it can all be sequenced
properly. The only other caller is arm_smmu_release_device() and it is
going to free the cdtable anyhow, so it doesn't matter what is in it.

Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 29 ++++++++++++++-------
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 7b1f7fa27b3df0..212d0ad7e5f911 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2495,14 +2495,6 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 
 	master->domain = NULL;
 	master->ats_enabled = false;
-	/*
-	 * Clearing the CD entry isn't strictly required to detach the domain
-	 * since the table is uninstalled anyway, but it helps avoid confusion
-	 * in the call to arm_smmu_write_ctx_desc on the next attach (which
-	 * expects the entry to be empty).
-	 */
-	if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 && master->cd_table.cdtab)
-		arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);
 }
 
 static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
@@ -2579,6 +2571,17 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 				master->domain = NULL;
 				goto out_list_del;
 			}
+		} else {
+			/*
+			 * arm_smmu_write_ctx_desc() relies on the entry being
+			 * invalid to work, clear any existing entry.
+			 */
+			ret = arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
+						      NULL);
+			if (ret) {
+				master->domain = NULL;
+				goto out_list_del;
+			}
 		}
 
 		ret = arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, &smmu_domain->cd);
@@ -2588,15 +2591,23 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		}
 
 		arm_smmu_make_cdtable_ste(&target, master, &master->cd_table);
+		arm_smmu_install_ste_for_dev(master, &target);
 		break;
 	case ARM_SMMU_DOMAIN_S2:
 		arm_smmu_make_s2_domain_ste(&target, master, smmu_domain);
+		arm_smmu_install_ste_for_dev(master, &target);
+		if (master->cd_table.cdtab)
+			arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
+						      NULL);
 		break;
 	case ARM_SMMU_DOMAIN_BYPASS:
 		arm_smmu_make_bypass_ste(&target);
+		arm_smmu_install_ste_for_dev(master, &target);
+		if (master->cd_table.cdtab)
+			arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
+						      NULL);
 		break;
 	}
-	arm_smmu_install_ste_for_dev(master, &target);
 
 	arm_smmu_enable_ats(master);
 	goto out_unlock;
-- 
2.43.0



From irogers at google.com  Tue Dec  5 11:14:45 2023
From: irogers at google.com (Ian Rogers)
Date: Tue, 5 Dec 2023 11:14:45 -0800
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <CAM9d7ciqm2NLt5kxjVdOP2y-KV30_CRsSjHpcQgntvNGWukx9g@mail.gmail.com>
References: <20231204182330.654255-1-irogers@google.com> <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
 <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com>
 <ZW9G8Clxwl6bd0H6@kernel.org> <CAM9d7ciOp_O5N1TDX0HyKavykirByAYrqzcmM-_6ZWjMv-47WQ@mail.gmail.com>
 <ZW9whqUEILWMdcmi@kernel.org> <CAM9d7ciqm2NLt5kxjVdOP2y-KV30_CRsSjHpcQgntvNGWukx9g@mail.gmail.com>
Message-ID: <CAP-5=fXpsGNVfz+jyu7A=uhrJVQ2xeQ_Forq7CJ4YSjFp-UWnw@mail.gmail.com>

On Tue, Dec 5, 2023 at 11:11?AM Namhyung Kim <namhyung at kernel.org> wrote:
>
> On Tue, Dec 5, 2023 at 10:48?AM Arnaldo Carvalho de Melo
> <acme at kernel.org> wrote:
> >
> > Em Tue, Dec 05, 2023 at 09:24:42AM -0800, Namhyung Kim escreveu:
> > > Hi Arnaldo,
> > >
> > > On Tue, Dec 5, 2023 at 7:51?AM Arnaldo Carvalho de Melo <acme at kernel.org> wrote:
> > > >
> > > > Em Mon, Dec 04, 2023 at 07:33:18PM -0800, Namhyung Kim escreveu:
> > > > > On Mon, Dec 4, 2023 at 2:45?PM Ilkka Koskinen <ilkka at os.amperecomputing.com> wrote:
> > > > > > On Mon, 4 Dec 2023, Ian Rogers wrote:
> > > > > > > A metric is default by having "Default" within its groups. The default
> > > > > > > metricgroup name needn't be set and this can result in segv in
> > > > > > > default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
> > > > > > > that assume it has a value when there is a Default metric group. To
> > > > > > > avoid the segv initialize the value to "".
> > > >
> > > > > > > Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
> > > > > > > Signed-off-by: Ian Rogers <irogers at google.com>
> > > >
> > > > > > Thanks! I was going to look for the bug but got pulled to other
> > > > > > tasks. The patch looks good to me and I tested it successfully on
> > > > > > AmpereOne.
> > > >
> > > > > >    Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
> > > >
> > > > > Looks like it needs to go through perf-tools for v6.7.
> > > > > Ian, do you think this one is enough?
> > > >
> > > > So I had this on my local perf-tools-next, removed now, I also have some
> > > > other fixes by Ian on the tmp.perf-tools-next, please let me know what
> > > > you guys decide to have in perf-tools for v6.7 so that I can remove it
> > > > from there.
> > >
> > > I think we need this one and the Ampere default-metric-group fix.
> > >
> > > https://lore.kernel.org/r/20231201021550.1109196-2-ilkka at os.amperecomputing.com/
> > >
> > > Also perf list JSON fix can go to v6.7.
> > >
> > > https://lore.kernel.org/r/20231129213428.2227448-2-irogers at google.com/
> >
> > Ok, removed both, please augment the later description to:
> >
> > "perf list: Fix JSON segfault by setting the used skip_fuplicate_pmus callback"
> >
> > The original description was vague, improving it a bit like that helps
> > when just looking at the output of "git log --oneline".
>
> Done and pushed to tmp.perf-tools!

Thanks Namhyung, there was a typo in Arnaldo's commit message
"s/fuplicate/duplicate/" could you fix?

Ian

> Thanks,
> Namhyung


From jgg at nvidia.com  Tue Dec  5 11:14:39 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:39 -0400
Subject: [PATCH v3 07/19] iommu/arm-smmu-v3: Move the STE generation for S1 and S2 domains into functions
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <7-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

This is preparation to move the STE calculation higher up in to the call
chain and remove arm_smmu_write_strtab_ent(). These new functions will be
called directly from attach_dev.

Reviewed-by: Moritz Fischer <mdf at kernel.org>
Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 114 +++++++++++---------
 1 file changed, 62 insertions(+), 52 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 95c78ccaebd439..b3b28c10bd042e 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1463,13 +1463,69 @@ static void arm_smmu_make_bypass_ste(struct arm_smmu_ste *target)
 		FIELD_PREP(STRTAB_STE_1_SHCFG, STRTAB_STE_1_SHCFG_INCOMING));
 }
 
+static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
+				      struct arm_smmu_master *master,
+				      struct arm_smmu_ctx_desc_cfg *cd_table)
+{
+	struct arm_smmu_device *smmu = master->smmu;
+
+	memset(target, 0, sizeof(*target));
+	target->data[0] = cpu_to_le64(
+		STRTAB_STE_0_V |
+		FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S1_TRANS) |
+		FIELD_PREP(STRTAB_STE_0_S1FMT, cd_table->s1fmt) |
+		(cd_table->cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) |
+		FIELD_PREP(STRTAB_STE_0_S1CDMAX, cd_table->s1cdmax));
+
+	target->data[1] = cpu_to_le64(
+		FIELD_PREP(STRTAB_STE_1_S1DSS, STRTAB_STE_1_S1DSS_SSID0) |
+		FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) |
+		FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) |
+		FIELD_PREP(STRTAB_STE_1_S1CSH, ARM_SMMU_SH_ISH) |
+		((smmu->features & ARM_SMMU_FEAT_STALLS &&
+		  !master->stall_enabled) ?
+			 STRTAB_STE_1_S1STALLD :
+			 0) |
+		FIELD_PREP(STRTAB_STE_1_EATS,
+			   master->ats_enabled ? STRTAB_STE_1_EATS_TRANS : 0) |
+		FIELD_PREP(STRTAB_STE_1_STRW,
+			   (smmu->features & ARM_SMMU_FEAT_E2H) ?
+				   STRTAB_STE_1_STRW_EL2 :
+				   STRTAB_STE_1_STRW_NSEL1));
+}
+
+static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
+					struct arm_smmu_master *master,
+					struct arm_smmu_domain *smmu_domain)
+{
+	struct arm_smmu_s2_cfg *s2_cfg = &smmu_domain->s2_cfg;
+
+	memset(target, 0, sizeof(*target));
+	target->data[0] = cpu_to_le64(
+		STRTAB_STE_0_V |
+		FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S2_TRANS));
+
+	target->data[1] |= cpu_to_le64(
+		FIELD_PREP(STRTAB_STE_1_EATS,
+			   master->ats_enabled ? STRTAB_STE_1_EATS_TRANS : 0));
+
+	target->data[2] = cpu_to_le64(
+		FIELD_PREP(STRTAB_STE_2_S2VMID, s2_cfg->vmid) |
+		FIELD_PREP(STRTAB_STE_2_VTCR, s2_cfg->vtcr) |
+		STRTAB_STE_2_S2AA64 |
+#ifdef __BIG_ENDIAN
+		STRTAB_STE_2_S2ENDI |
+#endif
+		STRTAB_STE_2_S2PTW |
+		STRTAB_STE_2_S2R);
+
+	target->data[3] = cpu_to_le64(s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK);
+}
+
 static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 				      struct arm_smmu_ste *dst)
 {
-	u64 val;
 	struct arm_smmu_device *smmu = master->smmu;
-	struct arm_smmu_ctx_desc_cfg *cd_table = NULL;
-	struct arm_smmu_s2_cfg *s2_cfg = NULL;
 	struct arm_smmu_domain *smmu_domain = master->domain;
 	struct arm_smmu_ste target = {};
 
@@ -1484,61 +1540,15 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 
 	switch (smmu_domain->stage) {
 	case ARM_SMMU_DOMAIN_S1:
-		cd_table = &master->cd_table;
+		arm_smmu_make_cdtable_ste(&target, master, &master->cd_table);
 		break;
 	case ARM_SMMU_DOMAIN_S2:
-		s2_cfg = &smmu_domain->s2_cfg;
+		arm_smmu_make_s2_domain_ste(&target, master, smmu_domain);
 		break;
 	case ARM_SMMU_DOMAIN_BYPASS:
 		arm_smmu_make_bypass_ste(&target);
-		arm_smmu_write_ste(smmu, sid, dst, &target);
-		return;
+		break;
 	}
-
-	/* Nuke the existing STE_0 value, as we're going to rewrite it */
-	val = STRTAB_STE_0_V;
-
-	if (cd_table) {
-		u64 strw = smmu->features & ARM_SMMU_FEAT_E2H ?
-			STRTAB_STE_1_STRW_EL2 : STRTAB_STE_1_STRW_NSEL1;
-
-		target.data[1] = cpu_to_le64(
-			 FIELD_PREP(STRTAB_STE_1_S1DSS, STRTAB_STE_1_S1DSS_SSID0) |
-			 FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) |
-			 FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) |
-			 FIELD_PREP(STRTAB_STE_1_S1CSH, ARM_SMMU_SH_ISH) |
-			 FIELD_PREP(STRTAB_STE_1_STRW, strw));
-
-		if (smmu->features & ARM_SMMU_FEAT_STALLS &&
-		    !master->stall_enabled)
-			target.data[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
-
-		val |= (cd_table->cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) |
-			FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S1_TRANS) |
-			FIELD_PREP(STRTAB_STE_0_S1CDMAX, cd_table->s1cdmax) |
-			FIELD_PREP(STRTAB_STE_0_S1FMT, cd_table->s1fmt);
-	}
-
-	if (s2_cfg) {
-		target.data[2] = cpu_to_le64(
-			 FIELD_PREP(STRTAB_STE_2_S2VMID, s2_cfg->vmid) |
-			 FIELD_PREP(STRTAB_STE_2_VTCR, s2_cfg->vtcr) |
-#ifdef __BIG_ENDIAN
-			 STRTAB_STE_2_S2ENDI |
-#endif
-			 STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2AA64 |
-			 STRTAB_STE_2_S2R);
-
-		target.data[3] = cpu_to_le64(s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK);
-
-		val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S2_TRANS);
-	}
-
-	if (master->ats_enabled)
-		target.data[1] |= cpu_to_le64(FIELD_PREP(STRTAB_STE_1_EATS,
-						 STRTAB_STE_1_EATS_TRANS));
-
-	target.data[0] = cpu_to_le64(val);
 	arm_smmu_write_ste(smmu, sid, dst, &target);
 }
 
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:41 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:41 -0400
Subject: [PATCH v3 09/19] iommu/arm-smmu-v3: Hold arm_smmu_asid_lock during all of attach_dev
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <9-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

The BTM support wants to be able to change the ASID of any smmu_domain.
When it goes to do this it holds the arm_smmu_asid_lock and iterates over
the target domain's devices list.

During attach of a S1 domain we must ensure that the devices list and
CD are in sync, otherwise we could miss CD updates or a parallel CD update
could push an out of date CD.

This is pretty complicated, and almost works today because
arm_smmu_detach_dev() removes the master from the linked list before
working on the CD entries, preventing parallel update of the CD.

However, it does have an issue where the CD can remain programed while the
domain appears to be unattached. arm_smmu_share_asid() will then not clear
any CD entriess and install its own CD entry with the same ASID
concurrently. This creates a small race window where the IOMMU can see two
ASIDs pointing to different translations.

Solve this by wrapping most of the attach flow in the
arm_smmu_asid_lock. This locks more than strictly needed to prepare for
the next patch which will reorganize the order of the linked list, STE and
CD changes.

Move arm_smmu_detach_dev() till after we have initialized the domain so
the lock can be held for less time.

Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 22 ++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e2ae0081c47820..c375da195af713 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2560,8 +2560,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		return -EBUSY;
 	}
 
-	arm_smmu_detach_dev(master);
-
 	mutex_lock(&smmu_domain->init_mutex);
 
 	if (!smmu_domain->smmu) {
@@ -2576,6 +2574,16 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	if (ret)
 		return ret;
 
+	/*
+	 * Prevent arm_smmu_share_asid() from trying to change the ASID
+	 * of either the old or new domain while we are working on it.
+	 * This allows the STE and the smmu_domain->devices list to
+	 * be inconsistent during this routine.
+	 */
+	mutex_lock(&arm_smmu_asid_lock);
+
+	arm_smmu_detach_dev(master);
+
 	master->domain = smmu_domain;
 
 	/*
@@ -2601,13 +2609,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 			}
 		}
 
-		/*
-		 * Prevent SVA from concurrently modifying the CD or writing to
-		 * the CD entry
-		 */
-		mutex_lock(&arm_smmu_asid_lock);
 		ret = arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, &smmu_domain->cd);
-		mutex_unlock(&arm_smmu_asid_lock);
 		if (ret) {
 			master->domain = NULL;
 			goto out_list_del;
@@ -2617,13 +2619,15 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	arm_smmu_install_ste_for_dev(master);
 
 	arm_smmu_enable_ats(master);
-	return 0;
+	goto out_unlock;
 
 out_list_del:
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
 	list_del(&master->domain_head);
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
+out_unlock:
+	mutex_unlock(&arm_smmu_asid_lock);
 	return ret;
 }
 
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:35 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:35 -0400
Subject: [PATCH v3 03/19] iommu/arm-smmu-v3: Remove ARM_SMMU_DOMAIN_NESTED
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <3-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Currently this is exactly the same as ARM_SMMU_DOMAIN_S2, so just remove
it. The ongoing work to add nesting support through iommufd will do
something a little different.

Reviewed-by: Moritz Fischer <mdf at kernel.org>
Reviewed-by: Eric Auger <eric.auger at redhat.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 +---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 -
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 89e9c001faad71..b120d836681c1c 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1286,7 +1286,6 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 			cd_table = &master->cd_table;
 			break;
 		case ARM_SMMU_DOMAIN_S2:
-		case ARM_SMMU_DOMAIN_NESTED:
 			s2_cfg = &smmu_domain->s2_cfg;
 			break;
 		default:
@@ -2167,7 +2166,6 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain)
 		fmt = ARM_64_LPAE_S1;
 		finalise_stage_fn = arm_smmu_domain_finalise_s1;
 		break;
-	case ARM_SMMU_DOMAIN_NESTED:
 	case ARM_SMMU_DOMAIN_S2:
 		ias = smmu->ias;
 		oas = smmu->oas;
@@ -2736,7 +2734,7 @@ static int arm_smmu_enable_nesting(struct iommu_domain *domain)
 	if (smmu_domain->smmu)
 		ret = -EPERM;
 	else
-		smmu_domain->stage = ARM_SMMU_DOMAIN_NESTED;
+		smmu_domain->stage = ARM_SMMU_DOMAIN_S2;
 	mutex_unlock(&smmu_domain->init_mutex);
 
 	return ret;
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 03f9e526cbd92f..27ddf1acd12cea 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -715,7 +715,6 @@ struct arm_smmu_master {
 enum arm_smmu_domain_stage {
 	ARM_SMMU_DOMAIN_S1 = 0,
 	ARM_SMMU_DOMAIN_S2,
-	ARM_SMMU_DOMAIN_NESTED,
 	ARM_SMMU_DOMAIN_BYPASS,
 };
 
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:50 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:50 -0400
Subject: [PATCH v3 18/19] iommu/arm-smmu-v3: Pass arm_smmu_domain and arm_smmu_device to finalize
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <18-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Instead of putting container_of() casts in the internals, use the proper
type in this call chain. This makes it easier to check that the two global
static domains are not leaking into call chains they should not.

Passing the smmu avoids the only caller from having to set it and unset it
in the error path.

Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 34 ++++++++++-----------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 8269e2fed6038b..873343109a90bb 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -87,6 +87,8 @@ static struct arm_smmu_option_prop arm_smmu_options[] = {
 };
 
 static void arm_smmu_rmr_install_bypass_ste(struct arm_smmu_device *smmu);
+static int arm_smmu_domain_finalise(struct arm_smmu_domain *smmu_domain,
+				    struct arm_smmu_device *smmu);
 
 static void parse_driver_options(struct arm_smmu_device *smmu)
 {
@@ -2215,12 +2217,12 @@ static void arm_smmu_domain_free(struct iommu_domain *domain)
 	kfree(smmu_domain);
 }
 
-static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain,
+static int arm_smmu_domain_finalise_s1(struct arm_smmu_device *smmu,
+				       struct arm_smmu_domain *smmu_domain,
 				       struct io_pgtable_cfg *pgtbl_cfg)
 {
 	int ret;
 	u32 asid;
-	struct arm_smmu_device *smmu = smmu_domain->smmu;
 	struct arm_smmu_ctx_desc *cd = &smmu_domain->cd;
 	typeof(&pgtbl_cfg->arm_lpae_s1_cfg.tcr) tcr = &pgtbl_cfg->arm_lpae_s1_cfg.tcr;
 
@@ -2252,11 +2254,11 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain,
 	return ret;
 }
 
-static int arm_smmu_domain_finalise_s2(struct arm_smmu_domain *smmu_domain,
+static int arm_smmu_domain_finalise_s2(struct arm_smmu_device *smmu,
+				       struct arm_smmu_domain *smmu_domain,
 				       struct io_pgtable_cfg *pgtbl_cfg)
 {
 	int vmid;
-	struct arm_smmu_device *smmu = smmu_domain->smmu;
 	struct arm_smmu_s2_cfg *cfg = &smmu_domain->s2_cfg;
 
 	/* Reserve VMID 0 for stage-2 bypass STEs */
@@ -2269,17 +2271,17 @@ static int arm_smmu_domain_finalise_s2(struct arm_smmu_domain *smmu_domain,
 	return 0;
 }
 
-static int arm_smmu_domain_finalise(struct iommu_domain *domain)
+static int arm_smmu_domain_finalise(struct arm_smmu_domain *smmu_domain,
+				    struct arm_smmu_device *smmu)
 {
 	int ret;
 	unsigned long ias, oas;
 	enum io_pgtable_fmt fmt;
 	struct io_pgtable_cfg pgtbl_cfg;
 	struct io_pgtable_ops *pgtbl_ops;
-	int (*finalise_stage_fn)(struct arm_smmu_domain *,
-				 struct io_pgtable_cfg *);
-	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
-	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	int (*finalise_stage_fn)(struct arm_smmu_device *smmu,
+				 struct arm_smmu_domain *smmu_domain,
+				 struct io_pgtable_cfg *pgtbl_cfg);
 
 	/* Restrict the stage to what we can actually support */
 	if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S1))
@@ -2318,17 +2320,18 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain)
 	if (!pgtbl_ops)
 		return -ENOMEM;
 
-	domain->pgsize_bitmap = pgtbl_cfg.pgsize_bitmap;
-	domain->geometry.aperture_end = (1UL << pgtbl_cfg.ias) - 1;
-	domain->geometry.force_aperture = true;
+	smmu_domain->domain.pgsize_bitmap = pgtbl_cfg.pgsize_bitmap;
+	smmu_domain->domain.geometry.aperture_end = (1UL << pgtbl_cfg.ias) - 1;
+	smmu_domain->domain.geometry.force_aperture = true;
 
-	ret = finalise_stage_fn(smmu_domain, &pgtbl_cfg);
+	ret = finalise_stage_fn(smmu, smmu_domain, &pgtbl_cfg);
 	if (ret < 0) {
 		free_io_pgtable_ops(pgtbl_ops);
 		return ret;
 	}
 
 	smmu_domain->pgtbl_ops = pgtbl_ops;
+	smmu_domain->smmu = smmu;
 	return 0;
 }
 
@@ -2520,10 +2523,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	mutex_lock(&smmu_domain->init_mutex);
 
 	if (!smmu_domain->smmu) {
-		smmu_domain->smmu = smmu;
-		ret = arm_smmu_domain_finalise(domain);
-		if (ret)
-			smmu_domain->smmu = NULL;
+		ret = arm_smmu_domain_finalise(smmu_domain, smmu);
 	} else if (smmu_domain->smmu != smmu)
 		ret = -EINVAL;
 
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:48 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:48 -0400
Subject: [PATCH v3 16/19] iommu/arm-smmu-v3: Add a global static BLOCKED domain
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <16-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Using the same design as the IDENTITY domain install an
STRTAB_STE_0_CFG_ABORT STE.

Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 9899caeabc8744..386bf954542e7d 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2647,6 +2647,24 @@ static struct iommu_domain arm_smmu_identity_domain = {
 	.ops = &arm_smmu_identity_ops,
 };
 
+static int arm_smmu_attach_dev_blocked(struct iommu_domain *domain,
+					struct device *dev)
+{
+	struct arm_smmu_ste ste;
+
+	arm_smmu_make_abort_ste(&ste);
+	return arm_smmu_attach_dev_ste(dev, &ste);
+}
+
+static const struct iommu_domain_ops arm_smmu_blocked_ops = {
+	.attach_dev = arm_smmu_attach_dev_blocked,
+};
+
+static struct iommu_domain arm_smmu_blocked_domain = {
+	.type = IOMMU_DOMAIN_BLOCKED,
+	.ops = &arm_smmu_blocked_ops,
+};
+
 static int arm_smmu_map_pages(struct iommu_domain *domain, unsigned long iova,
 			      phys_addr_t paddr, size_t pgsize, size_t pgcount,
 			      int prot, gfp_t gfp, size_t *mapped)
@@ -3041,6 +3059,7 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
 
 static struct iommu_ops arm_smmu_ops = {
 	.identity_domain	= &arm_smmu_identity_domain,
+	.blocked_domain		= &arm_smmu_blocked_domain,
 	.capable		= arm_smmu_capable,
 	.domain_alloc		= arm_smmu_domain_alloc,
 	.probe_device		= arm_smmu_probe_device,
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:42 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:42 -0400
Subject: [PATCH v3 10/19] iommu/arm-smmu-v3: Compute the STE only once for each master
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <10-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Currently arm_smmu_install_ste_for_dev() iterates over every SID and
computes from scratch an identical STE. Every SID should have the same STE
contents. Turn this inside out so that the STE is supplied by the caller
and arm_smmu_install_ste_for_dev() simply installs it to every SID.

This is possible now that the STE generation does not inform what sequence
should be used to program it.

This allows splitting the STE calculation up according to the call site,
which following patches will make use of, and removes the confusing NULL
domain special case that only supported arm_smmu_detach_dev().

Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 58 ++++++++-------------
 1 file changed, 22 insertions(+), 36 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index c375da195af713..0c1d70b8f325ed 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1535,36 +1535,6 @@ static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
 				      STRTAB_STE_3_S2TTB_MASK);
 }
 
-static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
-				      struct arm_smmu_ste *dst)
-{
-	struct arm_smmu_device *smmu = master->smmu;
-	struct arm_smmu_domain *smmu_domain = master->domain;
-	struct arm_smmu_ste target = {};
-
-	if (!smmu_domain) {
-		if (disable_bypass)
-			arm_smmu_make_abort_ste(&target);
-		else
-			arm_smmu_make_bypass_ste(&target);
-		arm_smmu_write_ste(smmu, sid, dst, &target);
-		return;
-	}
-
-	switch (smmu_domain->stage) {
-	case ARM_SMMU_DOMAIN_S1:
-		arm_smmu_make_cdtable_ste(&target, master, &master->cd_table);
-		break;
-	case ARM_SMMU_DOMAIN_S2:
-		arm_smmu_make_s2_domain_ste(&target, master, smmu_domain);
-		break;
-	case ARM_SMMU_DOMAIN_BYPASS:
-		arm_smmu_make_bypass_ste(&target);
-		break;
-	}
-	arm_smmu_write_ste(smmu, sid, dst, &target);
-}
-
 static void arm_smmu_init_bypass_stes(struct arm_smmu_ste *strtab,
 				      unsigned int nent)
 {
@@ -2387,7 +2357,8 @@ arm_smmu_get_step_for_sid(struct arm_smmu_device *smmu, u32 sid)
 	}
 }
 
-static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
+static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master,
+					 const struct arm_smmu_ste *target)
 {
 	int i, j;
 	struct arm_smmu_device *smmu = master->smmu;
@@ -2404,7 +2375,7 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
 		if (j < i)
 			continue;
 
-		arm_smmu_write_strtab_ent(master, sid, step);
+		arm_smmu_write_ste(smmu, sid, step, target);
 	}
 }
 
@@ -2511,6 +2482,7 @@ static void arm_smmu_disable_pasid(struct arm_smmu_master *master)
 static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 {
 	unsigned long flags;
+	struct arm_smmu_ste target;
 	struct arm_smmu_domain *smmu_domain = master->domain;
 
 	if (!smmu_domain)
@@ -2524,7 +2496,11 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 
 	master->domain = NULL;
 	master->ats_enabled = false;
-	arm_smmu_install_ste_for_dev(master);
+	if (disable_bypass)
+		arm_smmu_make_abort_ste(&target);
+	else
+		arm_smmu_make_bypass_ste(&target);
+	arm_smmu_install_ste_for_dev(master, &target);
 	/*
 	 * Clearing the CD entry isn't strictly required to detach the domain
 	 * since the table is uninstalled anyway, but it helps avoid confusion
@@ -2539,6 +2515,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 {
 	int ret = 0;
 	unsigned long flags;
+	struct arm_smmu_ste target;
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
 	struct arm_smmu_device *smmu;
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
@@ -2600,7 +2577,8 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	list_add(&master->domain_head, &smmu_domain->devices);
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
-	if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
+	switch (smmu_domain->stage) {
+	case ARM_SMMU_DOMAIN_S1:
 		if (!master->cd_table.cdtab) {
 			ret = arm_smmu_alloc_cd_tables(master);
 			if (ret) {
@@ -2614,9 +2592,17 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 			master->domain = NULL;
 			goto out_list_del;
 		}
-	}
 
-	arm_smmu_install_ste_for_dev(master);
+		arm_smmu_make_cdtable_ste(&target, master, &master->cd_table);
+		break;
+	case ARM_SMMU_DOMAIN_S2:
+		arm_smmu_make_s2_domain_ste(&target, master, smmu_domain);
+		break;
+	case ARM_SMMU_DOMAIN_BYPASS:
+		arm_smmu_make_bypass_ste(&target);
+		break;
+	}
+	arm_smmu_install_ste_for_dev(master, &target);
 
 	arm_smmu_enable_ats(master);
 	goto out_unlock;
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:47 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:47 -0400
Subject: [PATCH v3 15/19] iommu/arm-smmu-v3: Add a global static IDENTITY domain
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <15-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Move to the new static global for identity domains. Move all the logic out
of arm_smmu_attach_dev into an identity only function.

Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 82 +++++++++++++++------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  1 -
 2 files changed, 58 insertions(+), 25 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 525048a79e8a90..9899caeabc8744 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2173,8 +2173,7 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
 		return arm_smmu_sva_domain_alloc();
 
 	if (type != IOMMU_DOMAIN_UNMANAGED &&
-	    type != IOMMU_DOMAIN_DMA &&
-	    type != IOMMU_DOMAIN_IDENTITY)
+	    type != IOMMU_DOMAIN_DMA)
 		return NULL;
 
 	/*
@@ -2282,11 +2281,6 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain)
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
 	struct arm_smmu_device *smmu = smmu_domain->smmu;
 
-	if (domain->type == IOMMU_DOMAIN_IDENTITY) {
-		smmu_domain->stage = ARM_SMMU_DOMAIN_BYPASS;
-		return 0;
-	}
-
 	/* Restrict the stage to what we can actually support */
 	if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S1))
 		smmu_domain->stage = ARM_SMMU_DOMAIN_S2;
@@ -2484,7 +2478,7 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 	struct arm_smmu_domain *smmu_domain;
 	unsigned long flags;
 
-	if (!domain)
+	if (!domain || !(domain->type & __IOMMU_DOMAIN_PAGING))
 		return;
 
 	smmu_domain = to_smmu_domain(domain);
@@ -2547,15 +2541,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 
 	arm_smmu_detach_dev(master);
 
-	/*
-	 * The SMMU does not support enabling ATS with bypass. When the STE is
-	 * in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests and
-	 * Translated transactions are denied as though ATS is disabled for the
-	 * stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
-	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
-	 */
-	if (smmu_domain->stage != ARM_SMMU_DOMAIN_BYPASS)
-		master->ats_enabled = arm_smmu_ats_supported(master);
+	master->ats_enabled = arm_smmu_ats_supported(master);
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
 	list_add(&master->domain_head, &smmu_domain->devices);
@@ -2592,13 +2578,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 			arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
 						      NULL);
 		break;
-	case ARM_SMMU_DOMAIN_BYPASS:
-		arm_smmu_make_bypass_ste(&target);
-		arm_smmu_install_ste_for_dev(master, &target);
-		if (master->cd_table.cdtab)
-			arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
-						      NULL);
-		break;
 	}
 
 	arm_smmu_enable_ats(master, smmu_domain);
@@ -2614,6 +2593,60 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	return ret;
 }
 
+static int arm_smmu_attach_dev_ste(struct device *dev,
+				   struct arm_smmu_ste *ste)
+{
+	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+
+	if (arm_smmu_master_sva_enabled(master))
+		return -EBUSY;
+
+	/*
+	 * Do not allow any ASID to be changed while are working on the STE,
+	 * otherwise we could miss invalidations.
+	 */
+	mutex_lock(&arm_smmu_asid_lock);
+
+	/*
+	 * The SMMU does not support enabling ATS with bypass/abort. When the
+	 * STE is in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests
+	 * and Translated transactions are denied as though ATS is disabled for
+	 * the stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
+	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
+	 */
+	arm_smmu_detach_dev(master);
+
+	arm_smmu_install_ste_for_dev(master, ste);
+	mutex_unlock(&arm_smmu_asid_lock);
+
+	/*
+	 * This has to be done after removing the master from the
+	 * arm_smmu_domain->devices to avoid races updating the same context
+	 * descriptor from arm_smmu_share_asid().
+	 */
+	if (master->cd_table.cdtab)
+		arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);
+	return 0;
+}
+
+static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
+					struct device *dev)
+{
+	struct arm_smmu_ste ste;
+
+	arm_smmu_make_bypass_ste(&ste);
+	return arm_smmu_attach_dev_ste(dev, &ste);
+}
+
+static const struct iommu_domain_ops arm_smmu_identity_ops = {
+	.attach_dev = arm_smmu_attach_dev_identity,
+};
+
+static struct iommu_domain arm_smmu_identity_domain = {
+	.type = IOMMU_DOMAIN_IDENTITY,
+	.ops = &arm_smmu_identity_ops,
+};
+
 static int arm_smmu_map_pages(struct iommu_domain *domain, unsigned long iova,
 			      phys_addr_t paddr, size_t pgsize, size_t pgcount,
 			      int prot, gfp_t gfp, size_t *mapped)
@@ -3007,6 +3040,7 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
 }
 
 static struct iommu_ops arm_smmu_ops = {
+	.identity_domain	= &arm_smmu_identity_domain,
 	.capable		= arm_smmu_capable,
 	.domain_alloc		= arm_smmu_domain_alloc,
 	.probe_device		= arm_smmu_probe_device,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 21f2f73501019a..154808f96718df 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -712,7 +712,6 @@ struct arm_smmu_master {
 enum arm_smmu_domain_stage {
 	ARM_SMMU_DOMAIN_S1 = 0,
 	ARM_SMMU_DOMAIN_S2,
-	ARM_SMMU_DOMAIN_BYPASS,
 };
 
 struct arm_smmu_domain {
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:33 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:33 -0400
Subject: [PATCH v3 01/19] iommu/arm-smmu-v3: Add a type for the STE
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <1-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Instead of passing a naked __le16 * around to represent a STE wrap it in a
"struct arm_smmu_ste" with an array of the correct size. This makes it
much clearer which functions will comprise the "STE API".

Reviewed-by: Moritz Fischer <mdf at kernel.org>
Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Eric Auger <eric.auger at redhat.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 59 ++++++++++-----------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  7 ++-
 2 files changed, 35 insertions(+), 31 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 7445454c2af244..c5895f4d7d6c9d 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1249,7 +1249,7 @@ static void arm_smmu_sync_ste_for_sid(struct arm_smmu_device *smmu, u32 sid)
 }
 
 static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
-				      __le64 *dst)
+				      struct arm_smmu_ste *dst)
 {
 	/*
 	 * This is hideously complicated, but we only really care about
@@ -1267,7 +1267,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 	 * 2. Write everything apart from dword 0, sync, write dword 0, sync
 	 * 3. Update Config, sync
 	 */
-	u64 val = le64_to_cpu(dst[0]);
+	u64 val = le64_to_cpu(dst->data[0]);
 	bool ste_live = false;
 	struct arm_smmu_device *smmu = NULL;
 	struct arm_smmu_ctx_desc_cfg *cd_table = NULL;
@@ -1325,10 +1325,10 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 		else
 			val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_BYPASS);
 
-		dst[0] = cpu_to_le64(val);
-		dst[1] = cpu_to_le64(FIELD_PREP(STRTAB_STE_1_SHCFG,
+		dst->data[0] = cpu_to_le64(val);
+		dst->data[1] = cpu_to_le64(FIELD_PREP(STRTAB_STE_1_SHCFG,
 						STRTAB_STE_1_SHCFG_INCOMING));
-		dst[2] = 0; /* Nuke the VMID */
+		dst->data[2] = 0; /* Nuke the VMID */
 		/*
 		 * The SMMU can perform negative caching, so we must sync
 		 * the STE regardless of whether the old value was live.
@@ -1343,7 +1343,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 			STRTAB_STE_1_STRW_EL2 : STRTAB_STE_1_STRW_NSEL1;
 
 		BUG_ON(ste_live);
-		dst[1] = cpu_to_le64(
+		dst->data[1] = cpu_to_le64(
 			 FIELD_PREP(STRTAB_STE_1_S1DSS, STRTAB_STE_1_S1DSS_SSID0) |
 			 FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) |
 			 FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) |
@@ -1352,7 +1352,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 
 		if (smmu->features & ARM_SMMU_FEAT_STALLS &&
 		    !master->stall_enabled)
-			dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
+			dst->data[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
 
 		val |= (cd_table->cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) |
 			FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S1_TRANS) |
@@ -1362,7 +1362,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 
 	if (s2_cfg) {
 		BUG_ON(ste_live);
-		dst[2] = cpu_to_le64(
+		dst->data[2] = cpu_to_le64(
 			 FIELD_PREP(STRTAB_STE_2_S2VMID, s2_cfg->vmid) |
 			 FIELD_PREP(STRTAB_STE_2_VTCR, s2_cfg->vtcr) |
 #ifdef __BIG_ENDIAN
@@ -1371,18 +1371,18 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 			 STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2AA64 |
 			 STRTAB_STE_2_S2R);
 
-		dst[3] = cpu_to_le64(s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK);
+		dst->data[3] = cpu_to_le64(s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK);
 
 		val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S2_TRANS);
 	}
 
 	if (master->ats_enabled)
-		dst[1] |= cpu_to_le64(FIELD_PREP(STRTAB_STE_1_EATS,
+		dst->data[1] |= cpu_to_le64(FIELD_PREP(STRTAB_STE_1_EATS,
 						 STRTAB_STE_1_EATS_TRANS));
 
 	arm_smmu_sync_ste_for_sid(smmu, sid);
 	/* See comment in arm_smmu_write_ctx_desc() */
-	WRITE_ONCE(dst[0], cpu_to_le64(val));
+	WRITE_ONCE(dst->data[0], cpu_to_le64(val));
 	arm_smmu_sync_ste_for_sid(smmu, sid);
 
 	/* It's likely that we'll want to use the new STE soon */
@@ -1390,7 +1390,8 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 		arm_smmu_cmdq_issue_cmd(smmu, &prefetch_cmd);
 }
 
-static void arm_smmu_init_bypass_stes(__le64 *strtab, unsigned int nent, bool force)
+static void arm_smmu_init_bypass_stes(struct arm_smmu_ste *strtab,
+				      unsigned int nent, bool force)
 {
 	unsigned int i;
 	u64 val = STRTAB_STE_0_V;
@@ -1401,11 +1402,11 @@ static void arm_smmu_init_bypass_stes(__le64 *strtab, unsigned int nent, bool fo
 		val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_BYPASS);
 
 	for (i = 0; i < nent; ++i) {
-		strtab[0] = cpu_to_le64(val);
-		strtab[1] = cpu_to_le64(FIELD_PREP(STRTAB_STE_1_SHCFG,
-						   STRTAB_STE_1_SHCFG_INCOMING));
-		strtab[2] = 0;
-		strtab += STRTAB_STE_DWORDS;
+		strtab->data[0] = cpu_to_le64(val);
+		strtab->data[1] = cpu_to_le64(FIELD_PREP(
+			STRTAB_STE_1_SHCFG, STRTAB_STE_1_SHCFG_INCOMING));
+		strtab->data[2] = 0;
+		strtab++;
 	}
 }
 
@@ -2209,26 +2210,23 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain)
 	return 0;
 }
 
-static __le64 *arm_smmu_get_step_for_sid(struct arm_smmu_device *smmu, u32 sid)
+static struct arm_smmu_ste *
+arm_smmu_get_step_for_sid(struct arm_smmu_device *smmu, u32 sid)
 {
-	__le64 *step;
 	struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
 
 	if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
-		struct arm_smmu_strtab_l1_desc *l1_desc;
-		int idx;
+		unsigned int idx1, idx2;
 
 		/* Two-level walk */
-		idx = (sid >> STRTAB_SPLIT) * STRTAB_L1_DESC_DWORDS;
-		l1_desc = &cfg->l1_desc[idx];
-		idx = (sid & ((1 << STRTAB_SPLIT) - 1)) * STRTAB_STE_DWORDS;
-		step = &l1_desc->l2ptr[idx];
+		idx1 = (sid >> STRTAB_SPLIT) * STRTAB_L1_DESC_DWORDS;
+		idx2 = sid & ((1 << STRTAB_SPLIT) - 1);
+		return &cfg->l1_desc[idx1].l2ptr[idx2];
 	} else {
 		/* Simple linear lookup */
-		step = &cfg->strtab[sid * STRTAB_STE_DWORDS];
+		return (struct arm_smmu_ste *)&cfg
+			       ->strtab[sid * STRTAB_STE_DWORDS];
 	}
-
-	return step;
 }
 
 static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
@@ -2238,7 +2236,8 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
 
 	for (i = 0; i < master->num_streams; ++i) {
 		u32 sid = master->streams[i].id;
-		__le64 *step = arm_smmu_get_step_for_sid(smmu, sid);
+		struct arm_smmu_ste *step =
+			arm_smmu_get_step_for_sid(smmu, sid);
 
 		/* Bridged PCI devices may end up with duplicated IDs */
 		for (j = 0; j < i; j++)
@@ -3769,7 +3768,7 @@ static void arm_smmu_rmr_install_bypass_ste(struct arm_smmu_device *smmu)
 	iort_get_rmr_sids(dev_fwnode(smmu->dev), &rmr_list);
 
 	list_for_each_entry(e, &rmr_list, list) {
-		__le64 *step;
+		struct arm_smmu_ste *step;
 		struct iommu_iort_rmr_data *rmr;
 		int ret, i;
 
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 961205ba86d25d..03f9e526cbd92f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -206,6 +206,11 @@
 #define STRTAB_L1_DESC_L2PTR_MASK	GENMASK_ULL(51, 6)
 
 #define STRTAB_STE_DWORDS		8
+
+struct arm_smmu_ste {
+	__le64 data[STRTAB_STE_DWORDS];
+};
+
 #define STRTAB_STE_0_V			(1UL << 0)
 #define STRTAB_STE_0_CFG		GENMASK_ULL(3, 1)
 #define STRTAB_STE_0_CFG_ABORT		0
@@ -571,7 +576,7 @@ struct arm_smmu_priq {
 struct arm_smmu_strtab_l1_desc {
 	u8				span;
 
-	__le64				*l2ptr;
+	struct arm_smmu_ste		*l2ptr;
 	dma_addr_t			l2ptr_dma;
 };
 
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:34 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:34 -0400
Subject: [PATCH v3 02/19] iommu/arm-smmu-v3: Master cannot be NULL in arm_smmu_write_strtab_ent()
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <2-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

The only caller is arm_smmu_install_ste_for_dev() which never has a NULL
master. Remove the confusing if.

Reviewed-by: Moritz Fischer <mdf at kernel.org>
Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Eric Auger <eric.auger at redhat.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index c5895f4d7d6c9d..89e9c001faad71 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1269,10 +1269,10 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 	 */
 	u64 val = le64_to_cpu(dst->data[0]);
 	bool ste_live = false;
-	struct arm_smmu_device *smmu = NULL;
+	struct arm_smmu_device *smmu = master->smmu;
 	struct arm_smmu_ctx_desc_cfg *cd_table = NULL;
 	struct arm_smmu_s2_cfg *s2_cfg = NULL;
-	struct arm_smmu_domain *smmu_domain = NULL;
+	struct arm_smmu_domain *smmu_domain = master->domain;
 	struct arm_smmu_cmdq_ent prefetch_cmd = {
 		.opcode		= CMDQ_OP_PREFETCH_CFG,
 		.prefetch	= {
@@ -1280,11 +1280,6 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 		},
 	};
 
-	if (master) {
-		smmu_domain = master->domain;
-		smmu = master->smmu;
-	}
-
 	if (smmu_domain) {
 		switch (smmu_domain->stage) {
 		case ARM_SMMU_DOMAIN_S1:
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:49 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:49 -0400
Subject: [PATCH v3 17/19] iommu/arm-smmu-v3: Use the identity/blocked domain during release
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <17-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Consolidate some more code by having release call
arm_smmu_attach_dev_identity/blocked() instead of open coding this.

Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 386bf954542e7d..8269e2fed6038b 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2901,19 +2901,16 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 static void arm_smmu_release_device(struct device *dev)
 {
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
-	struct arm_smmu_ste target;
 
 	if (WARN_ON(arm_smmu_master_sva_enabled(master)))
 		iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
 
 	/* Put the STE back to what arm_smmu_init_strtab() sets */
 	if (disable_bypass && !dev->iommu->require_direct)
-		arm_smmu_make_abort_ste(&target);
+		arm_smmu_attach_dev_blocked(&arm_smmu_blocked_domain, dev);
 	else
-		arm_smmu_make_bypass_ste(&target);
-	arm_smmu_install_ste_for_dev(master, &target);
+		arm_smmu_attach_dev_identity(&arm_smmu_identity_domain, dev);
 
-	arm_smmu_detach_dev(master);
 	arm_smmu_disable_pasid(master);
 	arm_smmu_remove_master(master);
 	if (master->cd_table.cdtab)
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:40 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:40 -0400
Subject: [PATCH v3 08/19] iommu/arm-smmu-v3: Build the whole STE in arm_smmu_make_s2_domain_ste()
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <8-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Half the code was living in arm_smmu_domain_finalise_s2(), just move it
here and take the values directly from the pgtbl_ops instead of storing
copies.

Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 27 ++++++++++++---------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  2 --
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index b3b28c10bd042e..e2ae0081c47820 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1499,6 +1499,11 @@ static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
 					struct arm_smmu_domain *smmu_domain)
 {
 	struct arm_smmu_s2_cfg *s2_cfg = &smmu_domain->s2_cfg;
+	const struct io_pgtable_cfg *pgtbl_cfg =
+		&io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops)->cfg;
+	typeof(&pgtbl_cfg->arm_lpae_s2_cfg.vtcr) vtcr =
+		&pgtbl_cfg->arm_lpae_s2_cfg.vtcr;
+	u64 vtcr_val;
 
 	memset(target, 0, sizeof(*target));
 	target->data[0] = cpu_to_le64(
@@ -1509,9 +1514,16 @@ static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
 		FIELD_PREP(STRTAB_STE_1_EATS,
 			   master->ats_enabled ? STRTAB_STE_1_EATS_TRANS : 0));
 
+	vtcr_val = FIELD_PREP(STRTAB_STE_2_VTCR_S2T0SZ, vtcr->tsz) |
+		   FIELD_PREP(STRTAB_STE_2_VTCR_S2SL0, vtcr->sl) |
+		   FIELD_PREP(STRTAB_STE_2_VTCR_S2IR0, vtcr->irgn) |
+		   FIELD_PREP(STRTAB_STE_2_VTCR_S2OR0, vtcr->orgn) |
+		   FIELD_PREP(STRTAB_STE_2_VTCR_S2SH0, vtcr->sh) |
+		   FIELD_PREP(STRTAB_STE_2_VTCR_S2TG, vtcr->tg) |
+		   FIELD_PREP(STRTAB_STE_2_VTCR_S2PS, vtcr->ps);
 	target->data[2] = cpu_to_le64(
 		FIELD_PREP(STRTAB_STE_2_S2VMID, s2_cfg->vmid) |
-		FIELD_PREP(STRTAB_STE_2_VTCR, s2_cfg->vtcr) |
+		FIELD_PREP(STRTAB_STE_2_VTCR, vtcr_val) |
 		STRTAB_STE_2_S2AA64 |
 #ifdef __BIG_ENDIAN
 		STRTAB_STE_2_S2ENDI |
@@ -1519,7 +1531,8 @@ static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
 		STRTAB_STE_2_S2PTW |
 		STRTAB_STE_2_S2R);
 
-	target->data[3] = cpu_to_le64(s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK);
+	target->data[3] = cpu_to_le64(pgtbl_cfg->arm_lpae_s2_cfg.vttbr &
+				      STRTAB_STE_3_S2TTB_MASK);
 }
 
 static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
@@ -2276,7 +2289,6 @@ static int arm_smmu_domain_finalise_s2(struct arm_smmu_domain *smmu_domain,
 	int vmid;
 	struct arm_smmu_device *smmu = smmu_domain->smmu;
 	struct arm_smmu_s2_cfg *cfg = &smmu_domain->s2_cfg;
-	typeof(&pgtbl_cfg->arm_lpae_s2_cfg.vtcr) vtcr;
 
 	/* Reserve VMID 0 for stage-2 bypass STEs */
 	vmid = ida_alloc_range(&smmu->vmid_map, 1, (1 << smmu->vmid_bits) - 1,
@@ -2284,16 +2296,7 @@ static int arm_smmu_domain_finalise_s2(struct arm_smmu_domain *smmu_domain,
 	if (vmid < 0)
 		return vmid;
 
-	vtcr = &pgtbl_cfg->arm_lpae_s2_cfg.vtcr;
 	cfg->vmid	= (u16)vmid;
-	cfg->vttbr	= pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
-	cfg->vtcr	= FIELD_PREP(STRTAB_STE_2_VTCR_S2T0SZ, vtcr->tsz) |
-			  FIELD_PREP(STRTAB_STE_2_VTCR_S2SL0, vtcr->sl) |
-			  FIELD_PREP(STRTAB_STE_2_VTCR_S2IR0, vtcr->irgn) |
-			  FIELD_PREP(STRTAB_STE_2_VTCR_S2OR0, vtcr->orgn) |
-			  FIELD_PREP(STRTAB_STE_2_VTCR_S2SH0, vtcr->sh) |
-			  FIELD_PREP(STRTAB_STE_2_VTCR_S2TG, vtcr->tg) |
-			  FIELD_PREP(STRTAB_STE_2_VTCR_S2PS, vtcr->ps);
 	return 0;
 }
 
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 27ddf1acd12cea..1be0c1151c50c3 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -609,8 +609,6 @@ struct arm_smmu_ctx_desc_cfg {
 
 struct arm_smmu_s2_cfg {
 	u16				vmid;
-	u64				vttbr;
-	u64				vtcr;
 };
 
 struct arm_smmu_strtab_cfg {
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:36 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:36 -0400
Subject: [PATCH v3 04/19] iommu/arm-smmu-v3: Make STE programming independent of the callers
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <4-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

As the comment in arm_smmu_write_strtab_ent() explains, this routine has
been limited to only work correctly in certain scenarios that the caller
must ensure. Generally the caller must put the STE into ABORT or BYPASS
before attempting to program it to something else.

The next patches/series are going to start removing some of this logic
from the callers, and add more complex state combinations than currently.

Thus, consolidate all the complexity here. Callers do not have to care
about what STE transition they are doing, this function will handle
everything optimally.

Revise arm_smmu_write_strtab_ent() so it algorithmically computes the
required programming sequence to avoid creating an incoherent 'torn' STE
in the HW caches. The update algorithm follows the same design that the
driver already uses: it is safe to change bits that HW doesn't currently
use and then do a single 64 bit update, with sync's in between.

The basic idea is to express in a bitmask what bits the HW is actually
using based on the V and CFG bits. Based on that mask we know what STE
changes are safe and which are disruptive. We can count how many 64 bit
QWORDS need a disruptive update and know if a step with V=0 is required.

This gives two basic flows through the algorithm.

If only a single 64 bit quantity needs disruptive replacement:
 - Write the target value into all currently unused bits
 - Write the single 64 bit quantity
 - Zero the remaining different bits

If multiple 64 bit quantities need disruptive replacement then do:
 - Write V=0 to QWORD 0
 - Write the entire STE except QWORD 0
 - Write QWORD 0

With HW flushes at each step, that can be skipped if the STE didn't change
in that step.

At this point it generates the same sequence of updates as the current
code, except that zeroing the VMID on entry to BYPASS/ABORT will do an
extra sync (this seems to be an existing bug).

Going forward this will use a V=0 transition instead of cycling through
ABORT if a hitfull change is required. This seems more appropriate as ABORT
will fail DMAs without any logging, but dropping a DMA due to transient
V=0 is probably signaling a bug, so the C_BAD_STE is valuable.

Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 272 +++++++++++++++-----
 1 file changed, 208 insertions(+), 64 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index b120d836681c1c..0934f882b94e94 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -971,6 +971,101 @@ void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid)
 	arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
 }
 
+/*
+ * This algorithm updates any STE/CD to any value without creating a situation
+ * where the HW can percieve a corrupted entry. HW is only required to have a 64
+ * bit atomicity with stores from the CPU, while entries are many 64 bit values
+ * big.
+ *
+ * The algorithm works by evolving the entry toward the target in a series of
+ * steps. Each step synchronizes with the HW so that the HW can not see an entry
+ * torn across two steps. Upon each call cur/cur_used reflect the current
+ * synchronized value seen by the HW.
+ *
+ * During each step the HW can observe a torn entry that has any combination of
+ * the step's old/new 64 bit words. The algorithm objective is for the HW
+ * behavior to always be one of current behavior, V=0, or new behavior, during
+ * each step, and across all steps.
+ *
+ * At each step one of three actions is chosen to evolve cur to target:
+ *  - Update all unused bits with their target values.
+ *    This relies on the IGNORED behavior described in the specification
+ *  - Update a single 64-bit value
+ *  - Update all unused bits and set V=0
+ *
+ * The last two actions will cause cur_used to change, which will then allow the
+ * first action on the next step.
+ *
+ * In the most general case we can make any update in three steps:
+ *  - Disrupting the entry (V=0)
+ *  - Fill now unused bits, all bits except V
+ *  - Make valid (V=1), single 64 bit store
+ *
+ * However this disrupts the HW while it is happening. There are several
+ * interesting cases where a STE/CD can be updated without disturbing the HW
+ * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
+ * because the used bits don't intersect. We can detect this by calculating how
+ * many 64 bit values need update after adjusting the unused bits and skip the
+ * V=0 process.
+ */
+static bool arm_smmu_write_entry_step(__le64 *cur, const __le64 *cur_used,
+				      const __le64 *target,
+				      const __le64 *target_used, __le64 *step,
+				      __le64 v_bit,
+				      unsigned int len)
+{
+	u8 step_used_diff = 0;
+	u8 step_change = 0;
+	unsigned int i;
+
+	/*
+	 * Compute a step that has all the bits currently unused by HW set to
+	 * their target values.
+	 */
+	for (i = 0; i != len; i++) {
+		step[i] = (cur[i] & cur_used[i]) | (target[i] & ~cur_used[i]);
+		if (cur[i] != step[i])
+			step_change |= 1 << i;
+		/*
+		 * Each bit indicates if the step is incorrect compared to the
+		 * target, considering only the used bits in the target
+		 */
+		if ((step[i] & target_used[i]) != (target[i] & target_used[i]))
+			step_used_diff |= 1 << i;
+	}
+
+	if (hweight8(step_used_diff) > 1) {
+		/*
+		 * More than 1 qword is mismatched, this cannot be done without
+		 * a break. Clear the V bit and go again.
+		 */
+		step[0] &= ~v_bit;
+	} else if (!step_change && step_used_diff) {
+		/*
+		 * Have exactly one critical qword, all the other qwords are set
+		 * correctly, so we can set this qword now.
+		 */
+		i = ffs(step_used_diff) - 1;
+		step[i] = target[i];
+	} else if (!step_change) {
+		/* cur == target, so all done */
+		if (memcmp(cur, target, len * sizeof(*cur)) == 0)
+			return true;
+
+		/*
+		 * All the used HW bits match, but unused bits are different.
+		 * Set them as well. Technically this isn't necessary but it
+		 * brings the entry to the full target state, so if there are
+		 * bugs in the mask calculation this will obscure them.
+		 */
+		memcpy(step, target, len * sizeof(*step));
+	}
+
+	for (i = 0; i != len; i++)
+		WRITE_ONCE(cur[i], step[i]);
+	return false;
+}
+
 static void arm_smmu_sync_cd(struct arm_smmu_master *master,
 			     int ssid, bool leaf)
 {
@@ -1248,37 +1343,115 @@ static void arm_smmu_sync_ste_for_sid(struct arm_smmu_device *smmu, u32 sid)
 	arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
 }
 
+/*
+ * Based on the value of ent report which bits of the STE the HW will access. It
+ * would be nice if this was complete according to the spec, but minimally it
+ * has to capture the bits this driver uses.
+ */
+static void arm_smmu_get_ste_used(const struct arm_smmu_ste *ent,
+				  struct arm_smmu_ste *used_bits)
+{
+	memset(used_bits, 0, sizeof(*used_bits));
+
+	used_bits->data[0] = cpu_to_le64(STRTAB_STE_0_V);
+	if (!(ent->data[0] & cpu_to_le64(STRTAB_STE_0_V)))
+		return;
+
+	/*
+	 * If S1 is enabled S1DSS is valid, see 13.5 Summary of
+	 * attribute/permission configuration fields for the SHCFG behavior.
+	 */
+	if (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(ent->data[0])) & 1 &&
+	    FIELD_GET(STRTAB_STE_1_S1DSS, le64_to_cpu(ent->data[1])) ==
+		    STRTAB_STE_1_S1DSS_BYPASS)
+		used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_SHCFG);
+
+	used_bits->data[0] |= cpu_to_le64(STRTAB_STE_0_CFG);
+	switch (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(ent->data[0]))) {
+	case STRTAB_STE_0_CFG_ABORT:
+		break;
+	case STRTAB_STE_0_CFG_BYPASS:
+		used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_SHCFG);
+		break;
+	case STRTAB_STE_0_CFG_S1_TRANS:
+		used_bits->data[0] |= cpu_to_le64(STRTAB_STE_0_S1FMT |
+						  STRTAB_STE_0_S1CTXPTR_MASK |
+						  STRTAB_STE_0_S1CDMAX);
+		used_bits->data[1] |=
+			cpu_to_le64(STRTAB_STE_1_S1DSS | STRTAB_STE_1_S1CIR |
+				    STRTAB_STE_1_S1COR | STRTAB_STE_1_S1CSH |
+				    STRTAB_STE_1_S1STALLD | STRTAB_STE_1_STRW);
+		used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_EATS);
+		break;
+	case STRTAB_STE_0_CFG_S2_TRANS:
+		used_bits->data[1] |=
+			cpu_to_le64(STRTAB_STE_1_EATS | STRTAB_STE_1_SHCFG);
+		used_bits->data[2] |=
+			cpu_to_le64(STRTAB_STE_2_S2VMID | STRTAB_STE_2_VTCR |
+				    STRTAB_STE_2_S2AA64 | STRTAB_STE_2_S2ENDI |
+				    STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2R);
+		used_bits->data[3] |= cpu_to_le64(STRTAB_STE_3_S2TTB_MASK);
+		break;
+
+	default:
+		memset(used_bits, 0xFF, sizeof(*used_bits));
+		WARN_ON(true);
+	}
+}
+
+static bool arm_smmu_write_ste_step(struct arm_smmu_ste *cur,
+				    const struct arm_smmu_ste *target,
+				    const struct arm_smmu_ste *target_used)
+{
+	struct arm_smmu_ste cur_used;
+	struct arm_smmu_ste step;
+
+	arm_smmu_get_ste_used(cur, &cur_used);
+	return arm_smmu_write_entry_step(cur->data, cur_used.data, target->data,
+					 target_used->data, step.data,
+					 cpu_to_le64(STRTAB_STE_0_V),
+					 ARRAY_SIZE(cur->data));
+}
+
+static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
+			       struct arm_smmu_ste *ste,
+			       const struct arm_smmu_ste *target)
+{
+	struct arm_smmu_ste target_used;
+	int i;
+
+	arm_smmu_get_ste_used(target, &target_used);
+	/* Masks in arm_smmu_get_ste_used() are up to date */
+	for (i = 0; i != ARRAY_SIZE(target->data); i++)
+		WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);
+
+	while (true) {
+		if (arm_smmu_write_ste_step(ste, target, &target_used))
+			break;
+		arm_smmu_sync_ste_for_sid(smmu, sid);
+	}
+
+	/* It's likely that we'll want to use the new STE soon */
+	if (!(smmu->options & ARM_SMMU_OPT_SKIP_PREFETCH)) {
+		struct arm_smmu_cmdq_ent
+			prefetch_cmd = { .opcode = CMDQ_OP_PREFETCH_CFG,
+					 .prefetch = {
+						 .sid = sid,
+					 } };
+
+		arm_smmu_cmdq_issue_cmd(smmu, &prefetch_cmd);
+	}
+}
+
 static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 				      struct arm_smmu_ste *dst)
 {
-	/*
-	 * This is hideously complicated, but we only really care about
-	 * three cases at the moment:
-	 *
-	 * 1. Invalid (all zero) -> bypass/fault (init)
-	 * 2. Bypass/fault -> translation/bypass (attach)
-	 * 3. Translation/bypass -> bypass/fault (detach)
-	 *
-	 * Given that we can't update the STE atomically and the SMMU
-	 * doesn't read the thing in a defined order, that leaves us
-	 * with the following maintenance requirements:
-	 *
-	 * 1. Update Config, return (init time STEs aren't live)
-	 * 2. Write everything apart from dword 0, sync, write dword 0, sync
-	 * 3. Update Config, sync
-	 */
-	u64 val = le64_to_cpu(dst->data[0]);
-	bool ste_live = false;
+	u64 val;
 	struct arm_smmu_device *smmu = master->smmu;
 	struct arm_smmu_ctx_desc_cfg *cd_table = NULL;
 	struct arm_smmu_s2_cfg *s2_cfg = NULL;
 	struct arm_smmu_domain *smmu_domain = master->domain;
-	struct arm_smmu_cmdq_ent prefetch_cmd = {
-		.opcode		= CMDQ_OP_PREFETCH_CFG,
-		.prefetch	= {
-			.sid	= sid,
-		},
-	};
+	struct arm_smmu_ste target = {};
 
 	if (smmu_domain) {
 		switch (smmu_domain->stage) {
@@ -1293,22 +1466,6 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 		}
 	}
 
-	if (val & STRTAB_STE_0_V) {
-		switch (FIELD_GET(STRTAB_STE_0_CFG, val)) {
-		case STRTAB_STE_0_CFG_BYPASS:
-			break;
-		case STRTAB_STE_0_CFG_S1_TRANS:
-		case STRTAB_STE_0_CFG_S2_TRANS:
-			ste_live = true;
-			break;
-		case STRTAB_STE_0_CFG_ABORT:
-			BUG_ON(!disable_bypass);
-			break;
-		default:
-			BUG(); /* STE corruption */
-		}
-	}
-
 	/* Nuke the existing STE_0 value, as we're going to rewrite it */
 	val = STRTAB_STE_0_V;
 
@@ -1319,16 +1476,11 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 		else
 			val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_BYPASS);
 
-		dst->data[0] = cpu_to_le64(val);
-		dst->data[1] = cpu_to_le64(FIELD_PREP(STRTAB_STE_1_SHCFG,
+		target.data[0] = cpu_to_le64(val);
+		target.data[1] = cpu_to_le64(FIELD_PREP(STRTAB_STE_1_SHCFG,
 						STRTAB_STE_1_SHCFG_INCOMING));
-		dst->data[2] = 0; /* Nuke the VMID */
-		/*
-		 * The SMMU can perform negative caching, so we must sync
-		 * the STE regardless of whether the old value was live.
-		 */
-		if (smmu)
-			arm_smmu_sync_ste_for_sid(smmu, sid);
+		target.data[2] = 0; /* Nuke the VMID */
+		arm_smmu_write_ste(smmu, sid, dst, &target);
 		return;
 	}
 
@@ -1336,8 +1488,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 		u64 strw = smmu->features & ARM_SMMU_FEAT_E2H ?
 			STRTAB_STE_1_STRW_EL2 : STRTAB_STE_1_STRW_NSEL1;
 
-		BUG_ON(ste_live);
-		dst->data[1] = cpu_to_le64(
+		target.data[1] = cpu_to_le64(
 			 FIELD_PREP(STRTAB_STE_1_S1DSS, STRTAB_STE_1_S1DSS_SSID0) |
 			 FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) |
 			 FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) |
@@ -1346,7 +1497,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 
 		if (smmu->features & ARM_SMMU_FEAT_STALLS &&
 		    !master->stall_enabled)
-			dst->data[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
+			target.data[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
 
 		val |= (cd_table->cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) |
 			FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S1_TRANS) |
@@ -1355,8 +1506,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 	}
 
 	if (s2_cfg) {
-		BUG_ON(ste_live);
-		dst->data[2] = cpu_to_le64(
+		target.data[2] = cpu_to_le64(
 			 FIELD_PREP(STRTAB_STE_2_S2VMID, s2_cfg->vmid) |
 			 FIELD_PREP(STRTAB_STE_2_VTCR, s2_cfg->vtcr) |
 #ifdef __BIG_ENDIAN
@@ -1365,23 +1515,17 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 			 STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2AA64 |
 			 STRTAB_STE_2_S2R);
 
-		dst->data[3] = cpu_to_le64(s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK);
+		target.data[3] = cpu_to_le64(s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK);
 
 		val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S2_TRANS);
 	}
 
 	if (master->ats_enabled)
-		dst->data[1] |= cpu_to_le64(FIELD_PREP(STRTAB_STE_1_EATS,
+		target.data[1] |= cpu_to_le64(FIELD_PREP(STRTAB_STE_1_EATS,
 						 STRTAB_STE_1_EATS_TRANS));
 
-	arm_smmu_sync_ste_for_sid(smmu, sid);
-	/* See comment in arm_smmu_write_ctx_desc() */
-	WRITE_ONCE(dst->data[0], cpu_to_le64(val));
-	arm_smmu_sync_ste_for_sid(smmu, sid);
-
-	/* It's likely that we'll want to use the new STE soon */
-	if (!(smmu->options & ARM_SMMU_OPT_SKIP_PREFETCH))
-		arm_smmu_cmdq_issue_cmd(smmu, &prefetch_cmd);
+	target.data[0] = cpu_to_le64(val);
+	arm_smmu_write_ste(smmu, sid, dst, &target);
 }
 
 static void arm_smmu_init_bypass_stes(struct arm_smmu_ste *strtab,
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:46 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:46 -0400
Subject: [PATCH v3 14/19] iommu/arm-smmu-v3: Remove arm_smmu_master->domain
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <14-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Introducing global statics which are of type struct iommu_domain, not
struct arm_smmu_domain makes it difficult to retain
arm_smmu_master->domain, as it can no longer point to an IDENTITY or
BLOCKED domain.

The only place that uses the value is arm_smmu_detach_dev(). Change things
to work like other drivers and call iommu_get_domain_for_dev() to obtain
the current domain.

The master->domain is subtly protecting the domain_head against being
unused, change the domain_head to be INIT'd when the master is not
attached to a domain instead of garbage/zero.

Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 26 ++++++++-------------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  1 -
 2 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e1de2799310961..525048a79e8a90 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2480,19 +2480,20 @@ static void arm_smmu_disable_pasid(struct arm_smmu_master *master)
 
 static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 {
+	struct iommu_domain *domain = iommu_get_domain_for_dev(master->dev);
+	struct arm_smmu_domain *smmu_domain;
 	unsigned long flags;
-	struct arm_smmu_domain *smmu_domain = master->domain;
 
-	if (!smmu_domain)
+	if (!domain)
 		return;
 
+	smmu_domain = to_smmu_domain(domain);
 	arm_smmu_disable_ats(master, smmu_domain);
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_del(&master->domain_head);
+	list_del_init(&master->domain_head);
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
-	master->domain = NULL;
 	master->ats_enabled = false;
 }
 
@@ -2546,8 +2547,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 
 	arm_smmu_detach_dev(master);
 
-	master->domain = smmu_domain;
-
 	/*
 	 * The SMMU does not support enabling ATS with bypass. When the STE is
 	 * in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests and
@@ -2566,10 +2565,8 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	case ARM_SMMU_DOMAIN_S1:
 		if (!master->cd_table.cdtab) {
 			ret = arm_smmu_alloc_cd_tables(master);
-			if (ret) {
-				master->domain = NULL;
+			if (ret)
 				goto out_list_del;
-			}
 		} else {
 			/*
 			 * arm_smmu_write_ctx_desc() relies on the entry being
@@ -2577,17 +2574,13 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 			 */
 			ret = arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
 						      NULL);
-			if (ret) {
-				master->domain = NULL;
+			if (ret)
 				goto out_list_del;
-			}
 		}
 
 		ret = arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, &smmu_domain->cd);
-		if (ret) {
-			master->domain = NULL;
+		if (ret)
 			goto out_list_del;
-		}
 
 		arm_smmu_make_cdtable_ste(&target, master, &master->cd_table);
 		arm_smmu_install_ste_for_dev(master, &target);
@@ -2613,7 +2606,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 
 out_list_del:
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_del(&master->domain_head);
+	list_del_init(&master->domain_head);
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
 out_unlock:
@@ -2817,6 +2810,7 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 	master->dev = dev;
 	master->smmu = smmu;
 	INIT_LIST_HEAD(&master->bonds);
+	INIT_LIST_HEAD(&master->domain_head);
 	dev_iommu_priv_set(dev, master);
 
 	ret = arm_smmu_insert_master(smmu, master);
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 1be0c1151c50c3..21f2f73501019a 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -695,7 +695,6 @@ struct arm_smmu_stream {
 struct arm_smmu_master {
 	struct arm_smmu_device		*smmu;
 	struct device			*dev;
-	struct arm_smmu_domain		*domain;
 	struct list_head		domain_head;
 	struct arm_smmu_stream		*streams;
 	/* Locked by the iommu core using the group mutex */
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:38 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:38 -0400
Subject: [PATCH v3 06/19] iommu/arm-smmu-v3: Move arm_smmu_rmr_install_bypass_ste()
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <6-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Logically arm_smmu_init_strtab_linear() is the function that allocates and
populates the stream table with the initial value of the STEs. After this
function returns the stream table should be fully ready.

arm_smmu_rmr_install_bypass_ste() adjusts the initial stream table to force
any SIDs that the FW says have IOMMU_RESV_DIRECT to use bypass. This
ensures there is no disruption to the identity mapping during boot.

Put arm_smmu_rmr_install_bypass_ste() into arm_smmu_init_strtab_linear(),
it already executes immediately after arm_smmu_init_strtab_linear().

No functional change intended.

Reviewed-by: Michael Shavit <mshavit at google.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 0a4bf1cbe42293..95c78ccaebd439 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -86,6 +86,8 @@ static struct arm_smmu_option_prop arm_smmu_options[] = {
 	{ 0, NULL},
 };
 
+static void arm_smmu_rmr_install_bypass_ste(struct arm_smmu_device *smmu);
+
 static void parse_driver_options(struct arm_smmu_device *smmu)
 {
 	int i = 0;
@@ -3201,6 +3203,9 @@ static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
 	cfg->strtab_base_cfg = reg;
 
 	arm_smmu_init_bypass_stes(strtab, cfg->num_l1_ents);
+
+	/* Check for RMRs and install bypass STEs if any */
+	arm_smmu_rmr_install_bypass_ste(smmu);
 	return 0;
 }
 
@@ -4014,9 +4019,6 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
 	/* Record our private device structure */
 	platform_set_drvdata(pdev, smmu);
 
-	/* Check for RMRs and install bypass STEs if any */
-	arm_smmu_rmr_install_bypass_ste(smmu);
-
 	/* Reset the device */
 	ret = arm_smmu_device_reset(smmu, bypass);
 	if (ret)
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:51 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:51 -0400
Subject: [PATCH v3 19/19] iommu/arm-smmu-v3: Convert to domain_alloc_paging()
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <19-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

Now that the BLOCKED and IDENTITY behaviors are managed with their own
domains change to the domain_alloc_paging() op.

For now SVA remains using the old interface, eventually it will get its
own op that can pass in the device and mm_struct which will let us have a
sane lifetime for the mmu_notifier.

Call arm_smmu_domain_finalise() early if dev is available.

Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 873343109a90bb..f3900a3d52524a 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2169,14 +2169,15 @@ static bool arm_smmu_capable(struct device *dev, enum iommu_cap cap)
 
 static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
 {
-	struct arm_smmu_domain *smmu_domain;
 
 	if (type == IOMMU_DOMAIN_SVA)
 		return arm_smmu_sva_domain_alloc();
+	return NULL;
+}
 
-	if (type != IOMMU_DOMAIN_UNMANAGED &&
-	    type != IOMMU_DOMAIN_DMA)
-		return NULL;
+static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
+{
+	struct arm_smmu_domain *smmu_domain;
 
 	/*
 	 * Allocate the domain and initialise some of its data structures.
@@ -2192,6 +2193,14 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
 	spin_lock_init(&smmu_domain->devices_lock);
 	INIT_LIST_HEAD(&smmu_domain->mmu_notifiers);
 
+	if (dev) {
+		struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+
+		if (arm_smmu_domain_finalise(smmu_domain, master->smmu)) {
+			kfree(smmu_domain);
+			return NULL;
+		}
+	}
 	return &smmu_domain->domain;
 }
 
@@ -3059,6 +3068,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.blocked_domain		= &arm_smmu_blocked_domain,
 	.capable		= arm_smmu_capable,
 	.domain_alloc		= arm_smmu_domain_alloc,
+	.domain_alloc_paging    = arm_smmu_domain_alloc_paging,
 	.probe_device		= arm_smmu_probe_device,
 	.release_device		= arm_smmu_release_device,
 	.device_group		= arm_smmu_device_group,
-- 
2.43.0



From jgg at nvidia.com  Tue Dec  5 11:14:43 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue,  5 Dec 2023 15:14:43 -0400
Subject: [PATCH v3 11/19] iommu/arm-smmu-v3: Do not change the STE twice during arm_smmu_attach_dev()
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <11-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>

This was needed because the STE code required the STE to be in
ABORT/BYPASS inorder to program a cdtable or S2 STE. Now that the STE code
can automatically handle all transitions we can remove this step
from the attach_dev flow.

A few small bugs exist because of this:

1) If the core code does BLOCKED -> UNMANAGED with disable_bypass=false
   then there will be a moment where the STE points at BYPASS. Since
   this can be done by VFIO/IOMMUFD it is a small security race.

2) If the core code does IDENTITY -> DMA then any IOMMU_RESV_DIRECT
   regions will temporarily become BLOCKED. We'd like drivers to
   work in a way that allows IOMMU_RESV_DIRECT to be continuously
   functional during these transitions.

Make arm_smmu_release_device() put the STE back to the correct
ABORT/BYPASS setting. Fix a bug where a IOMMU_RESV_DIRECT was ignored on
this path.

As noted before the reordering of the linked list/STE/CD changes is OK
against concurrent arm_smmu_share_asid() because of the
arm_smmu_asid_lock.

Tested-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
Tested-by: Nicolin Chen <nicolinc at nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc at nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 0c1d70b8f325ed..7b1f7fa27b3df0 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2482,7 +2482,6 @@ static void arm_smmu_disable_pasid(struct arm_smmu_master *master)
 static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 {
 	unsigned long flags;
-	struct arm_smmu_ste target;
 	struct arm_smmu_domain *smmu_domain = master->domain;
 
 	if (!smmu_domain)
@@ -2496,11 +2495,6 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 
 	master->domain = NULL;
 	master->ats_enabled = false;
-	if (disable_bypass)
-		arm_smmu_make_abort_ste(&target);
-	else
-		arm_smmu_make_bypass_ste(&target);
-	arm_smmu_install_ste_for_dev(master, &target);
 	/*
 	 * Clearing the CD entry isn't strictly required to detach the domain
 	 * since the table is uninstalled anyway, but it helps avoid confusion
@@ -2852,9 +2846,18 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 static void arm_smmu_release_device(struct device *dev)
 {
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+	struct arm_smmu_ste target;
 
 	if (WARN_ON(arm_smmu_master_sva_enabled(master)))
 		iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
+
+	/* Put the STE back to what arm_smmu_init_strtab() sets */
+	if (disable_bypass && !dev->iommu->require_direct)
+		arm_smmu_make_abort_ste(&target);
+	else
+		arm_smmu_make_bypass_ste(&target);
+	arm_smmu_install_ste_for_dev(master, &target);
+
 	arm_smmu_detach_dev(master);
 	arm_smmu_disable_pasid(master);
 	arm_smmu_remove_master(master);
-- 
2.43.0



From namhyung at kernel.org  Tue Dec  5 11:17:27 2023
From: namhyung at kernel.org (Namhyung Kim)
Date: Tue, 5 Dec 2023 11:17:27 -0800
Subject: [PATCH v1 1/2] perf metrics: Avoid segv if default metricgroup
 isn't set
In-Reply-To: <CAP-5=fXpsGNVfz+jyu7A=uhrJVQ2xeQ_Forq7CJ4YSjFp-UWnw@mail.gmail.com>
References: <20231204182330.654255-1-irogers@google.com> <bea4ad79-297e-9737-8af1-2286192d26f4@os.amperecomputing.com>
 <CAM9d7ci=Tk845H3x3KMDu-hTdP-u0O6a8D3iAa8EnFLLjOO6OQ@mail.gmail.com>
 <ZW9G8Clxwl6bd0H6@kernel.org> <CAM9d7ciOp_O5N1TDX0HyKavykirByAYrqzcmM-_6ZWjMv-47WQ@mail.gmail.com>
 <ZW9whqUEILWMdcmi@kernel.org> <CAM9d7ciqm2NLt5kxjVdOP2y-KV30_CRsSjHpcQgntvNGWukx9g@mail.gmail.com>
 <CAP-5=fXpsGNVfz+jyu7A=uhrJVQ2xeQ_Forq7CJ4YSjFp-UWnw@mail.gmail.com>
Message-ID: <CAM9d7cgRvyCyNowzx15AakorV7-D4h28NqHAei_tLFFw9D3euA@mail.gmail.com>

On Tue, Dec 5, 2023 at 11:15?AM Ian Rogers <irogers at google.com> wrote:
>
> On Tue, Dec 5, 2023 at 11:11?AM Namhyung Kim <namhyung at kernel.org> wrote:
> >
> > On Tue, Dec 5, 2023 at 10:48?AM Arnaldo Carvalho de Melo
> > <acme at kernel.org> wrote:

> > > "perf list: Fix JSON segfault by setting the used skip_fuplicate_pmus callback"
> > >
> > > The original description was vague, improving it a bit like that helps
> > > when just looking at the output of "git log --oneline".
> >
> > Done and pushed to tmp.perf-tools!
>
> Thanks Namhyung, there was a typo in Arnaldo's commit message
> "s/fuplicate/duplicate/" could you fix?

Oops, fixed now.  Thanks for checking.
Namhyung


From wahrenst at gmx.net  Tue Dec  5 11:18:07 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 5 Dec 2023 20:18:07 +0100
Subject: [PATCH v2 0/5] staging: vc04_services: Drop custom logging
In-Reply-To: <a87efe94-b3fb-a360-dfcd-db2097b89d6f@ideasonboard.com>
References: <20231128201926.489269-1-umang.jain@ideasonboard.com>
 <42cd081f-bee9-49ff-b8f6-17ec58f43058@gmx.net>
 <a87efe94-b3fb-a360-dfcd-db2097b89d6f@ideasonboard.com>
Message-ID: <8d3304d4-743c-4670-ad8d-d31535738664@gmx.net>

Hi Umang,

Am 05.12.23 um 07:39 schrieb Umang Jain:
> Hi Stefan,
>
> On 11/29/23 4:56 AM, Stefan Wahren wrote:
>> Hi Umang,
>>
>> Am 28.11.23 um 21:19 schrieb Umang Jain:
>>> This series also removes the vchiq_log_* macro and makes use of
>>> dev_dbg()
>>> directly.
>> sorry, i didn't had the time to follow the logging discussion, but the
>> following commits:
>>
>> staging: vc04: Convert vchiq_log_error() to use dynamic debug
>> staging: vc04: Convert vchiq_log_warning() to use dynamic debug
>> staging: vc04: Convert(and rename) vchiq_log_info() to use dynamic debug
>>
>> changed the logging behavior. I don't think it's intended to move
>> everything to dev_dbg.
>>
>> I would expected the following mapping:
>> vchiq_log_error -> dev_err
>> vchiq_log_warning -> dev_warn
>
> For this I agree,
>> vchiq_log_info -> dev_info
>
> However, I think vchiq_log_info and vchiq_log_debug should be moved to
> dev_dbg.
>
> Otherwise, I think they'll spew a ton of information to dmesg by default.

generally i agree. Unfortunately we need to double check every log
message, because some of them are unnecessary.

>>>
>>> Patch 1/5 is fix. It prevents passing NULL to one of vchiq_log_error().
>>> The function there in question, does not have any users as of
>>> now. However, it is going to be used by the vc-sm-cma and bcm2835-isp
>>> drivers (posted on list for review [1]). There was discussion on v1,
>>> whether I should drop and add the function later, however, didn't
>>> conclude.
>>>
>>> Patch 2/5 removes vchiq_log_error() macro
>>> Patch 3/5 removes vchiq_log_warning() macro
>>> Patch 4/5 removes vchiq_log_trace() macro
>>> Patch 5/5 removes vchiq_log_debug() macro
>>>
>>> This completes the following TODO item:
>>>
>>> ```
>>> * Cleanup logging mechanism
>>>
>>> The driver should probably be using the standard kernel logging
>>> mechanisms
>>> such as dev_info, dev_dbg, and friends.
>>> ```
>>>
>>> [1]:
>>> https://lore.kernel.org/linux-media/20231109210309.638594-1-umang.jain at ideasonboard.com/
>>>
>>> Changes in v2:
>>> - Separate out one fixup patch from v1 (Patch 1/9)and send separately
>>> - Drop usage of log_type() and log_category() helpers. Directly use
>>> ?? dev_dbg() as suggested by Greg KH.
>>> - Drop __func__ annotation from all logs. Dynamic debug has 'f'
>>> ?? decorator flag which can be used instead of manual __func__
>>> - Reword commit messages.
>>>
>>> Umang Jain (5):
>>> ?? staging: vc04_services: Do not pass NULL to vchiq_log_error()
>>> ?? staging: vc04_services: Drop vchiq_log_error() in favour of dev_dbg
>>> ?? staging: vc04_services: Drop vchiq_log_warning() in favour of
>>> dev_dbg
>>> ?? staging: vc04_services: Drop vchiq_log_trace() in favour of dev_dbg
>>> ?? staging: vc04_services: Drop vchiq_log_debug() in favour of dev_dbg
>>>
>>> ? drivers/staging/vc04_services/interface/TODO? |?? 5 -
>>> ? .../interface/vchiq_arm/vchiq_arm.c?????????? | 176 ++++----
>>> ? .../interface/vchiq_arm/vchiq_connected.c???? |?? 8 +-
>>> ? .../interface/vchiq_arm/vchiq_connected.h???? |?? 4 +-
>>> ? .../interface/vchiq_arm/vchiq_core.c????????? | 402
>>> +++++++++---------
>>> ? .../interface/vchiq_arm/vchiq_core.h????????? |? 38 --
>>> ? .../interface/vchiq_arm/vchiq_dev.c?????????? |? 92 ++--
>>> ? 7 files changed, 315 insertions(+), 410 deletions(-)
>>>
>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From jm at ti.com  Tue Dec  5 11:22:44 2023
From: jm at ti.com (Judith Mendez)
Date: Tue, 5 Dec 2023 13:22:44 -0600
Subject: [PATCH 1/3] arm64: dts: ti: k3-j7200-main: Add Itap Delay Value
 For DDR52 speed mode
In-Reply-To: <20231201082045.790478-2-b-kapoor@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
 <20231201082045.790478-2-b-kapoor@ti.com>
Message-ID: <f3b5cc05-9a68-4319-a7fe-963123ae82c5@ti.com>

Hi Bhavya,

On 12/1/23 2:20 AM, Bhavya Kapoor wrote:
> DDR52 speed mode is enabled for eMMC in J7200 but its Itap Delay Value
> is not present in the device tree. Thus, add Itap Delay Value for eMMC
> High Speed DDR which is DDR52 speed mode for J7200 SoC according to
> datasheet for J7200.
> 
> [+] Refer to : section 7.9.5.16.1 MMCSD0 - eMMC Interface,  in
> 	J7200 datasheet
> - https://www.ti.com/lit/ds/symlink/dra821u-q1.pdf
> 

LGTM

Reviewed-by: Judith Mendez <jm at ti.com>

> Signed-off-by: Bhavya Kapoor <b-kapoor at ti.com>
> ---
>   arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> index 264913f83287..39ce465c8e00 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> @@ -647,6 +647,7 @@ main_sdhci0: mmc at 4f80000 {
>   		ti,otap-del-sel-hs400 = <0x5>;
>   		ti,itap-del-sel-legacy = <0x10>;
>   		ti,itap-del-sel-mmc-hs = <0xa>;
> +		ti,itap-del-sel-ddr52 = <0x3>;
>   		ti,strobe-sel = <0x77>;
>   		ti,clkbuf-sel = <0x7>;
>   		ti,trm-icp = <0x8>;

~ Judith


From jm at ti.com  Tue Dec  5 11:24:38 2023
From: jm at ti.com (Judith Mendez)
Date: Tue, 5 Dec 2023 13:24:38 -0600
Subject: [PATCH 2/3] arm64: dts: ti: k3-j721s2-main: Add Itap Delay Value
 For DDR50 speed mode
In-Reply-To: <20231201082045.790478-3-b-kapoor@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
 <20231201082045.790478-3-b-kapoor@ti.com>
Message-ID: <231e173e-2452-401a-8c11-5b555da59a2b@ti.com>

Hi Bhavya,

On 12/1/23 2:20 AM, Bhavya Kapoor wrote:
> DDR50 speed mode is enabled for MMCSD in J721s2 but its Itap Delay
> Value is not present in the device tree. Thus, add Itap Delay Value
> for MMCSD High Speed DDR which is DDR50 speed mode for J721s2 SoC
> according to datasheet for J721s2.
> 
> [+] Refer to : section 7.10.5.17.2 MMC1/2 - SD/SDIO Interface,  in
> 	J721s2 datasheet
> - https://www.ti.com/lit/ds/symlink/tda4vl-q1.pdf
> 

LGTM

Reviewed-by: Judith Mendez <jm at ti.com>

> Signed-off-by: Bhavya Kapoor <b-kapoor at ti.com>
> ---
>   arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> index b03731b53a26..e1255956288b 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> @@ -766,6 +766,7 @@ main_sdhci1: mmc at 4fb0000 {
>   		ti,itap-del-sel-sd-hs = <0x0>;
>   		ti,itap-del-sel-sdr12 = <0x0>;
>   		ti,itap-del-sel-sdr25 = <0x0>;
> +		ti,itap-del-sel-ddr50 = <0x2>;
>   		ti,clkbuf-sel = <0x7>;
>   		ti,trm-icp = <0x8>;
>   		dma-coherent;

~ Judith


From catalin.marinas at arm.com  Tue Dec  5 11:24:37 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 5 Dec 2023 19:24:37 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231205164318.GG2692119@nvidia.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
Message-ID: <ZW949Tl3VmQfPk0L@arm.com>

On Tue, Dec 05, 2023 at 12:43:18PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 05, 2023 at 04:22:33PM +0000, Catalin Marinas wrote:
> > Yeah, I made this argument in the past. But it's a fair question to ask
> > since the Arm world is different from x86. Just reusing an existing
> > driver in a different context may break its expectations. Does Normal NC
> > access complete by the time a TLBI (for Stage 2) and DSB (DVMsync) is
> > completed? It does reach some point of serialisation with subsequent
> > accesses to the same address but not sure how it is ordered with an
> > access to a different location like the config space used for reset.
> > Maybe it's not a problem at all or it is safe only for PCIe but it would
> > be good to get to the bottom of this.
> 
> IMHO, the answer is you can't know architecturally. The specific
> vfio-platform driver must do an analysis of it's specific SOC and
> determine what exactly is required to order the reset. The primary
> purpose of the vfio-platform drivers is to provide this reset!
> 
> In most cases I would expect some reads from the device to be required
> before the reset.

I can see in the vfio_platform_common.c code that the reset is either
handled by an ACPI _RST method or some custom function in case of DT.
Let's consider the ACPI method for now, I assume the AML code pokes some
device registers but we can't say much about the ordering it expects
without knowing the details. The AML may assume that the ioaddr mapped
as Device-nRnRE (ioremap()) in the kernel has the same attributes
wherever else is mapped in user or guests. Note that currently the
vfio_platform and vfio_pci drivers only allow pgprot_noncached() in
user, so they wouldn't worry about other mismatched aliases.

I think PCIe is slightly better documented but even here we'll have to
rely on the TLBI+DSB to clear any prior writes on different CPUs.

It can be argued that it's the responsibility of whoever grants device
access to know the details. However, it would help if we give some
guidance, any expectations broken if an alias is Normal-NC? It's easier
to start with PCIe first until we get some concrete request for other
types of devices.

> > So, I think it would be easier to get this patch upstream if we limit
> > the change to PCIe devices for now. We may relax this further in the
> > future. Do you actually have a need for non-PCIe devices to support WC
> > in the guest or it's more about the complexity of the logic to detect
> > whether it's actually a PCIe BAR we are mapping into the guest? (I can
> > see some Arm GPU folk asking for this but those devices are not easily
> > virtualisable).
> 
> The complexity is my concern, and the disruption to the ecosystem with
> some of the ideas given.
> 
> If there was a trivial way to convey in the VMA that it is safe then
> sure, no objection from me.

I suggested a new VM_* flag or some way to probe the iomem_resources for
PCIe ranges (if they are described in there, not sure). We can invent
other tree searching for ranges that get registers from the vfio driver,
I don't think it's that difficult.

Question is, do we need to do this for other types of devices or it's
mostly theoretical at this point (what's theoretical goes both ways
really).

A more complex way is to change vfio to allow Normal mappings and KVM
would mimic them. You were actually planning to do this for Cacheable
anyway.

> I would turn it around and ask we find a way to restrict platform
> devices when someone comes with a platform device that wants to use
> secure kvm and has a single well defined HW problem that is solved by
> this work.

We end up with similar search/validation mechanism, so not sure we gain
much.

> What if we change vfio-pci to use pgprot_device() like it already
> really should and say the pgprot_noncached() is enforced as
> DEVICE_nGnRnE and pgprot_device() may be DEVICE_nGnRE or NORMAL_NC?
> Would that be acceptable?

pgprot_device() needs to stay as Device, otherwise you'd get speculative
reads with potential side-effects.

-- 
Catalin


From jm at ti.com  Tue Dec  5 11:25:55 2023
From: jm at ti.com (Judith Mendez)
Date: Tue, 5 Dec 2023 13:25:55 -0600
Subject: [PATCH 3/3] arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value
 For DDR50 speed mode
In-Reply-To: <20231201082045.790478-4-b-kapoor@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
 <20231201082045.790478-4-b-kapoor@ti.com>
Message-ID: <7291a4a5-9e8e-4d9f-9aea-f40e1fccc5f7@ti.com>

Hi Bhavya,

On 12/1/23 2:20 AM, Bhavya Kapoor wrote:
> DDR50 speed mode is enabled for MMCSD in J784s4 but its Itap Delay
> Value is not present in the device tree. Thus, add Itap Delay Value
> for MMCSD High Speed DDR which is DDR50 speed mode for J784s4 SoC
> according to datasheet for J784s4.
> 
> [+] Refer to : section 7.10.5.17.2 MMC1/2 - SD/SDIO Interface, in
> 	J784s4 datasheet
> - https://www.ti.com/lit/ds/symlink/tda4vh-q1.pdf
> 

Also looks good. (:

Reviewed-by: Judith Mendez <jm at ti.com>

> Signed-off-by: Bhavya Kapoor <b-kapoor at ti.com>
> ---
>   arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index d89bcddcfe3d..b9a2358b1459 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -712,6 +712,7 @@ main_sdhci1: mmc at 4fb0000 {
>   		ti,itap-del-sel-sd-hs = <0x0>;
>   		ti,itap-del-sel-sdr12 = <0x0>;
>   		ti,itap-del-sel-sdr25 = <0x0>;
> +		ti,itap-del-sel-ddr50 = <0x2>;
>   		ti,clkbuf-sel = <0x7>;
>   		ti,trm-icp = <0x8>;
>   		dma-coherent;

~ Judith


From wahrenst at gmx.net  Tue Dec  5 11:32:44 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 5 Dec 2023 20:32:44 +0100
Subject: [PATCH v3 1/4] staging: vc04_services: Drop vchiq_log_error() in
 favour of dev_err
In-Reply-To: <20231205084157.73819-2-umang.jain@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-2-umang.jain@ideasonboard.com>
Message-ID: <d6bf7115-dd15-43a0-b45a-41fc778ff160@gmx.net>

Hi Umang,

Am 05.12.23 um 09:41 schrieb Umang Jain:
> Drop vchiq_log_error() macro which wraps dev_dbg(). Introduce the usage
> of dev_err() directly.
sorry, i missed to review the last change. So the change won't be that
trivial.
>
> Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
> ---
>   .../interface/vchiq_arm/vchiq_arm.c           |  50 ++++----
>   .../interface/vchiq_arm/vchiq_connected.c     |   6 +-
>   .../interface/vchiq_arm/vchiq_core.c          | 113 +++++++++---------
>   .../interface/vchiq_arm/vchiq_core.h          |   4 -
>   .../interface/vchiq_arm/vchiq_dev.c           |  45 ++++---
>   5 files changed, 101 insertions(+), 117 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> index 7978fb6dc4fb..b403400edd8e 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -683,8 +683,7 @@ int vchiq_initialise(struct vchiq_instance **instance_out)
>   		usleep_range(500, 600);
>   	}
>   	if (i == VCHIQ_INIT_RETRIES) {
> -		vchiq_log_error(state->dev, VCHIQ_CORE, "%s: videocore not initialized\n",
> -				__func__);
> +		dev_err(state->dev, "core: %s: Videocore not initialized\n", __func__);
>   		ret = -ENOTCONN;
>   		goto failed;
>   	} else if (i > 0) {
> @@ -694,8 +693,7 @@ int vchiq_initialise(struct vchiq_instance **instance_out)
>
>   	instance = kzalloc(sizeof(*instance), GFP_KERNEL);
>   	if (!instance) {
> -		vchiq_log_error(state->dev, VCHIQ_CORE,
> -				"%s: error allocating vchiq instance\n", __func__);
> +		dev_err(state->dev, "core: %s: Cannot allocate vchiq instance\n", __func__);
please drop because kzalloc already report such errors
>   		ret = -ENOMEM;
>   		goto failed;
>   	}
> @@ -967,8 +965,7 @@ vchiq_blocking_bulk_transfer(struct vchiq_instance *instance, unsigned int handl
>   	} else {
>   		waiter = kzalloc(sizeof(*waiter), GFP_KERNEL);
>   		if (!waiter) {
> -			vchiq_log_error(service->state->dev, VCHIQ_CORE,
> -					"%s - out of memory", __func__);
> +			dev_err(service->state->dev, "core: %s: - Out of memory\n", __func__);
ditto
>   			return -ENOMEM;
>   		}
>   	}
> @@ -1290,8 +1287,8 @@ vchiq_keepalive_vchiq_callback(struct vchiq_instance *instance,
>   			       struct vchiq_header *header,
>   			       unsigned int service_user, void *bulk_user)
>   {
> -	vchiq_log_error(instance->state->dev, VCHIQ_SUSPEND,
> -			"%s callback reason %d", __func__, reason);
> +	dev_err(instance->state->dev, "suspend: %s: callback reason %d\n",
> +		__func__, reason);
>   	return 0;
>   }
>
> @@ -1315,22 +1312,20 @@ vchiq_keepalive_thread_func(void *v)
>
>   	ret = vchiq_initialise(&instance);
>   	if (ret) {
> -		vchiq_log_error(state->dev, VCHIQ_SUSPEND,
> -				"%s vchiq_initialise failed %d", __func__, ret);
> +		dev_err(state->dev, "suspend: %s: vchiq_initialise failed %d\n", __func__, ret);
>   		goto exit;
>   	}
>
>   	status = vchiq_connect(instance);
>   	if (status) {
> -		vchiq_log_error(state->dev, VCHIQ_SUSPEND,
> -				"%s vchiq_connect failed %d", __func__, status);
> +		dev_err(state->dev, "suspend: %s: vchiq_connect failed %d\n", __func__, status);
>   		goto shutdown;
>   	}
>
>   	status = vchiq_add_service(instance, &params, &ka_handle);
>   	if (status) {
> -		vchiq_log_error(state->dev, VCHIQ_SUSPEND,
> -				"%s vchiq_open_service failed %d", __func__, status);
> +		dev_err(state->dev, "suspend: %s: vchiq_open_service failed %d\n",
> +			__func__, status);
>   		goto shutdown;
>   	}
>
> @@ -1338,8 +1333,7 @@ vchiq_keepalive_thread_func(void *v)
>   		long rc = 0, uc = 0;
>
>   		if (wait_for_completion_interruptible(&arm_state->ka_evt)) {
> -			vchiq_log_error(state->dev, VCHIQ_SUSPEND,
> -					"%s interrupted", __func__);
> +			dev_err(state->dev, "suspend: %s: interrupted\n", __func__);
I think this isn't an error and we should use dev_dbg here.
>   			flush_signals(current);
>   			continue;
>   		}
> @@ -1359,16 +1353,15 @@ vchiq_keepalive_thread_func(void *v)
>   			atomic_inc(&arm_state->ka_use_ack_count);
>   			status = vchiq_use_service(instance, ka_handle);
>   			if (status) {
> -				vchiq_log_error(state->dev, VCHIQ_SUSPEND,
> -						"%s vchiq_use_service error %d", __func__, status);
> +				dev_err(state->dev, "suspend: %s: vchiq_use_service error %d\n",
> +					__func__, status);
>   			}
>   		}
>   		while (rc--) {
>   			status = vchiq_release_service(instance, ka_handle);
>   			if (status) {
> -				vchiq_log_error(state->dev, VCHIQ_SUSPEND,
> -						"%s vchiq_release_service error %d", __func__,
> -						status);
> +				dev_err(state->dev, "suspend: %s: vchiq_release_service error %d\n",
> +					__func__, status);
>   			}
>   		}
>   	}
> @@ -1403,7 +1396,7 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
>   			 service->client_id);
>   		entity_uc = &service->service_use_count;
>   	} else {
> -		vchiq_log_error(state->dev, VCHIQ_SUSPEND, "%s null service ptr", __func__);
> +		dev_err(state->dev, "suspend: %s: null service ptr\n", __func__);
Instead of dev_err() i would suggest a WARN() here
>   		ret = -EINVAL;
>   		goto out;
>   	}
> @@ -1686,10 +1679,10 @@ vchiq_check_service(struct vchiq_service *service)
>   	read_unlock_bh(&arm_state->susp_res_lock);
>
>   	if (ret) {
> -		vchiq_log_error(service->state->dev, VCHIQ_SUSPEND,
> -				"%s ERROR - %p4cc:%d service count %d, state count %d", __func__,
> -				&service->base.fourcc, service->client_id,
> -				service->service_use_count, arm_state->videocore_use_count);
> +		dev_err(service->state->dev,
> +			"suspend: %s:  %p4cc:%d service count %d, state count %d\n",
> +			__func__, &service->base.fourcc, service->client_id,
> +			service->service_use_count, arm_state->videocore_use_count);
>   		vchiq_dump_service_use_state(service->state);
>   	}
>   out:
> @@ -1722,9 +1715,8 @@ void vchiq_platform_conn_state_changed(struct vchiq_state *state,
>   					      (void *)state,
>   					      threadname);
>   	if (IS_ERR(arm_state->ka_thread)) {
> -		vchiq_log_error(state->dev, VCHIQ_SUSPEND,
> -				"vchiq: FATAL: couldn't create thread %s",
> -				threadname);
> +		dev_err(state->dev, "suspend: Couldn't create thread %s\n",
> +			threadname);
>   	} else {
>   		wake_up_process(arm_state->ka_thread);
>   	}
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
> index 21f9fa1a1713..3cad13f09e37 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
> @@ -39,9 +39,9 @@ void vchiq_add_connected_callback(struct vchiq_device *device, void (*callback)(
>   		callback();
>   	} else {
>   		if (g_num_deferred_callbacks >= MAX_CALLBACKS) {
> -			vchiq_log_error(&device->dev, VCHIQ_CORE,
> -					"There already %d callback registered - please increase MAX_CALLBACKS",
> -					g_num_deferred_callbacks);
> +			dev_err(&device->dev,
> +				"core: There already %d callback registered - please increase MAX_CALLBACKS\n",
> +				g_num_deferred_callbacks);
>   		} else {
>   			g_deferred_callback[g_num_deferred_callbacks] =
>   				callback;
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> index e0022acb4c58..63f412815a32 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> @@ -741,10 +741,10 @@ process_free_data_message(struct vchiq_state *state, u32 *service_found,
>   		 */
>   		complete(&quota->quota_event);
>   	} else if (count == 0) {
> -		vchiq_log_error(state->dev, VCHIQ_CORE,
> -				"service %d message_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)",
> -				port, quota->message_use_count, header, msgid, header->msgid,
> -				header->size);
> +		dev_err(state->dev,
> +			"core: service %d message_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)\n",
> +			port, quota->message_use_count, header, msgid,
> +			header->msgid, header->size);
>   		WARN(1, "invalid message use count\n");
>   	}
>   	if (!BITSET_IS_SET(service_found, port)) {
> @@ -766,9 +766,9 @@ process_free_data_message(struct vchiq_state *state, u32 *service_found,
>   			vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: pfq:%d %x@%pK - slot_use->%d",
>   					state->id, port, header->size, header, count - 1);
>   		} else {
> -			vchiq_log_error(state->dev, VCHIQ_CORE,
> -					"service %d slot_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)",
> -					port, count, header, msgid, header->msgid, header->size);
> +			dev_err(state->dev,
> +				"core: service %d slot_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)\n",
> +				port, count, header, msgid, header->msgid, header->size);
>   			WARN(1, "bad slot use count\n");
>   		}
>   	}
> @@ -831,9 +831,9 @@ process_free_queue(struct vchiq_state *state, u32 *service_found,
>
>   			pos += calc_stride(header->size);
>   			if (pos > VCHIQ_SLOT_SIZE) {
> -				vchiq_log_error(state->dev, VCHIQ_CORE,
> -						"pfq - pos %x: header %pK, msgid %x, header->msgid %x, header->size %x",
> -						pos, header, msgid, header->msgid, header->size);
> +				dev_err(state->dev,
> +					"core: pfq - pos %x: header %pK, msgid %x, header->msgid %x, header->size %x\n",
> +					pos, header, msgid, header->msgid, header->size);
>   				WARN(1, "invalid slot position\n");
>   			}
>   		}
> @@ -1167,8 +1167,8 @@ queue_message_sync(struct vchiq_state *state, struct vchiq_service *service,
>   		int oldmsgid = header->msgid;
>
>   		if (oldmsgid != VCHIQ_MSGID_PADDING)
> -			vchiq_log_error(state->dev, VCHIQ_CORE, "%d: qms - msgid %x, not PADDING",
> -					state->id, oldmsgid);
> +			dev_err(state->dev, "core: %d: qms - msgid %x, not PADDING\n",
> +				state->id, oldmsgid);
>   	}
>
>   	vchiq_log_debug(state->dev, VCHIQ_SYNC,
> @@ -1616,10 +1616,10 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>   		}
>
>   		if (!service) {
> -			vchiq_log_error(state->dev, VCHIQ_CORE,
> -					"%d: prs %s@%pK (%d->%d) - invalid/closed service %d",
> -					state->id, msg_type_str(type), header, remoteport,
> -					localport, localport);
> +			dev_err(state->dev,
> +				"core: %d: prs %s@%pK (%d->%d) - invalid/closed service %d\n",
> +				state->id, msg_type_str(type), header, remoteport,
> +				localport, localport);
>   			goto skip_message;
>   		}
>   		break;
> @@ -1640,9 +1640,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>
>   	if (((unsigned long)header & VCHIQ_SLOT_MASK) +
>   	    calc_stride(size) > VCHIQ_SLOT_SIZE) {
> -		vchiq_log_error(state->dev, VCHIQ_CORE,
> -				"header %pK (msgid %x) - size %x too big for slot",
> -				header, (unsigned int)msgid, (unsigned int)size);
> +		dev_err(state->dev, "core: header %pK (msgid %x) - size %x too big for slot\n",
> +			header, (unsigned int)msgid, (unsigned int)size);
>   		WARN(1, "oversized for slot\n");
>   	}
>
> @@ -1668,8 +1667,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>   			set_service_state(service, VCHIQ_SRVSTATE_OPEN);
>   			complete(&service->remove_event);
>   		} else {
> -			vchiq_log_error(state->dev, VCHIQ_CORE, "OPENACK received in state %s",
> -					srvstate_names[service->srvstate]);
> +			dev_err(state->dev, "core: OPENACK received in state %s\n",
> +				srvstate_names[service->srvstate]);
>   		}
>   		break;
>   	case VCHIQ_MSG_CLOSE:
> @@ -1740,11 +1739,10 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>   			}
>   			if ((int)(queue->remote_insert -
>   				queue->local_insert) >= 0) {
> -				vchiq_log_error(state->dev, VCHIQ_CORE,
> -						"%d: prs %s@%pK (%d->%d) unexpected (ri=%d,li=%d)",
> -						state->id, msg_type_str(type), header, remoteport,
> -						localport, queue->remote_insert,
> -						queue->local_insert);
> +				dev_err(state->dev,
> +					"core: %d: prs %s@%pK (%d->%d) unexpected (ri=%d,li=%d)\n",
> +					state->id, msg_type_str(type), header, remoteport,
> +					localport, queue->remote_insert, queue->local_insert);
>   				mutex_unlock(&service->bulk_mutex);
>   				break;
>   			}
> @@ -1790,8 +1788,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>   		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs PAUSE@%pK,%x",
>   				state->id, header, size);
>   		if (state->conn_state == VCHIQ_CONNSTATE_PAUSED) {
> -			vchiq_log_error(state->dev, VCHIQ_CORE,
> -					"%d: PAUSE received in state PAUSED", state->id);
> +			dev_err(state->dev, "core: %d: PAUSE received in state PAUSED\n",
> +				state->id);
>   			break;
>   		}
>   		if (state->conn_state != VCHIQ_CONNSTATE_PAUSE_SENT) {
> @@ -1821,8 +1819,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>   		break;
>
>   	default:
> -		vchiq_log_error(state->dev, VCHIQ_CORE, "%d: prs invalid msgid %x@%pK,%x",
> -				state->id, msgid, header, size);
> +		dev_err(state->dev, "core: %d: prs invalid msgid %x@%pK,%x\n",
> +			state->id, msgid, header, size);
>   		WARN(1, "invalid message\n");
>   		break;
>   	}
> @@ -1932,7 +1930,7 @@ handle_poll(struct vchiq_state *state)
>   			 * since the PAUSE should have flushed
>   			 * through outstanding messages.
>   			 */
> -			vchiq_log_error(state->dev, VCHIQ_CORE, "Failed to send RESUME message");
> +			dev_err(state->dev, "core: Failed to send RESUME message\n");
>   		}
>   		break;
>   	default:
> @@ -2032,10 +2030,10 @@ sync_func(void *v)
>   		service = find_service_by_port(state, localport);
>
>   		if (!service) {
> -			vchiq_log_error(state->dev, VCHIQ_SYNC,
> -					"%d: sf %s@%pK (%d->%d) - invalid/closed service %d",
> -					state->id, msg_type_str(type), header,
> -					remoteport, localport, localport);
> +			dev_err(state->dev,
> +				"sync: %d: sf %s@%pK (%d->%d) - invalid/closed service %d\n",
> +				state->id, msg_type_str(type), header, remoteport,
> +				localport, localport);
>   			release_message_sync(state, header);
>   			continue;
>   		}
> @@ -2077,15 +2075,15 @@ sync_func(void *v)
>   			    (service->srvstate == VCHIQ_SRVSTATE_OPENSYNC)) {
>   				if (make_service_callback(service, VCHIQ_MESSAGE_AVAILABLE, header,
>   							  NULL) == -EAGAIN)
> -					vchiq_log_error(state->dev, VCHIQ_SYNC,
> -							"synchronous callback to service %d returns -EAGAIN",
> -							localport);
> +					dev_err(state->dev,
> +						"sync: error: synchronous callback to service %d returns -EAGAIN\n",
> +						localport);
>   			}
>   			break;
>
>   		default:
> -			vchiq_log_error(state->dev, VCHIQ_SYNC, "%d: sf unexpected msgid %x@%pK,%x",
> -					state->id, msgid, header, size);
> +			dev_err(state->dev, "sync: error: %d: sf unexpected msgid %x@%pK,%x\n",
> +				state->id, msgid, header, size);
>   			release_message_sync(state, header);
>   			break;
>   		}
> @@ -2118,8 +2116,8 @@ vchiq_init_slots(struct device *dev, void *mem_base, int mem_size)
>   	num_slots -= first_data_slot;
>
>   	if (num_slots < 4) {
> -		vchiq_log_error(dev, VCHIQ_CORE, "%s - insufficient memory %x bytes",
> -				__func__, mem_size);
> +		dev_err(dev, "core: %s: Insufficient memory %x bytes\n",
> +			__func__, mem_size);
>   		return NULL;
>   	}
>
> @@ -2500,11 +2498,10 @@ vchiq_open_service_internal(struct vchiq_service *service, int client_id)
>   	} else if ((service->srvstate != VCHIQ_SRVSTATE_OPEN) &&
>   		   (service->srvstate != VCHIQ_SRVSTATE_OPENSYNC)) {
>   		if (service->srvstate != VCHIQ_SRVSTATE_CLOSEWAIT)
> -			vchiq_log_error(service->state->dev, VCHIQ_CORE,
> -					"%d: osi - srvstate = %s (ref %u)",
> -					service->state->id,
> -					srvstate_names[service->srvstate],
> -					kref_read(&service->ref_count));
> +			dev_err(service->state->dev,
> +				"core: %d: osi - srvstate = %s (ref %u)\n",
> +				service->state->id, srvstate_names[service->srvstate],
> +				kref_read(&service->ref_count));
>   		status = -EINVAL;
>   		VCHIQ_SERVICE_STATS_INC(service, error_count);
>   		vchiq_release_service_internal(service);
> @@ -2565,9 +2562,9 @@ release_service_messages(struct vchiq_service *service)
>   			}
>   			pos += calc_stride(header->size);
>   			if (pos > VCHIQ_SLOT_SIZE) {
> -				vchiq_log_error(state->dev, VCHIQ_CORE,
> -						"fsi - pos %x: header %pK, msgid %x, header->msgid %x, header->size %x",
> -						pos, header, msgid, header->msgid, header->size);
> +				dev_err(state->dev,
> +					"core: fsi - pos %x: header %pK, msgid %x, header->msgid %x, header->size %x\n",
> +					pos, header, msgid, header->msgid, header->size);
>   				WARN(1, "invalid slot position\n");
>   			}
>   		}
> @@ -2621,8 +2618,8 @@ close_service_complete(struct vchiq_service *service, int failstate)
>   	case VCHIQ_SRVSTATE_LISTENING:
>   		break;
>   	default:
> -		vchiq_log_error(service->state->dev, VCHIQ_CORE, "%s(%x) called in state %s",
> -				__func__, service->handle, srvstate_names[service->srvstate]);
> +		dev_err(service->state->dev, "core: (%x) called in state %s\n",
> +			service->handle, srvstate_names[service->srvstate]);
>   		WARN(1, "%s in unexpected state\n", __func__);
>   		return -EINVAL;
>   	}
> @@ -2677,8 +2674,8 @@ vchiq_close_service_internal(struct vchiq_service *service, int close_recvd)
>   	case VCHIQ_SRVSTATE_LISTENING:
>   	case VCHIQ_SRVSTATE_CLOSEWAIT:
>   		if (close_recvd) {
> -			vchiq_log_error(state->dev, VCHIQ_CORE, "%s(1) called in state %s",
> -					__func__, srvstate_names[service->srvstate]);
> +			dev_err(state->dev, "core: (1) called in state %s\n",
> +				srvstate_names[service->srvstate]);
>   		} else if (is_server) {
>   			if (service->srvstate == VCHIQ_SRVSTATE_LISTENING) {
>   				status = -EINVAL;
> @@ -2765,8 +2762,8 @@ vchiq_close_service_internal(struct vchiq_service *service, int close_recvd)
>   		break;
>
>   	default:
> -		vchiq_log_error(state->dev, VCHIQ_CORE, "%s(%d) called in state %s", __func__,
> -				close_recvd, srvstate_names[service->srvstate]);
> +		dev_err(state->dev, "core: (%d) called in state %s\n",
> +			close_recvd, srvstate_names[service->srvstate]);
>   		break;
>   	}
>
> @@ -2805,8 +2802,8 @@ vchiq_free_service_internal(struct vchiq_service *service)
>   	case VCHIQ_SRVSTATE_CLOSEWAIT:
>   		break;
>   	default:
> -		vchiq_log_error(state->dev, VCHIQ_CORE, "%d: fsi - (%d) in state %s", state->id,
> -				service->localport, srvstate_names[service->srvstate]);
> +		dev_err(state->dev, "core: %d: fsi - (%d) in state %s\n",
> +			state->id, service->localport, srvstate_names[service->srvstate]);
>   		return;
>   	}
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
> index 564b5c707267..d7dcd17e4bff 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
> @@ -53,10 +53,6 @@ static inline const char *log_category_str(enum vchiq_log_category c)
>   	return strings[c];
>   };
>
> -#ifndef vchiq_log_error
> -#define vchiq_log_error(dev, cat, fmt, ...) \
> -	do { dev_dbg(dev, "%s error: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
> -#endif
>   #ifndef vchiq_log_warning
>   #define vchiq_log_warning(dev, cat, fmt, ...) \
>   	do { dev_dbg(dev, "%s warning: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
> index 307a2d76cbb7..ba287cb4c87b 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
> @@ -271,9 +271,9 @@ static int vchiq_ioc_dequeue_message(struct vchiq_instance *instance,
>   			ret = -EFAULT;
>   		}
>   	} else {
> -		vchiq_log_error(service->state->dev, VCHIQ_ARM,
> -				"header %pK: bufsize %x < size %x",
> -				header, args->bufsize, header->size);
> +		dev_err(service->state->dev,
> +			"arm: header %pK: bufsize %x < size %x\n",
> +			header, args->bufsize, header->size);
>   		WARN(1, "invalid size\n");
>   		ret = -EMSGSIZE;
>   	}
> @@ -318,8 +318,8 @@ static int vchiq_irq_queue_bulk_tx_rx(struct vchiq_instance *instance,
>   		}
>   		mutex_unlock(&instance->bulk_waiter_list_mutex);
>   		if (!waiter) {
> -			vchiq_log_error(service->state->dev, VCHIQ_ARM,
> -					"no bulk_waiter found for pid %d", current->pid);
> +			dev_err(service->state->dev,
> +				"arm: no bulk_waiter found for pid %d\n", current->pid);
>   			ret = -ESRCH;
>   			goto out;
>   		}
> @@ -501,10 +501,10 @@ static int vchiq_ioc_await_completion(struct vchiq_instance *instance,
>   			msglen = header->size + sizeof(struct vchiq_header);
>   			/* This must be a VCHIQ-style service */
>   			if (args->msgbufsize < msglen) {
> -				vchiq_log_error(service->state->dev, VCHIQ_ARM,
> -						"header %pK: msgbufsize %x < msglen %x",
> -						header, args->msgbufsize, msglen);
> -						WARN(1, "invalid message size\n");
> +				dev_err(service->state->dev,
> +					"arm: header %pK: msgbufsize %x < msglen %x\n",
> +					header, args->msgbufsize, msglen);
> +				WARN(1, "invalid message size\n");
>   				if (ret == 0)
>   					ret = -EMSGSIZE;
>   				break;
> @@ -618,9 +618,9 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>   		}
>   		rc = mutex_lock_killable(&instance->state->mutex);
>   		if (rc) {
> -			vchiq_log_error(instance->state->dev, VCHIQ_ARM,
> -					"vchiq: connect: could not lock mutex for state %d: %d",
> -					instance->state->id, rc);
> +			dev_err(instance->state->dev,
> +				"arm: vchiq: connect: could not lock mutex for state %d: %d\n",
> +				instance->state->id, rc);
I think this should be dev_dbg
>   			ret = -EINTR;
>   			break;
>   		}
> @@ -630,8 +630,8 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>   		if (!status)
>   			instance->connected = 1;
>   		else
> -			vchiq_log_error(instance->state->dev, VCHIQ_ARM,
> -					"vchiq: could not connect: %d", status);
> +			dev_err(instance->state->dev,
> +				"arm: vchiq: could not connect: %d\n", status);
>   		break;
>
>   	case VCHIQ_IOC_CREATE_SERVICE: {
> @@ -700,13 +700,13 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>   				vchiq_use_service_internal(service) :
>   				vchiq_release_service_internal(service);
>   			if (ret) {
> -				vchiq_log_error(instance->state->dev, VCHIQ_SUSPEND,
> -						"%s: cmd %s returned error %ld for service %p4cc:%03d",
> -						__func__, (cmd == VCHIQ_IOC_USE_SERVICE) ?
> -						"VCHIQ_IOC_USE_SERVICE" :
> -						"VCHIQ_IOC_RELEASE_SERVICE",
> -						ret, &service->base.fourcc,
> -						service->client_id);
> +				dev_err(instance->state->dev,
> +					"suspend: cmd %s returned error %ld for service %p4cc:%03d\n",
> +					(cmd == VCHIQ_IOC_USE_SERVICE) ?
> +					"VCHIQ_IOC_USE_SERVICE" :
> +					"VCHIQ_IOC_RELEASE_SERVICE",
> +					ret, &service->base.fourcc,
> +					service->client_id);
>   			}
>   		} else {
>   			ret = -EINVAL;
> @@ -1173,8 +1173,7 @@ static int vchiq_open(struct inode *inode, struct file *file)
>   	vchiq_log_debug(state->dev, VCHIQ_ARM, "vchiq_open");
>
>   	if (!state) {
> -		vchiq_log_error(state->dev, VCHIQ_ARM,
> -				"vchiq has no connection to VideoCore");
> +		dev_err(state->dev, "arm: vchiq has no connection to VideoCore\n");
>   		return -ENOTCONN;
>   	}
>



From catalin.marinas at arm.com  Tue Dec  5 11:34:45 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 5 Dec 2023 19:34:45 +0000
Subject: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64
In-Reply-To: <20231205175127.GJ2692119@nvidia.com>
References: <cover.1700766072.git.leon@kernel.org>
 <c3ae87aea7660c3d266905c19d10d8de0f9fb779.1700766072.git.leon@kernel.org>
 <ZWB373y5XuZDultf@FVFF77S0Q05N>
 <20231124122352.GB436702@nvidia.com>
 <ZWSOwT2OyMXD1lmo@arm.com>
 <20231127134505.GI436702@nvidia.com>
 <ZW4NAzI_jvwoq8dL@arm.com>
 <20231204182330.GK1493156@nvidia.com>
 <ZW9cF0ALVwgvcQMy@arm.com>
 <20231205175127.GJ2692119@nvidia.com>
Message-ID: <ZW97VdHYH3HYVyd5@arm.com>

On Tue, Dec 05, 2023 at 01:51:27PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 05, 2023 at 05:21:27PM +0000, Catalin Marinas wrote:
> > On Mon, Dec 04, 2023 at 02:23:30PM -0400, Jason Gunthorpe wrote:
> > > On Mon, Dec 04, 2023 at 05:31:47PM +0000, Catalin Marinas wrote:
> > > > Personally I'd optimise the mempcy_toio() arm64 implementation to do
> > > > STPs if the alignment is right (like we do for classic memcpy()).
> > > > There's a slight overhead for alignment checking but I suspect it would
> > > > be lost as long as you can get the write-combining. Not sure whether the
> > > > interspersed reads in memcpy_toio() would somehow prevent the
> > > > write-combining.
> > > 
> > > I understand on these new CPUs anything other than a block of
> > > contiguous STPs is risky to break the WC. I was told we should not
> > > have any loads between them.
> > 
> > Classic memcpy does similar tricks with four LDPs in a row before
> > starting to issue the STPs (though there are new LDPs for the next
> > data in-between). But that was tuned for cacheable memory, not sure
> > if something similar would behave well on Normal-NC memory.
> 
> Can we conclude a direction here?
> 
> 1) I don't want to mess with x86 so we keep a dedicated API
>    Are we agreed to call it __iowrite512_copy() and note its special
>    alignment limitation?

Sounds fine to me.

> 2) You want to #define __iowrite512_copy() to memcpy_toio() on ARM and
>    implement some quad STP optimization for this case?

We can have the generic __iowrite512_copy() do memcpy_toio() and have
the arm64 implement an optimised version.

What I'm not entirely sure of is the DGH (whatever the io_* barrier name
is). I'd put it in the same __iowrite512_copy() function and remove it
from the driver code. Otherwise when ST64B is added, we have an
unnecessary DGH in the driver. If this does not match the other
__iowrite*_copy() semantics, we can come up with another name. But start
with this for now and document the function.

> 3) A future ST64B and the x86 version would be put under
>    __iowrite512_copy()?

Yes, arch-specific override.

> 4) A future ST64B would come with some kind of 'must do 64b copy or
>    oops' to support the future HW that must have this instruction? eg
>    we already see on Intel that HW must use ENQCMD and nothing else.

I don't agree with the oops part. We can't guarantee it on arm64, ST64B
I think is optional in the architecture. If you do need such guarantees,
we'd need the driver to probe for the feature (e.g. arch_has_...()) and
invoke a new macro. You can't have the __iowrite512_copy() that worked
fine suddenly giving an error just because some driver wants a
guaranteed atomic 64 byte write.

-- 
Catalin


From wahrenst at gmx.net  Tue Dec  5 11:37:38 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 5 Dec 2023 20:37:38 +0100
Subject: [PATCH v3 2/4] staging: vc04_services: Drop vchiq_log_warning()
 in favour of dev_warn
In-Reply-To: <20231205084157.73819-3-umang.jain@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-3-umang.jain@ideasonboard.com>
Message-ID: <cd08e69d-a54e-411d-bee9-5c827ed257ba@gmx.net>

Hi Umang,

Am 05.12.23 um 09:41 schrieb Umang Jain:
> Drop vchiq_log_warning() macro which wraps dev_dbg(). Introduce the usage
> of dev_warn() directly.
>
> Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
> ---
>   .../interface/vchiq_arm/vchiq_arm.c           | 30 +++++++++----------
>   .../interface/vchiq_arm/vchiq_core.c          | 30 +++++++++----------
>   .../interface/vchiq_arm/vchiq_core.h          |  4 ---
>   3 files changed, 29 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> index b403400edd8e..56326b59a718 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -687,8 +687,8 @@ int vchiq_initialise(struct vchiq_instance **instance_out)
>   		ret = -ENOTCONN;
>   		goto failed;
>   	} else if (i > 0) {
> -		vchiq_log_warning(state->dev, VCHIQ_CORE,
> -				  "%s: videocore initialized after %d retries\n", __func__, i);
> +		dev_warn(state->dev, "core: %s: videocore initialized after %d retries\n",
> +			 __func__, i);
>   	}
>
>   	instance = kzalloc(sizeof(*instance), GFP_KERNEL);
> @@ -1644,20 +1644,19 @@ vchiq_dump_service_use_state(struct vchiq_state *state)
>   	read_unlock_bh(&arm_state->susp_res_lock);
>
>   	if (only_nonzero)
> -		vchiq_log_warning(state->dev, VCHIQ_SUSPEND,
> -				  "Too many active services (%d). Only dumping up to first %d services with non-zero use-count",
> -				  active_services, found);
> +		dev_warn(state->dev,
> +			 "suspend: Too many active services (%d). Only dumping up to first %d services with non-zero use-count\n",
> +			 active_services, found);
>
>   	for (i = 0; i < found; i++) {
> -		vchiq_log_warning(state->dev, VCHIQ_SUSPEND,
> -				  "%p4cc:%d service count %d %s",
> -				  &service_data[i].fourcc,
> -				  service_data[i].clientid, service_data[i].use_count,
> -				  service_data[i].use_count ? nz : "");
> +		dev_warn(state->dev,
> +			 "suspend: %p4cc:%d service count %d %s\n",
> +			 &service_data[i].fourcc,
> +			 service_data[i].clientid, service_data[i].use_count,
> +			 service_data[i].use_count ? nz : "");
>   	}
> -	vchiq_log_warning(state->dev, VCHIQ_SUSPEND, "VCHIQ use count %d", peer_count);
> -	vchiq_log_warning(state->dev, VCHIQ_SUSPEND, "Overall vchiq instance use count %d",
> -			  vc_use_count);
> +	dev_warn(state->dev, "suspend: VCHIQ use count %d\n", peer_count);
> +	dev_warn(state->dev, "suspend: Overall vchiq instance use count %d\n", vc_use_count);
>
>   	kfree(service_data);
>   }
> @@ -1771,8 +1770,7 @@ static int vchiq_probe(struct platform_device *pdev)
>   	 */
>   	err = vchiq_register_chrdev(&pdev->dev);
>   	if (err) {
> -		vchiq_log_warning(&pdev->dev, VCHIQ_ARM,
> -				  "Failed to initialize vchiq cdev");
> +		dev_warn(&pdev->dev, "arm: Failed to initialize vchiq cdev\n");
I think a dev_err() would fit better here.
>   		goto error_exit;
>   	}
>
> @@ -1782,7 +1780,7 @@ static int vchiq_probe(struct platform_device *pdev)
>   	return 0;
>
>   failed_platform_init:
> -	vchiq_log_warning(&pdev->dev, VCHIQ_ARM, "could not initialize vchiq platform");
> +	dev_warn(&pdev->dev, "arm: Could not initialize vchiq platform\n");
ditto
>   error_exit:
>   	return err;
>   }
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> index 63f412815a32..2fd793954001 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> @@ -465,9 +465,9 @@ make_service_callback(struct vchiq_service *service, enum vchiq_reason reason,
>   	status = service->base.callback(service->instance, reason, header, service->handle,
>   					bulk_userdata);
>   	if (status && (status != -EAGAIN)) {
> -		vchiq_log_warning(service->state->dev, VCHIQ_CORE,
> -				  "%d: ignoring ERROR from callback to service %x",
> -				  service->state->id, service->handle);
> +		dev_warn(service->state->dev,
> +			 "core: %d: ignoring ERROR from callback to service %x\n",
> +			 service->state->id, service->handle);
>   		status = 0;
>   	}
>
> @@ -1609,10 +1609,10 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>   				vchiq_service_put(service);
>   			service = get_connected_service(state, remoteport);
>   			if (service)
> -				vchiq_log_warning(state->dev, VCHIQ_CORE,
> -						  "%d: prs %s@%pK (%d->%d) - found connected service %d",
> -						  state->id, msg_type_str(type), header,
> -						  remoteport, localport, service->localport);
> +				dev_warn(state->dev,
> +					 "core: %d: prs %s@%pK (%d->%d) - found connected service %d\n",
> +					 state->id, msg_type_str(type), header,
> +					 remoteport, localport, service->localport);
>   		}
>
>   		if (!service) {
> @@ -2903,10 +2903,10 @@ vchiq_close_service(struct vchiq_instance *instance, unsigned int handle)
>   		    (service->srvstate == VCHIQ_SRVSTATE_OPEN))
>   			break;
>
> -		vchiq_log_warning(service->state->dev, VCHIQ_CORE,
> -				  "%d: close_service:%d - waiting in state %s",
> -				  service->state->id, service->localport,
> -				  srvstate_names[service->srvstate]);
> +		dev_warn(service->state->dev,
> +			 "core: %d: close_service:%d - waiting in state %s\n",
> +			 service->state->id, service->localport,
> +			 srvstate_names[service->srvstate]);
>   	}
>
>   	if (!status &&
> @@ -2964,10 +2964,10 @@ vchiq_remove_service(struct vchiq_instance *instance, unsigned int handle)
>   		    (service->srvstate == VCHIQ_SRVSTATE_OPEN))
>   			break;
>
> -		vchiq_log_warning(service->state->dev, VCHIQ_CORE,
> -				  "%d: remove_service:%d - waiting in state %s",
> -				  service->state->id, service->localport,
> -				  srvstate_names[service->srvstate]);
> +		dev_warn(service->state->dev,
> +			 "core: %d: remove_service:%d - waiting in state %s\n",
> +			 service->state->id, service->localport,
> +			 srvstate_names[service->srvstate]);
>   	}
>
>   	if (!status && (service->srvstate != VCHIQ_SRVSTATE_FREE))
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
> index d7dcd17e4bff..bc980a001711 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
> @@ -53,10 +53,6 @@ static inline const char *log_category_str(enum vchiq_log_category c)
>   	return strings[c];
>   };
>
> -#ifndef vchiq_log_warning
> -#define vchiq_log_warning(dev, cat, fmt, ...) \
> -	do { dev_dbg(dev, "%s warning: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)
> -#endif
>   #ifndef vchiq_log_debug
>   #define vchiq_log_debug(dev, cat, fmt, ...) \
>   	do { dev_dbg(dev, "%s debug: " fmt, log_category_str(cat), ##__VA_ARGS__); } while (0)



From sdf at google.com  Tue Dec  5 11:39:28 2023
From: sdf at google.com (Stanislav Fomichev)
Date: Tue, 5 Dec 2023 11:39:28 -0800
Subject: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC
In-Reply-To: <656f66023f7bd_3dd6422942a@willemb.c.googlers.com.notmuch>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com> <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
 <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
 <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com>
 <CAKH8qBuXL8bOYtfKKPS8y=KJqouDptyciCjr0wNKVHtNj6BmqA@mail.gmail.com> <656f66023f7bd_3dd6422942a@willemb.c.googlers.com.notmuch>
Message-ID: <ZW98UW033wCy9vI-@google.com>

On 12/05, Willem de Bruijn wrote:
> Stanislav Fomichev wrote:
> > On Tue, Dec 5, 2023 at 7:34?AM Florian Bezdeka
> > <florian.bezdeka at siemens.com> wrote:
> > >
> > > On Tue, 2023-12-05 at 15:25 +0000, Song, Yoong Siang wrote:
> > > > On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote:
> > > > > Jesper Dangaard Brouer wrote:
> > > > > >
> > > > > >
> > > > > > On 12/3/23 17:51, Song Yoong Siang wrote:
> > > > > > > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > > > > > > copy via XDP Tx metadata framework.
> > > > > > >
> > > > > > > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > > > > > > ---
> > > > > > >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> > > > > >
> > > > > > As requested before, I think we need to see another driver implementing
> > > > > > this.
> > > > > >
> > > > > > I propose driver igc and chip i225.
> > > >
> > > > Sure. I will include igc patches in next version.
> > > >
> > > > > >
> > > > > > The interesting thing for me is to see how the LaunchTime max 1 second
> > > > > > into the future[1] is handled code wise. One suggestion is to add a
> > > > > > section to Documentation/networking/xsk-tx-metadata.rst per driver that
> > > > > > mentions/documents these different hardware limitations.  It is natural
> > > > > > that different types of hardware have limitations.  This is a close-to
> > > > > > hardware-level abstraction/API, and IMHO as long as we document the
> > > > > > limitations we can expose this API without too many limitations for more
> > > > > > capable hardware.
> > > >
> > > > Sure. I will try to add hardware limitations in documentation.
> > > >
> > > > >
> > > > > I would assume that the kfunc will fail when a value is passed that
> > > > > cannot be programmed.
> > > > >
> > > >
> > > > In current design, the xsk_tx_metadata_request() dint got return value.
> > > > So user won't know if their request is fail.
> > > > It is complex to inform user which request is failing.
> > > > Therefore, IMHO, it is good that we let driver handle the error silently.
> > > >
> > >
> > > If the programmed value is invalid, the packet will be "dropped" / will
> > > never make it to the wire, right?
> 
> Programmable behavior is to either drop or cap to some boundary
> value, such as the farthest programmable time in the future: the
> horizon. In fq:
> 
>                 /* Check if packet timestamp is too far in the future. */
>                 if (fq_packet_beyond_horizon(skb, q, now)) {
>                         if (q->horizon_drop) {
>                                         q->stat_horizon_drops++;
>                                         return qdisc_drop(skb, sch, to_free);
>                         }
>                         q->stat_horizon_caps++;
>                         skb->tstamp = now + q->horizon;
>                 }
>                 fq_skb_cb(skb)->time_to_send = skb->tstamp;
> 
> Drop is the more obviously correct mode.
> 
> Programming with a clock source that the driver does not support will
> then be a persistent failure.
> 
> Preferably, this driver capability can be queried beforehand (rather
> than only through reading error counters afterwards).
> 
> Perhaps it should not be a driver task to convert from possibly
> multiple clock sources to the device native clock. Right now, we do
> use per-device timecounters for this, implemented in the driver.
> 
> As for which clocks are relevant. For PTP, I suppose the device PHC,
> converted to nsec. For pacing offload, TCP uses CLOCK_MONOTONIC.

Do we need to expose some generic netdev netlink apis to query/adjust
nic clock sources (or maybe there is something existing already)?
Then the userspace can be responsible for syncing/converting the
timestamps to the internal nic clocks. +1 to trying to avoid doing
this in the drivers.

> > > That is clearly a situation that the user should be informed about. For
> > > RT systems this normally means that something is really wrong regarding
> > > timing / cycle overflow. Such systems have to react on that situation.
> > 
> > In general, af_xdp is a bit lacking in this 'notify the user that they
> > somehow messed up' area :-(
> > For example, pushing a tx descriptor with a wrong addr/len in zc mode
> > will not give any visible signal back (besides driver potentially
> > spilling something into dmesg as it was in the mlx case).
> > We can probably start with having some counters for these events?
> 
> This is because the AF_XDP completion queue descriptor format is only
> a u64 address?

Yeah. XDP_COPY mode has the descriptor validation which is exported via
recvmsg errno, but zerocopy path seems to be too deep in the stack
to report something back. And there is no place, as you mention,
in the completion ring to report the status.

> Could error conditions be reported on tx completion in the metadata,
> using xsk_tx_metadata_complete?

That would be one way to do it, yes. But then the error reporting depends
on the metadata opt-in. Having a separate ring to export the errors,
or having a v2 tx-completions layout with extra 'status' field would also
work.

But this seems like something that should be handled separately? Because
we'd have to teach all existing zc drivers to report those errors back
instead of dropping these descriptors..


From jgg at nvidia.com  Tue Dec  5 11:48:22 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 15:48:22 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZW949Tl3VmQfPk0L@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
Message-ID: <20231205194822.GL2692119@nvidia.com>

On Tue, Dec 05, 2023 at 07:24:37PM +0000, Catalin Marinas wrote:
> On Tue, Dec 05, 2023 at 12:43:18PM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 05, 2023 at 04:22:33PM +0000, Catalin Marinas wrote:
> > > Yeah, I made this argument in the past. But it's a fair question to ask
> > > since the Arm world is different from x86. Just reusing an existing
> > > driver in a different context may break its expectations. Does Normal NC
> > > access complete by the time a TLBI (for Stage 2) and DSB (DVMsync) is
> > > completed? It does reach some point of serialisation with subsequent
> > > accesses to the same address but not sure how it is ordered with an
> > > access to a different location like the config space used for reset.
> > > Maybe it's not a problem at all or it is safe only for PCIe but it would
> > > be good to get to the bottom of this.
> > 
> > IMHO, the answer is you can't know architecturally. The specific
> > vfio-platform driver must do an analysis of it's specific SOC and
> > determine what exactly is required to order the reset. The primary
> > purpose of the vfio-platform drivers is to provide this reset!
> > 
> > In most cases I would expect some reads from the device to be required
> > before the reset.
> 
> I can see in the vfio_platform_common.c code that the reset is either
> handled by an ACPI _RST method or some custom function in case of DT.
> Let's consider the ACPI method for now, I assume the AML code pokes some
> device registers but we can't say much about the ordering it expects
> without knowing the details. The AML may assume that the ioaddr mapped
> as Device-nRnRE (ioremap()) in the kernel has the same attributes
> wherever else is mapped in user or guests. Note that currently the
> vfio_platform and vfio_pci drivers only allow pgprot_noncached() in
> user, so they wouldn't worry about other mismatched aliases.

AML is OS agnostic. It technically shouldn't assume the OS never used
NORMAL_NC to access the device.

By the time the AML is invoked the VMAs are all revoked and all TLBs
are flushed so I think the mismatched alias problem is gone??

> It can be argued that it's the responsibility of whoever grants device
> access to know the details. However, it would help if we give some
> guidance, any expectations broken if an alias is Normal-NC? It's easier
> to start with PCIe first until we get some concrete request for other
> types of devices.

The issue was about NORMAL_NC access prior to the TLBI continuing to
float in the interconnect and not be ordered strictly before the reset
write.

Which, IMHO, is basically arguing that DSB doesn't order these
operations on some specific SOC - which I view with some doubt.

> > The complexity is my concern, and the disruption to the ecosystem with
> > some of the ideas given.
> > 
> > If there was a trivial way to convey in the VMA that it is safe then
> > sure, no objection from me.
> 
> I suggested a new VM_* flag or some way to probe the iomem_resources for
> PCIe ranges (if they are described in there, not sure). We can invent
> other tree searching for ranges that get registers from the vfio driver,
> I don't think it's that difficult.

I do not like iomem_resource probing on principle :(

A VM_ flag would be fine, but seems wasteful.

> A more complex way is to change vfio to allow Normal mappings and KVM
> would mimic them. You were actually planning to do this for Cacheable
> anyway.

This needs qemu changes, so I very much don't like it.

Cachable is always cachable, it is different thing.
 
> > I would turn it around and ask we find a way to restrict platform
> > devices when someone comes with a platform device that wants to use
> > secure kvm and has a single well defined HW problem that is solved by
> > this work.
> 
> We end up with similar search/validation mechanism, so not sure we gain
> much.

We gain by not doing it, ever. I'm expecting nobody will ever bring it
up.

The vfio-platform drivers all look to be rather old to me, and the
manifestation is, at worst, that a hostile VM that didn't crash the
machine before does crash it now.

I have serious doubts anyone will run into an issue.

> > What if we change vfio-pci to use pgprot_device() like it already
> > really should and say the pgprot_noncached() is enforced as
> > DEVICE_nGnRnE and pgprot_device() may be DEVICE_nGnRE or NORMAL_NC?
> > Would that be acceptable?
> 
> pgprot_device() needs to stay as Device, otherwise you'd get speculative
> reads with potential side-effects.

I do not mean to change pgprot_device() I mean to detect the
difference via pgprot_device() vs pgprot_noncached(). They put a
different value in the PTE that we can sense. It is very hacky.

Jason


From peter.griffin at linaro.org  Tue Dec  5 11:51:00 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Tue, 5 Dec 2023 19:51:00 +0000
Subject: [PATCH v5 13/20] pinctrl: samsung: Add filter selection support
 for alive banks
In-Reply-To: <ZWpybAkHVYGzWKL0@google.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-14-peter.griffin@linaro.org> <ZWpybAkHVYGzWKL0@google.com>
Message-ID: <CADrjBPpOOtFzkBupXHxKHH2T480_uQ_SmMeU+Z8V7WV6UkzBUg@mail.gmail.com>

Hi Will,

Thanks for testing!

On Fri, 1 Dec 2023 at 23:55, William McVicker <willmcvicker at google.com> wrote:
>
> On 12/01/2023, Peter Griffin wrote:
> > Newer Exynos SoCs have a filter selection register on alive bank pins.
> > This allows the selection of a digital or delay filter for each pin. If
> > the filter selection register is not available then the default filter
> > (digital) is applied.
> >
> > On suspend we apply the analog filter to all pins in the bank (as the
> > digital filter relies on a clock). On resume the digital filter is
> > reapplied to all pins in the bank. The digital filter is working via
> > clock and has an adjustable filter delay register bitfield, whereas
> > the analog filter uses a fixed delay.
> >
> > The filter determines to what extent signal fluctuations received through
> > the pad are considered glitches.
> >
> > The code path can be exercised using
> > echo mem > /sys/power/state
> > And then wake the device using a eint gpio
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
>
> Tested-by: Will McVicker <willmcvicker at google.com>
>
> --
>
> I verified boot and that the pinctrl driver is probing. When I tested
>
>   echo mem > /sys/power/state
>
> I wasn't able to re-wake the device (not sure how to send an eint gpio on
> a phone form factor). I tried with no_console_suspend but that hits a SError
> Interrupt (likely due to a PMU secure register access). Let me know if there's
> anything else I should test out.

Yes you're correct that SError is caused by the PMU secure register access.

Thanks,

Peter.
>
> Thanks,
> Will
>
> > ---
> >  drivers/pinctrl/samsung/pinctrl-exynos.c  | 89 ++++++++++++++++++++++-
> >  drivers/pinctrl/samsung/pinctrl-exynos.h  |  7 ++
> >  drivers/pinctrl/samsung/pinctrl-samsung.c |  2 +
> >  drivers/pinctrl/samsung/pinctrl-samsung.h | 22 ++++++
> >  4 files changed, 119 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > index 6b58ec84e34b..56fc11a1fe2f 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > @@ -269,6 +269,71 @@ struct exynos_eint_gpio_save {
> >       u32 eint_mask;
> >  };
> >
> > +/*
> > + * Set the desired filter (digital or analog delay) to every pin in
> > + * the bank. Note the filter selection bitfield is only found on alive
> > + * banks. The filter determines to what extent signal fluctuations
> > + * received through the pad are considered glitches.
> > + */
> > +static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
> > +                                struct samsung_pin_bank *bank, int filter)
> > +{
> > +     unsigned int flt_reg, flt_con = 0;
> > +     unsigned int val, shift;
> > +     int i;
> > +     int loop_cnt;
> > +
> > +     /*
> > +      * The FLTCON register has the following layout
> > +      *
> > +      * BitfieldName[PinNum][Bit:Bit]
> > +      * FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
> > +      * FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
> > +      * FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
> > +      * FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
> > +      *
> > +      * FLT_EN       0x0 = Disable, 0x1=Enable
> > +      * FLT_SEL      0x0 = Delay filter, 0x1 Digital filter
> > +      * FLT_WIDTH    Filtering width. Valid when FLT_SEL is 0x1
> > +      */
> > +
> > +     flt_con |= EXYNOS9_FLTCON_EN;
> > +
> > +     if (filter)
> > +             flt_con |= EXYNOS9_FLTCON_DIGITAL;
> > +
> > +     flt_reg = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
> > +
> > +     /*
> > +      * If nr_pins > 4, we should set FLTCON0 register fully.
> > +      * (pin0 ~ 3). So loop 4 times in case of FLTCON0.
> > +      */
> > +     if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN)
> > +             loop_cnt = EXYNOS9_FLTCON_NR_PIN;
> > +     else
> > +             loop_cnt = bank->nr_pins;
> > +
> > +     val = readl(d->virt_base + flt_reg);
> > +     for (i = 0; i < loop_cnt; i++) {
> > +             shift = i * EXYNOS9_FLTCON_LEN;
> > +             val &= ~(EXYNOS9_FLTCON_MASK << shift);
> > +             val |= (flt_con << shift);
> > +     }
> > +     writel(val, d->virt_base + flt_reg);
> > +
> > +     /* Loop for FLTCON1 pin 4 ~ 7 */
> > +     if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN) {
> > +             loop_cnt = (bank->nr_pins - EXYNOS9_FLTCON_NR_PIN);
> > +             val = readl(d->virt_base + flt_reg + 0x4);
> > +             for (i = 0; i < loop_cnt; i++) {
> > +                     shift = i * EXYNOS9_FLTCON_LEN;
> > +                     val &= ~(EXYNOS9_FLTCON_MASK << shift);
> > +                     val |= (flt_con << shift);
> > +             }
> > +             writel(val, d->virt_base + flt_reg + 0x4);
> > +     }
> > +}
> > +
> >  /*
> >   * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
> >   * @d: driver data of samsung pinctrl driver.
> > @@ -321,6 +386,10 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
> >                       goto err_domains;
> >               }
> >
> > +             /* Set Delay Analog Filter */
> > +             if (bank->fltcon_type != FLT_DEFAULT)
> > +                     exynos_eint_flt_config(d, bank,
> > +                                            EXYNOS9_FLTCON_DELAY);
> >       }
> >
> >       return 0;
> > @@ -555,6 +624,11 @@ __init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
> >               if (bank->eint_type != EINT_TYPE_WKUP)
> >                       continue;
> >
> > +             /* Set Digital Filter */
> > +             if (bank->fltcon_type != FLT_DEFAULT)
> > +                     exynos_eint_flt_config(d, bank,
> > +                                            EXYNOS9_FLTCON_DIGITAL);
> > +
> >               bank->irq_chip = devm_kmemdup(dev, irq_chip, sizeof(*irq_chip),
> >                                             GFP_KERNEL);
> >               if (!bank->irq_chip) {
> > @@ -658,6 +732,7 @@ static void exynos_pinctrl_suspend_bank(
> >  void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
> >  {
> >       struct samsung_pin_bank *bank = drvdata->pin_banks;
> > +     struct samsung_pinctrl_drv_data *d = bank->drvdata;
> >       struct exynos_irq_chip *irq_chip = NULL;
> >       int i;
> >
> > @@ -665,6 +740,10 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
> >               if (bank->eint_type == EINT_TYPE_GPIO)
> >                       exynos_pinctrl_suspend_bank(drvdata, bank);
> >               else if (bank->eint_type == EINT_TYPE_WKUP) {
> > +                     /* Setting Delay (Analog) Filter */
> > +                     if (bank->fltcon_type != FLT_DEFAULT)
> > +                             exynos_eint_flt_config(d, bank,
> > +                                                    EXYNOS9_FLTCON_DELAY);
> >                       if (!irq_chip) {
> >                               irq_chip = bank->irq_chip;
> >                               irq_chip->set_eint_wakeup_mask(drvdata,
> > @@ -707,11 +786,19 @@ static void exynos_pinctrl_resume_bank(
> >  void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
> >  {
> >       struct samsung_pin_bank *bank = drvdata->pin_banks;
> > +     struct samsung_pinctrl_drv_data *d = bank->drvdata;
> >       int i;
> >
> >       for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
> > -             if (bank->eint_type == EINT_TYPE_GPIO)
> > +             if (bank->eint_type == EINT_TYPE_GPIO) {
> >                       exynos_pinctrl_resume_bank(drvdata, bank);
> > +             } else if (bank->eint_type == EINT_TYPE_WKUP ||
> > +                        bank->eint_type == EINT_TYPE_WKUP_MUX) {
> > +                     /* Set Digital Filter */
> > +                     if (bank->fltcon_type != FLT_DEFAULT)
> > +                             exynos_eint_flt_config(d, bank,
> > +                                                    EXYNOS9_FLTCON_DIGITAL);
> > +             }
> >  }
> >
> >  static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
> > index 3ac52c2cf998..e2799ff1b5e9 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
> > @@ -50,6 +50,13 @@
> >
> >  #define EXYNOS_EINT_MAX_PER_BANK     8
> >  #define EXYNOS_EINT_NR_WKUP_EINT
> > +/* EINT filter configuration */
> > +#define EXYNOS9_FLTCON_EN            BIT(7)
> > +#define EXYNOS9_FLTCON_DIGITAL               BIT(6)
> > +#define EXYNOS9_FLTCON_DELAY         (0 << 6)
> > +#define EXYNOS9_FLTCON_MASK          0xff
> > +#define EXYNOS9_FLTCON_LEN           8
> > +#define EXYNOS9_FLTCON_NR_PIN                4
> >
> >  #define EXYNOS_PIN_BANK_EINTN(pins, reg, id)         \
> >       {                                               \
> > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > index 79babbb39ced..50c360b4753a 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > @@ -1105,6 +1105,8 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
> >               bank->eint_func = bdata->eint_func;
> >               bank->eint_type = bdata->eint_type;
> >               bank->eint_mask = bdata->eint_mask;
> > +             bank->fltcon_type = bdata->fltcon_type;
> > +             bank->fltcon_offset = bdata->fltcon_offset;
> >               bank->eint_offset = bdata->eint_offset;
> >               bank->name = bdata->name;
> >
> > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> > index 9b3db50adef3..5fab3885a7d7 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> > @@ -82,6 +82,20 @@ enum eint_type {
> >       EINT_TYPE_WKUP_MUX,
> >  };
> >
> > +/**
> > + * enum fltcon_type - filter selection
> > + * @FLT_DEFAULT: filter not selectable, default digital filter
> > + * @FLT_SELECT: filter selectable (digital or delay)
> > + *
> > + * Some banks on newer Exynos based SoCs have a selectable filter on alive
> > + * banks of 'analog/delay' or 'digital'. If the filter selection register is
> > + * not available then the default filter is used (digital).
> > + */
> > +enum fltcon_type {
> > +     FLT_DEFAULT,
> > +     FLT_SELECTABLE,
> > +};
> > +
> >  /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
> >  #define PIN_NAME_LENGTH      10
> >
> > @@ -122,6 +136,8 @@ struct samsung_pin_bank_type {
> >   * @eint_type: type of the external interrupt supported by the bank.
> >   * @eint_mask: bit mask of pins which support EINT function.
> >   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> > + * @fltcon_type: whether the filter (delay/digital) is selectable
> > + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
> >   * @name: name to be prefixed for each pin in this pin bank.
> >   */
> >  struct samsung_pin_bank_data {
> > @@ -133,6 +149,8 @@ struct samsung_pin_bank_data {
> >       enum eint_type  eint_type;
> >       u32             eint_mask;
> >       u32             eint_offset;
> > +     enum fltcon_type fltcon_type;
> > +     u32             fltcon_offset;
> >       const char      *name;
> >  };
> >
> > @@ -147,6 +165,8 @@ struct samsung_pin_bank_data {
> >   * @eint_type: type of the external interrupt supported by the bank.
> >   * @eint_mask: bit mask of pins which support EINT function.
> >   * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
> > + * @fltcon_type: whether the filter (delay/digital) is selectable
> > + * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
> >   * @name: name to be prefixed for each pin in this pin bank.
> >   * @id: id of the bank, propagated to the pin range.
> >   * @pin_base: starting pin number of the bank.
> > @@ -170,6 +190,8 @@ struct samsung_pin_bank {
> >       enum eint_type  eint_type;
> >       u32             eint_mask;
> >       u32             eint_offset;
> > +     enum fltcon_type fltcon_type;
> > +     u32             fltcon_offset;
> >       const char      *name;
> >       u32             id;
> >
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >


From jgg at nvidia.com  Tue Dec  5 11:51:30 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 15:51:30 -0400
Subject: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64
In-Reply-To: <ZW97VdHYH3HYVyd5@arm.com>
References: <c3ae87aea7660c3d266905c19d10d8de0f9fb779.1700766072.git.leon@kernel.org>
 <ZWB373y5XuZDultf@FVFF77S0Q05N>
 <20231124122352.GB436702@nvidia.com>
 <ZWSOwT2OyMXD1lmo@arm.com>
 <20231127134505.GI436702@nvidia.com>
 <ZW4NAzI_jvwoq8dL@arm.com>
 <20231204182330.GK1493156@nvidia.com>
 <ZW9cF0ALVwgvcQMy@arm.com>
 <20231205175127.GJ2692119@nvidia.com>
 <ZW97VdHYH3HYVyd5@arm.com>
Message-ID: <20231205195130.GM2692119@nvidia.com>

On Tue, Dec 05, 2023 at 07:34:45PM +0000, Catalin Marinas wrote:

> > 2) You want to #define __iowrite512_copy() to memcpy_toio() on ARM and
> >    implement some quad STP optimization for this case?
> 
> We can have the generic __iowrite512_copy() do memcpy_toio() and have
> the arm64 implement an optimised version.
> 
> What I'm not entirely sure of is the DGH (whatever the io_* barrier name
> is). I'd put it in the same __iowrite512_copy() function and remove it
> from the driver code. Otherwise when ST64B is added, we have an
> unnecessary DGH in the driver. If this does not match the other
> __iowrite*_copy() semantics, we can come up with another name. But start
> with this for now and document the function.

I think the iowrite is only used for WC and the DGH is functionally
harmless for non-WC, so it makes sense.

In this case we should just remove the DGH macro from the generic
architecture code and tell people to use iowrite - since we now
understand that callers basically have to in order to use DGH on new
ARM CPUs.

> > 3) A future ST64B and the x86 version would be put under
> >    __iowrite512_copy()?
> 
> Yes, arch-specific override.
> 
> > 4) A future ST64B would come with some kind of 'must do 64b copy or
> >    oops' to support the future HW that must have this instruction? eg
> >    we already see on Intel that HW must use ENQCMD and nothing else.
> 
> I don't agree with the oops part. We can't guarantee it on arm64, ST64B
> I think is optional in the architecture. If you do need such guarantees,
> we'd need the driver to probe for the feature (e.g. arch_has_...()) and
> invoke a new macro. 

Yes, exactly. The driver must check. The new macro should oops if it
is invoked wrong, the same way enqcmd will oops if invoked wrong on
Intel.

Jason


From willemdebruijn.kernel at gmail.com  Tue Dec  5 12:01:47 2023
From: willemdebruijn.kernel at gmail.com (Willem de Bruijn)
Date: Tue, 05 Dec 2023 15:01:47 -0500
Subject: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC
In-Reply-To: <ZW98UW033wCy9vI-@google.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com>
 <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
 <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
 <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com>
 <CAKH8qBuXL8bOYtfKKPS8y=KJqouDptyciCjr0wNKVHtNj6BmqA@mail.gmail.com>
 <656f66023f7bd_3dd6422942a@willemb.c.googlers.com.notmuch>
 <ZW98UW033wCy9vI-@google.com>
Message-ID: <656f81abaeee7_3f5f95294ef@willemb.c.googlers.com.notmuch>

Stanislav Fomichev wrote:
> On 12/05, Willem de Bruijn wrote:
> > Stanislav Fomichev wrote:
> > > On Tue, Dec 5, 2023 at 7:34?AM Florian Bezdeka
> > > <florian.bezdeka at siemens.com> wrote:
> > > >
> > > > On Tue, 2023-12-05 at 15:25 +0000, Song, Yoong Siang wrote:
> > > > > On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote:
> > > > > > Jesper Dangaard Brouer wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 12/3/23 17:51, Song Yoong Siang wrote:
> > > > > > > > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > > > > > > > copy via XDP Tx metadata framework.
> > > > > > > >
> > > > > > > > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > > > > > > > ---
> > > > > > > >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> > > > > > >
> > > > > > > As requested before, I think we need to see another driver implementing
> > > > > > > this.
> > > > > > >
> > > > > > > I propose driver igc and chip i225.
> > > > >
> > > > > Sure. I will include igc patches in next version.
> > > > >
> > > > > > >
> > > > > > > The interesting thing for me is to see how the LaunchTime max 1 second
> > > > > > > into the future[1] is handled code wise. One suggestion is to add a
> > > > > > > section to Documentation/networking/xsk-tx-metadata.rst per driver that
> > > > > > > mentions/documents these different hardware limitations.  It is natural
> > > > > > > that different types of hardware have limitations.  This is a close-to
> > > > > > > hardware-level abstraction/API, and IMHO as long as we document the
> > > > > > > limitations we can expose this API without too many limitations for more
> > > > > > > capable hardware.
> > > > >
> > > > > Sure. I will try to add hardware limitations in documentation.
> > > > >
> > > > > >
> > > > > > I would assume that the kfunc will fail when a value is passed that
> > > > > > cannot be programmed.
> > > > > >
> > > > >
> > > > > In current design, the xsk_tx_metadata_request() dint got return value.
> > > > > So user won't know if their request is fail.
> > > > > It is complex to inform user which request is failing.
> > > > > Therefore, IMHO, it is good that we let driver handle the error silently.
> > > > >
> > > >
> > > > If the programmed value is invalid, the packet will be "dropped" / will
> > > > never make it to the wire, right?
> > 
> > Programmable behavior is to either drop or cap to some boundary
> > value, such as the farthest programmable time in the future: the
> > horizon. In fq:
> > 
> >                 /* Check if packet timestamp is too far in the future. */
> >                 if (fq_packet_beyond_horizon(skb, q, now)) {
> >                         if (q->horizon_drop) {
> >                                         q->stat_horizon_drops++;
> >                                         return qdisc_drop(skb, sch, to_free);
> >                         }
> >                         q->stat_horizon_caps++;
> >                         skb->tstamp = now + q->horizon;
> >                 }
> >                 fq_skb_cb(skb)->time_to_send = skb->tstamp;
> > 
> > Drop is the more obviously correct mode.
> > 
> > Programming with a clock source that the driver does not support will
> > then be a persistent failure.
> > 
> > Preferably, this driver capability can be queried beforehand (rather
> > than only through reading error counters afterwards).
> > 
> > Perhaps it should not be a driver task to convert from possibly
> > multiple clock sources to the device native clock. Right now, we do
> > use per-device timecounters for this, implemented in the driver.
> > 
> > As for which clocks are relevant. For PTP, I suppose the device PHC,
> > converted to nsec. For pacing offload, TCP uses CLOCK_MONOTONIC.
> 
> Do we need to expose some generic netdev netlink apis to query/adjust
> nic clock sources (or maybe there is something existing already)?
> Then the userspace can be responsible for syncing/converting the
> timestamps to the internal nic clocks. +1 to trying to avoid doing
> this in the drivers.

Perhaps. I'm just a bit hesitant since that is UAPI and this is all
quite hand-wavy still.

Some of the conversion necessarily has to be in the driver. Only the
driver knows the descriptor format, and limitations of that, such as
the bit-width that can be encoded.

If we cannot move anything out of the drivers (quite likely), then
agreed that a netdev/ethtool netlink query approach is helpful.

To be clear: I don't mean that that should be part of this series.
This is not an XSK specific concern.

> > > > That is clearly a situation that the user should be informed about. For
> > > > RT systems this normally means that something is really wrong regarding
> > > > timing / cycle overflow. Such systems have to react on that situation.
> > > 
> > > In general, af_xdp is a bit lacking in this 'notify the user that they
> > > somehow messed up' area :-(
> > > For example, pushing a tx descriptor with a wrong addr/len in zc mode
> > > will not give any visible signal back (besides driver potentially
> > > spilling something into dmesg as it was in the mlx case).
> > > We can probably start with having some counters for these events?
> > 
> > This is because the AF_XDP completion queue descriptor format is only
> > a u64 address?
> 
> Yeah. XDP_COPY mode has the descriptor validation which is exported via
> recvmsg errno, but zerocopy path seems to be too deep in the stack
> to report something back. And there is no place, as you mention,
> in the completion ring to report the status.
> 
> > Could error conditions be reported on tx completion in the metadata,
> > using xsk_tx_metadata_complete?
> 
> That would be one way to do it, yes. But then the error reporting depends
> on the metadata opt-in. Having a separate ring to export the errors,
> or having a v2 tx-completions layout with extra 'status' field would also
> work.
> 
> But this seems like something that should be handled separately? Because
> we'd have to teach all existing zc drivers to report those errors back
> instead of dropping these descriptors..

Agreed on both points :) A v2 tx-completions that supports status
could be useful. But again, this is out of scope of this specific
launch time feature.


From wahrenst at gmx.net  Tue Dec  5 12:05:30 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue,  5 Dec 2023 21:05:30 +0100
Subject: [PATCH V4 2/3] usb: xhci: xhci-plat: Add support for BCM2711
In-Reply-To: <20231205200531.8232-1-wahrenst@gmx.net>
References: <20231205200531.8232-1-wahrenst@gmx.net>
Message-ID: <20231205200531.8232-3-wahrenst@gmx.net>

With the introduction of a BCM2711 specific compatible, this also
needs to be added to the xHCI driver.

Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
 drivers/usb/host/xhci-plat.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index b93161374293..bc5e8f4cdadf 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -129,6 +129,9 @@ static const struct of_device_id usb_xhci_of_match[] = {
 	}, {
 		.compatible = "brcm,xhci-brcm-v2",
 		.data = &xhci_plat_brcm,
+	}, {
+		.compatible = "brcm,bcm2711-xhci",
+		.data = &xhci_plat_brcm,
 	}, {
 		.compatible = "brcm,bcm7445-xhci",
 		.data = &xhci_plat_brcm,
--
2.34.1



From wahrenst at gmx.net  Tue Dec  5 12:05:31 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue,  5 Dec 2023 21:05:31 +0100
Subject: [PATCH V4 3/3] ARM: dts: bcm2711: Add BCM2711 xHCI support
In-Reply-To: <20231205200531.8232-1-wahrenst@gmx.net>
References: <20231205200531.8232-1-wahrenst@gmx.net>
Message-ID: <20231205200531.8232-4-wahrenst@gmx.net>

The BCM2711 SoC also has a mostly generic xHCI. The USB port is
currently only usable on the Compute Module 4 (e.g. via IO board).
Because DWC2 and xHCI share the same PHY, we let the bootloader
enable it on demand.

Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
 arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi |  5 +++++
 arch/arm/boot/dts/broadcom/bcm2711.dtsi     | 14 ++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi b/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi
index 98817a6675b9..d233a191c139 100644
--- a/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include "bcm2835-rpi.dtsi"

+#include <dt-bindings/power/raspberrypi-power.h>
 #include <dt-bindings/reset/raspberrypi,firmware-reset.h>

 / {
@@ -76,3 +77,7 @@ &v3d {
 &vchiq {
 	interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
 };
+
+&xhci {
+	power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2711.dtsi b/arch/arm/boot/dts/broadcom/bcm2711.dtsi
index 4a379a14966d..22c7f1561344 100644
--- a/arch/arm/boot/dts/broadcom/bcm2711.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm2711.dtsi
@@ -604,6 +604,20 @@ genet_mdio: mdio at e14 {
 			};
 		};

+		xhci: usb at 7e9c0000 {
+			compatible = "brcm,bcm2711-xhci", "brcm,xhci-brcm-v2";
+			reg = <0x0 0x7e9c0000 0x100000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+			/* DWC2 and this IP block share the same USB PHY,
+			 * enabling both at the same time results in lockups.
+			 * So keep this node disabled and let the bootloader
+			 * decide which interface should be enabled.
+			 */
+			status = "disabled";
+		};
+
 		v3d: gpu at 7ec00000 {
 			compatible = "brcm,2711-v3d";
 			reg = <0x0 0x7ec00000 0x4000>,
--
2.34.1



From wahrenst at gmx.net  Tue Dec  5 12:05:28 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue,  5 Dec 2023 21:05:28 +0100
Subject: [PATCH V4 0/3] ARM: dts: bcm2711: Add BCM2711 xHCI support
Message-ID: <20231205200531.8232-1-wahrenst@gmx.net>

In contrast to the Raspberry Pi 4, the Compute Module 4 or the IO board
does not have a VL805 USB 3.0 host controller, which is connected via
PCIe. Instead, the Compute Module provides the built-in
xHCI of the BCM2711 SoC.

Changes in V4:
- use "brcm,xhci-brcm-v2" as fallback compatible as suggested by
  Conor & Florian

Changes in V3:
- introduce a new compatible for BCM2711 in order to make the
  power domain dependency SoC specific, which also results in
  a driver change

Changes in V2:
- adjust xHCI compatible as suggested by Justin & Florian
- keep xHCI disabled in order to let the bootloader decide which
  USB block should be enabled, which result in a drop of patch 3

Stefan Wahren (3):
  dt-bindings: usb: xhci: add support for BCM2711
  usb: xhci: xhci-plat: Add support for BCM2711
  ARM: dts: bcm2711: Add BCM2711 xHCI support

 .../devicetree/bindings/usb/generic-xhci.yaml | 25 ++++++++++++++++---
 arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi   |  5 ++++
 arch/arm/boot/dts/broadcom/bcm2711.dtsi       | 14 +++++++++++
 drivers/usb/host/xhci-plat.c                  |  3 +++
 4 files changed, 44 insertions(+), 3 deletions(-)

--
2.34.1



From wahrenst at gmx.net  Tue Dec  5 12:05:29 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue,  5 Dec 2023 21:05:29 +0100
Subject: [PATCH V4 1/3] dt-bindings: usb: xhci: Add support for BCM2711
In-Reply-To: <20231205200531.8232-1-wahrenst@gmx.net>
References: <20231205200531.8232-1-wahrenst@gmx.net>
Message-ID: <20231205200531.8232-2-wahrenst@gmx.net>

The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
but also requires a power domain. So introduce a new compatible
and the specific constraints. Since the key allOf can only occur
once, merge the reference below.

Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
---
 .../devicetree/bindings/usb/generic-xhci.yaml | 25 ++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
index 594ebb3ee432..6ceafa4af292 100644
--- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
@@ -9,9 +9,6 @@ title: USB xHCI Controller
 maintainers:
   - Mathias Nyman <mathias.nyman at intel.com>

-allOf:
-  - $ref: usb-xhci.yaml#
-
 properties:
   compatible:
     oneOf:
@@ -25,6 +22,11 @@ properties:
               - marvell,armada-380-xhci
               - marvell,armada-8k-xhci
           - const: generic-xhci
+      - description: Broadcom SoCs with power domains
+        items:
+          - enum:
+              - brcm,bcm2711-xhci
+          - const: brcm,xhci-brcm-v2
       - description: Broadcom STB SoCs with xHCI
         enum:
           - brcm,xhci-brcm-v2
@@ -49,6 +51,9 @@ properties:
       - const: core
       - const: reg

+  power-domains:
+    maxItems: 1
+
 unevaluatedProperties: false

 required:
@@ -56,6 +61,20 @@ required:
   - reg
   - interrupts

+allOf:
+  - $ref: usb-xhci.yaml#
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: brcm,bcm2711-xhci
+    then:
+      required:
+        - power-domains
+    else:
+      properties:
+        power-domains: false
+
 examples:
   - |
     usb at f0931000 {
--
2.34.1



From nm at ti.com  Tue Dec  5 12:09:00 2023
From: nm at ti.com (Nishanth Menon)
Date: Tue, 5 Dec 2023 14:09:00 -0600
Subject: [PATCH v2] arm64: dts: ti: k3-am65: Add AM652 DTSI file
In-Reply-To: <20231205162358.23904-1-afd@ti.com>
References: <20231205162358.23904-1-afd@ti.com>
Message-ID: <170180691055.3345166.14566348520909354148.b4-ty@ti.com>

Hi Andrew Davis,

On Tue, 05 Dec 2023 10:23:58 -0600, Andrew Davis wrote:
> The AM652 is basically a AM654 but with 2 cores instead of 4. Add
> a DTSI file for AM652 matching AM654 except this core difference.
> 
> This removes the need to remove the extra cores from AM654 manually
> in DT files for boards that use the AM652 variant. Do that for
> the IOT2050 boards here.
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: ti: k3-am65: Add AM652 DTSI file
      commit: fcb97d190c3ca411b37d8dd0b2650fa1378f08d4

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Tue Dec  5 12:11:14 2023
From: nm at ti.com (Nishanth Menon)
Date: Tue, 5 Dec 2023 14:11:14 -0600
Subject: [PATCH RESEND v3 0/9] arm64: dts: ti: Enable CSI cameras for AM62 family
In-Reply-To: <20231201-csi_dts-v3-0-9f06f31080fe@ti.com>
References: <20231201-csi_dts-v3-0-9f06f31080fe@ti.com>
Message-ID: <170180697250.3345832.2524014147786723166.b4-ty@ti.com>

Hi Jai Luthra,

On Fri, 01 Dec 2023 10:39:15 +0530, Jai Luthra wrote:
> This series enables CSI camera support on BeaglePlay, SK-AM62 and
> SK-AM62A, now that the dt-bindings and driver support for CSI-RX related
> IPs is merged in v6.7-rc1.
> 
> Along with the device tree nodes for CSI-RX, add new DT overlays for
> different camera modules like RPiv2 (IMX219) or PCam5C (OV5640).
> 
> [...]

I have applied the following to branch ti-k3-config-next on [1].
Thank you!

[1/9] arm64: defconfig: Enable AM62 CSI2RX
      commit: bd62d91f42d015e173809214badaf750b75be2d1

I have applied the following to branch ti-k3-dts-next on [1]:

[2/9] arm64: dts: ti: Enable CSI-RX on AM62
      commit: 2017f5a610a998cd414c7d9e8b19051014f3126b
[3/9] arm64: dts: ti: Enable CSI-RX on AM62A
      commit: c45e3b54ad1e84f59b3193abc6f451a8cdf7d69f
[4/9] arm64: dts: ti: k3-am625-beagleplay: Add overlays for OV5640
      commit: defa1438c5b34af13fb56c7faefaeec648805530
[5/9] arm64: dts: ti: k3-am62x-sk: Enable camera peripherals
      commit: fed1e53ecf9f0ecf04bd931428287fd1002899ef
[6/9] arm64: dts: ti: k3-am62x: Add overlays for OV5640
      commit: 635ed97151945a7fdf104ef1227d86f0a9e3678e
[7/9] arm64: dts: ti: k3-am62a7-sk: Enable camera peripherals
      commit: 00d7f8f9efdbdf551e92683f5cd274145dce2c4b
[8/9] arm64: dts: ti: k3-am62x: Add overlay for IMX219
      commit: 4111db03dc05c49ded2d9ec21b52c0ca45b59303
[9/9] arm64: dts: ti: Use OF_ALL_DTBS for combined blobs
      commit: b0044823a6607e535fdb083c89f487fbf183b171

with minor $subject and formatting updates to stay in sync with existing
changes.

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From 21cnbao at gmail.com  Tue Dec  5 12:16:26 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Wed, 6 Dec 2023 09:16:26 +1300
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <5216caaf-1fcf-4715-99c3-521e2a1cc756@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com> <20231204102027.57185-5-ryan.roberts@arm.com>
 <CAGsJ_4zG6W_Z-u+3QcRDn4ByoeqUXjMusNS0RotfRMSqo8RCHg@mail.gmail.com>
 <CAGsJ_4zYhJWGx1DnHTiDnP3h1m8_rr6ZT6fXt8pO=jzs9QZS-A@mail.gmail.com> <5216caaf-1fcf-4715-99c3-521e2a1cc756@arm.com>
Message-ID: <CAGsJ_4xHib66MP3-o9jpHGzKecmgb-omBXinazBbrCiwHkonEQ@mail.gmail.com>

On Tue, Dec 5, 2023 at 11:48?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>
> On 05/12/2023 01:24, Barry Song wrote:
> > On Tue, Dec 5, 2023 at 9:15?AM Barry Song <21cnbao at gmail.com> wrote:
> >>
> >> On Mon, Dec 4, 2023 at 6:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
> >>>
> >>> Introduce the logic to allow THP to be configured (through the new sysfs
> >>> interface we just added) to allocate large folios to back anonymous
> >>> memory, which are larger than the base page size but smaller than
> >>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
> >>>
> >>> mTHP continues to be PTE-mapped, but in many cases can still provide
> >>> similar benefits to traditional PMD-sized THP: Page faults are
> >>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
> >>> the configured order), but latency spikes are much less prominent
> >>> because the size of each page isn't as huge as the PMD-sized variant and
> >>> there is less memory to clear in each page fault. The number of per-page
> >>> operations (e.g. ref counting, rmap management, lru list management) are
> >>> also significantly reduced since those ops now become per-folio.
> >>>
> >>> Some architectures also employ TLB compression mechanisms to squeeze
> >>> more entries in when a set of PTEs are virtually and physically
> >>> contiguous and approporiately aligned. In this case, TLB misses will
> >>> occur less often.
> >>>
> >>> The new behaviour is disabled by default, but can be enabled at runtime
> >>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
> >>> (see documentation in previous commit). The long term aim is to change
> >>> the default to include suitable lower orders, but there are some risks
> >>> around internal fragmentation that need to be better understood first.
> >>>
> >>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> >>> ---
> >>>  include/linux/huge_mm.h |   6 ++-
> >>>  mm/memory.c             | 106 ++++++++++++++++++++++++++++++++++++----
> >>>  2 files changed, 101 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> >>> index bd0eadd3befb..91a53b9835a4 100644
> >>> --- a/include/linux/huge_mm.h
> >>> +++ b/include/linux/huge_mm.h
> >>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
> >>>  #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> >>>
> >>>  /*
> >>> - * Mask of all large folio orders supported for anonymous THP.
> >>> + * Mask of all large folio orders supported for anonymous THP; all orders up to
> >>> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
> >>> + * (which is a limitation of the THP implementation).
> >>>   */
> >>> -#define THP_ORDERS_ALL_ANON    BIT(PMD_ORDER)
> >>> +#define THP_ORDERS_ALL_ANON    ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
> >>>
> >>>  /*
> >>>   * Mask of all large folio orders supported for file THP.
> >>> diff --git a/mm/memory.c b/mm/memory.c
> >>> index 3ceeb0f45bf5..bf7e93813018 100644
> >>> --- a/mm/memory.c
> >>> +++ b/mm/memory.c
> >>> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >>>         return ret;
> >>>  }
> >>>
> >>> +static bool pte_range_none(pte_t *pte, int nr_pages)
> >>> +{
> >>> +       int i;
> >>> +
> >>> +       for (i = 0; i < nr_pages; i++) {
> >>> +               if (!pte_none(ptep_get_lockless(pte + i)))
> >>> +                       return false;
> >>> +       }
> >>> +
> >>> +       return true;
> >>> +}
> >>> +
> >>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
> >>> +{
> >>> +       gfp_t gfp;
> >>> +       pte_t *pte;
> >>> +       unsigned long addr;
> >>> +       struct folio *folio;
> >>> +       struct vm_area_struct *vma = vmf->vma;
> >>> +       unsigned long orders;
> >>> +       int order;
> >>> +
> >>> +       /*
> >>> +        * If uffd is active for the vma we need per-page fault fidelity to
> >>> +        * maintain the uffd semantics.
> >>> +        */
> >>> +       if (userfaultfd_armed(vma))
> >>> +               goto fallback;
> >>> +
> >>> +       /*
> >>> +        * Get a list of all the (large) orders below PMD_ORDER that are enabled
> >>> +        * for this vma. Then filter out the orders that can't be allocated over
> >>> +        * the faulting address and still be fully contained in the vma.
> >>> +        */
> >>> +       orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
> >>> +                                         BIT(PMD_ORDER) - 1);
> >>> +       orders = thp_vma_suitable_orders(vma, vmf->address, orders);
> >>> +
> >>> +       if (!orders)
> >>> +               goto fallback;
> >>> +
> >>> +       pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
> >>> +       if (!pte)
> >>> +               return ERR_PTR(-EAGAIN);
> >>> +
> >>> +       order = first_order(orders);
> >>> +       while (orders) {
> >>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> >>> +               vmf->pte = pte + pte_index(addr);
> >>> +               if (pte_range_none(vmf->pte, 1 << order))
> >>> +                       break;
> >>> +               order = next_order(&orders, order);
> >>> +       }
> >>> +
> >>> +       vmf->pte = NULL;
> >>> +       pte_unmap(pte);
> >>> +
> >>> +       gfp = vma_thp_gfp_mask(vma);
> >>> +
> >>> +       while (orders) {
> >>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> >>> +               folio = vma_alloc_folio(gfp, order, vma, addr, true);
> >>> +               if (folio) {
> >>> +                       clear_huge_page(&folio->page, addr, 1 << order);
> >>
> >> Minor.
> >>
> >> Do we have to constantly clear a huge page? Is it possible to let
> >> post_alloc_hook()
> >> finish this job by using __GFP_ZERO/__GFP_ZEROTAGS as
> >> vma_alloc_zeroed_movable_folio() is doing?
>
> I'm currently following the same allocation pattern as is done for PMD-sized
> THP. In earlier versions of this patch I was trying to be smarter and use the
> __GFP_ZERO/__GFP_ZEROTAGS as you suggest, but I was advised to keep it simple
> and follow the existing pattern.
>
> I have a vague recollection __GFP_ZERO is not preferred for large folios because
> of some issue with virtually indexed caches? (Matthew: did I see you mention
> that in some other context?)
>
> That said, I wasn't aware that Android ships with
> CONFIG_INIT_ON_ALLOC_DEFAULT_ON (I thought it was only used as a debug option),
> so I can see the potential for some overhead reduction here.
>
> Options:
>
>  1) leave it as is and accept the duplicated clearing
>  2) Pass __GFP_ZERO and remove clear_huge_page()
>  3) define __GFP_SKIP_ZERO even when kasan is not enabled and pass it down so
>     clear_huge_page() is the only clear
>  4) make clear_huge_page() conditional on !want_init_on_alloc()
>
> I prefer option 4. What do you think?

either 1 and 4 is ok to me if we will finally remove this duplicated
clear_huge_page on top.
4 is even better as it can at least temporarily resolve the problem.

in Android gki_defconfig,
https://android.googlesource.com/kernel/common/+/refs/heads/android14-6.1-lts/arch/arm64/configs/gki_defconfig

Android always has the below,
CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y

here is some explanation for the reason,
https://source.android.com/docs/security/test/memory-safety/zero-initialized-memory

>
> As an aside, I've also noticed that clear_huge_page() should take vmf->address
> so that it clears the faulting page last to keep the cache hot. If we decide on
> an option that keeps clear_huge_page(), I'll also make that change.
>
> Thanks,
> Ryan
>
> >>

Thanks
Barry


From festevam at gmail.com  Tue Dec  5 12:22:08 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 5 Dec 2023 17:22:08 -0300
Subject: [PATCH] serial: imx: Fix clock imbalance
In-Reply-To: <20231205005108.79782-1-marex@denx.de>
References: <20231205005108.79782-1-marex@denx.de>
Message-ID: <CAOMZO5Asw8O_=RCrku65ovGb+MARLRtamn05Bw5LaQHFsT2YpQ@mail.gmail.com>

Hi Marek,

On Mon, Dec 4, 2023 at 9:51?PM Marek Vasut <marex at denx.de> wrote:
>
> Disable and unprepare the clock on every exit from probe function
> after the clock were prepared and enabled to avoid enable/disable
> imbalance.
>
> Signed-off-by: Marek Vasut <marex at denx.de>

Reviewed-by: Fabio Estevam <festevam at gmail.com>


From cfsworks at gmail.com  Tue Dec  5 12:28:59 2023
From: cfsworks at gmail.com (Sam Edwards)
Date: Tue,  5 Dec 2023 12:28:59 -0800
Subject: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
Message-ID: <20231205202900.4617-1-CFSworks@gmail.com>

The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
will sometimes (varying between specific RK3588 chips, not over time) shut
off the DBI block, and reads to this range will instead stall
indefinitely.

When this happens, it will prevent Linux from booting altogether. The
PCIe driver will stall the CPU core once it attempts to read the version
information from the DBI range.

Fix this boot hang by adding the correct pinctrl configuration to the
PCIe 3.0 device node, which is the proper thing to do anyway. While
we're at it, also add the necessary configuration to the PCIe 2.0 node,
which may or may not fix the equivalent problem over there -- but is the
proper thing to do anyway. :)

Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
Signed-off-by: Sam Edwards <CFSworks at gmail.com>
---
 .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
index 9570b34aca2e..129f14dbd42f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
@@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy at 1 {
 &pcie2x1l1 {
 	linux,pci-domain = <1>;
 	pinctrl-names = "default";
-	pinctrl-0 = <&pcie2_reset>;
+	pinctrl-0 = <&pcie30x1m1_pins>;
 	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
 	status = "okay";
 };
@@ -226,7 +226,7 @@ &pcie30phy {
 &pcie3x4 {
 	linux,pci-domain = <0>;
 	pinctrl-names = "default";
-	pinctrl-0 = <&pcie3_reset>;
+	pinctrl-0 = <&pcie30x4m1_pins>;
 	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
 	vpcie3v3-supply = <&vcc3v3_pcie30>;
 	status = "okay";
@@ -245,17 +245,7 @@ hym8563_int: hym8563-int {
 		};
 	};
 
-	pcie2 {
-		pcie2_reset: pcie2-reset {
-			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
-		};
-	};
-
 	pcie3 {
-		pcie3_reset: pcie3-reset {
-			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
-		};
-
 		vcc3v3_pcie30_en: pcie3-reg {
 			rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
-- 
2.41.0



From cfsworks at gmail.com  Tue Dec  5 12:29:00 2023
From: cfsworks at gmail.com (Sam Edwards)
Date: Tue,  5 Dec 2023 12:29:00 -0800
Subject: [RESEND PATCH] arm64: dts: rockchip: Fix eMMC Data Strobe PD
Message-ID: <20231205202900.4617-2-CFSworks@gmail.com>

JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is
currently used only in HS400 mode, as a device->host clock signal that
"is used only in read operation. The Data Strobe is always High-Z (not
driven by the device and pulled down by RDS) or Driven Low in write
operation, except during CRC status response." RDS is a pull-down
resistor specified in the 10K-100K ohm range. Thus per the standard, the
Data Strobe is always pulled to ground (by the eMMC and/or RDS) during
write operations.

Evidently, the eMMC host controller in the RK3588 considers an active
voltage on the eMMC-DS line during a write to be an error.

The default (i.e. hardware reset, and Rockchip BSP) behavior for the
RK3588 is to activate the eMMC-DS pin's builtin pull-down. As a result,
many RK3588 board designers do not bother adding a dedicated RDS
resistor, instead relying on the RK3588's internal bias. The current
devicetree, however, disables this bias (`pcfg_pull_none`), breaking
HS400-mode writes for boards without a dedicated RDS, but with an eMMC
chip that chooses to High-Z (instead of drive-low) the eMMC-DS line.
(The Turing RK1 is one such board.)

Fix this by changing the bias in the (common) emmc_data_strobe case to
reflect the expected hardware/BSP behavior. This is unlikely to cause
regressions elsewhere: the pull-down is only relevant for High-Z eMMCs,
and if this is redundant with a (dedicated) RDS resistor, the effective
result is only a lower resistance to ground -- where the range of
tolerance is quite high. If it does, it's better fixed in the specific
devicetrees.

Fixes: d85f8a5c798d5 ("arm64: dts: rockchip: Add rk3588 pinctrl data")
Signed-off-by: Sam Edwards <CFSworks at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588s-pinctrl.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-pinctrl.dtsi
index 63151d9d2377..30db12c4fc82 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-pinctrl.dtsi
@@ -369,7 +369,7 @@ emmc_cmd: emmc-cmd {
 		emmc_data_strobe: emmc-data-strobe {
 			rockchip,pins =
 				/* emmc_data_strobe */
-				<2 RK_PA2 1 &pcfg_pull_none>;
+				<2 RK_PA2 1 &pcfg_pull_down>;
 		};
 	};
 
-- 
2.41.0



From lkp at intel.com  Tue Dec  5 13:04:42 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 6 Dec 2023 05:04:42 +0800
Subject: [PATCH V2 3/3] arm64: dts: mediatek: Add Acelink EW-7886CAX
In-Reply-To: <20231204200907.5687-3-zajec5@gmail.com>
References: <20231204200907.5687-3-zajec5@gmail.com>
Message-ID: <202312060400.SeDMAMe7-lkp@intel.com>

Hi Rafa?,

kernel test robot noticed the following build errors:

[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v6.7-rc4 next-20231205]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Rafa-Mi-ecki/dt-bindings-arm64-dts-mediatek-Add-Acelink-EW-7886CAX-access-point/20231205-041120
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/20231204200907.5687-3-zajec5%40gmail.com
patch subject: [PATCH V2 3/3] arm64: dts: mediatek: Add Acelink EW-7886CAX
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20231206/202312060400.SeDMAMe7-lkp at intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231206/202312060400.SeDMAMe7-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312060400.SeDMAMe7-lkp at intel.com/

All errors (new ones prefixed by >>):

>> Error: arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts:103.3-4 syntax error
   FATAL ERROR: Unable to parse input tree

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From peter.griffin at linaro.org  Tue Dec  5 13:24:28 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Tue, 5 Dec 2023 21:24:28 +0000
Subject: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <CAPLW+4kBOWFPx3Hr-=UoLWvRxCorzBY9RCOiBhfkKcU0LAa21Q@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-15-peter.griffin@linaro.org> <CAPLW+4kBOWFPx3Hr-=UoLWvRxCorzBY9RCOiBhfkKcU0LAa21Q@mail.gmail.com>
Message-ID: <CADrjBPoua+pBTfZbkzPEk-71OZUNsXUzMmJD7CEt0EzSjg7pDw@mail.gmail.com>

Hi Sam,

Thanks for the review.

On Sat, 2 Dec 2023 at 00:40, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > Add support for the pin-controller found on the gs101 SoC used in
> > Pixel 6 phones.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 159 ++++++++++++++++++
> >  drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
> >  drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
> >  drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
> >  drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
> >  5 files changed, 198 insertions(+)
> >
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > index cb965cf93705..e1a0668ecb16 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> > @@ -796,3 +796,162 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
> >         .ctrl           = fsd_pin_ctrl,
> >         .num_ctrl       = ARRAY_SIZE(fsd_pin_ctrl),
> >  };
> > +
> > +/*
> > + * bank type for non-alive type
> > + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
> > + * (CONPDN bit field: 2, PUDPDN bit field: 4)
> > + */
> > +static struct samsung_pin_bank_type gs101_bank_type_off  = {
> > +       .fld_width = { 4, 1, 4, 4, 2, 4, },
> > +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
> > +};
>
> This is just the same as exynos850_bank_type_off (100% duplication).

Ah nice, I hadn't spotted that these structs matched exynos850.

> Here is what I suggest. Now that it's obvious there is some common
> platform for moder Exynos SoCs, and it's probably Exynos9, I'd suggest
> next course of action (if maintainers agree):
>   1. Remove this one
>   2. Rename exynos850_bank_type_off to exynos9_bank_type_off
>   3. Use it for both gs101 and exynos850
>
> Does it make sense?

Yes, sounds like a good plan to me. I just checked downstream and they
were called bank_type_6 and bank_type_7 originally.

@Krzysztof - are you OK with the proposed generic name above
(exynos9_bank_type_off?) to be used by both exynos850 and gs101 (and
also future Tensor exynos based SoCs)?

>
> > +
> > +/*
> > + * bank type for alive type
> > + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
> > + */
> > +static const struct samsung_pin_bank_type gs101_bank_type_alive = {
> > +       .fld_width = { 4, 1, 4, 4, },
> > +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
> > +};
>
> Ditto, it's a duplication of exynos850_bank_type_alive .
>
> > +
> > +/* pin banks of gs101 pin-controller (ALIVE) */
> > +static const struct samsung_pin_bank_data gs101_pin_alive[] = {
> > +       EXYNOS9_PIN_BANK_EINTW(8, 0x0, "gpa0", 0x00, 0x00),
> > +       EXYNOS9_PIN_BANK_EINTW(7, 0x20, "gpa1", 0x04, 0x08),
> > +       EXYNOS9_PIN_BANK_EINTW(5, 0x40, "gpa2", 0x08, 0x10),
> > +       EXYNOS9_PIN_BANK_EINTW(4, 0x60, "gpa3", 0x0c, 0x18),
> > +       EXYNOS9_PIN_BANK_EINTW(4, 0x80, "gpa4", 0x10, 0x1c),
> > +       EXYNOS9_PIN_BANK_EINTW(7, 0xa0, "gpa5", 0x14, 0x20),
> > +       EXYNOS9_PIN_BANK_EINTW(8, 0xc0, "gpa9", 0x18, 0x28),
> > +       EXYNOS9_PIN_BANK_EINTW(2, 0xe0, "gpa10", 0x1c, 0x30),
> > +};
> > +
> > +/* pin banks of gs101 pin-controller (FAR_ALIVE) */
> > +static const struct samsung_pin_bank_data gs101_pin_far_alive[] = {
> > +       EXYNOS9_PIN_BANK_EINTW(8, 0x0, "gpa6", 0x00, 0x00),
> > +       EXYNOS9_PIN_BANK_EINTW(4, 0x20, "gpa7", 0x04, 0x08),
> > +       EXYNOS9_PIN_BANK_EINTW(8, 0x40, "gpa8", 0x08, 0x0c),
> > +       EXYNOS9_PIN_BANK_EINTW(2, 0x60, "gpa11", 0x0c, 0x14),
> > +};
> > +
> > +/* pin banks of gs101 pin-controller (GSACORE) */
> > +static const struct samsung_pin_bank_data gs101_pin_gsacore[] = {
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0x0, "gps0", 0x00, 0x00),
> > +       EXYNOS9_PIN_BANK_EINTG(8, 0x20, "gps1", 0x04, 0x04),
> > +       EXYNOS9_PIN_BANK_EINTG(3, 0x40, "gps2", 0x08, 0x0c),
> > +};
> > +
> > +/* pin banks of gs101 pin-controller (GSACTRL) */
> > +static const struct samsung_pin_bank_data gs101_pin_gsactrl[] = {
> > +       EXYNOS9_PIN_BANK_EINTW(6, 0x0, "gps3", 0x00, 0x00),
> > +};
> > +
> > +/* pin banks of gs101 pin-controller (PERIC0) */
> > +static const struct samsung_pin_bank_data gs101_pin_peric0[] = {
> > +       EXYNOS9_PIN_BANK_EINTG(5, 0x0, "gpp0", 0x00, 0x00),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x20, "gpp1", 0x04, 0x08),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x40, "gpp2", 0x08, 0x0c),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0x60, "gpp3", 0x0c, 0x10),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x80, "gpp4", 0x10, 0x14),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0xa0, "gpp5", 0x14, 0x18),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0xc0, "gpp6", 0x18, 0x1c),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0xe0, "gpp7", 0x1c, 0x20),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x100, "gpp8", 0x20, 0x24),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0x120, "gpp9", 0x24, 0x28),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x140, "gpp10", 0x28, 0x2c),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0x160, "gpp11", 0x2c, 0x30),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x180, "gpp12", 0x30, 0x34),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0x1a0, "gpp13", 0x34, 0x38),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x1c0, "gpp14", 0x38, 0x3c),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0x1e0, "gpp15", 0x3c, 0x40),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x200, "gpp16", 0x40, 0x44),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0x220, "gpp17", 0x44, 0x48),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x240, "gpp18", 0x48, 0x4c),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x260, "gpp19", 0x4c, 0x50),
> > +};
> > +
> > +/* pin banks of gs101 pin-controller (PERIC1) */
> > +static const struct samsung_pin_bank_data gs101_pin_peric1[] = {
> > +       EXYNOS9_PIN_BANK_EINTG(8, 0x0, "gpp20", 0x00, 0x00),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x20, "gpp21", 0x04, 0x08),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0x40, "gpp22", 0x08, 0x0c),
> > +       EXYNOS9_PIN_BANK_EINTG(8, 0x60, "gpp23", 0x0c, 0x10),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0x80, "gpp24", 0x10, 0x18),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0xa0, "gpp25", 0x14, 0x1c),
> > +       EXYNOS9_PIN_BANK_EINTG(5, 0xc0, "gpp26", 0x18, 0x20),
> > +       EXYNOS9_PIN_BANK_EINTG(4, 0xe0, "gpp27", 0x1c, 0x28),
> > +};
> > +
> > +/* pin banks of gs101 pin-controller (HSI1) */
> > +static const struct samsung_pin_bank_data gs101_pin_hsi1[] = {
> > +       EXYNOS9_PIN_BANK_EINTG(6, 0x0, "gph0", 0x00, 0x00),
> > +       EXYNOS9_PIN_BANK_EINTG(7, 0x20, "gph1", 0x04, 0x08),
> > +};
> > +
> > +/* pin banks of gs101 pin-controller (HSI2) */
> > +static const struct samsung_pin_bank_data gs101_pin_hsi2[] = {
> > +       EXYNOS9_PIN_BANK_EINTG(6, 0x0, "gph2", 0x00, 0x00),
> > +       EXYNOS9_PIN_BANK_EINTG(2, 0x20, "gph3", 0x04, 0x08),
> > +       EXYNOS9_PIN_BANK_EINTG(6, 0x40, "gph4", 0x08, 0x0c),
> > +};
> > +
> > +static const struct samsung_pin_ctrl gs101_pin_ctrl[] __initconst = {
> > +       {
> > +               /* pin banks of gs101 pin-controller (ALIVE) */
> > +               .pin_banks      = gs101_pin_alive,
> > +               .nr_banks       = ARRAY_SIZE(gs101_pin_alive),
> > +               .eint_wkup_init = exynos_eint_wkup_init,
> > +               .suspend        = exynos_pinctrl_suspend,
> > +               .resume         = exynos_pinctrl_resume,
> > +       }, {
> > +               /* pin banks of gs101 pin-controller (FAR_ALIVE) */
> > +               .pin_banks      = gs101_pin_far_alive,
> > +               .nr_banks       = ARRAY_SIZE(gs101_pin_far_alive),
> > +               .eint_wkup_init = exynos_eint_wkup_init,
> > +               .suspend        = exynos_pinctrl_suspend,
> > +               .resume         = exynos_pinctrl_resume,
> > +       }, {
> > +               /* pin banks of gs101 pin-controller (GSACORE) */
> > +               .pin_banks      = gs101_pin_gsacore,
> > +               .nr_banks       = ARRAY_SIZE(gs101_pin_gsacore),
> > +       }, {
> > +               /* pin banks of gs101 pin-controller (GSACTRL) */
> > +               .pin_banks      = gs101_pin_gsactrl,
> > +               .nr_banks       = ARRAY_SIZE(gs101_pin_gsactrl),
> > +       }, {
> > +               /* pin banks of gs101 pin-controller (PERIC0) */
> > +               .pin_banks      = gs101_pin_peric0,
> > +               .nr_banks       = ARRAY_SIZE(gs101_pin_peric0),
> > +               .eint_gpio_init = exynos_eint_gpio_init,
> > +               .suspend        = exynos_pinctrl_suspend,
> > +               .resume         = exynos_pinctrl_resume,
> > +       }, {
> > +               /* pin banks of gs101 pin-controller (PERIC1) */
> > +               .pin_banks      = gs101_pin_peric1,
> > +               .nr_banks       = ARRAY_SIZE(gs101_pin_peric1),
> > +               .eint_gpio_init = exynos_eint_gpio_init,
> > +               .suspend        = exynos_pinctrl_suspend,
> > +               .resume = exynos_pinctrl_resume,
> > +       }, {
> > +               /* pin banks of gs101 pin-controller (HSI1) */
> > +               .pin_banks      = gs101_pin_hsi1,
> > +               .nr_banks       = ARRAY_SIZE(gs101_pin_hsi1),
> > +               .eint_gpio_init = exynos_eint_gpio_init,
> > +               .suspend        = exynos_pinctrl_suspend,
> > +               .resume         = exynos_pinctrl_resume,
> > +       }, {
> > +               /* pin banks of gs101 pin-controller (HSI2) */
> > +               .pin_banks      = gs101_pin_hsi2,
> > +               .nr_banks       = ARRAY_SIZE(gs101_pin_hsi2),
> > +               .eint_gpio_init = exynos_eint_gpio_init,
> > +               .suspend        = exynos_pinctrl_suspend,
> > +               .resume         = exynos_pinctrl_resume,
> > +       },
> > +};
> > +
> > +const struct samsung_pinctrl_of_match_data gs101_of_data __initconst = {
> > +       .ctrl           = gs101_pin_ctrl,
> > +       .num_ctrl       = ARRAY_SIZE(gs101_pin_ctrl),
> > +};
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > index 56fc11a1fe2f..75b9cf72ce73 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > @@ -537,6 +537,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
> >                         .data = &exynos7_wkup_irq_chip },
> >         { .compatible = "samsung,exynosautov9-wakeup-eint",
> >                         .data = &exynos7_wkup_irq_chip },
> > +       { .compatible = "google,gs101-wakeup-eint",
> > +                       .data = &exynos7_wkup_irq_chip },
> >         { }
> >  };
> >
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
> > index e2799ff1b5e9..1ffc90db079d 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
> > @@ -147,6 +147,40 @@
> >                 .name           = id                            \
> >         }
> >
> > +#define EXYNOS9_PIN_BANK_EINTN(types, pins, reg, id)   \
> > +       {                                               \
> > +               .type           = &types,               \
> > +               .pctl_offset    = reg,                  \
> > +               .nr_pins        = pins,                 \
> > +               .eint_type      = EINT_TYPE_NONE,       \
> > +               .fltcon_type    = FLT_DEFAULT           \
> > +               .name           = id                    \
> > +       }
>
> Where exactly it is used? What is 'types'?

EXYNOS9_PIN_BANK_EINTN macro can be dropped completely for gs101 as it
isn't used anywhere. I checked downstream code and it is declared and
not used there as well.

>Moreover, it doesn't look
> very different from EXYNOS850_PIN_BANK_EINTN() -- just because I
> created EXYNOS850_PIN_BANK_EINTN() exactly from this downstream macro.
> I was strictly prohibited adding EXYNOS9_* stuff back at the time. But
> now I guess it should be apparent we are actually dealing with Exynos9
> common platform. So I suggest renaming EXYNOS850_PIN_BANK_EINTN() to
> EXYNOS9_PIN_BANK_EINTN().
>
> > +
> > +#define EXYNOS9_PIN_BANK_EINTG(pins, reg, id, offs, fltcon_offs) \
> > +       {                                               \
> > +               .type           = &gs101_bank_type_off, \
> > +               .pctl_offset    = reg,                  \
> > +               .nr_pins        = pins,                 \
> > +               .eint_type      = EINT_TYPE_GPIO,       \
> > +               .eint_offset    = offs,                 \
> > +               .fltcon_type    = FLT_DEFAULT,          \
> > +               .fltcon_offset  = fltcon_offs,          \
> > +               .name           = id                    \
> > +       }
>
> Ditto. Please add filter fields to EXYNOS850_PIN_BANK_EINTG() instead
> of adding pretty much the same macro (it is the same, I created
> EXYNOS850_PIN_BANK_EINTG() from exactly this macro). Also I suggest
> renaming EXYNOS850_PIN_BANK_EINTG() to EXYNOS9_PIN_BANK_EINTG(), to
> avoid confusion. If you need any help with reworking Exynos850 pinctrl
> correspondingly, please let me know.

The only issue for me migrating Exynos850 to EXYNOS9_PIN_BANK_EINTG is
knowing what the fltcon_offset is. Can you provide the fltcon_offset
offsets for the relevant Exynos850 banks and help test?

Thanks,

Peter.

>
> > +
> > +#define EXYNOS9_PIN_BANK_EINTW(pins, reg, id, offs, fltcon_offs) \
> > +       {                                                       \
> > +               .type           = &gs101_bank_type_alive,       \
> > +               .pctl_offset    = reg,                          \
> > +               .nr_pins        = pins,                         \
> > +               .eint_type      = EINT_TYPE_WKUP,               \
> > +               .eint_offset    = offs,                         \
> > +               .fltcon_type    = FLT_SELECTABLE,               \
> > +               .fltcon_offset  = fltcon_offs,                  \
> > +               .name           = id                            \
> > +       }
>
> Ditto.
>
> > +
> >  /**
> >   * struct exynos_weint_data: irq specific data for all the wakeup interrupts
> >   * generated by the external wakeup interrupt controller.
> > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > index 50c360b4753a..982a5702714c 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > @@ -1323,6 +1323,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
> >                 .data = &exynosautov9_of_data },
> >         { .compatible = "tesla,fsd-pinctrl",
> >                 .data = &fsd_of_data },
> > +       { .compatible = "google,gs101-pinctrl",
> > +               .data = &gs101_of_data },
> >  #endif
> >  #ifdef CONFIG_PINCTRL_S3C64XX
> >         { .compatible = "samsung,s3c64xx-pinctrl",
> > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> > index 5fab3885a7d7..f6856290608c 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> > @@ -373,6 +373,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
> >  extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
> >  extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
> >  extern const struct samsung_pinctrl_of_match_data fsd_of_data;
> > +extern const struct samsung_pinctrl_of_match_data gs101_of_data;
> >  extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
> >  extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
> >  extern const struct samsung_pinctrl_of_match_data s3c2416_of_data;
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >


From festevam at gmail.com  Tue Dec  5 13:26:38 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 5 Dec 2023 18:26:38 -0300
Subject: [PATCH] ARM: dts: imx28-tx28: Pass #sound-dai-cells
In-Reply-To: <d2029304-ec7e-4679-aecf-bdeedcd88242@gmx.net>
References: <20231205145335.2055549-1-festevam@gmail.com> <d2029304-ec7e-4679-aecf-bdeedcd88242@gmx.net>
Message-ID: <CAOMZO5Dtq6Z4fJEy=oDyxOmbbv1d32VVx1TfDpqyrvVoz+HTBg@mail.gmail.com>

Hi Stefan,

On Tue, Dec 5, 2023 at 3:32?PM Stefan Wahren <wahrenst at gmx.net> wrote:

> this patch is fine
>
> Reviewed-by: Stefan Wahren <wahrenst at gmx.net>

Thanks for your review.

> but this node name looks wrong.
>
> It should be sgtl5000: codec at a

Yes, I noticed that too.

I will address this on a separate patch. There are other i.MX DTs that use the
sgtl5000 at a format and need to be fixed as well.


From zajec5 at gmail.com  Tue Dec  5 13:44:01 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 5 Dec 2023 22:44:01 +0100
Subject: [PATCH V2 3/3] arm64: dts: mediatek: Add Acelink EW-7886CAX
In-Reply-To: <202312060400.SeDMAMe7-lkp@intel.com>
References: <20231204200907.5687-3-zajec5@gmail.com>
 <202312060400.SeDMAMe7-lkp@intel.com>
Message-ID: <708e46fb-5aaf-4c47-a8f5-4cd5171a8d76@gmail.com>

On 5.12.2023 22:04, kernel test robot wrote:
> Hi Rafa?,
> 
> kernel test robot noticed the following build errors:
> 
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on linus/master v6.7-rc4 next-20231205]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Rafa-Mi-ecki/dt-bindings-arm64-dts-mediatek-Add-Acelink-EW-7886CAX-access-point/20231205-041120
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
> patch link:    https://lore.kernel.org/r/20231204200907.5687-3-zajec5%40gmail.com
> patch subject: [PATCH V2 3/3] arm64: dts: mediatek: Add Acelink EW-7886CAX
> config: arm64-defconfig (https://download.01.org/0day-ci/archive/20231206/202312060400.SeDMAMe7-lkp at intel.com/config)
> compiler: aarch64-linux-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231206/202312060400.SeDMAMe7-lkp at intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp at intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202312060400.SeDMAMe7-lkp at intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>>> Error: arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts:103.3-4 syntax error
>     FATAL ERROR: Unable to parse input tree

Ahh, required change stayed right there in my "git diff". I noticed it,
fixed, but forgot to amend. Sorry, I'll send V3 shortly.


From festevam at gmail.com  Tue Dec  5 13:59:38 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 5 Dec 2023 18:59:38 -0300
Subject: [PATCH] arm64: dts: ls1012a: Remove big-endian from thermal
In-Reply-To: <20231010014035.GB819755@dragon>
References: <20230929185510.707475-1-festevam@gmail.com> <20231010014035.GB819755@dragon>
Message-ID: <CAOMZO5BjEEk0e8vyYm2XW0DCDPEoCUQn3ufN5hpES18uaPRMww@mail.gmail.com>

Hi Leo,

On Mon, Oct 9, 2023 at 10:40?PM Shawn Guo <shawnguo at kernel.org> wrote:
>
> On Fri, Sep 29, 2023 at 03:55:10PM -0300, Fabio Estevam wrote:
> > From: Fabio Estevam <festevam at denx.de>
> >
> > Per qoriq-thermal.yaml, 'big-endian' is not a valid property.
> >
> > When the 'little-endian' property is absent, the default is big endian.
> >
> > Remove it to fix the following schema warning:
> >
> > tmu at 1f00000: 'big-endian' does not match any of the regexes: 'pinctrl-[0-9]+'
> > from schema $id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
> >
> > Signed-off-by: Fabio Estevam <festevam at denx.de>
>
> Leo,
>
> Can you confirm this is fine?

Do you agree with this change?

>
> Shawn
>
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > index a863022529ac..d0733451d3ce 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > @@ -346,7 +346,6 @@ tmu: tmu at 1f00000 {
> >                                              0x00030004 0x00000047
> >                                              0x00030005 0x00000053
> >                                              0x00030006 0x00000060>;
> > -                     big-endian;
> >                       #thermal-sensor-cells = <1>;
> >               };
> >
> > --
> > 2.34.1
> >


From peter.griffin at linaro.org  Tue Dec  5 14:03:51 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Tue, 5 Dec 2023 22:03:51 +0000
Subject: [PATCH v5 15/20] watchdog: s3c2410_wdt: Add support for WTCON
 register DBGACK_MASK bit
In-Reply-To: <CAPLW+4=2aK-XJ69cTBzwhQF8s3E9in-NFkK3h43L7C+oieqyDg@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-16-peter.griffin@linaro.org> <CAPLW+4=2aK-XJ69cTBzwhQF8s3E9in-NFkK3h43L7C+oieqyDg@mail.gmail.com>
Message-ID: <CADrjBPreo1uXOksJ15AaiowGS8wf63DV6Q_phDvZzxoinVYjqQ@mail.gmail.com>

Hi Sam,

On Sat, 2 Dec 2023 at 00:53, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > The WDT uses the CPU core signal DBGACK to determine whether the SoC
> > is running in debug mode or not. If the DBGACK signal is asserted and
> > DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
> > (disabled).
> >
> > Presence of the DBGACK_MASK bit is determined by adding a new
> > QUIRK_HAS_DBGACK_BIT quirk.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  drivers/watchdog/s3c2410_wdt.c | 27 ++++++++++++++++++++++++---
> >  1 file changed, 24 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> > index 0b4bd883ff28..39f3489e41d6 100644
> > --- a/drivers/watchdog/s3c2410_wdt.c
> > +++ b/drivers/watchdog/s3c2410_wdt.c
> > @@ -34,9 +34,10 @@
> >
> >  #define S3C2410_WTCNT_MAXCNT   0xffff
> >
> > -#define S3C2410_WTCON_RSTEN    (1 << 0)
> > -#define S3C2410_WTCON_INTEN    (1 << 2)
> > -#define S3C2410_WTCON_ENABLE   (1 << 5)
> > +#define S3C2410_WTCON_RSTEN            (1 << 0)
> > +#define S3C2410_WTCON_INTEN            (1 << 2)
> > +#define S3C2410_WTCON_ENABLE           (1 << 5)
> > +#define S3C2410_WTCON_DBGACK_MASK      (1 << 16)
>
> Suggest using BIT() macro. Btw, checkpatch with --strict option
> suggests it too :)

Yes indeed. I was somewhat reluctant to include changes that had
nothing to do with the DBGACK feature but I will update to use the BIT
macro in v6.
>
> >
> >  #define S3C2410_WTCON_DIV16    (0 << 3)
> >  #define S3C2410_WTCON_DIV32    (1 << 3)
> > @@ -100,12 +101,17 @@
> >   * %QUIRK_HAS_PMU_CNT_EN: PMU block has some register (e.g. CLUSTERx_NONCPU_OUT)
> >   * with "watchdog counter enable" bit. That bit should be set to make watchdog
> >   * counter running.
> > + *
> > + * %QUIRK_HAS_DBGACK_BIT: WTCON register has DBGACK_MASK bit. Setting the
> > + * DBGACK_MASK bit disables the watchdog outputs when the SoC is in debug mode.
> > + * Debug mode is determined by the DBGACK CPU signal.
> >   */
> >  #define QUIRK_HAS_WTCLRINT_REG                 (1 << 0)
> >  #define QUIRK_HAS_PMU_MASK_RESET               (1 << 1)
> >  #define QUIRK_HAS_PMU_RST_STAT                 (1 << 2)
> >  #define QUIRK_HAS_PMU_AUTO_DISABLE             (1 << 3)
> >  #define QUIRK_HAS_PMU_CNT_EN                   (1 << 4)
> > +#define QUIRK_HAS_DBGACK_BIT                   (1 << 5)
> >
> >  /* These quirks require that we have a PMU register map */
> >  #define QUIRKS_HAVE_PMUREG \
> > @@ -375,6 +381,19 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
> >         return 0;
> >  }
> >
> > +static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt)
> > +{
> > +       unsigned long wtcon;
> > +
> > +       if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
> > +               return;
> > +
> > +       /*  disable watchdog outputs if CPU is in debug mode */
>
> Double whitespace in the comment. Also, I'd move this comment up to
> the function declaration.

Will fix

>
> Other than that:
>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

Thanks,

Peter
>
> > +       wtcon = readl(wdt->reg_base + S3C2410_WTCON);
> > +       wtcon |= S3C2410_WTCON_DBGACK_MASK;
> > +       writel(wtcon, wdt->reg_base + S3C2410_WTCON);
> > +}
> > +
> >  static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
> >  {
> >         struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
> > @@ -700,6 +719,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
> >         wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
> >         wdt->wdt_device.parent = dev;
> >
> > +       s3c2410wdt_mask_dbgack(wdt);
> > +
> >         /*
> >          * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
> >          * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >


From peter.griffin at linaro.org  Tue Dec  5 14:19:35 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Tue, 5 Dec 2023 22:19:35 +0000
Subject: [PATCH v5 16/20] watchdog: s3c2410_wdt: Add support for Google
 gs101 SoC
In-Reply-To: <CAPLW+4mxzu4d_9i=ouDGtnSRMbhibfBnT5aXhkC4cGEC1bm6Bw@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-17-peter.griffin@linaro.org> <CAPLW+4mxzu4d_9i=ouDGtnSRMbhibfBnT5aXhkC4cGEC1bm6Bw@mail.gmail.com>
Message-ID: <CADrjBPrK9+1O3u3MEh9VGGjdODidzTKM64a6P26fFPZqjvJSGQ@mail.gmail.com>

Hi Sam,

On Sat, 2 Dec 2023 at 01:02, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > This patch adds the compatibles and drvdata for the Google
> > gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.
> >
> > Similar to Exynos850 it has two watchdog instances, one for
> > each cluster and has some control bits in PMU registers.
> >
> > gs101 also has the dbgack_mask bit in wtcon register, so
> > we also enable QUIRK_HAS_DBGACK_BIT.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  drivers/watchdog/s3c2410_wdt.c | 47 ++++++++++++++++++++++++++++++----
> >  1 file changed, 42 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> > index 39f3489e41d6..c1ae71574457 100644
> > --- a/drivers/watchdog/s3c2410_wdt.c
> > +++ b/drivers/watchdog/s3c2410_wdt.c
> > @@ -68,6 +68,13 @@
> >  #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT     25
> >  #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT     24
> >
> > +#define GS_CLUSTER0_NONCPU_OUT                 0x1220
> > +#define GS_CLUSTER1_NONCPU_OUT                 0x1420
> > +#define GS_CLUSTER0_NONCPU_INT_EN              0x1244
> > +#define GS_CLUSTER1_NONCPU_INT_EN              0x1444
> > +#define GS_CLUSTER2_NONCPU_INT_EN              0x1644
> > +#define GS_RST_STAT_REG_OFFSET                 0x3B44
> > +
> >  /**
> >   * DOC: Quirk flags for different Samsung watchdog IP-cores
> >   *
> > @@ -269,6 +276,30 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
> >                   QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
> >  };
> >
> > +static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
> > +       .mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
> > +       .mask_bit = 2,
> > +       .mask_reset_inv = true,
> > +       .rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> > +       .rst_stat_bit = 0,
> > +       .cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
> > +       .cnt_en_bit = 8,
> > +       .quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
>
> Please keep it at 80 characters limit.

will fix
>
> > +                 QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT,
> > +};
> > +
> > +static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
> > +       .mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
> > +       .mask_bit = 2,
> > +       .mask_reset_inv = true,
> > +       .rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> > +       .rst_stat_bit = 1,
> > +       .cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
> > +       .cnt_en_bit = 7,
> > +       .quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
>
> Please keep it at 80 characters limit.

will fix
>
> > +                 QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT,
> > +};
> > +
> >  static const struct of_device_id s3c2410_wdt_match[] = {
> >         { .compatible = "samsung,s3c2410-wdt",
> >           .data = &drv_data_s3c2410 },
> > @@ -284,6 +315,8 @@ static const struct of_device_id s3c2410_wdt_match[] = {
> >           .data = &drv_data_exynos850_cl0 },
> >         { .compatible = "samsung,exynosautov9-wdt",
> >           .data = &drv_data_exynosautov9_cl0 },
> > +       { .compatible = "google,gs101-wdt",
> > +         .data = &drv_data_gs101_cl0 },
> >         {},
> >  };
> >  MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
> > @@ -604,9 +637,10 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
> >         }
> >
> >  #ifdef CONFIG_OF
> > -       /* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
> > +       /* Choose Exynos850/ExynosAutov9/gs101 driver data w.r.t. cluster index */
>
> Please keep it at 80 characters limit. Also, maybe just make it more
> generic and mention "Exynos9 platforms" instead of listing all SoCs?
>

Will fix and reword.

> Other than that:
>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

Thanks!

Peter
>
>
> >         if (variant == &drv_data_exynos850_cl0 ||
> > -           variant == &drv_data_exynosautov9_cl0) {
> > +           variant == &drv_data_exynosautov9_cl0 ||
> > +           variant == &drv_data_gs101_cl0) {
> >                 u32 index;
> >                 int err;
> >
> > @@ -619,9 +653,12 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
> >                 case 0:
> >                         break;
> >                 case 1:
> > -                       variant = (variant == &drv_data_exynos850_cl0) ?
> > -                               &drv_data_exynos850_cl1 :
> > -                               &drv_data_exynosautov9_cl1;
> > +                       if (variant == &drv_data_exynos850_cl0)
> > +                               variant = &drv_data_exynos850_cl1;
> > +                       else if (variant == &drv_data_exynosautov9_cl0)
> > +                               variant = &drv_data_exynosautov9_cl1;
> > +                       else if (variant == &drv_data_gs101_cl0)
> > +                               variant = &drv_data_gs101_cl1;
> >                         break;
> >                 default:
> >                         return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >


From peter.griffin at linaro.org  Tue Dec  5 14:27:21 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Tue, 5 Dec 2023 22:27:21 +0000
Subject: [PATCH v5 17/20] tty: serial: samsung: Add gs101 compatible and
 common fifoszdt_serial_drv_data
In-Reply-To: <CAPLW+4mGykKdYuhjcpYQwk7cabo0mFv6Qo3UedcrVcLvMkww_Q@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-18-peter.griffin@linaro.org> <CAPLW+4mGykKdYuhjcpYQwk7cabo0mFv6Qo3UedcrVcLvMkww_Q@mail.gmail.com>
Message-ID: <CADrjBPrPqe8wnvmwB3+WKA_q=fkfNVAyhxHLe6Ok_LifGxARjg@mail.gmail.com>

Hi Sam,

On Sat, 2 Dec 2023 at 01:09, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > Add serial driver data for Google Tensor gs101 SoC and a common
> > fifoszdt_serial_drv_data that can be used by platforms that specify the
> > samsung,uart-fifosize DT property.
> >
> > A corresponding dt-bindings patch updates the yaml to ensure
> > samsung,uart-fifosize is a required property.
> >
> > Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> > Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> > Reviewed-by: Arnd Bergmann <arnd at arndb.de>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  drivers/tty/serial/samsung_tty.c | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> > index 1b0c2b467a30..f8d98f1006de 100644
> > --- a/drivers/tty/serial/samsung_tty.c
> > +++ b/drivers/tty/serial/samsung_tty.c
> > @@ -2490,14 +2490,25 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
> >         .fifosize = { 256, 64, 64, 64 },
> >  };
> >
> > +/*
> > + * Common drv_data struct for platforms that specify uart,fifosize in
> > + * device tree.
>
> Isn't it "samsung,uart-fifosize"? Or it was intended this way?

The comment should read "samsung,uart-fifosize". Will update.

Thanks,

Peter.
>
> Other than this, LGTM (my R-b tag is already present in this patch).
>
> > + */
> > +static const struct s3c24xx_serial_drv_data exynos_fifoszdt_serial_drv_data = {
> > +       EXYNOS_COMMON_SERIAL_DRV_DATA(),
> > +       .fifosize = { 0 },
> > +};
> > +
> >  #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
> >  #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
> >  #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
> > +#define EXYNOS_FIFOSZDT_DRV_DATA (&exynos_fifoszdt_serial_drv_data)
> >
> >  #else
> >  #define EXYNOS4210_SERIAL_DRV_DATA NULL
> >  #define EXYNOS5433_SERIAL_DRV_DATA NULL
> >  #define EXYNOS850_SERIAL_DRV_DATA NULL
> > +#define EXYNOS_FIFOSZDT_DRV_DATA NULL
> >  #endif
> >
> >  #ifdef CONFIG_ARCH_APPLE
> > @@ -2581,6 +2592,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
> >         }, {
> >                 .name           = "artpec8-uart",
> >                 .driver_data    = (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
> > +       }, {
> > +               .name           = "gs101-uart",
> > +               .driver_data    = (kernel_ulong_t)EXYNOS_FIFOSZDT_DRV_DATA,
> >         },
> >         { },
> >  };
> > @@ -2602,6 +2616,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
> >                 .data = EXYNOS850_SERIAL_DRV_DATA },
> >         { .compatible = "axis,artpec8-uart",
> >                 .data = ARTPEC8_SERIAL_DRV_DATA },
> > +       { .compatible = "google,gs101-uart",
> > +               .data = EXYNOS_FIFOSZDT_DRV_DATA },
> >         {},
> >  };
> >  MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >


From peter.griffin at linaro.org  Tue Dec  5 14:29:34 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Tue, 5 Dec 2023 22:29:34 +0000
Subject: [PATCH v5 17/20] tty: serial: samsung: Add gs101 compatible and
 common fifoszdt_serial_drv_data
In-Reply-To: <ZWpz5L2g4SB2cdVD@google.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-18-peter.griffin@linaro.org> <ZWpz5L2g4SB2cdVD@google.com>
Message-ID: <CADrjBPpOUf72k=tFWsOQUUuH2Nc8O9=_EaX7QexTCvRT-5QndQ@mail.gmail.com>

Hi Will,

On Sat, 2 Dec 2023 at 00:01, William McVicker <willmcvicker at google.com> wrote:
>
> On 12/01/2023, Peter Griffin wrote:
> > Add serial driver data for Google Tensor gs101 SoC and a common
> > fifoszdt_serial_drv_data that can be used by platforms that specify the
> > samsung,uart-fifosize DT property.
> >
> > A corresponding dt-bindings patch updates the yaml to ensure
> > samsung,uart-fifosize is a required property.
> >
> > Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> > Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> > Reviewed-by: Arnd Bergmann <arnd at arndb.de>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
>
> Tested-by: Will McVicker <willmcvicker at google.com>
>
> ---
>
> I verified boot to a busybox console with kernel logs printed to the serial
> port.

Thanks for testing :) I've added your Tested-by tags to the various
patches apart from the pinctrl ones that have been refactored a bit.

Thanks,

Peter.
>
> Regards,
> Will
>
> > ---
> >  drivers/tty/serial/samsung_tty.c | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> > index 1b0c2b467a30..f8d98f1006de 100644
> > --- a/drivers/tty/serial/samsung_tty.c
> > +++ b/drivers/tty/serial/samsung_tty.c
> > @@ -2490,14 +2490,25 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
> >       .fifosize = { 256, 64, 64, 64 },
> >  };
> >
> > +/*
> > + * Common drv_data struct for platforms that specify uart,fifosize in
> > + * device tree.
> > + */
> > +static const struct s3c24xx_serial_drv_data exynos_fifoszdt_serial_drv_data = {
> > +     EXYNOS_COMMON_SERIAL_DRV_DATA(),
> > +     .fifosize = { 0 },
> > +};
> > +
> >  #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
> >  #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
> >  #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
> > +#define EXYNOS_FIFOSZDT_DRV_DATA (&exynos_fifoszdt_serial_drv_data)
> >
> >  #else
> >  #define EXYNOS4210_SERIAL_DRV_DATA NULL
> >  #define EXYNOS5433_SERIAL_DRV_DATA NULL
> >  #define EXYNOS850_SERIAL_DRV_DATA NULL
> > +#define EXYNOS_FIFOSZDT_DRV_DATA NULL
> >  #endif
> >
> >  #ifdef CONFIG_ARCH_APPLE
> > @@ -2581,6 +2592,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
> >       }, {
> >               .name           = "artpec8-uart",
> >               .driver_data    = (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
> > +     }, {
> > +             .name           = "gs101-uart",
> > +             .driver_data    = (kernel_ulong_t)EXYNOS_FIFOSZDT_DRV_DATA,
> >       },
> >       { },
> >  };
> > @@ -2602,6 +2616,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
> >               .data = EXYNOS850_SERIAL_DRV_DATA },
> >       { .compatible = "axis,artpec8-uart",
> >               .data = ARTPEC8_SERIAL_DRV_DATA },
> > +     { .compatible = "google,gs101-uart",
> > +             .data = EXYNOS_FIFOSZDT_DRV_DATA },
> >       {},
> >  };
> >  MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >


From linus.walleij at linaro.org  Tue Dec  5 14:43:19 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 5 Dec 2023 23:43:19 +0100
Subject: [PATCH net-next v2 6/9] net: wan/ixp4xx_hss: Convert to platform
 remove callback returning void
In-Reply-To: <b0488fa6181a47668e5737905ae7adc8d7cd055e.1701713943.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701713943.git.u.kleine-koenig@pengutronix.de> <b0488fa6181a47668e5737905ae7adc8d7cd055e.1701713943.git.u.kleine-koenig@pengutronix.de>
Message-ID: <CACRpkdbszYnpuDYeUCKiMwJvV9tq8b4Yq8bmsTr7vK5g_b=Qng@mail.gmail.com>

On Mon, Dec 4, 2023 at 7:31?PM Uwe Kleine-K?nig
<u.kleine-koenig at pengutronix.de> wrote:

> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
>
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Link: https://lore.kernel.org/r/20231117095922.876489-8-u.kleine-koenig at pengutronix.de
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From florian.fainelli at broadcom.com  Tue Dec  5 14:44:49 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Tue,  5 Dec 2023 14:44:49 -0800
Subject: [PATCH V2 2/2] ARM: dts: broadcom: Add BCM63138's high speed UART
In-Reply-To: <20231122144208.21114-2-zajec5@gmail.com>
References: <20231122144208.21114-1-zajec5@gmail.com> <20231122144208.21114-2-zajec5@gmail.com>
Message-ID: <20231205224449.632075-1-florian.fainelli@broadcom.com>

From: Florian Fainelli <f.fainelli at gmail.com>

On Wed, 22 Nov 2023 15:42:08 +0100, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> It's designed for hardwiring Bluetooth devices to it.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian


From florian.fainelli at broadcom.com  Tue Dec  5 14:50:21 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Tue,  5 Dec 2023 14:50:21 -0800
Subject: [GIT PULL 1/1] Broadcom devicetree fixes for 6.7
Message-ID: <20231205225021.653045-1-florian.fainelli@broadcom.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://github.com/Broadcom/stblinux.git tags/arm-soc/for-6.7/devicetree-fixes

for you to fetch changes up to dc761f11af2e39119d3a7942e3d10615f3d900e7:

  ARM: dts: bcm2711-rpi-400: Fix delete-node of led_act (2023-11-28 16:26:07 -0800)

----------------------------------------------------------------
This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
6.7, please pull the following:

- Stefan corrects the disabling of the activity LED for the Raspberry Pi
  400

----------------------------------------------------------------
Stefan Wahren (1):
      ARM: dts: bcm2711-rpi-400: Fix delete-node of led_act

 arch/arm/boot/dts/broadcom/bcm2711-rpi-400.dts | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)


From florian.fainelli at broadcom.com  Tue Dec  5 14:51:54 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Tue, 5 Dec 2023 14:51:54 -0800
Subject: [PATCH V4 1/3] dt-bindings: usb: xhci: Add support for BCM2711
In-Reply-To: <20231205200531.8232-2-wahrenst@gmx.net>
References: <20231205200531.8232-1-wahrenst@gmx.net>
 <20231205200531.8232-2-wahrenst@gmx.net>
Message-ID: <22afbcd0-e812-4ccf-a513-6747d8eceec7@broadcom.com>

On 12/5/23 12:05, Stefan Wahren wrote:
> The xHCI IP on the BCM2711 SoC is compatible to "brcm,xhci-brcm-v2",
> but also requires a power domain. So introduce a new compatible
> and the specific constraints. Since the key allOf can only occur
> once, merge the reference below.
> 
> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
> Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/84c4c3d5/attachment.p7s>

From florian.fainelli at broadcom.com  Tue Dec  5 14:53:54 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Tue, 5 Dec 2023 14:53:54 -0800
Subject: [PATCH V4 2/3] usb: xhci: xhci-plat: Add support for BCM2711
In-Reply-To: <20231205200531.8232-3-wahrenst@gmx.net>
References: <20231205200531.8232-1-wahrenst@gmx.net>
 <20231205200531.8232-3-wahrenst@gmx.net>
Message-ID: <361289df-6a76-4a83-b027-318dcfa3817a@broadcom.com>

On 12/5/23 12:05, Stefan Wahren wrote:
> With the introduction of a BCM2711 specific compatible, this also
> needs to be added to the xHCI driver.
> 
> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>

Tested-by: Florian Fainelli <florian.fainelli at broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/f29cd710/attachment-0001.p7s>

From florian.fainelli at broadcom.com  Tue Dec  5 14:53:56 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Tue, 5 Dec 2023 14:53:56 -0800
Subject: [PATCH V4 3/3] ARM: dts: bcm2711: Add BCM2711 xHCI support
In-Reply-To: <20231205200531.8232-4-wahrenst@gmx.net>
References: <20231205200531.8232-1-wahrenst@gmx.net>
 <20231205200531.8232-4-wahrenst@gmx.net>
Message-ID: <ae9171c1-af2c-4bd2-82f4-a7598aa92959@broadcom.com>

On 12/5/23 12:05, Stefan Wahren wrote:
> The BCM2711 SoC also has a mostly generic xHCI. The USB port is
> currently only usable on the Compute Module 4 (e.g. via IO board).
> Because DWC2 and xHCI share the same PHY, we let the bootloader
> enable it on demand.
> 
> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>

Tested-by: Florian Fainelli <florian.fainelli at broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231205/02c37f1b/attachment.p7s>

From lkp at intel.com  Tue Dec  5 15:03:46 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 6 Dec 2023 07:03:46 +0800
Subject: [PATCH net-next 11/16] net: pcs: xpcs: Change
 xpcs_create_mdiodev() suffix to "byaddr"
In-Reply-To: <20231205103559.9605-12-fancer.lancer@gmail.com>
References: <20231205103559.9605-12-fancer.lancer@gmail.com>
Message-ID: <202312060634.Cblfigt2-lkp@intel.com>

Hi Serge,

kernel test robot noticed the following build errors:

[auto build test ERROR on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Serge-Semin/net-pcs-xpcs-Drop-sentinel-entry-from-2500basex-ifaces-list/20231205-183808
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231205103559.9605-12-fancer.lancer%40gmail.com
patch subject: [PATCH net-next 11/16] net: pcs: xpcs: Change xpcs_create_mdiodev() suffix to "byaddr"
config: arc-randconfig-001-20231206 (https://download.01.org/0day-ci/archive/20231206/202312060634.Cblfigt2-lkp at intel.com/config)
compiler: arc-elf-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231206/202312060634.Cblfigt2-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312060634.Cblfigt2-lkp at intel.com/

All error/warnings (new ones prefixed by >>):

   drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c: In function 'txgbe_mdio_pcs_init':
>> drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c:150:16: error: implicit declaration of function 'xpcs_create_mdiodev'; did you mean 'xpcs_create_byaddr'? [-Werror=implicit-function-declaration]
     150 |         xpcs = xpcs_create_mdiodev(mii_bus, 0, PHY_INTERFACE_MODE_10GBASER);
         |                ^~~~~~~~~~~~~~~~~~~
         |                xpcs_create_byaddr
>> drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c:150:14: warning: assignment to 'struct dw_xpcs *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     150 |         xpcs = xpcs_create_mdiodev(mii_bus, 0, PHY_INTERFACE_MODE_10GBASER);
         |              ^
   cc1: some warnings being treated as errors


vim +150 drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c

854cace61387b6 Jiawen Wu      2023-06-06  121  
854cace61387b6 Jiawen Wu      2023-06-06  122  static int txgbe_mdio_pcs_init(struct txgbe *txgbe)
854cace61387b6 Jiawen Wu      2023-06-06  123  {
854cace61387b6 Jiawen Wu      2023-06-06  124  	struct mii_bus *mii_bus;
854cace61387b6 Jiawen Wu      2023-06-06  125  	struct dw_xpcs *xpcs;
854cace61387b6 Jiawen Wu      2023-06-06  126  	struct pci_dev *pdev;
854cace61387b6 Jiawen Wu      2023-06-06  127  	struct wx *wx;
854cace61387b6 Jiawen Wu      2023-06-06  128  	int ret = 0;
854cace61387b6 Jiawen Wu      2023-06-06  129  
854cace61387b6 Jiawen Wu      2023-06-06  130  	wx = txgbe->wx;
854cace61387b6 Jiawen Wu      2023-06-06  131  	pdev = wx->pdev;
854cace61387b6 Jiawen Wu      2023-06-06  132  
854cace61387b6 Jiawen Wu      2023-06-06  133  	mii_bus = devm_mdiobus_alloc(&pdev->dev);
854cace61387b6 Jiawen Wu      2023-06-06  134  	if (!mii_bus)
854cace61387b6 Jiawen Wu      2023-06-06  135  		return -ENOMEM;
854cace61387b6 Jiawen Wu      2023-06-06  136  
854cace61387b6 Jiawen Wu      2023-06-06  137  	mii_bus->name = "txgbe_pcs_mdio_bus";
854cace61387b6 Jiawen Wu      2023-06-06  138  	mii_bus->read_c45 = &txgbe_pcs_read;
854cace61387b6 Jiawen Wu      2023-06-06  139  	mii_bus->write_c45 = &txgbe_pcs_write;
854cace61387b6 Jiawen Wu      2023-06-06  140  	mii_bus->parent = &pdev->dev;
854cace61387b6 Jiawen Wu      2023-06-06  141  	mii_bus->phy_mask = ~0;
854cace61387b6 Jiawen Wu      2023-06-06  142  	mii_bus->priv = wx;
854cace61387b6 Jiawen Wu      2023-06-06  143  	snprintf(mii_bus->id, MII_BUS_ID_SIZE, "txgbe_pcs-%x",
d8c21ef7b2b147 Xiongfeng Wang 2023-08-08  144  		 pci_dev_id(pdev));
854cace61387b6 Jiawen Wu      2023-06-06  145  
854cace61387b6 Jiawen Wu      2023-06-06  146  	ret = devm_mdiobus_register(&pdev->dev, mii_bus);
854cace61387b6 Jiawen Wu      2023-06-06  147  	if (ret)
854cace61387b6 Jiawen Wu      2023-06-06  148  		return ret;
854cace61387b6 Jiawen Wu      2023-06-06  149  
854cace61387b6 Jiawen Wu      2023-06-06 @150  	xpcs = xpcs_create_mdiodev(mii_bus, 0, PHY_INTERFACE_MODE_10GBASER);
854cace61387b6 Jiawen Wu      2023-06-06  151  	if (IS_ERR(xpcs))
854cace61387b6 Jiawen Wu      2023-06-06  152  		return PTR_ERR(xpcs);
854cace61387b6 Jiawen Wu      2023-06-06  153  
854cace61387b6 Jiawen Wu      2023-06-06  154  	txgbe->xpcs = xpcs;
854cace61387b6 Jiawen Wu      2023-06-06  155  
854cace61387b6 Jiawen Wu      2023-06-06  156  	return 0;
854cace61387b6 Jiawen Wu      2023-06-06  157  }
854cace61387b6 Jiawen Wu      2023-06-06  158  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From rdunlap at infradead.org  Tue Dec  5 15:04:48 2023
From: rdunlap at infradead.org (Randy Dunlap)
Date: Tue,  5 Dec 2023 15:04:48 -0800
Subject: [PATCH] clocksource: cadence-ttc: fix some kernel-doc warnings
Message-ID: <20231205230448.772-1-rdunlap@infradead.org>

Fix some function kernel-doc warnings to placate scripts/kernel-doc.

timer-cadence-ttc.c:79: warning: Function parameter or member 'clk_rate_change_nb' not described in 'ttc_timer'
timer-cadence-ttc.c:158: warning: Function parameter or member 'cs' not described in '__ttc_clocksource_read'
timer-cadence-ttc.c:194: warning: expecting prototype for ttc_set_{shutdown|oneshot|periodic}(). Prototype was for ttc_shutdown() instead
timer-cadence-ttc.c:196: warning: No description found for return value of 'ttc_shutdown'
timer-cadence-ttc.c:212: warning: No description found for return value of 'ttc_set_periodic'

Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
Cc: Michal Simek <michal.simek at amd.com>
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/clocksource/timer-cadence-ttc.c |   22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff -- a/drivers/clocksource/timer-cadence-ttc.c b/drivers/clocksource/timer-cadence-ttc.c
--- a/drivers/clocksource/timer-cadence-ttc.c
+++ b/drivers/clocksource/timer-cadence-ttc.c
@@ -69,7 +69,7 @@
  * @base_addr:	Base address of timer
  * @freq:	Timer input clock frequency
  * @clk:	Associated clock source
- * @clk_rate_change_nb	Notifier block for clock rate changes
+ * @clk_rate_change_nb:	Notifier block for clock rate changes
  */
 struct ttc_timer {
 	void __iomem *base_addr;
@@ -134,7 +134,7 @@ static void ttc_set_interval(struct ttc_
  * @irq:	IRQ number of the Timer
  * @dev_id:	void pointer to the ttc_timer instance
  *
- * returns: Always IRQ_HANDLED - success
+ * Returns: Always IRQ_HANDLED - success
  **/
 static irqreturn_t ttc_clock_event_interrupt(int irq, void *dev_id)
 {
@@ -151,8 +151,9 @@ static irqreturn_t ttc_clock_event_inter
 
 /**
  * __ttc_clocksource_read - Reads the timer counter register
+ * @cs: &clocksource to read from
  *
- * returns: Current timer counter register value
+ * Returns: Current timer counter register value
  **/
 static u64 __ttc_clocksource_read(struct clocksource *cs)
 {
@@ -173,7 +174,7 @@ static u64 notrace ttc_sched_clock_read(
  * @cycles:	Timer interval ticks
  * @evt:	Address of clock event instance
  *
- * returns: Always 0 - success
+ * Returns: Always %0 - success
  **/
 static int ttc_set_next_event(unsigned long cycles,
 					struct clock_event_device *evt)
@@ -186,9 +187,12 @@ static int ttc_set_next_event(unsigned l
 }
 
 /**
- * ttc_set_{shutdown|oneshot|periodic} - Sets the state of timer
- *
+ * ttc_shutdown - Sets the state of timer
  * @evt:	Address of clock event instance
+ *
+ * Used for shutdown or oneshot.
+ *
+ * Returns: Always %0 - success
  **/
 static int ttc_shutdown(struct clock_event_device *evt)
 {
@@ -202,6 +206,12 @@ static int ttc_shutdown(struct clock_eve
 	return 0;
 }
 
+/**
+ * ttc_set_periodic - Sets the state of timer
+ * @evt:	Address of clock event instance
+ *
+ * Returns: Always %0 - success
+ */
 static int ttc_set_periodic(struct clock_event_device *evt)
 {
 	struct ttc_timer_clockevent *ttce = to_ttc_timer_clkevent(evt);


From bot at kernelci.org  Tue Dec  5 15:12:58 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Tue, 05 Dec 2023 15:12:58 -0800 (PST)
Subject: arm64/for-kernelci build: 1 build: 0 failed,
 1 passed (v6.7-rc4-20-gd46efae31672)
Message-ID: <656fae7a.170a0220.dc4df.f5e8@mx.google.com>

arm64/for-kernelci build: 1 build: 0 failed, 1 passed (v6.7-rc4-20-gd46efae31672)

Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v6.7-rc4-20-gd46efae31672/

Tree: arm64
Branch: for-kernelci
Git Describe: v6.7-rc4-20-gd46efae31672
Git Commit: d46efae31672cd1945e62f57e7eb660d75a95d36
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Built: 1 unique architecture

================================================================================

Detailed per-defconfig build reports:

--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) ? PASS, 0 errors, 0 warnings, 0 section mismatches

---
For more info write to <info at kernelci.org>


From jgg at nvidia.com  Tue Dec  5 15:53:31 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 5 Dec 2023 19:53:31 -0400
Subject: [PATCH v2 19/27] iommu/arm-smmu-v3: Keep track of
 arm_smmu_master_domain for SVA
In-Reply-To: <19-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
References: <0-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
 <19-v2-16665a652079+5947-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <20231205235331.GA2805372@nvidia.com>

On Wed, Nov 01, 2023 at 08:36:37PM -0300, Jason Gunthorpe wrote:
> Currently the smmu_domain->devices list is unused for SVA domains.
> Fill it in with the SSID and master of every arm_smmu_set_pasid()
> using the same logic as the RID attach.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
> ---
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 326c82fad90b8a..23bcdf1630c23e 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2712,6 +2712,8 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
>  	struct arm_smmu_domain *sid_smmu_domain =
>  		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
>  	struct arm_smmu_cd *cdptr;
> +	struct attach_state state;
> +	int ret;
>  
>  	if (!sid_smmu_domain || sid_smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
>  		return -ENODEV;
> @@ -2719,14 +2721,30 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
>  	cdptr = arm_smmu_get_cd_ptr(master, pasid);
>  	if (!cdptr)
>  		return -ENOMEM;
> +
> +	mutex_lock(&arm_smmu_asid_lock);
> +	ret = arm_smmu_attach_prepare(master, smmu_domain, pasid, &state);
> +	if (ret)
> +		goto out_unlock;
> +
>  	arm_smmu_write_cd_entry(master, pasid, cdptr, cd);
> +
> +	arm_smmu_attach_commit(master, pasid, &state);
> +
> +out_unlock:
> +	mutex_unlock(&arm_smmu_asid_lock);
>  	return 0;
>  }

This should be 'return ret'

Jason


From bot at kernelci.org  Tue Dec  5 15:56:17 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Tue, 05 Dec 2023 15:56:17 -0800 (PST)
Subject: arm64/for-kernelci baseline: 40 runs,
 1 regressions (v6.7-rc4-20-gd46efae31672)
Message-ID: <656fb8a1.170a0220.88853.4c3b@mx.google.com>

arm64/for-kernelci baseline: 40 runs, 1 regressions (v6.7-rc4-20-gd46efae31672)

Regressions Summary
-------------------

platform                 | arch  | lab             | compiler | defconfig | regressions
-------------------------+-------+-----------------+----------+-----------+------------
imx8mm-innocomm-wb15-evk | arm64 | lab-pengutronix | gcc-10   | defconfig | 1          

  Details:  https://kernelci.org/test/job/arm64/branch/for-kernelci/kernel/v6.7-rc4-20-gd46efae31672/plan/baseline/

  Test:     baseline
  Tree:     arm64
  Branch:   for-kernelci
  Describe: v6.7-rc4-20-gd46efae31672
  URL:      https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
  SHA:      d46efae31672cd1945e62f57e7eb660d75a95d36 


Test Regressions
---------------- 


platform                 | arch  | lab             | compiler | defconfig | regressions
-------------------------+-------+-----------------+----------+-----------+------------
imx8mm-innocomm-wb15-evk | arm64 | lab-pengutronix | gcc-10   | defconfig | 1          

  Details:     https://kernelci.org/test/plan/id/656fae92917a57a122e13495

  Results:     0 PASS, 1 FAIL, 0 SKIP
  Full config: defconfig
  Compiler:    gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
  Plain log:   https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc4-20-gd46efae31672/arm64/defconfig/gcc-10/lab-pengutronix/baseline-imx8mm-innocomm-wb15-evk.txt
  HTML log:    https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc4-20-gd46efae31672/arm64/defconfig/gcc-10/lab-pengutronix/baseline-imx8mm-innocomm-wb15-evk.html
  Rootfs:      http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230623.0/arm64/rootfs.cpio.gz 


  * baseline.login: https://kernelci.org/test/case/id/656fae92917a57a122e13496
        failing since 7 days (last pass: v6.6-rc7-89-g8de1e7afcc1c5, first fail: v6.7-rc3) 
  


From lkp at intel.com  Tue Dec  5 16:19:07 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 6 Dec 2023 08:19:07 +0800
Subject: [PATCH net-next 13/16] net: stmmac: intel: Register generic MDIO
 device
In-Reply-To: <20231205103559.9605-14-fancer.lancer@gmail.com>
References: <20231205103559.9605-14-fancer.lancer@gmail.com>
Message-ID: <202312060845.lDDRDWET-lkp@intel.com>

Hi Serge,

kernel test robot noticed the following build errors:

[auto build test ERROR on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Serge-Semin/net-pcs-xpcs-Drop-sentinel-entry-from-2500basex-ifaces-list/20231205-183808
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231205103559.9605-14-fancer.lancer%40gmail.com
patch subject: [PATCH net-next 13/16] net: stmmac: intel: Register generic MDIO device
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20231206/202312060845.lDDRDWET-lkp at intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231206/202312060845.lDDRDWET-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312060845.lDDRDWET-lkp at intel.com/

All errors (new ones prefixed by >>):

   drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c: In function 'intel_mgbe_common_data':
>> drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:646:31: error: 'clk' undeclared (first use in this function)
     646 |         clk_disable_unprepare(clk);
         |                               ^~~
   drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:646:31: note: each undeclared identifier is reported only once for each function it appears in


vim +/clk +646 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c

   446	
   447	static int intel_mgbe_common_data(struct pci_dev *pdev,
   448					  struct plat_stmmacenet_data *plat)
   449	{
   450		struct fwnode_handle *fwnode;
   451		char clk_name[20];
   452		int ret;
   453		int i;
   454	
   455		plat->pdev = pdev;
   456		plat->phy_addr = -1;
   457		plat->clk_csr = 5;
   458		plat->has_gmac = 0;
   459		plat->has_gmac4 = 1;
   460		plat->force_sf_dma_mode = 0;
   461		plat->flags |= (STMMAC_FLAG_TSO_EN | STMMAC_FLAG_SPH_DISABLE);
   462	
   463		/* Multiplying factor to the clk_eee_i clock time
   464		 * period to make it closer to 100 ns. This value
   465		 * should be programmed such that the clk_eee_time_period *
   466		 * (MULT_FACT_100NS + 1) should be within 80 ns to 120 ns
   467		 * clk_eee frequency is 19.2Mhz
   468		 * clk_eee_time_period is 52ns
   469		 * 52ns * (1 + 1) = 104ns
   470		 * MULT_FACT_100NS = 1
   471		 */
   472		plat->mult_fact_100ns = 1;
   473	
   474		plat->rx_sched_algorithm = MTL_RX_ALGORITHM_SP;
   475	
   476		for (i = 0; i < plat->rx_queues_to_use; i++) {
   477			plat->rx_queues_cfg[i].mode_to_use = MTL_QUEUE_DCB;
   478			plat->rx_queues_cfg[i].chan = i;
   479	
   480			/* Disable Priority config by default */
   481			plat->rx_queues_cfg[i].use_prio = false;
   482	
   483			/* Disable RX queues routing by default */
   484			plat->rx_queues_cfg[i].pkt_route = 0x0;
   485		}
   486	
   487		for (i = 0; i < plat->tx_queues_to_use; i++) {
   488			plat->tx_queues_cfg[i].mode_to_use = MTL_QUEUE_DCB;
   489	
   490			/* Disable Priority config by default */
   491			plat->tx_queues_cfg[i].use_prio = false;
   492			/* Default TX Q0 to use TSO and rest TXQ for TBS */
   493			if (i > 0)
   494				plat->tx_queues_cfg[i].tbs_en = 1;
   495		}
   496	
   497		/* FIFO size is 4096 bytes for 1 tx/rx queue */
   498		plat->tx_fifo_size = plat->tx_queues_to_use * 4096;
   499		plat->rx_fifo_size = plat->rx_queues_to_use * 4096;
   500	
   501		plat->tx_sched_algorithm = MTL_TX_ALGORITHM_WRR;
   502		plat->tx_queues_cfg[0].weight = 0x09;
   503		plat->tx_queues_cfg[1].weight = 0x0A;
   504		plat->tx_queues_cfg[2].weight = 0x0B;
   505		plat->tx_queues_cfg[3].weight = 0x0C;
   506		plat->tx_queues_cfg[4].weight = 0x0D;
   507		plat->tx_queues_cfg[5].weight = 0x0E;
   508		plat->tx_queues_cfg[6].weight = 0x0F;
   509		plat->tx_queues_cfg[7].weight = 0x10;
   510	
   511		plat->dma_cfg->pbl = 32;
   512		plat->dma_cfg->pblx8 = true;
   513		plat->dma_cfg->fixed_burst = 0;
   514		plat->dma_cfg->mixed_burst = 0;
   515		plat->dma_cfg->aal = 0;
   516		plat->dma_cfg->dche = true;
   517	
   518		plat->axi = devm_kzalloc(&pdev->dev, sizeof(*plat->axi),
   519					 GFP_KERNEL);
   520		if (!plat->axi)
   521			return -ENOMEM;
   522	
   523		plat->axi->axi_lpi_en = 0;
   524		plat->axi->axi_xit_frm = 0;
   525		plat->axi->axi_wr_osr_lmt = 1;
   526		plat->axi->axi_rd_osr_lmt = 1;
   527		plat->axi->axi_blen[0] = 4;
   528		plat->axi->axi_blen[1] = 8;
   529		plat->axi->axi_blen[2] = 16;
   530	
   531		plat->ptp_max_adj = plat->clk_ptp_rate;
   532		plat->eee_usecs_rate = plat->clk_ptp_rate;
   533	
   534		/* Set system clock */
   535		sprintf(clk_name, "%s-%s", "stmmac", pci_name(pdev));
   536	
   537		plat->stmmac_clk = clk_register_fixed_rate(&pdev->dev,
   538							   clk_name, NULL, 0,
   539							   plat->clk_ptp_rate);
   540	
   541		if (IS_ERR(plat->stmmac_clk)) {
   542			dev_warn(&pdev->dev, "Fail to register stmmac-clk\n");
   543			plat->stmmac_clk = NULL;
   544		}
   545	
   546		ret = clk_prepare_enable(plat->stmmac_clk);
   547		if (ret) {
   548			clk_unregister_fixed_rate(plat->stmmac_clk);
   549			return ret;
   550		}
   551	
   552		plat->ptp_clk_freq_config = intel_mgbe_ptp_clk_freq_config;
   553	
   554		/* Set default value for multicast hash bins */
   555		plat->multicast_filter_bins = HASH_TABLE_SIZE;
   556	
   557		/* Set default value for unicast filter entries */
   558		plat->unicast_filter_entries = 1;
   559	
   560		/* Set the maxmtu to a default of JUMBO_LEN */
   561		plat->maxmtu = JUMBO_LEN;
   562	
   563		plat->flags |= STMMAC_FLAG_VLAN_FAIL_Q_EN;
   564	
   565		/* Use the last Rx queue */
   566		plat->vlan_fail_q = plat->rx_queues_to_use - 1;
   567	
   568		/* For fixed-link setup, we allow phy-mode setting */
   569		fwnode = dev_fwnode(&pdev->dev);
   570		if (fwnode) {
   571			int phy_mode;
   572	
   573			/* "phy-mode" setting is optional. If it is set,
   574			 *  we allow either sgmii or 1000base-x for now.
   575			 */
   576			phy_mode = fwnode_get_phy_mode(fwnode);
   577			if (phy_mode >= 0) {
   578				if (phy_mode == PHY_INTERFACE_MODE_SGMII ||
   579				    phy_mode == PHY_INTERFACE_MODE_1000BASEX)
   580					plat->phy_interface = phy_mode;
   581				else
   582					dev_warn(&pdev->dev, "Invalid phy-mode\n");
   583			}
   584		}
   585	
   586		/* Intel mgbe SGMII interface uses pcs-xcps */
   587		if (plat->phy_interface == PHY_INTERFACE_MODE_SGMII ||
   588		    plat->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
   589			struct mdio_board_info *xpcs_info;
   590	
   591			xpcs_info = devm_kzalloc(&pdev->dev,
   592						 sizeof(*xpcs_info) + MII_BUS_ID_SIZE,
   593						 GFP_KERNEL);
   594			if (!xpcs_info) {
   595				ret = -ENOMEM;
   596				goto err_alloc_info;
   597			}
   598	
   599			xpcs_info->bus_id = (void *)xpcs_info + sizeof(*xpcs_info);
   600			snprintf((char *)xpcs_info->bus_id, MII_BUS_ID_SIZE,
   601				 "stmmac-%x", plat->bus_id);
   602	
   603			snprintf(xpcs_info->modalias, MDIO_NAME_SIZE, "dwxpcs");
   604	
   605			xpcs_info->mdio_addr = INTEL_MGBE_XPCS_ADDR;
   606	
   607			ret = mdiobus_register_board_info(xpcs_info, 1);
   608			if (ret)
   609				goto err_alloc_info;
   610	
   611			plat->mdio_bus_data->has_xpcs = true;
   612			plat->mdio_bus_data->xpcs_an_inband = true;
   613		}
   614	
   615		/* For fixed-link setup, we clear xpcs_an_inband */
   616		if (fwnode) {
   617			struct fwnode_handle *fixed_node;
   618	
   619			fixed_node = fwnode_get_named_child_node(fwnode, "fixed-link");
   620			if (fixed_node)
   621				plat->mdio_bus_data->xpcs_an_inband = false;
   622	
   623			fwnode_handle_put(fixed_node);
   624		}
   625	
   626		/* Ensure mdio bus PHY-scan skips intel serdes and pcs-xpcs */
   627		plat->mdio_bus_data->phy_mask = 1 << INTEL_MGBE_ADHOC_ADDR;
   628		plat->mdio_bus_data->phy_mask |= 1 << INTEL_MGBE_XPCS_ADDR;
   629	
   630		plat->int_snapshot_num = AUX_SNAPSHOT1;
   631	
   632		plat->crosststamp = intel_crosststamp;
   633		plat->flags &= ~STMMAC_FLAG_INT_SNAPSHOT_EN;
   634	
   635		/* Setup MSI vector offset specific to Intel mGbE controller */
   636		plat->msi_mac_vec = 29;
   637		plat->msi_lpi_vec = 28;
   638		plat->msi_sfty_ce_vec = 27;
   639		plat->msi_sfty_ue_vec = 26;
   640		plat->msi_rx_base_vec = 0;
   641		plat->msi_tx_base_vec = 1;
   642	
   643		return 0;
   644	
   645	err_alloc_info:
 > 646		clk_disable_unprepare(clk);
   647		clk_unregister_fixed_rate(clk);
   648	
   649		return ret;
   650	}
   651	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Tue Dec  5 16:29:36 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 6 Dec 2023 08:29:36 +0800
Subject: [PATCH net-next 11/16] net: pcs: xpcs: Change
 xpcs_create_mdiodev() suffix to "byaddr"
In-Reply-To: <20231205103559.9605-12-fancer.lancer@gmail.com>
References: <20231205103559.9605-12-fancer.lancer@gmail.com>
Message-ID: <202312060843.C3pV7P8b-lkp@intel.com>

Hi Serge,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Serge-Semin/net-pcs-xpcs-Drop-sentinel-entry-from-2500basex-ifaces-list/20231205-183808
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231205103559.9605-12-fancer.lancer%40gmail.com
patch subject: [PATCH net-next 11/16] net: pcs: xpcs: Change xpcs_create_mdiodev() suffix to "byaddr"
config: x86_64-randconfig-006-20231206 (https://download.01.org/0day-ci/archive/20231206/202312060843.C3pV7P8b-lkp at intel.com/config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231206/202312060843.C3pV7P8b-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312060843.C3pV7P8b-lkp at intel.com/

All warnings (new ones prefixed by >>):

   drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c: In function 'txgbe_mdio_pcs_init':
   drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c:150:9: error: implicit declaration of function 'xpcs_create_mdiodev'; did you mean 'xpcs_create_byaddr'? [-Werror=implicit-function-declaration]
     xpcs = xpcs_create_mdiodev(mii_bus, 0, PHY_INTERFACE_MODE_10GBASER);
            ^~~~~~~~~~~~~~~~~~~
            xpcs_create_byaddr
>> drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c:150:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     xpcs = xpcs_create_mdiodev(mii_bus, 0, PHY_INTERFACE_MODE_10GBASER);
          ^
   cc1: some warnings being treated as errors


vim +150 drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c

854cace61387b6 Jiawen Wu      2023-06-06  121  
854cace61387b6 Jiawen Wu      2023-06-06  122  static int txgbe_mdio_pcs_init(struct txgbe *txgbe)
854cace61387b6 Jiawen Wu      2023-06-06  123  {
854cace61387b6 Jiawen Wu      2023-06-06  124  	struct mii_bus *mii_bus;
854cace61387b6 Jiawen Wu      2023-06-06  125  	struct dw_xpcs *xpcs;
854cace61387b6 Jiawen Wu      2023-06-06  126  	struct pci_dev *pdev;
854cace61387b6 Jiawen Wu      2023-06-06  127  	struct wx *wx;
854cace61387b6 Jiawen Wu      2023-06-06  128  	int ret = 0;
854cace61387b6 Jiawen Wu      2023-06-06  129  
854cace61387b6 Jiawen Wu      2023-06-06  130  	wx = txgbe->wx;
854cace61387b6 Jiawen Wu      2023-06-06  131  	pdev = wx->pdev;
854cace61387b6 Jiawen Wu      2023-06-06  132  
854cace61387b6 Jiawen Wu      2023-06-06  133  	mii_bus = devm_mdiobus_alloc(&pdev->dev);
854cace61387b6 Jiawen Wu      2023-06-06  134  	if (!mii_bus)
854cace61387b6 Jiawen Wu      2023-06-06  135  		return -ENOMEM;
854cace61387b6 Jiawen Wu      2023-06-06  136  
854cace61387b6 Jiawen Wu      2023-06-06  137  	mii_bus->name = "txgbe_pcs_mdio_bus";
854cace61387b6 Jiawen Wu      2023-06-06  138  	mii_bus->read_c45 = &txgbe_pcs_read;
854cace61387b6 Jiawen Wu      2023-06-06  139  	mii_bus->write_c45 = &txgbe_pcs_write;
854cace61387b6 Jiawen Wu      2023-06-06  140  	mii_bus->parent = &pdev->dev;
854cace61387b6 Jiawen Wu      2023-06-06  141  	mii_bus->phy_mask = ~0;
854cace61387b6 Jiawen Wu      2023-06-06  142  	mii_bus->priv = wx;
854cace61387b6 Jiawen Wu      2023-06-06  143  	snprintf(mii_bus->id, MII_BUS_ID_SIZE, "txgbe_pcs-%x",
d8c21ef7b2b147 Xiongfeng Wang 2023-08-08  144  		 pci_dev_id(pdev));
854cace61387b6 Jiawen Wu      2023-06-06  145  
854cace61387b6 Jiawen Wu      2023-06-06  146  	ret = devm_mdiobus_register(&pdev->dev, mii_bus);
854cace61387b6 Jiawen Wu      2023-06-06  147  	if (ret)
854cace61387b6 Jiawen Wu      2023-06-06  148  		return ret;
854cace61387b6 Jiawen Wu      2023-06-06  149  
854cace61387b6 Jiawen Wu      2023-06-06 @150  	xpcs = xpcs_create_mdiodev(mii_bus, 0, PHY_INTERFACE_MODE_10GBASER);
854cace61387b6 Jiawen Wu      2023-06-06  151  	if (IS_ERR(xpcs))
854cace61387b6 Jiawen Wu      2023-06-06  152  		return PTR_ERR(xpcs);
854cace61387b6 Jiawen Wu      2023-06-06  153  
854cace61387b6 Jiawen Wu      2023-06-06  154  	txgbe->xpcs = xpcs;
854cace61387b6 Jiawen Wu      2023-06-06  155  
854cace61387b6 Jiawen Wu      2023-06-06  156  	return 0;
854cace61387b6 Jiawen Wu      2023-06-06  157  }
854cace61387b6 Jiawen Wu      2023-06-06  158  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From shawnguo at kernel.org  Tue Dec  5 16:49:28 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 08:49:28 +0800
Subject: [PATCH v5 0/3] board: imx8mn-rve-gateway: add support for RVE
 gateway board
In-Reply-To: <20231205150814.344883-1-hugo@hugovil.com>
References: <20231205150814.344883-1-hugo@hugovil.com>
Message-ID: <20231206004928.GJ236001@dragon>

On Tue, Dec 05, 2023 at 10:08:11AM -0500, Hugo Villeneuve wrote:
> Hugo Villeneuve (3):
>   dt-bindings: vendor-prefixes: add rve
>   dt-bindings: arm: fsl: add RVE gateway board
>   arm64: dts: freescale: introduce rve-gateway board

Applied all, thanks!


From shawnguo at kernel.org  Tue Dec  5 16:50:33 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 08:50:33 +0800
Subject: [PATCH v2] arm64: dts: imx8mn-var-som-symphony: add vcc supply
 for PCA9534
In-Reply-To: <20231107155040.1644169-1-hugo@hugovil.com>
References: <20231107155040.1644169-1-hugo@hugovil.com>
Message-ID: <20231206005033.GK236001@dragon>

On Tue, Nov 07, 2023 at 10:50:40AM -0500, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> 
> The following warning is shown when probing device:
> 
>     pca953x 1-0020: supply vcc not found, using dummy regulator
> 
> Define a new fixed 3.3v regulator for carrier board peripherals,
> enabled by mosfet switch Q2 after the SOM_3V3 supply rises (no software
> control).
> 
> Add this new regulator as vcc supply to the PCA9534 to silence the warning.
> 
> Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Applied, thanks!


From daniel at makrotopia.org  Tue Dec  5 16:55:44 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 00:55:44 +0000
Subject: [PATCH v3 1/4] dt-bindings: clock: mediatek: add MT7988 clock IDs
Message-ID: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add MT7988 clock dt-bindings for topckgen, apmixedsys, infracfg,
ethernet and xfipll subsystem clocks.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v3: no changes
v2: fix indentation

 .../dt-bindings/clock/mediatek,mt7988-clk.h   | 280 ++++++++++++++++++
 1 file changed, 280 insertions(+)
 create mode 100644 include/dt-bindings/clock/mediatek,mt7988-clk.h

diff --git a/include/dt-bindings/clock/mediatek,mt7988-clk.h b/include/dt-bindings/clock/mediatek,mt7988-clk.h
new file mode 100644
index 0000000000000..63376e40f14d2
--- /dev/null
+++ b/include/dt-bindings/clock/mediatek,mt7988-clk.h
@@ -0,0 +1,280 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#ifndef _DT_BINDINGS_CLK_MT7988_H
+#define _DT_BINDINGS_CLK_MT7988_H
+
+/* APMIXEDSYS */
+
+#define CLK_APMIXED_NETSYSPLL			0
+#define CLK_APMIXED_MPLL			1
+#define CLK_APMIXED_MMPLL			2
+#define CLK_APMIXED_APLL2			3
+#define CLK_APMIXED_NET1PLL			4
+#define CLK_APMIXED_NET2PLL			5
+#define CLK_APMIXED_WEDMCUPLL			6
+#define CLK_APMIXED_SGMPLL			7
+#define CLK_APMIXED_ARM_B			8
+#define CLK_APMIXED_CCIPLL2_B			9
+#define CLK_APMIXED_USXGMIIPLL			10
+#define CLK_APMIXED_MSDCPLL			11
+
+/* TOPCKGEN */
+
+#define CLK_TOP_XTAL				0
+#define CLK_TOP_XTAL_D2				1
+#define CLK_TOP_RTC_32K				2
+#define CLK_TOP_RTC_32P7K			3
+#define CLK_TOP_MPLL_D2				4
+#define CLK_TOP_MPLL_D3_D2			5
+#define CLK_TOP_MPLL_D4				6
+#define CLK_TOP_MPLL_D8				7
+#define CLK_TOP_MPLL_D8_D2			8
+#define CLK_TOP_MMPLL_D2			9
+#define CLK_TOP_MMPLL_D3_D5			10
+#define CLK_TOP_MMPLL_D4			11
+#define CLK_TOP_MMPLL_D6_D2			12
+#define CLK_TOP_MMPLL_D8			13
+#define CLK_TOP_APLL2_D4			14
+#define CLK_TOP_NET1PLL_D4			15
+#define CLK_TOP_NET1PLL_D5			16
+#define CLK_TOP_NET1PLL_D5_D2			17
+#define CLK_TOP_NET1PLL_D5_D4			18
+#define CLK_TOP_NET1PLL_D8			19
+#define CLK_TOP_NET1PLL_D8_D2			20
+#define CLK_TOP_NET1PLL_D8_D4			21
+#define CLK_TOP_NET1PLL_D8_D8			22
+#define CLK_TOP_NET1PLL_D8_D16			23
+#define CLK_TOP_NET2PLL_D2			24
+#define CLK_TOP_NET2PLL_D4			25
+#define CLK_TOP_NET2PLL_D4_D4			26
+#define CLK_TOP_NET2PLL_D4_D8			27
+#define CLK_TOP_NET2PLL_D6			28
+#define CLK_TOP_NET2PLL_D8			29
+#define CLK_TOP_NETSYS_SEL			30
+#define CLK_TOP_NETSYS_500M_SEL			31
+#define CLK_TOP_NETSYS_2X_SEL			32
+#define CLK_TOP_NETSYS_GSW_SEL			33
+#define CLK_TOP_ETH_GMII_SEL			34
+#define CLK_TOP_NETSYS_MCU_SEL			35
+#define CLK_TOP_NETSYS_PAO_2X_SEL		36
+#define CLK_TOP_EIP197_SEL			37
+#define CLK_TOP_AXI_INFRA_SEL			38
+#define CLK_TOP_UART_SEL			39
+#define CLK_TOP_EMMC_250M_SEL			40
+#define CLK_TOP_EMMC_400M_SEL			41
+#define CLK_TOP_SPI_SEL				42
+#define CLK_TOP_SPIM_MST_SEL			43
+#define CLK_TOP_NFI1X_SEL			44
+#define CLK_TOP_SPINFI_SEL			45
+#define CLK_TOP_PWM_SEL				46
+#define CLK_TOP_I2C_SEL				47
+#define CLK_TOP_PCIE_MBIST_250M_SEL		48
+#define CLK_TOP_PEXTP_TL_SEL			49
+#define CLK_TOP_PEXTP_TL_P1_SEL			50
+#define CLK_TOP_PEXTP_TL_P2_SEL			51
+#define CLK_TOP_PEXTP_TL_P3_SEL			52
+#define CLK_TOP_USB_SYS_SEL			53
+#define CLK_TOP_USB_SYS_P1_SEL			54
+#define CLK_TOP_USB_XHCI_SEL			55
+#define CLK_TOP_USB_XHCI_P1_SEL			56
+#define CLK_TOP_USB_FRMCNT_SEL			57
+#define CLK_TOP_USB_FRMCNT_P1_SEL		58
+#define CLK_TOP_AUD_SEL				59
+#define CLK_TOP_A1SYS_SEL			60
+#define CLK_TOP_AUD_L_SEL			61
+#define CLK_TOP_A_TUNER_SEL			62
+#define CLK_TOP_SSPXTP_SEL			63
+#define CLK_TOP_USB_PHY_SEL			64
+#define CLK_TOP_USXGMII_SBUS_0_SEL		65
+#define CLK_TOP_USXGMII_SBUS_1_SEL		66
+#define CLK_TOP_SGM_0_SEL			67
+#define CLK_TOP_SGM_SBUS_0_SEL			68
+#define CLK_TOP_SGM_1_SEL			69
+#define CLK_TOP_SGM_SBUS_1_SEL			70
+#define CLK_TOP_XFI_PHY_0_XTAL_SEL		71
+#define CLK_TOP_XFI_PHY_1_XTAL_SEL		72
+#define CLK_TOP_SYSAXI_SEL			73
+#define CLK_TOP_SYSAPB_SEL			74
+#define CLK_TOP_ETH_REFCK_50M_SEL		75
+#define CLK_TOP_ETH_SYS_200M_SEL		76
+#define CLK_TOP_ETH_SYS_SEL			77
+#define CLK_TOP_ETH_XGMII_SEL			78
+#define CLK_TOP_BUS_TOPS_SEL			79
+#define CLK_TOP_NPU_TOPS_SEL			80
+#define CLK_TOP_DRAMC_SEL			81
+#define CLK_TOP_DRAMC_MD32_SEL			82
+#define CLK_TOP_INFRA_F26M_SEL			83
+#define CLK_TOP_PEXTP_P0_SEL			84
+#define CLK_TOP_PEXTP_P1_SEL			85
+#define CLK_TOP_PEXTP_P2_SEL			86
+#define CLK_TOP_PEXTP_P3_SEL			87
+#define CLK_TOP_DA_XTP_GLB_P0_SEL		88
+#define CLK_TOP_DA_XTP_GLB_P1_SEL		89
+#define CLK_TOP_DA_XTP_GLB_P2_SEL		90
+#define CLK_TOP_DA_XTP_GLB_P3_SEL		91
+#define CLK_TOP_CKM_SEL				92
+#define CLK_TOP_DA_SEL				93
+#define CLK_TOP_PEXTP_SEL			94
+#define CLK_TOP_TOPS_P2_26M_SEL			95
+#define CLK_TOP_MCUSYS_BACKUP_625M_SEL		96
+#define CLK_TOP_NETSYS_SYNC_250M_SEL		97
+#define CLK_TOP_MACSEC_SEL			98
+#define CLK_TOP_NETSYS_TOPS_400M_SEL		99
+#define CLK_TOP_NETSYS_PPEFB_250M_SEL		100
+#define CLK_TOP_NETSYS_WARP_SEL			101
+#define CLK_TOP_ETH_MII_SEL			102
+#define CLK_TOP_NPU_SEL				103
+#define CLK_TOP_AUD_I2S_M			104
+
+/* MCUSYS */
+
+#define CLK_MCU_BUS_DIV_SEL			0
+#define CLK_MCU_ARM_DIV_SEL			1
+
+/* INFRACFG_AO */
+
+#define CLK_INFRA_MUX_UART0_SEL			0
+#define CLK_INFRA_MUX_UART1_SEL			1
+#define CLK_INFRA_MUX_UART2_SEL			2
+#define CLK_INFRA_MUX_SPI0_SEL			3
+#define CLK_INFRA_MUX_SPI1_SEL			4
+#define CLK_INFRA_MUX_SPI2_SEL			5
+#define CLK_INFRA_PWM_SEL			6
+#define CLK_INFRA_PWM_CK1_SEL			7
+#define CLK_INFRA_PWM_CK2_SEL			8
+#define CLK_INFRA_PWM_CK3_SEL			9
+#define CLK_INFRA_PWM_CK4_SEL			10
+#define CLK_INFRA_PWM_CK5_SEL			11
+#define CLK_INFRA_PWM_CK6_SEL			12
+#define CLK_INFRA_PWM_CK7_SEL			13
+#define CLK_INFRA_PWM_CK8_SEL			14
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL	15
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL	16
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL	17
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL	18
+
+/* INFRACFG */
+
+#define CLK_INFRA_PCIE_PERI_26M_CK_P0		19
+#define CLK_INFRA_PCIE_PERI_26M_CK_P1		20
+#define CLK_INFRA_PCIE_PERI_26M_CK_P2		21
+#define CLK_INFRA_PCIE_PERI_26M_CK_P3		22
+#define CLK_INFRA_66M_GPT_BCK			23
+#define CLK_INFRA_66M_PWM_HCK			24
+#define CLK_INFRA_66M_PWM_BCK			25
+#define CLK_INFRA_66M_PWM_CK1			26
+#define CLK_INFRA_66M_PWM_CK2			27
+#define CLK_INFRA_66M_PWM_CK3			28
+#define CLK_INFRA_66M_PWM_CK4			29
+#define CLK_INFRA_66M_PWM_CK5			30
+#define CLK_INFRA_66M_PWM_CK6			31
+#define CLK_INFRA_66M_PWM_CK7			32
+#define CLK_INFRA_66M_PWM_CK8			33
+#define CLK_INFRA_133M_CQDMA_BCK		34
+#define CLK_INFRA_66M_AUD_SLV_BCK		35
+#define CLK_INFRA_AUD_26M			36
+#define CLK_INFRA_AUD_L				37
+#define CLK_INFRA_AUD_AUD			38
+#define CLK_INFRA_AUD_EG2			39
+#define CLK_INFRA_DRAMC_F26M			40
+#define CLK_INFRA_133M_DBG_ACKM			41
+#define CLK_INFRA_66M_AP_DMA_BCK		42
+#define CLK_INFRA_66M_SEJ_BCK			43
+#define CLK_INFRA_PRE_CK_SEJ_F13M		44
+#define CLK_INFRA_26M_THERM_SYSTEM		45
+#define CLK_INFRA_I2C_BCK			46
+#define CLK_INFRA_52M_UART0_CK			47
+#define CLK_INFRA_52M_UART1_CK			48
+#define CLK_INFRA_52M_UART2_CK			49
+#define CLK_INFRA_NFI				50
+#define CLK_INFRA_SPINFI			51
+#define CLK_INFRA_66M_NFI_HCK			52
+#define CLK_INFRA_104M_SPI0			53
+#define CLK_INFRA_104M_SPI1			54
+#define CLK_INFRA_104M_SPI2_BCK			55
+#define CLK_INFRA_66M_SPI0_HCK			56
+#define CLK_INFRA_66M_SPI1_HCK			57
+#define CLK_INFRA_66M_SPI2_HCK			58
+#define CLK_INFRA_66M_FLASHIF_AXI		59
+#define CLK_INFRA_RTC				60
+#define CLK_INFRA_26M_ADC_BCK			61
+#define CLK_INFRA_RC_ADC			62
+#define CLK_INFRA_MSDC400			63
+#define CLK_INFRA_MSDC2_HCK			64
+#define CLK_INFRA_133M_MSDC_0_HCK		65
+#define CLK_INFRA_66M_MSDC_0_HCK		66
+#define CLK_INFRA_133M_CPUM_BCK			67
+#define CLK_INFRA_BIST2FPC			68
+#define CLK_INFRA_I2C_X16W_MCK_CK_P1		69
+#define CLK_INFRA_I2C_X16W_PCK_CK_P1		70
+#define CLK_INFRA_133M_USB_HCK			71
+#define CLK_INFRA_133M_USB_HCK_CK_P1		72
+#define CLK_INFRA_66M_USB_HCK			73
+#define CLK_INFRA_66M_USB_HCK_CK_P1		74
+#define CLK_INFRA_USB_SYS			75
+#define CLK_INFRA_USB_SYS_CK_P1			76
+#define CLK_INFRA_USB_REF			77
+#define CLK_INFRA_USB_CK_P1			78
+#define CLK_INFRA_USB_FRMCNT			79
+#define CLK_INFRA_USB_FRMCNT_CK_P1		80
+#define CLK_INFRA_USB_PIPE			81
+#define CLK_INFRA_USB_PIPE_CK_P1		82
+#define CLK_INFRA_USB_UTMI			83
+#define CLK_INFRA_USB_UTMI_CK_P1		84
+#define CLK_INFRA_USB_XHCI			85
+#define CLK_INFRA_USB_XHCI_CK_P1		86
+#define CLK_INFRA_PCIE_GFMUX_TL_P0		87
+#define CLK_INFRA_PCIE_GFMUX_TL_P1		88
+#define CLK_INFRA_PCIE_GFMUX_TL_P2		89
+#define CLK_INFRA_PCIE_GFMUX_TL_P3		90
+#define CLK_INFRA_PCIE_PIPE_P0			91
+#define CLK_INFRA_PCIE_PIPE_P1			92
+#define CLK_INFRA_PCIE_PIPE_P2			93
+#define CLK_INFRA_PCIE_PIPE_P3			94
+#define CLK_INFRA_133M_PCIE_CK_P0		95
+#define CLK_INFRA_133M_PCIE_CK_P1		96
+#define CLK_INFRA_133M_PCIE_CK_P2		97
+#define CLK_INFRA_133M_PCIE_CK_P3		98
+
+/* ETHDMA */
+
+#define CLK_ETHDMA_XGP1_EN			0
+#define CLK_ETHDMA_XGP2_EN			1
+#define CLK_ETHDMA_XGP3_EN			2
+#define CLK_ETHDMA_FE_EN			3
+#define CLK_ETHDMA_GP2_EN			4
+#define CLK_ETHDMA_GP1_EN			5
+#define CLK_ETHDMA_GP3_EN			6
+#define CLK_ETHDMA_ESW_EN			7
+#define CLK_ETHDMA_CRYPT0_EN			8
+#define CLK_ETHDMA_NR_CLK			9
+
+/* SGMIISYS_0 */
+
+#define CLK_SGM0_TX_EN				0
+#define CLK_SGM0_RX_EN				1
+#define CLK_SGMII0_NR_CLK			2
+
+/* SGMIISYS_1 */
+
+#define CLK_SGM1_TX_EN				0
+#define CLK_SGM1_RX_EN				1
+#define CLK_SGMII1_NR_CLK			2
+
+/* ETHWARP */
+
+#define CLK_ETHWARP_WOCPU2_EN			0
+#define CLK_ETHWARP_WOCPU1_EN			1
+#define CLK_ETHWARP_WOCPU0_EN			2
+#define CLK_ETHWARP_NR_CLK			3
+
+/* XFIPLL */
+#define CLK_XFIPLL_PLL				0
+#define CLK_XFIPLL_PLL_EN			1
+
+#endif /* _DT_BINDINGS_CLK_MT7988_H */
-- 
2.43.0


From shawnguo at kernel.org  Tue Dec  5 16:57:04 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 08:57:04 +0800
Subject: [PATCH] arm64: dts: imx8qm: Add imx8qm's own pm to avoid panic
 during startup
In-Reply-To: <20231110072531.1957891-1-xiaolei.wang@windriver.com>
References: <20231110072531.1957891-1-xiaolei.wang@windriver.com>
Message-ID: <20231206005704.GL236001@dragon>

On Fri, Nov 10, 2023 at 03:25:31PM +0800, Xiaolei Wang wrote:
> Add imx8qm's own pm, otherwise the following panic will
> occur during the startup process:
> 
>  Kernel panic - not syncing: Asynchronous SError Interrupt
>  Hardware name: Freescale i.MX8QM MEK (DT)
>  Workqueue: events_unbound deferred_probe_work_func
>  Call trace:
>   dump_backtrace+0x98/0xf0
>   show_stack+0x18/0x24
>   dump_stack_lvl+0x60/0xac
>   dump_stack+0x18/0x24
>   panic+0x340/0x3a0
>   nmi_panic+0x8c/0x90
>   arm64_serror_panic+0x6c/0x78
>   do_serror+0x3c/0x78
>   el1h_64_error_handler+0x38/0x50
>   el1h_64_error+0x64/0x68
>   fsl_edma_chan_mux+0x98/0xdc
>   fsl_edma_probe+0x278/0x898
>   platform_probe+0x68/0xd8
>   really_probe+0x110/0x27c
>   __driver_probe_device+0x78/0x12c
>   driver_probe_device+0x3c/0x118
>   __device_attach_driver+0xb8/0xf8
>   bus_for_each_drv+0x84/0xe4
>   __device_attach+0xfc/0x18c
>   device_initial_probe+0x14/0x20
> 
> Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]")
> Signed-off-by: Xiaolei Wang <xiaolei.wang at windriver.com>

Applied, thanks!


From daniel at makrotopia.org  Tue Dec  5 16:57:04 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 00:57:04 +0000
Subject: [PATCH v3 2/4] dt-bindings: clock: mediatek: add clock controllers
 of MT7988
In-Reply-To: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
Message-ID: <def05aac79ddff872d3e56698b736cb445f14116.1701823757.git.daniel@makrotopia.org>

Add various clock controllers found in the MT7988 SoC to existing
bindings (if applicable) and add files for the new ethwarp, mcusys
and xfi-pll clock controllers not previously present in any SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v3:
 * move clock bindings to clock folder
 * drop ti,syscon-reset from bindings and example
 * merge mcusys with topckgen bindings

v2:
 * dropped unused labels
 * add 'type: object' declaration for reset-controller found in new
   ethwarp controller and represented as ti,syscon-reset
 * rebase on top of
   "dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema"

 .../arm/mediatek/mediatek,infracfg.yaml       |  1 +
 .../bindings/clock/mediatek,apmixedsys.yaml   |  1 +
 .../bindings/clock/mediatek,ethsys.yaml       |  1 +
 .../clock/mediatek,mt7988-ethwarp.yaml        | 49 +++++++++++++++++++
 .../clock/mediatek,mt7988-xfi-pll.yaml        | 48 ++++++++++++++++++
 .../bindings/clock/mediatek,topckgen.yaml     |  2 +
 .../bindings/net/pcs/mediatek,sgmiisys.yaml   | 13 +++--
 7 files changed, 112 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
index ea98043c6ba3d..230b5188a88db 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
@@ -30,6 +30,7 @@ properties:
               - mediatek,mt7629-infracfg
               - mediatek,mt7981-infracfg
               - mediatek,mt7986-infracfg
+              - mediatek,mt7988-infracfg
               - mediatek,mt8135-infracfg
               - mediatek,mt8167-infracfg
               - mediatek,mt8173-infracfg
diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
index 372c1d744bc27..685535846cbb7 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
@@ -22,6 +22,7 @@ properties:
           - mediatek,mt7622-apmixedsys
           - mediatek,mt7981-apmixedsys
           - mediatek,mt7986-apmixedsys
+          - mediatek,mt7988-apmixedsys
           - mediatek,mt8135-apmixedsys
           - mediatek,mt8173-apmixedsys
           - mediatek,mt8516-apmixedsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
index 94d42c8647777..f9cddacc2eae1 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
@@ -22,6 +22,7 @@ properties:
               - mediatek,mt7629-ethsys
               - mediatek,mt7981-ethsys
               - mediatek,mt7986-ethsys
+              - mediatek,mt7988-ethsys
           - const: syscon
       - items:
           - const: mediatek,mt7623-ethsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
new file mode 100644
index 0000000000000..9b919a155eb13
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-ethwarp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 ethwarp Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The Mediatek MT7988 ethwarp controller provides clocks and resets for the
+  Ethernet related subsystems found the MT7988 SoC.
+  The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
+
+properties:
+  compatible:
+    items:
+      - const: mediatek,mt7988-ethwarp
+      - const: syscon
+      - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/reset/ti-syscon.h>
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        clock-controller at 15031000 {
+            compatible = "mediatek,mt7988-ethwarp", "syscon", "simple-mfd";
+            reg = <0 0x15031000 0 0x1000>;
+            #clock-cells = <1>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
new file mode 100644
index 0000000000000..fe5e3a70299fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-xfi-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 XFI PLL Clock Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The MediaTek XFI PLL controller provides the 156.25MHz clock for the
+  Ethernet SerDes PHY from the 40MHz top_xtal clock.
+
+properties:
+  compatible:
+    const: mediatek,mt7988-xfi-pll
+
+  reg:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - resets
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+        clock-controller at 11f40000 {
+            compatible = "mediatek,mt7988-xfi-pll";
+            reg = <0 0x11f40000 0 0x1000>;
+            resets = <&watchdog 16>;
+            #clock-cells = <1>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
index 6d087ded7437a..bdf3b55bd56fd 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
@@ -37,6 +37,8 @@ properties:
               - mediatek,mt7629-topckgen
               - mediatek,mt7981-topckgen
               - mediatek,mt7986-topckgen
+              - mediatek,mt7988-mcusys
+              - mediatek,mt7988-topckgen
               - mediatek,mt8167-topckgen
               - mediatek,mt8183-topckgen
           - const: syscon
diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
index 66a95191bd776..68632cda334bd 100644
--- a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
+++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
@@ -15,15 +15,22 @@ description:
 
 properties:
   compatible:
-    items:
-      - enum:
+    oneOf:
+      - items:
+        - enum:
           - mediatek,mt7622-sgmiisys
           - mediatek,mt7629-sgmiisys
           - mediatek,mt7981-sgmiisys_0
           - mediatek,mt7981-sgmiisys_1
           - mediatek,mt7986-sgmiisys_0
           - mediatek,mt7986-sgmiisys_1
-      - const: syscon
+        - const: syscon
+      - items:
+        - enum:
+          - mediatek,mt7988-sgmiisys_0
+          - mediatek,mt7988-sgmiisys_1
+        - const: syscon
+        - const: simple-mfd
 
   reg:
     maxItems: 1
-- 
2.43.0


From daniel at makrotopia.org  Tue Dec  5 16:57:20 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 00:57:20 +0000
Subject: [PATCH v3 3/4] clk: mediatek: Add pcw_chg_shift control
In-Reply-To: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
Message-ID: <40981d0bb722eb509628bcf82c31f632e4cf747a.1701823757.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Introduce pcw_chg_shfit control to optionally use that instead of the
hardcoded PCW_CHG_MASK macro.
This will needed for clocks on the MT7988 SoC.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v3: use git --from ...
v2: no changes

 drivers/clk/mediatek/clk-pll.c | 5 ++++-
 drivers/clk/mediatek/clk-pll.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index 513ab6b1b3229..9f08bc5d2a8a2 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -114,7 +114,10 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll, u32 pcw,
 			pll->data->pcw_shift);
 	val |= pcw << pll->data->pcw_shift;
 	writel(val, pll->pcw_addr);
-	chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
+	if (pll->data->pcw_chg_shift)
+		chg = readl(pll->pcw_chg_addr) | BIT(pll->data->pcw_chg_shift);
+	else
+		chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
 	writel(chg, pll->pcw_chg_addr);
 	if (pll->tuner_addr)
 		writel(val + 1, pll->tuner_addr);
diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
index f17278ff15d78..d28d317e84377 100644
--- a/drivers/clk/mediatek/clk-pll.h
+++ b/drivers/clk/mediatek/clk-pll.h
@@ -44,6 +44,7 @@ struct mtk_pll_data {
 	u32 pcw_reg;
 	int pcw_shift;
 	u32 pcw_chg_reg;
+	int pcw_chg_shift;
 	const struct mtk_pll_div_table *div_table;
 	const char *parent_name;
 	u32 en_reg;
-- 
2.43.0


From daniel at makrotopia.org  Tue Dec  5 16:57:32 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 00:57:32 +0000
Subject: [PATCH v3 4/4] clk: mediatek: add drivers for MT7988 SoC
In-Reply-To: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
Message-ID: <af4c5a230cc65d72987cb531518ae32706d6d95e.1701823757.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add APMIXED, ETH, INFRACFG and TOPCKGEN clock drivers which are
typical MediaTek designs.

Also add driver for XFIPLL clock generating the 156.25MHz clock for
the XFI SerDes. It needs an undocumented software workaround and has
an unknown internal design.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v3: use git --from ...
v2: no changes

 drivers/clk/mediatek/Kconfig               |   9 +
 drivers/clk/mediatek/Makefile              |   5 +
 drivers/clk/mediatek/clk-mt7988-apmixed.c  | 113 ++++++
 drivers/clk/mediatek/clk-mt7988-eth.c      | 141 +++++++
 drivers/clk/mediatek/clk-mt7988-infracfg.c | 378 +++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-topckgen.c | 446 +++++++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-xfipll.c   |  79 ++++
 7 files changed, 1171 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt7988-apmixed.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-eth.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-infracfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-topckgen.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-xfipll.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 48b42d11111cd..70a005e7e1b18 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -423,6 +423,15 @@ config COMMON_CLK_MT7986_ETHSYS
 	  This driver adds support for clocks for Ethernet and SGMII
 	  required on MediaTek MT7986 SoC.
 
+config COMMON_CLK_MT7988
+	tristate "Clock driver for MediaTek MT7988"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	select COMMON_CLK_MEDIATEK
+	default ARCH_MEDIATEK
+	help
+	  This driver supports MediaTek MT7988 basic clocks and clocks
+	  required for various periperals found on this SoC.
+
 config COMMON_CLK_MT8135
 	tristate "Clock driver for MediaTek MT8135"
 	depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index dbeaa5b41177d..eeccfa039896f 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -62,6 +62,11 @@ obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-apmixed.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-topckgen.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-infracfg.o
 obj-$(CONFIG_COMMON_CLK_MT7986_ETHSYS) += clk-mt7986-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-apmixed.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-topckgen.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-infracfg.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-xfipll.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135-apmixedsys.o clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8167) += clk-mt8167-apmixedsys.o clk-mt8167.o
 obj-$(CONFIG_COMMON_CLK_MT8167_AUDSYS) += clk-mt8167-aud.o
diff --git a/drivers/clk/mediatek/clk-mt7988-apmixed.c b/drivers/clk/mediatek/clk-mt7988-apmixed.c
new file mode 100644
index 0000000000000..3f1edc231e37a
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-apmixed.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include "clk-pll.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+#define MT7988_PLL_FMAX (2500UL * MHZ)
+#define MT7988_PCW_CHG_SHIFT 2
+
+#define PLL_xtal(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _rst_bar_mask, \
+		 _pcwbits, _pd_reg, _pd_shift, _tuner_reg, _tuner_en_reg,     \
+		 _tuner_en_bit, _pcw_reg, _pcw_shift, _pcw_chg_reg,           \
+		 _div_table)                                                  \
+	{                                                                     \
+		.id = _id, .name = _name, .reg = _reg, .pwr_reg = _pwr_reg,   \
+		.en_mask = _en_mask, .flags = _flags,                         \
+		.rst_bar_mask = BIT(_rst_bar_mask), .fmax = MT7988_PLL_FMAX,  \
+		.pcwbits = _pcwbits, .pd_reg = _pd_reg,                       \
+		.pd_shift = _pd_shift, .tuner_reg = _tuner_reg,               \
+		.tuner_en_reg = _tuner_en_reg, .tuner_en_bit = _tuner_en_bit, \
+		.pcw_reg = _pcw_reg, .pcw_shift = _pcw_shift,                 \
+		.pcw_chg_reg = _pcw_chg_reg,                                  \
+		.pcw_chg_shift = MT7988_PCW_CHG_SHIFT,                        \
+		.div_table = _div_table, .parent_name = "clkxtal",            \
+	}
+
+#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _rst_bar_mask,      \
+	    _pcwbits, _pd_reg, _pd_shift, _tuner_reg, _tuner_en_reg,          \
+	    _tuner_en_bit, _pcw_reg, _pcw_shift, _pcw_chg_reg)                \
+	PLL_xtal(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _rst_bar_mask, \
+		 _pcwbits, _pd_reg, _pd_shift, _tuner_reg, _tuner_en_reg,     \
+		 _tuner_en_bit, _pcw_reg, _pcw_shift, _pcw_chg_reg, NULL)
+
+static const struct mtk_pll_data plls[] = {
+	PLL(CLK_APMIXED_NETSYSPLL, "netsyspll", 0x0104, 0x0110, 0x00000001, 0,
+	    0, 32, 0x0104, 4, 0, 0, 0, 0x0108, 0, 0x0104),
+	PLL(CLK_APMIXED_MPLL, "mpll", 0x0114, 0x0120, 0xff000001, HAVE_RST_BAR,
+	    23, 32, 0x0114, 4, 0, 0, 0, 0x0118, 0, 0x0114),
+	PLL(CLK_APMIXED_MMPLL, "mmpll", 0x0124, 0x0130, 0xff000001,
+	    HAVE_RST_BAR, 23, 32, 0x0124, 4, 0, 0, 0, 0x0128, 0, 0x0124),
+	PLL(CLK_APMIXED_APLL2, "apll2", 0x0134, 0x0140, 0x00000001, 0, 0, 32,
+	    0x0134, 4, 0x0704, 0x0700, 1, 0x0138, 0, 0x0134),
+	PLL(CLK_APMIXED_NET1PLL, "net1pll", 0x0144, 0x0150, 0xff000001,
+	    HAVE_RST_BAR, 23, 32, 0x0144, 4, 0, 0, 0, 0x0148, 0, 0x0144),
+	PLL(CLK_APMIXED_NET2PLL, "net2pll", 0x0154, 0x0160, 0xff000001,
+	    (HAVE_RST_BAR | PLL_AO), 23, 32, 0x0154, 4, 0, 0, 0, 0x0158, 0,
+	    0x0154),
+	PLL(CLK_APMIXED_WEDMCUPLL, "wedmcupll", 0x0164, 0x0170, 0x00000001, 0,
+	    0, 32, 0x0164, 4, 0, 0, 0, 0x0168, 0, 0x0164),
+	PLL(CLK_APMIXED_SGMPLL, "sgmpll", 0x0174, 0x0180, 0x00000001, 0, 0, 32,
+	    0x0174, 4, 0, 0, 0, 0x0178, 0, 0x0174),
+	PLL(CLK_APMIXED_ARM_B, "arm_b", 0x0204, 0x0210, 0xff000001,
+	    (HAVE_RST_BAR | PLL_AO), 23, 32, 0x0204, 4, 0, 0, 0, 0x0208, 0,
+	    0x0204),
+	PLL(CLK_APMIXED_CCIPLL2_B, "ccipll2_b", 0x0214, 0x0220, 0xff000001,
+	    HAVE_RST_BAR, 23, 32, 0x0214, 4, 0, 0, 0, 0x0218, 0, 0x0214),
+	PLL(CLK_APMIXED_USXGMIIPLL, "usxgmiipll", 0x0304, 0x0310, 0xff000001,
+	    HAVE_RST_BAR, 23, 32, 0x0304, 4, 0, 0, 0, 0x0308, 0, 0x0304),
+	PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x0314, 0x0320, 0x00000001, 0, 0,
+	    32, 0x0314, 4, 0, 0, 0, 0x0318, 0, 0x0314),
+};
+
+static const struct of_device_id of_match_clk_mt7988_apmixed[] = {
+	{ .compatible = "mediatek,mt7988-apmixedsys", },
+	{ /* sentinel */ }
+};
+
+static int clk_mt7988_apmixed_probe(struct platform_device *pdev)
+{
+	struct clk_hw_onecell_data *clk_data;
+	struct device_node *node = pdev->dev.of_node;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(ARRAY_SIZE(plls));
+	if (!clk_data)
+		return -ENOMEM;
+
+	mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+
+	r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
+	if (r) {
+		pr_err("%s(): could not register clock provider: %d\n",
+		       __func__, r);
+		goto free_apmixed_data;
+	}
+	return r;
+
+free_apmixed_data:
+	mtk_free_clk_data(clk_data);
+	return r;
+}
+
+static struct platform_driver clk_mt7988_apmixed_drv = {
+	.probe = clk_mt7988_apmixed_probe,
+	.driver = {
+		.name = "clk-mt7988-apmixed",
+		.of_match_table = of_match_clk_mt7988_apmixed,
+	},
+};
+builtin_platform_driver(clk_mt7988_apmixed_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-eth.c b/drivers/clk/mediatek/clk-mt7988-eth.c
new file mode 100644
index 0000000000000..48d3bb45611fb
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-eth.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static const struct mtk_gate_regs ethdma_cg_regs = {
+	.set_ofs = 0x30,
+	.clr_ofs = 0x30,
+	.sta_ofs = 0x30,
+};
+
+#define GATE_ETHDMA(_id, _name, _parent, _shift)                              \
+	{                                                                     \
+		.id = _id, .name = _name, .parent_name = _parent,             \
+		.regs = &ethdma_cg_regs, .shift = _shift,                     \
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,                       \
+	}
+
+static const struct mtk_gate ethdma_clks[] = {
+	GATE_ETHDMA(CLK_ETHDMA_XGP1_EN, "ethdma_xgp1_en", "top_xtal", 0),
+	GATE_ETHDMA(CLK_ETHDMA_XGP2_EN, "ethdma_xgp2_en", "top_xtal", 1),
+	GATE_ETHDMA(CLK_ETHDMA_XGP3_EN, "ethdma_xgp3_en", "top_xtal", 2),
+	GATE_ETHDMA(CLK_ETHDMA_FE_EN, "ethdma_fe_en", "netsys_2x_sel", 6),
+	GATE_ETHDMA(CLK_ETHDMA_GP2_EN, "ethdma_gp2_en", "top_xtal", 7),
+	GATE_ETHDMA(CLK_ETHDMA_GP1_EN, "ethdma_gp1_en", "top_xtal", 8),
+	GATE_ETHDMA(CLK_ETHDMA_GP3_EN, "ethdma_gp3_en", "top_xtal", 10),
+	GATE_ETHDMA(CLK_ETHDMA_ESW_EN, "ethdma_esw_en", "netsys_gsw_sel", 16),
+	GATE_ETHDMA(CLK_ETHDMA_CRYPT0_EN, "ethdma_crypt0_en", "eip197_sel",
+		    29),
+};
+
+static const struct mtk_clk_desc ethdma_desc = {
+	.clks = ethdma_clks,
+	.num_clks = ARRAY_SIZE(ethdma_clks),
+};
+
+static const struct mtk_gate_regs sgmii0_cg_regs = {
+	.set_ofs = 0xe4,
+	.clr_ofs = 0xe4,
+	.sta_ofs = 0xe4,
+};
+
+#define GATE_SGMII0(_id, _name, _parent, _shift)                              \
+	{                                                                     \
+		.id = _id, .name = _name, .parent_name = _parent,             \
+		.regs = &sgmii0_cg_regs, .shift = _shift,                     \
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,                       \
+	}
+
+static const struct mtk_gate sgmii0_clks[] = {
+	GATE_SGMII0(CLK_SGM0_TX_EN, "sgm0_tx_en", "top_xtal", 2),
+	GATE_SGMII0(CLK_SGM0_RX_EN, "sgm0_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii0_desc = {
+	.clks = sgmii0_clks,
+	.num_clks = ARRAY_SIZE(sgmii0_clks),
+};
+
+static const struct mtk_gate_regs sgmii1_cg_regs = {
+	.set_ofs = 0xe4,
+	.clr_ofs = 0xe4,
+	.sta_ofs = 0xe4,
+};
+
+#define GATE_SGMII1(_id, _name, _parent, _shift)                              \
+	{                                                                     \
+		.id = _id, .name = _name, .parent_name = _parent,             \
+		.regs = &sgmii1_cg_regs, .shift = _shift,                     \
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,                       \
+	}
+
+static const struct mtk_gate sgmii1_clks[] = {
+	GATE_SGMII1(CLK_SGM1_TX_EN, "sgm1_tx_en", "top_xtal", 2),
+	GATE_SGMII1(CLK_SGM1_RX_EN, "sgm1_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii1_desc = {
+	.clks = sgmii1_clks,
+	.num_clks = ARRAY_SIZE(sgmii1_clks),
+};
+
+static const struct mtk_gate_regs ethwarp_cg_regs = {
+	.set_ofs = 0x14,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x14,
+};
+
+#define GATE_ETHWARP(_id, _name, _parent, _shift)                             \
+	{                                                                     \
+		.id = _id, .name = _name, .parent_name = _parent,             \
+		.regs = &ethwarp_cg_regs, .shift = _shift,                    \
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,                       \
+	}
+
+static const struct mtk_gate ethwarp_clks[] = {
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU2_EN, "ethwarp_wocpu2_en",
+		     "netsys_mcu_sel", 13),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU1_EN, "ethwarp_wocpu1_en",
+		     "netsys_mcu_sel", 14),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU0_EN, "ethwarp_wocpu0_en",
+		     "netsys_mcu_sel", 15),
+};
+
+static const struct mtk_clk_desc ethwarp_desc = {
+	.clks = ethwarp_clks,
+	.num_clks = ARRAY_SIZE(ethwarp_clks),
+};
+
+static const struct of_device_id of_match_clk_mt7988_eth[] = {
+	{ .compatible = "mediatek,mt7988-ethsys", .data = &ethdma_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys_0", .data = &sgmii0_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys_1", .data = &sgmii1_desc },
+	{ .compatible = "mediatek,mt7988-ethwarp", .data = &ethwarp_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_eth);
+
+static struct platform_driver clk_mt7988_eth_drv = {
+	.driver = {
+		.name = "clk-mt7988-eth",
+		.of_match_table = of_match_clk_mt7988_eth,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_eth_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 Ethernet clocks driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-infracfg.c b/drivers/clk/mediatek/clk-mt7988-infracfg.c
new file mode 100644
index 0000000000000..d23f7bdfafd9d
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-infracfg.c
@@ -0,0 +1,378 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const char *const infra_mux_uart0_parents[] __initconst = {
+	"csw_infra_f26m_sel", "uart_sel"
+};
+
+static const char *const infra_mux_uart1_parents[] __initconst = {
+	"csw_infra_f26m_sel", "uart_sel"
+};
+
+static const char *const infra_mux_uart2_parents[] __initconst = {
+	"csw_infra_f26m_sel", "uart_sel"
+};
+
+static const char *const infra_mux_spi0_parents[] __initconst = { "i2c_sel",
+								  "spi_sel" };
+
+static const char *const infra_mux_spi1_parents[] __initconst = {
+	"i2c_sel", "spim_mst_sel"
+};
+
+static const char *const infra_pwm_bck_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "sysaxi_sel", "pwm_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p0_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel",
+	"pextp_tl_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p1_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel",
+	"pextp_tl_p1_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p2_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel",
+	"pextp_tl_p2_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p3_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel",
+	"pextp_tl_p3_sel"
+};
+
+static const struct mtk_mux infra_muxes[] = {
+	/* MODULE_CLK_SEL_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART0_SEL, "infra_mux_uart0_sel",
+			     infra_mux_uart0_parents, 0x0018, 0x0010, 0x0014,
+			     0, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART1_SEL, "infra_mux_uart1_sel",
+			     infra_mux_uart1_parents, 0x0018, 0x0010, 0x0014,
+			     1, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART2_SEL, "infra_mux_uart2_sel",
+			     infra_mux_uart2_parents, 0x0018, 0x0010, 0x0014,
+			     2, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI0_SEL, "infra_mux_spi0_sel",
+			     infra_mux_spi0_parents, 0x0018, 0x0010, 0x0014, 4,
+			     1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI1_SEL, "infra_mux_spi1_sel",
+			     infra_mux_spi1_parents, 0x0018, 0x0010, 0x0014, 5,
+			     1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI2_SEL, "infra_mux_spi2_sel",
+			     infra_mux_spi0_parents, 0x0018, 0x0010, 0x0014, 6,
+			     1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_SEL, "infra_pwm_sel",
+			     infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 14,
+			     2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK1_SEL, "infra_pwm_ck1_sel",
+			     infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 16,
+			     2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK2_SEL, "infra_pwm_ck2_sel",
+			     infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 18,
+			     2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK3_SEL, "infra_pwm_ck3_sel",
+			     infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 20,
+			     2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK4_SEL, "infra_pwm_ck4_sel",
+			     infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 22,
+			     2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK5_SEL, "infra_pwm_ck5_sel",
+			     infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 24,
+			     2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK6_SEL, "infra_pwm_ck6_sel",
+			     infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 26,
+			     2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK7_SEL, "infra_pwm_ck7_sel",
+			     infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 28,
+			     2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK8_SEL, "infra_pwm_ck8_sel",
+			     infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 30,
+			     2, -1, -1, -1),
+	/* MODULE_CLK_SEL_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL,
+			     "infra_pcie_gfmux_tl_o_p0_sel",
+			     infra_pcie_gfmux_tl_ck_o_p0_parents, 0x0028,
+			     0x0020, 0x0024, 0, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL,
+			     "infra_pcie_gfmux_tl_o_p1_sel",
+			     infra_pcie_gfmux_tl_ck_o_p1_parents, 0x0028,
+			     0x0020, 0x0024, 2, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL,
+			     "infra_pcie_gfmux_tl_o_p2_sel",
+			     infra_pcie_gfmux_tl_ck_o_p2_parents, 0x0028,
+			     0x0020, 0x0024, 4, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL,
+			     "infra_pcie_gfmux_tl_o_p3_sel",
+			     infra_pcie_gfmux_tl_ck_o_p3_parents, 0x0028,
+			     0x0020, 0x0024, 6, 2, -1, -1, -1),
+};
+
+static const struct mtk_gate_regs infra0_cg_regs = {
+	.set_ofs = 0x10,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x18,
+};
+
+static const struct mtk_gate_regs infra1_cg_regs = {
+	.set_ofs = 0x40,
+	.clr_ofs = 0x44,
+	.sta_ofs = 0x48,
+};
+
+static const struct mtk_gate_regs infra2_cg_regs = {
+	.set_ofs = 0x50,
+	.clr_ofs = 0x54,
+	.sta_ofs = 0x58,
+};
+
+static const struct mtk_gate_regs infra3_cg_regs = {
+	.set_ofs = 0x60,
+	.clr_ofs = 0x64,
+	.sta_ofs = 0x68,
+};
+
+#define GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, _flags)			\
+	{									\
+		.id = _id, .name = _name, .parent_name = _parent,		\
+		.regs = &infra0_cg_regs, .shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr, .flags = _flags,		\
+	}
+
+#define GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, _flags)			\
+	{									\
+		.id = _id, .name = _name, .parent_name = _parent,		\
+		.regs = &infra1_cg_regs, .shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr, .flags = _flags,		\
+	}
+
+#define GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, _flags)			\
+	{									\
+		.id = _id, .name = _name, .parent_name = _parent,		\
+		.regs = &infra2_cg_regs, .shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr, .flags = _flags,		\
+	}
+
+#define GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, _flags)			\
+	{									\
+		.id = _id, .name = _name, .parent_name = _parent,		\
+		.regs = &infra3_cg_regs, .shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr, .flags = _flags,		\
+	}
+
+#define GATE_INFRA0(_id, _name, _parent, _shift)				\
+	GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA1(_id, _name, _parent, _shift)				\
+	GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA2(_id, _name, _parent, _shift)				\
+	GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA3(_id, _name, _parent, _shift)				\
+	GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, 0)
+
+
+#define GATE_CRITICAL(_id, _name, _parent, _regs, _shift)			\
+	{									\
+		.id = _id, .name = _name, .parent_name = _parent,		\
+		.regs = _regs, .shift = _shift,					\
+		.flags = CLK_IS_CRITICAL,					\
+		.ops = &mtk_clk_gate_ops_setclr,				\
+	}
+
+static const struct mtk_gate infra_clks[] = {
+	/* INFRA0 */
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P0,
+		    "infra_pcie_peri_ck_26m_ck_p0", "csw_infra_f26m_sel", 7),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P1,
+		    "infra_pcie_peri_ck_26m_ck_p1", "csw_infra_f26m_sel", 8),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P2,
+		    "infra_pcie_peri_ck_26m_ck_p2", "csw_infra_f26m_sel", 9),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P3,
+		    "infra_pcie_peri_ck_26m_ck_p3", "csw_infra_f26m_sel", 10),
+	/* INFRA1 */
+	GATE_INFRA1(CLK_INFRA_66M_GPT_BCK, "infra_hf_66m_gpt_bck",
+		    "sysaxi_sel", 0),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_HCK, "infra_hf_66m_pwm_hck",
+		    "sysaxi_sel", 1),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_BCK, "infra_hf_66m_pwm_bck",
+		    "infra_pwm_sel", 2),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK1, "infra_hf_66m_pwm_ck1",
+		    "infra_pwm_ck1_sel", 3),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK2, "infra_hf_66m_pwm_ck2",
+		    "infra_pwm_ck2_sel", 4),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK3, "infra_hf_66m_pwm_ck3",
+		    "infra_pwm_ck3_sel", 5),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK4, "infra_hf_66m_pwm_ck4",
+		    "infra_pwm_ck4_sel", 6),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK5, "infra_hf_66m_pwm_ck5",
+		    "infra_pwm_ck5_sel", 7),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK6, "infra_hf_66m_pwm_ck6",
+		    "infra_pwm_ck6_sel", 8),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK7, "infra_hf_66m_pwm_ck7",
+		    "infra_pwm_ck7_sel", 9),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK8, "infra_hf_66m_pwm_ck8",
+		    "infra_pwm_ck8_sel", 10),
+	GATE_INFRA1(CLK_INFRA_133M_CQDMA_BCK, "infra_hf_133m_cqdma_bck",
+		    "sysaxi_sel", 12),
+	GATE_INFRA1(CLK_INFRA_66M_AUD_SLV_BCK, "infra_66m_aud_slv_bck",
+		    "sysaxi_sel", 13),
+	GATE_INFRA1(CLK_INFRA_AUD_26M, "infra_f_faud_26m",
+		    "csw_infra_f26m_sel", 14),
+	GATE_INFRA1(CLK_INFRA_AUD_L, "infra_f_faud_l", "aud_l_sel", 15),
+	GATE_INFRA1(CLK_INFRA_AUD_AUD, "infra_f_aud_aud", "a1sys_sel", 16),
+	GATE_INFRA1(CLK_INFRA_AUD_EG2, "infra_f_faud_eg2", "a_tuner_sel", 18),
+	GATE_INFRA1_FLAGS(CLK_INFRA_DRAMC_F26M, "infra_dramc_f26m",
+			  "csw_infra_f26m_sel", 19, CLK_IS_CRITICAL),
+	/* JTAG */
+	GATE_INFRA1_FLAGS(CLK_INFRA_133M_DBG_ACKM, "infra_hf_133m_dbg_ackm",
+			  "sysaxi_sel", 20, CLK_IS_CRITICAL),
+	GATE_INFRA1(CLK_INFRA_66M_AP_DMA_BCK, "infra_66m_ap_dma_bck",
+		    "sysaxi_sel", 21),
+	GATE_INFRA1(CLK_INFRA_66M_SEJ_BCK, "infra_hf_66m_sej_bck",
+		    "sysaxi_sel", 29),
+	GATE_INFRA1(CLK_INFRA_PRE_CK_SEJ_F13M, "infra_pre_ck_sej_f13m",
+		    "csw_infra_f26m_sel", 30),
+	/* INFRA2 */
+	GATE_INFRA2(CLK_INFRA_26M_THERM_SYSTEM, "infra_hf_26m_therm_system",
+		    "csw_infra_f26m_sel", 0),
+	GATE_INFRA2(CLK_INFRA_I2C_BCK, "infra_i2c_bck", "i2c_sel", 1),
+	GATE_INFRA2(CLK_INFRA_52M_UART0_CK, "infra_f_52m_uart0",
+		    "infra_mux_uart0_sel", 3),
+	GATE_INFRA2(CLK_INFRA_52M_UART1_CK, "infra_f_52m_uart1",
+		    "infra_mux_uart1_sel", 4),
+	GATE_INFRA2(CLK_INFRA_52M_UART2_CK, "infra_f_52m_uart2",
+		    "infra_mux_uart2_sel", 5),
+	GATE_INFRA2(CLK_INFRA_NFI, "infra_f_fnfi", "nfi1x_sel", 9),
+	GATE_INFRA2(CLK_INFRA_SPINFI, "infra_f_fspinfi", "spinfi_sel", 10),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_NFI_HCK, "infra_hf_66m_nfi_hck",
+			  "sysaxi_sel", 11, CLK_IS_CRITICAL),
+	GATE_INFRA2_FLAGS(CLK_INFRA_104M_SPI0, "infra_hf_104m_spi0",
+			  "infra_mux_spi0_sel", 12, CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_104M_SPI1, "infra_hf_104m_spi1",
+		    "infra_mux_spi1_sel", 13),
+	GATE_INFRA2(CLK_INFRA_104M_SPI2_BCK, "infra_hf_104m_spi2_bck",
+		    "infra_mux_spi2_sel", 14),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_SPI0_HCK, "infra_hf_66m_spi0_hck",
+			  "sysaxi_sel", 15, CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_66M_SPI1_HCK, "infra_hf_66m_spi1_hck",
+		    "sysaxi_sel", 16),
+	GATE_INFRA2(CLK_INFRA_66M_SPI2_HCK, "infra_hf_66m_spi2_hck",
+		    "sysaxi_sel", 17),
+	GATE_INFRA2(CLK_INFRA_66M_FLASHIF_AXI, "infra_hf_66m_flashif_axi",
+		    "sysaxi_sel", 18),
+	GATE_CRITICAL(CLK_INFRA_RTC, "infra_f_frtc", "top_rtc_32k", &infra2_cg_regs, 19),
+	GATE_INFRA2(CLK_INFRA_26M_ADC_BCK, "infra_f_26m_adc_bck",
+		    "csw_infra_f26m_sel", 20),
+	GATE_INFRA2(CLK_INFRA_RC_ADC, "infra_f_frc_adc", "infra_f_26m_adc_bck",
+		    21),
+	GATE_INFRA2(CLK_INFRA_MSDC400, "infra_f_fmsdc400", "emmc_400m_sel",
+		    22),
+	GATE_INFRA2(CLK_INFRA_MSDC2_HCK, "infra_f_fmsdc2_hck", "emmc_250m_sel",
+		    23),
+	GATE_INFRA2(CLK_INFRA_133M_MSDC_0_HCK, "infra_hf_133m_msdc_0_hck",
+		    "sysaxi_sel", 24),
+	GATE_INFRA2(CLK_INFRA_66M_MSDC_0_HCK, "infra_66m_msdc_0_hck",
+		    "sysaxi_sel", 25),
+	GATE_INFRA2(CLK_INFRA_133M_CPUM_BCK, "infra_hf_133m_cpum_bck",
+		    "sysaxi_sel", 26),
+	GATE_INFRA2(CLK_INFRA_BIST2FPC, "infra_hf_fbist2fpc", "nfi1x_sel", 27),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_MCK_CK_P1,
+		    "infra_hf_i2c_x16w_mck_ck_p1", "sysaxi_sel", 29),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_PCK_CK_P1,
+		    "infra_hf_i2c_x16w_pck_ck_p1", "sysaxi_sel", 31),
+	/* INFRA3 */
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK, "infra_133m_usb_hck", "sysaxi_sel",
+		    0),
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK_CK_P1, "infra_133m_usb_hck_ck_p1",
+		    "sysaxi_sel", 1),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK, "infra_66m_usb_hck", "sysaxi_sel",
+		    2),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK_CK_P1, "infra_66m_usb_hck_ck_p1",
+		    "sysaxi_sel", 3),
+	GATE_INFRA3(CLK_INFRA_USB_SYS, "infra_usb_sys", "usb_sys_sel", 4),
+	GATE_INFRA3(CLK_INFRA_USB_SYS_CK_P1, "infra_usb_sys_ck_p1",
+		    "usb_sys_p1_sel", 5),
+	GATE_INFRA3(CLK_INFRA_USB_REF, "infra_usb_ref", "top_xtal", 6),
+	GATE_INFRA3(CLK_INFRA_USB_CK_P1, "infra_usb_ck_p1", "top_xtal", 7),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT, "infra_usb_frmcnt",
+			  "usb_frmcnt_sel", 8, CLK_IS_CRITICAL),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT_CK_P1, "infra_usb_frmcnt_ck_p1",
+			  "usb_frmcnt_p1_sel", 9, CLK_IS_CRITICAL),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE, "infra_usb_pipe", "sspxtp_sel", 10),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE_CK_P1, "infra_usb_pipe_ck_p1",
+		    "usb_phy_sel", 11),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI, "infra_usb_utmi", "top_xtal", 12),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI_CK_P1, "infra_usb_utmi_ck_p1",
+		    "top_xtal", 13),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI, "infra_usb_xhci", "usb_xhci_sel", 14),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI_CK_P1, "infra_usb_xhci_ck_p1",
+		    "usb_xhci_p1_sel", 15),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P0, "infra_pcie_gfmux_tl_ck_p0",
+		    "infra_pcie_gfmux_tl_o_p0_sel", 20),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P1, "infra_pcie_gfmux_tl_ck_p1",
+		    "infra_pcie_gfmux_tl_o_p1_sel", 21),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P2, "infra_pcie_gfmux_tl_ck_p2",
+		    "infra_pcie_gfmux_tl_o_p2_sel", 22),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P3, "infra_pcie_gfmux_tl_ck_p3",
+		    "infra_pcie_gfmux_tl_o_p3_sel", 23),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P0, "infra_pcie_pipe_ck_p0",
+		    "top_xtal", 24),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P1, "infra_pcie_pipe_ck_p1",
+		    "top_xtal", 25),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P2, "infra_pcie_pipe_ck_p2",
+		    "top_xtal", 26),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P3, "infra_pcie_pipe_ck_p3",
+		    "top_xtal", 27),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P0, "infra_133m_pcie_ck_p0",
+		    "sysaxi_sel", 28),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P1, "infra_133m_pcie_ck_p1",
+		    "sysaxi_sel", 29),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P2, "infra_133m_pcie_ck_p2",
+		    "sysaxi_sel", 30),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P3, "infra_133m_pcie_ck_p3",
+		    "sysaxi_sel", 31),
+};
+
+static const struct mtk_clk_desc infra_desc = {
+	.clks = infra_clks,
+	.num_clks = ARRAY_SIZE(infra_clks),
+	.mux_clks = infra_muxes,
+	.num_mux_clks = ARRAY_SIZE(infra_muxes),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const struct of_device_id of_match_clk_mt7988_infracfg[] = {
+	{ .compatible = "mediatek,mt7988-infracfg", .data = &infra_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_infracfg);
+
+static struct platform_driver clk_mt7988_infracfg_drv = {
+	.driver = {
+		.name = "clk-mt7988-infracfg",
+		.of_match_table = of_match_clk_mt7988_infracfg,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_infracfg_drv);
diff --git a/drivers/clk/mediatek/clk-mt7988-topckgen.c b/drivers/clk/mediatek/clk-mt7988-topckgen.c
new file mode 100644
index 0000000000000..7bed282e615f8
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-topckgen.c
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+	FIXED_CLK(CLK_TOP_XTAL, "top_xtal", "clkxtal", 40000000),
+};
+
+static const struct mtk_fixed_factor top_divs[] = {
+	FACTOR(CLK_TOP_XTAL_D2, "top_xtal_d2", "top_xtal", 1, 2),
+	FACTOR(CLK_TOP_RTC_32K, "top_rtc_32k", "top_xtal", 1, 1250),
+	FACTOR(CLK_TOP_RTC_32P7K, "top_rtc_32p7k", "top_xtal", 1, 1220),
+	FACTOR(CLK_TOP_MPLL_D2, "mpll_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D3_D2, "mpll_d3_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D4, "mpll_d4", "mpll", 1, 4),
+	FACTOR(CLK_TOP_MPLL_D8, "mpll_d8", "mpll", 1, 8),
+	FACTOR(CLK_TOP_MPLL_D8_D2, "mpll_d8_d2", "mpll", 1, 16),
+	FACTOR(CLK_TOP_MMPLL_D2, "mmpll_d2", "mmpll", 1, 2),
+	FACTOR(CLK_TOP_MMPLL_D3_D5, "mmpll_d3_d5", "mmpll", 1, 15),
+	FACTOR(CLK_TOP_MMPLL_D4, "mmpll_d4", "mmpll", 1, 4),
+	FACTOR(CLK_TOP_MMPLL_D6_D2, "mmpll_d6_d2", "mmpll", 1, 12),
+	FACTOR(CLK_TOP_MMPLL_D8, "mmpll_d8", "mmpll", 1, 8),
+	FACTOR(CLK_TOP_APLL2_D4, "apll2_d4", "apll2", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D4, "net1pll_d4", "net1pll", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D5, "net1pll_d5", "net1pll", 1, 5),
+	FACTOR(CLK_TOP_NET1PLL_D5_D2, "net1pll_d5_d2", "net1pll", 1, 10),
+	FACTOR(CLK_TOP_NET1PLL_D5_D4, "net1pll_d5_d4", "net1pll", 1, 20),
+	FACTOR(CLK_TOP_NET1PLL_D8, "net1pll_d8", "net1pll", 1, 8),
+	FACTOR(CLK_TOP_NET1PLL_D8_D2, "net1pll_d8_d2", "net1pll", 1, 16),
+	FACTOR(CLK_TOP_NET1PLL_D8_D4, "net1pll_d8_d4", "net1pll", 1, 32),
+	FACTOR(CLK_TOP_NET1PLL_D8_D8, "net1pll_d8_d8", "net1pll", 1, 64),
+	FACTOR(CLK_TOP_NET1PLL_D8_D16, "net1pll_d8_d16", "net1pll", 1, 128),
+	FACTOR(CLK_TOP_NET2PLL_D2, "net2pll_d2", "net2pll", 1, 2),
+	FACTOR(CLK_TOP_NET2PLL_D4, "net2pll_d4", "net2pll", 1, 4),
+	FACTOR(CLK_TOP_NET2PLL_D4_D4, "net2pll_d4_d4", "net2pll", 1, 16),
+	FACTOR(CLK_TOP_NET2PLL_D4_D8, "net2pll_d4_d8", "net2pll", 1, 32),
+	FACTOR(CLK_TOP_NET2PLL_D6, "net2pll_d6", "net2pll", 1, 6),
+	FACTOR(CLK_TOP_NET2PLL_D8, "net2pll_d8", "net2pll", 1, 8),
+};
+
+static const char *const netsys_parents[] = { "top_xtal", "net2pll_d2",
+					      "mmpll_d2" };
+
+static const char *const netsys_500m_parents[] = { "top_xtal", "net1pll_d5",
+						   "net1pll_d5_d2" };
+
+static const char *const netsys_2x_parents[] = { "top_xtal", "net2pll",
+						 "mmpll" };
+
+static const char *const netsys_gsw_parents[] = { "top_xtal", "net1pll_d4",
+						  "net1pll_d5" };
+
+static const char *const eth_gmii_parents[] = { "top_xtal", "net1pll_d5_d4" };
+
+static const char *const netsys_mcu_parents[] = { "top_xtal",	"net2pll",
+						  "mmpll",	"net1pll_d4",
+						  "net1pll_d5", "mpll" };
+
+static const char *const eip197_parents[] = { "top_xtal",   "netsyspll",
+					      "net2pll",    "mmpll",
+					      "net1pll_d4", "net1pll_d5" };
+
+static const char *const axi_infra_parents[] = { "top_xtal", "net1pll_d8_d2" };
+
+static const char *const uart_parents[] = { "top_xtal", "mpll_d8",
+					    "mpll_d8_d2" };
+
+static const char *const emmc_250m_parents[] = { "top_xtal", "net1pll_d5_d2",
+						 "mmpll_d4" };
+
+static const char *const emmc_400m_parents[] = { "top_xtal", "msdcpll",
+						 "mmpll_d2", "mpll_d2",
+						 "mmpll_d4", "net1pll_d8_d2" };
+
+static const char *const spi_parents[] = { "top_xtal",	 "mpll_d2",
+					   "mmpll_d4",	 "net1pll_d8_d2",
+					   "net2pll_d6", "net1pll_d5_d4",
+					   "mpll_d4",	 "net1pll_d8_d4" };
+
+static const char *const nfi1x_parents[] = { "top_xtal",      "mmpll_d4",
+					     "net1pll_d8_d2", "net2pll_d6",
+					     "mpll_d4",	      "mmpll_d8",
+					     "net1pll_d8_d4", "mpll_d8" };
+
+static const char *const spinfi_parents[] = { "top_xtal_d2",   "top_xtal",
+					      "net1pll_d5_d4", "mpll_d4",
+					      "mmpll_d8",      "net1pll_d8_d4",
+					      "mmpll_d6_d2",   "mpll_d8" };
+
+static const char *const pwm_parents[] = { "top_xtal",	    "net1pll_d8_d2",
+					   "net1pll_d5_d4", "mpll_d4",
+					   "mpll_d8_d2",    "top_rtc_32k" };
+
+static const char *const i2c_parents[] = { "top_xtal", "net1pll_d5_d4",
+					   "mpll_d4", "net1pll_d8_d4" };
+
+static const char *const pcie_mbist_250m_parents[] = { "top_xtal",
+						       "net1pll_d5_d2" };
+
+static const char *const pextp_tl_ck_parents[] = { "top_xtal", "net2pll_d6",
+						   "mmpll_d8", "mpll_d8_d2",
+						   "top_rtc_32k" };
+
+static const char *const usb_frmcnt_parents[] = { "top_xtal", "mmpll_d3_d5" };
+
+static const char *const aud_parents[] = { "top_xtal", "apll2" };
+
+static const char *const a1sys_parents[] = { "top_xtal", "apll2_d4" };
+
+static const char *const aud_l_parents[] = { "top_xtal", "apll2",
+					     "mpll_d8_d2" };
+
+static const char *const sspxtp_parents[] = { "top_xtal_d2", "mpll_d8_d2" };
+
+static const char *const usxgmii_sbus_0_parents[] = { "top_xtal",
+						      "net1pll_d8_d4" };
+
+static const char *const sgm_0_parents[] = { "top_xtal", "sgmpll" };
+
+static const char *const sysapb_parents[] = { "top_xtal", "mpll_d3_d2" };
+
+static const char *const eth_refck_50m_parents[] = { "top_xtal",
+						     "net2pll_d4_d4" };
+
+static const char *const eth_sys_200m_parents[] = { "top_xtal", "net2pll_d4" };
+
+static const char *const eth_xgmii_parents[] = { "top_xtal_d2",
+						 "net1pll_d8_d8",
+						 "net1pll_d8_d16" };
+
+static const char *const bus_tops_parents[] = { "top_xtal", "net1pll_d5",
+						"net2pll_d2" };
+
+static const char *const npu_tops_parents[] = { "top_xtal", "net2pll" };
+
+static const char *const dramc_md32_parents[] = { "top_xtal", "mpll_d2",
+						  "wedmcupll" };
+
+static const char *const da_xtp_glb_p0_parents[] = { "top_xtal",
+						     "net2pll_d8" };
+
+static const char *const mcusys_backup_625m_parents[] = { "top_xtal",
+							  "net1pll_d4" };
+
+static const char *const macsec_parents[] = { "top_xtal", "sgmpll",
+					      "net1pll_d8" };
+
+static const char *const netsys_tops_400m_parents[] = { "top_xtal",
+							"net2pll_d2" };
+
+static const char *const eth_mii_parents[] = { "top_xtal_d2",
+					       "net2pll_d4_d8" };
+
+static const struct mtk_mux top_muxes[] = {
+	/* CLK_CFG_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SEL, "netsys_sel", netsys_parents,
+			     0x000, 0x004, 0x008, 0, 2, 7, 0x1c0, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_500M_SEL, "netsys_500m_sel",
+			     netsys_500m_parents, 0x000, 0x004, 0x008, 8, 2,
+			     15, 0x1C0, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_2X_SEL, "netsys_2x_sel",
+			     netsys_2x_parents, 0x000, 0x004, 0x008, 16, 2, 23,
+			     0x1C0, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_GSW_SEL, "netsys_gsw_sel",
+			     netsys_gsw_parents, 0x000, 0x004, 0x008, 24, 2,
+			     31, 0x1C0, 3),
+	/* CLK_CFG_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_GMII_SEL, "eth_gmii_sel",
+			     eth_gmii_parents, 0x010, 0x014, 0x018, 0, 1, 7,
+			     0x1C0, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_MCU_SEL, "netsys_mcu_sel",
+			     netsys_mcu_parents, 0x010, 0x014, 0x018, 8, 3, 15,
+			     0x1C0, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PAO_2X_SEL, "netsys_pao_2x_sel",
+			     netsys_mcu_parents, 0x010, 0x014, 0x018, 16, 3,
+			     23, 0x1C0, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EIP197_SEL, "eip197_sel", eip197_parents,
+			     0x010, 0x014, 0x018, 24, 3, 31, 0x1c0, 7),
+	/* CLK_CFG_2 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_AXI_INFRA_SEL, "axi_infra_sel",
+				   axi_infra_parents, 0x020, 0x024, 0x028, 0,
+				   1, 7, 0x1C0, 8, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_UART_SEL, "uart_sel", uart_parents, 0x020,
+			     0x024, 0x028, 8, 2, 15, 0x1c0, 9),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_250M_SEL, "emmc_250m_sel",
+			     emmc_250m_parents, 0x020, 0x024, 0x028, 16, 2, 23,
+			     0x1C0, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_400M_SEL, "emmc_400m_sel",
+			     emmc_400m_parents, 0x020, 0x024, 0x028, 24, 3, 31,
+			     0x1C0, 11),
+	/* CLK_CFG_3 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPI_SEL, "spi_sel", spi_parents, 0x030,
+			     0x034, 0x038, 0, 3, 7, 0x1c0, 12),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPIM_MST_SEL, "spim_mst_sel", spi_parents,
+			     0x030, 0x034, 0x038, 8, 3, 15, 0x1c0, 13),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NFI1X_SEL, "nfi1x_sel", nfi1x_parents,
+			     0x030, 0x034, 0x038, 16, 3, 23, 0x1c0, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPINFI_SEL, "spinfi_sel", spinfi_parents,
+			     0x030, 0x034, 0x038, 24, 3, 31, 0x1c0, 15),
+	/* CLK_CFG_4 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PWM_SEL, "pwm_sel", pwm_parents, 0x040,
+			     0x044, 0x048, 0, 3, 7, 0x1c0, 16),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_I2C_SEL, "i2c_sel", i2c_parents, 0x040,
+			     0x044, 0x048, 8, 2, 15, 0x1c0, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PCIE_MBIST_250M_SEL,
+			     "pcie_mbist_250m_sel", pcie_mbist_250m_parents,
+			     0x040, 0x044, 0x048, 16, 1, 23, 0x1C0, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_SEL, "pextp_tl_sel",
+			     pextp_tl_ck_parents, 0x040, 0x044, 0x048, 24, 3,
+			     31, 0x1C0, 19),
+	/* CLK_CFG_5 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P1_SEL, "pextp_tl_p1_sel",
+			     pextp_tl_ck_parents, 0x050, 0x054, 0x058, 0, 3, 7,
+			     0x1C0, 20),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P2_SEL, "pextp_tl_p2_sel",
+			     pextp_tl_ck_parents, 0x050, 0x054, 0x058, 8, 3,
+			     15, 0x1C0, 21),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P3_SEL, "pextp_tl_p3_sel",
+			     pextp_tl_ck_parents, 0x050, 0x054, 0x058, 16, 3,
+			     23, 0x1C0, 22),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_SEL, "usb_sys_sel",
+			     eth_gmii_parents, 0x050, 0x054, 0x058, 24, 1, 31,
+			     0x1C0, 23),
+	/* CLK_CFG_6 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_P1_SEL, "usb_sys_p1_sel",
+			     eth_gmii_parents, 0x060, 0x064, 0x068, 0, 1, 7,
+			     0x1C0, 24),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_SEL, "usb_xhci_sel",
+			     eth_gmii_parents, 0x060, 0x064, 0x068, 8, 1, 15,
+			     0x1C0, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_P1_SEL, "usb_xhci_p1_sel",
+			     eth_gmii_parents, 0x060, 0x064, 0x068, 16, 1, 23,
+			     0x1C0, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_SEL, "usb_frmcnt_sel",
+			     usb_frmcnt_parents, 0x060, 0x064, 0x068, 24, 1,
+			     31, 0x1C0, 27),
+	/* CLK_CFG_7 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_P1_SEL, "usb_frmcnt_p1_sel",
+			     usb_frmcnt_parents, 0x070, 0x074, 0x078, 0, 1, 7,
+			     0x1C0, 28),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_SEL, "aud_sel", aud_parents, 0x070,
+			     0x074, 0x078, 8, 1, 15, 0x1c0, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A1SYS_SEL, "a1sys_sel", a1sys_parents,
+			     0x070, 0x074, 0x078, 16, 1, 23, 0x1c0, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_L_SEL, "aud_l_sel", aud_l_parents,
+			     0x070, 0x074, 0x078, 24, 2, 31, 0x1c4, 0),
+	/* CLK_CFG_8 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A_TUNER_SEL, "a_tuner_sel", a1sys_parents,
+			     0x080, 0x084, 0x088, 0, 1, 7, 0x1c4, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SSPXTP_SEL, "sspxtp_sel", sspxtp_parents,
+			     0x080, 0x084, 0x088, 8, 1, 15, 0x1c4, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_PHY_SEL, "usb_phy_sel",
+			     sspxtp_parents, 0x080, 0x084, 0x088, 16, 1, 23,
+			     0x1c4, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_0_SEL, "usxgmii_sbus_0_sel",
+			     usxgmii_sbus_0_parents, 0x080, 0x084, 0x088, 24,
+			     1, 31, 0x1C4, 4),
+	/* CLK_CFG_9 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_1_SEL, "usxgmii_sbus_1_sel",
+			     usxgmii_sbus_0_parents, 0x090, 0x094, 0x098, 0, 1,
+			     7, 0x1C4, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_0_SEL, "sgm_0_sel", sgm_0_parents,
+			     0x090, 0x094, 0x098, 8, 1, 15, 0x1c4, 6),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_0_SEL, "sgm_sbus_0_sel",
+				   usxgmii_sbus_0_parents, 0x090, 0x094, 0x098,
+				   16, 1, 23, 0x1C4, 7, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_1_SEL, "sgm_1_sel", sgm_0_parents,
+			     0x090, 0x094, 0x098, 24, 1, 31, 0x1c4, 8),
+	/* CLK_CFG_10 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_1_SEL, "sgm_sbus_1_sel",
+				   usxgmii_sbus_0_parents, 0x0a0, 0x0a4, 0x0a8,
+				   0, 1, 7, 0x1C4, 9, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_0_XTAL_SEL, "xfi_phy_0_xtal_sel",
+			     sspxtp_parents, 0x0a0, 0x0a4, 0x0a8, 8, 1, 15,
+			     0x1C4, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_1_XTAL_SEL, "xfi_phy_1_xtal_sel",
+			     sspxtp_parents, 0x0a0, 0x0a4, 0x0a8, 16, 1, 23,
+			     0x1C4, 11),
+	/* CLK_CFG_11 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAXI_SEL, "sysaxi_sel",
+				   axi_infra_parents, 0x0a0, 0x0a4, 0x0a8, 24,
+				   1, 31, 0x1C4, 12, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAPB_SEL, "sysapb_sel",
+				   sysapb_parents, 0x0b0, 0x0b4, 0x0b8, 0, 1,
+				   7, 0x1c4, 13, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_REFCK_50M_SEL, "eth_refck_50m_sel",
+			     eth_refck_50m_parents, 0x0b0, 0x0b4, 0x0b8, 8, 1,
+			     15, 0x1C4, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_200M_SEL, "eth_sys_200m_sel",
+			     eth_sys_200m_parents, 0x0b0, 0x0b4, 0x0b8, 16, 1,
+			     23, 0x1C4, 15),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_SEL, "eth_sys_sel",
+			     pcie_mbist_250m_parents, 0x0b0, 0x0b4, 0x0b8, 24,
+			     1, 31, 0x1C4, 16),
+	/* CLK_CFG_12 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_XGMII_SEL, "eth_xgmii_sel",
+			     eth_xgmii_parents, 0x0c0, 0x0c4, 0x0c8, 0, 2, 7,
+			     0x1C4, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_BUS_TOPS_SEL, "bus_tops_sel",
+			     bus_tops_parents, 0x0c0, 0x0c4, 0x0c8, 8, 2, 15,
+			     0x1C4, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_TOPS_SEL, "npu_tops_sel",
+			     npu_tops_parents, 0x0c0, 0x0c4, 0x0c8, 16, 1, 23,
+			     0x1C4, 19),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_SEL, "dramc_sel",
+				   sspxtp_parents, 0x0c0, 0x0c4, 0x0c8, 24, 1,
+				   31, 0x1C4, 20, CLK_IS_CRITICAL),
+	/* CLK_CFG_13 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_MD32_SEL, "dramc_md32_sel",
+				   dramc_md32_parents, 0x0d0, 0x0d4, 0x0d8, 0,
+				   2, 7, 0x1C4, 21, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(
+		CLK_TOP_INFRA_F26M_SEL, "csw_infra_f26m_sel", sspxtp_parents,
+		0x0d0, 0x0d4, 0x0d8, 8, 1, 15, 0x1C4, 22, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P0_SEL, "pextp_p0_sel",
+			     sspxtp_parents, 0x0d0, 0x0d4, 0x0d8, 16, 1, 23,
+			     0x1C4, 23),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P1_SEL, "pextp_p1_sel",
+			     sspxtp_parents, 0x0d0, 0x0d4, 0x0d8, 24, 1, 31,
+			     0x1C4, 24),
+	/* CLK_CFG_14 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P2_SEL, "pextp_p2_sel",
+			     sspxtp_parents, 0x0e0, 0x0e4, 0x0e8, 0, 1, 7,
+			     0x1C4, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P3_SEL, "pextp_p3_sel",
+			     sspxtp_parents, 0x0e0, 0x0e4, 0x0e8, 8, 1, 15,
+			     0x1C4, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P0_SEL, "da_xtp_glb_p0_sel",
+			     da_xtp_glb_p0_parents, 0x0e0, 0x0e4, 0x0e8, 16, 1,
+			     23, 0x1C4, 27),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P1_SEL, "da_xtp_glb_p1_sel",
+			     da_xtp_glb_p0_parents, 0x0e0, 0x0e4, 0x0e8, 24, 1,
+			     31, 0x1C4, 28),
+	/* CLK_CFG_15 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P2_SEL, "da_xtp_glb_p2_sel",
+			     da_xtp_glb_p0_parents, 0x0f0, 0x0f4, 0x0f8, 0, 1,
+			     7, 0x1C4, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P3_SEL, "da_xtp_glb_p3_sel",
+			     da_xtp_glb_p0_parents, 0x0f0, 0x0f4, 0x0f8, 8, 1,
+			     15, 0x1C4, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_CKM_SEL, "ckm_sel", sspxtp_parents, 0x0F0,
+			     0x0f4, 0x0f8, 16, 1, 23, 0x1c8, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_SEL, "da_sel", sspxtp_parents, 0x0f0,
+			     0x0f4, 0x0f8, 24, 1, 31, 0x1C8, 1),
+	/* CLK_CFG_16 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_SEL, "pextp_sel", sspxtp_parents,
+			     0x0100, 0x104, 0x108, 0, 1, 7, 0x1c8, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_TOPS_P2_26M_SEL, "tops_p2_26m_sel",
+			     sspxtp_parents, 0x0100, 0x104, 0x108, 8, 1, 15,
+			     0x1C8, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MCUSYS_BACKUP_625M_SEL,
+			     "mcusys_backup_625m_sel",
+			     mcusys_backup_625m_parents, 0x0100, 0x104, 0x108,
+			     16, 1, 23, 0x1C8, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SYNC_250M_SEL,
+			     "netsys_sync_250m_sel", pcie_mbist_250m_parents,
+			     0x0100, 0x104, 0x108, 24, 1, 31, 0x1c8, 5),
+	/* CLK_CFG_17 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MACSEC_SEL, "macsec_sel", macsec_parents,
+			     0x0110, 0x114, 0x118, 0, 2, 7, 0x1c8, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_TOPS_400M_SEL,
+			     "netsys_tops_400m_sel", netsys_tops_400m_parents,
+			     0x0110, 0x114, 0x118, 8, 1, 15, 0x1c8, 7),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PPEFB_250M_SEL,
+			     "netsys_ppefb_250m_sel", pcie_mbist_250m_parents,
+			     0x0110, 0x114, 0x118, 16, 1, 23, 0x1c8, 8),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_WARP_SEL, "netsys_warp_sel",
+			     netsys_parents, 0x0110, 0x114, 0x118, 24, 2, 31,
+			     0x1C8, 9),
+	/* CLK_CFG_18 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_MII_SEL, "eth_mii_sel",
+			     eth_mii_parents, 0x0120, 0x124, 0x128, 0, 1, 7,
+			     0x1c8, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_SEL, "ck_npu_sel", netsys_2x_parents,
+			     0x0120, 0x124, 0x128, 8, 2, 15, 0x1c8, 11),
+};
+
+static const struct mtk_composite top_aud_divs[] = {
+	DIV_GATE(CLK_TOP_AUD_I2S_M, "aud_i2s_m", "aud_sel", 0x0420, 0, 0x0420,
+		 8, 8),
+};
+
+static const struct mtk_clk_desc topck_desc = {
+	.fixed_clks = top_fixed_clks,
+	.num_fixed_clks = ARRAY_SIZE(top_fixed_clks),
+	.factor_clks = top_divs,
+	.num_factor_clks = ARRAY_SIZE(top_divs),
+	.mux_clks = top_muxes,
+	.num_mux_clks = ARRAY_SIZE(top_muxes),
+	.composite_clks = top_aud_divs,
+	.num_composite_clks = ARRAY_SIZE(top_aud_divs),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const char *const mcu_bus_div_parents[] = { "top_xtal", "ccipll2_b",
+						   "net1pll_d4" };
+
+static const char *const mcu_arm_div_parents[] = { "top_xtal", "arm_b",
+						   "net1pll_d4" };
+
+static struct mtk_composite mcu_muxes[] = {
+	/* bus_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_BUS_DIV_SEL, "mcu_bus_div_sel",
+		       mcu_bus_div_parents, 0x7C0, 9, 2, -1, CLK_IS_CRITICAL),
+	/* mp2_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_ARM_DIV_SEL, "mcu_arm_div_sel",
+		       mcu_arm_div_parents, 0x7A8, 9, 2, -1, CLK_IS_CRITICAL),
+};
+
+static const struct mtk_clk_desc mcusys_desc = {
+	.composite_clks = mcu_muxes,
+	.num_composite_clks = ARRAY_SIZE(mcu_muxes),
+};
+
+static const struct of_device_id of_match_clk_mt7988_topckgen[] = {
+	{ .compatible = "mediatek,mt7988-topckgen", .data = &topck_desc },
+	{ .compatible = "mediatek,mt7988-mcusys", .data = &mcusys_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_topckgen);
+
+static struct platform_driver clk_mt7988_topckgen_drv = {
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+	.driver = {
+		.name = "clk-mt7988-topckgen",
+		.of_match_table = of_match_clk_mt7988_topckgen,
+	},
+};
+module_platform_driver(clk_mt7988_topckgen_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-xfipll.c b/drivers/clk/mediatek/clk-mt7988-xfipll.c
new file mode 100644
index 0000000000000..5862818085a8c
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-xfipll.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+/* Register to control USXGMII XFI PLL analog */
+#define XFI_PLL_ANA_GLB8		0x108
+#define RG_XFI_PLL_ANA_SWWA		0x02283248
+
+static const struct mtk_gate_regs xfipll_cg_regs = {
+	.set_ofs = 0x8,
+	.clr_ofs = 0x8,
+	.sta_ofs = 0x8,
+};
+
+#define GATE_XFIPLL(_id, _name, _parent, _shift)                              \
+	{                                                                     \
+		.id = _id, .name = _name, .parent_name = _parent,             \
+		.regs = &xfipll_cg_regs, .shift = _shift,                     \
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,                       \
+	}
+
+static const struct mtk_fixed_factor xfipll_divs[] = {
+	FACTOR(CLK_XFIPLL_PLL, "xfipll_pll", "top_xtal", 125, 32),
+};
+
+static const struct mtk_gate xfipll_clks[] = {
+	GATE_XFIPLL(CLK_XFIPLL_PLL_EN, "xfipll_pll_en", "xfipll_pll", 31),
+};
+
+static const struct mtk_clk_desc xfipll_desc = {
+	.clks = xfipll_clks,
+	.num_clks = ARRAY_SIZE(xfipll_clks),
+	.factor_clks = xfipll_divs,
+	.num_factor_clks = ARRAY_SIZE(xfipll_divs),
+};
+
+static int clk_mt7988_xfipll_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	void __iomem *base = of_iomap(node, 0);
+
+	if (!base)
+		return -ENOMEM;
+
+	/* Apply software workaround for USXGMII PLL TCL issue */
+	writel(RG_XFI_PLL_ANA_SWWA, base + XFI_PLL_ANA_GLB8);
+	iounmap(base);
+
+	return mtk_clk_simple_probe(pdev);
+};
+
+static const struct of_device_id of_match_clk_mt7988_xfipll[] = {
+	{ .compatible = "mediatek,mt7988-xfi-pll", .data = &xfipll_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_xfipll);
+
+static struct platform_driver clk_mt7988_xfipll_drv = {
+	.driver = {
+		.name = "clk-mt7988-xfipll",
+		.of_match_table = of_match_clk_mt7988_xfipll,
+	},
+	.probe = clk_mt7988_xfipll_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_xfipll_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 XFI PLL clock driver");
+MODULE_LICENSE("GPL");
-- 
2.43.0


From shawnguo at kernel.org  Tue Dec  5 16:59:21 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 08:59:21 +0800
Subject: [PATCH] arm64: dts: imx93: correct mediamix power
In-Reply-To: <20231113100229.3885321-1-victor.liu@nxp.com>
References: <20231113100229.3885321-1-victor.liu@nxp.com>
Message-ID: <20231206005921.GM236001@dragon>

On Mon, Nov 13, 2023 at 06:02:29PM +0800, Liu Ying wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> "nic_media" clock should be enabled when power on/off mediamix, otherwise
> power on/off will fail. Because "media_axi_root" clock is the parent of
> "nic_media" clock, so replace "media_axi_clock" clock with "nic_media"
> clock in mediamix node.
> 
> Link: https://github.com/nxp-imx/linux-imx/commit/ce18e6d0071ae9df5486af8613708ebe920484be
> Fixes: f2d03ba997cb ("arm64: dts: imx93: reorder device nodes")
> Fixes: e85d3458a804 ("arm64: dts: imx93: add src node")
> Reviewed-by: Jacky Bai <ping.bai at nxp.com>
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> Signed-off-by: Liu Ying <victor.liu at nxp.com>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:03:16 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:03:16 +0800
Subject: [PATCH v3 1/2] dt-bindings: arm: Add compatible for SKOV i.MX8MP
 RevB board
In-Reply-To: <20231113113855.4076151-1-o.rempel@pengutronix.de>
References: <20231113113855.4076151-1-o.rempel@pengutronix.de>
Message-ID: <20231206010316.GN236001@dragon>

On Mon, Nov 13, 2023 at 12:38:54PM +0100, Oleksij Rempel wrote:
> Add DT compatible string for a SKOV i.MX8MP RevB climate controller board.
> 
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Applied both, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:07:36 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:07:36 +0800
Subject: [PATCH] arm64: dts: imx8qm-ss-dma: Pass lpuart dma-names
In-Reply-To: <20231113192139.22994-1-festevam@gmail.com>
References: <20231113192139.22994-1-festevam@gmail.com>
Message-ID: <20231206010736.GO236001@dragon>

On Mon, Nov 13, 2023 at 04:21:39PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per fsl-lpuart.yaml, when the 'dmas' property is used 'dma-names' should
> also be present.
> 
> Pass the lpuart 'dma-names' property to fix the following schema
> warnings:
> 
> imx8dxl-evk.dtb: serial at 5a060000: dma-names:0: 'rx' was expected
> 	from schema $id: http://devicetree.org/schemas/serial/fsl-lpuart.yaml#
> imx8dxl-evk.dtb: serial at 5a060000: dma-names:1: 'tx' was expected
> 	from schema $id: http://devicetree.org/schemas/serial/fsl-lpuart.yaml#
> imx8dxl-evk.dtb: serial at 5a060000: Unevaluated properties are not allowed ('dma-names' was unexpected)
> 	from schema $id: http://devicetree.org/schemas/serial/fsl-lpuart.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:08:12 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:08:12 +0800
Subject: [PATCH] arm64: dts: imx8mm-emcon-avari: Fix gpio-cells
In-Reply-To: <20231113192649.25669-1-festevam@gmail.com>
References: <20231113192649.25669-1-festevam@gmail.com>
Message-ID: <20231206010812.GP236001@dragon>

On Mon, Nov 13, 2023 at 04:26:49PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per nxp,pcf8575.yaml, #gpio-cells should be 2.
> 
> Change it to fix the following schema warning:
> 
> imx8mm-emcon-avari.dtb: gpio at 3a: #gpio-cells:0:0: 2 was expected
> 	from schema $id: http://devicetree.org/schemas/gpio/nxp,pcf8575.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:08:28 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:08:28 +0800
Subject: [PATCH] arm64: dts: imx8dxl-ss-conn: Fix Ethernet
 interrupt-names order
In-Reply-To: <20231113193548.28382-1-festevam@gmail.com>
References: <20231113193548.28382-1-festevam@gmail.com>
Message-ID: <20231206010828.GQ236001@dragon>

On Mon, Nov 13, 2023 at 04:35:48PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per snps,dwmac.yaml, the interrupt-names entries should be in the
> following order: "macirq", "eth_wake_irq";
> 
> Change it to fix the following schema warnings.
> 
> imx8dxl-evk.dtb: ethernet at 5b050000: interrupt-names:0: 'macirq' was expected
> 	from schema $id: http://devicetree.org/schemas/net/snps,dwmac.yaml#
> imx8dxl-evk.dtb: ethernet at 5b050000: interrupt-names:1: 'macirq' is not one of ['eth_wake_irq', 'eth_lpi']
> 	from schema $id: http://devicetree.org/schemas/net/snps,dwmac.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:08:44 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:08:44 +0800
Subject: [PATCH] arm64: dts: imx8mm-nitrogen-r2: Fix I2C mux subnode name
In-Reply-To: <20231113202521.37386-1-festevam@gmail.com>
References: <20231113202521.37386-1-festevam@gmail.com>
Message-ID: <20231206010844.GR236001@dragon>

On Mon, Nov 13, 2023 at 05:25:21PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per i2c-mux-pca954x.yaml, the I2C subnodes should follow the
> 'i2c@' format.
> 
> Change it to fix the following schema warning:
> 
> imx8mm-nitrogen-r2.dtb: i2c-mux at 70: Unevaluated properties are not allowed ('i2c3 at 0' was unexpected)
> 	from schema $id: http://devicetree.org/schemas/i2c/i2c-mux-pca954x.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:09:00 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:09:00 +0800
Subject: [PATCH] arm64: dts: imx8mp-debix-model-a: Use phy-mode
In-Reply-To: <20231113230400.67256-1-festevam@gmail.com>
References: <20231113230400.67256-1-festevam@gmail.com>
Message-ID: <20231206010900.GS236001@dragon>

On Mon, Nov 13, 2023 at 08:04:00PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> The property 'phy-connection-type' can be used to describe the interface
> type between the Ethernet device and the Ethernet PHY device.
> 
> However, snps,dwmac.yaml gives the following warning:
> 
> imx8mp-debix-model-a.dtb: ethernet at 30bf0000: 'phy-mode' is a required property
> 	from schema $id: http://devicetree.org/schemas/net/snps,dwmac.yaml#
> 
> To avoid the warning, switch to the more commonly used, 'phy-mode'
> property instead.
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:09:19 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:09:19 +0800
Subject: [PATCH v3] arm64: dts: imx8qxp-mek: Fix gpio-sbu-mux compatible
In-Reply-To: <20231113231229.69508-1-festevam@gmail.com>
References: <20231113231229.69508-1-festevam@gmail.com>
Message-ID: <20231206010919.GT236001@dragon>

On Mon, Nov 13, 2023 at 08:12:29PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per gpio-sbu-mux.yaml, the compatible entry is incomplete.
> 
> The imx8qxp-mek board uses a CBDTU02043, so complete the gpio-sbu-mux
> compatible accordingly.
> 
> This fixes the following schema warning:
> 
> imx8qxp-mek.dtb: gpio-sbu-mux: compatible:0: 'gpio-sbu-mux' is not one of ['onnn,fsusb43l10x', 'pericom,pi3usb102']
> 	from schema $id: http://devicetree.org/schemas/usb/gpio-sbu-mux.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:10:12 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:10:12 +0800
Subject: [PATCH 1/2] arm64: dts: imx93: Remove unexistent
 'shared-interrupt'
In-Reply-To: <20231113232016.70657-1-festevam@gmail.com>
References: <20231113232016.70657-1-festevam@gmail.com>
Message-ID: <20231206011012.GU236001@dragon>

On Mon, Nov 13, 2023 at 08:20:15PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> The 'shared-interrupt' property is not documented nor used anywhere.
> 
> Remove it.
> 
> This fixes the following schema warning:
> 
> imx93-11x11-evk.dtb: dma-controller at 42000000: Unevaluated properties are not allowed ('shared-interrupt' was unexpected)
> 	from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied both, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:22:27 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:22:27 +0800
Subject: [RESEND PATCH] ARM: imx: Use device_get_match_data()
In-Reply-To: <20231115210319.3747145-1-robh@kernel.org>
References: <20231115210319.3747145-1-robh@kernel.org>
Message-ID: <20231206012227.GW236001@dragon>

On Wed, Nov 15, 2023 at 03:03:18PM -0600, Rob Herring wrote:
> Use preferred device_get_match_data() instead of of_match_device() to
> get the driver match data. With this, adjust the includes to explicitly
> include the correct headers.
> 
> Signed-off-by: Rob Herring <robh at kernel.org>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:23:27 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:23:27 +0800
Subject: [PATCH 1/1] arm64: dts: tqma8mpql: Remove invalid/unused property
In-Reply-To: <20231117075957.2128070-1-alexander.stein@ew.tq-group.com>
References: <20231117075957.2128070-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231206012327.GX236001@dragon>

On Fri, Nov 17, 2023 at 08:59:57AM +0100, Alexander Stein wrote:
> 'dr_mode' is part of the USB DWC3 core, not the glue layer. Remove the
> property from glue layer. Fixes the dtbs_check warning:
> arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dtb: usb at 32f10108:
>   'dr_mode' does not match any of the regexes: '^usb@[0-9a-f]+$',
>   'pinctrl-[0-9]+'
>  from schema $id: http://devicetree.org/schemas/usb/fsl,imx8mp-dwc3.yaml#
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:32:47 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:32:47 +0800
Subject: [PATCH] ARM: dts: nxp: imx7d-pico: add cpu-supply nodes
In-Reply-To: <20231117232352.101713-1-lech.perczak@gmail.com>
References: <20231117232352.101713-1-lech.perczak@gmail.com>
Message-ID: <20231206013247.GY236001@dragon>

On Sat, Nov 18, 2023 at 12:23:52AM +0100, Lech Perczak wrote:
> The PICO-IMX7D SoM has the usual power supply configuration using
> output sw1a of PF3000 PMIC, which was defined in downstream derivative
> of linux-imx (see link) in the sources for "Android Things" devkit.
> It is required to support CPU frequency scaling.
> 
> Map the respective "cpu-supply" nodes of each core to sw1a of the PMIC.
> 
> Enabling them causes cpufreq-dt, and imx-thermal drivers to probe
> successfully, and CPU frequency scaling to function.
> 
> Link: https://android.googlesource.com/platform/hardware/bsp/kernel/nxp/imx-v4.1/+/o-iot-preview-5/arch/arm/boot/dts/imx7d-pico.dtsi#849
> 
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Cc: Sascha Hauer <s.hauer at pengutronix.de>
> 
> Signed-off-by: Lech Perczak <lech.perczak at gmail.com>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:34:21 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:34:21 +0800
Subject: [PATCH v3 5/5] arm64: dts: imx8dxl-ss-ddr: change ddr_pmu0
 compatible
In-Reply-To: <20231120093317.2652866-5-xu.yang_2@nxp.com>
References: <20231120093317.2652866-1-xu.yang_2@nxp.com>
 <20231120093317.2652866-5-xu.yang_2@nxp.com>
Message-ID: <20231206013421.GZ236001@dragon>

On Mon, Nov 20, 2023 at 05:33:17PM +0800, Xu Yang wrote:
> i.MX8DXL's ddr pmu has port/channel filter capabilities, but it still is
> compatible with "fsl,imx8-ddr-pmu". This will change the compatible.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:37:37 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:37:37 +0800
Subject: [PATCH v1 0/3] ARM: dts: imx: Add mmc aliases to Toradex DTS
In-Reply-To: <20231120205818.33120-1-francesco@dolcini.it>
References: <20231120205818.33120-1-francesco@dolcini.it>
Message-ID: <20231206013737.GA236001@dragon>

On Mon, Nov 20, 2023 at 09:58:15PM +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> Add mmc aliases to ensure a consistent mmc device naming across the
> Toradex SoM family, with this commit mmc0 is the on-module eMMC
> boot device and the not available mmc interfaces are removed.
> 
> Hiago De Franco (3):
>   ARM: dts: imx6qdl-apalis: Add usdhc aliases
>   ARM: dts: imx6qdl-colibri: Add usdhc aliases
>   ARM: dts: imx7d-colibri-emmc: Add usdhc aliases

Applied all, thanks!


From xu.yang_2 at nxp.com  Tue Dec  5 17:42:51 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Wed, 6 Dec 2023 01:42:51 +0000
Subject: [EXT] Re: [PATCH 1/3] dt-bindings: perf: fsl-imx-ddr: Add i.MX95
 compatible
In-Reply-To: <20231201-pointer-statue-f30a42b8102e@spud>
References: <20231127073208.1055466-1-xu.yang_2@nxp.com>
 <20231127-whoever-magical-5a7cf2b142e1@spud>
 <DB7PR04MB51460A715C6870642B6D7BBE8C81A@DB7PR04MB5146.eurprd04.prod.outlook.com>
 <20231201-pointer-statue-f30a42b8102e@spud>
Message-ID: <DB7PR04MB514668A8B172CD1A2187BC408C84A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Hi Conor,

> 
> On Fri, Dec 01, 2023 at 06:41:59AM +0000, Xu Yang wrote:
> > Hi Conor,
> >
> > >
> > > On Mon, Nov 27, 2023 at 03:32:06PM +0800, Xu Yang wrote:
> > > > i.MX95 has a more precise counting capability than i.MX93. This will add
> > > > a compatible for it.
> > >
> > > It is hard to tell from this comment, but I figure this "more precise
> > > capability" is not an option you can enable, but instead makes the
> > > programming model of this device different to that of the imx93?
> >
> > Actually, imx95 is compatible with imx93 except AXI ID filter capability.
> > But for AXI ID filter, imx95 is using different registers and bits from
> > imx93 for filter configuration.
> 
> This sounds like it conflicts with...
> 
> > To distinguish them, I need use different
> > compatible because programming model cannot recognize which device is
> > running.
> >
> > compatible = "fsl,imx95-ddr-pmu";
> 
> > compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu";
> 
> ...this. If drivers for the imx93 need changes to work on the imx95,
> then `compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu";` cannot be
> used. If they will work, with only the new imx95 features being
> non-functional, then you can use it.

Yes, it is. When compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu" is used,
only the new imx95 features is not functional, other basic function works for
both imx95 and imx93.

Thanks,
Xu Yang

> 
> > Both above compatible is okay for me. Therefore, "fsl,imx95-ddr-pmu" is needed.


From daniel at makrotopia.org  Tue Dec  5 17:43:44 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 01:43:44 +0000
Subject: [RFC PATCH v2 0/8] Add support for 10G Ethernet SerDes on MT7988
Message-ID: <cover.1701826319.git.daniel@makrotopia.org>

This series aims to add support for GMAC2 and GMAC3 of the MediaTek MT7988 SoC.
While the vendor SDK stuffs all this into their Ethernet driver, I've tried to
seperate things into a PHY driver, a PCS driver as well as changes to the
existing Ethernet and LynxI PCS driver.

 +--------------+   +----------------+   +------------------+
 |              +---|  USXGMII PCS   |---+                  |
 | Ethernet MAC |   +----------------+   | PEXTP SerDes PHY |
 |              +---|   SGMII PCS    |---+                  |
 +--------------+   +----------------+   +------------------+

Alltogether this allows using GMAC2 and GMAC3 with all possible interface modes,
including in-band-status if needed.

Note that this series depends on patch
"dt-bindings: clock: mediatek: add MT7988 clock IDs"
being merged before.

https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=807227

Changes since RFC v1:
 - drop patch inhibiting SGMII AN in 2500Base-X mode
 - make pcs-mtk-lynxi a proper platform driver
 - ... hence allowing to remove all the wrappers from the usxgmii driver
 - attach PEXTP to MAC instead of to USXGMII PCS

Daniel Golle (8):
  dt-bindings: phy: mediatek,xfi-pextp: add new bindings
  phy: add driver for MediaTek pextp 10GE SerDes PHY
  net: pcs: pcs-mtk-lynxi: add platform driver for MT7988
  dt-bindings: net: pcs: add bindings for MediaTek USXGMII PCS
  net: pcs: add driver for MediaTek USXGMII PCS
  dt-bindings: net: mediatek: remove wrongly added clocks and SerDes
  dt-bindings: net: mediatek,net: fix and complete mt7988-eth binding
  net: ethernet: mtk_eth_soc: add paths and SerDes modes for MT7988

 .../devicetree/bindings/net/mediatek,net.yaml | 180 ++++++--
 .../bindings/net/pcs/mediatek,usxgmii.yaml    |  60 +++
 .../bindings/phy/mediatek,xfi-pextp.yaml      |  80 ++++
 MAINTAINERS                                   |   3 +
 drivers/net/ethernet/mediatek/mtk_eth_path.c  | 122 +++++-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 284 ++++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h   | 107 ++++-
 drivers/net/pcs/Kconfig                       |  11 +
 drivers/net/pcs/Makefile                      |   1 +
 drivers/net/pcs/pcs-mtk-lynxi.c               | 170 ++++++-
 drivers/net/pcs/pcs-mtk-usxgmii.c             | 413 ++++++++++++++++++
 drivers/phy/mediatek/Kconfig                  |  11 +
 drivers/phy/mediatek/Makefile                 |   1 +
 drivers/phy/mediatek/phy-mtk-pextp.c          | 365 ++++++++++++++++
 include/linux/pcs/pcs-mtk-lynxi.h             |   1 +
 include/linux/pcs/pcs-mtk-usxgmii.h           |  26 ++
 16 files changed, 1746 insertions(+), 89 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
 create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml
 create mode 100644 drivers/net/pcs/pcs-mtk-usxgmii.c
 create mode 100644 drivers/phy/mediatek/phy-mtk-pextp.c
 create mode 100644 include/linux/pcs/pcs-mtk-usxgmii.h

-- 
2.43.0


From daniel at makrotopia.org  Tue Dec  5 17:43:55 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 01:43:55 +0000
Subject: [RFC PATCH v2 1/8] dt-bindings: phy: mediatek,xfi-pextp: add new
 bindings
In-Reply-To: <cover.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
Message-ID: <f57cc2bfadca35219707a0af507ad6e2e354e311.1701826319.git.daniel@makrotopia.org>

Add bindings for the MediaTek PEXTP Ethernet SerDes PHY found in the
MediaTek MT7988 SoC which can operate at various interfaces modes:

 * USXGMII
 * 10GBase-R
 * 5GBase-R
 * 2500Base-X
 * 1000Base-X
 * Cisco SGMII (MAC side)

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 .../bindings/phy/mediatek,xfi-pextp.yaml      | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml

diff --git a/Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml b/Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml
new file mode 100644
index 0000000000000..58c93368141e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,xfi-pextp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek XFI PEXTP SerDes PHY
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The MediaTek XFI PEXTP SerDes PHY provides the physical SerDes lanes
+  used by the MediaTek USXGMII PCS.
+
+properties:
+  $nodename:
+    pattern: "^phy@[0-9a-f]+$"
+
+  compatible:
+    const: mediatek,mt7988-xfi-pextp
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: XFI PHY clock
+      - description: XFI register clock
+
+  clock-names:
+    items:
+      - const: "xfipll"
+      - const: "topxtal"
+
+  resets:
+    items:
+      - description: PEXTP reset
+
+  mediatek,usxgmii-performance-errata:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      USXGMII0 on MT7988 suffers from a performance problem in 10GBase-R
+      mode which needs a work-around in the driver. The work-around is
+      enabled using this flag.
+
+  "#phy-cells":
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mediatek,mt7988-clk.h>
+    #include <dt-bindings/reset/mediatek,mt7988-resets.h>
+    soc {
+      #address-cells = <2>;
+      #size-cells = <2>;
+
+      phy at 11f20000 {
+        compatible = "mediatek,mt7988-xfi-pextp";
+        reg = <0 0x11f20000 0 0x10000>;
+        clocks = <&xfi_pll CLK_XFIPLL_PLL_EN>,
+                 <&topckgen CLK_TOP_XFI_PHY_0_XTAL_SEL>;
+        clock-names = "xfipll", "topxtal";
+        resets = <&watchdog MT7988_TOPRGU_XFI_PEXTP0_GRST>;
+        mediatek,usxgmii-performance-errata;
+        #phy-cells = <0>;
+      };
+    };
+
+...
-- 
2.43.0


From daniel at makrotopia.org  Tue Dec  5 17:44:08 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 01:44:08 +0000
Subject: [RFC PATCH v2 2/8] phy: add driver for MediaTek pextp 10GE SerDes PHY
In-Reply-To: <cover.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
Message-ID: <63636378a52dd1ea7370dbf0ca3037a7d24004b9.1701826319.git.daniel@makrotopia.org>

Add driver for MediaTek's pextp 10 Gigabit/s Ethernet SerDes PHY which
can be found in the MT7988 SoC.

The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
PHY_INTERFACE_MODE_* corresponding to the supported modes:

 * USXGMII
 * 10GBase-R
 * 5GBase-R
 * 2500Base-X
 * 1000Base-X
 * Cisco SGMII (MAC side)

In order to work-around a performance issue present on the first of
two PEXTP present in MT7988 special tuning is applied which can be
selected by adding the mediatek,usxgmii-performance-errata property to
the device tree node.

There is no documentation what-so-ever for the pextp registers and
this driver is based on a GPL licensed implementation found in
MediaTek's SDK.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 MAINTAINERS                          |   1 +
 drivers/phy/mediatek/Kconfig         |  11 +
 drivers/phy/mediatek/Makefile        |   1 +
 drivers/phy/mediatek/phy-mtk-pextp.c | 365 +++++++++++++++++++++++++++
 4 files changed, 378 insertions(+)
 create mode 100644 drivers/phy/mediatek/phy-mtk-pextp.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1ef2a16370619..1ea4555013a4d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13497,6 +13497,7 @@ L:	netdev at vger.kernel.org
 S:	Maintained
 F:	drivers/net/phy/mediatek-ge-soc.c
 F:	drivers/net/phy/mediatek-ge.c
+F:	drivers/phy/mediatek/phy-mtk-pextp.c
 
 MEDIATEK I2C CONTROLLER DRIVER
 M:	Qii Wang <qii.wang at mediatek.com>
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index 3125ecb5d119f..a7749a6d96541 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -13,6 +13,17 @@ config PHY_MTK_PCIE
 	  callback for PCIe GEN3 port, it supports software efuse
 	  initialization.
 
+config PHY_MTK_PEXTP
+	tristate "MediaTek PEXTP Driver"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	depends on OF && OF_ADDRESS
+	depends on HAS_IOMEM
+	select GENERIC_PHY
+	help
+	  Say 'Y' here to add support for MediaTek pextp PHY driver.
+	  The driver provides access to the Ethernet SerDes PHY supporting
+	  various 1GE, 2.5GE, 5GE and 10GE modes.
+
 config PHY_MTK_TPHY
 	tristate "MediaTek T-PHY Driver"
 	depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index c9a50395533eb..ca60c7b9b02ac 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PHY_MTK_PCIE)		+= phy-mtk-pcie.o
 obj-$(CONFIG_PHY_MTK_TPHY)		+= phy-mtk-tphy.o
 obj-$(CONFIG_PHY_MTK_UFS)		+= phy-mtk-ufs.o
 obj-$(CONFIG_PHY_MTK_XSPHY)		+= phy-mtk-xsphy.o
+obj-$(CONFIG_PHY_MTK_PEXTP)		+= phy-mtk-pextp.o
 
 phy-mtk-hdmi-drv-y			:= phy-mtk-hdmi.o
 phy-mtk-hdmi-drv-y			+= phy-mtk-hdmi-mt2701.o
diff --git a/drivers/phy/mediatek/phy-mtk-pextp.c b/drivers/phy/mediatek/phy-mtk-pextp.c
new file mode 100644
index 0000000000000..e5bfab86f95a5
--- /dev/null
+++ b/drivers/phy/mediatek/phy-mtk-pextp.c
@@ -0,0 +1,365 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* MediaTek 10GE SerDes PHY driver
+ *
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ * based on mtk_usxgmii.c found in MediaTek's SDK released under GPL-2.0
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Henry Yen <henry.yen at mediatek.com>
+ */
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/netdevice.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/reset.h>
+#include <linux/phy.h>
+#include <linux/phy/phy.h>
+
+struct mtk_pextp_phy {
+	void __iomem		*base;
+	struct device		*dev;
+	struct reset_control	*reset;
+	struct clk		*clk[2];
+	bool			da_war;
+};
+
+static bool mtk_interface_mode_is_xgmii(phy_interface_t interface)
+{
+	switch (interface) {
+	case PHY_INTERFACE_MODE_INTERNAL:
+	case PHY_INTERFACE_MODE_USXGMII:
+	case PHY_INTERFACE_MODE_10GBASER:
+	case PHY_INTERFACE_MODE_5GBASER:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static void mtk_pextp_setup(struct mtk_pextp_phy *pextp, phy_interface_t interface)
+{
+	bool is_10g = (interface == PHY_INTERFACE_MODE_10GBASER ||
+		       interface == PHY_INTERFACE_MODE_USXGMII);
+	bool is_2p5g = (interface == PHY_INTERFACE_MODE_2500BASEX);
+	bool is_5g = (interface == PHY_INTERFACE_MODE_5GBASER);
+
+	dev_dbg(pextp->dev, "setting up for mode %s\n", phy_modes(interface));
+
+	/* Setup operation mode */
+	if (is_10g)
+		iowrite32(0x00C9071C, pextp->base + 0x9024);
+	else
+		iowrite32(0x00D9071C, pextp->base + 0x9024);
+
+	if (is_5g)
+		iowrite32(0xAAA5A5AA, pextp->base + 0x2020);
+	else
+		iowrite32(0xAA8585AA, pextp->base + 0x2020);
+
+	if (is_2p5g || is_5g || is_10g) {
+		iowrite32(0x0C020707, pextp->base + 0x2030);
+		iowrite32(0x0E050F0F, pextp->base + 0x2034);
+		iowrite32(0x00140032, pextp->base + 0x2040);
+	} else {
+		iowrite32(0x0C020207, pextp->base + 0x2030);
+		iowrite32(0x0E05050F, pextp->base + 0x2034);
+		iowrite32(0x00200032, pextp->base + 0x2040);
+	}
+
+	if (is_2p5g || is_10g)
+		iowrite32(0x00C014AA, pextp->base + 0x50F0);
+	else if (is_5g)
+		iowrite32(0x00C018AA, pextp->base + 0x50F0);
+	else
+		iowrite32(0x00C014BA, pextp->base + 0x50F0);
+
+	if (is_5g) {
+		iowrite32(0x3777812B, pextp->base + 0x50E0);
+		iowrite32(0x005C9CFF, pextp->base + 0x506C);
+		iowrite32(0x9DFAFAFA, pextp->base + 0x5070);
+		iowrite32(0x273F3F3F, pextp->base + 0x5074);
+		iowrite32(0xA8883868, pextp->base + 0x5078);
+		iowrite32(0x14661466, pextp->base + 0x507C);
+	} else {
+		iowrite32(0x3777C12B, pextp->base + 0x50E0);
+		iowrite32(0x005F9CFF, pextp->base + 0x506C);
+		iowrite32(0x9D9DFAFA, pextp->base + 0x5070);
+		iowrite32(0x27273F3F, pextp->base + 0x5074);
+		iowrite32(0xA7883C68, pextp->base + 0x5078);
+		iowrite32(0x11661166, pextp->base + 0x507C);
+	}
+
+	if (is_2p5g || is_10g) {
+		iowrite32(0x0E000AAF, pextp->base + 0x5080);
+		iowrite32(0x08080D0D, pextp->base + 0x5084);
+		iowrite32(0x02030909, pextp->base + 0x5088);
+	} else if (is_5g) {
+		iowrite32(0x0E001ABF, pextp->base + 0x5080);
+		iowrite32(0x080B0D0D, pextp->base + 0x5084);
+		iowrite32(0x02050909, pextp->base + 0x5088);
+	} else {
+		iowrite32(0x0E000EAF, pextp->base + 0x5080);
+		iowrite32(0x08080E0D, pextp->base + 0x5084);
+		iowrite32(0x02030B09, pextp->base + 0x5088);
+	}
+
+	if (is_5g) {
+		iowrite32(0x0C000000, pextp->base + 0x50E4);
+		iowrite32(0x04000000, pextp->base + 0x50E8);
+	} else {
+		iowrite32(0x0C0C0000, pextp->base + 0x50E4);
+		iowrite32(0x04040000, pextp->base + 0x50E8);
+	}
+
+	if (is_2p5g || mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x0F0F0C06, pextp->base + 0x50EC);
+	else
+		iowrite32(0x0F0F0606, pextp->base + 0x50EC);
+
+	if (is_5g) {
+		iowrite32(0x50808C8C, pextp->base + 0x50A8);
+		iowrite32(0x18000000, pextp->base + 0x6004);
+	} else {
+		iowrite32(0x506E8C8C, pextp->base + 0x50A8);
+		iowrite32(0x18190000, pextp->base + 0x6004);
+	}
+
+	if (is_10g)
+		iowrite32(0x01423342, pextp->base + 0x00F8);
+	else if (is_5g)
+		iowrite32(0x00A132A1, pextp->base + 0x00F8);
+	else if (is_2p5g)
+		iowrite32(0x009C329C, pextp->base + 0x00F8);
+	else
+		iowrite32(0x00FA32FA, pextp->base + 0x00F8);
+
+	/* Force SGDT_OUT off and select PCS */
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x80201F20, pextp->base + 0x00F4);
+	else
+		iowrite32(0x80201F21, pextp->base + 0x00F4);
+
+	/* Force GLB_CKDET_OUT */
+	iowrite32(0x00050C00, pextp->base + 0x0030);
+
+	/* Force AEQ on */
+	iowrite32(0x02002800, pextp->base + 0x0070);
+	ndelay(1020);
+
+	/* Setup DA default value */
+	iowrite32(0x00000020, pextp->base + 0x30B0);
+	iowrite32(0x00008A01, pextp->base + 0x3028);
+	iowrite32(0x0000A884, pextp->base + 0x302C);
+	iowrite32(0x00083002, pextp->base + 0x3024);
+	if (mtk_interface_mode_is_xgmii(interface)) {
+		iowrite32(0x00022220, pextp->base + 0x3010);
+		iowrite32(0x0F020A01, pextp->base + 0x5064);
+		iowrite32(0x06100600, pextp->base + 0x50B4);
+		if (interface == PHY_INTERFACE_MODE_USXGMII)
+			iowrite32(0x40704000, pextp->base + 0x3048);
+		else
+			iowrite32(0x47684100, pextp->base + 0x3048);
+	} else {
+		iowrite32(0x00011110, pextp->base + 0x3010);
+		iowrite32(0x40704000, pextp->base + 0x3048);
+	}
+
+	if (!mtk_interface_mode_is_xgmii(interface) && !is_2p5g)
+		iowrite32(0x0000C000, pextp->base + 0x3064);
+
+	if (interface == PHY_INTERFACE_MODE_USXGMII) {
+		iowrite32(0xA8000000, pextp->base + 0x3050);
+		iowrite32(0x000000AA, pextp->base + 0x3054);
+	} else if (mtk_interface_mode_is_xgmii(interface)) {
+		iowrite32(0x00000000, pextp->base + 0x3050);
+		iowrite32(0x00000000, pextp->base + 0x3054);
+	} else {
+		iowrite32(0xA8000000, pextp->base + 0x3050);
+		iowrite32(0x000000AA, pextp->base + 0x3054);
+	}
+
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x00000F00, pextp->base + 0x306C);
+	else if (is_2p5g)
+		iowrite32(0x22000F00, pextp->base + 0x306C);
+	else
+		iowrite32(0x20200F00, pextp->base + 0x306C);
+
+	if (interface == PHY_INTERFACE_MODE_10GBASER && pextp->da_war)
+		iowrite32(0x0007B400, pextp->base + 0xA008);
+
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x00040000, pextp->base + 0xA060);
+	else
+		iowrite32(0x00050000, pextp->base + 0xA060);
+
+	if (is_10g)
+		iowrite32(0x00000001, pextp->base + 0x90D0);
+	else if (is_5g)
+		iowrite32(0x00000003, pextp->base + 0x90D0);
+	else if (is_2p5g)
+		iowrite32(0x00000005, pextp->base + 0x90D0);
+	else
+		iowrite32(0x00000007, pextp->base + 0x90D0);
+
+	/* Release reset */
+	iowrite32(0x0200E800, pextp->base + 0x0070);
+	usleep_range(150, 500);
+
+	/* Switch to P0 */
+	iowrite32(0x0200C111, pextp->base + 0x0070);
+	ndelay(1020);
+	iowrite32(0x0200C101, pextp->base + 0x0070);
+	usleep_range(15, 50);
+
+	if (mtk_interface_mode_is_xgmii(interface)) {
+		/* Switch to Gen3 */
+		iowrite32(0x0202C111, pextp->base + 0x0070);
+	} else {
+		/* Switch to Gen2 */
+		iowrite32(0x0201C111, pextp->base + 0x0070);
+	}
+	ndelay(1020);
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x0202C101, pextp->base + 0x0070);
+	else
+		iowrite32(0x0201C101, pextp->base + 0x0070);
+	usleep_range(100, 500);
+	iowrite32(0x00000030, pextp->base + 0x30B0);
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x80201F00, pextp->base + 0x00F4);
+	else
+		iowrite32(0x80201F01, pextp->base + 0x00F4);
+
+	iowrite32(0x30000000, pextp->base + 0x3040);
+	usleep_range(400, 1000);
+}
+
+static int mtk_pextp_set_mode(struct phy *phy, enum phy_mode mode, int submode)
+{
+	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
+
+	if (mode != PHY_MODE_ETHERNET)
+		return -EINVAL;
+
+	switch (submode) {
+	case PHY_INTERFACE_MODE_1000BASEX:
+	case PHY_INTERFACE_MODE_2500BASEX:
+	case PHY_INTERFACE_MODE_SGMII:
+	case PHY_INTERFACE_MODE_5GBASER:
+	case PHY_INTERFACE_MODE_10GBASER:
+	case PHY_INTERFACE_MODE_USXGMII:
+		mtk_pextp_setup(pextp, submode);
+		return 0;
+	default:
+		return -EINVAL;
+	}
+}
+
+static int mtk_pextp_reset(struct phy *phy)
+{
+	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
+
+	reset_control_assert(pextp->reset);
+	usleep_range(100, 500);
+	reset_control_deassert(pextp->reset);
+	usleep_range(1, 10);
+
+	return 0;
+}
+
+static int mtk_pextp_power_on(struct phy *phy)
+{
+	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
+	int ret;
+
+	ret = clk_prepare_enable(pextp->clk[0]);
+	if (ret)
+		return ret;
+
+	return clk_prepare_enable(pextp->clk[1]);
+}
+
+static int mtk_pextp_power_off(struct phy *phy)
+{
+	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
+
+	clk_disable_unprepare(pextp->clk[1]);
+	clk_disable_unprepare(pextp->clk[0]);
+
+	return 0;
+}
+
+static const struct phy_ops mtk_pextp_ops = {
+	.power_on	= mtk_pextp_power_on,
+	.power_off	= mtk_pextp_power_off,
+	.set_mode	= mtk_pextp_set_mode,
+	.reset		= mtk_pextp_reset,
+	.owner		= THIS_MODULE,
+};
+
+static int mtk_pextp_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct phy_provider *phy_provider;
+	struct mtk_pextp_phy *pextp;
+	struct phy *phy;
+
+	if (!np)
+		return -ENODEV;
+
+	pextp = devm_kzalloc(&pdev->dev, sizeof(*pextp), GFP_KERNEL);
+	if (!pextp)
+		return -ENOMEM;
+
+	pextp->base = devm_of_iomap(&pdev->dev, np, 0, NULL);
+	if (!pextp->base)
+		return -EIO;
+
+	pextp->dev = &pdev->dev;
+	pextp->clk[0] = devm_clk_get(&pdev->dev, "topxtal");
+	if (IS_ERR(pextp->clk[0]))
+		return PTR_ERR(pextp->clk[0]);
+
+	pextp->clk[1] = devm_clk_get(&pdev->dev, "xfipll");
+	if (IS_ERR(pextp->clk[1]))
+		return PTR_ERR(pextp->clk[1]);
+
+	pextp->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+	if (IS_ERR(pextp->reset))
+		return PTR_ERR(pextp->reset);
+
+	pextp->da_war = of_property_read_bool(np, "mediatek,usxgmii-performance-errata");
+
+	phy = devm_phy_create(&pdev->dev, NULL, &mtk_pextp_ops);
+	if (IS_ERR(phy))
+		return PTR_ERR(phy);
+
+	phy_set_drvdata(phy, pextp);
+
+	phy_provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
+
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id mtk_pextp_match[] = {
+	{ .compatible = "mediatek,mt7988-xfi-pextp", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, mtk_pextp_match);
+
+static struct platform_driver mtk_pextp_driver = {
+	.probe = mtk_pextp_probe,
+	.driver = {
+		.name = "mtk-pextp",
+		.of_match_table = mtk_pextp_match,
+	},
+};
+module_platform_driver(mtk_pextp_driver);
+
+MODULE_DESCRIPTION("MediaTek pextp SerDes PHY driver");
+MODULE_AUTHOR("Daniel Golle <daniel at makrotopia.org>");
+MODULE_LICENSE("GPL");
-- 
2.43.0


From daniel at makrotopia.org  Tue Dec  5 17:44:17 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 01:44:17 +0000
Subject: [RFC PATCH v2 3/8] net: pcs: pcs-mtk-lynxi: add platform driver for
 MT7988
In-Reply-To: <cover.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
Message-ID: <68bb81ac6bf99393c8de256f42e5715626590af8.1701826319.git.daniel@makrotopia.org>

Introduce a proper platform MFD driver for the LynxI (H)SGMII PCS which
is going to initially be used for the MT7988 SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 drivers/net/pcs/pcs-mtk-lynxi.c   | 170 ++++++++++++++++++++++++++++--
 include/linux/pcs/pcs-mtk-lynxi.h |   1 +
 2 files changed, 160 insertions(+), 11 deletions(-)

diff --git a/drivers/net/pcs/pcs-mtk-lynxi.c b/drivers/net/pcs/pcs-mtk-lynxi.c
index 8501dd365279b..558d6351399b5 100644
--- a/drivers/net/pcs/pcs-mtk-lynxi.c
+++ b/drivers/net/pcs/pcs-mtk-lynxi.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright (c) 2018-2019 MediaTek Inc.
-/* A library for MediaTek SGMII circuit
+/* A library and platform driver for the MediaTek LynxI SGMII circuit
  *
  * Author: Sean Wang <sean.wang at mediatek.com>
  * Author: Alexander Couzens <lynxis at fe80.eu>
@@ -8,11 +8,16 @@
  *
  */
 
+#include <linux/clk.h>
 #include <linux/mdio.h>
+#include <linux/mfd/syscon.h>
 #include <linux/of.h>
+#include <linux/of_platform.h>
 #include <linux/pcs/pcs-mtk-lynxi.h>
 #include <linux/phylink.h>
+#include <linux/platform_device.h>
 #include <linux/regmap.h>
+#include <linux/reset.h>
 
 /* SGMII subsystem config registers */
 /* BMCR (low 16) BMSR (high 16) */
@@ -65,6 +70,8 @@
 #define SGMII_PN_SWAP_MASK		GENMASK(1, 0)
 #define SGMII_PN_SWAP_TX_RX		(BIT(0) | BIT(1))
 
+#define MTK_NETSYS_V3_AMA_RGC3		0x128
+
 /* struct mtk_pcs_lynxi -  This structure holds each sgmii regmap andassociated
  *                         data
  * @regmap:                The register map pointing at the range used to setup
@@ -81,6 +88,10 @@ struct mtk_pcs_lynxi {
 	phy_interface_t		interface;
 	struct			phylink_pcs pcs;
 	u32			flags;
+	struct reset_control	*rstc;
+	struct clk		*sgmii_sel;
+	struct clk		*sgmii_rx;
+	struct clk		*sgmii_tx;
 };
 
 static struct mtk_pcs_lynxi *pcs_to_mtk_pcs_lynxi(struct phylink_pcs *pcs)
@@ -102,6 +113,17 @@ static void mtk_pcs_lynxi_get_state(struct phylink_pcs *pcs,
 					 FIELD_GET(SGMII_LPA, adv));
 }
 
+static void mtk_sgmii_reset(struct mtk_pcs_lynxi *mpcs)
+{
+	if (!mpcs->rstc)
+		return;
+
+	reset_control_assert(mpcs->rstc);
+	usleep_range(100, 500);
+	reset_control_deassert(mpcs->rstc);
+	mdelay(10);
+}
+
 static int mtk_pcs_lynxi_config(struct phylink_pcs *pcs, unsigned int neg_mode,
 				phy_interface_t interface,
 				const unsigned long *advertising,
@@ -147,6 +169,7 @@ static int mtk_pcs_lynxi_config(struct phylink_pcs *pcs, unsigned int neg_mode,
 				SGMII_PHYA_PWD);
 
 		/* Reset SGMII PCS state */
+		mtk_sgmii_reset(mpcs);
 		regmap_set_bits(mpcs->regmap, SGMSYS_RESERVED_0,
 				SGMII_SW_RESET);
 
@@ -233,10 +256,29 @@ static void mtk_pcs_lynxi_link_up(struct phylink_pcs *pcs,
 	}
 }
 
+static int mtk_pcs_lynxi_enable(struct phylink_pcs *pcs)
+{
+	struct mtk_pcs_lynxi *mpcs = pcs_to_mtk_pcs_lynxi(pcs);
+
+	if (mpcs->sgmii_tx && mpcs->sgmii_rx) {
+		clk_prepare_enable(mpcs->sgmii_rx);
+		clk_prepare_enable(mpcs->sgmii_tx);
+	}
+
+	return 0;
+}
+
 static void mtk_pcs_lynxi_disable(struct phylink_pcs *pcs)
 {
 	struct mtk_pcs_lynxi *mpcs = pcs_to_mtk_pcs_lynxi(pcs);
 
+	regmap_set_bits(mpcs->regmap, SGMSYS_QPHY_PWR_STATE_CTRL, SGMII_PHYA_PWD);
+
+	if (mpcs->sgmii_tx && mpcs->sgmii_rx) {
+		clk_disable_unprepare(mpcs->sgmii_tx);
+		clk_disable_unprepare(mpcs->sgmii_rx);
+	}
+
 	mpcs->interface = PHY_INTERFACE_MODE_NA;
 }
 
@@ -246,11 +288,12 @@ static const struct phylink_pcs_ops mtk_pcs_lynxi_ops = {
 	.pcs_an_restart = mtk_pcs_lynxi_restart_an,
 	.pcs_link_up = mtk_pcs_lynxi_link_up,
 	.pcs_disable = mtk_pcs_lynxi_disable,
+	.pcs_enable = mtk_pcs_lynxi_enable,
 };
 
-struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
-					 struct regmap *regmap, u32 ana_rgc3,
-					 u32 flags)
+static struct phylink_pcs *mtk_pcs_lynxi_init(struct device *dev, struct regmap *regmap,
+					      u32 ana_rgc3, u32 flags,
+					      struct mtk_pcs_lynxi *prealloc)
 {
 	struct mtk_pcs_lynxi *mpcs;
 	u32 id, ver;
@@ -258,29 +301,33 @@ struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
 
 	ret = regmap_read(regmap, SGMSYS_PCS_DEVICE_ID, &id);
 	if (ret < 0)
-		return NULL;
+		return ERR_PTR(ret);
 
 	if (id != SGMII_LYNXI_DEV_ID) {
 		dev_err(dev, "unknown PCS device id %08x\n", id);
-		return NULL;
+		return ERR_PTR(-ENODEV);
 	}
 
 	ret = regmap_read(regmap, SGMSYS_PCS_SCRATCH, &ver);
 	if (ret < 0)
-		return NULL;
+		return ERR_PTR(ret);
 
 	ver = FIELD_GET(SGMII_DEV_VERSION, ver);
 	if (ver != 0x1) {
 		dev_err(dev, "unknown PCS device version %04x\n", ver);
-		return NULL;
+		return ERR_PTR(-ENODEV);
 	}
 
 	dev_dbg(dev, "MediaTek LynxI SGMII PCS (id 0x%08x, ver 0x%04x)\n", id,
 		ver);
 
-	mpcs = kzalloc(sizeof(*mpcs), GFP_KERNEL);
-	if (!mpcs)
-		return NULL;
+	if (prealloc) {
+		mpcs = prealloc;
+	} else {
+		mpcs = kzalloc(sizeof(*mpcs), GFP_KERNEL);
+		if (!mpcs)
+			return ERR_PTR(-ENOMEM);
+	};
 
 	mpcs->ana_rgc3 = ana_rgc3;
 	mpcs->regmap = regmap;
@@ -291,6 +338,13 @@ struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
 	mpcs->interface = PHY_INTERFACE_MODE_NA;
 
 	return &mpcs->pcs;
+};
+
+struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
+					 struct regmap *regmap, u32 ana_rgc3,
+					 u32 flags)
+{
+	return mtk_pcs_lynxi_init(dev, regmap, ana_rgc3, flags, NULL);
 }
 EXPORT_SYMBOL(mtk_pcs_lynxi_create);
 
@@ -303,4 +357,98 @@ void mtk_pcs_lynxi_destroy(struct phylink_pcs *pcs)
 }
 EXPORT_SYMBOL(mtk_pcs_lynxi_destroy);
 
+static int mtk_pcs_lynxi_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct mtk_pcs_lynxi *mpcs;
+	struct phylink_pcs *pcs;
+	struct regmap *regmap;
+	u32 flags = 0;
+
+	mpcs = devm_kzalloc(dev, sizeof(*mpcs), GFP_KERNEL);
+	if (!mpcs)
+		return -ENOMEM;
+
+	regmap = syscon_node_to_regmap(np->parent);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	if (of_property_read_bool(np->parent, "mediatek,pnswap"))
+		flags |= MTK_SGMII_FLAG_PN_SWAP;
+
+	mpcs->rstc = of_reset_control_get_shared(np->parent, NULL);
+	if (IS_ERR(mpcs->rstc))
+		return PTR_ERR(mpcs->rstc);
+
+	reset_control_deassert(mpcs->rstc);
+	mpcs->sgmii_sel = devm_clk_get_enabled(dev, "sgmii_sel");
+	if (IS_ERR(mpcs->sgmii_sel))
+		return PTR_ERR(mpcs->sgmii_sel);
+
+	mpcs->sgmii_rx = devm_clk_get(dev, "sgmii_rx");
+	if (IS_ERR(mpcs->sgmii_rx))
+		return PTR_ERR(mpcs->sgmii_rx);
+
+	mpcs->sgmii_tx = devm_clk_get(dev, "sgmii_tx");
+	if (IS_ERR(mpcs->sgmii_tx))
+		return PTR_ERR(mpcs->sgmii_tx);
+
+	pcs = mtk_pcs_lynxi_init(dev, regmap, (uintptr_t)of_device_get_match_data(dev),
+				 flags, mpcs);
+	if (IS_ERR(pcs))
+		return PTR_ERR(pcs);
+
+	regmap_set_bits(mpcs->regmap, SGMSYS_QPHY_PWR_STATE_CTRL, SGMII_PHYA_PWD);
+
+	platform_set_drvdata(pdev, mpcs);
+
+	return 0;
+}
+
+static const struct of_device_id mtk_pcs_lynxi_of_match[] = {
+	{ .compatible = "mediatek,mt7988-sgmii", .data = (void *)MTK_NETSYS_V3_AMA_RGC3 },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mtk_pcs_lynxi_of_match);
+
+struct phylink_pcs *mtk_pcs_lynxi_select_pcs(struct device_node *np, phy_interface_t mode)
+{
+	struct platform_device *pdev;
+	struct mtk_pcs_lynxi *mpcs;
+
+	if (!np)
+		return NULL;
+
+	if (!of_device_is_available(np))
+		return ERR_PTR(-ENODEV);
+
+	if (!of_match_node(mtk_pcs_lynxi_of_match, np))
+		return ERR_PTR(-EINVAL);
+
+	pdev = of_find_device_by_node(np);
+	if (!pdev || !platform_get_drvdata(pdev)) {
+		if (pdev)
+			put_device(&pdev->dev);
+		return ERR_PTR(-EPROBE_DEFER);
+	}
+
+	mpcs = platform_get_drvdata(pdev);
+	put_device(&pdev->dev);
+
+	return &mpcs->pcs;
+}
+EXPORT_SYMBOL(mtk_pcs_lynxi_select_pcs);
+
+static struct platform_driver mtk_pcs_lynxi_driver = {
+	.driver = {
+		.name = "mtk-pcs-lynxi",
+		.of_match_table = mtk_pcs_lynxi_of_match,
+	},
+	.probe = mtk_pcs_lynxi_probe,
+};
+module_platform_driver(mtk_pcs_lynxi_driver);
+
+MODULE_AUTHOR("Daniel Golle <daniel at makrotopia.org>");
+MODULE_DESCRIPTION("MediaTek LynxI HSGMII PCS");
 MODULE_LICENSE("GPL");
diff --git a/include/linux/pcs/pcs-mtk-lynxi.h b/include/linux/pcs/pcs-mtk-lynxi.h
index be3b4ab32f4a7..5db19d6a7261f 100644
--- a/include/linux/pcs/pcs-mtk-lynxi.h
+++ b/include/linux/pcs/pcs-mtk-lynxi.h
@@ -10,4 +10,5 @@ struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
 					 struct regmap *regmap,
 					 u32 ana_rgc3, u32 flags);
 void mtk_pcs_lynxi_destroy(struct phylink_pcs *pcs);
+struct phylink_pcs *mtk_pcs_lynxi_select_pcs(struct device_node *np, phy_interface_t mode);
 #endif
-- 
2.43.0


From shawnguo at kernel.org  Tue Dec  5 17:44:29 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:44:29 +0800
Subject: [PATCH v2] ARM: imx: Check return value of devm_kasprintf in
 imx_mmdc_perf_init
In-Reply-To: <20231122064636.7268-1-chentao@kylinos.cn>
References: <20231122064636.7268-1-chentao@kylinos.cn>
Message-ID: <20231206014429.GB236001@dragon>

On Wed, Nov 22, 2023 at 02:46:36PM +0800, Kunwu Chan wrote:
> devm_kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. Ensure the allocation was successful
> by checking the pointer validity.
> 
> Release the id allocated in 'mmdc_pmu_init' when 'devm_kasprintf'
> return NULL
> 
> Suggested-by: Ahmad Fatoum <a.fatoum at pengutronix.de>
> Fixes: e76bdfd7403a ("ARM: imx: Added perf functionality to mmdc driver")
> Signed-off-by: Kunwu Chan <chentao at kylinos.cn>

Applied, thanks!


From daniel at makrotopia.org  Tue Dec  5 17:44:27 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 01:44:27 +0000
Subject: [RFC PATCH v2 4/8] dt-bindings: net: pcs: add bindings for MediaTek
 USXGMII PCS
In-Reply-To: <cover.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
Message-ID: <14c3eb3022fac2af105950eb161990ecfb17c016.1701826319.git.daniel@makrotopia.org>

MediaTek's USXGMII can be found in the MT7988 SoC. We need to access
it in order to configure and monitor the Ethernet SerDes link in
USXGMII, 10GBase-R and 5GBase-R mode. By including a wrapped
legacy 1000Base-X/2500Base-X/Cisco SGMII LynxI PCS as well, those
interface modes are also available.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 .../bindings/net/pcs/mediatek,usxgmii.yaml    | 100 ++++++++++++++++++
 1 file changed, 100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml

diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
new file mode 100644
index 0000000000000..9a798c0d2fdd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pcs/mediatek,usxgmii.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek USXGMII PCS
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The MediaTek USXGMII PCS provides physical link control and status
+  for USXGMII, 10GBase-R and 5GBase-R links on the SerDes interfaces
+  provided by the PEXTP PHY.
+  In order to also support legacy 2500Base-X, 1000Base-X and Cisco
+  SGMII an existing mediatek,*-sgmiisys LynxI PCS is wrapped to
+  provide those interfaces modes on the same SerDes interfaces shared
+  with the USXGMII PCS.
+
+properties:
+  $nodename:
+    pattern: "^pcs@[0-9a-f]+$"
+
+  compatible:
+    const: mediatek,mt7988-usxgmiisys
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: USXGMII top-level clock
+      - description: SGMII top-level clock
+      - description: SGMII subsystem TX clock
+      - description: SGMII subsystem RX clock
+      - description: XFI PLL clock
+
+  clock-names:
+    items:
+      - const: usxgmii
+      - const: sgmii_sel
+      - const: sgmii_tx
+      - const: sgmii_rx
+      - const: xfi_pll
+
+  phys:
+    items:
+      - description: PEXTP SerDes PHY
+
+  mediatek,sgmiisys:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      Phandle to the syscon node of the corresponding SGMII LynxI PCS.
+
+  resets:
+    items:
+      - description: XFI reset
+      - description: SGMII reset
+
+  reset-names:
+    items:
+      - const: xfi
+      - const: sgmii
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - phys
+  - mediatek,sgmiisys
+  - resets
+  - reset-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mediatek,mt7988-clk.h>
+    #include <dt-bindings/reset/mediatek,mt7988-resets.h>
+    soc {
+      #address-cells = <2>;
+      #size-cells = <2>;
+        usxgmiisys0: pcs at 10080000 {
+          compatible = "mediatek,mt7988-usxgmiisys";
+          reg = <0 0x10080000 0 0x1000>;
+          clocks = <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>,
+                   <&topckgen CLK_TOP_SGM_0_SEL>,
+                   <&sgmiisys0 CLK_SGM0_TX_EN>,
+                   <&sgmiisys0 CLK_SGM0_RX_EN>,
+                   <&xfi_pll CLK_XFIPLL_PLL_EN>;
+          clock-names = "usxgmii", "sgmii_sel", "sgmii_tx", "sgmii_rx", "xfi_pll";
+          resets = <&watchdog MT7988_TOPRGU_XFI0_GRST>,
+                   <&watchdog MT7988_TOPRGU_SGMII0_GRST>;
+          reset-names = "xfi", "sgmii";
+          phys = <&xfi_pextp0>;
+          mediatek,sgmiisys = <&sgmiisys0>;
+        };
+    };
-- 
2.43.0


From daniel at makrotopia.org  Tue Dec  5 17:44:38 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 01:44:38 +0000
Subject: [RFC PATCH v2 5/8] net: pcs: add driver for MediaTek USXGMII PCS
In-Reply-To: <cover.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
Message-ID: <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>

Add driver for USXGMII PCS found in the MediaTek MT7988 SoC and supporting
USXGMII, 10GBase-R and 5GBase-R interface modes. In order to support
Cisco SGMII, 1000Base-X and 2500Base-X via the also present LynxI PCS
create a wrapped PCS taking care of the components shared between the
new USXGMII PCS and the legacy LynxI PCS.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 .../bindings/net/pcs/mediatek,usxgmii.yaml    |  46 +-
 MAINTAINERS                                   |   2 +
 drivers/net/pcs/Kconfig                       |  11 +
 drivers/net/pcs/Makefile                      |   1 +
 drivers/net/pcs/pcs-mtk-usxgmii.c             | 413 ++++++++++++++++++
 include/linux/pcs/pcs-mtk-usxgmii.h           |  26 ++
 6 files changed, 456 insertions(+), 43 deletions(-)
 create mode 100644 drivers/net/pcs/pcs-mtk-usxgmii.c
 create mode 100644 include/linux/pcs/pcs-mtk-usxgmii.h

diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
index 9a798c0d2fdd7..0cdaa3545edb0 100644
--- a/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
+++ b/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
@@ -31,70 +31,30 @@ properties:
   clocks:
     items:
       - description: USXGMII top-level clock
-      - description: SGMII top-level clock
-      - description: SGMII subsystem TX clock
-      - description: SGMII subsystem RX clock
-      - description: XFI PLL clock
-
-  clock-names:
-    items:
-      - const: usxgmii
-      - const: sgmii_sel
-      - const: sgmii_tx
-      - const: sgmii_rx
-      - const: xfi_pll
-
-  phys:
-    items:
-      - description: PEXTP SerDes PHY
-
-  mediatek,sgmiisys:
-    $ref: /schemas/types.yaml#/definitions/phandle
-    description:
-      Phandle to the syscon node of the corresponding SGMII LynxI PCS.
 
   resets:
     items:
       - description: XFI reset
-      - description: SGMII reset
-
-  reset-names:
-    items:
-      - const: xfi
-      - const: sgmii
 
 required:
   - compatible
   - reg
   - clocks
-  - clock-names
-  - phys
-  - mediatek,sgmiisys
   - resets
-  - reset-names
 
 additionalProperties: false
 
 examples:
   - |
     #include <dt-bindings/clock/mediatek,mt7988-clk.h>
-    #include <dt-bindings/reset/mediatek,mt7988-resets.h>
+    #define MT7988_TOPRGU_XFI0_GRST 12
     soc {
       #address-cells = <2>;
       #size-cells = <2>;
         usxgmiisys0: pcs at 10080000 {
           compatible = "mediatek,mt7988-usxgmiisys";
           reg = <0 0x10080000 0 0x1000>;
-          clocks = <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>,
-                   <&topckgen CLK_TOP_SGM_0_SEL>,
-                   <&sgmiisys0 CLK_SGM0_TX_EN>,
-                   <&sgmiisys0 CLK_SGM0_RX_EN>,
-                   <&xfi_pll CLK_XFIPLL_PLL_EN>;
-          clock-names = "usxgmii", "sgmii_sel", "sgmii_tx", "sgmii_rx", "xfi_pll";
-          resets = <&watchdog MT7988_TOPRGU_XFI0_GRST>,
-                   <&watchdog MT7988_TOPRGU_SGMII0_GRST>;
-          reset-names = "xfi", "sgmii";
-          phys = <&xfi_pextp0>;
-          mediatek,sgmiisys = <&sgmiisys0>;
+          clocks = <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>;
+          resets = <&watchdog MT7988_TOPRGU_XFI0_GRST>;
         };
     };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1ea4555013a4d..13fe7ffb10f7d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13487,7 +13487,9 @@ M:	Daniel Golle <daniel at makrotopia.org>
 L:	netdev at vger.kernel.org
 S:	Maintained
 F:	drivers/net/pcs/pcs-mtk-lynxi.c
+F:	drivers/net/pcs/pcs-mtk-usxgmii.c
 F:	include/linux/pcs/pcs-mtk-lynxi.h
+F:	include/linux/pcs/pcs-mtk-usxgmii.h
 
 MEDIATEK ETHERNET PHY DRIVERS
 M:	Daniel Golle <daniel at makrotopia.org>
diff --git a/drivers/net/pcs/Kconfig b/drivers/net/pcs/Kconfig
index 87cf308fc6d8b..55a6865bdaba3 100644
--- a/drivers/net/pcs/Kconfig
+++ b/drivers/net/pcs/Kconfig
@@ -25,6 +25,17 @@ config PCS_MTK_LYNXI
 	  This module provides helpers to phylink for managing the LynxI PCS
 	  which is part of MediaTek's SoC and Ethernet switch ICs.
 
+config PCS_MTK_USXGMII
+	tristate "MediaTek USXGMII PCS"
+	select PCS_MTK_LYNXI
+	select PHY_MTK_PEXTP
+	select PHYLINK
+	help
+	  This module provides a driver for MediaTek's USXGMII PCS supporting
+	  10GBase-R, 5GBase-R and USXGMII interface modes.
+	  1000Base-X, 2500Base-X and Cisco SGMII are supported on the same
+	  differential pairs via an embedded LynxI PHY.
+
 config PCS_RZN1_MIIC
 	tristate "Renesas RZ/N1 MII converter"
 	depends on OF && (ARCH_RZN1 || COMPILE_TEST)
diff --git a/drivers/net/pcs/Makefile b/drivers/net/pcs/Makefile
index fb1694192ae63..cc355152ca1ca 100644
--- a/drivers/net/pcs/Makefile
+++ b/drivers/net/pcs/Makefile
@@ -6,4 +6,5 @@ pcs_xpcs-$(CONFIG_PCS_XPCS)	:= pcs-xpcs.o pcs-xpcs-nxp.o pcs-xpcs-wx.o
 obj-$(CONFIG_PCS_XPCS)		+= pcs_xpcs.o
 obj-$(CONFIG_PCS_LYNX)		+= pcs-lynx.o
 obj-$(CONFIG_PCS_MTK_LYNXI)	+= pcs-mtk-lynxi.o
+obj-$(CONFIG_PCS_MTK_USXGMII)	+= pcs-mtk-usxgmii.o
 obj-$(CONFIG_PCS_RZN1_MIIC)	+= pcs-rzn1-miic.o
diff --git a/drivers/net/pcs/pcs-mtk-usxgmii.c b/drivers/net/pcs/pcs-mtk-usxgmii.c
new file mode 100644
index 0000000000000..e895aae3999fe
--- /dev/null
+++ b/drivers/net/pcs/pcs-mtk-usxgmii.c
@@ -0,0 +1,413 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Henry Yen <henry.yen at mediatek.com>
+ *         Daniel Golle <daniel at makrotopia.org>
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mdio.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/reset.h>
+#include <linux/pcs/pcs-mtk-usxgmii.h>
+#include <linux/platform_device.h>
+
+/* USXGMII subsystem config registers */
+/* Register to control speed */
+#define RG_PHY_TOP_SPEED_CTRL1			0x80c
+#define USXGMII_RATE_UPDATE_MODE		BIT(31)
+#define USXGMII_MAC_CK_GATED			BIT(29)
+#define USXGMII_IF_FORCE_EN			BIT(28)
+#define USXGMII_RATE_ADAPT_MODE			GENMASK(10, 8)
+#define USXGMII_RATE_ADAPT_MODE_X1		0
+#define USXGMII_RATE_ADAPT_MODE_X2		1
+#define USXGMII_RATE_ADAPT_MODE_X4		2
+#define USXGMII_RATE_ADAPT_MODE_X10		3
+#define USXGMII_RATE_ADAPT_MODE_X100		4
+#define USXGMII_RATE_ADAPT_MODE_X5		5
+#define USXGMII_RATE_ADAPT_MODE_X50		6
+#define USXGMII_XFI_RX_MODE			GENMASK(6, 4)
+#define USXGMII_XFI_TX_MODE			GENMASK(2, 0)
+#define USXGMII_XFI_MODE_10G			0
+#define USXGMII_XFI_MODE_5G			1
+#define USXGMII_XFI_MODE_2P5G			3
+
+/* Register to control PCS AN */
+#define RG_PCS_AN_CTRL0				0x810
+#define USXGMII_AN_RESTART			BIT(31)
+#define USXGMII_AN_SYNC_CNT			GENMASK(30, 11)
+#define USXGMII_AN_ENABLE			BIT(0)
+
+#define RG_PCS_AN_CTRL2				0x818
+#define USXGMII_LINK_TIMER_IDLE_DETECT		GENMASK(29, 20)
+#define USXGMII_LINK_TIMER_COMP_ACK_DETECT	GENMASK(19, 10)
+#define USXGMII_LINK_TIMER_AN_RESTART		GENMASK(9, 0)
+
+/* Register to read PCS AN status */
+#define RG_PCS_AN_STS0				0x81c
+#define USXGMII_LPA				GENMASK(15, 0)
+#define USXGMII_LPA_LATCH			BIT(31)
+
+/* Register to read PCS link status */
+#define RG_PCS_RX_STATUS0			0x904
+#define RG_PCS_RX_STATUS_UPDATE			BIT(16)
+#define RG_PCS_RX_LINK_STATUS			BIT(2)
+
+/* struct mtk_usxgmii_pcs - This structure holds each usxgmii PCS
+ * @pcs:		Phylink PCS structure
+ * @dev:		Pointer to device structure
+ * @base:		IO memory to access PCS hardware
+ * @clk:		Pointer to USXGMII clk
+ * @reset:		Pointer to USXGMII reset control
+ * @interface:		Currently selected interface mode
+ * @neg_mode:		Currently used phylink neg_mode
+ */
+struct mtk_usxgmii_pcs {
+	struct phylink_pcs		pcs;
+	struct device			*dev;
+	void __iomem			*base;
+	struct clk			*clk;
+	struct reset_control		*reset;
+	phy_interface_t			interface;
+	unsigned int			neg_mode;
+};
+
+static u32 mtk_r32(struct mtk_usxgmii_pcs *mpcs, unsigned int reg)
+{
+	return ioread32(mpcs->base + reg);
+}
+
+static void mtk_m32(struct mtk_usxgmii_pcs *mpcs, unsigned int reg, u32 mask, u32 set)
+{
+	u32 val;
+
+	val = ioread32(mpcs->base + reg);
+	val &= ~mask;
+	val |= set;
+	iowrite32(val, mpcs->base + reg);
+}
+
+static struct mtk_usxgmii_pcs *pcs_to_mtk_usxgmii_pcs(struct phylink_pcs *pcs)
+{
+	return container_of(pcs, struct mtk_usxgmii_pcs, pcs);
+}
+
+static void mtk_usxgmii_reset(struct mtk_usxgmii_pcs *mpcs)
+{
+	reset_control_assert(mpcs->reset);
+	usleep_range(100, 500);
+	reset_control_deassert(mpcs->reset);
+
+	mdelay(10);
+}
+
+static int mtk_usxgmii_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
+				  phy_interface_t interface,
+				  const unsigned long *advertising,
+				  bool permit_pause_to_mac)
+{
+	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
+	unsigned int an_ctrl = 0, link_timer = 0, xfi_mode = 0, adapt_mode = 0;
+	bool mode_changed = false;
+
+	if (interface == PHY_INTERFACE_MODE_USXGMII) {
+		an_ctrl = FIELD_PREP(USXGMII_AN_SYNC_CNT, 0x1FF) | USXGMII_AN_ENABLE;
+		link_timer = FIELD_PREP(USXGMII_LINK_TIMER_IDLE_DETECT, 0x7B) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_COMP_ACK_DETECT, 0x7B) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_AN_RESTART, 0x7B);
+		xfi_mode = FIELD_PREP(USXGMII_XFI_RX_MODE, USXGMII_XFI_MODE_10G) |
+			   FIELD_PREP(USXGMII_XFI_TX_MODE, USXGMII_XFI_MODE_10G);
+	} else if (interface == PHY_INTERFACE_MODE_10GBASER) {
+		an_ctrl = FIELD_PREP(USXGMII_AN_SYNC_CNT, 0x1FF);
+		link_timer = FIELD_PREP(USXGMII_LINK_TIMER_IDLE_DETECT, 0x7B) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_COMP_ACK_DETECT, 0x7B) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_AN_RESTART, 0x7B);
+		xfi_mode = FIELD_PREP(USXGMII_XFI_RX_MODE, USXGMII_XFI_MODE_10G) |
+			   FIELD_PREP(USXGMII_XFI_TX_MODE, USXGMII_XFI_MODE_10G);
+		adapt_mode = USXGMII_RATE_UPDATE_MODE;
+	} else if (interface == PHY_INTERFACE_MODE_5GBASER) {
+		an_ctrl = FIELD_PREP(USXGMII_AN_SYNC_CNT, 0xFF);
+		link_timer = FIELD_PREP(USXGMII_LINK_TIMER_IDLE_DETECT, 0x3D) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_COMP_ACK_DETECT, 0x3D) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_AN_RESTART, 0x3D);
+		xfi_mode = FIELD_PREP(USXGMII_XFI_RX_MODE, USXGMII_XFI_MODE_5G) |
+			   FIELD_PREP(USXGMII_XFI_TX_MODE, USXGMII_XFI_MODE_5G);
+		adapt_mode = USXGMII_RATE_UPDATE_MODE;
+	} else {
+		return -EINVAL;
+	}
+
+	adapt_mode |= FIELD_PREP(USXGMII_RATE_ADAPT_MODE, USXGMII_RATE_ADAPT_MODE_X1);
+
+	if (mpcs->interface != interface) {
+		mpcs->interface = interface;
+		mode_changed = true;
+	}
+
+	mtk_usxgmii_reset(mpcs);
+
+	/* Setup USXGMII AN ctrl */
+	mtk_m32(mpcs, RG_PCS_AN_CTRL0,
+		USXGMII_AN_SYNC_CNT | USXGMII_AN_ENABLE,
+		an_ctrl);
+
+	mtk_m32(mpcs, RG_PCS_AN_CTRL2,
+		USXGMII_LINK_TIMER_IDLE_DETECT |
+		USXGMII_LINK_TIMER_COMP_ACK_DETECT |
+		USXGMII_LINK_TIMER_AN_RESTART,
+		link_timer);
+
+	mpcs->neg_mode = neg_mode;
+
+	/* Gated MAC CK */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
+		USXGMII_MAC_CK_GATED, USXGMII_MAC_CK_GATED);
+
+	/* Enable interface force mode */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
+		USXGMII_IF_FORCE_EN, USXGMII_IF_FORCE_EN);
+
+	/* Setup USXGMII adapt mode */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
+		USXGMII_RATE_UPDATE_MODE | USXGMII_RATE_ADAPT_MODE,
+		adapt_mode);
+
+	/* Setup USXGMII speed */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
+		USXGMII_XFI_RX_MODE | USXGMII_XFI_TX_MODE,
+		xfi_mode);
+
+	usleep_range(1, 10);
+
+	/* Un-gated MAC CK */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1, USXGMII_MAC_CK_GATED, 0);
+
+	usleep_range(1, 10);
+
+	/* Disable interface force mode for the AN mode */
+	if (an_ctrl & USXGMII_AN_ENABLE)
+		mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1, USXGMII_IF_FORCE_EN, 0);
+
+	return mode_changed;
+}
+
+static void mtk_usxgmii_pcs_get_fixed_speed(struct mtk_usxgmii_pcs *mpcs,
+					    struct phylink_link_state *state)
+{
+	u32 val = mtk_r32(mpcs, RG_PHY_TOP_SPEED_CTRL1);
+	int speed;
+
+	/* Calculate speed from interface speed and rate adapt mode */
+	switch (FIELD_GET(USXGMII_XFI_RX_MODE, val)) {
+	case USXGMII_XFI_MODE_10G:
+		speed = 10000;
+		break;
+	case USXGMII_XFI_MODE_5G:
+		speed = 5000;
+		break;
+	case USXGMII_XFI_MODE_2P5G:
+		speed = 2500;
+		break;
+	default:
+		state->speed = SPEED_UNKNOWN;
+		return;
+	}
+
+	switch (FIELD_GET(USXGMII_RATE_ADAPT_MODE, val)) {
+	case USXGMII_RATE_ADAPT_MODE_X100:
+		speed /= 100;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X50:
+		speed /= 50;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X10:
+		speed /= 10;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X5:
+		speed /= 5;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X4:
+		speed /= 4;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X2:
+		speed /= 2;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X1:
+		break;
+	default:
+		state->speed = SPEED_UNKNOWN;
+		return;
+	}
+
+	state->speed = speed;
+	state->duplex = DUPLEX_FULL;
+}
+
+static void mtk_usxgmii_pcs_get_an_state(struct mtk_usxgmii_pcs *mpcs,
+					 struct phylink_link_state *state)
+{
+	u16 lpa;
+
+	/* Refresh LPA by toggling LPA_LATCH */
+	mtk_m32(mpcs, RG_PCS_AN_STS0, USXGMII_LPA_LATCH, USXGMII_LPA_LATCH);
+	ndelay(1020);
+	mtk_m32(mpcs, RG_PCS_AN_STS0, USXGMII_LPA_LATCH, 0);
+	ndelay(1020);
+	lpa = FIELD_GET(USXGMII_LPA, mtk_r32(mpcs, RG_PCS_AN_STS0));
+
+	phylink_decode_usxgmii_word(state, lpa);
+}
+
+static void mtk_usxgmii_pcs_get_state(struct phylink_pcs *pcs,
+				      struct phylink_link_state *state)
+{
+	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
+
+	/* Refresh USXGMII link status by toggling RG_PCS_AN_STATUS_UPDATE */
+	mtk_m32(mpcs, RG_PCS_RX_STATUS0, RG_PCS_RX_STATUS_UPDATE,
+		RG_PCS_RX_STATUS_UPDATE);
+	ndelay(1020);
+	mtk_m32(mpcs, RG_PCS_RX_STATUS0, RG_PCS_RX_STATUS_UPDATE, 0);
+	ndelay(1020);
+
+	/* Read USXGMII link status */
+	state->link = FIELD_GET(RG_PCS_RX_LINK_STATUS,
+				mtk_r32(mpcs, RG_PCS_RX_STATUS0));
+
+	/* Continuously repeat re-configuration sequence until link comes up */
+	if (!state->link) {
+		mtk_usxgmii_pcs_config(pcs, mpcs->neg_mode,
+				       state->interface, NULL, false);
+		return;
+	}
+
+	if (FIELD_GET(USXGMII_AN_ENABLE, mtk_r32(mpcs, RG_PCS_AN_CTRL0)))
+		mtk_usxgmii_pcs_get_an_state(mpcs, state);
+	else
+		mtk_usxgmii_pcs_get_fixed_speed(mpcs, state);
+}
+
+static void mtk_usxgmii_pcs_restart_an(struct phylink_pcs *pcs)
+{
+	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
+
+	mtk_m32(mpcs, RG_PCS_AN_CTRL0, USXGMII_AN_RESTART, USXGMII_AN_RESTART);
+}
+
+static void mtk_usxgmii_pcs_link_up(struct phylink_pcs *pcs, unsigned int neg_mode,
+				    phy_interface_t interface,
+				    int speed, int duplex)
+{
+	/* Reconfiguring USXGMII to ensure the quality of the RX signal
+	 * after the line side link up.
+	 */
+	mtk_usxgmii_pcs_config(pcs, neg_mode, interface, NULL, false);
+}
+
+static void mtk_usxgmii_pcs_disable(struct phylink_pcs *pcs)
+{
+	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
+
+	mpcs->interface = PHY_INTERFACE_MODE_NA;
+	mpcs->neg_mode = -1;
+}
+
+static const struct phylink_pcs_ops mtk_usxgmii_pcs_ops = {
+	.pcs_config = mtk_usxgmii_pcs_config,
+	.pcs_get_state = mtk_usxgmii_pcs_get_state,
+	.pcs_an_restart = mtk_usxgmii_pcs_restart_an,
+	.pcs_link_up = mtk_usxgmii_pcs_link_up,
+	.pcs_disable = mtk_usxgmii_pcs_disable,
+};
+
+static int mtk_usxgmii_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_usxgmii_pcs *mpcs;
+
+	mpcs = devm_kzalloc(dev, sizeof(*mpcs), GFP_KERNEL);
+	if (!mpcs)
+		return -ENOMEM;
+
+	mpcs->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(mpcs->base))
+		return PTR_ERR(mpcs->base);
+
+	mpcs->dev = dev;
+	mpcs->pcs.ops = &mtk_usxgmii_pcs_ops;
+	mpcs->pcs.poll = true;
+	mpcs->pcs.neg_mode = true;
+	mpcs->interface = PHY_INTERFACE_MODE_NA;
+	mpcs->neg_mode = -1;
+
+	mpcs->clk = devm_clk_get_enabled(mpcs->dev, NULL);
+	if (IS_ERR(mpcs->clk))
+		return PTR_ERR(mpcs->clk);
+
+	mpcs->reset = devm_reset_control_get_shared(dev, NULL);
+	if (IS_ERR(mpcs->reset))
+		return PTR_ERR(mpcs->reset);
+
+	reset_control_deassert(mpcs->reset);
+
+	platform_set_drvdata(pdev, mpcs);
+
+	return 0;
+}
+
+static int mtk_usxgmii_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static const struct of_device_id mtk_usxgmii_of_mtable[] = {
+	{ .compatible = "mediatek,mt7988-usxgmiisys" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mtk_usxgmii_of_mtable);
+
+struct phylink_pcs *mtk_usxgmii_select_pcs(struct device_node *np, phy_interface_t mode)
+{
+	struct platform_device *pdev;
+	struct mtk_usxgmii_pcs *mpcs;
+
+	if (!np)
+		return NULL;
+
+	if (!of_device_is_available(np))
+		return ERR_PTR(-ENODEV);
+
+	if (!of_match_node(mtk_usxgmii_of_mtable, np))
+		return ERR_PTR(-EINVAL);
+
+	pdev = of_find_device_by_node(np);
+	if (!pdev || !platform_get_drvdata(pdev)) {
+		if (pdev)
+			put_device(&pdev->dev);
+		return ERR_PTR(-EPROBE_DEFER);
+	}
+
+	mpcs = platform_get_drvdata(pdev);
+	put_device(&pdev->dev);
+
+	return &mpcs->pcs;
+}
+EXPORT_SYMBOL(mtk_usxgmii_select_pcs);
+
+static struct platform_driver mtk_usxgmii_driver = {
+	.driver = {
+		.name			= "mtk_usxgmii",
+		.suppress_bind_attrs	= true,
+		.of_match_table		= mtk_usxgmii_of_mtable,
+	},
+	.probe = mtk_usxgmii_probe,
+	.remove = mtk_usxgmii_remove,
+};
+module_platform_driver(mtk_usxgmii_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek USXGMII PCS driver");
+MODULE_AUTHOR("Daniel Golle <daniel at makrotopia.org>");
diff --git a/include/linux/pcs/pcs-mtk-usxgmii.h b/include/linux/pcs/pcs-mtk-usxgmii.h
new file mode 100644
index 0000000000000..346b88bdf7a6e
--- /dev/null
+++ b/include/linux/pcs/pcs-mtk-usxgmii.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_PCS_MTK_USXGMII_H
+#define __LINUX_PCS_MTK_USXGMII_H
+
+#include <linux/phylink.h>
+
+/**
+ * mtk_usxgmii_select_pcs() - Get MediaTek PCS instance
+ * @np:		Pointer to device node indentifying a MediaTek USXGMII PCS
+ * @mode:	Ethernet PHY interface mode
+ *
+ * Return PCS identified by a device node and the PHY interface mode in use
+ *
+ * Return:	Pointer to phylink PCS instance of NULL
+ */
+#if IS_ENABLED(CONFIG_PCS_MTK_USXGMII)
+struct phylink_pcs *mtk_usxgmii_select_pcs(struct device_node *np, phy_interface_t mode);
+#else
+static inline struct phylink_pcs *mtk_usxgmii_select_pcs(struct device_node *np,
+							 phy_interface_t mode)
+{
+	return NULL;
+}
+#endif /* IS_ENABLED(CONFIG_PCS_MTK_USXGMII) */
+
+#endif /* __LINUX_PCS_MTK_USXGMII_H */
-- 
2.43.0


From daniel at makrotopia.org  Tue Dec  5 17:44:51 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 01:44:51 +0000
Subject: [RFC PATCH v2 6/8] dt-bindings: net: mediatek: remove wrongly added
 clocks and SerDes
In-Reply-To: <cover.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
Message-ID: <e2214e904cde9a9d64ec1e87ac38560f7ac35a1f.1701826319.git.daniel@makrotopia.org>

Several clocks as well as both sgmiisys phandles were added by mistake
to the Ethernet bindings for MT7988.

This happened because the vendor driver which served as a reference
uses a high number of syscon phandles to access various parts of the
SoC which wasn't acceptable upstream. Hence several parts which have
never previously been supported (such SerDes PHY and USXGMII PCS) have
been moved to separate drivers which also result in a much more sane
device tree.

Quickly align the bindings with the upcoming reality of the drivers
actually adding full support for this SoC.

Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 .../devicetree/bindings/net/mediatek,net.yaml | 32 ++++---------------
 1 file changed, 7 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
index e74502a0afe86..030d106bc7d3f 100644
--- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
@@ -337,32 +337,23 @@ allOf:
           minItems: 4
 
         clocks:
-          minItems: 34
-          maxItems: 34
+          minItems: 24
+          maxItems: 24
 
         clock-names:
           items:
-            - const: crypto
+            - const: xgp1
+            - const: xgp2
+            - const: xgp3
             - const: fe
             - const: gp2
             - const: gp1
             - const: gp3
+            - const: esw
+            - const: crypto
             - const: ethwarp_wocpu2
             - const: ethwarp_wocpu1
             - const: ethwarp_wocpu0
-            - const: esw
-            - const: netsys0
-            - const: netsys1
-            - const: sgmii_tx250m
-            - const: sgmii_rx250m
-            - const: sgmii2_tx250m
-            - const: sgmii2_rx250m
-            - const: top_usxgmii0_sel
-            - const: top_usxgmii1_sel
-            - const: top_sgm0_sel
-            - const: top_sgm1_sel
-            - const: top_xfi_phy0_xtal_sel
-            - const: top_xfi_phy1_xtal_sel
             - const: top_eth_gmii_sel
             - const: top_eth_refck_50m_sel
             - const: top_eth_sys_200m_sel
@@ -375,15 +366,6 @@ allOf:
             - const: top_netsys_sync_250m_sel
             - const: top_netsys_ppefb_250m_sel
             - const: top_netsys_warp_sel
-            - const: wocpu1
-            - const: wocpu0
-            - const: xgp1
-            - const: xgp2
-            - const: xgp3
-
-        mediatek,sgmiisys:
-          minItems: 2
-          maxItems: 2
 
 patternProperties:
   "^mac@[0-1]$":
-- 
2.43.0


From daniel at makrotopia.org  Tue Dec  5 17:45:02 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 01:45:02 +0000
Subject: [RFC PATCH v2 7/8] dt-bindings: net: mediatek,net: fix and complete
 mt7988-eth binding
In-Reply-To: <cover.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
Message-ID: <567c6aaa64ecb4872056bc0105c70153fd9d9b50.1701826319.git.daniel@makrotopia.org>

Complete support for MT7988 which comes with 3 MACs, SRAM for DMA
descriptors and uses a dedicated PCS for the SerDes units.

Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 .../devicetree/bindings/net/mediatek,net.yaml | 148 +++++++++++++++++-
 1 file changed, 146 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
index 030d106bc7d3f..ca0667c51c1c2 100644
--- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
@@ -28,7 +28,10 @@ properties:
       - ralink,rt5350-eth
 
   reg:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: Base of registers used to program the ethernet controller
+      - description: SRAM region used for DMA descriptors
 
   clocks: true
   clock-names: true
@@ -115,6 +118,9 @@ allOf:
               - mediatek,mt7623-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           maxItems: 3
 
@@ -149,6 +155,9 @@ allOf:
               - mediatek,mt7621-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           maxItems: 1
 
@@ -174,6 +183,9 @@ allOf:
             const: mediatek,mt7622-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           maxItems: 3
 
@@ -215,6 +227,9 @@ allOf:
             const: mediatek,mt7629-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           maxItems: 3
 
@@ -257,6 +272,9 @@ allOf:
             const: mediatek,mt7981-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           minItems: 4
 
@@ -295,6 +313,9 @@ allOf:
             const: mediatek,mt7986-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           minItems: 4
 
@@ -333,8 +354,13 @@ allOf:
             const: mediatek,mt7988-eth
     then:
       properties:
+        reg:
+          maxItems: 2
+          minItems: 2
+
         interrupts:
           minItems: 4
+          maxItems: 4
 
         clocks:
           minItems: 24
@@ -368,7 +394,7 @@ allOf:
             - const: top_netsys_warp_sel
 
 patternProperties:
-  "^mac@[0-1]$":
+  "^mac@[0-2]$":
     type: object
     unevaluatedProperties: false
     allOf:
@@ -382,6 +408,9 @@ patternProperties:
       reg:
         maxItems: 1
 
+      phys:
+        maxItems: 1
+
     required:
       - reg
       - compatible
@@ -559,3 +588,118 @@ examples:
         };
       };
     };
+
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+    soc {
+      #address-cells = <2>;
+      #size-cells = <2>;
+
+      ethernet at 15100000 {
+        compatible = "mediatek,mt7988-eth";
+        reg = <0 0x15100000 0 0x80000>, <0 0x15400000 0 0x380000>;
+        interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
+
+        clocks = <&ethsys CLK_ETHDMA_XGP1_EN>,
+                 <&ethsys CLK_ETHDMA_XGP2_EN>,
+                 <&ethsys CLK_ETHDMA_XGP3_EN>,
+                 <&ethsys CLK_ETHDMA_FE_EN>,
+                 <&ethsys CLK_ETHDMA_GP2_EN>,
+                 <&ethsys CLK_ETHDMA_GP1_EN>,
+                 <&ethsys CLK_ETHDMA_GP3_EN>,
+                 <&ethsys CLK_ETHDMA_ESW_EN>,
+                 <&ethsys CLK_ETHDMA_CRYPT0_EN>,
+                 <&ethwarp CLK_ETHWARP_WOCPU2_EN>,
+                 <&ethwarp CLK_ETHWARP_WOCPU1_EN>,
+                 <&ethwarp CLK_ETHWARP_WOCPU0_EN>,
+                 <&topckgen CLK_TOP_ETH_GMII_SEL>,
+                 <&topckgen CLK_TOP_ETH_REFCK_50M_SEL>,
+                 <&topckgen CLK_TOP_ETH_SYS_200M_SEL>,
+                 <&topckgen CLK_TOP_ETH_SYS_SEL>,
+                 <&topckgen CLK_TOP_ETH_XGMII_SEL>,
+                 <&topckgen CLK_TOP_ETH_MII_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_500M_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_PAO_2X_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_SYNC_250M_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_PPEFB_250M_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_WARP_SEL>;
+
+        clock-names = "xgp1", "xgp2", "xgp3", "fe", "gp2", "gp1",
+                      "gp3", "esw", "crypto",
+                      "ethwarp_wocpu2", "ethwarp_wocpu1",
+                      "ethwarp_wocpu0", "top_eth_gmii_sel",
+                      "top_eth_refck_50m_sel", "top_eth_sys_200m_sel",
+                      "top_eth_sys_sel", "top_eth_xgmii_sel",
+                      "top_eth_mii_sel", "top_netsys_sel",
+                      "top_netsys_500m_sel", "top_netsys_pao_2x_sel",
+                      "top_netsys_sync_250m_sel",
+                      "top_netsys_ppefb_250m_sel",
+                      "top_netsys_warp_sel";
+        assigned-clocks = <&topckgen CLK_TOP_NETSYS_2X_SEL>,
+                          <&topckgen CLK_TOP_NETSYS_GSW_SEL>,
+                          <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>,
+                          <&topckgen CLK_TOP_USXGMII_SBUS_1_SEL>,
+                          <&topckgen CLK_TOP_SGM_0_SEL>,
+                          <&topckgen CLK_TOP_SGM_1_SEL>;
+        assigned-clock-parents = <&apmixedsys CLK_APMIXED_NET2PLL>,
+                                 <&topckgen CLK_TOP_NET1PLL_D4>,
+                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
+                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
+                                 <&apmixedsys CLK_APMIXED_SGMPLL>,
+                                 <&apmixedsys CLK_APMIXED_SGMPLL>;
+        mediatek,ethsys = <&ethsys>;
+        mediatek,infracfg = <&topmisc>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        mac at 0 {
+          compatible = "mediatek,eth-mac";
+          reg = <0>;
+          phy-mode = "internal"; /* CPU port of built-in 1GE switch */
+
+          fixed-link {
+            speed = <10000>;
+            full-duplex;
+            pause;
+          };
+        };
+
+        mac at 1 {
+          compatible = "mediatek,eth-mac";
+          reg = <1>;
+          phy-handle = <&int_2p5g_phy>;
+        };
+
+        mac at 2 {
+          compatible = "mediatek,eth-mac";
+          reg = <2>;
+          pcs-handle = <&usxgmiisys0>;
+          phy-handle = <&phy0>;
+        };
+
+        mdio_bus: mdio-bus {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          /* external PHY */
+          phy0: ethernet-phy at 0 {
+            reg = <0>;
+            compatible = "ethernet-phy-ieee802.3-c45";
+          };
+
+          /* internal 2.5G PHY */
+          int_2p5g_phy: ethernet-phy at 15 {
+            reg = <15>;
+            compatible = "ethernet-phy-ieee802.3-c45";
+            phy-mode = "internal";
+          };
+        };
+      };
+    };
-- 
2.43.0


From daniel at makrotopia.org  Tue Dec  5 17:45:17 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 01:45:17 +0000
Subject: [RFC PATCH v2 8/8] net: ethernet: mtk_eth_soc: add paths and SerDes
 modes for MT7988
In-Reply-To: <cover.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
Message-ID: <3ccc33fa14310ab47e90ff8e6ce46f1562bb838e.1701826319.git.daniel@makrotopia.org>

MT7988 comes with a built-in 2.5G PHY as well as SerDes lanes to
connect external PHYs or transceivers in USXGMII, 10GBase-R, 5GBase-R,
2500Base-X, 1000Base-X and Cisco SGMII interface modes.

Implement support for configuring for the new paths to SerDes interfaces
and the internal 2.5G PHY.

Add USXGMII PCS driver for 10GBase-R, 5GBase-R and USXGMII mode, and
setup the new PHYA on MT7988 to access the also still existing old
LynxI PCS for 1000Base-X, 2500Base-X and Cisco SGMII PCS interface
modes.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 drivers/net/ethernet/mediatek/mtk_eth_path.c | 122 +++++++-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c  | 284 +++++++++++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h  | 107 +++++--
 3 files changed, 462 insertions(+), 51 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_path.c b/drivers/net/ethernet/mediatek/mtk_eth_path.c
index 7c27a19c4d8f4..3f4f4cfe6a233 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_path.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_path.c
@@ -31,10 +31,20 @@ static const char *mtk_eth_path_name(u64 path)
 		return "gmac2_rgmii";
 	case MTK_ETH_PATH_GMAC2_SGMII:
 		return "gmac2_sgmii";
+	case MTK_ETH_PATH_GMAC2_2P5GPHY:
+		return "gmac2_2p5gphy";
 	case MTK_ETH_PATH_GMAC2_GEPHY:
 		return "gmac2_gephy";
+	case MTK_ETH_PATH_GMAC3_SGMII:
+		return "gmac3_sgmii";
 	case MTK_ETH_PATH_GDM1_ESW:
 		return "gdm1_esw";
+	case MTK_ETH_PATH_GMAC1_USXGMII:
+		return "gmac1_usxgmii";
+	case MTK_ETH_PATH_GMAC2_USXGMII:
+		return "gmac2_usxgmii";
+	case MTK_ETH_PATH_GMAC3_USXGMII:
+		return "gmac3_usxgmii";
 	default:
 		return "unknown path";
 	}
@@ -127,6 +137,27 @@ static int set_mux_u3_gmac2_to_qphy(struct mtk_eth *eth, u64 path)
 	return 0;
 }
 
+static int set_mux_gmac2_to_2p5gphy(struct mtk_eth *eth, u64 path)
+{
+	int ret;
+
+	if (path == MTK_ETH_PATH_GMAC2_2P5GPHY) {
+		ret = regmap_clear_bits(eth->ethsys, ETHSYS_SYSCFG0, SYSCFG0_SGMII_GMAC2_V2);
+		if (ret)
+			return ret;
+
+		/* Setup mux to 2p5g PHY */
+		ret = regmap_clear_bits(eth->infra, TOP_MISC_NETSYS_PCS_MUX, MUX_G2_USXGMII_SEL);
+		if (ret)
+			return ret;
+
+		dev_dbg(eth->dev, "path %s in %s updated\n",
+			mtk_eth_path_name(path), __func__);
+	}
+
+	return 0;
+}
+
 static int set_mux_gmac1_gmac2_to_sgmii_rgmii(struct mtk_eth *eth, u64 path)
 {
 	unsigned int val = 0;
@@ -165,7 +196,48 @@ static int set_mux_gmac1_gmac2_to_sgmii_rgmii(struct mtk_eth *eth, u64 path)
 	return 0;
 }
 
-static int set_mux_gmac12_to_gephy_sgmii(struct mtk_eth *eth, u64 path)
+static int set_mux_gmac123_to_usxgmii(struct mtk_eth *eth, u64 path)
+{
+	unsigned int val = 0;
+	bool updated = true;
+	int mac_id = 0;
+
+	/* Disable SYSCFG1 SGMII */
+	regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
+
+	switch (path) {
+	case MTK_ETH_PATH_GMAC1_USXGMII:
+		val &= ~(u32)SYSCFG0_SGMII_GMAC1_V2;
+		mac_id = MTK_GMAC1_ID;
+		break;
+	case MTK_ETH_PATH_GMAC2_USXGMII:
+		val &= ~(u32)SYSCFG0_SGMII_GMAC2_V2;
+		mac_id = MTK_GMAC2_ID;
+		break;
+	case MTK_ETH_PATH_GMAC3_USXGMII:
+		val &= ~(u32)SYSCFG0_SGMII_GMAC3_V2;
+		mac_id = MTK_GMAC3_ID;
+		break;
+	default:
+		updated = false;
+	};
+
+	if (updated) {
+		regmap_update_bits(eth->ethsys, ETHSYS_SYSCFG0,
+				   SYSCFG0_SGMII_MASK, val);
+
+		if (mac_id == MTK_GMAC2_ID)
+			regmap_set_bits(eth->infra, TOP_MISC_NETSYS_PCS_MUX,
+					MUX_G2_USXGMII_SEL);
+	}
+
+	dev_dbg(eth->dev, "path %s in %s updated = %d\n",
+		mtk_eth_path_name(path), __func__, updated);
+
+	return 0;
+}
+
+static int set_mux_gmac123_to_gephy_sgmii(struct mtk_eth *eth, u64 path)
 {
 	unsigned int val = 0;
 	bool updated = true;
@@ -182,6 +254,9 @@ static int set_mux_gmac12_to_gephy_sgmii(struct mtk_eth *eth, u64 path)
 	case MTK_ETH_PATH_GMAC2_SGMII:
 		val |= SYSCFG0_SGMII_GMAC2_V2;
 		break;
+	case MTK_ETH_PATH_GMAC3_SGMII:
+		val |= SYSCFG0_SGMII_GMAC3_V2;
+		break;
 	default:
 		updated = false;
 	}
@@ -209,6 +284,10 @@ static const struct mtk_eth_muxc mtk_eth_muxc[] = {
 		.name = "mux_u3_gmac2_to_qphy",
 		.cap_bit = MTK_ETH_MUX_U3_GMAC2_TO_QPHY,
 		.set_path = set_mux_u3_gmac2_to_qphy,
+	}, {
+		.name = "mux_gmac2_to_2p5gphy",
+		.cap_bit = MTK_ETH_MUX_GMAC2_TO_2P5GPHY,
+		.set_path = set_mux_gmac2_to_2p5gphy,
 	}, {
 		.name = "mux_gmac1_gmac2_to_sgmii_rgmii",
 		.cap_bit = MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII,
@@ -216,7 +295,15 @@ static const struct mtk_eth_muxc mtk_eth_muxc[] = {
 	}, {
 		.name = "mux_gmac12_to_gephy_sgmii",
 		.cap_bit = MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII,
-		.set_path = set_mux_gmac12_to_gephy_sgmii,
+		.set_path = set_mux_gmac123_to_gephy_sgmii,
+	}, {
+		.name = "mux_gmac123_to_gephy_sgmii",
+		.cap_bit = MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII,
+		.set_path = set_mux_gmac123_to_gephy_sgmii,
+	}, {
+		.name = "mux_gmac123_to_usxgmii",
+		.cap_bit = MTK_ETH_MUX_GMAC123_TO_USXGMII,
+		.set_path = set_mux_gmac123_to_usxgmii,
 	},
 };
 
@@ -249,12 +336,39 @@ static int mtk_eth_mux_setup(struct mtk_eth *eth, u64 path)
 	return err;
 }
 
+int mtk_gmac_usxgmii_path_setup(struct mtk_eth *eth, int mac_id)
+{
+	u64 path;
+
+	path = (mac_id == MTK_GMAC1_ID) ?  MTK_ETH_PATH_GMAC1_USXGMII :
+	       (mac_id == MTK_GMAC2_ID) ?  MTK_ETH_PATH_GMAC2_USXGMII :
+					   MTK_ETH_PATH_GMAC3_USXGMII;
+
+	/* Setup proper MUXes along the path */
+	return mtk_eth_mux_setup(eth, path);
+}
+
 int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id)
 {
 	u64 path;
 
-	path = (mac_id == 0) ?  MTK_ETH_PATH_GMAC1_SGMII :
-				MTK_ETH_PATH_GMAC2_SGMII;
+	path = (mac_id == MTK_GMAC1_ID) ? MTK_ETH_PATH_GMAC1_SGMII :
+	       (mac_id == MTK_GMAC2_ID) ? MTK_ETH_PATH_GMAC2_SGMII :
+					  MTK_ETH_PATH_GMAC3_SGMII;
+
+	/* Setup proper MUXes along the path */
+	return mtk_eth_mux_setup(eth, path);
+}
+
+int mtk_gmac_2p5gphy_path_setup(struct mtk_eth *eth, int mac_id)
+{
+	u64 path = 0;
+
+	if (mac_id == MTK_GMAC2_ID)
+		path = MTK_ETH_PATH_GMAC2_2P5GPHY;
+
+	if (!path)
+		return -EINVAL;
 
 	/* Setup proper MUXes along the path */
 	return mtk_eth_mux_setup(eth, path);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index a6e91573f8dae..8663903d541f3 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -22,6 +22,8 @@
 #include <linux/pinctrl/devinfo.h>
 #include <linux/phylink.h>
 #include <linux/pcs/pcs-mtk-lynxi.h>
+#include <linux/pcs/pcs-mtk-usxgmii.h>
+#include <linux/phy/phy.h>
 #include <linux/jhash.h>
 #include <linux/bitfield.h>
 #include <net/dsa.h>
@@ -260,12 +262,8 @@ static const char * const mtk_clks_source_name[] = {
 	"ethwarp_wocpu2",
 	"ethwarp_wocpu1",
 	"ethwarp_wocpu0",
-	"top_usxgmii0_sel",
-	"top_usxgmii1_sel",
 	"top_sgm0_sel",
 	"top_sgm1_sel",
-	"top_xfi_phy0_xtal_sel",
-	"top_xfi_phy1_xtal_sel",
 	"top_eth_gmii_sel",
 	"top_eth_refck_50m_sel",
 	"top_eth_sys_200m_sel",
@@ -508,6 +506,30 @@ static void mtk_setup_bridge_switch(struct mtk_eth *eth)
 		MTK_GSW_CFG);
 }
 
+static bool mtk_check_gmac23_idle(struct mtk_mac *mac)
+{
+	u32 mac_fsm, gdm_fsm;
+
+	mac_fsm = mtk_r32(mac->hw, MTK_MAC_FSM(mac->id));
+
+	switch (mac->id) {
+	case MTK_GMAC2_ID:
+		gdm_fsm = mtk_r32(mac->hw, MTK_FE_GDM2_FSM);
+		break;
+	case MTK_GMAC3_ID:
+		gdm_fsm = mtk_r32(mac->hw, MTK_FE_GDM3_FSM);
+		break;
+	default:
+		return true;
+	};
+
+	if ((mac_fsm & 0xFFFF0000) == 0x01010000 &&
+	    (gdm_fsm & 0xFFFF0000) == 0x00000000)
+		return true;
+
+	return false;
+}
+
 static struct phylink_pcs *mtk_mac_select_pcs(struct phylink_config *config,
 					      phy_interface_t interface)
 {
@@ -516,6 +538,21 @@ static struct phylink_pcs *mtk_mac_select_pcs(struct phylink_config *config,
 	struct mtk_eth *eth = mac->hw;
 	unsigned int sid;
 
+	if (mtk_is_netsys_v3_or_greater(eth)) {
+		switch (interface) {
+		case PHY_INTERFACE_MODE_1000BASEX:
+		case PHY_INTERFACE_MODE_2500BASEX:
+		case PHY_INTERFACE_MODE_SGMII:
+			return mtk_pcs_lynxi_select_pcs(mac->sgmii_pcs_of_node, interface);
+		case PHY_INTERFACE_MODE_5GBASER:
+		case PHY_INTERFACE_MODE_10GBASER:
+		case PHY_INTERFACE_MODE_USXGMII:
+			return mtk_usxgmii_select_pcs(mac->usxgmii_pcs_of_node, interface);
+		default:
+			return NULL;
+		}
+	}
+
 	if (interface == PHY_INTERFACE_MODE_SGMII ||
 	    phy_interface_mode_is_8023z(interface)) {
 		sid = (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_SGMII)) ?
@@ -567,7 +604,22 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
 					goto init_err;
 			}
 			break;
+		case PHY_INTERFACE_MODE_USXGMII:
+		case PHY_INTERFACE_MODE_10GBASER:
+		case PHY_INTERFACE_MODE_5GBASER:
+			if (MTK_HAS_CAPS(eth->soc->caps, MTK_USXGMII)) {
+				err = mtk_gmac_usxgmii_path_setup(eth, mac->id);
+				if (err)
+					goto init_err;
+			}
+			break;
 		case PHY_INTERFACE_MODE_INTERNAL:
+			if (mac->id == MTK_GMAC2_ID &&
+			    MTK_HAS_CAPS(eth->soc->caps, MTK_2P5GPHY)) {
+				err = mtk_gmac_2p5gphy_path_setup(eth, mac->id);
+				if (err)
+					goto init_err;
+			}
 			break;
 		default:
 			goto err_phy;
@@ -614,8 +666,6 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
 		val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
 		val |= SYSCFG0_GE_MODE(ge_mode, mac->id);
 		regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
-
-		mac->interface = state->interface;
 	}
 
 	/* SGMII */
@@ -632,21 +682,40 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
 
 		/* Save the syscfg0 value for mac_finish */
 		mac->syscfg0 = val;
-	} else if (phylink_autoneg_inband(mode)) {
+	} else if (state->interface != PHY_INTERFACE_MODE_USXGMII &&
+		   state->interface != PHY_INTERFACE_MODE_10GBASER &&
+		   state->interface != PHY_INTERFACE_MODE_5GBASER &&
+		   phylink_autoneg_inband(mode)) {
 		dev_err(eth->dev,
-			"In-band mode not supported in non SGMII mode!\n");
+			"In-band mode not supported in non-SerDes modes!\n");
 		return;
 	}
 
 	/* Setup gmac */
-	if (mtk_is_netsys_v3_or_greater(eth) &&
-	    mac->interface == PHY_INTERFACE_MODE_INTERNAL) {
-		mtk_w32(mac->hw, MTK_GDMA_XGDM_SEL, MTK_GDMA_EG_CTRL(mac->id));
-		mtk_w32(mac->hw, MAC_MCR_FORCE_LINK_DOWN, MTK_MAC_MCR(mac->id));
+	if (mtk_is_netsys_v3_or_greater(eth)) {
+		if (mtk_interface_mode_is_xgmii(state->interface)) {
+			mtk_w32(mac->hw, MTK_GDMA_XGDM_SEL, MTK_GDMA_EG_CTRL(mac->id));
+			mtk_w32(mac->hw, MAC_MCR_FORCE_LINK_DOWN, MTK_MAC_MCR(mac->id));
 
-		mtk_setup_bridge_switch(eth);
+			if (mac->id == MTK_GMAC1_ID)
+				mtk_setup_bridge_switch(eth);
+		} else {
+			mtk_w32(eth, 0, MTK_GDMA_EG_CTRL(mac->id));
+
+			/* FIXME: In current hardware design, we have to reset FE
+			 * when swtiching XGDM to GDM. Therefore, here trigger an SER
+			 * to let GDM go back to the initial state.
+			 */
+			if ((mtk_interface_mode_is_xgmii(mac->interface) ||
+			     mac->interface == PHY_INTERFACE_MODE_NA) &&
+			    !mtk_check_gmac23_idle(mac) &&
+			    !test_bit(MTK_RESETTING, &eth->state))
+				schedule_work(&eth->pending_work);
+		}
 	}
 
+	mac->interface = state->interface;
+
 	return;
 
 err_phy:
@@ -659,6 +728,18 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
 		mac->id, phy_modes(state->interface), err);
 }
 
+static int mtk_mac_prepare(struct phylink_config *config, unsigned int mode,
+			   phy_interface_t interface)
+{
+	struct mtk_mac *mac = container_of(config, struct mtk_mac,
+					   phylink_config);
+
+	if (mac->pextp && mac->interface != interface)
+		phy_reset(mac->pextp);
+
+	return 0;
+}
+
 static int mtk_mac_finish(struct phylink_config *config, unsigned int mode,
 			  phy_interface_t interface)
 {
@@ -667,6 +748,10 @@ static int mtk_mac_finish(struct phylink_config *config, unsigned int mode,
 	struct mtk_eth *eth = mac->hw;
 	u32 mcr_cur, mcr_new;
 
+	/* Setup PMA/PMD */
+	if (mac->pextp)
+		phy_set_mode_ext(mac->pextp, PHY_MODE_ETHERNET, interface);
+
 	/* Enable SGMII */
 	if (interface == PHY_INTERFACE_MODE_SGMII ||
 	    phy_interface_mode_is_8023z(interface))
@@ -692,10 +777,13 @@ static void mtk_mac_link_down(struct phylink_config *config, unsigned int mode,
 {
 	struct mtk_mac *mac = container_of(config, struct mtk_mac,
 					   phylink_config);
-	u32 mcr = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
 
-	mcr &= ~(MAC_MCR_TX_EN | MAC_MCR_RX_EN);
-	mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
+	if (!mtk_interface_mode_is_xgmii(interface)) {
+		mtk_m32(mac->hw, MAC_MCR_TX_EN | MAC_MCR_RX_EN, 0, MTK_MAC_MCR(mac->id));
+		mtk_m32(mac->hw, MTK_XGMAC_FORCE_LINK(mac->id), 0, MTK_XGMAC_STS(mac->id));
+	} else if (mac->id != MTK_GMAC1_ID) {
+		mtk_m32(mac->hw, XMAC_MCR_TRX_DISABLE, XMAC_MCR_TRX_DISABLE, MTK_XMAC_MCR(mac->id));
+	}
 }
 
 static void mtk_set_queue_speed(struct mtk_eth *eth, unsigned int idx,
@@ -767,13 +855,11 @@ static void mtk_set_queue_speed(struct mtk_eth *eth, unsigned int idx,
 	mtk_w32(eth, val, soc->reg_map->qdma.qtx_sch + ofs);
 }
 
-static void mtk_mac_link_up(struct phylink_config *config,
-			    struct phy_device *phy,
-			    unsigned int mode, phy_interface_t interface,
-			    int speed, int duplex, bool tx_pause, bool rx_pause)
+static void mtk_gdm_mac_link_up(struct mtk_mac *mac,
+				struct phy_device *phy,
+				unsigned int mode, phy_interface_t interface,
+				int speed, int duplex, bool tx_pause, bool rx_pause)
 {
-	struct mtk_mac *mac = container_of(config, struct mtk_mac,
-					   phylink_config);
 	u32 mcr;
 
 	mcr = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
@@ -807,9 +893,63 @@ static void mtk_mac_link_up(struct phylink_config *config,
 	mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
 }
 
+static void mtk_xgdm_mac_link_up(struct mtk_mac *mac,
+				 struct phy_device *phy,
+				 unsigned int mode, phy_interface_t interface,
+				 int speed, int duplex, bool tx_pause, bool rx_pause)
+{
+	u32 mcr, force_link = 0;
+
+	if (mac->id == MTK_GMAC1_ID)
+		return;
+
+	/* Eliminate the interference(before link-up) caused by PHY noise */
+	mtk_m32(mac->hw, XMAC_LOGIC_RST, 0, MTK_XMAC_LOGIC_RST(mac->id));
+	mdelay(20);
+	mtk_m32(mac->hw, XMAC_GLB_CNTCLR, XMAC_GLB_CNTCLR, MTK_XMAC_CNT_CTRL(mac->id));
+
+	if (mac->interface == PHY_INTERFACE_MODE_INTERNAL || mac->id == MTK_GMAC3_ID)
+		force_link = MTK_XGMAC_FORCE_LINK(mac->id);
+
+	mtk_m32(mac->hw, MTK_XGMAC_FORCE_LINK(mac->id), force_link, MTK_XGMAC_STS(mac->id));
+
+	mcr = mtk_r32(mac->hw, MTK_XMAC_MCR(mac->id));
+	mcr &= ~(XMAC_MCR_FORCE_TX_FC | XMAC_MCR_FORCE_RX_FC | XMAC_MCR_TRX_DISABLE);
+	/* Configure pause modes -
+	 * phylink will avoid these for half duplex
+	 */
+	if (tx_pause)
+		mcr |= XMAC_MCR_FORCE_TX_FC;
+	if (rx_pause)
+		mcr |= XMAC_MCR_FORCE_RX_FC;
+
+	mtk_w32(mac->hw, mcr, MTK_XMAC_MCR(mac->id));
+}
+
+static void mtk_mac_link_up(struct phylink_config *config,
+			    struct phy_device *phy,
+			    unsigned int mode, phy_interface_t interface,
+			    int speed, int duplex, bool tx_pause, bool rx_pause)
+{
+	struct mtk_mac *mac = container_of(config, struct mtk_mac,
+					   phylink_config);
+
+	if (mtk_interface_mode_is_xgmii(interface))
+		mtk_xgdm_mac_link_up(mac, phy, mode, interface, speed, duplex,
+				     tx_pause, rx_pause);
+	else
+		mtk_gdm_mac_link_up(mac, phy, mode, interface, speed, duplex,
+				    tx_pause, rx_pause);
+
+	/* Repeat pextp setup to tune link */
+	if (mac->pextp)
+		phy_set_mode_ext(mac->pextp, PHY_MODE_ETHERNET, interface);
+}
+
 static const struct phylink_mac_ops mtk_phylink_ops = {
 	.mac_select_pcs = mtk_mac_select_pcs,
 	.mac_config = mtk_mac_config,
+	.mac_prepare = mtk_mac_prepare,
 	.mac_finish = mtk_mac_finish,
 	.mac_link_down = mtk_mac_link_down,
 	.mac_link_up = mtk_mac_link_up,
@@ -3359,6 +3499,9 @@ static int mtk_open(struct net_device *dev)
 	struct mtk_eth *eth = mac->hw;
 	int i, err;
 
+	if (mac->pextp)
+		phy_power_on(mac->pextp);
+
 	err = phylink_of_phy_connect(mac->phylink, mac->of_node, 0);
 	if (err) {
 		netdev_err(dev, "%s: could not attach PHY: %d\n", __func__,
@@ -3488,6 +3631,9 @@ static int mtk_stop(struct net_device *dev)
 	for (i = 0; i < ARRAY_SIZE(eth->ppe); i++)
 		mtk_ppe_stop(eth->ppe[i]);
 
+	if (mac->pextp)
+		phy_power_off(mac->pextp);
+
 	return 0;
 }
 
@@ -4487,6 +4633,7 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 	const __be32 *_id = of_get_property(np, "reg", NULL);
 	phy_interface_t phy_mode;
 	struct phylink *phylink;
+	struct phylink_pcs *pcs = NULL;
 	struct mtk_mac *mac;
 	int id, err;
 	int txqs = 1;
@@ -4521,16 +4668,39 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 	mac->id = id;
 	mac->hw = eth;
 	mac->of_node = np;
+	mac->sgmii_pcs_of_node = of_parse_phandle(mac->of_node, "pcs-handle", 0);
+	if (mac->sgmii_pcs_of_node) {
+		pcs = mtk_pcs_lynxi_select_pcs(mac->sgmii_pcs_of_node, PHY_INTERFACE_MODE_NA);
+		if (IS_ERR(pcs)) {
+			if (PTR_ERR(pcs) != -EPROBE_DEFER)
+				dev_err(eth->dev, "cannot select SGMII PCS, error %ld\n",
+					PTR_ERR(pcs));
+
+			return PTR_ERR(pcs);
+		}
+	}
 
-	err = of_get_ethdev_address(mac->of_node, eth->netdev[id]);
-	if (err == -EPROBE_DEFER)
-		return err;
+	mac->usxgmii_pcs_of_node = of_parse_phandle(mac->of_node, "pcs-handle", 1);
+	if (mac->usxgmii_pcs_of_node) {
+		pcs = mtk_usxgmii_select_pcs(mac->usxgmii_pcs_of_node, PHY_INTERFACE_MODE_NA);
+		if (IS_ERR(pcs)) {
+			if (PTR_ERR(pcs) != -EPROBE_DEFER)
+				dev_err(eth->dev, "cannot select USXGMII PCS, error %ld\n",
+					PTR_ERR(pcs));
 
-	if (err) {
-		/* If the mac address is invalid, use random mac address */
-		eth_hw_addr_random(eth->netdev[id]);
-		dev_err(eth->dev, "generated random MAC address %pM\n",
-			eth->netdev[id]->dev_addr);
+			return PTR_ERR(pcs);
+		}
+	}
+
+	if (pcs && mtk_is_netsys_v3_or_greater(eth)) {
+		mac->pextp = devm_of_phy_get(eth->dev, mac->of_node, NULL);
+		if (IS_ERR(mac->pextp)) {
+			if (PTR_ERR(mac->pextp) != -EPROBE_DEFER)
+				dev_err(eth->dev, "cannot get PHY, error %ld\n",
+					PTR_ERR(mac->pextp));
+
+			return PTR_ERR(mac->pextp);
+		}
 	}
 
 	memset(mac->hwlro_ip, 0, sizeof(mac->hwlro_ip));
@@ -4613,8 +4783,21 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 		phy_interface_zero(mac->phylink_config.supported_interfaces);
 		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
 			  mac->phylink_config.supported_interfaces);
+	} else if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_USXGMII)) {
+		mac->phylink_config.mac_capabilities |= MAC_5000FD | MAC_10000FD;
+		__set_bit(PHY_INTERFACE_MODE_5GBASER,
+			  mac->phylink_config.supported_interfaces);
+		__set_bit(PHY_INTERFACE_MODE_10GBASER,
+			  mac->phylink_config.supported_interfaces);
+		__set_bit(PHY_INTERFACE_MODE_USXGMII,
+			  mac->phylink_config.supported_interfaces);
 	}
 
+	if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_2P5GPHY) &&
+	    id == MTK_GMAC2_ID)
+		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
+			  mac->phylink_config.supported_interfaces);
+
 	phylink = phylink_create(&mac->phylink_config,
 				 of_fwnode_handle(mac->of_node),
 				 phy_mode, &mtk_phylink_ops);
@@ -4665,6 +4848,26 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 	return err;
 }
 
+static int mtk_mac_assign_address(struct mtk_eth *eth, int i, bool test_defer_only)
+{
+	int err = of_get_ethdev_address(eth->mac[i]->of_node, eth->netdev[i]);
+
+	if (err == -EPROBE_DEFER)
+		return err;
+
+	if (test_defer_only)
+		return 0;
+
+	if (err) {
+		/* If the mac address is invalid, use random mac address */
+		eth_hw_addr_random(eth->netdev[i]);
+		dev_err(eth->dev, "generated random MAC address %pM\n",
+			eth->netdev[i]);
+	}
+
+	return 0;
+}
+
 void mtk_eth_set_dma_device(struct mtk_eth *eth, struct device *dma_dev)
 {
 	struct net_device *dev, *tmp;
@@ -4808,7 +5011,8 @@ static int mtk_probe(struct platform_device *pdev)
 			regmap_write(cci, 0, 3);
 	}
 
-	if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII)) {
+	if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII) &&
+	    !mtk_is_netsys_v3_or_greater(eth)) {
 		err = mtk_sgmii_init(eth);
 
 		if (err)
@@ -4919,6 +5123,24 @@ static int mtk_probe(struct platform_device *pdev)
 		}
 	}
 
+	for (i = 0; i < MTK_MAX_DEVS; i++) {
+		if (!eth->netdev[i])
+			continue;
+
+		err = mtk_mac_assign_address(eth, i, true);
+		if (err)
+			goto err_deinit_hw;
+	}
+
+	for (i = 0; i < MTK_MAX_DEVS; i++) {
+		if (!eth->netdev[i])
+			continue;
+
+		err = mtk_mac_assign_address(eth, i, false);
+		if (err)
+			goto err_deinit_hw;
+	}
+
 	if (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_INT)) {
 		err = devm_request_irq(eth->dev, eth->irq[0],
 				       mtk_handle_irq, 0,
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 9ae3b8a71d0e6..c021fc6efe0f5 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -15,6 +15,7 @@
 #include <linux/u64_stats_sync.h>
 #include <linux/refcount.h>
 #include <linux/phylink.h>
+#include <linux/reset.h>
 #include <linux/rhashtable.h>
 #include <linux/dim.h>
 #include <linux/bitfield.h>
@@ -503,6 +504,21 @@
 #define INTF_MODE_RGMII_1000    (TRGMII_MODE | TRGMII_CENTRAL_ALIGNED)
 #define INTF_MODE_RGMII_10_100  0
 
+/* XFI Mac control registers */
+#define MTK_XMAC_BASE(x)	(0x12000 + (((x) - 1) * 0x1000))
+#define MTK_XMAC_MCR(x)		(MTK_XMAC_BASE(x))
+#define XMAC_MCR_TRX_DISABLE	0xf
+#define XMAC_MCR_FORCE_TX_FC	BIT(5)
+#define XMAC_MCR_FORCE_RX_FC	BIT(4)
+
+/* XFI Mac logic reset registers */
+#define MTK_XMAC_LOGIC_RST(x)	(MTK_XMAC_BASE(x) + 0x10)
+#define XMAC_LOGIC_RST		BIT(0)
+
+/* XFI Mac count global control */
+#define MTK_XMAC_CNT_CTRL(x)	(MTK_XMAC_BASE(x) + 0x100)
+#define XMAC_GLB_CNTCLR		BIT(0)
+
 /* GPIO port control registers for GMAC 2*/
 #define GPIO_OD33_CTRL8		0x4c0
 #define GPIO_BIAS_CTRL		0xed0
@@ -528,6 +544,7 @@
 #define SYSCFG0_SGMII_GMAC2    ((3 << 8) & SYSCFG0_SGMII_MASK)
 #define SYSCFG0_SGMII_GMAC1_V2 BIT(9)
 #define SYSCFG0_SGMII_GMAC2_V2 BIT(8)
+#define SYSCFG0_SGMII_GMAC3_V2 BIT(7)
 
 
 /* ethernet subsystem clock register */
@@ -566,6 +583,11 @@
 #define GEPHY_MAC_SEL          BIT(1)
 
 /* Top misc registers */
+#define TOP_MISC_NETSYS_PCS_MUX	0x84
+#define NETSYS_PCS_MUX_MASK	GENMASK(1, 0)
+#define	MUX_G2_USXGMII_SEL	BIT(1)
+#define MUX_HSGMII1_G1_SEL	BIT(0)
+
 #define USB_PHY_SWITCH_REG	0x218
 #define QPHY_SEL_MASK		GENMASK(1, 0)
 #define SGMII_QPHY_SEL		0x2
@@ -590,6 +612,8 @@
 #define MT7628_SDM_RBCNT	(MT7628_SDM_OFFSET + 0x10c)
 #define MT7628_SDM_CS_ERR	(MT7628_SDM_OFFSET + 0x110)
 
+/* Debug Purpose Register */
+#define MTK_PSE_FQFC_CFG	0x100
 #define MTK_FE_CDM1_FSM		0x220
 #define MTK_FE_CDM2_FSM		0x224
 #define MTK_FE_CDM3_FSM		0x238
@@ -598,6 +622,11 @@
 #define MTK_FE_CDM6_FSM		0x328
 #define MTK_FE_GDM1_FSM		0x228
 #define MTK_FE_GDM2_FSM		0x22C
+#define MTK_FE_GDM3_FSM		0x23C
+#define MTK_FE_PSE_FREE		0x240
+#define MTK_FE_DROP_FQ		0x244
+#define MTK_FE_DROP_FC		0x248
+#define MTK_FE_DROP_PPE		0x24C
 
 #define MTK_MAC_FSM(x)		(0x1010C + ((x) * 0x100))
 
@@ -722,12 +751,8 @@ enum mtk_clks_map {
 	MTK_CLK_ETHWARP_WOCPU2,
 	MTK_CLK_ETHWARP_WOCPU1,
 	MTK_CLK_ETHWARP_WOCPU0,
-	MTK_CLK_TOP_USXGMII_SBUS_0_SEL,
-	MTK_CLK_TOP_USXGMII_SBUS_1_SEL,
 	MTK_CLK_TOP_SGM_0_SEL,
 	MTK_CLK_TOP_SGM_1_SEL,
-	MTK_CLK_TOP_XFI_PHY_0_XTAL_SEL,
-	MTK_CLK_TOP_XFI_PHY_1_XTAL_SEL,
 	MTK_CLK_TOP_ETH_GMII_SEL,
 	MTK_CLK_TOP_ETH_REFCK_50M_SEL,
 	MTK_CLK_TOP_ETH_SYS_200M_SEL,
@@ -798,19 +823,9 @@ enum mtk_clks_map {
 				 BIT_ULL(MTK_CLK_GP3) | BIT_ULL(MTK_CLK_XGP1) | \
 				 BIT_ULL(MTK_CLK_XGP2) | BIT_ULL(MTK_CLK_XGP3) | \
 				 BIT_ULL(MTK_CLK_CRYPTO) | \
-				 BIT_ULL(MTK_CLK_SGMII_TX_250M) | \
-				 BIT_ULL(MTK_CLK_SGMII_RX_250M) | \
-				 BIT_ULL(MTK_CLK_SGMII2_TX_250M) | \
-				 BIT_ULL(MTK_CLK_SGMII2_RX_250M) | \
 				 BIT_ULL(MTK_CLK_ETHWARP_WOCPU2) | \
 				 BIT_ULL(MTK_CLK_ETHWARP_WOCPU1) | \
 				 BIT_ULL(MTK_CLK_ETHWARP_WOCPU0) | \
-				 BIT_ULL(MTK_CLK_TOP_USXGMII_SBUS_0_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_USXGMII_SBUS_1_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_SGM_0_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_SGM_1_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_XFI_PHY_0_XTAL_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_XFI_PHY_1_XTAL_SEL) | \
 				 BIT_ULL(MTK_CLK_TOP_ETH_GMII_SEL) | \
 				 BIT_ULL(MTK_CLK_TOP_ETH_REFCK_50M_SEL) | \
 				 BIT_ULL(MTK_CLK_TOP_ETH_SYS_200M_SEL) | \
@@ -944,6 +959,8 @@ enum mkt_eth_capabilities {
 	MTK_RGMII_BIT = 0,
 	MTK_TRGMII_BIT,
 	MTK_SGMII_BIT,
+	MTK_USXGMII_BIT,
+	MTK_2P5GPHY_BIT,
 	MTK_ESW_BIT,
 	MTK_GEPHY_BIT,
 	MTK_MUX_BIT,
@@ -964,8 +981,11 @@ enum mkt_eth_capabilities {
 	MTK_ETH_MUX_GDM1_TO_GMAC1_ESW_BIT,
 	MTK_ETH_MUX_GMAC2_GMAC0_TO_GEPHY_BIT,
 	MTK_ETH_MUX_U3_GMAC2_TO_QPHY_BIT,
+	MTK_ETH_MUX_GMAC2_TO_2P5GPHY_BIT,
 	MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII_BIT,
 	MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII_BIT,
+	MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII_BIT,
+	MTK_ETH_MUX_GMAC123_TO_USXGMII_BIT,
 
 	/* PATH BITS */
 	MTK_ETH_PATH_GMAC1_RGMII_BIT,
@@ -973,14 +993,21 @@ enum mkt_eth_capabilities {
 	MTK_ETH_PATH_GMAC1_SGMII_BIT,
 	MTK_ETH_PATH_GMAC2_RGMII_BIT,
 	MTK_ETH_PATH_GMAC2_SGMII_BIT,
+	MTK_ETH_PATH_GMAC2_2P5GPHY_BIT,
 	MTK_ETH_PATH_GMAC2_GEPHY_BIT,
+	MTK_ETH_PATH_GMAC3_SGMII_BIT,
 	MTK_ETH_PATH_GDM1_ESW_BIT,
+	MTK_ETH_PATH_GMAC1_USXGMII_BIT,
+	MTK_ETH_PATH_GMAC2_USXGMII_BIT,
+	MTK_ETH_PATH_GMAC3_USXGMII_BIT,
 };
 
 /* Supported hardware group on SoCs */
 #define MTK_RGMII		BIT_ULL(MTK_RGMII_BIT)
 #define MTK_TRGMII		BIT_ULL(MTK_TRGMII_BIT)
 #define MTK_SGMII		BIT_ULL(MTK_SGMII_BIT)
+#define MTK_USXGMII		BIT_ULL(MTK_USXGMII_BIT)
+#define MTK_2P5GPHY		BIT_ULL(MTK_2P5GPHY_BIT)
 #define MTK_ESW			BIT_ULL(MTK_ESW_BIT)
 #define MTK_GEPHY		BIT_ULL(MTK_GEPHY_BIT)
 #define MTK_MUX			BIT_ULL(MTK_MUX_BIT)
@@ -1003,10 +1030,16 @@ enum mkt_eth_capabilities {
 	BIT_ULL(MTK_ETH_MUX_GMAC2_GMAC0_TO_GEPHY_BIT)
 #define MTK_ETH_MUX_U3_GMAC2_TO_QPHY		\
 	BIT_ULL(MTK_ETH_MUX_U3_GMAC2_TO_QPHY_BIT)
+#define MTK_ETH_MUX_GMAC2_TO_2P5GPHY		\
+	BIT_ULL(MTK_ETH_MUX_GMAC2_TO_2P5GPHY_BIT)
 #define MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII	\
 	BIT_ULL(MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII_BIT)
 #define MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII	\
 	BIT_ULL(MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII_BIT)
+#define MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII	\
+	BIT_ULL(MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII_BIT)
+#define MTK_ETH_MUX_GMAC123_TO_USXGMII	\
+	BIT_ULL(MTK_ETH_MUX_GMAC123_TO_USXGMII_BIT)
 
 /* Supported path present on SoCs */
 #define MTK_ETH_PATH_GMAC1_RGMII	BIT_ULL(MTK_ETH_PATH_GMAC1_RGMII_BIT)
@@ -1014,8 +1047,13 @@ enum mkt_eth_capabilities {
 #define MTK_ETH_PATH_GMAC1_SGMII	BIT_ULL(MTK_ETH_PATH_GMAC1_SGMII_BIT)
 #define MTK_ETH_PATH_GMAC2_RGMII	BIT_ULL(MTK_ETH_PATH_GMAC2_RGMII_BIT)
 #define MTK_ETH_PATH_GMAC2_SGMII	BIT_ULL(MTK_ETH_PATH_GMAC2_SGMII_BIT)
+#define MTK_ETH_PATH_GMAC2_2P5GPHY	BIT_ULL(MTK_ETH_PATH_GMAC2_2P5GPHY_BIT)
 #define MTK_ETH_PATH_GMAC2_GEPHY	BIT_ULL(MTK_ETH_PATH_GMAC2_GEPHY_BIT)
+#define MTK_ETH_PATH_GMAC3_SGMII	BIT_ULL(MTK_ETH_PATH_GMAC3_SGMII_BIT)
 #define MTK_ETH_PATH_GDM1_ESW		BIT_ULL(MTK_ETH_PATH_GDM1_ESW_BIT)
+#define MTK_ETH_PATH_GMAC1_USXGMII	BIT_ULL(MTK_ETH_PATH_GMAC1_USXGMII_BIT)
+#define MTK_ETH_PATH_GMAC2_USXGMII	BIT_ULL(MTK_ETH_PATH_GMAC2_USXGMII_BIT)
+#define MTK_ETH_PATH_GMAC3_USXGMII	BIT_ULL(MTK_ETH_PATH_GMAC3_USXGMII_BIT)
 
 #define MTK_GMAC1_RGMII		(MTK_ETH_PATH_GMAC1_RGMII | MTK_RGMII)
 #define MTK_GMAC1_TRGMII	(MTK_ETH_PATH_GMAC1_TRGMII | MTK_TRGMII)
@@ -1023,7 +1061,12 @@ enum mkt_eth_capabilities {
 #define MTK_GMAC2_RGMII		(MTK_ETH_PATH_GMAC2_RGMII | MTK_RGMII)
 #define MTK_GMAC2_SGMII		(MTK_ETH_PATH_GMAC2_SGMII | MTK_SGMII)
 #define MTK_GMAC2_GEPHY		(MTK_ETH_PATH_GMAC2_GEPHY | MTK_GEPHY)
+#define MTK_GMAC2_2P5GPHY	(MTK_ETH_PATH_GMAC2_2P5GPHY | MTK_2P5GPHY)
+#define MTK_GMAC3_SGMII		(MTK_ETH_PATH_GMAC3_SGMII | MTK_SGMII)
 #define MTK_GDM1_ESW		(MTK_ETH_PATH_GDM1_ESW | MTK_ESW)
+#define MTK_GMAC1_USXGMII	(MTK_ETH_PATH_GMAC1_USXGMII | MTK_USXGMII)
+#define MTK_GMAC2_USXGMII	(MTK_ETH_PATH_GMAC2_USXGMII | MTK_USXGMII)
+#define MTK_GMAC3_USXGMII	(MTK_ETH_PATH_GMAC3_USXGMII | MTK_USXGMII)
 
 /* MUXes present on SoCs */
 /* 0: GDM1 -> GMAC1, 1: GDM1 -> ESW */
@@ -1042,10 +1085,20 @@ enum mkt_eth_capabilities {
 	(MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII | MTK_MUX | \
 	MTK_SHARED_SGMII)
 
+/* 2: GMAC2 -> XGMII */
+#define MTK_MUX_GMAC2_TO_2P5GPHY      \
+	(MTK_ETH_MUX_GMAC2_TO_2P5GPHY | MTK_MUX | MTK_INFRA)
+
 /* 0: GMACx -> GEPHY, 1: GMACx -> SGMII where x is 1 or 2 */
 #define MTK_MUX_GMAC12_TO_GEPHY_SGMII   \
 	(MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII | MTK_MUX)
 
+#define MTK_MUX_GMAC123_TO_GEPHY_SGMII   \
+	(MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII | MTK_MUX)
+
+#define MTK_MUX_GMAC123_TO_USXGMII   \
+	(MTK_ETH_MUX_GMAC123_TO_USXGMII | MTK_MUX | MTK_INFRA)
+
 #define MTK_HAS_CAPS(caps, _x)		(((caps) & (_x)) == (_x))
 
 #define MT7621_CAPS  (MTK_GMAC1_RGMII | MTK_GMAC1_TRGMII | \
@@ -1077,8 +1130,12 @@ enum mkt_eth_capabilities {
 		      MTK_MUX_GMAC12_TO_GEPHY_SGMII | MTK_QDMA | \
 		      MTK_RSTCTRL_PPE1 | MTK_SRAM)
 
-#define MT7988_CAPS  (MTK_36BIT_DMA | MTK_GDM1_ESW | MTK_QDMA | \
-		      MTK_RSTCTRL_PPE1 | MTK_RSTCTRL_PPE2 | MTK_SRAM)
+#define MT7988_CAPS  (MTK_36BIT_DMA | MTK_GDM1_ESW | MTK_GMAC1_SGMII | \
+		      MTK_GMAC2_2P5GPHY | MTK_GMAC2_SGMII | MTK_GMAC2_USXGMII | \
+		      MTK_GMAC3_SGMII | MTK_GMAC3_USXGMII | \
+		      MTK_MUX_GMAC123_TO_GEPHY_SGMII | \
+		      MTK_MUX_GMAC123_TO_USXGMII | MTK_MUX_GMAC2_TO_2P5GPHY | \
+		      MTK_QDMA | MTK_RSTCTRL_PPE1 | MTK_RSTCTRL_PPE2 | MTK_SRAM)
 
 struct mtk_tx_dma_desc_info {
 	dma_addr_t	addr;
@@ -1313,6 +1370,9 @@ struct mtk_mac {
 	phy_interface_t			interface;
 	int				speed;
 	struct device_node		*of_node;
+	struct device_node		*sgmii_pcs_of_node;
+	struct device_node		*usxgmii_pcs_of_node;
+	struct phy			*pextp;
 	struct phylink			*phylink;
 	struct phylink_config		phylink_config;
 	struct mtk_eth			*hw;
@@ -1421,6 +1481,19 @@ static inline u32 mtk_get_ib2_multicast_mask(struct mtk_eth *eth)
 	return MTK_FOE_IB2_MULTICAST;
 }
 
+static inline bool mtk_interface_mode_is_xgmii(phy_interface_t interface)
+{
+	switch (interface) {
+	case PHY_INTERFACE_MODE_INTERNAL:
+	case PHY_INTERFACE_MODE_USXGMII:
+	case PHY_INTERFACE_MODE_10GBASER:
+	case PHY_INTERFACE_MODE_5GBASER:
+		return true;
+	default:
+		return false;
+	}
+}
+
 /* read the hardware status register */
 void mtk_stats_update_mac(struct mtk_mac *mac);
 
@@ -1429,8 +1502,10 @@ u32 mtk_r32(struct mtk_eth *eth, unsigned reg);
 u32 mtk_m32(struct mtk_eth *eth, u32 mask, u32 set, unsigned int reg);
 
 int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id);
+int mtk_gmac_2p5gphy_path_setup(struct mtk_eth *eth, int mac_id);
 int mtk_gmac_gephy_path_setup(struct mtk_eth *eth, int mac_id);
 int mtk_gmac_rgmii_path_setup(struct mtk_eth *eth, int mac_id);
+int mtk_gmac_usxgmii_path_setup(struct mtk_eth *eth, int mac_id);
 
 int mtk_eth_offload_init(struct mtk_eth *eth);
 int mtk_eth_setup_tc(struct net_device *dev, enum tc_setup_type type,
-- 
2.43.0


From shawnguo at kernel.org  Tue Dec  5 17:48:02 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:48:02 +0800
Subject: [PATCH v1] arm64: dts: imx8-apalis: set wifi regulator to
 always-on
In-Reply-To: <ZV8v5zd8G6f7BdN9@francesco-nb.int.toradex.com>
References: <20231123104812.13906-1-francesco@dolcini.it>
 <CAOMZO5A53XFbRBp6QXWoDVBr=J347_riO1wWgPLxczT3JcuwQA@mail.gmail.com>
 <ZV8v5zd8G6f7BdN9@francesco-nb.int.toradex.com>
Message-ID: <20231206014802.GC236001@dragon>

On Thu, Nov 23, 2023 at 11:56:39AM +0100, Francesco Dolcini wrote:
> Hello Fabio,
> 
> On Thu, Nov 23, 2023 at 07:52:27AM -0300, Fabio Estevam wrote:
> > On Thu, Nov 23, 2023 at 7:48?AM Francesco Dolcini <francesco at dolcini.it> wrote:
> > >
> > > From: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> > >
> > > Make sure that the wifi regulator is always on. The wifi driver itself
> > > puts the wifi module into suspend mode. If we cut the power the driver
> > > will crash when resuming from suspend.
> > >
> > > Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> > > Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> > 
> > I think this one deserves a Fixes tag.
> 
> Fixes: ad0de4ceb706 ("arm64: dts: freescale: add initial apalis imx8 aka quadmax module support")
> 
> Shawn, I assume you could just pick the Fixes tag without me sending a
> v2, if you disagree just speak-up.

Applied with the Fixes tag, thanks!


From shawnguo at kernel.org  Tue Dec  5 17:51:00 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:51:00 +0800
Subject: [PATCH 1/2] ARM: dts: nxp: minor whitespace cleanup around '='
In-Reply-To: <20231124095104.58772-1-krzysztof.kozlowski@linaro.org>
References: <20231124095104.58772-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231206015100.GD236001@dragon>

On Fri, Nov 24, 2023 at 10:51:03AM +0100, Krzysztof Kozlowski wrote:
> The DTS code coding style expects exactly one space before and after '='
> sign.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Applied both, thanks!


From moritzf at google.com  Tue Dec  5 17:53:37 2023
From: moritzf at google.com (Moritz Fischer)
Date: Wed, 6 Dec 2023 01:53:37 +0000
Subject: [PATCH v3 00/19] Update SMMUv3 to the modern iommu API (part 1/3)
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <20231206015337.edefoajnku374qpm@google.com>

Hi Jason,

just got back to actually having access to my machine...

On Tue, Dec 05, 2023 at 03:14:32PM -0400, Jason Gunthorpe wrote:
> The SMMUv3 driver was originally written in 2015 when the iommu driver
> facing API looked quite different. The API has evolved, especially lately,
> and the driver has fallen behind.

> This work aims to bring make the SMMUv3 driver the best IOMMU driver with
> the most comprehensive implementation of the API. After all parts it
> addresses:

>   - Global static BLOCKED and IDENTITY domains with 'never fail' attach
>     semantics. BLOCKED is desired for efficient VFIO.

>   - Support map before attach for PAGING iommu_domains.

>   - attach_dev failure does not change the HW configuration.

>   - Fully hitless transitions between IDENTITY -> DMA -> IDENTITY.
>     The API has IOMMU_RESV_DIRECT which is expected to be
>     continuously translating.

>   - Safe transitions between PAGING -> BLOCKED, do not ever temporarily
>     do IDENTITY. This is required for iommufd security.

>   - Full PASID API support including:
>      - S1/SVA domains attached to PASIDs
>      - IDENTITY/BLOCKED/S1 attached to RID
>      - Change of the RID domain while PASIDs are attached

>   - Streamlined SVA support using the core infrastructure

>   - Hitless, whenever possible, change between two domains

>   - iommufd IOMMU_GET_HW_INFO, IOMMU_HWPT_ALLOC_NEST_PARENT, and
>     IOMMU_DOMAIN_NESTED support

> Over all these things are going to become more accessible to iommufd, and
> exposed to VMs, so it is important for the driver to have a robust
> implementation of the API.

> The work is split into three parts, with this part largely focusing on the
> STE and building up to the BLOCKED & IDENTITY global static domains.

> The second part largely focuses on the CD and builds up to having a common
> PASID infrastructure that SVA and S1 domains equally use.

> The third part has some random cleanups and the iommufd related parts.

> Overall this takes the approach of turning the STE/CD programming upside
> down where the CD/STE value is computed right at a driver callback
> function and then pushed down into programming logic. The programming
> logic hides the details of the required CD/STE tear-less update. This
> makes the CD/STE functions independent of the arm_smmu_domain which makes
> it fairly straightforward to untangle all the different call chains, and
> add news ones.

> Further, this frees the arm_smmu_domain related logic from keeping track
> of what state the STE/CD is currently in so it can carefully sequence the
> correct update. There are many new update pairs that are subtly introduced
> as the work progresses.

> The locking to support BTM via arm_smmu_asid_lock is a bit subtle right
> now and patches throughout this work adjust and tighten this so that it is
> clearer and doesn't get broken.

> Once the lower STE layers no longer need to touch arm_smmu_domain we can
> isolate struct arm_smmu_domain to be only used for PAGING domains, audit
> all the to_smmu_domain() calls to be only in PAGING domain ops, and
> introduce the normal global static BLOCKED/IDENTITY domains using the new
> STE infrastructure. Part 2 will ultimately migrate SVA over to use
> arm_smmu_domain as well.

> All parts are on github:

>   https://github.com/jgunthorpe/linux/commits/smmuv3_newapi

> v3:
>   - Use some local variables in arm_smmu_get_step_for_sid() for clarity
>   - White space and spelling changes
>   - Commit message updates
>   - Keep master->domain_head initialized to avoid a list_del corruption
> v2:  
> https://lore.kernel.org/r/0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg at nvidia.com
>   - Rebased on v6.7-rc1
>   - Improve the comment for arm_smmu_write_entry_step()
>   - Fix the botched memcmp
>   - Document the spec justification for the SHCFG exclusion in used
>   - Include STRTAB_STE_1_SHCFG for STRTAB_STE_0_CFG_S2_TRANS in used
>   - WARN_ON for unknown STEs in used
>   - Fix error unwind in arm_smmu_attach_dev()
>   - Whitespace, spelling, and checkpatch related items
> v1:  
> https://lore.kernel.org/r/0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg at nvidia.com

> Jason Gunthorpe (19):
>    iommu/arm-smmu-v3: Add a type for the STE
>    iommu/arm-smmu-v3: Master cannot be NULL in
>      arm_smmu_write_strtab_ent()
>    iommu/arm-smmu-v3: Remove ARM_SMMU_DOMAIN_NESTED
>    iommu/arm-smmu-v3: Make STE programming independent of the callers
>    iommu/arm-smmu-v3: Consolidate the STE generation for abort/bypass
>    iommu/arm-smmu-v3: Move arm_smmu_rmr_install_bypass_ste()
>    iommu/arm-smmu-v3: Move the STE generation for S1 and S2 domains into
>      functions
>    iommu/arm-smmu-v3: Build the whole STE in
>      arm_smmu_make_s2_domain_ste()
>    iommu/arm-smmu-v3: Hold arm_smmu_asid_lock during all of attach_dev
>    iommu/arm-smmu-v3: Compute the STE only once for each master
>    iommu/arm-smmu-v3: Do not change the STE twice during
>      arm_smmu_attach_dev()
>    iommu/arm-smmu-v3: Put writing the context descriptor in the right
>      order
>    iommu/arm-smmu-v3: Pass smmu_domain to arm_enable/disable_ats()
>    iommu/arm-smmu-v3: Remove arm_smmu_master->domain
>    iommu/arm-smmu-v3: Add a global static IDENTITY domain
>    iommu/arm-smmu-v3: Add a global static BLOCKED domain
>    iommu/arm-smmu-v3: Use the identity/blocked domain during release
>    iommu/arm-smmu-v3: Pass arm_smmu_domain and arm_smmu_device to
>      finalize
>    iommu/arm-smmu-v3: Convert to domain_alloc_paging()

>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 729 +++++++++++++-------
>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  12 +-
>   2 files changed, 477 insertions(+), 264 deletions(-)


> base-commit: ca7fcaff577c92d85f0e05cc7be79759155fe328
> --
> 2.43.0


For whole series:
Tested-by: Moritz Fischer <moritzf at google.com>

Cheers,
Moritz


From shawnguo at kernel.org  Tue Dec  5 17:58:32 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 09:58:32 +0800
Subject: [PATCH] MAINTAINERS: reinstate freescale ARM64 DT directory in
 i.MX entry
In-Reply-To: <20231127053414.2200563-1-a.fatoum@pengutronix.de>
References: <20231127053414.2200563-1-a.fatoum@pengutronix.de>
Message-ID: <20231206015832.GE236001@dragon>

On Mon, Nov 27, 2023 at 06:34:14AM +0100, Ahmad Fatoum wrote:
> The MAINTAINERS entry's F: currently only matches the 32-bit device trees,
> as commit 724ba6751532 ("ARM: dts: Move .dts files to vendor sub-directories")
> inadvertently dropped the 64-bit DT match when it added the 32 bit
> matches. The entry has a N: imx, which reduced the impact a bit, but
> still some board device trees may not contain the substring and would
> thus not be covered by the entry.
> 
> Reinstate the missing F: line to restore previous behavior.
> 
> Fixes: 724ba6751532 ("ARM: dts: Move .dts files to vendor sub-directories")
> Signed-off-by: Ahmad Fatoum <a.fatoum at pengutronix.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 18:01:02 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 10:01:02 +0800
Subject: [PATCH v9] ARM: dts: nxp: Fix some common switch mistakes
In-Reply-To: <20231127-mv88e6xxx-nxp-v9-1-69f3f783f4af@linaro.org>
References: <20231127-mv88e6xxx-nxp-v9-1-69f3f783f4af@linaro.org>
Message-ID: <20231206020102.GF236001@dragon>

On Mon, Nov 27, 2023 at 04:55:20PM +0100, Linus Walleij wrote:
> Fix some errors in the Marvell MV88E6xxx switch descriptions:
> - switch0 at 0 is not OK, should be ethernet-switch at 0
> - ports should be ethernet-ports
> - port should be ethernet-port
> - phy should be ethernet-phy
> 
> Reviewed-by: Andrew Lunn <andrew at lunn.ch>
> Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 18:04:21 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 10:04:21 +0800
Subject: [PATCH 2/2] ARM: dts: imx7: add MIPI-DSI support
In-Reply-To: <20231127-b4-imx7-mipi-dsi-v1-2-7d22eee70c67@pengutronix.de>
References: <20231127-b4-imx7-mipi-dsi-v1-0-7d22eee70c67@pengutronix.de>
 <20231127-b4-imx7-mipi-dsi-v1-2-7d22eee70c67@pengutronix.de>
Message-ID: <20231206020421.GG236001@dragon>

On Mon, Nov 27, 2023 at 05:12:29PM +0100, Roland Hieber wrote:
> From: Marco Felsch <m.felsch at pengutronix.de>
> 
> This adds the device tree support for the MIPI-DSI block. The block can
> be used as encoder for the parallel signals coming from the lcdif block.
> 
> Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
> Signed-off-by: Roland Hieber <rhi at pengutronix.de>

Applied this one, thanks!


From shawnguo at kernel.org  Tue Dec  5 18:05:34 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 10:05:34 +0800
Subject: [PATCH] ARM: dts: imx7: Declare timers compatible with
 fsl,imx6dl-gpt
In-Reply-To: <20231127-b4-imx7-dt-v1-1-6ecbd0471cc4@pengutronix.de>
References: <20231127-b4-imx7-dt-v1-1-6ecbd0471cc4@pengutronix.de>
Message-ID: <20231206020534.GH236001@dragon>

On Mon, Nov 27, 2023 at 05:05:01PM +0100, Roland Hieber wrote:
> From: Philipp Zabel <p.zabel at pengutronix.de>
> 
> The timer nodes declare compatibility with "fsl,imx6sx-gpt", which
> itself is compatible with "fsl,imx6dl-gpt". Switch the fallback
> compatible from "fsl,imx6sx-gpt" to "fsl,imx6dl-gpt".
> 
> Fixes: 949673450291 ("ARM: dts: add imx7d soc dtsi file")
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Signed-off-by: Roland Hieber <rhi at pengutronix.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 18:06:51 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 10:06:51 +0800
Subject: [PATCH] ARM: dts: imx7s: Add on-chip memory
In-Reply-To: <20231127-b4-imx7-ocram-v1-1-430a75e3e9db@pengutronix.de>
References: <20231127-b4-imx7-ocram-v1-1-430a75e3e9db@pengutronix.de>
Message-ID: <20231206020651.GI236001@dragon>

On Mon, Nov 27, 2023 at 05:15:01PM +0100, Roland Hieber wrote:
> From: Philipp Zabel <p.zabel at pengutronix.de>
> 
> Add the 128 KiB on-chip SRAM at address 0x900000.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Signed-off-by: Roland Hieber <rhi at pengutronix.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 18:17:11 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 10:17:11 +0800
Subject: [PATCH 1/3] arm64: dts: imx8mm: Simplify mipi_dsi clocks
In-Reply-To: <20231128045415.210682-1-aford173@gmail.com>
References: <20231128045415.210682-1-aford173@gmail.com>
Message-ID: <20231206021711.GJ236001@dragon>

On Mon, Nov 27, 2023 at 10:54:13PM -0600, Adam Ford wrote:
> The device tree clock structure for the mipi_dsi is
> unnecessarily redundant.
> 
> The default clock parent of IMX8MM_CLK_DSI_PHY_REF is
> already IMX8MM_CLK_24M, so there is no need to set the
> parent-child relationship between them.  The default clock
> rates for IMX8MM_SYS_PLL1_266M and IMX8MM_CLK_24M are
> already defined to be 266MHz and 24MHz respectively,
> so there is no need to define those clock rates.
> 
> On i.MX8M[MNP] the  samsung,pll-clock-frequency is not
> necessary, because the driver will read it from sclk_mipi
> which is also already set to 24MHz making it also
> redundant.
> 
> Signed-off-by: Adam Ford <aford173 at gmail.com>

Applied all, thanks!


From shawnguo at kernel.org  Tue Dec  5 18:26:45 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 10:26:45 +0800
Subject: [PATCH v1 0/2] arm64: dts: freescale: verdin-imx8mp: add support
 to mallow board
In-Reply-To: <20231129164022.143340-1-francesco@dolcini.it>
References: <20231129164022.143340-1-francesco@dolcini.it>
Message-ID: <20231206022645.GK236001@dragon>

On Wed, Nov 29, 2023 at 05:40:20PM +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> Add Toradex Verdin IMX8MP Mallow carrier board support. Mallow is a
> low-cost carrier board in the Verdin family with a small form factor and
> build for volume production making it ideal for industrial and embedded
> applications.
> 
> https://www.toradex.com/products/carrier-board/mallow-carrier-board
> 
> Joao Paulo Goncalves (2):
>   dt-bindings: arm: fsl: add verdin imx8mp mallow board
>   arm64: dts: freescale: verdin-imx8mp: add support to mallow board

Applied both, thanks!


From shawnguo at kernel.org  Tue Dec  5 18:34:34 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 10:34:34 +0800
Subject: [PATCH v2 01/14] arm64: dts: imx8mm-kontron: Add support for
 display bridges on BL i.MX8MM
In-Reply-To: <20231130161657.556483-2-frieder@fris.de>
References: <20231130161657.556483-1-frieder@fris.de>
 <20231130161657.556483-2-frieder@fris.de>
Message-ID: <20231206023434.GL236001@dragon>

On Thu, Nov 30, 2023 at 05:16:01PM +0100, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf at kontron.de>
> 
> The Kontron Electronics BL i.MX8MM has oboard disply bridges for
> DSI->HDMI and DSI->LVDS conversion. The DSI interface is muxed by
> a GPIO-controlled switch to one of these two bridges.
> 
> By default the HDMI bridge is enabled. The LVDS bridge can be
> selected by loading an additional (panel-specific) overlay.
> 
> Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
> ---
> Changes for v2:
> * Rework DSI mux GPIO logic to be compatible with overlay
> * Switch from 4 to 2 DSI lanes for LVDS bridge to fix non-working display
> ---
>  .../boot/dts/freescale/imx8mm-kontron-bl.dts  | 158 ++++++++++++++++++
>  1 file changed, 158 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
> index dcec57c20399e..0fb16b811461e 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
> @@ -25,6 +25,17 @@ osc_can: clock-osc-can {
>  		clock-output-names = "osc-can";
>  	};
>  
> +	hdmi-out {
> +		compatible = "hdmi-connector";
> +		type = "a";
> +
> +		port {
> +			hdmi_in_conn: endpoint {
> +				remote-endpoint = <&bridge_out_conn>;
> +			};
> +		};
> +	};
> +
>  	leds {
>  		compatible = "gpio-leds";
>  		pinctrl-names = "default";
> @@ -132,6 +143,102 @@ ethphy: ethernet-phy at 0 {
>  	};
>  };
>  
> +&gpio4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_gpio4>;
> +
> +	dsi_mux_sel_hdmi: dsi-mux-sel-hdmi-hog {
> +		gpio-hog;
> +		gpios = <14 GPIO_ACTIVE_HIGH>;
> +		output-high;
> +		line-name = "dsi-mux-sel";
> +		status = "okay";

Status "okay" is usually used to flip "disabled".

> +	};
> +
> +	dsi_mux_sel_lvds: dsi-mux-sel-lvds-hog {
> +		gpio-hog;
> +		gpios = <14 GPIO_ACTIVE_HIGH>;
> +		output-low;
> +		line-name = "dsi-mux-sel";
> +		status = "disabled";
> +	};
> +
> +	dsi-mux-oe-hog {
> +		gpio-hog;
> +		gpios = <15 GPIO_ACTIVE_LOW>;
> +		output-high;
> +		line-name = "dsi-mux-oe";
> +	};
> +};
> +
> +&i2c3 {
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c3>;
> +	status = "okay";
> +
> +	hdmi: hdmi at 39 {
> +		compatible = "adi,adv7535";
> +		reg = <0x39>;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_adv7535>;
> +
> +		interrupt-parent = <&gpio4>;
> +		interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
> +
> +		adi,dsi-lanes = <4>;
> +
> +		a2vdd-supply = <&reg_vdd_1v8>;
> +		avdd-supply = <&reg_vdd_1v8>;
> +		dvdd-supply = <&reg_vdd_1v8>;
> +		pvdd-supply = <&reg_vdd_1v8>;
> +		v1p2-supply = <&reg_vdd_1v8>;
> +		v3p3-supply = <&reg_vdd_3v3>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;

Have a newline between properties and child node.

Shawn

> +				bridge_in_dsi_hdmi: endpoint {
> +					remote-endpoint = <&dsi_out_bridge>;
> +				};
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +				bridge_out_conn: endpoint {
> +					remote-endpoint = <&hdmi_in_conn>;
> +				};
> +			};
> +		};
> +	};
> +
> +	lvds: bridge at 2c {
> +		compatible = "ti,sn65dsi84";
> +		reg = <0x2c>;
> +		enable-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_sn65dsi84>;
> +		status = "disabled";
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +				bridge_in_dsi_lvds: endpoint {
> +					remote-endpoint = <&dsi_out_bridge>;
> +					data-lanes = <1 2>;
> +				};
> +			};
> +		};
> +	};
> +};
> +
>  &i2c4 {
>  	clock-frequency = <100000>;
>  	pinctrl-names = "default";
> @@ -144,6 +251,30 @@ rx8900: rtc at 32 {
>  	};
>  };
>  
> +&lcdif {
> +	status = "okay";
> +};
> +
> +&mipi_dsi {
> +	samsung,esc-clock-frequency = <54000000>;
> +	/*
> +	 * Let the driver calculate an appropriate clock rate based on the pixel
> +	 * clock instead of using the fixed value from imx8mm.dtsi.
> +	 */
> +	/delete-property/ samsung,pll-clock-frequency;
> +	status = "okay";
> +
> +	ports {
> +		port at 1 {
> +			reg = <1>;
> +
> +			dsi_out_bridge: endpoint {
> +				remote-endpoint = <&bridge_in_dsi_hdmi>;
> +			};
> +		};
> +	};
> +};
> +
>  &pwm2 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_pwm2>;
> @@ -207,6 +338,12 @@ &iomuxc {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_gpio>;
>  
> +	pinctrl_adv7535: adv7535grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI1_TXD4_GPIO4_IO16		0x19
> +		>;
> +	};
> +
>  	pinctrl_can: cangrp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28		0x19
> @@ -277,6 +414,20 @@ MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19
>  		>;
>  	};
>  
> +	pinctrl_gpio4: gpio4grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI1_TXD2_GPIO4_IO14		0x19
> +			MX8MM_IOMUXC_SAI1_TXD3_GPIO4_IO15		0x19
> +		>;
> +	};
> +
> +	pinctrl_i2c3: i2c3grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083
> +			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083
> +		>;
> +	};
> +
>  	pinctrl_i2c4: i2c4grp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x400001c3
> @@ -290,6 +441,13 @@ MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT			0x19
>  		>;
>  	};
>  
> +	pinctrl_sn65dsi84: sn65dsi84grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI2_TXD0_GPIO4_IO26		0x19
> +			MX8MM_IOMUXC_SD2_WP_GPIO2_IO20			0x19
> +		>;
> +	};
> +
>  	pinctrl_uart1: uart1grp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x140
> -- 
> 2.43.0
> 


From shawnguo at kernel.org  Tue Dec  5 18:43:55 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 10:43:55 +0800
Subject: [PATCH v2 02/14] arm64: dts: imx8mm-kontron: Add DL
 (Display-Line) overlay with LVDS support
In-Reply-To: <20231130161657.556483-3-frieder@fris.de>
References: <20231130161657.556483-1-frieder@fris.de>
 <20231130161657.556483-3-frieder@fris.de>
Message-ID: <20231206024355.GM236001@dragon>

On Thu, Nov 30, 2023 at 05:16:02PM +0100, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf at kontron.de>
> 
> The Kontron Electronics DL i.MX8MM consists of the BL i.MX8MM board
> and a 7" LVDS panel. Provide an overlay that enables the panel.
> 
> Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
> ---
> Changes for v2:
> * Rework DSI mux GPIO logic to be compatible with overlay
> ---
>  arch/arm64/boot/dts/freescale/Makefile        |   4 +
>  .../boot/dts/freescale/imx8mm-kontron-dl.dtso | 200 ++++++++++++++++++
>  2 files changed, 204 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso
> 
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 300049037eb0b..e08024797721a 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -166,6 +166,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla.dtb
>  
> +imx8mm-kontron-dl-dtbs			:= imx8mm-kontron-bl.dtb imx8mm-kontron-dl.dtbo
> +
> +dtb-$(CONFIG_ARCH_MXC) += imx8mm-kontron-dl.dtb
> +
>  imx8mm-venice-gw72xx-0x-imx219-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-imx219.dtbo
>  imx8mm-venice-gw72xx-0x-rpidsi-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rpidsi.dtbo
>  imx8mm-venice-gw72xx-0x-rs232-rts-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rs232-rts.dtbo
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso b/arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso
> new file mode 100644
> index 0000000000000..c6369072577e0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso
> @@ -0,0 +1,200 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 Kontron Electronics GmbH
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include "imx8mm-pinfunc.h"
> +
> +&{/} {
> +	compatible = "kontron,imx8mm-bl", "kontron,imx8mm-sl", "fsl,imx8mm";
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm1 0 50000 0>;
> +		brightness-levels = <0 100>;
> +		num-interpolated-steps = <100>;
> +		default-brightness-level = <100>;
> +	};
> +
> +	panel {
> +		compatible = "panel-lvds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_panel>;
> +		backlight = <&backlight>;
> +		data-mapping = "vesa-24";
> +		enable-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
> +		height-mm = <86>;
> +		width-mm = <154>;
> +
> +		panel-timing {
> +			clock-frequency = <51200000>;
> +			hactive = <1024>;
> +			vactive = <600>;
> +			hsync-len = <1>;
> +			hfront-porch = <160>;
> +			hback-porch = <160>;
> +			vsync-len = <1>;
> +			vfront-porch = <12>;
> +			vback-porch = <23>;
> +		};
> +
> +		port {
> +			panel_out_bridge: endpoint {
> +				remote-endpoint = <&bridge_out_panel>;
> +			};
> +		};
> +	};
> +};
> +
> +&dsi_mux_sel_hdmi {
> +	status = "disabled";
> +};
> +
> +&dsi_mux_sel_lvds {
> +	status = "okay";
> +};
> +
> +&dsi_out_bridge {
> +	remote-endpoint = <&bridge_in_dsi_lvds>;
> +};
> +
> +&gpio3 {
> +	panel_rst {
> +		gpio-hog;
> +		gpios = <20 GPIO_ACTIVE_HIGH>;
> +		output-high;
> +		line-name = "panel-reset";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_panel_rst>;
> +	};
> +
> +	panel_stby {
> +		gpio-hog;
> +		gpios = <21 GPIO_ACTIVE_HIGH>;
> +		output-high;
> +		line-name = "panel-standby";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_panel_stby>;
> +	};
> +
> +	panel_hinv {
> +		gpio-hog;
> +		gpios = <24 GPIO_ACTIVE_HIGH>;
> +		output-high;
> +		line-name = "panel-horizontal-invert";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_panel_hinv>;
> +	};
> +
> +	panel_vinv {
> +		gpio-hog;
> +		gpios = <25 GPIO_ACTIVE_HIGH>;
> +		output-low;
> +		line-name = "panel-vertical-invert";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_panel_vinv>;
> +	};
> +};
> +
> +&hdmi {
> +	status = "disabled";
> +};
> +
> +&i2c2 {
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +	status = "okay";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	gt911 at 5d {
> +		compatible = "goodix,gt928";
> +		reg = <0x5d>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_touch>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <22 8>;
> +		reset-gpios = <&gpio3 23 0>;
> +		irq-gpios = <&gpio3 22 0>;
> +	};
> +};
> +
> +&lvds {
> +	status = "okay";
> +
> +	ports {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		port at 2 {
> +			reg = <2>;

Have a newline between properties and child node.

> +			bridge_out_panel: endpoint {
> +				remote-endpoint = <&panel_out_bridge>;
> +			};
> +		};
> +	};
> +};
> +
> +&pwm1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm1>;
> +	status = "okay";
> +};
> +
> +&iomuxc {
> +	pinctrl_panel_rst: panelrstgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20		0x19
> +		>;
> +	};
> +
> +	pinctrl_panel_stby: panelstbygrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21		0x19
> +		>;
> +	};
> +
> +	pinctrl_panel_hinv: panelhinvgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24		0x19
> +		>;
> +	};
> +
> +	pinctrl_panel_vinv: panelvinvgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19
> +		>;
> +	};
> +
> +	pinctrl_i2c2: i2c2grp {

Could you sort the pinctrl nodes alphabetically?

Shawn

> +		fsl,pins = <
> +			MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL			0x40000083
> +			MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA			0x40000083
> +		>;
> +	};
> +
> +	pinctrl_pwm1: pwm1grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SPDIF_EXT_CLK_PWM1_OUT		0x6
> +		>;
> +	};
> +
> +	pinctrl_panel: panelgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI5_RXFS_GPIO3_IO19		0x19
> +		>;
> +	};
> +
> +	pinctrl_touch: touchgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22		0x19
> +			MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23		0x19
> +		>;
> +	};
> +};
> -- 
> 2.43.0
> 


From wenst at chromium.org  Tue Dec  5 18:55:44 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 6 Dec 2023 10:55:44 +0800
Subject: [RFC PATCH v3 4/5] arm64: dts: mediatek: mt8173-elm-hana: Mark
 touchscreens and trackpads as fail
In-Reply-To: <3700f05f-2411-4422-972f-f3df690efb84@collabora.com>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-5-wenst@chromium.org>
 <CAD=FV=W01gfxV6RN2o6CVS7jjf8qgKP-jUy9Bp94d2hWzVC48A@mail.gmail.com>
 <CAGXv+5E+R292XsOFSL-j0KJMmVJjWtxMRgCK8besP7mo6NDOWA@mail.gmail.com>
 <CAD=FV=UQkAjgMuR85cPikNtCxsODWPWs7cibOcOoNGdjSSvF8Q@mail.gmail.com> <3700f05f-2411-4422-972f-f3df690efb84@collabora.com>
Message-ID: <CAGXv+5G5fFTv8zn=YamSdccjuYemE5oKBqjb8CSyGzu9aMJ0eg@mail.gmail.com>

On Tue, Dec 5, 2023 at 6:22?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 04/12/23 17:50, Doug Anderson ha scritto:
> > Hi,
> >
> > On Sun, Dec 3, 2023 at 10:59?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >>
> >> On Sat, Dec 2, 2023 at 8:58?AM Doug Anderson <dianders at chromium.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >>>>
> >>>> @@ -44,6 +46,7 @@ trackpad2: trackpad at 2c {
> >>>>                  reg = <0x2c>;
> >>>>                  hid-descr-addr = <0x0020>;
> >>>>                  wakeup-source;
> >>>> +               status = "fail-needs-probe";
> >>>
> >>> While doing this, you could also remove the hack where the trackpad
> >>> IRQ pinctrl is listed under i2c4.
> >>
> >> Sure. I do think we can do away with it though. According to at least one
> >> schematic, the interrupt line has pull-ups on both sides of the voltage
> >> shifter.
> >>
> >> BTW, The touchscreen doesn't have pinctrl entries. This has pull-ups on
> >> both sides of the voltage shifter as well.
> >
> > I dunno if the convention is different on Mediatek boards, but at
> > least on boards I've been involved with in the past we've always put
> > pinctrl entries just to make things explicit. This meant that we
> > didn't rely on the firmware/bootrom/defaults to leave pulls in any
> > particular state. ...otherwise those external pull-ups could be
> > fighting with internal pull-downs, right?
> >
>
> MediaTek boards aren't special and there's no good reason for those to rely on
> firmware/bootrom/defaults - so there is no good reason to avoid declaring any
> relevant pinctrl entry.

I think this should be migrated to use the proper GPIO bindings: the
GPIO_PULL_UP / GPIO_PULL_DOWN / GPIO_BIAS_DISABLE flags.

But that's a different discussion.

ChenYu


From shawnguo at kernel.org  Tue Dec  5 19:01:25 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 11:01:25 +0800
Subject: [PATCH v2 14/14] arm64: dts: imx8mm-kontron: Refactor devicetree
 for OSM-S module and board
In-Reply-To: <20231130161657.556483-15-frieder@fris.de>
References: <20231130161657.556483-1-frieder@fris.de>
 <20231130161657.556483-15-frieder@fris.de>
Message-ID: <20231206030125.GN236001@dragon>

On Thu, Nov 30, 2023 at 05:16:14PM +0100, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf at kontron.de>
> 
> The OSM spec defines dedicated functions for all pads of the SoM.
> Therefore we can assume that carrier board designs stick to these
> definitions and extend the SoM devicetree include with matching
> default nodes and pinmux settings.
> 
> This way we can reduce the overhead and redundancy in the carrier
> board devicetrees while still sticking to the policy of separating
> board and module description.
> 
> Even if the carrier board design deviates slightly from the spec it
> can define its own pinmux definitions and use them as necessary or
> even disable unused nodes from the SoM devicetree.
> 
> Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
> ---
> Changes for v2:
> * none
> ---
>  .../dts/freescale/imx8mm-kontron-bl-osm-s.dts | 269 +++------
>  .../dts/freescale/imx8mm-kontron-osm-s.dtsi   | 552 +++++++++++++++++-
>  2 files changed, 616 insertions(+), 205 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
> index 12f786a72fbd5..efadfdff00af1 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
> @@ -25,8 +25,6 @@ osc_can: clock-osc-can {
>  
>  	leds {
>  		compatible = "gpio-leds";
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&pinctrl_gpio_led>;
>  
>  		led1 {
>  			label = "led1";
> @@ -52,24 +50,12 @@ pwm-beeper {
>  
>  	reg_rst_eth2: regulator-rst-eth2 {
>  		compatible = "regulator-fixed";
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&pinctrl_usb_eth2>;
>  		gpio = <&gpio1 1 GPIO_ACTIVE_HIGH>;
>  		enable-active-high;
>  		regulator-always-on;
>  		regulator-name = "rst-usb-eth2";
>  	};
>  
> -	reg_usb1_vbus: regulator-usb1-vbus {
> -		compatible = "regulator-fixed";
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&pinctrl_reg_usb1_vbus>;
> -		gpio = <&gpio3 25 GPIO_ACTIVE_LOW>;
> -		regulator-min-microvolt = <5000000>;
> -		regulator-max-microvolt = <5000000>;
> -		regulator-name = "usb1-vbus";
> -	};
> -
>  	reg_vdd_5v: regulator-5v {
>  		compatible = "regulator-fixed";
>  		regulator-always-on;
> @@ -80,9 +66,6 @@ reg_vdd_5v: regulator-5v {
>  };
>  
>  &ecspi2 {
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_ecspi2>;
> -	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
>  	status = "okay";
>  
>  	can at 0 {
> @@ -103,9 +86,6 @@ can at 0 {
>  };
>  
>  &ecspi3 {
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_ecspi3>;
> -	cs-gpios = <&gpio5 25 GPIO_ACTIVE_LOW>;
>  	status = "okay";
>  
>  	eeram at 0 {
> @@ -117,7 +97,7 @@ eeram at 0 {
>  
>  &fec1 {
>  	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_enet>;
> +	pinctrl-0 = <&pinctrl_enet_rgmii>;
>  	phy-connection-type = "rgmii-id";
>  	phy-handle = <&ethphy>;
>  	status = "okay";
> @@ -136,27 +116,59 @@ ethphy: ethernet-phy at 0 {
>  	};
>  };
>  
> +/*
> + * Rename SoM signals according to board usage:
> + *   GPIO_B_0      -> DIO1_OUT
> + *   GPIO_B_1      -> DIO2_OUT
> + */
>  &gpio1 {
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_gpio1>;
> -	gpio-line-names = "", "", "", "dio1-out", "", "", "dio1-in", "dio2-out",
> -			  "dio2-in", "dio3-out", "dio3-in", "dio4-out", "", "", "", "",
> -			  "", "", "", "", "", "", "", "",
> -			  "", "", "", "", "", "", "", "";
> +	gpio-line-names = "", "GPIO_A_0", "", "GPIO_A_1",
> +			  "", "GPIO_A_2", "GPIO_A_3", "GPIO_A_4",
> +			  "GPIO_A_5", "GPIO_A_6", "GPIO_A_7", "DIO1_OUT",
> +			  "DIO2_OUT", "USB_A_OC#", "CAM_MCK", "USB_B_OC#",
> +			  "ETH_MDC", "ETH_MDIO", "ETH_A_(S)(R)(G)MII_TXD3",
> +			  "ETH_A_(S)(R)(G)MII_TXD2", "ETH_A_(S)(R)(G)MII_TXD1",
> +			  "ETH_A_(S)(R)(G)MII_TXD0", "ETH_A_(R)(G)MII_TX_EN(_ER)",
> +			  "ETH_A_(R)(G)MII_TX_CLK", "ETH_A_(R)(G)MII_RX_DV(_ER)",
> +			  "ETH_A_(R)(G)MII_RX_CLK", "ETH_A_(S)(R)(G)MII_RXD0",
> +			  "ETH_A_(S)(R)(G)MII_RXD1", "ETH_A_(R)(G)MII_RXD2",
> +			  "ETH_A_(R)(G)MII_RXD3";
>  };
>  
> -&gpio5 {
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_gpio5>;
> -	gpio-line-names = "", "", "dio4-in", "", "", "", "", "",
> -			  "", "", "", "", "", "", "", "",
> -			  "", "", "", "", "", "", "", "",
> -			  "", "", "", "", "", "", "", "";
> +/*
> + * Rename SoM signals according to board usage:
> + *   GPIO_B_2      -> DIO3_OUT
> + *   GPIO_B_3      -> DIO4_OUT
> + */
> +&gpio3 {
> +	gpio-line-names = "GPIO_C_5", "GPIO_C_4", "SDIO_B_CD#", "SDIO_B_D5",
> +			  "SDIO_B_D6", "SDIO_B_D7", "GPIO_C_0", "GPIO_C_1",
> +			  "GPIO_C_2", "GPIO_C_3", "SDIO_B_D0", "SDIO_B_D1",
> +			  "SDIO_B_D2", "SDIO_B_D3", "", "SDIO_B_D4",
> +			  "CARRIER_PWR_EN", "SDIO_B_CLK", "SDIO_B_CMD", "DIO3_OUT",
> +			  "USB_B_EN", "DIO4_OUT", "PCIe_CLKREQ#", "PCIe_A_PERST#",
> +			  "PCIe_WAKE#", "USB_A_EN";
> +};
> +
> +/*
> + * Rename SoM signals according to board usage:
> + *   GPIO_B_4      -> DIO1_IN
> + *   GPIO_B_5      -> DIO2_IN
> + *   GPIO_B_6      -> DIO3_IN
> + *   GPIO_B_7      -> DIO4_IN
> + */
> +&gpio4 {
> +	gpio-line-names = "GPIO_C_7", "", "I2S_A_DATA_IN", "I2S_B_DATA_IN",
> +			  "DIO1_IN", "BOOT_SEL0#", "BOOT_SEL1#", "",
> +			  "", "", "I2S_LRCLK", "I2S_BITCLK",
> +			  "I2S_A_DATA_OUT", "I2S_B_DATA_OUT", "DIO2_IN", "DIO3_IN",
> +			  "DIO4_IN", "SPI_A_/WP_(IO2)", "SPI_A_/HOLD_(IO3)", "GPIO_C_6",
> +			  "I2S_MCLK", "UART_A_TX", "UART_A_RX", "UART_A_CTS",
> +			  "UART_A_RTS", "", "", "",
> +			  "PCIe_SM_ALERT", "UART_B_RTS", "UART_B_CTS", "UART_B_RX";
>  };
>  
>  &i2c3 {
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_i2c3>;
>  	status = "okay";
>  
>  	usb-hub at 2c {
> @@ -169,27 +181,28 @@ usb-hub at 2c {
>  	};
>  };
>  
> -&i2c4 {
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_i2c4>;
> -};
> -
>  &pwm2 {
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_pwm2>;
>  	status = "okay";
>  };
>  
> +&reg_usb2_vbus {
> +	status = "disabled";
> +};
> +
> +&reg_usdhc2_vcc {
> +	status = "disabled";
> +};
> +
> +&reg_usdhc3_vcc {
> +	status = "disabled";
> +};
> +
>  &uart1 {
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_uart1>;
>  	uart-has-rtscts;
>  	status = "okay";
>  };
>  
>  &uart2 {
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_uart2>;
>  	linux,rs485-enabled-at-boot-time;
>  	uart-has-rtscts;
>  	status = "okay";
> @@ -197,8 +210,6 @@ &uart2 {
>  
>  &usbotg1 {
>  	dr_mode = "otg";
> -	disable-over-current;
> -	vbus-supply = <&reg_usb1_vbus>;
>  	status = "okay";
>  };
>  
> @@ -209,6 +220,9 @@ &usbotg2 {
>  	#size-cells = <0>;
>  	status = "okay";
>  
> +	/* VBUS is controlled by the hub */
> +	/delete-property/ vbus-supply;
> +
>  	usb1 at 1 {
>  		compatible = "usb424,2514";
>  		reg = <1>;
> @@ -224,171 +238,20 @@ usbnet: ethernet at 1 {
>  };
>  
>  &usdhc2 {
> -	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> -	pinctrl-0 = <&pinctrl_usdhc2>;
> -	pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
> -	pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
>  	vmmc-supply = <&reg_vdd_3v3>;
> -	vqmmc-supply = <&reg_nvcc_sd>;
> -	cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
>  	status = "okay";
>  };
>  
>  &iomuxc {
>  	pinctrl_can: cangrp {
>  		fsl,pins = <
> -			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19
> -		>;
> -	};
> -
> -	pinctrl_ecspi2: ecspi2grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO		0x82
> -			MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI		0x82
> -			MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK		0x82
> -			MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13		0x19
> -		>;
> -	};
> -
> -	pinctrl_ecspi3: ecspi3grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO		0x82
> -			MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI		0x82
> -			MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK		0x82
> -			MX8MM_IOMUXC_UART2_TXD_GPIO5_IO25		0x19
> -		>;
> -	};
> -
> -	pinctrl_enet: enetgrp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x3
> -			MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO		0x3
> -			MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3		0x1f
> -			MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2		0x1f
> -			MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1		0x1f
> -			MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0		0x1f
> -			MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3		0x91
> -			MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2		0x91
> -			MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1		0x91
> -			MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0		0x91
> -			MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC		0x1f
> -			MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC		0x91
> -			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x91
> -			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x1f
> -			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x19 /* PHY RST */
> -		>;
> -	};
> -
> -	pinctrl_gpio_led: gpioledgrp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x19
> -			MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7		0x19
> -			MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8		0x19
> -		>;
> -	};
> -
> -	pinctrl_gpio1: gpio1grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19
> -			MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x19
> -			MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11		0x19
> -			MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6		0x19
> -			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10		0x19
> -		>;
> -	};
> -
> -	pinctrl_gpio5: gpio5grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19
> -		>;
> -	};
> -
> -	pinctrl_i2c3: i2c3grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083
> -			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083
> -		>;
> -	};
> -
> -	pinctrl_i2c4: i2c4grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x40000083
> -			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x40000083
> -		>;
> -	};
> -
> -	pinctrl_pwm2: pwm2grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT			0x19
> -		>;
> -	};
> -
> -	pinctrl_reg_usb1_vbus: regusb1vbusgrp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19
> -		>;
> -	};
> -
> -	pinctrl_uart1: uart1grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x0
> -			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x0
> -			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x0
> -			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x0
> -		>;
> -	};
> -
> -	pinctrl_uart2: uart2grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x0
> -			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x0
> -			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x0
> -			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x0
> -		>;
> -	};
> -
> -	pinctrl_usb_eth2: usbeth2grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19
> -		>;
> -	};
> -
> -	pinctrl_usdhc2: usdhc2grp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x90
> -			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d0
> -			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d0
> -			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0
> -			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0
> -			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0
> -			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
> -			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
> -		>;
> -	};
> -
> -	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
> -		fsl,pins = <
> -			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x94
> -			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d4
> -			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d4
> -			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4
> -			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4
> -			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4
> -			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
> -			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
> +			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19  /* SDIO_B_PWR_EN */
>  		>;
>  	};
>  
> -	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
> +	pinctrl_usb_hub: usbhubgrp {
>  		fsl,pins = <
> -			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x96
> -			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d6
> -			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d6
> -			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6
> -			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6
> -			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6
> -			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
> -			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
> +			MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19 /* SDIO_B_WP */
>  		>;
>  	};
>  };
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
> index 6b9058fc53332..1a5c29565e7fe 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
> @@ -3,6 +3,7 @@
>   * Copyright (C) 2022 Kontron Electronics GmbH
>   */
>  
> +#include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/interrupt-controller/irq.h>
>  #include "imx8mm.dtsi"
>  
> @@ -28,6 +29,73 @@ memory at 40000000 {
>  	chosen {
>  		stdout-path = &uart3;
>  	};
> +
> +	reg_vdd_carrier: regulator-vdd-carrier {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_reg_vdd_carrier>;
> +		enable-active-high;
> +		gpio = <&gpio3 16 GPIO_ACTIVE_HIGH>;

Can we flip the order of these two properties? enable-active-high is a
further description to GPIO_ACTIVE_HIGH.

Shawn

> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-name = "VDD_CARRIER";
> +
> +		regulator-state-standby {
> +			regulator-on-in-suspend;
> +		};
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +
> +		regulator-state-disk {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	reg_usb1_vbus: regulator-usb1-vbus {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_reg_usb1_vbus>;
> +		enable-active-high;
> +		gpio = <&gpio3 25 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-name = "VBUS_USB1";
> +	};
> +
> +	reg_usb2_vbus: regulator-usb2-vbus {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_reg_usb2_vbus>;
> +		enable-active-high;
> +		gpio = <&gpio3 20 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-name = "VBUS_USB2";
> +	};
> +
> +	reg_usdhc2_vcc: regulator-usdhc2-vcc {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_reg_usdhc2_vcc>;
> +		enable-active-high;
> +		gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-name = "VCC_SDIO_A";
> +	};
> +
> +	reg_usdhc3_vcc: regulator-usdhc3-vcc {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_reg_usdhc3_vcc>;
> +		enable-active-high;
> +		gpio = <&gpio5 1 GPIO_ACTIVE_HIGH>;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-name = "VCC_SDIO_B";
> +	};
>  };
>  
>  &A53_0 {
> @@ -96,6 +164,79 @@ partition at 1f0000 {
>  	};
>  };
>  
> +&ecspi2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi2>, <&pinctrl_ecspi2_gpio>;
> +	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
> +};
> +
> +&ecspi3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi3>;
> +	cs-gpios = <&gpio5 25 GPIO_ACTIVE_LOW>;
> +};
> +
> +&gpio1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_gpio1>;
> +	gpio-line-names = "", "GPIO_A_0", "", "GPIO_A_1",
> +			  "", "GPIO_A_2", "GPIO_A_3", "GPIO_A_4",
> +			  "GPIO_A_5", "GPIO_A_6", "GPIO_A_7", "GPIO_B_0",
> +			  "GPIO_B_1", "USB_A_OC#", "CAM_MCK", "USB_B_OC#",
> +			  "ETH_MDC", "ETH_MDIO", "ETH_A_(S)(R)(G)MII_TXD3",
> +			  "ETH_A_(S)(R)(G)MII_TXD2", "ETH_A_(S)(R)(G)MII_TXD1",
> +			  "ETH_A_(S)(R)(G)MII_TXD0", "ETH_A_(R)(G)MII_TX_EN(_ER)",
> +			  "ETH_A_(R)(G)MII_TX_CLK", "ETH_A_(R)(G)MII_RX_DV(_ER)",
> +			  "ETH_A_(R)(G)MII_RX_CLK", "ETH_A_(S)(R)(G)MII_RXD0",
> +			  "ETH_A_(S)(R)(G)MII_RXD1", "ETH_A_(R)(G)MII_RXD2",
> +			  "ETH_A_(R)(G)MII_RXD3";
> +};
> +
> +&gpio2 {
> +	gpio-line-names = "", "", "", "",
> +			  "", "", "", "",
> +			  "", "", "", "",
> +			  "SDIO_A_CD#", "SDIO_A_CLK", "SDIO_A_CMD", "SDIO_A_D0",
> +			  "SDIO_A_D1", "SDIO_A_D2", "SDIO_A_D3", "SDIO_A_PWR_EN",
> +			  "SDIO_A_WP";
> +};
> +
> +&gpio3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_gpio3>;
> +	gpio-line-names = "GPIO_C_5", "GPIO_C_4", "SDIO_B_CD#", "SDIO_B_D5",
> +			  "SDIO_B_D6", "SDIO_B_D7", "GPIO_C_0", "GPIO_C_1",
> +			  "GPIO_C_2", "GPIO_C_3", "SDIO_B_D0", "SDIO_B_D1",
> +			  "SDIO_B_D2", "SDIO_B_D3", "", "SDIO_B_D4",
> +			  "CARRIER_PWR_EN", "SDIO_B_CLK", "SDIO_B_CMD", "GPIO_B_2",
> +			  "USB_B_EN", "GPIO_B_3", "PCIe_CLKREQ#", "PCIe_A_PERST#",
> +			  "PCIe_WAKE#", "USB_A_EN";
> +};
> +
> +&gpio4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_gpio4>;
> +	gpio-line-names = "GPIO_C_7", "", "I2S_A_DATA_IN", "I2S_B_DATA_IN",
> +			  "GPIO_B_4", "BOOT_SEL0#", "BOOT_SEL1#", "",
> +			  "", "", "I2S_LRCLK", "I2S_BITCLK",
> +			  "I2S_A_DATA_OUT", "I2S_B_DATA_OUT", "GPIO_B_5", "GPIO_B_6",
> +			  "GPIO_B_7", "SPI_A_/WP_(IO2)", "SPI_A_/HOLD_(IO3)", "GPIO_C_6",
> +			  "I2S_MCLK", "UART_A_TX", "UART_A_RX", "UART_A_CTS",
> +			  "UART_A_RTS", "", "", "",
> +			  "PCIe_SM_ALERT", "UART_B_RTS", "UART_B_CTS", "UART_B_RX";
> +};
> +
> +&gpio5 {
> +	gpio-line-names = "UART_B_TX", "SDIO_B_PWR_EN", "SDIO_B_WP", "PWM_2",
> +			  "PWM_1", "PWM_0", "", "",
> +			  "", "", "SPI_A_SCK", "SPI_A_SDO_(IO1)",
> +			  "SPI_A_SCK", "SPI_A_CS0#", "", "",
> +			  "I2C_A_SCL", "I2C_A_SDA", "I2C_B_SCL", "I2C_B_SDA",
> +			  "PCIe_SMCLK", "PCIe_SMDAT", "SPI_B_SCK", "SPI_B_SDO",
> +			  "SPI_B_SDI", "SPI_B_CS0#", "UART_CON_RX", "UART_CON_TX",
> +			  "UART_C_RX", "UART_C_TX";
> +};
> +
>  &i2c1 {
>  	clock-frequency = <400000>;
>  	pinctrl-names = "default";
> @@ -222,12 +363,69 @@ rv3028: rtc at 52 {
>  	};
>  };
>  
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +};
> +
> +&i2c3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c3>;
> +};
> +
> +&i2c4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c4>;
> +};
> +
> +&pwm1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm1>;
> +};
> +
> +&pwm2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm2>;
> +};
> +
> +&pwm3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm3>;
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1>;
> +};
> +
> +&uart2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart2>;
> +};
> +
>  &uart3 { /* console */
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_uart3>;
>  	status = "okay";
>  };
>  
> +&uart4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart4>;
> +};
> +
> +&usbotg1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usb1>;
> +	vbus-supply = <&reg_usb1_vbus>;
> +};
> +
> +&usbotg2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usb2>;
> +	vbus-supply = <&reg_usb2_vbus>;
> +};
> +
>  &usdhc1 {
>  	pinctrl-names = "default", "state_100mhz", "state_200mhz";
>  	pinctrl-0 = <&pinctrl_usdhc1>;
> @@ -240,6 +438,26 @@ &usdhc1 {
>  	status = "okay";
>  };
>  
> +&usdhc2 {
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> +	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> +	vmmc-supply = <&reg_usdhc2_vcc>;
> +	vqmmc-supply = <&reg_nvcc_sd>;
> +	cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
> +};
> +
> +&usdhc3 {
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> +	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_gpio>;
> +	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_usdhc3_gpio>;
> +	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_usdhc3_gpio>;
> +	vmmc-supply = <&reg_usdhc3_vcc>;
> +	vqmmc-supply = <&reg_nvcc_sd>;
> +	cd-gpios = <&gpio3 2 GPIO_ACTIVE_LOW>;
> +};
> +
>  &wdog1 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_wdog>;
> @@ -248,6 +466,12 @@ &wdog1 {
>  };
>  
>  &iomuxc {
> +	pinctrl_csi_mck: csimckgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_GPIO1_IO14_CCMSRCGPCMIX_CLKO1	0x59 /* CAM_MCK */
> +		>;
> +	};
> +
>  	pinctrl_ecspi1: ecspi1grp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO		0x82
> @@ -257,6 +481,106 @@ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9		0x19
>  		>;
>  	};
>  
> +	pinctrl_ecspi2: ecspi2grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO		0x82 /* SPI_A_SDI_(IO0) */
> +			MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI		0x82 /* SPI_A_SDO_(IO1) */
> +			MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK		0x82 /* SPI_A_SCK */
> +			MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13		0x19 /* SPI_A_CS0# */
> +		>;
> +	};
> +
> +	pinctrl_ecspi2_gpio: ecspi2gpiogrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI1_TXD5_GPIO4_IO17		0x19 /* SPI_A_/WP_(IO2) */
> +			MX8MM_IOMUXC_SAI1_TXD6_GPIO4_IO18		0x19 /* SPI_A_/HOLD_(IO3) */
> +		>;
> +	};
> +
> +	pinctrl_ecspi3: ecspi3grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO		0x82 /* SPI_B_SDI */
> +			MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI		0x82 /* SPI_B_SDO */
> +			MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK		0x82 /* SPI_B_SCK */
> +			MX8MM_IOMUXC_UART2_TXD_GPIO5_IO25		0x19 /* SPI_B_CS0# */
> +		>;
> +	};
> +
> +	pinctrl_enet_rgmii: enetrgmiigrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x03 /* ETH_MDC */
> +			MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO		0x03 /* ETH_MDIO */
> +			MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3		0x1f /* ETH_A_(S)(R)(G)MII_TXD3 */
> +			MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2		0x1f /* ETH_A_(S)(R)(G)MII_TXD2 */
> +			MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1		0x1f /* ETH_A_(S)(R)(G)MII_TXD1 */
> +			MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0		0x1f /* ETH_A_(S)(R)(G)MII_TXD0 */
> +			MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3		0x91 /* ETH_A_(R)(G)MII_RXD3 */
> +			MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2		0x91 /* ETH_A_(R)(G)MII_RXD2 */
> +			MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1		0x91 /* ETH_A_(S)(R)(G)MII_RXD1 */
> +			MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0		0x91 /* ETH_A_(S)(R)(G)MII_RXD0 */
> +			MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC		0x1f /* ETH_A_(R)(G)MII_TX_CLK */
> +			MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC		0x91 /* ETH_A_(R)(G)MII_RX_CLK */
> +			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x91 /* ETH_A_(R)(G)MII_RX_DV(_ER) */
> +			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x1f /* ETH_A_(R)(G)MII_TX_EN(_ER) */
> +		>;
> +	};
> +
> +	pinctrl_enet_rmii: enetrmiigrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x03 /* ETH_MDC */
> +			MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO		0x03 /* ETH_MDIO */
> +			MX8MM_IOMUXC_ENET_TD2_ENET1_TX_CLK		0x4000001f /* ETH_A_(S)(R)(G)MII_TXD2 */
> +			MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1		0x56 /* ETH_A_(S)(R)(G)MII_TXD1 */
> +			MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0		0x56 /* ETH_A_(S)(R)(G)MII_TXD0 */
> +			MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1		0x56 /* ETH_A_(S)(R)(G)MII_RXD1 */
> +			MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0		0x56 /* ETH_A_(S)(R)(G)MII_RXD0 */
> +			MX8MM_IOMUXC_ENET_RXC_ENET1_RX_ER		0x56 /* ETH_A_(R)(G)MII_RX_CLK */
> +			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x56 /* ETH_A_(R)(G)MII_RX_DV(_ER) */
> +			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x56 /* ETH_A_(R)(G)MII_TX_EN(_ER) */
> +		>;
> +	};
> +
> +	pinctrl_gpio1: gpio1grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19 /* GPIO_A_0 */
> +			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x19 /* GPIO_A_1 */
> +			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x19 /* GPIO_A_2 */
> +			MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6		0x19 /* GPIO_A_3 */
> +			MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7		0x19 /* GPIO_A_4 */
> +			MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8		0x19 /* GPIO_A_5 */
> +			MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x19 /* GPIO_A_6 */
> +			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10		0x19 /* GPIO_A_7 */
> +			MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11		0x19 /* GPIO_B_0 */
> +			MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12		0x19 /* GPIO_B_1 */
> +		>;
> +	};
> +
> +	pinctrl_gpio3: gpio3grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_NAND_ALE_GPIO3_IO0			0x19 /* GPIO_C_5 */
> +			MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1		0x19 /* GPIO_C_4 */
> +			MX8MM_IOMUXC_NAND_DATA00_GPIO3_IO6		0x19 /* GPIO_C_0 */
> +			MX8MM_IOMUXC_NAND_DATA01_GPIO3_IO7		0x19 /* GPIO_C_1 */
> +			MX8MM_IOMUXC_NAND_DATA02_GPIO3_IO8		0x19 /* GPIO_C_2 */
> +			MX8MM_IOMUXC_NAND_DATA03_GPIO3_IO9		0x19 /* GPIO_C_3 */
> +			MX8MM_IOMUXC_SAI5_RXFS_GPIO3_IO19		0x19 /* GPIO_B_2 */
> +			MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21		0x19 /* GPIO_B_3 */
> +		>;
> +	};
> +
> +	pinctrl_gpio4: gpio4grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI1_RXFS_GPIO4_IO0		0x19 /* GPIO_C_7 */
> +			MX8MM_IOMUXC_SAI1_RXD2_GPIO4_IO4		0x19 /* GPIO_B_4 */
> +			MX8MM_IOMUXC_SAI1_RXD3_GPIO4_IO5		0x19 /* BOOT_SEL0# */
> +			MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6		0x19 /* BOOT_SEL1# */
> +			MX8MM_IOMUXC_SAI1_TXD2_GPIO4_IO14		0x19 /* GPIO_B_5 */
> +			MX8MM_IOMUXC_SAI1_TXD3_GPIO4_IO15		0x19 /* GPIO_B_6 */
> +			MX8MM_IOMUXC_SAI1_TXD4_GPIO4_IO16		0x19 /* GPIO_B_7 */
> +			MX8MM_IOMUXC_SAI1_TXD7_GPIO4_IO19		0x19 /* GPIO_C_6 */
> +		>;
> +	};
> +
>  	pinctrl_i2c1: i2c1grp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL			0x40000083
> @@ -264,22 +588,149 @@ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA			0x40000083
>  		>;
>  	};
>  
> +	pinctrl_i2c2: i2c2grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL			0x40000083 /* I2C_A_SCL */
> +			MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA			0x40000083 /* I2C_A_SDA */
> +		>;
> +	};
> +
> +	pinctrl_i2c3: i2c3grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083 /* I2C_B_SCL */
> +			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083 /* I2C_B_SDA */
> +		>;
> +	};
> +
> +	pinctrl_i2c4: i2c4grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x40000083 /* PCIe_SMCLK and I2C_CAM_SCL/CSI_TX_P */
> +			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x40000083 /* PCIe_SMDAT and I2C_CAM_SDA/CSI_TX_N */
> +		>;
> +	};
> +
> +	pinctrl_pcie: pciegrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22		0x19 /* PCIe_CLKREQ# */
> +			MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23		0x19 /* PCIe_A_PERST# */
> +			MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24		0x19 /* PCIe_WAKE# */
> +			MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28		0x19 /* PCIe_SM_ALERT */
> +		>;
> +	};
> +
>  	pinctrl_pmic: pmicgrp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0		0x141
>  		>;
>  	};
>  
> +	pinctrl_pwm1: pwm1grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SPDIF_EXT_CLK_PWM1_OUT		0x19 /* PWM_0 */
> +		>;
> +	};
> +
> +	pinctrl_pwm2: pwm2grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT			0x19 /* PWM_1 */
> +		>;
> +	};
> +
> +	pinctrl_pwm3: pwm3grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SPDIF_TX_PWM3_OUT			0x19 /* PWM_2 */
> +		>;
> +	};
> +
> +	pinctrl_reg_usb1_vbus: regusb1vbusgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19 /* USB_A_EN */
> +		>;
> +	};
> +
> +	pinctrl_reg_usb2_vbus: regusb2vbusgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20		0x19 /* USB_B_EN */
> +		>;
> +	};
> +
> +	pinctrl_reg_usdhc2_vcc: regusdhc2vccgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19		0x19 /* SDIO_A_PWR_EN */
> +		>;
> +	};
> +
> +	pinctrl_reg_usdhc3_vcc: regusdhc3vccgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19 /* SDIO_B_PWR_EN */
> +		>;
> +	};
> +
> +	pinctrl_reg_vdd_carrier: regvddcarriergrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_NAND_READY_B_GPIO3_IO16		0x19 /* CARRIER_PWR_EN */
> +		>;
> +	};
> +
>  	pinctrl_rtc: rtcgrp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_SAI1_RXC_GPIO4_IO1			0x19
>  		>;
>  	};
>  
> +	pinctrl_sai1: sai1grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI1_RXD0_SAI1_RX_DATA0		0xd6 /* I2S_A_DATA_IN */
> +			MX8MM_IOMUXC_SAI1_TXD0_SAI1_TX_DATA0		0xd6 /* I2S_A_DATA_OUT */
> +			MX8MM_IOMUXC_SAI1_RXD1_SAI1_RX_DATA1		0xd6 /* I2S_B_DATA_IN */
> +			MX8MM_IOMUXC_SAI1_TXD1_SAI1_TX_DATA1		0xd6 /* I2S_B_DATA_OUT */
> +			MX8MM_IOMUXC_SAI1_MCLK_SAI1_MCLK		0xd6 /* I2S_MCLK */
> +			MX8MM_IOMUXC_SAI1_TXFS_SAI1_TX_SYNC		0xd6 /* I2S_LRCLK */
> +			MX8MM_IOMUXC_SAI1_TXC_SAI1_TX_BCLK		0xd6 /* I2S_BITCLK */
> +		>;
> +	};
> +
> +	pinctrl_uart1: uart1grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x0 /* UART_A_RX */
> +			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x0 /* UART_A_TX */
> +			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x0 /* UART_A_CTS */
> +			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x0 /* UART_A_RTS */
> +		>;
> +	};
> +
> +	pinctrl_uart2: uart2grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x0 /* UART_B_RX */
> +			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x0 /* UART_B_TX */
> +			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x0 /* UART_B_CTS */
> +			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x0 /* UART_B_RTS */
> +		>;
> +	};
> +
>  	pinctrl_uart3: uart3grp {
>  		fsl,pins = <
> -			MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX		0x140
> -			MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX		0x140
> +			MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX		0x140 /* UART_CON_RX */
> +			MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX		0x140 /* UART_CON_TX */
> +		>;
> +	};
> +
> +	pinctrl_uart4: uart4grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX		0x0 /* UART_C_RX */
> +			MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX		0x0 /* UART_C_TX */
> +		>;
> +	};
> +
> +	pinctrl_usb1: usb1grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_GPIO1_IO13_USB1_OTG_OC		0x19 /* USB_A_OC# */
> +		>;
> +	};
> +
> +	pinctrl_usb2: usb2grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_GPIO1_IO15_USB2_OTG_OC		0x19 /* USB_B_OC# */
>  		>;
>  	};
>  
> @@ -334,6 +785,103 @@ MX8MM_IOMUXC_SD1_STROBE_USDHC1_STROBE		0x196
>  		>;
>  	};
>  
> +	pinctrl_usdhc2: usdhc2grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x90 /* SDIO_A_CLK */
> +			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d0 /* SDIO_A_CMD */
> +			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d0 /* SDIO_A_D0 */
> +			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0 /* SDIO_A_D1 */
> +			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0 /* SDIO_A_D2 */
> +			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0 /* SDIO_A_D3 */
> +			MX8MM_IOMUXC_SD2_WP_USDHC2_WP			0x400000d6 /* SDIO_A_WP */
> +			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
> +		>;
> +	};
> +
> +	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x94 /* SDIO_A_CLK */
> +			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d4 /* SDIO_A_CMD */
> +			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d4 /* SDIO_A_D0 */
> +			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4 /* SDIO_A_D1 */
> +			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4 /* SDIO_A_D2 */
> +			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4 /* SDIO_A_D3 */
> +			MX8MM_IOMUXC_SD2_WP_USDHC2_WP			0x400000d6 /* SDIO_A_WP */
> +			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
> +		>;
> +	};
> +
> +	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x96 /* SDIO_A_CLK */
> +			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d6 /* SDIO_A_CMD */
> +			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d6 /* SDIO_A_D0 */
> +			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6 /* SDIO_A_D1 */
> +			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6 /* SDIO_A_D2 */
> +			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6 /* SDIO_A_D3 */
> +			MX8MM_IOMUXC_SD2_WP_USDHC2_WP			0x400000d6 /* SDIO_A_WP */
> +			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
> +		>;
> +	};
> +
> +	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19 /* SDIO_A_CD# */
> +		>;
> +	};
> +
> +	pinctrl_usdhc3: usdhc3grp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x90 /* SDIO_B_CLK */
> +			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x90 /* SDIO_B_CMD */
> +			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x90 /* SDIO_B_D0 */
> +			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x90 /* SDIO_B_D1 */
> +			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x90 /* SDIO_B_D2 */
> +			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x90 /* SDIO_B_D3 */
> +			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x90 /* SDIO_B_D4 */
> +			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x90 /* SDIO_B_D5 */
> +			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x90 /* SDIO_B_D6 */
> +			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x90 /* SDIO_B_D7 */
> +		>;
> +	};
> +
> +	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x94 /* SDIO_B_CLK */
> +			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x94 /* SDIO_B_CMD */
> +			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x94 /* SDIO_B_D0 */
> +			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x94 /* SDIO_B_D1 */
> +			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x94 /* SDIO_B_D2 */
> +			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x94 /* SDIO_B_D3 */
> +			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x94 /* SDIO_B_D4 */
> +			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x94 /* SDIO_B_D5 */
> +			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x94 /* SDIO_B_D6 */
> +			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x94 /* SDIO_B_D7 */
> +		>;
> +	};
> +
> +	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x96 /* SDIO_B_CLK */
> +			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x96 /* SDIO_B_CMD */
> +			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x96 /* SDIO_B_D0 */
> +			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x96 /* SDIO_B_D1 */
> +			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x96 /* SDIO_B_D2 */
> +			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x96 /* SDIO_B_D3 */
> +			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x96 /* SDIO_B_D4 */
> +			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x96 /* SDIO_B_D5 */
> +			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x96 /* SDIO_B_D6 */
> +			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x96 /* SDIO_B_D7 */
> +		>;
> +	};
> +
> +	pinctrl_usdhc3_gpio: usdhc3gpiogrp {
> +		fsl,pins = <
> +			MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2		0x19 /* SDIO_B_CD# */
> +			MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19 /* SDIO_B_WP */
> +		>;
> +	};
> +
>  	pinctrl_wdog: wdoggrp {
>  		fsl,pins = <
>  			MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B		0xc6
> -- 
> 2.43.0
> 


From shawnguo at kernel.org  Tue Dec  5 19:07:35 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 11:07:35 +0800
Subject: [PATCH] arm64: dts: imx8mm-venice-gw7: Adjust PCI Ethernet nodes
In-Reply-To: <20231130225242.988336-1-festevam@gmail.com>
References: <20231130225242.988336-1-festevam@gmail.com>
Message-ID: <20231206030735.GO236001@dragon>

On Thu, Nov 30, 2023 at 07:52:42PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> As per Rob Herring's feedback:
> 
> "The ethernet device should have a node name of
> 'ethernet'. The 'pcie' node name and 'device_type = "pci"' is for PCI
> buses/bridges only."
> 
> Do it as suggested.
> 
> Fixes: d61c5068729a ("arm64: dts: imx8mm-venice-gw7: Fix pci sub-nodes")
> Suggested-by: Rob Herring <robh at kernel.org>
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 19:09:26 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 11:09:26 +0800
Subject: [PATCH v1 0/2] arm64: dts: freescale: verdin-imx8mm: add support
 to mallow board
In-Reply-To: <20231201150733.24454-1-francesco@dolcini.it>
References: <20231201150733.24454-1-francesco@dolcini.it>
Message-ID: <20231206030926.GP236001@dragon>

On Fri, Dec 01, 2023 at 04:07:31PM +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> Add Toradex Verdin IMX8MM Mallow carrier board support. Mallow is a
> low-cost carrier board in the Verdin family with a small form factor and
> build for volume production making it ideal for industrial and embedded
> applications.
> 
> https://www.toradex.com/products/carrier-board/mallow-carrier-board
> 
> Joao Paulo Goncalves (2):
>   dt-bindings: arm: fsl: add verdin imx8mm mallow board
>   arm64: dts: freescale: verdin-imx8mm: add support to mallow board

Applied both, thanks!


From gregkh at linuxfoundation.org  Tue Dec  5 19:14:05 2023
From: gregkh at linuxfoundation.org (Greg KH)
Date: Wed, 6 Dec 2023 12:14:05 +0900
Subject: [GIT PULL] coresight: Fixes for v6.7-rc1
In-Reply-To: <20231116170119.1786378-1-suzuki.poulose@arm.com>
References: <20231116170119.1786378-1-suzuki.poulose@arm.com>
Message-ID: <2023120656-king-starting-3fe9@gregkh>

On Thu, Nov 16, 2023 at 05:01:19PM +0000, Suzuki K Poulose wrote:
> Hi Greg
> 
> Please find fixes for hwtracing/coresight subsystem, targetting  Linux v6.7.

Sorry for the delay, now pulled and pushed out.

greg k-h


From shawnguo at kernel.org  Tue Dec  5 19:15:18 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 11:15:18 +0800
Subject: [PATCH v2 0/2] arm64: dts: freescale: verdin-imx8mp: add support
 to mallow board
In-Reply-To: <20231201153929.26590-1-francesco@dolcini.it>
References: <20231201153929.26590-1-francesco@dolcini.it>
Message-ID: <20231206031518.GQ236001@dragon>

On Fri, Dec 01, 2023 at 04:39:27PM +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> Add Toradex Verdin IMX8MP Mallow carrier board support. Mallow is a
> low-cost carrier board in the Verdin family with a small form factor and
> build for volume production making it ideal for industrial and embedded
> applications.
> 
> https://www.toradex.com/products/carrier-board/mallow-carrier-board
> 
> v1:
>  - https://lore.kernel.org/all/20231129164022.143340-1-francesco at dolcini.it/
> v2:
>  - remove dt nodes: eeprom_display_adapter, hwmon
>  - add Acked-by: Krzysztof
>  - correct hwmon_temp node compatible to "ti,tmp1075"
> 
> Joao Paulo Goncalves (2):
>   dt-bindings: arm: fsl: add verdin imx8mp mallow board
>   arm64: dts: freescale: verdin-imx8mp: add support to mallow board

Ok, applied this version instead.

It would be helpful if you drop a note on the previous version when you
discard it with a new one.

Shawn


From shawnguo at kernel.org  Tue Dec  5 19:16:16 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 11:16:16 +0800
Subject: [PATCH v3 2/5] arm64: dts: imx8mq-phanbell: make dts use
 gpio-fan matrix instead of array
In-Reply-To: <20231202222934.137191-2-david@ixit.cz>
References: <20231202222934.137191-1-david@ixit.cz>
 <20231202222934.137191-2-david@ixit.cz>
Message-ID: <20231206031616.GR236001@dragon>

On Sat, Dec 02, 2023 at 11:29:01PM +0100, David Heidelberg wrote:
> No functional changes.
> 
> Adjust to comply with dt-schema requirements
> and make possible to validate values.
> 
> Signed-off-by: David Heidelberg <david at ixit.cz>

Applied, thanks!


From peterlin at andestech.com  Tue Dec  5 19:14:08 2023
From: peterlin at andestech.com (Yu-Chien Peter Lin)
Date: Wed, 6 Dec 2023 11:14:08 +0800
Subject: [PATCH v4 09/13] dt-bindings: riscv: Add T-Head PMU extension
 description
In-Reply-To: <IA1PR20MB4953460FE5BF431DD32CD860BB81A@IA1PR20MB4953.namprd20.prod.outlook.com>
References: <ZWhT_VSpl2aksVK7@APC323>
 <IA1PR20MB4953460FE5BF431DD32CD860BB81A@IA1PR20MB4953.namprd20.prod.outlook.com>
Message-ID: <ZW_nAMRDWoMo6t8r@APC323>

On Fri, Dec 01, 2023 at 09:14:00AM +0800, Inochi Amaoto wrote:
<...>
> >>
> >> Hi, Peter Lin:
> >>
> >> You can use the following two document to get all events:
> >> https://github.com/T-head-Semi/openc906/tree/main/doc
> >> https://github.com/T-head-Semi/openc910/tree/main/doc
> >>
> >> There are also some RTL code can describe these events:
> >> https://github.com/T-head-Semi/openc910/blob/e0c4ad8ec7f8c70f649d826ebd6c949086453272/C910_RTL_FACTORY/gen_rtl/pmu/rtl/ct_hpcp_top.v#L1123
> >> https://github.com/T-head-Semi/openc906/blob/af5614d72de7e5a4b8609c427d2e20af1deb21c4/C906_RTL_FACTORY/gen_rtl/pmu/rtl/aq_hpcp_top.v#L543
> >>
> >> The perf events json can also be used as document, this is already
> >> applied (with more detailed explanation):
> >> https://lore.kernel.org/all/IA1PR20MB495325FCF603BAA841E29281BBBAA at IA1PR20MB4953.namprd20.prod.outlook.com/
> >
> >Thanks for reaching out!
> >The updated description will be:
> >
> >- const: xtheadpmu
> >  description:
> >    The T-Head performance monitor extension for counter overflow, as ratified
> >    in commit bd9206 ("Initial commit") of Xuantie C906 user manual.
> >    https://github.com/T-head-Semi/openc906/tree/main/doc
> >
> >Is it OK with you?
> >
> 
> Please indicate chapter 12 and chapter 13.5 of the manual related to
> the PMU. And changed openc906 manual to openc910 manual because it is
> more updated.
> 
> If modified:
> 
> Reviewed-by: Inochi Amaoto <inochiama at outlook.com>

Got it! Thanks for the information.

Regards,
Peter Lin


From shawnguo at kernel.org  Tue Dec  5 19:18:12 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 11:18:12 +0800
Subject: [PATCH] ARM: dts: imx28-tx28: Pass #sound-dai-cells
In-Reply-To: <20231205145335.2055549-1-festevam@gmail.com>
References: <20231205145335.2055549-1-festevam@gmail.com>
Message-ID: <20231206031812.GS236001@dragon>

On Tue, Dec 05, 2023 at 11:53:35AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per sgtl5000.yaml, '#sound-dai-cells' is a required property.
> 
> Pass it to fix the following dt-schema warning:
> 
> imx28-tx28.dtb: sgtl5000 at a: '#sound-dai-cells' is a required property
> 	from schema $id: http://devicetree.org/schemas/sound/sgtl5000.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 19:19:42 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 11:19:42 +0800
Subject: [PATCH] ARM: dts: imx28-lwe: Pass device_type to the memory node
In-Reply-To: <20231205131838.2013872-1-festevam@gmail.com>
References: <20231205131838.2013872-1-festevam@gmail.com>
Message-ID: <20231206031942.GA270430@dragon>

On Tue, Dec 05, 2023 at 10:18:38AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per memory.yaml, 'device_type' is a required property.
> 
> Pass it to fix the following dt-schema warning:
> 
> imx28-xea.dtb: /: memory at 40000000: 'device_type' is a required property
> 	from schema $id: http://devicetree.org/schemas/memory.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 19:20:16 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 11:20:16 +0800
Subject: [PATCH] ARM: dts: imx28-xea: Pass the 'model' property
In-Reply-To: <20231205132735.2016022-1-festevam@gmail.com>
References: <20231205132735.2016022-1-festevam@gmail.com>
Message-ID: <20231206032016.GB270430@dragon>

On Tue, Dec 05, 2023 at 10:27:35AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per root-node.yaml, 'model' is a required property.
> 
> Pass it to fix the following dt-schema warning:
> 
> imx28-xea.dtb: /: 'model' is a required property
> 	from schema $id: http://devicetree.org/schemas/root-node.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Tue Dec  5 19:22:26 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 11:22:26 +0800
Subject: [PATCH 1/2] ARM: mxs: Do not search for "fsl,clkctrl"
In-Reply-To: <20231205144713.2053916-1-festevam@gmail.com>
References: <20231205144713.2053916-1-festevam@gmail.com>
Message-ID: <20231206032226.GC270430@dragon>

On Tue, Dec 05, 2023 at 11:47:12AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> The "fsl,clkctrl" compatible string is not documented.
> 
> It is used only to find the base address of the clock controller.
> 
> Instead of searching for an undocumented compatible string, search
> for "fsl,imx23-clkctrl" and "fsl,imx28-clkctrl".
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied both, thanks!


From robh at kernel.org  Tue Dec  5 19:39:36 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 05 Dec 2023 21:39:36 -0600
Subject: [RFC PATCH v2 1/8] dt-bindings: phy: mediatek,xfi-pextp: add
 new bindings
In-Reply-To: <f57cc2bfadca35219707a0af507ad6e2e354e311.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <f57cc2bfadca35219707a0af507ad6e2e354e311.1701826319.git.daniel@makrotopia.org>
Message-ID: <170183397288.462976.3952343134089704927.robh@kernel.org>


On Wed, 06 Dec 2023 01:43:55 +0000, Daniel Golle wrote:
> Add bindings for the MediaTek PEXTP Ethernet SerDes PHY found in the
> MediaTek MT7988 SoC which can operate at various interfaces modes:
> 
>  * USXGMII
>  * 10GBase-R
>  * 5GBase-R
>  * 2500Base-X
>  * 1000Base-X
>  * Cisco SGMII (MAC side)
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../bindings/phy/mediatek,xfi-pextp.yaml      | 80 +++++++++++++++++++
>  1 file changed, 80 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml:33:16: [error] string value is redundantly quoted with any quotes (quoted-strings)
./Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml:34:16: [error] string value is redundantly quoted with any quotes (quoted-strings)

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.example.dts:18:18: fatal error: dt-bindings/clock/mediatek,mt7988-clk.h: No such file or directory
   18 |         #include <dt-bindings/clock/mediatek,mt7988-clk.h>
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: dt_binding_check] Error 2
make: *** [Makefile:234: __sub-make] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/f57cc2bfadca35219707a0af507ad6e2e354e311.1701826319.git.daniel at makrotopia.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From robh at kernel.org  Tue Dec  5 19:39:36 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 05 Dec 2023 21:39:36 -0600
Subject: [RFC PATCH v2 7/8] dt-bindings: net: mediatek,net: fix and
 complete mt7988-eth binding
In-Reply-To: <567c6aaa64ecb4872056bc0105c70153fd9d9b50.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <567c6aaa64ecb4872056bc0105c70153fd9d9b50.1701826319.git.daniel@makrotopia.org>
Message-ID: <170183397601.463117.12810951410156171210.robh@kernel.org>


On Wed, 06 Dec 2023 01:45:02 +0000, Daniel Golle wrote:
> Complete support for MT7988 which comes with 3 MACs, SRAM for DMA
> descriptors and uses a dedicated PCS for the SerDes units.
> 
> Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../devicetree/bindings/net/mediatek,net.yaml | 148 +++++++++++++++++-
>  1 file changed, 146 insertions(+), 2 deletions(-)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/net/mediatek,net.example.dts:231:18: fatal error: dt-bindings/clock/mediatek,mt7988-clk.h: No such file or directory
  231 |         #include <dt-bindings/clock/mediatek,mt7988-clk.h>
make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/net/mediatek,net.example.dtb] Error 1

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/567c6aaa64ecb4872056bc0105c70153fd9d9b50.1701826319.git.daniel at makrotopia.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From robh at kernel.org  Tue Dec  5 19:39:36 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 05 Dec 2023 21:39:36 -0600
Subject: [RFC PATCH v2 5/8] net: pcs: add driver for MediaTek USXGMII
 PCS
In-Reply-To: <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
Message-ID: <170183397446.463049.17564721561503446292.robh@kernel.org>


On Wed, 06 Dec 2023 01:44:38 +0000, Daniel Golle wrote:
> Add driver for USXGMII PCS found in the MediaTek MT7988 SoC and supporting
> USXGMII, 10GBase-R and 5GBase-R interface modes. In order to support
> Cisco SGMII, 1000Base-X and 2500Base-X via the also present LynxI PCS
> create a wrapped PCS taking care of the components shared between the
> new USXGMII PCS and the legacy LynxI PCS.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../bindings/net/pcs/mediatek,usxgmii.yaml    |  46 +-
>  MAINTAINERS                                   |   2 +
>  drivers/net/pcs/Kconfig                       |  11 +
>  drivers/net/pcs/Makefile                      |   1 +
>  drivers/net/pcs/pcs-mtk-usxgmii.c             | 413 ++++++++++++++++++
>  include/linux/pcs/pcs-mtk-usxgmii.h           |  26 ++
>  6 files changed, 456 insertions(+), 43 deletions(-)
>  create mode 100644 drivers/net/pcs/pcs-mtk-usxgmii.c
>  create mode 100644 include/linux/pcs/pcs-mtk-usxgmii.h
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:


doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel at makrotopia.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From robh at kernel.org  Tue Dec  5 19:39:36 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 05 Dec 2023 21:39:36 -0600
Subject: [RFC PATCH v2 4/8] dt-bindings: net: pcs: add bindings for
 MediaTek USXGMII PCS
In-Reply-To: <14c3eb3022fac2af105950eb161990ecfb17c016.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <14c3eb3022fac2af105950eb161990ecfb17c016.1701826319.git.daniel@makrotopia.org>
Message-ID: <170183397366.463026.10686567364320956476.robh@kernel.org>


On Wed, 06 Dec 2023 01:44:27 +0000, Daniel Golle wrote:
> MediaTek's USXGMII can be found in the MT7988 SoC. We need to access
> it in order to configure and monitor the Ethernet SerDes link in
> USXGMII, 10GBase-R and 5GBase-R mode. By including a wrapped
> legacy 1000Base-X/2500Base-X/Cisco SGMII LynxI PCS as well, those
> interface modes are also available.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../bindings/net/pcs/mediatek,usxgmii.yaml    | 100 ++++++++++++++++++
>  1 file changed, 100 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.example.dts:18:18: fatal error: dt-bindings/clock/mediatek,mt7988-clk.h: No such file or directory
make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.example.dtb] Error 1

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/14c3eb3022fac2af105950eb161990ecfb17c016.1701826319.git.daniel at makrotopia.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From robh at kernel.org  Tue Dec  5 19:39:36 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 05 Dec 2023 21:39:36 -0600
Subject: [RFC PATCH v2 6/8] dt-bindings: net: mediatek: remove wrongly
 added clocks and SerDes
In-Reply-To: <e2214e904cde9a9d64ec1e87ac38560f7ac35a1f.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <e2214e904cde9a9d64ec1e87ac38560f7ac35a1f.1701826319.git.daniel@makrotopia.org>
Message-ID: <170183397527.463082.3332126649962865060.robh@kernel.org>


On Wed, 06 Dec 2023 01:44:51 +0000, Daniel Golle wrote:
> Several clocks as well as both sgmiisys phandles were added by mistake
> to the Ethernet bindings for MT7988.
> 
> This happened because the vendor driver which served as a reference
> uses a high number of syscon phandles to access various parts of the
> SoC which wasn't acceptable upstream. Hence several parts which have
> never previously been supported (such SerDes PHY and USXGMII PCS) have
> been moved to separate drivers which also result in a much more sane
> device tree.
> 
> Quickly align the bindings with the upcoming reality of the drivers
> actually adding full support for this SoC.
> 
> Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../devicetree/bindings/net/mediatek,net.yaml | 32 ++++---------------
>  1 file changed, 7 insertions(+), 25 deletions(-)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.example.dts:18:18: fatal error: dt-bindings/clock/mediatek,mt7988-clk.h: No such file or directory
make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.example.dtb] Error 1

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/e2214e904cde9a9d64ec1e87ac38560f7ac35a1f.1701826319.git.daniel at makrotopia.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From sjg at chromium.org  Tue Dec  5 19:54:41 2023
From: sjg at chromium.org (Simon Glass)
Date: Tue, 5 Dec 2023 20:54:41 -0700
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <92a3e3b4-6f4d-4ca4-947f-db905f328d4c@pengutronix.de>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <92a3e3b4-6f4d-4ca4-947f-db905f328d4c@pengutronix.de>
Message-ID: <CAPnjgZ3QZh3+2PtmSvje=KAw1n1o_jmhgC1ZnhM9JBoEjLG+fQ@mail.gmail.com>

Hi Ahmad,

On Tue, 5 Dec 2023 at 04:48, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
>
> Hello Simon,
>
> On 02.12.23 04:54, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> >
> > The files compress from about 86MB to 24MB using this approach.
> >
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> >
> > Add a 'make image.fit' build target for arm64, as well. Use
> > FIT_COMPRESSION to select a different algorithm.
> >
> > The FIT can be examined using 'dumpimage -l'.
> >
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> >
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
>
> kernel_noload support is now in barebox next branch and I tested this
> series against it:
>
> Tested-by: Ahmad Fatoum <a.fatoum at pengutronix.de> # barebox
>

OK great thank you.

> > +"""Build a FIT containing a lot of devicetree files
> > +
> > +Usage:
> > +    make_fit.py -A arm64 -n 'Linux-6.6' -O linux
> > +        -f arch/arm64/boot/image.fit -k /tmp/kern/arch/arm64/boot/image.itk
> > +        /tmp/kern/arch/arm64/boot/dts/ -E -c gzip
> > +
> > +Creates a FIT containing the supplied kernel and a directory containing the
> > +devicetree files.
> > +
> > +Use -E to generate an external FIT (where the data is placed after the
> > +FIT data structure). This allows parsing of the data without loading
> > +the entire FIT.
> > +
> > +Use -c to compress the data, using bzip2, gzip, lz4, lzma, lzo and
> > +zstd algorithms.
> > +
> > +The resulting FIT can be booted by bootloaders which support FIT, such
> > +as U-Boot, Linuxboot, Tianocore, etc.
>
> Feel free to add barebox to the list. Did you check whether Linuxboot and
> Tianocore support kernel_noload?

Only what I was told by people in those projects. They may not even
look at the load address, but I am not an expert on that.

>
> > +        fsw.property_u32('load', 0)
> > +        fsw.property_u32('entry', 0)
>
> I still think load and entry dummy values are confusing and should be dropped.

This is what the spec requires at present. But I agree we should
change it. I will dig into that at some point to see what is needed.

>
> > +    with fsw.add_node(f'fdt-{seq}'):
> > +        # Get the compatible / model information
> > +        with open(fname, 'rb') as inf:
> > +            data = inf.read()
> > +        fdt = libfdt.FdtRo(data)
> > +        model = fdt.getprop(0, 'model').as_str()
> > +        compat = fdt.getprop(0, 'compatible')
> > +
> > +        fsw.property_string('description', model)
> > +        fsw.property_string('type', 'flat_dt')
> > +        fsw.property_string('arch', arch)
> > +        fsw.property_string('compression', compress)
> > +        fsw.property('compatible', bytes(compat))
> > +
> > +        with open(fname, 'rb') as inf:
> > +            compressed = compress_data(inf, compress)
> > +        fsw.property('data', compressed)
> > +    return model, compat
>
> After Doug's elaboration, extracting multiple compatibles is fine by me.

OK good.

Regards,
Simon


From patchwork-bot+netdevbpf at kernel.org  Tue Dec  5 20:00:26 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 06 Dec 2023 04:00:26 +0000
Subject: [PATCH net-next v2 0/9] net*: Convert to platform remove callback
 returning void
In-Reply-To: <cover.1701713943.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701713943.git.u.kleine-koenig@pengutronix.de>
Message-ID: <170183522618.32207.8967841669098706210.git-patchwork-notify@kernel.org>

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba at kernel.org>:

On Mon,  4 Dec 2023 19:30:40 +0100 you wrote:
> Hello,
> 
> (implicit) v1 of this series can be found at
> https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koenig at pengutronix.de.
> Changes since then:
> 
>  - Dropped patch #1 as Alex objected. Patch #1 (was #2 before) now
>    converts ipa to remove_new() and introduces an error message in the
>    error path that failed before.
> 
> [...]

Here is the summary with links:
  - [net-next,v2,1/9] net: ipa: Convert to platform remove callback returning void
    https://git.kernel.org/netdev/net-next/c/a92dbb9cdf04
  - [net-next,v2,2/9] net: fjes: Convert to platform remove callback returning void
    https://git.kernel.org/netdev/net-next/c/2ce19934a4dc
  - [net-next,v2,3/9] net: pcs: rzn1-miic: Convert to platform remove callback returning void
    https://git.kernel.org/netdev/net-next/c/e36dc85c245f
  - [net-next,v2,4/9] net: sfp: Convert to platform remove callback returning void
    https://git.kernel.org/netdev/net-next/c/bb1afee98466
  - [net-next,v2,5/9] net: wan/fsl_ucc_hdlc: Convert to platform remove callback returning void
    https://git.kernel.org/netdev/net-next/c/2d0c06fd39be
  - [net-next,v2,6/9] net: wan/ixp4xx_hss: Convert to platform remove callback returning void
    https://git.kernel.org/netdev/net-next/c/2d8590858753
  - [net-next,v2,7/9] net: wwan: qcom_bam_dmux: Convert to platform remove callback returning void
    https://git.kernel.org/netdev/net-next/c/a06041e2f4ae
  - [net-next,v2,8/9] ieee802154: fakelb: Convert to platform remove callback returning void
    (no matching commit)
  - [net-next,v2,9/9] ieee802154: hwsim: Convert to platform remove callback returning void
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From lkp at intel.com  Tue Dec  5 20:11:06 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 06 Dec 2023 12:11:06 +0800
Subject: [linux-next:master] BUILD REGRESSION
 0f5f12ac05f36f117e793656c3f560625e927f1b
Message-ID: <202312061258.nAVYPFq2-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 0f5f12ac05f36f117e793656c3f560625e927f1b  Add linux-next specific files for 20231205

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202312051416.YiRWCYmp-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312051418.JkBRBDyP-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312051419.DsbnPGym-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312051913.e5iif8Qz-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312051935.IXiYU8Kn-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312052245.yFpBSgNH-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312060025.BdeqZrWx-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312060311.Tnsv2fl2-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312060355.M0eJtq4X-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312061137.QgjJ4nTc-lkp at intel.com

Error/Warning: (recently discovered and may have been fixed)

aarch64-linux-ld: qcom_stats.c:(.text+0x470): undefined reference to `qmp_send'
arch/mips/kernel/crash.c:96:6: warning: no previous prototype for 'default_machine_crash_shutdown' [-Wmissing-prototypes]
arch/mips/kernel/machine_kexec.c:161:6: warning: no previous prototype for 'kexec_nonboot_cpu_jump' [-Wmissing-prototypes]
arch/mips/kernel/machine_kexec.c:170:6: warning: conflicting types for 'kexec_reboot'; have 'void(void)'
arch/mips/kernel/machine_kexec.c:170:6: warning: no previous prototype for 'kexec_reboot' [-Wmissing-prototypes]
arch/mips/kernel/machine_kexec.c:77:17: error: 'kexec_args' undeclared (first use in this function)
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:1671:9: sparse:    struct dma_fence *
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:1671:9: sparse:    struct dma_fence [noderef] __rcu *
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:2765:36: sparse:    struct dma_fence *
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:2765:36: sparse:    struct dma_fence [noderef] __rcu *
drivers/leds/leds-sun50i-a100.c:309:12: error: call to __compiletime_assert_280 declared with 'error' attribute: FIELD_PREP: value too large for the field
drivers/media/i2c/saa6752hs.c:598:18: error: implicit declaration of function 'v4l2_subdev_state_get_format' [-Werror=implicit-function-declaration]
qcom_stats.c:(.text+0x33c): undefined reference to `qmp_send'
qcom_stats.c:(.text+0x398): undefined reference to `__aeabi_uldivmod'
qcom_stats.c:(.text+0x6c4): undefined reference to `__udivdi3'
qcom_stats.c:(.text+0x8a0): undefined reference to `qmp_get'
qcom_stats.c:(.text.qcom_ddr_stats_show+0x14c): undefined reference to `__udivdi3'

Unverified Error/Warning (likely false positive, please contact us if interested):

drivers/gpu/drm/i915/display/intel_fbdev_fb.c:111 intel_fbdev_fb_fill_info() error: uninitialized symbol 'vaddr'.

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-randconfig-r013-20211213
|   |-- (.init.text):undefined-reference-to-__auxiliary_driver_register
|   |-- (.text):undefined-reference-to-auxiliary_device_init
|   |-- alpha-linux-ld:(.init.text):undefined-reference-to-__auxiliary_driver_register
|   |-- alpha-linux-ld:(.text):undefined-reference-to-__auxiliary_device_add
|   `-- alpha-linux-ld:(.text):undefined-reference-to-auxiliary_device_init
|-- arc-randconfig-c031-20221114
|   `-- drivers-media-i2c-saa6752hs.c:error:implicit-declaration-of-function-v4l2_subdev_state_get_format
|-- arm-allyesconfig
|   `-- qcom_stats.c:(.text):undefined-reference-to-__aeabi_uldivmod
|-- arm64-randconfig-r034-20230701
|   |-- aarch64-linux-ld:qcom_stats.c:(.text):undefined-reference-to-qmp_send
|   |-- qcom_stats.c:(.text):undefined-reference-to-qmp_get
|   `-- qcom_stats.c:(.text):undefined-reference-to-qmp_send
|-- i386-randconfig-061-20231205
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- i386-randconfig-063-20231205
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- i386-randconfig-141-20231205
|   |-- block-bdev.c-bdev_open_by_dev()-warn:possible-memory-leak-of-handle
|   |-- drivers-gpu-drm-amd-amdgpu-amdgpu_connectors.c-amdgpu_connector_dvi_detect()-warn:inconsistent-indenting
|   |-- drivers-gpu-drm-amd-amdgpu-amdgpu_ras.c-amdgpu_ras_query_error_status_helper()-error:we-previously-assumed-info-could-be-null-(see-line-)
|   |-- drivers-gpu-drm-drm_gpuvm.c-drm_gpuvm_exec_lock_range()-error:uninitialized-symbol-ret-.
|   |-- drivers-hwtracing-stm-core.c-stm_register_device()-error:double-free-of-stm
|   |-- fs-bcachefs-btree_update_interior.c-bch2_btree_update_start()-warn:inconsistent-returns-c-gc_lock-.
|   |-- fs-bcachefs-btree_write_buffer.c-bch2_btree_write_buffer_flush_locked()-error:we-previously-assumed-iter.path-could-be-null-(see-line-)
|   |-- fs-bcachefs-recovery.c-bch2_journal_replay()-error:uninitialized-symbol-ret-.
|   |-- lib-zstd-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-compress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-compress-..-common-bits.h-ZSTD_countLeadingZeros64()-warn:inconsistent-indenting
|   |-- lib-zstd-compress-..-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-compress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting
|   |-- lib-zstd-decompress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-decompress-..-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
|   `-- lib-zstd-decompress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting
|-- mips-allyesconfig
|   `-- qcom_stats.c:(.text.qcom_ddr_stats_show):undefined-reference-to-__udivdi3
|-- mips-randconfig-r006-20221108
|   `-- cache.c:(.text):undefined-reference-to-r3k_cache_init
|-- mips-randconfig-r021-20230305
|   |-- arch-mips-kernel-crash.c:warning:no-previous-prototype-for-default_machine_crash_shutdown
|   |-- arch-mips-kernel-machine_kexec.c:warning:conflicting-types-for-kexec_reboot-have-void(void)
|   |-- arch-mips-kernel-machine_kexec.c:warning:no-previous-prototype-for-kexec_nonboot_cpu_jump
|   `-- arch-mips-kernel-machine_kexec.c:warning:no-previous-prototype-for-kexec_reboot
|-- mips-randconfig-r032-20220731
|   `-- arch-mips-kernel-machine_kexec.c:error:kexec_args-undeclared-(first-use-in-this-function)
|-- mips-randconfig-s051-20220905
|   `-- arch-mips-mm-cache.c:(.text.cpu_cache_init):undefined-reference-to-r3k_cache_init
|-- nios2-randconfig-r112-20231205
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- parisc-randconfig-r133-20231205
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- powerpc-randconfig-003-20231205
|   `-- qcom_stats.c:(.text):undefined-reference-to-__udivdi3
|-- powerpc-randconfig-r111-20231205
|   |-- lib-raid6-altivec4.c:sparse:incomplete-type-static-toplevel-unative_t
|   |-- lib-raid6-altivec4.c:sparse:int-static-signed-toplevel-__preempt_count_sub(-...-)
|   |-- lib-raid6-altivec4.c:sparse:int-static-signed-toplevel-disable_kernel_altivec(-...-)
|   |-- lib-raid6-altivec4.c:sparse:int-static-toplevel-unative_t
|   |-- lib-raid6-altivec8.c:sparse:incomplete-type-static-toplevel-unative_t
|   |-- lib-raid6-altivec8.c:sparse:int-static-signed-toplevel-__preempt_count_sub(-...-)
|   |-- lib-raid6-altivec8.c:sparse:int-static-signed-toplevel-disable_kernel_altivec(-...-)
|   |-- lib-raid6-altivec8.c:sparse:int-static-toplevel-unative_t
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- powerpc-randconfig-r123-20231205
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- powerpc64-randconfig-002-20231205
|   `-- arch-powerpc-include-asm-book3s-pgtable-64k.h:warning:no-return-statement-in-function-returning-non-void
|-- sh-randconfig-r035-20230105
|   `-- standard-input:Error:missing-expression-in-.size-directive
|-- sh-randconfig-r112-20231205
|   `-- include-drm-bridge-aux-bridge.h:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- sparc-allmodconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc-allnoconfig
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-defconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-randconfig-001-20231205
|   `-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|-- sparc-randconfig-r006-20230514
|   `-- parport_pc.c:(.text):undefined-reference-to-ebus_dma_prepare
|-- sparc-randconfig-r036-20230809
|   `-- sparc-linux-ld:arch-sparc-include-asm-parport.h:(.text):undefined-reference-to-ebus_dma_enable
|-- sparc-randconfig-r062-20231205
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-pagecv_flag-set-but-not-used
|-- sparc-randconfig-r121-20231205
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   |-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- sparc-sparc64_defconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-allmodconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-allyesconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-defconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
`-- x86_64-randconfig-161-20231205
    |-- drivers-hwtracing-stm-core.c-stm_register_device()-error:double-free-of-stm
    |-- lib-zstd-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
    |-- lib-zstd-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
    |-- lib-zstd-decompress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
    `-- lib-zstd-decompress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting
clang_recent_errors
|-- arm-randconfig-r133-20231204
|   `-- arch-arm-kernel-machine_kexec.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-const-volatile-noderef-__user-ptr-got-restricted-__be32-usertype
|-- arm64-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- arm64-allyesconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- hexagon-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- hexagon-allyesconfig
|   |-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|   |-- ld.lld:error:vmlinux.a(arch-hexagon-kernel-head.o):(.init.text):relocation-R_HEX_B22_PCREL-out-of-range:is-not-in-references-__vmnewmap
|   |-- ld.lld:error:vmlinux.a(arch-hexagon-kernel-head.o):(.init.text):relocation-R_HEX_B22_PCREL-out-of-range:is-not-in-references-__vmsetvec
|   `-- ld.lld:error:vmlinux.a(arch-hexagon-kernel-head.o):(.init.text):relocation-R_HEX_B22_PCREL-out-of-range:is-not-in-references-memset
|-- hexagon-randconfig-r113-20231205
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- i386-allmodconfig
|   |-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|   `-- fs-bcachefs-replicas.c:error:builtin-functions-must-be-directly-called
|-- i386-allyesconfig
|   |-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|   `-- fs-bcachefs-replicas.c:error:builtin-functions-must-be-directly-called
|-- i386-randconfig-061-20231206
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-opcode-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-owner-got-int
|   `-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-type-got-int
|-- powerpc-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- powerpc-allyesconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- powerpc64-randconfig-r123-20231126
|   `-- drivers-leds-leds-sun50i-a100.c:error:call-to-__compiletime_assert_NNN-declared-with-error-attribute:FIELD_PREP:value-too-large-for-the-field
|-- powerpc64-randconfig-r131-20231205
|   |-- lib-raid6-altivec4.c:sparse:incomplete-type-static-toplevel-unative_t
|   |-- lib-raid6-altivec4.c:sparse:int-static-signed-toplevel-__preempt_count_sub(-...-)
|   |-- lib-raid6-altivec4.c:sparse:int-static-signed-toplevel-disable_kernel_altivec(-...-)
|   |-- lib-raid6-altivec4.c:sparse:int-static-toplevel-unative_t
|   |-- lib-raid6-altivec8.c:sparse:incomplete-type-static-toplevel-unative_t
|   |-- lib-raid6-altivec8.c:sparse:int-static-signed-toplevel-__preempt_count_sub(-...-)
|   |-- lib-raid6-altivec8.c:sparse:int-static-signed-toplevel-disable_kernel_altivec(-...-)
|   |-- lib-raid6-altivec8.c:sparse:int-static-toplevel-unative_t
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- s390-randconfig-001-20231205
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- s390-randconfig-002-20231205
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- x86_64-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- x86_64-allyesconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- x86_64-randconfig-121-20231205
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- x86_64-randconfig-122-20231205
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- x86_64-randconfig-123-20231203
|   |-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_process.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-address-spaces):
|   |-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_process.c:sparse:struct-dma_fence
|   |-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_process.c:sparse:struct-dma_fence-noderef-__rcu
|   |-- drivers-gpu-drm-amd-amdgpu-amdgpu_amdkfd_gpuvm.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-address-spaces):
|   |-- drivers-gpu-drm-amd-amdgpu-amdgpu_amdkfd_gpuvm.c:sparse:struct-dma_fence
|   `-- drivers-gpu-drm-amd-amdgpu-amdgpu_amdkfd_gpuvm.c:sparse:struct-dma_fence-noderef-__rcu
|-- x86_64-randconfig-123-20231205
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- x86_64-randconfig-161-20231206
|   `-- drivers-gpu-drm-i915-display-intel_fbdev_fb.c-intel_fbdev_fb_fill_info()-error:uninitialized-symbol-vaddr-.
`-- x86_64-randconfig-r132-20231205
    `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer

elapsed time: 1453m

configs tested: 177
configs skipped: 3

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                          axs103_defconfig   gcc  
arc                      axs103_smp_defconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231205   gcc  
arc                   randconfig-002-20231205   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                     am200epdkit_defconfig   clang
arm                         axm55xx_defconfig   gcc  
arm                                 defconfig   clang
arm                   randconfig-001-20231205   gcc  
arm                   randconfig-002-20231205   gcc  
arm                   randconfig-003-20231205   gcc  
arm                   randconfig-004-20231205   gcc  
arm                           sunxi_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231205   gcc  
arm64                 randconfig-002-20231205   gcc  
arm64                 randconfig-003-20231205   gcc  
arm64                 randconfig-004-20231205   gcc  
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231205   gcc  
csky                  randconfig-002-20231205   gcc  
hexagon                          allmodconfig   clang
hexagon                           allnoconfig   clang
hexagon                          allyesconfig   clang
hexagon                             defconfig   clang
hexagon               randconfig-001-20231205   clang
hexagon               randconfig-002-20231205   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231205   gcc  
i386         buildonly-randconfig-002-20231205   gcc  
i386         buildonly-randconfig-003-20231205   gcc  
i386         buildonly-randconfig-004-20231205   gcc  
i386         buildonly-randconfig-005-20231205   gcc  
i386         buildonly-randconfig-006-20231205   gcc  
i386                                defconfig   gcc  
i386                  randconfig-001-20231205   gcc  
i386                  randconfig-002-20231205   gcc  
i386                  randconfig-003-20231205   gcc  
i386                  randconfig-004-20231205   gcc  
i386                  randconfig-005-20231205   gcc  
i386                  randconfig-006-20231205   gcc  
i386                  randconfig-011-20231205   clang
i386                  randconfig-012-20231205   clang
i386                  randconfig-013-20231205   clang
i386                  randconfig-014-20231205   clang
i386                  randconfig-015-20231205   clang
i386                  randconfig-016-20231205   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231205   gcc  
loongarch             randconfig-002-20231205   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
mips                           xway_defconfig   gcc  
nios2                            alldefconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231205   gcc  
nios2                 randconfig-002-20231205   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
openrisc                       virt_defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                generic-64bit_defconfig   gcc  
parisc                randconfig-001-20231205   gcc  
parisc                randconfig-002-20231205   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                 canyonlands_defconfig   gcc  
powerpc                      ep88xc_defconfig   gcc  
powerpc                 mpc8315_rdb_defconfig   clang
powerpc               randconfig-001-20231205   gcc  
powerpc               randconfig-002-20231205   gcc  
powerpc               randconfig-003-20231205   gcc  
powerpc64             randconfig-001-20231205   gcc  
powerpc64             randconfig-002-20231205   gcc  
powerpc64             randconfig-003-20231205   gcc  
riscv                            allmodconfig   gcc  
riscv                             allnoconfig   clang
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231205   gcc  
riscv                 randconfig-002-20231205   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231205   clang
s390                  randconfig-002-20231205   clang
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                               j2_defconfig   gcc  
sh                          r7780mp_defconfig   gcc  
sh                    randconfig-001-20231205   gcc  
sh                    randconfig-002-20231205   gcc  
sh                           se7751_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                       sparc64_defconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231205   gcc  
sparc64               randconfig-002-20231205   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231205   gcc  
um                    randconfig-002-20231205   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231205   gcc  
x86_64       buildonly-randconfig-002-20231205   gcc  
x86_64       buildonly-randconfig-003-20231205   gcc  
x86_64       buildonly-randconfig-004-20231205   gcc  
x86_64       buildonly-randconfig-005-20231205   gcc  
x86_64       buildonly-randconfig-006-20231205   gcc  
x86_64                              defconfig   gcc  
x86_64                randconfig-001-20231205   clang
x86_64                randconfig-002-20231205   clang
x86_64                randconfig-003-20231205   clang
x86_64                randconfig-004-20231205   clang
x86_64                randconfig-005-20231205   clang
x86_64                randconfig-006-20231205   clang
x86_64                randconfig-011-20231205   gcc  
x86_64                randconfig-012-20231205   gcc  
x86_64                randconfig-013-20231205   gcc  
x86_64                randconfig-014-20231205   gcc  
x86_64                randconfig-015-20231205   gcc  
x86_64                randconfig-016-20231205   gcc  
x86_64                randconfig-071-20231205   gcc  
x86_64                randconfig-072-20231205   gcc  
x86_64                randconfig-073-20231205   gcc  
x86_64                randconfig-074-20231205   gcc  
x86_64                randconfig-075-20231205   gcc  
x86_64                randconfig-076-20231205   gcc  
x86_64                          rhel-8.3-rust   clang
xtensa                            allnoconfig   gcc  
xtensa                randconfig-002-20231205   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From umang.jain at ideasonboard.com  Tue Dec  5 21:27:59 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Wed, 6 Dec 2023 10:57:59 +0530
Subject: [PATCH v3 1/4] staging: vc04_services: Drop vchiq_log_error() in
 favour of dev_err
In-Reply-To: <d6bf7115-dd15-43a0-b45a-41fc778ff160@gmx.net>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-2-umang.jain@ideasonboard.com>
 <d6bf7115-dd15-43a0-b45a-41fc778ff160@gmx.net>
Message-ID: <6a8566c0-bd26-4ec1-9f7d-d58bbed8411c@ideasonboard.com>

Hi Stefan

On 12/6/23 1:02 AM, Stefan Wahren wrote:
> Hi Umang,
>
> Am 05.12.23 um 09:41 schrieb Umang Jain:
>> Drop vchiq_log_error() macro which wraps dev_dbg(). Introduce the usage
>> of dev_err() directly.
> sorry, i missed to review the last change. So the change won't be that
> trivial.

All the changes you said are valid and I have taken a note of it.

However, I think it would best that if we can address them in a separate 
series on top of this (and I will do it). It would seem to be 
streamlined on top of this.
>>
>> Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
>> ---
>> ? .../interface/vchiq_arm/vchiq_arm.c?????????? |? 50 ++++----
>> ? .../interface/vchiq_arm/vchiq_connected.c???? |?? 6 +-
>> ? .../interface/vchiq_arm/vchiq_core.c????????? | 113 +++++++++---------
>> ? .../interface/vchiq_arm/vchiq_core.h????????? |?? 4 -
>> ? .../interface/vchiq_arm/vchiq_dev.c?????????? |? 45 ++++---
>> ? 5 files changed, 101 insertions(+), 117 deletions(-)
>>
>> diff --git 
>> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
>> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> index 7978fb6dc4fb..b403400edd8e 100644
>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> @@ -683,8 +683,7 @@ int vchiq_initialise(struct vchiq_instance 
>> **instance_out)
>> ????????? usleep_range(500, 600);
>> ????? }
>> ????? if (i == VCHIQ_INIT_RETRIES) {
>> -??????? vchiq_log_error(state->dev, VCHIQ_CORE, "%s: videocore not 
>> initialized\n",
>> -??????????????? __func__);
>> +??????? dev_err(state->dev, "core: %s: Videocore not initialized\n", 
>> __func__);
>> ????????? ret = -ENOTCONN;
>> ????????? goto failed;
>> ????? } else if (i > 0) {
>> @@ -694,8 +693,7 @@ int vchiq_initialise(struct vchiq_instance 
>> **instance_out)
>>
>> ????? instance = kzalloc(sizeof(*instance), GFP_KERNEL);
>> ????? if (!instance) {
>> -??????? vchiq_log_error(state->dev, VCHIQ_CORE,
>> -??????????????? "%s: error allocating vchiq instance\n", __func__);
>> +??????? dev_err(state->dev, "core: %s: Cannot allocate vchiq 
>> instance\n", __func__);
> please drop because kzalloc already report such errors
>> ????????? ret = -ENOMEM;
>> ????????? goto failed;
>> ????? }
>> @@ -967,8 +965,7 @@ vchiq_blocking_bulk_transfer(struct 
>> vchiq_instance *instance, unsigned int handl
>> ????? } else {
>> ????????? waiter = kzalloc(sizeof(*waiter), GFP_KERNEL);
>> ????????? if (!waiter) {
>> -??????????? vchiq_log_error(service->state->dev, VCHIQ_CORE,
>> -??????????????????? "%s - out of memory", __func__);
>> +??????????? dev_err(service->state->dev, "core: %s: - Out of 
>> memory\n", __func__);
> ditto
>> ????????????? return -ENOMEM;
>> ????????? }
>> ????? }
>> @@ -1290,8 +1287,8 @@ vchiq_keepalive_vchiq_callback(struct 
>> vchiq_instance *instance,
>> ???????????????????? struct vchiq_header *header,
>> ???????????????????? unsigned int service_user, void *bulk_user)
>> ? {
>> -??? vchiq_log_error(instance->state->dev, VCHIQ_SUSPEND,
>> -??????????? "%s callback reason %d", __func__, reason);
>> +??? dev_err(instance->state->dev, "suspend: %s: callback reason %d\n",
>> +??????? __func__, reason);
>> ????? return 0;
>> ? }
>>
>> @@ -1315,22 +1312,20 @@ vchiq_keepalive_thread_func(void *v)
>>
>> ????? ret = vchiq_initialise(&instance);
>> ????? if (ret) {
>> -??????? vchiq_log_error(state->dev, VCHIQ_SUSPEND,
>> -??????????????? "%s vchiq_initialise failed %d", __func__, ret);
>> +??????? dev_err(state->dev, "suspend: %s: vchiq_initialise failed 
>> %d\n", __func__, ret);
>> ????????? goto exit;
>> ????? }
>>
>> ????? status = vchiq_connect(instance);
>> ????? if (status) {
>> -??????? vchiq_log_error(state->dev, VCHIQ_SUSPEND,
>> -??????????????? "%s vchiq_connect failed %d", __func__, status);
>> +??????? dev_err(state->dev, "suspend: %s: vchiq_connect failed 
>> %d\n", __func__, status);
>> ????????? goto shutdown;
>> ????? }
>>
>> ????? status = vchiq_add_service(instance, &params, &ka_handle);
>> ????? if (status) {
>> -??????? vchiq_log_error(state->dev, VCHIQ_SUSPEND,
>> -??????????????? "%s vchiq_open_service failed %d", __func__, status);
>> +??????? dev_err(state->dev, "suspend: %s: vchiq_open_service failed 
>> %d\n",
>> +??????????? __func__, status);
>> ????????? goto shutdown;
>> ????? }
>>
>> @@ -1338,8 +1333,7 @@ vchiq_keepalive_thread_func(void *v)
>> ????????? long rc = 0, uc = 0;
>>
>> ????????? if (wait_for_completion_interruptible(&arm_state->ka_evt)) {
>> -??????????? vchiq_log_error(state->dev, VCHIQ_SUSPEND,
>> -??????????????????? "%s interrupted", __func__);
>> +??????????? dev_err(state->dev, "suspend: %s: interrupted\n", 
>> __func__);
> I think this isn't an error and we should use dev_dbg here.
>> ????????????? flush_signals(current);
>> ????????????? continue;
>> ????????? }
>> @@ -1359,16 +1353,15 @@ vchiq_keepalive_thread_func(void *v)
>> ????????????? atomic_inc(&arm_state->ka_use_ack_count);
>> ????????????? status = vchiq_use_service(instance, ka_handle);
>> ????????????? if (status) {
>> -??????????????? vchiq_log_error(state->dev, VCHIQ_SUSPEND,
>> -??????????????????????? "%s vchiq_use_service error %d", __func__, 
>> status);
>> +??????????????? dev_err(state->dev, "suspend: %s: vchiq_use_service 
>> error %d\n",
>> +??????????????????? __func__, status);
>> ????????????? }
>> ????????? }
>> ????????? while (rc--) {
>> ????????????? status = vchiq_release_service(instance, ka_handle);
>> ????????????? if (status) {
>> -??????????????? vchiq_log_error(state->dev, VCHIQ_SUSPEND,
>> -??????????????????????? "%s vchiq_release_service error %d", __func__,
>> -??????????????????????? status);
>> +??????????????? dev_err(state->dev, "suspend: %s: 
>> vchiq_release_service error %d\n",
>> +??????????????????? __func__, status);
>> ????????????? }
>> ????????? }
>> ????? }
>> @@ -1403,7 +1396,7 @@ vchiq_use_internal(struct vchiq_state *state, 
>> struct vchiq_service *service,
>> ?????????????? service->client_id);
>> ????????? entity_uc = &service->service_use_count;
>> ????? } else {
>> -??????? vchiq_log_error(state->dev, VCHIQ_SUSPEND, "%s null service 
>> ptr", __func__);
>> +??????? dev_err(state->dev, "suspend: %s: null service ptr\n", 
>> __func__);
> Instead of dev_err() i would suggest a WARN() here
>> ????????? ret = -EINVAL;
>> ????????? goto out;
>> ????? }
>> @@ -1686,10 +1679,10 @@ vchiq_check_service(struct vchiq_service 
>> *service)
>> ????? read_unlock_bh(&arm_state->susp_res_lock);
>>
>> ????? if (ret) {
>> -??????? vchiq_log_error(service->state->dev, VCHIQ_SUSPEND,
>> -??????????????? "%s ERROR - %p4cc:%d service count %d, state count 
>> %d", __func__,
>> -??????????????? &service->base.fourcc, service->client_id,
>> -??????????????? service->service_use_count, 
>> arm_state->videocore_use_count);
>> +??????? dev_err(service->state->dev,
>> +??????????? "suspend: %s:? %p4cc:%d service count %d, state count 
>> %d\n",
>> +??????????? __func__, &service->base.fourcc, service->client_id,
>> +??????????? service->service_use_count, 
>> arm_state->videocore_use_count);
>> ????????? vchiq_dump_service_use_state(service->state);
>> ????? }
>> ? out:
>> @@ -1722,9 +1715,8 @@ void vchiq_platform_conn_state_changed(struct 
>> vchiq_state *state,
>> ??????????????????????????? (void *)state,
>> ??????????????????????????? threadname);
>> ????? if (IS_ERR(arm_state->ka_thread)) {
>> -??????? vchiq_log_error(state->dev, VCHIQ_SUSPEND,
>> -??????????????? "vchiq: FATAL: couldn't create thread %s",
>> -??????????????? threadname);
>> +??????? dev_err(state->dev, "suspend: Couldn't create thread %s\n",
>> +??????????? threadname);
>> ????? } else {
>> ????????? wake_up_process(arm_state->ka_thread);
>> ????? }
>> diff --git 
>> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c 
>> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
>> index 21f9fa1a1713..3cad13f09e37 100644
>> --- 
>> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
>> +++ 
>> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
>> @@ -39,9 +39,9 @@ void vchiq_add_connected_callback(struct 
>> vchiq_device *device, void (*callback)(
>> ????????? callback();
>> ????? } else {
>> ????????? if (g_num_deferred_callbacks >= MAX_CALLBACKS) {
>> -??????????? vchiq_log_error(&device->dev, VCHIQ_CORE,
>> -??????????????????? "There already %d callback registered - please 
>> increase MAX_CALLBACKS",
>> -??????????????????? g_num_deferred_callbacks);
>> +??????????? dev_err(&device->dev,
>> +??????????????? "core: There already %d callback registered - please 
>> increase MAX_CALLBACKS\n",
>> +??????????????? g_num_deferred_callbacks);
>> ????????? } else {
>> ????????????? g_deferred_callback[g_num_deferred_callbacks] =
>> ????????????????? callback;
>> diff --git 
>> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c 
>> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
>> index e0022acb4c58..63f412815a32 100644
>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
>> @@ -741,10 +741,10 @@ process_free_data_message(struct vchiq_state 
>> *state, u32 *service_found,
>> ?????????? */
>> ????????? complete(&quota->quota_event);
>> ????? } else if (count == 0) {
>> -??????? vchiq_log_error(state->dev, VCHIQ_CORE,
>> -??????????????? "service %d message_use_count=%d (header %pK, msgid 
>> %x, header->msgid %x, header->size %x)",
>> -??????????????? port, quota->message_use_count, header, msgid, 
>> header->msgid,
>> -??????????????? header->size);
>> +??????? dev_err(state->dev,
>> +??????????? "core: service %d message_use_count=%d (header %pK, 
>> msgid %x, header->msgid %x, header->size %x)\n",
>> +??????????? port, quota->message_use_count, header, msgid,
>> +??????????? header->msgid, header->size);
>> ????????? WARN(1, "invalid message use count\n");
>> ????? }
>> ????? if (!BITSET_IS_SET(service_found, port)) {
>> @@ -766,9 +766,9 @@ process_free_data_message(struct vchiq_state 
>> *state, u32 *service_found,
>> ????????????? vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: pfq:%d 
>> %x@%pK - slot_use->%d",
>> ????????????????????? state->id, port, header->size, header, count - 1);
>> ????????? } else {
>> -??????????? vchiq_log_error(state->dev, VCHIQ_CORE,
>> -??????????????????? "service %d slot_use_count=%d (header %pK, msgid 
>> %x, header->msgid %x, header->size %x)",
>> -??????????????????? port, count, header, msgid, header->msgid, 
>> header->size);
>> +??????????? dev_err(state->dev,
>> +??????????????? "core: service %d slot_use_count=%d (header %pK, 
>> msgid %x, header->msgid %x, header->size %x)\n",
>> +??????????????? port, count, header, msgid, header->msgid, 
>> header->size);
>> ????????????? WARN(1, "bad slot use count\n");
>> ????????? }
>> ????? }
>> @@ -831,9 +831,9 @@ process_free_queue(struct vchiq_state *state, u32 
>> *service_found,
>>
>> ????????????? pos += calc_stride(header->size);
>> ????????????? if (pos > VCHIQ_SLOT_SIZE) {
>> -??????????????? vchiq_log_error(state->dev, VCHIQ_CORE,
>> -??????????????????????? "pfq - pos %x: header %pK, msgid %x, 
>> header->msgid %x, header->size %x",
>> -??????????????????????? pos, header, msgid, header->msgid, 
>> header->size);
>> +??????????????? dev_err(state->dev,
>> +??????????????????? "core: pfq - pos %x: header %pK, msgid %x, 
>> header->msgid %x, header->size %x\n",
>> +??????????????????? pos, header, msgid, header->msgid, header->size);
>> ????????????????? WARN(1, "invalid slot position\n");
>> ????????????? }
>> ????????? }
>> @@ -1167,8 +1167,8 @@ queue_message_sync(struct vchiq_state *state, 
>> struct vchiq_service *service,
>> ????????? int oldmsgid = header->msgid;
>>
>> ????????? if (oldmsgid != VCHIQ_MSGID_PADDING)
>> -??????????? vchiq_log_error(state->dev, VCHIQ_CORE, "%d: qms - msgid 
>> %x, not PADDING",
>> -??????????????????? state->id, oldmsgid);
>> +??????????? dev_err(state->dev, "core: %d: qms - msgid %x, not 
>> PADDING\n",
>> +??????????????? state->id, oldmsgid);
>> ????? }
>>
>> ????? vchiq_log_debug(state->dev, VCHIQ_SYNC,
>> @@ -1616,10 +1616,10 @@ parse_message(struct vchiq_state *state, 
>> struct vchiq_header *header)
>> ????????? }
>>
>> ????????? if (!service) {
>> -??????????? vchiq_log_error(state->dev, VCHIQ_CORE,
>> -??????????????????? "%d: prs %s@%pK (%d->%d) - invalid/closed 
>> service %d",
>> -??????????????????? state->id, msg_type_str(type), header, remoteport,
>> -??????????????????? localport, localport);
>> +??????????? dev_err(state->dev,
>> +??????????????? "core: %d: prs %s@%pK (%d->%d) - invalid/closed 
>> service %d\n",
>> +??????????????? state->id, msg_type_str(type), header, remoteport,
>> +??????????????? localport, localport);
>> ????????????? goto skip_message;
>> ????????? }
>> ????????? break;
>> @@ -1640,9 +1640,8 @@ parse_message(struct vchiq_state *state, struct 
>> vchiq_header *header)
>>
>> ????? if (((unsigned long)header & VCHIQ_SLOT_MASK) +
>> ????????? calc_stride(size) > VCHIQ_SLOT_SIZE) {
>> -??????? vchiq_log_error(state->dev, VCHIQ_CORE,
>> -??????????????? "header %pK (msgid %x) - size %x too big for slot",
>> -??????????????? header, (unsigned int)msgid, (unsigned int)size);
>> +??????? dev_err(state->dev, "core: header %pK (msgid %x) - size %x 
>> too big for slot\n",
>> +??????????? header, (unsigned int)msgid, (unsigned int)size);
>> ????????? WARN(1, "oversized for slot\n");
>> ????? }
>>
>> @@ -1668,8 +1667,8 @@ parse_message(struct vchiq_state *state, struct 
>> vchiq_header *header)
>> ????????????? set_service_state(service, VCHIQ_SRVSTATE_OPEN);
>> ????????????? complete(&service->remove_event);
>> ????????? } else {
>> -??????????? vchiq_log_error(state->dev, VCHIQ_CORE, "OPENACK 
>> received in state %s",
>> -??????????????????? srvstate_names[service->srvstate]);
>> +??????????? dev_err(state->dev, "core: OPENACK received in state %s\n",
>> +??????????????? srvstate_names[service->srvstate]);
>> ????????? }
>> ????????? break;
>> ????? case VCHIQ_MSG_CLOSE:
>> @@ -1740,11 +1739,10 @@ parse_message(struct vchiq_state *state, 
>> struct vchiq_header *header)
>> ????????????? }
>> ????????????? if ((int)(queue->remote_insert -
>> ????????????????? queue->local_insert) >= 0) {
>> -??????????????? vchiq_log_error(state->dev, VCHIQ_CORE,
>> -??????????????????????? "%d: prs %s@%pK (%d->%d) unexpected 
>> (ri=%d,li=%d)",
>> -??????????????????????? state->id, msg_type_str(type), header, 
>> remoteport,
>> -??????????????????????? localport, queue->remote_insert,
>> -??????????????????????? queue->local_insert);
>> +??????????????? dev_err(state->dev,
>> +??????????????????? "core: %d: prs %s@%pK (%d->%d) unexpected 
>> (ri=%d,li=%d)\n",
>> +??????????????????? state->id, msg_type_str(type), header, remoteport,
>> +??????????????????? localport, queue->remote_insert, 
>> queue->local_insert);
>> ????????????????? mutex_unlock(&service->bulk_mutex);
>> ????????????????? break;
>> ????????????? }
>> @@ -1790,8 +1788,8 @@ parse_message(struct vchiq_state *state, struct 
>> vchiq_header *header)
>> ????????? vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs 
>> PAUSE@%pK,%x",
>> ????????????????? state->id, header, size);
>> ????????? if (state->conn_state == VCHIQ_CONNSTATE_PAUSED) {
>> -??????????? vchiq_log_error(state->dev, VCHIQ_CORE,
>> -??????????????????? "%d: PAUSE received in state PAUSED", state->id);
>> +??????????? dev_err(state->dev, "core: %d: PAUSE received in state 
>> PAUSED\n",
>> +??????????????? state->id);
>> ????????????? break;
>> ????????? }
>> ????????? if (state->conn_state != VCHIQ_CONNSTATE_PAUSE_SENT) {
>> @@ -1821,8 +1819,8 @@ parse_message(struct vchiq_state *state, struct 
>> vchiq_header *header)
>> ????????? break;
>>
>> ????? default:
>> -??????? vchiq_log_error(state->dev, VCHIQ_CORE, "%d: prs invalid 
>> msgid %x@%pK,%x",
>> -??????????????? state->id, msgid, header, size);
>> +??????? dev_err(state->dev, "core: %d: prs invalid msgid %x@%pK,%x\n",
>> +??????????? state->id, msgid, header, size);
>> ????????? WARN(1, "invalid message\n");
>> ????????? break;
>> ????? }
>> @@ -1932,7 +1930,7 @@ handle_poll(struct vchiq_state *state)
>> ?????????????? * since the PAUSE should have flushed
>> ?????????????? * through outstanding messages.
>> ?????????????? */
>> -??????????? vchiq_log_error(state->dev, VCHIQ_CORE, "Failed to send 
>> RESUME message");
>> +??????????? dev_err(state->dev, "core: Failed to send RESUME 
>> message\n");
>> ????????? }
>> ????????? break;
>> ????? default:
>> @@ -2032,10 +2030,10 @@ sync_func(void *v)
>> ????????? service = find_service_by_port(state, localport);
>>
>> ????????? if (!service) {
>> -??????????? vchiq_log_error(state->dev, VCHIQ_SYNC,
>> -??????????????????? "%d: sf %s@%pK (%d->%d) - invalid/closed service 
>> %d",
>> -??????????????????? state->id, msg_type_str(type), header,
>> -??????????????????? remoteport, localport, localport);
>> +??????????? dev_err(state->dev,
>> +??????????????? "sync: %d: sf %s@%pK (%d->%d) - invalid/closed 
>> service %d\n",
>> +??????????????? state->id, msg_type_str(type), header, remoteport,
>> +??????????????? localport, localport);
>> ????????????? release_message_sync(state, header);
>> ????????????? continue;
>> ????????? }
>> @@ -2077,15 +2075,15 @@ sync_func(void *v)
>> ????????????????? (service->srvstate == VCHIQ_SRVSTATE_OPENSYNC)) {
>> ????????????????? if (make_service_callback(service, 
>> VCHIQ_MESSAGE_AVAILABLE, header,
>> ??????????????????????????????? NULL) == -EAGAIN)
>> -??????????????????? vchiq_log_error(state->dev, VCHIQ_SYNC,
>> -??????????????????????????? "synchronous callback to service %d 
>> returns -EAGAIN",
>> -??????????????????????????? localport);
>> +??????????????????? dev_err(state->dev,
>> +??????????????????????? "sync: error: synchronous callback to 
>> service %d returns -EAGAIN\n",
>> +??????????????????????? localport);
>> ????????????? }
>> ????????????? break;
>>
>> ????????? default:
>> -??????????? vchiq_log_error(state->dev, VCHIQ_SYNC, "%d: sf 
>> unexpected msgid %x@%pK,%x",
>> -??????????????????? state->id, msgid, header, size);
>> +??????????? dev_err(state->dev, "sync: error: %d: sf unexpected 
>> msgid %x@%pK,%x\n",
>> +??????????????? state->id, msgid, header, size);
>> ????????????? release_message_sync(state, header);
>> ????????????? break;
>> ????????? }
>> @@ -2118,8 +2116,8 @@ vchiq_init_slots(struct device *dev, void 
>> *mem_base, int mem_size)
>> ????? num_slots -= first_data_slot;
>>
>> ????? if (num_slots < 4) {
>> -??????? vchiq_log_error(dev, VCHIQ_CORE, "%s - insufficient memory 
>> %x bytes",
>> -??????????????? __func__, mem_size);
>> +??????? dev_err(dev, "core: %s: Insufficient memory %x bytes\n",
>> +??????????? __func__, mem_size);
>> ????????? return NULL;
>> ????? }
>>
>> @@ -2500,11 +2498,10 @@ vchiq_open_service_internal(struct 
>> vchiq_service *service, int client_id)
>> ????? } else if ((service->srvstate != VCHIQ_SRVSTATE_OPEN) &&
>> ???????????? (service->srvstate != VCHIQ_SRVSTATE_OPENSYNC)) {
>> ????????? if (service->srvstate != VCHIQ_SRVSTATE_CLOSEWAIT)
>> -??????????? vchiq_log_error(service->state->dev, VCHIQ_CORE,
>> -??????????????????? "%d: osi - srvstate = %s (ref %u)",
>> -??????????????????? service->state->id,
>> -??????????????????? srvstate_names[service->srvstate],
>> -??????????????????? kref_read(&service->ref_count));
>> +??????????? dev_err(service->state->dev,
>> +??????????????? "core: %d: osi - srvstate = %s (ref %u)\n",
>> +??????????????? service->state->id, srvstate_names[service->srvstate],
>> +??????????????? kref_read(&service->ref_count));
>> ????????? status = -EINVAL;
>> ????????? VCHIQ_SERVICE_STATS_INC(service, error_count);
>> ????????? vchiq_release_service_internal(service);
>> @@ -2565,9 +2562,9 @@ release_service_messages(struct vchiq_service 
>> *service)
>> ????????????? }
>> ????????????? pos += calc_stride(header->size);
>> ????????????? if (pos > VCHIQ_SLOT_SIZE) {
>> -??????????????? vchiq_log_error(state->dev, VCHIQ_CORE,
>> -??????????????????????? "fsi - pos %x: header %pK, msgid %x, 
>> header->msgid %x, header->size %x",
>> -??????????????????????? pos, header, msgid, header->msgid, 
>> header->size);
>> +??????????????? dev_err(state->dev,
>> +??????????????????? "core: fsi - pos %x: header %pK, msgid %x, 
>> header->msgid %x, header->size %x\n",
>> +??????????????????? pos, header, msgid, header->msgid, header->size);
>> ????????????????? WARN(1, "invalid slot position\n");
>> ????????????? }
>> ????????? }
>> @@ -2621,8 +2618,8 @@ close_service_complete(struct vchiq_service 
>> *service, int failstate)
>> ????? case VCHIQ_SRVSTATE_LISTENING:
>> ????????? break;
>> ????? default:
>> -??????? vchiq_log_error(service->state->dev, VCHIQ_CORE, "%s(%x) 
>> called in state %s",
>> -??????????????? __func__, service->handle, 
>> srvstate_names[service->srvstate]);
>> +??????? dev_err(service->state->dev, "core: (%x) called in state %s\n",
>> +??????????? service->handle, srvstate_names[service->srvstate]);
>> ????????? WARN(1, "%s in unexpected state\n", __func__);
>> ????????? return -EINVAL;
>> ????? }
>> @@ -2677,8 +2674,8 @@ vchiq_close_service_internal(struct 
>> vchiq_service *service, int close_recvd)
>> ????? case VCHIQ_SRVSTATE_LISTENING:
>> ????? case VCHIQ_SRVSTATE_CLOSEWAIT:
>> ????????? if (close_recvd) {
>> -??????????? vchiq_log_error(state->dev, VCHIQ_CORE, "%s(1) called in 
>> state %s",
>> -??????????????????? __func__, srvstate_names[service->srvstate]);
>> +??????????? dev_err(state->dev, "core: (1) called in state %s\n",
>> +??????????????? srvstate_names[service->srvstate]);
>> ????????? } else if (is_server) {
>> ????????????? if (service->srvstate == VCHIQ_SRVSTATE_LISTENING) {
>> ????????????????? status = -EINVAL;
>> @@ -2765,8 +2762,8 @@ vchiq_close_service_internal(struct 
>> vchiq_service *service, int close_recvd)
>> ????????? break;
>>
>> ????? default:
>> -??????? vchiq_log_error(state->dev, VCHIQ_CORE, "%s(%d) called in 
>> state %s", __func__,
>> -??????????????? close_recvd, srvstate_names[service->srvstate]);
>> +??????? dev_err(state->dev, "core: (%d) called in state %s\n",
>> +??????????? close_recvd, srvstate_names[service->srvstate]);
>> ????????? break;
>> ????? }
>>
>> @@ -2805,8 +2802,8 @@ vchiq_free_service_internal(struct 
>> vchiq_service *service)
>> ????? case VCHIQ_SRVSTATE_CLOSEWAIT:
>> ????????? break;
>> ????? default:
>> -??????? vchiq_log_error(state->dev, VCHIQ_CORE, "%d: fsi - (%d) in 
>> state %s", state->id,
>> -??????????????? service->localport, srvstate_names[service->srvstate]);
>> +??????? dev_err(state->dev, "core: %d: fsi - (%d) in state %s\n",
>> +??????????? state->id, service->localport, 
>> srvstate_names[service->srvstate]);
>> ????????? return;
>> ????? }
>>
>> diff --git 
>> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h 
>> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
>> index 564b5c707267..d7dcd17e4bff 100644
>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
>> @@ -53,10 +53,6 @@ static inline const char *log_category_str(enum 
>> vchiq_log_category c)
>> ????? return strings[c];
>> ? };
>>
>> -#ifndef vchiq_log_error
>> -#define vchiq_log_error(dev, cat, fmt, ...) \
>> -??? do { dev_dbg(dev, "%s error: " fmt, log_category_str(cat), 
>> ##__VA_ARGS__); } while (0)
>> -#endif
>> ? #ifndef vchiq_log_warning
>> ? #define vchiq_log_warning(dev, cat, fmt, ...) \
>> ????? do { dev_dbg(dev, "%s warning: " fmt, log_category_str(cat), 
>> ##__VA_ARGS__); } while (0)
>> diff --git 
>> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c 
>> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
>> index 307a2d76cbb7..ba287cb4c87b 100644
>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
>> @@ -271,9 +271,9 @@ static int vchiq_ioc_dequeue_message(struct 
>> vchiq_instance *instance,
>> ????????????? ret = -EFAULT;
>> ????????? }
>> ????? } else {
>> -??????? vchiq_log_error(service->state->dev, VCHIQ_ARM,
>> -??????????????? "header %pK: bufsize %x < size %x",
>> -??????????????? header, args->bufsize, header->size);
>> +??????? dev_err(service->state->dev,
>> +??????????? "arm: header %pK: bufsize %x < size %x\n",
>> +??????????? header, args->bufsize, header->size);
>> ????????? WARN(1, "invalid size\n");
>> ????????? ret = -EMSGSIZE;
>> ????? }
>> @@ -318,8 +318,8 @@ static int vchiq_irq_queue_bulk_tx_rx(struct 
>> vchiq_instance *instance,
>> ????????? }
>> mutex_unlock(&instance->bulk_waiter_list_mutex);
>> ????????? if (!waiter) {
>> -??????????? vchiq_log_error(service->state->dev, VCHIQ_ARM,
>> -??????????????????? "no bulk_waiter found for pid %d", current->pid);
>> +??????????? dev_err(service->state->dev,
>> +??????????????? "arm: no bulk_waiter found for pid %d\n", 
>> current->pid);
>> ????????????? ret = -ESRCH;
>> ????????????? goto out;
>> ????????? }
>> @@ -501,10 +501,10 @@ static int vchiq_ioc_await_completion(struct 
>> vchiq_instance *instance,
>> ????????????? msglen = header->size + sizeof(struct vchiq_header);
>> ????????????? /* This must be a VCHIQ-style service */
>> ????????????? if (args->msgbufsize < msglen) {
>> -??????????????? vchiq_log_error(service->state->dev, VCHIQ_ARM,
>> -??????????????????????? "header %pK: msgbufsize %x < msglen %x",
>> -??????????????????????? header, args->msgbufsize, msglen);
>> -??????????????????????? WARN(1, "invalid message size\n");
>> +??????????????? dev_err(service->state->dev,
>> +??????????????????? "arm: header %pK: msgbufsize %x < msglen %x\n",
>> +??????????????????? header, args->msgbufsize, msglen);
>> +??????????????? WARN(1, "invalid message size\n");
>> ????????????????? if (ret == 0)
>> ????????????????????? ret = -EMSGSIZE;
>> ????????????????? break;
>> @@ -618,9 +618,9 @@ vchiq_ioctl(struct file *file, unsigned int cmd, 
>> unsigned long arg)
>> ????????? }
>> ????????? rc = mutex_lock_killable(&instance->state->mutex);
>> ????????? if (rc) {
>> -??????????? vchiq_log_error(instance->state->dev, VCHIQ_ARM,
>> -??????????????????? "vchiq: connect: could not lock mutex for state 
>> %d: %d",
>> -??????????????????? instance->state->id, rc);
>> +??????????? dev_err(instance->state->dev,
>> +??????????????? "arm: vchiq: connect: could not lock mutex for state 
>> %d: %d\n",
>> +??????????????? instance->state->id, rc);
> I think this should be dev_dbg
>> ????????????? ret = -EINTR;
>> ????????????? break;
>> ????????? }
>> @@ -630,8 +630,8 @@ vchiq_ioctl(struct file *file, unsigned int cmd, 
>> unsigned long arg)
>> ????????? if (!status)
>> ????????????? instance->connected = 1;
>> ????????? else
>> -??????????? vchiq_log_error(instance->state->dev, VCHIQ_ARM,
>> -??????????????????? "vchiq: could not connect: %d", status);
>> +??????????? dev_err(instance->state->dev,
>> +??????????????? "arm: vchiq: could not connect: %d\n", status);
>> ????????? break;
>>
>> ????? case VCHIQ_IOC_CREATE_SERVICE: {
>> @@ -700,13 +700,13 @@ vchiq_ioctl(struct file *file, unsigned int 
>> cmd, unsigned long arg)
>> ????????????????? vchiq_use_service_internal(service) :
>> ????????????????? vchiq_release_service_internal(service);
>> ????????????? if (ret) {
>> -??????????????? vchiq_log_error(instance->state->dev, VCHIQ_SUSPEND,
>> -??????????????????????? "%s: cmd %s returned error %ld for service 
>> %p4cc:%03d",
>> -??????????????????????? __func__, (cmd == VCHIQ_IOC_USE_SERVICE) ?
>> -??????????????????????? "VCHIQ_IOC_USE_SERVICE" :
>> -??????????????????????? "VCHIQ_IOC_RELEASE_SERVICE",
>> -??????????????????????? ret, &service->base.fourcc,
>> -??????????????????????? service->client_id);
>> +??????????????? dev_err(instance->state->dev,
>> +??????????????????? "suspend: cmd %s returned error %ld for service 
>> %p4cc:%03d\n",
>> +??????????????????? (cmd == VCHIQ_IOC_USE_SERVICE) ?
>> +??????????????????? "VCHIQ_IOC_USE_SERVICE" :
>> +??????????????????? "VCHIQ_IOC_RELEASE_SERVICE",
>> +??????????????????? ret, &service->base.fourcc,
>> +??????????????????? service->client_id);
>> ????????????? }
>> ????????? } else {
>> ????????????? ret = -EINVAL;
>> @@ -1173,8 +1173,7 @@ static int vchiq_open(struct inode *inode, 
>> struct file *file)
>> ????? vchiq_log_debug(state->dev, VCHIQ_ARM, "vchiq_open");
>>
>> ????? if (!state) {
>> -??????? vchiq_log_error(state->dev, VCHIQ_ARM,
>> -??????????????? "vchiq has no connection to VideoCore");
>> +??????? dev_err(state->dev, "arm: vchiq has no connection to 
>> VideoCore\n");
>> ????????? return -ENOTCONN;
>> ????? }
>>
>



From dan.carpenter at linaro.org  Tue Dec  5 21:35:52 2023
From: dan.carpenter at linaro.org (Dan Carpenter)
Date: Wed, 6 Dec 2023 08:35:52 +0300
Subject: [PATCH] [net/ethernet] arc_emac: Add error handling in
 emac_rockchip_probe
In-Reply-To: <20231130031318.35850-1-liuhaoran14@163.com>
Message-ID: <08f04975-2abb-4c1a-8bf6-34e6653568af@suswa.mountain>

Hi Haoran,

kernel test robot noticed the following build warnings:

https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Haoran-Liu/arc_emac-Add-error-handling-in-emac_rockchip_probe/20231130-112325
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next
patch link:    https://lore.kernel.org/r/20231130031318.35850-1-liuhaoran14%40163.com
patch subject: [PATCH] [net/ethernet] arc_emac: Add error handling in emac_rockchip_probe
config: csky-randconfig-r071-20231203 (https://download.01.org/0day-ci/archive/20231206/202312060119.eRpB9j4s-lkp at intel.com/config)
compiler: csky-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231206/202312060119.eRpB9j4s-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Reported-by: Dan Carpenter <dan.carpenter at linaro.org>
| Closes: https://lore.kernel.org/r/202312060119.eRpB9j4s-lkp at intel.com/

smatch warnings:
drivers/net/ethernet/arc/emac_rockchip.c:139 emac_rockchip_probe() warn: missing unwind goto?
drivers/net/ethernet/arc/emac_rockchip.c:249 emac_rockchip_probe() warn: 'ndev' from alloc_etherdev_mqs() not released on lines: 139.

vim +139 drivers/net/ethernet/arc/emac_rockchip.c

6eacf31139bf96 Romain Perier      2014-09-08   93  static int emac_rockchip_probe(struct platform_device *pdev)
6eacf31139bf96 Romain Perier      2014-09-08   94  {
6eacf31139bf96 Romain Perier      2014-09-08   95  	struct device *dev = &pdev->dev;
6eacf31139bf96 Romain Perier      2014-09-08   96  	struct net_device *ndev;
6eacf31139bf96 Romain Perier      2014-09-08   97  	struct rockchip_priv_data *priv;
6eacf31139bf96 Romain Perier      2014-09-08   98  	const struct of_device_id *match;
0c65b2b90d13c1 Andrew Lunn        2019-11-04   99  	phy_interface_t interface;
6eacf31139bf96 Romain Perier      2014-09-08  100  	u32 data;
0c65b2b90d13c1 Andrew Lunn        2019-11-04  101  	int err;
6eacf31139bf96 Romain Perier      2014-09-08  102  
6eacf31139bf96 Romain Perier      2014-09-08  103  	if (!pdev->dev.of_node)
6eacf31139bf96 Romain Perier      2014-09-08  104  		return -ENODEV;
6eacf31139bf96 Romain Perier      2014-09-08  105  
6eacf31139bf96 Romain Perier      2014-09-08  106  	ndev = alloc_etherdev(sizeof(struct rockchip_priv_data));
6eacf31139bf96 Romain Perier      2014-09-08  107  	if (!ndev)
6eacf31139bf96 Romain Perier      2014-09-08  108  		return -ENOMEM;
6eacf31139bf96 Romain Perier      2014-09-08  109  	platform_set_drvdata(pdev, ndev);
6eacf31139bf96 Romain Perier      2014-09-08  110  	SET_NETDEV_DEV(ndev, dev);
6eacf31139bf96 Romain Perier      2014-09-08  111  
6eacf31139bf96 Romain Perier      2014-09-08  112  	priv = netdev_priv(ndev);
6eacf31139bf96 Romain Perier      2014-09-08  113  	priv->emac.drv_name = DRV_NAME;
6eacf31139bf96 Romain Perier      2014-09-08  114  	priv->emac.set_mac_speed = emac_rockchip_set_mac_speed;
6eacf31139bf96 Romain Perier      2014-09-08  115  
0c65b2b90d13c1 Andrew Lunn        2019-11-04  116  	err = of_get_phy_mode(dev->of_node, &interface);
0c65b2b90d13c1 Andrew Lunn        2019-11-04  117  	if (err)
0c65b2b90d13c1 Andrew Lunn        2019-11-04  118  		goto out_netdev;
6eacf31139bf96 Romain Perier      2014-09-08  119  
af72261f33ee49 Xing Zheng         2016-01-08  120  	/* RK3036/RK3066/RK3188 SoCs only support RMII */
6eacf31139bf96 Romain Perier      2014-09-08  121  	if (interface != PHY_INTERFACE_MODE_RMII) {
6eacf31139bf96 Romain Perier      2014-09-08  122  		dev_err(dev, "unsupported phy interface mode %d\n", interface);
6eacf31139bf96 Romain Perier      2014-09-08  123  		err = -ENOTSUPP;
6eacf31139bf96 Romain Perier      2014-09-08  124  		goto out_netdev;
6eacf31139bf96 Romain Perier      2014-09-08  125  	}
6eacf31139bf96 Romain Perier      2014-09-08  126  
663713eb477b9b Caesar Wang        2016-03-14  127  	priv->grf = syscon_regmap_lookup_by_phandle(dev->of_node,
663713eb477b9b Caesar Wang        2016-03-14  128  						    "rockchip,grf");
6eacf31139bf96 Romain Perier      2014-09-08  129  	if (IS_ERR(priv->grf)) {
663713eb477b9b Caesar Wang        2016-03-14  130  		dev_err(dev, "failed to retrieve global register file (%ld)\n",
663713eb477b9b Caesar Wang        2016-03-14  131  			PTR_ERR(priv->grf));
6eacf31139bf96 Romain Perier      2014-09-08  132  		err = PTR_ERR(priv->grf);
6eacf31139bf96 Romain Perier      2014-09-08  133  		goto out_netdev;
6eacf31139bf96 Romain Perier      2014-09-08  134  	}
6eacf31139bf96 Romain Perier      2014-09-08  135  
6eacf31139bf96 Romain Perier      2014-09-08  136  	match = of_match_node(emac_rockchip_dt_ids, dev->of_node);
8cb4cdab4b4030 Haoran Liu         2023-11-29  137  	if (!match) {
8cb4cdab4b4030 Haoran Liu         2023-11-29  138  		dev_err(dev, "No matching device found\n");
8cb4cdab4b4030 Haoran Liu         2023-11-29 @139  		return -ENODEV;

goto out_netdev;

8cb4cdab4b4030 Haoran Liu         2023-11-29  140  	}
8cb4cdab4b4030 Haoran Liu         2023-11-29  141  
6eacf31139bf96 Romain Perier      2014-09-08  142  	priv->soc_data = match->data;
6eacf31139bf96 Romain Perier      2014-09-08  143  
6eacf31139bf96 Romain Perier      2014-09-08  144  	priv->emac.clk = devm_clk_get(dev, "hclk");
6eacf31139bf96 Romain Perier      2014-09-08  145  	if (IS_ERR(priv->emac.clk)) {
663713eb477b9b Caesar Wang        2016-03-14  146  		dev_err(dev, "failed to retrieve host clock (%ld)\n",
663713eb477b9b Caesar Wang        2016-03-14  147  			PTR_ERR(priv->emac.clk));
6eacf31139bf96 Romain Perier      2014-09-08  148  		err = PTR_ERR(priv->emac.clk);
6eacf31139bf96 Romain Perier      2014-09-08  149  		goto out_netdev;
6eacf31139bf96 Romain Perier      2014-09-08  150  	}
6eacf31139bf96 Romain Perier      2014-09-08  151  
6eacf31139bf96 Romain Perier      2014-09-08  152  	priv->refclk = devm_clk_get(dev, "macref");
6eacf31139bf96 Romain Perier      2014-09-08  153  	if (IS_ERR(priv->refclk)) {
663713eb477b9b Caesar Wang        2016-03-14  154  		dev_err(dev, "failed to retrieve reference clock (%ld)\n",
663713eb477b9b Caesar Wang        2016-03-14  155  			PTR_ERR(priv->refclk));
6eacf31139bf96 Romain Perier      2014-09-08  156  		err = PTR_ERR(priv->refclk);
6eacf31139bf96 Romain Perier      2014-09-08  157  		goto out_netdev;
6eacf31139bf96 Romain Perier      2014-09-08  158  	}
6eacf31139bf96 Romain Perier      2014-09-08  159  
6eacf31139bf96 Romain Perier      2014-09-08  160  	err = clk_prepare_enable(priv->refclk);
6eacf31139bf96 Romain Perier      2014-09-08  161  	if (err) {
6eacf31139bf96 Romain Perier      2014-09-08  162  		dev_err(dev, "failed to enable reference clock (%d)\n", err);
6eacf31139bf96 Romain Perier      2014-09-08  163  		goto out_netdev;
6eacf31139bf96 Romain Perier      2014-09-08  164  	}
6eacf31139bf96 Romain Perier      2014-09-08  165  
6eacf31139bf96 Romain Perier      2014-09-08  166  	/* Optional regulator for PHY */
6eacf31139bf96 Romain Perier      2014-09-08  167  	priv->regulator = devm_regulator_get_optional(dev, "phy");
6eacf31139bf96 Romain Perier      2014-09-08  168  	if (IS_ERR(priv->regulator)) {
00777fac28ba3e Christophe JAILLET 2018-03-18  169  		if (PTR_ERR(priv->regulator) == -EPROBE_DEFER) {
00777fac28ba3e Christophe JAILLET 2018-03-18  170  			err = -EPROBE_DEFER;
00777fac28ba3e Christophe JAILLET 2018-03-18  171  			goto out_clk_disable;
00777fac28ba3e Christophe JAILLET 2018-03-18  172  		}
6eacf31139bf96 Romain Perier      2014-09-08  173  		dev_err(dev, "no regulator found\n");
6eacf31139bf96 Romain Perier      2014-09-08  174  		priv->regulator = NULL;
6eacf31139bf96 Romain Perier      2014-09-08  175  	}
6eacf31139bf96 Romain Perier      2014-09-08  176  
6eacf31139bf96 Romain Perier      2014-09-08  177  	if (priv->regulator) {
6eacf31139bf96 Romain Perier      2014-09-08  178  		err = regulator_enable(priv->regulator);
6eacf31139bf96 Romain Perier      2014-09-08  179  		if (err) {
6eacf31139bf96 Romain Perier      2014-09-08  180  			dev_err(dev, "failed to enable phy-supply (%d)\n", err);
6eacf31139bf96 Romain Perier      2014-09-08  181  			goto out_clk_disable;
6eacf31139bf96 Romain Perier      2014-09-08  182  		}
6eacf31139bf96 Romain Perier      2014-09-08  183  	}
6eacf31139bf96 Romain Perier      2014-09-08  184  
f4c9d3ee0334fd Xing Zheng         2016-01-08  185  	/* Set speed 100M */
f4c9d3ee0334fd Xing Zheng         2016-01-08  186  	data = (1 << (priv->soc_data->grf_speed_offset + 16)) |
f4c9d3ee0334fd Xing Zheng         2016-01-08  187  	       (1 << priv->soc_data->grf_speed_offset);
f4c9d3ee0334fd Xing Zheng         2016-01-08  188  	/* Set RMII mode */
f4c9d3ee0334fd Xing Zheng         2016-01-08  189  	data |= (1 << (priv->soc_data->grf_mode_offset + 16)) |
f4c9d3ee0334fd Xing Zheng         2016-01-08  190  		(0 << priv->soc_data->grf_mode_offset);
6eacf31139bf96 Romain Perier      2014-09-08  191  
6eacf31139bf96 Romain Perier      2014-09-08  192  	err = regmap_write(priv->grf, priv->soc_data->grf_offset, data);
6eacf31139bf96 Romain Perier      2014-09-08  193  	if (err) {
663713eb477b9b Caesar Wang        2016-03-14  194  		dev_err(dev, "unable to apply initial settings to grf (%d)\n",
663713eb477b9b Caesar Wang        2016-03-14  195  			err);
6eacf31139bf96 Romain Perier      2014-09-08  196  		goto out_regulator_disable;
6eacf31139bf96 Romain Perier      2014-09-08  197  	}
6eacf31139bf96 Romain Perier      2014-09-08  198  
6eacf31139bf96 Romain Perier      2014-09-08  199  	/* RMII interface needs always a rate of 50MHz */
6eacf31139bf96 Romain Perier      2014-09-08  200  	err = clk_set_rate(priv->refclk, 50000000);
2a9ee696c72a24 Branislav Radocaj  2017-12-12  201  	if (err) {
663713eb477b9b Caesar Wang        2016-03-14  202  		dev_err(dev,
663713eb477b9b Caesar Wang        2016-03-14  203  			"failed to change reference clock rate (%d)\n", err);
2a9ee696c72a24 Branislav Radocaj  2017-12-12  204  		goto out_regulator_disable;
2a9ee696c72a24 Branislav Radocaj  2017-12-12  205  	}
c9bca2fe3ca6d6 Xing Zheng         2016-01-08  206  
f4c9d3ee0334fd Xing Zheng         2016-01-08  207  	if (priv->soc_data->need_div_macclk) {
f4c9d3ee0334fd Xing Zheng         2016-01-08  208  		priv->macclk = devm_clk_get(dev, "macclk");
f4c9d3ee0334fd Xing Zheng         2016-01-08  209  		if (IS_ERR(priv->macclk)) {
663713eb477b9b Caesar Wang        2016-03-14  210  			dev_err(dev, "failed to retrieve mac clock (%ld)\n",
663713eb477b9b Caesar Wang        2016-03-14  211  				PTR_ERR(priv->macclk));
f4c9d3ee0334fd Xing Zheng         2016-01-08  212  			err = PTR_ERR(priv->macclk);
f4c9d3ee0334fd Xing Zheng         2016-01-08  213  			goto out_regulator_disable;
f4c9d3ee0334fd Xing Zheng         2016-01-08  214  		}
f4c9d3ee0334fd Xing Zheng         2016-01-08  215  
f4c9d3ee0334fd Xing Zheng         2016-01-08  216  		err = clk_prepare_enable(priv->macclk);
f4c9d3ee0334fd Xing Zheng         2016-01-08  217  		if (err) {
f4c9d3ee0334fd Xing Zheng         2016-01-08  218  			dev_err(dev, "failed to enable mac clock (%d)\n", err);
f4c9d3ee0334fd Xing Zheng         2016-01-08  219  			goto out_regulator_disable;
f4c9d3ee0334fd Xing Zheng         2016-01-08  220  		}
f4c9d3ee0334fd Xing Zheng         2016-01-08  221  
f4c9d3ee0334fd Xing Zheng         2016-01-08  222  		/* RMII TX/RX needs always a rate of 25MHz */
f4c9d3ee0334fd Xing Zheng         2016-01-08  223  		err = clk_set_rate(priv->macclk, 25000000);
e46772a6946a7d Branislav Radocaj  2017-12-07  224  		if (err) {
663713eb477b9b Caesar Wang        2016-03-14  225  			dev_err(dev,
663713eb477b9b Caesar Wang        2016-03-14  226  				"failed to change mac clock rate (%d)\n", err);
e46772a6946a7d Branislav Radocaj  2017-12-07  227  			goto out_clk_disable_macclk;
e46772a6946a7d Branislav Radocaj  2017-12-07  228  		}
f4c9d3ee0334fd Xing Zheng         2016-01-08  229  	}
f4c9d3ee0334fd Xing Zheng         2016-01-08  230  
c9bca2fe3ca6d6 Xing Zheng         2016-01-08  231  	err = arc_emac_probe(ndev, interface);
c9bca2fe3ca6d6 Xing Zheng         2016-01-08  232  	if (err) {
c9bca2fe3ca6d6 Xing Zheng         2016-01-08  233  		dev_err(dev, "failed to probe arc emac (%d)\n", err);
2a9ee696c72a24 Branislav Radocaj  2017-12-12  234  		goto out_clk_disable_macclk;
c9bca2fe3ca6d6 Xing Zheng         2016-01-08  235  	}
c9bca2fe3ca6d6 Xing Zheng         2016-01-08  236  
6eacf31139bf96 Romain Perier      2014-09-08  237  	return 0;
2a9ee696c72a24 Branislav Radocaj  2017-12-12  238  
e46772a6946a7d Branislav Radocaj  2017-12-07  239  out_clk_disable_macclk:
2a9ee696c72a24 Branislav Radocaj  2017-12-12  240  	if (priv->soc_data->need_div_macclk)
e46772a6946a7d Branislav Radocaj  2017-12-07  241  		clk_disable_unprepare(priv->macclk);
6eacf31139bf96 Romain Perier      2014-09-08  242  out_regulator_disable:
6eacf31139bf96 Romain Perier      2014-09-08  243  	if (priv->regulator)
6eacf31139bf96 Romain Perier      2014-09-08  244  		regulator_disable(priv->regulator);
6eacf31139bf96 Romain Perier      2014-09-08  245  out_clk_disable:
6eacf31139bf96 Romain Perier      2014-09-08  246  	clk_disable_unprepare(priv->refclk);
6eacf31139bf96 Romain Perier      2014-09-08  247  out_netdev:
6eacf31139bf96 Romain Perier      2014-09-08  248  	free_netdev(ndev);
6eacf31139bf96 Romain Perier      2014-09-08 @249  	return err;
6eacf31139bf96 Romain Perier      2014-09-08  250  }

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki



From quic_nitirawa at quicinc.com  Tue Dec  5 21:36:28 2023
From: quic_nitirawa at quicinc.com (Nitin Rawat)
Date: Wed,  6 Dec 2023 11:06:28 +0530
Subject: [PATCH V1] scsi: ufs: core: store min and max clk freq from OPP table
Message-ID: <20231206053628.32169-1-quic_nitirawa@quicinc.com>

OPP support will make use of OPP table in device tree and removes
freq-table-hz property from device tree.

With OPP enabled in devicetree, clki->min_freq and clki->maxfreq
currently is not getting updated and the value is set to 0.

Soc vendors like qcom, mediatek uses clki->minfreq and clki->maxfreq
in vendor specific file. These frequencies values are used to update
vendor specific configurations. Since the value is 0, it is causing
functional issue.

Add code to store the min and max ufs clk frequency from OPP table.

Fixes: 72208ebe181e ("scsi: ufs: core: Add support for parsing OPP")
Co-developed-by: Manish Pandey <quic_mapa at quicinc.com>
Signed-off-by: Manish Pandey <quic_mapa at quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
---
 drivers/ufs/host/ufshcd-pltfrm.c | 56 ++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/drivers/ufs/host/ufshcd-pltfrm.c b/drivers/ufs/host/ufshcd-pltfrm.c
index da2558e274b4..12fa6f7d6a97 100644
--- a/drivers/ufs/host/ufshcd-pltfrm.c
+++ b/drivers/ufs/host/ufshcd-pltfrm.c
@@ -13,6 +13,7 @@
 #include <linux/pm_opp.h>
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
+#include <linux/clk.h>

 #include <ufs/ufshcd.h>
 #include "ufshcd-pltfrm.h"
@@ -213,6 +214,55 @@ static void ufshcd_init_lanes_per_dir(struct ufs_hba *hba)
 	}
 }

+/**
+ * ufshcd_config_min_max_clk_freq - update min and max freq
+ * @hba: per adapter instance
+ *
+ * This function store min and max freq for all the clocks.
+ *
+ * Returns 0 for success and non-zero for failure
+ */
+static int ufshcd_config_min_max_clk_freq(struct ufs_hba *hba)
+{
+	struct list_head *head = &hba->clk_list_head;
+	struct dev_pm_opp *opp;
+	struct ufs_clk_info *clki;
+	unsigned long freq;
+	u8 idx = 0;
+	int ret;
+
+	list_for_each_entry(clki, head, list) {
+		if (!clki->name)
+			continue;
+
+		clki->clk = devm_clk_get(hba->dev, clki->name);
+		if (!IS_ERR_OR_NULL(clki->clk)) {
+			/* Find Max Freq */
+			freq = ULONG_MAX;
+			opp = dev_pm_opp_find_freq_floor_indexed(hba->dev, &freq, idx);
+			if (IS_ERR(opp)) {
+				dev_err(hba->dev, "failed to find dev_pm_opp\n");
+				ret = PTR_ERR(opp);
+				return ret;
+			}
+			clki->max_freq = dev_pm_opp_get_freq_indexed(opp, idx);
+
+			/* Find Min Freq */
+			freq = 0;
+			opp = dev_pm_opp_find_freq_ceil_indexed(hba->dev, &freq, idx);
+			if (IS_ERR(opp)) {
+				dev_err(hba->dev, "failed to find dev_pm_opp\n");
+				ret = PTR_ERR(opp);
+				return ret;
+			}
+			clki->min_freq = dev_pm_opp_get_freq_indexed(opp, idx);
+			idx++;
+		}
+	}
+
+	return 0;
+}
+
 static int ufshcd_parse_operating_points(struct ufs_hba *hba)
 {
 	struct device *dev = hba->dev;
@@ -279,6 +329,12 @@ static int ufshcd_parse_operating_points(struct ufs_hba *hba)
 		return ret;
 	}

+	ret = ufshcd_config_min_max_clk_freq(hba);
+	if (ret) {
+		dev_err(dev, "Failed to get min max freq: %d\n", ret);
+		return ret;
+	}
+
 	hba->use_pm_opp = true;

 	return 0;
--
2.17.1



From Frank.li at nxp.com  Tue Dec  5 21:46:15 2023
From: Frank.li at nxp.com (Frank Li)
Date: Wed, 6 Dec 2023 00:46:15 -0500
Subject: [PATCH v2 2/2] arm64: dts: freescale: imx93: add i3c1 and i3c2
In-Reply-To: <20231127-cherisher-falsify-8193656e8872@wendy>
References: <20231017194657.3199749-1-Frank.Li@nxp.com>
 <20231017194657.3199749-2-Frank.Li@nxp.com>
 <ZUz/8fBWtnwdSW9w@lizhi-Precision-Tower-5810>
 <20231127022140.GJ87953@dragon>
 <20231127-cherisher-falsify-8193656e8872@wendy>
Message-ID: <ZXAKp1WS97cAI5X2@lizhi-Precision-Tower-5810>

On Mon, Nov 27, 2023 at 09:35:39AM +0000, Conor Dooley wrote:
> On Mon, Nov 27, 2023 at 10:21:40AM +0800, Shawn Guo wrote:
> > On Thu, Nov 09, 2023 at 10:51:13AM -0500, Frank Li wrote:
> > > On Tue, Oct 17, 2023 at 03:46:57PM -0400, Frank Li wrote:
> > > > Add I3C1 and I3C2.
> > > > 
> > > > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > > > ---
> > > 
> > > @Guo Shawn:
> > > 
> > > Driver part already merged. 
> > > 
> > > Please pick up dts part
> > 
> > Rob had a comment [1] about SoC specific compatible.  That's not what we
> > want?
> > 
> > Shawn
> > 
> > [1] https://lkml.iu.edu/hypermail/linux/kernel/2310.2/03035.html
> 
> Yeah, Rob's request here looks valid to me. Should just be a bindings
> change Frank & fall back to the "silvaco,i3c-master-v1" compatible.
> 
> Cheers,
> Conor.

@shawn:
	rob agree on "silvaco,i3c-master-v1" compatible.

Frank


From viresh.kumar at linaro.org  Tue Dec  5 22:11:11 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Wed, 6 Dec 2023 11:41:11 +0530
Subject: [PATCH v2] cpufreq: scmi: process the result of
 devm_of_clk_add_hw_provider()
In-Reply-To: <20231205151220.18463-1-adiupina@astralinux.ru>
References: <2e919694-e124-4864-aa02-01d47495032b@wanadoo.fr>
 <20231205151220.18463-1-adiupina@astralinux.ru>
Message-ID: <20231206061111.yim5ahpwdovirtzu@vireshk-i7>

On 05-12-23, 18:12, Alexandra Diupina wrote:
> devm_of_clk_add_hw_provider() may return an errno, so
> add a return value check
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Fixes: 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider")
> Signed-off-by: Alexandra Diupina <adiupina at astralinux.ru>
> ---
> v2: replace dev_err() with dev_err_probe() as 
> Christophe JAILLET <christophe.jaillet at wanadoo.fr> suggested
>  drivers/cpufreq/scmi-cpufreq.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index c8a7ccc42c16..4ee23f4ebf4a 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -334,8 +334,11 @@ static int scmi_cpufreq_probe(struct scmi_device *sdev)
>  
>  #ifdef CONFIG_COMMON_CLK
>  	/* dummy clock provider as needed by OPP if clocks property is used */
> -	if (of_property_present(dev->of_node, "#clock-cells"))
> -		devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get, NULL);
> +	if (of_property_present(dev->of_node, "#clock-cells")) {
> +		ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get, NULL);
> +		if (ret)
> +			return dev_err_probe(dev, ret, "%s: registering clock provider failed\n", __func__);
> +	}
>  #endif
>  
>  	ret = cpufreq_register_driver(&scmi_cpufreq_driver);

Applied. Thanks.

-- 
viresh


From aakarsh.jain at samsung.com  Tue Dec  5 22:30:34 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:34 +0530
Subject: [Patch v5 00/11] Add MFC V12 support
References: <CGME20231206063105epcas5p3034f89af2be6922ab04771de099a124a@epcas5p3.samsung.com>
Message-ID: <20231206063045.97234-1-aakarsh.jain@samsung.com>

This patch series adds MFC v12 support. MFC v12 is used in Tesla FSD SoC.

This adds support for following:

-Add support for YV12 and I420 format (3-plane)
-Add support for Rate Control, UHD and DMABUF for encoder
-Add support for DPB buffers allocation based on MFC requirement

Changes since v4:
-Addressed review comments by Krzysztof Kozlowski.
As per discussion included iommus property in dt-schema.
-Addressed review comments by Hans Verkuil.
Fixed checkpatch warnings with --strict flag enabled.
Upstreamed s5p-mfc-v12.fw to linux-firmware.
Added comment in the patch 9 regarding loading mfc firmware v12 
sequentially.
-Addressed review comments by Nicolas Dufresne
Made use of v4l2-common library to get number of planes needed for
particular format in patch 4.
v4 link:https://patchwork.kernel.org/project/linux-media/patch/20231025102216.50480-2-aakarsh.jain at samsung.com/

Changes since v3:
-Removed vp9 codec support for now and just keeping MFC v12 base
patches with necessary hardware controls, decoder, encoder and
structural changes. Also covers luma dbp, chroma dpb and mv sizes
for each codec as per the UM for MFCv12, along with appropriate
alignment.
v3 link: https://patchwork.kernel.org/project/linux-media/cover/20221011122516.32135-1-aakarsh.jain at samsung.com/

Changes since v2:
-Addressed review comments by Rob Herring.
This was regarding the errors found by Rob bot in yaml file. File
'samsung,s5p-mfc.yaml' is already converted into json schema and is
merged.

-Addressed review comments by Krzysztof Kozlowski.
This was regarding depricated properties mentioned in s5p-mfc.txt file.
Review comment was addressed and 'samsung,s5p-mfc.yaml' is already
merged now.

-Addressed review comments by Andi Shyti.
This was regarding addition of 'MFC_V10PLUS_BITS' macro in
's5p_mfc_common.h file.
v2 link: https://patchwork.kernel.org/project/linux-media/cover/20220907064715.55778-1-smitha.t at samsung.com/

Changes since v1:
-Addressed review comments by Krzysztof Kozlowski.
Separated bug fixes patches, resent again with fix tag
and those are merged now.
-Added SoC based compatible string.

-Addressed review comments by Andrzej Hajda
Assigned width64 and height32 variable with ALIGN(ctx->img_..)
used in the code in 's5p_mfc_opr_v6.c' file.
v1 link: https://patchwork.kernel.org/project/linux-media/patch/20220517125548.14746-2-smitha.t at samsung.com/

Aakarsh Jain (11):
  dt-bindings: media: s5p-mfc: Add mfcv12 variant
  media: s5p-mfc: Rename IS_MFCV10 macro
  media: s5p-mfc: Add initial support for MFCv12
  media: s5p-mfc: Add YV12 and I420 multiplanar format support
  media: s5p-mfc: Add support for rate controls in MFCv12
  media: s5p-mfc: Add support for UHD encoding.
  media: s5p-mfc: Add support for DMABUF for encoder
  media: s5p-mfc: Set context for valid case before calling try_run
  media: s5p-mfc: Load firmware for each run in MFCv12.
  media: s5p-mfc: DPB Count Independent of VIDIOC_REQBUF
  arm64: dts: fsd: Add MFC related DT enteries

 .../bindings/media/samsung,s5p-mfc.yaml       |  18 ++
 arch/arm64/boot/dts/tesla/fsd.dtsi            |  21 ++
 .../platform/samsung/s5p-mfc/regs-mfc-v12.h   |  52 +++
 .../platform/samsung/s5p-mfc/regs-mfc-v7.h    |   1 +
 .../platform/samsung/s5p-mfc/regs-mfc-v8.h    |   3 +
 .../media/platform/samsung/s5p-mfc/s5p_mfc.c  |  36 ++-
 .../platform/samsung/s5p-mfc/s5p_mfc_common.h |  29 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_ctrl.c   |  10 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_dec.c    |  60 +++-
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    | 149 ++++++---
 .../platform/samsung/s5p-mfc/s5p_mfc_opr.h    |  14 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c |  12 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 300 ++++++++++++++----
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h |   7 +-
 14 files changed, 563 insertions(+), 149 deletions(-)
 create mode 100644 drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h

-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:35 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:35 +0530
Subject: [Patch v5 01/11] dt-bindings: media: s5p-mfc: Add mfcv12 variant
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063108epcas5p1af3d9d0442c8abebe91d769cc68284d5@epcas5p1.samsung.com>
Message-ID: <20231206063045.97234-2-aakarsh.jain@samsung.com>

Add Tesla FSD MFC(MFC v12) compatible.

Cc: linux-fsd at tesla.com
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
changelog:
v4->v5
Added iommu property for mfcv12.

v3->v4
Since mfc dt-schema patch got merged so now only one patch remains which add
mfcv12 compatible.
On top of this change, added mfcv12 hw properties in this patch. Since, this became
relatively new patch so thought of getting it reviewed again. So, removed krzysztof's
reviewed-by tag.

v2->v3:
Fixed warnings and errors reported by Rob bot on dt-schema patch.

v1->v2:
There were two different patches for dt-schema. First patch was for conversion
of mfc txt file to json schema and also contains mfcv12 hw properties and
Second patch was for adding mfcv12 specific compatible string.
So as per review comment, changed mfcv12 compatible string to SoC base and fixed
the warnings reported by Rob bot in dt-schema file.
 .../bindings/media/samsung,s5p-mfc.yaml        | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
index 084b44582a43..d66e51547482 100644
--- a/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
+++ b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
@@ -24,6 +24,7 @@ properties:
           - samsung,mfc-v7                # Exynos5420
           - samsung,mfc-v8                # Exynos5800
           - samsung,mfc-v10               # Exynos7880
+          - tesla,fsd-mfc                 # Tesla FSD
       - items:
           - enum:
               - samsung,exynos3250-mfc    # Exynos3250
@@ -165,6 +166,23 @@ allOf:
           minItems: 1
           maxItems: 2
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - tesla,fsd-mfc
+    then:
+      properties:
+        clocks:
+          maxItems: 1
+        clock-names:
+          items:
+            - const: mfc
+        iommus:
+          maxItems: 2
+        iommus-names: false
+
 examples:
   - |
     #include <dt-bindings/clock/exynos4.h>
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:36 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:36 +0530
Subject: [Patch v5 02/11] media: s5p-mfc: Rename IS_MFCV10 macro
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063111epcas5p112aeeca899892a154c9a68c8e8873647@epcas5p1.samsung.com>
Message-ID: <20231206063045.97234-3-aakarsh.jain@samsung.com>

Renames macro IS_MFCV10 to IS_MFCV10_PLUS so that the MFCv10 code can
be resued for MFCv12 support. Since some part of MFCv10 specific code
holds good for MFCv12 also.

Cc: linux-fsd at tesla.com
Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../platform/samsung/s5p-mfc/s5p_mfc_common.h | 10 +++----
 .../platform/samsung/s5p-mfc/s5p_mfc_ctrl.c   |  2 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 28 +++++++++----------
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index 5304f42c8c72..2ae2f23c4741 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -771,11 +771,11 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq);
 #define HAS_PORTNUM(dev)	(dev ? (dev->variant ? \
 				(dev->variant->port_num ? 1 : 0) : 0) : 0)
 #define IS_TWOPORT(dev)		(dev->variant->port_num == 2 ? 1 : 0)
-#define IS_MFCV6_PLUS(dev)	(dev->variant->version >= 0x60 ? 1 : 0)
-#define IS_MFCV7_PLUS(dev)	(dev->variant->version >= 0x70 ? 1 : 0)
-#define IS_MFCV8_PLUS(dev)	(dev->variant->version >= 0x80 ? 1 : 0)
-#define IS_MFCV10(dev)		(dev->variant->version >= 0xA0 ? 1 : 0)
-#define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10(dev))
+#define IS_MFCV6_PLUS(dev)	((dev)->variant->version >= 0x60)
+#define IS_MFCV7_PLUS(dev)	((dev)->variant->version >= 0x70)
+#define IS_MFCV8_PLUS(dev)	((dev)->variant->version >= 0x80)
+#define IS_MFCV10_PLUS(dev)	((dev)->variant->version >= 0xA0)
+#define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10_PLUS(dev))
 
 #define MFC_V5_BIT	BIT(0)
 #define MFC_V6_BIT	BIT(1)
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
index 6d3c92045c05..54b54b2fa9b1 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
@@ -236,7 +236,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
 	else
 		mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
 
-	if (IS_MFCV10(dev))
+	if (IS_MFCV10_PLUS(dev))
 		mfc_write(dev, 0x0, S5P_FIMV_MFC_CLOCK_OFF_V10);
 
 	mfc_debug(2, "Will now wait for completion of firmware transfer\n");
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index c0df5ac9fcff..882166e4ac50 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -72,9 +72,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			  ctx->luma_size, ctx->chroma_size, ctx->mv_size);
 		mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
 	} else if (ctx->type == MFCINST_ENCODER) {
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev))
 			ctx->tmv_buffer_size = 0;
-		} else if (IS_MFCV8_PLUS(dev))
+		else if (IS_MFCV8_PLUS(dev))
 			ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
 			ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, mb_height),
 			S5P_FIMV_TMV_BUFFER_ALIGN_V6);
@@ -82,7 +82,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
 			ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
 			S5P_FIMV_TMV_BUFFER_ALIGN_V6);
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			lcu_width = S5P_MFC_LCU_WIDTH(ctx->img_width);
 			lcu_height = S5P_MFC_LCU_HEIGHT(ctx->img_height);
 			if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
@@ -133,7 +133,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 	switch (ctx->codec_mode) {
 	case S5P_MFC_CODEC_H264_DEC:
 	case S5P_MFC_CODEC_H264_MVC_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else if (IS_MFCV8_PLUS(dev))
 			ctx->scratch_buf_size =
@@ -152,7 +152,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			(ctx->mv_count * ctx->mv_size);
 		break;
 	case S5P_MFC_CODEC_MPEG4_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else if (IS_MFCV7_PLUS(dev)) {
 			ctx->scratch_buf_size =
@@ -172,7 +172,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		break;
 	case S5P_MFC_CODEC_VC1RCV_DEC:
 	case S5P_MFC_CODEC_VC1_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else
 			ctx->scratch_buf_size =
@@ -189,7 +189,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank2.size = 0;
 		break;
 	case S5P_MFC_CODEC_H263_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else
 			ctx->scratch_buf_size =
@@ -201,7 +201,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank1.size = ctx->scratch_buf_size;
 		break;
 	case S5P_MFC_CODEC_VP8_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else if (IS_MFCV8_PLUS(dev))
 			ctx->scratch_buf_size =
@@ -230,7 +230,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			DEC_VP9_STATIC_BUFFER_SIZE;
 		break;
 	case S5P_MFC_CODEC_H264_ENC:
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 			ALIGN(ENC_V100_H264_ME_SIZE(mb_width, mb_height), 16);
@@ -254,7 +254,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		break;
 	case S5P_MFC_CODEC_MPEG4_ENC:
 	case S5P_MFC_CODEC_H263_ENC:
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 				ALIGN(ENC_V100_MPEG4_ME_SIZE(mb_width,
@@ -273,7 +273,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank2.size = 0;
 		break;
 	case S5P_MFC_CODEC_VP8_ENC:
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 				ALIGN(ENC_V100_VP8_ME_SIZE(mb_width, mb_height),
@@ -452,7 +452,7 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
 
 	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
 			ctx->codec_mode == S5P_MFC_CODEC_H264_MVC_DEC) {
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V10(ctx->img_width,
 					ctx->img_height);
 		} else {
@@ -668,7 +668,7 @@ static int s5p_mfc_set_enc_ref_buffer_v6(struct s5p_mfc_ctx *ctx)
 
 	mfc_debug(2, "Buf1: %p (%d)\n", (void *)buf_addr1, buf_size1);
 
-	if (IS_MFCV10(dev)) {
+	if (IS_MFCV10_PLUS(dev)) {
 		/* start address of per buffer is aligned */
 		for (i = 0; i < ctx->pb_count; i++) {
 			writel(buf_addr1, mfc_regs->e_luma_dpb + (4 * i));
@@ -2455,7 +2455,7 @@ const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev)
 	R(e_h264_options, S5P_FIMV_E_H264_OPTIONS_V8);
 	R(e_min_scratch_buffer_size, S5P_FIMV_E_MIN_SCRATCH_BUFFER_SIZE_V8);
 
-	if (!IS_MFCV10(dev))
+	if (!IS_MFCV10_PLUS(dev))
 		goto done;
 
 	/* Initialize registers used in MFC v10 only.
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:37 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:37 +0530
Subject: [Patch v5 03/11] media: s5p-mfc: Add initial support for MFCv12
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063114epcas5p4637c47d1bc778bf293fd9d98b89bbb8a@epcas5p4.samsung.com>
Message-ID: <20231206063045.97234-4-aakarsh.jain@samsung.com>

Add support for MFCv12, with a new register file and necessary hw
control, decoder, encoder and structural changes. Add luma dbp, chroma
dpb and mv sizes for each codec as per the UM for MFCv12, along with
appropriate alignment.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../platform/samsung/s5p-mfc/regs-mfc-v12.h   | 50 +++++++++++
 .../media/platform/samsung/s5p-mfc/s5p_mfc.c  | 30 +++++++
 .../platform/samsung/s5p-mfc/s5p_mfc_common.h | 15 +++-
 .../platform/samsung/s5p-mfc/s5p_mfc_ctrl.c   |  2 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_dec.c    |  6 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    |  5 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr.h    |  8 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 83 +++++++++++++++----
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h |  6 +-
 9 files changed, 170 insertions(+), 35 deletions(-)
 create mode 100644 drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h

diff --git a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
new file mode 100644
index 000000000000..d987bba1ffbd
--- /dev/null
+++ b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Register definition file for Samsung MFC V12.x Interface (FIMV) driver
+ *
+ * Copyright (c) 2020 Samsung Electronics Co., Ltd.
+ *     http://www.samsung.com/
+ */
+
+#ifndef _REGS_MFC_V12_H
+#define _REGS_MFC_V12_H
+
+#include <linux/sizes.h>
+#include "regs-mfc-v10.h"
+
+/* MFCv12 Context buffer sizes */
+#define MFC_CTX_BUF_SIZE_V12		(30 * SZ_1K)
+#define MFC_H264_DEC_CTX_BUF_SIZE_V12	(2 * SZ_1M)
+#define MFC_OTHER_DEC_CTX_BUF_SIZE_V12	(30 * SZ_1K)
+#define MFC_H264_ENC_CTX_BUF_SIZE_V12	(100 * SZ_1K)
+#define MFC_HEVC_ENC_CTX_BUF_SIZE_V12	(40 * SZ_1K)
+#define MFC_OTHER_ENC_CTX_BUF_SIZE_V12	(25 * SZ_1K)
+
+/* MFCv12 variant defines */
+#define MAX_FW_SIZE_V12			(SZ_1M)
+#define MAX_CPB_SIZE_V12		(7 * SZ_1M)
+#define MFC_VERSION_V12			0xC0
+#define MFC_NUM_PORTS_V12		1
+#define S5P_FIMV_CODEC_VP9_ENC		27
+
+/* Encoder buffer size for MFCv12 */
+#define ENC_V120_BASE_SIZE(x, y) \
+	((((x) + 3) * ((y) + 3) * 8) \
+	+ ((((y) * 64) + 2304) * ((x) + 7) / 8))
+
+#define ENC_V120_H264_ME_SIZE(x, y) \
+	ALIGN((ENC_V120_BASE_SIZE(x, y) \
+	+ (DIV_ROUND_UP((x) * (y), 64) * 32)), 256)
+
+#define ENC_V120_MPEG4_ME_SIZE(x, y) \
+	ALIGN((ENC_V120_BASE_SIZE(x, y) \
+	+ (DIV_ROUND_UP((x) * (y), 128) * 16)), 256)
+
+#define ENC_V120_VP8_ME_SIZE(x, y) \
+	ALIGN(ENC_V120_BASE_SIZE((x), (y)), 256)
+
+#define ENC_V120_HEVC_ME_SIZE(x, y)     \
+	ALIGN(((((x) + 3) * ((y) + 3) * 32)       \
+	+ ((((y) * 128) + 2304) * ((x) + 3) / 4)), 256)
+
+#endif /*_REGS_MFC_V12_H*/
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index e30e54935d79..dee9ef017997 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -790,6 +790,8 @@ static int s5p_mfc_open(struct file *file)
 	INIT_LIST_HEAD(&ctx->dst_queue);
 	ctx->src_queue_cnt = 0;
 	ctx->dst_queue_cnt = 0;
+	ctx->is_422 = 0;
+	ctx->is_10bit = 0;
 	/* Get context number */
 	ctx->num = 0;
 	while (dev->ctx[ctx->num]) {
@@ -1660,6 +1662,31 @@ static struct s5p_mfc_variant mfc_drvdata_v10 = {
 	.fw_name[0]     = "s5p-mfc-v10.fw",
 };
 
+static struct s5p_mfc_buf_size_v6 mfc_buf_size_v12 = {
+	.dev_ctx        = MFC_CTX_BUF_SIZE_V12,
+	.h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V12,
+	.other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V12,
+	.h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V12,
+	.hevc_enc_ctx   = MFC_HEVC_ENC_CTX_BUF_SIZE_V12,
+	.other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V12,
+};
+
+static struct s5p_mfc_buf_size buf_size_v12 = {
+	.fw     = MAX_FW_SIZE_V12,
+	.cpb    = MAX_CPB_SIZE_V12,
+	.priv   = &mfc_buf_size_v12,
+};
+
+static struct s5p_mfc_variant mfc_drvdata_v12 = {
+	.version        = MFC_VERSION_V12,
+	.version_bit    = MFC_V12_BIT,
+	.port_num       = MFC_NUM_PORTS_V12,
+	.buf_size       = &buf_size_v12,
+	.fw_name[0]     = "s5p-mfc-v12.fw",
+	.clk_names	= {"mfc"},
+	.num_clocks	= 1,
+};
+
 static const struct of_device_id exynos_mfc_match[] = {
 	{
 		.compatible = "samsung,mfc-v5",
@@ -1682,6 +1709,9 @@ static const struct of_device_id exynos_mfc_match[] = {
 	}, {
 		.compatible = "samsung,mfc-v10",
 		.data = &mfc_drvdata_v10,
+	}, {
+		.compatible = "tesla,fsd-mfc",
+		.data = &mfc_drvdata_v12,
 	},
 	{},
 };
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index 2ae2f23c4741..ba0990a6e6a8 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -19,7 +19,7 @@
 #include <media/v4l2-ioctl.h>
 #include <media/videobuf2-v4l2.h>
 #include "regs-mfc.h"
-#include "regs-mfc-v10.h"
+#include "regs-mfc-v12.h"
 
 #define S5P_MFC_NAME		"s5p-mfc"
 
@@ -720,6 +720,8 @@ struct s5p_mfc_ctx {
 	struct v4l2_ctrl *ctrls[MFC_MAX_CTRLS];
 	struct v4l2_ctrl_handler ctrl_handler;
 	size_t scratch_buf_size;
+	int is_10bit;
+	int is_422;
 };
 
 /*
@@ -775,6 +777,7 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq);
 #define IS_MFCV7_PLUS(dev)	((dev)->variant->version >= 0x70)
 #define IS_MFCV8_PLUS(dev)	((dev)->variant->version >= 0x80)
 #define IS_MFCV10_PLUS(dev)	((dev)->variant->version >= 0xA0)
+#define IS_MFCV12(dev)		((dev)->variant->version >= 0xC0)
 #define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10_PLUS(dev))
 
 #define MFC_V5_BIT	BIT(0)
@@ -782,11 +785,15 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq);
 #define MFC_V7_BIT	BIT(2)
 #define MFC_V8_BIT	BIT(3)
 #define MFC_V10_BIT	BIT(5)
+#define MFC_V12_BIT	BIT(7)
 
 #define MFC_V5PLUS_BITS		(MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT | \
-					MFC_V8_BIT | MFC_V10_BIT)
+					MFC_V8_BIT | MFC_V10_BIT | MFC_V12_BIT)
 #define MFC_V6PLUS_BITS		(MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT | \
-					MFC_V10_BIT)
-#define MFC_V7PLUS_BITS		(MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT)
+					MFC_V10_BIT | MFC_V12_BIT)
+#define MFC_V7PLUS_BITS		(MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT | \
+					MFC_V12_BIT)
+
+#define MFC_V10PLUS_BITS	(MFC_V10_BIT | MFC_V12_BIT)
 
 #endif /* S5P_MFC_COMMON_H_ */
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
index 54b54b2fa9b1..b49159142c53 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
@@ -130,7 +130,7 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
 			mfc_write(dev, 0, S5P_FIMV_REG_CLEAR_BEGIN_V6 + (i*4));
 
 		/* check bus reset control before reset */
-		if (dev->risc_on)
+		if (dev->risc_on && !IS_MFCV12(dev))
 			if (s5p_mfc_bus_reset(dev))
 				return -EIO;
 		/* Reset
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
index 268ffe4da53c..e219cbcd86d5 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
@@ -146,7 +146,7 @@ static struct s5p_mfc_fmt formats[] = {
 		.codec_mode	= S5P_FIMV_CODEC_HEVC_DEC,
 		.type		= MFC_FMT_DEC,
 		.num_planes	= 1,
-		.versions	= MFC_V10_BIT,
+		.versions	= MFC_V10PLUS_BITS,
 		.flags		= V4L2_FMT_FLAG_DYN_RESOLUTION |
 				  V4L2_FMT_FLAG_CONTINUOUS_BYTESTREAM,
 	},
@@ -155,7 +155,7 @@ static struct s5p_mfc_fmt formats[] = {
 		.codec_mode	= S5P_FIMV_CODEC_VP9_DEC,
 		.type		= MFC_FMT_DEC,
 		.num_planes	= 1,
-		.versions	= MFC_V10_BIT,
+		.versions	= MFC_V10PLUS_BITS,
 		.flags		= V4L2_FMT_FLAG_DYN_RESOLUTION,
 	},
 };
@@ -355,7 +355,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 		pix_mp->width = ctx->buf_width;
 		pix_mp->height = ctx->buf_height;
 		pix_mp->field = V4L2_FIELD_NONE;
-		pix_mp->num_planes = 2;
+		pix_mp->num_planes = ctx->dst_fmt->num_planes;
 		/* Set pixelformat to the format in which MFC
 		   outputs the decoded frame */
 		pix_mp->pixelformat = ctx->dst_fmt->fourcc;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index 4b4c129c09e7..d518e329ffbb 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -92,7 +92,7 @@ static struct s5p_mfc_fmt formats[] = {
 		.codec_mode	= S5P_FIMV_CODEC_HEVC_ENC,
 		.type		= MFC_FMT_ENC,
 		.num_planes	= 1,
-		.versions	= MFC_V10_BIT,
+		.versions	= MFC_V10PLUS_BITS,
 	},
 };
 
@@ -1179,7 +1179,8 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
 		if (FW_HAS_E_MIN_SCRATCH_BUF(dev)) {
 			ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
 					get_e_min_scratch_buf_size, dev);
-			ctx->bank1.size += ctx->scratch_buf_size;
+			if (!IS_MFCV12(dev))
+				ctx->bank1.size += ctx->scratch_buf_size;
 		}
 		ctx->state = MFCINST_HEAD_PRODUCED;
 	}
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
index b9831275f3ab..87ac56756a16 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
@@ -166,9 +166,9 @@ struct s5p_mfc_regs {
 	void __iomem *d_decoded_third_addr;/* only v7 */
 	void __iomem *d_used_dpb_flag_upper;/* v7 and v8 */
 	void __iomem *d_used_dpb_flag_lower;/* v7 and v8 */
-	void __iomem *d_min_scratch_buffer_size; /* v10 */
-	void __iomem *d_static_buffer_addr; /* v10 */
-	void __iomem *d_static_buffer_size; /* v10 */
+	void __iomem *d_min_scratch_buffer_size; /* v10 and v12 */
+	void __iomem *d_static_buffer_addr; /* v10 and v12 */
+	void __iomem *d_static_buffer_size; /* v10 and v12 */
 
 	/* encoder registers */
 	void __iomem *e_frame_width;
@@ -268,7 +268,7 @@ struct s5p_mfc_regs {
 	void __iomem *e_vp8_hierarchical_qp_layer0;/* v7 and v8 */
 	void __iomem *e_vp8_hierarchical_qp_layer1;/* v7 and v8 */
 	void __iomem *e_vp8_hierarchical_qp_layer2;/* v7 and v8 */
-	void __iomem *e_min_scratch_buffer_size; /* v10 */
+	void __iomem *e_min_scratch_buffer_size; /* v10 and v12 */
 	void __iomem *e_num_t_layer; /* v10 */
 	void __iomem *e_hier_qp_layer0; /* v10 */
 	void __iomem *e_hier_bit_rate_layer0; /* v10 */
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 882166e4ac50..a49aa6c1e30b 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -60,12 +60,14 @@ static void s5p_mfc_release_dec_desc_buffer_v6(struct s5p_mfc_ctx *ctx)
 static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	unsigned int mb_width, mb_height;
+	unsigned int mb_width, mb_height, width64, height32;
 	unsigned int lcu_width = 0, lcu_height = 0;
 	int ret;
 
 	mb_width = MB_WIDTH(ctx->img_width);
 	mb_height = MB_HEIGHT(ctx->img_height);
+	width64 = ALIGN(ctx->img_width, 64);
+	height32 = ALIGN(ctx->img_height, 32);
 
 	if (ctx->type == MFCINST_DECODER) {
 		mfc_debug(2, "Luma size:%d Chroma size:%d MV size:%d\n",
@@ -82,7 +84,39 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
 			ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
 			S5P_FIMV_TMV_BUFFER_ALIGN_V6);
-		if (IS_MFCV10_PLUS(dev)) {
+		if (IS_MFCV12(dev)) {
+			lcu_width = S5P_MFC_LCU_WIDTH(ctx->img_width);
+			lcu_height = S5P_MFC_LCU_HEIGHT(ctx->img_height);
+			if (ctx->codec_mode == S5P_FIMV_CODEC_HEVC_ENC && ctx->is_10bit) {
+				ctx->luma_dpb_size =
+					width64 * height32 +
+					ALIGN(DIV_ROUND_UP(lcu_width * 32, 4), 16) * height32 + 128;
+				if (ctx->is_422)
+					ctx->chroma_dpb_size =
+						ctx->luma_dpb_size;
+				else
+					ctx->chroma_dpb_size =
+						width64 * height32 / 2 +
+						ALIGN(DIV_ROUND_UP(lcu_width *
+							32, 4), 16) * height32 / 2 + 128;
+			} else if (ctx->codec_mode == S5P_FIMV_CODEC_VP9_ENC &&	ctx->is_10bit) {
+				ctx->luma_dpb_size =
+					ALIGN(ctx->img_width * 2, 128) * height32 + 64;
+				ctx->chroma_dpb_size =
+					ALIGN(ctx->img_width * 2, 128) * height32 / 2 + 64;
+			} else {
+				ctx->luma_dpb_size =
+					width64 * height32 + 64;
+				if (ctx->is_422)
+					ctx->chroma_dpb_size =
+						ctx->luma_dpb_size;
+				else
+					ctx->chroma_dpb_size =
+						width64 * height32 / 2 + 64;
+			}
+			ctx->luma_dpb_size = ALIGN(ctx->luma_dpb_size + 256, SZ_2K);
+			ctx->chroma_dpb_size = ALIGN(ctx->chroma_dpb_size + 256, SZ_2K);
+		} else if (IS_MFCV10_PLUS(dev)) {
 			lcu_width = S5P_MFC_LCU_WIDTH(ctx->img_width);
 			lcu_height = S5P_MFC_LCU_HEIGHT(ctx->img_height);
 			if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
@@ -230,7 +264,11 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			DEC_VP9_STATIC_BUFFER_SIZE;
 		break;
 	case S5P_MFC_CODEC_H264_ENC:
-		if (IS_MFCV10_PLUS(dev)) {
+		if (IS_MFCV12(dev)) {
+			mfc_debug(2, "Use min scratch buffer size\n");
+			ctx->me_buffer_size =
+				ENC_V120_H264_ME_SIZE(mb_width, mb_height);
+		} else if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 			ALIGN(ENC_V100_H264_ME_SIZE(mb_width, mb_height), 16);
@@ -254,7 +292,11 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		break;
 	case S5P_MFC_CODEC_MPEG4_ENC:
 	case S5P_MFC_CODEC_H263_ENC:
-		if (IS_MFCV10_PLUS(dev)) {
+		if (IS_MFCV12(dev)) {
+			mfc_debug(2, "Use min scratch buffer size\n");
+			ctx->me_buffer_size =
+				ENC_V120_MPEG4_ME_SIZE(mb_width, mb_height);
+		} else if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 				ALIGN(ENC_V100_MPEG4_ME_SIZE(mb_width,
@@ -265,7 +307,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 						mb_width,
 						mb_height);
 		ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size,
-				S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);
+					S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);
 		ctx->bank1.size =
 			ctx->scratch_buf_size + ctx->tmv_buffer_size +
 			(ctx->pb_count * (ctx->luma_dpb_size +
@@ -273,7 +315,11 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank2.size = 0;
 		break;
 	case S5P_MFC_CODEC_VP8_ENC:
-		if (IS_MFCV10_PLUS(dev)) {
+		if (IS_MFCV12(dev)) {
+			mfc_debug(2, "Use min scratch buffer size\n");
+			ctx->me_buffer_size =
+				ENC_V120_VP8_ME_SIZE(mb_width, mb_height);
+		} else if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 				ALIGN(ENC_V100_VP8_ME_SIZE(mb_width, mb_height),
@@ -297,9 +343,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank2.size = 0;
 		break;
 	case S5P_MFC_CODEC_HEVC_ENC:
+		if (IS_MFCV12(dev))
+			ctx->me_buffer_size =
+				ENC_V120_HEVC_ME_SIZE(lcu_width, lcu_height);
+		else
+			ctx->me_buffer_size =
+				ALIGN(ENC_V100_HEVC_ME_SIZE(lcu_width, lcu_height), 16);
 		mfc_debug(2, "Use min scratch buffer size\n");
-		ctx->me_buffer_size =
-			ALIGN(ENC_V100_HEVC_ME_SIZE(lcu_width, lcu_height), 16);
 		ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size, 256);
 		ctx->bank1.size =
 			ctx->scratch_buf_size + ctx->tmv_buffer_size +
@@ -452,16 +502,15 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
 
 	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
 			ctx->codec_mode == S5P_MFC_CODEC_H264_MVC_DEC) {
-		if (IS_MFCV10_PLUS(dev)) {
-			ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V10(ctx->img_width,
-					ctx->img_height);
-		} else {
-			ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V6(ctx->img_width,
-					ctx->img_height);
-		}
+		if (IS_MFCV12(dev))
+			ctx->mv_size = S5P_MFC_DEC_MV_SIZE(ctx->img_width, ctx->img_height, 1024);
+		else if (IS_MFCV10_PLUS(dev))
+			ctx->mv_size = S5P_MFC_DEC_MV_SIZE(ctx->img_width, ctx->img_height, 512);
+		else
+			ctx->mv_size = S5P_MFC_DEC_MV_SIZE(ctx->img_width, ctx->img_height, 128);
+
 	} else if (ctx->codec_mode == S5P_MFC_CODEC_HEVC_DEC) {
-		ctx->mv_size = s5p_mfc_dec_hevc_mv_size(ctx->img_width,
-				ctx->img_height);
+		ctx->mv_size = s5p_mfc_dec_hevc_mv_size(ctx->img_width, ctx->img_height);
 		ctx->mv_size = ALIGN(ctx->mv_size, 32);
 	} else {
 		ctx->mv_size = 0;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
index e4dd03c5454c..ff582eea4217 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
@@ -19,10 +19,8 @@
 
 #define MB_WIDTH(x_size)		DIV_ROUND_UP(x_size, 16)
 #define MB_HEIGHT(y_size)		DIV_ROUND_UP(y_size, 16)
-#define S5P_MFC_DEC_MV_SIZE_V6(x, y)	(MB_WIDTH(x) * \
-					(((MB_HEIGHT(y)+1)/2)*2) * 64 + 128)
-#define S5P_MFC_DEC_MV_SIZE_V10(x, y)	(MB_WIDTH(x) * \
-					(((MB_HEIGHT(y)+1)/2)*2) * 64 + 512)
+#define S5P_MFC_DEC_MV_SIZE(x, y, offset)	(MB_WIDTH(x) * \
+					(((MB_HEIGHT(y) + 1) / 2) * 2) * 64 + (offset))
 #define S5P_MFC_LCU_WIDTH(x_size)	DIV_ROUND_UP(x_size, 32)
 #define S5P_MFC_LCU_HEIGHT(y_size)	DIV_ROUND_UP(y_size, 32)
 
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:38 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:38 +0530
Subject: [Patch v5 04/11] media: s5p-mfc: Add YV12 and I420 multiplanar
 format support
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063117epcas5p251b8b355642fa50678802d72d0ca3556@epcas5p2.samsung.com>
Message-ID: <20231206063045.97234-5-aakarsh.jain@samsung.com>

YV12 and I420 format (3-plane) support is added. Stride information is
added to all formats and planes since it is necessary for YV12/I420
which are different from width.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../platform/samsung/s5p-mfc/regs-mfc-v12.h   |   2 +
 .../platform/samsung/s5p-mfc/regs-mfc-v7.h    |   1 +
 .../platform/samsung/s5p-mfc/regs-mfc-v8.h    |   3 +
 .../platform/samsung/s5p-mfc/s5p_mfc_common.h |   4 +
 .../platform/samsung/s5p-mfc/s5p_mfc_dec.c    |  54 +++++-
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    |  97 +++++++++--
 .../platform/samsung/s5p-mfc/s5p_mfc_opr.h    |   6 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c |  12 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 157 ++++++++++++++----
 9 files changed, 273 insertions(+), 63 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
index d987bba1ffbd..24e669d8ea29 100644
--- a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
+++ b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
@@ -26,6 +26,8 @@
 #define MFC_VERSION_V12			0xC0
 #define MFC_NUM_PORTS_V12		1
 #define S5P_FIMV_CODEC_VP9_ENC		27
+#define MFC_CHROMA_PAD_BYTES_V12        256
+#define S5P_FIMV_D_ALIGN_PLANE_SIZE_V12 256
 
 /* Encoder buffer size for MFCv12 */
 #define ENC_V120_BASE_SIZE(x, y) \
diff --git a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v7.h b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v7.h
index 4a7adfdaa359..50f9bf0603c1 100644
--- a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v7.h
+++ b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v7.h
@@ -24,6 +24,7 @@
 
 #define S5P_FIMV_E_ENCODED_SOURCE_FIRST_ADDR_V7		0xfa70
 #define S5P_FIMV_E_ENCODED_SOURCE_SECOND_ADDR_V7	0xfa74
+#define S5P_FIMV_E_ENCODED_SOURCE_THIRD_ADDR_V7		0xfa78
 
 #define S5P_FIMV_E_VP8_OPTIONS_V7			0xfdb0
 #define S5P_FIMV_E_VP8_FILTER_OPTIONS_V7		0xfdb4
diff --git a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v8.h b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v8.h
index 162e3c7e920f..0ef9eb2dff22 100644
--- a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v8.h
+++ b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v8.h
@@ -17,13 +17,16 @@
 #define S5P_FIMV_D_MIN_SCRATCH_BUFFER_SIZE_V8	0xf108
 #define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8	0xf144
 #define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V8	0xf148
+#define S5P_FIMV_D_THIRD_PLANE_DPB_SIZE_V8	0xf14C
 #define S5P_FIMV_D_MV_BUFFER_SIZE_V8		0xf150
 
 #define S5P_FIMV_D_FIRST_PLANE_DPB_STRIDE_SIZE_V8	0xf138
 #define S5P_FIMV_D_SECOND_PLANE_DPB_STRIDE_SIZE_V8	0xf13c
+#define S5P_FIMV_D_THIRD_PLANE_DPB_STRIDE_SIZE_V8	0xf140
 
 #define S5P_FIMV_D_FIRST_PLANE_DPB_V8		0xf160
 #define S5P_FIMV_D_SECOND_PLANE_DPB_V8		0xf260
+#define S5P_FIMV_D_THIRD_PLANE_DPB_V8		0xf360
 #define S5P_FIMV_D_MV_BUFFER_V8			0xf460
 
 #define S5P_FIMV_D_NUM_MV_V8			0xf134
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index ba0990a6e6a8..23ff2817b76d 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -56,6 +56,7 @@
 #define MFC_NO_INSTANCE_SET	-1
 #define MFC_ENC_CAP_PLANE_COUNT	1
 #define MFC_ENC_OUT_PLANE_COUNT	2
+#define VB2_MAX_PLANE_COUNT	3
 #define STUFF_BYTE		4
 #define MFC_MAX_CTRLS		128
 
@@ -181,6 +182,7 @@ struct s5p_mfc_buf {
 		struct {
 			size_t luma;
 			size_t chroma;
+			size_t chroma_1;
 		} raw;
 		size_t stream;
 	} cookie;
@@ -657,6 +659,7 @@ struct s5p_mfc_ctx {
 
 	int luma_size;
 	int chroma_size;
+	int chroma_size_1;
 	int mv_size;
 
 	unsigned long consumed_stream;
@@ -722,6 +725,7 @@ struct s5p_mfc_ctx {
 	size_t scratch_buf_size;
 	int is_10bit;
 	int is_422;
+	int stride[VB2_MAX_PLANE_COUNT];
 };
 
 /*
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
index e219cbcd86d5..3957f28d4547 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
@@ -56,6 +56,20 @@ static struct s5p_mfc_fmt formats[] = {
 		.num_planes	= 2,
 		.versions	= MFC_V6PLUS_BITS,
 	},
+	{
+		.fourcc         = V4L2_PIX_FMT_YUV420M,
+		.codec_mode     = S5P_MFC_CODEC_NONE,
+		.type           = MFC_FMT_RAW,
+		.num_planes     = 3,
+		.versions       = MFC_V12_BIT,
+	},
+	{
+		.fourcc         = V4L2_PIX_FMT_YVU420M,
+		.codec_mode     = S5P_MFC_CODEC_NONE,
+		.type           = MFC_FMT_RAW,
+		.num_planes     = 3,
+		.versions       = MFC_V12_BIT
+	},
 	{
 		.fourcc		= V4L2_PIX_FMT_H264,
 		.codec_mode	= S5P_MFC_CODEC_H264_DEC,
@@ -359,10 +373,15 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 		/* Set pixelformat to the format in which MFC
 		   outputs the decoded frame */
 		pix_mp->pixelformat = ctx->dst_fmt->fourcc;
-		pix_mp->plane_fmt[0].bytesperline = ctx->buf_width;
+		pix_mp->plane_fmt[0].bytesperline = ctx->stride[0];
 		pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
-		pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
+		pix_mp->plane_fmt[1].bytesperline = ctx->stride[1];
 		pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			pix_mp->plane_fmt[2].bytesperline = ctx->stride[2];
+			pix_mp->plane_fmt[2].sizeimage = ctx->chroma_size_1;
+		}
 	} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 		/* This is run on OUTPUT
 		   The buffer contains compressed image
@@ -920,6 +939,7 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
 {
 	struct s5p_mfc_ctx *ctx = fh_to_ctx(vq->drv_priv);
 	struct s5p_mfc_dev *dev = ctx->dev;
+	const struct v4l2_format_info *format;
 
 	/* Video output for decoding (source)
 	 * this can be set after getting an instance */
@@ -936,7 +956,13 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
 	} else if (ctx->state == MFCINST_HEAD_PARSED &&
 		   vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 		/* Output plane count is 2 - one for Y and one for CbCr */
-		*plane_count = 2;
+		format = v4l2_format_info(ctx->dst_fmt->fourcc);
+		if (!format) {
+			mfc_err("invalid format\n");
+			return -EINVAL;
+		}
+		*plane_count = format->comp_planes;
+
 		/* Setup buffer count */
 		if (*buf_count < ctx->pb_count)
 			*buf_count = ctx->pb_count;
@@ -955,14 +981,18 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
 	    vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 		psize[0] = ctx->luma_size;
 		psize[1] = ctx->chroma_size;
-
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			psize[2] = ctx->chroma_size_1;
 		if (IS_MFCV6_PLUS(dev))
 			alloc_devs[0] = ctx->dev->mem_dev[BANK_L_CTX];
 		else
 			alloc_devs[0] = ctx->dev->mem_dev[BANK_R_CTX];
 		alloc_devs[1] = ctx->dev->mem_dev[BANK_L_CTX];
-	} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE &&
-		   ctx->state == MFCINST_INIT) {
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			alloc_devs[2] = ctx->dev->mem_dev[BANK_L_CTX];
+	} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && ctx->state == MFCINST_INIT) {
 		psize[0] = ctx->dec_src_buf_size;
 		alloc_devs[0] = ctx->dev->mem_dev[BANK_L_CTX];
 	} else {
@@ -994,12 +1024,24 @@ static int s5p_mfc_buf_init(struct vb2_buffer *vb)
 			mfc_err("Plane buffer (CAPTURE) is too small\n");
 			return -EINVAL;
 		}
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			if (vb2_plane_size(vb, 2) < ctx->chroma_size_1) {
+				mfc_err("Plane buffer (CAPTURE) is too small\n");
+				return -EINVAL;
+			}
+		}
 		i = vb->index;
 		ctx->dst_bufs[i].b = vbuf;
 		ctx->dst_bufs[i].cookie.raw.luma =
 					vb2_dma_contig_plane_dma_addr(vb, 0);
 		ctx->dst_bufs[i].cookie.raw.chroma =
 					vb2_dma_contig_plane_dma_addr(vb, 1);
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			ctx->dst_bufs[i].cookie.raw.chroma_1 =
+					vb2_dma_contig_plane_dma_addr(vb, 2);
+		}
 		ctx->dst_bufs_cnt++;
 	} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 		if (IS_ERR_OR_NULL(ERR_PTR(
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index d518e329ffbb..6b495a738291 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -59,6 +59,20 @@ static struct s5p_mfc_fmt formats[] = {
 		.num_planes	= 2,
 		.versions	= MFC_V6PLUS_BITS,
 	},
+	{
+		.fourcc         = V4L2_PIX_FMT_YUV420M,
+		.codec_mode     = S5P_MFC_CODEC_NONE,
+		.type           = MFC_FMT_RAW,
+		.num_planes     = 3,
+		.versions       = MFC_V12_BIT,
+	},
+	{
+		.fourcc         = V4L2_PIX_FMT_YVU420M,
+		.codec_mode     = S5P_MFC_CODEC_NONE,
+		.type           = MFC_FMT_RAW,
+		.num_planes     = 3,
+		.versions       = MFC_V12_BIT,
+	},
 	{
 		.fourcc		= V4L2_PIX_FMT_H264,
 		.codec_mode	= S5P_MFC_CODEC_H264_ENC,
@@ -1193,14 +1207,20 @@ static int enc_pre_frame_start(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	struct s5p_mfc_buf *dst_mb;
 	struct s5p_mfc_buf *src_mb;
-	unsigned long src_y_addr, src_c_addr, dst_addr;
+	unsigned long src_y_addr, src_c_addr, src_c_1_addr, dst_addr;
 	unsigned int dst_size;
 
 	src_mb = list_entry(ctx->src_queue.next, struct s5p_mfc_buf, list);
 	src_y_addr = vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 0);
 	src_c_addr = vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 1);
+	if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+			V4L2_PIX_FMT_YVU420M)
+		src_c_1_addr =
+			vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 2);
+	else
+		src_c_1_addr = 0;
 	s5p_mfc_hw_call(dev->mfc_ops, set_enc_frame_buffer, ctx,
-							src_y_addr, src_c_addr);
+					src_y_addr, src_c_addr, src_c_1_addr);
 
 	dst_mb = list_entry(ctx->dst_queue.next, struct s5p_mfc_buf, list);
 	dst_addr = vb2_dma_contig_plane_dma_addr(&dst_mb->b->vb2_buf, 0);
@@ -1215,8 +1235,8 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	struct s5p_mfc_buf *mb_entry;
-	unsigned long enc_y_addr = 0, enc_c_addr = 0;
-	unsigned long mb_y_addr, mb_c_addr;
+	unsigned long enc_y_addr = 0, enc_c_addr = 0, enc_c_1_addr = 0;
+	unsigned long mb_y_addr, mb_c_addr, mb_c_1_addr;
 	int slice_type;
 	unsigned int strm_size;
 	bool src_ready;
@@ -1229,18 +1249,26 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
 		  mfc_read(dev, S5P_FIMV_ENC_SI_PIC_CNT));
 	if (slice_type >= 0) {
 		s5p_mfc_hw_call(dev->mfc_ops, get_enc_frame_buffer, ctx,
-				&enc_y_addr, &enc_c_addr);
+				&enc_y_addr, &enc_c_addr, &enc_c_1_addr);
 		list_for_each_entry(mb_entry, &ctx->src_queue, list) {
 			mb_y_addr = vb2_dma_contig_plane_dma_addr(
 					&mb_entry->b->vb2_buf, 0);
 			mb_c_addr = vb2_dma_contig_plane_dma_addr(
 					&mb_entry->b->vb2_buf, 1);
-			if ((enc_y_addr == mb_y_addr) &&
-						(enc_c_addr == mb_c_addr)) {
+			if (ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YUV420M ||
+					ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YVU420M)
+				mb_c_1_addr = vb2_dma_contig_plane_dma_addr
+					(&mb_entry->b->vb2_buf, 2);
+			else
+				mb_c_1_addr = 0;
+			if (enc_y_addr == mb_y_addr && enc_c_addr == mb_c_addr && enc_c_1_addr
+					== mb_c_1_addr) {
 				list_del(&mb_entry->list);
 				ctx->src_queue_cnt--;
 				vb2_buffer_done(&mb_entry->b->vb2_buf,
-							VB2_BUF_STATE_DONE);
+						VB2_BUF_STATE_DONE);
 				break;
 			}
 		}
@@ -1249,20 +1277,27 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
 					&mb_entry->b->vb2_buf, 0);
 			mb_c_addr = vb2_dma_contig_plane_dma_addr(
 					&mb_entry->b->vb2_buf, 1);
-			if ((enc_y_addr == mb_y_addr) &&
-						(enc_c_addr == mb_c_addr)) {
+			if (ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YUV420M ||
+					ctx->src_fmt->fourcc == V4L2_PIX_FMT_YVU420M)
+				mb_c_1_addr = vb2_dma_contig_plane_dma_addr(&
+						mb_entry->b->vb2_buf, 2);
+			else
+				mb_c_1_addr = 0;
+			if (enc_y_addr == mb_y_addr && enc_c_addr == mb_c_addr && enc_c_1_addr
+					== mb_c_1_addr) {
 				list_del(&mb_entry->list);
 				ctx->ref_queue_cnt--;
 				vb2_buffer_done(&mb_entry->b->vb2_buf,
-							VB2_BUF_STATE_DONE);
+						VB2_BUF_STATE_DONE);
 				break;
 			}
 		}
 	}
 	if (ctx->src_queue_cnt > 0 && (ctx->state == MFCINST_RUNNING ||
-				       ctx->state == MFCINST_FINISHING)) {
+				ctx->state == MFCINST_FINISHING)) {
 		mb_entry = list_entry(ctx->src_queue.next, struct s5p_mfc_buf,
-									list);
+				list);
 		if (mb_entry->flags & MFC_BUF_FLAG_USED) {
 			list_del(&mb_entry->list);
 			ctx->src_queue_cnt--;
@@ -1381,10 +1416,15 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 		pix_fmt_mp->pixelformat = ctx->src_fmt->fourcc;
 		pix_fmt_mp->num_planes = ctx->src_fmt->num_planes;
 
-		pix_fmt_mp->plane_fmt[0].bytesperline = ctx->buf_width;
+		pix_fmt_mp->plane_fmt[0].bytesperline = ctx->stride[0];
 		pix_fmt_mp->plane_fmt[0].sizeimage = ctx->luma_size;
-		pix_fmt_mp->plane_fmt[1].bytesperline = ctx->buf_width;
+		pix_fmt_mp->plane_fmt[1].bytesperline = ctx->stride[1];
 		pix_fmt_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+		if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			pix_fmt_mp->plane_fmt[2].bytesperline = ctx->stride[2];
+			pix_fmt_mp->plane_fmt[2].sizeimage = ctx->chroma_size_1;
+		}
 	} else {
 		mfc_err("invalid buf type\n");
 		return -EINVAL;
@@ -1468,9 +1508,14 @@ static int vidioc_s_fmt(struct file *file, void *priv, struct v4l2_format *f)
 
 		s5p_mfc_hw_call(dev->mfc_ops, enc_calc_src_size, ctx);
 		pix_fmt_mp->plane_fmt[0].sizeimage = ctx->luma_size;
-		pix_fmt_mp->plane_fmt[0].bytesperline = ctx->buf_width;
+		pix_fmt_mp->plane_fmt[0].bytesperline = ctx->stride[0];
 		pix_fmt_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
-		pix_fmt_mp->plane_fmt[1].bytesperline = ctx->buf_width;
+		pix_fmt_mp->plane_fmt[1].bytesperline = ctx->stride[1];
+		if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			pix_fmt_mp->plane_fmt[2].bytesperline = ctx->stride[2];
+			pix_fmt_mp->plane_fmt[2].sizeimage = ctx->chroma_size_1;
+		}
 
 		ctx->src_bufs_cnt = 0;
 		ctx->output_state = QUEUE_FREE;
@@ -2414,10 +2459,17 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
 
 		psize[0] = ctx->luma_size;
 		psize[1] = ctx->chroma_size;
+		if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			psize[2] = ctx->chroma_size_1;
 
 		if (IS_MFCV6_PLUS(dev)) {
 			alloc_devs[0] = ctx->dev->mem_dev[BANK_L_CTX];
 			alloc_devs[1] = ctx->dev->mem_dev[BANK_L_CTX];
+			if (ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+				alloc_devs[2] = ctx->dev->mem_dev[BANK_L_CTX];
 		} else {
 			alloc_devs[0] = ctx->dev->mem_dev[BANK_R_CTX];
 			alloc_devs[1] = ctx->dev->mem_dev[BANK_R_CTX];
@@ -2456,6 +2508,11 @@ static int s5p_mfc_buf_init(struct vb2_buffer *vb)
 					vb2_dma_contig_plane_dma_addr(vb, 0);
 		ctx->src_bufs[i].cookie.raw.chroma =
 					vb2_dma_contig_plane_dma_addr(vb, 1);
+		if (ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			ctx->src_bufs[i].cookie.raw.chroma_1 =
+					vb2_dma_contig_plane_dma_addr(vb, 2);
 		ctx->src_bufs_cnt++;
 	} else {
 		mfc_err("invalid queue type: %d\n", vq->type);
@@ -2493,6 +2550,12 @@ static int s5p_mfc_buf_prepare(struct vb2_buffer *vb)
 			mfc_err("plane size is too small for output\n");
 			return -EINVAL;
 		}
+		if ((ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M ||
+		     ctx->src_fmt->fourcc == V4L2_PIX_FMT_YVU420M) &&
+		    (vb2_plane_size(vb, 2) < ctx->chroma_size_1)) {
+			mfc_err("plane size is too small for output\n");
+			return -EINVAL;
+		}
 	} else {
 		mfc_err("invalid queue type: %d\n", vq->type);
 		return -EINVAL;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
index 87ac56756a16..7c5e851c8191 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
@@ -293,9 +293,11 @@ struct s5p_mfc_hw_ops {
 	int (*set_enc_stream_buffer)(struct s5p_mfc_ctx *ctx,
 			unsigned long addr, unsigned int size);
 	void (*set_enc_frame_buffer)(struct s5p_mfc_ctx *ctx,
-			unsigned long y_addr, unsigned long c_addr);
+			unsigned long y_addr, unsigned long c_addr,
+			unsigned long c_1_addr);
 	void (*get_enc_frame_buffer)(struct s5p_mfc_ctx *ctx,
-			unsigned long *y_addr, unsigned long *c_addr);
+			unsigned long *y_addr, unsigned long *c_addr,
+			unsigned long *c_1_addr);
 	void (*try_run)(struct s5p_mfc_dev *dev);
 	void (*clear_int_flags)(struct s5p_mfc_dev *dev);
 	int (*get_dspl_y_adr)(struct s5p_mfc_dev *dev);
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
index 28a06dc343fd..fcfaf125a5a1 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
@@ -516,7 +516,8 @@ static int s5p_mfc_set_enc_stream_buffer_v5(struct s5p_mfc_ctx *ctx,
 }
 
 static void s5p_mfc_set_enc_frame_buffer_v5(struct s5p_mfc_ctx *ctx,
-		unsigned long y_addr, unsigned long c_addr)
+		unsigned long y_addr, unsigned long c_addr,
+		unsigned long c_1_addr)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 
@@ -525,7 +526,8 @@ static void s5p_mfc_set_enc_frame_buffer_v5(struct s5p_mfc_ctx *ctx,
 }
 
 static void s5p_mfc_get_enc_frame_buffer_v5(struct s5p_mfc_ctx *ctx,
-		unsigned long *y_addr, unsigned long *c_addr)
+		unsigned long *y_addr, unsigned long *c_addr,
+		unsigned long *c_1_addr)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 
@@ -1210,7 +1212,7 @@ static int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 	if (list_empty(&ctx->src_queue)) {
 		/* send null frame */
 		s5p_mfc_set_enc_frame_buffer_v5(ctx, dev->dma_base[BANK_R_CTX],
-						dev->dma_base[BANK_R_CTX]);
+						dev->dma_base[BANK_R_CTX], 0);
 		src_mb = NULL;
 	} else {
 		src_mb = list_entry(ctx->src_queue.next, struct s5p_mfc_buf,
@@ -1220,7 +1222,7 @@ static int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 			/* send null frame */
 			s5p_mfc_set_enc_frame_buffer_v5(ctx,
 						dev->dma_base[BANK_R_CTX],
-						dev->dma_base[BANK_R_CTX]);
+						dev->dma_base[BANK_R_CTX], 0);
 			ctx->state = MFCINST_FINISHING;
 		} else {
 			src_y_addr = vb2_dma_contig_plane_dma_addr(
@@ -1228,7 +1230,7 @@ static int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 			src_c_addr = vb2_dma_contig_plane_dma_addr(
 					&src_mb->b->vb2_buf, 1);
 			s5p_mfc_set_enc_frame_buffer_v5(ctx, src_y_addr,
-								src_c_addr);
+								src_c_addr, 0);
 			if (src_mb->flags & MFC_BUF_FLAG_EOS)
 				ctx->state = MFCINST_FINISHING;
 		}
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index a49aa6c1e30b..36aebca11313 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -488,16 +488,35 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	ctx->buf_width = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
 	ctx->buf_height = ALIGN(ctx->img_height, S5P_FIMV_NV12MT_VALIGN_V6);
+	ctx->chroma_size_1 = 0;
 	mfc_debug(2, "SEQ Done: Movie dimensions %dx%d,\n"
 			"buffer dimensions: %dx%d\n", ctx->img_width,
 			ctx->img_height, ctx->buf_width, ctx->buf_height);
 
-	ctx->luma_size = calc_plane(ctx->img_width, ctx->img_height);
-	ctx->chroma_size = calc_plane(ctx->img_width, (ctx->img_height >> 1));
+	switch (ctx->dst_fmt->fourcc) {
+	case V4L2_PIX_FMT_NV12M:
+	case V4L2_PIX_FMT_NV21M:
+		ctx->stride[0] = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->stride[1] = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->luma_size = calc_plane(ctx->stride[0], ctx->img_height);
+		ctx->chroma_size = calc_plane(ctx->stride[1], (ctx->img_height / 2));
+		break;
+	case V4L2_PIX_FMT_YUV420M:
+	case V4L2_PIX_FMT_YVU420M:
+		ctx->stride[0] = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->stride[1] = ALIGN(ctx->img_width / 2, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->stride[2] = ALIGN(ctx->img_width / 2, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->luma_size = calc_plane(ctx->stride[0], ctx->img_height);
+		ctx->chroma_size = calc_plane(ctx->stride[1], (ctx->img_height / 2));
+		ctx->chroma_size_1 = calc_plane(ctx->stride[2], (ctx->img_height / 2));
+		break;
+	}
+
 	if (IS_MFCV8_PLUS(ctx->dev)) {
 		/* MFCv8 needs additional 64 bytes for luma,chroma dpb*/
 		ctx->luma_size += S5P_FIMV_D_ALIGN_PLANE_SIZE_V8;
 		ctx->chroma_size += S5P_FIMV_D_ALIGN_PLANE_SIZE_V8;
+		ctx->chroma_size_1 += S5P_FIMV_D_ALIGN_PLANE_SIZE_V8;
 	}
 
 	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
@@ -524,14 +543,40 @@ static void s5p_mfc_enc_calc_src_size_v6(struct s5p_mfc_ctx *ctx)
 	mb_width = MB_WIDTH(ctx->img_width);
 	mb_height = MB_HEIGHT(ctx->img_height);
 
-	ctx->buf_width = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
-	ctx->luma_size = ALIGN((mb_width * mb_height) * 256, 256);
-	ctx->chroma_size = ALIGN((mb_width * mb_height) * 128, 256);
-
-	/* MFCv7 needs pad bytes for Luma and Chroma */
-	if (IS_MFCV7_PLUS(ctx->dev)) {
+	if (IS_MFCV12(ctx->dev)) {
+		switch (ctx->src_fmt->fourcc) {
+		case V4L2_PIX_FMT_NV12M:
+		case V4L2_PIX_FMT_NV21M:
+			ctx->stride[0] = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->stride[1] = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->luma_size = ctx->stride[0] * ALIGN(ctx->img_height, 16);
+			ctx->chroma_size =  ctx->stride[0] * ALIGN(ctx->img_height / 2, 16);
+			break;
+		case V4L2_PIX_FMT_YUV420M:
+		case V4L2_PIX_FMT_YVU420M:
+			ctx->stride[0] = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->stride[1] = ALIGN(ctx->img_width / 2, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->stride[2] = ALIGN(ctx->img_width / 2, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->luma_size = ctx->stride[0] * ALIGN(ctx->img_height, 16);
+			ctx->chroma_size =  ctx->stride[1] * ALIGN(ctx->img_height / 2, 16);
+			ctx->chroma_size_1 =  ctx->stride[2] * ALIGN(ctx->img_height / 2, 16);
+			break;
+		}
 		ctx->luma_size += MFC_LUMA_PAD_BYTES_V7;
-		ctx->chroma_size += MFC_CHROMA_PAD_BYTES_V7;
+		ctx->chroma_size += MFC_CHROMA_PAD_BYTES_V12;
+		ctx->chroma_size_1 += MFC_CHROMA_PAD_BYTES_V12;
+	} else {
+		ctx->buf_width = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
+		ctx->stride[0] = ctx->buf_width;
+		ctx->stride[1] = ctx->buf_width;
+		ctx->luma_size = ALIGN((mb_width * mb_height) * 256, 256);
+		ctx->chroma_size = ALIGN((mb_width * mb_height) * 128, 256);
+		ctx->chroma_size_1 = 0;
+		/* MFCv7 needs pad bytes for Luma and Chroma */
+		if (IS_MFCV7_PLUS(ctx->dev)) {
+			ctx->luma_size += MFC_LUMA_PAD_BYTES_V7;
+			ctx->chroma_size += MFC_LUMA_PAD_BYTES_V7;
+		}
 	}
 }
 
@@ -578,15 +623,18 @@ static int s5p_mfc_set_dec_frame_buffer_v6(struct s5p_mfc_ctx *ctx)
 	writel(ctx->total_dpb_count, mfc_regs->d_num_dpb);
 	writel(ctx->luma_size, mfc_regs->d_first_plane_dpb_size);
 	writel(ctx->chroma_size, mfc_regs->d_second_plane_dpb_size);
-
+	if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+			V4L2_PIX_FMT_YVU420M)
+		writel(ctx->chroma_size_1, mfc_regs->d_third_plane_dpb_size);
 	writel(buf_addr1, mfc_regs->d_scratch_buffer_addr);
 	writel(ctx->scratch_buf_size, mfc_regs->d_scratch_buffer_size);
 
 	if (IS_MFCV8_PLUS(dev)) {
-		writel(ctx->img_width,
-			mfc_regs->d_first_plane_dpb_stride_size);
-		writel(ctx->img_width,
-			mfc_regs->d_second_plane_dpb_stride_size);
+		writel(ctx->stride[0], mfc_regs->d_first_plane_dpb_stride_size);
+		writel(ctx->stride[1], mfc_regs->d_second_plane_dpb_stride_size);
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			writel(ctx->stride[2], mfc_regs->d_third_plane_dpb_stride_size);
 	}
 
 	buf_addr1 += ctx->scratch_buf_size;
@@ -615,6 +663,13 @@ static int s5p_mfc_set_dec_frame_buffer_v6(struct s5p_mfc_ctx *ctx)
 					ctx->dst_bufs[i].cookie.raw.chroma);
 		writel(ctx->dst_bufs[i].cookie.raw.chroma,
 				mfc_regs->d_second_plane_dpb + i * 4);
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			mfc_debug(2, "\tChroma_1 %d: %zx\n", i, ctx
+					->dst_bufs[i].cookie.raw.chroma_1);
+			writel(ctx->dst_bufs[i].cookie.raw.chroma_1, mfc_regs->d_third_plane_dpb +
+					i * 4);
+		}
 	}
 	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
 			ctx->codec_mode == S5P_MFC_CODEC_H264_MVC_DEC ||
@@ -673,20 +728,24 @@ static int s5p_mfc_set_enc_stream_buffer_v6(struct s5p_mfc_ctx *ctx,
 }
 
 static void s5p_mfc_set_enc_frame_buffer_v6(struct s5p_mfc_ctx *ctx,
-		unsigned long y_addr, unsigned long c_addr)
+		unsigned long y_addr, unsigned long c_addr,
+		unsigned long c_1_addr)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
 
 	writel(y_addr, mfc_regs->e_source_first_plane_addr);
 	writel(c_addr, mfc_regs->e_source_second_plane_addr);
+	writel(c_1_addr, mfc_regs->e_source_third_plane_addr);
 
 	mfc_debug(2, "enc src y buf addr: 0x%08lx\n", y_addr);
 	mfc_debug(2, "enc src c buf addr: 0x%08lx\n", c_addr);
+	mfc_debug(2, "enc src cr buf addr: 0x%08lx\n", c_1_addr);
 }
 
 static void s5p_mfc_get_enc_frame_buffer_v6(struct s5p_mfc_ctx *ctx,
-		unsigned long *y_addr, unsigned long *c_addr)
+		unsigned long *y_addr, unsigned long *c_addr,
+		unsigned long *c_1_addr)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
@@ -694,12 +753,17 @@ static void s5p_mfc_get_enc_frame_buffer_v6(struct s5p_mfc_ctx *ctx,
 
 	*y_addr = readl(mfc_regs->e_encoded_source_first_plane_addr);
 	*c_addr = readl(mfc_regs->e_encoded_source_second_plane_addr);
+	if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+			V4L2_PIX_FMT_YVU420M)
+		*c_1_addr = readl(mfc_regs->e_encoded_source_third_plane_addr);
+	else
+		*c_1_addr = 0;
 
 	enc_recon_y_addr = readl(mfc_regs->e_recon_luma_dpb_addr);
 	enc_recon_c_addr = readl(mfc_regs->e_recon_chroma_dpb_addr);
 
 	mfc_debug(2, "recon y addr: 0x%08lx y_addr: 0x%08lx\n", enc_recon_y_addr, *y_addr);
-	mfc_debug(2, "recon c addr: 0x%08lx\n", enc_recon_c_addr);
+	mfc_debug(2, "recon c addr: 0x%08lx c_addr: 0x%08lx\n", enc_recon_c_addr, *c_addr);
 }
 
 /* Set encoding ref & codec buffer */
@@ -876,6 +940,20 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
 		writel(reg, mfc_regs->e_enc_options);
 		/* 0: NV12(CbCr), 1: NV21(CrCb) */
 		writel(0x0, mfc_regs->pixel_format);
+	} else if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YVU420M) {
+		/* 0: Linear, 1: 2D tiled*/
+		reg = readl(mfc_regs->e_enc_options);
+		reg &= ~(0x1 << 7);
+		writel(reg, mfc_regs->e_enc_options);
+		/* 2: YV12(CrCb), 3: I420(CrCb) */
+		writel(0x2, mfc_regs->pixel_format);
+	} else if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M) {
+		/* 0: Linear, 1: 2D tiled*/
+		reg = readl(mfc_regs->e_enc_options);
+		reg &= ~(0x1 << 7);
+		writel(reg, mfc_regs->e_enc_options);
+		/* 2: YV12(CrCb), 3: I420(CrCb) */
+		writel(0x3, mfc_regs->pixel_format);
 	}
 
 	/* memory structure recon. frame */
@@ -1686,8 +1764,12 @@ static int s5p_mfc_init_decode_v6(struct s5p_mfc_ctx *ctx)
 	else
 		writel(reg, mfc_regs->d_dec_options);
 
-	/* 0: NV12(CbCr), 1: NV21(CrCb) */
-	if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_NV21M)
+	/* 0: NV12(CbCr), 1: NV21(CrCb), 2: YV12(CrCb), 3: I420(CbCr) */
+	if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M)
+		writel(0x3, mfc_regs->pixel_format);
+	else if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YVU420M)
+		writel(0x2, mfc_regs->pixel_format);
+	else if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_NV21M)
 		writel(0x1, mfc_regs->pixel_format);
 	else
 		writel(0x0, mfc_regs->pixel_format);
@@ -1771,8 +1853,11 @@ static int s5p_mfc_init_encode_v6(struct s5p_mfc_ctx *ctx)
 
 	/* Set stride lengths for v7 & above */
 	if (IS_MFCV7_PLUS(dev)) {
-		writel(ctx->img_width, mfc_regs->e_source_first_plane_stride);
-		writel(ctx->img_width, mfc_regs->e_source_second_plane_stride);
+		writel(ctx->stride[0], mfc_regs->e_source_first_plane_stride);
+		writel(ctx->stride[1], mfc_regs->e_source_second_plane_stride);
+		if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			writel(ctx->stride[2], mfc_regs->e_source_third_plane_stride);
 	}
 
 	writel(ctx->inst_no, mfc_regs->instance_id);
@@ -1881,7 +1966,7 @@ static inline int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	struct s5p_mfc_buf *dst_mb;
 	struct s5p_mfc_buf *src_mb;
-	unsigned long src_y_addr, src_c_addr, dst_addr;
+	unsigned long src_y_addr, src_c_addr, src_c_1_addr, dst_addr;
 	/*
 	unsigned int src_y_size, src_c_size;
 	*/
@@ -1899,22 +1984,28 @@ static inline int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 
 	if (list_empty(&ctx->src_queue)) {
 		/* send null frame */
-		s5p_mfc_set_enc_frame_buffer_v6(ctx, 0, 0);
+		s5p_mfc_set_enc_frame_buffer_v6(ctx, 0, 0, 0);
 		src_mb = NULL;
 	} else {
 		src_mb = list_entry(ctx->src_queue.next, struct s5p_mfc_buf, list);
 		src_mb->flags |= MFC_BUF_FLAG_USED;
 		if (src_mb->b->vb2_buf.planes[0].bytesused == 0) {
-			s5p_mfc_set_enc_frame_buffer_v6(ctx, 0, 0);
+			s5p_mfc_set_enc_frame_buffer_v6(ctx, 0, 0, 0);
 			ctx->state = MFCINST_FINISHING;
 		} else {
 			src_y_addr = vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 0);
 			src_c_addr = vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 1);
+			if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YVU420M)
+				src_c_1_addr = vb2_dma_contig_plane_dma_addr
+					(&src_mb->b->vb2_buf, 2);
+			else
+				src_c_1_addr = 0;
 
 			mfc_debug(2, "enc src y addr: 0x%08lx\n", src_y_addr);
 			mfc_debug(2, "enc src c addr: 0x%08lx\n", src_c_addr);
 
-			s5p_mfc_set_enc_frame_buffer_v6(ctx, src_y_addr, src_c_addr);
+			s5p_mfc_set_enc_frame_buffer_v6(ctx, src_y_addr, src_c_addr, src_c_1_addr);
 			if (src_mb->flags & MFC_BUF_FLAG_EOS)
 				ctx->state = MFCINST_FINISHING;
 		}
@@ -2436,10 +2527,9 @@ const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev)
 	R(e_source_first_plane_stride, S5P_FIMV_E_SOURCE_FIRST_STRIDE_V7);
 	R(e_source_second_plane_stride, S5P_FIMV_E_SOURCE_SECOND_STRIDE_V7);
 	R(e_source_third_plane_stride, S5P_FIMV_E_SOURCE_THIRD_STRIDE_V7);
-	R(e_encoded_source_first_plane_addr,
-			S5P_FIMV_E_ENCODED_SOURCE_FIRST_ADDR_V7);
-	R(e_encoded_source_second_plane_addr,
-			S5P_FIMV_E_ENCODED_SOURCE_SECOND_ADDR_V7);
+	R(e_encoded_source_first_plane_addr, S5P_FIMV_E_ENCODED_SOURCE_FIRST_ADDR_V7);
+	R(e_encoded_source_second_plane_addr, S5P_FIMV_E_ENCODED_SOURCE_SECOND_ADDR_V7);
+	R(e_encoded_source_third_plane_addr, S5P_FIMV_E_ENCODED_SOURCE_THIRD_ADDR_V7);
 	R(e_vp8_options, S5P_FIMV_E_VP8_OPTIONS_V7);
 
 	if (!IS_MFCV8_PLUS(dev))
@@ -2454,16 +2544,17 @@ const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev)
 	R(d_cpb_buffer_offset, S5P_FIMV_D_CPB_BUFFER_OFFSET_V8);
 	R(d_first_plane_dpb_size, S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8);
 	R(d_second_plane_dpb_size, S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V8);
+	R(d_third_plane_dpb_size, S5P_FIMV_D_THIRD_PLANE_DPB_SIZE_V8);
 	R(d_scratch_buffer_addr, S5P_FIMV_D_SCRATCH_BUFFER_ADDR_V8);
 	R(d_scratch_buffer_size, S5P_FIMV_D_SCRATCH_BUFFER_SIZE_V8);
-	R(d_first_plane_dpb_stride_size,
-			S5P_FIMV_D_FIRST_PLANE_DPB_STRIDE_SIZE_V8);
-	R(d_second_plane_dpb_stride_size,
-			S5P_FIMV_D_SECOND_PLANE_DPB_STRIDE_SIZE_V8);
+	R(d_first_plane_dpb_stride_size, S5P_FIMV_D_FIRST_PLANE_DPB_STRIDE_SIZE_V8);
+	R(d_second_plane_dpb_stride_size, S5P_FIMV_D_SECOND_PLANE_DPB_STRIDE_SIZE_V8);
+	R(d_third_plane_dpb_stride_size, S5P_FIMV_D_THIRD_PLANE_DPB_STRIDE_SIZE_V8);
 	R(d_mv_buffer_size, S5P_FIMV_D_MV_BUFFER_SIZE_V8);
 	R(d_num_mv, S5P_FIMV_D_NUM_MV_V8);
 	R(d_first_plane_dpb, S5P_FIMV_D_FIRST_PLANE_DPB_V8);
 	R(d_second_plane_dpb, S5P_FIMV_D_SECOND_PLANE_DPB_V8);
+	R(d_third_plane_dpb, S5P_FIMV_D_THIRD_PLANE_DPB_V8);
 	R(d_mv_buffer, S5P_FIMV_D_MV_BUFFER_V8);
 	R(d_init_buffer_options, S5P_FIMV_D_INIT_BUFFER_OPTIONS_V8);
 	R(d_available_dpb_flag_lower, S5P_FIMV_D_AVAILABLE_DPB_FLAG_LOWER_V8);
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:39 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:39 +0530
Subject: [Patch v5 05/11] media: s5p-mfc: Add support for rate controls in
 MFCv12
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063121epcas5p17a110abeea781dcb8760b4da4c8e4074@epcas5p1.samsung.com>
Message-ID: <20231206063045.97234-6-aakarsh.jain@samsung.com>

In MFCv12, the rc configs are changed with support for CBR loose,
CBR tight and Variable Bitrate (VBR) added.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 22 +++++++++++++++----
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h |  1 +
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 36aebca11313..4a0d0e228e78 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -992,10 +992,24 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
 
 	/* reaction coefficient */
 	if (p->rc_frame) {
-		if (p->rc_reaction_coeff < TIGHT_CBR_MAX) /* tight CBR */
-			writel(1, mfc_regs->e_rc_mode);
-		else					  /* loose CBR */
-			writel(2, mfc_regs->e_rc_mode);
+		if (IS_MFCV12(dev)) {
+			/* loose CBR */
+			if (p->rc_reaction_coeff < LOOSE_CBR_MAX)
+				writel(1, mfc_regs->e_rc_mode);
+			/* tight CBR */
+			else if (p->rc_reaction_coeff < TIGHT_CBR_MAX)
+				writel(0, mfc_regs->e_rc_mode);
+			/* VBR */
+			else
+				writel(2, mfc_regs->e_rc_mode);
+		} else {
+			/* tight CBR */
+			if (p->rc_reaction_coeff < TIGHT_CBR_MAX)
+				writel(1, mfc_regs->e_rc_mode);
+			/* loose CBR */
+			else
+				writel(2, mfc_regs->e_rc_mode);
+		}
 	}
 
 	/* seq header ctrl */
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
index ff582eea4217..94ecb0e6e7c7 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
@@ -40,6 +40,7 @@
 #define ENC_H264_LEVEL_MAX		42
 #define ENC_MPEG4_VOP_TIME_RES_MAX	((1 << 16) - 1)
 #define FRAME_DELTA_H264_H263		1
+#define LOOSE_CBR_MAX			5
 #define TIGHT_CBR_MAX			10
 #define ENC_HEVC_RC_FRAME_RATE_MAX	((1 << 16) - 1)
 #define ENC_HEVC_QP_INDEX_MIN		-12
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:40 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:40 +0530
Subject: [Patch v5 06/11] media: s5p-mfc: Add support for UHD encoding.
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063125epcas5p2c5d07f51ba83198ccb8fbab005bab8f6@epcas5p2.samsung.com>
Message-ID: <20231206063045.97234-7-aakarsh.jain@samsung.com>

MFC driver had restriction on max resolution of 1080p, updated it for
UHD. Added corresponding support to set recommended profile and level
for H264 in UHD scenario.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c |  9 ++++++---
 .../media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c  | 12 ++++++++++++
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index 6b495a738291..b01b9511e50c 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -1461,9 +1461,12 @@ static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 			mfc_err("Unsupported format by this MFC version.\n");
 			return -EINVAL;
 		}
-
-		v4l_bound_align_image(&pix_fmt_mp->width, 8, 1920, 1,
-			&pix_fmt_mp->height, 4, 1080, 1, 0);
+		if (IS_MFCV12(dev))
+			v4l_bound_align_image(&pix_fmt_mp->width, 8, 3840, 1, &pix_fmt_mp
+					->height, 4, 2160, 1, 0);
+		else
+			v4l_bound_align_image(&pix_fmt_mp->width, 8, 1920, 1, &pix_fmt_mp
+					->height, 4, 1080, 1, 0);
 	} else {
 		mfc_err("invalid buf type\n");
 		return -EINVAL;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 4a0d0e228e78..572293f3b190 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1071,6 +1071,18 @@ static int s5p_mfc_set_enc_params_h264(struct s5p_mfc_ctx *ctx)
 	reg |= ((p->num_b_frame & 0x3) << 16);
 	writel(reg, mfc_regs->e_gop_config);
 
+	/* UHD encoding case */
+	if (ctx->img_width == 3840 && ctx->img_height == 2160) {
+		if (p_h264->level < 51) {
+			mfc_debug(2, "Set Level 5.1 for UHD\n");
+			p_h264->level = 51;
+		}
+		if (p_h264->profile != 0x2) {
+			mfc_debug(2, "Set High profile for UHD\n");
+			p_h264->profile = 0x2;
+		}
+	}
+
 	/* profile & level */
 	reg = 0;
 	/** level */
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:41 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:41 +0530
Subject: [Patch v5 07/11] media: s5p-mfc: Add support for DMABUF for encoder
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063128epcas5p3145907e75b404400a552b8bd66e1c175@epcas5p3.samsung.com>
Message-ID: <20231206063045.97234-8-aakarsh.jain@samsung.com>

Add dmabuf support for mfc encoder

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../media/platform/samsung/s5p-mfc/s5p_mfc.c  |  4 ++--
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    | 20 ++++++++++---------
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index dee9ef017997..bd055dea827e 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -865,7 +865,7 @@ static int s5p_mfc_open(struct file *file)
 		q->io_modes = VB2_MMAP;
 		q->ops = get_dec_queue_ops();
 	} else if (vdev == dev->vfd_enc) {
-		q->io_modes = VB2_MMAP | VB2_USERPTR;
+		q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
 		q->ops = get_enc_queue_ops();
 	} else {
 		ret = -ENOENT;
@@ -892,7 +892,7 @@ static int s5p_mfc_open(struct file *file)
 		q->io_modes = VB2_MMAP;
 		q->ops = get_dec_queue_ops();
 	} else if (vdev == dev->vfd_enc) {
-		q->io_modes = VB2_MMAP | VB2_USERPTR;
+		q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
 		q->ops = get_enc_queue_ops();
 	} else {
 		ret = -ENOENT;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index b01b9511e50c..a5df0759ccf0 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -1538,9 +1538,10 @@ static int vidioc_reqbufs(struct file *file, void *priv,
 	struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
 	int ret = 0;
 
-	/* if memory is not mmp or userptr return error */
+	/* if memory is not mmp or userptr or dmabuf return error */
 	if ((reqbufs->memory != V4L2_MEMORY_MMAP) &&
-		(reqbufs->memory != V4L2_MEMORY_USERPTR))
+		(reqbufs->memory != V4L2_MEMORY_USERPTR) &&
+		(reqbufs->memory != V4L2_MEMORY_DMABUF))
 		return -EINVAL;
 	if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 		if (reqbufs->count == 0) {
@@ -1617,9 +1618,10 @@ static int vidioc_querybuf(struct file *file, void *priv,
 	struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
 	int ret = 0;
 
-	/* if memory is not mmp or userptr return error */
+	/* if memory is not mmp or userptr or dmabuf return error */
 	if ((buf->memory != V4L2_MEMORY_MMAP) &&
-		(buf->memory != V4L2_MEMORY_USERPTR))
+		(buf->memory != V4L2_MEMORY_USERPTR) &&
+		(buf->memory != V4L2_MEMORY_DMABUF))
 		return -EINVAL;
 	if (buf->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 		if (ctx->state != MFCINST_GOT_INST) {
@@ -2580,11 +2582,11 @@ static int s5p_mfc_start_streaming(struct vb2_queue *q, unsigned int count)
 						S5P_MFC_R2H_CMD_SEQ_DONE_RET,
 						0);
 		}
-
-		if (ctx->src_bufs_cnt < ctx->pb_count) {
-			mfc_err("Need minimum %d OUTPUT buffers\n",
-					ctx->pb_count);
-			return -ENOBUFS;
+		if (q->memory != V4L2_MEMORY_DMABUF) {
+			if (ctx->src_bufs_cnt < ctx->pb_count) {
+				mfc_err("Need minimum %d OUTPUT buffers\n", ctx->pb_count);
+				return -ENOBUFS;
+			}
 		}
 	}
 
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:42 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:42 +0530
Subject: [Patch v5 08/11] media: s5p-mfc: Set context for valid case before
 calling try_run
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063131epcas5p2e0fc772f8f8ac35897920d24a0193d71@epcas5p2.samsung.com>
Message-ID: <20231206063045.97234-9-aakarsh.jain@samsung.com>

Context bit is set for hardware execution if there is a buffer in
source and destination queue before calling try_run in the
init_buffers function. Now there will be a new context created and
hardware will be invoked for the buffer queued instead of waiting for
another buffer to be queued from userspace to set this context bit for
hw execution.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index bd055dea827e..fbb047eadf5a 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -604,6 +604,8 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx *ctx,
 		s5p_mfc_clock_off();
 
 		wake_up(&ctx->queue);
+		if (ctx->src_queue_cnt >= 1 && ctx->dst_queue_cnt >= 1)
+			set_work_bit_irqsave(ctx);
 		s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 	} else {
 		WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:43 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:43 +0530
Subject: [Patch v5 09/11] media: s5p-mfc: Load firmware for each run in
 MFCv12.
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063134epcas5p2b3b9ca0351cd9c1cb169d7a4a3a30b80@epcas5p2.samsung.com>
Message-ID: <20231206063045.97234-10-aakarsh.jain@samsung.com>

In MFCv12, some section of firmware gets updated at each MFC run.
Hence we need to reload original firmware for each run at the start.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
index b49159142c53..24dd40ae71ec 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
@@ -51,8 +51,10 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
 	 * into kernel. */
 	mfc_debug_enter();
 
-	if (dev->fw_get_done)
-		return 0;
+	/* Load MFC v12 firmware for each run when MFC runs sequentially */
+	if (!IS_MFCV12(dev))
+		if (dev->fw_get_done)
+			return 0;
 
 	for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
 		if (!dev->variant->fw_name[i])
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:44 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:44 +0530
Subject: [Patch v5 10/11] media: s5p-mfc: DPB Count Independent of
 VIDIOC_REQBUF
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063137epcas5p3450b1c70bdf7461afeeb6a3db341818c@epcas5p3.samsung.com>
Message-ID: <20231206063045.97234-11-aakarsh.jain@samsung.com>

Add allocation of DPB buffers based on MFC requirement so,
codec buffers allocations has been moved after state
MFCINST_HEAD_PRODUCED. It is taken care that codec buffer allocation
is performed in process context from userspace IOCTL call.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c     | 18 ++----------------
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c  |  7 +++++++
 2 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index a5df0759ccf0..a50df888c7c5 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -1164,7 +1164,6 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	struct s5p_mfc_enc_params *p = &ctx->enc_params;
 	struct s5p_mfc_buf *dst_mb;
-	unsigned int enc_pb_count;
 
 	if (p->seq_hdr_mode == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) {
 		if (!list_empty(&ctx->dst_queue)) {
@@ -1186,10 +1185,7 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
 			set_work_bit_irqsave(ctx);
 		s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 	} else {
-		enc_pb_count = s5p_mfc_hw_call(dev->mfc_ops,
-				get_enc_dpb_count, dev);
-		if (ctx->pb_count < enc_pb_count)
-			ctx->pb_count = enc_pb_count;
+		ctx->pb_count = s5p_mfc_hw_call(dev->mfc_ops, get_enc_dpb_count, dev);
 		if (FW_HAS_E_MIN_SCRATCH_BUF(dev)) {
 			ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
 					get_e_min_scratch_buf_size, dev);
@@ -1564,14 +1560,6 @@ static int vidioc_reqbufs(struct file *file, void *priv,
 		}
 		ctx->capture_state = QUEUE_BUFS_REQUESTED;
 
-		ret = s5p_mfc_hw_call(ctx->dev->mfc_ops,
-				alloc_codec_buffers, ctx);
-		if (ret) {
-			mfc_err("Failed to allocate encoding buffers\n");
-			reqbufs->count = 0;
-			ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
-			return -ENOMEM;
-		}
 	} else if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 		if (reqbufs->count == 0) {
 			mfc_debug(2, "Freeing buffers\n");
@@ -1587,15 +1575,13 @@ static int vidioc_reqbufs(struct file *file, void *priv,
 			return -EINVAL;
 		}
 
-		if (IS_MFCV6_PLUS(dev)) {
+		if (IS_MFCV6_PLUS(dev) && (!IS_MFCV12(dev))) {
 			/* Check for min encoder buffers */
 			if (ctx->pb_count &&
 				(reqbufs->count < ctx->pb_count)) {
 				reqbufs->count = ctx->pb_count;
 				mfc_debug(2, "Minimum %d output buffers needed\n",
 						ctx->pb_count);
-			} else {
-				ctx->pb_count = reqbufs->count;
 			}
 		}
 
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 572293f3b190..fd945211d28e 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -2110,6 +2110,13 @@ static inline int s5p_mfc_run_init_enc_buffers(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	int ret;
 
+	ret = s5p_mfc_hw_call(ctx->dev->mfc_ops, alloc_codec_buffers, ctx);
+	if (ret) {
+		mfc_err("Failed to allocate encoding buffers\n");
+		return -ENOMEM;
+	}
+	mfc_debug(2, "Allocated Internal Encoding Buffers\n");
+
 	dev->curr_ctx = ctx->num;
 	ret = s5p_mfc_set_enc_ref_buffer_v6(ctx);
 	if (ret) {
-- 
2.17.1



From aakarsh.jain at samsung.com  Tue Dec  5 22:30:45 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed,  6 Dec 2023 12:00:45 +0530
Subject: [Patch v5 11/11] arm64: dts: fsd: Add MFC related DT enteries
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063140epcas5p1ba86525117f4d9ec9172ae7cb18b7420@epcas5p1.samsung.com>
Message-ID: <20231206063045.97234-12-aakarsh.jain@samsung.com>

Add MFC DT node and reserve memory node for MFC usage.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 arch/arm64/boot/dts/tesla/fsd.dtsi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/tesla/fsd.dtsi b/arch/arm64/boot/dts/tesla/fsd.dtsi
index bb50a9f7db4a..f421012b0a4a 100644
--- a/arch/arm64/boot/dts/tesla/fsd.dtsi
+++ b/arch/arm64/boot/dts/tesla/fsd.dtsi
@@ -342,6 +342,18 @@
 		#clock-cells = <0>;
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		mfc_left: region at 84000000 {
+			compatible = "shared-dma-pool";
+			no-map;
+			reg = <0 0x84000000 0 0x8000000>;
+		};
+	};
+
 	soc: soc at 0 {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -956,6 +968,15 @@
 			clock-names = "fin_pll", "mct";
 		};
 
+		mfc: mfc at 12880000 {
+			compatible = "tesla,fsd-mfc";
+			reg = <0x0 0x12880000 0x0 0x10000>;
+			interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "mfc";
+			clocks = <&clock_mfc MFC_MFC_IPCLKPORT_ACLK>;
+			memory-region = <&mfc_left>;
+		};
+
 		ufs: ufs at 15120000 {
 			compatible = "tesla,fsd-ufs";
 			reg = <0x0 0x15120000 0x0 0x200>,  /* 0: HCI standard */
-- 
2.17.1



From lkp at intel.com  Tue Dec  5 22:39:56 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 6 Dec 2023 14:39:56 +0800
Subject: [PATCH v4 2/5] clk: stm32mp1: use stm32mp13 reset driver
In-Reply-To: <20231128164851.588315-3-gabriel.fernandez@foss.st.com>
References: <20231128164851.588315-3-gabriel.fernandez@foss.st.com>
Message-ID: <202312061455.vpswjBcr-lkp@intel.com>

Hi,

kernel test robot noticed the following build warnings:

[auto build test WARNING on atorgue-stm32/stm32-next]
[also build test WARNING on clk/clk-next robh/for-next linus/master v6.7-rc4 next-20231206]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/gabriel-fernandez-foss-st-com/clk-stm32mp1-move-stm32mp1-clock-driver-into-stm32-directory/20231129-005157
base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
patch link:    https://lore.kernel.org/r/20231128164851.588315-3-gabriel.fernandez%40foss.st.com
patch subject: [PATCH v4 2/5] clk: stm32mp1: use stm32mp13 reset driver
config: arm-randconfig-r132-20231201 (https://download.01.org/0day-ci/archive/20231206/202312061455.vpswjBcr-lkp at intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231206/202312061455.vpswjBcr-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312061455.vpswjBcr-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/clk/stm32/clk-stm32mp13.c:1516:29: sparse: sparse: symbol 'stm32mp13_reset_data' was not declared. Should it be static?
--
>> drivers/clk/stm32/clk-stm32mp1.c:2148:29: sparse: sparse: symbol 'stm32mp1_reset_data' was not declared. Should it be static?

vim +/stm32mp13_reset_data +1516 drivers/clk/stm32/clk-stm32mp13.c

  1515	
> 1516	struct clk_stm32_reset_data stm32mp13_reset_data = {
  1517		.nr_lines	= STM32MP1_RESET_ID_MASK,
  1518		.clear_offset	= RCC_CLR_OFFSET,
  1519	};
  1520	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From joel at jms.id.au  Tue Dec  5 22:46:15 2023
From: joel at jms.id.au (Joel Stanley)
Date: Wed, 6 Dec 2023 17:16:15 +1030
Subject: [PATCH v3 0/2] ARM: dts: aspeed: asrock: Add ASRock X570D4U BMC
In-Reply-To: <20231202003908.3635695-1-renze@rnplus.nl>
References: <20231202003908.3635695-1-renze@rnplus.nl>
Message-ID: <CACPK8XfhK8eSjYvEd=7WshOh+Sj6vrERxwgAYGitVALw0pUf8w@mail.gmail.com>

On Sat, 2 Dec 2023 at 11:09, Renze Nicolai <renze at rnplus.nl> wrote:
>
> Hello,
>
> These patches add a device-tree (and a bindings update) for the
> Aspeed BMC on the ASRock X570D4U, so that it can be added as a
> supported OpenBMC platform.

Looks great!

Reviewed-by: Joel Stanley <joel at jms.id.au>

I've also added this to the openbmc tree, so no need to send the patches there..

>
> Changes since v2:
>   - Renamed leds to led-0 and led-1 to match Documentation/devicetree/bindings/leds/leds-gpio.yaml
>   - Added aliasses and labels for the i2c-mux on i2c bus 4
>   - Added the missing blank line between the ehci1 and uhci nodes
>
> Greetings,
> Renze Nicolai
>
> Renze Nicolai (2):
>   dt-bindings: arm: aspeed: add Asrock X570D4U board
>   ARM: dts: aspeed: asrock: Add ASRock X570D4U BMC
>
>  .../bindings/arm/aspeed/aspeed.yaml           |   1 +
>  arch/arm/boot/dts/aspeed/Makefile             |   1 +
>  .../dts/aspeed/aspeed-bmc-asrock-x570d4u.dts  | 377 ++++++++++++++++++
>  3 files changed, 379 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
>
> --
> 2.43.0
>


From wahrenst at gmx.net  Tue Dec  5 23:00:26 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Wed, 6 Dec 2023 08:00:26 +0100
Subject: [PATCH] ARM: dts: imx28-xea: Pass the 'model' property
In-Reply-To: <20231205132735.2016022-1-festevam@gmail.com>
References: <20231205132735.2016022-1-festevam@gmail.com>
Message-ID: <88a045f5-a18d-424a-811e-10f095ca151e@gmx.net>

Hi,

sorry i replied just to the list last time :-(

Am 05.12.23 um 14:27 schrieb Fabio Estevam:
> From: Fabio Estevam <festevam at denx.de>
>
> Per root-node.yaml, 'model' is a required property.
>
> Pass it to fix the following dt-schema warning:
>
> imx28-xea.dtb: /: 'model' is a required property
> 	from schema $id: http://devicetree.org/schemas/root-node.yaml#
>
> Signed-off-by: Fabio Estevam <festevam at denx.de>
i would consider this as a fix because every board file should have a
model, which is helpful for debugging.

Fixes: 445ae16ac1c5 ("ARM: dts: imx28: Add DTS description of imx28
based XEA board")
> ---
>   arch/arm/boot/dts/nxp/mxs/imx28-xea.dts | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> index a400c108f66a..cc54a0390f8c 100644
> --- a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> +++ b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> @@ -8,6 +8,7 @@
>   #include "imx28-lwe.dtsi"
>
>   / {
> +	model = "Liebherr Xea board";
s/Xea/XEA

Thanks
>   	compatible = "lwn,imx28-xea", "fsl,imx28";
>   };
>



From michal.simek at amd.com  Tue Dec  5 23:48:11 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 6 Dec 2023 08:48:11 +0100
Subject: [PATCH] clocksource: cadence-ttc: fix some kernel-doc warnings
In-Reply-To: <20231205230448.772-1-rdunlap@infradead.org>
References: <20231205230448.772-1-rdunlap@infradead.org>
Message-ID: <1fdcdaa8-5eb4-4a03-ad34-811c3ad7efd0@amd.com>



On 12/6/23 00:04, Randy Dunlap wrote:
> Fix some function kernel-doc warnings to placate scripts/kernel-doc.
> 
> timer-cadence-ttc.c:79: warning: Function parameter or member 'clk_rate_change_nb' not described in 'ttc_timer'
> timer-cadence-ttc.c:158: warning: Function parameter or member 'cs' not described in '__ttc_clocksource_read'
> timer-cadence-ttc.c:194: warning: expecting prototype for ttc_set_{shutdown|oneshot|periodic}(). Prototype was for ttc_shutdown() instead
> timer-cadence-ttc.c:196: warning: No description found for return value of 'ttc_shutdown'
> timer-cadence-ttc.c:212: warning: No description found for return value of 'ttc_set_periodic'
> 
> Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
> Cc: Michal Simek <michal.simek at amd.com>
> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>   drivers/clocksource/timer-cadence-ttc.c |   22 ++++++++++++++++------
>   1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff -- a/drivers/clocksource/timer-cadence-ttc.c b/drivers/clocksource/timer-cadence-ttc.c
> --- a/drivers/clocksource/timer-cadence-ttc.c
> +++ b/drivers/clocksource/timer-cadence-ttc.c
> @@ -69,7 +69,7 @@
>    * @base_addr:	Base address of timer
>    * @freq:	Timer input clock frequency
>    * @clk:	Associated clock source
> - * @clk_rate_change_nb	Notifier block for clock rate changes
> + * @clk_rate_change_nb:	Notifier block for clock rate changes
>    */
>   struct ttc_timer {
>   	void __iomem *base_addr;
> @@ -134,7 +134,7 @@ static void ttc_set_interval(struct ttc_
>    * @irq:	IRQ number of the Timer
>    * @dev_id:	void pointer to the ttc_timer instance
>    *
> - * returns: Always IRQ_HANDLED - success
> + * Returns: Always IRQ_HANDLED - success
>    **/
>   static irqreturn_t ttc_clock_event_interrupt(int irq, void *dev_id)
>   {
> @@ -151,8 +151,9 @@ static irqreturn_t ttc_clock_event_inter
>   
>   /**
>    * __ttc_clocksource_read - Reads the timer counter register
> + * @cs: &clocksource to read from
>    *
> - * returns: Current timer counter register value
> + * Returns: Current timer counter register value
>    **/
>   static u64 __ttc_clocksource_read(struct clocksource *cs)
>   {
> @@ -173,7 +174,7 @@ static u64 notrace ttc_sched_clock_read(
>    * @cycles:	Timer interval ticks
>    * @evt:	Address of clock event instance
>    *
> - * returns: Always 0 - success
> + * Returns: Always %0 - success
>    **/
>   static int ttc_set_next_event(unsigned long cycles,
>   					struct clock_event_device *evt)
> @@ -186,9 +187,12 @@ static int ttc_set_next_event(unsigned l
>   }
>   
>   /**
> - * ttc_set_{shutdown|oneshot|periodic} - Sets the state of timer
> - *
> + * ttc_shutdown - Sets the state of timer
>    * @evt:	Address of clock event instance
> + *
> + * Used for shutdown or oneshot.
> + *
> + * Returns: Always %0 - success
>    **/
>   static int ttc_shutdown(struct clock_event_device *evt)
>   {
> @@ -202,6 +206,12 @@ static int ttc_shutdown(struct clock_eve
>   	return 0;
>   }
>   
> +/**
> + * ttc_set_periodic - Sets the state of timer
> + * @evt:	Address of clock event instance
> + *
> + * Returns: Always %0 - success
> + */
>   static int ttc_set_periodic(struct clock_event_device *evt)
>   {
>   	struct ttc_timer_clockevent *ttce = to_ttc_timer_clkevent(evt);

Acked-by: Michal Simek <michal.simek at amd.com>
Tested-by: Michal Simek <michal.simek at amd.com>

Thanks,
Michal


From mani at kernel.org  Tue Dec  5 23:54:47 2023
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Wed, 6 Dec 2023 13:24:47 +0530
Subject: [PATCH V1] scsi: ufs: core: store min and max clk freq from OPP
 table
In-Reply-To: <20231206053628.32169-1-quic_nitirawa@quicinc.com>
References: <20231206053628.32169-1-quic_nitirawa@quicinc.com>
Message-ID: <20231206075447.GA4954@thinkpad>

On Wed, Dec 06, 2023 at 11:06:28AM +0530, Nitin Rawat wrote:
> OPP support will make use of OPP table in device tree and removes
> freq-table-hz property from device tree.
> 
> With OPP enabled in devicetree, clki->min_freq and clki->maxfreq
> currently is not getting updated and the value is set to 0.
> 
> Soc vendors like qcom, mediatek uses clki->minfreq and clki->maxfreq
> in vendor specific file. These frequencies values are used to update
> vendor specific configurations. Since the value is 0, it is causing
> functional issue.

How about,

"OPP support added by commit 72208ebe181e ("scsi: ufs: core: Add support
for parsing OPP") doesn't update the min_freq and max_freq of each clocks
in 'struct ufs_clk_info'.

But these values are used by the vendor host drivers internally for controller
configuration. When the OPP support is enabled in devicetree, these values will
be 0, causing boot issues on the respective platforms.

So let's parse the min_freq and max_freq of all clocks while parsing the OPP
table."

> 
> Add code to store the min and max ufs clk frequency from OPP table.
> 
> Fixes: 72208ebe181e ("scsi: ufs: core: Add support for parsing OPP")
> Co-developed-by: Manish Pandey <quic_mapa at quicinc.com>
> Signed-off-by: Manish Pandey <quic_mapa at quicinc.com>
> Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
> ---
>  drivers/ufs/host/ufshcd-pltfrm.c | 56 ++++++++++++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/drivers/ufs/host/ufshcd-pltfrm.c b/drivers/ufs/host/ufshcd-pltfrm.c
> index da2558e274b4..12fa6f7d6a97 100644
> --- a/drivers/ufs/host/ufshcd-pltfrm.c
> +++ b/drivers/ufs/host/ufshcd-pltfrm.c
> @@ -13,6 +13,7 @@
>  #include <linux/pm_opp.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/of.h>
> +#include <linux/clk.h>

Sort includes alphabetically.

> 
>  #include <ufs/ufshcd.h>
>  #include "ufshcd-pltfrm.h"
> @@ -213,6 +214,55 @@ static void ufshcd_init_lanes_per_dir(struct ufs_hba *hba)
>  	}
>  }
> 
> +/**
> + * ufshcd_config_min_max_clk_freq - update min and max freq

"ufshcd_parse_clock_min_max_freq - Parse MIN and MAX frequencies of clocks"

> + * @hba: per adapter instance
> + *
> + * This function store min and max freq for all the clocks.
> + *

"This function parses MIN and MAX frequencies of all clocks required by the
vendor host drivers."

> + * Returns 0 for success and non-zero for failure
> + */
> +static int ufshcd_config_min_max_clk_freq(struct ufs_hba *hba)
> +{
> +	struct list_head *head = &hba->clk_list_head;
> +	struct dev_pm_opp *opp;
> +	struct ufs_clk_info *clki;

Please maintain reverse Xmas tree order. It's not a rule for this driver, but my
own preference.

> +	unsigned long freq;
> +	u8 idx = 0;
> +	int ret;

This won't be needed if all the return values are directly returned as I shared
below.

> +
> +	list_for_each_entry(clki, head, list) {
> +		if (!clki->name)
> +			continue;
> +
> +		clki->clk = devm_clk_get(hba->dev, clki->name);
> +		if (!IS_ERR_OR_NULL(clki->clk)) {

This function won't return NULL, so IS_ERR() is sufficient.

> +			/* Find Max Freq */
> +			freq = ULONG_MAX;
> +			opp = dev_pm_opp_find_freq_floor_indexed(hba->dev, &freq, idx);

Use idx++ and get rid of the increment at the end of the 'if' condition.

> +			if (IS_ERR(opp)) {
> +				dev_err(hba->dev, "failed to find dev_pm_opp\n");

"Failed to find OPP for MAX frequency"

> +				ret = PTR_ERR(opp);

return PTR_ERR(opp);

> +				return ret;
> +			}
> +			clki->max_freq = dev_pm_opp_get_freq_indexed(opp, idx);
> +

Missing dev_pm_opp_put()

> +			/* Find Min Freq */
> +			freq = 0;
> +			opp = dev_pm_opp_find_freq_ceil_indexed(hba->dev, &freq, idx);
> +			if (IS_ERR(opp)) {
> +				dev_err(hba->dev, "failed to find dev_pm_opp\n");

"Failed to find OPP for MIN frequency"

> +				ret = PTR_ERR(opp);

return PTR_ERR(opp);

> +				return ret;
> +			}
> +			clki->min_freq = dev_pm_opp_get_freq_indexed(opp, idx);

Missing dev_pm_opp_put()

> +			idx++;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
>  static int ufshcd_parse_operating_points(struct ufs_hba *hba)
>  {
>  	struct device *dev = hba->dev;
> @@ -279,6 +329,12 @@ static int ufshcd_parse_operating_points(struct ufs_hba *hba)
>  		return ret;
>  	}
> 
> +	ret = ufshcd_config_min_max_clk_freq(hba);
> +	if (ret) {
> +		dev_err(dev, "Failed to get min max freq: %d\n", ret);

Since we already print error message inside the function, no need to do the same
here.

- Mani

> +		return ret;
> +	}
> +
>  	hba->use_pm_opp = true;
> 
>  	return 0;
> --
> 2.17.1
> 

-- 
????????? ????????


From yunfei.dong at mediatek.com  Wed Dec  6 00:15:21 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:21 +0800
Subject: [PATCH v3,04/21] v4l: add documentation for secure memory flag
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-5-yunfei.dong@mediatek.com>

From: Jeffrey Kardatzke <jkardatzke at google.com>

Adds documentation for V4L2_MEMORY_FLAG_SECURE.

Signed-off-by: Jeffrey Kardatzke <jkardatzke at google.com>
Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 Documentation/userspace-api/media/v4l/buffer.rst | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst
index 52bbee81c080..a5a7d1c72d53 100644
--- a/Documentation/userspace-api/media/v4l/buffer.rst
+++ b/Documentation/userspace-api/media/v4l/buffer.rst
@@ -696,7 +696,7 @@ enum v4l2_memory
 
 .. _memory-flags:
 
-Memory Consistency Flags
+Memory Flags
 ------------------------
 
 .. raw:: latex
@@ -728,6 +728,12 @@ Memory Consistency Flags
 	only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the
 	queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
 	<V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability.
+    * .. _`V4L2-MEMORY-FLAG-SECURE`:
+
+      - ``V4L2_MEMORY_FLAG_SECURE``
+      - 0x00000002
+      - DMA bufs passed into the queue will be validated to ensure they were
+	allocated from a secure dma-heap.
 
 .. raw:: latex
 
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:23 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:23 +0800
Subject: [PATCH v3,06/21] dma-heap: Add proper kref handling on dma-buf heaps
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-7-yunfei.dong@mediatek.com>

From: John Stultz <jstultz at google.com>

Add proper refcounting on the dma_heap structure.
While existing heaps are built-in, we may eventually
have heaps loaded from modules, and we'll need to be
able to properly handle the references to the heaps

Signed-off-by: John Stultz <jstultz at google.com>
Signed-off-by: T.J. Mercier <tjmercier at google.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
[Yong: Just add comment for "minor" and "refcount"]
Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 drivers/dma-buf/dma-heap.c | 29 +++++++++++++++++++++++++++++
 include/linux/dma-heap.h   |  2 ++
 2 files changed, 31 insertions(+)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 22f6c193db0d..97025ee8500f 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -11,6 +11,7 @@
 #include <linux/dma-buf.h>
 #include <linux/dma-heap.h>
 #include <linux/err.h>
+#include <linux/kref.h>
 #include <linux/list.h>
 #include <linux/nospec.h>
 #include <linux/syscalls.h>
@@ -30,6 +31,7 @@
  * @heap_devt:		heap device node
  * @list:		list head connecting to list of heaps
  * @heap_cdev:		heap char device
+ * @refcount:		reference counter for this heap device
  *
  * Represents a heap of memory from which buffers can be made.
  */
@@ -40,6 +42,7 @@ struct dma_heap {
 	dev_t heap_devt;
 	struct list_head list;
 	struct cdev heap_cdev;
+	struct kref refcount;
 };
 
 static LIST_HEAD(heap_list);
@@ -240,6 +243,7 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
 	if (!heap)
 		return ERR_PTR(-ENOMEM);
 
+	kref_init(&heap->refcount);
 	heap->name = exp_info->name;
 	heap->ops = exp_info->ops;
 	heap->priv = exp_info->priv;
@@ -304,6 +308,31 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
 	return err_ret;
 }
 
+static void dma_heap_release(struct kref *ref)
+{
+	struct dma_heap *heap = container_of(ref, struct dma_heap, refcount);
+	unsigned int minor = MINOR(heap->heap_devt);
+
+	mutex_lock(&heap_list_lock);
+	list_del(&heap->list);
+	mutex_unlock(&heap_list_lock);
+
+	device_destroy(dma_heap_class, heap->heap_devt);
+	cdev_del(&heap->heap_cdev);
+	xa_erase(&dma_heap_minors, minor);
+
+	kfree(heap);
+}
+
+/**
+ * dma_heap_put - drops a reference to a dmabuf heap, potentially freeing it
+ * @heap: DMA-Heap whose reference count to decrement
+ */
+void dma_heap_put(struct dma_heap *heap)
+{
+	kref_put(&heap->refcount, dma_heap_release);
+}
+
 static char *dma_heap_devnode(const struct device *dev, umode_t *mode)
 {
 	return kasprintf(GFP_KERNEL, "dma_heap/%s", dev_name(dev));
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index fbe86ec889a8..d57593f8a1bc 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -46,4 +46,6 @@ const char *dma_heap_get_name(struct dma_heap *heap);
 
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
 
+void dma_heap_put(struct dma_heap *heap);
+
 #endif /* _DMA_HEAPS_H */
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:28 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:28 +0800
Subject: [PATCH v3,11/21] media: mediatek: vcodec: initialize msg and vsi information
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-12-yunfei.dong@mediatek.com>

Need to initialize msg and vsi information before sending to optee-os, then
calling optee invoke command to send the information to optee-os.

For the optee communication interface is different with scp, using
flag to separate them.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_drv.h       |  2 +
 .../mediatek/vcodec/decoder/vdec_vpu_if.c     | 49 ++++++++++++++++---
 .../mediatek/vcodec/decoder/vdec_vpu_if.h     |  4 ++
 3 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
index b1a2107f2a1e..47eca245dc07 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
@@ -175,6 +175,7 @@ struct mtk_vcodec_dec_pdata {
  * @vpu_inst: vpu instance pointer.
  *
  * @is_10bit_bitstream: set to true if it's 10bit bitstream
+ * @is_secure_playback: Secure Video Playback (SVP) mode
  */
 struct mtk_vcodec_dec_ctx {
 	enum mtk_instance_type type;
@@ -220,6 +221,7 @@ struct mtk_vcodec_dec_ctx {
 	void *vpu_inst;
 
 	bool is_10bit_bitstream;
+	bool is_secure_playback;
 };
 
 /**
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
index 82e57ae983d5..5336769a3fb5 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
@@ -148,7 +148,10 @@ static void vpu_dec_ipi_handler(void *data, unsigned int len, void *priv)
 
 static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
 {
-	int err, id, msgid;
+	struct mtk_vdec_optee_data_to_shm *optee_data;
+	int data_size, id, hw_id, msgid;
+	void *ack_msg, *data_msg;
+	int err;
 
 	msgid = *(uint32_t *)msg;
 	mtk_vdec_debug(vpu->ctx, "id=%X", msgid);
@@ -158,16 +161,46 @@ static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
 
 	if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
 		if (msgid == AP_IPIMSG_DEC_CORE ||
-		    msgid == AP_IPIMSG_DEC_CORE_END)
+		    msgid == AP_IPIMSG_DEC_CORE_END) {
+			optee_data = &vpu->core_optee_info;
 			id = vpu->core_id;
-		else
+		} else {
+			optee_data = &vpu->lat_optee_info;
 			id = vpu->id;
+		}
 	} else {
+		optee_data = &vpu->lat_optee_info;
 		id = vpu->id;
 	}
 
-	err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, msg,
-				     len, 2000);
+	if (!vpu->ctx->is_secure_playback) {
+		err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, msg, len, 2000);
+	} else {
+		hw_id = (id == SCP_IPI_VDEC_LAT) ? MTK_VDEC_LAT0 : MTK_VDEC_CORE;
+
+		mtk_vcodec_dec_optee_set_data(optee_data, msg, len, OPTEE_MSG_INDEX);
+
+		/* There is no need to copy the data (VSI) message to shared memory,
+		 * but we still need to set the buffer size to a non-zero value.
+		 */
+		if (msgid == AP_IPIMSG_DEC_CORE || msgid == AP_IPIMSG_DEC_START) {
+			data_msg = mtk_vcodec_dec_get_shm_buffer_va(vpu->ctx->dev->optee_private,
+								    hw_id, OPTEE_DATA_INDEX);
+			data_size = mtk_vcodec_dec_get_shm_buffer_size(vpu->ctx->dev->optee_private,
+								       hw_id, OPTEE_DATA_INDEX);
+			mtk_vcodec_dec_optee_set_data(optee_data, data_msg, data_size,
+						      OPTEE_DATA_INDEX);
+		}
+
+		err = mtk_vcodec_dec_optee_invokd_cmd(vpu->ctx->dev->optee_private,
+						      hw_id, optee_data);
+		vpu->failure = err;
+
+		ack_msg = mtk_vcodec_dec_get_shm_buffer_va(vpu->ctx->dev->optee_private, hw_id,
+							   OPTEE_MSG_INDEX);
+		vpu_dec_ipi_handler(ack_msg, 0, vpu->ctx->dev);
+	}
+
 	if (err) {
 		mtk_vdec_err(vpu->ctx, "send fail vpu_id=%d msg_id=%X status=%d",
 			     id, msgid, err);
@@ -213,7 +246,11 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
 		return err;
 	}
 
-	if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
+	/* Using tee interface to communicate with optee os directly for SVP mode,
+	 * fw ipi interface is used for normal playback.
+	 */
+	if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE &&
+	    !vpu->ctx->is_secure_playback) {
 		err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
 						 vpu->core_id, vpu->handler,
 						 "vdec", vpu->ctx->dev);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h
index fbb3f34a73f0..946e5abcc7d3 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.h
@@ -28,6 +28,8 @@ struct mtk_vcodec_dec_ctx;
  * @codec_type     : use codec type to separate different codecs
  * @capture_type:	used capture type to separate different capture format
  * @fb_sz  : frame buffer size of each plane
+ * @lat_optee_info  : used to send msg to optee shm buffer
+ * @core_optee_info  : used to send msg to optee shm buffer
  */
 struct vdec_vpu_inst {
 	int id;
@@ -44,6 +46,8 @@ struct vdec_vpu_inst {
 	unsigned int codec_type;
 	unsigned int capture_type;
 	unsigned int fb_sz[2];
+	struct mtk_vdec_optee_data_to_shm lat_optee_info;
+	struct mtk_vdec_optee_data_to_shm core_optee_info;
 };
 
 /**
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:30 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:30 +0800
Subject: [PATCH v3,13/21] media: mediatek: vcodec: using shared memory as vsi address
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-14-yunfei.dong@mediatek.com>

The vsi buffer is allocated by tee share memory for svp mode, need to
use the share memory as the vsi address to store vsi data.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c         | 9 +++++++--
 .../media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c | 8 ++++++--
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
index 0e741e0dc8ba..4967e0f0984d 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
@@ -417,8 +417,13 @@ static int vdec_h264_slice_init(struct mtk_vcodec_dec_ctx *ctx)
 
 	vsi_size = round_up(sizeof(struct vdec_h264_slice_vsi), VCODEC_DEC_ALIGNED_64);
 	inst->vsi = inst->vpu.vsi;
-	inst->vsi_core =
-		(struct vdec_h264_slice_vsi *)(((char *)inst->vpu.vsi) + vsi_size);
+	if (ctx->is_secure_playback)
+		inst->vsi_core =
+			mtk_vcodec_dec_get_shm_buffer_va(ctx->dev->optee_private, MTK_VDEC_CORE,
+							 OPTEE_DATA_INDEX);
+	else
+		inst->vsi_core =
+			(struct vdec_h264_slice_vsi *)(((char *)inst->vpu.vsi) + vsi_size);
 	inst->resolution_changed = true;
 	inst->realloc_mv_buf = true;
 
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
index 5336769a3fb5..5c31641e9abe 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
@@ -18,8 +18,12 @@ static void handle_init_ack_msg(const struct vdec_vpu_ipi_init_ack *msg)
 
 	/* mapping VPU address to kernel virtual address */
 	/* the content in vsi is initialized to 0 in VPU */
-	vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
-					     msg->vpu_inst_addr);
+	if (vpu->ctx->is_secure_playback)
+		vpu->vsi = mtk_vcodec_dec_get_shm_buffer_va(vpu->ctx->dev->optee_private,
+							    MTK_VDEC_LAT0, OPTEE_DATA_INDEX);
+	else
+		vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
+						     msg->vpu_inst_addr);
 	vpu->inst_addr = msg->vpu_inst_addr;
 
 	mtk_vdec_debug(vpu->ctx, "- vpu_inst_addr = 0x%x", vpu->inst_addr);
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:38 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:38 +0800
Subject: [PATCH v3,21/21] media: mediatek: vcodec: move vdec init interface to setup callback
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-22-yunfei.dong@mediatek.com>

Getting secure video playback (svp) flag when request output buffer, then
calling init interface to init svp parameters in optee-os.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../mediatek/vcodec/decoder/mtk_vcodec_dec.c  | 144 ++++++++++++------
 1 file changed, 94 insertions(+), 50 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
index ab922e8d2d37..3639beac20cb 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
@@ -184,6 +184,74 @@ void mtk_vcodec_dec_set_default_params(struct mtk_vcodec_dec_ctx *ctx)
 	q_data->bytesperline[1] = q_data->coded_width;
 }
 
+static int mtk_vcodec_dec_init_pic_info(struct mtk_vcodec_dec_ctx *ctx, enum v4l2_buf_type type)
+{
+	const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata;
+	struct mtk_q_data *q_data;
+	int ret;
+
+	if (!ctx->current_codec)
+		return 0;
+
+	if (V4L2_TYPE_IS_OUTPUT(type) && ctx->state == MTK_STATE_FREE) {
+		q_data = mtk_vdec_get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE);
+		if (!q_data)
+			return -EINVAL;
+
+		ret = vdec_if_init(ctx, q_data->fmt->fourcc);
+		if (ret) {
+			mtk_v4l2_vdec_err(ctx, "[%d]: vdec_if_init() fail ret=%d",
+					  ctx->id, ret);
+			return -EINVAL;
+		}
+		ctx->state = MTK_STATE_INIT;
+	}
+
+	if (!dec_pdata->uses_stateless_api)
+		return 0;
+
+	/*
+	 * If get pic info fail, need to use the default pic info params, or
+	 * v4l2-compliance will fail
+	 */
+	ret = vdec_if_get_param(ctx, GET_PARAM_PIC_INFO, &ctx->picinfo);
+	if (ret) {
+		mtk_v4l2_vdec_err(ctx, "[%d]Error!! Get GET_PARAM_PICTURE_INFO Fail",
+				  ctx->id);
+	}
+
+	ctx->last_decoded_picinfo = ctx->picinfo;
+
+	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 1) {
+		ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
+			ctx->picinfo.fb_sz[0] +
+			ctx->picinfo.fb_sz[1];
+		ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
+			ctx->picinfo.buf_w;
+	} else {
+		if (ctx->is_secure_playback)
+			ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
+				ctx->picinfo.fb_sz[0] + ctx->picinfo.fb_sz[1];
+		else
+			ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] = ctx->picinfo.fb_sz[0];
+
+		ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = ctx->picinfo.buf_w;
+		ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] = ctx->picinfo.fb_sz[1];
+		ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] = ctx->picinfo.buf_w;
+	}
+
+	ctx->q_data[MTK_Q_DATA_DST].coded_width = ctx->picinfo.buf_w;
+	ctx->q_data[MTK_Q_DATA_DST].coded_height = ctx->picinfo.buf_h;
+	mtk_v4l2_vdec_dbg(2, ctx,
+			  "[%d] init() plane:%d wxh=%dx%d pic wxh=%dx%d sz=0x%x_0x%x",
+			  ctx->id, q_data->fmt->num_planes,
+			  ctx->picinfo.buf_w, ctx->picinfo.buf_h,
+			  ctx->picinfo.pic_w, ctx->picinfo.pic_h,
+			  ctx->q_data[MTK_Q_DATA_DST].sizeimage[0],
+			  ctx->q_data[MTK_Q_DATA_DST].sizeimage[1]);
+	return 0;
+}
+
 static int vidioc_vdec_qbuf(struct file *file, void *priv,
 			    struct v4l2_buffer *buf)
 {
@@ -479,17 +547,7 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
 		ctx->ycbcr_enc = pix_mp->ycbcr_enc;
 		ctx->quantization = pix_mp->quantization;
 		ctx->xfer_func = pix_mp->xfer_func;
-
 		ctx->current_codec = fmt->fourcc;
-		if (ctx->state == MTK_STATE_FREE) {
-			ret = vdec_if_init(ctx, q_data->fmt->fourcc);
-			if (ret) {
-				mtk_v4l2_vdec_err(ctx, "[%d]: vdec_if_init() fail ret=%d",
-						  ctx->id, ret);
-				return -EINVAL;
-			}
-			ctx->state = MTK_STATE_INIT;
-		}
 	} else {
 		ctx->capture_fourcc = fmt->fourcc;
 	}
@@ -502,46 +560,11 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
 		ctx->picinfo.pic_w = pix_mp->width;
 		ctx->picinfo.pic_h = pix_mp->height;
 
-		/*
-		 * If get pic info fail, need to use the default pic info params, or
-		 * v4l2-compliance will fail
-		 */
-		ret = vdec_if_get_param(ctx, GET_PARAM_PIC_INFO, &ctx->picinfo);
-		if (ret) {
-			mtk_v4l2_vdec_err(ctx, "[%d]Error!! Get GET_PARAM_PICTURE_INFO Fail",
-					  ctx->id);
-		}
-
-		ctx->last_decoded_picinfo = ctx->picinfo;
-
-		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 1) {
-			ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
-				ctx->picinfo.fb_sz[0] +
-				ctx->picinfo.fb_sz[1];
-			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
-				ctx->picinfo.buf_w;
-		} else {
-			ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
-				ctx->picinfo.fb_sz[0];
-			ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
-				ctx->picinfo.buf_w;
-			ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] =
-				ctx->picinfo.fb_sz[1];
-			ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] =
-				ctx->picinfo.buf_w;
-		}
-
-		ctx->q_data[MTK_Q_DATA_DST].coded_width = ctx->picinfo.buf_w;
-		ctx->q_data[MTK_Q_DATA_DST].coded_height = ctx->picinfo.buf_h;
-		mtk_v4l2_vdec_dbg(2, ctx,
-				  "[%d] init() plane:%d wxh=%dx%d pic wxh=%dx%d sz=0x%x_0x%x",
-				  ctx->id, pix_mp->num_planes,
-				  ctx->picinfo.buf_w, ctx->picinfo.buf_h,
-				  ctx->picinfo.pic_w, ctx->picinfo.pic_h,
-				  ctx->q_data[MTK_Q_DATA_DST].sizeimage[0],
-				  ctx->q_data[MTK_Q_DATA_DST].sizeimage[1]);
+		if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+			ret = mtk_vcodec_dec_init_pic_info(ctx, f->type);
 	}
-	return 0;
+
+	return ret;
 }
 
 static int vidioc_enum_framesizes(struct file *file, void *priv,
@@ -722,7 +745,7 @@ int vb2ops_vdec_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
 {
 	struct mtk_vcodec_dec_ctx *ctx = vb2_get_drv_priv(vq);
 	struct mtk_q_data *q_data;
-	unsigned int i;
+	unsigned int i, ret;
 
 	q_data = mtk_vdec_get_q_data(ctx, vq->type);
 
@@ -731,6 +754,25 @@ int vb2ops_vdec_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
 		return -EINVAL;
 	}
 
+	if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+		ret = mtk_vcodec_dec_init_pic_info(ctx, vq->type);
+		if (ret) {
+			mtk_v4l2_vdec_err(ctx, "Failed to init picture information");
+			return ret;
+		}
+
+		if (vq->secure_mem && !ctx->is_secure_playback) {
+			ret = mtk_vcodec_dec_optee_open(ctx->dev->optee_private);
+			if (ret) {
+				mtk_v4l2_vdec_err(ctx, "Failed to open decoder optee os");
+				return ret;
+			}
+			ctx->is_secure_playback = vq->secure_mem;
+			mtk_v4l2_vdec_dbg(1, ctx, "Getting secure decoder mode:%d",
+					  ctx->is_secure_playback);
+		}
+	}
+
 	if (*nplanes) {
 		if (vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 			if (*nplanes != q_data->fmt->num_planes)
@@ -980,6 +1022,7 @@ int mtk_vcodec_dec_queue_init(void *priv, struct vb2_queue *src_vq,
 	src_vq->lock		= &ctx->dev->dev_mutex;
 	src_vq->dev             = &ctx->dev->plat_dev->dev;
 	src_vq->allow_cache_hints = 1;
+	src_vq->allow_secure_mem = 1;
 
 	ret = vb2_queue_init(src_vq);
 	if (ret) {
@@ -996,6 +1039,7 @@ int mtk_vcodec_dec_queue_init(void *priv, struct vb2_queue *src_vq,
 	dst_vq->lock		= &ctx->dev->dev_mutex;
 	dst_vq->dev             = &ctx->dev->plat_dev->dev;
 	dst_vq->allow_cache_hints = 1;
+	dst_vq->allow_secure_mem = 1;
 
 	ret = vb2_queue_init(dst_vq);
 	if (ret)
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:34 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:34 +0800
Subject: [PATCH v3,17/21] media: medkatek: vcodec: re-construct h264 driver to support svp mode
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-18-yunfei.dong@mediatek.com>

Need secure buffer size to convert secure handle to secure
pa in optee-os, re-construct the vsi struct to store each
secure buffer size.

Separate svp and normal wait interrupt condition for svp mode
waiting hardware interrupt in optee-os.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../decoder/vdec/vdec_h264_req_multi_if.c     | 261 +++++++++++-------
 .../mediatek/vcodec/decoder/vdec_msg_queue.c  |   9 +-
 2 files changed, 168 insertions(+), 102 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
index 4967e0f0984d..a1a68487131c 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
@@ -60,14 +60,36 @@ struct vdec_h264_slice_lat_dec_param {
  * @crc:		Used to check whether hardware's status is right
  */
 struct vdec_h264_slice_info {
+	u64 wdma_end_addr_offset;
 	u16 nal_info;
 	u16 timeout;
-	u32 bs_buf_size;
-	u64 bs_buf_addr;
-	u64 y_fb_dma;
-	u64 c_fb_dma;
 	u64 vdec_fb_va;
 	u32 crc[8];
+	u32 reserved;
+};
+
+/*
+ * struct vdec_h264_slice_mem - memory address and size
+ */
+struct vdec_h264_slice_mem {
+	union {
+		u64 buf;
+		u64 dma_addr;
+	};
+	union {
+		size_t size;
+		u64 dma_addr_end;
+	};
+};
+
+/**
+ * struct vdec_h264_slice_fb - frame buffer for decoding
+ * @y:  current y buffer address info
+ * @c:  current c buffer address info
+ */
+struct vdec_h264_slice_fb {
+	struct vdec_h264_slice_mem y;
+	struct vdec_h264_slice_mem c;
 };
 
 /**
@@ -92,18 +114,16 @@ struct vdec_h264_slice_info {
  */
 struct vdec_h264_slice_vsi {
 	/* LAT dec addr */
-	u64 wdma_err_addr;
-	u64 wdma_start_addr;
-	u64 wdma_end_addr;
-	u64 slice_bc_start_addr;
-	u64 slice_bc_end_addr;
-	u64 row_info_start_addr;
-	u64 row_info_end_addr;
-	u64 trans_start;
-	u64 trans_end;
-	u64 wdma_end_addr_offset;
+	struct vdec_h264_slice_mem bs;
+	struct vdec_h264_slice_fb fb;
 
-	u64 mv_buf_dma[H264_MAX_MV_NUM];
+	struct vdec_h264_slice_mem ube;
+	struct vdec_h264_slice_mem trans;
+	struct vdec_h264_slice_mem row_info;
+	struct vdec_h264_slice_mem err_map;
+	struct vdec_h264_slice_mem slice_bc;
+
+	struct vdec_h264_slice_mem mv_buf_dma[H264_MAX_MV_NUM];
 	struct vdec_h264_slice_info dec;
 	struct vdec_h264_slice_lat_dec_param h264_slice_params;
 };
@@ -392,6 +412,100 @@ static void vdec_h264_slice_get_crop_info(struct vdec_h264_slice_inst *inst,
 		       cr->left, cr->top, cr->width, cr->height);
 }
 
+static void vdec_h264_slice_setup_lat_buffer(struct vdec_h264_slice_inst *inst,
+					     struct mtk_vcodec_mem *bs,
+					     struct vdec_lat_buf *lat_buf)
+{
+	struct mtk_vcodec_mem *mem;
+	int i;
+
+	inst->vsi->bs.dma_addr = (u64)bs->dma_addr;
+	inst->vsi->bs.size = bs->size;
+
+	for (i = 0; i < H264_MAX_MV_NUM; i++) {
+		mem = &inst->mv_buf[i];
+		inst->vsi->mv_buf_dma[i].dma_addr = mem->dma_addr;
+		inst->vsi->mv_buf_dma[i].size = mem->size;
+	}
+	inst->vsi->ube.dma_addr = lat_buf->ctx->msg_queue.wdma_addr.dma_addr;
+	inst->vsi->ube.size = lat_buf->ctx->msg_queue.wdma_addr.size;
+
+	inst->vsi->row_info.dma_addr = 0;
+	inst->vsi->row_info.size = 0;
+
+	inst->vsi->err_map.dma_addr = lat_buf->wdma_err_addr.dma_addr;
+	inst->vsi->err_map.size = lat_buf->wdma_err_addr.size;
+
+	inst->vsi->slice_bc.dma_addr = lat_buf->slice_bc_addr.dma_addr;
+	inst->vsi->slice_bc.size = lat_buf->slice_bc_addr.size;
+
+	inst->vsi->trans.dma_addr_end = inst->ctx->msg_queue.wdma_rptr_addr;
+	inst->vsi->trans.dma_addr = inst->ctx->msg_queue.wdma_wptr_addr;
+}
+
+static int vdec_h264_slice_setup_core_buffer(struct vdec_h264_slice_inst *inst,
+					     struct vdec_h264_slice_share_info *share_info,
+					     struct vdec_lat_buf *lat_buf)
+{
+	struct mtk_vcodec_mem *mem;
+	struct mtk_vcodec_dec_ctx *ctx = inst->ctx;
+	struct vb2_v4l2_buffer *vb2_v4l2;
+	struct vdec_fb *fb;
+	u64 y_fb_dma, c_fb_dma = 0;
+	int i;
+
+	fb = ctx->dev->vdec_pdata->get_cap_buffer(ctx);
+	if (!fb) {
+		mtk_vdec_err(ctx, "fb buffer is NULL");
+		return -EBUSY;
+	}
+
+	y_fb_dma = (u64)fb->base_y.dma_addr;
+	if (!ctx->is_secure_playback) {
+		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 1)
+			c_fb_dma =
+				y_fb_dma + inst->ctx->picinfo.buf_w * inst->ctx->picinfo.buf_h;
+		else
+			c_fb_dma = (u64)fb->base_c.dma_addr;
+	}
+
+	mtk_vdec_debug(ctx, "[h264-core] y/c addr = 0x%llx 0x%llx", y_fb_dma, c_fb_dma);
+
+	inst->vsi_core->fb.y.dma_addr = y_fb_dma;
+	inst->vsi_core->fb.y.size = ctx->picinfo.fb_sz[0];
+	inst->vsi_core->fb.c.dma_addr = c_fb_dma;
+	inst->vsi_core->fb.c.size = ctx->picinfo.fb_sz[1];
+
+	inst->vsi_core->dec.vdec_fb_va = (unsigned long)fb;
+	inst->vsi_core->dec.nal_info = share_info->nal_info;
+
+	inst->vsi_core->ube.dma_addr = lat_buf->ctx->msg_queue.wdma_addr.dma_addr;
+	inst->vsi_core->ube.size = lat_buf->ctx->msg_queue.wdma_addr.size;
+
+	inst->vsi_core->err_map.dma_addr = lat_buf->wdma_err_addr.dma_addr;
+	inst->vsi_core->err_map.size = lat_buf->wdma_err_addr.size;
+
+	inst->vsi_core->slice_bc.dma_addr = lat_buf->slice_bc_addr.dma_addr;
+	inst->vsi_core->slice_bc.size = lat_buf->slice_bc_addr.size;
+
+	inst->vsi_core->row_info.dma_addr = 0;
+	inst->vsi_core->row_info.size = 0;
+
+	inst->vsi_core->trans.dma_addr = share_info->trans_start;
+	inst->vsi_core->trans.dma_addr_end = share_info->trans_end;
+
+	for (i = 0; i < H264_MAX_MV_NUM; i++) {
+		mem = &inst->mv_buf[i];
+		inst->vsi_core->mv_buf_dma[i].dma_addr = mem->dma_addr;
+		inst->vsi_core->mv_buf_dma[i].size = mem->size;
+	}
+
+	vb2_v4l2 = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
+	v4l2_m2m_buf_copy_metadata(&lat_buf->ts_info, vb2_v4l2, true);
+
+	return 0;
+}
+
 static int vdec_h264_slice_init(struct mtk_vcodec_dec_ctx *ctx)
 {
 	struct vdec_h264_slice_inst *inst;
@@ -457,64 +571,22 @@ static void vdec_h264_slice_deinit(void *h_vdec)
 
 static int vdec_h264_slice_core_decode(struct vdec_lat_buf *lat_buf)
 {
-	struct vdec_fb *fb;
-	u64 vdec_fb_va;
-	u64 y_fb_dma, c_fb_dma;
-	int err, timeout, i;
+	int err, timeout;
 	struct mtk_vcodec_dec_ctx *ctx = lat_buf->ctx;
 	struct vdec_h264_slice_inst *inst = ctx->drv_handle;
-	struct vb2_v4l2_buffer *vb2_v4l2;
 	struct vdec_h264_slice_share_info *share_info = lat_buf->private_data;
-	struct mtk_vcodec_mem *mem;
 	struct vdec_vpu_inst *vpu = &inst->vpu;
 
 	mtk_vdec_debug(ctx, "[h264-core] vdec_h264 core decode");
 	memcpy(&inst->vsi_core->h264_slice_params, &share_info->h264_slice_params,
 	       sizeof(share_info->h264_slice_params));
 
-	fb = ctx->dev->vdec_pdata->get_cap_buffer(ctx);
-	if (!fb) {
-		err = -EBUSY;
-		mtk_vdec_err(ctx, "fb buffer is NULL");
+	err = vdec_h264_slice_setup_core_buffer(inst, share_info, lat_buf);
+	if (err)
 		goto vdec_dec_end;
-	}
-
-	vdec_fb_va = (unsigned long)fb;
-	y_fb_dma = (u64)fb->base_y.dma_addr;
-	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 1)
-		c_fb_dma =
-			y_fb_dma + inst->ctx->picinfo.buf_w * inst->ctx->picinfo.buf_h;
-	else
-		c_fb_dma = (u64)fb->base_c.dma_addr;
-
-	mtk_vdec_debug(ctx, "[h264-core] y/c addr = 0x%llx 0x%llx", y_fb_dma, c_fb_dma);
-
-	inst->vsi_core->dec.y_fb_dma = y_fb_dma;
-	inst->vsi_core->dec.c_fb_dma = c_fb_dma;
-	inst->vsi_core->dec.vdec_fb_va = vdec_fb_va;
-	inst->vsi_core->dec.nal_info = share_info->nal_info;
-	inst->vsi_core->wdma_start_addr =
-		lat_buf->ctx->msg_queue.wdma_addr.dma_addr;
-	inst->vsi_core->wdma_end_addr =
-		lat_buf->ctx->msg_queue.wdma_addr.dma_addr +
-		lat_buf->ctx->msg_queue.wdma_addr.size;
-	inst->vsi_core->wdma_err_addr = lat_buf->wdma_err_addr.dma_addr;
-	inst->vsi_core->slice_bc_start_addr = lat_buf->slice_bc_addr.dma_addr;
-	inst->vsi_core->slice_bc_end_addr = lat_buf->slice_bc_addr.dma_addr +
-		lat_buf->slice_bc_addr.size;
-	inst->vsi_core->trans_start = share_info->trans_start;
-	inst->vsi_core->trans_end = share_info->trans_end;
-	for (i = 0; i < H264_MAX_MV_NUM; i++) {
-		mem = &inst->mv_buf[i];
-		inst->vsi_core->mv_buf_dma[i] = mem->dma_addr;
-	}
-
-	vb2_v4l2 = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
-	v4l2_m2m_buf_copy_metadata(&lat_buf->ts_info, vb2_v4l2, true);
 
 	vdec_h264_slice_fill_decode_reflist(inst, &inst->vsi_core->h264_slice_params,
 					    share_info);
-
 	err = vpu_dec_core(vpu);
 	if (err) {
 		mtk_vdec_err(ctx, "core decode err=%d", err);
@@ -573,12 +645,11 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	struct vdec_h264_slice_inst *inst = h_vdec;
 	struct vdec_vpu_inst *vpu = &inst->vpu;
 	struct mtk_video_dec_buf *src_buf_info;
-	int nal_start_idx, err, timeout = 0, i;
+	int nal_start_idx, err, timeout = 0;
 	unsigned int data[2];
 	struct vdec_lat_buf *lat_buf;
 	struct vdec_h264_slice_share_info *share_info;
 	unsigned char *buf;
-	struct mtk_vcodec_mem *mem;
 
 	if (vdec_msg_queue_init(&inst->ctx->msg_queue, inst->ctx,
 				vdec_h264_slice_core_decode,
@@ -617,11 +688,9 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	if (err)
 		goto err_free_fb_out;
 
-	vdec_h264_insert_startcode(inst->ctx->dev, buf, &bs->size,
-				   &share_info->h264_slice_params.pps);
-
-	inst->vsi->dec.bs_buf_addr = (uint64_t)bs->dma_addr;
-	inst->vsi->dec.bs_buf_size = bs->size;
+	if (!inst->ctx->is_secure_playback)
+		vdec_h264_insert_startcode(inst->ctx->dev, buf, &bs->size,
+					   &share_info->h264_slice_params.pps);
 
 	*res_chg = inst->resolution_changed;
 	if (inst->resolution_changed) {
@@ -634,38 +703,27 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 		}
 		inst->resolution_changed = false;
 	}
-	for (i = 0; i < H264_MAX_MV_NUM; i++) {
-		mem = &inst->mv_buf[i];
-		inst->vsi->mv_buf_dma[i] = mem->dma_addr;
-	}
-	inst->vsi->wdma_start_addr = lat_buf->ctx->msg_queue.wdma_addr.dma_addr;
-	inst->vsi->wdma_end_addr = lat_buf->ctx->msg_queue.wdma_addr.dma_addr +
-		lat_buf->ctx->msg_queue.wdma_addr.size;
-	inst->vsi->wdma_err_addr = lat_buf->wdma_err_addr.dma_addr;
-	inst->vsi->slice_bc_start_addr = lat_buf->slice_bc_addr.dma_addr;
-	inst->vsi->slice_bc_end_addr = lat_buf->slice_bc_addr.dma_addr +
-		lat_buf->slice_bc_addr.size;
-
-	inst->vsi->trans_end = inst->ctx->msg_queue.wdma_rptr_addr;
-	inst->vsi->trans_start = inst->ctx->msg_queue.wdma_wptr_addr;
-	mtk_vdec_debug(inst->ctx, "lat:trans(0x%llx 0x%llx) err:0x%llx",
-		       inst->vsi->wdma_start_addr,
-		       inst->vsi->wdma_end_addr,
-		       inst->vsi->wdma_err_addr);
-
-	mtk_vdec_debug(inst->ctx, "slice(0x%llx 0x%llx) rprt((0x%llx 0x%llx))",
-		       inst->vsi->slice_bc_start_addr,
-		       inst->vsi->slice_bc_end_addr,
-		       inst->vsi->trans_start,
-		       inst->vsi->trans_end);
+
+	vdec_h264_slice_setup_lat_buffer(inst, bs, lat_buf);
+	mtk_vdec_debug(inst->ctx, "lat:trans(0x%llx 0x%lx) err:0x%llx",
+		       inst->vsi->ube.dma_addr, (unsigned long)inst->vsi->ube.size,
+		       inst->vsi->err_map.dma_addr);
+
+	mtk_vdec_debug(inst->ctx, "slice(0x%llx 0x%lx) rprt((0x%llx 0x%llx))",
+		       inst->vsi->slice_bc.dma_addr, (unsigned long)inst->vsi->slice_bc.size,
+		       inst->vsi->trans.dma_addr, inst->vsi->trans.dma_addr_end);
 	err = vpu_dec_start(vpu, data, 2);
 	if (err) {
 		mtk_vdec_debug(inst->ctx, "lat decode err: %d", err);
 		goto err_free_fb_out;
 	}
 
-	share_info->trans_end = inst->ctx->msg_queue.wdma_addr.dma_addr +
-		inst->vsi->wdma_end_addr_offset;
+	if (inst->ctx->is_secure_playback)
+		share_info->trans_end = inst->vsi->dec.wdma_end_addr_offset;
+	else
+		share_info->trans_end = inst->ctx->msg_queue.wdma_addr.dma_addr +
+			inst->vsi->dec.wdma_end_addr_offset;
+
 	share_info->trans_start = inst->ctx->msg_queue.wdma_wptr_addr;
 	share_info->nal_info = inst->vsi->dec.nal_info;
 
@@ -691,8 +749,11 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 		return -EINVAL;
 	}
 
-	share_info->trans_end = inst->ctx->msg_queue.wdma_addr.dma_addr +
-		inst->vsi->wdma_end_addr_offset;
+	if (inst->ctx->is_secure_playback)
+		share_info->trans_end = inst->vsi->dec.wdma_end_addr_offset;
+	else
+		share_info->trans_end = inst->ctx->msg_queue.wdma_addr.dma_addr +
+			inst->vsi->dec.wdma_end_addr_offset;
 	vdec_msg_queue_update_ube_wptr(&lat_buf->ctx->msg_queue, share_info->trans_end);
 
 	if (!IS_VDEC_INNER_RACING(inst->ctx->dev->dec_capability)) {
@@ -737,10 +798,10 @@ static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs
 	mtk_vdec_debug(inst->ctx, "[h264-dec] [%d] y_dma=%llx c_dma=%llx",
 		       inst->ctx->decoded_frame_cnt, y_fb_dma, c_fb_dma);
 
-	inst->vsi_ctx.dec.bs_buf_addr = (u64)bs->dma_addr;
-	inst->vsi_ctx.dec.bs_buf_size = bs->size;
-	inst->vsi_ctx.dec.y_fb_dma = y_fb_dma;
-	inst->vsi_ctx.dec.c_fb_dma = c_fb_dma;
+	inst->vsi_ctx.bs.dma_addr = (u64)bs->dma_addr;
+	inst->vsi_ctx.bs.size = bs->size;
+	inst->vsi_ctx.fb.y.dma_addr = y_fb_dma;
+	inst->vsi_ctx.fb.c.dma_addr = c_fb_dma;
 	inst->vsi_ctx.dec.vdec_fb_va = (u64)(uintptr_t)fb;
 
 	v4l2_m2m_buf_copy_metadata(&src_buf_info->m2m_buf.vb,
@@ -770,7 +831,7 @@ static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs
 
 		for (i = 0; i < H264_MAX_MV_NUM; i++) {
 			mem = &inst->mv_buf[i];
-			inst->vsi_ctx.mv_buf_dma[i] = mem->dma_addr;
+			inst->vsi_ctx.mv_buf_dma[i].dma_addr = mem->dma_addr;
 		}
 	}
 
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
index f283c4703dc6..c1310176ae05 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
@@ -308,8 +308,13 @@ int vdec_msg_queue_init(struct vdec_msg_queue *msg_queue,
 		msg_queue->wdma_addr.size = 0;
 		return -ENOMEM;
 	}
-	msg_queue->wdma_rptr_addr = msg_queue->wdma_addr.dma_addr;
-	msg_queue->wdma_wptr_addr = msg_queue->wdma_addr.dma_addr;
+	if (ctx->is_secure_playback) {
+		msg_queue->wdma_rptr_addr = 0;
+		msg_queue->wdma_wptr_addr = 0;
+	} else {
+		msg_queue->wdma_rptr_addr = msg_queue->wdma_addr.dma_addr;
+		msg_queue->wdma_wptr_addr = msg_queue->wdma_addr.dma_addr;
+	}
 
 	msg_queue->empty_lat_buf.ctx = ctx;
 	msg_queue->empty_lat_buf.core_decode = NULL;
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:29 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:29 +0800
Subject: [PATCH v3,12/21] media: mediatek: vcodec: add interface to allocate/free secure memory
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-13-yunfei.dong@mediatek.com>

Need to call dma heap interface to allocate/free secure memory when playing
secure video.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../media/platform/mediatek/vcodec/Kconfig    |   1 +
 .../mediatek/vcodec/common/mtk_vcodec_util.c  | 122 +++++++++++++++++-
 .../mediatek/vcodec/common/mtk_vcodec_util.h  |   3 +
 3 files changed, 123 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/Kconfig b/drivers/media/platform/mediatek/vcodec/Kconfig
index bc8292232530..707865703e61 100644
--- a/drivers/media/platform/mediatek/vcodec/Kconfig
+++ b/drivers/media/platform/mediatek/vcodec/Kconfig
@@ -17,6 +17,7 @@ config VIDEO_MEDIATEK_VCODEC
 	depends on VIDEO_MEDIATEK_VPU || !VIDEO_MEDIATEK_VPU
 	depends on MTK_SCP || !MTK_SCP
 	depends on MTK_SMI || (COMPILE_TEST && MTK_SMI=n)
+	depends on DMABUF_HEAPS
 	select VIDEOBUF2_DMA_CONTIG
 	select V4L2_MEM2MEM_DEV
 	select VIDEO_MEDIATEK_VCODEC_VPU if VIDEO_MEDIATEK_VPU
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
index 9ce34a3b5ee6..2c44747f77a0 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
@@ -5,9 +5,11 @@
 *	Tiffany Lin <tiffany.lin at mediatek.com>
 */
 
+#include <linux/dma-heap.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/regmap.h>
+#include <uapi/linux/dma-heap.h>
 
 #include "../decoder/mtk_vcodec_dec_drv.h"
 #include "../encoder/mtk_vcodec_enc_drv.h"
@@ -45,7 +47,7 @@ int mtk_vcodec_write_vdecsys(struct mtk_vcodec_dec_ctx *ctx, unsigned int reg,
 }
 EXPORT_SYMBOL(mtk_vcodec_write_vdecsys);
 
-int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
+static int mtk_vcodec_mem_alloc_nor(void *priv, struct mtk_vcodec_mem *mem)
 {
 	enum mtk_instance_type inst_type = *((unsigned int *)priv);
 	struct platform_device *plat_dev;
@@ -76,9 +78,71 @@ int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
 
 	return 0;
 }
-EXPORT_SYMBOL(mtk_vcodec_mem_alloc);
 
-void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
+static int mtk_vcodec_mem_alloc_sec(struct mtk_vcodec_dec_ctx *ctx, struct mtk_vcodec_mem *mem)
+{
+	struct device *dev = &ctx->dev->plat_dev->dev;
+	struct dma_buf *dma_buffer;
+	struct dma_heap *vdec_heap;
+	struct dma_buf_attachment *attach;
+	struct sg_table *sgt;
+	unsigned long size = mem->size;
+	int ret = 0;
+
+	if (!size)
+		return -EINVAL;
+
+	vdec_heap = dma_heap_find("mtk_svp");
+	if (!vdec_heap) {
+		mtk_v4l2_vdec_err(ctx, "dma heap find failed!");
+		return -EPERM;
+	}
+
+	dma_buffer = dma_heap_buffer_alloc(vdec_heap, size, DMA_HEAP_VALID_FD_FLAGS,
+					   DMA_HEAP_VALID_HEAP_FLAGS);
+	if (IS_ERR_OR_NULL(dma_buffer)) {
+		mtk_v4l2_vdec_err(ctx, "dma heap alloc size=0x%lx failed!", size);
+		return PTR_ERR(dma_buffer);
+	}
+
+	attach = dma_buf_attach(dma_buffer, dev);
+	if (IS_ERR_OR_NULL(attach)) {
+		mtk_v4l2_vdec_err(ctx, "dma attach size=0x%lx failed!", size);
+		ret = PTR_ERR(attach);
+		goto err_attach;
+	}
+
+	sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+	if (IS_ERR_OR_NULL(sgt)) {
+		mtk_v4l2_vdec_err(ctx, "dma map attach size=0x%lx failed!", size);
+		ret = PTR_ERR(sgt);
+		goto err_sgt;
+	}
+
+	mem->va = dma_buffer;
+	mem->dma_addr = (dma_addr_t)sg_dma_address((sgt)->sgl);
+
+	if (!mem->va || !mem->dma_addr) {
+		mtk_v4l2_vdec_err(ctx, "dma buffer size=0x%lx failed!", size);
+		ret = -EPERM;
+		goto err_addr;
+	}
+
+	mem->attach = attach;
+	mem->sgt = sgt;
+
+	return 0;
+err_addr:
+	dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+err_sgt:
+	dma_buf_detach(dma_buffer, attach);
+err_attach:
+	dma_buf_put(dma_buffer);
+
+	return ret;
+}
+
+static void mtk_vcodec_mem_free_nor(void *priv, struct mtk_vcodec_mem *mem)
 {
 	enum mtk_instance_type inst_type = *((unsigned int *)priv);
 	struct platform_device *plat_dev;
@@ -111,6 +175,57 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
 	mem->dma_addr = 0;
 	mem->size = 0;
 }
+
+static void mtk_vcodec_mem_free_sec(struct mtk_vcodec_mem *mem)
+{
+	if (mem->sgt)
+		dma_buf_unmap_attachment(mem->attach, mem->sgt, DMA_BIDIRECTIONAL);
+	dma_buf_detach((struct dma_buf *)mem->va, mem->attach);
+	dma_buf_put((struct dma_buf *)mem->va);
+
+	mem->attach = NULL;
+	mem->sgt = NULL;
+	mem->va = NULL;
+	mem->dma_addr = 0;
+	mem->size = 0;
+}
+
+int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
+{
+	enum mtk_instance_type inst_type = *((unsigned int *)priv);
+	int ret;
+
+	if (inst_type == MTK_INST_DECODER) {
+		struct mtk_vcodec_dec_ctx *dec_ctx = priv;
+
+		if (dec_ctx->is_secure_playback) {
+			ret = mtk_vcodec_mem_alloc_sec(dec_ctx, mem);
+			goto alloc_end;
+		}
+	}
+
+	ret = mtk_vcodec_mem_alloc_nor(priv, mem);
+alloc_end:
+
+	return ret;
+}
+EXPORT_SYMBOL(mtk_vcodec_mem_alloc);
+
+void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
+{
+	enum mtk_instance_type inst_type = *((unsigned int *)priv);
+
+	if (inst_type == MTK_INST_DECODER) {
+		struct mtk_vcodec_dec_ctx *dec_ctx = priv;
+
+		if (dec_ctx->is_secure_playback) {
+			mtk_vcodec_mem_free_sec(mem);
+			return;
+		}
+	}
+
+	mtk_vcodec_mem_free_nor(priv, mem);
+}
 EXPORT_SYMBOL(mtk_vcodec_mem_free);
 
 void *mtk_vcodec_get_hw_dev(struct mtk_vcodec_dec_dev *dev, int hw_idx)
@@ -172,3 +287,4 @@ EXPORT_SYMBOL(mtk_vcodec_get_curr_ctx);
 
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("Mediatek video codec driver");
+MODULE_IMPORT_NS(DMA_BUF);
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.h
index 85f615cdd4d3..22078e757ed0 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.h
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.h
@@ -18,6 +18,9 @@ struct mtk_vcodec_mem {
 	size_t size;
 	void *va;
 	dma_addr_t dma_addr;
+
+	struct dma_buf_attachment *attach;
+	struct sg_table *sgt;
 };
 
 struct mtk_vcodec_fb {
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:17 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:17 +0800
Subject: [PATCH v3,00/21] add driver to support secure video decoder
Message-ID: <20231206081538.17056-1-yunfei.dong@mediatek.com>

The patch series used to enable secure video playback (SVP) on MediaTek
hardware in the Linux kernel.

Memory Definitions:
secure memory - Memory allocated in the TEE (Trusted Execution
Environment) which is inaccessible in the REE (Rich Execution
Environment, i.e. linux kernel/userspace).
secure handle - Integer value which acts as reference to 'secure
memory'. Used in communication between TEE and REE to reference
'secure memory'.
secure buffer - 'secure memory' that is used to store decrypted,
compressed video or for other general purposes in the TEE.
secure surface - 'secure memory' that is used to store graphic buffers.

Memory Usage in SVP:
The overall flow of SVP starts with encrypted video coming in from an
outside source into the REE. The REE will then allocate a 'secure
buffer' and send the corresponding 'secure handle' along with the
encrypted, compressed video data to the TEE. The TEE will then decrypt
the video and store the result in the 'secure buffer'. The REE will
then allocate a 'secure surface'. The REE will pass the 'secure
handles' for both the 'secure buffer' and 'secure surface' into the
TEE for video decoding. The video decoder HW will then decode the
contents of the 'secure buffer' and place the result in the 'secure
surface'. The REE will then attach the 'secure surface' to the overlay
plane for rendering of the video.

Everything relating to ensuring security of the actual contents of the
'secure buffer' and 'secure surface' is out of scope for the REE and
is the responsibility of the TEE.

This patch series is consists of four parts. The first is from Jeffrey,
adding secure memory flag in v4l2 framework to support request secure
buffer.

The second and third parts are from John and T.J, adding some heap
interfaces, then our kernel users could allocate buffer from special
heap. The patch v1 is inside below dmabuf link.
https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu at mediatek.com/
To avoid confusing, move them into vcodec patchset since we use the
new interfaces directly.

The fourth part is mediatek decoder driver, adding tee interface to
support secure video decoder.

---
Changed in v3:
- rewrite the cover-letter of this patch series
- disable irq for svp mode
- rebase the driver based on the latest media stage

Changed in v2:
- remove setting decoder mode and getting secure handle from decode
- add Jeffrey's patch
- add John and T.J's patch
- getting secure flag with request buffer
- fix some comments from patch v1
---
Jeffrey Kardatzke (4):
  v4l2: add secure memory flags
  v4l2: handle secure memory flags in queue setup
  v4l2: verify secure dmabufs are used in secure queue
  v4l: add documentation for secure memory flag

John Stultz (2):
  dma-heap: Add proper kref handling on dma-buf heaps
  dma-heap: Provide accessors so that in-kernel drivers can allocate
    dmabufs from specific heaps

T.J. Mercier (1):
  dma-buf: heaps: Deduplicate docs and adopt common format

Yunfei Dong (14):
  media: mediatek: vcodec: add tee client interface to communiate with
    optee-os
  media: mediatek: vcodec: allocate tee share memory
  media: mediatek: vcodec: send share memory data to optee
  media: mediatek: vcodec: initialize msg and vsi information
  media: mediatek: vcodec: add interface to allocate/free secure memory
  media: mediatek: vcodec: using shared memory as vsi address
  media: mediatek: vcodec: Add capture format to support one plane
    memory
  media: mediatek: vcodec: Add one plane format
  media: medkatek: vcodec: support one plane capture buffer
  media: medkatek: vcodec: re-construct h264 driver to support svp mode
  media: medkatek: vcodec: remove parse nal_info in kernel
  media: medkatek: vcodec: disable wait interrupt for svp mode
  media: medkatek: vcodec: support tee decoder
  media: mediatek: vcodec: move vdec init interface to setup callback

 .../userspace-api/media/v4l/buffer.rst        |   8 +-
 .../media/v4l/pixfmt-reserved.rst             |   8 +
 drivers/dma-buf/dma-heap.c                    | 139 +++++--
 .../media/common/videobuf2/videobuf2-core.c   |  23 ++
 .../common/videobuf2/videobuf2-dma-contig.c   |   6 +
 .../media/common/videobuf2/videobuf2-dma-sg.c |   6 +
 .../media/common/videobuf2/videobuf2-v4l2.c   |  34 +-
 .../media/platform/mediatek/vcodec/Kconfig    |   1 +
 .../mediatek/vcodec/common/mtk_vcodec_util.c  | 122 +++++-
 .../mediatek/vcodec/common/mtk_vcodec_util.h  |   3 +
 .../platform/mediatek/vcodec/decoder/Makefile |   1 +
 .../mediatek/vcodec/decoder/mtk_vcodec_dec.c  | 155 ++++---
 .../vcodec/decoder/mtk_vcodec_dec_drv.c       |   8 +
 .../vcodec/decoder/mtk_vcodec_dec_drv.h       |   7 +
 .../vcodec/decoder/mtk_vcodec_dec_hw.c        |  34 +-
 .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 383 ++++++++++++++++++
 .../vcodec/decoder/mtk_vcodec_dec_optee.h     | 156 +++++++
 .../vcodec/decoder/mtk_vcodec_dec_pm.c        |   6 +-
 .../vcodec/decoder/mtk_vcodec_dec_stateless.c |  35 +-
 .../decoder/vdec/vdec_h264_req_common.c       |  11 +-
 .../decoder/vdec/vdec_h264_req_multi_if.c     | 334 +++++++++------
 .../mediatek/vcodec/decoder/vdec_drv_if.c     |   4 +-
 .../mediatek/vcodec/decoder/vdec_msg_queue.c  |   9 +-
 .../mediatek/vcodec/decoder/vdec_vpu_if.c     |  57 ++-
 .../mediatek/vcodec/decoder/vdec_vpu_if.h     |   4 +
 drivers/media/v4l2-core/v4l2-common.c         |   2 +
 drivers/media/v4l2-core/v4l2-ioctl.c          |   1 +
 include/linux/dma-heap.h                      |  29 +-
 include/media/videobuf2-core.h                |   8 +-
 include/uapi/linux/videodev2.h                |   3 +
 30 files changed, 1296 insertions(+), 301 deletions(-)
 create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
 create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h

-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:20 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:20 +0800
Subject: [PATCH v3,03/21] v4l2: verify secure dmabufs are used in secure queue
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-4-yunfei.dong@mediatek.com>

From: Jeffrey Kardatzke <jkardatzke at google.com>

Verfies in the dmabuf implementations that if the secure memory flag is
set for a queue that the dmabuf submitted to the queue is unmappable.

Signed-off-by: Jeffrey Kardatzke <jkardatzke at google.com>
Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 drivers/media/common/videobuf2/videobuf2-dma-contig.c | 6 ++++++
 drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 6 ++++++
 2 files changed, 12 insertions(+)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 3d4fd4ef5310..ad58ef8dc231 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -710,6 +710,12 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
 		return -EINVAL;
 	}
 
+	/* verify the dmabuf is secure if we are in secure mode */
+	if (buf->vb->vb2_queue->secure_mem && sg_page(sgt->sgl)) {
+		pr_err("secure queue requires secure dma_buf");
+		return -EINVAL;
+	}
+
 	/* checking if dmabuf is big enough to store contiguous chunk */
 	contig_size = vb2_dc_get_contiguous_size(sgt);
 	if (contig_size < buf->size) {
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 28f3fdfe23a2..55428c73c380 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -564,6 +564,12 @@ static int vb2_dma_sg_map_dmabuf(void *mem_priv)
 		return -EINVAL;
 	}
 
+	/* verify the dmabuf is secure if we are in secure mode */
+	if (buf->vb->vb2_queue->secure_mem && !sg_dma_secure(sgt->sgl)) {
+		pr_err("secure queue requires secure dma_buf");
+		return -EINVAL;
+	}
+
 	buf->dma_sgt = sgt;
 	buf->vaddr = NULL;
 
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:36 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:36 +0800
Subject: [PATCH v3,19/21] media: medkatek: vcodec: disable wait interrupt for svp mode
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-20-yunfei.dong@mediatek.com>

Waiting interrupt in optee-os for svp mode, need to disable it in kernel
in case of interrupt is cleaned.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_hw.c        | 34 +++++------
 .../vcodec/decoder/mtk_vcodec_dec_pm.c        |  6 +-
 .../decoder/vdec/vdec_h264_req_multi_if.c     | 57 +++++++++++--------
 3 files changed, 54 insertions(+), 43 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_hw.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_hw.c
index 881d5de41e05..1982c088c6da 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_hw.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_hw.c
@@ -72,26 +72,28 @@ static irqreturn_t mtk_vdec_hw_irq_handler(int irq, void *priv)
 
 	ctx = mtk_vcodec_get_curr_ctx(dev->main_dev, dev->hw_idx);
 
-	/* check if HW active or not */
-	cg_status = readl(dev->reg_base[VDEC_HW_SYS] + VDEC_HW_ACTIVE_ADDR);
-	if (cg_status & VDEC_HW_ACTIVE_MASK) {
-		mtk_v4l2_vdec_err(ctx, "vdec active is not 0x0 (0x%08x)", cg_status);
-		return IRQ_HANDLED;
-	}
+	if (!ctx->is_secure_playback) {
+		/* check if HW active or not */
+		cg_status = readl(dev->reg_base[VDEC_HW_SYS] + VDEC_HW_ACTIVE_ADDR);
+		if (cg_status & VDEC_HW_ACTIVE_MASK) {
+			mtk_v4l2_vdec_err(ctx, "vdec active is not 0x0 (0x%08x)", cg_status);
+			return IRQ_HANDLED;
+		}
 
-	dec_done_status = readl(vdec_misc_addr);
-	if ((dec_done_status & MTK_VDEC_IRQ_STATUS_DEC_SUCCESS) !=
-	    MTK_VDEC_IRQ_STATUS_DEC_SUCCESS)
-		return IRQ_HANDLED;
+		dec_done_status = readl(vdec_misc_addr);
+		if ((dec_done_status & MTK_VDEC_IRQ_STATUS_DEC_SUCCESS) !=
+		    MTK_VDEC_IRQ_STATUS_DEC_SUCCESS)
+			return IRQ_HANDLED;
 
-	/* clear interrupt */
-	writel(dec_done_status | VDEC_IRQ_CFG, vdec_misc_addr);
-	writel(dec_done_status & ~VDEC_IRQ_CLR, vdec_misc_addr);
+		/* clear interrupt */
+		writel(dec_done_status | VDEC_IRQ_CFG, vdec_misc_addr);
+		writel(dec_done_status & ~VDEC_IRQ_CLR, vdec_misc_addr);
 
-	wake_up_dec_ctx(ctx, MTK_INST_IRQ_RECEIVED, dev->hw_idx);
+		wake_up_dec_ctx(ctx, MTK_INST_IRQ_RECEIVED, dev->hw_idx);
 
-	mtk_v4l2_vdec_dbg(3, ctx, "wake up ctx %d, dec_done_status=%x",
-			  ctx->id, dec_done_status);
+		mtk_v4l2_vdec_dbg(3, ctx, "wake up ctx %d, dec_done_status=%x",
+				  ctx->id, dec_done_status);
+	}
 
 	return IRQ_HANDLED;
 }
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_pm.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_pm.c
index aefd3e9e3061..a94eda936f16 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_pm.c
@@ -238,7 +238,8 @@ void mtk_vcodec_dec_enable_hardware(struct mtk_vcodec_dec_ctx *ctx, int hw_idx)
 		mtk_vcodec_dec_child_dev_on(ctx->dev, MTK_VDEC_LAT0);
 	mtk_vcodec_dec_child_dev_on(ctx->dev, hw_idx);
 
-	mtk_vcodec_dec_enable_irq(ctx->dev, hw_idx);
+	if (!ctx->is_secure_playback)
+		mtk_vcodec_dec_enable_irq(ctx->dev, hw_idx);
 
 	if (IS_VDEC_INNER_RACING(ctx->dev->dec_capability))
 		mtk_vcodec_load_racing_info(ctx);
@@ -250,7 +251,8 @@ void mtk_vcodec_dec_disable_hardware(struct mtk_vcodec_dec_ctx *ctx, int hw_idx)
 	if (IS_VDEC_INNER_RACING(ctx->dev->dec_capability))
 		mtk_vcodec_record_racing_info(ctx);
 
-	mtk_vcodec_dec_disable_irq(ctx->dev, hw_idx);
+	if (!ctx->is_secure_playback)
+		mtk_vcodec_dec_disable_irq(ctx->dev, hw_idx);
 
 	mtk_vcodec_dec_child_dev_off(ctx->dev, hw_idx);
 	if (IS_VDEC_LAT_ARCH(ctx->dev->vdec_pdata->hw_arch) &&
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
index 2dfb3043493e..3e2270399b6c 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
@@ -593,14 +593,16 @@ static int vdec_h264_slice_core_decode(struct vdec_lat_buf *lat_buf)
 		goto vdec_dec_end;
 	}
 
-	/* wait decoder done interrupt */
-	timeout = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
-					       WAIT_INTR_TIMEOUT_MS, MTK_VDEC_CORE);
-	if (timeout)
-		mtk_vdec_err(ctx, "core decode timeout: pic_%d", ctx->decoded_frame_cnt);
-	inst->vsi_core->dec.timeout = !!timeout;
-
-	vpu_dec_core_end(vpu);
+	if (!ctx->is_secure_playback) {
+		/* wait decoder done interrupt */
+		timeout = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
+						       WAIT_INTR_TIMEOUT_MS, MTK_VDEC_CORE);
+		if (timeout)
+			mtk_vdec_err(ctx, "core decode timeout: pic_%d", ctx->decoded_frame_cnt);
+		inst->vsi_core->dec.timeout = !!timeout;
+
+		vpu_dec_core_end(vpu);
+	}
 	mtk_vdec_debug(ctx, "pic[%d] crc: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x",
 		       ctx->decoded_frame_cnt,
 		       inst->vsi_core->dec.crc[0], inst->vsi_core->dec.crc[1],
@@ -724,14 +726,16 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 		vdec_msg_queue_qbuf(&inst->ctx->msg_queue.core_ctx, lat_buf);
 	}
 
-	/* wait decoder done interrupt */
-	timeout = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
-					       WAIT_INTR_TIMEOUT_MS, MTK_VDEC_LAT0);
-	if (timeout)
-		mtk_vdec_err(inst->ctx, "lat decode timeout: pic_%d", inst->slice_dec_num);
-	inst->vsi->dec.timeout = !!timeout;
+	if (!inst->ctx->is_secure_playback) {
+		/* wait decoder done interrupt */
+		timeout = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
+						       WAIT_INTR_TIMEOUT_MS, MTK_VDEC_LAT0);
+		if (timeout)
+			mtk_vdec_err(inst->ctx, "lat decode timeout: pic_%d", inst->slice_dec_num);
+		inst->vsi->dec.timeout = !!timeout;
 
-	err = vpu_dec_end(vpu);
+		err = vpu_dec_end(vpu);
+	}
 	if (err == SLICE_HEADER_FULL || err == TRANS_BUFFER_FULL) {
 		if (!IS_VDEC_INNER_RACING(inst->ctx->dev->dec_capability))
 			vdec_msg_queue_qbuf(&inst->ctx->msg_queue.lat_ctx, lat_buf);
@@ -831,16 +835,19 @@ static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs
 	if (err)
 		goto err_free_fb_out;
 
-	/* wait decoder done interrupt */
-	err = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
-					   WAIT_INTR_TIMEOUT_MS, MTK_VDEC_CORE);
-	if (err)
-		mtk_vdec_err(inst->ctx, "decode timeout: pic_%d", inst->ctx->decoded_frame_cnt);
-
-	inst->vsi->dec.timeout = !!err;
-	err = vpu_dec_end(vpu);
-	if (err)
-		goto err_free_fb_out;
+	if (!inst->ctx->is_secure_playback) {
+		/* wait decoder done interrupt */
+		err = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
+						   WAIT_INTR_TIMEOUT_MS, MTK_VDEC_CORE);
+		if (err)
+			mtk_vdec_err(inst->ctx, "decode timeout: pic_%d",
+				     inst->ctx->decoded_frame_cnt);
+
+		inst->vsi->dec.timeout = !!err;
+		err = vpu_dec_end(vpu);
+		if (err)
+			goto err_free_fb_out;
+	}
 
 	memcpy(&inst->vsi_ctx, inst->vpu.vsi, sizeof(inst->vsi_ctx));
 	mtk_vdec_debug(inst->ctx, "pic[%d] crc: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x",
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:25 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:25 +0800
Subject: [PATCH v3,08/21] media: mediatek: vcodec: add tee client interface to communiate with optee-os
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-9-yunfei.dong@mediatek.com>

Open tee context to initialize the environment in order to communication
with optee-os, then open tee session as the communication pipeline for
lat and core to send data for hardware decode.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../platform/mediatek/vcodec/decoder/Makefile |   1 +
 .../vcodec/decoder/mtk_vcodec_dec_drv.h       |   5 +
 .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 165 ++++++++++++++++++
 .../vcodec/decoder/mtk_vcodec_dec_optee.h     |  73 ++++++++
 4 files changed, 244 insertions(+)
 create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
 create mode 100644 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/Makefile b/drivers/media/platform/mediatek/vcodec/decoder/Makefile
index 904cd22def84..1624933dfd5e 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/Makefile
+++ b/drivers/media/platform/mediatek/vcodec/decoder/Makefile
@@ -21,5 +21,6 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
 		mtk_vcodec_dec_stateful.o \
 		mtk_vcodec_dec_stateless.o \
 		mtk_vcodec_dec_pm.o \
+		mtk_vcodec_dec_optee.o \
 
 mtk-vcodec-dec-hw-y := mtk_vcodec_dec_hw.o
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
index 849b89dd205c..b1a2107f2a1e 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h
@@ -11,6 +11,7 @@
 #include "../common/mtk_vcodec_dbgfs.h"
 #include "../common/mtk_vcodec_fw_priv.h"
 #include "../common/mtk_vcodec_util.h"
+#include "mtk_vcodec_dec_optee.h"
 #include "vdec_msg_queue.h"
 
 #define MTK_VCODEC_DEC_NAME	"mtk-vcodec-dec"
@@ -261,6 +262,8 @@ struct mtk_vcodec_dec_ctx {
  * @dbgfs: debug log related information
  *
  * @chip_name: used to distinguish platforms and select the correct codec configuration values
+ *
+ * @optee_private: optee private data
  */
 struct mtk_vcodec_dec_dev {
 	struct v4l2_device v4l2_dev;
@@ -303,6 +306,8 @@ struct mtk_vcodec_dec_dev {
 	struct mtk_vcodec_dbgfs dbgfs;
 
 	enum mtk_vcodec_dec_chip_name chip_name;
+
+	struct mtk_vdec_optee_private *optee_private;
 };
 
 static inline struct mtk_vcodec_dec_ctx *fh_to_dec_ctx(struct v4l2_fh *fh)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
new file mode 100644
index 000000000000..38d9c1c1785a
--- /dev/null
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Yunfei Dong <yunfei.dong at mediatek.com>
+ */
+
+#include "mtk_vcodec_dec_drv.h"
+#include "mtk_vcodec_dec_optee.h"
+
+/*
+ * Randomly generated, and must correspond to the GUID on the TA side.
+ */
+static const uuid_t mtk_vdec_lat_uuid =
+	UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
+		  0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x90);
+
+static const uuid_t mtk_vdec_core_uuid =
+	UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
+		  0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x91);
+
+/*
+ * Check whether this driver supports decoder TA in the TEE instance,
+ * represented by the params (ver/data) of this function.
+ */
+static int mtk_vcodec_dec_optee_match(struct tee_ioctl_version_data *ver_data, const void *not_used)
+{
+	if (ver_data->impl_id == TEE_IMPL_ID_OPTEE)
+		return 1;
+	else
+		return 0;
+}
+
+int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev)
+{
+	vcodec_dev->optee_private = devm_kzalloc(&vcodec_dev->plat_dev->dev,
+						 sizeof(*vcodec_dev->optee_private),
+						 GFP_KERNEL);
+	if (!vcodec_dev->optee_private)
+		return -ENOMEM;
+
+	vcodec_dev->optee_private->vcodec_dev = vcodec_dev;
+
+	atomic_set(&vcodec_dev->optee_private->tee_active_cnt, 0);
+	mutex_init(&vcodec_dev->optee_private->tee_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_private_init);
+
+static int mtk_vcodec_dec_optee_init_hw_info(struct mtk_vdec_optee_private *optee_private,
+					     enum mtk_vdec_hw_id hardware_index)
+{
+	struct device *dev = &optee_private->vcodec_dev->plat_dev->dev;
+	struct tee_ioctl_open_session_arg session_arg;
+	struct mtk_vdec_optee_ca_info *ca_info;
+	int err = 0, session_func;
+
+	/* Open lat and core session with vdec TA. */
+	switch (hardware_index) {
+	case MTK_VDEC_LAT0:
+		export_uuid(session_arg.uuid, &mtk_vdec_lat_uuid);
+		session_func = MTK_VDEC_OPTEE_TA_LAT_SUBMIT_COMMAND;
+		ca_info = &optee_private->lat_ca;
+		break;
+	case MTK_VDEC_CORE:
+		export_uuid(session_arg.uuid, &mtk_vdec_core_uuid);
+		session_func = MTK_VDEC_OPTEE_TA_CORE_SUBMIT_COMMAND;
+		ca_info = &optee_private->core_ca;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	session_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
+	session_arg.num_params = 0;
+
+	err = tee_client_open_session(optee_private->tee_vdec_ctx, &session_arg, NULL);
+	if (err < 0 || session_arg.ret != 0) {
+		dev_err(dev, MTK_DBG_VCODEC_STR "open vdec tee session fail hw_id:%d err:%x.\n",
+			hardware_index, session_arg.ret);
+		return -EINVAL;
+	}
+	ca_info->vdec_session_id = session_arg.session;
+	ca_info->hw_id = hardware_index;
+	ca_info->vdec_session_func = session_func;
+
+	dev_dbg(dev, MTK_DBG_VCODEC_STR "open vdec tee session hw_id:%d session_id=%x.\n",
+		hardware_index, ca_info->vdec_session_id);
+
+	return err;
+}
+
+static void mtk_vcodec_dec_optee_deinit_hw_info(struct mtk_vdec_optee_private *optee_private,
+						enum mtk_vdec_hw_id hw_id)
+{
+	struct mtk_vdec_optee_ca_info *ca_info;
+
+	if (hw_id == MTK_VDEC_LAT0)
+		ca_info = &optee_private->lat_ca;
+	else
+		ca_info = &optee_private->core_ca;
+
+	tee_client_close_session(optee_private->tee_vdec_ctx, ca_info->vdec_session_id);
+}
+
+int mtk_vcodec_dec_optee_open(struct mtk_vdec_optee_private *optee_private)
+{
+	struct device *dev = &optee_private->vcodec_dev->plat_dev->dev;
+	int ret;
+
+	mutex_lock(&optee_private->tee_mutex);
+	if (atomic_inc_return(&optee_private->tee_active_cnt) > 1) {
+		mutex_unlock(&optee_private->tee_mutex);
+		dev_dbg(dev, MTK_DBG_VCODEC_STR "already init vdec optee private data!\n");
+		return 0;
+	}
+
+	/* Open context with TEE driver */
+	optee_private->tee_vdec_ctx = tee_client_open_context(NULL, mtk_vcodec_dec_optee_match,
+							      NULL, NULL);
+	if (IS_ERR(optee_private->tee_vdec_ctx)) {
+		dev_err(dev, MTK_DBG_VCODEC_STR "optee vdec tee context failed.\n");
+		ret = PTR_ERR(optee_private->tee_vdec_ctx);
+		goto err_ctx_open;
+	}
+
+	ret = mtk_vcodec_dec_optee_init_hw_info(optee_private, MTK_VDEC_LAT0);
+	if (ret < 0)
+		goto err_lat_init;
+
+	if (IS_VDEC_LAT_ARCH(optee_private->vcodec_dev->vdec_pdata->hw_arch)) {
+		ret = mtk_vcodec_dec_optee_init_hw_info(optee_private, MTK_VDEC_CORE);
+		if (ret < 0)
+			goto err_core_init;
+	}
+
+	mutex_unlock(&optee_private->tee_mutex);
+	return 0;
+err_core_init:
+	mtk_vcodec_dec_optee_deinit_hw_info(optee_private, MTK_VDEC_LAT0);
+err_lat_init:
+	tee_client_close_context(optee_private->tee_vdec_ctx);
+err_ctx_open:
+
+	mutex_unlock(&optee_private->tee_mutex);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_open);
+
+void mtk_vcodec_dec_optee_release(struct mtk_vdec_optee_private *optee_private)
+{
+	mutex_lock(&optee_private->tee_mutex);
+	if (!atomic_dec_and_test(&optee_private->tee_active_cnt)) {
+		mutex_unlock(&optee_private->tee_mutex);
+		return;
+	}
+
+	mtk_vcodec_dec_optee_deinit_hw_info(optee_private, MTK_VDEC_LAT0);
+	if (IS_VDEC_LAT_ARCH(optee_private->vcodec_dev->vdec_pdata->hw_arch))
+		mtk_vcodec_dec_optee_deinit_hw_info(optee_private, MTK_VDEC_CORE);
+
+	tee_client_close_context(optee_private->tee_vdec_ctx);
+	mutex_unlock(&optee_private->tee_mutex);
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_release);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
new file mode 100644
index 000000000000..8b1dca49331e
--- /dev/null
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Yunfei Dong <yunfei.dong at mediatek.com>
+ */
+
+#ifndef _MTK_VCODEC_DEC_OPTEE_H_
+#define _MTK_VCODEC_DEC_OPTEE_H_
+
+#include <linux/tee_drv.h>
+#include <linux/uuid.h>
+
+#include "mtk_vcodec_dec_drv.h"
+
+/* The TA ID implemented in this TA */
+#define MTK_VDEC_OPTEE_TA_LAT_SUBMIT_COMMAND  (0x10)
+#define MTK_VDEC_OPTEE_TA_CORE_SUBMIT_COMMAND  (0x20)
+
+#define MTK_OPTEE_MAX_TEE_PARAMS 4
+
+/**
+ * struct mtk_vdec_optee_ca_info - ca related param
+ * @vdec_session_id:   optee TA session identifier.
+ * @hw_id:             hardware index.
+ * @vdec_session_func: trusted application function id used specific to the TA.
+ */
+struct mtk_vdec_optee_ca_info {
+	u32 vdec_session_id;
+	enum mtk_vdec_hw_id hw_id;
+	u32 vdec_session_func;
+};
+
+/**
+ * struct mtk_vdec_optee_private - optee private data
+ * @vcodec_dev:     pointer to the mtk_vcodec_dev of the device
+ * @tee_vdec_ctx:   decoder TEE context handler.
+ * @lat_ca:         lat hardware information used to communicate with TA.
+ * @core_ca:        core hardware information used to communicate with TA.
+ *
+ * @tee_active_cnt: used to mark whether need to init optee
+ * @tee_mutex:      mutex lock used for optee
+ */
+struct mtk_vdec_optee_private {
+	struct mtk_vcodec_dec_dev *vcodec_dev;
+	struct tee_context *tee_vdec_ctx;
+
+	struct mtk_vdec_optee_ca_info lat_ca;
+	struct mtk_vdec_optee_ca_info core_ca;
+
+	atomic_t tee_active_cnt;
+	/* mutext used to lock optee open and release information. */
+	struct mutex tee_mutex;
+};
+
+/**
+ * mtk_vcodec_dec_optee_open - setup the communication channels with TA.
+ * @optee_private: optee private context
+ */
+int mtk_vcodec_dec_optee_open(struct mtk_vdec_optee_private *optee_private);
+
+/**
+ * mtk_vcodec_dec_optee_private_init - init optee parameters.
+ * @vcodec_dev: pointer to the mtk_vcodec_dev of the device
+ */
+int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev);
+
+/**
+ * mtk_vcodec_dec_optee_release - close the communication channels with TA.
+ * @optee_private: optee private context
+ */
+void mtk_vcodec_dec_optee_release(struct mtk_vdec_optee_private *optee_private);
+
+#endif /* _MTK_VCODEC_FW_OPTEE_H_ */
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:18 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:18 +0800
Subject: [PATCH v3,01/21] v4l2: add secure memory flags
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-2-yunfei.dong@mediatek.com>

From: Jeffrey Kardatzke <jkardatzke at google.com>

Adds a V4L2 flag which indicates that a queue is using secure dmabufs
and the corresponding capability flag.

Signed-off-by: Jeffrey Kardatzke <jkardatzke at google.com>
Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 include/media/videobuf2-core.h | 8 +++++++-
 include/uapi/linux/videodev2.h | 2 ++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 5557d78b6f20..98eba43661c1 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -518,6 +518,9 @@ struct vb2_buf_ops {
  *		->finish().
  * @non_coherent_mem: when set queue will attempt to allocate buffers using
  *		non-coherent memory.
+ * @allow_secure_mem: when set user-space can pass the %V4L2_MEMORY_FLAG_SECURE
+ *		flag to indicate the dma bufs are secure.
+ * @secure_mem: when set queue will verify that the dma bufs are secure.
  * @lock:	pointer to a mutex that protects the &struct vb2_queue. The
  *		driver can set this to a mutex to let the v4l2 core serialize
  *		the queuing ioctls. If the driver wants to handle locking
@@ -601,6 +604,8 @@ struct vb2_queue {
 	unsigned int			uses_requests:1;
 	unsigned int			allow_cache_hints:1;
 	unsigned int			non_coherent_mem:1;
+	unsigned int			allow_secure_mem:1;
+	unsigned int			secure_mem:1;
 
 	struct mutex			*lock;
 	void				*owner;
@@ -770,7 +775,8 @@ void vb2_core_querybuf(struct vb2_queue *q, struct vb2_buffer *vb, void *pb);
  * @q:		pointer to &struct vb2_queue with videobuf2 queue.
  * @memory:	memory type, as defined by &enum vb2_memory.
  * @flags:	auxiliary queue/buffer management flags. Currently, the only
- *		used flag is %V4L2_MEMORY_FLAG_NON_COHERENT.
+ *		used flags are %V4L2_MEMORY_FLAG_NON_COHERENT and
+ *		%V4L2_MEMORY_FLAG_SECURE.
  * @count:	requested buffer count.
  *
  * Videobuf2 core helper to implement VIDIOC_REQBUF() operation. It is called
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 68e7ac178cc2..570b11552818 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1026,6 +1026,7 @@ struct v4l2_requestbuffers {
 };
 
 #define V4L2_MEMORY_FLAG_NON_COHERENT			(1 << 0)
+#define V4L2_MEMORY_FLAG_SECURE				(1 << 1)
 
 /* capabilities for struct v4l2_requestbuffers and v4l2_create_buffers */
 #define V4L2_BUF_CAP_SUPPORTS_MMAP			(1 << 0)
@@ -1036,6 +1037,7 @@ struct v4l2_requestbuffers {
 #define V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF	(1 << 5)
 #define V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS		(1 << 6)
 #define V4L2_BUF_CAP_SUPPORTS_MAX_NUM_BUFFERS		(1 << 7)
+#define V4L2_BUF_CAP_SUPPORTS_SECURE_MEM		(1 << 8)
 
 /**
  * struct v4l2_plane - plane info for multi-planar buffers
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:22 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:22 +0800
Subject: [PATCH v3,05/21] dma-buf: heaps: Deduplicate docs and adopt common format
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-6-yunfei.dong@mediatek.com>

From: "T.J. Mercier" <tjmercier at google.com>

The docs for dma_heap_get_name were incorrect, and since they were
duplicated in the header they were wrong there too.

The docs formatting was inconsistent so I tried to make it more
consistent across functions since I'm already in here doing cleanup.

Remove multiple unused includes and alphabetize.

Signed-off-by: T.J. Mercier <tjmercier at google.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
[Yong: Just add a comment for "priv" to mute build warning]
Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 drivers/dma-buf/dma-heap.c | 27 +++++++++++++++------------
 include/linux/dma-heap.h   | 21 +--------------------
 2 files changed, 16 insertions(+), 32 deletions(-)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 84ae708fafe7..22f6c193db0d 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -7,17 +7,15 @@
  */
 
 #include <linux/cdev.h>
-#include <linux/debugfs.h>
 #include <linux/device.h>
 #include <linux/dma-buf.h>
+#include <linux/dma-heap.h>
 #include <linux/err.h>
-#include <linux/xarray.h>
 #include <linux/list.h>
-#include <linux/slab.h>
 #include <linux/nospec.h>
-#include <linux/uaccess.h>
 #include <linux/syscalls.h>
-#include <linux/dma-heap.h>
+#include <linux/uaccess.h>
+#include <linux/xarray.h>
 #include <uapi/linux/dma-heap.h>
 
 #define DEVNAME "dma_heap"
@@ -28,9 +26,10 @@
  * struct dma_heap - represents a dmabuf heap in the system
  * @name:		used for debugging/device-node name
  * @ops:		ops struct for this heap
- * @heap_devt		heap device node
- * @list		list head connecting to list of heaps
- * @heap_cdev		heap char device
+ * @priv:		private data for this heap
+ * @heap_devt:		heap device node
+ * @list:		list head connecting to list of heaps
+ * @heap_cdev:		heap char device
  *
  * Represents a heap of memory from which buffers can be made.
  */
@@ -193,11 +192,11 @@ static const struct file_operations dma_heap_fops = {
 };
 
 /**
- * dma_heap_get_drvdata() - get per-subdriver data for the heap
+ * dma_heap_get_drvdata - get per-heap driver data
  * @heap: DMA-Heap to retrieve private data for
  *
  * Returns:
- * The per-subdriver data for the heap.
+ * The per-heap data for the heap.
  */
 void *dma_heap_get_drvdata(struct dma_heap *heap)
 {
@@ -205,8 +204,8 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
 }
 
 /**
- * dma_heap_get_name() - get heap name
- * @heap: DMA-Heap to retrieve private data for
+ * dma_heap_get_name - get heap name
+ * @heap: DMA-Heap to retrieve the name of
  *
  * Returns:
  * The char* for the heap name.
@@ -216,6 +215,10 @@ const char *dma_heap_get_name(struct dma_heap *heap)
 	return heap->name;
 }
 
+/**
+ * dma_heap_add - adds a heap to dmabuf heaps
+ * @exp_info: information needed to register this heap
+ */
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
 {
 	struct dma_heap *heap, *h, *err_ret;
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 0c05561cad6e..fbe86ec889a8 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -9,14 +9,13 @@
 #ifndef _DMA_HEAPS_H
 #define _DMA_HEAPS_H
 
-#include <linux/cdev.h>
 #include <linux/types.h>
 
 struct dma_heap;
 
 /**
  * struct dma_heap_ops - ops to operate on a given heap
- * @allocate:		allocate dmabuf and return struct dma_buf ptr
+ * @allocate:	allocate dmabuf and return struct dma_buf ptr
  *
  * allocate returns dmabuf on success, ERR_PTR(-errno) on error.
  */
@@ -41,28 +40,10 @@ struct dma_heap_export_info {
 	void *priv;
 };
 
-/**
- * dma_heap_get_drvdata() - get per-heap driver data
- * @heap: DMA-Heap to retrieve private data for
- *
- * Returns:
- * The per-heap data for the heap.
- */
 void *dma_heap_get_drvdata(struct dma_heap *heap);
 
-/**
- * dma_heap_get_name() - get heap name
- * @heap: DMA-Heap to retrieve private data for
- *
- * Returns:
- * The char* for the heap name.
- */
 const char *dma_heap_get_name(struct dma_heap *heap);
 
-/**
- * dma_heap_add - adds a heap to dmabuf heaps
- * @exp_info:		information needed to register this heap
- */
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
 
 #endif /* _DMA_HEAPS_H */
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:24 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:24 +0800
Subject: [PATCH v3,07/21] dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-8-yunfei.dong@mediatek.com>

From: John Stultz <jstultz at google.com>

This allows drivers who don't want to create their own
DMA-BUF exporter to be able to allocate DMA-BUFs directly
from existing DMA-BUF Heaps.

There is some concern that the premise of DMA-BUF heaps is
that userland knows better about what type of heap memory
is needed for a pipeline, so it would likely be best for
drivers to import and fill DMA-BUFs allocated by userland
instead of allocating one themselves, but this is still
up for debate.

Signed-off-by: John Stultz <jstultz at google.com>
Signed-off-by: T.J. Mercier <tjmercier at google.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
[Yong: Fix the checkpatch alignment warning]
Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 drivers/dma-buf/dma-heap.c | 83 ++++++++++++++++++++++++++++++--------
 include/linux/dma-heap.h   |  6 +++
 2 files changed, 73 insertions(+), 16 deletions(-)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 97025ee8500f..6efe833a4b10 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -51,12 +51,24 @@ static dev_t dma_heap_devt;
 static struct class *dma_heap_class;
 static DEFINE_XARRAY_ALLOC(dma_heap_minors);
 
-static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
-				 unsigned int fd_flags,
-				 unsigned int heap_flags)
+/**
+ * dma_heap_buffer_alloc - Allocate dma-buf from a dma_heap
+ * @heap:	DMA-Heap to allocate from
+ * @len:	size to allocate in bytes
+ * @fd_flags:	flags to set on returned dma-buf fd
+ * @heap_flags: flags to pass to the dma heap
+ *
+ * This is for internal dma-buf allocations only. Free returned buffers with dma_buf_put().
+ */
+struct dma_buf *dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
+				      unsigned int fd_flags,
+				      unsigned int heap_flags)
 {
-	struct dma_buf *dmabuf;
-	int fd;
+	if (fd_flags & ~DMA_HEAP_VALID_FD_FLAGS)
+		return ERR_PTR(-EINVAL);
+
+	if (heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
+		return ERR_PTR(-EINVAL);
 
 	/*
 	 * Allocations from all heaps have to begin
@@ -64,9 +76,20 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
 	 */
 	len = PAGE_ALIGN(len);
 	if (!len)
-		return -EINVAL;
+		return ERR_PTR(-EINVAL);
+
+	return heap->ops->allocate(heap, len, fd_flags, heap_flags);
+}
+EXPORT_SYMBOL_GPL(dma_heap_buffer_alloc);
 
-	dmabuf = heap->ops->allocate(heap, len, fd_flags, heap_flags);
+static int dma_heap_bufferfd_alloc(struct dma_heap *heap, size_t len,
+				   unsigned int fd_flags,
+				   unsigned int heap_flags)
+{
+	struct dma_buf *dmabuf;
+	int fd;
+
+	dmabuf = dma_heap_buffer_alloc(heap, len, fd_flags, heap_flags);
 	if (IS_ERR(dmabuf))
 		return PTR_ERR(dmabuf);
 
@@ -104,15 +127,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
 	if (heap_allocation->fd)
 		return -EINVAL;
 
-	if (heap_allocation->fd_flags & ~DMA_HEAP_VALID_FD_FLAGS)
-		return -EINVAL;
-
-	if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
-		return -EINVAL;
-
-	fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
-				   heap_allocation->fd_flags,
-				   heap_allocation->heap_flags);
+	fd = dma_heap_bufferfd_alloc(heap, heap_allocation->len,
+				     heap_allocation->fd_flags,
+				     heap_allocation->heap_flags);
 	if (fd < 0)
 		return fd;
 
@@ -205,6 +222,7 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
 {
 	return heap->priv;
 }
+EXPORT_SYMBOL_GPL(dma_heap_get_drvdata);
 
 /**
  * dma_heap_get_name - get heap name
@@ -217,6 +235,7 @@ const char *dma_heap_get_name(struct dma_heap *heap)
 {
 	return heap->name;
 }
+EXPORT_SYMBOL_GPL(dma_heap_get_name);
 
 /**
  * dma_heap_add - adds a heap to dmabuf heaps
@@ -307,6 +326,37 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
 	kfree(heap);
 	return err_ret;
 }
+EXPORT_SYMBOL_GPL(dma_heap_add);
+
+/**
+ * dma_heap_find - get the heap registered with the specified name
+ * @name: Name of the DMA-Heap to find
+ *
+ * Returns:
+ * The DMA-Heap with the provided name.
+ *
+ * NOTE: DMA-Heaps returned from this function MUST be released using
+ * dma_heap_put() when the user is done to enable the heap to be unloaded.
+ */
+struct dma_heap *dma_heap_find(const char *name)
+{
+	struct dma_heap *h;
+
+	mutex_lock(&heap_list_lock);
+	list_for_each_entry(h, &heap_list, list) {
+		if (!kref_get_unless_zero(&h->refcount))
+			continue;
+
+		if (!strcmp(h->name, name)) {
+			mutex_unlock(&heap_list_lock);
+			return h;
+		}
+		dma_heap_put(h);
+	}
+	mutex_unlock(&heap_list_lock);
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(dma_heap_find);
 
 static void dma_heap_release(struct kref *ref)
 {
@@ -332,6 +382,7 @@ void dma_heap_put(struct dma_heap *heap)
 {
 	kref_put(&heap->refcount, dma_heap_release);
 }
+EXPORT_SYMBOL_GPL(dma_heap_put);
 
 static char *dma_heap_devnode(const struct device *dev, umode_t *mode)
 {
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index d57593f8a1bc..3cbf9bff2346 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -46,6 +46,12 @@ const char *dma_heap_get_name(struct dma_heap *heap);
 
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
 
+struct dma_heap *dma_heap_find(const char *name);
+
 void dma_heap_put(struct dma_heap *heap);
 
+struct dma_buf *dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
+				      unsigned int fd_flags,
+				      unsigned int heap_flags);
+
 #endif /* _DMA_HEAPS_H */
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:26 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:26 +0800
Subject: [PATCH v3,09/21] media: mediatek: vcodec: allocate tee share memory
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-10-yunfei.dong@mediatek.com>

Allocate two share memory for each lat and core hardware used to share
information with optee-os. Msg buffer used to send ipi command and get ack
command with optee-os, data buffer used to store vsi information which
used for hardware decode.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 80 ++++++++++++++++++-
 .../vcodec/decoder/mtk_vcodec_dec_optee.h     | 32 ++++++++
 2 files changed, 111 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
index 38d9c1c1785a..611fb0e56480 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
@@ -47,13 +47,69 @@ int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev)
 }
 EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_private_init);
 
+static void mtk_vcodec_dec_optee_deinit_memref(struct mtk_vdec_optee_ca_info *ca_info,
+					       enum mtk_vdec_optee_data_index data_index)
+{
+	tee_shm_free(ca_info->shm_memref[data_index].msg_shm);
+}
+
+static int mtk_vcodec_dec_optee_init_memref(struct tee_context *tee_vdec_ctx,
+					    struct mtk_vdec_optee_ca_info *ca_info,
+					    enum mtk_vdec_optee_data_index data_index)
+{
+	struct mtk_vdec_optee_shm_memref *shm_memref;
+	int alloc_size = 0, err = 0;
+	u64 shm_param_type = 0;
+	bool copy_buffer;
+
+	switch (data_index) {
+	case OPTEE_MSG_INDEX:
+		shm_param_type = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT;
+		alloc_size = MTK_VDEC_OPTEE_MSG_SIZE;
+		copy_buffer = true;
+		break;
+	case OPTEE_DATA_INDEX:
+		shm_param_type = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT;
+		alloc_size = MTK_VDEC_OPTEE_HW_SIZE;
+		copy_buffer = false;
+		break;
+	default:
+		pr_err(MTK_DBG_VCODEC_STR "tee invalid data_index: %d.\n", data_index);
+		return -EINVAL;
+	}
+
+	shm_memref = &ca_info->shm_memref[data_index];
+
+	/* Allocate dynamic shared memory with decoder TA */
+	shm_memref->msg_shm_size = alloc_size;
+	shm_memref->param_type = shm_param_type;
+	shm_memref->copy_to_ta = copy_buffer;
+	shm_memref->msg_shm = tee_shm_alloc_kernel_buf(tee_vdec_ctx, shm_memref->msg_shm_size);
+	if (IS_ERR(shm_memref->msg_shm)) {
+		pr_err(MTK_DBG_VCODEC_STR "tee alloc buf fail: data_index:%d.\n", data_index);
+		return -ENOMEM;
+	}
+
+	shm_memref->msg_shm_ca_buf = tee_shm_get_va(shm_memref->msg_shm, 0);
+	if (IS_ERR(shm_memref->msg_shm_ca_buf)) {
+		pr_err(MTK_DBG_VCODEC_STR "tee get shm va fail: data_index:%d.\n", data_index);
+		err = PTR_ERR(shm_memref->msg_shm_ca_buf);
+		goto err_get_msg_va;
+	}
+
+	return err;
+err_get_msg_va:
+	tee_shm_free(shm_memref->msg_shm);
+	return err;
+}
+
 static int mtk_vcodec_dec_optee_init_hw_info(struct mtk_vdec_optee_private *optee_private,
 					     enum mtk_vdec_hw_id hardware_index)
 {
 	struct device *dev = &optee_private->vcodec_dev->plat_dev->dev;
 	struct tee_ioctl_open_session_arg session_arg;
 	struct mtk_vdec_optee_ca_info *ca_info;
-	int err = 0, session_func;
+	int err, i, j, session_func;
 
 	/* Open lat and core session with vdec TA. */
 	switch (hardware_index) {
@@ -87,6 +143,24 @@ static int mtk_vcodec_dec_optee_init_hw_info(struct mtk_vdec_optee_private *opte
 	dev_dbg(dev, MTK_DBG_VCODEC_STR "open vdec tee session hw_id:%d session_id=%x.\n",
 		hardware_index, ca_info->vdec_session_id);
 
+	/* Allocate dynamic shared memory with decoder TA */
+	for (i = 0; i < OPTEE_MAX_INDEX; i++) {
+		err = mtk_vcodec_dec_optee_init_memref(optee_private->tee_vdec_ctx, ca_info, i);
+		if (err) {
+			dev_err(dev, MTK_DBG_VCODEC_STR "init vdec memref failed: %d.\n", i);
+			goto err_init_memref;
+		}
+	}
+
+	return err;
+err_init_memref:
+	if (i != 0) {
+		for (j = 0; j < i; j++)
+			mtk_vcodec_dec_optee_deinit_memref(ca_info, j);
+	}
+
+	tee_client_close_session(optee_private->tee_vdec_ctx, ca_info->vdec_session_id);
+
 	return err;
 }
 
@@ -94,12 +168,16 @@ static void mtk_vcodec_dec_optee_deinit_hw_info(struct mtk_vdec_optee_private *o
 						enum mtk_vdec_hw_id hw_id)
 {
 	struct mtk_vdec_optee_ca_info *ca_info;
+	int i;
 
 	if (hw_id == MTK_VDEC_LAT0)
 		ca_info = &optee_private->lat_ca;
 	else
 		ca_info = &optee_private->core_ca;
 
+	for (i = 0; i < OPTEE_MAX_INDEX; i++)
+		mtk_vcodec_dec_optee_deinit_memref(ca_info, i);
+
 	tee_client_close_session(optee_private->tee_vdec_ctx, ca_info->vdec_session_id);
 }
 
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
index 8b1dca49331e..24aa63af9887 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
@@ -18,16 +18,48 @@
 
 #define MTK_OPTEE_MAX_TEE_PARAMS 4
 
+#define MTK_VDEC_OPTEE_MSG_SIZE     128
+#define MTK_VDEC_OPTEE_HW_SIZE      (8 * SZ_1K)
+
+/**
+ * struct mtk_vdec_optee_shm_memref - share memory reference params
+ * @msg_shm:        message shared with TA in TEE.
+ * @msg_shm_ca_buf: ca buffer.
+ *
+ * @msg_shm_size:   share message size.
+ * @param_type:     each tee param types.
+ * @copy_to_ta:     need to copy data from ca to share memory.
+ */
+struct mtk_vdec_optee_shm_memref {
+	struct tee_shm *msg_shm;
+	u8 *msg_shm_ca_buf;
+
+	u32 msg_shm_size;
+	u64 param_type;
+	bool copy_to_ta;
+};
+
 /**
  * struct mtk_vdec_optee_ca_info - ca related param
  * @vdec_session_id:   optee TA session identifier.
  * @hw_id:             hardware index.
  * @vdec_session_func: trusted application function id used specific to the TA.
+ * @shm_memref:        share memory reference params.
  */
 struct mtk_vdec_optee_ca_info {
 	u32 vdec_session_id;
 	enum mtk_vdec_hw_id hw_id;
 	u32 vdec_session_func;
+	struct mtk_vdec_optee_shm_memref shm_memref[MTK_OPTEE_MAX_TEE_PARAMS];
+};
+
+/*
+ * enum mtk_vdec_optee_data_index - used to indentify each share memory information
+ */
+enum mtk_vdec_optee_data_index {
+	OPTEE_MSG_INDEX = 0,
+	OPTEE_DATA_INDEX,
+	OPTEE_MAX_INDEX,
 };
 
 /**
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:37 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:37 +0800
Subject: [PATCH v3,20/21] media: medkatek: vcodec: support tee decoder
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-21-yunfei.dong@mediatek.com>

Initialize tee private data to support secure decoder.
Release tee related information for each instance when decoder
done.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
index f47c98faf068..08e7d250487b 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
@@ -310,6 +310,9 @@ static int fops_vcodec_release(struct file *file)
 	v4l2_fh_exit(&ctx->fh);
 	v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
 
+	if (ctx->is_secure_playback)
+		mtk_vcodec_dec_optee_release(dev->optee_private);
+
 	mtk_vcodec_dbgfs_remove(dev, ctx->id);
 	list_del_init(&ctx->list);
 	kfree(ctx);
@@ -466,6 +469,11 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
 	atomic_set(&dev->dec_active_cnt, 0);
 	memset(dev->vdec_racing_info, 0, sizeof(dev->vdec_racing_info));
 	mutex_init(&dev->dec_racing_info_mutex);
+	ret = mtk_vcodec_dec_optee_private_init(dev);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to init svp private.");
+		goto err_reg_cont;
+	}
 
 	ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, -1);
 	if (ret) {
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:35 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:35 +0800
Subject: [PATCH v3,18/21] media: medkatek: vcodec: remove parse nal_info in kernel
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-19-yunfei.dong@mediatek.com>

The hardware can parse syntax to get nal_info, needn't to use cpu.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c    | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
index a1a68487131c..2dfb3043493e 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
@@ -645,11 +645,10 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	struct vdec_h264_slice_inst *inst = h_vdec;
 	struct vdec_vpu_inst *vpu = &inst->vpu;
 	struct mtk_video_dec_buf *src_buf_info;
-	int nal_start_idx, err, timeout = 0;
+	int err, timeout = 0;
 	unsigned int data[2];
 	struct vdec_lat_buf *lat_buf;
 	struct vdec_h264_slice_share_info *share_info;
-	unsigned char *buf;
 
 	if (vdec_msg_queue_init(&inst->ctx->msg_queue, inst->ctx,
 				vdec_h264_slice_core_decode,
@@ -673,14 +672,6 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 	share_info = lat_buf->private_data;
 	src_buf_info = container_of(bs, struct mtk_video_dec_buf, bs_buffer);
 
-	buf = (unsigned char *)bs->va;
-	nal_start_idx = mtk_vdec_h264_find_start_code(buf, bs->size);
-	if (nal_start_idx < 0) {
-		err = -EINVAL;
-		goto err_free_fb_out;
-	}
-
-	inst->vsi->dec.nal_info = buf[nal_start_idx];
 	lat_buf->src_buf_req = src_buf_info->m2m_buf.vb.vb2_buf.req_obj.req;
 	v4l2_m2m_buf_copy_metadata(&src_buf_info->m2m_buf.vb, &lat_buf->ts_info, true);
 
@@ -689,7 +680,7 @@ static int vdec_h264_slice_lat_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
 		goto err_free_fb_out;
 
 	if (!inst->ctx->is_secure_playback)
-		vdec_h264_insert_startcode(inst->ctx->dev, buf, &bs->size,
+		vdec_h264_insert_startcode(inst->ctx->dev, bs->va, &bs->size,
 					   &share_info->h264_slice_params.pps);
 
 	*res_chg = inst->resolution_changed;
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:33 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:33 +0800
Subject: [PATCH v3,16/21] media: medkatek: vcodec: support one plane capture buffer
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-17-yunfei.dong@mediatek.com>

The capture buffer has two planes for format MM21, but user space only
allocate secure memory for plane[0], and the size is Y data + uv data.
The driver need to support one plane decoder for svp mode.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../mediatek/vcodec/decoder/mtk_vcodec_dec.c  |  7 ++++-
 .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 26 ++++++++++---------
 .../decoder/vdec/vdec_h264_req_common.c       | 11 +++-----
 .../mediatek/vcodec/decoder/vdec_drv_if.c     |  4 +--
 4 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
index 604fdc8ee3ce..ab922e8d2d37 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
@@ -653,7 +653,12 @@ static int vidioc_vdec_g_fmt(struct file *file, void *priv,
 		 * So we just return picinfo yet, and update picinfo in
 		 * stop_streaming hook function
 		 */
-		q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
+
+		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 1)
+			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0] + ctx->picinfo.fb_sz[1];
+		else
+			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
+
 		q_data->sizeimage[1] = ctx->picinfo.fb_sz[1];
 		q_data->bytesperline[0] = ctx->last_decoded_picinfo.buf_w;
 		q_data->bytesperline[1] = ctx->last_decoded_picinfo.buf_w;
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
index cc42c942eb8a..707ed57a412e 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
@@ -285,14 +285,14 @@ static struct vdec_fb *vdec_get_cap_buffer(struct mtk_vcodec_dec_ctx *ctx)
 	framebuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, m2m_buf.vb);
 
 	pfb = &framebuf->frame_buffer;
-	pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
+	if (!ctx->is_secure_playback)
+		pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
 	pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
 	pfb->base_y.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
 
-	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
+	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2 && !ctx->is_secure_playback) {
 		pfb->base_c.va = vb2_plane_vaddr(dst_buf, 1);
-		pfb->base_c.dma_addr =
-			vb2_dma_contig_plane_dma_addr(dst_buf, 1);
+		pfb->base_c.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 1);
 		pfb->base_c.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[1];
 	}
 	mtk_v4l2_vdec_dbg(1, ctx,
@@ -339,16 +339,18 @@ static void mtk_vdec_worker(struct work_struct *work)
 	mtk_v4l2_vdec_dbg(3, ctx, "[%d] (%d) id=%d, vb=%p", ctx->id,
 			  vb2_src->vb2_queue->type, vb2_src->index, vb2_src);
 
-	bs_src->va = vb2_plane_vaddr(vb2_src, 0);
-	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
-	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
-	if (!bs_src->va) {
-		v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
-		mtk_v4l2_vdec_err(ctx, "[%d] id=%d source buffer is NULL", ctx->id,
-				  vb2_src->index);
-		return;
+	if (!ctx->is_secure_playback) {
+		bs_src->va = vb2_plane_vaddr(vb2_src, 0);
+		if (!bs_src->va) {
+			v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
+			mtk_v4l2_vdec_err(ctx, "[%d] id=%d source buffer is NULL", ctx->id,
+					  vb2_src->index);
+			return;
+		}
 	}
 
+	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
+	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
 	mtk_v4l2_vdec_dbg(3, ctx, "[%d] Bitstream VA=%p DMA=%pad Size=%zx vb=%p",
 			  ctx->id, bs_src->va, &bs_src->dma_addr, bs_src->size, vb2_src);
 	/* Apply request controls. */
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
index 5ca20d75dc8e..2a57e689ec07 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
@@ -79,15 +79,12 @@ void mtk_vdec_h264_fill_dpb_info(struct mtk_vcodec_dec_ctx *ctx,
 		vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
 		h264_dpb_info[index].field = vb2_v4l2->field;
 
-		h264_dpb_info[index].y_dma_addr =
-			vb2_dma_contig_plane_dma_addr(vb, 0);
+		h264_dpb_info[index].y_dma_addr = vb2_dma_contig_plane_dma_addr(vb, 0);
 		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
+			h264_dpb_info[index].c_dma_addr = vb2_dma_contig_plane_dma_addr(vb, 1);
+		else if (!ctx->is_secure_playback)
 			h264_dpb_info[index].c_dma_addr =
-				vb2_dma_contig_plane_dma_addr(vb, 1);
-		else
-			h264_dpb_info[index].c_dma_addr =
-				h264_dpb_info[index].y_dma_addr +
-				ctx->picinfo.fb_sz[0];
+				h264_dpb_info[index].y_dma_addr + ctx->picinfo.fb_sz[0];
 	}
 }
 
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
index d0b459b1603f..fb3e4f75ed93 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
@@ -73,14 +73,14 @@ int vdec_if_decode(struct mtk_vcodec_dec_ctx *ctx, struct mtk_vcodec_mem *bs,
 {
 	int ret = 0;
 
-	if (bs) {
+	if (bs && !ctx->is_secure_playback) {
 		if ((bs->dma_addr & 63) != 0) {
 			mtk_v4l2_vdec_err(ctx, "bs dma_addr should 64 byte align");
 			return -EINVAL;
 		}
 	}
 
-	if (fb) {
+	if (fb && !ctx->is_secure_playback) {
 		if (((fb->base_y.dma_addr & 511) != 0) ||
 		    ((fb->base_c.dma_addr & 511) != 0)) {
 			mtk_v4l2_vdec_err(ctx, "frame buffer dma_addr should 512 byte align");
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:31 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:31 +0800
Subject: [PATCH v3,14/21] media: mediatek: vcodec: Add capture format to support one plane memory
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-15-yunfei.dong@mediatek.com>

Define one uncompressed capture format V4L2_PIX_FMT_MS21 in order to
support one plane memory. The buffer size is luma + chroma, luma is
stored at the start and chrome is stored at the end.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 Documentation/userspace-api/media/v4l/pixfmt-reserved.rst | 8 ++++++++
 drivers/media/v4l2-core/v4l2-common.c                     | 2 ++
 drivers/media/v4l2-core/v4l2-ioctl.c                      | 1 +
 include/uapi/linux/videodev2.h                            | 1 +
 4 files changed, 12 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
index 886ba7b08d6b..6ec899649d50 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
@@ -295,6 +295,14 @@ please make a proposal on the linux-media mailing list.
       - Compressed format used by Nuvoton NPCM video driver. This format is
         defined in Remote Framebuffer Protocol (RFC 6143, chapter 7.7.4 Hextile
         Encoding).
+    * .. _V4L2-PIX-FMT-MS21:
+
+      - ``V4L2_PIX_FMT_MS21``
+      - 'MS21'
+      - This format has one plane, luma and chroma are stored in a contiguous
+        memory. Luma pixel in 16x32 tiles at the start, chroma pixel in 16x16
+        tiles at the end. The image height must be aligned with 32 and the image
+        width must be aligned with 16.
 .. raw:: latex
 
     \normalsize
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index e9e7e70fa24e..85aa3319cbc6 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -269,6 +269,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
 		  .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
 		{ .format = V4L2_PIX_FMT_MT2110R, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
 		  .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
+		{ .format = V4L2_PIX_FMT_MS21,    .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
+		  .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
 
 		/* YUV planar formats */
 		{ .format = V4L2_PIX_FMT_NV12,    .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 33076af4dfdb..26ffe4d1c28f 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1511,6 +1511,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
 		case V4L2_PIX_FMT_MT2110T:	descr = "Mediatek 10bit Tile Mode"; break;
 		case V4L2_PIX_FMT_MT2110R:	descr = "Mediatek 10bit Raster Mode"; break;
 		case V4L2_PIX_FMT_HEXTILE:	descr = "Hextile Compressed Format"; break;
+		case V4L2_PIX_FMT_MS21:		descr = "Mediatek One Plane Format"; break;
 		default:
 			if (fmt->description[0])
 				return;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 570b11552818..6be0d0e35077 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -798,6 +798,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_MM21     v4l2_fourcc('M', 'M', '2', '1') /* Mediatek 8-bit block mode, two non-contiguous planes */
 #define V4L2_PIX_FMT_MT2110T  v4l2_fourcc('M', 'T', '2', 'T') /* Mediatek 10-bit block tile mode */
 #define V4L2_PIX_FMT_MT2110R  v4l2_fourcc('M', 'T', '2', 'R') /* Mediatek 10-bit block raster mode */
+#define V4L2_PIX_FMT_MS21     v4l2_fourcc('M', 'S', '2', '1') /* Mediatek 8-bit block mode with one plane */
 #define V4L2_PIX_FMT_INZI     v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar Greyscale 10-bit and Depth 16-bit */
 #define V4L2_PIX_FMT_CNF4     v4l2_fourcc('C', 'N', 'F', '4') /* Intel 4-bit packed depth confidence information */
 #define V4L2_PIX_FMT_HI240    v4l2_fourcc('H', 'I', '2', '4') /* BTTV 8-bit dithered RGB */
-- 
2.18.0



From shameerali.kolothum.thodi at huawei.com  Wed Dec  6 00:17:59 2023
From: shameerali.kolothum.thodi at huawei.com (Shameerali Kolothum Thodi)
Date: Wed, 6 Dec 2023 08:17:59 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <296657c5b09f46a1ac6e4d993fbc0875@huawei.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org> <ZW8MP2tDt4_9ROBz@arm.com>
 <296657c5b09f46a1ac6e4d993fbc0875@huawei.com>
Message-ID: <a3b71568a13949be938a4d104c0d7c42@huawei.com>



> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Tuesday, December 5, 2023 2:17 PM
> To: 'Catalin Marinas' <catalin.marinas at arm.com>; Marc Zyngier
> <maz at kernel.org>
> Cc: ankita at nvidia.com; jgg at nvidia.com; oliver.upton at linux.dev;
> suzuki.poulose at arm.com; yuzenghui <yuzenghui at huawei.com>;
> will at kernel.org; ardb at kernel.org; akpm at linux-foundation.org;
> gshan at redhat.com; aniketa at nvidia.com; cjia at nvidia.com;
> kwankhede at nvidia.com; targupta at nvidia.com; vsethi at nvidia.com;
> acurrid at nvidia.com; apopple at nvidia.com; jhubbard at nvidia.com;
> danw at nvidia.com; mochs at nvidia.com; kvmarm at lists.linux.dev;
> kvm at vger.kernel.org; lpieralisi at kernel.org; linux-kernel at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; linyufeng (A)
> <linyufeng3 at huawei.com>
> Subject: RE: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_*
> and NORMAL_NC for IO memory
> 
> 
> 
> > -----Original Message-----
> > From: Catalin Marinas <catalin.marinas at arm.com>
> > Sent: Tuesday, December 5, 2023 11:41 AM
> > To: Marc Zyngier <maz at kernel.org>
> > Cc: ankita at nvidia.com; Shameerali Kolothum Thodi
> > <shameerali.kolothum.thodi at huawei.com>; jgg at nvidia.com;
> > oliver.upton at linux.dev; suzuki.poulose at arm.com; yuzenghui
> > <yuzenghui at huawei.com>; will at kernel.org; ardb at kernel.org;
> akpm at linux-
> > foundation.org; gshan at redhat.com; aniketa at nvidia.com;
> cjia at nvidia.com;
> > kwankhede at nvidia.com; targupta at nvidia.com; vsethi at nvidia.com;
> > acurrid at nvidia.com; apopple at nvidia.com; jhubbard at nvidia.com;
> > danw at nvidia.com; mochs at nvidia.com; kvmarm at lists.linux.dev;
> > kvm at vger.kernel.org; lpieralisi at kernel.org; linux-kernel at vger.kernel.org;
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_*
> > and NORMAL_NC for IO memory
> >
> > + Lorenzo, he really needs to be on this thread.
> >
> > On Tue, Dec 05, 2023 at 09:21:28AM +0000, Marc Zyngier wrote:
> > > On Tue, 05 Dec 2023 03:30:15 +0000,
> > > <ankita at nvidia.com> wrote:
> > > > From: Ankit Agrawal <ankita at nvidia.com>
> > > >
> > > > Currently, KVM for ARM64 maps at stage 2 memory that is considered
> > device
> > > > (i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting
> > > > overrides (as per the ARM architecture [1]) any device MMIO mapping
> > > > present at stage 1, resulting in a set-up whereby a guest operating
> > > > system cannot determine device MMIO mapping memory attributes on
> > its
> > > > own but it is always overridden by the KVM stage 2 default.
> > [...]
> > > Despite the considerable increase in the commit message length, a
> > > number of questions are left unanswered:
> > >
> > > - Shameer reported a regression on non-FWB systems, breaking device
> > >   assignment:
> > >
> > >
> >
> https://lore.kernel.org/all/af13ed63dc9a4f26a6c958ebfa77d78a at huawei.co
> > m/
> >
> > This referred to the first patch in the old series which was trying to
> > make the Stage 2 cacheable based on the vma attributes. That patch has
> > been dropped for now. It would be good if Shameer confirms this was the
> > problem.
> >
> 
> Yes, that was related to the first patch. We will soon test this on both FWB
> and
> non-FWB platforms and report back.
> 

Thanks to Yufeng, the test on both FWB and non-FWB platforms with a  GPU dev
assignment looks fine with this patch.

Shameer




From yunfei.dong at mediatek.com  Wed Dec  6 00:15:32 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:32 +0800
Subject: [PATCH v3,15/21] media: mediatek: vcodec: Add one plane format
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-16-yunfei.dong@mediatek.com>

Adding capture formats to support V4L2_PIX_FMT_MS21. This format has
one plane and only be used for secure video playback at current period.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c    | 4 +++-
 .../mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c   | 9 ++++++++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
index ba742f0e391d..604fdc8ee3ce 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
@@ -49,7 +49,9 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_dec_ctx *ctx, int format_inde
 		num_frame_count++;
 	}
 
-	if (num_frame_count == 1 || (!ctx->is_10bit_bitstream && fmt->fourcc == V4L2_PIX_FMT_MM21))
+	if ((!ctx->is_10bit_bitstream && fmt->fourcc == V4L2_PIX_FMT_MM21) ||
+	    (ctx->is_secure_playback && fmt->fourcc == V4L2_PIX_FMT_MS21) ||
+	    num_frame_count == 1)
 		return true;
 
 	q_data = &ctx->q_data[MTK_Q_DATA_SRC];
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
index d54b3833790d..cc42c942eb8a 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
@@ -229,7 +229,7 @@ static const struct mtk_stateless_control mtk_stateless_controls[] = {
 
 #define NUM_CTRLS ARRAY_SIZE(mtk_stateless_controls)
 
-static struct mtk_video_fmt mtk_video_formats[9];
+static struct mtk_video_fmt mtk_video_formats[10];
 
 static struct mtk_video_fmt default_out_format;
 static struct mtk_video_fmt default_cap_format;
@@ -770,6 +770,11 @@ static void mtk_vcodec_add_formats(unsigned int fourcc,
 		mtk_video_formats[count_formats].type = MTK_FMT_FRAME;
 		mtk_video_formats[count_formats].num_planes = 2;
 		break;
+	case V4L2_PIX_FMT_MS21:
+		mtk_video_formats[count_formats].fourcc = fourcc;
+		mtk_video_formats[count_formats].type = MTK_FMT_FRAME;
+		mtk_video_formats[count_formats].num_planes = 1;
+		break;
 	default:
 		mtk_v4l2_vdec_err(ctx, "Can not add unsupported format type");
 		return;
@@ -798,6 +803,8 @@ static void mtk_vcodec_get_supported_formats(struct mtk_vcodec_dec_ctx *ctx)
 		cap_format_count++;
 	}
 	if (ctx->dev->dec_capability & MTK_VDEC_FORMAT_MM21) {
+		mtk_vcodec_add_formats(V4L2_PIX_FMT_MS21, ctx);
+		cap_format_count++;
 		mtk_vcodec_add_formats(V4L2_PIX_FMT_MM21, ctx);
 		cap_format_count++;
 	}
-- 
2.18.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:27 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:27 +0800
Subject: [PATCH v3,10/21] media: mediatek: vcodec: send share memory data to optee
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-11-yunfei.dong@mediatek.com>

Setting msg and vsi information to shared buffer, then call tee invoke
function to send it to optee-os.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../vcodec/decoder/mtk_vcodec_dec_optee.c     | 140 ++++++++++++++++++
 .../vcodec/decoder/mtk_vcodec_dec_optee.h     |  51 +++++++
 2 files changed, 191 insertions(+)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
index 611fb0e56480..f29a8d143fee 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.c
@@ -241,3 +241,143 @@ void mtk_vcodec_dec_optee_release(struct mtk_vdec_optee_private *optee_private)
 	mutex_unlock(&optee_private->tee_mutex);
 }
 EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_release);
+
+static int mtk_vcodec_dec_optee_fill_shm(struct tee_param *command_params,
+					 struct mtk_vdec_optee_shm_memref *shm_memref,
+					 struct mtk_vdec_optee_data_to_shm *data,
+					 int index, struct device *dev)
+{
+	if (!data->msg_buf_size[index] || !data->msg_buf[index]) {
+		pr_err(MTK_DBG_VCODEC_STR "tee invalid buf param: %d.\n", index);
+		return -EINVAL;
+	}
+
+	*command_params = (struct tee_param) {
+		.attr = shm_memref->param_type,
+		.u.memref = {
+			.shm = shm_memref->msg_shm,
+			.size = data->msg_buf_size[index],
+			.shm_offs = 0,
+		},
+	};
+
+	if (!shm_memref->copy_to_ta) {
+		dev_dbg(dev, MTK_DBG_VCODEC_STR "share memref data: 0x%x param_type:%llu.\n",
+			*((unsigned int *)shm_memref->msg_shm_ca_buf), shm_memref->param_type);
+		return 0;
+	}
+
+	memset(shm_memref->msg_shm_ca_buf, 0, shm_memref->msg_shm_size);
+	memcpy(shm_memref->msg_shm_ca_buf, data->msg_buf[index], data->msg_buf_size[index]);
+
+	dev_dbg(dev, MTK_DBG_VCODEC_STR "share memref data => msg id:0x%x 0x%x param_type:%llu.\n",
+		*((unsigned int *)data->msg_buf[index]),
+		*((unsigned int *)shm_memref->msg_shm_ca_buf),
+		shm_memref->param_type);
+
+	return 0;
+}
+
+void mtk_vcodec_dec_optee_set_data(struct mtk_vdec_optee_data_to_shm *data,
+				   void *buf, int buf_size,
+				   enum mtk_vdec_optee_data_index index)
+{
+	data->msg_buf[index] = buf;
+	data->msg_buf_size[index] = buf_size;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_set_data);
+
+int mtk_vcodec_dec_optee_invokd_cmd(struct mtk_vdec_optee_private *optee_private,
+				    enum mtk_vdec_hw_id hw_id,
+				    struct mtk_vdec_optee_data_to_shm *data)
+{
+	struct device *dev = &optee_private->vcodec_dev->plat_dev->dev;
+	struct tee_ioctl_invoke_arg trans_args;
+	struct tee_param command_params[MTK_OPTEE_MAX_TEE_PARAMS];
+	struct mtk_vdec_optee_ca_info *ca_info;
+	struct mtk_vdec_optee_shm_memref *shm_memref;
+	int ret, index;
+
+	if (hw_id == MTK_VDEC_LAT0)
+		ca_info = &optee_private->lat_ca;
+	else
+		ca_info = &optee_private->core_ca;
+
+	memset(&trans_args, 0, sizeof(trans_args));
+	memset(command_params, 0, sizeof(command_params));
+
+	trans_args = (struct tee_ioctl_invoke_arg) {
+		.func = ca_info->vdec_session_func,
+		.session = ca_info->vdec_session_id,
+		.num_params = MTK_OPTEE_MAX_TEE_PARAMS,
+	};
+
+	/* Fill msg command parameters */
+	for (index = 0; index < MTK_OPTEE_MAX_TEE_PARAMS; index++) {
+		shm_memref = &ca_info->shm_memref[index];
+
+		if (shm_memref->param_type == TEE_IOCTL_PARAM_ATTR_TYPE_NONE ||
+		    data->msg_buf_size[index] == 0)
+			continue;
+
+		dev_dbg(dev, MTK_DBG_VCODEC_STR "tee share memory data size: %d -> %d.\n",
+			data->msg_buf_size[index], shm_memref->msg_shm_size);
+
+		if (data->msg_buf_size[index] > shm_memref->msg_shm_size) {
+			dev_err(dev, MTK_DBG_VCODEC_STR "tee buf size big than shm (%d -> %d).\n",
+				data->msg_buf_size[index], shm_memref->msg_shm_size);
+			return -EINVAL;
+		}
+
+		ret = mtk_vcodec_dec_optee_fill_shm(&command_params[index], shm_memref,
+						    data, index, dev);
+		if (ret)
+			return ret;
+	}
+
+	ret = tee_client_invoke_func(optee_private->tee_vdec_ctx, &trans_args, command_params);
+	if (ret < 0 || trans_args.ret != 0) {
+		dev_err(dev, MTK_DBG_VCODEC_STR "tee submit command fail: 0x%x 0x%x.\n",
+			trans_args.ret, ret);
+		return (ret < 0) ? ret : trans_args.ret;
+	}
+
+	/* clear all attrs, set all command param to unused */
+	for (index = 0; index < MTK_OPTEE_MAX_TEE_PARAMS; index++) {
+		data->msg_buf[index] = NULL;
+		data->msg_buf_size[index] = 0;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_optee_invokd_cmd);
+
+void *mtk_vcodec_dec_get_shm_buffer_va(struct mtk_vdec_optee_private *optee_private,
+				       enum mtk_vdec_hw_id hw_id,
+				       enum mtk_vdec_optee_data_index data_index)
+{
+	struct mtk_vdec_optee_ca_info *ca_info;
+
+	if (hw_id == MTK_VDEC_LAT0)
+		ca_info = &optee_private->lat_ca;
+	else
+		ca_info = &optee_private->core_ca;
+
+	return ca_info->shm_memref[data_index].msg_shm_ca_buf;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_get_shm_buffer_va);
+
+int mtk_vcodec_dec_get_shm_buffer_size(struct mtk_vdec_optee_private *optee_private,
+				       enum mtk_vdec_hw_id hw_id,
+				       enum mtk_vdec_optee_data_index data_index)
+{
+	struct mtk_vdec_optee_ca_info *ca_info;
+
+	if (hw_id == MTK_VDEC_LAT0)
+		ca_info = &optee_private->lat_ca;
+	else
+		ca_info = &optee_private->core_ca;
+
+	return ca_info->shm_memref[data_index].msg_shm_size;
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_dec_get_shm_buffer_size);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
index 24aa63af9887..c24a567ec877 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_optee.h
@@ -62,6 +62,16 @@ enum mtk_vdec_optee_data_index {
 	OPTEE_MAX_INDEX,
 };
 
+/**
+ * struct mtk_vdec_optee_data_to_shm - shm data used for TA
+ * @msg_buf:     msg information to TA.
+ * @msg_buf_len: length of msg information.
+ */
+struct mtk_vdec_optee_data_to_shm {
+	void *msg_buf[MTK_OPTEE_MAX_TEE_PARAMS];
+	int msg_buf_size[MTK_OPTEE_MAX_TEE_PARAMS];
+};
+
 /**
  * struct mtk_vdec_optee_private - optee private data
  * @vcodec_dev:     pointer to the mtk_vcodec_dev of the device
@@ -102,4 +112,45 @@ int mtk_vcodec_dec_optee_private_init(struct mtk_vcodec_dec_dev *vcodec_dev);
  */
 void mtk_vcodec_dec_optee_release(struct mtk_vdec_optee_private *optee_private);
 
+/**
+ * mtk_vcodec_dec_optee_set_data - set buffer to share memref.
+ * @vcodec_dev: normal world data used to init optee share memory
+ * @buf: normal world buffer address
+ * @buf_size: buf size
+ * @data_index: indentify each share memory informaiton
+ */
+void mtk_vcodec_dec_optee_set_data(struct mtk_vdec_optee_data_to_shm *data,
+				   void *buf, int buf_size,
+				   enum mtk_vdec_optee_data_index data_index);
+
+/**
+ * mtk_vcodec_dec_optee_invokd_cmd - send share memory data to optee .
+ * @optee_private: optee private context
+ * @hw_id: hardware index
+ * @data: normal world data used to init optee share memory
+ */
+int mtk_vcodec_dec_optee_invokd_cmd(struct mtk_vdec_optee_private *optee_private,
+				    enum mtk_vdec_hw_id hw_id,
+				    struct mtk_vdec_optee_data_to_shm *data);
+
+/**
+ * mtk_vcodec_dec_get_shm_buffer_va - close the communication channels with TA.
+ * @optee_private: optee private context
+ * @hw_id:         hardware index
+ * @@data_index: indentify each share memory informaiton
+ */
+void *mtk_vcodec_dec_get_shm_buffer_va(struct mtk_vdec_optee_private *optee_private,
+				       enum mtk_vdec_hw_id hw_id,
+				       enum mtk_vdec_optee_data_index data_index);
+
+/**
+ * mtk_vcodec_dec_get_shm_buffer_size - close the communication channels with TA.
+ * @optee_private: optee private context
+ * @hw_id:         hardware index
+ * @@data_index: indentify each share memory informaiton
+ */
+int mtk_vcodec_dec_get_shm_buffer_size(struct mtk_vdec_optee_private *optee_private,
+				       enum mtk_vdec_hw_id hw_id,
+				       enum mtk_vdec_optee_data_index data_index);
+
 #endif /* _MTK_VCODEC_FW_OPTEE_H_ */
-- 
2.18.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 00:31:43 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 09:31:43 +0100
Subject: [PATCH] ARM: dts: stm32mp15x: Consolidate usbh_[eo]hci phy properties
Message-ID: <20231206083142.1476340-2-u.kleine-koenig@pengutronix.de>

All machines making use of &usbh_ehci and/or &usbh_ohci use

	phys = <&usbphyc_port0>;

So move this setting into the .dtsi. Also add

	phy-names = "usb";

which isn't used by all machines, but nice for consistency.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 arch/arm/boot/dts/st/stm32mp151.dtsi                        | 4 ++++
 arch/arm/boot/dts/st/stm32mp151a-prtt1l.dtsi                | 2 --
 arch/arm/boot/dts/st/stm32mp157a-stinger96.dtsi             | 2 --
 arch/arm/boot/dts/st/stm32mp157c-emstamp-argon.dtsi         | 4 ----
 arch/arm/boot/dts/st/stm32mp157c-ev1.dts                    | 1 -
 arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts           | 4 ----
 arch/arm/boot/dts/st/stm32mp157c-phycore-stm32mp15-som.dtsi | 4 ----
 arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi               | 3 ---
 arch/arm/boot/dts/st/stm32mp15xx-dhcom-drc02.dtsi           | 1 -
 arch/arm/boot/dts/st/stm32mp15xx-dhcom-pdk2.dtsi            | 1 -
 arch/arm/boot/dts/st/stm32mp15xx-dhcom-picoitx.dtsi         | 2 --
 arch/arm/boot/dts/st/stm32mp15xx-dhcor-avenger96.dtsi       | 2 --
 arch/arm/boot/dts/st/stm32mp15xx-dhcor-drc-compact.dtsi     | 2 --
 arch/arm/boot/dts/st/stm32mp15xx-dhcor-testbench.dtsi       | 2 --
 arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi                   | 2 --
 15 files changed, 4 insertions(+), 32 deletions(-)

diff --git a/arch/arm/boot/dts/st/stm32mp151.dtsi b/arch/arm/boot/dts/st/stm32mp151.dtsi
index 61508917521c..fa4cbd312e5a 100644
--- a/arch/arm/boot/dts/st/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp151.dtsi
@@ -1521,6 +1521,8 @@ usbh_ohci: usb at 5800c000 {
 			clocks = <&usbphyc>, <&rcc USBH>;
 			resets = <&rcc USBH_R>;
 			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+			phys = <&usbphyc_port0>;
+			phy-names = "usb";
 			status = "disabled";
 		};
 
@@ -1531,6 +1533,8 @@ usbh_ehci: usb at 5800d000 {
 			resets = <&rcc USBH_R>;
 			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 			companion = <&usbh_ohci>;
+			phys = <&usbphyc_port0>;
+			phy-names = "usb";
 			status = "disabled";
 		};
 
diff --git a/arch/arm/boot/dts/st/stm32mp151a-prtt1l.dtsi b/arch/arm/boot/dts/st/stm32mp151a-prtt1l.dtsi
index dd23de85100c..3938d357e198 100644
--- a/arch/arm/boot/dts/st/stm32mp151a-prtt1l.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp151a-prtt1l.dtsi
@@ -206,8 +206,6 @@ pins {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp157a-stinger96.dtsi b/arch/arm/boot/dts/st/stm32mp157a-stinger96.dtsi
index 5f85598cc7c6..5c1cc48e5199 100644
--- a/arch/arm/boot/dts/st/stm32mp157a-stinger96.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp157a-stinger96.dtsi
@@ -313,8 +313,6 @@ &uart7 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp157c-emstamp-argon.dtsi b/arch/arm/boot/dts/st/stm32mp157c-emstamp-argon.dtsi
index f928cfb80b87..4792004cab0c 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-emstamp-argon.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp157c-emstamp-argon.dtsi
@@ -500,14 +500,10 @@ &usart3 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
 	status = "okay";
 };
 
 &usbh_ohci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ev1.dts b/arch/arm/boot/dts/st/stm32mp157c-ev1.dts
index cd9c3ff5378b..9eb9a1bf4f2c 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ev1.dts
@@ -362,7 +362,6 @@ &usart3 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
 	status = "okay";
 	#address-cells = <1>;
 	#size-cells = <0>;
diff --git a/arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts b/arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts
index bd67a1db9122..527c33be66cc 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts
@@ -197,14 +197,10 @@ &uart4 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
 	status = "okay";
 };
 
 &usbh_ohci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp157c-phycore-stm32mp15-som.dtsi b/arch/arm/boot/dts/st/stm32mp157c-phycore-stm32mp15-som.dtsi
index 4e8b2d2b30c7..bf0c32027baf 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-phycore-stm32mp15-som.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp157c-phycore-stm32mp15-som.dtsi
@@ -547,14 +547,10 @@ &usart3 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
 	status = "okay";
 };
 
 &usbh_ohci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi b/arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi
index f09b7c384bd9..fc3a2386dbb9 100644
--- a/arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi
@@ -567,9 +567,6 @@ &usart3 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
-
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dhcom-drc02.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dhcom-drc02.dtsi
index 35b1034aa3cf..bb4f8a0b937f 100644
--- a/arch/arm/boot/dts/st/stm32mp15xx-dhcom-drc02.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xx-dhcom-drc02.dtsi
@@ -152,7 +152,6 @@ &uart8 {	/* RS485 */
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dhcom-pdk2.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dhcom-pdk2.dtsi
index 46b87a27d8b3..466d9701add0 100644
--- a/arch/arm/boot/dts/st/stm32mp15xx-dhcom-pdk2.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xx-dhcom-pdk2.dtsi
@@ -305,7 +305,6 @@ &uart8 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dhcom-picoitx.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dhcom-picoitx.dtsi
index abc595350e71..b5bc53accd6b 100644
--- a/arch/arm/boot/dts/st/stm32mp15xx-dhcom-picoitx.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xx-dhcom-picoitx.dtsi
@@ -119,12 +119,10 @@ &uart8 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
 	status = "okay";
 };
 
 &usbh_ohci {
-	phys = <&usbphyc_port0>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dhcor-avenger96.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dhcor-avenger96.dtsi
index 0069ad75d55e..343a4613dfca 100644
--- a/arch/arm/boot/dts/st/stm32mp15xx-dhcor-avenger96.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xx-dhcor-avenger96.dtsi
@@ -489,8 +489,6 @@ bluetooth {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dhcor-drc-compact.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dhcor-drc-compact.dtsi
index 92d906bfd5d7..bc4ddcbdd5cf 100644
--- a/arch/arm/boot/dts/st/stm32mp15xx-dhcor-drc-compact.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xx-dhcor-drc-compact.dtsi
@@ -312,12 +312,10 @@ &usart3 {	/* RS485 or RS232 */
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
 	status = "okay";
 };
 
 &usbh_ohci {
-	phys = <&usbphyc_port0>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dhcor-testbench.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dhcor-testbench.dtsi
index ab7f0ba49639..6e79c4b6fe32 100644
--- a/arch/arm/boot/dts/st/stm32mp15xx-dhcor-testbench.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xx-dhcor-testbench.dtsi
@@ -168,12 +168,10 @@ &uart7 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
 	status = "okay";
 };
 
 &usbh_ohci {
-	phys = <&usbphyc_port0>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
index 511113f2e399..704c0d0cfe5f 100644
--- a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
@@ -680,8 +680,6 @@ &usart3 {
 };
 
 &usbh_ehci {
-	phys = <&usbphyc_port0>;
-	status = "okay";
 	#address-cells = <1>;
 	#size-cells = <0>;
 	/* onboard HUB */

base-commit: 577a4ee0b96fb043c9cf4a533c550ff587e526cf
-- 
2.42.0



From yunfei.dong at mediatek.com  Wed Dec  6 00:15:19 2023
From: yunfei.dong at mediatek.com (Yunfei Dong)
Date: Wed, 6 Dec 2023 16:15:19 +0800
Subject: [PATCH v3,02/21] v4l2: handle secure memory flags in queue setup
In-Reply-To: <20231206081538.17056-1-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
Message-ID: <20231206081538.17056-3-yunfei.dong@mediatek.com>

From: Jeffrey Kardatzke <jkardatzke at google.com>

Validates the secure memory flags when setting up a queue and ensures
the queue has the proper capability.

Signed-off-by: Jeffrey Kardatzke <jkardatzke at google.com>
Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
---
 .../media/common/videobuf2/videobuf2-core.c   | 23 +++++++++++++
 .../media/common/videobuf2/videobuf2-v4l2.c   | 34 +++++++++++++------
 2 files changed, 46 insertions(+), 11 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index 8c1df829745b..09dc030484be 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -813,6 +813,15 @@ static bool verify_coherency_flags(struct vb2_queue *q, bool non_coherent_mem)
 	return true;
 }
 
+static bool verify_secure_mem_flags(struct vb2_queue *q, bool secure_mem)
+{
+	if (secure_mem != q->secure_mem) {
+		dprintk(q, 1, "secure memory model mismatch\n");
+		return false;
+	}
+	return true;
+}
+
 int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
 		     unsigned int flags, unsigned int *count)
 {
@@ -820,6 +829,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
 	unsigned int q_num_bufs = vb2_get_num_buffers(q);
 	unsigned plane_sizes[VB2_MAX_PLANES] = { };
 	bool non_coherent_mem = flags & V4L2_MEMORY_FLAG_NON_COHERENT;
+	bool secure_mem = flags & V4L2_MEMORY_FLAG_SECURE;
 	unsigned int i;
 	int ret = 0;
 
@@ -836,6 +846,8 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
 	if (*count == 0 || q_num_bufs != 0 ||
 	    (q->memory != VB2_MEMORY_UNKNOWN && q->memory != memory) ||
 	    !verify_coherency_flags(q, non_coherent_mem)) {
+		bool no_previous_buffers = !q->num_buffers;
+
 		/*
 		 * We already have buffers allocated, so first check if they
 		 * are not in use and can be freed.
@@ -854,6 +866,12 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
 		__vb2_queue_free(q, q_num_bufs);
 		mutex_unlock(&q->mmap_lock);
 
+		/*
+		 * Do not allow switching secure buffer mode.
+		 */
+		if (!no_previous_buffers && !verify_secure_mem_flags(q, secure_mem))
+			return -EINVAL;
+
 		/*
 		 * In case of REQBUFS(0) return immediately without calling
 		 * driver's queue_setup() callback and allocating resources.
@@ -882,6 +900,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
 	if (ret)
 		return ret;
 	set_queue_coherency(q, non_coherent_mem);
+	q->secure_mem = secure_mem;
 
 	/*
 	 * Ask the driver how many buffers and planes per buffer it requires.
@@ -986,6 +1005,7 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
 	unsigned plane_sizes[VB2_MAX_PLANES] = { };
 	bool non_coherent_mem = flags & V4L2_MEMORY_FLAG_NON_COHERENT;
 	unsigned int q_num_bufs = vb2_get_num_buffers(q);
+	bool secure_mem = flags & V4L2_MEMORY_FLAG_SECURE;
 	bool no_previous_buffers = !q_num_bufs;
 	int ret = 0;
 
@@ -1015,6 +1035,7 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
 			return ret;
 		q->waiting_for_buffers = !q->is_output;
 		set_queue_coherency(q, non_coherent_mem);
+		q->secure_mem = secure_mem;
 	} else {
 		if (q->memory != memory) {
 			dprintk(q, 1, "memory model mismatch\n");
@@ -1022,6 +1043,8 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
 		}
 		if (!verify_coherency_flags(q, non_coherent_mem))
 			return -EINVAL;
+		if (!verify_secure_mem_flags(q, secure_mem))
+			return -EINVAL;
 	}
 
 	num_buffers = min(*count, q->max_num_buffers - q_num_bufs);
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 54d572c3b515..0a530830276c 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -686,22 +686,30 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
 		*caps |= V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS;
 	if (q->supports_requests)
 		*caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
+	if (q->allow_secure_mem && q->io_modes & VB2_DMABUF)
+		*caps |= V4L2_BUF_CAP_SUPPORTS_SECURE_MEM;
 }
 
-static void validate_memory_flags(struct vb2_queue *q,
+static bool validate_memory_flags(struct vb2_queue *q,
 				  int memory,
 				  u32 *flags)
 {
+	if (*flags & V4L2_MEMORY_FLAG_SECURE &&
+	    (!q->allow_secure_mem || memory != V4L2_MEMORY_DMABUF)) {
+		return false;
+	}
+
 	if (!q->allow_cache_hints || memory != V4L2_MEMORY_MMAP) {
 		/*
-		 * This needs to clear V4L2_MEMORY_FLAG_NON_COHERENT only,
-		 * but in order to avoid bugs we zero out all bits.
+		 * This needs to clear V4L2_MEMORY_FLAG_NON_COHERENT only.
 		 */
-		*flags = 0;
-	} else {
-		/* Clear all unknown flags. */
-		*flags &= V4L2_MEMORY_FLAG_NON_COHERENT;
+		*flags &= ~V4L2_MEMORY_FLAG_NON_COHERENT;
 	}
+
+	/* Clear all unknown flags. */
+	*flags &= V4L2_MEMORY_FLAG_NON_COHERENT | V4L2_MEMORY_FLAG_SECURE;
+
+	return true;
 }
 
 int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
@@ -710,7 +718,8 @@ int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
 	u32 flags = req->flags;
 
 	fill_buf_caps(q, &req->capabilities);
-	validate_memory_flags(q, req->memory, &flags);
+	if (!validate_memory_flags(q, req->memory, &flags))
+		return -EINVAL;
 	req->flags = flags;
 	return ret ? ret : vb2_core_reqbufs(q, req->memory,
 					    req->flags, &req->count);
@@ -752,7 +761,8 @@ int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create)
 	unsigned i;
 
 	fill_buf_caps(q, &create->capabilities);
-	validate_memory_flags(q, create->memory, &create->flags);
+	if (!validate_memory_flags(q, create->memory, &create->flags))
+		return -EINVAL;
 	create->index = vb2_get_num_buffers(q);
 	create->max_num_buffers = q->max_num_buffers;
 	create->capabilities |= V4L2_BUF_CAP_SUPPORTS_MAX_NUM_BUFFERS;
@@ -1007,7 +1017,8 @@ int vb2_ioctl_reqbufs(struct file *file, void *priv,
 	u32 flags = p->flags;
 
 	fill_buf_caps(vdev->queue, &p->capabilities);
-	validate_memory_flags(vdev->queue, p->memory, &flags);
+	if (!validate_memory_flags(vdev->queue, p->memory, &flags))
+		return -EINVAL;
 	p->flags = flags;
 	if (res)
 		return res;
@@ -1031,7 +1042,8 @@ int vb2_ioctl_create_bufs(struct file *file, void *priv,
 
 	p->index = vdev->queue->num_buffers;
 	fill_buf_caps(vdev->queue, &p->capabilities);
-	validate_memory_flags(vdev->queue, p->memory, &p->flags);
+	if (!validate_memory_flags(vdev->queue, p->memory, &p->flags))
+		return -EINVAL;
 	/*
 	 * If count == 0, then just check if memory and type are valid.
 	 * Any -EBUSY result from vb2_verify_memory_type can be mapped to 0.
-- 
2.18.0



From jianjun.wang at mediatek.com  Wed Dec  6 00:37:52 2023
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Wed, 6 Dec 2023 16:37:52 +0800
Subject: [PATCH 1/2] PCI: mediatek: Allocate MSI address with dmam_alloc_coherent
In-Reply-To: <20231206083753.18186-1-jianjun.wang@mediatek.com>
References: <20231206083753.18186-1-jianjun.wang@mediatek.com>
Message-ID: <20231206083753.18186-2-jianjun.wang@mediatek.com>

Use 'dmam_alloc_coherent' to allocate the MSI address, instead of using
'virt_to_phys'.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
---
 drivers/pci/controller/pcie-mediatek.c | 29 ++++++++++++++++++--------
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 66a8f73296fc..b080f7ca6da0 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -178,6 +178,7 @@ struct mtk_pcie_soc {
  * @phy: pointer to PHY control block
  * @slot: port slot
  * @irq: GIC irq
+ * @msg_addr: MSI message address
  * @irq_domain: legacy INTx IRQ domain
  * @inner_domain: inner IRQ domain
  * @msi_domain: MSI IRQ domain
@@ -198,6 +199,7 @@ struct mtk_pcie_port {
 	struct phy *phy;
 	u32 slot;
 	int irq;
+	dma_addr_t msg_addr;
 	struct irq_domain *irq_domain;
 	struct irq_domain *inner_domain;
 	struct irq_domain *msi_domain;
@@ -394,12 +396,10 @@ static struct pci_ops mtk_pcie_ops_v2 = {
 static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
 {
 	struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
-	phys_addr_t addr;
 
 	/* MT2712/MT7622 only support 32-bit MSI addresses */
-	addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
 	msg->address_hi = 0;
-	msg->address_lo = lower_32_bits(addr);
+	msg->address_lo = lower_32_bits(port->msg_addr);
 
 	msg->data = data->hwirq;
 
@@ -515,18 +515,26 @@ static int mtk_pcie_allocate_msi_domains(struct mtk_pcie_port *port)
 	return 0;
 }
 
-static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
+static int mtk_pcie_enable_msi(struct mtk_pcie_port *port)
 {
 	u32 val;
-	phys_addr_t msg_addr;
+	void *msi_vaddr;
 
-	msg_addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
-	val = lower_32_bits(msg_addr);
+	msi_vaddr = dmam_alloc_coherent(port->pcie->dev, sizeof(dma_addr_t), &port->msg_addr,
+					GFP_KERNEL);
+	if (!msi_vaddr) {
+		dev_err(port->pcie->dev, "failed to alloc and map MSI data\n");
+		return -ENOMEM;
+	}
+
+	val = lower_32_bits(port->msg_addr);
 	writel(val, port->base + PCIE_IMSI_ADDR);
 
 	val = readl(port->base + PCIE_INT_MASK);
 	val &= ~MSI_MASK;
 	writel(val, port->base + PCIE_INT_MASK);
+
+	return 0;
 }
 
 static void mtk_pcie_irq_teardown(struct mtk_pcie *pcie)
@@ -732,8 +740,11 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
 	val &= ~INTX_MASK;
 	writel(val, port->base + PCIE_INT_MASK);
 
-	if (IS_ENABLED(CONFIG_PCI_MSI))
-		mtk_pcie_enable_msi(port);
+	if (IS_ENABLED(CONFIG_PCI_MSI)) {
+		err = mtk_pcie_enable_msi(port);
+		if (err)
+			return err;
+	}
 
 	/* Set AHB to PCIe translation windows */
 	val = lower_32_bits(mem->start) |
-- 
2.18.0



From jianjun.wang at mediatek.com  Wed Dec  6 00:37:53 2023
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Wed, 6 Dec 2023 16:37:53 +0800
Subject: [PATCH 2/2] PCI: mediatek-gen3: Allocate MSI address with dmam_alloc_coherent
In-Reply-To: <20231206083753.18186-1-jianjun.wang@mediatek.com>
References: <20231206083753.18186-1-jianjun.wang@mediatek.com>
Message-ID: <20231206083753.18186-3-jianjun.wang@mediatek.com>

Use 'dmam_alloc_coherent' to allocate the MSI address, instead of using
static physical address.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
---
 drivers/pci/controller/pcie-mediatek-gen3.c | 30 +++++++++++----------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index e0e27645fdf4..0b1b5c8e5288 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -108,7 +108,7 @@
  */
 struct mtk_msi_set {
 	void __iomem *base;
-	phys_addr_t msg_addr;
+	dma_addr_t msg_addr;
 	u32 saved_irq_state;
 };
 
@@ -116,7 +116,6 @@ struct mtk_msi_set {
  * struct mtk_gen3_pcie - PCIe port information
  * @dev: pointer to PCIe device
  * @base: IO mapped register base
- * @reg_base: physical register base
  * @mac_reset: MAC reset control
  * @phy_reset: PHY reset control
  * @phy: PHY controller block
@@ -135,7 +134,6 @@ struct mtk_msi_set {
 struct mtk_gen3_pcie {
 	struct device *dev;
 	void __iomem *base;
-	phys_addr_t reg_base;
 	struct reset_control *mac_reset;
 	struct reset_control *phy_reset;
 	struct phy *phy;
@@ -278,18 +276,24 @@ static int mtk_pcie_set_trans_table(struct mtk_gen3_pcie *pcie,
 	return 0;
 }
 
-static void mtk_pcie_enable_msi(struct mtk_gen3_pcie *pcie)
+static int mtk_pcie_enable_msi(struct mtk_gen3_pcie *pcie)
 {
 	int i;
 	u32 val;
+	void *msi_vaddr;
 
 	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
 		struct mtk_msi_set *msi_set = &pcie->msi_sets[i];
 
 		msi_set->base = pcie->base + PCIE_MSI_SET_BASE_REG +
 				i * PCIE_MSI_SET_OFFSET;
-		msi_set->msg_addr = pcie->reg_base + PCIE_MSI_SET_BASE_REG +
-				    i * PCIE_MSI_SET_OFFSET;
+
+		msi_vaddr = dmam_alloc_coherent(pcie->dev, sizeof(dma_addr_t), &msi_set->msg_addr,
+						GFP_KERNEL);
+		if (!msi_vaddr) {
+			dev_err(pcie->dev, "failed to alloc and map MSI data for set %d\n", i);
+			return -ENOMEM;
+		}
 
 		/* Configure the MSI capture address */
 		writel_relaxed(lower_32_bits(msi_set->msg_addr), msi_set->base);
@@ -305,6 +309,8 @@ static void mtk_pcie_enable_msi(struct mtk_gen3_pcie *pcie)
 	val = readl_relaxed(pcie->base + PCIE_INT_ENABLE_REG);
 	val |= PCIE_MSI_ENABLE;
 	writel_relaxed(val, pcie->base + PCIE_INT_ENABLE_REG);
+
+	return 0;
 }
 
 static int mtk_pcie_startup_port(struct mtk_gen3_pcie *pcie)
@@ -371,7 +377,9 @@ static int mtk_pcie_startup_port(struct mtk_gen3_pcie *pcie)
 		return err;
 	}
 
-	mtk_pcie_enable_msi(pcie);
+	err = mtk_pcie_enable_msi(pcie);
+	if (err)
+		return err;
 
 	/* Set PCIe translation windows */
 	resource_list_for_each_entry(entry, &host->windows) {
@@ -762,20 +770,14 @@ static int mtk_pcie_parse_port(struct mtk_gen3_pcie *pcie)
 {
 	struct device *dev = pcie->dev;
 	struct platform_device *pdev = to_platform_device(dev);
-	struct resource *regs;
 	int ret;
 
-	regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pcie-mac");
-	if (!regs)
-		return -EINVAL;
-	pcie->base = devm_ioremap_resource(dev, regs);
+	pcie->base = devm_platform_ioremap_resource_byname(pdev, "pcie-mac");
 	if (IS_ERR(pcie->base)) {
 		dev_err(dev, "failed to map register base\n");
 		return PTR_ERR(pcie->base);
 	}
 
-	pcie->reg_base = regs->start;
-
 	pcie->phy_reset = devm_reset_control_get_optional_exclusive(dev, "phy");
 	if (IS_ERR(pcie->phy_reset)) {
 		ret = PTR_ERR(pcie->phy_reset);
-- 
2.18.0



From jianjun.wang at mediatek.com  Wed Dec  6 00:37:51 2023
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Wed, 6 Dec 2023 16:37:51 +0800
Subject: [PATCH 0/2] PCI: mediatek: Allocate MSI address with dmam_alloc_coherent
Message-ID: <20231206083753.18186-1-jianjun.wang@mediatek.com>

These series of patches change the allocation of MSI address on MediaTek
platform, which uses 'dmam_alloc_coherent' to allocate the MSI address.

Jianjun Wang (2):
  PCI: mediatek: Allocate MSI address with dmam_alloc_coherent
  PCI: mediatek-gen3: Allocate MSI address with dmam_alloc_coherent

 drivers/pci/controller/pcie-mediatek-gen3.c | 30 +++++++++++----------
 drivers/pci/controller/pcie-mediatek.c      | 29 +++++++++++++-------
 2 files changed, 36 insertions(+), 23 deletions(-)

-- 
2.18.0



From hverkuil-cisco at xs4all.nl  Wed Dec  6 00:46:35 2023
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Wed, 6 Dec 2023 09:46:35 +0100
Subject: [PATCH v3,16/21] media: medkatek: vcodec: support one plane
 capture buffer
In-Reply-To: <20231206081538.17056-17-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
 <20231206081538.17056-17-yunfei.dong@mediatek.com>
Message-ID: <574bb65f-872d-4bf4-9d3d-a330133de884@xs4all.nl>

On 06/12/2023 09:15, Yunfei Dong wrote:
> The capture buffer has two planes for format MM21, but user space only
> allocate secure memory for plane[0], and the size is Y data + uv data.
> The driver need to support one plane decoder for svp mode.

For a future v4: note the typo in the Subject line: medkatek -> mediatek.
It's present in patches 16-20.

Regards,

	Hans

> 
> Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
> ---
>  .../mediatek/vcodec/decoder/mtk_vcodec_dec.c  |  7 ++++-
>  .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 26 ++++++++++---------
>  .../decoder/vdec/vdec_h264_req_common.c       | 11 +++-----
>  .../mediatek/vcodec/decoder/vdec_drv_if.c     |  4 +--
>  4 files changed, 26 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> index 604fdc8ee3ce..ab922e8d2d37 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> @@ -653,7 +653,12 @@ static int vidioc_vdec_g_fmt(struct file *file, void *priv,
>  		 * So we just return picinfo yet, and update picinfo in
>  		 * stop_streaming hook function
>  		 */
> -		q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
> +
> +		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 1)
> +			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0] + ctx->picinfo.fb_sz[1];
> +		else
> +			q_data->sizeimage[0] = ctx->picinfo.fb_sz[0];
> +
>  		q_data->sizeimage[1] = ctx->picinfo.fb_sz[1];
>  		q_data->bytesperline[0] = ctx->last_decoded_picinfo.buf_w;
>  		q_data->bytesperline[1] = ctx->last_decoded_picinfo.buf_w;
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> index cc42c942eb8a..707ed57a412e 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> @@ -285,14 +285,14 @@ static struct vdec_fb *vdec_get_cap_buffer(struct mtk_vcodec_dec_ctx *ctx)
>  	framebuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, m2m_buf.vb);
>  
>  	pfb = &framebuf->frame_buffer;
> -	pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
> +	if (!ctx->is_secure_playback)
> +		pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
>  	pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
>  	pfb->base_y.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
>  
> -	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
> +	if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2 && !ctx->is_secure_playback) {
>  		pfb->base_c.va = vb2_plane_vaddr(dst_buf, 1);
> -		pfb->base_c.dma_addr =
> -			vb2_dma_contig_plane_dma_addr(dst_buf, 1);
> +		pfb->base_c.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 1);
>  		pfb->base_c.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[1];
>  	}
>  	mtk_v4l2_vdec_dbg(1, ctx,
> @@ -339,16 +339,18 @@ static void mtk_vdec_worker(struct work_struct *work)
>  	mtk_v4l2_vdec_dbg(3, ctx, "[%d] (%d) id=%d, vb=%p", ctx->id,
>  			  vb2_src->vb2_queue->type, vb2_src->index, vb2_src);
>  
> -	bs_src->va = vb2_plane_vaddr(vb2_src, 0);
> -	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
> -	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
> -	if (!bs_src->va) {
> -		v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
> -		mtk_v4l2_vdec_err(ctx, "[%d] id=%d source buffer is NULL", ctx->id,
> -				  vb2_src->index);
> -		return;
> +	if (!ctx->is_secure_playback) {
> +		bs_src->va = vb2_plane_vaddr(vb2_src, 0);
> +		if (!bs_src->va) {
> +			v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
> +			mtk_v4l2_vdec_err(ctx, "[%d] id=%d source buffer is NULL", ctx->id,
> +					  vb2_src->index);
> +			return;
> +		}
>  	}
>  
> +	bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
> +	bs_src->size = (size_t)vb2_src->planes[0].bytesused;
>  	mtk_v4l2_vdec_dbg(3, ctx, "[%d] Bitstream VA=%p DMA=%pad Size=%zx vb=%p",
>  			  ctx->id, bs_src->va, &bs_src->dma_addr, bs_src->size, vb2_src);
>  	/* Apply request controls. */
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
> index 5ca20d75dc8e..2a57e689ec07 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_common.c
> @@ -79,15 +79,12 @@ void mtk_vdec_h264_fill_dpb_info(struct mtk_vcodec_dec_ctx *ctx,
>  		vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
>  		h264_dpb_info[index].field = vb2_v4l2->field;
>  
> -		h264_dpb_info[index].y_dma_addr =
> -			vb2_dma_contig_plane_dma_addr(vb, 0);
> +		h264_dpb_info[index].y_dma_addr = vb2_dma_contig_plane_dma_addr(vb, 0);
>  		if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
> +			h264_dpb_info[index].c_dma_addr = vb2_dma_contig_plane_dma_addr(vb, 1);
> +		else if (!ctx->is_secure_playback)
>  			h264_dpb_info[index].c_dma_addr =
> -				vb2_dma_contig_plane_dma_addr(vb, 1);
> -		else
> -			h264_dpb_info[index].c_dma_addr =
> -				h264_dpb_info[index].y_dma_addr +
> -				ctx->picinfo.fb_sz[0];
> +				h264_dpb_info[index].y_dma_addr + ctx->picinfo.fb_sz[0];
>  	}
>  }
>  
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> index d0b459b1603f..fb3e4f75ed93 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_drv_if.c
> @@ -73,14 +73,14 @@ int vdec_if_decode(struct mtk_vcodec_dec_ctx *ctx, struct mtk_vcodec_mem *bs,
>  {
>  	int ret = 0;
>  
> -	if (bs) {
> +	if (bs && !ctx->is_secure_playback) {
>  		if ((bs->dma_addr & 63) != 0) {
>  			mtk_v4l2_vdec_err(ctx, "bs dma_addr should 64 byte align");
>  			return -EINVAL;
>  		}
>  	}
>  
> -	if (fb) {
> +	if (fb && !ctx->is_secure_playback) {
>  		if (((fb->base_y.dma_addr & 511) != 0) ||
>  		    ((fb->base_c.dma_addr & 511) != 0)) {
>  			mtk_v4l2_vdec_err(ctx, "frame buffer dma_addr should 512 byte align");



From m.szyprowski at samsung.com  Wed Dec  6 00:46:42 2023
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed,  6 Dec 2023 09:46:42 +0100
Subject: [PATCH] drivers: perf: constify the ctl_table argument of the riscv
 user access handler
References: <CGME20231206084652eucas1p1fd6025710032f3a4a64b05dab67a2a17@eucas1p1.samsung.com>
Message-ID: <20231206084642.802053-1-m.szyprowski@samsung.com>


Fix riscv build break after commit c8be9e66ca1e ("sysctl: treewide:
constify the ctl_table argument of handlers").

Fixes: c8be9e66ca1e ("sysctl: treewide: constify the ctl_table argument of handlers")
Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/perf/riscv_pmu_sbi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index 16acd4dcdb96..97e345f7d25d 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -986,7 +986,7 @@ static void riscv_pmu_update_counter_access(void *info)
 		csr_write(CSR_SCOUNTEREN, 0x2);
 }
 
-static int riscv_pmu_proc_user_access_handler(struct ctl_table *table,
+static int riscv_pmu_proc_user_access_handler(const struct ctl_table *table,
 					      int write, void *buffer,
 					      size_t *lenp, loff_t *ppos)
 {
-- 
2.34.1



From u.kleine-koenig at pengutronix.de  Wed Dec  6 00:48:53 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 6 Dec 2023 09:48:53 +0100
Subject: [PATCH] ARM: dts: stm32mp15x: Consolidate usbh_[eo]hci phy
 properties
In-Reply-To: <20231206083142.1476340-2-u.kleine-koenig@pengutronix.de>
References: <20231206083142.1476340-2-u.kleine-koenig@pengutronix.de>
Message-ID: <20231206084853.q4dfbp5twpe235se@pengutronix.de>

Hello,

On Wed, Dec 06, 2023 at 09:31:43AM +0100, Uwe Kleine-K?nig wrote:
> diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
> index 511113f2e399..704c0d0cfe5f 100644
> --- a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
> +++ b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
> @@ -680,8 +680,6 @@ &usart3 {
>  };
>  
>  &usbh_ehci {
> -	phys = <&usbphyc_port0>;
> -	status = "okay";

the status property must be kept. I will wait a bit for further review
and then resend (unless this patch is picked up with this issue fixed
up).

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/c832945b/attachment.sig>

From keith.zhao at starfivetech.com  Wed Dec  6 00:55:02 2023
From: keith.zhao at starfivetech.com (Keith Zhao)
Date: Wed, 6 Dec 2023 16:55:02 +0800
Subject: [PATCH v1 0/2] Add waveshare 7inch touchscreen panel support
In-Reply-To: <CAPY8ntAXYVTTfXL5HX-14t-VDe63eFgRBNKA0aG3RamKepxwDQ@mail.gmail.com>
References: <20231124104451.44271-1-shengyang.chen@starfivetech.com>
 <dab03c60-caa9-47e3-9dac-fa499227b67b@gmx.net>
 <CAPY8ntAXYVTTfXL5HX-14t-VDe63eFgRBNKA0aG3RamKepxwDQ@mail.gmail.com>
Message-ID: <5b837622-3ac9-47d5-aaf1-6b1ef5144c1c@starfivetech.com>



On 2023/11/25 0:04, Dave Stevenson wrote:
> On Fri, 24 Nov 2023 at 15:00, Stefan Wahren <wahrenst at gmx.net> wrote:
>>
>> Hi Shengyang,
>>
>> [fix address of Emma]
> 
> Not merged to master yet, but Emma has stepped back from maintenance.
> https://lists.freedesktop.org/archives/dri-devel/2023-October/428829.html
> Dropped from the cc.
> 
>> Am 24.11.23 um 11:44 schrieb Shengyang Chen:
>> > This patchset adds waveshare 7inch touchscreen panel support
>> > for the StarFive JH7110 SoC.
>> >
>> > Patch 1 add new compatible for the raspberrypi panel driver and its dt-binding.
>> > Patch 2 add new display mode and new probing process for raspberrypi panel driver.
>> >
>> > Waveshare 7inch touchscreen panel is a kind of raspberrypi panel
>> > which can be drived by raspberrypi panel driver.
>> >
>> > The series has been tested on the VisionFive 2 board.
>> surprisingly i was recently working on the official Raspberry Pi
>> touchscreen and was able to get it running the new way.
>>
>> What do i mean with the new way. There is almost nothing special to the
>> Raspberry Pi touchscreen, so we should try to use/extend existing
>> components like:
>>
>> CONFIG_DRM_PANEL_SIMPLE
>> CONFIG_TOUCHSCREEN_EDT_FT5X06
>> CONFIG_DRM_TOSHIBA_TC358762
>>
>> The only special part is the Attiny on the connector PCB which requires:
>>
>> CONFIG_REGULATOR_RASPBERRYPI_TOUCHSCREEN_ATTINY
>>
>> So the whole point is to avoid writing monolitic drivers for simple
>> panel like that.
>>
>> There is a WIP branch based on top of Linux 6.7-rcX, which should
>> demonstrate this approach [1]. Unfortunately it is not ready for
>> upstreaming, but it has been tested on a Raspberry Pi 3 B Plus. Maybe
>> this is helpful for your case.
>>
>> Actually i consider panel-raspberrypi-touchscreen.c as a dead end, which
>> shouldn't be extended.
> 
> Agreed.
> 
> The panel control being bound in with the Atmel control has no hook
> for the EDT5x06 touch driver to hook in and keep the power to the
> touch controller active. When the panel disable gets called, bye bye
> touch overlay :-(
> 
> And I'm reading the driver change as more of a hack to get it to work
> on your platform, not as adding support for the Waveshare panel
> variant.
> Waveshare deliberately cloned the behaviour of the Pi 7" panel in
> order to make it work with the old Pi firmware drivers, so it
> shouldn't need any significant changes. Where did the new timings come
> from?
> 
>   Dave
hi Dave :
that's means the panel driver split into 3 sub-modules:
panel + panel_bridge + regulator.

I have a question: in the  
static int rpi_touchscreen_probe(struct i2c_client *i2c)
{
	......

	ver = rpi_touchscreen_i2c_read(ts, REG_ID);
	if (ver < 0) {
		dev_err(dev, "Atmel I2C read failed: %d\n", ver);
		return -ENODEV;
	}

	switch (ver) {
	case 0xde: /* ver 1 */
	case 0xc3: /* ver 2 */
		break;
	default:
		dev_err(dev, "Unknown Atmel firmware revision: 0x%02x\n", ver);
		return -ENODEV;
	}

	......
}
i think this "I2C read" can use to detect whether the panel is connected to dsi controller.

and when split the panel driver into 3 sub-modules, it seems the default way is connected.
if I drop the panel , run modetest to check the connector status , result connected.
Is there any way to detect the connection in this case? 
Thanks



-------------------------------------

Where did the new timings come from?

-------------------------------------
My platform dphy tx hardware has certain limitations.
Only supports integer multiples of 10M bitrate: 
such as 160M ,170M, 180M,190M,...1G(max)

as common dphy bitrate = pixclock*bpp/lanes.
This value cannot match successfully in most cases.

so in order to match bitrate , I choose a bitrate value around pixclock*bpp/lanes,
Prevent overflow and underflow by fine-tuning the timing parameters:-(
that will make the new timming value.

> 
>> Btw there are already DT overlays in mainline which seems to use the
>> Raspberry Pi 7inch panel (without touch function yet) [2].
>>
>> [1] - https://github.com/lategoodbye/rpi-zero/commits/v6.7-7inch-ts
>> [2] -
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x-rpidsi.dtso?h=v6.6.2&id=6b4da1354fd81adace0cda448c77d8f2a47d8474
>>
>> >
>> > Shengyang Chen (2):
>> >    dt-bindings: display: panel: raspberrypi: Add compatible property for
>> >      waveshare 7inch touchscreen panel
>> >    gpu: drm: panel: raspberrypi: add new display mode and new probing
>> >      process
>> >
>> >   .../panel/raspberrypi,7inch-touchscreen.yaml  |  4 +-
>> >   .../drm/panel/panel-raspberrypi-touchscreen.c | 99 ++++++++++++++++---
>> >   2 files changed, 91 insertions(+), 12 deletions(-)
>> >
>>


From piotr.firek at financialflows.pl  Wed Dec  6 00:55:23 2023
From: piotr.firek at financialflows.pl (Piotr Firek)
Date: Wed,  6 Dec 2023 08:55:23 GMT
Subject: =?UTF-8?Q?Prosz=C4=99_o_kontakt?=
Message-ID: <20231206074500-0.1.1e.8i4i.0.5x34dhecyc@financialflows.pl>

Dzie? dobry,

Czy jest mo?liwo?? nawi?zania wsp??pracy z Pa?stwem?

Z ch?ci? porozmawiam z osob? zajmuj?c? si? dzia?aniami zwi?zanymi ze sprzeda??.

Pomagamy skutecznie pozyskiwa? nowych klient?w.

Zapraszam do kontaktu.


Pozdrawiam
Piotr Firek


From jensenhuang at friendlyarm.com  Wed Dec  6 01:06:40 2023
From: jensenhuang at friendlyarm.com (Jensen Huang)
Date: Wed,  6 Dec 2023 17:06:40 +0800
Subject: [PATCH] i2c: rk3x: fix potential spinlock recursion on poll
Message-ID: <20231206090641.18849-1-jensenhuang@friendlyarm.com>

Possible deadlock scenario (on reboot):
rk3x_i2c_xfer_common(polling)
    -> rk3x_i2c_wait_xfer_poll()
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock);
            ...
        <rk3x i2c interrupt>
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock); (deadlock here)

Store the IRQ number and disable/enable it around the polling transfer.
This patch has been tested on NanoPC-T4.

Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>
---
 drivers/i2c/busses/i2c-rk3x.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index a044ca0c35a1..94514637c3bd 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -200,6 +200,7 @@ struct rk3x_i2c {
 	struct clk *clk;
 	struct clk *pclk;
 	struct notifier_block clk_rate_nb;
+	int irq;
 
 	/* Settings */
 	struct i2c_timings t;
@@ -1087,13 +1088,18 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
 
 		spin_unlock_irqrestore(&i2c->lock, flags);
 
-		rk3x_i2c_start(i2c);
-
 		if (!polling) {
+			rk3x_i2c_start(i2c);
+
 			timeout = wait_event_timeout(i2c->wait, !i2c->busy,
 						     msecs_to_jiffies(WAIT_TIMEOUT));
 		} else {
+			disable_irq(i2c->irq);
+			rk3x_i2c_start(i2c);
+
 			timeout = rk3x_i2c_wait_xfer_poll(i2c);
+
+			enable_irq(i2c->irq);
 		}
 
 		spin_lock_irqsave(&i2c->lock, flags);
@@ -1310,6 +1316,8 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	i2c->irq = irq;
+
 	platform_set_drvdata(pdev, i2c);
 
 	if (i2c->soc_data->calc_timings == rk3x_i2c_v0_calc_timings) {
-- 
2.42.0



From nicolas.ferre at microchip.com  Wed Dec  6 01:24:51 2023
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Wed, 6 Dec 2023 10:24:51 +0100
Subject: [PATCH] power: reset: at91: Drop '__init' from
 at91_wakeup_status()
In-Reply-To: <20231120-fix-at91-modpost-warnings-v1-1-813671933863@kernel.org>
References: <20231120-fix-at91-modpost-warnings-v1-1-813671933863@kernel.org>
Message-ID: <62b3cd0f-e71c-4d53-be87-388809b42dcc@microchip.com>

On 20/11/2023 at 23:35, Nathan Chancellor wrote:
> When building with clang, there are two section mismatch warnings:
> 
>    WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x7c (section: .text) -> at91_wakeup_status (section: .init.text)
>    WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text)
> 
> Drop '__init' from at91_wakeup_status() to clear up the mismatch.
> 
> Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
> Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
> Signed-off-by: Nathan Chancellor <nathan at kernel.org>

Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>
Thanks, best regards,
   Nicolas

> ---
> I suspect this is not visible for GCC due to inlining
> at91_wakeup_status() but I did not actually check.
> ---
>   drivers/power/reset/at91-poweroff.c      | 2 +-
>   drivers/power/reset/at91-sama5d2_shdwc.c | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/reset/at91-poweroff.c b/drivers/power/reset/at91-poweroff.c
> index 126e774e210c..93eece027865 100644
> --- a/drivers/power/reset/at91-poweroff.c
> +++ b/drivers/power/reset/at91-poweroff.c
> @@ -57,7 +57,7 @@ static struct shdwc {
>          void __iomem *mpddrc_base;
>   } at91_shdwc;
> 
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
>   {
>          const char *reason;
>          u32 reg = readl(at91_shdwc.shdwc_base + AT91_SHDW_SR);
> diff --git a/drivers/power/reset/at91-sama5d2_shdwc.c b/drivers/power/reset/at91-sama5d2_shdwc.c
> index af95c7b39cb3..959ce0dbe91d 100644
> --- a/drivers/power/reset/at91-sama5d2_shdwc.c
> +++ b/drivers/power/reset/at91-sama5d2_shdwc.c
> @@ -107,7 +107,7 @@ static const unsigned long long sdwc_dbc_period[] = {
>          0, 3, 32, 512, 4096, 32768,
>   };
> 
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
>   {
>          struct shdwc *shdw = platform_get_drvdata(pdev);
>          const struct reg_config *rcfg = shdw->rcfg;
> 
> ---
> base-commit: b55d073e6501dc6077edaa945a6dad8ac5c8bbab
> change-id: 20231120-fix-at91-modpost-warnings-beabd2bac722
> 
> Best regards,
> --
> Nathan Chancellor <nathan at kernel.org>
> 



From shawnguo at kernel.org  Wed Dec  6 01:26:00 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 17:26:00 +0800
Subject: [PATCH] ARM: dts: imx28-xea: Pass the 'model' property
In-Reply-To: <88a045f5-a18d-424a-811e-10f095ca151e@gmx.net>
References: <20231205132735.2016022-1-festevam@gmail.com>
 <88a045f5-a18d-424a-811e-10f095ca151e@gmx.net>
Message-ID: <20231206092600.GD270430@dragon>

On Wed, Dec 06, 2023 at 08:00:26AM +0100, Stefan Wahren wrote:
> Hi,
> 
> sorry i replied just to the list last time :-(
> 
> Am 05.12.23 um 14:27 schrieb Fabio Estevam:
> > From: Fabio Estevam <festevam at denx.de>
> > 
> > Per root-node.yaml, 'model' is a required property.
> > 
> > Pass it to fix the following dt-schema warning:
> > 
> > imx28-xea.dtb: /: 'model' is a required property
> > 	from schema $id: http://devicetree.org/schemas/root-node.yaml#
> > 
> > Signed-off-by: Fabio Estevam <festevam at denx.de>
> i would consider this as a fix because every board file should have a
> model, which is helpful for debugging.
> 
> Fixes: 445ae16ac1c5 ("ARM: dts: imx28: Add DTS description of imx28
> based XEA board")

Ok, I added it.

> > ---
> >   arch/arm/boot/dts/nxp/mxs/imx28-xea.dts | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> > index a400c108f66a..cc54a0390f8c 100644
> > --- a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> > +++ b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> > @@ -8,6 +8,7 @@
> >   #include "imx28-lwe.dtsi"
> > 
> >   / {
> > +	model = "Liebherr Xea board";
> s/Xea/XEA

Fixed it up.

Shawn


From xueshuai at linux.alibaba.com  Wed Dec  6 01:28:15 2023
From: xueshuai at linux.alibaba.com (Shuai Xue)
Date: Wed, 6 Dec 2023 17:28:15 +0800
Subject: [PATCH v11 4/5] drivers/perf: add DesignWare PCIe PMU driver
In-Reply-To: <20231205142128.GA18450@willie-the-truck>
References: <20231121013400.18367-5-xueshuai@linux.alibaba.com>
 <2d52f588-f584-4c01-8f41-227815a54e41@suswa.mountain>
 <20231205142128.GA18450@willie-the-truck>
Message-ID: <2c092b76-6b76-4675-94c8-2e4b0031c966@linux.alibaba.com>



On 2023/12/5 22:21, Will Deacon wrote:
> On Sat, Nov 25, 2023 at 10:06:39AM +0300, Dan Carpenter wrote:
>> Hi Shuai,
>>
>> kernel test robot noticed the following build warnings:
>>
>> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>>
>> url:    https://github.com/intel-lab-lkp/linux/commits/Shuai-Xue/docs-perf-Add-description-for-Synopsys-DesignWare-PCIe-PMU-driver/20231121-093713
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
>> patch link:    https://lore.kernel.org/r/20231121013400.18367-5-xueshuai%40linux.alibaba.com
>> patch subject: [PATCH v11 4/5] drivers/perf: add DesignWare PCIe PMU driver
>> config: x86_64-randconfig-r071-20231123 (https://download.01.org/0day-ci/archive/20231124/202311241906.0ymlLjyo-lkp at intel.com/config)
>> compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
>> reproduce: (https://download.01.org/0day-ci/archive/20231124/202311241906.0ymlLjyo-lkp at intel.com/reproduce)
>>
>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> the same patch/commit), kindly add following tags
>> | Reported-by: kernel test robot <lkp at intel.com>
>> | Reported-by: Dan Carpenter <error27 at gmail.com>
>> | Closes: https://lore.kernel.org/r/202311241906.0ymlLjyo-lkp at intel.com/
>>
>> smatch warnings:
>> drivers/perf/dwc_pcie_pmu.c:352 dwc_pcie_pmu_event_update() error: uninitialized symbol 'now'.
>>
>> vim +/now +352 drivers/perf/dwc_pcie_pmu.c
>>
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  338  static void dwc_pcie_pmu_event_update(struct perf_event *event)
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  339  {
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  340  	struct hw_perf_event *hwc = &event->hw;
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  341  	enum dwc_pcie_event_type type = DWC_PCIE_EVENT_TYPE(event);
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  342  	u64 delta, prev, now;
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  343  
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  344  	do {
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  345  		prev = local64_read(&hwc->prev_count);
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  346  
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  347  		if (type == DWC_PCIE_LANE_EVENT)
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  348  			now = dwc_pcie_pmu_read_lane_event_counter(event);
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  349  		else if (type == DWC_PCIE_TIME_BASE_EVENT)
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  350  			now = dwc_pcie_pmu_read_time_based_counter(event);
>>
>> uninitialized on else path.
>>
>> 3481798a4ec51d1 Shuai Xue 2023-11-21  351  
>> 3481798a4ec51d1 Shuai Xue 2023-11-21 @352  	} while (local64_cmpxchg(&hwc->prev_count, prev, now) != prev);
> 
> Shuai, any chance you can address this please? I think the event validation
> logic means that the type is only ever one of the cases you handle, so
> you probably just want to either initialise 'now' to 0 or WARN and return
> early if the type is unknown.

Hi, Will, and Dan,

As the type is checked in dwc_pcie_pmu_event_init(), I will fix this warning by
initialising 'now' to 0.

Thank you.
Best Regards,
Shuai


From heiko at sntech.de  Wed Dec  6 01:29:51 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Wed, 06 Dec 2023 10:29:51 +0100
Subject: [PATCH] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <20231206090641.18849-1-jensenhuang@friendlyarm.com>
References: <20231206090641.18849-1-jensenhuang@friendlyarm.com>
Message-ID: <5298230.31r3eYUQgx@diego>

Am Mittwoch, 6. Dezember 2023, 10:06:40 CET schrieb Jensen Huang:
> Possible deadlock scenario (on reboot):
> rk3x_i2c_xfer_common(polling)
>     -> rk3x_i2c_wait_xfer_poll()
>         -> rk3x_i2c_irq(0, i2c);
>             --> spin_lock(&i2c->lock);
>             ...
>         <rk3x i2c interrupt>
>         -> rk3x_i2c_irq(0, i2c);
>             --> spin_lock(&i2c->lock); (deadlock here)
>
> Store the IRQ number and disable/enable it around the polling transfer.
> This patch has been tested on NanoPC-T4.
> 
> Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>

Reviewed-by: Heiko Stuebner <heiko at sntech.de>


> ---
>  drivers/i2c/busses/i2c-rk3x.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index a044ca0c35a1..94514637c3bd 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -200,6 +200,7 @@ struct rk3x_i2c {
>  	struct clk *clk;
>  	struct clk *pclk;
>  	struct notifier_block clk_rate_nb;
> +	int irq;
>  
>  	/* Settings */
>  	struct i2c_timings t;
> @@ -1087,13 +1088,18 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
>  
>  		spin_unlock_irqrestore(&i2c->lock, flags);
>  
> -		rk3x_i2c_start(i2c);
> -
>  		if (!polling) {
> +			rk3x_i2c_start(i2c);
> +
>  			timeout = wait_event_timeout(i2c->wait, !i2c->busy,
>  						     msecs_to_jiffies(WAIT_TIMEOUT));
>  		} else {
> +			disable_irq(i2c->irq);
> +			rk3x_i2c_start(i2c);
> +
>  			timeout = rk3x_i2c_wait_xfer_poll(i2c);
> +
> +			enable_irq(i2c->irq);
>  		}
>  
>  		spin_lock_irqsave(&i2c->lock, flags);
> @@ -1310,6 +1316,8 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> +	i2c->irq = irq;
> +
>  	platform_set_drvdata(pdev, i2c);
>  
>  	if (i2c->soc_data->calc_timings == rk3x_i2c_v0_calc_timings) {
> 






From shawnguo at kernel.org  Wed Dec  6 01:31:06 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 6 Dec 2023 17:31:06 +0800
Subject: [PATCH v2 2/2] arm64: dts: freescale: imx93: add i3c1 and i3c2
In-Reply-To: <ZXAKp1WS97cAI5X2@lizhi-Precision-Tower-5810>
References: <20231017194657.3199749-1-Frank.Li@nxp.com>
 <20231017194657.3199749-2-Frank.Li@nxp.com>
 <ZUz/8fBWtnwdSW9w@lizhi-Precision-Tower-5810>
 <20231127022140.GJ87953@dragon>
 <20231127-cherisher-falsify-8193656e8872@wendy>
 <ZXAKp1WS97cAI5X2@lizhi-Precision-Tower-5810>
Message-ID: <20231206093106.GE270430@dragon>

On Wed, Dec 06, 2023 at 12:46:15AM -0500, Frank Li wrote:
> On Mon, Nov 27, 2023 at 09:35:39AM +0000, Conor Dooley wrote:
> > On Mon, Nov 27, 2023 at 10:21:40AM +0800, Shawn Guo wrote:
> > > On Thu, Nov 09, 2023 at 10:51:13AM -0500, Frank Li wrote:
> > > > On Tue, Oct 17, 2023 at 03:46:57PM -0400, Frank Li wrote:
> > > > > Add I3C1 and I3C2.
> > > > > 
> > > > > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > > > > ---
> > > > 
> > > > @Guo Shawn:
> > > > 
> > > > Driver part already merged. 
> > > > 
> > > > Please pick up dts part
> > > 
> > > Rob had a comment [1] about SoC specific compatible.  That's not what we
> > > want?
> > > 
> > > Shawn
> > > 
> > > [1] https://lkml.iu.edu/hypermail/linux/kernel/2310.2/03035.html
> > 
> > Yeah, Rob's request here looks valid to me. Should just be a bindings
> > change Frank & fall back to the "silvaco,i3c-master-v1" compatible.
> > 
> > Cheers,
> > Conor.
> 
> @shawn:
> 	rob agree on "silvaco,i3c-master-v1" compatible.

Hmm, not sure I have seen that.  Here is what I saw from Rob:

"
The real problem here is not whether we have "v1" or not, but you need
an SoC specific compatible. Unless there's a public spec where we can
know exactly how many resets, clocks, interrupts, etc.
"

Shawn


From suzuki.poulose at arm.com  Wed Dec  6 01:32:19 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Wed, 6 Dec 2023 09:32:19 +0000
Subject: [GIT PULL] coresight: Fixes for v6.7-rc1
In-Reply-To: <2023120656-king-starting-3fe9@gregkh>
References: <20231116170119.1786378-1-suzuki.poulose@arm.com>
 <2023120656-king-starting-3fe9@gregkh>
Message-ID: <30439275-9c25-4dc4-ae21-d75af5963dab@arm.com>

On 06/12/2023 03:14, Greg KH wrote:
> On Thu, Nov 16, 2023 at 05:01:19PM +0000, Suzuki K Poulose wrote:
>> Hi Greg
>>
>> Please find fixes for hwtracing/coresight subsystem, targetting  Linux v6.7.
> 
> Sorry for the delay, now pulled and pushed out.

Thank you, Greg!

Suzuki



From lukma at denx.de  Wed Dec  6 01:33:46 2023
From: lukma at denx.de (Lukasz Majewski)
Date: Wed, 6 Dec 2023 10:33:46 +0100
Subject: [PATCH] ARM: dts: imx28-xea: Pass the 'model' property
In-Reply-To: <20231205132735.2016022-1-festevam@gmail.com>
References: <20231205132735.2016022-1-festevam@gmail.com>
Message-ID: <20231206103346.150e108e@wsk>

On Tue,  5 Dec 2023 10:27:35 -0300
Fabio Estevam <festevam at gmail.com> wrote:

> From: Fabio Estevam <festevam at denx.de>
> 
> Per root-node.yaml, 'model' is a required property.
> 
> Pass it to fix the following dt-schema warning:
> 
> imx28-xea.dtb: /: 'model' is a required property
> 	from schema $id: http://devicetree.org/schemas/root-node.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>
> ---
>  arch/arm/boot/dts/nxp/mxs/imx28-xea.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts
> b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts index
> a400c108f66a..cc54a0390f8c 100644 ---
> a/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts +++
> b/arch/arm/boot/dts/nxp/mxs/imx28-xea.dts @@ -8,6 +8,7 @@
>  #include "imx28-lwe.dtsi"
>  
>  / {
> +	model = "Liebherr Xea board";
>  	compatible = "lwn,imx28-xea", "fsl,imx28";
>  };
>  

Reviewed-by: Lukasz Majewski <lukma at denx.de>


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/79633e5e/attachment-0001.sig>

From heiko at sntech.de  Wed Dec  6 01:35:48 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Wed, 06 Dec 2023 10:35:48 +0100
Subject: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
In-Reply-To: <20231205202900.4617-1-CFSworks@gmail.com>
References: <20231205202900.4617-1-CFSworks@gmail.com>
Message-ID: <2724771.ElGaqSPkdT@diego>

Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards:
> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
> will sometimes (varying between specific RK3588 chips, not over time) shut
> off the DBI block, and reads to this range will instead stall
> indefinitely.
> 
> When this happens, it will prevent Linux from booting altogether. The
> PCIe driver will stall the CPU core once it attempts to read the version
> information from the DBI range.
> 
> Fix this boot hang by adding the correct pinctrl configuration to the
> PCIe 3.0 device node, which is the proper thing to do anyway. While
> we're at it, also add the necessary configuration to the PCIe 2.0 node,
> which may or may not fix the equivalent problem over there -- but is the
> proper thing to do anyway. :)
> 
> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
> Signed-off-by: Sam Edwards <CFSworks at gmail.com>
> ---
>  .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> index 9570b34aca2e..129f14dbd42f 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy at 1 {
>  &pcie2x1l1 {
>  	linux,pci-domain = <1>;
>  	pinctrl-names = "default";
> -	pinctrl-0 = <&pcie2_reset>;
> +	pinctrl-0 = <&pcie30x1m1_pins>;

This really throws me for a loop here - in the original submission too
already. Because somehow those pins are named pcie30x1... for the
pcie2 controller ;-) .


>  	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
>  	status = "okay";
>  };
> @@ -226,7 +226,7 @@ &pcie30phy {
>  &pcie3x4 {
>  	linux,pci-domain = <0>;
>  	pinctrl-names = "default";
> -	pinctrl-0 = <&pcie3_reset>;
> +	pinctrl-0 = <&pcie30x4m1_pins>;
>  	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
>  	vpcie3v3-supply = <&vcc3v3_pcie30>;
>  	status = "okay";
> @@ -245,17 +245,7 @@ hym8563_int: hym8563-int {
>  		};
>  	};
>  
> -	pcie2 {
> -		pcie2_reset: pcie2-reset {
> -			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
> -		};
> -	};
> -
>  	pcie3 {
> -		pcie3_reset: pcie3-reset {
> -			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
> -		};
> -
>  		vcc3v3_pcie30_en: pcie3-reg {
>  			rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
>  		};
> 






From daniel.lezcano at linaro.org  Wed Dec  6 01:35:58 2023
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 6 Dec 2023 10:35:58 +0100
Subject: [PATCH] clocksource: cadence-ttc: fix some kernel-doc warnings
In-Reply-To: <20231205230448.772-1-rdunlap@infradead.org>
References: <20231205230448.772-1-rdunlap@infradead.org>
Message-ID: <581d7e03-7415-49f7-b348-f4f6dc1c336b@linaro.org>

On 06/12/2023 00:04, Randy Dunlap wrote:
> Fix some function kernel-doc warnings to placate scripts/kernel-doc.
> 
> timer-cadence-ttc.c:79: warning: Function parameter or member 'clk_rate_change_nb' not described in 'ttc_timer'
> timer-cadence-ttc.c:158: warning: Function parameter or member 'cs' not described in '__ttc_clocksource_read'
> timer-cadence-ttc.c:194: warning: expecting prototype for ttc_set_{shutdown|oneshot|periodic}(). Prototype was for ttc_shutdown() instead
> timer-cadence-ttc.c:196: warning: No description found for return value of 'ttc_shutdown'
> timer-cadence-ttc.c:212: warning: No description found for return value of 'ttc_set_periodic'
> 
> Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
> Cc: Michal Simek <michal.simek at amd.com>
> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: linux-arm-kernel at lists.infradead.org
> ---

Applied, thanks

-- 
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From maxime.chevallier at bootlin.com  Wed Dec  6 01:38:26 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Wed, 6 Dec 2023 10:38:26 +0100
Subject: [RFC PATCH v2 3/8] net: pcs: pcs-mtk-lynxi: add platform driver
 for MT7988
In-Reply-To: <68bb81ac6bf99393c8de256f42e5715626590af8.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
	<68bb81ac6bf99393c8de256f42e5715626590af8.1701826319.git.daniel@makrotopia.org>
Message-ID: <20231206103826.4e396513@device.home>

Hello Daniel,

My two cents below :

On Wed, 6 Dec 2023 01:44:17 +0000
Daniel Golle <daniel at makrotopia.org> wrote:

> Introduce a proper platform MFD driver for the LynxI (H)SGMII PCS which
> is going to initially be used for the MT7988 SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

 [ ... ]

> +static int mtk_pcs_lynxi_enable(struct phylink_pcs *pcs)
> +{
> +	struct mtk_pcs_lynxi *mpcs = pcs_to_mtk_pcs_lynxi(pcs);
> +
> +	if (mpcs->sgmii_tx && mpcs->sgmii_rx) {
> +		clk_prepare_enable(mpcs->sgmii_rx);
> +		clk_prepare_enable(mpcs->sgmii_tx);

You can use the clk_bulk_prepare_enable() here

> +	}
> +
> +	return 0;
> +}
> +
>  static void mtk_pcs_lynxi_disable(struct phylink_pcs *pcs)
>  {
>  	struct mtk_pcs_lynxi *mpcs = pcs_to_mtk_pcs_lynxi(pcs);
>  
> +	regmap_set_bits(mpcs->regmap, SGMSYS_QPHY_PWR_STATE_CTRL, SGMII_PHYA_PWD);
> +
> +	if (mpcs->sgmii_tx && mpcs->sgmii_rx) {
> +		clk_disable_unprepare(mpcs->sgmii_tx);
> +		clk_disable_unprepare(mpcs->sgmii_rx);

and clk_bulk_disable_unprepare() here

 [...]

> +static int mtk_pcs_lynxi_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *np = dev->of_node;
> +	struct mtk_pcs_lynxi *mpcs;
> +	struct phylink_pcs *pcs;
> +	struct regmap *regmap;
> +	u32 flags = 0;
> +
> +	mpcs = devm_kzalloc(dev, sizeof(*mpcs), GFP_KERNEL);
> +	if (!mpcs)
> +		return -ENOMEM;
> +
> +	regmap = syscon_node_to_regmap(np->parent);
> +	if (IS_ERR(regmap))
> +		return PTR_ERR(regmap);
> +
> +	if (of_property_read_bool(np->parent, "mediatek,pnswap"))
> +		flags |= MTK_SGMII_FLAG_PN_SWAP;
> +
> +	mpcs->rstc = of_reset_control_get_shared(np->parent, NULL);
> +	if (IS_ERR(mpcs->rstc))
> +		return PTR_ERR(mpcs->rstc);
> +
> +	reset_control_deassert(mpcs->rstc);
> +	mpcs->sgmii_sel = devm_clk_get_enabled(dev, "sgmii_sel");
> +	if (IS_ERR(mpcs->sgmii_sel))
> +		return PTR_ERR(mpcs->sgmii_sel);
> +
> +	mpcs->sgmii_rx = devm_clk_get(dev, "sgmii_rx");
> +	if (IS_ERR(mpcs->sgmii_rx))
> +		return PTR_ERR(mpcs->sgmii_rx);
> +
> +	mpcs->sgmii_tx = devm_clk_get(dev, "sgmii_tx");
> +	if (IS_ERR(mpcs->sgmii_tx))
> +		return PTR_ERR(mpcs->sgmii_tx);

and clk bulk operations here as well ?

Maxime


From heiko at sntech.de  Wed Dec  6 01:42:05 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed,  6 Dec 2023 10:42:05 +0100
Subject: [PATCH 0/2] Theobroma-Systems Jaguar single board computer
In-Reply-To: <20231201191103.343097-1-heiko@sntech.de>
References: <20231201191103.343097-1-heiko@sntech.de>
Message-ID: <170185570322.596796.12623208720682445135.b4-ty@sntech.de>

On Fri, 1 Dec 2023 20:11:01 +0100, Heiko Stuebner wrote:
> This adds the Jaguar SBC from Theobroma Systems.
> 
> 
> Heiko Stuebner (2):
>   dt-bindings: arm: rockchip: Add Theobroma-Systems Jaguar SBC
>   arm64: dts: rockchip: add Theobroma Jaguar SBC
> 
> [...]

Applied, thanks!

[1/2] dt-bindings: arm: rockchip: Add Theobroma-Systems Jaguar SBC
      commit: 9aeb5f0321f8eb24c26b98b7dc416e21a765d499
[2/2] arm64: dts: rockchip: add Theobroma Jaguar SBC
      commit: e4e8169830b36e30ad5eec080762154e659f6eb4

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Wed Dec  6 01:42:04 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed,  6 Dec 2023 10:42:04 +0100
Subject: [RESEND PATCH] arm64: dts: rockchip: Fix eMMC Data Strobe PD
In-Reply-To: <20231205202900.4617-2-CFSworks@gmail.com>
References: <20231205202900.4617-2-CFSworks@gmail.com>
Message-ID: <170185570321.596796.2043963859516585499.b4-ty@sntech.de>

On Tue, 5 Dec 2023 12:29:00 -0800, Sam Edwards wrote:
> JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is
> currently used only in HS400 mode, as a device->host clock signal that
> "is used only in read operation. The Data Strobe is always High-Z (not
> driven by the device and pulled down by RDS) or Driven Low in write
> operation, except during CRC status response." RDS is a pull-down
> resistor specified in the 10K-100K ohm range. Thus per the standard, the
> Data Strobe is always pulled to ground (by the eMMC and/or RDS) during
> write operations.
> 
> [...]

Applied, thanks!

[1/1] arm64: dts: rockchip: Fix eMMC Data Strobe PD
      commit: 37f3d6108730713c411827ab4af764909f4dfc78

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From alexander.stein at ew.tq-group.com  Wed Dec  6 01:44:01 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Wed,  6 Dec 2023 10:44:01 +0100
Subject: [PATCH 1/1] media: nxp: imx8-isi-debug: Add missing registers to debugfs output
Message-ID: <20231206094401.491100-1-alexander.stein@ew.tq-group.com>

The extended address registers are missing in the debug output register
list. Add them.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
index 6709ab7ea1f3..3ac5685d6cc1 100644
--- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
+++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
@@ -66,6 +66,13 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
 		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF2_ADDR_V),
 		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
 		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
+		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),
 	};
 
 	struct mxc_isi_pipe *pipe = m->private;
-- 
2.34.1



From maxime.chevallier at bootlin.com  Wed Dec  6 01:44:48 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Wed, 6 Dec 2023 10:44:48 +0100
Subject: [RFC PATCH v2 2/8] phy: add driver for MediaTek pextp 10GE
 SerDes PHY
In-Reply-To: <63636378a52dd1ea7370dbf0ca3037a7d24004b9.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
	<63636378a52dd1ea7370dbf0ca3037a7d24004b9.1701826319.git.daniel@makrotopia.org>
Message-ID: <20231206104448.0774da58@device.home>

Hello Daniel,

On Wed, 6 Dec 2023 01:44:08 +0000
Daniel Golle <daniel at makrotopia.org> wrote:

> Add driver for MediaTek's pextp 10 Gigabit/s Ethernet SerDes PHY which
> can be found in the MT7988 SoC.
> 
> The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
> PHY_INTERFACE_MODE_* corresponding to the supported modes:
> 
>  * USXGMII
>  * 10GBase-R
>  * 5GBase-R
>  * 2500Base-X
>  * 1000Base-X
>  * Cisco SGMII (MAC side)
> 
> In order to work-around a performance issue present on the first of
> two PEXTP present in MT7988 special tuning is applied which can be
> selected by adding the mediatek,usxgmii-performance-errata property to
> the device tree node.
> 
> There is no documentation what-so-ever for the pextp registers and
> this driver is based on a GPL licensed implementation found in
> MediaTek's SDK.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---

 [...]

> +
> +static int mtk_pextp_power_on(struct phy *phy)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +	int ret;
> +
> +	ret = clk_prepare_enable(pextp->clk[0]);
> +	if (ret)
> +		return ret;
> +
> +	return clk_prepare_enable(pextp->clk[1]);
> +}

clk_bulk operations could be used here

> +static int mtk_pextp_power_off(struct phy *phy)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> +	clk_disable_unprepare(pextp->clk[1]);
> +	clk_disable_unprepare(pextp->clk[0]);
> +
> +	return 0;
> +}

Here

> +static const struct phy_ops mtk_pextp_ops = {
> +	.power_on	= mtk_pextp_power_on,
> +	.power_off	= mtk_pextp_power_off,
> +	.set_mode	= mtk_pextp_set_mode,
> +	.reset		= mtk_pextp_reset,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int mtk_pextp_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct phy_provider *phy_provider;
> +	struct mtk_pextp_phy *pextp;
> +	struct phy *phy;
> +
> +	if (!np)
> +		return -ENODEV;
> +
> +	pextp = devm_kzalloc(&pdev->dev, sizeof(*pextp), GFP_KERNEL);
> +	if (!pextp)
> +		return -ENOMEM;
> +
> +	pextp->base = devm_of_iomap(&pdev->dev, np, 0, NULL);
> +	if (!pextp->base)
> +		return -EIO;
> +
> +	pextp->dev = &pdev->dev;
> +	pextp->clk[0] = devm_clk_get(&pdev->dev, "topxtal");
> +	if (IS_ERR(pextp->clk[0]))
> +		return PTR_ERR(pextp->clk[0]);
> +
> +	pextp->clk[1] = devm_clk_get(&pdev->dev, "xfipll");
> +	if (IS_ERR(pextp->clk[1]))
> +		return PTR_ERR(pextp->clk[1]);

And here as well.

Thanks,

Maxime



From shengyang.chen at starfivetech.com  Wed Dec  6 01:43:48 2023
From: shengyang.chen at starfivetech.com (Shengyang Chen)
Date: Wed, 6 Dec 2023 17:43:48 +0800
Subject: [PATCH v1 1/2] dt-bindings: display: panel: raspberrypi: Add
 compatible property for waveshare 7inch touchscreen panel
In-Reply-To: <20231124-lesser-sinister-7f9cd7b80e35@spud>
References: <20231124104451.44271-1-shengyang.chen@starfivetech.com>
 <20231124104451.44271-2-shengyang.chen@starfivetech.com>
 <20231124-lesser-sinister-7f9cd7b80e35@spud>
Message-ID: <2d48e460-e46e-431f-bd7b-e34ebe73a40c@starfivetech.com>

Hi, Conor

On 2023/11/24 20:31, Conor Dooley wrote:
> On Fri, Nov 24, 2023 at 06:44:50PM +0800, Shengyang Chen wrote:
>> The waveshare 7inch touchscreen panel is a kind of raspberrypi pi
>> panel
> 
> Can you be more specific about what "is a kind of rpi panel" means?
> Are they using identical chips as controllers or something like that?
> 

Wareshare panel has same i2c slave address and registers address with 
the original raspberry pi panel. They both use Atmel firmware and they
got same reg id. It can be operated by using the driver of raspberry pi driver
after some change of the code. So I suppose it may be a kind of raspberry pi panel 
and discribe it in this way. It's my own judgement. Sorry about that.
Maybe just like Dave said, It cloned the behaviour of the raspberri pi panel.
I will change the discribtion in next version to not make other confused.

By the way, we will try Stefan's method before next version. 
The method we used in this patch may be abandoned if Stefan's method is verified in our platform.
At that time yaml may also be changed to fit new method.


>> and it can be drived by panel-raspberrypi-touchscreen.c.
>> Add compatible property for it.
>> 
>> Signed-off-by: Keith Zhao <keith.zhao at starfivetech.com>
>> Signed-off-by: Shengyang Chen <shengyang.chen at starfivetech.com>
>> ---
>>  .../bindings/display/panel/raspberrypi,7inch-touchscreen.yaml | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>> 
>> diff --git a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
>> index 22a083f7bc8e..e4e6cb4d4e5b 100644
>> --- a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
>> +++ b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
>> @@ -22,7 +22,9 @@ description: |+
>>  
>>  properties:
>>    compatible:
>> -    const: raspberrypi,7inch-touchscreen-panel
>> +    enum:
>> +      - raspberrypi,7inch-touchscreen-panel
>> +      - waveshare,7inch-touchscreen-panel
>>  
>>    reg:
>>      const: 0x45
>> -- 
>> 2.17.1
>> 


thanks.

Best Regards,
Shengyang



From shengyang.chen at starfivetech.com  Wed Dec  6 01:53:23 2023
From: shengyang.chen at starfivetech.com (Shengyang Chen)
Date: Wed, 6 Dec 2023 17:53:23 +0800
Subject: [PATCH v1 0/2] Add waveshare 7inch touchscreen panel support
In-Reply-To: <dab03c60-caa9-47e3-9dac-fa499227b67b@gmx.net>
References: <20231124104451.44271-1-shengyang.chen@starfivetech.com>
 <dab03c60-caa9-47e3-9dac-fa499227b67b@gmx.net>
Message-ID: <0447c983-ee90-475e-9356-ad451f32da1d@starfivetech.com>

Hi, Stefan

Thanks for your comment and review

On 2023/11/24 22:54, Stefan Wahren wrote:
> Hi Shengyang,
> 
> [fix address of Emma]
> 
> Am 24.11.23 um 11:44 schrieb Shengyang Chen:
>> This patchset adds waveshare 7inch touchscreen panel support
>> for the StarFive JH7110 SoC.
>>
>> Patch 1 add new compatible for the raspberrypi panel driver and its dt-binding.
>> Patch 2 add new display mode and new probing process for raspberrypi panel driver.
>>
>> Waveshare 7inch touchscreen panel is a kind of raspberrypi panel
>> which can be drived by raspberrypi panel driver.
>>
>> The series has been tested on the VisionFive 2 board.
> surprisingly i was recently working on the official Raspberry Pi
> touchscreen and was able to get it running the new way.
> 
> What do i mean with the new way. There is almost nothing special to the
> Raspberry Pi touchscreen, so we should try to use/extend existing
> components like:
> 
> CONFIG_DRM_PANEL_SIMPLE
> CONFIG_TOUCHSCREEN_EDT_FT5X06
> CONFIG_DRM_TOSHIBA_TC358762
> 
> The only special part is the Attiny on the connector PCB which requires:
> 
> CONFIG_REGULATOR_RASPBERRYPI_TOUCHSCREEN_ATTINY
> 
> So the whole point is to avoid writing monolitic drivers for simple
> panel like that.
> 
> There is a WIP branch based on top of Linux 6.7-rcX, which should
> demonstrate this approach [1]. Unfortunately it is not ready for
> upstreaming, but it has been tested on a Raspberry Pi 3 B Plus. Maybe
> this is helpful for your case.
> 
> Actually i consider panel-raspberrypi-touchscreen.c as a dead end, which
> shouldn't be extended.
> 
> Btw there are already DT overlays in mainline which seems to use the
> Raspberry Pi 7inch panel (without touch function yet) [2].
> 
> [1] - https://github.com/lategoodbye/rpi-zero/commits/v6.7-7inch-ts
> [2] -
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x-rpidsi.dtso?h=v6.6.2&id=6b4da1354fd81adace0cda448c77d8f2a47d8474
> 

Thank you very much for your advice. We will try this method before making new patch.
This method will be used if its verified in our soc.
If there is any problem, we may continue to contact. Thanks a lot.

>>
>> Shengyang Chen (2):
>> ?? dt-bindings: display: panel: raspberrypi: Add compatible property for
>> ???? waveshare 7inch touchscreen panel
>> ?? gpu: drm: panel: raspberrypi: add new display mode and new probing
>> ???? process
>>
>> ? .../panel/raspberrypi,7inch-touchscreen.yaml? |? 4 +-
>> ? .../drm/panel/panel-raspberrypi-touchscreen.c | 99 ++++++++++++++++---
>> ? 2 files changed, 91 insertions(+), 12 deletions(-)
>>
> 


thanks

Best Regards,
Shengyang


From maxime.chevallier at bootlin.com  Wed Dec  6 01:58:38 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Wed, 6 Dec 2023 10:58:38 +0100
Subject: [RFC PATCH v2 5/8] net: pcs: add driver for MediaTek USXGMII
 PCS
In-Reply-To: <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
	<3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
Message-ID: <20231206105838.069ae288@device.home>

Hello Daniel,

On Wed, 6 Dec 2023 01:44:38 +0000
Daniel Golle <daniel at makrotopia.org> wrote:

> Add driver for USXGMII PCS found in the MediaTek MT7988 SoC and supporting
> USXGMII, 10GBase-R and 5GBase-R interface modes. In order to support
> Cisco SGMII, 1000Base-X and 2500Base-X via the also present LynxI PCS
> create a wrapped PCS taking care of the components shared between the
> new USXGMII PCS and the legacy LynxI PCS.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---

[...]

> +
> +static int mtk_usxgmii_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
> +				  phy_interface_t interface,
> +				  const unsigned long *advertising,
> +				  bool permit_pause_to_mac)
> +{
> +	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
> +	unsigned int an_ctrl = 0, link_timer = 0, xfi_mode = 0, adapt_mode = 0;
> +	bool mode_changed = false;

Reverse christmas tree ordering can be used here (longest lines first)

> +
> +	if (interface == PHY_INTERFACE_MODE_USXGMII) {
> +		an_ctrl = FIELD_PREP(USXGMII_AN_SYNC_CNT, 0x1FF) | USXGMII_AN_ENABLE;
> +		link_timer = FIELD_PREP(USXGMII_LINK_TIMER_IDLE_DETECT, 0x7B) |
> +			     FIELD_PREP(USXGMII_LINK_TIMER_COMP_ACK_DETECT, 0x7B) |
> +			     FIELD_PREP(USXGMII_LINK_TIMER_AN_RESTART, 0x7B);
> +		xfi_mode = FIELD_PREP(USXGMII_XFI_RX_MODE, USXGMII_XFI_MODE_10G) |
> +			   FIELD_PREP(USXGMII_XFI_TX_MODE, USXGMII_XFI_MODE_10G);
> +	} else if (interface == PHY_INTERFACE_MODE_10GBASER) {
> +		an_ctrl = FIELD_PREP(USXGMII_AN_SYNC_CNT, 0x1FF);
> +		link_timer = FIELD_PREP(USXGMII_LINK_TIMER_IDLE_DETECT, 0x7B) |
> +			     FIELD_PREP(USXGMII_LINK_TIMER_COMP_ACK_DETECT, 0x7B) |
> +			     FIELD_PREP(USXGMII_LINK_TIMER_AN_RESTART, 0x7B);
> +		xfi_mode = FIELD_PREP(USXGMII_XFI_RX_MODE, USXGMII_XFI_MODE_10G) |
> +			   FIELD_PREP(USXGMII_XFI_TX_MODE, USXGMII_XFI_MODE_10G);
> +		adapt_mode = USXGMII_RATE_UPDATE_MODE;
> +	} else if (interface == PHY_INTERFACE_MODE_5GBASER) {
> +		an_ctrl = FIELD_PREP(USXGMII_AN_SYNC_CNT, 0xFF);
> +		link_timer = FIELD_PREP(USXGMII_LINK_TIMER_IDLE_DETECT, 0x3D) |
> +			     FIELD_PREP(USXGMII_LINK_TIMER_COMP_ACK_DETECT, 0x3D) |
> +			     FIELD_PREP(USXGMII_LINK_TIMER_AN_RESTART, 0x3D);
> +		xfi_mode = FIELD_PREP(USXGMII_XFI_RX_MODE, USXGMII_XFI_MODE_5G) |
> +			   FIELD_PREP(USXGMII_XFI_TX_MODE, USXGMII_XFI_MODE_5G);
> +		adapt_mode = USXGMII_RATE_UPDATE_MODE;
> +	} else {
> +		return -EINVAL;
> +	}
> +
> +	adapt_mode |= FIELD_PREP(USXGMII_RATE_ADAPT_MODE, USXGMII_RATE_ADAPT_MODE_X1);
> +
> +	if (mpcs->interface != interface) {
> +		mpcs->interface = interface;
> +		mode_changed = true;
> +	}
> +
> +	mtk_usxgmii_reset(mpcs);
> +
> +	/* Setup USXGMII AN ctrl */
> +	mtk_m32(mpcs, RG_PCS_AN_CTRL0,
> +		USXGMII_AN_SYNC_CNT | USXGMII_AN_ENABLE,
> +		an_ctrl);
> +
> +	mtk_m32(mpcs, RG_PCS_AN_CTRL2,
> +		USXGMII_LINK_TIMER_IDLE_DETECT |
> +		USXGMII_LINK_TIMER_COMP_ACK_DETECT |
> +		USXGMII_LINK_TIMER_AN_RESTART,
> +		link_timer);
> +
> +	mpcs->neg_mode = neg_mode;
> +
> +	/* Gated MAC CK */
> +	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
> +		USXGMII_MAC_CK_GATED, USXGMII_MAC_CK_GATED);
> +
> +	/* Enable interface force mode */
> +	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
> +		USXGMII_IF_FORCE_EN, USXGMII_IF_FORCE_EN);
> +
> +	/* Setup USXGMII adapt mode */
> +	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
> +		USXGMII_RATE_UPDATE_MODE | USXGMII_RATE_ADAPT_MODE,
> +		adapt_mode);
> +
> +	/* Setup USXGMII speed */
> +	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
> +		USXGMII_XFI_RX_MODE | USXGMII_XFI_TX_MODE,
> +		xfi_mode);
> +
> +	usleep_range(1, 10);
> +
> +	/* Un-gated MAC CK */
> +	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1, USXGMII_MAC_CK_GATED, 0);
> +
> +	usleep_range(1, 10);
> +
> +	/* Disable interface force mode for the AN mode */
> +	if (an_ctrl & USXGMII_AN_ENABLE)
> +		mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1, USXGMII_IF_FORCE_EN, 0);
> +
> +	return mode_changed;
> +}
> +

[...]

> +static void mtk_usxgmii_pcs_get_state(struct phylink_pcs *pcs,
> +				      struct phylink_link_state *state)
> +{
> +	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
> +
> +	/* Refresh USXGMII link status by toggling RG_PCS_AN_STATUS_UPDATE */
> +	mtk_m32(mpcs, RG_PCS_RX_STATUS0, RG_PCS_RX_STATUS_UPDATE,
> +		RG_PCS_RX_STATUS_UPDATE);
> +	ndelay(1020);
> +	mtk_m32(mpcs, RG_PCS_RX_STATUS0, RG_PCS_RX_STATUS_UPDATE, 0);
> +	ndelay(1020);
> +
> +	/* Read USXGMII link status */
> +	state->link = FIELD_GET(RG_PCS_RX_LINK_STATUS,
> +				mtk_r32(mpcs, RG_PCS_RX_STATUS0));
> +
> +	/* Continuously repeat re-configuration sequence until link comes up */
> +	if (!state->link) {
> +		mtk_usxgmii_pcs_config(pcs, mpcs->neg_mode,
> +				       state->interface, NULL, false);
> +		return;

.pcs_get_state() isn't called only for link state polling,but also when querying
the link state from ethtool, from phylink_ethtool_ksettings_get().

As mtk_usxgmii_pcs_config triggers a pcs reset and reconfiguration, won't this disrupt
the link ? 

Thanks,

Maxime


From angelogioacchino.delregno at collabora.com  Wed Dec  6 02:02:30 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 6 Dec 2023 11:02:30 +0100
Subject: [RFC PATCH v3 4/5] arm64: dts: mediatek: mt8173-elm-hana: Mark
 touchscreens and trackpads as fail
In-Reply-To: <CAGXv+5G5fFTv8zn=YamSdccjuYemE5oKBqjb8CSyGzu9aMJ0eg@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org>
 <20231128084236.157152-5-wenst@chromium.org>
 <CAD=FV=W01gfxV6RN2o6CVS7jjf8qgKP-jUy9Bp94d2hWzVC48A@mail.gmail.com>
 <CAGXv+5E+R292XsOFSL-j0KJMmVJjWtxMRgCK8besP7mo6NDOWA@mail.gmail.com>
 <CAD=FV=UQkAjgMuR85cPikNtCxsODWPWs7cibOcOoNGdjSSvF8Q@mail.gmail.com>
 <3700f05f-2411-4422-972f-f3df690efb84@collabora.com>
 <CAGXv+5G5fFTv8zn=YamSdccjuYemE5oKBqjb8CSyGzu9aMJ0eg@mail.gmail.com>
Message-ID: <4b9ea82c-d1a4-47b6-ba03-346cfdedef05@collabora.com>

Il 06/12/23 03:55, Chen-Yu Tsai ha scritto:
> On Tue, Dec 5, 2023 at 6:22?PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno at collabora.com> wrote:
>>
>> Il 04/12/23 17:50, Doug Anderson ha scritto:
>>> Hi,
>>>
>>> On Sun, Dec 3, 2023 at 10:59?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>>>>
>>>> On Sat, Dec 2, 2023 at 8:58?AM Doug Anderson <dianders at chromium.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
>>>>>>
>>>>>> @@ -44,6 +46,7 @@ trackpad2: trackpad at 2c {
>>>>>>                   reg = <0x2c>;
>>>>>>                   hid-descr-addr = <0x0020>;
>>>>>>                   wakeup-source;
>>>>>> +               status = "fail-needs-probe";
>>>>>
>>>>> While doing this, you could also remove the hack where the trackpad
>>>>> IRQ pinctrl is listed under i2c4.
>>>>
>>>> Sure. I do think we can do away with it though. According to at least one
>>>> schematic, the interrupt line has pull-ups on both sides of the voltage
>>>> shifter.
>>>>
>>>> BTW, The touchscreen doesn't have pinctrl entries. This has pull-ups on
>>>> both sides of the voltage shifter as well.
>>>
>>> I dunno if the convention is different on Mediatek boards, but at
>>> least on boards I've been involved with in the past we've always put
>>> pinctrl entries just to make things explicit. This meant that we
>>> didn't rely on the firmware/bootrom/defaults to leave pulls in any
>>> particular state. ...otherwise those external pull-ups could be
>>> fighting with internal pull-downs, right?
>>>
>>
>> MediaTek boards aren't special and there's no good reason for those to rely on
>> firmware/bootrom/defaults - so there is no good reason to avoid declaring any
>> relevant pinctrl entry.
> 
> I think this should be migrated to use the proper GPIO bindings: the
> GPIO_PULL_UP / GPIO_PULL_DOWN / GPIO_BIAS_DISABLE flags.
> 
> But that's a different discussion.
> 

100% agreed.

Cheers,
Angelo



From tabba at google.com  Wed Dec  6 02:04:50 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:50 +0000
Subject: [PATCH v2 00/12] KVM: arm64: Fixes to fine grain traps and pKVM traps
Message-ID: <20231206100503.564090-1-tabba@google.com>

Changes from v1:
- Handle HAFGRTR_EL2 in nested virt
- Update the nested virt FGT tables with the added trap bits (Marc)
- Use the generated value for RES0 (Marc)
- Calculate the value of NMASK based on RES0 and MASK

This patch series has fixes, updates, and code for validating
fine grain trap register masks, as well as some fixes to feature
trapping in pKVM.

New fine grain trap (FGT) bits have been defined in the latest
Arm Architecture System Registers xml specification (2023-09)
[*], so the code is updated to reflect them. Moreover, some of
the already-defined masks overlap with RES0, which this series
fixes.

It also adds FGT register masks that weren't defined earlier,
handling of HAFGRTR_EL2 in nested virt, as well as build time
validation that the bits of the various masks are all accounted
for and without overlap.

Based on 6.7-rc4.

Cheers,
/fuad

[*] https://developer.arm.com/downloads/-/exploration-tools

Fuad Tabba (12):
  KVM: Add missing HCRX_EL2 field definitions
  KVM: arm64: Add latest HFGxTR_EL2 FGT entries to nested virt
  KVM: arm64: Add latest HFGITR_EL2 FGT entries to nested virt
  KVM: arm64: Add bit masks for HAFGRTR_EL2
  KVM: arm64: Handle HAFGRTR_EL2 trapping in nested virt
  KVM: arm64: Update and fix FGT register masks
  KVM: arm64: Add build validation for FGT trap mask values
  KVM: arm64: Use generated FGT RES0 bits instead of specifying them
  KVM: arm64: Generate the HFGWTR-only RES0 bits
  KVM: arm64: Define FGT NMASK bits relative to other fields
  KVM: arm64: Trap external trace for protected VMs
  KVM: arm64: Mark CMOW as allowed for protected VMs

 arch/arm64/include/asm/kvm_arm.h              | 58 +++++++------
 arch/arm64/include/asm/kvm_host.h             |  1 +
 arch/arm64/include/asm/sysreg.h               | 20 +++++
 arch/arm64/kvm/emulate-nested.c               | 63 ++++++++++++++
 arch/arm64/kvm/hyp/include/hyp/switch.h       | 29 +++++++
 .../arm64/kvm/hyp/include/nvhe/fixed_config.h |  4 +-
 arch/arm64/kvm/hyp/nvhe/pkvm.c                |  4 +
 arch/arm64/kvm/sys_regs.c                     |  1 +
 arch/arm64/tools/sysreg                       | 82 ++++++++++++++++++-
 9 files changed, 231 insertions(+), 31 deletions(-)


base-commit: 33cc938e65a98f1d29d0a18403dbbee050dcad9a
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:04:51 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:51 +0000
Subject: [PATCH v2 01/12] KVM: Add missing HCRX_EL2 field definitions
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-2-tabba@google.com>

Add the latest field definitions to HCRX_EL2 from the 2023-09 Arm
Architecture System Registers xml specification [*].

These fields aren't used yet. This is done mainly to get the
correct generated value for the register's RES0 mask.

[*] https://developer.arm.com/documentation/ddi0601/2023-09/AArch64-Registers/HCRX-EL2--Extended-Hypervisor-Configuration-Register

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/tools/sysreg | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 96cbeeab4eec..c6cc8f2396e6 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2300,7 +2300,9 @@ Fields	ZCR_ELx
 EndSysreg
 
 Sysreg	HCRX_EL2	3	4	1	2	2
-Res0	63:23
+Res0	63:25
+Field	24	PACMEn
+Field	23	EnFPM
 Field	22	GCSEn
 Field	21	EnIDCP128
 Field	20	EnSDERR
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:04:53 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:53 +0000
Subject: [PATCH v2 03/12] KVM: arm64: Add latest HFGITR_EL2 FGT entries to
 nested virt
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-4-tabba@google.com>

Add the missing nested virt FGT table entries HFGITR_EL2. Based
on the 2023-09 Arm Architecture System Registers xml
specification [*]. Add the missing field definitions as well,
both to generate the correct RES0 mask and to be able to toggle
their FGT bits.

Also adds definitions of some of the missing system registers and
instructions, which can be trapped by the FGT bits.

[*] https://developer.arm.com/downloads/-/exploration-tools

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/sysreg.h | 7 +++++++
 arch/arm64/kvm/emulate-nested.c | 5 +++++
 arch/arm64/tools/sysreg         | 4 +++-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 7b469b3ac1f9..5892f9f1b541 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -658,6 +658,7 @@
 #define OP_AT_S1E0W	sys_insn(AT_Op0, 0, AT_CRn, 8, 3)
 #define OP_AT_S1E1RP	sys_insn(AT_Op0, 0, AT_CRn, 9, 0)
 #define OP_AT_S1E1WP	sys_insn(AT_Op0, 0, AT_CRn, 9, 1)
+#define OP_AT_S1E1A	sys_insn(AT_Op0, 0, AT_CRn, 9, 2)
 #define OP_AT_S1E2R	sys_insn(AT_Op0, 4, AT_CRn, 8, 0)
 #define OP_AT_S1E2W	sys_insn(AT_Op0, 4, AT_CRn, 8, 1)
 #define OP_AT_S12E1R	sys_insn(AT_Op0, 4, AT_CRn, 8, 4)
@@ -794,10 +795,16 @@
 #define OP_TLBI_VMALLS12E1NXS		sys_insn(1, 4, 9, 7, 6)
 
 /* Misc instructions */
+#define OP_GCSPUSHX			sys_insn(1, 0, 7, 7, 4)
+#define OP_GCSPOPCX			sys_insn(1, 0, 7, 7, 5)
+#define OP_GCSPOPX			sys_insn(1, 0, 7, 7, 6)
+#define OP_GCSPUSHM			sys_insn(1, 3, 7, 7, 0)
+
 #define OP_BRB_IALL			sys_insn(1, 1, 7, 2, 4)
 #define OP_BRB_INJ			sys_insn(1, 1, 7, 2, 5)
 #define OP_CFP_RCTX			sys_insn(1, 3, 7, 3, 4)
 #define OP_DVP_RCTX			sys_insn(1, 3, 7, 3, 5)
+#define OP_COSP_RCTX			sys_insn(1, 3, 7, 3, 6)
 #define OP_CPP_RCTX			sys_insn(1, 3, 7, 3, 7)
 
 /* Common SCTLR_ELx flags. */
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index 8b473a1bbc11..89901550db34 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -1117,6 +1117,11 @@ static const struct encoding_to_trap_config encoding_to_fgt[] __initconst = {
 	SR_FGT(SYS_AFSR1_EL1, 		HFGxTR, AFSR1_EL1, 1),
 	SR_FGT(SYS_AFSR0_EL1, 		HFGxTR, AFSR0_EL1, 1),
 	/* HFGITR_EL2 */
+	SR_FGT(OP_AT_S1E1A, 		HFGITR, ATS1E1A, 1),
+	SR_FGT(OP_COSP_RCTX, 		HFGITR, COSPRCTX, 1),
+	SR_FGT(OP_GCSPUSHX, 		HFGITR, nGCSEPP, 0),
+	SR_FGT(OP_GCSPOPX, 		HFGITR, nGCSEPP, 0),
+	SR_FGT(OP_GCSPUSHM, 		HFGITR, nGCSPUSHM_EL1, 0),
 	SR_FGT(OP_BRB_IALL, 		HFGITR, nBRBIALL, 0),
 	SR_FGT(OP_BRB_INJ, 		HFGITR, nBRBINJ, 0),
 	SR_FGT(SYS_DC_CVAC, 		HFGITR, DCCVAC, 1),
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index c6cc8f2396e6..61cc3bcfc3fa 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2102,7 +2102,9 @@ Fields	HFGxTR_EL2
 EndSysreg
 
 Sysreg HFGITR_EL2	3	4	1	1	6
-Res0	63:61
+Res0	63
+Field	62	ATS1E1A
+Res0	61
 Field	60	COSPRCTX
 Field	59	nGCSEPP
 Field	58	nGCSSTR_EL1
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:04:52 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:52 +0000
Subject: [PATCH v2 02/12] KVM: arm64: Add latest HFGxTR_EL2 FGT entries to
 nested virt
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-3-tabba@google.com>

Add the missing nested virt FGT table entries HFGxTR_EL2. Based
on the 2023-09 Arm Architecture System Registers xml
specification [*].

Also adds definitions of some of the missing system registers,
which can be trapped by the FGT bits.

[*] https://developer.arm.com/downloads/-/exploration-tools

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/sysreg.h | 13 +++++++++++++
 arch/arm64/kvm/emulate-nested.c | 10 ++++++++++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 5e65f51c10d2..7b469b3ac1f9 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -297,6 +297,10 @@
 #define SYS_APGAKEYLO_EL1		sys_reg(3, 0, 2, 3, 0)
 #define SYS_APGAKEYHI_EL1		sys_reg(3, 0, 2, 3, 1)
 
+#define SYS_GCSCR_EL1			sys_reg(3, 0, 2, 5, 0)
+#define SYS_GCSPR_EL1			sys_reg(3, 0, 2, 5, 1)
+#define SYS_GCSCRE0_EL1			sys_reg(3, 0, 2, 5, 2)
+
 #define SYS_SPSR_EL1			sys_reg(3, 0, 4, 0, 0)
 #define SYS_ELR_EL1			sys_reg(3, 0, 4, 0, 1)
 
@@ -356,7 +360,11 @@
 #define SYS_PMMIR_EL1			sys_reg(3, 0, 9, 14, 6)
 
 #define SYS_MAIR_EL1			sys_reg(3, 0, 10, 2, 0)
+#define SYS_MAIR2_EL1			sys_reg(3, 0, 10, 2, 1)
+#define SYS_POR_EL1			sys_reg(3, 0, 10, 2, 4)
+#define SYS_S2POR_EL1			sys_reg(3, 0, 10, 2, 5)
 #define SYS_AMAIR_EL1			sys_reg(3, 0, 10, 3, 0)
+#define SYS_AMAIR2_EL1			sys_reg(3, 0, 10, 3, 1)
 
 #define SYS_VBAR_EL1			sys_reg(3, 0, 12, 0, 0)
 #define SYS_DISR_EL1			sys_reg(3, 0, 12, 1, 1)
@@ -390,6 +398,7 @@
 #define SYS_ICC_IGRPEN1_EL1		sys_reg(3, 0, 12, 12, 7)
 
 #define SYS_ACCDATA_EL1			sys_reg(3, 0, 13, 0, 5)
+#define SYS_RCWMASK_EL1			sys_reg(3, 0, 13, 0, 6)
 
 #define SYS_CNTKCTL_EL1			sys_reg(3, 0, 14, 1, 0)
 
@@ -398,6 +407,8 @@
 #define SYS_RNDR_EL0			sys_reg(3, 3, 2, 4, 0)
 #define SYS_RNDRRS_EL0			sys_reg(3, 3, 2, 4, 1)
 
+#define SYS_GCSPR_EL0			sys_reg(3, 3, 2, 5, 1)
+
 #define SYS_PMCR_EL0			sys_reg(3, 3, 9, 12, 0)
 #define SYS_PMCNTENSET_EL0		sys_reg(3, 3, 9, 12, 1)
 #define SYS_PMCNTENCLR_EL0		sys_reg(3, 3, 9, 12, 2)
@@ -412,6 +423,8 @@
 #define SYS_PMUSERENR_EL0		sys_reg(3, 3, 9, 14, 0)
 #define SYS_PMOVSSET_EL0		sys_reg(3, 3, 9, 14, 3)
 
+#define SYS_POR_EL0			sys_reg(3, 3, 10, 2, 4)
+
 #define SYS_TPIDR_EL0			sys_reg(3, 3, 13, 0, 2)
 #define SYS_TPIDRRO_EL0			sys_reg(3, 3, 13, 0, 3)
 #define SYS_TPIDR2_EL0			sys_reg(3, 3, 13, 0, 5)
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index 06185216a297..8b473a1bbc11 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -1042,10 +1042,20 @@ enum fg_filter_id {
 
 static const struct encoding_to_trap_config encoding_to_fgt[] __initconst = {
 	/* HFGRTR_EL2, HFGWTR_EL2 */
+	SR_FGT(SYS_AMAIR2_EL1,		HFGxTR, nAMAIR2_EL1, 0),
+	SR_FGT(SYS_MAIR2_EL1,		HFGxTR, nMAIR2_EL1, 0),
+	SR_FGT(SYS_S2POR_EL1,		HFGxTR, nS2POR_EL1, 0),
+	SR_FGT(SYS_POR_EL1,		HFGxTR, nPOR_EL1, 0),
+	SR_FGT(SYS_POR_EL0,		HFGxTR, nPOR_EL0, 0),
 	SR_FGT(SYS_PIR_EL1,		HFGxTR, nPIR_EL1, 0),
 	SR_FGT(SYS_PIRE0_EL1,		HFGxTR, nPIRE0_EL1, 0),
+	SR_FGT(SYS_RCWMASK_EL1,		HFGxTR, nRCWMASK_EL1, 0),
 	SR_FGT(SYS_TPIDR2_EL0,		HFGxTR, nTPIDR2_EL0, 0),
 	SR_FGT(SYS_SMPRI_EL1,		HFGxTR, nSMPRI_EL1, 0),
+	SR_FGT(SYS_GCSCR_EL1,		HFGxTR, nGCS_EL1, 0),
+	SR_FGT(SYS_GCSPR_EL1,		HFGxTR, nGCS_EL1, 0),
+	SR_FGT(SYS_GCSCRE0_EL1,		HFGxTR, nGCS_EL0, 0),
+	SR_FGT(SYS_GCSPR_EL0,		HFGxTR, nGCS_EL0, 0),
 	SR_FGT(SYS_ACCDATA_EL1,		HFGxTR, nACCDATA_EL1, 0),
 	SR_FGT(SYS_ERXADDR_EL1,		HFGxTR, ERXADDR_EL1, 1),
 	SR_FGT(SYS_ERXPFGCDN_EL1,	HFGxTR, ERXPFGCDN_EL1, 1),
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:04:54 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:54 +0000
Subject: [PATCH v2 04/12] KVM: arm64: Add bit masks for HAFGRTR_EL2
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-5-tabba@google.com>

To support HAFGRTR_EL2 supported in nested virt in the following
patch, first add its bitmask definitions based on the 2023-09
Arm Architecture System Registers xml specification [*].

[*] https://developer.arm.com/downloads/-/exploration-tools

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index b85f46a73e21..7de0a7062625 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -370,6 +370,10 @@
 #define __HDFGWTR_EL2_MASK	~__HDFGWTR_EL2_nMASK
 #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
 
+#define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
+#define __HAFGRTR_EL2_MASK	(GENMASK(49, 17) | GENMASK(4, 0))
+#define __HAFGRTR_EL2_nMASK	0UL
+
 /* Similar definitions for HCRX_EL2 */
 #define __HCRX_EL2_RES0		(GENMASK(63, 16) | GENMASK(13, 12))
 #define __HCRX_EL2_MASK		(0)
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:04:55 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:55 +0000
Subject: [PATCH v2 05/12] KVM: arm64: Handle HAFGRTR_EL2 trapping in nested virt
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-6-tabba@google.com>

Add the encodings to fine grain trapping fields for HAFGRTR_EL2
and add the associated handling code in nested virt. Based on
the 2023-09 Arm Architecture System Registers xml
specification [*]. Add the missing field definitions as well,
both to generate the correct RES0 mask and to be able to toggle
their FGT bits.

Also add the code for handling FGT trapping, reading of the
register, to nested virt.

[*] https://developer.arm.com/downloads/-/exploration-tools

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_host.h       |  1 +
 arch/arm64/kvm/emulate-nested.c         | 48 +++++++++++++++++++++++++
 arch/arm64/kvm/hyp/include/hyp/switch.h | 11 ++++++
 arch/arm64/kvm/sys_regs.c               |  1 +
 arch/arm64/tools/sysreg                 | 43 ++++++++++++++++++++++
 5 files changed, 104 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 824f29f04916..ba14648e2de2 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -443,6 +443,7 @@ enum vcpu_sysreg {
 	HFGITR_EL2,
 	HDFGRTR_EL2,
 	HDFGWTR_EL2,
+	HAFGRTR_EL2,
 	CNTHP_CTL_EL2,
 	CNTHP_CVAL_EL2,
 	CNTHV_CTL_EL2,
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index 89901550db34..431fd429932d 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -1012,6 +1012,7 @@ enum fgt_group_id {
 	HDFGRTR_GROUP,
 	HDFGWTR_GROUP,
 	HFGITR_GROUP,
+	HAFGRTR_GROUP,
 
 	/* Must be last */
 	__NR_FGT_GROUP_IDS__
@@ -1689,6 +1690,49 @@ static const struct encoding_to_trap_config encoding_to_fgt[] __initconst = {
 	SR_FGT(SYS_PMCR_EL0,		HDFGWTR, PMCR_EL0, 1),
 	SR_FGT(SYS_PMSWINC_EL0,		HDFGWTR, PMSWINC_EL0, 1),
 	SR_FGT(SYS_OSLAR_EL1,		HDFGWTR, OSLAR_EL1, 1),
+	/*
+	 * HAFGRTR_EL2
+	 */
+	SR_FGT(SYS_AMEVTYPER1_EL0(15),	HAFGRTR, AMEVTYPER115_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(14),	HAFGRTR, AMEVTYPER114_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(13),	HAFGRTR, AMEVTYPER113_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(12),	HAFGRTR, AMEVTYPER112_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(11),	HAFGRTR, AMEVTYPER111_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(10),	HAFGRTR, AMEVTYPER110_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(9),	HAFGRTR, AMEVTYPER19_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(8),	HAFGRTR, AMEVTYPER18_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(7),	HAFGRTR, AMEVTYPER17_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(6),	HAFGRTR, AMEVTYPER16_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(5),	HAFGRTR, AMEVTYPER15_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(4),	HAFGRTR, AMEVTYPER14_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(3),	HAFGRTR, AMEVTYPER13_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(2),	HAFGRTR, AMEVTYPER12_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(1),	HAFGRTR, AMEVTYPER11_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(0),	HAFGRTR, AMEVTYPER10_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(15),	HAFGRTR, AMEVCNTR115_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(14),	HAFGRTR, AMEVCNTR114_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(13),	HAFGRTR, AMEVCNTR113_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(12),	HAFGRTR, AMEVCNTR112_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(11),	HAFGRTR, AMEVCNTR111_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(10),	HAFGRTR, AMEVCNTR110_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(9),	HAFGRTR, AMEVCNTR19_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(8),	HAFGRTR, AMEVCNTR18_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(7),	HAFGRTR, AMEVCNTR17_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(6),	HAFGRTR, AMEVCNTR16_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(5),	HAFGRTR, AMEVCNTR15_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(4),	HAFGRTR, AMEVCNTR14_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(3),	HAFGRTR, AMEVCNTR13_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(2),	HAFGRTR, AMEVCNTR12_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(1),	HAFGRTR, AMEVCNTR11_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(0),	HAFGRTR, AMEVCNTR10_EL0, 1),
+	SR_FGT(SYS_AMCNTENCLR1_EL0,	HAFGRTR, AMCNTEN1, 1),
+	SR_FGT(SYS_AMCNTENSET1_EL0,	HAFGRTR, AMCNTEN1, 1),
+	SR_FGT(SYS_AMCNTENCLR0_EL0,	HAFGRTR, AMCNTEN0, 1),
+	SR_FGT(SYS_AMCNTENSET0_EL0,	HAFGRTR, AMCNTEN0, 1),
+	SR_FGT(SYS_AMEVCNTR0_EL0(3),	HAFGRTR, AMEVCNTR03_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR0_EL0(2),	HAFGRTR, AMEVCNTR02_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR0_EL0(1),	HAFGRTR, AMEVCNTR01_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR0_EL0(0),	HAFGRTR, AMEVCNTR00_EL0, 1),
 };
 
 static union trap_config get_trap_config(u32 sysreg)
@@ -1909,6 +1953,10 @@ bool __check_nv_sr_forward(struct kvm_vcpu *vcpu)
 			val = sanitised_sys_reg(vcpu, HDFGWTR_EL2);
 		break;
 
+	case HAFGRTR_GROUP:
+		val = sanitised_sys_reg(vcpu, HAFGRTR_EL2);
+		break;
+
 	case HFGITR_GROUP:
 		val = sanitised_sys_reg(vcpu, HFGITR_EL2);
 		switch (tc.fgf) {
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index f99d8af0b9af..76a3d78b13d9 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -153,6 +153,17 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 
 	write_sysreg_s(r_val, SYS_HDFGRTR_EL2);
 	write_sysreg_s(w_val, SYS_HDFGWTR_EL2);
+
+	ctxt_sys_reg(hctxt, HAFGRTR_EL2) = read_sysreg_s(SYS_HAFGRTR_EL2);
+
+	r_clr = r_set = 0;
+	compute_clr_set(vcpu, HAFGRTR_EL2, r_clr, r_set);
+
+	r_val = __HAFGRTR_EL2_nMASK;
+	r_val |= r_set;
+	r_val &= ~r_clr;
+
+	write_sysreg_s(r_val, SYS_HAFGRTR_EL2);
 }
 
 static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4735e1b37fb3..8bb297a2df38 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2532,6 +2532,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_DACR32_EL2), trap_undef, reset_unknown, DACR32_EL2 },
 	EL2_REG(HDFGRTR_EL2, access_rw, reset_val, 0),
 	EL2_REG(HDFGWTR_EL2, access_rw, reset_val, 0),
+	EL2_REG(HAFGRTR_EL2, access_rw, reset_val, 0),
 	EL2_REG(SPSR_EL2, access_rw, reset_val, 0),
 	EL2_REG(ELR_EL2, access_rw, reset_val, 0),
 	{ SYS_DESC(SYS_SP_EL1), access_sp_el1},
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 61cc3bcfc3fa..e5631f4e62f4 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2297,6 +2297,49 @@ Field	1	DBGBVRn_EL1
 Field	0	DBGBCRn_EL1
 EndSysreg
 
+Sysreg HAFGRTR_EL2	3	4	3	1	6
+Res0	63:50
+Field	49	AMEVTYPER115_EL0
+Field	48	AMEVCNTR115_EL0
+Field	47	AMEVTYPER114_EL0
+Field	46	AMEVCNTR114_EL0
+Field	45	AMEVTYPER113_EL0
+Field	44	AMEVCNTR113_EL0
+Field	43	AMEVTYPER112_EL0
+Field	42	AMEVCNTR112_EL0
+Field	41	AMEVTYPER111_EL0
+Field	40	AMEVCNTR111_EL0
+Field	39	AMEVTYPER110_EL0
+Field	38	AMEVCNTR110_EL0
+Field	37	AMEVTYPER19_EL0
+Field	36	AMEVCNTR19_EL0
+Field	35	AMEVTYPER18_EL0
+Field	34	AMEVCNTR18_EL0
+Field	33	AMEVTYPER17_EL0
+Field	32	AMEVCNTR17_EL0
+Field	31	AMEVTYPER16_EL0
+Field	30	AMEVCNTR16_EL0
+Field	29	AMEVTYPER15_EL0
+Field	28	AMEVCNTR15_EL0
+Field	27	AMEVTYPER14_EL0
+Field	26	AMEVCNTR14_EL0
+Field	25	AMEVTYPER13_EL0
+Field	24	AMEVCNTR13_EL0
+Field	23	AMEVTYPER12_EL0
+Field	22	AMEVCNTR12_EL0
+Field	21	AMEVTYPER11_EL0
+Field	20	AMEVCNTR11_EL0
+Field	19	AMEVTYPER10_EL0
+Field	18	AMEVCNTR10_EL0
+Field	17	AMCNTEN1
+Res0	16:5
+Field	4	AMEVCNTR03_EL0
+Field	3	AMEVCNTR02_EL0
+Field	2	AMEVCNTR01_EL0
+Field	1	AMEVCNTR00_EL0
+Field	0	AMCNTEN0
+EndSysreg
+
 Sysreg	ZCR_EL2	3	4	1	2	0
 Fields	ZCR_ELx
 EndSysreg
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:04:56 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:56 +0000
Subject: [PATCH v2 06/12] KVM: arm64: Update and fix FGT register masks
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-7-tabba@google.com>

New trap bits have been defined in the 2023-09 Arm Architecture
System Registers xml specification [*]. Moreover, the existing
definitions of some of the mask and the RES0 bits overlap, which
could be wrong, confusing, or both.

Update the bits to represent the latest spec (as of this patch,
2023-09), and ensure that the existing bits are consistent.

Subsequent patches will use the generated RES0 fields instead of
specifying them manually. This patch keeps the manual encoding of
the bits to make it easier to review the series.

[*] https://developer.arm.com/downloads/-/exploration-tools

Fixes: 0fd76865006d ("KVM: arm64: Add nPIR{E0}_EL1 to HFG traps")
Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 39 ++++++++++++++++++++------------
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 7de0a7062625..b0dc3249d5cd 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -344,30 +344,39 @@
  * Once we get to a point where the two describe the same thing, we'll
  * merge the definitions. One day.
  */
-#define __HFGRTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51))
+#define __HFGRTR_EL2_RES0	BIT(51)
 #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
-#define __HFGRTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
+#define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
 
-#define __HFGWTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51) |	\
-				 BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
-				 GENMASK(26, 25) | BIT(21) | BIT(18) |	\
+#define __HFGWTR_EL2_RES0	(BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
+				 BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
 				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
-#define __HFGWTR_EL2_MASK	GENMASK(49, 0)
-#define __HFGWTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
+#define __HFGWTR_EL2_MASK	(GENMASK(49, 47) | GENMASK(45, 43) | \
+				 BIT(41) | GENMASK(39, 29) | BIT(27) | \
+				 GENMASK(24, 22) | GENMASK(20, 19) | \
+				 GENMASK(17, 16) | GENMASK(13, 11) | \
+				 GENMASK(8, 3) | GENMASK(1, 0))
+#define __HFGWTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
 
-#define __HFGITR_EL2_RES0	GENMASK(63, 57)
-#define __HFGITR_EL2_MASK	GENMASK(54, 0)
-#define __HFGITR_EL2_nMASK	GENMASK(56, 55)
+#define __HFGITR_EL2_RES0	(BIT(63) | BIT(61))
+#define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
+#define __HFGITR_EL2_nMASK	GENMASK(59, 55)
 
 #define __HDFGRTR_EL2_RES0	(BIT(49) | BIT(42) | GENMASK(39, 38) |	\
 				 GENMASK(21, 20) | BIT(8))
-#define __HDFGRTR_EL2_MASK	~__HDFGRTR_EL2_nMASK
+#define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
+				 GENMASK(41, 40) | GENMASK(37, 22) | \
+				 GENMASK(19, 9) | GENMASK(7, 0))
 #define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
 
 #define __HDFGWTR_EL2_RES0	(BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
 				 BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
 				 BIT(22) | BIT(9) | BIT(6))
-#define __HDFGWTR_EL2_MASK	~__HDFGWTR_EL2_nMASK
+#define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
+				 GENMASK(46, 44) | GENMASK(42, 41) | \
+				 GENMASK(37, 35) | GENMASK(33, 31) | \
+				 GENMASK(29, 23) | GENMASK(21, 10) | \
+				 GENMASK(8, 7) | GENMASK(5, 0))
 #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
 
 #define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
@@ -375,9 +384,9 @@
 #define __HAFGRTR_EL2_nMASK	0UL
 
 /* Similar definitions for HCRX_EL2 */
-#define __HCRX_EL2_RES0		(GENMASK(63, 16) | GENMASK(13, 12))
-#define __HCRX_EL2_MASK		(0)
-#define __HCRX_EL2_nMASK	(GENMASK(15, 14) | GENMASK(4, 0))
+#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
+#define __HCRX_EL2_MASK		(BIT(6))
+#define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
 
 /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
 #define HPFAR_MASK	(~UL(0xf))
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:04:57 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:57 +0000
Subject: [PATCH v2 07/12] KVM: arm64: Add build validation for FGT trap mask values
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-8-tabba@google.com>

These checks help ensure that all the bits are accounted for,
that there hasn't been a transcribing error from the spec nor
from the generated mask values, which will be used in subsequent
patches.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/include/hyp/switch.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 76a3d78b13d9..91d0f73161bd 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -79,6 +79,16 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
 		clr |= ~hfg & __ ## reg ## _nMASK; 			\
 	} while(0)
 
+/*
+ * Validate the fine grain trap masks.
+ * Check that the masks do not overlap and that all bits are accounted for.
+ */
+#define CHECK_FGT_MASKS(reg)							\
+	do {									\
+		BUILD_BUG_ON((__ ## reg ## _MASK) & (__ ## reg ## _nMASK));	\
+		BUILD_BUG_ON(~((__ ## reg ## _RES0) ^ (__ ## reg ## _MASK) ^	\
+			       (__ ## reg ## _nMASK)));				\
+	} while(0)
 
 static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 {
@@ -86,6 +96,14 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 	u64 r_clr = 0, w_clr = 0, r_set = 0, w_set = 0, tmp;
 	u64 r_val, w_val;
 
+	CHECK_FGT_MASKS(HFGRTR_EL2);
+	CHECK_FGT_MASKS(HFGWTR_EL2);
+	CHECK_FGT_MASKS(HFGITR_EL2);
+	CHECK_FGT_MASKS(HDFGRTR_EL2);
+	CHECK_FGT_MASKS(HDFGWTR_EL2);
+	CHECK_FGT_MASKS(HAFGRTR_EL2);
+	CHECK_FGT_MASKS(HCRX_EL2);
+
 	if (!cpus_have_final_cap(ARM64_HAS_FGT))
 		return;
 
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:04:58 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:58 +0000
Subject: [PATCH v2 08/12] KVM: arm64: Use generated FGT RES0 bits instead of
 specifying them
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-9-tabba@google.com>

Now that all FGT fields are accounted for and represented, use
the generated value instead of manually specifying them.

For __HFGWTR_EL2_RES0, however, there is no generated value. Its
fields are subset of HFGRTR_EL2, with the remaining being RES0.
Therefore, add a mask that represents the HFGRTR_EL2 only bits
and define __HFGWTR_EL2_* using those and the __HFGRTR_EL2_*
fields.

No functional change intended.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 34 +++++++++++++++-----------------
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index b0dc3249d5cd..5b634e909d1c 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -344,34 +344,32 @@
  * Once we get to a point where the two describe the same thing, we'll
  * merge the definitions. One day.
  */
-#define __HFGRTR_EL2_RES0	BIT(51)
+#define __HFGRTR_EL2_RES0	HFGxTR_EL2_RES0
 #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
 #define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
 
-#define __HFGWTR_EL2_RES0	(BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
-				 BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
+/*
+ * The HFGWTR bits are a subset of HFGRTR bits. To ensure we don't miss any
+ * future additions, define __HFGWTR* macros relative to __HFGRTR* ones.
+ */
+#define __HFGxTR_READ_ONLY_MASK	(BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
+				 GENMASK(26, 25) | BIT(21) | BIT(18) | \
 				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
-#define __HFGWTR_EL2_MASK	(GENMASK(49, 47) | GENMASK(45, 43) | \
-				 BIT(41) | GENMASK(39, 29) | BIT(27) | \
-				 GENMASK(24, 22) | GENMASK(20, 19) | \
-				 GENMASK(17, 16) | GENMASK(13, 11) | \
-				 GENMASK(8, 3) | GENMASK(1, 0))
-#define __HFGWTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
-
-#define __HFGITR_EL2_RES0	(BIT(63) | BIT(61))
+#define __HFGWTR_EL2_RES0	(__HFGRTR_EL2_RES0 | __HFGxTR_READ_ONLY_MASK)
+#define __HFGWTR_EL2_MASK	(__HFGRTR_EL2_MASK & ~__HFGxTR_READ_ONLY_MASK)
+#define __HFGWTR_EL2_nMASK	(__HFGRTR_EL2_nMASK & ~__HFGxTR_READ_ONLY_MASK)
+
+#define __HFGITR_EL2_RES0	HFGITR_EL2_RES0
 #define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
 #define __HFGITR_EL2_nMASK	GENMASK(59, 55)
 
-#define __HDFGRTR_EL2_RES0	(BIT(49) | BIT(42) | GENMASK(39, 38) |	\
-				 GENMASK(21, 20) | BIT(8))
+#define __HDFGRTR_EL2_RES0	HDFGRTR_EL2_RES0
 #define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
 				 GENMASK(41, 40) | GENMASK(37, 22) | \
 				 GENMASK(19, 9) | GENMASK(7, 0))
 #define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
 
-#define __HDFGWTR_EL2_RES0	(BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
-				 BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
-				 BIT(22) | BIT(9) | BIT(6))
+#define __HDFGWTR_EL2_RES0	HDFGWTR_EL2_RES0
 #define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
 				 GENMASK(46, 44) | GENMASK(42, 41) | \
 				 GENMASK(37, 35) | GENMASK(33, 31) | \
@@ -379,12 +377,12 @@
 				 GENMASK(8, 7) | GENMASK(5, 0))
 #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
 
-#define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
+#define __HAFGRTR_EL2_RES0	HAFGRTR_EL2_RES0
 #define __HAFGRTR_EL2_MASK	(GENMASK(49, 17) | GENMASK(4, 0))
 #define __HAFGRTR_EL2_nMASK	0UL
 
 /* Similar definitions for HCRX_EL2 */
-#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
+#define __HCRX_EL2_RES0         HCRX_EL2_RES0
 #define __HCRX_EL2_MASK		(BIT(6))
 #define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
 
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:04:59 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:04:59 +0000
Subject: [PATCH v2 09/12] KVM: arm64: Generate the HFGWTR-only RES0 bits
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-10-tabba@google.com>

Generate the HFGWTR-only RES0 bits in sysreg. This is done to
consolidate all the bit definitions in one place.

No functional change intended.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 13 +++----------
 arch/arm64/tools/sysreg          | 26 ++++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 5b634e909d1c..02442bc90717 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -348,16 +348,9 @@
 #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
 #define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
 
-/*
- * The HFGWTR bits are a subset of HFGRTR bits. To ensure we don't miss any
- * future additions, define __HFGWTR* macros relative to __HFGRTR* ones.
- */
-#define __HFGxTR_READ_ONLY_MASK	(BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
-				 GENMASK(26, 25) | BIT(21) | BIT(18) | \
-				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
-#define __HFGWTR_EL2_RES0	(__HFGRTR_EL2_RES0 | __HFGxTR_READ_ONLY_MASK)
-#define __HFGWTR_EL2_MASK	(__HFGRTR_EL2_MASK & ~__HFGxTR_READ_ONLY_MASK)
-#define __HFGWTR_EL2_nMASK	(__HFGRTR_EL2_nMASK & ~__HFGxTR_READ_ONLY_MASK)
+#define __HFGWTR_EL2_RES0	(__HFGRTR_EL2_RES0 | HFGWTR_ONLY_EL2_RES0)
+#define __HFGWTR_EL2_MASK	(__HFGRTR_EL2_MASK & ~HFGWTR_ONLY_EL2_RES0)
+#define __HFGWTR_EL2_nMASK	(__HFGRTR_EL2_nMASK & ~HFGWTR_ONLY_EL2_RES0)
 
 #define __HFGITR_EL2_RES0	HFGITR_EL2_RES0
 #define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index e5631f4e62f4..85f8b385fed2 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2093,6 +2093,32 @@ Field	1	AFSR1_EL1
 Field	0	AFSR0_EL1
 EndSysregFields
 
+# HFGWTR_EL2 bits are a subset of those for HFGRTR_EL2.
+# Define RES0 only present in HFGWTR_EL2.
+SysregFields	HFGWTR_ONLY_EL2
+Unkn	63:47
+Res0	46
+Unkn	45:43
+Res0	42
+Unkn	41
+Res0	40
+Unkn	39:29
+Res0	28
+Unkn	27
+Res0	26:25
+Unkn	24:22
+Res0	21
+Unkn	20:19
+Res0	18
+Unkn	17:16
+Res0	15:14
+Unkn	13:11
+Res0	10:9
+Unkn	8:3
+Res0	2
+Unkn	1:0
+EndSysregFields
+
 Sysreg HFGRTR_EL2	3	4	1	1	4
 Fields	HFGxTR_EL2
 EndSysreg
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:05:00 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:05:00 +0000
Subject: [PATCH v2 10/12] KVM: arm64: Define FGT NMASK bits relative to other fields
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-11-tabba@google.com>

Now that RES0 and MASK have full coverage, no speed to manually
encode NMASK. Calculate it relative to the other fields.

No functional change intended.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 02442bc90717..cb01dd18f763 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -346,21 +346,21 @@
  */
 #define __HFGRTR_EL2_RES0	HFGxTR_EL2_RES0
 #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
-#define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
+#define __HFGRTR_EL2_nMASK	~(__HFGRTR_EL2_RES0 | __HFGRTR_EL2_MASK)
 
 #define __HFGWTR_EL2_RES0	(__HFGRTR_EL2_RES0 | HFGWTR_ONLY_EL2_RES0)
 #define __HFGWTR_EL2_MASK	(__HFGRTR_EL2_MASK & ~HFGWTR_ONLY_EL2_RES0)
-#define __HFGWTR_EL2_nMASK	(__HFGRTR_EL2_nMASK & ~HFGWTR_ONLY_EL2_RES0)
+#define __HFGWTR_EL2_nMASK	~(__HFGWTR_EL2_RES0 | __HFGWTR_EL2_MASK)
 
 #define __HFGITR_EL2_RES0	HFGITR_EL2_RES0
 #define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
-#define __HFGITR_EL2_nMASK	GENMASK(59, 55)
+#define __HFGITR_EL2_nMASK	~(__HFGITR_EL2_RES0 | __HFGITR_EL2_MASK)
 
 #define __HDFGRTR_EL2_RES0	HDFGRTR_EL2_RES0
 #define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
 				 GENMASK(41, 40) | GENMASK(37, 22) | \
 				 GENMASK(19, 9) | GENMASK(7, 0))
-#define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
+#define __HDFGRTR_EL2_nMASK	~(__HDFGRTR_EL2_RES0 | __HDFGRTR_EL2_MASK)
 
 #define __HDFGWTR_EL2_RES0	HDFGWTR_EL2_RES0
 #define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
@@ -368,16 +368,16 @@
 				 GENMASK(37, 35) | GENMASK(33, 31) | \
 				 GENMASK(29, 23) | GENMASK(21, 10) | \
 				 GENMASK(8, 7) | GENMASK(5, 0))
-#define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
+#define __HDFGWTR_EL2_nMASK	~(__HDFGWTR_EL2_RES0 | __HDFGWTR_EL2_MASK)
 
 #define __HAFGRTR_EL2_RES0	HAFGRTR_EL2_RES0
 #define __HAFGRTR_EL2_MASK	(GENMASK(49, 17) | GENMASK(4, 0))
-#define __HAFGRTR_EL2_nMASK	0UL
+#define __HAFGRTR_EL2_nMASK	~(__HAFGRTR_EL2_RES0 | __HAFGRTR_EL2_MASK)
 
 /* Similar definitions for HCRX_EL2 */
 #define __HCRX_EL2_RES0         HCRX_EL2_RES0
 #define __HCRX_EL2_MASK		(BIT(6))
-#define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
+#define __HCRX_EL2_nMASK	~(__HCRX_EL2_RES0 | __HCRX_EL2_MASK)
 
 /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
 #define HPFAR_MASK	(~UL(0xf))
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:05:01 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:05:01 +0000
Subject: [PATCH v2 11/12] KVM: arm64: Trap external trace for protected VMs
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-12-tabba@google.com>

pKVM does not support external trace for protected VMs. Trap
external trace, and add the ExtTrcBuff to make it possible to
check for the feature.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++++
 arch/arm64/tools/sysreg        | 5 ++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 9d23a51d7f75..84b5c3f387d8 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -136,6 +136,10 @@ static void pvm_init_traps_aa64dfr0(struct kvm_vcpu *vcpu)
 			cptr_set |= CPTR_EL2_TTA;
 	}
 
+	/* Trap External Trace */
+	if (!FIELD_GET(ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_ExtTrcBuff), feature_ids))
+		mdcr_clear |= MDCR_EL2_E2TB_MASK << MDCR_EL2_E2TB_SHIFT;
+
 	vcpu->arch.mdcr_el2 |= mdcr_set;
 	vcpu->arch.mdcr_el2 &= ~mdcr_clear;
 	vcpu->arch.cptr_el2 |= cptr_set;
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 85f8b385fed2..be857797cc00 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1115,7 +1115,10 @@ Enum	63:60	HPMN0
 	0b0000	UNPREDICTABLE
 	0b0001	DEF
 EndEnum
-Res0	59:56
+UnsignedEnum	59:56	ExtTrcBuff
+	0b0000	NI
+	0b0001	IMP
+EndEnum
 UnsignedEnum	55:52	BRBE
 	0b0000	NI
 	0b0001	IMP
-- 
2.43.0.rc2.451.g8631bc7472-goog



From tabba at google.com  Wed Dec  6 02:05:02 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed,  6 Dec 2023 10:05:02 +0000
Subject: [PATCH v2 12/12] KVM: arm64: Mark CMOW as allowed for protected VMs
In-Reply-To: <20231206100503.564090-1-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
Message-ID: <20231206100503.564090-13-tabba@google.com>

Cache maintenance operations are not trapped for protected VMs,
and shouldn't be. Mark the feature as allowed.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/include/nvhe/fixed_config.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
index e91922daa8ca..e628541585fc 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
@@ -101,6 +101,7 @@
  * - Privileged Access Never
  * - SError interrupt exceptions from speculative reads
  * - Enhanced Translation Synchronization
+ * - Control for cache maintenance permission
  */
 #define PVM_ID_AA64MMFR1_ALLOW (\
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_HAFDBS) | \
@@ -108,7 +109,8 @@
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_HPDS) | \
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_PAN) | \
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_SpecSEI) | \
-	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_ETS) \
+	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_ETS) | \
+	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_CMOW) \
 	)
 
 /*
-- 
2.43.0.rc2.451.g8631bc7472-goog



From magnus.karlsson at gmail.com  Wed Dec  6 02:06:57 2023
From: magnus.karlsson at gmail.com (Magnus Karlsson)
Date: Wed, 6 Dec 2023 11:06:57 +0100
Subject: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC
In-Reply-To: <ZW98UW033wCy9vI-@google.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com> <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
 <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
 <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com>
 <CAKH8qBuXL8bOYtfKKPS8y=KJqouDptyciCjr0wNKVHtNj6BmqA@mail.gmail.com>
 <656f66023f7bd_3dd6422942a@willemb.c.googlers.com.notmuch> <ZW98UW033wCy9vI-@google.com>
Message-ID: <CAJ8uoz3_XqavGt1DyFoQAuKS8Faa1Lc85b2t+whc-f6GN1Pvzw@mail.gmail.com>

On Tue, 5 Dec 2023 at 20:39, Stanislav Fomichev <sdf at google.com> wrote:
>
> On 12/05, Willem de Bruijn wrote:
> > Stanislav Fomichev wrote:
> > > On Tue, Dec 5, 2023 at 7:34?AM Florian Bezdeka
> > > <florian.bezdeka at siemens.com> wrote:
> > > >
> > > > On Tue, 2023-12-05 at 15:25 +0000, Song, Yoong Siang wrote:
> > > > > On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote:
> > > > > > Jesper Dangaard Brouer wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 12/3/23 17:51, Song Yoong Siang wrote:
> > > > > > > > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > > > > > > > copy via XDP Tx metadata framework.
> > > > > > > >
> > > > > > > > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > > > > > > > ---
> > > > > > > >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> > > > > > >
> > > > > > > As requested before, I think we need to see another driver implementing
> > > > > > > this.
> > > > > > >
> > > > > > > I propose driver igc and chip i225.
> > > > >
> > > > > Sure. I will include igc patches in next version.
> > > > >
> > > > > > >
> > > > > > > The interesting thing for me is to see how the LaunchTime max 1 second
> > > > > > > into the future[1] is handled code wise. One suggestion is to add a
> > > > > > > section to Documentation/networking/xsk-tx-metadata.rst per driver that
> > > > > > > mentions/documents these different hardware limitations.  It is natural
> > > > > > > that different types of hardware have limitations.  This is a close-to
> > > > > > > hardware-level abstraction/API, and IMHO as long as we document the
> > > > > > > limitations we can expose this API without too many limitations for more
> > > > > > > capable hardware.
> > > > >
> > > > > Sure. I will try to add hardware limitations in documentation.
> > > > >
> > > > > >
> > > > > > I would assume that the kfunc will fail when a value is passed that
> > > > > > cannot be programmed.
> > > > > >
> > > > >
> > > > > In current design, the xsk_tx_metadata_request() dint got return value.
> > > > > So user won't know if their request is fail.
> > > > > It is complex to inform user which request is failing.
> > > > > Therefore, IMHO, it is good that we let driver handle the error silently.
> > > > >
> > > >
> > > > If the programmed value is invalid, the packet will be "dropped" / will
> > > > never make it to the wire, right?
> >
> > Programmable behavior is to either drop or cap to some boundary
> > value, such as the farthest programmable time in the future: the
> > horizon. In fq:
> >
> >                 /* Check if packet timestamp is too far in the future. */
> >                 if (fq_packet_beyond_horizon(skb, q, now)) {
> >                         if (q->horizon_drop) {
> >                                         q->stat_horizon_drops++;
> >                                         return qdisc_drop(skb, sch, to_free);
> >                         }
> >                         q->stat_horizon_caps++;
> >                         skb->tstamp = now + q->horizon;
> >                 }
> >                 fq_skb_cb(skb)->time_to_send = skb->tstamp;
> >
> > Drop is the more obviously correct mode.
> >
> > Programming with a clock source that the driver does not support will
> > then be a persistent failure.
> >
> > Preferably, this driver capability can be queried beforehand (rather
> > than only through reading error counters afterwards).
> >
> > Perhaps it should not be a driver task to convert from possibly
> > multiple clock sources to the device native clock. Right now, we do
> > use per-device timecounters for this, implemented in the driver.
> >
> > As for which clocks are relevant. For PTP, I suppose the device PHC,
> > converted to nsec. For pacing offload, TCP uses CLOCK_MONOTONIC.
>
> Do we need to expose some generic netdev netlink apis to query/adjust
> nic clock sources (or maybe there is something existing already)?
> Then the userspace can be responsible for syncing/converting the
> timestamps to the internal nic clocks. +1 to trying to avoid doing
> this in the drivers.
>
> > > > That is clearly a situation that the user should be informed about. For
> > > > RT systems this normally means that something is really wrong regarding
> > > > timing / cycle overflow. Such systems have to react on that situation.
> > >
> > > In general, af_xdp is a bit lacking in this 'notify the user that they
> > > somehow messed up' area :-(
> > > For example, pushing a tx descriptor with a wrong addr/len in zc mode
> > > will not give any visible signal back (besides driver potentially
> > > spilling something into dmesg as it was in the mlx case).
> > > We can probably start with having some counters for these events?
> >
> > This is because the AF_XDP completion queue descriptor format is only
> > a u64 address?
>
> Yeah. XDP_COPY mode has the descriptor validation which is exported via
> recvmsg errno, but zerocopy path seems to be too deep in the stack
> to report something back. And there is no place, as you mention,
> in the completion ring to report the status.
>
> > Could error conditions be reported on tx completion in the metadata,
> > using xsk_tx_metadata_complete?
>
> That would be one way to do it, yes. But then the error reporting depends
> on the metadata opt-in. Having a separate ring to export the errors,
> or having a v2 tx-completions layout with extra 'status' field would also
> work.

There are error counters for the non-metadata and offloading cases
above that can be retrieved with the XDP_STATISTICS getsockopt(). From
if_xdp.h:

struct xdp_statistics {
        __u64 rx_dropped; /* Dropped for other reasons */
        __u64 rx_invalid_descs; /* Dropped due to invalid descriptor */
        __u64 tx_invalid_descs; /* Dropped due to invalid descriptor */
        __u64 rx_ring_full; /* Dropped due to rx ring being full */
        __u64 rx_fill_ring_empty_descs; /* Failed to retrieve item
from fill ring */
        __u64 tx_ring_empty_descs; /* Failed to retrieve item from tx ring */
};

Albeit, these are aggregate statistics and do not say anything about
which packet that caused it. Works well for things that are
programming bugs that should not occur (such as rx_invalid_descs and
tx_invalid_descs) and requires the programmer to debug and fix his or
her program, but it does not work for requests that might fail even
though the program is correct and need to be handled on a packet by
packet basis. So something needs to be added for that as you both say.

Would prefer if we could avoid a v2 completion descriptor format or
another ring that needs to be checked all the time, so if we could
live with providing the error status in the metadata field of the
packet at completion time, that would be good. Though having the error
status in the completion ring would be faster as that cache line is
hot, while the metadata section of the packet is likely not at
completion time. So that speaks for a v2 completion ring format. Just
thinking out loud here.

> But this seems like something that should be handled separately? Because
> we'd have to teach all existing zc drivers to report those errors back
> instead of dropping these descriptors..
>


From ryan.roberts at arm.com  Wed Dec  6 02:08:00 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 6 Dec 2023 10:08:00 +0000
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <b8f5a47a-af1e-44ed-a89b-460d0be56d2c@huawei.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <b8f5a47a-af1e-44ed-a89b-460d0be56d2c@huawei.com>
Message-ID: <82068e6a-937b-43db-8496-76fdf3158080@arm.com>

On 05/12/2023 14:19, Kefeng Wang wrote:
> 
> 
> On 2023/12/4 18:20, Ryan Roberts wrote:
>> Hi All,
>>
>> A new week, a new version, a new name... This is v8 of a series to implement
>> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
>> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
>> this fares better.
>>
>> The objective of this is to improve performance by allocating larger chunks of
>> memory during anonymous page faults:
>>
>> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>> ??? pages, there are efficiency savings to be had; fewer page faults, batched PTE
>> ??? and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>> ??? overhead. This should benefit all architectures.
>> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>> ??? advantage of HW TLB compression techniques. A reduction in TLB pressure
>> ??? speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>> ??? TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
>>
>> This version changes the name and tidies up some of the kernel code and test
>> code, based on feedback against v7 (see change log for details).
>>
>> By default, the existing behaviour (and performance) is maintained. The user
>> must explicitly enable multi-size THP to see the performance benefit. This is
>> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
>> David for the suggestion)! This interface is inspired by the existing
>> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
>> compatibility with the existing PMD-size THP interface, and provides a base for
>> future extensibility. See [8] for detailed discussion of the interface.
>>
>> This series is based on mm-unstable (715b67adf4c8).
>>
>>
>> Prerequisites
>> =============
>>
>> Some work items identified as being prerequisites are listed on page 3 at [9].
>> The summary is:
>>
>> | item????????????????????????? | status????????????????? |
>> |:------------------------------|:------------------------|
>> | mlock???????????????????????? | In mainline (v6.7)????? |
>> | madvise?????????????????????? | In mainline (v6.6)????? |
>> | compaction??????????????????? | v1 posted [10]????????? |
>> | numa balancing??????????????? | Investigated: see below |
>> | user-triggered page migration | In mainline (v6.7)????? |
>> | khugepaged collapse?????????? | In mainline (NOP)?????? |
>>
>> On NUMA balancing, which currently ignores any PTE-mapped THPs it encounters,
>> John Hubbard has investigated this and concluded that it is A) not clear at the
>> moment what a better policy might be for PTE-mapped THP and B) questions whether
>> this should really be considered a prerequisite given no regression is caused
>> for the default "multi-size THP disabled" case, and there is no correctness
>> issue when it is enabled - its just a potential for non-optimal performance.
>>
>> If there are no disagreements about removing numa balancing from the list (none
>> were raised when I first posted this comment against v7), then that just leaves
>> compaction which is in review on list at the moment.
>>
>> I really would like to get this series (and its remaining comapction
>> prerequisite) in for v6.8. I accept that it may be a bit optimistic at this
>> point, but lets see where we get to with review?
>>
>>
>> Testing
>> =======
>>
>> The series includes patches for mm selftests to enlighten the cow and khugepaged
>> tests to explicitly test with multi-size THP, in the same way that PMD-sized
>> THP is tested. The new tests all pass, and no regressions are observed in the mm
>> selftest suite. I've also run my usual kernel compilation and java script
>> benchmarks without any issues.
>>
>> Refer to my performance numbers posted with v6 [6]. (These are for multi-size
>> THP only - they do not include the arm64 contpte follow-on series).
>>
>> John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
>> some workloads at [11]. (Observed using v6 of this series as well as the arm64
>> contpte series).
>>
>> Kefeng Wang at Huawei has also indicated he sees improvements at [12] although
>> there are some latency regressions also.
> 
> Hi Ryan,
> 
> Here is some test results based on v6.7-rc1 +
> [PATCH v7 00/10] Small-sized THP for anonymous memory +
> [PATCH v2 00/14] Transparent Contiguous PTEs for User Mappings
> 
> case1: basepage 64K
> case2: basepage 4K + thp=64k + PAGE_ALLOC_COSTLY_ORDER = 3
> case3: basepage 4K + thp=64k + PAGE_ALLOC_COSTLY_ORDER = 4

Thanks for sharing these results. With the exception of a few outliers, It looks
like the ~rough conclusion is that bandwidth improves, but not as much as 64K
base pages, and latency regresses, but also not as much as 64K base pages?

I expect that over time, as we add more optimizations, we will get bandwidth
closer to 64K base pages; one crucial one is getting executable file-backed
memory into contpte mappings, for example.

It's probably not time to switch PAGE_ALLOC_COSTLY_ORDER quite yet; but
something to keep an eye on and consider down the road?

Thanks,
Ryan

> 
> The results is compared with basepage 4K on Kunpeng920.
> 
> Note,
> - The test based on ext4 filesystem and THP=2M is disabled.
> - The results were not analyzed, it is for reference only,
> ? as some values of test items are not consistent.
> 
> 1) Unixbench 1core
> Index_Values_1core?????????????????????? case1?????? case2??? case3
> Dhrystone_2_using_register_variables???? 0.28%????? 0.39%???? 0.17%
> Double-Precision_Whetstone????????????? -0.01%????? 0.00%???? 0.00%
> Execl_Throughput??????????????????????? *21.13%*??? 2.16%???? 3.01%
> File_Copy_1024_bufsize_2000_maxblocks?? -0.51%???? *8.33%*?? *8.76%*
> File_Copy_256_bufsize_500_maxblocks????? 0.78%???? *11.89%*? *10.85%*
> File_Copy_4096_bufsize_8000_maxblocks??? 7.42%????? 7.27%??? *10.66%*
> Pipe_Throughput???????????????????????? -0.24%???? *6.82%*?? *5.08%*
> Pipe-based_Context_Switching???????????? 1.38%???? *13.49%*? *9.91%*
> Process_Creation??????????????????????? *32.46%*??? 4.30%??? *8.54%*
> Shell_Scripts_(1_concurrent)??????????? *31.67%*??? 1.92%???? 2.60%
> Shell_Scripts_(8_concurrent)??????????? *40.59%*??? 1.30%??? *5.29%*
> System_Call_Overhead???????????????????? 3.92%???? *8.13%???? 2.96%
> 
> System_Benchmarks_Index_Score?????????? 10.66%????? 5.39%???? 5.58%
> 
> For 1core,
> - case1 wins on Execl_Throughput/Process_Creation/Shell_Scripts
> ? a lot, and score higher 10.66% vs basepage 4K.
> - case2/3 wins on File_Copy/Pipe and score higher 5%+ than basepage 4K,
> ? also case3 looks better on Shell_Scripts_(8_concurrent) than case2.
> 
> 2) Unixbench 128core
> Index_Values_128core??????????????????? case1???? case2???? case3
> Dhrystone_2_using_register_variables??? 2.07%??? -0.03%??? -0.11%
> Double-Precision_Whetstone???????????? -0.03%???? 0.00%??? 0.00%
> Execl_Throughput?????????????????????? *39.28%*? -4.23%??? 1.93%
> File_Copy_1024_bufsize_2000_maxblocks?? 5.46%???? 1.30%??? 4.20%
> File_Copy_256_bufsize_500_maxblocks??? -8.89%??? *6.56%?? *5.02%*
> File_Copy_4096_bufsize_8000_maxblocks?? 3.43%?? *-5.46%*?? 0.56%
> Pipe_Throughput???????????????????????? 3.80%??? *7.69%?? *7.80%*
> Pipe-based_Context_Switching?????????? *7.62%*??? 0.95%??? 4.69%
> Process_Creation?????????????????????? *28.11%*? -2.79%??? 2.40%
> Shell_Scripts_(1_concurrent)?????????? *39.68%*?? 1.86%?? *5.30%*
> Shell_Scripts_(8_concurrent)?????????? *41.35%*?? 2.49%?? *7.16%*
> System_Call_Overhead?????????????????? -1.55%??? -0.04%?? *8.23%*
> 
> System_Benchmarks_Index_Score????????? 12.08%???? 0.63%??? 3.88%
> 
> For 128core,
> - case1 wins on Execl_Throughput/Process_Creation/Shell_Scripts
> ? a lot, also good at Pipe-based_Context_Switching, and score higher
> ? 12.08% vs basepage 4K.
> - case2/case3 wins on File_Copy_256/Pipe_Throughput, but case2 is
> ? not better than basepage 4K, case3 wins 3.88%.
> 
> 3) Lmbench Processor_processes
> Processor_Processes??? case1????? case2????? case3
> null_call????????????? 1.76%????? 0.40%???? 0.65%
> null_io?????????????? -0.76%???? -0.38%??? -0.23%
> stat???????????????? *-16.09%*? *-12.49%*?? 4.22%
> open_close??????????? -2.69%????? 4.51%???? 3.21%
> slct_TCP????????????? -0.56%????? 0.00%??? -0.44%
> sig_inst????????????? -1.54%????? 0.73%???? 0.70%
> sig_hndl????????????? -2.85%????? 0.01%???? 1.85%
> fork_proc??????????? *23.31%*???? 8.77%??? -5.42%
> exec_proc??????????? *13.22%*??? -0.30%???? 1.09%
> sh_proc????????????? *14.04%*??? -0.10%???? 1.09%
> 
> - case1 is much better than basepage 4K, same as Unixbench test,
> ? case2 is better on fork_proc, but case3 is worse
> - note: the variance of fork/exec/sh is bigger than others
> 
> 4) Lmbench Context_switching_ctxsw
> Context_switching_ctxsw? case1???? case2???????? case3
> 2p/0K?????????????????? -12.16%??? -5.29%?????? -1.86%
> 2p/16K????????????????? -11.26%??? -3.71%?????? -4.53%
> 2p/64K????????????????? -2.60%????? 3.84%?????? -1.98%
> 8p/16K????????????????? -7.56%???? -1.21%?????? -0.88%
> 8p/64K?????????????????? 5.10%????? 4.88%??????? 1.19%
> 16p/16K???????????????? -5.81%???? -2.44%?????? -3.84%
> 16p/64K????????????????? 4.29%???? -1.94%?????? -2.50%
> - case1/2/3 worse than basepage 4K and case1 is the worst.
> 
> 4) Lmbench Local_latencies
> Local_latencies????? case1????? case2???? case3
> Pipe??????????????? -9.23%????? 0.58%??? -4.34%
> AF_UNIX???????????? -5.34%???? -1.76%???? 3.03%
> UDP???????????????? -6.70%???? -5.96%??? -9.81%
> TCP???????????????? -7.95%???? -7.58%??? -5.63%
> TCP_conn??????????? -213.99%?? -227.78%? -659.67%
> - TCP_conn is very unreliable, ignore it
> - case1/2/3 slower than basepage 4K
> 
> 5) Lmbench File_&_VM_latencies
> File_&_VM_latencies??? case1???? case2??????? case3
> 10K_File_Create??????? 2.60%??? -0.52%???????? 2.66%
> 10K_File_Delete?????? -2.91%??? -5.20%??????? -2.11%
> 10K_File_Create?????? 10.23%???? 1.18%???????? 0.12%
> 10K_File_Delete????? -17.76%??? -2.97%??????? -1.49%
> Mmap_Latency???????? *63.05%*??? 2.57%??????? -0.96%
> Prot_Fault??????????? 10.41%??? -3.21%?????? *-19.11%*
> Page_Fault????????? *-132.01%*?? 2.35%??????? -0.79%
> 100fd_selct????????? -1.20%????? 0.10%???????? 0.31%
> - case1 is very good at Mmap_Latency and not good at Page_fault
> - case2/3 slower on Prot_Faul/10K_FILE_Delete vs basepage 4k,
> ? the rest doesn't look much different.
> 
> 6) Lmbench Local_bandwidths
> Local_bandwidths??? case1?? case2?????? case3
> Pipe?????????????? 265.22%?? 15.44%???? 11.33%
> AF_UNIX??????????? 13.41%?? -2.66%????? 2.63%
> TCP?????????????? -1.30%???? 25.90%???? 2.48%
> File_reread??????? 14.79%??? 31.52%??? -14.16%
> Mmap_reread??????? 27.47%??? 49.00%??? -0.11%
> Bcopy(libc)??????? 2.58%???? 2.45%????? 2.46%
> Bcopy(hand)??????? 25.78%??? 22.56%???? 22.68%
> Mem_read?????????? 38.26%??? 36.80%???? 36.49%
> Mem_write????????? 10.93%??? 3.44%????? 3.12%
> 
> - case1 is very good at bandwidth, case2 is better than basepage 4k
> ? but lower than case1, case3 is bad at File_reread
> 
> 7)Lmbench Memory_latencies
> Memory_latencies??? case1???? case2???? case3
> L1_$??????????????? 0.02%???? 0.00%??? -0.03%
> L2_$?????????????? -1.56%??? -2.65%??? -1.25%
> Main_mem?????????? 50.82%???? 32.51%??? 33.47%
> Rand_mem?????????? 15.29%??? -8.79%??? -8.80%
> 
> - case1 also good at Main/Rand mem access latencies,
> - case2/case3 is better at Main_mem, but worse at Rand_mem.
> 
> Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
> 
> 
> 
> 
> 
> 
> 



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 02:08:00 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Wed, 6 Dec 2023 12:08:00 +0200
Subject: [PATCH 4/4] media: rkisp1: Fix IRQ disable race issue
In-Reply-To: <20231205121355.GE17394@pendragon.ideasonboard.com>
References: <20231205-rkisp-irq-fix-v1-0-f4045c74ba45@ideasonboard.com>
 <20231205-rkisp-irq-fix-v1-4-f4045c74ba45@ideasonboard.com>
 <20231205121355.GE17394@pendragon.ideasonboard.com>
Message-ID: <c7117713-bc98-459c-a475-2ec838215cd9@ideasonboard.com>

On 05/12/2023 14:13, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Tue, Dec 05, 2023 at 10:09:35AM +0200, Tomi Valkeinen wrote:
>> In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
>> interrupts and then apparently assumes that the interrupt handler won't
>> be running, and proceeds in the stop procedure. This is not the case, as
>> the interrupt handler can already be running, which would lead to the
>> ISP being disabled while the interrupt handler handling a captured
>> frame.
>>
>> It is not clear to me if this problem causes a real issue, but shutting
>> down the ISP while an interrupt handler is running sounds rather bad.
> 
> Agreed.
> 
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>> ---
>>   drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c | 14 +++++++++++++-
>>   drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 20 +++++++++++++++++---
>>   2 files changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>> index f6b54654b435..f0cef766fc0c 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>> @@ -125,8 +125,20 @@ static void rkisp1_csi_disable(struct rkisp1_csi *csi)
>>   	struct rkisp1_device *rkisp1 = csi->rkisp1;
>>   	u32 val;
>>   
>> -	/* Mask and clear interrupts. */
>> +	/* Mask MIPI interrupts. */
>>   	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_IMSC, 0);
>> +
>> +	/* Flush posted writes */
>> +	rkisp1_read(rkisp1, RKISP1_CIF_MIPI_IMSC);
>> +
>> +	/*
>> +	 * Wait until the IRQ handler has ended. The IRQ handler may get called
>> +	 * even after this, but it will return immediately as the MIPI
>> +	 * interrupts have been masked.
>> +	 */
> 
> This comment will need to be updated if patch 3/4 gets replaced by a
> patch that drops IRQF_SHARED.

I don't think it needs an update, as the irq handling is divided into 
multiple parts. The handler here may get called due to a MI or ISP 
interrupt, and vice versa.

  Tomi

> 
>> +	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MIPI]);
>> +
>> +	/* Clear MIPI interrupt status */
>>   	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_ICR, ~0);
>>   
>>   	val = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_CTRL);
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>> index d6b8786661ad..a6dd497c884c 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>> @@ -364,11 +364,25 @@ static void rkisp1_isp_stop(struct rkisp1_isp *isp)
>>   	 * ISP(mi) stop in mi frame end -> Stop ISP(mipi) ->
>>   	 * Stop ISP(isp) ->wait for ISP isp off
>>   	 */
>> -	/* stop and clear MI and ISP interrupts */
>> -	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
>> -	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
>>   
>> +	/* Mask MI and ISP interrupts */
>> +	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
>>   	rkisp1_write(rkisp1, RKISP1_CIF_MI_IMSC, 0);
>> +
>> +	/* Flush posted writes */
>> +	rkisp1_read(rkisp1, RKISP1_CIF_MI_IMSC);
>> +
>> +	/*
>> +	 * Wait until the IRQ handler has ended. The IRQ handler may get called
>> +	 * even after this, but it will return immediately as the MI and ISP
>> +	 * interrupts have been masked.
>> +	 */
> 
> Same here.
> 
>> +	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_ISP]);
>> +	if (rkisp1->irqs[RKISP1_IRQ_ISP] != rkisp1->irqs[RKISP1_IRQ_MI])
>> +		synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MI]);
> 
> It would be nice if we could avoid the double synchronize_irq() for
> platforms where RKISP1_IRQ_MIPI and RKISP1_IRQ_ISP are identical, but I
> understand that would be difficult.
> 
>> +
>> +	/* Clear MI and ISP interrupt status */
>> +	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
>>   	rkisp1_write(rkisp1, RKISP1_CIF_MI_ICR, ~0);
>>   
>>   	/* stop ISP */
> 



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 02:12:27 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Wed, 06 Dec 2023 12:12:27 +0200
Subject: [PATCH v2 0/4] media: rkisp1: Fix IRQ related issues
Message-ID: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>

These fix a few IRQ related issues I noticed when testing i.MX8MP. These
are based on Paul's recently sent "[PATCH v4 00/11] media: rkisp1: Add
support for i.MX8MP" series, but could also be rebased on top of
mainline if needed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
Changes in v2:
- New patch: "media: rkisp1: Drop IRQF_SHARED"
- Update "media: rkisp1: Fix IRQ handler return values" according to
  Laurent's comment.
- Drop "media: rkisp1: Fix IRQ handling due to shared interrupts"
- Update description for "media: rkisp1: Fix IRQ disable race issue"
- Link to v1: https://lore.kernel.org/r/20231205-rkisp-irq-fix-v1-0-f4045c74ba45 at ideasonboard.com

---
Tomi Valkeinen (4):
      media: rkisp1: Drop IRQF_SHARED
      media: rkisp1: Fix IRQ handler return values
      media: rkisp1: Store IRQ lines
      media: rkisp1: Fix IRQ disable race issue

 .../media/platform/rockchip/rkisp1/rkisp1-common.h | 11 ++++++-
 .../media/platform/rockchip/rkisp1/rkisp1-csi.c    | 14 +++++++-
 .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 37 ++++++++++++++++------
 .../media/platform/rockchip/rkisp1/rkisp1-isp.c    | 20 ++++++++++--
 4 files changed, 67 insertions(+), 15 deletions(-)
---
base-commit: dd19f89b915c203d49e3b23ca02446d4fb05d955
change-id: 20231205-rkisp-irq-fix-e123a8a6732f

Best regards,
-- 
Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 02:12:29 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Wed, 06 Dec 2023 12:12:29 +0200
Subject: [PATCH v2 2/4] media: rkisp1: Fix IRQ handler return values
In-Reply-To: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
References: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
Message-ID: <20231206-rkisp-irq-fix-v2-2-6ba4185eeb1f@ideasonboard.com>

The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an
irqreturn_t value, but rkisp1_isr() ignores those values and always
returns IRQ_HANDLED.

Fix this by collecting the return values, and returning IRQ_HANDLED or
IRQ_NONE as appropriate.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index d4950294b7b9..030eb8c79546 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -444,17 +444,25 @@ static int rkisp1_entities_register(struct rkisp1_device *rkisp1)
 
 static irqreturn_t rkisp1_isr(int irq, void *ctx)
 {
+	irqreturn_t ret = IRQ_NONE;
+
 	/*
 	 * Call rkisp1_capture_isr() first to handle the frame that
 	 * potentially completed using the current frame_sequence number before
 	 * it is potentially incremented by rkisp1_isp_isr() in the vertical
 	 * sync.
 	 */
-	rkisp1_capture_isr(irq, ctx);
-	rkisp1_isp_isr(irq, ctx);
-	rkisp1_csi_isr(irq, ctx);
 
-	return IRQ_HANDLED;
+	if (rkisp1_capture_isr(irq, ctx) == IRQ_HANDLED)
+		ret = IRQ_HANDLED;
+
+	if (rkisp1_isp_isr(irq, ctx) == IRQ_HANDLED)
+		ret = IRQ_HANDLED;
+
+	if (rkisp1_csi_isr(irq, ctx) == IRQ_HANDLED)
+		ret = IRQ_HANDLED;
+
+	return ret;
 }
 
 static const char * const px30_isp_clks[] = {

-- 
2.34.1



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 02:12:30 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Wed, 06 Dec 2023 12:12:30 +0200
Subject: [PATCH v2 3/4] media: rkisp1: Store IRQ lines
In-Reply-To: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
References: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
Message-ID: <20231206-rkisp-irq-fix-v2-3-6ba4185eeb1f@ideasonboard.com>

Store the IRQ lines used by the driver for easy access. These are needed
in future patches which fix IRQ race issues.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 .../media/platform/rockchip/rkisp1/rkisp1-common.h    | 11 ++++++++++-
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c   | 19 ++++++++++++++-----
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
index 960ab89c659b..ec28907d978e 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
@@ -62,6 +62,14 @@ struct regmap;
 						 RKISP1_CIF_ISP_EXP_END |	\
 						 RKISP1_CIF_ISP_HIST_MEASURE_RDY)
 
+/* IRQ lines */
+enum rkisp1_irq_line {
+	RKISP1_IRQ_ISP = 0,
+	RKISP1_IRQ_MI,
+	RKISP1_IRQ_MIPI,
+	RKISP1_NUM_IRQS,
+};
+
 /* enum for the resizer pads */
 enum rkisp1_rsz_pad {
 	RKISP1_RSZ_PAD_SINK,
@@ -437,7 +445,6 @@ struct rkisp1_debug {
  * struct rkisp1_device - ISP platform device
  *
  * @base_addr:	   base register address
- * @irq:	   the irq number
  * @dev:	   a pointer to the struct device
  * @clk_size:	   number of clocks
  * @clks:	   array of clocks
@@ -457,6 +464,7 @@ struct rkisp1_debug {
  * @stream_lock:   serializes {start/stop}_streaming callbacks between the capture devices.
  * @debug:	   debug params to be exposed on debugfs
  * @info:	   version-specific ISP information
+ * @irqs:          IRQ line numbers
  */
 struct rkisp1_device {
 	void __iomem *base_addr;
@@ -479,6 +487,7 @@ struct rkisp1_device {
 	struct mutex stream_lock; /* serialize {start/stop}_streaming cb between capture devices */
 	struct rkisp1_debug debug;
 	const struct rkisp1_info *info;
+	int irqs[RKISP1_NUM_IRQS];
 };
 
 /*
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index 030eb8c79546..492ff5e6770d 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -115,6 +115,7 @@
 struct rkisp1_isr_data {
 	const char *name;
 	irqreturn_t (*isr)(int irq, void *ctx);
+	u32 line_mask;
 };
 
 /* ----------------------------------------------------------------------------
@@ -473,9 +474,9 @@ static const char * const px30_isp_clks[] = {
 };
 
 static const struct rkisp1_isr_data px30_isp_isrs[] = {
-	{ "isp", rkisp1_isp_isr },
-	{ "mi", rkisp1_capture_isr },
-	{ "mipi", rkisp1_csi_isr },
+	{ "isp", rkisp1_isp_isr, BIT(RKISP1_IRQ_ISP) },
+	{ "mi", rkisp1_capture_isr, BIT(RKISP1_IRQ_MI) },
+	{ "mipi", rkisp1_csi_isr, BIT(RKISP1_IRQ_MIPI) },
 };
 
 static const struct rkisp1_info px30_isp_info = {
@@ -496,7 +497,7 @@ static const char * const rk3399_isp_clks[] = {
 };
 
 static const struct rkisp1_isr_data rk3399_isp_isrs[] = {
-	{ NULL, rkisp1_isr },
+	{ NULL, rkisp1_isr, BIT(RKISP1_IRQ_ISP) | BIT(RKISP1_IRQ_MI) | BIT(RKISP1_IRQ_MIPI) },
 };
 
 static const struct rkisp1_info rk3399_isp_info = {
@@ -517,7 +518,7 @@ static const char * const imx8mp_isp_clks[] = {
 };
 
 static const struct rkisp1_isr_data imx8mp_isp_isrs[] = {
-	{ NULL, rkisp1_isr },
+	{ NULL, rkisp1_isr, BIT(RKISP1_IRQ_ISP) | BIT(RKISP1_IRQ_MI) | BIT(RKISP1_IRQ_MIPI) },
 };
 
 static const struct rkisp1_info imx8mp_isp_info = {
@@ -574,6 +575,9 @@ static int rkisp1_probe(struct platform_device *pdev)
 	if (IS_ERR(rkisp1->base_addr))
 		return PTR_ERR(rkisp1->base_addr);
 
+	for (unsigned int il = 0; il < RKISP1_NUM_IRQS; ++il)
+		rkisp1->irqs[il] = -1;
+
 	for (i = 0; i < info->isr_size; i++) {
 		irq = info->isrs[i].name
 		    ? platform_get_irq_byname(pdev, info->isrs[i].name)
@@ -581,6 +585,11 @@ static int rkisp1_probe(struct platform_device *pdev)
 		if (irq < 0)
 			return irq;
 
+		for (unsigned int il = 0; il < RKISP1_NUM_IRQS; ++il) {
+			if (info->isrs[i].line_mask & BIT(il))
+				rkisp1->irqs[il] = irq;
+		}
+
 		ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0,
 				       dev_driver_string(dev), dev);
 		if (ret) {

-- 
2.34.1



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 02:12:31 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Wed, 06 Dec 2023 12:12:31 +0200
Subject: [PATCH v2 4/4] media: rkisp1: Fix IRQ disable race issue
In-Reply-To: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
References: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
Message-ID: <20231206-rkisp-irq-fix-v2-4-6ba4185eeb1f@ideasonboard.com>

In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
interrupts and then apparently assumes that the interrupt handler won't
be running, and proceeds in the stop procedure. This is not the case, as
the interrupt handler can already be running, which would lead to the
ISP being disabled while the interrupt handler handling a captured
frame.

This brings up two issues: 1) the ISP could be powered off while the
interrupt handler is still running and accessing registers, leading to
board lockup, and 2) the interrupt handler code and the code that
disables the streaming might do things that conflict.

It is not clear to me if 2) causes a real issue, but 1) can be seen with
a suitable delay (or printk in my case) in the interrupt handler,
leading to board lockup.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c | 14 +++++++++++++-
 drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 20 +++++++++++++++++---
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
index 47f4353a1784..0bab3303f2e4 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
@@ -125,8 +125,20 @@ static void rkisp1_csi_disable(struct rkisp1_csi *csi)
 	struct rkisp1_device *rkisp1 = csi->rkisp1;
 	u32 val;
 
-	/* Mask and clear interrupts. */
+	/* Mask MIPI interrupts. */
 	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_IMSC, 0);
+
+	/* Flush posted writes */
+	rkisp1_read(rkisp1, RKISP1_CIF_MIPI_IMSC);
+
+	/*
+	 * Wait until the IRQ handler has ended. The IRQ handler may get called
+	 * even after this, but it will return immediately as the MIPI
+	 * interrupts have been masked.
+	 */
+	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MIPI]);
+
+	/* Clear MIPI interrupt status */
 	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_ICR, ~0);
 
 	val = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_CTRL);
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
index dafbfd230542..33b5a714d117 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
@@ -364,11 +364,25 @@ static void rkisp1_isp_stop(struct rkisp1_isp *isp)
 	 * ISP(mi) stop in mi frame end -> Stop ISP(mipi) ->
 	 * Stop ISP(isp) ->wait for ISP isp off
 	 */
-	/* stop and clear MI and ISP interrupts */
-	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
-	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
 
+	/* Mask MI and ISP interrupts */
+	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
 	rkisp1_write(rkisp1, RKISP1_CIF_MI_IMSC, 0);
+
+	/* Flush posted writes */
+	rkisp1_read(rkisp1, RKISP1_CIF_MI_IMSC);
+
+	/*
+	 * Wait until the IRQ handler has ended. The IRQ handler may get called
+	 * even after this, but it will return immediately as the MI and ISP
+	 * interrupts have been masked.
+	 */
+	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_ISP]);
+	if (rkisp1->irqs[RKISP1_IRQ_ISP] != rkisp1->irqs[RKISP1_IRQ_MI])
+		synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MI]);
+
+	/* Clear MI and ISP interrupt status */
+	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
 	rkisp1_write(rkisp1, RKISP1_CIF_MI_ICR, ~0);
 
 	/* stop ISP */

-- 
2.34.1



From ryan.roberts at arm.com  Wed Dec  6 02:13:21 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 6 Dec 2023 10:13:21 +0000
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <8d5fdb17-c670-4814-8f48-4b90062668fc@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <8d5fdb17-c670-4814-8f48-4b90062668fc@redhat.com>
Message-ID: <f65baa0c-3f5a-45ad-80dd-c240fe166877@arm.com>

On 05/12/2023 17:21, David Hildenbrand wrote:
> On 04.12.23 11:20, Ryan Roberts wrote:
>> Hi All,
>>
>> A new week, a new version, a new name... This is v8 of a series to implement
>> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
>> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
>> this fares better.
>>
>> The objective of this is to improve performance by allocating larger chunks of
>> memory during anonymous page faults:
>>
>> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>> ??? pages, there are efficiency savings to be had; fewer page faults, batched PTE
>> ??? and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>> ??? overhead. This should benefit all architectures.
>> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>> ??? advantage of HW TLB compression techniques. A reduction in TLB pressure
>> ??? speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>> ??? TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
>>
>> This version changes the name and tidies up some of the kernel code and test
>> code, based on feedback against v7 (see change log for details).
>>
>> By default, the existing behaviour (and performance) is maintained. The user
>> must explicitly enable multi-size THP to see the performance benefit. This is
>> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
>> David for the suggestion)! This interface is inspired by the existing
>> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
>> compatibility with the existing PMD-size THP interface, and provides a base for
>> future extensibility. See [8] for detailed discussion of the interface.
>>
>> This series is based on mm-unstable (715b67adf4c8).
> 
> I took a look at the core pieces. Some things might want some smaller tweaks,
> but nothing that should stop this from having fun in mm-unstable, and replacing
> the smaller things as we move forward.
> 

Thanks! I'll address your comments and see if I can post another (final??)
version next week.


From sumitg at nvidia.com  Wed Dec  6 02:13:40 2023
From: sumitg at nvidia.com (Sumit Gupta)
Date: Wed, 6 Dec 2023 15:43:40 +0530
Subject: [Patch v7] ACPI: processor: reduce CPUFREQ thermal reduction pctg
 for Tegra241
In-Reply-To: <6ccd1598-3c8b-1290-9494-01a3cdbb3003@huawei.com>
References: <20231123121433.12089-1-sumitg@nvidia.com>
 <ZV9bGtUsjF1v1oIW@bogus> <6ccd1598-3c8b-1290-9494-01a3cdbb3003@huawei.com>
Message-ID: <fd877ca8-6deb-9bc1-877d-57817a8913ac@nvidia.com>


>>> From: Srikar Srimath Tirumala <srikars at nvidia.com>
>>>
>>> Current implementation of processor_thermal performs software throttling
>>> in fixed steps of "20%" which can be too coarse for some platforms.
>>> We observed some performance gain after reducing the throttle 
>>> percentage.
>>> Change the CPUFREQ thermal reduction percentage and maximum thermal 
>>> steps
>>> to be configurable. Also, update the default values of both for Nvidia
>>> Tegra241 (Grace) SoC. The thermal reduction percentage is reduced to 
>>> "5%"
>>> and accordingly the maximum number of thermal steps are increased as 
>>> they
>>> are derived from the reduction percentage.
>>>
>>> Signed-off-by: Srikar Srimath Tirumala <srikars at nvidia.com>
>>> Co-developed-by: Sumit Gupta <sumitg at nvidia.com>
>>> Signed-off-by: Sumit Gupta <sumitg at nvidia.com>
>>> ---
>>>
>>> Sending this patch separately as the other patch in the series is
>>> applied by Rafael in v6[1]. Revision history before this version is
>>> in the cover letter of v6[1].
>>>
>>> Please review and provide ACK if looks fine.
>>>
>>
>> For arm64 specific changes(a minor nit below though),
>>
>> Acked-by: Sudeep Holla <sudeep.holla at arm.com>
>>
>>
>> [...]
>>
>>> diff --git a/drivers/acpi/arm64/thermal_cpufreq.c 
>>> b/drivers/acpi/arm64/thermal_cpufreq.c
>>> new file mode 100644
>>> index 000000000000..d524f2cd6044
>>> --- /dev/null
>>> +++ b/drivers/acpi/arm64/thermal_cpufreq.c
>>> @@ -0,0 +1,20 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +#include <linux/acpi.h>
>>> +
>>> +#include "../internal.h"
>>> +
>>> +#define SMCCC_SOC_ID_T241????? 0x036b0241
>>> +
>>
>> [nit] We really need to find better place to define this globally and not
>> locally at each usage site like this. We already have it in GICv3 driver.
>> But that can come as a cleanup later if it causes issue for merging this
>> change.
> 
> Agreed.
> 
> Looks good to me as well.
> 
> Acked-by: Hanjun Guo <guohanjun at huawei.com>
> 

Hi Rafael,

If the change seems fine, could you please apply this patch?

Thanks,
Sumit



From ryan.roberts at arm.com  Wed Dec  6 02:15:56 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 6 Dec 2023 10:15:56 +0000
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <CAGsJ_4xHib66MP3-o9jpHGzKecmgb-omBXinazBbrCiwHkonEQ@mail.gmail.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <CAGsJ_4zG6W_Z-u+3QcRDn4ByoeqUXjMusNS0RotfRMSqo8RCHg@mail.gmail.com>
 <CAGsJ_4zYhJWGx1DnHTiDnP3h1m8_rr6ZT6fXt8pO=jzs9QZS-A@mail.gmail.com>
 <5216caaf-1fcf-4715-99c3-521e2a1cc756@arm.com>
 <CAGsJ_4xHib66MP3-o9jpHGzKecmgb-omBXinazBbrCiwHkonEQ@mail.gmail.com>
Message-ID: <c20b75c2-1636-47b8-b120-e0b8da326374@arm.com>

On 05/12/2023 20:16, Barry Song wrote:
> On Tue, Dec 5, 2023 at 11:48?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>>
>> On 05/12/2023 01:24, Barry Song wrote:
>>> On Tue, Dec 5, 2023 at 9:15?AM Barry Song <21cnbao at gmail.com> wrote:
>>>>
>>>> On Mon, Dec 4, 2023 at 6:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>>>>>
>>>>> Introduce the logic to allow THP to be configured (through the new sysfs
>>>>> interface we just added) to allocate large folios to back anonymous
>>>>> memory, which are larger than the base page size but smaller than
>>>>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>>>>>
>>>>> mTHP continues to be PTE-mapped, but in many cases can still provide
>>>>> similar benefits to traditional PMD-sized THP: Page faults are
>>>>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
>>>>> the configured order), but latency spikes are much less prominent
>>>>> because the size of each page isn't as huge as the PMD-sized variant and
>>>>> there is less memory to clear in each page fault. The number of per-page
>>>>> operations (e.g. ref counting, rmap management, lru list management) are
>>>>> also significantly reduced since those ops now become per-folio.
>>>>>
>>>>> Some architectures also employ TLB compression mechanisms to squeeze
>>>>> more entries in when a set of PTEs are virtually and physically
>>>>> contiguous and approporiately aligned. In this case, TLB misses will
>>>>> occur less often.
>>>>>
>>>>> The new behaviour is disabled by default, but can be enabled at runtime
>>>>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
>>>>> (see documentation in previous commit). The long term aim is to change
>>>>> the default to include suitable lower orders, but there are some risks
>>>>> around internal fragmentation that need to be better understood first.
>>>>>
>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>> ---
>>>>>  include/linux/huge_mm.h |   6 ++-
>>>>>  mm/memory.c             | 106 ++++++++++++++++++++++++++++++++++++----
>>>>>  2 files changed, 101 insertions(+), 11 deletions(-)
>>>>>
>>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>>>> index bd0eadd3befb..91a53b9835a4 100644
>>>>> --- a/include/linux/huge_mm.h
>>>>> +++ b/include/linux/huge_mm.h
>>>>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>>>>>  #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>>>>>
>>>>>  /*
>>>>> - * Mask of all large folio orders supported for anonymous THP.
>>>>> + * Mask of all large folio orders supported for anonymous THP; all orders up to
>>>>> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
>>>>> + * (which is a limitation of the THP implementation).
>>>>>   */
>>>>> -#define THP_ORDERS_ALL_ANON    BIT(PMD_ORDER)
>>>>> +#define THP_ORDERS_ALL_ANON    ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>>>>>
>>>>>  /*
>>>>>   * Mask of all large folio orders supported for file THP.
>>>>> diff --git a/mm/memory.c b/mm/memory.c
>>>>> index 3ceeb0f45bf5..bf7e93813018 100644
>>>>> --- a/mm/memory.c
>>>>> +++ b/mm/memory.c
>>>>> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>>>         return ret;
>>>>>  }
>>>>>
>>>>> +static bool pte_range_none(pte_t *pte, int nr_pages)
>>>>> +{
>>>>> +       int i;
>>>>> +
>>>>> +       for (i = 0; i < nr_pages; i++) {
>>>>> +               if (!pte_none(ptep_get_lockless(pte + i)))
>>>>> +                       return false;
>>>>> +       }
>>>>> +
>>>>> +       return true;
>>>>> +}
>>>>> +
>>>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>>>>> +{
>>>>> +       gfp_t gfp;
>>>>> +       pte_t *pte;
>>>>> +       unsigned long addr;
>>>>> +       struct folio *folio;
>>>>> +       struct vm_area_struct *vma = vmf->vma;
>>>>> +       unsigned long orders;
>>>>> +       int order;
>>>>> +
>>>>> +       /*
>>>>> +        * If uffd is active for the vma we need per-page fault fidelity to
>>>>> +        * maintain the uffd semantics.
>>>>> +        */
>>>>> +       if (userfaultfd_armed(vma))
>>>>> +               goto fallback;
>>>>> +
>>>>> +       /*
>>>>> +        * Get a list of all the (large) orders below PMD_ORDER that are enabled
>>>>> +        * for this vma. Then filter out the orders that can't be allocated over
>>>>> +        * the faulting address and still be fully contained in the vma.
>>>>> +        */
>>>>> +       orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
>>>>> +                                         BIT(PMD_ORDER) - 1);
>>>>> +       orders = thp_vma_suitable_orders(vma, vmf->address, orders);
>>>>> +
>>>>> +       if (!orders)
>>>>> +               goto fallback;
>>>>> +
>>>>> +       pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>>>> +       if (!pte)
>>>>> +               return ERR_PTR(-EAGAIN);
>>>>> +
>>>>> +       order = first_order(orders);
>>>>> +       while (orders) {
>>>>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>>> +               vmf->pte = pte + pte_index(addr);
>>>>> +               if (pte_range_none(vmf->pte, 1 << order))
>>>>> +                       break;
>>>>> +               order = next_order(&orders, order);
>>>>> +       }
>>>>> +
>>>>> +       vmf->pte = NULL;
>>>>> +       pte_unmap(pte);
>>>>> +
>>>>> +       gfp = vma_thp_gfp_mask(vma);
>>>>> +
>>>>> +       while (orders) {
>>>>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>>> +               folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>>>> +               if (folio) {
>>>>> +                       clear_huge_page(&folio->page, addr, 1 << order);
>>>>
>>>> Minor.
>>>>
>>>> Do we have to constantly clear a huge page? Is it possible to let
>>>> post_alloc_hook()
>>>> finish this job by using __GFP_ZERO/__GFP_ZEROTAGS as
>>>> vma_alloc_zeroed_movable_folio() is doing?
>>
>> I'm currently following the same allocation pattern as is done for PMD-sized
>> THP. In earlier versions of this patch I was trying to be smarter and use the
>> __GFP_ZERO/__GFP_ZEROTAGS as you suggest, but I was advised to keep it simple
>> and follow the existing pattern.
>>
>> I have a vague recollection __GFP_ZERO is not preferred for large folios because
>> of some issue with virtually indexed caches? (Matthew: did I see you mention
>> that in some other context?)
>>
>> That said, I wasn't aware that Android ships with
>> CONFIG_INIT_ON_ALLOC_DEFAULT_ON (I thought it was only used as a debug option),
>> so I can see the potential for some overhead reduction here.
>>
>> Options:
>>
>>  1) leave it as is and accept the duplicated clearing
>>  2) Pass __GFP_ZERO and remove clear_huge_page()
>>  3) define __GFP_SKIP_ZERO even when kasan is not enabled and pass it down so
>>     clear_huge_page() is the only clear
>>  4) make clear_huge_page() conditional on !want_init_on_alloc()
>>
>> I prefer option 4. What do you think?
> 
> either 1 and 4 is ok to me if we will finally remove this duplicated
> clear_huge_page on top.
> 4 is even better as it can at least temporarily resolve the problem.

I'm going to stick with option 1 for this series. Then we can fix it uniformly
here and for PMD-sized THP in a separate patch (possibly with the approach
suggested in 4).

> 
> in Android gki_defconfig,
> https://android.googlesource.com/kernel/common/+/refs/heads/android14-6.1-lts/arch/arm64/configs/gki_defconfig
> 
> Android always has the below,
> CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
> 
> here is some explanation for the reason,
> https://source.android.com/docs/security/test/memory-safety/zero-initialized-memory
> 
>>
>> As an aside, I've also noticed that clear_huge_page() should take vmf->address
>> so that it clears the faulting page last to keep the cache hot. If we decide on
>> an option that keeps clear_huge_page(), I'll also make that change.

I'll make this change for the next version.

>>
>> Thanks,
>> Ryan
>>
>>>>
> 
> Thanks
> Barry



From angelogioacchino.delregno at collabora.com  Wed Dec  6 02:19:32 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 6 Dec 2023 11:19:32 +0100
Subject: [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free()
 error log criteria
In-Reply-To: <20231113123049.4117280-4-fshao@chromium.org>
References: <20231113123049.4117280-1-fshao@chromium.org>
 <20231113123049.4117280-4-fshao@chromium.org>
Message-ID: <6c693161-0e89-4f9d-9a92-18f3783eefd2@collabora.com>

Il 13/11/23 13:26, Fei Shao ha scritto:
> mtk_vcodec_mem_free() shouldn't print error if the target DMA buffer has
> never been allocated or was freed properly in the previous call. That
> makes log confusing.
> 
> Update the error path to print log only when the caller attempts to free
> nonzero-size buffer with VA being NULL, which indicates something indeed
> went wrong.
> 
> This brings another benefit that the callers no more need to check
> mem->va explicitly to avoid the error, which can make the code more
> compact and neat.
> 
> Signed-off-by: Fei Shao <fshao at chromium.org>

I think that this error is supposed to catch two issues in one:
  - We're called to free no memory (something that does make no sense),
    this may happen for example when calling xxx_free() twice, and it
    is a mistake that *must* be fixed;
  - We're failing to free memory for real (which you covered)

....that said, I think that if you want to clarify the error messages
in this function, it should look something like this:

if (!mem->va) {
	mtk_v4l2_err(plat_dev, "%s: Tried to free a NULL VA", __func__);
	if (mem->size)
		mtk_v4l2_err(plat_dev, "Failed to free %lu bytes", mem->size);
	return;
}

Cheers,
Angelo



From angelogioacchino.delregno at collabora.com  Wed Dec  6 02:19:37 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 6 Dec 2023 11:19:37 +0100
Subject: [PATCH 1/4] media: mediatek: vcodec: Replace dev_name in error
 string
In-Reply-To: <20231113123049.4117280-2-fshao@chromium.org>
References: <20231113123049.4117280-1-fshao@chromium.org>
 <20231113123049.4117280-2-fshao@chromium.org>
Message-ID: <fe265655-3ebe-466d-875b-f74e57e0363c@collabora.com>

Il 13/11/23 13:26, Fei Shao ha scritto:
> mtk_v4l2_err() already uses dev_err(), so don't print the device name
> again. Print function name instead.
> 
> Signed-off-by: Fei Shao <fshao at chromium.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From angelogioacchino.delregno at collabora.com  Wed Dec  6 02:19:37 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 6 Dec 2023 11:19:37 +0100
Subject: [PATCH 2/4] media: mediatek: vcodec: Drop unnecessary variable
In-Reply-To: <20231113123049.4117280-3-fshao@chromium.org>
References: <20231113123049.4117280-1-fshao@chromium.org>
 <20231113123049.4117280-3-fshao@chromium.org>
Message-ID: <3528639f-85a3-4756-b04b-c233f6c84276@collabora.com>

Il 13/11/23 13:26, Fei Shao ha scritto:
> It's unclear why only mem->size has local copies without particular
> usage in mtk_vcodec_mem_alloc() and mtk_vcodec_mem_free(), and they
> seem removable.
> 
> Drop them to make the code visually consistent, and update printk format
> identifier accordingly.
> 
> Signed-off-by: Fei Shao <fshao at chromium.org>

That's probably just about personal preferences, as mem->size is not expected
to change during the flow of those functions.

That said, as much as you, I prefer not having this local copy as it's using
(a very small amount of) memory for no real reason anyway, so:

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Wed Dec  6 02:19:32 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 6 Dec 2023 11:19:32 +0100
Subject: [PATCH 4/4] media: mediatek: vcodec: Drop VA check against
 mtk_vcodec_mem_free()
In-Reply-To: <20231113123049.4117280-5-fshao@chromium.org>
References: <20231113123049.4117280-1-fshao@chromium.org>
 <20231113123049.4117280-5-fshao@chromium.org>
Message-ID: <449b9678-e3c2-4410-ac80-c50a1a25cc06@collabora.com>

Il 13/11/23 13:26, Fei Shao ha scritto:
> Now mtk_vcodec_mem_free() handles the VA-is-NULL case without generating
> excess error log, so we don't need to check that every time before using
> it in the driver.
> 
> Remove all the unnecessary if branches against mtk_vcodec_mem_free().
> 
> Signed-off-by: Fei Shao <fshao at chromium.org>

For the reasons explained in patch [3/4], I'd prefer to keep those checks.

Cheers,
Angelo


From tabba at google.com  Wed Dec  6 02:19:21 2023
From: tabba at google.com (Fuad Tabba)
Date: Wed, 6 Dec 2023 10:19:21 +0000
Subject: [PATCH v2 09/12] KVM: arm64: Generate the HFGWTR-only RES0 bits
In-Reply-To: <20231206100503.564090-10-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com> <20231206100503.564090-10-tabba@google.com>
Message-ID: <CA+EHjTyBXnS-EUpEeYWg9L3jRDLsHY9vxPVm7yMZYKe-hs3DeQ@mail.gmail.com>

Hi,

On Wed, Dec 6, 2023 at 10:05?AM Fuad Tabba <tabba at google.com> wrote:
>
> Generate the HFGWTR-only RES0 bits in sysreg. This is done to
> consolidate all the bit definitions in one place.

I should have marked this as an RFC. I'm not sure if this approach is
better than the previous patch, or if I should just bite the bullet
and fully define HFGWTR's fields.

Cheers,
/fuad

>
> No functional change intended.
>
> Signed-off-by: Fuad Tabba <tabba at google.com>
> ---
>  arch/arm64/include/asm/kvm_arm.h | 13 +++----------
>  arch/arm64/tools/sysreg          | 26 ++++++++++++++++++++++++++
>  2 files changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 5b634e909d1c..02442bc90717 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -348,16 +348,9 @@
>  #define __HFGRTR_EL2_MASK      GENMASK(49, 0)
>  #define __HFGRTR_EL2_nMASK     (GENMASK(63, 52) | BIT(50))
>
> -/*
> - * The HFGWTR bits are a subset of HFGRTR bits. To ensure we don't miss any
> - * future additions, define __HFGWTR* macros relative to __HFGRTR* ones.
> - */
> -#define __HFGxTR_READ_ONLY_MASK        (BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
> -                                GENMASK(26, 25) | BIT(21) | BIT(18) | \
> -                                GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
> -#define __HFGWTR_EL2_RES0      (__HFGRTR_EL2_RES0 | __HFGxTR_READ_ONLY_MASK)
> -#define __HFGWTR_EL2_MASK      (__HFGRTR_EL2_MASK & ~__HFGxTR_READ_ONLY_MASK)
> -#define __HFGWTR_EL2_nMASK     (__HFGRTR_EL2_nMASK & ~__HFGxTR_READ_ONLY_MASK)
> +#define __HFGWTR_EL2_RES0      (__HFGRTR_EL2_RES0 | HFGWTR_ONLY_EL2_RES0)
> +#define __HFGWTR_EL2_MASK      (__HFGRTR_EL2_MASK & ~HFGWTR_ONLY_EL2_RES0)
> +#define __HFGWTR_EL2_nMASK     (__HFGRTR_EL2_nMASK & ~HFGWTR_ONLY_EL2_RES0)
>
>  #define __HFGITR_EL2_RES0      HFGITR_EL2_RES0
>  #define __HFGITR_EL2_MASK      (BIT(62) | BIT(60) | GENMASK(54, 0))
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index e5631f4e62f4..85f8b385fed2 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -2093,6 +2093,32 @@ Field    1       AFSR1_EL1
>  Field  0       AFSR0_EL1
>  EndSysregFields
>
> +# HFGWTR_EL2 bits are a subset of those for HFGRTR_EL2.
> +# Define RES0 only present in HFGWTR_EL2.
> +SysregFields   HFGWTR_ONLY_EL2
> +Unkn   63:47
> +Res0   46
> +Unkn   45:43
> +Res0   42
> +Unkn   41
> +Res0   40
> +Unkn   39:29
> +Res0   28
> +Unkn   27
> +Res0   26:25
> +Unkn   24:22
> +Res0   21
> +Unkn   20:19
> +Res0   18
> +Unkn   17:16
> +Res0   15:14
> +Unkn   13:11
> +Res0   10:9
> +Unkn   8:3
> +Res0   2
> +Unkn   1:0
> +EndSysregFields
> +
>  Sysreg HFGRTR_EL2      3       4       1       1       4
>  Fields HFGxTR_EL2
>  EndSysreg
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From krzysztof.kozlowski at linaro.org  Wed Dec  6 02:20:20 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 11:20:20 +0100
Subject: [PATCH v3 1/4] dt-bindings: clock: mediatek: add MT7988 clock IDs
In-Reply-To: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
Message-ID: <dfd4af72-c621-42ae-bb13-cb204aaa8ffd@linaro.org>

On 06/12/2023 01:55, Daniel Golle wrote:
> From: Sam Shih <sam.shih at mediatek.com>
> 
> Add MT7988 clock dt-bindings for topckgen, apmixedsys, infracfg,
> ethernet and xfipll subsystem clocks.
> 
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
> v3: no changes

Really? It was entirely different author at v2.

> v2: fix indentation
> 
>  .../dt-bindings/clock/mediatek,mt7988-clk.h   | 280 ++++++++++++++++++
>  1 file changed, 280 insertions(+)
>  create mode 100644 include/dt-bindings/clock/mediatek,mt7988-clk.h
> 


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 02:12:28 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Wed, 06 Dec 2023 12:12:28 +0200
Subject: [PATCH v2 1/4] media: rkisp1: Drop IRQF_SHARED
In-Reply-To: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
References: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
Message-ID: <20231206-rkisp-irq-fix-v2-1-6ba4185eeb1f@ideasonboard.com>

In all known platforms the ISP has dedicated IRQ lines, but for some
reason the driver uses IRQF_SHARED.

Supporting IRQF_SHARED properly requires handling interrupts even when
our device is disabled, and the driver does not handle this. To avoid
adding such code, and to be sure the driver won't accidentally be used
in a platform with shared interrupts, let's drop the IRQF_SHARED flag.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index 2b9886fd0800..d4950294b7b9 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -573,7 +573,7 @@ static int rkisp1_probe(struct platform_device *pdev)
 		if (irq < 0)
 			return irq;
 
-		ret = devm_request_irq(dev, irq, info->isrs[i].isr, IRQF_SHARED,
+		ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0,
 				       dev_driver_string(dev), dev);
 		if (ret) {
 			dev_err(dev, "request irq failed: %d\n", ret);

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Wed Dec  6 02:21:48 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 11:21:48 +0100
Subject: [PATCH v3 2/4] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <def05aac79ddff872d3e56698b736cb445f14116.1701823757.git.daniel@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
 <def05aac79ddff872d3e56698b736cb445f14116.1701823757.git.daniel@makrotopia.org>
Message-ID: <d80d493f-bc77-4e27-9432-36512e445ba0@linaro.org>

On 06/12/2023 01:57, Daniel Golle wrote:
> Add various clock controllers found in the MT7988 SoC to existing
> bindings (if applicable) and add files for the new ethwarp, mcusys
> and xfi-pll clock controllers not previously present in any SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
> v3:
>  * move clock bindings to clock folder
>  * drop ti,syscon-reset from bindings and example
>  * merge mcusys with topckgen bindings
> 
> v2:
>  * dropped unused labels
>  * add 'type: object' declaration for reset-controller found in new
>    ethwarp controller and represented as ti,syscon-reset
>  * rebase on top of
>    "dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema"
> 
>  .../arm/mediatek/mediatek,infracfg.yaml       |  1 +
>  .../bindings/clock/mediatek,apmixedsys.yaml   |  1 +
>  .../bindings/clock/mediatek,ethsys.yaml       |  1 +
>  .../clock/mediatek,mt7988-ethwarp.yaml        | 49 +++++++++++++++++++
>  .../clock/mediatek,mt7988-xfi-pll.yaml        | 48 ++++++++++++++++++
>  .../bindings/clock/mediatek,topckgen.yaml     |  2 +
>  .../bindings/net/pcs/mediatek,sgmiisys.yaml   | 13 +++--
>  7 files changed, 112 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
>  create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
> index ea98043c6ba3d..230b5188a88db 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
> @@ -30,6 +30,7 @@ properties:
>                - mediatek,mt7629-infracfg
>                - mediatek,mt7981-infracfg
>                - mediatek,mt7986-infracfg
> +              - mediatek,mt7988-infracfg
>                - mediatek,mt8135-infracfg
>                - mediatek,mt8167-infracfg
>                - mediatek,mt8173-infracfg
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
> index 372c1d744bc27..685535846cbb7 100644
> --- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
> +++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
> @@ -22,6 +22,7 @@ properties:
>            - mediatek,mt7622-apmixedsys
>            - mediatek,mt7981-apmixedsys
>            - mediatek,mt7986-apmixedsys
> +          - mediatek,mt7988-apmixedsys
>            - mediatek,mt8135-apmixedsys
>            - mediatek,mt8173-apmixedsys
>            - mediatek,mt8516-apmixedsys
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
> index 94d42c8647777..f9cddacc2eae1 100644
> --- a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
> +++ b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
> @@ -22,6 +22,7 @@ properties:
>                - mediatek,mt7629-ethsys
>                - mediatek,mt7981-ethsys
>                - mediatek,mt7986-ethsys
> +              - mediatek,mt7988-ethsys
>            - const: syscon
>        - items:
>            - const: mediatek,mt7623-ethsys
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
> new file mode 100644
> index 0000000000000..9b919a155eb13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-ethwarp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT7988 ethwarp Controller
> +
> +maintainers:
> +  - Daniel Golle <daniel at makrotopia.org>
> +
> +description:
> +  The Mediatek MT7988 ethwarp controller provides clocks and resets for the
> +  Ethernet related subsystems found the MT7988 SoC.
> +  The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: mediatek,mt7988-ethwarp
> +      - const: syscon
> +      - const: simple-mfd

Why this is a simple MFD without children? Something is not right here.
Either this is not simple-mfd or this is not complete binding.

> +
> +  reg:
> +    maxItems: 1
> +
> +  '#clock-cells':
> +    const: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/reset/ti-syscon.h>
> +    soc {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        clock-controller at 15031000 {
> +            compatible = "mediatek,mt7988-ethwarp", "syscon", "simple-mfd";
> +            reg = <0 0x15031000 0 0x1000>;
> +            #clock-cells = <1>;
> +        };
> +    };
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
> new file mode 100644
> index 0000000000000..fe5e3a70299fd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-xfi-pll.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT7988 XFI PLL Clock Controller
> +
> +maintainers:
> +  - Daniel Golle <daniel at makrotopia.org>
> +
> +description:
> +  The MediaTek XFI PLL controller provides the 156.25MHz clock for the
> +  Ethernet SerDes PHY from the 40MHz top_xtal clock.
> +
> +properties:
> +  compatible:
> +    const: mediatek,mt7988-xfi-pll
> +
> +  reg:
> +    maxItems: 1
> +
> +  resets:
> +    maxItems: 1
> +
> +  '#clock-cells':
> +    const: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - resets
> +  - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    soc {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        clock-controller at 11f40000 {
> +            compatible = "mediatek,mt7988-xfi-pll";
> +            reg = <0 0x11f40000 0 0x1000>;
> +            resets = <&watchdog 16>;
> +            #clock-cells = <1>;
> +        };
> +    };
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
> index 6d087ded7437a..bdf3b55bd56fd 100644
> --- a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
> +++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
> @@ -37,6 +37,8 @@ properties:
>                - mediatek,mt7629-topckgen
>                - mediatek,mt7981-topckgen
>                - mediatek,mt7986-topckgen
> +              - mediatek,mt7988-mcusys
> +              - mediatek,mt7988-topckgen
>                - mediatek,mt8167-topckgen
>                - mediatek,mt8183-topckgen
>            - const: syscon
> diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
> index 66a95191bd776..68632cda334bd 100644
> --- a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
> +++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
> @@ -15,15 +15,22 @@ description:
>  
>  properties:
>    compatible:
> -    items:
> -      - enum:
> +    oneOf:
> +      - items:
> +        - enum:

It does not look like you tested the bindings, at least after quick
look. Please run `make dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint.

Best regards,
Krzysztof



From david at redhat.com  Wed Dec  6 02:22:59 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 6 Dec 2023 11:22:59 +0100
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <f65baa0c-3f5a-45ad-80dd-c240fe166877@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <8d5fdb17-c670-4814-8f48-4b90062668fc@redhat.com>
 <f65baa0c-3f5a-45ad-80dd-c240fe166877@arm.com>
Message-ID: <7d3457cd-5e3d-42a7-8113-545da646d7c8@redhat.com>

On 06.12.23 11:13, Ryan Roberts wrote:
> On 05/12/2023 17:21, David Hildenbrand wrote:
>> On 04.12.23 11:20, Ryan Roberts wrote:
>>> Hi All,
>>>
>>> A new week, a new version, a new name... This is v8 of a series to implement
>>> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
>>> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
>>> this fares better.
>>>
>>> The objective of this is to improve performance by allocating larger chunks of
>>> memory during anonymous page faults:
>>>
>>> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>>>  ??? pages, there are efficiency savings to be had; fewer page faults, batched PTE
>>>  ??? and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>>>  ??? overhead. This should benefit all architectures.
>>> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>>>  ??? advantage of HW TLB compression techniques. A reduction in TLB pressure
>>>  ??? speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>>>  ??? TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
>>>
>>> This version changes the name and tidies up some of the kernel code and test
>>> code, based on feedback against v7 (see change log for details).
>>>
>>> By default, the existing behaviour (and performance) is maintained. The user
>>> must explicitly enable multi-size THP to see the performance benefit. This is
>>> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
>>> David for the suggestion)! This interface is inspired by the existing
>>> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
>>> compatibility with the existing PMD-size THP interface, and provides a base for
>>> future extensibility. See [8] for detailed discussion of the interface.
>>>
>>> This series is based on mm-unstable (715b67adf4c8).
>>
>> I took a look at the core pieces. Some things might want some smaller tweaks,
>> but nothing that should stop this from having fun in mm-unstable, and replacing
>> the smaller things as we move forward.
>>
> 
> Thanks! I'll address your comments and see if I can post another (final??)
> version next week.

It's always possible to do incremental changes on top that Andrew will 
squash in the end. I even recall that he prefers that way once a series 
has been in mm-unstable for a bit, so one can better observe the diff 
and which effects they have.

-- 
Cheers,

David / dhildenb



From 21cnbao at gmail.com  Wed Dec  6 02:25:34 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Wed, 6 Dec 2023 23:25:34 +1300
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <c20b75c2-1636-47b8-b120-e0b8da326374@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com> <20231204102027.57185-5-ryan.roberts@arm.com>
 <CAGsJ_4zG6W_Z-u+3QcRDn4ByoeqUXjMusNS0RotfRMSqo8RCHg@mail.gmail.com>
 <CAGsJ_4zYhJWGx1DnHTiDnP3h1m8_rr6ZT6fXt8pO=jzs9QZS-A@mail.gmail.com>
 <5216caaf-1fcf-4715-99c3-521e2a1cc756@arm.com> <CAGsJ_4xHib66MP3-o9jpHGzKecmgb-omBXinazBbrCiwHkonEQ@mail.gmail.com>
 <c20b75c2-1636-47b8-b120-e0b8da326374@arm.com>
Message-ID: <CAGsJ_4xsqAB6spgk3tw+96NY=+2036hx49tFNY66cMcmDamo+Q@mail.gmail.com>

On Wed, Dec 6, 2023 at 11:16?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
>
> On 05/12/2023 20:16, Barry Song wrote:
> > On Tue, Dec 5, 2023 at 11:48?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
> >>
> >> On 05/12/2023 01:24, Barry Song wrote:
> >>> On Tue, Dec 5, 2023 at 9:15?AM Barry Song <21cnbao at gmail.com> wrote:
> >>>>
> >>>> On Mon, Dec 4, 2023 at 6:21?PM Ryan Roberts <ryan.roberts at arm.com> wrote:
> >>>>>
> >>>>> Introduce the logic to allow THP to be configured (through the new sysfs
> >>>>> interface we just added) to allocate large folios to back anonymous
> >>>>> memory, which are larger than the base page size but smaller than
> >>>>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
> >>>>>
> >>>>> mTHP continues to be PTE-mapped, but in many cases can still provide
> >>>>> similar benefits to traditional PMD-sized THP: Page faults are
> >>>>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
> >>>>> the configured order), but latency spikes are much less prominent
> >>>>> because the size of each page isn't as huge as the PMD-sized variant and
> >>>>> there is less memory to clear in each page fault. The number of per-page
> >>>>> operations (e.g. ref counting, rmap management, lru list management) are
> >>>>> also significantly reduced since those ops now become per-folio.
> >>>>>
> >>>>> Some architectures also employ TLB compression mechanisms to squeeze
> >>>>> more entries in when a set of PTEs are virtually and physically
> >>>>> contiguous and approporiately aligned. In this case, TLB misses will
> >>>>> occur less often.
> >>>>>
> >>>>> The new behaviour is disabled by default, but can be enabled at runtime
> >>>>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
> >>>>> (see documentation in previous commit). The long term aim is to change
> >>>>> the default to include suitable lower orders, but there are some risks
> >>>>> around internal fragmentation that need to be better understood first.
> >>>>>
> >>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> >>>>> ---
> >>>>>  include/linux/huge_mm.h |   6 ++-
> >>>>>  mm/memory.c             | 106 ++++++++++++++++++++++++++++++++++++----
> >>>>>  2 files changed, 101 insertions(+), 11 deletions(-)
> >>>>>
> >>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> >>>>> index bd0eadd3befb..91a53b9835a4 100644
> >>>>> --- a/include/linux/huge_mm.h
> >>>>> +++ b/include/linux/huge_mm.h
> >>>>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
> >>>>>  #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> >>>>>
> >>>>>  /*
> >>>>> - * Mask of all large folio orders supported for anonymous THP.
> >>>>> + * Mask of all large folio orders supported for anonymous THP; all orders up to
> >>>>> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
> >>>>> + * (which is a limitation of the THP implementation).
> >>>>>   */
> >>>>> -#define THP_ORDERS_ALL_ANON    BIT(PMD_ORDER)
> >>>>> +#define THP_ORDERS_ALL_ANON    ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
> >>>>>
> >>>>>  /*
> >>>>>   * Mask of all large folio orders supported for file THP.
> >>>>> diff --git a/mm/memory.c b/mm/memory.c
> >>>>> index 3ceeb0f45bf5..bf7e93813018 100644
> >>>>> --- a/mm/memory.c
> >>>>> +++ b/mm/memory.c
> >>>>> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >>>>>         return ret;
> >>>>>  }
> >>>>>
> >>>>> +static bool pte_range_none(pte_t *pte, int nr_pages)
> >>>>> +{
> >>>>> +       int i;
> >>>>> +
> >>>>> +       for (i = 0; i < nr_pages; i++) {
> >>>>> +               if (!pte_none(ptep_get_lockless(pte + i)))
> >>>>> +                       return false;
> >>>>> +       }
> >>>>> +
> >>>>> +       return true;
> >>>>> +}
> >>>>> +
> >>>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >>>>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
> >>>>> +{
> >>>>> +       gfp_t gfp;
> >>>>> +       pte_t *pte;
> >>>>> +       unsigned long addr;
> >>>>> +       struct folio *folio;
> >>>>> +       struct vm_area_struct *vma = vmf->vma;
> >>>>> +       unsigned long orders;
> >>>>> +       int order;
> >>>>> +
> >>>>> +       /*
> >>>>> +        * If uffd is active for the vma we need per-page fault fidelity to
> >>>>> +        * maintain the uffd semantics.
> >>>>> +        */
> >>>>> +       if (userfaultfd_armed(vma))
> >>>>> +               goto fallback;
> >>>>> +
> >>>>> +       /*
> >>>>> +        * Get a list of all the (large) orders below PMD_ORDER that are enabled
> >>>>> +        * for this vma. Then filter out the orders that can't be allocated over
> >>>>> +        * the faulting address and still be fully contained in the vma.
> >>>>> +        */
> >>>>> +       orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
> >>>>> +                                         BIT(PMD_ORDER) - 1);
> >>>>> +       orders = thp_vma_suitable_orders(vma, vmf->address, orders);
> >>>>> +
> >>>>> +       if (!orders)
> >>>>> +               goto fallback;
> >>>>> +
> >>>>> +       pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
> >>>>> +       if (!pte)
> >>>>> +               return ERR_PTR(-EAGAIN);
> >>>>> +
> >>>>> +       order = first_order(orders);
> >>>>> +       while (orders) {
> >>>>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> >>>>> +               vmf->pte = pte + pte_index(addr);
> >>>>> +               if (pte_range_none(vmf->pte, 1 << order))
> >>>>> +                       break;
> >>>>> +               order = next_order(&orders, order);
> >>>>> +       }
> >>>>> +
> >>>>> +       vmf->pte = NULL;
> >>>>> +       pte_unmap(pte);
> >>>>> +
> >>>>> +       gfp = vma_thp_gfp_mask(vma);
> >>>>> +
> >>>>> +       while (orders) {
> >>>>> +               addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> >>>>> +               folio = vma_alloc_folio(gfp, order, vma, addr, true);
> >>>>> +               if (folio) {
> >>>>> +                       clear_huge_page(&folio->page, addr, 1 << order);
> >>>>
> >>>> Minor.
> >>>>
> >>>> Do we have to constantly clear a huge page? Is it possible to let
> >>>> post_alloc_hook()
> >>>> finish this job by using __GFP_ZERO/__GFP_ZEROTAGS as
> >>>> vma_alloc_zeroed_movable_folio() is doing?
> >>
> >> I'm currently following the same allocation pattern as is done for PMD-sized
> >> THP. In earlier versions of this patch I was trying to be smarter and use the
> >> __GFP_ZERO/__GFP_ZEROTAGS as you suggest, but I was advised to keep it simple
> >> and follow the existing pattern.
> >>
> >> I have a vague recollection __GFP_ZERO is not preferred for large folios because
> >> of some issue with virtually indexed caches? (Matthew: did I see you mention
> >> that in some other context?)
> >>
> >> That said, I wasn't aware that Android ships with
> >> CONFIG_INIT_ON_ALLOC_DEFAULT_ON (I thought it was only used as a debug option),
> >> so I can see the potential for some overhead reduction here.
> >>
> >> Options:
> >>
> >>  1) leave it as is and accept the duplicated clearing
> >>  2) Pass __GFP_ZERO and remove clear_huge_page()
> >>  3) define __GFP_SKIP_ZERO even when kasan is not enabled and pass it down so
> >>     clear_huge_page() is the only clear
> >>  4) make clear_huge_page() conditional on !want_init_on_alloc()
> >>
> >> I prefer option 4. What do you think?
> >
> > either 1 and 4 is ok to me if we will finally remove this duplicated
> > clear_huge_page on top.
> > 4 is even better as it can at least temporarily resolve the problem.
>
> I'm going to stick with option 1 for this series. Then we can fix it uniformly
> here and for PMD-sized THP in a separate patch (possibly with the approach
> suggested in 4).

Ok. Thanks. there is no one fixing PMD-sized THP, probably because PMD-sized
THP is shutdown immediately after Android boots :-)

>
> >
> > in Android gki_defconfig,
> > https://android.googlesource.com/kernel/common/+/refs/heads/android14-6.1-lts/arch/arm64/configs/gki_defconfig
> >
> > Android always has the below,
> > CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
> >
> > here is some explanation for the reason,
> > https://source.android.com/docs/security/test/memory-safety/zero-initialized-memory
> >
> >>
> >> As an aside, I've also noticed that clear_huge_page() should take vmf->address
> >> so that it clears the faulting page last to keep the cache hot. If we decide on
> >> an option that keeps clear_huge_page(), I'll also make that change.
>
> I'll make this change for the next version.
>
> >>
> >> Thanks,
> >> Ryan
> >>

Thanks
Barry


From krzysztof.kozlowski at linaro.org  Wed Dec  6 02:32:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 11:32:07 +0100
Subject: [Patch v5 01/11] dt-bindings: media: s5p-mfc: Add mfcv12 variant
In-Reply-To: <20231206063045.97234-2-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
 <CGME20231206063108epcas5p1af3d9d0442c8abebe91d769cc68284d5@epcas5p1.samsung.com>
 <20231206063045.97234-2-aakarsh.jain@samsung.com>
Message-ID: <58b77bd2-84fc-4e94-807f-1600d0053938@linaro.org>

On 06/12/2023 07:30, Aakarsh Jain wrote:
> Add Tesla FSD MFC(MFC v12) compatible.
> 
> Cc: linux-fsd at tesla.com
> Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From geert at linux-m68k.org  Wed Dec  6 02:33:17 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 6 Dec 2023 11:33:17 +0100
Subject: [PATCH 11/14] arm64: renesas: rzg3s-smarc-som: Invert the logic
 for SW_SD2_EN macro
In-Reply-To: <20231120070024.4079344-12-claudiu.beznea.uj@bp.renesas.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com> <20231120070024.4079344-12-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdUbKe=yiXWNmk5BJFLtF2psx9khiDRGasT9WsnHz4RWsg@mail.gmail.com>

Hi Claudiu,

On Mon, Nov 20, 2023 at 8:03?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> The intention of SW_SD2_EN macro was to reflect the state of SW_CONFIG3
> switch available on RZ/G3S Smarc Module. According to documentation SD2
> is enabled when switch is in OFF state. For this, changed the logic of
> marco to map value 0 to switch's OFF state and value 1 to switch's ON
> state. Along with this update the description for each state for better
> understanding.
>
> The value of SW_SD2_EN macro was not changed in file because, according to
> documentation, the default state for this switch is ON.
>
> Fixes: adb4f0c5699c ("arm64: dts: renesas: Add initial support for RZ/G3S SMARC SoM")
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> @@ -14,8 +14,8 @@
>   *     0 - SD0 is connected to eMMC
>   *     1 - SD0 is connected to uSD0 card
>   * @SW_SD2_EN:
> - *     0 - SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
> - *     1 - SD2 is connected to SoC
> + *     0 - (switch OFF) SD2 is connected to SoC
> + *     1 - (switch ON)  SCIF1, SSI0, IRQ0, IRQ1 connected to SoC

I think this is still confusing: SW_SD2_EN refers to an active-low signal
(SW_SD2_EN#) in the schematics.

Before, SW_SD2_EN used assertion-logic (1 is enabled), and didn't
match the physical signal level.
After your patch, SW_SD2_EN matches the active-low physical level, but
this is not reflected in the name...

>   */
>  #define SW_SD0_DEV_SEL 1
>  #define SW_SD2_EN      1
> @@ -25,7 +25,7 @@ / {
>
>         aliases {
>                 mmc0 = &sdhi0;
> -#if SW_SD2_EN
> +#if !SW_SD2_EN

... so this condition looks really weird.

>                 mmc2 = &sdhi2;
>  #endif
>         };
> @@ -116,7 +116,7 @@ &sdhi0 {
>  };
>  #endif
>
> -#if SW_SD2_EN
> +#if !SW_SD2_EN
>  &sdhi2 {
>         pinctrl-0 = <&sdhi2_pins>;
>         pinctrl-names = "default";

So I think SW_SD2_EN should be renamed to SW_SD2_EN_N.

Cfr. SW_ET0_EN_N on RZ/G2UL:

arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * DIP-Switch SW1 setting
arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * 1 : High; 0: Low
arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * SW1-2 :
SW_SD0_DEV_SEL    (0: uSD; 1: eMMC)
arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * SW1-3 :
SW_ET0_EN_N               (0: ETHER0; 1: CAN0, CAN1, SSI1, RSPI1)
arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * Please change
below macros according to SW1 setting on the SoM

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From krzysztof.kozlowski at linaro.org  Wed Dec  6 02:33:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 11:33:53 +0100
Subject: [Patch v5 11/11] arm64: dts: fsd: Add MFC related DT enteries
In-Reply-To: <20231206063045.97234-12-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
 <CGME20231206063140epcas5p1ba86525117f4d9ec9172ae7cb18b7420@epcas5p1.samsung.com>
 <20231206063045.97234-12-aakarsh.jain@samsung.com>
Message-ID: <91188ba1-fd37-454f-beb1-0119bd24d3c8@linaro.org>

On 06/12/2023 07:30, Aakarsh Jain wrote:
> Add MFC DT node and reserve memory node for MFC usage.
> 
> Cc: linux-fsd at tesla.com
> Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
> Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
> ---
>  arch/arm64/boot/dts/tesla/fsd.dtsi | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)

This should be merged via Samsung SoC, so I will take it once bindings
get accepted.

If there is going to be resend of entire patchset, please don't include
this patch in new resend. If this patch needs resending, send it
separately and provide lore link to the bindings.

Best regards,
Krzysztof



From angelogioacchino.delregno at collabora.com  Wed Dec  6 02:38:36 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 6 Dec 2023 11:38:36 +0100
Subject: [PATCH v3 3/4] clk: mediatek: Add pcw_chg_shift control
In-Reply-To: <40981d0bb722eb509628bcf82c31f632e4cf747a.1701823757.git.daniel@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
 <40981d0bb722eb509628bcf82c31f632e4cf747a.1701823757.git.daniel@makrotopia.org>
Message-ID: <0ebce75d-0074-4128-b35e-e86ee3ee546b@collabora.com>

Il 06/12/23 01:57, Daniel Golle ha scritto:
> From: Sam Shih <sam.shih at mediatek.com>
> 
> Introduce pcw_chg_shfit control to optionally use that instead of the
> hardcoded PCW_CHG_MASK macro.
> This will needed for clocks on the MT7988 SoC.
> 
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
> v3: use git --from ...
> v2: no changes
> 
>   drivers/clk/mediatek/clk-pll.c | 5 ++++-
>   drivers/clk/mediatek/clk-pll.h | 1 +
>   2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
> index 513ab6b1b3229..9f08bc5d2a8a2 100644
> --- a/drivers/clk/mediatek/clk-pll.c
> +++ b/drivers/clk/mediatek/clk-pll.c
> @@ -114,7 +114,10 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll, u32 pcw,
>   			pll->data->pcw_shift);
>   	val |= pcw << pll->data->pcw_shift;
>   	writel(val, pll->pcw_addr);
> -	chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
> +	if (pll->data->pcw_chg_shift)
> +		chg = readl(pll->pcw_chg_addr) | BIT(pll->data->pcw_chg_shift);
> +	else
> +		chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
>   	writel(chg, pll->pcw_chg_addr);
>   	if (pll->tuner_addr)
>   		writel(val + 1, pll->tuner_addr);
> diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
> index f17278ff15d78..d28d317e84377 100644
> --- a/drivers/clk/mediatek/clk-pll.h
> +++ b/drivers/clk/mediatek/clk-pll.h
> @@ -44,6 +44,7 @@ struct mtk_pll_data {
>   	u32 pcw_reg;
>   	int pcw_shift;
>   	u32 pcw_chg_reg;
> +	int pcw_chg_shift;
>   	const struct mtk_pll_div_table *div_table;
>   	const char *parent_name;
>   	u32 en_reg;

Hmm... no, this is not the best at all and can be improved.

Okay, so, the situation here is that one or some PLL(s) on MT7988 have a different
PCW_CHG_MASK as far as I understand.

Situation here is:
  - Each PLL must be registered to clk-pll
  - Each driver declaring a PLL does exactly so
    - There's a function to register the PLL

You definitely don't want to add a conditional in pll_set_rate(): even though
this is technically not a performance path on the current SoCs (and will probably
never be), it's simply useless to have this (very small) overhead there.

The solution is to:
  - Change that pcw_chg_shift to an unsigned short int type (or u8, your call):
    you don't need 32 bits for this number, as the expected range of this member
    is [0-31], and this can be expressed in just 4 bits (u8 is the smallest though)
  - Add that to function mtk_clk_register_pll_ops()
  - Change mtk_pll_set_rate_regs() to always do
    chg = readl(pll->pcw_chg_addr) | BIT(pll->data->pcw_chg_shift);

Cheers,
Angelo


From lkp at intel.com  Wed Dec  6 02:42:38 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 6 Dec 2023 18:42:38 +0800
Subject: [PATCH v4 2/5] clk: stm32mp1: use stm32mp13 reset driver
In-Reply-To: <20231128164851.588315-3-gabriel.fernandez@foss.st.com>
References: <20231128164851.588315-3-gabriel.fernandez@foss.st.com>
Message-ID: <202312061848.1bvWrret-lkp@intel.com>

Hi,

kernel test robot noticed the following build warnings:

[auto build test WARNING on atorgue-stm32/stm32-next]
[also build test WARNING on clk/clk-next robh/for-next linus/master v6.7-rc4 next-20231206]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/gabriel-fernandez-foss-st-com/clk-stm32mp1-move-stm32mp1-clock-driver-into-stm32-directory/20231129-005157
base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
patch link:    https://lore.kernel.org/r/20231128164851.588315-3-gabriel.fernandez%40foss.st.com
patch subject: [PATCH v4 2/5] clk: stm32mp1: use stm32mp13 reset driver
config: arm-randconfig-r132-20231201 (https://download.01.org/0day-ci/archive/20231206/202312061848.1bvWrret-lkp at intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231206/202312061848.1bvWrret-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312061848.1bvWrret-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/clk/stm32/clk-stm32mp13.c:1516:29: sparse: sparse: symbol 'stm32mp13_reset_data' was not declared. Should it be static?
--
>> drivers/clk/stm32/clk-stm32mp1.c:2148:29: sparse: sparse: symbol 'stm32mp1_reset_data' was not declared. Should it be static?

vim +/stm32mp13_reset_data +1516 drivers/clk/stm32/clk-stm32mp13.c

  1515	
> 1516	struct clk_stm32_reset_data stm32mp13_reset_data = {
  1517		.nr_lines	= STM32MP1_RESET_ID_MASK,
  1518		.clear_offset	= RCC_CLR_OFFSET,
  1519	};
  1520	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From conor at kernel.org  Wed Dec  6 02:55:48 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 6 Dec 2023 10:55:48 +0000
Subject: [PATCH] drivers: perf: constify the ctl_table argument of the
 riscv user access handler
In-Reply-To: <20231206084642.802053-1-m.szyprowski@samsung.com>
References: <CGME20231206084652eucas1p1fd6025710032f3a4a64b05dab67a2a17@eucas1p1.samsung.com>
 <20231206084642.802053-1-m.szyprowski@samsung.com>
Message-ID: <20231206-flanking-frill-fffeca740221@spud>

On Wed, Dec 06, 2023 at 09:46:42AM +0100, Marek Szyprowski wrote:
> 
> Fix riscv build break after commit c8be9e66ca1e ("sysctl: treewide:
> constify the ctl_table argument of handlers").
> 
> Fixes: c8be9e66ca1e ("sysctl: treewide: constify the ctl_table argument of handlers")
> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>

This breaks the build when applied to the RISC-V tree. I'm going to mark
it "handled elsewhere" in patchwork since it needs to go into whatever
tree has the broken commit.

Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/c9ffdb6e/attachment.sig>

From geert at linux-m68k.org  Wed Dec  6 02:56:48 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 6 Dec 2023 11:56:48 +0100
Subject: [PATCH 11/14] arm64: renesas: rzg3s-smarc-som: Invert the logic
 for SW_SD2_EN macro
In-Reply-To: <CAMuHMdUbKe=yiXWNmk5BJFLtF2psx9khiDRGasT9WsnHz4RWsg@mail.gmail.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-12-claudiu.beznea.uj@bp.renesas.com> <CAMuHMdUbKe=yiXWNmk5BJFLtF2psx9khiDRGasT9WsnHz4RWsg@mail.gmail.com>
Message-ID: <CAMuHMdXwSo1L9UuFg9RL0TLL_xzVt2r6QEFc0gtPoydpr4FmSQ@mail.gmail.com>

On Wed, Dec 6, 2023 at 11:33?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Mon, Nov 20, 2023 at 8:03?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> > From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >
> > The intention of SW_SD2_EN macro was to reflect the state of SW_CONFIG3
> > switch available on RZ/G3S Smarc Module. According to documentation SD2
> > is enabled when switch is in OFF state. For this, changed the logic of
> > marco to map value 0 to switch's OFF state and value 1 to switch's ON
> > state. Along with this update the description for each state for better
> > understanding.
> >
> > The value of SW_SD2_EN macro was not changed in file because, according to
> > documentation, the default state for this switch is ON.
> >
> > Fixes: adb4f0c5699c ("arm64: dts: renesas: Add initial support for RZ/G3S SMARC SoM")
> > Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> Thanks for your patch!
>
> > --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> > @@ -14,8 +14,8 @@
> >   *     0 - SD0 is connected to eMMC
> >   *     1 - SD0 is connected to uSD0 card
> >   * @SW_SD2_EN:
> > - *     0 - SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
> > - *     1 - SD2 is connected to SoC
> > + *     0 - (switch OFF) SD2 is connected to SoC
> > + *     1 - (switch ON)  SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
>
> I think this is still confusing: SW_SD2_EN refers to an active-low signal
> (SW_SD2_EN#) in the schematics.

OMG, while the signal is called "SW_SD2_EN#" in the schematics, it is
_not_ active-low!
SW_D2_EN# drives a STG3692 quad SPDT switch, and SD2 is enabled
if SW_D2_EN# is high...

The RZ/G3S SMARC Module User Manual says:

Signal SW_SD2_EN ON: SD2 is disabled.
Signal SW_SD2_EN OFF: SD2 is enabled.

So whatever we do, something will look odd :-(

> Before, SW_SD2_EN used assertion-logic (1 is enabled), and didn't
> match the physical signal level.
> After your patch, SW_SD2_EN matches the active-low physical level, but
> this is not reflected in the name...
>
> >   */
> >  #define SW_SD0_DEV_SEL 1
> >  #define SW_SD2_EN      1
> > @@ -25,7 +25,7 @@ / {
> >
> >         aliases {
> >                 mmc0 = &sdhi0;
> > -#if SW_SD2_EN
> > +#if !SW_SD2_EN
>
> ... so this condition looks really weird.

Still, I think the original looks nicer here.

So I suggest to keep the original logic, but clarify the position of
the switch.
Does that make sense?


>
> >                 mmc2 = &sdhi2;
> >  #endif
> >         };
> > @@ -116,7 +116,7 @@ &sdhi0 {
> >  };
> >  #endif
> >
> > -#if SW_SD2_EN
> > +#if !SW_SD2_EN
> >  &sdhi2 {
> >         pinctrl-0 = <&sdhi2_pins>;
> >         pinctrl-names = "default";
>
> So I think SW_SD2_EN should be renamed to SW_SD2_EN_N.
>
> Cfr. SW_ET0_EN_N on RZ/G2UL:
>
> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * DIP-Switch SW1 setting
> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * 1 : High; 0: Low
> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * SW1-2 :
> SW_SD0_DEV_SEL    (0: uSD; 1: eMMC)
> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * SW1-3 :
> SW_ET0_EN_N               (0: ETHER0; 1: CAN0, CAN1, SSI1, RSPI1)
> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * Please change
> below macros according to SW1 setting on the SoM

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From angelogioacchino.delregno at collabora.com  Wed Dec  6 02:58:18 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 6 Dec 2023 11:58:18 +0100
Subject: [PATCH v3 4/4] clk: mediatek: add drivers for MT7988 SoC
In-Reply-To: <af4c5a230cc65d72987cb531518ae32706d6d95e.1701823757.git.daniel@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
 <af4c5a230cc65d72987cb531518ae32706d6d95e.1701823757.git.daniel@makrotopia.org>
Message-ID: <21d8bd42-ae90-4ab0-88af-31722f6d4886@collabora.com>

Il 06/12/23 01:57, Daniel Golle ha scritto:
> From: Sam Shih <sam.shih at mediatek.com>
> 
> Add APMIXED, ETH, INFRACFG and TOPCKGEN clock drivers which are
> typical MediaTek designs.
> 
> Also add driver for XFIPLL clock generating the 156.25MHz clock for
> the XFI SerDes. It needs an undocumented software workaround and has
> an unknown internal design.
> 
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
> v3: use git --from ...
> v2: no changes
> 
>   drivers/clk/mediatek/Kconfig               |   9 +
>   drivers/clk/mediatek/Makefile              |   5 +
>   drivers/clk/mediatek/clk-mt7988-apmixed.c  | 113 ++++++
>   drivers/clk/mediatek/clk-mt7988-eth.c      | 141 +++++++
>   drivers/clk/mediatek/clk-mt7988-infracfg.c | 378 +++++++++++++++++
>   drivers/clk/mediatek/clk-mt7988-topckgen.c | 446 +++++++++++++++++++++
>   drivers/clk/mediatek/clk-mt7988-xfipll.c   |  79 ++++
>   7 files changed, 1171 insertions(+)
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-apmixed.c
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-eth.c
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-infracfg.c
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-topckgen.c
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-xfipll.c
> 
> diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> index 48b42d11111cd..70a005e7e1b18 100644
> --- a/drivers/clk/mediatek/Kconfig
> +++ b/drivers/clk/mediatek/Kconfig
> @@ -423,6 +423,15 @@ config COMMON_CLK_MT7986_ETHSYS
>   	  This driver adds support for clocks for Ethernet and SGMII
>   	  required on MediaTek MT7986 SoC.
>   
> +config COMMON_CLK_MT7988
> +	tristate "Clock driver for MediaTek MT7988"
> +	depends on ARCH_MEDIATEK || COMPILE_TEST
> +	select COMMON_CLK_MEDIATEK
> +	default ARCH_MEDIATEK
> +	help
> +	  This driver supports MediaTek MT7988 basic clocks and clocks
> +	  required for various periperals found on this SoC.
> +
>   config COMMON_CLK_MT8135
>   	tristate "Clock driver for MediaTek MT8135"
>   	depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index dbeaa5b41177d..eeccfa039896f 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -62,6 +62,11 @@ obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-apmixed.o
>   obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-topckgen.o
>   obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-infracfg.o
>   obj-$(CONFIG_COMMON_CLK_MT7986_ETHSYS) += clk-mt7986-eth.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-apmixed.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-topckgen.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-infracfg.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-eth.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-xfipll.o
>   obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135-apmixedsys.o clk-mt8135.o
>   obj-$(CONFIG_COMMON_CLK_MT8167) += clk-mt8167-apmixedsys.o clk-mt8167.o
>   obj-$(CONFIG_COMMON_CLK_MT8167_AUDSYS) += clk-mt8167-aud.o
> diff --git a/drivers/clk/mediatek/clk-mt7988-apmixed.c b/drivers/clk/mediatek/clk-mt7988-apmixed.c
> new file mode 100644
> index 0000000000000..3f1edc231e37a
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt7988-apmixed.c
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2023 MediaTek Inc.
> + * Author: Sam Shih <sam.shih at mediatek.com>
> + * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include "clk-mtk.h"
> +#include "clk-gate.h"
> +#include "clk-mux.h"
> +#include "clk-pll.h"
> +#include <dt-bindings/clock/mediatek,mt7988-clk.h>
> +
> +#define MT7988_PLL_FMAX (2500UL * MHZ)
> +#define MT7988_PCW_CHG_SHIFT 2
> +
> +#define PLL_xtal(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _rst_bar_mask, \

You're never assigning any div_table, so you don't need to have PLL and PLL_xtal.

Also, why is your crystal named "clkxtal" instead of "clk26m" like all the others?

If your clkxtal is 26MHz, please just change the name to "clk26m" as this is what
is used by most of the other MTK clock drivers, and because the clk26m name does
actually stand for practically the same as your clkxtal, granted that yours is
26M.

> +		 _pcwbits, _pd_reg, _pd_shift, _tuner_reg, _tuner_en_reg,     \
> +		 _tuner_en_bit, _pcw_reg, _pcw_shift, _pcw_chg_reg,           \
> +		 _div_table)                                                  \
> +	{                                                                     \
> +		.id = _id, .name = _name, .reg = _reg, .pwr_reg = _pwr_reg,   \
> +		.en_mask = _en_mask, .flags = _flags,                         \
> +		.rst_bar_mask = BIT(_rst_bar_mask), .fmax = MT7988_PLL_FMAX,  \
> +		.pcwbits = _pcwbits, .pd_reg = _pd_reg,                       \
> +		.pd_shift = _pd_shift, .tuner_reg = _tuner_reg,               \
> +		.tuner_en_reg = _tuner_en_reg, .tuner_en_bit = _tuner_en_bit, \
> +		.pcw_reg = _pcw_reg, .pcw_shift = _pcw_shift,                 \
> +		.pcw_chg_reg = _pcw_chg_reg,                                  \
> +		.pcw_chg_shift = MT7988_PCW_CHG_SHIFT,                        \
> +		.div_table = _div_table, .parent_name = "clkxtal",            \
> +	}
> +

..snip..

> +
> +static const struct of_device_id of_match_clk_mt7988_apmixed[] = {
> +	{ .compatible = "mediatek,mt7988-apmixedsys", },

{ .compatible = "mediatek,mt7988-apmixedsys" },

( there is an extra comma: `sys", }` => `sys" }` )

> +	{ /* sentinel */ }
> +};
> +
> +static int clk_mt7988_apmixed_probe(struct platform_device *pdev)
> +{
> +	struct clk_hw_onecell_data *clk_data;
> +	struct device_node *node = pdev->dev.of_node;
> +	int r;
> +
> +	clk_data = mtk_alloc_clk_data(ARRAY_SIZE(plls));
> +	if (!clk_data)
> +		return -ENOMEM;
> +
> +	mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);

Error checking is missing for mtk_clk_register_plls().

> +
> +	r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
> +	if (r) {
> +		pr_err("%s(): could not register clock provider: %d\n",
> +		       __func__, r);
> +		goto free_apmixed_data;
> +	}
> +	return r;
> +
> +free_apmixed_data:
> +	mtk_free_clk_data(clk_data);
> +	return r;
> +}
> +
> +static struct platform_driver clk_mt7988_apmixed_drv = {
> +	.probe = clk_mt7988_apmixed_probe,
> +	.driver = {
> +		.name = "clk-mt7988-apmixed",
> +		.of_match_table = of_match_clk_mt7988_apmixed,
> +	},
> +};
> +builtin_platform_driver(clk_mt7988_apmixed_drv);
> +MODULE_LICENSE("GPL");

..snip..

> diff --git a/drivers/clk/mediatek/clk-mt7988-infracfg.c b/drivers/clk/mediatek/clk-mt7988-infracfg.c
> new file mode 100644
> index 0000000000000..d23f7bdfafd9d
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt7988-infracfg.c
> @@ -0,0 +1,378 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2023 MediaTek Inc.
> + * Author: Sam Shih <sam.shih at mediatek.com>
> + * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include "clk-mtk.h"
> +#include "clk-gate.h"
> +#include "clk-mux.h"
> +#include <dt-bindings/clock/mediatek,mt7988-clk.h>
> +
> +static DEFINE_SPINLOCK(mt7988_clk_lock);
> +
> +static const char *const infra_mux_uart0_parents[] __initconst = {

Are you sure that you need those __initconst annotations?

> +	"csw_infra_f26m_sel", "uart_sel"
> +};
> +

..snip..

> +
> +static const struct mtk_gate_regs infra0_cg_regs = {
> +	.set_ofs = 0x10,
> +	.clr_ofs = 0x14,
> +	.sta_ofs = 0x18,
> +};
> +
> +static const struct mtk_gate_regs infra1_cg_regs = {
> +	.set_ofs = 0x40,
> +	.clr_ofs = 0x44,
> +	.sta_ofs = 0x48,
> +};
> +
> +static const struct mtk_gate_regs infra2_cg_regs = {
> +	.set_ofs = 0x50,
> +	.clr_ofs = 0x54,
> +	.sta_ofs = 0x58,
> +};
> +
> +static const struct mtk_gate_regs infra3_cg_regs = {
> +	.set_ofs = 0x60,
> +	.clr_ofs = 0x64,
> +	.sta_ofs = 0x68,
> +};
> +
> +#define GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, _flags)			\

This is exactly the definition of GATE_MTK_FLAGS.
Use that common definition instead.

> +	{									\
> +		.id = _id, .name = _name, .parent_name = _parent,		\
> +		.regs = &infra0_cg_regs, .shift = _shift,			\
> +		.ops = &mtk_clk_gate_ops_setclr, .flags = _flags,		\
> +	}
> +
> +#define GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, _flags)			\

same

> +	{									\
> +		.id = _id, .name = _name, .parent_name = _parent,		\
> +		.regs = &infra1_cg_regs, .shift = _shift,			\
> +		.ops = &mtk_clk_gate_ops_setclr, .flags = _flags,		\
> +	}
> +
> +#define GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, _flags)			\

same again

> +	{									\
> +		.id = _id, .name = _name, .parent_name = _parent,		\
> +		.regs = &infra2_cg_regs, .shift = _shift,			\
> +		.ops = &mtk_clk_gate_ops_setclr, .flags = _flags,		\
> +	}
> +
> +#define GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, _flags)			\

and again.

> +	{									\
> +		.id = _id, .name = _name, .parent_name = _parent,		\
> +		.regs = &infra3_cg_regs, .shift = _shift,			\
> +		.ops = &mtk_clk_gate_ops_setclr, .flags = _flags,		\
> +	}
> +

#define GATE_INFRA0(_id, _name, _parent, _shift)			\
	GATE_MTK_FLAGS(_id, _name, _parent, &infra0_cg_regs, _shift,	\
		&mtk_clk_gate_ops_setclr, 0)

#define GATE_INFRA1(_id, _name, _parent, _shift)			\
	GATE_MTK_FLAGS(_id, _name, _parent, &infra1_cg_regs, _shift,	\
		&mtk_clk_gate_ops_setclr, 0)

#define GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, _flags)		\
	GATE_MTK_FLAGS(_id, _name, _parent, &infra2_cg_regs, _shift,	\
		&mtk_clk_gate_ops_setclr, _flags)

#define GATE_INFRA2(_id, _name, _parent, _shift)			\
	GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, 0)

#define GATE_INFRA3(_id, _name, _parent, _shift)			\
	GATE_MTK_FLAGS(_id, _name, _parent, &infra0_cg_regs, _shift,	\
		&mtk_clk_gate_ops_setclr, 0)

> +#define GATE_INFRA0(_id, _name, _parent, _shift)				\
> +	GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, 0)
> +
> +#define GATE_INFRA1(_id, _name, _parent, _shift)				\
> +	GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, 0)
> +
> +#define GATE_INFRA2(_id, _name, _parent, _shift)				\
> +	GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, 0)
> +
> +#define GATE_INFRA3(_id, _name, _parent, _shift)				\
> +	GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, 0)
> +
> +
> +#define GATE_CRITICAL(_id, _name, _parent, _regs, _shift)			\


You are using it like that:
GATE_CRITICAL(CLK_INFRA_RTC, "infra_f_frtc", "top_rtc_32k", &infra2_cg_regs, 19),

Change it to
GATE_INFRA2_FLAGS(CLK_INFRA_RTC, "infra_f_frtc", "top_rtc_32k", 19),

> +	{									\
> +		.id = _id, .name = _name, .parent_name = _parent,		\
> +		.regs = _regs, .shift = _shift,					\
> +		.flags = CLK_IS_CRITICAL,					\
> +		.ops = &mtk_clk_gate_ops_setclr,				\
> +	}
> +
> +static const struct mtk_gate infra_clks[] = {
> +	/* INFRA0 */
> +	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P0,
> +		    "infra_pcie_peri_ck_26m_ck_p0", "csw_infra_f26m_sel", 7),
> +	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P1,
> +		    "infra_pcie_peri_ck_26m_ck_p1", "csw_infra_f26m_sel", 8),
> +	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P2,
> +		    "infra_pcie_peri_ck_26m_ck_p2", "csw_infra_f26m_sel", 9),
> +	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P3,
> +		    "infra_pcie_peri_ck_26m_ck_p3", "csw_infra_f26m_sel", 10),
> +	/* INFRA1 */
> +	GATE_INFRA1(CLK_INFRA_66M_GPT_BCK, "infra_hf_66m_gpt_bck",
> +		    "sysaxi_sel", 0),

This one and multiple other entries do fit in one line.

Up to 100 columns is ok: please use one line where possible, here and in the other
drivers as well, where this comment applies.

> +	GATE_INFRA1(CLK_INFRA_66M_PWM_HCK, "infra_hf_66m_pwm_hck",
> +		    "sysaxi_sel", 1),

..snip..


> diff --git a/drivers/clk/mediatek/clk-mt7988-topckgen.c b/drivers/clk/mediatek/clk-mt7988-topckgen.c
> new file mode 100644
> index 0000000000000..7bed282e615f8
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt7988-topckgen.c
> @@ -0,0 +1,446 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2023 MediaTek Inc.
> + * Author: Sam Shih <sam.shih at mediatek.com>
> + * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include "clk-mtk.h"
> +#include "clk-gate.h"
> +#include "clk-mux.h"
> +#include <dt-bindings/clock/mediatek,mt7988-clk.h>
> +
> +static DEFINE_SPINLOCK(mt7988_clk_lock);
> +
> +static const struct mtk_fixed_clk top_fixed_clks[] = {
> +	FIXED_CLK(CLK_TOP_XTAL, "top_xtal", "clkxtal", 40000000),

Again, why clkxtal and not clk26m?

> +};
> +
> +static const struct mtk_fixed_factor top_divs[] = {
> +	FACTOR(CLK_TOP_XTAL_D2, "top_xtal_d2", "top_xtal", 1, 2),
> +	FACTOR(CLK_TOP_RTC_32K, "top_rtc_32k", "top_xtal", 1, 1250),
> +	FACTOR(CLK_TOP_RTC_32P7K, "top_rtc_32p7k", "top_xtal", 1, 1220),
> +	FACTOR(CLK_TOP_MPLL_D2, "mpll_d2", "mpll", 1, 2),
> +	FACTOR(CLK_TOP_MPLL_D3_D2, "mpll_d3_d2", "mpll", 1, 2),
> +	FACTOR(CLK_TOP_MPLL_D4, "mpll_d4", "mpll", 1, 4),
> +	FACTOR(CLK_TOP_MPLL_D8, "mpll_d8", "mpll", 1, 8),
> +	FACTOR(CLK_TOP_MPLL_D8_D2, "mpll_d8_d2", "mpll", 1, 16),
> +	FACTOR(CLK_TOP_MMPLL_D2, "mmpll_d2", "mmpll", 1, 2),
> +	FACTOR(CLK_TOP_MMPLL_D3_D5, "mmpll_d3_d5", "mmpll", 1, 15),
> +	FACTOR(CLK_TOP_MMPLL_D4, "mmpll_d4", "mmpll", 1, 4),
> +	FACTOR(CLK_TOP_MMPLL_D6_D2, "mmpll_d6_d2", "mmpll", 1, 12),
> +	FACTOR(CLK_TOP_MMPLL_D8, "mmpll_d8", "mmpll", 1, 8),
> +	FACTOR(CLK_TOP_APLL2_D4, "apll2_d4", "apll2", 1, 4),
> +	FACTOR(CLK_TOP_NET1PLL_D4, "net1pll_d4", "net1pll", 1, 4),
> +	FACTOR(CLK_TOP_NET1PLL_D5, "net1pll_d5", "net1pll", 1, 5),
> +	FACTOR(CLK_TOP_NET1PLL_D5_D2, "net1pll_d5_d2", "net1pll", 1, 10),
> +	FACTOR(CLK_TOP_NET1PLL_D5_D4, "net1pll_d5_d4", "net1pll", 1, 20),
> +	FACTOR(CLK_TOP_NET1PLL_D8, "net1pll_d8", "net1pll", 1, 8),
> +	FACTOR(CLK_TOP_NET1PLL_D8_D2, "net1pll_d8_d2", "net1pll", 1, 16),
> +	FACTOR(CLK_TOP_NET1PLL_D8_D4, "net1pll_d8_d4", "net1pll", 1, 32),
> +	FACTOR(CLK_TOP_NET1PLL_D8_D8, "net1pll_d8_d8", "net1pll", 1, 64),
> +	FACTOR(CLK_TOP_NET1PLL_D8_D16, "net1pll_d8_d16", "net1pll", 1, 128),
> +	FACTOR(CLK_TOP_NET2PLL_D2, "net2pll_d2", "net2pll", 1, 2),
> +	FACTOR(CLK_TOP_NET2PLL_D4, "net2pll_d4", "net2pll", 1, 4),
> +	FACTOR(CLK_TOP_NET2PLL_D4_D4, "net2pll_d4_d4", "net2pll", 1, 16),
> +	FACTOR(CLK_TOP_NET2PLL_D4_D8, "net2pll_d4_d8", "net2pll", 1, 32),
> +	FACTOR(CLK_TOP_NET2PLL_D6, "net2pll_d6", "net2pll", 1, 6),
> +	FACTOR(CLK_TOP_NET2PLL_D8, "net2pll_d8", "net2pll", 1, 8),
> +};
> +
> +static const char *const netsys_parents[] = { "top_xtal", "net2pll_d2",
> +					      "mmpll_d2" };

Fits in one line as well: please fix, here and everywhere else.

> +
> +static const char *const netsys_500m_parents[] = { "top_xtal", "net1pll_d5",
> +						   "net1pll_d5_d2" };
> +

..snip..

> diff --git a/drivers/clk/mediatek/clk-mt7988-xfipll.c b/drivers/clk/mediatek/clk-mt7988-xfipll.c
> new file mode 100644
> index 0000000000000..5862818085a8c
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt7988-xfipll.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include "clk-mtk.h"
> +#include "clk-gate.h"
> +#include <dt-bindings/clock/mediatek,mt7988-clk.h>
> +
> +/* Register to control USXGMII XFI PLL analog */
> +#define XFI_PLL_ANA_GLB8		0x108
> +#define RG_XFI_PLL_ANA_SWWA		0x02283248
> +
> +static const struct mtk_gate_regs xfipll_cg_regs = {
> +	.set_ofs = 0x8,
> +	.clr_ofs = 0x8,
> +	.sta_ofs = 0x8,
> +};
> +
> +#define GATE_XFIPLL(_id, _name, _parent, _shift)                              \
> +	{                                                                     \
> +		.id = _id, .name = _name, .parent_name = _parent,             \
> +		.regs = &xfipll_cg_regs, .shift = _shift,                     \
> +		.ops = &mtk_clk_gate_ops_no_setclr_inv,                       \
> +	}
> +
> +static const struct mtk_fixed_factor xfipll_divs[] = {
> +	FACTOR(CLK_XFIPLL_PLL, "xfipll_pll", "top_xtal", 125, 32),
> +};
> +
> +static const struct mtk_gate xfipll_clks[] = {
> +	GATE_XFIPLL(CLK_XFIPLL_PLL_EN, "xfipll_pll_en", "xfipll_pll", 31),
> +};
> +
> +static const struct mtk_clk_desc xfipll_desc = {
> +	.clks = xfipll_clks,
> +	.num_clks = ARRAY_SIZE(xfipll_clks),
> +	.factor_clks = xfipll_divs,
> +	.num_factor_clks = ARRAY_SIZE(xfipll_divs),
> +};
> +
> +static int clk_mt7988_xfipll_probe(struct platform_device *pdev)
> +{
> +	struct device_node *node = pdev->dev.of_node;
> +	void __iomem *base = of_iomap(node, 0);
> +
> +	if (!base)
> +		return -ENOMEM;
> +
> +	/* Apply software workaround for USXGMII PLL TCL issue */?

This hurts my heart... :-P
but it's ok :-)

Cheers,
Angelo


From hverkuil at xs4all.nl  Wed Dec  6 02:59:30 2023
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Wed, 6 Dec 2023 11:59:30 +0100
Subject: [PATCH v9 5/5] MAINTAINERS: Add entries for Toshiba Visconti
 Video Input Interface
In-Reply-To: <TYAPR01MB62015CB80317567D6F9C4A5E92BDA@TYAPR01MB6201.jpnprd01.prod.outlook.com>
References: <20231012071329.2542003-1-yuji2.ishikawa@toshiba.co.jp>
 <20231012071329.2542003-6-yuji2.ishikawa@toshiba.co.jp>
 <767e3297-e1f9-483d-870e-67e75048b91a@xs4all.nl>
 <TYAPR01MB62015CB80317567D6F9C4A5E92BDA@TYAPR01MB6201.jpnprd01.prod.outlook.com>
Message-ID: <cae19173-1b36-4300-b770-782a7b7c2200@xs4all.nl>

On 27/11/2023 01:38, yuji2.ishikawa at toshiba.co.jp wrote:
> Hello Hans,
> Thank you for the review.
> 
>> -----Original Message-----
>> From: Hans Verkuil <hverkuil at xs4all.nl>
>> Sent: Tuesday, November 14, 2023 5:41 PM
>> To: ishikawa yuji(?? ?? ?????????????)
>> <yuji2.ishikawa at toshiba.co.jp>; Laurent Pinchart
>> <laurent.pinchart at ideasonboard.com>; Mauro Carvalho Chehab
>> <mchehab at kernel.org>; Rob Herring <robh+dt at kernel.org>; Krzysztof
>> Kozlowski <krzysztof.kozlowski+dt at linaro.org>; Conor Dooley
>> <conor+dt at kernel.org>; iwamatsu nobuhiro(?? ?? ??????????
>> ???) <nobuhiro1.iwamatsu at toshiba.co.jp>
>> Cc: linux-media at vger.kernel.org; devicetree at vger.kernel.org;
>> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org
>> Subject: Re: [PATCH v9 5/5] MAINTAINERS: Add entries for Toshiba Visconti
>> Video Input Interface
>>
>> On 12/10/2023 09:13, Yuji Ishikawa wrote:
>>> Added entries for visconti Video Input Interface driver, including;
>>> * device tree bindings
>>> * source files
>>> * documentation files
>>>
>>> Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
>>> ---
>>> Changelog v2:
>>> - no change
>>>
>>> Changelog v3:
>>> - added entry for driver API documentation
>>>
>>> Changelog v4:
>>> - added entry for header file
>>>
>>> Changelog v5:
>>> - no change
>>>
>>> Changelog v6:
>>> - update path to VIIF driver source files
>>>
>>> Changelog v7:
>>> - no change
>>>
>>> Changelog v8:
>>> - rename bindings description file
>>>
>>> Changelog v9:
>>> - no change
>>>
>>>  MAINTAINERS | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS index
>>> eaa1a28a9d54..6035f711b3fb 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -2902,17 +2902,21 @@ F:
>> 	Documentation/devicetree/bindings/arm/toshiba.yaml
>>>  F:
>> 	Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.y
>> aml
>>>  F:
>> 	Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.y
>> aml
>>>  F:	Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
>>> +F:
>> 	Documentation/devicetree/bindings/media/toshiba,visconti5-viif.yam
>> l
>>>  F:
>> 	Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.ya
>> ml
>>>  F:	Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
>>>  F:
>> 	Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.y
>> aml
>>>  F:
>> 	Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.
>> yaml
>>> +F:	Documentation/driver-api/media/drivers/visconti-viif.rst
>>>  F:	arch/arm64/boot/dts/toshiba/
>>>  F:	drivers/clk/visconti/
>>>  F:	drivers/gpio/gpio-visconti.c
>>> +F:	drivers/media/platform/toshiba/visconti/
>>>  F:	drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
>>>  F:	drivers/pci/controller/dwc/pcie-visconti.c
>>>  F:	drivers/pinctrl/visconti/
>>>  F:	drivers/watchdog/visconti_wdt.c
>>> +F:	include/uapi/linux/visconti_viif.h
>>>  N:	visconti
>>
>> This is a bit odd: it adds the driver to an existing entry, but you do not add
>> yourself as maintainer. Typically a large driver like this one will have its own
>> entry.
>>
>> At minimum I need an Acked-by from Nobuhiro Iwamatsu for this change. But I
>> think it might be better to make a separate entry for this driver. Up to you,
>> though.
> 
> I'll make a separate entry for Visconti VIIF driver.
> I talked it over with Iwamatsu-san and he agreed.
> I need Acked-by tag from him at v10 patch submission; is it a correct understanding?

Yes, that's correct.

Regards,

	Hans

> 
>>
>> Regards,
>>
>> 	Hans
>>
>>>
>>>  ARM/UNIPHIER ARCHITECTURE
> 
> Regards,
> Yuji



From angelogioacchino.delregno at collabora.com  Wed Dec  6 02:59:54 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 6 Dec 2023 11:59:54 +0100
Subject: [PATCH v3 2/4] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <def05aac79ddff872d3e56698b736cb445f14116.1701823757.git.daniel@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
 <def05aac79ddff872d3e56698b736cb445f14116.1701823757.git.daniel@makrotopia.org>
Message-ID: <3e72bff6-9f4d-4cd4-845e-b065f1233ec6@collabora.com>

Il 06/12/23 01:57, Daniel Golle ha scritto:
> Add various clock controllers found in the MT7988 SoC to existing
> bindings (if applicable) and add files for the new ethwarp, mcusys
> and xfi-pll clock controllers not previously present in any SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
> v3:
>   * move clock bindings to clock folder
>   * drop ti,syscon-reset from bindings and example
>   * merge mcusys with topckgen bindings
> 
> v2:
>   * dropped unused labels
>   * add 'type: object' declaration for reset-controller found in new
>     ethwarp controller and represented as ti,syscon-reset
>   * rebase on top of
>     "dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema"
> 
>   .../arm/mediatek/mediatek,infracfg.yaml       |  1 +
>   .../bindings/clock/mediatek,apmixedsys.yaml   |  1 +
>   .../bindings/clock/mediatek,ethsys.yaml       |  1 +
>   .../clock/mediatek,mt7988-ethwarp.yaml        | 49 +++++++++++++++++++
>   .../clock/mediatek,mt7988-xfi-pll.yaml        | 48 ++++++++++++++++++
>   .../bindings/clock/mediatek,topckgen.yaml     |  2 +
>   .../bindings/net/pcs/mediatek,sgmiisys.yaml   | 13 +++--
>   7 files changed, 112 insertions(+), 3 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
>   create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
> index ea98043c6ba3d..230b5188a88db 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
> @@ -30,6 +30,7 @@ properties:
>                 - mediatek,mt7629-infracfg
>                 - mediatek,mt7981-infracfg
>                 - mediatek,mt7986-infracfg
> +              - mediatek,mt7988-infracfg
>                 - mediatek,mt8135-infracfg
>                 - mediatek,mt8167-infracfg
>                 - mediatek,mt8173-infracfg
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
> index 372c1d744bc27..685535846cbb7 100644
> --- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
> +++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
> @@ -22,6 +22,7 @@ properties:
>             - mediatek,mt7622-apmixedsys
>             - mediatek,mt7981-apmixedsys
>             - mediatek,mt7986-apmixedsys
> +          - mediatek,mt7988-apmixedsys
>             - mediatek,mt8135-apmixedsys
>             - mediatek,mt8173-apmixedsys
>             - mediatek,mt8516-apmixedsys
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
> index 94d42c8647777..f9cddacc2eae1 100644
> --- a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
> +++ b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
> @@ -22,6 +22,7 @@ properties:
>                 - mediatek,mt7629-ethsys
>                 - mediatek,mt7981-ethsys
>                 - mediatek,mt7986-ethsys
> +              - mediatek,mt7988-ethsys
>             - const: syscon
>         - items:
>             - const: mediatek,mt7623-ethsys
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
> new file mode 100644
> index 0000000000000..9b919a155eb13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-ethwarp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT7988 ethwarp Controller
> +
> +maintainers:
> +  - Daniel Golle <daniel at makrotopia.org>
> +
> +description:
> +  The Mediatek MT7988 ethwarp controller provides clocks and resets for the
> +  Ethernet related subsystems found the MT7988 SoC.
> +  The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: mediatek,mt7988-ethwarp
> +      - const: syscon
> +      - const: simple-mfd

No, this is not a mfd, I say.

Prove me wrong! :-)

..snip..

> diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
> index 66a95191bd776..68632cda334bd 100644
> --- a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
> +++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
> @@ -15,15 +15,22 @@ description:
>   
>   properties:
>     compatible:
> -    items:
> -      - enum:
> +    oneOf:
> +      - items:
> +        - enum:
>             - mediatek,mt7622-sgmiisys
>             - mediatek,mt7629-sgmiisys
>             - mediatek,mt7981-sgmiisys_0
>             - mediatek,mt7981-sgmiisys_1
>             - mediatek,mt7986-sgmiisys_0
>             - mediatek,mt7986-sgmiisys_1
> -      - const: syscon
> +        - const: syscon
> +      - items:
> +        - enum:
> +          - mediatek,mt7988-sgmiisys_0
> +          - mediatek,mt7988-sgmiisys_1
> +        - const: syscon
> +        - const: simple-mfd

Same.

Cheers,
Angelo


From geert at linux-m68k.org  Wed Dec  6 03:03:14 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 6 Dec 2023 12:03:14 +0100
Subject: [PATCH 12/14] arm64: dts: renesas: Improve documentation for SW_SD0_DEV_SEL
In-Reply-To: <20231120070024.4079344-13-claudiu.beznea.uj@bp.renesas.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com> <20231120070024.4079344-13-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdWa9wSDfwrz=WSpa9S16BnMCJHdEiJSNFB2m8gr_p8z9g@mail.gmail.com>

Hi Claudiu,

On Mon, Nov 20, 2023 at 8:03?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> Add switch OFF/OFF description to values of SW_SD0_DEV_SEL for
> better understanding.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> @@ -11,8 +11,8 @@
>  /*
>   * Signals of SW_CONFIG switches:
>   * @SW_SD0_DEV_SEL:
> - *     0 - SD0 is connected to eMMC
> - *     1 - SD0 is connected to uSD0 card
> + *     0 - (switch OFF) SD0 is connected to eMMC
> + *     1 - (switch ON)  SD0 is connected to uSD0 card
>   * @SW_SD2_EN:
>   *     0 - (switch OFF) SD2 is connected to SoC
>   *     1 - (switch ON)  SCIF1, SSI0, IRQ0, IRQ1 connected to SoC

I guess this makes sense
Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From hverkuil at xs4all.nl  Wed Dec  6 03:03:32 2023
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Wed, 6 Dec 2023 12:03:32 +0100
Subject: [PATCH v9 3/5] media: platform: visconti: add V4L2 vendor
 specific control handlers
In-Reply-To: <TYAPR01MB62013046647975761414115992BDA@TYAPR01MB6201.jpnprd01.prod.outlook.com>
References: <20231012071329.2542003-1-yuji2.ishikawa@toshiba.co.jp>
 <20231012071329.2542003-4-yuji2.ishikawa@toshiba.co.jp>
 <6095bd3d-2580-44e2-b622-3ad31e12787f@xs4all.nl>
 <a84ce942-e6df-414e-8d0c-e7d3ef3e62f6@xs4all.nl>
 <TYAPR01MB62013046647975761414115992BDA@TYAPR01MB6201.jpnprd01.prod.outlook.com>
Message-ID: <178d5426-9761-4790-a488-a0009b0c9ba0@xs4all.nl>

On 27/11/2023 01:45, yuji2.ishikawa at toshiba.co.jp wrote:
> Hello Hans,
> 
>> -----Original Message-----
>> From: Hans Verkuil <hverkuil at xs4all.nl>
>> Sent: Tuesday, November 14, 2023 6:11 PM
>> To: ishikawa yuji(?? ?? ?????????????)
>> <yuji2.ishikawa at toshiba.co.jp>; Laurent Pinchart
>> <laurent.pinchart at ideasonboard.com>; Mauro Carvalho Chehab
>> <mchehab at kernel.org>; Rob Herring <robh+dt at kernel.org>; Krzysztof
>> Kozlowski <krzysztof.kozlowski+dt at linaro.org>; Conor Dooley
>> <conor+dt at kernel.org>; iwamatsu nobuhiro(?? ?? ??????????
>> ???) <nobuhiro1.iwamatsu at toshiba.co.jp>
>> Cc: linux-media at vger.kernel.org; devicetree at vger.kernel.org;
>> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org
>> Subject: Re: [PATCH v9 3/5] media: platform: visconti: add V4L2 vendor
>> specific control handlers
>>
>> On 14/11/2023 10:02, Hans Verkuil wrote:
>>> On 12/10/2023 09:13, Yuji Ishikawa wrote:
>>>> Add support to Image Signal Processors of Visconti's Video Input Interface.
>>>> This patch adds vendor specific compound controls to configure the
>>>> image signal processor.
>>>>
>>>> Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
>>>> ---
>>>> Changelog v2:
>>>> - Resend v1 because a patch exceeds size limit.
>>>>
>>>> Changelog v3:
>>>> - Adapted to media control framework
>>>> - Introduced ISP subdevice, capture device
>>>> - Remove private IOCTLs and add vendor specific V4L2 controls
>>>> - Change function name avoiding camelcase and uppercase letters
>>>>
>>>> Changelog v4:
>>>> - Split patches because the v3 patch exceeds size limit
>>>> - Stop using ID number to identify driver instance:
>>>>   - Use dynamically allocated structure to hold HW specific context,
>>>>     instead of static one.
>>>>   - Call HW layer functions with the context structure instead of ID
>>>> number
>>>>
>>>> Changelog v5:
>>>> - no change
>>>>
>>>> Changelog v6:
>>>> - remove unused macros
>>>> - removed hwd_ and HWD_ prefix
>>>> - update source code documentation
>>>> - Suggestion from Hans Verkuil
>>>>   - pointer to userland memory is removed from uAPI arguments
>>>>     - style of structure is now "nested" instead of "chained by pointer";
>>>>   - use div64_u64 for 64bit division
>>>>   - vendor specific controls support TRY_EXT_CTRLS
>>>>   - add READ_ONLY flag to GET_CALIBRATION_STATUS control and
>> similar ones
>>>>   - human friendry control names for vendor specific controls
>>>>   - add initial value to each vendor specific control
>>>>   - GET_LAST_CAPTURE_STATUS control is updated asyncnously from
>> workqueue
>>>>   - remove EXECUTE_ON_WRITE flag of vendor specific control
>>>>   - uAPI: return value of GET_CALIBRATION_STATUS follows common
>> rules of error codes
>>>>   - applied v4l2-compliance
>>>> - Suggestion from Sakari Ailus
>>>>   - use div64_u64 for 64bit division
>>>>   - update copyright's year
>>>>   - remove redandunt cast
>>>>   - use bool instead of HWD_VIIF_ENABLE/DISABLE
>>>>   - simplify comparison to 0
>>>>   - simplify statements with trigram operator
>>>>   - remove redundant local variables
>>>>   - use general integer types instead of u32/s32
>>>> - Suggestion from Laurent Pinchart
>>>>   - moved VIIF driver to driver/platform/toshiba/visconti
>>>>   - change register access: struct-style to macro-style
>>>>   - remove unused type definitions
>>>>   - define enums instead of successive macro constants
>>>>   - remove redundant parenthesis of macro constant
>>>>   - embed struct hwd_res into struct viif_device
>>>>   - use xxx_dma instead of xxx_paddr for variable names of IOVA
>>>>   - literal value: just 0 instead of 0x0
>>>>   - use literal 1 or 0 instead of HWD_VIIF_ENABLE, DISABLE for register
>> access
>>>>   - use true or false instead of HWD_VIIF_ENABLE, DISABLE for function
>> calls
>>>>   - uAPI: return value of GET_CALIBRATION_STATUS follows common
>> rules
>>>> of error codes
>>>>
>>>> Changelog v7:
>>>> - remove unused variables
>>>> - split long statements which have multiple logical-OR and trigram
>>>> operators
>>>>
>>>> Changelog v8:
>>>> - define constant V4L2_CTRL_TYPE_VISCONTI_ISP for datatype
>>>>   of Visconti specific controls
>>>> - Suggestion from Hans Verkuil
>>>>   - remove pr_info()
>>>>   - use pm_runtime_get_if_in_use() to get power status
>>>>
>>>> Changelog v9:
>>>> - fix warning for cast between ptr and dma_addr_t
>>>>
>>>>  .../media/platform/toshiba/visconti/Makefile  |    2 +-
>>>>  .../media/platform/toshiba/visconti/viif.c    |   10 +-
>>>>  .../platform/toshiba/visconti/viif_controls.c | 3395
>> +++++++++++++++++
>>>>  .../platform/toshiba/visconti/viif_controls.h |   18 +
>>>>  .../platform/toshiba/visconti/viif_isp.c      |   15 +-
>>>>  drivers/media/v4l2-core/v4l2-ctrls-core.c     |    7 +-
>>>>  include/uapi/linux/videodev2.h                |    2 +
>>>>  7 files changed, 3431 insertions(+), 18 deletions(-)  create mode
>>>> 100644 drivers/media/platform/toshiba/visconti/viif_controls.c
>>>>  create mode 100644
>>>> drivers/media/platform/toshiba/visconti/viif_controls.h
>>>>
>>>
>>> <snip>
>>>
>>> These core changes below should be in a separate patch, not mixed in
>>> with the driver.
>>>
>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c
>>>> b/drivers/media/v4l2-core/v4l2-ctrls-core.c
>>>> index a662fb60f73f..0c4df9fffbe0 100644
>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-core.c
>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-core.c
>>>> @@ -367,7 +367,9 @@ void v4l2_ctrl_type_op_log(const struct v4l2_ctrl
>> *ctrl)
>>>>  	case V4L2_CTRL_TYPE_AV1_FILM_GRAIN:
>>>>  		pr_cont("AV1_FILM_GRAIN");
>>>>  		break;
>>>> -
>>>> +	case V4L2_CTRL_TYPE_VISCONTI_ISP:
>>>> +		pr_cont("VISCONTI_ISP");
>>>> +		break;
>>>>  	default:
>>>>  		pr_cont("unknown type %d", ctrl->type);
>>>>  		break;
>>>> @@ -1163,6 +1165,9 @@ static int std_validate_compound(const struct
>> v4l2_ctrl *ctrl, u32 idx,
>>>>  	case V4L2_CTRL_TYPE_AV1_FILM_GRAIN:
>>>>  		return validate_av1_film_grain(p);
>>>>
>>>> +	case V4L2_CTRL_TYPE_VISCONTI_ISP:
>>>> +		break;
>>>> +
>>>>  	case V4L2_CTRL_TYPE_AREA:
>>>>  		area = p;
>>>>  		if (!area->width || !area->height) diff --git
>>>> a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>>>> index c3d4e490ce7c..bbc3cd3efa65 100644
>>>> --- a/include/uapi/linux/videodev2.h
>>>> +++ b/include/uapi/linux/videodev2.h
>>>> @@ -1915,6 +1915,8 @@ enum v4l2_ctrl_type {
>>>>  	V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY = 0x281,
>>>>  	V4L2_CTRL_TYPE_AV1_FRAME	    = 0x282,
>>>>  	V4L2_CTRL_TYPE_AV1_FILM_GRAIN	    = 0x283,
>>>> +
>>>> +	V4L2_CTRL_TYPE_VISCONTI_ISP = 0x290,
>>>
>>> I see you are using the same V4L2_CTRL_TYPE_VISCONTI_ISP for all the
>>> compound controls. But that's not allowed: the V4L2_CTRL_TYPE_ defines
>>> determine the control type, so each struct used by a control needs its own
>> type.
>>
>> Actually, you don't want to add such a type at all. This is all driver specific, so
>> support like this belongs in the driver.
>>
>> A good example of that is
>> V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP in
>> drivers/media/platform/nxp/dw100/dw100.c: there all the handling is done in
>> the driver, and it adds init/validate/log/equal ops as well.
> 
> I checked drivers/media/platform/nxp/dw100/dw100.c and found that
> V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP handles a 2D array of U32 parameters,
> which is covered by standard v4l2_ctrl_type_op_xxxx() APIs.
> 
> I suppose that controls of the VIIF driver, which handle control specific structs,
> would not be implemented in the same way and something else may be needed.

The key takeaway here is that you don't want to have to add support for a
driver-specific type to the core control framework. It has to remain
driver specific. In this case that means you need to provide your own
custom type ops in the driver, just like dw100 does. The actual code there
will of course be different, since you are dealing with a compound type,
not an array. But the principle is the same.

Regards,

	Hans

> 
>> Regards,
>>
>> 	Hans
>>
>>>
>>> I also noticed looking through include/uapi/linux/visconti_viif.h that
>>> some of the struct have holes. I really want to avoid holes in structs
>>> used by controls, it is bad practice.
>>>
>>> The pahole utility is very useful for testing this. It is also highly
>>> recommended to check for both 32 and 64 bit compilation: the struct
>>> layout must be the same, otherwise you would run into problems if a 32
>>> bit application is used with a 64 bit kernel.
>>>
>>> Finally, Laurent and/or Sakari will also take a look at this driver,
>>> for some reason this driver has been mostly reviewed by me, but I am
>>> not really the expert on ISPs.
>>>
>>> Regards,
>>>
>>> 	Hans
>>>
>>>>  };
>>>>
>>>>  /*  Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
>>>
>>>
> 
> Regards,
> Yuji



From quic_nitirawa at quicinc.com  Wed Dec  6 03:05:24 2023
From: quic_nitirawa at quicinc.com (Nitin Rawat)
Date: Wed, 6 Dec 2023 16:35:24 +0530
Subject: [PATCH V1] scsi: ufs: core: store min and max clk freq from OPP
 table
In-Reply-To: <20231206075447.GA4954@thinkpad>
References: <20231206053628.32169-1-quic_nitirawa@quicinc.com>
 <20231206075447.GA4954@thinkpad>
Message-ID: <f30d3c21-f355-d535-480b-2fd36167bcfd@quicinc.com>



On 12/6/2023 1:24 PM, Manivannan Sadhasivam wrote:
> On Wed, Dec 06, 2023 at 11:06:28AM +0530, Nitin Rawat wrote:
>> OPP support will make use of OPP table in device tree and removes
>> freq-table-hz property from device tree.
>>
>> With OPP enabled in devicetree, clki->min_freq and clki->maxfreq
>> currently is not getting updated and the value is set to 0.
>>
>> Soc vendors like qcom, mediatek uses clki->minfreq and clki->maxfreq
>> in vendor specific file. These frequencies values are used to update
>> vendor specific configurations. Since the value is 0, it is causing
>> functional issue.
> 
> How about,
> 
> "OPP support added by commit 72208ebe181e ("scsi: ufs: core: Add support
> for parsing OPP") doesn't update the min_freq and max_freq of each clocks
> in 'struct ufs_clk_info'.
> 
> But these values are used by the vendor host drivers internally for controller
> configuration. When the OPP support is enabled in devicetree, these values will
> be 0, causing boot issues on the respective platforms.
> 
> So let's parse the min_freq and max_freq of all clocks while parsing the OPP
> table."
> 
>>
>> Add code to store the min and max ufs clk frequency from OPP table.

Sure. Will update in next patchset.

>>
>> Fixes: 72208ebe181e ("scsi: ufs: core: Add support for parsing OPP")
>> Co-developed-by: Manish Pandey <quic_mapa at quicinc.com>
>> Signed-off-by: Manish Pandey <quic_mapa at quicinc.com>
>> Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
>> ---
>>   drivers/ufs/host/ufshcd-pltfrm.c | 56 ++++++++++++++++++++++++++++++++
>>   1 file changed, 56 insertions(+)
>>
>> diff --git a/drivers/ufs/host/ufshcd-pltfrm.c b/drivers/ufs/host/ufshcd-pltfrm.c
>> index da2558e274b4..12fa6f7d6a97 100644
>> --- a/drivers/ufs/host/ufshcd-pltfrm.c
>> +++ b/drivers/ufs/host/ufshcd-pltfrm.c
>> @@ -13,6 +13,7 @@
>>   #include <linux/pm_opp.h>
>>   #include <linux/pm_runtime.h>
>>   #include <linux/of.h>
>> +#include <linux/clk.h>
> 
> Sort includes alphabetically.

Sure. Will update in next patchset

> 
>>
>>   #include <ufs/ufshcd.h>
>>   #include "ufshcd-pltfrm.h"
>> @@ -213,6 +214,55 @@ static void ufshcd_init_lanes_per_dir(struct ufs_hba *hba)
>>   	}
>>   }
>>
>> +/**
>> + * ufshcd_config_min_max_clk_freq - update min and max freq
> 
> "ufshcd_parse_clock_min_max_freq - Parse MIN and MAX frequencies of clocks"
> 
>> + * @hba: per adapter instance
>> + *
>> + * This function store min and max freq for all the clocks.
>> + *
> 
> "This function parses MIN and MAX frequencies of all clocks required by the
> vendor host drivers."
> 
>> + * Returns 0 for success and non-zero for failure
>> + */
>> +static int ufshcd_config_min_max_clk_freq(struct ufs_hba *hba)
>> +{
>> +	struct list_head *head = &hba->clk_list_head;
>> +	struct dev_pm_opp *opp;
>> +	struct ufs_clk_info *clki;
> 
> Please maintain reverse Xmas tree order. It's not a rule for this driver, but my
> own preference.
> 
>> +	unsigned long freq;
>> +	u8 idx = 0;
>> +	int ret;
> 
> This won't be needed if all the return values are directly returned as I shared
> below.


Will Addressed all ret comments in next patchset.
> 
>> +
>> +	list_for_each_entry(clki, head, list) {
>> +		if (!clki->name)
>> +			continue;
>> +
>> +		clki->clk = devm_clk_get(hba->dev, clki->name);
>> +		if (!IS_ERR_OR_NULL(clki->clk)) {
> 
> This function won't return NULL, so IS_ERR() is sufficient.
> 
>> +			/* Find Max Freq */
>> +			freq = ULONG_MAX;
>> +			opp = dev_pm_opp_find_freq_floor_indexed(hba->dev, &freq, idx);
> 
> Use idx++ and get rid of the increment at the end of the 'if' condition.

If we increment idx++ here, dev_pm_opp_find_freq_ceil_indexed will use 
incremented idx which is not correct. Hence i added at end after both 
the call.

> 
>> +			if (IS_ERR(opp)) {
>> +				dev_err(hba->dev, "failed to find dev_pm_opp\n");
> 
> "Failed to find OPP for MAX frequency"
> 
>> +				ret = PTR_ERR(opp);
> 
> return PTR_ERR(opp);
> 
>> +				return ret;
>> +			}
>> +			clki->max_freq = dev_pm_opp_get_freq_indexed(opp, idx);
>> +
> 
> Missing dev_pm_opp_put()

Thanks. Will update in next patchset.

> 
>> +			/* Find Min Freq */
>> +			freq = 0;
>> +			opp = dev_pm_opp_find_freq_ceil_indexed(hba->dev, &freq, idx);
>> +			if (IS_ERR(opp)) {
>> +				dev_err(hba->dev, "failed to find dev_pm_opp\n");
> 
> "Failed to find OPP for MIN frequency"
> 
>> +				ret = PTR_ERR(opp);
> 
> return PTR_ERR(opp);
> 
>> +				return ret;
>> +			}
>> +			clki->min_freq = dev_pm_opp_get_freq_indexed(opp, idx);
> 
> Missing dev_pm_opp_put()
> 
>> +			idx++;
>> +		}
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>   static int ufshcd_parse_operating_points(struct ufs_hba *hba)
>>   {
>>   	struct device *dev = hba->dev;
>> @@ -279,6 +329,12 @@ static int ufshcd_parse_operating_points(struct ufs_hba *hba)
>>   		return ret;
>>   	}
>>
>> +	ret = ufshcd_config_min_max_clk_freq(hba);
>> +	if (ret) {
>> +		dev_err(dev, "Failed to get min max freq: %d\n", ret);
> 
> Since we already print error message inside the function, no need to do the same
> here.

Sure. Will update in next patchset

> 
> - Mani
> 
>> +		return ret;
>> +	}
>> +
>>   	hba->use_pm_opp = true;
>>
>>   	return 0;
>> --
>> 2.17.1
>>
> 

Thanks,
Nitin


From hverkuil at xs4all.nl  Wed Dec  6 03:08:43 2023
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Wed, 6 Dec 2023 12:08:43 +0100
Subject: [PATCH v9 3/5] media: platform: visconti: add V4L2 vendor
 specific control handlers
In-Reply-To: <TYAPR01MB62019C91FAC70080B967D34792BDA@TYAPR01MB6201.jpnprd01.prod.outlook.com>
References: <20231012071329.2542003-1-yuji2.ishikawa@toshiba.co.jp>
 <20231012071329.2542003-4-yuji2.ishikawa@toshiba.co.jp>
 <6095bd3d-2580-44e2-b622-3ad31e12787f@xs4all.nl>
 <a84ce942-e6df-414e-8d0c-e7d3ef3e62f6@xs4all.nl>
 <20231114095331.GA13826@pendragon.ideasonboard.com>
 <TYAPR01MB62019C91FAC70080B967D34792BDA@TYAPR01MB6201.jpnprd01.prod.outlook.com>
Message-ID: <5595805b-8017-4bcd-bcbc-fd0a75f9c3dc@xs4all.nl>

On 27/11/2023 01:46, yuji2.ishikawa at toshiba.co.jp wrote:
> Hello Laurent,
> 
> Thank you for your comment.
> 
>> -----Original Message-----
>> From: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>> Sent: Tuesday, November 14, 2023 6:54 PM
>> To: Hans Verkuil <hverkuil at xs4all.nl>
>> Cc: ishikawa yuji(?? ?? ?????????????)
>> <yuji2.ishikawa at toshiba.co.jp>; Mauro Carvalho Chehab
>> <mchehab at kernel.org>; Rob Herring <robh+dt at kernel.org>; Krzysztof
>> Kozlowski <krzysztof.kozlowski+dt at linaro.org>; Conor Dooley
>> <conor+dt at kernel.org>; iwamatsu nobuhiro(?? ?? ??????????
>> ???) <nobuhiro1.iwamatsu at toshiba.co.jp>; linux-media at vger.kernel.org;
>> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>> linux-kernel at vger.kernel.org
>> Subject: Re: [PATCH v9 3/5] media: platform: visconti: add V4L2 vendor
>> specific control handlers
>>
>> On Tue, Nov 14, 2023 at 10:10:50AM +0100, Hans Verkuil wrote:
>>> On 14/11/2023 10:02, Hans Verkuil wrote:
>>>> On 12/10/2023 09:13, Yuji Ishikawa wrote:
>>>>> Add support to Image Signal Processors of Visconti's Video Input
>> Interface.
>>>>> This patch adds vendor specific compound controls to configure the
>>>>> image signal processor.
>>>>>
>>>>> Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
>>>>> ---
>>>>> Changelog v2:
>>>>> - Resend v1 because a patch exceeds size limit.
>>>>>
>>>>> Changelog v3:
>>>>> - Adapted to media control framework
>>>>> - Introduced ISP subdevice, capture device
>>>>> - Remove private IOCTLs and add vendor specific V4L2 controls
>>>>> - Change function name avoiding camelcase and uppercase letters
>>>>>
>>>>> Changelog v4:
>>>>> - Split patches because the v3 patch exceeds size limit
>>>>> - Stop using ID number to identify driver instance:
>>>>>   - Use dynamically allocated structure to hold HW specific context,
>>>>>     instead of static one.
>>>>>   - Call HW layer functions with the context structure instead of
>>>>> ID number
>>>>>
>>>>> Changelog v5:
>>>>> - no change
>>>>>
>>>>> Changelog v6:
>>>>> - remove unused macros
>>>>> - removed hwd_ and HWD_ prefix
>>>>> - update source code documentation
>>>>> - Suggestion from Hans Verkuil
>>>>>   - pointer to userland memory is removed from uAPI arguments
>>>>>     - style of structure is now "nested" instead of "chained by pointer";
>>>>>   - use div64_u64 for 64bit division
>>>>>   - vendor specific controls support TRY_EXT_CTRLS
>>>>>   - add READ_ONLY flag to GET_CALIBRATION_STATUS control and
>> similar ones
>>>>>   - human friendry control names for vendor specific controls
>>>>>   - add initial value to each vendor specific control
>>>>>   - GET_LAST_CAPTURE_STATUS control is updated asyncnously from
>> workqueue
>>>>>   - remove EXECUTE_ON_WRITE flag of vendor specific control
>>>>>   - uAPI: return value of GET_CALIBRATION_STATUS follows common
>> rules of error codes
>>>>>   - applied v4l2-compliance
>>>>> - Suggestion from Sakari Ailus
>>>>>   - use div64_u64 for 64bit division
>>>>>   - update copyright's year
>>>>>   - remove redandunt cast
>>>>>   - use bool instead of HWD_VIIF_ENABLE/DISABLE
>>>>>   - simplify comparison to 0
>>>>>   - simplify statements with trigram operator
>>>>>   - remove redundant local variables
>>>>>   - use general integer types instead of u32/s32
>>>>> - Suggestion from Laurent Pinchart
>>>>>   - moved VIIF driver to driver/platform/toshiba/visconti
>>>>>   - change register access: struct-style to macro-style
>>>>>   - remove unused type definitions
>>>>>   - define enums instead of successive macro constants
>>>>>   - remove redundant parenthesis of macro constant
>>>>>   - embed struct hwd_res into struct viif_device
>>>>>   - use xxx_dma instead of xxx_paddr for variable names of IOVA
>>>>>   - literal value: just 0 instead of 0x0
>>>>>   - use literal 1 or 0 instead of HWD_VIIF_ENABLE, DISABLE for register
>> access
>>>>>   - use true or false instead of HWD_VIIF_ENABLE, DISABLE for function
>> calls
>>>>>   - uAPI: return value of GET_CALIBRATION_STATUS follows common
>>>>> rules of error codes
>>>>>
>>>>> Changelog v7:
>>>>> - remove unused variables
>>>>> - split long statements which have multiple logical-OR and trigram
>>>>> operators
>>>>>
>>>>> Changelog v8:
>>>>> - define constant V4L2_CTRL_TYPE_VISCONTI_ISP for datatype
>>>>>   of Visconti specific controls
>>>>> - Suggestion from Hans Verkuil
>>>>>   - remove pr_info()
>>>>>   - use pm_runtime_get_if_in_use() to get power status
>>>>>
>>>>> Changelog v9:
>>>>> - fix warning for cast between ptr and dma_addr_t
>>>>>
>>>>>  .../media/platform/toshiba/visconti/Makefile  |    2 +-
>>>>>  .../media/platform/toshiba/visconti/viif.c    |   10 +-
>>>>>  .../platform/toshiba/visconti/viif_controls.c | 3395
>> +++++++++++++++++
>>>>>  .../platform/toshiba/visconti/viif_controls.h |   18 +
>>>>>  .../platform/toshiba/visconti/viif_isp.c      |   15 +-
>>>>>  drivers/media/v4l2-core/v4l2-ctrls-core.c     |    7 +-
>>>>>  include/uapi/linux/videodev2.h                |    2 +
>>>>>  7 files changed, 3431 insertions(+), 18 deletions(-)  create mode
>>>>> 100644 drivers/media/platform/toshiba/visconti/viif_controls.c
>>>>>  create mode 100644
>>>>> drivers/media/platform/toshiba/visconti/viif_controls.h
>>>>>
>>>>
>>>> <snip>
>>>>
>>>> These core changes below should be in a separate patch, not mixed in
>>>> with the driver.
>>>>
>>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c
>>>>> b/drivers/media/v4l2-core/v4l2-ctrls-core.c
>>>>> index a662fb60f73f..0c4df9fffbe0 100644
>>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-core.c
>>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-core.c
>>>>> @@ -367,7 +367,9 @@ void v4l2_ctrl_type_op_log(const struct v4l2_ctrl
>> *ctrl)
>>>>>  	case V4L2_CTRL_TYPE_AV1_FILM_GRAIN:
>>>>>  		pr_cont("AV1_FILM_GRAIN");
>>>>>  		break;
>>>>> -
>>>>> +	case V4L2_CTRL_TYPE_VISCONTI_ISP:
>>>>> +		pr_cont("VISCONTI_ISP");
>>>>> +		break;
>>>>>  	default:
>>>>>  		pr_cont("unknown type %d", ctrl->type);
>>>>>  		break;
>>>>> @@ -1163,6 +1165,9 @@ static int std_validate_compound(const struct
>> v4l2_ctrl *ctrl, u32 idx,
>>>>>  	case V4L2_CTRL_TYPE_AV1_FILM_GRAIN:
>>>>>  		return validate_av1_film_grain(p);
>>>>>
>>>>> +	case V4L2_CTRL_TYPE_VISCONTI_ISP:
>>>>> +		break;
>>>>> +
>>>>>  	case V4L2_CTRL_TYPE_AREA:
>>>>>  		area = p;
>>>>>  		if (!area->width || !area->height) diff --git
>>>>> a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>>>>> index c3d4e490ce7c..bbc3cd3efa65 100644
>>>>> --- a/include/uapi/linux/videodev2.h
>>>>> +++ b/include/uapi/linux/videodev2.h
>>>>> @@ -1915,6 +1915,8 @@ enum v4l2_ctrl_type {
>>>>>  	V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY = 0x281,
>>>>>  	V4L2_CTRL_TYPE_AV1_FRAME	    = 0x282,
>>>>>  	V4L2_CTRL_TYPE_AV1_FILM_GRAIN	    = 0x283,
>>>>> +
>>>>> +	V4L2_CTRL_TYPE_VISCONTI_ISP = 0x290,
>>>>
>>>> I see you are using the same V4L2_CTRL_TYPE_VISCONTI_ISP for all the
>>>> compound controls. But that's not allowed: the V4L2_CTRL_TYPE_
>>>> defines determine the control type, so each struct used by a control needs
>> its own type.
>>>
>>> Actually, you don't want to add such a type at all. This is all driver
>>> specific, so support like this belongs in the driver.
>>>
>>> A good example of that is
>> V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP in
>>> drivers/media/platform/nxp/dw100/dw100.c: there all the handling is
>>> done in the driver, and it adds init/validate/log/equal ops as well.
>>
>> Actually, I think a better option is to use parameters buffers instead of controls,
>> like other ISP driver do.
>>
> 
> I'll quickly make an experimental impl of parameters buffers of the VIIF driver and check if it works well.
> I'm still not for sure passing parameter via parameters buffers satisfies the timing constraint of the HW.

This is the preferred method over using controls.

Note that the 32 bit vs 64 bit requirement still stands, so use pahole to make
sure that whatever data you exchange over the parameter buffer is the same for
both architectures.

Regards,

	Hans

> 
>>>> I also noticed looking through include/uapi/linux/visconti_viif.h
>>>> that some of the struct have holes. I really want to avoid holes in
>>>> structs used by controls, it is bad practice.
>>>>
>>>> The pahole utility is very useful for testing this. It is also
>>>> highly recommended to check for both 32 and 64 bit compilation: the
>>>> struct layout must be the same, otherwise you would run into
>>>> problems if a 32 bit application is used with a 64 bit kernel.
>>>>
>>>> Finally, Laurent and/or Sakari will also take a look at this driver,
>>>> for some reason this driver has been mostly reviewed by me, but I am
>>>> not really the expert on ISPs.
>>>>
>>>>>  };
>>>>>
>>>>>  /*  Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
>>
>> --
>> Regards,
>>
>> Laurent Pinchart
> 
> 
> Regards,
> Yuji



From catalin.marinas at arm.com  Wed Dec  6 03:09:18 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 6 Dec 2023 11:09:18 +0000
Subject: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64
In-Reply-To: <20231205195130.GM2692119@nvidia.com>
References: <ZWB373y5XuZDultf@FVFF77S0Q05N>
 <20231124122352.GB436702@nvidia.com>
 <ZWSOwT2OyMXD1lmo@arm.com>
 <20231127134505.GI436702@nvidia.com>
 <ZW4NAzI_jvwoq8dL@arm.com>
 <20231204182330.GK1493156@nvidia.com>
 <ZW9cF0ALVwgvcQMy@arm.com>
 <20231205175127.GJ2692119@nvidia.com>
 <ZW97VdHYH3HYVyd5@arm.com>
 <20231205195130.GM2692119@nvidia.com>
Message-ID: <ZXBWXodu2rxQ7Szz@arm.com>

On Tue, Dec 05, 2023 at 03:51:30PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 05, 2023 at 07:34:45PM +0000, Catalin Marinas wrote:
> > > 2) You want to #define __iowrite512_copy() to memcpy_toio() on ARM and
> > >    implement some quad STP optimization for this case?
> > 
> > We can have the generic __iowrite512_copy() do memcpy_toio() and have
> > the arm64 implement an optimised version.
> > 
> > What I'm not entirely sure of is the DGH (whatever the io_* barrier name
> > is). I'd put it in the same __iowrite512_copy() function and remove it
> > from the driver code. Otherwise when ST64B is added, we have an
> > unnecessary DGH in the driver. If this does not match the other
> > __iowrite*_copy() semantics, we can come up with another name. But start
> > with this for now and document the function.
> 
> I think the iowrite is only used for WC and the DGH is functionally
> harmless for non-WC, so it makes sense.
> 
> In this case we should just remove the DGH macro from the generic
> architecture code and tell people to use iowrite - since we now
> understand that callers basically have to in order to use DGH on new
> ARM CPUs.

That works for me but what would the semantics be for __iowrite64_copy()
for example? Is there a DGH at the end of the whole write or after each
iteration? I'd go with the former since e.g. hns3_tx_push_bd() does
that (and doesn't seem to be a 64 byte copy). Similarly for
__iowrite512_copy(), if you want the DGH after each iteration you should
only pass a count of 1.

-- 
Catalin


From krzysztof.kozlowski at linaro.org  Wed Dec  6 03:09:24 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 12:09:24 +0100
Subject: [PATCH 1/4] dt-bindings: memory: additional compatible strings
 for Broadcom DPFE
In-Reply-To: <20231205184741.3092376-2-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-2-mmayer@broadcom.com>
Message-ID: <f17dcd86-7f87-4433-a106-eb7bfdfb05ab@linaro.org>

On 05/12/2023 19:47, Markus Mayer wrote:
> Add versioned compatible strings for Broadcom DPFE. These take the form
> brcm,dpfe-cpu-v<N> where <N> is a number from 1 to 4.
> 
> These API version related compatible strings are more specific than the
> catch-all "brcm,dpfe-cpu" and more generic than chip-specific compatible
> strings.

None of this explains: Why? I don't see any point in this and commit
does not explain.

> 
> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
> ---
>  .../bindings/memory-controllers/brcm,dpfe-cpu.yaml        | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
> index 08cbdcddfead..6dffa7b62baf 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
> +++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
> @@ -16,6 +16,11 @@ properties:
>        - enum:
>            - brcm,bcm7271-dpfe-cpu
>            - brcm,bcm7268-dpfe-cpu
> +      - enum:
> +          - brcm,dpfe-cpu-v1
> +          - brcm,dpfe-cpu-v2
> +          - brcm,dpfe-cpu-v3
> +          - brcm,dpfe-cpu-v4

No, that's just wrong. So you want to say bcm7271 is brcm,dpfe-cpu-v4?

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec  6 03:09:49 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 12:09:49 +0100
Subject: [PATCH 2/4] memory: brcmstb_dpfe: introduce version-specific
 compatible strings
In-Reply-To: <20231205184741.3092376-3-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-3-mmayer@broadcom.com>
Message-ID: <7844ca22-df53-458d-9e3b-7b0758a80455@linaro.org>

On 05/12/2023 19:47, Markus Mayer wrote:
> Introduce compatible strings brcm,dpfe-cpu-v1 through brcm,dpfe-cpu-v3
> to the Broadcom DPFE driver.

No, why?

> 
> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
> ---
>  drivers/memory/brcmstb_dpfe.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> index a7ab3d377206..66876b409e59 100644
> --- a/drivers/memory/brcmstb_dpfe.c
> +++ b/drivers/memory/brcmstb_dpfe.c
> @@ -924,6 +924,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
>  	{ .compatible = "brcm,bcm7271-dpfe-cpu", .data = &dpfe_api_old_v2 },
>  	{ .compatible = "brcm,bcm7278-dpfe-cpu", .data = &dpfe_api_old_v2 },
>  	{ .compatible = "brcm,bcm7211-dpfe-cpu", .data = &dpfe_api_new_v2 },
> +
> +	/* Match specific DCPU versions */
> +	{ .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
> +	{ .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
> +	{ .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },

Pointless change.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec  6 03:10:17 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 12:10:17 +0100
Subject: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
In-Reply-To: <20231205184741.3092376-4-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-4-mmayer@broadcom.com>
Message-ID: <e63906cf-9f76-4fed-91b0-1a9168b179bd@linaro.org>

On 05/12/2023 19:47, Markus Mayer wrote:
> Add support for version 4 of the DPFE API. This new version is largely
> identical to version 3. The main difference is that all commands now
> take the MHS version number as the first argument. Any other arguments
> have been pushed down by one (i.e. what used to be arg0 in v3 is arg1 in
> v4).
> 
> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
> ---

...

> +
>  static const char *get_error_text(unsigned int i)
>  {
>  	static const char * const error_text[] = {
> @@ -929,8 +954,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
>  	{ .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
>  	{ .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
>  	{ .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
> +	{ .compatible = "brcm,dpfe-cpu-v4", .data = &dpfe_api_v4 },
>  

No, use SoC specific compatible.

Best regards,
Krzysztof



From claudiu.beznea at tuxon.dev  Wed Dec  6 03:11:55 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Wed, 6 Dec 2023 13:11:55 +0200
Subject: [PATCH 11/14] arm64: renesas: rzg3s-smarc-som: Invert the logic
 for SW_SD2_EN macro
In-Reply-To: <CAMuHMdXwSo1L9UuFg9RL0TLL_xzVt2r6QEFc0gtPoydpr4FmSQ@mail.gmail.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-12-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdUbKe=yiXWNmk5BJFLtF2psx9khiDRGasT9WsnHz4RWsg@mail.gmail.com>
 <CAMuHMdXwSo1L9UuFg9RL0TLL_xzVt2r6QEFc0gtPoydpr4FmSQ@mail.gmail.com>
Message-ID: <248d24a9-589e-4b92-94b6-98504f78d7b9@tuxon.dev>

Hi, Geert,

On 06.12.2023 12:56, Geert Uytterhoeven wrote:
> On Wed, Dec 6, 2023 at 11:33?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>> On Mon, Nov 20, 2023 at 8:03?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>
>>> The intention of SW_SD2_EN macro was to reflect the state of SW_CONFIG3
>>> switch available on RZ/G3S Smarc Module. According to documentation SD2
>>> is enabled when switch is in OFF state. For this, changed the logic of
>>> marco to map value 0 to switch's OFF state and value 1 to switch's ON
>>> state. Along with this update the description for each state for better
>>> understanding.
>>>
>>> The value of SW_SD2_EN macro was not changed in file because, according to
>>> documentation, the default state for this switch is ON.
>>>
>>> Fixes: adb4f0c5699c ("arm64: dts: renesas: Add initial support for RZ/G3S SMARC SoM")
>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> Thanks for your patch!
>>
>>> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
>>> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
>>> @@ -14,8 +14,8 @@
>>>   *     0 - SD0 is connected to eMMC
>>>   *     1 - SD0 is connected to uSD0 card
>>>   * @SW_SD2_EN:
>>> - *     0 - SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
>>> - *     1 - SD2 is connected to SoC
>>> + *     0 - (switch OFF) SD2 is connected to SoC
>>> + *     1 - (switch ON)  SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
>>
>> I think this is still confusing: SW_SD2_EN refers to an active-low signal
>> (SW_SD2_EN#) in the schematics.
> 
> OMG, while the signal is called "SW_SD2_EN#" in the schematics, it is
> _not_ active-low!
> SW_D2_EN# drives a STG3692 quad SPDT switch, and SD2 is enabled
> if SW_D2_EN# is high...
> 
> The RZ/G3S SMARC Module User Manual says:
> 
> Signal SW_SD2_EN ON: SD2 is disabled.
> Signal SW_SD2_EN OFF: SD2 is enabled.

I followed the description in this manual, chapter 2.1.1 SW_CONFIG. The
idea was that these macros to correspond to individual switches, to match
that table (describing switches position) with this code as the user in the
end sets those switches described in table at 2.1.1 w/o necessary going
deep into schematic (at least in the beginning when trying different
functionalities).

Do you think it would be better if we will have these macros named
SWCONFIGX, X in {1, 2, 3, 4, 5, 6} ?

> 
> So whatever we do, something will look odd :-(
> 
>> Before, SW_SD2_EN used assertion-logic (1 is enabled), and didn't
>> match the physical signal level.
>> After your patch, SW_SD2_EN matches the active-low physical level, but
>> this is not reflected in the name...
>>
>>>   */
>>>  #define SW_SD0_DEV_SEL 1
>>>  #define SW_SD2_EN      1
>>> @@ -25,7 +25,7 @@ / {
>>>
>>>         aliases {
>>>                 mmc0 = &sdhi0;
>>> -#if SW_SD2_EN
>>> +#if !SW_SD2_EN
>>
>> ... so this condition looks really weird.
> 
> Still, I think the original looks nicer here.
> 
> So I suggest to keep the original logic, but clarify the position of
> the switch.
> Does that make sense?

It will still be odd, AFAICT, as this way as we will map 0 to ON and 1 to
OFF... A bit counterintuitive.

> 
> 
>>
>>>                 mmc2 = &sdhi2;
>>>  #endif
>>>         };
>>> @@ -116,7 +116,7 @@ &sdhi0 {
>>>  };
>>>  #endif
>>>
>>> -#if SW_SD2_EN
>>> +#if !SW_SD2_EN
>>>  &sdhi2 {
>>>         pinctrl-0 = <&sdhi2_pins>;
>>>         pinctrl-names = "default";
>>
>> So I think SW_SD2_EN should be renamed to SW_SD2_EN_N.
>>
>> Cfr. SW_ET0_EN_N on RZ/G2UL:
>>
>> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * DIP-Switch SW1 setting
>> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * 1 : High; 0: Low
>> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * SW1-2 :
>> SW_SD0_DEV_SEL    (0: uSD; 1: eMMC)
>> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * SW1-3 :
>> SW_ET0_EN_N               (0: ETHER0; 1: CAN0, CAN1, SSI1, RSPI1)
>> arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts- * Please change
>> below macros according to SW1 setting on the SoM
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds


From krzysztof.kozlowski at linaro.org  Wed Dec  6 03:13:19 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 12:13:19 +0100
Subject: [PATCH 4/4] memory: brcmstb_dpfe: introduce best-effort API
 detection
In-Reply-To: <20231205184741.3092376-5-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-5-mmayer@broadcom.com>
Message-ID: <8e86fb4c-9526-4d64-9352-f9c8e5cae75f@linaro.org>

On 05/12/2023 19:47, Markus Mayer wrote:
> Add a best-effort probe function that tries all known DPFE versions to
> see if one might actually work. This helps in cases where device tree
> doesn't provide the proper version information for whatever reason. In

So for incomplete DTS you now add elaborate, own, custom matching
function. That's not how the code should work.

> that case, the driver may still be able to register if one of the known
> API versions ends up working.
> 
> Caveat: we have to skip "v1" during our best effort attempts. This is
> due to the fact that attempting a firmware download as required by v1
> will result in a memory access violation on anything but v1 hardware.
> This would crash the kernel. Since we don't know the HW version, we need
> to play it safe and skip v1.

None of this commit explains what is real problem being solved.


> 
> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
> ---
>  drivers/memory/brcmstb_dpfe.c | 58 ++++++++++++++++++++++++++++++++++-
>  1 file changed, 57 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> index 0b0a9b85b605..15f4ee3b8535 100644
> --- a/drivers/memory/brcmstb_dpfe.c
> +++ b/drivers/memory/brcmstb_dpfe.c
> @@ -879,6 +879,50 @@ static int brcmstb_dpfe_resume(struct platform_device *pdev)
>  	return brcmstb_dpfe_download_firmware(priv);
>  }
>  
> +static int brcmstb_dpfe_probe_best_effort(struct platform_device *pdev)
> +{
> +	const char versioned_compat[] = "brcm,dpfe-cpu-v";
> +	const char v1_str[] = "-v1";
> +	const struct of_device_id *matches;
> +	const struct dpfe_api *orig_dpfe_api;
> +	struct device *dev = &pdev->dev;
> +	struct brcmstb_dpfe_priv *priv;
> +	int ret = -ENODEV;
> +
> +	priv = dev_get_drvdata(dev);
> +	orig_dpfe_api = priv->dpfe_api;
> +	matches = dev->driver->of_match_table;
> +
> +	/* Loop over all compatible strings */
> +	for (; matches->compatible[0]; matches++) {
> +		const char *compat = matches->compatible;
> +		/* Find the ones that start with "brcm,dpfe-cpu-v" */
> +		if (strstr(compat, versioned_compat) == compat) {
> +			char *v1_ptr = strstr(compat, v1_str);
> +			/*
> +			 * We must skip v1, since we don't know the hardware
> +			 * version and attempting a firmware download on v2 and
> +			 * newer would crash the kernel due to a memory access
> +			 * violation.
> +			 * We make sure to match "-v1" at the end of the string
> +			 * only.
> +			 */
> +			if (v1_ptr && v1_ptr[sizeof(v1_str)] == '\0')
> +				continue;
> +			priv->dpfe_api = matches->data;
> +			/* Fingers crossed... */
> +			ret = brcmstb_dpfe_download_firmware(priv);
> +			if (!ret)
> +				return 0;
> +		}
> +	}
> +
> +	/* It didn't work, so let's clean up. */
> +	priv->dpfe_api = orig_dpfe_api;
> +
> +	return ret;
> +}
> +
>  static int brcmstb_dpfe_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -923,8 +967,20 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
>  	}
>  
>  	ret = brcmstb_dpfe_download_firmware(priv);
> +	if (ret && ret != -EPROBE_DEFER) {
> +		/*
> +		 * If the information provided by Device Tree didn't work, let's
> +		 * try all known version. Maybe one will work.

I don't understand how this comment is related to downloading firmware.

> +		 */
> +		dev_warn(dev,
> +			"DPFE v%d didn't work, reverting to best-effort\n",
> +			priv->dpfe_api->version);
> +		dev_warn(dev,
> +			"Device Tree and / or the driver should be updated\n");

You are now introducing new warnings?

NAK

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec  6 03:14:14 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 12:14:14 +0100
Subject: [PATCH 0/4] memory: brcmstb_dpfe: support DPFE API v4
In-Reply-To: <20231205184741.3092376-1-mmayer@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
Message-ID: <28531f53-3213-4d12-b4c8-d91cfd0461d5@linaro.org>

On 05/12/2023 19:47, Markus Mayer wrote:
> It has become necessary to distinguish between the various DPFE API
> versions by version number. Having just chip-specific compatible strings
> and one generic version is no longer meeting our needs.
> 
> Also, a new DPFE API version, v4, needs to be supported by the driver.
> 
> As a result, an intermediate compatible string format is being

Introducing new SoC does not justify this. It's not correlated, not
related. Stop using some fake arguments to introduce something which we
do not want: versions.

> introduced: brcm,dpfe-cpu-v<N> where <N> represents the API version
> number. This is more specific than the catch-all "brcm,dpfe-cpu" and
> more generic than chip-specific compatible strings, such as
> "brcm,bcm7271-dpfe-cpu".

NAK

Best regards,
Krzysztof



From mani at kernel.org  Wed Dec  6 03:17:07 2023
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Wed, 6 Dec 2023 16:47:07 +0530
Subject: [PATCH V1] scsi: ufs: core: store min and max clk freq from OPP
 table
In-Reply-To: <f30d3c21-f355-d535-480b-2fd36167bcfd@quicinc.com>
References: <20231206053628.32169-1-quic_nitirawa@quicinc.com>
 <20231206075447.GA4954@thinkpad>
 <f30d3c21-f355-d535-480b-2fd36167bcfd@quicinc.com>
Message-ID: <20231206111707.GA12802@thinkpad>

On Wed, Dec 06, 2023 at 04:35:24PM +0530, Nitin Rawat wrote:
> 
> 
> On 12/6/2023 1:24 PM, Manivannan Sadhasivam wrote:
> > On Wed, Dec 06, 2023 at 11:06:28AM +0530, Nitin Rawat wrote:
> > > OPP support will make use of OPP table in device tree and removes
> > > freq-table-hz property from device tree.
> > > 
> > > With OPP enabled in devicetree, clki->min_freq and clki->maxfreq
> > > currently is not getting updated and the value is set to 0.
> > > 
> > > Soc vendors like qcom, mediatek uses clki->minfreq and clki->maxfreq
> > > in vendor specific file. These frequencies values are used to update
> > > vendor specific configurations. Since the value is 0, it is causing
> > > functional issue.
> > 
> > How about,
> > 
> > "OPP support added by commit 72208ebe181e ("scsi: ufs: core: Add support
> > for parsing OPP") doesn't update the min_freq and max_freq of each clocks
> > in 'struct ufs_clk_info'.
> > 
> > But these values are used by the vendor host drivers internally for controller
> > configuration. When the OPP support is enabled in devicetree, these values will
> > be 0, causing boot issues on the respective platforms.
> > 
> > So let's parse the min_freq and max_freq of all clocks while parsing the OPP
> > table."
> > 
> > > 
> > > Add code to store the min and max ufs clk frequency from OPP table.
> 
> Sure. Will update in next patchset.
> 
> > > 
> > > Fixes: 72208ebe181e ("scsi: ufs: core: Add support for parsing OPP")
> > > Co-developed-by: Manish Pandey <quic_mapa at quicinc.com>
> > > Signed-off-by: Manish Pandey <quic_mapa at quicinc.com>
> > > Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
> > > ---
> > >   drivers/ufs/host/ufshcd-pltfrm.c | 56 ++++++++++++++++++++++++++++++++
> > >   1 file changed, 56 insertions(+)
> > > 
> > > diff --git a/drivers/ufs/host/ufshcd-pltfrm.c b/drivers/ufs/host/ufshcd-pltfrm.c
> > > index da2558e274b4..12fa6f7d6a97 100644
> > > --- a/drivers/ufs/host/ufshcd-pltfrm.c
> > > +++ b/drivers/ufs/host/ufshcd-pltfrm.c
> > > @@ -13,6 +13,7 @@
> > >   #include <linux/pm_opp.h>
> > >   #include <linux/pm_runtime.h>
> > >   #include <linux/of.h>
> > > +#include <linux/clk.h>
> > 
> > Sort includes alphabetically.
> 
> Sure. Will update in next patchset
> 
> > 
> > > 
> > >   #include <ufs/ufshcd.h>
> > >   #include "ufshcd-pltfrm.h"
> > > @@ -213,6 +214,55 @@ static void ufshcd_init_lanes_per_dir(struct ufs_hba *hba)
> > >   	}
> > >   }
> > > 
> > > +/**
> > > + * ufshcd_config_min_max_clk_freq - update min and max freq
> > 
> > "ufshcd_parse_clock_min_max_freq - Parse MIN and MAX frequencies of clocks"
> > 
> > > + * @hba: per adapter instance
> > > + *
> > > + * This function store min and max freq for all the clocks.
> > > + *
> > 
> > "This function parses MIN and MAX frequencies of all clocks required by the
> > vendor host drivers."
> > 
> > > + * Returns 0 for success and non-zero for failure
> > > + */
> > > +static int ufshcd_config_min_max_clk_freq(struct ufs_hba *hba)
> > > +{
> > > +	struct list_head *head = &hba->clk_list_head;
> > > +	struct dev_pm_opp *opp;
> > > +	struct ufs_clk_info *clki;
> > 
> > Please maintain reverse Xmas tree order. It's not a rule for this driver, but my
> > own preference.
> > 
> > > +	unsigned long freq;
> > > +	u8 idx = 0;
> > > +	int ret;
> > 
> > This won't be needed if all the return values are directly returned as I shared
> > below.
> 
> 
> Will Addressed all ret comments in next patchset.
> > 
> > > +
> > > +	list_for_each_entry(clki, head, list) {
> > > +		if (!clki->name)
> > > +			continue;
> > > +
> > > +		clki->clk = devm_clk_get(hba->dev, clki->name);
> > > +		if (!IS_ERR_OR_NULL(clki->clk)) {
> > 
> > This function won't return NULL, so IS_ERR() is sufficient.
> > 
> > > +			/* Find Max Freq */
> > > +			freq = ULONG_MAX;
> > > +			opp = dev_pm_opp_find_freq_floor_indexed(hba->dev, &freq, idx);
> > 
> > Use idx++ and get rid of the increment at the end of the 'if' condition.
> 
> If we increment idx++ here, dev_pm_opp_find_freq_ceil_indexed will use
> incremented idx which is not correct. Hence i added at end after both the
> call.

Ah, right. Please increment it in dev_pm_opp_find_freq_ceil_indexed() instead.

- Mani

-- 
????????? ????????


From geert at linux-m68k.org  Wed Dec  6 03:22:13 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 6 Dec 2023 12:22:13 +0100
Subject: [PATCH 13/14] arm64: dts: renesas: rzg3s-smarc-som: Enable
 Ethernet interfaces
In-Reply-To: <20231120070024.4079344-14-claudiu.beznea.uj@bp.renesas.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com> <20231120070024.4079344-14-claudiu.beznea.uj@bp.renesas.com>
Message-ID: <CAMuHMdXs9tKo9W31f5OybNR51a_i99Lyx=wHe0GLrADN_8KZTg@mail.gmail.com>

Hi Claudiu,

Thanks for your patch!

On Mon, Nov 20, 2023 at 8:03?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>
> RZ/G3S Smarc Module has Ethernet PHYs (KSZ9131) connected to each Ethernet
> IP. For this add proper DT bindings to enable the Ethernet communication
> though these PHYs.
>
> The interface b/w PHYs and MACs is RGMII. The skew settings were set to
> zero as based on phy-mode (rgmii-id) the KSZ9131 driver enables internal
> DLL which adds 2ns delay b/w clocks (TX/RX) and data signals.

So shouldn't you just use phy-mode "rgmii" instead?

> Different pin settings were applied to TXC, TX_CTL compared with the rest
> of the RGMII pins to comply with requirements for these pins imposed by
> HW manual of RZ/G3S (see chapters "Ether Ch0 Voltage Mode Control
> Register (ETH0_POC)", "Ether Ch1 Voltage Mode Control Register (ETH1_POC)",
> for power source selection, "Ether MII/RGMII Mode Control Register
> (ETH_MODE)" for output-enable and "Input Enable Control Register (IEN_m)"
> for input-enable configurations).
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>

> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> @@ -25,7 +25,10 @@ / {
>
>         aliases {
>                 mmc0 = &sdhi0;
> -#if !SW_SD2_EN
> +#if SW_SD2_EN

Cfr. my comment on [PATCH 11/14], this looks odd...

> +               eth0 = &eth0;
> +               eth1 = &eth1;
> +#else
>                 mmc2 = &sdhi2;
>  #endif
>         };
> @@ -81,6 +84,64 @@ vcc_sdhi2: regulator2 {
>         };
>  };
>
> +#if SW_SD2_EN

Likewise.

> +&eth0 {
> +       pinctrl-0 = <&eth0_pins>;
> +       pinctrl-names = "default";
> +       phy-handle = <&phy0>;
> +       phy-mode = "rgmii-id";
> +       #address-cells = <1>;
> +       #size-cells = <0>;

#{address,size}-cells should be in the SoC-specific .dtsi.
Same for eth1.

> +       status = "okay";

The rest LGTM.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From geert at linux-m68k.org  Wed Dec  6 03:27:15 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 6 Dec 2023 12:27:15 +0100
Subject: [PATCH 11/14] arm64: renesas: rzg3s-smarc-som: Invert the logic
 for SW_SD2_EN macro
In-Reply-To: <248d24a9-589e-4b92-94b6-98504f78d7b9@tuxon.dev>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-12-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdUbKe=yiXWNmk5BJFLtF2psx9khiDRGasT9WsnHz4RWsg@mail.gmail.com>
 <CAMuHMdXwSo1L9UuFg9RL0TLL_xzVt2r6QEFc0gtPoydpr4FmSQ@mail.gmail.com> <248d24a9-589e-4b92-94b6-98504f78d7b9@tuxon.dev>
Message-ID: <CAMuHMdXo9Pj1NJ+XK-XKj18ynZ3gOxrXQpjMsTjfziTAyjYMdA@mail.gmail.com>

Hi Claudiu,

On Wed, Dec 6, 2023 at 12:12?PM claudiu beznea <claudiu.beznea at tuxon.dev> wrote:
> On 06.12.2023 12:56, Geert Uytterhoeven wrote:
> > On Wed, Dec 6, 2023 at 11:33?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> >> On Mon, Nov 20, 2023 at 8:03?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
> >>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>>
> >>> The intention of SW_SD2_EN macro was to reflect the state of SW_CONFIG3
> >>> switch available on RZ/G3S Smarc Module. According to documentation SD2
> >>> is enabled when switch is in OFF state. For this, changed the logic of
> >>> marco to map value 0 to switch's OFF state and value 1 to switch's ON
> >>> state. Along with this update the description for each state for better
> >>> understanding.
> >>>
> >>> The value of SW_SD2_EN macro was not changed in file because, according to
> >>> documentation, the default state for this switch is ON.
> >>>
> >>> Fixes: adb4f0c5699c ("arm64: dts: renesas: Add initial support for RZ/G3S SMARC SoM")
> >>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>
> >> Thanks for your patch!
> >>
> >>> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> >>> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> >>> @@ -14,8 +14,8 @@
> >>>   *     0 - SD0 is connected to eMMC
> >>>   *     1 - SD0 is connected to uSD0 card
> >>>   * @SW_SD2_EN:
> >>> - *     0 - SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
> >>> - *     1 - SD2 is connected to SoC
> >>> + *     0 - (switch OFF) SD2 is connected to SoC
> >>> + *     1 - (switch ON)  SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
> >>
> >> I think this is still confusing: SW_SD2_EN refers to an active-low signal
> >> (SW_SD2_EN#) in the schematics.
> >
> > OMG, while the signal is called "SW_SD2_EN#" in the schematics, it is
> > _not_ active-low!
> > SW_D2_EN# drives a STG3692 quad SPDT switch, and SD2 is enabled
> > if SW_D2_EN# is high...
> >
> > The RZ/G3S SMARC Module User Manual says:
> >
> > Signal SW_SD2_EN ON: SD2 is disabled.
> > Signal SW_SD2_EN OFF: SD2 is enabled.
>
> I followed the description in this manual, chapter 2.1.1 SW_CONFIG. The
> idea was that these macros to correspond to individual switches, to match
> that table (describing switches position) with this code as the user in the
> end sets those switches described in table at 2.1.1 w/o necessary going
> deep into schematic (at least in the beginning when trying different
> functionalities).
>
> Do you think it would be better if we will have these macros named
> SWCONFIGX, X in {1, 2, 3, 4, 5, 6} ?

Perhaps. A disadvantage would be that SW_CONFIG%u doesn't
give any indication about its purpose...

> > So whatever we do, something will look odd :-(
> >
> >> Before, SW_SD2_EN used assertion-logic (1 is enabled), and didn't
> >> match the physical signal level.
> >> After your patch, SW_SD2_EN matches the active-low physical level, but
> >> this is not reflected in the name...
> >>
> >>>   */
> >>>  #define SW_SD0_DEV_SEL 1
> >>>  #define SW_SD2_EN      1
> >>> @@ -25,7 +25,7 @@ / {
> >>>
> >>>         aliases {
> >>>                 mmc0 = &sdhi0;
> >>> -#if SW_SD2_EN
> >>> +#if !SW_SD2_EN
> >>
> >> ... so this condition looks really weird.
> >
> > Still, I think the original looks nicer here.
> >
> > So I suggest to keep the original logic, but clarify the position of
> > the switch.
> > Does that make sense?
>
> It will still be odd, AFAICT, as this way as we will map 0 to ON and 1 to
> OFF... A bit counterintuitive.

Most switches on board pull signals LOW when the switch is ON...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From claudiu.beznea at tuxon.dev  Wed Dec  6 03:31:32 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Wed, 6 Dec 2023 13:31:32 +0200
Subject: [PATCH 11/14] arm64: renesas: rzg3s-smarc-som: Invert the logic
 for SW_SD2_EN macro
In-Reply-To: <CAMuHMdXo9Pj1NJ+XK-XKj18ynZ3gOxrXQpjMsTjfziTAyjYMdA@mail.gmail.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-12-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdUbKe=yiXWNmk5BJFLtF2psx9khiDRGasT9WsnHz4RWsg@mail.gmail.com>
 <CAMuHMdXwSo1L9UuFg9RL0TLL_xzVt2r6QEFc0gtPoydpr4FmSQ@mail.gmail.com>
 <248d24a9-589e-4b92-94b6-98504f78d7b9@tuxon.dev>
 <CAMuHMdXo9Pj1NJ+XK-XKj18ynZ3gOxrXQpjMsTjfziTAyjYMdA@mail.gmail.com>
Message-ID: <6e14077c-ceb6-4921-8db2-1dc4a99856c6@tuxon.dev>



On 06.12.2023 13:27, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Wed, Dec 6, 2023 at 12:12?PM claudiu beznea <claudiu.beznea at tuxon.dev> wrote:
>> On 06.12.2023 12:56, Geert Uytterhoeven wrote:
>>> On Wed, Dec 6, 2023 at 11:33?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>>> On Mon, Nov 20, 2023 at 8:03?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
>>>>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>>>
>>>>> The intention of SW_SD2_EN macro was to reflect the state of SW_CONFIG3
>>>>> switch available on RZ/G3S Smarc Module. According to documentation SD2
>>>>> is enabled when switch is in OFF state. For this, changed the logic of
>>>>> marco to map value 0 to switch's OFF state and value 1 to switch's ON
>>>>> state. Along with this update the description for each state for better
>>>>> understanding.
>>>>>
>>>>> The value of SW_SD2_EN macro was not changed in file because, according to
>>>>> documentation, the default state for this switch is ON.
>>>>>
>>>>> Fixes: adb4f0c5699c ("arm64: dts: renesas: Add initial support for RZ/G3S SMARC SoM")
>>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>>>
>>>> Thanks for your patch!
>>>>
>>>>> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
>>>>> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
>>>>> @@ -14,8 +14,8 @@
>>>>>   *     0 - SD0 is connected to eMMC
>>>>>   *     1 - SD0 is connected to uSD0 card
>>>>>   * @SW_SD2_EN:
>>>>> - *     0 - SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
>>>>> - *     1 - SD2 is connected to SoC
>>>>> + *     0 - (switch OFF) SD2 is connected to SoC
>>>>> + *     1 - (switch ON)  SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
>>>>
>>>> I think this is still confusing: SW_SD2_EN refers to an active-low signal
>>>> (SW_SD2_EN#) in the schematics.
>>>
>>> OMG, while the signal is called "SW_SD2_EN#" in the schematics, it is
>>> _not_ active-low!
>>> SW_D2_EN# drives a STG3692 quad SPDT switch, and SD2 is enabled
>>> if SW_D2_EN# is high...
>>>
>>> The RZ/G3S SMARC Module User Manual says:
>>>
>>> Signal SW_SD2_EN ON: SD2 is disabled.
>>> Signal SW_SD2_EN OFF: SD2 is enabled.
>>
>> I followed the description in this manual, chapter 2.1.1 SW_CONFIG. The
>> idea was that these macros to correspond to individual switches, to match
>> that table (describing switches position) with this code as the user in the
>> end sets those switches described in table at 2.1.1 w/o necessary going
>> deep into schematic (at least in the beginning when trying different
>> functionalities).
>>
>> Do you think it would be better if we will have these macros named
>> SWCONFIGX, X in {1, 2, 3, 4, 5, 6} ?
> 
> Perhaps. A disadvantage would be that SW_CONFIG%u doesn't
> give any indication about its purpose...

That's the reason I chose initially to have the signal names instead of
SWCONFIGX.

Now seeing that signal names could be confusing I tend to go with SWCONFIGx
instead.

> 
>>> So whatever we do, something will look odd :-(
>>>
>>>> Before, SW_SD2_EN used assertion-logic (1 is enabled), and didn't
>>>> match the physical signal level.
>>>> After your patch, SW_SD2_EN matches the active-low physical level, but
>>>> this is not reflected in the name...
>>>>
>>>>>   */
>>>>>  #define SW_SD0_DEV_SEL 1
>>>>>  #define SW_SD2_EN      1
>>>>> @@ -25,7 +25,7 @@ / {
>>>>>
>>>>>         aliases {
>>>>>                 mmc0 = &sdhi0;
>>>>> -#if SW_SD2_EN
>>>>> +#if !SW_SD2_EN
>>>>
>>>> ... so this condition looks really weird.
>>>
>>> Still, I think the original looks nicer here.
>>>
>>> So I suggest to keep the original logic, but clarify the position of
>>> the switch.
>>> Does that make sense?
>>
>> It will still be odd, AFAICT, as this way as we will map 0 to ON and 1 to
>> OFF... A bit counterintuitive.
> 
> Most switches on board pull signals LOW when the switch is ON...
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 


From krzysztof.kozlowski at linaro.org  Wed Dec  6 03:38:14 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 12:38:14 +0100
Subject: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl
 configuration
In-Reply-To: <000001da24c0$0b83aab0$228b0010$@samsung.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-15-peter.griffin@linaro.org>
 <CGME20231202004026epcas5p4d3947d7bb99e54f70ca37272cfdc5e55@epcas5p4.samsung.com>
 <CAPLW+4kBOWFPx3Hr-=UoLWvRxCorzBY9RCOiBhfkKcU0LAa21Q@mail.gmail.com>
 <000001da24c0$0b83aab0$228b0010$@samsung.com>
Message-ID: <71972f4f-b5ac-484a-8a09-0b74bd7c623b@linaro.org>

On 02/12/2023 02:36, Alim Akhtar wrote:
> 
> 
>> -----Original Message-----
>> From: Sam Protsenko <semen.protsenko at linaro.org>
>> Sent: Saturday, December 2, 2023 6:10 AM
>> To: Peter Griffin <peter.griffin at linaro.org>
>> Cc: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
>> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
>> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
>> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
>> will at kernel.org; arnd at arndb.de; olof at lixom.net;
>> gregkh at linuxfoundation.org; jirislaby at kernel.org;
>> cw00.choi at samsung.com; alim.akhtar at samsung.com;
>> tudor.ambarus at linaro.org; andre.draszik at linaro.org;
>> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
>> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
>> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
>> team at android.com; linux-serial at vger.kernel.org
>> Subject: Re: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl
>> configuration
>>
>> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org>
>> wrote:
>>>
>>> Add support for the pin-controller found on the gs101 SoC used in
>>> Pixel 6 phones.
>>>
>>> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
>>> ---
>>>  .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 159 ++++++++++++++++++
>>>  drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
>>>  drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
>>>  drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
>>>  drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
>>>  5 files changed, 198 insertions(+)
>>>
>>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>>> b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>>> index cb965cf93705..e1a0668ecb16 100644
>>> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>>> @@ -796,3 +796,162 @@ const struct samsung_pinctrl_of_match_data
>> fsd_of_data __initconst = {
>>>         .ctrl           = fsd_pin_ctrl,
>>>         .num_ctrl       = ARRAY_SIZE(fsd_pin_ctrl),
>>>  };
>>> +
>>> +/*
>>> + * bank type for non-alive type
>>> + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit
>>> +field: 4)
>>> + * (CONPDN bit field: 2, PUDPDN bit field: 4)  */ static struct
>>> +samsung_pin_bank_type gs101_bank_type_off  = {
>>> +       .fld_width = { 4, 1, 4, 4, 2, 4, },
>>> +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, }, };
>>
>> This is just the same as exynos850_bank_type_off (100% duplication).
>> Here is what I suggest. Now that it's obvious there is some common platform
>> for moder Exynos SoCs, and it's probably Exynos9, I'd suggest next course of
>> action (if maintainers agree):
>>   1. Remove this one
>>   2. Rename exynos850_bank_type_off to exynos9_bank_type_off
>>   3. Use it for both gs101 and exynos850
>>
>> Does it make sense?
>>
> My opinion is to reuse exynos850 for gs101 (wherever applicable), same philosophy was historically followed in this file.
> That way (using exynos850 for gs101) things will be simple. 
> Adding exynos9_* is not adding any benefit, rather it create confusion.

I don't see much value in renaming exynos850 bank type to exynos9
considering:
1. We don't really know the bank types for all of Exynos9xxx SoCs,
2. Exynos7885 also uses Exynos850 bank types. Exynos7885 was much
earlier than Exynos9xxx family.

Best regards,
Krzysztof



From maz at kernel.org  Wed Dec  6 03:39:03 2023
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 06 Dec 2023 11:39:03 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
In-Reply-To: <ZW9uqu7yOtyZfmvC@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
	<86fs0hatt3.wl-maz@kernel.org>
	<ZW8MP2tDt4_9ROBz@arm.com>
	<20231205130517.GD2692119@nvidia.com>
	<ZW9OSe8Z9gAmM7My@arm.com>
	<20231205164318.GG2692119@nvidia.com>
	<86bkb4bn2v.wl-maz@kernel.org>
	<ZW9ezSGSDIvv5MsQ@arm.com>
	<86a5qobkt8.wl-maz@kernel.org>
	<ZW9uqu7yOtyZfmvC@arm.com>
Message-ID: <868r67blwo.wl-maz@kernel.org>

On Tue, 05 Dec 2023 18:40:42 +0000,
Catalin Marinas <catalin.marinas at arm.com> wrote:
> 
> On Tue, Dec 05, 2023 at 05:50:27PM +0000, Marc Zyngier wrote:
> > On Tue, 05 Dec 2023 17:33:01 +0000,
> > Catalin Marinas <catalin.marinas at arm.com> wrote:
> > > Ideally we should do this for vfio only but we don't have an easy
> > > way to convey this to KVM.
> > 
> > But if we want to limit this to PCIe, we'll have to find out. The
> > initial proposal (a long while ago) had a flag conveying some
> > information, and I'd definitely feel more confident having something
> > like that.
> 
> We can add a VM_PCI_IO in the high vma flags to be set by
> vfio_pci_core_mmap(), though it limits it to 64-bit architectures. KVM
> knows this is PCI and relaxes things a bit. It's not generic though if
> we need this later for something else.

Either that, or something actually describing the attributes that VFIO
wants.

And I very much want it to be a buy-in behaviour, not something that
automagically happens and changes the default behaviour for everyone
based on some hand-wavy assertions.

If that means a userspace change, fine by me. The VMM better know what
is happening.

	M.

-- 
Without deviation from the norm, progress is not possible.


From aford173 at gmail.com  Wed Dec  6 03:43:43 2023
From: aford173 at gmail.com (Adam Ford)
Date: Wed, 6 Dec 2023 05:43:43 -0600
Subject: [PATCH v2 0/4] media: rkisp1: Fix IRQ related issues
In-Reply-To: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
References: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
Message-ID: <CAHCN7xLgOVPMhFWty8Yofsy4F-rFgTT=PuzD4UrA3kOsPQaYUQ@mail.gmail.com>

On Wed, Dec 6, 2023 at 4:12?AM Tomi Valkeinen
<tomi.valkeinen at ideasonboard.com> wrote:
>
> These fix a few IRQ related issues I noticed when testing i.MX8MP. These
> are based on Paul's recently sent "[PATCH v4 00/11] media: rkisp1: Add
> support for i.MX8MP" series, but could also be rebased on top of
> mainline if needed.
>
I applied the whole series on top of your DMA patch and the series
from Paul porting the rkisp1 to the imx8mp and ran the camera for 15
minutes streaming to my monitor.  I didn't see any glitches or video
distortion at 640x480.

For the series...

Tested-by: Adam Ford <aford173 at gmail.com>  #imx8mp-beacon

> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
> Changes in v2:
> - New patch: "media: rkisp1: Drop IRQF_SHARED"
> - Update "media: rkisp1: Fix IRQ handler return values" according to
>   Laurent's comment.
> - Drop "media: rkisp1: Fix IRQ handling due to shared interrupts"
> - Update description for "media: rkisp1: Fix IRQ disable race issue"
> - Link to v1: https://lore.kernel.org/r/20231205-rkisp-irq-fix-v1-0-f4045c74ba45 at ideasonboard.com
>
> ---
> Tomi Valkeinen (4):
>       media: rkisp1: Drop IRQF_SHARED
>       media: rkisp1: Fix IRQ handler return values
>       media: rkisp1: Store IRQ lines
>       media: rkisp1: Fix IRQ disable race issue
>
>  .../media/platform/rockchip/rkisp1/rkisp1-common.h | 11 ++++++-
>  .../media/platform/rockchip/rkisp1/rkisp1-csi.c    | 14 +++++++-
>  .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 37 ++++++++++++++++------
>  .../media/platform/rockchip/rkisp1/rkisp1-isp.c    | 20 ++++++++++--
>  4 files changed, 67 insertions(+), 15 deletions(-)
> ---
> base-commit: dd19f89b915c203d49e3b23ca02446d4fb05d955
> change-id: 20231205-rkisp-irq-fix-e123a8a6732f
>
> Best regards,
> --
> Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>


From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:23 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:23 +0100
Subject: [PATCH v4 009/115] pwm: atmel: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <3b4d48109b6fcb9aecae030a9f9c879cd3ae0835.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-atmel.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 47bcc8a3bf9d..4ef91fe6f147 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -210,7 +210,7 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
 	shift = fls(cycles) - atmel_pwm->data->cfg.period_bits;
 
 	if (shift > PWM_MAX_PRES) {
-		dev_err(chip->dev, "pres exceeds the maximum value\n");
+		dev_err(pwmchip_parent(chip), "pres exceeds the maximum value\n");
 		return -EINVAL;
 	} else if (shift > 0) {
 		*pres = shift;
@@ -321,7 +321,7 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 		ret = atmel_pwm_calculate_cprd_and_pres(chip, clkrate, state, &cprd,
 							&pres);
 		if (ret) {
-			dev_err(chip->dev,
+			dev_err(pwmchip_parent(chip),
 				"failed to calculate cprd and prescaler\n");
 			return ret;
 		}
@@ -333,7 +333,7 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 		} else {
 			ret = clk_enable(atmel_pwm->clk);
 			if (ret) {
-				dev_err(chip->dev, "failed to enable clock\n");
+				dev_err(pwmchip_parent(chip), "failed to enable clock\n");
 				return ret;
 			}
 		}
@@ -462,8 +462,9 @@ static const struct of_device_id atmel_pwm_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, atmel_pwm_dt_ids);
 
-static int atmel_pwm_enable_clk_if_on(struct atmel_pwm_chip *atmel_pwm, bool on)
+static int atmel_pwm_enable_clk_if_on(struct pwm_chip *chip, bool on)
 {
+	struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
 	unsigned int i, cnt = 0;
 	unsigned long sr;
 	int ret = 0;
@@ -480,7 +481,7 @@ static int atmel_pwm_enable_clk_if_on(struct atmel_pwm_chip *atmel_pwm, bool on)
 	for (i = 0; i < cnt; i++) {
 		ret = clk_enable(atmel_pwm->clk);
 		if (ret) {
-			dev_err(atmel_pwm->chip.dev,
+			dev_err(pwmchip_parent(chip),
 				"failed to enable clock for pwm %pe\n",
 				ERR_PTR(ret));
 
@@ -525,7 +526,7 @@ static int atmel_pwm_probe(struct platform_device *pdev)
 	atmel_pwm->chip.ops = &atmel_pwm_ops;
 	atmel_pwm->chip.npwm = 4;
 
-	ret = atmel_pwm_enable_clk_if_on(atmel_pwm, true);
+	ret = atmel_pwm_enable_clk_if_on(&atmel_pwm->chip, true);
 	if (ret < 0)
 		return ret;
 
@@ -538,7 +539,7 @@ static int atmel_pwm_probe(struct platform_device *pdev)
 	return 0;
 
 disable_clk:
-	atmel_pwm_enable_clk_if_on(atmel_pwm, false);
+	atmel_pwm_enable_clk_if_on(&atmel_pwm->chip, false);
 
 	return ret;
 }
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:37 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:37 +0100
Subject: [PATCH v4 023/115] pwm: meson: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <52b4ea8c74ef274832b06bfc57c9706c140dd329.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-meson.c | 38 +++++++++++++++++++++-----------------
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index 5bea53243ed2..640d6fe63799 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -122,7 +122,7 @@ static int meson_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
 {
 	struct meson_pwm *meson = to_meson_pwm(chip);
 	struct meson_pwm_channel *channel = &meson->channels[pwm->hwpwm];
-	struct device *dev = chip->dev;
+	struct device *dev = pwmchip_parent(chip);
 	int err;
 
 	err = clk_prepare_enable(channel->clk);
@@ -143,9 +143,10 @@ static void meson_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
 	clk_disable_unprepare(channel->clk);
 }
 
-static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm,
+static int meson_pwm_calc(struct pwm_chip *chip, struct pwm_device *pwm,
 			  const struct pwm_state *state)
 {
+	struct meson_pwm *meson = to_meson_pwm(chip);
 	struct meson_pwm_channel *channel = &meson->channels[pwm->hwpwm];
 	unsigned int cnt, duty_cnt;
 	unsigned long fin_freq;
@@ -169,19 +170,19 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm,
 
 	fin_freq = clk_round_rate(channel->clk, freq);
 	if (fin_freq == 0) {
-		dev_err(meson->chip.dev, "invalid source clock frequency\n");
+		dev_err(pwmchip_parent(chip), "invalid source clock frequency\n");
 		return -EINVAL;
 	}
 
-	dev_dbg(meson->chip.dev, "fin_freq: %lu Hz\n", fin_freq);
+	dev_dbg(pwmchip_parent(chip), "fin_freq: %lu Hz\n", fin_freq);
 
 	cnt = div_u64(fin_freq * period, NSEC_PER_SEC);
 	if (cnt > 0xffff) {
-		dev_err(meson->chip.dev, "unable to get period cnt\n");
+		dev_err(pwmchip_parent(chip), "unable to get period cnt\n");
 		return -EINVAL;
 	}
 
-	dev_dbg(meson->chip.dev, "period=%llu cnt=%u\n", period, cnt);
+	dev_dbg(pwmchip_parent(chip), "period=%llu cnt=%u\n", period, cnt);
 
 	if (duty == period) {
 		channel->hi = cnt;
@@ -192,7 +193,7 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm,
 	} else {
 		duty_cnt = div_u64(fin_freq * duty, NSEC_PER_SEC);
 
-		dev_dbg(meson->chip.dev, "duty=%llu duty_cnt=%u\n", duty, duty_cnt);
+		dev_dbg(pwmchip_parent(chip), "duty=%llu duty_cnt=%u\n", duty, duty_cnt);
 
 		channel->hi = duty_cnt;
 		channel->lo = cnt - duty_cnt;
@@ -203,8 +204,9 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm,
 	return 0;
 }
 
-static void meson_pwm_enable(struct meson_pwm *meson, struct pwm_device *pwm)
+static void meson_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 {
+	struct meson_pwm *meson = to_meson_pwm(chip);
 	struct meson_pwm_channel *channel = &meson->channels[pwm->hwpwm];
 	struct meson_pwm_channel_data *channel_data;
 	unsigned long flags;
@@ -215,7 +217,7 @@ static void meson_pwm_enable(struct meson_pwm *meson, struct pwm_device *pwm)
 
 	err = clk_set_rate(channel->clk, channel->rate);
 	if (err)
-		dev_err(meson->chip.dev, "setting clock rate failed\n");
+		dev_err(pwmchip_parent(chip), "setting clock rate failed\n");
 
 	spin_lock_irqsave(&meson->lock, flags);
 
@@ -230,8 +232,9 @@ static void meson_pwm_enable(struct meson_pwm *meson, struct pwm_device *pwm)
 	spin_unlock_irqrestore(&meson->lock, flags);
 }
 
-static void meson_pwm_disable(struct meson_pwm *meson, struct pwm_device *pwm)
+static void meson_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
 {
+	struct meson_pwm *meson = to_meson_pwm(chip);
 	unsigned long flags;
 	u32 value;
 
@@ -269,16 +272,16 @@ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 			channel->hi = ~0;
 			channel->lo = 0;
 
-			meson_pwm_enable(meson, pwm);
+			meson_pwm_enable(chip, pwm);
 		} else {
-			meson_pwm_disable(meson, pwm);
+			meson_pwm_disable(chip, pwm);
 		}
 	} else {
-		err = meson_pwm_calc(meson, pwm, state);
+		err = meson_pwm_calc(chip, pwm, state);
 		if (err < 0)
 			return err;
 
-		meson_pwm_enable(meson, pwm);
+		meson_pwm_enable(chip, pwm);
 	}
 
 	return 0;
@@ -432,10 +435,11 @@ static const struct of_device_id meson_pwm_matches[] = {
 };
 MODULE_DEVICE_TABLE(of, meson_pwm_matches);
 
-static int meson_pwm_init_channels(struct meson_pwm *meson)
+static int meson_pwm_init_channels(struct pwm_chip *chip)
 {
+	struct meson_pwm *meson = to_meson_pwm(chip);
 	struct clk_parent_data mux_parent_data[MESON_MAX_MUX_PARENTS] = {};
-	struct device *dev = meson->chip.dev;
+	struct device *dev = pwmchip_parent(chip);
 	unsigned int i;
 	char name[255];
 	int err;
@@ -549,7 +553,7 @@ static int meson_pwm_probe(struct platform_device *pdev)
 
 	meson->data = of_device_get_match_data(&pdev->dev);
 
-	err = meson_pwm_init_channels(meson);
+	err = meson_pwm_init_channels(&meson->chip);
 	if (err < 0)
 		return err;
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:34 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:34 +0100
Subject: [PATCH v4 020/115] pwm: lpc18xx-sct: Make use of parent device pointer in driver data
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <107f776436bda40947b00096e966c527dfac98f6.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, make use of the
already existing pointer to the parent device in driver data. However
rename the pointer to "parent" for consistency with other drivers.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-lpc18xx-sct.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
index b3d4a955aa31..9e1db43a5171 100644
--- a/drivers/pwm/pwm-lpc18xx-sct.c
+++ b/drivers/pwm/pwm-lpc18xx-sct.c
@@ -92,7 +92,7 @@ struct lpc18xx_pwm_data {
 };
 
 struct lpc18xx_pwm_chip {
-	struct device *dev;
+	struct device *parent;
 	struct pwm_chip chip;
 	void __iomem *base;
 	struct clk *pwm_clk;
@@ -198,7 +198,7 @@ static int lpc18xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	if (period_ns < lpc18xx_pwm->min_period_ns ||
 	    period_ns > lpc18xx_pwm->max_period_ns) {
-		dev_err(chip->dev, "period %d not in range\n", period_ns);
+		dev_err(lpc18xx_pwm->parent, "period %d not in range\n", period_ns);
 		return -ERANGE;
 	}
 
@@ -214,7 +214,7 @@ static int lpc18xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	 */
 	if (requested_events > 2 && lpc18xx_pwm->period_ns != period_ns &&
 	    lpc18xx_pwm->period_ns) {
-		dev_err(chip->dev, "conflicting period requested for PWM %u\n",
+		dev_err(lpc18xx_pwm->parent, "conflicting period requested for PWM %u\n",
 			pwm->hwpwm);
 		mutex_unlock(&lpc18xx_pwm->period_lock);
 		return -EBUSY;
@@ -291,7 +291,7 @@ static int lpc18xx_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
 				    LPC18XX_PWM_EVENT_MAX);
 
 	if (event >= LPC18XX_PWM_EVENT_MAX) {
-		dev_err(lpc18xx_pwm->dev,
+		dev_err(lpc18xx_pwm->parent,
 			"maximum number of simultaneous channels reached\n");
 		return -EBUSY;
 	}
@@ -360,7 +360,7 @@ static int lpc18xx_pwm_probe(struct platform_device *pdev)
 	if (!lpc18xx_pwm)
 		return -ENOMEM;
 
-	lpc18xx_pwm->dev = &pdev->dev;
+	lpc18xx_pwm->parent = &pdev->dev;
 
 	lpc18xx_pwm->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(lpc18xx_pwm->base))
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:36 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:36 +0100
Subject: [PATCH v4 022/115] pwm: mediatek: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <028a566d671a9ef14ed8e79818bfd05b19a234cf.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-mediatek.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 17d290f847af..d7d1c326e8cf 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -150,7 +150,7 @@ static int pwm_mediatek_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	if (clkdiv > PWM_CLK_DIV_MAX) {
 		pwm_mediatek_clk_disable(chip, pwm);
-		dev_err(chip->dev, "period of %d ns not supported\n", period_ns);
+		dev_err(pwmchip_parent(chip), "period of %d ns not supported\n", period_ns);
 		return -EINVAL;
 	}
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:38 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:38 +0100
Subject: [PATCH v4 024/115] pwm: mtk-disp: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <93ee3518cd35dd9ec88b83b9657c9857e7be58e3.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-mtk-disp.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index a72f7be36996..186aa5c04435 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -91,14 +91,14 @@ static int mtk_disp_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	if (!mdp->enabled) {
 		err = clk_prepare_enable(mdp->clk_main);
 		if (err < 0) {
-			dev_err(chip->dev, "Can't enable mdp->clk_main: %pe\n",
+			dev_err(pwmchip_parent(chip), "Can't enable mdp->clk_main: %pe\n",
 				ERR_PTR(err));
 			return err;
 		}
 
 		err = clk_prepare_enable(mdp->clk_mm);
 		if (err < 0) {
-			dev_err(chip->dev, "Can't enable mdp->clk_mm: %pe\n",
+			dev_err(pwmchip_parent(chip), "Can't enable mdp->clk_mm: %pe\n",
 				ERR_PTR(err));
 			clk_disable_unprepare(mdp->clk_main);
 			return err;
@@ -181,13 +181,13 @@ static int mtk_disp_pwm_get_state(struct pwm_chip *chip,
 
 	err = clk_prepare_enable(mdp->clk_main);
 	if (err < 0) {
-		dev_err(chip->dev, "Can't enable mdp->clk_main: %pe\n", ERR_PTR(err));
+		dev_err(pwmchip_parent(chip), "Can't enable mdp->clk_main: %pe\n", ERR_PTR(err));
 		return err;
 	}
 
 	err = clk_prepare_enable(mdp->clk_mm);
 	if (err < 0) {
-		dev_err(chip->dev, "Can't enable mdp->clk_mm: %pe\n", ERR_PTR(err));
+		dev_err(pwmchip_parent(chip), "Can't enable mdp->clk_mm: %pe\n", ERR_PTR(err));
 		clk_disable_unprepare(mdp->clk_main);
 		return err;
 	}
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:24 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:24 +0100
Subject: [PATCH v4 010/115] pwm: atmel-tcb: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <909399b9171a08433b16f81ca21efca47aa859d6.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-atmel-tcb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
index d42c897cb85e..80121ab81a01 100644
--- a/drivers/pwm/pwm-atmel-tcb.c
+++ b/drivers/pwm/pwm-atmel-tcb.c
@@ -327,7 +327,7 @@ static int atmel_tcb_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	if ((atcbpwm && atcbpwm->duty > 0 &&
 			atcbpwm->duty != atcbpwm->period) &&
 		(atcbpwm->div != i || atcbpwm->period != period)) {
-		dev_err(chip->dev,
+		dev_err(pwmchip_parent(chip),
 			"failed to configure period_ns: PWM group already configured with a different value\n");
 		return -EINVAL;
 	}
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:54 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:54 +0100
Subject: [PATCH v4 040/115] pwm: vt8500: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <c4dcb84818b34d2b26c349e62f6ff2f1c1726c59.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-vt8500.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index bdea60389487..ff5e76afbddf 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -53,8 +53,9 @@ struct vt8500_chip {
 #define to_vt8500_chip(chip)	container_of(chip, struct vt8500_chip, chip)
 
 #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
-static inline void vt8500_pwm_busy_wait(struct vt8500_chip *vt8500, int nr, u8 bitmask)
+static inline void vt8500_pwm_busy_wait(struct pwm_chip *chip, int nr, u8 bitmask)
 {
+	struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
 	int loops = msecs_to_loops(10);
 	u32 mask = bitmask << (nr << 8);
 
@@ -62,7 +63,7 @@ static inline void vt8500_pwm_busy_wait(struct vt8500_chip *vt8500, int nr, u8 b
 		cpu_relax();
 
 	if (unlikely(!loops))
-		dev_warn(vt8500->chip.dev, "Waiting for status bits 0x%x to clear timed out\n",
+		dev_warn(pwmchip_parent(chip), "Waiting for status bits 0x%x to clear timed out\n",
 			 mask);
 }
 
@@ -77,7 +78,7 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	err = clk_enable(vt8500->clk);
 	if (err < 0) {
-		dev_err(chip->dev, "failed to enable clock\n");
+		dev_err(pwmchip_parent(chip), "failed to enable clock\n");
 		return err;
 	}
 
@@ -103,18 +104,18 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	dc = div64_u64(c, period_ns);
 
 	writel(prescale, vt8500->base + REG_SCALAR(pwm->hwpwm));
-	vt8500_pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_SCALAR_UPDATE);
+	vt8500_pwm_busy_wait(chip, pwm->hwpwm, STATUS_SCALAR_UPDATE);
 
 	writel(pv, vt8500->base + REG_PERIOD(pwm->hwpwm));
-	vt8500_pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_PERIOD_UPDATE);
+	vt8500_pwm_busy_wait(chip, pwm->hwpwm, STATUS_PERIOD_UPDATE);
 
 	writel(dc, vt8500->base + REG_DUTY(pwm->hwpwm));
-	vt8500_pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_DUTY_UPDATE);
+	vt8500_pwm_busy_wait(chip, pwm->hwpwm, STATUS_DUTY_UPDATE);
 
 	val = readl(vt8500->base + REG_CTRL(pwm->hwpwm));
 	val |= CTRL_AUTOLOAD;
 	writel(val, vt8500->base + REG_CTRL(pwm->hwpwm));
-	vt8500_pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_CTRL_UPDATE);
+	vt8500_pwm_busy_wait(chip, pwm->hwpwm, STATUS_CTRL_UPDATE);
 
 	clk_disable(vt8500->clk);
 	return 0;
@@ -128,14 +129,14 @@ static int vt8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 
 	err = clk_enable(vt8500->clk);
 	if (err < 0) {
-		dev_err(chip->dev, "failed to enable clock\n");
+		dev_err(pwmchip_parent(chip), "failed to enable clock\n");
 		return err;
 	}
 
 	val = readl(vt8500->base + REG_CTRL(pwm->hwpwm));
 	val |= CTRL_ENABLE;
 	writel(val, vt8500->base + REG_CTRL(pwm->hwpwm));
-	vt8500_pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_CTRL_UPDATE);
+	vt8500_pwm_busy_wait(chip, pwm->hwpwm, STATUS_CTRL_UPDATE);
 
 	return 0;
 }
@@ -148,7 +149,7 @@ static void vt8500_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
 	val = readl(vt8500->base + REG_CTRL(pwm->hwpwm));
 	val &= ~CTRL_ENABLE;
 	writel(val, vt8500->base + REG_CTRL(pwm->hwpwm));
-	vt8500_pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_CTRL_UPDATE);
+	vt8500_pwm_busy_wait(chip, pwm->hwpwm, STATUS_CTRL_UPDATE);
 
 	clk_disable(vt8500->clk);
 }
@@ -168,7 +169,7 @@ static int vt8500_pwm_set_polarity(struct pwm_chip *chip,
 		val &= ~CTRL_INVERT;
 
 	writel(val, vt8500->base + REG_CTRL(pwm->hwpwm));
-	vt8500_pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_CTRL_UPDATE);
+	vt8500_pwm_busy_wait(chip, pwm->hwpwm, STATUS_CTRL_UPDATE);
 
 	return 0;
 }
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:44 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:44 +0100
Subject: [PATCH v4 030/115] pwm: samsung: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <2acfcb939f7a498db49bab3e5f3548096038d551.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-samsung.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 6e77302f7368..a97cae49406e 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -197,12 +197,12 @@ static unsigned long pwm_samsung_calc_tin(struct samsung_pwm_chip *our_chip,
 				return rate;
 		}
 
-		dev_warn(our_chip->chip.dev,
+		dev_warn(pwmchip_parent(&our_chip->chip),
 			"tclk of PWM %d is inoperational, using tdiv\n", chan);
 	}
 
 	rate = pwm_samsung_get_tin_rate(our_chip, chan);
-	dev_dbg(our_chip->chip.dev, "tin parent at %lu\n", rate);
+	dev_dbg(pwmchip_parent(&our_chip->chip), "tin parent at %lu\n", rate);
 
 	/*
 	 * Compare minimum PWM frequency that can be achieved with possible
@@ -232,7 +232,7 @@ static int pwm_samsung_request(struct pwm_chip *chip, struct pwm_device *pwm)
 	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
 
 	if (!(our_chip->variant.output_mask & BIT(pwm->hwpwm))) {
-		dev_warn(chip->dev,
+		dev_warn(pwmchip_parent(chip),
 			"tried to request PWM channel %d without output\n",
 			pwm->hwpwm);
 		return -EINVAL;
@@ -326,12 +326,12 @@ static int __pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 		period = NSEC_PER_SEC / period_ns;
 
-		dev_dbg(our_chip->chip.dev, "duty_ns=%d, period_ns=%d (%u)\n",
+		dev_dbg(pwmchip_parent(chip), "duty_ns=%d, period_ns=%d (%u)\n",
 						duty_ns, period_ns, period);
 
 		tin_rate = pwm_samsung_calc_tin(our_chip, pwm->hwpwm, period);
 
-		dev_dbg(our_chip->chip.dev, "tin_rate=%lu\n", tin_rate);
+		dev_dbg(pwmchip_parent(chip), "tin_rate=%lu\n", tin_rate);
 
 		tin_ns = NSEC_PER_SEC / tin_rate;
 		tcnt = period_ns / tin_ns;
@@ -355,8 +355,7 @@ static int __pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	/* -1UL will give 100% duty. */
 	--tcmp;
 
-	dev_dbg(our_chip->chip.dev,
-				"tin_ns=%u, tcmp=%u/%u\n", tin_ns, tcmp, tcnt);
+	dev_dbg(pwmchip_parent(chip), "tin_ns=%u, tcmp=%u/%u\n", tin_ns, tcmp, tcnt);
 
 	/* Update PWM registers. */
 	writel(tcnt, our_chip->base + REG_TCNTB(pwm->hwpwm));
@@ -368,7 +367,7 @@ static int __pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * shortly afer this update (before it autoreloaded the new values).
 	 */
 	if (oldtcmp == (u32) -1) {
-		dev_dbg(our_chip->chip.dev, "Forcing manual update");
+		dev_dbg(pwmchip_parent(chip), "Forcing manual update");
 		pwm_samsung_manual_update(our_chip, pwm);
 	}
 
@@ -509,7 +508,7 @@ MODULE_DEVICE_TABLE(of, samsung_pwm_matches);
 
 static int pwm_samsung_parse_dt(struct samsung_pwm_chip *our_chip)
 {
-	struct device_node *np = our_chip->chip.dev->of_node;
+	struct device_node *np = pwmchip_parent(&our_chip->chip)->of_node;
 	const struct of_device_id *match;
 	struct property *prop;
 	const __be32 *cur;
@@ -523,7 +522,7 @@ static int pwm_samsung_parse_dt(struct samsung_pwm_chip *our_chip)
 
 	of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) {
 		if (val >= SAMSUNG_PWM_NUM) {
-			dev_err(our_chip->chip.dev,
+			dev_err(pwmchip_parent(&our_chip->chip),
 				"%s: invalid channel index in samsung,pwm-outputs property\n",
 								__func__);
 			continue;
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:47 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:47 +0100
Subject: [PATCH v4 033/115] pwm: stm32: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <375190a81bd1521b90f27688feb43e6c9e9f7c98.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-stm32.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 5f10cba492ec..d1dc9e3ca2a1 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -94,7 +94,7 @@ static int stm32_pwm_raw_capture(struct stm32_pwm *priv, struct pwm_device *pwm,
 				 unsigned long tmo_ms, u32 *raw_prd,
 				 u32 *raw_dty)
 {
-	struct device *parent = priv->chip.dev->parent;
+	struct device *parent = pwmchip_parent(&priv->chip)->parent;
 	enum stm32_timers_dmas dma_id;
 	u32 ccen, ccr;
 	int ret;
@@ -170,7 +170,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	ret = clk_enable(priv->clk);
 	if (ret) {
-		dev_err(priv->chip.dev, "failed to enable counter clock\n");
+		dev_err(pwmchip_parent(chip), "failed to enable counter clock\n");
 		goto unlock;
 	}
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:41 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:41 +0100
Subject: [PATCH v4 027/115] pwm: raspberrypi-poe: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <01d8e34142c626cfd1ee6c8972728592286b22c8.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-raspberrypi-poe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-raspberrypi-poe.c b/drivers/pwm/pwm-raspberrypi-poe.c
index 1ad814fdec6b..f10e8a624c51 100644
--- a/drivers/pwm/pwm-raspberrypi-poe.c
+++ b/drivers/pwm/pwm-raspberrypi-poe.c
@@ -122,7 +122,7 @@ static int raspberrypi_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	ret = raspberrypi_pwm_set_property(rpipwm->firmware, RPI_PWM_CUR_DUTY_REG,
 					   duty_cycle);
 	if (ret) {
-		dev_err(chip->dev, "Failed to set duty cycle: %pe\n",
+		dev_err(pwmchip_parent(chip), "Failed to set duty cycle: %pe\n",
 			ERR_PTR(ret));
 		return ret;
 	}
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:32 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:32 +0100
Subject: [PATCH v4 018/115] pwm: imx27: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <5e8f73d0742507f4e7ddad050d2e79812a1cd62f.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-imx27.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 7d9bc43f12b0..5d796453519a 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -145,7 +145,7 @@ static int pwm_imx27_get_state(struct pwm_chip *chip,
 		state->polarity = PWM_POLARITY_INVERSED;
 		break;
 	default:
-		dev_warn(chip->dev, "can't set polarity, output disconnected");
+		dev_warn(pwmchip_parent(chip), "can't set polarity, output disconnected");
 	}
 
 	prescaler = MX3_PWMCR_PRESCALER_GET(val);
@@ -177,7 +177,7 @@ static int pwm_imx27_get_state(struct pwm_chip *chip,
 static void pwm_imx27_sw_reset(struct pwm_chip *chip)
 {
 	struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
-	struct device *dev = chip->dev;
+	struct device *dev = pwmchip_parent(chip);
 	int wait_count = 0;
 	u32 cr;
 
@@ -196,7 +196,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
 				     struct pwm_device *pwm)
 {
 	struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
-	struct device *dev = chip->dev;
+	struct device *dev = pwmchip_parent(chip);
 	unsigned int period_ms;
 	int fifoav;
 	u32 sr;
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:48 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:48 +0100
Subject: [PATCH v4 034/115] pwm: stmpe: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <57e5d3873f70b3568276acf19e4aab44aca38b2f.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-stmpe.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pwm/pwm-stmpe.c b/drivers/pwm/pwm-stmpe.c
index d730631c6583..941b1e218e35 100644
--- a/drivers/pwm/pwm-stmpe.c
+++ b/drivers/pwm/pwm-stmpe.c
@@ -44,7 +44,7 @@ static int stmpe_24xx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 
 	ret = stmpe_reg_read(stmpe_pwm->stmpe, STMPE24XX_PWMCS);
 	if (ret < 0) {
-		dev_err(chip->dev, "error reading PWM#%u control\n",
+		dev_err(pwmchip_parent(chip), "error reading PWM#%u control\n",
 			pwm->hwpwm);
 		return ret;
 	}
@@ -53,7 +53,7 @@ static int stmpe_24xx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 
 	ret = stmpe_reg_write(stmpe_pwm->stmpe, STMPE24XX_PWMCS, value);
 	if (ret) {
-		dev_err(chip->dev, "error writing PWM#%u control\n",
+		dev_err(pwmchip_parent(chip), "error writing PWM#%u control\n",
 			pwm->hwpwm);
 		return ret;
 	}
@@ -70,7 +70,7 @@ static int stmpe_24xx_pwm_disable(struct pwm_chip *chip,
 
 	ret = stmpe_reg_read(stmpe_pwm->stmpe, STMPE24XX_PWMCS);
 	if (ret < 0) {
-		dev_err(chip->dev, "error reading PWM#%u control\n",
+		dev_err(pwmchip_parent(chip), "error reading PWM#%u control\n",
 			pwm->hwpwm);
 		return ret;
 	}
@@ -79,7 +79,7 @@ static int stmpe_24xx_pwm_disable(struct pwm_chip *chip,
 
 	ret = stmpe_reg_write(stmpe_pwm->stmpe, STMPE24XX_PWMCS, value);
 	if (ret)
-		dev_err(chip->dev, "error writing PWM#%u control\n",
+		dev_err(pwmchip_parent(chip), "error writing PWM#%u control\n",
 			pwm->hwpwm);
 	return ret;
 }
@@ -125,7 +125,7 @@ static int stmpe_24xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 		ret = stmpe_set_altfunc(stmpe_pwm->stmpe, BIT(pin),
 					STMPE_BLOCK_PWM);
 		if (ret) {
-			dev_err(chip->dev, "unable to connect PWM#%u to pin\n",
+			dev_err(pwmchip_parent(chip), "unable to connect PWM#%u to pin\n",
 				pwm->hwpwm);
 			return ret;
 		}
@@ -150,7 +150,7 @@ static int stmpe_24xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 		return -ENODEV;
 	}
 
-	dev_dbg(chip->dev, "PWM#%u: config duty %d ns, period %d ns\n",
+	dev_dbg(pwmchip_parent(chip), "PWM#%u: config duty %d ns, period %d ns\n",
 		pwm->hwpwm, duty_ns, period_ns);
 
 	if (duty_ns == 0) {
@@ -216,7 +216,7 @@ static int stmpe_24xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 			program[1] = BRANCH;
 		}
 
-		dev_dbg(chip->dev,
+		dev_dbg(pwmchip_parent(chip),
 			"PWM#%u: value = %02x, last_duty = %02x, program=%04x,%04x,%04x\n",
 			pwm->hwpwm, value, last, program[0], program[1],
 			program[2]);
@@ -233,7 +233,7 @@ static int stmpe_24xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 		ret = stmpe_reg_write(stmpe_pwm->stmpe, offset, value);
 		if (ret) {
-			dev_err(chip->dev, "error writing register %02x: %d\n",
+			dev_err(pwmchip_parent(chip), "error writing register %02x: %d\n",
 				offset, ret);
 			return ret;
 		}
@@ -242,7 +242,7 @@ static int stmpe_24xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 		ret = stmpe_reg_write(stmpe_pwm->stmpe, offset, value);
 		if (ret) {
-			dev_err(chip->dev, "error writing register %02x: %d\n",
+			dev_err(pwmchip_parent(chip), "error writing register %02x: %d\n",
 				offset, ret);
 			return ret;
 		}
@@ -255,7 +255,7 @@ static int stmpe_24xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	/* Sleep for 200ms so we're sure it will take effect */
 	msleep(200);
 
-	dev_dbg(chip->dev, "programmed PWM#%u, %u bytes\n", pwm->hwpwm, i);
+	dev_dbg(pwmchip_parent(chip), "programmed PWM#%u, %u bytes\n", pwm->hwpwm, i);
 
 	return 0;
 }
-- 
2.42.0



From quic_snehshah at quicinc.com  Wed Dec  6 03:47:25 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Wed, 6 Dec 2023 17:17:25 +0530
Subject: [PATCH net-next] net: stmmac: qcom-ethqos: Add sysfs nodes for
 qcom ethqos
In-Reply-To: <3e4a1b9c-ed0f-466e-ba11-fc5b7ef308a1@lunn.ch>
References: <20231204084854.31543-1-quic_snehshah@quicinc.com>
 <3e4a1b9c-ed0f-466e-ba11-fc5b7ef308a1@lunn.ch>
Message-ID: <5d5f3955-fc30-428c-99f4-42f9b7580a84@quicinc.com>



On 12/5/2023 8:38 PM, Andrew Lunn wrote:
> On Mon, Dec 04, 2023 at 02:18:54PM +0530, Sneh Shah wrote:
>> Add sysfs nodes to conifigure routing of specific vlan id to GVM queue.
>> GVM queue is not exposed to PVM stmmac, so TC ops can't configure routing.
> 
> Adding files in /sysfs has ~0 chance of being accepted.
> 
> As requested, please explain what all these different hardware blocks
> are, and what you are trying to achieve. We can then recommend the
> correct interface.
> 
>     Andrew
> 
> ---
> pw-bot: cr

We have multiVM Architecture here. PVM  will have stmmac running with 4 Rx Tx queues. stmmac in PVM is responsible to configure whole ethernet HW MAC/DMA/MTL ( including clocks, regulators and other core bsp elements).
In GVM we have thin Ethernet driver, which is responsible to configure and manage only 1 Rx/TX queue, i.e 5th Rx/Tx ethernet queue. GVM can't access any other resisters apart from this 5th queue specific MTL and DMA registers.

We need to route vlan traffic of a specific Priority to GVM Queue (Ethernet queue 5) via programming a MAC register. The MAC register is not accessible in GVM and has to be programmed from PVM. stmmac already has TC OPS to program this routing via vlan priority. However, as PVM has only 4 queues enabled, TC tool will not take 5th queue as input. Hence, these nodes were added to conifure the MAC register to route specific vlan packets to 5th queue in GVM.

Note: The queues mentioned above are HW MTL Queues and DMA Channels. The routing can be done in the HW itself based on vlan pcp before the packets reach to driver.




From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:04 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:04 +0100
Subject: [PATCH v4 050/115] pwm: bcm-iproc: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e15c08ae19c3cf1d95768449283dcfc87894b61f.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-bcm-iproc driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-bcm-iproc.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/pwm/pwm-bcm-iproc.c b/drivers/pwm/pwm-bcm-iproc.c
index 758254025683..f4c9f10e490e 100644
--- a/drivers/pwm/pwm-bcm-iproc.c
+++ b/drivers/pwm/pwm-bcm-iproc.c
@@ -34,14 +34,13 @@
 #define IPROC_PWM_PRESCALE_MAX			0x3f
 
 struct iproc_pwmc {
-	struct pwm_chip chip;
 	void __iomem *base;
 	struct clk *clk;
 };
 
 static inline struct iproc_pwmc *to_iproc_pwmc(struct pwm_chip *chip)
 {
-	return container_of(chip, struct iproc_pwmc, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static void iproc_pwmc_enable(struct iproc_pwmc *ip, unsigned int channel)
@@ -187,20 +186,20 @@ static const struct pwm_ops iproc_pwm_ops = {
 
 static int iproc_pwmc_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct iproc_pwmc *ip;
 	unsigned int i;
 	u32 value;
 	int ret;
 
-	ip = devm_kzalloc(&pdev->dev, sizeof(*ip), GFP_KERNEL);
-	if (!ip)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 4, sizeof(*ip));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	ip = to_iproc_pwmc(chip);
 
 	platform_set_drvdata(pdev, ip);
 
-	ip->chip.dev = &pdev->dev;
-	ip->chip.ops = &iproc_pwm_ops;
-	ip->chip.npwm = 4;
+	chip->ops = &iproc_pwm_ops;
 
 	ip->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(ip->base))
@@ -214,14 +213,14 @@ static int iproc_pwmc_probe(struct platform_device *pdev)
 	/* Set full drive and normal polarity for all channels */
 	value = readl(ip->base + IPROC_PWM_CTRL_OFFSET);
 
-	for (i = 0; i < ip->chip.npwm; i++) {
+	for (i = 0; i < chip->npwm; i++) {
 		value &= ~(1 << IPROC_PWM_CTRL_TYPE_SHIFT(i));
 		value |= 1 << IPROC_PWM_CTRL_POLARITY_SHIFT(i);
 	}
 
 	writel(value, ip->base + IPROC_PWM_CTRL_OFFSET);
 
-	ret = devm_pwmchip_add(&pdev->dev, &ip->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0)
 		return dev_err_probe(&pdev->dev, ret,
 				     "failed to add PWM chip\n");
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:49 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:49 +0100
Subject: [PATCH v4 035/115] pwm: sun4i: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e3f7af28e1a9c18e021be4d2180be68015a345e1.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-sun4i.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 1a439025540d..44edf1ce5739 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -245,7 +245,7 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	if (!cstate.enabled) {
 		ret = clk_prepare_enable(sun4i_pwm->clk);
 		if (ret) {
-			dev_err(chip->dev, "failed to enable PWM clock\n");
+			dev_err(pwmchip_parent(chip), "failed to enable PWM clock\n");
 			return ret;
 		}
 	}
@@ -253,7 +253,7 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	ret = sun4i_pwm_calculate(sun4i_pwm, state, &duty, &period, &prescaler,
 				  &bypass);
 	if (ret) {
-		dev_err(chip->dev, "period exceeds the maximum value\n");
+		dev_err(pwmchip_parent(chip), "period exceeds the maximum value\n");
 		if (!cstate.enabled)
 			clk_disable_unprepare(sun4i_pwm->clk);
 		return ret;
-- 
2.42.0



From claudiu.beznea at tuxon.dev  Wed Dec  6 03:48:26 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Wed, 6 Dec 2023 13:48:26 +0200
Subject: [PATCH 13/14] arm64: dts: renesas: rzg3s-smarc-som: Enable
 Ethernet interfaces
In-Reply-To: <CAMuHMdXs9tKo9W31f5OybNR51a_i99Lyx=wHe0GLrADN_8KZTg@mail.gmail.com>
References: <20231120070024.4079344-1-claudiu.beznea.uj@bp.renesas.com>
 <20231120070024.4079344-14-claudiu.beznea.uj@bp.renesas.com>
 <CAMuHMdXs9tKo9W31f5OybNR51a_i99Lyx=wHe0GLrADN_8KZTg@mail.gmail.com>
Message-ID: <89b68781-b552-499d-a8f2-df4dccbb02e0@tuxon.dev>

Hi, Geert,

On 06.12.2023 13:22, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> Thanks for your patch!
> 
> On Mon, Nov 20, 2023 at 8:03?AM Claudiu <claudiu.beznea at tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
>>
>> RZ/G3S Smarc Module has Ethernet PHYs (KSZ9131) connected to each Ethernet
>> IP. For this add proper DT bindings to enable the Ethernet communication
>> though these PHYs.
>>
>> The interface b/w PHYs and MACs is RGMII. The skew settings were set to
>> zero as based on phy-mode (rgmii-id) the KSZ9131 driver enables internal
>> DLL which adds 2ns delay b/w clocks (TX/RX) and data signals.
> 
> So shouldn't you just use phy-mode "rgmii" instead?

I chose it like this for simpler configuration of the skew settings. The
PHY supports fixed 2ns delays which is enough for RGMII. And this is
configured based on phy-mode="rgmii-id". As this delay depends also on
soldering length I consider it better this way.

The other variant would have been using phy-mode="rgmii" + skew settings.

Also, same phy-mode is used by rzg2ul-smarc-som.dtsi which is using the
same PHY.

>> Different pin settings were applied to TXC, TX_CTL compared with the rest
>> of the RGMII pins to comply with requirements for these pins imposed by
>> HW manual of RZ/G3S (see chapters "Ether Ch0 Voltage Mode Control
>> Register (ETH0_POC)", "Ether Ch1 Voltage Mode Control Register (ETH1_POC)",
>> for power source selection, "Ether MII/RGMII Mode Control Register
>> (ETH_MODE)" for output-enable and "Input Enable Control Register (IEN_m)"
>> for input-enable configurations).
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> 
>> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
>> @@ -25,7 +25,10 @@ / {
>>
>>         aliases {
>>                 mmc0 = &sdhi0;
>> -#if !SW_SD2_EN
>> +#if SW_SD2_EN
> 
> Cfr. my comment on [PATCH 11/14], this looks odd...
> 
>> +               eth0 = &eth0;
>> +               eth1 = &eth1;
>> +#else
>>                 mmc2 = &sdhi2;
>>  #endif
>>         };
>> @@ -81,6 +84,64 @@ vcc_sdhi2: regulator2 {
>>         };
>>  };
>>
>> +#if SW_SD2_EN
> 
> Likewise.
> 
>> +&eth0 {
>> +       pinctrl-0 = <&eth0_pins>;
>> +       pinctrl-names = "default";
>> +       phy-handle = <&phy0>;
>> +       phy-mode = "rgmii-id";
>> +       #address-cells = <1>;
>> +       #size-cells = <0>;
> 
> #{address,size}-cells should be in the SoC-specific .dtsi.
> Same for eth1.
> 
>> +       status = "okay";
> 
> The rest LGTM.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:07 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:07 +0100
Subject: [PATCH v4 053/115] pwm: brcmstb: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <806f32f9b50445908879b335e61a95f5403f34b1.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-brcmstb driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-brcmstb.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-brcmstb.c b/drivers/pwm/pwm-brcmstb.c
index 0fdeb0b2dbf3..82d27d07ba91 100644
--- a/drivers/pwm/pwm-brcmstb.c
+++ b/drivers/pwm/pwm-brcmstb.c
@@ -54,7 +54,6 @@
 struct brcmstb_pwm {
 	void __iomem *base;
 	struct clk *clk;
-	struct pwm_chip chip;
 };
 
 static inline u32 brcmstb_pwm_readl(struct brcmstb_pwm *p,
@@ -77,7 +76,7 @@ static inline void brcmstb_pwm_writel(struct brcmstb_pwm *p, u32 value,
 
 static inline struct brcmstb_pwm *to_brcmstb_pwm(struct pwm_chip *chip)
 {
-	return container_of(chip, struct brcmstb_pwm, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 /*
@@ -230,12 +229,14 @@ MODULE_DEVICE_TABLE(of, brcmstb_pwm_of_match);
 
 static int brcmstb_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct brcmstb_pwm *p;
 	int ret;
 
-	p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
-	if (!p)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 2, sizeof(*p));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	p = to_brcmstb_pwm(chip);
 
 	p->clk = devm_clk_get_enabled(&pdev->dev, NULL);
 	if (IS_ERR(p->clk))
@@ -244,15 +245,13 @@ static int brcmstb_pwm_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, p);
 
-	p->chip.dev = &pdev->dev;
-	p->chip.ops = &brcmstb_pwm_ops;
-	p->chip.npwm = 2;
+	chip->ops = &brcmstb_pwm_ops;
 
 	p->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(p->base))
 		return PTR_ERR(p->base);
 
-	ret = devm_pwmchip_add(&pdev->dev, &p->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret)
 		return dev_err_probe(&pdev->dev, ret, "failed to add PWM chip\n");
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:09 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:09 +0100
Subject: [PATCH v4 055/115] pwm: clps711x: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e14e65eee15cee08c3b455691d6ade1844495f0d.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-clps711x driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-clps711x.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
index 42179b3f7ec3..9b80077fef20 100644
--- a/drivers/pwm/pwm-clps711x.c
+++ b/drivers/pwm/pwm-clps711x.c
@@ -12,7 +12,6 @@
 #include <linux/pwm.h>
 
 struct clps711x_chip {
-	struct pwm_chip chip;
 	void __iomem *pmpcon;
 	struct clk *clk;
 	spinlock_t lock;
@@ -20,7 +19,7 @@ struct clps711x_chip {
 
 static inline struct clps711x_chip *to_clps711x_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct clps711x_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
@@ -85,11 +84,13 @@ static struct pwm_device *clps711x_pwm_xlate(struct pwm_chip *chip,
 
 static int clps711x_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct clps711x_chip *priv;
 
-	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
-	if (!priv)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 2, sizeof(*priv));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	priv = to_clps711x_chip(chip);
 
 	priv->pmpcon = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(priv->pmpcon))
@@ -99,15 +100,13 @@ static int clps711x_pwm_probe(struct platform_device *pdev)
 	if (IS_ERR(priv->clk))
 		return PTR_ERR(priv->clk);
 
-	priv->chip.ops = &clps711x_pwm_ops;
-	priv->chip.dev = &pdev->dev;
-	priv->chip.npwm = 2;
-	priv->chip.of_xlate = clps711x_pwm_xlate;
-	priv->chip.of_pwm_n_cells = 1;
+	chip->ops = &clps711x_pwm_ops;
+	chip->of_xlate = clps711x_pwm_xlate;
+	chip->of_pwm_n_cells = 1;
 
 	spin_lock_init(&priv->lock);
 
-	return devm_pwmchip_add(&pdev->dev, &priv->chip);
+	return devm_pwmchip_add(&pdev->dev, chip);
 }
 
 static const struct of_device_id __maybe_unused clps711x_pwm_dt_ids[] = {
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:02 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:02 +0100
Subject: [PATCH v4 048/115] pwm: atmel-tcb: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <c3f4f985fe02cb5a0889dc182a44a26d4bc84933.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-atmel-tcb driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-atmel-tcb.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
index 80121ab81a01..0663685532ec 100644
--- a/drivers/pwm/pwm-atmel-tcb.c
+++ b/drivers/pwm/pwm-atmel-tcb.c
@@ -47,7 +47,6 @@ struct atmel_tcb_channel {
 };
 
 struct atmel_tcb_pwm_chip {
-	struct pwm_chip chip;
 	spinlock_t lock;
 	u8 channel;
 	u8 width;
@@ -63,7 +62,7 @@ static const u8 atmel_tcb_divisors[] = { 2, 8, 32, 128, 0, };
 
 static inline struct atmel_tcb_pwm_chip *to_tcb_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct atmel_tcb_pwm_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int atmel_tcb_pwm_request(struct pwm_chip *chip,
@@ -389,6 +388,7 @@ static const struct of_device_id atmel_tcb_of_match[] = {
 static int atmel_tcb_pwm_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *match;
+	struct pwm_chip *chip;
 	struct atmel_tcb_pwm_chip *tcbpwm;
 	const struct atmel_tcb_config *config;
 	struct device_node *np = pdev->dev.of_node;
@@ -396,9 +396,10 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
 	int err;
 	int channel;
 
-	tcbpwm = devm_kzalloc(&pdev->dev, sizeof(*tcbpwm), GFP_KERNEL);
-	if (tcbpwm == NULL)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, NPWM, sizeof(*tcbpwm));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	tcbpwm = to_tcb_chip(chip);
 
 	err = of_property_read_u32(np, "reg", &channel);
 	if (err < 0) {
@@ -436,9 +437,7 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
 		}
 	}
 
-	tcbpwm->chip.dev = &pdev->dev;
-	tcbpwm->chip.ops = &atmel_tcb_pwm_ops;
-	tcbpwm->chip.npwm = NPWM;
+	chip->ops = &atmel_tcb_pwm_ops;
 	tcbpwm->channel = channel;
 	tcbpwm->width = config->counter_width;
 
@@ -448,11 +447,11 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
 
 	spin_lock_init(&tcbpwm->lock);
 
-	err = pwmchip_add(&tcbpwm->chip);
+	err = pwmchip_add(chip);
 	if (err < 0)
 		goto err_disable_clk;
 
-	platform_set_drvdata(pdev, tcbpwm);
+	platform_set_drvdata(pdev, chip);
 
 	return 0;
 
@@ -473,9 +472,10 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
 
 static void atmel_tcb_pwm_remove(struct platform_device *pdev)
 {
-	struct atmel_tcb_pwm_chip *tcbpwm = platform_get_drvdata(pdev);
+	struct pwm_chip *chip = platform_get_drvdata(pdev);
+	struct atmel_tcb_pwm_chip *tcbpwm = to_tcb_chip(chip);
 
-	pwmchip_remove(&tcbpwm->chip);
+	pwmchip_remove(chip);
 
 	clk_disable_unprepare(tcbpwm->slow_clk);
 	clk_put(tcbpwm->gclk);
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:03 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:03 +0100
Subject: [PATCH v4 049/115] pwm: bcm2835: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <237e4923fbc4e78e30fb4103b584557ac43a2458.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-bcm2835 driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-bcm2835.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index ab30667f4f95..826f0494dc5f 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -24,7 +24,6 @@
 #define PERIOD_MIN		0x2
 
 struct bcm2835_pwm {
-	struct pwm_chip chip;
 	struct device *dev;
 	void __iomem *base;
 	struct clk *clk;
@@ -32,7 +31,7 @@ struct bcm2835_pwm {
 
 static inline struct bcm2835_pwm *to_bcm2835_pwm(struct pwm_chip *chip)
 {
-	return container_of(chip, struct bcm2835_pwm, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int bcm2835_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
@@ -133,12 +132,14 @@ static const struct pwm_ops bcm2835_pwm_ops = {
 
 static int bcm2835_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct bcm2835_pwm *pc;
 	int ret;
 
-	pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
-	if (!pc)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 2, sizeof(*pc));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	pc = to_bcm2835_pwm(chip);
 
 	pc->dev = &pdev->dev;
 
@@ -151,13 +152,11 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
 				     "clock not found\n");
 
-	pc->chip.dev = &pdev->dev;
-	pc->chip.ops = &bcm2835_pwm_ops;
-	pc->chip.npwm = 2;
+	chip->ops = &bcm2835_pwm_ops;
 
 	platform_set_drvdata(pdev, pc);
 
-	ret = devm_pwmchip_add(&pdev->dev, &pc->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0)
 		return dev_err_probe(&pdev->dev, ret,
 				     "failed to add pwmchip\n");
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:00 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:00 +0100
Subject: [PATCH v4 046/115] pwm: atmel-hlcdc: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <626279339e6088d5209b0b3d6638250402f6834c.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-atme-hlcdc driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-atmel-hlcdc.c | 35 ++++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
index 3f2c5031a3ba..aa1b67b6f2ea 100644
--- a/drivers/pwm/pwm-atmel-hlcdc.c
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -28,7 +28,6 @@ struct atmel_hlcdc_pwm_errata {
 };
 
 struct atmel_hlcdc_pwm {
-	struct pwm_chip chip;
 	struct atmel_hlcdc *hlcdc;
 	struct clk *cur_clk;
 	const struct atmel_hlcdc_pwm_errata *errata;
@@ -36,7 +35,7 @@ struct atmel_hlcdc_pwm {
 
 static inline struct atmel_hlcdc_pwm *to_atmel_hlcdc_pwm(struct pwm_chip *chip)
 {
-	return container_of(chip, struct atmel_hlcdc_pwm, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int atmel_hlcdc_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -182,10 +181,11 @@ static const struct atmel_hlcdc_pwm_errata atmel_hlcdc_pwm_sama5d3_errata = {
 
 static int atmel_hlcdc_pwm_suspend(struct device *dev)
 {
-	struct atmel_hlcdc_pwm *atmel = dev_get_drvdata(dev);
+	struct pwm_chip *chip = dev_get_drvdata(dev);
+	struct atmel_hlcdc_pwm *atmel = to_atmel_hlcdc_pwm(chip);
 
 	/* Keep the periph clock enabled if the PWM is still running. */
-	if (pwm_is_enabled(&atmel->chip.pwms[0]))
+	if (pwm_is_enabled(&chip->pwms[0]))
 		clk_disable_unprepare(atmel->hlcdc->periph_clk);
 
 	return 0;
@@ -193,11 +193,12 @@ static int atmel_hlcdc_pwm_suspend(struct device *dev)
 
 static int atmel_hlcdc_pwm_resume(struct device *dev)
 {
-	struct atmel_hlcdc_pwm *atmel = dev_get_drvdata(dev);
+	struct pwm_chip *chip = dev_get_drvdata(dev);
+	struct atmel_hlcdc_pwm *atmel = to_atmel_hlcdc_pwm(chip);
 	struct pwm_state state;
 	int ret;
 
-	pwm_get_state(&atmel->chip.pwms[0], &state);
+	pwm_get_state(&chip->pwms[0], &state);
 
 	/* Re-enable the periph clock it was stopped during suspend. */
 	if (!state.enabled) {
@@ -206,8 +207,7 @@ static int atmel_hlcdc_pwm_resume(struct device *dev)
 			return ret;
 	}
 
-	return atmel_hlcdc_pwm_apply(&atmel->chip, &atmel->chip.pwms[0],
-				     &state);
+	return atmel_hlcdc_pwm_apply(chip, &chip->pwms[0], &state);
 }
 
 static DEFINE_SIMPLE_DEV_PM_OPS(atmel_hlcdc_pwm_pm_ops,
@@ -243,15 +243,17 @@ static int atmel_hlcdc_pwm_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *match;
 	struct device *dev = &pdev->dev;
+	struct pwm_chip *chip;
 	struct atmel_hlcdc_pwm *atmel;
 	struct atmel_hlcdc *hlcdc;
 	int ret;
 
 	hlcdc = dev_get_drvdata(dev->parent);
 
-	atmel = devm_kzalloc(dev, sizeof(*atmel), GFP_KERNEL);
-	if (!atmel)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(dev, 1, sizeof(*atmel));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	atmel = to_atmel_hlcdc_pwm(chip);
 
 	ret = clk_prepare_enable(hlcdc->periph_clk);
 	if (ret)
@@ -262,11 +264,9 @@ static int atmel_hlcdc_pwm_probe(struct platform_device *pdev)
 		atmel->errata = match->data;
 
 	atmel->hlcdc = hlcdc;
-	atmel->chip.ops = &atmel_hlcdc_pwm_ops;
-	atmel->chip.dev = dev;
-	atmel->chip.npwm = 1;
+	chip->ops = &atmel_hlcdc_pwm_ops;
 
-	ret = pwmchip_add(&atmel->chip);
+	ret = pwmchip_add(chip);
 	if (ret) {
 		clk_disable_unprepare(hlcdc->periph_clk);
 		return ret;
@@ -279,9 +279,10 @@ static int atmel_hlcdc_pwm_probe(struct platform_device *pdev)
 
 static void atmel_hlcdc_pwm_remove(struct platform_device *pdev)
 {
-	struct atmel_hlcdc_pwm *atmel = platform_get_drvdata(pdev);
+	struct pwm_chip *chip = platform_get_drvdata(pdev);
+	struct atmel_hlcdc_pwm *atmel = to_atmel_hlcdc_pwm(chip);
 
-	pwmchip_remove(&atmel->chip);
+	pwmchip_remove(chip);
 
 	clk_disable_unprepare(atmel->hlcdc->periph_clk);
 }
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:28 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:28 +0100
Subject: [PATCH v4 074/115] pwm: mediatek: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <555f6785eb433361f116151ef998f5b412fff3a9.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-mediatek driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-mediatek.c | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index d7d1c326e8cf..d4329affccda 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -51,7 +51,6 @@ struct pwm_mediatek_of_data {
  * @soc: pointer to chip's platform data
  */
 struct pwm_mediatek_chip {
-	struct pwm_chip chip;
 	void __iomem *regs;
 	struct clk *clk_top;
 	struct clk *clk_main;
@@ -70,7 +69,7 @@ static const unsigned int mtk_pwm_reg_offset_v2[] = {
 static inline struct pwm_mediatek_chip *
 to_pwm_mediatek_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct pwm_mediatek_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int pwm_mediatek_clk_enable(struct pwm_chip *chip,
@@ -233,21 +232,26 @@ static const struct pwm_ops pwm_mediatek_ops = {
 
 static int pwm_mediatek_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct pwm_mediatek_chip *pc;
+	const struct pwm_mediatek_of_data *soc;
 	unsigned int i;
 	int ret;
 
-	pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
-	if (!pc)
-		return -ENOMEM;
+	soc = of_device_get_match_data(&pdev->dev);
 
-	pc->soc = of_device_get_match_data(&pdev->dev);
+	chip = devm_pwmchip_alloc(&pdev->dev, soc->num_pwms, sizeof(*pc));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	pc = to_pwm_mediatek_chip(chip);
+
+	pc->soc = soc;
 
 	pc->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(pc->regs))
 		return PTR_ERR(pc->regs);
 
-	pc->clk_pwms = devm_kmalloc_array(&pdev->dev, pc->soc->num_pwms,
+	pc->clk_pwms = devm_kmalloc_array(&pdev->dev, soc->num_pwms,
 				    sizeof(*pc->clk_pwms), GFP_KERNEL);
 	if (!pc->clk_pwms)
 		return -ENOMEM;
@@ -262,7 +266,7 @@ static int pwm_mediatek_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk_main),
 				     "Failed to get main clock\n");
 
-	for (i = 0; i < pc->soc->num_pwms; i++) {
+	for (i = 0; i < soc->num_pwms; i++) {
 		char name[8];
 
 		snprintf(name, sizeof(name), "pwm%d", i + 1);
@@ -273,11 +277,9 @@ static int pwm_mediatek_probe(struct platform_device *pdev)
 					     "Failed to get %s clock\n", name);
 	}
 
-	pc->chip.dev = &pdev->dev;
-	pc->chip.ops = &pwm_mediatek_ops;
-	pc->chip.npwm = pc->soc->num_pwms;
+	chip->ops = &pwm_mediatek_ops;
 
-	ret = devm_pwmchip_add(&pdev->dev, &pc->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0)
 		return dev_err_probe(&pdev->dev, ret, "pwmchip_add() failed\n");
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:26 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:26 +0100
Subject: [PATCH v4 072/115] pwm: lpc32xx: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <fb0d021b6ba149b4799e182c0d3428ce621bbcc8.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-lpc32xx driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-lpc32xx.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/pwm/pwm-lpc32xx.c b/drivers/pwm/pwm-lpc32xx.c
index 1d9f3e7a2434..c748537e57d1 100644
--- a/drivers/pwm/pwm-lpc32xx.c
+++ b/drivers/pwm/pwm-lpc32xx.c
@@ -15,7 +15,6 @@
 #include <linux/slab.h>
 
 struct lpc32xx_pwm_chip {
-	struct pwm_chip chip;
 	struct clk *clk;
 	void __iomem *base;
 };
@@ -23,8 +22,10 @@ struct lpc32xx_pwm_chip {
 #define PWM_ENABLE	BIT(31)
 #define PWM_PIN_LEVEL	BIT(30)
 
-#define to_lpc32xx_pwm_chip(_chip) \
-	container_of(_chip, struct lpc32xx_pwm_chip, chip)
+static inline struct lpc32xx_pwm_chip *to_lpc32xx_pwm_chip(struct pwm_chip *chip)
+{
+	return pwmchip_get_drvdata(chip);
+}
 
 static int lpc32xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 			      int duty_ns, int period_ns)
@@ -119,13 +120,15 @@ static const struct pwm_ops lpc32xx_pwm_ops = {
 
 static int lpc32xx_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct lpc32xx_pwm_chip *lpc32xx;
 	int ret;
 	u32 val;
 
-	lpc32xx = devm_kzalloc(&pdev->dev, sizeof(*lpc32xx), GFP_KERNEL);
-	if (!lpc32xx)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*lpc32xx));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	lpc32xx = to_lpc32xx_pwm_chip(chip);
 
 	lpc32xx->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(lpc32xx->base))
@@ -135,16 +138,14 @@ static int lpc32xx_pwm_probe(struct platform_device *pdev)
 	if (IS_ERR(lpc32xx->clk))
 		return PTR_ERR(lpc32xx->clk);
 
-	lpc32xx->chip.dev = &pdev->dev;
-	lpc32xx->chip.ops = &lpc32xx_pwm_ops;
-	lpc32xx->chip.npwm = 1;
+	chip->ops = &lpc32xx_pwm_ops;
 
 	/* If PWM is disabled, configure the output to the default value */
 	val = readl(lpc32xx->base);
 	val &= ~PWM_PIN_LEVEL;
 	writel(val, lpc32xx->base);
 
-	ret = devm_pwmchip_add(&pdev->dev, &lpc32xx->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "failed to add PWM chip, error %d\n", ret);
 		return ret;
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:25 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:25 +0100
Subject: [PATCH v4 071/115] pwm: lpc18xx-sct: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <b07bdc367f430c41f483e36981167b965c3b62ac.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-lpc18xx-sct driver to further changes of the pwm
core outlined in the commit introducing devm_pwmchip_alloc(). There is
no intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-lpc18xx-sct.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
index 9e1db43a5171..39bfcd5b6c29 100644
--- a/drivers/pwm/pwm-lpc18xx-sct.c
+++ b/drivers/pwm/pwm-lpc18xx-sct.c
@@ -93,7 +93,6 @@ struct lpc18xx_pwm_data {
 
 struct lpc18xx_pwm_chip {
 	struct device *parent;
-	struct pwm_chip chip;
 	void __iomem *base;
 	struct clk *pwm_clk;
 	unsigned long clk_rate;
@@ -110,7 +109,7 @@ struct lpc18xx_pwm_chip {
 static inline struct lpc18xx_pwm_chip *
 to_lpc18xx_pwm_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct lpc18xx_pwm_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static inline void lpc18xx_pwm_writel(struct lpc18xx_pwm_chip *lpc18xx_pwm,
@@ -351,14 +350,15 @@ MODULE_DEVICE_TABLE(of, lpc18xx_pwm_of_match);
 
 static int lpc18xx_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct lpc18xx_pwm_chip *lpc18xx_pwm;
 	int ret;
 	u64 val;
 
-	lpc18xx_pwm = devm_kzalloc(&pdev->dev, sizeof(*lpc18xx_pwm),
-				   GFP_KERNEL);
-	if (!lpc18xx_pwm)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, LPC18XX_NUM_PWMS, sizeof(*lpc18xx_pwm));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	lpc18xx_pwm = to_lpc18xx_pwm_chip(chip);
 
 	lpc18xx_pwm->parent = &pdev->dev;
 
@@ -391,9 +391,7 @@ static int lpc18xx_pwm_probe(struct platform_device *pdev)
 	lpc18xx_pwm->min_period_ns = DIV_ROUND_UP(NSEC_PER_SEC,
 						  lpc18xx_pwm->clk_rate);
 
-	lpc18xx_pwm->chip.dev = &pdev->dev;
-	lpc18xx_pwm->chip.ops = &lpc18xx_pwm_ops;
-	lpc18xx_pwm->chip.npwm = LPC18XX_NUM_PWMS;
+	chip->ops = &lpc18xx_pwm_ops;
 
 	/* SCT counter must be in unify (32 bit) mode */
 	lpc18xx_pwm_writel(lpc18xx_pwm, LPC18XX_PWM_CONFIG,
@@ -425,21 +423,22 @@ static int lpc18xx_pwm_probe(struct platform_device *pdev)
 	val |= LPC18XX_PWM_PRE(0);
 	lpc18xx_pwm_writel(lpc18xx_pwm, LPC18XX_PWM_CTRL, val);
 
-	ret = pwmchip_add(&lpc18xx_pwm->chip);
+	ret = pwmchip_add(chip);
 	if (ret < 0)
 		return dev_err_probe(&pdev->dev, ret, "pwmchip_add failed\n");
 
-	platform_set_drvdata(pdev, lpc18xx_pwm);
+	platform_set_drvdata(pdev, chip);
 
 	return 0;
 }
 
 static void lpc18xx_pwm_remove(struct platform_device *pdev)
 {
-	struct lpc18xx_pwm_chip *lpc18xx_pwm = platform_get_drvdata(pdev);
+	struct pwm_chip *chip = platform_get_drvdata(pdev);
+	struct lpc18xx_pwm_chip *lpc18xx_pwm = to_lpc18xx_pwm_chip(chip);
 	u32 val;
 
-	pwmchip_remove(&lpc18xx_pwm->chip);
+	pwmchip_remove(chip);
 
 	val = lpc18xx_pwm_readl(lpc18xx_pwm, LPC18XX_PWM_CTRL);
 	lpc18xx_pwm_writel(lpc18xx_pwm, LPC18XX_PWM_CTRL,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:01 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:01 +0100
Subject: [PATCH v4 047/115] pwm: atmel: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <da992a33bb17314d091ea63f12724147be23d887.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-atmel driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-atmel.c | 28 +++++++++++++---------------
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 4ef91fe6f147..ab84229161ef 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -77,7 +77,6 @@ struct atmel_pwm_data {
 };
 
 struct atmel_pwm_chip {
-	struct pwm_chip chip;
 	struct clk *clk;
 	void __iomem *base;
 	const struct atmel_pwm_data *data;
@@ -99,7 +98,7 @@ struct atmel_pwm_chip {
 
 static inline struct atmel_pwm_chip *to_atmel_pwm_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct atmel_pwm_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static inline u32 atmel_pwm_readl(struct atmel_pwm_chip *chip,
@@ -473,7 +472,7 @@ static int atmel_pwm_enable_clk_if_on(struct pwm_chip *chip, bool on)
 	if (!sr)
 		return 0;
 
-	cnt = bitmap_weight(&sr, atmel_pwm->chip.npwm);
+	cnt = bitmap_weight(&sr, chip->npwm);
 
 	if (!on)
 		goto disable_clk;
@@ -481,9 +480,8 @@ static int atmel_pwm_enable_clk_if_on(struct pwm_chip *chip, bool on)
 	for (i = 0; i < cnt; i++) {
 		ret = clk_enable(atmel_pwm->clk);
 		if (ret) {
-			dev_err(pwmchip_parent(chip),
-				"failed to enable clock for pwm %pe\n",
-				ERR_PTR(ret));
+			dev_err_probe(pwmchip_parent(chip), ret,
+				"failed to enable clock for pwm\n");
 
 			cnt = i;
 			goto disable_clk;
@@ -501,12 +499,14 @@ static int atmel_pwm_enable_clk_if_on(struct pwm_chip *chip, bool on)
 
 static int atmel_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct atmel_pwm_chip *atmel_pwm;
 	int ret;
 
-	atmel_pwm = devm_kzalloc(&pdev->dev, sizeof(*atmel_pwm), GFP_KERNEL);
-	if (!atmel_pwm)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 4, sizeof(*atmel_pwm));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	atmel_pwm = to_atmel_pwm_chip(chip);
 
 	atmel_pwm->data = of_device_get_match_data(&pdev->dev);
 
@@ -522,15 +522,13 @@ static int atmel_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(atmel_pwm->clk),
 				     "failed to get prepared PWM clock\n");
 
-	atmel_pwm->chip.dev = &pdev->dev;
-	atmel_pwm->chip.ops = &atmel_pwm_ops;
-	atmel_pwm->chip.npwm = 4;
+	chip->ops = &atmel_pwm_ops;
 
-	ret = atmel_pwm_enable_clk_if_on(&atmel_pwm->chip, true);
+	ret = atmel_pwm_enable_clk_if_on(chip, true);
 	if (ret < 0)
 		return ret;
 
-	ret = devm_pwmchip_add(&pdev->dev, &atmel_pwm->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0) {
 		dev_err_probe(&pdev->dev, ret, "failed to add PWM chip\n");
 		goto disable_clk;
@@ -539,7 +537,7 @@ static int atmel_pwm_probe(struct platform_device *pdev)
 	return 0;
 
 disable_clk:
-	atmel_pwm_enable_clk_if_on(&atmel_pwm->chip, false);
+	atmel_pwm_enable_clk_if_on(chip, false);
 
 	return ret;
 }
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:46 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:46 +0100
Subject: [PATCH v4 032/115] pwm: stm32-lp: Make use of pwmchip_parent() macro
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <ba8f7a49a8206d24854777b65c2e679f93852fe3.1701860672.git.u.kleine-koenig@pengutronix.de>

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the macro
provided for exactly this purpose.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-stm32-lp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 439068f3eca1..3754faeca838 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	do_div(div, NSEC_PER_SEC);
 	if (!div) {
 		/* Clock is too slow to achieve requested period. */
-		dev_dbg(priv->chip.dev, "Can't reach %llu ns\n", state->period);
+		dev_dbg(pwmchip_parent(chip), "Can't reach %llu ns\n", state->period);
 		return -EINVAL;
 	}
 
@@ -69,7 +69,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	while (div > STM32_LPTIM_MAX_ARR) {
 		presc++;
 		if ((1 << presc) > STM32_LPTIM_MAX_PRESCALER) {
-			dev_err(priv->chip.dev, "max prescaler exceeded\n");
+			dev_err(pwmchip_parent(chip), "max prescaler exceeded\n");
 			return -EINVAL;
 		}
 		div = prd >> presc;
@@ -130,7 +130,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 				       (val & STM32_LPTIM_CMPOK_ARROK) == STM32_LPTIM_CMPOK_ARROK,
 				       100, 1000);
 	if (ret) {
-		dev_err(priv->chip.dev, "ARR/CMP registers write issue\n");
+		dev_err(pwmchip_parent(chip), "ARR/CMP registers write issue\n");
 		goto err;
 	}
 	ret = regmap_write(priv->regmap, STM32_LPTIM_ICR,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:31 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:31 +0100
Subject: [PATCH v4 077/115] pwm: mtk-disp: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e5852ac7208917932f9e6bce96a40ecd1a2b5991.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-mtk-disp driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-mtk-disp.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 186aa5c04435..bafd6b6195f6 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -42,7 +42,6 @@ struct mtk_pwm_data {
 };
 
 struct mtk_disp_pwm {
-	struct pwm_chip chip;
 	const struct mtk_pwm_data *data;
 	struct clk *clk_main;
 	struct clk *clk_mm;
@@ -52,7 +51,7 @@ struct mtk_disp_pwm {
 
 static inline struct mtk_disp_pwm *to_mtk_disp_pwm(struct pwm_chip *chip)
 {
-	return container_of(chip, struct mtk_disp_pwm, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static void mtk_disp_pwm_update_bits(struct mtk_disp_pwm *mdp, u32 offset,
@@ -231,12 +230,14 @@ static const struct pwm_ops mtk_disp_pwm_ops = {
 
 static int mtk_disp_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct mtk_disp_pwm *mdp;
 	int ret;
 
-	mdp = devm_kzalloc(&pdev->dev, sizeof(*mdp), GFP_KERNEL);
-	if (!mdp)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*mdp));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	mdp = to_mtk_disp_pwm(chip);
 
 	mdp->data = of_device_get_match_data(&pdev->dev);
 
@@ -254,11 +255,9 @@ static int mtk_disp_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(mdp->clk_mm),
 				     "Failed to get mm clock\n");
 
-	mdp->chip.dev = &pdev->dev;
-	mdp->chip.ops = &mtk_disp_pwm_ops;
-	mdp->chip.npwm = 1;
+	chip->ops = &mtk_disp_pwm_ops;
 
-	ret = devm_pwmchip_add(&pdev->dev, &mdp->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0)
 		return dev_err_probe(&pdev->dev, ret, "pwmchip_add() failed\n");
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:19 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:19 +0100
Subject: [PATCH v4 065/115] pwm: imx-tpm: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <54815ba81395492a7098755951d0ce7616a7f4fe.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-tmp driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-imx-tpm.c | 34 +++++++++++++++++++---------------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
index 9fc290e647e1..04f8ab315748 100644
--- a/drivers/pwm/pwm-imx-tpm.c
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -57,7 +57,6 @@
 #define PWM_IMX_TPM_MOD_MOD	GENMASK(PWM_IMX_TPM_MOD_WIDTH - 1, 0)
 
 struct imx_tpm_pwm_chip {
-	struct pwm_chip chip;
 	struct clk *clk;
 	void __iomem *base;
 	struct mutex lock;
@@ -75,7 +74,7 @@ struct imx_tpm_pwm_param {
 static inline struct imx_tpm_pwm_chip *
 to_imx_tpm_pwm_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct imx_tpm_pwm_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 /*
@@ -336,35 +335,40 @@ static const struct pwm_ops imx_tpm_pwm_ops = {
 
 static int pwm_imx_tpm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct imx_tpm_pwm_chip *tpm;
+	void __iomem *base;
 	int ret;
+	unsigned int npwm;
 	u32 val;
 
-	tpm = devm_kzalloc(&pdev->dev, sizeof(*tpm), GFP_KERNEL);
-	if (!tpm)
-		return -ENOMEM;
+	base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	/* get number of channels */
+	val = readl(tpm->base + PWM_IMX_TPM_PARAM);
+	npwm = FIELD_GET(PWM_IMX_TPM_PARAM_CHAN, val);
+
+	chip = devm_pwmchip_alloc(&pdev->dev, npwm, sizeof(*tpm));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	tpm = to_imx_tpm_pwm_chip(chip);
 
 	platform_set_drvdata(pdev, tpm);
 
-	tpm->base = devm_platform_ioremap_resource(pdev, 0);
-	if (IS_ERR(tpm->base))
-		return PTR_ERR(tpm->base);
+	tpm->base = base;
 
 	tpm->clk = devm_clk_get_enabled(&pdev->dev, NULL);
 	if (IS_ERR(tpm->clk))
 		return dev_err_probe(&pdev->dev, PTR_ERR(tpm->clk),
 				     "failed to get PWM clock\n");
 
-	tpm->chip.dev = &pdev->dev;
-	tpm->chip.ops = &imx_tpm_pwm_ops;
-
-	/* get number of channels */
-	val = readl(tpm->base + PWM_IMX_TPM_PARAM);
-	tpm->chip.npwm = FIELD_GET(PWM_IMX_TPM_PARAM_CHAN, val);
+	chip->ops = &imx_tpm_pwm_ops;
 
 	mutex_init(&tpm->lock);
 
-	ret = devm_pwmchip_add(&pdev->dev, &tpm->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret)
 		return dev_err_probe(&pdev->dev, ret, "failed to add PWM chip\n");
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:40 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:40 +0100
Subject: [PATCH v4 086/115] pwm: rockchip: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <6ff62a16862768b6817819b95e2924e41e05274f.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-rockchip driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-rockchip.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index a7c647e37837..0fa7575dbb54 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -30,7 +30,6 @@
 #define PWM_LP_DISABLE		(0 << 8)
 
 struct rockchip_pwm_chip {
-	struct pwm_chip chip;
 	struct clk *clk;
 	struct clk *pclk;
 	const struct rockchip_pwm_data *data;
@@ -54,7 +53,7 @@ struct rockchip_pwm_data {
 
 static inline struct rockchip_pwm_chip *to_rockchip_pwm_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct rockchip_pwm_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int rockchip_pwm_get_state(struct pwm_chip *chip,
@@ -296,14 +295,16 @@ MODULE_DEVICE_TABLE(of, rockchip_pwm_dt_ids);
 
 static int rockchip_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct rockchip_pwm_chip *pc;
 	u32 enable_conf, ctrl;
 	bool enabled;
 	int ret, count;
 
-	pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
-	if (!pc)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*pc));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	pc = to_rockchip_pwm_chip(chip);
 
 	pc->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(pc->base))
@@ -337,18 +338,16 @@ static int rockchip_pwm_probe(struct platform_device *pdev)
 		goto err_clk;
 	}
 
-	platform_set_drvdata(pdev, pc);
+	platform_set_drvdata(pdev, chip);
 
 	pc->data = device_get_match_data(&pdev->dev);
-	pc->chip.dev = &pdev->dev;
-	pc->chip.ops = &rockchip_pwm_ops;
-	pc->chip.npwm = 1;
+	chip->ops = &rockchip_pwm_ops;
 
 	enable_conf = pc->data->enable_conf;
 	ctrl = readl_relaxed(pc->base + pc->data->regs.ctrl);
 	enabled = (ctrl & enable_conf) == enable_conf;
 
-	ret = pwmchip_add(&pc->chip);
+	ret = pwmchip_add(chip);
 	if (ret < 0) {
 		dev_err_probe(&pdev->dev, ret, "pwmchip_add() failed\n");
 		goto err_pclk;
@@ -372,9 +371,10 @@ static int rockchip_pwm_probe(struct platform_device *pdev)
 
 static void rockchip_pwm_remove(struct platform_device *pdev)
 {
-	struct rockchip_pwm_chip *pc = platform_get_drvdata(pdev);
+	struct pwm_chip *chip = platform_get_drvdata(pdev);
+	struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
 
-	pwmchip_remove(&pc->chip);
+	pwmchip_remove(chip);
 
 	clk_unprepare(pc->pclk);
 	clk_unprepare(pc->clk);
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:17 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:17 +0100
Subject: [PATCH v4 063/115] pwm: imx1: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <024bde4691a4e1db45e22027230f219172e70705.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-imx1 driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-imx1.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-imx1.c b/drivers/pwm/pwm-imx1.c
index d175d895f22a..1d2aae2d278f 100644
--- a/drivers/pwm/pwm-imx1.c
+++ b/drivers/pwm/pwm-imx1.c
@@ -28,10 +28,12 @@ struct pwm_imx1_chip {
 	struct clk *clk_ipg;
 	struct clk *clk_per;
 	void __iomem *mmio_base;
-	struct pwm_chip chip;
 };
 
-#define to_pwm_imx1_chip(chip)	container_of(chip, struct pwm_imx1_chip, chip)
+static inline struct pwm_imx1_chip *to_pwm_imx1_chip(struct pwm_chip *chip)
+{
+	return pwmchip_get_drvdata(chip);
+}
 
 static int pwm_imx1_clk_prepare_enable(struct pwm_chip *chip)
 {
@@ -156,11 +158,13 @@ MODULE_DEVICE_TABLE(of, pwm_imx1_dt_ids);
 
 static int pwm_imx1_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct pwm_imx1_chip *imx;
 
-	imx = devm_kzalloc(&pdev->dev, sizeof(*imx), GFP_KERNEL);
-	if (!imx)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*imx));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	imx = to_pwm_imx1_chip(chip);
 
 	imx->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
 	if (IS_ERR(imx->clk_ipg))
@@ -172,15 +176,13 @@ static int pwm_imx1_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(imx->clk_per),
 				     "failed to get peripheral clock\n");
 
-	imx->chip.ops = &pwm_imx1_ops;
-	imx->chip.dev = &pdev->dev;
-	imx->chip.npwm = 1;
+	chip->ops = &pwm_imx1_ops;
 
 	imx->mmio_base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(imx->mmio_base))
 		return PTR_ERR(imx->mmio_base);
 
-	return devm_pwmchip_add(&pdev->dev, &imx->chip);
+	return devm_pwmchip_add(&pdev->dev, chip);
 }
 
 static struct platform_driver pwm_imx1_driver = {
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:29 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:29 +0100
Subject: [PATCH v4 075/115] pwm: meson: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <513593a5a3d4169abfdabe36de966e5095edfd3b.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-meson driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-meson.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index 640d6fe63799..187cd6f35cce 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -102,7 +102,6 @@ struct meson_pwm_data {
 };
 
 struct meson_pwm {
-	struct pwm_chip chip;
 	const struct meson_pwm_data *data;
 	struct meson_pwm_channel channels[MESON_NUM_PWMS];
 	void __iomem *base;
@@ -115,7 +114,7 @@ struct meson_pwm {
 
 static inline struct meson_pwm *to_meson_pwm(struct pwm_chip *chip)
 {
-	return container_of(chip, struct meson_pwm, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int meson_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
@@ -449,7 +448,7 @@ static int meson_pwm_init_channels(struct pwm_chip *chip)
 		mux_parent_data[i].name = meson->data->parent_names[i];
 	}
 
-	for (i = 0; i < meson->chip.npwm; i++) {
+	for (i = 0; i < chip->npwm; i++) {
 		struct meson_pwm_channel *channel = &meson->channels[i];
 		struct clk_parent_data div_parent = {}, gate_parent = {};
 		struct clk_init_data init = {};
@@ -535,29 +534,29 @@ static int meson_pwm_init_channels(struct pwm_chip *chip)
 
 static int meson_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct meson_pwm *meson;
 	int err;
 
-	meson = devm_kzalloc(&pdev->dev, sizeof(*meson), GFP_KERNEL);
-	if (!meson)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	meson = to_meson_pwm(chip);
 
 	meson->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(meson->base))
 		return PTR_ERR(meson->base);
 
 	spin_lock_init(&meson->lock);
-	meson->chip.dev = &pdev->dev;
-	meson->chip.ops = &meson_pwm_ops;
-	meson->chip.npwm = MESON_NUM_PWMS;
+	chip->ops = &meson_pwm_ops;
 
 	meson->data = of_device_get_match_data(&pdev->dev);
 
-	err = meson_pwm_init_channels(&meson->chip);
+	err = meson_pwm_init_channels(chip);
 	if (err < 0)
 		return err;
 
-	err = devm_pwmchip_add(&pdev->dev, &meson->chip);
+	err = devm_pwmchip_add(&pdev->dev, chip);
 	if (err < 0) {
 		dev_err(&pdev->dev, "failed to register PWM chip: %d\n", err);
 		return err;
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:42 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:42 +0100
Subject: [PATCH v4 088/115] pwm: samsung: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <45a2ef2b613d4b1c77973e8991f46018273e8e3c.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-samsung driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-samsung.c | 45 +++++++++++++++++++++------------------
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index a97cae49406e..fcbe464b0c38 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -80,7 +80,6 @@ struct samsung_pwm_channel {
  * @channel:		per channel driver data
  */
 struct samsung_pwm_chip {
-	struct pwm_chip chip;
 	struct samsung_pwm_variant variant;
 	u8 inverter_mask;
 	u8 disabled_mask;
@@ -110,7 +109,7 @@ static DEFINE_SPINLOCK(samsung_pwm_lock);
 static inline
 struct samsung_pwm_chip *to_samsung_pwm_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct samsung_pwm_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static inline unsigned int to_tcon_channel(unsigned int channel)
@@ -181,9 +180,10 @@ static unsigned long pwm_samsung_get_tin_rate(struct samsung_pwm_chip *our_chip,
 	return rate / (reg + 1);
 }
 
-static unsigned long pwm_samsung_calc_tin(struct samsung_pwm_chip *our_chip,
+static unsigned long pwm_samsung_calc_tin(struct pwm_chip *chip,
 					  unsigned int chan, unsigned long freq)
 {
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
 	struct samsung_pwm_variant *variant = &our_chip->variant;
 	unsigned long rate;
 	struct clk *clk;
@@ -197,12 +197,12 @@ static unsigned long pwm_samsung_calc_tin(struct samsung_pwm_chip *our_chip,
 				return rate;
 		}
 
-		dev_warn(pwmchip_parent(&our_chip->chip),
+		dev_warn(pwmchip_parent(chip),
 			"tclk of PWM %d is inoperational, using tdiv\n", chan);
 	}
 
 	rate = pwm_samsung_get_tin_rate(our_chip, chan);
-	dev_dbg(pwmchip_parent(&our_chip->chip), "tin parent at %lu\n", rate);
+	dev_dbg(pwmchip_parent(chip), "tin parent at %lu\n", rate);
 
 	/*
 	 * Compare minimum PWM frequency that can be achieved with possible
@@ -329,7 +329,7 @@ static int __pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
 		dev_dbg(pwmchip_parent(chip), "duty_ns=%d, period_ns=%d (%u)\n",
 						duty_ns, period_ns, period);
 
-		tin_rate = pwm_samsung_calc_tin(our_chip, pwm->hwpwm, period);
+		tin_rate = pwm_samsung_calc_tin(chip, pwm->hwpwm, period);
 
 		dev_dbg(pwmchip_parent(chip), "tin_rate=%lu\n", tin_rate);
 
@@ -506,9 +506,10 @@ static const struct of_device_id samsung_pwm_matches[] = {
 };
 MODULE_DEVICE_TABLE(of, samsung_pwm_matches);
 
-static int pwm_samsung_parse_dt(struct samsung_pwm_chip *our_chip)
+static int pwm_samsung_parse_dt(struct pwm_chip *chip)
 {
-	struct device_node *np = pwmchip_parent(&our_chip->chip)->of_node;
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	struct device_node *np = pwmchip_parent(chip)->of_node;
 	const struct of_device_id *match;
 	struct property *prop;
 	const __be32 *cur;
@@ -522,7 +523,7 @@ static int pwm_samsung_parse_dt(struct samsung_pwm_chip *our_chip)
 
 	of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) {
 		if (val >= SAMSUNG_PWM_NUM) {
-			dev_err(pwmchip_parent(&our_chip->chip),
+			dev_err(pwmchip_parent(chip),
 				"%s: invalid channel index in samsung,pwm-outputs property\n",
 								__func__);
 			continue;
@@ -533,7 +534,7 @@ static int pwm_samsung_parse_dt(struct samsung_pwm_chip *our_chip)
 	return 0;
 }
 #else
-static int pwm_samsung_parse_dt(struct samsung_pwm_chip *our_chip)
+static int pwm_samsung_parse_dt(struct pwm_chip *chip)
 {
 	return -ENODEV;
 }
@@ -542,21 +543,22 @@ static int pwm_samsung_parse_dt(struct samsung_pwm_chip *our_chip)
 static int pwm_samsung_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
+	struct pwm_chip *chip;
 	struct samsung_pwm_chip *our_chip;
 	unsigned int chan;
 	int ret;
 
-	our_chip = devm_kzalloc(&pdev->dev, sizeof(*our_chip), GFP_KERNEL);
-	if (our_chip == NULL)
+	chip = devm_pwmchip_alloc(&pdev->dev, SAMSUNG_PWM_NUM, sizeof(*chip));
+	if (chip == NULL)
 		return -ENOMEM;
+	our_chip = to_samsung_pwm_chip(chip);
+
+	chip->ops = &pwm_samsung_ops;
 
-	our_chip->chip.dev = &pdev->dev;
-	our_chip->chip.ops = &pwm_samsung_ops;
-	our_chip->chip.npwm = SAMSUNG_PWM_NUM;
 	our_chip->inverter_mask = BIT(SAMSUNG_PWM_NUM) - 1;
 
 	if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
-		ret = pwm_samsung_parse_dt(our_chip);
+		ret = pwm_samsung_parse_dt(chip);
 		if (ret)
 			return ret;
 	} else {
@@ -595,7 +597,7 @@ static int pwm_samsung_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, our_chip);
 
-	ret = pwmchip_add(&our_chip->chip);
+	ret = pwmchip_add(chip);
 	if (ret < 0) {
 		dev_err(dev, "failed to register PWM chip\n");
 		clk_disable_unprepare(our_chip->base_clk);
@@ -612,17 +614,18 @@ static int pwm_samsung_probe(struct platform_device *pdev)
 
 static void pwm_samsung_remove(struct platform_device *pdev)
 {
-	struct samsung_pwm_chip *our_chip = platform_get_drvdata(pdev);
+	struct pwm_chip *chip = platform_get_drvdata(pdev);
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
 
-	pwmchip_remove(&our_chip->chip);
+	pwmchip_remove(chip);
 
 	clk_disable_unprepare(our_chip->base_clk);
 }
 
 static int pwm_samsung_resume(struct device *dev)
 {
-	struct samsung_pwm_chip *our_chip = dev_get_drvdata(dev);
-	struct pwm_chip *chip = &our_chip->chip;
+	struct pwm_chip *chip = dev_get_drvdata(dev);
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
 	unsigned int i;
 
 	for (i = 0; i < SAMSUNG_PWM_NUM; i++) {
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:43:59 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:43:59 +0100
Subject: [PATCH v4 045/115] pwm: apple: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <bd5e8b3ea3b17f64f10418ac9214dab025b00972.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-apple driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-apple.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-apple.c b/drivers/pwm/pwm-apple.c
index 4d755b628d9e..6e58aca2f13c 100644
--- a/drivers/pwm/pwm-apple.c
+++ b/drivers/pwm/pwm-apple.c
@@ -32,14 +32,13 @@
 #define APPLE_PWM_CTRL_OUTPUT_ENABLE BIT(14)
 
 struct apple_pwm {
-	struct pwm_chip chip;
 	void __iomem *base;
 	u64 clkrate;
 };
 
 static inline struct apple_pwm *to_apple_pwm(struct pwm_chip *chip)
 {
-	return container_of(chip, struct apple_pwm, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int apple_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -103,13 +102,16 @@ static const struct pwm_ops apple_pwm_ops = {
 
 static int apple_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct apple_pwm *fpwm;
 	struct clk *clk;
 	int ret;
 
-	fpwm = devm_kzalloc(&pdev->dev, sizeof(*fpwm), GFP_KERNEL);
-	if (!fpwm)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*fpwm));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+
+	fpwm = to_apple_pwm(chip);
 
 	fpwm->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(fpwm->base))
@@ -129,11 +131,9 @@ static int apple_pwm_probe(struct platform_device *pdev)
 	if (fpwm->clkrate > NSEC_PER_SEC)
 		return dev_err_probe(&pdev->dev, -EINVAL, "pwm clock out of range");
 
-	fpwm->chip.dev = &pdev->dev;
-	fpwm->chip.npwm = 1;
-	fpwm->chip.ops = &apple_pwm_ops;
+	chip->ops = &apple_pwm_ops;
 
-	ret = devm_pwmchip_add(&pdev->dev, &fpwm->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0)
 		return dev_err_probe(&pdev->dev, ret, "unable to add pwm chip");
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:18 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:18 +0100
Subject: [PATCH v4 064/115] pwm: imx27: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <a415a12f067bfd915c16459622b3efc1df8b8760.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-imx27 driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-imx27.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 5d796453519a..54589f0b3b78 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -83,7 +83,6 @@ struct pwm_imx27_chip {
 	struct clk	*clk_ipg;
 	struct clk	*clk_per;
 	void __iomem	*mmio_base;
-	struct pwm_chip	chip;
 
 	/*
 	 * The driver cannot read the current duty cycle from the hardware if
@@ -93,7 +92,10 @@ struct pwm_imx27_chip {
 	unsigned int duty_cycle;
 };
 
-#define to_pwm_imx27_chip(chip)	container_of(chip, struct pwm_imx27_chip, chip)
+static inline struct pwm_imx27_chip *to_pwm_imx27_chip(struct pwm_chip *chip)
+{
+	return pwmchip_get_drvdata(chip);
+}
 
 static int pwm_imx27_clk_prepare_enable(struct pwm_imx27_chip *imx)
 {
@@ -306,13 +308,15 @@ MODULE_DEVICE_TABLE(of, pwm_imx27_dt_ids);
 
 static int pwm_imx27_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct pwm_imx27_chip *imx;
 	int ret;
 	u32 pwmcr;
 
-	imx = devm_kzalloc(&pdev->dev, sizeof(*imx), GFP_KERNEL);
-	if (imx == NULL)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*imx));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	imx = to_pwm_imx27_chip(chip);
 
 	imx->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
 	if (IS_ERR(imx->clk_ipg))
@@ -324,9 +328,7 @@ static int pwm_imx27_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(imx->clk_per),
 				     "failed to get peripheral clock\n");
 
-	imx->chip.ops = &pwm_imx27_ops;
-	imx->chip.dev = &pdev->dev;
-	imx->chip.npwm = 1;
+	chip->ops = &pwm_imx27_ops;
 
 	imx->mmio_base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(imx->mmio_base))
@@ -341,7 +343,7 @@ static int pwm_imx27_probe(struct platform_device *pdev)
 	if (!(pwmcr & MX3_PWMCR_EN))
 		pwm_imx27_clk_disable_unprepare(imx);
 
-	return devm_pwmchip_add(&pdev->dev, &imx->chip);
+	return devm_pwmchip_add(&pdev->dev, chip);
 }
 
 static struct platform_driver imx_pwm_driver = {
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:37 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:37 +0100
Subject: [PATCH v4 083/115] pwm: raspberrypi-poe: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <11b3a9ab42ae302071dcab5eb0bba70174c8efc6.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-raspberrypi-poe driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-raspberrypi-poe.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-raspberrypi-poe.c b/drivers/pwm/pwm-raspberrypi-poe.c
index f10e8a624c51..8921e7ea2cea 100644
--- a/drivers/pwm/pwm-raspberrypi-poe.c
+++ b/drivers/pwm/pwm-raspberrypi-poe.c
@@ -27,7 +27,6 @@
 
 struct raspberrypi_pwm {
 	struct rpi_firmware *firmware;
-	struct pwm_chip chip;
 	unsigned int duty_cycle;
 };
 
@@ -40,7 +39,7 @@ struct raspberrypi_pwm_prop {
 static inline
 struct raspberrypi_pwm *raspberrypi_pwm_from_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct raspberrypi_pwm, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int raspberrypi_pwm_set_property(struct rpi_firmware *firmware,
@@ -142,6 +141,7 @@ static int raspberrypi_pwm_probe(struct platform_device *pdev)
 	struct device_node *firmware_node;
 	struct device *dev = &pdev->dev;
 	struct rpi_firmware *firmware;
+	struct pwm_chip *chip;
 	struct raspberrypi_pwm *rpipwm;
 	int ret;
 
@@ -157,14 +157,14 @@ static int raspberrypi_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, -EPROBE_DEFER,
 				     "Failed to get firmware handle\n");
 
-	rpipwm = devm_kzalloc(&pdev->dev, sizeof(*rpipwm), GFP_KERNEL);
-	if (!rpipwm)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, RASPBERRYPI_FIRMWARE_PWM_NUM,
+				  sizeof(*rpipwm));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	rpipwm = raspberrypi_pwm_from_chip(chip);
 
 	rpipwm->firmware = firmware;
-	rpipwm->chip.dev = dev;
-	rpipwm->chip.ops = &raspberrypi_pwm_ops;
-	rpipwm->chip.npwm = RASPBERRYPI_FIRMWARE_PWM_NUM;
+	chip->ops = &raspberrypi_pwm_ops;
 
 	ret = raspberrypi_pwm_get_property(rpipwm->firmware, RPI_PWM_CUR_DUTY_REG,
 					   &rpipwm->duty_cycle);
@@ -173,7 +173,7 @@ static int raspberrypi_pwm_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	return devm_pwmchip_add(dev, &rpipwm->chip);
+	return devm_pwmchip_add(dev, chip);
 }
 
 static const struct of_device_id raspberrypi_pwm_of_match[] = {
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:58 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:58 +0100
Subject: [PATCH v4 104/115] pwm: vt8500: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <ace1811895ea24b70d7317967104b5ce1bd185e2.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-vt8500 driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-vt8500.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index ff5e76afbddf..b24afee37488 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -45,12 +45,14 @@
 #define STATUS_ALL_UPDATE	0x0F
 
 struct vt8500_chip {
-	struct pwm_chip chip;
 	void __iomem *base;
 	struct clk *clk;
 };
 
-#define to_vt8500_chip(chip)	container_of(chip, struct vt8500_chip, chip)
+static inline struct vt8500_chip *to_vt8500_chip(struct pwm_chip *chip)
+{
+	return pwmchip_get_drvdata(chip);
+}
 
 #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
 static inline void vt8500_pwm_busy_wait(struct pwm_chip *chip, int nr, u8 bitmask)
@@ -232,6 +234,7 @@ MODULE_DEVICE_TABLE(of, vt8500_pwm_dt_ids);
 
 static int vt8500_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct vt8500_chip *vt8500;
 	struct device_node *np = pdev->dev.of_node;
 	int ret;
@@ -239,13 +242,12 @@ static int vt8500_pwm_probe(struct platform_device *pdev)
 	if (!np)
 		return dev_err_probe(&pdev->dev, -EINVAL, "invalid devicetree node\n");
 
-	vt8500 = devm_kzalloc(&pdev->dev, sizeof(*vt8500), GFP_KERNEL);
-	if (vt8500 == NULL)
+	chip = devm_pwmchip_alloc(&pdev->dev, VT8500_NR_PWMS, sizeof(*vt8500));
+	if (chip == NULL)
 		return -ENOMEM;
+	vt8500 = to_vt8500_chip(chip);
 
-	vt8500->chip.dev = &pdev->dev;
-	vt8500->chip.ops = &vt8500_pwm_ops;
-	vt8500->chip.npwm = VT8500_NR_PWMS;
+	chip->ops = &vt8500_pwm_ops;
 
 	vt8500->clk = devm_clk_get_prepared(&pdev->dev, NULL);
 	if (IS_ERR(vt8500->clk))
@@ -255,7 +257,7 @@ static int vt8500_pwm_probe(struct platform_device *pdev)
 	if (IS_ERR(vt8500->base))
 		return PTR_ERR(vt8500->base);
 
-	ret = devm_pwmchip_add(&pdev->dev, &vt8500->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0)
 		return dev_err_probe(&pdev->dev, ret, "failed to add PWM chip\n");
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:50 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:50 +0100
Subject: [PATCH v4 096/115] pwm: stmpe: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <3238b92e8714e6742cad31892f938982a63222de.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-stmpe driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-stmpe.c | 38 ++++++++++++++++++++------------------
 1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/pwm/pwm-stmpe.c b/drivers/pwm/pwm-stmpe.c
index 941b1e218e35..b9d06bcc6e93 100644
--- a/drivers/pwm/pwm-stmpe.c
+++ b/drivers/pwm/pwm-stmpe.c
@@ -27,13 +27,12 @@
 
 struct stmpe_pwm {
 	struct stmpe *stmpe;
-	struct pwm_chip chip;
 	u8 last_duty;
 };
 
 static inline struct stmpe_pwm *to_stmpe_pwm(struct pwm_chip *chip)
 {
-	return container_of(chip, struct stmpe_pwm, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int stmpe_24xx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
@@ -292,33 +291,36 @@ static const struct pwm_ops stmpe_24xx_pwm_ops = {
 static int __init stmpe_pwm_probe(struct platform_device *pdev)
 {
 	struct stmpe *stmpe = dev_get_drvdata(pdev->dev.parent);
+	struct pwm_chip *chip;
 	struct stmpe_pwm *stmpe_pwm;
 	int ret;
 
-	stmpe_pwm = devm_kzalloc(&pdev->dev, sizeof(*stmpe_pwm), GFP_KERNEL);
-	if (!stmpe_pwm)
-		return -ENOMEM;
+	switch (stmpe->partnum) {
+	case STMPE2401:
+	case STMPE2403:
+		break;
+	case STMPE1601:
+		return dev_err_probe(&pdev->dev, -EINVAL,
+				     "STMPE1601 not yet supported\n");
+	default:
+		return dev_err_probe(&pdev->dev, -EINVAL,
+				     "Unknown STMPE PWM\n");
+	}
+
+	chip = devm_pwmchip_alloc(&pdev->dev, 3, sizeof(*stmpe_pwm));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	stmpe_pwm = to_stmpe_pwm(chip);
 
 	stmpe_pwm->stmpe = stmpe;
-	stmpe_pwm->chip.dev = &pdev->dev;
 
-	if (stmpe->partnum == STMPE2401 || stmpe->partnum == STMPE2403) {
-		stmpe_pwm->chip.ops = &stmpe_24xx_pwm_ops;
-		stmpe_pwm->chip.npwm = 3;
-	} else {
-		if (stmpe->partnum == STMPE1601)
-			dev_err(&pdev->dev, "STMPE1601 not yet supported\n");
-		else
-			dev_err(&pdev->dev, "Unknown STMPE PWM\n");
-
-		return -ENODEV;
-	}
+	chip->ops = &stmpe_24xx_pwm_ops;
 
 	ret = stmpe_enable(stmpe, STMPE_BLOCK_PWM);
 	if (ret)
 		return ret;
 
-	ret = pwmchip_add(&stmpe_pwm->chip);
+	ret = pwmchip_add(chip);
 	if (ret) {
 		stmpe_disable(stmpe, STMPE_BLOCK_PWM);
 		return ret;
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:32 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:32 +0100
Subject: [PATCH v4 078/115] pwm: mxs: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <953de9fc4e4d34d32ce27b7ec6b301cd08c1fff2.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-mxs driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-mxs.c | 32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
index 1b5e787d78f1..8cad214b1c29 100644
--- a/drivers/pwm/pwm-mxs.c
+++ b/drivers/pwm/pwm-mxs.c
@@ -37,12 +37,14 @@ static const u8 cdiv_shift[PERIOD_CDIV_MAX] = {
 };
 
 struct mxs_pwm_chip {
-	struct pwm_chip chip;
 	struct clk *clk;
 	void __iomem *base;
 };
 
-#define to_mxs_pwm_chip(_chip) container_of(_chip, struct mxs_pwm_chip, chip)
+static inline struct mxs_pwm_chip *to_mxs_pwm_chip(struct pwm_chip *chip)
+{
+	return pwmchip_get_drvdata(chip);
+}
 
 static int mxs_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 			 const struct pwm_state *state)
@@ -120,12 +122,21 @@ static const struct pwm_ops mxs_pwm_ops = {
 static int mxs_pwm_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
+	struct pwm_chip *chip;
 	struct mxs_pwm_chip *mxs;
+	u32 npwm;
 	int ret;
 
-	mxs = devm_kzalloc(&pdev->dev, sizeof(*mxs), GFP_KERNEL);
-	if (!mxs)
-		return -ENOMEM;
+	ret = of_property_read_u32(np, "fsl,pwm-number", &npwm);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to get pwm number: %d\n", ret);
+		return ret;
+	}
+
+	chip = devm_pwmchip_alloc(&pdev->dev, npwm, sizeof(*mxs));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	mxs = to_mxs_pwm_chip(chip);
 
 	mxs->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(mxs->base))
@@ -135,21 +146,14 @@ static int mxs_pwm_probe(struct platform_device *pdev)
 	if (IS_ERR(mxs->clk))
 		return PTR_ERR(mxs->clk);
 
-	mxs->chip.dev = &pdev->dev;
-	mxs->chip.ops = &mxs_pwm_ops;
-
-	ret = of_property_read_u32(np, "fsl,pwm-number", &mxs->chip.npwm);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "failed to get pwm number: %d\n", ret);
-		return ret;
-	}
+	chip->ops = &mxs_pwm_ops;
 
 	/* FIXME: Only do this if the PWM isn't already running */
 	ret = stmp_reset_block(mxs->base);
 	if (ret)
 		return dev_err_probe(&pdev->dev, ret, "failed to reset PWM\n");
 
-	ret = devm_pwmchip_add(&pdev->dev, &mxs->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "failed to add pwm chip %d\n", ret);
 		return ret;
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:51 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:51 +0100
Subject: [PATCH v4 097/115] pwm: sun4i: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <c79e120b120df9eedddaaf70364d28e15df23d91.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-sun4i driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-sun4i.c | 34 +++++++++++++++++++---------------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 44edf1ce5739..36a8dc65b19c 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -81,7 +81,6 @@ struct sun4i_pwm_data {
 };
 
 struct sun4i_pwm_chip {
-	struct pwm_chip chip;
 	struct clk *bus_clk;
 	struct clk *clk;
 	struct reset_control *rst;
@@ -92,7 +91,7 @@ struct sun4i_pwm_chip {
 
 static inline struct sun4i_pwm_chip *to_sun4i_pwm_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct sun4i_pwm_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static inline u32 sun4i_pwm_readl(struct sun4i_pwm_chip *chip,
@@ -384,17 +383,22 @@ MODULE_DEVICE_TABLE(of, sun4i_pwm_dt_ids);
 
 static int sun4i_pwm_probe(struct platform_device *pdev)
 {
+	struct pwm_chip *chip;
 	struct sun4i_pwm_chip *sun4ichip;
+	const struct sun4i_pwm_data *data;
 	int ret;
 
-	sun4ichip = devm_kzalloc(&pdev->dev, sizeof(*sun4ichip), GFP_KERNEL);
-	if (!sun4ichip)
-		return -ENOMEM;
-
-	sun4ichip->data = of_device_get_match_data(&pdev->dev);
-	if (!sun4ichip->data)
+	data = of_device_get_match_data(&pdev->dev);
+	if (!data)
 		return -ENODEV;
 
+	chip = devm_pwmchip_alloc(&pdev->dev, data->npwm, sizeof(*sun4ichip));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	sun4ichip = to_sun4i_pwm_chip(chip);
+
+	sun4ichip->data = data;
+
 	sun4ichip->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(sun4ichip->base))
 		return PTR_ERR(sun4ichip->base);
@@ -451,19 +455,18 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
 		goto err_bus;
 	}
 
-	sun4ichip->chip.dev = &pdev->dev;
-	sun4ichip->chip.ops = &sun4i_pwm_ops;
-	sun4ichip->chip.npwm = sun4ichip->data->npwm;
+	chip->ops = &sun4i_pwm_ops;
+	chip->npwm = sun4ichip->data->npwm;
 
 	spin_lock_init(&sun4ichip->ctrl_lock);
 
-	ret = pwmchip_add(&sun4ichip->chip);
+	ret = pwmchip_add(chip);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
 		goto err_pwm_add;
 	}
 
-	platform_set_drvdata(pdev, sun4ichip);
+	platform_set_drvdata(pdev, chip);
 
 	return 0;
 
@@ -477,9 +480,10 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
 
 static void sun4i_pwm_remove(struct platform_device *pdev)
 {
-	struct sun4i_pwm_chip *sun4ichip = platform_get_drvdata(pdev);
+	struct pwm_chip *chip = platform_get_drvdata(pdev);
+	struct sun4i_pwm_chip *sun4ichip = to_sun4i_pwm_chip(chip);
 
-	pwmchip_remove(&sun4ichip->chip);
+	pwmchip_remove(chip);
 
 	clk_disable_unprepare(sun4ichip->bus_clk);
 	reset_control_assert(sun4ichip->rst);
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:48 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:48 +0100
Subject: [PATCH v4 094/115] pwm: stm32-lp: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <08caf1d4a05831c7372d5f9c888dd495c01ddb26.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-stm32-lp driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-stm32-lp.c | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 3754faeca838..579fea9a0da4 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -18,14 +18,13 @@
 #include <linux/pwm.h>
 
 struct stm32_pwm_lp {
-	struct pwm_chip chip;
 	struct clk *clk;
 	struct regmap *regmap;
 };
 
 static inline struct stm32_pwm_lp *to_stm32_pwm_lp(struct pwm_chip *chip)
 {
-	return container_of(chip, struct stm32_pwm_lp, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 /* STM32 Low-Power Timer is preceded by a configurable power-of-2 prescaler */
@@ -196,20 +195,20 @@ static const struct pwm_ops stm32_pwm_lp_ops = {
 static int stm32_pwm_lp_probe(struct platform_device *pdev)
 {
 	struct stm32_lptimer *ddata = dev_get_drvdata(pdev->dev.parent);
+	struct pwm_chip *chip;
 	struct stm32_pwm_lp *priv;
 	int ret;
 
-	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
-	if (!priv)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*priv));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	priv = to_stm32_pwm_lp(chip);
 
 	priv->regmap = ddata->regmap;
 	priv->clk = ddata->clk;
-	priv->chip.dev = &pdev->dev;
-	priv->chip.ops = &stm32_pwm_lp_ops;
-	priv->chip.npwm = 1;
+	chip->ops = &stm32_pwm_lp_ops;
 
-	ret = devm_pwmchip_add(&pdev->dev, &priv->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0)
 		return ret;
 
@@ -220,13 +219,13 @@ static int stm32_pwm_lp_probe(struct platform_device *pdev)
 
 static int stm32_pwm_lp_suspend(struct device *dev)
 {
-	struct stm32_pwm_lp *priv = dev_get_drvdata(dev);
+	struct pwm_chip *chip = dev_get_drvdata(dev);
 	struct pwm_state state;
 
-	pwm_get_state(&priv->chip.pwms[0], &state);
+	pwm_get_state(&chip->pwms[0], &state);
 	if (state.enabled) {
 		dev_err(dev, "The consumer didn't stop us (%s)\n",
-			priv->chip.pwms[0].label);
+			chip->pwms[0].label);
 		return -EBUSY;
 	}
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:59 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:59 +0100
Subject: [PATCH v4 105/115] pwm: xilinx: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <9accf9867f66b90166aa52ff28d0634f917a73d1.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-xilinx driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-xilinx.c | 34 ++++++++++++++--------------------
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/pwm/pwm-xilinx.c b/drivers/pwm/pwm-xilinx.c
index 5f3c2a6fed11..465ac9617256 100644
--- a/drivers/pwm/pwm-xilinx.c
+++ b/drivers/pwm/pwm-xilinx.c
@@ -80,15 +80,10 @@ unsigned int xilinx_timer_get_period(struct xilinx_timer_priv *priv,
 #define TCSR_PWM_CLEAR (TCSR_MDT | TCSR_LOAD)
 #define TCSR_PWM_MASK (TCSR_PWM_SET | TCSR_PWM_CLEAR)
 
-struct xilinx_pwm_device {
-	struct pwm_chip chip;
-	struct xilinx_timer_priv priv;
-};
-
 static inline struct xilinx_timer_priv
 *xilinx_pwm_chip_to_priv(struct pwm_chip *chip)
 {
-	return &container_of(chip, struct xilinx_pwm_device, chip)->priv;
+	return pwmchip_get_drvdata(chip);
 }
 
 static bool xilinx_timer_pwm_enabled(u32 tcsr0, u32 tcsr1)
@@ -213,8 +208,8 @@ static int xilinx_pwm_probe(struct platform_device *pdev)
 	int ret;
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
+	struct pwm_chip *chip;
 	struct xilinx_timer_priv *priv;
-	struct xilinx_pwm_device *xilinx_pwm;
 	u32 pwm_cells, one_timer, width;
 	void __iomem *regs;
 
@@ -225,11 +220,11 @@ static int xilinx_pwm_probe(struct platform_device *pdev)
 	if (ret)
 		return dev_err_probe(dev, ret, "could not read #pwm-cells\n");
 
-	xilinx_pwm = devm_kzalloc(dev, sizeof(*xilinx_pwm), GFP_KERNEL);
-	if (!xilinx_pwm)
-		return -ENOMEM;
-	platform_set_drvdata(pdev, xilinx_pwm);
-	priv = &xilinx_pwm->priv;
+	chip = devm_pwmchip_alloc(dev, 1, sizeof(*priv));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	priv = xilinx_pwm_chip_to_priv(chip);
+	platform_set_drvdata(pdev, chip);
 
 	regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(regs))
@@ -278,10 +273,8 @@ static int xilinx_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, ret, "Clock enable failed\n");
 	clk_rate_exclusive_get(priv->clk);
 
-	xilinx_pwm->chip.dev = dev;
-	xilinx_pwm->chip.ops = &xilinx_pwm_ops;
-	xilinx_pwm->chip.npwm = 1;
-	ret = pwmchip_add(&xilinx_pwm->chip);
+	chip->ops = &xilinx_pwm_ops;
+	ret = pwmchip_add(chip);
 	if (ret) {
 		clk_rate_exclusive_put(priv->clk);
 		clk_disable_unprepare(priv->clk);
@@ -293,11 +286,12 @@ static int xilinx_pwm_probe(struct platform_device *pdev)
 
 static void xilinx_pwm_remove(struct platform_device *pdev)
 {
-	struct xilinx_pwm_device *xilinx_pwm = platform_get_drvdata(pdev);
+	struct pwm_chip *chip = platform_get_drvdata(pdev);
+	struct xilinx_timer_priv *priv = xilinx_pwm_chip_to_priv(chip);
 
-	pwmchip_remove(&xilinx_pwm->chip);
-	clk_rate_exclusive_put(xilinx_pwm->priv.clk);
-	clk_disable_unprepare(xilinx_pwm->priv.clk);
+	pwmchip_remove(chip);
+	clk_rate_exclusive_put(priv->clk);
+	clk_disable_unprepare(priv->clk);
 }
 
 static const struct of_device_id xilinx_pwm_of_match[] = {
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:57 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:57 +0100
Subject: [PATCH v4 103/115] pwm: visconti: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e8c7c3837df04f7c612b80079c64352c83cd3ab6.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-visconti driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-visconti.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
index 8d736d558122..9e55380957be 100644
--- a/drivers/pwm/pwm-visconti.c
+++ b/drivers/pwm/pwm-visconti.c
@@ -34,13 +34,12 @@
 #define PIPGM_PWMC_POLARITY_MASK	GENMASK(5, 5)
 
 struct visconti_pwm_chip {
-	struct pwm_chip chip;
 	void __iomem *base;
 };
 
 static inline struct visconti_pwm_chip *visconti_pwm_from_chip(struct pwm_chip *chip)
 {
-	return container_of(chip, struct visconti_pwm_chip, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -134,22 +133,22 @@ static const struct pwm_ops visconti_pwm_ops = {
 static int visconti_pwm_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
+	struct pwm_chip *chip;
 	struct visconti_pwm_chip *priv;
 	int ret;
 
-	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
-	if (!priv)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(dev, 4, sizeof(*priv));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	priv = visconti_pwm_from_chip(chip);
 
 	priv->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(priv->base))
 		return PTR_ERR(priv->base);
 
-	priv->chip.dev = dev;
-	priv->chip.ops = &visconti_pwm_ops;
-	priv->chip.npwm = 4;
+	chip->ops = &visconti_pwm_ops;
 
-	ret = devm_pwmchip_add(&pdev->dev, &priv->chip);
+	ret = devm_pwmchip_add(&pdev->dev, chip);
 	if (ret < 0)
 		return dev_err_probe(&pdev->dev, ret, "Cannot register visconti PWM\n");
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Wed Dec  6 03:44:49 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 12:44:49 +0100
Subject: [PATCH v4 095/115] pwm: stm32: Make use of devm_pwmchip_alloc() function
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <11f47a97a66786752f6a6482318c49681bfa018b.1701860672.git.u.kleine-koenig@pengutronix.de>

This prepares the pwm-stm32 driver to further changes of the pwm core
outlined in the commit introducing devm_pwmchip_alloc(). There is no
intended semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-stm32.c | 51 ++++++++++++++++++++++-------------------
 1 file changed, 27 insertions(+), 24 deletions(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index d1dc9e3ca2a1..aae8bd4f40ab 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -27,7 +27,6 @@ struct stm32_breakinput {
 };
 
 struct stm32_pwm {
-	struct pwm_chip chip;
 	struct mutex lock; /* protect pwm config/enable */
 	struct clk *clk;
 	struct regmap *regmap;
@@ -40,7 +39,7 @@ struct stm32_pwm {
 
 static inline struct stm32_pwm *to_stm32_pwm_dev(struct pwm_chip *chip)
 {
-	return container_of(chip, struct stm32_pwm, chip);
+	return pwmchip_get_drvdata(chip);
 }
 
 static u32 active_channels(struct stm32_pwm *dev)
@@ -90,11 +89,12 @@ static u32 active_channels(struct stm32_pwm *dev)
  * - Period     = t2 - t0
  * - Duty cycle = t1 - t0
  */
-static int stm32_pwm_raw_capture(struct stm32_pwm *priv, struct pwm_device *pwm,
+static int stm32_pwm_raw_capture(struct pwm_chip *chip, struct pwm_device *pwm,
 				 unsigned long tmo_ms, u32 *raw_prd,
 				 u32 *raw_dty)
 {
-	struct device *parent = pwmchip_parent(&priv->chip)->parent;
+	struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
+	struct device *parent = pwmchip_parent(chip)->parent;
 	enum stm32_timers_dmas dma_id;
 	u32 ccen, ccr;
 	int ret;
@@ -208,7 +208,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct pwm_device *pwm,
 			   TIM_CCER_CC12P : TIM_CCER_CC34P, pwm->hwpwm < 2 ?
 			   TIM_CCER_CC2P : TIM_CCER_CC4P);
 
-	ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, &raw_prd, &raw_dty);
+	ret = stm32_pwm_raw_capture(chip, pwm, tmo_ms, &raw_prd, &raw_dty);
 	if (ret)
 		goto stop;
 
@@ -229,7 +229,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct pwm_device *pwm,
 		/* 2nd measure with new scale */
 		psc /= scale;
 		regmap_write(priv->regmap, TIM_PSC, psc);
-		ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, &raw_prd,
+		ret = stm32_pwm_raw_capture(chip, pwm, tmo_ms, &raw_prd,
 					    &raw_dty);
 		if (ret)
 			goto stop;
@@ -257,7 +257,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct pwm_device *pwm,
 			   FIELD_PREP(TIM_CCMR_IC1PSC, icpsc) |
 			   FIELD_PREP(TIM_CCMR_IC2PSC, icpsc));
 
-	ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, &raw_prd, &raw_dty);
+	ret = stm32_pwm_raw_capture(chip, pwm, tmo_ms, &raw_prd, &raw_dty);
 	if (ret)
 		goto stop;
 
@@ -605,7 +605,7 @@ static void stm32_pwm_detect_complementary(struct stm32_pwm *priv)
 	priv->have_complementary_output = (ccer != 0);
 }
 
-static unsigned int stm32_pwm_detect_channels(struct stm32_pwm *priv,
+static unsigned int stm32_pwm_detect_channels(struct stm32_timers *ddata,
 					      unsigned int *num_enabled)
 {
 	u32 ccer, ccer_backup;
@@ -614,10 +614,10 @@ static unsigned int stm32_pwm_detect_channels(struct stm32_pwm *priv,
 	 * If channels enable bits don't exist writing 1 will have no
 	 * effect so we can detect and count them.
 	 */
-	regmap_read(priv->regmap, TIM_CCER, &ccer_backup);
-	regmap_set_bits(priv->regmap, TIM_CCER, TIM_CCER_CCXE);
-	regmap_read(priv->regmap, TIM_CCER, &ccer);
-	regmap_write(priv->regmap, TIM_CCER, ccer_backup);
+	regmap_read(ddata->regmap, TIM_CCER, &ccer_backup);
+	regmap_set_bits(ddata->regmap, TIM_CCER, TIM_CCER_CCXE);
+	regmap_read(ddata->regmap, TIM_CCER, &ccer);
+	regmap_write(ddata->regmap, TIM_CCER, ccer_backup);
 
 	*num_enabled = hweight32(ccer_backup & TIM_CCER_CCXE);
 
@@ -632,11 +632,14 @@ static int stm32_pwm_probe(struct platform_device *pdev)
 	struct stm32_pwm *priv;
 	unsigned int num_enabled;
 	unsigned int i;
+	struct pwm_chip *chip;
 	int ret;
 
-	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
-	if (!priv)
-		return -ENOMEM;
+	chip = devm_pwmchip_alloc(dev, stm32_pwm_detect_channels(ddata, &num_enabled),
+				  sizeof(*priv));
+	if (IS_ERR(chip))
+		return PTR_ERR(chip);
+	priv = to_stm32_pwm_dev(chip);
 
 	mutex_init(&priv->lock);
 	priv->regmap = ddata->regmap;
@@ -652,37 +655,36 @@ static int stm32_pwm_probe(struct platform_device *pdev)
 
 	stm32_pwm_detect_complementary(priv);
 
-	priv->chip.dev = dev;
-	priv->chip.ops = &stm32pwm_ops;
-	priv->chip.npwm = stm32_pwm_detect_channels(priv, &num_enabled);
+	chip->ops = &stm32pwm_ops;
 
 	/* Initialize clock refcount to number of enabled PWM channels. */
 	for (i = 0; i < num_enabled; i++)
 		clk_enable(priv->clk);
 
-	ret = devm_pwmchip_add(dev, &priv->chip);
+	ret = devm_pwmchip_add(dev, chip);
 	if (ret < 0)
 		return ret;
 
-	platform_set_drvdata(pdev, priv);
+	platform_set_drvdata(pdev, chip);
 
 	return 0;
 }
 
 static int stm32_pwm_suspend(struct device *dev)
 {
-	struct stm32_pwm *priv = dev_get_drvdata(dev);
+	struct pwm_chip *chip = dev_get_drvdata(dev);
+	struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
 	unsigned int i;
 	u32 ccer, mask;
 
 	/* Look for active channels */
 	ccer = active_channels(priv);
 
-	for (i = 0; i < priv->chip.npwm; i++) {
+	for (i = 0; i < chip->npwm; i++) {
 		mask = TIM_CCER_CC1E << (i * 4);
 		if (ccer & mask) {
 			dev_err(dev, "PWM %u still in use by consumer %s\n",
-				i, priv->chip.pwms[i].label);
+				i, chip->pwms[i].label);
 			return -EBUSY;
 		}
 	}
@@ -692,7 +694,8 @@ static int stm32_pwm_suspend(struct device *dev)
 
 static int stm32_pwm_resume(struct device *dev)
 {
-	struct stm32_pwm *priv = dev_get_drvdata(dev);
+	struct pwm_chip *chip = dev_get_drvdata(dev);
+	struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
 	int ret;
 
 	ret = pinctrl_pm_select_default_state(dev);
-- 
2.42.0



From lpieralisi at kernel.org  Wed Dec  6 03:52:22 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Wed, 6 Dec 2023 12:52:22 +0100
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZW9uqu7yOtyZfmvC@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <86bkb4bn2v.wl-maz@kernel.org>
 <ZW9ezSGSDIvv5MsQ@arm.com>
 <86a5qobkt8.wl-maz@kernel.org>
 <ZW9uqu7yOtyZfmvC@arm.com>
Message-ID: <ZXBgdnz7wVYuDCgU@lpieralisi>

On Tue, Dec 05, 2023 at 06:40:42PM +0000, Catalin Marinas wrote:
> On Tue, Dec 05, 2023 at 05:50:27PM +0000, Marc Zyngier wrote:
> > On Tue, 05 Dec 2023 17:33:01 +0000,
> > Catalin Marinas <catalin.marinas at arm.com> wrote:
> > > Ideally we should do this for vfio only but we don't have an easy
> > > way to convey this to KVM.
> > 
> > But if we want to limit this to PCIe, we'll have to find out. The
> > initial proposal (a long while ago) had a flag conveying some
> > information, and I'd definitely feel more confident having something
> > like that.
> 
> We can add a VM_PCI_IO in the high vma flags to be set by
> vfio_pci_core_mmap(), though it limits it to 64-bit architectures. KVM
> knows this is PCI and relaxes things a bit. It's not generic though if
> we need this later for something else.
> 
> A question for Lorenzo: do these BARs appear in iomem_resource? We could
> search that up instead of a flag, something like the page_is_ram()
> helper.

They do but an iomem_resource look-up alone if I am not mistaken would
not tell us if it is PCI address space, we would need additional checks
(like detecting if we are decoding an address within a PCI host bridge
windows) to determine that if we go down this route.

Lorenzo


From krzysztof.kozlowski at linaro.org  Wed Dec  6 03:53:30 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed,  6 Dec 2023 12:53:30 +0100
Subject: [PATCH 1/3] dt-bindings: arm: coresight: restrict single port subnodes
Message-ID: <20231206115332.22712-1-krzysztof.kozlowski@linaro.org>

"in-ports" and "out-ports" with single "port" subnode should use
"additionalProperties: false" to disallow any other properties mentioned
by graph schema which are not applicable for this case, e.g.
"address-cells".

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../devicetree/bindings/arm/arm,coresight-dummy-sink.yaml        | 1 +
 .../devicetree/bindings/arm/arm,coresight-dummy-source.yaml      | 1 +
 Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml   | 1 +
 Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml   | 1 +
 4 files changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
index c960c8e0a9a5..61143907bcde 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
@@ -41,6 +41,7 @@ properties:
 
   in-ports:
     $ref: /schemas/graph.yaml#/properties/ports
+    additionalProperties: false
 
     properties:
       port:
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
index 6745b4cc8f1c..a71a05c58cc6 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
@@ -40,6 +40,7 @@ properties:
 
   out-ports:
     $ref: /schemas/graph.yaml#/properties/ports
+    additionalProperties: false
 
     properties:
       port:
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
index ea3c5db6b52d..e55f69c2ff38 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
@@ -76,6 +76,7 @@ properties:
     description: |
       Output connections from the TPDA to legacy CoreSight trace bus.
     $ref: /schemas/graph.yaml#/properties/ports
+    additionalProperties: false
 
     properties:
       port:
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
index 61ddc3b5b247..6984003485e8 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
@@ -72,6 +72,7 @@ properties:
     description: |
       Output connections from the TPDM to coresight funnel/TPDA.
     $ref: /schemas/graph.yaml#/properties/ports
+    additionalProperties: false
 
     properties:
       port:
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Wed Dec  6 03:53:31 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed,  6 Dec 2023 12:53:31 +0100
Subject: [PATCH 2/3] dt-bindings: arm: qcom,coresight-tpda: drop redundant type from ports
In-Reply-To: <20231206115332.22712-1-krzysztof.kozlowski@linaro.org>
References: <20231206115332.22712-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231206115332.22712-2-krzysztof.kozlowski@linaro.org>

"in-ports" and "out-ports" are defined by graph schema, so defining its
type is redundant.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
index e55f69c2ff38..66d291b56019 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
@@ -66,13 +66,11 @@ properties:
       - const: apb_pclk
 
   in-ports:
-    type: object
     description: |
       Input connections from TPDM to TPDA
     $ref: /schemas/graph.yaml#/properties/ports
 
   out-ports:
-    type: object
     description: |
       Output connections from the TPDA to legacy CoreSight trace bus.
     $ref: /schemas/graph.yaml#/properties/ports
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Wed Dec  6 03:53:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed,  6 Dec 2023 12:53:32 +0100
Subject: [PATCH 3/3] dt-bindings: arm: qcom,coresight-tpda: fix indentation in the example
In-Reply-To: <20231206115332.22712-1-krzysztof.kozlowski@linaro.org>
References: <20231206115332.22712-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231206115332.22712-3-krzysztof.kozlowski@linaro.org>

Fix triple-space indentation to double-space in the example DTS.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/arm/qcom,coresight-tpda.yaml     | 32 +++++++++----------
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
index 66d291b56019..b748cf21a4d7 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
@@ -96,33 +96,31 @@ examples:
   # minimum tpda definition.
   - |
     tpda at 6004000 {
-       compatible = "qcom,coresight-tpda", "arm,primecell";
-       reg = <0x6004000 0x1000>;
+      compatible = "qcom,coresight-tpda", "arm,primecell";
+      reg = <0x6004000 0x1000>;
 
-       clocks = <&aoss_qmp>;
-       clock-names = "apb_pclk";
+      clocks = <&aoss_qmp>;
+      clock-names = "apb_pclk";
 
-       in-ports {
-         #address-cells = <1>;
-         #size-cells = <0>;
+      in-ports {
+        #address-cells = <1>;
+        #size-cells = <0>;
 
         port at 0 {
           reg = <0>;
           tpda_qdss_0_in_tpdm_dcc: endpoint {
-            remote-endpoint =
-              <&tpdm_dcc_out_tpda_qdss_0>;
-            };
+            remote-endpoint = <&tpdm_dcc_out_tpda_qdss_0>;
+          };
         };
       };
 
-       out-ports {
-         port {
-                 tpda_qdss_out_funnel_in0: endpoint {
-                    remote-endpoint =
-                    <&funnel_in0_in_tpda_qdss>;
-                  };
+      out-ports {
+        port {
+          tpda_qdss_out_funnel_in0: endpoint {
+            remote-endpoint = <&funnel_in0_in_tpda_qdss>;
           };
-       };
+        };
+      };
     };
 
 ...
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 03:58:24 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 08:58:24 -0300
Subject: [PATCH 1/3] ARM: dts: imx25: Pass I2C clock-names property
Message-ID: <20231206115826.2244964-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per i2c-imx.yaml, 'clock-names' is a required property.

Pass it to fix the following dt-schema warning:

imx25-pdk.dtb: i2c at 43f80000: clock-names:0: 'ipg' was expected
	from schema $id: http://devicetree.org/schemas/i2c/i2c-imx.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx25.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx25.dtsi b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
index 534c70b8d79d..21c968341b3c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
@@ -93,7 +93,7 @@ i2c1: i2c at 43f80000 {
 				compatible = "fsl,imx25-i2c", "fsl,imx21-i2c";
 				reg = <0x43f80000 0x4000>;
 				clocks = <&clks 48>;
-				clock-names = "";
+				clock-names = "ipg";
 				interrupts = <3>;
 				status = "disabled";
 			};
@@ -104,7 +104,7 @@ i2c3: i2c at 43f84000 {
 				compatible = "fsl,imx25-i2c", "fsl,imx21-i2c";
 				reg = <0x43f84000 0x4000>;
 				clocks = <&clks 48>;
-				clock-names = "";
+				clock-names = "ipg";
 				interrupts = <10>;
 				status = "disabled";
 			};
@@ -151,7 +151,7 @@ i2c2: i2c at 43f98000 {
 				compatible = "fsl,imx25-i2c", "fsl,imx21-i2c";
 				reg = <0x43f98000 0x4000>;
 				clocks = <&clks 48>;
-				clock-names = "";
+				clock-names = "ipg";
 				interrupts = <4>;
 				status = "disabled";
 			};
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 03:58:25 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 08:58:25 -0300
Subject: [PATCH 2/3] ARM: dts: imx25-pdk: Pass #sound-dai-cells
In-Reply-To: <20231206115826.2244964-1-festevam@gmail.com>
References: <20231206115826.2244964-1-festevam@gmail.com>
Message-ID: <20231206115826.2244964-2-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per sgtl5000.yaml, '#sound-dai-cells' is a required property.

Pass it to fix the following dt-schema warning:

imx25-pdk.dtb: sgtl5000 at a: '#sound-dai-cells' is a required property
	from schema $id: http://devicetree.org/schemas/sound/sgtl5000.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx25-pdk.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts b/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
index 04f4b127a172..14a61dc1e742 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
@@ -122,6 +122,7 @@ &i2c1 {
 	codec: sgtl5000 at a {
 		compatible = "fsl,sgtl5000";
 		reg = <0x0a>;
+		 #sound-dai-cells = <0>;
 		clocks = <&clks 129>;
 		VDDA-supply = <&reg_2p5v>;
 		VDDIO-supply = <&reg_3p3v>;
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 03:58:26 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 08:58:26 -0300
Subject: [PATCH 3/3] ARM: dts: imx25/27-eukrea: Fix RTC node name
In-Reply-To: <20231206115826.2244964-1-festevam@gmail.com>
References: <20231206115826.2244964-1-festevam@gmail.com>
Message-ID: <20231206115826.2244964-3-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Node names should be generic. Use 'rtc' as node name to fix
the following dt-schema warning:

imx25-eukrea-mbimxsd25-baseboard.dtb: pcf8563 at 51: $nodename:0: 'pcf8563 at 51' does not match '^rtc(@.*|-([0-9]|[1-9][0-9]+))?$'
	from schema $id: http://devicetree.org/schemas/rtc/nxp,pcf8563.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx25-eukrea-cpuimx25.dtsi | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-cpuimx25.dtsi b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-cpuimx25.dtsi
index 0703f62d10d1..93a6e4e680b4 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-cpuimx25.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-cpuimx25.dtsi
@@ -27,7 +27,7 @@ &i2c1 {
 	pinctrl-0 = <&pinctrl_i2c1>;
 	status = "okay";
 
-	pcf8563 at 51 {
+	rtc at 51 {
 		compatible = "nxp,pcf8563";
 		reg = <0x51>;
 	};
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi
index 74110bbcd9d4..4b83e2918b55 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi
@@ -33,7 +33,7 @@ &i2c1 {
 	pinctrl-0 = <&pinctrl_i2c1>;
 	status = "okay";
 
-	pcf8563 at 51 {
+	rtc at 51 {
 		compatible = "nxp,pcf8563";
 		reg = <0x51>;
 	};
-- 
2.34.1



From hch at infradead.org  Wed Dec  6 04:09:30 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Wed, 6 Dec 2023 04:09:30 -0800
Subject: [PATCH V1] scsi: ufs: core: store min and max clk freq from OPP
 table
In-Reply-To: <20231206075447.GA4954@thinkpad>
References: <20231206053628.32169-1-quic_nitirawa@quicinc.com>
 <20231206075447.GA4954@thinkpad>
Message-ID: <ZXBkeqyoA1E3bznx@infradead.org>

On Wed, Dec 06, 2023 at 01:24:47PM +0530, Manivannan Sadhasivam wrote:
> But these values are used by the vendor host drivers internally for controller
> configuration. When the OPP support is enabled in devicetree, these values will

There is no such thing as a "vendor" driver.



From catalin.marinas at arm.com  Wed Dec  6 04:14:18 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 6 Dec 2023 12:14:18 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <868r67blwo.wl-maz@kernel.org>
References: <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <86bkb4bn2v.wl-maz@kernel.org>
 <ZW9ezSGSDIvv5MsQ@arm.com>
 <86a5qobkt8.wl-maz@kernel.org>
 <ZW9uqu7yOtyZfmvC@arm.com>
 <868r67blwo.wl-maz@kernel.org>
Message-ID: <ZXBlmt88dKmZLCU9@arm.com>

On Wed, Dec 06, 2023 at 11:39:03AM +0000, Marc Zyngier wrote:
> On Tue, 05 Dec 2023 18:40:42 +0000,
> Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Tue, Dec 05, 2023 at 05:50:27PM +0000, Marc Zyngier wrote:
> > > On Tue, 05 Dec 2023 17:33:01 +0000,
> > > Catalin Marinas <catalin.marinas at arm.com> wrote:
> > > > Ideally we should do this for vfio only but we don't have an easy
> > > > way to convey this to KVM.
> > > 
> > > But if we want to limit this to PCIe, we'll have to find out. The
> > > initial proposal (a long while ago) had a flag conveying some
> > > information, and I'd definitely feel more confident having something
> > > like that.
> > 
> > We can add a VM_PCI_IO in the high vma flags to be set by
> > vfio_pci_core_mmap(), though it limits it to 64-bit architectures. KVM
> > knows this is PCI and relaxes things a bit. It's not generic though if
> > we need this later for something else.
> 
> Either that, or something actually describing the attributes that VFIO
> wants.
> 
> And I very much want it to be a buy-in behaviour, not something that
> automagically happens and changes the default behaviour for everyone
> based on some hand-wavy assertions.
> 
> If that means a userspace change, fine by me. The VMM better know what
> is happening.

Driving the attributes from a single point like the VFIO driver is
indeed better. The problem is that write-combining on Arm doesn't come
without speculative loads, otherwise we would have solved it by now. I
also recall the VFIO maintainer pushing back on relaxing the
pgprot_noncached() for the user mapping but I don't remember the
reasons.

We could do with a pgprot_maybewritecombine() or
pgprot_writecombinenospec() (similar to Jason's idea but without
changing the semantics of pgprot_device()). For the user mapping on
arm64 this would be Device (even _GRE) since it can't disable
speculation but stage 2 would leave the decision to the guest since the
speculative loads aren't much different from committed loads done
wrongly.

If we want the VMM to drive this entirely, we could add a new mmap()
flag like MAP_WRITECOMBINE or PROT_WRITECOMBINE. They do feel a bit
weird but there is precedent with PROT_MTE to describe a memory type.
One question is whether the VFIO driver still needs to have the
knowledge and sanitise the requests from the VMM within a single BAR. If
there are no security implications to such mappings, the VMM can map
parts of the BAR as pgprot_noncached(), other parts as
pgprot_writecombine() and KVM just follows them (similarly if we need a
cacheable mapping).

The latter has some benefits for DPDK but it's a lot more involved with
having to add device-specific knowledge into the VMM. The VMM would also
have to present the whole BAR contiguously to the guest even if there
are different mapping attributes within the range. So a lot of MAP_FIXED
uses. I'd rather leaving this decision with the guest than the VMM, it
looks like more hassle to create those mappings. The VMM or the VFIO
could only state write-combine and speculation allowed.

-- 
Catalin


From andi.shyti at kernel.org  Wed Dec  6 04:27:38 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Wed, 6 Dec 2023 13:27:38 +0100
Subject: [PATCH] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <20231206090641.18849-1-jensenhuang@friendlyarm.com>
References: <20231206090641.18849-1-jensenhuang@friendlyarm.com>
Message-ID: <20231206122738.cnnjxszz4g6zak3w@zenone.zhora.eu>

Hi Jensen,

On Wed, Dec 06, 2023 at 05:06:40PM +0800, Jensen Huang wrote:
> Possible deadlock scenario (on reboot):
> rk3x_i2c_xfer_common(polling)
>     -> rk3x_i2c_wait_xfer_poll()
>         -> rk3x_i2c_irq(0, i2c);
>             --> spin_lock(&i2c->lock);
>             ...
>         <rk3x i2c interrupt>
>         -> rk3x_i2c_irq(0, i2c);
>             --> spin_lock(&i2c->lock); (deadlock here)
> 
> Store the IRQ number and disable/enable it around the polling transfer.
> This patch has been tested on NanoPC-T4.
> 
> Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>

Looks good,

Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Thanks,
Andi


From andre.draszik at linaro.org  Wed Dec  6 04:30:38 2023
From: andre.draszik at linaro.org (=?ISO-8859-1?Q?Andr=E9?= Draszik)
Date: Wed, 06 Dec 2023 12:30:38 +0000
Subject: [PATCH v5 02/20] dt-bindings: clock: Add Google gs101 clock
 management unit bindings
In-Reply-To: <20231201160925.3136868-3-peter.griffin@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
	 <20231201160925.3136868-3-peter.griffin@linaro.org>
Message-ID: <6e595a110444033de6ecd35bedc6e84ea1c43fdc.camel@linaro.org>

Hi Pete,

On Fri, 2023-12-01 at 16:09 +0000, Peter Griffin wrote:
> [...]
> +...
> diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
> new file mode 100644
> index 000000000000..9f280f74578a
> --- /dev/null
> +++ b/include/dt-bindings/clock/google,gs101.h
> @@ -0,0 +1,392 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + * Author: Peter Griffin <peter.griffin at linaro.org>
> + *
> + * Device Tree binding constants for Google gs101 clock controller.
> + */
> +
> +#ifndef _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
> +#define _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
> +
> +/* CMU_TOP PLL */
> +#define CLK_FOUT_SHARED0_PLL		1
> +#define CLK_FOUT_SHARED1_PLL		2
> +#define CLK_FOUT_SHARED2_PLL		3
> +#define CLK_FOUT_SHARED3_PLL		4
> +#define CLK_FOUT_SPARE_PLL		5
> +
> +/* CMU_TOP MUX */
> +#define CLK_MOUT_SHARED0_PLL		6
> +#define CLK_MOUT_SHARED1_PLL		7
> +#define CLK_MOUT_SHARED2_PLL		8
> +#define CLK_MOUT_SHARED3_PLL		9
> +#define CLK_MOUT_SPARE_PLL		10
> +#define CLK_MOUT_BO_BUS			11
> +#define CLK_MOUT_BUS0_BUS		12
> +#define CLK_MOUT_BUS1_BUS		13
> +#define CLK_MOUT_BUS2_BUS		14
> +#define CLK_MOUT_CIS_CLK0		15
> +#define CLK_MOUT_CIS_CLK1		16
> +#define CLK_MOUT_CIS_CLK2		17
> +#define CLK_MOUT_CIS_CLK3		18
> +#define CLK_MOUT_CIS_CLK4		19
> +#define CLK_MOUT_CIS_CLK5		20
> +#define CLK_MOUT_CIS_CLK6		21
> +#define CLK_MOUT_CIS_CLK7		22
> +#define CLK_MOUT_CMU_BOOST		23
> +#define CLK_MOUT_BOOST_OPTION1		24
> +#define CLK_MOUT_CORE_BUS		25
> +#define CLK_MOUT_CPUCL0_DBG		26
> +#define CLK_MOUT_CPUCL0_SWITCH		27
> +#define CLK_MOUT_CPUCL1_SWITCH		28
> +#define CLK_MOUT_CPUCL2_SWITCH		29
> +#define CLK_MOUT_CSIS_BUS		30
> +#define CLK_MOUT_DISP_BUS		31
> +#define CLK_MOUT_DNS_BUS		32
> +#define CLK_MOUT_DPU_BUS		33
> +#define CLK_MOUT_EH_BUS			34
> +#define CLK_MOUT_G2D_G2D		35
> +#define CLK_MOUT_G2D_MSCL		36
> +#define CLK_MOUT_G3AA_G3AA		37
> +#define CLK_MOUT_G3D_BUSD		38
> +#define CLK_MOUT_G3D_GLB		39
> +#define CLK_MOUT_G3D_SWITCH		40
> +#define CLK_MOUT_GDC_GDC0		41
> +#define CLK_MOUT_GDC_GDC1		42
> +#define CLK_MOUT_GDC_SCSC		43
> +#define CLK_MOUT_CMU_HPM		44
> +#define CLK_MOUT_HSI0_BUS		45
> +#define CLK_MOUT_HSI0_DPGTC		46
> +#define CLK_MOUT_HSI0_USB31DRD		47
> +#define CLK_MOUT_HSI0_USBDPDGB		48
> +#define CLK_MOUT_HSI1_BUS		49
> +#define CLK_MOUT_HSI1_PCIE		50
> +#define CLK_MOUT_HSI2_BUS		51
> +#define CLK_MOUT_HSI2_MMC_CARD		52
> +#define CLK_MOUT_HSI2_PCIE		53
> +#define CLK_MOUT_HSI2_UFS_EMBD		54
> +#define CLK_MOUT_IPP_BUS		55
> +#define CLK_MOUT_ITP_BUS		56
> +#define CLK_MOUT_MCSC_ITSC		57
> +#define CLK_MOUT_MCSC_MCSC		58
> +#define CLK_MOUT_MFC_MFC		59
> +#define CLK_MOUT_MIF_BUSP		60
> +#define CLK_MOUT_MIF_SWITCH		61
> +#define CLK_MOUT_MISC_BUS		62
> +#define CLK_MOUT_MISC_SSS		63
> +#define CLK_MOUT_PDP_BUS		64
> +#define CLK_MOUT_PDP_VRA		65
> +#define CLK_MOUT_PERIC0_BUS		66
> +#define CLK_MOUT_PERIC0_IP		67
> +#define CLK_MOUT_PERIC1_BUS		68
> +#define CLK_MOUT_PERIC1_IP		69
> +#define CLK_MOUT_TNR_BUS		70
> +#define CLK_MOUT_TOP_BOOST_OPTION1	71
> +#define CLK_MOUT_TOP_CMUREF		72
> +#define CLK_MOUT_TPU_BUS		73
> +#define CLK_MOUT_TPU_TPU		74
> +#define CLK_MOUT_TPU_TPUCTL		75
> +#define CLK_MOUT_TPU_UART		76
> +#define CLK_MOUT_CMU_CMUREF		77
> +
> +/* CMU_TOP Dividers */
> +#define CLK_DOUT_BO_BUS			78
> +#define CLK_DOUT_BUS0_BUS		79
> +#define CLK_DOUT_BUS1_BUS		80
> +#define CLK_DOUT_BUS2_BUS		81
> +#define CLK_DOUT_CIS_CLK0		82
> +#define CLK_DOUT_CIS_CLK1		83
> +#define CLK_DOUT_CIS_CLK2		84
> +#define CLK_DOUT_CIS_CLK3		85
> +#define CLK_DOUT_CIS_CLK4		86
> +#define CLK_DOUT_CIS_CLK5		87
> +#define CLK_DOUT_CIS_CLK6		88
> +#define CLK_DOUT_CIS_CLK7		89
> +#define CLK_DOUT_CORE_BUS		90
> +#define CLK_DOUT_CPUCL0_DBG		91
> +#define CLK_DOUT_CPUCL0_SWITCH		92
> +#define CLK_DOUT_CPUCL1_SWITCH		93
> +#define CLK_DOUT_CPUCL2_SWITCH		94
> +#define CLK_DOUT_CSIS_BUS		95
> +#define CLK_DOUT_DISP_BUS		96
> +#define CLK_DOUT_DNS_BUS		97
> +#define CLK_DOUT_DPU_BUS		98
> +#define CLK_DOUT_EH_BUS			99
> +#define CLK_DOUT_G2D_G2D		100
> +#define CLK_DOUT_G2D_MSCL		101
> +#define CLK_DOUT_G3AA_G3AA		102
> +#define CLK_DOUT_G3D_BUSD		103
> +#define CLK_DOUT_G3D_GLB		104
> +#define CLK_DOUT_G3D_SWITCH		105
> +#define CLK_DOUT_GDC_GDC0		106
> +#define CLK_DOUT_GDC_GDC1		107
> +#define CLK_DOUT_GDC_SCSC		108
> +#define CLK_DOUT_CMU_HPM		109
> +#define CLK_DOUT_HSI0_BUS		110
> +#define CLK_DOUT_HSI0_DPGTC		111
> +#define CLK_DOUT_HSI0_USB31DRD		112
> +#define CLK_DOUT_HSI0_USBDPDGB		113
> +#define CLK_DOUT_HSI1_BUS		114
> +#define CLK_DOUT_HSI1_PCIE		115
> +#define CLK_DOUT_HSI2_BUS		116
> +#define CLK_DOUT_HSI2_MMC_CARD		117
> +#define CLK_DOUT_HSI2_PCIE		118
> +#define CLK_DOUT_HSI2_UFS_EMBD		119
> +#define CLK_DOUT_IPP_BUS		107

You're restarting at 107 here, but the numbers should continue at 120...

> +#define CLK_DOUT_ITP_BUS		108
> +#define CLK_DOUT_MCSC_ITSC		109
> +#define CLK_DOUT_MCSC_MCSC		110
> +#define CLK_DOUT_MFC_MFC		111
> +#define CLK_DOUT_MIF_BUSP		112
> +#define CLK_DOUT_MISC_BUS		113
> +#define CLK_DOUT_MISC_SSS		114
> +#define CLK_DOUT_PDP_BUS		115
> +#define CLK_DOUT_PDP_VRA		116
> +#define CLK_DOUT_PERIC0_BUS		117
> +#define CLK_DOUT_PERIC0_IP		118
> +#define CLK_DOUT_PERIC1_BUS		119
> +#define CLK_DOUT_PERIC1_IP		120
> +#define CLK_DOUT_TNR_BUS		121
> +#define CLK_DOUT_TPU_BUS		122
> +#define CLK_DOUT_TPU_TPU		123
> +#define CLK_DOUT_TPU_TPUCTL		124
> +#define CLK_DOUT_TPU_UART		125
> +#define CLK_DOUT_CMU_BOOST		126
> +#define CLK_DOUT_CMU_CMUREF		127
> +#define CLK_DOUT_SHARED0_DIV2		128
> +#define CLK_DOUT_SHARED0_DIV3		129
> +#define CLK_DOUT_SHARED0_DIV4		130
> +#define CLK_DOUT_SHARED0_DIV5		131
> +#define CLK_DOUT_SHARED1_DIV2		132
> +#define CLK_DOUT_SHARED1_DIV3		133
> +#define CLK_DOUT_SHARED1_DIV4		134
> +#define CLK_DOUT_SHARED2_DIV2		135
> +#define CLK_DOUT_SHARED3_DIV2		136
> +
> +/* CMU_TOP Gates */
> +#define CLK_GOUT_BUS0_BOOST		137
> +#define CLK_GOUT_BUS1_BOOST		138
> +#define CLK_GOUT_BUS2_BOOST		139
> +#define CLK_GOUT_CORE_BOOST		140
> +#define CLK_GOUT_CPUCL0_BOOST		141
> +#define CLK_GOUT_CPUCL1_BOOST		142
> +#define CLK_GOUT_CPUCL2_BOOST		143
> +#define CLK_GOUT_MIF_BOOST		144
> +#define CLK_GOUT_MIF_SWITCH		145
> +#define CLK_GOUT_BO_BUS			146
> +#define CLK_GOUT_BUS0_BUS		147
> +#define CLK_GOUT_BUS1_BUS		148
> +#define CLK_GOUT_BUS2_BUS		149
> +#define CLK_GOUT_CIS_CLK0		150
> +#define CLK_GOUT_CIS_CLK1		151
> +#define CLK_GOUT_CIS_CLK2		152
> +#define CLK_GOUT_CIS_CLK3		153
> +#define CLK_GOUT_CIS_CLK4		154
> +#define CLK_GOUT_CIS_CLK5		155
> +#define CLK_GOUT_CIS_CLK6		156
> +#define CLK_GOUT_CIS_CLK7		157
> +#define CLK_GOUT_CMU_BOOST		158
> +#define CLK_GOUT_CORE_BUS		159
> +#define CLK_GOUT_CPUCL0_DBG		160
> +#define CLK_GOUT_CPUCL0_SWITCH		161
> +#define CLK_GOUT_CPUCL1_SWITCH		162
> +#define CLK_GOUT_CPUCL2_SWITCH		163
> +#define CLK_GOUT_CSIS_BUS		164
> +#define CLK_GOUT_DISP_BUS		165
> +#define CLK_GOUT_DNS_BUS		166
> +#define CLK_GOUT_DPU_BUS		167
> +#define CLK_GOUT_EH_BUS			168
> +#define CLK_GOUT_G2D_G2D		169
> +#define CLK_GOUT_G2D_MSCL		170
> +#define CLK_GOUT_G3AA_G3AA		171
> +#define CLK_GOUT_G3D_BUSD		172
> +#define CLK_GOUT_G3D_GLB		173
> +#define CLK_GOUT_G3D_SWITCH		174
> +#define CLK_GOUT_GDC_GDC0		175
> +#define CLK_GOUT_GDC_GDC1		176
> +#define CLK_GOUT_GDC_SCSC		177
> +#define CLK_GOUT_CMU_HPM		178
> +#define CLK_GOUT_HSI0_BUS		179
> +#define CLK_GOUT_HSI0_DPGTC		180
> +#define CLK_GOUT_HSI0_USB31DRD		181
> +#define CLK_GOUT_HSI0_USBDPDGB		182
> +#define CLK_GOUT_HSI1_BUS		183
> +#define CLK_GOUT_HSI1_PCIE		184
> +#define CLK_GOUT_HSI2_BUS		185
> +#define CLK_GOUT_HSI2_MMC_CARD		186
> +#define CLK_GOUT_HSI2_PCIE		187
> +#define CLK_GOUT_HSI2_UFS_EMBD		188
> +#define CLK_GOUT_IPP_BUS		189
> +#define CLK_GOUT_ITP_BUS		190
> +#define CLK_GOUT_MCSC_ITSC		191
> +#define CLK_GOUT_MCSC_MCSC		192
> +#define CLK_GOUT_MFC_MFC		193
> +#define CLK_GOUT_MIF_BUSP		194
> +#define CLK_GOUT_MISC_BUS		195
> +#define CLK_GOUT_MISC_SSS		196
> +#define CLK_GOUT_PDP_BUS		197
> +#define CLK_GOUT_PDP_VRA		298
> +#define CLK_GOUT_G3AA			299
> +#define CLK_GOUT_PERIC0_BUS		200
> +#define CLK_GOUT_PERIC0_IP		201
> +#define CLK_GOUT_PERIC1_BUS		202
> +#define CLK_GOUT_PERIC1_IP		203
> +#define CLK_GOUT_TNR_BUS		204
> +#define CLK_GOUT_TOP_CMUREF		205
> +#define CLK_GOUT_TPU_BUS		206
> +#define CLK_GOUT_TPU_TPU		207
> +#define CLK_GOUT_TPU_TPUCTL		208
> +#define CLK_GOUT_TPU_UART		209

... up to here. I also checked the other units, they seem to be OK.

Cheers,
Andre'



From festevam at gmail.com  Wed Dec  6 04:33:43 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 09:33:43 -0300
Subject: [PATCH] ARM: dts: imx: Use 
Message-ID: <20231206123343.2254869-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per mtd-physmap.yaml, 'nor at 0,0' is not a valid node pattern.

Change it to 'flash at 0,0' to fix the following dt-schema warning:

imx1-ads.dtb: nor at 0,0: $nodename:0: 'nor at 0,0' does not match '^(flash|.*sram|nand)(@.*)?$'
	from schema $id: http://devicetree.org/schemas/mtd/mtd-physmap.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx1-ads.dts                  | 2 +-
 arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts              | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi    | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx1-ads.dts b/arch/arm/boot/dts/nxp/imx/imx1-ads.dts
index 5833fb6f15d8..2c817c4a4c68 100644
--- a/arch/arm/boot/dts/nxp/imx/imx1-ads.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx1-ads.dts
@@ -65,7 +65,7 @@ &weim {
 	pinctrl-0 = <&pinctrl_weim>;
 	status = "okay";
 
-	nor: nor at 0,0 {
+	nor: flash at 0,0 {
 		compatible = "cfi-flash";
 		reg = <0 0x00000000 0x02000000>;
 		bank-width = <4>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts b/arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts
index 1f11e9542a72..e66eef87a7a4 100644
--- a/arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts
@@ -45,7 +45,7 @@ &weim {
 	pinctrl-0 = <&pinctrl_weim>;
 	status = "okay";
 
-	nor: nor at 0,0 {
+	nor: flash at 0,0 {
 		compatible = "cfi-flash";
 		reg = <0 0x00000000 0x02000000>;
 		bank-width = <2>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi
index 4b83e2918b55..c7e923584878 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi
@@ -90,7 +90,7 @@ &usbotg {
 &weim {
 	status = "okay";
 
-	nor: nor at 0,0 {
+	nor: flash at 0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "cfi-flash";
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
index 7b2ea4cdae58..8d428c844666 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
@@ -314,7 +314,7 @@ &usbotg {
 &weim {
 	status = "okay";
 
-	nor: nor at 0,0 {
+	nor: flash at 0,0 {
 		compatible = "cfi-flash";
 		reg = <0 0x00000000 0x02000000>;
 		bank-width = <2>;
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 04:36:05 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 09:36:05 -0300
Subject: [PATCH v2] ARM: dts: imx: Use flash@0,0 pattern
Message-ID: <20231206123605.2255158-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per mtd-physmap.yaml, 'nor at 0,0' is not a valid node pattern.

Change it to 'flash at 0,0' to fix the following dt-schema warning:

imx1-ads.dtb: nor at 0,0: $nodename:0: 'nor at 0,0' does not match '^(flash|.*sram|nand)(@.*)?$'
	from schema $id: http://devicetree.org/schemas/mtd/mtd-physmap.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
Changes since v1:
- Fix Subject.

 arch/arm/boot/dts/nxp/imx/imx1-ads.dts                  | 2 +-
 arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts              | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi    | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx1-ads.dts b/arch/arm/boot/dts/nxp/imx/imx1-ads.dts
index 5833fb6f15d8..2c817c4a4c68 100644
--- a/arch/arm/boot/dts/nxp/imx/imx1-ads.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx1-ads.dts
@@ -65,7 +65,7 @@ &weim {
 	pinctrl-0 = <&pinctrl_weim>;
 	status = "okay";
 
-	nor: nor at 0,0 {
+	nor: flash at 0,0 {
 		compatible = "cfi-flash";
 		reg = <0 0x00000000 0x02000000>;
 		bank-width = <4>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts b/arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts
index 1f11e9542a72..e66eef87a7a4 100644
--- a/arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts
@@ -45,7 +45,7 @@ &weim {
 	pinctrl-0 = <&pinctrl_weim>;
 	status = "okay";
 
-	nor: nor at 0,0 {
+	nor: flash at 0,0 {
 		compatible = "cfi-flash";
 		reg = <0 0x00000000 0x02000000>;
 		bank-width = <2>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi
index 4b83e2918b55..c7e923584878 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi
@@ -90,7 +90,7 @@ &usbotg {
 &weim {
 	status = "okay";
 
-	nor: nor at 0,0 {
+	nor: flash at 0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "cfi-flash";
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
index 7b2ea4cdae58..8d428c844666 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
@@ -314,7 +314,7 @@ &usbotg {
 &weim {
 	status = "okay";
 
-	nor: nor at 0,0 {
+	nor: flash at 0,0 {
 		compatible = "cfi-flash";
 		reg = <0 0x00000000 0x02000000>;
 		bank-width = <2>;
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 04:39:20 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 09:39:20 -0300
Subject: [PATCH 1/2] ARM: dts: imx27: Fix sram node
Message-ID: <20231206123921.2255532-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per sram.yaml, address-cells, size-cells and ranges are mandatory.

Pass them to fix the following dt-schema warnings:

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx27.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx27.dtsi b/arch/arm/boot/dts/nxp/imx/imx27.dtsi
index faba12ee7465..cac4b3d68986 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27.dtsi
@@ -588,6 +588,9 @@ weim: weim at d8002000 {
 		iram: sram at ffff4c00 {
 			compatible = "mmio-sram";
 			reg = <0xffff4c00 0xb400>;
+			ranges = <0 0xffff4c00 0xb400>;
+			#address-cells = <1>;
+			#size-cells = <1>;
 		};
 	};
 };
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 04:39:21 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 09:39:21 -0300
Subject: [PATCH 2/2] ARM: dts: imx1: Fix sram node
In-Reply-To: <20231206123921.2255532-1-festevam@gmail.com>
References: <20231206123921.2255532-1-festevam@gmail.com>
Message-ID: <20231206123921.2255532-2-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per sram.yaml, address-cells, size-cells and ranges are mandatory.

The node name should be sram.

Change the node name and pass the required properties to fix the
following dt-schema warnings:

imx1-apf9328.dtb: esram at 300000: $nodename:0: 'esram at 300000' does not match '^sram(@.*)?'
	from schema $id: http://devicetree.org/schemas/sram/sram.yaml#
imx1-apf9328.dtb: esram at 300000: '#address-cells' is a required property
	from schema $id: http://devicetree.org/schemas/sram/sram.yaml#
imx1-apf9328.dtb: esram at 300000: '#size-cells' is a required property
	from schema $id: http://devicetree.org/schemas/sram/sram.yaml#
imx1-apf9328.dtb: esram at 300000: 'ranges' is a required property
	from schema $id: http://devicetree.org/schemas/sram/sram.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx1.dtsi | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx1.dtsi b/arch/arm/boot/dts/nxp/imx/imx1.dtsi
index e312f1e74e2f..4aeb74479f44 100644
--- a/arch/arm/boot/dts/nxp/imx/imx1.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx1.dtsi
@@ -268,9 +268,12 @@ weim: weim at 220000 {
 			status = "disabled";
 		};
 
-		esram: esram at 300000 {
+		esram: sram at 300000 {
 			compatible = "mmio-sram";
 			reg = <0x00300000 0x20000>;
+			ranges = <0 0x00300000 0x20000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
 		};
 	};
 };
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 04:45:29 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 09:45:29 -0300
Subject: [PATCH] ARM: dts: imx27-phytec-phycore-som: Use the mux- prefix
Message-ID: <20231206124529.2256756-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

According to Documentation/devicetree/bindings/sound/imx-audmux.yaml,
there must be a "mux-" prefix in the audmux port nodes.

Add the "mux-" prefix to avoid the following dt-schema warning:

imx27-phytec-phycore-rdk.dtb: audmux at 10016000: 'pins4', 'ssi0' do not match any of the regexes: '^mux-[0-9a-z]*$', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/sound/imx-audmux.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
index 8d428c844666..dc316358a7d4 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
@@ -49,12 +49,12 @@ &audmux {
 	status = "okay";
 
 	/* SSI0 <=> PINS_4 (MC13783 Audio) */
-	ssi0 {
+	mux-ssi0 {
 		fsl,audmux-port = <0>;
 		fsl,port-config = <0xcb205000>;
 	};
 
-	pins4 {
+	mux-pins4 {
 		fsl,audmux-port = <2>;
 		fsl,port-config = <0x00001000>;
 	};
-- 
2.34.1



From daniel at makrotopia.org  Wed Dec  6 04:45:40 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 12:45:40 +0000
Subject: [PATCH v3 2/4] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <3e72bff6-9f4d-4cd4-845e-b065f1233ec6@collabora.com>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
 <def05aac79ddff872d3e56698b736cb445f14116.1701823757.git.daniel@makrotopia.org>
 <3e72bff6-9f4d-4cd4-845e-b065f1233ec6@collabora.com>
Message-ID: <ZXBs9GOOOlZrMuSW@makrotopia.org>

On Wed, Dec 06, 2023 at 11:59:54AM +0100, AngeloGioacchino Del Regno wrote:
> Il 06/12/23 01:57, Daniel Golle ha scritto:
> > Add various clock controllers found in the MT7988 SoC to existing
> > bindings (if applicable) and add files for the new ethwarp, mcusys
> > and xfi-pll clock controllers not previously present in any SoC.
> > 
> > Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> > ---
> > v3:
> >   * move clock bindings to clock folder
> >   * drop ti,syscon-reset from bindings and example
> >   * merge mcusys with topckgen bindings
> > 
> > v2:
> >   * dropped unused labels
> >   * add 'type: object' declaration for reset-controller found in new
> >     ethwarp controller and represented as ti,syscon-reset
> >   * rebase on top of
> >     "dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema"
> > 
> >   .../arm/mediatek/mediatek,infracfg.yaml       |  1 +
> >   .../bindings/clock/mediatek,apmixedsys.yaml   |  1 +
> >   .../bindings/clock/mediatek,ethsys.yaml       |  1 +
> >   .../clock/mediatek,mt7988-ethwarp.yaml        | 49 +++++++++++++++++++
> >   .../clock/mediatek,mt7988-xfi-pll.yaml        | 48 ++++++++++++++++++
> >   .../bindings/clock/mediatek,topckgen.yaml     |  2 +
> >   .../bindings/net/pcs/mediatek,sgmiisys.yaml   | 13 +++--
> >   7 files changed, 112 insertions(+), 3 deletions(-)
> >   create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
> >   create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
> > index ea98043c6ba3d..230b5188a88db 100644
> > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
> > @@ -30,6 +30,7 @@ properties:
> >                 - mediatek,mt7629-infracfg
> >                 - mediatek,mt7981-infracfg
> >                 - mediatek,mt7986-infracfg
> > +              - mediatek,mt7988-infracfg
> >                 - mediatek,mt8135-infracfg
> >                 - mediatek,mt8167-infracfg
> >                 - mediatek,mt8173-infracfg
> > diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
> > index 372c1d744bc27..685535846cbb7 100644
> > --- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
> > +++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
> > @@ -22,6 +22,7 @@ properties:
> >             - mediatek,mt7622-apmixedsys
> >             - mediatek,mt7981-apmixedsys
> >             - mediatek,mt7986-apmixedsys
> > +          - mediatek,mt7988-apmixedsys
> >             - mediatek,mt8135-apmixedsys
> >             - mediatek,mt8173-apmixedsys
> >             - mediatek,mt8516-apmixedsys
> > diff --git a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
> > index 94d42c8647777..f9cddacc2eae1 100644
> > --- a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
> > +++ b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
> > @@ -22,6 +22,7 @@ properties:
> >                 - mediatek,mt7629-ethsys
> >                 - mediatek,mt7981-ethsys
> >                 - mediatek,mt7986-ethsys
> > +              - mediatek,mt7988-ethsys
> >             - const: syscon
> >         - items:
> >             - const: mediatek,mt7623-ethsys
> > diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
> > new file mode 100644
> > index 0000000000000..9b919a155eb13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
> > @@ -0,0 +1,49 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-ethwarp.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MediaTek MT7988 ethwarp Controller
> > +
> > +maintainers:
> > +  - Daniel Golle <daniel at makrotopia.org>
> > +
> > +description:
> > +  The Mediatek MT7988 ethwarp controller provides clocks and resets for the
> > +  Ethernet related subsystems found the MT7988 SoC.
> > +  The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - const: mediatek,mt7988-ethwarp
> > +      - const: syscon
> > +      - const: simple-mfd
> 
> No, this is not a mfd, I say.
> 
> Prove me wrong! :-)

https://github.com/dangowrt/linux/blob/mt7988-for-next/arch/arm64/boot/dts/mediatek/mt7988a.dtsi#L564

The 'simple-mfd' compatible is required to have the Linux
kernel probe drivers for sub-nodes -- several drivers will act on
the different aspects of the circuit exposed at this memory range.
>From what I understand, this is the definition of a MFD.

> 
> ..snip..
> 
> > diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
> > index 66a95191bd776..68632cda334bd 100644
> > --- a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
> > +++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
> > @@ -15,15 +15,22 @@ description:
> >   properties:
> >     compatible:
> > -    items:
> > -      - enum:
> > +    oneOf:
> > +      - items:
> > +        - enum:
> >             - mediatek,mt7622-sgmiisys
> >             - mediatek,mt7629-sgmiisys
> >             - mediatek,mt7981-sgmiisys_0
> >             - mediatek,mt7981-sgmiisys_1
> >             - mediatek,mt7986-sgmiisys_0
> >             - mediatek,mt7986-sgmiisys_1
> > -      - const: syscon
> > +        - const: syscon
> > +      - items:
> > +        - enum:
> > +          - mediatek,mt7988-sgmiisys_0
> > +          - mediatek,mt7988-sgmiisys_1
> > +        - const: syscon
> > +        - const: simple-mfd
> 
> Same.
> 
> Cheers,
> Angelo


From peter.griffin at linaro.org  Wed Dec  6 04:47:14 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Wed, 6 Dec 2023 12:47:14 +0000
Subject: [PATCH v5 14/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <71972f4f-b5ac-484a-8a09-0b74bd7c623b@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-15-peter.griffin@linaro.org> <CGME20231202004026epcas5p4d3947d7bb99e54f70ca37272cfdc5e55@epcas5p4.samsung.com>
 <CAPLW+4kBOWFPx3Hr-=UoLWvRxCorzBY9RCOiBhfkKcU0LAa21Q@mail.gmail.com>
 <000001da24c0$0b83aab0$228b0010$@samsung.com> <71972f4f-b5ac-484a-8a09-0b74bd7c623b@linaro.org>
Message-ID: <CADrjBPqTdmEqD_4fcPqz0wBYqgPG8nPr2reXp5=s=bRRtLKXsg@mail.gmail.com>

Hi Krzysztof / Sam,

On Wed, 6 Dec 2023 at 11:38, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 02/12/2023 02:36, Alim Akhtar wrote:
> >
> >>
> >> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org>
> >> wrote:
> >>>
> >>> Add support for the pin-controller found on the gs101 SoC used in
> >>> Pixel 6 phones.
> >>>
> >>> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> >>> ---
> >>>  .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 159 ++++++++++++++++++
> >>>  drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
> >>>  drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
> >>>  drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
> >>>  drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
> >>>  5 files changed, 198 insertions(+)
> >>>
> >>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> >>> b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> >>> index cb965cf93705..e1a0668ecb16 100644
> >>> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> >>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> >>> @@ -796,3 +796,162 @@ const struct samsung_pinctrl_of_match_data
> >> fsd_of_data __initconst = {
> >>>         .ctrl           = fsd_pin_ctrl,
> >>>         .num_ctrl       = ARRAY_SIZE(fsd_pin_ctrl),
> >>>  };
> >>> +
> >>> +/*
> >>> + * bank type for non-alive type
> >>> + * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit
> >>> +field: 4)
> >>> + * (CONPDN bit field: 2, PUDPDN bit field: 4)  */ static struct
> >>> +samsung_pin_bank_type gs101_bank_type_off  = {
> >>> +       .fld_width = { 4, 1, 4, 4, 2, 4, },
> >>> +       .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, }, };
> >>
> >> This is just the same as exynos850_bank_type_off (100% duplication).
> >> Here is what I suggest. Now that it's obvious there is some common platform
> >> for moder Exynos SoCs, and it's probably Exynos9, I'd suggest next course of
> >> action (if maintainers agree):
> >>   1. Remove this one
> >>   2. Rename exynos850_bank_type_off to exynos9_bank_type_off
> >>   3. Use it for both gs101 and exynos850
> >>
> >> Does it make sense?
> >>
> > My opinion is to reuse exynos850 for gs101 (wherever applicable), same philosophy was historically followed in this file.
> > That way (using exynos850 for gs101) things will be simple.
> > Adding exynos9_* is not adding any benefit, rather it create confusion.
>
> I don't see much value in renaming exynos850 bank type to exynos9
> considering:
> 1. We don't really know the bank types for all of Exynos9xxx SoCs,
> 2. Exynos7885 also uses Exynos850 bank types. Exynos7885 was much
> earlier than Exynos9xxx family.

Thanks Alim and Krzysztof for your input.

Exynos7885 (Exynos 8 family) using Exynos850 bank types looks like a
mistake to me. I found some downstream code for 7885, and it doesn't
look like selecting a filter was supported downstream [1] [2]. As Sam
confirmed this hardware is present on e850 downstream, so 7885 and
e850 have different hardware at least for these banks.

As the EXYNOS850_PIN_BANK_EINTW macro is being used by Exynos850,
exynosautov9 and exynos7885 using a generic macro with gs101 doesn't
look possible (I have no way to find out these filter register
offsets, or if those platforms actually have these registers).

Therefore I propose:
1. For bank types that match exactly use exynos850 versions
2. For bank types which have fltcon_offset we add a new macro
EXYNOS9_PIN_BANK_EINTW like it exists in this series or
GS101_PIN_BANK_EINTW if people prefer that

That still leaves us in the rather unfortunate position that if
Exynos850 wants selectable filter support then it wouldn't be using
the EXYNOS850_PIN_BANK_EINTW macro. But I suggest we cross that bridge
if/when Sam decides to support selectable filters on e850. We could do
some sort of macro renaming, but what we rename it to though I have no
idea EXYNOS7885_blah or EXYNOSAUTOV9_blah.

@Chanho do you know if ExynosAutov9 supports selectable filters on alive banks?

regards,

Peter

[1] https://github.com/samsungexynos7885/android_kernel_samsung_universal7885/blob/android-9.0/drivers/pinctrl/samsung/pinctrl-exynos.c#L1696
[2] https://github.com/samsungexynos7885/android_kernel_samsung_universal7885/blob/android-9.0/drivers/pinctrl/samsung/pinctrl-exynos.h#L108


From hverkuil-cisco at xs4all.nl  Wed Dec  6 04:57:46 2023
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Wed, 6 Dec 2023 13:57:46 +0100
Subject: [Patch v5 09/11] media: s5p-mfc: Load firmware for each run in
 MFCv12.
In-Reply-To: <20231206063045.97234-10-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
 <CGME20231206063134epcas5p2b3b9ca0351cd9c1cb169d7a4a3a30b80@epcas5p2.samsung.com>
 <20231206063045.97234-10-aakarsh.jain@samsung.com>
Message-ID: <2c9b85dc-ebd7-43a7-bb66-d96ba9a28082@xs4all.nl>

On 06/12/2023 07:30, Aakarsh Jain wrote:
> In MFCv12, some section of firmware gets updated at each MFC run.
> Hence we need to reload original firmware for each run at the start.
> 
> Cc: linux-fsd at tesla.com
> Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
> Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> index b49159142c53..24dd40ae71ec 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> @@ -51,8 +51,10 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
>  	 * into kernel. */
>  	mfc_debug_enter();
>  
> -	if (dev->fw_get_done)
> -		return 0;
> +	/* Load MFC v12 firmware for each run when MFC runs sequentially */

You had a much longer explanation in your reply to my original question.

I think it is better if that longer explanation is added here.

Things that are weird and unexpected need good comments, explaining why
it is done, and also what you know and do not know about this.

E.g. you know through trial and error that it is needed (or perhaps you
got information on this some the fw team), but there might be open questions
that are not yet answered.

This is all information that you can't get from the source code since it has
to do with the black box firmware. So putting all you know in a comment is
the best way of communicating this to future readers of the source code.

Regards,

	Hans

> +	if (!IS_MFCV12(dev))
> +		if (dev->fw_get_done)
> +			return 0;
>  
>  	for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
>  		if (!dev->variant->fw_name[i])



From hverkuil-cisco at xs4all.nl  Wed Dec  6 04:59:21 2023
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Wed, 6 Dec 2023 13:59:21 +0100
Subject: [Patch v5 00/11] Add MFC V12 support
In-Reply-To: <20231206063045.97234-1-aakarsh.jain@samsung.com>
References: <CGME20231206063105epcas5p3034f89af2be6922ab04771de099a124a@epcas5p3.samsung.com>
 <20231206063045.97234-1-aakarsh.jain@samsung.com>
Message-ID: <d00fa740-bcf8-47af-b70a-cabbb7237d99@xs4all.nl>

On 06/12/2023 07:30, Aakarsh Jain wrote:
> This patch series adds MFC v12 support. MFC v12 is used in Tesla FSD SoC.
> 
> This adds support for following:
> 
> -Add support for YV12 and I420 format (3-plane)
> -Add support for Rate Control, UHD and DMABUF for encoder
> -Add support for DPB buffers allocation based on MFC requirement

I'm getting one smatch warning:

drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c:2453 s5p_mfc_queue_setup() error: we previously assumed 'ctx->src_fmt' could be null (see line 2441)

And a few kerneldoc warnings:

drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h:729: warning: Function parameter or member 'chroma_size_1' not described in 's5p_mfc_ctx'
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h:729: warning: Function parameter or member 'is_10bit' not described in 's5p_mfc_ctx'
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h:729: warning: Function parameter or member 'is_422' not described in 's5p_mfc_ctx'
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h:729: warning: Function parameter or member 'stride' not described in 's5p_mfc_ctx'

Something for v6.

Regards,

	Hans

> 
> Changes since v4:
> -Addressed review comments by Krzysztof Kozlowski.
> As per discussion included iommus property in dt-schema.
> -Addressed review comments by Hans Verkuil.
> Fixed checkpatch warnings with --strict flag enabled.
> Upstreamed s5p-mfc-v12.fw to linux-firmware.
> Added comment in the patch 9 regarding loading mfc firmware v12 
> sequentially.
> -Addressed review comments by Nicolas Dufresne
> Made use of v4l2-common library to get number of planes needed for
> particular format in patch 4.
> v4 link:https://patchwork.kernel.org/project/linux-media/patch/20231025102216.50480-2-aakarsh.jain at samsung.com/
> 
> Changes since v3:
> -Removed vp9 codec support for now and just keeping MFC v12 base
> patches with necessary hardware controls, decoder, encoder and
> structural changes. Also covers luma dbp, chroma dpb and mv sizes
> for each codec as per the UM for MFCv12, along with appropriate
> alignment.
> v3 link: https://patchwork.kernel.org/project/linux-media/cover/20221011122516.32135-1-aakarsh.jain at samsung.com/
> 
> Changes since v2:
> -Addressed review comments by Rob Herring.
> This was regarding the errors found by Rob bot in yaml file. File
> 'samsung,s5p-mfc.yaml' is already converted into json schema and is
> merged.
> 
> -Addressed review comments by Krzysztof Kozlowski.
> This was regarding depricated properties mentioned in s5p-mfc.txt file.
> Review comment was addressed and 'samsung,s5p-mfc.yaml' is already
> merged now.
> 
> -Addressed review comments by Andi Shyti.
> This was regarding addition of 'MFC_V10PLUS_BITS' macro in
> 's5p_mfc_common.h file.
> v2 link: https://patchwork.kernel.org/project/linux-media/cover/20220907064715.55778-1-smitha.t at samsung.com/
> 
> Changes since v1:
> -Addressed review comments by Krzysztof Kozlowski.
> Separated bug fixes patches, resent again with fix tag
> and those are merged now.
> -Added SoC based compatible string.
> 
> -Addressed review comments by Andrzej Hajda
> Assigned width64 and height32 variable with ALIGN(ctx->img_..)
> used in the code in 's5p_mfc_opr_v6.c' file.
> v1 link: https://patchwork.kernel.org/project/linux-media/patch/20220517125548.14746-2-smitha.t at samsung.com/
> 
> Aakarsh Jain (11):
>   dt-bindings: media: s5p-mfc: Add mfcv12 variant
>   media: s5p-mfc: Rename IS_MFCV10 macro
>   media: s5p-mfc: Add initial support for MFCv12
>   media: s5p-mfc: Add YV12 and I420 multiplanar format support
>   media: s5p-mfc: Add support for rate controls in MFCv12
>   media: s5p-mfc: Add support for UHD encoding.
>   media: s5p-mfc: Add support for DMABUF for encoder
>   media: s5p-mfc: Set context for valid case before calling try_run
>   media: s5p-mfc: Load firmware for each run in MFCv12.
>   media: s5p-mfc: DPB Count Independent of VIDIOC_REQBUF
>   arm64: dts: fsd: Add MFC related DT enteries
> 
>  .../bindings/media/samsung,s5p-mfc.yaml       |  18 ++
>  arch/arm64/boot/dts/tesla/fsd.dtsi            |  21 ++
>  .../platform/samsung/s5p-mfc/regs-mfc-v12.h   |  52 +++
>  .../platform/samsung/s5p-mfc/regs-mfc-v7.h    |   1 +
>  .../platform/samsung/s5p-mfc/regs-mfc-v8.h    |   3 +
>  .../media/platform/samsung/s5p-mfc/s5p_mfc.c  |  36 ++-
>  .../platform/samsung/s5p-mfc/s5p_mfc_common.h |  29 +-
>  .../platform/samsung/s5p-mfc/s5p_mfc_ctrl.c   |  10 +-
>  .../platform/samsung/s5p-mfc/s5p_mfc_dec.c    |  60 +++-
>  .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    | 149 ++++++---
>  .../platform/samsung/s5p-mfc/s5p_mfc_opr.h    |  14 +-
>  .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c |  12 +-
>  .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 300 ++++++++++++++----
>  .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h |   7 +-
>  14 files changed, 563 insertions(+), 149 deletions(-)
>  create mode 100644 drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
> 



From jgg at nvidia.com  Wed Dec  6 04:59:19 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 6 Dec 2023 08:59:19 -0400
Subject: [PATCH rdma-next 1/2] arm64/io: add memcpy_toio_64
In-Reply-To: <ZXBWXodu2rxQ7Szz@arm.com>
References: <20231124122352.GB436702@nvidia.com>
 <ZWSOwT2OyMXD1lmo@arm.com>
 <20231127134505.GI436702@nvidia.com>
 <ZW4NAzI_jvwoq8dL@arm.com>
 <20231204182330.GK1493156@nvidia.com>
 <ZW9cF0ALVwgvcQMy@arm.com>
 <20231205175127.GJ2692119@nvidia.com>
 <ZW97VdHYH3HYVyd5@arm.com>
 <20231205195130.GM2692119@nvidia.com>
 <ZXBWXodu2rxQ7Szz@arm.com>
Message-ID: <20231206125919.GP2692119@nvidia.com>

On Wed, Dec 06, 2023 at 11:09:18AM +0000, Catalin Marinas wrote:
> On Tue, Dec 05, 2023 at 03:51:30PM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 05, 2023 at 07:34:45PM +0000, Catalin Marinas wrote:
> > > > 2) You want to #define __iowrite512_copy() to memcpy_toio() on ARM and
> > > >    implement some quad STP optimization for this case?
> > > 
> > > We can have the generic __iowrite512_copy() do memcpy_toio() and have
> > > the arm64 implement an optimised version.
> > > 
> > > What I'm not entirely sure of is the DGH (whatever the io_* barrier name
> > > is). I'd put it in the same __iowrite512_copy() function and remove it
> > > from the driver code. Otherwise when ST64B is added, we have an
> > > unnecessary DGH in the driver. If this does not match the other
> > > __iowrite*_copy() semantics, we can come up with another name. But start
> > > with this for now and document the function.
> > 
> > I think the iowrite is only used for WC and the DGH is functionally
> > harmless for non-WC, so it makes sense.
> > 
> > In this case we should just remove the DGH macro from the generic
> > architecture code and tell people to use iowrite - since we now
> > understand that callers basically have to in order to use DGH on new
> > ARM CPUs.
> 
> That works for me but what would the semantics be for __iowrite64_copy()
> for example? Is there a DGH at the end of the whole write or after each
> iteration?

End of the iowrite_copy function call. The purpose of DGH is to reduce
latency through write combining buffers by providing a hint to the HW
to close them. __iowrite64_copy can be reasonably thought of as trying
to push the argument into a single TLP.

> I'd go with the former since e.g. hns3_tx_push_bd() does
> that (and doesn't seem to be a 64 byte copy).

sizeof(struct hns3_desc) == 32, HNS3_MAX_PUSH_BD_NUM == 2, so it is 64
bytes.

Indeed, I already know this HW and it functions similar to mlx5. In
userspace it uses the ST4 instruction, in fact HNS was the team that
did that change citing measured improvements on their SOC. Changing
this to be the STP block will likely be an improvement.

Jason


From heiko at sntech.de  Wed Dec  6 05:06:59 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Wed, 06 Dec 2023 14:06:59 +0100
Subject: [PATCH v4 086/115] pwm: rockchip: Make use of devm_pwmchip_alloc()
 function
In-Reply-To: <6ff62a16862768b6817819b95e2924e41e05274f.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
 <6ff62a16862768b6817819b95e2924e41e05274f.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <2584330.irdbgypaU6@diego>

Am Mittwoch, 6. Dezember 2023, 12:44:40 CET schrieb Uwe Kleine-K?nig:
> This prepares the pwm-rockchip driver to further changes of the pwm core
> outlined in the commit introducing devm_pwmchip_alloc(). There is no
> intended semantical change and the driver should behave as before.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

I looked the important patches up on lore (adding devm_pwmchip_alloc
for example) and the change looks correct, so

Reviewed-by: Heiko Stuebner <heiko at sntech.de>




From ryan.roberts at arm.com  Wed Dec  6 05:18:29 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 6 Dec 2023 13:18:29 +0000
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <004ed23d-5571-4474-b7fe-7bc08817c165@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
 <004ed23d-5571-4474-b7fe-7bc08817c165@redhat.com>
Message-ID: <ca3a2b97-f08e-452a-91dc-1a53dece0aa6@arm.com>

On 05/12/2023 16:57, David Hildenbrand wrote:
> On 04.12.23 11:20, Ryan Roberts wrote:
>> In preparation for adding support for anonymous multi-size THP,
>> introduce new sysfs structure that will be used to control the new
>> behaviours. A new directory is added under transparent_hugepage for each
>> supported THP size, and contains an `enabled` file, which can be set to
>> "inherit" (to inherit the global setting), "always", "madvise" or
>> "never". For now, the kernel still only supports PMD-sized anonymous
>> THP, so only 1 directory is populated.
>>
>> The first half of the change converts transhuge_vma_suitable() and
>> hugepage_vma_check() so that they take a bitfield of orders for which
>> the user wants to determine support, and the functions filter out all
>> the orders that can't be supported, given the current sysfs
>> configuration and the VMA dimensions. If there is only 1 order set in
>> the input then the output can continue to be treated like a boolean;
>> this is the case for most call sites. The resulting functions are
>> renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
>> respectively.
>>
>> The second half of the change implements the new sysfs interface. It has
>> been done so that each supported THP size has a `struct thpsize`, which
>> describes the relevant metadata and is itself a kobject. This is pretty
>> minimal for now, but should make it easy to add new per-thpsize files to
>> the interface if needed in future (e.g. per-size defrag). Rather than
>> keep the `enabled` state directly in the struct thpsize, I've elected to
>> directly encode it into huge_anon_orders_[always|madvise|inherit]
>> bitfields since this reduces the amount of work required in
>> thp_vma_allowable_orders() which is called for every page fault.
>>
>> See Documentation/admin-guide/mm/transhuge.rst, as modified by this
>> commit, for details of how the new sysfs interface works.
>>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
> 
> Some comments mostly regarding thp_vma_allowable_orders and friends. In general,
> LGTM. I'll have to go over the order logic once again, I got a bit lost once we
> started mixing anon and file orders.
> 
> [...]
> 
> Doc updates all looked good to me, skimming over them.
> 
>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> index fa0350b0812a..bd0eadd3befb 100644
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
> 
> [...]
> 
>> +static inline unsigned long thp_vma_suitable_orders(struct vm_area_struct *vma,
>> +??????? unsigned long addr, unsigned long orders)
>> +{
>> +??? int order;
>> +
>> +??? /*
>> +???? * Iterate over orders, highest to lowest, removing orders that don't
>> +???? * meet alignment requirements from the set. Exit loop at first order
>> +???? * that meets requirements, since all lower orders must also meet
>> +???? * requirements.
>> +???? */
>> +
>> +??? order = first_order(orders);
> 
> nit: "highest_order" or "largest_order" would be more expressive regarding the
> actual semantics.

Yep, will call it "highest_order".

> 
>> +
>> +??? while (orders) {
>> +??????? unsigned long hpage_size = PAGE_SIZE << order;
>> +??????? unsigned long haddr = ALIGN_DOWN(addr, hpage_size);
>> +
>> +??????? if (haddr >= vma->vm_start &&
>> +??????????? haddr + hpage_size <= vma->vm_end) {
>> +??????????? if (!vma_is_anonymous(vma)) {
>> +??????????????? if (IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) -
>> +??????????????????????? vma->vm_pgoff,
>> +??????????????????????? hpage_size >> PAGE_SHIFT))
>> +??????????????????? break;
>> +??????????? } else
>> +??????????????? break;
> 
> Comment: Codying style wants you to use if () {} else {}
> 
> But I'd recommend for the conditions:
> 
> if (haddr < vma->vm_start ||
> ??? haddr + hpage_size > vma->vm_end)
> ????continue;
> /* Don't have to check pgoff for anonymous vma */
> if (!vma_is_anonymous(vma))
> ????break;
> if (IS_ALIGNED((...
> ????break;

OK I'll take this structure.

> 
> [...]
> 
> 
>> +/**
>> + * thp_vma_allowable_orders - determine hugepage orders that are allowed for vma
>> + * @vma:? the vm area to check
>> + * @vm_flags: use these vm_flags instead of vma->vm_flags
>> + * @smaps: whether answer will be used for smaps file
>> + * @in_pf: whether answer will be used by page fault handler
>> + * @enforce_sysfs: whether sysfs config should be taken into account
>> + * @orders: bitfield of all orders to consider
>> + *
>> + * Calculates the intersection of the requested hugepage orders and the allowed
>> + * hugepage orders for the provided vma. Permitted orders are encoded as a set
>> + * bit at the corresponding bit position (bit-2 corresponds to order-2, bit-3
>> + * corresponds to order-3, etc). Order-0 is never considered a hugepage order.
>> + *
>> + * Return: bitfield of orders allowed for hugepage in the vma. 0 if no hugepage
>> + * orders are allowed.
>> + */
>> +unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
>> +?????????????????????? unsigned long vm_flags, bool smaps,
>> +?????????????????????? bool in_pf, bool enforce_sysfs,
>> +?????????????????????? unsigned long orders)
>> +{
>> +??? /* Check the intersection of requested and supported orders. */
>> +??? orders &= vma_is_anonymous(vma) ?
>> +??????????? THP_ORDERS_ALL_ANON : THP_ORDERS_ALL_FILE;
>> +??? if (!orders)
>> +??????? return 0;
> 
> Comment: if this is called from some hot path, we might want to move as much as
> possible into a header, so we can avoid this function call here when e.g., THP
> are completely disabled etc.

If THP is completely disabled (compiled out) then thp_vma_allowable_orders() is
defined as a header inline that returns 0. I'm not sure there are any paths in
practice which are likely to ask for a set of orders which are never supported
(i.e. where this specific check would return 0). And the "are they run time
enabled" check is further down and fairly involved, so not sure that's ideal for
an inline.

I haven't changed the pattern from how it was previously, so I don't think it
should be any more expensive. Which parts exactly do you want to move to a header?


> 
>> +
>> ????? if (!vma->vm_mm)??????? /* vdso */
>> -??????? return false;
>> +??????? return 0;
>> ? ????? /*
>> ?????? * Explicitly disabled through madvise or prctl, or some
>> @@ -88,16 +141,16 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>> unsigned long vm_flags,
>> ?????? * */
>> ????? if ((vm_flags & VM_NOHUGEPAGE) ||
>> ????????? test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
>> -??????? return false;
>> +??????? return 0;
>> ????? /*
>> ?????? * If the hardware/firmware marked hugepage support disabled.
>> ?????? */
>> ????? if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED))
>> -??????? return false;
>> +??????? return 0;
>> ? ????? /* khugepaged doesn't collapse DAX vma, but page fault is fine. */
>> ????? if (vma_is_dax(vma))
>> -??????? return in_pf;
>> +??????? return in_pf ? orders : 0;
>> ? ????? /*
>> ?????? * khugepaged special VMA and hugetlb VMA.
>> @@ -105,17 +158,29 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>> unsigned long vm_flags,
>> ?????? * VM_MIXEDMAP set.
>> ?????? */
>> ????? if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
>> -??????? return false;
>> +??????? return 0;
>> ? ????? /*
>> -???? * Check alignment for file vma and size for both file and anon vma.
>> +???? * Check alignment for file vma and size for both file and anon vma by
>> +???? * filtering out the unsuitable orders.
>> ?????? *
>> ?????? * Skip the check for page fault. Huge fault does the check in fault
>> -???? * handlers. And this check is not suitable for huge PUD fault.
>> +???? * handlers.
>> ?????? */
>> -??? if (!in_pf &&
>> -??????? !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
>> -??????? return false;
>> +??? if (!in_pf) {
>> +??????? int order = first_order(orders);
>> +??????? unsigned long addr;
>> +
>> +??????? while (orders) {
>> +??????????? addr = vma->vm_end - (PAGE_SIZE << order);
>> +??????????? if (thp_vma_suitable_orders(vma, addr, BIT(order)))
>> +??????????????? break;
> 
> Comment: you'd want a "thp_vma_suitable_order" helper here. But maybe the
> compiler is smart enough to optimize the loop and everyything else out.

I'm happy to refactor so that thp_vma_suitable_order() is the basic primitive,
then make thp_vma_suitable_orders() a loop that calls thp_vma_suitable_order()
(that's basically how it is laid out already, just all in one function). Is that
what you are requesting?

> 
> [...]
> 
>> +
>> +static ssize_t thpsize_enabled_store(struct kobject *kobj,
>> +???????????????????? struct kobj_attribute *attr,
>> +???????????????????? const char *buf, size_t count)
>> +{
>> +??? int order = to_thpsize(kobj)->order;
>> +??? ssize_t ret = count;
>> +
>> +??? if (sysfs_streq(buf, "always")) {
>> +??????? set_bit(order, &huge_anon_orders_always);
>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>> +??? } else if (sysfs_streq(buf, "inherit")) {
>> +??????? set_bit(order, &huge_anon_orders_inherit);
>> +??????? clear_bit(order, &huge_anon_orders_always);
>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>> +??? } else if (sysfs_streq(buf, "madvise")) {
>> +??????? set_bit(order, &huge_anon_orders_madvise);
>> +??????? clear_bit(order, &huge_anon_orders_always);
>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>> +??? } else if (sysfs_streq(buf, "never")) {
>> +??????? clear_bit(order, &huge_anon_orders_always);
>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>> +??????? clear_bit(order, &huge_anon_orders_madvise);
> 
> Note: I was wondering for a second if some concurrent cames could lead to an
> inconsistent state. I think in the worst case we'll simply end up with "never"
> on races.

You mean if different threads try to write different values to this file
concurrently? Or if there is a concurrent fault that tries to read the flags
while they are being modified?

I thought about this for a long time too and wasn't sure what was best. The
existing global enabled store impl clears the bits first then sets the bit. With
this approach you can end up with multiple bits set if there is a race to set
diffierent values, and you can end up with a faulting thread seeing never if it
reads the bits after they have been cleared but before setting them.

I decided to set the new bit before clearing the old bits, which is different; A
racing fault will never see "never" but as you say, a race to set the file could
result in "never" being set.

On reflection, it's probably best to set the bit *last* like the global control
does?


> 
> [...]
> 
>> ? static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
>> ? {
>> ????? int err;
>> +??? struct thpsize *thpsize;
>> +??? unsigned long orders;
>> +??? int order;
>> +
>> +??? /*
>> +???? * Default to setting PMD-sized THP to inherit the global setting and
>> +???? * disable all other sizes. powerpc's PMD_ORDER isn't a compile-time
>> +???? * constant so we have to do this here.
>> +???? */
>> +??? huge_anon_orders_inherit = BIT(PMD_ORDER);
>> ? ????? *hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
>> ????? if (unlikely(!*hugepage_kobj)) {
>> @@ -434,8 +631,24 @@ static int __init hugepage_init_sysfs(struct kobject
>> **hugepage_kobj)
>> ????????? goto remove_hp_group;
>> ????? }
>> ? +??? orders = THP_ORDERS_ALL_ANON;
>> +??? order = first_order(orders);
>> +??? while (orders) {
>> +??????? thpsize = thpsize_create(order, *hugepage_kobj);
>> +??????? if (IS_ERR(thpsize)) {
>> +??????????? pr_err("failed to create thpsize for order %d\n", order);
>> +??????????? err = PTR_ERR(thpsize);
>> +??????????? goto remove_all;
>> +??????? }
>> +??????? list_add(&thpsize->node, &thpsize_list);
>> +??????? order = next_order(&orders, order);
>> +??? }
>> +
>> ????? return 0;
>> ? 
> 
> [...]
> 
>> ????? page = compound_head(page);
>> @@ -5116,7 +5116,8 @@ static vm_fault_t __handle_mm_fault(struct
>> vm_area_struct *vma,
>> ????????? return VM_FAULT_OOM;
>> ? retry_pud:
>> ????? if (pud_none(*vmf.pud) &&
>> -??????? hugepage_vma_check(vma, vm_flags, false, true, true)) {
>> +??????? thp_vma_allowable_orders(vma, vm_flags, false, true, true,
>> +???????????????????? BIT(PUD_ORDER))) {
>> ????????? ret = create_huge_pud(&vmf);
>> ????????? if (!(ret & VM_FAULT_FALLBACK))
>> ????????????? return ret;
>> @@ -5150,7 +5151,8 @@ static vm_fault_t __handle_mm_fault(struct
>> vm_area_struct *vma,
>> ????????? goto retry_pud;
>> ? ????? if (pmd_none(*vmf.pmd) &&
>> -??????? hugepage_vma_check(vma, vm_flags, false, true, true)) {
>> +??????? thp_vma_allowable_orders(vma, vm_flags, false, true, true,
>> +???????????????????? BIT(PMD_ORDER))) {
> 
> Comment: A helper like "thp_vma_allowable_order(vma, PMD_ORDER)" might make this
> easier to read -- and the implemenmtation will be faster.

I'm happy to do this and use it to improve readability:

#define thp_vma_allowable_order(..., order) \
	thp_vma_allowable_orders(..., BIT(order))

This wouldn't make the implementation any faster though; Are you suggesting a
completely separate impl? Even then, I don't think there is much scope to make
it faster for the case where there is only 1 order in the bitfield.

> 
>> ????????? ret = create_huge_pmd(&vmf);
>> ????????? if (!(ret & VM_FAULT_FALLBACK))
>> ????????????? return ret;
>> diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
>> index e0b368e545ed..64da127cc267 100644
>> --- a/mm/page_vma_mapped.c
>> +++ b/mm/page_vma_mapped.c
>> @@ -268,7 +268,8 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
>> ?????????????? * cleared *pmd but not decremented compound_mapcount().
>> ?????????????? */
>> ????????????? if ((pvmw->flags & PVMW_SYNC) &&
>> -??????????????? transhuge_vma_suitable(vma, pvmw->address) &&
>> +??????????????? thp_vma_suitable_orders(vma, pvmw->address,
>> +??????????????????????????? BIT(PMD_ORDER)) &&
> 
> Comment: Similarly, a helper like "thp_vma_suitable_order(vma, PMD_ORDER)" might
> make this easier to read.

Yep, will do this.

> 
>> ????????????????? (pvmw->nr_pages >= HPAGE_PMD_NR)) {
>> ????????????????? spinlock_t *ptl = pmd_lock(mm, pvmw->pmd);
>> ? 
> 



From lkp at intel.com  Wed Dec  6 05:27:16 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 6 Dec 2023 21:27:16 +0800
Subject: [PATCH v4 4/5] clk: stm32: introduce clocks for STM32MP257
 platform
In-Reply-To: <20231128164851.588315-5-gabriel.fernandez@foss.st.com>
References: <20231128164851.588315-5-gabriel.fernandez@foss.st.com>
Message-ID: <202312062107.FZNn2b0i-lkp@intel.com>

Hi,

kernel test robot noticed the following build warnings:

[auto build test WARNING on atorgue-stm32/stm32-next]
[also build test WARNING on clk/clk-next robh/for-next linus/master v6.7-rc4 next-20231206]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/gabriel-fernandez-foss-st-com/clk-stm32mp1-move-stm32mp1-clock-driver-into-stm32-directory/20231129-005157
base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
patch link:    https://lore.kernel.org/r/20231128164851.588315-5-gabriel.fernandez%40foss.st.com
patch subject: [PATCH v4 4/5] clk: stm32: introduce clocks for STM32MP257 platform
config: arm-randconfig-r132-20231201 (https://download.01.org/0day-ci/archive/20231206/202312062107.FZNn2b0i-lkp at intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231206/202312062107.FZNn2b0i-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312062107.FZNn2b0i-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/clk/stm32/clk-stm32mp25.c:1003:5: sparse: sparse: symbol 'stm32mp25_cpt_gate' was not declared. Should it be static?
>> drivers/clk/stm32/clk-stm32mp25.c:1005:29: sparse: sparse: symbol 'stm32mp25_clock_data' was not declared. Should it be static?
>> drivers/clk/stm32/clk-stm32mp25.c:1011:29: sparse: sparse: symbol 'stm32mp25_reset_data' was not declared. Should it be static?

vim +/stm32mp25_cpt_gate +1003 drivers/clk/stm32/clk-stm32mp25.c

  1002	
> 1003	u16 stm32mp25_cpt_gate[GATE_NB];
  1004	
> 1005	struct clk_stm32_clock_data stm32mp25_clock_data = {
  1006		.gate_cpt	= stm32mp25_cpt_gate,
  1007		.gates		= stm32mp25_gates,
  1008		.muxes		= stm32mp25_muxes,
  1009	};
  1010	
> 1011	struct clk_stm32_reset_data stm32mp25_reset_data = {
  1012		.reset_lines	= stm32mp25_reset_cfg,
  1013		.nr_lines	= ARRAY_SIZE(stm32mp25_reset_cfg),
  1014	};
  1015	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From sumitg at nvidia.com  Wed Dec  6 05:28:17 2023
From: sumitg at nvidia.com (Sumit Gupta)
Date: Wed, 6 Dec 2023 18:58:17 +0530
Subject: [PATCH v2 2/2] cpufreq: Wire-up arch-flavored freq info into
 cpufreq_verify_current_freq
In-Reply-To: <ZW8D5TfSwuJfdYeD@arm.com>
References: <20231127160838.1403404-1-beata.michalska@arm.com>
 <20231127160838.1403404-3-beata.michalska@arm.com> <ZWXy0h/fFfQh+Rhy@arm.com>
 <3e6077bb-907c-057f-0896-d0a5814a4229@nvidia.com> <ZW8D5TfSwuJfdYeD@arm.com>
Message-ID: <c8b4d391-681e-f4a6-2839-e5951429f043@nvidia.com>



On 05/12/23 16:35, Ionela Voinescu wrote:
> External email: Use caution opening links or attachments
> 
> 
> Hi Sumit,
> 
> On Friday 01 Dec 2023 at 18:32:10 (+0530), Sumit Gupta wrote:
>> Hi Ionela,
>>
>>>> --- a/drivers/cpufreq/cpufreq.c
>>>> +++ b/drivers/cpufreq/cpufreq.c
>>>> @@ -1756,7 +1756,8 @@ static unsigned int cpufreq_verify_current_freq(struct cpufreq_policy *policy, b
>>>>    {
>>>>         unsigned int new_freq;
>>>>
>>>> -     new_freq = cpufreq_driver->get(policy->cpu);
>>>> +     new_freq = arch_freq_get_on_cpu(policy->cpu);
>>>> +     new_freq = new_freq ?: cpufreq_driver->get(policy->cpu);
>>>
>>> Given that arch_freq_get_on_cpu() is an average frequency, it does not
>>> seem right to me to trigger the sync & update process of
>>> cpufreq_verify_current_freq() based on it.
>>>
>>> cpufreq_verify_current_freq() will at least modify the internal state of
>>> the policy and send PRE and POST notifications, if not do a full frequency
>>> update, based on this average frequency, which is likely different from
>>> the current frequency, even beyond the 1MHz threshold.
>>>
>>> While I believe it's okay to return this average frequency in
>>> cpuinfo_cur_freq, I don't think it should be used as an indication of
>>> an accurate current frequency, which is what
>>> cpufreq_verify_current_freq() expects.
>>>
>>> Sumit, can you give more details on the issue at [1] and why this change
>>> fixes it?
>>>
>>> [1] https://lore.kernel.org/lkml/6a5710f6-bfbb-5dfd-11cd-0cd02220cee7 at nvidia.com/
>>>
>>> Thank you,
>>> Ionela.
>>>
>> cpufreq_verify_current_freq() also updates 'policy->cur' in POST
>> notification if the frequency from hardware has more delta (out of sync).
>>
>> As the value from 'cpufreq_driver->get()' is not reliable due to [1],
>> calling the 'get' hook can update the 'policy->cur' with a wrong value when
>> governor starts in cpufreq_start_governor().
>> And if the frequency is never changed after the governor starts during
>> boot e.g. when performance governor is set as default, then
>> 'scaling_cur_freq' always returns wrong value.
>>
>> Instead, the arch_freq_get_on_cpu() API updates 'policy->cur' with a more
>> stable freq value.
>>
>> [1] https://lore.kernel.org/lkml/20230418113459.12860-7-sumitg at nvidia.com/
> 
> Got it, many thanks!
> 
> As the code is right now in v2, arch_freq_get_on_cpu() is called on
> show_scaling_cur_freq(), so the problem you describe would not show up.
> policy->cur would still be incorrect, but 'scaling_cur_freq' would
> return the value from arch_freq_get_on_cpu().
> 
> Would it be enough if arch_freq_get_on_cpu() gets also called from
> show_cpuinfo_cur_freq() instead of cpufreq_verify_current_freq()?
> 
> Thanks,
> Ionela.
> 

Yes.
I am not sure if making both the nodes 'scaling_cur_freq' and 
'cpuinfo_cur_freq' same is fine?

Best Regards,
Sumit Gupta


From robh at kernel.org  Wed Dec  6 05:34:03 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 07:34:03 -0600
Subject: [RFC PATCH v2 5/8] net: pcs: add driver for MediaTek USXGMII PCS
In-Reply-To: <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
Message-ID: <20231206133403.GA1894508-robh@kernel.org>

On Wed, Dec 06, 2023 at 01:44:38AM +0000, Daniel Golle wrote:
> Add driver for USXGMII PCS found in the MediaTek MT7988 SoC and supporting
> USXGMII, 10GBase-R and 5GBase-R interface modes. In order to support
> Cisco SGMII, 1000Base-X and 2500Base-X via the also present LynxI PCS
> create a wrapped PCS taking care of the components shared between the
> new USXGMII PCS and the legacy LynxI PCS.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../bindings/net/pcs/mediatek,usxgmii.yaml    |  46 +-

Why are you changing the binding you just added?

In any case, bindings are separate patches.

>  MAINTAINERS                                   |   2 +
>  drivers/net/pcs/Kconfig                       |  11 +
>  drivers/net/pcs/Makefile                      |   1 +
>  drivers/net/pcs/pcs-mtk-usxgmii.c             | 413 ++++++++++++++++++
>  include/linux/pcs/pcs-mtk-usxgmii.h           |  26 ++
>  6 files changed, 456 insertions(+), 43 deletions(-)
>  create mode 100644 drivers/net/pcs/pcs-mtk-usxgmii.c
>  create mode 100644 include/linux/pcs/pcs-mtk-usxgmii.h


From daniel at makrotopia.org  Wed Dec  6 05:37:43 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 13:37:43 +0000
Subject: [RFC PATCH v2 5/8] net: pcs: add driver for MediaTek USXGMII PCS
In-Reply-To: <20231206133403.GA1894508-robh@kernel.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
 <20231206133403.GA1894508-robh@kernel.org>
Message-ID: <ZXB5J5zO6IeTCy3b@makrotopia.org>

On Wed, Dec 06, 2023 at 07:34:03AM -0600, Rob Herring wrote:
> On Wed, Dec 06, 2023 at 01:44:38AM +0000, Daniel Golle wrote:
> > Add driver for USXGMII PCS found in the MediaTek MT7988 SoC and supporting
> > USXGMII, 10GBase-R and 5GBase-R interface modes. In order to support
> > Cisco SGMII, 1000Base-X and 2500Base-X via the also present LynxI PCS
> > create a wrapped PCS taking care of the components shared between the
> > new USXGMII PCS and the legacy LynxI PCS.
> > 
> > Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> > ---
> >  .../bindings/net/pcs/mediatek,usxgmii.yaml    |  46 +-
> 
> Why are you changing the binding you just added?

Oh, that change slipped into the wrong commit by accident, sorry about
that, I will fix it in the next iteration.

> 
> In any case, bindings are separate patches.
> 
> >  MAINTAINERS                                   |   2 +
> >  drivers/net/pcs/Kconfig                       |  11 +
> >  drivers/net/pcs/Makefile                      |   1 +
> >  drivers/net/pcs/pcs-mtk-usxgmii.c             | 413 ++++++++++++++++++
> >  include/linux/pcs/pcs-mtk-usxgmii.h           |  26 ++
> >  6 files changed, 456 insertions(+), 43 deletions(-)
> >  create mode 100644 drivers/net/pcs/pcs-mtk-usxgmii.c
> >  create mode 100644 include/linux/pcs/pcs-mtk-usxgmii.h


From robh at kernel.org  Wed Dec  6 05:38:16 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 07:38:16 -0600
Subject: [RFC PATCH v2 7/8] dt-bindings: net: mediatek,net: fix and
 complete mt7988-eth binding
In-Reply-To: <567c6aaa64ecb4872056bc0105c70153fd9d9b50.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <567c6aaa64ecb4872056bc0105c70153fd9d9b50.1701826319.git.daniel@makrotopia.org>
Message-ID: <20231206133816.GA1914715-robh@kernel.org>

On Wed, Dec 06, 2023 at 01:45:02AM +0000, Daniel Golle wrote:
> Complete support for MT7988 which comes with 3 MACs, SRAM for DMA
> descriptors and uses a dedicated PCS for the SerDes units.
> 
> Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../devicetree/bindings/net/mediatek,net.yaml | 148 +++++++++++++++++-
>  1 file changed, 146 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> index 030d106bc7d3f..ca0667c51c1c2 100644
> --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
> +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> @@ -28,7 +28,10 @@ properties:
>        - ralink,rt5350-eth
>  
>    reg:
> -    maxItems: 1
> +    minItems: 1
> +    items:
> +      - description: Base of registers used to program the ethernet controller
> +      - description: SRAM region used for DMA descriptors

Is this a dedicated SRAM for this purpose, or a common one partitioned 
up. mmio-sram and a phandle is how to do the latter.

>  
>    clocks: true
>    clock-names: true
> @@ -115,6 +118,9 @@ allOf:
>                - mediatek,mt7623-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            maxItems: 3
>  
> @@ -149,6 +155,9 @@ allOf:
>                - mediatek,mt7621-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            maxItems: 1
>  
> @@ -174,6 +183,9 @@ allOf:
>              const: mediatek,mt7622-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            maxItems: 3
>  
> @@ -215,6 +227,9 @@ allOf:
>              const: mediatek,mt7629-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            maxItems: 3
>  
> @@ -257,6 +272,9 @@ allOf:
>              const: mediatek,mt7981-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            minItems: 4
>  
> @@ -295,6 +313,9 @@ allOf:
>              const: mediatek,mt7986-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            minItems: 4
>  
> @@ -333,8 +354,13 @@ allOf:
>              const: mediatek,mt7988-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 2

Don't need maxItems here. That's already the max.

> +          minItems: 2
> +
>          interrupts:
>            minItems: 4
> +          maxItems: 4
>  
>          clocks:
>            minItems: 24
> @@ -368,7 +394,7 @@ allOf:
>              - const: top_netsys_warp_sel
>  
>  patternProperties:
> -  "^mac@[0-1]$":
> +  "^mac@[0-2]$":
>      type: object
>      unevaluatedProperties: false
>      allOf:
> @@ -382,6 +408,9 @@ patternProperties:
>        reg:
>          maxItems: 1
>  
> +      phys:
> +        maxItems: 1
> +
>      required:
>        - reg
>        - compatible
> @@ -559,3 +588,118 @@ examples:
>          };
>        };
>      };
> +
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/clock/mediatek,mt7988-clk.h>


Why is fixing the binding needing a new example? Is this example really 
different enough to justify a whole other example?

> +
> +    soc {
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +
> +      ethernet at 15100000 {
> +        compatible = "mediatek,mt7988-eth";
> +        reg = <0 0x15100000 0 0x80000>, <0 0x15400000 0 0x380000>;
> +        interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
> +                     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
> +                     <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
> +                     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
> +
> +        clocks = <&ethsys CLK_ETHDMA_XGP1_EN>,
> +                 <&ethsys CLK_ETHDMA_XGP2_EN>,
> +                 <&ethsys CLK_ETHDMA_XGP3_EN>,
> +                 <&ethsys CLK_ETHDMA_FE_EN>,
> +                 <&ethsys CLK_ETHDMA_GP2_EN>,
> +                 <&ethsys CLK_ETHDMA_GP1_EN>,
> +                 <&ethsys CLK_ETHDMA_GP3_EN>,
> +                 <&ethsys CLK_ETHDMA_ESW_EN>,
> +                 <&ethsys CLK_ETHDMA_CRYPT0_EN>,
> +                 <&ethwarp CLK_ETHWARP_WOCPU2_EN>,
> +                 <&ethwarp CLK_ETHWARP_WOCPU1_EN>,
> +                 <&ethwarp CLK_ETHWARP_WOCPU0_EN>,
> +                 <&topckgen CLK_TOP_ETH_GMII_SEL>,
> +                 <&topckgen CLK_TOP_ETH_REFCK_50M_SEL>,
> +                 <&topckgen CLK_TOP_ETH_SYS_200M_SEL>,
> +                 <&topckgen CLK_TOP_ETH_SYS_SEL>,
> +                 <&topckgen CLK_TOP_ETH_XGMII_SEL>,
> +                 <&topckgen CLK_TOP_ETH_MII_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_500M_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_PAO_2X_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_SYNC_250M_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_PPEFB_250M_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_WARP_SEL>;
> +
> +        clock-names = "xgp1", "xgp2", "xgp3", "fe", "gp2", "gp1",
> +                      "gp3", "esw", "crypto",
> +                      "ethwarp_wocpu2", "ethwarp_wocpu1",
> +                      "ethwarp_wocpu0", "top_eth_gmii_sel",
> +                      "top_eth_refck_50m_sel", "top_eth_sys_200m_sel",
> +                      "top_eth_sys_sel", "top_eth_xgmii_sel",
> +                      "top_eth_mii_sel", "top_netsys_sel",
> +                      "top_netsys_500m_sel", "top_netsys_pao_2x_sel",
> +                      "top_netsys_sync_250m_sel",
> +                      "top_netsys_ppefb_250m_sel",
> +                      "top_netsys_warp_sel";
> +        assigned-clocks = <&topckgen CLK_TOP_NETSYS_2X_SEL>,
> +                          <&topckgen CLK_TOP_NETSYS_GSW_SEL>,
> +                          <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>,
> +                          <&topckgen CLK_TOP_USXGMII_SBUS_1_SEL>,
> +                          <&topckgen CLK_TOP_SGM_0_SEL>,
> +                          <&topckgen CLK_TOP_SGM_1_SEL>;
> +        assigned-clock-parents = <&apmixedsys CLK_APMIXED_NET2PLL>,
> +                                 <&topckgen CLK_TOP_NET1PLL_D4>,
> +                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
> +                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
> +                                 <&apmixedsys CLK_APMIXED_SGMPLL>,
> +                                 <&apmixedsys CLK_APMIXED_SGMPLL>;
> +        mediatek,ethsys = <&ethsys>;
> +        mediatek,infracfg = <&topmisc>;
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        mac at 0 {
> +          compatible = "mediatek,eth-mac";
> +          reg = <0>;
> +          phy-mode = "internal"; /* CPU port of built-in 1GE switch */
> +
> +          fixed-link {
> +            speed = <10000>;
> +            full-duplex;
> +            pause;
> +          };
> +        };
> +
> +        mac at 1 {
> +          compatible = "mediatek,eth-mac";
> +          reg = <1>;
> +          phy-handle = <&int_2p5g_phy>;
> +        };
> +
> +        mac at 2 {
> +          compatible = "mediatek,eth-mac";
> +          reg = <2>;
> +          pcs-handle = <&usxgmiisys0>;
> +          phy-handle = <&phy0>;
> +        };
> +
> +        mdio_bus: mdio-bus {
> +          #address-cells = <1>;
> +          #size-cells = <0>;
> +
> +          /* external PHY */
> +          phy0: ethernet-phy at 0 {
> +            reg = <0>;
> +            compatible = "ethernet-phy-ieee802.3-c45";
> +          };
> +
> +          /* internal 2.5G PHY */
> +          int_2p5g_phy: ethernet-phy at 15 {
> +            reg = <15>;
> +            compatible = "ethernet-phy-ieee802.3-c45";
> +            phy-mode = "internal";
> +          };
> +        };
> +      };
> +    };
> -- 
> 2.43.0


From lee at kernel.org  Wed Dec  6 05:45:18 2023
From: lee at kernel.org (Lee Jones)
Date: Wed, 6 Dec 2023 13:45:18 +0000
Subject: (subset) [PATCH v11 01/10] mfd: tps6594: Use set/get APIs to
 access spi->chip_select
In-Reply-To: <395caa58-a8a0-4c75-85d3-4fa0f6f4a9ba@sirena.org.uk>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-2-amit.kumar-mahapatra@amd.com>
 <170142465659.3329910.8527538140063947758.b4-ty@kernel.org>
 <395caa58-a8a0-4c75-85d3-4fa0f6f4a9ba@sirena.org.uk>
Message-ID: <20231206134518.GE3375667@google.com>

On Fri, 01 Dec 2023, Mark Brown wrote:

> On Fri, Dec 01, 2023 at 09:57:36AM +0000, Lee Jones wrote:
> > On Sat, 25 Nov 2023 14:51:28 +0530, Amit Kumar Mahapatra wrote:
> > > In preparation for adding multiple CS support for a device, set/get
> > > functions were introduces accessing spi->chip_select in
> > > 'commit 303feb3cc06a ("spi: Add APIs in spi core to set/get
> > > spi->chip_select and spi->cs_gpiod")'.
> > > Replace spi->chip_select with spi_get_chipselect() API.
> 
> > Applied, thanks!
> 
> > [01/10] mfd: tps6594: Use set/get APIs to access spi->chip_select
> >         commit: dd636638446c87c95c5beddcd367d95ac6764c6c
> 
> Is there a signed tag available for this - without this change the
> subsequent SPI changes introduce a build breakage.

Not yet, but I can get around to making one.

-- 
Lee Jones [???]


From andrew at lunn.ch  Wed Dec  6 05:52:59 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 6 Dec 2023 14:52:59 +0100
Subject: [PATCH net-next] net: stmmac: qcom-ethqos: Add sysfs nodes for
 qcom ethqos
In-Reply-To: <5d5f3955-fc30-428c-99f4-42f9b7580a84@quicinc.com>
References: <20231204084854.31543-1-quic_snehshah@quicinc.com>
 <3e4a1b9c-ed0f-466e-ba11-fc5b7ef308a1@lunn.ch>
 <5d5f3955-fc30-428c-99f4-42f9b7580a84@quicinc.com>
Message-ID: <0c966845-2bbc-4196-806d-6a33e435bf7d@lunn.ch>

On Wed, Dec 06, 2023 at 05:17:25PM +0530, Sneh Shah wrote:
> 
> 
> On 12/5/2023 8:38 PM, Andrew Lunn wrote:
> > On Mon, Dec 04, 2023 at 02:18:54PM +0530, Sneh Shah wrote:
> >> Add sysfs nodes to conifigure routing of specific vlan id to GVM queue.
> >> GVM queue is not exposed to PVM stmmac, so TC ops can't configure routing.
> > 
> > Adding files in /sysfs has ~0 chance of being accepted.
> > 
> > As requested, please explain what all these different hardware blocks
> > are, and what you are trying to achieve. We can then recommend the
> > correct interface.
> > 
> >     Andrew
> > 
> > ---
> > pw-bot: cr
> 

> We have multiVM Architecture here. PVM will have stmmac running with
> 4 Rx Tx queues. stmmac in PVM is responsible to configure whole
> ethernet HW MAC/DMA/MTL ( including clocks, regulators and other
> core bsp elements).

Please remember that stmmac is mostly used in embedded systems. People
used to embedded systems generally don't know virtual machine
terminology. So please spell out what PBM, GVM, etc mean.

> In GVM we have thin Ethernet driver, which is responsible to
> configure and manage only 1 Rx/TX queue, i.e 5th Rx/Tx ethernet
> queue. GVM can't access any other resisters apart from this 5th
> queue specific MTL and DMA registers.
 
> We need to route vlan traffic of a specific Priority to GVM Queue
> (Ethernet queue 5) via programming a MAC register. The MAC register
> is not accessible in GVM and has to be programmed from PVM. stmmac
> already has TC OPS to program this routing via vlan
> priority. However, as PVM has only 4 queues enabled, TC tool will
> not take 5th queue as input. Hence, these nodes were added to
> conifure the MAC register to route specific vlan packets to 5th
> queue in GVM.
 
> Note: The queues mentioned above are HW MTL Queues and DMA
> Channels. The routing can be done in the HW itself based on vlan pcp
> before the packets reach to driver.

Is the normal way you would do this is like this:

tc qdisc add dev eth1 parent root handle 100 \
mqprio num_tc 4 \
map 0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0 \
queues 1 at 0 1 at 1 1 at 2 1 at 3 \
hw 1

But you are saying that you cannot extend this to 5 queues?

    Andrew


From gabriel.fernandez at foss.st.com  Wed Dec  6 06:00:25 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Wed, 6 Dec 2023 15:00:25 +0100
Subject: [PATCH v5 1/5] clk: stm32mp1: move stm32mp1 clock driver into stm32 directory
In-Reply-To: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
References: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231206140029.492906-2-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Move all STM32MP clock drivers into same directory (stm32).

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/Kconfig                    | 11 +---------
 drivers/clk/Makefile                   |  1 -
 drivers/clk/stm32/Kconfig              | 29 ++++++++++++++++++++++++++
 drivers/clk/stm32/Makefile             |  1 +
 drivers/clk/{ => stm32}/clk-stm32mp1.c |  0
 5 files changed, 31 insertions(+), 11 deletions(-)
 create mode 100644 drivers/clk/stm32/Kconfig
 rename drivers/clk/{ => stm32}/clk-stm32mp1.c (100%)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c30d0d396f7a..50af5fc7f570 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -414,16 +414,6 @@ config COMMON_CLK_VC7
 	  Renesas Versaclock7 is a family of configurable clock generator
 	  and jitter attenuator ICs with fractional and integer dividers.
 
-config COMMON_CLK_STM32MP135
-	def_bool COMMON_CLK && MACH_STM32MP13
-	help
-	  Support for stm32mp135 SoC family clocks
-
-config COMMON_CLK_STM32MP157
-	def_bool COMMON_CLK && MACH_STM32MP157
-	help
-	  Support for stm32mp157 SoC family clocks
-
 config COMMON_CLK_STM32F
 	def_bool COMMON_CLK && (MACH_STM32F429 || MACH_STM32F469 || MACH_STM32F746)
 	help
@@ -504,6 +494,7 @@ source "drivers/clk/starfive/Kconfig"
 source "drivers/clk/sunxi/Kconfig"
 source "drivers/clk/sunxi-ng/Kconfig"
 source "drivers/clk/tegra/Kconfig"
+source "drivers/clk/stm32/Kconfig"
 source "drivers/clk/ti/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
 source "drivers/clk/visconti/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ed71f2e0ee36..14fa8d4ecc1f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -70,7 +70,6 @@ obj-$(CONFIG_COMMON_CLK_SI570)		+= clk-si570.o
 obj-$(CONFIG_COMMON_CLK_SP7021)		+= clk-sp7021.o
 obj-$(CONFIG_COMMON_CLK_STM32F)		+= clk-stm32f4.o
 obj-$(CONFIG_COMMON_CLK_STM32H7)	+= clk-stm32h7.o
-obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o
 obj-$(CONFIG_COMMON_CLK_TPS68470)      += clk-tps68470.o
 obj-$(CONFIG_CLK_TWL6040)		+= clk-twl6040.o
 obj-$(CONFIG_CLK_TWL)			+= clk-twl.o
diff --git a/drivers/clk/stm32/Kconfig b/drivers/clk/stm32/Kconfig
new file mode 100644
index 000000000000..3c8493a94a11
--- /dev/null
+++ b/drivers/clk/stm32/Kconfig
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# common clock support for STMicroelectronics SoC family.
+
+menuconfig COMMON_CLK_STM32MP
+	bool "Clock support for common STM32MP clocks"
+	depends on ARCH_STM32 || COMPILE_TEST
+	default y
+	select RESET_CONTROLLER
+	help
+	  Support for STM32MP SoC family clocks.
+
+if COMMON_CLK_STM32MP
+
+config COMMON_CLK_STM32MP135
+	bool "Clock driver for stm32mp13x clocks"
+	depends on ARM || COMPILE_TEST
+	default y
+	help
+	  Support for stm32mp13x SoC family clocks.
+
+config COMMON_CLK_STM32MP157
+	bool "Clock driver for stm32mp15x clocks"
+	depends on ARM || COMPILE_TEST
+	default y
+	help
+	  Support for stm32mp15x SoC family clocks.
+
+endif
+
diff --git a/drivers/clk/stm32/Makefile b/drivers/clk/stm32/Makefile
index 95bd2230bba0..c154ef3e88f9 100644
--- a/drivers/clk/stm32/Makefile
+++ b/drivers/clk/stm32/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_COMMON_CLK_STM32MP135)	+= clk-stm32mp13.o clk-stm32-core.o reset-stm32.o
+obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o
diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/stm32/clk-stm32mp1.c
similarity index 100%
rename from drivers/clk/clk-stm32mp1.c
rename to drivers/clk/stm32/clk-stm32mp1.c
-- 
2.25.1



From gabriel.fernandez at foss.st.com  Wed Dec  6 06:00:26 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Wed, 6 Dec 2023 15:00:26 +0100
Subject: [PATCH v5 2/5] clk: stm32mp1: use stm32mp13 reset driver
In-Reply-To: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
References: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231206140029.492906-3-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

STM32MP15 is now using the same reset driver as STM32MP13 as they
have the same binding requirement.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/stm32/Makefile         |   2 +-
 drivers/clk/stm32/clk-stm32-core.c |   5 +-
 drivers/clk/stm32/clk-stm32-core.h |   5 +-
 drivers/clk/stm32/clk-stm32mp1.c   | 127 ++++-------------------------
 drivers/clk/stm32/clk-stm32mp13.c  |   9 +-
 drivers/clk/stm32/reset-stm32.c    |  14 ++--
 drivers/clk/stm32/reset-stm32.h    |   8 +-
 7 files changed, 42 insertions(+), 128 deletions(-)

diff --git a/drivers/clk/stm32/Makefile b/drivers/clk/stm32/Makefile
index c154ef3e88f9..5ced7fe3ddec 100644
--- a/drivers/clk/stm32/Makefile
+++ b/drivers/clk/stm32/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_COMMON_CLK_STM32MP135)	+= clk-stm32mp13.o clk-stm32-core.o reset-stm32.o
-obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o
+obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o reset-stm32.o
diff --git a/drivers/clk/stm32/clk-stm32-core.c b/drivers/clk/stm32/clk-stm32-core.c
index 067b918a8894..58705fcad334 100644
--- a/drivers/clk/stm32/clk-stm32-core.c
+++ b/drivers/clk/stm32/clk-stm32-core.c
@@ -70,6 +70,7 @@ static int stm32_rcc_clock_init(struct device *dev,
 int stm32_rcc_init(struct device *dev, const struct of_device_id *match_data,
 		   void __iomem *base)
 {
+	const struct stm32_rcc_match_data *rcc_match_data;
 	const struct of_device_id *match;
 	int err;
 
@@ -79,8 +80,10 @@ int stm32_rcc_init(struct device *dev, const struct of_device_id *match_data,
 		return -ENODEV;
 	}
 
+	rcc_match_data = match->data;
+
 	/* RCC Reset Configuration */
-	err = stm32_rcc_reset_init(dev, match, base);
+	err = stm32_rcc_reset_init(dev, rcc_match_data->reset_data, base);
 	if (err) {
 		pr_err("stm32 reset failed to initialize\n");
 		return err;
diff --git a/drivers/clk/stm32/clk-stm32-core.h b/drivers/clk/stm32/clk-stm32-core.h
index 76cffda02308..bb5aa19a792d 100644
--- a/drivers/clk/stm32/clk-stm32-core.h
+++ b/drivers/clk/stm32/clk-stm32-core.h
@@ -70,15 +70,12 @@ struct stm32_rcc_match_data {
 	const struct clock_config	*tab_clocks;
 	unsigned int			maxbinding;
 	struct clk_stm32_clock_data	*clock_data;
-	u32				clear_offset;
+	struct clk_stm32_reset_data	*reset_data;
 	int (*check_security)(void __iomem *base,
 			      const struct clock_config *cfg);
 	int (*multi_mux)(void __iomem *base, const struct clock_config *cfg);
 };
 
-int stm32_rcc_reset_init(struct device *dev, const struct of_device_id *match,
-			 void __iomem *base);
-
 int stm32_rcc_init(struct device *dev, const struct of_device_id *match_data,
 		   void __iomem *base);
 
diff --git a/drivers/clk/stm32/clk-stm32mp1.c b/drivers/clk/stm32/clk-stm32mp1.c
index 939779f66867..7e2337297402 100644
--- a/drivers/clk/stm32/clk-stm32mp1.c
+++ b/drivers/clk/stm32/clk-stm32mp1.c
@@ -20,6 +20,10 @@
 
 #include <dt-bindings/clock/stm32mp1-clks.h>
 
+#include "reset-stm32.h"
+
+#define STM32MP1_RESET_ID_MASK GENMASK(15, 0)
+
 static DEFINE_SPINLOCK(rlock);
 
 #define RCC_OCENSETR		0x0C
@@ -2137,22 +2141,27 @@ struct stm32_rcc_match_data {
 	const struct clock_config *cfg;
 	unsigned int num;
 	unsigned int maxbinding;
-	u32 clear_offset;
+	struct clk_stm32_reset_data *reset_data;
 	bool (*check_security)(const struct clock_config *cfg);
 };
 
+static struct clk_stm32_reset_data stm32mp1_reset_data = {
+	.nr_lines	= STM32MP1_RESET_ID_MASK,
+	.clear_offset	= RCC_CLR,
+};
+
 static struct stm32_rcc_match_data stm32mp1_data = {
 	.cfg		= stm32mp1_clock_cfg,
 	.num		= ARRAY_SIZE(stm32mp1_clock_cfg),
 	.maxbinding	= STM32MP1_LAST_CLK,
-	.clear_offset	= RCC_CLR,
+	.reset_data	= &stm32mp1_reset_data,
 };
 
 static struct stm32_rcc_match_data stm32mp1_data_secure = {
 	.cfg		= stm32mp1_clock_cfg,
 	.num		= ARRAY_SIZE(stm32mp1_clock_cfg),
 	.maxbinding	= STM32MP1_LAST_CLK,
-	.clear_offset	= RCC_CLR,
+	.reset_data	= &stm32mp1_reset_data,
 	.check_security = &stm32_check_security
 };
 
@@ -2193,113 +2202,6 @@ static int stm32_register_hw_clk(struct device *dev,
 	return 0;
 }
 
-#define STM32_RESET_ID_MASK GENMASK(15, 0)
-
-struct stm32_reset_data {
-	/* reset lock */
-	spinlock_t			lock;
-	struct reset_controller_dev	rcdev;
-	void __iomem			*membase;
-	u32				clear_offset;
-};
-
-static inline struct stm32_reset_data *
-to_stm32_reset_data(struct reset_controller_dev *rcdev)
-{
-	return container_of(rcdev, struct stm32_reset_data, rcdev);
-}
-
-static int stm32_reset_update(struct reset_controller_dev *rcdev,
-			      unsigned long id, bool assert)
-{
-	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
-
-	if (data->clear_offset) {
-		void __iomem *addr;
-
-		addr = data->membase + (bank * reg_width);
-		if (!assert)
-			addr += data->clear_offset;
-
-		writel(BIT(offset), addr);
-
-	} else {
-		unsigned long flags;
-		u32 reg;
-
-		spin_lock_irqsave(&data->lock, flags);
-
-		reg = readl(data->membase + (bank * reg_width));
-
-		if (assert)
-			reg |= BIT(offset);
-		else
-			reg &= ~BIT(offset);
-
-		writel(reg, data->membase + (bank * reg_width));
-
-		spin_unlock_irqrestore(&data->lock, flags);
-	}
-
-	return 0;
-}
-
-static int stm32_reset_assert(struct reset_controller_dev *rcdev,
-			      unsigned long id)
-{
-	return stm32_reset_update(rcdev, id, true);
-}
-
-static int stm32_reset_deassert(struct reset_controller_dev *rcdev,
-				unsigned long id)
-{
-	return stm32_reset_update(rcdev, id, false);
-}
-
-static int stm32_reset_status(struct reset_controller_dev *rcdev,
-			      unsigned long id)
-{
-	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
-	u32 reg;
-
-	reg = readl(data->membase + (bank * reg_width));
-
-	return !!(reg & BIT(offset));
-}
-
-static const struct reset_control_ops stm32_reset_ops = {
-	.assert		= stm32_reset_assert,
-	.deassert	= stm32_reset_deassert,
-	.status		= stm32_reset_status,
-};
-
-static int stm32_rcc_reset_init(struct device *dev, void __iomem *base,
-				const struct of_device_id *match)
-{
-	const struct stm32_rcc_match_data *data = match->data;
-	struct stm32_reset_data *reset_data = NULL;
-
-	reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
-	if (!reset_data)
-		return -ENOMEM;
-
-	spin_lock_init(&reset_data->lock);
-	reset_data->membase = base;
-	reset_data->rcdev.owner = THIS_MODULE;
-	reset_data->rcdev.ops = &stm32_reset_ops;
-	reset_data->rcdev.of_node = dev_of_node(dev);
-	reset_data->rcdev.nr_resets = STM32_RESET_ID_MASK;
-	reset_data->clear_offset = data->clear_offset;
-
-	return reset_controller_register(&reset_data->rcdev);
-}
-
 static int stm32_rcc_clock_init(struct device *dev, void __iomem *base,
 				const struct of_device_id *match)
 {
@@ -2342,6 +2244,7 @@ static int stm32_rcc_clock_init(struct device *dev, void __iomem *base,
 static int stm32_rcc_init(struct device *dev, void __iomem *base,
 			  const struct of_device_id *match_data)
 {
+	const struct stm32_rcc_match_data *rcc_match_data;
 	const struct of_device_id *match;
 	int err;
 
@@ -2351,8 +2254,10 @@ static int stm32_rcc_init(struct device *dev, void __iomem *base,
 		return -ENODEV;
 	}
 
+	rcc_match_data = match->data;
+
 	/* RCC Reset Configuration */
-	err = stm32_rcc_reset_init(dev, base, match);
+	err = stm32_rcc_reset_init(dev, rcc_match_data->reset_data, base);
 	if (err) {
 		pr_err("stm32mp1 reset failed to initialize\n");
 		return err;
diff --git a/drivers/clk/stm32/clk-stm32mp13.c b/drivers/clk/stm32/clk-stm32mp13.c
index c4a737482fe5..d4ecb3c34a1b 100644
--- a/drivers/clk/stm32/clk-stm32mp13.c
+++ b/drivers/clk/stm32/clk-stm32mp13.c
@@ -10,8 +10,10 @@
 #include <linux/platform_device.h>
 #include <dt-bindings/clock/stm32mp13-clks.h>
 #include "clk-stm32-core.h"
+#include "reset-stm32.h"
 #include "stm32mp13_rcc.h"
 
+#define STM32MP1_RESET_ID_MASK GENMASK(15, 0)
 #define RCC_CLR_OFFSET		0x4
 
 /* STM32 Gates definition */
@@ -1511,13 +1513,18 @@ static struct clk_stm32_clock_data stm32mp13_clock_data = {
 	.is_multi_mux	= stm32mp13_is_multi_mux,
 };
 
+static struct clk_stm32_reset_data stm32mp13_reset_data = {
+	.nr_lines	= STM32MP1_RESET_ID_MASK,
+	.clear_offset	= RCC_CLR_OFFSET,
+};
+
 static const struct stm32_rcc_match_data stm32mp13_data = {
 	.tab_clocks	= stm32mp13_clock_cfg,
 	.num_clocks	= ARRAY_SIZE(stm32mp13_clock_cfg),
 	.clock_data	= &stm32mp13_clock_data,
 	.check_security = &stm32mp13_clock_is_provided_by_secure,
 	.maxbinding	= STM32MP1_LAST_CLK,
-	.clear_offset	= RCC_CLR_OFFSET,
+	.reset_data	= &stm32mp13_reset_data,
 };
 
 static const struct of_device_id stm32mp13_match_data[] = {
diff --git a/drivers/clk/stm32/reset-stm32.c b/drivers/clk/stm32/reset-stm32.c
index e89381528af9..14c2ee1eebee 100644
--- a/drivers/clk/stm32/reset-stm32.c
+++ b/drivers/clk/stm32/reset-stm32.c
@@ -11,9 +11,7 @@
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 
-#include "clk-stm32-core.h"
-
-#define STM32_RESET_ID_MASK GENMASK(15, 0)
+#include "reset-stm32.h"
 
 struct stm32_reset_data {
 	/* reset lock */
@@ -99,24 +97,22 @@ static const struct reset_control_ops stm32_reset_ops = {
 	.status		= stm32_reset_status,
 };
 
-int stm32_rcc_reset_init(struct device *dev, const struct of_device_id *match,
+int stm32_rcc_reset_init(struct device *dev, struct clk_stm32_reset_data *data,
 			 void __iomem *base)
 {
-	const struct stm32_rcc_match_data *data = match->data;
-	struct stm32_reset_data *reset_data = NULL;
-
-	data = match->data;
+	struct stm32_reset_data *reset_data;
 
 	reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
 	if (!reset_data)
 		return -ENOMEM;
 
 	spin_lock_init(&reset_data->lock);
+
 	reset_data->membase = base;
 	reset_data->rcdev.owner = THIS_MODULE;
 	reset_data->rcdev.ops = &stm32_reset_ops;
 	reset_data->rcdev.of_node = dev_of_node(dev);
-	reset_data->rcdev.nr_resets = STM32_RESET_ID_MASK;
+	reset_data->rcdev.nr_resets = data->nr_lines;
 	reset_data->clear_offset = data->clear_offset;
 
 	return reset_controller_register(&reset_data->rcdev);
diff --git a/drivers/clk/stm32/reset-stm32.h b/drivers/clk/stm32/reset-stm32.h
index 6eb6ea4b55ab..8cf1cc9be480 100644
--- a/drivers/clk/stm32/reset-stm32.h
+++ b/drivers/clk/stm32/reset-stm32.h
@@ -4,5 +4,11 @@
  * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
  */
 
-int stm32_rcc_reset_init(struct device *dev, const struct of_device_id *match,
+struct clk_stm32_reset_data {
+	const struct reset_control_ops *ops;
+	unsigned int nr_lines;
+	u32 clear_offset;
+};
+
+int stm32_rcc_reset_init(struct device *dev, struct clk_stm32_reset_data *data,
 			 void __iomem *base);
-- 
2.25.1



From gabriel.fernandez at foss.st.com  Wed Dec  6 06:00:24 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Wed, 6 Dec 2023 15:00:24 +0100
Subject: [PATCH v5 0/5] Introduce STM32MP257 clock driver
Message-ID: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

This patch-set introduces clock driver for STM32MP257 based on Arm Cortex-35.
It creates also a menuconfig for all STM32MP clock drivers.
The STM32MP1 and STM32MP13 are now in same stm32 directory

v5:
  - Fix sparse warnings: was not declared. Should it be static?
    drivers/clk/stm32/clk-stm32mp13.c:1516:29: symbol 'stm32mp13_reset_data'
    drivers/clk/stm32/clk-stm32mp1.c:2148:29: symbol 'stm32mp1_reset_data'
    drivers/clk/stm32/clk-stm32mp25.c:1003:5: symbol 'stm32mp25_cpt_gate'
    drivers/clk/stm32/clk-stm32mp25.c:1005:29: symbol 'stm32mp25_clock_data'
    drivers/clk/stm32/clk-stm32mp25.c:1011:29: symbol 'stm32mp25_reset_data'

v4:
  - use GPL-2.0-only OR BSD-2-Clause for clock and reset binding files
  - use quotes ' for #clock-cells and #reset-cells in YAML documentation
  - reset binding start now to 0 instead 1
  - improve management of reset lines that are not managed

v3:
  - from Rob Herring change clock item description in YAML documentation
v2:
  - rework reset binding (use ID witch start from 0)
  - rework reset driver to manage STM32MP13 / STM32MP15 / STM32MP25
  - rework YAML documentation

Gabriel Fernandez (5):
  clk: stm32mp1: move stm32mp1 clock driver into stm32 directory
  clk: stm32mp1: use stm32mp13 reset driver
  dt-bindings: stm32: add clocks and reset binding for stm32mp25
    platform
  clk: stm32: introduce clocks for STM32MP257 platform
  arm64: dts: st: add rcc support in stm32mp251

 .../bindings/clock/st,stm32mp25-rcc.yaml      |   76 +
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |   59 +-
 drivers/clk/Kconfig                           |   11 +-
 drivers/clk/Makefile                          |    1 -
 drivers/clk/stm32/Kconfig                     |   36 +
 drivers/clk/stm32/Makefile                    |    2 +
 drivers/clk/stm32/clk-stm32-core.c            |    5 +-
 drivers/clk/stm32/clk-stm32-core.h            |    5 +-
 drivers/clk/{ => stm32}/clk-stm32mp1.c        |  127 +-
 drivers/clk/stm32/clk-stm32mp13.c             |    9 +-
 drivers/clk/stm32/clk-stm32mp25.c             | 1125 ++++
 drivers/clk/stm32/reset-stm32.c               |   73 +-
 drivers/clk/stm32/reset-stm32.h               |   15 +-
 drivers/clk/stm32/stm32mp25_rcc.h             | 4977 +++++++++++++++++
 include/dt-bindings/clock/st,stm32mp25-rcc.h  |  492 ++
 include/dt-bindings/reset/st,stm32mp25-rcc.h  |  167 +
 16 files changed, 6999 insertions(+), 181 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
 create mode 100644 drivers/clk/stm32/Kconfig
 rename drivers/clk/{ => stm32}/clk-stm32mp1.c (95%)
 create mode 100644 drivers/clk/stm32/clk-stm32mp25.c
 create mode 100644 drivers/clk/stm32/stm32mp25_rcc.h
 create mode 100644 include/dt-bindings/clock/st,stm32mp25-rcc.h
 create mode 100644 include/dt-bindings/reset/st,stm32mp25-rcc.h

-- 
2.25.1



From gabriel.fernandez at foss.st.com  Wed Dec  6 06:00:27 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Wed, 6 Dec 2023 15:00:27 +0100
Subject: [PATCH v5 3/5] dt-bindings: stm32: add clocks and reset binding for stm32mp25 platform
In-Reply-To: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
References: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231206140029.492906-4-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Adds clock and reset binding entries for STM32MP25 SoC family

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/clock/st,stm32mp25-rcc.yaml      |  76 +++
 include/dt-bindings/clock/st,stm32mp25-rcc.h  | 492 ++++++++++++++++++
 include/dt-bindings/reset/st,stm32mp25-rcc.h  | 167 ++++++
 3 files changed, 735 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
 create mode 100644 include/dt-bindings/clock/st,stm32mp25-rcc.h
 create mode 100644 include/dt-bindings/reset/st,stm32mp25-rcc.h

diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
new file mode 100644
index 000000000000..7732e79a42b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/st,stm32mp25-rcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32MP25 Reset Clock Controller
+
+maintainers:
+  - Gabriel Fernandez <gabriel.fernandez at foss.st.com>
+
+description: |
+  The RCC hardware block is both a reset and a clock controller.
+  RCC makes also power management (resume/supend).
+
+  See also::
+    include/dt-bindings/clock/st,stm32mp25-rcc.h
+    include/dt-bindings/reset/st,stm32mp25-rcc.h
+
+properties:
+  compatible:
+    enum:
+      - st,stm32mp25-rcc
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+  '#reset-cells':
+    const: 1
+
+  clocks:
+    items:
+      - description: CK_SCMI_HSE High Speed External oscillator (8 to 48 MHz)
+      - description: CK_SCMI_HSI High Speed Internal oscillator (~ 64 MHz)
+      - description: CK_SCMI_MSI Low Power Internal oscillator (~ 4 MHz or ~ 16 MHz)
+      - description: CK_SCMI_LSE Low Speed External oscillator (32 KHz)
+      - description: CK_SCMI_LSI Low Speed Internal oscillator (~ 32 KHz)
+
+  clock-names:
+    items:
+      - const: hse
+      - const: hsi
+      - const: msi
+      - const: lse
+      - const: lsi
+
+required:
+  - compatible
+  - reg
+  - '#clock-cells'
+  - '#reset-cells'
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+
+    rcc: clock-controller at 44200000 {
+        compatible = "st,stm32mp25-rcc";
+        reg = <0x44200000 0x10000>;
+        #clock-cells = <1>;
+        #reset-cells = <1>;
+        clock-names = "hse", "hsi", "msi", "lse", "lsi";
+        clocks = <&scmi_clk CK_SCMI_HSE>,
+                 <&scmi_clk CK_SCMI_HSI>,
+                 <&scmi_clk CK_SCMI_MSI>,
+                 <&scmi_clk CK_SCMI_LSE>,
+                 <&scmi_clk CK_SCMI_LSI>;
+    };
+...
diff --git a/include/dt-bindings/clock/st,stm32mp25-rcc.h b/include/dt-bindings/clock/st,stm32mp25-rcc.h
new file mode 100644
index 000000000000..b6cf05ad4be6
--- /dev/null
+++ b/include/dt-bindings/clock/st,stm32mp25-rcc.h
@@ -0,0 +1,492 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
+/*
+ * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
+ * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
+ */
+
+#ifndef _DT_BINDINGS_STM32MP25_CLKS_H_
+#define _DT_BINDINGS_STM32MP25_CLKS_H_
+
+/* INTERNAL/EXTERNAL OSCILLATORS */
+#define HSI_CK			0
+#define HSE_CK			1
+#define MSI_CK			2
+#define LSI_CK			3
+#define LSE_CK			4
+#define I2S_CK			5
+#define RTC_CK			6
+#define SPDIF_CK_SYMB		7
+
+/* PLL CLOCKS */
+#define PLL1_CK			8
+#define PLL2_CK			9
+#define PLL3_CK			10
+#define PLL4_CK			11
+#define PLL5_CK			12
+#define PLL6_CK			13
+#define PLL7_CK			14
+#define PLL8_CK			15
+
+#define CK_CPU1			16
+
+/* APB DIV CLOCKS */
+#define CK_ICN_APB1		17
+#define CK_ICN_APB2		18
+#define CK_ICN_APB3		19
+#define CK_ICN_APB4		20
+#define CK_ICN_APBDBG		21
+
+/* GLOBAL TIMER */
+#define TIMG1_CK		22
+#define TIMG2_CK		23
+
+/* FLEXGEN CLOCKS */
+#define CK_ICN_HS_MCU		24
+#define CK_ICN_SDMMC		25
+#define CK_ICN_DDR		26
+#define CK_ICN_DISPLAY		27
+#define CK_ICN_HSL		28
+#define CK_ICN_NIC		29
+#define CK_ICN_VID		30
+#define CK_FLEXGEN_07		31
+#define CK_FLEXGEN_08		32
+#define CK_FLEXGEN_09		33
+#define CK_FLEXGEN_10		34
+#define CK_FLEXGEN_11		35
+#define CK_FLEXGEN_12		36
+#define CK_FLEXGEN_13		37
+#define CK_FLEXGEN_14		38
+#define CK_FLEXGEN_15		39
+#define CK_FLEXGEN_16		40
+#define CK_FLEXGEN_17		41
+#define CK_FLEXGEN_18		42
+#define CK_FLEXGEN_19		43
+#define CK_FLEXGEN_20		44
+#define CK_FLEXGEN_21		45
+#define CK_FLEXGEN_22		46
+#define CK_FLEXGEN_23		47
+#define CK_FLEXGEN_24		48
+#define CK_FLEXGEN_25		49
+#define CK_FLEXGEN_26		50
+#define CK_FLEXGEN_27		51
+#define CK_FLEXGEN_28		52
+#define CK_FLEXGEN_29		53
+#define CK_FLEXGEN_30		54
+#define CK_FLEXGEN_31		55
+#define CK_FLEXGEN_32		56
+#define CK_FLEXGEN_33		57
+#define CK_FLEXGEN_34		58
+#define CK_FLEXGEN_35		59
+#define CK_FLEXGEN_36		60
+#define CK_FLEXGEN_37		61
+#define CK_FLEXGEN_38		62
+#define CK_FLEXGEN_39		63
+#define CK_FLEXGEN_40		64
+#define CK_FLEXGEN_41		65
+#define CK_FLEXGEN_42		66
+#define CK_FLEXGEN_43		67
+#define CK_FLEXGEN_44		68
+#define CK_FLEXGEN_45		69
+#define CK_FLEXGEN_46		70
+#define CK_FLEXGEN_47		71
+#define CK_FLEXGEN_48		72
+#define CK_FLEXGEN_49		73
+#define CK_FLEXGEN_50		74
+#define CK_FLEXGEN_51		75
+#define CK_FLEXGEN_52		76
+#define CK_FLEXGEN_53		77
+#define CK_FLEXGEN_54		78
+#define CK_FLEXGEN_55		79
+#define CK_FLEXGEN_56		80
+#define CK_FLEXGEN_57		81
+#define CK_FLEXGEN_58		82
+#define CK_FLEXGEN_59		83
+#define CK_FLEXGEN_60		84
+#define CK_FLEXGEN_61		85
+#define CK_FLEXGEN_62		86
+#define CK_FLEXGEN_63		87
+
+/* LOW SPEED MCU CLOCK */
+#define CK_ICN_LS_MCU		88
+
+#define CK_BUS_STM500		89
+#define CK_BUS_FMC		90
+#define CK_BUS_GPU		91
+#define CK_BUS_ETH1		92
+#define CK_BUS_ETH2		93
+#define CK_BUS_PCIE		94
+#define CK_BUS_DDRPHYC		95
+#define CK_BUS_SYSCPU1		96
+#define CK_BUS_ETHSW		97
+#define CK_BUS_HPDMA1		98
+#define CK_BUS_HPDMA2		99
+#define CK_BUS_HPDMA3		100
+#define CK_BUS_ADC12		101
+#define CK_BUS_ADC3		102
+#define CK_BUS_IPCC1		103
+#define CK_BUS_CCI		104
+#define CK_BUS_CRC		105
+#define CK_BUS_MDF1		106
+#define CK_BUS_OSPIIOM		107
+#define CK_BUS_BKPSRAM		108
+#define CK_BUS_HASH		109
+#define CK_BUS_RNG		110
+#define CK_BUS_CRYP1		111
+#define CK_BUS_CRYP2		112
+#define CK_BUS_SAES		113
+#define CK_BUS_PKA		114
+#define CK_BUS_GPIOA		115
+#define CK_BUS_GPIOB		116
+#define CK_BUS_GPIOC		117
+#define CK_BUS_GPIOD		118
+#define CK_BUS_GPIOE		119
+#define CK_BUS_GPIOF		120
+#define CK_BUS_GPIOG		121
+#define CK_BUS_GPIOH		122
+#define CK_BUS_GPIOI		123
+#define CK_BUS_GPIOJ		124
+#define CK_BUS_GPIOK		125
+#define CK_BUS_LPSRAM1		126
+#define CK_BUS_LPSRAM2		127
+#define CK_BUS_LPSRAM3		128
+#define CK_BUS_GPIOZ		129
+#define CK_BUS_LPDMA		130
+#define CK_BUS_HSEM		131
+#define CK_BUS_IPCC2		132
+#define CK_BUS_RTC		133
+#define CK_BUS_SPI8		134
+#define CK_BUS_LPUART1		135
+#define CK_BUS_I2C8		136
+#define CK_BUS_LPTIM3		137
+#define CK_BUS_LPTIM4		138
+#define CK_BUS_LPTIM5		139
+#define CK_BUS_IWDG5		140
+#define CK_BUS_WWDG2		141
+#define CK_BUS_I3C4		142
+#define CK_BUS_TIM2		143
+#define CK_BUS_TIM3		144
+#define CK_BUS_TIM4		145
+#define CK_BUS_TIM5		146
+#define CK_BUS_TIM6		147
+#define CK_BUS_TIM7		148
+#define CK_BUS_TIM10		149
+#define CK_BUS_TIM11		150
+#define CK_BUS_TIM12		151
+#define CK_BUS_TIM13		152
+#define CK_BUS_TIM14		153
+#define CK_BUS_LPTIM1		154
+#define CK_BUS_LPTIM2		155
+#define CK_BUS_SPI2		156
+#define CK_BUS_SPI3		157
+#define CK_BUS_SPDIFRX		158
+#define CK_BUS_USART2		159
+#define CK_BUS_USART3		160
+#define CK_BUS_UART4		161
+#define CK_BUS_UART5		162
+#define CK_BUS_I2C1		163
+#define CK_BUS_I2C2		164
+#define CK_BUS_I2C3		165
+#define CK_BUS_I2C4		166
+#define CK_BUS_I2C5		167
+#define CK_BUS_I2C6		168
+#define CK_BUS_I2C7		169
+#define CK_BUS_I3C1		170
+#define CK_BUS_I3C2		171
+#define CK_BUS_I3C3		172
+#define CK_BUS_TIM1		173
+#define CK_BUS_TIM8		174
+#define CK_BUS_TIM15		175
+#define CK_BUS_TIM16		176
+#define CK_BUS_TIM17		177
+#define CK_BUS_TIM20		178
+#define CK_BUS_SAI1		179
+#define CK_BUS_SAI2		180
+#define CK_BUS_SAI3		181
+#define CK_BUS_SAI4		182
+#define CK_BUS_USART1		183
+#define CK_BUS_USART6		184
+#define CK_BUS_UART7		185
+#define CK_BUS_UART8		186
+#define CK_BUS_UART9		187
+#define CK_BUS_FDCAN		188
+#define CK_BUS_SPI1		189
+#define CK_BUS_SPI4		190
+#define CK_BUS_SPI5		191
+#define CK_BUS_SPI6		192
+#define CK_BUS_SPI7		193
+#define CK_BUS_BSEC		194
+#define CK_BUS_IWDG1		195
+#define CK_BUS_IWDG2		196
+#define CK_BUS_IWDG3		197
+#define CK_BUS_IWDG4		198
+#define CK_BUS_WWDG1		199
+#define CK_BUS_VREF		200
+#define CK_BUS_DTS		201
+#define CK_BUS_SERC		202
+#define CK_BUS_HDP		203
+#define CK_BUS_IS2M		204
+#define CK_BUS_DSI		205
+#define CK_BUS_LTDC		206
+#define CK_BUS_CSI		207
+#define CK_BUS_DCMIPP		208
+#define CK_BUS_DDRC		209
+#define CK_BUS_DDRCFG		210
+#define CK_BUS_GICV2M		211
+#define CK_BUS_USBTC		212
+#define CK_BUS_USB3PCIEPHY	214
+#define CK_BUS_STGEN		215
+#define CK_BUS_VDEC		216
+#define CK_BUS_VENC		217
+#define CK_SYSDBG		218
+#define CK_KER_TIM2		219
+#define CK_KER_TIM3		220
+#define CK_KER_TIM4		221
+#define CK_KER_TIM5		222
+#define CK_KER_TIM6		223
+#define CK_KER_TIM7		224
+#define CK_KER_TIM10		225
+#define CK_KER_TIM11		226
+#define CK_KER_TIM12		227
+#define CK_KER_TIM13		228
+#define CK_KER_TIM14		229
+#define CK_KER_TIM1		230
+#define CK_KER_TIM8		231
+#define CK_KER_TIM15		232
+#define CK_KER_TIM16		233
+#define CK_KER_TIM17		234
+#define CK_KER_TIM20		235
+#define CK_BUS_SYSRAM		236
+#define CK_BUS_VDERAM		237
+#define CK_BUS_RETRAM		238
+#define CK_BUS_OSPI1		239
+#define CK_BUS_OSPI2		240
+#define CK_BUS_OTFD1		241
+#define CK_BUS_OTFD2		242
+#define CK_BUS_SRAM1		243
+#define CK_BUS_SRAM2		244
+#define CK_BUS_SDMMC1		245
+#define CK_BUS_SDMMC2		246
+#define CK_BUS_SDMMC3		247
+#define CK_BUS_DDR		248
+#define CK_BUS_RISAF4		249
+#define CK_BUS_USB2OHCI		250
+#define CK_BUS_USB2EHCI		251
+#define CK_BUS_USB3DR		252
+#define CK_KER_LPTIM1		253
+#define CK_KER_LPTIM2		254
+#define CK_KER_USART2		255
+#define CK_KER_UART4		256
+#define CK_KER_USART3		257
+#define CK_KER_UART5		258
+#define CK_KER_SPI2		259
+#define CK_KER_SPI3		260
+#define CK_KER_SPDIFRX		261
+#define CK_KER_I2C1		262
+#define CK_KER_I2C2		263
+#define CK_KER_I3C1		264
+#define CK_KER_I3C2		265
+#define CK_KER_I2C3		266
+#define CK_KER_I2C5		267
+#define CK_KER_I3C3		268
+#define CK_KER_I2C4		269
+#define CK_KER_I2C6		270
+#define CK_KER_I2C7		271
+#define CK_KER_SPI1		272
+#define CK_KER_SPI4		273
+#define CK_KER_SPI5		274
+#define CK_KER_SPI6		275
+#define CK_KER_SPI7		276
+#define CK_KER_USART1		277
+#define CK_KER_USART6		278
+#define CK_KER_UART7		279
+#define CK_KER_UART8		280
+#define CK_KER_UART9		281
+#define CK_KER_MDF1		282
+#define CK_KER_SAI1		283
+#define CK_KER_SAI2		284
+#define CK_KER_SAI3		285
+#define CK_KER_SAI4		286
+#define CK_KER_FDCAN		287
+#define CK_KER_DSIBLANE		288
+#define CK_KER_DSIPHY		289
+#define CK_KER_CSI		290
+#define CK_KER_CSITXESC		291
+#define CK_KER_CSIPHY		292
+#define CK_KER_LVDSPHY		293
+#define CK_KER_STGEN		294
+#define CK_KER_USB3PCIEPHY	295
+#define CK_KER_USB2PHY2EN	296
+#define CK_KER_I3C4		297
+#define CK_KER_SPI8		298
+#define CK_KER_I2C8		299
+#define CK_KER_LPUART1		300
+#define CK_KER_LPTIM3		301
+#define CK_KER_LPTIM4		302
+#define CK_KER_LPTIM5		303
+#define CK_KER_TSDBG		304
+#define CK_KER_TPIU		305
+#define CK_BUS_ETR		306
+#define CK_BUS_SYSATB		307
+#define CK_KER_ADC12		308
+#define CK_KER_ADC3		309
+#define CK_KER_OSPI1		310
+#define CK_KER_OSPI2		311
+#define CK_KER_FMC		312
+#define CK_KER_SDMMC1		313
+#define CK_KER_SDMMC2		314
+#define CK_KER_SDMMC3		315
+#define CK_KER_ETH1		316
+#define CK_KER_ETH2		317
+#define CK_KER_ETH1PTP		318
+#define CK_KER_ETH2PTP		319
+#define CK_KER_USB2PHY1		320
+#define CK_KER_USB2PHY2		321
+#define CK_KER_ETHSW		322
+#define CK_KER_ETHSWREF		323
+#define CK_MCO1			324
+#define CK_MCO2			325
+#define CK_KER_DTS		326
+#define CK_ETH1_RX		327
+#define CK_ETH1_TX		328
+#define CK_ETH1_MAC		329
+#define CK_ETH2_RX		330
+#define CK_ETH2_TX		331
+#define CK_ETH2_MAC		332
+#define CK_ETH1_STP		333
+#define CK_ETH2_STP		334
+#define CK_KER_USBTC		335
+#define CK_BUS_ADF1		336
+#define CK_KER_ADF1		337
+#define CK_BUS_LVDS		338
+#define CK_KER_LTDC		339
+#define CK_KER_GPU		340
+#define CK_BUS_ETHSWACMCFG	341
+#define CK_BUS_ETHSWACMMSG	342
+#define HSE_DIV2_CK		343
+
+#define STM32MP25_LAST_CLK	344
+
+#define CK_SCMI_ICN_HS_MCU	0
+#define CK_SCMI_ICN_SDMMC	1
+#define CK_SCMI_ICN_DDR		2
+#define CK_SCMI_ICN_DISPLAY	3
+#define CK_SCMI_ICN_HSL		4
+#define CK_SCMI_ICN_NIC		5
+#define CK_SCMI_ICN_VID		6
+#define CK_SCMI_FLEXGEN_07	7
+#define CK_SCMI_FLEXGEN_08	8
+#define CK_SCMI_FLEXGEN_09	9
+#define CK_SCMI_FLEXGEN_10	10
+#define CK_SCMI_FLEXGEN_11	11
+#define CK_SCMI_FLEXGEN_12	12
+#define CK_SCMI_FLEXGEN_13	13
+#define CK_SCMI_FLEXGEN_14	14
+#define CK_SCMI_FLEXGEN_15	15
+#define CK_SCMI_FLEXGEN_16	16
+#define CK_SCMI_FLEXGEN_17	17
+#define CK_SCMI_FLEXGEN_18	18
+#define CK_SCMI_FLEXGEN_19	19
+#define CK_SCMI_FLEXGEN_20	20
+#define CK_SCMI_FLEXGEN_21	21
+#define CK_SCMI_FLEXGEN_22	22
+#define CK_SCMI_FLEXGEN_23	23
+#define CK_SCMI_FLEXGEN_24	24
+#define CK_SCMI_FLEXGEN_25	25
+#define CK_SCMI_FLEXGEN_26	26
+#define CK_SCMI_FLEXGEN_27	27
+#define CK_SCMI_FLEXGEN_28	28
+#define CK_SCMI_FLEXGEN_29	29
+#define CK_SCMI_FLEXGEN_30	30
+#define CK_SCMI_FLEXGEN_31	31
+#define CK_SCMI_FLEXGEN_32	32
+#define CK_SCMI_FLEXGEN_33	33
+#define CK_SCMI_FLEXGEN_34	34
+#define CK_SCMI_FLEXGEN_35	35
+#define CK_SCMI_FLEXGEN_36	36
+#define CK_SCMI_FLEXGEN_37	37
+#define CK_SCMI_FLEXGEN_38	38
+#define CK_SCMI_FLEXGEN_39	39
+#define CK_SCMI_FLEXGEN_40	40
+#define CK_SCMI_FLEXGEN_41	41
+#define CK_SCMI_FLEXGEN_42	42
+#define CK_SCMI_FLEXGEN_43	43
+#define CK_SCMI_FLEXGEN_44	44
+#define CK_SCMI_FLEXGEN_45	45
+#define CK_SCMI_FLEXGEN_46	46
+#define CK_SCMI_FLEXGEN_47	47
+#define CK_SCMI_FLEXGEN_48	48
+#define CK_SCMI_FLEXGEN_49	49
+#define CK_SCMI_FLEXGEN_50	50
+#define CK_SCMI_FLEXGEN_51	51
+#define CK_SCMI_FLEXGEN_52	52
+#define CK_SCMI_FLEXGEN_53	53
+#define CK_SCMI_FLEXGEN_54	54
+#define CK_SCMI_FLEXGEN_55	55
+#define CK_SCMI_FLEXGEN_56	56
+#define CK_SCMI_FLEXGEN_57	57
+#define CK_SCMI_FLEXGEN_58	58
+#define CK_SCMI_FLEXGEN_59	59
+#define CK_SCMI_FLEXGEN_60	60
+#define CK_SCMI_FLEXGEN_61	61
+#define CK_SCMI_FLEXGEN_62	62
+#define CK_SCMI_FLEXGEN_63	63
+#define CK_SCMI_ICN_LS_MCU	64
+#define CK_SCMI_HSE		65
+#define CK_SCMI_LSE		66
+#define CK_SCMI_HSI		67
+#define CK_SCMI_LSI		68
+#define CK_SCMI_MSI		69
+#define CK_SCMI_HSE_DIV2	70
+#define CK_SCMI_CPU1		71
+#define CK_SCMI_SYSCPU1		72
+#define CK_SCMI_PLL2		73
+#define CK_SCMI_PLL3		74
+#define CK_SCMI_RTC		75
+#define CK_SCMI_RTCCK		76
+#define CK_SCMI_ICN_APB1	77
+#define CK_SCMI_ICN_APB2	78
+#define CK_SCMI_ICN_APB3	79
+#define CK_SCMI_ICN_APB4	80
+#define CK_SCMI_ICN_APBDBG	81
+#define CK_SCMI_TIMG1		82
+#define CK_SCMI_TIMG2		83
+#define CK_SCMI_BKPSRAM		84
+#define CK_SCMI_BSEC		85
+#define CK_SCMI_ETR		87
+#define CK_SCMI_FMC		88
+#define CK_SCMI_GPIOA		89
+#define CK_SCMI_GPIOB		90
+#define CK_SCMI_GPIOC		91
+#define CK_SCMI_GPIOD		92
+#define CK_SCMI_GPIOE		93
+#define CK_SCMI_GPIOF		94
+#define CK_SCMI_GPIOG		95
+#define CK_SCMI_GPIOH		96
+#define CK_SCMI_GPIOI		97
+#define CK_SCMI_GPIOJ		98
+#define CK_SCMI_GPIOK		99
+#define CK_SCMI_GPIOZ		100
+#define CK_SCMI_HPDMA1		101
+#define CK_SCMI_HPDMA2		102
+#define CK_SCMI_HPDMA3		103
+#define CK_SCMI_HSEM		104
+#define CK_SCMI_IPCC1		105
+#define CK_SCMI_IPCC2		106
+#define CK_SCMI_LPDMA		107
+#define CK_SCMI_RETRAM		108
+#define CK_SCMI_SRAM1		109
+#define CK_SCMI_SRAM2		110
+#define CK_SCMI_LPSRAM1		111
+#define CK_SCMI_LPSRAM2		112
+#define CK_SCMI_LPSRAM3		113
+#define CK_SCMI_VDERAM		114
+#define CK_SCMI_SYSRAM		115
+#define CK_SCMI_OSPI1		116
+#define CK_SCMI_OSPI2		117
+#define CK_SCMI_TPIU		118
+#define CK_SCMI_SYSDBG		119
+#define CK_SCMI_SYSATB		120
+#define CK_SCMI_TSDBG		121
+#define CK_SCMI_STM500		122
+
+#endif /* _DT_BINDINGS_STM32MP25_CLKS_H_ */
diff --git a/include/dt-bindings/reset/st,stm32mp25-rcc.h b/include/dt-bindings/reset/st,stm32mp25-rcc.h
new file mode 100644
index 000000000000..d5615930bcc8
--- /dev/null
+++ b/include/dt-bindings/reset/st,stm32mp25-rcc.h
@@ -0,0 +1,167 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
+/*
+ * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
+ * Author(s): Gabriel Fernandez <gabriel.fernandez at foss.st.com>
+ */
+
+#ifndef _DT_BINDINGS_STM32MP25_RESET_H_
+#define _DT_BINDINGS_STM32MP25_RESET_H_
+
+#define TIM1_R		0
+#define TIM2_R		1
+#define TIM3_R		2
+#define TIM4_R		3
+#define TIM5_R		4
+#define TIM6_R		5
+#define TIM7_R		6
+#define TIM8_R		7
+#define TIM10_R		8
+#define TIM11_R		9
+#define TIM12_R		10
+#define TIM13_R		11
+#define TIM14_R		12
+#define TIM15_R		13
+#define TIM16_R		14
+#define TIM17_R		15
+#define TIM20_R		16
+#define LPTIM1_R	17
+#define LPTIM2_R	18
+#define LPTIM3_R	19
+#define LPTIM4_R	20
+#define LPTIM5_R	21
+#define SPI1_R		22
+#define SPI2_R		23
+#define SPI3_R		24
+#define SPI4_R		25
+#define SPI5_R		26
+#define SPI6_R		27
+#define SPI7_R		28
+#define SPI8_R		29
+#define SPDIFRX_R	30
+#define USART1_R	31
+#define USART2_R	32
+#define USART3_R	33
+#define UART4_R		34
+#define UART5_R		35
+#define USART6_R	36
+#define UART7_R		37
+#define UART8_R		38
+#define UART9_R		39
+#define LPUART1_R	40
+#define IS2M_R		41
+#define I2C1_R		42
+#define I2C2_R		43
+#define I2C3_R		44
+#define I2C4_R		45
+#define I2C5_R		46
+#define I2C6_R		47
+#define I2C7_R		48
+#define I2C8_R		49
+#define SAI1_R		50
+#define SAI2_R		51
+#define SAI3_R		52
+#define SAI4_R		53
+#define MDF1_R		54
+#define MDF2_R		55
+#define FDCAN_R		56
+#define HDP_R		57
+#define ADC12_R		58
+#define ADC3_R		59
+#define ETH1_R		60
+#define ETH2_R		61
+#define USB2_R		62
+#define USB2PHY1_R	63
+#define USB2PHY2_R	64
+#define USB3DR_R	65
+#define USB3PCIEPHY_R	66
+#define USBTC_R		67
+#define ETHSW_R		68
+#define SDMMC1_R	69
+#define SDMMC1DLL_R	70
+#define SDMMC2_R	71
+#define SDMMC2DLL_R	72
+#define SDMMC3_R	73
+#define SDMMC3DLL_R	74
+#define GPU_R		75
+#define LTDC_R		76
+#define DSI_R		77
+#define LVDS_R		78
+#define CSI_R		79
+#define DCMIPP_R	80
+#define CCI_R		81
+#define VDEC_R		82
+#define VENC_R		83
+#define WWDG1_R		84
+#define WWDG2_R		85
+#define VREF_R		86
+#define DTS_R		87
+#define CRC_R		88
+#define SERC_R		89
+#define OSPIIOM_R	90
+#define I3C1_R		91
+#define I3C2_R		92
+#define I3C3_R		93
+#define I3C4_R		94
+#define IWDG2_KER_R	95
+#define IWDG4_KER_R	96
+#define RNG_R		97
+#define PKA_R		98
+#define SAES_R		99
+#define HASH_R		100
+#define CRYP1_R		101
+#define CRYP2_R		102
+#define PCIE_R		103
+#define OSPI1_R		104
+#define OSPI1DLL_R	105
+#define OSPI2_R		106
+#define OSPI2DLL_R	107
+#define FMC_R		108
+#define DBG_R		109
+#define GPIOA_R		110
+#define GPIOB_R		111
+#define GPIOC_R		112
+#define GPIOD_R		113
+#define GPIOE_R		114
+#define GPIOF_R		115
+#define GPIOG_R		116
+#define GPIOH_R		117
+#define GPIOI_R		118
+#define GPIOJ_R		119
+#define GPIOK_R		120
+#define GPIOZ_R		121
+#define HPDMA1_R	122
+#define HPDMA2_R	123
+#define HPDMA3_R	124
+#define LPDMA_R		125
+#define HSEM_R		126
+#define IPCC1_R		127
+#define IPCC2_R		128
+#define C2_HOLDBOOT_R	129
+#define C1_HOLDBOOT_R	130
+#define C1_R		131
+#define C1P1POR_R	132
+#define C1P1_R		133
+#define C2_R		134
+#define C3_R		135
+#define SYS_R		136
+#define VSW_R		137
+#define C1MS_R		138
+#define DDRCP_R		139
+#define DDRCAPB_R	140
+#define DDRPHYCAPB_R	141
+#define DDRCFG_R	142
+#define DDR_R		143
+
+#define STM32MP25_LAST_RESET	144
+
+#define RST_SCMI_C1_R		0
+#define RST_SCMI_C2_R		1
+#define RST_SCMI_C1_HOLDBOOT_R	2
+#define RST_SCMI_C2_HOLDBOOT_R	3
+#define RST_SCMI_FMC		4
+#define RST_SCMI_OSPI1		5
+#define RST_SCMI_OSPI1DLL	6
+#define RST_SCMI_OSPI2		7
+#define RST_SCMI_OSPI2DLL	8
+
+#endif /* _DT_BINDINGS_STM32MP25_RESET_H_ */
-- 
2.25.1



From gregor.herburger at ew.tq-group.com  Wed Dec  6 06:01:01 2023
From: gregor.herburger at ew.tq-group.com (Gregor Herburger)
Date: Wed, 06 Dec 2023 15:01:01 +0100
Subject: [PATCH 1/2] dt-bindings: arm: fsl: Add TQ-Systems LX2160A based
 boards
In-Reply-To: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>
References: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>
Message-ID: <20231206-for-ml-tqmlx2160a-v1-1-622e41ae4d8e@ew.tq-group.com>

TQMLX2160A is a TQ-Systems GmbH SoM using the LX2160A SoC.
MBLX2160a is the starterkit baseboard for TQMLX2160A.

Signed-off-by: Gregor Herburger <gregor.herburger at ew.tq-group.com>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 32b195852a75..97413df64f55 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1476,6 +1476,16 @@ properties:
           - const: solidrun,lx2162a-som
           - const: fsl,lx2160a
 
+      - description:
+          TQ-Systems TQMLX2160A is a series of socketable SOM featuring
+          LX2160A system-on-chip variants. MBLX2160A mainboard can be used a
+          starterkit.
+        items:
+          - enum:
+              - tq,lx2160a-tqmlx2160a-mblx2160a
+          - const: tq,lx2160a-tqmlx2160a
+          - const: fsl,lx2160a
+
       - description: S32G2 based Boards
         items:
           - enum:

-- 
2.34.1



From gregor.herburger at ew.tq-group.com  Wed Dec  6 06:01:00 2023
From: gregor.herburger at ew.tq-group.com (Gregor Herburger)
Date: Wed, 06 Dec 2023 15:01:00 +0100
Subject: [PATCH 0/2] TQMLX2160A support
Message-ID: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>

Hi,

this series adds initial support for the TQMLX2160A SoM on MBLX2160a
baseboard. The various supported Serdes Configurations are added with
overlay files.

Patch 1 adds the compatible to dt bindings
Patch 2 adds the dts files

---
Gregor Herburger (2):
      dt-bindings: arm: fsl: Add TQ-Systems LX2160A based boards
      arm64: dts: freescale: add fsl-lx2160a-mblx2160a board

 Documentation/devicetree/bindings/arm/fsl.yaml     |  10 +
 arch/arm64/boot/dts/freescale/Makefile             |  26 ++
 .../freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 338 +++++++++++++++++++++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtso   |  29 ++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtso   |  17 ++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso   |  49 +++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso    |  55 ++++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtso    |  47 +++
 .../boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi |  97 ++++++
 9 files changed, 668 insertions(+)
---
base-commit: 8728c14129df7a6e29188a2e737b4774fb200953
change-id: 20231206-for-ml-tqmlx2160a-68ee235f71cd

Best regards,
-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
https://www.tq-group.com/



From gregor.herburger at ew.tq-group.com  Wed Dec  6 06:01:02 2023
From: gregor.herburger at ew.tq-group.com (Gregor Herburger)
Date: Wed, 06 Dec 2023 15:01:02 +0100
Subject: [PATCH 2/2] arm64: dts: freescale: add fsl-lx2160a-mblx2160a board
In-Reply-To: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>
References: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>
Message-ID: <20231206-for-ml-tqmlx2160a-v1-2-622e41ae4d8e@ew.tq-group.com>

Add the different serdes configurations as overlays.

Signed-off-by: Gregor Herburger <gregor.herburger at ew.tq-group.com>
---
 arch/arm64/boot/dts/freescale/Makefile             |  26 ++
 .../freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 338 +++++++++++++++++++++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtso   |  29 ++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtso   |  17 ++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso   |  49 +++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso    |  55 ++++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtso    |  47 +++
 .../boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi |  97 ++++++
 8 files changed, 658 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 300049037eb0..cc30e6dc9f64 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -53,6 +53,32 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds-85bb.dtb
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds-899b.dtb
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds-9999.dtb
 
+fsl-lx2160a-tqmlx2160a-mblx2160a-12-11-x-dtbs := fsl-lx2160a-tqmlx2160a-mblx2160a.dtb \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtbo \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtbo
+fsl-lx2160a-tqmlx2160a-mblx2160a-12-7-x-dtbs := fsl-lx2160a-tqmlx2160a-mblx2160a.dtb \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtbo \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtbo
+fsl-lx2160a-tqmlx2160a-mblx2160a-12-8-x-dtbs := fsl-lx2160a-tqmlx2160a-mblx2160a.dtb \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtbo \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtbo
+fsl-lx2160a-tqmlx2160a-mblx2160a-14-7-x-dtbs := fsl-lx2160a-tqmlx2160a-mblx2160a.dtb \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtbo \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtbo
+fsl-lx2160a-tqmlx2160a-mblx2160a-14-8-x-dtbs := fsl-lx2160a-tqmlx2160a-mblx2160a.dtb \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtbo \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtbo
+fsl-lx2160a-tqmlx2160a-mblx2160a-14-11-x-dtbs := fsl-lx2160a-tqmlx2160a-mblx2160a.dtb \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtbo \
+	fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtbo
+
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-tqmlx2160a-mblx2160a-12-11-x.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-tqmlx2160a-mblx2160a-12-8-x.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-tqmlx2160a-mblx2160a-12-7-x.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-tqmlx2160a-mblx2160a-14-11-x.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-tqmlx2160a-mblx2160a-14-8-x.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-tqmlx2160a-mblx2160a-14-7-x.dtb
+
 dtb-$(CONFIG_ARCH_MXC) += imx8dxl-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-data-modul-edm-sbc.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
new file mode 100644
index 000000000000..da0f58e26b9a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
@@ -0,0 +1,338 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2020-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Gregor Herburger
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/net/ti-dp83867.h>
+
+#include "fsl-lx2160a-tqmlx2160a.dtsi"
+
+/ {
+	model = "TQ Systems GmbH MBLX2160A Starterkit";
+	compatible = "tq,lx2160a-tqmlx2160a-mblx2160a", "tq,lx2160a-tqmlx2160a",
+		     "fsl,lx2160a";
+
+	aliases {
+		mmc0 = &esdhc0;
+		mmc1 = &esdhc1;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	chosen {
+		stdout-path = &uart0;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		button-user1 {
+			label = "button:user1";
+			gpios = <&gpio2 9 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_F1>;
+		};
+
+		button-user2 {
+			label = "button:user2";
+			gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_F2>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-user1 {
+			gpios = <&gpioex1 15 GPIO_ACTIVE_LOW>;
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_HEARTBEAT;
+			function-enumerator = <0>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led-user2 {
+			gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_HEARTBEAT;
+			function-enumerator = <1>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	sfp_xfi1: sfp-xfi1 {
+		compatible = "sff,sfp";
+		i2c-bus = <&xfi1_i2c>;
+		mod-def0-gpios = <&gpioex2 2 GPIO_ACTIVE_LOW>;
+		los-gpios = <&gpioex2 3 GPIO_ACTIVE_HIGH>;
+		tx-fault-gpios = <&gpioex2 0 GPIO_ACTIVE_HIGH>;
+		tx-disable-gpios = <&gpioex2 1 GPIO_ACTIVE_HIGH>;
+		status = "disabled";
+	};
+
+	sfp_xfi2: sfp-xfi2 {
+		compatible = "sff,sfp";
+		i2c-bus = <&xfi2_i2c>;
+		mod-def0-gpios = <&gpioex2 6 GPIO_ACTIVE_LOW>;
+		los-gpios = <&gpioex2 7 GPIO_ACTIVE_HIGH>;
+		tx-fault-gpios = <&gpioex2 4 GPIO_ACTIVE_HIGH>;
+		tx-disable-gpios = <&gpioex2 5 GPIO_ACTIVE_HIGH>;
+		status = "disabled";
+	};
+};
+
+&can0 {
+	status = "okay";
+};
+
+&can1 {
+	status = "okay";
+};
+
+&dpmac17 {
+	phy-handle = <&dp83867_2_3>;
+	phy-connection-type = "rgmii-id";
+};
+
+&dpmac18 {
+	phy-handle = <&dp83867_2_4>;
+	phy-connection-type = "rgmii-id";
+};
+
+&emdio1 {
+	status = "okay";
+
+	dp83867_1_1: ethernet-phy at 1 {
+		reg = <1>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+
+	dp83867_1_2: ethernet-phy at 2 {
+		reg = <2>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+
+	dp83867_1_3: ethernet-phy at 3 {
+		reg = <3>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+
+	dp83867_1_4: ethernet-phy at 4 {
+		reg = <4>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+
+	dp83867_1_5: ethernet-phy at 5 {
+		reg = <5>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+
+	dp83867_1_6: ethernet-phy at 6 {
+		reg = <6>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+};
+
+&emdio2 {
+	status = "okay";
+
+	dp83867_2_1: ethernet-phy at 1 {
+		reg = <1>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+
+	dp83867_2_2: ethernet-phy at 2 {
+		reg = <2>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+
+	dp83867_2_3: ethernet-phy at 3 {
+		reg = <3>;
+		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+		ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+
+	dp83867_2_4: ethernet-phy at 4 {
+		reg = <4>;
+		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+		ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+		ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+	};
+};
+
+&esdhc0 {
+	sd-uhs-sdr104;
+	sd-uhs-sdr50;
+	sd-uhs-sdr25;
+	sd-uhs-sdr12;
+	no-mmc;
+	no-sdio;
+	wp-gpios = <&gpio0 30 GPIO_ACTIVE_LOW>;
+	cd-gpios = <&gpio0 31 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&i2c0 {
+	gpioex3: gpio at 20 {
+		compatible = "nxp,pca9555";
+		reg = <0x20>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		vcc-supply = <&reg_vcc3v3>;
+	};
+};
+
+&i2c4 {
+	status = "okay";
+
+	mux at 70 {
+		compatible = "nxp,pca9544";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		vdd-supply = <&reg_vcc3v3>;
+
+		i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c at 1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c at 2 {
+			reg = <2>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			gpioex0: gpio at 20 {
+				compatible = "nxp,pca9555";
+				reg = <0x20>;
+				#gpio-cells = <2>;
+				gpio-controller;
+				vcc-supply = <&reg_vcc3v3>;
+			};
+
+			gpioex1: gpio at 21 {
+				compatible = "nxp,pca9555";
+				reg = <0x21>;
+				#gpio-cells = <2>;
+				gpio-controller;
+				vcc-supply = <&reg_vcc3v3>;
+			};
+
+			gpioex2: gpio at 22 {
+				compatible = "nxp,pca9555";
+				reg = <0x22>;
+				#gpio-cells = <2>;
+				gpio-controller;
+				vcc-supply = <&reg_vcc3v3>;
+			};
+		};
+
+		i2c at 3 {
+			reg = <3>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+};
+
+&i2c5 {
+	status = "okay";
+
+	mux at 70 {
+		compatible = "nxp,pca9544";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		vdd-supply = <&reg_vcc3v3>;
+
+		i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		xfi1_i2c: i2c at 1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		xfi2_i2c: i2c at 2 {
+			reg = <2>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c at 3 {
+			reg = <3>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+};
+
+&pcs_mdio17 {
+	status = "okay";
+};
+
+&pcs_mdio18 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&uart3 {
+	status = "okay";
+};
+
+&usb0 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	hub_2_0: hub at 1 {
+		compatible = "usb451,8142";
+		reg = <1>;
+		peer-hub = <&hub_3_0>;
+		reset-gpios = <&gpioex1 0 GPIO_ACTIVE_LOW>;
+		vcc-supply = <&reg_vcc3v3>;
+	};
+
+	hub_3_0: hub at 2 {
+		compatible = "usb451,8140";
+		reg = <2>;
+		peer-hub = <&hub_2_0>;
+		reset-gpios = <&gpioex1 0 GPIO_ACTIVE_LOW>;
+		vcc-supply = <&reg_vcc3v3>;
+	};
+};
+
+&usb1 {
+	dr_mode = "otg";
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtso
new file mode 100644
index 000000000000..8284a564e20d
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtso
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2020-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Gregor Herburger
+ */
+
+/dts-v1/;
+/plugin/;
+
+&dpmac9 {
+	phy-handle = <&dp83867_2_1>;
+	phy-connection-type = "sgmii";
+	managed = "in-band-status";
+};
+
+&dpmac10 {
+	phy-handle = <&dp83867_2_2>;
+	phy-connection-type = "sgmii";
+	managed = "in-band-status";
+};
+
+&pcs_mdio9 {
+	status = "okay";
+};
+
+&pcs_mdio10 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtso
new file mode 100644
index 000000000000..636b17a383ed
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtso
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2020-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Gregor Herburger
+ */
+
+/dts-v1/;
+/plugin/;
+
+&dpmac1 {
+	managed = "in-band-status";
+};
+
+&pcs_mdio1 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
new file mode 100644
index 000000000000..6d0c808cd840
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2020-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Gregor Herburger
+ */
+
+/dts-v1/;
+/plugin/;
+
+&dpmac12 {
+	phy-handle = <&dp83867_1_1>;
+	phy-connection-type = "sgmii";
+	managed = "in-band-status";
+};
+
+&dpmac13 {
+	phy-handle = <&dp83867_1_5>;
+	phy-connection-type = "sgmii";
+	managed = "in-band-status";
+};
+
+&dpmac14 {
+	phy-handle = <&dp83867_1_6>;
+	phy-connection-type = "sgmii";
+	managed = "in-band-status";
+};
+
+&dpmac16 {
+	phy-handle = <&dp83867_1_4>;
+	phy-connection-type = "sgmii";
+	managed = "in-band-status";
+};
+
+&pcs_mdio12 {
+	status = "okay";
+};
+
+&pcs_mdio13 {
+	status = "okay";
+};
+
+&pcs_mdio14 {
+	status = "okay";
+};
+
+&pcs_mdio16 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
new file mode 100644
index 000000000000..db88a86ff69c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2020-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Gregor Herburger
+ */
+
+/dts-v1/;
+/plugin/;
+
+&dpmac12 {
+	phy-handle = <&dp83867_1_1>;
+	phy-connection-type = "sgmii";
+	managed = "in-band-status";
+};
+
+&dpmac13 {
+	sfp = <&sfp_xfi1>;
+	managed = "in-band-status";
+};
+
+&dpmac14 {
+	sfp = <&sfp_xfi2>;
+	managed = "in-band-status";
+};
+
+&dpmac16 {
+	phy-handle = <&dp83867_1_4>;
+	phy-connection-type = "sgmii";
+	managed = "in-band-status";
+};
+
+&pcs_mdio12 {
+	status = "okay";
+};
+
+&pcs_mdio13 {
+	status = "okay";
+};
+
+&pcs_mdio14 {
+	status = "okay";
+};
+
+&pcs_mdio16 {
+	status = "okay";
+};
+
+&sfp_xfi1 {
+	status = "okay";
+};
+
+&sfp_xfi2 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtso
new file mode 100644
index 000000000000..f6dfa76aa0e7
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtso
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2020-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Gregor Herburger
+ */
+
+/dts-v1/;
+/plugin/;
+
+&dpmac13 {
+	sfp = <&sfp_xfi1>;
+	managed = "in-band-status";
+};
+
+&dpmac14 {
+	sfp = <&sfp_xfi2>;
+	managed = "in-band-status";
+};
+
+&pcs_mdio13 {
+	status = "okay";
+};
+
+&pcs_mdio14 {
+	status = "okay";
+};
+
+&sata0 {
+	status = "okay";
+};
+
+&sata1 {
+	status = "okay";
+};
+
+&sata2 {
+	status = "okay";
+};
+
+&sfp_xfi1 {
+	status = "okay";
+};
+
+&sfp_xfi2 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
new file mode 100644
index 000000000000..89a4765737b4
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2020-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Gregor Herburger
+ */
+
+#include "fsl-lx2160a.dtsi"
+
+/ {
+	reg_vcc3v3: regulator-vcc3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "VCC3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+};
+
+
+&emdio1 {
+	status = "okay";
+};
+
+&emdio2 {
+	status = "okay";
+};
+
+&esdhc1 {
+	bus-width = <8>;
+	no-sd;
+	no-sdio;
+	non-removable;
+	mmc-hs200-1_8v;
+	status = "okay";
+};
+
+&fspi {
+	status = "okay";
+
+	flash0: flash at 0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		spi-max-frequency = <10000000>;
+		spi-rx-bus-width = <1>;
+		spi-tx-bus-width = <1>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+		};
+	};
+
+	flash1: flash at 1 {
+		compatible = "jedec,spi-nor";
+		reg = <1>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		spi-max-frequency = <10000000>;
+		spi-rx-bus-width = <1>;
+		spi-tx-bus-width = <1>;
+	};
+};
+
+&i2c0 {
+	scl-gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	sensor0: temperature-sensor at 1f {
+		compatible = "nxp,se97", "jedec,jc-42.4-temp";
+		reg = <0x1f>;
+	};
+
+	eeprom1: eeprom at 57 {
+		compatible = "atmel,24c02";
+		reg = <0x57>;
+		pagesize = <16>;
+		read-only;
+		vcc-supply = <&reg_vcc3v3>;
+	};
+
+	rtc: rtc at 51 {
+		compatible = "nxp,pcf85063a";
+		reg = <0x51>;
+		quartz-load-femtofarads = <12500>;
+	};
+
+	eeprom2: eeprom at 50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+		pagesize = <32>;
+		vcc-supply = <&reg_vcc3v3>;
+	};
+};

-- 
2.34.1



From gabriel.fernandez at foss.st.com  Wed Dec  6 06:00:29 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Wed, 6 Dec 2023 15:00:29 +0100
Subject: [PATCH v5 5/5] arm64: dts: st: add rcc support in stm32mp251
In-Reply-To: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
References: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231206140029.492906-6-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Add RCC support to manage clocks and resets on the STM32MP251.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 59 ++++++++++++++------------
 1 file changed, 31 insertions(+), 28 deletions(-)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 124403f5f1f4..dfbdb3a773e4 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -3,7 +3,9 @@
  * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
  * Author: Alexandre Torgue <alexandre.torgue at foss.st.com> for STMicroelectronics.
  */
+#include <dt-bindings/clock/st,stm32mp25-rcc.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset/st,stm32mp25-rcc.h>
 
 / {
 	#address-cells = <2>;
@@ -35,22 +37,10 @@ arm_wdt: watchdog {
 	};
 
 	clocks {
-		ck_flexgen_08: ck-flexgen-08 {
+		clk_rcbsec: clk-rcbsec {
 			#clock-cells = <0>;
 			compatible = "fixed-clock";
-			clock-frequency = <100000000>;
-		};
-
-		ck_flexgen_51: ck-flexgen-51 {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <200000000>;
-		};
-
-		ck_icn_ls_mcu: ck-icn-ls-mcu {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <200000000>;
+			clock-frequency = <64000000>;
 		};
 	};
 
@@ -122,7 +112,7 @@ usart2: serial at 400e0000 {
 				compatible = "st,stm32h7-uart";
 				reg = <0x400e0000 0x400>;
 				interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&ck_flexgen_08>;
+				clocks = <&rcc CK_KER_USART2>;
 				status = "disabled";
 			};
 
@@ -131,7 +121,7 @@ sdmmc1: mmc at 48220000 {
 				arm,primecell-periphid = <0x00353180>;
 				reg = <0x48220000 0x400>, <0x44230400 0x8>;
 				interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&ck_flexgen_51>;
+				clocks = <&rcc CK_KER_SDMMC1 >;
 				clock-names = "apb_pclk";
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
@@ -140,6 +130,19 @@ sdmmc1: mmc at 48220000 {
 			};
 		};
 
+		rcc: clock-controller at 44200000 {
+			compatible = "st,stm32mp25-rcc";
+			reg = <0x44200000 0x10000>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+			clock-names = "hse", "hsi", "msi", "lse", "lsi";
+			clocks = <&scmi_clk CK_SCMI_HSE>,
+				<&scmi_clk CK_SCMI_HSI>,
+				<&scmi_clk CK_SCMI_MSI>,
+				<&scmi_clk CK_SCMI_LSE>,
+				<&scmi_clk CK_SCMI_LSI>;
+		};
+
 		syscfg: syscon at 44230000 {
 			compatible = "st,stm32mp25-syscfg", "syscon";
 			reg = <0x44230000 0x10000>;
@@ -158,7 +161,7 @@ gpioa: gpio at 44240000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x0 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOA>;
 				st,bank-name = "GPIOA";
 				status = "disabled";
 			};
@@ -169,7 +172,7 @@ gpiob: gpio at 44250000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x10000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOB>;
 				st,bank-name = "GPIOB";
 				status = "disabled";
 			};
@@ -180,7 +183,7 @@ gpioc: gpio at 44260000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x20000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOC>;
 				st,bank-name = "GPIOC";
 				status = "disabled";
 			};
@@ -191,7 +194,7 @@ gpiod: gpio at 44270000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x30000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOD>;
 				st,bank-name = "GPIOD";
 				status = "disabled";
 			};
@@ -202,7 +205,7 @@ gpioe: gpio at 44280000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x40000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOE>;
 				st,bank-name = "GPIOE";
 				status = "disabled";
 			};
@@ -213,7 +216,7 @@ gpiof: gpio at 44290000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x50000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOF>;
 				st,bank-name = "GPIOF";
 				status = "disabled";
 			};
@@ -224,7 +227,7 @@ gpiog: gpio at 442a0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x60000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOG>;
 				st,bank-name = "GPIOG";
 				status = "disabled";
 			};
@@ -235,7 +238,7 @@ gpioh: gpio at 442b0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x70000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOH>;
 				st,bank-name = "GPIOH";
 				status = "disabled";
 			};
@@ -246,7 +249,7 @@ gpioi: gpio at 442c0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x80000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOI>;
 				st,bank-name = "GPIOI";
 				status = "disabled";
 			};
@@ -257,7 +260,7 @@ gpioj: gpio at 442d0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x90000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOJ>;
 				st,bank-name = "GPIOJ";
 				status = "disabled";
 			};
@@ -268,7 +271,7 @@ gpiok: gpio at 442e0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0xa0000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOK>;
 				st,bank-name = "GPIOK";
 				status = "disabled";
 			};
@@ -287,7 +290,7 @@ gpioz: gpio at 46200000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOZ>;
 				st,bank-name = "GPIOZ";
 				st,bank-ioport = <11>;
 				status = "disabled";
-- 
2.25.1



From quic_mnaresh at quicinc.com  Wed Dec  6 06:02:54 2023
From: quic_mnaresh at quicinc.com (Naresh Maramaina)
Date: Wed, 6 Dec 2023 19:32:54 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <5e7c5c75-cb5f-4afe-9d57-b0cab01a6f26@acm.org>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
 <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>
 <5e7c5c75-cb5f-4afe-9d57-b0cab01a6f26@acm.org>
Message-ID: <b9373252-710c-4a54-95cc-046314796960@quicinc.com>



On 12/5/2023 10:41 PM, Bart Van Assche wrote:
> On 12/4/23 21:58, Naresh Maramaina wrote:
>> On 12/5/2023 12:30 AM, Bart Van Assche wrote:
>>> On 12/4/23 06:30, Maramaina Naresh wrote:
>>>> +??? /* This capability allows the host controller driver to use the 
>>>> PM QoS
>>>> +???? * feature.
>>>> +???? */
>>>> +??? UFSHCD_CAP_PM_QOS??????????????? = 1 << 13,
>>>> ? };
>>>
>>> Why does it depend on the host driver whether or not PM QoS is
>>> enabled? Why isn't it enabled unconditionally?
>>
>> For some platform vendors power KPI might be more important than 
>> random io KPI. Hence this flag is disabled by default and can be 
>> enabled based on platform requirement.
> 
> How about leaving this flag out unless if a host vendor asks explicitly
> for this flag?

IMHO, instead of completely removing this flag, how about having
flag like "UFSHCD_CAP_DISABLE_PM_QOS" which will make PMQOS enable
by default and if some host vendor wants to disable it explicitly,
they can enable that flag.
Please let me know your opinion.

>>>
>>>> + * @pm_qos_req: PM QoS request handle
>>>> + * @pm_qos_init: flag to check if pm qos init completed
>>>> ?? */
>>>
>>> Documentation for pm_qos_init is missing.
>>>
>> Sorry, i didn't get your comment, i have already added documentation 
>> for @pm_qos_init, @pm_qos_req variable as above. Do you want me to add 
>> this information some where else as well?
> 
> Oops, I meant 'qos_vote'.

Sure. I'll take of this in next patchset.

> 
> Thanks,
> 
> Bart.
> 

Thanks,
Naresh


From cniedermaier at dh-electronics.com  Wed Dec  6 06:06:56 2023
From: cniedermaier at dh-electronics.com (Christoph Niedermaier)
Date: Wed, 6 Dec 2023 14:06:56 +0000
Subject: [PATCH] serial: imx: Fix clock imbalance
In-Reply-To: <20231205005108.79782-1-marex@denx.de>
References: <20231205005108.79782-1-marex@denx.de>
Message-ID: <bd165a300edc44c09d078d1e778ddfe9@dh-electronics.com>

From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Marek Vasut
Sent: Tuesday, December 5, 2023 1:51 AM
> Disable and unprepare the clock on every exit from probe function
> after the clock were prepared and enabled to avoid enable/disable
> imbalance.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> ---
> Cc: "Ilpo J?rvinen" <ilpo.jarvinen at linux.intel.com>
> Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Jiri Slaby <jirislaby at kernel.org>
> Cc: NXP Linux Team <linux-imx at nxp.com>
> Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> Cc: Rob Herring <robh at kernel.org>
> Cc: Sascha Hauer <s.hauer at pengutronix.de>
> Cc: Sergey Organov <sorganov at gmail.com>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Tom Rix <trix at redhat.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-serial at vger.kernel.org
> ---
>  drivers/tty/serial/imx.c | 18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 52dd8a6b87603..1cce66e5d05d8 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -2332,10 +2332,8 @@ static int imx_uart_probe(struct platform_device *pdev)
>         }
> 
>         ret = uart_get_rs485_mode(&sport->port);
> -       if (ret) {
> -               clk_disable_unprepare(sport->clk_ipg);
> -               return ret;
> -       }
> +       if (ret)
> +               goto err_clk;
> 
>         if (sport->port.rs485.flags & SER_RS485_ENABLED &&
>             (!sport->have_rtscts && !sport->have_rtsgpio))
> @@ -2436,7 +2434,7 @@ static int imx_uart_probe(struct platform_device *pdev)
>                 if (ret) {
>                         dev_err(&pdev->dev, "failed to request rx irq: %d\n",
>                                 ret);
> -                       return ret;
> +                       goto err_clk;
>                 }
> 
>                 ret = devm_request_irq(&pdev->dev, txirq, imx_uart_txint, 0,
> @@ -2444,7 +2442,7 @@ static int imx_uart_probe(struct platform_device *pdev)
>                 if (ret) {
>                         dev_err(&pdev->dev, "failed to request tx irq: %d\n",
>                                 ret);
> -                       return ret;
> +                       goto err_clk;
>                 }
> 
>                 ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
> @@ -2452,14 +2450,14 @@ static int imx_uart_probe(struct platform_device *pdev)
>                 if (ret) {
>                         dev_err(&pdev->dev, "failed to request rts irq: %d\n",
>                                 ret);
> -                       return ret;
> +                       goto err_clk;
>                 }
>         } else {
>                 ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
>                                        dev_name(&pdev->dev), sport);
>                 if (ret) {
>                         dev_err(&pdev->dev, "failed to request irq: %d\n", ret);
> -                       return ret;
> +                       goto err_clk;
>                 }
>         }
> 
> @@ -2468,6 +2466,10 @@ static int imx_uart_probe(struct platform_device *pdev)
>         platform_set_drvdata(pdev, sport);
> 
>         return uart_add_one_port(&imx_uart_uart_driver, &sport->port);
> +
> +err_clk:
> +       clk_disable_unprepare(sport->clk_ipg);
> +       return ret;
>  }
> 
>  static void imx_uart_remove(struct platform_device *pdev)

Reviewed-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>

Regards
Christoph

From ryan.roberts at arm.com  Wed Dec  6 06:19:57 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 6 Dec 2023 14:19:57 +0000
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
Message-ID: <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>

On 05/12/2023 16:32, David Hildenbrand wrote:
> On 04.12.23 11:20, Ryan Roberts wrote:
>> Introduce the logic to allow THP to be configured (through the new sysfs
>> interface we just added) to allocate large folios to back anonymous
>> memory, which are larger than the base page size but smaller than
>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>>
>> mTHP continues to be PTE-mapped, but in many cases can still provide
>> similar benefits to traditional PMD-sized THP: Page faults are
>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
>> the configured order), but latency spikes are much less prominent
>> because the size of each page isn't as huge as the PMD-sized variant and
>> there is less memory to clear in each page fault. The number of per-page
>> operations (e.g. ref counting, rmap management, lru list management) are
>> also significantly reduced since those ops now become per-folio.
>>
>> Some architectures also employ TLB compression mechanisms to squeeze
>> more entries in when a set of PTEs are virtually and physically
>> contiguous and approporiately aligned. In this case, TLB misses will
>> occur less often.
>>
>> The new behaviour is disabled by default, but can be enabled at runtime
>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
>> (see documentation in previous commit). The long term aim is to change
>> the default to include suitable lower orders, but there are some risks
>> around internal fragmentation that need to be better understood first.
>>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> 
> In general, looks good to me, some comments/nits. And the usual "let's make sure
> we don't degrade order-0 and keep that as fast as possible" comment.
> 
>> ---
>> ? include/linux/huge_mm.h |?? 6 ++-
>> ? mm/memory.c???????????? | 106 ++++++++++++++++++++++++++++++++++++----
>> ? 2 files changed, 101 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> index bd0eadd3befb..91a53b9835a4 100644
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>> ? #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>> ? ? /*
>> - * Mask of all large folio orders supported for anonymous THP.
>> + * Mask of all large folio orders supported for anonymous THP; all orders up to
>> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
>> + * (which is a limitation of the THP implementation).
>> ?? */
>> -#define THP_ORDERS_ALL_ANON??? BIT(PMD_ORDER)
>> +#define THP_ORDERS_ALL_ANON??? ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>> ? ? /*
>> ?? * Mask of all large folio orders supported for file THP.
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 3ceeb0f45bf5..bf7e93813018 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>> ????? return ret;
>> ? }
>> ? +static bool pte_range_none(pte_t *pte, int nr_pages)
>> +{
>> +??? int i;
>> +
>> +??? for (i = 0; i < nr_pages; i++) {
>> +??????? if (!pte_none(ptep_get_lockless(pte + i)))
>> +??????????? return false;
>> +??? }
>> +
>> +??? return true;
>> +}
>> +
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>> +{
>> +??? gfp_t gfp;
>> +??? pte_t *pte;
>> +??? unsigned long addr;
>> +??? struct folio *folio;
>> +??? struct vm_area_struct *vma = vmf->vma;
>> +??? unsigned long orders;
>> +??? int order;
> 
> Nit: reverse christmas tree encouraged ;)

ACK will fix.

> 
>> +
>> +??? /*
>> +???? * If uffd is active for the vma we need per-page fault fidelity to
>> +???? * maintain the uffd semantics.
>> +???? */
>> +??? if (userfaultfd_armed(vma))
> 
> Nit: unlikely()

ACK will fix.

> 
>> +??????? goto fallback;
>> +
>> +??? /*
>> +???? * Get a list of all the (large) orders below PMD_ORDER that are enabled
>> +???? * for this vma. Then filter out the orders that can't be allocated over
>> +???? * the faulting address and still be fully contained in the vma.
>> +???? */
>> +??? orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
>> +????????????????????? BIT(PMD_ORDER) - 1);
>> +??? orders = thp_vma_suitable_orders(vma, vmf->address, orders);
> 
> Comment: Both will eventually loop over all orders, correct? Could eventually be
> sped up in the future.

No only thp_vma_suitable_orders() will loop. thp_vma_allowable_orders() only
loops if in_pf=false (it's true here).

> 
> Nit: the orders = ... order = ... looks like this might deserve a helper
> function that makes this easier to read.

To be honest, the existing function that I've modified is a bit of a mess.
thp_vma_allowable_orders() calls thp_vma_suitable_orders() if we are not in a
page fault, because the page fault handlers already do that check themselves. It
would be nice to refactor the whole thing so that thp_vma_allowable_orders() is
a strict superset of thp_vma_suitable_orders(). Then this can just call
thp_vma_allowable_orders(). But that's going to start touching the PMD and PUD
handlers, so prefer if we leave that for a separate patch set.

> 
> Nit: Why call thp_vma_suitable_orders if the orders are already 0? Again, some
> helper might be reasonable where that is handled internally.

Because thp_vma_suitable_orders() will handle it safely and is inline, so it
should just as efficient? This would go away with the refactoring described above.

> 
> Comment: For order-0 we'll always perform a function call to both
> thp_vma_allowable_orders() / thp_vma_suitable_orders(). We should perform some
> fast and efficient check if any <PMD THP are even enabled in the system / for
> this VMA, and in that case just fallback before doing more expensive checks.

thp_vma_allowable_orders() is inline as you mentioned.

I was deliberately trying to keep all the decision logic in one place
(thp_vma_suitable_orders) because it's already pretty complicated. But if you
insist, how about this in the header:

static inline
unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
				       unsigned long vm_flags, bool smaps,
				       bool in_pf, bool enforce_sysfs,
				       unsigned long orders)
{
	/* Optimization to check if required orders are enabled early. */
	if (enforce_sysfs && vma_is_anonymous(vma)) {
		unsigned long mask = READ_ONCE(huge_anon_orders_always);

		if (vm_flags & VM_HUGEPAGE)
			mask |= READ_ONCE(huge_anon_orders_madvise);
		if (hugepage_global_always() ||
			((vm_flags & VM_HUGEPAGE) && hugepage_global_enabled()))
			mask |= READ_ONCE(huge_anon_orders_inherit);

		orders &= mask;
		if (!orders)
			return 0;
		
		enforce_sysfs = false;
	}

	return __thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf,
					  enforce_sysfs, orders);
}

Then the above check can be removed from __thp_vma_allowable_orders() - it will
still retain the `if (enforce_sysfs && !vma_is_anonymous(vma))` part.


> 
>> +
>> +??? if (!orders)
>> +??????? goto fallback;
>> +
>> +??? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>> +??? if (!pte)
>> +??????? return ERR_PTR(-EAGAIN);
>> +
>> +??? order = first_order(orders);
>> +??? while (orders) {
>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>> +??????? vmf->pte = pte + pte_index(addr);
>> +??????? if (pte_range_none(vmf->pte, 1 << order))
>> +??????????? break;
> 
> Comment: Likely it would make sense to scan only once and determine the "largest
> none range" around that address, having the largest suitable order in mind.

Yes, that's how I used to do it, but Yu Zhou requested simplifying to this,
IIRC. Perhaps this an optimization opportunity for later?

> 
>> +??????? order = next_order(&orders, order);
>> +??? }
>> +
>> +??? vmf->pte = NULL;
> 
> Nit: Can you elaborate why you are messing with vmf->pte here? A simple helper
> variable will make this code look less magical. Unless I am missing something
> important :)

Gahh, I used to pass the vmf to what pte_range_none() was refactored into (an
approach that was suggested by Yu Zhou IIRC). But since I did some refactoring
based on some comments from JohnH, I see I don't need that anymore. Agreed; it
will be much clearer just to use a local variable. Will fix.

> 
>> +??? pte_unmap(pte);
>> +
>> +??? gfp = vma_thp_gfp_mask(vma);
>> +
>> +??? while (orders) {
>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>> +??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>> +??????? if (folio) {
>> +??????????? clear_huge_page(&folio->page, addr, 1 << order);
>> +??????????? return folio;
>> +??????? }
>> +??????? order = next_order(&orders, order);
>> +??? }
>> +
> 
> Queestion: would it make sense to combine both loops? I suspect memory
> allocations with pte_offset_map()/kmao are problematic.

They are both operating on separate orders; next_order() is "consuming" an order
by removing the current one from the orders bitfield and returning the next one.

So the first loop starts at the highest order and keeps checking lower orders
until one fully fits in the VMA. And the second loop starts at the first order
that was found to fully fits and loops to lower orders until an allocation is
successful.

So I don't see a need to combine the loops.

> 
>> +fallback:
>> +??? return vma_alloc_zeroed_movable_folio(vma, vmf->address);
>> +}
>> +#else
>> +#define alloc_anon_folio(vmf) \
>> +??????? vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
>> +#endif
>> +
>> ? /*
>> ?? * We enter with non-exclusive mmap_lock (to exclude vma changes,
>> ?? * but allow concurrent faults), and pte mapped but not yet locked.
>> @@ -4132,6 +4210,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>> ?? */
>> ? static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>> ? {
>> +??? int i;
>> +??? int nr_pages = 1;
>> +??? unsigned long addr = vmf->address;
>> ????? bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
>> ????? struct vm_area_struct *vma = vmf->vma;
>> ????? struct folio *folio;
> 
> Nit: reverse christmas tree :)

ACK

> 
>> @@ -4176,10 +4257,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>> ????? /* Allocate our own private page. */
>> ????? if (unlikely(anon_vma_prepare(vma)))
>> ????????? goto oom;
>> -??? folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
>> +??? folio = alloc_anon_folio(vmf);
>> +??? if (IS_ERR(folio))
>> +??????? return 0;
>> ????? if (!folio)
>> ????????? goto oom;
>> ? +??? nr_pages = folio_nr_pages(folio);
>> +??? addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
>> +
>> ????? if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
>> ????????? goto oom_free_page;
>> ????? folio_throttle_swaprate(folio, GFP_KERNEL);
>> @@ -4196,12 +4282,13 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>> ????? if (vma->vm_flags & VM_WRITE)
>> ????????? entry = pte_mkwrite(pte_mkdirty(entry), vma);
>> ? -??? vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
>> -??????????? &vmf->ptl);
>> +??? vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
>> ????? if (!vmf->pte)
>> ????????? goto release;
>> -??? if (vmf_pte_changed(vmf)) {
>> -??????? update_mmu_tlb(vma, vmf->address, vmf->pte);
>> +??? if ((nr_pages == 1 && vmf_pte_changed(vmf)) ||
>> +??????? (nr_pages? > 1 && !pte_range_none(vmf->pte, nr_pages))) {
>> +??????? for (i = 0; i < nr_pages; i++)
>> +??????????? update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);
> 
> Comment: separating the order-0 case from the other case might make this easier
> to read.

Yeah fair enough. Will fix.

> 
>> ????????? goto release;
>> ????? }
>> ? @@ -4216,16 +4303,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault
>> *vmf)
>> ????????? return handle_userfault(vmf, VM_UFFD_MISSING);
>> ????? }
>> ? -??? inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
>> -??? folio_add_new_anon_rmap(folio, vma, vmf->address);
>> +??? folio_ref_add(folio, nr_pages - 1);
>> +??? add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
>> +??? folio_add_new_anon_rmap(folio, vma, addr);
>> ????? folio_add_lru_vma(folio, vma);
>> ? setpte:
>> ????? if (uffd_wp)
>> ????????? entry = pte_mkuffd_wp(entry);
>> -??? set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
>> +??? set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
>> ? ????? /* No need to invalidate - it was non-present before */
>> -??? update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
>> +??? update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
>> ? unlock:
>> ????? if (vmf->pte)
>> ????????? pte_unmap_unlock(vmf->pte, vmf->ptl);
> 
> Benchmarking order-0 allocations might be interesting. There will be some added
> checks + multiple loops/conditionals for order-0 that could be avoided by having
> two separate code paths. If we can't measure a difference, all good.

Yep will do - will post numbers once I have them. I've been assuming that the
major cost is clearing the page, but perhaps I'm wrong.

> 



From p.zabel at pengutronix.de  Wed Dec  6 06:20:20 2023
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 06 Dec 2023 15:20:20 +0100
Subject: [PATCH v5 4/5] clk: stm32: introduce clocks for STM32MP257
 platform
In-Reply-To: <20231206140029.492906-5-gabriel.fernandez@foss.st.com>
References: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
	 <20231206140029.492906-5-gabriel.fernandez@foss.st.com>
Message-ID: <ec1912eab8bead59f520c48b6d73a084fd07732d.camel@pengutronix.de>

Hi Gabriel,

On Mi, 2023-12-06 at 15:00 +0100, gabriel.fernandez at foss.st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> 
> This driver is intended for the STM32MP25 clock family and utilizes
> the stm32-core API, similar to the stm32mp13 clock driver.
> 
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> ---
[...]
> diff --git a/drivers/clk/stm32/stm32mp25_rcc.h b/drivers/clk/stm32/stm32mp25_rcc.h
> new file mode 100644
> index 000000000000..b1aca78a0b22
> --- /dev/null
> +++ b/drivers/clk/stm32/stm32mp25_rcc.h
> @@ -0,0 +1,4977 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
> + * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
> + */
> +
> +#ifndef STM32MP25_RCC_H
> +#define STM32MP25_RCC_H
> +
> +#define RCC_SECCFGR0				0x0
[...]

What is the purpose of all the unused #defines?

I initially wanted to point out that the _SHIFT #defines are redundant
because the same information is already contained in the corresponding
_MASK #defines, but it seems like neither of the register field
definitions are used anywhere. It appears only some of the *CFGR
register offset #defines are actually used.

regards
Philipp


From ryan.roberts at arm.com  Wed Dec  6 06:22:44 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 6 Dec 2023 14:22:44 +0000
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <7d3457cd-5e3d-42a7-8113-545da646d7c8@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <8d5fdb17-c670-4814-8f48-4b90062668fc@redhat.com>
 <f65baa0c-3f5a-45ad-80dd-c240fe166877@arm.com>
 <7d3457cd-5e3d-42a7-8113-545da646d7c8@redhat.com>
Message-ID: <7a18b924-1012-4649-9289-ab5075eb7736@arm.com>

On 06/12/2023 10:22, David Hildenbrand wrote:
> On 06.12.23 11:13, Ryan Roberts wrote:
>> On 05/12/2023 17:21, David Hildenbrand wrote:
>>> On 04.12.23 11:20, Ryan Roberts wrote:
>>>> Hi All,
>>>>
>>>> A new week, a new version, a new name... This is v8 of a series to implement
>>>> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
>>>> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
>>>> this fares better.
>>>>
>>>> The objective of this is to improve performance by allocating larger chunks of
>>>> memory during anonymous page faults:
>>>>
>>>> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>>>> ???? pages, there are efficiency savings to be had; fewer page faults,
>>>> batched PTE
>>>> ???? and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>>>> ???? overhead. This should benefit all architectures.
>>>> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>>>> ???? advantage of HW TLB compression techniques. A reduction in TLB pressure
>>>> ???? speeds up kernel and user space. arm64 systems have 2 mechanisms to
>>>> coalesce
>>>> ???? TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
>>>>
>>>> This version changes the name and tidies up some of the kernel code and test
>>>> code, based on feedback against v7 (see change log for details).
>>>>
>>>> By default, the existing behaviour (and performance) is maintained. The user
>>>> must explicitly enable multi-size THP to see the performance benefit. This is
>>>> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
>>>> David for the suggestion)! This interface is inspired by the existing
>>>> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
>>>> compatibility with the existing PMD-size THP interface, and provides a base for
>>>> future extensibility. See [8] for detailed discussion of the interface.
>>>>
>>>> This series is based on mm-unstable (715b67adf4c8).
>>>
>>> I took a look at the core pieces. Some things might want some smaller tweaks,
>>> but nothing that should stop this from having fun in mm-unstable, and replacing
>>> the smaller things as we move forward.
>>>
>>
>> Thanks! I'll address your comments and see if I can post another (final??)
>> version next week.
> 
> It's always possible to do incremental changes on top that Andrew will squash in
> the end. I even recall that he prefers that way once a series has been in
> mm-unstable for a bit, so one can better observe the diff and which effects they
> have.
> 

I've responded to all your comments. There are a bunch of changes that I agree
would be good to make (and some which I disagree with - would be good if you get
a chance to respond).

I think I can get all the changes done and tested by Friday. So perhaps it's
simplest to keep this out of mm-unstable until then, and put the new version in
on Friday? Then if there are any more small changes to do, I can do those as diffs?

Thanks,
Ryan




From a.fatoum at pengutronix.de  Wed Dec  6 06:29:01 2023
From: a.fatoum at pengutronix.de (Ahmad Fatoum)
Date: Wed, 6 Dec 2023 15:29:01 +0100
Subject: [PATCH] serial: imx: Fix clock imbalance
In-Reply-To: <20231205005108.79782-1-marex@denx.de>
References: <20231205005108.79782-1-marex@denx.de>
Message-ID: <243633d4-78b9-4de6-83a9-3d2d4343a24f@pengutronix.de>

Hello Marek,

On 05.12.23 01:50, Marek Vasut wrote:
> Disable and unprepare the clock on every exit from probe function
> after the clock were prepared and enabled to avoid enable/disable
> imbalance.

Why not switch the probe function to use devm_clk_get_enabled() instead?

Cheers,
Ahmad

> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> ---
> Cc: "Ilpo J?rvinen" <ilpo.jarvinen at linux.intel.com>
> Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Jiri Slaby <jirislaby at kernel.org>
> Cc: NXP Linux Team <linux-imx at nxp.com>
> Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> Cc: Rob Herring <robh at kernel.org>
> Cc: Sascha Hauer <s.hauer at pengutronix.de>
> Cc: Sergey Organov <sorganov at gmail.com>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Tom Rix <trix at redhat.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-serial at vger.kernel.org
> ---
>  drivers/tty/serial/imx.c | 18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 52dd8a6b87603..1cce66e5d05d8 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -2332,10 +2332,8 @@ static int imx_uart_probe(struct platform_device *pdev)
>  	}
>  
>  	ret = uart_get_rs485_mode(&sport->port);
> -	if (ret) {
> -		clk_disable_unprepare(sport->clk_ipg);
> -		return ret;
> -	}
> +	if (ret)
> +		goto err_clk;
>  
>  	if (sport->port.rs485.flags & SER_RS485_ENABLED &&
>  	    (!sport->have_rtscts && !sport->have_rtsgpio))
> @@ -2436,7 +2434,7 @@ static int imx_uart_probe(struct platform_device *pdev)
>  		if (ret) {
>  			dev_err(&pdev->dev, "failed to request rx irq: %d\n",
>  				ret);
> -			return ret;
> +			goto err_clk;
>  		}
>  
>  		ret = devm_request_irq(&pdev->dev, txirq, imx_uart_txint, 0,
> @@ -2444,7 +2442,7 @@ static int imx_uart_probe(struct platform_device *pdev)
>  		if (ret) {
>  			dev_err(&pdev->dev, "failed to request tx irq: %d\n",
>  				ret);
> -			return ret;
> +			goto err_clk;
>  		}
>  
>  		ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
> @@ -2452,14 +2450,14 @@ static int imx_uart_probe(struct platform_device *pdev)
>  		if (ret) {
>  			dev_err(&pdev->dev, "failed to request rts irq: %d\n",
>  				ret);
> -			return ret;
> +			goto err_clk;
>  		}
>  	} else {
>  		ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
>  				       dev_name(&pdev->dev), sport);
>  		if (ret) {
>  			dev_err(&pdev->dev, "failed to request irq: %d\n", ret);
> -			return ret;
> +			goto err_clk;
>  		}
>  	}
>  
> @@ -2468,6 +2466,10 @@ static int imx_uart_probe(struct platform_device *pdev)
>  	platform_set_drvdata(pdev, sport);
>  
>  	return uart_add_one_port(&imx_uart_uart_driver, &sport->port);
> +
> +err_clk:
> +	clk_disable_unprepare(sport->clk_ipg);
> +	return ret;
>  }
>  
>  static void imx_uart_remove(struct platform_device *pdev)

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



From tudor.ambarus at linaro.org  Wed Dec  6 06:30:10 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Wed, 6 Dec 2023 14:30:10 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
Message-ID: <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>

Hi, Amit,

On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
> Each flash that is connected in stacked mode should have a separate
> parameter structure. So, the flash parameter member(*params) of the spi_nor
> structure is changed to an array (*params[2]). The array is used to store
> the parameters of each flash connected in stacked configuration.
> 
> The current implementation assumes that a maximum of two flashes are
> connected in stacked mode and both the flashes are of same make but can
> differ in sizes. So, except the sizes all other flash parameters of both
> the flashes are identical.

Do you plan to add support for different flashes in stacked mode? If
not, wouldn't it be simpler to have just an array of flash sizes instead
of duplicating the entire params struct?

> 
> SPI-NOR is not aware of the chip_select values, for any incoming request
> SPI-NOR will decide the flash index with the help of individual flash size
> and the configuration type (single/stacked). SPI-NOR will pass on the flash
> index information to the SPI core & SPI driver by setting the appropriate
> bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of
> nor->spimem->spi->cs_index_mask is set then the driver would
> assert/de-assert spi->chip_slect[n].
> 
> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at amd.com>
> ---
>  drivers/mtd/spi-nor/core.c  | 272 +++++++++++++++++++++++++++++-------
>  drivers/mtd/spi-nor/core.h  |   4 +
>  include/linux/mtd/spi-nor.h |  15 +-
>  3 files changed, 240 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 93ae69b7ff83..e990be7c7eb6 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c

cut

> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor)
>  static int spi_nor_late_init_params(struct spi_nor *nor)
>  {
>  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
> -	int ret;
> +	struct device_node *np = spi_nor_get_flash_node(nor);
> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
> +	u32 idx = 0;
> +	int rc, ret;
>  
>  	if (nor->manufacturer && nor->manufacturer->fixups &&
>  	    nor->manufacturer->fixups->late_init) {
> @@ -2937,6 +3042,44 @@ static int spi_nor_late_init_params(struct spi_nor *nor)
>  	if (params->n_banks > 1)
>  		params->bank_size = div64_u64(params->size, params->n_banks);
>  
> +	nor->num_flash = 0;
> +
> +	/*
> +	 * The flashes that are connected in stacked mode should be of same make.
> +	 * Except the flash size all other properties are identical for all the
> +	 * flashes connected in stacked mode.
> +	 * The flashes that are connected in parallel mode should be identical.
> +	 */
> +	while (idx < SNOR_FLASH_CNT_MAX) {
> +		rc = of_property_read_u64_index(np, "stacked-memories", idx, &flash_size[idx]);

This is a little late in my opinion, as we don't have any sanity check
on the flashes that are stacked on top of the first. We shall at least
read and compare the ID for all.

Cheers,
ta


From Bo.Ye at mediatek.com  Wed Dec  6 06:32:19 2023
From: Bo.Ye at mediatek.com (=?utf-8?B?Qm8gWWUgKOWPtuazoik=?=)
Date: Wed, 6 Dec 2023 14:32:19 +0000
Subject: [PATCH] thermal: Fix race condition in suspend/resume
In-Reply-To: <2f6530d551665e87cdf0331ecb223bdf4feb2435.camel@mediatek.com>
References: <20230916113327.85693-1-bo.ye@mediatek.com>
	 <542a64a842d715329b35654db908681e074b0db5.camel@mediatek.com>
	 <148c8e2d10bbb932177f732dfc44230681dc4d91.camel@mediatek.com>
	 <CAJZ5v0hSeCcpOr4qOpji8sbN89GnsYYc1pYBhV+LmS=TiJQMnA@mail.gmail.com>
	 <c8d305f8b46287d86a49a887983ff2198cfbc297.camel@mediatek.com>
	 <2f6530d551665e87cdf0331ecb223bdf4feb2435.camel@mediatek.com>
Message-ID: <9051236e98194f0358bb197a4a425d3fc0d4aeac.camel@mediatek.com>

On Thu, 2023-11-16 at 23:06 +0800, Bo Ye wrote:
Hi Reviewers,

  Please help review this change, or provide your suggestion. Thanks a
lot

> Hi Rafael sir,
> 
> Could you help review this patch, thanks a lot.
> 
> Best Regards
> Bo Ye
> 
> On Wed, 2023-11-01 at 22:58 +0800, Bo Ye wrote:
> > On Wed, 2023-10-25 at 20:21 +0200, Rafael J. Wysocki wrote:
> > >  	 
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > >  On Mon, Oct 23, 2023 at 3:20?AM Bo Ye (??) <Bo.Ye at mediatek.com>
> > > wrote:
> > > > 
> > > > Yes, it is observed issue.
> > > 
> > > It does happen, so it's not just "potential" and the subject of
> > > the
> > > patch is slightly misleading.  Please adjust it.
> > 
> > Done
> > 
> > > 
> > > > Firstly, it needs to be clarified that this issue occurs in a
> > > > real-
> > > > world environment. By analyzing the logs, we inferred that the
> > > 
> > > issue
> > > > occurred just as the system was entering suspend mode, and the
> > > > user
> > > 
> > > was
> > > > switching the thermal policy (this action causes all thermal
> > > > zones
> > > 
> > > to
> > > > unregister/register). In addition, we conducted degradation
> > > > tests
> > > 
> > > and
> > > > also reproduced this issue. The specific method is to first
> > > > switch
> > > 
> > > the
> > > > thermal policy through a command, and then immediately put the
> > > 
> > > system
> > > > into suspend state through another command. This method can
> > > > also
> > > > reproduce the issue.
> > > 
> > > OK, so please add this information to the patch changelog.
> > > 
> > > > On Thu, 2023-10-12 at 07:35 +0000, Bo Ye (??) wrote:
> > > > > On Sat, 2023-09-16 at 19:33 +0800, Bo Ye wrote:
> > > > > 
> > > > > Correct mail title format: remove "Subject:" from mail title.
> > > > > 
> > > > > > From: "yugang.wang" <yugang.wang at mediatek.com>
> > > > > > 
> > > > > > Body:
> > > > > > This patch fixes a race condition during system resume. It
> > > 
> > > occurs
> > > > > > if
> > > > > > the system is exiting a suspend state and a user is trying
> > > > > > to
> > > > > > register/unregister a thermal zone concurrently. The root
> > > > > > cause
> > > 
> > > is
> > > > > > that both actions access the `thermal_tz_list`.
> > > > > > 
> > > > > > In detail:
> > > > > > 
> > > > > > 1. At PM_POST_SUSPEND during the resume, the system reads
> > > > > > all
> > > > > > thermal
> > > > > >    zones in `thermal_tz_list`, then resets and updates
> > > > > > their
> > > > > >    temperatures.
> > > > > > 2. When registering/unregistering a thermal zone, the
> > > > > >    `thermal_tz_list` gets manipulated.
> > > > > > 
> > > > > > These two actions might occur concurrently, causing a race
> > > > > > condition.
> > > > > > To solve this issue, we introduce a mutex lock to protect
> > > > > > `thermal_tz_list` from being modified while it's being read
> > > > > > and
> > > > > > updated during the resume from suspend.
> > > > > > 
> > > > > > Kernel oops excerpt related to this fix:
> > > > > > 
> > > > > > [ 5201.869845] [T316822] pc: [0xffffffeb7d4876f0]
> > > > > > mutex_lock+0x34/0x170
> > > > > > [ 5201.869856] [T316822] lr: [0xffffffeb7ca98a84]
> > > > > > thermal_pm_notify+0xd4/0x26c
> > > > > > [... cut for brevity ...]
> > > > > > [ 5201.871061] [T316822]  suspend_prepare+0x150/0x470
> > > > > > [ 5201.871067] [T316822]  enter_state+0x84/0x6f4
> > > > > > [ 5201.871076] [T316822]  state_store+0x15c/0x1e8
> > > 
> > > Well, the connection between the above log snippet and the issue
> > > addressed by the patch is rather hard to establish.  Please
> > > include
> > > more of the oops information.
> > 
> > Thank you very much for reviewing the additional explanations.
> > 
> > 1.Enable thermal policy operation will unregister/register all
> > thermal
> > zones
> > 10-21 06:13:59.280   854   922 I libMtcLoader: enable thermal
> > policy
> > thermal_policy_09.
> > 
> > 2.System suspend entry time is 2023-10-20 22:13:59.242
> > [ 4106.364175][T609387] binder:534_2: [name:spm&][SPM] PM: suspend
> > entry 2023-10-20 22:13:59.242898243 UTC
> > [ 4106.366185][T609387] binder:534_2: PM: [name:wakeup&]PM: Pending
> > Wakeup Sources: NETLINK
> > 
> > 3. It can be proven that the absence of a switch strategy will
> > perform
> > unregister/register operations on thermal zones (android time is
> > 2023-
> > 10-20 22:13:59.282)?
> > Because the logs for other thermal zones switching are not enabled
> > by
> > default, we cannot see the logs related to other thermal zones.
> > [ 4106.404167][T600922] mtkPowerMsgHdl:
> > [name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
> > [ 4106.404215][T600922] mtkPowerMsgHdl:
> > [name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
> > [ 4106.404225][T600922] mtkPowerMsgHdl:
> > [name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
> > [ 4106.404504][T600922] mtkPowerMsgHdl:
> > [name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 0
> > [ 4106.404545][T600922] mtkPowerMsgHdl:
> > [name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 2
> > [ 4106.404566][T600922] mtkPowerMsgHdl:
> > [name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 1
> > 
> > 4. thermal_pm_notify trigger KE(android time:  2023-10-20 22:13:59.
> > 315894)
> > [ 4106.437171][T209387] binder:534_2: [name:mrdump&]Kernel Offset:
> > 0x289cc80000 from 0xffffffc008000000
> > [ 4106.437182][T209387] binder:534_2: [name:mrdump&]PHYS_OFFSET:
> > 0x40000000
> > [ 4106.437191][T209387] binder:534_2: [name:mrdump&]pstate:
> > 80400005
> > (Nzcv daif +PAN -UAO)
> > [ 4106.437204][T209387] binder:534_2: [name:mrdump&]pc :
> > [0xffffffe8a6688200] mutex_lock+0x34/0x184
> > [ 4106.437214][T209387] binder:534_2: [name:mrdump&]lr :
> > [0xffffffe8a5ce66bc] thermal_pm_notify+0xd4/0x26c
> > [ 4106.437220][T209387] binder:534_2: [name:mrdump&]sp :
> > ffffffc01bab3ae0
> > [ 4106.437226][T209387] binder:534_2: [name:mrdump&]x29:
> > ffffffc01bab3af0 x28: 0000000000000001
> > 
> > > 
> > > 
> > > > > > Signed-off-by: yugang.wang <yugang.wang at mediatek.com>
> > > > > > Signed-off-by: Bo Ye <bo.ye at mediatek.com>
> > > > > > ---
> > > > > >  drivers/thermal/thermal_core.c | 2 ++
> > > > > >  1 file changed, 2 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/thermal/thermal_core.c
> > > > > > b/drivers/thermal/thermal_core.c
> > > > > > index 8717a3343512..a7a18ed57b6d 100644
> > > > > > --- a/drivers/thermal/thermal_core.c
> > > > > > +++ b/drivers/thermal/thermal_core.c
> > > > > > @@ -1529,12 +1529,14 @@ static int thermal_pm_notify(struct
> > > > > > notifier_block *nb,
> > > > > >     case PM_POST_HIBERNATION:
> > > > > >     case PM_POST_RESTORE:
> > > > > >     case PM_POST_SUSPEND:
> > > > > > +           mutex_lock(&thermal_list_lock);
> > > > > >             atomic_set(&in_suspend, 0);
> > > 
> > > It is not clear to me why the above statement needs to be under
> > > the
> > > lock.
> > > 
> > > > > >             list_for_each_entry(tz, &thermal_tz_list, node)
> > > > > > {
> > > > > >                     thermal_zone_device_init(tz);
> > > > > >                     thermal_zone_device_update(tz,
> > > > 
> > > >                                                THERMAL_EVENT_UN
> > > > SP
> > > > EC
> > > > > > IFIED);
> > > > > >             }
> > > > > > +           mutex_unlock(&thermal_list_lock);
> > > > > >             break;
> > > > > >     default:
> > > > > >             break;

From heiko at sntech.de  Wed Dec  6 06:34:36 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed,  6 Dec 2023 15:34:36 +0100
Subject: [PATCH v2 0/4] arm64: dts: rockchip: aliases for core busses in main dtsi
In-Reply-To: <20231205164842.556684-1-heiko@sntech.de>
References: <20231205164842.556684-1-heiko@sntech.de>
Message-ID: <170187327282.665436.3746288633459520494.b4-ty@sntech.de>

On Tue, 5 Dec 2023 17:48:38 +0100, Heiko Stuebner wrote:
> Placement of aliases is cause for a lot of discussion :-).
> Most recently in [0]. And while devices such as mmc controllers do have
> names not following any numbers, this is different for the core
> busses/devices like serial, i2c, gpio, spi.
> 
> All of those start at number 0 and increment then. And all pieces of
> documentation like soc manuals, device schematics as well as pin-header
> descriptions for SBCs also use these numbers to identify the controller
> instance.
> 
> [...]

Applied, thanks!

[1/4] arm64: dts: rockchip: move rk3588 serial aliases to soc dtsi
      commit: 0aab62502c372e8c1fc83e4b44ed6c0b29a1e10b
[2/4] arm64: dts: rockchip: add rk3588 i2c aliases to soc dtsi
      commit: 4660763f93e089468457fe0c5396301511ec496f
[3/4] arm64: dts: rockchip: add rk3588 gpio aliases to soc dtsi
      commit: 092900cb2cac154f714aa7c24f30329ac3d5e255
[4/4] arm64: dts: rockchip: add rk3588 spi aliases to soc dtsi
      commit: ca1dcb7b914f50f18984628844b627b1226a4b01

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From tudor.ambarus at linaro.org  Wed Dec  6 06:43:56 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Wed, 6 Dec 2023 14:43:56 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
Message-ID: <9f577482-30d9-4e1d-9469-812d323b18c6@linaro.org>



On 12/6/23 14:30, Tudor Ambarus wrote:
> Hi, Amit,
> 
> On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
>> Each flash that is connected in stacked mode should have a separate
>> parameter structure. So, the flash parameter member(*params) of the spi_nor
>> structure is changed to an array (*params[2]). The array is used to store
>> the parameters of each flash connected in stacked configuration.
>>
>> The current implementation assumes that a maximum of two flashes are
>> connected in stacked mode and both the flashes are of same make but can
>> differ in sizes. So, except the sizes all other flash parameters of both
>> the flashes are identical.
> 
> Do you plan to add support for different flashes in stacked mode? If
> not, wouldn't it be simpler to have just an array of flash sizes instead
> of duplicating the entire params struct?
> 
>>
>> SPI-NOR is not aware of the chip_select values, for any incoming request
>> SPI-NOR will decide the flash index with the help of individual flash size
>> and the configuration type (single/stacked). SPI-NOR will pass on the flash
>> index information to the SPI core & SPI driver by setting the appropriate
>> bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of
>> nor->spimem->spi->cs_index_mask is set then the driver would
>> assert/de-assert spi->chip_slect[n].
>>
>> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at amd.com>
>> ---
>>  drivers/mtd/spi-nor/core.c  | 272 +++++++++++++++++++++++++++++-------
>>  drivers/mtd/spi-nor/core.h  |   4 +
>>  include/linux/mtd/spi-nor.h |  15 +-
>>  3 files changed, 240 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 93ae69b7ff83..e990be7c7eb6 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
> 
> cut
> 
>> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor)
>>  static int spi_nor_late_init_params(struct spi_nor *nor)
>>  {
>>  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
>> -	int ret;
>> +	struct device_node *np = spi_nor_get_flash_node(nor);
>> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
>> +	u32 idx = 0;
>> +	int rc, ret;
>>  
>>  	if (nor->manufacturer && nor->manufacturer->fixups &&
>>  	    nor->manufacturer->fixups->late_init) {
>> @@ -2937,6 +3042,44 @@ static int spi_nor_late_init_params(struct spi_nor *nor)
>>  	if (params->n_banks > 1)
>>  		params->bank_size = div64_u64(params->size, params->n_banks);
>>  
>> +	nor->num_flash = 0;
>> +
>> +	/*
>> +	 * The flashes that are connected in stacked mode should be of same make.
>> +	 * Except the flash size all other properties are identical for all the
>> +	 * flashes connected in stacked mode.
>> +	 * The flashes that are connected in parallel mode should be identical.
>> +	 */
>> +	while (idx < SNOR_FLASH_CNT_MAX) {
>> +		rc = of_property_read_u64_index(np, "stacked-memories", idx, &flash_size[idx]);

also, it's not clear to me why you read this property multiple times.
Have you sent a device tree patch somewhere? It will help me understand
what you're trying to achieve.

> 
> This is a little late in my opinion, as we don't have any sanity check
> on the flashes that are stacked on top of the first. We shall at least
> read and compare the ID for all.
> 
> Cheers,
> ta


From frieder at fris.de  Wed Dec  6 06:41:03 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:03 +0100
Subject: [PATCH v3 00/14] arm64: dts: imx8mm-kontron: DT updates
Message-ID: <20231206144201.46911-1-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

This patchset contains several improvements and updates for the devicetrees
for the i.MX8MM modules and boards by Kontron Electronics GmbH.

* HDMI/LVDS support for the BL/DL i.MX8MM
* Misc cleanups and small fixes
* OSM-S i.MX8MM module refactoring and update to latest HW revision

Changes in v3:
* Address Shawn's review comments for patch 1, 2 and 14 (thanks!)

Changes in v2:
* Rework DSI mux GPIO logic to be compatible with overlay
* Switch from 4 to 2 DSI lanes for LVDS bridge to fix non-working display

Frieder Schrempf (14):
  arm64: dts: imx8mm-kontron: Add support for display bridges on BL
    i.MX8MM
  arm64: dts: imx8mm-kontron: Add DL (Display-Line) overlay with LVDS
    support
  arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on OSM-S
    i.MX8MM
  arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on SL/BL
    i.MX8MM
  arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals
    on BL OSM-S board
  arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals
    on BL board
  arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals
    on BL OSM-S board
  arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals
    on BL board
  arm64: dts: imx8mm-kontron: Fix interrupt for RTC on OSM-S i.MX8MM
    module
  arm64: dts: imx8mm-kontron: Fix OSM-S devicetrees to match latest
    hardware
  arm64: dts: imx8mm-kontron: Disable uneffective PUE bit in SDIO IOMUX
  arm64: dts: imx8mm-kontron: Remove useless trickle-diode-disable from
    RTC node
  arm64: dts: imx8mm-kontron: Add I2C EEPROM on OSM-S Kontron i.MX8MM
  arm64: dts: imx8mm-kontron: Refactor devicetree for OSM-S module and
    board

 arch/arm64/boot/dts/freescale/Makefile        |   4 +
 .../dts/freescale/imx8mm-kontron-bl-osm-s.dts | 295 +++------
 .../boot/dts/freescale/imx8mm-kontron-bl.dts  | 198 +++++-
 .../boot/dts/freescale/imx8mm-kontron-dl.dtso | 201 +++++++
 .../dts/freescale/imx8mm-kontron-osm-s.dtsi   | 567 +++++++++++++++++-
 .../boot/dts/freescale/imx8mm-kontron-sl.dtsi |   4 +-
 6 files changed, 1035 insertions(+), 234 deletions(-)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso

-- 
2.43.0


From frieder at fris.de  Wed Dec  6 06:41:04 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:04 +0100
Subject: [PATCH v3 01/14] arm64: dts: imx8mm-kontron: Add support for display bridges on BL i.MX8MM
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-2-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

The Kontron Electronics BL i.MX8MM has oboard disply bridges for
DSI->HDMI and DSI->LVDS conversion. The DSI interface is muxed by
a GPIO-controlled switch to one of these two bridges.

By default the HDMI bridge is enabled. The LVDS bridge can be
selected by loading an additional (panel-specific) overlay.

Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* Address Shawn's review comments (thanks!)

Changes for v2:
* Rework DSI mux GPIO logic to be compatible with overlay
* Switch from 4 to 2 DSI lanes for LVDS bridge to fix non-working display
---
 .../boot/dts/freescale/imx8mm-kontron-bl.dts  | 160 ++++++++++++++++++
 1 file changed, 160 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
index dcec57c20399e..a0f0be3f104fb 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
@@ -25,6 +25,17 @@ osc_can: clock-osc-can {
 		clock-output-names = "osc-can";
 	};
 
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_in_conn: endpoint {
+				remote-endpoint = <&bridge_out_conn>;
+			};
+		};
+	};
+
 	leds {
 		compatible = "gpio-leds";
 		pinctrl-names = "default";
@@ -132,6 +143,104 @@ ethphy: ethernet-phy at 0 {
 	};
 };
 
+&gpio4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpio4>;
+
+	dsi_mux_sel_hdmi: dsi-mux-sel-hdmi-hog {
+		gpio-hog;
+		gpios = <14 GPIO_ACTIVE_HIGH>;
+		output-high;
+		line-name = "dsi-mux-sel";
+	};
+
+	dsi_mux_sel_lvds: dsi-mux-sel-lvds-hog {
+		gpio-hog;
+		gpios = <14 GPIO_ACTIVE_HIGH>;
+		output-low;
+		line-name = "dsi-mux-sel";
+		status = "disabled";
+	};
+
+	dsi-mux-oe-hog {
+		gpio-hog;
+		gpios = <15 GPIO_ACTIVE_LOW>;
+		output-high;
+		line-name = "dsi-mux-oe";
+	};
+};
+
+&i2c3 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+
+	hdmi: hdmi at 39 {
+		compatible = "adi,adv7535";
+		reg = <0x39>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_adv7535>;
+
+		interrupt-parent = <&gpio4>;
+		interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+
+		adi,dsi-lanes = <4>;
+
+		a2vdd-supply = <&reg_vdd_1v8>;
+		avdd-supply = <&reg_vdd_1v8>;
+		dvdd-supply = <&reg_vdd_1v8>;
+		pvdd-supply = <&reg_vdd_1v8>;
+		v1p2-supply = <&reg_vdd_1v8>;
+		v3p3-supply = <&reg_vdd_3v3>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				bridge_in_dsi_hdmi: endpoint {
+					remote-endpoint = <&dsi_out_bridge>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+
+				bridge_out_conn: endpoint {
+					remote-endpoint = <&hdmi_in_conn>;
+				};
+			};
+		};
+	};
+
+	lvds: bridge at 2c {
+		compatible = "ti,sn65dsi84";
+		reg = <0x2c>;
+		enable-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_sn65dsi84>;
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				bridge_in_dsi_lvds: endpoint {
+					remote-endpoint = <&dsi_out_bridge>;
+					data-lanes = <1 2>;
+				};
+			};
+		};
+	};
+};
+
 &i2c4 {
 	clock-frequency = <100000>;
 	pinctrl-names = "default";
@@ -144,6 +253,30 @@ rx8900: rtc at 32 {
 	};
 };
 
+&lcdif {
+	status = "okay";
+};
+
+&mipi_dsi {
+	samsung,esc-clock-frequency = <54000000>;
+	/*
+	 * Let the driver calculate an appropriate clock rate based on the pixel
+	 * clock instead of using the fixed value from imx8mm.dtsi.
+	 */
+	/delete-property/ samsung,pll-clock-frequency;
+	status = "okay";
+
+	ports {
+		port at 1 {
+			reg = <1>;
+
+			dsi_out_bridge: endpoint {
+				remote-endpoint = <&bridge_in_dsi_hdmi>;
+			};
+		};
+	};
+};
+
 &pwm2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_pwm2>;
@@ -207,6 +340,12 @@ &iomuxc {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_gpio>;
 
+	pinctrl_adv7535: adv7535grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI1_TXD4_GPIO4_IO16		0x19
+		>;
+	};
+
 	pinctrl_can: cangrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28		0x19
@@ -277,6 +416,20 @@ MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19
 		>;
 	};
 
+	pinctrl_gpio4: gpio4grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI1_TXD2_GPIO4_IO14		0x19
+			MX8MM_IOMUXC_SAI1_TXD3_GPIO4_IO15		0x19
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083
+			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083
+		>;
+	};
+
 	pinctrl_i2c4: i2c4grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x400001c3
@@ -290,6 +443,13 @@ MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT			0x19
 		>;
 	};
 
+	pinctrl_sn65dsi84: sn65dsi84grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI2_TXD0_GPIO4_IO26		0x19
+			MX8MM_IOMUXC_SD2_WP_GPIO2_IO20			0x19
+		>;
+	};
+
 	pinctrl_uart1: uart1grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x140
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:05 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:05 +0100
Subject: [PATCH v3 02/14] arm64: dts: imx8mm-kontron: Add DL (Display-Line) overlay with LVDS support
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-3-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

The Kontron Electronics DL i.MX8MM consists of the BL i.MX8MM board
and a 7" LVDS panel. Provide an overlay that enables the panel.

Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* Address Shawn's review comments (thanks!)

Changes for v2:
* Rework DSI mux GPIO logic to be compatible with overlay
---
 arch/arm64/boot/dts/freescale/Makefile        |   4 +
 .../boot/dts/freescale/imx8mm-kontron-dl.dtso | 201 ++++++++++++++++++
 2 files changed, 205 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 300049037eb0b..e08024797721a 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -166,6 +166,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla.dtb
 
+imx8mm-kontron-dl-dtbs			:= imx8mm-kontron-bl.dtb imx8mm-kontron-dl.dtbo
+
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-kontron-dl.dtb
+
 imx8mm-venice-gw72xx-0x-imx219-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-imx219.dtbo
 imx8mm-venice-gw72xx-0x-rpidsi-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rpidsi.dtbo
 imx8mm-venice-gw72xx-0x-rs232-rts-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rs232-rts.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso b/arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso
new file mode 100644
index 0000000000000..6784bea857c00
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Kontron Electronics GmbH
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx8mm-pinfunc.h"
+
+&{/} {
+	compatible = "kontron,imx8mm-bl", "kontron,imx8mm-sl", "fsl,imx8mm";
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm1 0 50000 0>;
+		brightness-levels = <0 100>;
+		num-interpolated-steps = <100>;
+		default-brightness-level = <100>;
+	};
+
+	panel {
+		compatible = "panel-lvds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel>;
+		backlight = <&backlight>;
+		data-mapping = "vesa-24";
+		enable-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+		height-mm = <86>;
+		width-mm = <154>;
+
+		panel-timing {
+			clock-frequency = <51200000>;
+			hactive = <1024>;
+			vactive = <600>;
+			hsync-len = <1>;
+			hfront-porch = <160>;
+			hback-porch = <160>;
+			vsync-len = <1>;
+			vfront-porch = <12>;
+			vback-porch = <23>;
+		};
+
+		port {
+			panel_out_bridge: endpoint {
+				remote-endpoint = <&bridge_out_panel>;
+			};
+		};
+	};
+};
+
+&dsi_mux_sel_hdmi {
+	status = "disabled";
+};
+
+&dsi_mux_sel_lvds {
+	status = "okay";
+};
+
+&dsi_out_bridge {
+	remote-endpoint = <&bridge_in_dsi_lvds>;
+};
+
+&gpio3 {
+	panel_rst {
+		gpio-hog;
+		gpios = <20 GPIO_ACTIVE_HIGH>;
+		output-high;
+		line-name = "panel-reset";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel_rst>;
+	};
+
+	panel_stby {
+		gpio-hog;
+		gpios = <21 GPIO_ACTIVE_HIGH>;
+		output-high;
+		line-name = "panel-standby";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel_stby>;
+	};
+
+	panel_hinv {
+		gpio-hog;
+		gpios = <24 GPIO_ACTIVE_HIGH>;
+		output-high;
+		line-name = "panel-horizontal-invert";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel_hinv>;
+	};
+
+	panel_vinv {
+		gpio-hog;
+		gpios = <25 GPIO_ACTIVE_HIGH>;
+		output-low;
+		line-name = "panel-vertical-invert";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel_vinv>;
+	};
+};
+
+&hdmi {
+	status = "disabled";
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	gt911 at 5d {
+		compatible = "goodix,gt928";
+		reg = <0x5d>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_touch>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <22 8>;
+		reset-gpios = <&gpio3 23 0>;
+		irq-gpios = <&gpio3 22 0>;
+	};
+};
+
+&lvds {
+	status = "okay";
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port at 2 {
+			reg = <2>;
+
+			bridge_out_panel: endpoint {
+				remote-endpoint = <&panel_out_bridge>;
+			};
+		};
+	};
+};
+
+&pwm1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm1>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL			0x40000083
+			MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA			0x40000083
+		>;
+	};
+
+	pinctrl_panel: panelgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_RXFS_GPIO3_IO19		0x19
+		>;
+	};
+
+	pinctrl_panel_hinv: panelhinvgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24		0x19
+		>;
+	};
+
+	pinctrl_panel_rst: panelrstgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20		0x19
+		>;
+	};
+
+	pinctrl_panel_stby: panelstbygrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21		0x19
+		>;
+	};
+
+	pinctrl_panel_vinv: panelvinvgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19
+		>;
+	};
+
+	pinctrl_pwm1: pwm1grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SPDIF_EXT_CLK_PWM1_OUT		0x6
+		>;
+	};
+
+	pinctrl_touch: touchgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22		0x19
+			MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23		0x19
+		>;
+	};
+};
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:06 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:06 +0100
Subject: [PATCH v3 03/14] arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on OSM-S i.MX8MM
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-4-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

There are external pullup resistors on the board and due to silicon
errata ERR050080 let's disable the internal ones to prevent any
unwanted behavior in case they wear out.

Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S")
Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts | 4 ++--
 arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
index 8b16bd68576c0..0730c22e5b6b9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
@@ -294,8 +294,8 @@ MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19
 
 	pinctrl_i2c4: i2c4grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x400001c3
-			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x400001c3
+			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x40000083
+			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x40000083
 		>;
 	};
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
index 6e75ab879bf59..3e7db968f7e64 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
@@ -252,8 +252,8 @@ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9		0x19
 
 	pinctrl_i2c1: i2c1grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL			0x400001c3
-			MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA			0x400001c3
+			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL			0x40000083
+			MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA			0x40000083
 		>;
 	};
 
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:07 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:07 +0100
Subject: [PATCH v3 04/14] arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on SL/BL i.MX8MM
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-5-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

There are external pullup resistors on the board and due to silicon
errata ERR050080 let's disable the internal ones to prevent any
unwanted behavior in case they wear out.

Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts  | 4 ++--
 arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
index a0f0be3f104fb..866f35d1633d4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
@@ -432,8 +432,8 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083
 
 	pinctrl_i2c4: i2c4grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x400001c3
-			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x400001c3
+			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x40000083
+			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x40000083
 		>;
 	};
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi
index 1f8326613ee9e..2076148e08627 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi
@@ -237,8 +237,8 @@ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9		0x19
 
 	pinctrl_i2c1: i2c1grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL			0x400001c3
-			MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA			0x400001c3
+			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL			0x40000083
+			MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA			0x40000083
 		>;
 	};
 
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:08 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:08 +0100
Subject: [PATCH v3 05/14] arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL OSM-S board
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-6-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

These signals are actively driven by the SoC or by the onboard
transceiver. There's no need to enable the internal pull resistors
and due to silicon errata ERR050080 let's disable the internal ones
to prevent any unwanted behavior in case they wear out.

Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S")
Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 .../dts/freescale/imx8mm-kontron-bl-osm-s.dts    | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
index 0730c22e5b6b9..1dd03ef0a7835 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
@@ -313,19 +313,19 @@ MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19
 
 	pinctrl_uart1: uart1grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x140
-			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x140
-			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x140
-			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x140
+			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x0
+			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x0
+			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x0
+			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x0
 		>;
 	};
 
 	pinctrl_uart2: uart2grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x140
-			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x140
-			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x140
-			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x140
+			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x0
+			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x0
+			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x0
+			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x0
 		>;
 	};
 
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:09 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:09 +0100
Subject: [PATCH v3 06/14] arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL board
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-7-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

These signals are actively driven by the SoC or by the onboard
transceiver. There's no need to enable the internal pull resistors
and due to silicon errata ERR050080 let's disable the internal ones
to prevent any unwanted behavior in case they wear out.

Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 .../boot/dts/freescale/imx8mm-kontron-bl.dts     | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
index 866f35d1633d4..767012661bfca 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
@@ -452,19 +452,19 @@ MX8MM_IOMUXC_SD2_WP_GPIO2_IO20			0x19
 
 	pinctrl_uart1: uart1grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x140
-			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x140
-			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x140
-			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x140
+			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x0
+			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x0
+			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x0
+			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x0
 		>;
 	};
 
 	pinctrl_uart2: uart2grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x140
-			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x140
-			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x140
-			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x140
+			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x0
+			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x0
+			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x0
+			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x0
 		>;
 	};
 
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:10 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:10 +0100
Subject: [PATCH v3 07/14] arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL OSM-S board
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-8-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

Some signals have external pullup resistors on the board and don't need
the internal ones to be enabled. Due to silicon errata ERR050080 let's
disable the internal pull resistors whererever possible and prevent
any unwanted behavior in case they wear out.

Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S")
Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 .../dts/freescale/imx8mm-kontron-bl-osm-s.dts  | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
index 1dd03ef0a7835..d9fa0deea7002 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
@@ -337,40 +337,40 @@ MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2		0x19
 
 	pinctrl_usdhc2: usdhc2grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x190
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x90
 			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d0
 			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d0
 			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0
 			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0
 			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0
-			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x019
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x1d0
+			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xd0
 		>;
 	};
 
 	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x194
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x94
 			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d4
 			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d4
 			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4
 			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4
 			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4
-			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x019
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x1d0
+			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xd0
 		>;
 	};
 
 	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x196
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x96
 			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d6
 			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d6
 			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6
 			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6
 			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6
-			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x019
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x1d0
+			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xd0
 		>;
 	};
 };
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:11 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:11 +0100
Subject: [PATCH v3 08/14] arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL board
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-9-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

Some signals have external pullup resistors on the board and don't need
the internal ones to be enabled. Due to silicon errata ERR050080 let's
disable the internal pull resistors whererever possible and prevent
any unwanted behavior in case they wear out.

Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 .../boot/dts/freescale/imx8mm-kontron-bl.dts   | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
index 767012661bfca..01722ab25392d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
@@ -476,40 +476,40 @@ MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2		0x19
 
 	pinctrl_usdhc2: usdhc2grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x190
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x90
 			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d0
 			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d0
 			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0
 			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0
 			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0
-			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x019
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x1d0
+			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xd0
 		>;
 	};
 
 	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x194
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x94
 			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d4
 			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d4
 			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4
 			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4
 			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4
-			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x019
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x1d0
+			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xd0
 		>;
 	};
 
 	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x196
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x96
 			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d6
 			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d6
 			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6
 			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6
 			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6
-			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x019
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x1d0
+			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xd0
 		>;
 	};
 };
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:12 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:12 +0100
Subject: [PATCH v3 09/14] arm64: dts: imx8mm-kontron: Fix interrupt for RTC on OSM-S i.MX8MM module
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-10-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

The level of the interrupt signal is active low instead. Fix this.

Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S")
Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
index 3e7db968f7e64..60abcb636cedf 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
@@ -210,7 +210,7 @@ rv3028: rtc at 52 {
 		reg = <0x52>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_rtc>;
-		interrupts-extended = <&gpio4 1 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts-extended = <&gpio4 1 IRQ_TYPE_LEVEL_LOW>;
 		trickle-diode-disable;
 	};
 };
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:13 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:13 +0100
Subject: [PATCH v3 10/14] arm64: dts: imx8mm-kontron: Fix OSM-S devicetrees to match latest hardware
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-11-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

The current state of the devicetree for the i.MX8MM OSM-S and the BL
baseboard reflects deprecated prototype hardware. Update the board
description to match the latest hardware revision.

As the old hardware is not available anymore, was only produced in
very small quantities and was broken in some ways, we can safely
fixup the original devicetree.

Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM-S")
Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 .../dts/freescale/imx8mm-kontron-bl-osm-s.dts | 64 ++++++++++++-------
 1 file changed, 41 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
index d9fa0deea7002..7c5586efccc59 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
@@ -30,18 +30,18 @@ leds {
 
 		led1 {
 			label = "led1";
-			gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;
 			linux,default-trigger = "heartbeat";
 		};
 
 		led2 {
 			label = "led2";
-			gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
 		};
 
 		led3 {
 			label = "led3";
-			gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio3 7 GPIO_ACTIVE_LOW>;
 		};
 	};
 
@@ -54,7 +54,7 @@ reg_rst_eth2: regulator-rst-eth2 {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_usb_eth2>;
-		gpio = <&gpio3 2 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio1 1 GPIO_ACTIVE_HIGH>;
 		enable-active-high;
 		regulator-always-on;
 		regulator-name = "rst-usb-eth2";
@@ -91,7 +91,7 @@ can at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_can>;
 		clocks = <&osc_can>;
-		interrupts-extended = <&gpio4 28 IRQ_TYPE_LEVEL_LOW>;
+		interrupts-extended = <&gpio5 1 IRQ_TYPE_LEVEL_LOW>;
 		/*
 		 * Limit the SPI clock to 15 MHz to prevent issues
 		 * with corrupted data due to chip errata.
@@ -118,7 +118,7 @@ eeram at 0 {
 &fec1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_enet>;
-	phy-connection-type = "rgmii-rxid";
+	phy-connection-type = "rgmii-id";
 	phy-handle = <&ethphy>;
 	status = "okay";
 
@@ -127,10 +127,11 @@ mdio {
 		#size-cells = <0>;
 
 		ethphy: ethernet-phy at 0 {
+			compatible = "ethernet-phy-id4f51.e91b",
+				     "ethernet-phy-ieee802.3-c22";
 			reg = <0>;
-			reset-assert-us = <1>;
-			reset-deassert-us = <15000>;
-			reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
 		};
 	};
 };
@@ -153,11 +154,24 @@ &gpio5 {
 			  "", "", "", "", "", "", "", "";
 };
 
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+
+	usb-hub at 2c {
+		compatible = "microchip,usb2514b";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usb_hub>;
+		reg = <0x2c>;
+		non-removable-ports = <0>, <3>;
+		reset-gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
+	};
+};
+
 &i2c4 {
-	clock-frequency = <100000>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_i2c4>;
-	status = "okay";
 };
 
 &pwm2 {
@@ -196,13 +210,13 @@ &usbotg2 {
 	status = "okay";
 
 	usb1 at 1 {
-		compatible = "usb424,9514";
+		compatible = "usb424,2514";
 		reg = <1>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 
 		usbnet: ethernet at 1 {
-			compatible = "usb424,ec00";
+			compatible = "usbb95,772b";
 			reg = <1>;
 			local-mac-address = [ 00 00 00 00 00 00 ];
 		};
@@ -223,7 +237,7 @@ &usdhc2 {
 &iomuxc {
 	pinctrl_can: cangrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28		0x19
+			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19
 		>;
 	};
 
@@ -261,27 +275,24 @@ MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC		0x1f
 			MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC		0x91
 			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x91
 			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x1f
-			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19 /* PHY RST */
-			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x19 /* ETH IRQ */
+			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x19 /* PHY RST */
 		>;
 	};
 
 	pinctrl_gpio_led: gpioledgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12		0x19
-			MX8MM_IOMUXC_GPIO1_IO13_GPIO1_IO13		0x19
-			MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14		0x19
+			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x19
+			MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7		0x19
+			MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8		0x19
 		>;
 	};
 
 	pinctrl_gpio1: gpio1grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x19
-			MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7		0x19
+			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19
 			MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x19
 			MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11		0x19
 			MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6		0x19
-			MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8		0x19
 			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10		0x19
 		>;
 	};
@@ -292,6 +303,13 @@ MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19
 		>;
 	};
 
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083
+			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083
+		>;
+	};
+
 	pinctrl_i2c4: i2c4grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x40000083
@@ -331,7 +349,7 @@ MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x0
 
 	pinctrl_usb_eth2: usbeth2grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2		0x19
+			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19
 		>;
 	};
 
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:14 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:14 +0100
Subject: [PATCH v3 11/14] arm64: dts: imx8mm-kontron: Disable uneffective PUE bit in SDIO IOMUX
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-12-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

The PUE bit is only effective if the PE bit is also set. To avoid
confusion, disable the PUE bit if it is not needed.

Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
index 7c5586efccc59..12f786a72fbd5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
@@ -362,7 +362,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0
 			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0
 			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0
 			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xd0
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
 		>;
 	};
 
@@ -375,7 +375,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4
 			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4
 			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4
 			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xd0
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
 		>;
 	};
 
@@ -388,7 +388,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6
 			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6
 			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6
 			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xd0
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
 		>;
 	};
 };
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:15 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:15 +0100
Subject: [PATCH v3 12/14] arm64: dts: imx8mm-kontron: Remove useless trickle-diode-disable from RTC node
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-13-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

The RV3028 driver doesn't use this property. Remove it.

Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
index 60abcb636cedf..b161b0c85d61e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
@@ -211,7 +211,6 @@ rv3028: rtc at 52 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_rtc>;
 		interrupts-extended = <&gpio4 1 IRQ_TYPE_LEVEL_LOW>;
-		trickle-diode-disable;
 	};
 };
 
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:16 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:16 +0100
Subject: [PATCH v3 13/14] arm64: dts: imx8mm-kontron: Add I2C EEPROM on OSM-S Kontron i.MX8MM
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-14-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

There is an EEPROM on the SoM module. Add it to the description.

Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* none

Changes for v2:
* none
---
 arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
index b161b0c85d61e..6b9058fc53332 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
@@ -205,6 +205,14 @@ reg_nvcc_sd: LDO5 {
 		};
 	};
 
+	eeprom: eeprom at 50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+		address-width = <16>;
+		pagesize = <32>;
+		size = <8192>;
+	};
+
 	rv3028: rtc at 52 {
 		compatible = "microcrystal,rv3028";
 		reg = <0x52>;
-- 
2.43.0



From frieder at fris.de  Wed Dec  6 06:41:17 2023
From: frieder at fris.de (Frieder Schrempf)
Date: Wed,  6 Dec 2023 15:41:17 +0100
Subject: [PATCH v3 14/14] arm64: dts: imx8mm-kontron: Refactor devicetree for OSM-S module and board
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231206144201.46911-15-frieder@fris.de>

From: Frieder Schrempf <frieder.schrempf at kontron.de>

The OSM spec defines dedicated functions for all pads of the SoM.
Therefore we can assume that carrier board designs stick to these
definitions and extend the SoM devicetree include with matching
default nodes and pinmux settings.

This way we can reduce the overhead and redundancy in the carrier
board devicetrees while still sticking to the policy of separating
board and module description.

Even if the carrier board design deviates slightly from the spec it
can define its own pinmux definitions and use them as necessary or
even disable unused nodes from the SoM devicetree.

Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
Changes for v3:
* Address Shawn's review comments (thanks!)

Changes for v2:
* none
---
 .../dts/freescale/imx8mm-kontron-bl-osm-s.dts | 269 +++------
 .../dts/freescale/imx8mm-kontron-osm-s.dtsi   | 552 +++++++++++++++++-
 2 files changed, 616 insertions(+), 205 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
index 12f786a72fbd5..efadfdff00af1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
@@ -25,8 +25,6 @@ osc_can: clock-osc-can {
 
 	leds {
 		compatible = "gpio-leds";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_gpio_led>;
 
 		led1 {
 			label = "led1";
@@ -52,24 +50,12 @@ pwm-beeper {
 
 	reg_rst_eth2: regulator-rst-eth2 {
 		compatible = "regulator-fixed";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usb_eth2>;
 		gpio = <&gpio1 1 GPIO_ACTIVE_HIGH>;
 		enable-active-high;
 		regulator-always-on;
 		regulator-name = "rst-usb-eth2";
 	};
 
-	reg_usb1_vbus: regulator-usb1-vbus {
-		compatible = "regulator-fixed";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_reg_usb1_vbus>;
-		gpio = <&gpio3 25 GPIO_ACTIVE_LOW>;
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-		regulator-name = "usb1-vbus";
-	};
-
 	reg_vdd_5v: regulator-5v {
 		compatible = "regulator-fixed";
 		regulator-always-on;
@@ -80,9 +66,6 @@ reg_vdd_5v: regulator-5v {
 };
 
 &ecspi2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_ecspi2>;
-	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
 	status = "okay";
 
 	can at 0 {
@@ -103,9 +86,6 @@ can at 0 {
 };
 
 &ecspi3 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_ecspi3>;
-	cs-gpios = <&gpio5 25 GPIO_ACTIVE_LOW>;
 	status = "okay";
 
 	eeram at 0 {
@@ -117,7 +97,7 @@ eeram at 0 {
 
 &fec1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet>;
+	pinctrl-0 = <&pinctrl_enet_rgmii>;
 	phy-connection-type = "rgmii-id";
 	phy-handle = <&ethphy>;
 	status = "okay";
@@ -136,27 +116,59 @@ ethphy: ethernet-phy at 0 {
 	};
 };
 
+/*
+ * Rename SoM signals according to board usage:
+ *   GPIO_B_0      -> DIO1_OUT
+ *   GPIO_B_1      -> DIO2_OUT
+ */
 &gpio1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_gpio1>;
-	gpio-line-names = "", "", "", "dio1-out", "", "", "dio1-in", "dio2-out",
-			  "dio2-in", "dio3-out", "dio3-in", "dio4-out", "", "", "", "",
-			  "", "", "", "", "", "", "", "",
-			  "", "", "", "", "", "", "", "";
+	gpio-line-names = "", "GPIO_A_0", "", "GPIO_A_1",
+			  "", "GPIO_A_2", "GPIO_A_3", "GPIO_A_4",
+			  "GPIO_A_5", "GPIO_A_6", "GPIO_A_7", "DIO1_OUT",
+			  "DIO2_OUT", "USB_A_OC#", "CAM_MCK", "USB_B_OC#",
+			  "ETH_MDC", "ETH_MDIO", "ETH_A_(S)(R)(G)MII_TXD3",
+			  "ETH_A_(S)(R)(G)MII_TXD2", "ETH_A_(S)(R)(G)MII_TXD1",
+			  "ETH_A_(S)(R)(G)MII_TXD0", "ETH_A_(R)(G)MII_TX_EN(_ER)",
+			  "ETH_A_(R)(G)MII_TX_CLK", "ETH_A_(R)(G)MII_RX_DV(_ER)",
+			  "ETH_A_(R)(G)MII_RX_CLK", "ETH_A_(S)(R)(G)MII_RXD0",
+			  "ETH_A_(S)(R)(G)MII_RXD1", "ETH_A_(R)(G)MII_RXD2",
+			  "ETH_A_(R)(G)MII_RXD3";
 };
 
-&gpio5 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_gpio5>;
-	gpio-line-names = "", "", "dio4-in", "", "", "", "", "",
-			  "", "", "", "", "", "", "", "",
-			  "", "", "", "", "", "", "", "",
-			  "", "", "", "", "", "", "", "";
+/*
+ * Rename SoM signals according to board usage:
+ *   GPIO_B_2      -> DIO3_OUT
+ *   GPIO_B_3      -> DIO4_OUT
+ */
+&gpio3 {
+	gpio-line-names = "GPIO_C_5", "GPIO_C_4", "SDIO_B_CD#", "SDIO_B_D5",
+			  "SDIO_B_D6", "SDIO_B_D7", "GPIO_C_0", "GPIO_C_1",
+			  "GPIO_C_2", "GPIO_C_3", "SDIO_B_D0", "SDIO_B_D1",
+			  "SDIO_B_D2", "SDIO_B_D3", "", "SDIO_B_D4",
+			  "CARRIER_PWR_EN", "SDIO_B_CLK", "SDIO_B_CMD", "DIO3_OUT",
+			  "USB_B_EN", "DIO4_OUT", "PCIe_CLKREQ#", "PCIe_A_PERST#",
+			  "PCIe_WAKE#", "USB_A_EN";
+};
+
+/*
+ * Rename SoM signals according to board usage:
+ *   GPIO_B_4      -> DIO1_IN
+ *   GPIO_B_5      -> DIO2_IN
+ *   GPIO_B_6      -> DIO3_IN
+ *   GPIO_B_7      -> DIO4_IN
+ */
+&gpio4 {
+	gpio-line-names = "GPIO_C_7", "", "I2S_A_DATA_IN", "I2S_B_DATA_IN",
+			  "DIO1_IN", "BOOT_SEL0#", "BOOT_SEL1#", "",
+			  "", "", "I2S_LRCLK", "I2S_BITCLK",
+			  "I2S_A_DATA_OUT", "I2S_B_DATA_OUT", "DIO2_IN", "DIO3_IN",
+			  "DIO4_IN", "SPI_A_/WP_(IO2)", "SPI_A_/HOLD_(IO3)", "GPIO_C_6",
+			  "I2S_MCLK", "UART_A_TX", "UART_A_RX", "UART_A_CTS",
+			  "UART_A_RTS", "", "", "",
+			  "PCIe_SM_ALERT", "UART_B_RTS", "UART_B_CTS", "UART_B_RX";
 };
 
 &i2c3 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_i2c3>;
 	status = "okay";
 
 	usb-hub at 2c {
@@ -169,27 +181,28 @@ usb-hub at 2c {
 	};
 };
 
-&i2c4 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_i2c4>;
-};
-
 &pwm2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_pwm2>;
 	status = "okay";
 };
 
+&reg_usb2_vbus {
+	status = "disabled";
+};
+
+&reg_usdhc2_vcc {
+	status = "disabled";
+};
+
+&reg_usdhc3_vcc {
+	status = "disabled";
+};
+
 &uart1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart1>;
 	uart-has-rtscts;
 	status = "okay";
 };
 
 &uart2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart2>;
 	linux,rs485-enabled-at-boot-time;
 	uart-has-rtscts;
 	status = "okay";
@@ -197,8 +210,6 @@ &uart2 {
 
 &usbotg1 {
 	dr_mode = "otg";
-	disable-over-current;
-	vbus-supply = <&reg_usb1_vbus>;
 	status = "okay";
 };
 
@@ -209,6 +220,9 @@ &usbotg2 {
 	#size-cells = <0>;
 	status = "okay";
 
+	/* VBUS is controlled by the hub */
+	/delete-property/ vbus-supply;
+
 	usb1 at 1 {
 		compatible = "usb424,2514";
 		reg = <1>;
@@ -224,171 +238,20 @@ usbnet: ethernet at 1 {
 };
 
 &usdhc2 {
-	pinctrl-names = "default", "state_100mhz", "state_200mhz";
-	pinctrl-0 = <&pinctrl_usdhc2>;
-	pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
-	pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
 	vmmc-supply = <&reg_vdd_3v3>;
-	vqmmc-supply = <&reg_nvcc_sd>;
-	cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
 	status = "okay";
 };
 
 &iomuxc {
 	pinctrl_can: cangrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19
-		>;
-	};
-
-	pinctrl_ecspi2: ecspi2grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO		0x82
-			MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI		0x82
-			MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK		0x82
-			MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13		0x19
-		>;
-	};
-
-	pinctrl_ecspi3: ecspi3grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO		0x82
-			MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI		0x82
-			MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK		0x82
-			MX8MM_IOMUXC_UART2_TXD_GPIO5_IO25		0x19
-		>;
-	};
-
-	pinctrl_enet: enetgrp {
-		fsl,pins = <
-			MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x3
-			MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO		0x3
-			MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3		0x1f
-			MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2		0x1f
-			MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1		0x1f
-			MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0		0x1f
-			MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3		0x91
-			MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2		0x91
-			MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1		0x91
-			MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0		0x91
-			MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC		0x1f
-			MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC		0x91
-			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x91
-			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x1f
-			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x19 /* PHY RST */
-		>;
-	};
-
-	pinctrl_gpio_led: gpioledgrp {
-		fsl,pins = <
-			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x19
-			MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7		0x19
-			MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8		0x19
-		>;
-	};
-
-	pinctrl_gpio1: gpio1grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19
-			MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x19
-			MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11		0x19
-			MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6		0x19
-			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10		0x19
-		>;
-	};
-
-	pinctrl_gpio5: gpio5grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19
-		>;
-	};
-
-	pinctrl_i2c3: i2c3grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083
-			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083
-		>;
-	};
-
-	pinctrl_i2c4: i2c4grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x40000083
-			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x40000083
-		>;
-	};
-
-	pinctrl_pwm2: pwm2grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT			0x19
-		>;
-	};
-
-	pinctrl_reg_usb1_vbus: regusb1vbusgrp {
-		fsl,pins = <
-			MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19
-		>;
-	};
-
-	pinctrl_uart1: uart1grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x0
-			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x0
-			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x0
-			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x0
-		>;
-	};
-
-	pinctrl_uart2: uart2grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x0
-			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x0
-			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x0
-			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x0
-		>;
-	};
-
-	pinctrl_usb_eth2: usbeth2grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19
-		>;
-	};
-
-	pinctrl_usdhc2: usdhc2grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x90
-			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d0
-			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d0
-			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0
-			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0
-			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0
-			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
-		>;
-	};
-
-	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
-		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x94
-			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d4
-			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d4
-			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4
-			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4
-			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4
-			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
+			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19  /* SDIO_B_PWR_EN */
 		>;
 	};
 
-	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+	pinctrl_usb_hub: usbhubgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x96
-			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d6
-			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d6
-			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6
-			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6
-			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6
-			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
+			MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19 /* SDIO_B_WP */
 		>;
 	};
 };
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
index 6b9058fc53332..663ae52b48526 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
@@ -3,6 +3,7 @@
  * Copyright (C) 2022 Kontron Electronics GmbH
  */
 
+#include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 #include "imx8mm.dtsi"
 
@@ -28,6 +29,73 @@ memory at 40000000 {
 	chosen {
 		stdout-path = &uart3;
 	};
+
+	reg_vdd_carrier: regulator-vdd-carrier {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_vdd_carrier>;
+		gpio = <&gpio3 16 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-name = "VDD_CARRIER";
+
+		regulator-state-standby {
+			regulator-on-in-suspend;
+		};
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+
+		regulator-state-disk {
+			regulator-off-in-suspend;
+		};
+	};
+
+	reg_usb1_vbus: regulator-usb1-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usb1_vbus>;
+		enable-active-high;
+		gpio = <&gpio3 25 GPIO_ACTIVE_HIGH>;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-name = "VBUS_USB1";
+	};
+
+	reg_usb2_vbus: regulator-usb2-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usb2_vbus>;
+		enable-active-high;
+		gpio = <&gpio3 20 GPIO_ACTIVE_HIGH>;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-name = "VBUS_USB2";
+	};
+
+	reg_usdhc2_vcc: regulator-usdhc2-vcc {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usdhc2_vcc>;
+		enable-active-high;
+		gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-name = "VCC_SDIO_A";
+	};
+
+	reg_usdhc3_vcc: regulator-usdhc3-vcc {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usdhc3_vcc>;
+		enable-active-high;
+		gpio = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-name = "VCC_SDIO_B";
+	};
 };
 
 &A53_0 {
@@ -96,6 +164,79 @@ partition at 1f0000 {
 	};
 };
 
+&ecspi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi2>, <&pinctrl_ecspi2_gpio>;
+	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+};
+
+&ecspi3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi3>;
+	cs-gpios = <&gpio5 25 GPIO_ACTIVE_LOW>;
+};
+
+&gpio1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpio1>;
+	gpio-line-names = "", "GPIO_A_0", "", "GPIO_A_1",
+			  "", "GPIO_A_2", "GPIO_A_3", "GPIO_A_4",
+			  "GPIO_A_5", "GPIO_A_6", "GPIO_A_7", "GPIO_B_0",
+			  "GPIO_B_1", "USB_A_OC#", "CAM_MCK", "USB_B_OC#",
+			  "ETH_MDC", "ETH_MDIO", "ETH_A_(S)(R)(G)MII_TXD3",
+			  "ETH_A_(S)(R)(G)MII_TXD2", "ETH_A_(S)(R)(G)MII_TXD1",
+			  "ETH_A_(S)(R)(G)MII_TXD0", "ETH_A_(R)(G)MII_TX_EN(_ER)",
+			  "ETH_A_(R)(G)MII_TX_CLK", "ETH_A_(R)(G)MII_RX_DV(_ER)",
+			  "ETH_A_(R)(G)MII_RX_CLK", "ETH_A_(S)(R)(G)MII_RXD0",
+			  "ETH_A_(S)(R)(G)MII_RXD1", "ETH_A_(R)(G)MII_RXD2",
+			  "ETH_A_(R)(G)MII_RXD3";
+};
+
+&gpio2 {
+	gpio-line-names = "", "", "", "",
+			  "", "", "", "",
+			  "", "", "", "",
+			  "SDIO_A_CD#", "SDIO_A_CLK", "SDIO_A_CMD", "SDIO_A_D0",
+			  "SDIO_A_D1", "SDIO_A_D2", "SDIO_A_D3", "SDIO_A_PWR_EN",
+			  "SDIO_A_WP";
+};
+
+&gpio3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpio3>;
+	gpio-line-names = "GPIO_C_5", "GPIO_C_4", "SDIO_B_CD#", "SDIO_B_D5",
+			  "SDIO_B_D6", "SDIO_B_D7", "GPIO_C_0", "GPIO_C_1",
+			  "GPIO_C_2", "GPIO_C_3", "SDIO_B_D0", "SDIO_B_D1",
+			  "SDIO_B_D2", "SDIO_B_D3", "", "SDIO_B_D4",
+			  "CARRIER_PWR_EN", "SDIO_B_CLK", "SDIO_B_CMD", "GPIO_B_2",
+			  "USB_B_EN", "GPIO_B_3", "PCIe_CLKREQ#", "PCIe_A_PERST#",
+			  "PCIe_WAKE#", "USB_A_EN";
+};
+
+&gpio4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpio4>;
+	gpio-line-names = "GPIO_C_7", "", "I2S_A_DATA_IN", "I2S_B_DATA_IN",
+			  "GPIO_B_4", "BOOT_SEL0#", "BOOT_SEL1#", "",
+			  "", "", "I2S_LRCLK", "I2S_BITCLK",
+			  "I2S_A_DATA_OUT", "I2S_B_DATA_OUT", "GPIO_B_5", "GPIO_B_6",
+			  "GPIO_B_7", "SPI_A_/WP_(IO2)", "SPI_A_/HOLD_(IO3)", "GPIO_C_6",
+			  "I2S_MCLK", "UART_A_TX", "UART_A_RX", "UART_A_CTS",
+			  "UART_A_RTS", "", "", "",
+			  "PCIe_SM_ALERT", "UART_B_RTS", "UART_B_CTS", "UART_B_RX";
+};
+
+&gpio5 {
+	gpio-line-names = "UART_B_TX", "SDIO_B_PWR_EN", "SDIO_B_WP", "PWM_2",
+			  "PWM_1", "PWM_0", "", "",
+			  "", "", "SPI_A_SCK", "SPI_A_SDO_(IO1)",
+			  "SPI_A_SCK", "SPI_A_CS0#", "", "",
+			  "I2C_A_SCL", "I2C_A_SDA", "I2C_B_SCL", "I2C_B_SDA",
+			  "PCIe_SMCLK", "PCIe_SMDAT", "SPI_B_SCK", "SPI_B_SDO",
+			  "SPI_B_SDI", "SPI_B_CS0#", "UART_CON_RX", "UART_CON_TX",
+			  "UART_C_RX", "UART_C_TX";
+};
+
 &i2c1 {
 	clock-frequency = <400000>;
 	pinctrl-names = "default";
@@ -222,12 +363,69 @@ rv3028: rtc at 52 {
 	};
 };
 
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+};
+
+&i2c4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c4>;
+};
+
+&pwm1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm1>;
+};
+
+&pwm2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm2>;
+};
+
+&pwm3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm3>;
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+};
+
 &uart3 { /* console */
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart3>;
 	status = "okay";
 };
 
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4>;
+};
+
+&usbotg1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb1>;
+	vbus-supply = <&reg_usb1_vbus>;
+};
+
+&usbotg2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb2>;
+	vbus-supply = <&reg_usb2_vbus>;
+};
+
 &usdhc1 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz";
 	pinctrl-0 = <&pinctrl_usdhc1>;
@@ -240,6 +438,26 @@ &usdhc1 {
 	status = "okay";
 };
 
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+	vmmc-supply = <&reg_usdhc2_vcc>;
+	vqmmc-supply = <&reg_nvcc_sd>;
+	cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+};
+
+&usdhc3 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_usdhc3_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_usdhc3_gpio>;
+	vmmc-supply = <&reg_usdhc3_vcc>;
+	vqmmc-supply = <&reg_nvcc_sd>;
+	cd-gpios = <&gpio3 2 GPIO_ACTIVE_LOW>;
+};
+
 &wdog1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_wdog>;
@@ -248,6 +466,12 @@ &wdog1 {
 };
 
 &iomuxc {
+	pinctrl_csi_mck: csimckgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_GPIO1_IO14_CCMSRCGPCMIX_CLKO1	0x59 /* CAM_MCK */
+		>;
+	};
+
 	pinctrl_ecspi1: ecspi1grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO		0x82
@@ -257,6 +481,106 @@ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9		0x19
 		>;
 	};
 
+	pinctrl_ecspi2: ecspi2grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO		0x82 /* SPI_A_SDI_(IO0) */
+			MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI		0x82 /* SPI_A_SDO_(IO1) */
+			MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK		0x82 /* SPI_A_SCK */
+			MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13		0x19 /* SPI_A_CS0# */
+		>;
+	};
+
+	pinctrl_ecspi2_gpio: ecspi2gpiogrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI1_TXD5_GPIO4_IO17		0x19 /* SPI_A_/WP_(IO2) */
+			MX8MM_IOMUXC_SAI1_TXD6_GPIO4_IO18		0x19 /* SPI_A_/HOLD_(IO3) */
+		>;
+	};
+
+	pinctrl_ecspi3: ecspi3grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO		0x82 /* SPI_B_SDI */
+			MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI		0x82 /* SPI_B_SDO */
+			MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK		0x82 /* SPI_B_SCK */
+			MX8MM_IOMUXC_UART2_TXD_GPIO5_IO25		0x19 /* SPI_B_CS0# */
+		>;
+	};
+
+	pinctrl_enet_rgmii: enetrgmiigrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x03 /* ETH_MDC */
+			MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO		0x03 /* ETH_MDIO */
+			MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3		0x1f /* ETH_A_(S)(R)(G)MII_TXD3 */
+			MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2		0x1f /* ETH_A_(S)(R)(G)MII_TXD2 */
+			MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1		0x1f /* ETH_A_(S)(R)(G)MII_TXD1 */
+			MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0		0x1f /* ETH_A_(S)(R)(G)MII_TXD0 */
+			MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3		0x91 /* ETH_A_(R)(G)MII_RXD3 */
+			MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2		0x91 /* ETH_A_(R)(G)MII_RXD2 */
+			MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1		0x91 /* ETH_A_(S)(R)(G)MII_RXD1 */
+			MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0		0x91 /* ETH_A_(S)(R)(G)MII_RXD0 */
+			MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC		0x1f /* ETH_A_(R)(G)MII_TX_CLK */
+			MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC		0x91 /* ETH_A_(R)(G)MII_RX_CLK */
+			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x91 /* ETH_A_(R)(G)MII_RX_DV(_ER) */
+			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x1f /* ETH_A_(R)(G)MII_TX_EN(_ER) */
+		>;
+	};
+
+	pinctrl_enet_rmii: enetrmiigrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x03 /* ETH_MDC */
+			MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO		0x03 /* ETH_MDIO */
+			MX8MM_IOMUXC_ENET_TD2_ENET1_TX_CLK		0x4000001f /* ETH_A_(S)(R)(G)MII_TXD2 */
+			MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1		0x56 /* ETH_A_(S)(R)(G)MII_TXD1 */
+			MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0		0x56 /* ETH_A_(S)(R)(G)MII_TXD0 */
+			MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1		0x56 /* ETH_A_(S)(R)(G)MII_RXD1 */
+			MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0		0x56 /* ETH_A_(S)(R)(G)MII_RXD0 */
+			MX8MM_IOMUXC_ENET_RXC_ENET1_RX_ER		0x56 /* ETH_A_(R)(G)MII_RX_CLK */
+			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x56 /* ETH_A_(R)(G)MII_RX_DV(_ER) */
+			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x56 /* ETH_A_(R)(G)MII_TX_EN(_ER) */
+		>;
+	};
+
+	pinctrl_gpio1: gpio1grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19 /* GPIO_A_0 */
+			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x19 /* GPIO_A_1 */
+			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x19 /* GPIO_A_2 */
+			MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6		0x19 /* GPIO_A_3 */
+			MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7		0x19 /* GPIO_A_4 */
+			MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8		0x19 /* GPIO_A_5 */
+			MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x19 /* GPIO_A_6 */
+			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10		0x19 /* GPIO_A_7 */
+			MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11		0x19 /* GPIO_B_0 */
+			MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12		0x19 /* GPIO_B_1 */
+		>;
+	};
+
+	pinctrl_gpio3: gpio3grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_NAND_ALE_GPIO3_IO0			0x19 /* GPIO_C_5 */
+			MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1		0x19 /* GPIO_C_4 */
+			MX8MM_IOMUXC_NAND_DATA00_GPIO3_IO6		0x19 /* GPIO_C_0 */
+			MX8MM_IOMUXC_NAND_DATA01_GPIO3_IO7		0x19 /* GPIO_C_1 */
+			MX8MM_IOMUXC_NAND_DATA02_GPIO3_IO8		0x19 /* GPIO_C_2 */
+			MX8MM_IOMUXC_NAND_DATA03_GPIO3_IO9		0x19 /* GPIO_C_3 */
+			MX8MM_IOMUXC_SAI5_RXFS_GPIO3_IO19		0x19 /* GPIO_B_2 */
+			MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21		0x19 /* GPIO_B_3 */
+		>;
+	};
+
+	pinctrl_gpio4: gpio4grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI1_RXFS_GPIO4_IO0		0x19 /* GPIO_C_7 */
+			MX8MM_IOMUXC_SAI1_RXD2_GPIO4_IO4		0x19 /* GPIO_B_4 */
+			MX8MM_IOMUXC_SAI1_RXD3_GPIO4_IO5		0x19 /* BOOT_SEL0# */
+			MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6		0x19 /* BOOT_SEL1# */
+			MX8MM_IOMUXC_SAI1_TXD2_GPIO4_IO14		0x19 /* GPIO_B_5 */
+			MX8MM_IOMUXC_SAI1_TXD3_GPIO4_IO15		0x19 /* GPIO_B_6 */
+			MX8MM_IOMUXC_SAI1_TXD4_GPIO4_IO16		0x19 /* GPIO_B_7 */
+			MX8MM_IOMUXC_SAI1_TXD7_GPIO4_IO19		0x19 /* GPIO_C_6 */
+		>;
+	};
+
 	pinctrl_i2c1: i2c1grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL			0x40000083
@@ -264,22 +588,149 @@ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA			0x40000083
 		>;
 	};
 
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL			0x40000083 /* I2C_A_SCL */
+			MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA			0x40000083 /* I2C_A_SDA */
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083 /* I2C_B_SCL */
+			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083 /* I2C_B_SDA */
+		>;
+	};
+
+	pinctrl_i2c4: i2c4grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x40000083 /* PCIe_SMCLK and I2C_CAM_SCL/CSI_TX_P */
+			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x40000083 /* PCIe_SMDAT and I2C_CAM_SDA/CSI_TX_N */
+		>;
+	};
+
+	pinctrl_pcie: pciegrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22		0x19 /* PCIe_CLKREQ# */
+			MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23		0x19 /* PCIe_A_PERST# */
+			MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24		0x19 /* PCIe_WAKE# */
+			MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28		0x19 /* PCIe_SM_ALERT */
+		>;
+	};
+
 	pinctrl_pmic: pmicgrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0		0x141
 		>;
 	};
 
+	pinctrl_pwm1: pwm1grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SPDIF_EXT_CLK_PWM1_OUT		0x19 /* PWM_0 */
+		>;
+	};
+
+	pinctrl_pwm2: pwm2grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT			0x19 /* PWM_1 */
+		>;
+	};
+
+	pinctrl_pwm3: pwm3grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SPDIF_TX_PWM3_OUT			0x19 /* PWM_2 */
+		>;
+	};
+
+	pinctrl_reg_usb1_vbus: regusb1vbusgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19 /* USB_A_EN */
+		>;
+	};
+
+	pinctrl_reg_usb2_vbus: regusb2vbusgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20		0x19 /* USB_B_EN */
+		>;
+	};
+
+	pinctrl_reg_usdhc2_vcc: regusdhc2vccgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19		0x19 /* SDIO_A_PWR_EN */
+		>;
+	};
+
+	pinctrl_reg_usdhc3_vcc: regusdhc3vccgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19 /* SDIO_B_PWR_EN */
+		>;
+	};
+
+	pinctrl_reg_vdd_carrier: regvddcarriergrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_NAND_READY_B_GPIO3_IO16		0x19 /* CARRIER_PWR_EN */
+		>;
+	};
+
 	pinctrl_rtc: rtcgrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_SAI1_RXC_GPIO4_IO1			0x19
 		>;
 	};
 
+	pinctrl_sai1: sai1grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI1_RXD0_SAI1_RX_DATA0		0xd6 /* I2S_A_DATA_IN */
+			MX8MM_IOMUXC_SAI1_TXD0_SAI1_TX_DATA0		0xd6 /* I2S_A_DATA_OUT */
+			MX8MM_IOMUXC_SAI1_RXD1_SAI1_RX_DATA1		0xd6 /* I2S_B_DATA_IN */
+			MX8MM_IOMUXC_SAI1_TXD1_SAI1_TX_DATA1		0xd6 /* I2S_B_DATA_OUT */
+			MX8MM_IOMUXC_SAI1_MCLK_SAI1_MCLK		0xd6 /* I2S_MCLK */
+			MX8MM_IOMUXC_SAI1_TXFS_SAI1_TX_SYNC		0xd6 /* I2S_LRCLK */
+			MX8MM_IOMUXC_SAI1_TXC_SAI1_TX_BCLK		0xd6 /* I2S_BITCLK */
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x0 /* UART_A_RX */
+			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x0 /* UART_A_TX */
+			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x0 /* UART_A_CTS */
+			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x0 /* UART_A_RTS */
+		>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x0 /* UART_B_RX */
+			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x0 /* UART_B_TX */
+			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x0 /* UART_B_CTS */
+			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x0 /* UART_B_RTS */
+		>;
+	};
+
 	pinctrl_uart3: uart3grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX		0x140
-			MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX		0x140
+			MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX		0x140 /* UART_CON_RX */
+			MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX		0x140 /* UART_CON_TX */
+		>;
+	};
+
+	pinctrl_uart4: uart4grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX		0x0 /* UART_C_RX */
+			MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX		0x0 /* UART_C_TX */
+		>;
+	};
+
+	pinctrl_usb1: usb1grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_GPIO1_IO13_USB1_OTG_OC		0x19 /* USB_A_OC# */
+		>;
+	};
+
+	pinctrl_usb2: usb2grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_GPIO1_IO15_USB2_OTG_OC		0x19 /* USB_B_OC# */
 		>;
 	};
 
@@ -334,6 +785,103 @@ MX8MM_IOMUXC_SD1_STROBE_USDHC1_STROBE		0x196
 		>;
 	};
 
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x90 /* SDIO_A_CLK */
+			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d0 /* SDIO_A_CMD */
+			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d0 /* SDIO_A_D0 */
+			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0 /* SDIO_A_D1 */
+			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0 /* SDIO_A_D2 */
+			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0 /* SDIO_A_D3 */
+			MX8MM_IOMUXC_SD2_WP_USDHC2_WP			0x400000d6 /* SDIO_A_WP */
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
+		>;
+	};
+
+	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x94 /* SDIO_A_CLK */
+			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d4 /* SDIO_A_CMD */
+			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d4 /* SDIO_A_D0 */
+			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4 /* SDIO_A_D1 */
+			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4 /* SDIO_A_D2 */
+			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4 /* SDIO_A_D3 */
+			MX8MM_IOMUXC_SD2_WP_USDHC2_WP			0x400000d6 /* SDIO_A_WP */
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
+		>;
+	};
+
+	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x96 /* SDIO_A_CLK */
+			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d6 /* SDIO_A_CMD */
+			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d6 /* SDIO_A_D0 */
+			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6 /* SDIO_A_D1 */
+			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6 /* SDIO_A_D2 */
+			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6 /* SDIO_A_D3 */
+			MX8MM_IOMUXC_SD2_WP_USDHC2_WP			0x400000d6 /* SDIO_A_WP */
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19 /* SDIO_A_CD# */
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x90 /* SDIO_B_CLK */
+			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x90 /* SDIO_B_CMD */
+			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x90 /* SDIO_B_D0 */
+			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x90 /* SDIO_B_D1 */
+			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x90 /* SDIO_B_D2 */
+			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x90 /* SDIO_B_D3 */
+			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x90 /* SDIO_B_D4 */
+			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x90 /* SDIO_B_D5 */
+			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x90 /* SDIO_B_D6 */
+			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x90 /* SDIO_B_D7 */
+		>;
+	};
+
+	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x94 /* SDIO_B_CLK */
+			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x94 /* SDIO_B_CMD */
+			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x94 /* SDIO_B_D0 */
+			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x94 /* SDIO_B_D1 */
+			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x94 /* SDIO_B_D2 */
+			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x94 /* SDIO_B_D3 */
+			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x94 /* SDIO_B_D4 */
+			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x94 /* SDIO_B_D5 */
+			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x94 /* SDIO_B_D6 */
+			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x94 /* SDIO_B_D7 */
+		>;
+	};
+
+	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x96 /* SDIO_B_CLK */
+			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x96 /* SDIO_B_CMD */
+			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x96 /* SDIO_B_D0 */
+			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x96 /* SDIO_B_D1 */
+			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x96 /* SDIO_B_D2 */
+			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x96 /* SDIO_B_D3 */
+			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x96 /* SDIO_B_D4 */
+			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x96 /* SDIO_B_D5 */
+			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x96 /* SDIO_B_D6 */
+			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x96 /* SDIO_B_D7 */
+		>;
+	};
+
+	pinctrl_usdhc3_gpio: usdhc3gpiogrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2		0x19 /* SDIO_B_CD# */
+			MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19 /* SDIO_B_WP */
+		>;
+	};
+
 	pinctrl_wdog: wdoggrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B		0xc6
-- 
2.43.0



From frieder.schrempf at kontron.de  Wed Dec  6 06:46:08 2023
From: frieder.schrempf at kontron.de (Frieder Schrempf)
Date: Wed, 6 Dec 2023 15:46:08 +0100
Subject: [PATCH v2 01/14] arm64: dts: imx8mm-kontron: Add support for
 display bridges on BL i.MX8MM
In-Reply-To: <20231206023434.GL236001@dragon>
References: <20231130161657.556483-1-frieder@fris.de>
 <20231130161657.556483-2-frieder@fris.de> <20231206023434.GL236001@dragon>
Message-ID: <34c64ffb-8d3c-478e-a8be-6a26e53b33b9@kontron.de>

Hi Shawn,

thanks for reviewing!

On 06.12.23 03:34, Shawn Guo wrote:
> On Thu, Nov 30, 2023 at 05:16:01PM +0100, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf at kontron.de>
>>
>> The Kontron Electronics BL i.MX8MM has oboard disply bridges for
>> DSI->HDMI and DSI->LVDS conversion. The DSI interface is muxed by
>> a GPIO-controlled switch to one of these two bridges.
>>
>> By default the HDMI bridge is enabled. The LVDS bridge can be
>> selected by loading an additional (panel-specific) overlay.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
>> ---
>> Changes for v2:
>> * Rework DSI mux GPIO logic to be compatible with overlay
>> * Switch from 4 to 2 DSI lanes for LVDS bridge to fix non-working display
>> ---
>>  .../boot/dts/freescale/imx8mm-kontron-bl.dts  | 158 ++++++++++++++++++
>>  1 file changed, 158 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
>> index dcec57c20399e..0fb16b811461e 100644
>> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
>> @@ -25,6 +25,17 @@ osc_can: clock-osc-can {
>>  		clock-output-names = "osc-can";
>>  	};
>>  
>> +	hdmi-out {
>> +		compatible = "hdmi-connector";
>> +		type = "a";
>> +
>> +		port {
>> +			hdmi_in_conn: endpoint {
>> +				remote-endpoint = <&bridge_out_conn>;
>> +			};
>> +		};
>> +	};
>> +
>>  	leds {
>>  		compatible = "gpio-leds";
>>  		pinctrl-names = "default";
>> @@ -132,6 +143,102 @@ ethphy: ethernet-phy at 0 {
>>  	};
>>  };
>>  
>> +&gpio4 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_gpio4>;
>> +
>> +	dsi_mux_sel_hdmi: dsi-mux-sel-hdmi-hog {
>> +		gpio-hog;
>> +		gpios = <14 GPIO_ACTIVE_HIGH>;
>> +		output-high;
>> +		line-name = "dsi-mux-sel";
>> +		status = "okay";
> 
> Status "okay" is usually used to flip "disabled".

Right, fixed in v3

>> +	};
>> +
>> +	dsi_mux_sel_lvds: dsi-mux-sel-lvds-hog {
>> +		gpio-hog;
>> +		gpios = <14 GPIO_ACTIVE_HIGH>;
>> +		output-low;
>> +		line-name = "dsi-mux-sel";
>> +		status = "disabled";
>> +	};
>> +
>> +	dsi-mux-oe-hog {
>> +		gpio-hog;
>> +		gpios = <15 GPIO_ACTIVE_LOW>;
>> +		output-high;
>> +		line-name = "dsi-mux-oe";
>> +	};
>> +};
>> +
>> +&i2c3 {
>> +	clock-frequency = <400000>;
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_i2c3>;
>> +	status = "okay";
>> +
>> +	hdmi: hdmi at 39 {
>> +		compatible = "adi,adv7535";
>> +		reg = <0x39>;
>> +
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_adv7535>;
>> +
>> +		interrupt-parent = <&gpio4>;
>> +		interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
>> +
>> +		adi,dsi-lanes = <4>;
>> +
>> +		a2vdd-supply = <&reg_vdd_1v8>;
>> +		avdd-supply = <&reg_vdd_1v8>;
>> +		dvdd-supply = <&reg_vdd_1v8>;
>> +		pvdd-supply = <&reg_vdd_1v8>;
>> +		v1p2-supply = <&reg_vdd_1v8>;
>> +		v3p3-supply = <&reg_vdd_3v3>;
>> +
>> +		ports {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			port at 0 {
>> +				reg = <0>;
> 
> Have a newline between properties and child node.

Fixed in v3

Thanks
Frieder

> 
>> +				bridge_in_dsi_hdmi: endpoint {
>> +					remote-endpoint = <&dsi_out_bridge>;
>> +				};
>> +			};
>> +
>> +			port at 1 {
>> +				reg = <1>;
>> +				bridge_out_conn: endpoint {
>> +					remote-endpoint = <&hdmi_in_conn>;
>> +				};
>> +			};
>> +		};
>> +	};
>> +
>> +	lvds: bridge at 2c {
>> +		compatible = "ti,sn65dsi84";
>> +		reg = <0x2c>;
>> +		enable-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_sn65dsi84>;
>> +		status = "disabled";
>> +
>> +		ports {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			port at 0 {
>> +				reg = <0>;
>> +				bridge_in_dsi_lvds: endpoint {
>> +					remote-endpoint = <&dsi_out_bridge>;
>> +					data-lanes = <1 2>;
>> +				};
>> +			};
>> +		};
>> +	};
>> +};
>> +
>>  &i2c4 {
>>  	clock-frequency = <100000>;
>>  	pinctrl-names = "default";
>> @@ -144,6 +251,30 @@ rx8900: rtc at 32 {
>>  	};
>>  };
>>  
>> +&lcdif {
>> +	status = "okay";
>> +};
>> +
>> +&mipi_dsi {
>> +	samsung,esc-clock-frequency = <54000000>;
>> +	/*
>> +	 * Let the driver calculate an appropriate clock rate based on the pixel
>> +	 * clock instead of using the fixed value from imx8mm.dtsi.
>> +	 */
>> +	/delete-property/ samsung,pll-clock-frequency;
>> +	status = "okay";
>> +
>> +	ports {
>> +		port at 1 {
>> +			reg = <1>;
>> +
>> +			dsi_out_bridge: endpoint {
>> +				remote-endpoint = <&bridge_in_dsi_hdmi>;
>> +			};
>> +		};
>> +	};
>> +};
>> +
>>  &pwm2 {
>>  	pinctrl-names = "default";
>>  	pinctrl-0 = <&pinctrl_pwm2>;
>> @@ -207,6 +338,12 @@ &iomuxc {
>>  	pinctrl-names = "default";
>>  	pinctrl-0 = <&pinctrl_gpio>;
>>  
>> +	pinctrl_adv7535: adv7535grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI1_TXD4_GPIO4_IO16		0x19
>> +		>;
>> +	};
>> +
>>  	pinctrl_can: cangrp {
>>  		fsl,pins = <
>>  			MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28		0x19
>> @@ -277,6 +414,20 @@ MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19
>>  		>;
>>  	};
>>  
>> +	pinctrl_gpio4: gpio4grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI1_TXD2_GPIO4_IO14		0x19
>> +			MX8MM_IOMUXC_SAI1_TXD3_GPIO4_IO15		0x19
>> +		>;
>> +	};
>> +
>> +	pinctrl_i2c3: i2c3grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083
>> +			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083
>> +		>;
>> +	};
>> +
>>  	pinctrl_i2c4: i2c4grp {
>>  		fsl,pins = <
>>  			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x400001c3
>> @@ -290,6 +441,13 @@ MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT			0x19
>>  		>;
>>  	};
>>  
>> +	pinctrl_sn65dsi84: sn65dsi84grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI2_TXD0_GPIO4_IO26		0x19
>> +			MX8MM_IOMUXC_SD2_WP_GPIO2_IO20			0x19
>> +		>;
>> +	};
>> +
>>  	pinctrl_uart1: uart1grp {
>>  		fsl,pins = <
>>  			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x140
>> -- 
>> 2.43.0
>>


From festevam at gmail.com  Wed Dec  6 06:47:35 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 6 Dec 2023 11:47:35 -0300
Subject: [PATCH v3 01/14] arm64: dts: imx8mm-kontron: Add support for
 display bridges on BL i.MX8MM
In-Reply-To: <20231206144201.46911-2-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de> <20231206144201.46911-2-frieder@fris.de>
Message-ID: <CAOMZO5Akp9PsFf2GrSFTKyM1c3kSUEeU=W9ODgiMkyHATRWHOw@mail.gmail.com>

Hi Frieder,

On Wed, Dec 6, 2023 at 11:44?AM Frieder Schrempf <frieder at fris.de> wrote:

> +               a2vdd-supply = <&reg_vdd_1v8>;
> +               avdd-supply = <&reg_vdd_1v8>;
> +               dvdd-supply = <&reg_vdd_1v8>;
> +               pvdd-supply = <&reg_vdd_1v8>;
> +               v1p2-supply = <&reg_vdd_1v8>;

Supplying 1.8V to v1p2-supply looks strange.


From conor at kernel.org  Wed Dec  6 06:47:59 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 6 Dec 2023 14:47:59 +0000
Subject: [PATCH 1/2] dt-bindings: arm: fsl: Add TQ-Systems LX2160A based
 boards
In-Reply-To: <20231206-for-ml-tqmlx2160a-v1-1-622e41ae4d8e@ew.tq-group.com>
References: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>
 <20231206-for-ml-tqmlx2160a-v1-1-622e41ae4d8e@ew.tq-group.com>
Message-ID: <20231206-turban-comma-97e617bcc46c@spud>

On Wed, Dec 06, 2023 at 03:01:01PM +0100, Gregor Herburger wrote:
> TQMLX2160A is a TQ-Systems GmbH SoM using the LX2160A SoC.
> MBLX2160a is the starterkit baseboard for TQMLX2160A.
> 
> Signed-off-by: Gregor Herburger <gregor.herburger at ew.tq-group.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/f65d7c6f/attachment.sig>

From frieder.schrempf at kontron.de  Wed Dec  6 06:48:39 2023
From: frieder.schrempf at kontron.de (Frieder Schrempf)
Date: Wed, 6 Dec 2023 15:48:39 +0100
Subject: [PATCH v2 02/14] arm64: dts: imx8mm-kontron: Add DL
 (Display-Line) overlay with LVDS support
In-Reply-To: <20231206024355.GM236001@dragon>
References: <20231130161657.556483-1-frieder@fris.de>
 <20231130161657.556483-3-frieder@fris.de> <20231206024355.GM236001@dragon>
Message-ID: <b6cb832f-4e20-4737-a129-493f487a537a@kontron.de>

On 06.12.23 03:43, Shawn Guo wrote:
> On Thu, Nov 30, 2023 at 05:16:02PM +0100, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf at kontron.de>
>>
>> The Kontron Electronics DL i.MX8MM consists of the BL i.MX8MM board
>> and a 7" LVDS panel. Provide an overlay that enables the panel.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
>> ---
>> Changes for v2:
>> * Rework DSI mux GPIO logic to be compatible with overlay
>> ---
>>  arch/arm64/boot/dts/freescale/Makefile        |   4 +
>>  .../boot/dts/freescale/imx8mm-kontron-dl.dtso | 200 ++++++++++++++++++
>>  2 files changed, 204 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso
>>
>> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
>> index 300049037eb0b..e08024797721a 100644
>> --- a/arch/arm64/boot/dts/freescale/Makefile
>> +++ b/arch/arm64/boot/dts/freescale/Makefile
>> @@ -166,6 +166,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
>>  dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
>>  dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla.dtb
>>  
>> +imx8mm-kontron-dl-dtbs			:= imx8mm-kontron-bl.dtb imx8mm-kontron-dl.dtbo
>> +
>> +dtb-$(CONFIG_ARCH_MXC) += imx8mm-kontron-dl.dtb
>> +
>>  imx8mm-venice-gw72xx-0x-imx219-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-imx219.dtbo
>>  imx8mm-venice-gw72xx-0x-rpidsi-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rpidsi.dtbo
>>  imx8mm-venice-gw72xx-0x-rs232-rts-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rs232-rts.dtbo
>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso b/arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso
>> new file mode 100644
>> index 0000000000000..c6369072577e0
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso
>> @@ -0,0 +1,200 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2023 Kontron Electronics GmbH
>> + */
>> +
>> +/dts-v1/;
>> +/plugin/;
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include "imx8mm-pinfunc.h"
>> +
>> +&{/} {
>> +	compatible = "kontron,imx8mm-bl", "kontron,imx8mm-sl", "fsl,imx8mm";
>> +
>> +	backlight: backlight {
>> +		compatible = "pwm-backlight";
>> +		pwms = <&pwm1 0 50000 0>;
>> +		brightness-levels = <0 100>;
>> +		num-interpolated-steps = <100>;
>> +		default-brightness-level = <100>;
>> +	};
>> +
>> +	panel {
>> +		compatible = "panel-lvds";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_panel>;
>> +		backlight = <&backlight>;
>> +		data-mapping = "vesa-24";
>> +		enable-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
>> +		height-mm = <86>;
>> +		width-mm = <154>;
>> +
>> +		panel-timing {
>> +			clock-frequency = <51200000>;
>> +			hactive = <1024>;
>> +			vactive = <600>;
>> +			hsync-len = <1>;
>> +			hfront-porch = <160>;
>> +			hback-porch = <160>;
>> +			vsync-len = <1>;
>> +			vfront-porch = <12>;
>> +			vback-porch = <23>;
>> +		};
>> +
>> +		port {
>> +			panel_out_bridge: endpoint {
>> +				remote-endpoint = <&bridge_out_panel>;
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&dsi_mux_sel_hdmi {
>> +	status = "disabled";
>> +};
>> +
>> +&dsi_mux_sel_lvds {
>> +	status = "okay";
>> +};
>> +
>> +&dsi_out_bridge {
>> +	remote-endpoint = <&bridge_in_dsi_lvds>;
>> +};
>> +
>> +&gpio3 {
>> +	panel_rst {
>> +		gpio-hog;
>> +		gpios = <20 GPIO_ACTIVE_HIGH>;
>> +		output-high;
>> +		line-name = "panel-reset";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_panel_rst>;
>> +	};
>> +
>> +	panel_stby {
>> +		gpio-hog;
>> +		gpios = <21 GPIO_ACTIVE_HIGH>;
>> +		output-high;
>> +		line-name = "panel-standby";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_panel_stby>;
>> +	};
>> +
>> +	panel_hinv {
>> +		gpio-hog;
>> +		gpios = <24 GPIO_ACTIVE_HIGH>;
>> +		output-high;
>> +		line-name = "panel-horizontal-invert";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_panel_hinv>;
>> +	};
>> +
>> +	panel_vinv {
>> +		gpio-hog;
>> +		gpios = <25 GPIO_ACTIVE_HIGH>;
>> +		output-low;
>> +		line-name = "panel-vertical-invert";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_panel_vinv>;
>> +	};
>> +};
>> +
>> +&hdmi {
>> +	status = "disabled";
>> +};
>> +
>> +&i2c2 {
>> +	clock-frequency = <400000>;
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_i2c2>;
>> +	status = "okay";
>> +
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +
>> +	gt911 at 5d {
>> +		compatible = "goodix,gt928";
>> +		reg = <0x5d>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_touch>;
>> +		interrupt-parent = <&gpio3>;
>> +		interrupts = <22 8>;
>> +		reset-gpios = <&gpio3 23 0>;
>> +		irq-gpios = <&gpio3 22 0>;
>> +	};
>> +};
>> +
>> +&lvds {
>> +	status = "okay";
>> +
>> +	ports {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		port at 2 {
>> +			reg = <2>;
> 
> Have a newline between properties and child node.

Sure, fixed in v3

> 
>> +			bridge_out_panel: endpoint {
>> +				remote-endpoint = <&panel_out_bridge>;
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&pwm1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_pwm1>;
>> +	status = "okay";
>> +};
>> +
>> +&iomuxc {
>> +	pinctrl_panel_rst: panelrstgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20		0x19
>> +		>;
>> +	};
>> +
>> +	pinctrl_panel_stby: panelstbygrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21		0x19
>> +		>;
>> +	};
>> +
>> +	pinctrl_panel_hinv: panelhinvgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24		0x19
>> +		>;
>> +	};
>> +
>> +	pinctrl_panel_vinv: panelvinvgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19
>> +		>;
>> +	};
>> +
>> +	pinctrl_i2c2: i2c2grp {
> 
> Could you sort the pinctrl nodes alphabetically?

Sure, done in v3

Thanks
Frieder

>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL			0x40000083
>> +			MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA			0x40000083
>> +		>;
>> +	};
>> +
>> +	pinctrl_pwm1: pwm1grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SPDIF_EXT_CLK_PWM1_OUT		0x6
>> +		>;
>> +	};
>> +
>> +	pinctrl_panel: panelgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI5_RXFS_GPIO3_IO19		0x19
>> +		>;
>> +	};
>> +
>> +	pinctrl_touch: touchgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22		0x19
>> +			MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23		0x19
>> +		>;
>> +	};
>> +};
>> -- 
>> 2.43.0
>>


From catalin.marinas at arm.com  Wed Dec  6 06:49:02 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 6 Dec 2023 14:49:02 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231205194822.GL2692119@nvidia.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
Message-ID: <ZXCJ3pVbKuHJ3LTz@arm.com>

On Tue, Dec 05, 2023 at 03:48:22PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 05, 2023 at 07:24:37PM +0000, Catalin Marinas wrote:
> > On Tue, Dec 05, 2023 at 12:43:18PM -0400, Jason Gunthorpe wrote:
> > > What if we change vfio-pci to use pgprot_device() like it already
> > > really should and say the pgprot_noncached() is enforced as
> > > DEVICE_nGnRnE and pgprot_device() may be DEVICE_nGnRE or NORMAL_NC?
> > > Would that be acceptable?
> > 
> > pgprot_device() needs to stay as Device, otherwise you'd get speculative
> > reads with potential side-effects.
> 
> I do not mean to change pgprot_device() I mean to detect the
> difference via pgprot_device() vs pgprot_noncached(). They put a
> different value in the PTE that we can sense. It is very hacky.

Ah, ok, it does look hacky though (as is the alternative of coming up
with a new specific pgprot_*() that KVM can treat differently).

BTW, on those Mellanox devices that require different attributes within
a BAR, do they have a problem with speculative reads causing
side-effects? If not, we might as well map the whole BAR in user as
Normal NC but have the guest use the appropriate attributes within the
BAR. The VMM wouldn't explicitly access the BAR but we'd get the
occasional speculative reads.

-- 
Catalin


From frieder.schrempf at kontron.de  Wed Dec  6 06:49:31 2023
From: frieder.schrempf at kontron.de (Frieder Schrempf)
Date: Wed, 6 Dec 2023 15:49:31 +0100
Subject: [PATCH v2 14/14] arm64: dts: imx8mm-kontron: Refactor devicetree
 for OSM-S module and board
In-Reply-To: <20231206030125.GN236001@dragon>
References: <20231130161657.556483-1-frieder@fris.de>
 <20231130161657.556483-15-frieder@fris.de> <20231206030125.GN236001@dragon>
Message-ID: <ecfc73fe-11a6-46b7-b97a-6e31bce73904@kontron.de>

On 06.12.23 04:01, Shawn Guo wrote:
> On Thu, Nov 30, 2023 at 05:16:14PM +0100, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf at kontron.de>
>>
>> The OSM spec defines dedicated functions for all pads of the SoM.
>> Therefore we can assume that carrier board designs stick to these
>> definitions and extend the SoM devicetree include with matching
>> default nodes and pinmux settings.
>>
>> This way we can reduce the overhead and redundancy in the carrier
>> board devicetrees while still sticking to the policy of separating
>> board and module description.
>>
>> Even if the carrier board design deviates slightly from the spec it
>> can define its own pinmux definitions and use them as necessary or
>> even disable unused nodes from the SoM devicetree.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
>> ---
>> Changes for v2:
>> * none
>> ---
>>  .../dts/freescale/imx8mm-kontron-bl-osm-s.dts | 269 +++------
>>  .../dts/freescale/imx8mm-kontron-osm-s.dtsi   | 552 +++++++++++++++++-
>>  2 files changed, 616 insertions(+), 205 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
>> index 12f786a72fbd5..efadfdff00af1 100644
>> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts
>> @@ -25,8 +25,6 @@ osc_can: clock-osc-can {
>>  
>>  	leds {
>>  		compatible = "gpio-leds";
>> -		pinctrl-names = "default";
>> -		pinctrl-0 = <&pinctrl_gpio_led>;
>>  
>>  		led1 {
>>  			label = "led1";
>> @@ -52,24 +50,12 @@ pwm-beeper {
>>  
>>  	reg_rst_eth2: regulator-rst-eth2 {
>>  		compatible = "regulator-fixed";
>> -		pinctrl-names = "default";
>> -		pinctrl-0 = <&pinctrl_usb_eth2>;
>>  		gpio = <&gpio1 1 GPIO_ACTIVE_HIGH>;
>>  		enable-active-high;
>>  		regulator-always-on;
>>  		regulator-name = "rst-usb-eth2";
>>  	};
>>  
>> -	reg_usb1_vbus: regulator-usb1-vbus {
>> -		compatible = "regulator-fixed";
>> -		pinctrl-names = "default";
>> -		pinctrl-0 = <&pinctrl_reg_usb1_vbus>;
>> -		gpio = <&gpio3 25 GPIO_ACTIVE_LOW>;
>> -		regulator-min-microvolt = <5000000>;
>> -		regulator-max-microvolt = <5000000>;
>> -		regulator-name = "usb1-vbus";
>> -	};
>> -
>>  	reg_vdd_5v: regulator-5v {
>>  		compatible = "regulator-fixed";
>>  		regulator-always-on;
>> @@ -80,9 +66,6 @@ reg_vdd_5v: regulator-5v {
>>  };
>>  
>>  &ecspi2 {
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_ecspi2>;
>> -	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
>>  	status = "okay";
>>  
>>  	can at 0 {
>> @@ -103,9 +86,6 @@ can at 0 {
>>  };
>>  
>>  &ecspi3 {
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_ecspi3>;
>> -	cs-gpios = <&gpio5 25 GPIO_ACTIVE_LOW>;
>>  	status = "okay";
>>  
>>  	eeram at 0 {
>> @@ -117,7 +97,7 @@ eeram at 0 {
>>  
>>  &fec1 {
>>  	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_enet>;
>> +	pinctrl-0 = <&pinctrl_enet_rgmii>;
>>  	phy-connection-type = "rgmii-id";
>>  	phy-handle = <&ethphy>;
>>  	status = "okay";
>> @@ -136,27 +116,59 @@ ethphy: ethernet-phy at 0 {
>>  	};
>>  };
>>  
>> +/*
>> + * Rename SoM signals according to board usage:
>> + *   GPIO_B_0      -> DIO1_OUT
>> + *   GPIO_B_1      -> DIO2_OUT
>> + */
>>  &gpio1 {
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_gpio1>;
>> -	gpio-line-names = "", "", "", "dio1-out", "", "", "dio1-in", "dio2-out",
>> -			  "dio2-in", "dio3-out", "dio3-in", "dio4-out", "", "", "", "",
>> -			  "", "", "", "", "", "", "", "",
>> -			  "", "", "", "", "", "", "", "";
>> +	gpio-line-names = "", "GPIO_A_0", "", "GPIO_A_1",
>> +			  "", "GPIO_A_2", "GPIO_A_3", "GPIO_A_4",
>> +			  "GPIO_A_5", "GPIO_A_6", "GPIO_A_7", "DIO1_OUT",
>> +			  "DIO2_OUT", "USB_A_OC#", "CAM_MCK", "USB_B_OC#",
>> +			  "ETH_MDC", "ETH_MDIO", "ETH_A_(S)(R)(G)MII_TXD3",
>> +			  "ETH_A_(S)(R)(G)MII_TXD2", "ETH_A_(S)(R)(G)MII_TXD1",
>> +			  "ETH_A_(S)(R)(G)MII_TXD0", "ETH_A_(R)(G)MII_TX_EN(_ER)",
>> +			  "ETH_A_(R)(G)MII_TX_CLK", "ETH_A_(R)(G)MII_RX_DV(_ER)",
>> +			  "ETH_A_(R)(G)MII_RX_CLK", "ETH_A_(S)(R)(G)MII_RXD0",
>> +			  "ETH_A_(S)(R)(G)MII_RXD1", "ETH_A_(R)(G)MII_RXD2",
>> +			  "ETH_A_(R)(G)MII_RXD3";
>>  };
>>  
>> -&gpio5 {
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_gpio5>;
>> -	gpio-line-names = "", "", "dio4-in", "", "", "", "", "",
>> -			  "", "", "", "", "", "", "", "",
>> -			  "", "", "", "", "", "", "", "",
>> -			  "", "", "", "", "", "", "", "";
>> +/*
>> + * Rename SoM signals according to board usage:
>> + *   GPIO_B_2      -> DIO3_OUT
>> + *   GPIO_B_3      -> DIO4_OUT
>> + */
>> +&gpio3 {
>> +	gpio-line-names = "GPIO_C_5", "GPIO_C_4", "SDIO_B_CD#", "SDIO_B_D5",
>> +			  "SDIO_B_D6", "SDIO_B_D7", "GPIO_C_0", "GPIO_C_1",
>> +			  "GPIO_C_2", "GPIO_C_3", "SDIO_B_D0", "SDIO_B_D1",
>> +			  "SDIO_B_D2", "SDIO_B_D3", "", "SDIO_B_D4",
>> +			  "CARRIER_PWR_EN", "SDIO_B_CLK", "SDIO_B_CMD", "DIO3_OUT",
>> +			  "USB_B_EN", "DIO4_OUT", "PCIe_CLKREQ#", "PCIe_A_PERST#",
>> +			  "PCIe_WAKE#", "USB_A_EN";
>> +};
>> +
>> +/*
>> + * Rename SoM signals according to board usage:
>> + *   GPIO_B_4      -> DIO1_IN
>> + *   GPIO_B_5      -> DIO2_IN
>> + *   GPIO_B_6      -> DIO3_IN
>> + *   GPIO_B_7      -> DIO4_IN
>> + */
>> +&gpio4 {
>> +	gpio-line-names = "GPIO_C_7", "", "I2S_A_DATA_IN", "I2S_B_DATA_IN",
>> +			  "DIO1_IN", "BOOT_SEL0#", "BOOT_SEL1#", "",
>> +			  "", "", "I2S_LRCLK", "I2S_BITCLK",
>> +			  "I2S_A_DATA_OUT", "I2S_B_DATA_OUT", "DIO2_IN", "DIO3_IN",
>> +			  "DIO4_IN", "SPI_A_/WP_(IO2)", "SPI_A_/HOLD_(IO3)", "GPIO_C_6",
>> +			  "I2S_MCLK", "UART_A_TX", "UART_A_RX", "UART_A_CTS",
>> +			  "UART_A_RTS", "", "", "",
>> +			  "PCIe_SM_ALERT", "UART_B_RTS", "UART_B_CTS", "UART_B_RX";
>>  };
>>  
>>  &i2c3 {
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_i2c3>;
>>  	status = "okay";
>>  
>>  	usb-hub at 2c {
>> @@ -169,27 +181,28 @@ usb-hub at 2c {
>>  	};
>>  };
>>  
>> -&i2c4 {
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_i2c4>;
>> -};
>> -
>>  &pwm2 {
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_pwm2>;
>>  	status = "okay";
>>  };
>>  
>> +&reg_usb2_vbus {
>> +	status = "disabled";
>> +};
>> +
>> +&reg_usdhc2_vcc {
>> +	status = "disabled";
>> +};
>> +
>> +&reg_usdhc3_vcc {
>> +	status = "disabled";
>> +};
>> +
>>  &uart1 {
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_uart1>;
>>  	uart-has-rtscts;
>>  	status = "okay";
>>  };
>>  
>>  &uart2 {
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&pinctrl_uart2>;
>>  	linux,rs485-enabled-at-boot-time;
>>  	uart-has-rtscts;
>>  	status = "okay";
>> @@ -197,8 +210,6 @@ &uart2 {
>>  
>>  &usbotg1 {
>>  	dr_mode = "otg";
>> -	disable-over-current;
>> -	vbus-supply = <&reg_usb1_vbus>;
>>  	status = "okay";
>>  };
>>  
>> @@ -209,6 +220,9 @@ &usbotg2 {
>>  	#size-cells = <0>;
>>  	status = "okay";
>>  
>> +	/* VBUS is controlled by the hub */
>> +	/delete-property/ vbus-supply;
>> +
>>  	usb1 at 1 {
>>  		compatible = "usb424,2514";
>>  		reg = <1>;
>> @@ -224,171 +238,20 @@ usbnet: ethernet at 1 {
>>  };
>>  
>>  &usdhc2 {
>> -	pinctrl-names = "default", "state_100mhz", "state_200mhz";
>> -	pinctrl-0 = <&pinctrl_usdhc2>;
>> -	pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
>> -	pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
>>  	vmmc-supply = <&reg_vdd_3v3>;
>> -	vqmmc-supply = <&reg_nvcc_sd>;
>> -	cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
>>  	status = "okay";
>>  };
>>  
>>  &iomuxc {
>>  	pinctrl_can: cangrp {
>>  		fsl,pins = <
>> -			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19
>> -		>;
>> -	};
>> -
>> -	pinctrl_ecspi2: ecspi2grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO		0x82
>> -			MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI		0x82
>> -			MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK		0x82
>> -			MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13		0x19
>> -		>;
>> -	};
>> -
>> -	pinctrl_ecspi3: ecspi3grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO		0x82
>> -			MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI		0x82
>> -			MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK		0x82
>> -			MX8MM_IOMUXC_UART2_TXD_GPIO5_IO25		0x19
>> -		>;
>> -	};
>> -
>> -	pinctrl_enet: enetgrp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x3
>> -			MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO		0x3
>> -			MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3		0x1f
>> -			MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2		0x1f
>> -			MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1		0x1f
>> -			MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0		0x1f
>> -			MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3		0x91
>> -			MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2		0x91
>> -			MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1		0x91
>> -			MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0		0x91
>> -			MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC		0x1f
>> -			MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC		0x91
>> -			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x91
>> -			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x1f
>> -			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x19 /* PHY RST */
>> -		>;
>> -	};
>> -
>> -	pinctrl_gpio_led: gpioledgrp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x19
>> -			MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7		0x19
>> -			MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8		0x19
>> -		>;
>> -	};
>> -
>> -	pinctrl_gpio1: gpio1grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19
>> -			MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x19
>> -			MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11		0x19
>> -			MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6		0x19
>> -			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10		0x19
>> -		>;
>> -	};
>> -
>> -	pinctrl_gpio5: gpio5grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19
>> -		>;
>> -	};
>> -
>> -	pinctrl_i2c3: i2c3grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083
>> -			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083
>> -		>;
>> -	};
>> -
>> -	pinctrl_i2c4: i2c4grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x40000083
>> -			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x40000083
>> -		>;
>> -	};
>> -
>> -	pinctrl_pwm2: pwm2grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT			0x19
>> -		>;
>> -	};
>> -
>> -	pinctrl_reg_usb1_vbus: regusb1vbusgrp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19
>> -		>;
>> -	};
>> -
>> -	pinctrl_uart1: uart1grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x0
>> -			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x0
>> -			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x0
>> -			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x0
>> -		>;
>> -	};
>> -
>> -	pinctrl_uart2: uart2grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x0
>> -			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x0
>> -			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x0
>> -			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x0
>> -		>;
>> -	};
>> -
>> -	pinctrl_usb_eth2: usbeth2grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19
>> -		>;
>> -	};
>> -
>> -	pinctrl_usdhc2: usdhc2grp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x90
>> -			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d0
>> -			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d0
>> -			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0
>> -			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0
>> -			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0
>> -			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
>> -			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
>> -		>;
>> -	};
>> -
>> -	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
>> -		fsl,pins = <
>> -			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x94
>> -			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d4
>> -			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d4
>> -			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4
>> -			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4
>> -			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4
>> -			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
>> -			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
>> +			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19  /* SDIO_B_PWR_EN */
>>  		>;
>>  	};
>>  
>> -	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
>> +	pinctrl_usb_hub: usbhubgrp {
>>  		fsl,pins = <
>> -			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x96
>> -			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d6
>> -			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d6
>> -			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6
>> -			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6
>> -			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6
>> -			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19
>> -			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
>> +			MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19 /* SDIO_B_WP */
>>  		>;
>>  	};
>>  };
>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
>> index 6b9058fc53332..1a5c29565e7fe 100644
>> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
>> @@ -3,6 +3,7 @@
>>   * Copyright (C) 2022 Kontron Electronics GmbH
>>   */
>>  
>> +#include <dt-bindings/gpio/gpio.h>
>>  #include <dt-bindings/interrupt-controller/irq.h>
>>  #include "imx8mm.dtsi"
>>  
>> @@ -28,6 +29,73 @@ memory at 40000000 {
>>  	chosen {
>>  		stdout-path = &uart3;
>>  	};
>> +
>> +	reg_vdd_carrier: regulator-vdd-carrier {
>> +		compatible = "regulator-fixed";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_reg_vdd_carrier>;
>> +		enable-active-high;
>> +		gpio = <&gpio3 16 GPIO_ACTIVE_HIGH>;
> 
> Can we flip the order of these two properties? enable-active-high is a
> further description to GPIO_ACTIVE_HIGH.

Sure, done in v3

>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +		regulator-name = "VDD_CARRIER";
>> +
>> +		regulator-state-standby {
>> +			regulator-on-in-suspend;
>> +		};
>> +
>> +		regulator-state-mem {
>> +			regulator-off-in-suspend;
>> +		};
>> +
>> +		regulator-state-disk {
>> +			regulator-off-in-suspend;
>> +		};
>> +	};
>> +
>> +	reg_usb1_vbus: regulator-usb1-vbus {
>> +		compatible = "regulator-fixed";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_reg_usb1_vbus>;
>> +		enable-active-high;
>> +		gpio = <&gpio3 25 GPIO_ACTIVE_HIGH>;
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		regulator-name = "VBUS_USB1";
>> +	};
>> +
>> +	reg_usb2_vbus: regulator-usb2-vbus {
>> +		compatible = "regulator-fixed";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_reg_usb2_vbus>;
>> +		enable-active-high;
>> +		gpio = <&gpio3 20 GPIO_ACTIVE_HIGH>;
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		regulator-name = "VBUS_USB2";
>> +	};
>> +
>> +	reg_usdhc2_vcc: regulator-usdhc2-vcc {
>> +		compatible = "regulator-fixed";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_reg_usdhc2_vcc>;
>> +		enable-active-high;
>> +		gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
>> +		regulator-min-microvolt = <3300000>;
>> +		regulator-max-microvolt = <3300000>;
>> +		regulator-name = "VCC_SDIO_A";
>> +	};
>> +
>> +	reg_usdhc3_vcc: regulator-usdhc3-vcc {
>> +		compatible = "regulator-fixed";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pinctrl_reg_usdhc3_vcc>;
>> +		enable-active-high;
>> +		gpio = <&gpio5 1 GPIO_ACTIVE_HIGH>;
>> +		regulator-min-microvolt = <3300000>;
>> +		regulator-max-microvolt = <3300000>;
>> +		regulator-name = "VCC_SDIO_B";
>> +	};
>>  };
>>  
>>  &A53_0 {
>> @@ -96,6 +164,79 @@ partition at 1f0000 {
>>  	};
>>  };
>>  
>> +&ecspi2 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_ecspi2>, <&pinctrl_ecspi2_gpio>;
>> +	cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +&ecspi3 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_ecspi3>;
>> +	cs-gpios = <&gpio5 25 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +&gpio1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_gpio1>;
>> +	gpio-line-names = "", "GPIO_A_0", "", "GPIO_A_1",
>> +			  "", "GPIO_A_2", "GPIO_A_3", "GPIO_A_4",
>> +			  "GPIO_A_5", "GPIO_A_6", "GPIO_A_7", "GPIO_B_0",
>> +			  "GPIO_B_1", "USB_A_OC#", "CAM_MCK", "USB_B_OC#",
>> +			  "ETH_MDC", "ETH_MDIO", "ETH_A_(S)(R)(G)MII_TXD3",
>> +			  "ETH_A_(S)(R)(G)MII_TXD2", "ETH_A_(S)(R)(G)MII_TXD1",
>> +			  "ETH_A_(S)(R)(G)MII_TXD0", "ETH_A_(R)(G)MII_TX_EN(_ER)",
>> +			  "ETH_A_(R)(G)MII_TX_CLK", "ETH_A_(R)(G)MII_RX_DV(_ER)",
>> +			  "ETH_A_(R)(G)MII_RX_CLK", "ETH_A_(S)(R)(G)MII_RXD0",
>> +			  "ETH_A_(S)(R)(G)MII_RXD1", "ETH_A_(R)(G)MII_RXD2",
>> +			  "ETH_A_(R)(G)MII_RXD3";
>> +};
>> +
>> +&gpio2 {
>> +	gpio-line-names = "", "", "", "",
>> +			  "", "", "", "",
>> +			  "", "", "", "",
>> +			  "SDIO_A_CD#", "SDIO_A_CLK", "SDIO_A_CMD", "SDIO_A_D0",
>> +			  "SDIO_A_D1", "SDIO_A_D2", "SDIO_A_D3", "SDIO_A_PWR_EN",
>> +			  "SDIO_A_WP";
>> +};
>> +
>> +&gpio3 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_gpio3>;
>> +	gpio-line-names = "GPIO_C_5", "GPIO_C_4", "SDIO_B_CD#", "SDIO_B_D5",
>> +			  "SDIO_B_D6", "SDIO_B_D7", "GPIO_C_0", "GPIO_C_1",
>> +			  "GPIO_C_2", "GPIO_C_3", "SDIO_B_D0", "SDIO_B_D1",
>> +			  "SDIO_B_D2", "SDIO_B_D3", "", "SDIO_B_D4",
>> +			  "CARRIER_PWR_EN", "SDIO_B_CLK", "SDIO_B_CMD", "GPIO_B_2",
>> +			  "USB_B_EN", "GPIO_B_3", "PCIe_CLKREQ#", "PCIe_A_PERST#",
>> +			  "PCIe_WAKE#", "USB_A_EN";
>> +};
>> +
>> +&gpio4 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_gpio4>;
>> +	gpio-line-names = "GPIO_C_7", "", "I2S_A_DATA_IN", "I2S_B_DATA_IN",
>> +			  "GPIO_B_4", "BOOT_SEL0#", "BOOT_SEL1#", "",
>> +			  "", "", "I2S_LRCLK", "I2S_BITCLK",
>> +			  "I2S_A_DATA_OUT", "I2S_B_DATA_OUT", "GPIO_B_5", "GPIO_B_6",
>> +			  "GPIO_B_7", "SPI_A_/WP_(IO2)", "SPI_A_/HOLD_(IO3)", "GPIO_C_6",
>> +			  "I2S_MCLK", "UART_A_TX", "UART_A_RX", "UART_A_CTS",
>> +			  "UART_A_RTS", "", "", "",
>> +			  "PCIe_SM_ALERT", "UART_B_RTS", "UART_B_CTS", "UART_B_RX";
>> +};
>> +
>> +&gpio5 {
>> +	gpio-line-names = "UART_B_TX", "SDIO_B_PWR_EN", "SDIO_B_WP", "PWM_2",
>> +			  "PWM_1", "PWM_0", "", "",
>> +			  "", "", "SPI_A_SCK", "SPI_A_SDO_(IO1)",
>> +			  "SPI_A_SCK", "SPI_A_CS0#", "", "",
>> +			  "I2C_A_SCL", "I2C_A_SDA", "I2C_B_SCL", "I2C_B_SDA",
>> +			  "PCIe_SMCLK", "PCIe_SMDAT", "SPI_B_SCK", "SPI_B_SDO",
>> +			  "SPI_B_SDI", "SPI_B_CS0#", "UART_CON_RX", "UART_CON_TX",
>> +			  "UART_C_RX", "UART_C_TX";
>> +};
>> +
>>  &i2c1 {
>>  	clock-frequency = <400000>;
>>  	pinctrl-names = "default";
>> @@ -222,12 +363,69 @@ rv3028: rtc at 52 {
>>  	};
>>  };
>>  
>> +&i2c2 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_i2c2>;
>> +};
>> +
>> +&i2c3 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_i2c3>;
>> +};
>> +
>> +&i2c4 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_i2c4>;
>> +};
>> +
>> +&pwm1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_pwm1>;
>> +};
>> +
>> +&pwm2 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_pwm2>;
>> +};
>> +
>> +&pwm3 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_pwm3>;
>> +};
>> +
>> +&uart1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_uart1>;
>> +};
>> +
>> +&uart2 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_uart2>;
>> +};
>> +
>>  &uart3 { /* console */
>>  	pinctrl-names = "default";
>>  	pinctrl-0 = <&pinctrl_uart3>;
>>  	status = "okay";
>>  };
>>  
>> +&uart4 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_uart4>;
>> +};
>> +
>> +&usbotg1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_usb1>;
>> +	vbus-supply = <&reg_usb1_vbus>;
>> +};
>> +
>> +&usbotg2 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_usb2>;
>> +	vbus-supply = <&reg_usb2_vbus>;
>> +};
>> +
>>  &usdhc1 {
>>  	pinctrl-names = "default", "state_100mhz", "state_200mhz";
>>  	pinctrl-0 = <&pinctrl_usdhc1>;
>> @@ -240,6 +438,26 @@ &usdhc1 {
>>  	status = "okay";
>>  };
>>  
>> +&usdhc2 {
>> +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
>> +	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
>> +	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
>> +	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
>> +	vmmc-supply = <&reg_usdhc2_vcc>;
>> +	vqmmc-supply = <&reg_nvcc_sd>;
>> +	cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +&usdhc3 {
>> +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
>> +	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_gpio>;
>> +	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_usdhc3_gpio>;
>> +	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_usdhc3_gpio>;
>> +	vmmc-supply = <&reg_usdhc3_vcc>;
>> +	vqmmc-supply = <&reg_nvcc_sd>;
>> +	cd-gpios = <&gpio3 2 GPIO_ACTIVE_LOW>;
>> +};
>> +
>>  &wdog1 {
>>  	pinctrl-names = "default";
>>  	pinctrl-0 = <&pinctrl_wdog>;
>> @@ -248,6 +466,12 @@ &wdog1 {
>>  };
>>  
>>  &iomuxc {
>> +	pinctrl_csi_mck: csimckgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_GPIO1_IO14_CCMSRCGPCMIX_CLKO1	0x59 /* CAM_MCK */
>> +		>;
>> +	};
>> +
>>  	pinctrl_ecspi1: ecspi1grp {
>>  		fsl,pins = <
>>  			MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO		0x82
>> @@ -257,6 +481,106 @@ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9		0x19
>>  		>;
>>  	};
>>  
>> +	pinctrl_ecspi2: ecspi2grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO		0x82 /* SPI_A_SDI_(IO0) */
>> +			MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI		0x82 /* SPI_A_SDO_(IO1) */
>> +			MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK		0x82 /* SPI_A_SCK */
>> +			MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13		0x19 /* SPI_A_CS0# */
>> +		>;
>> +	};
>> +
>> +	pinctrl_ecspi2_gpio: ecspi2gpiogrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI1_TXD5_GPIO4_IO17		0x19 /* SPI_A_/WP_(IO2) */
>> +			MX8MM_IOMUXC_SAI1_TXD6_GPIO4_IO18		0x19 /* SPI_A_/HOLD_(IO3) */
>> +		>;
>> +	};
>> +
>> +	pinctrl_ecspi3: ecspi3grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO		0x82 /* SPI_B_SDI */
>> +			MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI		0x82 /* SPI_B_SDO */
>> +			MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK		0x82 /* SPI_B_SCK */
>> +			MX8MM_IOMUXC_UART2_TXD_GPIO5_IO25		0x19 /* SPI_B_CS0# */
>> +		>;
>> +	};
>> +
>> +	pinctrl_enet_rgmii: enetrgmiigrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x03 /* ETH_MDC */
>> +			MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO		0x03 /* ETH_MDIO */
>> +			MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3		0x1f /* ETH_A_(S)(R)(G)MII_TXD3 */
>> +			MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2		0x1f /* ETH_A_(S)(R)(G)MII_TXD2 */
>> +			MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1		0x1f /* ETH_A_(S)(R)(G)MII_TXD1 */
>> +			MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0		0x1f /* ETH_A_(S)(R)(G)MII_TXD0 */
>> +			MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3		0x91 /* ETH_A_(R)(G)MII_RXD3 */
>> +			MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2		0x91 /* ETH_A_(R)(G)MII_RXD2 */
>> +			MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1		0x91 /* ETH_A_(S)(R)(G)MII_RXD1 */
>> +			MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0		0x91 /* ETH_A_(S)(R)(G)MII_RXD0 */
>> +			MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC		0x1f /* ETH_A_(R)(G)MII_TX_CLK */
>> +			MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC		0x91 /* ETH_A_(R)(G)MII_RX_CLK */
>> +			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x91 /* ETH_A_(R)(G)MII_RX_DV(_ER) */
>> +			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x1f /* ETH_A_(R)(G)MII_TX_EN(_ER) */
>> +		>;
>> +	};
>> +
>> +	pinctrl_enet_rmii: enetrmiigrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x03 /* ETH_MDC */
>> +			MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO		0x03 /* ETH_MDIO */
>> +			MX8MM_IOMUXC_ENET_TD2_ENET1_TX_CLK		0x4000001f /* ETH_A_(S)(R)(G)MII_TXD2 */
>> +			MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1		0x56 /* ETH_A_(S)(R)(G)MII_TXD1 */
>> +			MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0		0x56 /* ETH_A_(S)(R)(G)MII_TXD0 */
>> +			MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1		0x56 /* ETH_A_(S)(R)(G)MII_RXD1 */
>> +			MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0		0x56 /* ETH_A_(S)(R)(G)MII_RXD0 */
>> +			MX8MM_IOMUXC_ENET_RXC_ENET1_RX_ER		0x56 /* ETH_A_(R)(G)MII_RX_CLK */
>> +			MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL	0x56 /* ETH_A_(R)(G)MII_RX_DV(_ER) */
>> +			MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL	0x56 /* ETH_A_(R)(G)MII_TX_EN(_ER) */
>> +		>;
>> +	};
>> +
>> +	pinctrl_gpio1: gpio1grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1		0x19 /* GPIO_A_0 */
>> +			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x19 /* GPIO_A_1 */
>> +			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x19 /* GPIO_A_2 */
>> +			MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6		0x19 /* GPIO_A_3 */
>> +			MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7		0x19 /* GPIO_A_4 */
>> +			MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8		0x19 /* GPIO_A_5 */
>> +			MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x19 /* GPIO_A_6 */
>> +			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10		0x19 /* GPIO_A_7 */
>> +			MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11		0x19 /* GPIO_B_0 */
>> +			MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12		0x19 /* GPIO_B_1 */
>> +		>;
>> +	};
>> +
>> +	pinctrl_gpio3: gpio3grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_NAND_ALE_GPIO3_IO0			0x19 /* GPIO_C_5 */
>> +			MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1		0x19 /* GPIO_C_4 */
>> +			MX8MM_IOMUXC_NAND_DATA00_GPIO3_IO6		0x19 /* GPIO_C_0 */
>> +			MX8MM_IOMUXC_NAND_DATA01_GPIO3_IO7		0x19 /* GPIO_C_1 */
>> +			MX8MM_IOMUXC_NAND_DATA02_GPIO3_IO8		0x19 /* GPIO_C_2 */
>> +			MX8MM_IOMUXC_NAND_DATA03_GPIO3_IO9		0x19 /* GPIO_C_3 */
>> +			MX8MM_IOMUXC_SAI5_RXFS_GPIO3_IO19		0x19 /* GPIO_B_2 */
>> +			MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21		0x19 /* GPIO_B_3 */
>> +		>;
>> +	};
>> +
>> +	pinctrl_gpio4: gpio4grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI1_RXFS_GPIO4_IO0		0x19 /* GPIO_C_7 */
>> +			MX8MM_IOMUXC_SAI1_RXD2_GPIO4_IO4		0x19 /* GPIO_B_4 */
>> +			MX8MM_IOMUXC_SAI1_RXD3_GPIO4_IO5		0x19 /* BOOT_SEL0# */
>> +			MX8MM_IOMUXC_SAI1_RXD4_GPIO4_IO6		0x19 /* BOOT_SEL1# */
>> +			MX8MM_IOMUXC_SAI1_TXD2_GPIO4_IO14		0x19 /* GPIO_B_5 */
>> +			MX8MM_IOMUXC_SAI1_TXD3_GPIO4_IO15		0x19 /* GPIO_B_6 */
>> +			MX8MM_IOMUXC_SAI1_TXD4_GPIO4_IO16		0x19 /* GPIO_B_7 */
>> +			MX8MM_IOMUXC_SAI1_TXD7_GPIO4_IO19		0x19 /* GPIO_C_6 */
>> +		>;
>> +	};
>> +
>>  	pinctrl_i2c1: i2c1grp {
>>  		fsl,pins = <
>>  			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL			0x40000083
>> @@ -264,22 +588,149 @@ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA			0x40000083
>>  		>;
>>  	};
>>  
>> +	pinctrl_i2c2: i2c2grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL			0x40000083 /* I2C_A_SCL */
>> +			MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA			0x40000083 /* I2C_A_SDA */
>> +		>;
>> +	};
>> +
>> +	pinctrl_i2c3: i2c3grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x40000083 /* I2C_B_SCL */
>> +			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x40000083 /* I2C_B_SDA */
>> +		>;
>> +	};
>> +
>> +	pinctrl_i2c4: i2c4grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL			0x40000083 /* PCIe_SMCLK and I2C_CAM_SCL/CSI_TX_P */
>> +			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA			0x40000083 /* PCIe_SMDAT and I2C_CAM_SDA/CSI_TX_N */
>> +		>;
>> +	};
>> +
>> +	pinctrl_pcie: pciegrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22		0x19 /* PCIe_CLKREQ# */
>> +			MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23		0x19 /* PCIe_A_PERST# */
>> +			MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24		0x19 /* PCIe_WAKE# */
>> +			MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28		0x19 /* PCIe_SM_ALERT */
>> +		>;
>> +	};
>> +
>>  	pinctrl_pmic: pmicgrp {
>>  		fsl,pins = <
>>  			MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0		0x141
>>  		>;
>>  	};
>>  
>> +	pinctrl_pwm1: pwm1grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SPDIF_EXT_CLK_PWM1_OUT		0x19 /* PWM_0 */
>> +		>;
>> +	};
>> +
>> +	pinctrl_pwm2: pwm2grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT			0x19 /* PWM_1 */
>> +		>;
>> +	};
>> +
>> +	pinctrl_pwm3: pwm3grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SPDIF_TX_PWM3_OUT			0x19 /* PWM_2 */
>> +		>;
>> +	};
>> +
>> +	pinctrl_reg_usb1_vbus: regusb1vbusgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25		0x19 /* USB_A_EN */
>> +		>;
>> +	};
>> +
>> +	pinctrl_reg_usb2_vbus: regusb2vbusgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20		0x19 /* USB_B_EN */
>> +		>;
>> +	};
>> +
>> +	pinctrl_reg_usdhc2_vcc: regusdhc2vccgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19		0x19 /* SDIO_A_PWR_EN */
>> +		>;
>> +	};
>> +
>> +	pinctrl_reg_usdhc3_vcc: regusdhc3vccgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1			0x19 /* SDIO_B_PWR_EN */
>> +		>;
>> +	};
>> +
>> +	pinctrl_reg_vdd_carrier: regvddcarriergrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_NAND_READY_B_GPIO3_IO16		0x19 /* CARRIER_PWR_EN */
>> +		>;
>> +	};
>> +
>>  	pinctrl_rtc: rtcgrp {
>>  		fsl,pins = <
>>  			MX8MM_IOMUXC_SAI1_RXC_GPIO4_IO1			0x19
>>  		>;
>>  	};
>>  
>> +	pinctrl_sai1: sai1grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI1_RXD0_SAI1_RX_DATA0		0xd6 /* I2S_A_DATA_IN */
>> +			MX8MM_IOMUXC_SAI1_TXD0_SAI1_TX_DATA0		0xd6 /* I2S_A_DATA_OUT */
>> +			MX8MM_IOMUXC_SAI1_RXD1_SAI1_RX_DATA1		0xd6 /* I2S_B_DATA_IN */
>> +			MX8MM_IOMUXC_SAI1_TXD1_SAI1_TX_DATA1		0xd6 /* I2S_B_DATA_OUT */
>> +			MX8MM_IOMUXC_SAI1_MCLK_SAI1_MCLK		0xd6 /* I2S_MCLK */
>> +			MX8MM_IOMUXC_SAI1_TXFS_SAI1_TX_SYNC		0xd6 /* I2S_LRCLK */
>> +			MX8MM_IOMUXC_SAI1_TXC_SAI1_TX_BCLK		0xd6 /* I2S_BITCLK */
>> +		>;
>> +	};
>> +
>> +	pinctrl_uart1: uart1grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX		0x0 /* UART_A_RX */
>> +			MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX		0x0 /* UART_A_TX */
>> +			MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B		0x0 /* UART_A_CTS */
>> +			MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B		0x0 /* UART_A_RTS */
>> +		>;
>> +	};
>> +
>> +	pinctrl_uart2: uart2grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x0 /* UART_B_RX */
>> +			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x0 /* UART_B_TX */
>> +			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x0 /* UART_B_CTS */
>> +			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x0 /* UART_B_RTS */
>> +		>;
>> +	};
>> +
>>  	pinctrl_uart3: uart3grp {
>>  		fsl,pins = <
>> -			MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX		0x140
>> -			MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX		0x140
>> +			MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX		0x140 /* UART_CON_RX */
>> +			MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX		0x140 /* UART_CON_TX */
>> +		>;
>> +	};
>> +
>> +	pinctrl_uart4: uart4grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX		0x0 /* UART_C_RX */
>> +			MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX		0x0 /* UART_C_TX */
>> +		>;
>> +	};
>> +
>> +	pinctrl_usb1: usb1grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_GPIO1_IO13_USB1_OTG_OC		0x19 /* USB_A_OC# */
>> +		>;
>> +	};
>> +
>> +	pinctrl_usb2: usb2grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_GPIO1_IO15_USB2_OTG_OC		0x19 /* USB_B_OC# */
>>  		>;
>>  	};
>>  
>> @@ -334,6 +785,103 @@ MX8MM_IOMUXC_SD1_STROBE_USDHC1_STROBE		0x196
>>  		>;
>>  	};
>>  
>> +	pinctrl_usdhc2: usdhc2grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x90 /* SDIO_A_CLK */
>> +			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d0 /* SDIO_A_CMD */
>> +			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d0 /* SDIO_A_D0 */
>> +			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0 /* SDIO_A_D1 */
>> +			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0 /* SDIO_A_D2 */
>> +			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0 /* SDIO_A_D3 */
>> +			MX8MM_IOMUXC_SD2_WP_USDHC2_WP			0x400000d6 /* SDIO_A_WP */
>> +			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
>> +		>;
>> +	};
>> +
>> +	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x94 /* SDIO_A_CLK */
>> +			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d4 /* SDIO_A_CMD */
>> +			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d4 /* SDIO_A_D0 */
>> +			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4 /* SDIO_A_D1 */
>> +			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4 /* SDIO_A_D2 */
>> +			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4 /* SDIO_A_D3 */
>> +			MX8MM_IOMUXC_SD2_WP_USDHC2_WP			0x400000d6 /* SDIO_A_WP */
>> +			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
>> +		>;
>> +	};
>> +
>> +	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x96 /* SDIO_A_CLK */
>> +			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d6 /* SDIO_A_CMD */
>> +			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d6 /* SDIO_A_D0 */
>> +			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6 /* SDIO_A_D1 */
>> +			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6 /* SDIO_A_D2 */
>> +			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6 /* SDIO_A_D3 */
>> +			MX8MM_IOMUXC_SD2_WP_USDHC2_WP			0x400000d6 /* SDIO_A_WP */
>> +			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x90
>> +		>;
>> +	};
>> +
>> +	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x19 /* SDIO_A_CD# */
>> +		>;
>> +	};
>> +
>> +	pinctrl_usdhc3: usdhc3grp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x90 /* SDIO_B_CLK */
>> +			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x90 /* SDIO_B_CMD */
>> +			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x90 /* SDIO_B_D0 */
>> +			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x90 /* SDIO_B_D1 */
>> +			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x90 /* SDIO_B_D2 */
>> +			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x90 /* SDIO_B_D3 */
>> +			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x90 /* SDIO_B_D4 */
>> +			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x90 /* SDIO_B_D5 */
>> +			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x90 /* SDIO_B_D6 */
>> +			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x90 /* SDIO_B_D7 */
>> +		>;
>> +	};
>> +
>> +	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x94 /* SDIO_B_CLK */
>> +			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x94 /* SDIO_B_CMD */
>> +			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x94 /* SDIO_B_D0 */
>> +			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x94 /* SDIO_B_D1 */
>> +			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x94 /* SDIO_B_D2 */
>> +			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x94 /* SDIO_B_D3 */
>> +			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x94 /* SDIO_B_D4 */
>> +			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x94 /* SDIO_B_D5 */
>> +			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x94 /* SDIO_B_D6 */
>> +			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x94 /* SDIO_B_D7 */
>> +		>;
>> +	};
>> +
>> +	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x96 /* SDIO_B_CLK */
>> +			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x96 /* SDIO_B_CMD */
>> +			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x96 /* SDIO_B_D0 */
>> +			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x96 /* SDIO_B_D1 */
>> +			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x96 /* SDIO_B_D2 */
>> +			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x96 /* SDIO_B_D3 */
>> +			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x96 /* SDIO_B_D4 */
>> +			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x96 /* SDIO_B_D5 */
>> +			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x96 /* SDIO_B_D6 */
>> +			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x96 /* SDIO_B_D7 */
>> +		>;
>> +	};
>> +
>> +	pinctrl_usdhc3_gpio: usdhc3gpiogrp {
>> +		fsl,pins = <
>> +			MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2		0x19 /* SDIO_B_CD# */
>> +			MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2		0x19 /* SDIO_B_WP */
>> +		>;
>> +	};
>> +
>>  	pinctrl_wdog: wdoggrp {
>>  		fsl,pins = <
>>  			MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B		0xc6
>> -- 
>> 2.43.0
>>


From gabriel.fernandez at foss.st.com  Wed Dec  6 06:50:05 2023
From: gabriel.fernandez at foss.st.com (Gabriel FERNANDEZ)
Date: Wed, 6 Dec 2023 15:50:05 +0100
Subject: [PATCH v5 4/5] clk: stm32: introduce clocks for STM32MP257
 platform
In-Reply-To: <ec1912eab8bead59f520c48b6d73a084fd07732d.camel@pengutronix.de>
References: <20231206140029.492906-1-gabriel.fernandez@foss.st.com>
 <20231206140029.492906-5-gabriel.fernandez@foss.st.com>
 <ec1912eab8bead59f520c48b6d73a084fd07732d.camel@pengutronix.de>
Message-ID: <fe5cf8bf-fa80-400c-b2e0-969b5ed68c8b@foss.st.com>

Hi Philipp, thank's for reviewing.

On 12/6/23 15:20, Philipp Zabel wrote:
> Hi Gabriel,
>
> On Mi, 2023-12-06 at 15:00 +0100, gabriel.fernandez at foss.st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
>>
>> This driver is intended for the STM32MP25 clock family and utilizes
>> the stm32-core API, similar to the stm32mp13 clock driver.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
>> ---
> [...]
>> diff --git a/drivers/clk/stm32/stm32mp25_rcc.h b/drivers/clk/stm32/stm32mp25_rcc.h
>> new file mode 100644
>> index 000000000000..b1aca78a0b22
>> --- /dev/null
>> +++ b/drivers/clk/stm32/stm32mp25_rcc.h
>> @@ -0,0 +1,4977 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
>> + * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
>> + */
>> +
>> +#ifndef STM32MP25_RCC_H
>> +#define STM32MP25_RCC_H
>> +
>> +#define RCC_SECCFGR0				0x0
> [...]
>
> What is the purpose of all the unused #defines?
>
> I initially wanted to point out that the _SHIFT #defines are redundant
> because the same information is already contained in the corresponding
> _MASK #defines, but it seems like neither of the register field
> definitions are used anywhere. It appears only some of the *CFGR
> register offset #defines are actually used.

It's a generated file that is also used for other components,

but it's not a big deal to remove the unused defines in the Kernel.

I'm waiting for other remarks before sending a V6

Best regards

Gabriel

> regards
> Philipp


From heiko at sntech.de  Wed Dec  6 06:50:41 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed,  6 Dec 2023 15:50:41 +0100
Subject: [PATCH] dt-bindings: PCI: dwc: rockchip: document optional pcie reference clock input
Message-ID: <20231206145041.667900-1-heiko@sntech.de>

From: Heiko Stuebner <heiko.stuebner at cherry.de>

On some boards the 100MHz PCIe reference clock to both controller and
devices is controllable. Add that clock to the list of clocks.

The clock is optional, so the minItems stays the same.

Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
---
 Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
index 1ae8dcfa072c..5f719218c472 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
@@ -49,6 +49,7 @@ properties:
       - description: APB clock for PCIe
       - description: Auxiliary clock for PCIe
       - description: PIPE clock
+      - description: Reference clock for PCIe
 
   clock-names:
     minItems: 5
@@ -59,6 +60,7 @@ properties:
       - const: pclk
       - const: aux
       - const: pipe
+      - const: ref
 
   interrupts:
     items:
-- 
2.39.2



From frieder.schrempf at kontron.de  Wed Dec  6 06:54:17 2023
From: frieder.schrempf at kontron.de (Frieder Schrempf)
Date: Wed, 6 Dec 2023 15:54:17 +0100
Subject: [PATCH v3 01/14] arm64: dts: imx8mm-kontron: Add support for
 display bridges on BL i.MX8MM
In-Reply-To: <CAOMZO5Akp9PsFf2GrSFTKyM1c3kSUEeU=W9ODgiMkyHATRWHOw@mail.gmail.com>
References: <20231206144201.46911-1-frieder@fris.de>
 <20231206144201.46911-2-frieder@fris.de>
 <CAOMZO5Akp9PsFf2GrSFTKyM1c3kSUEeU=W9ODgiMkyHATRWHOw@mail.gmail.com>
Message-ID: <ce45d170-9331-47b5-b8c3-6feff489db1b@kontron.de>

Hi Fabio,

On 06.12.23 15:47, Fabio Estevam wrote:
> Hi Frieder,
> 
> On Wed, Dec 6, 2023 at 11:44?AM Frieder Schrempf <frieder at fris.de> wrote:
> 
>> +               a2vdd-supply = <&reg_vdd_1v8>;
>> +               avdd-supply = <&reg_vdd_1v8>;
>> +               dvdd-supply = <&reg_vdd_1v8>;
>> +               pvdd-supply = <&reg_vdd_1v8>;
>> +               v1p2-supply = <&reg_vdd_1v8>;
> 
> Supplying 1.8V to v1p2-supply looks strange.

Indeed, but it's correct. From the binding docs:

  v1p2-supply:
    description:
      A supply that powers up the V1P2 pin. It can be either 1.2V
      or 1.8V for ADV7533 but only 1.8V for ADV7535.

Best regards
Frieder


From heiko at sntech.de  Wed Dec  6 06:55:52 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Wed, 06 Dec 2023 15:55:52 +0100
Subject: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
In-Reply-To: <20231205202900.4617-1-CFSworks@gmail.com>
References: <20231205202900.4617-1-CFSworks@gmail.com>
Message-ID: <3331042.e9J7NaK4W3@diego>

Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards:
> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
> will sometimes (varying between specific RK3588 chips, not over time) shut
> off the DBI block, and reads to this range will instead stall
> indefinitely.
> 
> When this happens, it will prevent Linux from booting altogether. The
> PCIe driver will stall the CPU core once it attempts to read the version
> information from the DBI range.
> 
> Fix this boot hang by adding the correct pinctrl configuration to the
> PCIe 3.0 device node, which is the proper thing to do anyway. While
> we're at it, also add the necessary configuration to the PCIe 2.0 node,
> which may or may not fix the equivalent problem over there -- but is the
> proper thing to do anyway. :)
> 
> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
> Signed-off-by: Sam Edwards <CFSworks at gmail.com>
> ---
>  .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> index 9570b34aca2e..129f14dbd42f 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy at 1 {
>  &pcie2x1l1 {
>  	linux,pci-domain = <1>;
>  	pinctrl-names = "default";
> -	pinctrl-0 = <&pcie2_reset>;
> +	pinctrl-0 = <&pcie30x1m1_pins>;
>  	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
>  	status = "okay";
>  };
> @@ -226,7 +226,7 @@ &pcie30phy {
>  &pcie3x4 {
>  	linux,pci-domain = <0>;
>  	pinctrl-names = "default";
> -	pinctrl-0 = <&pcie3_reset>;
> +	pinctrl-0 = <&pcie30x4m1_pins>;

also, why are you throwing out the pinctrl for the reset pin.
That seems not related to the regular pins and you could instead just do

+	pinctrl-0 = <&pcie30x4m1_pins>, <&pcie3_reset>;

Thanks
Heiko

>  	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
>  	vpcie3v3-supply = <&vcc3v3_pcie30>;
>  	status = "okay";
> @@ -245,17 +245,7 @@ hym8563_int: hym8563-int {
>  		};
>  	};
>  
> -	pcie2 {
> -		pcie2_reset: pcie2-reset {
> -			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
> -		};
> -	};
> -
>  	pcie3 {
> -		pcie3_reset: pcie3-reset {
> -			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
> -		};
> -
>  		vcc3v3_pcie30_en: pcie3-reg {
>  			rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
>  		};
> 






From robh at kernel.org  Wed Dec  6 06:56:44 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 08:56:44 -0600
Subject: [PATCH 3/7] dt-bindings: i2c: document st,stm32mp25-i2c
 compatible
In-Reply-To: <20231129125920.1702497-4-alain.volmat@foss.st.com>
References: <20231129125920.1702497-1-alain.volmat@foss.st.com>
 <20231129125920.1702497-4-alain.volmat@foss.st.com>
Message-ID: <20231206145644.GA2133904-robh@kernel.org>

On Wed, Nov 29, 2023 at 01:59:12PM +0100, Alain Volmat wrote:
> Add a new compatible st,stm32mp25-i2c for the STM32MP25 series which
> has only one interrupt line for both events and errors and differs in
> term of handling of FastModePlus.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
> ---
>  .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 49 +++++++++++++++----
>  1 file changed, 39 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
> index 94b75d9f66cd..6a69bb6de23e 100644
> --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
> @@ -19,6 +19,7 @@ allOf:
>                - st,stm32f7-i2c
>                - st,stm32mp13-i2c
>                - st,stm32mp15-i2c
> +              - st,stm32mp25-i2c
>      then:
>        properties:
>          i2c-scl-rising-time-ns:
> @@ -41,6 +42,43 @@ allOf:
>          clock-frequency:
>            enum: [100000, 400000]
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - st,stm32f4-i2c
> +              - st,stm32f7-i2c
> +              - st,stm32mp13-i2c
> +              - st,stm32mp15-i2c
> +    then:
> +      properties:
> +        interrupts:
> +          items:
> +            - description: interrupt ID for I2C event
> +            - description: interrupt ID for I2C error
> +
> +        interrupt-names:
> +          items:
> +            - const: event
> +            - const: error
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - st,stm32mp25-i2c
> +    then:
> +      properties:
> +        interrupts:
> +          items:
> +            - description: common interrupt for events and errors
> +
> +        interrupt-names:
> +          items:
> +            - const: event
> +
>  properties:
>    compatible:
>      enum:
> @@ -48,20 +86,11 @@ properties:
>        - st,stm32f7-i2c
>        - st,stm32mp13-i2c
>        - st,stm32mp15-i2c
> +      - st,stm32mp25-i2c
>  
>    reg:
>      maxItems: 1
>  
> -  interrupts:
> -    items:
> -      - description: interrupt ID for I2C event
> -      - description: interrupt ID for I2C error
> -
> -  interrupt-names:
> -    items:
> -      - const: event
> -      - const: error

No this should remain. You are duplicating defining the names otherwise. 
Add 'minItems: 1' here. Then the if/then schemas should just have 
'maxItems: 1' or 'minItems: 2'.

Rob


From dave.stevenson at raspberrypi.com  Wed Dec  6 06:56:37 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Wed, 6 Dec 2023 14:56:37 +0000
Subject: [PATCH v1 0/2] Add waveshare 7inch touchscreen panel support
In-Reply-To: <5b837622-3ac9-47d5-aaf1-6b1ef5144c1c@starfivetech.com>
References: <20231124104451.44271-1-shengyang.chen@starfivetech.com>
 <dab03c60-caa9-47e3-9dac-fa499227b67b@gmx.net> <CAPY8ntAXYVTTfXL5HX-14t-VDe63eFgRBNKA0aG3RamKepxwDQ@mail.gmail.com>
 <5b837622-3ac9-47d5-aaf1-6b1ef5144c1c@starfivetech.com>
Message-ID: <CAPY8ntCw_-QG_v-KGipshq09sZ1fD3yascrHcLz3TYREmnk0sA@mail.gmail.com>

Hi Keith

On Wed, 6 Dec 2023 at 08:55, Keith Zhao <keith.zhao at starfivetech.com> wrote:
>
>
>
> On 2023/11/25 0:04, Dave Stevenson wrote:
> > On Fri, 24 Nov 2023 at 15:00, Stefan Wahren <wahrenst at gmx.net> wrote:
> >>
> >> Hi Shengyang,
> >>
> >> [fix address of Emma]
> >
> > Not merged to master yet, but Emma has stepped back from maintenance.
> > https://lists.freedesktop.org/archives/dri-devel/2023-October/428829.html
> > Dropped from the cc.
> >
> >> Am 24.11.23 um 11:44 schrieb Shengyang Chen:
> >> > This patchset adds waveshare 7inch touchscreen panel support
> >> > for the StarFive JH7110 SoC.
> >> >
> >> > Patch 1 add new compatible for the raspberrypi panel driver and its dt-binding.
> >> > Patch 2 add new display mode and new probing process for raspberrypi panel driver.
> >> >
> >> > Waveshare 7inch touchscreen panel is a kind of raspberrypi panel
> >> > which can be drived by raspberrypi panel driver.
> >> >
> >> > The series has been tested on the VisionFive 2 board.
> >> surprisingly i was recently working on the official Raspberry Pi
> >> touchscreen and was able to get it running the new way.
> >>
> >> What do i mean with the new way. There is almost nothing special to the
> >> Raspberry Pi touchscreen, so we should try to use/extend existing
> >> components like:
> >>
> >> CONFIG_DRM_PANEL_SIMPLE
> >> CONFIG_TOUCHSCREEN_EDT_FT5X06
> >> CONFIG_DRM_TOSHIBA_TC358762
> >>
> >> The only special part is the Attiny on the connector PCB which requires:
> >>
> >> CONFIG_REGULATOR_RASPBERRYPI_TOUCHSCREEN_ATTINY
> >>
> >> So the whole point is to avoid writing monolitic drivers for simple
> >> panel like that.
> >>
> >> There is a WIP branch based on top of Linux 6.7-rcX, which should
> >> demonstrate this approach [1]. Unfortunately it is not ready for
> >> upstreaming, but it has been tested on a Raspberry Pi 3 B Plus. Maybe
> >> this is helpful for your case.
> >>
> >> Actually i consider panel-raspberrypi-touchscreen.c as a dead end, which
> >> shouldn't be extended.
> >
> > Agreed.
> >
> > The panel control being bound in with the Atmel control has no hook
> > for the EDT5x06 touch driver to hook in and keep the power to the
> > touch controller active. When the panel disable gets called, bye bye
> > touch overlay :-(
> >
> > And I'm reading the driver change as more of a hack to get it to work
> > on your platform, not as adding support for the Waveshare panel
> > variant.
> > Waveshare deliberately cloned the behaviour of the Pi 7" panel in
> > order to make it work with the old Pi firmware drivers, so it
> > shouldn't need any significant changes. Where did the new timings come
> > from?
> >
> >   Dave
> hi Dave :
> that's means the panel driver split into 3 sub-modules:
> panel + panel_bridge + regulator.

Correct.

You'll have a fourth device in edt_ft5x06 for the touch overlay too,
which will link to the regulator driver for power control.

> I have a question: in the
> static int rpi_touchscreen_probe(struct i2c_client *i2c)
> {
>         ......
>
>         ver = rpi_touchscreen_i2c_read(ts, REG_ID);
>         if (ver < 0) {
>                 dev_err(dev, "Atmel I2C read failed: %d\n", ver);
>                 return -ENODEV;
>         }
>
>         switch (ver) {
>         case 0xde: /* ver 1 */
>         case 0xc3: /* ver 2 */
>                 break;
>         default:
>                 dev_err(dev, "Unknown Atmel firmware revision: 0x%02x\n", ver);
>                 return -ENODEV;
>         }
>
>         ......
> }
> i think this "I2C read" can use to detect whether the panel is connected to dsi controller.
>
> and when split the panel driver into 3 sub-modules, it seems the default way is connected.
> if I drop the panel , run modetest to check the connector status , result connected.
> Is there any way to detect the connection in this case?
> Thanks

I am not aware of any DSI drivers that support hotplugging, therefore
the connector state will always be connected if the device probes.

On vc4 the relevant DSI host controller has to have been enabled in
device tree and will be a required component for binding. The DSI host
controller will be waiting on the DSI peripheral driver to call
mipi_dsi_attach, which then calls component_add. If the panel or panel
regulator isn't present, then that never happens if the panel isn't
present, so vc4 won't bind.
It is a little ugly in that you lose the whole DRM card, but that is
how I understand DRM is generally set up to work for DSI or similar
display interfaces.

> -------------------------------------
>
> Where did the new timings come from?
>
> -------------------------------------
> My platform dphy tx hardware has certain limitations.
> Only supports integer multiples of 10M bitrate:
> such as 160M ,170M, 180M,190M,...1G(max)
>
> as common dphy bitrate = pixclock*bpp/lanes.
> This value cannot match successfully in most cases.
>
> so in order to match bitrate , I choose a bitrate value around pixclock*bpp/lanes,
> Prevent overflow and underflow by fine-tuning the timing parameters:-(
> that will make the new timming value.

That isn't really a function of the panel then.

All DRM bridges have the option to define a mode_fixup in
drm_bridge_funcs, and that gives you the option to adjust the timings
as required.

vc4 has a similar constraint in that the PHY only has an integer
divider from a 2 or 3GHz PLL. It implements mode_fixup to compute the
next highest pixel clock, and then adjusts the horizontal front porch
to keep the same line timing. See
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_dsi.c#L825

  Dave

> >
> >> Btw there are already DT overlays in mainline which seems to use the
> >> Raspberry Pi 7inch panel (without touch function yet) [2].
> >>
> >> [1] - https://github.com/lategoodbye/rpi-zero/commits/v6.7-7inch-ts
> >> [2] -
> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x-rpidsi.dtso?h=v6.6.2&id=6b4da1354fd81adace0cda448c77d8f2a47d8474
> >>
> >> >
> >> > Shengyang Chen (2):
> >> >    dt-bindings: display: panel: raspberrypi: Add compatible property for
> >> >      waveshare 7inch touchscreen panel
> >> >    gpu: drm: panel: raspberrypi: add new display mode and new probing
> >> >      process
> >> >
> >> >   .../panel/raspberrypi,7inch-touchscreen.yaml  |  4 +-
> >> >   .../drm/panel/panel-raspberrypi-touchscreen.c | 99 ++++++++++++++++---
> >> >   2 files changed, 91 insertions(+), 12 deletions(-)
> >> >
> >>


From festevam at gmail.com  Wed Dec  6 07:00:18 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 12:00:18 -0300
Subject: [PATCH 1/6] ARM: dts: imx27: Use 'bus' for AIPI bus
Message-ID: <20231206150023.2305685-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per simple-bus.yaml, 'aipi' is not a valid node name.

Change it to 'bus' to fix the following dt-schema warning:

imx27-pdk.dtb: aipi at 10020000: $nodename:0: 'aipi at 10020000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
	from schema $id: http://devicetree.org/schemas/simple-bus.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx27.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx27.dtsi b/arch/arm/boot/dts/nxp/imx/imx27.dtsi
index cac4b3d68986..ec472695c71e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27.dtsi
@@ -81,7 +81,7 @@ soc: soc {
 		interrupt-parent = <&aitc>;
 		ranges;
 
-		aipi1: aipi at 10000000 { /* AIPI1 */
+		aipi1: bus at 10000000 { /* AIPI1 */
 			compatible = "fsl,aipi-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
@@ -453,7 +453,7 @@ gpt6: timer at 1001f000 {
 			};
 		};
 
-		aipi2: aipi at 10020000 { /* AIPI2 */
+		aipi2: bus at 10020000 { /* AIPI2 */
 			compatible = "fsl,aipi-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 07:00:19 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 12:00:19 -0300
Subject: [PATCH 2/6] ARM: dts: imx27: Use 'bus' for EMI bus
In-Reply-To: <20231206150023.2305685-1-festevam@gmail.com>
References: <20231206150023.2305685-1-festevam@gmail.com>
Message-ID: <20231206150023.2305685-2-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per simple-bus.yaml, 'emi' is not a valid node name.

Change it to 'bus' to fix the following dt-schema warning:

imx25-pdk.dtb: emi at 80000000: $nodename:0: 'emi at 80000000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
	from schema $id: http://devicetree.org/schemas/simple-bus.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx25.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx25.dtsi b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
index 21c968341b3c..d0193d6f2d08 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
@@ -597,7 +597,7 @@ iram: sram at 78000000 {
 			#size-cells = <1>;
 		};
 
-		emi at 80000000 {
+		bus at 80000000 {
 			compatible = "fsl,emi-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 07:00:21 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 12:00:21 -0300
Subject: [PATCH 4/6] ARM: dts: imx27-phytec-phycore-rdk: Move usbphy nodes out of simple-bus
In-Reply-To: <20231206150023.2305685-1-festevam@gmail.com>
References: <20231206150023.2305685-1-festevam@gmail.com>
Message-ID: <20231206150023.2305685-4-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The USB PHY nodes should not be described under 'simple-bus'.

Move it out of simple-bus.

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 .../dts/nxp/imx/imx27-phytec-phycore-rdk.dts  | 15 ++++++--------
 .../dts/nxp/imx/imx27-phytec-phycore-som.dtsi | 20 +++++++------------
 2 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts
index 7f0cd4d3ec2d..b7df7f20ec04 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts
@@ -48,15 +48,12 @@ regulator-2 {
 		regulator-always-on;
 	};
 
-	usbphy {
-		usbphy2: usbphy at 2 {
-			compatible = "usb-nop-xceiv";
-			reg = <2>;
-			vcc-supply = <&reg_5v0>;
-			clocks = <&clks IMX27_CLK_DUMMY>;
-			clock-names = "main_clk";
-			#phy-cells = <0>;
-		};
+	usbphy2: usbphy {
+		compatible = "usb-nop-xceiv";
+		vcc-supply = <&reg_5v0>;
+		clocks = <&clks IMX27_CLK_DUMMY>;
+		clock-names = "main_clk";
+		#phy-cells = <0>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
index dc316358a7d4..0e527d1f9e55 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
@@ -29,19 +29,13 @@ reg_5v0: regulator-1 {
 		regulator-max-microvolt = <5000000>;
 	};
 
-	usbphy {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		usbphy0: usbphy at 0 {
-			compatible = "usb-nop-xceiv";
-			reg = <0>;
-			vcc-supply = <&sw3_reg>;
-			clocks = <&clks IMX27_CLK_DUMMY>;
-			clock-names = "main_clk";
-			#phy-cells = <0>;
-		};
+
+	usbphy0: usbphy {
+		compatible = "usb-nop-xceiv";
+		vcc-supply = <&sw3_reg>;
+		clocks = <&clks IMX27_CLK_DUMMY>;
+		clock-names = "main_clk";
+		#phy-cells = <0>;
 	};
 };
 
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 07:00:20 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 12:00:20 -0300
Subject: [PATCH 3/6] ARM: dts: imx27-pdk: Move usbphy0 out of simple-bus
In-Reply-To: <20231206150023.2305685-1-festevam@gmail.com>
References: <20231206150023.2305685-1-festevam@gmail.com>
Message-ID: <20231206150023.2305685-3-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The USB PHY should not be described under 'simple-bus'.

Move it out of simple-bus.

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx27-pdk.dts | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx27-pdk.dts b/arch/arm/boot/dts/nxp/imx/imx27-pdk.dts
index 35123b7cb6b3..21d436972aa4 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-pdk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-pdk.dts
@@ -14,18 +14,12 @@ memory at a0000000 {
 		reg = <0xa0000000 0x08000000>;
 	};
 
-	usbphy {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		usbphy0: usbphy at 0 {
-			compatible = "usb-nop-xceiv";
-			reg = <0>;
-			clocks = <&clks IMX27_CLK_DUMMY>;
-			clock-names = "main_clk";
-			#phy-cells = <0>;
-		};
+
+	usbphy0: usbphy {
+		compatible = "usb-nop-xceiv";
+		clocks = <&clks IMX27_CLK_DUMMY>;
+		clock-names = "main_clk";
+		#phy-cells = <0>;
 	};
 };
 
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 07:00:22 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 12:00:22 -0300
Subject: [PATCH 5/6] ARM: dts: imx1: Use 'bus' for AIPI bus
In-Reply-To: <20231206150023.2305685-1-festevam@gmail.com>
References: <20231206150023.2305685-1-festevam@gmail.com>
Message-ID: <20231206150023.2305685-5-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per simple-bus.yaml, 'aipi' is not a valid node name.

Change it to 'bus' to fix the following dt-schema warning:

imx1-apf9328.dtb: aipi at 200000: $nodename:0: 'aipi at 200000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
	from schema $id: http://devicetree.org/schemas/simple-bus.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx1.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx1.dtsi b/arch/arm/boot/dts/nxp/imx/imx1.dtsi
index 4aeb74479f44..1ac10965fdfd 100644
--- a/arch/arm/boot/dts/nxp/imx/imx1.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx1.dtsi
@@ -68,7 +68,7 @@ soc {
 		interrupt-parent = <&aitc>;
 		ranges;
 
-		aipi at 200000 {
+		bus at 200000 {
 			compatible = "fsl,aipi-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
@@ -155,7 +155,7 @@ uart3: serial at 20a000 {
 			};
 		};
 
-		aipi at 210000 {
+		bus at 210000 {
 			compatible = "fsl,aipi-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 07:00:23 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 12:00:23 -0300
Subject: [PATCH 6/6] ARM: dts: imx25: Move usbphy nodes out of simple-bus
In-Reply-To: <20231206150023.2305685-1-festevam@gmail.com>
References: <20231206150023.2305685-1-festevam@gmail.com>
Message-ID: <20231206150023.2305685-6-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The USB PHY nodes should not be described under 'simple-bus'.

Move it out of simple-bus.

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx25.dtsi | 28 ++++++++++------------------
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx25.dtsi b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
index d0193d6f2d08..e7b7f22b5e89 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
@@ -68,6 +68,16 @@ osc {
 		};
 	};
 
+	usbphy0: usb-phy0 {
+		compatible = "usb-nop-xceiv";
+		#phy-cells = <0>;
+	};
+
+	usbphy1: usb-phy1 {
+		compatible = "usb-nop-xceiv";
+		#phy-cells = <0>;
+	};
+
 	soc: soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -617,22 +627,4 @@ nfc: nand at bb000000 {
 			};
 		};
 	};
-
-	usbphy {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		usbphy0: usb-phy at 0 {
-			reg = <0>;
-			compatible = "usb-nop-xceiv";
-			#phy-cells = <0>;
-		};
-
-		usbphy1: usb-phy at 1 {
-			reg = <1>;
-			compatible = "usb-nop-xceiv";
-			#phy-cells = <0>;
-		};
-	};
 };
-- 
2.34.1



From jgg at nvidia.com  Wed Dec  6 07:05:56 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 6 Dec 2023 11:05:56 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZXCJ3pVbKuHJ3LTz@arm.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
 <ZXCJ3pVbKuHJ3LTz@arm.com>
Message-ID: <20231206150556.GQ2692119@nvidia.com>

On Wed, Dec 06, 2023 at 02:49:02PM +0000, Catalin Marinas wrote:
> On Tue, Dec 05, 2023 at 03:48:22PM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 05, 2023 at 07:24:37PM +0000, Catalin Marinas wrote:
> > > On Tue, Dec 05, 2023 at 12:43:18PM -0400, Jason Gunthorpe wrote:
> > > > What if we change vfio-pci to use pgprot_device() like it already
> > > > really should and say the pgprot_noncached() is enforced as
> > > > DEVICE_nGnRnE and pgprot_device() may be DEVICE_nGnRE or NORMAL_NC?
> > > > Would that be acceptable?
> > > 
> > > pgprot_device() needs to stay as Device, otherwise you'd get speculative
> > > reads with potential side-effects.
> > 
> > I do not mean to change pgprot_device() I mean to detect the
> > difference via pgprot_device() vs pgprot_noncached(). They put a
> > different value in the PTE that we can sense. It is very hacky.
> 
> Ah, ok, it does look hacky though (as is the alternative of coming up
> with a new specific pgprot_*() that KVM can treat differently).
> 
> BTW, on those Mellanox devices that require different attributes within
> a BAR, do they have a problem with speculative reads causing
> side-effects? 

Yes. We definitely have had that problem in the past on older
devices. VFIO must map the BAR using pgprot_device/noncached() into
the VMM, no other choice is functionally OK.

Only some pages can safely tolerate speculative reads and the guest
driver knows which they are.

Jason


From festevam at gmail.com  Wed Dec  6 07:06:55 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 6 Dec 2023 12:06:55 -0300
Subject: [PATCH v3 01/14] arm64: dts: imx8mm-kontron: Add support for
 display bridges on BL i.MX8MM
In-Reply-To: <ce45d170-9331-47b5-b8c3-6feff489db1b@kontron.de>
References: <20231206144201.46911-1-frieder@fris.de> <20231206144201.46911-2-frieder@fris.de>
 <CAOMZO5Akp9PsFf2GrSFTKyM1c3kSUEeU=W9ODgiMkyHATRWHOw@mail.gmail.com> <ce45d170-9331-47b5-b8c3-6feff489db1b@kontron.de>
Message-ID: <CAOMZO5Cx00a8DJbm3gzQAsLrQNXmTnCcDmrtMTtRg7XvYBVi_g@mail.gmail.com>

On Wed, Dec 6, 2023 at 11:54?AM Frieder Schrempf
<frieder.schrempf at kontron.de> wrote:

> Indeed, but it's correct. From the binding docs:
>
>   v1p2-supply:
>     description:
>       A supply that powers up the V1P2 pin. It can be either 1.2V
>       or 1.8V for ADV7533 but only 1.8V for ADV7535.

Thanks for the clarification. It looks good then.


From jgg at nvidia.com  Wed Dec  6 07:16:03 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 6 Dec 2023 11:16:03 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZXBlmt88dKmZLCU9@arm.com>
References: <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <86bkb4bn2v.wl-maz@kernel.org>
 <ZW9ezSGSDIvv5MsQ@arm.com>
 <86a5qobkt8.wl-maz@kernel.org>
 <ZW9uqu7yOtyZfmvC@arm.com>
 <868r67blwo.wl-maz@kernel.org>
 <ZXBlmt88dKmZLCU9@arm.com>
Message-ID: <20231206151603.GR2692119@nvidia.com>

On Wed, Dec 06, 2023 at 12:14:18PM +0000, Catalin Marinas wrote:

> We could do with a pgprot_maybewritecombine() or
> pgprot_writecombinenospec() (similar to Jason's idea but without
> changing the semantics of pgprot_device()). For the user mapping on
> arm64 this would be Device (even _GRE) since it can't disable
> speculation but stage 2 would leave the decision to the guest since the
> speculative loads aren't much different from committed loads done
> wrongly.

This would be fine, as would a VMA flag. Please pick one :)

I think a VMA flag is simpler than messing with pgprot.

> If we want the VMM to drive this entirely, we could add a new mmap()
> flag like MAP_WRITECOMBINE or PROT_WRITECOMBINE. They do feel a bit

As in the other thread, we cannot unconditionally map NORMAL_NC into
the VMM.

> The latter has some benefits for DPDK but it's a lot more involved
> with

DPDK WC support will be solved with some VFIO-only change if anyone
ever cares to make it, if that is what you mean.

> having to add device-specific knowledge into the VMM. The VMM would also
> have to present the whole BAR contiguously to the guest even if there
> are different mapping attributes within the range. So a lot of MAP_FIXED
> uses. I'd rather leaving this decision with the guest than the VMM, it
> looks like more hassle to create those mappings. The VMM or the VFIO
> could only state write-combine and speculation allowed.

We talked about this already, the guest must decide, the VMM doesn't
have the information to pre-predict which pages the guest will want to
use WC on.

Jason


From lpieralisi at kernel.org  Wed Dec  6 07:18:05 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Wed, 6 Dec 2023 16:18:05 +0100
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231206150556.GQ2692119@nvidia.com>
References: <20231205033015.10044-1-ankita@nvidia.com>
 <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
 <ZXCJ3pVbKuHJ3LTz@arm.com>
 <20231206150556.GQ2692119@nvidia.com>
Message-ID: <ZXCQrTbf6q0BIhSw@lpieralisi>

On Wed, Dec 06, 2023 at 11:05:56AM -0400, Jason Gunthorpe wrote:
> On Wed, Dec 06, 2023 at 02:49:02PM +0000, Catalin Marinas wrote:
> > On Tue, Dec 05, 2023 at 03:48:22PM -0400, Jason Gunthorpe wrote:
> > > On Tue, Dec 05, 2023 at 07:24:37PM +0000, Catalin Marinas wrote:
> > > > On Tue, Dec 05, 2023 at 12:43:18PM -0400, Jason Gunthorpe wrote:
> > > > > What if we change vfio-pci to use pgprot_device() like it already
> > > > > really should and say the pgprot_noncached() is enforced as
> > > > > DEVICE_nGnRnE and pgprot_device() may be DEVICE_nGnRE or NORMAL_NC?
> > > > > Would that be acceptable?
> > > > 
> > > > pgprot_device() needs to stay as Device, otherwise you'd get speculative
> > > > reads with potential side-effects.
> > > 
> > > I do not mean to change pgprot_device() I mean to detect the
> > > difference via pgprot_device() vs pgprot_noncached(). They put a
> > > different value in the PTE that we can sense. It is very hacky.
> > 
> > Ah, ok, it does look hacky though (as is the alternative of coming up
> > with a new specific pgprot_*() that KVM can treat differently).
> > 
> > BTW, on those Mellanox devices that require different attributes within
> > a BAR, do they have a problem with speculative reads causing
> > side-effects? 
> 
> Yes. We definitely have had that problem in the past on older
> devices. VFIO must map the BAR using pgprot_device/noncached() into
> the VMM, no other choice is functionally OK.

Were those BARs tagged as prefetchable or non-prefetchable ? I assume the
latter but please let me know if I am guessing wrong.

Thanks,
Lorenzo


From mani at kernel.org  Wed Dec  6 07:26:46 2023
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Wed, 6 Dec 2023 20:56:46 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231204143101.64163-2-quic_mnaresh@quicinc.com>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
Message-ID: <20231206152646.GH12802@thinkpad>

On Mon, Dec 04, 2023 at 08:00:59PM +0530, Maramaina Naresh wrote:
> Register ufs driver to CPU latency PM QoS framework can improves
> ufs device random io performance.
> 
> PM QoS initialization will insert new QoS request into the CPU
> latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
> value.
> 
> UFS driver will vote for performance mode on scale up and power
> save mode for scale down.
> 
> If clock scaling feature is not enabled then voting will be based
> on clock on or off condition.
> 
> tiotest benchmark tool io performance results on sm8550 platform:
> 
> 1. Without PM QoS support
> 	Type (Speed in)    | Average of 18 iterations
> 	Random Write(IPOS) | 41065.13
> 	Random Read(IPOS)  | 37101.3
> 
> 2. With PM QoS support
> 	Type (Speed in)    | Average of 18 iterations
> 	Random Write(IPOS) | 46784.9
> 	Random Read(IPOS)  | 42943.4
> (Improvement % with PM QoS = ~15%).
> 
> Co-developed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
> Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
> Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall at quicinc.com>
> Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
> ---
>  drivers/ufs/core/ufshcd-priv.h |  8 +++++
>  drivers/ufs/core/ufshcd.c      | 62 ++++++++++++++++++++++++++++++++++
>  include/ufs/ufshcd.h           | 16 +++++++++
>  3 files changed, 86 insertions(+)
> 
> diff --git a/drivers/ufs/core/ufshcd-priv.h b/drivers/ufs/core/ufshcd-priv.h
> index f42d99ce5bf1..536805f6c4e1 100644
> --- a/drivers/ufs/core/ufshcd-priv.h
> +++ b/drivers/ufs/core/ufshcd-priv.h
> @@ -241,6 +241,14 @@ static inline void ufshcd_vops_config_scaling_param(struct ufs_hba *hba,
>  		hba->vops->config_scaling_param(hba, p, data);
>  }
>  
> +static inline u32 ufshcd_vops_config_qos_vote(struct ufs_hba *hba)
> +{
> +	if (hba->vops && hba->vops->config_qos_vote)
> +		return hba->vops->config_qos_vote(hba);

Please remove this callback as Bart noted.

> +
> +	return UFSHCD_QOS_DEFAULT_VOTE;
> +}
> +
>  static inline void ufshcd_vops_reinit_notify(struct ufs_hba *hba)
>  {
>  	if (hba->vops && hba->vops->reinit_notify)
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index ae9936fc6ffb..13370febd2b5 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -1001,6 +1001,20 @@ static bool ufshcd_is_unipro_pa_params_tuning_req(struct ufs_hba *hba)
>  	return ufshcd_get_local_unipro_ver(hba) < UFS_UNIPRO_VER_1_6;
>  }
>  
> +/**
> + * ufshcd_pm_qos_perf - vote for PM QoS performance or power save mode

ufshcd_pm_qos_update() - Update PM QoS request

> + * @hba: per adapter instance
> + * @on: If True, vote for perf PM QoS mode otherwise power save mode
> + */
> +static void ufshcd_pm_qos_perf(struct ufs_hba *hba, bool on)
> +{
> +	if (!hba->pm_qos_init)
> +		return;
> +
> +	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? hba->qos_vote
> +							: PM_QOS_DEFAULT_VALUE);
> +}
> +
>  /**
>   * ufshcd_set_clk_freq - set UFS controller clock frequencies
>   * @hba: per adapter instance
> @@ -1153,6 +1167,10 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, unsigned long freq,
>  	trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
>  			(scale_up ? "up" : "down"),
>  			ktime_to_us(ktime_sub(ktime_get(), start)), ret);
> +
> +	if (!ret)
> +		ufshcd_pm_qos_perf(hba, scale_up);

Can't you just move this before trace_ufshcd_profile_clk_scaling()? This also
avoids checking for !ret.

> +
>  	return ret;
>  }
>  
> @@ -9204,6 +9222,8 @@ static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
>  	if (ret)
>  		return ret;
>  
> +	if (!ufshcd_is_clkscaling_supported(hba))
> +		ufshcd_pm_qos_perf(hba, on);
>  out:
>  	if (ret) {
>  		list_for_each_entry(clki, head, list) {
> @@ -9296,6 +9316,45 @@ static int ufshcd_init_clocks(struct ufs_hba *hba)
>  	return ret;
>  }
>  
> +/**
> + * ufshcd_pm_qos_init - initialize PM QoS instance

"Initialize PM QoS request"

> + * @hba: per adapter instance
> + */
> +static void ufshcd_pm_qos_init(struct ufs_hba *hba)
> +{
> +	if (!(hba->caps & UFSHCD_CAP_PM_QOS))
> +		return;
> +
> +	/*
> +	 * called to configure PM QoS vote value for UFS host,
> +	 * expecting qos vote return value from caller else
> +	 * default vote value will be return.
> +	 */
> +	hba->qos_vote = ufshcd_vops_config_qos_vote(hba);

No need of this variable too if you get rid of the callback.

> +	cpu_latency_qos_add_request(&hba->pm_qos_req,
> +					PM_QOS_DEFAULT_VALUE);
> +
> +	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
> +		hba->pm_qos_init = true;

Why do you need this flag?

> +
> +	dev_dbg(hba->dev, "%s: QoS %s, qos_vote: %u\n", __func__,
> +		hba->pm_qos_init ? "initialized" : "uninitialized",
> +		hba->qos_vote);
> +}
> +
> +/**
> + * ufshcd_pm_qos_exit - remove instance from PM QoS
> + * @hba: per adapter instance
> + */
> +static void ufshcd_pm_qos_exit(struct ufs_hba *hba)
> +{
> +	if (!hba->pm_qos_init)
> +		return;
> +
> +	cpu_latency_qos_remove_request(&hba->pm_qos_req);
> +	hba->pm_qos_init = false;
> +}
> +

[...]

>  /**
>   * struct ufs_hba - per adapter private structure
>   * @mmio_base: UFSHCI base register address
> @@ -912,6 +923,8 @@ enum ufshcd_mcq_opr {
>   * @mcq_base: Multi circular queue registers base address
>   * @uhq: array of supported hardware queues
>   * @dev_cmd_queue: Queue for issuing device management commands
> + * @pm_qos_req: PM QoS request handle
> + * @pm_qos_init: flag to check if pm qos init completed
>   */
>  struct ufs_hba {
>  	void __iomem *mmio_base;
> @@ -1076,6 +1089,9 @@ struct ufs_hba {
>  	struct ufs_hw_queue *uhq;
>  	struct ufs_hw_queue *dev_cmd_queue;
>  	struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
> +	struct pm_qos_request pm_qos_req;
> +	bool pm_qos_init;
> +	u32 qos_vote;

Order doesn't match Kdoc.

- Mani

-- 
????????? ????????


From mani at kernel.org  Wed Dec  6 07:32:42 2023
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Wed, 6 Dec 2023 21:02:42 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <b9373252-710c-4a54-95cc-046314796960@quicinc.com>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
 <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>
 <5e7c5c75-cb5f-4afe-9d57-b0cab01a6f26@acm.org>
 <b9373252-710c-4a54-95cc-046314796960@quicinc.com>
Message-ID: <20231206153242.GI12802@thinkpad>

On Wed, Dec 06, 2023 at 07:32:54PM +0530, Naresh Maramaina wrote:
> 
> 
> On 12/5/2023 10:41 PM, Bart Van Assche wrote:
> > On 12/4/23 21:58, Naresh Maramaina wrote:
> > > On 12/5/2023 12:30 AM, Bart Van Assche wrote:
> > > > On 12/4/23 06:30, Maramaina Naresh wrote:
> > > > > +??? /* This capability allows the host controller driver to
> > > > > use the PM QoS
> > > > > +???? * feature.
> > > > > +???? */
> > > > > +??? UFSHCD_CAP_PM_QOS??????????????? = 1 << 13,
> > > > > ? };
> > > > 
> > > > Why does it depend on the host driver whether or not PM QoS is
> > > > enabled? Why isn't it enabled unconditionally?
> > > 
> > > For some platform vendors power KPI might be more important than
> > > random io KPI. Hence this flag is disabled by default and can be
> > > enabled based on platform requirement.
> > 
> > How about leaving this flag out unless if a host vendor asks explicitly
> > for this flag?
> 
> IMHO, instead of completely removing this flag, how about having
> flag like "UFSHCD_CAP_DISABLE_PM_QOS" which will make PMQOS enable
> by default and if some host vendor wants to disable it explicitly,
> they can enable that flag.
> Please let me know your opinion.
> 

If a vendor wants to disable this feature, then the driver has to be modified.
That won't be very convenient. So either this has to be configured through sysfs
or Kconfig if flexibility matters.

- Mani

> > > > 
> > > > > + * @pm_qos_req: PM QoS request handle
> > > > > + * @pm_qos_init: flag to check if pm qos init completed
> > > > > ?? */
> > > > 
> > > > Documentation for pm_qos_init is missing.
> > > > 
> > > Sorry, i didn't get your comment, i have already added documentation
> > > for @pm_qos_init, @pm_qos_req variable as above. Do you want me to
> > > add this information some where else as well?
> > 
> > Oops, I meant 'qos_vote'.
> 
> Sure. I'll take of this in next patchset.
> 
> > 
> > Thanks,
> > 
> > Bart.
> > 
> 
> Thanks,
> Naresh
> 

-- 
????????? ????????


From bhe at redhat.com  Wed Dec  6 07:37:52 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 6 Dec 2023 23:37:52 +0800
Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <20231204-liftoff-enclosure-d3e3daf0ab6e@spud>
References: <20231130023955.5257-1-bhe@redhat.com>
 <20231130023955.5257-6-bhe@redhat.com>
 <20231201-blog-blasphemy-985d2665903c@wendy>
 <ZW3yXWJ7rTrtZzyg@MiWiFi-R3L-srv>
 <20231204-liftoff-enclosure-d3e3daf0ab6e@spud>
Message-ID: <ZXCVUD9cCYEShrrj@MiWiFi-R3L-srv>

On 12/04/23 at 04:14pm, Conor Dooley wrote:
> On Mon, Dec 04, 2023 at 11:38:05PM +0800, Baoquan He wrote:
> > On 12/01/23 at 10:38am, Conor Dooley wrote:
> > > On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
> > > 
> > > $subject has a typo in the arch bit :)
> > 
> > Indeed, will fix if need report. Thanks for careful checking.
> > 
> > > 
> > > > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > > > loading related codes.
> > > 
> > > Commit messages should be understandable in isolation, but this only
> > > explains (part of) what is obvious in the diff. Why is this change
> > > being made?
> > 
> > The purpose has been detailedly described in cover letter and patch 1
> > log. Andrew has picked these patches into his tree and grabbed the cover
> > letter log into the relevant commit for people's later checking. All
> > these seven patches will be present in mainline together. This is common
> > way when posting patch series? Please let me know if I misunderstand
> > anything.
> 
> Each patch having a commit message that explains why a change is being
> made is the expectation. It is especially useful to explain the why
> here, since it is not just a mechanical conversion of pr_debug()s as the
> commit message suggests.

Sounds reasonable. I rephrase the patch 3 log as below, do you think
it's OK to you?

I will also adjust patch logs on other ARCH once this one is done.
Thanks.

=============================
Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if required

Then when specifying '-d' for kexec_file_load interface, loaded
locations of kernel/initrd/cmdline etc can be printed out to help debug.

Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file
loading related codes.

And also replace pr_notice() with kexec_dprintk() in elf_kexec_load()
because it's make sense to always print out loaded location of purgatory
and device tree even though users don't expect the message.

And also remove kexec_image_info() because the content has been printed
out in generic code.

============================

> 
> > > 
> > > > 
> > > > And also remove kexec_image_info() because the content has been printed
> > > > out in generic code.
> > > > 
> > > > Signed-off-by: Baoquan He <bhe at redhat.com>
> > > > ---
> > > >  arch/riscv/kernel/elf_kexec.c     | 11 ++++++-----
> > > >  arch/riscv/kernel/machine_kexec.c | 26 --------------------------
> > > >  2 files changed, 6 insertions(+), 31 deletions(-)
> > > > 
> > > > diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> > > > index e60fbd8660c4..5bd1ec3341fe 100644
> > > > --- a/arch/riscv/kernel/elf_kexec.c
> > > > +++ b/arch/riscv/kernel/elf_kexec.c
> > > > @@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > >  	if (ret)
> > > >  		goto out;
> > > >  	kernel_start = image->start;
> > > > -	pr_notice("The entry point of kernel at 0x%lx\n", image->start);
> > > >  
> > > >  	/* Add the kernel binary to the image */
> > > >  	ret = riscv_kexec_elf_load(image, &ehdr, &elf_info,
> > > > @@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > >  		image->elf_load_addr = kbuf.mem;
> > > >  		image->elf_headers_sz = headers_sz;
> > > >  
> > > > -		pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > > -			 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > > +		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > > +			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > >  
> > > >  		/* Setup cmdline for kdump kernel case */
> > > >  		modified_cmdline = setup_kdump_cmdline(image, cmdline,
> > > > @@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > >  		pr_err("Error loading purgatory ret=%d\n", ret);
> > > >  		goto out;
> > > >  	}
> > > > +	kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem);
> > > > +
> > > >  	ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry",
> > > >  					     &kernel_start,
> > > >  					     sizeof(kernel_start), 0);
> > > > @@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > >  		if (ret)
> > > >  			goto out;
> > > >  		initrd_pbase = kbuf.mem;
> > > 
> > > > -		pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > > +		kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > 
> > > This is not a pr_debug().
> > > 
> > > >  	}
> > > >  
> > > >  	/* Add the DTB to the image */
> > > > @@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > >  	}
> > > >  	/* Cache the fdt buffer address for memory cleanup */
> > > >  	image->arch.fdt = fdt;
> > > 
> > > > -	pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > > +	kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > 
> > > Neither is this. Why are they being moved from pr_notice()?
> > 
> > You are right. 
> > 
> > While always printing out the loaded location of purgatory and
> > device tree doesn't make sense. It will be confusing when users
> > see these even when they do normal kexec/kdump loading. It should be
> > changed to pr_debug().
> > 
> > Which way do you suggest?
> > 1) change it back to pr_debug(), fix it in another patch;
> > 2) keep it as is in the patch;
> 
> Personally I think it is fine to change them all in one patch, but the
> rationale for converting pr_notice() to your new debug infrastructure
> needs to be in the commit message.

Sure, sounds good to me. I have changed the patch log to reflect this as
you suggested, please help check. Thanks again.



From jgg at nvidia.com  Wed Dec  6 07:38:09 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 6 Dec 2023 11:38:09 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZXCQrTbf6q0BIhSw@lpieralisi>
References: <86fs0hatt3.wl-maz@kernel.org>
 <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
 <ZXCJ3pVbKuHJ3LTz@arm.com>
 <20231206150556.GQ2692119@nvidia.com>
 <ZXCQrTbf6q0BIhSw@lpieralisi>
Message-ID: <20231206153809.GS2692119@nvidia.com>

On Wed, Dec 06, 2023 at 04:18:05PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Dec 06, 2023 at 11:05:56AM -0400, Jason Gunthorpe wrote:
> > On Wed, Dec 06, 2023 at 02:49:02PM +0000, Catalin Marinas wrote:
> > > On Tue, Dec 05, 2023 at 03:48:22PM -0400, Jason Gunthorpe wrote:
> > > > On Tue, Dec 05, 2023 at 07:24:37PM +0000, Catalin Marinas wrote:
> > > > > On Tue, Dec 05, 2023 at 12:43:18PM -0400, Jason Gunthorpe wrote:
> > > > > > What if we change vfio-pci to use pgprot_device() like it already
> > > > > > really should and say the pgprot_noncached() is enforced as
> > > > > > DEVICE_nGnRnE and pgprot_device() may be DEVICE_nGnRE or NORMAL_NC?
> > > > > > Would that be acceptable?
> > > > > 
> > > > > pgprot_device() needs to stay as Device, otherwise you'd get speculative
> > > > > reads with potential side-effects.
> > > > 
> > > > I do not mean to change pgprot_device() I mean to detect the
> > > > difference via pgprot_device() vs pgprot_noncached(). They put a
> > > > different value in the PTE that we can sense. It is very hacky.
> > > 
> > > Ah, ok, it does look hacky though (as is the alternative of coming up
> > > with a new specific pgprot_*() that KVM can treat differently).
> > > 
> > > BTW, on those Mellanox devices that require different attributes within
> > > a BAR, do they have a problem with speculative reads causing
> > > side-effects? 
> > 
> > Yes. We definitely have had that problem in the past on older
> > devices. VFIO must map the BAR using pgprot_device/noncached() into
> > the VMM, no other choice is functionally OK.
> 
> Were those BARs tagged as prefetchable or non-prefetchable ? I assume the
> latter but please let me know if I am guessing wrong.

I don't know it was quite old HW. Probably.

Just because a BAR is not marked as prefetchable doesn't mean that the
device can't use NORMAL_NC on subsets of it.

Jason


From conor at kernel.org  Wed Dec  6 07:40:21 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 6 Dec 2023 15:40:21 +0000
Subject: [PATCH v1 1/2] dt-bindings: display: panel: raspberrypi: Add
 compatible property for waveshare 7inch touchscreen panel
In-Reply-To: <2d48e460-e46e-431f-bd7b-e34ebe73a40c@starfivetech.com>
References: <20231124104451.44271-1-shengyang.chen@starfivetech.com>
 <20231124104451.44271-2-shengyang.chen@starfivetech.com>
 <20231124-lesser-sinister-7f9cd7b80e35@spud>
 <2d48e460-e46e-431f-bd7b-e34ebe73a40c@starfivetech.com>
Message-ID: <20231206-isolating-smoked-b490952029d0@spud>

On Wed, Dec 06, 2023 at 05:43:48PM +0800, Shengyang Chen wrote:
> Hi, Conor
> 
> On 2023/11/24 20:31, Conor Dooley wrote:
> > On Fri, Nov 24, 2023 at 06:44:50PM +0800, Shengyang Chen wrote:
> >> The waveshare 7inch touchscreen panel is a kind of raspberrypi pi
> >> panel
> > 
> > Can you be more specific about what "is a kind of rpi panel" means?
> > Are they using identical chips as controllers or something like that?
> > 
> 
> Wareshare panel has same i2c slave address and registers address with 
> the original raspberry pi panel. They both use Atmel firmware and they
> got same reg id. It can be operated by using the driver of raspberry pi driver
> after some change of the code. So I suppose it may be a kind of raspberry pi panel 
> and discribe it in this way. It's my own judgement. Sorry about that.
> Maybe just like Dave said, It cloned the behaviour of the raspberri pi panel.
> I will change the discribtion in next version to not make other confused.
> 
> By the way, we will try Stefan's method before next version. 
> The method we used in this patch may be abandoned if Stefan's method is verified in our platform.
> At that time yaml may also be changed to fit new method.

I don't know what Stefan's approach is, but I do not think that a
bindings patch should be dropped. The waveshare might be a clone, but it
is a distinct device. If the same driver can control both, then the
compatible setups that should be permitted are:
compatible = "raspberrypi,7inch-touchscreen-panel";
and
compatible = "waveshare,7inch-touchscreen-panel", "raspberrypi,7inch-touchscreen-panel";

Cheers,
Conor.

> >> and it can be drived by panel-raspberrypi-touchscreen.c.
> >> Add compatible property for it.
> >> 
> >> Signed-off-by: Keith Zhao <keith.zhao at starfivetech.com>
> >> Signed-off-by: Shengyang Chen <shengyang.chen at starfivetech.com>
> >> ---
> >>  .../bindings/display/panel/raspberrypi,7inch-touchscreen.yaml | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
> >> index 22a083f7bc8e..e4e6cb4d4e5b 100644
> >> --- a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
> >> +++ b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
> >> @@ -22,7 +22,9 @@ description: |+
> >>  
> >>  properties:
> >>    compatible:
> >> -    const: raspberrypi,7inch-touchscreen-panel
> >> +    enum:
> >> +      - raspberrypi,7inch-touchscreen-panel
> >> +      - waveshare,7inch-touchscreen-panel
> >>  
> >>    reg:
> >>      const: 0x45
> >> -- 
> >> 2.17.1
> >> 
> 
> 
> thanks.
> 
> Best Regards,
> Shengyang
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/94726463/attachment-0001.sig>

From mathieu.poirier at linaro.org  Wed Dec  6 07:43:07 2023
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 6 Dec 2023 08:43:07 -0700
Subject: [PATCH v7 3/4] remoteproc: zynqmp: add pm domains support
In-Reply-To: <ea2edc6e-6655-47f8-8b6d-242f5a0ef804@amd.com>
References: <20231117174238.1876655-1-tanmay.shah@amd.com> <20231117174238.1876655-4-tanmay.shah@amd.com>
 <ZV02P3bHEhPLQHBo@p14s> <93487d3c-c324-4b9b-8b25-0b4ea52237b4@amd.com>
 <ZV+V6V2sEWgsqngk@p14s> <a75b22c1-66e3-4fce-ae64-de79e73f3cfa@amd.com>
 <ZWdwl/8LC2Nn+vCq@p14s> <ea2edc6e-6655-47f8-8b6d-242f5a0ef804@amd.com>
Message-ID: <CANLsYkzJgZRSz5=nzW+ATmBKemoSd3ybhKuz1CJy33hftAGiqw@mail.gmail.com>

On Fri, 1 Dec 2023 at 11:10, Tanmay Shah <tanmay.shah at amd.com> wrote:
>
>
> On 11/29/23 11:10 AM, Mathieu Poirier wrote:
> > On Mon, Nov 27, 2023 at 10:33:05AM -0600, Tanmay Shah wrote:
> > >
> > > On 11/23/23 12:11 PM, Mathieu Poirier wrote:
> > > > On Wed, Nov 22, 2023 at 03:00:36PM -0600, Tanmay Shah wrote:
> > > > > Hi Mathieu,
> > > > >
> > > > > Please find my comments below.
> > > > >
> > > > > On 11/21/23 4:59 PM, Mathieu Poirier wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Fri, Nov 17, 2023 at 09:42:37AM -0800, Tanmay Shah wrote:
> > > > > > > Use TCM pm domains extracted from device-tree
> > > > > > > to power on/off TCM using general pm domain framework.
> > > > > > >
> > > > > > > Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> > > > > > > ---
> > > > > > >
> > > > > > > Changes in v7:
> > > > > > >   - %s/pm_dev1/pm_dev_core0/r
> > > > > > >   - %s/pm_dev_link1/pm_dev_core0_link/r
> > > > > > >   - %s/pm_dev2/pm_dev_core1/r
> > > > > > >   - %s/pm_dev_link2/pm_dev_core1_link/r
> > > > > > >   - remove pm_domain_id check to move next patch
> > > > > > >   - add comment about how 1st entry in pm domain list is used
> > > > > > >   - fix loop when jump to fail_add_pm_domains loop
> > > > > > >
> > > > > > >  drivers/remoteproc/xlnx_r5_remoteproc.c | 215 +++++++++++++++++++++++-
> > > > > > >  1 file changed, 212 insertions(+), 3 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > index 4395edea9a64..22bccc5075a0 100644
> > > > > > > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > @@ -16,6 +16,7 @@
> > > > > > >  #include <linux/of_reserved_mem.h>
> > > > > > >  #include <linux/platform_device.h>
> > > > > > >  #include <linux/remoteproc.h>
> > > > > > > +#include <linux/pm_domain.h>
> > > > > > >
> > > > > > >  #include "remoteproc_internal.h"
> > > > > > >
> > > > > > > @@ -102,6 +103,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
> > > > > > >   * @rproc: rproc handle
> > > > > > >   * @pm_domain_id: RPU CPU power domain id
> > > > > > >   * @ipi: pointer to mailbox information
> > > > > > > + * @num_pm_dev: number of tcm pm domain devices for this core
> > > > > > > + * @pm_dev_core0: pm domain virtual devices for power domain framework
> > > > > > > + * @pm_dev_core0_link: pm domain device links after registration
> > > > > > > + * @pm_dev_core1: used only in lockstep mode. second core's pm domain virtual devices
> > > > > > > + * @pm_dev_core1_link: used only in lockstep mode. second core's pm device links after
> > > > > > > + * registration
> > > > > > >   */
> > > > > > >  struct zynqmp_r5_core {
> > > > > > >     struct device *dev;
> > > > > > > @@ -111,6 +118,11 @@ struct zynqmp_r5_core {
> > > > > > >     struct rproc *rproc;
> > > > > > >     u32 pm_domain_id;
> > > > > > >     struct mbox_info *ipi;
> > > > > > > +   int num_pm_dev;
> > > > > > > +   struct device **pm_dev_core0;
> > > > > > > +   struct device_link **pm_dev_core0_link;
> > > > > > > +   struct device **pm_dev_core1;
> > > > > > > +   struct device_link **pm_dev_core1_link;
> > > > > > >  };
> > > > > > >
> > > > > > >  /**
> > > > > > > @@ -651,7 +663,8 @@ static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
> > > > > > >                                          ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> > > > > > >                                          ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> > > > > > >             if (ret < 0) {
> > > > > > > -                   dev_err(dev, "failed to turn on TCM 0x%x", pm_domain_id);
> > > > > > > +                   dev_err(dev, "failed to turn on TCM 0x%x",
> > > > > > > +                           pm_domain_id);
> > > > > >
> > > > > > Spurious change, you should have caught that.
> > > > >
> > > > > Ack, need to observe changes more closely before sending them.
> > > > >
> > > > > >
> > > > > > >                     goto release_tcm_lockstep;
> > > > > > >             }
> > > > > > >
> > > > > > > @@ -758,6 +771,189 @@ static int zynqmp_r5_parse_fw(struct rproc *rproc, const struct firmware *fw)
> > > > > > >     return ret;
> > > > > > >  }
> > > > > > >
> > > > > > > +static void zynqmp_r5_remove_pm_domains(struct rproc *rproc)
> > > > > > > +{
> > > > > > > +   struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > > +   struct device *dev = r5_core->dev;
> > > > > > > +   struct zynqmp_r5_cluster *cluster;
> > > > > > > +   int i;
> > > > > > > +
> > > > > > > +   cluster = platform_get_drvdata(to_platform_device(dev->parent));
> > > > > > > +
> > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > +           device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core0[i], false);
> > > > > > > +   }
> > > > > > > +
> > > > > > > +   kfree(r5_core->pm_dev_core0);
> > > > > > > +   r5_core->pm_dev_core0 = NULL;
> > > > > > > +   kfree(r5_core->pm_dev_core0_link);
> > > > > > > +   r5_core->pm_dev_core0_link = NULL;
> > > > > > > +
> > > > > > > +   if (cluster->mode == SPLIT_MODE) {
> > > > > > > +           r5_core->num_pm_dev = 0;
> > > > > > > +           return;
> > > > > > > +   }
> > > > > > > +
> > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > +           device_link_del(r5_core->pm_dev_core1_link[i]);
> > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core1[i], false);
> > > > > > > +   }
> > > > > > > +
> > > > > > > +   kfree(r5_core->pm_dev_core1);
> > > > > > > +   r5_core->pm_dev_core1 = NULL;
> > > > > > > +   kfree(r5_core->pm_dev_core1_link);
> > > > > > > +   r5_core->pm_dev_core1_link = NULL;
> > > > > > > +   r5_core->num_pm_dev = 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int zynqmp_r5_add_pm_domains(struct rproc *rproc)
> > > > > > > +{
> > > > > > > +   struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > > +   struct device *dev = r5_core->dev, *dev2;
> > > > > > > +   struct zynqmp_r5_cluster *cluster;
> > > > > > > +   struct platform_device *pdev;
> > > > > > > +   struct device_node *np;
> > > > > > > +   int i, j, num_pm_dev, ret;
> > > > > > > +
> > > > > > > +   cluster = dev_get_drvdata(dev->parent);
> > > > > > > +
> > > > > > > +   /* get number of power-domains */
> > > > > > > +   num_pm_dev = of_count_phandle_with_args(r5_core->np, "power-domains",
> > > > > > > +                                           "#power-domain-cells");
> > > > > > > +
> > > > > > > +   if (num_pm_dev <= 0)
> > > > > > > +           return -EINVAL;
> > > > > > > +
> > > > > > > +   r5_core->pm_dev_core0 = kcalloc(num_pm_dev,
> > > > > > > +                                   sizeof(struct device *),
> > > > > > > +                                   GFP_KERNEL);
> > > > > > > +   if (!r5_core->pm_dev_core0)
> > > > > > > +           ret = -ENOMEM;
> > > > > > > +
> > > > > > > +   r5_core->pm_dev_core0_link = kcalloc(num_pm_dev,
> > > > > > > +                                        sizeof(struct device_link *),
> > > > > > > +                                        GFP_KERNEL);
> > > > > > > +   if (!r5_core->pm_dev_core0_link) {
> > > > > > > +           kfree(r5_core->pm_dev_core0);
> > > > > > > +           r5_core->pm_dev_core0 = NULL;
> > > > > > > +           return -ENOMEM;
> > > > > > > +   }
> > > > > > > +
> > > > > > > +   r5_core->num_pm_dev = num_pm_dev;
> > > > > > > +
> > > > > > > +   /*
> > > > > > > +    * start from 2nd entry in power-domains property list as
> > > > > > > +    * for zynqmp we only add TCM power domains and not core's power domain.
> > > > > > > +    * 1st entry is used to configure r5 operation mode.
> > > > > >
> > > > > > You are still not saying _where_ ->pm_dev_core0[0] gets added.
> > > > >
> > > > > So, pm_dev_core0[0] isn't really need to be added for zynqmp platform, as firmware starts it with call,
> > > > >
> > > > > zynqmp_pm_request_wake during rproc_start callback. I will document this in next
> > > > >
> > > >
> > > > That is exactly what I am looking for.  That way people don't have to go through
> > > > the entire driver trying to figure out what is happening with pm_dev_core[0].
> > > >
> > > > I'm also not sure about the power-up order.  Logically the TCMs should be
> > > > powered up before the R5 in order to put code in them.  The R5s are powered in
> > > > zynqmp_r5_rproc_start() but I am unclear as to where in the boot sequence the
> > > > TCMs are powered - can you expand on that?
> > >
> > >
> > > Sure. Following is call sequece
> > >
> > > zynqmp_r5_rproc_prepare
> > >
> > > zynqmp_r5_add_pm_domains -> Here TCM is powered on when device_link_add is called via zynqmp-pm-domains.c driver.
> > >
> > > . . .
> > >
> > > zynqmp_r5_rproc_start -> load firmware and Starts RPU
> > >
> > > So what you mentioned is correct, TCM is being powerd-on before we load firmware and start RPU.
> > >
> > >
> > > >
> > > > > revision. For new platforms pm_dev_core0[0] will be added in future.
> > > >
> > > > Now I'm really confused - what do you mean by "pm_dev_core0[0] will be added in
> > > > future"?
> > >
> > >
> > > ZynqMP platform has platform management firmware running on microblaze.
> > >
> > > This firmware design does not expect R5 pm domains to be requested explicitly.
> > >
> > > This means, during zynqmp_r5_rproc_start when "zynqmp_pm_request_wake" is called,
> > >
> > > firmware powers on R5. So, pm_dev_core[0] is not really used for ZynqMP.
> > >
> > > However, this design was changed for new platforms i.e. "versal" and onwards.
> > >
> > > Firmware of new platform expects pm domains to be requested explicitly for R5 cores before
> > >
> > > waking them up.
> > >
> > > That means, pm_dev_core[0] for R5 cores on new platform (Versal) needs to be used same as TCM.
> > >
> > > Then, we should wake it up on r5_core.
> > >
> > > To summarize:
> > >
> > > For zynqmp only following call needed to start R5:
> > >
> > > zynqmp_pm_request_wake
> > >
> > > For "versal" and onwards we need two calls to start R5:
> > >
> > > "device_link_add" and zynqmp_pm_request_wake
> > >
> > > So, in future pm_core_dev[0] will be used.
> > >
> >
> > Thanks for the clarification on both front.  The problem here is that we are
> > keeping R5 power domain information in two different places, i.e
> > zynqmp_r5_core::pm_domain_id and zynqmp_r5_core::pm_dev_core0[0].
> >
> > Please see if you can retreive the power domain ID from
> > zynqmp_r5_core::pm_dev_core0[0].  That way you can get the power domain ID when
> > calling zynqmp_pm_request_wake() and zynqmp_pm_force_pwrdwn() and get rid of
> > zynqmp_r5_core::pm_domain_id.
>
> Hi Mathieu,
>
> I looked into this. Probably I can't retrieve pm_domain_id from pm_dev_core0[0],
>
> However, I can retrieve it from device-tree when calling zynqmp_pm_request_wake
>
> and zynqmp_pm_force_pwrdwn.
>
> zynqmp_r5_core::pm_domain_id is caching that value during probe, and use it during
> rest of the driver lifecycle.
>
> I am okay either way, (keeping it as it is, or get it from device-tree). Let me know your
>
> preference.
>

Humm...  Then I suggest to simply get rid of the device linking to
deal with the TCMs' power management.  From where I stand it provides
more confusion than benefits, and that is without considering the
extra complexity.

> Thanks,
>
> Tanmay
>
> > >
> > > > >
> > > > > I hope this meets expectations.
> > > > >
> > > > >
> > > > > >
> > > > > > > +    */
> > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > +           r5_core->pm_dev_core0[i] = dev_pm_domain_attach_by_id(dev, i);
> > > > > > > +           if (IS_ERR_OR_NULL(r5_core->pm_dev_core0[i])) {
> > > > > >
> > > > > > Here IS_ERR_OR_NULL() is used while two if conditions for NULL and an error
> > > > > > code are used in the loop for the lockstep mode.  Please pick one heuristic and
> > > > > > stick with it.  I have no preference on which one.
> > > > >
> > > > > Ok, I think IS_ERR_OR_NULL is more cleaner, I will address it in next revision.
> > > > >
> > > > >
> > > > > >
> > > > > > > +                   dev_dbg(dev, "failed to attach pm domain %d, ret=%ld\n", i,
> > > > > > > +                           PTR_ERR(r5_core->pm_dev_core0[i]));
> > > > > > > +                   ret = -EINVAL;
> > > > > > > +                   goto fail_add_pm_domains;
> > > > > > > +           }
> > > > > > > +           r5_core->pm_dev_core0_link[i] = device_link_add(dev,
> > > > > > > +                                                           r5_core->pm_dev_core0[i],
> > > > > > > +                                                           DL_FLAG_STATELESS |
> > > > > > > +                                                           DL_FLAG_RPM_ACTIVE |
> > > > > > > +                                                           DL_FLAG_PM_RUNTIME);
> > > > > > > +           if (!r5_core->pm_dev_core0_link[i]) {
> > > > > > > +                   dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > > +                   r5_core->pm_dev_core0[i] = NULL;
> > > > > > > +                   ret = -EINVAL;
> > > > > > > +                   goto fail_add_pm_domains;
> > > > > > > +           }
> > > > > > > +   }
> > > > > > > +
> > > > > > > +   if (cluster->mode == SPLIT_MODE)
> > > > > > > +           return 0;
> > > > > > > +
> > > > > > > +   r5_core->pm_dev_core1 = kcalloc(num_pm_dev,
> > > > > > > +                                   sizeof(struct device *),
> > > > > > > +                                   GFP_KERNEL);
> > > > > > > +   if (!r5_core->pm_dev_core1) {
> > > > > > > +           ret = -ENOMEM;
> > > > > > > +           goto fail_add_pm_domains;
> > > > > > > +   }
> > > > > > > +
> > > > > > > +   r5_core->pm_dev_core1_link = kcalloc(num_pm_dev,
> > > > > > > +                                        sizeof(struct device_link *),
> > > > > > > +                                        GFP_KERNEL);
> > > > > > > +   if (!r5_core->pm_dev_core1_link) {
> > > > > > > +           kfree(r5_core->pm_dev_core1);
> > > > > > > +           r5_core->pm_dev_core1 = NULL;
> > > > > > > +           ret = -ENOMEM;
> > > > > > > +           goto fail_add_pm_domains;
> > > > > > > +   }
> > > > > > > +
> > > > > > > +   /* get second core's device to detach its power-domains */
> > > > > > > +   np = of_get_next_child(cluster->dev->of_node, of_node_get(dev->of_node));
> > > > > > > +
> > > > > > > +   pdev = of_find_device_by_node(np);
> > > > > > > +   if (!pdev) {
> > > > > > > +           dev_err(cluster->dev, "core1 platform device not available\n");
> > > > > > > +           kfree(r5_core->pm_dev_core1);
> > > > > > > +           kfree(r5_core->pm_dev_core1_link);
> > > > > > > +           r5_core->pm_dev_core1 = NULL;
> > > > > > > +           r5_core->pm_dev_core1_link = NULL;
> > > > > > > +           ret = -EINVAL;
> > > > > > > +           goto fail_add_pm_domains;
> > > > > > > +   }
> > > > > > > +
> > > > > > > +   dev2 = &pdev->dev;
> > > > > > > +
> > > > > > > +   /* for zynqmp we only add TCM power domains and not core's power domain */
> > > > > > > +   for (j = 1; j < r5_core->num_pm_dev; j++) {
> > > > > > > +           r5_core->pm_dev_core1[j] = dev_pm_domain_attach_by_id(dev2, j);
> > > > > > > +           if (!r5_core->pm_dev_core1[j]) {
> > > > > > > +                   dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > > +                   ret = -EINVAL;
> > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > +           } else if (IS_ERR(r5_core->pm_dev_core1[j])) {
> > > > > > > +                   dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > > +                   ret = PTR_ERR(r5_core->pm_dev_core1[j]);
> > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > +           }
> > > > > > > +
> > > > > > > +           r5_core->pm_dev_core1_link[j] = device_link_add(dev,
> > > > > > > +                                                           r5_core->pm_dev_core1[j],
> > > > > > > +                                                           DL_FLAG_STATELESS |
> > > > > > > +                                                           DL_FLAG_RPM_ACTIVE |
> > > > > > > +                                                           DL_FLAG_PM_RUNTIME);
> > > > > > > +           if (!r5_core->pm_dev_core1_link[j]) {
> > > > > > > +                   dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > > +                   r5_core->pm_dev_core1[j] = NULL;
> > > > > > > +                   ret = -ENODEV;
> > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > +           }
> > > > > > > +   }
> > > > > > > +
> > > > > > > +fail_add_pm_domains_lockstep:
> > > > > > > +   while (--j >= 0) {
> > > > > > > +           device_link_del(r5_core->pm_dev_core1_link[j]);
> > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > > +   }
> > > > > > > +   kfree(r5_core->pm_dev_core1);
> > > > > > > +   r5_core->pm_dev_core1 = NULL;
> > > > > > > +   kfree(r5_core->pm_dev_core1_link);
> > > > > > > +   r5_core->pm_dev_core1_link = NULL;
> > > > > > > +
> > > > > > > +fail_add_pm_domains:
> > > > > > > +   while (--i >= 0) {
> > > > > > > +           device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > > +   }
> > > > > > > +   kfree(r5_core->pm_dev_core0);
> > > > > > > +   r5_core->pm_dev_core0 = NULL;
> > > > > > > +   kfree(r5_core->pm_dev_core0_link);
> > > > > > > +   r5_core->pm_dev_core0_link = NULL;
> > > > > > > +
> > > > > >
> > > > > > The error path is much cleaner and readable now.
> > > > > >
> > > > > > I will continue tomorrow.
> > > > > >
> > > > > > Mathieu
> > > > > >
> > > > > > > +   return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > >  /**
> > > > > > >   * zynqmp_r5_rproc_prepare()
> > > > > > >   * adds carveouts for TCM bank and reserved memory regions
> > > > > > > @@ -770,19 +966,30 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
> > > > > > >  {
> > > > > > >     int ret;
> > > > > > >
> > > > > > > +   ret = zynqmp_r5_add_pm_domains(rproc);
> > > > > > > +   if (ret) {
> > > > > > > +           dev_err(&rproc->dev, "failed to add pm domains\n");
> > > > > > > +           return ret;
> > > > > > > +   }
> > > > > > > +
> > > > > > >     ret = add_tcm_banks(rproc);
> > > > > > >     if (ret) {
> > > > > > >             dev_err(&rproc->dev, "failed to get TCM banks, err %d\n", ret);
> > > > > > > -           return ret;
> > > > > > > +           goto fail_prepare;
> > > > > > >     }
> > > > > > >
> > > > > > >     ret = add_mem_regions_carveout(rproc);
> > > > > > >     if (ret) {
> > > > > > >             dev_err(&rproc->dev, "failed to get reserve mem regions %d\n", ret);
> > > > > > > -           return ret;
> > > > > > > +           goto fail_prepare;
> > > > > > >     }
> > > > > > >
> > > > > > >     return 0;
> > > > > > > +
> > > > > > > +fail_prepare:
> > > > > > > +   zynqmp_r5_remove_pm_domains(rproc);
> > > > > > > +
> > > > > > > +   return ret;
> > > > > > >  }
> > > > > > >
> > > > > > >  /**
> > > > > > > @@ -801,6 +1008,8 @@ static int zynqmp_r5_rproc_unprepare(struct rproc *rproc)
> > > > > > >
> > > > > > >     r5_core = rproc->priv;
> > > > > > >
> > > > > > > +   zynqmp_r5_remove_pm_domains(rproc);
> > > > > > > +
> > > > > > >     for (i = 0; i < r5_core->tcm_bank_count; i++) {
> > > > > > >             pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
> > > > > > >             if (zynqmp_pm_release_node(pm_domain_id))
> > > > > > > --
> > > > > > > 2.25.1
> > > > > > >


From ryan.roberts at arm.com  Wed Dec  6 07:44:44 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 6 Dec 2023 15:44:44 +0000
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
 <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
Message-ID: <5c06e3fc-e8f0-4896-ab71-2317a71e812a@arm.com>

On 06/12/2023 14:19, Ryan Roberts wrote:
> On 05/12/2023 16:32, David Hildenbrand wrote:
>> On 04.12.23 11:20, Ryan Roberts wrote:
>>> Introduce the logic to allow THP to be configured (through the new sysfs
>>> interface we just added) to allocate large folios to back anonymous
>>> memory, which are larger than the base page size but smaller than
>>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>>>
>>> mTHP continues to be PTE-mapped, but in many cases can still provide
>>> similar benefits to traditional PMD-sized THP: Page faults are
>>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
>>> the configured order), but latency spikes are much less prominent
>>> because the size of each page isn't as huge as the PMD-sized variant and
>>> there is less memory to clear in each page fault. The number of per-page
>>> operations (e.g. ref counting, rmap management, lru list management) are
>>> also significantly reduced since those ops now become per-folio.
>>>
>>> Some architectures also employ TLB compression mechanisms to squeeze
>>> more entries in when a set of PTEs are virtually and physically
>>> contiguous and approporiately aligned. In this case, TLB misses will
>>> occur less often.
>>>
>>> The new behaviour is disabled by default, but can be enabled at runtime
>>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
>>> (see documentation in previous commit). The long term aim is to change
>>> the default to include suitable lower orders, but there are some risks
>>> around internal fragmentation that need to be better understood first.
>>>
>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>
>> In general, looks good to me, some comments/nits. And the usual "let's make sure
>> we don't degrade order-0 and keep that as fast as possible" comment.
>>
>>> ---
>>> ? include/linux/huge_mm.h |?? 6 ++-
>>> ? mm/memory.c???????????? | 106 ++++++++++++++++++++++++++++++++++++----
>>> ? 2 files changed, 101 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>> index bd0eadd3befb..91a53b9835a4 100644
>>> --- a/include/linux/huge_mm.h
>>> +++ b/include/linux/huge_mm.h
>>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>>> ? #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>>> ? ? /*
>>> - * Mask of all large folio orders supported for anonymous THP.
>>> + * Mask of all large folio orders supported for anonymous THP; all orders up to
>>> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
>>> + * (which is a limitation of the THP implementation).
>>> ?? */
>>> -#define THP_ORDERS_ALL_ANON??? BIT(PMD_ORDER)
>>> +#define THP_ORDERS_ALL_ANON??? ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>>> ? ? /*
>>> ?? * Mask of all large folio orders supported for file THP.
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index 3ceeb0f45bf5..bf7e93813018 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>> ????? return ret;
>>> ? }
>>> ? +static bool pte_range_none(pte_t *pte, int nr_pages)
>>> +{
>>> +??? int i;
>>> +
>>> +??? for (i = 0; i < nr_pages; i++) {
>>> +??????? if (!pte_none(ptep_get_lockless(pte + i)))
>>> +??????????? return false;
>>> +??? }
>>> +
>>> +??? return true;
>>> +}
>>> +
>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>>> +{
>>> +??? gfp_t gfp;
>>> +??? pte_t *pte;
>>> +??? unsigned long addr;
>>> +??? struct folio *folio;
>>> +??? struct vm_area_struct *vma = vmf->vma;
>>> +??? unsigned long orders;
>>> +??? int order;
>>
>> Nit: reverse christmas tree encouraged ;)
> 
> ACK will fix.
> 
>>
>>> +
>>> +??? /*
>>> +???? * If uffd is active for the vma we need per-page fault fidelity to
>>> +???? * maintain the uffd semantics.
>>> +???? */
>>> +??? if (userfaultfd_armed(vma))
>>
>> Nit: unlikely()
> 
> ACK will fix.
> 
>>
>>> +??????? goto fallback;
>>> +
>>> +??? /*
>>> +???? * Get a list of all the (large) orders below PMD_ORDER that are enabled
>>> +???? * for this vma. Then filter out the orders that can't be allocated over
>>> +???? * the faulting address and still be fully contained in the vma.
>>> +???? */
>>> +??? orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
>>> +????????????????????? BIT(PMD_ORDER) - 1);
>>> +??? orders = thp_vma_suitable_orders(vma, vmf->address, orders);
>>
>> Comment: Both will eventually loop over all orders, correct? Could eventually be
>> sped up in the future.
> 
> No only thp_vma_suitable_orders() will loop. thp_vma_allowable_orders() only
> loops if in_pf=false (it's true here).
> 
>>
>> Nit: the orders = ... order = ... looks like this might deserve a helper
>> function that makes this easier to read.
> 
> To be honest, the existing function that I've modified is a bit of a mess.
> thp_vma_allowable_orders() calls thp_vma_suitable_orders() if we are not in a
> page fault, because the page fault handlers already do that check themselves. It
> would be nice to refactor the whole thing so that thp_vma_allowable_orders() is
> a strict superset of thp_vma_suitable_orders(). Then this can just call
> thp_vma_allowable_orders(). But that's going to start touching the PMD and PUD
> handlers, so prefer if we leave that for a separate patch set.
> 
>>
>> Nit: Why call thp_vma_suitable_orders if the orders are already 0? Again, some
>> helper might be reasonable where that is handled internally.
> 
> Because thp_vma_suitable_orders() will handle it safely and is inline, so it
> should just as efficient? This would go away with the refactoring described above.
> 
>>
>> Comment: For order-0 we'll always perform a function call to both
>> thp_vma_allowable_orders() / thp_vma_suitable_orders(). We should perform some
>> fast and efficient check if any <PMD THP are even enabled in the system / for
>> this VMA, and in that case just fallback before doing more expensive checks.
> 

I just noticed I got these functions round the wrong way in my previous response:

> thp_vma_allowable_orders() is inline as you mentioned.

^ Meant thp_vma_suitable_orders() here.

> 
> I was deliberately trying to keep all the decision logic in one place
> (thp_vma_suitable_orders) because it's already pretty complicated. But if you

^ Meant thp_vma_allowable_orders() here.

Sorry for the confusion.

> insist, how about this in the header:
> 
> static inline
> unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
> 				       unsigned long vm_flags, bool smaps,
> 				       bool in_pf, bool enforce_sysfs,
> 				       unsigned long orders)
> {
> 	/* Optimization to check if required orders are enabled early. */
> 	if (enforce_sysfs && vma_is_anonymous(vma)) {
> 		unsigned long mask = READ_ONCE(huge_anon_orders_always);
> 
> 		if (vm_flags & VM_HUGEPAGE)
> 			mask |= READ_ONCE(huge_anon_orders_madvise);
> 		if (hugepage_global_always() ||
> 			((vm_flags & VM_HUGEPAGE) && hugepage_global_enabled()))
> 			mask |= READ_ONCE(huge_anon_orders_inherit);
> 
> 		orders &= mask;
> 		if (!orders)
> 			return 0;
> 		
> 		enforce_sysfs = false;
> 	}
> 
> 	return __thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf,
> 					  enforce_sysfs, orders);
> }
> 
> Then the above check can be removed from __thp_vma_allowable_orders() - it will
> still retain the `if (enforce_sysfs && !vma_is_anonymous(vma))` part.
> 
> 
>>
>>> +
>>> +??? if (!orders)
>>> +??????? goto fallback;
>>> +
>>> +??? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>> +??? if (!pte)
>>> +??????? return ERR_PTR(-EAGAIN);
>>> +
>>> +??? order = first_order(orders);
>>> +??? while (orders) {
>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>> +??????? vmf->pte = pte + pte_index(addr);
>>> +??????? if (pte_range_none(vmf->pte, 1 << order))
>>> +??????????? break;
>>
>> Comment: Likely it would make sense to scan only once and determine the "largest
>> none range" around that address, having the largest suitable order in mind.
> 
> Yes, that's how I used to do it, but Yu Zhou requested simplifying to this,
> IIRC. Perhaps this an optimization opportunity for later?
> 
>>
>>> +??????? order = next_order(&orders, order);
>>> +??? }
>>> +
>>> +??? vmf->pte = NULL;
>>
>> Nit: Can you elaborate why you are messing with vmf->pte here? A simple helper
>> variable will make this code look less magical. Unless I am missing something
>> important :)
> 
> Gahh, I used to pass the vmf to what pte_range_none() was refactored into (an
> approach that was suggested by Yu Zhou IIRC). But since I did some refactoring
> based on some comments from JohnH, I see I don't need that anymore. Agreed; it
> will be much clearer just to use a local variable. Will fix.
> 
>>
>>> +??? pte_unmap(pte);
>>> +
>>> +??? gfp = vma_thp_gfp_mask(vma);
>>> +
>>> +??? while (orders) {
>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>> +??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>> +??????? if (folio) {
>>> +??????????? clear_huge_page(&folio->page, addr, 1 << order);
>>> +??????????? return folio;
>>> +??????? }
>>> +??????? order = next_order(&orders, order);
>>> +??? }
>>> +
>>
>> Queestion: would it make sense to combine both loops? I suspect memory
>> allocations with pte_offset_map()/kmao are problematic.
> 
> They are both operating on separate orders; next_order() is "consuming" an order
> by removing the current one from the orders bitfield and returning the next one.
> 
> So the first loop starts at the highest order and keeps checking lower orders
> until one fully fits in the VMA. And the second loop starts at the first order
> that was found to fully fits and loops to lower orders until an allocation is
> successful.
> 
> So I don't see a need to combine the loops.
> 
>>
>>> +fallback:
>>> +??? return vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>> +}
>>> +#else
>>> +#define alloc_anon_folio(vmf) \
>>> +??????? vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
>>> +#endif
>>> +
>>> ? /*
>>> ?? * We enter with non-exclusive mmap_lock (to exclude vma changes,
>>> ?? * but allow concurrent faults), and pte mapped but not yet locked.
>>> @@ -4132,6 +4210,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>> ?? */
>>> ? static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>> ? {
>>> +??? int i;
>>> +??? int nr_pages = 1;
>>> +??? unsigned long addr = vmf->address;
>>> ????? bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
>>> ????? struct vm_area_struct *vma = vmf->vma;
>>> ????? struct folio *folio;
>>
>> Nit: reverse christmas tree :)
> 
> ACK
> 
>>
>>> @@ -4176,10 +4257,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>> ????? /* Allocate our own private page. */
>>> ????? if (unlikely(anon_vma_prepare(vma)))
>>> ????????? goto oom;
>>> -??? folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>> +??? folio = alloc_anon_folio(vmf);
>>> +??? if (IS_ERR(folio))
>>> +??????? return 0;
>>> ????? if (!folio)
>>> ????????? goto oom;
>>> ? +??? nr_pages = folio_nr_pages(folio);
>>> +??? addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
>>> +
>>> ????? if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
>>> ????????? goto oom_free_page;
>>> ????? folio_throttle_swaprate(folio, GFP_KERNEL);
>>> @@ -4196,12 +4282,13 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>> ????? if (vma->vm_flags & VM_WRITE)
>>> ????????? entry = pte_mkwrite(pte_mkdirty(entry), vma);
>>> ? -??? vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
>>> -??????????? &vmf->ptl);
>>> +??? vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
>>> ????? if (!vmf->pte)
>>> ????????? goto release;
>>> -??? if (vmf_pte_changed(vmf)) {
>>> -??????? update_mmu_tlb(vma, vmf->address, vmf->pte);
>>> +??? if ((nr_pages == 1 && vmf_pte_changed(vmf)) ||
>>> +??????? (nr_pages? > 1 && !pte_range_none(vmf->pte, nr_pages))) {
>>> +??????? for (i = 0; i < nr_pages; i++)
>>> +??????????? update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);
>>
>> Comment: separating the order-0 case from the other case might make this easier
>> to read.
> 
> Yeah fair enough. Will fix.
> 
>>
>>> ????????? goto release;
>>> ????? }
>>> ? @@ -4216,16 +4303,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault
>>> *vmf)
>>> ????????? return handle_userfault(vmf, VM_UFFD_MISSING);
>>> ????? }
>>> ? -??? inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
>>> -??? folio_add_new_anon_rmap(folio, vma, vmf->address);
>>> +??? folio_ref_add(folio, nr_pages - 1);
>>> +??? add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
>>> +??? folio_add_new_anon_rmap(folio, vma, addr);
>>> ????? folio_add_lru_vma(folio, vma);
>>> ? setpte:
>>> ????? if (uffd_wp)
>>> ????????? entry = pte_mkuffd_wp(entry);
>>> -??? set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
>>> +??? set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
>>> ? ????? /* No need to invalidate - it was non-present before */
>>> -??? update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
>>> +??? update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
>>> ? unlock:
>>> ????? if (vmf->pte)
>>> ????????? pte_unmap_unlock(vmf->pte, vmf->ptl);
>>
>> Benchmarking order-0 allocations might be interesting. There will be some added
>> checks + multiple loops/conditionals for order-0 that could be avoided by having
>> two separate code paths. If we can't measure a difference, all good.
> 
> Yep will do - will post numbers once I have them. I've been assuming that the
> major cost is clearing the page, but perhaps I'm wrong.
> 
>>
> 



From peteryin.openbmc at gmail.com  Wed Dec  6 07:53:13 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Wed,  6 Dec 2023 23:53:13 +0800
Subject: [PATCH v6 0/2] Add Facebook Harma (AST2600) BMC
Message-ID: <20231206155316.4181813-1-peteryin.openbmc@gmail.com>

Summary:
Add linux device tree entry related to Harma
specific devices connected to BMC SoC.

v5:https://lore.kernel.org/all/20231204081029.2272626-3-peteryin.openbmc at gmail.com/
v4:https://lore.kernel.org/all/20231204054131.1845775-3-peter.yin at quantatw.com/
v3:https://lore.kernel.org/all/20231123050415.3441429-3-peteryin.openbmc at gmail.com/
v2:https://lore.kernel.org/all/cdbc75b9-3be1-4017-9bee-c8f161b6843c at linaro.org/
v1:https://lore.kernel.org/all/20231024082404.735843-3-peteryin.openbmc at gmail.com/

Change log
v5 -> v6
  - Add Retimer eeprom
  - Add Power Led
  - Add GPIO/SGPIO Line Name

v4 -> v5
  - Rename document and file from minerva-harma to harma. 
  - remove Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
v3 -> v4
  - Add SGPIO line name.

v2 -> v3:
  - Fixed led schema.
  - Fixed i2c mux schema.
  - Add BMC_READY and SGPIO_READY.

v1 -> v2:
  - Add Power sensors.
  - Modify ehci number.
  - Add Led.
  - Modify SGPIO line-name.
v1:
  - Create minerva harma dts file.

Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
Peter Yin (2):
  dt-bindings: arm: aspeed: add Meta Harma board
  ARM: dts: aspeed: Harma: Add Facebook Harma (AST2600) BMC

 .../bindings/arm/aspeed/aspeed.yaml           |   1 +
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-facebook-harma.dts  | 607 ++++++++++++++++++
 3 files changed, 609 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts

-- 
2.25.1



From peteryin.openbmc at gmail.com  Wed Dec  6 07:53:14 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Wed,  6 Dec 2023 23:53:14 +0800
Subject: [PATCH v6 1/2] dt-bindings: arm: aspeed: add Meta Harma board
In-Reply-To: <20231206155316.4181813-1-peteryin.openbmc@gmail.com>
References: <20231206155316.4181813-1-peteryin.openbmc@gmail.com>
Message-ID: <20231206155316.4181813-2-peteryin.openbmc@gmail.com>

Document the new compatibles used on Meta Harma.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
 Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index e17b3d66d6e55..fac3cda3f4870 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -79,6 +79,7 @@ properties:
               - facebook,elbert-bmc
               - facebook,fuji-bmc
               - facebook,greatlakes-bmc
+              - facebook,harma-bmc
               - facebook,yosemite4-bmc
               - ibm,everest-bmc
               - ibm,rainier-bmc
-- 
2.25.1



From peteryin.openbmc at gmail.com  Wed Dec  6 07:53:15 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Wed,  6 Dec 2023 23:53:15 +0800
Subject: [PATCH v6 2/2] ARM: dts: aspeed: Harma: Add Facebook Harma (AST2600) BMC
In-Reply-To: <20231206155316.4181813-1-peteryin.openbmc@gmail.com>
References: <20231206155316.4181813-1-peteryin.openbmc@gmail.com>
Message-ID: <20231206155316.4181813-3-peteryin.openbmc@gmail.com>

Add linux device tree entry related to
Harma specific devices connected to BMC SoC.

Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-facebook-harma.dts  | 607 ++++++++++++++++++
 2 files changed, 608 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts

diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 23cbc7203a8e3..92ba3208d2a27 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -19,6 +19,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-facebook-fuji.dtb \
 	aspeed-bmc-facebook-galaxy100.dtb \
 	aspeed-bmc-facebook-greatlakes.dtb \
+	aspeed-bmc-facebook-harma.dtb \
 	aspeed-bmc-facebook-minipack.dtb \
 	aspeed-bmc-facebook-tiogapass.dtb \
 	aspeed-bmc-facebook-wedge40.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
new file mode 100644
index 0000000000000..85a3607fc4b19
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
@@ -0,0 +1,607 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2023 Facebook Inc.
+
+/dts-v1/;
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/i2c/i2c.h>
+
+/ {
+	model = "Facebook Harma";
+	compatible = "facebook,harma-bmc", "aspeed,ast2600";
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart6;
+		serial2 = &uart2;
+		serial4 = &uart5;
+
+		i2c20 = &imux20;
+		i2c21 = &imux21;
+		i2c22 = &imux22;
+		i2c23 = &imux23;
+		i2c24 = &imux24;
+		i2c25 = &imux25;
+		i2c26 = &imux26;
+		i2c27 = &imux27;
+		i2c28 = &imux28;
+		i2c29 = &imux29;
+		i2c30 = &imux30;
+		i2c31 = &imux31;
+	};
+
+	chosen {
+		stdout-path = &uart5;
+	};
+
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+
+	iio-hwmon {
+		compatible = "iio-hwmon";
+		io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+			      <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+			      <&adc1 2>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			label = "bmc_heartbeat_amber";
+			gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led-1 {
+			label = "fp_id_amber";
+			default-state = "off";
+			gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-2 {
+			label = "power_blue";
+			default-state = "off";
+			gpios = <&gpio0 124 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+// HOST BIOS Debug
+&uart1 {
+	status = "okay";
+};
+
+// SOL Host Console
+&uart2 {
+	status = "okay";
+	pinctrl-0 = <>;
+};
+
+// SOL BMC Console
+&uart4 {
+	status = "okay";
+	pinctrl-0 = <>;
+};
+
+// BMC Debug Console
+&uart5 {
+	status = "okay";
+};
+
+// MTIA
+&uart6 {
+	status = "okay";
+};
+
+&uart_routing {
+	status = "okay";
+};
+
+&vuart1 {
+	status = "okay";
+	virtual;
+	port=<0x3e8>;
+	sirq = <7>;
+	sirq-polarity = <0>;
+	dma-mode;
+	dma-channel = <12>;
+};
+
+&wdt1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdtrst1_default>;
+	aspeed,reset-type = "soc";
+	aspeed,external-signal;
+	aspeed,ext-push-pull;
+	aspeed,ext-active-high;
+	aspeed,ext-pulse-duration = <256>;
+};
+
+&mac3 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rmii4_default>;
+	no-hw-checksum;
+	use-ncsi;
+	ncsi-ctrl,start-redo-probe;
+	ncsi-ctrl,no-channel-monitor;
+	mlx,multi-host;
+	ncsi-package = <1>;
+	ncsi-channel = <1>;
+	ncsi-rexmit = <1>;
+	ncsi-timeout = <2>;
+};
+
+&rtc {
+	status = "okay";
+};
+
+&fmc {
+	status = "okay";
+
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "bmc";
+		spi-max-frequency = <50000000>;
+#include "openbmc-flash-layout-128.dtsi"
+	};
+
+	flash at 1 {
+		status = "okay";
+		m25p,fast-read;
+		label = "alt-bmc";
+		spi-max-frequency = <50000000>;
+	};
+};
+
+// BIOS Flash
+&spi2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spi2_default>;
+
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "pnor";
+		spi-max-frequency = <12000000>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
+	};
+};
+
+&kcs2 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca8>;
+};
+
+&kcs3 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca2>;
+};
+
+&i2c0 {
+	status = "okay";
+
+	max31790 at 30{
+		compatible = "max31790";
+		reg = <0x30>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
+
+&i2c1 {
+	status = "okay";
+
+	tmp75 at 4b {
+		compatible = "ti,tmp75";
+		reg = <0x4b>;
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	max31790 at 30{
+		compatible = "max31790";
+		reg = <0x30>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
+
+&i2c3 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9543";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux20: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			//Retimer Flash
+			eeprom at 50 {
+				compatible = "atmel,24c2048";
+				reg = <0x50>;
+				pagesize = <128>;
+			};
+		};
+		imux21: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
+};
+
+&i2c4 {
+	status = "okay";
+	// PDB FRU
+	eeprom at 52 {
+		compatible = "atmel,24c64";
+		reg = <0x52>;
+	};
+
+	delta_brick at 69 {
+		compatible = "pmbus";
+		reg = <0x69>;
+	};
+};
+
+&i2c5 {
+	status = "okay";
+};
+
+&i2c6 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9543";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux22: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux23: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
+};
+
+&i2c7 {
+	status = "okay";
+};
+
+&i2c8 {
+	status = "okay";
+};
+
+&i2c9 {
+	status = "okay";
+
+	gpio at 30 {
+		compatible = "nxp,pca9555";
+		reg = <0x30>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+	gpio at 31 {
+		compatible = "nxp,pca9555";
+		reg = <0x31>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	i2c-mux at 71 {
+		compatible = "nxp,pca9546";
+		reg = <0x71>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux24: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux25: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+		imux26: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+		imux27: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+	};
+	// PTTV FRU
+	eeprom at 52 {
+		compatible = "atmel,24c64";
+		reg = <0x52>;
+	};
+};
+
+&i2c11 {
+	status = "okay";
+};
+
+&i2c12 {
+	status = "okay";
+};
+
+&i2c13 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9545";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux28: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux29: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			//MB FRU
+			eeprom at 54 {
+				compatible = "atmel,24c64";
+				reg = <0x54>;
+			};
+		};
+		imux30: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+		imux31: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+	};
+};
+
+// To Debug card
+&i2c14 {
+	status = "okay";
+	multi-master;
+
+	ipmb at 10 {
+		compatible = "ipmb-dev";
+		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+		i2c-protocol;
+	};
+};
+
+&i2c15 {
+	status = "okay";
+
+	// SCM FRU
+	eeprom at 50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+	};
+
+	// BSM FRU
+	eeprom at 56 {
+		compatible = "atmel,24c64";
+		reg = <0x56>;
+	};
+};
+
+&adc0 {
+	aspeed,int-vref-microvolt = <2500000>;
+	status = "okay";
+	pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+		&pinctrl_adc2_default &pinctrl_adc3_default
+		&pinctrl_adc4_default &pinctrl_adc5_default
+		&pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+	aspeed,int-vref-microvolt = <2500000>;
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc10_default>;
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-names = "default";
+	gpio-line-names =
+	/*A0-A7*/	"","","","","","","","",
+	/*B0-B7*/	"","","","",
+			"FM_BMC_MUX_CS_SPI_SEL_0","FM_ID_LED_N","","",
+	/*C0-C7*/	"","","","","","","","",
+	/*D0-D7*/	"","","SOL_UART_SET","","","","","",
+	/*E0-E7*/	"","","","","","","","",
+	/*F0-F7*/	"","","","","","","","",
+	/*G0-G7*/	"","","","","","","","",
+	/*H0-H7*/	"","","","","","","","",
+	/*I0-I7*/	"","","","","","","","",
+	/*J0-J7*/	"","","","","","","","",
+	/*K0-K7*/	"","","","","","","","",
+	/*L0-L7*/	"","","","","","","","",
+	/*M0-M7*/	"","","","","","","","",
+	/*N0-N7*/	"LED_POSTCODE_0","LED_POSTCODE_1",
+			"LED_POSTCODE_2","LED_POSTCODE_3",
+			"LED_POSTCODE_4","LED_POSTCODE_5",
+			"LED_POSTCODE_6","LED_POSTCODE_7",
+	/*O0-O7*/	"","","","","","","","",
+	/*P0-P7*/	"FP_SYS_PWRBTN_IN_N","BMC_SYS_PWRBTN_OUT_N",
+			"FP_RST_BTN_IN_N","","POWER_LED","","","",
+	/*Q0-Q7*/	"","","","","","","","",
+	/*R0-R7*/	"","","","","","","","",
+	/*S0-S7*/	"","","","","","","","",
+	/*T0-T7*/	"","","","","","","","",
+	/*U0-U7*/	"","","","","","","ENABLE_ID_LED_GATE","",
+	/*V0-V7*/	"","","","","BAT_DETECT","","","",
+	/*W0-W7*/	"","","","","","","","",
+	/*X0-X7*/	"","","","","","","","",
+	/*Y0-Y7*/	"","","","","","","","",
+	/*Z0-Z7*/	"","","","","","","","";
+};
+
+&sgpiom0 {
+	status = "okay";
+	max-ngpios = <128>;
+	ngpios = <128>;
+	bus-frequency = <2000000>;
+	gpio-line-names =
+	/*in - out - in - out */
+	/*A0-A3 line 0-7*/
+	"FM_SCM_CABLE_PRSNT_N","FM_PWRDIS_E1S_0",
+	"FM_EXP_AUX_PWR_EN","",
+	"FM_EXP_MAIN_PWR_EN","FM_PWRDIS_E1S_1",
+	"PWRGD_EXP_PWR","",
+	/*A4-A7 line 8-15*/
+	"PWRGD_P12V_MEM","FM_MODULE_PWR_EN",
+	"PWRGD_P3V3_STBY","FM_HOST_PWRGD",
+	"PWRGD_P1V8","FM_CRD_PWRGD_L",
+	"FM_PRSNT_CPU_N","FM_SMI_ACTIVE_N",
+	/*B0-B3 line 16-23*/
+	"FM_PVDD33_S5_EN","BMC_CPU_NMI_N",
+	"RGD_PVDD33_S5","NMI_SYNC_FLOOD_N",
+	"FM_PVDD18_S5_EN","",
+	"PWRGD_PVDD18_S5","",
+	/*B4-B7 line 24-31*/
+	"PWRGD_SB_STBY_PWROK","FM_CPU_SP5R1",
+	"RST_RSMRST_PLD_N","FM_CPU_SP5R2",
+	"SYS_SCM_PWRBTN_N","FM_CPU_SP5R3",
+	"SYS_PWRBTN_N","FM_CPU_SP5R4",
+	/*C0-C3 line 32-39*/
+	"FM_SLPS5_PLD_N","FM_CPU0_SA0",
+	"FM_SLPS3_PLD_N","FM_CPU0_SA1",
+	"FM_PVDD11_S3_EN","FM_RT_CPU0_P0_LVS_EN",
+	"PWRGD_CHGK","FM_RT_CPU0_P1_LVS_EN",
+	/*C4-C7 line 40-47*/
+	"PWRGD_CHAE","FM_SMB_RT_ROM_P0_SEL",
+	"PWRGD_PVDD11_S3","FM_SMB_RT_ROM_P1_SEL",
+	"PVDDCR_CPU0_EN","FM_I3C_CPU_MUX0_OE_N",
+	"PWRGD_PVDDCR_CPU0","FM_I3C_CPU_MUX0_SEL",
+	/*D0-D3 line 48-55*/
+	"PVDDCR_CPU1_EN","FM_I3C_CPU_MUX1_OE_N",
+	"PWRGD_PVDDCR_CPU1","FM_I3C_CPU_MUX1_SEL",
+	"PVDDCR_SOC_EN","RST_BMC_N",
+	"PWRGD_PVDDCR_SOC","RST_MUX_CPU0_P0_N",
+	/*D4-D7 line 56-63*/
+	"PVDDIO_EN","RST_MUX_CPU0_P1_N",
+	"PWRGD_PVDDIO","RST_MUX_E1S_N",
+	"PLD_SYS_POWER_GOOD","RST_MUX_MB_N",
+	"FM_CPU_PWR_GOOD","RST_SMB_E1S_0_N",
+	/*E0-E3 line 64-71*/
+	"FM_PWRGD_CPU_PWROK","RST_SMB_E1S_1_N",
+	"PLD_BIOS_POST_CMPLT_N","RST_SRST_CPLD_SCM_N",
+	"FM_PRSNT_E1S_0_N","RST_USB_HUB_R_N",
+	"FM_E1S_0_EN","BMC_RST_BTN_OUT_N",
+	/*E4-E7 line 72-79*/
+	"FM_PRSNT_E1S_1_N","RST_CPU_KBRST_N",
+	"FM_E1S_1_EN","RST_PLTRST_SCM_N",
+	"FM_P0V9_RT_EN1","BMC_JTAG_MUX_SEL_0",
+	"PWRGD_P0V9_RT1","BMC_JTAG_MUX_SEL_1",
+	/*F0-F3 line 80-87*/
+	"FM_P0V9_RT_EN2","BMC_JTAG_SEL",
+	"PWRGD_P0V9_RT2","BMC_READY_N",
+	"FM_P1V8_CPU1_RT_EN","BMC_SGPIO_READY",
+	"PWRGD_P1V8_CPU1_RT","FM_RT_CPU0_P0_LVS_EN_FORCE",
+	/*F4-F7 line 88-95*/
+	"FM_MODULES_0_PRSNT1_N","FM_RT_CPU0_P1_LVS_EN_FORCE",
+	"FM_MODULES_1_PRSNT1_N","FM_BIOS_MRC_DEBUG_MSG_DIS",
+	"FM_PWRGD_MODULE","UART_BUF_SEL",
+	"FM_CMM_PRS_L","AC_ON_OFF_BTN_CPLD_N",
+	/*G0-G3 line 96-103*/
+	"FM_CPU_CORETYPE2","",
+	"FM_CPU_CORETYPE1","",
+	"FM_CPU_CORETYPE0","",
+	"FM_BOARD_REV_ID5","",
+	/*G4-G7 line 104-111*/
+	"FM_BOARD_REV_ID4","",
+	"FM_BOARD_REV_ID3","",
+	"FM_BOARD_REV_ID2","",
+	"FM_BOARD_REV_ID1","",
+	/*H0-H3 line 112-119*/
+	"FM_BOARD_REV_ID0","",
+	"FM_FAN_0_PWRGD_L","",
+	"FM_FAN_1_PWRGD_L","",
+	"FM_UART_SCM_BUF_0_EN","",
+	/*H4-H7 line 120-127*/
+	"FM_UART_SCM_BUF_1_EN","",
+	"FM_EXP_PRSNT3_N","",
+	"FM_EXP_PRSNT2_N","",
+	"FM_EXP_PRSNT1_N","",
+	/*I0-I3 line 128-135*/
+	"FM_EXP_PRSNT0_N","",
+	"FM_EXP_SLOT_ID1","",
+	"FM_EXP_SLOT_ID0","",
+	"FM_FORCE_POWERON_N","",
+	/*I4-I7 line 136-143*/
+	"FM_P5V_USB_SW_EN_N","",
+	"FM_JTAG_SCM_SEL","",
+	"FM_RST_CPU_RESET_N","",
+	"FM_SOL_UART_CH_SEL","",
+	/*J0-J3 line 144-151*/
+	"RST_MB_STBY_SCM_N","",
+	"","",
+	"RST_PCIE_MODULES_PERST0","",
+	"RST_ROT_CPU","",
+	/*J4-J7 line 152-159*/
+	"SLOT_ID_BCB_0","",
+	"SLOT_ID_BCB_1","",
+	"SLOT_ID_BCB_2","",
+	"SLOT_ID_BCB_3","",
+	/*K0-K3 line 160-167*/
+	"FM_RT_CPU0_P0_LVS_EN_R","",
+	"FM_RT_CPU0_P1_LVS_EN_R","",
+	"","","","",
+	/*K4-K7 line 168-175*/
+	"","","","","","","","",
+	/*L0-L3 line 176-183*/
+	"","","","","","","","",
+	/*L4-L7 line 184-191*/
+	"","","","","","","","",
+	/*M0-M3 line 192-199*/
+	"","","","","","","","",
+	/*M4-M7 line 200-207*/
+	"","","","","","","","",
+	/*N0-N3 line 208-215*/
+	"","","","","","","","",
+	/*N4-N7 line 216-223*/
+	"","","","","","","","",
+	/*O0-O3 line 224-231*/
+	"","","","","","","","",
+	/*O4-O7 line 232-239*/
+	"","","","","","","","",
+	/*P0-P3 line 240-247*/
+	"","","","","","","","",
+	/*P4-P7 line 248-255*/
+	"","","","","","","","";
+};
-- 
2.25.1



From nm at ti.com  Wed Dec  6 07:58:37 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 6 Dec 2023 09:58:37 -0600
Subject: (subset) [PATCH v3 0/3] Revamp k3-socinfo driver
In-Reply-To: <20231016101608.993921-1-n-francis@ti.com>
References: <20231016101608.993921-1-n-francis@ti.com>
Message-ID: <170187817080.1997.17836327731857780198.b4-ty@ti.com>

Hi Neha Malcom Francis,

On Mon, 16 Oct 2023 15:46:05 +0530, Neha Malcom Francis wrote:
> k3-socinfo driver doesn't account for difference series of silicon
> revisions instead of the typical 1.0, 2.0 etc case. This exception is
> currently already seen in J721E. This series aims to modify the driver
> to account for those exceptions as well as clean things up a bit.
> 
> Changes since v2:
> 	- Nishanth:
> 		- update commit message
> 		- move from double Signed-off-by to Co-developed-by
> 		- make j721e_rev_string_map[] a const char
> 		- drop k3_rev_string_map[] and continue using old
> 		  "variant++" logic for the typical cases
> 		- appropriate error handling with no overrides
> 		  distinguishing between ENODEV and ENOMEM
> 		- add patch for error handling initial cleanup
> 		- reorder patches
> 
> [...]

I have applied the following to branch ti-drivers-soc-next on [1].
Thank you!

[3/3] soc: ti: k3-socinfo: Revamp driver to accommodate different rev structs
      commit: 3ba080bf46e4a9039d0d41356f4a2515e00bf747

The networking dependency previously identified has been sorted out
and available in linux-next[2] since next-20231206. So, this is a good
time for us to merge the patch that I have been keeping held up. At least
on my local scan, I don't see any other in-tree driver impacted by this.

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
[2] https://lore.kernel.org/all/20231201132033.29576-1-r-gunasekaran at ti.com/
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From Frank.Li at nxp.com  Wed Dec  6 07:58:54 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:58:54 -0500
Subject: [PATCH 0/9] PCI: imx6: Clean up and add imx95 pci support
Message-ID: <20231206155903.566194-1-Frank.Li@nxp.com>

first 6 patches use drvdata: flags to simplify some switch-case code.
Improve maintaince and easy to read code.

Then add imx95 basic pci host function.

@richard and #shenwei

This just precode, please review it as draft ideas.

Frank Li (8):
  PCI: imx6: Simplify clock handling by using HAS_CLK_* bitmask
  PCI: imx6: Simplify phy handling by using by using
    IMX6_PCIE_FLAG_HAS_PHY
  PCI: imx6: Simplify reset handling by using by using
    *_FLAG_HAS_*_RESET
  PCI: imx6: Using "linux,pci-domain" as slot ID
  PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
  PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
  PCI: imx6: Simplify switch-case logic by involve init_phy callback
  PCI: imx6: Add iMX95 PCIe support

Richard Zhu (1):
  dt-bindings: imx6q-pcie: Add imx95 pcie compatible string

 .../bindings/pci/fsl,imx6q-pcie.yaml          |   1 +
 drivers/pci/controller/dwc/pci-imx6.c         | 513 ++++++++++--------
 2 files changed, 302 insertions(+), 212 deletions(-)

-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 07:58:55 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:58:55 -0500
Subject: [PATCH 1/9] PCI: imx6: Simplify clock handling by using HAS_CLK_* bitmask
In-Reply-To: <20231206155903.566194-1-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
Message-ID: <20231206155903.566194-2-Frank.Li@nxp.com>

Refactors the clock handling logic in the imx6 PCI driver by adding
HAS_CLK_* bitmask define for drvdata::flags . Simplifies the code and makes
it more maintainable, as future additions of SOC support will only require
straightforward changes. The drvdata::flags and a bitmask ensures a cleaner
and more scalable switch-case structure for handling clocks.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 84 +++++++++++++--------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 74703362aeec..8a9b527934f8 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -60,6 +60,10 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
+#define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
+#define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
+
+#define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
@@ -550,19 +554,23 @@ static int imx6_pcie_attach_pd(struct device *dev)
 
 static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	struct dw_pcie *pci = imx6_pcie->pci;
-	struct device *dev = pci->dev;
 	unsigned int offset;
 	int ret = 0;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
 		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_axi clock\n");
-			break;
-		}
+		if (ret)
+			return ret;
+	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
+		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
+		if (ret)
+			return ret;
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
 		break;
@@ -589,12 +597,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_aux clock\n");
-			break;
-		}
-
 		offset = imx6_pcie_grp_offset(imx6_pcie);
 		/*
 		 * Set the over ride low and enabled
@@ -614,10 +616,13 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI))
 		clk_disable_unprepare(imx6_pcie->pcie_inbound_axi);
-		break;
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX))
+		clk_disable_unprepare(imx6_pcie->pcie_aux);
+
+	switch (imx6_pcie->drvdata->variant) {
 	case IMX6QP:
 	case IMX6Q:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
@@ -631,14 +636,6 @@ static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		clk_disable_unprepare(imx6_pcie->pcie_aux);
-		break;
 	default:
 		break;
 	}
@@ -1316,21 +1313,21 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
 				     "pcie clock source missing or invalid\n");
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
-							   "pcie_inbound_axi");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
+		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev, "pcie_inbound_axi");
 		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
-					     "pcie_inbound_axi clock missing or invalid\n");
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
+			dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
+				      "pcie_inbound_axi clock missing or invalid\n");
+	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
 		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
 		if (IS_ERR(imx6_pcie->pcie_aux))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
 					     "pcie_aux clock source missing or invalid\n");
-		fallthrough;
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
 			imx6_pcie->controller_id = 1;
@@ -1353,10 +1350,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	case IMX8MM_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
 		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
 									 "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
@@ -1482,7 +1475,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.variant = IMX6SX,
 		.flags = IMX6_PCIE_FLAG_IMX6_PHY |
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
-			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 	},
 	[IMX6QP] = {
@@ -1500,30 +1494,36 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 07:58:56 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:58:56 -0500
Subject: [PATCH 2/9] PCI: imx6: Simplify phy handling by using by using IMX6_PCIE_FLAG_HAS_PHY
In-Reply-To: <20231206155903.566194-1-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
Message-ID: <20231206155903.566194-3-Frank.Li@nxp.com>

Refactors the phy handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_PHY bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling phy.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 8a9b527934f8..bcf52aa86462 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -62,6 +62,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 #define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
 #define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
+#define IMX6_PCIE_FLAG_HAS_PHY			BIT(5)
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
@@ -1327,6 +1328,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "pcie_aux clock source missing or invalid\n");
 	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY)) {
+		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+		if (IS_ERR(imx6_pcie->phy))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
+					     "failed to get pcie phy\n");
+	}
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
@@ -1356,11 +1364,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
 
-		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
-		if (IS_ERR(imx6_pcie->phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
-					     "failed to get pcie phy\n");
-
 		break;
 	default:
 		break;
@@ -1500,24 +1503,28 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
-		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 07:58:57 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:58:57 -0500
Subject: [PATCH 3/9] PCI: imx6: Simplify reset handling by using by using *_FLAG_HAS_*_RESET
In-Reply-To: <20231206155903.566194-1-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
Message-ID: <20231206155903.566194-4-Frank.Li@nxp.com>

Refactors the reset handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling reset.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 115 +++++++++++---------------
 1 file changed, 47 insertions(+), 68 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index bcf52aa86462..62d77fabd82a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -63,6 +63,8 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
 #define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(5)
+#define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(6)
+#define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(7)
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
@@ -696,18 +698,13 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET))
 		reset_control_assert(imx6_pcie->pciephy_reset);
-		fallthrough;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET))
 		reset_control_assert(imx6_pcie->apps_reset);
-		break;
+
+	switch (imx6_pcie->drvdata->variant) {
 	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
@@ -728,6 +725,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
 		break;
+	default:
+		break;
 	}
 
 	/* Some boards don't have PCIe reset GPIO. */
@@ -741,14 +740,11 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-		break;
-	case IMX7D:
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET))
 		reset_control_deassert(imx6_pcie->pciephy_reset);
 
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX7D:
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
 		 * Corrector" and other mysterious undocumented things.
@@ -780,11 +776,7 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 
 		usleep_range(200, 500);
 		break;
-	case IMX6Q:		/* Nothing to do */
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
+	default:
 		break;
 	}
 
@@ -831,16 +823,12 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2,
 				   IMX6Q_GPR12_PCIE_CTL_2);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_deassert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET))
+		reset_control_deassert(imx6_pcie->apps_reset);
 }
 
 static void imx6_pcie_ltssm_disable(struct device *dev)
@@ -854,16 +842,12 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET))
+		reset_control_assert(imx6_pcie->apps_reset);
 }
 
 static int imx6_pcie_start_link(struct dw_pcie *pci)
@@ -1335,36 +1319,24 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "failed to get pcie phy\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-
-		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
-									    "pciephy");
-		if (IS_ERR(imx6_pcie->pciephy_reset)) {
-			dev_err(dev, "Failed to get PCIEPHY reset control\n");
-			return PTR_ERR(imx6_pcie->pciephy_reset);
-		}
-
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
-		if (IS_ERR(imx6_pcie->apps_reset)) {
-			dev_err(dev, "Failed to get PCIE APPS reset control\n");
-			return PTR_ERR(imx6_pcie->apps_reset);
-		}
-		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET)) {
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev, "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
+	}
 
-		break;
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET)) {
+		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev, "pciephy");
+		if (IS_ERR(imx6_pcie->pciephy_reset))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pciephy_reset),
+					     "Failed to get PCIEPHY reset control\n");
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX7D:
+		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
+			imx6_pcie->controller_id = 1;
 	default:
 		break;
 	}
@@ -1492,32 +1464,39 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
-		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
 			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
 			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 07:58:58 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:58:58 -0500
Subject: [PATCH 4/9] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231206155903.566194-1-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
Message-ID: <20231206155903.566194-5-Frank.Li@nxp.com>

Avoid use get slot id by compared with register physical address. If there
are more than 2 slots, compared logic will become complex.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 62d77fabd82a..239ef439ba70 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -33,6 +33,7 @@
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
+#include "../../pci.h"
 #include "pcie-designware.h"
 
 #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
@@ -1333,6 +1334,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "Failed to get PCIEPHY reset control\n");
 	}
 
+	/* Using linux,pci-domain as PCI slot id */
+	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
+	if (imx6_pcie->controller_id)
+		imx6_pcie->controller_id = 0;
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 07:58:59 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:58:59 -0500
Subject: [PATCH 5/9] PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
In-Reply-To: <20231206155903.566194-1-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
Message-ID: <20231206155903.566194-6-Frank.Li@nxp.com>

Add drvdata::ltssm_off and drvdata::ltssm_mask to simple
imx6_pcie_ltssm_enable(disable)() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 37 ++++++++++++---------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 239ef439ba70..334e714a7e96 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,8 @@ struct imx6_pcie_drvdata {
 	u32 flags;
 	int dbi_length;
 	const char *gpr;
+	const u32 ltssm_off;
+	const u32 ltssm_mask;
 };
 
 struct imx6_pcie {
@@ -815,18 +817,11 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_ltssm_enable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2,
-				   IMX6Q_GPR12_PCIE_CTL_2);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off, drvdata->ltssm_mask,
+				   drvdata->ltssm_mask);
 
 	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET))
 		reset_control_deassert(imx6_pcie->apps_reset);
@@ -835,17 +830,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 static void imx6_pcie_ltssm_disable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2, 0);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off,
+				   drvdata->ltssm_mask, 0);
 
 	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET))
 		reset_control_assert(imx6_pcie->apps_reset);
@@ -1451,6 +1440,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1459,6 +1450,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
 			 IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1467,6 +1460,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 07:59:00 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:59:00 -0500
Subject: [PATCH 6/9] PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
In-Reply-To: <20231206155903.566194-1-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
Message-ID: <20231206155903.566194-7-Frank.Li@nxp.com>

Add drvdata::mode_off and drvdata::mode_mask to simple
imx6_pcie_configure_type() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 60 ++++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 334e714a7e96..a2a3496fe8a0 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -69,6 +69,7 @@ enum imx6_pcie_variants {
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
+#define IMX6_PCIE_MAX_INSTANCES			2
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -77,6 +78,8 @@ struct imx6_pcie_drvdata {
 	const char *gpr;
 	const u32 ltssm_off;
 	const u32 ltssm_mask;
+	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
+	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
 };
 
 struct imx6_pcie {
@@ -177,32 +180,25 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
-	unsigned int mask, val, mode;
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
+	unsigned int mask, val, mode, id;
 
-	if (imx6_pcie->drvdata->mode == DW_PCIE_EP_TYPE)
+	if (drvdata->mode == DW_PCIE_EP_TYPE)
 		mode = PCI_EXP_TYPE_ENDPOINT;
 	else
 		mode = PCI_EXP_TYPE_ROOT_PORT;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		if (imx6_pcie->controller_id == 1) {
-			mask = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
-					  mode);
-		} else {
-			mask = IMX6Q_GPR12_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		}
-		break;
-	default:
-		mask = IMX6Q_GPR12_DEVICE_TYPE;
-		val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		break;
-	}
+	id = imx6_pcie->controller_id;
+
+	/* If mode_mask[id] is zero, means each controller have its individual gpr */
+	if (!drvdata->mode_mask[id])
+		id = 0;
+
+	mask = drvdata->mode_mask[id];
+	/* FIELD_PREP mask have been constant */
+	val = mode << __bf_shf(mask);
 
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, mask, val);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->mode_off[id], mask, val);
 }
 
 static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
@@ -1442,6 +1438,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1452,6 +1450,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1462,6 +1462,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1469,6 +1471,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET |
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1476,6 +1480,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET |
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1484,6 +1492,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY |
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
@@ -1492,6 +1502,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY |
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
@@ -1500,6 +1512,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
@@ -1507,12 +1523,16 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 07:59:01 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:59:01 -0500
Subject: [PATCH 7/9] PCI: imx6: Simplify switch-case logic by involve init_phy callback
In-Reply-To: <20231206155903.566194-1-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
Message-ID: <20231206155903.566194-8-Frank.Li@nxp.com>

Add drvdata::init_phy() callback function, so difference SOC choose
difference callback function to simple switch-case logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 135 ++++++++++++++------------
 1 file changed, 71 insertions(+), 64 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index a2a3496fe8a0..990b91534ea9 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -70,6 +70,9 @@ enum imx6_pcie_variants {
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
 #define IMX6_PCIE_MAX_INSTANCES			2
+
+struct imx6_pcie;
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -80,6 +83,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
 struct imx6_pcie {
@@ -326,76 +330,69 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
 	return 0;
 }
 
-static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+static int imx8mq_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		/*
-		 * The PHY initialization had been done in the PHY
-		 * driver, break here directly.
-		 */
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		/*
-		 * TODO: Currently this code assumes external
-		 * oscillator is being used
-		 */
+	/*
+	 * TODO: Currently this code assumes external
+	 * oscillator is being used
+	 */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   imx6_pcie_grp_offset(imx6_pcie),
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD,
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD);
+	/*
+	 * Regarding the datasheet, the PCIE_VPH is suggested
+	 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
+	 * VREG_BYPASS should be cleared to zero.
+	 */
+	if (imx6_pcie->vph && regulator_get_voltage(imx6_pcie->vph) > 3000000)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr,
 				   imx6_pcie_grp_offset(imx6_pcie),
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD,
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD);
-		/*
-		 * Regarding the datasheet, the PCIE_VPH is suggested
-		 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
-		 * VREG_BYPASS should be cleared to zero.
-		 */
-		if (imx6_pcie->vph &&
-		    regulator_get_voltage(imx6_pcie->vph) > 3000000)
-			regmap_update_bits(imx6_pcie->iomuxc_gpr,
-					   imx6_pcie_grp_offset(imx6_pcie),
-					   IMX8MQ_GPR_PCIE_VREG_BYPASS,
-					   0);
-		break;
-	case IMX7D:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX8MQ_GPR_PCIE_VREG_BYPASS,
+				   0);
+
+	return 0;
+}
+
+static int imx7d_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	return	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
-		break;
-	case IMX6SX:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6SX_GPR12_PCIE_RX_EQ_MASK,
-				   IMX6SX_GPR12_PCIE_RX_EQ_2);
-		fallthrough;
-	default:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+}
+
+static int imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 
-		/* configure constant input signal to the pcie ctrl and phy */
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
-
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN1,
-				   imx6_pcie->tx_deemph_gen1 << 0);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
-				   imx6_pcie->tx_deemph_gen2_3p5db << 6);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
-				   imx6_pcie->tx_deemph_gen2_6db << 12);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_FULL,
-				   imx6_pcie->tx_swing_full << 18);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_LOW,
-				   imx6_pcie->tx_swing_low << 25);
-		break;
-	}
+	/* configure constant input signal to the pcie ctrl and phy */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN1,
+			   imx6_pcie->tx_deemph_gen1 << 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
+			   imx6_pcie->tx_deemph_gen2_3p5db << 6);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
+			   imx6_pcie->tx_deemph_gen2_6db << 12);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_FULL,
+			   imx6_pcie->tx_swing_full << 18);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_LOW,
+			   imx6_pcie->tx_swing_low << 25);
+	return 0;
+}
 
-	imx6_pcie_configure_type(imx6_pcie);
+static int imx6sx_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6SX_GPR12_PCIE_RX_EQ_MASK, IMX6SX_GPR12_PCIE_RX_EQ_2);
+
+	return imx6_pcie_init_phy(imx6_pcie);
 }
 
 static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
@@ -945,7 +942,11 @@ static int imx6_pcie_host_init(struct dw_pcie_rp *pp)
 	}
 
 	imx6_pcie_assert_core_reset(imx6_pcie);
-	imx6_pcie_init_phy(imx6_pcie);
+
+	if (imx6_pcie->drvdata->init_phy)
+		imx6_pcie->drvdata->init_phy(imx6_pcie);
+
+	imx6_pcie_configure_type(imx6_pcie);
 
 	ret = imx6_pcie_clk_enable(imx6_pcie);
 	if (ret) {
@@ -1440,6 +1441,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1452,6 +1454,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6sx_pcie_init_phy,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1464,6 +1467,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1473,6 +1477,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx7d_pcie_init_phy,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1484,6 +1489,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1516,6 +1522,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 07:59:02 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:59:02 -0500
Subject: [PATCH 8/9] dt-bindings: imx6q-pcie: Add imx95 pcie compatible string
In-Reply-To: <20231206155903.566194-1-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
Message-ID: <20231206155903.566194-9-Frank.Li@nxp.com>

From: Richard Zhu <hongxing.zhu at nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.

Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
---
 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 81bbb8728f0f..723335767843 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -29,6 +29,7 @@ properties:
       - fsl,imx8mq-pcie
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
+      - fsl,imx95-pcie
 
   reg:
     items:
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 07:59:03 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 10:59:03 -0500
Subject: [PATCH 9/9] PCI: imx6: Add iMX95 PCIe support
In-Reply-To: <20231206155903.566194-1-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
Message-ID: <20231206155903.566194-10-Frank.Li@nxp.com>

Add iMX95 PCIe basic root complex function support.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 85 +++++++++++++++++++++++++--
 1 file changed, 80 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 990b91534ea9..7e51aef97baa 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -43,6 +43,25 @@
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
 #define IMX8MQ_PCIE2_BASE_ADDR			0x33c00000
 
+#define IMX95_PCIE_PHY_GEN_CTRL			0x0
+#define IMX95_PCIE_REF_USE_PAD			BIT(17)
+
+#define IMX95_PCIE_PHY_MPLLA_CTRL		0x10
+#define IMX95_PCIE_PHY_MPLL_STATE		BIT(30)
+
+#define IMX95_PCIE_SS_RW_REG_0			0xf0
+#define IMX95_PCIE_REF_CLKEN			BIT(23)
+#define IMX95_PCIE_PHY_CR_PARA_SEL		BIT(9)
+
+#define IMX95_PE0_GEN_CTRL_1			0x1050
+#define IMX95_PCIE_DEVICE_TYPE			GENMASK(3, 0)
+
+#define IMX95_PE0_GEN_CTRL_3			0x1058
+#define IMX95_PCIE_LTSSM_EN			BIT(0)
+
+#define IMX95_PE0_PM_STS			0x1064
+#define IMX95_PCIE_PM_LINKST_IN_L2		BIT(14)
+
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -53,6 +72,7 @@ enum imx6_pcie_variants {
 	IMX8MQ,
 	IMX8MM,
 	IMX8MP,
+	IMX95,
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
@@ -79,6 +99,7 @@ struct imx6_pcie_drvdata {
 	u32 flags;
 	int dbi_length;
 	const char *gpr;
+	u32 pf_lut_offset;
 	const u32 ltssm_off;
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
@@ -182,6 +203,24 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
+static int imx95_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			IMX95_PCIE_SS_RW_REG_0,
+			IMX95_PCIE_PHY_CR_PARA_SEL,
+			IMX95_PCIE_PHY_CR_PARA_SEL);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_PHY_GEN_CTRL,
+			   IMX95_PCIE_REF_USE_PAD, 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_SS_RW_REG_0,
+			   IMX95_PCIE_REF_CLKEN,
+			   IMX95_PCIE_REF_CLKEN);
+
+	return 0;
+}
+
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
 	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
@@ -589,6 +628,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
 		break;
 	case IMX7D:
+	case IMX95:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -735,11 +775,20 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 {
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
+	u32 val;
 
 	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET))
 		reset_control_deassert(imx6_pcie->pciephy_reset);
 
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX95:
+		/* Polling the MPLL_STATE */
+		if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+					IMX95_PCIE_PHY_MPLLA_CTRL, val,
+					val & IMX95_PCIE_PHY_MPLL_STATE,
+					10, 10000))
+			dev_err(dev, "PCIe PLL lock timeout\n");
+		break;
 	case IMX7D:
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
@@ -1348,12 +1397,27 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(imx6_pcie->turnoff_reset);
 	}
 
+	if (imx6_pcie->drvdata->gpr) {
 	/* Grab GPR config register range */
-	imx6_pcie->iomuxc_gpr =
-		 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
-	if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
-		dev_err(dev, "unable to find iomuxc registers\n");
-		return PTR_ERR(imx6_pcie->iomuxc_gpr);
+		imx6_pcie->iomuxc_gpr =
+			 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
+	}
+
+	if (imx6_pcie->drvdata->pf_lut_offset) {
+		void __iomem *off = pci->dbi_base + imx6_pcie->drvdata->pf_lut_offset;
+		static struct regmap_config regmap_config = {
+			.reg_bits = 32,
+			.val_bits = 32,
+			.reg_stride = 4,
+		};
+
+		imx6_pcie->iomuxc_gpr = devm_regmap_init_mmio(dev, off, &regmap_config);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
 	}
 
 	/* Grab PCIe PHY Tx Settings */
@@ -1511,6 +1575,16 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
+	[IMX95] = {
+		.variant = IMX8MP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.pf_lut_offset = 0x40000,
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
@@ -1551,6 +1625,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
 	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{ .compatible = "fsl,imx8mp-pcie", .data = &drvdata[IMX8MP], },
+	{ .compatible = "fsl,imx95-pcie", .data = &drvdata[IMX95], },
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
-- 
2.34.1



From nm at ti.com  Wed Dec  6 08:02:19 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 6 Dec 2023 10:02:19 -0600
Subject: [PATCH] arm64: dts: ti: phycore-am64: Add R5F DMA Region and Mailboxes
In-Reply-To: <20231204212304.1736306-1-ggiordano@phytec.com>
References: <20231204212304.1736306-1-ggiordano@phytec.com>
Message-ID: <170187833586.2751.3691315852629771770.b4-ty@ti.com>

Hi Garrett Giordano,

On Mon, 04 Dec 2023 13:23:04 -0800, Garrett Giordano wrote:
> Communication between the R5F subsystem and Linux takes place using DMA
> memory regions and mailboxes. Here we add DT nodes for the memory
> regions and mailboxes to facilitate communication between the R5
> clusters and Linux as remoteproc will fail to start if no memory
> regions or mailboxes are provided.
> 
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/1] arm64: dts: ti: phycore-am64: Add R5F DMA Region and Mailboxes
      commit: 5709a6809a6869970ef47bbad7451d32e9081ce1

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From conor at kernel.org  Wed Dec  6 08:02:49 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 6 Dec 2023 16:02:49 +0000
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <FE0DBA5E-95A5-4C27-9F69-D1D8BDF56EC3@goldelico.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <CFF198DA-5C42-425E-86F4-759629489ECB@goldelico.com>
 <cb590a13-e0ff-49d9-8583-be613ad50dc5@ti.com>
 <FE0DBA5E-95A5-4C27-9F69-D1D8BDF56EC3@goldelico.com>
Message-ID: <20231206-wolverine-paprika-0674ca01e1f2@spud>

On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote:
> > Am 05.12.2023 um 18:33 schrieb Andrew Davis <afd at ti.com>:
> > 
> > On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
> >>> +          - enum:
> >>> +              - ti,omap3430-gpu # Rev 121
> >>> +              - ti,omap3630-gpu # Rev 125
> >> Is the "Rev 121" and "Rev 125" a property of the SoC integration (clock/reset/power
> >> hookup etc.) or of the integrated SGX core?
> > 
> > The Rev is a property of the SGX core, not the SoC integration.
> 
> Then, it should belong there and not be a comment of the ti,omap*-gpu record.
> In this way it does not seem to be a proper hardware description.
> 
> BTW: there are examples where the revision is part of the compatible string, even
> if the (Linux) driver makes no use of it:
> 
> drivers/net/ethernet/xilinx/xilinx_emaclite.c

AFAICT these Xilinx devices that put the revisions in the compatible are
a different case - they're "soft" IP intended for use in the fabric of
an FPGA, and assigning a device specific compatible there does not make
sense.

In this case it appears that the revision is completely known once you
see "ti,omap3630-gpu", so encoding the extra "121" into the compatible
string is not required.

> 
> > But it seems that
> > compatible string is being used to define both (as we see being debated in the other
> > thread on this series).
> > 
> >> In my understanding the Revs are different variants of the SGX core (errata
> >> fixes, instruction set, pipeline size etc.). And therefore the current driver code
> >> has to be configured by some macros to handle such cases.
> >> So the Rev should IMHO be part of the next line:
> >>> +          - const: img,powervr-sgx530
> >> +          - enum:
> >> +              - img,powervr-sgx530-121
> >> +              - img,powervr-sgx530-125
> >> We have a similar definition in the openpvrsgx code.
> >> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";
> >> (I don't mind about the powervr- prefix).
> >> This would allow a generic and universal sgx driver (loaded through just matching
> >> "img,sgx530") to handle the errata and revision specifics at runtime based on the
> >> compatible entry ("img,sgx530-121") and know about SoC integration ("ti,omap3-sgx530-121").

The "raw" sgx530 compatible does not seem helpful if the sgx530-121 or
sgx530-125 compatibles are also required to be present for the driver to
actually function. The revision specific compatibles I would not object
to, but everything in here has different revisions anyway - does the
same revision actually appear in multiple devices? If it doesn't then I
don't see any value in the suffixed compatibles either.

> >> And user-space can be made to load the right firmware variant based on "img,sgx530-121"
> >> I don't know if there is some register which allows to discover the revision long
> >> before the SGX subsystem is initialized and the firmware is up and running.
> >> What I know is that it is possible to read out the revision after starting the firmware
> >> but it may just echo the version number of the firmware binary provided from user-space.
> > 
> > We should be able to read out the revision (register EUR_CR_CORE_REVISION), the problem is
> > today the driver is built for a given revision at compile time.
> 
> Yes, that is something we had planned to get rid of for a long time by using different compatible
> strings and some variant specific struct like many others drivers are doing it.
> But it was a to big task so nobody did start with it.
> 
> > That is a software issue,
> > not something that we need to encode in DT. While the core ID (SGX5xx) can be also detected
> > (EUR_CR_CORE_ID), the location of that register changes, and so it does need encoded in
> > DT compatible.
> 
> Ok, I didn't know about such registers as there is not much public information available.
> Fair enough, there are some error reports about in different forums.
> 
> On the other hand we then must read out this register in more or less early initialization
> stages. Even if we know this information to be static and it could be as simple as a list
> of compatible strings in the driver.
> 
> > The string "ti,omap3430-gpu" tells us the revision if we cannot detect it (as in the current
> > driver), and the SoC integration is generic anyway (just a reg and interrupt).
> 
> It of course tells, but may need a translation table that needs to be maintained in a
> different format. Basically the same what the comments show in a non-machine readable
> format.
> 
> I just wonder why the specific version can or should not become simply part of the DTS
> and needs this indirection.
> 
> Basically it is a matter of openness for future (driver) development and why it needs
> careful decisions.
> 
> So in other words: I would prefer to see the comments about versions encoded in the device
> tree binary to make it machine readable.

It's already machine readable if it is invariant on an SoC given the
patch had SoC-specific compatibles.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/48108dd6/attachment.sig>

From hugo at hugovil.com  Wed Dec  6 08:03:00 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Wed,  6 Dec 2023 11:03:00 -0500
Subject: [PATCH 0/3] board: imx8mn-dimonoff-gateway-evk: add support for Dimonoff gateway EVK board
Message-ID: <20231206160303.33185-1-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Hello,
this patch series add support for the Dimonoff gateway EVK board.

Based on shawnguo/for-next branch.

Thank you.

Hugo Villeneuve (3):
  dt-bindings: vendor-prefixes: add dimonoff
  dt-bindings: arm: fsl: add Dimonoff gateway EVK board
  arm64: dts: freescale: introduce dimonoff-gateway-evk board

 .../devicetree/bindings/arm/fsl.yaml          |   1 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../freescale/imx8mn-dimonoff-gateway-evk.dts | 159 ++++++++++++++++++
 4 files changed, 163 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts


base-commit: 8c3c7094bf5b965a6dfc74864838fa4954dcf1c9
-- 
2.39.2



From hugo at hugovil.com  Wed Dec  6 08:03:02 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Wed,  6 Dec 2023 11:03:02 -0500
Subject: [PATCH 2/3] dt-bindings: arm: fsl: add Dimonoff gateway EVK board
In-Reply-To: <20231206160303.33185-1-hugo@hugovil.com>
References: <20231206160303.33185-1-hugo@hugovil.com>
Message-ID: <20231206160303.33185-3-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Add DT compatible string for Dimonoff gateway EVK board based on a
Variscite VAR-SOM-NANO with a NXP MX8MN nano CPU.

Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index cd87d1afe7b7..e445d65d6f17 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1025,6 +1025,7 @@ properties:
       - description: Variscite VAR-SOM-MX8MN based boards
         items:
           - enum:
+              - dimonoff,dimonoff-gateway-evk # i.MX8MN Dimonoff Gateway EVK Board
               - rve,rve-gateway # i.MX8MN RVE Gateway Board
               - variscite,var-som-mx8mn-symphony
           - const: variscite,var-som-mx8mn
-- 
2.39.2



From hugo at hugovil.com  Wed Dec  6 08:03:01 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Wed,  6 Dec 2023 11:03:01 -0500
Subject: [PATCH 1/3] dt-bindings: vendor-prefixes: add dimonoff
In-Reply-To: <20231206160303.33185-1-hugo@hugovil.com>
References: <20231206160303.33185-1-hugo@hugovil.com>
Message-ID: <20231206160303.33185-2-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Add vendor prefix for Dimonoff, which provides
IoT smart solutions and custom engineering services.

Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 71dcd6240a99..338ad15a7ab2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -352,6 +352,8 @@ patternProperties:
     description: Digi International Inc.
   "^digilent,.*":
     description: Diglent, Inc.
+  "^dimonoff,.*":
+    description: Dimonoff inc.
   "^diodes,.*":
     description: Diodes, Inc.
   "^dioo,.*":
-- 
2.39.2



From hugo at hugovil.com  Wed Dec  6 08:03:03 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Wed,  6 Dec 2023 11:03:03 -0500
Subject: [PATCH 3/3] arm64: dts: freescale: introduce dimonoff-gateway-evk board
In-Reply-To: <20231206160303.33185-1-hugo@hugovil.com>
References: <20231206160303.33185-1-hugo@hugovil.com>
Message-ID: <20231206160303.33185-4-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

The Dimonoff gateway EVK board is based on a Variscite
VAR-SOM-NANO, with a NXP MX8MN nano CPU and also based on a Symphony
mx8mn EVK.

Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
---
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../freescale/imx8mn-dimonoff-gateway-evk.dts | 159 ++++++++++++++++++
 2 files changed, 160 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index d22e4f4f886d..1f29215ea9bb 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -97,6 +97,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-bsh-smm-s2.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-bsh-smm-s2pro.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mn-dimonoff-gateway-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr3l-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts
new file mode 100644
index 000000000000..c4572be437bd
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 DimOnOff
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx8mn-var-som-symphony.dts"
+
+/ {
+	model = "DimOnOff Gateway EVK board";
+	compatible = "dimonoff,dimonoff-gateway-evk", "variscite,var-som-mx8mn", "fsl,imx8mn";
+
+	/*
+	 * U30 FPF2193 regulator.
+	 * Source = BASE_PER_3V3 = SOM_3V3 (COM pin 49).
+	 */
+	reg_disp_3v3: regulator-disp-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "Display 3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpio_keys>;
+
+		key-enter {
+			label = "enter";
+			gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_ENTER>;
+			wakeup-source;
+		};
+	};
+
+	/* Bourns PEC12R rotary encoder, 24 steps. */
+	rotary: rotary-encoder {
+		compatible = "rotary-encoder";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_rotary>;
+		gpios = <&gpio5 12 GPIO_ACTIVE_LOW>, /* A */
+			<&gpio5 13 GPIO_ACTIVE_LOW>; /* B */
+		linux,axis = <0>; /* REL_X */
+		rotary-encoder,encoding = "gray";
+		rotary-encoder,relative-axis;
+	};
+};
+
+/* Disable Asynchronous Sample Rate Converter (audio) */
+&easrc {
+	status = "disabled";
+};
+
+&ecspi1 {
+	/* Resistive touch controller */
+	/delete-node/ touchscreen at 0;
+};
+
+&gpu {
+	status = "disabled";
+};
+
+&i2c2 {
+	adc at 48 {
+		compatible = "ti,ads7924";
+		reg = <0x48>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_adc>;
+		vref-supply = <&reg_disp_3v3>;
+		reset-gpios = <&gpio5 5 GPIO_ACTIVE_LOW>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		channel at 0 {
+			reg = <0>;
+			label = "Pot0";
+		};
+		channel at 1 {
+			reg = <1>;
+			label = "Pot1";
+		};
+		channel at 2 {
+			reg = <2>;
+			label = "Pot2";
+		};
+		channel at 3 {
+			reg = <3>;
+			label = "Pot3";
+		};
+	};
+
+	rtc at 51 {
+		compatible = "nxp,pcf2129";
+		reg = <0x51>;
+		reset-source; /* For watchdog. */
+	};
+
+	rtc at 53 {
+		compatible = "nxp,pcf2131";
+		reg = <0x53>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_rtc>;
+		reset-source; /* For watchdog. */
+		interrupt-parent = <&gpio5>;
+		interrupts = <10 IRQ_TYPE_EDGE_FALLING>; /* J17.6 on EVK */
+	};
+};
+
+&i2c3 {
+	touchscreen at 38 {
+		status = "disabled";
+	};
+
+	codec at 1a {
+		status = "disabled";
+	};
+
+	/* DS1337 RTC module */
+	rtc at 68 {
+		status = "disabled";
+	};
+};
+
+&sai5 {
+	status = "disabled";
+};
+
+&iomuxc {
+	pinctrl_gpio_keys: gpiokeysgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8	0xc6
+		>;
+	};
+
+	pinctrl_rotary: rotarygrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_ECSPI2_MISO_GPIO5_IO12	0x00000156
+			MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13	0x00000156
+		>;
+	};
+
+	pinctrl_adc: adcgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5	0x00000156
+		>;
+	};
+
+	pinctrl_rtc: rtcgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_ECSPI2_SCLK_GPIO5_IO10	0x00000156
+			MX8MN_IOMUXC_ECSPI2_MOSI_GPIO5_IO11	0x00000156
+		>;
+	};
+};
-- 
2.39.2



From nm at ti.com  Wed Dec  6 08:03:42 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 6 Dec 2023 10:03:42 -0600
Subject: [PATCH 1/3] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Lower I2C1 frequency
In-Reply-To: <20231204222811.2344460-1-ggiordano@phytec.com>
References: <20231204222811.2344460-1-ggiordano@phytec.com>
Message-ID: <170187855182.4369.10040429085945945592.b4-ty@ti.com>

Hi Garrett Giordano,

On Mon, 04 Dec 2023 14:28:09 -0800, Garrett Giordano wrote:
> The gpio-expander on i2c-1 has a maximum frequency of 100kHz. Update our
> main_i2c1 frequency to allow the nxp,pcf8574 gpio-expander to function
> properly.
> 
> 

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/3] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Lower I2C1 frequency
      commit: 9c316d58c238e58d6346458462e8b0fd308e7332
[2/3] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Add HDMI support
      commit: bac441710306a84c52f0f9a561aa9839b91caa14
[3/3] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Remove HDMI Reset Line Name
      commit: fecdf6de7e47849504d0edaaff55fa0baadef420

For future reference: using a cover-letter (though not mandatory)
helps reviewers provide a ack/ other tag on cover letter to apply to
all patches and b4 can easily figure it out.

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Wed Dec  6 08:04:03 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 6 Dec 2023 10:04:03 -0600
Subject: [PATCH v3 0/3] arm64: dts: ti: add verdin am62 mallow board
In-Reply-To: <20231205184605.35225-1-francesco@dolcini.it>
References: <20231205184605.35225-1-francesco@dolcini.it>
Message-ID: <170187863264.4898.11481701414086150455.b4-ty@ti.com>

Hi Francesco Dolcini,

On Tue, 05 Dec 2023 19:46:02 +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> Add Toradex Verdin AM62 Mallow carrier board support. Mallow is a
> low-cost carrier board in the Verdin family with a small form factor and
> build for volume production making it ideal for industrial and embedded
> applications.
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/3] arm64: dts: ti: verdin-am62: improve spi1 chip-select pinctrl
      commit: fcb335934c5132f6f0646475ece5db729fcfbf84
[2/3] dt-bindings: arm: ti: add verdin am62 mallow board
      commit: f9b5aae471dca94de2ea525136a59927e9b1d7cf
[3/3] arm64: dts: ti: add verdin am62 mallow board
      commit: 7698622fbcf4fef2ec7e2fcbae35eb5e503dfddf

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From daniel at makrotopia.org  Wed Dec  6 08:08:39 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 16:08:39 +0000
Subject: [RFC PATCH v2 7/8] dt-bindings: net: mediatek,net: fix and
 complete mt7988-eth binding
In-Reply-To: <20231206133816.GA1914715-robh@kernel.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <567c6aaa64ecb4872056bc0105c70153fd9d9b50.1701826319.git.daniel@makrotopia.org>
 <20231206133816.GA1914715-robh@kernel.org>
Message-ID: <ZXCch6o2Wfp3fQQw@makrotopia.org>

On Wed, Dec 06, 2023 at 07:38:16AM -0600, Rob Herring wrote:
> On Wed, Dec 06, 2023 at 01:45:02AM +0000, Daniel Golle wrote:
> > Complete support for MT7988 which comes with 3 MACs, SRAM for DMA
> > descriptors and uses a dedicated PCS for the SerDes units.
> > 
> > Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
> > Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> > ---
> >  .../devicetree/bindings/net/mediatek,net.yaml | 148 +++++++++++++++++-
> >  1 file changed, 146 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> > index 030d106bc7d3f..ca0667c51c1c2 100644
> > --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
> > +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> > @@ -28,7 +28,10 @@ properties:
> >        - ralink,rt5350-eth
> >  
> >    reg:
> > -    maxItems: 1
> > +    minItems: 1
> > +    items:
> > +      - description: Base of registers used to program the ethernet controller
> > +      - description: SRAM region used for DMA descriptors
> 
> Is this a dedicated SRAM for this purpose, or a common one partitioned 
> up. mmio-sram and a phandle is how to do the latter.

The SRAM memory sits just next to the Ethernet and dedicated for this
purpose, at least in theory. I'm not aware of the internal details here.

> 
> >  
> >    clocks: true
> >    clock-names: true
> > @@ -115,6 +118,9 @@ allOf:
> >                - mediatek,mt7623-eth
> >      then:
> >        properties:
> > +        reg:
> > +          maxItems: 1
> > +
> >          interrupts:
> >            maxItems: 3
> >  
> > @@ -149,6 +155,9 @@ allOf:
> >                - mediatek,mt7621-eth
> >      then:
> >        properties:
> > +        reg:
> > +          maxItems: 1
> > +
> >          interrupts:
> >            maxItems: 1
> >  
> > @@ -174,6 +183,9 @@ allOf:
> >              const: mediatek,mt7622-eth
> >      then:
> >        properties:
> > +        reg:
> > +          maxItems: 1
> > +
> >          interrupts:
> >            maxItems: 3
> >  
> > @@ -215,6 +227,9 @@ allOf:
> >              const: mediatek,mt7629-eth
> >      then:
> >        properties:
> > +        reg:
> > +          maxItems: 1
> > +
> >          interrupts:
> >            maxItems: 3
> >  
> > @@ -257,6 +272,9 @@ allOf:
> >              const: mediatek,mt7981-eth
> >      then:
> >        properties:
> > +        reg:
> > +          maxItems: 1
> > +
> >          interrupts:
> >            minItems: 4
> >  
> > @@ -295,6 +313,9 @@ allOf:
> >              const: mediatek,mt7986-eth
> >      then:
> >        properties:
> > +        reg:
> > +          maxItems: 1
> > +
> >          interrupts:
> >            minItems: 4
> >  
> > @@ -333,8 +354,13 @@ allOf:
> >              const: mediatek,mt7988-eth
> >      then:
> >        properties:
> > +        reg:
> > +          maxItems: 2
> 
> Don't need maxItems here. That's already the max.

Ack.

> 
> > +          minItems: 2
> > +
> >          interrupts:
> >            minItems: 4
> > +          maxItems: 4
> >  
> >          clocks:
> >            minItems: 24
> > @@ -368,7 +394,7 @@ allOf:
> >              - const: top_netsys_warp_sel
> >  
> >  patternProperties:
> > -  "^mac@[0-1]$":
> > +  "^mac@[0-2]$":
> >      type: object
> >      unevaluatedProperties: false
> >      allOf:
> > @@ -382,6 +408,9 @@ patternProperties:
> >        reg:
> >          maxItems: 1
> >  
> > +      phys:
> > +        maxItems: 1
> > +
> >      required:
> >        - reg
> >        - compatible
> > @@ -559,3 +588,118 @@ examples:
> >          };
> >        };
> >      };
> > +
> > +  - |
> > +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +    #include <dt-bindings/interrupt-controller/irq.h>
> > +    #include <dt-bindings/clock/mediatek,mt7988-clk.h>
> 
> 
> Why is fixing the binding needing a new example? Is this example really 
> different enough to justify a whole other example?

Starting from MT7988 the PCS needs to be referenced as pcs-handle in the
MAC node, so that is a bit different. If you don't think that justifies
including the additional example I will drop that.

> 
> > +
> > +    soc {
> > +      #address-cells = <2>;
> > +      #size-cells = <2>;
> > +
> > +      ethernet at 15100000 {
> > +        compatible = "mediatek,mt7988-eth";
> > +        reg = <0 0x15100000 0 0x80000>, <0 0x15400000 0 0x380000>;
> > +        interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
> > +                     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
> > +                     <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
> > +                     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > +        clocks = <&ethsys CLK_ETHDMA_XGP1_EN>,
> > +                 <&ethsys CLK_ETHDMA_XGP2_EN>,
> > +                 <&ethsys CLK_ETHDMA_XGP3_EN>,
> > +                 <&ethsys CLK_ETHDMA_FE_EN>,
> > +                 <&ethsys CLK_ETHDMA_GP2_EN>,
> > +                 <&ethsys CLK_ETHDMA_GP1_EN>,
> > +                 <&ethsys CLK_ETHDMA_GP3_EN>,
> > +                 <&ethsys CLK_ETHDMA_ESW_EN>,
> > +                 <&ethsys CLK_ETHDMA_CRYPT0_EN>,
> > +                 <&ethwarp CLK_ETHWARP_WOCPU2_EN>,
> > +                 <&ethwarp CLK_ETHWARP_WOCPU1_EN>,
> > +                 <&ethwarp CLK_ETHWARP_WOCPU0_EN>,
> > +                 <&topckgen CLK_TOP_ETH_GMII_SEL>,
> > +                 <&topckgen CLK_TOP_ETH_REFCK_50M_SEL>,
> > +                 <&topckgen CLK_TOP_ETH_SYS_200M_SEL>,
> > +                 <&topckgen CLK_TOP_ETH_SYS_SEL>,
> > +                 <&topckgen CLK_TOP_ETH_XGMII_SEL>,
> > +                 <&topckgen CLK_TOP_ETH_MII_SEL>,
> > +                 <&topckgen CLK_TOP_NETSYS_SEL>,
> > +                 <&topckgen CLK_TOP_NETSYS_500M_SEL>,
> > +                 <&topckgen CLK_TOP_NETSYS_PAO_2X_SEL>,
> > +                 <&topckgen CLK_TOP_NETSYS_SYNC_250M_SEL>,
> > +                 <&topckgen CLK_TOP_NETSYS_PPEFB_250M_SEL>,
> > +                 <&topckgen CLK_TOP_NETSYS_WARP_SEL>;
> > +
> > +        clock-names = "xgp1", "xgp2", "xgp3", "fe", "gp2", "gp1",
> > +                      "gp3", "esw", "crypto",
> > +                      "ethwarp_wocpu2", "ethwarp_wocpu1",
> > +                      "ethwarp_wocpu0", "top_eth_gmii_sel",
> > +                      "top_eth_refck_50m_sel", "top_eth_sys_200m_sel",
> > +                      "top_eth_sys_sel", "top_eth_xgmii_sel",
> > +                      "top_eth_mii_sel", "top_netsys_sel",
> > +                      "top_netsys_500m_sel", "top_netsys_pao_2x_sel",
> > +                      "top_netsys_sync_250m_sel",
> > +                      "top_netsys_ppefb_250m_sel",
> > +                      "top_netsys_warp_sel";
> > +        assigned-clocks = <&topckgen CLK_TOP_NETSYS_2X_SEL>,
> > +                          <&topckgen CLK_TOP_NETSYS_GSW_SEL>,
> > +                          <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>,
> > +                          <&topckgen CLK_TOP_USXGMII_SBUS_1_SEL>,
> > +                          <&topckgen CLK_TOP_SGM_0_SEL>,
> > +                          <&topckgen CLK_TOP_SGM_1_SEL>;
> > +        assigned-clock-parents = <&apmixedsys CLK_APMIXED_NET2PLL>,
> > +                                 <&topckgen CLK_TOP_NET1PLL_D4>,
> > +                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
> > +                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
> > +                                 <&apmixedsys CLK_APMIXED_SGMPLL>,
> > +                                 <&apmixedsys CLK_APMIXED_SGMPLL>;
> > +        mediatek,ethsys = <&ethsys>;
> > +        mediatek,infracfg = <&topmisc>;
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +
> > +        mac at 0 {
> > +          compatible = "mediatek,eth-mac";
> > +          reg = <0>;
> > +          phy-mode = "internal"; /* CPU port of built-in 1GE switch */
> > +
> > +          fixed-link {
> > +            speed = <10000>;
> > +            full-duplex;
> > +            pause;
> > +          };
> > +        };
> > +
> > +        mac at 1 {
> > +          compatible = "mediatek,eth-mac";
> > +          reg = <1>;
> > +          phy-handle = <&int_2p5g_phy>;
> > +        };
> > +
> > +        mac at 2 {
> > +          compatible = "mediatek,eth-mac";
> > +          reg = <2>;
> > +          pcs-handle = <&usxgmiisys0>;
> > +          phy-handle = <&phy0>;
> > +        };
> > +
> > +        mdio_bus: mdio-bus {
> > +          #address-cells = <1>;
> > +          #size-cells = <0>;
> > +
> > +          /* external PHY */
> > +          phy0: ethernet-phy at 0 {
> > +            reg = <0>;
> > +            compatible = "ethernet-phy-ieee802.3-c45";
> > +          };
> > +
> > +          /* internal 2.5G PHY */
> > +          int_2p5g_phy: ethernet-phy at 15 {
> > +            reg = <15>;
> > +            compatible = "ethernet-phy-ieee802.3-c45";
> > +            phy-mode = "internal";
> > +          };
> > +        };
> > +      };
> > +    };
> > -- 
> > 2.43.0


From afd at ti.com  Wed Dec  6 08:15:26 2023
From: afd at ti.com (Andrew Davis)
Date: Wed, 6 Dec 2023 10:15:26 -0600
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231206-wolverine-paprika-0674ca01e1f2@spud>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <CFF198DA-5C42-425E-86F4-759629489ECB@goldelico.com>
 <cb590a13-e0ff-49d9-8583-be613ad50dc5@ti.com>
 <FE0DBA5E-95A5-4C27-9F69-D1D8BDF56EC3@goldelico.com>
 <20231206-wolverine-paprika-0674ca01e1f2@spud>
Message-ID: <8328bec9-a963-4f8a-ae03-a531749a30db@ti.com>

On 12/6/23 10:02 AM, Conor Dooley wrote:
> On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote:
>>> Am 05.12.2023 um 18:33 schrieb Andrew Davis <afd at ti.com>:
>>>
>>> On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
>>>>> +          - enum:
>>>>> +              - ti,omap3430-gpu # Rev 121
>>>>> +              - ti,omap3630-gpu # Rev 125
>>>> Is the "Rev 121" and "Rev 125" a property of the SoC integration (clock/reset/power
>>>> hookup etc.) or of the integrated SGX core?
>>>
>>> The Rev is a property of the SGX core, not the SoC integration.
>>
>> Then, it should belong there and not be a comment of the ti,omap*-gpu record.
>> In this way it does not seem to be a proper hardware description.
>>
>> BTW: there are examples where the revision is part of the compatible string, even
>> if the (Linux) driver makes no use of it:
>>
>> drivers/net/ethernet/xilinx/xilinx_emaclite.c
> 
> AFAICT these Xilinx devices that put the revisions in the compatible are
> a different case - they're "soft" IP intended for use in the fabric of
> an FPGA, and assigning a device specific compatible there does not make
> sense.
> 
> In this case it appears that the revision is completely known once you
> see "ti,omap3630-gpu", so encoding the extra "121" into the compatible
> string is not required.
> 
>>
>>> But it seems that
>>> compatible string is being used to define both (as we see being debated in the other
>>> thread on this series).
>>>
>>>> In my understanding the Revs are different variants of the SGX core (errata
>>>> fixes, instruction set, pipeline size etc.). And therefore the current driver code
>>>> has to be configured by some macros to handle such cases.
>>>> So the Rev should IMHO be part of the next line:
>>>>> +          - const: img,powervr-sgx530
>>>> +          - enum:
>>>> +              - img,powervr-sgx530-121
>>>> +              - img,powervr-sgx530-125
>>>> We have a similar definition in the openpvrsgx code.
>>>> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";
>>>> (I don't mind about the powervr- prefix).
>>>> This would allow a generic and universal sgx driver (loaded through just matching
>>>> "img,sgx530") to handle the errata and revision specifics at runtime based on the
>>>> compatible entry ("img,sgx530-121") and know about SoC integration ("ti,omap3-sgx530-121").
> 
> The "raw" sgx530 compatible does not seem helpful if the sgx530-121 or
> sgx530-125 compatibles are also required to be present for the driver to
> actually function. The revision specific compatibles I would not object
> to, but everything in here has different revisions anyway - does the
> same revision actually appear in multiple devices? If it doesn't then I
> don't see any value in the suffixed compatibles either.
> 

Everything here has different revisions because any device that uses
the same revision can also use the same base compatible string. For
instance AM335x SoCs use the SGX530 revision 125, same as OMAP3630,
so I simply reuse that compatible in their DT as you can see in
patch [5/10]. I didn't see the need for a new compatible string
for identical (i.e. "compatible") IP and integration.

The first device to use that IP/revision combo gets the named
compatible, all others re-use the same compatible where possible.

Andrew

>>>> And user-space can be made to load the right firmware variant based on "img,sgx530-121"
>>>> I don't know if there is some register which allows to discover the revision long
>>>> before the SGX subsystem is initialized and the firmware is up and running.
>>>> What I know is that it is possible to read out the revision after starting the firmware
>>>> but it may just echo the version number of the firmware binary provided from user-space.
>>>
>>> We should be able to read out the revision (register EUR_CR_CORE_REVISION), the problem is
>>> today the driver is built for a given revision at compile time.
>>
>> Yes, that is something we had planned to get rid of for a long time by using different compatible
>> strings and some variant specific struct like many others drivers are doing it.
>> But it was a to big task so nobody did start with it.
>>
>>> That is a software issue,
>>> not something that we need to encode in DT. While the core ID (SGX5xx) can be also detected
>>> (EUR_CR_CORE_ID), the location of that register changes, and so it does need encoded in
>>> DT compatible.
>>
>> Ok, I didn't know about such registers as there is not much public information available.
>> Fair enough, there are some error reports about in different forums.
>>
>> On the other hand we then must read out this register in more or less early initialization
>> stages. Even if we know this information to be static and it could be as simple as a list
>> of compatible strings in the driver.
>>
>>> The string "ti,omap3430-gpu" tells us the revision if we cannot detect it (as in the current
>>> driver), and the SoC integration is generic anyway (just a reg and interrupt).
>>
>> It of course tells, but may need a translation table that needs to be maintained in a
>> different format. Basically the same what the comments show in a non-machine readable
>> format.
>>
>> I just wonder why the specific version can or should not become simply part of the DTS
>> and needs this indirection.
>>
>> Basically it is a matter of openness for future (driver) development and why it needs
>> careful decisions.
>>
>> So in other words: I would prefer to see the comments about versions encoded in the device
>> tree binary to make it machine readable.
> 
> It's already machine readable if it is invariant on an SoC given the
> patch had SoC-specific compatibles.
> 


From thierry.reding at gmail.com  Wed Dec  6 08:16:26 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Wed, 6 Dec 2023 17:16:26 +0100
Subject: [PATCH 2/6] dt-bindings: pwm: samsung: add specific compatible
 for Tesla FSD
In-Reply-To: <20231205092229.19135-3-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
 <20231205092229.19135-3-krzysztof.kozlowski@linaro.org>
Message-ID: <ZXCeWmEO3PJiK0m5@orome.fritz.box>

On Tue, Dec 05, 2023 at 10:22:25AM +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs.  Historically we
> kept the old (block's) compatible only.  This works fine and there is no
> bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add Tesla FSD compatible specific to be used with an existing fallback.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  Documentation/devicetree/bindings/pwm/pwm-samsung.yaml | 1 +
>  1 file changed, 1 insertion(+)

You point to the guidelines that say we should have specific compatible
strings, but then the string that you add seems very generic. Now, I'm
obviously not an expert on Tesla hardware, but just FSD seems to be
quite generic according to the internet. It seems like the chip derived
from Samsung used to be known as AP3/HW3, but there's now also AP4/HW4,
so I wonder if those differ in some way and if these shouldn't include
some sort of version/generation number.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/dbda0f11/attachment.sig>

From florian.fainelli at broadcom.com  Wed Dec  6 08:18:02 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Wed, 6 Dec 2023 08:18:02 -0800
Subject: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
In-Reply-To: <e63906cf-9f76-4fed-91b0-1a9168b179bd@linaro.org>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-4-mmayer@broadcom.com>
 <e63906cf-9f76-4fed-91b0-1a9168b179bd@linaro.org>
Message-ID: <12f3c515-71cf-46a5-ad92-15bf6c4c2f2c@broadcom.com>



On 12/6/2023 3:10 AM, Krzysztof Kozlowski wrote:
> On 05/12/2023 19:47, Markus Mayer wrote:
>> Add support for version 4 of the DPFE API. This new version is largely
>> identical to version 3. The main difference is that all commands now
>> take the MHS version number as the first argument. Any other arguments
>> have been pushed down by one (i.e. what used to be arg0 in v3 is arg1 in
>> v4).
>>
>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
>> ---
> 
> ...
> 
>> +
>>   static const char *get_error_text(unsigned int i)
>>   {
>>   	static const char * const error_text[] = {
>> @@ -929,8 +954,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
>>   	{ .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
>>   	{ .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
>>   	{ .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
>> +	{ .compatible = "brcm,dpfe-cpu-v4", .data = &dpfe_api_v4 },
>>   
> 
> No, use SoC specific compatible.

This is not that simple because for a given SoC, the API implemented by 
the firmware can change, in fact it has changed over the lifetime of a 
given SoC as firmware updates get rolled out. Arguably the dialect 
spoken by the firmware should not have changed and we told the firmware 
team about that but it basically went nowhere and here we are.

The Device Tree gets populated by the boot loader which figures out 
which API is spoken and places one of those compatible strings 
accordingly for the kernel to avoid having to do any sort of run-time 
detection which is slow and completely unnecessary when we can simply 
tell it ahead of time what to use.
-- 
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/3e75c10e/attachment-0001.p7s>

From detheridge at ti.com  Wed Dec  6 08:18:18 2023
From: detheridge at ti.com (Etheridge, Darren)
Date: Wed, 6 Dec 2023 10:18:18 -0600
Subject: [PATCH v2 0/2] Enable PowerVR driver for TI AM62x
In-Reply-To: <cover.1701773390.git.donald.robson@imgtec.com>
References: <cover.1701773390.git.donald.robson@imgtec.com>
Message-ID: <b3064dfc-5420-4868-89f6-bb962cf9e7c9@ti.com>

On 12/5/2023 5:39 AM, Donald Robson wrote:
> These patches enable the new open source PowerVR driver for TI AM62x SoCs,
> currently the only one supported.
> 
> Changes since v1:
> - Added patch 1 for arm64 defconfig (requested by Nishanth Menon)
> 
> Donald Robson (1):
>    arm64: defconfig: enable DRM_POWERVR
> 
> Sarah Walker (1):
>    arm64: dts: ti: k3-am62-main: Add GPU device node
> 
For the series:

Acked-by: Darren Etheridge <detheridge at ti.com>


Thanks,
Darren


From florian.fainelli at broadcom.com  Wed Dec  6 08:19:46 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Wed, 6 Dec 2023 08:19:46 -0800
Subject: [PATCH 2/4] memory: brcmstb_dpfe: introduce version-specific
 compatible strings
In-Reply-To: <7844ca22-df53-458d-9e3b-7b0758a80455@linaro.org>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-3-mmayer@broadcom.com>
 <7844ca22-df53-458d-9e3b-7b0758a80455@linaro.org>
Message-ID: <cb1d5118-b4f6-46b3-814b-2edf16372d01@broadcom.com>



On 12/6/2023 3:09 AM, Krzysztof Kozlowski wrote:
> On 05/12/2023 19:47, Markus Mayer wrote:
>> Introduce compatible strings brcm,dpfe-cpu-v1 through brcm,dpfe-cpu-v3
>> to the Broadcom DPFE driver.
> 
> No, why?
> 
>>
>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
>> ---
>>   drivers/memory/brcmstb_dpfe.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
>> index a7ab3d377206..66876b409e59 100644
>> --- a/drivers/memory/brcmstb_dpfe.c
>> +++ b/drivers/memory/brcmstb_dpfe.c
>> @@ -924,6 +924,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
>>   	{ .compatible = "brcm,bcm7271-dpfe-cpu", .data = &dpfe_api_old_v2 },
>>   	{ .compatible = "brcm,bcm7278-dpfe-cpu", .data = &dpfe_api_old_v2 },
>>   	{ .compatible = "brcm,bcm7211-dpfe-cpu", .data = &dpfe_api_new_v2 },
>> +
>> +	/* Match specific DCPU versions */
>> +	{ .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
>> +	{ .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
>> +	{ .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
> 
> Pointless change.

Is it possible to ask you as a maintainer to stop having those knee jerk 
reactions and try to understand things a bit better, or simply request a 
better explanation from the submitter?
-- 
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/af6acb93/attachment.p7s>

From catalin.marinas at arm.com  Wed Dec  6 08:23:25 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 6 Dec 2023 16:23:25 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231206153809.GS2692119@nvidia.com>
References: <ZW8MP2tDt4_9ROBz@arm.com>
 <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
 <ZXCJ3pVbKuHJ3LTz@arm.com>
 <20231206150556.GQ2692119@nvidia.com>
 <ZXCQrTbf6q0BIhSw@lpieralisi>
 <20231206153809.GS2692119@nvidia.com>
Message-ID: <ZXCf_e-ACqrj6VrV@arm.com>

On Wed, Dec 06, 2023 at 11:38:09AM -0400, Jason Gunthorpe wrote:
> On Wed, Dec 06, 2023 at 04:18:05PM +0100, Lorenzo Pieralisi wrote:
> > On Wed, Dec 06, 2023 at 11:05:56AM -0400, Jason Gunthorpe wrote:
> > > On Wed, Dec 06, 2023 at 02:49:02PM +0000, Catalin Marinas wrote:
> > > > BTW, on those Mellanox devices that require different attributes within
> > > > a BAR, do they have a problem with speculative reads causing
> > > > side-effects? 
> > > 
> > > Yes. We definitely have had that problem in the past on older
> > > devices. VFIO must map the BAR using pgprot_device/noncached() into
> > > the VMM, no other choice is functionally OK.
> > 
> > Were those BARs tagged as prefetchable or non-prefetchable ? I assume the
> > latter but please let me know if I am guessing wrong.
> 
> I don't know it was quite old HW. Probably.
> 
> Just because a BAR is not marked as prefetchable doesn't mean that the
> device can't use NORMAL_NC on subsets of it.

What about the other way around - would we have a prefetchable BAR that
has portions which are unprefetchable?

-- 
Catalin


From florian.fainelli at broadcom.com  Wed Dec  6 08:24:50 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Wed, 6 Dec 2023 08:24:50 -0800
Subject: [PATCH 4/4] memory: brcmstb_dpfe: introduce best-effort API
 detection
In-Reply-To: <8e86fb4c-9526-4d64-9352-f9c8e5cae75f@linaro.org>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-5-mmayer@broadcom.com>
 <8e86fb4c-9526-4d64-9352-f9c8e5cae75f@linaro.org>
Message-ID: <60f1db84-893b-4ce0-bf3b-592452e87a91@broadcom.com>



On 12/6/2023 3:13 AM, Krzysztof Kozlowski wrote:
> On 05/12/2023 19:47, Markus Mayer wrote:
>> Add a best-effort probe function that tries all known DPFE versions to
>> see if one might actually work. This helps in cases where device tree
>> doesn't provide the proper version information for whatever reason. In
> 
> So for incomplete DTS you now add elaborate, own, custom matching
> function. That's not how the code should work.

I suppose that we could drop that change and simply rely upon the Device 
Tree containing an adequate compatible string. This change was added as 
a transitional step for ourselves mostly. I agree this may not entirely 
belong upstream.
-- 
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/b83d6a84/attachment-0001.p7s>

From sudeep.holla at arm.com  Wed Dec  6 08:23:37 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 6 Dec 2023 16:23:37 +0000
Subject: [GIT PULL] firmware: arm_ffa: Fixes for v6.7
In-Reply-To: <20231116191603.929767-1-sudeep.holla@arm.com>
References: <20231116191603.929767-1-sudeep.holla@arm.com>
Message-ID: <20231206162337.emy3kirnsmbgpvye@bogus>

On Thu, Nov 16, 2023 at 07:16:03PM +0000, Sudeep Holla wrote:
> Hi ARM SoC Team,
> 
> Please pull !

Gentle ping! I see you are pulling the fixes now. You may already have
this in todo list, but since it has been close to 3 weeks and during the
LPC week, I thought of replying so that it doesn't get slipped.

-- 
Regards,
Sudeep


From catalin.marinas at arm.com  Wed Dec  6 08:31:48 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 6 Dec 2023 16:31:48 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231206151603.GR2692119@nvidia.com>
References: <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <86bkb4bn2v.wl-maz@kernel.org>
 <ZW9ezSGSDIvv5MsQ@arm.com>
 <86a5qobkt8.wl-maz@kernel.org>
 <ZW9uqu7yOtyZfmvC@arm.com>
 <868r67blwo.wl-maz@kernel.org>
 <ZXBlmt88dKmZLCU9@arm.com>
 <20231206151603.GR2692119@nvidia.com>
Message-ID: <ZXCh9N2xp0efHcpE@arm.com>

On Wed, Dec 06, 2023 at 11:16:03AM -0400, Jason Gunthorpe wrote:
> On Wed, Dec 06, 2023 at 12:14:18PM +0000, Catalin Marinas wrote:
> > We could do with a pgprot_maybewritecombine() or
> > pgprot_writecombinenospec() (similar to Jason's idea but without
> > changing the semantics of pgprot_device()). For the user mapping on
> > arm64 this would be Device (even _GRE) since it can't disable
> > speculation but stage 2 would leave the decision to the guest since the
> > speculative loads aren't much different from committed loads done
> > wrongly.
> 
> This would be fine, as would a VMA flag. Please pick one :)
> 
> I think a VMA flag is simpler than messing with pgprot.

I guess one could write a patch and see how it goes ;).

> > If we want the VMM to drive this entirely, we could add a new mmap()
> > flag like MAP_WRITECOMBINE or PROT_WRITECOMBINE. They do feel a bit
> 
> As in the other thread, we cannot unconditionally map NORMAL_NC into
> the VMM.

I'm not suggesting this but rather the VMM map portions of the BAR with
either Device or Normal-NC, concatenate them (MAP_FIXED) and pass this
range as a memory slot (or multiple if a slot doesn't allow multiple
vmas).

> > The latter has some benefits for DPDK but it's a lot more involved
> > with
> 
> DPDK WC support will be solved with some VFIO-only change if anyone
> ever cares to make it, if that is what you mean.

Yeah. Some arguments I've heard in private and public discussions is
that the KVM device pass-through shouldn't be different from the DPDK
case. So fixing that would cover KVM as well, though we'd need
additional logic in the VMM. BenH had a short talk at Plumbers around
this - https://youtu.be/QLvN3KXCn0k?t=7010. There was some statement in
there that for x86, the guests are allowed to do WC without other KVM
restrictions (not sure whether that's the case, not familiar with it).

> > having to add device-specific knowledge into the VMM. The VMM would also
> > have to present the whole BAR contiguously to the guest even if there
> > are different mapping attributes within the range. So a lot of MAP_FIXED
> > uses. I'd rather leaving this decision with the guest than the VMM, it
> > looks like more hassle to create those mappings. The VMM or the VFIO
> > could only state write-combine and speculation allowed.
> 
> We talked about this already, the guest must decide, the VMM doesn't
> have the information to pre-predict which pages the guest will want to
> use WC on.

Are the Device/Normal offsets within a BAR fixed, documented in e.g. the
spec or this is something configurable via some MMIO that the guest
does.

-- 
Catalin


From florian.fainelli at broadcom.com  Wed Dec  6 08:32:27 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Wed, 6 Dec 2023 08:32:27 -0800
Subject: [PATCH 1/4] dt-bindings: memory: additional compatible strings
 for Broadcom DPFE
In-Reply-To: <f17dcd86-7f87-4433-a106-eb7bfdfb05ab@linaro.org>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-2-mmayer@broadcom.com>
 <f17dcd86-7f87-4433-a106-eb7bfdfb05ab@linaro.org>
Message-ID: <42677f2d-190c-4043-a61d-8bfba581a764@broadcom.com>



On 12/6/2023 3:09 AM, Krzysztof Kozlowski wrote:
> On 05/12/2023 19:47, Markus Mayer wrote:
>> Add versioned compatible strings for Broadcom DPFE. These take the form
>> brcm,dpfe-cpu-v<N> where <N> is a number from 1 to 4.
>>
>> These API version related compatible strings are more specific than the
>> catch-all "brcm,dpfe-cpu" and more generic than chip-specific compatible
>> strings.
> 
> None of this explains: Why? I don't see any point in this and commit
> does not explain.
> 
>>
>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
>> ---
>>   .../bindings/memory-controllers/brcm,dpfe-cpu.yaml        | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>> index 08cbdcddfead..6dffa7b62baf 100644
>> --- a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>> +++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>> @@ -16,6 +16,11 @@ properties:
>>         - enum:
>>             - brcm,bcm7271-dpfe-cpu
>>             - brcm,bcm7268-dpfe-cpu
>> +      - enum:
>> +          - brcm,dpfe-cpu-v1
>> +          - brcm,dpfe-cpu-v2
>> +          - brcm,dpfe-cpu-v3
>> +          - brcm,dpfe-cpu-v4
> 
> No, that's just wrong. So you want to say bcm7271 is brcm,dpfe-cpu-v4?

No as the example shows it "speaks" API v1.

I would be inclined to completely remove the chip specific compatible 
strings from the binding because they are not sufficient or descriptive 
enough to determine which API version is being spoken, since the 
firmware is unfortunately allowed to change major APIs (and the 
messaging format, because why not?) at a moments notice.
-- 
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/8119de6f/attachment.p7s>

From Frank.li at nxp.com  Wed Dec  6 08:33:44 2023
From: Frank.li at nxp.com (Frank Li)
Date: Wed, 6 Dec 2023 11:33:44 -0500
Subject: [PATCH v2 2/2] arm64: dts: freescale: imx93: add i3c1 and i3c2
In-Reply-To: <20231206093106.GE270430@dragon>
References: <20231017194657.3199749-1-Frank.Li@nxp.com>
 <20231017194657.3199749-2-Frank.Li@nxp.com>
 <ZUz/8fBWtnwdSW9w@lizhi-Precision-Tower-5810>
 <20231127022140.GJ87953@dragon>
 <20231127-cherisher-falsify-8193656e8872@wendy>
 <ZXAKp1WS97cAI5X2@lizhi-Precision-Tower-5810>
 <20231206093106.GE270430@dragon>
Message-ID: <ZXCiaKfMYYShoiXK@lizhi-Precision-Tower-5810>

On Wed, Dec 06, 2023 at 05:31:06PM +0800, Shawn Guo wrote:
> On Wed, Dec 06, 2023 at 12:46:15AM -0500, Frank Li wrote:
> > On Mon, Nov 27, 2023 at 09:35:39AM +0000, Conor Dooley wrote:
> > > On Mon, Nov 27, 2023 at 10:21:40AM +0800, Shawn Guo wrote:
> > > > On Thu, Nov 09, 2023 at 10:51:13AM -0500, Frank Li wrote:
> > > > > On Tue, Oct 17, 2023 at 03:46:57PM -0400, Frank Li wrote:
> > > > > > Add I3C1 and I3C2.
> > > > > > 
> > > > > > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > > > > > ---
> > > > > 
> > > > > @Guo Shawn:
> > > > > 
> > > > > Driver part already merged. 
> > > > > 
> > > > > Please pick up dts part
> > > > 
> > > > Rob had a comment [1] about SoC specific compatible.  That's not what we
> > > > want?
> > > > 
> > > > Shawn
> > > > 
> > > > [1] https://lkml.iu.edu/hypermail/linux/kernel/2310.2/03035.html
> > > 
> > > Yeah, Rob's request here looks valid to me. Should just be a bindings
> > > change Frank & fall back to the "silvaco,i3c-master-v1" compatible.
> > > 
> > > Cheers,
> > > Conor.
> > 
> > @shawn:
> > 	rob agree on "silvaco,i3c-master-v1" compatible.
> 
> Hmm, not sure I have seen that.  Here is what I saw from Rob:
> 
> "
> The real problem here is not whether we have "v1" or not, but you need
> an SoC specific compatible. Unless there's a public spec where we can
> know exactly how many resets, clocks, interrupts, etc.
> "

@Rob:
	Previous existed binding doc is "silvaco,i3c-master-v1". So far
this IP in our difference SOC have the same resets and clocks, and only one
interrrupts.
	current existed i3c controller compatible string is

	snps,dw-i3c-master-1.00a
	cdns,i3c-master
	mipi-i3c-hci

	mipi-i3c-hci is standard. "snps", "cdns" are similar as prefix
"silivaco".
	I think the same IP vendor and same IP version should have same
resets, clocks, and interrupts. So far still not met exception yet.

Frank


> 
> Shawn


From helgaas at kernel.org  Wed Dec  6 08:36:56 2023
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 6 Dec 2023 10:36:56 -0600
Subject: [PATCH 4/9] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231206155903.566194-5-Frank.Li@nxp.com>
Message-ID: <20231206163656.GA717052@bhelgaas>

In subject, maybe you mean "Use 'linux,pci-domain' as slot ID"?
"Using" is the wrong verb form here.

On Wed, Dec 06, 2023 at 10:58:58AM -0500, Frank Li wrote:
> Avoid use get slot id by compared with register physical address. If there
> are more than 2 slots, compared logic will become complex.

But this doesn't say anything about "linux,pci-domain", and I don't
see anything about a register physical address in the patch.

Maybe this commit log was meant for a different patch?  I'm confused.

> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 62d77fabd82a..239ef439ba70 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -33,6 +33,7 @@
>  #include <linux/pm_domain.h>
>  #include <linux/pm_runtime.h>
>  
> +#include "../../pci.h"
>  #include "pcie-designware.h"
>  
>  #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
> @@ -1333,6 +1334,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  					     "Failed to get PCIEPHY reset control\n");
>  	}
>  
> +	/* Using linux,pci-domain as PCI slot id */
> +	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
> +	if (imx6_pcie->controller_id)
> +		imx6_pcie->controller_id = 0;

I don't understand what this is doing.  It looks the same as just:

  imx6_pcie->controller_id = 0;

Maybe this is a typo?  As written, it doesn't look like there's any
point in calling of_get_pci_domain_nr().

>  	switch (imx6_pcie->drvdata->variant) {
>  	case IMX7D:
>  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> -- 
> 2.34.1
> 


From arnd at kernel.org  Wed Dec  6 08:40:06 2023
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 06 Dec 2023 17:40:06 +0100
Subject: [GIT PULL] firmware: arm_ffa: Fixes for v6.7
In-Reply-To: <20231206162337.emy3kirnsmbgpvye@bogus>
References: <20231116191603.929767-1-sudeep.holla@arm.com>
 <20231206162337.emy3kirnsmbgpvye@bogus>
Message-ID: <7c9b9b51-9ce6-4214-809c-81b39cf4c555@app.fastmail.com>

On Wed, Dec 6, 2023, at 17:23, Sudeep Holla wrote:
> On Thu, Nov 16, 2023 at 07:16:03PM +0000, Sudeep Holla wrote:
>> Hi ARM SoC Team,
>> 
>> Please pull !
>
> Gentle ping! I see you are pulling the fixes now. You may already have
> this in todo list, but since it has been close to 3 weeks and during the
> LPC week, I thought of replying so that it doesn't get slipped.

Pulled now, sorry it took me this long.

This one was indeed one of two pull requests I had missed while
going through the backlog but I would have noticed it today.

    Arnd


From jgg at nvidia.com  Wed Dec  6 08:48:02 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 6 Dec 2023 12:48:02 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZXCf_e-ACqrj6VrV@arm.com>
References: <20231205130517.GD2692119@nvidia.com>
 <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
 <ZXCJ3pVbKuHJ3LTz@arm.com>
 <20231206150556.GQ2692119@nvidia.com>
 <ZXCQrTbf6q0BIhSw@lpieralisi>
 <20231206153809.GS2692119@nvidia.com>
 <ZXCf_e-ACqrj6VrV@arm.com>
Message-ID: <20231206164802.GT2692119@nvidia.com>

On Wed, Dec 06, 2023 at 04:23:25PM +0000, Catalin Marinas wrote:
> On Wed, Dec 06, 2023 at 11:38:09AM -0400, Jason Gunthorpe wrote:
> > On Wed, Dec 06, 2023 at 04:18:05PM +0100, Lorenzo Pieralisi wrote:
> > > On Wed, Dec 06, 2023 at 11:05:56AM -0400, Jason Gunthorpe wrote:
> > > > On Wed, Dec 06, 2023 at 02:49:02PM +0000, Catalin Marinas wrote:
> > > > > BTW, on those Mellanox devices that require different attributes within
> > > > > a BAR, do they have a problem with speculative reads causing
> > > > > side-effects? 
> > > > 
> > > > Yes. We definitely have had that problem in the past on older
> > > > devices. VFIO must map the BAR using pgprot_device/noncached() into
> > > > the VMM, no other choice is functionally OK.
> > > 
> > > Were those BARs tagged as prefetchable or non-prefetchable ? I assume the
> > > latter but please let me know if I am guessing wrong.
> > 
> > I don't know it was quite old HW. Probably.
> > 
> > Just because a BAR is not marked as prefetchable doesn't mean that the
> > device can't use NORMAL_NC on subsets of it.
> 
> What about the other way around - would we have a prefetchable BAR that
> has portions which are unprefetchable?

I would say possibly.

Prefetch is a dead concept in PCIe, it was obsoleted in PCI-X about 20
years ago. No PCIe system has ever done prefetch.

There is a strong incentive to mark BAR's as prefetchable because it
allows 64 bit addressing in configurations with bridges.

So.. I would expect people have done interesting things here.

Jason


From Frank.li at nxp.com  Wed Dec  6 08:50:16 2023
From: Frank.li at nxp.com (Frank Li)
Date: Wed, 6 Dec 2023 11:50:16 -0500
Subject: [PATCH 4/9] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231206163656.GA717052@bhelgaas>
References: <20231206155903.566194-5-Frank.Li@nxp.com>
 <20231206163656.GA717052@bhelgaas>
Message-ID: <ZXCmSOwTWR6AVpGB@lizhi-Precision-Tower-5810>

On Wed, Dec 06, 2023 at 10:36:56AM -0600, Bjorn Helgaas wrote:
> In subject, maybe you mean "Use 'linux,pci-domain' as slot ID"?
> "Using" is the wrong verb form here.
> 
> On Wed, Dec 06, 2023 at 10:58:58AM -0500, Frank Li wrote:
> > Avoid use get slot id by compared with register physical address. If there
> > are more than 2 slots, compared logic will become complex.
> 
> But this doesn't say anything about "linux,pci-domain", and I don't
> see anything about a register physical address in the patch.
> 
> Maybe this commit log was meant for a different patch?  I'm confused.
> 
> > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > ---
> >  drivers/pci/controller/dwc/pci-imx6.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> > index 62d77fabd82a..239ef439ba70 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -33,6 +33,7 @@
> >  #include <linux/pm_domain.h>
> >  #include <linux/pm_runtime.h>
> >  
> > +#include "../../pci.h"
> >  #include "pcie-designware.h"
> >  
> >  #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
> > @@ -1333,6 +1334,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> >  					     "Failed to get PCIEPHY reset control\n");
> >  	}
> >  
> > +	/* Using linux,pci-domain as PCI slot id */
> > +	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
> > +	if (imx6_pcie->controller_id)
> > +		imx6_pcie->controller_id = 0;
> 
> I don't understand what this is doing.  It looks the same as just:

Good capture. It should be 
if (imx6_pcie->controller_id < 0)
	imx6_pcie->controller_id = 0;

for only one PCI controller case. I just tested first one slot before send
patch, so not met problem.

Previously, we use below logic
	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
		imx6_pcie->controller_id = 1;

It is not good to depend on register's base address. If there are 3
controllers, check logic will becomoe ugly.

Frank
> 
>   imx6_pcie->controller_id = 0;
> 
> Maybe this is a typo?  As written, it doesn't look like there's any
> point in calling of_get_pci_domain_nr().
> 
> >  	switch (imx6_pcie->drvdata->variant) {
> >  	case IMX7D:
> >  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> > -- 
> > 2.34.1
> > 


From p.zabel at pengutronix.de  Wed Dec  6 08:52:23 2023
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 06 Dec 2023 17:52:23 +0100
Subject: [PATCH 3/9] PCI: imx6: Simplify reset handling by using by
 using *_FLAG_HAS_*_RESET
In-Reply-To: <20231206155903.566194-4-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
	 <20231206155903.566194-4-Frank.Li@nxp.com>
Message-ID: <e314466b31dd8e88212ae5d7ac2fecf26b851829.camel@pengutronix.de>

Hi Frank,

On Mi, 2023-12-06 at 10:58 -0500, Frank Li wrote:
> Refactors the reset handling logic in the imx6 PCI driver by adding
> IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.
> 
> The drvdata::flags and a bitmask ensures a cleaner and more scalable
> switch-case structure for handling reset.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 115 +++++++++++---------------
>  1 file changed, 47 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index bcf52aa86462..62d77fabd82a 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
[...]
> @@ -696,18 +698,13 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
>  
>  static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
>  {
> -	switch (imx6_pcie->drvdata->variant) {
> -	case IMX7D:
> -	case IMX8MQ:
> -	case IMX8MQ_EP:
> +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET))

This check is not strictly necessary. If the flag is not set,
imx6_pcie->pciephy_reset is guaranteed to be NULL, and then
reset_control_assert() is a no-op. Same for the other (de)assert
calls below.

[...]

> @@ -1335,36 +1319,24 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  					     "failed to get pcie phy\n");
>  	}
>  
> -	switch (imx6_pcie->drvdata->variant) {
> -	case IMX7D:
> -		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> -			imx6_pcie->controller_id = 1;
> -
> -		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
> -									    "pciephy");
> -		if (IS_ERR(imx6_pcie->pciephy_reset)) {
> -			dev_err(dev, "Failed to get PCIEPHY reset control\n");
> -			return PTR_ERR(imx6_pcie->pciephy_reset);
> -		}
> -
> -		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> -									 "apps");
> -		if (IS_ERR(imx6_pcie->apps_reset)) {
> -			dev_err(dev, "Failed to get PCIE APPS reset control\n");
> -			return PTR_ERR(imx6_pcie->apps_reset);
> -		}
> -		break;
> -	case IMX8MM:
> -	case IMX8MM_EP:
> -	case IMX8MP:
> -	case IMX8MP_EP:
> -		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> -									 "apps");
> +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET)) {
> +		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev, "apps");
[...]

I wonder whether we should just defer the check whether apps/pciephy
resets should be used to the device tree validation, and make this an
unconditional call to get an optional reset control:

	imx6_pcie->apps_reset = devm_reset_control_get_optional_exclusive(dev, "apps");

regards
Philipp


From conor at kernel.org  Wed Dec  6 08:54:33 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 6 Dec 2023 16:54:33 +0000
Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <ZXCVUD9cCYEShrrj@MiWiFi-R3L-srv>
References: <20231130023955.5257-1-bhe@redhat.com>
 <20231130023955.5257-6-bhe@redhat.com>
 <20231201-blog-blasphemy-985d2665903c@wendy>
 <ZW3yXWJ7rTrtZzyg@MiWiFi-R3L-srv>
 <20231204-liftoff-enclosure-d3e3daf0ab6e@spud>
 <ZXCVUD9cCYEShrrj@MiWiFi-R3L-srv>
Message-ID: <20231206-pasta-embassy-c7250740b16c@spud>

On Wed, Dec 06, 2023 at 11:37:52PM +0800, Baoquan He wrote:
> On 12/04/23 at 04:14pm, Conor Dooley wrote:
> > On Mon, Dec 04, 2023 at 11:38:05PM +0800, Baoquan He wrote:
> > > On 12/01/23 at 10:38am, Conor Dooley wrote:
> > > > On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
> > > > 
> > > > $subject has a typo in the arch bit :)
> > > 
> > > Indeed, will fix if need report. Thanks for careful checking.
> > > 
> > > > 
> > > > > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > > > > loading related codes.
> > > > 
> > > > Commit messages should be understandable in isolation, but this only
> > > > explains (part of) what is obvious in the diff. Why is this change
> > > > being made?
> > > 
> > > The purpose has been detailedly described in cover letter and patch 1
> > > log. Andrew has picked these patches into his tree and grabbed the cover
> > > letter log into the relevant commit for people's later checking. All
> > > these seven patches will be present in mainline together. This is common
> > > way when posting patch series? Please let me know if I misunderstand
> > > anything.
> > 
> > Each patch having a commit message that explains why a change is being
> > made is the expectation. It is especially useful to explain the why
> > here, since it is not just a mechanical conversion of pr_debug()s as the
> > commit message suggests.
> 
> Sounds reasonable. I rephrase the patch 3 log as below, do you think
> it's OK to you?

Yes, but with one comment.

> 
> I will also adjust patch logs on other ARCH once this one is done.
> Thanks.
> 
> =============================
> Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if required
> 
> Then when specifying '-d' for kexec_file_load interface, loaded
> locations of kernel/initrd/cmdline etc can be printed out to help debug.
> 
> Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> loading related codes.
> 

> And also replace pr_notice() with kexec_dprintk() in elf_kexec_load()
> because it's make sense to always print out loaded location of purgatory
> and device tree even though users don't expect the message.

This seems to contradict what you said in your earlier mail, about
moving these from notice to debug. I think you missed a negation in your
new version of the commit message. What you said in response to me seems
like a more complete explanation anyway:
	always printing out the loaded location of purgatory and
	device tree doesn't make sense. It will be confusing when users
	see these even when they do normal kexec/kdump loading.

Thanks,
Conor.

> And also remove kexec_image_info() because the content has been printed
> out in generic code.
> 
> ============================
> 
> > 
> > > > 
> > > > > 
> > > > > And also remove kexec_image_info() because the content has been printed
> > > > > out in generic code.
> > > > > 
> > > > > Signed-off-by: Baoquan He <bhe at redhat.com>
> > > > > ---
> > > > >  arch/riscv/kernel/elf_kexec.c     | 11 ++++++-----
> > > > >  arch/riscv/kernel/machine_kexec.c | 26 --------------------------
> > > > >  2 files changed, 6 insertions(+), 31 deletions(-)
> > > > > 
> > > > > diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> > > > > index e60fbd8660c4..5bd1ec3341fe 100644
> > > > > --- a/arch/riscv/kernel/elf_kexec.c
> > > > > +++ b/arch/riscv/kernel/elf_kexec.c
> > > > > @@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > >  	if (ret)
> > > > >  		goto out;
> > > > >  	kernel_start = image->start;
> > > > > -	pr_notice("The entry point of kernel at 0x%lx\n", image->start);
> > > > >  
> > > > >  	/* Add the kernel binary to the image */
> > > > >  	ret = riscv_kexec_elf_load(image, &ehdr, &elf_info,
> > > > > @@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > >  		image->elf_load_addr = kbuf.mem;
> > > > >  		image->elf_headers_sz = headers_sz;
> > > > >  
> > > > > -		pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > > > -			 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > > > +		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > > > +			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > > >  
> > > > >  		/* Setup cmdline for kdump kernel case */
> > > > >  		modified_cmdline = setup_kdump_cmdline(image, cmdline,
> > > > > @@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > >  		pr_err("Error loading purgatory ret=%d\n", ret);
> > > > >  		goto out;
> > > > >  	}
> > > > > +	kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem);
> > > > > +
> > > > >  	ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry",
> > > > >  					     &kernel_start,
> > > > >  					     sizeof(kernel_start), 0);
> > > > > @@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > >  		if (ret)
> > > > >  			goto out;
> > > > >  		initrd_pbase = kbuf.mem;
> > > > 
> > > > > -		pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > > > +		kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > > 
> > > > This is not a pr_debug().
> > > > 
> > > > >  	}
> > > > >  
> > > > >  	/* Add the DTB to the image */
> > > > > @@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > >  	}
> > > > >  	/* Cache the fdt buffer address for memory cleanup */
> > > > >  	image->arch.fdt = fdt;
> > > > 
> > > > > -	pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > > > +	kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > > 
> > > > Neither is this. Why are they being moved from pr_notice()?
> > > 
> > > You are right. 
> > > 
> > > While always printing out the loaded location of purgatory and
> > > device tree doesn't make sense. It will be confusing when users
> > > see these even when they do normal kexec/kdump loading. It should be
> > > changed to pr_debug().
> > > 
> > > Which way do you suggest?
> > > 1) change it back to pr_debug(), fix it in another patch;
> > > 2) keep it as is in the patch;
> > 
> > Personally I think it is fine to change them all in one patch, but the
> > rationale for converting pr_notice() to your new debug infrastructure
> > needs to be in the commit message.
> 
> Sure, sounds good to me. I have changed the patch log to reflect this as
> you suggested, please help check. Thanks again.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/69e66116/attachment.sig>

From helgaas at kernel.org  Wed Dec  6 08:59:53 2023
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 6 Dec 2023 10:59:53 -0600
Subject: [PATCH 4/9] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <ZXCmSOwTWR6AVpGB@lizhi-Precision-Tower-5810>
Message-ID: <20231206165953.GA717921@bhelgaas>

On Wed, Dec 06, 2023 at 11:50:16AM -0500, Frank Li wrote:
> On Wed, Dec 06, 2023 at 10:36:56AM -0600, Bjorn Helgaas wrote:
> > In subject, maybe you mean "Use 'linux,pci-domain' as slot ID"?
> > "Using" is the wrong verb form here.
> > 
> > On Wed, Dec 06, 2023 at 10:58:58AM -0500, Frank Li wrote:
> > > Avoid use get slot id by compared with register physical address. If there
> > > are more than 2 slots, compared logic will become complex.
> > 
> > But this doesn't say anything about "linux,pci-domain", and I don't
> > see anything about a register physical address in the patch.
> > 
> > Maybe this commit log was meant for a different patch?  I'm confused.
> > 
> > > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > > ---
> > >  drivers/pci/controller/dwc/pci-imx6.c | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 62d77fabd82a..239ef439ba70 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -33,6 +33,7 @@
> > >  #include <linux/pm_domain.h>
> > >  #include <linux/pm_runtime.h>
> > >  
> > > +#include "../../pci.h"
> > >  #include "pcie-designware.h"
> > >  
> > >  #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
> > > @@ -1333,6 +1334,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> > >  					     "Failed to get PCIEPHY reset control\n");
> > >  	}
> > >  
> > > +	/* Using linux,pci-domain as PCI slot id */
> > > +	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
> > > +	if (imx6_pcie->controller_id)
> > > +		imx6_pcie->controller_id = 0;
> > 
> > I don't understand what this is doing.  It looks the same as just:
> 
> Good capture. It should be 
> if (imx6_pcie->controller_id < 0)
> 	imx6_pcie->controller_id = 0;
> 
> for only one PCI controller case. I just tested first one slot before send
> patch, so not met problem.
> 
> Previously, we use below logic
> 	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> 		imx6_pcie->controller_id = 1;
> 
> It is not good to depend on register's base address. If there are 3
> controllers, check logic will becomoe ugly.

Makes sense.  If the previous code depended on the base address, this
patch would make more sense if it contained both the addition of the
of_get_pci_domain_nr() call and the removal of the base address code.

> > Maybe this is a typo?  As written, it doesn't look like there's any
> > point in calling of_get_pci_domain_nr().
> > 
> > >  	switch (imx6_pcie->drvdata->variant) {
> > >  	case IMX7D:
> > >  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> > > -- 
> > > 2.34.1
> > > 


From dianders at chromium.org  Wed Dec  6 09:00:40 2023
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 6 Dec 2023 09:00:40 -0800
Subject: [RFC PATCH v3 4/5] arm64: dts: mediatek: mt8173-elm-hana: Mark
 touchscreens and trackpads as fail
In-Reply-To: <4b9ea82c-d1a4-47b6-ba03-346cfdedef05@collabora.com>
References: <20231128084236.157152-1-wenst@chromium.org> <20231128084236.157152-5-wenst@chromium.org>
 <CAD=FV=W01gfxV6RN2o6CVS7jjf8qgKP-jUy9Bp94d2hWzVC48A@mail.gmail.com>
 <CAGXv+5E+R292XsOFSL-j0KJMmVJjWtxMRgCK8besP7mo6NDOWA@mail.gmail.com>
 <CAD=FV=UQkAjgMuR85cPikNtCxsODWPWs7cibOcOoNGdjSSvF8Q@mail.gmail.com>
 <3700f05f-2411-4422-972f-f3df690efb84@collabora.com> <CAGXv+5G5fFTv8zn=YamSdccjuYemE5oKBqjb8CSyGzu9aMJ0eg@mail.gmail.com>
 <4b9ea82c-d1a4-47b6-ba03-346cfdedef05@collabora.com>
Message-ID: <CAD=FV=UMRRYieChp2+4Z6zxL-CSVZabiokuHH=qrnMMSmjNM2Q@mail.gmail.com>

Hi,

On Wed, Dec 6, 2023 at 2:02?AM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 06/12/23 03:55, Chen-Yu Tsai ha scritto:
> > On Tue, Dec 5, 2023 at 6:22?PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno at collabora.com> wrote:
> >>
> >> Il 04/12/23 17:50, Doug Anderson ha scritto:
> >>> Hi,
> >>>
> >>> On Sun, Dec 3, 2023 at 10:59?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >>>>
> >>>> On Sat, Dec 2, 2023 at 8:58?AM Doug Anderson <dianders at chromium.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >>>>>>
> >>>>>> @@ -44,6 +46,7 @@ trackpad2: trackpad at 2c {
> >>>>>>                   reg = <0x2c>;
> >>>>>>                   hid-descr-addr = <0x0020>;
> >>>>>>                   wakeup-source;
> >>>>>> +               status = "fail-needs-probe";
> >>>>>
> >>>>> While doing this, you could also remove the hack where the trackpad
> >>>>> IRQ pinctrl is listed under i2c4.
> >>>>
> >>>> Sure. I do think we can do away with it though. According to at least one
> >>>> schematic, the interrupt line has pull-ups on both sides of the voltage
> >>>> shifter.
> >>>>
> >>>> BTW, The touchscreen doesn't have pinctrl entries. This has pull-ups on
> >>>> both sides of the voltage shifter as well.
> >>>
> >>> I dunno if the convention is different on Mediatek boards, but at
> >>> least on boards I've been involved with in the past we've always put
> >>> pinctrl entries just to make things explicit. This meant that we
> >>> didn't rely on the firmware/bootrom/defaults to leave pulls in any
> >>> particular state. ...otherwise those external pull-ups could be
> >>> fighting with internal pull-downs, right?
> >>>
> >>
> >> MediaTek boards aren't special and there's no good reason for those to rely on
> >> firmware/bootrom/defaults - so there is no good reason to avoid declaring any
> >> relevant pinctrl entry.
> >
> > I think this should be migrated to use the proper GPIO bindings: the
> > GPIO_PULL_UP / GPIO_PULL_DOWN / GPIO_BIAS_DISABLE flags.
> >
> > But that's a different discussion.
> >
>
> 100% agreed.

I guess I'd need to see patches as an example to see how this looks,
but I'm at least slightly skeptical. In this case the GPIO is
indirectly specified via "interrupts". Would you add these flags to
the interrupts specifier, too? There's another potential pull as well
(PIN_CONFIG_BIAS_BUS_HOLD) as well as other pin configuration
(PIN_CONFIG_INPUT_DEBOUNCE, for instance). Do we try to fit all of
these into the GPIO / interrupt specifier?

Certainly I will admit that this is a complicated topic, but it seems
weird to say that we use pinctrl to specify pin configuration / pulls
for all pins except ones that are configured as GPIOs or GPIO
interrupts.

-Doug


From Frank.li at nxp.com  Wed Dec  6 09:07:00 2023
From: Frank.li at nxp.com (Frank Li)
Date: Wed, 6 Dec 2023 12:07:00 -0500
Subject: [PATCH 4/9] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231206165953.GA717921@bhelgaas>
References: <ZXCmSOwTWR6AVpGB@lizhi-Precision-Tower-5810>
 <20231206165953.GA717921@bhelgaas>
Message-ID: <ZXCqNI3VZ8Sn23WM@lizhi-Precision-Tower-5810>

On Wed, Dec 06, 2023 at 10:59:53AM -0600, Bjorn Helgaas wrote:
> On Wed, Dec 06, 2023 at 11:50:16AM -0500, Frank Li wrote:
> > On Wed, Dec 06, 2023 at 10:36:56AM -0600, Bjorn Helgaas wrote:
> > > In subject, maybe you mean "Use 'linux,pci-domain' as slot ID"?
> > > "Using" is the wrong verb form here.
> > > 
> > > On Wed, Dec 06, 2023 at 10:58:58AM -0500, Frank Li wrote:
> > > > Avoid use get slot id by compared with register physical address. If there
> > > > are more than 2 slots, compared logic will become complex.
> > > 
> > > But this doesn't say anything about "linux,pci-domain", and I don't
> > > see anything about a register physical address in the patch.
> > > 
> > > Maybe this commit log was meant for a different patch?  I'm confused.
> > > 
> > > > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > > > ---
> > > >  drivers/pci/controller/dwc/pci-imx6.c | 6 ++++++
> > > >  1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> > > > index 62d77fabd82a..239ef439ba70 100644
> > > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > > @@ -33,6 +33,7 @@
> > > >  #include <linux/pm_domain.h>
> > > >  #include <linux/pm_runtime.h>
> > > >  
> > > > +#include "../../pci.h"
> > > >  #include "pcie-designware.h"
> > > >  
> > > >  #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
> > > > @@ -1333,6 +1334,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> > > >  					     "Failed to get PCIEPHY reset control\n");
> > > >  	}
> > > >  
> > > > +	/* Using linux,pci-domain as PCI slot id */
> > > > +	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
> > > > +	if (imx6_pcie->controller_id)
> > > > +		imx6_pcie->controller_id = 0;
> > > 
> > > I don't understand what this is doing.  It looks the same as just:
> > 
> > Good capture. It should be 
> > if (imx6_pcie->controller_id < 0)
> > 	imx6_pcie->controller_id = 0;
> > 
> > for only one PCI controller case. I just tested first one slot before send
> > patch, so not met problem.
> > 
> > Previously, we use below logic
> > 	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> > 		imx6_pcie->controller_id = 1;
> > 
> > It is not good to depend on register's base address. If there are 3
> > controllers, check logic will becomoe ugly.
> 
> Makes sense.  If the previous code depended on the base address, this
> patch would make more sense if it contained both the addition of the
> of_get_pci_domain_nr() call and the removal of the base address code.

Remove base address code will block existed functions. My plan is
1. this patch upstreamed
2. related dts add linux,pci-domain.
3. removed base address compare code.

Frank

> 
> > > Maybe this is a typo?  As written, it doesn't look like there's any
> > > point in calling of_get_pci_domain_nr().
> > > 
> > > >  	switch (imx6_pcie->drvdata->variant) {
> > > >  	case IMX7D:
> > > >  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> > > > -- 
> > > > 2.34.1
> > > > 


From helgaas at kernel.org  Wed Dec  6 09:07:47 2023
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 6 Dec 2023 11:07:47 -0600
Subject: [PATCH 1/2] PCI: mediatek: Allocate MSI address with
 dmam_alloc_coherent
In-Reply-To: <20231206083753.18186-2-jianjun.wang@mediatek.com>
Message-ID: <20231206170747.GA718062@bhelgaas>

On Wed, Dec 06, 2023 at 04:37:52PM +0800, Jianjun Wang wrote:
> Use 'dmam_alloc_coherent' to allocate the MSI address, instead of using
> 'virt_to_phys'.

s/'dmam_alloc_coherent'/dmam_alloc_coherent()/
s/'virt_to_phys'/virt_to_phys()/

In subject also.

> @@ -732,8 +740,11 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
>  	val &= ~INTX_MASK;
>  	writel(val, port->base + PCIE_INT_MASK);
>  
> -	if (IS_ENABLED(CONFIG_PCI_MSI))
> -		mtk_pcie_enable_msi(port);
> +	if (IS_ENABLED(CONFIG_PCI_MSI)) {
> +		err = mtk_pcie_enable_msi(port);
> +		if (err)
> +			return err;

Is failure to enable MSI a fatal issue?  It looks like this will make
the host controller completely unusable if we can't set up MSI, even
if downstream PCI devices could use INTx and get along without MSI.

Bjorn


From andre.przywara at arm.com  Wed Dec  6 09:11:28 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 6 Dec 2023 17:11:28 +0000
Subject: [PATCH v4 097/115] pwm: sun4i: Make use of devm_pwmchip_alloc()
 function
In-Reply-To: <c79e120b120df9eedddaaf70364d28e15df23d91.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
	<c79e120b120df9eedddaaf70364d28e15df23d91.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <20231206171128.3e2391ea@donnerap.manchester.arm.com>

On Wed,  6 Dec 2023 12:44:51 +0100
Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote:

Hi,

> This prepares the pwm-sun4i driver to further changes of the pwm core
> outlined in the commit introducing devm_pwmchip_alloc(). There is no
> intended semantical change and the driver should behave as before.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

That looks alright to me, it's really only wrapping the access to
struct sun4i_pwm_chip using the newly provided functions.

Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Cheers,
Andre

> ---
>  drivers/pwm/pwm-sun4i.c | 34 +++++++++++++++++++---------------
>  1 file changed, 19 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 44edf1ce5739..36a8dc65b19c 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -81,7 +81,6 @@ struct sun4i_pwm_data {
>  };
>  
>  struct sun4i_pwm_chip {
> -	struct pwm_chip chip;
>  	struct clk *bus_clk;
>  	struct clk *clk;
>  	struct reset_control *rst;
> @@ -92,7 +91,7 @@ struct sun4i_pwm_chip {
>  
>  static inline struct sun4i_pwm_chip *to_sun4i_pwm_chip(struct pwm_chip *chip)
>  {
> -	return container_of(chip, struct sun4i_pwm_chip, chip);
> +	return pwmchip_get_drvdata(chip);
>  }
>  
>  static inline u32 sun4i_pwm_readl(struct sun4i_pwm_chip *chip,
> @@ -384,17 +383,22 @@ MODULE_DEVICE_TABLE(of, sun4i_pwm_dt_ids);
>  
>  static int sun4i_pwm_probe(struct platform_device *pdev)
>  {
> +	struct pwm_chip *chip;
>  	struct sun4i_pwm_chip *sun4ichip;
> +	const struct sun4i_pwm_data *data;
>  	int ret;
>  
> -	sun4ichip = devm_kzalloc(&pdev->dev, sizeof(*sun4ichip), GFP_KERNEL);
> -	if (!sun4ichip)
> -		return -ENOMEM;
> -
> -	sun4ichip->data = of_device_get_match_data(&pdev->dev);
> -	if (!sun4ichip->data)
> +	data = of_device_get_match_data(&pdev->dev);
> +	if (!data)
>  		return -ENODEV;
>  
> +	chip = devm_pwmchip_alloc(&pdev->dev, data->npwm, sizeof(*sun4ichip));
> +	if (IS_ERR(chip))
> +		return PTR_ERR(chip);
> +	sun4ichip = to_sun4i_pwm_chip(chip);
> +
> +	sun4ichip->data = data;
> +
>  	sun4ichip->base = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(sun4ichip->base))
>  		return PTR_ERR(sun4ichip->base);
> @@ -451,19 +455,18 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>  		goto err_bus;
>  	}
>  
> -	sun4ichip->chip.dev = &pdev->dev;
> -	sun4ichip->chip.ops = &sun4i_pwm_ops;
> -	sun4ichip->chip.npwm = sun4ichip->data->npwm;
> +	chip->ops = &sun4i_pwm_ops;
> +	chip->npwm = sun4ichip->data->npwm;
>  
>  	spin_lock_init(&sun4ichip->ctrl_lock);
>  
> -	ret = pwmchip_add(&sun4ichip->chip);
> +	ret = pwmchip_add(chip);
>  	if (ret < 0) {
>  		dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
>  		goto err_pwm_add;
>  	}
>  
> -	platform_set_drvdata(pdev, sun4ichip);
> +	platform_set_drvdata(pdev, chip);
>  
>  	return 0;
>  
> @@ -477,9 +480,10 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>  
>  static void sun4i_pwm_remove(struct platform_device *pdev)
>  {
> -	struct sun4i_pwm_chip *sun4ichip = platform_get_drvdata(pdev);
> +	struct pwm_chip *chip = platform_get_drvdata(pdev);
> +	struct sun4i_pwm_chip *sun4ichip = to_sun4i_pwm_chip(chip);
>  
> -	pwmchip_remove(&sun4ichip->chip);
> +	pwmchip_remove(chip);
>  
>  	clk_disable_unprepare(sun4ichip->bus_clk);
>  	reset_control_assert(sun4ichip->rst);



From jgg at nvidia.com  Wed Dec  6 09:20:35 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 6 Dec 2023 13:20:35 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZXCh9N2xp0efHcpE@arm.com>
References: <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <86bkb4bn2v.wl-maz@kernel.org>
 <ZW9ezSGSDIvv5MsQ@arm.com>
 <86a5qobkt8.wl-maz@kernel.org>
 <ZW9uqu7yOtyZfmvC@arm.com>
 <868r67blwo.wl-maz@kernel.org>
 <ZXBlmt88dKmZLCU9@arm.com>
 <20231206151603.GR2692119@nvidia.com>
 <ZXCh9N2xp0efHcpE@arm.com>
Message-ID: <20231206172035.GU2692119@nvidia.com>

On Wed, Dec 06, 2023 at 04:31:48PM +0000, Catalin Marinas wrote:

> > This would be fine, as would a VMA flag. Please pick one :)
> > 
> > I think a VMA flag is simpler than messing with pgprot.
> 
> I guess one could write a patch and see how it goes ;).

A lot of patches have been sent on this already :(

> > > If we want the VMM to drive this entirely, we could add a new mmap()
> > > flag like MAP_WRITECOMBINE or PROT_WRITECOMBINE. They do feel a bit
> > 
> > As in the other thread, we cannot unconditionally map NORMAL_NC into
> > the VMM.
> 
> I'm not suggesting this but rather the VMM map portions of the BAR with
> either Device or Normal-NC, concatenate them (MAP_FIXED) and pass this
> range as a memory slot (or multiple if a slot doesn't allow multiple
> vmas).

The VMM can't know what to do. We already talked about this. The VMM
cannot be involved in the decision to make pages NORMAL_NC or
not. That idea ignores how actual devices work.

Either the VM decides directly as this patch proposes or the VM does
some new generic trap/hypercall to ask the VMM to change it on its
behalf. The VMM cannot do it independently.

AFAIK nobody wants to see a trap/hypercall solution.

That is why we have been exclusively focused on this approach.

> > > The latter has some benefits for DPDK but it's a lot more involved
> > > with
> > 
> > DPDK WC support will be solved with some VFIO-only change if anyone
> > ever cares to make it, if that is what you mean.
> 
> Yeah. Some arguments I've heard in private and public discussions is
> that the KVM device pass-through shouldn't be different from the DPDK
> case. 

I strongly disagree with this.

The KVM case should be solved without the VMM being aware of what
mappings the VM is doing.

DPDK is in control and can directly ask VFIO to make the correct
pgprot with an ioctl.

You can hear Alex also articulate this position in that video.

> There was some statement in there that for x86, the guests are
> allowed to do WC without other KVM restrictions (not sure whether
> that's the case, not familiar with it).

x86 has a similar issue (Sean was talking about this and how he wants
to fix it) where the VMM can restrict things and on x86 there are
configurations where WC does and doesn't work in VM's too. Depends on
who made the hypervisor. :(

Nobody has pushed hard enough to see it resolved in upstream, but I
understand some of the cloud operator set have their own solutions.

> > We talked about this already, the guest must decide, the VMM doesn't
> > have the information to pre-predict which pages the guest will want to
> > use WC on.
> 
> Are the Device/Normal offsets within a BAR fixed, documented in e.g. the
> spec or this is something configurable via some MMIO that the guest
> does.

No, it is fully dynamic on demand with firmware RPCs.

Jason


From jgg at nvidia.com  Wed Dec  6 09:28:08 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:08 -0400
Subject: [PATCH v3 02/27] iommu/arm-smmu-v3: Do not allow a SVA domain to be set on the wrong PASID
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <2-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

The SVA code is wired to assume that the SVA is programmed onto the
mm->pasid. The current core code always does this, so it is fine.

Add a check for clarity.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index bd0566381c58a9..ee3d148aafa26b 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -585,6 +585,9 @@ static int arm_smmu_sva_set_dev_pasid(struct iommu_domain *domain,
 	int ret = 0;
 	struct mm_struct *mm = domain->mm;
 
+	if (mm->pasid != id)
+		return -EINVAL;
+
 	mutex_lock(&sva_lock);
 	ret = __arm_smmu_sva_bind(dev, mm);
 	mutex_unlock(&sva_lock);
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:24 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:24 -0400
Subject: [PATCH v3 18/27] iommu/arm-smmu-v3: Make SVA allocate a normal arm_smmu_domain
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <18-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Currently the SVA domain is a naked struct iommu_domain, allocate a struct
arm_smmu_domain instead.

This is necessary to be able to use the struct arm_master_domain
mechanism.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 12 +++----
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 34 +++++++++++--------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  7 ++--
 3 files changed, 30 insertions(+), 23 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 2f818b24d931c2..5894785aa901e8 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -646,14 +646,14 @@ static const struct iommu_domain_ops arm_smmu_sva_domain_ops = {
 	.free			= arm_smmu_sva_domain_free
 };
 
-struct iommu_domain *arm_smmu_sva_domain_alloc(void)
+struct iommu_domain *arm_smmu_sva_domain_alloc(unsigned type)
 {
-	struct iommu_domain *domain;
+	struct arm_smmu_domain *smmu_domain;
 
-	domain = kzalloc(sizeof(*domain), GFP_KERNEL);
-	if (!domain)
+	smmu_domain = arm_smmu_domain_alloc();
+	if (!smmu_domain)
 		return NULL;
-	domain->ops = &arm_smmu_sva_domain_ops;
+	smmu_domain->domain.ops = &arm_smmu_sva_domain_ops;
 
-	return domain;
+	return &smmu_domain->domain;
 }
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index a6cd4699ddcc76..5db78e6e03dcfd 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2228,23 +2228,10 @@ static bool arm_smmu_capable(struct device *dev, enum iommu_cap cap)
 	}
 }
 
-static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
-{
-
-	if (type == IOMMU_DOMAIN_SVA)
-		return arm_smmu_sva_domain_alloc();
-	return NULL;
-}
-
-static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
+struct arm_smmu_domain *arm_smmu_domain_alloc(void)
 {
 	struct arm_smmu_domain *smmu_domain;
 
-	/*
-	 * Allocate the domain and initialise some of its data structures.
-	 * We can't really do anything meaningful until we've added a
-	 * master.
-	 */
 	smmu_domain = kzalloc(sizeof(*smmu_domain), GFP_KERNEL);
 	if (!smmu_domain)
 		return NULL;
@@ -2254,6 +2241,23 @@ static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
 	spin_lock_init(&smmu_domain->devices_lock);
 	INIT_LIST_HEAD(&smmu_domain->mmu_notifiers);
 
+	return smmu_domain;
+}
+
+static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
+{
+	struct arm_smmu_domain *smmu_domain;
+
+	smmu_domain = arm_smmu_domain_alloc();
+	if (!smmu_domain)
+		return NULL;
+
+	/*
+	 * Allocate the domain and initialise some of its data structures.
+	 * We can't really do anything meaningful until we've added a
+	 * master.
+	 */
+
 	if (dev) {
 		struct arm_smmu_master *master = dev_iommu_priv_get(dev);
 
@@ -3207,7 +3211,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.identity_domain	= &arm_smmu_identity_domain,
 	.blocked_domain		= &arm_smmu_blocked_domain,
 	.capable		= arm_smmu_capable,
-	.domain_alloc		= arm_smmu_domain_alloc,
+	.domain_alloc		= arm_smmu_sva_domain_alloc,
 	.domain_alloc_paging    = arm_smmu_domain_alloc_paging,
 	.probe_device		= arm_smmu_probe_device,
 	.release_device		= arm_smmu_release_device,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index f72aebaf95f981..c1181e456b7d5f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -765,7 +765,8 @@ to_smmu_domain_safe(struct iommu_domain *domain)
 {
 	if (!domain)
 		return NULL;
-	if (domain->type & __IOMMU_DOMAIN_PAGING)
+	if (domain->type & __IOMMU_DOMAIN_PAGING ||
+	    domain->type == IOMMU_DOMAIN_SVA)
 		return to_smmu_domain(domain);
 	return NULL;
 }
@@ -773,6 +774,8 @@ to_smmu_domain_safe(struct iommu_domain *domain)
 extern struct xarray arm_smmu_asid_xa;
 extern struct mutex arm_smmu_asid_lock;
 
+struct arm_smmu_domain *arm_smmu_domain_alloc(void);
+
 void arm_smmu_clear_cd(struct arm_smmu_master *master, int ssid);
 struct arm_smmu_cd *arm_smmu_get_cd_ptr(struct arm_smmu_master *master,
 					u32 ssid);
@@ -805,7 +808,7 @@ int arm_smmu_master_enable_sva(struct arm_smmu_master *master);
 int arm_smmu_master_disable_sva(struct arm_smmu_master *master);
 bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master);
 void arm_smmu_sva_notifier_synchronize(void);
-struct iommu_domain *arm_smmu_sva_domain_alloc(void);
+struct iommu_domain *arm_smmu_sva_domain_alloc(unsigned int type);
 void arm_smmu_sva_remove_dev_pasid(struct iommu_domain *domain,
 				   struct device *dev, ioasid_t id);
 #else /* CONFIG_ARM_SMMU_V3_SVA */
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:18 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:18 -0400
Subject: [PATCH v3 12/27] iommu/arm-smmu-v3: Build the whole CD in arm_smmu_make_s1_cd()
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <12-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Half the code was living in arm_smmu_domain_finalise_s1(), just move it
here and take the values directly from the pgtbl_ops instead of storing
copies.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 47 ++++++++-------------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  3 --
 2 files changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 27c0a468958dc0..38e83386f631f1 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1204,15 +1204,25 @@ void arm_smmu_make_s1_cd(struct arm_smmu_cd *target,
 			 struct arm_smmu_domain *smmu_domain)
 {
 	struct arm_smmu_ctx_desc *cd = &smmu_domain->cd;
+	const struct io_pgtable_cfg *pgtbl_cfg =
+		&io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops)->cfg;
+	typeof(&pgtbl_cfg->arm_lpae_s1_cfg.tcr) tcr =
+		&pgtbl_cfg->arm_lpae_s1_cfg.tcr;
 
 	memset(target, 0, sizeof(*target));
 
 	target->data[0] = cpu_to_le64(
-		cd->tcr |
+		FIELD_PREP(CTXDESC_CD_0_TCR_T0SZ, tcr->tsz) |
+		FIELD_PREP(CTXDESC_CD_0_TCR_TG0, tcr->tg) |
+		FIELD_PREP(CTXDESC_CD_0_TCR_IRGN0, tcr->irgn) |
+		FIELD_PREP(CTXDESC_CD_0_TCR_ORGN0, tcr->orgn) |
+		FIELD_PREP(CTXDESC_CD_0_TCR_SH0, tcr->sh) |
+		CTXDESC_CD_0_TCR_EPD1 |
 #ifdef __BIG_ENDIAN
 		CTXDESC_CD_0_ENDI |
 #endif
 		CTXDESC_CD_0_V |
+		FIELD_PREP(CTXDESC_CD_0_TCR_IPS, tcr->ips) |
 		CTXDESC_CD_0_AA64 |
 		(master->stall_enabled ? CTXDESC_CD_0_S : 0) |
 		CTXDESC_CD_0_R |
@@ -1220,9 +1230,9 @@ void arm_smmu_make_s1_cd(struct arm_smmu_cd *target,
 		CTXDESC_CD_0_ASET |
 		FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid)
 		);
-
-	target->data[1] = cpu_to_le64(cd->ttbr & CTXDESC_CD_1_TTB0_MASK);
-	target->data[3] = cpu_to_le64(cd->mair);
+	target->data[1] = cpu_to_le64(pgtbl_cfg->arm_lpae_s1_cfg.ttbr &
+				      CTXDESC_CD_1_TTB0_MASK);
+	target->data[3] = cpu_to_le64(pgtbl_cfg->arm_lpae_s1_cfg.mair);
 }
 
 void arm_smmu_clear_cd(struct arm_smmu_master *master, int ssid)
@@ -2240,13 +2250,11 @@ static void arm_smmu_domain_free(struct iommu_domain *domain)
 }
 
 static int arm_smmu_domain_finalise_s1(struct arm_smmu_device *smmu,
-				       struct arm_smmu_domain *smmu_domain,
-				       struct io_pgtable_cfg *pgtbl_cfg)
+				       struct arm_smmu_domain *smmu_domain)
 {
 	int ret;
 	u32 asid;
 	struct arm_smmu_ctx_desc *cd = &smmu_domain->cd;
-	typeof(&pgtbl_cfg->arm_lpae_s1_cfg.tcr) tcr = &pgtbl_cfg->arm_lpae_s1_cfg.tcr;
 
 	refcount_set(&cd->refs, 1);
 
@@ -2254,31 +2262,13 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_device *smmu,
 	mutex_lock(&arm_smmu_asid_lock);
 	ret = xa_alloc(&arm_smmu_asid_xa, &asid, cd,
 		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
-	if (ret)
-		goto out_unlock;
-
 	cd->asid	= (u16)asid;
-	cd->ttbr	= pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
-	cd->tcr		= FIELD_PREP(CTXDESC_CD_0_TCR_T0SZ, tcr->tsz) |
-			  FIELD_PREP(CTXDESC_CD_0_TCR_TG0, tcr->tg) |
-			  FIELD_PREP(CTXDESC_CD_0_TCR_IRGN0, tcr->irgn) |
-			  FIELD_PREP(CTXDESC_CD_0_TCR_ORGN0, tcr->orgn) |
-			  FIELD_PREP(CTXDESC_CD_0_TCR_SH0, tcr->sh) |
-			  FIELD_PREP(CTXDESC_CD_0_TCR_IPS, tcr->ips) |
-			  CTXDESC_CD_0_TCR_EPD1 | CTXDESC_CD_0_AA64;
-	cd->mair	= pgtbl_cfg->arm_lpae_s1_cfg.mair;
-
-	mutex_unlock(&arm_smmu_asid_lock);
-	return 0;
-
-out_unlock:
 	mutex_unlock(&arm_smmu_asid_lock);
 	return ret;
 }
 
 static int arm_smmu_domain_finalise_s2(struct arm_smmu_device *smmu,
-				       struct arm_smmu_domain *smmu_domain,
-				       struct io_pgtable_cfg *pgtbl_cfg)
+				       struct arm_smmu_domain *smmu_domain)
 {
 	int vmid;
 	struct arm_smmu_s2_cfg *cfg = &smmu_domain->s2_cfg;
@@ -2302,8 +2292,7 @@ static int arm_smmu_domain_finalise(struct arm_smmu_domain *smmu_domain,
 	struct io_pgtable_cfg pgtbl_cfg;
 	struct io_pgtable_ops *pgtbl_ops;
 	int (*finalise_stage_fn)(struct arm_smmu_device *smmu,
-				 struct arm_smmu_domain *smmu_domain,
-				 struct io_pgtable_cfg *pgtbl_cfg);
+				 struct arm_smmu_domain *smmu_domain);
 
 	/* Restrict the stage to what we can actually support */
 	if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S1))
@@ -2346,7 +2335,7 @@ static int arm_smmu_domain_finalise(struct arm_smmu_domain *smmu_domain,
 	smmu_domain->domain.geometry.aperture_end = (1UL << pgtbl_cfg.ias) - 1;
 	smmu_domain->domain.geometry.force_aperture = true;
 
-	ret = finalise_stage_fn(smmu, smmu_domain, &pgtbl_cfg);
+	ret = finalise_stage_fn(smmu, smmu_domain);
 	if (ret < 0) {
 		free_io_pgtable_ops(pgtbl_ops);
 		return ret;
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 1c756803b7f963..b7a65e37c51e9e 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -587,9 +587,6 @@ struct arm_smmu_strtab_l1_desc {
 
 struct arm_smmu_ctx_desc {
 	u16				asid;
-	u64				ttbr;
-	u64				tcr;
-	u64				mair;
 
 	refcount_t			refs;
 	struct mm_struct		*mm;
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:11 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:11 -0400
Subject: [PATCH v3 05/27] iommu/arm-smmu-v3: Make CD programming use arm_smmu_write_entry_step()
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <5-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

CD table entries and STE's have the same essential programming sequence,
just with different types and sizes.

Have arm_smmu_write_ctx_desc() generate a target CD and call
arm_smmu_write_entry_step() to do the programming. Due to the way the
target CD is generated by modifying the existing CD this alone is not
enough for the CD callers to be freed of the ordering requirements.

The following patches will make the rest of the CD flow mirror the STE
flow with precise CD contents generated in all cases.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 79 +++++++++++++++------
 1 file changed, 57 insertions(+), 22 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 3f77583144e649..0847ce91c5cc1a 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1146,6 +1146,55 @@ static struct arm_smmu_cd *arm_smmu_get_cd_ptr(struct arm_smmu_master *master,
 	return &l1_desc->l2ptr[idx];
 }
 
+static void arm_smmu_get_cd_used(const struct arm_smmu_cd *ent,
+				 struct arm_smmu_cd *used_bits)
+{
+	memset(used_bits, 0, sizeof(*used_bits));
+
+	used_bits->data[0] = cpu_to_le64(CTXDESC_CD_0_V);
+	if (!(ent->data[0] & cpu_to_le64(CTXDESC_CD_0_V)))
+		return;
+	memset(used_bits, 0xFF, sizeof(*used_bits));
+
+	/* EPD0 means T0SZ/TG0/IR0/OR0/SH0/TTB0 are IGNORED */
+	if (ent->data[0] & cpu_to_le64(CTXDESC_CD_0_TCR_EPD0)) {
+		used_bits->data[0] &= ~cpu_to_le64(
+			CTXDESC_CD_0_TCR_T0SZ | CTXDESC_CD_0_TCR_TG0 |
+			CTXDESC_CD_0_TCR_IRGN0 | CTXDESC_CD_0_TCR_ORGN0 |
+			CTXDESC_CD_0_TCR_SH0);
+		used_bits->data[1] &= ~cpu_to_le64(CTXDESC_CD_1_TTB0_MASK);
+	}
+}
+
+static bool arm_smmu_write_cd_step(struct arm_smmu_cd *cur,
+				   const struct arm_smmu_cd *target,
+				   const struct arm_smmu_cd *target_used)
+{
+	struct arm_smmu_cd cur_used;
+	struct arm_smmu_cd step;
+
+	arm_smmu_get_cd_used(cur, &cur_used);
+	return arm_smmu_write_entry_step(cur->data, cur_used.data, target->data,
+					 target_used->data, step.data,
+					 cpu_to_le64(CTXDESC_CD_0_V),
+					 ARRAY_SIZE(cur->data));
+
+}
+
+static void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
+				    struct arm_smmu_cd *cdptr,
+				    const struct arm_smmu_cd *target)
+{
+	struct arm_smmu_cd target_used;
+
+	arm_smmu_get_cd_used(target, &target_used);
+	while (true) {
+		if (arm_smmu_write_cd_step(cdptr, target, &target_used))
+			break;
+		arm_smmu_sync_cd(master, ssid, true);
+	}
+}
+
 int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
 			    struct arm_smmu_ctx_desc *cd)
 {
@@ -1162,16 +1211,19 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
 	 */
 	u64 val;
 	bool cd_live;
-	struct arm_smmu_cd *cdptr;
+	struct arm_smmu_cd target;
+	struct arm_smmu_cd *cdptr = &target;
+	struct arm_smmu_cd *cd_table_entry;
 	struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table;
 
 	if (WARN_ON(ssid >= (1 << cd_table->s1cdmax)))
 		return -E2BIG;
 
-	cdptr = arm_smmu_get_cd_ptr(master, ssid);
-	if (!cdptr)
+	cd_table_entry = arm_smmu_get_cd_ptr(master, ssid);
+	if (!cd_table_entry)
 		return -ENOMEM;
 
+	target = *cd_table_entry;
 	val = le64_to_cpu(cdptr->data[0]);
 	cd_live = !!(val & CTXDESC_CD_0_V);
 
@@ -1191,13 +1243,6 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
 		cdptr->data[2] = 0;
 		cdptr->data[3] = cpu_to_le64(cd->mair);
 
-		/*
-		 * STE may be live, and the SMMU might read dwords of this CD in any
-		 * order. Ensure that it observes valid values before reading
-		 * V=1.
-		 */
-		arm_smmu_sync_cd(master, ssid, true);
-
 		val = cd->tcr |
 #ifdef __BIG_ENDIAN
 			CTXDESC_CD_0_ENDI |
@@ -1211,18 +1256,8 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
 		if (cd_table->stall_enabled)
 			val |= CTXDESC_CD_0_S;
 	}
-
-	/*
-	 * The SMMU accesses 64-bit values atomically. See IHI0070Ca 3.21.3
-	 * "Configuration structures and configuration invalidation completion"
-	 *
-	 *   The size of single-copy atomic reads made by the SMMU is
-	 *   IMPLEMENTATION DEFINED but must be at least 64 bits. Any single
-	 *   field within an aligned 64-bit span of a structure can be altered
-	 *   without first making the structure invalid.
-	 */
-	WRITE_ONCE(cdptr->data[0], cpu_to_le64(val));
-	arm_smmu_sync_cd(master, ssid, true);
+	cdptr->data[0] = cpu_to_le64(val);
+	arm_smmu_write_cd_entry(master, ssid, cd_table_entry, &target);
 	return 0;
 }
 
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:15 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:15 -0400
Subject: [PATCH v3 09/27] iommu/arm-smmu-v3: Allocate the CD table entry in advance
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <9-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Avoid arm_smmu_attach_dev() having to undo the changes to the
smmu_domain->devices list, acquire the cdptr earlier so we don't need to
handle that error.

Now there is a clear break in arm_smmu_attach_dev() where all the
prep-work has been done non-disruptively and we commit to making the HW
change, which cannot fail.

This completes transforming arm_smmu_attach_dev() so that it does not
disturb the HW if it fails.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 24 +++++++--------------
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index a21589f8729176..eea561edaee908 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2596,6 +2596,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	struct arm_smmu_device *smmu;
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
 	struct arm_smmu_master *master;
+	struct arm_smmu_cd *cdptr;
 
 	if (!fwspec)
 		return -ENOENT;
@@ -2624,6 +2625,12 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	if (ret)
 		return ret;
 
+	if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
+		cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
+		if (!cdptr)
+			return -ENOMEM;
+	}
+
 	/*
 	 * Prevent arm_smmu_share_asid() from trying to change the ASID
 	 * of either the old or new domain while we are working on it.
@@ -2643,13 +2650,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	switch (smmu_domain->stage) {
 	case ARM_SMMU_DOMAIN_S1: {
 		struct arm_smmu_cd target_cd;
-		struct arm_smmu_cd *cdptr;
-
-		cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
-		if (!cdptr) {
-			ret = -ENOMEM;
-			goto out_list_del;
-		}
 
 		arm_smmu_make_s1_cd(&target_cd, master, smmu_domain);
 		arm_smmu_write_cd_entry(master, IOMMU_NO_PASID, cdptr,
@@ -2666,16 +2666,8 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	}
 
 	arm_smmu_enable_ats(master, smmu_domain);
-	goto out_unlock;
-
-out_list_del:
-	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_del_init(&master->domain_head);
-	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
-
-out_unlock:
 	mutex_unlock(&arm_smmu_asid_lock);
-	return ret;
+	return 0;
 }
 
 static int arm_smmu_attach_dev_ste(struct device *dev,
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:21 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:21 -0400
Subject: [PATCH v3 15/27] iommu/arm-smmu-v3: Add ssid to struct arm_smmu_master_domain
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <15-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Prepare to allow a S1 domain to be attached to a PASID as well. Keep track
of the SSID the domain is using on each master in the
arm_smmu_master_domain.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 11 +++--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 42 +++++++++++++++----
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  5 ++-
 3 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index c541b94917d036..4644d4601c0830 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -47,13 +47,12 @@ arm_smmu_update_s1_domain_cd_entry(struct arm_smmu_domain *smmu_domain)
 		struct arm_smmu_master *master = master_domain->master;
 		struct arm_smmu_cd *cdptr;
 
-		/* S1 domains only support RID attachment right now */
-		cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
+		cdptr = arm_smmu_get_cd_ptr(master, master_domain->ssid);
 		if (WARN_ON(!cdptr))
 			continue;
 
 		arm_smmu_make_s1_cd(&target_cd, master, smmu_domain);
-		arm_smmu_write_cd_entry(master, IOMMU_NO_PASID, cdptr,
+		arm_smmu_write_cd_entry(master, master_domain->ssid, cdptr,
 					&target_cd);
 	}
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
@@ -283,7 +282,7 @@ static void arm_smmu_mm_arch_invalidate_secondary_tlbs(struct mmu_notifier *mn,
 						    smmu_domain);
 	}
 
-	arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, start, size);
+	arm_smmu_atc_inv_domain_sva(smmu_domain, mm->pasid, start, size);
 }
 
 static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
@@ -319,7 +318,7 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
 	arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_mn->cd->asid);
-	arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, 0, 0);
+	arm_smmu_atc_inv_domain_sva(smmu_domain, mm->pasid, 0, 0);
 
 	smmu_mn->cleared = true;
 	mutex_unlock(&sva_lock);
@@ -398,7 +397,7 @@ static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
 	 */
 	if (!smmu_mn->cleared) {
 		arm_smmu_tlb_inv_asid(smmu_domain->smmu, cd->asid);
-		arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, 0, 0);
+		arm_smmu_atc_inv_domain_sva(smmu_domain, mm->pasid, 0, 0);
 	}
 
 	/* Frees smmu_mn */
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index b50d5cfbef8c71..a2263d9c3658a3 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1967,8 +1967,8 @@ static int arm_smmu_atc_inv_master(struct arm_smmu_master *master)
 	return arm_smmu_cmdq_batch_submit(master->smmu, &cmds);
 }
 
-int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, int ssid,
-			    unsigned long iova, size_t size)
+static int __arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
+				     ioasid_t ssid, unsigned long iova, size_t size)
 {
 	struct arm_smmu_master_domain *master_domain;
 	int i;
@@ -1996,8 +1996,6 @@ int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, int ssid,
 	if (!atomic_read(&smmu_domain->nr_ats_masters))
 		return 0;
 
-	arm_smmu_atc_inv_to_cmd(ssid, iova, size, &cmd);
-
 	cmds.num = 0;
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
@@ -2008,6 +2006,16 @@ int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, int ssid,
 		if (!master->ats_enabled)
 			continue;
 
+		/*
+		 * Non-zero ssid means SVA is co-opting the S1 domain to issue
+		 * invalidations for SVA PASIDs.
+		 */
+		if (ssid != IOMMU_NO_PASID)
+			arm_smmu_atc_inv_to_cmd(ssid, iova, size, &cmd);
+		else
+			arm_smmu_atc_inv_to_cmd(master_domain->ssid, iova, size,
+						&cmd);
+
 		for (i = 0; i < master->num_streams; i++) {
 			cmd.atc.sid = master->streams[i].id;
 			arm_smmu_cmdq_batch_add(smmu_domain->smmu, &cmds, &cmd);
@@ -2018,6 +2026,19 @@ int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, int ssid,
 	return arm_smmu_cmdq_batch_submit(smmu_domain->smmu, &cmds);
 }
 
+static int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
+				   unsigned long iova, size_t size)
+{
+	return __arm_smmu_atc_inv_domain(smmu_domain, IOMMU_NO_PASID, iova,
+					 size);
+}
+
+int arm_smmu_atc_inv_domain_sva(struct arm_smmu_domain *smmu_domain,
+				ioasid_t ssid, unsigned long iova, size_t size)
+{
+	return __arm_smmu_atc_inv_domain(smmu_domain, ssid, iova, size);
+}
+
 /* IO_PGTABLE API */
 static void arm_smmu_tlb_inv_context(void *cookie)
 {
@@ -2039,7 +2060,7 @@ static void arm_smmu_tlb_inv_context(void *cookie)
 		cmd.tlbi.vmid	= smmu_domain->s2_cfg.vmid;
 		arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
 	}
-	arm_smmu_atc_inv_domain(smmu_domain, IOMMU_NO_PASID, 0, 0);
+	arm_smmu_atc_inv_domain(smmu_domain, 0, 0);
 }
 
 static void __arm_smmu_tlb_inv_range(struct arm_smmu_cmdq_ent *cmd,
@@ -2137,7 +2158,7 @@ static void arm_smmu_tlb_inv_range_domain(unsigned long iova, size_t size,
 	 * Unfortunately, this can't be leaf-only since we may have
 	 * zapped an entire table.
 	 */
-	arm_smmu_atc_inv_domain(smmu_domain, IOMMU_NO_PASID, iova, size);
+	arm_smmu_atc_inv_domain(smmu_domain, iova, size);
 }
 
 void arm_smmu_tlb_inv_range_asid(unsigned long iova, size_t size, int asid,
@@ -2474,7 +2495,8 @@ static void arm_smmu_disable_pasid(struct arm_smmu_master *master)
 
 static struct arm_smmu_master_domain *
 arm_smmu_find_master_domain(struct arm_smmu_domain *smmu_domain,
-			    struct arm_smmu_master *master)
+			    struct arm_smmu_master *master,
+			    ioasid_t ssid)
 {
 	struct arm_smmu_master_domain *master_domain;
 
@@ -2482,7 +2504,8 @@ arm_smmu_find_master_domain(struct arm_smmu_domain *smmu_domain,
 
 	list_for_each_entry(master_domain, &smmu_domain->devices,
 			    devices_elm) {
-		if (master_domain->master == master)
+		if (master_domain->master == master &&
+		    master_domain->ssid == ssid)
 			return master_domain;
 	}
 	return NULL;
@@ -2499,7 +2522,8 @@ static void arm_smmu_remove_master_domain(struct arm_smmu_master *master,
 		return;
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	master_domain = arm_smmu_find_master_domain(smmu_domain, master);
+	master_domain = arm_smmu_find_master_domain(smmu_domain, master,
+						    IOMMU_NO_PASID);
 	if (master_domain) {
 		list_del(&master_domain->devices_elm);
 		kfree(master_domain);
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 59bb420af52e28..887669f04b55c1 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -738,6 +738,7 @@ struct arm_smmu_domain {
 struct arm_smmu_master_domain {
 	struct list_head devices_elm;
 	struct arm_smmu_master *master;
+	u16 ssid;
 };
 
 static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
@@ -783,8 +784,8 @@ void arm_smmu_tlb_inv_range_asid(unsigned long iova, size_t size, int asid,
 				 size_t granule, bool leaf,
 				 struct arm_smmu_domain *smmu_domain);
 bool arm_smmu_free_asid(struct arm_smmu_ctx_desc *cd);
-int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, int ssid,
-			    unsigned long iova, size_t size);
+int arm_smmu_atc_inv_domain_sva(struct arm_smmu_domain *smmu_domain,
+				ioasid_t ssid, unsigned long iova, size_t size);
 
 #ifdef CONFIG_ARM_SMMU_V3_SVA
 bool arm_smmu_sva_supported(struct arm_smmu_device *smmu);
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:07 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:07 -0400
Subject: [PATCH v3 01/27] iommu/arm-smmu-v3: Check that the RID domain is S1 in SVA
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <1-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

This code only works if the RID domain is a S1 domain and has already
installed the cdtable.

Add a to_smmu_domain_safe() which does a robust conversion from
struct iommu_domain to the struct arm_smmu_domain.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c |  7 +++++--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c     |  7 +++----
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h     | 14 ++++++++++++++
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 353248ab18e76d..bd0566381c58a9 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -379,8 +379,11 @@ static int __arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm)
 	int ret;
 	struct arm_smmu_bond *bond;
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
-	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
-	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct arm_smmu_domain *smmu_domain =
+		to_smmu_domain_safe(iommu_get_domain_for_dev(dev));
+
+	if (!smmu_domain || smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
+		return -ENODEV;
 
 	if (!master || !master->sva_enabled)
 		return -ENODEV;
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index f3900a3d52524a..0f3bbc4a2addc8 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2486,14 +2486,13 @@ static void arm_smmu_disable_pasid(struct arm_smmu_master *master)
 
 static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 {
-	struct iommu_domain *domain = iommu_get_domain_for_dev(master->dev);
-	struct arm_smmu_domain *smmu_domain;
+	struct arm_smmu_domain *smmu_domain =
+		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
 	unsigned long flags;
 
-	if (!domain || !(domain->type & __IOMMU_DOMAIN_PAGING))
+	if (!smmu_domain)
 		return;
 
-	smmu_domain = to_smmu_domain(domain);
 	arm_smmu_disable_ats(master, smmu_domain);
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 154808f96718df..6f62184eaa2434 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -740,6 +740,20 @@ static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
 	return container_of(dom, struct arm_smmu_domain, domain);
 }
 
+/*
+ * Check that the domain type has an arm_smmu_domain struct. The global static
+ * IDENTITY and BLOCKED domains do not.
+ */
+static inline struct arm_smmu_domain *
+to_smmu_domain_safe(struct iommu_domain *domain)
+{
+	if (!domain)
+		return NULL;
+	if (domain->type & __IOMMU_DOMAIN_PAGING)
+		return to_smmu_domain(domain);
+	return NULL;
+}
+
 extern struct xarray arm_smmu_asid_xa;
 extern struct mutex arm_smmu_asid_lock;
 extern struct arm_smmu_ctx_desc quiet_cd;
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:12 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:12 -0400
Subject: [PATCH v3 06/27] iommu/arm-smmu-v3: Consolidate clearing a CD table entry
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <6-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

A cleared entry is all 0's. Make arm_smmu_clear_cd() do this sequence.

If we are clearing an entry and for some reason it is not already
allocated in the CD table then something has gone wrong.

Move the two SVA flows that clear the CD to this interface.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  9 +++++++--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 20 ++++++++++++++-----
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  2 ++
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index ee3d148aafa26b..521bfa18879f90 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -328,7 +328,7 @@ arm_smmu_mmu_notifier_get(struct arm_smmu_domain *smmu_domain,
 		ret = arm_smmu_write_ctx_desc(master, mm->pasid, cd);
 		if (ret) {
 			list_for_each_entry_from_reverse(master, &smmu_domain->devices, domain_head)
-				arm_smmu_write_ctx_desc(master, mm->pasid, NULL);
+				arm_smmu_clear_cd(master, mm->pasid);
 			break;
 		}
 	}
@@ -352,13 +352,18 @@ static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
 	struct mm_struct *mm = smmu_mn->mn.mm;
 	struct arm_smmu_ctx_desc *cd = smmu_mn->cd;
 	struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
+	struct arm_smmu_master *master;
+	unsigned long flags;
 
 	if (!refcount_dec_and_test(&smmu_mn->refs))
 		return;
 
 	list_del(&smmu_mn->list);
 
-	arm_smmu_update_ctx_desc_devices(smmu_domain, mm->pasid, NULL);
+	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
+	list_for_each_entry(master, &smmu_domain->devices, domain_head)
+		arm_smmu_clear_cd(master, mm->pasid);
+	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
 	/*
 	 * If we went through clear(), we've already invalidated, and no
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 0847ce91c5cc1a..7fcd578b762afe 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1195,6 +1195,19 @@ static void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
 	}
 }
 
+void arm_smmu_clear_cd(struct arm_smmu_master *master, int ssid)
+{
+	struct arm_smmu_cd target = {};
+	struct arm_smmu_cd *cdptr;
+
+	if (!master->cd_table.cdtab)
+		return;
+	cdptr = arm_smmu_get_cd_ptr(master, ssid);
+	if (WARN_ON(!cdptr))
+		return;
+	arm_smmu_write_cd_entry(master, ssid, cdptr, &target);
+}
+
 int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
 			    struct arm_smmu_ctx_desc *cd)
 {
@@ -2622,9 +2635,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	case ARM_SMMU_DOMAIN_S2:
 		arm_smmu_make_s2_domain_ste(&target, master, smmu_domain);
 		arm_smmu_install_ste_for_dev(master, &target);
-		if (master->cd_table.cdtab)
-			arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
-						      NULL);
+		arm_smmu_clear_cd(master, IOMMU_NO_PASID);
 		break;
 	}
 
@@ -2672,8 +2683,7 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 	 * arm_smmu_domain->devices to avoid races updating the same context
 	 * descriptor from arm_smmu_share_asid().
 	 */
-	if (master->cd_table.cdtab)
-		arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, NULL);
+	arm_smmu_clear_cd(master, IOMMU_NO_PASID);
 	return 0;
 }
 
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 24a77e0a97898b..a8e7574ab8e154 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -763,6 +763,8 @@ extern struct xarray arm_smmu_asid_xa;
 extern struct mutex arm_smmu_asid_lock;
 extern struct arm_smmu_ctx_desc quiet_cd;
 
+void arm_smmu_clear_cd(struct arm_smmu_master *master, int ssid);
+
 int arm_smmu_write_ctx_desc(struct arm_smmu_master *smmu_master, int ssid,
 			    struct arm_smmu_ctx_desc *cd);
 void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid);
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:14 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:14 -0400
Subject: [PATCH v3 08/27] iommu/arm-smmu-v3: Move allocation of the cdtable into arm_smmu_get_cd_ptr()
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <8-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

No reason to force callers to do two steps. Make arm_smmu_get_cd_ptr()
able to return an entry in all cases except OOM.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 696f837015771f..a21589f8729176 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -89,6 +89,7 @@ static struct arm_smmu_option_prop arm_smmu_options[] = {
 static void arm_smmu_rmr_install_bypass_ste(struct arm_smmu_device *smmu);
 static int arm_smmu_domain_finalise(struct arm_smmu_domain *smmu_domain,
 				    struct arm_smmu_device *smmu);
+static int arm_smmu_alloc_cd_tables(struct arm_smmu_master *master);
 
 static void parse_driver_options(struct arm_smmu_device *smmu)
 {
@@ -1127,6 +1128,11 @@ struct arm_smmu_cd *arm_smmu_get_cd_ptr(struct arm_smmu_master *master,
 	struct arm_smmu_device *smmu = master->smmu;
 	struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table;
 
+	if (!master->cd_table.cdtab) {
+		if (arm_smmu_alloc_cd_tables(master))
+			return NULL;
+	}
+
 	if (cd_table->s1fmt == STRTAB_STE_0_S1FMT_LINEAR)
 		return (struct arm_smmu_cd *)(cd_table->cdtab +
 					      ssid * CTXDESC_CD_DWORDS);
@@ -2639,12 +2645,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		struct arm_smmu_cd target_cd;
 		struct arm_smmu_cd *cdptr;
 
-		if (!master->cd_table.cdtab) {
-			ret = arm_smmu_alloc_cd_tables(master);
-			if (ret)
-				goto out_list_del;
-		}
-
 		cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
 		if (!cdptr) {
 			ret = -ENOMEM;
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:22 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:22 -0400
Subject: [PATCH v3 16/27] iommu/arm-smmu-v3: Keep track of valid CD entries in the cd_table
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <16-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

We no longer need a master->sva_enable to control what attaches are
allowed.

Instead keep track inside the cd_table how many valid CD entries exist,
and if the RID has a valid entry.

Replace all the attach focused master->sva_enabled tests with a check if
the CD has valid entries (or not). If there are any valid entries then the
CD table must be currently programmed to the STE.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  5 +---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 26 ++++++++++---------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   | 10 +++++++
 3 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 4644d4601c0830..2f818b24d931c2 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -417,9 +417,6 @@ static int __arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm,
 	if (!smmu_domain || smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
 		return -ENODEV;
 
-	if (!master || !master->sva_enabled)
-		return -ENODEV;
-
 	bond = kzalloc(sizeof(*bond), GFP_KERNEL);
 	if (!bond)
 		return -ENOMEM;
@@ -622,7 +619,7 @@ static int arm_smmu_sva_set_dev_pasid(struct iommu_domain *domain,
 	struct mm_struct *mm = domain->mm;
 	struct arm_smmu_cd target;
 
-	if (mm->pasid != id)
+	if (mm->pasid != id || !master->cd_table.used_sid)
 		return -EINVAL;
 
 	if (!arm_smmu_get_cd_ptr(master, id))
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index a2263d9c3658a3..5f6ffd816aaee6 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1186,8 +1186,19 @@ void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
 			     const struct arm_smmu_cd *target)
 {
 	struct arm_smmu_cd target_used;
+	bool cur_valid = cdptr->data[0] & cpu_to_le64(CTXDESC_CD_0_V);
+	bool target_valid = target->data[0] & cpu_to_le64(CTXDESC_CD_0_V);
 	int i;
 
+	if (cur_valid != target_valid) {
+		if (cur_valid)
+			master->cd_table.used_ssids--;
+		else
+			master->cd_table.used_ssids++;
+	}
+	if (ssid == IOMMU_NO_PASID)
+		master->cd_table.used_sid = target_valid;
+
 	arm_smmu_get_cd_used(target, &target_used);
 	/* Masks in arm_smmu_get_cd_used() are up to date */
 	for (i = 0; i != ARRAY_SIZE(target->data); i++)
@@ -2629,16 +2640,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	master = dev_iommu_priv_get(dev);
 	smmu = master->smmu;
 
-	/*
-	 * Checking that SVA is disabled ensures that this device isn't bound to
-	 * any mm, and can be safely detached from its old domain. Bonds cannot
-	 * be removed concurrently since we're holding the group mutex.
-	 */
-	if (arm_smmu_master_sva_enabled(master)) {
-		dev_err(dev, "cannot attach - SVA enabled\n");
-		return -EBUSY;
-	}
-
 	mutex_lock(&smmu_domain->init_mutex);
 
 	if (!smmu_domain->smmu) {
@@ -2654,7 +2655,8 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
 		if (!cdptr)
 			return -ENOMEM;
-	}
+	} else if (arm_smmu_ssids_in_use(&master->cd_table))
+		return -EBUSY;
 
 	/*
 	 * Prevent arm_smmu_share_asid() from trying to change the ASID
@@ -2726,7 +2728,7 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 	struct arm_smmu_domain *old_domain =
 		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
 
-	if (arm_smmu_master_sva_enabled(master))
+	if (arm_smmu_ssids_in_use(&master->cd_table))
 		return -EBUSY;
 
 	/*
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 887669f04b55c1..f72aebaf95f981 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -602,11 +602,21 @@ struct arm_smmu_ctx_desc_cfg {
 	dma_addr_t			cdtab_dma;
 	struct arm_smmu_l1_ctx_desc	*l1_desc;
 	unsigned int			num_l1_ents;
+	unsigned int			used_ssids;
+	bool				used_sid;
 	u8				s1fmt;
 	/* log2 of the maximum number of CDs supported by this table */
 	u8				s1cdmax;
 };
 
+/* True if the cd table has SSIDS > 0 in use. */
+static inline bool arm_smmu_ssids_in_use(struct arm_smmu_ctx_desc_cfg *cd_table)
+{
+	if (cd_table->used_sid)
+		return cd_table->used_ssids > 1;
+	return cd_table->used_ssids;
+}
+
 struct arm_smmu_s2_cfg {
 	u16				vmid;
 };
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:33 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:33 -0400
Subject: [PATCH v3 27/27] iommu/arm-smmu-v3: Allow setting a S1 domain to a PASID
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <27-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

The SVA cleanup made the SSID logic entirely general so all we need to do
is call it with the correct cd table entry for a S1 domain.

This is slightly tricky because of the ASID and how the locking works, the
simple fix is to just update the ASID once we get the right locks.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 45 +++++++++++++++++++--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  2 +-
 2 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 7e5721490b7f4c..5a0f0ea30c3f5b 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1217,8 +1217,6 @@ void arm_smmu_make_s1_cd(struct arm_smmu_cd *target,
 	typeof(&pgtbl_cfg->arm_lpae_s1_cfg.tcr) tcr =
 		&pgtbl_cfg->arm_lpae_s1_cfg.tcr;
 
-	lockdep_assert_held(&master->smmu->asid_lock);
-
 	memset(target, 0, sizeof(*target));
 
 	target->data[0] = cpu_to_le64(
@@ -2685,6 +2683,36 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	return 0;
 }
 
+static int arm_smmu_s1_set_dev_pasid(struct iommu_domain *domain,
+				      struct device *dev, ioasid_t id)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+	struct arm_smmu_device *smmu = master->smmu;
+	struct arm_smmu_cd target_cd;
+	int ret = 0;
+
+	mutex_lock(&smmu_domain->init_mutex);
+	if (!smmu_domain->smmu)
+		ret = arm_smmu_domain_finalise(smmu_domain, smmu);
+	else if (smmu_domain->smmu != smmu)
+		ret = -EINVAL;
+	mutex_unlock(&smmu_domain->init_mutex);
+	if (ret)
+		return ret;
+
+	if (smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
+		return -EINVAL;
+
+	/*
+	 * We can read cd.asid outside the lock because arm_smmu_set_pasid()
+	 * will fix it
+	 */
+	arm_smmu_make_s1_cd(&target_cd, master, smmu_domain);
+	return arm_smmu_set_pasid(master, to_smmu_domain(domain), id,
+				  &target_cd);
+}
+
 static void arm_smmu_update_ste(struct arm_smmu_master *master,
 				struct iommu_domain *sid_domain,
 				bool want_ats)
@@ -2713,7 +2741,7 @@ static void arm_smmu_update_ste(struct arm_smmu_master *master,
 
 int arm_smmu_set_pasid(struct arm_smmu_master *master,
 		       struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
-		       const struct arm_smmu_cd *cd)
+		       struct arm_smmu_cd *cd)
 {
 	struct iommu_domain *sid_domain = iommu_get_domain_for_dev(master->dev);
 	struct arm_smmu_cd *cdptr;
@@ -2737,6 +2765,14 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
 	if (ret)
 		goto out_unlock;
 
+	/*
+	 * We don't want to obtain to the asid_lock too early, so fix up the
+	 * caller set ASID under the lock in case it changed.
+	 */
+	cd->data[0] &= ~cpu_to_le64(CTXDESC_CD_0_ASID);
+	cd->data[0] |= cpu_to_le64(
+		FIELD_PREP(CTXDESC_CD_0_ASID, smmu_domain->cd.asid));
+
 	arm_smmu_write_cd_entry(master, pasid, cdptr, cd);
 	arm_smmu_update_ste(master, sid_domain, state.want_ats);
 
@@ -2754,7 +2790,7 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
 	struct iommu_domain *domain;
 	bool last_ssid = master->cd_table.used_ssids == 1;
 
-	domain = iommu_get_domain_for_dev_pasid(dev, pasid, IOMMU_DOMAIN_SVA);
+	domain = iommu_get_domain_for_dev_pasid(dev, pasid, 0);
 	if (WARN_ON(IS_ERR(domain)) || !domain)
 		return;
 
@@ -3280,6 +3316,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.owner			= THIS_MODULE,
 	.default_domain_ops = &(const struct iommu_domain_ops) {
 		.attach_dev		= arm_smmu_attach_dev,
+		.set_dev_pasid		= arm_smmu_s1_set_dev_pasid,
 		.map_pages		= arm_smmu_map_pages,
 		.unmap_pages		= arm_smmu_unmap_pages,
 		.flush_iotlb_all	= arm_smmu_flush_iotlb_all,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 19628340ccd632..91b23437f41055 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -786,7 +786,7 @@ void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
 
 int arm_smmu_set_pasid(struct arm_smmu_master *master,
 		       struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
-		       const struct arm_smmu_cd *cd);
+		       struct arm_smmu_cd *cd);
 void arm_smmu_remove_pasid(struct arm_smmu_master *master,
 			   struct arm_smmu_domain *smmu_domain, ioasid_t pasid);
 
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:16 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:16 -0400
Subject: [PATCH v3 10/27] iommu/arm-smmu-v3: Move the CD generation for SVA into a function
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <10-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Pull all the calculations for building the CD table entry for a mmu_struct
into arm_smmu_make_sva_cd().

Call it in the two places installing the SVA CD table entry.

Open code the last caller of arm_smmu_update_ctx_desc_devices() and remove
the function.

Remove arm_smmu_write_ctx_desc() since all callers are gone.

Remove quiet_cd since all users are gone, arm_smmu_make_sva_cd() creates
the same value.

The behavior of quiet_cd changes slightly, the old implementation edited
the CD in place to set CTXDESC_CD_0_TCR_EPD0 assuming it was a SVA CD
entry. This version generates a full CD entry with a 0 TTB0 and relies on
arm_smmu_write_cd_entry() to install it hitlessly.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 145 +++++++++++-------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   |  81 +---------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |   5 -
 3 files changed, 95 insertions(+), 136 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 04a807774402b2..1f0940b497f3c6 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -35,25 +35,6 @@ struct arm_smmu_bond {
 
 static DEFINE_MUTEX(sva_lock);
 
-/*
- * Write the CD to the CD tables for all masters that this domain is attached
- * to. Note that this is only used to update existing CD entries in the target
- * CD table, for which it's assumed that arm_smmu_write_ctx_desc can't fail.
- */
-static void arm_smmu_update_ctx_desc_devices(struct arm_smmu_domain *smmu_domain,
-					   int ssid,
-					   struct arm_smmu_ctx_desc *cd)
-{
-	struct arm_smmu_master *master;
-	unsigned long flags;
-
-	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_for_each_entry(master, &smmu_domain->devices, domain_head) {
-		arm_smmu_write_ctx_desc(master, ssid, cd);
-	}
-	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
-}
-
 static void
 arm_smmu_update_s1_domain_cd_entry(struct arm_smmu_domain *smmu_domain)
 {
@@ -129,11 +110,76 @@ arm_smmu_share_asid(struct mm_struct *mm, u16 asid)
 	return NULL;
 }
 
+static u64 page_size_to_cd(void)
+{
+	static_assert(PAGE_SIZE == SZ_4K || PAGE_SIZE == SZ_16K ||
+		      PAGE_SIZE == SZ_64K);
+	if (PAGE_SIZE == SZ_64K)
+		return ARM_LPAE_TCR_TG0_64K;
+	if (PAGE_SIZE == SZ_16K)
+		return ARM_LPAE_TCR_TG0_16K;
+	return ARM_LPAE_TCR_TG0_4K;
+}
+
+static void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
+				 struct arm_smmu_master *master,
+				 struct mm_struct *mm, u16 asid)
+{
+	u64 par;
+
+	memset(target, 0, sizeof(*target));
+
+	par = cpuid_feature_extract_unsigned_field(
+		read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1),
+		ID_AA64MMFR0_EL1_PARANGE_SHIFT);
+
+	target->data[0] = cpu_to_le64(
+		CTXDESC_CD_0_TCR_EPD1 |
+#ifdef __BIG_ENDIAN
+		CTXDESC_CD_0_ENDI |
+#endif
+		CTXDESC_CD_0_V |
+		FIELD_PREP(CTXDESC_CD_0_TCR_IPS, par) |
+		CTXDESC_CD_0_AA64 |
+		(master->stall_enabled ? CTXDESC_CD_0_S : 0) |
+		CTXDESC_CD_0_R |
+		CTXDESC_CD_0_A |
+		CTXDESC_CD_0_ASET |
+		FIELD_PREP(CTXDESC_CD_0_ASID, asid));
+
+	/*
+	 * If no MM is passed then this creates a SVA entry that faults
+	 * everything. arm_smmu_write_cd_entry() can hitlessly go between these
+	 * two entries types since TTB0 is ignored by HW when EPD0 is set.
+	 */
+	if (mm) {
+		target->data[0] |= cpu_to_le64(
+			FIELD_PREP(CTXDESC_CD_0_TCR_T0SZ,
+				   64ULL - vabits_actual) |
+			FIELD_PREP(CTXDESC_CD_0_TCR_TG0, page_size_to_cd()) |
+			FIELD_PREP(CTXDESC_CD_0_TCR_IRGN0,
+				   ARM_LPAE_TCR_RGN_WBWA) |
+			FIELD_PREP(CTXDESC_CD_0_TCR_ORGN0,
+				   ARM_LPAE_TCR_RGN_WBWA) |
+			FIELD_PREP(CTXDESC_CD_0_TCR_SH0, ARM_LPAE_TCR_SH_IS));
+
+		target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
+					      CTXDESC_CD_1_TTB0_MASK);
+	} else {
+		target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_EPD0);
+	}
+
+	/*
+	 * MAIR value is pretty much constant and global, so we can just get it
+	 * from the current CPU register
+	 */
+	target->data[3] = cpu_to_le64(read_sysreg(mair_el1));
+}
+
 static struct arm_smmu_ctx_desc *arm_smmu_alloc_shared_cd(struct mm_struct *mm)
 {
 	u16 asid;
 	int err = 0;
-	u64 tcr, par, reg;
 	struct arm_smmu_ctx_desc *cd;
 	struct arm_smmu_ctx_desc *ret = NULL;
 
@@ -167,39 +213,6 @@ static struct arm_smmu_ctx_desc *arm_smmu_alloc_shared_cd(struct mm_struct *mm)
 	if (err)
 		goto out_free_asid;
 
-	tcr = FIELD_PREP(CTXDESC_CD_0_TCR_T0SZ, 64ULL - vabits_actual) |
-	      FIELD_PREP(CTXDESC_CD_0_TCR_IRGN0, ARM_LPAE_TCR_RGN_WBWA) |
-	      FIELD_PREP(CTXDESC_CD_0_TCR_ORGN0, ARM_LPAE_TCR_RGN_WBWA) |
-	      FIELD_PREP(CTXDESC_CD_0_TCR_SH0, ARM_LPAE_TCR_SH_IS) |
-	      CTXDESC_CD_0_TCR_EPD1 | CTXDESC_CD_0_AA64;
-
-	switch (PAGE_SIZE) {
-	case SZ_4K:
-		tcr |= FIELD_PREP(CTXDESC_CD_0_TCR_TG0, ARM_LPAE_TCR_TG0_4K);
-		break;
-	case SZ_16K:
-		tcr |= FIELD_PREP(CTXDESC_CD_0_TCR_TG0, ARM_LPAE_TCR_TG0_16K);
-		break;
-	case SZ_64K:
-		tcr |= FIELD_PREP(CTXDESC_CD_0_TCR_TG0, ARM_LPAE_TCR_TG0_64K);
-		break;
-	default:
-		WARN_ON(1);
-		err = -EINVAL;
-		goto out_free_asid;
-	}
-
-	reg = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
-	par = cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR0_EL1_PARANGE_SHIFT);
-	tcr |= FIELD_PREP(CTXDESC_CD_0_TCR_IPS, par);
-
-	cd->ttbr = virt_to_phys(mm->pgd);
-	cd->tcr = tcr;
-	/*
-	 * MAIR value is pretty much constant and global, so we can just get it
-	 * from the current CPU register
-	 */
-	cd->mair = read_sysreg(mair_el1);
 	cd->asid = asid;
 	cd->mm = mm;
 
@@ -276,6 +289,8 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 {
 	struct arm_smmu_mmu_notifier *smmu_mn = mn_to_smmu(mn);
 	struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
+	struct arm_smmu_master *master;
+	unsigned long flags;
 
 	mutex_lock(&sva_lock);
 	if (smmu_mn->cleared) {
@@ -287,7 +302,18 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 	 * DMA may still be running. Keep the cd valid to avoid C_BAD_CD events,
 	 * but disable translation.
 	 */
-	arm_smmu_update_ctx_desc_devices(smmu_domain, mm->pasid, &quiet_cd);
+	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
+	list_for_each_entry(master, &smmu_domain->devices, domain_head) {
+		struct arm_smmu_cd target;
+		struct arm_smmu_cd *cdptr;
+
+		cdptr = arm_smmu_get_cd_ptr(master, mm->pasid);
+		if (WARN_ON(!cdptr))
+			continue;
+		arm_smmu_make_sva_cd(&target, master, NULL, smmu_mn->cd->asid);
+		arm_smmu_write_cd_entry(master, mm->pasid, cdptr, &target);
+	}
+	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
 	arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_mn->cd->asid);
 	arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, 0, 0);
@@ -348,12 +374,19 @@ arm_smmu_mmu_notifier_get(struct arm_smmu_domain *smmu_domain,
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
 	list_for_each_entry(master, &smmu_domain->devices, domain_head) {
-		ret = arm_smmu_write_ctx_desc(master, mm->pasid, cd);
-		if (ret) {
+		struct arm_smmu_cd target;
+		struct arm_smmu_cd *cdptr;
+
+		cdptr = arm_smmu_get_cd_ptr(master, mm->pasid);
+		if (!cdptr) {
+			ret = -ENOMEM;
 			list_for_each_entry_from_reverse(master, &smmu_domain->devices, domain_head)
 				arm_smmu_clear_cd(master, mm->pasid);
 			break;
 		}
+
+		arm_smmu_make_sva_cd(&target, master, mm, cd->asid);
+		arm_smmu_write_cd_entry(master, mm->pasid, cdptr, &target);
 	}
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 	if (ret)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index eea561edaee908..824e725f905d71 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -74,12 +74,6 @@ struct arm_smmu_option_prop {
 DEFINE_XARRAY_ALLOC1(arm_smmu_asid_xa);
 DEFINE_MUTEX(arm_smmu_asid_lock);
 
-/*
- * Special value used by SVA when a process dies, to quiesce a CD without
- * disabling it.
- */
-struct arm_smmu_ctx_desc quiet_cd = { 0 };
-
 static struct arm_smmu_option_prop arm_smmu_options[] = {
 	{ ARM_SMMU_OPT_SKIP_PREFETCH, "hisilicon,broken-prefetch-cmd" },
 	{ ARM_SMMU_OPT_PAGE0_REGS_ONLY, "cavium,cn9900-broken-page1-regspace"},
@@ -1115,7 +1109,7 @@ static void arm_smmu_write_cd_l1_desc(__le64 *dst,
 	u64 val = (l1_desc->l2ptr_dma & CTXDESC_L1_DESC_L2PTR_MASK) |
 		  CTXDESC_L1_DESC_V;
 
-	/* See comment in arm_smmu_write_ctx_desc() */
+	/* The HW has 64 bit atomicity with stores to the L2 CD table */
 	WRITE_ONCE(*dst, cpu_to_le64(val));
 }
 
@@ -1192,8 +1186,12 @@ void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
 			     const struct arm_smmu_cd *target)
 {
 	struct arm_smmu_cd target_used;
+	int i;
 
 	arm_smmu_get_cd_used(target, &target_used);
+	/* Masks in arm_smmu_get_cd_used() are up to date */
+	for (i = 0; i != ARRAY_SIZE(target->data); i++)
+		WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);
 	while (true) {
 		if (arm_smmu_write_cd_step(cdptr, target, &target_used))
 			break;
@@ -1240,72 +1238,6 @@ void arm_smmu_clear_cd(struct arm_smmu_master *master, int ssid)
 	arm_smmu_write_cd_entry(master, ssid, cdptr, &target);
 }
 
-int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
-			    struct arm_smmu_ctx_desc *cd)
-{
-	/*
-	 * This function handles the following cases:
-	 *
-	 * (1) Install primary CD, for normal DMA traffic (SSID = IOMMU_NO_PASID = 0).
-	 * (2) Install a secondary CD, for SID+SSID traffic.
-	 * (3) Update ASID of a CD. Atomically write the first 64 bits of the
-	 *     CD, then invalidate the old entry and mappings.
-	 * (4) Quiesce the context without clearing the valid bit. Disable
-	 *     translation, and ignore any translation fault.
-	 * (5) Remove a secondary CD.
-	 */
-	u64 val;
-	bool cd_live;
-	struct arm_smmu_cd target;
-	struct arm_smmu_cd *cdptr = &target;
-	struct arm_smmu_cd *cd_table_entry;
-	struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table;
-
-	if (WARN_ON(ssid >= (1 << cd_table->s1cdmax)))
-		return -E2BIG;
-
-	cd_table_entry = arm_smmu_get_cd_ptr(master, ssid);
-	if (!cd_table_entry)
-		return -ENOMEM;
-
-	target = *cd_table_entry;
-	val = le64_to_cpu(cdptr->data[0]);
-	cd_live = !!(val & CTXDESC_CD_0_V);
-
-	if (!cd) { /* (5) */
-		val = 0;
-	} else if (cd == &quiet_cd) { /* (4) */
-		val |= CTXDESC_CD_0_TCR_EPD0;
-	} else if (cd_live) { /* (3) */
-		val &= ~CTXDESC_CD_0_ASID;
-		val |= FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid);
-		/*
-		 * Until CD+TLB invalidation, both ASIDs may be used for tagging
-		 * this substream's traffic
-		 */
-	} else { /* (1) and (2) */
-		cdptr->data[1] = cpu_to_le64(cd->ttbr & CTXDESC_CD_1_TTB0_MASK);
-		cdptr->data[2] = 0;
-		cdptr->data[3] = cpu_to_le64(cd->mair);
-
-		val = cd->tcr |
-#ifdef __BIG_ENDIAN
-			CTXDESC_CD_0_ENDI |
-#endif
-			CTXDESC_CD_0_R | CTXDESC_CD_0_A |
-			(cd->mm ? 0 : CTXDESC_CD_0_ASET) |
-			CTXDESC_CD_0_AA64 |
-			FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid) |
-			CTXDESC_CD_0_V;
-
-		if (cd_table->stall_enabled)
-			val |= CTXDESC_CD_0_S;
-	}
-	cdptr->data[0] = cpu_to_le64(val);
-	arm_smmu_write_cd_entry(master, ssid, cd_table_entry, &target);
-	return 0;
-}
-
 static int arm_smmu_alloc_cd_tables(struct arm_smmu_master *master)
 {
 	int ret;
@@ -1314,7 +1246,6 @@ static int arm_smmu_alloc_cd_tables(struct arm_smmu_master *master)
 	struct arm_smmu_device *smmu = master->smmu;
 	struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table;
 
-	cd_table->stall_enabled = master->stall_enabled;
 	cd_table->s1cdmax = master->ssid_bits;
 	max_contexts = 1 << cd_table->s1cdmax;
 
@@ -1412,7 +1343,7 @@ arm_smmu_write_strtab_l1_desc(__le64 *dst, struct arm_smmu_strtab_l1_desc *desc)
 	val |= FIELD_PREP(STRTAB_L1_DESC_SPAN, desc->span);
 	val |= desc->l2ptr_dma & STRTAB_L1_DESC_L2PTR_MASK;
 
-	/* See comment in arm_smmu_write_ctx_desc() */
+	/* The HW has 64 bit atomicity with stores to the L2 STE table */
 	WRITE_ONCE(*dst, cpu_to_le64(val));
 }
 
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 950f5a08acda6d..6ed7645938a686 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -608,8 +608,6 @@ struct arm_smmu_ctx_desc_cfg {
 	u8				s1fmt;
 	/* log2 of the maximum number of CDs supported by this table */
 	u8				s1cdmax;
-	/* Whether CD entries in this table have the stall bit set. */
-	u8				stall_enabled:1;
 };
 
 struct arm_smmu_s2_cfg {
@@ -761,7 +759,6 @@ to_smmu_domain_safe(struct iommu_domain *domain)
 
 extern struct xarray arm_smmu_asid_xa;
 extern struct mutex arm_smmu_asid_lock;
-extern struct arm_smmu_ctx_desc quiet_cd;
 
 void arm_smmu_clear_cd(struct arm_smmu_master *master, int ssid);
 struct arm_smmu_cd *arm_smmu_get_cd_ptr(struct arm_smmu_master *master,
@@ -773,8 +770,6 @@ void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
 			     struct arm_smmu_cd *cdptr,
 			     const struct arm_smmu_cd *target);
 
-int arm_smmu_write_ctx_desc(struct arm_smmu_master *smmu_master, int ssid,
-			    struct arm_smmu_ctx_desc *cd);
 void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid);
 void arm_smmu_tlb_inv_range_asid(unsigned long iova, size_t size, int asid,
 				 size_t granule, bool leaf,
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:09 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:09 -0400
Subject: [PATCH v3 03/27] iommu/arm-smmu-v3: Do not ATC invalidate the entire domain
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <3-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

At this point we know which master we are going to change the PCI config
on, this is the only device we need to invalidate. Switch
arm_smmu_atc_inv_domain() for arm_smmu_atc_inv_master().

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 0f3bbc4a2addc8..39e010c838b1c2 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2416,7 +2416,10 @@ static void arm_smmu_enable_ats(struct arm_smmu_master *master,
 	pdev = to_pci_dev(master->dev);
 
 	atomic_inc(&smmu_domain->nr_ats_masters);
-	arm_smmu_atc_inv_domain(smmu_domain, IOMMU_NO_PASID, 0, 0);
+	/*
+	 * ATC invalidation of PASID 0 causes the entire ATC to be flushed.
+	 */
+	arm_smmu_atc_inv_master(master);
 	if (pci_enable_ats(pdev, stu))
 		dev_err(master->dev, "Failed to enable ATS (STU %zu)\n", stu);
 }
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:31 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:31 -0400
Subject: [PATCH v3 25/27] iommu/arm-smmu-v3: Allow IDENTITY/BLOCKED to be set while PASID is used
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <25-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

The HW supports this, use the S1DSS bits to configure the behavior
of SSID=0 which is the RID's translation.

If SSID's are currently being used in the CD table then just update the
S1DSS bits in the STE, remove the master_domain and leave ATS alone.

For iommufd the driver design has a small problem that all the unused CD
table entries are set with V=0 which will generate an event if VFIO
userspace tries to use the CD entry. This patch extends this problem to
include the RID as well if PASID is being used.

For BLOCKED with used PASIDs the
F_STREAM_DISABLED (STRTAB_STE_1_S1DSS_TERMINATE) event is generated on
untagged traffic and a substream CD table entry with V=0 (removed pasid)
will generate C_BAD_CD. Arguably there is no advantage to using S1DSS over
the CD entry 0 with V=0.

As we don't yet support PASID in iommufd this is a problem to resolve
later, possibly by using EPD0 for unused CD table entries instead of V=0,
and not using S1DSS for BLOCKED.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 66 ++++++++++++++-------
 1 file changed, 43 insertions(+), 23 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 3907cf4db3efe1..f97fac1de0b103 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1485,7 +1485,7 @@ static void arm_smmu_make_bypass_ste(struct arm_smmu_ste *target)
 static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
 				      struct arm_smmu_master *master,
 				      struct arm_smmu_ctx_desc_cfg *cd_table,
-				      bool ats_enabled)
+				      bool ats_enabled, unsigned int s1dss)
 {
 	struct arm_smmu_device *smmu = master->smmu;
 
@@ -1498,7 +1498,7 @@ static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
 		FIELD_PREP(STRTAB_STE_0_S1CDMAX, cd_table->s1cdmax));
 
 	target->data[1] = cpu_to_le64(
-		FIELD_PREP(STRTAB_STE_1_S1DSS, STRTAB_STE_1_S1DSS_SSID0) |
+		FIELD_PREP(STRTAB_STE_1_S1DSS, s1dss) |
 		FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) |
 		FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) |
 		FIELD_PREP(STRTAB_STE_1_S1CSH, ARM_SMMU_SH_ISH) |
@@ -1511,7 +1511,11 @@ static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
 		FIELD_PREP(STRTAB_STE_1_STRW,
 			   (smmu->features & ARM_SMMU_FEAT_E2H) ?
 				   STRTAB_STE_1_STRW_EL2 :
-				   STRTAB_STE_1_STRW_NSEL1));
+				   STRTAB_STE_1_STRW_NSEL1) |
+		FIELD_PREP(STRTAB_STE_1_SHCFG,
+			   s1dss == STRTAB_STE_1_S1DSS_BYPASS ?
+				   STRTAB_STE_1_SHCFG_INCOMING :
+				   0));
 }
 
 static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
@@ -2656,7 +2660,8 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		arm_smmu_write_cd_entry(master, IOMMU_NO_PASID, cdptr,
 					&target_cd);
 		arm_smmu_make_cdtable_ste(&target, master, &master->cd_table,
-					  state.want_ats);
+					  state.want_ats,
+					  STRTAB_STE_1_S1DSS_SSID0);
 		arm_smmu_install_ste_for_dev(master, &target);
 		break;
 	}
@@ -2727,16 +2732,14 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
 	mutex_unlock(&master->smmu->asid_lock);
 }
 
-static int arm_smmu_attach_dev_ste(struct device *dev,
-				   struct arm_smmu_ste *ste)
+static void arm_smmu_attach_dev_ste(struct device *dev,
+				    struct arm_smmu_ste *ste,
+				    unsigned int s1dss)
 {
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
 	struct arm_smmu_domain *old_domain =
 		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
 
-	if (arm_smmu_ssids_in_use(&master->cd_table))
-		return -EBUSY;
-
 	/*
 	 * Do not allow any ASID to be changed while are working on the STE,
 	 * otherwise we could miss invalidations.
@@ -2744,19 +2747,34 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 	mutex_lock(&master->smmu->asid_lock);
 
 	/*
-	 * The SMMU does not support enabling ATS with bypass/abort. When the
-	 * STE is in bypass (STE.Config[2:0] == 0b100), ATS Translation Requests
-	 * and Translated transactions are denied as though ATS is disabled for
-	 * the stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
-	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
+	 * If the CD table is not in use we can use the provided STE, otherwise
+	 * we use a cdtable STE with the provided S1DSS.
 	 */
-	if (master->ats_enabled) {
-		pci_disable_ats(to_pci_dev(master->dev));
+	if (!arm_smmu_ssids_in_use(&master->cd_table)) {
 		/*
-		 * Ensure ATS is disabled at the endpoint before we issue the
-		 * ATC invalidation via the SMMU.
+		 * The SMMU does not support enabling ATS with bypass/abort.
+		 * When the STE is in bypass (STE.Config[2:0] == 0b100), ATS
+		 * Translation Requests and Translated transactions are denied
+		 * as though ATS is disabled for the stream (STE.EATS == 0b00),
+		 * causing F_BAD_ATS_TREQ and F_TRANSL_FORBIDDEN events
+		 * (IHI0070Ea 5.2 Stream Table Entry).
 		 */
-		wmb();
+		if (master->ats_enabled) {
+			pci_disable_ats(to_pci_dev(master->dev));
+			/*
+			 * Ensure ATS is disabled at the endpoint before we
+			 * issue the ATC invalidation via the SMMU.
+			 */
+			wmb();
+		}
+	} else {
+		/*
+		 * It also does not support ATS with S1DSS = bypass but we have
+		 * no idea what the other PASIDs are doing so it has to be left
+		 * on.
+		 */
+		arm_smmu_make_cdtable_ste(ste, master, &master->cd_table,
+					  master->ats_enabled, s1dss);
 	}
 
 	arm_smmu_install_ste_for_dev(master, ste);
@@ -2768,7 +2786,8 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 					      IOMMU_NO_PASID);
 	}
 
-	master->ats_enabled = false;
+	if (!arm_smmu_ssids_in_use(&master->cd_table))
+		master->ats_enabled = false;
 
 	mutex_unlock(&master->smmu->asid_lock);
 
@@ -2778,7 +2797,6 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 	 * descriptor from arm_smmu_share_asid().
 	 */
 	arm_smmu_clear_cd(master, IOMMU_NO_PASID);
-	return 0;
 }
 
 static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
@@ -2787,7 +2805,8 @@ static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
 	struct arm_smmu_ste ste;
 
 	arm_smmu_make_bypass_ste(&ste);
-	return arm_smmu_attach_dev_ste(dev, &ste);
+	arm_smmu_attach_dev_ste(dev, &ste, STRTAB_STE_1_S1DSS_BYPASS);
+	return 0;
 }
 
 static const struct iommu_domain_ops arm_smmu_identity_ops = {
@@ -2805,7 +2824,8 @@ static int arm_smmu_attach_dev_blocked(struct iommu_domain *domain,
 	struct arm_smmu_ste ste;
 
 	arm_smmu_make_abort_ste(&ste);
-	return arm_smmu_attach_dev_ste(dev, &ste);
+	arm_smmu_attach_dev_ste(dev, &ste, STRTAB_STE_1_S1DSS_TERMINATE);
+	return 0;
 }
 
 static const struct iommu_domain_ops arm_smmu_blocked_ops = {
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:17 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:17 -0400
Subject: [PATCH v3 11/27] iommu/arm-smmu-v3: Lift CD programming out of the SVA notifier code
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <11-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

ops->set_dev_pasid()/ops->remove_dev_pasid() should work on a single CD
table entry, the one that was actually passed in to the function. The
current iterating over the master's list is a hold over from the prior
design where the CD table was part of the S1 domain.

Lift this code up and out so that we setup the CD only once for the
correct thing.

The SVA code "works" under a single configuration:
 - The RID domain is a S1 domain
 - The programmed PASID is the mm->pasid
 - Nothing changes while SVA is running (sva_enable)

Invalidation will still iterate over the S1 domain's master list. That
remains OK after this change, we may do harmless extra ATS invalidations
for PASIDs that don't need it.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 55 ++++++-------------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 24 ++++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  6 ++
 3 files changed, 48 insertions(+), 37 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 1f0940b497f3c6..29469073fc53fe 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -339,10 +339,8 @@ arm_smmu_mmu_notifier_get(struct arm_smmu_domain *smmu_domain,
 			  struct mm_struct *mm)
 {
 	int ret;
-	unsigned long flags;
 	struct arm_smmu_ctx_desc *cd;
 	struct arm_smmu_mmu_notifier *smmu_mn;
-	struct arm_smmu_master *master;
 
 	list_for_each_entry(smmu_mn, &smmu_domain->mmu_notifiers, list) {
 		if (smmu_mn->mn.mm == mm) {
@@ -372,32 +370,9 @@ arm_smmu_mmu_notifier_get(struct arm_smmu_domain *smmu_domain,
 		goto err_free_cd;
 	}
 
-	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_for_each_entry(master, &smmu_domain->devices, domain_head) {
-		struct arm_smmu_cd target;
-		struct arm_smmu_cd *cdptr;
-
-		cdptr = arm_smmu_get_cd_ptr(master, mm->pasid);
-		if (!cdptr) {
-			ret = -ENOMEM;
-			list_for_each_entry_from_reverse(master, &smmu_domain->devices, domain_head)
-				arm_smmu_clear_cd(master, mm->pasid);
-			break;
-		}
-
-		arm_smmu_make_sva_cd(&target, master, mm, cd->asid);
-		arm_smmu_write_cd_entry(master, mm->pasid, cdptr, &target);
-	}
-	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
-	if (ret)
-		goto err_put_notifier;
-
 	list_add(&smmu_mn->list, &smmu_domain->mmu_notifiers);
 	return smmu_mn;
 
-err_put_notifier:
-	/* Frees smmu_mn */
-	mmu_notifier_put(&smmu_mn->mn);
 err_free_cd:
 	arm_smmu_free_shared_cd(cd);
 	return ERR_PTR(ret);
@@ -408,19 +383,12 @@ static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
 	struct mm_struct *mm = smmu_mn->mn.mm;
 	struct arm_smmu_ctx_desc *cd = smmu_mn->cd;
 	struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
-	struct arm_smmu_master *master;
-	unsigned long flags;
 
 	if (!refcount_dec_and_test(&smmu_mn->refs))
 		return;
 
 	list_del(&smmu_mn->list);
 
-	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_for_each_entry(master, &smmu_domain->devices, domain_head)
-		arm_smmu_clear_cd(master, mm->pasid);
-	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
-
 	/*
 	 * If we went through clear(), we've already invalidated, and no
 	 * new TLB entry can have been formed.
@@ -435,7 +403,8 @@ static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
 	arm_smmu_free_shared_cd(cd);
 }
 
-static int __arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm)
+static int __arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm,
+			       struct arm_smmu_cd *target)
 {
 	int ret;
 	struct arm_smmu_bond *bond;
@@ -462,6 +431,7 @@ static int __arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm)
 	}
 
 	list_add(&bond->list, &master->bonds);
+	arm_smmu_make_sva_cd(target, master, mm, bond->smmu_mn->cd->asid);
 	return 0;
 
 err_free_bond:
@@ -624,6 +594,8 @@ void arm_smmu_sva_remove_dev_pasid(struct iommu_domain *domain,
 	struct arm_smmu_bond *bond = NULL, *t;
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
 
+	arm_smmu_remove_pasid(master, to_smmu_domain(domain), id);
+
 	mutex_lock(&sva_lock);
 	list_for_each_entry(t, &master->bonds, list) {
 		if (t->mm == mm) {
@@ -643,17 +615,26 @@ void arm_smmu_sva_remove_dev_pasid(struct iommu_domain *domain,
 static int arm_smmu_sva_set_dev_pasid(struct iommu_domain *domain,
 				      struct device *dev, ioasid_t id)
 {
+	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
 	int ret = 0;
 	struct mm_struct *mm = domain->mm;
+	struct arm_smmu_cd target;
 
 	if (mm->pasid != id)
 		return -EINVAL;
 
-	mutex_lock(&sva_lock);
-	ret = __arm_smmu_sva_bind(dev, mm);
-	mutex_unlock(&sva_lock);
+	if (!arm_smmu_get_cd_ptr(master, id))
+		return -ENOMEM;
 
-	return ret;
+	mutex_lock(&sva_lock);
+	ret = __arm_smmu_sva_bind(dev, mm, &target);
+	mutex_unlock(&sva_lock);
+	if (ret)
+		return ret;
+
+	/* This cannot fail since we preallocated the cdptr */
+	arm_smmu_set_pasid(master, to_smmu_domain(domain), id, &target);
+	return 0;
 }
 
 static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 824e725f905d71..27c0a468958dc0 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2601,6 +2601,30 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	return 0;
 }
 
+int arm_smmu_set_pasid(struct arm_smmu_master *master,
+		       struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
+		       const struct arm_smmu_cd *cd)
+{
+	struct arm_smmu_domain *sid_smmu_domain =
+		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
+	struct arm_smmu_cd *cdptr;
+
+	if (!sid_smmu_domain || sid_smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
+		return -ENODEV;
+
+	cdptr = arm_smmu_get_cd_ptr(master, pasid);
+	if (!cdptr)
+		return -ENOMEM;
+	arm_smmu_write_cd_entry(master, pasid, cdptr, cd);
+	return 0;
+}
+
+void arm_smmu_remove_pasid(struct arm_smmu_master *master,
+			   struct arm_smmu_domain *smmu_domain, ioasid_t pasid)
+{
+	arm_smmu_clear_cd(master, pasid);
+}
+
 static int arm_smmu_attach_dev_ste(struct device *dev,
 				   struct arm_smmu_ste *ste)
 {
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 6ed7645938a686..1c756803b7f963 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -770,6 +770,12 @@ void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
 			     struct arm_smmu_cd *cdptr,
 			     const struct arm_smmu_cd *target);
 
+int arm_smmu_set_pasid(struct arm_smmu_master *master,
+		       struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
+		       const struct arm_smmu_cd *cd);
+void arm_smmu_remove_pasid(struct arm_smmu_master *master,
+			   struct arm_smmu_domain *smmu_domain, ioasid_t pasid);
+
 void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid);
 void arm_smmu_tlb_inv_range_asid(unsigned long iova, size_t size, int asid,
 				 size_t granule, bool leaf,
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:23 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:23 -0400
Subject: [PATCH v3 17/27] iommu/arm-smmu-v3: Thread SSID through the arm_smmu_attach_*() interface
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <17-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Allow creating and managing arm_smmu_mater_domain's with a non-zero SSID
through the arm_smmu_attach_*() family of functions. This triggers ATC
invalidation for the correct SSID in PASID cases and tracks the
per-attachment SSID in the struct arm_smmu_master_domain.

Generalize arm_smmu_attach_remove() to be able to remove SSID's as well by
ensuring the ATC for the PASID is flushed properly.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 33 ++++++++++++---------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 5f6ffd816aaee6..a6cd4699ddcc76 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1961,13 +1961,14 @@ arm_smmu_atc_inv_to_cmd(int ssid, unsigned long iova, size_t size,
 	cmd->atc.size	= log2_span;
 }
 
-static int arm_smmu_atc_inv_master(struct arm_smmu_master *master)
+static int arm_smmu_atc_inv_master(struct arm_smmu_master *master,
+				   ioasid_t ssid)
 {
 	int i;
 	struct arm_smmu_cmdq_ent cmd;
 	struct arm_smmu_cmdq_batch cmds;
 
-	arm_smmu_atc_inv_to_cmd(IOMMU_NO_PASID, 0, 0, &cmd);
+	arm_smmu_atc_inv_to_cmd(ssid, 0, 0, &cmd);
 
 	cmds.num = 0;
 	for (i = 0; i < master->num_streams; i++) {
@@ -2452,7 +2453,7 @@ static void arm_smmu_enable_ats(struct arm_smmu_master *master)
 	/*
 	 * ATC invalidation of PASID 0 causes the entire ATC to be flushed.
 	 */
-	arm_smmu_atc_inv_master(master);
+	arm_smmu_atc_inv_master(master, IOMMU_NO_PASID);
 	if (pci_enable_ats(pdev, stu))
 		dev_err(master->dev, "Failed to enable ATS (STU %zu)\n", stu);
 }
@@ -2523,7 +2524,8 @@ arm_smmu_find_master_domain(struct arm_smmu_domain *smmu_domain,
 }
 
 static void arm_smmu_remove_master_domain(struct arm_smmu_master *master,
-					  struct arm_smmu_domain *smmu_domain)
+					  struct arm_smmu_domain *smmu_domain,
+					  ioasid_t ssid)
 {
 	struct arm_smmu_master_domain *master_domain;
 	unsigned long flags;
@@ -2533,8 +2535,7 @@ static void arm_smmu_remove_master_domain(struct arm_smmu_master *master,
 		return;
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	master_domain = arm_smmu_find_master_domain(smmu_domain, master,
-						    IOMMU_NO_PASID);
+	master_domain = arm_smmu_find_master_domain(smmu_domain, master, ssid);
 	if (master_domain) {
 		list_del(&master_domain->devices_elm);
 		kfree(master_domain);
@@ -2554,7 +2555,7 @@ struct attach_state {
  */
 static int arm_smmu_attach_prepare(struct arm_smmu_master *master,
 				   struct arm_smmu_domain *smmu_domain,
-				   struct attach_state *state)
+				   ioasid_t ssid, struct attach_state *state)
 {
 	struct arm_smmu_master_domain *master_domain;
 	unsigned long flags;
@@ -2570,6 +2571,7 @@ static int arm_smmu_attach_prepare(struct arm_smmu_master *master,
 	if (!master_domain)
 		return -ENOMEM;
 	master_domain->master = master;
+	master_domain->ssid = ssid;
 
 	state->want_ats = arm_smmu_ats_supported(master);
 
@@ -2600,7 +2602,7 @@ static int arm_smmu_attach_prepare(struct arm_smmu_master *master,
  * smmu_domain->devices list.
  */
 static void arm_smmu_attach_commit(struct arm_smmu_master *master,
-				   struct attach_state *state)
+				   ioasid_t ssid, struct attach_state *state)
 {
 	lockdep_assert_held(&arm_smmu_asid_lock);
 
@@ -2615,12 +2617,13 @@ static void arm_smmu_attach_commit(struct arm_smmu_master *master,
 		 * SMMU is translating for the new domain and both the old&new
 		 * domain will issue invalidations.
 		 */
-		arm_smmu_atc_inv_master(master);
+		arm_smmu_atc_inv_master(master, ssid);
 	}
 
 	arm_smmu_remove_master_domain(
 		master,
-		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev)));
+		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev)),
+		ssid);
 }
 
 static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
@@ -2666,7 +2669,8 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	 */
 	mutex_lock(&arm_smmu_asid_lock);
 
-	ret = arm_smmu_attach_prepare(master, smmu_domain, &state);
+	ret = arm_smmu_attach_prepare(master, smmu_domain, IOMMU_NO_PASID,
+				      &state);
 	if (ret) {
 		mutex_unlock(&arm_smmu_asid_lock);
 		return ret;
@@ -2692,7 +2696,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		break;
 	}
 
-	arm_smmu_attach_commit(master, &state);
+	arm_smmu_attach_commit(master, IOMMU_NO_PASID, &state);
 	mutex_unlock(&arm_smmu_asid_lock);
 	return 0;
 }
@@ -2757,8 +2761,9 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 
 	if (old_domain) {
 		if (master->ats_enabled)
-			arm_smmu_atc_inv_master(master);
-		arm_smmu_remove_master_domain(master, old_domain);
+			arm_smmu_atc_inv_master(master, IOMMU_NO_PASID);
+		arm_smmu_remove_master_domain(master, old_domain,
+					      IOMMU_NO_PASID);
 	}
 
 	master->ats_enabled = false;
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:25 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:25 -0400
Subject: [PATCH v3 19/27] iommu/arm-smmu-v3: Keep track of arm_smmu_master_domain for SVA
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <19-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Currently the smmu_domain->devices list is unused for SVA domains.
Fill it in with the SSID and master of every arm_smmu_set_pasid()
using the same logic as the RID attach.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 5db78e6e03dcfd..10dc7edd40e1b1 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2712,6 +2712,8 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
 	struct arm_smmu_domain *sid_smmu_domain =
 		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
 	struct arm_smmu_cd *cdptr;
+	struct attach_state state;
+	int ret;
 
 	if (!sid_smmu_domain || sid_smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
 		return -ENODEV;
@@ -2719,14 +2721,30 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
 	cdptr = arm_smmu_get_cd_ptr(master, pasid);
 	if (!cdptr)
 		return -ENOMEM;
+
+	mutex_lock(&arm_smmu_asid_lock);
+	ret = arm_smmu_attach_prepare(master, smmu_domain, pasid, &state);
+	if (ret)
+		goto out_unlock;
+
 	arm_smmu_write_cd_entry(master, pasid, cdptr, cd);
-	return 0;
+
+	arm_smmu_attach_commit(master, pasid, &state);
+
+out_unlock:
+	mutex_unlock(&arm_smmu_asid_lock);
+	return ret;
 }
 
 void arm_smmu_remove_pasid(struct arm_smmu_master *master,
 			   struct arm_smmu_domain *smmu_domain, ioasid_t pasid)
 {
+	mutex_lock(&arm_smmu_asid_lock);
 	arm_smmu_clear_cd(master, pasid);
+	if (master->ats_enabled)
+		arm_smmu_atc_inv_master(master, pasid);
+	arm_smmu_remove_master_domain(master, smmu_domain, pasid);
+	mutex_unlock(&arm_smmu_asid_lock);
 }
 
 static int arm_smmu_attach_dev_ste(struct device *dev,
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:19 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:19 -0400
Subject: [PATCH v3 13/27] iommu/arm-smmu-v3: Make smmu_domain->devices into an allocated list
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <13-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

The next patch will need to store the same master twice (with different
SSIDs), so allocate memory for each list element.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 11 ++++--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 39 ++++++++++++++++---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  7 +++-
 3 files changed, 47 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 29469073fc53fe..c541b94917d036 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -38,12 +38,13 @@ static DEFINE_MUTEX(sva_lock);
 static void
 arm_smmu_update_s1_domain_cd_entry(struct arm_smmu_domain *smmu_domain)
 {
-	struct arm_smmu_master *master;
+	struct arm_smmu_master_domain *master_domain;
 	struct arm_smmu_cd target_cd;
 	unsigned long flags;
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_for_each_entry(master, &smmu_domain->devices, domain_head) {
+	list_for_each_entry(master_domain, &smmu_domain->devices, devices_elm) {
+		struct arm_smmu_master *master = master_domain->master;
 		struct arm_smmu_cd *cdptr;
 
 		/* S1 domains only support RID attachment right now */
@@ -289,7 +290,7 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 {
 	struct arm_smmu_mmu_notifier *smmu_mn = mn_to_smmu(mn);
 	struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
-	struct arm_smmu_master *master;
+	struct arm_smmu_master_domain *master_domain;
 	unsigned long flags;
 
 	mutex_lock(&sva_lock);
@@ -303,7 +304,9 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 	 * but disable translation.
 	 */
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_for_each_entry(master, &smmu_domain->devices, domain_head) {
+	list_for_each_entry(master_domain, &smmu_domain->devices,
+			    devices_elm) {
+		struct arm_smmu_master *master = master_domain->master;
 		struct arm_smmu_cd target;
 		struct arm_smmu_cd *cdptr;
 
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 38e83386f631f1..6a3a5df836b9c7 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1968,10 +1968,10 @@ static int arm_smmu_atc_inv_master(struct arm_smmu_master *master)
 int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, int ssid,
 			    unsigned long iova, size_t size)
 {
+	struct arm_smmu_master_domain *master_domain;
 	int i;
 	unsigned long flags;
 	struct arm_smmu_cmdq_ent cmd;
-	struct arm_smmu_master *master;
 	struct arm_smmu_cmdq_batch cmds;
 
 	if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS))
@@ -1999,7 +1999,10 @@ int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, int ssid,
 	cmds.num = 0;
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_for_each_entry(master, &smmu_domain->devices, domain_head) {
+	list_for_each_entry(master_domain, &smmu_domain->devices,
+			    devices_elm) {
+		struct arm_smmu_master *master = master_domain->master;
+
 		if (!master->ats_enabled)
 			continue;
 
@@ -2489,10 +2492,27 @@ static void arm_smmu_disable_pasid(struct arm_smmu_master *master)
 	pci_disable_pasid(pdev);
 }
 
+static struct arm_smmu_master_domain *
+arm_smmu_find_master_domain(struct arm_smmu_domain *smmu_domain,
+			    struct arm_smmu_master *master)
+{
+	struct arm_smmu_master_domain *master_domain;
+
+	lockdep_assert_held(&smmu_domain->devices_lock);
+
+	list_for_each_entry(master_domain, &smmu_domain->devices,
+			    devices_elm) {
+		if (master_domain->master == master)
+			return master_domain;
+	}
+	return NULL;
+}
+
 static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 {
 	struct arm_smmu_domain *smmu_domain =
 		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
+	struct arm_smmu_master_domain *master_domain;
 	unsigned long flags;
 
 	if (!smmu_domain)
@@ -2501,7 +2521,11 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master)
 	arm_smmu_disable_ats(master, smmu_domain);
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_del_init(&master->domain_head);
+	master_domain = arm_smmu_find_master_domain(smmu_domain, master);
+	if (master_domain) {
+		list_del(&master_domain->devices_elm);
+		kfree(master_domain);
+	}
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
 	master->ats_enabled = false;
@@ -2515,6 +2539,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
 	struct arm_smmu_device *smmu;
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct arm_smmu_master_domain *master_domain;
 	struct arm_smmu_master *master;
 	struct arm_smmu_cd *cdptr;
 
@@ -2551,6 +2576,11 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 			return -ENOMEM;
 	}
 
+	master_domain = kzalloc(sizeof(*master_domain), GFP_KERNEL);
+	if (!master_domain)
+		return -ENOMEM;
+	master_domain->master = master;
+
 	/*
 	 * Prevent arm_smmu_share_asid() from trying to change the ASID
 	 * of either the old or new domain while we are working on it.
@@ -2564,7 +2594,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	master->ats_enabled = arm_smmu_ats_supported(master);
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_add(&master->domain_head, &smmu_domain->devices);
+	list_add(&master_domain->devices_elm, &smmu_domain->devices);
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
 	switch (smmu_domain->stage) {
@@ -2881,7 +2911,6 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 	master->dev = dev;
 	master->smmu = smmu;
 	INIT_LIST_HEAD(&master->bonds);
-	INIT_LIST_HEAD(&master->domain_head);
 	dev_iommu_priv_set(dev, master);
 
 	ret = arm_smmu_insert_master(smmu, master);
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index b7a65e37c51e9e..59bb420af52e28 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -695,7 +695,6 @@ struct arm_smmu_stream {
 struct arm_smmu_master {
 	struct arm_smmu_device		*smmu;
 	struct device			*dev;
-	struct list_head		domain_head;
 	struct arm_smmu_stream		*streams;
 	/* Locked by the iommu core using the group mutex */
 	struct arm_smmu_ctx_desc_cfg	cd_table;
@@ -729,12 +728,18 @@ struct arm_smmu_domain {
 
 	struct iommu_domain		domain;
 
+	/* List of struct arm_smmu_master_domain */
 	struct list_head		devices;
 	spinlock_t			devices_lock;
 
 	struct list_head		mmu_notifiers;
 };
 
+struct arm_smmu_master_domain {
+	struct list_head devices_elm;
+	struct arm_smmu_master *master;
+};
+
 static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
 {
 	return container_of(dom, struct arm_smmu_domain, domain);
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:10 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:10 -0400
Subject: [PATCH v3 04/27] iommu/arm-smmu-v3: Add a type for the CD entry
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <4-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Instead of passing a naked __le16 * around to represent a CD table entry
wrap it in a "struct arm_smmu_cd" with an array of the correct size. This
makes it much clearer which functions will comprise the "CD API".

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 20 +++++++++++---------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  7 ++++++-
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 39e010c838b1c2..3f77583144e649 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1118,7 +1118,8 @@ static void arm_smmu_write_cd_l1_desc(__le64 *dst,
 	WRITE_ONCE(*dst, cpu_to_le64(val));
 }
 
-static __le64 *arm_smmu_get_cd_ptr(struct arm_smmu_master *master, u32 ssid)
+static struct arm_smmu_cd *arm_smmu_get_cd_ptr(struct arm_smmu_master *master,
+					       u32 ssid)
 {
 	__le64 *l1ptr;
 	unsigned int idx;
@@ -1127,7 +1128,8 @@ static __le64 *arm_smmu_get_cd_ptr(struct arm_smmu_master *master, u32 ssid)
 	struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table;
 
 	if (cd_table->s1fmt == STRTAB_STE_0_S1FMT_LINEAR)
-		return cd_table->cdtab + ssid * CTXDESC_CD_DWORDS;
+		return (struct arm_smmu_cd *)(cd_table->cdtab +
+					      ssid * CTXDESC_CD_DWORDS);
 
 	idx = ssid >> CTXDESC_SPLIT;
 	l1_desc = &cd_table->l1_desc[idx];
@@ -1141,7 +1143,7 @@ static __le64 *arm_smmu_get_cd_ptr(struct arm_smmu_master *master, u32 ssid)
 		arm_smmu_sync_cd(master, ssid, false);
 	}
 	idx = ssid & (CTXDESC_L2_ENTRIES - 1);
-	return l1_desc->l2ptr + idx * CTXDESC_CD_DWORDS;
+	return &l1_desc->l2ptr[idx];
 }
 
 int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
@@ -1160,7 +1162,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
 	 */
 	u64 val;
 	bool cd_live;
-	__le64 *cdptr;
+	struct arm_smmu_cd *cdptr;
 	struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table;
 
 	if (WARN_ON(ssid >= (1 << cd_table->s1cdmax)))
@@ -1170,7 +1172,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
 	if (!cdptr)
 		return -ENOMEM;
 
-	val = le64_to_cpu(cdptr[0]);
+	val = le64_to_cpu(cdptr->data[0]);
 	cd_live = !!(val & CTXDESC_CD_0_V);
 
 	if (!cd) { /* (5) */
@@ -1185,9 +1187,9 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
 		 * this substream's traffic
 		 */
 	} else { /* (1) and (2) */
-		cdptr[1] = cpu_to_le64(cd->ttbr & CTXDESC_CD_1_TTB0_MASK);
-		cdptr[2] = 0;
-		cdptr[3] = cpu_to_le64(cd->mair);
+		cdptr->data[1] = cpu_to_le64(cd->ttbr & CTXDESC_CD_1_TTB0_MASK);
+		cdptr->data[2] = 0;
+		cdptr->data[3] = cpu_to_le64(cd->mair);
 
 		/*
 		 * STE may be live, and the SMMU might read dwords of this CD in any
@@ -1219,7 +1221,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
 	 *   field within an aligned 64-bit span of a structure can be altered
 	 *   without first making the structure invalid.
 	 */
-	WRITE_ONCE(cdptr[0], cpu_to_le64(val));
+	WRITE_ONCE(cdptr->data[0], cpu_to_le64(val));
 	arm_smmu_sync_cd(master, ssid, true);
 	return 0;
 }
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 6f62184eaa2434..24a77e0a97898b 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -282,6 +282,11 @@ struct arm_smmu_ste {
 #define CTXDESC_L1_DESC_L2PTR_MASK	GENMASK_ULL(51, 12)
 
 #define CTXDESC_CD_DWORDS		8
+
+struct arm_smmu_cd {
+	__le64 data[CTXDESC_CD_DWORDS];
+};
+
 #define CTXDESC_CD_0_TCR_T0SZ		GENMASK_ULL(5, 0)
 #define CTXDESC_CD_0_TCR_TG0		GENMASK_ULL(7, 6)
 #define CTXDESC_CD_0_TCR_IRGN0		GENMASK_ULL(9, 8)
@@ -591,7 +596,7 @@ struct arm_smmu_ctx_desc {
 };
 
 struct arm_smmu_l1_ctx_desc {
-	__le64				*l2ptr;
+	struct arm_smmu_cd		*l2ptr;
 	dma_addr_t			l2ptr_dma;
 };
 
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:27 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:27 -0400
Subject: [PATCH v3 21/27] iommu/arm-smmu-v3: Put the SVA mmu notifier in the smmu_domain
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <21-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

This removes all the notifier de-duplication logic in the driver and
relies on the core code to de-duplicate and allocate only one SVA domain
per mm per smmu instance. This naturally gives a 1:1 relationship between
SVA domain and mmu notifier.

Remove all of the previous mmu_notifier, bond, shared cd, and cd refcount
logic entirely.

For the purpose of organizing patches lightly remove BTM support. The next
patches will add it back in. BTM is a performance optimization so this is
bisection friendly functionally invisible change. Note that the current
code never even enables ARM_SMMU_FEAT_BTM so none of this code is ever
even used.

The bond/shared_cd/btm/asid allocator are tightly wound together and
changing them all at once would make this patch too big. The core issue is
that having a single SVA domain per-smmu instance conflicts with the
design of having a global ASID table that BTM currently needs, as we would
end up having to assign multiple SVA domains to the same ASID.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 385 ++++--------------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   |  80 +---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  14 +-
 3 files changed, 101 insertions(+), 378 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 991daffbee31aa..30cdd0661c00da 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -13,29 +13,9 @@
 #include "../../iommu-sva.h"
 #include "../../io-pgtable-arm.h"
 
-struct arm_smmu_mmu_notifier {
-	struct mmu_notifier		mn;
-	struct arm_smmu_ctx_desc	*cd;
-	bool				cleared;
-	refcount_t			refs;
-	struct list_head		list;
-	struct arm_smmu_domain		*domain;
-};
-
-#define mn_to_smmu(mn) container_of(mn, struct arm_smmu_mmu_notifier, mn)
-
-struct arm_smmu_bond {
-	struct mm_struct		*mm;
-	struct arm_smmu_mmu_notifier	*smmu_mn;
-	struct list_head		list;
-};
-
-#define sva_to_bond(handle) \
-	container_of(handle, struct arm_smmu_bond, sva)
-
 static DEFINE_MUTEX(sva_lock);
 
-static void
+static void __maybe_unused
 arm_smmu_update_s1_domain_cd_entry(struct arm_smmu_domain *smmu_domain)
 {
 	struct arm_smmu_master_domain *master_domain;
@@ -58,58 +38,6 @@ arm_smmu_update_s1_domain_cd_entry(struct arm_smmu_domain *smmu_domain)
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 }
 
-/*
- * Check if the CPU ASID is available on the SMMU side. If a private context
- * descriptor is using it, try to replace it.
- */
-static struct arm_smmu_ctx_desc *
-arm_smmu_share_asid(struct mm_struct *mm, u16 asid)
-{
-	int ret;
-	u32 new_asid;
-	struct arm_smmu_ctx_desc *cd;
-	struct arm_smmu_device *smmu;
-	struct arm_smmu_domain *smmu_domain;
-
-	cd = xa_load(&arm_smmu_asid_xa, asid);
-	if (!cd)
-		return NULL;
-
-	if (cd->mm) {
-		if (WARN_ON(cd->mm != mm))
-			return ERR_PTR(-EINVAL);
-		/* All devices bound to this mm use the same cd struct. */
-		refcount_inc(&cd->refs);
-		return cd;
-	}
-
-	smmu_domain = container_of(cd, struct arm_smmu_domain, cd);
-	smmu = smmu_domain->smmu;
-
-	ret = xa_alloc(&arm_smmu_asid_xa, &new_asid, cd,
-		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
-	if (ret)
-		return ERR_PTR(-ENOSPC);
-	/*
-	 * Race with unmap: TLB invalidations will start targeting the new ASID,
-	 * which isn't assigned yet. We'll do an invalidate-all on the old ASID
-	 * later, so it doesn't matter.
-	 */
-	cd->asid = new_asid;
-	/*
-	 * Update ASID and invalidate CD in all associated masters. There will
-	 * be some overlap between use of both ASIDs, until we invalidate the
-	 * TLB.
-	 */
-	arm_smmu_update_s1_domain_cd_entry(smmu_domain);
-
-	/* Invalidate TLB entries previously associated with that context */
-	arm_smmu_tlb_inv_asid(smmu, asid);
-
-	xa_erase(&arm_smmu_asid_xa, asid);
-	return NULL;
-}
-
 static u64 page_size_to_cd(void)
 {
 	static_assert(PAGE_SIZE == SZ_4K || PAGE_SIZE == SZ_16K ||
@@ -123,7 +51,8 @@ static u64 page_size_to_cd(void)
 
 static void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
 				 struct arm_smmu_master *master,
-				 struct mm_struct *mm, u16 asid)
+				 struct mm_struct *mm, u16 asid,
+				 bool btm_invalidation)
 {
 	u64 par;
 
@@ -144,7 +73,7 @@ static void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
 		(master->stall_enabled ? CTXDESC_CD_0_S : 0) |
 		CTXDESC_CD_0_R |
 		CTXDESC_CD_0_A |
-		CTXDESC_CD_0_ASET |
+		(btm_invalidation ? 0 : CTXDESC_CD_0_ASET) |
 		FIELD_PREP(CTXDESC_CD_0_ASID, asid));
 
 	/*
@@ -176,69 +105,6 @@ static void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
 	target->data[3] = cpu_to_le64(read_sysreg(mair_el1));
 }
 
-static struct arm_smmu_ctx_desc *arm_smmu_alloc_shared_cd(struct mm_struct *mm)
-{
-	u16 asid;
-	int err = 0;
-	struct arm_smmu_ctx_desc *cd;
-	struct arm_smmu_ctx_desc *ret = NULL;
-
-	/* Don't free the mm until we release the ASID */
-	mmgrab(mm);
-
-	asid = arm64_mm_context_get(mm);
-	if (!asid) {
-		err = -ESRCH;
-		goto out_drop_mm;
-	}
-
-	cd = kzalloc(sizeof(*cd), GFP_KERNEL);
-	if (!cd) {
-		err = -ENOMEM;
-		goto out_put_context;
-	}
-
-	refcount_set(&cd->refs, 1);
-
-	mutex_lock(&arm_smmu_asid_lock);
-	ret = arm_smmu_share_asid(mm, asid);
-	if (ret) {
-		mutex_unlock(&arm_smmu_asid_lock);
-		goto out_free_cd;
-	}
-
-	err = xa_insert(&arm_smmu_asid_xa, asid, cd, GFP_KERNEL);
-	mutex_unlock(&arm_smmu_asid_lock);
-
-	if (err)
-		goto out_free_asid;
-
-	cd->asid = asid;
-	cd->mm = mm;
-
-	return cd;
-
-out_free_asid:
-	arm_smmu_free_asid(cd);
-out_free_cd:
-	kfree(cd);
-out_put_context:
-	arm64_mm_context_put(mm);
-out_drop_mm:
-	mmdrop(mm);
-	return err < 0 ? ERR_PTR(err) : ret;
-}
-
-static void arm_smmu_free_shared_cd(struct arm_smmu_ctx_desc *cd)
-{
-	if (arm_smmu_free_asid(cd)) {
-		/* Unpin ASID */
-		arm64_mm_context_put(cd->mm);
-		mmdrop(cd->mm);
-		kfree(cd);
-	}
-}
-
 /*
  * Cloned from the MAX_TLBI_OPS in arch/arm64/include/asm/tlbflush.h, this
  * is used as a threshold to replace per-page TLBI commands to issue in the
@@ -253,8 +119,8 @@ static void arm_smmu_mm_arch_invalidate_secondary_tlbs(struct mmu_notifier *mn,
 						unsigned long start,
 						unsigned long end)
 {
-	struct arm_smmu_mmu_notifier *smmu_mn = mn_to_smmu(mn);
-	struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
+	struct arm_smmu_domain *smmu_domain =
+		container_of(mn, struct arm_smmu_domain, mmu_notifier);
 	size_t size;
 
 	/*
@@ -271,33 +137,27 @@ static void arm_smmu_mm_arch_invalidate_secondary_tlbs(struct mmu_notifier *mn,
 			size = 0;
 	}
 
-	if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM)) {
+	if (!smmu_domain->btm_invalidation) {
 		if (!size)
 			arm_smmu_tlb_inv_asid(smmu_domain->smmu,
-					      smmu_mn->cd->asid);
+					      smmu_domain->cd.asid);
 		else
 			arm_smmu_tlb_inv_range_asid(start, size,
-						    smmu_mn->cd->asid,
+						    smmu_domain->cd.asid,
 						    PAGE_SIZE, false,
 						    smmu_domain);
 	}
 
-	arm_smmu_atc_inv_domain_sva(smmu_domain, mm->pasid, start, size);
+	arm_smmu_atc_inv_domain(smmu_domain, start, size);
 }
 
 static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 {
-	struct arm_smmu_mmu_notifier *smmu_mn = mn_to_smmu(mn);
-	struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
+	struct arm_smmu_domain *smmu_domain =
+		container_of(mn, struct arm_smmu_domain, mmu_notifier);
 	struct arm_smmu_master_domain *master_domain;
 	unsigned long flags;
 
-	mutex_lock(&sva_lock);
-	if (smmu_mn->cleared) {
-		mutex_unlock(&sva_lock);
-		return;
-	}
-
 	/*
 	 * DMA may still be running. Keep the cd valid to avoid C_BAD_CD events,
 	 * but disable translation.
@@ -309,24 +169,27 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 		struct arm_smmu_cd target;
 		struct arm_smmu_cd *cdptr;
 
-		cdptr = arm_smmu_get_cd_ptr(master, mm->pasid);
+		cdptr = arm_smmu_get_cd_ptr(master, master_domain->ssid);
 		if (WARN_ON(!cdptr))
 			continue;
-		arm_smmu_make_sva_cd(&target, master, NULL, smmu_mn->cd->asid);
-		arm_smmu_write_cd_entry(master, mm->pasid, cdptr, &target);
+		arm_smmu_make_sva_cd(&target, master, NULL,
+				     smmu_domain->cd.asid,
+				     smmu_domain->btm_invalidation);
+		arm_smmu_write_cd_entry(master, master_domain->ssid, cdptr,
+					&target);
 	}
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
-	arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_mn->cd->asid);
-	arm_smmu_atc_inv_domain_sva(smmu_domain, mm->pasid, 0, 0);
-
-	smmu_mn->cleared = true;
-	mutex_unlock(&sva_lock);
+	arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_domain->cd.asid);
+	arm_smmu_atc_inv_domain(smmu_domain, 0, 0);
 }
 
 static void arm_smmu_mmu_notifier_free(struct mmu_notifier *mn)
 {
-	kfree(mn_to_smmu(mn));
+	struct arm_smmu_domain *smmu_domain =
+		container_of(mn, struct arm_smmu_domain, mmu_notifier);
+
+	kfree(smmu_domain);
 }
 
 static const struct mmu_notifier_ops arm_smmu_mmu_notifier_ops = {
@@ -335,109 +198,6 @@ static const struct mmu_notifier_ops arm_smmu_mmu_notifier_ops = {
 	.free_notifier			= arm_smmu_mmu_notifier_free,
 };
 
-/* Allocate or get existing MMU notifier for this {domain, mm} pair */
-static struct arm_smmu_mmu_notifier *
-arm_smmu_mmu_notifier_get(struct arm_smmu_domain *smmu_domain,
-			  struct mm_struct *mm)
-{
-	int ret;
-	struct arm_smmu_ctx_desc *cd;
-	struct arm_smmu_mmu_notifier *smmu_mn;
-
-	list_for_each_entry(smmu_mn, &smmu_domain->mmu_notifiers, list) {
-		if (smmu_mn->mn.mm == mm) {
-			refcount_inc(&smmu_mn->refs);
-			return smmu_mn;
-		}
-	}
-
-	cd = arm_smmu_alloc_shared_cd(mm);
-	if (IS_ERR(cd))
-		return ERR_CAST(cd);
-
-	smmu_mn = kzalloc(sizeof(*smmu_mn), GFP_KERNEL);
-	if (!smmu_mn) {
-		ret = -ENOMEM;
-		goto err_free_cd;
-	}
-
-	refcount_set(&smmu_mn->refs, 1);
-	smmu_mn->cd = cd;
-	smmu_mn->domain = smmu_domain;
-	smmu_mn->mn.ops = &arm_smmu_mmu_notifier_ops;
-
-	ret = mmu_notifier_register(&smmu_mn->mn, mm);
-	if (ret) {
-		kfree(smmu_mn);
-		goto err_free_cd;
-	}
-
-	list_add(&smmu_mn->list, &smmu_domain->mmu_notifiers);
-	return smmu_mn;
-
-err_free_cd:
-	arm_smmu_free_shared_cd(cd);
-	return ERR_PTR(ret);
-}
-
-static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
-{
-	struct mm_struct *mm = smmu_mn->mn.mm;
-	struct arm_smmu_ctx_desc *cd = smmu_mn->cd;
-	struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
-
-	if (!refcount_dec_and_test(&smmu_mn->refs))
-		return;
-
-	list_del(&smmu_mn->list);
-
-	/*
-	 * If we went through clear(), we've already invalidated, and no
-	 * new TLB entry can have been formed.
-	 */
-	if (!smmu_mn->cleared) {
-		arm_smmu_tlb_inv_asid(smmu_domain->smmu, cd->asid);
-		arm_smmu_atc_inv_domain_sva(smmu_domain, mm->pasid, 0, 0);
-	}
-
-	/* Frees smmu_mn */
-	mmu_notifier_put(&smmu_mn->mn);
-	arm_smmu_free_shared_cd(cd);
-}
-
-static int __arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm,
-			       struct arm_smmu_cd *target)
-{
-	int ret;
-	struct arm_smmu_bond *bond;
-	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
-	struct arm_smmu_domain *smmu_domain =
-		to_smmu_domain_safe(iommu_get_domain_for_dev(dev));
-
-	if (!smmu_domain || smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
-		return -ENODEV;
-
-	bond = kzalloc(sizeof(*bond), GFP_KERNEL);
-	if (!bond)
-		return -ENOMEM;
-
-	bond->mm = mm;
-
-	bond->smmu_mn = arm_smmu_mmu_notifier_get(smmu_domain, mm);
-	if (IS_ERR(bond->smmu_mn)) {
-		ret = PTR_ERR(bond->smmu_mn);
-		goto err_free_bond;
-	}
-
-	list_add(&bond->list, &master->bonds);
-	arm_smmu_make_sva_cd(target, master, mm, bond->smmu_mn->cd->asid);
-	return 0;
-
-err_free_bond:
-	kfree(bond);
-	return ret;
-}
-
 bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
 {
 	unsigned long reg, fld;
@@ -565,11 +325,6 @@ int arm_smmu_master_enable_sva(struct arm_smmu_master *master)
 int arm_smmu_master_disable_sva(struct arm_smmu_master *master)
 {
 	mutex_lock(&sva_lock);
-	if (!list_empty(&master->bonds)) {
-		dev_err(master->dev, "cannot disable SVA, device is bound\n");
-		mutex_unlock(&sva_lock);
-		return -EBUSY;
-	}
 	arm_smmu_master_sva_disable_iopf(master);
 	master->sva_enabled = false;
 	mutex_unlock(&sva_lock);
@@ -586,59 +341,54 @@ void arm_smmu_sva_notifier_synchronize(void)
 	mmu_notifier_synchronize();
 }
 
-void arm_smmu_sva_remove_dev_pasid(struct iommu_domain *domain,
-				   struct device *dev, ioasid_t id)
-{
-	struct mm_struct *mm = domain->mm;
-	struct arm_smmu_bond *bond = NULL, *t;
-	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
-
-	arm_smmu_remove_pasid(master, to_smmu_domain(domain), id);
-
-	mutex_lock(&sva_lock);
-	list_for_each_entry(t, &master->bonds, list) {
-		if (t->mm == mm) {
-			bond = t;
-			break;
-		}
-	}
-
-	if (!WARN_ON(!bond)) {
-		list_del(&bond->list);
-		arm_smmu_mmu_notifier_put(bond->smmu_mn);
-		kfree(bond);
-	}
-	mutex_unlock(&sva_lock);
-}
-
 static int arm_smmu_sva_set_dev_pasid(struct iommu_domain *domain,
 				      struct device *dev, ioasid_t id)
 {
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
-	int ret = 0;
-	struct mm_struct *mm = domain->mm;
 	struct arm_smmu_cd target;
+	int ret;
 
-	if (mm->pasid != id || !master->cd_table.used_sid)
+	/* Prevent arm_smmu_mm_release from being called while we are attaching */
+	if (!mmget_not_zero(domain->mm))
 		return -EINVAL;
 
-	if (!arm_smmu_get_cd_ptr(master, id))
-		return -ENOMEM;
+	/*
+	 * This does not need the arm_smmu_asid_lock because SVA domains never
+	 * get reassigned
+	 */
+	arm_smmu_make_sva_cd(&target, master, smmu_domain->domain.mm,
+			     smmu_domain->cd.asid,
+			     smmu_domain->btm_invalidation);
 
-	mutex_lock(&sva_lock);
-	ret = __arm_smmu_sva_bind(dev, mm, &target);
-	mutex_unlock(&sva_lock);
-	if (ret)
-		return ret;
+	ret = arm_smmu_set_pasid(master, to_smmu_domain(domain), id, &target);
 
-	/* This cannot fail since we preallocated the cdptr */
-	arm_smmu_set_pasid(master, to_smmu_domain(domain), id, &target);
-	return 0;
+	mmput(domain->mm);
+	return ret;
 }
 
 static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
 {
-	kfree(to_smmu_domain(domain));
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+
+	/*
+	 * Ensure the ASID is empty in the iommu cache before allowing reuse.
+	 */
+	arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_domain->cd.asid);
+
+	/*
+	 * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
+	 * still be called/running at this point. We allow the ASID to be
+	 * reused, and if there is a race then it just suffers harmless
+	 * unnecessary invalidation.
+	 */
+	xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
+
+	/*
+	 * Actual free is defered to the SRCU callback
+	 * arm_smmu_mmu_notifier_free()
+	 */
+	mmu_notifier_put(&smmu_domain->mmu_notifier);
 }
 
 static const struct iommu_domain_ops arm_smmu_sva_domain_ops = {
@@ -652,6 +402,8 @@ struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
 	struct arm_smmu_device *smmu = master->smmu;
 	struct arm_smmu_domain *smmu_domain;
+	u32 asid;
+	int ret;
 
 	smmu_domain = arm_smmu_domain_alloc();
 	if (!smmu_domain)
@@ -661,5 +413,22 @@ struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
 	smmu_domain->domain.ops = &arm_smmu_sva_domain_ops;
 	smmu_domain->smmu = smmu;
 
+	ret = xa_alloc(&arm_smmu_asid_xa, &asid, smmu_domain,
+		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
+	if (ret)
+		goto err_free;
+
+	smmu_domain->cd.asid = asid;
+	smmu_domain->mmu_notifier.ops = &arm_smmu_mmu_notifier_ops;
+	ret = mmu_notifier_register(&smmu_domain->mmu_notifier, mm);
+	if (ret)
+		goto err_asid;
+
 	return &smmu_domain->domain;
+
+err_asid:
+	xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
+err_free:
+	kfree(smmu_domain);
+	return ERR_PTR(ret);
 }
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index d09505acd4f8ce..c87e3f197e0fda 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1339,22 +1339,6 @@ static void arm_smmu_free_cd_tables(struct arm_smmu_master *master)
 	cd_table->cdtab = NULL;
 }
 
-bool arm_smmu_free_asid(struct arm_smmu_ctx_desc *cd)
-{
-	bool free;
-	struct arm_smmu_ctx_desc *old_cd;
-
-	if (!cd->asid)
-		return false;
-
-	free = refcount_dec_and_test(&cd->refs);
-	if (free) {
-		old_cd = xa_erase(&arm_smmu_asid_xa, cd->asid);
-		WARN_ON(old_cd != cd);
-	}
-	return free;
-}
-
 /* Stream table manipulation functions */
 static void
 arm_smmu_write_strtab_l1_desc(__le64 *dst, struct arm_smmu_strtab_l1_desc *desc)
@@ -1979,8 +1963,8 @@ static int arm_smmu_atc_inv_master(struct arm_smmu_master *master,
 	return arm_smmu_cmdq_batch_submit(master->smmu, &cmds);
 }
 
-static int __arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
-				     ioasid_t ssid, unsigned long iova, size_t size)
+int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
+			    unsigned long iova, size_t size)
 {
 	struct arm_smmu_master_domain *master_domain;
 	int i;
@@ -2018,15 +2002,7 @@ static int __arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
 		if (!master->ats_enabled)
 			continue;
 
-		/*
-		 * Non-zero ssid means SVA is co-opting the S1 domain to issue
-		 * invalidations for SVA PASIDs.
-		 */
-		if (ssid != IOMMU_NO_PASID)
-			arm_smmu_atc_inv_to_cmd(ssid, iova, size, &cmd);
-		else
-			arm_smmu_atc_inv_to_cmd(master_domain->ssid, iova, size,
-						&cmd);
+		arm_smmu_atc_inv_to_cmd(master_domain->ssid, iova, size, &cmd);
 
 		for (i = 0; i < master->num_streams; i++) {
 			cmd.atc.sid = master->streams[i].id;
@@ -2038,19 +2014,6 @@ static int __arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
 	return arm_smmu_cmdq_batch_submit(smmu_domain->smmu, &cmds);
 }
 
-static int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
-				   unsigned long iova, size_t size)
-{
-	return __arm_smmu_atc_inv_domain(smmu_domain, IOMMU_NO_PASID, iova,
-					 size);
-}
-
-int arm_smmu_atc_inv_domain_sva(struct arm_smmu_domain *smmu_domain,
-				ioasid_t ssid, unsigned long iova, size_t size)
-{
-	return __arm_smmu_atc_inv_domain(smmu_domain, ssid, iova, size);
-}
-
 /* IO_PGTABLE API */
 static void arm_smmu_tlb_inv_context(void *cookie)
 {
@@ -2239,7 +2202,6 @@ struct arm_smmu_domain *arm_smmu_domain_alloc(void)
 	mutex_init(&smmu_domain->init_mutex);
 	INIT_LIST_HEAD(&smmu_domain->devices);
 	spin_lock_init(&smmu_domain->devices_lock);
-	INIT_LIST_HEAD(&smmu_domain->mmu_notifiers);
 
 	return smmu_domain;
 }
@@ -2280,7 +2242,7 @@ static void arm_smmu_domain_free(struct iommu_domain *domain)
 	if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
 		/* Prevent SVA from touching the CD while we're freeing it */
 		mutex_lock(&arm_smmu_asid_lock);
-		arm_smmu_free_asid(&smmu_domain->cd);
+		xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
 		mutex_unlock(&arm_smmu_asid_lock);
 	} else {
 		struct arm_smmu_s2_cfg *cfg = &smmu_domain->s2_cfg;
@@ -2298,11 +2260,9 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_device *smmu,
 	u32 asid;
 	struct arm_smmu_ctx_desc *cd = &smmu_domain->cd;
 
-	refcount_set(&cd->refs, 1);
-
 	/* Prevent SVA from modifying the ASID until it is written to the CD */
 	mutex_lock(&arm_smmu_asid_lock);
-	ret = xa_alloc(&arm_smmu_asid_xa, &asid, cd,
+	ret = xa_alloc(&arm_smmu_asid_xa, &asid, smmu_domain,
 		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
 	cd->asid	= (u16)asid;
 	mutex_unlock(&arm_smmu_asid_lock);
@@ -2715,7 +2675,10 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
 	struct attach_state state;
 	int ret;
 
-	if (!sid_smmu_domain || sid_smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
+	if (smmu_domain->smmu != master->smmu)
+		return -EINVAL;
+
+	if (!sid_smmu_domain || !master->cd_table.used_sid)
 		return -ENODEV;
 
 	cdptr = arm_smmu_get_cd_ptr(master, pasid);
@@ -2736,9 +2699,18 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
 	return ret;
 }
 
-void arm_smmu_remove_pasid(struct arm_smmu_master *master,
-			   struct arm_smmu_domain *smmu_domain, ioasid_t pasid)
+static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
 {
+	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+	struct arm_smmu_domain *smmu_domain;
+	struct iommu_domain *domain;
+
+	domain = iommu_get_domain_for_dev_pasid(dev, pasid, IOMMU_DOMAIN_SVA);
+	if (WARN_ON(IS_ERR(domain)) || !domain)
+		return;
+
+	smmu_domain = to_smmu_domain(domain);
+
 	mutex_lock(&arm_smmu_asid_lock);
 	arm_smmu_clear_cd(master, pasid);
 	if (master->ats_enabled)
@@ -3032,7 +3004,6 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 
 	master->dev = dev;
 	master->smmu = smmu;
-	INIT_LIST_HEAD(&master->bonds);
 	dev_iommu_priv_set(dev, master);
 
 	ret = arm_smmu_insert_master(smmu, master);
@@ -3214,17 +3185,6 @@ static int arm_smmu_def_domain_type(struct device *dev)
 	return 0;
 }
 
-static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
-{
-	struct iommu_domain *domain;
-
-	domain = iommu_get_domain_for_dev_pasid(dev, pasid, IOMMU_DOMAIN_SVA);
-	if (WARN_ON(IS_ERR(domain)) || !domain)
-		return;
-
-	arm_smmu_sva_remove_dev_pasid(domain, dev, pasid);
-}
-
 static struct iommu_ops arm_smmu_ops = {
 	.identity_domain	= &arm_smmu_identity_domain,
 	.blocked_domain		= &arm_smmu_blocked_domain,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 48871c8ee8c88c..a229ad0adf6a49 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -587,9 +587,6 @@ struct arm_smmu_strtab_l1_desc {
 
 struct arm_smmu_ctx_desc {
 	u16				asid;
-
-	refcount_t			refs;
-	struct mm_struct		*mm;
 };
 
 struct arm_smmu_l1_ctx_desc {
@@ -713,7 +710,6 @@ struct arm_smmu_master {
 	bool				stall_enabled;
 	bool				sva_enabled;
 	bool				iopf_enabled;
-	struct list_head		bonds;
 	unsigned int			ssid_bits;
 };
 
@@ -742,7 +738,8 @@ struct arm_smmu_domain {
 	struct list_head		devices;
 	spinlock_t			devices_lock;
 
-	struct list_head		mmu_notifiers;
+	struct mmu_notifier		mmu_notifier;
+	bool				btm_invalidation;
 };
 
 struct arm_smmu_master_domain {
@@ -796,9 +793,8 @@ void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid);
 void arm_smmu_tlb_inv_range_asid(unsigned long iova, size_t size, int asid,
 				 size_t granule, bool leaf,
 				 struct arm_smmu_domain *smmu_domain);
-bool arm_smmu_free_asid(struct arm_smmu_ctx_desc *cd);
-int arm_smmu_atc_inv_domain_sva(struct arm_smmu_domain *smmu_domain,
-				ioasid_t ssid, unsigned long iova, size_t size);
+int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
+			    unsigned long iova, size_t size);
 
 #ifdef CONFIG_ARM_SMMU_V3_SVA
 bool arm_smmu_sva_supported(struct arm_smmu_device *smmu);
@@ -810,8 +806,6 @@ bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master);
 void arm_smmu_sva_notifier_synchronize(void);
 struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
 					       struct mm_struct *mm);
-void arm_smmu_sva_remove_dev_pasid(struct iommu_domain *domain,
-				   struct device *dev, ioasid_t id);
 #else /* CONFIG_ARM_SMMU_V3_SVA */
 static inline bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
 {
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:26 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:26 -0400
Subject: [PATCH v3 20/27] iommu: Add ops->domain_alloc_sva()
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <20-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Make a new op that receives the device and the mm_struct that the SVA
domain should be created for. Unlike domain_alloc_paging() the dev
argument is never NULL here.

This allows drivers to fully initialize the SVA domain and allocate the
mmu_notifier during allocation. It allows the notifier lifetime to follow
the lifetime of the iommu_domain.

Since we have only one call site, upgrade the new op to return ERR_PTR
instead of NULL.

Change SMMUv3 to use the new op.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 12 +++++++++---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c     |  2 +-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h     |  6 +++++-
 drivers/iommu/iommu-sva.c                       |  4 ++--
 drivers/iommu/iommu.c                           | 12 +++++++++---
 include/linux/iommu.h                           |  3 +++
 6 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 5894785aa901e8..991daffbee31aa 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -638,7 +638,7 @@ static int arm_smmu_sva_set_dev_pasid(struct iommu_domain *domain,
 
 static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
 {
-	kfree(domain);
+	kfree(to_smmu_domain(domain));
 }
 
 static const struct iommu_domain_ops arm_smmu_sva_domain_ops = {
@@ -646,14 +646,20 @@ static const struct iommu_domain_ops arm_smmu_sva_domain_ops = {
 	.free			= arm_smmu_sva_domain_free
 };
 
-struct iommu_domain *arm_smmu_sva_domain_alloc(unsigned type)
+struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
+					       struct mm_struct *mm)
 {
+	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+	struct arm_smmu_device *smmu = master->smmu;
 	struct arm_smmu_domain *smmu_domain;
 
 	smmu_domain = arm_smmu_domain_alloc();
 	if (!smmu_domain)
-		return NULL;
+		return ERR_PTR(-ENOMEM);
+
+	smmu_domain->domain.type = IOMMU_DOMAIN_SVA;
 	smmu_domain->domain.ops = &arm_smmu_sva_domain_ops;
+	smmu_domain->smmu = smmu;
 
 	return &smmu_domain->domain;
 }
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 10dc7edd40e1b1..d09505acd4f8ce 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -3229,8 +3229,8 @@ static struct iommu_ops arm_smmu_ops = {
 	.identity_domain	= &arm_smmu_identity_domain,
 	.blocked_domain		= &arm_smmu_blocked_domain,
 	.capable		= arm_smmu_capable,
-	.domain_alloc		= arm_smmu_sva_domain_alloc,
 	.domain_alloc_paging    = arm_smmu_domain_alloc_paging,
+	.domain_alloc_sva       = arm_smmu_sva_domain_alloc,
 	.probe_device		= arm_smmu_probe_device,
 	.release_device		= arm_smmu_release_device,
 	.device_group		= arm_smmu_device_group,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index c1181e456b7d5f..48871c8ee8c88c 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -808,7 +808,8 @@ int arm_smmu_master_enable_sva(struct arm_smmu_master *master);
 int arm_smmu_master_disable_sva(struct arm_smmu_master *master);
 bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master);
 void arm_smmu_sva_notifier_synchronize(void);
-struct iommu_domain *arm_smmu_sva_domain_alloc(unsigned int type);
+struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
+					       struct mm_struct *mm);
 void arm_smmu_sva_remove_dev_pasid(struct iommu_domain *domain,
 				   struct device *dev, ioasid_t id);
 #else /* CONFIG_ARM_SMMU_V3_SVA */
@@ -854,5 +855,8 @@ static inline void arm_smmu_sva_remove_dev_pasid(struct iommu_domain *domain,
 						 ioasid_t id)
 {
 }
+
+#define arm_smmu_sva_domain_alloc NULL
+
 #endif /* CONFIG_ARM_SMMU_V3_SVA */
 #endif /* _ARM_SMMU_V3_H */
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index b78671a8a9143f..a52b206793b420 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -87,8 +87,8 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
 
 	/* Allocate a new domain and set it on device pasid. */
 	domain = iommu_sva_domain_alloc(dev, mm);
-	if (!domain) {
-		ret = -ENOMEM;
+	if (IS_ERR(domain)) {
+		ret = PTR_ERR(domain);
 		goto out_unlock;
 	}
 
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index f17a1113f3d6a3..899d73062f6e67 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -3543,9 +3543,15 @@ struct iommu_domain *iommu_sva_domain_alloc(struct device *dev,
 	const struct iommu_ops *ops = dev_iommu_ops(dev);
 	struct iommu_domain *domain;
 
-	domain = ops->domain_alloc(IOMMU_DOMAIN_SVA);
-	if (!domain)
-		return NULL;
+	if (ops->domain_alloc_sva) {
+		domain = ops->domain_alloc_sva(dev, mm);
+		if (IS_ERR(domain))
+			return domain;
+	} else {
+		domain = ops->domain_alloc(IOMMU_DOMAIN_SVA);
+		if (!domain)
+			return ERR_PTR(-ENOMEM);
+	}
 
 	domain->type = IOMMU_DOMAIN_SVA;
 	mmgrab(mm);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index ec289c1016f5f2..7bd8c898e67559 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -346,6 +346,7 @@ static inline int __iommu_copy_struct_from_user(
  *                     Upon failure, ERR_PTR must be returned.
  * @domain_alloc_paging: Allocate an iommu_domain that can be used for
  *                       UNMANAGED, DMA, and DMA_FQ domain types.
+ * @domain_alloc_sva: Allocate an iommu_domain for Shared Virtual Addressing.
  * @probe_device: Add device to iommu driver handling
  * @release_device: Remove device from iommu driver handling
  * @probe_finalize: Do final setup work after the device is added to an IOMMU
@@ -386,6 +387,8 @@ struct iommu_ops {
 		struct device *dev, u32 flags, struct iommu_domain *parent,
 		const struct iommu_user_data *user_data);
 	struct iommu_domain *(*domain_alloc_paging)(struct device *dev);
+	struct iommu_domain *(*domain_alloc_sva)(struct device *dev,
+						 struct mm_struct *mm);
 
 	struct iommu_device *(*probe_device)(struct device *dev);
 	void (*release_device)(struct device *dev);
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:06 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:06 -0400
Subject: [PATCH v3 00/27] Update SMMUv3 to the modern iommu API (part 2/3)
Message-ID: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

[Sorry to resend this, I typo'd something and didn't CC the mailing lists]

Continuing the work of part 1 this focuses on the CD, PASID and SVA
components:

 - attach_dev failure does not change the HW configuration.

 - Full PASID API support including:
    - S1/SVA domains attached to PASIDs
    - IDENTITY/BLOCKED/S1 attached to RID
    - Change of the RID domain while PASIDs are attached

 - Streamlined SVA support using the core infrastructure

 - Hitless, whenever possible, change between two domains

Making the CD programming work like the new STE programming allows
untangling some of the confusing SVA flows. From there the focus is on
building out the core infrastructure for dealing with PASID and CD
entries, then keeping track of unique SSID's for ATS invalidation.

The ATS ordering is generalized so that the PASID flow can use it and put
into a form where it is fully hitless, whenever possible. Care is taken to
ensure that ATC flushes are present after any change in translation.

Finally we simply kill the entire outdated SVA mmu_notifier implementation
in one shot and switch it over to the newly created generic PASID & CD
code. This avoids the messy and confusing approach of trying to
incrementally untangle this in place. The new code is small and simple
enough this is much better than trying to figure out  fixes.

Once SVA is resting on the right CD code it is straightforward to make the
PASID interface functionally complete.

This depends on part 1

The SVA change requires Tina's series:

https://lore.kernel.org/linux-iommu/20231027000525.1278806-1-tina.zhang at intel.com/

(Although if you have only a single SVA device it is not necessary to
test)

It achieves the same goals as the several series from Michael and the S1DSS
series from Nicolin that were trying to improve portions of the API.

This is on github: https://github.com/jgunthorpe/linux/commits/smmuv3_newapi

v3:
 - Rebase on the latest part 1
 - update comments and commit messages
 - Fix error exit in arm_smmu_set_pasid()
 - Fix inverted logic for btm_invalidation
 - Add missing ATC invalidation on mm release
 - Add a big comment explaining that BTM is not enabled and what is
   missing to enable it.
v2: https://lore.kernel.org/r/0-v2-16665a652079+5947-smmuv3_newapi_p2_jgg at nvidia.com
 - Rebased on iommmufd + Joerg's tree
 - Use sid_smmu_domain consistently to refer to the domain attached to the
   device (eg the PCIe RID)
 - Rework how arm_smmu_attach_*() and callers flow to be more careful
   about ordering around ATC invalidation. The ATC must be invalidated
   after it is impossible to establish stale entires.
 - ATS disable is now entirely part of arm_smmu_attach_dev_ste(), which is
   the only STE type that ever disables ATS.
 - Remove the 'existing_master_domain' optimization, the code is
   functionally fine without it.
 - Whitespace, spelling, and checkpatch related items
 - Fixed wrong value stored in the xa for the BTM flows
 - Use pasid more consistently instead of id
v1: https://lore.kernel.org/r/0-v1-afbb86647bbd+5-smmuv3_newapi_p2_jgg at nvidia.com

Jason Gunthorpe (27):
  iommu/arm-smmu-v3: Check that the RID domain is S1 in SVA
  iommu/arm-smmu-v3: Do not allow a SVA domain to be set on the wrong
    PASID
  iommu/arm-smmu-v3: Do not ATC invalidate the entire domain
  iommu/arm-smmu-v3: Add a type for the CD entry
  iommu/arm-smmu-v3: Make CD programming use arm_smmu_write_entry_step()
  iommu/arm-smmu-v3: Consolidate clearing a CD table entry
  iommu/arm-smmu-v3: Move the CD generation for S1 domains into a
    function
  iommu/arm-smmu-v3: Move allocation of the cdtable into
    arm_smmu_get_cd_ptr()
  iommu/arm-smmu-v3: Allocate the CD table entry in advance
  iommu/arm-smmu-v3: Move the CD generation for SVA into a function
  iommu/arm-smmu-v3: Lift CD programming out of the SVA notifier code
  iommu/arm-smmu-v3: Build the whole CD in arm_smmu_make_s1_cd()
  iommu/arm-smmu-v3: Make smmu_domain->devices into an allocated list
  iommu/arm-smmu-v3: Make changing domains be hitless for ATS
  iommu/arm-smmu-v3: Add ssid to struct arm_smmu_master_domain
  iommu/arm-smmu-v3: Keep track of valid CD entries in the cd_table
  iommu/arm-smmu-v3: Thread SSID through the arm_smmu_attach_*()
    interface
  iommu/arm-smmu-v3: Make SVA allocate a normal arm_smmu_domain
  iommu/arm-smmu-v3: Keep track of arm_smmu_master_domain for SVA
  iommu: Add ops->domain_alloc_sva()
  iommu/arm-smmu-v3: Put the SVA mmu notifier in the smmu_domain
  iommu/arm-smmu-v3: Consolidate freeing the ASID/VMID
  iommu/arm-smmu-v3: Move the arm_smmu_asid_xa to per-smmu like vmid
  iommu/arm-smmu-v3: Bring back SVA BTM support
  iommu/arm-smmu-v3: Allow IDENTITY/BLOCKED to be set while PASID is
    used
  iommu/arm-smmu-v3: Allow a PASID to be set when RID is
    IDENTITY/BLOCKED
  iommu/arm-smmu-v3: Allow setting a S1 domain to a PASID

 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 630 ++++++-------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 834 +++++++++++-------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  94 +-
 drivers/iommu/iommu-sva.c                     |   4 +-
 drivers/iommu/iommu.c                         |  12 +-
 include/linux/iommu.h                         |   3 +
 6 files changed, 899 insertions(+), 678 deletions(-)


base-commit: df3abd7ce2d2ca37e0afc6c421517ae79d3ddb94
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:29 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:29 -0400
Subject: [PATCH v3 23/27] iommu/arm-smmu-v3: Move the arm_smmu_asid_xa to per-smmu like vmid
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <23-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

The SVA BTM and shared cd code was the only thing keeping this as a global
array. Now that is out of the way we can move it to per-smmu.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  2 +-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 39 +++++++++----------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  5 +--
 3 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 19b4d52be7ab66..d5772ce27d48b2 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -408,7 +408,7 @@ struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
 	smmu_domain->domain.ops = &arm_smmu_sva_domain_ops;
 	smmu_domain->smmu = smmu;
 
-	ret = xa_alloc(&arm_smmu_asid_xa, &asid, smmu_domain,
+	ret = xa_alloc(&smmu->asid_map, &asid, smmu_domain,
 		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
 	if (ret)
 		goto err_free;
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 83e31177215533..e30de36044cac5 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -71,9 +71,6 @@ struct arm_smmu_option_prop {
 	const char *prop;
 };
 
-DEFINE_XARRAY_ALLOC1(arm_smmu_asid_xa);
-DEFINE_MUTEX(arm_smmu_asid_lock);
-
 static struct arm_smmu_option_prop arm_smmu_options[] = {
 	{ ARM_SMMU_OPT_SKIP_PREFETCH, "hisilicon,broken-prefetch-cmd" },
 	{ ARM_SMMU_OPT_PAGE0_REGS_ONLY, "cavium,cn9900-broken-page1-regspace"},
@@ -2245,9 +2242,9 @@ void arm_smmu_domain_free_id(struct arm_smmu_domain *smmu_domain)
 		arm_smmu_tlb_inv_asid(smmu, smmu_domain->cd.asid);
 
 		/* Prevent SVA from touching the CD while we're freeing it */
-		mutex_lock(&arm_smmu_asid_lock);
-		xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
-		mutex_unlock(&arm_smmu_asid_lock);
+		mutex_lock(&smmu->asid_lock);
+		xa_erase(&smmu->asid_map, smmu_domain->cd.asid);
+		mutex_unlock(&smmu->asid_lock);
 	} else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S2 &&
 		   smmu_domain->s2_cfg.vmid) {
 		struct arm_smmu_cmdq_ent cmd = {
@@ -2277,11 +2274,11 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_device *smmu,
 	struct arm_smmu_ctx_desc *cd = &smmu_domain->cd;
 
 	/* Prevent SVA from modifying the ASID until it is written to the CD */
-	mutex_lock(&arm_smmu_asid_lock);
-	ret = xa_alloc(&arm_smmu_asid_xa, &asid, smmu_domain,
+	mutex_lock(&smmu->asid_lock);
+	ret = xa_alloc(&smmu->asid_map, &asid, smmu_domain,
 		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
 	cd->asid	= (u16)asid;
-	mutex_unlock(&arm_smmu_asid_lock);
+	mutex_unlock(&smmu->asid_lock);
 	return ret;
 }
 
@@ -2545,7 +2542,7 @@ static int arm_smmu_attach_prepare(struct arm_smmu_master *master,
 	 * arm_smmu_master_domain contents otherwise it could randomly write one
 	 * or the other to the CD.
 	 */
-	lockdep_assert_held(&arm_smmu_asid_lock);
+	lockdep_assert_held(&master->smmu->asid_lock);
 
 	master_domain = kzalloc(sizeof(*master_domain), GFP_KERNEL);
 	if (!master_domain)
@@ -2584,7 +2581,7 @@ static int arm_smmu_attach_prepare(struct arm_smmu_master *master,
 static void arm_smmu_attach_commit(struct arm_smmu_master *master,
 				   ioasid_t ssid, struct attach_state *state)
 {
-	lockdep_assert_held(&arm_smmu_asid_lock);
+	lockdep_assert_held(&master->smmu->asid_lock);
 
 	if (!state->want_ats) {
 		WARN_ON(master->ats_enabled);
@@ -2647,12 +2644,12 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	 * This allows the STE and the smmu_domain->devices list to
 	 * be inconsistent during this routine.
 	 */
-	mutex_lock(&arm_smmu_asid_lock);
+	mutex_lock(&smmu->asid_lock);
 
 	ret = arm_smmu_attach_prepare(master, smmu_domain, IOMMU_NO_PASID,
 				      &state);
 	if (ret) {
-		mutex_unlock(&arm_smmu_asid_lock);
+		mutex_unlock(&smmu->asid_lock);
 		return ret;
 	}
 
@@ -2677,7 +2674,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	}
 
 	arm_smmu_attach_commit(master, IOMMU_NO_PASID, &state);
-	mutex_unlock(&arm_smmu_asid_lock);
+	mutex_unlock(&smmu->asid_lock);
 	return 0;
 }
 
@@ -2701,7 +2698,7 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
 	if (!cdptr)
 		return -ENOMEM;
 
-	mutex_lock(&arm_smmu_asid_lock);
+	mutex_lock(&master->smmu->asid_lock);
 	ret = arm_smmu_attach_prepare(master, smmu_domain, pasid, &state);
 	if (ret)
 		goto out_unlock;
@@ -2711,7 +2708,7 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
 	arm_smmu_attach_commit(master, pasid, &state);
 
 out_unlock:
-	mutex_unlock(&arm_smmu_asid_lock);
+	mutex_unlock(&master->smmu->asid_lock);
 	return ret;
 }
 
@@ -2727,12 +2724,12 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
 
 	smmu_domain = to_smmu_domain(domain);
 
-	mutex_lock(&arm_smmu_asid_lock);
+	mutex_lock(&master->smmu->asid_lock);
 	arm_smmu_clear_cd(master, pasid);
 	if (master->ats_enabled)
 		arm_smmu_atc_inv_master(master, pasid);
 	arm_smmu_remove_master_domain(master, smmu_domain, pasid);
-	mutex_unlock(&arm_smmu_asid_lock);
+	mutex_unlock(&master->smmu->asid_lock);
 }
 
 static int arm_smmu_attach_dev_ste(struct device *dev,
@@ -2749,7 +2746,7 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 	 * Do not allow any ASID to be changed while are working on the STE,
 	 * otherwise we could miss invalidations.
 	 */
-	mutex_lock(&arm_smmu_asid_lock);
+	mutex_lock(&master->smmu->asid_lock);
 
 	/*
 	 * The SMMU does not support enabling ATS with bypass/abort. When the
@@ -2778,7 +2775,7 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 
 	master->ats_enabled = false;
 
-	mutex_unlock(&arm_smmu_asid_lock);
+	mutex_unlock(&master->smmu->asid_lock);
 
 	/*
 	 * This has to be done after removing the master from the
@@ -3436,6 +3433,8 @@ static int arm_smmu_init_strtab(struct arm_smmu_device *smmu)
 	smmu->strtab_cfg.strtab_base = reg;
 
 	ida_init(&smmu->vmid_map);
+	xa_init_flags(&smmu->asid_map, XA_FLAGS_ALLOC1);
+	mutex_init(&smmu->asid_lock);
 
 	return 0;
 }
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index c7c4f4fda31297..efc6bc11bbb838 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -675,6 +675,8 @@ struct arm_smmu_device {
 
 #define ARM_SMMU_MAX_ASIDS		(1 << 16)
 	unsigned int			asid_bits;
+	struct xarray			asid_map;
+	struct mutex			asid_lock;
 
 #define ARM_SMMU_MAX_VMIDS		(1 << 16)
 	unsigned int			vmid_bits;
@@ -768,9 +770,6 @@ to_smmu_domain_safe(struct iommu_domain *domain)
 	return NULL;
 }
 
-extern struct xarray arm_smmu_asid_xa;
-extern struct mutex arm_smmu_asid_lock;
-
 struct arm_smmu_domain *arm_smmu_domain_alloc(void);
 
 void arm_smmu_clear_cd(struct arm_smmu_master *master, int ssid);
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:30 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:30 -0400
Subject: [PATCH v3 24/27] iommu/arm-smmu-v3: Bring back SVA BTM support
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <24-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

BTM support is a feature where the CPU TLB invalidation can be forwarded
to the IOMMU and also invalidate the IOTLB. For this to work the CPU and
IOMMU ASID must be the same.

Retain the prior SVA design here of keeping the ASID allocator for the
IOMMU private to SMMU and force SVA domains to set an ASID that matches
the CPU ASID.

This requires changing the ASID assigned to a S1 domain if it happens to
be overlapping with the required CPU ASID. We hold on to the CPU ASID so
long as the SVA iommu_domain exists, so SVA domain conflict is not
possible.

With the asid per-smmu we no longer have a problem that two per-smmu
iommu_domain's would need to share a CPU ASID entry in the IOMMU's xarray.

Use the same ASID move algorithm for the S1 domains as before with some
streamlining around how the xarray is being used. Do not synchronize the
ASID's if BTM mode is not supported. Just leave BTM features off
everywhere.

Audit all the places that touch cd->asid and think carefully about how the
locking works with the change to the cd->asid by the move algorithm. Use
xarray internal locking during xa_alloc() instead of double locking. Add a
note that concurrent S1 invalidation doesn't fully work.

Note that this is all still dead code, ARM_SMMU_FEAT_BTM is never set.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 133 ++++++++++++++++--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   |  15 +-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |   2 +-
 3 files changed, 129 insertions(+), 21 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index d5772ce27d48b2..e1df7dca853615 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -15,12 +15,33 @@
 
 static DEFINE_MUTEX(sva_lock);
 
-static void __maybe_unused
-arm_smmu_update_s1_domain_cd_entry(struct arm_smmu_domain *smmu_domain)
+static int arm_smmu_realloc_s1_domain_asid(struct arm_smmu_device *smmu,
+					   struct arm_smmu_domain *smmu_domain)
 {
 	struct arm_smmu_master_domain *master_domain;
+	u32 old_asid = smmu_domain->cd.asid;
 	struct arm_smmu_cd target_cd;
 	unsigned long flags;
+	int ret;
+
+	lockdep_assert_held(&smmu->asid_lock);
+
+	/*
+	 * FIXME: The unmap and invalidation path doesn't take any locks but
+	 * this is not fully safe. Since updating the CD tables is not atomic
+	 * there is always a hole where invalidating only one ASID of two active
+	 * ASIDs during unmap will cause the IOTLB to become stale.
+	 *
+	 * This approach is to hopefully shift the racing CPUs to the new ASID
+	 * before we start programming the HW. This increases the chance that
+	 * racing IOPTE changes will pick up an invalidation for the new ASID
+	 * and we achieve eventual consistency. For the brief period where the
+	 * old ASID is still in the CD entries it will become incoherent.
+	 */
+	ret = xa_alloc(&smmu->asid_map, &smmu_domain->cd.asid, smmu_domain,
+		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
+	if (ret)
+		return ret;
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
 	list_for_each_entry(master_domain, &smmu_domain->devices, devices_elm) {
@@ -36,6 +57,10 @@ arm_smmu_update_s1_domain_cd_entry(struct arm_smmu_domain *smmu_domain)
 					&target_cd);
 	}
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
+
+	/* Clean the ASID we are about to assign to a new translation */
+	arm_smmu_tlb_inv_asid(smmu, old_asid);
+	return 0;
 }
 
 static u64 page_size_to_cd(void)
@@ -138,12 +163,12 @@ static void arm_smmu_mm_arch_invalidate_secondary_tlbs(struct mmu_notifier *mn,
 	}
 
 	if (!smmu_domain->btm_invalidation) {
+		ioasid_t asid = READ_ONCE(smmu_domain->cd.asid);
+
 		if (!size)
-			arm_smmu_tlb_inv_asid(smmu_domain->smmu,
-					      smmu_domain->cd.asid);
+			arm_smmu_tlb_inv_asid(smmu_domain->smmu, asid);
 		else
-			arm_smmu_tlb_inv_range_asid(start, size,
-						    smmu_domain->cd.asid,
+			arm_smmu_tlb_inv_range_asid(start, size, asid,
 						    PAGE_SIZE, false,
 						    smmu_domain);
 	}
@@ -172,6 +197,8 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 		cdptr = arm_smmu_get_cd_ptr(master, master_domain->ssid);
 		if (WARN_ON(!cdptr))
 			continue;
+
+		/* An SVA ASID never changes, no asid_lock required */
 		arm_smmu_make_sva_cd(&target, master, NULL,
 				     smmu_domain->cd.asid,
 				     smmu_domain->btm_invalidation);
@@ -378,6 +405,8 @@ static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
 	 * unnecessary invalidation.
 	 */
 	arm_smmu_domain_free_id(smmu_domain);
+	if (smmu_domain->btm_invalidation)
+		arm64_mm_context_put(domain->mm);
 
 	/*
 	 * Actual free is defered to the SRCU callback
@@ -391,13 +420,97 @@ static const struct iommu_domain_ops arm_smmu_sva_domain_ops = {
 	.free			= arm_smmu_sva_domain_free
 };
 
+static int arm_smmu_share_asid(struct arm_smmu_device *smmu,
+			       struct arm_smmu_domain *smmu_domain,
+			       struct mm_struct *mm)
+{
+	struct arm_smmu_domain *old_s1_domain;
+	int ret;
+
+	/*
+	 * Notice that BTM is never currently enabled, this is all dead code.
+	 * The specification cautions:
+	 *
+	 * Note: Arm expects that SMMU stage 2 address spaces are generally
+	 * shared with their respective PE virtual machine stage 2
+	 * configuration. If broadcast invalidation is required to be avoided
+	 * for a particular SMMU stage 2 address space, Arm recommends that a
+	 * hypervisor configures the STE with a VMID that is not allocated for
+	 * virtual machine use on the PEs
+	 *
+	 * However, in Linux, both KVM and SMMU think they own the VMID pool.
+	 * Unfortunately the ARM design is problematic for Linux as we do not
+	 * currently share the S2 table with KVM. This creates a situation where
+	 * the S2 needs to have the same VMID as KVM in order to allow the guest
+	 * to use BTM, however we must still invalidate the S2 directly since it
+	 * is a different radix tree. What Linux would like is something like
+	 * ASET for the STE to disable BTM only for the S2.
+	 *
+	 * Arguably in a system with BTM the driver should prefer to use a S1
+	 * table in all cases execpt when explicitly asked to create a nesting
+	 * parent. Then it should use the VMID of KVM to enable BTM in the
+	 * guest. We cannot optimize away the resulting double invalidation of
+	 * the S2 :( Or we simply ignore BTM entirely as we are doing now.
+	 */
+	if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM))
+		return xa_alloc(&smmu->asid_map, &smmu_domain->cd.asid,
+				smmu_domain,
+				XA_LIMIT(1, (1 << smmu->asid_bits) - 1),
+				GFP_KERNEL);
+
+	/* At this point the caller ensures we have a mmget() */
+	smmu_domain->cd.asid = arm64_mm_context_get(mm);
+
+	mutex_lock(&smmu->asid_lock);
+	old_s1_domain = xa_store(&smmu->asid_map, smmu_domain->cd.asid,
+				 smmu_domain, GFP_KERNEL);
+	if (xa_err(old_s1_domain)) {
+		ret = xa_err(old_s1_domain);
+		goto out_put_asid;
+	}
+
+	/*
+	 * In BTM mode the CPU ASID and the IOMMU ASID have to be the same.
+	 * Unfortunately we run separate allocators for this and the IOMMU
+	 * ASID can already have been assigned to a S1 domain. SVA domains
+	 * always align to their CPU ASIDs. In this case we change
+	 * the S1 domain's ASID, update the CD entry and flush the caches.
+	 *
+	 * This is a bit tricky, all the places writing to a S1 CD, reading the
+	 * S1 ASID, or doing xa_erase must hold the asid_lock or xa_lock to
+	 * avoid IOTLB incoherence.
+	 */
+	if (old_s1_domain) {
+		if (WARN_ON(old_s1_domain->domain.type == IOMMU_DOMAIN_SVA)) {
+			ret = -EINVAL;
+			goto out_restore_s1;
+		}
+		ret = arm_smmu_realloc_s1_domain_asid(smmu, old_s1_domain);
+		if (ret)
+			goto out_restore_s1;
+	}
+
+	smmu_domain->btm_invalidation = true;
+
+	ret = 0;
+	goto out_unlock;
+
+out_restore_s1:
+	xa_store(&smmu->asid_map, smmu_domain->cd.asid, old_s1_domain,
+		 GFP_KERNEL);
+out_put_asid:
+	arm64_mm_context_put(mm);
+out_unlock:
+	mutex_unlock(&smmu->asid_lock);
+	return ret;
+}
+
 struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
 					       struct mm_struct *mm)
 {
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
 	struct arm_smmu_device *smmu = master->smmu;
 	struct arm_smmu_domain *smmu_domain;
-	u32 asid;
 	int ret;
 
 	smmu_domain = arm_smmu_domain_alloc();
@@ -408,12 +521,10 @@ struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
 	smmu_domain->domain.ops = &arm_smmu_sva_domain_ops;
 	smmu_domain->smmu = smmu;
 
-	ret = xa_alloc(&smmu->asid_map, &asid, smmu_domain,
-		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
+	ret = arm_smmu_share_asid(smmu, smmu_domain, mm);
 	if (ret)
 		goto err_free;
 
-	smmu_domain->cd.asid = asid;
 	smmu_domain->mmu_notifier.ops = &arm_smmu_mmu_notifier_ops;
 	ret = mmu_notifier_register(&smmu_domain->mmu_notifier, mm);
 	if (ret)
@@ -423,6 +534,8 @@ struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
 
 err_asid:
 	arm_smmu_domain_free_id(smmu_domain);
+	if (smmu_domain->btm_invalidation)
+		arm64_mm_context_put(mm);
 err_free:
 	kfree(smmu_domain);
 	return ERR_PTR(ret);
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e30de36044cac5..3907cf4db3efe1 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1217,6 +1217,8 @@ void arm_smmu_make_s1_cd(struct arm_smmu_cd *target,
 	typeof(&pgtbl_cfg->arm_lpae_s1_cfg.tcr) tcr =
 		&pgtbl_cfg->arm_lpae_s1_cfg.tcr;
 
+	lockdep_assert_held(&master->smmu->asid_lock);
+
 	memset(target, 0, sizeof(*target));
 
 	target->data[0] = cpu_to_le64(
@@ -2026,7 +2028,7 @@ static void arm_smmu_tlb_inv_context(void *cookie)
 	 * careful, 007.
 	 */
 	if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
-		arm_smmu_tlb_inv_asid(smmu, smmu_domain->cd.asid);
+		arm_smmu_tlb_inv_asid(smmu, READ_ONCE(smmu_domain->cd.asid));
 	} else {
 		cmd.opcode	= CMDQ_OP_TLBI_S12_VMALL;
 		cmd.tlbi.vmid	= smmu_domain->s2_cfg.vmid;
@@ -2269,17 +2271,10 @@ static void arm_smmu_domain_free(struct iommu_domain *domain)
 static int arm_smmu_domain_finalise_s1(struct arm_smmu_device *smmu,
 				       struct arm_smmu_domain *smmu_domain)
 {
-	int ret;
-	u32 asid;
 	struct arm_smmu_ctx_desc *cd = &smmu_domain->cd;
 
-	/* Prevent SVA from modifying the ASID until it is written to the CD */
-	mutex_lock(&smmu->asid_lock);
-	ret = xa_alloc(&smmu->asid_map, &asid, smmu_domain,
-		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
-	cd->asid	= (u16)asid;
-	mutex_unlock(&smmu->asid_lock);
-	return ret;
+	return xa_alloc(&smmu->asid_map, &cd->asid, smmu_domain,
+			XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
 }
 
 static int arm_smmu_domain_finalise_s2(struct arm_smmu_device *smmu,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index efc6bc11bbb838..96b01db47b0ea5 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -586,7 +586,7 @@ struct arm_smmu_strtab_l1_desc {
 };
 
 struct arm_smmu_ctx_desc {
-	u16				asid;
+	u32				asid;
 };
 
 struct arm_smmu_l1_ctx_desc {
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:20 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:20 -0400
Subject: [PATCH v3 14/27] iommu/arm-smmu-v3: Make changing domains be hitless for ATS
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <14-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

The core code allows the domain to be changed on the fly without a forced
stop in BLOCKED/IDENTITY. In this flow the driver should just continually
maintain the ATS with no change while the STE is updated.

ATS relies on a linked list smmu_domain->devices to keep track of which
masters have the domain programmed, but this list is also used by
arm_smmu_share_asid(), unrelated to ats.

Create two new functions to encapsulate this combined logic:
 arm_smmu_attach_prepare()
 arm_smmu_attach_commit()

Put the ATS disable flow into arm_smmu_attach_dev_ste() - we only disable
ATS when going to IDENTITY or BLOCKED domains.

Installing a S1/S2 domain always enables the ATS if the PCIe device
supports it.

The enable flow is now ordered differently to allow it to be hitless:

  1) Add the master to the new smmu_domain->devices list
  2) Program the STE
  3) Enable ATS at PCIe
  4) Remove the master from the old smmu_domain

This flow ensures that invalidations to either domain will generate an ATC
invalidation to the device while the STE is being switched. Thus we don't
need to turn off the ATS anymore for correctness.

The disable flow is the reverse:
 1) Disable ATS at PCIe
 2) Program the STE
 3) Invalidate the ATC
 4) Remove the master from the old smmu_domain

Move the nr_ats_masters adjustments to be close to the list
manipulations. It is a count of the number of ATS enabled
masters currently in the list. This is stricly before and after the STE/CD
are revised, and done under a spin_lock which more clearly pairs with the
smp_mb() on the read side.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 171 ++++++++++++++------
 1 file changed, 120 insertions(+), 51 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 6a3a5df836b9c7..b50d5cfbef8c71 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1490,7 +1490,8 @@ static void arm_smmu_make_bypass_ste(struct arm_smmu_ste *target)
 
 static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
 				      struct arm_smmu_master *master,
-				      struct arm_smmu_ctx_desc_cfg *cd_table)
+				      struct arm_smmu_ctx_desc_cfg *cd_table,
+				      bool ats_enabled)
 {
 	struct arm_smmu_device *smmu = master->smmu;
 
@@ -1512,7 +1513,7 @@ static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
 			 STRTAB_STE_1_S1STALLD :
 			 0) |
 		FIELD_PREP(STRTAB_STE_1_EATS,
-			   master->ats_enabled ? STRTAB_STE_1_EATS_TRANS : 0) |
+			   ats_enabled ? STRTAB_STE_1_EATS_TRANS : 0) |
 		FIELD_PREP(STRTAB_STE_1_STRW,
 			   (smmu->features & ARM_SMMU_FEAT_E2H) ?
 				   STRTAB_STE_1_STRW_EL2 :
@@ -1521,7 +1522,8 @@ static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
 
 static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
 					struct arm_smmu_master *master,
-					struct arm_smmu_domain *smmu_domain)
+					struct arm_smmu_domain *smmu_domain,
+					bool ats_enabled)
 {
 	struct arm_smmu_s2_cfg *s2_cfg = &smmu_domain->s2_cfg;
 	const struct io_pgtable_cfg *pgtbl_cfg =
@@ -1537,7 +1539,7 @@ static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
 
 	target->data[1] |= cpu_to_le64(
 		FIELD_PREP(STRTAB_STE_1_EATS,
-			   master->ats_enabled ? STRTAB_STE_1_EATS_TRANS : 0));
+			   ats_enabled ? STRTAB_STE_1_EATS_TRANS : 0));
 
 	vtcr_val = FIELD_PREP(STRTAB_STE_2_VTCR_S2T0SZ, vtcr->tsz) |
 		   FIELD_PREP(STRTAB_STE_2_VTCR_S2SL0, vtcr->sl) |
@@ -2405,22 +2407,16 @@ static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
 	return dev_is_pci(dev) && pci_ats_supported(to_pci_dev(dev));
 }
 
-static void arm_smmu_enable_ats(struct arm_smmu_master *master,
-				struct arm_smmu_domain *smmu_domain)
+static void arm_smmu_enable_ats(struct arm_smmu_master *master)
 {
 	size_t stu;
 	struct pci_dev *pdev;
 	struct arm_smmu_device *smmu = master->smmu;
 
-	/* Don't enable ATS at the endpoint if it's not enabled in the STE */
-	if (!master->ats_enabled)
-		return;
-
 	/* Smallest Translation Unit: log2 of the smallest supported granule */
 	stu = __ffs(smmu->pgsize_bitmap);
 	pdev = to_pci_dev(master->dev);
 
-	atomic_inc(&smmu_domain->nr_ats_masters);
 	/*
 	 * ATC invalidation of PASID 0 causes the entire ATC to be flushed.
 	 */
@@ -2429,22 +2425,6 @@ static void arm_smmu_enable_ats(struct arm_smmu_master *master,
 		dev_err(master->dev, "Failed to enable ATS (STU %zu)\n", stu);
 }
 
-static void arm_smmu_disable_ats(struct arm_smmu_master *master,
-				 struct arm_smmu_domain *smmu_domain)
-{
-	if (!master->ats_enabled)
-		return;
-
-	pci_disable_ats(to_pci_dev(master->dev));
-	/*
-	 * Ensure ATS is disabled at the endpoint before we issue the
-	 * ATC invalidation via the SMMU.
-	 */
-	wmb();
-	arm_smmu_atc_inv_master(master);
-	atomic_dec(&smmu_domain->nr_ats_masters);
-}
-
 static int arm_smmu_enable_pasid(struct arm_smmu_master *master)
 {
 	int ret;
@@ -2508,40 +2488,116 @@ arm_smmu_find_master_domain(struct arm_smmu_domain *smmu_domain,
 	return NULL;
 }
 
-static void arm_smmu_detach_dev(struct arm_smmu_master *master)
+static void arm_smmu_remove_master_domain(struct arm_smmu_master *master,
+					  struct arm_smmu_domain *smmu_domain)
 {
-	struct arm_smmu_domain *smmu_domain =
-		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
 	struct arm_smmu_master_domain *master_domain;
 	unsigned long flags;
 
+	/* NULL means the old domain is IDENTITY/BLOCKED which we don't track */
 	if (!smmu_domain)
 		return;
 
-	arm_smmu_disable_ats(master, smmu_domain);
-
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
 	master_domain = arm_smmu_find_master_domain(smmu_domain, master);
 	if (master_domain) {
 		list_del(&master_domain->devices_elm);
 		kfree(master_domain);
+		if (master->ats_enabled)
+			atomic_dec(&smmu_domain->nr_ats_masters);
 	}
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
+}
 
-	master->ats_enabled = false;
+struct attach_state {
+	bool want_ats;
+};
+
+/*
+ * Prepare to attach a domain to a master. This always goes in the direction of
+ * enabling the ATS.
+ */
+static int arm_smmu_attach_prepare(struct arm_smmu_master *master,
+				   struct arm_smmu_domain *smmu_domain,
+				   struct attach_state *state)
+{
+	struct arm_smmu_master_domain *master_domain;
+	unsigned long flags;
+
+	/*
+	 * arm_smmu_share_asid() must not see two domains pointing to the same
+	 * arm_smmu_master_domain contents otherwise it could randomly write one
+	 * or the other to the CD.
+	 */
+	lockdep_assert_held(&arm_smmu_asid_lock);
+
+	master_domain = kzalloc(sizeof(*master_domain), GFP_KERNEL);
+	if (!master_domain)
+		return -ENOMEM;
+	master_domain->master = master;
+
+	state->want_ats = arm_smmu_ats_supported(master);
+
+	/*
+	 * During prepare we want the current smmu_domain and new smmu_domain to
+	 * be in the devices list before we change any HW. This ensures that
+	 * both domains will send ATS invalidations to the master until we are
+	 * done.
+	 *
+	 * It is tempting to make this list only track masters that are using
+	 * ATS, but arm_smmu_share_asid() also uses this to change the ASID of a
+	 * domain, unrelated to ATS.
+	 *
+	 * Notice if we are re-attaching the same domain then the list will have
+	 * two identical entries and commit will remove only one of them.
+	 */
+	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
+	if (state->want_ats)
+		atomic_inc(&smmu_domain->nr_ats_masters);
+	list_add(&master_domain->devices_elm, &smmu_domain->devices);
+	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
+	return 0;
+}
+
+/*
+ * Commit is done after the STE/CD are configured to respond to ATS requests. It
+ * enables and synchronizes the PCI device's ATC and finishes manipulating the
+ * smmu_domain->devices list.
+ */
+static void arm_smmu_attach_commit(struct arm_smmu_master *master,
+				   struct attach_state *state)
+{
+	lockdep_assert_held(&arm_smmu_asid_lock);
+
+	if (!state->want_ats) {
+		WARN_ON(master->ats_enabled);
+	} else if (!master->ats_enabled) {
+		master->ats_enabled = true;
+		arm_smmu_enable_ats(master);
+	} else {
+		/*
+		 * The translation has changed, flush the ATC. At this point the
+		 * SMMU is translating for the new domain and both the old&new
+		 * domain will issue invalidations.
+		 */
+		arm_smmu_atc_inv_master(master);
+	}
+
+	arm_smmu_remove_master_domain(
+		master,
+		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev)));
 }
 
 static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 {
 	int ret = 0;
-	unsigned long flags;
 	struct arm_smmu_ste target;
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
 	struct arm_smmu_device *smmu;
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
-	struct arm_smmu_master_domain *master_domain;
 	struct arm_smmu_master *master;
 	struct arm_smmu_cd *cdptr;
+	struct attach_state state;
 
 	if (!fwspec)
 		return -ENOENT;
@@ -2576,11 +2632,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 			return -ENOMEM;
 	}
 
-	master_domain = kzalloc(sizeof(*master_domain), GFP_KERNEL);
-	if (!master_domain)
-		return -ENOMEM;
-	master_domain->master = master;
-
 	/*
 	 * Prevent arm_smmu_share_asid() from trying to change the ASID
 	 * of either the old or new domain while we are working on it.
@@ -2589,13 +2640,11 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	 */
 	mutex_lock(&arm_smmu_asid_lock);
 
-	arm_smmu_detach_dev(master);
-
-	master->ats_enabled = arm_smmu_ats_supported(master);
-
-	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
-	list_add(&master_domain->devices_elm, &smmu_domain->devices);
-	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
+	ret = arm_smmu_attach_prepare(master, smmu_domain, &state);
+	if (ret) {
+		mutex_unlock(&arm_smmu_asid_lock);
+		return ret;
+	}
 
 	switch (smmu_domain->stage) {
 	case ARM_SMMU_DOMAIN_S1: {
@@ -2604,18 +2653,20 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 		arm_smmu_make_s1_cd(&target_cd, master, smmu_domain);
 		arm_smmu_write_cd_entry(master, IOMMU_NO_PASID, cdptr,
 					&target_cd);
-		arm_smmu_make_cdtable_ste(&target, master, &master->cd_table);
+		arm_smmu_make_cdtable_ste(&target, master, &master->cd_table,
+					  state.want_ats);
 		arm_smmu_install_ste_for_dev(master, &target);
 		break;
 	}
 	case ARM_SMMU_DOMAIN_S2:
-		arm_smmu_make_s2_domain_ste(&target, master, smmu_domain);
+		arm_smmu_make_s2_domain_ste(&target, master, smmu_domain,
+					    state.want_ats);
 		arm_smmu_install_ste_for_dev(master, &target);
 		arm_smmu_clear_cd(master, IOMMU_NO_PASID);
 		break;
 	}
 
-	arm_smmu_enable_ats(master, smmu_domain);
+	arm_smmu_attach_commit(master, &state);
 	mutex_unlock(&arm_smmu_asid_lock);
 	return 0;
 }
@@ -2648,6 +2699,8 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 				   struct arm_smmu_ste *ste)
 {
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+	struct arm_smmu_domain *old_domain =
+		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
 
 	if (arm_smmu_master_sva_enabled(master))
 		return -EBUSY;
@@ -2665,9 +2718,25 @@ static int arm_smmu_attach_dev_ste(struct device *dev,
 	 * the stream (STE.EATS == 0b00), causing F_BAD_ATS_TREQ and
 	 * F_TRANSL_FORBIDDEN events (IHI0070Ea 5.2 Stream Table Entry).
 	 */
-	arm_smmu_detach_dev(master);
+	if (master->ats_enabled) {
+		pci_disable_ats(to_pci_dev(master->dev));
+		/*
+		 * Ensure ATS is disabled at the endpoint before we issue the
+		 * ATC invalidation via the SMMU.
+		 */
+		wmb();
+	}
 
 	arm_smmu_install_ste_for_dev(master, ste);
+
+	if (old_domain) {
+		if (master->ats_enabled)
+			arm_smmu_atc_inv_master(master);
+		arm_smmu_remove_master_domain(master, old_domain);
+	}
+
+	master->ats_enabled = false;
+
 	mutex_unlock(&arm_smmu_asid_lock);
 
 	/*
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:28 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:28 -0400
Subject: [PATCH v3 22/27] iommu/arm-smmu-v3: Consolidate freeing the ASID/VMID
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <22-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

The SMMUv3 IOTLB is tagged with a VMID/ASID cache tag. Any time the
underlying translation is changed these need to be invalidated. At boot
time the IOTLB starts out empty and all cache tags are available for
allocation.

When a tag is taken out of the allocator the code assumes the IOTLB
doesn't reference it, and immediately programs it into a STE/CD. If the
cache is referencing the tag then it will have stale data and IOMMU will
become incoherent.

Thus, whenever an ASID/VMID is freed back to the allocator we need to know
that the IOTLB doesn't have any references to it. The SVA code correctly
had an invalidation here, but the paging code does not.

Consolidate freeing the VMID/ASID to one place and consistently flush both
ID types before returning to their allocators.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  9 ++---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 36 +++++++++++++------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  1 +
 3 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 30cdd0661c00da..19b4d52be7ab66 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -371,18 +371,13 @@ static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
 {
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
 
-	/*
-	 * Ensure the ASID is empty in the iommu cache before allowing reuse.
-	 */
-	arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_domain->cd.asid);
-
 	/*
 	 * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
 	 * still be called/running at this point. We allow the ASID to be
 	 * reused, and if there is a race then it just suffers harmless
 	 * unnecessary invalidation.
 	 */
-	xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
+	arm_smmu_domain_free_id(smmu_domain);
 
 	/*
 	 * Actual free is defered to the SRCU callback
@@ -427,7 +422,7 @@ struct iommu_domain *arm_smmu_sva_domain_alloc(struct device *dev,
 	return &smmu_domain->domain;
 
 err_asid:
-	xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
+	arm_smmu_domain_free_id(smmu_domain);
 err_free:
 	kfree(smmu_domain);
 	return ERR_PTR(ret);
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index c87e3f197e0fda..83e31177215533 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2231,25 +2231,41 @@ static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
 	return &smmu_domain->domain;
 }
 
-static void arm_smmu_domain_free(struct iommu_domain *domain)
+/*
+ * Return the domain's ASID or VMID back to the allocator. All IDs in the
+ * allocator do not have an IOTLB entries referencing them.
+ */
+void arm_smmu_domain_free_id(struct arm_smmu_domain *smmu_domain)
 {
-	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
 	struct arm_smmu_device *smmu = smmu_domain->smmu;
 
-	free_io_pgtable_ops(smmu_domain->pgtbl_ops);
+	if ((smmu_domain->stage == ARM_SMMU_DOMAIN_S1 ||
+	     smmu_domain->domain.type == IOMMU_DOMAIN_SVA) &&
+	    smmu_domain->cd.asid) {
+		arm_smmu_tlb_inv_asid(smmu, smmu_domain->cd.asid);
 
-	/* Free the ASID or VMID */
-	if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
 		/* Prevent SVA from touching the CD while we're freeing it */
 		mutex_lock(&arm_smmu_asid_lock);
 		xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
 		mutex_unlock(&arm_smmu_asid_lock);
-	} else {
-		struct arm_smmu_s2_cfg *cfg = &smmu_domain->s2_cfg;
-		if (cfg->vmid)
-			ida_free(&smmu->vmid_map, cfg->vmid);
-	}
+	} else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S2 &&
+		   smmu_domain->s2_cfg.vmid) {
+		struct arm_smmu_cmdq_ent cmd = {
+			.opcode = CMDQ_OP_TLBI_S12_VMALL,
+			.tlbi.vmid = smmu_domain->s2_cfg.vmid
+		};
 
+		arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
+		ida_free(&smmu->vmid_map, smmu_domain->s2_cfg.vmid);
+	}
+}
+
+static void arm_smmu_domain_free(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+
+	free_io_pgtable_ops(smmu_domain->pgtbl_ops);
+	arm_smmu_domain_free_id(smmu_domain);
 	kfree(smmu_domain);
 }
 
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index a229ad0adf6a49..c7c4f4fda31297 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -789,6 +789,7 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
 void arm_smmu_remove_pasid(struct arm_smmu_master *master,
 			   struct arm_smmu_domain *smmu_domain, ioasid_t pasid);
 
+void arm_smmu_domain_free_id(struct arm_smmu_domain *smmu_domain);
 void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid);
 void arm_smmu_tlb_inv_range_asid(unsigned long iova, size_t size, int asid,
 				 size_t granule, bool leaf,
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:13 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:13 -0400
Subject: [PATCH v3 07/27] iommu/arm-smmu-v3: Move the CD generation for S1 domains into a function
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <7-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

Introduce arm_smmu_make_s1_cd() to build the CD from the paging S1 domain,
and reorganize all the places programming S1 domain CD table entries to
call it.

Split arm_smmu_update_s1_domain_cd_entry() from
arm_smmu_update_ctx_desc_devices() so that the S1 path has its own call
chain separate from the unrelated SVA path.

arm_smmu_update_s1_domain_cd_entry() only works on S1 domains
attached to RIDs and refreshes all their CDs.

Remove the forced clear of the CD during S1 domain attach,
arm_smmu_write_cd_entry() will do this automatically if necessary.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 25 +++++++-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 60 +++++++++++++------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  8 +++
 3 files changed, 75 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 521bfa18879f90..04a807774402b2 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -54,6 +54,29 @@ static void arm_smmu_update_ctx_desc_devices(struct arm_smmu_domain *smmu_domain
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 }
 
+static void
+arm_smmu_update_s1_domain_cd_entry(struct arm_smmu_domain *smmu_domain)
+{
+	struct arm_smmu_master *master;
+	struct arm_smmu_cd target_cd;
+	unsigned long flags;
+
+	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
+	list_for_each_entry(master, &smmu_domain->devices, domain_head) {
+		struct arm_smmu_cd *cdptr;
+
+		/* S1 domains only support RID attachment right now */
+		cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
+		if (WARN_ON(!cdptr))
+			continue;
+
+		arm_smmu_make_s1_cd(&target_cd, master, smmu_domain);
+		arm_smmu_write_cd_entry(master, IOMMU_NO_PASID, cdptr,
+					&target_cd);
+	}
+	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
+}
+
 /*
  * Check if the CPU ASID is available on the SMMU side. If a private context
  * descriptor is using it, try to replace it.
@@ -97,7 +120,7 @@ arm_smmu_share_asid(struct mm_struct *mm, u16 asid)
 	 * be some overlap between use of both ASIDs, until we invalidate the
 	 * TLB.
 	 */
-	arm_smmu_update_ctx_desc_devices(smmu_domain, IOMMU_NO_PASID, cd);
+	arm_smmu_update_s1_domain_cd_entry(smmu_domain);
 
 	/* Invalidate TLB entries previously associated with that context */
 	arm_smmu_tlb_inv_asid(smmu, asid);
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 7fcd578b762afe..696f837015771f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1118,8 +1118,8 @@ static void arm_smmu_write_cd_l1_desc(__le64 *dst,
 	WRITE_ONCE(*dst, cpu_to_le64(val));
 }
 
-static struct arm_smmu_cd *arm_smmu_get_cd_ptr(struct arm_smmu_master *master,
-					       u32 ssid)
+struct arm_smmu_cd *arm_smmu_get_cd_ptr(struct arm_smmu_master *master,
+					u32 ssid)
 {
 	__le64 *l1ptr;
 	unsigned int idx;
@@ -1181,9 +1181,9 @@ static bool arm_smmu_write_cd_step(struct arm_smmu_cd *cur,
 
 }
 
-static void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
-				    struct arm_smmu_cd *cdptr,
-				    const struct arm_smmu_cd *target)
+void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
+			     struct arm_smmu_cd *cdptr,
+			     const struct arm_smmu_cd *target)
 {
 	struct arm_smmu_cd target_used;
 
@@ -1195,6 +1195,32 @@ static void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
 	}
 }
 
+void arm_smmu_make_s1_cd(struct arm_smmu_cd *target,
+			 struct arm_smmu_master *master,
+			 struct arm_smmu_domain *smmu_domain)
+{
+	struct arm_smmu_ctx_desc *cd = &smmu_domain->cd;
+
+	memset(target, 0, sizeof(*target));
+
+	target->data[0] = cpu_to_le64(
+		cd->tcr |
+#ifdef __BIG_ENDIAN
+		CTXDESC_CD_0_ENDI |
+#endif
+		CTXDESC_CD_0_V |
+		CTXDESC_CD_0_AA64 |
+		(master->stall_enabled ? CTXDESC_CD_0_S : 0) |
+		CTXDESC_CD_0_R |
+		CTXDESC_CD_0_A |
+		CTXDESC_CD_0_ASET |
+		FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid)
+		);
+
+	target->data[1] = cpu_to_le64(cd->ttbr & CTXDESC_CD_1_TTB0_MASK);
+	target->data[3] = cpu_to_le64(cd->mair);
+}
+
 void arm_smmu_clear_cd(struct arm_smmu_master *master, int ssid)
 {
 	struct arm_smmu_cd target = {};
@@ -2609,29 +2635,29 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
 
 	switch (smmu_domain->stage) {
-	case ARM_SMMU_DOMAIN_S1:
+	case ARM_SMMU_DOMAIN_S1: {
+		struct arm_smmu_cd target_cd;
+		struct arm_smmu_cd *cdptr;
+
 		if (!master->cd_table.cdtab) {
 			ret = arm_smmu_alloc_cd_tables(master);
 			if (ret)
 				goto out_list_del;
-		} else {
-			/*
-			 * arm_smmu_write_ctx_desc() relies on the entry being
-			 * invalid to work, clear any existing entry.
-			 */
-			ret = arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID,
-						      NULL);
-			if (ret)
-				goto out_list_del;
 		}
 
-		ret = arm_smmu_write_ctx_desc(master, IOMMU_NO_PASID, &smmu_domain->cd);
-		if (ret)
+		cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
+		if (!cdptr) {
+			ret = -ENOMEM;
 			goto out_list_del;
+		}
 
+		arm_smmu_make_s1_cd(&target_cd, master, smmu_domain);
+		arm_smmu_write_cd_entry(master, IOMMU_NO_PASID, cdptr,
+					&target_cd);
 		arm_smmu_make_cdtable_ste(&target, master, &master->cd_table);
 		arm_smmu_install_ste_for_dev(master, &target);
 		break;
+	}
 	case ARM_SMMU_DOMAIN_S2:
 		arm_smmu_make_s2_domain_ste(&target, master, smmu_domain);
 		arm_smmu_install_ste_for_dev(master, &target);
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index a8e7574ab8e154..950f5a08acda6d 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -764,6 +764,14 @@ extern struct mutex arm_smmu_asid_lock;
 extern struct arm_smmu_ctx_desc quiet_cd;
 
 void arm_smmu_clear_cd(struct arm_smmu_master *master, int ssid);
+struct arm_smmu_cd *arm_smmu_get_cd_ptr(struct arm_smmu_master *master,
+					u32 ssid);
+void arm_smmu_make_s1_cd(struct arm_smmu_cd *target,
+			 struct arm_smmu_master *master,
+			 struct arm_smmu_domain *smmu_domain);
+void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
+			     struct arm_smmu_cd *cdptr,
+			     const struct arm_smmu_cd *target);
 
 int arm_smmu_write_ctx_desc(struct arm_smmu_master *smmu_master, int ssid,
 			    struct arm_smmu_ctx_desc *cd);
-- 
2.43.0



From jgg at nvidia.com  Wed Dec  6 09:28:32 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed,  6 Dec 2023 13:28:32 -0400
Subject: [PATCH v3 26/27] iommu/arm-smmu-v3: Allow a PASID to be set when RID is IDENTITY/BLOCKED
In-Reply-To: <0-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>
Message-ID: <26-v3-9083a9368a5c+23fb-smmuv3_newapi_p2_jgg@nvidia.com>

If the STE doesn't point to the CD table we can upgrade it by
reprogramming the STE with the appropriate S1DSS. We may also need to turn
on ATS at the same time.

Keep track if the installed STE is pointing at the cd_table and the ATS
state to trigger this path.

Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 57 +++++++++++++++++++--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  6 ++-
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index f97fac1de0b103..7e5721490b7f4c 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2385,6 +2385,13 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master,
 	int i, j;
 	struct arm_smmu_device *smmu = master->smmu;
 
+	master->cd_table.in_ste =
+		FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(target->data[0])) ==
+		STRTAB_STE_0_CFG_S1_TRANS;
+	master->ste_ats_enabled =
+		FIELD_GET(STRTAB_STE_1_EATS, le64_to_cpu(target->data[1])) ==
+		STRTAB_STE_1_EATS_TRANS;
+
 	for (i = 0; i < master->num_streams; ++i) {
 		u32 sid = master->streams[i].id;
 		struct arm_smmu_ste *step =
@@ -2678,21 +2685,48 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	return 0;
 }
 
+static void arm_smmu_update_ste(struct arm_smmu_master *master,
+				struct iommu_domain *sid_domain,
+				bool want_ats)
+{
+	unsigned int s1dss = STRTAB_STE_1_S1DSS_TERMINATE;
+	struct arm_smmu_ste ste;
+
+	if (master->cd_table.in_ste && master->ste_ats_enabled == want_ats)
+		return;
+
+	if (sid_domain->type == IOMMU_DOMAIN_IDENTITY)
+		s1dss = STRTAB_STE_1_S1DSS_BYPASS;
+	else
+		WARN_ON(sid_domain->type != IOMMU_DOMAIN_BLOCKED);
+
+	/*
+	 * Change the STE into a cdtable one with SID IDENTITY/BLOCKED behavior
+	 * using s1dss if necessary. The cd_table is already installed then
+	 * the S1DSS is correct and this will just update the EATS. Otherwise
+	 * it installs the entire thing. This will be hitless.
+	 */
+	arm_smmu_make_cdtable_ste(&ste, master, &master->cd_table, want_ats,
+				  s1dss);
+	arm_smmu_install_ste_for_dev(master, &ste);
+}
+
 int arm_smmu_set_pasid(struct arm_smmu_master *master,
 		       struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
 		       const struct arm_smmu_cd *cd)
 {
-	struct arm_smmu_domain *sid_smmu_domain =
-		to_smmu_domain_safe(iommu_get_domain_for_dev(master->dev));
+	struct iommu_domain *sid_domain = iommu_get_domain_for_dev(master->dev);
 	struct arm_smmu_cd *cdptr;
 	struct attach_state state;
 	int ret;
 
-	if (smmu_domain->smmu != master->smmu)
+	if (smmu_domain->smmu != master->smmu || pasid == IOMMU_NO_PASID)
 		return -EINVAL;
 
-	if (!sid_smmu_domain || !master->cd_table.used_sid)
-		return -ENODEV;
+	if (!master->cd_table.in_ste &&
+	    sid_domain->type != IOMMU_DOMAIN_IDENTITY &&
+	    sid_domain->type != IOMMU_DOMAIN_BLOCKED)
+		return -EINVAL;
 
 	cdptr = arm_smmu_get_cd_ptr(master, pasid);
 	if (!cdptr)
@@ -2704,6 +2738,7 @@ int arm_smmu_set_pasid(struct arm_smmu_master *master,
 		goto out_unlock;
 
 	arm_smmu_write_cd_entry(master, pasid, cdptr, cd);
+	arm_smmu_update_ste(master, sid_domain, state.want_ats);
 
 	arm_smmu_attach_commit(master, pasid, &state);
 
@@ -2717,6 +2752,7 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
 	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
 	struct arm_smmu_domain *smmu_domain;
 	struct iommu_domain *domain;
+	bool last_ssid = master->cd_table.used_ssids == 1;
 
 	domain = iommu_get_domain_for_dev_pasid(dev, pasid, IOMMU_DOMAIN_SVA);
 	if (WARN_ON(IS_ERR(domain)) || !domain)
@@ -2730,6 +2766,17 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
 		arm_smmu_atc_inv_master(master, pasid);
 	arm_smmu_remove_master_domain(master, smmu_domain, pasid);
 	mutex_unlock(&master->smmu->asid_lock);
+
+	/*
+	 * When the last user of the CD table goes away downgrade the STE back
+	 * to a non-cd_table one.
+	 */
+	if (last_ssid && !master->cd_table.used_sid) {
+		struct iommu_domain *sid_domain =
+			iommu_get_domain_for_dev(master->dev);
+
+		sid_domain->ops->attach_dev(sid_domain, master->dev);
+	}
 }
 
 static void arm_smmu_attach_dev_ste(struct device *dev,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 96b01db47b0ea5..19628340ccd632 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -600,7 +600,8 @@ struct arm_smmu_ctx_desc_cfg {
 	struct arm_smmu_l1_ctx_desc	*l1_desc;
 	unsigned int			num_l1_ents;
 	unsigned int			used_ssids;
-	bool				used_sid;
+	u8				used_sid;
+	u8				in_ste;
 	u8				s1fmt;
 	/* log2 of the maximum number of CDs supported by this table */
 	u8				s1cdmax;
@@ -708,7 +709,8 @@ struct arm_smmu_master {
 	/* Locked by the iommu core using the group mutex */
 	struct arm_smmu_ctx_desc_cfg	cd_table;
 	unsigned int			num_streams;
-	bool				ats_enabled;
+	bool				ats_enabled : 1;
+	bool				ste_ats_enabled : 1;
 	bool				stall_enabled;
 	bool				sva_enabled;
 	bool				iopf_enabled;
-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Wed Dec  6 09:29:33 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 18:29:33 +0100
Subject: [PATCH 1/4] dt-bindings: memory: additional compatible strings
 for Broadcom DPFE
In-Reply-To: <42677f2d-190c-4043-a61d-8bfba581a764@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-2-mmayer@broadcom.com>
 <f17dcd86-7f87-4433-a106-eb7bfdfb05ab@linaro.org>
 <42677f2d-190c-4043-a61d-8bfba581a764@broadcom.com>
Message-ID: <5497447c-023b-4837-a5e2-b465ba2f624d@linaro.org>

On 06/12/2023 17:32, Florian Fainelli wrote:
> 
> 
> On 12/6/2023 3:09 AM, Krzysztof Kozlowski wrote:
>> On 05/12/2023 19:47, Markus Mayer wrote:
>>> Add versioned compatible strings for Broadcom DPFE. These take the form
>>> brcm,dpfe-cpu-v<N> where <N> is a number from 1 to 4.
>>>
>>> These API version related compatible strings are more specific than the
>>> catch-all "brcm,dpfe-cpu" and more generic than chip-specific compatible
>>> strings.
>>
>> None of this explains: Why? I don't see any point in this and commit
>> does not explain.
>>
>>>
>>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
>>> ---
>>>   .../bindings/memory-controllers/brcm,dpfe-cpu.yaml        | 8 +++++++-
>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>>> index 08cbdcddfead..6dffa7b62baf 100644
>>> --- a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>>> +++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>>> @@ -16,6 +16,11 @@ properties:
>>>         - enum:
>>>             - brcm,bcm7271-dpfe-cpu
>>>             - brcm,bcm7268-dpfe-cpu
>>> +      - enum:
>>> +          - brcm,dpfe-cpu-v1
>>> +          - brcm,dpfe-cpu-v2
>>> +          - brcm,dpfe-cpu-v3
>>> +          - brcm,dpfe-cpu-v4
>>
>> No, that's just wrong. So you want to say bcm7271 is brcm,dpfe-cpu-v4?
> 
> No as the example shows it "speaks" API v1.

Example is not a binding. It does not matter except of validating the
binding. This is just incorrect.

> 
> I would be inclined to completely remove the chip specific compatible 
> strings from the binding because they are not sufficient or descriptive 
> enough to determine which API version is being spoken, since the 
> firmware is unfortunately allowed to change major APIs (and the 
> messaging format, because why not?) at a moments notice.

Then versions do not give you anything more.

Best regards,
Krzysztof



From u.kleine-koenig at pengutronix.de  Wed Dec  6 09:30:43 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 18:30:43 +0100
Subject: [PATCH] pwm: stmpe: Silence duplicate error messages
Message-ID: <20231206173042.1762233-2-u.kleine-koenig@pengutronix.de>

stmpe_reg_read() and stmpe_reg_write() already emit error messages when
they fail. So the extra error messages in the pwm driver are only little
useful. They are useful in some situation, as they give a bit of context
to the failing register write. So don't remove them but degrade them to
dev_dbg().

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
Hello,

some time ago I suggested to remove the error messages. Thierry
suggested instead to turn them into dev_dbg instead.

See
https://lore.kernel.org/linux-pwm/20230728081803.aswbz4slvrqqi5hc at pengutronix.de
for the thread where that happend.

Best regards
Uwe

 drivers/pwm/pwm-stmpe.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/pwm/pwm-stmpe.c b/drivers/pwm/pwm-stmpe.c
index d730631c6583..19c0c0f39675 100644
--- a/drivers/pwm/pwm-stmpe.c
+++ b/drivers/pwm/pwm-stmpe.c
@@ -44,7 +44,7 @@ static int stmpe_24xx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 
 	ret = stmpe_reg_read(stmpe_pwm->stmpe, STMPE24XX_PWMCS);
 	if (ret < 0) {
-		dev_err(chip->dev, "error reading PWM#%u control\n",
+		dev_dbg(chip->dev, "error reading PWM#%u control\n",
 			pwm->hwpwm);
 		return ret;
 	}
@@ -53,7 +53,7 @@ static int stmpe_24xx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 
 	ret = stmpe_reg_write(stmpe_pwm->stmpe, STMPE24XX_PWMCS, value);
 	if (ret) {
-		dev_err(chip->dev, "error writing PWM#%u control\n",
+		dev_dbg(chip->dev, "error writing PWM#%u control\n",
 			pwm->hwpwm);
 		return ret;
 	}
@@ -70,7 +70,7 @@ static int stmpe_24xx_pwm_disable(struct pwm_chip *chip,
 
 	ret = stmpe_reg_read(stmpe_pwm->stmpe, STMPE24XX_PWMCS);
 	if (ret < 0) {
-		dev_err(chip->dev, "error reading PWM#%u control\n",
+		dev_dbg(chip->dev, "error reading PWM#%u control\n",
 			pwm->hwpwm);
 		return ret;
 	}
@@ -79,7 +79,7 @@ static int stmpe_24xx_pwm_disable(struct pwm_chip *chip,
 
 	ret = stmpe_reg_write(stmpe_pwm->stmpe, STMPE24XX_PWMCS, value);
 	if (ret)
-		dev_err(chip->dev, "error writing PWM#%u control\n",
+		dev_dbg(chip->dev, "error writing PWM#%u control\n",
 			pwm->hwpwm);
 	return ret;
 }
@@ -233,7 +233,7 @@ static int stmpe_24xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 		ret = stmpe_reg_write(stmpe_pwm->stmpe, offset, value);
 		if (ret) {
-			dev_err(chip->dev, "error writing register %02x: %d\n",
+			dev_dbg(chip->dev, "error writing register %02x: %d\n",
 				offset, ret);
 			return ret;
 		}
@@ -242,7 +242,7 @@ static int stmpe_24xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 		ret = stmpe_reg_write(stmpe_pwm->stmpe, offset, value);
 		if (ret) {
-			dev_err(chip->dev, "error writing register %02x: %d\n",
+			dev_dbg(chip->dev, "error writing register %02x: %d\n",
 				offset, ret);
 			return ret;
 		}
-- 
2.42.0



From krzysztof.kozlowski at linaro.org  Wed Dec  6 09:31:56 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 18:31:56 +0100
Subject: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
In-Reply-To: <12f3c515-71cf-46a5-ad92-15bf6c4c2f2c@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-4-mmayer@broadcom.com>
 <e63906cf-9f76-4fed-91b0-1a9168b179bd@linaro.org>
 <12f3c515-71cf-46a5-ad92-15bf6c4c2f2c@broadcom.com>
Message-ID: <c483e962-a565-45b0-91e2-41f47e2cf4bb@linaro.org>

On 06/12/2023 17:18, Florian Fainelli wrote:
> 
> 
> On 12/6/2023 3:10 AM, Krzysztof Kozlowski wrote:
>> On 05/12/2023 19:47, Markus Mayer wrote:
>>> Add support for version 4 of the DPFE API. This new version is largely
>>> identical to version 3. The main difference is that all commands now
>>> take the MHS version number as the first argument. Any other arguments
>>> have been pushed down by one (i.e. what used to be arg0 in v3 is arg1 in
>>> v4).
>>>
>>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
>>> ---
>>
>> ...
>>
>>> +
>>>   static const char *get_error_text(unsigned int i)
>>>   {
>>>   	static const char * const error_text[] = {
>>> @@ -929,8 +954,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
>>>   	{ .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
>>>   	{ .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
>>>   	{ .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
>>> +	{ .compatible = "brcm,dpfe-cpu-v4", .data = &dpfe_api_v4 },
>>>   
>>
>> No, use SoC specific compatible.
> 
> This is not that simple because for a given SoC, the API implemented by 
> the firmware can change, in fact it has changed over the lifetime of a 
> given SoC as firmware updates get rolled out. Arguably the dialect 
> spoken by the firmware should not have changed and we told the firmware 
> team about that but it basically went nowhere and here we are.
> 
> The Device Tree gets populated by the boot loader which figures out 
> which API is spoken and places one of those compatible strings 
> accordingly for the kernel to avoid having to do any sort of run-time 
> detection which is slow and completely unnecessary when we can simply 
> tell it ahead of time what to use.

Thanks for providing justification, quite reasonable. A pity that none
of the commit msgs answered this way.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec  6 09:33:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 18:33:53 +0100
Subject: [PATCH 2/4] memory: brcmstb_dpfe: introduce version-specific
 compatible strings
In-Reply-To: <cb1d5118-b4f6-46b3-814b-2edf16372d01@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-3-mmayer@broadcom.com>
 <7844ca22-df53-458d-9e3b-7b0758a80455@linaro.org>
 <cb1d5118-b4f6-46b3-814b-2edf16372d01@broadcom.com>
Message-ID: <7d30acd6-1f00-47d1-b7ed-05e7bdab119c@linaro.org>

On 06/12/2023 17:19, Florian Fainelli wrote:
> 
> 
> On 12/6/2023 3:09 AM, Krzysztof Kozlowski wrote:
>> On 05/12/2023 19:47, Markus Mayer wrote:
>>> Introduce compatible strings brcm,dpfe-cpu-v1 through brcm,dpfe-cpu-v3
>>> to the Broadcom DPFE driver.
>>
>> No, why?
>>
>>>
>>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
>>> ---
>>>   drivers/memory/brcmstb_dpfe.c | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
>>> index a7ab3d377206..66876b409e59 100644
>>> --- a/drivers/memory/brcmstb_dpfe.c
>>> +++ b/drivers/memory/brcmstb_dpfe.c
>>> @@ -924,6 +924,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
>>>   	{ .compatible = "brcm,bcm7271-dpfe-cpu", .data = &dpfe_api_old_v2 },
>>>   	{ .compatible = "brcm,bcm7278-dpfe-cpu", .data = &dpfe_api_old_v2 },
>>>   	{ .compatible = "brcm,bcm7211-dpfe-cpu", .data = &dpfe_api_new_v2 },
>>> +
>>> +	/* Match specific DCPU versions */
>>> +	{ .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
>>> +	{ .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
>>> +	{ .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
>>
>> Pointless change.
> 
> Is it possible to ask you as a maintainer to stop having those knee jerk 
> reactions and try to understand things a bit better, or simply request a 
> better explanation from the submitter?

I asked: "Why?". None of the commits explain the rationale behind the
change. None of them say why such change is needed. They all repeat what
the patch is doing, which is pretty easy to see from the diff. The
commit must answer the trickiest question: why are we doing this?

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec  6 09:35:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 18:35:53 +0100
Subject: [PATCH 2/6] dt-bindings: pwm: samsung: add specific compatible
 for Tesla FSD
In-Reply-To: <ZXCeWmEO3PJiK0m5@orome.fritz.box>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
 <20231205092229.19135-3-krzysztof.kozlowski@linaro.org>
 <ZXCeWmEO3PJiK0m5@orome.fritz.box>
Message-ID: <cfd9cbc6-5f66-4929-9afb-3a572e93e8ae@linaro.org>

On 06/12/2023 17:16, Thierry Reding wrote:
> On Tue, Dec 05, 2023 at 10:22:25AM +0100, Krzysztof Kozlowski wrote:
>> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
>> others it reuses several devices from older designs.  Historically we
>> kept the old (block's) compatible only.  This works fine and there is no
>> bug here, however guidelines expressed in
>> Documentation/devicetree/bindings/writing-bindings.rst state that:
>> 1. Compatibles should be specific.
>> 2. We should add new compatibles in case of bugs or features.
>>
>> Add Tesla FSD compatible specific to be used with an existing fallback.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>>
>> ---
>>
>> I propose to take the patch through Samsung SoC (me). See cover letter
>> for explanation.
>> ---
>>  Documentation/devicetree/bindings/pwm/pwm-samsung.yaml | 1 +
>>  1 file changed, 1 insertion(+)
> 
> You point to the guidelines that say we should have specific compatible> strings, but then the string that you add seems very generic. Now, I'm
> obviously not an expert on Tesla hardware, but just FSD seems to be
> quite generic according to the internet. It seems like the chip derived
> from Samsung used to be known as AP3/HW3, but there's now also AP4/HW4,
> so I wonder if those differ in some way and if these shouldn't include
> some sort of version/generation number.

That's the compatible chosen that time for entire platform, as a
consensus, for all SoC components. Thus the PWM compatible is as
specific as it can get.

Best regards,
Krzysztof



From florian.fainelli at broadcom.com  Wed Dec  6 09:36:39 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Wed, 6 Dec 2023 09:36:39 -0800
Subject: [PATCH 1/4] dt-bindings: memory: additional compatible strings
 for Broadcom DPFE
In-Reply-To: <5497447c-023b-4837-a5e2-b465ba2f624d@linaro.org>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-2-mmayer@broadcom.com>
 <f17dcd86-7f87-4433-a106-eb7bfdfb05ab@linaro.org>
 <42677f2d-190c-4043-a61d-8bfba581a764@broadcom.com>
 <5497447c-023b-4837-a5e2-b465ba2f624d@linaro.org>
Message-ID: <25177e5c-880e-4c7b-8a72-2d908a970afb@broadcom.com>

On 12/6/23 09:29, Krzysztof Kozlowski wrote:
> On 06/12/2023 17:32, Florian Fainelli wrote:
>>
>>
>> On 12/6/2023 3:09 AM, Krzysztof Kozlowski wrote:
>>> On 05/12/2023 19:47, Markus Mayer wrote:
>>>> Add versioned compatible strings for Broadcom DPFE. These take the form
>>>> brcm,dpfe-cpu-v<N> where <N> is a number from 1 to 4.
>>>>
>>>> These API version related compatible strings are more specific than the
>>>> catch-all "brcm,dpfe-cpu" and more generic than chip-specific compatible
>>>> strings.
>>>
>>> None of this explains: Why? I don't see any point in this and commit
>>> does not explain.
>>>
>>>>
>>>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
>>>> ---
>>>>    .../bindings/memory-controllers/brcm,dpfe-cpu.yaml        | 8 +++++++-
>>>>    1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>>>> index 08cbdcddfead..6dffa7b62baf 100644
>>>> --- a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>>>> +++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>>>> @@ -16,6 +16,11 @@ properties:
>>>>          - enum:
>>>>              - brcm,bcm7271-dpfe-cpu
>>>>              - brcm,bcm7268-dpfe-cpu
>>>> +      - enum:
>>>> +          - brcm,dpfe-cpu-v1
>>>> +          - brcm,dpfe-cpu-v2
>>>> +          - brcm,dpfe-cpu-v3
>>>> +          - brcm,dpfe-cpu-v4
>>>
>>> No, that's just wrong. So you want to say bcm7271 is brcm,dpfe-cpu-v4?
>>
>> No as the example shows it "speaks" API v1.
> 
> Example is not a binding. It does not matter except of validating the
> binding. This is just incorrect.
> 
>>
>> I would be inclined to completely remove the chip specific compatible
>> strings from the binding because they are not sufficient or descriptive
>> enough to determine which API version is being spoken, since the
>> firmware is unfortunately allowed to change major APIs (and the
>> messaging format, because why not?) at a moments notice.
> 
> Then versions do not give you anything more.

The versions indicate exactly which API to be spoken to with the 
firmware. The firmware API was not properly designed, it should have had 
a way to indicate which API it has, regardless of the messaging format 
it implements, but for reasons unknown that is not how it was implemented.

Essentially we need to know right away and ahead of time which API to be 
used, otherwise that means doing runtime detection like what patch 4 
does which you do not want to see.
-- 
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/7b8346b9/attachment.p7s>

From u.kleine-koenig at pengutronix.de  Wed Dec  6 09:38:50 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 6 Dec 2023 18:38:50 +0100
Subject: [PATCH 12/18] dt-bindings: pwm: add binding for mt8365 SoC
In-Reply-To: <20231023214411.sbrdqgethas25rkd@pengutronix.de>
References: <20231023-display-support-v1-0-5c860ed5c33b@baylibre.com>
 <20231023-display-support-v1-12-5c860ed5c33b@baylibre.com>
 <20231023214411.sbrdqgethas25rkd@pengutronix.de>
Message-ID: <20231206173850.s6dndsjeeuy3sjan@pengutronix.de>

Hello,

On Mon, Oct 23, 2023 at 11:44:11PM +0200, Uwe Kleine-K?nig wrote:
> On Mon, Oct 23, 2023 at 04:40:12PM +0200, Alexandre Mergnat wrote:
> > Display PWM for MT8365 is compatible with MT8183. Then, add MT8365 binding
> > along with MT8183 SoC.
> > 
> > Signed-off-by: Alexandre Mergnat <amergnat at baylibre.com>
> 
> Acked-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> 
> What is the merge plan here? Should the whole series go in via drm?

I'll assume that Alexandre will send out a new round of this series and
this patch isn't supposed to be applied as is to the pwm tree. So I'm
marking this patch as "changes requested" in our patchwork.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/35080ea4/attachment-0001.sig>

From krzysztof.kozlowski at linaro.org  Wed Dec  6 09:42:31 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 18:42:31 +0100
Subject: [PATCH 1/4] dt-bindings: memory: additional compatible strings
 for Broadcom DPFE
In-Reply-To: <25177e5c-880e-4c7b-8a72-2d908a970afb@broadcom.com>
References: <20231205184741.3092376-1-mmayer@broadcom.com>
 <20231205184741.3092376-2-mmayer@broadcom.com>
 <f17dcd86-7f87-4433-a106-eb7bfdfb05ab@linaro.org>
 <42677f2d-190c-4043-a61d-8bfba581a764@broadcom.com>
 <5497447c-023b-4837-a5e2-b465ba2f624d@linaro.org>
 <25177e5c-880e-4c7b-8a72-2d908a970afb@broadcom.com>
Message-ID: <3fff866f-fbe8-4d23-87f3-275380adf3d4@linaro.org>

On 06/12/2023 18:36, Florian Fainelli wrote:
> On 12/6/23 09:29, Krzysztof Kozlowski wrote:
>> On 06/12/2023 17:32, Florian Fainelli wrote:
>>>
>>>
>>> On 12/6/2023 3:09 AM, Krzysztof Kozlowski wrote:
>>>> On 05/12/2023 19:47, Markus Mayer wrote:
>>>>> Add versioned compatible strings for Broadcom DPFE. These take the form
>>>>> brcm,dpfe-cpu-v<N> where <N> is a number from 1 to 4.
>>>>>
>>>>> These API version related compatible strings are more specific than the
>>>>> catch-all "brcm,dpfe-cpu" and more generic than chip-specific compatible
>>>>> strings.
>>>>
>>>> None of this explains: Why? I don't see any point in this and commit
>>>> does not explain.
>>>>
>>>>>
>>>>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
>>>>> ---
>>>>>    .../bindings/memory-controllers/brcm,dpfe-cpu.yaml        | 8 +++++++-
>>>>>    1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>>>>> index 08cbdcddfead..6dffa7b62baf 100644
>>>>> --- a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>>>>> +++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml
>>>>> @@ -16,6 +16,11 @@ properties:
>>>>>          - enum:
>>>>>              - brcm,bcm7271-dpfe-cpu
>>>>>              - brcm,bcm7268-dpfe-cpu
>>>>> +      - enum:
>>>>> +          - brcm,dpfe-cpu-v1
>>>>> +          - brcm,dpfe-cpu-v2
>>>>> +          - brcm,dpfe-cpu-v3
>>>>> +          - brcm,dpfe-cpu-v4
>>>>
>>>> No, that's just wrong. So you want to say bcm7271 is brcm,dpfe-cpu-v4?
>>>
>>> No as the example shows it "speaks" API v1.
>>
>> Example is not a binding. It does not matter except of validating the
>> binding. This is just incorrect.
>>
>>>
>>> I would be inclined to completely remove the chip specific compatible
>>> strings from the binding because they are not sufficient or descriptive
>>> enough to determine which API version is being spoken, since the
>>> firmware is unfortunately allowed to change major APIs (and the
>>> messaging format, because why not?) at a moments notice.
>>
>> Then versions do not give you anything more.
> 
> The versions indicate exactly which API to be spoken to with the 
> firmware. The firmware API was not properly designed, it should have had 
> a way to indicate which API it has, regardless of the messaging format 
> it implements, but for reasons unknown that is not how it was implemented.
> 
> Essentially we need to know right away and ahead of time which API to be 
> used, otherwise that means doing runtime detection like what patch 4 
> does which you do not want to see.

Yeah, I see, you explained this deeper in response to 3/4, which I read
after this one.

Deprecating specific compatibles makes sense. If you have subset of FW
per given SoC, you could keep the specific compatible followed by subset
of version-compatibles (e.g. bcm7271 + v1 + generic fallback). However
then generic fallback is useless and you should actually drop it. The
only, *ONLY* point of generic fallback is to be used by OS alone. In
that case it cannot be used alone, so it is useless.

We do not use generic compatibles in a way of "I want to call all of
these devices a DPFE" or "I want to call it a default".

Now, if you do not have subset of FW per given SoC, so anything can
match with anything, then in one commit:
1. Deprecate specific compatible followed by useless generic fallback
2. Add versioned-compatibles alone, since generic fallback gives nothing.

Best regards,
Krzysztof



From u.kleine-koenig at pengutronix.de  Wed Dec  6 09:48:23 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 6 Dec 2023 18:48:23 +0100
Subject: [PATCH RESEND v10 0/3] Support pwm/tach driver for aspeed ast26xx
In-Reply-To: <3ea9ef0c-27c0-4304-8bf7-26710224c3b1@roeck-us.net>
References: <20231107105025.1480561-1-billy_tsai@aspeedtech.com>
 <3ea9ef0c-27c0-4304-8bf7-26710224c3b1@roeck-us.net>
Message-ID: <20231206174823.ok6rrufhez33rte5@pengutronix.de>

On Tue, Nov 07, 2023 at 11:02:43AM -0800, Guenter Roeck wrote:
> On 11/7/23 02:50, Billy Tsai wrote:
> > Unlike the old design that the register setting of the TACH should based
> > on the configure of the PWM. In ast26xx, the dependency between pwm and
> > tach controller is eliminated and becomes a separate hardware block. One
> > is used to provide pwm output and another is used to monitor the frequency
> > of the input. This driver implements them by exposing two kernel
> > subsystems: PWM and HWMON. The PWM subsystem can be utilized alongside
> > existing drivers for controlling elements such as fans (pwm-fan.c),
> > beepers (pwm-beeper.c) and so on. Through the HWMON subsystem, the driver
> > provides sysfs interfaces for fan.
> > 
> > Changes since v9:
> > Change the type of fan-driving-mode to string
> > Fix some typos and formatting issues.
> > 
> 
> What is the resend about ?

And to the original v10 there is a reply by Krzysztof;
see https://lore.kernel.org/linux-pwm/3d9e50db-19f0-43b3-8042-2f80a1e7b79e at linaro.org/ .

I'll mark the original and this resend as "changes-requested" in our
patchwork. Probably the most cooperative way to object is to send a v11
and point out the changes compared to v10.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231206/03a10a77/attachment.sig>

From linux at armlinux.org.uk  Wed Dec  6 09:51:34 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 6 Dec 2023 17:51:34 +0000
Subject: [RFC PATCH v2 3/8] net: pcs: pcs-mtk-lynxi: add platform driver
 for MT7988
In-Reply-To: <68bb81ac6bf99393c8de256f42e5715626590af8.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <68bb81ac6bf99393c8de256f42e5715626590af8.1701826319.git.daniel@makrotopia.org>
Message-ID: <ZXC0pq2C6iRmeF4B@shell.armlinux.org.uk>

On Wed, Dec 06, 2023 at 01:44:17AM +0000, Daniel Golle wrote:
> +struct phylink_pcs *mtk_pcs_lynxi_select_pcs(struct device_node *np, phy_interface_t mode)
> +{
> +	struct platform_device *pdev;
> +	struct mtk_pcs_lynxi *mpcs;
> +
> +	if (!np)
> +		return NULL;
> +
> +	if (!of_device_is_available(np))
> +		return ERR_PTR(-ENODEV);
> +
> +	if (!of_match_node(mtk_pcs_lynxi_of_match, np))
> +		return ERR_PTR(-EINVAL);
> +
> +	pdev = of_find_device_by_node(np);
> +	if (!pdev || !platform_get_drvdata(pdev)) {
> +		if (pdev)
> +			put_device(&pdev->dev);
> +		return ERR_PTR(-EPROBE_DEFER);
> +	}
> +
> +	mpcs = platform_get_drvdata(pdev);
> +	put_device(&pdev->dev);
> +
> +	return &mpcs->pcs;
> +}
> +EXPORT_SYMBOL(mtk_pcs_lynxi_select_pcs);

If you're going to play games like this, then you must mark the driver
with .suppress_bind_attrs = true to remove the bind/unbind attributes
in userspace that could wreak havoc with the above - because there is
_nothing_ that guarantees that the memory you're returning from this
function will remain intact. Basically, it's racy.

Also, I'm not sure I approve of using the "select_pcs" suffix (I
haven't spotted _where_ you use this, but returning EPROBE_DEFER to
phylink's mac_select_pcs() method doesn't do anything to defer any
probe, so that's an entirely misleading error code.

If we are going to have device drivers for PCS, then we need to
seriously think about how we look up PCS and return the phylink_pcs
pointer - and also how we handle the PCS device going away. None of
that should be coded into _any_ PCS driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From linux at armlinux.org.uk  Wed Dec  6 09:56:17 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 6 Dec 2023 17:56:17 +0000
Subject: [RFC PATCH v2 5/8] net: pcs: add driver for MediaTek USXGMII PCS
In-Reply-To: <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
Message-ID: <ZXC1wRWEx3f9MMMq@shell.armlinux.org.uk>

On Wed, Dec 06, 2023 at 01:44:38AM +0000, Daniel Golle wrote:
> +struct phylink_pcs *mtk_usxgmii_select_pcs(struct device_node *np, phy_interface_t mode)
> +{
> +	struct platform_device *pdev;
> +	struct mtk_usxgmii_pcs *mpcs;
> +
> +	if (!np)
> +		return NULL;
> +
> +	if (!of_device_is_available(np))
> +		return ERR_PTR(-ENODEV);
> +
> +	if (!of_match_node(mtk_usxgmii_of_mtable, np))
> +		return ERR_PTR(-EINVAL);
> +
> +	pdev = of_find_device_by_node(np);
> +	if (!pdev || !platform_get_drvdata(pdev)) {
> +		if (pdev)
> +			put_device(&pdev->dev);
> +		return ERR_PTR(-EPROBE_DEFER);
> +	}
> +
> +	mpcs = platform_get_drvdata(pdev);
> +	put_device(&pdev->dev);
> +
> +	return &mpcs->pcs;
> +}
> +EXPORT_SYMBOL(mtk_usxgmii_select_pcs);

All the same arguments apply here as per the lynxi driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From krzysztof.kozlowski at linaro.org  Wed Dec  6 09:56:35 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 6 Dec 2023 18:56:35 +0100
Subject: [PATCH RESEND v10 0/3] Support pwm/tach driver for aspeed ast26xx
In-Reply-To: <20231206174823.ok6rrufhez33rte5@pengutronix.de>
References: <20231107105025.1480561-1-billy_tsai@aspeedtech.com>
 <3ea9ef0c-27c0-4304-8bf7-26710224c3b1@roeck-us.net>
 <20231206174823.ok6rrufhez33rte5@pengutronix.de>
Message-ID: <ed9d28e0-f879-41f3-8679-7ed5e0eec7ce@linaro.org>

On 06/12/2023 18:48, Uwe Kleine-K?nig wrote:
> On Tue, Nov 07, 2023 at 11:02:43AM -0800, Guenter Roeck wrote:
>> On 11/7/23 02:50, Billy Tsai wrote:
>>> Unlike the old design that the register setting of the TACH should based
>>> on the configure of the PWM. In ast26xx, the dependency between pwm and
>>> tach controller is eliminated and becomes a separate hardware block. One
>>> is used to provide pwm output and another is used to monitor the frequency
>>> of the input. This driver implements them by exposing two kernel
>>> subsystems: PWM and HWMON. The PWM subsystem can be utilized alongside
>>> existing drivers for controlling elements such as fans (pwm-fan.c),
>>> beepers (pwm-beeper.c) and so on. Through the HWMON subsystem, the driver
>>> provides sysfs interfaces for fan.
>>>
>>> Changes since v9:
>>> Change the type of fan-driving-mode to string
>>> Fix some typos and formatting issues.
>>>
>>
>> What is the resend about ?
> 
> And to the original v10 there is a reply by Krzysztof;
> see https://lore.kernel.org/linux-pwm/3d9e50db-19f0-43b3-8042-2f80a1e7b79e at linaro.org/ .
> 
> I'll mark the original and this resend as "changes-requested" in our
> patchwork. Probably the most cooperative way to object is to send a v11
> and point out the changes compared to v10.

The resend might be fixing issues from v10, but who knows which and how
many. In any case it should be v11, not a resend.

Best regards,
Krzysztof



From linux at armlinux.org.uk  Wed Dec  6 09:58:08 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 6 Dec 2023 17:58:08 +0000
Subject: [RFC PATCH v2 5/8] net: pcs: add driver for MediaTek USXGMII PCS
In-Reply-To: <20231206105838.069ae288@device.home>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
 <20231206105838.069ae288@device.home>
Message-ID: <ZXC2MFn7pVX/KNmJ@shell.armlinux.org.uk>

On Wed, Dec 06, 2023 at 10:58:38AM +0100, Maxime Chevallier wrote:
> On Wed, 6 Dec 2023 01:44:38 +0000
> Daniel Golle <daniel at makrotopia.org> wrote:
> > +	/* Read USXGMII link status */
> > +	state->link = FIELD_GET(RG_PCS_RX_LINK_STATUS,
> > +				mtk_r32(mpcs, RG_PCS_RX_STATUS0));
> > +
> > +	/* Continuously repeat re-configuration sequence until link comes up */
> > +	if (!state->link) {
> > +		mtk_usxgmii_pcs_config(pcs, mpcs->neg_mode,
> > +				       state->interface, NULL, false);
> > +		return;
> 
> .pcs_get_state() isn't called only for link state polling,but also when querying
> the link state from ethtool, from phylink_ethtool_ksettings_get().
> 
> As mtk_usxgmii_pcs_config triggers a pcs reset and reconfiguration, won't this disrupt
> the link ? 

Highly likely if there's a race, but note that mtk_usxgmii_pcs_config()
only gets called if the link is *down*. I guess some IPs need a bit of
kicking to work properly.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From tanmay.shah at amd.com  Wed Dec  6 10:06:45 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Wed, 6 Dec 2023 12:06:45 -0600
Subject: [PATCH v7 3/4] remoteproc: zynqmp: add pm domains support
In-Reply-To: <CANLsYkzJgZRSz5=nzW+ATmBKemoSd3ybhKuz1CJy33hftAGiqw@mail.gmail.com>
References: <20231117174238.1876655-1-tanmay.shah@amd.com>
 <20231117174238.1876655-4-tanmay.shah@amd.com> <ZV02P3bHEhPLQHBo@p14s>
 <93487d3c-c324-4b9b-8b25-0b4ea52237b4@amd.com> <ZV+V6V2sEWgsqngk@p14s>
 <a75b22c1-66e3-4fce-ae64-de79e73f3cfa@amd.com> <ZWdwl/8LC2Nn+vCq@p14s>
 <ea2edc6e-6655-47f8-8b6d-242f5a0ef804@amd.com>
 <CANLsYkzJgZRSz5=nzW+ATmBKemoSd3ybhKuz1CJy33hftAGiqw@mail.gmail.com>
Message-ID: <2e24d9be-be10-4f80-b3af-c3e0ed003e7b@amd.com>


On 12/6/23 9:43 AM, Mathieu Poirier wrote:
> On Fri, 1 Dec 2023 at 11:10, Tanmay Shah <tanmay.shah at amd.com> wrote:
> >
> >
> > On 11/29/23 11:10 AM, Mathieu Poirier wrote:
> > > On Mon, Nov 27, 2023 at 10:33:05AM -0600, Tanmay Shah wrote:
> > > >
> > > > On 11/23/23 12:11 PM, Mathieu Poirier wrote:
> > > > > On Wed, Nov 22, 2023 at 03:00:36PM -0600, Tanmay Shah wrote:
> > > > > > Hi Mathieu,
> > > > > >
> > > > > > Please find my comments below.
> > > > > >
> > > > > > On 11/21/23 4:59 PM, Mathieu Poirier wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, Nov 17, 2023 at 09:42:37AM -0800, Tanmay Shah wrote:
> > > > > > > > Use TCM pm domains extracted from device-tree
> > > > > > > > to power on/off TCM using general pm domain framework.
> > > > > > > >
> > > > > > > > Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> > > > > > > > ---
> > > > > > > >
> > > > > > > > Changes in v7:
> > > > > > > >   - %s/pm_dev1/pm_dev_core0/r
> > > > > > > >   - %s/pm_dev_link1/pm_dev_core0_link/r
> > > > > > > >   - %s/pm_dev2/pm_dev_core1/r
> > > > > > > >   - %s/pm_dev_link2/pm_dev_core1_link/r
> > > > > > > >   - remove pm_domain_id check to move next patch
> > > > > > > >   - add comment about how 1st entry in pm domain list is used
> > > > > > > >   - fix loop when jump to fail_add_pm_domains loop
> > > > > > > >
> > > > > > > >  drivers/remoteproc/xlnx_r5_remoteproc.c | 215 +++++++++++++++++++++++-
> > > > > > > >  1 file changed, 212 insertions(+), 3 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > > index 4395edea9a64..22bccc5075a0 100644
> > > > > > > > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > > @@ -16,6 +16,7 @@
> > > > > > > >  #include <linux/of_reserved_mem.h>
> > > > > > > >  #include <linux/platform_device.h>
> > > > > > > >  #include <linux/remoteproc.h>
> > > > > > > > +#include <linux/pm_domain.h>
> > > > > > > >
> > > > > > > >  #include "remoteproc_internal.h"
> > > > > > > >
> > > > > > > > @@ -102,6 +103,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
> > > > > > > >   * @rproc: rproc handle
> > > > > > > >   * @pm_domain_id: RPU CPU power domain id
> > > > > > > >   * @ipi: pointer to mailbox information
> > > > > > > > + * @num_pm_dev: number of tcm pm domain devices for this core
> > > > > > > > + * @pm_dev_core0: pm domain virtual devices for power domain framework
> > > > > > > > + * @pm_dev_core0_link: pm domain device links after registration
> > > > > > > > + * @pm_dev_core1: used only in lockstep mode. second core's pm domain virtual devices
> > > > > > > > + * @pm_dev_core1_link: used only in lockstep mode. second core's pm device links after
> > > > > > > > + * registration
> > > > > > > >   */
> > > > > > > >  struct zynqmp_r5_core {
> > > > > > > >     struct device *dev;
> > > > > > > > @@ -111,6 +118,11 @@ struct zynqmp_r5_core {
> > > > > > > >     struct rproc *rproc;
> > > > > > > >     u32 pm_domain_id;
> > > > > > > >     struct mbox_info *ipi;
> > > > > > > > +   int num_pm_dev;
> > > > > > > > +   struct device **pm_dev_core0;
> > > > > > > > +   struct device_link **pm_dev_core0_link;
> > > > > > > > +   struct device **pm_dev_core1;
> > > > > > > > +   struct device_link **pm_dev_core1_link;
> > > > > > > >  };
> > > > > > > >
> > > > > > > >  /**
> > > > > > > > @@ -651,7 +663,8 @@ static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
> > > > > > > >                                          ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> > > > > > > >                                          ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> > > > > > > >             if (ret < 0) {
> > > > > > > > -                   dev_err(dev, "failed to turn on TCM 0x%x", pm_domain_id);
> > > > > > > > +                   dev_err(dev, "failed to turn on TCM 0x%x",
> > > > > > > > +                           pm_domain_id);
> > > > > > >
> > > > > > > Spurious change, you should have caught that.
> > > > > >
> > > > > > Ack, need to observe changes more closely before sending them.
> > > > > >
> > > > > > >
> > > > > > > >                     goto release_tcm_lockstep;
> > > > > > > >             }
> > > > > > > >
> > > > > > > > @@ -758,6 +771,189 @@ static int zynqmp_r5_parse_fw(struct rproc *rproc, const struct firmware *fw)
> > > > > > > >     return ret;
> > > > > > > >  }
> > > > > > > >
> > > > > > > > +static void zynqmp_r5_remove_pm_domains(struct rproc *rproc)
> > > > > > > > +{
> > > > > > > > +   struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > > > +   struct device *dev = r5_core->dev;
> > > > > > > > +   struct zynqmp_r5_cluster *cluster;
> > > > > > > > +   int i;
> > > > > > > > +
> > > > > > > > +   cluster = platform_get_drvdata(to_platform_device(dev->parent));
> > > > > > > > +
> > > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > > +           device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core0[i], false);
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   kfree(r5_core->pm_dev_core0);
> > > > > > > > +   r5_core->pm_dev_core0 = NULL;
> > > > > > > > +   kfree(r5_core->pm_dev_core0_link);
> > > > > > > > +   r5_core->pm_dev_core0_link = NULL;
> > > > > > > > +
> > > > > > > > +   if (cluster->mode == SPLIT_MODE) {
> > > > > > > > +           r5_core->num_pm_dev = 0;
> > > > > > > > +           return;
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > > +           device_link_del(r5_core->pm_dev_core1_link[i]);
> > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core1[i], false);
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   kfree(r5_core->pm_dev_core1);
> > > > > > > > +   r5_core->pm_dev_core1 = NULL;
> > > > > > > > +   kfree(r5_core->pm_dev_core1_link);
> > > > > > > > +   r5_core->pm_dev_core1_link = NULL;
> > > > > > > > +   r5_core->num_pm_dev = 0;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +static int zynqmp_r5_add_pm_domains(struct rproc *rproc)
> > > > > > > > +{
> > > > > > > > +   struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > > > +   struct device *dev = r5_core->dev, *dev2;
> > > > > > > > +   struct zynqmp_r5_cluster *cluster;
> > > > > > > > +   struct platform_device *pdev;
> > > > > > > > +   struct device_node *np;
> > > > > > > > +   int i, j, num_pm_dev, ret;
> > > > > > > > +
> > > > > > > > +   cluster = dev_get_drvdata(dev->parent);
> > > > > > > > +
> > > > > > > > +   /* get number of power-domains */
> > > > > > > > +   num_pm_dev = of_count_phandle_with_args(r5_core->np, "power-domains",
> > > > > > > > +                                           "#power-domain-cells");
> > > > > > > > +
> > > > > > > > +   if (num_pm_dev <= 0)
> > > > > > > > +           return -EINVAL;
> > > > > > > > +
> > > > > > > > +   r5_core->pm_dev_core0 = kcalloc(num_pm_dev,
> > > > > > > > +                                   sizeof(struct device *),
> > > > > > > > +                                   GFP_KERNEL);
> > > > > > > > +   if (!r5_core->pm_dev_core0)
> > > > > > > > +           ret = -ENOMEM;
> > > > > > > > +
> > > > > > > > +   r5_core->pm_dev_core0_link = kcalloc(num_pm_dev,
> > > > > > > > +                                        sizeof(struct device_link *),
> > > > > > > > +                                        GFP_KERNEL);
> > > > > > > > +   if (!r5_core->pm_dev_core0_link) {
> > > > > > > > +           kfree(r5_core->pm_dev_core0);
> > > > > > > > +           r5_core->pm_dev_core0 = NULL;
> > > > > > > > +           return -ENOMEM;
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   r5_core->num_pm_dev = num_pm_dev;
> > > > > > > > +
> > > > > > > > +   /*
> > > > > > > > +    * start from 2nd entry in power-domains property list as
> > > > > > > > +    * for zynqmp we only add TCM power domains and not core's power domain.
> > > > > > > > +    * 1st entry is used to configure r5 operation mode.
> > > > > > >
> > > > > > > You are still not saying _where_ ->pm_dev_core0[0] gets added.
> > > > > >
> > > > > > So, pm_dev_core0[0] isn't really need to be added for zynqmp platform, as firmware starts it with call,
> > > > > >
> > > > > > zynqmp_pm_request_wake during rproc_start callback. I will document this in next
> > > > > >
> > > > >
> > > > > That is exactly what I am looking for.  That way people don't have to go through
> > > > > the entire driver trying to figure out what is happening with pm_dev_core[0].
> > > > >
> > > > > I'm also not sure about the power-up order.  Logically the TCMs should be
> > > > > powered up before the R5 in order to put code in them.  The R5s are powered in
> > > > > zynqmp_r5_rproc_start() but I am unclear as to where in the boot sequence the
> > > > > TCMs are powered - can you expand on that?
> > > >
> > > >
> > > > Sure. Following is call sequece
> > > >
> > > > zynqmp_r5_rproc_prepare
> > > >
> > > > zynqmp_r5_add_pm_domains -> Here TCM is powered on when device_link_add is called via zynqmp-pm-domains.c driver.
> > > >
> > > > . . .
> > > >
> > > > zynqmp_r5_rproc_start -> load firmware and Starts RPU
> > > >
> > > > So what you mentioned is correct, TCM is being powerd-on before we load firmware and start RPU.
> > > >
> > > >
> > > > >
> > > > > > revision. For new platforms pm_dev_core0[0] will be added in future.
> > > > >
> > > > > Now I'm really confused - what do you mean by "pm_dev_core0[0] will be added in
> > > > > future"?
> > > >
> > > >
> > > > ZynqMP platform has platform management firmware running on microblaze.
> > > >
> > > > This firmware design does not expect R5 pm domains to be requested explicitly.
> > > >
> > > > This means, during zynqmp_r5_rproc_start when "zynqmp_pm_request_wake" is called,
> > > >
> > > > firmware powers on R5. So, pm_dev_core[0] is not really used for ZynqMP.
> > > >
> > > > However, this design was changed for new platforms i.e. "versal" and onwards.
> > > >
> > > > Firmware of new platform expects pm domains to be requested explicitly for R5 cores before
> > > >
> > > > waking them up.
> > > >
> > > > That means, pm_dev_core[0] for R5 cores on new platform (Versal) needs to be used same as TCM.
> > > >
> > > > Then, we should wake it up on r5_core.
> > > >
> > > > To summarize:
> > > >
> > > > For zynqmp only following call needed to start R5:
> > > >
> > > > zynqmp_pm_request_wake
> > > >
> > > > For "versal" and onwards we need two calls to start R5:
> > > >
> > > > "device_link_add" and zynqmp_pm_request_wake
> > > >
> > > > So, in future pm_core_dev[0] will be used.
> > > >
> > >
> > > Thanks for the clarification on both front.  The problem here is that we are
> > > keeping R5 power domain information in two different places, i.e
> > > zynqmp_r5_core::pm_domain_id and zynqmp_r5_core::pm_dev_core0[0].
> > >
> > > Please see if you can retreive the power domain ID from
> > > zynqmp_r5_core::pm_dev_core0[0].  That way you can get the power domain ID when
> > > calling zynqmp_pm_request_wake() and zynqmp_pm_force_pwrdwn() and get rid of
> > > zynqmp_r5_core::pm_domain_id.
> >
> > Hi Mathieu,
> >
> > I looked into this. Probably I can't retrieve pm_domain_id from pm_dev_core0[0],
> >
> > However, I can retrieve it from device-tree when calling zynqmp_pm_request_wake
> >
> > and zynqmp_pm_force_pwrdwn.
> >
> > zynqmp_r5_core::pm_domain_id is caching that value during probe, and use it during
> > rest of the driver lifecycle.
> >
> > I am okay either way, (keeping it as it is, or get it from device-tree). Let me know your
> >
> > preference.
> >
>
> Humm...  Then I suggest to simply get rid of the device linking to
> deal with the TCMs' power management.  From where I stand it provides
> more confusion than benefits, and that is without considering the
> extra complexity.


Do you mean to get rid of pm_dev_core0[1], and pm_dev_core0[2] as well ?

If yes, its preferred to use pm_domain framework to power-on/off TCM.

If we want to get rid of zynqmp_r5_core::pm_domain_id, I will do what's done in

__genpd_dev_pm_attach API where, pm_domain_id is retrieved using of_node of pm_dev_core0[*] device.

??? ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
??????????????????????????? "#power-domain-cells", index, &pd_args);

However, Its preferred to use pm_domain framework when power-domains are available in device-tree.

Let? me know.

Thanks,

Tanmay


> > Thanks,
> >
> > Tanmay
> >
> > > >
> > > > > >
> > > > > > I hope this meets expectations.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > > +    */
> > > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > > +           r5_core->pm_dev_core0[i] = dev_pm_domain_attach_by_id(dev, i);
> > > > > > > > +           if (IS_ERR_OR_NULL(r5_core->pm_dev_core0[i])) {
> > > > > > >
> > > > > > > Here IS_ERR_OR_NULL() is used while two if conditions for NULL and an error
> > > > > > > code are used in the loop for the lockstep mode.  Please pick one heuristic and
> > > > > > > stick with it.  I have no preference on which one.
> > > > > >
> > > > > > Ok, I think IS_ERR_OR_NULL is more cleaner, I will address it in next revision.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > > +                   dev_dbg(dev, "failed to attach pm domain %d, ret=%ld\n", i,
> > > > > > > > +                           PTR_ERR(r5_core->pm_dev_core0[i]));
> > > > > > > > +                   ret = -EINVAL;
> > > > > > > > +                   goto fail_add_pm_domains;
> > > > > > > > +           }
> > > > > > > > +           r5_core->pm_dev_core0_link[i] = device_link_add(dev,
> > > > > > > > +                                                           r5_core->pm_dev_core0[i],
> > > > > > > > +                                                           DL_FLAG_STATELESS |
> > > > > > > > +                                                           DL_FLAG_RPM_ACTIVE |
> > > > > > > > +                                                           DL_FLAG_PM_RUNTIME);
> > > > > > > > +           if (!r5_core->pm_dev_core0_link[i]) {
> > > > > > > > +                   dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > > > +                   r5_core->pm_dev_core0[i] = NULL;
> > > > > > > > +                   ret = -EINVAL;
> > > > > > > > +                   goto fail_add_pm_domains;
> > > > > > > > +           }
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   if (cluster->mode == SPLIT_MODE)
> > > > > > > > +           return 0;
> > > > > > > > +
> > > > > > > > +   r5_core->pm_dev_core1 = kcalloc(num_pm_dev,
> > > > > > > > +                                   sizeof(struct device *),
> > > > > > > > +                                   GFP_KERNEL);
> > > > > > > > +   if (!r5_core->pm_dev_core1) {
> > > > > > > > +           ret = -ENOMEM;
> > > > > > > > +           goto fail_add_pm_domains;
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   r5_core->pm_dev_core1_link = kcalloc(num_pm_dev,
> > > > > > > > +                                        sizeof(struct device_link *),
> > > > > > > > +                                        GFP_KERNEL);
> > > > > > > > +   if (!r5_core->pm_dev_core1_link) {
> > > > > > > > +           kfree(r5_core->pm_dev_core1);
> > > > > > > > +           r5_core->pm_dev_core1 = NULL;
> > > > > > > > +           ret = -ENOMEM;
> > > > > > > > +           goto fail_add_pm_domains;
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   /* get second core's device to detach its power-domains */
> > > > > > > > +   np = of_get_next_child(cluster->dev->of_node, of_node_get(dev->of_node));
> > > > > > > > +
> > > > > > > > +   pdev = of_find_device_by_node(np);
> > > > > > > > +   if (!pdev) {
> > > > > > > > +           dev_err(cluster->dev, "core1 platform device not available\n");
> > > > > > > > +           kfree(r5_core->pm_dev_core1);
> > > > > > > > +           kfree(r5_core->pm_dev_core1_link);
> > > > > > > > +           r5_core->pm_dev_core1 = NULL;
> > > > > > > > +           r5_core->pm_dev_core1_link = NULL;
> > > > > > > > +           ret = -EINVAL;
> > > > > > > > +           goto fail_add_pm_domains;
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   dev2 = &pdev->dev;
> > > > > > > > +
> > > > > > > > +   /* for zynqmp we only add TCM power domains and not core's power domain */
> > > > > > > > +   for (j = 1; j < r5_core->num_pm_dev; j++) {
> > > > > > > > +           r5_core->pm_dev_core1[j] = dev_pm_domain_attach_by_id(dev2, j);
> > > > > > > > +           if (!r5_core->pm_dev_core1[j]) {
> > > > > > > > +                   dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > > > +                   ret = -EINVAL;
> > > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > > +           } else if (IS_ERR(r5_core->pm_dev_core1[j])) {
> > > > > > > > +                   dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > > > +                   ret = PTR_ERR(r5_core->pm_dev_core1[j]);
> > > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > > +           }
> > > > > > > > +
> > > > > > > > +           r5_core->pm_dev_core1_link[j] = device_link_add(dev,
> > > > > > > > +                                                           r5_core->pm_dev_core1[j],
> > > > > > > > +                                                           DL_FLAG_STATELESS |
> > > > > > > > +                                                           DL_FLAG_RPM_ACTIVE |
> > > > > > > > +                                                           DL_FLAG_PM_RUNTIME);
> > > > > > > > +           if (!r5_core->pm_dev_core1_link[j]) {
> > > > > > > > +                   dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > > > +                   r5_core->pm_dev_core1[j] = NULL;
> > > > > > > > +                   ret = -ENODEV;
> > > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > > +           }
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +fail_add_pm_domains_lockstep:
> > > > > > > > +   while (--j >= 0) {
> > > > > > > > +           device_link_del(r5_core->pm_dev_core1_link[j]);
> > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > > > +   }
> > > > > > > > +   kfree(r5_core->pm_dev_core1);
> > > > > > > > +   r5_core->pm_dev_core1 = NULL;
> > > > > > > > +   kfree(r5_core->pm_dev_core1_link);
> > > > > > > > +   r5_core->pm_dev_core1_link = NULL;
> > > > > > > > +
> > > > > > > > +fail_add_pm_domains:
> > > > > > > > +   while (--i >= 0) {
> > > > > > > > +           device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > > > +   }
> > > > > > > > +   kfree(r5_core->pm_dev_core0);
> > > > > > > > +   r5_core->pm_dev_core0 = NULL;
> > > > > > > > +   kfree(r5_core->pm_dev_core0_link);
> > > > > > > > +   r5_core->pm_dev_core0_link = NULL;
> > > > > > > > +
> > > > > > >
> > > > > > > The error path is much cleaner and readable now.
> > > > > > >
> > > > > > > I will continue tomorrow.
> > > > > > >
> > > > > > > Mathieu
> > > > > > >
> > > > > > > > +   return ret;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > >  /**
> > > > > > > >   * zynqmp_r5_rproc_prepare()
> > > > > > > >   * adds carveouts for TCM bank and reserved memory regions
> > > > > > > > @@ -770,19 +966,30 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
> > > > > > > >  {
> > > > > > > >     int ret;
> > > > > > > >
> > > > > > > > +   ret = zynqmp_r5_add_pm_domains(rproc);
> > > > > > > > +   if (ret) {
> > > > > > > > +           dev_err(&rproc->dev, "failed to add pm domains\n");
> > > > > > > > +           return ret;
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > >     ret = add_tcm_banks(rproc);
> > > > > > > >     if (ret) {
> > > > > > > >             dev_err(&rproc->dev, "failed to get TCM banks, err %d\n", ret);
> > > > > > > > -           return ret;
> > > > > > > > +           goto fail_prepare;
> > > > > > > >     }
> > > > > > > >
> > > > > > > >     ret = add_mem_regions_carveout(rproc);
> > > > > > > >     if (ret) {
> > > > > > > >             dev_err(&rproc->dev, "failed to get reserve mem regions %d\n", ret);
> > > > > > > > -           return ret;
> > > > > > > > +           goto fail_prepare;
> > > > > > > >     }
> > > > > > > >
> > > > > > > >     return 0;
> > > > > > > > +
> > > > > > > > +fail_prepare:
> > > > > > > > +   zynqmp_r5_remove_pm_domains(rproc);
> > > > > > > > +
> > > > > > > > +   return ret;
> > > > > > > >  }
> > > > > > > >
> > > > > > > >  /**
> > > > > > > > @@ -801,6 +1008,8 @@ static int zynqmp_r5_rproc_unprepare(struct rproc *rproc)
> > > > > > > >
> > > > > > > >     r5_core = rproc->priv;
> > > > > > > >
> > > > > > > > +   zynqmp_r5_remove_pm_domains(rproc);
> > > > > > > > +
> > > > > > > >     for (i = 0; i < r5_core->tcm_bank_count; i++) {
> > > > > > > >             pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
> > > > > > > >             if (zynqmp_pm_release_node(pm_domain_id))
> > > > > > > > --
> > > > > > > > 2.25.1
> > > > > > > >


From cfsworks at gmail.com  Wed Dec  6 10:26:40 2023
From: cfsworks at gmail.com (Sam Edwards)
Date: Wed, 6 Dec 2023 11:26:40 -0700
Subject: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing
 RK1
In-Reply-To: <3331042.e9J7NaK4W3@diego>
References: <20231205202900.4617-1-CFSworks@gmail.com>
 <3331042.e9J7NaK4W3@diego>
Message-ID: <d38540c5-79a8-0582-87b9-0e99bf3044d5@gmail.com>



On 12/6/23 07:55, Heiko St?bner wrote:
> Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards:
>> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
>> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
>> will sometimes (varying between specific RK3588 chips, not over time) shut
>> off the DBI block, and reads to this range will instead stall
>> indefinitely.
>>
>> When this happens, it will prevent Linux from booting altogether. The
>> PCIe driver will stall the CPU core once it attempts to read the version
>> information from the DBI range.
>>
>> Fix this boot hang by adding the correct pinctrl configuration to the
>> PCIe 3.0 device node, which is the proper thing to do anyway. While
>> we're at it, also add the necessary configuration to the PCIe 2.0 node,
>> which may or may not fix the equivalent problem over there -- but is the
>> proper thing to do anyway. :)
>>
>> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
>> Signed-off-by: Sam Edwards <CFSworks at gmail.com>
>> ---
>>   .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------
>>   1 file changed, 2 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
>> index 9570b34aca2e..129f14dbd42f 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
>> @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy at 1 {
>>   &pcie2x1l1 {
>>   	linux,pci-domain = <1>;
>>   	pinctrl-names = "default";
>> -	pinctrl-0 = <&pcie2_reset>;
>> +	pinctrl-0 = <&pcie30x1m1_pins>;
>>   	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
>>   	status = "okay";
>>   };
>> @@ -226,7 +226,7 @@ &pcie30phy {
>>   &pcie3x4 {
>>   	linux,pci-domain = <0>;
>>   	pinctrl-names = "default";
>> -	pinctrl-0 = <&pcie3_reset>;
>> +	pinctrl-0 = <&pcie30x4m1_pins>;

Hi Heiko,

> 
> also, why are you throwing out the pinctrl for the reset pin.
> That seems not related to the regular pins and you could instead just do
> 
> +	pinctrl-0 = <&pcie30x4m1_pins>, <&pcie3_reset>;

The pcie30x4m1_pins def does include pinmuxing `4 RK_PB6` to the DW 
controller already. The v2 patch should probably instead remove the 
reset-gpios property, since an out-of-band GPIO reset is not needed when 
the controller can do it.

I'm still looking into the story with the PCIe 2.0 pins, since 2.0x1's 
PERST# is definitely 4A2. I'll ask around and try to find out where the 
corresponding CLKREQ# is going.

> 
> Thanks
> Heiko

Likewise,
Sam

> 
>>   	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
>>   	vpcie3v3-supply = <&vcc3v3_pcie30>;
>>   	status = "okay";
>> @@ -245,17 +245,7 @@ hym8563_int: hym8563-int {
>>   		};
>>   	};
>>   
>> -	pcie2 {
>> -		pcie2_reset: pcie2-reset {
>> -			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
>> -		};
>> -	};
>> -
>>   	pcie3 {
>> -		pcie3_reset: pcie3-reset {
>> -			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
>> -		};
>> -
>>   		vcc3v3_pcie30_en: pcie3-reg {
>>   			rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
>>   		};
>>
> 
> 
> 
> 


From mmayer at broadcom.com  Wed Dec  6 10:48:30 2023
From: mmayer at broadcom.com (Markus Mayer)
Date: Wed, 6 Dec 2023 10:48:30 -0800
Subject: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
In-Reply-To: <c483e962-a565-45b0-91e2-41f47e2cf4bb@linaro.org>
References: <20231205184741.3092376-1-mmayer@broadcom.com> <20231205184741.3092376-4-mmayer@broadcom.com>
 <e63906cf-9f76-4fed-91b0-1a9168b179bd@linaro.org> <12f3c515-71cf-46a5-ad92-15bf6c4c2f2c@broadcom.com>
 <c483e962-a565-45b0-91e2-41f47e2cf4bb@linaro.org>
Message-ID: <CAGt4E5smwohGsPkvFOY8o270mNQnTkSWz8UKh3un2=XtEibzAg@mail.gmail.com>

On Wed, 6 Dec 2023 at 09:32, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 06/12/2023 17:18, Florian Fainelli wrote:
> >
> >
> > On 12/6/2023 3:10 AM, Krzysztof Kozlowski wrote:
> >> On 05/12/2023 19:47, Markus Mayer wrote:
> >>> Add support for version 4 of the DPFE API. This new version is largely
> >>> identical to version 3. The main difference is that all commands now
> >>> take the MHS version number as the first argument. Any other arguments
> >>> have been pushed down by one (i.e. what used to be arg0 in v3 is arg1 in
> >>> v4).
> >>>
> >>> Signed-off-by: Markus Mayer <mmayer at broadcom.com>
> >>
> >> ...
> >>
> >>> +
> >>>   static const char *get_error_text(unsigned int i)
> >>>   {
> >>>     static const char * const error_text[] = {
> >>> @@ -929,8 +954,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
> >>>     { .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
> >>>     { .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
> >>>     { .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
> >>> +   { .compatible = "brcm,dpfe-cpu-v4", .data = &dpfe_api_v4 },
> >>>
> >>
> >> No, use SoC specific compatible.
> >
> > This is not that simple because for a given SoC, the API implemented by
> > the firmware can change, in fact it has changed over the lifetime of a
> > given SoC as firmware updates get rolled out. Arguably the dialect
> > spoken by the firmware should not have changed and we told the firmware
> > team about that but it basically went nowhere and here we are.
> >
> > The Device Tree gets populated by the boot loader which figures out
> > which API is spoken and places one of those compatible strings
> > accordingly for the kernel to avoid having to do any sort of run-time
> > detection which is slow and completely unnecessary when we can simply
> > tell it ahead of time what to use.
>
> Thanks for providing justification, quite reasonable. A pity that none
> of the commit msgs answered this way.

The real pity is how this API was designed, making all of this
necessary in the first place.

We can definitely spell out more clearly in the commit messages what
is going on and why all of this is needed. I'll pull all the pieces
together from the various responses. As long as there's a way we can
reasonably implement what we need, we'll be happy.

> Best regards,
> Krzysztof


From linux at armlinux.org.uk  Wed Dec  6 10:55:50 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 6 Dec 2023 18:55:50 +0000
Subject: [RFC PATCH v2 8/8] net: ethernet: mtk_eth_soc: add paths and
 SerDes modes for MT7988
In-Reply-To: <3ccc33fa14310ab47e90ff8e6ce46f1562bb838e.1701826319.git.daniel@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <3ccc33fa14310ab47e90ff8e6ce46f1562bb838e.1701826319.git.daniel@makrotopia.org>
Message-ID: <ZXDDtmRklS6o994V@shell.armlinux.org.uk>

On Wed, Dec 06, 2023 at 01:45:17AM +0000, Daniel Golle wrote:
> @@ -516,6 +538,21 @@ static struct phylink_pcs *mtk_mac_select_pcs(struct phylink_config *config,
>  	struct mtk_eth *eth = mac->hw;
>  	unsigned int sid;
>  
> +	if (mtk_is_netsys_v3_or_greater(eth)) {
> +		switch (interface) {
> +		case PHY_INTERFACE_MODE_1000BASEX:
> +		case PHY_INTERFACE_MODE_2500BASEX:
> +		case PHY_INTERFACE_MODE_SGMII:
> +			return mtk_pcs_lynxi_select_pcs(mac->sgmii_pcs_of_node, interface);
> +		case PHY_INTERFACE_MODE_5GBASER:
> +		case PHY_INTERFACE_MODE_10GBASER:
> +		case PHY_INTERFACE_MODE_USXGMII:
> +			return mtk_usxgmii_select_pcs(mac->usxgmii_pcs_of_node, interface);

>From what I can see, neither of these two "select_pcs" methods that
you're calling makes any use of the "interface" you pass to them.
I'm not sure what they _could_ do with it either, given that what
you're effectively doing here is getting the phylink_pcs structure from
the driver, and each one only has a single phylink_pcs.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From maxime.chevallier at bootlin.com  Wed Dec  6 10:58:02 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Wed, 6 Dec 2023 19:58:02 +0100
Subject: [RFC PATCH v2 5/8] net: pcs: add driver for MediaTek USXGMII
 PCS
In-Reply-To: <ZXC2MFn7pVX/KNmJ@shell.armlinux.org.uk>
References: <cover.1701826319.git.daniel@makrotopia.org>
	<3cd8af5e44554c2db2d7898494ee813967206bd9.1701826319.git.daniel@makrotopia.org>
	<20231206105838.069ae288@device.home>
	<ZXC2MFn7pVX/KNmJ@shell.armlinux.org.uk>
Message-ID: <20231206195802.5d2562e7@device.home>

On Wed, 6 Dec 2023 17:58:08 +0000
"Russell King (Oracle)" <linux at armlinux.org.uk> wrote:

> On Wed, Dec 06, 2023 at 10:58:38AM +0100, Maxime Chevallier wrote:
> > On Wed, 6 Dec 2023 01:44:38 +0000
> > Daniel Golle <daniel at makrotopia.org> wrote:  
> > > +	/* Read USXGMII link status */
> > > +	state->link = FIELD_GET(RG_PCS_RX_LINK_STATUS,
> > > +				mtk_r32(mpcs, RG_PCS_RX_STATUS0));
> > > +
> > > +	/* Continuously repeat re-configuration sequence until link comes up */
> > > +	if (!state->link) {
> > > +		mtk_usxgmii_pcs_config(pcs, mpcs->neg_mode,
> > > +				       state->interface, NULL, false);
> > > +		return;  
> > 
> > .pcs_get_state() isn't called only for link state polling,but also when querying
> > the link state from ethtool, from phylink_ethtool_ksettings_get().
> > 
> > As mtk_usxgmii_pcs_config triggers a pcs reset and reconfiguration, won't this disrupt
> > the link ?   
> 
> Highly likely if there's a race, but note that mtk_usxgmii_pcs_config()
> only gets called if the link is *down*. I guess some IPs need a bit of
> kicking to work properly.
> 
Ah right that's true, it should be OK then.

Thanks,

Maxime


From catalin.marinas at arm.com  Wed Dec  6 10:58:44 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 6 Dec 2023 18:58:44 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231206172035.GU2692119@nvidia.com>
References: <20231205164318.GG2692119@nvidia.com>
 <86bkb4bn2v.wl-maz@kernel.org>
 <ZW9ezSGSDIvv5MsQ@arm.com>
 <86a5qobkt8.wl-maz@kernel.org>
 <ZW9uqu7yOtyZfmvC@arm.com>
 <868r67blwo.wl-maz@kernel.org>
 <ZXBlmt88dKmZLCU9@arm.com>
 <20231206151603.GR2692119@nvidia.com>
 <ZXCh9N2xp0efHcpE@arm.com>
 <20231206172035.GU2692119@nvidia.com>
Message-ID: <ZXDEZO6sS1dE_to9@arm.com>

On Wed, Dec 06, 2023 at 01:20:35PM -0400, Jason Gunthorpe wrote:
> On Wed, Dec 06, 2023 at 04:31:48PM +0000, Catalin Marinas wrote:
> > > This would be fine, as would a VMA flag. Please pick one :)
> > > 
> > > I think a VMA flag is simpler than messing with pgprot.
> > 
> > I guess one could write a patch and see how it goes ;).
> 
> A lot of patches have been sent on this already :(

But not one with a VM_* flag. I guess we could also add a VM_VFIO flag
which implies KVM has less restrictions on the memory type. I think
that's more bike-shedding.

The key point is that we don't want to relax this for whatever KVM may
map in the guest but only for certain devices. Just having a vma may not
be sufficient, we can't tell where that vma came from.

So for the vfio bits, completely untested:

-------------8<----------------------------
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 1929103ee59a..b89d2dfcd534 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1863,7 +1863,7 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
 	 * See remap_pfn_range(), called from vfio_pci_fault() but we can't
 	 * change vm_flags within the fault handler.  Set them now.
 	 */
-	vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
+	vm_flags_set(vma, VM_VFIO | VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
 	vma->vm_ops = &vfio_pci_mmap_ops;

 	return 0;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 418d26608ece..6df46fd7836a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -391,6 +391,13 @@ extern unsigned int kobjsize(const void *objp);
 # define VM_UFFD_MINOR		VM_NONE
 #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */

+#ifdef CONFIG_64BIT
+#define VM_VFIO_BIT		39
+#define VM_VFIO			BIT(VM_VFIO_BIT)
+#else
+#define VM_VFIO			VM_NONE
+#endif
+
 /* Bits set in the VMA until the stack is in its final location */
 #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
-------------8<----------------------------

In KVM, Akita's patch would take this into account, not just rely on
"device==true".

> > > > If we want the VMM to drive this entirely, we could add a new mmap()
> > > > flag like MAP_WRITECOMBINE or PROT_WRITECOMBINE. They do feel a bit
> > > 
> > > As in the other thread, we cannot unconditionally map NORMAL_NC into
> > > the VMM.
> > 
> > I'm not suggesting this but rather the VMM map portions of the BAR with
> > either Device or Normal-NC, concatenate them (MAP_FIXED) and pass this
> > range as a memory slot (or multiple if a slot doesn't allow multiple
> > vmas).
> 
> The VMM can't know what to do. We already talked about this. The VMM
> cannot be involved in the decision to make pages NORMAL_NC or
> not. That idea ignores how actual devices work.
[...]
> > Are the Device/Normal offsets within a BAR fixed, documented in e.g. the
> > spec or this is something configurable via some MMIO that the guest
> > does.
> 
> No, it is fully dynamic on demand with firmware RPCs.

I think that's a key argument. The VMM cannot, on its own, configure the
BAR and figure a way to communicate this to the guest. We could invent
some para-virtualisation/trapping mechanism but that's unnecessarily
complicated. In the DPDK case, DPDK both configures and interacts with
the device. In the VMM/VM case, we need the VM to do this, we can't
split the configuration in VMM and interaction with the device in the
VM.

-- 
Catalin


From jgg at nvidia.com  Wed Dec  6 11:03:56 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 6 Dec 2023 15:03:56 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZXDEZO6sS1dE_to9@arm.com>
References: <86bkb4bn2v.wl-maz@kernel.org>
 <ZW9ezSGSDIvv5MsQ@arm.com>
 <86a5qobkt8.wl-maz@kernel.org>
 <ZW9uqu7yOtyZfmvC@arm.com>
 <868r67blwo.wl-maz@kernel.org>
 <ZXBlmt88dKmZLCU9@arm.com>
 <20231206151603.GR2692119@nvidia.com>
 <ZXCh9N2xp0efHcpE@arm.com>
 <20231206172035.GU2692119@nvidia.com>
 <ZXDEZO6sS1dE_to9@arm.com>
Message-ID: <20231206190356.GD2692119@nvidia.com>

On Wed, Dec 06, 2023 at 06:58:44PM +0000, Catalin Marinas wrote:

> -------------8<----------------------------
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index 1929103ee59a..b89d2dfcd534 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -1863,7 +1863,7 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
>  	 * See remap_pfn_range(), called from vfio_pci_fault() but we can't
>  	 * change vm_flags within the fault handler.  Set them now.
>  	 */
> -	vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
> +	vm_flags_set(vma, VM_VFIO | VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
>  	vma->vm_ops = &vfio_pci_mmap_ops;
> 
>  	return 0;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 418d26608ece..6df46fd7836a 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -391,6 +391,13 @@ extern unsigned int kobjsize(const void *objp);
>  # define VM_UFFD_MINOR		VM_NONE
>  #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
> 
> +#ifdef CONFIG_64BIT
> +#define VM_VFIO_BIT		39
> +#define VM_VFIO			BIT(VM_VFIO_BIT)
> +#else
> +#define VM_VFIO			VM_NONE
> +#endif
> +
>  /* Bits set in the VMA until the stack is in its final location */
>  #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
> -------------8<----------------------------
> 
> In KVM, Akita's patch would take this into account, not just rely on
> "device==true".

Yes, Ankit let's try this please. I would not call it VM_VFIO though

VM_VFIO_ALLOW_WC ?

Introduce it in a separate patch and summarize this thread, with a
suggested-by from Catalin :)

Cc Sean Christopherson <seanjc at google.com> too as x86 kvm might
support the idea

> I think that's a key argument. The VMM cannot, on its own, configure the
> BAR and figure a way to communicate this to the guest. We could invent
> some para-virtualisation/trapping mechanism but that's unnecessarily
> complicated. In the DPDK case, DPDK both configures and interacts with
> the device. In the VMM/VM case, we need the VM to do this, we can't
> split the configuration in VMM and interaction with the device in the
> VM.

Yes

Thanks,
Jason 


From sdf at google.com  Wed Dec  6 11:06:05 2023
From: sdf at google.com (Stanislav Fomichev)
Date: Wed, 6 Dec 2023 11:06:05 -0800
Subject: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC
In-Reply-To: <CAJ8uoz3_XqavGt1DyFoQAuKS8Faa1Lc85b2t+whc-f6GN1Pvzw@mail.gmail.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com> <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
 <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
 <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com>
 <CAKH8qBuXL8bOYtfKKPS8y=KJqouDptyciCjr0wNKVHtNj6BmqA@mail.gmail.com>
 <656f66023f7bd_3dd6422942a@willemb.c.googlers.com.notmuch>
 <ZW98UW033wCy9vI-@google.com> <CAJ8uoz3_XqavGt1DyFoQAuKS8Faa1Lc85b2t+whc-f6GN1Pvzw@mail.gmail.com>
Message-ID: <ZXDGHThTynXbSTJG@google.com>

On 12/06, Magnus Karlsson wrote:
> On Tue, 5 Dec 2023 at 20:39, Stanislav Fomichev <sdf at google.com> wrote:
> >
> > On 12/05, Willem de Bruijn wrote:
> > > Stanislav Fomichev wrote:
> > > > On Tue, Dec 5, 2023 at 7:34?AM Florian Bezdeka
> > > > <florian.bezdeka at siemens.com> wrote:
> > > > >
> > > > > On Tue, 2023-12-05 at 15:25 +0000, Song, Yoong Siang wrote:
> > > > > > On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote:
> > > > > > > Jesper Dangaard Brouer wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On 12/3/23 17:51, Song Yoong Siang wrote:
> > > > > > > > > This patch enables Launch Time (Time-Based Scheduling) support to XDP zero
> > > > > > > > > copy via XDP Tx metadata framework.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Song Yoong Siang<yoong.siang.song at intel.com>
> > > > > > > > > ---
> > > > > > > > >   drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  2 ++
> > > > > > > >
> > > > > > > > As requested before, I think we need to see another driver implementing
> > > > > > > > this.
> > > > > > > >
> > > > > > > > I propose driver igc and chip i225.
> > > > > >
> > > > > > Sure. I will include igc patches in next version.
> > > > > >
> > > > > > > >
> > > > > > > > The interesting thing for me is to see how the LaunchTime max 1 second
> > > > > > > > into the future[1] is handled code wise. One suggestion is to add a
> > > > > > > > section to Documentation/networking/xsk-tx-metadata.rst per driver that
> > > > > > > > mentions/documents these different hardware limitations.  It is natural
> > > > > > > > that different types of hardware have limitations.  This is a close-to
> > > > > > > > hardware-level abstraction/API, and IMHO as long as we document the
> > > > > > > > limitations we can expose this API without too many limitations for more
> > > > > > > > capable hardware.
> > > > > >
> > > > > > Sure. I will try to add hardware limitations in documentation.
> > > > > >
> > > > > > >
> > > > > > > I would assume that the kfunc will fail when a value is passed that
> > > > > > > cannot be programmed.
> > > > > > >
> > > > > >
> > > > > > In current design, the xsk_tx_metadata_request() dint got return value.
> > > > > > So user won't know if their request is fail.
> > > > > > It is complex to inform user which request is failing.
> > > > > > Therefore, IMHO, it is good that we let driver handle the error silently.
> > > > > >
> > > > >
> > > > > If the programmed value is invalid, the packet will be "dropped" / will
> > > > > never make it to the wire, right?
> > >
> > > Programmable behavior is to either drop or cap to some boundary
> > > value, such as the farthest programmable time in the future: the
> > > horizon. In fq:
> > >
> > >                 /* Check if packet timestamp is too far in the future. */
> > >                 if (fq_packet_beyond_horizon(skb, q, now)) {
> > >                         if (q->horizon_drop) {
> > >                                         q->stat_horizon_drops++;
> > >                                         return qdisc_drop(skb, sch, to_free);
> > >                         }
> > >                         q->stat_horizon_caps++;
> > >                         skb->tstamp = now + q->horizon;
> > >                 }
> > >                 fq_skb_cb(skb)->time_to_send = skb->tstamp;
> > >
> > > Drop is the more obviously correct mode.
> > >
> > > Programming with a clock source that the driver does not support will
> > > then be a persistent failure.
> > >
> > > Preferably, this driver capability can be queried beforehand (rather
> > > than only through reading error counters afterwards).
> > >
> > > Perhaps it should not be a driver task to convert from possibly
> > > multiple clock sources to the device native clock. Right now, we do
> > > use per-device timecounters for this, implemented in the driver.
> > >
> > > As for which clocks are relevant. For PTP, I suppose the device PHC,
> > > converted to nsec. For pacing offload, TCP uses CLOCK_MONOTONIC.
> >
> > Do we need to expose some generic netdev netlink apis to query/adjust
> > nic clock sources (or maybe there is something existing already)?
> > Then the userspace can be responsible for syncing/converting the
> > timestamps to the internal nic clocks. +1 to trying to avoid doing
> > this in the drivers.
> >
> > > > > That is clearly a situation that the user should be informed about. For
> > > > > RT systems this normally means that something is really wrong regarding
> > > > > timing / cycle overflow. Such systems have to react on that situation.
> > > >
> > > > In general, af_xdp is a bit lacking in this 'notify the user that they
> > > > somehow messed up' area :-(
> > > > For example, pushing a tx descriptor with a wrong addr/len in zc mode
> > > > will not give any visible signal back (besides driver potentially
> > > > spilling something into dmesg as it was in the mlx case).
> > > > We can probably start with having some counters for these events?
> > >
> > > This is because the AF_XDP completion queue descriptor format is only
> > > a u64 address?
> >
> > Yeah. XDP_COPY mode has the descriptor validation which is exported via
> > recvmsg errno, but zerocopy path seems to be too deep in the stack
> > to report something back. And there is no place, as you mention,
> > in the completion ring to report the status.
> >
> > > Could error conditions be reported on tx completion in the metadata,
> > > using xsk_tx_metadata_complete?
> >
> > That would be one way to do it, yes. But then the error reporting depends
> > on the metadata opt-in. Having a separate ring to export the errors,
> > or having a v2 tx-completions layout with extra 'status' field would also
> > work.
> 
> There are error counters for the non-metadata and offloading cases
> above that can be retrieved with the XDP_STATISTICS getsockopt(). From
> if_xdp.h:
> 
> struct xdp_statistics {
>         __u64 rx_dropped; /* Dropped for other reasons */
>         __u64 rx_invalid_descs; /* Dropped due to invalid descriptor */
>         __u64 tx_invalid_descs; /* Dropped due to invalid descriptor */
>         __u64 rx_ring_full; /* Dropped due to rx ring being full */
>         __u64 rx_fill_ring_empty_descs; /* Failed to retrieve item
> from fill ring */
>         __u64 tx_ring_empty_descs; /* Failed to retrieve item from tx ring */
> };
> 
> Albeit, these are aggregate statistics and do not say anything about
> which packet that caused it. Works well for things that are
> programming bugs that should not occur (such as rx_invalid_descs and
> tx_invalid_descs) and requires the programmer to debug and fix his or
> her program, but it does not work for requests that might fail even
> though the program is correct and need to be handled on a packet by
> packet basis. So something needs to be added for that as you both say.
> 
> Would prefer if we could avoid a v2 completion descriptor format or
> another ring that needs to be checked all the time, so if we could
> live with providing the error status in the metadata field of the
> packet at completion time, that would be good. Though having the error
> status in the completion ring would be faster as that cache line is
> hot, while the metadata section of the packet is likely not at
> completion time. So that speaks for a v2 completion ring format. Just
> thinking out loud here.

In this case, maybe adding tx_over_horizon_dropped to XDP_STATISTICS
is all we need here? We can have some new api to query this horizon
per netdev.


From catalin.marinas at arm.com  Wed Dec  6 11:06:58 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 6 Dec 2023 19:06:58 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231206190356.GD2692119@nvidia.com>
References: <ZW9ezSGSDIvv5MsQ@arm.com>
 <86a5qobkt8.wl-maz@kernel.org>
 <ZW9uqu7yOtyZfmvC@arm.com>
 <868r67blwo.wl-maz@kernel.org>
 <ZXBlmt88dKmZLCU9@arm.com>
 <20231206151603.GR2692119@nvidia.com>
 <ZXCh9N2xp0efHcpE@arm.com>
 <20231206172035.GU2692119@nvidia.com>
 <ZXDEZO6sS1dE_to9@arm.com>
 <20231206190356.GD2692119@nvidia.com>
Message-ID: <ZXDGUskp1s4Bwbtr@arm.com>

On Wed, Dec 06, 2023 at 03:03:56PM -0400, Jason Gunthorpe wrote:
> On Wed, Dec 06, 2023 at 06:58:44PM +0000, Catalin Marinas wrote:
> > -------------8<----------------------------
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> > index 1929103ee59a..b89d2dfcd534 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -1863,7 +1863,7 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
> >  	 * See remap_pfn_range(), called from vfio_pci_fault() but we can't
> >  	 * change vm_flags within the fault handler.  Set them now.
> >  	 */
> > -	vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
> > +	vm_flags_set(vma, VM_VFIO | VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
> >  	vma->vm_ops = &vfio_pci_mmap_ops;
> > 
> >  	return 0;
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 418d26608ece..6df46fd7836a 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -391,6 +391,13 @@ extern unsigned int kobjsize(const void *objp);
> >  # define VM_UFFD_MINOR		VM_NONE
> >  #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
> > 
> > +#ifdef CONFIG_64BIT
> > +#define VM_VFIO_BIT		39
> > +#define VM_VFIO			BIT(VM_VFIO_BIT)
> > +#else
> > +#define VM_VFIO			VM_NONE
> > +#endif
> > +
> >  /* Bits set in the VMA until the stack is in its final location */
> >  #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
> > -------------8<----------------------------
> > 
> > In KVM, Akita's patch would take this into account, not just rely on
> > "device==true".
> 
> Yes, Ankit let's try this please. I would not call it VM_VFIO though
> 
> VM_VFIO_ALLOW_WC ?

Yeah. I don't really care about the name.

-- 
Catalin


From cfsworks at gmail.com  Wed Dec  6 11:42:33 2023
From: cfsworks at gmail.com (Sam Edwards)
Date: Wed, 6 Dec 2023 12:42:33 -0700
Subject: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing
 RK1
In-Reply-To: <2724771.ElGaqSPkdT@diego>
References: <20231205202900.4617-1-CFSworks@gmail.com>
 <2724771.ElGaqSPkdT@diego>
Message-ID: <b188d02d-7bca-0f1e-bf83-e04e7a4330ea@gmail.com>



On 12/6/23 02:35, Heiko St?bner wrote:
> Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards:
>> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
>> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
>> will sometimes (varying between specific RK3588 chips, not over time) shut
>> off the DBI block, and reads to this range will instead stall
>> indefinitely.
>>
>> When this happens, it will prevent Linux from booting altogether. The
>> PCIe driver will stall the CPU core once it attempts to read the version
>> information from the DBI range.
>>
>> Fix this boot hang by adding the correct pinctrl configuration to the
>> PCIe 3.0 device node, which is the proper thing to do anyway. While
>> we're at it, also add the necessary configuration to the PCIe 2.0 node,
>> which may or may not fix the equivalent problem over there -- but is the
>> proper thing to do anyway. :)
>>
>> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
>> Signed-off-by: Sam Edwards <CFSworks at gmail.com>
>> ---
>>   .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------
>>   1 file changed, 2 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
>> index 9570b34aca2e..129f14dbd42f 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
>> @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy at 1 {
>>   &pcie2x1l1 {
>>   	linux,pci-domain = <1>;
>>   	pinctrl-names = "default";
>> -	pinctrl-0 = <&pcie2_reset>;
>> +	pinctrl-0 = <&pcie30x1m1_pins>;
> 
> This really throws me for a loop here - in the original submission too
> already. Because somehow those pins are named pcie30x1... for the
> pcie2 controller ;-) .

Hi Heiko,

I just double-checked. The RK1's PCIe 2.0 x1 has the following pin 
assignments:
PCIE1_CLKREQ_N -> AK30 (4 RK_PA0)
PCIE_WAKE (shared with PCIE0 wake signal) -> AL30 (4 RK_PA1)
PCIE1_RST_N -> AM29 (4 RK_PA2)

...so the patch's pinmux setting is indeed correct. (But we may still 
want to drop the `reset-gpios` property; see my reply to your other email.)

The confusion seems to be that the PCIe 2.0 path used here is:
PCIe30X1_1(1L1) -> Combo PIPE PHY2
(So, a PCIe3 controller, but a PCIe2 PHY.)

The WAKE/CLKREQ/PERST signals are very low-speed, and thus bypass the 
PHY: the RK3588's IOMUX subsystem connects them directly to the PCIe3 
controller. So they are "pcie30" pins in that sense.

The (potential) misnomer here is `pcie2x1l1`. The controller at 
0xFE180000 is unequivocally a PCIe 3.0 core, and it *could* be muxed to 
a (bifurcated) PCIe 3.0 x2 PHY for true PCIe 3.0 operation. But since it 
appears that mainline doesn't support this bifurcation (yet), this PCIe 
3.0 core can only be used for PCIe 2.0 through combphy2, which is 
probably why the DT node is labeled `pcie2x1l1` (for now).

In any case, thank you for calling attention to this! I enjoyed 
researching the "why" and hope that it clarifies things for you as well. :)

Cheers,
Sam

> 
> 
>>   	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
>>   	status = "okay";
>>   };
>> @@ -226,7 +226,7 @@ &pcie30phy {
>>   &pcie3x4 {
>>   	linux,pci-domain = <0>;
>>   	pinctrl-names = "default";
>> -	pinctrl-0 = <&pcie3_reset>;
>> +	pinctrl-0 = <&pcie30x4m1_pins>;
>>   	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
>>   	vpcie3v3-supply = <&vcc3v3_pcie30>;
>>   	status = "okay";
>> @@ -245,17 +245,7 @@ hym8563_int: hym8563-int {
>>   		};
>>   	};
>>   
>> -	pcie2 {
>> -		pcie2_reset: pcie2-reset {
>> -			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
>> -		};
>> -	};
>> -
>>   	pcie3 {
>> -		pcie3_reset: pcie3-reset {
>> -			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
>> -		};
>> -
>>   		vcc3v3_pcie30_en: pcie3-reg {
>>   			rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
>>   		};
>>
> 
> 
> 
> 


From rafael at kernel.org  Wed Dec  6 11:44:18 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 6 Dec 2023 20:44:18 +0100
Subject: [PATCH v3 0/5] Support _UID matching for integer types
In-Reply-To: <20231123100617.28020-1-raag.jadav@intel.com>
References: <20231123100617.28020-1-raag.jadav@intel.com>
Message-ID: <CAJZ5v0h7rSY7cD18pGTy9GuNB5s5EvVCNWngPKBtCCXrrNNW5A@mail.gmail.com>

On Thu, Nov 23, 2023 at 11:07?AM Raag Jadav <raag.jadav at intel.com> wrote:
>
> This series updates the standard ACPI helpers to support _UID matching
> for both integer and string types, and uses them in a couple of places.
>
> Changes since v2:
> - Drop __builtin functions to reduce complexity (Rafael)
> - Update tags
>
> Changes since v1:
> - Fix build errors
>
> Raag Jadav (5):
>   ACPI: bus: update acpi_dev_uid_match() to support multiple types
>   ACPI: bus: update acpi_dev_hid_uid_match() to support multiple types
>   ACPI: LPSS: use acpi_dev_uid_match() for matching _UID
>   efi: dev-path-parser: use acpi_dev_uid_match() for matching _UID
>   perf: arm_cspmu: drop redundant acpi_dev_uid_to_integer()

All applied as 6.8 material, but I renamed the auxiliary macros in the
first patch and moved the kerneldoc comment below them.

TBH, I'm not entirely sure about the value of the second of those
auxiliary macros, but then I don't particularly dislike it either.


From cristian_ci at protonmail.com  Wed Dec  6 11:51:19 2023
From: cristian_ci at protonmail.com (cristian_ci)
Date: Wed, 06 Dec 2023 19:51:19 +0000
Subject: [BUG] wireless: mt7601u: probe failed with error -110
In-Reply-To: <20231126142634.3a100e2c@kernel.org>
References: <Bnwq2et4CBU1_MS8X3rFeejMDmKf2dr_BNq60IzBcGKbjTxHG1CjJ0zB_wZjn8_iLJsi7fCx6_Eh01ozYBqPA-cEZXMZE_X98E0b7yotXCg=@protonmail.com> <20231126142634.3a100e2c@kernel.org>
Message-ID: <QGXUDgc-RbYOKRZYX_gp7uyKz_WQ4_6b_R9c4Qyd-3oEd4V_vluPJtyJfVqpvcF5kKQ3Ffr3cVXmxAY3jPYQwKSBrusexYYFIPfHJ1qtFPI=@protonmail.com>

[RESEND I've made a mistake with list of recipients]

Update:

I've built and installed mt7601Usta vendor driver, which is shown into lsmod output.

ra0 interface appears as shown in the following output from iwconfig and ifconfig:

ra0       Ralink STA  ESSID:""
          Mode:Auto  Frequency=2.412 GHz  Access Point: Not-Associated
          Bit Rate:1 Mb/s
          RTS thr:off   Fragment thr:off
          Link Quality=10/100  Signal level:0 dBm  Noise level:0 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0


ra0       Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisioni:0 txqueuelen:1000
          Byte RX:0 (0.0 B)  Byte TX:0 (0.0 B)

The driver is properly loaded and the device doesn't connect/disconnect continuously as instead happens in mainline driver:

Bus 001 Device 007: ID 148f:7601 Ralink Technology, Corp.
    |__ Port 3: Dev 7, If 0, Class=vend., Driver=rt2870, 480M

Any thoughts?

Waiting for a reply,

Cristian.


From daniel at makrotopia.org  Wed Dec  6 11:52:23 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 19:52:23 +0000
Subject: [RFC PATCH v2 8/8] net: ethernet: mtk_eth_soc: add paths and
 SerDes modes for MT7988
In-Reply-To: <ZXDDtmRklS6o994V@shell.armlinux.org.uk>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <3ccc33fa14310ab47e90ff8e6ce46f1562bb838e.1701826319.git.daniel@makrotopia.org>
 <ZXDDtmRklS6o994V@shell.armlinux.org.uk>
Message-ID: <ZXDQ94Xh3gzL3IR9@makrotopia.org>

On Wed, Dec 06, 2023 at 06:55:50PM +0000, Russell King (Oracle) wrote:
> On Wed, Dec 06, 2023 at 01:45:17AM +0000, Daniel Golle wrote:
> > @@ -516,6 +538,21 @@ static struct phylink_pcs *mtk_mac_select_pcs(struct phylink_config *config,
> >  	struct mtk_eth *eth = mac->hw;
> >  	unsigned int sid;
> >  
> > +	if (mtk_is_netsys_v3_or_greater(eth)) {
> > +		switch (interface) {
> > +		case PHY_INTERFACE_MODE_1000BASEX:
> > +		case PHY_INTERFACE_MODE_2500BASEX:
> > +		case PHY_INTERFACE_MODE_SGMII:
> > +			return mtk_pcs_lynxi_select_pcs(mac->sgmii_pcs_of_node, interface);
> > +		case PHY_INTERFACE_MODE_5GBASER:
> > +		case PHY_INTERFACE_MODE_10GBASER:
> > +		case PHY_INTERFACE_MODE_USXGMII:
> > +			return mtk_usxgmii_select_pcs(mac->usxgmii_pcs_of_node, interface);
> 
> From what I can see, neither of these two "select_pcs" methods that
> you're calling makes any use of the "interface" you pass to them.
> I'm not sure what they _could_ do with it either, given that what
> you're effectively doing here is getting the phylink_pcs structure from
> the driver, and each one only has a single phylink_pcs.

Yes, you are right, the interface parameter isn't used, I will drop
it from both mtk_*_select_pcs() prototypes.

In the long run we may want something like
struct phylink_pcs *of_pcs_get(struct device_node *np, phy_interface_t interface)
provided by a to-be-built drivers/net/pcs/core.c...


From rafael at kernel.org  Wed Dec  6 11:55:19 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 6 Dec 2023 20:55:19 +0100
Subject: [Patch v7] ACPI: processor: reduce CPUFREQ thermal reduction pctg
 for Tegra241
In-Reply-To: <6ccd1598-3c8b-1290-9494-01a3cdbb3003@huawei.com>
References: <20231123121433.12089-1-sumitg@nvidia.com> <ZV9bGtUsjF1v1oIW@bogus>
 <6ccd1598-3c8b-1290-9494-01a3cdbb3003@huawei.com>
Message-ID: <CAJZ5v0jT=xhTcAHKUMPJR2VbpFNLm1aX-CrcB70Man+VbQX-yQ@mail.gmail.com>

On Thu, Nov 23, 2023 at 3:32?PM Hanjun Guo <guohanjun at huawei.com> wrote:
>
> On 2023/11/23 22:00, Sudeep Holla wrote:
> > On Thu, Nov 23, 2023 at 05:44:33PM +0530, Sumit Gupta wrote:
> >> From: Srikar Srimath Tirumala <srikars at nvidia.com>
> >>
> >> Current implementation of processor_thermal performs software throttling
> >> in fixed steps of "20%" which can be too coarse for some platforms.
> >> We observed some performance gain after reducing the throttle percentage.
> >> Change the CPUFREQ thermal reduction percentage and maximum thermal steps
> >> to be configurable. Also, update the default values of both for Nvidia
> >> Tegra241 (Grace) SoC. The thermal reduction percentage is reduced to "5%"
> >> and accordingly the maximum number of thermal steps are increased as they
> >> are derived from the reduction percentage.
> >>
> >> Signed-off-by: Srikar Srimath Tirumala <srikars at nvidia.com>
> >> Co-developed-by: Sumit Gupta <sumitg at nvidia.com>
> >> Signed-off-by: Sumit Gupta <sumitg at nvidia.com>
> >> ---
> >>
> >> Sending this patch separately as the other patch in the series is
> >> applied by Rafael in v6[1]. Revision history before this version is
> >> in the cover letter of v6[1].
> >>
> >> Please review and provide ACK if looks fine.
> >>
> >
> > For arm64 specific changes(a minor nit below though),
> >
> > Acked-by: Sudeep Holla <sudeep.holla at arm.com>

Applied as 6.8 material, thanks!


From festevam at gmail.com  Wed Dec  6 12:00:33 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 17:00:33 -0300
Subject: [PATCH] ARM: dts: imx25: Fix the iim compatible string
Message-ID: <20231206200033.2360532-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per imx-iim.yaml, the compatible string should only contain a single
entry.

Use it as "fsl,imx25-iim" to fix the following dt-schema warning:

imx25-karo-tx25.dtb: efuse at 53ff0000: compatible: ['fsl,imx25-iim', 'fsl,imx27-iim'] is too long
	from schema $id: http://devicetree.org/schemas/nvmem/imx-iim.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx25.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx25.dtsi b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
index e7b7f22b5e89..db814d7b568d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
@@ -552,7 +552,7 @@ pwm1: pwm at 53fe0000 {
 			};
 
 			iim: efuse at 53ff0000 {
-				compatible = "fsl,imx25-iim", "fsl,imx27-iim";
+				compatible = "fsl,imx25-iim";
 				reg = <0x53ff0000 0x4000>;
 				interrupts = <19>;
 				clocks = <&clks 99>;
-- 
2.34.1



From leoyang.li at nxp.com  Wed Dec  6 11:47:33 2023
From: leoyang.li at nxp.com (Leo Li)
Date: Wed, 6 Dec 2023 19:47:33 +0000
Subject: [PATCH] arm64: dts: ls1012a: Remove big-endian from thermal
In-Reply-To: <CAOMZO5BjEEk0e8vyYm2XW0DCDPEoCUQn3ufN5hpES18uaPRMww@mail.gmail.com>
References: <20230929185510.707475-1-festevam@gmail.com>
 <20231010014035.GB819755@dragon>
 <CAOMZO5BjEEk0e8vyYm2XW0DCDPEoCUQn3ufN5hpES18uaPRMww@mail.gmail.com>
Message-ID: <DB3PR0402MB3674935F3FBECD3D25153D8E8F84A@DB3PR0402MB3674.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Fabio Estevam <festevam at gmail.com>
> Sent: Tuesday, December 5, 2023 4:00 PM
> To: Shawn Guo <shawnguo at kernel.org>; Leo Li <leoyang.li at nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; Fabio Estevam
> <festevam at denx.de>
> Subject: Re: [PATCH] arm64: dts: ls1012a: Remove big-endian from thermal
> 
> Hi Leo,
> 
> On Mon, Oct 9, 2023 at 10:40?PM Shawn Guo <shawnguo at kernel.org> wrote:
> >
> > On Fri, Sep 29, 2023 at 03:55:10PM -0300, Fabio Estevam wrote:
> > > From: Fabio Estevam <festevam at denx.de>
> > >
> > > Per qoriq-thermal.yaml, 'big-endian' is not a valid property.
> > >
> > > When the 'little-endian' property is absent, the default is big endian.
> > >
> > > Remove it to fix the following schema warning:
> > >
> > > tmu at 1f00000: 'big-endian' does not match any of the regexes: 'pinctrl-[0-
> 9]+'
> > > from schema $id:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevice
> tree.org%2Fschemas%2Fthermal%2Fqoriq-
> thermal.yaml%23&data=05%7C01%7Cleoyang.li%40nxp.com%7Caefb2100b7
> a34977023908dbf5dd81a5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C638374103934974217%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=yUSalG9%2B0INDoSpIIu1aCsIM9Jt%2BuiPnNIWHY0uuzik%3D&re
> served=0
> > >
> > > Signed-off-by: Fabio Estevam <festevam at denx.de>
> >
> > Leo,
> >
> > Can you confirm this is fine?
> 
> Do you agree with this change?

You are right.  Thanks for the fix.

Acked-by: Li Yang <leoyang.li at nxp.com>

> 
> >
> > Shawn
> >
> > > ---
> > >  arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > > index a863022529ac..d0733451d3ce 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > > @@ -346,7 +346,6 @@ tmu: tmu at 1f00000 {
> > >                                              0x00030004 0x00000047
> > >                                              0x00030005 0x00000053
> > >                                              0x00030006 0x00000060>;
> > > -                     big-endian;
> > >                       #thermal-sensor-cells = <1>;
> > >               };
> > >
> > > --
> > > 2.34.1
> > >

From festevam at gmail.com  Wed Dec  6 12:12:52 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 17:12:52 -0300
Subject: [PATCH] ARM: dts: imx25/27: 
Message-ID: <20231206201252.2376554-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per display-timings.yaml, the 'timing' pattern should be used to
describe the display timings.

Change it accordingly to fix the following dt-schema warning:

imx27-apf27dev.dtb: display-timings: '800x480' does not match any of the regexes: '^timing', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/display/panel/display-timings.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 .../dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts   | 2 +-
 .../dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts   | 2 +-
 .../dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts    | 2 +-
 arch/arm/boot/dts/nxp/imx/imx25-pdk.dts                         | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts                    | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts  | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts        | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts          | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
index fc8a502fc957..6cddb2cc36fe 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
@@ -16,7 +16,7 @@ cmo_qvga: display {
 		bus-width = <18>;
 		display-timings {
 			native-mode = <&qvga_timings>;
-			qvga_timings: 320x240 {
+			qvga_timings: timing0 {
 				clock-frequency = <6500000>;
 				hactive = <320>;
 				vactive = <240>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
index 80a7f96de4c6..64b2ffac463b 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
@@ -16,7 +16,7 @@ dvi_svga: display {
 		bus-width = <18>;
 		display-timings {
 			native-mode = <&dvi_svga_timings>;
-			dvi_svga_timings: 800x600 {
+			dvi_svga_timings: timing0 {
 				clock-frequency = <40000000>;
 				hactive = <800>;
 				vactive = <600>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
index 24027a1fb46d..fb074bfdaa8d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
@@ -16,7 +16,7 @@ dvi_vga: display {
 		bus-width = <18>;
 		display-timings {
 			native-mode = <&dvi_vga_timings>;
-			dvi_vga_timings: 640x480 {
+			dvi_vga_timings: timing0 {
 				clock-frequency = <31250000>;
 				hactive = <640>;
 				vactive = <480>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts b/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
index 14a61dc1e742..6a5563298bf3 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
@@ -68,7 +68,7 @@ wvga: display {
 		bus-width = <18>;
 		display-timings {
 			native-mode = <&wvga_timings>;
-			wvga_timings: 640x480 {
+			wvga_timings: timing0 {
 				hactive = <640>;
 				vactive = <480>;
 				hback-porch = <45>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts b/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts
index a21f1f7c24b8..f047a8487073 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts
@@ -16,7 +16,7 @@ display: display {
 		fsl,pcr = <0xfae80083>;	/* non-standard but required */
 		display-timings {
 			native-mode = <&timing0>;
-			timing0: 800x480 {
+			timing0: timing0 {
 				clock-frequency = <33000033>;
 				hactive = <800>;
 				vactive = <480>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts
index 145e459625b3..d78793601306 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts
@@ -16,7 +16,7 @@ display0: CMO-QVGA {
 
 		display-timings {
 			native-mode = <&timing0>;
-			timing0: 320x240 {
+			timing0: timing0 {
 				clock-frequency = <6500000>;
 				hactive = <320>;
 				vactive = <240>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts
index 25442eba21c1..27c93b9fe049 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts
@@ -19,7 +19,7 @@ display: display {
 		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
 		display-timings {
 			native-mode = <&timing0>;
-			timing0: 640x480 {
+			timing0: timing0 {
 				hactive = <640>;
 				vactive = <480>;
 				hback-porch = <112>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts
index b7df7f20ec04..b8048e12e3d9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts
@@ -19,7 +19,7 @@ display0: LQ035Q7 {
 
 		display-timings {
 			native-mode = <&timing0>;
-			timing0: 240x320 {
+			timing0: timing0 {
 				clock-frequency = <5500000>;
 				hactive = <240>;
 				vactive = <320>;
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec  6 12:12:55 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed,  6 Dec 2023 15:12:55 -0500
Subject: [PATCH 1/1] arm64: dts: imx8qm: Fix edma3 power-domains and interrupt number
Message-ID: <20231206201256.1113800-1-Frank.Li@nxp.com>

Fixed a kernel dump when access edma3 registers.

[    1.517547] SError Interrupt on CPU1, code 0x00000000bf000002 -- SError
[    1.517556] CPU: 1 PID: 59 Comm: kworker/u8:2 Not tainted 6.7.0-rc3-next-20231129-dirty #3
[    1.517564] Hardware name: Freescale i.MX8QM MEK (DT)
[    1.517570] Workqueue: events_unbound deferred_probe_work_func
[    1.517593] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.517601] pc : vsnprintf+0x60/0x770
[    1.517612] lr : snprintf+0x58/0x80
[    1.517619] sp : ffff800082f0b9e0
[    1.517622] x29: ffff800082f0b9e0 x28: ffff8000819a8af8 x27: ffff000801f90080
[    1.517632] x26: ffff000801f90510 x25: 0000000000000001 x24: 0000000000000020
[    1.517640] x23: 00000000ffffffd8 x22: ffff000800114800 x21: ffff800082f0baf0
[    1.517650] x20: ffff000801f90698 x19: ffff000801f906b8 x18: ffffffffffffffff
[    1.517659] x17: 6e6f632d616d642e x16: 3030303066396135 x15: ffff800102f0b687
[    1.517668] x14: 0000000000000000 x13: 30206e6168632065 x12: 74697277203a7265
[    1.517677] x11: 6c6c6f72746e6f63 x10: 2d616d642e303030 x9 : 72656c6c6f72746e
[    1.517686] x8 : ffff000800396740 x7 : 205d333337383035 x6 : ffff800082f0baf0
[    1.517694] x5 : 00000000ffffffd8 x4 : ffff000800396740 x3 : ffff800082f0ba70
[    1.517703] x2 : ffff8000819a8af8 x1 : ffff800082f0baf0 x0 : 0000000000000025
[    1.517713] Kernel panic - not syncing: Asynchronous SError Interrupt
[    1.517718] CPU: 1 PID: 59 Comm: kworker/u8:2 Not tainted 6.7.0-rc3-next-20231129-dirty #3
[    1.517724] Hardware name: Freescale i.MX8QM MEK (DT)
[    1.517727] Workqueue: events_unbound deferred_probe_work_func
[    1.517736] Call trace:
[    1.517739]  dump_backtrace+0x90/0xe8
[    1.517752]  show_stack+0x18/0x24
[    1.517761]  dump_stack_lvl+0x48/0x60
[    1.517771]  dump_stack+0x18/0x24
[    1.517780]  panic+0x36c/0x3ac
[    1.517789]  nmi_panic+0x48/0x94
[    1.517796]  arm64_serror_panic+0x6c/0x78
[    1.517801]  do_serror+0x3c/0x78
[    1.517806]  el1h_64_error_handler+0x30/0x48
[    1.517813]  el1h_64_error+0x64/0x68
[    1.517819]  vsnprintf+0x60/0x770
[    1.517827]  snprintf+0x58/0x80
[    1.517834]  fsl_edma_probe+0x2ac/0x830

It is eDMA1 at QM, which have the same register with eDMA3 at qxp.

Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]")
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 .../boot/dts/freescale/imx8qm-ss-dma.dtsi     | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
index 01539df335f8c..5d76b4dee4cef 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
@@ -44,6 +44,33 @@ can2_lpcg: clock-controller at 5acf0000 {
 	};
 };
 
+/* It is eDMA1 in 8QM RM, but 8QXP it is eDMA3 */
+&edma3 {
+	reg = <0x5a9f0000 0x210000>;
+	dma-channels = <10>;
+	interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 427 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 433 IRQ_TYPE_LEVEL_HIGH>;
+	power-domains = <&pd IMX_SC_R_DMA_1_CH0>,
+			<&pd IMX_SC_R_DMA_1_CH1>,
+			<&pd IMX_SC_R_DMA_1_CH2>,
+			<&pd IMX_SC_R_DMA_1_CH3>,
+			<&pd IMX_SC_R_DMA_1_CH4>,
+			<&pd IMX_SC_R_DMA_1_CH5>,
+			<&pd IMX_SC_R_DMA_1_CH6>,
+			<&pd IMX_SC_R_DMA_1_CH7>,
+			<&pd IMX_SC_R_DMA_1_CH8>,
+			<&pd IMX_SC_R_DMA_1_CH9>;
+};
+
+/* It is edma0 in 8QM RM, but it is eDMA2 at 8QXP */
 &edma2 {
 	reg = <0x5a1f0000 0x170000>;
 	#dma-cells = <3>;
-- 
2.34.1



From kan.liang at linux.intel.com  Wed Dec  6 12:13:18 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed,  6 Dec 2023 12:13:18 -0800
Subject: [PATCH 0/6] Clean up perf mem
Message-ID: <20231206201324.184059-1-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

As discussed in the below thread, the patch set is to clean up perf mem.
https://lore.kernel.org/lkml/afefab15-cffc-4345-9cf4-c6a4128d4d9c at linux.intel.com/

Introduce generic functions perf_mem_events__ptr(),
perf_mem_events__name() ,and is_mem_loads_aux_event() to replace the
ARCH specific ones.
Simplify the perf_mem_event__supported().

Only keeps the ARCH-specific perf_mem_events array in the corresponding
mem-events.c for each ARCH.

There is no functional change.

The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
etc. But I can only test it on two Intel platforms.
Please give it try, if you have machines with other ARCHs.

Here are the test results:
Intel hybrid machine:

$perf mem record -e list
ldlat-loads  : available
ldlat-stores : available

$perf mem record -e ldlat-loads -v --ldlat 50
calling: record -e cpu_atom/mem-loads,ldlat=50/P -e cpu_core/mem-loads,ldlat=50/P

$perf mem record -v
calling: record -e cpu_atom/mem-loads,ldlat=30/P -e cpu_atom/mem-stores/P -e cpu_core/mem-loads,ldlat=30/P -e cpu_core/mem-stores/P

$perf mem record -t store -v
calling: record -e cpu_atom/mem-stores/P -e cpu_core/mem-stores/P


Intel SPR:
$perf mem record -e list
ldlat-loads  : available
ldlat-stores : available

$perf mem record -e ldlat-loads -v --ldlat 50
calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=50/}:P

$perf mem record -v
calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=30/}:P -e cpu/mem-stores/P

$perf mem record -t store -v
calling: record -e cpu/mem-stores/P

Kan Liang (6):
  perf mem: Add mem_events into the supported perf_pmu
  perf mem: Clean up perf_mem_events__ptr()
  perf mem: Clean up perf_mem_events__name()
  perf mem: Clean up perf_mem_event__supported()
  perf mem: Clean up is_mem_loads_aux_event()
  perf mem: Remove useless header files for X86

 tools/perf/arch/arm64/util/mem-events.c   |  36 +----
 tools/perf/arch/arm64/util/mem-events.h   |   7 +
 tools/perf/arch/arm64/util/pmu.c          |   6 +
 tools/perf/arch/powerpc/util/mem-events.c |  13 +-
 tools/perf/arch/powerpc/util/mem-events.h |   7 +
 tools/perf/arch/powerpc/util/pmu.c        |  11 ++
 tools/perf/arch/s390/util/pmu.c           |   3 +
 tools/perf/arch/x86/util/mem-events.c     |  99 +++---------
 tools/perf/arch/x86/util/mem-events.h     |  10 ++
 tools/perf/arch/x86/util/pmu.c            |  11 ++
 tools/perf/builtin-c2c.c                  |  28 +++-
 tools/perf/builtin-mem.c                  |  28 +++-
 tools/perf/util/mem-events.c              | 177 +++++++++++++---------
 tools/perf/util/mem-events.h              |  15 +-
 tools/perf/util/pmu.c                     |   4 +-
 tools/perf/util/pmu.h                     |   7 +
 16 files changed, 248 insertions(+), 214 deletions(-)
 create mode 100644 tools/perf/arch/arm64/util/mem-events.h
 create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
 create mode 100644 tools/perf/arch/powerpc/util/pmu.c
 create mode 100644 tools/perf/arch/x86/util/mem-events.h

-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec  6 12:13:19 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed,  6 Dec 2023 12:13:19 -0800
Subject: [PATCH 1/6] perf mem: Add mem_events into the supported perf_pmu
In-Reply-To: <20231206201324.184059-1-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
Message-ID: <20231206201324.184059-2-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

With the mem_events, perf doesn't need to read sysfs for each PMU to
find the mem-events-supported PMU. The patch also makes it possible to
clean up the related __weak functions later.

The patch is only to add the mem_events into the perf_pmu for all ARCHs.
It will be used in the later cleanup patches.

Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c | 4 ++--
 tools/perf/arch/arm64/util/mem-events.h | 7 +++++++
 tools/perf/arch/arm64/util/pmu.c        | 6 ++++++
 tools/perf/arch/s390/util/pmu.c         | 3 +++
 tools/perf/arch/x86/util/mem-events.c   | 4 ++--
 tools/perf/arch/x86/util/mem-events.h   | 9 +++++++++
 tools/perf/arch/x86/util/pmu.c          | 7 +++++++
 tools/perf/util/mem-events.c            | 2 +-
 tools/perf/util/mem-events.h            | 1 +
 tools/perf/util/pmu.c                   | 4 +++-
 tools/perf/util/pmu.h                   | 7 +++++++
 11 files changed, 48 insertions(+), 6 deletions(-)
 create mode 100644 tools/perf/arch/arm64/util/mem-events.h
 create mode 100644 tools/perf/arch/x86/util/mem-events.h

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index 3bcc5c7035c2..aaa4804922b4 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -4,7 +4,7 @@
 
 #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
 
-static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
 	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
 	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
 	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
@@ -17,7 +17,7 @@ struct perf_mem_event *perf_mem_events__ptr(int i)
 	if (i >= PERF_MEM_EVENTS__MAX)
 		return NULL;
 
-	return &perf_mem_events[i];
+	return &perf_mem_events_arm[i];
 }
 
 const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
diff --git a/tools/perf/arch/arm64/util/mem-events.h b/tools/perf/arch/arm64/util/mem-events.h
new file mode 100644
index 000000000000..5fc50be4be38
--- /dev/null
+++ b/tools/perf/arch/arm64/util/mem-events.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ARM64_MEM_EVENTS_H
+#define _ARM64_MEM_EVENTS_H
+
+extern struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX];
+
+#endif /* _ARM64_MEM_EVENTS_H */
diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
index 2a4eab2d160e..69673fcf4a61 100644
--- a/tools/perf/arch/arm64/util/pmu.c
+++ b/tools/perf/arch/arm64/util/pmu.c
@@ -8,6 +8,12 @@
 #include <api/fs/fs.h>
 #include <math.h>
 
+void perf_pmu__arch_init(struct perf_pmu *pmu)
+{
+	if (strcmp(pmu->name, "arm_spe_0"))
+		pmu->mem_events = perf_mem_events_arm;
+}
+
 const struct pmu_metrics_table *pmu_metrics_table__find(void)
 {
 	struct perf_pmu *pmu;
diff --git a/tools/perf/arch/s390/util/pmu.c b/tools/perf/arch/s390/util/pmu.c
index 886c30e001fa..225d7dc2379c 100644
--- a/tools/perf/arch/s390/util/pmu.c
+++ b/tools/perf/arch/s390/util/pmu.c
@@ -19,4 +19,7 @@ void perf_pmu__arch_init(struct perf_pmu *pmu)
 	    !strcmp(pmu->name, S390_PMUPAI_EXT) ||
 	    !strcmp(pmu->name, S390_PMUCPUM_CF))
 		pmu->selectable = true;
+
+	if (pmu->is_core)
+		pmu->mem_events = perf_mem_events;
 }
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 191b372f9a2d..2b81d229982c 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -16,13 +16,13 @@ static char mem_stores_name[100];
 
 #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
 
-static struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
 	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads"),
 	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores"),
 	E(NULL,			NULL,				NULL),
 };
 
-static struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
 	E(NULL,		NULL,		NULL),
 	E(NULL,		NULL,		NULL),
 	E("mem-ldst",	"ibs_op//",	"ibs_op"),
diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
new file mode 100644
index 000000000000..3959e427f482
--- /dev/null
+++ b/tools/perf/arch/x86/util/mem-events.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _X86_MEM_EVENTS_H
+#define _X86_MEM_EVENTS_H
+
+extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
+
+extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
+
+#endif /* _X86_MEM_EVENTS_H */
diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
index 469555ae9b3c..7e69f4f2e363 100644
--- a/tools/perf/arch/x86/util/pmu.c
+++ b/tools/perf/arch/x86/util/pmu.c
@@ -15,6 +15,7 @@
 #include "../../../util/pmu.h"
 #include "../../../util/fncache.h"
 #include "../../../util/pmus.h"
+#include "mem-events.h"
 #include "env.h"
 
 void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
@@ -30,6 +31,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
 		pmu->selectable = true;
 	}
 #endif
+
+	if (x86__is_amd_cpu()) {
+		if (strcmp(pmu->name, "ibs_op"))
+			pmu->mem_events = perf_mem_events_amd;
+	} else if (pmu->is_core)
+		pmu->mem_events = perf_mem_events_intel;
 }
 
 int perf_pmus__num_mem_pmus(void)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 3a2e3687878c..0a8f415f5efe 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -19,7 +19,7 @@ unsigned int perf_mem_events__loads_ldlat = 30;
 
 #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
 
-static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
 	E("ldlat-loads",	"cpu/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads"),
 	E("ldlat-stores",	"cpu/mem-stores/P",		"cpu/events/mem-stores"),
 	E(NULL,			NULL,				NULL),
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index b40ad6ea93fc..8c5694b2d0b0 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -34,6 +34,7 @@ enum {
 };
 
 extern unsigned int perf_mem_events__loads_ldlat;
+extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
 
 int perf_mem_events__parse(const char *str);
 int perf_mem_events__init(void);
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 3c9609944a2f..3d4373b8ab63 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -986,8 +986,10 @@ static int pmu_max_precise(int dirfd, struct perf_pmu *pmu)
 }
 
 void __weak
-perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
+perf_pmu__arch_init(struct perf_pmu *pmu)
 {
+	if (pmu->is_core)
+		pmu->mem_events = perf_mem_events;
 }
 
 struct perf_pmu *perf_pmu__lookup(struct list_head *pmus, int dirfd, const char *name)
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 424c3fee0949..e35d985206db 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -10,6 +10,8 @@
 #include <stdio.h>
 #include "parse-events.h"
 #include "pmu-events/pmu-events.h"
+#include "map_symbol.h"
+#include "mem-events.h"
 
 struct evsel_config_term;
 struct perf_cpu_map;
@@ -162,6 +164,11 @@ struct perf_pmu {
 		 */
 		bool exclude_guest;
 	} missing_features;
+
+	/**
+	 * @mem_events: List of the supported mem events
+	 */
+	struct perf_mem_event *mem_events;
 };
 
 /** @perf_pmu__fake: A special global PMU used for testing. */
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec  6 12:13:21 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed,  6 Dec 2023 12:13:21 -0800
Subject: [PATCH 3/6] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <20231206201324.184059-1-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
Message-ID: <20231206201324.184059-4-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
one.

The mem_load events may have a different format. Add ldlat and aux_event
in the struct perf_mem_event to indicate the format and the extra aux
event.

Add perf_mem_events_intel_aux[] to support the extra mem_load_aux event.

Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c   | 26 ++-------
 tools/perf/arch/powerpc/util/mem-events.c | 13 ++---
 tools/perf/arch/powerpc/util/mem-events.h |  7 +++
 tools/perf/arch/powerpc/util/pmu.c        | 11 ++++
 tools/perf/arch/x86/util/mem-events.c     | 70 +++++------------------
 tools/perf/arch/x86/util/mem-events.h     |  1 +
 tools/perf/arch/x86/util/pmu.c            |  8 ++-
 tools/perf/util/mem-events.c              | 56 ++++++++++++------
 tools/perf/util/mem-events.h              |  3 +-
 9 files changed, 89 insertions(+), 106 deletions(-)
 create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
 create mode 100644 tools/perf/arch/powerpc/util/pmu.c

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index 2602e8688727..eb2ef84f0fc8 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -2,28 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
-	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
-	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
-	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
+	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0",	true,	0),
+	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0",	false,	0),
+	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0",	true,	0),
 };
-
-static char mem_ev_name[100];
-
-const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
-{
-	struct perf_mem_event *e = &perf_mem_events_arm[i];
-
-	if (i >= PERF_MEM_EVENTS__MAX)
-		return NULL;
-
-	if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE)
-		scnprintf(mem_ev_name, sizeof(mem_ev_name),
-			  e->name, perf_mem_events__loads_ldlat);
-	else /* PERF_MEM_EVENTS__STORE */
-		scnprintf(mem_ev_name, sizeof(mem_ev_name), e->name);
-
-	return mem_ev_name;
-}
diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
index 78b986e5268d..b7883e38950f 100644
--- a/tools/perf/arch/powerpc/util/mem-events.c
+++ b/tools/perf/arch/powerpc/util/mem-events.c
@@ -2,11 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-/* PowerPC does not support 'ldlat' parameter. */
-const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
-{
-	if (i == PERF_MEM_EVENTS__LOAD)
-		return "cpu/mem-loads/";
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
-	return "cpu/mem-stores/";
-}
+struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
+	E("ldlat-loads",	"%s/mem-loads/",	"cpu/events/mem-loads",		false,	0),
+	E("ldlat-stores",	"%s/mem-stores/",	"cpu/events/mem-stores",	false,	0),
+	E(NULL,			NULL,			NULL,				false,	0),
+};
diff --git a/tools/perf/arch/powerpc/util/mem-events.h b/tools/perf/arch/powerpc/util/mem-events.h
new file mode 100644
index 000000000000..6acc3d1b6873
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/mem-events.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _POWER_MEM_EVENTS_H
+#define _POWER_MEM_EVENTS_H
+
+extern struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX];
+
+#endif /* _POWER_MEM_EVENTS_H */
diff --git a/tools/perf/arch/powerpc/util/pmu.c b/tools/perf/arch/powerpc/util/pmu.c
new file mode 100644
index 000000000000..168173f88ddb
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/pmu.c
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <string.h>
+
+#include "../../../util/pmu.h"
+
+void perf_pmu__arch_init(struct perf_pmu *pmu)
+{
+	if (pmu->is_core)
+		pmu->mem_events = perf_mem_events_power;
+}
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 5fb41d50118d..f0e66a0151a0 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -7,25 +7,26 @@
 #include "linux/string.h"
 #include "env.h"
 
-static char mem_loads_name[100];
-static bool mem_loads_name__init;
-static char mem_stores_name[100];
-
 #define MEM_LOADS_AUX		0x8203
-#define MEM_LOADS_AUX_NAME     "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P"
 
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads"),
-	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores"),
-	E(NULL,			NULL,				NULL),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads",	true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,			false,	0),
+};
+
+struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
+	E("ldlat-loads",	"{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P",	"%s/events/mem-loads",	true,	MEM_LOADS_AUX),
+	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,			false,	0),
 };
 
 struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
-	E(NULL,		NULL,		NULL),
-	E(NULL,		NULL,		NULL),
-	E("mem-ldst",	"ibs_op//",	"ibs_op"),
+	E(NULL,		NULL,		NULL,		false,	0),
+	E(NULL,		NULL,		NULL,		false,	0),
+	E("mem-ldst",	"%s//",		"ibs_op",	false,	0),
 };
 
 bool is_mem_loads_aux_event(struct evsel *leader)
@@ -40,48 +41,3 @@ bool is_mem_loads_aux_event(struct evsel *leader)
 
 	return leader->core.attr.config == MEM_LOADS_AUX;
 }
-
-const char *perf_mem_events__name(int i, const char *pmu_name)
-{
-	struct perf_mem_event *e;
-
-	if (x86__is_amd_cpu())
-		e = &perf_mem_events_amd[i];
-	else
-		e = &perf_mem_events_intel[i];
-
-	if (!e)
-		return NULL;
-
-	if (i == PERF_MEM_EVENTS__LOAD) {
-		if (mem_loads_name__init && !pmu_name)
-			return mem_loads_name;
-
-		if (!pmu_name) {
-			mem_loads_name__init = true;
-			pmu_name = "cpu";
-		}
-
-		if (perf_pmus__have_event(pmu_name, "mem-loads-aux")) {
-			scnprintf(mem_loads_name, sizeof(mem_loads_name),
-				  MEM_LOADS_AUX_NAME, pmu_name, pmu_name,
-				  perf_mem_events__loads_ldlat);
-		} else {
-			scnprintf(mem_loads_name, sizeof(mem_loads_name),
-				  e->name, pmu_name,
-				  perf_mem_events__loads_ldlat);
-		}
-		return mem_loads_name;
-	}
-
-	if (i == PERF_MEM_EVENTS__STORE) {
-		if (!pmu_name)
-			pmu_name = "cpu";
-
-		scnprintf(mem_stores_name, sizeof(mem_stores_name),
-			  e->name, pmu_name);
-		return mem_stores_name;
-	}
-
-	return e->name;
-}
diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
index 3959e427f482..f55c8d3b7d59 100644
--- a/tools/perf/arch/x86/util/mem-events.h
+++ b/tools/perf/arch/x86/util/mem-events.h
@@ -3,6 +3,7 @@
 #define _X86_MEM_EVENTS_H
 
 extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
+extern struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX];
 
 extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
 
diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
index 7e69f4f2e363..446f8197aae4 100644
--- a/tools/perf/arch/x86/util/pmu.c
+++ b/tools/perf/arch/x86/util/pmu.c
@@ -35,8 +35,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
 	if (x86__is_amd_cpu()) {
 		if (strcmp(pmu->name, "ibs_op"))
 			pmu->mem_events = perf_mem_events_amd;
-	} else if (pmu->is_core)
-		pmu->mem_events = perf_mem_events_intel;
+	} else if (pmu->is_core) {
+		if (perf_pmu__have_event(pmu, "mem-loads-aux"))
+			pmu->mem_events = perf_mem_events_intel_aux;
+		else
+			pmu->mem_events = perf_mem_events_intel;
+	}
 }
 
 int perf_pmus__num_mem_pmus(void)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 887ffdcce338..3a60cbcd6d8e 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -17,17 +17,17 @@
 
 unsigned int perf_mem_events__loads_ldlat = 30;
 
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"cpu/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads"),
-	E("ldlat-stores",	"cpu/mem-stores/P",		"cpu/events/mem-stores"),
-	E(NULL,			NULL,				NULL),
+	E("ldlat-loads",	"%s/mem-loads/,ldlat=%u/P",	"cpu/events/mem-loads",		true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"cpu/events/mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,				false,	0),
 };
 #undef E
 
 static char mem_loads_name[100];
-static bool mem_loads_name__init;
+static char mem_stores_name[100];
 
 struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i)
 {
@@ -62,23 +62,45 @@ struct perf_pmu *perf_mem_events_find_pmu(void)
 	return perf_pmus__scan_mem(NULL);
 }
 
-const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
+static const char *perf_mem_events__name(int i, struct perf_pmu *pmu)
 {
-	struct perf_mem_event *e = &perf_mem_events[i];
+	struct perf_mem_event *e = &pmu->mem_events[i];
 
 	if (!e)
 		return NULL;
 
-	if (i == PERF_MEM_EVENTS__LOAD) {
-		if (!mem_loads_name__init) {
-			mem_loads_name__init = true;
-			scnprintf(mem_loads_name, sizeof(mem_loads_name),
-				  e->name, perf_mem_events__loads_ldlat);
+	if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE) {
+		if (e->ldlat) {
+			if (!e->aux_event) {
+				/* ARM and Most of Intel */
+				scnprintf(mem_loads_name, sizeof(mem_loads_name),
+					  e->name, pmu->name,
+					  perf_mem_events__loads_ldlat);
+			} else {
+				/* Intel with mem-loads-aux event */
+				scnprintf(mem_loads_name, sizeof(mem_loads_name),
+					  e->name, pmu->name, pmu->name,
+					  perf_mem_events__loads_ldlat);
+			}
+		} else {
+			if (!e->aux_event) {
+				/* AMD and POWER */
+				scnprintf(mem_loads_name, sizeof(mem_loads_name),
+					  e->name, pmu->name);
+			} else
+				return NULL;
 		}
+
 		return mem_loads_name;
 	}
 
-	return e->name;
+	if (i == PERF_MEM_EVENTS__STORE) {
+		scnprintf(mem_stores_name, sizeof(mem_stores_name),
+			  e->name, pmu->name);
+		return mem_stores_name;
+	}
+
+	return NULL;
 }
 
 __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
@@ -175,7 +197,7 @@ void perf_mem_events__list(struct perf_pmu *pmu)
 			e->tag ? 13 : 0,
 			e->tag ? : "",
 			e->tag && verbose > 0 ? 25 : 0,
-			e->tag && verbose > 0 ? perf_mem_events__name(j, NULL) : "",
+			e->tag && verbose > 0 ? perf_mem_events__name(j, pmu) : "",
 			e->supported ? ": available\n" : "");
 	}
 }
@@ -198,15 +220,15 @@ int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 
 			if (!e->supported) {
 				pr_err("failed: event '%s' not supported\n",
-					perf_mem_events__name(j, pmu->name));
+					perf_mem_events__name(j, pmu));
 				return -1;
 			}
 
 			if (perf_pmus__num_mem_pmus() == 1) {
 				rec_argv[i++] = "-e";
-				rec_argv[i++] = perf_mem_events__name(j, NULL);
+				rec_argv[i++] = perf_mem_events__name(j, pmu);
 			} else {
-				const char *s = perf_mem_events__name(j, pmu->name);
+				const char *s = perf_mem_events__name(j, pmu);
 
 				if (!perf_mem_event__supported(mnt, pmu, e))
 					continue;
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index 59a4303aac96..d257cf67d6d9 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -14,6 +14,8 @@
 struct perf_mem_event {
 	bool		record;
 	bool		supported;
+	bool		ldlat;
+	u32		aux_event;
 	const char	*tag;
 	const char	*name;
 	const char	*sysfs_name;
@@ -39,7 +41,6 @@ extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
 int perf_mem_events__parse(struct perf_pmu *pmu, const char *str);
 int perf_mem_events__init(struct perf_pmu *pmu);
 
-const char *perf_mem_events__name(int i, const char *pmu_name);
 struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i);
 struct perf_pmu *perf_mem_events_find_pmu(void);
 bool is_mem_loads_aux_event(struct evsel *leader);
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec  6 12:13:20 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed,  6 Dec 2023 12:13:20 -0800
Subject: [PATCH 2/6] perf mem: Clean up perf_mem_events__ptr()
In-Reply-To: <20231206201324.184059-1-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
Message-ID: <20231206201324.184059-3-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

The mem_events can be retrieved from the struct perf_pmu now. An ARCH
specific perf_mem_events__ptr() is not required anymore. Remove all of
them.

The Intel hybrid has multiple mem-events-supported PMUs. But they share
the same mem_events. Other ARCHs only support one mem-events-supported
PMU. In the configuration, it's good enough to only configure the
mem_events for one PMU. Add perf_mem_events_find_pmu() which returns the
first mem-events-supported PMU.

In the perf_mem_events__init(), the perf_pmus__scan() is not required
anymore. It avoids checking the sysfs for every PMU on the system.

Make the perf_mem_events__record_args() more generic. Remove the
perf_mem_events__print_unsupport_hybrid().

Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c |  10 +--
 tools/perf/arch/x86/util/mem-events.c   |  18 ++---
 tools/perf/builtin-c2c.c                |  28 +++++--
 tools/perf/builtin-mem.c                |  28 +++++--
 tools/perf/util/mem-events.c            | 103 ++++++++++++------------
 tools/perf/util/mem-events.h            |   9 ++-
 6 files changed, 104 insertions(+), 92 deletions(-)

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index aaa4804922b4..2602e8688727 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -12,17 +12,9 @@ struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
 
 static char mem_ev_name[100];
 
-struct perf_mem_event *perf_mem_events__ptr(int i)
-{
-	if (i >= PERF_MEM_EVENTS__MAX)
-		return NULL;
-
-	return &perf_mem_events_arm[i];
-}
-
 const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
 {
-	struct perf_mem_event *e = perf_mem_events__ptr(i);
+	struct perf_mem_event *e = &perf_mem_events_arm[i];
 
 	if (i >= PERF_MEM_EVENTS__MAX)
 		return NULL;
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 2b81d229982c..5fb41d50118d 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -28,17 +28,6 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
 	E("mem-ldst",	"ibs_op//",	"ibs_op"),
 };
 
-struct perf_mem_event *perf_mem_events__ptr(int i)
-{
-	if (i >= PERF_MEM_EVENTS__MAX)
-		return NULL;
-
-	if (x86__is_amd_cpu())
-		return &perf_mem_events_amd[i];
-
-	return &perf_mem_events_intel[i];
-}
-
 bool is_mem_loads_aux_event(struct evsel *leader)
 {
 	struct perf_pmu *pmu = perf_pmus__find("cpu");
@@ -54,7 +43,12 @@ bool is_mem_loads_aux_event(struct evsel *leader)
 
 const char *perf_mem_events__name(int i, const char *pmu_name)
 {
-	struct perf_mem_event *e = perf_mem_events__ptr(i);
+	struct perf_mem_event *e;
+
+	if (x86__is_amd_cpu())
+		e = &perf_mem_events_amd[i];
+	else
+		e = &perf_mem_events_intel[i];
 
 	if (!e)
 		return NULL;
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index a4cf9de7a7b5..76c760be1bcf 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -3215,12 +3215,19 @@ static int parse_record_events(const struct option *opt,
 			       const char *str, int unset __maybe_unused)
 {
 	bool *event_set = (bool *) opt->value;
+	struct perf_pmu *pmu;
+
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: there is no PMU that supports perf c2c\n");
+		exit(-1);
+	}
 
 	if (!strcmp(str, "list")) {
-		perf_mem_events__list();
+		perf_mem_events__list(pmu);
 		exit(0);
 	}
-	if (perf_mem_events__parse(str))
+	if (perf_mem_events__parse(pmu, str))
 		exit(-1);
 
 	*event_set = true;
@@ -3245,6 +3252,7 @@ static int perf_c2c__record(int argc, const char **argv)
 	bool all_user = false, all_kernel = false;
 	bool event_set = false;
 	struct perf_mem_event *e;
+	struct perf_pmu *pmu;
 	struct option options[] = {
 	OPT_CALLBACK('e', "event", &event_set, "event",
 		     "event selector. Use 'perf c2c record -e list' to list available events",
@@ -3256,7 +3264,13 @@ static int perf_c2c__record(int argc, const char **argv)
 	OPT_END()
 	};
 
-	if (perf_mem_events__init()) {
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: no PMU supports the memory events\n");
+		return -1;
+	}
+
+	if (perf_mem_events__init(pmu)) {
 		pr_err("failed: memory events not supported\n");
 		return -1;
 	}
@@ -3280,7 +3294,7 @@ static int perf_c2c__record(int argc, const char **argv)
 	rec_argv[i++] = "record";
 
 	if (!event_set) {
-		e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD_STORE);
+		e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD_STORE);
 		/*
 		 * The load and store operations are required, use the event
 		 * PERF_MEM_EVENTS__LOAD_STORE if it is supported.
@@ -3289,15 +3303,15 @@ static int perf_c2c__record(int argc, const char **argv)
 			e->record = true;
 			rec_argv[i++] = "-W";
 		} else {
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+			e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD);
 			e->record = true;
 
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__STORE);
+			e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__STORE);
 			e->record = true;
 		}
 	}
 
-	e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+	e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD);
 	if (e->record)
 		rec_argv[i++] = "-W";
 
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index 51499c20da01..8218c4721101 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -43,12 +43,19 @@ static int parse_record_events(const struct option *opt,
 			       const char *str, int unset __maybe_unused)
 {
 	struct perf_mem *mem = *(struct perf_mem **)opt->value;
+	struct perf_pmu *pmu;
+
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: there is no PMU that supports perf mem\n");
+		exit(-1);
+	}
 
 	if (!strcmp(str, "list")) {
-		perf_mem_events__list();
+		perf_mem_events__list(pmu);
 		exit(0);
 	}
-	if (perf_mem_events__parse(str))
+	if (perf_mem_events__parse(pmu, str))
 		exit(-1);
 
 	mem->operation = 0;
@@ -72,6 +79,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 	int ret;
 	bool all_user = false, all_kernel = false;
 	struct perf_mem_event *e;
+	struct perf_pmu *pmu;
 	struct option options[] = {
 	OPT_CALLBACK('e', "event", &mem, "event",
 		     "event selector. use 'perf mem record -e list' to list available events",
@@ -84,7 +92,13 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 	OPT_END()
 	};
 
-	if (perf_mem_events__init()) {
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: no PMU supports the memory events\n");
+		return -1;
+	}
+
+	if (perf_mem_events__init(pmu)) {
 		pr_err("failed: memory events not supported\n");
 		return -1;
 	}
@@ -113,7 +127,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 
 	rec_argv[i++] = "record";
 
-	e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD_STORE);
+	e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD_STORE);
 
 	/*
 	 * The load and store operations are required, use the event
@@ -126,17 +140,17 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 		rec_argv[i++] = "-W";
 	} else {
 		if (mem->operation & MEM_OPERATION_LOAD) {
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+			e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD);
 			e->record = true;
 		}
 
 		if (mem->operation & MEM_OPERATION_STORE) {
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__STORE);
+			e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__STORE);
 			e->record = true;
 		}
 	}
 
-	e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+	e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD);
 	if (e->record)
 		rec_argv[i++] = "-W";
 
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 0a8f415f5efe..887ffdcce338 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -29,17 +29,42 @@ struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
 static char mem_loads_name[100];
 static bool mem_loads_name__init;
 
-struct perf_mem_event * __weak perf_mem_events__ptr(int i)
+struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i)
 {
-	if (i >= PERF_MEM_EVENTS__MAX)
+	if (i >= PERF_MEM_EVENTS__MAX || !pmu)
 		return NULL;
 
-	return &perf_mem_events[i];
+	return &pmu->mem_events[i];
+}
+
+static struct perf_pmu *perf_pmus__scan_mem(struct perf_pmu *pmu)
+{
+	while ((pmu = perf_pmus__scan(pmu)) != NULL) {
+		if (pmu->mem_events)
+			return pmu;
+	}
+	return NULL;
+}
+
+struct perf_pmu *perf_mem_events_find_pmu(void)
+{
+	/*
+	 * The current perf mem doesn't support per-PMU configuration.
+	 * The exact same configuration is applied to all the
+	 * mem_events supported PMUs.
+	 * Return the first mem_events supported PMU.
+	 *
+	 * Notes: The only case which may support multiple mem_events
+	 * supported PMUs is Intel hybrid. The exact same mem_events
+	 * is shared among the PMUs. Only configure the first PMU
+	 * is good enough as well.
+	 */
+	return perf_pmus__scan_mem(NULL);
 }
 
 const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
 {
-	struct perf_mem_event *e = perf_mem_events__ptr(i);
+	struct perf_mem_event *e = &perf_mem_events[i];
 
 	if (!e)
 		return NULL;
@@ -61,7 +86,7 @@ __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
 	return false;
 }
 
-int perf_mem_events__parse(const char *str)
+int perf_mem_events__parse(struct perf_pmu *pmu, const char *str)
 {
 	char *tok, *saveptr = NULL;
 	bool found = false;
@@ -79,7 +104,7 @@ int perf_mem_events__parse(const char *str)
 
 	while (tok) {
 		for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-			struct perf_mem_event *e = perf_mem_events__ptr(j);
+			struct perf_mem_event *e = perf_mem_events__ptr(pmu, j);
 
 			if (!e->tag)
 				continue;
@@ -112,7 +137,7 @@ static bool perf_mem_event__supported(const char *mnt, struct perf_pmu *pmu,
 	return !stat(path, &st);
 }
 
-int perf_mem_events__init(void)
+int perf_mem_events__init(struct perf_pmu *pmu)
 {
 	const char *mnt = sysfs__mount();
 	bool found = false;
@@ -122,8 +147,7 @@ int perf_mem_events__init(void)
 		return -ENOENT;
 
 	for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-		struct perf_mem_event *e = perf_mem_events__ptr(j);
-		struct perf_pmu *pmu = NULL;
+		struct perf_mem_event *e = perf_mem_events__ptr(pmu, j);
 
 		/*
 		 * If the event entry isn't valid, skip initialization
@@ -132,29 +156,20 @@ int perf_mem_events__init(void)
 		if (!e->tag)
 			continue;
 
-		/*
-		 * Scan all PMUs not just core ones, since perf mem/c2c on
-		 * platforms like AMD uses IBS OP PMU which is independent
-		 * of core PMU.
-		 */
-		while ((pmu = perf_pmus__scan(pmu)) != NULL) {
-			e->supported |= perf_mem_event__supported(mnt, pmu, e);
-			if (e->supported) {
-				found = true;
-				break;
-			}
-		}
+		e->supported |= perf_mem_event__supported(mnt, pmu, e);
+		if (e->supported)
+			found = true;
 	}
 
 	return found ? 0 : -ENOENT;
 }
 
-void perf_mem_events__list(void)
+void perf_mem_events__list(struct perf_pmu *pmu)
 {
 	int j;
 
 	for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-		struct perf_mem_event *e = perf_mem_events__ptr(j);
+		struct perf_mem_event *e = perf_mem_events__ptr(pmu, j);
 
 		fprintf(stderr, "%-*s%-*s%s",
 			e->tag ? 13 : 0,
@@ -165,50 +180,32 @@ void perf_mem_events__list(void)
 	}
 }
 
-static void perf_mem_events__print_unsupport_hybrid(struct perf_mem_event *e,
-						    int idx)
-{
-	const char *mnt = sysfs__mount();
-	struct perf_pmu *pmu = NULL;
-
-	while ((pmu = perf_pmus__scan(pmu)) != NULL) {
-		if (!perf_mem_event__supported(mnt, pmu, e)) {
-			pr_err("failed: event '%s' not supported\n",
-			       perf_mem_events__name(idx, pmu->name));
-		}
-	}
-}
-
 int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 				 char **rec_tmp, int *tmp_nr)
 {
 	const char *mnt = sysfs__mount();
+	struct perf_pmu *pmu = NULL;
 	int i = *argv_nr, k = 0;
 	struct perf_mem_event *e;
 
-	for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-		e = perf_mem_events__ptr(j);
-		if (!e->record)
-			continue;
 
-		if (perf_pmus__num_mem_pmus() == 1) {
-			if (!e->supported) {
-				pr_err("failed: event '%s' not supported\n",
-				       perf_mem_events__name(j, NULL));
-				return -1;
-			}
+	while ((pmu = perf_pmus__scan_mem(pmu)) != NULL) {
+		for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
+			e = perf_mem_events__ptr(pmu, j);
 
-			rec_argv[i++] = "-e";
-			rec_argv[i++] = perf_mem_events__name(j, NULL);
-		} else {
-			struct perf_pmu *pmu = NULL;
+			if (!e->record)
+				continue;
 
 			if (!e->supported) {
-				perf_mem_events__print_unsupport_hybrid(e, j);
+				pr_err("failed: event '%s' not supported\n",
+					perf_mem_events__name(j, pmu->name));
 				return -1;
 			}
 
-			while ((pmu = perf_pmus__scan(pmu)) != NULL) {
+			if (perf_pmus__num_mem_pmus() == 1) {
+				rec_argv[i++] = "-e";
+				rec_argv[i++] = perf_mem_events__name(j, NULL);
+			} else {
 				const char *s = perf_mem_events__name(j, pmu->name);
 
 				if (!perf_mem_event__supported(mnt, pmu, e))
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index 8c5694b2d0b0..59a4303aac96 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -36,14 +36,15 @@ enum {
 extern unsigned int perf_mem_events__loads_ldlat;
 extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
 
-int perf_mem_events__parse(const char *str);
-int perf_mem_events__init(void);
+int perf_mem_events__parse(struct perf_pmu *pmu, const char *str);
+int perf_mem_events__init(struct perf_pmu *pmu);
 
 const char *perf_mem_events__name(int i, const char *pmu_name);
-struct perf_mem_event *perf_mem_events__ptr(int i);
+struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i);
+struct perf_pmu *perf_mem_events_find_pmu(void);
 bool is_mem_loads_aux_event(struct evsel *leader);
 
-void perf_mem_events__list(void);
+void perf_mem_events__list(struct perf_pmu *pmu);
 int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 				 char **rec_tmp, int *tmp_nr);
 
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec  6 12:13:24 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed,  6 Dec 2023 12:13:24 -0800
Subject: [PATCH 6/6] perf mem: Remove useless header files for X86
In-Reply-To: <20231206201324.184059-1-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
Message-ID: <20231206201324.184059-7-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

The X86 mem-events.c only has perf_mem_events array now. Remove useless
header files.

Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/x86/util/mem-events.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 71ffe16de751..62df03e91c7e 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -1,11 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
-#include "util/pmu.h"
-#include "util/pmus.h"
-#include "util/env.h"
-#include "map_symbol.h"
-#include "mem-events.h"
 #include "linux/string.h"
-#include "env.h"
+#include "util/map_symbol.h"
+#include "util/mem-events.h"
+#include "mem-events.h"
+
 
 #define MEM_LOADS_AUX		0x8203
 
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec  6 12:13:23 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed,  6 Dec 2023 12:13:23 -0800
Subject: [PATCH 5/6] perf mem: Clean up is_mem_loads_aux_event()
In-Reply-To: <20231206201324.184059-1-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
Message-ID: <20231206201324.184059-6-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

The aux_event can be retrieved from the perf_pmu now. Implement a
generic support.

Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/x86/util/mem-events.c | 13 -------------
 tools/perf/util/mem-events.c          | 14 ++++++++++++--
 2 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index b776d849fc64..71ffe16de751 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -28,16 +28,3 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
 	E(NULL,		NULL,		NULL,	false,	0),
 	E("mem-ldst",	"%s//",		NULL,	false,	0),
 };
-
-bool is_mem_loads_aux_event(struct evsel *leader)
-{
-	struct perf_pmu *pmu = perf_pmus__find("cpu");
-
-	if (!pmu)
-		pmu = perf_pmus__find("cpu_core");
-
-	if (pmu && !perf_pmu__have_event(pmu, "mem-loads-aux"))
-		return false;
-
-	return leader->core.attr.config == MEM_LOADS_AUX;
-}
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 9ea9e9a868c4..336d1109b3a5 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -103,9 +103,19 @@ static const char *perf_mem_events__name(int i, struct perf_pmu *pmu)
 	return NULL;
 }
 
-__weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
+bool is_mem_loads_aux_event(struct evsel *leader)
 {
-	return false;
+	struct perf_pmu *pmu = leader->pmu;
+	struct perf_mem_event *e;
+
+	if (!pmu || !pmu->mem_events)
+		return false;
+
+	e = &pmu->mem_events[PERF_MEM_EVENTS__LOAD];
+	if (!e->aux_event)
+		return false;
+
+	return leader->core.attr.config == e->aux_event;
 }
 
 int perf_mem_events__parse(struct perf_pmu *pmu, const char *str)
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec  6 12:13:22 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed,  6 Dec 2023 12:13:22 -0800
Subject: [PATCH 4/6] perf mem: Clean up perf_mem_event__supported()
In-Reply-To: <20231206201324.184059-1-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
Message-ID: <20231206201324.184059-5-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

For some ARCHs, e.g., ARM and AMD, to get the availability of the
mem-events, perf checks the existence of a specific PMU. For the other
ARCHs, e.g., Intel and Power, perf has to check the existence of some
specific events.

The current perf only iterates the mem-events-supported PMUs. It's not
required to check the existence of a specific PMU anymore.

Rename sysfs_name to event_name, which stores the specific mem-events.
Perf only needs to check those events for the availability of the
mem-events.

Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c   |  8 ++++----
 tools/perf/arch/powerpc/util/mem-events.c |  8 ++++----
 tools/perf/arch/x86/util/mem-events.c     | 20 ++++++++++----------
 tools/perf/util/mem-events.c              | 16 +++++++++-------
 tools/perf/util/mem-events.h              |  2 +-
 5 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index eb2ef84f0fc8..590dddd6b0ab 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -2,10 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
-	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0",	true,	0),
-	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0",	false,	0),
-	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0",	true,	0),
+	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	NULL,	true,	0),
+	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			NULL,	false,	0),
+	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	NULL,	true,	0),
 };
diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
index b7883e38950f..72a6ac2b52f5 100644
--- a/tools/perf/arch/powerpc/util/mem-events.c
+++ b/tools/perf/arch/powerpc/util/mem-events.c
@@ -2,10 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads/",	"cpu/events/mem-loads",		false,	0),
-	E("ldlat-stores",	"%s/mem-stores/",	"cpu/events/mem-stores",	false,	0),
-	E(NULL,			NULL,			NULL,				false,	0),
+	E("ldlat-loads",	"%s/mem-loads/",	"mem-loads",	false,	0),
+	E("ldlat-stores",	"%s/mem-stores/",	"mem-stores",	false,	0),
+	E(NULL,			NULL,			NULL,		false,	0),
 };
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index f0e66a0151a0..b776d849fc64 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -9,24 +9,24 @@
 
 #define MEM_LOADS_AUX		0x8203
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads",	true,	0),
-	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
-	E(NULL,			NULL,				NULL,			false,	0),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"mem-loads",	true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,		false,	0),
 };
 
 struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P",	"%s/events/mem-loads",	true,	MEM_LOADS_AUX),
-	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
-	E(NULL,			NULL,				NULL,			false,	0),
+	E("ldlat-loads",	"{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P",	"mem-loads",	true,	MEM_LOADS_AUX),
+	E("ldlat-stores",	"%s/mem-stores/P",		"mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,		false,	0),
 };
 
 struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
-	E(NULL,		NULL,		NULL,		false,	0),
-	E(NULL,		NULL,		NULL,		false,	0),
-	E("mem-ldst",	"%s//",		"ibs_op",	false,	0),
+	E(NULL,		NULL,		NULL,	false,	0),
+	E(NULL,		NULL,		NULL,	false,	0),
+	E("mem-ldst",	"%s//",		NULL,	false,	0),
 };
 
 bool is_mem_loads_aux_event(struct evsel *leader)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 3a60cbcd6d8e..9ea9e9a868c4 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -17,12 +17,12 @@
 
 unsigned int perf_mem_events__loads_ldlat = 30;
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads/,ldlat=%u/P",	"cpu/events/mem-loads",		true,	0),
-	E("ldlat-stores",	"%s/mem-stores/P",		"cpu/events/mem-stores",	false,	0),
-	E(NULL,			NULL,				NULL,				false,	0),
+	E("ldlat-loads",	"%s/mem-loads/,ldlat=%u/P",	"mem-loads",	true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,		false,	0),
 };
 #undef E
 
@@ -150,12 +150,14 @@ int perf_mem_events__parse(struct perf_pmu *pmu, const char *str)
 static bool perf_mem_event__supported(const char *mnt, struct perf_pmu *pmu,
 				      struct perf_mem_event *e)
 {
-	char sysfs_name[100];
 	char path[PATH_MAX];
 	struct stat st;
 
-	scnprintf(sysfs_name, sizeof(sysfs_name), e->sysfs_name, pmu->name);
-	scnprintf(path, PATH_MAX, "%s/devices/%s", mnt, sysfs_name);
+	if (!e->event_name)
+		return true;
+
+	scnprintf(path, PATH_MAX, "%s/devices/%s/events/%s", mnt, pmu->name, e->event_name);
+
 	return !stat(path, &st);
 }
 
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index d257cf67d6d9..d2875d731da8 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -18,7 +18,7 @@ struct perf_mem_event {
 	u32		aux_event;
 	const char	*tag;
 	const char	*name;
-	const char	*sysfs_name;
+	const char	*event_name;
 };
 
 struct mem_info {
-- 
2.35.1



From festevam at gmail.com  Wed Dec  6 12:14:05 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 17:14:05 -0300
Subject: [PATCH v2] ARM: dts: imx25/27: Pass timing0
Message-ID: <20231206201405.2376738-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per display-timings.yaml, the 'timing' pattern should be used to
describe the display timings.

Change it accordingly to fix the following dt-schema warning:

imx27-apf27dev.dtb: display-timings: '800x480' does not match any of the regexes: '^timing', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/display/panel/display-timings.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
Changes since v1:
- Fix Subject

 .../dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts   | 2 +-
 .../dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts   | 2 +-
 .../dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts    | 2 +-
 arch/arm/boot/dts/nxp/imx/imx25-pdk.dts                         | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts                    | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts  | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts        | 2 +-
 arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts          | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
index fc8a502fc957..6cddb2cc36fe 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
@@ -16,7 +16,7 @@ cmo_qvga: display {
 		bus-width = <18>;
 		display-timings {
 			native-mode = <&qvga_timings>;
-			qvga_timings: 320x240 {
+			qvga_timings: timing0 {
 				clock-frequency = <6500000>;
 				hactive = <320>;
 				vactive = <240>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
index 80a7f96de4c6..64b2ffac463b 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
@@ -16,7 +16,7 @@ dvi_svga: display {
 		bus-width = <18>;
 		display-timings {
 			native-mode = <&dvi_svga_timings>;
-			dvi_svga_timings: 800x600 {
+			dvi_svga_timings: timing0 {
 				clock-frequency = <40000000>;
 				hactive = <800>;
 				vactive = <600>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
index 24027a1fb46d..fb074bfdaa8d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
@@ -16,7 +16,7 @@ dvi_vga: display {
 		bus-width = <18>;
 		display-timings {
 			native-mode = <&dvi_vga_timings>;
-			dvi_vga_timings: 640x480 {
+			dvi_vga_timings: timing0 {
 				clock-frequency = <31250000>;
 				hactive = <640>;
 				vactive = <480>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts b/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
index 14a61dc1e742..6a5563298bf3 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
@@ -68,7 +68,7 @@ wvga: display {
 		bus-width = <18>;
 		display-timings {
 			native-mode = <&wvga_timings>;
-			wvga_timings: 640x480 {
+			wvga_timings: timing0 {
 				hactive = <640>;
 				vactive = <480>;
 				hback-porch = <45>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts b/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts
index a21f1f7c24b8..f047a8487073 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts
@@ -16,7 +16,7 @@ display: display {
 		fsl,pcr = <0xfae80083>;	/* non-standard but required */
 		display-timings {
 			native-mode = <&timing0>;
-			timing0: 800x480 {
+			timing0: timing0 {
 				clock-frequency = <33000033>;
 				hactive = <800>;
 				vactive = <480>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts
index 145e459625b3..d78793601306 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts
@@ -16,7 +16,7 @@ display0: CMO-QVGA {
 
 		display-timings {
 			native-mode = <&timing0>;
-			timing0: 320x240 {
+			timing0: timing0 {
 				clock-frequency = <6500000>;
 				hactive = <320>;
 				vactive = <240>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts
index 25442eba21c1..27c93b9fe049 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts
@@ -19,7 +19,7 @@ display: display {
 		fsl,pcr = <0xf0c88080>;	/* non-standard but required */
 		display-timings {
 			native-mode = <&timing0>;
-			timing0: 640x480 {
+			timing0: timing0 {
 				hactive = <640>;
 				vactive = <480>;
 				hback-porch = <112>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts
index b7df7f20ec04..b8048e12e3d9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts
@@ -19,7 +19,7 @@ display0: LQ035Q7 {
 
 		display-timings {
 			native-mode = <&timing0>;
-			timing0: 240x320 {
+			timing0: timing0 {
 				clock-frequency = <5500000>;
 				hactive = <240>;
 				vactive = <320>;
-- 
2.34.1



From festevam at gmail.com  Wed Dec  6 12:19:05 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  6 Dec 2023 17:19:05 -0300
Subject: [PATCH] ARM: dts: imx27-apf27dev: Fix LED name
Message-ID: <20231206201905.2383591-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per leds-gpio.yaml, the led names should start with 'led'.

Change it to fix the following dt-schema warning:

imx27-apf27dev.dtb: leds: 'user' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/leds/leds-gpio.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts b/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts
index f047a8487073..849306cb4532 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts
@@ -47,7 +47,7 @@ leds {
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		user {
+		led-user {
 			label = "Heartbeat";
 			gpios = <&gpio6 14 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "heartbeat";
-- 
2.34.1



From thiago.bauermann at linaro.org  Wed Dec  6 12:22:49 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Wed, 06 Dec 2023 17:22:49 -0300
Subject: [PATCH v7 21/39] arm64/gcs: Allocate a new GCS for threads with
 GCS enabled
In-Reply-To: <20231122-arm64-gcs-v7-21-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-21-201c483bd775@kernel.org>
Message-ID: <87il5bhyhy.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

> When a new thread is created by a thread with GCS enabled the GCS needs
> to be specified along with the regular stack.  clone3() has been
> extended to support this case, allowing userspace to explicitly request
> the size for the GCS to be created, but plain clone() is not extensible
> and existing clone3() users will not specify a size.
>
> For compatibility with these cases and also x86 (which did not initially
> implement clone3() support for shadow stacks) if no GCS is specified we
> will allocate one thread so when a thread is created which has GCS
                    ~~~~~~

This "thread" seems extraneous in the sentence. Remove it?

> enabled allocate one for it.  We follow the extensively discussed x86
> implementation and allocate min(RLIMIT_STACK, 4G).  Since the GCS only

Isn't it min(RLIMIT_STACK/2, 2G)?

> stores the call stack and not any variables this should be more than
> sufficient for most applications.
>
> GCSs allocated via this mechanism then it will be freed when the thread
> exits.

I'm not sure I parsed this sentence correctly. Is it missing an "If" at
the beginning?

-- 
Thiago


From linux at armlinux.org.uk  Wed Dec  6 12:23:05 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 6 Dec 2023 20:23:05 +0000
Subject: [RFC PATCH v2 8/8] net: ethernet: mtk_eth_soc: add paths and
 SerDes modes for MT7988
In-Reply-To: <ZXDQ94Xh3gzL3IR9@makrotopia.org>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <3ccc33fa14310ab47e90ff8e6ce46f1562bb838e.1701826319.git.daniel@makrotopia.org>
 <ZXDDtmRklS6o994V@shell.armlinux.org.uk>
 <ZXDQ94Xh3gzL3IR9@makrotopia.org>
Message-ID: <ZXDYKeXsMuJZlzWB@shell.armlinux.org.uk>

On Wed, Dec 06, 2023 at 07:52:23PM +0000, Daniel Golle wrote:
> On Wed, Dec 06, 2023 at 06:55:50PM +0000, Russell King (Oracle) wrote:
> > On Wed, Dec 06, 2023 at 01:45:17AM +0000, Daniel Golle wrote:
> > > @@ -516,6 +538,21 @@ static struct phylink_pcs *mtk_mac_select_pcs(struct phylink_config *config,
> > >  	struct mtk_eth *eth = mac->hw;
> > >  	unsigned int sid;
> > >  
> > > +	if (mtk_is_netsys_v3_or_greater(eth)) {
> > > +		switch (interface) {
> > > +		case PHY_INTERFACE_MODE_1000BASEX:
> > > +		case PHY_INTERFACE_MODE_2500BASEX:
> > > +		case PHY_INTERFACE_MODE_SGMII:
> > > +			return mtk_pcs_lynxi_select_pcs(mac->sgmii_pcs_of_node, interface);
> > > +		case PHY_INTERFACE_MODE_5GBASER:
> > > +		case PHY_INTERFACE_MODE_10GBASER:
> > > +		case PHY_INTERFACE_MODE_USXGMII:
> > > +			return mtk_usxgmii_select_pcs(mac->usxgmii_pcs_of_node, interface);
> > 
> > From what I can see, neither of these two "select_pcs" methods that
> > you're calling makes any use of the "interface" you pass to them.
> > I'm not sure what they _could_ do with it either, given that what
> > you're effectively doing here is getting the phylink_pcs structure from
> > the driver, and each one only has a single phylink_pcs.
> 
> Yes, you are right, the interface parameter isn't used, I will drop
> it from both mtk_*_select_pcs() prototypes.
> 
> In the long run we may want something like
> struct phylink_pcs *of_pcs_get(struct device_node *np, phy_interface_t interface)
> provided by a to-be-built drivers/net/pcs/core.c...

Again... it's not as simple as that. As soon as we get into the
situation that some _other_ driver becomes responsible for providing
the struct phylink_pcs pointer, we _then_ need to have some way of
dealing with that device going away.

By that I mean that the memory pointed to returned from such a function
that you are proposing above could be freed - or worse could be unmapped
from the kernel address space, and the same goes for the operations
structure as well - even more so if the "ops" are part of module data
and the module is unloaded.

As I know how these discussions go (it's not my first time bringing up
these kinds of multi-driver interations), no, locking the module into
memory doesn't work, and shows a lack of a full understanding of the
problem.

We need to have a way that when a PCS device is removed, that is
propagated up the management levels and causes the PCS to be gracefully
removed from the network driver (in other words, from phylink).

I won't accept a hack that sticky-plasters around the problem - not for
code that I am involved in actively maintaining - and sticky-plastering
around this class of problem seems to happen all too often in the
kernel.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From lkp at intel.com  Wed Dec  6 12:36:52 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 7 Dec 2023 04:36:52 +0800
Subject: [PATCH] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <20231206090641.18849-1-jensenhuang@friendlyarm.com>
References: <20231206090641.18849-1-jensenhuang@friendlyarm.com>
Message-ID: <202312070421.Lccd0PSI-lkp@intel.com>

Hi Jensen,

kernel test robot noticed the following build warnings:

[auto build test WARNING on rockchip/for-next]
[also build test WARNING on linus/master v6.7-rc4 next-20231206]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Jensen-Huang/i2c-rk3x-fix-potential-spinlock-recursion-on-poll/20231206-170807
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next
patch link:    https://lore.kernel.org/r/20231206090641.18849-1-jensenhuang%40friendlyarm.com
patch subject: [PATCH] i2c: rk3x: fix potential spinlock recursion on poll
config: arc-randconfig-r081-20231206 (https://download.01.org/0day-ci/archive/20231207/202312070421.Lccd0PSI-lkp at intel.com/config)
compiler: arc-elf-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231207/202312070421.Lccd0PSI-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312070421.Lccd0PSI-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> drivers/i2c/busses/i2c-rk3x.c:223: warning: Function parameter or member 'irq' not described in 'rk3x_i2c'


vim +223 drivers/i2c/busses/i2c-rk3x.c

c41aa3ce938b68 Max Schwarz  2014-06-11  171  
0a6ad2f95f36bf David Wu     2016-05-16  172  /**
0a6ad2f95f36bf David Wu     2016-05-16  173   * struct rk3x_i2c - private data of the controller
0a6ad2f95f36bf David Wu     2016-05-16  174   * @adap: corresponding I2C adapter
0a6ad2f95f36bf David Wu     2016-05-16  175   * @dev: device for this controller
0a6ad2f95f36bf David Wu     2016-05-16  176   * @soc_data: related soc data struct
0a6ad2f95f36bf David Wu     2016-05-16  177   * @regs: virtual memory area
7e086c3fc2df09 David Wu     2016-05-16  178   * @clk: function clk for rk3399 or function & Bus clks for others
7e086c3fc2df09 David Wu     2016-05-16  179   * @pclk: Bus clk for rk3399
0a6ad2f95f36bf David Wu     2016-05-16  180   * @clk_rate_nb: i2c clk rate change notify
0a6ad2f95f36bf David Wu     2016-05-16  181   * @t: I2C known timing information
0a6ad2f95f36bf David Wu     2016-05-16  182   * @lock: spinlock for the i2c bus
0a6ad2f95f36bf David Wu     2016-05-16  183   * @wait: the waitqueue to wait for i2c transfer
0a6ad2f95f36bf David Wu     2016-05-16  184   * @busy: the condition for the event to wait for
0a6ad2f95f36bf David Wu     2016-05-16  185   * @msg: current i2c message
0a6ad2f95f36bf David Wu     2016-05-16  186   * @addr: addr of i2c slave device
0a6ad2f95f36bf David Wu     2016-05-16  187   * @mode: mode of i2c transfer
0a6ad2f95f36bf David Wu     2016-05-16  188   * @is_last_msg: flag determines whether it is the last msg in this transfer
0a6ad2f95f36bf David Wu     2016-05-16  189   * @state: state of i2c transfer
0a6ad2f95f36bf David Wu     2016-05-16  190   * @processed: byte length which has been send or received
0a6ad2f95f36bf David Wu     2016-05-16  191   * @error: error code for i2c transfer
0a6ad2f95f36bf David Wu     2016-05-16  192   */
c41aa3ce938b68 Max Schwarz  2014-06-11  193  struct rk3x_i2c {
c41aa3ce938b68 Max Schwarz  2014-06-11  194  	struct i2c_adapter adap;
c41aa3ce938b68 Max Schwarz  2014-06-11  195  	struct device *dev;
d032a2eb2e3b9f Julia Lawall 2018-01-02  196  	const struct rk3x_i2c_soc_data *soc_data;
c41aa3ce938b68 Max Schwarz  2014-06-11  197  
c41aa3ce938b68 Max Schwarz  2014-06-11  198  	/* Hardware resources */
c41aa3ce938b68 Max Schwarz  2014-06-11  199  	void __iomem *regs;
c41aa3ce938b68 Max Schwarz  2014-06-11  200  	struct clk *clk;
7e086c3fc2df09 David Wu     2016-05-16  201  	struct clk *pclk;
249051f49907e7 Max Schwarz  2014-11-20  202  	struct notifier_block clk_rate_nb;
58bb392dd4c7fc Jensen Huang 2023-12-06  203  	int irq;
c41aa3ce938b68 Max Schwarz  2014-06-11  204  
c41aa3ce938b68 Max Schwarz  2014-06-11  205  	/* Settings */
1ab92956d4aac5 David Wu     2016-03-17  206  	struct i2c_timings t;
c41aa3ce938b68 Max Schwarz  2014-06-11  207  
c41aa3ce938b68 Max Schwarz  2014-06-11  208  	/* Synchronization & notification */
c41aa3ce938b68 Max Schwarz  2014-06-11  209  	spinlock_t lock;
c41aa3ce938b68 Max Schwarz  2014-06-11  210  	wait_queue_head_t wait;
c41aa3ce938b68 Max Schwarz  2014-06-11  211  	bool busy;
c41aa3ce938b68 Max Schwarz  2014-06-11  212  
c41aa3ce938b68 Max Schwarz  2014-06-11  213  	/* Current message */
c41aa3ce938b68 Max Schwarz  2014-06-11  214  	struct i2c_msg *msg;
c41aa3ce938b68 Max Schwarz  2014-06-11  215  	u8 addr;
c41aa3ce938b68 Max Schwarz  2014-06-11  216  	unsigned int mode;
c41aa3ce938b68 Max Schwarz  2014-06-11  217  	bool is_last_msg;
c41aa3ce938b68 Max Schwarz  2014-06-11  218  
c41aa3ce938b68 Max Schwarz  2014-06-11  219  	/* I2C state machine */
c41aa3ce938b68 Max Schwarz  2014-06-11  220  	enum rk3x_i2c_state state;
0a6ad2f95f36bf David Wu     2016-05-16  221  	unsigned int processed;
c41aa3ce938b68 Max Schwarz  2014-06-11  222  	int error;
c41aa3ce938b68 Max Schwarz  2014-06-11 @223  };
c41aa3ce938b68 Max Schwarz  2014-06-11  224  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From acme at kernel.org  Wed Dec  6 12:38:48 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Wed, 6 Dec 2023 17:38:48 -0300
Subject: [PATCH 6/6] perf mem: Remove useless header files for X86
In-Reply-To: <20231206201324.184059-7-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
 <20231206201324.184059-7-kan.liang@linux.intel.com>
Message-ID: <ZXDb2Gs1ECjejSbn@kernel.org>

Em Wed, Dec 06, 2023 at 12:13:24PM -0800, kan.liang at linux.intel.com escreveu:
> From: Kan Liang <kan.liang at linux.intel.com>
> 
> The X86 mem-events.c only has perf_mem_events array now. Remove useless
> header files.

It would be great that those were removed while you made the cleanups,
i.e. removed the need for one of them, remove it together with the
refactorings, etc.

But I don't think this is a requirement, just would make it cleaner.

Will wait for reviews now.

- Arnaldo
 
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
> ---
>  tools/perf/arch/x86/util/mem-events.c | 10 ++++------
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index 71ffe16de751..62df03e91c7e 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -1,11 +1,9 @@
>  // SPDX-License-Identifier: GPL-2.0
> -#include "util/pmu.h"
> -#include "util/pmus.h"
> -#include "util/env.h"
> -#include "map_symbol.h"
> -#include "mem-events.h"
>  #include "linux/string.h"
> -#include "env.h"
> +#include "util/map_symbol.h"
> +#include "util/mem-events.h"
> +#include "mem-events.h"
> +
>  
>  #define MEM_LOADS_AUX		0x8203
>  
> -- 
> 2.35.1
> 

-- 

- Arnaldo


From rafael at kernel.org  Wed Dec  6 12:41:05 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 6 Dec 2023 21:41:05 +0100
Subject: [PATCH v2 2/2] cpufreq: Wire-up arch-flavored freq info into cpufreq_verify_current_freq
In-Reply-To: <20231127160838.1403404-3-beata.michalska@arm.com>
References: <20231127160838.1403404-1-beata.michalska@arm.com> <20231127160838.1403404-3-beata.michalska@arm.com>
Message-ID: <CAJZ5v0jh3mG3hyFS6war=0bk3PvsVtTwZ1_YwwWov36Bmz7q0w@mail.gmail.com>

On Mon, Nov 27, 2023 at 5:09?PM Beata Michalska <beata.michalska at arm.com> wrote:
>
> From: Sumit Gupta <sumitg at nvidia.com>
>
> When available, use arch_freq_get_on_cpu to obtain current frequency
> (usually an average reported over given period of time)
> to better align the cpufreq's view on the current state of affairs.

And why is this a good idea?

Any problem statement?

> This also automatically pulls in the update for cpuinfo_cur_freq sysfs
> attribute, aligning it with the scaling_cur_freq one, and thus providing
> consistent view on relevant platforms.

I have no idea what the above is supposed to mean, sorry.

> Signed-off-by: Sumit Gupta <sumitg at nvidia.com>
> [BM: Subject & commit msg]
> Signed-off-by: Beata Michalska <beata.michalska at arm.com>
> ---
>  drivers/cpufreq/cpufreq.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 8c4f9c2f9c44..109559438f45 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1756,7 +1756,8 @@ static unsigned int cpufreq_verify_current_freq(struct cpufreq_policy *policy, b
>  {
>         unsigned int new_freq;
>
> -       new_freq = cpufreq_driver->get(policy->cpu);
> +       new_freq = arch_freq_get_on_cpu(policy->cpu);
> +       new_freq = new_freq ?: cpufreq_driver->get(policy->cpu);

Please don't use ?: in general and it is not even useful here AFAICS.

What would be wrong with

new_freq = arch_freq_get_on_cpu(policy->cpu);
if (!new_freq)
        new_freq = cpufreq_driver->get(policy->cpu);

?

>         if (!new_freq)
>                 return 0;
>
> --


From daniel at makrotopia.org  Wed Dec  6 12:47:25 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 6 Dec 2023 20:47:25 +0000
Subject: [RFC PATCH v2 8/8] net: ethernet: mtk_eth_soc: add paths and
 SerDes modes for MT7988
In-Reply-To: <ZXDYKeXsMuJZlzWB@shell.armlinux.org.uk>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <3ccc33fa14310ab47e90ff8e6ce46f1562bb838e.1701826319.git.daniel@makrotopia.org>
 <ZXDDtmRklS6o994V@shell.armlinux.org.uk>
 <ZXDQ94Xh3gzL3IR9@makrotopia.org>
 <ZXDYKeXsMuJZlzWB@shell.armlinux.org.uk>
Message-ID: <ZXDd3VmlG0e_Uzmk@makrotopia.org>

Hi Russell,

thank for going into my patch in depth and taking your time for an
elaborate and constructive answer.

On Wed, Dec 06, 2023 at 08:23:05PM +0000, Russell King (Oracle) wrote:
> On Wed, Dec 06, 2023 at 07:52:23PM +0000, Daniel Golle wrote:
> > On Wed, Dec 06, 2023 at 06:55:50PM +0000, Russell King (Oracle) wrote:
> > > On Wed, Dec 06, 2023 at 01:45:17AM +0000, Daniel Golle wrote:
> > > > @@ -516,6 +538,21 @@ static struct phylink_pcs *mtk_mac_select_pcs(struct phylink_config *config,
> > > >  	struct mtk_eth *eth = mac->hw;
> > > >  	unsigned int sid;
> > > >  
> > > > +	if (mtk_is_netsys_v3_or_greater(eth)) {
> > > > +		switch (interface) {
> > > > +		case PHY_INTERFACE_MODE_1000BASEX:
> > > > +		case PHY_INTERFACE_MODE_2500BASEX:
> > > > +		case PHY_INTERFACE_MODE_SGMII:
> > > > +			return mtk_pcs_lynxi_select_pcs(mac->sgmii_pcs_of_node, interface);
> > > > +		case PHY_INTERFACE_MODE_5GBASER:
> > > > +		case PHY_INTERFACE_MODE_10GBASER:
> > > > +		case PHY_INTERFACE_MODE_USXGMII:
> > > > +			return mtk_usxgmii_select_pcs(mac->usxgmii_pcs_of_node, interface);
> > > 
> > > From what I can see, neither of these two "select_pcs" methods that
> > > you're calling makes any use of the "interface" you pass to them.
> > > I'm not sure what they _could_ do with it either, given that what
> > > you're effectively doing here is getting the phylink_pcs structure from
> > > the driver, and each one only has a single phylink_pcs.
> > 
> > Yes, you are right, the interface parameter isn't used, I will drop
> > it from both mtk_*_select_pcs() prototypes.
> > 
> > In the long run we may want something like
> > struct phylink_pcs *of_pcs_get(struct device_node *np, phy_interface_t interface)
> > provided by a to-be-built drivers/net/pcs/core.c...
> 
> Again... it's not as simple as that. As soon as we get into the
> situation that some _other_ driver becomes responsible for providing
> the struct phylink_pcs pointer, we _then_ need to have some way of
> dealing with that device going away.

I assume you are referring to struct phylink_pcs *of_pcs_get(...),
right? And true, it'd be quite a complex piece of infrastructure.

> 
> By that I mean that the memory pointed to returned from such a function
> that you are proposing above could be freed - or worse could be unmapped
> from the kernel address space, and the same goes for the operations
> structure as well - even more so if the "ops" are part of module data
> and the module is unloaded.
> 
> As I know how these discussions go (it's not my first time bringing up
> these kinds of multi-driver interations), no, locking the module into
> memory doesn't work, and shows a lack of a full understanding of the
> problem.
> 
> We need to have a way that when a PCS device is removed, that is
> propagated up the management levels and causes the PCS to be gracefully
> removed from the network driver (in other words, from phylink).

I see -- spontanous removal of the PCS may not be a practical problem
on that very hardware, but from the driver model point of view, it is.

Should the callback for removal be implemented as part of the network
driver or are you suggesting to add such infrastructure to phylink?

> 
> I won't accept a hack that sticky-plasters around the problem - not for
> code that I am involved in actively maintaining - and sticky-plastering
> around this class of problem seems to happen all too often in the
> kernel.

Oh yes, I can see that every day when testing various SFP modules with
exposed PHYs -- and often get stackdumps thrown at me when I remove
them...


From laurent.pinchart at ideasonboard.com  Wed Dec  6 12:51:35 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 6 Dec 2023 22:51:35 +0200
Subject: [PATCH v2 1/4] media: rkisp1: Drop IRQF_SHARED
In-Reply-To: <20231206-rkisp-irq-fix-v2-1-6ba4185eeb1f@ideasonboard.com>
References: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
 <20231206-rkisp-irq-fix-v2-1-6ba4185eeb1f@ideasonboard.com>
Message-ID: <20231206205135.GB29417@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Wed, Dec 06, 2023 at 12:12:28PM +0200, Tomi Valkeinen wrote:
> In all known platforms the ISP has dedicated IRQ lines, but for some
> reason the driver uses IRQF_SHARED.
> 
> Supporting IRQF_SHARED properly requires handling interrupts even when
> our device is disabled, and the driver does not handle this. To avoid
> adding such code, and to be sure the driver won't accidentally be used
> in a platform with shared interrupts, let's drop the IRQF_SHARED flag.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
>  drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 2b9886fd0800..d4950294b7b9 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -573,7 +573,7 @@ static int rkisp1_probe(struct platform_device *pdev)
>  		if (irq < 0)
>  			return irq;
>  
> -		ret = devm_request_irq(dev, irq, info->isrs[i].isr, IRQF_SHARED,
> +		ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0,
>  				       dev_driver_string(dev), dev);
>  		if (ret) {
>  			dev_err(dev, "request irq failed: %d\n", ret);
> 

-- 
Regards,

Laurent Pinchart


From irogers at google.com  Wed Dec  6 13:01:12 2023
From: irogers at google.com (Ian Rogers)
Date: Wed, 6 Dec 2023 13:01:12 -0800
Subject: [PATCH 1/6] perf mem: Add mem_events into the supported perf_pmu
In-Reply-To: <20231206201324.184059-2-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com> <20231206201324.184059-2-kan.liang@linux.intel.com>
Message-ID: <CAP-5=fWD9EVHxR+2KE5JPGw_-+rDUbFVE04LNK+n1b3Mo53jqw@mail.gmail.com>

On Wed, Dec 6, 2023 at 12:13?PM <kan.liang at linux.intel.com> wrote:
>
> From: Kan Liang <kan.liang at linux.intel.com>
>
> With the mem_events, perf doesn't need to read sysfs for each PMU to
> find the mem-events-supported PMU. The patch also makes it possible to
> clean up the related __weak functions later.
>
> The patch is only to add the mem_events into the perf_pmu for all ARCHs.
> It will be used in the later cleanup patches.
>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>

Reviewed-by: Ian Rogers <irogers at google.com>

> ---
>  tools/perf/arch/arm64/util/mem-events.c | 4 ++--
>  tools/perf/arch/arm64/util/mem-events.h | 7 +++++++
>  tools/perf/arch/arm64/util/pmu.c        | 6 ++++++
>  tools/perf/arch/s390/util/pmu.c         | 3 +++
>  tools/perf/arch/x86/util/mem-events.c   | 4 ++--
>  tools/perf/arch/x86/util/mem-events.h   | 9 +++++++++
>  tools/perf/arch/x86/util/pmu.c          | 7 +++++++
>  tools/perf/util/mem-events.c            | 2 +-
>  tools/perf/util/mem-events.h            | 1 +
>  tools/perf/util/pmu.c                   | 4 +++-
>  tools/perf/util/pmu.h                   | 7 +++++++
>  11 files changed, 48 insertions(+), 6 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/mem-events.h
>  create mode 100644 tools/perf/arch/x86/util/mem-events.h
>
> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
> index 3bcc5c7035c2..aaa4804922b4 100644
> --- a/tools/perf/arch/arm64/util/mem-events.c
> +++ b/tools/perf/arch/arm64/util/mem-events.c
> @@ -4,7 +4,7 @@
>
>  #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>
> -static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
> +struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
>         E("spe-load",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",       "arm_spe_0"),
>         E("spe-store",  "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                      "arm_spe_0"),
>         E("spe-ldst",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",       "arm_spe_0"),
> @@ -17,7 +17,7 @@ struct perf_mem_event *perf_mem_events__ptr(int i)
>         if (i >= PERF_MEM_EVENTS__MAX)
>                 return NULL;
>
> -       return &perf_mem_events[i];
> +       return &perf_mem_events_arm[i];
>  }
>
>  const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
> diff --git a/tools/perf/arch/arm64/util/mem-events.h b/tools/perf/arch/arm64/util/mem-events.h
> new file mode 100644
> index 000000000000..5fc50be4be38
> --- /dev/null
> +++ b/tools/perf/arch/arm64/util/mem-events.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ARM64_MEM_EVENTS_H
> +#define _ARM64_MEM_EVENTS_H
> +
> +extern struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX];
> +
> +#endif /* _ARM64_MEM_EVENTS_H */
> diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
> index 2a4eab2d160e..69673fcf4a61 100644
> --- a/tools/perf/arch/arm64/util/pmu.c
> +++ b/tools/perf/arch/arm64/util/pmu.c
> @@ -8,6 +8,12 @@
>  #include <api/fs/fs.h>
>  #include <math.h>
>
> +void perf_pmu__arch_init(struct perf_pmu *pmu)
> +{
> +       if (strcmp(pmu->name, "arm_spe_0"))
> +               pmu->mem_events = perf_mem_events_arm;
> +}
> +
>  const struct pmu_metrics_table *pmu_metrics_table__find(void)
>  {
>         struct perf_pmu *pmu;
> diff --git a/tools/perf/arch/s390/util/pmu.c b/tools/perf/arch/s390/util/pmu.c
> index 886c30e001fa..225d7dc2379c 100644
> --- a/tools/perf/arch/s390/util/pmu.c
> +++ b/tools/perf/arch/s390/util/pmu.c
> @@ -19,4 +19,7 @@ void perf_pmu__arch_init(struct perf_pmu *pmu)
>             !strcmp(pmu->name, S390_PMUPAI_EXT) ||
>             !strcmp(pmu->name, S390_PMUCPUM_CF))
>                 pmu->selectable = true;
> +
> +       if (pmu->is_core)
> +               pmu->mem_events = perf_mem_events;
>  }
> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index 191b372f9a2d..2b81d229982c 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -16,13 +16,13 @@ static char mem_stores_name[100];
>
>  #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>
> -static struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
> +struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
>         E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "%s/events/mem-loads"),
>         E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores"),
>         E(NULL,                 NULL,                           NULL),
>  };
>
> -static struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
> +struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
>         E(NULL,         NULL,           NULL),
>         E(NULL,         NULL,           NULL),
>         E("mem-ldst",   "ibs_op//",     "ibs_op"),
> diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
> new file mode 100644
> index 000000000000..3959e427f482
> --- /dev/null
> +++ b/tools/perf/arch/x86/util/mem-events.h
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _X86_MEM_EVENTS_H
> +#define _X86_MEM_EVENTS_H
> +
> +extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
> +
> +extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
> +
> +#endif /* _X86_MEM_EVENTS_H */
> diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
> index 469555ae9b3c..7e69f4f2e363 100644
> --- a/tools/perf/arch/x86/util/pmu.c
> +++ b/tools/perf/arch/x86/util/pmu.c
> @@ -15,6 +15,7 @@
>  #include "../../../util/pmu.h"
>  #include "../../../util/fncache.h"
>  #include "../../../util/pmus.h"
> +#include "mem-events.h"
>  #include "env.h"
>
>  void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
> @@ -30,6 +31,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
>                 pmu->selectable = true;
>         }
>  #endif
> +
> +       if (x86__is_amd_cpu()) {
> +               if (strcmp(pmu->name, "ibs_op"))
> +                       pmu->mem_events = perf_mem_events_amd;
> +       } else if (pmu->is_core)
> +               pmu->mem_events = perf_mem_events_intel;
>  }
>
>  int perf_pmus__num_mem_pmus(void)
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index 3a2e3687878c..0a8f415f5efe 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -19,7 +19,7 @@ unsigned int perf_mem_events__loads_ldlat = 30;
>
>  #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>
> -static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
> +struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
>         E("ldlat-loads",        "cpu/mem-loads,ldlat=%u/P",     "cpu/events/mem-loads"),
>         E("ldlat-stores",       "cpu/mem-stores/P",             "cpu/events/mem-stores"),
>         E(NULL,                 NULL,                           NULL),
> diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
> index b40ad6ea93fc..8c5694b2d0b0 100644
> --- a/tools/perf/util/mem-events.h
> +++ b/tools/perf/util/mem-events.h
> @@ -34,6 +34,7 @@ enum {
>  };
>
>  extern unsigned int perf_mem_events__loads_ldlat;
> +extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
>
>  int perf_mem_events__parse(const char *str);
>  int perf_mem_events__init(void);
> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index 3c9609944a2f..3d4373b8ab63 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -986,8 +986,10 @@ static int pmu_max_precise(int dirfd, struct perf_pmu *pmu)
>  }
>
>  void __weak
> -perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
> +perf_pmu__arch_init(struct perf_pmu *pmu)
>  {
> +       if (pmu->is_core)
> +               pmu->mem_events = perf_mem_events;
>  }
>
>  struct perf_pmu *perf_pmu__lookup(struct list_head *pmus, int dirfd, const char *name)
> diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
> index 424c3fee0949..e35d985206db 100644
> --- a/tools/perf/util/pmu.h
> +++ b/tools/perf/util/pmu.h
> @@ -10,6 +10,8 @@
>  #include <stdio.h>
>  #include "parse-events.h"
>  #include "pmu-events/pmu-events.h"
> +#include "map_symbol.h"

nit: unused?

> +#include "mem-events.h"
>
>  struct evsel_config_term;
>  struct perf_cpu_map;
> @@ -162,6 +164,11 @@ struct perf_pmu {
>                  */
>                 bool exclude_guest;
>         } missing_features;
> +
> +       /**
> +        * @mem_events: List of the supported mem events
> +        */
> +       struct perf_mem_event *mem_events;
>  };
>
>  /** @perf_pmu__fake: A special global PMU used for testing. */
> --
> 2.35.1
>


From irogers at google.com  Wed Dec  6 13:04:14 2023
From: irogers at google.com (Ian Rogers)
Date: Wed, 6 Dec 2023 13:04:14 -0800
Subject: [PATCH 2/6] perf mem: Clean up perf_mem_events__ptr()
In-Reply-To: <20231206201324.184059-3-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com> <20231206201324.184059-3-kan.liang@linux.intel.com>
Message-ID: <CAP-5=fUhaOgMZuhhsmjkTL6QqEQzcjq9GjJyteLG5RTWuBQ0gg@mail.gmail.com>

On Wed, Dec 6, 2023 at 12:13?PM <kan.liang at linux.intel.com> wrote:
>
> From: Kan Liang <kan.liang at linux.intel.com>
>
> The mem_events can be retrieved from the struct perf_pmu now. An ARCH
> specific perf_mem_events__ptr() is not required anymore. Remove all of
> them.
>
> The Intel hybrid has multiple mem-events-supported PMUs. But they share
> the same mem_events. Other ARCHs only support one mem-events-supported
> PMU. In the configuration, it's good enough to only configure the
> mem_events for one PMU. Add perf_mem_events_find_pmu() which returns the
> first mem-events-supported PMU.
>
> In the perf_mem_events__init(), the perf_pmus__scan() is not required
> anymore. It avoids checking the sysfs for every PMU on the system.
>
> Make the perf_mem_events__record_args() more generic. Remove the
> perf_mem_events__print_unsupport_hybrid().
>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>

Reviewed-by: Ian Rogers <irogers at google.com>

> ---
>  tools/perf/arch/arm64/util/mem-events.c |  10 +--
>  tools/perf/arch/x86/util/mem-events.c   |  18 ++---
>  tools/perf/builtin-c2c.c                |  28 +++++--
>  tools/perf/builtin-mem.c                |  28 +++++--
>  tools/perf/util/mem-events.c            | 103 ++++++++++++------------
>  tools/perf/util/mem-events.h            |   9 ++-
>  6 files changed, 104 insertions(+), 92 deletions(-)
>
> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
> index aaa4804922b4..2602e8688727 100644
> --- a/tools/perf/arch/arm64/util/mem-events.c
> +++ b/tools/perf/arch/arm64/util/mem-events.c
> @@ -12,17 +12,9 @@ struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
>
>  static char mem_ev_name[100];
>
> -struct perf_mem_event *perf_mem_events__ptr(int i)
> -{
> -       if (i >= PERF_MEM_EVENTS__MAX)
> -               return NULL;
> -
> -       return &perf_mem_events_arm[i];
> -}
> -
>  const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
>  {
> -       struct perf_mem_event *e = perf_mem_events__ptr(i);
> +       struct perf_mem_event *e = &perf_mem_events_arm[i];
>
>         if (i >= PERF_MEM_EVENTS__MAX)
>                 return NULL;
> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index 2b81d229982c..5fb41d50118d 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -28,17 +28,6 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
>         E("mem-ldst",   "ibs_op//",     "ibs_op"),
>  };
>
> -struct perf_mem_event *perf_mem_events__ptr(int i)
> -{
> -       if (i >= PERF_MEM_EVENTS__MAX)
> -               return NULL;
> -
> -       if (x86__is_amd_cpu())
> -               return &perf_mem_events_amd[i];
> -
> -       return &perf_mem_events_intel[i];
> -}
> -
>  bool is_mem_loads_aux_event(struct evsel *leader)
>  {
>         struct perf_pmu *pmu = perf_pmus__find("cpu");
> @@ -54,7 +43,12 @@ bool is_mem_loads_aux_event(struct evsel *leader)
>
>  const char *perf_mem_events__name(int i, const char *pmu_name)
>  {
> -       struct perf_mem_event *e = perf_mem_events__ptr(i);
> +       struct perf_mem_event *e;
> +
> +       if (x86__is_amd_cpu())
> +               e = &perf_mem_events_amd[i];
> +       else
> +               e = &perf_mem_events_intel[i];
>
>         if (!e)
>                 return NULL;
> diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
> index a4cf9de7a7b5..76c760be1bcf 100644
> --- a/tools/perf/builtin-c2c.c
> +++ b/tools/perf/builtin-c2c.c
> @@ -3215,12 +3215,19 @@ static int parse_record_events(const struct option *opt,
>                                const char *str, int unset __maybe_unused)
>  {
>         bool *event_set = (bool *) opt->value;
> +       struct perf_pmu *pmu;
> +
> +       pmu = perf_mem_events_find_pmu();
> +       if (!pmu) {
> +               pr_err("failed: there is no PMU that supports perf c2c\n");
> +               exit(-1);
> +       }
>
>         if (!strcmp(str, "list")) {
> -               perf_mem_events__list();
> +               perf_mem_events__list(pmu);
>                 exit(0);
>         }
> -       if (perf_mem_events__parse(str))
> +       if (perf_mem_events__parse(pmu, str))
>                 exit(-1);
>
>         *event_set = true;
> @@ -3245,6 +3252,7 @@ static int perf_c2c__record(int argc, const char **argv)
>         bool all_user = false, all_kernel = false;
>         bool event_set = false;
>         struct perf_mem_event *e;
> +       struct perf_pmu *pmu;
>         struct option options[] = {
>         OPT_CALLBACK('e', "event", &event_set, "event",
>                      "event selector. Use 'perf c2c record -e list' to list available events",
> @@ -3256,7 +3264,13 @@ static int perf_c2c__record(int argc, const char **argv)
>         OPT_END()
>         };
>
> -       if (perf_mem_events__init()) {
> +       pmu = perf_mem_events_find_pmu();
> +       if (!pmu) {
> +               pr_err("failed: no PMU supports the memory events\n");
> +               return -1;
> +       }
> +
> +       if (perf_mem_events__init(pmu)) {
>                 pr_err("failed: memory events not supported\n");
>                 return -1;
>         }
> @@ -3280,7 +3294,7 @@ static int perf_c2c__record(int argc, const char **argv)
>         rec_argv[i++] = "record";
>
>         if (!event_set) {
> -               e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD_STORE);
> +               e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD_STORE);
>                 /*
>                  * The load and store operations are required, use the event
>                  * PERF_MEM_EVENTS__LOAD_STORE if it is supported.
> @@ -3289,15 +3303,15 @@ static int perf_c2c__record(int argc, const char **argv)
>                         e->record = true;
>                         rec_argv[i++] = "-W";
>                 } else {
> -                       e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
> +                       e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD);

Fwiw, it seems strange in cases like this that the function isn't:
perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD)

Thanks,
Ian

>                         e->record = true;
>
> -                       e = perf_mem_events__ptr(PERF_MEM_EVENTS__STORE);
> +                       e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__STORE);
>                         e->record = true;
>                 }
>         }
>
> -       e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
> +       e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD);
>         if (e->record)
>                 rec_argv[i++] = "-W";
>
> diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
> index 51499c20da01..8218c4721101 100644
> --- a/tools/perf/builtin-mem.c
> +++ b/tools/perf/builtin-mem.c
> @@ -43,12 +43,19 @@ static int parse_record_events(const struct option *opt,
>                                const char *str, int unset __maybe_unused)
>  {
>         struct perf_mem *mem = *(struct perf_mem **)opt->value;
> +       struct perf_pmu *pmu;
> +
> +       pmu = perf_mem_events_find_pmu();
> +       if (!pmu) {
> +               pr_err("failed: there is no PMU that supports perf mem\n");
> +               exit(-1);
> +       }
>
>         if (!strcmp(str, "list")) {
> -               perf_mem_events__list();
> +               perf_mem_events__list(pmu);
>                 exit(0);
>         }
> -       if (perf_mem_events__parse(str))
> +       if (perf_mem_events__parse(pmu, str))
>                 exit(-1);
>
>         mem->operation = 0;
> @@ -72,6 +79,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
>         int ret;
>         bool all_user = false, all_kernel = false;
>         struct perf_mem_event *e;
> +       struct perf_pmu *pmu;
>         struct option options[] = {
>         OPT_CALLBACK('e', "event", &mem, "event",
>                      "event selector. use 'perf mem record -e list' to list available events",
> @@ -84,7 +92,13 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
>         OPT_END()
>         };
>
> -       if (perf_mem_events__init()) {
> +       pmu = perf_mem_events_find_pmu();
> +       if (!pmu) {
> +               pr_err("failed: no PMU supports the memory events\n");
> +               return -1;
> +       }
> +
> +       if (perf_mem_events__init(pmu)) {
>                 pr_err("failed: memory events not supported\n");
>                 return -1;
>         }
> @@ -113,7 +127,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
>
>         rec_argv[i++] = "record";
>
> -       e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD_STORE);
> +       e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD_STORE);
>
>         /*
>          * The load and store operations are required, use the event
> @@ -126,17 +140,17 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
>                 rec_argv[i++] = "-W";
>         } else {
>                 if (mem->operation & MEM_OPERATION_LOAD) {
> -                       e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
> +                       e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD);
>                         e->record = true;
>                 }
>
>                 if (mem->operation & MEM_OPERATION_STORE) {
> -                       e = perf_mem_events__ptr(PERF_MEM_EVENTS__STORE);
> +                       e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__STORE);
>                         e->record = true;
>                 }
>         }
>
> -       e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
> +       e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD);
>         if (e->record)
>                 rec_argv[i++] = "-W";
>
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index 0a8f415f5efe..887ffdcce338 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -29,17 +29,42 @@ struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
>  static char mem_loads_name[100];
>  static bool mem_loads_name__init;
>
> -struct perf_mem_event * __weak perf_mem_events__ptr(int i)
> +struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i)
>  {
> -       if (i >= PERF_MEM_EVENTS__MAX)
> +       if (i >= PERF_MEM_EVENTS__MAX || !pmu)
>                 return NULL;
>
> -       return &perf_mem_events[i];
> +       return &pmu->mem_events[i];
> +}
> +
> +static struct perf_pmu *perf_pmus__scan_mem(struct perf_pmu *pmu)
> +{
> +       while ((pmu = perf_pmus__scan(pmu)) != NULL) {
> +               if (pmu->mem_events)
> +                       return pmu;
> +       }
> +       return NULL;
> +}
> +
> +struct perf_pmu *perf_mem_events_find_pmu(void)
> +{
> +       /*
> +        * The current perf mem doesn't support per-PMU configuration.
> +        * The exact same configuration is applied to all the
> +        * mem_events supported PMUs.
> +        * Return the first mem_events supported PMU.
> +        *
> +        * Notes: The only case which may support multiple mem_events
> +        * supported PMUs is Intel hybrid. The exact same mem_events
> +        * is shared among the PMUs. Only configure the first PMU
> +        * is good enough as well.
> +        */
> +       return perf_pmus__scan_mem(NULL);
>  }
>
>  const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
>  {
> -       struct perf_mem_event *e = perf_mem_events__ptr(i);
> +       struct perf_mem_event *e = &perf_mem_events[i];
>
>         if (!e)
>                 return NULL;
> @@ -61,7 +86,7 @@ __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
>         return false;
>  }
>
> -int perf_mem_events__parse(const char *str)
> +int perf_mem_events__parse(struct perf_pmu *pmu, const char *str)
>  {
>         char *tok, *saveptr = NULL;
>         bool found = false;
> @@ -79,7 +104,7 @@ int perf_mem_events__parse(const char *str)
>
>         while (tok) {
>                 for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
> -                       struct perf_mem_event *e = perf_mem_events__ptr(j);
> +                       struct perf_mem_event *e = perf_mem_events__ptr(pmu, j);
>
>                         if (!e->tag)
>                                 continue;
> @@ -112,7 +137,7 @@ static bool perf_mem_event__supported(const char *mnt, struct perf_pmu *pmu,
>         return !stat(path, &st);
>  }
>
> -int perf_mem_events__init(void)
> +int perf_mem_events__init(struct perf_pmu *pmu)
>  {
>         const char *mnt = sysfs__mount();
>         bool found = false;
> @@ -122,8 +147,7 @@ int perf_mem_events__init(void)
>                 return -ENOENT;
>
>         for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
> -               struct perf_mem_event *e = perf_mem_events__ptr(j);
> -               struct perf_pmu *pmu = NULL;
> +               struct perf_mem_event *e = perf_mem_events__ptr(pmu, j);
>
>                 /*
>                  * If the event entry isn't valid, skip initialization
> @@ -132,29 +156,20 @@ int perf_mem_events__init(void)
>                 if (!e->tag)
>                         continue;
>
> -               /*
> -                * Scan all PMUs not just core ones, since perf mem/c2c on
> -                * platforms like AMD uses IBS OP PMU which is independent
> -                * of core PMU.
> -                */
> -               while ((pmu = perf_pmus__scan(pmu)) != NULL) {
> -                       e->supported |= perf_mem_event__supported(mnt, pmu, e);
> -                       if (e->supported) {
> -                               found = true;
> -                               break;
> -                       }
> -               }
> +               e->supported |= perf_mem_event__supported(mnt, pmu, e);
> +               if (e->supported)
> +                       found = true;
>         }
>
>         return found ? 0 : -ENOENT;
>  }
>
> -void perf_mem_events__list(void)
> +void perf_mem_events__list(struct perf_pmu *pmu)
>  {
>         int j;
>
>         for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
> -               struct perf_mem_event *e = perf_mem_events__ptr(j);
> +               struct perf_mem_event *e = perf_mem_events__ptr(pmu, j);
>
>                 fprintf(stderr, "%-*s%-*s%s",
>                         e->tag ? 13 : 0,
> @@ -165,50 +180,32 @@ void perf_mem_events__list(void)
>         }
>  }
>
> -static void perf_mem_events__print_unsupport_hybrid(struct perf_mem_event *e,
> -                                                   int idx)
> -{
> -       const char *mnt = sysfs__mount();
> -       struct perf_pmu *pmu = NULL;
> -
> -       while ((pmu = perf_pmus__scan(pmu)) != NULL) {
> -               if (!perf_mem_event__supported(mnt, pmu, e)) {
> -                       pr_err("failed: event '%s' not supported\n",
> -                              perf_mem_events__name(idx, pmu->name));
> -               }
> -       }
> -}
> -
>  int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
>                                  char **rec_tmp, int *tmp_nr)
>  {
>         const char *mnt = sysfs__mount();
> +       struct perf_pmu *pmu = NULL;
>         int i = *argv_nr, k = 0;
>         struct perf_mem_event *e;
>
> -       for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
> -               e = perf_mem_events__ptr(j);
> -               if (!e->record)
> -                       continue;
>
> -               if (perf_pmus__num_mem_pmus() == 1) {
> -                       if (!e->supported) {
> -                               pr_err("failed: event '%s' not supported\n",
> -                                      perf_mem_events__name(j, NULL));
> -                               return -1;
> -                       }
> +       while ((pmu = perf_pmus__scan_mem(pmu)) != NULL) {
> +               for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
> +                       e = perf_mem_events__ptr(pmu, j);
>
> -                       rec_argv[i++] = "-e";
> -                       rec_argv[i++] = perf_mem_events__name(j, NULL);
> -               } else {
> -                       struct perf_pmu *pmu = NULL;
> +                       if (!e->record)
> +                               continue;
>
>                         if (!e->supported) {
> -                               perf_mem_events__print_unsupport_hybrid(e, j);
> +                               pr_err("failed: event '%s' not supported\n",
> +                                       perf_mem_events__name(j, pmu->name));
>                                 return -1;
>                         }
>
> -                       while ((pmu = perf_pmus__scan(pmu)) != NULL) {
> +                       if (perf_pmus__num_mem_pmus() == 1) {
> +                               rec_argv[i++] = "-e";
> +                               rec_argv[i++] = perf_mem_events__name(j, NULL);
> +                       } else {
>                                 const char *s = perf_mem_events__name(j, pmu->name);
>
>                                 if (!perf_mem_event__supported(mnt, pmu, e))
> diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
> index 8c5694b2d0b0..59a4303aac96 100644
> --- a/tools/perf/util/mem-events.h
> +++ b/tools/perf/util/mem-events.h
> @@ -36,14 +36,15 @@ enum {
>  extern unsigned int perf_mem_events__loads_ldlat;
>  extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
>
> -int perf_mem_events__parse(const char *str);
> -int perf_mem_events__init(void);
> +int perf_mem_events__parse(struct perf_pmu *pmu, const char *str);
> +int perf_mem_events__init(struct perf_pmu *pmu);
>
>  const char *perf_mem_events__name(int i, const char *pmu_name);
> -struct perf_mem_event *perf_mem_events__ptr(int i);
> +struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i);
> +struct perf_pmu *perf_mem_events_find_pmu(void);
>  bool is_mem_loads_aux_event(struct evsel *leader);
>
> -void perf_mem_events__list(void);
> +void perf_mem_events__list(struct perf_pmu *pmu);
>  int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
>                                  char **rec_tmp, int *tmp_nr);
>
> --
> 2.35.1
>


From irogers at google.com  Wed Dec  6 13:07:31 2023
From: irogers at google.com (Ian Rogers)
Date: Wed, 6 Dec 2023 13:07:31 -0800
Subject: [PATCH 3/6] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <20231206201324.184059-4-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com> <20231206201324.184059-4-kan.liang@linux.intel.com>
Message-ID: <CAP-5=fV7MNhTtO6ccPeQ40ZhEOFVmJVe1+cij9tqPeTqhHX_wQ@mail.gmail.com>

On Wed, Dec 6, 2023 at 12:13?PM <kan.liang at linux.intel.com> wrote:
>
> From: Kan Liang <kan.liang at linux.intel.com>
>
> Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
> one.
>
> The mem_load events may have a different format. Add ldlat and aux_event
> in the struct perf_mem_event to indicate the format and the extra aux
> event.
>
> Add perf_mem_events_intel_aux[] to support the extra mem_load_aux event.
>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
> ---
>  tools/perf/arch/arm64/util/mem-events.c   | 26 ++-------
>  tools/perf/arch/powerpc/util/mem-events.c | 13 ++---
>  tools/perf/arch/powerpc/util/mem-events.h |  7 +++
>  tools/perf/arch/powerpc/util/pmu.c        | 11 ++++
>  tools/perf/arch/x86/util/mem-events.c     | 70 +++++------------------
>  tools/perf/arch/x86/util/mem-events.h     |  1 +
>  tools/perf/arch/x86/util/pmu.c            |  8 ++-
>  tools/perf/util/mem-events.c              | 56 ++++++++++++------
>  tools/perf/util/mem-events.h              |  3 +-
>  9 files changed, 89 insertions(+), 106 deletions(-)
>  create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
>  create mode 100644 tools/perf/arch/powerpc/util/pmu.c
>
> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
> index 2602e8688727..eb2ef84f0fc8 100644
> --- a/tools/perf/arch/arm64/util/mem-events.c
> +++ b/tools/perf/arch/arm64/util/mem-events.c
> @@ -2,28 +2,10 @@
>  #include "map_symbol.h"
>  #include "mem-events.h"
>
> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
> -       E("spe-load",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",       "arm_spe_0"),
> -       E("spe-store",  "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                      "arm_spe_0"),
> -       E("spe-ldst",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",       "arm_spe_0"),
> +       E("spe-load",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",      "arm_spe_0",    true,   0),
> +       E("spe-store",  "%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                     "arm_spe_0",    false,  0),
> +       E("spe-ldst",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",      "arm_spe_0",    true,   0),
>  };
> -
> -static char mem_ev_name[100];
> -
> -const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
> -{
> -       struct perf_mem_event *e = &perf_mem_events_arm[i];
> -
> -       if (i >= PERF_MEM_EVENTS__MAX)
> -               return NULL;
> -
> -       if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE)
> -               scnprintf(mem_ev_name, sizeof(mem_ev_name),
> -                         e->name, perf_mem_events__loads_ldlat);
> -       else /* PERF_MEM_EVENTS__STORE */
> -               scnprintf(mem_ev_name, sizeof(mem_ev_name), e->name);
> -
> -       return mem_ev_name;
> -}
> diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
> index 78b986e5268d..b7883e38950f 100644
> --- a/tools/perf/arch/powerpc/util/mem-events.c
> +++ b/tools/perf/arch/powerpc/util/mem-events.c
> @@ -2,11 +2,10 @@
>  #include "map_symbol.h"
>  #include "mem-events.h"
>
> -/* PowerPC does not support 'ldlat' parameter. */
> -const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
> -{
> -       if (i == PERF_MEM_EVENTS__LOAD)
> -               return "cpu/mem-loads/";
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>
> -       return "cpu/mem-stores/";
> -}
> +struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
> +       E("ldlat-loads",        "%s/mem-loads/",        "cpu/events/mem-loads",         false,  0),
> +       E("ldlat-stores",       "%s/mem-stores/",       "cpu/events/mem-stores",        false,  0),
> +       E(NULL,                 NULL,                   NULL,                           false,  0),
> +};
> diff --git a/tools/perf/arch/powerpc/util/mem-events.h b/tools/perf/arch/powerpc/util/mem-events.h
> new file mode 100644
> index 000000000000..6acc3d1b6873
> --- /dev/null
> +++ b/tools/perf/arch/powerpc/util/mem-events.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _POWER_MEM_EVENTS_H
> +#define _POWER_MEM_EVENTS_H
> +
> +extern struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX];
> +
> +#endif /* _POWER_MEM_EVENTS_H */
> diff --git a/tools/perf/arch/powerpc/util/pmu.c b/tools/perf/arch/powerpc/util/pmu.c
> new file mode 100644
> index 000000000000..168173f88ddb
> --- /dev/null
> +++ b/tools/perf/arch/powerpc/util/pmu.c
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <string.h>
> +
> +#include "../../../util/pmu.h"
> +
> +void perf_pmu__arch_init(struct perf_pmu *pmu)
> +{
> +       if (pmu->is_core)
> +               pmu->mem_events = perf_mem_events_power;
> +}
> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index 5fb41d50118d..f0e66a0151a0 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -7,25 +7,26 @@
>  #include "linux/string.h"
>  #include "env.h"
>
> -static char mem_loads_name[100];
> -static bool mem_loads_name__init;
> -static char mem_stores_name[100];
> -
>  #define MEM_LOADS_AUX          0x8203
> -#define MEM_LOADS_AUX_NAME     "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P"
>
> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
> -       E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "%s/events/mem-loads"),
> -       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores"),
> -       E(NULL,                 NULL,                           NULL),
> +       E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "%s/events/mem-loads",  true,   0),
> +       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores", false,  0),
> +       E(NULL,                 NULL,                           NULL,                   false,  0),
> +};
> +
> +struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
> +       E("ldlat-loads",        "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P", "%s/events/mem-loads",  true,   MEM_LOADS_AUX),
> +       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores", false,  0),
> +       E(NULL,                 NULL,                           NULL,                   false,  0),
>  };
>
>  struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
> -       E(NULL,         NULL,           NULL),
> -       E(NULL,         NULL,           NULL),
> -       E("mem-ldst",   "ibs_op//",     "ibs_op"),
> +       E(NULL,         NULL,           NULL,           false,  0),
> +       E(NULL,         NULL,           NULL,           false,  0),
> +       E("mem-ldst",   "%s//",         "ibs_op",       false,  0),
>  };
>
>  bool is_mem_loads_aux_event(struct evsel *leader)
> @@ -40,48 +41,3 @@ bool is_mem_loads_aux_event(struct evsel *leader)
>
>         return leader->core.attr.config == MEM_LOADS_AUX;
>  }
> -
> -const char *perf_mem_events__name(int i, const char *pmu_name)
> -{
> -       struct perf_mem_event *e;
> -
> -       if (x86__is_amd_cpu())
> -               e = &perf_mem_events_amd[i];
> -       else
> -               e = &perf_mem_events_intel[i];
> -
> -       if (!e)
> -               return NULL;
> -
> -       if (i == PERF_MEM_EVENTS__LOAD) {
> -               if (mem_loads_name__init && !pmu_name)
> -                       return mem_loads_name;
> -
> -               if (!pmu_name) {
> -                       mem_loads_name__init = true;
> -                       pmu_name = "cpu";
> -               }
> -
> -               if (perf_pmus__have_event(pmu_name, "mem-loads-aux")) {
> -                       scnprintf(mem_loads_name, sizeof(mem_loads_name),
> -                                 MEM_LOADS_AUX_NAME, pmu_name, pmu_name,
> -                                 perf_mem_events__loads_ldlat);
> -               } else {
> -                       scnprintf(mem_loads_name, sizeof(mem_loads_name),
> -                                 e->name, pmu_name,
> -                                 perf_mem_events__loads_ldlat);
> -               }
> -               return mem_loads_name;
> -       }
> -
> -       if (i == PERF_MEM_EVENTS__STORE) {
> -               if (!pmu_name)
> -                       pmu_name = "cpu";
> -
> -               scnprintf(mem_stores_name, sizeof(mem_stores_name),
> -                         e->name, pmu_name);
> -               return mem_stores_name;
> -       }
> -
> -       return e->name;
> -}
> diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
> index 3959e427f482..f55c8d3b7d59 100644
> --- a/tools/perf/arch/x86/util/mem-events.h
> +++ b/tools/perf/arch/x86/util/mem-events.h
> @@ -3,6 +3,7 @@
>  #define _X86_MEM_EVENTS_H
>
>  extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
> +extern struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX];
>
>  extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
>
> diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
> index 7e69f4f2e363..446f8197aae4 100644
> --- a/tools/perf/arch/x86/util/pmu.c
> +++ b/tools/perf/arch/x86/util/pmu.c
> @@ -35,8 +35,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
>         if (x86__is_amd_cpu()) {
>                 if (strcmp(pmu->name, "ibs_op"))
>                         pmu->mem_events = perf_mem_events_amd;
> -       } else if (pmu->is_core)
> -               pmu->mem_events = perf_mem_events_intel;
> +       } else if (pmu->is_core) {
> +               if (perf_pmu__have_event(pmu, "mem-loads-aux"))
> +                       pmu->mem_events = perf_mem_events_intel_aux;
> +               else
> +                       pmu->mem_events = perf_mem_events_intel;
> +       }
>  }
>
>  int perf_pmus__num_mem_pmus(void)
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index 887ffdcce338..3a60cbcd6d8e 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -17,17 +17,17 @@
>
>  unsigned int perf_mem_events__loads_ldlat = 30;
>
> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
> -       E("ldlat-loads",        "cpu/mem-loads,ldlat=%u/P",     "cpu/events/mem-loads"),
> -       E("ldlat-stores",       "cpu/mem-stores/P",             "cpu/events/mem-stores"),
> -       E(NULL,                 NULL,                           NULL),
> +       E("ldlat-loads",        "%s/mem-loads/,ldlat=%u/P",     "cpu/events/mem-loads",         true,   0),

Is there a mistake here "/," looks like it should just be ",".

Thanks,
Ian

> +       E("ldlat-stores",       "%s/mem-stores/P",              "cpu/events/mem-stores",        false,  0),
> +       E(NULL,                 NULL,                           NULL,                           false,  0),
>  };
>  #undef E
>
>  static char mem_loads_name[100];
> -static bool mem_loads_name__init;
> +static char mem_stores_name[100];
>
>  struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i)
>  {
> @@ -62,23 +62,45 @@ struct perf_pmu *perf_mem_events_find_pmu(void)
>         return perf_pmus__scan_mem(NULL);
>  }
>
> -const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
> +static const char *perf_mem_events__name(int i, struct perf_pmu *pmu)
>  {
> -       struct perf_mem_event *e = &perf_mem_events[i];
> +       struct perf_mem_event *e = &pmu->mem_events[i];
>
>         if (!e)
>                 return NULL;
>
> -       if (i == PERF_MEM_EVENTS__LOAD) {
> -               if (!mem_loads_name__init) {
> -                       mem_loads_name__init = true;
> -                       scnprintf(mem_loads_name, sizeof(mem_loads_name),
> -                                 e->name, perf_mem_events__loads_ldlat);
> +       if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE) {
> +               if (e->ldlat) {
> +                       if (!e->aux_event) {
> +                               /* ARM and Most of Intel */
> +                               scnprintf(mem_loads_name, sizeof(mem_loads_name),
> +                                         e->name, pmu->name,
> +                                         perf_mem_events__loads_ldlat);
> +                       } else {
> +                               /* Intel with mem-loads-aux event */
> +                               scnprintf(mem_loads_name, sizeof(mem_loads_name),
> +                                         e->name, pmu->name, pmu->name,
> +                                         perf_mem_events__loads_ldlat);
> +                       }
> +               } else {
> +                       if (!e->aux_event) {
> +                               /* AMD and POWER */
> +                               scnprintf(mem_loads_name, sizeof(mem_loads_name),
> +                                         e->name, pmu->name);
> +                       } else
> +                               return NULL;
>                 }
> +
>                 return mem_loads_name;
>         }
>
> -       return e->name;
> +       if (i == PERF_MEM_EVENTS__STORE) {
> +               scnprintf(mem_stores_name, sizeof(mem_stores_name),
> +                         e->name, pmu->name);
> +               return mem_stores_name;
> +       }
> +
> +       return NULL;
>  }
>
>  __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
> @@ -175,7 +197,7 @@ void perf_mem_events__list(struct perf_pmu *pmu)
>                         e->tag ? 13 : 0,
>                         e->tag ? : "",
>                         e->tag && verbose > 0 ? 25 : 0,
> -                       e->tag && verbose > 0 ? perf_mem_events__name(j, NULL) : "",
> +                       e->tag && verbose > 0 ? perf_mem_events__name(j, pmu) : "",
>                         e->supported ? ": available\n" : "");
>         }
>  }
> @@ -198,15 +220,15 @@ int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
>
>                         if (!e->supported) {
>                                 pr_err("failed: event '%s' not supported\n",
> -                                       perf_mem_events__name(j, pmu->name));
> +                                       perf_mem_events__name(j, pmu));
>                                 return -1;
>                         }
>
>                         if (perf_pmus__num_mem_pmus() == 1) {
>                                 rec_argv[i++] = "-e";
> -                               rec_argv[i++] = perf_mem_events__name(j, NULL);
> +                               rec_argv[i++] = perf_mem_events__name(j, pmu);
>                         } else {
> -                               const char *s = perf_mem_events__name(j, pmu->name);
> +                               const char *s = perf_mem_events__name(j, pmu);
>
>                                 if (!perf_mem_event__supported(mnt, pmu, e))
>                                         continue;
> diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
> index 59a4303aac96..d257cf67d6d9 100644
> --- a/tools/perf/util/mem-events.h
> +++ b/tools/perf/util/mem-events.h
> @@ -14,6 +14,8 @@
>  struct perf_mem_event {
>         bool            record;
>         bool            supported;
> +       bool            ldlat;
> +       u32             aux_event;
>         const char      *tag;
>         const char      *name;
>         const char      *sysfs_name;
> @@ -39,7 +41,6 @@ extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
>  int perf_mem_events__parse(struct perf_pmu *pmu, const char *str);
>  int perf_mem_events__init(struct perf_pmu *pmu);
>
> -const char *perf_mem_events__name(int i, const char *pmu_name);
>  struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i);
>  struct perf_pmu *perf_mem_events_find_pmu(void);
>  bool is_mem_loads_aux_event(struct evsel *leader);
> --
> 2.35.1
>


From irogers at google.com  Wed Dec  6 13:08:34 2023
From: irogers at google.com (Ian Rogers)
Date: Wed, 6 Dec 2023 13:08:34 -0800
Subject: [PATCH 4/6] perf mem: Clean up perf_mem_event__supported()
In-Reply-To: <20231206201324.184059-5-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com> <20231206201324.184059-5-kan.liang@linux.intel.com>
Message-ID: <CAP-5=fUDiDWT3oEqS5NmVn-muhC+P=g5rW2aEyAgAQLS=UYxQw@mail.gmail.com>

On Wed, Dec 6, 2023 at 12:13?PM <kan.liang at linux.intel.com> wrote:
>
> From: Kan Liang <kan.liang at linux.intel.com>
>
> For some ARCHs, e.g., ARM and AMD, to get the availability of the
> mem-events, perf checks the existence of a specific PMU. For the other
> ARCHs, e.g., Intel and Power, perf has to check the existence of some
> specific events.
>
> The current perf only iterates the mem-events-supported PMUs. It's not
> required to check the existence of a specific PMU anymore.
>
> Rename sysfs_name to event_name, which stores the specific mem-events.
> Perf only needs to check those events for the availability of the
> mem-events.
>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>

Reviewed-by: Ian Rogers <irogers at google.com>

Thanks,
Ian

> ---
>  tools/perf/arch/arm64/util/mem-events.c   |  8 ++++----
>  tools/perf/arch/powerpc/util/mem-events.c |  8 ++++----
>  tools/perf/arch/x86/util/mem-events.c     | 20 ++++++++++----------
>  tools/perf/util/mem-events.c              | 16 +++++++++-------
>  tools/perf/util/mem-events.h              |  2 +-
>  5 files changed, 28 insertions(+), 26 deletions(-)
>
> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
> index eb2ef84f0fc8..590dddd6b0ab 100644
> --- a/tools/perf/arch/arm64/util/mem-events.c
> +++ b/tools/perf/arch/arm64/util/mem-events.c
> @@ -2,10 +2,10 @@
>  #include "map_symbol.h"
>  #include "mem-events.h"
>
> -#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
> -       E("spe-load",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",      "arm_spe_0",    true,   0),
> -       E("spe-store",  "%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                     "arm_spe_0",    false,  0),
> -       E("spe-ldst",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",      "arm_spe_0",    true,   0),
> +       E("spe-load",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",      NULL,   true,   0),
> +       E("spe-store",  "%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                     NULL,   false,  0),
> +       E("spe-ldst",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",      NULL,   true,   0),
>  };
> diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
> index b7883e38950f..72a6ac2b52f5 100644
> --- a/tools/perf/arch/powerpc/util/mem-events.c
> +++ b/tools/perf/arch/powerpc/util/mem-events.c
> @@ -2,10 +2,10 @@
>  #include "map_symbol.h"
>  #include "mem-events.h"
>
> -#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
> -       E("ldlat-loads",        "%s/mem-loads/",        "cpu/events/mem-loads",         false,  0),
> -       E("ldlat-stores",       "%s/mem-stores/",       "cpu/events/mem-stores",        false,  0),
> -       E(NULL,                 NULL,                   NULL,                           false,  0),
> +       E("ldlat-loads",        "%s/mem-loads/",        "mem-loads",    false,  0),
> +       E("ldlat-stores",       "%s/mem-stores/",       "mem-stores",   false,  0),
> +       E(NULL,                 NULL,                   NULL,           false,  0),
>  };
> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index f0e66a0151a0..b776d849fc64 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -9,24 +9,24 @@
>
>  #define MEM_LOADS_AUX          0x8203
>
> -#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
> -       E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "%s/events/mem-loads",  true,   0),
> -       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores", false,  0),
> -       E(NULL,                 NULL,                           NULL,                   false,  0),
> +       E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "mem-loads",    true,   0),
> +       E("ldlat-stores",       "%s/mem-stores/P",              "mem-stores",   false,  0),
> +       E(NULL,                 NULL,                           NULL,           false,  0),
>  };
>
>  struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
> -       E("ldlat-loads",        "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P", "%s/events/mem-loads",  true,   MEM_LOADS_AUX),
> -       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores", false,  0),
> -       E(NULL,                 NULL,                           NULL,                   false,  0),
> +       E("ldlat-loads",        "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P", "mem-loads",    true,   MEM_LOADS_AUX),
> +       E("ldlat-stores",       "%s/mem-stores/P",              "mem-stores",   false,  0),
> +       E(NULL,                 NULL,                           NULL,           false,  0),
>  };
>
>  struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
> -       E(NULL,         NULL,           NULL,           false,  0),
> -       E(NULL,         NULL,           NULL,           false,  0),
> -       E("mem-ldst",   "%s//",         "ibs_op",       false,  0),
> +       E(NULL,         NULL,           NULL,   false,  0),
> +       E(NULL,         NULL,           NULL,   false,  0),
> +       E("mem-ldst",   "%s//",         NULL,   false,  0),
>  };
>
>  bool is_mem_loads_aux_event(struct evsel *leader)
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index 3a60cbcd6d8e..9ea9e9a868c4 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -17,12 +17,12 @@
>
>  unsigned int perf_mem_events__loads_ldlat = 30;
>
> -#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
> -       E("ldlat-loads",        "%s/mem-loads/,ldlat=%u/P",     "cpu/events/mem-loads",         true,   0),
> -       E("ldlat-stores",       "%s/mem-stores/P",              "cpu/events/mem-stores",        false,  0),
> -       E(NULL,                 NULL,                           NULL,                           false,  0),
> +       E("ldlat-loads",        "%s/mem-loads/,ldlat=%u/P",     "mem-loads",    true,   0),
> +       E("ldlat-stores",       "%s/mem-stores/P",              "mem-stores",   false,  0),
> +       E(NULL,                 NULL,                           NULL,           false,  0),
>  };
>  #undef E
>
> @@ -150,12 +150,14 @@ int perf_mem_events__parse(struct perf_pmu *pmu, const char *str)
>  static bool perf_mem_event__supported(const char *mnt, struct perf_pmu *pmu,
>                                       struct perf_mem_event *e)
>  {
> -       char sysfs_name[100];
>         char path[PATH_MAX];
>         struct stat st;
>
> -       scnprintf(sysfs_name, sizeof(sysfs_name), e->sysfs_name, pmu->name);
> -       scnprintf(path, PATH_MAX, "%s/devices/%s", mnt, sysfs_name);
> +       if (!e->event_name)
> +               return true;
> +
> +       scnprintf(path, PATH_MAX, "%s/devices/%s/events/%s", mnt, pmu->name, e->event_name);
> +
>         return !stat(path, &st);
>  }
>
> diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
> index d257cf67d6d9..d2875d731da8 100644
> --- a/tools/perf/util/mem-events.h
> +++ b/tools/perf/util/mem-events.h
> @@ -18,7 +18,7 @@ struct perf_mem_event {
>         u32             aux_event;
>         const char      *tag;
>         const char      *name;
> -       const char      *sysfs_name;
> +       const char      *event_name;
>  };
>
>  struct mem_info {
> --
> 2.35.1
>


From irogers at google.com  Wed Dec  6 13:10:00 2023
From: irogers at google.com (Ian Rogers)
Date: Wed, 6 Dec 2023 13:10:00 -0800
Subject: [PATCH 5/6] perf mem: Clean up is_mem_loads_aux_event()
In-Reply-To: <20231206201324.184059-6-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com> <20231206201324.184059-6-kan.liang@linux.intel.com>
Message-ID: <CAP-5=fXtAKnvnubkqTUPdY9P98FqE5B9m3N+hRzRvPkvK3WS2w@mail.gmail.com>

On Wed, Dec 6, 2023 at 12:13?PM <kan.liang at linux.intel.com> wrote:
>
> From: Kan Liang <kan.liang at linux.intel.com>
>
> The aux_event can be retrieved from the perf_pmu now. Implement a
> generic support.
>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>

Reviewed-by: Ian Rogers <irogers at google.com>

Thanks,
Ian

> ---
>  tools/perf/arch/x86/util/mem-events.c | 13 -------------
>  tools/perf/util/mem-events.c          | 14 ++++++++++++--
>  2 files changed, 12 insertions(+), 15 deletions(-)
>
> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index b776d849fc64..71ffe16de751 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -28,16 +28,3 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
>         E(NULL,         NULL,           NULL,   false,  0),
>         E("mem-ldst",   "%s//",         NULL,   false,  0),
>  };
> -
> -bool is_mem_loads_aux_event(struct evsel *leader)
> -{
> -       struct perf_pmu *pmu = perf_pmus__find("cpu");
> -
> -       if (!pmu)
> -               pmu = perf_pmus__find("cpu_core");
> -
> -       if (pmu && !perf_pmu__have_event(pmu, "mem-loads-aux"))
> -               return false;
> -
> -       return leader->core.attr.config == MEM_LOADS_AUX;
> -}
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index 9ea9e9a868c4..336d1109b3a5 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -103,9 +103,19 @@ static const char *perf_mem_events__name(int i, struct perf_pmu *pmu)
>         return NULL;
>  }
>
> -__weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
> +bool is_mem_loads_aux_event(struct evsel *leader)
>  {
> -       return false;
> +       struct perf_pmu *pmu = leader->pmu;
> +       struct perf_mem_event *e;
> +
> +       if (!pmu || !pmu->mem_events)
> +               return false;
> +
> +       e = &pmu->mem_events[PERF_MEM_EVENTS__LOAD];
> +       if (!e->aux_event)
> +               return false;
> +
> +       return leader->core.attr.config == e->aux_event;
>  }
>
>  int perf_mem_events__parse(struct perf_pmu *pmu, const char *str)
> --
> 2.35.1
>


From thiago.bauermann at linaro.org  Wed Dec  6 13:27:25 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Wed, 06 Dec 2023 18:27:25 -0300
Subject: [PATCH v7 22/39] arm64/gcs: Implement shadow stack prctl()
 interface
In-Reply-To: <20231122-arm64-gcs-v7-22-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-22-201c483bd775@kernel.org>
Message-ID: <87edfzhvia.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

> Implement the architecture neutral prtctl() interface for setting the
> shadow stack status, this supports setting and reading the current GCS
> configuration for the current thread.
>
> Userspace can enable basic GCS functionality and additionally also
> support for GCS pushes and arbatrary GCS stores.  It is expected that

s/arbatrary/arbitrary/

> this prctl() will be called very early in application startup, for
> example by the dynamic linker, and not subsequently adjusted during
> normal operation.  Users should carefully note that after enabling GCS
> for a thread GCS will become active with no call stack so it is not
> normally possible to return from the function that invoked the prctl().

-- 
Thiago


From robh at kernel.org  Wed Dec  6 13:31:10 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 15:31:10 -0600
Subject: [RFC PATCH v2 2/6] of: reserved_mem: Swicth call to
 unflatten_device_tree() to after paging_init()
In-Reply-To: <20231204185409.19615-3-quic_obabatun@quicinc.com>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
 <20231204185409.19615-3-quic_obabatun@quicinc.com>
Message-ID: <20231206213110.GA3345785-robh@kernel.org>

On Mon, Dec 04, 2023 at 10:54:05AM -0800, Oreoluwa Babatunde wrote:
> Switch call to unflatten_device_tree() to after paging_init() on other
> archs to follow new order in which the reserved_mem regions are
> processed.

You did this so that you could allocate memory for the reserved regions. 
But unflatten_device_tree() can already do allocations using memblock. 
So the same thing should work for you.

I suspect that moving this will break any arch that called an of_* API 
between the original call and the new call location.

Rob


From wahrenst at gmx.net  Wed Dec  6 13:34:34 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Wed, 6 Dec 2023 22:34:34 +0100
Subject: [PATCH v3 1/4] staging: vc04_services: Drop vchiq_log_error() in
 favour of dev_err
In-Reply-To: <6a8566c0-bd26-4ec1-9f7d-d58bbed8411c@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-2-umang.jain@ideasonboard.com>
 <d6bf7115-dd15-43a0-b45a-41fc778ff160@gmx.net>
 <6a8566c0-bd26-4ec1-9f7d-d58bbed8411c@ideasonboard.com>
Message-ID: <3920385c-3c10-471a-ba82-8e48ba34f6a5@gmx.net>

Hi Umang,

Am 06.12.23 um 06:27 schrieb Umang Jain:
> Hi Stefan
>
> On 12/6/23 1:02 AM, Stefan Wahren wrote:
>> Hi Umang,
>>
>> Am 05.12.23 um 09:41 schrieb Umang Jain:
>>> Drop vchiq_log_error() macro which wraps dev_dbg(). Introduce the usage
>>> of dev_err() directly.
>> sorry, i missed to review the last change. So the change won't be that
>> trivial.
>
> All the changes you said are valid and I have taken a note of it.
>
> However, I think it would best that if we can address them in a
> separate series on top of this (and I will do it). It would seem to be
> streamlined on top of this.
i would address the comments as separate patches and then finally
convert the trivial rest with such a patch within one series. This
avoids unnecessary changes and reviewes. But that's just my opinion.

Best regards


From robh at kernel.org  Wed Dec  6 13:35:43 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 15:35:43 -0600
Subject: [RFC PATCH v2 0/6] Dynamic allocation of reserved_mem array.
In-Reply-To: <20231204185409.19615-1-quic_obabatun@quicinc.com>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
Message-ID: <20231206213543.GB3345785-robh@kernel.org>

On Mon, Dec 04, 2023 at 10:54:03AM -0800, Oreoluwa Babatunde wrote:
> The reserved_mem array is used to store the data of the different
> reserved memory regions specified in the DT of a device.
> The array stores information such as the name, node, starting address,
> and size of a reserved memory region.
> 
> The array is currently statically allocated with a size of
> MAX_RESERVED_REGIONS(64). This means that any system that specifies a
> number of reserved memory regions greater than MAX_RESERVED_REGIONS(64)
> will not have enough space to store the information for all the regions.
> 
> Therefore, this series extends the use of a static array for
> reserved_mem, and introduces a dynamically allocated array using
> memblock_alloc() based on the number of reserved memory regions
> specified in the DT.
> 
> Memory gotten from memblock_alloc() is only writable after paging_init()
> is called, but the reserved memory regions need to be reserved before
> then so that the system does not create page table mappings for them.
> 
> Reserved memory regions can be divided into 2 groups.
> i) Statically-placed reserved memory regions
> i.e. regions defined in the DT using the @reg property.
> ii) Dynamically-placed reserved memory regions.
> i.e. regions specified in the DT using the @alloc_ranges
>     and @size properties.
> 
> It is possible to call memblock_reserve() and memblock_mark_nomap() on
> the statically-placed reserved memory regions and not need to save them
> to the array until after paging_init(), but this is not possible for the
> dynamically-placed reserved memory because the starting address of these
> regions need to be stored somewhere after they are allocated.
> 
> Therefore, this series achieves the allocation and population of the
> reserved_mem array in two steps:
> 
> 1. Before paging_init()
>    Before paging_init() is called, iterate through the reserved_mem
>    nodes in the DT and do the following:
>    - Allocate memory for dynamically-placed reserved memory regions and
>      store their starting address in the static allocated reserved_mem
>      array.
>    - Call memblock_reserve() and memblock_mark_nomap() on all the
>      reserved memory regions as needed.
>    - Count the total number of reserved_mem nodes in the DT.
> 
> 2. After paging_init()
>    After paging_init() is called:
>    - Allocate new memory for the reserved_mem array based on the number
>      of reserved memory nodes in the DT.
>    - Transfer all the information that was stored in the static array
>      into the new array.
>    - Store the rest of the reserved_mem regions in the new array.
>      i.e. the statically-placed regions.
> 
> The static array is no longer needed after this point, but there is
> currently no obvious way to free the memory. Therefore, the size of the
> initial static array is now defined using a config option.

A config option is not going to work here.

> Because the array is used only before paging_init() to store the
> dynamically-placed reserved memory regions, the required size can vary
> from device to device. Therefore, scaling it can help get some memory
> savings.
> 
> A possible solution to freeing the memory for the static array will be
> to mark it as __initdata. This will automatically free the memory once
> the init process is done running.
> The reason why this is not pursued in this series is because of
> the possibility of a use-after-free.
> If the dynamic allocation of the reserved_mem array fails, then future
> accesses of the reserved_mem array will still be referencing the static
> array. When the init process ends and the memory is freed up, any
> further attempts to use the reserved_mem array will result in a
> use-after-free.

If memory allocation for the reserved_mem array fails so early in boot, 
you've got much bigger problems. Use __initdata, and just WARN if 
allocation fails and continue on (so hopefully the console is brought 
up and someone can see the WARN).

Rob


From thiago.bauermann at linaro.org  Wed Dec  6 13:44:04 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Wed, 06 Dec 2023 18:44:04 -0300
Subject: [PATCH v7 23/39] arm64/mm: Implement map_shadow_stack()
In-Reply-To: <20231122-arm64-gcs-v7-23-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-23-201c483bd775@kernel.org>
Message-ID: <87a5qnhuqj.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

> Since the x86 code has not yet been rebased to v6.5-rc1 this includes
> the architecture neutral parts of Rick Edgecmbe's "x86/shstk: Introduce
> map_shadow_stack syscall".

This paragraph can be dropped now.

-- 
Thiago


From hns at goldelico.com  Wed Dec  6 13:43:27 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Wed, 6 Dec 2023 22:43:27 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231206-wolverine-paprika-0674ca01e1f2@spud>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <CFF198DA-5C42-425E-86F4-759629489ECB@goldelico.com>
 <cb590a13-e0ff-49d9-8583-be613ad50dc5@ti.com>
 <FE0DBA5E-95A5-4C27-9F69-D1D8BDF56EC3@goldelico.com>
 <20231206-wolverine-paprika-0674ca01e1f2@spud>
Message-ID: <07CB504D-F4B7-425A-A24C-D0DC079ED48E@goldelico.com>



> Am 06.12.2023 um 17:02 schrieb Conor Dooley <conor at kernel.org>:
> 
> On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote:
>>> Am 05.12.2023 um 18:33 schrieb Andrew Davis <afd at ti.com>:
>>> 
>>> On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
>>>>> +          - enum:
>>>>> +              - ti,omap3430-gpu # Rev 121
>>>>> +              - ti,omap3630-gpu # Rev 125
>>>> Is the "Rev 121" and "Rev 125" a property of the SoC integration (clock/reset/power
>>>> hookup etc.) or of the integrated SGX core?
>>> 
>>> The Rev is a property of the SGX core, not the SoC integration.
>> 
>> Then, it should belong there and not be a comment of the ti,omap*-gpu record.
>> In this way it does not seem to be a proper hardware description.
>> 
>> BTW: there are examples where the revision is part of the compatible string, even
>> if the (Linux) driver makes no use of it:
>> 
>> drivers/net/ethernet/xilinx/xilinx_emaclite.c
> 
> AFAICT these Xilinx devices that put the revisions in the compatible are
> a different case - they're "soft" IP intended for use in the fabric of
> an FPGA, and assigning a device specific compatible there does not make
> sense.
> 
> In this case it appears that the revision is completely known once you
> see "ti,omap3630-gpu", so encoding the extra "121" into the compatible
> string is not required.

Well, I would not put my hand in the fire for this assumption.

And I am a friend of explicitly stating what is instead ot encoding indirectly.

> 
>> 
>>> But it seems that
>>> compatible string is being used to define both (as we see being debated in the other
>>> thread on this series).
>>> 
>>>> In my understanding the Revs are different variants of the SGX core (errata
>>>> fixes, instruction set, pipeline size etc.). And therefore the current driver code
>>>> has to be configured by some macros to handle such cases.
>>>> So the Rev should IMHO be part of the next line:
>>>>> +          - const: img,powervr-sgx530
>>>> +          - enum:
>>>> +              - img,powervr-sgx530-121
>>>> +              - img,powervr-sgx530-125
>>>> We have a similar definition in the openpvrsgx code.
>>>> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";
>>>> (I don't mind about the powervr- prefix).
>>>> This would allow a generic and universal sgx driver (loaded through just matching
>>>> "img,sgx530") to handle the errata and revision specifics at runtime based on the
>>>> compatible entry ("img,sgx530-121") and know about SoC integration ("ti,omap3-sgx530-121").
> 
> The "raw" sgx530 compatible does not seem helpful if the sgx530-121 or
> sgx530-125 compatibles are also required to be present for the driver to
> actually function.

Indeed. This seems to be redundant (but may need some pattern processing).

> The revision specific compatibles I would not object
> to, but everything in here has different revisions anyway - does the
> same revision actually appear in multiple devices? If it doesn't then I
> don't see any value in the suffixed compatibles either.

Well, we don't know.

So far only a subset of SoC with the SGX GPU core variants has been considered
(mainly because lack of user space code and device owners).

Maybe someone with insider knowledge can give a hint if the SGX version numbers
were assigned uniquely for each SoC integration project.

> 
>>>> And user-space can be made to load the right firmware variant based on "img,sgx530-121"
>>>> I don't know if there is some register which allows to discover the revision long
>>>> before the SGX subsystem is initialized and the firmware is up and running.
>>>> What I know is that it is possible to read out the revision after starting the firmware
>>>> but it may just echo the version number of the firmware binary provided from user-space.
>>> 
>>> We should be able to read out the revision (register EUR_CR_CORE_REVISION), the problem is
>>> today the driver is built for a given revision at compile time.
>> 
>> Yes, that is something we had planned to get rid of for a long time by using different compatible
>> strings and some variant specific struct like many others drivers are doing it.
>> But it was a to big task so nobody did start with it.
>> 
>>> That is a software issue,
>>> not something that we need to encode in DT. While the core ID (SGX5xx) can be also detected
>>> (EUR_CR_CORE_ID), the location of that register changes, and so it does need encoded in
>>> DT compatible.
>> 
>> Ok, I didn't know about such registers as there is not much public information available.
>> Fair enough, there are some error reports about in different forums.
>> 
>> On the other hand we then must read out this register in more or less early initialization
>> stages. Even if we know this information to be static and it could be as simple as a list
>> of compatible strings in the driver.
>> 
>>> The string "ti,omap3430-gpu" tells us the revision if we cannot detect it (as in the current
>>> driver), and the SoC integration is generic anyway (just a reg and interrupt).
>> 
>> It of course tells, but may need a translation table that needs to be maintained in a
>> different format. Basically the same what the comments show in a non-machine readable
>> format.
>> 
>> I just wonder why the specific version can or should not become simply part of the DTS
>> and needs this indirection.
>> 
>> Basically it is a matter of openness for future (driver) development and why it needs
>> careful decisions.
>> 
>> So in other words: I would prefer to see the comments about versions encoded in the device
>> tree binary to make it machine readable.
> 
> It's already machine readable if it is invariant on an SoC given the
> patch had SoC-specific compatibles.

But needs a translation table to get to the revision number.

I have not yet brought into discussion that there are different firmwares for sgx530-121,
sgx530-125, sgx544-116 etc. And user-space code may also depend on to be able to chose
the right one if multiple firmware packages are installed. Currently this is not the case
but would be a major benfit for OS packages.

To automate this we need a mechanism to scan the device tree for a compatible string that
tells which firmware variant to load.

But why force this to depend on the SoC compatible if it only depends indirectly?

By the way, there is a tested and working driver using the scheme with the sub-versions:

https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/11cc7876ba39b6172d19ee0bf0a872c1d3d745e1/drivers/gpu/drm/pvrsgx/pvr-drv.c#L306

On the other hand As far as I see this will can of course be adapted to the newly
proposed scheme.

But it still seems a bit twisted to me. Maybe because we for example define LCD panel
compatibles not by the compatible of the device they are installed in.

BR,
Nikolaus

From horms at kernel.org  Wed Dec  6 13:46:18 2023
From: horms at kernel.org (Simon Horman)
Date: Wed, 6 Dec 2023 21:46:18 +0000
Subject: [PATCH net-next 07/15] net: dsa: mt7530: do not run
 mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-8-arinc.unal@arinc9.com>
 <20231121185358.GA16629@kernel.org>
 <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
Message-ID: <20231206214618.GC50400@kernel.org>

+ Dan Carpenter <dan.carpenter at linaro.org>

On Sat, Dec 02, 2023 at 11:45:42AM +0300, Ar?n? ?NAL wrote:
> Hi Simon.
> 
> On 21.11.2023 21:53, Simon Horman wrote:
> > On Sat, Nov 18, 2023 at 03:31:57PM +0300, Ar?n? ?NAL wrote:
> > > There's no need to run all the code on mt7530_setup_port5() if port 5 is
> > > disabled. The only case for calling mt7530_setup_port5() from
> > > mt7530_setup() is when PHY muxing is enabled. That is because port 5 is not
> > > defined as a port on the devicetree, therefore, it cannot be controlled by
> > > phylink.
> > > 
> > > Because of this, run mt7530_setup_port5() if priv->p5_intf_sel is
> > > P5_INTF_SEL_PHY_P0 or P5_INTF_SEL_PHY_P4. Remove the P5_DISABLED case from
> > > mt7530_setup_port5().
> > > 
> > > Stop initialising the interface variable as the remaining cases will always
> > > call mt7530_setup_port5() with it initialised.
> > > 
> > > Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
> > > Reviewed-by: Vladimir Oltean <olteanv at gmail.com>
> > > ---
> > >   drivers/net/dsa/mt7530.c | 9 +++------
> > >   1 file changed, 3 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> > > index fc87ec817672..1aab4c3f28b0 100644
> > > --- a/drivers/net/dsa/mt7530.c
> > > +++ b/drivers/net/dsa/mt7530.c
> > > @@ -942,9 +942,6 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
> > >   		/* MT7530_P5_MODE_GMAC: P5 -> External phy or 2nd GMAC */
> > >   		val &= ~MHWTRAP_P5_DIS;
> > >   		break;
> > > -	case P5_DISABLED:
> > > -		interface = PHY_INTERFACE_MODE_NA;
> > > -		break;
> > >   	default:
> > >   		dev_err(ds->dev, "Unsupported p5_intf_sel %d\n",
> > >   			priv->p5_intf_sel);
> > > @@ -2313,8 +2310,6 @@ mt7530_setup(struct dsa_switch *ds)
> > >   		 * Set priv->p5_intf_sel to the appropriate value if PHY muxing
> > >   		 * is detected.
> > >   		 */
> > > -		interface = PHY_INTERFACE_MODE_NA;
> > > -
> > >   		for_each_child_of_node(dn, mac_np) {
> > >   			if (!of_device_is_compatible(mac_np,
> > >   						     "mediatek,eth-mac"))
> > > @@ -2346,7 +2341,9 @@ mt7530_setup(struct dsa_switch *ds)
> > >   			break;
> > >   		}
> > > -		mt7530_setup_port5(ds, interface);
> > > +		if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 ||
> > > +		    priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
> > > +			mt7530_setup_port5(ds, interface);
> > 
> > Hi Ar?n?,
> > 
> > It appears that interface is now uninitialised here.
> > 
> > Flagged by Smatch.
> 
> I'm not sure why it doesn't catch that for mt7530_setup_port5() to run
> here, priv->p5_intf_sel must be either P5_INTF_SEL_PHY_P0 or
> P5_INTF_SEL_PHY_P4. And for that to happen, the interface variable will be
> initialised.

Yes, I see your point now. At a guess, perhaps it because:

1. It doesn't know that of_get_phy_mode will set the value of interface
2. It doesn't know if the loop will run (more than zero times)

I CCed Dan Carpenter, who is surely more knowledgeable about this than I,
in case he wants to add anything.

> for_each_child_of_node(dn, mac_np) {
> 	if (!of_device_is_compatible(mac_np,
> 				     "mediatek,eth-mac"))
> 		continue;
> 
> 	ret = of_property_read_u32(mac_np, "reg", &id);
> 	if (ret < 0 || id != 1)
> 		continue;
> 
> 	phy_node = of_parse_phandle(mac_np, "phy-handle", 0);
> 	if (!phy_node)
> 		continue;
> 
> 	if (phy_node->parent == priv->dev->of_node->parent) {
> 		ret = of_get_phy_mode(mac_np, &interface);
> 		if (ret && ret != -ENODEV) {
> 			of_node_put(mac_np);
> 			of_node_put(phy_node);
> 			return ret;
> 		}
> 		id = of_mdio_parse_addr(ds->dev, phy_node);
> 		if (id == 0)
> 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P0;
> 		if (id == 4)
> 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P4;
> 	}
> 	of_node_put(mac_np);
> 	of_node_put(phy_node);
> 	break;
> }
> 
> if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 ||
>     priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
> 	mt7530_setup_port5(ds, interface);
> 
> Ar?n?


From u.kleine-koenig at pengutronix.de  Wed Dec  6 13:48:18 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed,  6 Dec 2023 22:48:18 +0100
Subject: [PATCH] pwm: meson: Simplify using dev_err_probe()
Message-ID: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>

Using dev_err_probe() emitting an error message mentioning a return
value and returning that value can be done in a single statement. Make
use of that to simplify the probe part of the driver. This has the
additional advantage to emit the symbolic name for the error instead of
the integer error value.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
Hello,

while trying to understand Jerome's series[1] I noticed this patch
opportunity.

Best regards
Uwe

[1] https://lore.kernel.org/linux-pwm/20231129134004.3642121-1-jbrunet at baylibre.com

 drivers/pwm/pwm-meson.c | 35 ++++++++++++++---------------------
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index 5bea53243ed2..2971bbf3b5e7 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -468,10 +468,9 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
 		channel->mux.hw.init = &init;
 
 		err = devm_clk_hw_register(dev, &channel->mux.hw);
-		if (err) {
-			dev_err(dev, "failed to register %s: %d\n", name, err);
-			return err;
-		}
+		if (err)
+			return dev_err_probe(dev, err,
+					     "failed to register %s\n", name);
 
 		snprintf(name, sizeof(name), "%s#div%u", dev_name(dev), i);
 
@@ -491,10 +490,9 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
 		channel->div.lock = &meson->lock;
 
 		err = devm_clk_hw_register(dev, &channel->div.hw);
-		if (err) {
-			dev_err(dev, "failed to register %s: %d\n", name, err);
-			return err;
-		}
+		if (err)
+			return dev_err_probe(dev, err,
+					     "failed to register %s\n", name);
 
 		snprintf(name, sizeof(name), "%s#gate%u", dev_name(dev), i);
 
@@ -513,17 +511,13 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
 		channel->gate.lock = &meson->lock;
 
 		err = devm_clk_hw_register(dev, &channel->gate.hw);
-		if (err) {
-			dev_err(dev, "failed to register %s: %d\n", name, err);
-			return err;
-		}
+		if (err)
+			return dev_err_probe(dev, err, "failed to register %s\n", name);
 
 		channel->clk = devm_clk_hw_get_clk(dev, &channel->gate.hw, NULL);
-		if (IS_ERR(channel->clk)) {
-			err = PTR_ERR(channel->clk);
-			dev_err(dev, "failed to register %s: %d\n", name, err);
-			return err;
-		}
+		if (IS_ERR(channel->clk))
+			return dev_err_probe(dev, PTR_ERR(channel->clk),
+					     "failed to register %s\n", name);
 	}
 
 	return 0;
@@ -554,10 +548,9 @@ static int meson_pwm_probe(struct platform_device *pdev)
 		return err;
 
 	err = devm_pwmchip_add(&pdev->dev, &meson->chip);
-	if (err < 0) {
-		dev_err(&pdev->dev, "failed to register PWM chip: %d\n", err);
-		return err;
-	}
+	if (err < 0)
+		return dev_err_probe(&pdev->dev, err,
+				     "failed to register PWM chip\n");
 
 	return 0;
 }
-- 
2.42.0



From kan.liang at linux.intel.com  Wed Dec  6 13:52:41 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Wed, 6 Dec 2023 16:52:41 -0500
Subject: [PATCH 3/6] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <CAP-5=fV7MNhTtO6ccPeQ40ZhEOFVmJVe1+cij9tqPeTqhHX_wQ@mail.gmail.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
 <20231206201324.184059-4-kan.liang@linux.intel.com>
 <CAP-5=fV7MNhTtO6ccPeQ40ZhEOFVmJVe1+cij9tqPeTqhHX_wQ@mail.gmail.com>
Message-ID: <fd94aa97-c18c-43a3-bb86-2f4cd93cae30@linux.intel.com>



On 2023-12-06 4:07 p.m., Ian Rogers wrote:
> On Wed, Dec 6, 2023 at 12:13?PM <kan.liang at linux.intel.com> wrote:
>>
>> From: Kan Liang <kan.liang at linux.intel.com>
>>
>> Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
>> one.
>>
>> The mem_load events may have a different format. Add ldlat and aux_event
>> in the struct perf_mem_event to indicate the format and the extra aux
>> event.
>>
>> Add perf_mem_events_intel_aux[] to support the extra mem_load_aux event.
>>
>> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
>> ---
>>  tools/perf/arch/arm64/util/mem-events.c   | 26 ++-------
>>  tools/perf/arch/powerpc/util/mem-events.c | 13 ++---
>>  tools/perf/arch/powerpc/util/mem-events.h |  7 +++
>>  tools/perf/arch/powerpc/util/pmu.c        | 11 ++++
>>  tools/perf/arch/x86/util/mem-events.c     | 70 +++++------------------
>>  tools/perf/arch/x86/util/mem-events.h     |  1 +
>>  tools/perf/arch/x86/util/pmu.c            |  8 ++-
>>  tools/perf/util/mem-events.c              | 56 ++++++++++++------
>>  tools/perf/util/mem-events.h              |  3 +-
>>  9 files changed, 89 insertions(+), 106 deletions(-)
>>  create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
>>  create mode 100644 tools/perf/arch/powerpc/util/pmu.c
>>
>> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
>> index 2602e8688727..eb2ef84f0fc8 100644
>> --- a/tools/perf/arch/arm64/util/mem-events.c
>> +++ b/tools/perf/arch/arm64/util/mem-events.c
>> @@ -2,28 +2,10 @@
>>  #include "map_symbol.h"
>>  #include "mem-events.h"
>>
>> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>>
>>  struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
>> -       E("spe-load",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",       "arm_spe_0"),
>> -       E("spe-store",  "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                      "arm_spe_0"),
>> -       E("spe-ldst",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",       "arm_spe_0"),
>> +       E("spe-load",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",      "arm_spe_0",    true,   0),
>> +       E("spe-store",  "%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                     "arm_spe_0",    false,  0),
>> +       E("spe-ldst",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",      "arm_spe_0",    true,   0),
>>  };
>> -
>> -static char mem_ev_name[100];
>> -
>> -const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
>> -{
>> -       struct perf_mem_event *e = &perf_mem_events_arm[i];
>> -
>> -       if (i >= PERF_MEM_EVENTS__MAX)
>> -               return NULL;
>> -
>> -       if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE)
>> -               scnprintf(mem_ev_name, sizeof(mem_ev_name),
>> -                         e->name, perf_mem_events__loads_ldlat);
>> -       else /* PERF_MEM_EVENTS__STORE */
>> -               scnprintf(mem_ev_name, sizeof(mem_ev_name), e->name);
>> -
>> -       return mem_ev_name;
>> -}
>> diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
>> index 78b986e5268d..b7883e38950f 100644
>> --- a/tools/perf/arch/powerpc/util/mem-events.c
>> +++ b/tools/perf/arch/powerpc/util/mem-events.c
>> @@ -2,11 +2,10 @@
>>  #include "map_symbol.h"
>>  #include "mem-events.h"
>>
>> -/* PowerPC does not support 'ldlat' parameter. */
>> -const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
>> -{
>> -       if (i == PERF_MEM_EVENTS__LOAD)
>> -               return "cpu/mem-loads/";
>> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>>
>> -       return "cpu/mem-stores/";
>> -}
>> +struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
>> +       E("ldlat-loads",        "%s/mem-loads/",        "cpu/events/mem-loads",         false,  0),
>> +       E("ldlat-stores",       "%s/mem-stores/",       "cpu/events/mem-stores",        false,  0),
>> +       E(NULL,                 NULL,                   NULL,                           false,  0),
>> +};
>> diff --git a/tools/perf/arch/powerpc/util/mem-events.h b/tools/perf/arch/powerpc/util/mem-events.h
>> new file mode 100644
>> index 000000000000..6acc3d1b6873
>> --- /dev/null
>> +++ b/tools/perf/arch/powerpc/util/mem-events.h
>> @@ -0,0 +1,7 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _POWER_MEM_EVENTS_H
>> +#define _POWER_MEM_EVENTS_H
>> +
>> +extern struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX];
>> +
>> +#endif /* _POWER_MEM_EVENTS_H */
>> diff --git a/tools/perf/arch/powerpc/util/pmu.c b/tools/perf/arch/powerpc/util/pmu.c
>> new file mode 100644
>> index 000000000000..168173f88ddb
>> --- /dev/null
>> +++ b/tools/perf/arch/powerpc/util/pmu.c
>> @@ -0,0 +1,11 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include <string.h>
>> +
>> +#include "../../../util/pmu.h"
>> +
>> +void perf_pmu__arch_init(struct perf_pmu *pmu)
>> +{
>> +       if (pmu->is_core)
>> +               pmu->mem_events = perf_mem_events_power;
>> +}
>> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
>> index 5fb41d50118d..f0e66a0151a0 100644
>> --- a/tools/perf/arch/x86/util/mem-events.c
>> +++ b/tools/perf/arch/x86/util/mem-events.c
>> @@ -7,25 +7,26 @@
>>  #include "linux/string.h"
>>  #include "env.h"
>>
>> -static char mem_loads_name[100];
>> -static bool mem_loads_name__init;
>> -static char mem_stores_name[100];
>> -
>>  #define MEM_LOADS_AUX          0x8203
>> -#define MEM_LOADS_AUX_NAME     "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P"
>>
>> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>>
>>  struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
>> -       E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "%s/events/mem-loads"),
>> -       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores"),
>> -       E(NULL,                 NULL,                           NULL),
>> +       E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "%s/events/mem-loads",  true,   0),
>> +       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores", false,  0),
>> +       E(NULL,                 NULL,                           NULL,                   false,  0),
>> +};
>> +
>> +struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
>> +       E("ldlat-loads",        "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P", "%s/events/mem-loads",  true,   MEM_LOADS_AUX),
>> +       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores", false,  0),
>> +       E(NULL,                 NULL,                           NULL,                   false,  0),
>>  };
>>
>>  struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
>> -       E(NULL,         NULL,           NULL),
>> -       E(NULL,         NULL,           NULL),
>> -       E("mem-ldst",   "ibs_op//",     "ibs_op"),
>> +       E(NULL,         NULL,           NULL,           false,  0),
>> +       E(NULL,         NULL,           NULL,           false,  0),
>> +       E("mem-ldst",   "%s//",         "ibs_op",       false,  0),
>>  };
>>
>>  bool is_mem_loads_aux_event(struct evsel *leader)
>> @@ -40,48 +41,3 @@ bool is_mem_loads_aux_event(struct evsel *leader)
>>
>>         return leader->core.attr.config == MEM_LOADS_AUX;
>>  }
>> -
>> -const char *perf_mem_events__name(int i, const char *pmu_name)
>> -{
>> -       struct perf_mem_event *e;
>> -
>> -       if (x86__is_amd_cpu())
>> -               e = &perf_mem_events_amd[i];
>> -       else
>> -               e = &perf_mem_events_intel[i];
>> -
>> -       if (!e)
>> -               return NULL;
>> -
>> -       if (i == PERF_MEM_EVENTS__LOAD) {
>> -               if (mem_loads_name__init && !pmu_name)
>> -                       return mem_loads_name;
>> -
>> -               if (!pmu_name) {
>> -                       mem_loads_name__init = true;
>> -                       pmu_name = "cpu";
>> -               }
>> -
>> -               if (perf_pmus__have_event(pmu_name, "mem-loads-aux")) {
>> -                       scnprintf(mem_loads_name, sizeof(mem_loads_name),
>> -                                 MEM_LOADS_AUX_NAME, pmu_name, pmu_name,
>> -                                 perf_mem_events__loads_ldlat);
>> -               } else {
>> -                       scnprintf(mem_loads_name, sizeof(mem_loads_name),
>> -                                 e->name, pmu_name,
>> -                                 perf_mem_events__loads_ldlat);
>> -               }
>> -               return mem_loads_name;
>> -       }
>> -
>> -       if (i == PERF_MEM_EVENTS__STORE) {
>> -               if (!pmu_name)
>> -                       pmu_name = "cpu";
>> -
>> -               scnprintf(mem_stores_name, sizeof(mem_stores_name),
>> -                         e->name, pmu_name);
>> -               return mem_stores_name;
>> -       }
>> -
>> -       return e->name;
>> -}
>> diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
>> index 3959e427f482..f55c8d3b7d59 100644
>> --- a/tools/perf/arch/x86/util/mem-events.h
>> +++ b/tools/perf/arch/x86/util/mem-events.h
>> @@ -3,6 +3,7 @@
>>  #define _X86_MEM_EVENTS_H
>>
>>  extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
>> +extern struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX];
>>
>>  extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
>>
>> diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
>> index 7e69f4f2e363..446f8197aae4 100644
>> --- a/tools/perf/arch/x86/util/pmu.c
>> +++ b/tools/perf/arch/x86/util/pmu.c
>> @@ -35,8 +35,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
>>         if (x86__is_amd_cpu()) {
>>                 if (strcmp(pmu->name, "ibs_op"))
>>                         pmu->mem_events = perf_mem_events_amd;
>> -       } else if (pmu->is_core)
>> -               pmu->mem_events = perf_mem_events_intel;
>> +       } else if (pmu->is_core) {
>> +               if (perf_pmu__have_event(pmu, "mem-loads-aux"))
>> +                       pmu->mem_events = perf_mem_events_intel_aux;
>> +               else
>> +                       pmu->mem_events = perf_mem_events_intel;
>> +       }
>>  }
>>
>>  int perf_pmus__num_mem_pmus(void)
>> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
>> index 887ffdcce338..3a60cbcd6d8e 100644
>> --- a/tools/perf/util/mem-events.c
>> +++ b/tools/perf/util/mem-events.c
>> @@ -17,17 +17,17 @@
>>
>>  unsigned int perf_mem_events__loads_ldlat = 30;
>>
>> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>>
>>  struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
>> -       E("ldlat-loads",        "cpu/mem-loads,ldlat=%u/P",     "cpu/events/mem-loads"),
>> -       E("ldlat-stores",       "cpu/mem-stores/P",             "cpu/events/mem-stores"),
>> -       E(NULL,                 NULL,                           NULL),
>> +       E("ldlat-loads",        "%s/mem-loads/,ldlat=%u/P",     "cpu/events/mem-loads",         true,   0),
> 
> Is there a mistake here "/," looks like it should just be ",".

Right, a typo. I will fix it in V2.

Thanks,
Kan
> 
> Thanks,
> Ian
> 
>> +       E("ldlat-stores",       "%s/mem-stores/P",              "cpu/events/mem-stores",        false,  0),
>> +       E(NULL,                 NULL,                           NULL,                           false,  0),
>>  };
>>  #undef E
>>
>>  static char mem_loads_name[100];
>> -static bool mem_loads_name__init;
>> +static char mem_stores_name[100];
>>
>>  struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i)
>>  {
>> @@ -62,23 +62,45 @@ struct perf_pmu *perf_mem_events_find_pmu(void)
>>         return perf_pmus__scan_mem(NULL);
>>  }
>>
>> -const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
>> +static const char *perf_mem_events__name(int i, struct perf_pmu *pmu)
>>  {
>> -       struct perf_mem_event *e = &perf_mem_events[i];
>> +       struct perf_mem_event *e = &pmu->mem_events[i];
>>
>>         if (!e)
>>                 return NULL;
>>
>> -       if (i == PERF_MEM_EVENTS__LOAD) {
>> -               if (!mem_loads_name__init) {
>> -                       mem_loads_name__init = true;
>> -                       scnprintf(mem_loads_name, sizeof(mem_loads_name),
>> -                                 e->name, perf_mem_events__loads_ldlat);
>> +       if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE) {
>> +               if (e->ldlat) {
>> +                       if (!e->aux_event) {
>> +                               /* ARM and Most of Intel */
>> +                               scnprintf(mem_loads_name, sizeof(mem_loads_name),
>> +                                         e->name, pmu->name,
>> +                                         perf_mem_events__loads_ldlat);
>> +                       } else {
>> +                               /* Intel with mem-loads-aux event */
>> +                               scnprintf(mem_loads_name, sizeof(mem_loads_name),
>> +                                         e->name, pmu->name, pmu->name,
>> +                                         perf_mem_events__loads_ldlat);
>> +                       }
>> +               } else {
>> +                       if (!e->aux_event) {
>> +                               /* AMD and POWER */
>> +                               scnprintf(mem_loads_name, sizeof(mem_loads_name),
>> +                                         e->name, pmu->name);
>> +                       } else
>> +                               return NULL;
>>                 }
>> +
>>                 return mem_loads_name;
>>         }
>>
>> -       return e->name;
>> +       if (i == PERF_MEM_EVENTS__STORE) {
>> +               scnprintf(mem_stores_name, sizeof(mem_stores_name),
>> +                         e->name, pmu->name);
>> +               return mem_stores_name;
>> +       }
>> +
>> +       return NULL;
>>  }
>>
>>  __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
>> @@ -175,7 +197,7 @@ void perf_mem_events__list(struct perf_pmu *pmu)
>>                         e->tag ? 13 : 0,
>>                         e->tag ? : "",
>>                         e->tag && verbose > 0 ? 25 : 0,
>> -                       e->tag && verbose > 0 ? perf_mem_events__name(j, NULL) : "",
>> +                       e->tag && verbose > 0 ? perf_mem_events__name(j, pmu) : "",
>>                         e->supported ? ": available\n" : "");
>>         }
>>  }
>> @@ -198,15 +220,15 @@ int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
>>
>>                         if (!e->supported) {
>>                                 pr_err("failed: event '%s' not supported\n",
>> -                                       perf_mem_events__name(j, pmu->name));
>> +                                       perf_mem_events__name(j, pmu));
>>                                 return -1;
>>                         }
>>
>>                         if (perf_pmus__num_mem_pmus() == 1) {
>>                                 rec_argv[i++] = "-e";
>> -                               rec_argv[i++] = perf_mem_events__name(j, NULL);
>> +                               rec_argv[i++] = perf_mem_events__name(j, pmu);
>>                         } else {
>> -                               const char *s = perf_mem_events__name(j, pmu->name);
>> +                               const char *s = perf_mem_events__name(j, pmu);
>>
>>                                 if (!perf_mem_event__supported(mnt, pmu, e))
>>                                         continue;
>> diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
>> index 59a4303aac96..d257cf67d6d9 100644
>> --- a/tools/perf/util/mem-events.h
>> +++ b/tools/perf/util/mem-events.h
>> @@ -14,6 +14,8 @@
>>  struct perf_mem_event {
>>         bool            record;
>>         bool            supported;
>> +       bool            ldlat;
>> +       u32             aux_event;
>>         const char      *tag;
>>         const char      *name;
>>         const char      *sysfs_name;
>> @@ -39,7 +41,6 @@ extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
>>  int perf_mem_events__parse(struct perf_pmu *pmu, const char *str);
>>  int perf_mem_events__init(struct perf_pmu *pmu);
>>
>> -const char *perf_mem_events__name(int i, const char *pmu_name);
>>  struct perf_mem_event *perf_mem_events__ptr(struct perf_pmu *pmu, int i);
>>  struct perf_pmu *perf_mem_events_find_pmu(void);
>>  bool is_mem_loads_aux_event(struct evsel *leader);
>> --
>> 2.35.1
>>


From kan.liang at linux.intel.com  Wed Dec  6 13:53:44 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Wed, 6 Dec 2023 16:53:44 -0500
Subject: [PATCH 6/6] perf mem: Remove useless header files for X86
In-Reply-To: <ZXDb2Gs1ECjejSbn@kernel.org>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
 <20231206201324.184059-7-kan.liang@linux.intel.com>
 <ZXDb2Gs1ECjejSbn@kernel.org>
Message-ID: <3e7450c1-a54f-41db-9dff-5e505297b30a@linux.intel.com>



On 2023-12-06 3:38 p.m., Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 06, 2023 at 12:13:24PM -0800, kan.liang at linux.intel.com escreveu:
>> From: Kan Liang <kan.liang at linux.intel.com>
>>
>> The X86 mem-events.c only has perf_mem_events array now. Remove useless
>> header files.
> 
> It would be great that those were removed while you made the cleanups,
> i.e. removed the need for one of them, remove it together with the
> refactorings, etc.
> 
> But I don't think this is a requirement, just would make it cleaner.

Sure, I will merge it with the previous patch in V2.

Thanks,
Kan
> 
> Will wait for reviews now.
> 
> - Arnaldo
>  
>> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
>> ---
>>  tools/perf/arch/x86/util/mem-events.c | 10 ++++------
>>  1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
>> index 71ffe16de751..62df03e91c7e 100644
>> --- a/tools/perf/arch/x86/util/mem-events.c
>> +++ b/tools/perf/arch/x86/util/mem-events.c
>> @@ -1,11 +1,9 @@
>>  // SPDX-License-Identifier: GPL-2.0
>> -#include "util/pmu.h"
>> -#include "util/pmus.h"
>> -#include "util/env.h"
>> -#include "map_symbol.h"
>> -#include "mem-events.h"
>>  #include "linux/string.h"
>> -#include "env.h"
>> +#include "util/map_symbol.h"
>> +#include "util/mem-events.h"
>> +#include "mem-events.h"
>> +
>>  
>>  #define MEM_LOADS_AUX		0x8203
>>  
>> -- 
>> 2.35.1
>>
> 


From robh at kernel.org  Wed Dec  6 14:00:40 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 16:00:40 -0600
Subject: [PATCH 1/6] dt-bindings: i2c: exynos5: add specific compatible
 for Tesla FSD
In-Reply-To: <20231205092229.19135-2-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
 <20231205092229.19135-2-krzysztof.kozlowski@linaro.org>
Message-ID: <170190003691.3402358.13173057171065129546.robh@kernel.org>


On Tue, 05 Dec 2023 10:22:24 +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs.  Historically we
> kept the old (block's) compatible only.  This works fine and there is no
> bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add Tesla FSD compatible specific to be used with an existing fallback.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>



From hns at goldelico.com  Wed Dec  6 14:02:26 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Wed, 6 Dec 2023 23:02:26 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <8328bec9-a963-4f8a-ae03-a531749a30db@ti.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <CFF198DA-5C42-425E-86F4-759629489ECB@goldelico.com>
 <cb590a13-e0ff-49d9-8583-be613ad50dc5@ti.com>
 <FE0DBA5E-95A5-4C27-9F69-D1D8BDF56EC3@goldelico.com>
 <20231206-wolverine-paprika-0674ca01e1f2@spud>
 <8328bec9-a963-4f8a-ae03-a531749a30db@ti.com>
Message-ID: <65992757-0A28-48AE-89D1-212E115265B8@goldelico.com>

(non-html)

> Am 06.12.2023 um 17:15 schrieb Andrew Davis <afd at ti.com>:
> 
> On 12/6/23 10:02 AM, Conor Dooley wrote:
>> On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote:
>>>> Am 05.12.2023 um 18:33 schrieb Andrew Davis <afd at ti.com>:
>>>> 
>>>> On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
>>>>>> +          - enum:
>>>>>> +              - ti,omap3430-gpu # Rev 121
>>>>>> +              - ti,omap3630-gpu # Rev 125
>>>>> Is the "Rev 121" and "Rev 125" a property of the SoC integration (clock/reset/power
>>>>> hookup etc.) or of the integrated SGX core?
>>>> 
>>>> The Rev is a property of the SGX core, not the SoC integration.
>>> 
>>> Then, it should belong there and not be a comment of the ti,omap*-gpu record.
>>> In this way it does not seem to be a proper hardware description.
>>> 
>>> BTW: there are examples where the revision is part of the compatible string, even
>>> if the (Linux) driver makes no use of it:
>>> 
>>> drivers/net/ethernet/xilinx/xilinx_emaclite.c
>> AFAICT these Xilinx devices that put the revisions in the compatible are
>> a different case - they're "soft" IP intended for use in the fabric of
>> an FPGA, and assigning a device specific compatible there does not make
>> sense.
>> In this case it appears that the revision is completely known once you
>> see "ti,omap3630-gpu", so encoding the extra "121" into the compatible
>> string is not required.
>>> 
>>>> But it seems that
>>>> compatible string is being used to define both (as we see being debated in the other
>>>> thread on this series).
>>>> 
>>>>> In my understanding the Revs are different variants of the SGX core (errata
>>>>> fixes, instruction set, pipeline size etc.). And therefore the current driver code
>>>>> has to be configured by some macros to handle such cases.
>>>>> So the Rev should IMHO be part of the next line:
>>>>>> +          - const: img,powervr-sgx530
>>>>> +          - enum:
>>>>> +              - img,powervr-sgx530-121
>>>>> +              - img,powervr-sgx530-125
>>>>> We have a similar definition in the openpvrsgx code.
>>>>> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";
>>>>> (I don't mind about the powervr- prefix).
>>>>> This would allow a generic and universal sgx driver (loaded through just matching
>>>>> "img,sgx530") to handle the errata and revision specifics at runtime based on the
>>>>> compatible entry ("img,sgx530-121") and know about SoC integration ("ti,omap3-sgx530-121").
>> The "raw" sgx530 compatible does not seem helpful if the sgx530-121 or
>> sgx530-125 compatibles are also required to be present for the driver to
>> actually function. The revision specific compatibles I would not object
>> to, but everything in here has different revisions anyway - does the
>> same revision actually appear in multiple devices? If it doesn't then I
>> don't see any value in the suffixed compatibles either.
> 
> Everything here has different revisions because any device that uses
> the same revision can also use the same base compatible string. For
> instance AM335x SoCs use the SGX530 revision 125, same as OMAP3630,
> so I simply reuse that compatible in their DT as you can see in
> patch [5/10]. I didn't see the need for a new compatible string
> for identical (i.e. "compatible") IP and integration.

Ok, this is a point. As long as there is no SoC which can come with different
SGX revisions the SoC compatible is enough for everything.

I never looked it that way.

> 
> The first device to use that IP/revision combo gets the named
> compatible, all others re-use the same compatible where possible.

Hm. If we take this rule, we can even completely leave out all

+          - const: img,powervr-sgx530
+          - const: img,powervr-sgx540
+          - const: img,powervr-sgx544

and just have a list of allsgx compatible SoC:

+      - items:
+          - enum:
+              - ti,am62-gpu # IMG AXE GPU model/revision is fully discoverable
+              - ti,omap3430-gpu # sgx530 Rev 121
+              - ti,omap3630-gpu # sgx530 Rev 125
+              - ingenic,jz4780-gpu # sgx540 Rev 130
+              - ti,omap4430-gpu # sgx540 Rev 120
+              - allwinner,sun6i-a31-gpu # sgx544 MP2 Rev 115
+              - ti,omap4470-gpu # sgx544 MP1 Rev 112
+              - ti,omap5432-gpu # sgx544 MP2 Rev 105
+              - ti,am5728-gpu # sgx544 MP2 Rev 116
+              - ti,am6548-gpu # sgx544 MP1 Rev 117
+              - more to come

> 
> Andrew
> 
>>>>> And user-space can be made to load the right firmware variant based on "img,sgx530-121"
>>>>> I don't know if there is some register which allows to discover the revision long
>>>>> before the SGX subsystem is initialized and the firmware is up and running.
>>>>> What I know is that it is possible to read out the revision after starting the firmware
>>>>> but it may just echo the version number of the firmware binary provided from user-space.
>>>> 
>>>> We should be able to read out the revision (register EUR_CR_CORE_REVISION), the problem is
>>>> today the driver is built for a given revision at compile time.
>>> 
>>> Yes, that is something we had planned to get rid of for a long time by using different compatible
>>> strings and some variant specific struct like many others drivers are doing it.
>>> But it was a to big task so nobody did start with it.
>>> 
>>>> That is a software issue,
>>>> not something that we need to encode in DT. While the core ID (SGX5xx) can be also detected
>>>> (EUR_CR_CORE_ID), the location of that register changes, and so it does need encoded in
>>>> DT compatible.
>>> 
>>> Ok, I didn't know about such registers as there is not much public information available.
>>> Fair enough, there are some error reports about in different forums.
>>> 
>>> On the other hand we then must read out this register in more or less early initialization
>>> stages. Even if we know this information to be static and it could be as simple as a list
>>> of compatible strings in the driver.
>>> 
>>>> The string "ti,omap3430-gpu" tells us the revision if we cannot detect it (as in the current
>>>> driver), and the SoC integration is generic anyway (just a reg and interrupt).
>>> 
>>> It of course tells, but may need a translation table that needs to be maintained in a
>>> different format. Basically the same what the comments show in a non-machine readable
>>> format.
>>> 
>>> I just wonder why the specific version can or should not become simply part of the DTS
>>> and needs this indirection.
>>> 
>>> Basically it is a matter of openness for future (driver) development and why it needs
>>> careful decisions.
>>> 
>>> So in other words: I would prefer to see the comments about versions encoded in the device
>>> tree binary to make it machine readable.
>> It's already machine readable if it is invariant on an SoC given the
>> patch had SoC-specific compatibles.
> 



From robh at kernel.org  Wed Dec  6 14:02:58 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 16:02:58 -0600
Subject: [PATCH 2/6] dt-bindings: pwm: samsung: add specific compatible
 for Tesla FSD
In-Reply-To: <20231205092229.19135-3-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
 <20231205092229.19135-3-krzysztof.kozlowski@linaro.org>
Message-ID: <170190017774.3416623.1160750978805123790.robh@kernel.org>


On Tue, 05 Dec 2023 10:22:25 +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs.  Historically we
> kept the old (block's) compatible only.  This works fine and there is no
> bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add Tesla FSD compatible specific to be used with an existing fallback.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  Documentation/devicetree/bindings/pwm/pwm-samsung.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Wed Dec  6 14:04:53 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 16:04:53 -0600
Subject: [PATCH 3/6] dt-bindings: serial: samsung: add specific
 compatible for Tesla FSD
In-Reply-To: <20231205092229.19135-4-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
 <20231205092229.19135-4-krzysztof.kozlowski@linaro.org>
Message-ID: <170190029299.3422337.18033865992163523386.robh@kernel.org>


On Tue, 05 Dec 2023 10:22:26 +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs.  Historically we
> kept the old (block's) compatible only.  This works fine and there is no
> bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add Tesla FSD compatible specific to be used with an existing fallback.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Wed Dec  6 14:05:04 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 16:05:04 -0600
Subject: [PATCH 4/6] dt-bindings: samsung: exynos-pmu: add specific
 compatible for Tesla FSD
In-Reply-To: <20231205092229.19135-5-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
 <20231205092229.19135-5-krzysztof.kozlowski@linaro.org>
Message-ID: <170190030447.3422711.17534836727723691670.robh@kernel.org>


On Tue, 05 Dec 2023 10:22:27 +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs.  Historically we
> kept the old (block's) compatible only.  This works fine and there is no
> bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add Tesla FSD compatible specific to be used with an existing fallback.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Wed Dec  6 14:05:20 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 16:05:20 -0600
Subject: [PATCH 5/6] dt-bindings: watchdog: samsung: add specific
 compatible for Tesla FSD
In-Reply-To: <20231205092229.19135-6-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
 <20231205092229.19135-6-krzysztof.kozlowski@linaro.org>
Message-ID: <170190031995.3423149.13499134597119767259.robh@kernel.org>


On Tue, 05 Dec 2023 10:22:28 +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs.  Historically we
> kept the old (block's) compatible only.  This works fine and there is no
> bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add Tesla FSD compatible specific to be used with an existing fallback.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  .../bindings/watchdog/samsung-wdt.yaml        | 21 ++++++++++++-------
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>



From laurent.pinchart at ideasonboard.com  Wed Dec  6 14:05:56 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 00:05:56 +0200
Subject: [PATCH v2 3/4] media: rkisp1: Store IRQ lines
In-Reply-To: <20231206-rkisp-irq-fix-v2-3-6ba4185eeb1f@ideasonboard.com>
References: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
 <20231206-rkisp-irq-fix-v2-3-6ba4185eeb1f@ideasonboard.com>
Message-ID: <20231206220556.GC29417@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Wed, Dec 06, 2023 at 12:12:30PM +0200, Tomi Valkeinen wrote:
> Store the IRQ lines used by the driver for easy access. These are needed
> in future patches which fix IRQ race issues.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
>  .../media/platform/rockchip/rkisp1/rkisp1-common.h    | 11 ++++++++++-
>  drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c   | 19 ++++++++++++++-----
>  2 files changed, 24 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> index 960ab89c659b..ec28907d978e 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> @@ -62,6 +62,14 @@ struct regmap;
>  						 RKISP1_CIF_ISP_EXP_END |	\
>  						 RKISP1_CIF_ISP_HIST_MEASURE_RDY)
>  
> +/* IRQ lines */
> +enum rkisp1_irq_line {
> +	RKISP1_IRQ_ISP = 0,
> +	RKISP1_IRQ_MI,
> +	RKISP1_IRQ_MIPI,
> +	RKISP1_NUM_IRQS,
> +};
> +
>  /* enum for the resizer pads */
>  enum rkisp1_rsz_pad {
>  	RKISP1_RSZ_PAD_SINK,
> @@ -437,7 +445,6 @@ struct rkisp1_debug {
>   * struct rkisp1_device - ISP platform device
>   *
>   * @base_addr:	   base register address
> - * @irq:	   the irq number
>   * @dev:	   a pointer to the struct device
>   * @clk_size:	   number of clocks
>   * @clks:	   array of clocks
> @@ -457,6 +464,7 @@ struct rkisp1_debug {
>   * @stream_lock:   serializes {start/stop}_streaming callbacks between the capture devices.
>   * @debug:	   debug params to be exposed on debugfs
>   * @info:	   version-specific ISP information
> + * @irqs:          IRQ line numbers
>   */
>  struct rkisp1_device {
>  	void __iomem *base_addr;
> @@ -479,6 +487,7 @@ struct rkisp1_device {
>  	struct mutex stream_lock; /* serialize {start/stop}_streaming cb between capture devices */
>  	struct rkisp1_debug debug;
>  	const struct rkisp1_info *info;
> +	int irqs[RKISP1_NUM_IRQS];
>  };
>  
>  /*
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 030eb8c79546..492ff5e6770d 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -115,6 +115,7 @@
>  struct rkisp1_isr_data {
>  	const char *name;
>  	irqreturn_t (*isr)(int irq, void *ctx);
> +	u32 line_mask;
>  };
>  
>  /* ----------------------------------------------------------------------------
> @@ -473,9 +474,9 @@ static const char * const px30_isp_clks[] = {
>  };
>  
>  static const struct rkisp1_isr_data px30_isp_isrs[] = {
> -	{ "isp", rkisp1_isp_isr },
> -	{ "mi", rkisp1_capture_isr },
> -	{ "mipi", rkisp1_csi_isr },
> +	{ "isp", rkisp1_isp_isr, BIT(RKISP1_IRQ_ISP) },
> +	{ "mi", rkisp1_capture_isr, BIT(RKISP1_IRQ_MI) },
> +	{ "mipi", rkisp1_csi_isr, BIT(RKISP1_IRQ_MIPI) },
>  };
>  
>  static const struct rkisp1_info px30_isp_info = {
> @@ -496,7 +497,7 @@ static const char * const rk3399_isp_clks[] = {
>  };
>  
>  static const struct rkisp1_isr_data rk3399_isp_isrs[] = {
> -	{ NULL, rkisp1_isr },
> +	{ NULL, rkisp1_isr, BIT(RKISP1_IRQ_ISP) | BIT(RKISP1_IRQ_MI) | BIT(RKISP1_IRQ_MIPI) },
>  };
>  
>  static const struct rkisp1_info rk3399_isp_info = {
> @@ -517,7 +518,7 @@ static const char * const imx8mp_isp_clks[] = {
>  };
>  
>  static const struct rkisp1_isr_data imx8mp_isp_isrs[] = {
> -	{ NULL, rkisp1_isr },
> +	{ NULL, rkisp1_isr, BIT(RKISP1_IRQ_ISP) | BIT(RKISP1_IRQ_MI) | BIT(RKISP1_IRQ_MIPI) },

The i.MX8MP has no CSI-2 RX in the ISP, you can drop RKISP1_IRQ_MIPI.

I think we can merge this series before the i.MX8MP support, could you
base v3 on top of the master branch of the linux-media stage tree ?

>  };
>  
>  static const struct rkisp1_info imx8mp_isp_info = {
> @@ -574,6 +575,9 @@ static int rkisp1_probe(struct platform_device *pdev)
>  	if (IS_ERR(rkisp1->base_addr))
>  		return PTR_ERR(rkisp1->base_addr);
>  
> +	for (unsigned int il = 0; il < RKISP1_NUM_IRQS; ++il)

I would use ARRAY_SIZE(rkisp1->irqs) instead of RKISP1_NUM_IRQS here.

> +		rkisp1->irqs[il] = -1;
> +
>  	for (i = 0; i < info->isr_size; i++) {
>  		irq = info->isrs[i].name
>  		    ? platform_get_irq_byname(pdev, info->isrs[i].name)
> @@ -581,6 +585,11 @@ static int rkisp1_probe(struct platform_device *pdev)
>  		if (irq < 0)
>  			return irq;
>  
> +		for (unsigned int il = 0; il < RKISP1_NUM_IRQS; ++il) {

Same here.

> +			if (info->isrs[i].line_mask & BIT(il))
> +				rkisp1->irqs[il] = irq;
> +		}
> +
>  		ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0,
>  				       dev_driver_string(dev), dev);
>  		if (ret) {

-- 
Regards,

Laurent Pinchart


From laurent.pinchart at ideasonboard.com  Wed Dec  6 14:13:09 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 00:13:09 +0200
Subject: [PATCH v2 4/4] media: rkisp1: Fix IRQ disable race issue
In-Reply-To: <20231206-rkisp-irq-fix-v2-4-6ba4185eeb1f@ideasonboard.com>
References: <20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f@ideasonboard.com>
 <20231206-rkisp-irq-fix-v2-4-6ba4185eeb1f@ideasonboard.com>
Message-ID: <20231206221309.GD29417@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Wed, Dec 06, 2023 at 12:12:31PM +0200, Tomi Valkeinen wrote:
> In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
> interrupts and then apparently assumes that the interrupt handler won't
> be running, and proceeds in the stop procedure. This is not the case, as
> the interrupt handler can already be running, which would lead to the
> ISP being disabled while the interrupt handler handling a captured
> frame.
> 
> This brings up two issues: 1) the ISP could be powered off while the
> interrupt handler is still running and accessing registers, leading to
> board lockup, and 2) the interrupt handler code and the code that
> disables the streaming might do things that conflict.
> 
> It is not clear to me if 2) causes a real issue, but 1) can be seen with
> a suitable delay (or printk in my case) in the interrupt handler,
> leading to board lockup.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
>  drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c | 14 +++++++++++++-
>  drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 20 +++++++++++++++++---
>  2 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> index 47f4353a1784..0bab3303f2e4 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> @@ -125,8 +125,20 @@ static void rkisp1_csi_disable(struct rkisp1_csi *csi)
>  	struct rkisp1_device *rkisp1 = csi->rkisp1;
>  	u32 val;
>  
> -	/* Mask and clear interrupts. */
> +	/* Mask MIPI interrupts. */
>  	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_IMSC, 0);
> +
> +	/* Flush posted writes */
> +	rkisp1_read(rkisp1, RKISP1_CIF_MIPI_IMSC);
> +
> +	/*
> +	 * Wait until the IRQ handler has ended. The IRQ handler may get called
> +	 * even after this, but it will return immediately as the MIPI
> +	 * interrupts have been masked.
> +	 */
> +	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MIPI]);
> +
> +	/* Clear MIPI interrupt status */
>  	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_ICR, ~0);
>  
>  	val = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_CTRL);
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> index dafbfd230542..33b5a714d117 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> @@ -364,11 +364,25 @@ static void rkisp1_isp_stop(struct rkisp1_isp *isp)
>  	 * ISP(mi) stop in mi frame end -> Stop ISP(mipi) ->
>  	 * Stop ISP(isp) ->wait for ISP isp off
>  	 */
> -	/* stop and clear MI and ISP interrupts */
> -	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
> -	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
>  
> +	/* Mask MI and ISP interrupts */
> +	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
>  	rkisp1_write(rkisp1, RKISP1_CIF_MI_IMSC, 0);
> +
> +	/* Flush posted writes */
> +	rkisp1_read(rkisp1, RKISP1_CIF_MI_IMSC);
> +
> +	/*
> +	 * Wait until the IRQ handler has ended. The IRQ handler may get called
> +	 * even after this, but it will return immediately as the MI and ISP
> +	 * interrupts have been masked.
> +	 */
> +	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_ISP]);
> +	if (rkisp1->irqs[RKISP1_IRQ_ISP] != rkisp1->irqs[RKISP1_IRQ_MI])
> +		synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MI]);
> +
> +	/* Clear MI and ISP interrupt status */
> +	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
>  	rkisp1_write(rkisp1, RKISP1_CIF_MI_ICR, ~0);
>  
>  	/* stop ISP */

-- 
Regards,

Laurent Pinchart


From paul at crapouillou.net  Wed Dec  6 14:15:53 2023
From: paul at crapouillou.net (Paul Cercueil)
Date: Wed,  6 Dec 2023 23:15:53 +0100
Subject: [PATCH 0/3] ARM: dts: samsung: exynos4210-i9100 updates
Message-ID: <20231206221556.15348-1-paul@crapouillou.net>

Hi Krzysztof / Rob,

Here a small patchset with a fix and some improvements to the DTS for
the Galaxy S2 (aka. i9100) phone.

The first patch unconditionally enables a regulator, which seems to be
needed for the phone to boot properly. I do not know what it is
connected to.

The last two patches add nodes for the touch keys and the accelerometer.

This patchset is based on linux-next-20231206.

Cheers,
-Paul.

Paul Cercueil (3):
  ARM: dts: samsung: exynos4210-i9100: Unconditionally enable LDO12
  ARM: dts: samsung: exynos4210-i9100: Add node for touch keys
  ARM: dts: samsung: exynos4210-i9100: Add accelerometer node

 .../arm/boot/dts/samsung/exynos4210-i9100.dts | 48 ++++++++++++++++++-
 1 file changed, 47 insertions(+), 1 deletion(-)

-- 
2.42.0



From paul at crapouillou.net  Wed Dec  6 14:15:54 2023
From: paul at crapouillou.net (Paul Cercueil)
Date: Wed,  6 Dec 2023 23:15:54 +0100
Subject: [PATCH 1/3] ARM: dts: samsung: exynos4210-i9100: Unconditionally enable LDO12
In-Reply-To: <20231206221556.15348-1-paul@crapouillou.net>
References: <20231206221556.15348-1-paul@crapouillou.net>
Message-ID: <20231206221556.15348-2-paul@crapouillou.net>

The kernel hangs for a good 12 seconds without any info being printed to
dmesg, very early in the boot process, if this regulator is not enabled.

Force-enable it to work around this issue, until we know more about the
underlying problem.

Signed-off-by: Paul Cercueil <paul at crapouillou.net>
Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2")
Cc: <stable at vger.kernel.org> # v5.8+
---
 arch/arm/boot/dts/samsung/exynos4210-i9100.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
index a9ec1f6c1dea..a076a1dfe41f 100644
--- a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
@@ -527,6 +527,14 @@ vtcam_reg: LDO12 {
 				regulator-name = "VT_CAM_1.8V";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
+
+				/*
+				 * Force-enable this regulator; otherwise the
+				 * kernel hangs very early in the boot process
+				 * for about 12 seconds, without apparent
+				 * reason.
+				 */
+				regulator-always-on;
 			};
 
 			vcclcd_reg: LDO13 {
-- 
2.42.0



From paul at crapouillou.net  Wed Dec  6 14:15:55 2023
From: paul at crapouillou.net (Paul Cercueil)
Date: Wed,  6 Dec 2023 23:15:55 +0100
Subject: [PATCH 2/3] ARM: dts: samsung: exynos4210-i9100: Add node for touch keys
In-Reply-To: <20231206221556.15348-1-paul@crapouillou.net>
References: <20231206221556.15348-1-paul@crapouillou.net>
Message-ID: <20231206221556.15348-3-paul@crapouillou.net>

Add a Device Tree node to support the LED-backed "menu" and "back" keys.

Signed-off-by: Paul Cercueil <paul at crapouillou.net>
---
 .../arm/boot/dts/samsung/exynos4210-i9100.dts | 23 ++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
index a076a1dfe41f..f03b03dbe9f2 100644
--- a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
@@ -184,6 +184,28 @@ s5k5bafx_ep: endpoint {
 		};
 	};
 
+	i2c-gpio-2 {
+		compatible = "i2c-gpio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		sda-gpios = <&gpk1 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+		scl-gpios = <&gpk1 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+		i2c-gpio,delay-us = <2>;
+
+		touchscreen at 20 {
+			compatible = "cypress,aries-touchkey";
+			reg = <0x20>;
+
+			interrupt-parent = <&gpl0>;
+			interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+			vdd-supply = <&vtouchled_reg>;
+			vcc-supply = <&vtouch_reg>;
+			linux,keycodes = <KEY_MENU>, <KEY_BACK>;
+		};
+	};
+
 	spi-3 {
 		compatible = "spi-gpio";
 		#address-cells = <1>;
@@ -513,7 +535,6 @@ vtouch_reg: LDO11 {
 				regulator-name = "TOUCH_2.8V";
 				regulator-min-microvolt = <2800000>;
 				regulator-max-microvolt = <2800000>;
-				regulator-always-on;
 			};
 
 			vpll_reg: LDO10 {
-- 
2.42.0



From paul at crapouillou.net  Wed Dec  6 14:15:56 2023
From: paul at crapouillou.net (Paul Cercueil)
Date: Wed,  6 Dec 2023 23:15:56 +0100
Subject: [PATCH 3/3] ARM: dts: samsung: exynos4210-i9100: Add accelerometer node
In-Reply-To: <20231206221556.15348-1-paul@crapouillou.net>
References: <20231206221556.15348-1-paul@crapouillou.net>
Message-ID: <20231206221556.15348-4-paul@crapouillou.net>

Add a Device Tree node for the ST Microelectronics "K3D" accelerometer
chip found in the Galaxy S2.

Signed-off-by: Paul Cercueil <paul at crapouillou.net>
---
 arch/arm/boot/dts/samsung/exynos4210-i9100.dts | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
index f03b03dbe9f2..7e57fe033e2b 100644
--- a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
@@ -421,6 +421,23 @@ touchscreen at 4a {
 	};
 };
 
+&i2c_1 {
+	status = "okay";
+
+	samsung,i2c-sda-delay = <100>;
+	samsung,i2c-slave-addr = <0x10>;
+	samsung,i2c-max-bus-freq = <100000>;
+
+	lis3dh: accelerometer at 19 {
+		compatible = "st,lis3dh-accel";
+		reg = <0x19>;
+
+		mount-matrix = "0", "-1", "0",
+			       "1", "0", "0",
+			       "0", "0", "1";
+	};
+};
+
 &i2c_5 {
 	status = "okay";
 
-- 
2.42.0



From paul at crapouillou.net  Wed Dec  6 14:18:41 2023
From: paul at crapouillou.net (Paul Cercueil)
Date: Wed,  6 Dec 2023 23:18:41 +0100
Subject: [PATCH RESEND] drm/exynos: dpi: Change connector type to DPI
Message-ID: <20231206221841.15685-1-paul@crapouillou.net>

When exynos_drm_dpi.c was written, DRM_MODE_CONNECTOR_DPI did not exist
yet and I guess that's the reason why DRM_MODE_CONNECTOR_VGA was used as
the connector type.

However, now it makes more sense to use DRM_MODE_CONNECTOR_DPI as the
connector type.

Signed-off-by: Paul Cercueil <paul at crapouillou.net>
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 378e5381978f..0dc36df6ada3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -101,7 +101,7 @@ static int exynos_dpi_create_connector(struct drm_encoder *encoder)
 
 	ret = drm_connector_init(encoder->dev, connector,
 				 &exynos_dpi_connector_funcs,
-				 DRM_MODE_CONNECTOR_VGA);
+				 DRM_MODE_CONNECTOR_DPI);
 	if (ret) {
 		DRM_DEV_ERROR(ctx->dev,
 			      "failed to initialize connector with drm\n");
-- 
2.42.0



From laurent.pinchart at ideasonboard.com  Wed Dec  6 14:36:36 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 00:36:36 +0200
Subject: [PATCH 1/1] media: nxp: imx8-isi-debug: Add missing registers to
 debugfs output
In-Reply-To: <20231206094401.491100-1-alexander.stein@ew.tq-group.com>
References: <20231206094401.491100-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231206223636.GE29417@pendragon.ideasonboard.com>

Hi Alexander,

On Wed, Dec 06, 2023 at 10:44:01AM +0100, Alexander Stein wrote:
> The extended address registers are missing in the debug output register
> list. Add them.
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> ---
>  drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> index 6709ab7ea1f3..3ac5685d6cc1 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> @@ -66,6 +66,13 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
>  		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF2_ADDR_V),
>  		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
>  		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
> +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),

Those registers only exist in the i.MX8MP. The i.MX8MN referenece manual
lists them as reserved and indicates they read as 0's, so it should be
safe.  The i.MX93 reference manual, however, doesn't list those
registers at all, so accessing them may lead to issues.

How what platform(s) have you tested this patch ?

>  	};
>  
>  	struct mxc_isi_pipe *pipe = m->private;

-- 
Regards,

Laurent Pinchart


From keescook at chromium.org  Wed Dec  6 14:38:40 2023
From: keescook at chromium.org (Kees Cook)
Date: Wed, 6 Dec 2023 14:38:40 -0800
Subject: WARNING: CPU: 6 PID: 474 at include/linux/maple_tree.h:712
 mmap_region (include/linux/maple_tree.h:556 include/linux/maple_tree.h:731
In-Reply-To: <B4299DC4-57CF-4CB2-ACB1-A215F429BF6A@kernel.org>
References: <CA+G9fYs-j2FYZSFSVZj48mgoM9gQd4-7M2mu2Ez3D1DqDdW2bQ@mail.gmail.com>
 <ZUzmlhvRv66I3J6P@finisterre.sirena.org.uk>
 <B4299DC4-57CF-4CB2-ACB1-A215F429BF6A@kernel.org>
Message-ID: <202312061435.E57F367C16@keescook>

On Thu, Nov 09, 2023 at 09:45:26PM -0800, Kees Cook wrote:
> 
> 
> On November 9, 2023 6:03:02 AM PST, Mark Brown <broonie at kernel.org> wrote:
> >On Thu, Nov 09, 2023 at 06:57:08PM +0530, Naresh Kamboju wrote:
> >> Following kernel panic noticed while running  selftests: exec: load_address
> >> on Fastmodels (FVP) running Linux next-20231109.
> >> 
> >
> >Copying in Kees and Eric who maintain the exec API.
> 
> I'm traveling tomorrow so I won't be able to investigate this for a couple days. A quick look makes it seem like this is only happening in -next? (This warning was recently added to __mas_set_range?)
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/include/linux/maple_tree.h?id=02eccbc51164b43c5dadc3e5b40922c757075e08
> 
> Adding Liam...

Did this get addressed? I still see the warning checks in
__mas_set_range()...

-Kees

-- 
Kees Cook


From robh at kernel.org  Wed Dec  6 14:45:57 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 6 Dec 2023 16:45:57 -0600
Subject: [PATCH] arm64: dts: imx8mm-venice: Fix PCI bus nodes
In-Reply-To: <CAJ+vNU1DiFbQivka8gA1URiLMD2mWJnWSdn-77bEo8Uz0Liqcg@mail.gmail.com>
References: <20231130191815.2421978-1-robh@kernel.org> <CAOMZO5AZNz1cRg+aYQjDmpZ75ATJQUTWmC5mx+vgaYcBL6M+2w@mail.gmail.com>
 <CAL_JsqKLFpPo8xTh_vgWvDXSY5J8tQJZh9SrkW2EiK5V_ZNeeA@mail.gmail.com> <CAJ+vNU1DiFbQivka8gA1URiLMD2mWJnWSdn-77bEo8Uz0Liqcg@mail.gmail.com>
Message-ID: <CAL_JsqJmK5UDN_xKjJHac1L4Wsrx1GLDmeek5=K7gm=W9XPkOw@mail.gmail.com>

On Tue, Dec 5, 2023 at 12:13?PM Tim Harvey <tharvey at gateworks.com> wrote:
>
> On Thu, Nov 30, 2023 at 2:33?PM Rob Herring <robh at kernel.org> wrote:
> >
> > On Thu, Nov 30, 2023 at 1:28?PM Fabio Estevam <festevam at gmail.com> wrote:
> > >
> > > Hi Rob,
> > >
> > > On Thu, Nov 30, 2023 at 4:18?PM Rob Herring <robh at kernel.org> wrote:
> > > >
> > > > The imx8mm-venice boards PCI bus nodes are a complete mess. The
> > > > unit-addresses are wrong. The PCI bridge nodes are incomplete missing
> > > > "device_type" and "ranges" and just wrong for "#address-cells" and
> > > > "#size-cells" values.
> > > >
> > > > All of these issues are reported warnings if anyone bothered to pay
> > > > attention. Sigh.
>
> Rob,
>
> Sorry about that. At the time the dt was submitted there were still so
> many dt warnings it wasn't very clear what was a legitimate issue and
> the PCI bindings are not that easy to understand.
>
> > >
> > > The warnings are gone in linux-next:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/freescale?h=next-20231130&id=d61c5068729a76a6183a897bcad4bf26e8d3d674
> >
> > Linux-next is wrong. The ethernet device should have a node name of
> > 'ethernet'. The 'pcie' node name and 'device_type = "pci"' is for PCI
> > buses/bridges only.
>
> So as Fabio has tried to fix this with a patch that landed in
> linux-next this patch won't apply. I'll submit one that covers your
> changes.

Thanks.

> It's always been unfortunate to have to have this level of detail in a
> device-tree just to allow boot firmware to populate the mac address of
> a PCI ethernet device.

More unfortunate are incomplete h/w designs lacking the MAC address. :(

Not really any way around it I think if you want something that works
for any device and any number of devices.

Rob


From bhe at redhat.com  Wed Dec  6 15:22:06 2023
From: bhe at redhat.com (Baoquan He)
Date: Thu, 7 Dec 2023 07:22:06 +0800
Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <20231206-pasta-embassy-c7250740b16c@spud>
References: <20231130023955.5257-1-bhe@redhat.com>
 <20231130023955.5257-6-bhe@redhat.com>
 <20231201-blog-blasphemy-985d2665903c@wendy>
 <ZW3yXWJ7rTrtZzyg@MiWiFi-R3L-srv>
 <20231204-liftoff-enclosure-d3e3daf0ab6e@spud>
 <ZXCVUD9cCYEShrrj@MiWiFi-R3L-srv>
 <20231206-pasta-embassy-c7250740b16c@spud>
Message-ID: <ZXECHg37DRZ9BQsP@MiWiFi-R3L-srv>

On 12/06/23 at 04:54pm, Conor Dooley wrote:
> On Wed, Dec 06, 2023 at 11:37:52PM +0800, Baoquan He wrote:
> > On 12/04/23 at 04:14pm, Conor Dooley wrote:
> > > On Mon, Dec 04, 2023 at 11:38:05PM +0800, Baoquan He wrote:
> > > > On 12/01/23 at 10:38am, Conor Dooley wrote:
> > > > > On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
> > > > > 
> > > > > $subject has a typo in the arch bit :)
> > > > 
> > > > Indeed, will fix if need report. Thanks for careful checking.
> > > > 
> > > > > 
> > > > > > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > > > > > loading related codes.
> > > > > 
> > > > > Commit messages should be understandable in isolation, but this only
> > > > > explains (part of) what is obvious in the diff. Why is this change
> > > > > being made?
> > > > 
> > > > The purpose has been detailedly described in cover letter and patch 1
> > > > log. Andrew has picked these patches into his tree and grabbed the cover
> > > > letter log into the relevant commit for people's later checking. All
> > > > these seven patches will be present in mainline together. This is common
> > > > way when posting patch series? Please let me know if I misunderstand
> > > > anything.
> > > 
> > > Each patch having a commit message that explains why a change is being
> > > made is the expectation. It is especially useful to explain the why
> > > here, since it is not just a mechanical conversion of pr_debug()s as the
> > > commit message suggests.
> > 
> > Sounds reasonable. I rephrase the patch 3 log as below, do you think
> > it's OK to you?
> 
> Yes, but with one comment.
> 
> > 
> > I will also adjust patch logs on other ARCH once this one is done.
> > Thanks.
> > 
> > =============================
> > Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if required
> > 
> > Then when specifying '-d' for kexec_file_load interface, loaded
> > locations of kernel/initrd/cmdline etc can be printed out to help debug.
> > 
> > Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > loading related codes.
> > 
> 
> > And also replace pr_notice() with kexec_dprintk() in elf_kexec_load()
> > because it's make sense to always print out loaded location of purgatory
              ~
> > and device tree even though users don't expect the message.

Fixed typo:
==========

And also replace pr_notice() with kexec_dprintk() in elf_kexec_load()
because it doesn't make sense to always print out loaded location of
purgatory and device tree even though users don't expect the message.

> 
> This seems to contradict what you said in your earlier mail, about
> moving these from notice to debug. I think you missed a negation in your
> new version of the commit message. What you said in response to me seems
> like a more complete explanation anyway:

Ah, I made mistake when typing, these printing is only for debugging,
so always printing out them is not suggested.

> 	always printing out the loaded location of purgatory and
> 	device tree doesn't make sense. It will be confusing when users
> 	see these even when they do normal kexec/kdump loading.
> 
> Thanks,
> Conor.
> 
> > And also remove kexec_image_info() because the content has been printed
> > out in generic code.
> > 
> > ============================
> > 
> > > 
> > > > > 
> > > > > > 
> > > > > > And also remove kexec_image_info() because the content has been printed
> > > > > > out in generic code.
> > > > > > 
> > > > > > Signed-off-by: Baoquan He <bhe at redhat.com>
> > > > > > ---
> > > > > >  arch/riscv/kernel/elf_kexec.c     | 11 ++++++-----
> > > > > >  arch/riscv/kernel/machine_kexec.c | 26 --------------------------
> > > > > >  2 files changed, 6 insertions(+), 31 deletions(-)
> > > > > > 
> > > > > > diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> > > > > > index e60fbd8660c4..5bd1ec3341fe 100644
> > > > > > --- a/arch/riscv/kernel/elf_kexec.c
> > > > > > +++ b/arch/riscv/kernel/elf_kexec.c
> > > > > > @@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > >  	if (ret)
> > > > > >  		goto out;
> > > > > >  	kernel_start = image->start;
> > > > > > -	pr_notice("The entry point of kernel at 0x%lx\n", image->start);
> > > > > >  
> > > > > >  	/* Add the kernel binary to the image */
> > > > > >  	ret = riscv_kexec_elf_load(image, &ehdr, &elf_info,
> > > > > > @@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > >  		image->elf_load_addr = kbuf.mem;
> > > > > >  		image->elf_headers_sz = headers_sz;
> > > > > >  
> > > > > > -		pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > > > > -			 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > > > > +		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > > > > +			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > > > >  
> > > > > >  		/* Setup cmdline for kdump kernel case */
> > > > > >  		modified_cmdline = setup_kdump_cmdline(image, cmdline,
> > > > > > @@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > >  		pr_err("Error loading purgatory ret=%d\n", ret);
> > > > > >  		goto out;
> > > > > >  	}
> > > > > > +	kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem);
> > > > > > +
> > > > > >  	ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry",
> > > > > >  					     &kernel_start,
> > > > > >  					     sizeof(kernel_start), 0);
> > > > > > @@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > >  		if (ret)
> > > > > >  			goto out;
> > > > > >  		initrd_pbase = kbuf.mem;
> > > > > 
> > > > > > -		pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > > > > +		kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > > > 
> > > > > This is not a pr_debug().
> > > > > 
> > > > > >  	}
> > > > > >  
> > > > > >  	/* Add the DTB to the image */
> > > > > > @@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > >  	}
> > > > > >  	/* Cache the fdt buffer address for memory cleanup */
> > > > > >  	image->arch.fdt = fdt;
> > > > > 
> > > > > > -	pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > > > > +	kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > > > 
> > > > > Neither is this. Why are they being moved from pr_notice()?
> > > > 
> > > > You are right. 
> > > > 
> > > > While always printing out the loaded location of purgatory and
> > > > device tree doesn't make sense. It will be confusing when users
> > > > see these even when they do normal kexec/kdump loading. It should be
> > > > changed to pr_debug().
> > > > 
> > > > Which way do you suggest?
> > > > 1) change it back to pr_debug(), fix it in another patch;
> > > > 2) keep it as is in the patch;
> > > 
> > > Personally I think it is fine to change them all in one patch, but the
> > > rationale for converting pr_notice() to your new debug infrastructure
> > > needs to be in the commit message.
> > 
> > Sure, sounds good to me. I have changed the patch log to reflect this as
> > you suggested, please help check. Thanks again.
> > 




From ilkka at os.amperecomputing.com  Wed Dec  6 15:43:39 2023
From: ilkka at os.amperecomputing.com (Ilkka Koskinen)
Date: Wed, 6 Dec 2023 15:43:39 -0800 (PST)
Subject: [PATCH 5/5] perf/arm_cspmu: Add devicetree support
In-Reply-To: <7000cdf3a22afe684793863e81a1d96bbddb5db1.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com> <7000cdf3a22afe684793863e81a1d96bbddb5db1.1701793996.git.robin.murphy@arm.com>
Message-ID: <b7905a93-e4c-b6a6-d584-389131f4276@os.amperecomputing.com>


Hi Robin,

On Tue, 5 Dec 2023, Robin Murphy wrote:
> Hook up devicetree probing support. For now let's hope that people
> implement PMIIDR properly and we don't need an override mechanism.
>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
> drivers/perf/arm_cspmu/arm_cspmu.c | 71 +++++++++++++++++++++++-------
> 1 file changed, 56 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
> index b64de4d800c7..80b5fc417ee3 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> @@ -27,6 +27,7 @@
> #include <linux/io-64-nonatomic-lo-hi.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> +#include <linux/of.h>
> #include <linux/perf_event.h>
> #include <linux/platform_device.h>
>
> @@ -309,6 +310,10 @@ static const char *arm_cspmu_get_name(const struct arm_cspmu *cspmu)
> 	static atomic_t pmu_idx[ACPI_APMT_NODE_TYPE_COUNT] = { 0 };
>
> 	dev = cspmu->dev;
> +	if (!has_acpi_companion(dev))

Am I missing something since this doesn't work on top of v6.7-rc4?
The problem I see is that has_acpi_companion() calls 
is_acpi_device_node(), which compares whether

 	fwnode->ops == &acpi_device_fwnode_ops;

However, the acpi/apmt code allocates fwnode by calling
acpi_alloc_fwnode_static(), which assigns &acpi_static_fwnode_ops
to ops.

I wonder though, if is_acpi_device_node() should check the static variant 
too? :/

Cheers, Ilkka

> +		return devm_kasprintf(dev, GFP_KERNEL, PMUNAME "_%u",
> +				      atomic_fetch_inc(&pmu_idx[0]));
> +
> 	apmt_node = arm_cspmu_apmt_node(dev);
> 	pmu_type = apmt_node->type;
>
> @@ -406,7 +411,6 @@ static struct arm_cspmu_impl_match *arm_cspmu_impl_match_get(u32 pmiidr)
> static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
> {
> 	int ret = 0;
> -	struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(cspmu->dev);
> 	struct arm_cspmu_impl_match *match;
>
> 	/* Start with a default PMU implementation */
> @@ -425,8 +429,12 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
> 	};
>
> 	/* Firmware may override implementer/product ID from PMIIDR */
> -	if (apmt_node->impl_id)
> -		cspmu->impl.pmiidr = apmt_node->impl_id;
> +	if (has_acpi_companion(cspmu->dev)) {
> +		struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(cspmu->dev);
> +
> +		if (apmt_node->impl_id)
> +			cspmu->impl.pmiidr = apmt_node->impl_id;
> +	}
>
> 	/* Find implementer specific attribute ops. */
> 	match = arm_cspmu_impl_match_get(cspmu->impl.pmiidr);
> @@ -928,7 +936,6 @@ static void arm_cspmu_read(struct perf_event *event)
>
> static struct arm_cspmu *arm_cspmu_alloc(struct platform_device *pdev)
> {
> -	struct acpi_apmt_node *apmt_node;
> 	struct arm_cspmu *cspmu;
> 	struct device *dev = &pdev->dev;
>
> @@ -939,8 +946,13 @@ static struct arm_cspmu *arm_cspmu_alloc(struct platform_device *pdev)
> 	cspmu->dev = dev;
> 	platform_set_drvdata(pdev, cspmu);
>
> -	apmt_node = arm_cspmu_apmt_node(dev);
> -	cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
> +	if (has_acpi_companion(dev)) {
> +		struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(dev);
> +
> +		cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
> +	} else {
> +		cspmu->has_atomic_dword = device_property_read_bool(dev, "arm,64-bit-atomic");
> +	}
>
> 	return cspmu;
> }
> @@ -1133,11 +1145,6 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
> 		}
> 	}
>
> -	if (cpumask_empty(&cspmu->associated_cpus)) {
> -		dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
> -		return -ENODEV;
> -	}
> -
> 	return 0;
> }
> #else
> @@ -1147,9 +1154,36 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
> }
> #endif
>
> +static int arm_cspmu_of_get_cpus(struct arm_cspmu *cspmu)
> +{
> +	struct of_phandle_iterator it;
> +	int ret, cpu;
> +
> +	of_for_each_phandle(&it, ret, cspmu->dev->of_node, "cpus", NULL, 0) {
> +		cpu = of_cpu_node_to_id(it.node);
> +		if (cpu < 0)
> +			continue;
> +		cpumask_set_cpu(cpu, &cspmu->associated_cpus);
> +	}
> +	return ret;
> +}
> +
> static int arm_cspmu_get_cpus(struct arm_cspmu *cspmu)
> {
> -	return arm_cspmu_acpi_get_cpus(cspmu);
> +	int ret = 0;
> +
> +	if (has_acpi_companion(cspmu->dev))
> +		ret = arm_cspmu_acpi_get_cpus(cspmu);
> +	else if (of_property_present(cspmu->dev->of_node, "cpus"))
> +		ret = arm_cspmu_of_get_cpus(cspmu);
> +	else
> +		cpumask_copy(&cspmu->associated_cpus, cpu_possible_mask);
> +
> +	if (!ret && cpumask_empty(&cspmu->associated_cpus)) {
> +		dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
> +		ret = -ENODEV;
> +	}
> +	return ret;
> }
>
> static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
> @@ -1246,11 +1280,18 @@ static const struct platform_device_id arm_cspmu_id[] = {
> };
> MODULE_DEVICE_TABLE(platform, arm_cspmu_id);
>
> +static const struct of_device_id arm_cspmu_of_match[] = {
> +	{ .compatible = "arm,coresight-pmu" },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, arm_cspmu_of_match);
> +
> static struct platform_driver arm_cspmu_driver = {
> 	.driver = {
> -			.name = DRVNAME,
> -			.suppress_bind_attrs = true,
> -		},
> +		.name = DRVNAME,
> +		.of_match_table = arm_cspmu_of_match,
> +		.suppress_bind_attrs = true,
> +	},
> 	.probe = arm_cspmu_device_probe,
> 	.remove = arm_cspmu_device_remove,
> 	.id_table = arm_cspmu_id,
> -- 
> 2.39.2.101.g768bb238c484.dirty
>
>


From lkp at intel.com  Wed Dec  6 15:43:14 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 7 Dec 2023 07:43:14 +0800
Subject: [PATCH] media: medkatek: vcodec: support tee decoder
In-Reply-To: <20231206081538.17056-21-yunfei.dong@mediatek.com>
References: <20231206081538.17056-21-yunfei.dong@mediatek.com>
Message-ID: <202312070717.a86rODYn-lkp@intel.com>

Hi Yunfei,

kernel test robot noticed the following build errors:

[auto build test ERROR on media-tree/master]
[also build test ERROR on linus/master v6.7-rc4 next-20231206]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Yunfei-Dong/media-medkatek-vcodec-support-tee-decoder/20231206-201843
base:   git://linuxtv.org/media_tree.git master
patch link:    https://lore.kernel.org/r/20231206081538.17056-21-yunfei.dong%40mediatek.com
patch subject: [PATCH] media: medkatek: vcodec: support tee decoder
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20231207/202312070717.a86rODYn-lkp at intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231207/202312070717.a86rODYn-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312070717.a86rODYn-lkp at intel.com/

All errors (new ones prefixed by >>):

   drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c: In function 'fops_vcodec_release':
>> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:313:16: error: 'struct mtk_vcodec_dec_ctx' has no member named 'is_secure_playback'
     313 |         if (ctx->is_secure_playback)
         |                ^~
>> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:17: error: implicit declaration of function 'mtk_vcodec_dec_optee_release'; did you mean 'mtk_vcodec_dec_release'? [-Werror=implicit-function-declaration]
     314 |                 mtk_vcodec_dec_optee_release(dev->optee_private);
         |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
         |                 mtk_vcodec_dec_release
>> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:49: error: 'struct mtk_vcodec_dec_dev' has no member named 'optee_private'
     314 |                 mtk_vcodec_dec_optee_release(dev->optee_private);
         |                                                 ^~
   drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c: In function 'mtk_vcodec_probe':
>> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:472:15: error: implicit declaration of function 'mtk_vcodec_dec_optee_private_init'; did you mean 'mtk_vcodec_dec_queue_init'? [-Werror=implicit-function-declaration]
     472 |         ret = mtk_vcodec_dec_optee_private_init(dev);
         |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         |               mtk_vcodec_dec_queue_init
   cc1: some warnings being treated as errors


vim +313 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c

   291	
   292	static int fops_vcodec_release(struct file *file)
   293	{
   294		struct mtk_vcodec_dec_dev *dev = video_drvdata(file);
   295		struct mtk_vcodec_dec_ctx *ctx = fh_to_dec_ctx(file->private_data);
   296	
   297		mtk_v4l2_vdec_dbg(0, ctx, "[%d] decoder", ctx->id);
   298		mutex_lock(&dev->dev_mutex);
   299	
   300		/*
   301		 * Call v4l2_m2m_ctx_release before mtk_vcodec_dec_release. First, it
   302		 * makes sure the worker thread is not running after vdec_if_deinit.
   303		 * Second, the decoder will be flushed and all the buffers will be
   304		 * returned in stop_streaming.
   305		 */
   306		v4l2_m2m_ctx_release(ctx->m2m_ctx);
   307		mtk_vcodec_dec_release(ctx);
   308	
   309		v4l2_fh_del(&ctx->fh);
   310		v4l2_fh_exit(&ctx->fh);
   311		v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
   312	
 > 313		if (ctx->is_secure_playback)
 > 314			mtk_vcodec_dec_optee_release(dev->optee_private);
   315	
   316		mtk_vcodec_dbgfs_remove(dev, ctx->id);
   317		list_del_init(&ctx->list);
   318		kfree(ctx);
   319		mutex_unlock(&dev->dev_mutex);
   320		return 0;
   321	}
   322	
   323	static const struct v4l2_file_operations mtk_vcodec_fops = {
   324		.owner		= THIS_MODULE,
   325		.open		= fops_vcodec_open,
   326		.release	= fops_vcodec_release,
   327		.poll		= v4l2_m2m_fop_poll,
   328		.unlocked_ioctl	= video_ioctl2,
   329		.mmap		= v4l2_m2m_fop_mmap,
   330	};
   331	
   332	static void mtk_vcodec_dec_get_chip_name(struct mtk_vcodec_dec_dev *vdec_dev)
   333	{
   334		struct device *dev = &vdec_dev->plat_dev->dev;
   335	
   336		if (of_device_is_compatible(dev->of_node, "mediatek,mt8173-vcodec-dec"))
   337			vdec_dev->chip_name = MTK_VDEC_MT8173;
   338		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8183-vcodec-dec"))
   339			vdec_dev->chip_name = MTK_VDEC_MT8183;
   340		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-dec"))
   341			vdec_dev->chip_name = MTK_VDEC_MT8192;
   342		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-dec"))
   343			vdec_dev->chip_name = MTK_VDEC_MT8195;
   344		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8186-vcodec-dec"))
   345			vdec_dev->chip_name = MTK_VDEC_MT8186;
   346		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8188-vcodec-dec"))
   347			vdec_dev->chip_name = MTK_VDEC_MT8188;
   348		else
   349			vdec_dev->chip_name = MTK_VDEC_INVAL;
   350	}
   351	
   352	static int mtk_vcodec_probe(struct platform_device *pdev)
   353	{
   354		struct mtk_vcodec_dec_dev *dev;
   355		struct video_device *vfd_dec;
   356		phandle rproc_phandle;
   357		enum mtk_vcodec_fw_type fw_type;
   358		int i, ret;
   359	
   360		dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
   361		if (!dev)
   362			return -ENOMEM;
   363	
   364		INIT_LIST_HEAD(&dev->ctx_list);
   365		dev->plat_dev = pdev;
   366	
   367		mtk_vcodec_dec_get_chip_name(dev);
   368		if (dev->chip_name == MTK_VDEC_INVAL) {
   369			dev_err(&pdev->dev, "Failed to get decoder chip name");
   370			return -EINVAL;
   371		}
   372	
   373		dev->vdec_pdata = of_device_get_match_data(&pdev->dev);
   374		if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vpu",
   375					  &rproc_phandle)) {
   376			fw_type = VPU;
   377		} else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp",
   378						 &rproc_phandle)) {
   379			fw_type = SCP;
   380		} else {
   381			dev_dbg(&pdev->dev, "Could not get vdec IPI device");
   382			return -ENODEV;
   383		}
   384		dma_set_max_seg_size(&pdev->dev, UINT_MAX);
   385	
   386		dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, DECODER);
   387		if (IS_ERR(dev->fw_handler))
   388			return PTR_ERR(dev->fw_handler);
   389	
   390		ret = mtk_vcodec_init_dec_resources(dev);
   391		if (ret) {
   392			dev_err(&pdev->dev, "Failed to init dec resources");
   393			goto err_dec_pm;
   394		}
   395	
   396		if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) {
   397			dev->core_workqueue =
   398				alloc_ordered_workqueue("core-decoder",
   399							WQ_MEM_RECLAIM | WQ_FREEZABLE);
   400			if (!dev->core_workqueue) {
   401				dev_dbg(&pdev->dev, "Failed to create core workqueue");
   402				ret = -EINVAL;
   403				goto err_res;
   404			}
   405		}
   406	
   407		for (i = 0; i < MTK_VDEC_HW_MAX; i++)
   408			mutex_init(&dev->dec_mutex[i]);
   409		mutex_init(&dev->dev_mutex);
   410		spin_lock_init(&dev->irqlock);
   411	
   412		snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name), "%s",
   413			"[/MTK_V4L2_VDEC]");
   414	
   415		ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
   416		if (ret) {
   417			dev_err(&pdev->dev, "v4l2_device_register err=%d", ret);
   418			goto err_core_workq;
   419		}
   420	
   421		vfd_dec = video_device_alloc();
   422		if (!vfd_dec) {
   423			dev_err(&pdev->dev, "Failed to allocate video device");
   424			ret = -ENOMEM;
   425			goto err_dec_alloc;
   426		}
   427		vfd_dec->fops		= &mtk_vcodec_fops;
   428		vfd_dec->ioctl_ops	= &mtk_vdec_ioctl_ops;
   429		vfd_dec->release	= video_device_release;
   430		vfd_dec->lock		= &dev->dev_mutex;
   431		vfd_dec->v4l2_dev	= &dev->v4l2_dev;
   432		vfd_dec->vfl_dir	= VFL_DIR_M2M;
   433		vfd_dec->device_caps	= V4L2_CAP_VIDEO_M2M_MPLANE |
   434				V4L2_CAP_STREAMING;
   435	
   436		snprintf(vfd_dec->name, sizeof(vfd_dec->name), "%s",
   437			MTK_VCODEC_DEC_NAME);
   438		video_set_drvdata(vfd_dec, dev);
   439		dev->vfd_dec = vfd_dec;
   440		platform_set_drvdata(pdev, dev);
   441	
   442		dev->m2m_dev_dec = v4l2_m2m_init(&mtk_vdec_m2m_ops);
   443		if (IS_ERR((__force void *)dev->m2m_dev_dec)) {
   444			dev_err(&pdev->dev, "Failed to init mem2mem dec device");
   445			ret = PTR_ERR((__force void *)dev->m2m_dev_dec);
   446			goto err_dec_alloc;
   447		}
   448	
   449		dev->decode_workqueue =
   450			alloc_ordered_workqueue(MTK_VCODEC_DEC_NAME,
   451				WQ_MEM_RECLAIM | WQ_FREEZABLE);
   452		if (!dev->decode_workqueue) {
   453			dev_err(&pdev->dev, "Failed to create decode workqueue");
   454			ret = -EINVAL;
   455			goto err_event_workq;
   456		}
   457	
   458		if (dev->vdec_pdata->is_subdev_supported) {
   459			ret = of_platform_populate(pdev->dev.of_node, NULL, NULL,
   460						   &pdev->dev);
   461			if (ret) {
   462				dev_err(&pdev->dev, "Main device of_platform_populate failed.");
   463				goto err_reg_cont;
   464			}
   465		} else {
   466			set_bit(MTK_VDEC_CORE, dev->subdev_bitmap);
   467		}
   468	
   469		atomic_set(&dev->dec_active_cnt, 0);
   470		memset(dev->vdec_racing_info, 0, sizeof(dev->vdec_racing_info));
   471		mutex_init(&dev->dec_racing_info_mutex);
 > 472		ret = mtk_vcodec_dec_optee_private_init(dev);
   473		if (ret) {
   474			dev_err(&pdev->dev, "Failed to init svp private.");
   475			goto err_reg_cont;
   476		}
   477	
   478		ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, -1);
   479		if (ret) {
   480			dev_err(&pdev->dev, "Failed to register video device");
   481			goto err_reg_cont;
   482		}
   483	
   484		if (dev->vdec_pdata->uses_stateless_api) {
   485			v4l2_disable_ioctl(vfd_dec, VIDIOC_DECODER_CMD);
   486			v4l2_disable_ioctl(vfd_dec, VIDIOC_TRY_DECODER_CMD);
   487	
   488			dev->mdev_dec.dev = &pdev->dev;
   489			strscpy(dev->mdev_dec.model, MTK_VCODEC_DEC_NAME,
   490				sizeof(dev->mdev_dec.model));
   491	
   492			media_device_init(&dev->mdev_dec);
   493			dev->mdev_dec.ops = &mtk_vcodec_media_ops;
   494			dev->v4l2_dev.mdev = &dev->mdev_dec;
   495	
   496			ret = v4l2_m2m_register_media_controller(dev->m2m_dev_dec, dev->vfd_dec,
   497								 MEDIA_ENT_F_PROC_VIDEO_DECODER);
   498			if (ret) {
   499				dev_err(&pdev->dev, "Failed to register media controller");
   500				goto err_dec_mem_init;
   501			}
   502	
   503			ret = media_device_register(&dev->mdev_dec);
   504			if (ret) {
   505				dev_err(&pdev->dev, "Failed to register media device");
   506				goto err_media_reg;
   507			}
   508	
   509			dev_dbg(&pdev->dev, "media registered as /dev/media%d", vfd_dec->minor);
   510		}
   511	
   512		mtk_vcodec_dbgfs_init(dev, false);
   513		dev_dbg(&pdev->dev, "decoder registered as /dev/video%d", vfd_dec->minor);
   514	
   515		return 0;
   516	
   517	err_media_reg:
   518		v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec);
   519	err_dec_mem_init:
   520		video_unregister_device(vfd_dec);
   521	err_reg_cont:
   522		if (dev->vdec_pdata->uses_stateless_api)
   523			media_device_cleanup(&dev->mdev_dec);
   524		destroy_workqueue(dev->decode_workqueue);
   525	err_event_workq:
   526		v4l2_m2m_release(dev->m2m_dev_dec);
   527	err_dec_alloc:
   528		v4l2_device_unregister(&dev->v4l2_dev);
   529	err_core_workq:
   530		if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch))
   531			destroy_workqueue(dev->core_workqueue);
   532	err_res:
   533		if (!dev->vdec_pdata->is_subdev_supported)
   534			pm_runtime_disable(dev->pm.dev);
   535	err_dec_pm:
   536		mtk_vcodec_fw_release(dev->fw_handler);
   537		return ret;
   538	}
   539	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Wed Dec  6 15:43:15 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 7 Dec 2023 07:43:15 +0800
Subject: [PATCH] media: medkatek: vcodec: support tee decoder
In-Reply-To: <20231206081538.17056-21-yunfei.dong@mediatek.com>
References: <20231206081538.17056-21-yunfei.dong@mediatek.com>
Message-ID: <202312070723.APrpMLj9-lkp@intel.com>

Hi Yunfei,

kernel test robot noticed the following build errors:

[auto build test ERROR on media-tree/master]
[also build test ERROR on linus/master v6.7-rc4 next-20231206]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Yunfei-Dong/media-medkatek-vcodec-support-tee-decoder/20231206-201843
base:   git://linuxtv.org/media_tree.git master
patch link:    https://lore.kernel.org/r/20231206081538.17056-21-yunfei.dong%40mediatek.com
patch subject: [PATCH] media: medkatek: vcodec: support tee decoder
config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20231207/202312070723.APrpMLj9-lkp at intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231207/202312070723.APrpMLj9-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312070723.APrpMLj9-lkp at intel.com/

All errors (new ones prefixed by >>):

>> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:313:11: error: no member named 'is_secure_playback' in 'struct mtk_vcodec_dec_ctx'
     313 |         if (ctx->is_secure_playback)
         |             ~~~  ^
>> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:3: error: call to undeclared function 'mtk_vcodec_dec_optee_release'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     314 |                 mtk_vcodec_dec_optee_release(dev->optee_private);
         |                 ^
   drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:3: note: did you mean 'mtk_vcodec_dec_release'?
   drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.h:88:6: note: 'mtk_vcodec_dec_release' declared here
      88 | void mtk_vcodec_dec_release(struct mtk_vcodec_dec_ctx *ctx);
         |      ^
>> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:37: error: no member named 'optee_private' in 'struct mtk_vcodec_dec_dev'
     314 |                 mtk_vcodec_dec_optee_release(dev->optee_private);
         |                                              ~~~  ^
>> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:472:8: error: call to undeclared function 'mtk_vcodec_dec_optee_private_init'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     472 |         ret = mtk_vcodec_dec_optee_private_init(dev);
         |               ^
   drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:472:8: note: did you mean 'mtk_vcodec_dec_queue_init'?
   drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.h:85:5: note: 'mtk_vcodec_dec_queue_init' declared here
      85 | int mtk_vcodec_dec_queue_init(void *priv, struct vb2_queue *src_vq,
         |     ^
   4 errors generated.


vim +313 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c

   291	
   292	static int fops_vcodec_release(struct file *file)
   293	{
   294		struct mtk_vcodec_dec_dev *dev = video_drvdata(file);
   295		struct mtk_vcodec_dec_ctx *ctx = fh_to_dec_ctx(file->private_data);
   296	
   297		mtk_v4l2_vdec_dbg(0, ctx, "[%d] decoder", ctx->id);
   298		mutex_lock(&dev->dev_mutex);
   299	
   300		/*
   301		 * Call v4l2_m2m_ctx_release before mtk_vcodec_dec_release. First, it
   302		 * makes sure the worker thread is not running after vdec_if_deinit.
   303		 * Second, the decoder will be flushed and all the buffers will be
   304		 * returned in stop_streaming.
   305		 */
   306		v4l2_m2m_ctx_release(ctx->m2m_ctx);
   307		mtk_vcodec_dec_release(ctx);
   308	
   309		v4l2_fh_del(&ctx->fh);
   310		v4l2_fh_exit(&ctx->fh);
   311		v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
   312	
 > 313		if (ctx->is_secure_playback)
 > 314			mtk_vcodec_dec_optee_release(dev->optee_private);
   315	
   316		mtk_vcodec_dbgfs_remove(dev, ctx->id);
   317		list_del_init(&ctx->list);
   318		kfree(ctx);
   319		mutex_unlock(&dev->dev_mutex);
   320		return 0;
   321	}
   322	
   323	static const struct v4l2_file_operations mtk_vcodec_fops = {
   324		.owner		= THIS_MODULE,
   325		.open		= fops_vcodec_open,
   326		.release	= fops_vcodec_release,
   327		.poll		= v4l2_m2m_fop_poll,
   328		.unlocked_ioctl	= video_ioctl2,
   329		.mmap		= v4l2_m2m_fop_mmap,
   330	};
   331	
   332	static void mtk_vcodec_dec_get_chip_name(struct mtk_vcodec_dec_dev *vdec_dev)
   333	{
   334		struct device *dev = &vdec_dev->plat_dev->dev;
   335	
   336		if (of_device_is_compatible(dev->of_node, "mediatek,mt8173-vcodec-dec"))
   337			vdec_dev->chip_name = MTK_VDEC_MT8173;
   338		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8183-vcodec-dec"))
   339			vdec_dev->chip_name = MTK_VDEC_MT8183;
   340		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-dec"))
   341			vdec_dev->chip_name = MTK_VDEC_MT8192;
   342		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-dec"))
   343			vdec_dev->chip_name = MTK_VDEC_MT8195;
   344		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8186-vcodec-dec"))
   345			vdec_dev->chip_name = MTK_VDEC_MT8186;
   346		else if (of_device_is_compatible(dev->of_node, "mediatek,mt8188-vcodec-dec"))
   347			vdec_dev->chip_name = MTK_VDEC_MT8188;
   348		else
   349			vdec_dev->chip_name = MTK_VDEC_INVAL;
   350	}
   351	
   352	static int mtk_vcodec_probe(struct platform_device *pdev)
   353	{
   354		struct mtk_vcodec_dec_dev *dev;
   355		struct video_device *vfd_dec;
   356		phandle rproc_phandle;
   357		enum mtk_vcodec_fw_type fw_type;
   358		int i, ret;
   359	
   360		dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
   361		if (!dev)
   362			return -ENOMEM;
   363	
   364		INIT_LIST_HEAD(&dev->ctx_list);
   365		dev->plat_dev = pdev;
   366	
   367		mtk_vcodec_dec_get_chip_name(dev);
   368		if (dev->chip_name == MTK_VDEC_INVAL) {
   369			dev_err(&pdev->dev, "Failed to get decoder chip name");
   370			return -EINVAL;
   371		}
   372	
   373		dev->vdec_pdata = of_device_get_match_data(&pdev->dev);
   374		if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vpu",
   375					  &rproc_phandle)) {
   376			fw_type = VPU;
   377		} else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp",
   378						 &rproc_phandle)) {
   379			fw_type = SCP;
   380		} else {
   381			dev_dbg(&pdev->dev, "Could not get vdec IPI device");
   382			return -ENODEV;
   383		}
   384		dma_set_max_seg_size(&pdev->dev, UINT_MAX);
   385	
   386		dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, DECODER);
   387		if (IS_ERR(dev->fw_handler))
   388			return PTR_ERR(dev->fw_handler);
   389	
   390		ret = mtk_vcodec_init_dec_resources(dev);
   391		if (ret) {
   392			dev_err(&pdev->dev, "Failed to init dec resources");
   393			goto err_dec_pm;
   394		}
   395	
   396		if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) {
   397			dev->core_workqueue =
   398				alloc_ordered_workqueue("core-decoder",
   399							WQ_MEM_RECLAIM | WQ_FREEZABLE);
   400			if (!dev->core_workqueue) {
   401				dev_dbg(&pdev->dev, "Failed to create core workqueue");
   402				ret = -EINVAL;
   403				goto err_res;
   404			}
   405		}
   406	
   407		for (i = 0; i < MTK_VDEC_HW_MAX; i++)
   408			mutex_init(&dev->dec_mutex[i]);
   409		mutex_init(&dev->dev_mutex);
   410		spin_lock_init(&dev->irqlock);
   411	
   412		snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name), "%s",
   413			"[/MTK_V4L2_VDEC]");
   414	
   415		ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
   416		if (ret) {
   417			dev_err(&pdev->dev, "v4l2_device_register err=%d", ret);
   418			goto err_core_workq;
   419		}
   420	
   421		vfd_dec = video_device_alloc();
   422		if (!vfd_dec) {
   423			dev_err(&pdev->dev, "Failed to allocate video device");
   424			ret = -ENOMEM;
   425			goto err_dec_alloc;
   426		}
   427		vfd_dec->fops		= &mtk_vcodec_fops;
   428		vfd_dec->ioctl_ops	= &mtk_vdec_ioctl_ops;
   429		vfd_dec->release	= video_device_release;
   430		vfd_dec->lock		= &dev->dev_mutex;
   431		vfd_dec->v4l2_dev	= &dev->v4l2_dev;
   432		vfd_dec->vfl_dir	= VFL_DIR_M2M;
   433		vfd_dec->device_caps	= V4L2_CAP_VIDEO_M2M_MPLANE |
   434				V4L2_CAP_STREAMING;
   435	
   436		snprintf(vfd_dec->name, sizeof(vfd_dec->name), "%s",
   437			MTK_VCODEC_DEC_NAME);
   438		video_set_drvdata(vfd_dec, dev);
   439		dev->vfd_dec = vfd_dec;
   440		platform_set_drvdata(pdev, dev);
   441	
   442		dev->m2m_dev_dec = v4l2_m2m_init(&mtk_vdec_m2m_ops);
   443		if (IS_ERR((__force void *)dev->m2m_dev_dec)) {
   444			dev_err(&pdev->dev, "Failed to init mem2mem dec device");
   445			ret = PTR_ERR((__force void *)dev->m2m_dev_dec);
   446			goto err_dec_alloc;
   447		}
   448	
   449		dev->decode_workqueue =
   450			alloc_ordered_workqueue(MTK_VCODEC_DEC_NAME,
   451				WQ_MEM_RECLAIM | WQ_FREEZABLE);
   452		if (!dev->decode_workqueue) {
   453			dev_err(&pdev->dev, "Failed to create decode workqueue");
   454			ret = -EINVAL;
   455			goto err_event_workq;
   456		}
   457	
   458		if (dev->vdec_pdata->is_subdev_supported) {
   459			ret = of_platform_populate(pdev->dev.of_node, NULL, NULL,
   460						   &pdev->dev);
   461			if (ret) {
   462				dev_err(&pdev->dev, "Main device of_platform_populate failed.");
   463				goto err_reg_cont;
   464			}
   465		} else {
   466			set_bit(MTK_VDEC_CORE, dev->subdev_bitmap);
   467		}
   468	
   469		atomic_set(&dev->dec_active_cnt, 0);
   470		memset(dev->vdec_racing_info, 0, sizeof(dev->vdec_racing_info));
   471		mutex_init(&dev->dec_racing_info_mutex);
 > 472		ret = mtk_vcodec_dec_optee_private_init(dev);
   473		if (ret) {
   474			dev_err(&pdev->dev, "Failed to init svp private.");
   475			goto err_reg_cont;
   476		}
   477	
   478		ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, -1);
   479		if (ret) {
   480			dev_err(&pdev->dev, "Failed to register video device");
   481			goto err_reg_cont;
   482		}
   483	
   484		if (dev->vdec_pdata->uses_stateless_api) {
   485			v4l2_disable_ioctl(vfd_dec, VIDIOC_DECODER_CMD);
   486			v4l2_disable_ioctl(vfd_dec, VIDIOC_TRY_DECODER_CMD);
   487	
   488			dev->mdev_dec.dev = &pdev->dev;
   489			strscpy(dev->mdev_dec.model, MTK_VCODEC_DEC_NAME,
   490				sizeof(dev->mdev_dec.model));
   491	
   492			media_device_init(&dev->mdev_dec);
   493			dev->mdev_dec.ops = &mtk_vcodec_media_ops;
   494			dev->v4l2_dev.mdev = &dev->mdev_dec;
   495	
   496			ret = v4l2_m2m_register_media_controller(dev->m2m_dev_dec, dev->vfd_dec,
   497								 MEDIA_ENT_F_PROC_VIDEO_DECODER);
   498			if (ret) {
   499				dev_err(&pdev->dev, "Failed to register media controller");
   500				goto err_dec_mem_init;
   501			}
   502	
   503			ret = media_device_register(&dev->mdev_dec);
   504			if (ret) {
   505				dev_err(&pdev->dev, "Failed to register media device");
   506				goto err_media_reg;
   507			}
   508	
   509			dev_dbg(&pdev->dev, "media registered as /dev/media%d", vfd_dec->minor);
   510		}
   511	
   512		mtk_vcodec_dbgfs_init(dev, false);
   513		dev_dbg(&pdev->dev, "decoder registered as /dev/video%d", vfd_dec->minor);
   514	
   515		return 0;
   516	
   517	err_media_reg:
   518		v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec);
   519	err_dec_mem_init:
   520		video_unregister_device(vfd_dec);
   521	err_reg_cont:
   522		if (dev->vdec_pdata->uses_stateless_api)
   523			media_device_cleanup(&dev->mdev_dec);
   524		destroy_workqueue(dev->decode_workqueue);
   525	err_event_workq:
   526		v4l2_m2m_release(dev->m2m_dev_dec);
   527	err_dec_alloc:
   528		v4l2_device_unregister(&dev->v4l2_dev);
   529	err_core_workq:
   530		if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch))
   531			destroy_workqueue(dev->core_workqueue);
   532	err_res:
   533		if (!dev->vdec_pdata->is_subdev_supported)
   534			pm_runtime_disable(dev->pm.dev);
   535	err_dec_pm:
   536		mtk_vcodec_fw_release(dev->fw_handler);
   537		return ret;
   538	}
   539	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From ahalaney at redhat.com  Wed Dec  6 15:46:09 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Wed, 06 Dec 2023 17:46:09 -0600
Subject: [PATCH net-next v2] net: stmmac: don't create a MDIO bus if
 unnecessary
Message-ID: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>

The stmmac_dt_phy() function, which parses the devicetree node of the
MAC and ultimately causes MDIO bus allocation, misinterprets what
fixed-link means in relation to the MAC's MDIO bus. This results in
a MDIO bus being created in situations it need not be.

Currently a MDIO bus is created if the description is either:

    1. Not fixed-link
    2. fixed-link but contains a MDIO bus as well

The "1" case above isn't always accurate. If there's a phy-handle,
it could be referencing a phy on another MDIO controller's bus[1]. In
this case currently the MAC will make a MDIO bus and scan it all
anyways unnecessarily.

There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
be created and scanned for a phy. This case can also be inferred from
the platform description by not having a phy-handle && not being
fixed-link. This hits case "1" in the current driver's logic.

Let's improve the logic to create a MDIO bus if either:

    - Devicetree contains a MDIO bus
    - !fixed-link && !phy-handle (legacy handling)

Below upstream devicetree snippets can be found that explain some of
the cases above more concretely.

Here's[0] a devicetree example where the MAC is both fixed-link and
driving a switch on MDIO (case "2" above). This needs a MDIO bus to
be created:

    &fec1 {
            phy-mode = "rmii";

            fixed-link {
                    speed = <100>;
                    full-duplex;
            };

            mdio1: mdio {
                    switch0: switch0 at 0 {
                            compatible = "marvell,mv88e6190";
                            pinctrl-0 = <&pinctrl_gpio_switch0>;
                    };
            };
    };

Here's[1] an example where there is no MDIO bus or fixed-link for
the ethernet1 MAC, so no MDIO bus should be created since ethernet0
is the MDIO master for ethernet1's phy:

    &ethernet0 {
            phy-mode = "sgmii";
            phy-handle = <&sgmii_phy0>;

            mdio {
                    compatible = "snps,dwmac-mdio";
                    sgmii_phy0: phy at 8 {
                            compatible = "ethernet-phy-id0141.0dd4";
                            reg = <0x8>;
                            device_type = "ethernet-phy";
                    };

                    sgmii_phy1: phy at a {
                            compatible = "ethernet-phy-id0141.0dd4";
                            reg = <0xa>;
                            device_type = "ethernet-phy";
                    };
            };
    };

    &ethernet1 {
            phy-mode = "sgmii";
            phy-handle = <&sgmii_phy1>;
    };

Finally there's descriptions like this[2] which don't describe the
MDIO bus but expect it to be created and the whole address space
scanned for a phy since there's no phy-handle or fixed-link described:

    &gmac {
            phy-supply = <&vcc_lan>;
            phy-mode = "rmii";
            snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
            snps,reset-active-low;
            snps,reset-delays-us = <0 10000 1000000>;
    };

[0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts
[1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
[2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164

Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 85 ++++++++++------------
 1 file changed, 37 insertions(+), 48 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1ffde555da47..7da461fe93f6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -296,69 +296,39 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
 }
 
 /**
- * stmmac_dt_phy - parse device-tree driver parameters to allocate PHY resources
- * @plat: driver data platform structure
- * @np: device tree node
- * @dev: device pointer
- * Description:
- * The mdio bus will be allocated in case of a phy transceiver is on board;
- * it will be NULL if the fixed-link is configured.
- * If there is the "snps,dwmac-mdio" sub-node the mdio will be allocated
- * in any case (for DSA, mdio must be registered even if fixed-link).
- * The table below sums the supported configurations:
- *	-------------------------------
- *	snps,phy-addr	|     Y
- *	-------------------------------
- *	phy-handle	|     Y
- *	-------------------------------
- *	fixed-link	|     N
- *	-------------------------------
- *	snps,dwmac-mdio	|
- *	  even if	|     Y
- *	fixed-link	|
- *	-------------------------------
+ * stmmac_of_get_mdio() - Gets the MDIO bus from the devicetree
+ * @np: devicetree node
  *
- * It returns 0 in case of success otherwise -ENODEV.
+ * The MDIO bus will be searched for in the following ways:
+ * 1. The compatible is "snps,dwc-qos-ethernet-4.10" && a "mdio" named
+ *    child node exists
+ * 2. A child node with the "snps,dwmac-mdio" compatible is present
+ *
+ * Return: The MDIO node if present otherwise NULL
  */
-static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
-			 struct device_node *np, struct device *dev)
+static struct device_node *stmmac_of_get_mdio(struct device_node *np)
 {
-	bool mdio = !of_phy_is_fixed_link(np);
 	static const struct of_device_id need_mdio_ids[] = {
 		{ .compatible = "snps,dwc-qos-ethernet-4.10" },
 		{},
 	};
+	struct device_node *mdio_node = NULL;
 
 	if (of_match_node(need_mdio_ids, np)) {
-		plat->mdio_node = of_get_child_by_name(np, "mdio");
+		mdio_node = of_get_child_by_name(np, "mdio");
 	} else {
 		/**
 		 * If snps,dwmac-mdio is passed from DT, always register
 		 * the MDIO
 		 */
-		for_each_child_of_node(np, plat->mdio_node) {
-			if (of_device_is_compatible(plat->mdio_node,
+		for_each_child_of_node(np, mdio_node) {
+			if (of_device_is_compatible(mdio_node,
 						    "snps,dwmac-mdio"))
 				break;
 		}
 	}
 
-	if (plat->mdio_node) {
-		dev_dbg(dev, "Found MDIO subnode\n");
-		mdio = true;
-	}
-
-	if (mdio) {
-		plat->mdio_bus_data =
-			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
-				     GFP_KERNEL);
-		if (!plat->mdio_bus_data)
-			return -ENOMEM;
-
-		plat->mdio_bus_data->needs_reset = true;
-	}
-
-	return 0;
+	return mdio_node;
 }
 
 /**
@@ -417,6 +387,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
 	struct device_node *np = pdev->dev.of_node;
 	struct plat_stmmacenet_data *plat;
 	struct stmmac_dma_cfg *dma_cfg;
+	bool legacy_mdio;
 	int phy_mode;
 	void *ret;
 	int rc;
@@ -471,10 +442,28 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
 	if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
 		dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
 
-	/* To Configure PHY by using all device-tree supported properties */
-	rc = stmmac_dt_phy(plat, np, &pdev->dev);
-	if (rc)
-		return ERR_PTR(rc);
+	plat->mdio_node = stmmac_of_get_mdio(np);
+	if (plat->mdio_node)
+		dev_dbg(&pdev->dev, "Found MDIO subnode\n");
+
+	/* Legacy devicetrees allowed for no MDIO bus description and expect
+	 * the bus to be scanned for devices. If there's no phy or fixed-link
+	 * described assume this is the case since there must be something
+	 * connected to the MAC.
+	 */
+	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
+	if (legacy_mdio)
+		dev_info(&pdev->dev, "Deprecated MDIO bus assumption used\n");
+
+	if (plat->mdio_node || legacy_mdio) {
+		plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
+						   sizeof(struct stmmac_mdio_bus_data),
+						   GFP_KERNEL);
+		if (!plat->mdio_bus_data)
+			return ERR_PTR(-ENOMEM);
+
+		plat->mdio_bus_data->needs_reset = true;
+	}
 
 	of_property_read_u32(np, "tx-fifo-depth", &plat->tx_fifo_size);
 

---
base-commit: fd8a79b63710acb84321be3ce74be23c876873fb
change-id: 20231127-stmmac-no-mdio-node-1db9da8a25d9

Best regards,
-- 
Andrew Halaney <ahalaney at redhat.com>



From ahalaney at redhat.com  Wed Dec  6 15:58:40 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Wed, 6 Dec 2023 17:58:40 -0600
Subject: [PATCH net-next v2] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
References: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
Message-ID: <nmkpcss5pymkjitcf2o3pwu3r2rbu3kfy2ubtkpmktw6worj5p@rk5aljx6slwi>

On Wed, Dec 06, 2023 at 05:46:09PM -0600, Andrew Halaney wrote:
> The stmmac_dt_phy() function, which parses the devicetree node of the
> MAC and ultimately causes MDIO bus allocation, misinterprets what
> fixed-link means in relation to the MAC's MDIO bus. This results in
> a MDIO bus being created in situations it need not be.
> 
> Currently a MDIO bus is created if the description is either:
> 
>     1. Not fixed-link
>     2. fixed-link but contains a MDIO bus as well
> 
> The "1" case above isn't always accurate. If there's a phy-handle,
> it could be referencing a phy on another MDIO controller's bus[1]. In
> this case currently the MAC will make a MDIO bus and scan it all
> anyways unnecessarily.
> 
> There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> be created and scanned for a phy. This case can also be inferred from
> the platform description by not having a phy-handle && not being
> fixed-link. This hits case "1" in the current driver's logic.
> 
> Let's improve the logic to create a MDIO bus if either:
> 
>     - Devicetree contains a MDIO bus
>     - !fixed-link && !phy-handle (legacy handling)
> 
> Below upstream devicetree snippets can be found that explain some of
> the cases above more concretely.
> 
> Here's[0] a devicetree example where the MAC is both fixed-link and
> driving a switch on MDIO (case "2" above). This needs a MDIO bus to
> be created:
> 
>     &fec1 {
>             phy-mode = "rmii";
> 
>             fixed-link {
>                     speed = <100>;
>                     full-duplex;
>             };
> 
>             mdio1: mdio {
>                     switch0: switch0 at 0 {
>                             compatible = "marvell,mv88e6190";
>                             pinctrl-0 = <&pinctrl_gpio_switch0>;
>                     };
>             };
>     };
> 
> Here's[1] an example where there is no MDIO bus or fixed-link for
> the ethernet1 MAC, so no MDIO bus should be created since ethernet0
> is the MDIO master for ethernet1's phy:
> 
>     &ethernet0 {
>             phy-mode = "sgmii";
>             phy-handle = <&sgmii_phy0>;
> 
>             mdio {
>                     compatible = "snps,dwmac-mdio";
>                     sgmii_phy0: phy at 8 {
>                             compatible = "ethernet-phy-id0141.0dd4";
>                             reg = <0x8>;
>                             device_type = "ethernet-phy";
>                     };
> 
>                     sgmii_phy1: phy at a {
>                             compatible = "ethernet-phy-id0141.0dd4";
>                             reg = <0xa>;
>                             device_type = "ethernet-phy";
>                     };
>             };
>     };
> 
>     &ethernet1 {
>             phy-mode = "sgmii";
>             phy-handle = <&sgmii_phy1>;
>     };
> 
> Finally there's descriptions like this[2] which don't describe the
> MDIO bus but expect it to be created and the whole address space
> scanned for a phy since there's no phy-handle or fixed-link described:
> 
>     &gmac {
>             phy-supply = <&vcc_lan>;
>             phy-mode = "rmii";
>             snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
>             snps,reset-active-low;
>             snps,reset-delays-us = <0 10000 1000000>;
>     };
> 
> [0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts
> [1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
> [2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164
> 
> Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
> ---

Gah, I failed to describe my changes since Bart's v1 when picking this
up with b4 to make v2. Whoops!

Changes since v1:
    - Handle the fixed-link + mdio case (Andrew Lunn)
    - Reworded commit message
    - Handle the "legacy" case still mentioned in the commit
    - Bit further refactoring of the function



From daniel at makrotopia.org  Wed Dec  6 16:07:14 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Thu, 7 Dec 2023 00:07:14 +0000
Subject: [RFC PATCH v2 3/8] net: pcs: pcs-mtk-lynxi: add platform driver
 for MT7988
In-Reply-To: <ZXC0pq2C6iRmeF4B@shell.armlinux.org.uk>
References: <cover.1701826319.git.daniel@makrotopia.org>
 <68bb81ac6bf99393c8de256f42e5715626590af8.1701826319.git.daniel@makrotopia.org>
 <ZXC0pq2C6iRmeF4B@shell.armlinux.org.uk>
Message-ID: <ZXEMsugMy6_gPRRi@makrotopia.org>

On Wed, Dec 06, 2023 at 05:51:34PM +0000, Russell King (Oracle) wrote:
> On Wed, Dec 06, 2023 at 01:44:17AM +0000, Daniel Golle wrote:
> > +struct phylink_pcs *mtk_pcs_lynxi_select_pcs(struct device_node *np, phy_interface_t mode)
> > +{
> > +	struct platform_device *pdev;
> > +	struct mtk_pcs_lynxi *mpcs;
> > +
> > +	if (!np)
> > +		return NULL;
> > +
> > +	if (!of_device_is_available(np))
> > +		return ERR_PTR(-ENODEV);
> > +
> > +	if (!of_match_node(mtk_pcs_lynxi_of_match, np))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	pdev = of_find_device_by_node(np);
> > +	if (!pdev || !platform_get_drvdata(pdev)) {
> > +		if (pdev)
> > +			put_device(&pdev->dev);
> > +		return ERR_PTR(-EPROBE_DEFER);
> > +	}
> > +
> > +	mpcs = platform_get_drvdata(pdev);
> > +	put_device(&pdev->dev);
> > +
> > +	return &mpcs->pcs;
> > +}
> > +EXPORT_SYMBOL(mtk_pcs_lynxi_select_pcs);
> 
> If you're going to play games like this, then you must mark the driver
> with .suppress_bind_attrs = true to remove the bind/unbind attributes
> in userspace that could wreak havoc with the above - because there is
> _nothing_ that guarantees that the memory you're returning from this
> function will remain intact. Basically, it's racy.

Ack, I've set .suppress_bind_attrs = true in the usxgmii driver but
forgot to add it here.

> Also, I'm not sure I approve of using the "select_pcs" suffix (I
> haven't spotted _where_ you use this, but returning EPROBE_DEFER to
> phylink's mac_select_pcs() method doesn't do anything to defer any
> probe, so that's an entirely misleading error code.

EPROBE_DEFER is handled when the function is called by mtk_add_mac()
during probe of the Ethernet driver -- which we do want to postpone
in case the PCS hasn't been probed yet as at this point that's the
best we can do without adding lots of intrastructure to dynamically
attach the PCS later on...

But true, later the function is being called by mac_select_pcs() and
what ever it returns is returned to the caller of mac_select_pcs().
If you think it's better to return ENODEV (or EAGAIN?) I can change
that -- from what I could tell, the only error which receives special
handling by phylink is -EOPNOTSUPP, everything else just gets passed-
through to the callers.

> If we are going to have device drivers for PCS, then we need to
> seriously think about how we look up PCS and return the phylink_pcs
> pointer - and also how we handle the PCS device going away. None of
> that should be coded into _any_ PCS driver.

I agree -- just wasn't up to design and implement all that at once.


From joel at jms.id.au  Wed Dec  6 16:10:17 2023
From: joel at jms.id.au (Joel Stanley)
Date: Thu, 7 Dec 2023 10:40:17 +1030
Subject: [PATCH v6 2/2] ARM: dts: aspeed: Harma: Add Facebook Harma
 (AST2600) BMC
In-Reply-To: <20231206155316.4181813-3-peteryin.openbmc@gmail.com>
References: <20231206155316.4181813-1-peteryin.openbmc@gmail.com> <20231206155316.4181813-3-peteryin.openbmc@gmail.com>
Message-ID: <CACPK8XepWC+KUaYr8nQJ9ggkX5n=aQzT_U5+u_N86=LthkbwDw@mail.gmail.com>

On Thu, 7 Dec 2023 at 02:25, Peter Yin <peteryin.openbmc at gmail.com> wrote:
>
> Add linux device tree entry related to
> Harma specific devices connected to BMC SoC.

This isn't a very helpful commit message. Convention is to mention
what the system is to give context; eg "The SuperCorp Machine1
multi-node server system uses an AST2600 BMC".

> +&mac3 {
> +       status = "okay";
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_rmii4_default>;
> +       no-hw-checksum;
> +       use-ncsi;
> +       ncsi-ctrl,start-redo-probe;
> +       ncsi-ctrl,no-channel-monitor;
> +       mlx,multi-host;
> +       ncsi-package = <1>;
> +       ncsi-channel = <1>;
> +       ncsi-rexmit = <1>;
> +       ncsi-timeout = <2>;

These properties are not supported by the kernel. It seems Facebook
uses them in their machines, it would be great if you contributed
support for them to mainline.

If not, please drop the properties.

> +
> +&gpio0 {
> +       pinctrl-names = "default";
> +       gpio-line-names =
> +       /*A0-A7*/       "","","","","","","","",
> +       /*B0-B7*/       "","","","",
> +                       "FM_BMC_MUX_CS_SPI_SEL_0","FM_ID_LED_N","","",
> +       /*C0-C7*/       "","","","","","","","",
> +       /*D0-D7*/       "","","SOL_UART_SET","","","","","",
> +       /*E0-E7*/       "","","","","","","","",
> +       /*F0-F7*/       "","","","","","","","",
> +       /*G0-G7*/       "","","","","","","","",
> +       /*H0-H7*/       "","","","","","","","",
> +       /*I0-I7*/       "","","","","","","","",
> +       /*J0-J7*/       "","","","","","","","",
> +       /*K0-K7*/       "","","","","","","","",
> +       /*L0-L7*/       "","","","","","","","",
> +       /*M0-M7*/       "","","","","","","","",
> +       /*N0-N7*/       "LED_POSTCODE_0","LED_POSTCODE_1",
> +                       "LED_POSTCODE_2","LED_POSTCODE_3",
> +                       "LED_POSTCODE_4","LED_POSTCODE_5",
> +                       "LED_POSTCODE_6","LED_POSTCODE_7",
> +       /*O0-O7*/       "","","","","","","","",
> +       /*P0-P7*/       "FP_SYS_PWRBTN_IN_N","BMC_SYS_PWRBTN_OUT_N",

Is this machine going to run openbmc?

We have a set of documented properties for GPIOs such as the power button:

https://github.com/openbmc/docs/blob/master/designs/device-tree-gpio-naming.md

If you intentionally do not want to follow this scheme, please mention
why in your commit message.

Cheers,

Joel


From shawnguo at kernel.org  Wed Dec  6 16:52:02 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 7 Dec 2023 08:52:02 +0800
Subject: [GIT PULL] i.MX fixes for 6.7
Message-ID: <20231207005202.GF270430@dragon>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-6.7

for you to fetch changes up to 63ef8fc9bcee6b73ca445a19a7ac6bd544723c9f:

  ARM: dts: imx28-xea: Pass the 'model' property (2023-12-06 17:23:58 +0800)

----------------------------------------------------------------
i.MX fixes for 6.7:

- A MAINTAINERS update to reinstate freescale ARM64 DT directory in i.MX
  entry.
- A series from Alexander Stein to fix #pwm-cells for imx8-ss.
- A series from Haibo Chen to fix GPIO node name for i.MX93 and
  i.MX8ULP.
- Add parkmode-disable-ss-quirk for DWC3 on i.MX8MP and i.MX8MQ to fix
  an issue that the controller may hang when processing transactions
  under heavy USB traffic from multiple endpoints.
- Fix mediamix block power on/off for i.MX93 by correcting the power
  domain clock to be 'nic_media'.
- A couple of Ethernet PHY clock regression fixes for imx6ul-pico and
  imx6q-skov board.
- Fix edma3 power domain for i.MX8QM to fix a panic during startup
  process.

----------------------------------------------------------------
Ahmad Fatoum (1):
      MAINTAINERS: reinstate freescale ARM64 DT directory in i.MX entry

Alexander Stein (4):
      arm64: dt: imx93: tqma9352-mba93xxla: Fix LPUART2 pad config
      dt-bindings: pwm: imx-pwm: Unify #pwm-cells for all compatibles
      arm64: dts: freescale: imx8-ss-lsio: Fix #pwm-cells
      arm64: dts: freescale: imx8-ss-dma: Fix #pwm-cells

Fabio Estevam (2):
      ARM: dts: imx6ul-pico: Describe the Ethernet PHY clock
      ARM: dts: imx28-xea: Pass the 'model' property

Haibo Chen (2):
      arm64: dts: imx93: update gpio node name to align with register address
      arm64: dts: imx8ulp: update gpio node name to align with register address

Kunwu Chan (1):
      ARM: imx: Check return value of devm_kasprintf in imx_mmdc_perf_init

Nathan Rossi (1):
      arm64: dts: imx8mp: imx8mq: Add parkmode-disable-ss-quirk on DWC3

Peng Fan (1):
      arm64: dts: imx93: correct mediamix power

Philipp Zabel (1):
      ARM: dts: imx7: Declare timers compatible with fsl,imx6dl-gpt

Stefan Eichenberger (1):
      arm64: dts: imx8-apalis: set wifi regulator to always-on

Stefan Kerkmann (1):
      ARM: dts: imx6q: skov: fix ethernet clock regression

Xiaolei Wang (1):
      arm64: dts: imx8qm: Add imx8qm's own pm to avoid panic during startup

 Documentation/devicetree/bindings/pwm/imx-pwm.yaml           | 10 ++++------
 MAINTAINERS                                                  |  1 +
 arch/arm/boot/dts/nxp/imx/imx6q-skov-reve-mi1010ait-1cp1.dts |  4 ++--
 arch/arm/boot/dts/nxp/imx/imx6ul-pico.dtsi                   |  2 ++
 arch/arm/boot/dts/nxp/imx/imx7s.dtsi                         |  8 ++++----
 arch/arm/boot/dts/nxp/mxs/imx28-xea.dts                      |  1 +
 arch/arm/mach-imx/mmdc.c                                     |  7 ++++++-
 arch/arm64/boot/dts/freescale/imx8-apalis-v1.1.dtsi          |  5 +----
 arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi               |  2 +-
 arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi              |  8 ++++----
 arch/arm64/boot/dts/freescale/imx8mp.dtsi                    |  2 ++
 arch/arm64/boot/dts/freescale/imx8mq.dtsi                    |  2 ++
 arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi             | 11 +++++++++++
 arch/arm64/boot/dts/freescale/imx8ulp.dtsi                   |  6 +++---
 arch/arm64/boot/dts/freescale/imx93-tqma9352-mba93xxla.dts   |  2 +-
 arch/arm64/boot/dts/freescale/imx93.dtsi                     | 10 +++++-----
 16 files changed, 50 insertions(+), 31 deletions(-)


From bvanassche at acm.org  Wed Dec  6 17:02:04 2023
From: bvanassche at acm.org (Bart Van Assche)
Date: Wed, 6 Dec 2023 15:02:04 -1000
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231206153242.GI12802@thinkpad>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
 <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>
 <5e7c5c75-cb5f-4afe-9d57-b0cab01a6f26@acm.org>
 <b9373252-710c-4a54-95cc-046314796960@quicinc.com>
 <20231206153242.GI12802@thinkpad>
Message-ID: <effb603e-ca7a-4f24-9783-4d62790165ae@acm.org>

On 12/6/23 05:32, Manivannan Sadhasivam wrote:
> On Wed, Dec 06, 2023 at 07:32:54PM +0530, Naresh Maramaina wrote:
>> On 12/5/2023 10:41 PM, Bart Van Assche wrote:
>>> On 12/4/23 21:58, Naresh Maramaina wrote:
>>>> On 12/5/2023 12:30 AM, Bart Van Assche wrote:
>>>>> On 12/4/23 06:30, Maramaina Naresh wrote:
>>>>>> +??? /* This capability allows the host controller driver to
>>>>>> use the PM QoS
>>>>>> +???? * feature.
>>>>>> +???? */
>>>>>> +??? UFSHCD_CAP_PM_QOS??????????????? = 1 << 13,
>>>>>>  ? };
>>>>>
>>>>> Why does it depend on the host driver whether or not PM QoS is
>>>>> enabled? Why isn't it enabled unconditionally?
>>>>
>>>> For some platform vendors power KPI might be more important than
>>>> random io KPI. Hence this flag is disabled by default and can be
>>>> enabled based on platform requirement.
>>>
>>> How about leaving this flag out unless if a host vendor asks explicitly
>>> for this flag?
>>
>> IMHO, instead of completely removing this flag, how about having
>> flag like "UFSHCD_CAP_DISABLE_PM_QOS" which will make PMQOS enable
>> by default and if some host vendor wants to disable it explicitly,
>> they can enable that flag.
>> Please let me know your opinion.

That would result in a flag that is tested but that is never set by
upstream code. I'm not sure that's acceptable.

> If a vendor wants to disable this feature, then the driver has to be modified.
> That won't be very convenient. So either this has to be configured through sysfs
> or Kconfig if flexibility matters.

Kconfig sounds worse to me because changing any Kconfig flag requires a
modification of the Android GKI kernel.

Thanks,

Bart.


From jmattson at google.com  Wed Dec  6 17:03:02 2023
From: jmattson at google.com (Jim Mattson)
Date: Wed,  6 Dec 2023 17:03:02 -0800
Subject: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()
In-Reply-To: <20220921003201.1441511-11-seanjc@google.com>
References: <20220921003201.1441511-11-seanjc@google.com>
Message-ID: <20231207010302.2240506-1-jmattson@google.com>

kvm_vcpu_check_block() is called while not in TASK_RUNNING, and therefore
it cannot sleep.  Writing to guest memory is therefore forbidden, but it
can happen on AMD processors if kvm_check_nested_events() causes a vmexit.

Fortunately, all events that are caught by kvm_check_nested_events() are
also recognized by kvm_vcpu_has_events() through vendor callbacks such as
kvm_x86_interrupt_allowed() or kvm_x86_ops.nested_ops->has_events(), so
remove the call and postpone the actual processing to vcpu_block().

Opportunistically honor the return of kvm_check_nested_events().  KVM
punted on the check in kvm_vcpu_running() because the only error path is
if vmx_complete_nested_posted_interrupt() fails, in which case KVM exits
to userspace with "internal error" i.e. the VM is likely dead anyways so
it wasn't worth overloading the return of kvm_vcpu_running().

Add the check mostly so that KVM is consistent with itself; the return of
the call via kvm_apic_accept_events()=>kvm_check_nested_events() that
immediately follows  _is_ checked.

Reported-by: Maxim Levitsky <mlevitsk at redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini at redhat.com>
[sean: check and handle return of kvm_check_nested_events()]
Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 arch/x86/kvm/x86.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dcc675d4e44b..8aeacbc2bff9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -10815,6 +10815,17 @@ static inline int vcpu_block(struct kvm_vcpu *vcpu)
 			return 1;
 	}
 
+	/*
+	 * Evaluate nested events before exiting the halted state.  This allows
+	 * the halt state to be recorded properly in the VMCS12's activity
+	 * state field (AMD does not have a similar field and a VM-Exit always
+	 * causes a spurious wakeup from HLT).
+	 */
+	if (is_guest_mode(vcpu)) {
+		if (kvm_check_nested_events(vcpu) < 0)
+			return 0;
+	}
+
 	if (kvm_apic_accept_events(vcpu) < 0)
 		return 0;
 	switch(vcpu->arch.mp_state) {
@@ -10837,9 +10848,6 @@ static inline int vcpu_block(struct kvm_vcpu *vcpu)
 
 static inline bool kvm_vcpu_running(struct kvm_vcpu *vcpu)
 {
-	if (is_guest_mode(vcpu))
-		kvm_check_nested_events(vcpu);
-
 	return (vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE &&
 		!vcpu->arch.apf.halted);
 }

This commit breaks delivery of a (virtualized) posted interrupt from
an L1 vCPU to a halted L2 vCPU.

Looking back at commit e6c67d8cf117 ("KVM: nVMX: Wake blocked vCPU in
guest-mode if pending interrupt in virtual APICv"), Liran wrote:

    Note that this also handles the case of nested posted-interrupt by the
    fact RVI is updated in vmx_complete_nested_posted_interrupt() which is
    called from kvm_vcpu_check_block() -> kvm_arch_vcpu_runnable() ->
    kvm_vcpu_running() -> vmx_check_nested_events() ->
    vmx_complete_nested_posted_interrupt().

Clearly, that is no longer the case.


From Liam.Howlett at Oracle.com  Wed Dec  6 17:41:04 2023
From: Liam.Howlett at Oracle.com (Liam R. Howlett)
Date: Wed, 6 Dec 2023 20:41:04 -0500
Subject: WARNING: CPU: 6 PID: 474 at include/linux/maple_tree.h:712
 mmap_region (include/linux/maple_tree.h:556 include/linux/maple_tree.h:731
In-Reply-To: <202312061435.E57F367C16@keescook>
References: <CA+G9fYs-j2FYZSFSVZj48mgoM9gQd4-7M2mu2Ez3D1DqDdW2bQ@mail.gmail.com>
 <ZUzmlhvRv66I3J6P@finisterre.sirena.org.uk>
 <B4299DC4-57CF-4CB2-ACB1-A215F429BF6A@kernel.org>
 <202312061435.E57F367C16@keescook>
Message-ID: <20231207014104.n6vul2ylgqjnsfia@revolver>

* Kees Cook <keescook at chromium.org> [231206 17:38]:
> On Thu, Nov 09, 2023 at 09:45:26PM -0800, Kees Cook wrote:
> > 
> > 
> > On November 9, 2023 6:03:02 AM PST, Mark Brown <broonie at kernel.org> wrote:
> > >On Thu, Nov 09, 2023 at 06:57:08PM +0530, Naresh Kamboju wrote:
> > >> Following kernel panic noticed while running  selftests: exec: load_address
> > >> on Fastmodels (FVP) running Linux next-20231109.
> > >> 
> > >
> > >Copying in Kees and Eric who maintain the exec API.
> > 
> > I'm traveling tomorrow so I won't be able to investigate this for a couple days. A quick look makes it seem like this is only happening in -next? (This warning was recently added to __mas_set_range?)
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/include/linux/maple_tree.h?id=02eccbc51164b43c5dadc3e5b40922c757075e08
> > 
> > Adding Liam...
> 
> Did this get addressed? I still see the warning checks in
> __mas_set_range()...

Sorry, I missed your first email somehow.

I'll look into it.

Thanks,
Liam


From ilkka at os.amperecomputing.com  Wed Dec  6 18:15:45 2023
From: ilkka at os.amperecomputing.com (Ilkka Koskinen)
Date: Wed, 6 Dec 2023 18:15:45 -0800 (PST)
Subject: [PATCH 3/5] perf/arm_cspmu: Simplify counter reset
In-Reply-To: <34ecf45f0f9a0fa34a580f162f02c23d9b849d90.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com> <34ecf45f0f9a0fa34a580f162f02c23d9b849d90.1701793996.git.robin.murphy@arm.com>
Message-ID: <b5d7abb5-443c-f66c-901d-232d2ff3264b@os.amperecomputing.com>


On Tue, 5 Dec 2023, Robin Murphy wrote:
> arm_cspmu_reset_counters() inherently also stops them since it is
> writing 0 to PMCR.E, so there should be no need to do that twice.
> Also tidy up the reset routine itself for consistency with the start
> and stop routines, and to be clear at first glance that it is simply
> writing a constant value.
>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>


Reviewed-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>

Cheers, Ilkka


> ---
> drivers/perf/arm_cspmu/arm_cspmu.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
> index f7aa2ac5fd88..b64de4d800c7 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> @@ -525,11 +525,7 @@ static int arm_cspmu_alloc_attr_groups(struct arm_cspmu *cspmu)
>
> static inline void arm_cspmu_reset_counters(struct arm_cspmu *cspmu)
> {
> -	u32 pmcr = 0;
> -
> -	pmcr |= PMCR_P;
> -	pmcr |= PMCR_C;
> -	writel(pmcr, cspmu->base0 + PMCR);
> +	writel(PMCR_C | PMCR_P, cspmu->base0 + PMCR);
> }
>
> static inline void arm_cspmu_start_counters(struct arm_cspmu *cspmu)
> @@ -1189,7 +1185,6 @@ static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
> 	};
>
> 	/* Hardware counter init */
> -	arm_cspmu_stop_counters(cspmu);
> 	arm_cspmu_reset_counters(cspmu);
>
> 	ret = perf_pmu_register(&cspmu->pmu, cspmu->name, -1);
> -- 
> 2.39.2.101.g768bb238c484.dirty
>
>


From ilkka at os.amperecomputing.com  Wed Dec  6 18:16:20 2023
From: ilkka at os.amperecomputing.com (Ilkka Koskinen)
Date: Wed, 6 Dec 2023 18:16:20 -0800 (PST)
Subject: [PATCH 1/5] perf/arm_cspmu: Simplify initialisation
In-Reply-To: <9842b71263a0a5e7ebb9aebb5f9ac15e1e24ff65.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com> <9842b71263a0a5e7ebb9aebb5f9ac15e1e24ff65.1701793996.git.robin.murphy@arm.com>
Message-ID: <d8c73013-7250-2589-79db-602490a46086@os.amperecomputing.com>


On Tue, 5 Dec 2023, Robin Murphy wrote:
> It's far simpler for implementations to literally override whichever
> default ops they want to, by initialising to the default ops first. This
> saves all the bother of checking what the impl_init_ops call has or
> hasn't touched. Make the same clear distinction for the PMIIDR override
> as well, in case we gain more sources for overriding that in future.
>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>

Reviewed-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>

Cheers, Ilkka


> ---
> drivers/perf/arm_cspmu/arm_cspmu.c    | 55 +++++++++++----------------
> drivers/perf/arm_cspmu/nvidia_cspmu.c |  6 ---
> 2 files changed, 22 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
> index 2cc35dded007..a3347b1287e6 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> @@ -100,13 +100,6 @@
> #define ARM_CSPMU_ACTIVE_CPU_MASK		0x0
> #define ARM_CSPMU_ASSOCIATED_CPU_MASK		0x1
>
> -/* Check and use default if implementer doesn't provide attribute callback */
> -#define CHECK_DEFAULT_IMPL_OPS(ops, callback)			\
> -	do {							\
> -		if (!ops->callback)				\
> -			ops->callback = arm_cspmu_ ## callback;	\
> -	} while (0)
> -
> /*
>  * Maximum poll count for reading counter value using high-low-high sequence.
>  */
> @@ -408,21 +401,32 @@ static struct arm_cspmu_impl_match *arm_cspmu_impl_match_get(u32 pmiidr)
> 	return NULL;
> }
>
> +#define DEFAULT_IMPL_OP(name)	.name = arm_cspmu_##name
> +
> static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
> {
> 	int ret = 0;
> -	struct arm_cspmu_impl_ops *impl_ops = &cspmu->impl.ops;
> 	struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(cspmu->dev);
> 	struct arm_cspmu_impl_match *match;
>
> -	/*
> -	 * Get PMU implementer and product id from APMT node.
> -	 * If APMT node doesn't have implementer/product id, try get it
> -	 * from PMIIDR.
> -	 */
> -	cspmu->impl.pmiidr =
> -		(apmt_node->impl_id) ? apmt_node->impl_id :
> -				       readl(cspmu->base0 + PMIIDR);
> +	/* Start with a default PMU implementation */
> +	cspmu->impl.module = THIS_MODULE;
> +	cspmu->impl.pmiidr = readl(cspmu->base0 + PMIIDR);
> +	cspmu->impl.ops = (struct arm_cspmu_impl_ops) {
> +		DEFAULT_IMPL_OP(get_event_attrs),
> +		DEFAULT_IMPL_OP(get_format_attrs),
> +		DEFAULT_IMPL_OP(get_identifier),
> +		DEFAULT_IMPL_OP(get_name),
> +		DEFAULT_IMPL_OP(is_cycle_counter_event),
> +		DEFAULT_IMPL_OP(event_type),
> +		DEFAULT_IMPL_OP(event_filter),
> +		DEFAULT_IMPL_OP(set_ev_filter),
> +		DEFAULT_IMPL_OP(event_attr_is_visible),
> +	};
> +
> +	/* Firmware may override implementer/product ID from PMIIDR */
> +	if (apmt_node->impl_id)
> +		cspmu->impl.pmiidr = apmt_node->impl_id;
>
> 	/* Find implementer specific attribute ops. */
> 	match = arm_cspmu_impl_match_get(cspmu->impl.pmiidr);
> @@ -450,24 +454,9 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
> 		}
>
> 		mutex_unlock(&arm_cspmu_lock);
> +	}
>
> -		if (ret)
> -			return ret;
> -	} else
> -		cspmu->impl.module = THIS_MODULE;
> -
> -	/* Use default callbacks if implementer doesn't provide one. */
> -	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_event_attrs);
> -	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_format_attrs);
> -	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_identifier);
> -	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_name);
> -	CHECK_DEFAULT_IMPL_OPS(impl_ops, is_cycle_counter_event);
> -	CHECK_DEFAULT_IMPL_OPS(impl_ops, event_type);
> -	CHECK_DEFAULT_IMPL_OPS(impl_ops, event_filter);
> -	CHECK_DEFAULT_IMPL_OPS(impl_ops, event_attr_is_visible);
> -	CHECK_DEFAULT_IMPL_OPS(impl_ops, set_ev_filter);
> -
> -	return 0;
> +	return ret;
> }
>
> static struct attribute_group *
> diff --git a/drivers/perf/arm_cspmu/nvidia_cspmu.c b/drivers/perf/arm_cspmu/nvidia_cspmu.c
> index 0382b702f092..5b84b701ad62 100644
> --- a/drivers/perf/arm_cspmu/nvidia_cspmu.c
> +++ b/drivers/perf/arm_cspmu/nvidia_cspmu.c
> @@ -388,12 +388,6 @@ static int nv_cspmu_init_ops(struct arm_cspmu *cspmu)
> 	impl_ops->get_format_attrs		= nv_cspmu_get_format_attrs;
> 	impl_ops->get_name			= nv_cspmu_get_name;
>
> -	/* Set others to NULL to use default callback. */
> -	impl_ops->event_type			= NULL;
> -	impl_ops->event_attr_is_visible		= NULL;
> -	impl_ops->get_identifier		= NULL;
> -	impl_ops->is_cycle_counter_event	= NULL;
> -
> 	return 0;
> }
>
> -- 
> 2.39.2.101.g768bb238c484.dirty
>
>


From keith.zhao at starfivetech.com  Wed Dec  6 18:16:57 2023
From: keith.zhao at starfivetech.com (Keith Zhao)
Date: Thu, 7 Dec 2023 10:16:57 +0800
Subject: [PATCH v1 0/2] Add waveshare 7inch touchscreen panel support
In-Reply-To: <CAPY8ntCw_-QG_v-KGipshq09sZ1fD3yascrHcLz3TYREmnk0sA@mail.gmail.com>
References: <20231124104451.44271-1-shengyang.chen@starfivetech.com>
 <dab03c60-caa9-47e3-9dac-fa499227b67b@gmx.net>
 <CAPY8ntAXYVTTfXL5HX-14t-VDe63eFgRBNKA0aG3RamKepxwDQ@mail.gmail.com>
 <5b837622-3ac9-47d5-aaf1-6b1ef5144c1c@starfivetech.com>
 <CAPY8ntCw_-QG_v-KGipshq09sZ1fD3yascrHcLz3TYREmnk0sA@mail.gmail.com>
Message-ID: <a6468707-583f-4ce9-837d-16bb9079a0f6@starfivetech.com>



On 2023/12/6 22:56, Dave Stevenson wrote:
> Hi Keith
> 
> On Wed, 6 Dec 2023 at 08:55, Keith Zhao <keith.zhao at starfivetech.com> wrote:
>>
>>
>>
>> On 2023/11/25 0:04, Dave Stevenson wrote:
>> > On Fri, 24 Nov 2023 at 15:00, Stefan Wahren <wahrenst at gmx.net> wrote:
>> >>
>> >> Hi Shengyang,
>> >>
>> >> [fix address of Emma]
>> >
>> > Not merged to master yet, but Emma has stepped back from maintenance.
>> > https://lists.freedesktop.org/archives/dri-devel/2023-October/428829.html
>> > Dropped from the cc.
>> >
>> >> Am 24.11.23 um 11:44 schrieb Shengyang Chen:
>> >> > This patchset adds waveshare 7inch touchscreen panel support
>> >> > for the StarFive JH7110 SoC.
>> >> >
>> >> > Patch 1 add new compatible for the raspberrypi panel driver and its dt-binding.
>> >> > Patch 2 add new display mode and new probing process for raspberrypi panel driver.
>> >> >
>> >> > Waveshare 7inch touchscreen panel is a kind of raspberrypi panel
>> >> > which can be drived by raspberrypi panel driver.
>> >> >
>> >> > The series has been tested on the VisionFive 2 board.
>> >> surprisingly i was recently working on the official Raspberry Pi
>> >> touchscreen and was able to get it running the new way.
>> >>
>> >> What do i mean with the new way. There is almost nothing special to the
>> >> Raspberry Pi touchscreen, so we should try to use/extend existing
>> >> components like:
>> >>
>> >> CONFIG_DRM_PANEL_SIMPLE
>> >> CONFIG_TOUCHSCREEN_EDT_FT5X06
>> >> CONFIG_DRM_TOSHIBA_TC358762
>> >>
>> >> The only special part is the Attiny on the connector PCB which requires:
>> >>
>> >> CONFIG_REGULATOR_RASPBERRYPI_TOUCHSCREEN_ATTINY
>> >>
>> >> So the whole point is to avoid writing monolitic drivers for simple
>> >> panel like that.
>> >>
>> >> There is a WIP branch based on top of Linux 6.7-rcX, which should
>> >> demonstrate this approach [1]. Unfortunately it is not ready for
>> >> upstreaming, but it has been tested on a Raspberry Pi 3 B Plus. Maybe
>> >> this is helpful for your case.
>> >>
>> >> Actually i consider panel-raspberrypi-touchscreen.c as a dead end, which
>> >> shouldn't be extended.
>> >
>> > Agreed.
>> >
>> > The panel control being bound in with the Atmel control has no hook
>> > for the EDT5x06 touch driver to hook in and keep the power to the
>> > touch controller active. When the panel disable gets called, bye bye
>> > touch overlay :-(
>> >
>> > And I'm reading the driver change as more of a hack to get it to work
>> > on your platform, not as adding support for the Waveshare panel
>> > variant.
>> > Waveshare deliberately cloned the behaviour of the Pi 7" panel in
>> > order to make it work with the old Pi firmware drivers, so it
>> > shouldn't need any significant changes. Where did the new timings come
>> > from?
>> >
>> >   Dave
>> hi Dave :
>> that's means the panel driver split into 3 sub-modules:
>> panel + panel_bridge + regulator.
> 
> Correct.
> 
> You'll have a fourth device in edt_ft5x06 for the touch overlay too,
> which will link to the regulator driver for power control.
> 
>> I have a question: in the
>> static int rpi_touchscreen_probe(struct i2c_client *i2c)
>> {
>>         ......
>>
>>         ver = rpi_touchscreen_i2c_read(ts, REG_ID);
>>         if (ver < 0) {
>>                 dev_err(dev, "Atmel I2C read failed: %d\n", ver);
>>                 return -ENODEV;
>>         }
>>
>>         switch (ver) {
>>         case 0xde: /* ver 1 */
>>         case 0xc3: /* ver 2 */
>>                 break;
>>         default:
>>                 dev_err(dev, "Unknown Atmel firmware revision: 0x%02x\n", ver);
>>                 return -ENODEV;
>>         }
>>
>>         ......
>> }
>> i think this "I2C read" can use to detect whether the panel is connected to dsi controller.
>>
>> and when split the panel driver into 3 sub-modules, it seems the default way is connected.
>> if I drop the panel , run modetest to check the connector status , result connected.
>> Is there any way to detect the connection in this case?
>> Thanks
> 
> I am not aware of any DSI drivers that support hotplugging, therefore
> the connector state will always be connected if the device probes.
> 
> On vc4 the relevant DSI host controller has to have been enabled in
> device tree and will be a required component for binding. The DSI host
> controller will be waiting on the DSI peripheral driver to call
> mipi_dsi_attach, which then calls component_add. If the panel or panel
> regulator isn't present, then that never happens if the panel isn't
> present, so vc4 won't bind.
> It is a little ugly in that you lose the whole DRM card, but that is
> how I understand DRM is generally set up to work for DSI or similar
> display interfaces.
> 
>> -------------------------------------
>>
>> Where did the new timings come from?
>>
>> -------------------------------------
>> My platform dphy tx hardware has certain limitations.
>> Only supports integer multiples of 10M bitrate:
>> such as 160M ,170M, 180M,190M,...1G(max)
>>
>> as common dphy bitrate = pixclock*bpp/lanes.
>> This value cannot match successfully in most cases.
>>
>> so in order to match bitrate , I choose a bitrate value around pixclock*bpp/lanes,
>> Prevent overflow and underflow by fine-tuning the timing parameters:-(
>> that will make the new timming value.
> 
> That isn't really a function of the panel then.
> 
> All DRM bridges have the option to define a mode_fixup in
> drm_bridge_funcs, and that gives you the option to adjust the timings
> as required.
> 
> vc4 has a similar constraint in that the PHY only has an integer
> divider from a 2 or 3GHz PLL. It implements mode_fixup to compute the
> next highest pixel clock, and then adjusts the horizontal front porch
> to keep the same line timing. See
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_dsi.c#L825
> I see 
I never thought that mode fixup is used to do this.
This would be a correct way to modify its timming parameters

thanks you Dave
>   Dave
> 
>> >
>> >> Btw there are already DT overlays in mainline which seems to use the
>> >> Raspberry Pi 7inch panel (without touch function yet) [2].
>> >>
>> >> [1] - https://github.com/lategoodbye/rpi-zero/commits/v6.7-7inch-ts
>> >> [2] -
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x-rpidsi.dtso?h=v6.6.2&id=6b4da1354fd81adace0cda448c77d8f2a47d8474
>> >>
>> >> >
>> >> > Shengyang Chen (2):
>> >> >    dt-bindings: display: panel: raspberrypi: Add compatible property for
>> >> >      waveshare 7inch touchscreen panel
>> >> >    gpu: drm: panel: raspberrypi: add new display mode and new probing
>> >> >      process
>> >> >
>> >> >   .../panel/raspberrypi,7inch-touchscreen.yaml  |  4 +-
>> >> >   .../drm/panel/panel-raspberrypi-touchscreen.c | 99 ++++++++++++++++---
>> >> >   2 files changed, 91 insertions(+), 12 deletions(-)
>> >> >
>> >>


From inki.dae at samsung.com  Wed Dec  6 18:37:44 2023
From: inki.dae at samsung.com (=?UTF-8?B?64yA7J246riwL1RpemVuIFBsYXRmb3JtIExhYihTUikv7IK87ISx7KCE7J6Q?=)
Date: Thu, 7 Dec 2023 11:37:44 +0900
Subject: [PATCH v3 08/16] drm/exynos: Convert to platform remove
 callback returning void
In-Reply-To: <20231128165505.wm4xs4ktycswthkt@pengutronix.de>
References: <20231102165640.3307820-18-u.kleine-koenig@pengutronix.de>
	<20231102165640.3307820-26-u.kleine-koenig@pengutronix.de>
	<CAAQKjZOnVSaO6QHpSo_i=WgTaawTq0UFtzwTw8kQ5iHN4qiAtQ@mail.gmail.com>
	<20231108075454.3aivzrbvtr4en22e@pengutronix.de>
	<CGME20231128165521epcas1p4993f7d2fab0723130a4612d810d254f8@epcas1p4.samsung.com>
	<20231128165505.wm4xs4ktycswthkt@pengutronix.de>
Message-ID: <048901da28b6$5be8e700$13bab500$@samsung.com>

Hello Uwe Kleine-K?nig,

> -----Original Message-----
> From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> Sent: Wednesday, November 29, 2023 1:55 AM
> To: Inki Dae <daeinki at gmail.com>
> Cc: linux-samsung-soc at vger.kernel.org; Daniel Vetter <daniel at ffwll.ch>;
> Jingoo Han <jingoohan1 at gmail.com>; Seung-Woo Kim <sw0312.kim at samsung.com>;
> Kyungmin Park <kyungmin.park at samsung.com>; DRI mailing list <dri-
> devel at lists.freedesktop.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>; kernel at pengutronix.de; Alim Akhtar
> <alim.akhtar at samsung.com>; David Airlie <airlied at gmail.com>; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v3 08/16] drm/exynos: Convert to platform remove
> callback returning void
> 
> Hello Inki,
> 
> On Wed, Nov 08, 2023 at 08:54:54AM +0100, Uwe Kleine-K?nig wrote:
> > Hello Inki,
> >
> > On Wed, Nov 08, 2023 at 01:16:18PM +0900, Inki Dae wrote:
> > > Sorry for late. There was a merge conflict so I fixed it manually and
> > > merged. And seems your patch description is duplicated so dropped
> > > duplicated one.
> >
> > Ah. I have a template that generates one patch per driver. I guess this
> > is the result of using squash instead of fixup while putting all exynos
> > changes into a single patch.
> 
> This patch didn't make it into next yet even though it's included in
> your exynos-drm-next branch at
> https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git.
> 
> Is this on purpose?

drm-exynos tree is not included in the next tree. It was previously included, but it has been removed. drm-exynos tree is merged into the mainline through the drm-next tree, but when the drm-next is synchronized to the next tree, a conflict occurred between the exynos-drm tree and the drm-next tree. Therefore, I had requested that drm-exynos tree be removed from the next. Perhaps I was inexperienced in managing the git tree at that time. :)

Thanks,
Inki Dae

> 
> Best regards
> Uwe
> 
> --
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 |
> https://protect2.fireeye.com/v1/url?k=421afdc5-23671746-421b768a-
> 74fe48600158-d04d6f7cf9d099c0&q=1&e=0938fb20-be8e-4a27-af6c-
> 9e745ec738c6&u=https%3A%2F%2Fwww.pengutronix.de%2F |




From inki.dae at samsung.com  Wed Dec  6 18:42:07 2023
From: inki.dae at samsung.com (=?ks_c_5601-1987?B?tOvAzrHiL1RpemVuIFBsYXRmb3JtIExhYihTUikvu++8usD8wNo=?=)
Date: Thu, 7 Dec 2023 11:42:07 +0900
Subject: [PATCH RESEND] drm/exynos: dpi: Change connector type to DPI
In-Reply-To: <20231206221841.15685-1-paul@crapouillou.net>
References: <CGME20231206221903epcas1p2e9d90110b0f2901e3e7db86f748026f1@epcas1p2.samsung.com>
	<20231206221841.15685-1-paul@crapouillou.net>
Message-ID: <048a01da28b6$f84c2670$e8e47350$@samsung.com>

Hi Paul,

> -----Original Message-----
> From: Paul Cercueil <paul at crapouillou.net>
> Sent: Thursday, December 7, 2023 7:19 AM
> To: Inki Dae <inki.dae at samsung.com>; Seung-Woo Kim
> <sw0312.kim at samsung.com>; Kyungmin Park <kyungmin.park at samsung.com>;
> Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>; Alim Akhtar
> <alim.akhtar at samsung.com>
> Cc: David Airlie <airlied at gmail.com>; Daniel Vetter <daniel at ffwll.ch>;
> dri-devel at lists.freedesktop.org; linux-arm-kernel at lists.infradead.org;
> linux-samsung-soc at vger.kernel.org; linux-kernel at vger.kernel.org; Paul
> Cercueil <paul at crapouillou.net>
> Subject: [PATCH RESEND] drm/exynos: dpi: Change connector type to DPI
> 
> When exynos_drm_dpi.c was written, DRM_MODE_CONNECTOR_DPI did not exist
> yet and I guess that's the reason why DRM_MODE_CONNECTOR_VGA was used as
> the connector type.
> 
> However, now it makes more sense to use DRM_MODE_CONNECTOR_DPI as the
> connector type.

Sorry for late. Merged.

Thanks,
Inki Dae

> 
> Signed-off-by: Paul Cercueil <paul at crapouillou.net>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> index 378e5381978f..0dc36df6ada3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> @@ -101,7 +101,7 @@ static int exynos_dpi_create_connector(struct
> drm_encoder *encoder)
> 
>  	ret = drm_connector_init(encoder->dev, connector,
>  				 &exynos_dpi_connector_funcs,
> -				 DRM_MODE_CONNECTOR_VGA);
> +				 DRM_MODE_CONNECTOR_DPI);
>  	if (ret) {
>  		DRM_DEV_ERROR(ctx->dev,
>  			      "failed to initialize connector with drm\n");
> --
> 2.42.0
> 




From ilkka at os.amperecomputing.com  Wed Dec  6 18:47:01 2023
From: ilkka at os.amperecomputing.com (Ilkka Koskinen)
Date: Wed, 6 Dec 2023 18:47:01 -0800 (PST)
Subject: [PATCH 2/5] perf/arm_cspmu: Simplify attribute groups
In-Reply-To: <f75cacb440011df35fc476cf4be37484fd044b92.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com> <f75cacb440011df35fc476cf4be37484fd044b92.1701793996.git.robin.murphy@arm.com>
Message-ID: <5ee6f058-a8eb-4b5b-4b0-3123e77a998b@os.amperecomputing.com>


On Tue, 5 Dec 2023, Robin Murphy wrote:
> The attribute group array itself is always the same, so there's no
> need to allocate it separately. Storing it directly in our instance
> data saves memory and gives us one less point of failure.
>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>

Reviewed-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>

Cheers, Ilkka


> ---
> drivers/perf/arm_cspmu/arm_cspmu.c | 26 +++++++++-----------------
> drivers/perf/arm_cspmu/arm_cspmu.h |  1 +
> 2 files changed, 10 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
> index a3347b1287e6..f7aa2ac5fd88 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> @@ -501,23 +501,16 @@ arm_cspmu_alloc_format_attr_group(struct arm_cspmu *cspmu)
> 	return format_group;
> }
>
> -static struct attribute_group **
> -arm_cspmu_alloc_attr_group(struct arm_cspmu *cspmu)
> +static int arm_cspmu_alloc_attr_groups(struct arm_cspmu *cspmu)
> {
> -	struct attribute_group **attr_groups = NULL;
> -	struct device *dev = cspmu->dev;
> +	const struct attribute_group **attr_groups = cspmu->attr_groups;
> 	const struct arm_cspmu_impl_ops *impl_ops = &cspmu->impl.ops;
>
> 	cspmu->identifier = impl_ops->get_identifier(cspmu);
> 	cspmu->name = impl_ops->get_name(cspmu);
>
> 	if (!cspmu->identifier || !cspmu->name)
> -		return NULL;
> -
> -	attr_groups = devm_kcalloc(dev, 5, sizeof(struct attribute_group *),
> -				   GFP_KERNEL);
> -	if (!attr_groups)
> -		return NULL;
> +		return -ENOMEM;
>
> 	attr_groups[0] = arm_cspmu_alloc_event_attr_group(cspmu);
> 	attr_groups[1] = arm_cspmu_alloc_format_attr_group(cspmu);
> @@ -525,9 +518,9 @@ arm_cspmu_alloc_attr_group(struct arm_cspmu *cspmu)
> 	attr_groups[3] = &arm_cspmu_cpumask_attr_group;
>
> 	if (!attr_groups[0] || !attr_groups[1])
> -		return NULL;
> +		return -ENOMEM;
>
> -	return attr_groups;
> +	return 0;
> }
>
> static inline void arm_cspmu_reset_counters(struct arm_cspmu *cspmu)
> @@ -1166,11 +1159,10 @@ static int arm_cspmu_get_cpus(struct arm_cspmu *cspmu)
> static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
> {
> 	int ret, capabilities;
> -	struct attribute_group **attr_groups;
>
> -	attr_groups = arm_cspmu_alloc_attr_group(cspmu);
> -	if (!attr_groups)
> -		return -ENOMEM;
> +	ret = arm_cspmu_alloc_attr_groups(cspmu);
> +	if (ret)
> +		return ret;
>
> 	ret = cpuhp_state_add_instance(arm_cspmu_cpuhp_state,
> 				       &cspmu->cpuhp_node);
> @@ -1192,7 +1184,7 @@ static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
> 		.start		= arm_cspmu_start,
> 		.stop		= arm_cspmu_stop,
> 		.read		= arm_cspmu_read,
> -		.attr_groups	= (const struct attribute_group **)attr_groups,
> +		.attr_groups	= cspmu->attr_groups,
> 		.capabilities	= capabilities,
> 	};
>
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.h b/drivers/perf/arm_cspmu/arm_cspmu.h
> index 2fe723555a6b..c9163acfe810 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.h
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.h
> @@ -157,6 +157,7 @@ struct arm_cspmu {
> 	int cycle_counter_logical_idx;
>
> 	struct arm_cspmu_hw_events hw_events;
> +	const struct attribute_group *attr_groups[5];
>
> 	struct arm_cspmu_impl impl;
> };
> -- 
> 2.39.2.101.g768bb238c484.dirty
>
>


From ankita at nvidia.com  Wed Dec  6 18:53:23 2023
From: ankita at nvidia.com (Ankit Agrawal)
Date: Thu, 7 Dec 2023 02:53:23 +0000
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZXDGUskp1s4Bwbtr@arm.com>
References: <ZW9ezSGSDIvv5MsQ@arm.com> <86a5qobkt8.wl-maz@kernel.org>
 <ZW9uqu7yOtyZfmvC@arm.com> <868r67blwo.wl-maz@kernel.org>
 <ZXBlmt88dKmZLCU9@arm.com> <20231206151603.GR2692119@nvidia.com>
 <ZXCh9N2xp0efHcpE@arm.com> <20231206172035.GU2692119@nvidia.com>
 <ZXDEZO6sS1dE_to9@arm.com> <20231206190356.GD2692119@nvidia.com>
 <ZXDGUskp1s4Bwbtr@arm.com>
Message-ID: <BY5PR12MB37634D7D2B66D772986C4C1DB08BA@BY5PR12MB3763.namprd12.prod.outlook.com>



>On Wed, Dec 06, 2023 at 03:03:56PM -0400, Jason Gunthorpe wrote:
>> On Wed, Dec 06, 2023 at 06:58:44PM +0000, Catalin Marinas wrote:
>> > -------------8<----------------------------
>> > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
>> > index 1929103ee59a..b89d2dfcd534 100644
>> > --- a/drivers/vfio/pci/vfio_pci_core.c
>> > +++ b/drivers/vfio/pci/vfio_pci_core.c
>> > @@ -1863,7 +1863,7 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
>> >????? * See remap_pfn_range(), called from vfio_pci_fault() but we can't
>> >????? * change vm_flags within the fault handler.? Set them now.
>> >????? */
>> > -?? vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
>> > +?? vm_flags_set(vma, VM_VFIO | VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
>> >???? vma->vm_ops = &vfio_pci_mmap_ops;
>> >
>> >???? return 0;
>> > diff --git a/include/linux/mm.h b/include/linux/mm.h
>> > index 418d26608ece..6df46fd7836a 100644
>> > --- a/include/linux/mm.h
>> > +++ b/include/linux/mm.h
>> > @@ -391,6 +391,13 @@ extern unsigned int kobjsize(const void *objp);
>> >? # define VM_UFFD_MINOR???????????? VM_NONE
>> >? #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
>> >
>> > +#ifdef CONFIG_64BIT
>> > +#define VM_VFIO_BIT??????????????? 39
>> > +#define VM_VFIO??????????????????? BIT(VM_VFIO_BIT)
>> > +#else
>> > +#define VM_VFIO??????????????????? VM_NONE
>> > +#endif
>> > +
>> >? /* Bits set in the VMA until the stack is in its final location */
>> >? #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
>> > -------------8<----------------------------
>> >
>> > In KVM, Akita's patch would take this into account, not just rely on
>> > "device==true".
>>
>> Yes, Ankit let's try this please. I would not call it VM_VFIO though
>>
>> VM_VFIO_ALLOW_WC ?
>
> Yeah. I don't really care about the name.

Thanks, I will make the change to set the VM_VFIO_ALLOW_WC flag in vfio.
Then make use of "device==true" and presence of the flag to decide on
setting the S2 as NORMAL_NC.

From shengyang.chen at starfivetech.com  Wed Dec  6 19:48:56 2023
From: shengyang.chen at starfivetech.com (Shengyang Chen)
Date: Thu, 7 Dec 2023 11:48:56 +0800
Subject: [PATCH v1 1/2] dt-bindings: display: panel: raspberrypi: Add
 compatible property for waveshare 7inch touchscreen panel
In-Reply-To: <20231206-isolating-smoked-b490952029d0@spud>
References: <20231124104451.44271-1-shengyang.chen@starfivetech.com>
 <20231124104451.44271-2-shengyang.chen@starfivetech.com>
 <20231124-lesser-sinister-7f9cd7b80e35@spud>
 <2d48e460-e46e-431f-bd7b-e34ebe73a40c@starfivetech.com>
 <20231206-isolating-smoked-b490952029d0@spud>
Message-ID: <53b992e8-1b36-4540-a993-fde8e550faf9@starfivetech.com>

Hi, Conor

thanks for comment

On 2023/12/6 23:40, Conor Dooley wrote:
> On Wed, Dec 06, 2023 at 05:43:48PM +0800, Shengyang Chen wrote:
>> Hi, Conor
>> 
>> On 2023/11/24 20:31, Conor Dooley wrote:
>> > On Fri, Nov 24, 2023 at 06:44:50PM +0800, Shengyang Chen wrote:
>> >> The waveshare 7inch touchscreen panel is a kind of raspberrypi pi
>> >> panel
>> > 
>> > Can you be more specific about what "is a kind of rpi panel" means?
>> > Are they using identical chips as controllers or something like that?
>> > 
>> 
>> Wareshare panel has same i2c slave address and registers address with 
>> the original raspberry pi panel. They both use Atmel firmware and they
>> got same reg id. It can be operated by using the driver of raspberry pi driver
>> after some change of the code. So I suppose it may be a kind of raspberry pi panel 
>> and discribe it in this way. It's my own judgement. Sorry about that.
>> Maybe just like Dave said, It cloned the behaviour of the raspberri pi panel.
>> I will change the discribtion in next version to not make other confused.
>> 
>> By the way, we will try Stefan's method before next version. 
>> The method we used in this patch may be abandoned if Stefan's method is verified in our platform.
>> At that time yaml may also be changed to fit new method.
> 
> I don't know what Stefan's approach is, but I do not think that a
> bindings patch should be dropped. The waveshare might be a clone, but it
> is a distinct device. If the same driver can control both, then the
> compatible setups that should be permitted are:
> compatible = "raspberrypi,7inch-touchscreen-panel";
> and
> compatible = "waveshare,7inch-touchscreen-panel", "raspberrypi,7inch-touchscreen-panel";
> 
> Cheers,
> Conor.
> 

Here is our consideration of this submit:

Although Waveshare panel reuse the driver of raspberry pi panel, they are different in probing process
and panel parameters.
we try to use compatible and data to distinguish these two panel

Here are the reference
driver part:
https://elixir.bootlin.com/linux/v6.7-rc3/source/drivers/gpu/drm/panel/panel-simple.c
dt-binding part:
https://elixir.bootlin.com/linux/v6.7-rc3/source/Documentation/devicetree/bindings/display/panel/panel-simple.yaml


For example:

in driver part:

in drivers/gpu/drm/panel/panel-simple.c:#in line 4189
----------------------------------------------------------------------------------
we can got different compatible with its own data.
================================================
static const struct of_device_id platform_of_match[] = {			//the of_match array list
	{
		.compatible = "ampire,am-1280800n3tzqw-t00h",
		.data = &ampire_am_1280800n3tzqw_t00h,		//we define our panel parameter or special panel function, which can distinguish different panels
	}, {
		.compatible = "ampire,am-480272h3tmqw-t01h",
		.data = &ampire_am_480272h3tmqw_t01h,
	}, 
...
...
}
===============================================

in drivers/gpu/drm/panel/panel-simple.c:#in line 4611
----------------------------------------------------------------------------------
we can use the generic probing process to probe our driver
after getting its own data.
================================================
static int panel_simple_platform_probe(struct platform_device *pdev)
{
	const struct panel_desc *desc;

	desc = of_device_get_match_data(&pdev->dev);			//we get our panel parameter
	if (!desc)
		return -ENODEV;

	return panel_simple_probe(&pdev->dev, desc);			//probe with returned data
}



================================================

in yamel part:

in /Documentation/devicetree/bindings/display/panel/panel-simple.yaml#in line 33
----------------------------------------------------------------------------------
We refer to this approach, adding our compatible to the yaml of raspberry pi panel
================================================

properties:
  compatible:
    enum:
    # compatible must be listed in alphabetical order, ordered by compatible.
    # The description in the comment is mandatory for each compatible.

        # Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel
      - ampire,am-1280800n3tzqw-t00h
        # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
      - ampire,am-480272h3tmqw-t01h
================================================



If we use Stenfan's method, we can reuse the code of panel-simple.c
we may submit our patch to
/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
/drivers/gpu/drm/panel/panel-simple.c
as a new panel porting. That may less confuse.


here is Stenfan's method:
[1] - https://github.com/lategoodbye/rpi-zero/commits/v6.7-7inch-ts
[2] -
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x-rpidsi.dtso?h=v6.6.2&id=6b4da1354fd81adace0cda448c77d8f2a47d8474


Thanks

Best Regards,
Shengyang


>> >> and it can be drived by panel-raspberrypi-touchscreen.c.
>> >> Add compatible property for it.
>> >> 
>> >> Signed-off-by: Keith Zhao <keith.zhao at starfivetech.com>
>> >> Signed-off-by: Shengyang Chen <shengyang.chen at starfivetech.com>
>> >> ---
>> >>  .../bindings/display/panel/raspberrypi,7inch-touchscreen.yaml | 4 +++-
>> >>  1 file changed, 3 insertions(+), 1 deletion(-)
>> >> 
>> >> diff --git a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
>> >> index 22a083f7bc8e..e4e6cb4d4e5b 100644
>> >> --- a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
>> >> +++ b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
>> >> @@ -22,7 +22,9 @@ description: |+
>> >>  
>> >>  properties:
>> >>    compatible:
>> >> -    const: raspberrypi,7inch-touchscreen-panel
>> >> +    enum:
>> >> +      - raspberrypi,7inch-touchscreen-panel
>> >> +      - waveshare,7inch-touchscreen-panel
>> >>  
>> >>    reg:
>> >>      const: 0x45
>> >> -- 
>> >> 2.17.1
>> >> 
>> 
>> 
>> thanks.
>> 
>> Best Regards,
>> Shengyang
>> 



From cl at linux.com  Wed Dec  6 19:54:48 2023
From: cl at linux.com (Christoph Lameter (Ampere))
Date: Wed, 06 Dec 2023 19:54:48 -0800
Subject: [RFC 0/8] ARM64 TLB logic revision for more control and enhanced diagnostics
Message-ID: <20231207035448.430024696@linux.com>

WARNING: First draft of the patchset, tested with kernel compiles, may
corrupt your memory.

This patchset intends to aid in help debugging and scaling TLB operations
on ARM64. This is in particular desirable for ARM architectures with
large numbers of cores. What is often seen is that the mesh is flooded with
snoop traffic that is related to TLBI broadcasts.

The patchset adds the following features:

- Allow diagnostics via /proc/vmstat like already possible on X86 with the
	CONFIG_DEBUG_TLB  option.

  Some sample output:

  cat /proc/vmstat
	...
	nr_tlb_remote_flush 554104		Flushes converted to IPIs with local flushing
	nr_tlb_remote_flush_received 1312243	IPIs received to perform local flushing
	nr_tlb_local_flush_all 141837		Local flush alls
	nr_tlb_local_flush_range 571784		Local flush range
	nr_tlb_local_flush_one 8011880		Local individual page flushes
	nr_tlb_flush_all 28239			Flush alls through the mesh
	nr_tlb_flush_range 13003		Flush range through the mesh
	nr_tlb_flush_one 54764			Flush one through the mesh
	nr_tlb_skipped 0			Suppressed flush

- Tracks the cores that have used an address space. With that we can
	compute the weight of cpus that have used this address space
	to decide on how to optimally do the flushing when such an action
	is required.

- Control the TLB flushing behavior via the kernel command line and also on a running system.

    New Kernel parameter  tlb_mode=<tlb_mode>
    New sysfs setting     /sys/kernel/debug/tlb_mode

	tlb_mode is comprised of a set of flags starting at bit 10. Bit 0-9
	are used to set a boundary as to what cpu weight will lead to a mesh
	flush. If the cpu weight is lower then IPIs are send avoiding the mesh.

	Feature flags:

	Bit 10 = If the current cpu is the only one that has ever used an
			address space then perform local invalidation.
			This catches the majority of flushes on boot and
			activities of typical single threaded Unixy processes.

	Bit 11 = Enable TLB range. Various hardware has problems with TLB range.
			This allows the kernel to recognize that TLB range
			should not be used and an alternate method is to be
			used to do the flushing.

	Bit 12 = Suppress TLB flushes if the address space is unused.
			If this bit is set and a flush is requested in an
			unused address space then no flush will be performed
			since there cannot any TLB entries. If this is
			not set then perform mesh flush (just to be sure).

- Autotunes the feature flags on bootup if the user has not specified tlb_mode.
	Calculates an optimal balance between IPIs and mesh flushing
	based on the number of cpus in the system. Enables local validation
	always and tlb range flushing if the processor features indicate
	that the processor supports it.


We need a more detailed description but I hope this is enough to get started.

These issues have been discussed before in an patchset that contains a similar feature 
in 2019:

https://lore.kernel.org/linux-arm-kernel/20190617143255.10462-1-indou.takao at jp.fujitsu.com/



From cl at gentwo.org  Wed Dec  6 19:57:03 2023
From: cl at gentwo.org (Christoph Lameter (Ampere))
Date: Wed, 06 Dec 2023 19:57:03 -0800
Subject: [RFC 0/8] ARM64 TLB logic revision for more control and enhanced diagnostics
Message-ID: <20231207035703.158053467@gentwo.org>

WARNING: First draft of the patchset, tested with kernel compiles, may
corrupt your memory.

This patchset intends to aid in help debugging and scaling TLB operations
on ARM64. This is in particular desirable for ARM architectures with
large numbers of cores. What is often seen is that the mesh is flooded with
snoop traffic that is related to TLBI broadcasts.

The patchset adds the following features:

- Allow diagnostics via /proc/vmstat like already possible on X86 with the
	CONFIG_DEBUG_TLB  option.

  Some sample output:

  cat /proc/vmstat
	...
	nr_tlb_remote_flush 554104		Flushes converted to IPIs with local flushing
	nr_tlb_remote_flush_received 1312243	IPIs received to perform local flushing
	nr_tlb_local_flush_all 141837		Local flush alls
	nr_tlb_local_flush_range 571784		Local flush range
	nr_tlb_local_flush_one 8011880		Local individual page flushes
	nr_tlb_flush_all 28239			Flush alls through the mesh
	nr_tlb_flush_range 13003		Flush range through the mesh
	nr_tlb_flush_one 54764			Flush one through the mesh
	nr_tlb_skipped 0			Suppressed flush

- Tracks the cores that have used an address space. With that we can
	compute the weight of cpus that have used this address space
	to decide on how to optimally do the flushing when such an action
	is required.

- Control the TLB flushing behavior via the kernel command line and also on a running system.

    New Kernel parameter  tlb_mode=<tlb_mode>
    New sysfs setting     /sys/kernel/debug/tlb_mode

	tlb_mode is comprised of a set of flags starting at bit 10. Bit 0-9
	are used to set a boundary as to what cpu weight will lead to a mesh
	flush. If the cpu weight is lower then IPIs are send avoiding the mesh.

	Feature flags:

	Bit 10 = If the current cpu is the only one that has ever used an
			address space then perform local invalidation.
			This catches the majority of flushes on boot and
			activities of typical single threaded Unixy processes.

	Bit 11 = Enable TLB range. Various hardware has problems with TLB range.
			This allows the kernel to recognize that TLB range
			should not be used and an alternate method is to be
			used to do the flushing.

	Bit 12 = Suppress TLB flushes if the address space is unused.
			If this bit is set and a flush is requested in an
			unused address space then no flush will be performed
			since there cannot any TLB entries. If this is
			not set then perform mesh flush (just to be sure).

- Autotunes the feature flags on bootup if the user has not specified tlb_mode.
	Calculates an optimal balance between IPIs and mesh flushing
	based on the number of cpus in the system. Enables local validation
	always and tlb range flushing if the processor features indicate
	that the processor supports it.


We need a more detailed description but I hope this is enough to get started.

These issues have been discussed before in an patchset that contains a similar feature 
in 2019:

https://lore.kernel.org/linux-arm-kernel/20190617143255.10462-1-indou.takao at jp.fujitsu.com/



From cl at linux.com  Wed Dec  6 20:23:49 2023
From: cl at linux.com (Christoph Lameter (Ampere))
Date: Wed, 6 Dec 2023 20:23:49 -0800 (PST)
Subject: [RFC 0/8] ARM64 TLB logic revision for more control and enhanced
 diagnostics
In-Reply-To: <20231207035448.430024696@linux.com>
References: <20231207035448.430024696@linux.com>
Message-ID: <39280781-2d7e-6f2d-d417-421ede5adfc7@linux.com>

The patches in the patchset were rejected by the infradead 
mailer. Tried multiple times.

The patchset can be found on kernel org in the meantime:

https://git.kernel.org/pub/scm/linux/kernel/git/christoph/linux.git/log/?h=tlb

Could someone give me a clue as to why the mailing list does not take 
patches from quilt anymore?

I got the following back from the mail server. Everything seems to check 
out as far as I can see. Tried from multiple emails. But nope...




>From linux-arm-kernel-bounces+cl=gentwo.org at lists.infradead.org  Wed Dec 
6 19:57:29 2023
Return-Path: <linux-arm-kernel-bounces+cl=gentwo.org at lists.infradead.org>
X-Original-To: cl at gentwo.org
Delivered-To: cl at gentwo.org
Received: from bombadil.infradead.org (bombadil.infradead.org 
[IPv6:2607:7c80:54:3::133])
         by gentwo.org (Postfix) with ESMTPS id 4B49B48F4C
         for <cl at gentwo.org>; Wed,  6 Dec 2023 19:57:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
         d=lists.infradead.org; s=bombadil.20210309; 
h=Sender:List-Id:Date:Message-ID:

To:From:Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Reply-To:

Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:

Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Help:
         List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
         bh=zWvnfDmYfVoivQxCjAVOhgbHxeaE+nz22oVa3ZjNTZE=; 
b=SFPz6W4YOfzjphrltl0TcQqdFa

+scg6wXD/ngEjw6lLUJ06adn7Jk1WbG79r1ejLjWoWdQWFJSjkOYMl7Ti98m0OnmO6e2xOvTUuS5B

cqTPlIHyRx2vw7Zs68zVQdIsp3CyJYqwJQQkGsqF97ZdLCzrOcburj7MI1wDzRxpIMSXh3d9eBGOP

jMacUI6fgRYxge6KmSo4Pd3g0bm2lXSSQJPiRS7Wj5wdwXgXs8LOP+RTv436VcBWfuC3Ct06Xujc2

hLPEokLaYBauB1b7oFDCGQn1NsoNwz4BFcoFqjl5FalQvrtU5xj/ICDTMq9L4xDbFIXUtYEr3dChP
         ierxmTgg==;
Received: from localhost ([::1] helo=bombadil.infradead.org)
         by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat 
Linux))
         id 1rB5Vw-00Bnyx-3B
         for cl at gentwo.org;
         Thu, 07 Dec 2023 03:57:28 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Your message to linux-arm-kernel awaits moderator approval
From: linux-arm-kernel-owner at lists.infradead.org
To: cl at gentwo.org
Message-ID: 
<mailman.61130.1701921444.1880391.linux-arm-kernel at lists.infradead.org>
Date: Wed, 06 Dec 2023 19:57:24 -0800
Precedence: bulk
X-BeenThere: linux-arm-kernel at lists.infradead.org
X-Mailman-Version: 2.1.34
List-Id: <linux-arm-kernel.lists.infradead.org>
X-List-Administrivia: yes
Sender: "linux-arm-kernel" <linux-arm-kernel-bounces at lists.infradead.org>
Errors-To: linux-arm-kernel-bounces+cl=gentwo.org at lists.infradead.org
Status: O
X-Status:
X-Keywords:
X-UID: 10563

Your mail to 'linux-arm-kernel' with the subject

     [RFC 8/8] Remove temporary _count_vm_tlb_event

Is being held until the list moderator can review it for approval.

The reason it is being held:

     Message has a suspicious header

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:


http://lists.infradead.org/mailman/confirm/linux-arm-kernel/b301494b26df71c14e8d923da3f452472fb6186f









From u-kumar1 at ti.com  Wed Dec  6 20:42:49 2023
From: u-kumar1 at ti.com (Kumar, Udit)
Date: Thu, 7 Dec 2023 10:12:49 +0530
Subject: [PATCH v9 6/7] arm64: dts: ti: k3-j721e-sk: Add TPS6594 family
 PMICs
In-Reply-To: <20231205151647.vh6rlhro7qlwoerc@knelt>
References: <20231205093439.2298296-1-n-francis@ti.com>
 <20231205093439.2298296-7-n-francis@ti.com>
 <20231205151647.vh6rlhro7qlwoerc@knelt>
Message-ID: <5e22f8cb-1004-4bcc-9bd0-2c30180ba10e@ti.com>


On 12/5/2023 8:46 PM, Nishanth Menon wrote:
> On 15:04-20231205, Neha Malcom Francis wrote:
>> This patch adds support for TPS6594 PMIC family on wakeup I2C0 bus.
>> These devices provide regulators (bucks and LDOs), but also GPIOs, a
>> RTC, a watchdog, an ESM (Error Signal Monitor) which monitors the SoC
>> error output signal, and a PFSM (Pre-configurable Finite State Machine)
>> which manages the operational modes of the PMIC.
>>
>> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
>> ---
>>   arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 158 +++++++++++++++++++++++++
>>   1 file changed, 158 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>> index 42fe8eee9ec8..e600825f7e78 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>> @@ -459,6 +459,13 @@ J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3) EXT_REFCLK1.GPIO1_12 */
>>   };
>>   
>>   &wkup_pmx0 {
>> +	pmic_irq_pins_default: pmic-irq-default-pins {
>> +		bootph-pre-ram;
>> +		pinctrl-single,pins = <
>> +			J721E_WKUP_IOPAD(0x0cc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
>> +		>;
>> +	};
>> +
>>   	mcu_cpsw_pins_default: mcu-cpsw-default-pins {
>>   		pinctrl-single,pins = <
>>   			J721E_WKUP_IOPAD(0x84, PIN_INPUT, 0) /* (B24) MCU_RGMII1_RD0 */
>> @@ -560,6 +567,157 @@ eeprom at 51 {
>>   		compatible = "atmel,24c512";
>>   		reg = <0x51>;
>>   	};
>> +
>> +	tps659413: pmic at 48 {
>> +		bootph-pre-ram;
> only for the leaf nodes. See
> https://libera.irclog.whitequark.org/armlinux/2023-10-19


AFAIK, please correct me, u-boot still needs in all nodes ?

>
>> +		compatible = "ti,tps6594-q1";
>> +		reg = <0x48>;
>> +		system-power-controller;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pmic_irq_pins_default>;
>> +		interrupt-parent = <&wkup_gpio0>;
>> +		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
>> +		ti,primary-pmic;
>> +
>> +		gpio-controller;
>> +		#gpio-cells = <2>;
>> +
>> +		buck123-supply = <&vsys_3v3>;
>> +		buck4-supply = <&vsys_3v3>;
>> +		buck5-supply = <&vsys_3v3>;
>> +		ldo1-supply = <&vsys_3v3>;
>> +		ldo2-supply = <&vsys_3v3>;
>> +		ldo3-supply = <&vsys_3v3>;
>> +		ldo4-supply = <&vsys_3v3>;
>> +
>> +		regulators {
>> +			bootph-pre-ram;
>> +			bucka123: buck123 {
>> +				bootph-pre-ram;
>> +				regulator-name = "vdd_cpu_avs";
>> +				regulator-min-microvolt = <600000>;
>> +				regulator-max-microvolt = <900000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			bucka4: buck4 {
>> +				regulator-name = "vdd_mcu_0v85";
>> +				regulator-min-microvolt = <850000>;
>> +				regulator-max-microvolt = <850000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			bucka5: buck5 {
>> +				regulator-name = "vdd_phyio_1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldoa1: ldo1 {
>> +				regulator-name = "vdd1_lpddr4_1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldoa2: ldo2 {
>> +				regulator-name = "vdd_mcuio_1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldoa3: ldo3 {
>> +				regulator-name = "vdda_dll_0v8";
>> +				regulator-min-microvolt = <800000>;
>> +				regulator-max-microvolt = <800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldoa4: ldo4 {
>> +				regulator-name = "vda_mcu_1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +		};
>> +	};
>> +
>> +	tps659411: pmic at 4c {
>> +		compatible = "ti,tps6594-q1";
>> +		reg = <0x4c>;
>> +		system-power-controller;
>> +		interrupt-parent = <&wkup_gpio0>;
>> +		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
>> +
>> +		gpio-controller;
>> +		#gpio-cells = <2>;
>> +
>> +		buck1234-supply = <&vsys_3v3>;
>> +		buck5-supply = <&vsys_3v3>;
>> +		ldo1-supply = <&vsys_3v3>;
>> +		ldo2-supply = <&vsys_3v3>;
>> +		ldo3-supply = <&vsys_3v3>;
>> +		ldo4-supply = <&vsys_3v3>;
>> +
>> +		regulators {
>> +			buckb1234: buck1234 {
>> +				regulator-name = "vdd_core_0v8";
>> +				regulator-min-microvolt = <800000>;
>> +				regulator-max-microvolt = <800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			buckb5: buck5 {
>> +				regulator-name = "vdd_ram_0v85";
>> +				regulator-min-microvolt = <850000>;
>> +				regulator-max-microvolt = <850000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldob1: ldo1 {
>> +				regulator-name = "vdd_sd_dv";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <3300000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldob2: ldo2 {
>> +				regulator-name = "vdd_usb_3v3";
>> +				regulator-min-microvolt = <3300000>;
>> +				regulator-max-microvolt = <3300000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldob3: ldo3 {
>> +				regulator-name = "vdd_io_1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +
>> +			ldob4: ldo4 {
>> +				regulator-name = "vda_pll_1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-boot-on;
>> +				regulator-always-on;
>> +			};
>> +		};
>> +	};
>>   };
>>   
>>   &mcu_uart0 {
>> -- 
>> 2.34.1
>>


From u-kumar1 at ti.com  Wed Dec  6 20:59:02 2023
From: u-kumar1 at ti.com (Kumar, Udit)
Date: Thu, 7 Dec 2023 10:29:02 +0530
Subject: [PATCH v9 5/7] arm64: dts: ti: k3-am69-sk: Add support for
 TPS6594 PMIC
In-Reply-To: <20231205093439.2298296-6-n-francis@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
 <20231205093439.2298296-6-n-francis@ti.com>
Message-ID: <5eecd094-bc14-4257-bbe9-1e20aabd38f7@ti.com>


On 12/5/2023 3:04 PM, Neha Malcom Francis wrote:
> This patch adds support for TPS6594 PMIC on wkup I2C0 bus. This device
> provides regulators (bucks and LDOs), but also GPIOs, a RTC, a watchdog,
> an ESM (Error Signal Monitor) which monitors the SoC error output
> signal, and a PFSM (Pre-configurable Finite State Machine) which manages
> the operational modes of the PMIC.
>
> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
> Tested-by: Manorit Chawdhry <m-chawdhry at ti.com>
> ---
>   arch/arm64/boot/dts/ti/k3-am69-sk.dts | 100 ++++++++++++++++++++++++++
>   1 file changed, 100 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> index 9868c7049bfb..dec27acb4e96 100644
> --- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> @@ -431,6 +431,17 @@ J784S4_IOPAD(0x000, PIN_INPUT, 7) /* (AN35) EXTINTN.GPIO0_0 */
>   	};
>   };
>   
> +&wkup_pmx1 {
> +	status = "okay";
> +
> +	pmic_irq_pins_default: pmic-irq-default-pins {
> +		pinctrl-single,pins = <
> +			/* (AA37) MCU_ADC1_AIN4.WKUP_GPIO0_83 */
> +			J784S4_WKUP_IOPAD(0x12c, PIN_INPUT, 7)
> +		>;
> +	};
> +};

Could you re check this pin mux

wkup_pmx1 is defined as reg = <0x00 0x4301c038 0x00 0x02c>;

LTM, this is above wrt given size


> +
>   &wkup_pmx2 {
>   	bootph-all;
>   	wkup_uart0_pins_default: wkup-uart0-default-pins {
> @@ -631,6 +642,95 @@ eeprom at 51 {
>   		compatible = "atmel,24c512";
>   		reg = <0x51>;
>   	};
> +
> +	tps659413: pmic at 48 {
> +		compatible = "ti,tps6594-q1";
> +		reg = <0x48>;
> +		system-power-controller;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_irq_pins_default>;
> +		interrupt-parent = <&wkup_gpio0>;
> +		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
> +		ti,primary-pmic;
> +
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +		buck12-supply = <&vsys_3v3>;
> +		buck3-supply = <&vsys_3v3>;
> +		buck4-supply = <&vsys_3v3>;
> +		buck5-supply = <&vsys_3v3>;
> +		ldo1-supply = <&vsys_3v3>;
> +		ldo2-supply = <&vsys_3v3>;
> +		ldo3-supply = <&vsys_3v3>;
> +		ldo4-supply = <&vsys_3v3>;
> +
> +		regulators {
> +			bucka12: buck12 {
> +				regulator-name = "vdd_ddr_1v1";
> +				regulator-min-microvolt = <1100000>;
> +				regulator-max-microvolt = <1100000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka3: buck3 {
> +				regulator-name = "vdd_ram_0v85";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka4: buck4 {
> +				regulator-name = "vdd_io_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka5: buck5 {
> +				regulator-name = "vdd_mcu_0v85";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa1: ldo1 {
> +				regulator-name = "vdd_mcuio_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa2: ldo2 {
> +				regulator-name = "vdd_mcuio_3v3";
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa3: ldo3 {
> +				regulator-name = "vds_dll_0v8";
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa4: ldo4 {
> +				regulator-name = "vda_mcu_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +		};
> +	};
>   };
>   
>   &wkup_gpio0 {


From n-francis at ti.com  Wed Dec  6 21:10:23 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Thu, 7 Dec 2023 10:40:23 +0530
Subject: [PATCH v9 5/7] arm64: dts: ti: k3-am69-sk: Add support for
 TPS6594 PMIC
In-Reply-To: <5eecd094-bc14-4257-bbe9-1e20aabd38f7@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
 <20231205093439.2298296-6-n-francis@ti.com>
 <5eecd094-bc14-4257-bbe9-1e20aabd38f7@ti.com>
Message-ID: <48ede2d2-29b8-4c92-940c-ac28f9d7c10f@ti.com>

Hi Udit,

On 07/12/23 10:29, Kumar, Udit wrote:
> 
> On 12/5/2023 3:04 PM, Neha Malcom Francis wrote:
>> This patch adds support for TPS6594 PMIC on wkup I2C0 bus. This device
>> provides regulators (bucks and LDOs), but also GPIOs, a RTC, a watchdog,
>> an ESM (Error Signal Monitor) which monitors the SoC error output
>> signal, and a PFSM (Pre-configurable Finite State Machine) which manages
>> the operational modes of the PMIC.
>>
>> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
>> Tested-by: Manorit Chawdhry <m-chawdhry at ti.com>
>> ---
>> ? arch/arm64/boot/dts/ti/k3-am69-sk.dts | 100 ++++++++++++++++++++++++++
>> ? 1 file changed, 100 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts 
>> b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
>> index 9868c7049bfb..dec27acb4e96 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
>> @@ -431,6 +431,17 @@ J784S4_IOPAD(0x000, PIN_INPUT, 7) /* (AN35) 
>> EXTINTN.GPIO0_0 */
>> ????? };
>> ? };
>> +&wkup_pmx1 {
>> +??? status = "okay";
>> +
>> +??? pmic_irq_pins_default: pmic-irq-default-pins {
>> +??????? pinctrl-single,pins = <
>> +??????????? /* (AA37) MCU_ADC1_AIN4.WKUP_GPIO0_83 */
>> +??????????? J784S4_WKUP_IOPAD(0x12c, PIN_INPUT, 7)
>> +??????? >;
>> +??? };
>> +};
> 
> Could you re check this pin mux
> 
> wkup_pmx1 is defined as reg = <0x00 0x4301c038 0x00 0x02c>;
> 
> LTM, this is above wrt given size
> 

You're right it must be in wkup_pmx2. Thanks for catching this!

> 
>> +
>> ? &wkup_pmx2 {
>> ????? bootph-all;
>> ????? wkup_uart0_pins_default: wkup-uart0-default-pins {
>> @@ -631,6 +642,95 @@ eeprom at 51 {
>> ????????? compatible = "atmel,24c512";
>> ????????? reg = <0x51>;
>> ????? };
>> +
>> +??? tps659413: pmic at 48 {
>> +??????? compatible = "ti,tps6594-q1";
>> +??????? reg = <0x48>;
>> +??????? system-power-controller;
>> +??????? pinctrl-names = "default";
>> +??????? pinctrl-0 = <&pmic_irq_pins_default>;
>> +??????? interrupt-parent = <&wkup_gpio0>;
>> +??????? interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
>> +??????? ti,primary-pmic;
>> +
>> +??????? gpio-controller;
>> +??????? #gpio-cells = <2>;
>> +
>> +??????? buck12-supply = <&vsys_3v3>;
>> +??????? buck3-supply = <&vsys_3v3>;
>> +??????? buck4-supply = <&vsys_3v3>;
>> +??????? buck5-supply = <&vsys_3v3>;
>> +??????? ldo1-supply = <&vsys_3v3>;
>> +??????? ldo2-supply = <&vsys_3v3>;
>> +??????? ldo3-supply = <&vsys_3v3>;
>> +??????? ldo4-supply = <&vsys_3v3>;
>> +
>> +??????? regulators {
>> +??????????? bucka12: buck12 {
>> +??????????????? regulator-name = "vdd_ddr_1v1";
>> +??????????????? regulator-min-microvolt = <1100000>;
>> +??????????????? regulator-max-microvolt = <1100000>;
>> +??????????????? regulator-boot-on;
>> +??????????????? regulator-always-on;
>> +??????????? };
>> +
>> +??????????? bucka3: buck3 {
>> +??????????????? regulator-name = "vdd_ram_0v85";
>> +??????????????? regulator-min-microvolt = <850000>;
>> +??????????????? regulator-max-microvolt = <850000>;
>> +??????????????? regulator-boot-on;
>> +??????????????? regulator-always-on;
>> +??????????? };
>> +
>> +??????????? bucka4: buck4 {
>> +??????????????? regulator-name = "vdd_io_1v8";
>> +??????????????? regulator-min-microvolt = <1800000>;
>> +??????????????? regulator-max-microvolt = <1800000>;
>> +??????????????? regulator-boot-on;
>> +??????????????? regulator-always-on;
>> +??????????? };
>> +
>> +??????????? bucka5: buck5 {
>> +??????????????? regulator-name = "vdd_mcu_0v85";
>> +??????????????? regulator-min-microvolt = <850000>;
>> +??????????????? regulator-max-microvolt = <850000>;
>> +??????????????? regulator-boot-on;
>> +??????????????? regulator-always-on;
>> +??????????? };
>> +
>> +??????????? ldoa1: ldo1 {
>> +??????????????? regulator-name = "vdd_mcuio_1v8";
>> +??????????????? regulator-min-microvolt = <1800000>;
>> +??????????????? regulator-max-microvolt = <1800000>;
>> +??????????????? regulator-boot-on;
>> +??????????????? regulator-always-on;
>> +??????????? };
>> +
>> +??????????? ldoa2: ldo2 {
>> +??????????????? regulator-name = "vdd_mcuio_3v3";
>> +??????????????? regulator-min-microvolt = <3300000>;
>> +??????????????? regulator-max-microvolt = <3300000>;
>> +??????????????? regulator-boot-on;
>> +??????????????? regulator-always-on;
>> +??????????? };
>> +
>> +??????????? ldoa3: ldo3 {
>> +??????????????? regulator-name = "vds_dll_0v8";
>> +??????????????? regulator-min-microvolt = <800000>;
>> +??????????????? regulator-max-microvolt = <800000>;
>> +??????????????? regulator-boot-on;
>> +??????????????? regulator-always-on;
>> +??????????? };
>> +
>> +??????????? ldoa4: ldo4 {
>> +??????????????? regulator-name = "vda_mcu_1v8";
>> +??????????????? regulator-min-microvolt = <1800000>;
>> +??????????????? regulator-max-microvolt = <1800000>;
>> +??????????????? regulator-boot-on;
>> +??????????????? regulator-always-on;
>> +??????????? };
>> +??????? };
>> +??? };
>> ? };
>> ? &wkup_gpio0 {

-- 
Thanking You
Neha Malcom Francis


From zhi.mao at mediatek.com  Wed Dec  6 21:20:14 2023
From: zhi.mao at mediatek.com (Zhi Mao)
Date: Thu, 7 Dec 2023 13:20:14 +0800
Subject: [PATCH v2 0/2] media: i2c: Add support for GC08A3 sensor 
Message-ID: <20231207052016.25954-1-zhi.mao@mediatek.com>

This series adds YAML DT binding and V4L2 sub-device driver for Galaxycore's
GC08A3 8-megapixel 10-bit RAW CMOS 1/4" sensor, with an MIPI CSI-2 image data
interface and the I2C control bus.

The driver is implemented with V4L2 framework.
 - Async registered as a V4L2 sub-device.
 - As the first component of camera system including Seninf, ISP pipeline.
 - A media entity that provides one source pad in common.
 - Used in camera features on ChromeOS application.

Also this driver supports following features:
 - manual exposure and analog gain control support
 - vertical blanking control support
 - test pattern support
 - media controller support
 - runtime PM support
 - support resolution: 3264x2448 at 30fps, 1920x1080 at 60fps

Previous versions of this patch-set can be found here:
 v1: https://lore.kernel.org/linux-media/20231123115104.32094-1-zhi.mao at mediatek.com/

Changes of v2 mainly address comments from Krzysztof/Rob Herring&Conor Dooley.
Compared to v1:
  - Fix some review comments  
  - Add reviewed-by for sensor driver
  - Fix some build-error and warning message 
 
Thanks


Zhi Mao (2):
  media: i2c: Add GC08A3 image sensor driver
  media: dt-bindings: media: i2c: Document GC08A3 bindings

 .../bindings/media/i2c/galaxycore,gc08a3.yaml |  127 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |    2 +
 drivers/media/i2c/Kconfig                     |   14 +
 drivers/media/i2c/Makefile                    |    1 +
 drivers/media/i2c/gc08a3.c                    | 1888 +++++++++++++++++
 5 files changed, 2032 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
 create mode 100644 drivers/media/i2c/gc08a3.c

-- 
2.25.1





From zhi.mao at mediatek.com  Wed Dec  6 21:20:15 2023
From: zhi.mao at mediatek.com (Zhi Mao)
Date: Thu, 7 Dec 2023 13:20:15 +0800
Subject: [PATCH 1/2] media: i2c: Add GC08A3 image sensor driver
In-Reply-To: <20231207052016.25954-1-zhi.mao@mediatek.com>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
Message-ID: <20231207052016.25954-2-zhi.mao@mediatek.com>

Add a V4L2 sub-device driver for Galaxycore GC08A3 image sensor.

Reviewed-By: yunkec at chromium.org
Signed-off-by: Zhi Mao <zhi.mao at mediatek.com>
---
 drivers/media/i2c/Kconfig  |   14 +
 drivers/media/i2c/Makefile |    1 +
 drivers/media/i2c/gc08a3.c | 1888 ++++++++++++++++++++++++++++++++++++
 3 files changed, 1903 insertions(+)
 create mode 100644 drivers/media/i2c/gc08a3.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 59ee0ca2c978..e2718bfdf369 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -50,6 +50,20 @@ config VIDEO_AR0521
 	  To compile this driver as a module, choose M here: the
 	  module will be called ar0521.
 
+config VIDEO_GC08A3
+	tristate "GalaxyCore gc08a3 sensor support"
+	depends on GPIOLIB && I2C && VIDEO_DEV
+	select V4L2_FWNODE
+	select MEDIA_CONTROLLER
+	select VIDEO_V4L2_SUBDEV_API
+	select REGMAP_I2C
+	help
+	  This is a Video4Linux2 sensor driver for the GalaxyCore gc08a3
+	  camera.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called gc08a3.
+
 config VIDEO_HI556
 	tristate "Hynix Hi-556 sensor support"
 	help
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f5010f80a21f..ec40dbd75e7a 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_VIDEO_DW9719) += dw9719.o
 obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
 obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
 obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8/
+obj-$(CONFIG_VIDEO_GC08A3) += gc08a3.o
 obj-$(CONFIG_VIDEO_HI556) += hi556.o
 obj-$(CONFIG_VIDEO_HI846) += hi846.o
 obj-$(CONFIG_VIDEO_HI847) += hi847.o
diff --git a/drivers/media/i2c/gc08a3.c b/drivers/media/i2c/gc08a3.c
new file mode 100644
index 000000000000..5a9580f97807
--- /dev/null
+++ b/drivers/media/i2c/gc08a3.c
@@ -0,0 +1,1888 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * gc08a3.c - gc08a3 sensor driver
+ *
+ * Copyright 2023 MediaTek
+ *
+ * Zhi Mao <zhi.mao at mediatek.com>
+ */
+
+#include <asm/unaligned.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <media/media-entity.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-fwnode.h>
+#include <media/v4l2-subdev.h>
+
+#define GC08A3_REG_VALUE_08BIT 1
+#define GC08A3_REG_VALUE_16BIT 2
+
+#define GC08A3_REG_CHIP_ID 0x03f0
+#define GC08A3_CHIP_ID 0x08a3
+
+#define GC08A3_NATIVE_WIDTH 3264
+#define GC08A3_NATIVE_HEIGHT 2448
+
+#define GC08A3_REG_TEST_PATTERN_EN 0x008c
+#define GC08A3_REG_TEST_PATTERN_IDX 0x008d
+#define GC08A3_TEST_PATTERN_EN 0x01
+
+#define GC08A3_STRAEMING_REG 0x0100
+
+#define GC08A3_DEFAULT_CLK_FREQ 24000000
+#define GC08A3_MBUS_CODE MEDIA_BUS_FMT_SRGGB10_1X10
+#define GC08A3_DATA_LANES 4
+
+/* for 1920*1080 */
+#define GC08A3_LINK_FREQ_207MHZ 207000000ULL
+/* for 3264*2448 */
+#define GC08A3_LINK_FREQ_336MHZ 336000000ULL
+
+#define GC08A3_RGB_DEPTH 10
+
+#define GC08A3_FRAME_LENGTH_REG 0x0340
+#define GC08A3_VTS_30FPS 2548
+#define GC08A3_VTS_30FPS_MIN 2548
+#define GC08A3_VTS_60FPS 1276
+#define GC08A3_VTS_60FPS_MIN 1276
+#define GC08A3_VTS_MAX 0xfff0
+
+#define GC08A3_HTS_30FPS 3640
+#define GC08A3_HTS_60FPS 3640
+
+#define GC08A3_EXP_REG 0x0202
+#define GC08A3_EXP_MARGIN 16
+#define GC08A3_EXP_MIN 4
+#define GC08A3_EXP_STEP 1
+
+#define GC08A3_FLIP_REG 0x0101
+#define GC08A3_FLIP_H_MASK 0x1
+#define GC08A3_FLIP_V_MASK 0x2
+
+#define GC08A3_AGAIN_REG 0x0204
+#define GC08A3_AGAIN_MIN 1024
+#define GC08A3_AGAIN_MAX (1024 * 16)
+#define GC08A3_AGAIN_STEP 1
+
+#define GC08A3_MIN_SLEEP_US  2000
+#define GC08A3_MAX_SLEEP_US  3000
+
+static const char *const gc08a3_test_pattern_menu[] = {
+	"No Pattern", "Solid Black", "Colour Bar", "Solid White",
+	"Solid Red", "Solid Green", "Solid Blue", "Solid Yellow",
+};
+
+enum {
+	GC08A3_LINK_FREQ_336MHZ_INDEX,
+	GC08A3_LINK_FREQ_207MHZ_INDEX,
+};
+
+static const s64 link_freq_menu_items[] = {
+	GC08A3_LINK_FREQ_336MHZ,
+	GC08A3_LINK_FREQ_207MHZ,
+};
+
+static const char *const gc08a3_supply_name[] = {
+	"avdd",
+	"dvdd",
+	"dovdd",
+};
+
+#define GC08A3_NUM_SUPPLIES ARRAY_SIZE(gc08a3_supply_name)
+
+struct gc08a3 {
+	struct device *dev;
+	struct v4l2_subdev sd;
+	struct media_pad pad;
+	struct v4l2_mbus_framefmt fmt;
+	struct i2c_client *client;
+
+	struct v4l2_rect crop;
+
+	struct clk *xclk;
+	struct regulator_bulk_data supplies[GC08A3_NUM_SUPPLIES];
+	struct gpio_desc *enable_gpio;
+
+	struct v4l2_ctrl_handler ctrls;
+	struct v4l2_ctrl *pixel_rate;
+	struct v4l2_ctrl *link_freq;
+	struct v4l2_ctrl *exposure;
+	struct v4l2_ctrl *vblank;
+	struct v4l2_ctrl *hblank;
+
+	/*
+	 * Serialize control access, get/set format, get selection
+	 * and start streaming.
+	 */
+	struct mutex mutex;
+
+	bool streaming;
+
+	/* Current mode */
+	const struct gc08a3_mode *cur_mode;
+};
+
+struct gc08a3_reg {
+	u16 address;
+	u8 val;
+};
+
+struct gc08a3_reg_list {
+	u32 num_of_regs;
+	const struct gc08a3_reg *regs;
+};
+
+struct gc08a3_link_freq_config {
+	const struct gc08a3_reg_list reg_list;
+};
+
+static const struct gc08a3_reg mode_3264x2448[] = {
+	/* system */
+	{ 0x031c, 0x60 },
+	{ 0x0337, 0x04 },
+	{ 0x0335, 0x51 },
+	{ 0x0336, 0x70 },
+	{ 0x0383, 0xbb },
+	{ 0x031a, 0x00 },
+	{ 0x0321, 0x10 },
+	{ 0x0327, 0x03 },
+	{ 0x0325, 0x40 },
+	{ 0x0326, 0x23 },
+	{ 0x0314, 0x11 },
+	{ 0x0315, 0xd6 },
+	{ 0x0316, 0x01 },
+	{ 0x0334, 0x40 },
+	{ 0x0324, 0x42 },
+	{ 0x031c, 0x00 },
+	{ 0x031c, 0x9f },
+	{ 0x0344, 0x00 },
+	{ 0x0345, 0x06 },
+	{ 0x0346, 0x00 },
+	{ 0x0347, 0x04 },
+	{ 0x0348, 0x0c },
+	{ 0x0349, 0xd0 },
+	{ 0x034a, 0x09 },
+	{ 0x034b, 0x9c },
+	{ 0x0202, 0x09 },
+	{ 0x0203, 0x04 },
+	{ 0x0340, 0x09 },
+	{ 0x0341, 0xf4 },
+	{ 0x0342, 0x07 },
+	{ 0x0343, 0x1c },
+
+	{ 0x0226, 0x00 },
+	{ 0x0227, 0x28 },
+	{ 0x0e38, 0x49 },
+	{ 0x0210, 0x13 },
+	{ 0x0218, 0x00 },
+	{ 0x0241, 0x88 },
+	{ 0x0392, 0x60 },
+
+	/* ISP */
+	{ 0x031c, 0x80 },
+	{ 0x03fe, 0x10 },
+	{ 0x03fe, 0x00 },
+	{ 0x031c, 0x9f },
+	{ 0x03fe, 0x00 },
+	{ 0x03fe, 0x00 },
+	{ 0x03fe, 0x00 },
+	{ 0x03fe, 0x00 },
+	{ 0x031c, 0x80 },
+	{ 0x03fe, 0x10 },
+	{ 0x03fe, 0x00 },
+	{ 0x031c, 0x9f },
+	{ 0x00a2, 0x00 },
+	{ 0x00a3, 0x00 },
+	{ 0x00ab, 0x00 },
+	{ 0x00ac, 0x00 },
+	{ 0x05a0, 0x82 },
+	{ 0x05ac, 0x00 },
+	{ 0x05ad, 0x01 },
+	{ 0x05ae, 0x00 },
+	{ 0x0800, 0x0a },
+	{ 0x0801, 0x14 },
+	{ 0x0802, 0x28 },
+	{ 0x0803, 0x34 },
+	{ 0x0804, 0x0e },
+	{ 0x0805, 0x33 },
+	{ 0x0806, 0x03 },
+	{ 0x0807, 0x8a },
+	{ 0x0808, 0x50 },
+	{ 0x0809, 0x00 },
+	{ 0x080a, 0x34 },
+	{ 0x080b, 0x03 },
+	{ 0x080c, 0x26 },
+	{ 0x080d, 0x03 },
+	{ 0x080e, 0x18 },
+	{ 0x080f, 0x03 },
+	{ 0x0810, 0x10 },
+	{ 0x0811, 0x03 },
+	{ 0x0812, 0x00 },
+	{ 0x0813, 0x00 },
+	{ 0x0814, 0x01 },
+	{ 0x0815, 0x00 },
+	{ 0x0816, 0x01 },
+	{ 0x0817, 0x00 },
+	{ 0x0818, 0x00 },
+	{ 0x0819, 0x0a },
+	{ 0x081a, 0x01 },
+	{ 0x081b, 0x6c },
+	{ 0x081c, 0x00 },
+	{ 0x081d, 0x0b },
+	{ 0x081e, 0x02 },
+	{ 0x081f, 0x00 },
+	{ 0x0820, 0x00 },
+	{ 0x0821, 0x0c },
+	{ 0x0822, 0x02 },
+	{ 0x0823, 0xd9 },
+	{ 0x0824, 0x00 },
+	{ 0x0825, 0x0d },
+	{ 0x0826, 0x03 },
+	{ 0x0827, 0xf0 },
+	{ 0x0828, 0x00 },
+	{ 0x0829, 0x0e },
+	{ 0x082a, 0x05 },
+	{ 0x082b, 0x94 },
+	{ 0x082c, 0x09 },
+	{ 0x082d, 0x6e },
+	{ 0x082e, 0x07 },
+	{ 0x082f, 0xe6 },
+	{ 0x0830, 0x10 },
+	{ 0x0831, 0x0e },
+	{ 0x0832, 0x0b },
+	{ 0x0833, 0x2c },
+	{ 0x0834, 0x14 },
+	{ 0x0835, 0xae },
+	{ 0x0836, 0x0f },
+	{ 0x0837, 0xc4 },
+	{ 0x0838, 0x18 },
+	{ 0x0839, 0x0e },
+	{ 0x05ac, 0x01 },
+	{ 0x059a, 0x00 },
+	{ 0x059b, 0x00 },
+	{ 0x059c, 0x01 },
+	{ 0x0598, 0x00 },
+	{ 0x0597, 0x14 },
+	{ 0x05ab, 0x09 },
+	{ 0x05a4, 0x02 },
+	{ 0x05a3, 0x05 },
+	{ 0x05a0, 0xc2 },
+	{ 0x0207, 0xc4 },
+
+	/* GAIN */
+	{ 0x0204, 0x04 },
+	{ 0x0205, 0x00 },
+	{ 0x0050, 0x5c },
+	{ 0x0051, 0x44 },
+
+	/* out window */
+	{ 0x009a, 0x66 },
+	{ 0x0351, 0x00 },
+	{ 0x0352, 0x06 },
+	{ 0x0353, 0x00 },
+	{ 0x0354, 0x08 },
+	{ 0x034c, 0x0c },
+	{ 0x034d, 0xc0 },
+	{ 0x034e, 0x09 },
+	{ 0x034f, 0x90 },
+
+	/* MIPI */
+	{ 0x0114, 0x03 },
+	{ 0x0180, 0x65 },
+	{ 0x0181, 0xf0 },
+	{ 0x0185, 0x01 },
+	{ 0x0115, 0x30 },
+	{ 0x011b, 0x12 },
+	{ 0x011c, 0x12 },
+	{ 0x0121, 0x06 },
+	{ 0x0122, 0x06 },
+	{ 0x0123, 0x15 },
+	{ 0x0124, 0x01 },
+	{ 0x0125, 0x0b },
+	{ 0x0126, 0x08 },
+	{ 0x0129, 0x06 },
+	{ 0x012a, 0x08 },
+	{ 0x012b, 0x08 },
+
+	{ 0x0a73, 0x60 },
+	{ 0x0a70, 0x11 },
+	{ 0x0313, 0x80 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0a70, 0x00 },
+	{ 0x00a4, 0x80 },
+	{ 0x0316, 0x01 },
+	{ 0x0a67, 0x00 },
+	{ 0x0084, 0x10 },
+	{ 0x0102, 0x09 },
+};
+
+static const struct gc08a3_reg mode_1920x1080[] = {
+	/* system */
+	{ 0x031c, 0x60 },
+	{ 0x0337, 0x04 },
+	{ 0x0335, 0x51 },
+	{ 0x0336, 0x45 },
+	{ 0x0383, 0x8b },
+	{ 0x031a, 0x00 },
+	{ 0x0321, 0x10 },
+	{ 0x0327, 0x03 },
+	{ 0x0325, 0x40 },
+	{ 0x0326, 0x23 },
+	{ 0x0314, 0x11 },
+	{ 0x0315, 0xd6 },
+	{ 0x0316, 0x01 },
+	{ 0x0334, 0x40 },
+	{ 0x0324, 0x42 },
+	{ 0x031c, 0x00 },
+	{ 0x031c, 0x9f },
+	{ 0x0344, 0x02 },
+	{ 0x0345, 0xa6 },
+	{ 0x0346, 0x02 },
+	{ 0x0347, 0xb0 },
+	{ 0x0348, 0x07 },
+	{ 0x0349, 0x90 },
+	{ 0x034a, 0x04 },
+	{ 0x034b, 0x44 },
+	{ 0x0202, 0x03 },
+	{ 0x0203, 0x00 },
+	{ 0x0340, 0x04 },
+	{ 0x0341, 0xfc },
+	{ 0x0342, 0x07 },
+	{ 0x0343, 0x1c },
+
+	{ 0x0226, 0x00 },
+	{ 0x0227, 0x88 },
+	{ 0x0e38, 0x49 },
+	{ 0x0210, 0x13 },
+	{ 0x0218, 0x00 },
+	{ 0x0241, 0x88 },
+	{ 0x0392, 0x60 },
+
+	/* ISP */
+	{ 0x031c, 0x80 },
+	{ 0x03fe, 0x10 },
+	{ 0x03fe, 0x00 },
+	{ 0x031c, 0x9f },
+	{ 0x03fe, 0x00 },
+	{ 0x03fe, 0x00 },
+	{ 0x03fe, 0x00 },
+	{ 0x03fe, 0x00 },
+	{ 0x031c, 0x80 },
+	{ 0x03fe, 0x10 },
+	{ 0x03fe, 0x00 },
+	{ 0x031c, 0x9f },
+	{ 0x00a2, 0xac },
+	{ 0x00a3, 0x02 },
+	{ 0x00ab, 0xa0 },
+	{ 0x00ac, 0x02 },
+	{ 0x05a0, 0x82 },
+	{ 0x05ac, 0x00 },
+	{ 0x05ad, 0x01 },
+	{ 0x05ae, 0x00 },
+	{ 0x0800, 0x0a },
+	{ 0x0801, 0x14 },
+	{ 0x0802, 0x28 },
+	{ 0x0803, 0x34 },
+	{ 0x0804, 0x0e },
+	{ 0x0805, 0x33 },
+	{ 0x0806, 0x03 },
+	{ 0x0807, 0x8a },
+	{ 0x0808, 0x50 },
+	{ 0x0809, 0x00 },
+	{ 0x080a, 0x34 },
+	{ 0x080b, 0x03 },
+	{ 0x080c, 0x26 },
+	{ 0x080d, 0x03 },
+	{ 0x080e, 0x18 },
+	{ 0x080f, 0x03 },
+	{ 0x0810, 0x10 },
+	{ 0x0811, 0x03 },
+	{ 0x0812, 0x00 },
+	{ 0x0813, 0x00 },
+	{ 0x0814, 0x01 },
+	{ 0x0815, 0x00 },
+	{ 0x0816, 0x01 },
+	{ 0x0817, 0x00 },
+	{ 0x0818, 0x00 },
+	{ 0x0819, 0x0a },
+	{ 0x081a, 0x01 },
+	{ 0x081b, 0x6c },
+	{ 0x081c, 0x00 },
+	{ 0x081d, 0x0b },
+	{ 0x081e, 0x02 },
+	{ 0x081f, 0x00 },
+	{ 0x0820, 0x00 },
+	{ 0x0821, 0x0c },
+	{ 0x0822, 0x02 },
+	{ 0x0823, 0xd9 },
+	{ 0x0824, 0x00 },
+	{ 0x0825, 0x0d },
+	{ 0x0826, 0x03 },
+	{ 0x0827, 0xf0 },
+	{ 0x0828, 0x00 },
+	{ 0x0829, 0x0e },
+	{ 0x082a, 0x05 },
+	{ 0x082b, 0x94 },
+	{ 0x082c, 0x09 },
+	{ 0x082d, 0x6e },
+	{ 0x082e, 0x07 },
+	{ 0x082f, 0xe6 },
+	{ 0x0830, 0x10 },
+	{ 0x0831, 0x0e },
+	{ 0x0832, 0x0b },
+	{ 0x0833, 0x2c },
+	{ 0x0834, 0x14 },
+	{ 0x0835, 0xae },
+	{ 0x0836, 0x0f },
+	{ 0x0837, 0xc4 },
+	{ 0x0838, 0x18 },
+	{ 0x0839, 0x0e },
+	{ 0x05ac, 0x01 },
+	{ 0x059a, 0x00 },
+	{ 0x059b, 0x00 },
+	{ 0x059c, 0x01 },
+	{ 0x0598, 0x00 },
+	{ 0x0597, 0x14 },
+	{ 0x05ab, 0x09 },
+	{ 0x05a4, 0x02 },
+	{ 0x05a3, 0x05 },
+	{ 0x05a0, 0xc2 },
+	{ 0x0207, 0xc4 },
+
+	/* GAIN */
+	{ 0x0204, 0x04 },
+	{ 0x0205, 0x00 },
+	{ 0x0050, 0x38 },
+	{ 0x0051, 0x20 },
+
+	/* out window */
+	{ 0x009a, 0x66 },
+	{ 0x0351, 0x00 },
+	{ 0x0352, 0x06 },
+	{ 0x0353, 0x00 },
+	{ 0x0354, 0x08 },
+	{ 0x034c, 0x07 },
+	{ 0x034d, 0x80 },
+	{ 0x034e, 0x04 },
+	{ 0x034f, 0x38 },
+
+	/* MIPI */
+	{ 0x0114, 0x03 },
+	{ 0x0180, 0x65 },
+	{ 0x0181, 0xf0 },
+	{ 0x0185, 0x01 },
+	{ 0x0115, 0x30 },
+	{ 0x011b, 0x12 },
+	{ 0x011c, 0x12 },
+	{ 0x0121, 0x02 },
+	{ 0x0122, 0x03 },
+	{ 0x0123, 0x0c },
+	{ 0x0124, 0x00 },
+	{ 0x0125, 0x09 },
+	{ 0x0126, 0x06 },
+	{ 0x0129, 0x04 },
+	{ 0x012a, 0x03 },
+	{ 0x012b, 0x06 },
+
+	{ 0x0a73, 0x60 },
+	{ 0x0a70, 0x11 },
+	{ 0x0313, 0x80 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0aff, 0x00 },
+	{ 0x0a70, 0x00 },
+	{ 0x00a4, 0x80 },
+	{ 0x0316, 0x01 },
+	{ 0x0a67, 0x00 },
+	{ 0x0084, 0x10 },
+	{ 0x0102, 0x09 },
+};
+
+static const struct gc08a3_reg mode_table_common[] = {
+	{ GC08A3_STRAEMING_REG, 0x00 },
+	/* system */
+	{ 0x031c, 0x60 },
+	{ 0x0337, 0x04 },
+	{ 0x0335, 0x51 },
+	{ 0x0336, 0x70 },
+	{ 0x0383, 0xbb },
+	{ 0x031a, 0x00 },
+	{ 0x0321, 0x10 },
+	{ 0x0327, 0x03 },
+	{ 0x0325, 0x40 },
+	{ 0x0326, 0x23 },
+	{ 0x0314, 0x11 },
+	{ 0x0315, 0xd6 },
+	{ 0x0316, 0x01 },
+	{ 0x0334, 0x40 },
+	{ 0x0324, 0x42 },
+	{ 0x031c, 0x00 },
+	{ 0x031c, 0x9f },
+	{ 0x039a, 0x13 },
+	{ 0x0084, 0x30 },
+	{ 0x02b3, 0x08 },
+	{ 0x0057, 0x0c },
+	{ 0x05c3, 0x50 },
+	{ 0x0311, 0x90 },
+	{ 0x05a0, 0x02 },
+	{ 0x0074, 0x0a },
+	{ 0x0059, 0x11 },
+	{ 0x0070, 0x05 },
+	{ 0x0101, 0x00 },
+
+	/* analog */
+	{ 0x0344, 0x00 },
+	{ 0x0345, 0x06 },
+	{ 0x0346, 0x00 },
+	{ 0x0347, 0x04 },
+	{ 0x0348, 0x0c },
+	{ 0x0349, 0xd0 },
+	{ 0x034a, 0x09 },
+	{ 0x034b, 0x9c },
+	{ 0x0202, 0x09 },
+	{ 0x0203, 0x04 },
+
+	{ 0x0219, 0x05 },
+	{ 0x0226, 0x00 },
+	{ 0x0227, 0x28 },
+	{ 0x0e0a, 0x00 },
+	{ 0x0e0b, 0x00 },
+	{ 0x0e24, 0x04 },
+	{ 0x0e25, 0x04 },
+	{ 0x0e26, 0x00 },
+	{ 0x0e27, 0x10 },
+	{ 0x0e01, 0x74 },
+	{ 0x0e03, 0x47 },
+	{ 0x0e04, 0x33 },
+	{ 0x0e05, 0x44 },
+	{ 0x0e06, 0x44 },
+	{ 0x0e0c, 0x1e },
+	{ 0x0e17, 0x3a },
+	{ 0x0e18, 0x3c },
+	{ 0x0e19, 0x40 },
+	{ 0x0e1a, 0x42 },
+	{ 0x0e28, 0x21 },
+	{ 0x0e2b, 0x68 },
+	{ 0x0e2c, 0x0d },
+	{ 0x0e2d, 0x08 },
+	{ 0x0e34, 0xf4 },
+	{ 0x0e35, 0x44 },
+	{ 0x0e36, 0x07 },
+	{ 0x0e38, 0x49 },
+	{ 0x0210, 0x13 },
+	{ 0x0218, 0x00 },
+	{ 0x0241, 0x88 },
+	{ 0x0e32, 0x00 },
+	{ 0x0e33, 0x18 },
+	{ 0x0e42, 0x03 },
+	{ 0x0e43, 0x80 },
+	{ 0x0e44, 0x04 },
+	{ 0x0e45, 0x00 },
+	{ 0x0e4f, 0x04 },
+	{ 0x057a, 0x20 },
+	{ 0x0381, 0x7c },
+	{ 0x0382, 0x9b },
+	{ 0x0384, 0xfb },
+	{ 0x0389, 0x38 },
+	{ 0x038a, 0x03 },
+	{ 0x0390, 0x6a },
+	{ 0x0391, 0x0b },
+	{ 0x0392, 0x60 },
+	{ 0x0393, 0xc1 },
+	{ 0x0396, 0xff },
+	{ 0x0398, 0x62 },
+
+	/* cisctl reset */
+	{ 0x031c, 0x80 },
+	{ 0x03fe, 0x10 },
+	{ 0x03fe, 0x00 },
+	{ 0x031c, 0x9f },
+	{ 0x03fe, 0x00 },
+	{ 0x03fe, 0x00 },
+	{ 0x03fe, 0x00 },
+	{ 0x03fe, 0x00 },
+	{ 0x031c, 0x80 },
+	{ 0x03fe, 0x10 },
+	{ 0x03fe, 0x00 },
+	{ 0x031c, 0x9f },
+	{ 0x0360, 0x01 },
+	{ 0x0360, 0x00 },
+	{ 0x0316, 0x09 },
+	{ 0x0a67, 0x80 },
+	{ 0x0313, 0x00 },
+	{ 0x0a53, 0x0e },
+	{ 0x0a65, 0x17 },
+	{ 0x0a68, 0xa1 },
+	{ 0x0a58, 0x00 },
+	{ 0x0ace, 0x0c },
+	{ 0x00a4, 0x00 },
+	{ 0x00a5, 0x01 },
+	{ 0x00a7, 0x09 },
+	{ 0x00a8, 0x9c },
+	{ 0x00a9, 0x0c },
+	{ 0x00aa, 0xd0 },
+	{ 0x0a8a, 0x00 },
+	{ 0x0a8b, 0xe0 },
+	{ 0x0a8c, 0x13 },
+	{ 0x0a8d, 0xe8 },
+	{ 0x0a90, 0x0a },
+	{ 0x0a91, 0x10 },
+	{ 0x0a92, 0xf8 },
+	{ 0x0a71, 0xf2 },
+	{ 0x0a72, 0x12 },
+	{ 0x0a73, 0x64 },
+	{ 0x0a75, 0x41 },
+	{ 0x0a70, 0x07 },
+	{ 0x0313, 0x80 },
+
+	/* ISP */
+	{ 0x00a0, 0x01 },
+	{ 0x0080, 0xd2 },
+	{ 0x0081, 0x3f },
+	{ 0x0087, 0x51 },
+	{ 0x0089, 0x03 },
+	{ 0x009b, 0x40 },
+	{ 0x05a0, 0x82 },
+	{ 0x05ac, 0x00 },
+	{ 0x05ad, 0x01 },
+	{ 0x05ae, 0x00 },
+	{ 0x0800, 0x0a },
+	{ 0x0801, 0x14 },
+	{ 0x0802, 0x28 },
+	{ 0x0803, 0x34 },
+	{ 0x0804, 0x0e },
+	{ 0x0805, 0x33 },
+	{ 0x0806, 0x03 },
+	{ 0x0807, 0x8a },
+	{ 0x0808, 0x50 },
+	{ 0x0809, 0x00 },
+	{ 0x080a, 0x34 },
+	{ 0x080b, 0x03 },
+	{ 0x080c, 0x26 },
+	{ 0x080d, 0x03 },
+	{ 0x080e, 0x18 },
+	{ 0x080f, 0x03 },
+	{ 0x0810, 0x10 },
+	{ 0x0811, 0x03 },
+	{ 0x0812, 0x00 },
+	{ 0x0813, 0x00 },
+	{ 0x0814, 0x01 },
+	{ 0x0815, 0x00 },
+	{ 0x0816, 0x01 },
+	{ 0x0817, 0x00 },
+	{ 0x0818, 0x00 },
+	{ 0x0819, 0x0a },
+	{ 0x081a, 0x01 },
+	{ 0x081b, 0x6c },
+	{ 0x081c, 0x00 },
+	{ 0x081d, 0x0b },
+	{ 0x081e, 0x02 },
+	{ 0x081f, 0x00 },
+	{ 0x0820, 0x00 },
+	{ 0x0821, 0x0c },
+	{ 0x0822, 0x02 },
+	{ 0x0823, 0xd9 },
+	{ 0x0824, 0x00 },
+	{ 0x0825, 0x0d },
+	{ 0x0826, 0x03 },
+	{ 0x0827, 0xf0 },
+	{ 0x0828, 0x00 },
+	{ 0x0829, 0x0e },
+	{ 0x082a, 0x05 },
+	{ 0x082b, 0x94 },
+	{ 0x082c, 0x09 },
+	{ 0x082d, 0x6e },
+	{ 0x082e, 0x07 },
+	{ 0x082f, 0xe6 },
+	{ 0x0830, 0x10 },
+	{ 0x0831, 0x0e },
+	{ 0x0832, 0x0b },
+	{ 0x0833, 0x2c },
+	{ 0x0834, 0x14 },
+	{ 0x0835, 0xae },
+	{ 0x0836, 0x0f },
+	{ 0x0837, 0xc4 },
+	{ 0x0838, 0x18 },
+	{ 0x0839, 0x0e },
+	{ 0x05ac, 0x01 },
+	{ 0x059a, 0x00 },
+	{ 0x059b, 0x00 },
+	{ 0x059c, 0x01 },
+	{ 0x0598, 0x00 },
+	{ 0x0597, 0x14 },
+	{ 0x05ab, 0x09 },
+	{ 0x05a4, 0x02 },
+	{ 0x05a3, 0x05 },
+	{ 0x05a0, 0xc2 },
+	{ 0x0207, 0xc4 },
+
+	/* GAIN */
+	{ 0x0208, 0x01 },
+	{ 0x0209, 0x72 },
+	{ 0x0204, 0x04 },
+	{ 0x0205, 0x00 },
+
+	{ 0x0040, 0x22 },
+	{ 0x0041, 0x20 },
+	{ 0x0043, 0x10 },
+	{ 0x0044, 0x00 },
+	{ 0x0046, 0x08 },
+	{ 0x0047, 0xf0 },
+	{ 0x0048, 0x0f },
+	{ 0x004b, 0x0f },
+	{ 0x004c, 0x00 },
+	{ 0x0050, 0x5c },
+	{ 0x0051, 0x44 },
+	{ 0x005b, 0x03 },
+	{ 0x00c0, 0x00 },
+	{ 0x00c1, 0x80 },
+	{ 0x00c2, 0x31 },
+	{ 0x00c3, 0x00 },
+	{ 0x0460, 0x04 },
+	{ 0x0462, 0x08 },
+	{ 0x0464, 0x0e },
+	{ 0x0466, 0x0a },
+	{ 0x0468, 0x12 },
+	{ 0x046a, 0x12 },
+	{ 0x046c, 0x10 },
+	{ 0x046e, 0x0c },
+	{ 0x0461, 0x03 },
+	{ 0x0463, 0x03 },
+	{ 0x0465, 0x03 },
+	{ 0x0467, 0x03 },
+	{ 0x0469, 0x04 },
+	{ 0x046b, 0x04 },
+	{ 0x046d, 0x04 },
+	{ 0x046f, 0x04 },
+	{ 0x0470, 0x04 },
+	{ 0x0472, 0x10 },
+	{ 0x0474, 0x26 },
+	{ 0x0476, 0x38 },
+	{ 0x0478, 0x20 },
+	{ 0x047a, 0x30 },
+	{ 0x047c, 0x38 },
+	{ 0x047e, 0x60 },
+	{ 0x0471, 0x05 },
+	{ 0x0473, 0x05 },
+	{ 0x0475, 0x05 },
+	{ 0x0477, 0x05 },
+	{ 0x0479, 0x04 },
+	{ 0x047b, 0x04 },
+	{ 0x047d, 0x04 },
+	{ 0x047f, 0x04 },
+};
+
+static const struct gc08a3_link_freq_config link_freq_configs[] = {
+	[GC08A3_LINK_FREQ_336MHZ_INDEX] = {
+		.reg_list = {
+			.num_of_regs = ARRAY_SIZE(mode_table_common),
+			.regs = mode_table_common,
+		}
+	},
+	[GC08A3_LINK_FREQ_207MHZ_INDEX] = {
+		.reg_list = {
+			.num_of_regs = ARRAY_SIZE(mode_table_common),
+			.regs = mode_table_common,
+		}
+	},
+
+};
+
+struct gc08a3_mode {
+	u32 width;
+	u32 height;
+	const struct gc08a3_reg_list reg_list;
+
+	u32 hts; /* Horizontal timining size */
+	u32 vts_def; /* Default vertical timining size */
+	u32 vts_min; /* Min vertical timining size */
+	u32 link_freq_index; /* Link frequency needed for this resolution */
+	u32 max_framerate;
+
+};
+
+/*
+ * Declare modes in order, from biggest
+ * to smallest height.
+ */
+static const struct gc08a3_mode gc08a3_modes[] = {
+	{
+		.width = GC08A3_NATIVE_WIDTH,
+		.height = GC08A3_NATIVE_HEIGHT,
+		.reg_list = {
+			.num_of_regs = ARRAY_SIZE(mode_3264x2448),
+			.regs = mode_3264x2448,
+		},
+		.link_freq_index = GC08A3_LINK_FREQ_336MHZ_INDEX,
+
+		.hts = GC08A3_HTS_30FPS,
+		.vts_def = GC08A3_VTS_30FPS,
+		.vts_min = GC08A3_VTS_30FPS_MIN,
+		.max_framerate = 300,
+	},
+	{
+		.width = 1920,
+		.height = 1080,
+		.reg_list = {
+			.num_of_regs = ARRAY_SIZE(mode_1920x1080),
+			.regs = mode_1920x1080,
+		},
+		.link_freq_index = GC08A3_LINK_FREQ_207MHZ_INDEX,
+
+		.hts = GC08A3_HTS_60FPS,
+		.vts_def = GC08A3_VTS_60FPS,
+		.vts_min = GC08A3_VTS_60FPS_MIN,
+		.max_framerate = 600,
+	},
+};
+
+static u64 to_pixel_rate(u32 f_index)
+{
+	u64 pixel_rate = link_freq_menu_items[f_index] * 2 * GC08A3_DATA_LANES;
+
+	do_div(pixel_rate, GC08A3_RGB_DEPTH);
+
+	return pixel_rate;
+}
+
+static int gc08a3_read_reg(struct gc08a3 *gc08a3, u16 reg, u16 len, u32 *val)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
+	struct i2c_msg msgs[2];
+	u8 addr_buf[2];
+	u8 data_buf[4] = { 0 };
+	int ret;
+
+	if (len > 4)
+		return -EINVAL;
+
+	put_unaligned_be16(reg, addr_buf);
+	msgs[0].addr = client->addr;
+	msgs[0].flags = 0;
+	msgs[0].len = sizeof(addr_buf);
+	msgs[0].buf = addr_buf;
+	msgs[1].addr = client->addr;
+	msgs[1].flags = I2C_M_RD;
+	msgs[1].len = len;
+	msgs[1].buf = &data_buf[4 - len];
+
+	ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
+	if (ret != ARRAY_SIZE(msgs))
+		return -EIO;
+
+	*val = get_unaligned_be32(data_buf);
+
+	return 0;
+}
+
+static int gc08a3_write_reg(struct gc08a3 *gc08a3, u16 reg, u16 len, u32 val)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
+	u8 buf[6];
+
+	if (len > 4)
+		return -EINVAL;
+
+	put_unaligned_be16(reg, buf);
+	put_unaligned_be32(val << 8 * (4 - len), buf + 2);
+	if (i2c_master_send(client, buf, len + 2) != len + 2)
+		return -EIO;
+
+	return 0;
+}
+
+static int gc08a3_write_reg_list(struct gc08a3 *gc08a3,
+				 const struct gc08a3_reg_list *r_list)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
+	unsigned int i;
+	int ret;
+
+	for (i = 0; i < r_list->num_of_regs; i++) {
+		ret = gc08a3_write_reg(gc08a3, r_list->regs[i].address,
+				       GC08A3_REG_VALUE_08BIT,
+				       r_list->regs[i].val);
+		if (ret) {
+			dev_err_ratelimited(&client->dev,
+					    "failed to write reg 0x%4.4x. error = %d",
+					    r_list->regs[i].address, ret);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int gc08a3_identify_module(struct gc08a3 *gc08a3)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
+	u32 val = 0;
+
+	gc08a3_read_reg(gc08a3, GC08A3_REG_CHIP_ID, GC08A3_REG_VALUE_16BIT,
+			&val);
+
+	if (val != GC08A3_CHIP_ID) {
+		dev_err(&client->dev, "chip id mismatch: 0x%x!=0x%x",
+			GC08A3_CHIP_ID, val);
+		return -ENXIO;
+	}
+
+	return 0;
+}
+
+static inline struct gc08a3 *to_gc08a3(struct v4l2_subdev *sd)
+{
+	return container_of(sd, struct gc08a3, sd);
+}
+
+static int gc08a3_power_on(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct v4l2_subdev *sd = i2c_get_clientdata(client);
+	struct gc08a3 *gc08a3 = to_gc08a3(sd);
+	int ret;
+
+	gpiod_set_value_cansleep(gc08a3->enable_gpio, 0);
+	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
+
+	ret = regulator_bulk_enable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
+	if (ret < 0) {
+		dev_err(gc08a3->dev, "failed to enable regulators: %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(gc08a3->xclk);
+	if (ret < 0) {
+		regulator_bulk_disable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
+		dev_err(gc08a3->dev, "clk prepare enable failed\n");
+		return ret;
+	}
+
+	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
+
+	gpiod_set_value_cansleep(gc08a3->enable_gpio, 1);
+	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
+
+	return 0;
+}
+
+static int gc08a3_power_off(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct v4l2_subdev *sd = i2c_get_clientdata(client);
+	struct gc08a3 *gc08a3 = to_gc08a3(sd);
+
+	gpiod_set_value_cansleep(gc08a3->enable_gpio, 0);
+
+	clk_disable_unprepare(gc08a3->xclk);
+
+	regulator_bulk_disable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
+	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
+
+	return 0;
+}
+
+static int gc08a3_enum_mbus_code(struct v4l2_subdev *sd,
+				 struct v4l2_subdev_state *sd_state,
+				 struct v4l2_subdev_mbus_code_enum *code)
+{
+	if (code->index > 0)
+		return -EINVAL;
+
+	code->code = GC08A3_MBUS_CODE;
+
+	return 0;
+}
+
+static int gc08a3_enum_frame_size(struct v4l2_subdev *subdev,
+				  struct v4l2_subdev_state *sd_state,
+				  struct v4l2_subdev_frame_size_enum *fse)
+{
+	if (fse->code != GC08A3_MBUS_CODE)
+		return -EINVAL;
+
+	if (fse->index >= ARRAY_SIZE(gc08a3_modes))
+		return -EINVAL;
+
+	fse->min_width = gc08a3_modes[fse->index].width;
+	fse->max_width = gc08a3_modes[fse->index].width;
+	fse->min_height = gc08a3_modes[fse->index].height;
+	fse->max_height = gc08a3_modes[fse->index].height;
+
+	return 0;
+}
+
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int gc08a3_g_register(struct v4l2_subdev *subdev,
+			     struct v4l2_dbg_register *reg)
+{
+	int ret;
+	u32 val;
+	struct gc08a3 *gc08a3 = container_of(subdev, struct gc08a3, sd);
+
+	ret = gc08a3_read_reg(gc08a3, reg->reg, GC08A3_REG_VALUE_08BIT, &val);
+	if (ret < 0)
+		return ret;
+
+	reg->val = val;
+	reg->size = 1;
+
+	return 0;
+}
+
+static int gc08a3_s_register(struct v4l2_subdev *subdev,
+			     const struct v4l2_dbg_register *reg)
+{
+	struct gc08a3 *gc08a3 = container_of(subdev, struct gc08a3, sd);
+
+	return gc08a3_write_reg(gc08a3, reg->reg, GC08A3_REG_VALUE_08BIT,
+				reg->val & 0xff);
+}
+
+#endif
+
+static const struct v4l2_subdev_core_ops gc08a3_core_ops = {
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+	.g_register = gc08a3_g_register,
+	.s_register = gc08a3_s_register,
+#endif
+};
+
+static struct v4l2_mbus_framefmt *
+__gc08a3_get_pad_format(struct gc08a3 *gc08a3,
+			struct v4l2_subdev_state *sd_state, unsigned int pad,
+			enum v4l2_subdev_format_whence which)
+{
+	switch (which) {
+	case V4L2_SUBDEV_FORMAT_TRY:
+		return v4l2_subdev_state_get_format(sd_state, pad);
+	case V4L2_SUBDEV_FORMAT_ACTIVE:
+		return &gc08a3->fmt;
+	default:
+		return NULL;
+	}
+}
+
+static int gc08a3_get_format(struct v4l2_subdev *sd,
+			     struct v4l2_subdev_state *sd_state,
+			     struct v4l2_subdev_format *format)
+{
+	struct gc08a3 *gc08a3 = to_gc08a3(sd);
+
+	mutex_lock(&gc08a3->mutex);
+	format->format = *__gc08a3_get_pad_format(gc08a3, sd_state, format->pad,
+						  format->which);
+	mutex_unlock(&gc08a3->mutex);
+
+	return 0;
+}
+
+static struct v4l2_rect *
+__gc08a3_get_pad_crop(struct gc08a3 *gc08a3, struct v4l2_subdev_state *sd_state,
+		      unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+	switch (which) {
+	case V4L2_SUBDEV_FORMAT_TRY:
+		return v4l2_subdev_state_get_crop(sd_state, pad);
+	case V4L2_SUBDEV_FORMAT_ACTIVE:
+		return &gc08a3->crop;
+	default:
+		return NULL;
+	}
+}
+
+static int gc08a3_update_cur_mode_controls(struct gc08a3 *gc08a3)
+{
+	s64 exposure_max, h_blank;
+	int ret = 0;
+
+	ret = __v4l2_ctrl_modify_range(gc08a3->vblank,
+				       gc08a3->cur_mode->vts_min - gc08a3->cur_mode->height,
+				       GC08A3_VTS_MAX - gc08a3->cur_mode->height, 1,
+				       gc08a3->cur_mode->vts_def - gc08a3->cur_mode->height);
+	if (ret)
+		dev_err(gc08a3->dev, "VB ctrl range update failed\n");
+
+	h_blank = gc08a3->cur_mode->hts - gc08a3->cur_mode->width;
+	ret = __v4l2_ctrl_modify_range(gc08a3->hblank, h_blank, h_blank, 1,
+				       h_blank);
+	if (ret)
+		dev_err(gc08a3->dev, "HB ctrl range update failed\n");
+
+	exposure_max = gc08a3->cur_mode->vts_def - GC08A3_EXP_MARGIN;
+	ret = __v4l2_ctrl_modify_range(gc08a3->exposure, GC08A3_EXP_MIN,
+				       exposure_max, GC08A3_EXP_STEP,
+				       exposure_max);
+	if (ret)
+		dev_err(gc08a3->dev, "exposure ctrl range update failed\n");
+
+	return ret;
+}
+
+static int gc08a3_set_format(struct v4l2_subdev *sd,
+			     struct v4l2_subdev_state *sd_state,
+			     struct v4l2_subdev_format *format)
+{
+	struct gc08a3 *gc08a3 = to_gc08a3(sd);
+	struct v4l2_mbus_framefmt *fmt;
+	struct v4l2_rect *crop;
+	const struct gc08a3_mode *mode;
+
+	mutex_lock(&gc08a3->mutex);
+
+	crop = __gc08a3_get_pad_crop(gc08a3, sd_state, format->pad,
+				     format->which);
+
+	mode = v4l2_find_nearest_size(gc08a3_modes, ARRAY_SIZE(gc08a3_modes),
+				      width, height, format->format.width,
+				      format->format.height);
+
+	crop->width = mode->width;
+	crop->height = mode->height;
+
+	fmt = __gc08a3_get_pad_format(gc08a3, sd_state, format->pad,
+				      format->which);
+	fmt->width = crop->width;
+	fmt->height = crop->height;
+	fmt->code = GC08A3_MBUS_CODE;
+	fmt->field = V4L2_FIELD_NONE;
+	fmt->colorspace = V4L2_COLORSPACE_SRGB;
+	fmt->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(fmt->colorspace);
+	fmt->quantization =
+		V4L2_MAP_QUANTIZATION_DEFAULT(true,
+					      fmt->colorspace,
+					      fmt->ycbcr_enc);
+	fmt->xfer_func = V4L2_MAP_XFER_FUNC_DEFAULT(fmt->colorspace);
+
+	format->format = *fmt;
+
+	gc08a3->cur_mode = mode;
+	gc08a3_update_cur_mode_controls(gc08a3);
+
+	mutex_unlock(&gc08a3->mutex);
+
+	return 0;
+}
+
+static int gc08a3_get_selection(struct v4l2_subdev *sd,
+				struct v4l2_subdev_state *sd_state,
+				struct v4l2_subdev_selection *sel)
+{
+	struct gc08a3 *gc08a3 = to_gc08a3(sd);
+
+	switch (sel->target) {
+	case V4L2_SEL_TGT_CROP:
+		mutex_lock(&gc08a3->mutex);
+		sel->r = *__gc08a3_get_pad_crop(gc08a3, sd_state, sel->pad, sel->which);
+		mutex_unlock(&gc08a3->mutex);
+		break;
+	case V4L2_SEL_TGT_CROP_BOUNDS:
+		sel->r.top = 0;
+		sel->r.left = 0;
+		sel->r.width = GC08A3_NATIVE_WIDTH;
+		sel->r.height = GC08A3_NATIVE_HEIGHT;
+		break;
+	case V4L2_SEL_TGT_CROP_DEFAULT:
+		if (gc08a3->cur_mode->width == GC08A3_NATIVE_WIDTH) {
+			sel->r.top = 0;
+			sel->r.left = 0;
+			sel->r.width = GC08A3_NATIVE_WIDTH;
+			sel->r.height = GC08A3_NATIVE_HEIGHT;
+		} else {
+			sel->r.top = 0;
+			sel->r.left = 0;
+			sel->r.width = 1920;
+			sel->r.height = 1080;
+		}
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int gc08a3_entity_init_cfg(struct v4l2_subdev *subdev,
+				  struct v4l2_subdev_state *sd_state)
+{
+	struct v4l2_subdev_format fmt = {};
+
+	fmt.which = sd_state ? V4L2_SUBDEV_FORMAT_TRY :
+			       V4L2_SUBDEV_FORMAT_ACTIVE;
+	fmt.format.width = gc08a3_modes[0].width;
+	fmt.format.height = gc08a3_modes[0].height;
+
+	gc08a3_set_format(subdev, sd_state, &fmt);
+
+	return 0;
+}
+
+static int gc08a3_set_ctrl_hflip(struct gc08a3 *gc08a3, u32 ctrl_val)
+{
+	int ret;
+	u32 val;
+
+	ret = gc08a3_read_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
+			      &val);
+	if (ret) {
+		dev_err(gc08a3->dev, "read hflip register failed: %d\n", ret);
+		return ret;
+	}
+
+	val = ctrl_val ? (val | GC08A3_FLIP_H_MASK) :
+			   (val & ~GC08A3_FLIP_H_MASK);
+	ret = gc08a3_write_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
+			       val);
+	if (ret < 0)
+		dev_err(gc08a3->dev, "Error %d\n", ret);
+
+	return ret;
+}
+
+static int gc08a3_set_ctrl_vflip(struct gc08a3 *gc08a3, u32 ctrl_val)
+{
+	int ret;
+	u32 val;
+
+	ret = gc08a3_read_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
+			      &val);
+	if (ret) {
+		dev_err(gc08a3->dev, "read vflip register failed: %d\n", ret);
+		return ret;
+	}
+
+	val = ctrl_val ? (val | GC08A3_FLIP_V_MASK) :
+			   (val & ~GC08A3_FLIP_V_MASK);
+	ret = gc08a3_write_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
+			       val);
+	if (ret < 0)
+		dev_err(gc08a3->dev, "Error %d\n", ret);
+
+	return ret;
+}
+
+static int gc08a3_test_pattern(struct gc08a3 *gc08a3, u32 pattern_menu)
+{
+	int ret = 0;
+	u32 pattern = 0;
+
+	if (pattern_menu) {
+		switch (pattern_menu) {
+		case 1:
+			pattern = 0x00;
+			break;
+		case 2:
+			pattern = 0x10;
+			break;
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 7:
+			pattern = pattern_menu + 1;
+			break;
+		}
+
+		ret = gc08a3_write_reg(gc08a3, GC08A3_REG_TEST_PATTERN_EN,
+				       GC08A3_REG_VALUE_08BIT,
+				       GC08A3_TEST_PATTERN_EN);
+		if (ret) {
+			dev_err(gc08a3->dev, "test pattern enable failed: %d\n", ret);
+			return ret;
+		}
+
+		ret = gc08a3_write_reg(gc08a3, GC08A3_REG_TEST_PATTERN_IDX,
+				       GC08A3_REG_VALUE_08BIT, pattern);
+		if (ret < 0)
+			dev_err(gc08a3->dev, "Error %d\n", ret);
+
+	} else {
+		ret = gc08a3_write_reg(gc08a3, GC08A3_REG_TEST_PATTERN_EN,
+				       GC08A3_REG_VALUE_08BIT, 0x00);
+		if (ret < 0)
+			dev_err(gc08a3->dev, "test pattern disable failed: %d\n", ret);
+	}
+
+	return ret;
+}
+
+static int gc08a3_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+	struct gc08a3 *gc08a3 =
+		container_of(ctrl->handler, struct gc08a3, ctrls);
+	int ret = 0;
+	s64 exposure_max;
+
+	if (ctrl->id == V4L2_CID_VBLANK) {
+		/* Update max exposure while meeting expected vblanking */
+		exposure_max = gc08a3->cur_mode->height + ctrl->val -
+			       GC08A3_EXP_MARGIN;
+		__v4l2_ctrl_modify_range(gc08a3->exposure,
+					 gc08a3->exposure->minimum,
+					 exposure_max, gc08a3->exposure->step,
+					 exposure_max);
+	}
+
+	/*
+	 * Applying V4L2 control value only happens
+	 * when power is up for streaming
+	 */
+	if (!pm_runtime_get_if_in_use(gc08a3->dev))
+		return 0;
+
+	switch (ctrl->id) {
+	case V4L2_CID_EXPOSURE:
+		ret = gc08a3_write_reg(gc08a3, GC08A3_EXP_REG,
+				       GC08A3_REG_VALUE_16BIT, ctrl->val);
+		break;
+
+	case V4L2_CID_ANALOGUE_GAIN:
+		ret = gc08a3_write_reg(gc08a3, GC08A3_AGAIN_REG,
+				       GC08A3_REG_VALUE_16BIT, ctrl->val);
+		break;
+
+	case V4L2_CID_VBLANK:
+		ret = gc08a3_write_reg(gc08a3, GC08A3_FRAME_LENGTH_REG,
+				       GC08A3_REG_VALUE_16BIT,
+				       gc08a3->cur_mode->height + ctrl->val);
+		break;
+
+	case V4L2_CID_HFLIP:
+		ret = gc08a3_set_ctrl_hflip(gc08a3, ctrl->val);
+		break;
+
+	case V4L2_CID_VFLIP:
+		ret = gc08a3_set_ctrl_vflip(gc08a3, ctrl->val);
+		break;
+
+	case V4L2_CID_TEST_PATTERN:
+		ret = gc08a3_test_pattern(gc08a3, ctrl->val);
+		break;
+
+	default:
+		break;
+	}
+
+	pm_runtime_put(gc08a3->dev);
+
+	return ret;
+}
+
+static int gc08a3_try_ctrl(struct v4l2_ctrl *ctrl)
+{
+	int ret = 0;
+
+	switch (ctrl->id) {
+	case V4L2_CID_EXPOSURE:
+	case V4L2_CID_ANALOGUE_GAIN:
+	case V4L2_CID_VBLANK:
+	case V4L2_CID_HFLIP:
+	case V4L2_CID_VFLIP:
+	case V4L2_CID_TEST_PATTERN:
+	default:
+		return 0;
+	}
+
+	return ret;
+}
+
+static const struct v4l2_ctrl_ops gc08a3_ctrl_ops = {
+	.try_ctrl = gc08a3_try_ctrl,
+	.s_ctrl = gc08a3_set_ctrl,
+};
+
+static int gc08a3_start_streaming(struct gc08a3 *gc08a3)
+{
+	const struct gc08a3_mode *mode;
+	const struct gc08a3_reg_list *reg_list;
+	int link_freq_index;
+	int ret;
+
+	mutex_lock(&gc08a3->mutex);
+
+	link_freq_index = gc08a3->cur_mode->link_freq_index;
+
+	reg_list = &link_freq_configs[link_freq_index].reg_list;
+	ret = gc08a3_write_reg_list(gc08a3, reg_list);
+	if (ret) {
+		dev_err(gc08a3->dev, "could not sent common table %d\n", ret);
+		goto error;
+	}
+
+	mode = gc08a3->cur_mode;
+	reg_list = &mode->reg_list;
+
+	ret = gc08a3_write_reg_list(gc08a3, reg_list);
+	if (ret < 0) {
+		dev_err(gc08a3->dev, "could not sent mode table %d\n", ret);
+		goto error;
+	}
+	ret = __v4l2_ctrl_handler_setup(&gc08a3->ctrls);
+	if (ret < 0) {
+		dev_err(gc08a3->dev, "could not sync v4l2 controls\n");
+		goto error;
+	}
+
+	ret = gc08a3_write_reg(gc08a3, GC08A3_STRAEMING_REG,
+			       GC08A3_REG_VALUE_08BIT, 1);
+	if (ret < 0) {
+		dev_err(gc08a3->dev, "write STRAEMING_REG failed: %d\n", ret);
+		goto error;
+	}
+
+	mutex_unlock(&gc08a3->mutex);
+
+	return 0;
+
+error:
+	mutex_unlock(&gc08a3->mutex);
+	return ret;
+}
+
+static int gc08a3_stop_streaming(struct gc08a3 *gc08a3)
+{
+	int ret;
+
+	ret = gc08a3_write_reg(gc08a3, GC08A3_STRAEMING_REG,
+			       GC08A3_REG_VALUE_08BIT, 0);
+	if (ret < 0)
+		dev_err(gc08a3->dev, "could not sent stop streaming %d\n", ret);
+
+	return ret;
+}
+
+static int gc08a3_s_stream(struct v4l2_subdev *subdev, int enable)
+{
+	struct gc08a3 *gc08a3 = to_gc08a3(subdev);
+	int ret;
+
+	if (gc08a3->streaming == enable)
+		return 0;
+
+	if (enable) {
+		ret = pm_runtime_resume_and_get(gc08a3->dev);
+		if (ret < 0)
+			return ret;
+
+		ret = gc08a3_start_streaming(gc08a3);
+		if (ret < 0)
+			goto err_rpm_put;
+	} else {
+		ret = gc08a3_stop_streaming(gc08a3);
+		if (ret < 0)
+			goto err_rpm_put;
+		pm_runtime_put(gc08a3->dev);
+	}
+
+	gc08a3->streaming = enable;
+	return 0;
+
+err_rpm_put:
+	pm_runtime_put(gc08a3->dev);
+	return ret;
+}
+
+static int gc08a3_g_mbus_config(struct v4l2_subdev *sd, unsigned int pad,
+				struct v4l2_mbus_config *config)
+{
+	config->type = V4L2_MBUS_CSI2_DPHY;
+	config->bus.mipi_csi2.num_data_lanes = 4;
+	config->bus.mipi_csi2.flags = 0;
+	return 0;
+}
+
+static int gc08a3_g_frame_interval(struct v4l2_subdev *subdev,
+				   struct v4l2_subdev_frame_interval *fival)
+{
+	struct gc08a3 *gc08a3 = to_gc08a3(subdev);
+
+	fival->interval.numerator = 1;
+	fival->interval.denominator = gc08a3->cur_mode->max_framerate / 10;
+
+	return 0;
+}
+
+static int
+gc08a3_enum_frame_interval(struct v4l2_subdev *subdev,
+			   struct v4l2_subdev_state *sd_state,
+			   struct v4l2_subdev_frame_interval_enum *fie)
+{
+	const struct gc08a3_mode *mode;
+
+	if (fie->index != 0)
+		return -EINVAL;
+
+	mode = v4l2_find_nearest_size(gc08a3_modes, ARRAY_SIZE(gc08a3_modes),
+				      width, height, fie->width, fie->height);
+
+	fie->code = GC08A3_MBUS_CODE;
+	fie->width = mode->width;
+	fie->height = mode->height;
+	fie->interval.numerator = 1;
+	fie->interval.denominator = mode->max_framerate / 10;
+
+	return 0;
+}
+
+static const struct v4l2_subdev_video_ops gc08a3_video_ops = {
+	.s_stream = gc08a3_s_stream,
+	.g_frame_interval = gc08a3_g_frame_interval,
+	.s_frame_interval = gc08a3_g_frame_interval,
+};
+
+static const struct v4l2_subdev_pad_ops gc08a3_subdev_pad_ops = {
+	.enum_mbus_code = gc08a3_enum_mbus_code,
+	.enum_frame_size = gc08a3_enum_frame_size,
+	.enum_frame_interval = gc08a3_enum_frame_interval,
+	.get_fmt = gc08a3_get_format,
+	.set_fmt = gc08a3_set_format,
+	.get_selection = gc08a3_get_selection,
+	.init_cfg = gc08a3_entity_init_cfg,
+	.get_mbus_config = gc08a3_g_mbus_config,
+};
+
+static const struct v4l2_subdev_ops gc08a3_subdev_ops = {
+	.core = &gc08a3_core_ops,
+	.video = &gc08a3_video_ops,
+	.pad = &gc08a3_subdev_pad_ops,
+};
+
+static int gc08a3_get_regulators(struct device *dev, struct gc08a3 *gc08a3)
+{
+	unsigned int i;
+
+	for (i = 0; i < GC08A3_NUM_SUPPLIES; i++)
+		gc08a3->supplies[i].supply = gc08a3_supply_name[i];
+
+	return devm_regulator_bulk_get(dev, GC08A3_NUM_SUPPLIES,
+				       gc08a3->supplies);
+}
+
+static int gc08a3_parse_fwnode(struct device *dev)
+{
+	struct fwnode_handle *endpoint;
+	struct v4l2_fwnode_endpoint bus_cfg = {
+		.bus_type = V4L2_MBUS_CSI2_DPHY,
+	};
+	unsigned int i, j;
+	int ret;
+
+	endpoint = fwnode_graph_get_next_endpoint(dev_fwnode(dev), NULL);
+	if (!endpoint) {
+		dev_err(dev, "endpoint node not found\n");
+		return -EINVAL;
+	}
+
+	ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, &bus_cfg);
+	if (ret) {
+		dev_err(dev, "parsing endpoint node failed\n");
+		goto done;
+	}
+
+	if (!bus_cfg.nr_of_link_frequencies) {
+		dev_err(dev, "no link frequencies defined");
+		ret = -EINVAL;
+		goto done;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(link_freq_menu_items); i++) {
+		for (j = 0; j < bus_cfg.nr_of_link_frequencies; j++) {
+			if (link_freq_menu_items[i] ==
+			    bus_cfg.link_frequencies[j])
+				break;
+		}
+
+		if (j == bus_cfg.nr_of_link_frequencies) {
+			dev_err(dev,
+				"no link frequency %lld supported, please check DT",
+				link_freq_menu_items[i]);
+			ret = -EINVAL;
+			goto done;
+		}
+	}
+
+done:
+	v4l2_fwnode_endpoint_free(&bus_cfg);
+	fwnode_handle_put(endpoint);
+	return ret;
+}
+
+static int __maybe_unused gc08a3_suspend(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct v4l2_subdev *sd = i2c_get_clientdata(client);
+	struct gc08a3 *gc08a3 = to_gc08a3(sd);
+
+	if (gc08a3->streaming)
+		gc08a3_stop_streaming(gc08a3);
+
+	return 0;
+}
+
+static int __maybe_unused gc08a3_resume(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct v4l2_subdev *sd = i2c_get_clientdata(client);
+	struct gc08a3 *gc08a3 = to_gc08a3(sd);
+	int ret;
+
+	if (gc08a3->streaming) {
+		ret = gc08a3_start_streaming(gc08a3);
+		if (ret)
+			goto error;
+	}
+
+	return 0;
+
+error:
+	gc08a3_stop_streaming(gc08a3);
+	gc08a3->streaming = 0;
+	return ret;
+}
+
+static int gc08a3_init_controls(struct gc08a3 *gc08a3)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
+	const struct v4l2_ctrl_ops *ops = &gc08a3_ctrl_ops;
+	struct v4l2_fwnode_device_properties props;
+	struct v4l2_ctrl_handler *ctrl_hdlr;
+	s64 exposure_max, h_blank;
+	int ret;
+
+	ctrl_hdlr = &gc08a3->ctrls;
+	ret = v4l2_ctrl_handler_init(ctrl_hdlr, 10);
+	if (ret)
+		return ret;
+
+	ctrl_hdlr->lock = &gc08a3->mutex;
+
+	gc08a3->link_freq =
+		v4l2_ctrl_new_int_menu(ctrl_hdlr,
+				       &gc08a3_ctrl_ops,
+				       V4L2_CID_LINK_FREQ,
+				       ARRAY_SIZE(link_freq_menu_items) - 1,
+				       0, link_freq_menu_items);
+	if (gc08a3->link_freq)
+		gc08a3->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+	gc08a3->pixel_rate =
+		v4l2_ctrl_new_std(ctrl_hdlr,
+				  &gc08a3_ctrl_ops,
+				  V4L2_CID_PIXEL_RATE, 0,
+				  to_pixel_rate(GC08A3_LINK_FREQ_336MHZ_INDEX), 1,
+				  to_pixel_rate(GC08A3_LINK_FREQ_336MHZ_INDEX));
+
+	gc08a3->vblank =
+		v4l2_ctrl_new_std(ctrl_hdlr,
+				  &gc08a3_ctrl_ops, V4L2_CID_VBLANK,
+				  gc08a3->cur_mode->vts_min - gc08a3->cur_mode->height,
+				  GC08A3_VTS_MAX - gc08a3->cur_mode->height, 1,
+				  gc08a3->cur_mode->vts_def - gc08a3->cur_mode->height);
+
+	h_blank = gc08a3->cur_mode->hts - gc08a3->cur_mode->width;
+	gc08a3->hblank = v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops,
+					   V4L2_CID_HBLANK, h_blank, h_blank, 1,
+					   h_blank);
+	if (gc08a3->hblank)
+		gc08a3->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+	v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops,
+			  V4L2_CID_ANALOGUE_GAIN, GC08A3_AGAIN_MIN,
+			  GC08A3_AGAIN_MAX, GC08A3_AGAIN_STEP,
+			  GC08A3_AGAIN_MIN);
+
+	exposure_max = gc08a3->cur_mode->vts_def - GC08A3_EXP_MARGIN;
+	gc08a3->exposure = v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops,
+					     V4L2_CID_EXPOSURE, GC08A3_EXP_MIN,
+					     exposure_max, GC08A3_EXP_STEP,
+					     exposure_max);
+
+	v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &gc08a3_ctrl_ops,
+				     V4L2_CID_TEST_PATTERN,
+				     ARRAY_SIZE(gc08a3_test_pattern_menu) - 1,
+				     0, 0, gc08a3_test_pattern_menu);
+
+	v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops, V4L2_CID_HFLIP, 0,
+			  1, 1, 0);
+
+	v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops, V4L2_CID_VFLIP, 0,
+			  1, 1, 0);
+
+	/* register properties to fwnode (e.g. rotation, orientation) */
+	ret = v4l2_fwnode_device_parse(&client->dev, &props);
+	if (ret)
+		goto error_ctrls;
+
+	ret = v4l2_ctrl_new_fwnode_properties(ctrl_hdlr, ops, &props);
+	if (ret)
+		goto error_ctrls;
+
+	if (ctrl_hdlr->error) {
+		ret = ctrl_hdlr->error;
+		goto error_ctrls;
+	}
+
+	gc08a3->sd.ctrl_handler = ctrl_hdlr;
+
+	return 0;
+
+error_ctrls:
+	v4l2_ctrl_handler_free(ctrl_hdlr);
+
+	return ret;
+}
+
+static int gc08a3_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct gc08a3 *gc08a3;
+	int ret;
+
+	ret = gc08a3_parse_fwnode(dev);
+	if (ret)
+		return ret;
+
+	gc08a3 = devm_kzalloc(dev, sizeof(*gc08a3), GFP_KERNEL);
+	if (!gc08a3)
+		return -ENOMEM;
+
+	gc08a3->dev = dev;
+
+	gc08a3->xclk = devm_clk_get(dev, NULL);
+	if (IS_ERR(gc08a3->xclk))
+		return dev_err_probe(dev, PTR_ERR(gc08a3->xclk),
+					 "failed to get xclk\n");
+
+	ret = clk_set_rate(gc08a3->xclk, GC08A3_DEFAULT_CLK_FREQ);
+	if (ret)
+		return dev_err_probe(dev, ret,
+					 "failed to set xclk frequency\n");
+
+	ret = gc08a3_get_regulators(dev, gc08a3);
+	if (ret < 0)
+		return dev_err_probe(dev, ret,
+					 "failed to get regulators\n");
+
+	gc08a3->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(gc08a3->enable_gpio))
+		return dev_err_probe(dev, PTR_ERR(gc08a3->enable_gpio),
+					 "failed to get gpio\n");
+
+	v4l2_i2c_subdev_init(&gc08a3->sd, client, &gc08a3_subdev_ops);
+
+	mutex_init(&gc08a3->mutex);
+	gc08a3->cur_mode = &gc08a3_modes[0];
+
+	ret = gc08a3_power_on(gc08a3->dev);
+	if (ret)
+		goto err_mutex;
+
+	ret = gc08a3_identify_module(gc08a3);
+	if (ret) {
+		dev_err(&client->dev, "failed to find sensor: %d\n", ret);
+		goto err_power_off;
+	}
+
+	ret = gc08a3_init_controls(gc08a3);
+	if (ret) {
+		dev_err(&client->dev, "failed to init controls: %d", ret);
+		goto err_power_off;
+	}
+
+	gc08a3->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+	gc08a3->pad.flags = MEDIA_PAD_FL_SOURCE;
+	gc08a3->sd.dev = &client->dev;
+	gc08a3->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+
+	ret = media_entity_pads_init(&gc08a3->sd.entity, 1, &gc08a3->pad);
+	if (ret < 0) {
+		dev_err(dev, "could not register media entity\n");
+		goto err_v4l2_ctrl_handler_free;
+	}
+
+	ret = v4l2_async_register_subdev_sensor(&gc08a3->sd);
+	if (ret < 0) {
+		dev_err(dev, "could not register v4l2 device\n");
+		goto err_media_entity_cleanup;
+	}
+
+	pm_runtime_set_active(gc08a3->dev);
+	pm_runtime_enable(gc08a3->dev);
+	pm_runtime_idle(gc08a3->dev);
+
+	return 0;
+
+err_media_entity_cleanup:
+	media_entity_cleanup(&gc08a3->sd.entity);
+
+err_v4l2_ctrl_handler_free:
+	v4l2_ctrl_handler_free(gc08a3->sd.ctrl_handler);
+
+err_power_off:
+	gc08a3_power_off(gc08a3->dev);
+
+err_mutex:
+	mutex_destroy(&gc08a3->mutex);
+
+	return ret;
+}
+
+static void gc08a3_remove(struct i2c_client *client)
+{
+	struct v4l2_subdev *sd = i2c_get_clientdata(client);
+	struct gc08a3 *gc08a3 = to_gc08a3(sd);
+
+	v4l2_async_unregister_subdev(&gc08a3->sd);
+	media_entity_cleanup(&gc08a3->sd.entity);
+	v4l2_ctrl_handler_free(&gc08a3->ctrls);
+
+	pm_runtime_disable(&client->dev);
+	pm_runtime_set_suspended(&client->dev);
+
+	mutex_destroy(&gc08a3->mutex);
+}
+
+static const struct of_device_id gc08a3_of_match[] = {
+	{ .compatible = "galaxycore,gc08a3" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, gc08a3_of_match);
+
+static const struct dev_pm_ops gc08a3_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(gc08a3_suspend, gc08a3_resume)
+	SET_RUNTIME_PM_OPS(gc08a3_power_off, gc08a3_power_on, NULL)
+};
+
+static struct i2c_driver gc08a3_i2c_driver = {
+	.driver = {
+		.of_match_table = gc08a3_of_match,
+		.pm = &gc08a3_pm_ops,
+		.name  = "gc08a3",
+	},
+	.probe = gc08a3_probe,
+	.remove = gc08a3_remove,
+};
+
+module_i2c_driver(gc08a3_i2c_driver);
+
+MODULE_DESCRIPTION("GalaxyCore gc08a3 Camera driver");
+MODULE_AUTHOR("Zhi Mao <zhi.mao at mediatek.com>");
+MODULE_LICENSE("GPL");
-- 
2.25.1



From zhi.mao at mediatek.com  Wed Dec  6 21:20:16 2023
From: zhi.mao at mediatek.com (Zhi Mao)
Date: Thu, 7 Dec 2023 13:20:16 +0800
Subject: [PATCH 2/2] media: dt-bindings: media: i2c: Document GC08A3 bindings
In-Reply-To: <20231207052016.25954-1-zhi.mao@mediatek.com>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
Message-ID: <20231207052016.25954-3-zhi.mao@mediatek.com>

Add YAML device tree binding for GC08A3 CMOS image sensor,
and the relevant MAINTAINERS entries.

Signed-off-by: Zhi Mao <zhi.mao at mediatek.com>
---
 .../bindings/media/i2c/galaxycore,gc08a3.yaml | 127 ++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 2 files changed, 129 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml

diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
new file mode 100644
index 000000000000..1802ff1c8a12
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/galaxycore,gc08a3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GalaxyCore gc08a3 1/4" 8M Pixel MIPI CSI-2 sensor
+
+maintainers:
+  - Zhi Mao <zhi.mao at mediatek.com>
+
+description:
+  The gc08a3 is a raw image sensor with an MIPI CSI-2 image data
+  interface and CCI (I2C compatible) control bus. The output format
+  is raw Bayer.
+
+properties:
+  compatible:
+    const: galaxycore,gc08a3
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    description:
+      External clock for the sensor.
+    maxItems: 1
+
+  clock-frequency:
+    description:
+      Frequency of the clock in Hz.
+
+  dovdd-supply: true
+
+  avdd-supply: true
+
+  dvdd-supply: true
+
+  enable-gpios:
+    description: Reference to the GPIO connected to the RESETB pin. Active low.
+    maxItems: 1
+
+  port:
+    $ref: /schemas/graph.yaml#/$defs/port-base
+    additionalProperties: false
+    description:
+      Output port node, single endpoint describing the CSI-2 transmitter.
+
+    properties:
+      endpoint:
+        $ref: /schemas/media/video-interfaces.yaml#
+        unevaluatedProperties: false
+
+        properties:
+          data-lanes:
+            oneOf:
+              - items:
+                  - const: 1
+                  - const: 2
+                  - const: 3
+                  - const: 4
+              - items:
+                  - const: 1
+                  - const: 2
+
+          link-frequencies: true
+
+        required:
+          - data-lanes
+          - link-frequencies
+
+    required:
+      - endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - clock-frequency
+  - dovdd-supply
+  - avdd-supply
+  - dvdd-supply
+  - enable-gpios
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        sensor0 at 31 {
+            status = "okay";
+            compatible = "galaxycore,gc08a3";
+            reg = <0x31>;
+
+            clocks = <&gc08a3_clk>;
+            clock-names = "xvclk";
+            clock-frequency = <24000000>;
+
+            enable-gpios = <&pio 19 GPIO_ACTIVE_HIGH>;
+
+            avdd-supply = <&gc08a3_avdd>;
+            dovdd-supply = <&ogc08a3_dovdd>;
+            dvdd-supply = <&gc08a3_dvdd>;
+
+            port {
+                sensor0_out_2: endpoint {
+                    data-lanes = <1 2 3 4>;
+                    link-frequencies = /bits/ 64 <336000000 207000000>;
+                    remote-endpoint = <&seninf_csi_port_0_in_2>;
+                };
+            };
+        };
+
+    };
+
+...
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index b752f8902367..1a16a94fb202 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -502,6 +502,8 @@ patternProperties:
     description: Fujitsu Ltd.
   "^fxtec,.*":
     description: FX Technology Ltd.
+  "^galaxycore,.*":
+    description: GalaxyCore Inc.
   "^gardena,.*":
     description: GARDENA GmbH
   "^gateway,.*":
-- 
2.25.1



From wenst at chromium.org  Wed Dec  6 21:28:24 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 7 Dec 2023 14:28:24 +0900
Subject: [PATCH v3 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <ab7988af-e7f9-433d-b35e-138f79ce82c0@collabora.com>
References: <20231204084012.2281292-1-wenst@chromium.org> <20231204084012.2281292-7-wenst@chromium.org>
 <ab7988af-e7f9-433d-b35e-138f79ce82c0@collabora.com>
Message-ID: <CAGXv+5EyHXWgbvtxx-skzi6FNEnZD8QEHQ2Wq224anY+QKUrew@mail.gmail.com>

On Mon, Dec 4, 2023 at 11:27?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> > Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> > Krabby design.
> >
> > Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> > convertible device with touchscreen and stylus.
> >
> > Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> > device. It does not have a touchscreen or stylus.
> >
> > The two devices both have two variants. The difference is a second
> > source touchpad controller that shares the same address as the original,
> > but is incompatible.
> >
> > The extra SKU IDs for the Tentacruel devices map to different sensor
> > components attached to the Embedded Controller. These are not visible
> > to the main processor.
> >
> > Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> > Acked-by: Conor Dooley <conor.dooley at microchip.com>
> > ---
> > Changes since v2:
> > - Picked up Conor's ack
> > - Rename touchpad to trackpad
> > - Drop pinctrl properties from trackpad in tentacruel/tentacool second
> >    source trackpad
> >
> > Changes since v1:
> > - Reorder SKU numbers in descending order.
> > - Fixed pinconfig node names
> > - Moved pinctrl-* properties after interrupts-*
> > - Switched to interrupts-extended for external components
> > - Marked ADSP as explicitly disabled, with a comment explaining that it
> >    stalls the system
> > - Renamed "touchpad" to "trackpad"
> > - Dropped bogus "no-laneswap" property from it6505 node
> > - Moved "realtek,jd-src" property to after all the regulator supplies
> > - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> > - Renamed "vgpu" regulator name to allow coupling, with a comment
> >    containing the name used in the design
> > - Renamed "cr50" node name to "tpm"
> > - Moved trackpad_pins reference up to i2c2; workaround for second source
> >    component resource sharing.
> > - Fix copyright year
> > - Fixed touchscreen supply name
> >
> >   arch/arm64/boot/dts/mediatek/Makefile         |    4 +
> >   .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
> >   .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
> >   .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
> >   .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
> >   .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
> >   .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
> >   7 files changed, 2003 insertions(+)
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> > index e6e7592a3645..442af61b1305 100644
> > --- a/arch/arm64/boot/dts/mediatek/Makefile
> > +++ b/arch/arm64/boot/dts/mediatek/Makefile
> > @@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> > new file mode 100644
> > index 000000000000..9b2b64525961
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> > @@ -0,0 +1,129 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2022 Google LLC
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt8186-corsola.dtsi"
> > +#include <dt-bindings/gpio/gpio.h>
> > +
> > +/ {
> > +     aliases {
> > +             i2c4 = &i2c4;
> > +     };
> > +};
> > +
> > +&dsi_out {
> > +     remote-endpoint = <&ps8640_in>;
> > +};
> > +
> > +&i2c0 {
> > +     clock-frequency = <400000>;
> > +
> > +     ps8640: edp-bridge at 8 {
> > +             compatible = "parade,ps8640";
> > +             reg = <0x8>;
> > +             powerdown-gpios = <&pio 96 GPIO_ACTIVE_LOW>;
> > +             reset-gpios = <&pio 98 GPIO_ACTIVE_LOW>;
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&ps8640_pins>;
> > +             vdd12-supply = <&mt6366_vrf12_reg>;
> > +             vdd33-supply = <&mt6366_vcn33_reg>;
> > +
> > +             ports {
> > +                     #address-cells = <1>;
> > +                     #size-cells = <0>;
> > +
> > +                     port at 0 {
> > +                             reg = <0>;
> > +
> > +                             ps8640_in: endpoint {
> > +                                     remote-endpoint = <&dsi_out>;
> > +                             };
> > +                     };
> > +
> > +                     port at 1 {
> > +                             reg = <1>;
> > +
> > +                             ps8640_out: endpoint {
> > +                                     remote-endpoint = <&panel_in>;
> > +                             };
> > +                     };
> > +             };
> > +
> > +             aux-bus {
> > +                     panel {
> > +                             compatible = "edp-panel";
> > +                             power-supply = <&pp3300_disp_x>;
> > +                             backlight = <&backlight_lcd0>;
> > +
> > +                             port {
> > +                                     panel_in: endpoint {
> > +                                             remote-endpoint = <&ps8640_out>;
> > +                                     };
> > +                             };
> > +                     };
> > +             };
> > +     };
> > +};
> > +
> > +&i2c1 {
> > +     i2c-scl-internal-delay-ns = <10000>;
> > +
> > +     touchscreen: touchscreen at 10 {
> > +             compatible = "hid-over-i2c";
> > +             reg = <0x10>;
> > +             interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&touchscreen_pins>;
> > +             post-power-on-delay-ms = <10>;
> > +             hid-descr-addr = <0x0001>;
> > +             vdd-supply = <&pp3300_s3>;
> > +     };
> > +};
> > +
> > +&i2c4 {
> > +     pinctrl-names = "default";
> > +     pinctrl-0 = <&i2c4_pins>;
> > +     clock-frequency = <400000>;
> > +     status = "okay";
> > +
> > +     proximity at 28 {
> > +             compatible = "semtech,sx9324";
> > +             reg = <0x28>;
> > +             interrupts-extended = <&pio 5 IRQ_TYPE_LEVEL_LOW>;
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&sar_sensor_pins>;
> > +             vdd-supply = <&mt6366_vio18_reg>;
> > +             svdd-supply = <&mt6366_vio18_reg>;
> > +             #io-channel-cells = <1>;
>
>  From the newest DTS coding style document:
>
> The following order of properties in device nodes is preferred:
>
> 1. compatible
> 2. reg
> 3. ranges
> 4. Standard/common properties (defined by common bindings, e.g. without
>     vendor-prefixes)
> 5. Vendor-specific properties
> 6. status (if applicable)
> 7. Child nodes, where each node is preceded with a blank line
>
> The "status" property is by default "okay", thus it can be omitted.
>
> The above-described ordering follows this approach:
>
> 1. Most important properties start the node: compatible then bus addressing to
>     match unit address.
> 2. Each node will have common properties in similar place.
> 3. Status is the last information to annotate that device node is or is not
>     finished (board resources are needed).

Wishing for a checking tool now. :p

> #io-channel-cells goes after `reg` (same for the other instances) :-)

Ack (though it looks weird).

> > +     };
> > +};
> > +
> > +&pio {
> > +     i2c4_pins: i2c4-pins {
> > +             pins-bus {
> > +                     pinmux = <PINMUX_GPIO136__FUNC_SDA4>,
> > +                              <PINMUX_GPIO135__FUNC_SCL4>;
> > +                     bias-disable;
> > +                     drive-strength = <4>;
> > +                     input-enable;
> > +             };
> > +     };
> > +
> > +     ps8640_pins: ps8640-pins {
> > +             pins-pwrdn-rst {
> > +                     pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
> > +                              <PINMUX_GPIO98__FUNC_GPIO98>;
> > +                     output-low;
> > +             };
> > +     };
> > +
> > +     sar_sensor_pins: sar-sensor-pins {
> > +             pins-irq {
> > +                     pinmux = <PINMUX_GPIO5__FUNC_GPIO5>;
> > +                     input-enable;
> > +                     bias-pull-up;
> > +             };
> > +     };
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> > new file mode 100644
> > index 000000000000..9bb64353ca65
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> > @@ -0,0 +1,57 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2022 Google LLC
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt8186-corsola-krabby.dtsi"
> > +
> > +/ {
> > +     model = "Google Tentacool board";
> > +     compatible = "google,tentacruel-sku327681", "google,tentacruel", "mediatek,mt8186";
> > +     chassis-type = "laptop";
> > +};
> > +
> > +/* Tentacool omits the pen. */
> > +&gpio_keys {
> > +     status = "disabled";
> > +};
> > +
> > +/* Tentacool omits the touchscreen; nothing else is on i2c1. */
> > +&i2c1 {
> > +     status = "disabled";
> > +};
> > +
> > +&keyboard_controller {
> > +     function-row-physmap = <
> > +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
> > +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
> > +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
> > +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
> > +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
> > +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
> > +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
> > +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
> > +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
> > +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
> > +     >;
> > +
> > +     linux,keymap = <
> > +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
> > +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> > +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> > +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> > +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> > +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> > +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> > +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> > +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> > +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> > +             CROS_STD_MAIN_KEYMAP
> > +     >;
> > +};
> > +
> > +/* Tentacool omits the touchscreen. */
> > +&touchscreen {
> > +     status = "disabled";
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > new file mode 100644
> > index 000000000000..c3ae6f9616c8
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > @@ -0,0 +1,24 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2023 Google LLC
> > + */
> > +
> > +#include "mt8186-corsola-tentacool-sku327681.dts"
> > +
> > +/ {
> > +     compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
> > +};
> > +
> > +/* This variant replaces only the trackpad controller. */
> > +&i2c2 {
> > +     /delete-node/ trackpad at 15;
>
> Why are you deleting the trackpad at 15 node?
>
> You can simply override the compatible, or actually omit the compatible string
> in the *.dtsi file, and set just that in each board *.dts.
>
> dtsi:
>         trackpad_a: trackpad at 15 {
>                 /* Compatible is set in each board dts */
>                 reg, interrupts, others
>         }
>
> dts:
>
> &trackpad_a {
>         compatible = "elan,ekth3000";
> };

The original trackpad at 15 comes from the base design and is used for all
models other than the ones with the conflicting component. Hence I believe
it should live in the base .dtsi.

The delete-node makes it much less likely to have any lingering properties.
These are not nodes that just differ in compatible strings like DSI panels.
They have incompatible bindings. For example, elan,ekth3000 uses "vcc-supply",
while "hid-over-i2c" uses "vdd-supply".

And going back to my previous argument, the base design used one specific
model which is carried over to all the other models.

Suppose I add a phandle to the original trackpad, and do

    /delete-node/ &trackpad;

Would that be better?

> other dts:
>
> &trackpad_a {
>         compatible = "hid-over-i2c";
> };
>
> > +
> > +     trackpad at 15 {
> > +             compatible = "hid-over-i2c";
> > +             reg = <0x15>;
> > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > +             hid-descr-addr = <0x0001>;
> > +             vdd-supply = <&pp3300_s3>;
> > +             wakeup-source;
> > +     };
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> > new file mode 100644
> > index 000000000000..26d3451a5e47
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> > @@ -0,0 +1,44 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2022 Google LLC
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt8186-corsola-krabby.dtsi"
> > +
> > +/ {
> > +     model = "Google Tentacruel board";
> > +     compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
> > +                  "google,tentacruel-sku262145", "google,tentacruel-sku262144",
> > +                  "google,tentacruel", "mediatek,mt8186";
> > +     chassis-type = "convertible";
> > +};
> > +
> > +&keyboard_controller {
> > +     function-row-physmap = <
> > +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
> > +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
> > +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
> > +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
> > +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
> > +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
> > +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
> > +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
> > +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
> > +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
> > +     >;
> > +
> > +     linux,keymap = <
> > +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
> > +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> > +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> > +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> > +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> > +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> > +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> > +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> > +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> > +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> > +             CROS_STD_MAIN_KEYMAP
> > +     >;
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > new file mode 100644
> > index 000000000000..447b57b12b41
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > @@ -0,0 +1,26 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2023 Google LLC
> > + */
> > +
> > +#include "mt8186-corsola-tentacruel-sku262144.dts"
> > +
> > +/ {
> > +     compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> > +                  "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> > +                  "google,tentacruel", "mediatek,mt8186";
> > +};
> > +
> > +/* This variant replaces only the trackpad controller. */
> > +&i2c2 {
> > +     /delete-node/ trackpad at 15;
> > +
> > +     trackpad at 15 {
> > +             compatible = "hid-over-i2c";
> > +             reg = <0x15>;
> > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > +             hid-descr-addr = <0x0001>;
> > +             vdd-supply = <&pp3300_s3>;
> > +             wakeup-source;
> > +     };
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > new file mode 100644
> > index 000000000000..8726b2916ef1
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > @@ -0,0 +1,1719 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (C) 2022 MediaTek Inc.
> > + */
> > +/dts-v1/;
> > +#include "mt8186.dtsi"
> > +#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/input/input.h>
> > +#include <dt-bindings/input/gpio-keys.h>
> > +#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
> > +
> > +/ {
> > +     aliases {
> > +             i2c0 = &i2c0;
> > +             i2c1 = &i2c1;
> > +             i2c2 = &i2c2;
> > +             i2c3 = &i2c3;
> > +             i2c5 = &i2c5;
> > +             mmc0 = &mmc0;
> > +             mmc1 = &mmc1;
> > +             serial0 = &uart0;
> > +     };
> > +
> > +     chosen {
> > +             stdout-path = "serial0:115200n8";
> > +     };
> > +
> > +     memory at 40000000 {
> > +             device_type = "memory";
> > +             /* The size should be filled in by the bootloader. */
> > +             reg = <0 0x40000000 0 0>;
> > +     };
> > +
> > +     backlight_lcd0: backlight-lcd0 {
> > +             compatible = "pwm-backlight";
> > +             pwms = <&pwm0 0 500000>;
> > +             power-supply = <&ppvar_sys>;
> > +             enable-gpios = <&pio 152 0>;
> > +             brightness-levels = <0 1023>;
> > +             num-interpolated-steps = <1023>;
> > +             default-brightness-level = <576>;
> > +     };
> > +
> > +     btsco: bt-sco {
>
> Do you really need the phandle to bt-sco?

No. But the sound node probably should be referencing it and the dmic
node via DT instead of hardcoding the DAI and codec names in the machine
driver.

Anyway, will remove the label for now.

> Also, this node describes a codec, so: "bt-sco-codec" please!

Ack.

> > +             compatible = "linux,bt-sco";
> > +             #sound-dai-cells = <0>;
> > +     };
> > +
> > +     dmic_codec: dmic-codec {
>
> This phandle is unused...

Removed.

> ..snip..
>
> > +
> > +&adsp {
> > +     memory-region = <&adsp_dma_mem>, <&adsp_mem>;
> > +     status = "disabled"; /* causes stall */
>
> This is a firmware issue: once the correct firmware is uploaded to linux-firmware
> the dsp node can get enabled... so it we make sure that this happens before this
> devicetree gets picked, we can avoid a second commit enabling audio.
>
> After all, since we *want to* use the Xtensa DSP for audio, without it booted
> sound won't work *anyway*.... so having the firmware in place can also be seen
> as a direct dependency of the entire audio functionality.
>
> P.S.: The FW that is distributed with ChromeOS works just fine!

I'll give that a try.

> > +};
> > +
> > +&afe {
> > +     i2s0-share = "I2S1";
> > +     i2s3-share = "I2S2";
> > +     status = "okay";
> > +};
> > +
>
> ..snip..
>
> > +&i2c2 {
> > +     pinctrl-names = "default";
> > +     /*
> > +      * Trackpad pin put here to work around second source components
> > +      * sharing the pinmux in steelix designs.
> > +      */
> > +     pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
>
> There's no choice for now... even if this is not beautiful to see... but it's still
> ok for me because we can revisit this later when the HW Prober mechanism will be
> upstreamed.

Yup. Working on that.

> > +     clock-frequency = <400000>;
> > +     i2c-scl-internal-delay-ns = <10000>;
> > +     status = "okay";
> > +
> > +     trackpad at 15 {
> > +             compatible = "elan,ekth3000";
> > +             reg = <0x15>;
> > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > +             vcc-supply = <&pp3300_s3>;
> > +             wakeup-source;
> > +     };
> > +};
> > +
>
> Thanks,
> Angelo

Thanks for the review again.

ChenYu


From n-francis at ti.com  Wed Dec  6 21:31:24 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Thu, 7 Dec 2023 11:01:24 +0530
Subject: [PATCH v9 6/7] arm64: dts: ti: k3-j721e-sk: Add TPS6594 family
 PMICs
In-Reply-To: <5e22f8cb-1004-4bcc-9bd0-2c30180ba10e@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
 <20231205093439.2298296-7-n-francis@ti.com>
 <20231205151647.vh6rlhro7qlwoerc@knelt>
 <5e22f8cb-1004-4bcc-9bd0-2c30180ba10e@ti.com>
Message-ID: <cc2c3e97-e2c6-487b-91a5-c5f5fbe2c3bc@ti.com>

Hi Nishanth, Udit,

On 07/12/23 10:12, Kumar, Udit wrote:
> 
> On 12/5/2023 8:46 PM, Nishanth Menon wrote:
>> On 15:04-20231205, Neha Malcom Francis wrote:
>>> This patch adds support for TPS6594 PMIC family on wakeup I2C0 bus.
>>> These devices provide regulators (bucks and LDOs), but also GPIOs, a
>>> RTC, a watchdog, an ESM (Error Signal Monitor) which monitors the SoC
>>> error output signal, and a PFSM (Pre-configurable Finite State Machine)
>>> which manages the operational modes of the PMIC.
>>>
>>> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
>>> ---
>>> ? arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 158 +++++++++++++++++++++++++
>>> ? 1 file changed, 158 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts 
>>> b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>>> index 42fe8eee9ec8..e600825f7e78 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>>> @@ -459,6 +459,13 @@ J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3) 
>>> EXT_REFCLK1.GPIO1_12 */
>>> ? };
>>> ? &wkup_pmx0 {
>>> +??? pmic_irq_pins_default: pmic-irq-default-pins {
>>> +??????? bootph-pre-ram;
>>> +??????? pinctrl-single,pins = <
>>> +??????????? J721E_WKUP_IOPAD(0x0cc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
>>> +??????? >;
>>> +??? };
>>> +
>>> ????? mcu_cpsw_pins_default: mcu-cpsw-default-pins {
>>> ????????? pinctrl-single,pins = <
>>> ????????????? J721E_WKUP_IOPAD(0x84, PIN_INPUT, 0) /* (B24) MCU_RGMII1_RD0 */
>>> @@ -560,6 +567,157 @@ eeprom at 51 {
>>> ????????? compatible = "atmel,24c512";
>>> ????????? reg = <0x51>;
>>> ????? };
>>> +
>>> +??? tps659413: pmic at 48 {
>>> +??????? bootph-pre-ram;
>> only for the leaf nodes. See
>> https://libera.irclog.whitequark.org/armlinux/2023-10-19
> 
> 
> AFAIK, please correct me, u-boot still needs in all nodes ?
> 

That's what I believe as well, is it better to have only the leaf nodes in 
kernel and have U-Boot DTSI handle the parent bootph properties? If so I'll send 
out v10 making change accordingly.

>>
>>> +??????? compatible = "ti,tps6594-q1";
>>> +??????? reg = <0x48>;
>>> +??????? system-power-controller;
>>> +??????? pinctrl-names = "default";
>>> +??????? pinctrl-0 = <&pmic_irq_pins_default>;
>>> +??????? interrupt-parent = <&wkup_gpio0>;
>>> +??????? interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
>>> +??????? ti,primary-pmic;
>>> +
>>> +??????? gpio-controller;
>>> +??????? #gpio-cells = <2>;
>>> +
>>> +??????? buck123-supply = <&vsys_3v3>;
>>> +??????? buck4-supply = <&vsys_3v3>;
>>> +??????? buck5-supply = <&vsys_3v3>;
>>> +??????? ldo1-supply = <&vsys_3v3>;
>>> +??????? ldo2-supply = <&vsys_3v3>;
>>> +??????? ldo3-supply = <&vsys_3v3>;
>>> +??????? ldo4-supply = <&vsys_3v3>;
>>> +
>>> +??????? regulators {
>>> +??????????? bootph-pre-ram;
>>> +??????????? bucka123: buck123 {
>>> +??????????????? bootph-pre-ram;
>>> +??????????????? regulator-name = "vdd_cpu_avs";
>>> +??????????????? regulator-min-microvolt = <600000>;
>>> +??????????????? regulator-max-microvolt = <900000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? bucka4: buck4 {
>>> +??????????????? regulator-name = "vdd_mcu_0v85";
>>> +??????????????? regulator-min-microvolt = <850000>;
>>> +??????????????? regulator-max-microvolt = <850000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? bucka5: buck5 {
>>> +??????????????? regulator-name = "vdd_phyio_1v8";
>>> +??????????????? regulator-min-microvolt = <1800000>;
>>> +??????????????? regulator-max-microvolt = <1800000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? ldoa1: ldo1 {
>>> +??????????????? regulator-name = "vdd1_lpddr4_1v8";
>>> +??????????????? regulator-min-microvolt = <1800000>;
>>> +??????????????? regulator-max-microvolt = <1800000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? ldoa2: ldo2 {
>>> +??????????????? regulator-name = "vdd_mcuio_1v8";
>>> +??????????????? regulator-min-microvolt = <1800000>;
>>> +??????????????? regulator-max-microvolt = <1800000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? ldoa3: ldo3 {
>>> +??????????????? regulator-name = "vdda_dll_0v8";
>>> +??????????????? regulator-min-microvolt = <800000>;
>>> +??????????????? regulator-max-microvolt = <800000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? ldoa4: ldo4 {
>>> +??????????????? regulator-name = "vda_mcu_1v8";
>>> +??????????????? regulator-min-microvolt = <1800000>;
>>> +??????????????? regulator-max-microvolt = <1800000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +??????? };
>>> +??? };
>>> +
>>> +??? tps659411: pmic at 4c {
>>> +??????? compatible = "ti,tps6594-q1";
>>> +??????? reg = <0x4c>;
>>> +??????? system-power-controller;
>>> +??????? interrupt-parent = <&wkup_gpio0>;
>>> +??????? interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
>>> +
>>> +??????? gpio-controller;
>>> +??????? #gpio-cells = <2>;
>>> +
>>> +??????? buck1234-supply = <&vsys_3v3>;
>>> +??????? buck5-supply = <&vsys_3v3>;
>>> +??????? ldo1-supply = <&vsys_3v3>;
>>> +??????? ldo2-supply = <&vsys_3v3>;
>>> +??????? ldo3-supply = <&vsys_3v3>;
>>> +??????? ldo4-supply = <&vsys_3v3>;
>>> +
>>> +??????? regulators {
>>> +??????????? buckb1234: buck1234 {
>>> +??????????????? regulator-name = "vdd_core_0v8";
>>> +??????????????? regulator-min-microvolt = <800000>;
>>> +??????????????? regulator-max-microvolt = <800000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? buckb5: buck5 {
>>> +??????????????? regulator-name = "vdd_ram_0v85";
>>> +??????????????? regulator-min-microvolt = <850000>;
>>> +??????????????? regulator-max-microvolt = <850000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? ldob1: ldo1 {
>>> +??????????????? regulator-name = "vdd_sd_dv";
>>> +??????????????? regulator-min-microvolt = <1800000>;
>>> +??????????????? regulator-max-microvolt = <3300000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? ldob2: ldo2 {
>>> +??????????????? regulator-name = "vdd_usb_3v3";
>>> +??????????????? regulator-min-microvolt = <3300000>;
>>> +??????????????? regulator-max-microvolt = <3300000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? ldob3: ldo3 {
>>> +??????????????? regulator-name = "vdd_io_1v8";
>>> +??????????????? regulator-min-microvolt = <1800000>;
>>> +??????????????? regulator-max-microvolt = <1800000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +
>>> +??????????? ldob4: ldo4 {
>>> +??????????????? regulator-name = "vda_pll_1v8";
>>> +??????????????? regulator-min-microvolt = <1800000>;
>>> +??????????????? regulator-max-microvolt = <1800000>;
>>> +??????????????? regulator-boot-on;
>>> +??????????????? regulator-always-on;
>>> +??????????? };
>>> +??????? };
>>> +??? };
>>> ? };
>>> ? &mcu_uart0 {
>>> -- 
>>> 2.34.1
>>>

-- 
Thanking You
Neha Malcom Francis


From wenst at chromium.org  Wed Dec  6 21:41:09 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 7 Dec 2023 14:41:09 +0900
Subject: [PATCH v3 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <4a7c0cd5-d705-4369-90dd-92d6a27c4723@collabora.com>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-7-wenst@chromium.org>
 <4a7c0cd5-d705-4369-90dd-92d6a27c4723@collabora.com>
Message-ID: <20231207054109.GA37230@google.com>

On Mon, Dec 04, 2023 at 01:55:06PM +0200, Eugen Hristev wrote:
> Hello Chen-Yu,
> 
> On 12/4/23 10:40, Chen-Yu Tsai wrote:
> > Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> > Krabby design.
> > 
> > Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> > convertible device with touchscreen and stylus.
> > 
> > Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> > device. It does not have a touchscreen or stylus.
> > 
> > The two devices both have two variants. The difference is a second
> > source touchpad controller that shares the same address as the original,
> > but is incompatible.
> > 
> > The extra SKU IDs for the Tentacruel devices map to different sensor
> > components attached to the Embedded Controller. These are not visible
> > to the main processor.
> > 
> > Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> > Acked-by: Conor Dooley <conor.dooley at microchip.com>
> > ---
> > Changes since v2:
> > - Picked up Conor's ack
> > - Rename touchpad to trackpad
> > - Drop pinctrl properties from trackpad in tentacruel/tentacool second
> >   source trackpad
> > 
> > Changes since v1:
> > - Reorder SKU numbers in descending order.
> > - Fixed pinconfig node names
> > - Moved pinctrl-* properties after interrupts-*
> > - Switched to interrupts-extended for external components
> > - Marked ADSP as explicitly disabled, with a comment explaining that it
> >   stalls the system
> > - Renamed "touchpad" to "trackpad"
> > - Dropped bogus "no-laneswap" property from it6505 node
> > - Moved "realtek,jd-src" property to after all the regulator supplies
> > - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> > - Renamed "vgpu" regulator name to allow coupling, with a comment
> >   containing the name used in the design
> > - Renamed "cr50" node name to "tpm"
> > - Moved trackpad_pins reference up to i2c2; workaround for second source
> >   component resource sharing.
> > - Fix copyright year
> > - Fixed touchscreen supply name
> > 
> >  arch/arm64/boot/dts/mediatek/Makefile         |    4 +
> >  .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
> >  .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
> >  .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
> >  .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
> >  .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
> >  .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
> >  7 files changed, 2003 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi

[...]

> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > new file mode 100644
> > index 000000000000..8726b2916ef1
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > @@ -0,0 +1,1719 @@

[...]

> > +	sound: sound {
> > +		compatible = "mediatek,mt8186-mt6366-rt1019-rt5682s-sound";
> > +		pinctrl-names = "aud_clk_mosi_off",
> > +				"aud_clk_mosi_on",
> > +				"aud_clk_miso_off",
> > +				"aud_clk_miso_on",
> > +				"aud_dat_miso_off",
> > +				"aud_dat_miso_on",
> > +				"aud_dat_mosi_off",
> > +				"aud_dat_mosi_on",
> > +				"aud_gpio_i2s0_off",
> > +				"aud_gpio_i2s0_on",
> > +				"aud_gpio_i2s1_off",
> > +				"aud_gpio_i2s1_on",
> > +				"aud_gpio_i2s2_off",
> > +				"aud_gpio_i2s2_on",
> > +				"aud_gpio_i2s3_off",
> > +				"aud_gpio_i2s3_on",
> > +				"aud_gpio_tdm_off",
> > +				"aud_gpio_tdm_on",
> > +				"aud_gpio_pcm_off",
> > +				"aud_gpio_pcm_on",
> > +				"aud_gpio_dmic_sec";
> > +		pinctrl-0 = <&aud_clk_mosi_off>;
> > +		pinctrl-1 = <&aud_clk_mosi_on>;
> > +		pinctrl-2 = <&aud_clk_miso_off>;
> > +		pinctrl-3 = <&aud_clk_miso_on>;
> > +		pinctrl-4 = <&aud_dat_miso_off>;
> > +		pinctrl-5 = <&aud_dat_miso_on>;
> > +		pinctrl-6 = <&aud_dat_mosi_off>;
> > +		pinctrl-7 = <&aud_dat_mosi_on>;
> > +		pinctrl-8 = <&aud_gpio_i2s0_off>;
> > +		pinctrl-9 = <&aud_gpio_i2s0_on>;
> > +		pinctrl-10 = <&aud_gpio_i2s1_off>;
> > +		pinctrl-11 = <&aud_gpio_i2s1_on>;
> > +		pinctrl-12 = <&aud_gpio_i2s2_off>;
> > +		pinctrl-13 = <&aud_gpio_i2s2_on>;
> > +		pinctrl-14 = <&aud_gpio_i2s3_off>;
> > +		pinctrl-15 = <&aud_gpio_i2s3_on>;
> > +		pinctrl-16 = <&aud_gpio_tdm_off>;
> > +		pinctrl-17 = <&aud_gpio_tdm_on>;
> 
> These two above bring errors, as discussed

Looking at the machine driver code, it seems OK to remove them. So I
will.

> > +		pinctrl-18 = <&aud_gpio_pcm_off>;
> > +		pinctrl-19 = <&aud_gpio_pcm_on>;
> > +		pinctrl-20 = <&aud_gpio_dmic_sec>;
> > +		mediatek,adsp = <&adsp>;
> > +		mediatek,platform = <&afe>;
> > +
> > +		playback-codecs {
> > +			sound-dai = <&it6505dptx>, <&rt1019p>;
> > +		};
> > +
> > +		headset-codec {
> > +			sound-dai = <&rt5682s 0>;
> > +		};
> > +	};

[...]

> > +&afe {
> > +	i2s0-share = "I2S1";
> > +	i2s3-share = "I2S2";
> 
> These i2sX-share are not documented.

Looks like this got handled directly in the machine driver.
Will remove.

> > +	status = "okay";
> > +};

[...]

> > +&i2c2 {
> > +	pinctrl-names = "default";
> > +	/*
> > +	 * Trackpad pin put here to work around second source components
> > +	 * sharing the pinmux in steelix designs.
> > +	 */
> > +	pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
> 
> While this makes things better, it's not correct. The i2c2 bus does not use the
> trackpad pin. I would believe a better way is to have a node that holds both
> trackpads and claims the pin for both at once. And that node not being the i2c bus
> as there could be more devices on the bus and the pin would be taken regardless of
> any trackpad probing , which is not right.

That is still a workaround, and it also doesn't work because there are
no bindings nor code for the extra device node level.

> Another option is to disable parallel probing for the trackpads, such that when one
> fails to probe, the pin is released and can be taken by the other one.

We thought about this but this workaround would impact everyone else not
dealing with second source components.

[...]

> > +	aud_gpio_tdm_off: aud-gpio-tdm-off-pins { };
> > +
> > +	aud_gpio_tdm_on: aud-gpio-tdm-on-pins { };
> 
> Guess have to remove these two empty pinctrls.

Yes. I'll try that. Looking at the code it should work.


Thanks for the review
ChenYu


From lkp at intel.com  Wed Dec  6 21:41:02 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 07 Dec 2023 13:41:02 +0800
Subject: [linux-next:master] BUILD REGRESSION
 577a4ee0b96fb043c9cf4a533c550ff587e526cf
Message-ID: <202312071357.ypE0yrPf-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 577a4ee0b96fb043c9cf4a533c550ff587e526cf  Add linux-next specific files for 20231206

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202312061337.WNVSk0AL-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312061837.tbKWaozM-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312062242.RFPPozG9-lkp at intel.com

Error/Warning: (recently discovered and may have been fixed)

/tmp/cco4BMDv.s:387: Error: selected processor does not support requested special purpose register -- `mrs r1,cpsr'
drivers/perf/riscv_pmu_sbi.c:1008:19: error: incompatible function pointer types initializing 'proc_handler *' (aka 'int (*)(const struct ctl_table *, int, void *, unsigned long *, long long *)') with an expression of type 'int (struct ctl_table *, int, void *, size_t *, loff_t *)' (aka 'int (struct ctl_table *, int, void *, unsigned long *, long long *)') [-Wincompatible-function-pointer-types]

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-randconfig-r132-20231206
|   |-- arch-alpha-mm-fault.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|   |-- drivers-atm-fore200e.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-int-usertype-b-got-restricted-__le32-usertype
|   |-- drivers-iio-imu-bmi323-bmi323_i2c.c:sparse:sparse:symbol-bmi323_i2c_regmap_config-was-not-declared.-Should-it-be-static
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- arm-allyesconfig
|   `-- qcom_stats.c:(.text):undefined-reference-to-__aeabi_uldivmod
|-- arm-randconfig-r016-20220626
|   `-- :Error:selected-processor-does-not-support-requested-special-purpose-register-mrs-r1-cpsr
|-- csky-randconfig-r122-20231206
|   |-- arch-csky-kernel-vdso-vgettimeofday.c:sparse:sparse:function-__vdso_clock_gettime-with-external-linkage-has-definition
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- microblaze-randconfig-r121-20231206
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- mips-allyesconfig
|   `-- qcom_stats.c:(.text.qcom_ddr_stats_show):undefined-reference-to-__udivdi3
|-- mips-randconfig-r123-20231206
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- parisc-randconfig-r113-20231206
|   |-- drivers-iio-imu-bmi323-bmi323_i2c.c:sparse:sparse:symbol-bmi323_i2c_regmap_config-was-not-declared.-Should-it-be-static
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-opcode-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-owner-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-type-got-int
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- sh-randconfig-m031-20230727
|   `-- standard-input:Error:unknown-pseudo-op:cfi_def_cfa_regist
|-- sh-randconfig-r112-20231206
|   |-- arch-sh-kernel-crash_dump.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-const-addr-got-void-noderef-__iomem
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-opcode-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-owner-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-type-got-int
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- sparc-allmodconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc-allnoconfig
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-defconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-randconfig-001-20231206
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-randconfig-002-20231206
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-randconfig-r061-20231206
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-allmodconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-allyesconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-defconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-randconfig-001-20231206
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-randconfig-002-20231206
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-randconfig-r133-20231206
|   |-- drivers-infiniband-hw-vmw_pvrdma-pvrdma.h:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-int-usertype-l-got-restricted-__le32-usertype
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- x86_64-randconfig-121-20231206
|   |-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_process.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-address-spaces):
|   |-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_process.c:sparse:struct-dma_fence
|   |-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_process.c:sparse:struct-dma_fence-noderef-__rcu
|   |-- drivers-gpu-drm-amd-amdgpu-amdgpu_amdkfd_gpuvm.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-address-spaces):
|   |-- drivers-gpu-drm-amd-amdgpu-amdgpu_amdkfd_gpuvm.c:sparse:struct-dma_fence
|   |-- drivers-gpu-drm-amd-amdgpu-amdgpu_amdkfd_gpuvm.c:sparse:struct-dma_fence-noderef-__rcu
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-opcode-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-owner-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-type-got-int
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
`-- x86_64-randconfig-122-20231206
    `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
clang_recent_errors
|-- arm64-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- arm64-allyesconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- arm64-randconfig-003-20231206
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- arm64-randconfig-004-20231206
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- hexagon-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- hexagon-allyesconfig
|   |-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|   |-- ld.lld:error:vmlinux.a(arch-hexagon-kernel-head.o):(.init.text):relocation-R_HEX_B22_PCREL-out-of-range:is-not-in-references-__vmnewmap
|   |-- ld.lld:error:vmlinux.a(arch-hexagon-kernel-head.o):(.init.text):relocation-R_HEX_B22_PCREL-out-of-range:is-not-in-references-__vmsetvec
|   `-- ld.lld:error:vmlinux.a(arch-hexagon-kernel-head.o):(.init.text):relocation-R_HEX_B22_PCREL-out-of-range:is-not-in-references-memset
|-- hexagon-randconfig-002-20231206
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- i386-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- i386-allyesconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- i386-randconfig-061-20231206
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-opcode-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-owner-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-type-got-int
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- i386-randconfig-141-20231206
|   |-- block-bdev.c-bdev_open_by_dev()-warn:possible-memory-leak-of-handle
|   |-- drivers-hwtracing-stm-core.c-stm_register_device()-error:double-free-of-stm
|   |-- lib-zstd-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-compress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-compress-..-common-bits.h-ZSTD_countLeadingZeros64()-warn:inconsistent-indenting
|   |-- lib-zstd-compress-..-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-compress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting
|   |-- lib-zstd-decompress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-decompress-..-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
|   |-- lib-zstd-decompress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting
|   `-- mm-slub.c-__put_partials()-error:calling-spin_unlock_irqrestore()-with-bogus-flags
|-- powerpc-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- powerpc-allyesconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- powerpc-randconfig-r064-20231206
|   `-- drivers-leds-leds-sun50i-a100.c:error:call-to-__compiletime_assert_NNN-declared-with-error-attribute:FIELD_PREP:value-too-large-for-the-field
|-- powerpc64-randconfig-002-20231206
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- powerpc64-randconfig-003-20231206
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- riscv-randconfig-001-20231206
|   `-- drivers-perf-riscv_pmu_sbi.c:error:incompatible-function-pointer-types-initializing-proc_handler-(aka-int-(-)(const-struct-ctl_table-int-void-unsigned-long-long-long-)-)-with-an-expression-of-type-int
|-- riscv-randconfig-002-20231206
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- s390-randconfig-r111-20231206
|   |-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- x86_64-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
`-- x86_64-allyesconfig
    `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used

elapsed time: 1467m

configs tested: 176
configs skipped: 3

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                                 defconfig   gcc  
arc                         haps_hs_defconfig   gcc  
arc                   randconfig-001-20231206   gcc  
arc                   randconfig-002-20231206   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                                 defconfig   clang
arm                          pxa910_defconfig   gcc  
arm                   randconfig-001-20231206   clang
arm                   randconfig-002-20231206   clang
arm                   randconfig-003-20231206   clang
arm                   randconfig-004-20231206   clang
arm                           spitz_defconfig   clang
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231206   clang
arm64                 randconfig-002-20231206   clang
arm64                 randconfig-003-20231206   clang
arm64                 randconfig-004-20231206   clang
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231206   gcc  
csky                  randconfig-002-20231206   gcc  
hexagon                          allmodconfig   clang
hexagon                           allnoconfig   clang
hexagon                          allyesconfig   clang
hexagon                             defconfig   clang
hexagon               randconfig-001-20231206   clang
hexagon               randconfig-002-20231206   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231206   clang
i386         buildonly-randconfig-002-20231206   clang
i386         buildonly-randconfig-003-20231206   clang
i386         buildonly-randconfig-004-20231206   clang
i386         buildonly-randconfig-005-20231206   clang
i386         buildonly-randconfig-006-20231206   clang
i386                                defconfig   gcc  
i386                  randconfig-001-20231206   clang
i386                  randconfig-002-20231206   clang
i386                  randconfig-003-20231206   clang
i386                  randconfig-004-20231206   clang
i386                  randconfig-005-20231206   clang
i386                  randconfig-006-20231206   clang
i386                  randconfig-011-20231206   gcc  
i386                  randconfig-012-20231206   gcc  
i386                  randconfig-013-20231206   gcc  
i386                  randconfig-014-20231206   gcc  
i386                  randconfig-015-20231206   gcc  
i386                  randconfig-016-20231206   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231206   gcc  
loongarch             randconfig-002-20231206   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
mips                           mtx1_defconfig   clang
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231206   gcc  
nios2                 randconfig-002-20231206   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231206   gcc  
parisc                randconfig-002-20231206   gcc  
parisc64                            defconfig   gcc  
powerpc                     akebono_defconfig   clang
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                 canyonlands_defconfig   gcc  
powerpc               randconfig-001-20231206   clang
powerpc               randconfig-003-20231206   clang
powerpc                     tqm5200_defconfig   clang
powerpc                     tqm8548_defconfig   gcc  
powerpc64             randconfig-001-20231206   clang
powerpc64             randconfig-002-20231206   clang
powerpc64             randconfig-003-20231206   clang
riscv                            allmodconfig   gcc  
riscv                             allnoconfig   clang
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231206   clang
riscv                 randconfig-002-20231206   clang
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231206   gcc  
s390                  randconfig-002-20231206   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                        edosk7705_defconfig   gcc  
sh                        edosk7760_defconfig   gcc  
sh                          lboxre2_defconfig   gcc  
sh                    randconfig-001-20231206   gcc  
sh                    randconfig-002-20231206   gcc  
sh                          rsk7269_defconfig   gcc  
sh                            shmin_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231206   gcc  
sparc64               randconfig-002-20231206   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231206   clang
um                    randconfig-002-20231206   clang
um                           x86_64_defconfig   gcc  
x86_64                           alldefconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231206   clang
x86_64       buildonly-randconfig-002-20231206   clang
x86_64       buildonly-randconfig-003-20231206   clang
x86_64       buildonly-randconfig-004-20231206   clang
x86_64       buildonly-randconfig-005-20231206   clang
x86_64       buildonly-randconfig-006-20231206   clang
x86_64                              defconfig   gcc  
x86_64                randconfig-001-20231206   gcc  
x86_64                randconfig-002-20231206   gcc  
x86_64                randconfig-003-20231206   gcc  
x86_64                randconfig-004-20231206   gcc  
x86_64                randconfig-005-20231206   gcc  
x86_64                randconfig-006-20231206   gcc  
x86_64                randconfig-011-20231206   clang
x86_64                randconfig-012-20231206   clang
x86_64                randconfig-013-20231206   clang
x86_64                randconfig-014-20231206   clang
x86_64                randconfig-015-20231206   clang
x86_64                randconfig-016-20231206   clang
x86_64                randconfig-071-20231206   clang
x86_64                randconfig-072-20231206   clang
x86_64                randconfig-073-20231206   clang
x86_64                randconfig-074-20231206   clang
x86_64                randconfig-075-20231206   clang
x86_64                randconfig-076-20231206   clang
x86_64                          rhel-8.3-rust   clang
xtensa                            allnoconfig   gcc  
xtensa                randconfig-001-20231206   gcc  
xtensa                randconfig-002-20231206   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From jasowang at redhat.com  Wed Dec  6 21:46:19 2023
From: jasowang at redhat.com (Jason Wang)
Date: Thu, 7 Dec 2023 13:46:19 +0800
Subject: [PATCH net-next 5/6] net: introduce page_frag_cache_drain()
In-Reply-To: <20231205113444.63015-6-linyunsheng@huawei.com>
References: <20231205113444.63015-1-linyunsheng@huawei.com> <20231205113444.63015-6-linyunsheng@huawei.com>
Message-ID: <CACGkMEsiDbZcCAKDxK7hQ=pqWM-GHG2UaKRGM264ozqKVwZRPg@mail.gmail.com>

On Tue, Dec 5, 2023 at 7:35?PM Yunsheng Lin <linyunsheng at huawei.com> wrote:
>
> When draining a page_frag_cache, most user are doing
> the similar steps, so introduce an API to avoid code
> duplication.
>
> Signed-off-by: Yunsheng Lin <linyunsheng at huawei.com>
> ---

For vhost part:

Acked-by: Jason Wang <jasowang at redhat.com>

Thanks



From tony at atomide.com  Wed Dec  6 22:08:54 2023
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 7 Dec 2023 08:08:54 +0200
Subject: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc
 for wkup_uart0
In-Reply-To: <7h5y1c7c0q.fsf@baylibre.com>
References: <20231114073209.40756-1-tony@atomide.com>
 <7h5y1c7c0q.fsf@baylibre.com>
Message-ID: <20231207060854.GQ5169@atomide.com>

* Kevin Hilman <khilman at kernel.org> [231205 18:14]:
> I'm a little confused why these power-domain and clocks stay here and
> are not moved under the wkup_uart0 node... 

The resources are also needed by the interconnect target module. It's the
wrapper IP for the child device(s). In this case there's one chip 8250 IP
instance. In some other devices there can be multiple child IP devices
wired to one target module.

> > -		clock-names = "fclk";
> > -		status = "disabled";
> > +		clock-names = "fck";
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges = <0 0 0x2b300000 0x100000>;
> > +
> > +		wkup_uart0: serial at 2b300000 {
> > +			compatible = "ti,am64-uart", "ti,am654-uart";
> > +			reg = <0 0x100>;
> > +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> > +			status = "disabled";
> 
> ...here.
> 
> The SCI device ID 114 is specifically for wkup_uart0[1], so it seems to
> me those should be in the wkup_uart0 node.

Those resources are also needed for the parent target module for revision
detection, quirks, reset, idle register configuration, and to probe the
child devices.

Here the 8250 IP can be set to status = "reserved" when used by the
firmware, and 8250 not touched by Linux. However, the parent interconnect
target module still needs to be configured for idle registers and wake-up
path register bit so the wake-up from deeper suspend states works.

Regards,

Tony


From quic_mojha at quicinc.com  Wed Dec  6 22:12:39 2023
From: quic_mojha at quicinc.com (Mukesh Ojha)
Date: Thu, 7 Dec 2023 11:42:39 +0530
Subject: [PATCH] irqchip/gic-v3-its: BUG_ON if stall bit is set
Message-ID: <1701929559-18252-1-git-send-email-quic_mojha@quicinc.com>

There could be various reason that stall bit could
be set due to software errors while processing
commands in command queue is being processed and
waiting for 1s is not going to help in debugging
as command processing anyways going to be timed
out and system will continue to run and may crash
after some time due to this.

So, to debug such issues what command caused the
stall bit to set, BUG_ON right away.

Signed-off-by: Mukesh Ojha <quic_mojha at quicinc.com>
---
 drivers/irqchip/irq-gic-v3-its.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 9a7a74239eab..8983e0a3318c 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1078,6 +1078,11 @@ static int its_wait_for_range_completion(struct its_node *its,
 		s64 delta;
 
 		rd_idx = readl_relaxed(its->base + GITS_CREADR);
+		/*
+		 * Check for stall bit as there is no point in waiting
+		 * for 1s if the stall bit is already set.
+		 */
+		BUG_ON(rd_idx & 1);
 
 		/*
 		 * Compute the read pointer progress, taking the
-- 
2.7.4



From axe.yang at mediatek.com  Wed Dec  6 22:35:33 2023
From: axe.yang at mediatek.com (Axe Yang)
Date: Thu, 7 Dec 2023 14:35:33 +0800
Subject: [PATCH v4 0/2] mmc: mediatek: add support for 64-steps tuning 
Message-ID: <20231207063535.29546-1-axe.yang@mediatek.com>

Change in v4:
- for SD/SDIO, tune 64 steps by default
- reduce some breaks to improve code readability

Change in v3:
- use BIT_ULL() instead of BIT() to avoid potential left shift operations
  that could cause exceed boundary problem on 32-bit platforms

Change in v2:
- move the change made to document to the front
- change mediatek,tune-step dts property type to enum for better scalability

Axe Yang (2):
  dt-bindings: mmc: mtk-sd: add tuning steps related property
  mmc: mediatek: extend number of tuning steps

 .../devicetree/bindings/mmc/mtk-sd.yaml       |   9 +
 drivers/mmc/host/mtk-sd.c                     | 158 ++++++++++++------
 2 files changed, 119 insertions(+), 48 deletions(-)

-- 
2.18.0



From tony at atomide.com  Wed Dec  6 22:38:02 2023
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 7 Dec 2023 08:38:02 +0200
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <20231205104343.2e3c4105@aktux>
References: <b97f04f6-cda2-4e9b-b729-a5149e36f978@linaro.org>
 <20231205075657.GN5169@atomide.com>
 <df7dd7b0-f315-4033-985a-175f75568a8c@linaro.org>
 <20231205081031.GO5169@atomide.com>
 <efcd64f4-00d2-4671-af3a-e27764f70e8d@linaro.org>
 <20231205083001.GP5169@atomide.com>
 <27f2e3a3-0791-4278-adb2-55ed76820a3a@linaro.org>
 <20231205100246.5db0d6a1@aktux>
 <78a81d54-f12c-401e-9a26-5125eb0b1c65@linaro.org>
 <20231205104343.2e3c4105@aktux>
Message-ID: <20231207063802.GR5169@atomide.com>

* Andreas Kemnade <andreas at kemnade.info> [231205 09:43]:
> On Tue, 5 Dec 2023 10:27:56 +0100
> Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> 
> > On 05/12/2023 10:02, Andreas Kemnade wrote:
> > > On Tue, 5 Dec 2023 09:45:44 +0100
> > > Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> > >   
> > >>> Sure the clock nodes can be there for the child IP, but they won't do
> > >>> anything. And still need to be managed separately by the device driver if
> > >>> added.    
> > >>
> > >> So if OS does not have runtime PM, the bindings are wrong? Bindings
> > >> should not depend on some particular feature of some particular OS.  
> > > 
> > > Any user of the devicetree sees that there is a parent and the parent needs
> > > to be enabled by some mechanism.
> > > E.g. I2c devices do not specify the clocks of the parent (the i2c master)  

Yeah the interconnect target module needs to be enabled before the child
IP can be probed for any OS. That is unless the target module is left on
from the bootloader.

But like I said, I have no objection to also having the clocks for the
child SGX device here. I think two out of the tree SGX clocks are merged,
so one of the three clocks would repeat twice in the binding.

We do provide some of the clock aliases, like fck and ick, for the child
ip automatically by the ti-sysc interconnect target module. But likely we
don't want to clock name specific handling in the driver so best to
standardize on SGX specific clock names. That is if the clock properties
are not set optional.

> > If you use this analogy, then compare it with an I2C device which has
> > these clock inputs. Such device must have clocks in the bindings.
> > 
> I would see target-module = i2c master.
> 
> Well, if there is a variant of the i2c device which does not require
> external clocks and a variant which requires it, then clock can be
> optional.

Yes that sounds about right for an analogy :)

Regards,

Tony


From axe.yang at mediatek.com  Wed Dec  6 22:35:35 2023
From: axe.yang at mediatek.com (Axe Yang)
Date: Thu, 7 Dec 2023 14:35:35 +0800
Subject: [PATCH v4 2/2] mmc: mediatek: extend number of tuning steps
In-Reply-To: <20231207063535.29546-1-axe.yang@mediatek.com>
References: <20231207063535.29546-1-axe.yang@mediatek.com>
Message-ID: <20231207063535.29546-3-axe.yang@mediatek.com>

Previously, during the MSDC calibration process, a full clock cycle
actually not be covered, which in some cases didn't yield the best
results and could cause CRC errors. This problem is particularly
evident when MSDC is used as an SDIO host. In fact, MSDC support
tuning up to a maximum of 64 steps, but by default, the step number
is 32. By increase the tuning step, we are more likely to cover more
parts of a clock cycle, and get better calibration result.

To illustrate, when tuning 32 steps, if the obtained window has a hole
near the middle, like this: 0xffc07ff (hex), then the selected delay
will be the 6 (counting from right to left).

(32 <- 1)
1111 1111 1100 0000 0000 0111 11(1)1 1111

However, if we tune 64 steps, the window obtained may look like this:
0xfffffffffffc07ff. The final selected delay will be 44, which is
safer as it is further away from the hole:

(64 <- 1)
1111 ... (1)111 1111 1111 1111 1111 1100 0000 0000 0111 1111 1111

In this case, delay 6 selected through 32 steps tuning is obviously
not optimal, and this delay is closer to the hole, using it would
easily cause CRC problems.

As per mesaurements taken on mediatek SoC platform, the tuning phase
will take:
	eMMC	- 32 steps: ~3ms
		- 64 steps: ~6ms
	SDIO	- 32 steps: ~4ms
		- 64 steos: ~7ms
Tuning more steps won't prolong boot times by any meaningful amount
of time, so for SD/SDIO the default tuning steps will be adjust to
64. But for eMMC, it is still preferred to use 32 steps tuning as
otherwise there would be performance lose when accessing the RPMB
partition(requiring retuning each time).

You can configure property "mediatek,tuning-step" in MSDC dts node
to adjust the step number.

Signed-off-by: Axe Yang <axe.yang at mediatek.com>
---
 drivers/mmc/host/mtk-sd.c | 158 ++++++++++++++++++++++++++------------
 1 file changed, 110 insertions(+), 48 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 97f7c3d4be6e..f315db48ac02 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -252,12 +252,16 @@
 
 #define MSDC_PAD_TUNE_DATWRDLY	  GENMASK(4, 0)		/* RW */
 #define MSDC_PAD_TUNE_DATRRDLY	  GENMASK(12, 8)	/* RW */
+#define MSDC_PAD_TUNE_DATRRDLY2	  GENMASK(12, 8)	/* RW */
 #define MSDC_PAD_TUNE_CMDRDLY	  GENMASK(20, 16)	/* RW */
+#define MSDC_PAD_TUNE_CMDRDLY2	  GENMASK(20, 16)	/* RW */
 #define MSDC_PAD_TUNE_CMDRRDLY	  GENMASK(26, 22)	/* RW */
 #define MSDC_PAD_TUNE_CLKTDLY	  GENMASK(31, 27)	/* RW */
 #define MSDC_PAD_TUNE_RXDLYSEL	  BIT(15)   /* RW */
 #define MSDC_PAD_TUNE_RD_SEL	  BIT(13)   /* RW */
 #define MSDC_PAD_TUNE_CMD_SEL	  BIT(21)   /* RW */
+#define MSDC_PAD_TUNE_RD2_SEL	  BIT(13)   /* RW */
+#define MSDC_PAD_TUNE_CMD2_SEL	  BIT(21)   /* RW */
 
 #define PAD_DS_TUNE_DLY_SEL       BIT(0)	  /* RW */
 #define PAD_DS_TUNE_DLY1	  GENMASK(6, 2)   /* RW */
@@ -325,7 +329,9 @@
 
 #define DEFAULT_DEBOUNCE	(8)	/* 8 cycles CD debounce */
 
-#define PAD_DELAY_MAX	32 /* PAD delay cells */
+#define TUNING_REG2_FIXED_OFFEST	4
+#define PAD_DELAY_HALF	32 /* PAD delay cells */
+#define PAD_DELAY_FULL	64
 /*--------------------------------------------------------------------------*/
 /* Descriptor Structure                                                     */
 /*--------------------------------------------------------------------------*/
@@ -461,6 +467,7 @@ struct msdc_host {
 	u32 hs400_ds_dly3;
 	u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
 	u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
+	u32 tuning_step;
 	bool hs400_cmd_resp_sel_rising;
 				 /* cmd response sample selection for HS400 */
 	bool hs400_mode;	/* current eMMC will run at hs400 mode */
@@ -1615,7 +1622,7 @@ static irqreturn_t msdc_cmdq_irq(struct msdc_host *host, u32 intsts)
 	}
 
 	if (cmd_err || dat_err) {
-		dev_err(host->dev, "cmd_err = %d, dat_err =%d, intsts = 0x%x",
+		dev_err(host->dev, "cmd_err = %d, dat_err = %d, intsts = 0x%x",
 			cmd_err, dat_err, intsts);
 	}
 
@@ -1780,10 +1787,20 @@ static void msdc_init_hw(struct msdc_host *host)
 				     DATA_K_VALUE_SEL);
 			sdr_set_bits(host->top_base + EMMC_TOP_CMD,
 				     PAD_CMD_RD_RXDLY_SEL);
+			if (host->tuning_step > PAD_DELAY_HALF) {
+				sdr_set_bits(host->top_base + EMMC_TOP_CONTROL,
+					     PAD_DAT_RD_RXDLY2_SEL);
+				sdr_set_bits(host->top_base + EMMC_TOP_CMD,
+					     PAD_CMD_RD_RXDLY2_SEL);
+			}
 		} else {
 			sdr_set_bits(host->base + tune_reg,
 				     MSDC_PAD_TUNE_RD_SEL |
 				     MSDC_PAD_TUNE_CMD_SEL);
+			if (host->tuning_step > PAD_DELAY_HALF)
+				sdr_set_bits(host->base + tune_reg + TUNING_REG2_FIXED_OFFEST,
+					     MSDC_PAD_TUNE_RD2_SEL |
+					     MSDC_PAD_TUNE_CMD2_SEL);
 		}
 	} else {
 		/* choose clock tune */
@@ -1925,24 +1942,24 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 		msdc_set_mclk(host, ios->timing, ios->clock);
 }
 
-static u32 test_delay_bit(u32 delay, u32 bit)
+static u64 test_delay_bit(u64 delay, u32 bit)
 {
-	bit %= PAD_DELAY_MAX;
-	return delay & BIT(bit);
+	bit %= PAD_DELAY_FULL;
+	return delay & BIT_ULL(bit);
 }
 
-static int get_delay_len(u32 delay, u32 start_bit)
+static int get_delay_len(u64 delay, u32 start_bit)
 {
 	int i;
 
-	for (i = 0; i < (PAD_DELAY_MAX - start_bit); i++) {
+	for (i = 0; i < (PAD_DELAY_FULL - start_bit); i++) {
 		if (test_delay_bit(delay, start_bit + i) == 0)
 			return i;
 	}
-	return PAD_DELAY_MAX - start_bit;
+	return PAD_DELAY_FULL - start_bit;
 }
 
-static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u32 delay)
+static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u64 delay)
 {
 	int start = 0, len = 0;
 	int start_final = 0, len_final = 0;
@@ -1950,28 +1967,28 @@ static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u32 delay)
 	struct msdc_delay_phase delay_phase = { 0, };
 
 	if (delay == 0) {
-		dev_err(host->dev, "phase error: [map:%x]\n", delay);
+		dev_err(host->dev, "phase error: [map:%016llx]\n", delay);
 		delay_phase.final_phase = final_phase;
 		return delay_phase;
 	}
 
-	while (start < PAD_DELAY_MAX) {
+	while (start < PAD_DELAY_FULL) {
 		len = get_delay_len(delay, start);
 		if (len_final < len) {
 			start_final = start;
 			len_final = len;
 		}
 		start += len ? len : 1;
-		if (len >= 12 && start_final < 4)
+		if (!upper_32_bits(delay) && len >= 12 && start_final < 4)
 			break;
 	}
 
 	/* The rule is that to find the smallest delay cell */
 	if (start_final == 0)
-		final_phase = (start_final + len_final / 3) % PAD_DELAY_MAX;
+		final_phase = (start_final + len_final / 3) % PAD_DELAY_FULL;
 	else
-		final_phase = (start_final + len_final / 2) % PAD_DELAY_MAX;
-	dev_dbg(host->dev, "phase: [map:%x] [maxlen:%d] [final:%d]\n",
+		final_phase = (start_final + len_final / 2) % PAD_DELAY_FULL;
+	dev_dbg(host->dev, "phase: [map:%016llx] [maxlen:%d] [final:%d]\n",
 		delay, len_final, final_phase);
 
 	delay_phase.maxlen = len_final;
@@ -1984,30 +2001,64 @@ static inline void msdc_set_cmd_delay(struct msdc_host *host, u32 value)
 {
 	u32 tune_reg = host->dev_comp->pad_tune_reg;
 
-	if (host->top_base)
-		sdr_set_field(host->top_base + EMMC_TOP_CMD, PAD_CMD_RXDLY,
-			      value);
-	else
-		sdr_set_field(host->base + tune_reg, MSDC_PAD_TUNE_CMDRDLY,
-			      value);
+	if (host->top_base) {
+		if (value < PAD_DELAY_HALF) {
+			sdr_set_field(host->top_base + EMMC_TOP_CMD, PAD_CMD_RXDLY, value);
+			sdr_set_field(host->top_base + EMMC_TOP_CMD, PAD_CMD_RXDLY2, 0);
+		} else {
+			sdr_set_field(host->top_base + EMMC_TOP_CMD, PAD_CMD_RXDLY,
+				      PAD_DELAY_HALF - 1);
+			sdr_set_field(host->top_base + EMMC_TOP_CMD, PAD_CMD_RXDLY2,
+				      value - PAD_DELAY_HALF);
+		}
+	} else {
+		if (value < PAD_DELAY_HALF) {
+			sdr_set_field(host->base + tune_reg, MSDC_PAD_TUNE_CMDRDLY, value);
+			sdr_set_field(host->base + tune_reg + TUNING_REG2_FIXED_OFFEST,
+				      MSDC_PAD_TUNE_CMDRDLY2, 0);
+		} else {
+			sdr_set_field(host->base + tune_reg, MSDC_PAD_TUNE_CMDRDLY,
+				      PAD_DELAY_HALF - 1);
+			sdr_set_field(host->base + tune_reg + TUNING_REG2_FIXED_OFFEST,
+				      MSDC_PAD_TUNE_CMDRDLY2, value - PAD_DELAY_HALF);
+		}
+	}
 }
 
 static inline void msdc_set_data_delay(struct msdc_host *host, u32 value)
 {
 	u32 tune_reg = host->dev_comp->pad_tune_reg;
 
-	if (host->top_base)
-		sdr_set_field(host->top_base + EMMC_TOP_CONTROL,
-			      PAD_DAT_RD_RXDLY, value);
-	else
-		sdr_set_field(host->base + tune_reg, MSDC_PAD_TUNE_DATRRDLY,
-			      value);
+	if (host->top_base) {
+		if (value < PAD_DELAY_HALF) {
+			sdr_set_field(host->top_base + EMMC_TOP_CONTROL,
+				      PAD_DAT_RD_RXDLY, value);
+			sdr_set_field(host->top_base + EMMC_TOP_CONTROL,
+				      PAD_DAT_RD_RXDLY2, 0);
+		} else {
+			sdr_set_field(host->top_base + EMMC_TOP_CONTROL,
+				      PAD_DAT_RD_RXDLY, PAD_DELAY_HALF - 1);
+			sdr_set_field(host->top_base + EMMC_TOP_CONTROL,
+				      PAD_DAT_RD_RXDLY2, value - PAD_DELAY_HALF);
+		}
+	} else {
+		if (value < PAD_DELAY_HALF) {
+			sdr_set_field(host->base + tune_reg, MSDC_PAD_TUNE_DATRRDLY, value);
+			sdr_set_field(host->base + tune_reg + TUNING_REG2_FIXED_OFFEST,
+				      MSDC_PAD_TUNE_DATRRDLY2, 0);
+		} else {
+			sdr_set_field(host->base + tune_reg, MSDC_PAD_TUNE_DATRRDLY,
+				      PAD_DELAY_HALF - 1);
+			sdr_set_field(host->base + tune_reg + TUNING_REG2_FIXED_OFFEST,
+				      MSDC_PAD_TUNE_DATRRDLY2, value - PAD_DELAY_HALF);
+		}
+	}
 }
 
 static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
 {
 	struct msdc_host *host = mmc_priv(mmc);
-	u32 rise_delay = 0, fall_delay = 0;
+	u64 rise_delay = 0, fall_delay = 0;
 	struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
 	struct msdc_delay_phase internal_delay_phase;
 	u8 final_delay, final_maxlen;
@@ -2023,7 +2074,7 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
 			      host->hs200_cmd_int_delay);
 
 	sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
-	for (i = 0 ; i < PAD_DELAY_MAX; i++) {
+	for (i = 0; i < host->tuning_step; i++) {
 		msdc_set_cmd_delay(host, i);
 		/*
 		 * Using the same parameters, it may sometimes pass the test,
@@ -2033,9 +2084,9 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
 		for (j = 0; j < 3; j++) {
 			mmc_send_tuning(mmc, opcode, &cmd_err);
 			if (!cmd_err) {
-				rise_delay |= BIT(i);
+				rise_delay |= BIT_ULL(i);
 			} else {
-				rise_delay &= ~BIT(i);
+				rise_delay &= ~BIT_ULL(i);
 				break;
 			}
 		}
@@ -2047,7 +2098,7 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
 		goto skip_fall;
 
 	sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
-	for (i = 0; i < PAD_DELAY_MAX; i++) {
+	for (i = 0; i < host->tuning_step; i++) {
 		msdc_set_cmd_delay(host, i);
 		/*
 		 * Using the same parameters, it may sometimes pass the test,
@@ -2057,9 +2108,9 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
 		for (j = 0; j < 3; j++) {
 			mmc_send_tuning(mmc, opcode, &cmd_err);
 			if (!cmd_err) {
-				fall_delay |= BIT(i);
+				fall_delay |= BIT_ULL(i);
 			} else {
-				fall_delay &= ~BIT(i);
+				fall_delay &= ~BIT_ULL(i);
 				break;
 			}
 		}
@@ -2082,12 +2133,12 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
 	if (host->dev_comp->async_fifo || host->hs200_cmd_int_delay)
 		goto skip_internal;
 
-	for (i = 0; i < PAD_DELAY_MAX; i++) {
+	for (i = 0; i < host->tuning_step; i++) {
 		sdr_set_field(host->base + tune_reg,
 			      MSDC_PAD_TUNE_CMDRRDLY, i);
 		mmc_send_tuning(mmc, opcode, &cmd_err);
 		if (!cmd_err)
-			internal_delay |= BIT(i);
+			internal_delay |= BIT_ULL(i);
 	}
 	dev_dbg(host->dev, "Final internal delay: 0x%x\n", internal_delay);
 	internal_delay_phase = get_best_delay(host, internal_delay);
@@ -2121,7 +2172,8 @@ static int hs400_tune_response(struct mmc_host *mmc, u32 opcode)
 		sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
 	else
 		sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
-	for (i = 0 ; i < PAD_DELAY_MAX; i++) {
+
+	for (i = 0; i < PAD_DELAY_HALF; i++) {
 		sdr_set_field(host->base + PAD_CMD_TUNE,
 			      PAD_CMD_TUNE_RX_DLY3, i);
 		/*
@@ -2151,7 +2203,7 @@ static int hs400_tune_response(struct mmc_host *mmc, u32 opcode)
 static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
 {
 	struct msdc_host *host = mmc_priv(mmc);
-	u32 rise_delay = 0, fall_delay = 0;
+	u64 rise_delay = 0, fall_delay = 0;
 	struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
 	u8 final_delay, final_maxlen;
 	int i, ret;
@@ -2160,11 +2212,11 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
 		      host->latch_ck);
 	sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_DSPL);
 	sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_W_DSPL);
-	for (i = 0 ; i < PAD_DELAY_MAX; i++) {
+	for (i = 0; i < host->tuning_step; i++) {
 		msdc_set_data_delay(host, i);
 		ret = mmc_send_tuning(mmc, opcode, NULL);
 		if (!ret)
-			rise_delay |= BIT(i);
+			rise_delay |= BIT_ULL(i);
 	}
 	final_rise_delay = get_best_delay(host, rise_delay);
 	/* if rising edge has enough margin, then do not scan falling edge */
@@ -2174,11 +2226,11 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
 
 	sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_DSPL);
 	sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_W_DSPL);
-	for (i = 0; i < PAD_DELAY_MAX; i++) {
+	for (i = 0; i < host->tuning_step; i++) {
 		msdc_set_data_delay(host, i);
 		ret = mmc_send_tuning(mmc, opcode, NULL);
 		if (!ret)
-			fall_delay |= BIT(i);
+			fall_delay |= BIT_ULL(i);
 	}
 	final_fall_delay = get_best_delay(host, fall_delay);
 
@@ -2206,7 +2258,7 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
 static int msdc_tune_together(struct mmc_host *mmc, u32 opcode)
 {
 	struct msdc_host *host = mmc_priv(mmc);
-	u32 rise_delay = 0, fall_delay = 0;
+	u64 rise_delay = 0, fall_delay = 0;
 	struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
 	u8 final_delay, final_maxlen;
 	int i, ret;
@@ -2217,12 +2269,12 @@ static int msdc_tune_together(struct mmc_host *mmc, u32 opcode)
 	sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
 	sdr_clr_bits(host->base + MSDC_IOCON,
 		     MSDC_IOCON_DSPL | MSDC_IOCON_W_DSPL);
-	for (i = 0 ; i < PAD_DELAY_MAX; i++) {
+	for (i = 0; i < host->tuning_step; i++) {
 		msdc_set_cmd_delay(host, i);
 		msdc_set_data_delay(host, i);
 		ret = mmc_send_tuning(mmc, opcode, NULL);
 		if (!ret)
-			rise_delay |= BIT(i);
+			rise_delay |= BIT_ULL(i);
 	}
 	final_rise_delay = get_best_delay(host, rise_delay);
 	/* if rising edge has enough margin, then do not scan falling edge */
@@ -2233,12 +2285,12 @@ static int msdc_tune_together(struct mmc_host *mmc, u32 opcode)
 	sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
 	sdr_set_bits(host->base + MSDC_IOCON,
 		     MSDC_IOCON_DSPL | MSDC_IOCON_W_DSPL);
-	for (i = 0; i < PAD_DELAY_MAX; i++) {
+	for (i = 0; i < host->tuning_step; i++) {
 		msdc_set_cmd_delay(host, i);
 		msdc_set_data_delay(host, i);
 		ret = mmc_send_tuning(mmc, opcode, NULL);
 		if (!ret)
-			fall_delay |= BIT(i);
+			fall_delay |= BIT_ULL(i);
 	}
 	final_fall_delay = get_best_delay(host, fall_delay);
 
@@ -2346,7 +2398,7 @@ static int msdc_execute_hs400_tuning(struct mmc_host *mmc, struct mmc_card *card
 	}
 
 	host->hs400_tuning = true;
-	for (i = 0; i < PAD_DELAY_MAX; i++) {
+	for (i = 0; i < PAD_DELAY_HALF; i++) {
 		if (host->top_base)
 			sdr_set_field(host->top_base + EMMC50_PAD_DS_TUNE,
 				      PAD_DS_DLY1, i);
@@ -2580,6 +2632,8 @@ static const struct cqhci_host_ops msdc_cmdq_ops = {
 static void msdc_of_property_parse(struct platform_device *pdev,
 				   struct msdc_host *host)
 {
+	struct mmc_host *mmc = mmc_from_priv(host);
+
 	of_property_read_u32(pdev->dev.of_node, "mediatek,latch-ck",
 			     &host->latch_ck);
 
@@ -2601,6 +2655,14 @@ static void msdc_of_property_parse(struct platform_device *pdev,
 	else
 		host->hs400_cmd_resp_sel_rising = false;
 
+	if (of_property_read_u32(pdev->dev.of_node, "mediatek,tuning-step",
+				 &host->tuning_step)) {
+		if (mmc->caps2 & MMC_CAP2_NO_MMC)
+			host->tuning_step = PAD_DELAY_FULL;
+		else
+			host->tuning_step = PAD_DELAY_HALF;
+	}
+
 	if (of_property_read_bool(pdev->dev.of_node,
 				  "supports-cqe"))
 		host->cqhci = true;
-- 
2.18.0



From dan.carpenter at linaro.org  Wed Dec  6 22:51:07 2023
From: dan.carpenter at linaro.org (Dan Carpenter)
Date: Thu, 7 Dec 2023 09:51:07 +0300
Subject: [PATCH net-next 07/15] net: dsa: mt7530: do not run
 mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-8-arinc.unal@arinc9.com>
 <20231121185358.GA16629@kernel.org>
 <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
Message-ID: <90fde560-054e-4188-b15c-df2e082d3e33@moroto.mountain>

On Sat, Dec 02, 2023 at 11:45:42AM +0300, Ar?n? ?NAL wrote:
> 
> I'm not sure why it doesn't catch that for mt7530_setup_port5() to run
> here, priv->p5_intf_sel must be either P5_INTF_SEL_PHY_P0 or
> P5_INTF_SEL_PHY_P4. And for that to happen, the interface variable will be
> initialised.
> 
> for_each_child_of_node(dn, mac_np) {
> 	if (!of_device_is_compatible(mac_np,
> 				     "mediatek,eth-mac"))
> 		continue;
> 
> 	ret = of_property_read_u32(mac_np, "reg", &id);
> 	if (ret < 0 || id != 1)
> 		continue;
> 
> 	phy_node = of_parse_phandle(mac_np, "phy-handle", 0);
> 	if (!phy_node)
> 		continue;
> 
> 	if (phy_node->parent == priv->dev->of_node->parent) {
> 		ret = of_get_phy_mode(mac_np, &interface);
> 		if (ret && ret != -ENODEV) {
> 			of_node_put(mac_np);
> 			of_node_put(phy_node);
> 			return ret;
> 		}
> 		id = of_mdio_parse_addr(ds->dev, phy_node);
> 		if (id == 0)
> 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P0;
> 		if (id == 4)
> 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P4;
> 	}
> 	of_node_put(mac_np);
> 	of_node_put(phy_node);
> 	break;
> }
> 
> if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 ||
>     priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
> 	mt7530_setup_port5(ds, interface);

Smatch doesn't know:
1) What the value of priv->p5_intf_sel is going into this function
2) We enter the for_each_child_of_node() loop
3) That if (phy_node->parent == priv->dev->of_node->parent) { is
   definitely true for one element on the list.

Looking at how Smatch parses this code, I could probably improve problem
#1 a bit.  Right now Smatch sees "struct mt7530_priv *priv = ds->priv;"
and "priv->p5_intf_sel" is unknown, but I could probably improve it to
where it says that it's in the 1-3 range.  But that doesn't help here
and it doesn't address problems 2 and 3.

It's a hard problem.

regards,
dan carpenter



From gregkh at linuxfoundation.org  Wed Dec  6 18:39:07 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 7 Dec 2023 11:39:07 +0900
Subject: [PATCH v3 1/4] staging: vc04_services: Drop vchiq_log_error() in
 favour of dev_err
In-Reply-To: <6a8566c0-bd26-4ec1-9f7d-d58bbed8411c@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-2-umang.jain@ideasonboard.com>
 <d6bf7115-dd15-43a0-b45a-41fc778ff160@gmx.net>
 <6a8566c0-bd26-4ec1-9f7d-d58bbed8411c@ideasonboard.com>
Message-ID: <2023120750-engorge-wham-83a0@gregkh>

On Wed, Dec 06, 2023 at 10:57:59AM +0530, Umang Jain wrote:
> Hi Stefan
> 
> On 12/6/23 1:02 AM, Stefan Wahren wrote:
> > Hi Umang,
> > 
> > Am 05.12.23 um 09:41 schrieb Umang Jain:
> > > Drop vchiq_log_error() macro which wraps dev_dbg(). Introduce the usage
> > > of dev_err() directly.
> > sorry, i missed to review the last change. So the change won't be that
> > trivial.
> 
> All the changes you said are valid and I have taken a note of it.
> 
> However, I think it would best that if we can address them in a separate
> series on top of this (and I will do it). It would seem to be streamlined on
> top of this.

Agreed, I'll merge this now so you can make forward progress here,
thanks!

greg k-h


From axe.yang at mediatek.com  Wed Dec  6 22:35:34 2023
From: axe.yang at mediatek.com (Axe Yang)
Date: Thu, 7 Dec 2023 14:35:34 +0800
Subject: [PATCH v4 1/2] dt-bindings: mmc: mtk-sd: add tuning steps related property
In-Reply-To: <20231207063535.29546-1-axe.yang@mediatek.com>
References: <20231207063535.29546-1-axe.yang@mediatek.com>
Message-ID: <20231207063535.29546-2-axe.yang@mediatek.com>

Add 'mediatek,tuning-steps' setting. This property will give MSDC
a chance to extend tuning steps up to 64. With more tuning steps,
MSDC may achieve a more optimal calibration result, thus avoiding
potential CRC issues.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Axe Yang <axe.yang at mediatek.com>
---
 Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
index 3fffa467e4e1..c532ec92d2d9 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
@@ -145,6 +145,15 @@ properties:
     minimum: 0
     maximum: 7
 
+  mediatek,tuning-step:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Some SoCs need extend tuning step for better delay value to avoid CRC issue.
+      If not present, default tuning step is 32. For eMMC and SD, this can yield
+      satisfactory calibration results in most cases.
+    enum: [32, 64]
+    default: 32
+
   resets:
     maxItems: 1
 
-- 
2.18.0



From alexander.stein at ew.tq-group.com  Wed Dec  6 23:31:56 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 07 Dec 2023 08:31:56 +0100
Subject: [PATCH 0/2] TQMLX2160A support
In-Reply-To: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>
References: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>
Message-ID: <1874330.tdWV9SEqCh@steina-w>

Hi,

Am Mittwoch, 6. Dezember 2023, 15:01:00 CET schrieb Gregor Herburger:
> Hi,
> 
> this series adds initial support for the TQMLX2160A SoM on MBLX2160a
> baseboard. The various supported Serdes Configurations are added with
> overlay files.
> 
> Patch 1 adds the compatible to dt bindings
> Patch 2 adds the dts files
> 
> ---
> Gregor Herburger (2):
>       dt-bindings: arm: fsl: Add TQ-Systems LX2160A based boards
>       arm64: dts: freescale: add fsl-lx2160a-mblx2160a board

For the whole series:
Reviewed-by: Alexander Stein <alexander.stein at ew.tq-group.com>

>  Documentation/devicetree/bindings/arm/fsl.yaml     |  10 +
>  arch/arm64/boot/dts/freescale/Makefile             |  26 ++
>  .../freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 338
> +++++++++++++++++++++ .../fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtso   | 
> 29 ++
>  .../fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtso   |  17 ++
>  .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso   |  49 +++
>  .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso    |  55 ++++
>  .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtso    |  47 +++
>  .../boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi |  97 ++++++
>  9 files changed, 668 insertions(+)
> ---
> base-commit: 8728c14129df7a6e29188a2e737b4774fb200953
> change-id: 20231206-for-ml-tqmlx2160a-68ee235f71cd
> 
> Best regards,


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From maz at kernel.org  Wed Dec  6 23:43:04 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 07 Dec 2023 07:43:04 +0000
Subject: [PATCH] irqchip/gic-v3-its: BUG_ON if stall bit is set
In-Reply-To: <1701929559-18252-1-git-send-email-quic_mojha@quicinc.com>
References: <1701929559-18252-1-git-send-email-quic_mojha@quicinc.com>
Message-ID: <87edfy8nlj.wl-maz@kernel.org>

On Thu, 07 Dec 2023 06:12:39 +0000,
Mukesh Ojha <quic_mojha at quicinc.com> wrote:
> 
> There could be various reason that stall bit could
> be set due to software errors while processing
> commands in command queue is being processed and

Such as?

> waiting for 1s is not going to help in debugging
> as command processing anyways going to be timed
> out and system will continue to run and may crash
> after some time due to this.
> 
> So, to debug such issues what command caused the
> stall bit to set, BUG_ON right away.

How on Earth will killing the system allow *anything* to be further
debugged?

If you need debug information, add the correct debug statements using
pr_debug(). Even better, try to gracefully recover from it if the ITS
command queue supports restarting.

Crashing the system is not an option.

	M.

-- 
Without deviation from the norm, progress is not possible.


From alexander.stein at ew.tq-group.com  Wed Dec  6 23:52:46 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 07 Dec 2023 08:52:46 +0100
Subject: [PATCH 1/1] media: nxp: imx8-isi-debug: Add missing registers to debugfs output
In-Reply-To: <20231206223636.GE29417@pendragon.ideasonboard.com>
References: <20231206094401.491100-1-alexander.stein@ew.tq-group.com> <20231206223636.GE29417@pendragon.ideasonboard.com>
Message-ID: <2915417.e9J7NaK4W3@steina-w>

Hi Laurent,

Am Mittwoch, 6. Dezember 2023, 23:36:36 CET schrieb Laurent Pinchart:
> Hi Alexander,
> 
> On Wed, Dec 06, 2023 at 10:44:01AM +0100, Alexander Stein wrote:
> > The extended address registers are missing in the debug output register
> > list. Add them.
> > 
> > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> > ---
> > 
> >  drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c index
> > 6709ab7ea1f3..3ac5685d6cc1 100644
> > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > @@ -66,6 +66,13 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file
> > *m, void *p)> 
> >  		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF2_ADDR_V),
> >  		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
> >  		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
> > 
> > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),
> 
> Those registers only exist in the i.MX8MP. The i.MX8MN referenece manual
> lists them as reserved and indicates they read as 0's, so it should be
> safe.  The i.MX93 reference manual, however, doesn't list those
> registers at all, so accessing them may lead to issues.
> 
> How what platform(s) have you tested this patch ?

Ah, you are right. That's something I didn't take into account. Up until now I 
only tested this on i.MX8MP. I hope I can test this on i.MX8MN and i.MX93 
soon.
Otherwise dumping these registers can depend on pdata->has_36bit_dma just to 
be safe.

Best regards,
Alexander

> >  	};
> >  	
> >  	struct mxc_isi_pipe *pipe = m->private;


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From tomi.valkeinen at ideasonboard.com  Wed Dec  6 23:57:46 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Thu, 07 Dec 2023 09:57:46 +0200
Subject: [PATCH v3 2/4] media: rkisp1: Fix IRQ handler return values
In-Reply-To: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>
References: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>
Message-ID: <20231207-rkisp-irq-fix-v3-2-358a2c871a3c@ideasonboard.com>

The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an
irqreturn_t value, but rkisp1_isr() ignores those values and always
returns IRQ_HANDLED.

Fix this by collecting the return values, and returning IRQ_HANDLED or
IRQ_NONE as appropriate.

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Tested-by: Adam Ford <aford173 at gmail.com>  #imx8mp-beacon
Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index 4c4514e20673..22b2ae0e89c4 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -442,17 +442,25 @@ static int rkisp1_entities_register(struct rkisp1_device *rkisp1)
 
 static irqreturn_t rkisp1_isr(int irq, void *ctx)
 {
+	irqreturn_t ret = IRQ_NONE;
+
 	/*
 	 * Call rkisp1_capture_isr() first to handle the frame that
 	 * potentially completed using the current frame_sequence number before
 	 * it is potentially incremented by rkisp1_isp_isr() in the vertical
 	 * sync.
 	 */
-	rkisp1_capture_isr(irq, ctx);
-	rkisp1_isp_isr(irq, ctx);
-	rkisp1_csi_isr(irq, ctx);
 
-	return IRQ_HANDLED;
+	if (rkisp1_capture_isr(irq, ctx) == IRQ_HANDLED)
+		ret = IRQ_HANDLED;
+
+	if (rkisp1_isp_isr(irq, ctx) == IRQ_HANDLED)
+		ret = IRQ_HANDLED;
+
+	if (rkisp1_csi_isr(irq, ctx) == IRQ_HANDLED)
+		ret = IRQ_HANDLED;
+
+	return ret;
 }
 
 static const char * const px30_isp_clks[] = {

-- 
2.34.1



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 23:57:44 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Thu, 07 Dec 2023 09:57:44 +0200
Subject: [PATCH v3 0/4] media: rkisp1: Fix IRQ related issues
Message-ID: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>

These fix a few IRQ related issues I noticed when testing i.MX8MP. This
series, as of v3, is based on linux-media-stage, and does not include
i.MX8MP support, as that is not in upstream yet.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
Changes in v3:
- Rebase on linux-media-stage
- Drop i.MX8MP support (which is a one line change) so that this can be
  based on upstream. I have still kept Adam's tested-by for
  imx8mp-beacon, as dropping the i.MX8MP support doesn't really affect the
  changes.
- Use ARRAY_SIZE() in patch 3
- Link to v2: https://lore.kernel.org/r/20231206-rkisp-irq-fix-v2-0-6ba4185eeb1f at ideasonboard.com

Changes in v2:
- New patch: "media: rkisp1: Drop IRQF_SHARED"
- Update "media: rkisp1: Fix IRQ handler return values" according to
  Laurent's comment.
- Drop "media: rkisp1: Fix IRQ handling due to shared interrupts"
- Update description for "media: rkisp1: Fix IRQ disable race issue"
- Link to v1: https://lore.kernel.org/r/20231205-rkisp-irq-fix-v1-0-f4045c74ba45 at ideasonboard.com

---
Tomi Valkeinen (4):
      media: rkisp1: Drop IRQF_SHARED
      media: rkisp1: Fix IRQ handler return values
      media: rkisp1: Store IRQ lines
      media: rkisp1: Fix IRQ disable race issue

 .../media/platform/rockchip/rkisp1/rkisp1-common.h | 11 ++++++-
 .../media/platform/rockchip/rkisp1/rkisp1-csi.c    | 14 ++++++++-
 .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 35 ++++++++++++++++------
 .../media/platform/rockchip/rkisp1/rkisp1-isp.c    | 20 +++++++++++--
 4 files changed, 66 insertions(+), 14 deletions(-)
---
base-commit: 8016943b5947cd485078e23899945c51e818aa63
change-id: 20231205-rkisp-irq-fix-e123a8a6732f

Best regards,
-- 
Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 23:57:45 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Thu, 07 Dec 2023 09:57:45 +0200
Subject: [PATCH v3 1/4] media: rkisp1: Drop IRQF_SHARED
In-Reply-To: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>
References: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>
Message-ID: <20231207-rkisp-irq-fix-v3-1-358a2c871a3c@ideasonboard.com>

In all known platforms the ISP has dedicated IRQ lines, but for some
reason the driver uses IRQF_SHARED.

Supporting IRQF_SHARED properly requires handling interrupts even when
our device is disabled, and the driver does not handle this. To avoid
adding such code, and to be sure the driver won't accidentally be used
in a platform with shared interrupts, let's drop the IRQF_SHARED flag.

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Tested-by: Adam Ford <aford173 at gmail.com>  #imx8mp-beacon
Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index c41abd2833f1..4c4514e20673 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -542,7 +542,7 @@ static int rkisp1_probe(struct platform_device *pdev)
 		if (irq < 0)
 			return irq;
 
-		ret = devm_request_irq(dev, irq, info->isrs[i].isr, IRQF_SHARED,
+		ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0,
 				       dev_driver_string(dev), dev);
 		if (ret) {
 			dev_err(dev, "request irq failed: %d\n", ret);

-- 
2.34.1



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 23:57:48 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Thu, 07 Dec 2023 09:57:48 +0200
Subject: [PATCH v3 4/4] media: rkisp1: Fix IRQ disable race issue
In-Reply-To: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>
References: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>
Message-ID: <20231207-rkisp-irq-fix-v3-4-358a2c871a3c@ideasonboard.com>

In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
interrupts and then apparently assumes that the interrupt handler won't
be running, and proceeds in the stop procedure. This is not the case, as
the interrupt handler can already be running, which would lead to the
ISP being disabled while the interrupt handler handling a captured
frame.

This brings up two issues: 1) the ISP could be powered off while the
interrupt handler is still running and accessing registers, leading to
board lockup, and 2) the interrupt handler code and the code that
disables the streaming might do things that conflict.

It is not clear to me if 2) causes a real issue, but 1) can be seen with
a suitable delay (or printk in my case) in the interrupt handler,
leading to board lockup.

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Tested-by: Adam Ford <aford173 at gmail.com>  #imx8mp-beacon
Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c | 14 +++++++++++++-
 drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 20 +++++++++++++++++---
 2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
index e6642a2167ef..b6e47e2f1b94 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
@@ -125,8 +125,20 @@ static void rkisp1_csi_disable(struct rkisp1_csi *csi)
 	struct rkisp1_device *rkisp1 = csi->rkisp1;
 	u32 val;
 
-	/* Mask and clear interrupts. */
+	/* Mask MIPI interrupts. */
 	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_IMSC, 0);
+
+	/* Flush posted writes */
+	rkisp1_read(rkisp1, RKISP1_CIF_MIPI_IMSC);
+
+	/*
+	 * Wait until the IRQ handler has ended. The IRQ handler may get called
+	 * even after this, but it will return immediately as the MIPI
+	 * interrupts have been masked.
+	 */
+	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MIPI]);
+
+	/* Clear MIPI interrupt status */
 	rkisp1_write(rkisp1, RKISP1_CIF_MIPI_ICR, ~0);
 
 	val = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_CTRL);
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
index ca6703bfd27b..29b538a5e1bb 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
@@ -254,11 +254,25 @@ static void rkisp1_isp_stop(struct rkisp1_isp *isp)
 	 * ISP(mi) stop in mi frame end -> Stop ISP(mipi) ->
 	 * Stop ISP(isp) ->wait for ISP isp off
 	 */
-	/* stop and clear MI and ISP interrupts */
-	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
-	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
 
+	/* Mask MI and ISP interrupts */
+	rkisp1_write(rkisp1, RKISP1_CIF_ISP_IMSC, 0);
 	rkisp1_write(rkisp1, RKISP1_CIF_MI_IMSC, 0);
+
+	/* Flush posted writes */
+	rkisp1_read(rkisp1, RKISP1_CIF_MI_IMSC);
+
+	/*
+	 * Wait until the IRQ handler has ended. The IRQ handler may get called
+	 * even after this, but it will return immediately as the MI and ISP
+	 * interrupts have been masked.
+	 */
+	synchronize_irq(rkisp1->irqs[RKISP1_IRQ_ISP]);
+	if (rkisp1->irqs[RKISP1_IRQ_ISP] != rkisp1->irqs[RKISP1_IRQ_MI])
+		synchronize_irq(rkisp1->irqs[RKISP1_IRQ_MI]);
+
+	/* Clear MI and ISP interrupt status */
+	rkisp1_write(rkisp1, RKISP1_CIF_ISP_ICR, ~0);
 	rkisp1_write(rkisp1, RKISP1_CIF_MI_ICR, ~0);
 
 	/* stop ISP */

-- 
2.34.1



From tomi.valkeinen at ideasonboard.com  Wed Dec  6 23:57:47 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Thu, 07 Dec 2023 09:57:47 +0200
Subject: [PATCH v3 3/4] media: rkisp1: Store IRQ lines
In-Reply-To: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>
References: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>
Message-ID: <20231207-rkisp-irq-fix-v3-3-358a2c871a3c@ideasonboard.com>

Store the IRQ lines used by the driver for easy access. These are needed
in future patches which fix IRQ race issues.

Tested-by: Adam Ford <aford173 at gmail.com>  #imx8mp-beacon
Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-common.h | 11 ++++++++++-
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c    | 17 +++++++++++++----
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
index 1e7cea1bea5e..2d7f06281c39 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
@@ -61,6 +61,14 @@ struct dentry;
 						 RKISP1_CIF_ISP_EXP_END |	\
 						 RKISP1_CIF_ISP_HIST_MEASURE_RDY)
 
+/* IRQ lines */
+enum rkisp1_irq_line {
+	RKISP1_IRQ_ISP = 0,
+	RKISP1_IRQ_MI,
+	RKISP1_IRQ_MIPI,
+	RKISP1_NUM_IRQS,
+};
+
 /* enum for the resizer pads */
 enum rkisp1_rsz_pad {
 	RKISP1_RSZ_PAD_SINK,
@@ -423,7 +431,6 @@ struct rkisp1_debug {
  * struct rkisp1_device - ISP platform device
  *
  * @base_addr:	   base register address
- * @irq:	   the irq number
  * @dev:	   a pointer to the struct device
  * @clk_size:	   number of clocks
  * @clks:	   array of clocks
@@ -441,6 +448,7 @@ struct rkisp1_debug {
  * @stream_lock:   serializes {start/stop}_streaming callbacks between the capture devices.
  * @debug:	   debug params to be exposed on debugfs
  * @info:	   version-specific ISP information
+ * @irqs:          IRQ line numbers
  */
 struct rkisp1_device {
 	void __iomem *base_addr;
@@ -461,6 +469,7 @@ struct rkisp1_device {
 	struct mutex stream_lock; /* serialize {start/stop}_streaming cb between capture devices */
 	struct rkisp1_debug debug;
 	const struct rkisp1_info *info;
+	int irqs[RKISP1_NUM_IRQS];
 };
 
 /*
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index 22b2ae0e89c4..c3fa40976140 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -114,6 +114,7 @@
 struct rkisp1_isr_data {
 	const char *name;
 	irqreturn_t (*isr)(int irq, void *ctx);
+	u32 line_mask;
 };
 
 /* ----------------------------------------------------------------------------
@@ -471,9 +472,9 @@ static const char * const px30_isp_clks[] = {
 };
 
 static const struct rkisp1_isr_data px30_isp_isrs[] = {
-	{ "isp", rkisp1_isp_isr },
-	{ "mi", rkisp1_capture_isr },
-	{ "mipi", rkisp1_csi_isr },
+	{ "isp", rkisp1_isp_isr, BIT(RKISP1_IRQ_ISP) },
+	{ "mi", rkisp1_capture_isr, BIT(RKISP1_IRQ_MI) },
+	{ "mipi", rkisp1_csi_isr, BIT(RKISP1_IRQ_MIPI) },
 };
 
 static const struct rkisp1_info px30_isp_info = {
@@ -492,7 +493,7 @@ static const char * const rk3399_isp_clks[] = {
 };
 
 static const struct rkisp1_isr_data rk3399_isp_isrs[] = {
-	{ NULL, rkisp1_isr },
+	{ NULL, rkisp1_isr, BIT(RKISP1_IRQ_ISP) | BIT(RKISP1_IRQ_MI) | BIT(RKISP1_IRQ_MIPI) },
 };
 
 static const struct rkisp1_info rk3399_isp_info = {
@@ -543,6 +544,9 @@ static int rkisp1_probe(struct platform_device *pdev)
 	if (IS_ERR(rkisp1->base_addr))
 		return PTR_ERR(rkisp1->base_addr);
 
+	for (unsigned int il = 0; il < ARRAY_SIZE(rkisp1->irqs); ++il)
+		rkisp1->irqs[il] = -1;
+
 	for (i = 0; i < info->isr_size; i++) {
 		irq = info->isrs[i].name
 		    ? platform_get_irq_byname(pdev, info->isrs[i].name)
@@ -550,6 +554,11 @@ static int rkisp1_probe(struct platform_device *pdev)
 		if (irq < 0)
 			return irq;
 
+		for (unsigned int il = 0; il < ARRAY_SIZE(rkisp1->irqs); ++il) {
+			if (info->isrs[i].line_mask & BIT(il))
+				rkisp1->irqs[il] = irq;
+		}
+
 		ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0,
 				       dev_driver_string(dev), dev);
 		if (ret) {

-- 
2.34.1



From u.kleine-koenig at pengutronix.de  Thu Dec  7 00:03:38 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Thu, 7 Dec 2023 09:03:38 +0100
Subject: [PATCH v3 08/16] drm/exynos: Convert to platform remove callback
 returning void
In-Reply-To: <048901da28b6$5be8e700$13bab500$@samsung.com>
References: <20231102165640.3307820-18-u.kleine-koenig@pengutronix.de>
 <20231102165640.3307820-26-u.kleine-koenig@pengutronix.de>
 <CAAQKjZOnVSaO6QHpSo_i=WgTaawTq0UFtzwTw8kQ5iHN4qiAtQ@mail.gmail.com>
 <20231108075454.3aivzrbvtr4en22e@pengutronix.de>
 <CGME20231128165521epcas1p4993f7d2fab0723130a4612d810d254f8@epcas1p4.samsung.com>
 <20231128165505.wm4xs4ktycswthkt@pengutronix.de>
 <048901da28b6$5be8e700$13bab500$@samsung.com>
Message-ID: <20231207080338.kcjx7uixxjw2axtc@pengutronix.de>

Hello Inki,

On Thu, Dec 07, 2023 at 11:37:44AM +0900, ???/Tizen Platform Lab(SR)/???? wrote:
> Hello Uwe Kleine-K?nig,
> 
> > -----Original Message-----
> > From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> > Sent: Wednesday, November 29, 2023 1:55 AM
> > To: Inki Dae <daeinki at gmail.com>
> > Cc: linux-samsung-soc at vger.kernel.org; Daniel Vetter <daniel at ffwll.ch>;
> > Jingoo Han <jingoohan1 at gmail.com>; Seung-Woo Kim <sw0312.kim at samsung.com>;
> > Kyungmin Park <kyungmin.park at samsung.com>; DRI mailing list <dri-
> > devel at lists.freedesktop.org>; Krzysztof Kozlowski
> > <krzysztof.kozlowski at linaro.org>; kernel at pengutronix.de; Alim Akhtar
> > <alim.akhtar at samsung.com>; David Airlie <airlied at gmail.com>; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [PATCH v3 08/16] drm/exynos: Convert to platform remove
> > callback returning void
> > 
> > Hello Inki,
> > 
> > On Wed, Nov 08, 2023 at 08:54:54AM +0100, Uwe Kleine-K?nig wrote:
> > > Hello Inki,
> > >
> > > On Wed, Nov 08, 2023 at 01:16:18PM +0900, Inki Dae wrote:
> > > > Sorry for late. There was a merge conflict so I fixed it manually and
> > > > merged. And seems your patch description is duplicated so dropped
> > > > duplicated one.
> > >
> > > Ah. I have a template that generates one patch per driver. I guess this
> > > is the result of using squash instead of fixup while putting all exynos
> > > changes into a single patch.
> > 
> > This patch didn't make it into next yet even though it's included in
> > your exynos-drm-next branch at
> > https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git.
> > 
> > Is this on purpose?
> 
> drm-exynos tree is not included in the next tree. It was previously
> included, but it has been removed. drm-exynos tree is merged into the
> mainline through the drm-next tree, but when the drm-next is
> synchronized to the next tree, a conflict occurred between the
> exynos-drm tree and the drm-next tree. Therefore, I had requested that
> drm-exynos tree be removed from the next. Perhaps I was inexperienced
> in managing the git tree at that time. :)

That sounds more like a reason to have your tree in next. One of the
core motivations of next is to find inter-tree conflicts early. If such
a conflict occurs and you only notice it when it's time to send your PR
to drm-next (or even later) the pressure to fix the problem is higher.

Also for patch contributors it's nice to have a "complete" next, their
tests are more expressive then.

So I want to encourage you to readd your tree to next.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/696ae1fc/attachment.sig>

From zajec5 at gmail.com  Thu Dec  7 00:05:12 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu,  7 Dec 2023 09:05:12 +0100
Subject: [PATCH V3 3/3] arm64: dts: mediatek: Add Acelink EW-7886CAX
In-Reply-To: <20231207080512.3688-1-zajec5@gmail.com>
References: <20231207080512.3688-1-zajec5@gmail.com>
Message-ID: <20231207080512.3688-3-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point.
It has 512 MiB of RAM, one 2.5 Gbps PoE (802.3at) Ethernet port and
on-SoC Wi-Fi.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
V2: Update coding style to follow:
    [PATCH v4] docs: dt-bindings: add DTS Coding Style document
V3: Add missing semicolon (I forgot to amend my local V2 change, sorry!)
    Drop unused "partitions" label

 arch/arm64/boot/dts/mediatek/Makefile         |   1 +
 .../mediatek/mt7986a-acelink-ew-7886cax.dts   | 173 ++++++++++++++++++
 2 files changed, 174 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index e6e7592a3645..9ff2ab6c5e4d 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-acelink-ew-7886cax.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nand.dtbo
diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts b/arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts
new file mode 100644
index 000000000000..08b3b0827436
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-acelink-ew-7886cax.dts
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+
+#include "mt7986a.dtsi"
+
+/ {
+	compatible = "acelink,ew-7886cax", "mediatek,mt7986a";
+	model = "Acelink EW-7886CAX";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory at 40000000 {
+		reg = <0 0x40000000 0 0x20000000>;
+		device_type = "memory";
+	};
+
+	keys {
+		compatible = "gpio-keys";
+
+		key-restart {
+			label = "Reset";
+			gpios = <&pio 7 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_RESTART>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			function = LED_FUNCTION_STATUS;
+			color = <LED_COLOR_ID_RED>;
+			gpios = <&pio 18 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-1 {
+			function = LED_FUNCTION_STATUS;
+			color = <LED_COLOR_ID_GREEN>;
+			gpios = <&pio 19 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-2 {
+			function = LED_FUNCTION_STATUS;
+			color = <LED_COLOR_ID_BLUE>;
+			gpios = <&pio 20 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+&crypto {
+	status = "okay";
+};
+
+&eth {
+	status = "okay";
+
+	mac at 1 {
+		compatible = "mediatek,eth-mac";
+		reg = <1>;
+		phy-mode = "2500base-x";
+		phy-handle = <&phy6>;
+		nvmem-cells = <&macaddr>;
+		nvmem-cell-names = "mac-address";
+	};
+
+	mdio-bus {
+		reset-gpios = <&pio 6 GPIO_ACTIVE_LOW>;
+		reset-delay-us = <50000>;
+		reset-post-delay-us = <20000>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy6: phy at 6 {
+			compatible = "ethernet-phy-ieee802.3-c45";
+			reg = <6>;
+		};
+	};
+};
+
+&pcie_phy {
+	status = "okay";
+};
+
+&spi0 {
+	status = "okay";
+
+	flash at 0 {
+		compatible = "spi-nand";
+		reg = <0>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		spi-max-frequency = <52000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition at 0 {
+				reg = <0x0 0x100000>;
+				label = "bootloader";
+				read-only;
+			};
+
+			partition at 100000 {
+				reg = <0x100000 0x80000>;
+				label = "u-boot-env";
+			};
+
+			partition at 180000 {
+				compatible = "nvmem-cells";
+				reg = <0x180000 0x200000>;
+				label = "factory";
+				read-only;
+
+				nvmem-layout {
+					compatible = "fixed-layout";
+					#address-cells = <1>;
+					#size-cells = <1>;
+
+					eeprom: eeprom at 0 {
+						reg = <0x0 0x1000>;
+					};
+
+					macaddr: macaddr at 4 {
+						reg = <0x4 0x6>;
+					};
+				};
+			};
+
+			partition at 380000 {
+				reg = <0x380000 0x200000>;
+				label = "fip";
+			};
+
+			partition at 580000 {
+				reg = <0x580000 0x4000000>;
+				label = "ubi";
+			};
+		};
+	};
+};
+
+&trng {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&watchdog {
+	status = "okay";
+};
+
+&wifi {
+	nvmem-cells = <&eeprom>;
+	nvmem-cell-names = "eeprom";
+	status = "okay";
+};
-- 
2.35.3



From zajec5 at gmail.com  Thu Dec  7 00:05:11 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu,  7 Dec 2023 09:05:11 +0100
Subject: [PATCH V3 2/3] dt-bindings: arm64: dts: mediatek: Add Acelink EW-7886CAX access point
In-Reply-To: <20231207080512.3688-1-zajec5@gmail.com>
References: <20231207080512.3688-1-zajec5@gmail.com>
Message-ID: <20231207080512.3688-2-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index a5999b3afc35..cfdd3317edda 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -84,6 +84,7 @@ properties:
           - const: mediatek,mt7629
       - items:
           - enum:
+              - acelink,ew-7886cax
               - bananapi,bpi-r3
               - mediatek,mt7986a-rfb
           - const: mediatek,mt7986a
-- 
2.35.3



From zajec5 at gmail.com  Thu Dec  7 00:05:10 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu,  7 Dec 2023 09:05:10 +0100
Subject: [PATCH V3 1/3] dt-bindings: vendor-prefixes: add acelink
Message-ID: <20231207080512.3688-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Acelink is a Taiwan company providing network products (routers, access
points, switches, cameras and more).

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c8..503a3caf6fc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -39,6 +39,8 @@ patternProperties:
     description: ShenZhen Asia Better Technology Ltd.
   "^acbel,.*":
     description: Acbel Polytech Inc.
+  "^acelink,.*":
+    description: Acelink Technology Co., Ltd.
   "^acer,.*":
     description: Acer Inc.
   "^acme,.*":
-- 
2.35.3



From krzysztof.kozlowski at linaro.org  Thu Dec  7 00:18:20 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 09:18:20 +0100
Subject: [PATCH 1/2] media: i2c: Add GC08A3 image sensor driver
In-Reply-To: <20231207052016.25954-2-zhi.mao@mediatek.com>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
 <20231207052016.25954-2-zhi.mao@mediatek.com>
Message-ID: <1d58c2b9-4206-409c-b312-87f4fb649512@linaro.org>

On 07/12/2023 06:20, Zhi Mao wrote:
> Add a V4L2 sub-device driver for Galaxycore GC08A3 image sensor.
> 
> Reviewed-By: yunkec at chromium.org

I don't see review given here:

https://lore.kernel.org/linux-media/20231123115104.32094-1-zhi.mao at mediatek.com/

This does not look like real review. Where was it performed? How
thorough was it? How many review iterations did it include?  Why there
is no name but anonymous review?



> Signed-off-by: Zhi Mao <zhi.mao at mediatek.com>
> ---
>  drivers/media/i2c/Kconfig  |   14 +
>  drivers/media/i2c/Makefile |    1 +
>  drivers/media/i2c/gc08a3.c | 1888 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 1903 insertions(+)
>  create mode 100644 drivers/media/i2c/gc08a3.c
> 

...

> +static inline struct gc08a3 *to_gc08a3(struct v4l2_subdev *sd)
> +{
> +	return container_of(sd, struct gc08a3, sd);
> +}
> +
> +static int gc08a3_power_on(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +	int ret;
> +
> +	gpiod_set_value_cansleep(gc08a3->enable_gpio, 0);

Why do you put make enable GPIO low? That's not how enable GPIO is
supposed to work...

> +	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
> +
> +	ret = regulator_bulk_enable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
> +	if (ret < 0) {
> +		dev_err(gc08a3->dev, "failed to enable regulators: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = clk_prepare_enable(gc08a3->xclk);
> +	if (ret < 0) {
> +		regulator_bulk_disable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
> +		dev_err(gc08a3->dev, "clk prepare enable failed\n");
> +		return ret;
> +	}
> +
> +	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
> +
> +	gpiod_set_value_cansleep(gc08a3->enable_gpio, 1);
> +	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_power_off(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	gpiod_set_value_cansleep(gc08a3->enable_gpio, 0);

How making enable GPIO low is related to power off? Enable means you
turn on some feature, not shutdown. Look at common GPIO consumer
bindings in the kernel.


...

> +static int gc08a3_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct gc08a3 *gc08a3;
> +	int ret;
> +
> +	ret = gc08a3_parse_fwnode(dev);
> +	if (ret)
> +		return ret;
> +
> +	gc08a3 = devm_kzalloc(dev, sizeof(*gc08a3), GFP_KERNEL);
> +	if (!gc08a3)
> +		return -ENOMEM;
> +
> +	gc08a3->dev = dev;
> +
> +	gc08a3->xclk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(gc08a3->xclk))
> +		return dev_err_probe(dev, PTR_ERR(gc08a3->xclk),
> +					 "failed to get xclk\n");

Misaligned indentation

> +
> +	ret = clk_set_rate(gc08a3->xclk, GC08A3_DEFAULT_CLK_FREQ);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +					 "failed to set xclk frequency\n");

Misaligned indentation

> +
> +	ret = gc08a3_get_regulators(dev, gc08a3);
> +	if (ret < 0)
> +		return dev_err_probe(dev, ret,
> +					 "failed to get regulators\n");

Misaligned indentation

> +
> +	gc08a3->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(gc08a3->enable_gpio))
> +		return dev_err_probe(dev, PTR_ERR(gc08a3->enable_gpio),
> +					 "failed to get gpio\n");

Misaligned indentation... probably entire code is misaligned.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec  7 00:19:01 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 09:19:01 +0100
Subject: [PATCH v2 0/2] media: i2c: Add support for GC08A3 sensor
In-Reply-To: <20231207052016.25954-1-zhi.mao@mediatek.com>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
Message-ID: <c8e0ff23-9464-441d-bcaa-485a3eca0fcd@linaro.org>

On 07/12/2023 06:20, Zhi Mao wrote:
> This series adds YAML DT binding and V4L2 sub-device driver for Galaxycore's
> GC08A3 8-megapixel 10-bit RAW CMOS 1/4" sensor, with an MIPI CSI-2 image data
> interface and the I2C control bus.
> 
> The driver is implemented with V4L2 framework.
>  - Async registered as a V4L2 sub-device.
>  - As the first component of camera system including Seninf, ISP pipeline.
>  - A media entity that provides one source pad in common.
>  - Used in camera features on ChromeOS application.
> 
> Also this driver supports following features:
>  - manual exposure and analog gain control support
>  - vertical blanking control support
>  - test pattern support
>  - media controller support
>  - runtime PM support
>  - support resolution: 3264x2448 at 30fps, 1920x1080 at 60fps
> 
> Previous versions of this patch-set can be found here:
>  v1: https://lore.kernel.org/linux-media/20231123115104.32094-1-zhi.mao at mediatek.com/
> 
> Changes of v2 mainly address comments from Krzysztof/Rob Herring&Conor Dooley.
> Compared to v1:
>   - Fix some review comments  

What exactly fixed? This cannot be that vague!



Best regards,
Krzysztof



From danishanwar at ti.com  Thu Dec  7 00:19:14 2023
From: danishanwar at ti.com (MD Danish Anwar)
Date: Thu, 7 Dec 2023 13:49:14 +0530
Subject: [PATCH 0/3] Add AM64x ICSSG Ethernet support
Message-ID: <20231207081917.340167-1-danishanwar@ti.com>

Hi All,

This series adds support for ICSSG ethernet on AM64x. 
This series is based on the latest next-20231207 linux-next.

AM64x EVM has three ethernet ports. One is dedicated to CPSW and one is
dedicated to ICSSG1. The remaining port is muxed between CPSW and ICSSG1
ICSSG1 ports. The ICSSG1 node is added in the k3-am642-evm.dts. By default
the muxed port is used by CPSW so 2nd ICSSG1 port is disabled in the
k3-am642-evm.dts. But overlay k3-am642-evm-icssg1-dualemac.dtso can be
applied to use muxed port as ICSSG1.

Thanks and Regards,
MD Danish Anwar

MD Danish Anwar (2):
  arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet support
  arm64: dts: ti: k3-am642-evm: add overlay for icssg1 2nd port

Suman Anna (1):
  arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes

 arch/arm64/boot/dts/ti/Makefile               |   2 +
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi      |  24 ++++
 .../dts/ti/k3-am642-evm-icssg1-dualemac.dtso  |  80 +++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-evm.dts       | 107 +++++++++++++++++-
 4 files changed, 212 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso

base-commit: 8e00ce02066e8f6f1ad5eab49a2ede7bf7a5ef64
-- 
2.34.1



From danishanwar at ti.com  Thu Dec  7 00:19:15 2023
From: danishanwar at ti.com (MD Danish Anwar)
Date: Thu, 7 Dec 2023 13:49:15 +0530
Subject: [PATCH 1/3] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes
In-Reply-To: <20231207081917.340167-1-danishanwar@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
Message-ID: <20231207081917.340167-2-danishanwar@ti.com>

From: Suman Anna <s-anna at ti.com>

The ICSSG IP on AM64x SoCs have two Industrial Ethernet Peripherals (IEPs)
to manage/generate Industrial Ethernet functions such as time stamping.
Each IEP sub-module is sourced from an internal clock mux that can be
derived from either of the IP instance's ICSSG_IEP_GCLK or from another
internal ICSSG CORE_CLK mux. Add both the IEP nodes for both the ICSSG
instances. The IEP clock is currently configured to be derived
indirectly from the ICSSG_ICLK running at 250 MHz.

Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
Signed-off-by: Suman Anna <s-anna at ti.com>
Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index c7be378492e2..055f6e3657c2 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -1234,6 +1234,18 @@ icssg0_iepclk_mux: iepclk-mux at 30 {
 			};
 		};
 
+		icssg0_iep0: iep at 2e000 {
+			compatible = "ti,am654-icss-iep";
+			reg = <0x2e000 0x1000>;
+			clocks = <&icssg0_iepclk_mux>;
+		};
+
+		icssg0_iep1: iep at 2f000 {
+			compatible = "ti,am654-icss-iep";
+			reg = <0x2f000 0x1000>;
+			clocks = <&icssg0_iepclk_mux>;
+		};
+
 		icssg0_mii_rt: mii-rt at 32000 {
 			compatible = "ti,pruss-mii", "syscon";
 			reg = <0x32000 0x100>;
@@ -1375,6 +1387,18 @@ icssg1_iepclk_mux: iepclk-mux at 30 {
 			};
 		};
 
+		icssg1_iep0: iep at 2e000 {
+			compatible = "ti,am654-icss-iep";
+			reg = <0x2e000 0x1000>;
+			clocks = <&icssg1_iepclk_mux>;
+		};
+
+		icssg1_iep1: iep at 2f000 {
+			compatible = "ti,am654-icss-iep";
+			reg = <0x2f000 0x1000>;
+			clocks = <&icssg1_iepclk_mux>;
+		};
+
 		icssg1_mii_rt: mii-rt at 32000 {
 			compatible = "ti,pruss-mii", "syscon";
 			reg = <0x32000 0x100>;
-- 
2.34.1



From Jianjun.Wang at mediatek.com  Thu Dec  7 00:18:56 2023
From: Jianjun.Wang at mediatek.com (=?utf-8?B?Smlhbmp1biBXYW5nICjnjovlu7rlhpsp?=)
Date: Thu, 7 Dec 2023 08:18:56 +0000
Subject: [PATCH 1/2] PCI: mediatek: Allocate MSI address with
 dmam_alloc_coherent
In-Reply-To: <20231206170747.GA718062@bhelgaas>
References: <20231206170747.GA718062@bhelgaas>
Message-ID: <5d289553a49274c92ce12eb63735cea2f1bf8bf1.camel@mediatek.com>

Hi Bjorn,

On Wed, 2023-12-06 at 11:07 -0600, Bjorn Helgaas wrote:
>  On Wed, Dec 06, 2023 at 04:37:52PM +0800, Jianjun Wang wrote:
> > Use 'dmam_alloc_coherent' to allocate the MSI address, instead of
> using
> > 'virt_to_phys'.
> 
> s/'dmam_alloc_coherent'/dmam_alloc_coherent()/
> s/'virt_to_phys'/virt_to_phys()/
> 
> In subject also.
> 
> > @@ -732,8 +740,11 @@ static int mtk_pcie_startup_port_v2(struct
> mtk_pcie_port *port)
> >  val &= ~INTX_MASK;
> >  writel(val, port->base + PCIE_INT_MASK);
> >  
> > -if (IS_ENABLED(CONFIG_PCI_MSI))
> > -mtk_pcie_enable_msi(port);
> > +if (IS_ENABLED(CONFIG_PCI_MSI)) {
> > +err = mtk_pcie_enable_msi(port);
> > +if (err)
> > +return err;
> 
> Is failure to enable MSI a fatal issue?  It looks like this will make
> the host controller completely unusable if we can't set up MSI, even
> if downstream PCI devices could use INTx and get along without MSI.

This shouldn't be a fatal issue, we can still use INTx, I'll fix them
in the next version, thanks for your review.

Thanks.
> 
> Bjorn

From danishanwar at ti.com  Thu Dec  7 00:19:17 2023
From: danishanwar at ti.com (MD Danish Anwar)
Date: Thu, 7 Dec 2023 13:49:17 +0530
Subject: [PATCH 3/3] arm64: dts: ti: k3-am642-evm: add overlay for icssg1 2nd port
In-Reply-To: <20231207081917.340167-1-danishanwar@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
Message-ID: <20231207081917.340167-4-danishanwar@ti.com>

The am642-evm doesn't allow to enable 2 x CPSW3g ports and 2 x ICSSG1 ports
all together, so base k3-am642-evm.dts enables by default 2 x CPSW3g ports
and 1 x ICSSG1 ports, but it also possible to support 1 x CPSW3g ports and
2 x ICSSG1 ports configuration.

This patch adds overlay to support 1 x CPSW3g ports and 2 x ICSSG1 ports
configuration:
- disable 2nd CPSW3g port
- update CPSW3g pinmuxes to not use RGMII2
- disable mdio-mux-1 and define mdio-mux-2 to route ICSSG1 MDIO to the
  shared DP83869 PHY
- add and enable ICSSG1 RGMII2 pinmuxes
- enable ICSSG1 MII1 port

Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
---
 arch/arm64/boot/dts/ti/Makefile               |  2 +
 .../dts/ti/k3-am642-evm-icssg1-dualemac.dtso  | 80 +++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  2 +-
 3 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 5ef49b02c71f..99a4dce47f02 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -35,12 +35,14 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62x-sk-csi2-imx219.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-am62x-sk-hdmi-audio.dtbo
 
 # Boards with AM64x SoC
+k3-am642-evm-icssg1-dtbs := k3-am642-evm.dtb k3-am642-evm-icssg1-dualemac.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-icssg1.dtb
 
 # Boards with AM65x SoC
 k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb k3-am654-base-board-rocktech-rk101-panel.dtbo
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
new file mode 100644
index 000000000000..6f33290c1ad6
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * DT overlay for enabling 2nd ICSSG1 port on AM642 EVM
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "k3-pinctrl.h"
+
+&{/} {
+	aliases {
+		ethernet1 = "/icssg1-eth/ethernet-ports/port at 0";
+		ethernet2 = "/icssg1-eth/ethernet-ports/port at 1";
+	};
+
+	mdio-mux-2 {
+		compatible = "mdio-mux-multiplexer";
+		mux-controls = <&mdio_mux>;
+		mdio-parent-bus = <&icssg1_mdio>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		mdio at 0 {
+			reg = <0x0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			icssg1_phy2: ethernet-phy at 3 {
+				reg = <3>;
+				tx-internal-delay-ps = <250>;
+				rx-internal-delay-ps = <2000>;
+			};
+		};
+	};
+};
+
+&main_pmx0 {
+	icssg1_rgmii2_pins_default: icssg1-rgmii2-default-pins {
+		pinctrl-single,pins = <
+			AM64X_IOPAD(0x0108, PIN_INPUT, 2) /* (W11) PRG1_PRU1_GPO0.RGMII2_RD0 */
+			AM64X_IOPAD(0x010c, PIN_INPUT, 2) /* (V11) PRG1_PRU1_GPO1.RGMII2_RD1 */
+			AM64X_IOPAD(0x0110, PIN_INPUT, 2) /* (AA12) PRG1_PRU1_GPO2.RGMII2_RD2 */
+			AM64X_IOPAD(0x0114, PIN_INPUT, 2) /* (Y12) PRG1_PRU1_GPO3.RGMII2_RD3 */
+			AM64X_IOPAD(0x0120, PIN_INPUT, 2) /* (U11) PRG1_PRU1_GPO6.RGMII2_RXC */
+			AM64X_IOPAD(0x0118, PIN_INPUT, 2) /* (W12) PRG1_PRU1_GPO4.RGMII2_RX_CTL */
+			AM64X_IOPAD(0x0134, PIN_OUTPUT, 2) /* (AA10) PRG1_PRU1_GPO11.RGMII2_TD0 */
+			AM64X_IOPAD(0x0138, PIN_OUTPUT, 2) /* (V10) PRG1_PRU1_GPO12.RGMII2_TD1 */
+			AM64X_IOPAD(0x013c, PIN_OUTPUT, 2) /* (U10) PRG1_PRU1_GPO13.RGMII2_TD2 */
+			AM64X_IOPAD(0x0140, PIN_OUTPUT, 2) /* (AA11) PRG1_PRU1_GPO14.RGMII2_TD3 */
+			AM64X_IOPAD(0x0148, PIN_OUTPUT, 2) /* (Y10) PRG1_PRU1_GPO16.RGMII2_TXC */
+			AM64X_IOPAD(0x0144, PIN_OUTPUT, 2) /* (Y11) PRG1_PRU1_GPO15.RGMII2_TX_CTL */
+		>;
+	};
+};
+
+&cpsw3g {
+	pinctrl-0 = <&rgmii1_pins_default>;
+};
+
+&cpsw_port2 {
+	status = "disabled";
+};
+
+&mdio_mux_1 {
+	status = "disabled";
+};
+
+&icssg1_eth {
+	pinctrl-0 = <&icssg1_rgmii1_pins_default &icssg1_rgmii2_pins_default>;
+};
+
+&icssg1_emac1 {
+	status = "okay";
+	phy-handle = <&icssg1_phy2>;
+	phy-mode = "rgmii-id";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 04d1c0602d31..90867090e725 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -203,7 +203,7 @@ mdio_mux: mux-controller {
 		mux-gpios = <&exp1 12 GPIO_ACTIVE_HIGH>;
 	};
 
-	mdio-mux-1 {
+	mdio_mux_1: mdio-mux-1 {
 		compatible = "mdio-mux-multiplexer";
 		mux-controls = <&mdio_mux>;
 		mdio-parent-bus = <&cpsw3g_mdio>;
-- 
2.34.1



From danishanwar at ti.com  Thu Dec  7 00:19:16 2023
From: danishanwar at ti.com (MD Danish Anwar)
Date: Thu, 7 Dec 2023 13:49:16 +0530
Subject: [PATCH 2/3] arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet support
In-Reply-To: <20231207081917.340167-1-danishanwar@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
Message-ID: <20231207081917.340167-3-danishanwar@ti.com>

ICSSG1 provides dual Gigabit Ethernet support with proper FW loaded.

The ICSSG1 MII0 (RGMII1) has DP83869 PHY attached to it. The ICSSG1 shares
MII1 (RGMII2) PHY DP83869 with CPSW3g and it's assigned by default to
CPSW3g. The MDIO access to MII1 (RGMII2) PHY DP83869 is controlled by MDIO
bus switch and also assigned to CPSW3g. Therefore the ICSSG1 MII1 (RGMII2)
port is kept disable and ICSSG1 is enabled in single MAC mode by
default.

Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 105 ++++++++++++++++++++++++
 1 file changed, 105 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 8c5651d2cf5d..04d1c0602d31 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -34,6 +34,11 @@ aliases {
 		ethernet1 = &cpsw_port2;
 	};
 
+	aliases {
+		ethernet2 = &icssg1_emac0;
+		ethernet3 = &icssg1_emac1;
+	};
+
 	memory at 80000000 {
 		bootph-all;
 		device_type = "memory";
@@ -229,6 +234,70 @@ transceiver2: can-phy1 {
 		max-bitrate = <5000000>;
 		standby-gpios = <&exp1 9 GPIO_ACTIVE_HIGH>;
 	};
+
+	icssg1_eth: icssg1-eth {
+		compatible = "ti,am642-icssg-prueth";
+		pinctrl-names = "default";
+		pinctrl-0 = <&icssg1_rgmii1_pins_default>;
+
+		sram = <&oc_sram>;
+		ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
+		firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
+				"ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
+				"ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
+				"ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
+				"ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
+				"ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
+
+		ti,pruss-gp-mux-sel = <2>,	/* MII mode */
+				      <2>,
+				      <2>,
+				      <2>,	/* MII mode */
+				      <2>,
+				      <2>;
+
+		ti,mii-g-rt = <&icssg1_mii_g_rt>;
+		ti,mii-rt = <&icssg1_mii_rt>;
+		ti,iep = <&icssg1_iep0>,  <&icssg1_iep1>;
+
+		interrupt-parent = <&icssg1_intc>;
+		interrupts = <24 0 2>, <25 1 3>;
+		interrupt-names = "tx_ts0", "tx_ts1";
+
+		dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
+		       <&main_pktdma 0xc201 15>, /* egress slice 0 */
+		       <&main_pktdma 0xc202 15>, /* egress slice 0 */
+		       <&main_pktdma 0xc203 15>, /* egress slice 0 */
+		       <&main_pktdma 0xc204 15>, /* egress slice 1 */
+		       <&main_pktdma 0xc205 15>, /* egress slice 1 */
+		       <&main_pktdma 0xc206 15>, /* egress slice 1 */
+		       <&main_pktdma 0xc207 15>, /* egress slice 1 */
+		       <&main_pktdma 0x4200 15>, /* ingress slice 0 */
+		       <&main_pktdma 0x4201 15>; /* ingress slice 1 */
+		dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
+			    "tx1-0", "tx1-1", "tx1-2", "tx1-3",
+			    "rx0", "rx1";
+
+		ethernet-ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			icssg1_emac0: port at 0 {
+				reg = <0>;
+				phy-handle = <&icssg1_phy1>;
+				phy-mode = "rgmii-id";
+				ti,syscon-rgmii-delay = <&main_conf 0x4110>;
+				/* Filled in by bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+			};
+			icssg1_emac1: port at 1 {
+				reg = <1>;
+				ti,syscon-rgmii-delay = <&main_conf 0x4114>;
+				/* Filled in by bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				status = "disabled";
+			};
+		};
+	};
 };
 
 &main_pmx0 {
@@ -383,6 +452,30 @@ ddr_vtt_pins_default: ddr-vtt-default-pins {
 			AM64X_IOPAD(0x0030, PIN_OUTPUT_PULLUP, 7) /* (L18) OSPI0_CSN1.GPIO0_12 */
 		>;
 	};
+
+	icssg1_mdio1_pins_default: icssg1-mdio1-default-pins {
+		pinctrl-single,pins = <
+			AM64X_IOPAD(0x015c, PIN_OUTPUT, 0) /* (Y6) PRG1_MDIO0_MDC */
+			AM64X_IOPAD(0x0158, PIN_INPUT, 0) /* (AA6) PRG1_MDIO0_MDIO */
+		>;
+	};
+
+	icssg1_rgmii1_pins_default: icssg1-rgmii1-default-pins{
+		pinctrl-single,pins = <
+			AM64X_IOPAD(0x00b8, PIN_INPUT, 2) /* (Y7) PRG1_PRU0_GPO0.PRG1_RGMII1_RD0 */
+			AM64X_IOPAD(0x00bc, PIN_INPUT, 2) /* (U8) PRG1_PRU0_GPO1.PRG1_RGMII1_RD1 */
+			AM64X_IOPAD(0x00c0, PIN_INPUT, 2) /* (W8) PRG1_PRU0_GPO2.PRG1_RGMII1_RD2 */
+			AM64X_IOPAD(0x00c4, PIN_INPUT, 2) /* (V8) PRG1_PRU0_GPO3.PRG1_RGMII1_RD3 */
+			AM64X_IOPAD(0x00d0, PIN_INPUT, 2) /* (AA7) PRG1_PRU0_GPO6.PRG1_RGMII1_RXC */
+			AM64X_IOPAD(0x00c8, PIN_INPUT, 2) /* (Y8) PRG1_PRU0_GPO4.PRG1_RGMII1_RX_CTL */
+			AM64X_IOPAD(0x00e4, PIN_INPUT, 2) /* (AA8) PRG1_PRU0_GPO11.PRG1_RGMII1_TD0 */
+			AM64X_IOPAD(0x00e8, PIN_INPUT, 2) /* (U9) PRG1_PRU0_GPO12.PRG1_RGMII1_TD1 */
+			AM64X_IOPAD(0x00ec, PIN_INPUT, 2) /* (W9) PRG1_PRU0_GPO13.PRG1_RGMII1_TD2 */
+			AM64X_IOPAD(0x00f0, PIN_INPUT, 2) /* (AA9) PRG1_PRU0_GPO14.PRG1_RGMII1_TD3 */
+			AM64X_IOPAD(0x00f8, PIN_INPUT, 2) /* (V9) PRG1_PRU0_GPO16.PRG1_RGMII1_TXC */
+			AM64X_IOPAD(0x00f4, PIN_INPUT, 2) /* (Y9) PRG1_PRU0_GPO15.PRG1_RGMII1_TX_CTL */
+		>;
+	};
 };
 
 &main_uart0 {
@@ -731,3 +824,15 @@ &main_mcan1 {
 	pinctrl-0 = <&main_mcan1_pins_default>;
 	phys = <&transceiver2>;
 };
+
+&icssg1_mdio {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&icssg1_mdio1_pins_default>;
+
+	icssg1_phy1: ethernet-phy at 0 {
+		reg = <0xf>;
+		tx-internal-delay-ps = <250>;
+		rx-internal-delay-ps = <2000>;
+	};
+};
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Thu Dec  7 00:21:39 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 09:21:39 +0100
Subject: [PATCH 2/2] media: dt-bindings: media: i2c: Document GC08A3
 bindings
In-Reply-To: <20231207052016.25954-3-zhi.mao@mediatek.com>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
 <20231207052016.25954-3-zhi.mao@mediatek.com>
Message-ID: <a7a9a204-cfd2-4510-890d-ce3f72d5fcda@linaro.org>

On 07/12/2023 06:20, Zhi Mao wrote:
> Add YAML device tree binding for GC08A3 CMOS image sensor,
> and the relevant MAINTAINERS entries.
> 
> Signed-off-by: Zhi Mao <zhi.mao at mediatek.com>
> ---
>  .../bindings/media/i2c/galaxycore,gc08a3.yaml | 127 ++++++++++++++++++
>  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
>  2 files changed, 129 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
> new file mode 100644
> index 000000000000..1802ff1c8a12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/galaxycore,gc08a3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GalaxyCore gc08a3 1/4" 8M Pixel MIPI CSI-2 sensor
> +
> +maintainers:
> +  - Zhi Mao <zhi.mao at mediatek.com>
> +
> +description:
> +  The gc08a3 is a raw image sensor with an MIPI CSI-2 image data
> +  interface and CCI (I2C compatible) control bus. The output format
> +  is raw Bayer.
> +
> +properties:
> +  compatible:
> +    const: galaxycore,gc08a3
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  clock-names:
> +    description:
> +      External clock for the sensor.
> +    maxItems: 1

Items must be defined or just drop the property. How did it even appear?
Who asked for this? Your changelog is so vague that anything can happen
with this code and you will claim "it was review fix". No, you must
explain the changes.

Go back to previous review and implement all the changes requested.

> +
> +  clock-frequency:
> +    description:
> +      Frequency of the clock in Hz.

Drop property


> +
> +  dovdd-supply: true
> +
> +  avdd-supply: true
> +
> +  dvdd-supply: true
> +
> +  enable-gpios:
> +    description: Reference to the GPIO connected to the RESETB pin. Active low.

That's not enable, but reset-gpios.

> +    maxItems: 1
> +
> +  port:
> +    $ref: /schemas/graph.yaml#/$defs/port-base
> +    additionalProperties: false
> +    description:
> +      Output port node, single endpoint describing the CSI-2 transmitter.
> +
> +    properties:
> +      endpoint:
> +        $ref: /schemas/media/video-interfaces.yaml#
> +        unevaluatedProperties: false
> +
> +        properties:
> +          data-lanes:
> +            oneOf:
> +              - items:
> +                  - const: 1
> +                  - const: 2
> +                  - const: 3
> +                  - const: 4
> +              - items:
> +                  - const: 1
> +                  - const: 2
> +
> +          link-frequencies: true
> +
> +        required:
> +          - data-lanes
> +          - link-frequencies
> +
> +    required:
> +      - endpoint
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - clock-frequency
> +  - dovdd-supply
> +  - avdd-supply
> +  - dvdd-supply
> +  - enable-gpios
> +  - port
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        sensor0 at 31 {
> +            status = "okay";

Drop. Do you see it anywhere in the bindings examples?

> +            compatible = "galaxycore,gc08a3";
> +            reg = <0x31>;
> +
> +            clocks = <&gc08a3_clk>;
> +            clock-names = "xvclk";

Drop

> +            clock-frequency = <24000000>;

Drop

> +
> +            enable-gpios = <&pio 19 GPIO_ACTIVE_HIGH>;
> +
> +            avdd-supply = <&gc08a3_avdd>;
> +            dovdd-supply = <&ogc08a3_dovdd>;
> +            dvdd-supply = <&gc08a3_dvdd>;
> +
> +            port {
> +                sensor0_out_2: endpoint {
> +                    data-lanes = <1 2 3 4>;
> +                    link-frequencies = /bits/ 64 <336000000 207000000>;
> +                    remote-endpoint = <&seninf_csi_port_0_in_2>;
> +                };
> +            };
> +        };
> +

Drop stray blank line.

> +    };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index b752f8902367..1a16a94fb202 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -502,6 +502,8 @@ patternProperties:
>      description: Fujitsu Ltd.
>    "^fxtec,.*":
>      description: FX Technology Ltd.
> +  "^galaxycore,.*":
> +    description: GalaxyCore Inc.

That's a duplicated patch... how many of this people are going to send?

Drop and rebase on top of previous work of people.


Best regards,
Krzysztof



From jensenhuang at friendlyarm.com  Thu Dec  7 00:21:59 2023
From: jensenhuang at friendlyarm.com (Jensen Huang)
Date: Thu,  7 Dec 2023 16:21:59 +0800
Subject: [PATCH v2] i2c: rk3x: fix potential spinlock recursion on poll
Message-ID: <20231207082200.16388-1-jensenhuang@friendlyarm.com>

Possible deadlock scenario (on reboot):
rk3x_i2c_xfer_common(polling)
    -> rk3x_i2c_wait_xfer_poll()
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock);
            ...
        <rk3x i2c interrupt>
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock); (deadlock here)

Store the IRQ number and disable/enable it around the polling transfer.
This patch has been tested on NanoPC-T4.

Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
---
Changes in v2:
 - Add description for member 'irq' to fix build warning

 drivers/i2c/busses/i2c-rk3x.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index a044ca0c35a1..4362db7c5789 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -178,6 +178,7 @@ struct rk3x_i2c_soc_data {
  * @clk: function clk for rk3399 or function & Bus clks for others
  * @pclk: Bus clk for rk3399
  * @clk_rate_nb: i2c clk rate change notify
+ * @irq: irq number
  * @t: I2C known timing information
  * @lock: spinlock for the i2c bus
  * @wait: the waitqueue to wait for i2c transfer
@@ -200,6 +201,7 @@ struct rk3x_i2c {
 	struct clk *clk;
 	struct clk *pclk;
 	struct notifier_block clk_rate_nb;
+	int irq;
 
 	/* Settings */
 	struct i2c_timings t;
@@ -1087,13 +1089,18 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
 
 		spin_unlock_irqrestore(&i2c->lock, flags);
 
-		rk3x_i2c_start(i2c);
-
 		if (!polling) {
+			rk3x_i2c_start(i2c);
+
 			timeout = wait_event_timeout(i2c->wait, !i2c->busy,
 						     msecs_to_jiffies(WAIT_TIMEOUT));
 		} else {
+			disable_irq(i2c->irq);
+			rk3x_i2c_start(i2c);
+
 			timeout = rk3x_i2c_wait_xfer_poll(i2c);
+
+			enable_irq(i2c->irq);
 		}
 
 		spin_lock_irqsave(&i2c->lock, flags);
@@ -1310,6 +1317,8 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	i2c->irq = irq;
+
 	platform_set_drvdata(pdev, i2c);
 
 	if (i2c->soc_data->calc_timings == rk3x_i2c_v0_calc_timings) {
-- 
2.42.0



From neil.armstrong at linaro.org  Thu Dec  7 00:22:33 2023
From: neil.armstrong at linaro.org (neil.armstrong at linaro.org)
Date: Thu, 7 Dec 2023 09:22:33 +0100
Subject: [PATCH v8 00/10] Enable HS-G5 support on SM8550
In-Reply-To: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
References: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
Message-ID: <e851f59a-a8fe-42fa-a3e3-65fc5b8f3269@linaro.org>

Hi Can,

On 02/12/2023 13:36, Can Guo wrote:
> This series enables HS-G5 support on SM8550.
> 
> This series is rebased on below changes from Mani -
> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-1-manivannan.sadhasivam at linaro.org/
> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-2-manivannan.sadhasivam at linaro.org/
> 
> This series is tested on below HW combinations -
> SM8550 MTP + UFS4.0
> SM8550 QRD + UFS3.1
> SM8450 MTP + UFS3.1 (for regression test)
> SM8350 MTP + UFS3.1 (for regression test)
> 
> Note that during reboot test on above platforms, I occasinally hit PA (PHY)
> error during the 2nd init, this is not related with this series. A fix for
> this is mentioned in below patchwork -
> 
> https://patchwork.kernel.org/project/linux-scsi/patch/1698145815-17396-1-git-send-email-quic_ziqichen at quicinc.com/
> 
> Also note that on platforms, which have two sets of UFS PHY settings are
> provided (say G4 and no-G4, G5 and no-G5). The two sets of PHY settings are
> basically programming different values to different registers, mixing the
> two sets and/or overwriting one set with another set is definitely not
> blessed by UFS PHY designers. For SM8550, this series will make sure we
> honor the rule. However, for old targets Mani and I will fix them in
> another series in future.

You dropped my tested-by tags, but I did a new test with v8 and:

Tested-by: Neil Armstrong <neil.armstrong at linaro.org> # on SM8550-QRD
Tested-by: Neil Armstrong <neil.armstrong at linaro.org> # on SM8650-QRD

Thanks,
Neil

> 
> v7 -> v8:
> In "scsi: ufs: ufs-qcom: Add support for UFS device version detection", fixed a BUG introduced from v6 -> v7. The spare register is added since HW ver 5, although reading the spare register on HW ver 4 is just getting 0x0, to be on the safe side, we are exluding HW ver 4.
> 
> v6 -> v7:
> 1. Rebased on linux-next, based SM8650 PHY settings are merged there, no changes to patches for UFS driver
> 2. Addressed comments from Mani
> 
> v5 -> v6:
> 1. Rebased on scsi-queue-6.8
> 2. Addressed comments from Dmitry and Mani in patches to phy-qcom-qmp-ufs.c
> 
> v4 -> v5:
> Removed two useless debug prints in patch #9
> 
> v3 -> v4:
> Used .tbls_hs_overlay array instead of adding more tables with different names like .tbls_hs_g5
> 
> v2 -> v3:
> 1. Addressed comments from Andrew, Mani and Bart in patch #1
> 2. Added patch #2 as per request from Andrew and Mani
> 3. Added patch #4 to fix a common issue on old targets, it is not necessary
>     for this series, but put in this series only because it would be easier
>     to maintain and no need to rebase
> 4. Addressed comments from Dmitry and Mani in patches to phy-qcom-qmp-ufs.c
> 
> v1 -> v2:
> 1. Removed 2 changes which were exposing power info in sysfs
> 2. Removed 1 change which was moving data structs to phy-qcom-qmp-ufs.h
> 3. Added one new change (the 1st one) to clean up usage of ufs_dev_params based on comments from Mani
> 4. Adjusted the logic of UFS device version detection according to comments from Mani:
> 	4.1 For HW version < 0x5, go through dual init
>   	4.2 For HW version >= 0x5
> 		a. If UFS device version is populated, one init is required
> 		b. If UFS device version is not populated, go through dual init
> 
> Bao D. Nguyen (1):
>    scsi: ufs: ufs-qcom: Add support for UFS device version detection
> 
> Can Guo (9):
>    scsi: ufs: host: Rename structure ufs_dev_params to ufs_host_params
>    scsi: ufs: ufs-qcom: No need to set hs_rate after
>      ufshcd_init_host_param()
>    scsi: ufs: ufs-qcom: Setup host power mode during init
>    scsi: ufs: ufs-qcom: Allow the first init start with the maximum
>      supported gear
>    scsi: ufs: ufs-qcom: Limit HS-G5 Rate-A to hosts with HW version 5
>    scsi: ufs: ufs-qcom: Set initial PHY gear to max HS gear for HW ver 4
>      and newer
>    scsi: ufs: ufs-qcom: Check return value of phy_set_mode_ext()
>    phy: qualcomm: phy-qcom-qmp-ufs: Rectify SM8550 UFS HS-G4 PHY Settings
>    phy: qualcomm: phy-qcom-qmp-ufs: Add High Speed Gear 5 support for
>      SM8550
> 
>   drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h     |   2 +
>   drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h |   2 +
>   .../qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h    |   9 +
>   drivers/phy/qualcomm/phy-qcom-qmp-ufs.c            | 191 ++++++++++++++++++---
>   drivers/ufs/host/ufs-exynos.c                      |   7 +-
>   drivers/ufs/host/ufs-hisi.c                        |  11 +-
>   drivers/ufs/host/ufs-mediatek.c                    |  12 +-
>   drivers/ufs/host/ufs-qcom.c                        |  97 ++++++++---
>   drivers/ufs/host/ufs-qcom.h                        |   7 +-
>   drivers/ufs/host/ufshcd-pltfrm.c                   |  69 ++++----
>   drivers/ufs/host/ufshcd-pltfrm.h                   |  10 +-
>   11 files changed, 309 insertions(+), 108 deletions(-)
> 



From quic_cang at quicinc.com  Thu Dec  7 00:26:12 2023
From: quic_cang at quicinc.com (Can Guo)
Date: Thu, 7 Dec 2023 16:26:12 +0800
Subject: [PATCH v8 00/10] Enable HS-G5 support on SM8550
In-Reply-To: <e851f59a-a8fe-42fa-a3e3-65fc5b8f3269@linaro.org>
References: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
 <e851f59a-a8fe-42fa-a3e3-65fc5b8f3269@linaro.org>
Message-ID: <cfd282bf-4e19-471f-9de2-18e286bce8bc@quicinc.com>

Hi Neil,

On 12/7/2023 4:22 PM, neil.armstrong at linaro.org wrote:
> Hi Can,
> 
> On 02/12/2023 13:36, Can Guo wrote:
>> This series enables HS-G5 support on SM8550.
>>
>> This series is rebased on below changes from Mani -
>> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-1-manivannan.sadhasivam at linaro.org/
>> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-2-manivannan.sadhasivam at linaro.org/
>>
>> This series is tested on below HW combinations -
>> SM8550 MTP + UFS4.0
>> SM8550 QRD + UFS3.1
>> SM8450 MTP + UFS3.1 (for regression test)
>> SM8350 MTP + UFS3.1 (for regression test)
>>
>> Note that during reboot test on above platforms, I occasinally hit PA 
>> (PHY)
>> error during the 2nd init, this is not related with this series. A fix 
>> for
>> this is mentioned in below patchwork -
>>
>> https://patchwork.kernel.org/project/linux-scsi/patch/1698145815-17396-1-git-send-email-quic_ziqichen at quicinc.com/
>>
>> Also note that on platforms, which have two sets of UFS PHY settings are
>> provided (say G4 and no-G4, G5 and no-G5). The two sets of PHY 
>> settings are
>> basically programming different values to different registers, mixing the
>> two sets and/or overwriting one set with another set is definitely not
>> blessed by UFS PHY designers. For SM8550, this series will make sure we
>> honor the rule. However, for old targets Mani and I will fix them in
>> another series in future.
> 
> You dropped my tested-by tags, but I did a new test with v8 and:
> 
> Tested-by: Neil Armstrong <neil.armstrong at linaro.org> # on SM8550-QRD
> Tested-by: Neil Armstrong <neil.armstrong at linaro.org> # on SM8650-QRD
> 

Thank you so much for testing this series.

I am sorry that I dropped the tested-by tags, since I slightly updated 
the last patch in this series, so I thought I should not apply the 
Tested-by tags from you.

Thanks,
Can Guo.

> Thanks,
> Neil
> 
>>
>> v7 -> v8:
>> In "scsi: ufs: ufs-qcom: Add support for UFS device version 
>> detection", fixed a BUG introduced from v6 -> v7. The spare register 
>> is added since HW ver 5, although reading the spare register on HW ver 
>> 4 is just getting 0x0, to be on the safe side, we are exluding HW ver 4.
>>
>> v6 -> v7:
>> 1. Rebased on linux-next, based SM8650 PHY settings are merged there, 
>> no changes to patches for UFS driver
>> 2. Addressed comments from Mani
>>
>> v5 -> v6:
>> 1. Rebased on scsi-queue-6.8
>> 2. Addressed comments from Dmitry and Mani in patches to 
>> phy-qcom-qmp-ufs.c
>>
>> v4 -> v5:
>> Removed two useless debug prints in patch #9
>>
>> v3 -> v4:
>> Used .tbls_hs_overlay array instead of adding more tables with 
>> different names like .tbls_hs_g5
>>
>> v2 -> v3:
>> 1. Addressed comments from Andrew, Mani and Bart in patch #1
>> 2. Added patch #2 as per request from Andrew and Mani
>> 3. Added patch #4 to fix a common issue on old targets, it is not 
>> necessary
>> ??? for this series, but put in this series only because it would be 
>> easier
>> ??? to maintain and no need to rebase
>> 4. Addressed comments from Dmitry and Mani in patches to 
>> phy-qcom-qmp-ufs.c
>>
>> v1 -> v2:
>> 1. Removed 2 changes which were exposing power info in sysfs
>> 2. Removed 1 change which was moving data structs to phy-qcom-qmp-ufs.h
>> 3. Added one new change (the 1st one) to clean up usage of 
>> ufs_dev_params based on comments from Mani
>> 4. Adjusted the logic of UFS device version detection according to 
>> comments from Mani:
>> ????4.1 For HW version < 0x5, go through dual init
>> ????? 4.2 For HW version >= 0x5
>> ??????? a. If UFS device version is populated, one init is required
>> ??????? b. If UFS device version is not populated, go through dual init
>>
>> Bao D. Nguyen (1):
>> ?? scsi: ufs: ufs-qcom: Add support for UFS device version detection
>>
>> Can Guo (9):
>> ?? scsi: ufs: host: Rename structure ufs_dev_params to ufs_host_params
>> ?? scsi: ufs: ufs-qcom: No need to set hs_rate after
>> ???? ufshcd_init_host_param()
>> ?? scsi: ufs: ufs-qcom: Setup host power mode during init
>> ?? scsi: ufs: ufs-qcom: Allow the first init start with the maximum
>> ???? supported gear
>> ?? scsi: ufs: ufs-qcom: Limit HS-G5 Rate-A to hosts with HW version 5
>> ?? scsi: ufs: ufs-qcom: Set initial PHY gear to max HS gear for HW ver 4
>> ???? and newer
>> ?? scsi: ufs: ufs-qcom: Check return value of phy_set_mode_ext()
>> ?? phy: qualcomm: phy-qcom-qmp-ufs: Rectify SM8550 UFS HS-G4 PHY Settings
>> ?? phy: qualcomm: phy-qcom-qmp-ufs: Add High Speed Gear 5 support for
>> ???? SM8550
>>
>> ? drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h???? |?? 2 +
>> ? drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h |?? 2 +
>> ? .../qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h??? |?? 9 +
>> ? drivers/phy/qualcomm/phy-qcom-qmp-ufs.c??????????? | 191 
>> ++++++++++++++++++---
>> ? drivers/ufs/host/ufs-exynos.c????????????????????? |?? 7 +-
>> ? drivers/ufs/host/ufs-hisi.c??????????????????????? |? 11 +-
>> ? drivers/ufs/host/ufs-mediatek.c??????????????????? |? 12 +-
>> ? drivers/ufs/host/ufs-qcom.c??????????????????????? |? 97 ++++++++---
>> ? drivers/ufs/host/ufs-qcom.h??????????????????????? |?? 7 +-
>> ? drivers/ufs/host/ufshcd-pltfrm.c?????????????????? |? 69 ++++----
>> ? drivers/ufs/host/ufshcd-pltfrm.h?????????????????? |? 10 +-
>> ? 11 files changed, 309 insertions(+), 108 deletions(-)
>>
> 


From krzysztof.kozlowski at linaro.org  Thu Dec  7 00:30:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 09:30:53 +0100
Subject: [PATCH 8/9] dt-bindings: imx6q-pcie: Add imx95 pcie compatible
 string
In-Reply-To: <20231206155903.566194-9-Frank.Li@nxp.com>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
 <20231206155903.566194-9-Frank.Li@nxp.com>
Message-ID: <09321ab0-30a0-4700-bf2d-9a3286412c44@linaro.org>

On 06/12/2023 16:59, Frank Li wrote:
> From: Richard Zhu <hongxing.zhu at nxp.com>
> 
> Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
> 

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec  7 00:31:56 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 09:31:56 +0100
Subject: [PATCH 1/3] dt-bindings: vendor-prefixes: add dimonoff
In-Reply-To: <20231206160303.33185-2-hugo@hugovil.com>
References: <20231206160303.33185-1-hugo@hugovil.com>
 <20231206160303.33185-2-hugo@hugovil.com>
Message-ID: <127e9801-2ce3-45d6-b6a5-238faa97f57a@linaro.org>

On 06/12/2023 17:03, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> 
> Add vendor prefix for Dimonoff, which provides
> IoT smart solutions and custom engineering services.
> 
> Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec  7 00:32:38 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 09:32:38 +0100
Subject: [PATCH 2/3] dt-bindings: arm: fsl: add Dimonoff gateway EVK board
In-Reply-To: <20231206160303.33185-3-hugo@hugovil.com>
References: <20231206160303.33185-1-hugo@hugovil.com>
 <20231206160303.33185-3-hugo@hugovil.com>
Message-ID: <6035c4cc-afe1-456d-a4d0-16992da09a2e@linaro.org>

On 06/12/2023 17:03, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> 
> Add DT compatible string for Dimonoff gateway EVK board based on a
> Variscite VAR-SOM-NANO with a NXP MX8MN nano CPU.
> 
> Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> ---
>  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index cd87d1afe7b7..e445d65d6f17 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -1025,6 +1025,7 @@ properties:
>        - description: Variscite VAR-SOM-MX8MN based boards
>          items:
>            - enum:
> +              - dimonoff,dimonoff-gateway-evk # i.MX8MN Dimonoff Gateway EVK Board

Company name appears twice, which is not really helpful. What's the true
name? Gateway EVK? Then keep only this.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec  7 00:33:38 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 09:33:38 +0100
Subject: [PATCH 3/3] arm64: dts: freescale: introduce dimonoff-gateway-evk
 board
In-Reply-To: <20231206160303.33185-4-hugo@hugovil.com>
References: <20231206160303.33185-1-hugo@hugovil.com>
 <20231206160303.33185-4-hugo@hugovil.com>
Message-ID: <50dc382a-4829-4a14-8c52-9aa1f073002f@linaro.org>

On 06/12/2023 17:03, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> 
> The Dimonoff gateway EVK board is based on a Variscite
> VAR-SOM-NANO, with a NXP MX8MN nano CPU and also based on a Symphony
> mx8mn EVK.
> 
> Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> ---
>  arch/arm64/boot/dts/freescale/Makefile        |   1 +
>  .../freescale/imx8mn-dimonoff-gateway-evk.dts | 159 ++++++++++++++++++
>  2 files changed, 160 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts
> 
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index d22e4f4f886d..1f29215ea9bb 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -97,6 +97,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-bsh-smm-s2.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-bsh-smm-s2pro.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mn-dimonoff-gateway-evk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr3l-evk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts
> new file mode 100644
> index 000000000000..c4572be437bd
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts
> @@ -0,0 +1,159 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2022 DimOnOff
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/usb/pd.h>
> +#include "imx8mn-var-som-symphony.dts"
> +
> +/ {
> +	model = "DimOnOff Gateway EVK board";
> +	compatible = "dimonoff,dimonoff-gateway-evk", "variscite,var-som-mx8mn", "fsl,imx8mn";

Please wrap at 80, like Coding Style asks. Checkpatch is not coding style.

With wrapping and alignment:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From dsimic at manjaro.org  Thu Dec  7 00:37:03 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Thu, 07 Dec 2023 09:37:03 +0100
Subject: [PATCH v2] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <20231207082200.16388-1-jensenhuang@friendlyarm.com>
References: <20231207082200.16388-1-jensenhuang@friendlyarm.com>
Message-ID: <ebf6cf8ec3b5befd673d295061fa2738@manjaro.org>

On 2023-12-07 09:21, Jensen Huang wrote:
> Possible deadlock scenario (on reboot):
> rk3x_i2c_xfer_common(polling)
>     -> rk3x_i2c_wait_xfer_poll()
>         -> rk3x_i2c_irq(0, i2c);
>             --> spin_lock(&i2c->lock);
>             ...
>         <rk3x i2c interrupt>
>         -> rk3x_i2c_irq(0, i2c);
>             --> spin_lock(&i2c->lock); (deadlock here)
> 
> Store the IRQ number and disable/enable it around the polling transfer.
> This patch has been tested on NanoPC-T4.

In case you haven't already seen the related discussion linked below, 
please have a look.  I also added more people to the list of recipients, 
in an attempt to make everyone aware of the different approaches to 
solving this issue.

https://lore.kernel.org/all/655177f4.050a0220.d85c9.3ba0 at mx.google.com/T/#m6fc9c214452fec6681843e7f455978c35c6f6c8b

> Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
> ---
> Changes in v2:
>  - Add description for member 'irq' to fix build warning
> 
>  drivers/i2c/busses/i2c-rk3x.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-rk3x.c 
> b/drivers/i2c/busses/i2c-rk3x.c
> index a044ca0c35a1..4362db7c5789 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -178,6 +178,7 @@ struct rk3x_i2c_soc_data {
>   * @clk: function clk for rk3399 or function & Bus clks for others
>   * @pclk: Bus clk for rk3399
>   * @clk_rate_nb: i2c clk rate change notify
> + * @irq: irq number
>   * @t: I2C known timing information
>   * @lock: spinlock for the i2c bus
>   * @wait: the waitqueue to wait for i2c transfer
> @@ -200,6 +201,7 @@ struct rk3x_i2c {
>  	struct clk *clk;
>  	struct clk *pclk;
>  	struct notifier_block clk_rate_nb;
> +	int irq;
> 
>  	/* Settings */
>  	struct i2c_timings t;
> @@ -1087,13 +1089,18 @@ static int rk3x_i2c_xfer_common(struct
> i2c_adapter *adap,
> 
>  		spin_unlock_irqrestore(&i2c->lock, flags);
> 
> -		rk3x_i2c_start(i2c);
> -
>  		if (!polling) {
> +			rk3x_i2c_start(i2c);
> +
>  			timeout = wait_event_timeout(i2c->wait, !i2c->busy,
>  						     msecs_to_jiffies(WAIT_TIMEOUT));
>  		} else {
> +			disable_irq(i2c->irq);
> +			rk3x_i2c_start(i2c);
> +
>  			timeout = rk3x_i2c_wait_xfer_poll(i2c);
> +
> +			enable_irq(i2c->irq);
>  		}
> 
>  		spin_lock_irqsave(&i2c->lock, flags);
> @@ -1310,6 +1317,8 @@ static int rk3x_i2c_probe(struct platform_device 
> *pdev)
>  		return ret;
>  	}
> 
> +	i2c->irq = irq;
> +
>  	platform_set_drvdata(pdev, i2c);
> 
>  	if (i2c->soc_data->calc_timings == rk3x_i2c_v0_calc_timings) {


From umang.jain at ideasonboard.com  Thu Dec  7 00:38:35 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Thu,  7 Dec 2023 14:08:35 +0530
Subject: [PATCH v3 0/2] staging: vc04_services: Use %p to log pointer
Message-ID: <20231207083837.153843-1-umang.jain@ideasonboard.com>

%lx is used to print the unmodified pointer address for debugging.
%p will print the hashed pointer address to avoid leaking information
about kernel memory layout to userspace. But when `no_hash_pointers`
is passed as kernel parameter, unmodified pointer address will be
printed.

Hence, drop %lx in favour of %p. For debugging purposes, one can
easily depend on `no_hash_pointers` kernel parameter.

Changes in v3:
- reword commit subject line.

Changes in v2:
- Built/Rebased on top of:
  [PATCH v2 0/5] staging: vc04_services: Drop custom logging

Umang Jain (2):
  staging: vc04_services: vchiq_arm: Use %p to log pointer address
  staging: vc04_services: vchiq_dev: Use %p to log pointer address

 .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c  | 7 +++----
 .../staging/vc04_services/interface/vchiq_arm/vchiq_dev.c  | 2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)


base-commit: 55e23aa95b10731c08ab207a42d868aaff3bd2a5
-- 
2.41.0



From umang.jain at ideasonboard.com  Thu Dec  7 00:38:36 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Thu,  7 Dec 2023 14:08:36 +0530
Subject: [PATCH v3 1/2] staging: vc04_services: vchiq_arm: Use %p to log pointer address
In-Reply-To: <20231207083837.153843-1-umang.jain@ideasonboard.com>
References: <20231207083837.153843-1-umang.jain@ideasonboard.com>
Message-ID: <20231207083837.153843-2-umang.jain@ideasonboard.com>

Solves the following Smatch warnings:
service_callback() warn: argument 7 to %lx specifier is cast from pointer
service_callback() warn: argument 11 to %lx specifier is cast from pointer
service_callback() warn: argument 12 to %lx specifier is cast from pointer
service_callback() warn: argument 13 to %lx specifier is cast from pointer

%p will print the hashed pointer to dynamic debug.
In order to print the unmodified pointer address, one can use the
`no_hash_pointers` via kernel parameters.

Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c  | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 4b4ff469d3a3..1579bd4e5263 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1088,10 +1088,9 @@ service_callback(struct vchiq_instance *instance, enum vchiq_reason reason,
 	rcu_read_unlock();
 
 	dev_dbg(service->state->dev,
-		"arm: service %lx(%d,%p), reason %d, header %lx, instance %lx, bulk_userdata %lx\n",
-		(unsigned long)user_service, service->localport,
-		user_service->userdata, reason, (unsigned long)header,
-		(unsigned long)instance, (unsigned long)bulk_userdata);
+		"arm: service %p(%d,%p), reason %d, header %p, instance %p, bulk_userdata %p\n",
+		user_service, service->localport, user_service->userdata,
+		reason, header, instance, bulk_userdata);
 
 	if (header && user_service->is_vchi) {
 		spin_lock(&msg_queue_spinlock);
-- 
2.41.0



From umang.jain at ideasonboard.com  Thu Dec  7 00:38:37 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Thu,  7 Dec 2023 14:08:37 +0530
Subject: [PATCH v3 2/2] staging: vc04_services: vchiq_dev: Use %p to log pointer address
In-Reply-To: <20231207083837.153843-1-umang.jain@ideasonboard.com>
References: <20231207083837.153843-1-umang.jain@ideasonboard.com>
Message-ID: <20231207083837.153843-3-umang.jain@ideasonboard.com>

Solves the following Smatch warnings:
vchiq_release() warn: argument 7 to %lx specifier is cast from pointer

%p will print the hashed pointer to dynamic debug.
In order to print the unmodified pointer address, one can use the
`no_hash_pointers` via kernel parameters.

Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
index 68c8897c504c..4d9deeeb637a 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
@@ -1201,7 +1201,7 @@ static int vchiq_release(struct inode *inode, struct file *file)
 	int ret = 0;
 	int i;
 
-	dev_dbg(state->dev, "arm: instance=%lx\n", (unsigned long)instance);
+	dev_dbg(state->dev, "arm: instance=%p\n", instance);
 
 	if (!state) {
 		ret = -EPERM;
-- 
2.41.0



From maz at kernel.org  Thu Dec  7 00:39:46 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 07 Dec 2023 08:39:46 +0000
Subject: [PATCH v3 15/21] KVM: arm64: Support FEAT_FPMR for guests
In-Reply-To: <20231205-arm64-2023-dpisa-v3-15-dbcbcd867a7f@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
	<20231205-arm64-2023-dpisa-v3-15-dbcbcd867a7f@kernel.org>
Message-ID: <87cyvi8kz1.wl-maz@kernel.org>

On Tue, 05 Dec 2023 16:48:13 +0000,
Mark Brown <broonie at kernel.org> wrote:
> 
> FEAT_FPMR introduces a new system register FPMR which allows configuration
> of floating point behaviour, currently for FP8 specific features. Allow use
> of this in guests, disabling the trap while guests are running and saving
> and restoring the value along with the rest of the floating point state.
> Since FPMR is stored immediately after the main floating point state we
> share it with the hypervisor by adjusting the size of the shared region.
> 
> Access to FPMR is covered by both a register specific trap HCRX_EL2.EnFPM
> and the overall floating point access trap so we just unconditionally
> enable the FPMR specific trap and rely on the floating point access trap to
> detect guest floating point usage.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  arch/arm64/include/asm/kvm_arm.h        |  2 +-
>  arch/arm64/include/asm/kvm_host.h       |  4 +++-
>  arch/arm64/kvm/emulate-nested.c         |  9 +++++++++
>  arch/arm64/kvm/fpsimd.c                 | 20 +++++++++++++++++---
>  arch/arm64/kvm/hyp/include/hyp/switch.h |  7 ++++++-
>  arch/arm64/kvm/sys_regs.c               | 11 +++++++++++
>  6 files changed, 47 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 9f9239d86900..95f3b44e7c3a 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -103,7 +103,7 @@
>  #define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
>  
>  #define HCRX_GUEST_FLAGS \
> -	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | \
> +	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM | \

We really should start making all of these things conditional. See
below.

>  	 (cpus_have_final_cap(ARM64_HAS_MOPS) ? (HCRX_EL2_MSCEn | HCRX_EL2_MCE2) : 0))
>  #define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM)
>  
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index f8d98985a39c..9885adff06fa 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -391,6 +391,8 @@ enum vcpu_sysreg {
>  	CNTP_CVAL_EL0,
>  	CNTP_CTL_EL0,
>  
> +	FPMR,
> +
>  	/* Memory Tagging Extension registers */
>  	RGSR_EL1,	/* Random Allocation Tag Seed Register */
>  	GCR_EL1,	/* Tag Control Register */
> @@ -517,7 +519,6 @@ struct kvm_vcpu_arch {
>  	enum fp_type fp_type;
>  	unsigned int sve_max_vl;
>  	u64 svcr;
> -	u64 fpmr;

Why do this change here? Why isn't done like that the first place?

>  
>  	/* Stage 2 paging state used by the hardware on next switch */
>  	struct kvm_s2_mmu *hw_mmu;
> @@ -576,6 +577,7 @@ struct kvm_vcpu_arch {
>  	struct kvm_guest_debug_arch external_debug_state;
>  
>  	struct user_fpsimd_state *host_fpsimd_state;	/* hyp VA */
> +	u64 *host_fpmr;					/* hyp VA */
>  	struct task_struct *parent_task;
>  
>  	struct {
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index 06185216a297..802e5cde696f 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -67,6 +67,8 @@ enum cgt_group_id {
>  	CGT_HCR_TTLBIS,
>  	CGT_HCR_TTLBOS,
>  
> +	CGT_HCRX_EnFPM,
> +
>  	CGT_MDCR_TPMCR,
>  	CGT_MDCR_TPM,
>  	CGT_MDCR_TDE,
> @@ -279,6 +281,12 @@ static const struct trap_bits coarse_trap_bits[] = {
>  		.mask		= HCR_TTLBOS,
>  		.behaviour	= BEHAVE_FORWARD_ANY,
>  	},
> +	[CGT_HCRX_EnFPM] = {
> +		.index		= HCRX_EL2,
> +		.value		= HCRX_EL2_EnFPM,
> +		.mask		= HCRX_EL2_EnFPM,
> +		.behaviour	= BEHAVE_FORWARD_ANY,

This looks wrong. HCRX_EL2.EnFPM is an enable bit.

> +	},
>  	[CGT_MDCR_TPMCR] = {
>  		.index		= MDCR_EL2,
>  		.value		= MDCR_EL2_TPMCR,
> @@ -478,6 +486,7 @@ static const struct encoding_to_trap_config encoding_to_cgt[] __initconst = {
>  	SR_TRAP(SYS_AIDR_EL1,		CGT_HCR_TID1),
>  	SR_TRAP(SYS_SMIDR_EL1,		CGT_HCR_TID1),
>  	SR_TRAP(SYS_CTR_EL0,		CGT_HCR_TID2),
> +	SR_TRAP(SYS_FPMR,		CGT_HCRX_EnFPM),
>  	SR_TRAP(SYS_CCSIDR_EL1,		CGT_HCR_TID2_TID4),
>  	SR_TRAP(SYS_CCSIDR2_EL1,	CGT_HCR_TID2_TID4),
>  	SR_TRAP(SYS_CLIDR_EL1,		CGT_HCR_TID2_TID4),
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index e3e611e30e91..dee078625d0d 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -14,6 +14,16 @@
>  #include <asm/kvm_mmu.h>
>  #include <asm/sysreg.h>
>  
> +static void *fpsimd_share_end(struct user_fpsimd_state *fpsimd)
> +{
> +	void *share_end = fpsimd + 1;
> +
> +	if (cpus_have_final_cap(ARM64_HAS_FPMR))
> +		share_end += sizeof(u64);
> +
> +	return share_end;
> +}

This is horrible. Why can't you just have a new structure wrapping
both user_fpsimd_state and fpmr? This is going to break in subtle
ways, just like the SVE/SME stuff.

> +
>  void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
>  {
>  	struct task_struct *p = vcpu->arch.parent_task;
> @@ -23,7 +33,7 @@ void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
>  		return;
>  
>  	fpsimd = &p->thread.uw.fpsimd_state;
> -	kvm_unshare_hyp(fpsimd, fpsimd + 1);
> +	kvm_unshare_hyp(fpsimd, fpsimd_share_end(fpsimd));
>  	put_task_struct(p);
>  }
>  
> @@ -45,11 +55,15 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
>  	kvm_vcpu_unshare_task_fp(vcpu);
>  
>  	/* Make sure the host task fpsimd state is visible to hyp: */
> -	ret = kvm_share_hyp(fpsimd, fpsimd + 1);
> +	ret = kvm_share_hyp(fpsimd, fpsimd_share_end(fpsimd));
>  	if (ret)
>  		return ret;
>  
>  	vcpu->arch.host_fpsimd_state = kern_hyp_va(fpsimd);
> +	if (cpus_have_final_cap(ARM64_HAS_FPMR)) {
> +		WARN_ON_ONCE(&current->thread.fpmr + 1 != fpsimd_share_end(fpsimd));

How can this happen?

> +		vcpu->arch.host_fpmr = kern_hyp_va(&current->thread.fpmr);
> +	}

We really need to stop piling the save/restore of stuff that isn't
advertised to the guest.

	M.

-- 
Without deviation from the norm, progress is not possible.


From umang.jain at ideasonboard.com  Thu Dec  7 00:41:36 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Thu, 7 Dec 2023 14:11:36 +0530
Subject: [PATCH v3 1/4] staging: vc04_services: Drop vchiq_log_error() in
 favour of dev_err
In-Reply-To: <3920385c-3c10-471a-ba82-8e48ba34f6a5@gmx.net>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-2-umang.jain@ideasonboard.com>
 <d6bf7115-dd15-43a0-b45a-41fc778ff160@gmx.net>
 <6a8566c0-bd26-4ec1-9f7d-d58bbed8411c@ideasonboard.com>
 <3920385c-3c10-471a-ba82-8e48ba34f6a5@gmx.net>
Message-ID: <855cd4ee-86db-ca46-ce91-17303941ff82@ideasonboard.com>

Hi Stefan

On 12/7/23 3:04 AM, Stefan Wahren wrote:
> Hi Umang,
>
> Am 06.12.23 um 06:27 schrieb Umang Jain:
>> Hi Stefan
>>
>> On 12/6/23 1:02 AM, Stefan Wahren wrote:
>>> Hi Umang,
>>>
>>> Am 05.12.23 um 09:41 schrieb Umang Jain:
>>>> Drop vchiq_log_error() macro which wraps dev_dbg(). Introduce the 
>>>> usage
>>>> of dev_err() directly.
>>> sorry, i missed to review the last change. So the change won't be that
>>> trivial.
>>
>> All the changes you said are valid and I have taken a note of it.
>>
>> However, I think it would best that if we can address them in a
>> separate series on top of this (and I will do it). It would seem to be
>> streamlined on top of this.
> i would address the comments as separate patches and then finally
> convert the trivial rest with such a patch within one series. This
> avoids unnecessary changes and reviewes. But that's just my opinion.
>

Series is merged by Greg KH (Thank you).

Do you have more comments on 3/4 and 4/4 or are they waiting on your 
review queue. Let me know so that I can prepare a follow up series in 
-one- go.

thanks!
> Best regards



From luxu.kernel at bytedance.com  Thu Dec  7 01:09:33 2023
From: luxu.kernel at bytedance.com (Xu Lu)
Date: Thu, 7 Dec 2023 17:09:33 +0800
Subject: [External] [RFC PATCH 0/3] riscv: add support for SBI Supervisor
 Software Events
In-Reply-To: <20231026143122.279437-1-cleger@rivosinc.com>
References: <20231026143122.279437-1-cleger@rivosinc.com>
Message-ID: <CAPYmKFsFLQnhXRPXpcoNfO-kEyjYLXD2Hm-F-O=Yxe1WJoSL9w@mail.gmail.com>

Pardon. It seems that the code in opensbi[1] is not complete for PMU NMI now.
For example, the pmu ovf irq is still delegated to supervisor mode and
thus can not really play a role as NMI. And neither the kernel nor
opensbi will inject a pmu event.

To complete the work, we think maybe 'enable_cb' and 'disable_cb'
functions can be supplied for sbi_sse_cb_ops.
When sbi_sse_enable is called to enable pmu event, the enable_cb will
be called to revoke the delegation of pmu ovf irq and enable this irq
in CSR_MIE.
When pmu ovf irq occurs, kernel traps into opensbi and opensbi injects
the event via sbi_sse_inject_event and eret back to kernel.

Please point it out if we have any misunderstanding.

By the way, how is SSE going now? We will appreciate it very much if
we can participate in some development work in kernel or opensbi and
be of any help.

Regards!

Link: https://github.com/rivosinc/opensbi/tree/dev/cleger/sse [1]

On Thu, Oct 26, 2023 at 10:31?PM Cl?ment L?ger <cleger at rivosinc.com> wrote:
>
> The SBI Supervisor Software Events (SSE) extensions provides a mechanism
> to inject software events from an SBI implementation to supervisor
> software such that it preempts all other supervisor level traps and
> interrupts [1].
>
> Various events are defined and can be send asynchronously to supervisor
> software (RAS, PMU, DEBUG, Asynchronous page fault) from SBI as well
> as platform specific events. Events can be either local (per-hart) or
> global. Events can be nested on top of each other based on priority and
> can interrupt the kernel at any time.
>
> First patch adds the SSE definitions. Second one adds support for SSE
> itself. Implementation is split between arch specific code and generic
> part (similarly to what is done for ARM SDEI). Finally, the last patch
> add support fro SSE event in the SBI PMU driver. If the SSE event is
> available from the SBI then, it will be used instead of the normal
> interrupt.
>
> Amongst the specific points that needs to be handle is the interruption
> at any point of the kernel execution and more specifically during
> exception handling. Due to the fact that the exception entry
> implementation uses the SCRATCH CSR as both the current task struct and
> as the temporary register to switch the stack and save register, it is
> difficult to reliably get the current task struct if we get interrupted
> at this specific moment. A fixup-like mechanism allows to mark the
> location of the current task struct depending on the entry level
> (user/kernel) and the location. This is then used in the SSE assembly to
> determine where is located the current task_struct.
>
> Contrary to pseudo NMI [2], SSE does not modifies the way interrupts are
> handled and does not adds any overhead to existing code. Moreover, it
> provides "true" NMI-like interrupts which can interrupt the kernel at
> any time (even in exception handling). This is particularly crucial for
> RAS errors which needs to be handled as fast as possible to avoid any
> fault propagation. Additionally, SSE event handling is faster that the
> standard IRQ handling path with almost half executed instruction (700 vs
> 1590). Some complementary tests/perf measurements will be done.
>
> For testing purpose, one can use the provided SBI implementation at [3].
> This series also needs patch [4] to fix a bug in the PMU driver.
>
> Link: https://lists.riscv.org/g/tech-prs/message/515 [1]
> Link: https://lore.kernel.org/lkml/20231023082911.23242-10-luxu.kernel at bytedance.com/T/ [2]
> Link: https://github.com/rivosinc/opensbi/tree/dev/cleger/sse [3]
> Link: https://lore.kernel.org/linux-arm-kernel/20231026084010.11888-1-alexghiti at rivosinc.com/ [4]
>
> ---
>
> Cl?ment L?ger (3):
>   riscv: add SBI SSE extension definitions
>   riscv: add support for SBI Supervisor Software Events extension
>   perf: RISC-V: add support for SSE event
>
>  arch/riscv/include/asm/asm-prototypes.h |   5 +
>  arch/riscv/include/asm/sbi.h            |  40 ++
>  arch/riscv/include/asm/sse.h            |  94 +++++
>  arch/riscv/kernel/Makefile              |   1 +
>  arch/riscv/kernel/asm-offsets.c         |  17 +
>  arch/riscv/kernel/entry.S               | 156 ++++++++
>  arch/riscv/kernel/sbi.c                 |   4 +
>  arch/riscv/kernel/sse.c                 |  97 +++++
>  arch/riscv/kernel/stacktrace.c          |  13 +
>  arch/riscv/kernel/vmlinux.lds.S         |   6 +
>  drivers/firmware/Kconfig                |  10 +
>  drivers/firmware/Makefile               |   1 +
>  drivers/firmware/riscv_sse.c            | 496 ++++++++++++++++++++++++
>  drivers/perf/riscv_pmu_sbi.c            |  51 ++-
>  include/linux/riscv_sse.h               |  56 +++
>  15 files changed, 1038 insertions(+), 9 deletions(-)
>  create mode 100644 arch/riscv/include/asm/sse.h
>  create mode 100644 arch/riscv/kernel/sse.c
>  create mode 100644 drivers/firmware/riscv_sse.c
>  create mode 100644 include/linux/riscv_sse.h
>
> --
> 2.42.0
>


From paul at crapouillou.net  Thu Dec  7 01:16:38 2023
From: paul at crapouillou.net (Paul Cercueil)
Date: Thu, 07 Dec 2023 10:16:38 +0100
Subject: [PATCH RESEND] drm/exynos: dpi: Change connector type to DPI
In-Reply-To: <048a01da28b6$f84c2670$e8e47350$@samsung.com>
References: <CGME20231206221903epcas1p2e9d90110b0f2901e3e7db86f748026f1@epcas1p2.samsung.com>
	 <20231206221841.15685-1-paul@crapouillou.net>
	 <048a01da28b6$f84c2670$e8e47350$@samsung.com>
Message-ID: <61393c2e941515612f7c4a7d66cd19f00e88ea9d.camel@crapouillou.net>

Le jeudi 07 d?cembre 2023 ? 11:42 +0900, ???/Tizen Platform
Lab(SR)/???? a ?crit?:
> Hi Paul,
> 
> > -----Original Message-----
> > From: Paul Cercueil <paul at crapouillou.net>
> > Sent: Thursday, December 7, 2023 7:19 AM
> > To: Inki Dae <inki.dae at samsung.com>; Seung-Woo Kim
> > <sw0312.kim at samsung.com>; Kyungmin Park
> > <kyungmin.park at samsung.com>;
> > Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>; Alim Akhtar
> > <alim.akhtar at samsung.com>
> > Cc: David Airlie <airlied at gmail.com>; Daniel Vetter
> > <daniel at ffwll.ch>;
> > dri-devel at lists.freedesktop.org;
> > linux-arm-kernel at lists.infradead.org;
> > linux-samsung-soc at vger.kernel.org; linux-kernel at vger.kernel.org;
> > Paul
> > Cercueil <paul at crapouillou.net>
> > Subject: [PATCH RESEND] drm/exynos: dpi: Change connector type to
> > DPI
> > 
> > When exynos_drm_dpi.c was written, DRM_MODE_CONNECTOR_DPI did not
> > exist
> > yet and I guess that's the reason why DRM_MODE_CONNECTOR_VGA was
> > used as
> > the connector type.
> > 
> > However, now it makes more sense to use DRM_MODE_CONNECTOR_DPI as
> > the
> > connector type.
> 
> Sorry for late. Merged.

No problem. Thank you!

Cheers,
-Paul

> 
> Thanks,
> Inki Dae
> 
> > 
> > Signed-off-by: Paul Cercueil <paul at crapouillou.net>
> > ---
> > ?drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
> > ?1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> > b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> > index 378e5381978f..0dc36df6ada3 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> > @@ -101,7 +101,7 @@ static int exynos_dpi_create_connector(struct
> > drm_encoder *encoder)
> > 
> > ?	ret = drm_connector_init(encoder->dev, connector,
> > ?				 &exynos_dpi_connector_funcs,
> > -				 DRM_MODE_CONNECTOR_VGA);
> > +				 DRM_MODE_CONNECTOR_DPI);
> > ?	if (ret) {
> > ?		DRM_DEV_ERROR(ctx->dev,
> > ?			????? "failed to initialize connector with
> > drm\n");
> > --
> > 2.42.0
> > 
> 
> 



From mripard at kernel.org  Thu Dec  7 01:20:01 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 7 Dec 2023 10:20:01 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
Message-ID: <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>

On Tue, Dec 05, 2023 at 02:50:08PM +0100, H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 05.12.2023 um 14:29 schrieb Maxime Ripard <mripard at kernel.org>:
> > 
> > Hi,
> > 
> > On Tue, Dec 05, 2023 at 09:18:58AM +0100, H. Nikolaus Schaller wrote:
> >>> Am 05.12.2023 um 07:57 schrieb Maxime Ripard <mripard at kernel.org>:
> >>> 
> >>> On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
> >>>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> >>>> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
> >>>> including register space and interrupts. Clocks, reset, and power domain
> >>>> information is SoC specific.
> >>>> 
> >>>> Signed-off-by: Andrew Davis <afd at ti.com>
> >>>> ---
> >>>> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
> >>>> 1 file changed, 63 insertions(+), 6 deletions(-)
> >>> 
> >>> I think it would be best to have a separate file for this, img,sgx.yaml
> >>> maybe?
> >> 
> >> Why?
> > 
> > Because it's more convenient?
> 
> Is it?

It's for a separate architecture, with a separate driver, maintained out
of tree by a separate community, with a separate set of requirements as
evidenced by the other thread. And that's all fine in itself, but
there's very little reason to put these two bindings in the same file.

We could also turn this around, why is it important that it's in the
same file?

> >> The whole family of IMG GPUs is PowerVR and SGX and Rogue are generations 5 and 6++:
> >> 
> >> https://en.wikipedia.org/wiki/PowerVR
> > 
> > That's not really relevant as far as bindings go.
> 
> But maybe for choosing binding file names. Well they are machine readable
> but sometimes humans work with them.

Heh. It's something that can also be easily grepped, and the name is
never going to reflect all the compatibles in a binding so it's what
you'll end up doing anyway. But feel free to suggest another name to
avoid the confusion.

> > We have multiple
> > binding files for devices of the same generation, or single bindings
> > covering multiple generations.
> > 
> > The important part is that every compatible is documented. It doesn't
> > really matter how or where.
> 
> Yes, and that is why I would find it more convenient to have a single
> "img,powervr.yaml" for all variations unless it becomes filled with
> unrelated stuff (which isn't as far as I see).

Again, hard disagree there.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/f786ffa3/attachment-0001.sig>

From ionela.voinescu at arm.com  Thu Dec  7 01:22:06 2023
From: ionela.voinescu at arm.com (Ionela Voinescu)
Date: Thu, 7 Dec 2023 09:22:06 +0000
Subject: [PATCH v2 2/2] cpufreq: Wire-up arch-flavored freq info into
 cpufreq_verify_current_freq
In-Reply-To: <c8b4d391-681e-f4a6-2839-e5951429f043@nvidia.com>
References: <20231127160838.1403404-1-beata.michalska@arm.com>
 <20231127160838.1403404-3-beata.michalska@arm.com>
 <ZWXy0h/fFfQh+Rhy@arm.com>
 <3e6077bb-907c-057f-0896-d0a5814a4229@nvidia.com>
 <ZW8D5TfSwuJfdYeD@arm.com>
 <c8b4d391-681e-f4a6-2839-e5951429f043@nvidia.com>
Message-ID: <ZXGOvsE4mKOsdoLp@arm.com>

On Wednesday 06 Dec 2023 at 18:58:17 (+0530), Sumit Gupta wrote:
> 
> 
> On 05/12/23 16:35, Ionela Voinescu wrote:
> > External email: Use caution opening links or attachments
> > 
> > 
> > Hi Sumit,
> > 
> > On Friday 01 Dec 2023 at 18:32:10 (+0530), Sumit Gupta wrote:
> > > Hi Ionela,
> > > 
> > > > > --- a/drivers/cpufreq/cpufreq.c
> > > > > +++ b/drivers/cpufreq/cpufreq.c
> > > > > @@ -1756,7 +1756,8 @@ static unsigned int cpufreq_verify_current_freq(struct cpufreq_policy *policy, b
> > > > >    {
> > > > >         unsigned int new_freq;
> > > > > 
> > > > > -     new_freq = cpufreq_driver->get(policy->cpu);
> > > > > +     new_freq = arch_freq_get_on_cpu(policy->cpu);
> > > > > +     new_freq = new_freq ?: cpufreq_driver->get(policy->cpu);
> > > > 
> > > > Given that arch_freq_get_on_cpu() is an average frequency, it does not
> > > > seem right to me to trigger the sync & update process of
> > > > cpufreq_verify_current_freq() based on it.
> > > > 
> > > > cpufreq_verify_current_freq() will at least modify the internal state of
> > > > the policy and send PRE and POST notifications, if not do a full frequency
> > > > update, based on this average frequency, which is likely different from
> > > > the current frequency, even beyond the 1MHz threshold.
> > > > 
> > > > While I believe it's okay to return this average frequency in
> > > > cpuinfo_cur_freq, I don't think it should be used as an indication of
> > > > an accurate current frequency, which is what
> > > > cpufreq_verify_current_freq() expects.
> > > > 
> > > > Sumit, can you give more details on the issue at [1] and why this change
> > > > fixes it?
> > > > 
> > > > [1] https://lore.kernel.org/lkml/6a5710f6-bfbb-5dfd-11cd-0cd02220cee7 at nvidia.com/
> > > > 
> > > > Thank you,
> > > > Ionela.
> > > > 
> > > cpufreq_verify_current_freq() also updates 'policy->cur' in POST
> > > notification if the frequency from hardware has more delta (out of sync).
> > > 
> > > As the value from 'cpufreq_driver->get()' is not reliable due to [1],
> > > calling the 'get' hook can update the 'policy->cur' with a wrong value when
> > > governor starts in cpufreq_start_governor().
> > > And if the frequency is never changed after the governor starts during
> > > boot e.g. when performance governor is set as default, then
> > > 'scaling_cur_freq' always returns wrong value.
> > > 
> > > Instead, the arch_freq_get_on_cpu() API updates 'policy->cur' with a more
> > > stable freq value.
> > > 
> > > [1] https://lore.kernel.org/lkml/20230418113459.12860-7-sumitg at nvidia.com/
> > 
> > Got it, many thanks!
> > 
> > As the code is right now in v2, arch_freq_get_on_cpu() is called on
> > show_scaling_cur_freq(), so the problem you describe would not show up.
> > policy->cur would still be incorrect, but 'scaling_cur_freq' would
> > return the value from arch_freq_get_on_cpu().
> > 
> > Would it be enough if arch_freq_get_on_cpu() gets also called from
> > show_cpuinfo_cur_freq() instead of cpufreq_verify_current_freq()?
> > 
> > Thanks,
> > Ionela.
> > 
> 
> Yes.
> I am not sure if making both the nodes 'scaling_cur_freq' and
> 'cpuinfo_cur_freq' same is fine?

That would happen anyway if arch_freq_get_on_cpu() is called from
cpufreq_verify_current_freq().

In principle, according to [1], it would be correct to use it for
'cpuinfo_cur_freq' and not 'scaling_cur_freq'. But the call from
show_scaling_cur_freq() is already there before these patches,
introduced a long time ago for x86.

The topic was discussed at [2] and the agreement so far was that it
would be best to keep the behaviour the same for both x86 and arm.

I don't like going against the user-guide, but these patches don't
actually go against the user-guide. The old call to
arch_freq_get_on_cpu() from show_scaling_cur_freq() goes against it.
But I agree that's something necessary to keep, as legacy for x86.
Additionally, you also mentioned that you'd prefer to have a more
accurate frequency returned for 'scaling_cur_freq'.

[1] https://www.kernel.org/doc/Documentation/cpu-freq/user-guide.txt
[2] https://lore.kernel.org/lkml/20230609043922.eyyqutbwlofqaddz at vireshk-i7/

Thanks,
Ionela.

> 
> Best Regards,
> Sumit Gupta


From cleger at rivosinc.com  Thu Dec  7 01:23:20 2023
From: cleger at rivosinc.com (=?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?=)
Date: Thu, 7 Dec 2023 10:23:20 +0100
Subject: [External] [RFC PATCH 0/3] riscv: add support for SBI Supervisor
 Software Events
In-Reply-To: <CAPYmKFsFLQnhXRPXpcoNfO-kEyjYLXD2Hm-F-O=Yxe1WJoSL9w@mail.gmail.com>
References: <20231026143122.279437-1-cleger@rivosinc.com>
 <CAPYmKFsFLQnhXRPXpcoNfO-kEyjYLXD2Hm-F-O=Yxe1WJoSL9w@mail.gmail.com>
Message-ID: <8a9952bf-67ff-4ab0-9e44-e2c2f2a68076@rivosinc.com>



On 07/12/2023 10:09, Xu Lu wrote:
> Pardon. It seems that the code in opensbi[1] is not complete for PMU NMI now.
> For example, the pmu ovf irq is still delegated to supervisor mode and
> thus can not really play a role as NMI. And neither the kernel nor
> opensbi will inject a pmu event.
> 
> To complete the work, we think maybe 'enable_cb' and 'disable_cb'
> functions can be supplied for sbi_sse_cb_ops.
> When sbi_sse_enable is called to enable pmu event, the enable_cb will
> be called to revoke the delegation of pmu ovf irq and enable this irq
> in CSR_MIE.

Hi Xu,

Indeed, this part has been developed but was left out for the RFC. But
your understanding is correct.

> When pmu ovf irq occurs, kernel traps into opensbi and opensbi injects
> the event via sbi_sse_inject_event and eret back to kernel.
> 
> Please point it out if we have any misunderstanding.
> 
> By the way, how is SSE going now? We will appreciate it very much if
> we can participate in some development work in kernel or opensbi and
> be of any help.

The development is almost complete, Anup/Himanchu will send a new
revision of the spec addressing various comments and I'll resend the RFC
following that spec update.

Regards,

Cl?ment

> 
> Regards!
> 
> Link: https://github.com/rivosinc/opensbi/tree/dev/cleger/sse [1]
> 
> On Thu, Oct 26, 2023 at 10:31?PM Cl?ment L?ger <cleger at rivosinc.com> wrote:
>>
>> The SBI Supervisor Software Events (SSE) extensions provides a mechanism
>> to inject software events from an SBI implementation to supervisor
>> software such that it preempts all other supervisor level traps and
>> interrupts [1].
>>
>> Various events are defined and can be send asynchronously to supervisor
>> software (RAS, PMU, DEBUG, Asynchronous page fault) from SBI as well
>> as platform specific events. Events can be either local (per-hart) or
>> global. Events can be nested on top of each other based on priority and
>> can interrupt the kernel at any time.
>>
>> First patch adds the SSE definitions. Second one adds support for SSE
>> itself. Implementation is split between arch specific code and generic
>> part (similarly to what is done for ARM SDEI). Finally, the last patch
>> add support fro SSE event in the SBI PMU driver. If the SSE event is
>> available from the SBI then, it will be used instead of the normal
>> interrupt.
>>
>> Amongst the specific points that needs to be handle is the interruption
>> at any point of the kernel execution and more specifically during
>> exception handling. Due to the fact that the exception entry
>> implementation uses the SCRATCH CSR as both the current task struct and
>> as the temporary register to switch the stack and save register, it is
>> difficult to reliably get the current task struct if we get interrupted
>> at this specific moment. A fixup-like mechanism allows to mark the
>> location of the current task struct depending on the entry level
>> (user/kernel) and the location. This is then used in the SSE assembly to
>> determine where is located the current task_struct.
>>
>> Contrary to pseudo NMI [2], SSE does not modifies the way interrupts are
>> handled and does not adds any overhead to existing code. Moreover, it
>> provides "true" NMI-like interrupts which can interrupt the kernel at
>> any time (even in exception handling). This is particularly crucial for
>> RAS errors which needs to be handled as fast as possible to avoid any
>> fault propagation. Additionally, SSE event handling is faster that the
>> standard IRQ handling path with almost half executed instruction (700 vs
>> 1590). Some complementary tests/perf measurements will be done.
>>
>> For testing purpose, one can use the provided SBI implementation at [3].
>> This series also needs patch [4] to fix a bug in the PMU driver.
>>
>> Link: https://lists.riscv.org/g/tech-prs/message/515 [1]
>> Link: https://lore.kernel.org/lkml/20231023082911.23242-10-luxu.kernel at bytedance.com/T/ [2]
>> Link: https://github.com/rivosinc/opensbi/tree/dev/cleger/sse [3]
>> Link: https://lore.kernel.org/linux-arm-kernel/20231026084010.11888-1-alexghiti at rivosinc.com/ [4]
>>
>> ---
>>
>> Cl?ment L?ger (3):
>>   riscv: add SBI SSE extension definitions
>>   riscv: add support for SBI Supervisor Software Events extension
>>   perf: RISC-V: add support for SSE event
>>
>>  arch/riscv/include/asm/asm-prototypes.h |   5 +
>>  arch/riscv/include/asm/sbi.h            |  40 ++
>>  arch/riscv/include/asm/sse.h            |  94 +++++
>>  arch/riscv/kernel/Makefile              |   1 +
>>  arch/riscv/kernel/asm-offsets.c         |  17 +
>>  arch/riscv/kernel/entry.S               | 156 ++++++++
>>  arch/riscv/kernel/sbi.c                 |   4 +
>>  arch/riscv/kernel/sse.c                 |  97 +++++
>>  arch/riscv/kernel/stacktrace.c          |  13 +
>>  arch/riscv/kernel/vmlinux.lds.S         |   6 +
>>  drivers/firmware/Kconfig                |  10 +
>>  drivers/firmware/Makefile               |   1 +
>>  drivers/firmware/riscv_sse.c            | 496 ++++++++++++++++++++++++
>>  drivers/perf/riscv_pmu_sbi.c            |  51 ++-
>>  include/linux/riscv_sse.h               |  56 +++
>>  15 files changed, 1038 insertions(+), 9 deletions(-)
>>  create mode 100644 arch/riscv/include/asm/sse.h
>>  create mode 100644 arch/riscv/kernel/sse.c
>>  create mode 100644 drivers/firmware/riscv_sse.c
>>  create mode 100644 include/linux/riscv_sse.h
>>
>> --
>> 2.42.0
>>


From jensenhuang at friendlyarm.com  Thu Dec  7 01:25:44 2023
From: jensenhuang at friendlyarm.com (Jensen Huang)
Date: Thu, 7 Dec 2023 17:25:44 +0800
Subject: [PATCH v2] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <ebf6cf8ec3b5befd673d295061fa2738@manjaro.org>
References: <20231207082200.16388-1-jensenhuang@friendlyarm.com> <ebf6cf8ec3b5befd673d295061fa2738@manjaro.org>
Message-ID: <CAMpZ1qHUnTDQ78gdrQF9Sx_-XfLM-B+H-0bL1-+twKsno+JOvg@mail.gmail.com>

On Thu, Dec 7, 2023 at 4:37?PM Dragan Simic <dsimic at manjaro.org> wrote:
>
> On 2023-12-07 09:21, Jensen Huang wrote:
> > Possible deadlock scenario (on reboot):
> > rk3x_i2c_xfer_common(polling)
> >     -> rk3x_i2c_wait_xfer_poll()
> >         -> rk3x_i2c_irq(0, i2c);
> >             --> spin_lock(&i2c->lock);
> >             ...
> >         <rk3x i2c interrupt>
> >         -> rk3x_i2c_irq(0, i2c);
> >             --> spin_lock(&i2c->lock); (deadlock here)
> >
> > Store the IRQ number and disable/enable it around the polling transfer.
> > This patch has been tested on NanoPC-T4.
>
> In case you haven't already seen the related discussion linked below,
> please have a look.  I also added more people to the list of recipients,
> in an attempt to make everyone aware of the different approaches to
> solving this issue.
>
> https://lore.kernel.org/all/655177f4.050a0220.d85c9.3ba0 at mx.google.com/T/#m6fc9c214452fec6681843e7f455978c35c6f6c8b

Thank you for providing the information. I hadn't seen this link before.
After carefully looking into the related discussion, it appears that
Dmitry Osipenko is already working on a suitable patch. To avoid duplication
or conflicts, my patch can be discarded.

--
Best regards,
Jensen


From peng.fan at oss.nxp.com  Thu Dec  7 01:33:44 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu,  7 Dec 2023 17:33:44 +0800
Subject: [PATCH V2 1/2] firmware: arm_scmi: clock: implement get permissions
Message-ID: <20231207093345.581048-1-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

ARM SCMI Spec 3.2 introduces Clock Get Permission command. This patch
is to add the support. Add three bool entries to scmi_clock_info to
indicate the operation is forbidden or not. If the CLOCK_GET_PERMISSIONS
command is not supported, the three bool variables will default
set to false, otherwise they will be set according to the return result
of CLOCK_GET_PERMISSIONS.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---

V2:
 Take Cristian's suggestion, https://lore.kernel.org/all/ZWiqqfQ73tezFmSk at pluto/

 drivers/firmware/arm_scmi/clock.c | 53 +++++++++++++++++++++++++++++++
 include/linux/scmi_protocol.h     |  4 +++
 2 files changed, 57 insertions(+)

diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index 98511a3aa367..0e048530bea2 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -25,8 +25,13 @@ enum scmi_clock_protocol_cmd {
 	CLOCK_POSSIBLE_PARENTS_GET = 0xC,
 	CLOCK_PARENT_SET = 0xD,
 	CLOCK_PARENT_GET = 0xE,
+	CLOCK_GET_PERMISSIONS = 0xF,
 };
 
+#define CLOCK_STATE_CONTROL_ALLOWED	BIT(31)
+#define CLOCK_PARENT_CONTROL_ALLOWED	BIT(30)
+#define CLOCK_RATE_CONTROL_ALLOWED	BIT(29)
+
 enum clk_state {
 	CLK_STATE_DISABLE,
 	CLK_STATE_ENABLE,
@@ -46,6 +51,7 @@ struct scmi_msg_resp_clock_attributes {
 #define SUPPORTS_RATE_CHANGE_REQUESTED_NOTIF(x)	((x) & BIT(30))
 #define SUPPORTS_EXTENDED_NAMES(x)		((x) & BIT(29))
 #define SUPPORTS_PARENT_CLOCK(x)		((x) & BIT(28))
+#define SUPPORTS_GET_PERMISSIONS(x)		((x) & BIT(1))
 	u8 name[SCMI_SHORT_NAME_MAX_SIZE];
 	__le32 clock_enable_latency;
 };
@@ -281,6 +287,35 @@ static int scmi_clock_possible_parents(const struct scmi_protocol_handle *ph, u3
 	return ret;
 }
 
+static int
+scmi_clock_get_permissions(const struct scmi_protocol_handle *ph, u32 clk_id,
+			   struct scmi_clock_info *clk)
+{
+	struct scmi_xfer *t;
+	u32 perm;
+	int ret;
+
+	ret = ph->xops->xfer_get_init(ph, CLOCK_GET_PERMISSIONS,
+				      sizeof(clk_id), sizeof(perm), &t);
+	if (ret)
+		return ret;
+
+	put_unaligned_le32(clk_id, t->tx.buf);
+
+	ret = ph->xops->do_xfer(ph, t);
+	if (!ret) {
+		perm = get_unaligned_le32(t->rx.buf);
+
+		clk->state_ctrl_forbidden = !(perm & CLOCK_STATE_CONTROL_ALLOWED);
+		clk->rate_ctrl_forbidden = !(perm & CLOCK_RATE_CONTROL_ALLOWED);
+		clk->parent_ctrl_forbidden = !(perm & CLOCK_PARENT_CONTROL_ALLOWED);
+	}
+
+	ph->xops->xfer_put(ph, t);
+
+	return ret;
+}
+
 static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
 				     u32 clk_id, struct scmi_clock_info *clk,
 				     u32 version)
@@ -307,6 +342,7 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
 		if (PROTOCOL_REV_MAJOR(version) >= 0x2)
 			latency = le32_to_cpu(attr->clock_enable_latency);
 		clk->enable_latency = latency ? : U32_MAX;
+		clk->attributes = attributes;
 	}
 
 	ph->xops->xfer_put(ph, t);
@@ -327,6 +363,8 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
 			clk->rate_change_requested_notifications = true;
 		if (SUPPORTS_PARENT_CLOCK(attributes))
 			scmi_clock_possible_parents(ph, clk_id, clk);
+		if (SUPPORTS_GET_PERMISSIONS(attributes))
+			scmi_clock_get_permissions(ph, clk_id, clk);
 	}
 
 	return ret;
@@ -499,6 +537,10 @@ static int scmi_clock_rate_set(const struct scmi_protocol_handle *ph,
 	struct scmi_xfer *t;
 	struct scmi_clock_set_rate *cfg;
 	struct clock_info *ci = ph->get_priv(ph);
+	struct scmi_clock_info *clk = ci->clk + clk_id;
+
+	if (clk->rate_ctrl_forbidden)
+		return -EACCES;
 
 	ret = ph->xops->xfer_get_init(ph, CLOCK_RATE_SET, sizeof(*cfg), 0, &t);
 	if (ret)
@@ -585,6 +627,9 @@ scmi_clock_set_parent(const struct scmi_protocol_handle *ph, u32 clk_id,
 	if (parent_id >= clk->num_parents)
 		return -EINVAL;
 
+	if (clk->parent_ctrl_forbidden)
+		return -EACCES;
+
 	ret = ph->xops->xfer_get_init(ph, CLOCK_PARENT_SET,
 				      sizeof(*cfg), 0, &t);
 	if (ret)
@@ -668,6 +713,10 @@ static int scmi_clock_enable(const struct scmi_protocol_handle *ph, u32 clk_id,
 			     bool atomic)
 {
 	struct clock_info *ci = ph->get_priv(ph);
+	struct scmi_clock_info *clk = ci->clk + clk_id;
+
+	if (clk->state_ctrl_forbidden)
+		return -EACCES;
 
 	return ci->clock_config_set(ph, clk_id, CLK_STATE_ENABLE,
 				    NULL_OEM_TYPE, 0, atomic);
@@ -677,6 +726,10 @@ static int scmi_clock_disable(const struct scmi_protocol_handle *ph, u32 clk_id,
 			      bool atomic)
 {
 	struct clock_info *ci = ph->get_priv(ph);
+	struct scmi_clock_info *clk = ci->clk + clk_id;
+
+	if (clk->state_ctrl_forbidden)
+		return -EACCES;
 
 	return ci->clock_config_set(ph, clk_id, CLK_STATE_DISABLE,
 				    NULL_OEM_TYPE, 0, atomic);
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index f2f05fb42d28..ad75784b567b 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -47,6 +47,9 @@ struct scmi_clock_info {
 	bool rate_discrete;
 	bool rate_changed_notifications;
 	bool rate_change_requested_notifications;
+	bool state_ctrl_forbidden;
+	bool rate_ctrl_forbidden;
+	bool parent_ctrl_forbidden;
 	union {
 		struct {
 			int num_rates;
@@ -60,6 +63,7 @@ struct scmi_clock_info {
 	};
 	int num_parents;
 	u32 *parents;
+	u32 attributes;
 };
 
 enum scmi_power_scale {
-- 
2.37.1



From peng.fan at oss.nxp.com  Thu Dec  7 01:33:45 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu,  7 Dec 2023 17:33:45 +0800
Subject: [PATCH V2 2/2] clk: scmi: support state_ctrl_forbidden
In-Reply-To: <20231207093345.581048-1-peng.fan@oss.nxp.com>
References: <20231207093345.581048-1-peng.fan@oss.nxp.com>
Message-ID: <20231207093345.581048-2-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Some clocks may exported to linux, while those clocks are not allowed
to configure by Linux. For example:

SYS_CLK1-----
             \
	     --MUX--->MMC1_CLK
             /
SYS_CLK2-----

MMC1 needs set parent, so SYS_CLK1 and SYS_CLK2 are exported to Linux,
then the clk propagation will touch SYS_CLK1 or SYS_CLK2.
So we need bypass the failure for SYS_CLK1 or SYS_CLK2 when enable
the clock of MMC1.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---

V2:
 New. Take Cristian's suggestion

 drivers/clk/clk-scmi.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
index 8cbe24789c24..1d809813eabd 100644
--- a/drivers/clk/clk-scmi.c
+++ b/drivers/clk/clk-scmi.c
@@ -119,8 +119,14 @@ static int scmi_clk_determine_rate(struct clk_hw *hw, struct clk_rate_request *r
 static int scmi_clk_enable(struct clk_hw *hw)
 {
 	struct scmi_clk *clk = to_scmi_clk(hw);
+	int ret;
+
+	ret = scmi_proto_clk_ops->enable(clk->ph, clk->id, NOT_ATOMIC);
 
-	return scmi_proto_clk_ops->enable(clk->ph, clk->id, NOT_ATOMIC);
+	if (ret == -EACCES && clk->info->state_ctrl_forbidden)
+		return 0;
+
+	return ret;
 }
 
 static void scmi_clk_disable(struct clk_hw *hw)
-- 
2.37.1



From conor.dooley at microchip.com  Thu Dec  7 01:34:59 2023
From: conor.dooley at microchip.com (Conor Dooley)
Date: Thu, 7 Dec 2023 09:34:59 +0000
Subject: [PATCH v1 1/2] dt-bindings: display: panel: raspberrypi: Add
 compatible property for waveshare 7inch touchscreen panel
In-Reply-To: <53b992e8-1b36-4540-a993-fde8e550faf9@starfivetech.com>
References: <20231124104451.44271-1-shengyang.chen@starfivetech.com>
 <20231124104451.44271-2-shengyang.chen@starfivetech.com>
 <20231124-lesser-sinister-7f9cd7b80e35@spud>
 <2d48e460-e46e-431f-bd7b-e34ebe73a40c@starfivetech.com>
 <20231206-isolating-smoked-b490952029d0@spud>
 <53b992e8-1b36-4540-a993-fde8e550faf9@starfivetech.com>
Message-ID: <20231207-dullness-deprive-ece2d47ff69d@wendy>

On Thu, Dec 07, 2023 at 11:48:56AM +0800, Shengyang Chen wrote:
> Hi, Conor
> 
> thanks for comment
> 
> On 2023/12/6 23:40, Conor Dooley wrote:
> > On Wed, Dec 06, 2023 at 05:43:48PM +0800, Shengyang Chen wrote:
> >> Hi, Conor
> >> 
> >> On 2023/11/24 20:31, Conor Dooley wrote:
> >> > On Fri, Nov 24, 2023 at 06:44:50PM +0800, Shengyang Chen wrote:
> >> >> The waveshare 7inch touchscreen panel is a kind of raspberrypi pi
> >> >> panel
> >> > 
> >> > Can you be more specific about what "is a kind of rpi panel" means?
> >> > Are they using identical chips as controllers or something like that?
> >> > 
> >> 
> >> Wareshare panel has same i2c slave address and registers address with 
> >> the original raspberry pi panel. They both use Atmel firmware and they
> >> got same reg id. It can be operated by using the driver of raspberry pi driver
> >> after some change of the code. So I suppose it may be a kind of raspberry pi panel 
> >> and discribe it in this way. It's my own judgement. Sorry about that.
> >> Maybe just like Dave said, It cloned the behaviour of the raspberri pi panel.
> >> I will change the discribtion in next version to not make other confused.
> >> 
> >> By the way, we will try Stefan's method before next version. 
> >> The method we used in this patch may be abandoned if Stefan's method is verified in our platform.
> >> At that time yaml may also be changed to fit new method.
> > 
> > I don't know what Stefan's approach is, but I do not think that a
> > bindings patch should be dropped. The waveshare might be a clone, but it
> > is a distinct device. If the same driver can control both, then the
> > compatible setups that should be permitted are:
> > compatible = "raspberrypi,7inch-touchscreen-panel";
> > and
> > compatible = "waveshare,7inch-touchscreen-panel", "raspberrypi,7inch-touchscreen-panel";

> If we use Stenfan's method, we can reuse the code of panel-simple.c
> we may submit our patch to
> /Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> /drivers/gpu/drm/panel/panel-simple.c
> as a new panel porting. That may less confuse.

As long as you provide a specific compatible, and not re-use the rpi
one, that's fine. It just sounded like you were intending to reuse that
here, but from this message it seems like I misunderstood.

Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/80fe14fe/attachment.sig>

From lkp at intel.com  Thu Dec  7 01:35:30 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 7 Dec 2023 17:35:30 +0800
Subject: [PATCH 7/9] PCI: imx6: Simplify switch-case logic by involve
 init_phy callback
In-Reply-To: <20231206155903.566194-8-Frank.Li@nxp.com>
References: <20231206155903.566194-8-Frank.Li@nxp.com>
Message-ID: <202312071732.l6LvuDdy-lkp@intel.com>

Hi Frank,

kernel test robot noticed the following build errors:

[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus linus/master v6.7-rc4 next-20231207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Frank-Li/PCI-imx6-Simplify-clock-handling-by-using-HAS_CLK_-bitmask/20231207-000209
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:    https://lore.kernel.org/r/20231206155903.566194-8-Frank.Li%40nxp.com
patch subject: [PATCH 7/9] PCI: imx6: Simplify switch-case logic by involve init_phy callback
config: powerpc-randconfig-002-20231207 (https://download.01.org/0day-ci/archive/20231207/202312071732.l6LvuDdy-lkp at intel.com/config)
compiler: powerpc-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231207/202312071732.l6LvuDdy-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312071732.l6LvuDdy-lkp at intel.com/

All errors (new ones prefixed by >>):

   powerpc-linux-ld: drivers/pci/controller/dwc/pci-imx6.o: in function `imx6_pcie_host_init':
>> pci-imx6.c:(.text.imx6_pcie_host_init+0x120): undefined reference to `__ffsdi2'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From krzysztof.kozlowski at linaro.org  Thu Dec  7 01:37:02 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 10:37:02 +0100
Subject: [PATCH] dt-bindings: PCI: dwc: rockchip: document optional pcie
 reference clock input
In-Reply-To: <20231206145041.667900-1-heiko@sntech.de>
References: <20231206145041.667900-1-heiko@sntech.de>
Message-ID: <c012c052-6511-4c9e-85ee-5caeeb81ea25@linaro.org>

On 06/12/2023 15:50, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner at cherry.de>
> 
> On some boards the 100MHz PCIe reference clock to both controller and
> devices is controllable. Add that clock to the list of clocks.
> 
> The clock is optional, so the minItems stays the same.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From robin.murphy at arm.com  Thu Dec  7 01:43:10 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 7 Dec 2023 09:43:10 +0000
Subject: [PATCH 5/5] perf/arm_cspmu: Add devicetree support
In-Reply-To: <b7905a93-e4c-b6a6-d584-389131f4276@os.amperecomputing.com>
References: <cover.1701793996.git.robin.murphy@arm.com>
 <7000cdf3a22afe684793863e81a1d96bbddb5db1.1701793996.git.robin.murphy@arm.com>
 <b7905a93-e4c-b6a6-d584-389131f4276@os.amperecomputing.com>
Message-ID: <23c9fc1e-dedd-4f27-8d84-3839b23c832d@arm.com>

On 2023-12-06 11:43 pm, Ilkka Koskinen wrote:
> 
> Hi Robin,
> 
> On Tue, 5 Dec 2023, Robin Murphy wrote:
>> Hook up devicetree probing support. For now let's hope that people
>> implement PMIIDR properly and we don't need an override mechanism.
>>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> ---
>> drivers/perf/arm_cspmu/arm_cspmu.c | 71 +++++++++++++++++++++++-------
>> 1 file changed, 56 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c 
>> b/drivers/perf/arm_cspmu/arm_cspmu.c
>> index b64de4d800c7..80b5fc417ee3 100644
>> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
>> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
>> @@ -27,6 +27,7 @@
>> #include <linux/io-64-nonatomic-lo-hi.h>
>> #include <linux/module.h>
>> #include <linux/mutex.h>
>> +#include <linux/of.h>
>> #include <linux/perf_event.h>
>> #include <linux/platform_device.h>
>>
>> @@ -309,6 +310,10 @@ static const char *arm_cspmu_get_name(const 
>> struct arm_cspmu *cspmu)
>> ????static atomic_t pmu_idx[ACPI_APMT_NODE_TYPE_COUNT] = { 0 };
>>
>> ????dev = cspmu->dev;
>> +??? if (!has_acpi_companion(dev))
> 
> Am I missing something since this doesn't work on top of v6.7-rc4?
> The problem I see is that has_acpi_companion() calls 
> is_acpi_device_node(), which compares whether
> 
>  ????fwnode->ops == &acpi_device_fwnode_ops;
> 
> However, the acpi/apmt code allocates fwnode by calling
> acpi_alloc_fwnode_static(), which assigns &acpi_static_fwnode_ops
> to ops.

Ah, I hadn't got as far as considering that has_acpi_companion() might 
only work for namespace devices, but it makes sense now that you point 
it out. I should have clarified that I don't have any suitable ACPI 
system to test this on, and have only been able to verify basic DT 
probing on an FPGA.

> I wonder though, if is_acpi_device_node() should check the static 
> variant too? :/

Thanks for the tip, I'll look into that and try to come up with 
something that works for a v2 (at worst there's always the traditional 
assumption that !dev->of_node implies ACPI)

Cheers,
Robin.

> 
> Cheers, Ilkka
> 
>> +??????? return devm_kasprintf(dev, GFP_KERNEL, PMUNAME "_%u",
>> +????????????????????? atomic_fetch_inc(&pmu_idx[0]));
>> +
>> ????apmt_node = arm_cspmu_apmt_node(dev);
>> ????pmu_type = apmt_node->type;
>>
>> @@ -406,7 +411,6 @@ static struct arm_cspmu_impl_match 
>> *arm_cspmu_impl_match_get(u32 pmiidr)
>> static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
>> {
>> ????int ret = 0;
>> -??? struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(cspmu->dev);
>> ????struct arm_cspmu_impl_match *match;
>>
>> ????/* Start with a default PMU implementation */
>> @@ -425,8 +429,12 @@ static int arm_cspmu_init_impl_ops(struct 
>> arm_cspmu *cspmu)
>> ????};
>>
>> ????/* Firmware may override implementer/product ID from PMIIDR */
>> -??? if (apmt_node->impl_id)
>> -??????? cspmu->impl.pmiidr = apmt_node->impl_id;
>> +??? if (has_acpi_companion(cspmu->dev)) {
>> +??????? struct acpi_apmt_node *apmt_node = 
>> arm_cspmu_apmt_node(cspmu->dev);
>> +
>> +??????? if (apmt_node->impl_id)
>> +??????????? cspmu->impl.pmiidr = apmt_node->impl_id;
>> +??? }
>>
>> ????/* Find implementer specific attribute ops. */
>> ????match = arm_cspmu_impl_match_get(cspmu->impl.pmiidr);
>> @@ -928,7 +936,6 @@ static void arm_cspmu_read(struct perf_event *event)
>>
>> static struct arm_cspmu *arm_cspmu_alloc(struct platform_device *pdev)
>> {
>> -??? struct acpi_apmt_node *apmt_node;
>> ????struct arm_cspmu *cspmu;
>> ????struct device *dev = &pdev->dev;
>>
>> @@ -939,8 +946,13 @@ static struct arm_cspmu *arm_cspmu_alloc(struct 
>> platform_device *pdev)
>> ????cspmu->dev = dev;
>> ????platform_set_drvdata(pdev, cspmu);
>>
>> -??? apmt_node = arm_cspmu_apmt_node(dev);
>> -??? cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
>> +??? if (has_acpi_companion(dev)) {
>> +??????? struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(dev);
>> +
>> +??????? cspmu->has_atomic_dword = apmt_node->flags & 
>> ACPI_APMT_FLAGS_ATOMIC;
>> +??? } else {
>> +??????? cspmu->has_atomic_dword = device_property_read_bool(dev, 
>> "arm,64-bit-atomic");
>> +??? }
>>
>> ????return cspmu;
>> }
>> @@ -1133,11 +1145,6 @@ static int arm_cspmu_acpi_get_cpus(struct 
>> arm_cspmu *cspmu)
>> ??????? }
>> ????}
>>
>> -??? if (cpumask_empty(&cspmu->associated_cpus)) {
>> -??????? dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
>> -??????? return -ENODEV;
>> -??? }
>> -
>> ????return 0;
>> }
>> #else
>> @@ -1147,9 +1154,36 @@ static int arm_cspmu_acpi_get_cpus(struct 
>> arm_cspmu *cspmu)
>> }
>> #endif
>>
>> +static int arm_cspmu_of_get_cpus(struct arm_cspmu *cspmu)
>> +{
>> +??? struct of_phandle_iterator it;
>> +??? int ret, cpu;
>> +
>> +??? of_for_each_phandle(&it, ret, cspmu->dev->of_node, "cpus", NULL, 
>> 0) {
>> +??????? cpu = of_cpu_node_to_id(it.node);
>> +??????? if (cpu < 0)
>> +??????????? continue;
>> +??????? cpumask_set_cpu(cpu, &cspmu->associated_cpus);
>> +??? }
>> +??? return ret;
>> +}
>> +
>> static int arm_cspmu_get_cpus(struct arm_cspmu *cspmu)
>> {
>> -??? return arm_cspmu_acpi_get_cpus(cspmu);
>> +??? int ret = 0;
>> +
>> +??? if (has_acpi_companion(cspmu->dev))
>> +??????? ret = arm_cspmu_acpi_get_cpus(cspmu);
>> +??? else if (of_property_present(cspmu->dev->of_node, "cpus"))
>> +??????? ret = arm_cspmu_of_get_cpus(cspmu);
>> +??? else
>> +??????? cpumask_copy(&cspmu->associated_cpus, cpu_possible_mask);
>> +
>> +??? if (!ret && cpumask_empty(&cspmu->associated_cpus)) {
>> +??????? dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
>> +??????? ret = -ENODEV;
>> +??? }
>> +??? return ret;
>> }
>>
>> static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
>> @@ -1246,11 +1280,18 @@ static const struct platform_device_id 
>> arm_cspmu_id[] = {
>> };
>> MODULE_DEVICE_TABLE(platform, arm_cspmu_id);
>>
>> +static const struct of_device_id arm_cspmu_of_match[] = {
>> +??? { .compatible = "arm,coresight-pmu" },
>> +??? {}
>> +};
>> +MODULE_DEVICE_TABLE(of, arm_cspmu_of_match);
>> +
>> static struct platform_driver arm_cspmu_driver = {
>> ????.driver = {
>> -??????????? .name = DRVNAME,
>> -??????????? .suppress_bind_attrs = true,
>> -??????? },
>> +??????? .name = DRVNAME,
>> +??????? .of_match_table = arm_cspmu_of_match,
>> +??????? .suppress_bind_attrs = true,
>> +??? },
>> ????.probe = arm_cspmu_device_probe,
>> ????.remove = arm_cspmu_device_remove,
>> ????.id_table = arm_cspmu_id,
>> -- 
>> 2.39.2.101.g768bb238c484.dirty
>>
>>


From mani at kernel.org  Thu Dec  7 01:43:57 2023
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Thu, 7 Dec 2023 15:13:57 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <effb603e-ca7a-4f24-9783-4d62790165ae@acm.org>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
 <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>
 <5e7c5c75-cb5f-4afe-9d57-b0cab01a6f26@acm.org>
 <b9373252-710c-4a54-95cc-046314796960@quicinc.com>
 <20231206153242.GI12802@thinkpad>
 <effb603e-ca7a-4f24-9783-4d62790165ae@acm.org>
Message-ID: <20231207094357.GI2932@thinkpad>

On Wed, Dec 06, 2023 at 03:02:04PM -1000, Bart Van Assche wrote:
> On 12/6/23 05:32, Manivannan Sadhasivam wrote:
> > On Wed, Dec 06, 2023 at 07:32:54PM +0530, Naresh Maramaina wrote:
> > > On 12/5/2023 10:41 PM, Bart Van Assche wrote:
> > > > On 12/4/23 21:58, Naresh Maramaina wrote:
> > > > > On 12/5/2023 12:30 AM, Bart Van Assche wrote:
> > > > > > On 12/4/23 06:30, Maramaina Naresh wrote:
> > > > > > > +??? /* This capability allows the host controller driver to
> > > > > > > use the PM QoS
> > > > > > > +???? * feature.
> > > > > > > +???? */
> > > > > > > +??? UFSHCD_CAP_PM_QOS??????????????? = 1 << 13,
> > > > > > >  ? };
> > > > > > 
> > > > > > Why does it depend on the host driver whether or not PM QoS is
> > > > > > enabled? Why isn't it enabled unconditionally?
> > > > > 
> > > > > For some platform vendors power KPI might be more important than
> > > > > random io KPI. Hence this flag is disabled by default and can be
> > > > > enabled based on platform requirement.
> > > > 
> > > > How about leaving this flag out unless if a host vendor asks explicitly
> > > > for this flag?
> > > 
> > > IMHO, instead of completely removing this flag, how about having
> > > flag like "UFSHCD_CAP_DISABLE_PM_QOS" which will make PMQOS enable
> > > by default and if some host vendor wants to disable it explicitly,
> > > they can enable that flag.
> > > Please let me know your opinion.
> 
> That would result in a flag that is tested but that is never set by
> upstream code. I'm not sure that's acceptable.
> 

Agree. The flag shouldn't be introduced if there are no users.

> > If a vendor wants to disable this feature, then the driver has to be modified.
> > That won't be very convenient. So either this has to be configured through sysfs
> > or Kconfig if flexibility matters.
> 
> Kconfig sounds worse to me because changing any Kconfig flag requires a
> modification of the Android GKI kernel.
> 

Hmm, ok. Then I think we can have a sysfs hook to toggle the enable switch.

- Mani

> Thanks,
> 
> Bart.

-- 
????????? ????????


From linus.walleij at linaro.org  Thu Dec  7 01:50:29 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 7 Dec 2023 10:50:29 +0100
Subject: [PATCH v4 00/23] pinctrl: Convert struct group_desc to use struct pingroup
In-Reply-To: <ZW3m-KDhs39i0E5n@smile.fi.intel.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <CACRpkdZhpXcx2FZYKM69j3x4dP5Nu-=3sXW+BQAw3k6c5aRrWw@mail.gmail.com> <ZW3m-KDhs39i0E5n@smile.fi.intel.com>
Message-ID: <CACRpkdaDDJfDznGZE1OGNt0Rc6Wbh0-0suu6PgL+veJea9rBRQ@mail.gmail.com>

On Mon, Dec 4, 2023 at 3:49?PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
> On Mon, Dec 04, 2023 at 03:38:43PM +0100, Linus Walleij wrote:
> > Hi Andy,
> >
> > due to compile errors on arm32 and arm64 I had to drop most of the
> > patches again but I kept the preparatory patches so your
> > patch stack don't need to be so deep.
>
> Thank you!
>
> ...
>
> > >   pinctrl: core: Make pins const unsigned int pointer in struct
> > >     group_desc
> > >   pinctrl: equilibrium: Convert to use struct pingroup
> > >   pinctrl: keembay: Convert to use struct pingroup
> > >   pinctrl: nuvoton: Convert to use struct pingroup and
> > >     PINCTRL_PINGROUP()
>
> Hmm... Why these to be dropped?

I couldn't tell apart which ones could cross depend on the others,
simple as that...

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Dec  7 01:56:50 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 7 Dec 2023 10:56:50 +0100
Subject: [PATCH 2/2] pinctrl: stm32: fix GPIO level interrupts
In-Reply-To: <20231204203357.2897008-3-ben.wolsieffer@hefring.com>
References: <20231204203357.2897008-1-ben.wolsieffer@hefring.com> <20231204203357.2897008-3-ben.wolsieffer@hefring.com>
Message-ID: <CACRpkdZKjcE5yMF0=E+4BRTEmrShSqFzCcyH8Rug7u7kOotUQQ@mail.gmail.com>

On Mon, Dec 4, 2023 at 9:35?PM Ben Wolsieffer
<ben.wolsieffer at hefring.com> wrote:

> The STM32 doesn't support GPIO level interrupts in hardware, so the
> driver tries to emulate them using edge interrupts, by retriggering the
> interrupt if necessary based on the pin state after the handler
> finishes.
>
> Currently, this functionality does not work because the irqchip uses
> handle_edge_irq(), which doesn't run the irq_eoi() or irq_unmask()
> callbacks after handling the interrupt. This patch fixes this by using
> handle_level_irq() for level interrupts, which causes irq_unmask() to be
> called to retrigger the interrupt.
>
> Signed-off-by: Ben Wolsieffer <ben.wolsieffer at hefring.com>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Marc Z can apply all the patches to the irq tree once he's happy
with the solution.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Dec  7 01:59:24 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 7 Dec 2023 10:59:24 +0100
Subject: [PATCH 2/2] pinctrl: stm32: fix GPIO level interrupts
In-Reply-To: <CACRpkdZKjcE5yMF0=E+4BRTEmrShSqFzCcyH8Rug7u7kOotUQQ@mail.gmail.com>
References: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>
 <20231204203357.2897008-3-ben.wolsieffer@hefring.com> <CACRpkdZKjcE5yMF0=E+4BRTEmrShSqFzCcyH8Rug7u7kOotUQQ@mail.gmail.com>
Message-ID: <CACRpkdaqZ4+oefozT863YbsY7e1kVJvSMBuiFmwhKSeXtPsE2w@mail.gmail.com>

On Thu, Dec 7, 2023 at 10:56?AM Linus Walleij <linus.walleij at linaro.org> wrote:
> On Mon, Dec 4, 2023 at 9:35?PM Ben Wolsieffer

> <ben.wolsieffer at hefring.com> wrote:
>
> > The STM32 doesn't support GPIO level interrupts in hardware, so the
> > driver tries to emulate them using edge interrupts, by retriggering the
> > interrupt if necessary based on the pin state after the handler
> > finishes.
> >
> > Currently, this functionality does not work because the irqchip uses
> > handle_edge_irq(), which doesn't run the irq_eoi() or irq_unmask()
> > callbacks after handling the interrupt. This patch fixes this by using
> > handle_level_irq() for level interrupts, which causes irq_unmask() to be
> > called to retrigger the interrupt.
> >
> > Signed-off-by: Ben Wolsieffer <ben.wolsieffer at hefring.com>
>
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
>
> Marc Z can apply all the patches to the irq tree once he's happy
> with the solution.

I see Marc stopped doing irq_chips, so tglx then!

Yours,
Linus Walleij


From festevam at gmail.com  Thu Dec  7 02:03:06 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 07:03:06 -0300
Subject: [PATCH RESEND v2] dt-bindings: nvmem: mxs-ocotp: Document fsl,ocotp
Message-ID: <20231207100306.2492505-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Both imx23.dtsi and imx28.dtsi describe the OCOTP nodes in
the format:

compatible = "fsl,imx28-ocotp", "fsl,ocotp";

Document the "fsl,ocotp" entry to fix the following schema
warning:

efuse at 8002c000: compatible: ['fsl,imx23-ocotp', 'fsl,ocotp'] is too long
from schema $id: http://devicetree.org/schemas/nvmem/mxs-ocotp.yaml#

Fixes: 2c504460f502 ("dt-bindings: nvmem: Convert MXS OCOTP to json-schema")
Signed-off-by: Fabio Estevam <festevam at denx.de>
---
Resending it as it was sent two months ago and it was still not applied.

Changes since v1:
- Added Fixes tag. (Conor)

 Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
index f43186f98607..d9287be89877 100644
--- a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
@@ -15,9 +15,11 @@ allOf:
 
 properties:
   compatible:
-    enum:
-      - fsl,imx23-ocotp
-      - fsl,imx28-ocotp
+    items:
+      - enum:
+          - fsl,imx23-ocotp
+          - fsl,imx28-ocotp
+      - const: fsl,ocotp
 
   reg:
     maxItems: 1
@@ -35,7 +37,7 @@ unevaluatedProperties: false
 examples:
   - |
     ocotp: efuse at 8002c000 {
-        compatible = "fsl,imx28-ocotp";
+        compatible = "fsl,imx28-ocotp", "fsl,ocotp";
         #address-cells = <1>;
         #size-cells = <1>;
         reg = <0x8002c000 0x2000>;
-- 
2.34.1



From festevam at gmail.com  Thu Dec  7 02:12:12 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 07:12:12 -0300
Subject: [PATCH] ARM: dts: imx23-sansa: Use preferred i2c-gpios properties
Message-ID: <20231207101212.2495648-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The 'gpios' property to describe the SDA and SCL GPIOs is considered
deprecated according to i2c-gpio.yaml.

Switch to the preferred 'sda-gpios' and 'scl-gpios' properties.

This fixes the following schema warnings:

imx23-sansa.dtb: i2c-0: 'sda-gpios' is a required property
	from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml#
imx23-sansa.dtb: i2c-0: 'scl-gpios' is a required property
	from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/mxs/imx23-sansa.dts | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/mxs/imx23-sansa.dts b/arch/arm/boot/dts/nxp/mxs/imx23-sansa.dts
index 636cf09a2b37..b23e7ada9c80 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx23-sansa.dts
+++ b/arch/arm/boot/dts/nxp/mxs/imx23-sansa.dts
@@ -175,10 +175,8 @@ i2c-0 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "i2c-gpio";
-		gpios = <
-			&gpio1 24 0		/* SDA */
-			&gpio1 22 0		/* SCL */
-		>;
+		sda-gpios = <&gpio1 24 0>;
+		scl-gpios = <&gpio1 22 0>;
 		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
 	};
 
@@ -186,10 +184,8 @@ i2c-1 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "i2c-gpio";
-		gpios = <
-			&gpio0 31 0		/* SDA */
-			&gpio0 30 0		/* SCL */
-		>;
+		sda-gpios = <&gpio0 31 0>;
+		scl-gpios = <&gpio0 30 0>;
 		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
 
 		touch: touch at 20 {
-- 
2.34.1



From laurent.pinchart at ideasonboard.com  Thu Dec  7 02:14:00 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 12:14:00 +0200
Subject: [PATCH 1/1] media: nxp: imx8-isi-debug: Add missing registers to
 debugfs output
In-Reply-To: <2915417.e9J7NaK4W3@steina-w>
References: <20231206094401.491100-1-alexander.stein@ew.tq-group.com>
 <20231206223636.GE29417@pendragon.ideasonboard.com>
 <2915417.e9J7NaK4W3@steina-w>
Message-ID: <20231207101400.GB3681@pendragon.ideasonboard.com>

Hi Alexander,

On Thu, Dec 07, 2023 at 08:52:46AM +0100, Alexander Stein wrote:
> Am Mittwoch, 6. Dezember 2023, 23:36:36 CET schrieb Laurent Pinchart:
> > On Wed, Dec 06, 2023 at 10:44:01AM +0100, Alexander Stein wrote:
> > > The extended address registers are missing in the debug output register
> > > list. Add them.
> > > 
> > > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> > > ---
> > > 
> > >  drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c index
> > > 6709ab7ea1f3..3ac5685d6cc1 100644
> > > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > @@ -66,6 +66,13 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
> > >  		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF2_ADDR_V),
> > >  		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
> > >  		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
> > > 
> > > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),
> > 
> > Those registers only exist in the i.MX8MP. The i.MX8MN referenece manual
> > lists them as reserved and indicates they read as 0's, so it should be
> > safe.  The i.MX93 reference manual, however, doesn't list those
> > registers at all, so accessing them may lead to issues.
> > 
> > How what platform(s) have you tested this patch ?
> 
> Ah, you are right. That's something I didn't take into account. Up until now I 
> only tested this on i.MX8MP. I hope I can test this on i.MX8MN and i.MX93 
> soon.
> Otherwise dumping these registers can depend on pdata->has_36bit_dma just to 
> be safe.

That sounds like a good solution to me. Will you do so in a v2 ?

> > >  	};
> > >  	
> > >  	struct mxc_isi_pipe *pipe = m->private;

-- 
Regards,

Laurent Pinchart


From lpieralisi at kernel.org  Thu Dec  7 02:13:52 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Thu, 7 Dec 2023 11:13:52 +0100
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231206164802.GT2692119@nvidia.com>
References: <ZW9OSe8Z9gAmM7My@arm.com>
 <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
 <ZXCJ3pVbKuHJ3LTz@arm.com>
 <20231206150556.GQ2692119@nvidia.com>
 <ZXCQrTbf6q0BIhSw@lpieralisi>
 <20231206153809.GS2692119@nvidia.com>
 <ZXCf_e-ACqrj6VrV@arm.com>
 <20231206164802.GT2692119@nvidia.com>
Message-ID: <ZXGa4A6rfxLtkTB2@lpieralisi>

On Wed, Dec 06, 2023 at 12:48:02PM -0400, Jason Gunthorpe wrote:
> On Wed, Dec 06, 2023 at 04:23:25PM +0000, Catalin Marinas wrote:
> > On Wed, Dec 06, 2023 at 11:38:09AM -0400, Jason Gunthorpe wrote:
> > > On Wed, Dec 06, 2023 at 04:18:05PM +0100, Lorenzo Pieralisi wrote:
> > > > On Wed, Dec 06, 2023 at 11:05:56AM -0400, Jason Gunthorpe wrote:
> > > > > On Wed, Dec 06, 2023 at 02:49:02PM +0000, Catalin Marinas wrote:
> > > > > > BTW, on those Mellanox devices that require different attributes within
> > > > > > a BAR, do they have a problem with speculative reads causing
> > > > > > side-effects? 
> > > > > 
> > > > > Yes. We definitely have had that problem in the past on older
> > > > > devices. VFIO must map the BAR using pgprot_device/noncached() into
> > > > > the VMM, no other choice is functionally OK.
> > > > 
> > > > Were those BARs tagged as prefetchable or non-prefetchable ? I assume the
> > > > latter but please let me know if I am guessing wrong.
> > > 
> > > I don't know it was quite old HW. Probably.
> > > 
> > > Just because a BAR is not marked as prefetchable doesn't mean that the
> > > device can't use NORMAL_NC on subsets of it.
> > 
> > What about the other way around - would we have a prefetchable BAR that
> > has portions which are unprefetchable?
> 
> I would say possibly.
> 
> Prefetch is a dead concept in PCIe, it was obsoleted in PCI-X about 20
> years ago. No PCIe system has ever done prefetch.
> 
> There is a strong incentive to mark BAR's as prefetchable because it
> allows 64 bit addressing in configurations with bridges.

If by strong incentive you mean the "Additional guidance on the
Prefetchable Bit in Memory Space BARs" in the PCI express specifications,
I think it has been removed from the spec and the criteria that had to be
met to implement it were basically impossible to fulfill on ARM systems,
it did not make any sense in the first place.

I agree on your statement related to the prefetchable concept but I
believe that a prefetchable BAR containing regions that have
read side-effects is essentially a borked design unless at system level
speculative reads are prevented (as far as I understand the
implementation note this could only be an endpoint integrated in a
system where read speculation can't just happen (?)).

Long story short: a PCIe card/device that can be plugged on any PCIe
compliant system (x86, ARM or whatever) should not mark a
BAR region with memory read side-effects as prefetchable, either
that or I don't understand what the implementation note above
was all about.

AFAIK the prefetchable concept in PCIe is likely to be scrapped
altogether in the not too distant future.

Anyway, that was just for completeness (and to shed light
on the BAR prefetchable bit usage).

Lorenzo


From festevam at gmail.com  Thu Dec  7 02:16:59 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 07:16:59 -0300
Subject: [PATCH v3] dt-bindings: nvmem: mxs-ocotp: Document fsl,ocotp
Message-ID: <20231207101659.2496154-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Both imx23.dtsi and imx28.dtsi describe the OCOTP nodes in
the format:

compatible = "fsl,imx28-ocotp", "fsl,ocotp";

Document the "fsl,ocotp" entry to fix the following schema
warning:

efuse at 8002c000: compatible: ['fsl,imx23-ocotp', 'fsl,ocotp'] is too long
from schema $id: http://devicetree.org/schemas/nvmem/mxs-ocotp.yaml#

Fixes: 2c504460f502 ("dt-bindings: nvmem: Convert MXS OCOTP to json-schema")
Signed-off-by: Fabio Estevam <festevam at denx.de>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Added Conor's Acked-by tag.

Changes since v1:
- Added Fixes tag. (Conor)

 Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
index f43186f98607..d9287be89877 100644
--- a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
@@ -15,9 +15,11 @@ allOf:
 
 properties:
   compatible:
-    enum:
-      - fsl,imx23-ocotp
-      - fsl,imx28-ocotp
+    items:
+      - enum:
+          - fsl,imx23-ocotp
+          - fsl,imx28-ocotp
+      - const: fsl,ocotp
 
   reg:
     maxItems: 1
@@ -35,7 +37,7 @@ unevaluatedProperties: false
 examples:
   - |
     ocotp: efuse at 8002c000 {
-        compatible = "fsl,imx28-ocotp";
+        compatible = "fsl,imx28-ocotp", "fsl,ocotp";
         #address-cells = <1>;
         #size-cells = <1>;
         reg = <0x8002c000 0x2000>;
-- 
2.34.1



From laurent.pinchart at ideasonboard.com  Thu Dec  7 02:25:05 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 12:25:05 +0200
Subject: [PATCH 1/2] media: dt-bindings: media: i2c: Document GC08A3
 bindings
In-Reply-To: <20231123-magical-rupture-83251807e995@spud>
References: <20231123115104.32094-1-zhi.mao@mediatek.com>
 <20231123115104.32094-2-zhi.mao@mediatek.com>
 <20231123-magical-rupture-83251807e995@spud>
Message-ID: <20231207102505.GI29417@pendragon.ideasonboard.com>

On Thu, Nov 23, 2023 at 05:31:35PM +0000, Conor Dooley wrote:
> On Thu, Nov 23, 2023 at 07:51:03PM +0800, Zhi Mao wrote:
> > Add YAML device tree binding for GC08A3 CMOS image sensor, 
> > and the relevant MAINTAINERS entries.
> > 
> > Signed-off-by: Zhi Mao <zhi.mao at mediatek.com>
> 
> Please test your bindings.
> 
> > ---
> >  .../bindings/media/i2c/galaxycore,gc08a3.yaml | 128 ++++++++++++++++++
> >  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
> >  2 files changed, 130 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
> > new file mode 100644
> > index 000000000000..089ea321da91
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
> > @@ -0,0 +1,128 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/galaxycore,gc08a3.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: GalaxyCore gc08a3 1/4" 8M Pixel MIPI CSI-2 sensor
> > +
> > +maintainers:
> > +  - Zhi Mao <zhi.mao at mediatek.com>
> > +
> > +description: |-
> 
> The |- is not needed, you have no formatting to preserve.
> 
> > +  The gc08a3 is a raw image sensor with an MIPI CSI-2 image data
> > +  interface and CCI (I2C compatible) control bus. The output format
> > +  is raw Bayer.
> > +
> > +properties:
> > +  compatible:
> > +    const: GalaxyCore,gc08a3
> 
> Please remove the capitals.
> 
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  clocks:
> > +    items:
> > +      - description: Reference to the mclk clock.
> 
> Pointless, just use maxItems: 1.
> 
> > +
> > +  assigned-clocks:
> > +    maxItems: 1
> > +
> > +  assigned-clock-rates:
> > +    maxItems: 1
> > +
> > +  enable-gpios:
> > +    description: Reference to the GPIO connected to the RESETB pin. Active low.
> > +    maxItems: 1
> > +

If that's the RESETB pin, it should be reset-gpios.

> > +  vddio-supply:
> > +    description: Definition of the regulator used for the VDDIO power supply.
> > +
> > +  vdda-supply:
> > +    description: Definition of the regulator used for the VDDA power supply.
> > +
> > +  vddd-supply:
> > +    description: Definition of the regulator used for the VDDD power supply.
> 
> These descriptions can all be replaced with "foo-supply: true" IMO.
> 
> > +  port:
> > +    $ref: /schemas/graph.yaml#/$defs/port-base
> > +    unevaluatedProperties: false
> > +
> > +    properties:
> > +      endpoint:
> > +        $ref: /schemas/media/video-interfaces.yaml#
> > +        unevaluatedProperties: false
> > +
> > +        properties:
> > +          data-lanes:
> > +            oneOf:
> > +              - items:
> > +                  - const: 1
> > +                  - const: 2
> > +                  - const: 3
> > +                  - const: 4
> > +              - items:
> > +                  - const: 1
> > +                  - const: 2
> > +
> > +          link-frequencies: true
> > +
> > +        required:
> > +          - data-lanes
> > +          - link-frequencies
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - clocks
> 
> > +  - assigned-clocks
> > +  - assigned-clock-rates
> 
> Why are these required?
> 
> > +  - vddio-supply
> > +  - vdda-supply
> > +  - vddd-supply
> > +  - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/gpio/gpio.h>
> > +
> > +    i2c {
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +
> > +        sensor0 at 2 {
> > +            status = "okay";
> > +            compatible = "GalaxyCore,gc08a3";
> > +            reg = <0x31>;
> > +
> > +            clocks = <&topckgen CLK_TOP_CAMTG>,
> > +                <&topckgen CLK_TOP_UNIVPLL_192M_D8>;
> > +            clock-names = "xvclk", "freq_mux";
> > +            clock-frequency = <24000000>;
> > +
> > +            assigned-clocks = <&topckgen CLK_TOP_CAMTG>,
> > +                    <&topckgen CLK_TOP_UNIVPLL_192M_D8>;
> > +            assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_192M_D8>;
> > +            assigned-clock-rates = <0>, <24000000>;
> > +
> > +            enable-gpios = <&pio 19 GPIO_ACTIVE_HIGH>;
> > +
> > +            pinctrl-names = "default";
> > +            pinctrl-0 = <&camera_pins_cam0>;
> > +
> > +            avdd-supply = <&mt6359_vfe28_ldo_reg>;
> > +
> > +            port {
> > +                sensor0_out_2: endpoint {
> > +                    data-lanes = <1 2 3 4>;
> > +                    link-frequencies = /bits/ 64 <336000000 207000000>;
> > +                    remote-endpoint = <&seninf_csi_port_0_in_2>;
> > +                };
> > +            };
> > +        };
> > +
> > +    };
> > +
> > +...
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > index 309b94c328c8..a0bbec0bfee2 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > @@ -502,6 +502,8 @@ patternProperties:
> >      description: Fujitsu Ltd.
> >    "^fxtec,.*":
> >      description: FX Technology Ltd.
> > +  "^GalaxyCore,.*":
> > +    description: GalaxyCore Inc.
> >    "^gardena,.*":
> >      description: GARDENA GmbH
> >    "^gateway,.*":

-- 
Regards,

Laurent Pinchart


From festevam at gmail.com  Thu Dec  7 02:26:31 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 07:26:31 -0300
Subject: [PATCH] ARM: dts: imx23/28: Fix the DMA controller node name
Message-ID: <20231207102631.2498659-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per fsl,mxs-dma.yaml, the node name should be 'dma-controller'.

Change it to fix the following dt-schema warning.

imx28-apf28.dtb: dma-apbx at 80024000: $nodename:0: 'dma-apbx at 80024000' does not match '^dma-controller(@.*)?$'
	from schema $id: http://devicetree.org/schemas/dma/fsl,mxs-dma.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/mxs/imx23.dtsi | 2 +-
 arch/arm/boot/dts/nxp/mxs/imx28.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/mxs/imx23.dtsi b/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
index 7d82c03ef402..0309592af1e1 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
+++ b/arch/arm/boot/dts/nxp/mxs/imx23.dtsi
@@ -412,7 +412,7 @@ emi at 80020000 {
 				status = "disabled";
 			};
 
-			dma_apbx: dma-apbx at 80024000 {
+			dma_apbx: dma-controller at 80024000 {
 				compatible = "fsl,imx23-dma-apbx";
 				reg = <0x80024000 0x2000>;
 				interrupts = <7>, <5>, <9>, <26>,
diff --git a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
index 9817ef7c0880..4817fba2d938 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
+++ b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
@@ -990,7 +990,7 @@ etm: etm at 80022000 {
 				status = "disabled";
 			};
 
-			dma_apbx: dma-apbx at 80024000 {
+			dma_apbx: dma-controller at 80024000 {
 				compatible = "fsl,imx28-dma-apbx";
 				reg = <0x80024000 0x2000>;
 				interrupts = <78>, <79>, <66>, <0>,
-- 
2.34.1



From quic_nitirawa at quicinc.com  Thu Dec  7 02:26:43 2023
From: quic_nitirawa at quicinc.com (Nitin Rawat)
Date: Thu, 7 Dec 2023 15:56:43 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231207094357.GI2932@thinkpad>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
 <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>
 <5e7c5c75-cb5f-4afe-9d57-b0cab01a6f26@acm.org>
 <b9373252-710c-4a54-95cc-046314796960@quicinc.com>
 <20231206153242.GI12802@thinkpad>
 <effb603e-ca7a-4f24-9783-4d62790165ae@acm.org>
 <20231207094357.GI2932@thinkpad>
Message-ID: <286b6f8a-c634-19ed-cf53-276cfe05d03f@quicinc.com>



On 12/7/2023 3:13 PM, Manivannan Sadhasivam wrote:
> On Wed, Dec 06, 2023 at 03:02:04PM -1000, Bart Van Assche wrote:
>> On 12/6/23 05:32, Manivannan Sadhasivam wrote:
>>> On Wed, Dec 06, 2023 at 07:32:54PM +0530, Naresh Maramaina wrote:
>>>> On 12/5/2023 10:41 PM, Bart Van Assche wrote:
>>>>> On 12/4/23 21:58, Naresh Maramaina wrote:
>>>>>> On 12/5/2023 12:30 AM, Bart Van Assche wrote:
>>>>>>> On 12/4/23 06:30, Maramaina Naresh wrote:
>>>>>>>> +??? /* This capability allows the host controller driver to
>>>>>>>> use the PM QoS
>>>>>>>> +???? * feature.
>>>>>>>> +???? */
>>>>>>>> +??? UFSHCD_CAP_PM_QOS??????????????? = 1 << 13,
>>>>>>>>   ? };
>>>>>>>
>>>>>>> Why does it depend on the host driver whether or not PM QoS is
>>>>>>> enabled? Why isn't it enabled unconditionally?
>>>>>>
>>>>>> For some platform vendors power KPI might be more important than
>>>>>> random io KPI. Hence this flag is disabled by default and can be
>>>>>> enabled based on platform requirement.
>>>>>
>>>>> How about leaving this flag out unless if a host vendor asks explicitly
>>>>> for this flag?
>>>>
>>>> IMHO, instead of completely removing this flag, how about having
>>>> flag like "UFSHCD_CAP_DISABLE_PM_QOS" which will make PMQOS enable
>>>> by default and if some host vendor wants to disable it explicitly,
>>>> they can enable that flag.
>>>> Please let me know your opinion.
>>
>> That would result in a flag that is tested but that is never set by
>> upstream code. I'm not sure that's acceptable.
>>
> 
> Agree. The flag shouldn't be introduced if there are no users.
> 
>>> If a vendor wants to disable this feature, then the driver has to be modified.
>>> That won't be very convenient. So either this has to be configured through sysfs
>>> or Kconfig if flexibility matters.
>>
>> Kconfig sounds worse to me because changing any Kconfig flag requires a
>> modification of the Android GKI kernel.
>>
> 
> Hmm, ok. Then I think we can have a sysfs hook to toggle the enable switch.

Hi Bart, Mani

How about keeping this feature enabled by default and having a module 
parameter to disable pmqos feature if required ?

Regards,
Nitin

> 
> - Mani
> 
>> Thanks,
>>
>> Bart.
> 



From hns at goldelico.com  Thu Dec  7 02:33:53 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Thu, 7 Dec 2023 11:33:53 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
 <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
Message-ID: <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>

Hi Maxime,

> Am 07.12.2023 um 10:20 schrieb Maxime Ripard <mripard at kernel.org>:
> 
> On Tue, Dec 05, 2023 at 02:50:08PM +0100, H. Nikolaus Schaller wrote:
>> Hi,
>> 
>>> Am 05.12.2023 um 14:29 schrieb Maxime Ripard <mripard at kernel.org>:
>>> 
>>> Hi,
>>> 
>>> On Tue, Dec 05, 2023 at 09:18:58AM +0100, H. Nikolaus Schaller wrote:
>>>>> Am 05.12.2023 um 07:57 schrieb Maxime Ripard <mripard at kernel.org>:
>>>>> 
>>>>> On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
>>>>>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
>>>>>> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
>>>>>> including register space and interrupts. Clocks, reset, and power domain
>>>>>> information is SoC specific.
>>>>>> 
>>>>>> Signed-off-by: Andrew Davis <afd at ti.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
>>>>>> 1 file changed, 63 insertions(+), 6 deletions(-)
>>>>> 
>>>>> I think it would be best to have a separate file for this, img,sgx.yaml
>>>>> maybe?
>>>> 
>>>> Why?
>>> 
>>> Because it's more convenient?
>> 
>> Is it?
> 
> It's for a separate architecture, with a separate driver, maintained out
> of tree by a separate community, with a separate set of requirements as
> evidenced by the other thread. And that's all fine in itself, but
> there's very little reason to put these two bindings in the same file.
> 
> We could also turn this around, why is it important that it's in the
> same file?

Same vendor. And enough similarity in architectures, even a logical sequence
of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
(SGX and Rogue seem to be just trade names for their architecture development).

AFAIK bindings should describe hardware and not communities or drivers
or who is currently maintaining it. The latter can change, the first not.

> 
>>>> The whole family of IMG GPUs is PowerVR and SGX and Rogue are generations 5 and 6++:
>>>> 
>>>> https://en.wikipedia.org/wiki/PowerVR
>>> 
>>> That's not really relevant as far as bindings go.
>> 
>> But maybe for choosing binding file names. Well they are machine readable
>> but sometimes humans work with them.
> 
> Heh. It's something that can also be easily grepped,

Yes, arbitrarily introduced confusion can always be resolved by search engines
and makes them necessary and more and more advanced :)

> and the name is
> never going to reflect all the compatibles in a binding so it's what
> you'll end up doing anyway. But feel free to suggest another name to
> avoid the confusion.

Well,

1. rename img,powervr.yaml => img,powervr-rogue.yaml
2. new file img,powervr-sgx.yaml

to have at least a systematic approach here.

>>> We have multiple
>>> binding files for devices of the same generation, or single bindings
>>> covering multiple generations.
>>> 
>>> The important part is that every compatible is documented. It doesn't
>>> really matter how or where.
>> 
>> Yes, and that is why I would find it more convenient to have a single
>> "img,powervr.yaml" for all variations unless it becomes filled with
>> unrelated stuff (which isn't as far as I see).
> 
> Again, hard disagree there.

I am fine with that. I just advocate to follow the KISS principle.

Same vendor, similar purpose, similar architecture => single bindings file
as Andrew proposed.

BR,
Nikolaus

From ryan.roberts at arm.com  Thu Dec  7 02:37:31 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 7 Dec 2023 10:37:31 +0000
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <5c06e3fc-e8f0-4896-ab71-2317a71e812a@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
 <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
 <5c06e3fc-e8f0-4896-ab71-2317a71e812a@arm.com>
Message-ID: <ce48e5e3-8501-45ea-bc6a-290c7d93c6be@arm.com>

On 06/12/2023 15:44, Ryan Roberts wrote:
> On 06/12/2023 14:19, Ryan Roberts wrote:
>> On 05/12/2023 16:32, David Hildenbrand wrote:
>>> On 04.12.23 11:20, Ryan Roberts wrote:
>>>> Introduce the logic to allow THP to be configured (through the new sysfs
>>>> interface we just added) to allocate large folios to back anonymous
>>>> memory, which are larger than the base page size but smaller than
>>>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>>>>
>>>> mTHP continues to be PTE-mapped, but in many cases can still provide
>>>> similar benefits to traditional PMD-sized THP: Page faults are
>>>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
>>>> the configured order), but latency spikes are much less prominent
>>>> because the size of each page isn't as huge as the PMD-sized variant and
>>>> there is less memory to clear in each page fault. The number of per-page
>>>> operations (e.g. ref counting, rmap management, lru list management) are
>>>> also significantly reduced since those ops now become per-folio.
>>>>
>>>> Some architectures also employ TLB compression mechanisms to squeeze
>>>> more entries in when a set of PTEs are virtually and physically
>>>> contiguous and approporiately aligned. In this case, TLB misses will
>>>> occur less often.
>>>>
>>>> The new behaviour is disabled by default, but can be enabled at runtime
>>>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
>>>> (see documentation in previous commit). The long term aim is to change
>>>> the default to include suitable lower orders, but there are some risks
>>>> around internal fragmentation that need to be better understood first.
>>>>
>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>
>>> In general, looks good to me, some comments/nits. And the usual "let's make sure
>>> we don't degrade order-0 and keep that as fast as possible" comment.
>>>
>>>> ---
>>>> ? include/linux/huge_mm.h |?? 6 ++-
>>>> ? mm/memory.c???????????? | 106 ++++++++++++++++++++++++++++++++++++----
>>>> ? 2 files changed, 101 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>>> index bd0eadd3befb..91a53b9835a4 100644
>>>> --- a/include/linux/huge_mm.h
>>>> +++ b/include/linux/huge_mm.h
>>>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>>>> ? #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>>>> ? ? /*
>>>> - * Mask of all large folio orders supported for anonymous THP.
>>>> + * Mask of all large folio orders supported for anonymous THP; all orders up to
>>>> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
>>>> + * (which is a limitation of the THP implementation).
>>>> ?? */
>>>> -#define THP_ORDERS_ALL_ANON??? BIT(PMD_ORDER)
>>>> +#define THP_ORDERS_ALL_ANON??? ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>>>> ? ? /*
>>>> ?? * Mask of all large folio orders supported for file THP.
>>>> diff --git a/mm/memory.c b/mm/memory.c
>>>> index 3ceeb0f45bf5..bf7e93813018 100644
>>>> --- a/mm/memory.c
>>>> +++ b/mm/memory.c
>>>> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>> ????? return ret;
>>>> ? }
>>>> ? +static bool pte_range_none(pte_t *pte, int nr_pages)
>>>> +{
>>>> +??? int i;
>>>> +
>>>> +??? for (i = 0; i < nr_pages; i++) {
>>>> +??????? if (!pte_none(ptep_get_lockless(pte + i)))
>>>> +??????????? return false;
>>>> +??? }
>>>> +
>>>> +??? return true;
>>>> +}
>>>> +
>>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>>>> +{
>>>> +??? gfp_t gfp;
>>>> +??? pte_t *pte;
>>>> +??? unsigned long addr;
>>>> +??? struct folio *folio;
>>>> +??? struct vm_area_struct *vma = vmf->vma;
>>>> +??? unsigned long orders;
>>>> +??? int order;
>>>
>>> Nit: reverse christmas tree encouraged ;)
>>
>> ACK will fix.
>>
>>>
>>>> +
>>>> +??? /*
>>>> +???? * If uffd is active for the vma we need per-page fault fidelity to
>>>> +???? * maintain the uffd semantics.
>>>> +???? */
>>>> +??? if (userfaultfd_armed(vma))
>>>
>>> Nit: unlikely()
>>
>> ACK will fix.
>>
>>>
>>>> +??????? goto fallback;
>>>> +
>>>> +??? /*
>>>> +???? * Get a list of all the (large) orders below PMD_ORDER that are enabled
>>>> +???? * for this vma. Then filter out the orders that can't be allocated over
>>>> +???? * the faulting address and still be fully contained in the vma.
>>>> +???? */
>>>> +??? orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
>>>> +????????????????????? BIT(PMD_ORDER) - 1);
>>>> +??? orders = thp_vma_suitable_orders(vma, vmf->address, orders);
>>>
>>> Comment: Both will eventually loop over all orders, correct? Could eventually be
>>> sped up in the future.
>>
>> No only thp_vma_suitable_orders() will loop. thp_vma_allowable_orders() only
>> loops if in_pf=false (it's true here).
>>
>>>
>>> Nit: the orders = ... order = ... looks like this might deserve a helper
>>> function that makes this easier to read.
>>
>> To be honest, the existing function that I've modified is a bit of a mess.
>> thp_vma_allowable_orders() calls thp_vma_suitable_orders() if we are not in a
>> page fault, because the page fault handlers already do that check themselves. It
>> would be nice to refactor the whole thing so that thp_vma_allowable_orders() is
>> a strict superset of thp_vma_suitable_orders(). Then this can just call
>> thp_vma_allowable_orders(). But that's going to start touching the PMD and PUD
>> handlers, so prefer if we leave that for a separate patch set.
>>
>>>
>>> Nit: Why call thp_vma_suitable_orders if the orders are already 0? Again, some
>>> helper might be reasonable where that is handled internally.
>>
>> Because thp_vma_suitable_orders() will handle it safely and is inline, so it
>> should just as efficient? This would go away with the refactoring described above.
>>
>>>
>>> Comment: For order-0 we'll always perform a function call to both
>>> thp_vma_allowable_orders() / thp_vma_suitable_orders(). We should perform some
>>> fast and efficient check if any <PMD THP are even enabled in the system / for
>>> this VMA, and in that case just fallback before doing more expensive checks.
>>
> 
> I just noticed I got these functions round the wrong way in my previous response:
> 
>> thp_vma_allowable_orders() is inline as you mentioned.
> 
> ^ Meant thp_vma_suitable_orders() here.
> 
>>
>> I was deliberately trying to keep all the decision logic in one place
>> (thp_vma_suitable_orders) because it's already pretty complicated. But if you
> 
> ^ Meant thp_vma_allowable_orders() here.
> 
> Sorry for the confusion.
> 
>> insist, how about this in the header:
>>
>> static inline
>> unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
>> 				       unsigned long vm_flags, bool smaps,
>> 				       bool in_pf, bool enforce_sysfs,
>> 				       unsigned long orders)
>> {
>> 	/* Optimization to check if required orders are enabled early. */
>> 	if (enforce_sysfs && vma_is_anonymous(vma)) {
>> 		unsigned long mask = READ_ONCE(huge_anon_orders_always);
>>
>> 		if (vm_flags & VM_HUGEPAGE)
>> 			mask |= READ_ONCE(huge_anon_orders_madvise);
>> 		if (hugepage_global_always() ||
>> 			((vm_flags & VM_HUGEPAGE) && hugepage_global_enabled()))
>> 			mask |= READ_ONCE(huge_anon_orders_inherit);
>>
>> 		orders &= mask;
>> 		if (!orders)
>> 			return 0;
>> 		
>> 		enforce_sysfs = false;
>> 	}
>>
>> 	return __thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf,
>> 					  enforce_sysfs, orders);
>> }
>>
>> Then the above check can be removed from __thp_vma_allowable_orders() - it will
>> still retain the `if (enforce_sysfs && !vma_is_anonymous(vma))` part.
>>
>>
>>>
>>>> +
>>>> +??? if (!orders)
>>>> +??????? goto fallback;
>>>> +
>>>> +??? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>>> +??? if (!pte)
>>>> +??????? return ERR_PTR(-EAGAIN);
>>>> +
>>>> +??? order = first_order(orders);
>>>> +??? while (orders) {
>>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>> +??????? vmf->pte = pte + pte_index(addr);
>>>> +??????? if (pte_range_none(vmf->pte, 1 << order))
>>>> +??????????? break;
>>>
>>> Comment: Likely it would make sense to scan only once and determine the "largest
>>> none range" around that address, having the largest suitable order in mind.
>>
>> Yes, that's how I used to do it, but Yu Zhou requested simplifying to this,
>> IIRC. Perhaps this an optimization opportunity for later?
>>
>>>
>>>> +??????? order = next_order(&orders, order);
>>>> +??? }
>>>> +
>>>> +??? vmf->pte = NULL;
>>>
>>> Nit: Can you elaborate why you are messing with vmf->pte here? A simple helper
>>> variable will make this code look less magical. Unless I am missing something
>>> important :)
>>
>> Gahh, I used to pass the vmf to what pte_range_none() was refactored into (an
>> approach that was suggested by Yu Zhou IIRC). But since I did some refactoring
>> based on some comments from JohnH, I see I don't need that anymore. Agreed; it
>> will be much clearer just to use a local variable. Will fix.
>>
>>>
>>>> +??? pte_unmap(pte);
>>>> +
>>>> +??? gfp = vma_thp_gfp_mask(vma);
>>>> +
>>>> +??? while (orders) {
>>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>> +??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>>> +??????? if (folio) {
>>>> +??????????? clear_huge_page(&folio->page, addr, 1 << order);
>>>> +??????????? return folio;
>>>> +??????? }
>>>> +??????? order = next_order(&orders, order);
>>>> +??? }
>>>> +
>>>
>>> Queestion: would it make sense to combine both loops? I suspect memory
>>> allocations with pte_offset_map()/kmao are problematic.
>>
>> They are both operating on separate orders; next_order() is "consuming" an order
>> by removing the current one from the orders bitfield and returning the next one.
>>
>> So the first loop starts at the highest order and keeps checking lower orders
>> until one fully fits in the VMA. And the second loop starts at the first order
>> that was found to fully fits and loops to lower orders until an allocation is
>> successful.
>>
>> So I don't see a need to combine the loops.
>>
>>>
>>>> +fallback:
>>>> +??? return vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>>> +}
>>>> +#else
>>>> +#define alloc_anon_folio(vmf) \
>>>> +??????? vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
>>>> +#endif
>>>> +
>>>> ? /*
>>>> ?? * We enter with non-exclusive mmap_lock (to exclude vma changes,
>>>> ?? * but allow concurrent faults), and pte mapped but not yet locked.
>>>> @@ -4132,6 +4210,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>> ?? */
>>>> ? static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>> ? {
>>>> +??? int i;
>>>> +??? int nr_pages = 1;
>>>> +??? unsigned long addr = vmf->address;
>>>> ????? bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
>>>> ????? struct vm_area_struct *vma = vmf->vma;
>>>> ????? struct folio *folio;
>>>
>>> Nit: reverse christmas tree :)
>>
>> ACK
>>
>>>
>>>> @@ -4176,10 +4257,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>> ????? /* Allocate our own private page. */
>>>> ????? if (unlikely(anon_vma_prepare(vma)))
>>>> ????????? goto oom;
>>>> -??? folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>>> +??? folio = alloc_anon_folio(vmf);
>>>> +??? if (IS_ERR(folio))
>>>> +??????? return 0;
>>>> ????? if (!folio)
>>>> ????????? goto oom;
>>>> ? +??? nr_pages = folio_nr_pages(folio);
>>>> +??? addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
>>>> +
>>>> ????? if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
>>>> ????????? goto oom_free_page;
>>>> ????? folio_throttle_swaprate(folio, GFP_KERNEL);
>>>> @@ -4196,12 +4282,13 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>> ????? if (vma->vm_flags & VM_WRITE)
>>>> ????????? entry = pte_mkwrite(pte_mkdirty(entry), vma);
>>>> ? -??? vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
>>>> -??????????? &vmf->ptl);
>>>> +??? vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
>>>> ????? if (!vmf->pte)
>>>> ????????? goto release;
>>>> -??? if (vmf_pte_changed(vmf)) {
>>>> -??????? update_mmu_tlb(vma, vmf->address, vmf->pte);
>>>> +??? if ((nr_pages == 1 && vmf_pte_changed(vmf)) ||
>>>> +??????? (nr_pages? > 1 && !pte_range_none(vmf->pte, nr_pages))) {
>>>> +??????? for (i = 0; i < nr_pages; i++)
>>>> +??????????? update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);
>>>
>>> Comment: separating the order-0 case from the other case might make this easier
>>> to read.
>>
>> Yeah fair enough. Will fix.
>>
>>>
>>>> ????????? goto release;
>>>> ????? }
>>>> ? @@ -4216,16 +4303,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault
>>>> *vmf)
>>>> ????????? return handle_userfault(vmf, VM_UFFD_MISSING);
>>>> ????? }
>>>> ? -??? inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
>>>> -??? folio_add_new_anon_rmap(folio, vma, vmf->address);
>>>> +??? folio_ref_add(folio, nr_pages - 1);
>>>> +??? add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
>>>> +??? folio_add_new_anon_rmap(folio, vma, addr);
>>>> ????? folio_add_lru_vma(folio, vma);
>>>> ? setpte:
>>>> ????? if (uffd_wp)
>>>> ????????? entry = pte_mkuffd_wp(entry);
>>>> -??? set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
>>>> +??? set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
>>>> ? ????? /* No need to invalidate - it was non-present before */
>>>> -??? update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
>>>> +??? update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
>>>> ? unlock:
>>>> ????? if (vmf->pte)
>>>> ????????? pte_unmap_unlock(vmf->pte, vmf->ptl);
>>>
>>> Benchmarking order-0 allocations might be interesting. There will be some added
>>> checks + multiple loops/conditionals for order-0 that could be avoided by having
>>> two separate code paths. If we can't measure a difference, all good.
>>
>> Yep will do - will post numbers once I have them. I've been assuming that the
>> major cost is clearing the page, but perhaps I'm wrong.
>>

I added a "write-fault-byte" benchmark to the microbenchmark tool you gave me.
This elides the normal memset page population routine, and instead writes the
first byte of every page while the timer is running.

I ran with 100 iterations per run, then ran the whole thing 16 times. I ran it
for a baseline kernel, as well as v8 (this series) and v9 (with changes from
your review). I repeated on Ampere Altra (bare metal) and Apple M2 (VM):

|              |        m2 vm        |        altra        |
|--------------|---------------------|--------------------:|
| kernel       |     mean |  std_rel |     mean |  std_rel |
|--------------|----------|----------|----------|---------:|
| baseline     |   0.000% |   0.341% |   0.000% |   3.581% |
| anonfolio-v8 |   0.005% |   0.272% |   5.068% |   1.128% |
| anonfolio-v9 |  -0.013% |   0.442% |   0.107% |   1.788% |

No measurable difference on M2, but altra has a slow down in v8 which is fixed
in v9; Looking at the changes, this is either down to the new unlikely() for the
uffd or due to moving the THP order check to be inline within
thp_vma_allowable_orders().

So I have all the changes done and perf numbers to show no regression for
order-0. I'm gonna do a final check and post v9 later today.

Thanks,
Ryan



From lkp at intel.com  Thu Dec  7 02:38:05 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 7 Dec 2023 18:38:05 +0800
Subject: [PATCH 6/9] PCI: imx6: Simplify configure_type() by using
 mode_off and mode_mask
In-Reply-To: <20231206155903.566194-7-Frank.Li@nxp.com>
References: <20231206155903.566194-7-Frank.Li@nxp.com>
Message-ID: <202312071824.0niFJcYw-lkp@intel.com>

Hi Frank,

kernel test robot noticed the following build errors:

[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus linus/master v6.7-rc4 next-20231207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Frank-Li/PCI-imx6-Simplify-clock-handling-by-using-HAS_CLK_-bitmask/20231207-000209
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:    https://lore.kernel.org/r/20231206155903.566194-7-Frank.Li%40nxp.com
patch subject: [PATCH 6/9] PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
config: arm-randconfig-002-20231207 (https://download.01.org/0day-ci/archive/20231207/202312071824.0niFJcYw-lkp at intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231207/202312071824.0niFJcYw-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312071824.0niFJcYw-lkp at intel.com/

All errors (new ones prefixed by >>):

   arm-linux-gnueabi-ld: drivers/pci/controller/dwc/pci-imx6.o: in function `imx6_pcie_init_phy':
>> pci-imx6.c:(.text+0xc40): undefined reference to `__ffsdi2'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From david at redhat.com  Thu Dec  7 02:40:56 2023
From: david at redhat.com (David Hildenbrand)
Date: Thu, 7 Dec 2023 11:40:56 +0100
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <ce48e5e3-8501-45ea-bc6a-290c7d93c6be@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
 <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
 <5c06e3fc-e8f0-4896-ab71-2317a71e812a@arm.com>
 <ce48e5e3-8501-45ea-bc6a-290c7d93c6be@arm.com>
Message-ID: <0999a3b3-6b5e-4927-97b6-546212506c47@redhat.com>

On 07.12.23 11:37, Ryan Roberts wrote:
> On 06/12/2023 15:44, Ryan Roberts wrote:
>> On 06/12/2023 14:19, Ryan Roberts wrote:
>>> On 05/12/2023 16:32, David Hildenbrand wrote:
>>>> On 04.12.23 11:20, Ryan Roberts wrote:
>>>>> Introduce the logic to allow THP to be configured (through the new sysfs
>>>>> interface we just added) to allocate large folios to back anonymous
>>>>> memory, which are larger than the base page size but smaller than
>>>>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>>>>>
>>>>> mTHP continues to be PTE-mapped, but in many cases can still provide
>>>>> similar benefits to traditional PMD-sized THP: Page faults are
>>>>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
>>>>> the configured order), but latency spikes are much less prominent
>>>>> because the size of each page isn't as huge as the PMD-sized variant and
>>>>> there is less memory to clear in each page fault. The number of per-page
>>>>> operations (e.g. ref counting, rmap management, lru list management) are
>>>>> also significantly reduced since those ops now become per-folio.
>>>>>
>>>>> Some architectures also employ TLB compression mechanisms to squeeze
>>>>> more entries in when a set of PTEs are virtually and physically
>>>>> contiguous and approporiately aligned. In this case, TLB misses will
>>>>> occur less often.
>>>>>
>>>>> The new behaviour is disabled by default, but can be enabled at runtime
>>>>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
>>>>> (see documentation in previous commit). The long term aim is to change
>>>>> the default to include suitable lower orders, but there are some risks
>>>>> around internal fragmentation that need to be better understood first.
>>>>>
>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>
>>>> In general, looks good to me, some comments/nits. And the usual "let's make sure
>>>> we don't degrade order-0 and keep that as fast as possible" comment.
>>>>
>>>>> ---
>>>>>  ? include/linux/huge_mm.h |?? 6 ++-
>>>>>  ? mm/memory.c???????????? | 106 ++++++++++++++++++++++++++++++++++++----
>>>>>  ? 2 files changed, 101 insertions(+), 11 deletions(-)
>>>>>
>>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>>>> index bd0eadd3befb..91a53b9835a4 100644
>>>>> --- a/include/linux/huge_mm.h
>>>>> +++ b/include/linux/huge_mm.h
>>>>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>>>>>  ? #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>>>>>  ? ? /*
>>>>> - * Mask of all large folio orders supported for anonymous THP.
>>>>> + * Mask of all large folio orders supported for anonymous THP; all orders up to
>>>>> + * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
>>>>> + * (which is a limitation of the THP implementation).
>>>>>  ?? */
>>>>> -#define THP_ORDERS_ALL_ANON??? BIT(PMD_ORDER)
>>>>> +#define THP_ORDERS_ALL_ANON??? ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>>>>>  ? ? /*
>>>>>  ?? * Mask of all large folio orders supported for file THP.
>>>>> diff --git a/mm/memory.c b/mm/memory.c
>>>>> index 3ceeb0f45bf5..bf7e93813018 100644
>>>>> --- a/mm/memory.c
>>>>> +++ b/mm/memory.c
>>>>> @@ -4125,6 +4125,84 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>>>  ????? return ret;
>>>>>  ? }
>>>>>  ? +static bool pte_range_none(pte_t *pte, int nr_pages)
>>>>> +{
>>>>> +??? int i;
>>>>> +
>>>>> +??? for (i = 0; i < nr_pages; i++) {
>>>>> +??????? if (!pte_none(ptep_get_lockless(pte + i)))
>>>>> +??????????? return false;
>>>>> +??? }
>>>>> +
>>>>> +??? return true;
>>>>> +}
>>>>> +
>>>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>>>>> +{
>>>>> +??? gfp_t gfp;
>>>>> +??? pte_t *pte;
>>>>> +??? unsigned long addr;
>>>>> +??? struct folio *folio;
>>>>> +??? struct vm_area_struct *vma = vmf->vma;
>>>>> +??? unsigned long orders;
>>>>> +??? int order;
>>>>
>>>> Nit: reverse christmas tree encouraged ;)
>>>
>>> ACK will fix.
>>>
>>>>
>>>>> +
>>>>> +??? /*
>>>>> +???? * If uffd is active for the vma we need per-page fault fidelity to
>>>>> +???? * maintain the uffd semantics.
>>>>> +???? */
>>>>> +??? if (userfaultfd_armed(vma))
>>>>
>>>> Nit: unlikely()
>>>
>>> ACK will fix.
>>>
>>>>
>>>>> +??????? goto fallback;
>>>>> +
>>>>> +??? /*
>>>>> +???? * Get a list of all the (large) orders below PMD_ORDER that are enabled
>>>>> +???? * for this vma. Then filter out the orders that can't be allocated over
>>>>> +???? * the faulting address and still be fully contained in the vma.
>>>>> +???? */
>>>>> +??? orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
>>>>> +????????????????????? BIT(PMD_ORDER) - 1);
>>>>> +??? orders = thp_vma_suitable_orders(vma, vmf->address, orders);
>>>>
>>>> Comment: Both will eventually loop over all orders, correct? Could eventually be
>>>> sped up in the future.
>>>
>>> No only thp_vma_suitable_orders() will loop. thp_vma_allowable_orders() only
>>> loops if in_pf=false (it's true here).
>>>
>>>>
>>>> Nit: the orders = ... order = ... looks like this might deserve a helper
>>>> function that makes this easier to read.
>>>
>>> To be honest, the existing function that I've modified is a bit of a mess.
>>> thp_vma_allowable_orders() calls thp_vma_suitable_orders() if we are not in a
>>> page fault, because the page fault handlers already do that check themselves. It
>>> would be nice to refactor the whole thing so that thp_vma_allowable_orders() is
>>> a strict superset of thp_vma_suitable_orders(). Then this can just call
>>> thp_vma_allowable_orders(). But that's going to start touching the PMD and PUD
>>> handlers, so prefer if we leave that for a separate patch set.
>>>
>>>>
>>>> Nit: Why call thp_vma_suitable_orders if the orders are already 0? Again, some
>>>> helper might be reasonable where that is handled internally.
>>>
>>> Because thp_vma_suitable_orders() will handle it safely and is inline, so it
>>> should just as efficient? This would go away with the refactoring described above.
>>>
>>>>
>>>> Comment: For order-0 we'll always perform a function call to both
>>>> thp_vma_allowable_orders() / thp_vma_suitable_orders(). We should perform some
>>>> fast and efficient check if any <PMD THP are even enabled in the system / for
>>>> this VMA, and in that case just fallback before doing more expensive checks.
>>>
>>
>> I just noticed I got these functions round the wrong way in my previous response:
>>
>>> thp_vma_allowable_orders() is inline as you mentioned.
>>
>> ^ Meant thp_vma_suitable_orders() here.
>>
>>>
>>> I was deliberately trying to keep all the decision logic in one place
>>> (thp_vma_suitable_orders) because it's already pretty complicated. But if you
>>
>> ^ Meant thp_vma_allowable_orders() here.
>>
>> Sorry for the confusion.
>>
>>> insist, how about this in the header:
>>>
>>> static inline
>>> unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
>>> 				       unsigned long vm_flags, bool smaps,
>>> 				       bool in_pf, bool enforce_sysfs,
>>> 				       unsigned long orders)
>>> {
>>> 	/* Optimization to check if required orders are enabled early. */
>>> 	if (enforce_sysfs && vma_is_anonymous(vma)) {
>>> 		unsigned long mask = READ_ONCE(huge_anon_orders_always);
>>>
>>> 		if (vm_flags & VM_HUGEPAGE)
>>> 			mask |= READ_ONCE(huge_anon_orders_madvise);
>>> 		if (hugepage_global_always() ||
>>> 			((vm_flags & VM_HUGEPAGE) && hugepage_global_enabled()))
>>> 			mask |= READ_ONCE(huge_anon_orders_inherit);
>>>
>>> 		orders &= mask;
>>> 		if (!orders)
>>> 			return 0;
>>> 		
>>> 		enforce_sysfs = false;
>>> 	}
>>>
>>> 	return __thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf,
>>> 					  enforce_sysfs, orders);
>>> }
>>>
>>> Then the above check can be removed from __thp_vma_allowable_orders() - it will
>>> still retain the `if (enforce_sysfs && !vma_is_anonymous(vma))` part.
>>>
>>>
>>>>
>>>>> +
>>>>> +??? if (!orders)
>>>>> +??????? goto fallback;
>>>>> +
>>>>> +??? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>>>> +??? if (!pte)
>>>>> +??????? return ERR_PTR(-EAGAIN);
>>>>> +
>>>>> +??? order = first_order(orders);
>>>>> +??? while (orders) {
>>>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>>> +??????? vmf->pte = pte + pte_index(addr);
>>>>> +??????? if (pte_range_none(vmf->pte, 1 << order))
>>>>> +??????????? break;
>>>>
>>>> Comment: Likely it would make sense to scan only once and determine the "largest
>>>> none range" around that address, having the largest suitable order in mind.
>>>
>>> Yes, that's how I used to do it, but Yu Zhou requested simplifying to this,
>>> IIRC. Perhaps this an optimization opportunity for later?
>>>
>>>>
>>>>> +??????? order = next_order(&orders, order);
>>>>> +??? }
>>>>> +
>>>>> +??? vmf->pte = NULL;
>>>>
>>>> Nit: Can you elaborate why you are messing with vmf->pte here? A simple helper
>>>> variable will make this code look less magical. Unless I am missing something
>>>> important :)
>>>
>>> Gahh, I used to pass the vmf to what pte_range_none() was refactored into (an
>>> approach that was suggested by Yu Zhou IIRC). But since I did some refactoring
>>> based on some comments from JohnH, I see I don't need that anymore. Agreed; it
>>> will be much clearer just to use a local variable. Will fix.
>>>
>>>>
>>>>> +??? pte_unmap(pte);
>>>>> +
>>>>> +??? gfp = vma_thp_gfp_mask(vma);
>>>>> +
>>>>> +??? while (orders) {
>>>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>>> +??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>>>> +??????? if (folio) {
>>>>> +??????????? clear_huge_page(&folio->page, addr, 1 << order);
>>>>> +??????????? return folio;
>>>>> +??????? }
>>>>> +??????? order = next_order(&orders, order);
>>>>> +??? }
>>>>> +
>>>>
>>>> Queestion: would it make sense to combine both loops? I suspect memory
>>>> allocations with pte_offset_map()/kmao are problematic.
>>>
>>> They are both operating on separate orders; next_order() is "consuming" an order
>>> by removing the current one from the orders bitfield and returning the next one.
>>>
>>> So the first loop starts at the highest order and keeps checking lower orders
>>> until one fully fits in the VMA. And the second loop starts at the first order
>>> that was found to fully fits and loops to lower orders until an allocation is
>>> successful.
>>>
>>> So I don't see a need to combine the loops.
>>>
>>>>
>>>>> +fallback:
>>>>> +??? return vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>>>> +}
>>>>> +#else
>>>>> +#define alloc_anon_folio(vmf) \
>>>>> +??????? vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
>>>>> +#endif
>>>>> +
>>>>>  ? /*
>>>>>  ?? * We enter with non-exclusive mmap_lock (to exclude vma changes,
>>>>>  ?? * but allow concurrent faults), and pte mapped but not yet locked.
>>>>> @@ -4132,6 +4210,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>>>  ?? */
>>>>>  ? static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>>>  ? {
>>>>> +??? int i;
>>>>> +??? int nr_pages = 1;
>>>>> +??? unsigned long addr = vmf->address;
>>>>>  ????? bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
>>>>>  ????? struct vm_area_struct *vma = vmf->vma;
>>>>>  ????? struct folio *folio;
>>>>
>>>> Nit: reverse christmas tree :)
>>>
>>> ACK
>>>
>>>>
>>>>> @@ -4176,10 +4257,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>>>  ????? /* Allocate our own private page. */
>>>>>  ????? if (unlikely(anon_vma_prepare(vma)))
>>>>>  ????????? goto oom;
>>>>> -??? folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>>>> +??? folio = alloc_anon_folio(vmf);
>>>>> +??? if (IS_ERR(folio))
>>>>> +??????? return 0;
>>>>>  ????? if (!folio)
>>>>>  ????????? goto oom;
>>>>>  ? +??? nr_pages = folio_nr_pages(folio);
>>>>> +??? addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
>>>>> +
>>>>>  ????? if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
>>>>>  ????????? goto oom_free_page;
>>>>>  ????? folio_throttle_swaprate(folio, GFP_KERNEL);
>>>>> @@ -4196,12 +4282,13 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>>>  ????? if (vma->vm_flags & VM_WRITE)
>>>>>  ????????? entry = pte_mkwrite(pte_mkdirty(entry), vma);
>>>>>  ? -??? vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
>>>>> -??????????? &vmf->ptl);
>>>>> +??? vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
>>>>>  ????? if (!vmf->pte)
>>>>>  ????????? goto release;
>>>>> -??? if (vmf_pte_changed(vmf)) {
>>>>> -??????? update_mmu_tlb(vma, vmf->address, vmf->pte);
>>>>> +??? if ((nr_pages == 1 && vmf_pte_changed(vmf)) ||
>>>>> +??????? (nr_pages? > 1 && !pte_range_none(vmf->pte, nr_pages))) {
>>>>> +??????? for (i = 0; i < nr_pages; i++)
>>>>> +??????????? update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);
>>>>
>>>> Comment: separating the order-0 case from the other case might make this easier
>>>> to read.
>>>
>>> Yeah fair enough. Will fix.
>>>
>>>>
>>>>>  ????????? goto release;
>>>>>  ????? }
>>>>>  ? @@ -4216,16 +4303,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault
>>>>> *vmf)
>>>>>  ????????? return handle_userfault(vmf, VM_UFFD_MISSING);
>>>>>  ????? }
>>>>>  ? -??? inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
>>>>> -??? folio_add_new_anon_rmap(folio, vma, vmf->address);
>>>>> +??? folio_ref_add(folio, nr_pages - 1);
>>>>> +??? add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
>>>>> +??? folio_add_new_anon_rmap(folio, vma, addr);
>>>>>  ????? folio_add_lru_vma(folio, vma);
>>>>>  ? setpte:
>>>>>  ????? if (uffd_wp)
>>>>>  ????????? entry = pte_mkuffd_wp(entry);
>>>>> -??? set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
>>>>> +??? set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
>>>>>  ? ????? /* No need to invalidate - it was non-present before */
>>>>> -??? update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
>>>>> +??? update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
>>>>>  ? unlock:
>>>>>  ????? if (vmf->pte)
>>>>>  ????????? pte_unmap_unlock(vmf->pte, vmf->ptl);
>>>>
>>>> Benchmarking order-0 allocations might be interesting. There will be some added
>>>> checks + multiple loops/conditionals for order-0 that could be avoided by having
>>>> two separate code paths. If we can't measure a difference, all good.
>>>
>>> Yep will do - will post numbers once I have them. I've been assuming that the
>>> major cost is clearing the page, but perhaps I'm wrong.
>>>
> 
> I added a "write-fault-byte" benchmark to the microbenchmark tool you gave me.
> This elides the normal memset page population routine, and instead writes the
> first byte of every page while the timer is running.
> 
> I ran with 100 iterations per run, then ran the whole thing 16 times. I ran it
> for a baseline kernel, as well as v8 (this series) and v9 (with changes from
> your review). I repeated on Ampere Altra (bare metal) and Apple M2 (VM):
> 
> |              |        m2 vm        |        altra        |
> |--------------|---------------------|--------------------:|
> | kernel       |     mean |  std_rel |     mean |  std_rel |
> |--------------|----------|----------|----------|---------:|
> | baseline     |   0.000% |   0.341% |   0.000% |   3.581% |
> | anonfolio-v8 |   0.005% |   0.272% |   5.068% |   1.128% |
> | anonfolio-v9 |  -0.013% |   0.442% |   0.107% |   1.788% |
> 
> No measurable difference on M2, but altra has a slow down in v8 which is fixed
> in v9; Looking at the changes, this is either down to the new unlikely() for the
> uffd or due to moving the THP order check to be inline within
> thp_vma_allowable_orders().

I suspect the last one.

> 
> So I have all the changes done and perf numbers to show no regression for
> order-0. I'm gonna do a final check and post v9 later today.

Good!

Let me catch up on your comments real quick.

-- 
Cheers,

David / dhildenb



From ryan.roberts at arm.com  Thu Dec  7 02:56:16 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 7 Dec 2023 10:56:16 +0000
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <ca3a2b97-f08e-452a-91dc-1a53dece0aa6@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
 <004ed23d-5571-4474-b7fe-7bc08817c165@redhat.com>
 <ca3a2b97-f08e-452a-91dc-1a53dece0aa6@arm.com>
Message-ID: <841178ee-d29d-43e3-b977-5796c90bd7ad@arm.com>

On 06/12/2023 13:18, Ryan Roberts wrote:
> On 05/12/2023 16:57, David Hildenbrand wrote:
>> On 04.12.23 11:20, Ryan Roberts wrote:
>>> In preparation for adding support for anonymous multi-size THP,
>>> introduce new sysfs structure that will be used to control the new
>>> behaviours. A new directory is added under transparent_hugepage for each
>>> supported THP size, and contains an `enabled` file, which can be set to
>>> "inherit" (to inherit the global setting), "always", "madvise" or
>>> "never". For now, the kernel still only supports PMD-sized anonymous
>>> THP, so only 1 directory is populated.
>>>
>>> The first half of the change converts transhuge_vma_suitable() and
>>> hugepage_vma_check() so that they take a bitfield of orders for which
>>> the user wants to determine support, and the functions filter out all
>>> the orders that can't be supported, given the current sysfs
>>> configuration and the VMA dimensions. If there is only 1 order set in
>>> the input then the output can continue to be treated like a boolean;
>>> this is the case for most call sites. The resulting functions are
>>> renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
>>> respectively.
>>>
>>> The second half of the change implements the new sysfs interface. It has
>>> been done so that each supported THP size has a `struct thpsize`, which
>>> describes the relevant metadata and is itself a kobject. This is pretty
>>> minimal for now, but should make it easy to add new per-thpsize files to
>>> the interface if needed in future (e.g. per-size defrag). Rather than
>>> keep the `enabled` state directly in the struct thpsize, I've elected to
>>> directly encode it into huge_anon_orders_[always|madvise|inherit]
>>> bitfields since this reduces the amount of work required in
>>> thp_vma_allowable_orders() which is called for every page fault.
>>>
>>> See Documentation/admin-guide/mm/transhuge.rst, as modified by this
>>> commit, for details of how the new sysfs interface works.
>>>
>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>> ---
>>
>> Some comments mostly regarding thp_vma_allowable_orders and friends. In general,
>> LGTM. I'll have to go over the order logic once again, I got a bit lost once we
>> started mixing anon and file orders.
>>
>> [...]
>>
>> Doc updates all looked good to me, skimming over them.
>>
>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>> index fa0350b0812a..bd0eadd3befb 100644
>>> --- a/include/linux/huge_mm.h
>>> +++ b/include/linux/huge_mm.h
>>
>> [...]
>>
>>> +static inline unsigned long thp_vma_suitable_orders(struct vm_area_struct *vma,
>>> +??????? unsigned long addr, unsigned long orders)
>>> +{
>>> +??? int order;
>>> +
>>> +??? /*
>>> +???? * Iterate over orders, highest to lowest, removing orders that don't
>>> +???? * meet alignment requirements from the set. Exit loop at first order
>>> +???? * that meets requirements, since all lower orders must also meet
>>> +???? * requirements.
>>> +???? */
>>> +
>>> +??? order = first_order(orders);
>>
>> nit: "highest_order" or "largest_order" would be more expressive regarding the
>> actual semantics.
> 
> Yep, will call it "highest_order".
> 
>>
>>> +
>>> +??? while (orders) {
>>> +??????? unsigned long hpage_size = PAGE_SIZE << order;
>>> +??????? unsigned long haddr = ALIGN_DOWN(addr, hpage_size);
>>> +
>>> +??????? if (haddr >= vma->vm_start &&
>>> +??????????? haddr + hpage_size <= vma->vm_end) {
>>> +??????????? if (!vma_is_anonymous(vma)) {
>>> +??????????????? if (IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) -
>>> +??????????????????????? vma->vm_pgoff,
>>> +??????????????????????? hpage_size >> PAGE_SHIFT))
>>> +??????????????????? break;
>>> +??????????? } else
>>> +??????????????? break;
>>
>> Comment: Codying style wants you to use if () {} else {}
>>
>> But I'd recommend for the conditions:
>>
>> if (haddr < vma->vm_start ||
>> ??? haddr + hpage_size > vma->vm_end)
>> ????continue;
>> /* Don't have to check pgoff for anonymous vma */
>> if (!vma_is_anonymous(vma))
>> ????break;
>> if (IS_ALIGNED((...
>> ????break;
> 
> OK I'll take this structure.

FYI I ended up NOT taking this, because I now have thp_vma_suitable_order() and
thp_vma_suitable_orders(). The former is essentially what was there before
(except I pass the order and derive the nr_pages, alignment, etc from that
rather than using the HPAGE_* macros. The latter is just a loop that calls the
former for each order in the bitfield.

> 
>>
>> [...]
>>
>>
>>> +/**
>>> + * thp_vma_allowable_orders - determine hugepage orders that are allowed for vma
>>> + * @vma:? the vm area to check
>>> + * @vm_flags: use these vm_flags instead of vma->vm_flags
>>> + * @smaps: whether answer will be used for smaps file
>>> + * @in_pf: whether answer will be used by page fault handler
>>> + * @enforce_sysfs: whether sysfs config should be taken into account
>>> + * @orders: bitfield of all orders to consider
>>> + *
>>> + * Calculates the intersection of the requested hugepage orders and the allowed
>>> + * hugepage orders for the provided vma. Permitted orders are encoded as a set
>>> + * bit at the corresponding bit position (bit-2 corresponds to order-2, bit-3
>>> + * corresponds to order-3, etc). Order-0 is never considered a hugepage order.
>>> + *
>>> + * Return: bitfield of orders allowed for hugepage in the vma. 0 if no hugepage
>>> + * orders are allowed.
>>> + */
>>> +unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
>>> +?????????????????????? unsigned long vm_flags, bool smaps,
>>> +?????????????????????? bool in_pf, bool enforce_sysfs,
>>> +?????????????????????? unsigned long orders)
>>> +{
>>> +??? /* Check the intersection of requested and supported orders. */
>>> +??? orders &= vma_is_anonymous(vma) ?
>>> +??????????? THP_ORDERS_ALL_ANON : THP_ORDERS_ALL_FILE;
>>> +??? if (!orders)
>>> +??????? return 0;
>>
>> Comment: if this is called from some hot path, we might want to move as much as
>> possible into a header, so we can avoid this function call here when e.g., THP
>> are completely disabled etc.
> 
> If THP is completely disabled (compiled out) then thp_vma_allowable_orders() is
> defined as a header inline that returns 0. I'm not sure there are any paths in
> practice which are likely to ask for a set of orders which are never supported
> (i.e. where this specific check would return 0). And the "are they run time
> enabled" check is further down and fairly involved, so not sure that's ideal for
> an inline.
> 
> I haven't changed the pattern from how it was previously, so I don't think it
> should be any more expensive. Which parts exactly do you want to move to a header?

As per my response against the next patch (#4), I have now implemented
thp_vma_allowable_orders() so that the order check is in the header with an
early exit if THP is completely disabled.

> 
> 
>>
>>> +
>>> ????? if (!vma->vm_mm)??????? /* vdso */
>>> -??????? return false;
>>> +??????? return 0;
>>> ? ????? /*
>>> ?????? * Explicitly disabled through madvise or prctl, or some
>>> @@ -88,16 +141,16 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>> unsigned long vm_flags,
>>> ?????? * */
>>> ????? if ((vm_flags & VM_NOHUGEPAGE) ||
>>> ????????? test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
>>> -??????? return false;
>>> +??????? return 0;
>>> ????? /*
>>> ?????? * If the hardware/firmware marked hugepage support disabled.
>>> ?????? */
>>> ????? if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED))
>>> -??????? return false;
>>> +??????? return 0;
>>> ? ????? /* khugepaged doesn't collapse DAX vma, but page fault is fine. */
>>> ????? if (vma_is_dax(vma))
>>> -??????? return in_pf;
>>> +??????? return in_pf ? orders : 0;
>>> ? ????? /*
>>> ?????? * khugepaged special VMA and hugetlb VMA.
>>> @@ -105,17 +158,29 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>> unsigned long vm_flags,
>>> ?????? * VM_MIXEDMAP set.
>>> ?????? */
>>> ????? if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
>>> -??????? return false;
>>> +??????? return 0;
>>> ? ????? /*
>>> -???? * Check alignment for file vma and size for both file and anon vma.
>>> +???? * Check alignment for file vma and size for both file and anon vma by
>>> +???? * filtering out the unsuitable orders.
>>> ?????? *
>>> ?????? * Skip the check for page fault. Huge fault does the check in fault
>>> -???? * handlers. And this check is not suitable for huge PUD fault.
>>> +???? * handlers.
>>> ?????? */
>>> -??? if (!in_pf &&
>>> -??????? !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
>>> -??????? return false;
>>> +??? if (!in_pf) {
>>> +??????? int order = first_order(orders);
>>> +??????? unsigned long addr;
>>> +
>>> +??????? while (orders) {
>>> +??????????? addr = vma->vm_end - (PAGE_SIZE << order);
>>> +??????????? if (thp_vma_suitable_orders(vma, addr, BIT(order)))
>>> +??????????????? break;
>>
>> Comment: you'd want a "thp_vma_suitable_order" helper here. But maybe the
>> compiler is smart enough to optimize the loop and everyything else out.
> 
> I'm happy to refactor so that thp_vma_suitable_order() is the basic primitive,
> then make thp_vma_suitable_orders() a loop that calls thp_vma_suitable_order()
> (that's basically how it is laid out already, just all in one function). Is that
> what you are requesting?
> 
>>
>> [...]
>>
>>> +
>>> +static ssize_t thpsize_enabled_store(struct kobject *kobj,
>>> +???????????????????? struct kobj_attribute *attr,
>>> +???????????????????? const char *buf, size_t count)
>>> +{
>>> +??? int order = to_thpsize(kobj)->order;
>>> +??? ssize_t ret = count;
>>> +
>>> +??? if (sysfs_streq(buf, "always")) {
>>> +??????? set_bit(order, &huge_anon_orders_always);
>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>> +??? } else if (sysfs_streq(buf, "inherit")) {
>>> +??????? set_bit(order, &huge_anon_orders_inherit);
>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>> +??? } else if (sysfs_streq(buf, "madvise")) {
>>> +??????? set_bit(order, &huge_anon_orders_madvise);
>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>> +??? } else if (sysfs_streq(buf, "never")) {
>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>
>> Note: I was wondering for a second if some concurrent cames could lead to an
>> inconsistent state. I think in the worst case we'll simply end up with "never"
>> on races.
> 
> You mean if different threads try to write different values to this file
> concurrently? Or if there is a concurrent fault that tries to read the flags
> while they are being modified?
> 
> I thought about this for a long time too and wasn't sure what was best. The
> existing global enabled store impl clears the bits first then sets the bit. With
> this approach you can end up with multiple bits set if there is a race to set
> diffierent values, and you can end up with a faulting thread seeing never if it
> reads the bits after they have been cleared but before setting them.
> 
> I decided to set the new bit before clearing the old bits, which is different; A
> racing fault will never see "never" but as you say, a race to set the file could
> result in "never" being set.
> 
> On reflection, it's probably best to set the bit *last* like the global control
> does?>
> 
>>
>> [...]
>>
>>> ? static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
>>> ? {
>>> ????? int err;
>>> +??? struct thpsize *thpsize;
>>> +??? unsigned long orders;
>>> +??? int order;
>>> +
>>> +??? /*
>>> +???? * Default to setting PMD-sized THP to inherit the global setting and
>>> +???? * disable all other sizes. powerpc's PMD_ORDER isn't a compile-time
>>> +???? * constant so we have to do this here.
>>> +???? */
>>> +??? huge_anon_orders_inherit = BIT(PMD_ORDER);
>>> ? ????? *hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
>>> ????? if (unlikely(!*hugepage_kobj)) {
>>> @@ -434,8 +631,24 @@ static int __init hugepage_init_sysfs(struct kobject
>>> **hugepage_kobj)
>>> ????????? goto remove_hp_group;
>>> ????? }
>>> ? +??? orders = THP_ORDERS_ALL_ANON;
>>> +??? order = first_order(orders);
>>> +??? while (orders) {
>>> +??????? thpsize = thpsize_create(order, *hugepage_kobj);
>>> +??????? if (IS_ERR(thpsize)) {
>>> +??????????? pr_err("failed to create thpsize for order %d\n", order);
>>> +??????????? err = PTR_ERR(thpsize);
>>> +??????????? goto remove_all;
>>> +??????? }
>>> +??????? list_add(&thpsize->node, &thpsize_list);
>>> +??????? order = next_order(&orders, order);
>>> +??? }
>>> +
>>> ????? return 0;
>>> ? 
>>
>> [...]
>>
>>> ????? page = compound_head(page);
>>> @@ -5116,7 +5116,8 @@ static vm_fault_t __handle_mm_fault(struct
>>> vm_area_struct *vma,
>>> ????????? return VM_FAULT_OOM;
>>> ? retry_pud:
>>> ????? if (pud_none(*vmf.pud) &&
>>> -??????? hugepage_vma_check(vma, vm_flags, false, true, true)) {
>>> +??????? thp_vma_allowable_orders(vma, vm_flags, false, true, true,
>>> +???????????????????? BIT(PUD_ORDER))) {
>>> ????????? ret = create_huge_pud(&vmf);
>>> ????????? if (!(ret & VM_FAULT_FALLBACK))
>>> ????????????? return ret;
>>> @@ -5150,7 +5151,8 @@ static vm_fault_t __handle_mm_fault(struct
>>> vm_area_struct *vma,
>>> ????????? goto retry_pud;
>>> ? ????? if (pmd_none(*vmf.pmd) &&
>>> -??????? hugepage_vma_check(vma, vm_flags, false, true, true)) {
>>> +??????? thp_vma_allowable_orders(vma, vm_flags, false, true, true,
>>> +???????????????????? BIT(PMD_ORDER))) {
>>
>> Comment: A helper like "thp_vma_allowable_order(vma, PMD_ORDER)" might make this
>> easier to read -- and the implemenmtation will be faster.
> 
> I'm happy to do this and use it to improve readability:
> 
> #define thp_vma_allowable_order(..., order) \
> 	thp_vma_allowable_orders(..., BIT(order))
> 
> This wouldn't make the implementation any faster though; Are you suggesting a
> completely separate impl? Even then, I don't think there is much scope to make
> it faster for the case where there is only 1 order in the bitfield.
> 
>>
>>> ????????? ret = create_huge_pmd(&vmf);
>>> ????????? if (!(ret & VM_FAULT_FALLBACK))
>>> ????????????? return ret;
>>> diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
>>> index e0b368e545ed..64da127cc267 100644
>>> --- a/mm/page_vma_mapped.c
>>> +++ b/mm/page_vma_mapped.c
>>> @@ -268,7 +268,8 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
>>> ?????????????? * cleared *pmd but not decremented compound_mapcount().
>>> ?????????????? */
>>> ????????????? if ((pvmw->flags & PVMW_SYNC) &&
>>> -??????????????? transhuge_vma_suitable(vma, pvmw->address) &&
>>> +??????????????? thp_vma_suitable_orders(vma, pvmw->address,
>>> +??????????????????????????? BIT(PMD_ORDER)) &&
>>
>> Comment: Similarly, a helper like "thp_vma_suitable_order(vma, PMD_ORDER)" might
>> make this easier to read.
> 
> Yep, will do this.
> 
>>
>>> ????????????????? (pvmw->nr_pages >= HPAGE_PMD_NR)) {
>>> ????????????????? spinlock_t *ptl = pmd_lock(mm, pvmw->pmd);
>>> ? 
>>
> 



From laurent.pinchart at ideasonboard.com  Thu Dec  7 03:06:19 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 13:06:19 +0200
Subject: [PATCH 2/2] media: i2c: Add GC08A3 image sensor driver
In-Reply-To: <20231123115104.32094-3-zhi.mao@mediatek.com>
References: <20231123115104.32094-1-zhi.mao@mediatek.com>
 <20231123115104.32094-3-zhi.mao@mediatek.com>
Message-ID: <20231207110619.GJ29417@pendragon.ideasonboard.com>

Hi Zhi Mao,

Thank you for the patch.

This is a partial review, as lots of things will change already for v2.
I'll review the next version in more details.

First of all, please rebase the driver on top of the master branch of
git://linuxtv.org/media_stage.git. Quite a few in-kernel APIs have
changed.

On Thu, Nov 23, 2023 at 07:51:04PM +0800, Zhi Mao wrote:
> Add a V4L2 sub-device driver for Galaxycore GC08A3 image sensor.
> 
> Signed-off-by: Zhi Mao <zhi.mao at mediatek.com>
> ---
>  drivers/media/i2c/Kconfig  |   14 +
>  drivers/media/i2c/Makefile |    1 +
>  drivers/media/i2c/gc08a3.c | 2046 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 2061 insertions(+)
>  create mode 100644 drivers/media/i2c/gc08a3.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 59ee0ca2c978..2e37be537690 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -1451,6 +1451,20 @@ config VIDEO_THS7303
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called ths7303.
>  
> +config VIDEO_GC08A3

Alphabetical order please.

> +	tristate "GalaxyCore gc08a3 sensor support"
> +	depends on GPIOLIB && I2C && VIDEO_DEV
> +	select V4L2_FWNODE
> +	select MEDIA_CONTROLLER
> +	select VIDEO_V4L2_SUBDEV_API

You can drop all of the above except

	depends on GPIOLIB

The dependencies on I2C and VIDEO_DEV and the selection of V4L2_FWNODE,
MEDIA_CONTROLLER and VIDEIO_V4L2_SUBDEV_API are now handled
automatically for all drivers in the VIDEO_CAMERA_SENSOR menu.

> +	select REGMAP_I2C
> +	help
> +	  This is a Video4Linux2 sensor driver for the GalaxyCore gc08a3
> +	  camera.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called gc08a3.
> +
>  endmenu
>  
>  #
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index f5010f80a21f..ec40dbd75e7a 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_VIDEO_DW9719) += dw9719.o
>  obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
>  obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
>  obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8/
> +obj-$(CONFIG_VIDEO_GC08A3) += gc08a3.o
>  obj-$(CONFIG_VIDEO_HI556) += hi556.o
>  obj-$(CONFIG_VIDEO_HI846) += hi846.o
>  obj-$(CONFIG_VIDEO_HI847) += hi847.o
> diff --git a/drivers/media/i2c/gc08a3.c b/drivers/media/i2c/gc08a3.c
> new file mode 100644
> index 000000000000..d3cf62b65c2e
> --- /dev/null
> +++ b/drivers/media/i2c/gc08a3.c
> @@ -0,0 +1,2046 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * gc08a3.c - gc08a3 sensor driver
> + *
> + * Copyright 2023 Mediatek
> + *
> + * Zhi Mao <zhi.mao at mediatek.com>
> + */
> +
> +#include <asm/unaligned.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <media/media-entity.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-fwnode.h>
> +#include <media/v4l2-subdev.h>
> +
> +//=========================================

V4L2 uses C-style comments.

> +#define GC08A3_REG_VALUE_08BIT 1
> +#define GC08A3_REG_VALUE_16BIT 2
> +#define GC08A3_REG_VALUE_24BIT 3

Please use the v4l2-cci helpers for register access.

> +
> +#define GC08A3_REG_CHIP_ID 0x03f0
> +#define GC08A3_CHIP_ID 0x08a3
> +
> +#define GC08A3_NATIVE_WIDTH		3264
> +#define GC08A3_NATIVE_HEIGHT	2448
> +
> +#define GC08A3_REG_TEST_PATTERN_EN 0x008c
> +#define GC08A3_REG_TEST_PATTERN_IDX 0x008d
> +#define GC08A3_TEST_PATTERN_EN 0x01
> +
> +#define GC08A3_STRAEMING_REG 0x0100
> +
> +#define GC08A3_SCLK 280000000LL
> +
> +#define GC08A3_DEFAULT_CLK_FREQ 24000000
> +#define GC08A3_FPS 30
> +#define GC08A3_MBUS_CODE MEDIA_BUS_FMT_SRGGB10_1X10
> +#define GC08A3_DATA_LANES 4
> +
> +//for 1920*1080
> +#define GC08A3_LINK_FREQ_207MHZ 207000000ULL
> +//for 3264*2448
> +#define GC08A3_LINK_FREQ_336MHZ 336000000ULL

Macros don't help readibility, simply use the numerical values in the
link_freq_menu_items array below.

> +
> +#define GC08A3_RGB_DEPTH 10
> +
> +//frame length
> +#define GC08A3_FL_REG 0x0340
> +#define GC08A3_VTS_30FPS 2548
> +#define GC08A3_VTS_30FPS_MIN 2548
> +#define GC08A3_VTS_60FPS 1276
> +#define GC08A3_VTS_60FPS_MIN 1276
> +#define GC08A3_VTS_MAX 0xfff0
> +#define GC08A3_FL_MARGIN 48
> +
> +// line length
> +#define GC08A3_LL_REG 0x0342
> +#define GC08A3_HTS_30FPS 3640
> +#define GC08A3_HTS_60FPS 3640
> +
> +#define GC08A3_EXP_REG 0x0202
> +#define GC08A3_EXP_MARGIN 16
> +#define GC08A3_EXP_MIN 4
> +#define GC08A3_EXP_STEP 1
> +
> +#define GC08A3_FLIP_REG 0x0101
> +#define GC08A3_FLIP_H_MASK 0x1
> +#define GC08A3_FLIP_V_MASK 0x2
> +
> +#define GC08A3_AGAIN_REG 0x0204
> +#define GC08A3_AGAIN_MIN 1024
> +#define GC08A3_AGAIN_MAX (1024 * 16)
> +#define GC08A3_AGAIN_STEP 1
> +
> +#define GC08A3_DGAIN_REG 0x020e
> +#define GC08A3_DGAIN_MIN 1024
> +#define GC08A3_DGAIN_MAX 1024
> +#define GC08A3_DGAIN_STEP 1
> +//============================================================
> +
> +//============================================================
> +static const char *const gc08a3_test_pattern_menu[] = {
> +	"No Pattern",  "Solid Black", "Solid White",  "Solid Red",
> +	"Solid Green", "Solid Blue",  "Solid Yellow", "Colour Bar",
> +};
> +
> +enum {
> +	GC08A3_LINK_FREQ_336MHZ_CFG,
> +	GC08A3_LINK_FREQ_207MHZ_CFG,
> +};
> +
> +static const s64 link_freq_menu_items[] = {
> +	GC08A3_LINK_FREQ_336MHZ,
> +	GC08A3_LINK_FREQ_207MHZ,
> +};
> +
> +static const char *const gc08a3_supply_name[] = {
> +	"avdd",
> +	"dvdd",
> +	"dovdd",
> +};
> +
> +#define GC08A3_NUM_SUPPLIES ARRAY_SIZE(gc08a3_supply_name)
> +
> +struct gc08a3 {
> +	struct device *dev;
> +	struct v4l2_subdev sd;
> +	struct media_pad pad;
> +	struct v4l2_mbus_framefmt fmt;

Please use the subdev active state to store the active format. See
commit e8a5b1df000e ("media: i2c: imx219: Use subdev active state") as
an example of how to do so. There's also documentation in
Documentation/driver-api/media/v4l2-subdev.rst (please read the most
up-to-date version in the master branch of the media_stage tree).

> +	struct i2c_client *client;
> +
> +	struct v4l2_rect crop;

This should be stored in the subdev active state too.

> +
> +	struct clk *xclk;
> +	struct regulator_bulk_data supplies[GC08A3_NUM_SUPPLIES];
> +	struct gpio_desc *enable_gpio;
> +
> +	struct regmap *regmap;
> +
> +	struct v4l2_ctrl_handler ctrls;
> +	struct v4l2_ctrl *pixel_rate;
> +	struct v4l2_ctrl *link_freq;
> +	struct v4l2_ctrl *exposure;
> +	struct v4l2_ctrl *vblank;
> +	struct v4l2_ctrl *hblank;
> +
> +	/*
> +	 * Serialize control access, get/set format, get selection
> +	 * and start streaming.
> +	 */
> +	struct mutex mutex;

The mutex won't be needed anymore once you use the subdev active state.

> +
> +	bool streaming;
> +
> +	/* Current mode */
> +	const struct gc08a3_mode *cur_mode;
> +};
> +
> +struct reg_8 {
> +	u16 address;
> +	u8 val;
> +};
> +
> +struct gc08a3_reg_list {
> +	u32 num_of_regs;
> +	const struct reg_8 *regs;
> +};
> +
> +struct gc08a3_link_freq_config {
> +	const struct gc08a3_reg_list reg_list;
> +};
> +
> +enum {
> +	GC08A3_TABLE_WAIT_MS = 0,
> +	GC08A3_TABLE_END,
> +};
> +
> +/*From gc08a3_mode_tbls.h*/
> +static const struct reg_8 mode_3264x2448[] = {
> +	/*system*/
> +	{ 0x031c, 0x60 },
> +	{ 0x0337, 0x04 },
> +	{ 0x0335, 0x51 },
> +	{ 0x0336, 0x70 },
> +	{ 0x0383, 0xbb },
> +	{ 0x031a, 0x00 },
> +	{ 0x0321, 0x10 },
> +	{ 0x0327, 0x03 },
> +	{ 0x0325, 0x40 },
> +	{ 0x0326, 0x23 },
> +	{ 0x0314, 0x11 },
> +	{ 0x0315, 0xd6 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0334, 0x40 },
> +	{ 0x0324, 0x42 },
> +	{ 0x031c, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x0344, 0x00 },
> +	{ 0x0345, 0x06 },
> +	{ 0x0346, 0x00 },
> +	{ 0x0347, 0x04 },
> +	{ 0x0348, 0x0c },
> +	{ 0x0349, 0xd0 }, //3280
> +	{ 0x034a, 0x09 },
> +	{ 0x034b, 0x9c }, //2460
> +	{ 0x0202, 0x09 },
> +	{ 0x0203, 0x04 }, //Exp
> +	{ 0x0340, 0x09 },
> +	{ 0x0341, 0xf4 }, //FL
> +	{ 0x0342, 0x07 },
> +	{ 0x0343, 0x1c }, //LineLength
> +
> +	{ 0x0226, 0x00 }, //min vb[15:8]
> +	{ 0x0227, 0x28 }, //min vb[7:0]
> +	{ 0x0e38, 0x49 },
> +	{ 0x0210, 0x13 },
> +	{ 0x0218, 0x00 },
> +	{ 0x0241, 0x88 },
> +	{ 0x0392, 0x60 },
> +
> +	/*ISP*/
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 }, //CISCTL_rst
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x00a2, 0x00 },
> +	{ 0x00a3, 0x00 },
> +	{ 0x00ab, 0x00 },
> +	{ 0x00ac, 0x00 },
> +	{ 0x05a0, 0x82 },
> +	{ 0x05ac, 0x00 },
> +	{ 0x05ad, 0x01 },
> +	{ 0x05ae, 0x00 },
> +	{ 0x0800, 0x0a },
> +	{ 0x0801, 0x14 },
> +	{ 0x0802, 0x28 },
> +	{ 0x0803, 0x34 },
> +	{ 0x0804, 0x0e },
> +	{ 0x0805, 0x33 },
> +	{ 0x0806, 0x03 },
> +	{ 0x0807, 0x8a },
> +	{ 0x0808, 0x50 },
> +	{ 0x0809, 0x00 },
> +	{ 0x080a, 0x34 },
> +	{ 0x080b, 0x03 },
> +	{ 0x080c, 0x26 },
> +	{ 0x080d, 0x03 },
> +	{ 0x080e, 0x18 },
> +	{ 0x080f, 0x03 },
> +	{ 0x0810, 0x10 },
> +	{ 0x0811, 0x03 },
> +	{ 0x0812, 0x00 },
> +	{ 0x0813, 0x00 },
> +	{ 0x0814, 0x01 },
> +	{ 0x0815, 0x00 },
> +	{ 0x0816, 0x01 },
> +	{ 0x0817, 0x00 },
> +	{ 0x0818, 0x00 },
> +	{ 0x0819, 0x0a },
> +	{ 0x081a, 0x01 },
> +	{ 0x081b, 0x6c },
> +	{ 0x081c, 0x00 },
> +	{ 0x081d, 0x0b },
> +	{ 0x081e, 0x02 },
> +	{ 0x081f, 0x00 },
> +	{ 0x0820, 0x00 },
> +	{ 0x0821, 0x0c },
> +	{ 0x0822, 0x02 },
> +	{ 0x0823, 0xd9 },
> +	{ 0x0824, 0x00 },
> +	{ 0x0825, 0x0d },
> +	{ 0x0826, 0x03 },
> +	{ 0x0827, 0xf0 },
> +	{ 0x0828, 0x00 },
> +	{ 0x0829, 0x0e },
> +	{ 0x082a, 0x05 },
> +	{ 0x082b, 0x94 },
> +	{ 0x082c, 0x09 },
> +	{ 0x082d, 0x6e },
> +	{ 0x082e, 0x07 },
> +	{ 0x082f, 0xe6 },
> +	{ 0x0830, 0x10 },
> +	{ 0x0831, 0x0e },
> +	{ 0x0832, 0x0b },
> +	{ 0x0833, 0x2c },
> +	{ 0x0834, 0x14 },
> +	{ 0x0835, 0xae },
> +	{ 0x0836, 0x0f },
> +	{ 0x0837, 0xc4 },
> +	{ 0x0838, 0x18 },
> +	{ 0x0839, 0x0e },
> +	{ 0x05ac, 0x01 },
> +	{ 0x059a, 0x00 },
> +	{ 0x059b, 0x00 },
> +	{ 0x059c, 0x01 },
> +	{ 0x0598, 0x00 },
> +	{ 0x0597, 0x14 },
> +	{ 0x05ab, 0x09 },
> +	{ 0x05a4, 0x02 },
> +	{ 0x05a3, 0x05 },
> +	{ 0x05a0, 0xc2 },
> +	{ 0x0207, 0xc4 },
> +
> +	/*GAIN*/
> +	{ 0x0204, 0x04 },
> +	{ 0x0205, 0x00 },
> +	{ 0x0050, 0x5c },
> +	{ 0x0051, 0x44 },
> +
> +	/*out window*/
> +	{ 0x009a, 0x66 },
> +	{ 0x0351, 0x00 },
> +	{ 0x0352, 0x06 }, //out_win_y1
> +	{ 0x0353, 0x00 },
> +	{ 0x0354, 0x08 }, //out_win_x1
> +	{ 0x034c, 0x0c },
> +	{ 0x034d, 0xc0 }, //3264
> +	{ 0x034e, 0x09 },
> +	{ 0x034f, 0x90 }, //2448
> +
> +	/*MIPI*/
> +	{ 0x0114, 0x03 }, //0:1lane 1:2lane 3:4lane
> +	{ 0x0180, 0x65 }, //[3:0]dphy_mipi_diff
> +	{ 0x0181, 0xf0 },
> +	{ 0x0185, 0x01 },
> +	{ 0x0115, 0x30 },
> +	{ 0x011b, 0x12 },
> +	{ 0x011c, 0x12 },
> +	{ 0x0121, 0x06 }, //T_LPX
> +	{ 0x0122, 0x06 }, //T_CLK_HS_PREPARE
> +	{ 0x0123, 0x15 }, //T_CLK_zero
> +	{ 0x0124, 0x01 }, //T_CLK_PRE
> +	{ 0x0125, 0x0b }, //T_CLK_POST
> +	{ 0x0126, 0x08 }, //T_CLK_TRAIL
> +	{ 0x0129, 0x06 }, //T_HS_PREPARE
> +	{ 0x012a, 0x08 }, //T_HS_Zero
> +	{ 0x012b, 0x08 }, //T_HS_TRAIL
> +
> +	{ 0x0a73, 0x60 },
> +	{ 0x0a70, 0x11 },
> +	{ 0x0313, 0x80 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0a70, 0x00 },
> +	{ 0x00a4, 0x80 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0a67, 0x00 },
> +	{ 0x0084, 0x10 },
> +	{ 0x0102, 0x09 },
> +
> +	{ GC08A3_TABLE_END, 0x00 }
> +};
> +
> +static const struct reg_8 mode_1920x1080[] = {
> +	/*system*/
> +	{ 0x031c, 0x60 },
> +	{ 0x0337, 0x04 },
> +	{ 0x0335, 0x51 },
> +	{ 0x0336, 0x45 },
> +	{ 0x0383, 0x8b },
> +	{ 0x031a, 0x00 },
> +	{ 0x0321, 0x10 },
> +	{ 0x0327, 0x03 },
> +	{ 0x0325, 0x40 },
> +	{ 0x0326, 0x23 },
> +	{ 0x0314, 0x11 },
> +	{ 0x0315, 0xd6 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0334, 0x40 },
> +	{ 0x0324, 0x42 },
> +	{ 0x031c, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x0344, 0x02 },
> +	{ 0x0345, 0xa6 },
> +	{ 0x0346, 0x02 },
> +	{ 0x0347, 0xb0 },
> +	{ 0x0348, 0x07 },
> +	{ 0x0349, 0x90 }, //1936
> +	{ 0x034a, 0x04 },
> +	{ 0x034b, 0x44 }, //1092
> +	{ 0x0202, 0x03 },
> +	{ 0x0203, 0x00 }, //Exp
> +	{ 0x0340, 0x04 },
> +	{ 0x0341, 0xfc }, //FL
> +	{ 0x0342, 0x07 },
> +	{ 0x0343, 0x1c }, //LineLength
> +
> +	{ 0x0226, 0x00 }, //min vb[15:8]
> +	{ 0x0227, 0x88 }, //min vb[7:0]
> +	{ 0x0e38, 0x49 },
> +	{ 0x0210, 0x13 },
> +	{ 0x0218, 0x00 },
> +	{ 0x0241, 0x88 },
> +	{ 0x0392, 0x60 },
> +
> +	/*ISP*/
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 }, //CISCTL_rst
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x00a2, 0xac },
> +	{ 0x00a3, 0x02 },
> +	{ 0x00ab, 0xa0 },
> +	{ 0x00ac, 0x02 },
> +	{ 0x05a0, 0x82 },
> +	{ 0x05ac, 0x00 },
> +	{ 0x05ad, 0x01 },
> +	{ 0x05ae, 0x00 },
> +	{ 0x0800, 0x0a },
> +	{ 0x0801, 0x14 },
> +	{ 0x0802, 0x28 },
> +	{ 0x0803, 0x34 },
> +	{ 0x0804, 0x0e },
> +	{ 0x0805, 0x33 },
> +	{ 0x0806, 0x03 },
> +	{ 0x0807, 0x8a },
> +	{ 0x0808, 0x50 },
> +	{ 0x0809, 0x00 },
> +	{ 0x080a, 0x34 },
> +	{ 0x080b, 0x03 },
> +	{ 0x080c, 0x26 },
> +	{ 0x080d, 0x03 },
> +	{ 0x080e, 0x18 },
> +	{ 0x080f, 0x03 },
> +	{ 0x0810, 0x10 },
> +	{ 0x0811, 0x03 },
> +	{ 0x0812, 0x00 },
> +	{ 0x0813, 0x00 },
> +	{ 0x0814, 0x01 },
> +	{ 0x0815, 0x00 },
> +	{ 0x0816, 0x01 },
> +	{ 0x0817, 0x00 },
> +	{ 0x0818, 0x00 },
> +	{ 0x0819, 0x0a },
> +	{ 0x081a, 0x01 },
> +	{ 0x081b, 0x6c },
> +	{ 0x081c, 0x00 },
> +	{ 0x081d, 0x0b },
> +	{ 0x081e, 0x02 },
> +	{ 0x081f, 0x00 },
> +	{ 0x0820, 0x00 },
> +	{ 0x0821, 0x0c },
> +	{ 0x0822, 0x02 },
> +	{ 0x0823, 0xd9 },
> +	{ 0x0824, 0x00 },
> +	{ 0x0825, 0x0d },
> +	{ 0x0826, 0x03 },
> +	{ 0x0827, 0xf0 },
> +	{ 0x0828, 0x00 },
> +	{ 0x0829, 0x0e },
> +	{ 0x082a, 0x05 },
> +	{ 0x082b, 0x94 },
> +	{ 0x082c, 0x09 },
> +	{ 0x082d, 0x6e },
> +	{ 0x082e, 0x07 },
> +	{ 0x082f, 0xe6 },
> +	{ 0x0830, 0x10 },
> +	{ 0x0831, 0x0e },
> +	{ 0x0832, 0x0b },
> +	{ 0x0833, 0x2c },
> +	{ 0x0834, 0x14 },
> +	{ 0x0835, 0xae },
> +	{ 0x0836, 0x0f },
> +	{ 0x0837, 0xc4 },
> +	{ 0x0838, 0x18 },
> +	{ 0x0839, 0x0e },
> +	{ 0x05ac, 0x01 },
> +	{ 0x059a, 0x00 },
> +	{ 0x059b, 0x00 },
> +	{ 0x059c, 0x01 },
> +	{ 0x0598, 0x00 },
> +	{ 0x0597, 0x14 },
> +	{ 0x05ab, 0x09 },
> +	{ 0x05a4, 0x02 },
> +	{ 0x05a3, 0x05 },
> +	{ 0x05a0, 0xc2 },
> +	{ 0x0207, 0xc4 },
> +
> +	/*GAIN*/
> +	{ 0x0204, 0x04 },
> +	{ 0x0205, 0x00 },
> +	{ 0x0050, 0x38 },
> +	{ 0x0051, 0x20 },
> +
> +	/*out window*/
> +	{ 0x009a, 0x66 },
> +	{ 0x0351, 0x00 },
> +	{ 0x0352, 0x06 }, //out_win_y1
> +	{ 0x0353, 0x00 },
> +	{ 0x0354, 0x08 }, //out_win_x1
> +	{ 0x034c, 0x07 },
> +	{ 0x034d, 0x80 }, //1920
> +	{ 0x034e, 0x04 },
> +	{ 0x034f, 0x38 }, //1080
> +
> +	/*MIPI*/
> +	{ 0x0114, 0x03 }, //0:1lane 1:2lane 3:4lane
> +	{ 0x0180, 0x65 }, //[3:0]dphy_mipi_diff
> +	{ 0x0181, 0xf0 },
> +	{ 0x0185, 0x01 },
> +	{ 0x0115, 0x30 },
> +	{ 0x011b, 0x12 },
> +	{ 0x011c, 0x12 },
> +	{ 0x0121, 0x02 }, //T_LPX
> +	{ 0x0122, 0x03 }, //T_CLK_HS_PREPARE
> +	{ 0x0123, 0x0c }, //T_CLK_zero
> +	{ 0x0124, 0x00 }, //T_CLK_PRE
> +	{ 0x0125, 0x09 }, //T_CLK_POST
> +	{ 0x0126, 0x06 }, //T_CLK_TRAIL
> +	{ 0x0129, 0x04 }, //T_HS_PREPARE
> +	{ 0x012a, 0x03 }, //T_HS_Zero
> +	{ 0x012b, 0x06 }, //T_HS_TRAIL
> +
> +	{ 0x0a73, 0x60 },
> +	{ 0x0a70, 0x11 },
> +	{ 0x0313, 0x80 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0a70, 0x00 },
> +	{ 0x00a4, 0x80 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0a67, 0x00 },
> +	{ 0x0084, 0x10 },
> +	{ 0x0102, 0x09 },
> +
> +	{ GC08A3_TABLE_END, 0x00 }
> +};
> +
> +static const struct reg_8 mode_table_common[] = {
> +	{ GC08A3_STRAEMING_REG, 0x00 },
> +	/*system*/
> +	{ 0x031c, 0x60 },
> +	{ 0x0337, 0x04 },
> +	{ 0x0335, 0x51 },
> +	{ 0x0336, 0x70 },
> +	{ 0x0383, 0xbb },
> +	{ 0x031a, 0x00 },
> +	{ 0x0321, 0x10 },
> +	{ 0x0327, 0x03 },
> +	{ 0x0325, 0x40 },
> +	{ 0x0326, 0x23 },
> +	{ 0x0314, 0x11 },
> +	{ 0x0315, 0xd6 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0334, 0x40 },
> +	{ 0x0324, 0x42 },
> +	{ 0x031c, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x039a, 0x13 },
> +	{ 0x0084, 0x30 },
> +	{ 0x02b3, 0x08 },
> +	{ 0x0057, 0x0c },
> +	{ 0x05c3, 0x50 },
> +	{ 0x0311, 0x90 },
> +	{ 0x05a0, 0x02 },
> +	{ 0x0074, 0x0a },
> +	{ 0x0059, 0x11 },
> +	{ 0x0070, 0x05 },
> +	{ 0x0101, 0x00 }, //[1]updown [0]mirror
> +
> +	/*analog*/
> +	{ 0x0344, 0x00 },
> +	{ 0x0345, 0x06 },
> +	{ 0x0346, 0x00 },
> +	{ 0x0347, 0x04 },
> +	{ 0x0348, 0x0c },
> +	{ 0x0349, 0xd0 }, //3280
> +	{ 0x034a, 0x09 },
> +	{ 0x034b, 0x9c }, //2460
> +	{ 0x0202, 0x09 },
> +	{ 0x0203, 0x04 }, //Exp
> +
> +	{ 0x0219, 0x05 }, //[4]FL_depend_exp
> +	{ 0x0226, 0x00 }, //min vb[15:8]
> +	{ 0x0227, 0x28 }, //min vb[7:0]
> +	{ 0x0e0a, 0x00 },
> +	{ 0x0e0b, 0x00 },
> +	{ 0x0e24, 0x04 },
> +	{ 0x0e25, 0x04 },
> +	{ 0x0e26, 0x00 },
> +	{ 0x0e27, 0x10 },
> +	{ 0x0e01, 0x74 },
> +	{ 0x0e03, 0x47 },
> +	{ 0x0e04, 0x33 },
> +	{ 0x0e05, 0x44 },
> +	{ 0x0e06, 0x44 },
> +	{ 0x0e0c, 0x1e },
> +	{ 0x0e17, 0x3a },
> +	{ 0x0e18, 0x3c },
> +	{ 0x0e19, 0x40 },
> +	{ 0x0e1a, 0x42 },
> +	{ 0x0e28, 0x21 },
> +	{ 0x0e2b, 0x68 },
> +	{ 0x0e2c, 0x0d },
> +	{ 0x0e2d, 0x08 },
> +	{ 0x0e34, 0xf4 },
> +	{ 0x0e35, 0x44 },
> +	{ 0x0e36, 0x07 },
> +	{ 0x0e38, 0x49 },
> +	{ 0x0210, 0x13 },
> +	{ 0x0218, 0x00 },
> +	{ 0x0241, 0x88 },
> +	{ 0x0e32, 0x00 },
> +	{ 0x0e33, 0x18 },
> +	{ 0x0e42, 0x03 },
> +	{ 0x0e43, 0x80 },
> +	{ 0x0e44, 0x04 },
> +	{ 0x0e45, 0x00 },
> +	{ 0x0e4f, 0x04 },
> +	{ 0x057a, 0x20 },
> +	{ 0x0381, 0x7c },
> +	{ 0x0382, 0x9b },
> +	{ 0x0384, 0xfb },
> +	{ 0x0389, 0x38 },
> +	{ 0x038a, 0x03 },
> +	{ 0x0390, 0x6a },
> +	{ 0x0391, 0x0b },
> +	{ 0x0392, 0x60 },
> +	{ 0x0393, 0xc1 },
> +	{ 0x0396, 0xff },
> +	{ 0x0398, 0x62 },
> +
> +	/*cisctl reset*/
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 }, //CISCTL_rst
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 }, //CISCTL_rst
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x0360, 0x01 },
> +	{ 0x0360, 0x00 },
> +	{ 0x0316, 0x09 },
> +	{ 0x0a67, 0x80 },
> +	{ 0x0313, 0x00 },
> +	{ 0x0a53, 0x0e },
> +	{ 0x0a65, 0x17 },
> +	{ 0x0a68, 0xa1 },
> +	{ 0x0a58, 0x00 },
> +	{ 0x0ace, 0x0c },
> +	{ 0x00a4, 0x00 },
> +	{ 0x00a5, 0x01 },
> +	{ 0x00a7, 0x09 },
> +	{ 0x00a8, 0x9c },
> +	{ 0x00a9, 0x0c },
> +	{ 0x00aa, 0xd0 },
> +	{ 0x0a8a, 0x00 },
> +	{ 0x0a8b, 0xe0 },
> +	{ 0x0a8c, 0x13 },
> +	{ 0x0a8d, 0xe8 },
> +	{ 0x0a90, 0x0a },
> +	{ 0x0a91, 0x10 },
> +	{ 0x0a92, 0xf8 },
> +	{ 0x0a71, 0xf2 },
> +	{ 0x0a72, 0x12 },
> +	{ 0x0a73, 0x64 },
> +	{ 0x0a75, 0x41 },
> +	{ 0x0a70, 0x07 },
> +	{ 0x0313, 0x80 },
> +
> +	/*ISP*/
> +	{ 0x00a0, 0x01 },
> +	{ 0x0080, 0xd2 },
> +	{ 0x0081, 0x3f },
> +	{ 0x0087, 0x51 },
> +	{ 0x0089, 0x03 },
> +	{ 0x009b, 0x40 },
> +	{ 0x05a0, 0x82 },
> +	{ 0x05ac, 0x00 },
> +	{ 0x05ad, 0x01 },
> +	{ 0x05ae, 0x00 },
> +	{ 0x0800, 0x0a },
> +	{ 0x0801, 0x14 },
> +	{ 0x0802, 0x28 },
> +	{ 0x0803, 0x34 },
> +	{ 0x0804, 0x0e },
> +	{ 0x0805, 0x33 },
> +	{ 0x0806, 0x03 },
> +	{ 0x0807, 0x8a },
> +	{ 0x0808, 0x50 },
> +	{ 0x0809, 0x00 },
> +	{ 0x080a, 0x34 },
> +	{ 0x080b, 0x03 },
> +	{ 0x080c, 0x26 },
> +	{ 0x080d, 0x03 },
> +	{ 0x080e, 0x18 },
> +	{ 0x080f, 0x03 },
> +	{ 0x0810, 0x10 },
> +	{ 0x0811, 0x03 },
> +	{ 0x0812, 0x00 },
> +	{ 0x0813, 0x00 },
> +	{ 0x0814, 0x01 },
> +	{ 0x0815, 0x00 },
> +	{ 0x0816, 0x01 },
> +	{ 0x0817, 0x00 },
> +	{ 0x0818, 0x00 },
> +	{ 0x0819, 0x0a },
> +	{ 0x081a, 0x01 },
> +	{ 0x081b, 0x6c },
> +	{ 0x081c, 0x00 },
> +	{ 0x081d, 0x0b },
> +	{ 0x081e, 0x02 },
> +	{ 0x081f, 0x00 },
> +	{ 0x0820, 0x00 },
> +	{ 0x0821, 0x0c },
> +	{ 0x0822, 0x02 },
> +	{ 0x0823, 0xd9 },
> +	{ 0x0824, 0x00 },
> +	{ 0x0825, 0x0d },
> +	{ 0x0826, 0x03 },
> +	{ 0x0827, 0xf0 },
> +	{ 0x0828, 0x00 },
> +	{ 0x0829, 0x0e },
> +	{ 0x082a, 0x05 },
> +	{ 0x082b, 0x94 },
> +	{ 0x082c, 0x09 },
> +	{ 0x082d, 0x6e },
> +	{ 0x082e, 0x07 },
> +	{ 0x082f, 0xe6 },
> +	{ 0x0830, 0x10 },
> +	{ 0x0831, 0x0e },
> +	{ 0x0832, 0x0b },
> +	{ 0x0833, 0x2c },
> +	{ 0x0834, 0x14 },
> +	{ 0x0835, 0xae },
> +	{ 0x0836, 0x0f },
> +	{ 0x0837, 0xc4 },
> +	{ 0x0838, 0x18 },
> +	{ 0x0839, 0x0e },
> +	{ 0x05ac, 0x01 },
> +	{ 0x059a, 0x00 },
> +	{ 0x059b, 0x00 },
> +	{ 0x059c, 0x01 },
> +	{ 0x0598, 0x00 },
> +	{ 0x0597, 0x14 },
> +	{ 0x05ab, 0x09 },
> +	{ 0x05a4, 0x02 },
> +	{ 0x05a3, 0x05 },
> +	{ 0x05a0, 0xc2 },
> +	{ 0x0207, 0xc4 },
> +
> +	/*GAIN*/
> +	{ 0x0208, 0x01 },
> +	{ 0x0209, 0x72 },
> +	{ 0x0204, 0x04 },
> +	{ 0x0205, 0x00 },
> +
> +	{ 0x0040, 0x22 },
> +	{ 0x0041, 0x20 },
> +	{ 0x0043, 0x10 },
> +	{ 0x0044, 0x00 },
> +	{ 0x0046, 0x08 },
> +	{ 0x0047, 0xf0 },
> +	{ 0x0048, 0x0f },
> +	{ 0x004b, 0x0f },
> +	{ 0x004c, 0x00 },
> +	{ 0x0050, 0x5c },
> +	{ 0x0051, 0x44 },
> +	{ 0x005b, 0x03 },
> +	{ 0x00c0, 0x00 },
> +	{ 0x00c1, 0x80 },
> +	{ 0x00c2, 0x31 },
> +	{ 0x00c3, 0x00 },
> +	{ 0x0460, 0x04 },
> +	{ 0x0462, 0x08 },
> +	{ 0x0464, 0x0e },
> +	{ 0x0466, 0x0a },
> +	{ 0x0468, 0x12 },
> +	{ 0x046a, 0x12 },
> +	{ 0x046c, 0x10 },
> +	{ 0x046e, 0x0c },
> +	{ 0x0461, 0x03 },
> +	{ 0x0463, 0x03 },
> +	{ 0x0465, 0x03 },
> +	{ 0x0467, 0x03 },
> +	{ 0x0469, 0x04 },
> +	{ 0x046b, 0x04 },
> +	{ 0x046d, 0x04 },
> +	{ 0x046f, 0x04 },
> +	{ 0x0470, 0x04 },
> +	{ 0x0472, 0x10 },
> +	{ 0x0474, 0x26 },
> +	{ 0x0476, 0x38 },
> +	{ 0x0478, 0x20 },
> +	{ 0x047a, 0x30 },
> +	{ 0x047c, 0x38 },
> +	{ 0x047e, 0x60 },
> +	{ 0x0471, 0x05 },
> +	{ 0x0473, 0x05 },
> +	{ 0x0475, 0x05 },
> +	{ 0x0477, 0x05 },
> +	{ 0x0479, 0x04 },
> +	{ 0x047b, 0x04 },
> +	{ 0x047d, 0x04 },
> +	{ 0x047f, 0x04 },
> +
> +	{ GC08A3_TABLE_END, 0x00 }
> +};
> +
> +static const struct gc08a3_link_freq_config link_freq_configs[] = {
> +	[GC08A3_LINK_FREQ_336MHZ_CFG] = {
> +		.reg_list = {
> +			.num_of_regs = ARRAY_SIZE(mode_table_common),
> +			.regs = mode_table_common,
> +		}
> +	},
> +	[GC08A3_LINK_FREQ_207MHZ_CFG] = {
> +		.reg_list = {
> +			.num_of_regs = ARRAY_SIZE(mode_table_common),
> +			.regs = mode_table_common,
> +		}
> +	},
> +

Extra blank line.

> +};
> +
> +enum {
> +	GC08A3_PREV,
> +	GC08A3_HS,
> +};
> +
> +/*
> + * Declare modes in order, from biggest
> + * to smallest height.
> + */
> +static const struct gc08a3_mode {
> +	u8 mode_id;
> +	u32 width;
> +	u32 height;
> +	const struct gc08a3_reg_list reg_list;
> +
> +	u32 hts; /* Horizontal timining size */
> +	u32 vts_def; /* Default vertical timining size */
> +	u32 vts_min; /* Min vertical timining size */
> +	u32 link_freq_index; /* Link frequency needed for this resolution */
> +	u32 max_framerate;
> +

Extra blank line.

> +} gc08a3_modes[] = {
> +	{
> +		.mode_id = GC08A3_PREV,
> +		.width = 3264,
> +		.height = 2448,
> +		.reg_list = {
> +			.num_of_regs = ARRAY_SIZE(mode_3264x2448),
> +			.regs = mode_3264x2448,
> +		},
> +		.link_freq_index = GC08A3_LINK_FREQ_336MHZ_CFG,
> +
> +		.hts = GC08A3_HTS_30FPS,
> +		.vts_def = GC08A3_VTS_30FPS,
> +		.vts_min = GC08A3_VTS_30FPS_MIN,
> +		.max_framerate = 300,
> +	},
> +	{
> +		.mode_id = GC08A3_HS,
> +		.width = 1920,
> +		.height = 1080,
> +		.reg_list = {
> +			.num_of_regs = ARRAY_SIZE(mode_1920x1080),
> +			.regs = mode_1920x1080,
> +		},
> +		.link_freq_index = GC08A3_LINK_FREQ_207MHZ_CFG,
> +
> +		.hts = GC08A3_HTS_60FPS,
> +		.vts_def = GC08A3_VTS_60FPS,
> +		.vts_min = GC08A3_VTS_60FPS_MIN,
> +		.max_framerate = 600,
> +	},
> +};
> +
> +static u64 to_pixel_rate(u32 f_index)
> +{
> +	u64 pixel_rate = link_freq_menu_items[f_index] * 2 * GC08A3_DATA_LANES;
> +
> +	do_div(pixel_rate, GC08A3_RGB_DEPTH);
> +
> +	return pixel_rate;
> +}
> +
> +static u64 __maybe_unused to_pixels_per_line(u32 hts, u32 f_index)
> +{
> +	u64 ppl = hts * to_pixel_rate(f_index);
> +
> +	do_div(ppl, GC08A3_SCLK);
> +
> +	return ppl;
> +}
> +
> +static int gc08a3_read_reg(struct gc08a3 *gc08a3, u16 reg, u16 len, u32 *val)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	struct i2c_msg msgs[2];
> +	u8 addr_buf[2];
> +	u8 data_buf[4] = { 0 };
> +	int ret;
> +
> +	if (len > 4)
> +		return -EINVAL;
> +
> +	put_unaligned_be16(reg, addr_buf);
> +	msgs[0].addr = client->addr;
> +	msgs[0].flags = 0;
> +	msgs[0].len = sizeof(addr_buf);
> +	msgs[0].buf = addr_buf;
> +	msgs[1].addr = client->addr;
> +	msgs[1].flags = I2C_M_RD;
> +	msgs[1].len = len;
> +	msgs[1].buf = &data_buf[4 - len];
> +
> +	ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
> +	if (ret != ARRAY_SIZE(msgs))
> +		return -EIO;
> +
> +	*val = get_unaligned_be32(data_buf);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_write_reg(struct gc08a3 *gc08a3, u16 reg, u16 len, u32 val)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	u8 buf[6];
> +
> +	if (len > 4)
> +		return -EINVAL;
> +
> +	put_unaligned_be16(reg, buf);
> +	put_unaligned_be32(val << 8 * (4 - len), buf + 2);
> +	if (i2c_master_send(client, buf, len + 2) != len + 2)
> +		return -EIO;
> +
> +	return 0;
> +}
> +
> +static int gc08a3_write_reg_list(struct gc08a3 *gc08a3,
> +				 const struct gc08a3_reg_list *r_list)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	unsigned int i;
> +	int ret;
> +
> +	for (i = 0; i < r_list->num_of_regs; i++) {
> +		if (r_list->regs[i].address == GC08A3_TABLE_WAIT_MS) {
> +			usleep_range(r_list->regs[i].val * 1000,
> +				     r_list->regs[i].val * 1000 + 500);
> +			continue;
> +		}
> +
> +		if (r_list->regs[i].address == GC08A3_TABLE_END)
> +			break;
> +
> +		ret = gc08a3_write_reg(gc08a3, r_list->regs[i].address,
> +				       GC08A3_REG_VALUE_08BIT,
> +				       r_list->regs[i].val);
> +		if (ret) {
> +			dev_err_ratelimited(&client->dev,
> +					    "failed to write reg 0x%4.4x. error = %d",
> +					    r_list->regs[i].address, ret);
> +			return ret;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static int gc08a3_identify_module(struct gc08a3 *gc08a3)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	u32 val = 0;
> +
> +	gc08a3_read_reg(gc08a3, GC08A3_REG_CHIP_ID, GC08A3_REG_VALUE_16BIT,
> +			&val);
> +
> +	if (val != GC08A3_CHIP_ID) {
> +		dev_err(&client->dev, "chip id mismatch: 0x%x!=0x%x",
> +			GC08A3_CHIP_ID, val);
> +		return -ENXIO;
> +	}
> +
> +	dev_info(&client->dev, "sensor_id: 0x%04x\n", val);
> +	return 0;
> +}
> +
> +static inline struct gc08a3 *to_gc08a3(struct v4l2_subdev *sd)
> +{
> +	return container_of(sd, struct gc08a3, sd);
> +}
> +
> +static int __maybe_unused gc08a3_power_on(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +	int ret;
> +
> +	dev_info(dev, "--- %s +", __func__);

Drop this. Tracing is done with ftrace. Same comment below where
applicable.

> +
> +	gpiod_set_value_cansleep(gc08a3->enable_gpio, 0);
> +	usleep_range(2000, 3000);
> +
> +	ret = regulator_bulk_enable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
> +	if (ret < 0) {
> +		dev_err(gc08a3->dev, "failed to enable regulators: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = clk_prepare_enable(gc08a3->xclk);
> +	if (ret < 0) {
> +		regulator_bulk_disable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
> +		dev_err(gc08a3->dev, "clk prepare enable failed\n");
> +		return ret;
> +	}
> +
> +	usleep_range(2000, 3000);
> +
> +	gpiod_set_value_cansleep(gc08a3->enable_gpio, 1);
> +	usleep_range(12000, 15000);
> +
> +	dev_info(dev, "--- %s -", __func__);
> +
> +	return 0;
> +}
> +
> +static int __maybe_unused gc08a3_power_off(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	dev_info(dev, "--- %s +", __func__);
> +
> +	gpiod_set_value_cansleep(gc08a3->enable_gpio, 0);
> +
> +	clk_disable_unprepare(gc08a3->xclk);
> +
> +	regulator_bulk_disable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
> +	usleep_range(10, 20);
> +
> +	dev_info(dev, "--- %s -", __func__);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_enum_mbus_code(struct v4l2_subdev *sd,
> +				 struct v4l2_subdev_state *sd_state,
> +				 struct v4l2_subdev_mbus_code_enum *code)
> +{
> +	if (code->index > 0)
> +		return -EINVAL;
> +
> +	code->code = GC08A3_MBUS_CODE;
> +
> +	return 0;
> +}
> +
> +static int gc08a3_enum_frame_size(struct v4l2_subdev *subdev,
> +				  struct v4l2_subdev_state *sd_state,
> +				  struct v4l2_subdev_frame_size_enum *fse)
> +{
> +	if (fse->code != GC08A3_MBUS_CODE)
> +		return -EINVAL;
> +
> +	if (fse->index >= ARRAY_SIZE(gc08a3_modes))
> +		return -EINVAL;
> +
> +	fse->min_width = gc08a3_modes[fse->index].width;
> +	fse->max_width = gc08a3_modes[fse->index].width;
> +	fse->min_height = gc08a3_modes[fse->index].height;
> +	fse->max_height = gc08a3_modes[fse->index].height;
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +static int gc08a3_g_register(struct v4l2_subdev *subdev,
> +			     struct v4l2_dbg_register *reg)
> +{
> +	int ret;
> +	u32 val;
> +	struct gc08a3 *gc08a3 = container_of(subdev, struct gc08a3, sd);
> +
> +	ret = gc08a3_read_reg(gc08a3, reg->reg, GC08A3_REG_VALUE_08BIT, &val);
> +	if (ret < 0)
> +		return ret;
> +
> +	reg->val = val;
> +	reg->size = 1;
> +
> +	return 0;
> +}
> +
> +static int gc08a3_s_register(struct v4l2_subdev *subdev,
> +			     const struct v4l2_dbg_register *reg)
> +{
> +	struct gc08a3 *gc08a3 = container_of(subdev, struct gc08a3, sd);
> +
> +	return gc08a3_write_reg(gc08a3, reg->reg, GC08A3_REG_VALUE_08BIT,
> +				reg->val & 0xff);
> +}
> +
> +#endif
> +
> +static const struct v4l2_subdev_core_ops gc08a3_core_ops = {
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +	.g_register = gc08a3_g_register,
> +	.s_register = gc08a3_s_register,
> +#endif

Drop these too. If you need to access registers directly from userspace
for development purpose, you can do so through i2cdev.

> +};
> +
> +static struct v4l2_mbus_framefmt *
> +__gc08a3_get_pad_format(struct gc08a3 *gc08a3,
> +			struct v4l2_subdev_state *sd_state, unsigned int pad,
> +			enum v4l2_subdev_format_whence which)
> +{
> +	switch (which) {
> +	case V4L2_SUBDEV_FORMAT_TRY:
> +		return v4l2_subdev_get_try_format(&gc08a3->sd, sd_state, pad);
> +	case V4L2_SUBDEV_FORMAT_ACTIVE:
> +		return &gc08a3->fmt;
> +	default:
> +		return NULL;
> +	}
> +}
> +
> +static int gc08a3_get_format(struct v4l2_subdev *sd,
> +			     struct v4l2_subdev_state *sd_state,
> +			     struct v4l2_subdev_format *format)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	mutex_lock(&gc08a3->mutex);
> +	format->format = *__gc08a3_get_pad_format(gc08a3, sd_state, format->pad,
> +						  format->which);
> +	mutex_unlock(&gc08a3->mutex);
> +
> +	return 0;
> +}
> +
> +static struct v4l2_rect *
> +__gc08a3_get_pad_crop(struct gc08a3 *gc08a3, struct v4l2_subdev_state *sd_state,
> +		      unsigned int pad, enum v4l2_subdev_format_whence which)
> +{
> +	switch (which) {
> +	case V4L2_SUBDEV_FORMAT_TRY:
> +		return v4l2_subdev_get_try_crop(&gc08a3->sd, sd_state, pad);
> +	case V4L2_SUBDEV_FORMAT_ACTIVE:
> +		return &gc08a3->crop;
> +	default:
> +		return NULL;
> +	}
> +}
> +
> +static int gc08a3_update_cur_mode_controls(struct gc08a3 *gc08a3)
> +{
> +	s64 exposure_max, h_blank;
> +	int ret = 0;
> +
> +	ret = __v4l2_ctrl_modify_range(gc08a3->vblank,
> +				       gc08a3->cur_mode->vts_min - gc08a3->cur_mode->height,
> +				       GC08A3_VTS_MAX - gc08a3->cur_mode->height, 1,
> +				       gc08a3->cur_mode->vts_def - gc08a3->cur_mode->height);
> +	if (ret)
> +		dev_err(gc08a3->dev, "VB ctrl range update failed\n");
> +
> +	h_blank = gc08a3->cur_mode->hts - gc08a3->cur_mode->width;
> +	ret = __v4l2_ctrl_modify_range(gc08a3->hblank, h_blank, h_blank, 1,
> +				       h_blank);
> +	if (ret)
> +		dev_err(gc08a3->dev, "HB ctrl range update failed\n");
> +
> +	exposure_max = gc08a3->cur_mode->vts_def - GC08A3_EXP_MARGIN;
> +	ret = __v4l2_ctrl_modify_range(gc08a3->exposure, GC08A3_EXP_MIN,
> +				       exposure_max, GC08A3_EXP_STEP,
> +				       exposure_max);
> +	if (ret)
> +		dev_err(gc08a3->dev, "exposure ctrl range update failed\n");
> +
> +	return ret;
> +}
> +
> +static int gc08a3_set_format(struct v4l2_subdev *sd,
> +			     struct v4l2_subdev_state *sd_state,
> +			     struct v4l2_subdev_format *format)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	struct device *dev = &client->dev;
> +	struct v4l2_mbus_framefmt *__format;
> +	struct v4l2_rect *__crop;
> +	const struct gc08a3_mode *mode;
> +
> +	mutex_lock(&gc08a3->mutex);
> +
> +	dev_dbg(dev, "---- %s, format(W x H:%d x %d)  +", __func__,
> +		format->format.width, format->format.height);
> +
> +	__crop = __gc08a3_get_pad_crop(gc08a3, sd_state, format->pad,
> +				       format->which);
> +
> +	mode = v4l2_find_nearest_size(gc08a3_modes, ARRAY_SIZE(gc08a3_modes),
> +				      width, height, format->format.width,
> +				      format->format.height);
> +
> +	dev_dbg(dev, "----nearest mode(W x H:%d x %d)", mode->width,
> +		mode->height);
> +
> +	__crop->width = mode->width;
> +	__crop->height = mode->height;
> +
> +	__format = __gc08a3_get_pad_format(gc08a3, sd_state, format->pad,
> +					   format->which);
> +	__format->width = __crop->width;
> +	__format->height = __crop->height;
> +	__format->code = GC08A3_MBUS_CODE;
> +	__format->field = V4L2_FIELD_NONE;
> +	__format->colorspace = V4L2_COLORSPACE_SRGB;
> +	__format->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(__format->colorspace);
> +	__format->quantization =
> +		V4L2_MAP_QUANTIZATION_DEFAULT(true,
> +					      __format->colorspace,
> +					      __format->ycbcr_enc);
> +	__format->xfer_func = V4L2_MAP_XFER_FUNC_DEFAULT(__format->colorspace);
> +
> +	format->format = *__format;
> +
> +	gc08a3->cur_mode = mode;
> +	gc08a3_update_cur_mode_controls(gc08a3);
> +
> +	mutex_unlock(&gc08a3->mutex);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_get_selection(struct v4l2_subdev *sd,
> +				struct v4l2_subdev_state *sd_state,
> +				struct v4l2_subdev_selection *sel)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	switch (sel->target) {
> +	case V4L2_SEL_TGT_CROP:
> +		mutex_lock(&gc08a3->mutex);
> +		sel->r = *__gc08a3_get_pad_crop(gc08a3, sd_state, sel->pad, sel->which);
> +		mutex_unlock(&gc08a3->mutex);
> +		break;
> +	case V4L2_SEL_TGT_CROP_BOUNDS:
> +		sel->r.top = 0;
> +		sel->r.left = 0;
> +		sel->r.width = GC08A3_NATIVE_WIDTH;
> +		sel->r.height = GC08A3_NATIVE_HEIGHT;
> +		break;
> +	case V4L2_SEL_TGT_CROP_DEFAULT:
> +		if (gc08a3->cur_mode->width == GC08A3_NATIVE_WIDTH) {
> +			sel->r.top = 0;
> +			sel->r.left = 0;
> +			sel->r.width = GC08A3_NATIVE_WIDTH;
> +			sel->r.height = GC08A3_NATIVE_HEIGHT;
> +		} else {
> +			sel->r.top = 0;
> +			sel->r.left = 0;
> +			sel->r.width = 1920;
> +			sel->r.height = 1080;
> +		}
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int gc08a3_entity_init_cfg(struct v4l2_subdev *subdev,
> +				  struct v4l2_subdev_state *sd_state)
> +{
> +	struct v4l2_subdev_format fmt = {};
> +
> +	fmt.which = sd_state ? V4L2_SUBDEV_FORMAT_TRY :
> +			       V4L2_SUBDEV_FORMAT_ACTIVE;
> +	fmt.format.width = gc08a3_modes[0].width;
> +	fmt.format.height = gc08a3_modes[0].height;
> +
> +	gc08a3_set_format(subdev, sd_state, &fmt);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_set_ctrl_hflip(struct gc08a3 *gc08a3, u32 ctrl_val)
> +{
> +	int ret;
> +	u32 val;
> +
> +	ret = gc08a3_read_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
> +			      &val);
> +	if (ret) {
> +		dev_err(gc08a3->dev, "read hflip register failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	val = (ctrl_val) ? (val | GC08A3_FLIP_H_MASK) :
> +			   (val & ~GC08A3_FLIP_H_MASK);
> +	ret = gc08a3_write_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
> +			       val);
> +	if (ret < 0)
> +		dev_err(gc08a3->dev, "Error %d\n", ret);
> +
> +	return ret;
> +}
> +
> +static int gc08a3_set_ctrl_vflip(struct gc08a3 *gc08a3, u32 ctrl_val)
> +{
> +	int ret;
> +	u32 val;
> +
> +	ret = gc08a3_read_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
> +			      &val);
> +	if (ret) {
> +		dev_err(gc08a3->dev, "read vflip register failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	val = (ctrl_val) ? (val | GC08A3_FLIP_V_MASK) :
> +			   (val & ~GC08A3_FLIP_V_MASK);
> +	ret = gc08a3_write_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
> +			       val);
> +	if (ret < 0)
> +		dev_err(gc08a3->dev, "Error %d\n", ret);
> +
> +	return ret;
> +}
> +
> +static int gc08a3_test_pattern(struct gc08a3 *gc08a3, u32 pattern_menu)
> +{
> +	int ret = 0;
> +	u32 pattern = 0;
> +
> +	if (pattern_menu) {
> +		// write bit16:0x0110 -> color bar
> +		switch (pattern_menu) {
> +		case 1:
> +			pattern = 0x00;
> +			break;
> +		case 2:
> +		case 3:
> +		case 4:
> +		case 5:
> +		case 6:
> +			pattern = pattern_menu + 2;
> +			break;
> +		case 7:
> +			pattern = 0x10;
> +			break;
> +
> +		default:
> +			dev_dbg(gc08a3->dev, "invalid pattern menu!\n");
> +			break;
> +		}
> +
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_REG_TEST_PATTERN_EN,
> +				       GC08A3_REG_VALUE_08BIT,
> +				       GC08A3_TEST_PATTERN_EN);
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_REG_TEST_PATTERN_IDX,
> +				       GC08A3_REG_VALUE_08BIT, pattern);
> +
> +	} else {
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_REG_TEST_PATTERN_EN,
> +				       GC08A3_REG_VALUE_08BIT, 0x00);
> +	}
> +
> +	return ret;
> +}
> +
> +static int gc08a3_set_ctrl(struct v4l2_ctrl *ctrl)
> +{
> +	struct gc08a3 *gc08a3 =
> +		container_of(ctrl->handler, struct gc08a3, ctrls);
> +	int ret = 0;
> +	s64 exposure_max;
> +
> +	if (ctrl->id == V4L2_CID_VBLANK) {
> +		/* Update max exposure while meeting expected vblanking */
> +		exposure_max = gc08a3->cur_mode->height + ctrl->val -
> +			       GC08A3_EXP_MARGIN;
> +		__v4l2_ctrl_modify_range(gc08a3->exposure,
> +					 gc08a3->exposure->minimum,
> +					 exposure_max, gc08a3->exposure->step,
> +					 exposure_max);
> +	}
> +
> +	/*
> +	 * Applying V4L2 control value only happens
> +	 * when power is up for streaming
> +	 */
> +	if (!pm_runtime_get_if_in_use(gc08a3->dev))
> +		return 0;
> +
> +	switch (ctrl->id) {
> +	case V4L2_CID_EXPOSURE:
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_EXP_REG,
> +				       GC08A3_REG_VALUE_16BIT, ctrl->val);
> +		break;
> +
> +	case V4L2_CID_ANALOGUE_GAIN:
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_AGAIN_REG,
> +				       GC08A3_REG_VALUE_16BIT, ctrl->val);
> +		break;
> +
> +	case V4L2_CID_VBLANK:
> +		dev_info(gc08a3->dev, "V4L2_CID_VBLANK:height:%d, V_BLNK:%d\n",
> +			 gc08a3->cur_mode->height, ctrl->val);

I would drop this too, or at the very least convert it to dev_dbg().
There should be no message but debug messages printed by the driver to
the kernel log during normal operation.

> +		ret = gc08a3_write_reg(gc08a3, GC08A3_FL_REG,
> +				       GC08A3_REG_VALUE_16BIT,
> +				       gc08a3->cur_mode->height + ctrl->val);
> +		break;
> +
> +	case V4L2_CID_HFLIP:
> +		gc08a3_set_ctrl_hflip(gc08a3, ctrl->val);
> +		break;
> +
> +	case V4L2_CID_VFLIP:
> +		gc08a3_set_ctrl_vflip(gc08a3, ctrl->val);
> +		break;
> +
> +	case V4L2_CID_TEST_PATTERN:
> +		ret = gc08a3_test_pattern(gc08a3, ctrl->val);
> +		break;
> +
> +	default:
> +		break;
> +	}
> +
> +	pm_runtime_put(gc08a3->dev);
> +
> +	return ret;
> +}
> +
> +static int get_volatile_ext_ctrl(struct v4l2_ctrl *ctrl)
> +{
> +	int ret = 0;
> +	struct gc08a3 *gc08a3 =
> +		container_of(ctrl->handler, struct gc08a3, ctrls);
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +
> +	dev_dbg(&client->dev, "---- %s, CMD:0x%x\n", __func__, ctrl->id);
> +	switch (ctrl->id) {
> +	default:
> +		dev_info(&client->dev, "[gc08a3] %s, un-support CMD: 0x%x\n",
> +			 __func__, ctrl->id);
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +static int gc08a3_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
> +{
> +	int ret = 0;
> +
> +	switch (ctrl->id) {
> +	default:
> +		ret = get_volatile_ext_ctrl(ctrl);
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +static int try_ext_ctrl(struct v4l2_ctrl *ctrl)
> +{
> +	int ret = 0;
> +	struct gc08a3 *gc08a3 =
> +		container_of(ctrl->handler, struct gc08a3, ctrls);
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +
> +	switch (ctrl->id) {
> +	default:
> +		dev_dbg(&client->dev,
> +			"[gc08a3] un-handle CMD: 0x%x (%s : %d)\n", ctrl->id,
> +			__func__, __LINE__);
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +static int gc08a3_try_ctrl(struct v4l2_ctrl *ctrl)
> +{
> +	int ret = 0;
> +
> +	switch (ctrl->id) {
> +	case V4L2_CID_EXPOSURE:
> +	case V4L2_CID_ANALOGUE_GAIN:
> +	case V4L2_CID_VBLANK:
> +	case V4L2_CID_HFLIP:
> +	case V4L2_CID_VFLIP:
> +	case V4L2_CID_TEST_PATTERN:
> +		return 0;
> +
> +	default:
> +		ret = try_ext_ctrl(ctrl);
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +static const struct v4l2_ctrl_ops gc08a3_ctrl_ops = {
> +	.g_volatile_ctrl = gc08a3_g_volatile_ctrl,
> +	.try_ctrl = gc08a3_try_ctrl,

Drop the .g_volatile_ctrl() and .try_ctrl() implementations, they don't
do anything, and the operations are optional.

> +	.s_ctrl = gc08a3_set_ctrl,
> +};
> +
> +static int gc08a3_start_streaming(struct gc08a3 *gc08a3)
> +{
> +	const struct gc08a3_mode *mode;
> +	const struct gc08a3_reg_list *reg_list;
> +	int link_freq_index;
> +	int ret;
> +
> +	dev_info(gc08a3->dev, "%s ++\n", __func__);
> +
> +	mutex_lock(&gc08a3->mutex);
> +
> +	link_freq_index = gc08a3->cur_mode->link_freq_index;
> +	dev_info(gc08a3->dev, "----link_freq_index = %d ", link_freq_index);
> +
> +	reg_list = &link_freq_configs[link_freq_index].reg_list;
> +	ret = gc08a3_write_reg_list(gc08a3, reg_list);
> +	if (ret) {
> +		dev_err(gc08a3->dev, "could not sent common table %d\n", ret);
> +		goto error;
> +	}
> +
> +	mode = gc08a3->cur_mode;
> +	dev_info(gc08a3->dev, "----write regtbl: mode(id:%d, WxH:%dx%d)",
> +		 mode->mode_id, mode->width, mode->height);
> +	reg_list = &mode->reg_list;
> +
> +	ret = gc08a3_write_reg_list(gc08a3, reg_list);
> +	if (ret < 0) {
> +		dev_err(gc08a3->dev, "could not sent mode table %d\n", ret);
> +		goto error;
> +	}
> +	ret = __v4l2_ctrl_handler_setup(&gc08a3->ctrls);
> +	if (ret < 0) {
> +		dev_err(gc08a3->dev, "could not sync v4l2 controls\n");
> +		goto error;
> +	}
> +
> +	ret = gc08a3_write_reg(gc08a3, GC08A3_STRAEMING_REG,
> +			       GC08A3_REG_VALUE_08BIT, 1);
> +	if (ret < 0) {
> +		dev_err(gc08a3->dev, "write STRAEMING_REG failed: %d\n", ret);
> +		goto error;
> +	}
> +
> +	mutex_unlock(&gc08a3->mutex);
> +
> +	dev_info(gc08a3->dev, "%s --\n", __func__);
> +
> +	return 0;
> +
> +error:
> +	mutex_unlock(&gc08a3->mutex);
> +	return ret;
> +}
> +
> +static int gc08a3_stop_streaming(struct gc08a3 *gc08a3)
> +{
> +	int ret;
> +
> +	dev_info(gc08a3->dev, "%s ++\n", __func__);
> +
> +	ret = gc08a3_write_reg(gc08a3, GC08A3_STRAEMING_REG,
> +			       GC08A3_REG_VALUE_08BIT, 0);
> +	if (ret < 0)
> +		dev_err(gc08a3->dev, "could not sent stop streaming %d\n", ret);
> +
> +	dev_info(gc08a3->dev, "%s --\n", __func__);
> +
> +	return ret;
> +}
> +
> +static int gc08a3_s_stream(struct v4l2_subdev *subdev, int enable)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(subdev);
> +	int ret;
> +
> +	if (gc08a3->streaming == enable)
> +		return 0;
> +
> +	if (enable) {
> +		ret = pm_runtime_resume_and_get(gc08a3->dev);
> +		if (ret < 0)
> +			return ret;
> +
> +		ret = gc08a3_start_streaming(gc08a3);
> +		if (ret < 0)
> +			goto err_rpm_put;
> +	} else {
> +		ret = gc08a3_stop_streaming(gc08a3);
> +		if (ret < 0)
> +			goto err_rpm_put;
> +		pm_runtime_put(gc08a3->dev);
> +	}
> +
> +	gc08a3->streaming = enable;
> +	return 0;
> +
> +err_rpm_put:
> +	pm_runtime_put(gc08a3->dev);
> +	return ret;
> +}
> +
> +static int gc08a3_g_mbus_config(struct v4l2_subdev *sd, unsigned int pad,
> +				struct v4l2_mbus_config *config)
> +{
> +	config->type = V4L2_MBUS_CSI2_DPHY;
> +	config->bus.mipi_csi2.num_data_lanes = 4;
> +	config->bus.mipi_csi2.flags = 0;
> +	return 0;
> +}
> +
> +static int gc08a3_g_frame_interval(struct v4l2_subdev *subdev,
> +				   struct v4l2_subdev_frame_interval *fival)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(subdev);
> +
> +	fival->interval.numerator = 1;
> +	fival->interval.denominator = gc08a3->cur_mode->max_framerate / 10;
> +
> +	return 0;
> +}
> +
> +static int
> +gc08a3_enum_frame_interval(struct v4l2_subdev *subdev,
> +			   struct v4l2_subdev_state *sd_state,
> +			   struct v4l2_subdev_frame_interval_enum *fie)
> +{
> +	const struct gc08a3_mode *mode;
> +
> +	if (fie->index != 0)
> +		return -EINVAL;
> +
> +	mode = v4l2_find_nearest_size(gc08a3_modes, ARRAY_SIZE(gc08a3_modes),
> +				      width, height, fie->width, fie->height);
> +
> +	fie->code = GC08A3_MBUS_CODE;
> +	fie->width = mode->width;
> +	fie->height = mode->height;
> +	fie->interval.numerator = 1;
> +	fie->interval.denominator = mode->max_framerate / 10;
> +
> +	return 0;
> +}
> +
> +static const struct v4l2_subdev_video_ops gc08a3_video_ops = {
> +	.s_stream = gc08a3_s_stream,
> +	.g_frame_interval = gc08a3_g_frame_interval,
> +	.s_frame_interval = gc08a3_g_frame_interval,
> +};
> +
> +static const struct v4l2_subdev_pad_ops gc08a3_subdev_pad_ops = {
> +	.enum_mbus_code = gc08a3_enum_mbus_code,
> +	.enum_frame_size = gc08a3_enum_frame_size,
> +	.enum_frame_interval = gc08a3_enum_frame_interval,
> +	.get_fmt = gc08a3_get_format,
> +	.set_fmt = gc08a3_set_format,
> +	.get_selection = gc08a3_get_selection,
> +	.init_cfg = gc08a3_entity_init_cfg,
> +	.get_mbus_config = gc08a3_g_mbus_config,
> +};
> +
> +static const struct v4l2_subdev_ops gc08a3_subdev_ops = {
> +	.core = &gc08a3_core_ops,
> +	.video = &gc08a3_video_ops,
> +	.pad = &gc08a3_subdev_pad_ops,
> +};
> +
> +static const struct regmap_config sensor_regmap_config = {
> +	.reg_bits = 16,
> +	.val_bits = 8,
> +	.cache_type = REGCACHE_RBTREE,
> +};
> +
> +static int gc08a3_get_regulators(struct device *dev, struct gc08a3 *gc08a3)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < GC08A3_NUM_SUPPLIES; i++)
> +		gc08a3->supplies[i].supply = gc08a3_supply_name[i];
> +
> +	return devm_regulator_bulk_get(dev, GC08A3_NUM_SUPPLIES,
> +				       gc08a3->supplies);
> +}
> +
> +static int gc08a3_parse_fwnode(struct device *dev)
> +{
> +	struct fwnode_handle *endpoint;
> +	struct v4l2_fwnode_endpoint bus_cfg = {
> +		.bus_type = V4L2_MBUS_CSI2_DPHY,
> +	};
> +	unsigned int i, j;
> +	int ret;
> +
> +	endpoint = fwnode_graph_get_next_endpoint(dev_fwnode(dev), NULL);
> +	if (!endpoint) {
> +		dev_err(dev, "endpoint node not found\n");
> +		return -EINVAL;
> +	}
> +
> +	ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, &bus_cfg);
> +	if (ret) {
> +		dev_err(dev, "parsing endpoint node failed\n");
> +		goto done;
> +	}
> +
> +	if (!bus_cfg.nr_of_link_frequencies) {
> +		dev_err(dev, "no link frequencies defined");
> +		ret = -EINVAL;
> +		goto done;
> +	}
> +
> +	for (i = 0; i < ARRAY_SIZE(link_freq_menu_items); i++) {
> +		for (j = 0; j < bus_cfg.nr_of_link_frequencies; j++) {
> +			if (link_freq_menu_items[i] ==
> +			    bus_cfg.link_frequencies[j])
> +				break;
> +		}
> +
> +		if (j == bus_cfg.nr_of_link_frequencies) {
> +			dev_err(dev,
> +				"no link frequency %lld supported, please check DT",
> +				link_freq_menu_items[i]);
> +			ret = -EINVAL;
> +			goto done;
> +		}
> +	}
> +
> +done:
> +	v4l2_fwnode_endpoint_free(&bus_cfg);
> +	fwnode_handle_put(endpoint);
> +	return ret;
> +}
> +
> +static int __maybe_unused gc08a3_suspend(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	if (gc08a3->streaming)
> +		gc08a3_stop_streaming(gc08a3);
> +
> +	return 0;
> +}
> +
> +static int __maybe_unused gc08a3_resume(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +	int ret;
> +
> +	if (gc08a3->streaming) {
> +		ret = gc08a3_start_streaming(gc08a3);
> +		if (ret)
> +			goto error;
> +	}
> +
> +	return 0;
> +
> +error:
> +	gc08a3_stop_streaming(gc08a3);
> +	gc08a3->streaming = 0;
> +	return ret;
> +}

No need for system suspend/resume operations. Please read
Documentation/driver-api/media/camera-sensor.rst in the master branch of
git://linuxtv.org/media_stage.git for an explanation.

> +
> +static int gc08a3_init_controls(struct gc08a3 *gc08a3)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	const struct v4l2_ctrl_ops *ops = &gc08a3_ctrl_ops;
> +	struct v4l2_fwnode_device_properties props;
> +	struct v4l2_ctrl_handler *ctrl_hdlr;
> +	s64 exposure_max, h_blank;
> +	int ret;
> +
> +	ctrl_hdlr = &gc08a3->ctrls;
> +	ret = v4l2_ctrl_handler_init(ctrl_hdlr, 10);
> +	if (ret)
> +		return ret;
> +
> +	ctrl_hdlr->lock = &gc08a3->mutex;
> +
> +	gc08a3->link_freq =
> +		v4l2_ctrl_new_int_menu(ctrl_hdlr,
> +				       &gc08a3_ctrl_ops,
> +				       V4L2_CID_LINK_FREQ,
> +				       ARRAY_SIZE(link_freq_menu_items) - 1,
> +				       0, link_freq_menu_items);
> +	if (gc08a3->link_freq)
> +		gc08a3->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> +	gc08a3->pixel_rate =
> +		v4l2_ctrl_new_std(ctrl_hdlr,
> +				  &gc08a3_ctrl_ops,
> +				  V4L2_CID_PIXEL_RATE, 0,
> +				  to_pixel_rate(GC08A3_LINK_FREQ_336MHZ_CFG), 1,
> +				  to_pixel_rate(GC08A3_LINK_FREQ_336MHZ_CFG));
> +
> +	gc08a3->vblank =
> +		v4l2_ctrl_new_std(ctrl_hdlr,
> +				  &gc08a3_ctrl_ops, V4L2_CID_VBLANK,
> +				  gc08a3->cur_mode->vts_min - gc08a3->cur_mode->height,
> +				  GC08A3_VTS_MAX - gc08a3->cur_mode->height, 1,
> +				  gc08a3->cur_mode->vts_def - gc08a3->cur_mode->height);
> +
> +	h_blank = gc08a3->cur_mode->hts - gc08a3->cur_mode->width;
> +	gc08a3->hblank = v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops,
> +					   V4L2_CID_HBLANK, h_blank, h_blank, 1,
> +					   h_blank);
> +	if (gc08a3->hblank)
> +		gc08a3->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> +	v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops,
> +			  V4L2_CID_ANALOGUE_GAIN, GC08A3_AGAIN_MIN,
> +			  GC08A3_AGAIN_MAX, GC08A3_AGAIN_STEP,
> +			  GC08A3_AGAIN_MIN);
> +
> +	exposure_max = gc08a3->cur_mode->vts_def - GC08A3_EXP_MARGIN;
> +	gc08a3->exposure = v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops,
> +					     V4L2_CID_EXPOSURE, GC08A3_EXP_MIN,
> +					     exposure_max, GC08A3_EXP_STEP,
> +					     exposure_max);
> +
> +	v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &gc08a3_ctrl_ops,
> +				     V4L2_CID_TEST_PATTERN,
> +				     ARRAY_SIZE(gc08a3_test_pattern_menu) - 1,
> +				     0, 0, gc08a3_test_pattern_menu);
> +
> +	v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops, V4L2_CID_HFLIP, 0,
> +			  1, 1, 0);
> +
> +	v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops, V4L2_CID_VFLIP, 0,
> +			  1, 1, 0);
> +
> +	/* register properties to fwnode (e.g. rotation, orientation) */
> +	ret = v4l2_fwnode_device_parse(&client->dev, &props);
> +	if (ret)
> +		goto error_ctrls;
> +
> +	ret = v4l2_ctrl_new_fwnode_properties(ctrl_hdlr, ops, &props);
> +	if (ret)
> +		goto error_ctrls;
> +
> +	if (ctrl_hdlr->error) {
> +		ret = ctrl_hdlr->error;
> +		goto error_ctrls;
> +	}
> +
> +	gc08a3->sd.ctrl_handler = ctrl_hdlr;
> +
> +	return 0;
> +
> +error_ctrls:
> +	v4l2_ctrl_handler_free(ctrl_hdlr);
> +
> +	return ret;
> +}
> +
> +static int gc08a3_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct gc08a3 *gc08a3;
> +	int ret;
> +
> +	dev_info(dev, "--- %s +", __func__);
> +
> +	ret = gc08a3_parse_fwnode(dev);
> +	if (ret)
> +		return ret;
> +
> +	gc08a3 = devm_kzalloc(dev, sizeof(*gc08a3), GFP_KERNEL);
> +	if (!gc08a3)
> +		return -ENOMEM;
> +
> +	gc08a3->dev = dev;
> +
> +	gc08a3->xclk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(gc08a3->xclk)) {
> +		dev_err(dev, "could not get xclk\n");
> +		return PTR_ERR(gc08a3->xclk);
> +	}
> +
> +	ret = clk_set_rate(gc08a3->xclk, GC08A3_DEFAULT_CLK_FREQ);
> +	if (ret) {
> +		dev_err(dev, "could not set xclk frequency\n");
> +		return ret;
> +	}
> +
> +	ret = gc08a3_get_regulators(dev, gc08a3);
> +	if (ret < 0) {
> +		dev_err(dev, "cannot get regulators\n");
> +		return ret;
> +	}
> +
> +	gc08a3->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(gc08a3->enable_gpio)) {
> +		dev_err(dev, "cannot get enable gpio\n");
> +		return PTR_ERR(gc08a3->enable_gpio);
> +	}
> +
> +	gc08a3->regmap = devm_regmap_init_i2c(client, &sensor_regmap_config);
> +	if (IS_ERR(gc08a3->regmap)) {
> +		dev_err(dev, "regmap init failed\n");
> +		return PTR_ERR(gc08a3->regmap);
> +	}
> +
> +	v4l2_i2c_subdev_init(&gc08a3->sd, client, &gc08a3_subdev_ops);
> +
> +	gc08a3_power_on(gc08a3->dev);
> +
> +	ret = gc08a3_identify_module(gc08a3);
> +	if (ret) {
> +		dev_err(&client->dev, "failed to find sensor: %d\n", ret);
> +		gc08a3_power_off(gc08a3->dev);
> +		return ret;
> +	}
> +
> +	mutex_init(&gc08a3->mutex);
> +	gc08a3->cur_mode = &gc08a3_modes[0];
> +
> +	ret = gc08a3_init_controls(gc08a3);
> +	if (ret) {
> +		dev_err(&client->dev, "failed to init controls: %d", ret);
> +		goto free_ctrl;
> +	}
> +
> +	gc08a3->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> +	gc08a3->pad.flags = MEDIA_PAD_FL_SOURCE;
> +	gc08a3->sd.dev = &client->dev;
> +	gc08a3->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
> +
> +	dev_dbg(&client->dev, "gc08a3->sd.name: %s, dev->of_node->name: %s\n",
> +		gc08a3->sd.name, dev->of_node->name);
> +	if (V4L2_SUBDEV_NAME_SIZE - strlen(gc08a3->sd.name) - 2 <
> +	    strlen(dev->of_node->name)) {
> +		dev_err(&client->dev,
> +			"the string length of (sd.name + of_node->name) is too long.\n");
> +		return -EINVAL;
> +	}
> +	strncat(gc08a3->sd.name, " ", 1);
> +	strncat(gc08a3->sd.name, dev->of_node->name,
> +		V4L2_SUBDEV_NAME_SIZE - strlen(gc08a3->sd.name) - 2);
> +	dev_dbg(&client->dev, "after: gc08a3->sd.name: %s\n", gc08a3->sd.name);
> +
> +	ret = media_entity_pads_init(&gc08a3->sd.entity, 1, &gc08a3->pad);
> +	if (ret < 0) {
> +		dev_err(dev, "could not register media entity\n");
> +		goto free_ctrl;
> +	}
> +
> +	ret = v4l2_async_register_subdev_sensor(&gc08a3->sd);
> +	if (ret < 0) {
> +		dev_err(dev, "could not register v4l2 device\n");
> +		goto free_entity;
> +	}
> +
> +	pm_runtime_set_active(gc08a3->dev);
> +	pm_runtime_enable(gc08a3->dev);
> +	pm_runtime_idle(gc08a3->dev);

Please see the imx219 driver for an example of how to correctly
implement runtime PM support. Please also use PM runtime autosuspend.

> +
> +	dev_info(dev, "--- %s -", __func__);
> +
> +	return 0;
> +
> +free_entity:
> +	media_entity_cleanup(&gc08a3->sd.entity);
> +free_ctrl:
> +	mutex_destroy(&gc08a3->mutex);
> +	v4l2_ctrl_handler_free(&gc08a3->ctrls);
> +	pm_runtime_disable(gc08a3->dev);
> +
> +	return ret;
> +}
> +
> +static void gc08a3_remove(struct i2c_client *client)
> +{
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	v4l2_async_unregister_subdev(&gc08a3->sd);
> +	media_entity_cleanup(&gc08a3->sd.entity);
> +	v4l2_ctrl_handler_free(&gc08a3->ctrls);
> +
> +	pm_runtime_disable(&client->dev);
> +	pm_runtime_set_suspended(&client->dev);
> +
> +	mutex_destroy(&gc08a3->mutex);
> +}
> +
> +static const struct of_device_id gc08a3_of_match[] = {
> +	{ .compatible = "GalaxyCore,gc08a3" },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, gc08a3_of_match);
> +
> +static const struct dev_pm_ops gc08a3_pm_ops = {
> +	SET_SYSTEM_SLEEP_PM_OPS(gc08a3_suspend, gc08a3_resume)
> +		SET_RUNTIME_PM_OPS(gc08a3_power_off, gc08a3_power_on, NULL)
> +};
> +
> +static struct i2c_driver gc08a3_i2c_driver = {
> +	.driver = {
> +		.of_match_table = gc08a3_of_match,
> +		.pm = &gc08a3_pm_ops,
> +		.name  = "gc08a3",
> +	},
> +	.probe_new  = gc08a3_probe,
> +	.remove = gc08a3_remove,
> +};
> +
> +module_i2c_driver(gc08a3_i2c_driver);
> +
> +MODULE_DESCRIPTION("GalaxyCore gc08a3 Camera driver");
> +MODULE_AUTHOR("Zhi Mao <zhi.mao at mediatek.com>");
> +MODULE_LICENSE("GPL");

-- 
Regards,

Laurent Pinchart


From lukasz.luba at arm.com  Thu Dec  7 03:07:58 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Thu, 7 Dec 2023 11:07:58 +0000
Subject: [PATCH] arm64: dts: rockchip: Add dynamic-power-coefficient to
 rk3399 GPU
In-Reply-To: <20231127081511.1911706-1-lukasz.luba@arm.com>
References: <20231127081511.1911706-1-lukasz.luba@arm.com>
Message-ID: <c5c6f169-e021-43c5-a478-21bfbdada554@arm.com>



On 11/27/23 08:15, Lukasz Luba wrote:
> Add dynamic-power-coefficient to the GPU node. That will create Energy
> Model for the GPU based on the coefficient and OPP table information.
> It will enable mechanism such as DTMP or IPA to work with the GPU DVFS.
> In similar way the Energy Model for CPUs in rk3399 is created, so both
> are aligned in power scale. The maximum power used from this coefficient
> is 1.5W at 600MHz.
> 
> Signed-off-by: Lukasz Luba <lukasz.luba at arm.com>
> ---
>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 


Gentle ping. What's the status of this?


From david at redhat.com  Thu Dec  7 03:08:08 2023
From: david at redhat.com (David Hildenbrand)
Date: Thu, 7 Dec 2023 12:08:08 +0100
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
 <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
Message-ID: <ca649aad-7b76-4c6d-b513-26b3d58f8e68@redhat.com>

[...]

>>
>> Nit: the orders = ... order = ... looks like this might deserve a helper
>> function that makes this easier to read.
> 
> To be honest, the existing function that I've modified is a bit of a mess.

It's all an ugly mess and I hate it.

It would be cleanest if we'd just have "thp_vma_configured_orders()" 
that gives us all configured orders for the given VMA+flags combination. 
No passing in of orders, try handling the masking in the caller.

Then, we move that nasty "transhuge_vma_suitable" handling for !in_pf 
out of there and handle that in the callers. The comment "Huge fault 
does the check in fault handlers. And this check is not suitable for 
huge PUD fault handlers." already makes me angry, what a mess.


Then, we'd have a thp_vma_fitting_orders() / thp_vma_is_fitting_order() 
function that does the filtering only based on the given address + vma 
size/alignment. That's roughly "thp_vma_suitable_orders()".


Finding a good name to combine both could be something like
"thp_vma_possible_orders()".


Would make more sense to me (but again, German guy, so it's probably all 
wrong).


> thp_vma_allowable_orders() calls thp_vma_suitable_orders() if we are not in a
> page fault, because the page fault handlers already do that check themselves. It
> would be nice to refactor the whole thing so that thp_vma_allowable_orders() is
> a strict superset of thp_vma_suitable_orders(). Then this can just call
> thp_vma_allowable_orders(). But that's going to start touching the PMD and PUD
> handlers, so prefer if we leave that for a separate patch set.
> 
>>
>> Nit: Why call thp_vma_suitable_orders if the orders are already 0? Again, some
>> helper might be reasonable where that is handled internally.
> 
> Because thp_vma_suitable_orders() will handle it safely and is inline, so it
> should just as efficient? This would go away with the refactoring described above.

Right. Won't win in a beauty contest. Some simple helper might make this 
much easier to digest.

> 
>>
>> Comment: For order-0 we'll always perform a function call to both
>> thp_vma_allowable_orders() / thp_vma_suitable_orders(). We should perform some
>> fast and efficient check if any <PMD THP are even enabled in the system / for
>> this VMA, and in that case just fallback before doing more expensive checks.
> 
> thp_vma_allowable_orders() is inline as you mentioned.
> 
> I was deliberately trying to keep all the decision logic in one place
> (thp_vma_suitable_orders) because it's already pretty complicated. But if you
> insist, how about this in the header:
> 
> static inline
> unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
> 				       unsigned long vm_flags, bool smaps,
> 				       bool in_pf, bool enforce_sysfs,
> 				       unsigned long orders)
> {
> 	/* Optimization to check if required orders are enabled early. */
> 	if (enforce_sysfs && vma_is_anonymous(vma)) {
> 		unsigned long mask = READ_ONCE(huge_anon_orders_always);
> 
> 		if (vm_flags & VM_HUGEPAGE)
> 			mask |= READ_ONCE(huge_anon_orders_madvise);
> 		if (hugepage_global_always() ||
> 			((vm_flags & VM_HUGEPAGE) && hugepage_global_enabled()))
> 			mask |= READ_ONCE(huge_anon_orders_inherit);
> 
> 		orders &= mask;
> 		if (!orders)
> 			return 0;
> 		
> 		enforce_sysfs = false;
> 	}
> 
> 	return __thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf,
> 					  enforce_sysfs, orders);
> }
> 
> Then the above check can be removed from __thp_vma_allowable_orders() - it will
> still retain the `if (enforce_sysfs && !vma_is_anonymous(vma))` part.
> 

Better. I still kind-of hate having to pass in orders here. Such masking 
is better done in the caller (see above how it might be done when moving 
the transhuge_vma_suitable() check out).

> 
>>
>>> +
>>> +??? if (!orders)
>>> +??????? goto fallback;
>>> +
>>> +??? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>> +??? if (!pte)
>>> +??????? return ERR_PTR(-EAGAIN);
>>> +
>>> +??? order = first_order(orders);
>>> +??? while (orders) {
>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>> +??????? vmf->pte = pte + pte_index(addr);
>>> +??????? if (pte_range_none(vmf->pte, 1 << order))
>>> +??????????? break;
>>
>> Comment: Likely it would make sense to scan only once and determine the "largest
>> none range" around that address, having the largest suitable order in mind.
> 
> Yes, that's how I used to do it, but Yu Zhou requested simplifying to this,
> IIRC. Perhaps this an optimization opportunity for later?

Yes, definetly.

> 
>>
>>> +??????? order = next_order(&orders, order);
>>> +??? }
>>> +
>>> +??? vmf->pte = NULL;
>>
>> Nit: Can you elaborate why you are messing with vmf->pte here? A simple helper
>> variable will make this code look less magical. Unless I am missing something
>> important :)
> 
> Gahh, I used to pass the vmf to what pte_range_none() was refactored into (an
> approach that was suggested by Yu Zhou IIRC). But since I did some refactoring
> based on some comments from JohnH, I see I don't need that anymore. Agreed; it
> will be much clearer just to use a local variable. Will fix.
> 
>>
>>> +??? pte_unmap(pte);
>>> +
>>> +??? gfp = vma_thp_gfp_mask(vma);
>>> +
>>> +??? while (orders) {
>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>> +??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>> +??????? if (folio) {
>>> +??????????? clear_huge_page(&folio->page, addr, 1 << order);
>>> +??????????? return folio;
>>> +??????? }
>>> +??????? order = next_order(&orders, order);
>>> +??? }
>>> +
>>
>> Queestion: would it make sense to combine both loops? I suspect memory
>> allocations with pte_offset_map()/kmao are problematic.
> 
> They are both operating on separate orders; next_order() is "consuming" an order
> by removing the current one from the orders bitfield and returning the next one.
> 
> So the first loop starts at the highest order and keeps checking lower orders
> until one fully fits in the VMA. And the second loop starts at the first order
> that was found to fully fits and loops to lower orders until an allocation is
> successful.

Right, but you know from the first loop which order is applicable (and 
will be fed to the second loop) and could just pte_unmap(pte) + 
tryalloc. If that fails, remap and try with the next orders.

That would make the code certainly easier to understand. That "orders" 
magic of constructing, filtering, walking is confusing :)


I might find some time today to see if there is an easy way to cleanup 
all what I spelled out above. It really is a mess. But likely that 
cleanup could be deferred (but you're touching it, so ... :) ).

-- 
Cheers,

David / dhildenb



From alexander.stein at ew.tq-group.com  Thu Dec  7 03:09:18 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu,  7 Dec 2023 12:09:18 +0100
Subject: [PATCH v2 1/1] media: nxp: imx8-isi-debug: Add missing 36-Bit DMA registers to debugfs output
Message-ID: <20231207110918.1338524-1-alexander.stein@ew.tq-group.com>

The extended address registers are missing in the debug output register
list. These are only available on 36-Bit DMA platforms. Due to the
prolonged name, the output width has to be adjusted as well.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
Changes in v2:
* Split register set into regular and 36-Bit DMA only
* Adjust output width to address longer register names

Currently only tested on TQMa8MPxL (imx8mp-tqma8mpql-mba8mpxl.dts)

 .../platform/nxp/imx8-isi/imx8-isi-debug.c    | 28 +++++++++++++++++--
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
index 6709ab7ea1f3..398864b5e506 100644
--- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
+++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
@@ -22,10 +22,11 @@ static inline u32 mxc_isi_read(struct mxc_isi_pipe *pipe, u32 reg)
 static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
 {
 #define MXC_ISI_DEBUG_REG(name)		{ name, #name }
-	static const struct {
+	struct debug_regs {
 		u32 offset;
 		const char * const name;
-	} registers[] = {
+	};
+	static const struct debug_regs registers[] = {
 		MXC_ISI_DEBUG_REG(CHNL_CTRL),
 		MXC_ISI_DEBUG_REG(CHNL_IMG_CTRL),
 		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF_CTRL),
@@ -67,6 +68,16 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
 		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
 		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
 	};
+	/* There registers contain the upper 4Bits of 36-Bit DMA addresses */
+	static const struct debug_regs registers_36bit_dma[] = {
+		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
+		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),
+	};
 
 	struct mxc_isi_pipe *pipe = m->private;
 	unsigned int i;
@@ -77,10 +88,21 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
 	seq_printf(m, "--- ISI pipe %u registers ---\n", pipe->id);
 
 	for (i = 0; i < ARRAY_SIZE(registers); ++i)
-		seq_printf(m, "%20s[0x%02x]: 0x%08x\n",
+		seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
 			   registers[i].name, registers[i].offset,
 			   mxc_isi_read(pipe, registers[i].offset));
 
+	if (pipe->isi->pdata->has_36bit_dma) {
+		for (i = 0; i < ARRAY_SIZE(registers_36bit_dma); ++i) {
+			const struct debug_regs *reg = &registers_36bit_dma[i];
+
+			seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
+				reg->name,
+				reg->offset,
+				mxc_isi_read(pipe, reg->offset));
+		}
+	}
+
 	pm_runtime_put(pipe->isi->dev);
 
 	return 0;
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec  7 03:09:53 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 07 Dec 2023 12:09:53 +0100
Subject: [PATCH 1/1] media: nxp: imx8-isi-debug: Add missing registers to debugfs output
In-Reply-To: <20231207101400.GB3681@pendragon.ideasonboard.com>
References: <20231206094401.491100-1-alexander.stein@ew.tq-group.com> <2915417.e9J7NaK4W3@steina-w> <20231207101400.GB3681@pendragon.ideasonboard.com>
Message-ID: <3272819.44csPzL39Z@steina-w>

Hi Laurent,

Am Donnerstag, 7. Dezember 2023, 11:14:00 CET schrieb Laurent Pinchart:
> Hi Alexander,
> 
> On Thu, Dec 07, 2023 at 08:52:46AM +0100, Alexander Stein wrote:
> > Am Mittwoch, 6. Dezember 2023, 23:36:36 CET schrieb Laurent Pinchart:
> > > On Wed, Dec 06, 2023 at 10:44:01AM +0100, Alexander Stein wrote:
> > > > The extended address registers are missing in the debug output
> > > > register
> > > > list. Add them.
> > > > 
> > > > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> > > > ---
> > > > 
> > > >  drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c index
> > > > 6709ab7ea1f3..3ac5685d6cc1 100644
> > > > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > > @@ -66,6 +66,13 @@ static int mxc_isi_debug_dump_regs_show(struct
> > > > seq_file *m, void *p)> > > 
> > > >  		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF2_ADDR_V),
> > > >  		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
> > > >  		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
> > > > 
> > > > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),
> > > 
> > > Those registers only exist in the i.MX8MP. The i.MX8MN referenece manual
> > > lists them as reserved and indicates they read as 0's, so it should be
> > > safe.  The i.MX93 reference manual, however, doesn't list those
> > > registers at all, so accessing them may lead to issues.
> > > 
> > > How what platform(s) have you tested this patch ?
> > 
> > Ah, you are right. That's something I didn't take into account. Up until
> > now I only tested this on i.MX8MP. I hope I can test this on i.MX8MN and
> > i.MX93 soon.
> > Otherwise dumping these registers can depend on pdata->has_36bit_dma just
> > to be safe.
> 
> That sounds like a good solution to me. Will you do so in a v2 ?

Yep, yep just sent it.

Best regards
Alexander

> 
> > > >  	};
> > > >  	
> > > >  	struct mxc_isi_pipe *pipe = m->private;


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From david at redhat.com  Thu Dec  7 03:13:05 2023
From: david at redhat.com (David Hildenbrand)
Date: Thu, 7 Dec 2023 12:13:05 +0100
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <ca3a2b97-f08e-452a-91dc-1a53dece0aa6@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
 <004ed23d-5571-4474-b7fe-7bc08817c165@redhat.com>
 <ca3a2b97-f08e-452a-91dc-1a53dece0aa6@arm.com>
Message-ID: <378afc6b-f93a-48ad-8aa6-ab171f3b9613@redhat.com>

>>
>>> +
>>>  ????? if (!vma->vm_mm)??????? /* vdso */
>>> -??????? return false;
>>> +??????? return 0;
>>>  ? ????? /*
>>>  ?????? * Explicitly disabled through madvise or prctl, or some
>>> @@ -88,16 +141,16 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>> unsigned long vm_flags,
>>>  ?????? * */
>>>  ????? if ((vm_flags & VM_NOHUGEPAGE) ||
>>>  ????????? test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
>>> -??????? return false;
>>> +??????? return 0;
>>>  ????? /*
>>>  ?????? * If the hardware/firmware marked hugepage support disabled.
>>>  ?????? */
>>>  ????? if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED))
>>> -??????? return false;
>>> +??????? return 0;
>>>  ? ????? /* khugepaged doesn't collapse DAX vma, but page fault is fine. */
>>>  ????? if (vma_is_dax(vma))
>>> -??????? return in_pf;
>>> +??????? return in_pf ? orders : 0;
>>>  ? ????? /*
>>>  ?????? * khugepaged special VMA and hugetlb VMA.
>>> @@ -105,17 +158,29 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>> unsigned long vm_flags,
>>>  ?????? * VM_MIXEDMAP set.
>>>  ?????? */
>>>  ????? if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
>>> -??????? return false;
>>> +??????? return 0;
>>>  ? ????? /*
>>> -???? * Check alignment for file vma and size for both file and anon vma.
>>> +???? * Check alignment for file vma and size for both file and anon vma by
>>> +???? * filtering out the unsuitable orders.
>>>  ?????? *
>>>  ?????? * Skip the check for page fault. Huge fault does the check in fault
>>> -???? * handlers. And this check is not suitable for huge PUD fault.
>>> +???? * handlers.
>>>  ?????? */
>>> -??? if (!in_pf &&
>>> -??????? !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
>>> -??????? return false;
>>> +??? if (!in_pf) {
>>> +??????? int order = first_order(orders);
>>> +??????? unsigned long addr;
>>> +
>>> +??????? while (orders) {
>>> +??????????? addr = vma->vm_end - (PAGE_SIZE << order);
>>> +??????????? if (thp_vma_suitable_orders(vma, addr, BIT(order)))
>>> +??????????????? break;
>>
>> Comment: you'd want a "thp_vma_suitable_order" helper here. But maybe the
>> compiler is smart enough to optimize the loop and everyything else out.
> 
> I'm happy to refactor so that thp_vma_suitable_order() is the basic primitive,
> then make thp_vma_suitable_orders() a loop that calls thp_vma_suitable_order()
> (that's basically how it is laid out already, just all in one function). Is that
> what you are requesting?

You got the spirit, yes.

>>
>> [...]
>>
>>> +
>>> +static ssize_t thpsize_enabled_store(struct kobject *kobj,
>>> +???????????????????? struct kobj_attribute *attr,
>>> +???????????????????? const char *buf, size_t count)
>>> +{
>>> +??? int order = to_thpsize(kobj)->order;
>>> +??? ssize_t ret = count;
>>> +
>>> +??? if (sysfs_streq(buf, "always")) {
>>> +??????? set_bit(order, &huge_anon_orders_always);
>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>> +??? } else if (sysfs_streq(buf, "inherit")) {
>>> +??????? set_bit(order, &huge_anon_orders_inherit);
>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>> +??? } else if (sysfs_streq(buf, "madvise")) {
>>> +??????? set_bit(order, &huge_anon_orders_madvise);
>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>> +??? } else if (sysfs_streq(buf, "never")) {
>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>
>> Note: I was wondering for a second if some concurrent cames could lead to an
>> inconsistent state. I think in the worst case we'll simply end up with "never"
>> on races.
> 
> You mean if different threads try to write different values to this file
> concurrently? Or if there is a concurrent fault that tries to read the flags
> while they are being modified?

I thought about what you said first, but what you said last might also 
apply. As long as "nothing breaks", all good.

> 
> I thought about this for a long time too and wasn't sure what was best. The
> existing global enabled store impl clears the bits first then sets the bit. With
> this approach you can end up with multiple bits set if there is a race to set
> diffierent values, and you can end up with a faulting thread seeing never if it
> reads the bits after they have been cleared but before setting them.

Right, but user space is playing stupid games and can win stupid prices. 
As long as nothing breaks, we're good.

> 
> I decided to set the new bit before clearing the old bits, which is different; A
> racing fault will never see "never" but as you say, a race to set the file could
> result in "never" being set.
> 
> On reflection, it's probably best to set the bit *last* like the global control
> does?

Probably might just slap a simple spinlock in there, so at least the 
writer side is completely serialized. Then you can just set the bit 
last. It's unlikely that readers will actually run into issues, and if 
they ever would, we could use some rcu magic to let them read a 
consistent state.

-- 
Cheers,

David / dhildenb



From eichest at gmail.com  Thu Dec  7 03:12:58 2023
From: eichest at gmail.com (Stefan Eichenberger)
Date: Thu,  7 Dec 2023 12:12:58 +0100
Subject: [PATCH v1 0/2] Add a property to turn off the max touch controller in suspend mode
Message-ID: <20231207111300.80581-1-eichest@gmail.com>

From: Stefan Eichenberger <stefan.eichenberger at toradex.com>

Our hardware has a shared regulator that powers various peripherals such
as the display, touch, USB hub, etc. Since the Maxtouch controller
doesn't currently allow it to be turned off, this regulator has to stay
on in suspend mode. This increases the overall power consumption. In
order to turn off the controller when the system goes into suspend mode,
this series adds a device tree property to the maxtouch driver that
allows the controller to be turned off completely and ensurs that it can
resume from the power off state.

Stefan Eichenberger (2):
  dt-bindings: input: atmel,maxtouch: add power-off-in-suspend property
  Input: atmel_mxt_ts - support power off in suspend

 .../bindings/input/atmel,maxtouch.yaml        |  6 ++
 drivers/input/touchscreen/atmel_mxt_ts.c      | 72 ++++++++++++++-----
 2 files changed, 61 insertions(+), 17 deletions(-)

-- 
2.40.1



From eichest at gmail.com  Thu Dec  7 03:12:59 2023
From: eichest at gmail.com (Stefan Eichenberger)
Date: Thu,  7 Dec 2023 12:12:59 +0100
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add poweroff-in-suspend property
In-Reply-To: <20231207111300.80581-1-eichest@gmail.com>
References: <20231207111300.80581-1-eichest@gmail.com>
Message-ID: <20231207111300.80581-2-eichest@gmail.com>

From: Stefan Eichenberger <stefan.eichenberger at toradex.com>

Add a new property to indicate that the device should be powered off in
suspend mode.

Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>
---
 Documentation/devicetree/bindings/input/atmel,maxtouch.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
index c40799355ed7..047a5101341c 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -87,6 +87,12 @@ properties:
       - 2 # ATMEL_MXT_WAKEUP_GPIO
     default: 0
 
+  atmel,poweroff-in-suspend:
+    description: |
+      When this property is set, all supplies are turned off when the system is
+      going to suspend.
+    type: boolean
+
   wakeup-source:
     type: boolean
 
-- 
2.40.1



From eichest at gmail.com  Thu Dec  7 03:13:00 2023
From: eichest at gmail.com (Stefan Eichenberger)
Date: Thu,  7 Dec 2023 12:13:00 +0100
Subject: [PATCH v1 2/2] Input: atmel_mxt_ts - support poweroff in suspend
In-Reply-To: <20231207111300.80581-1-eichest@gmail.com>
References: <20231207111300.80581-1-eichest@gmail.com>
Message-ID: <20231207111300.80581-3-eichest@gmail.com>

From: Stefan Eichenberger <stefan.eichenberger at toradex.com>

Add a new device tree property to indicate that the device should be
powered off in suspend mode. We have a shared regulator that powers the
display, a USB hub and some other peripherals. The maxtouch doesn't
normally disable the regulator in suspend mode, so our extra peripherals
stay powered on. This is not desirable as it consumes more power. With
this patch we add the option to disable the regulator in suspend mode
for the maxtouch and accept the longer initialisation time.

Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 72 ++++++++++++++++++------
 1 file changed, 55 insertions(+), 17 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 20094b9899f0..7caa0d317d30 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -317,6 +317,7 @@ struct mxt_data {
 	struct gpio_desc *reset_gpio;
 	struct gpio_desc *wake_gpio;
 	bool use_retrigen_workaround;
+	bool poweroff_in_suspend;
 
 	/* Cached parameters from object table */
 	u16 T5_address;
@@ -2799,15 +2800,18 @@ static int mxt_configure_objects(struct mxt_data *data,
 			dev_warn(dev, "Error %d updating config\n", error);
 	}
 
-	if (data->multitouch) {
-		error = mxt_initialize_input_device(data);
-		if (error)
-			return error;
-	} else {
-		dev_warn(dev, "No touch object detected\n");
-	}
+	/* If input device is not already registered */
+	if (!data->input_dev) {
+		if (data->multitouch) {
+			error = mxt_initialize_input_device(data);
+			if (error)
+				return error;
+		} else {
+			dev_warn(dev, "No touch object detected\n");
+		}
 
-	mxt_debug_init(data);
+		mxt_debug_init(data);
+	}
 
 	return 0;
 }
@@ -3328,6 +3332,8 @@ static int mxt_probe(struct i2c_client *client)
 		msleep(MXT_RESET_INVALID_CHG);
 	}
 
+	data->poweroff_in_suspend = device_property_read_bool(&client->dev,
+							       "atmel,poweroff-in-suspend");
 	/*
 	 * Controllers like mXT1386 have a dedicated WAKE line that could be
 	 * connected to a GPIO or to I2C SCL pin, or permanently asserted low.
@@ -3390,12 +3396,21 @@ static int mxt_suspend(struct device *dev)
 	if (!input_dev)
 		return 0;
 
-	mutex_lock(&input_dev->mutex);
+	if (!device_may_wakeup(dev) && data->poweroff_in_suspend) {
+		if (data->reset_gpio)
+			gpiod_set_value(data->reset_gpio, 1);
 
-	if (input_device_enabled(input_dev))
-		mxt_stop(data);
+		regulator_bulk_disable(ARRAY_SIZE(data->regulators),
+				data->regulators);
+		data->T44_address = 0;
+	} else {
+		mutex_lock(&input_dev->mutex);
+
+		if (input_device_enabled(input_dev))
+			mxt_stop(data);
 
-	mutex_unlock(&input_dev->mutex);
+		mutex_unlock(&input_dev->mutex);
+	}
 
 	disable_irq(data->irq);
 
@@ -3411,14 +3426,37 @@ static int mxt_resume(struct device *dev)
 	if (!input_dev)
 		return 0;
 
-	enable_irq(data->irq);
+	if (!device_may_wakeup(dev) && data->poweroff_in_suspend) {
+		int ret;
 
-	mutex_lock(&input_dev->mutex);
+		ret = regulator_bulk_enable(ARRAY_SIZE(data->regulators),
+				data->regulators);
+		if (ret) {
+			dev_err(dev, "failed to enable regulators: %d\n",
+					ret);
+			return ret;
+		}
+		msleep(MXT_BACKUP_TIME);
 
-	if (input_device_enabled(input_dev))
-		mxt_start(data);
+		if (data->reset_gpio) {
+			/* Wait a while and then de-assert the RESET GPIO line */
+			msleep(MXT_RESET_GPIO_TIME);
+			gpiod_set_value(data->reset_gpio, 0);
+			msleep(MXT_RESET_INVALID_CHG);
+		}
 
-	mutex_unlock(&input_dev->mutex);
+		/* This also enables the irq again */
+		mxt_initialize(data);
+	} else {
+		enable_irq(data->irq);
+
+		mutex_lock(&input_dev->mutex);
+
+		if (input_device_enabled(input_dev))
+			mxt_start(data);
+
+		mutex_unlock(&input_dev->mutex);
+	}
 
 	return 0;
 }
-- 
2.40.1



From fshao at chromium.org  Thu Dec  7 03:14:31 2023
From: fshao at chromium.org (Fei Shao)
Date: Thu, 7 Dec 2023 19:14:31 +0800
Subject: [PATCH 2/4] media: mediatek: vcodec: Drop unnecessary variable
In-Reply-To: <3528639f-85a3-4756-b04b-c233f6c84276@collabora.com>
References: <20231113123049.4117280-1-fshao@chromium.org> <20231113123049.4117280-3-fshao@chromium.org>
 <3528639f-85a3-4756-b04b-c233f6c84276@collabora.com>
Message-ID: <CAC=S1nibsNfo7Ans2J0aiXqJSz5-iTPh2NwTEuUL8-HUM0AJdw@mail.gmail.com>

Hi Angelo,

On Wed, Dec 6, 2023 at 6:19?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 13/11/23 13:26, Fei Shao ha scritto:
> > It's unclear why only mem->size has local copies without particular
> > usage in mtk_vcodec_mem_alloc() and mtk_vcodec_mem_free(), and they
> > seem removable.
> >
> > Drop them to make the code visually consistent, and update printk format
> > identifier accordingly.
> >
> > Signed-off-by: Fei Shao <fshao at chromium.org>
>
> That's probably just about personal preferences, as mem->size is not expected
> to change during the flow of those functions.
>
> That said, as much as you, I prefer not having this local copy as it's using
> (a very small amount of) memory for no real reason anyway, so:

Yes, and I think I should have mentioned this in the commit message...
I'll revise that in the next version.

Thanks,
Fei





>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
>
>


From mani at kernel.org  Thu Dec  7 03:21:01 2023
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Thu, 7 Dec 2023 16:51:01 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <286b6f8a-c634-19ed-cf53-276cfe05d03f@quicinc.com>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
 <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>
 <5e7c5c75-cb5f-4afe-9d57-b0cab01a6f26@acm.org>
 <b9373252-710c-4a54-95cc-046314796960@quicinc.com>
 <20231206153242.GI12802@thinkpad>
 <effb603e-ca7a-4f24-9783-4d62790165ae@acm.org>
 <20231207094357.GI2932@thinkpad>
 <286b6f8a-c634-19ed-cf53-276cfe05d03f@quicinc.com>
Message-ID: <20231207112101.GK2932@thinkpad>

On Thu, Dec 07, 2023 at 03:56:43PM +0530, Nitin Rawat wrote:
> 
> 
> On 12/7/2023 3:13 PM, Manivannan Sadhasivam wrote:
> > On Wed, Dec 06, 2023 at 03:02:04PM -1000, Bart Van Assche wrote:
> > > On 12/6/23 05:32, Manivannan Sadhasivam wrote:
> > > > On Wed, Dec 06, 2023 at 07:32:54PM +0530, Naresh Maramaina wrote:
> > > > > On 12/5/2023 10:41 PM, Bart Van Assche wrote:
> > > > > > On 12/4/23 21:58, Naresh Maramaina wrote:
> > > > > > > On 12/5/2023 12:30 AM, Bart Van Assche wrote:
> > > > > > > > On 12/4/23 06:30, Maramaina Naresh wrote:
> > > > > > > > > +??? /* This capability allows the host controller driver to
> > > > > > > > > use the PM QoS
> > > > > > > > > +???? * feature.
> > > > > > > > > +???? */
> > > > > > > > > +??? UFSHCD_CAP_PM_QOS??????????????? = 1 << 13,
> > > > > > > > >   ? };
> > > > > > > > 
> > > > > > > > Why does it depend on the host driver whether or not PM QoS is
> > > > > > > > enabled? Why isn't it enabled unconditionally?
> > > > > > > 
> > > > > > > For some platform vendors power KPI might be more important than
> > > > > > > random io KPI. Hence this flag is disabled by default and can be
> > > > > > > enabled based on platform requirement.
> > > > > > 
> > > > > > How about leaving this flag out unless if a host vendor asks explicitly
> > > > > > for this flag?
> > > > > 
> > > > > IMHO, instead of completely removing this flag, how about having
> > > > > flag like "UFSHCD_CAP_DISABLE_PM_QOS" which will make PMQOS enable
> > > > > by default and if some host vendor wants to disable it explicitly,
> > > > > they can enable that flag.
> > > > > Please let me know your opinion.
> > > 
> > > That would result in a flag that is tested but that is never set by
> > > upstream code. I'm not sure that's acceptable.
> > > 
> > 
> > Agree. The flag shouldn't be introduced if there are no users.
> > 
> > > > If a vendor wants to disable this feature, then the driver has to be modified.
> > > > That won't be very convenient. So either this has to be configured through sysfs
> > > > or Kconfig if flexibility matters.
> > > 
> > > Kconfig sounds worse to me because changing any Kconfig flag requires a
> > > modification of the Android GKI kernel.
> > > 
> > 
> > Hmm, ok. Then I think we can have a sysfs hook to toggle the enable switch.
> 
> Hi Bart, Mani
> 
> How about keeping this feature enabled by default and having a module
> parameter to disable pmqos feature if required ?
> 

Module params not encouraged these days unless there are no other feasible
options available.

- Mani

> Regards,
> Nitin
> 
> > 
> > - Mani
> > 
> > > Thanks,
> > > 
> > > Bart.
> > 
> 

-- 
????????? ????????


From ryan.roberts at arm.com  Thu Dec  7 03:22:59 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 7 Dec 2023 11:22:59 +0000
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <378afc6b-f93a-48ad-8aa6-ab171f3b9613@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
 <004ed23d-5571-4474-b7fe-7bc08817c165@redhat.com>
 <ca3a2b97-f08e-452a-91dc-1a53dece0aa6@arm.com>
 <378afc6b-f93a-48ad-8aa6-ab171f3b9613@redhat.com>
Message-ID: <4aa520f0-7c84-4e93-88bf-aee6d8d3ea70@arm.com>

On 07/12/2023 11:13, David Hildenbrand wrote:
>>>
>>>> +
>>>> ?????? if (!vma->vm_mm)??????? /* vdso */
>>>> -??????? return false;
>>>> +??????? return 0;
>>>> ?? ????? /*
>>>> ??????? * Explicitly disabled through madvise or prctl, or some
>>>> @@ -88,16 +141,16 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>>> unsigned long vm_flags,
>>>> ??????? * */
>>>> ?????? if ((vm_flags & VM_NOHUGEPAGE) ||
>>>> ?????????? test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
>>>> -??????? return false;
>>>> +??????? return 0;
>>>> ?????? /*
>>>> ??????? * If the hardware/firmware marked hugepage support disabled.
>>>> ??????? */
>>>> ?????? if (transparent_hugepage_flags & (1 <<
>>>> TRANSPARENT_HUGEPAGE_UNSUPPORTED))
>>>> -??????? return false;
>>>> +??????? return 0;
>>>> ?? ????? /* khugepaged doesn't collapse DAX vma, but page fault is fine. */
>>>> ?????? if (vma_is_dax(vma))
>>>> -??????? return in_pf;
>>>> +??????? return in_pf ? orders : 0;
>>>> ?? ????? /*
>>>> ??????? * khugepaged special VMA and hugetlb VMA.
>>>> @@ -105,17 +158,29 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>>> unsigned long vm_flags,
>>>> ??????? * VM_MIXEDMAP set.
>>>> ??????? */
>>>> ?????? if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
>>>> -??????? return false;
>>>> +??????? return 0;
>>>> ?? ????? /*
>>>> -???? * Check alignment for file vma and size for both file and anon vma.
>>>> +???? * Check alignment for file vma and size for both file and anon vma by
>>>> +???? * filtering out the unsuitable orders.
>>>> ??????? *
>>>> ??????? * Skip the check for page fault. Huge fault does the check in fault
>>>> -???? * handlers. And this check is not suitable for huge PUD fault.
>>>> +???? * handlers.
>>>> ??????? */
>>>> -??? if (!in_pf &&
>>>> -??????? !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
>>>> -??????? return false;
>>>> +??? if (!in_pf) {
>>>> +??????? int order = first_order(orders);
>>>> +??????? unsigned long addr;
>>>> +
>>>> +??????? while (orders) {
>>>> +??????????? addr = vma->vm_end - (PAGE_SIZE << order);
>>>> +??????????? if (thp_vma_suitable_orders(vma, addr, BIT(order)))
>>>> +??????????????? break;
>>>
>>> Comment: you'd want a "thp_vma_suitable_order" helper here. But maybe the
>>> compiler is smart enough to optimize the loop and everyything else out.
>>
>> I'm happy to refactor so that thp_vma_suitable_order() is the basic primitive,
>> then make thp_vma_suitable_orders() a loop that calls thp_vma_suitable_order()
>> (that's basically how it is laid out already, just all in one function). Is that
>> what you are requesting?
> 
> You got the spirit, yes.
> 
>>>
>>> [...]
>>>
>>>> +
>>>> +static ssize_t thpsize_enabled_store(struct kobject *kobj,
>>>> +???????????????????? struct kobj_attribute *attr,
>>>> +???????????????????? const char *buf, size_t count)
>>>> +{
>>>> +??? int order = to_thpsize(kobj)->order;
>>>> +??? ssize_t ret = count;
>>>> +
>>>> +??? if (sysfs_streq(buf, "always")) {
>>>> +??????? set_bit(order, &huge_anon_orders_always);
>>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>>> +??? } else if (sysfs_streq(buf, "inherit")) {
>>>> +??????? set_bit(order, &huge_anon_orders_inherit);
>>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>>> +??? } else if (sysfs_streq(buf, "madvise")) {
>>>> +??????? set_bit(order, &huge_anon_orders_madvise);
>>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>>> +??? } else if (sysfs_streq(buf, "never")) {
>>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>>
>>> Note: I was wondering for a second if some concurrent cames could lead to an
>>> inconsistent state. I think in the worst case we'll simply end up with "never"
>>> on races.
>>
>> You mean if different threads try to write different values to this file
>> concurrently? Or if there is a concurrent fault that tries to read the flags
>> while they are being modified?
> 
> I thought about what you said first, but what you said last might also apply. As
> long as "nothing breaks", all good.
> 
>>
>> I thought about this for a long time too and wasn't sure what was best. The
>> existing global enabled store impl clears the bits first then sets the bit. With
>> this approach you can end up with multiple bits set if there is a race to set
>> diffierent values, and you can end up with a faulting thread seeing never if it
>> reads the bits after they have been cleared but before setting them.
> 
> Right, but user space is playing stupid games and can win stupid prices. As long
> as nothing breaks, we're good.
> 
>>
>> I decided to set the new bit before clearing the old bits, which is different; A
>> racing fault will never see "never" but as you say, a race to set the file could
>> result in "never" being set.
>>
>> On reflection, it's probably best to set the bit *last* like the global control
>> does?
> 
> Probably might just slap a simple spinlock in there, so at least the writer side
> is completely serialized. Then you can just set the bit last. It's unlikely that
> readers will actually run into issues, and if they ever would, we could use some
> rcu magic to let them read a consistent state.

I'd prefer to leave it as it is now; clear first, set last without any explicit
serialization. I've convinced myself that nothing breaks and its the same
pattern used by the global control so its consistent. Unless you're insisting on
the spin lock?





From wenst at chromium.org  Thu Dec  7 03:23:40 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 7 Dec 2023 20:23:40 +0900
Subject: [PATCH v3 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <CAGXv+5EyHXWgbvtxx-skzi6FNEnZD8QEHQ2Wq224anY+QKUrew@mail.gmail.com>
References: <20231204084012.2281292-1-wenst@chromium.org> <20231204084012.2281292-7-wenst@chromium.org>
 <ab7988af-e7f9-433d-b35e-138f79ce82c0@collabora.com> <CAGXv+5EyHXWgbvtxx-skzi6FNEnZD8QEHQ2Wq224anY+QKUrew@mail.gmail.com>
Message-ID: <CAGXv+5H9dkYOUEDEYtDOzH9ma3wxuGMLfWy+9pE2swTFdNxOnQ@mail.gmail.com>

On Thu, Dec 7, 2023 at 2:28?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> On Mon, Dec 4, 2023 at 11:27?PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno at collabora.com> wrote:
> >
> > Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> > > Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> > > Krabby design.
> > >
> > > Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> > > convertible device with touchscreen and stylus.
> > >
> > > Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> > > device. It does not have a touchscreen or stylus.
> > >
> > > The two devices both have two variants. The difference is a second
> > > source touchpad controller that shares the same address as the original,
> > > but is incompatible.
> > >
> > > The extra SKU IDs for the Tentacruel devices map to different sensor
> > > components attached to the Embedded Controller. These are not visible
> > > to the main processor.
> > >
> > > Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> > > Acked-by: Conor Dooley <conor.dooley at microchip.com>
> > > ---
> > > Changes since v2:
> > > - Picked up Conor's ack
> > > - Rename touchpad to trackpad
> > > - Drop pinctrl properties from trackpad in tentacruel/tentacool second
> > >    source trackpad
> > >
> > > Changes since v1:
> > > - Reorder SKU numbers in descending order.
> > > - Fixed pinconfig node names
> > > - Moved pinctrl-* properties after interrupts-*
> > > - Switched to interrupts-extended for external components
> > > - Marked ADSP as explicitly disabled, with a comment explaining that it
> > >    stalls the system
> > > - Renamed "touchpad" to "trackpad"
> > > - Dropped bogus "no-laneswap" property from it6505 node
> > > - Moved "realtek,jd-src" property to after all the regulator supplies
> > > - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> > > - Renamed "vgpu" regulator name to allow coupling, with a comment
> > >    containing the name used in the design
> > > - Renamed "cr50" node name to "tpm"
> > > - Moved trackpad_pins reference up to i2c2; workaround for second source
> > >    component resource sharing.
> > > - Fix copyright year
> > > - Fixed touchscreen supply name
> > >
> > >   arch/arm64/boot/dts/mediatek/Makefile         |    4 +
> > >   .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
> > >   .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
> > >   .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
> > >   .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
> > >   .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
> > >   .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
> > >   7 files changed, 2003 insertions(+)
> > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > >
> > > diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> > > index e6e7592a3645..442af61b1305 100644
> > > --- a/arch/arm64/boot/dts/mediatek/Makefile
> > > +++ b/arch/arm64/boot/dts/mediatek/Makefile
> > > @@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
> > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
> > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
> > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> > > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
> > > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
> > > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> > > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
> > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
> > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
> > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> > > new file mode 100644
> > > index 000000000000..9b2b64525961
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> > > @@ -0,0 +1,129 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > +/*
> > > + * Copyright 2022 Google LLC
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "mt8186-corsola.dtsi"
> > > +#include <dt-bindings/gpio/gpio.h>
> > > +
> > > +/ {
> > > +     aliases {
> > > +             i2c4 = &i2c4;
> > > +     };
> > > +};
> > > +
> > > +&dsi_out {
> > > +     remote-endpoint = <&ps8640_in>;
> > > +};
> > > +
> > > +&i2c0 {
> > > +     clock-frequency = <400000>;
> > > +
> > > +     ps8640: edp-bridge at 8 {
> > > +             compatible = "parade,ps8640";
> > > +             reg = <0x8>;
> > > +             powerdown-gpios = <&pio 96 GPIO_ACTIVE_LOW>;
> > > +             reset-gpios = <&pio 98 GPIO_ACTIVE_LOW>;
> > > +             pinctrl-names = "default";
> > > +             pinctrl-0 = <&ps8640_pins>;
> > > +             vdd12-supply = <&mt6366_vrf12_reg>;
> > > +             vdd33-supply = <&mt6366_vcn33_reg>;
> > > +
> > > +             ports {
> > > +                     #address-cells = <1>;
> > > +                     #size-cells = <0>;
> > > +
> > > +                     port at 0 {
> > > +                             reg = <0>;
> > > +
> > > +                             ps8640_in: endpoint {
> > > +                                     remote-endpoint = <&dsi_out>;
> > > +                             };
> > > +                     };
> > > +
> > > +                     port at 1 {
> > > +                             reg = <1>;
> > > +
> > > +                             ps8640_out: endpoint {
> > > +                                     remote-endpoint = <&panel_in>;
> > > +                             };
> > > +                     };
> > > +             };
> > > +
> > > +             aux-bus {
> > > +                     panel {
> > > +                             compatible = "edp-panel";
> > > +                             power-supply = <&pp3300_disp_x>;
> > > +                             backlight = <&backlight_lcd0>;
> > > +
> > > +                             port {
> > > +                                     panel_in: endpoint {
> > > +                                             remote-endpoint = <&ps8640_out>;
> > > +                                     };
> > > +                             };
> > > +                     };
> > > +             };
> > > +     };
> > > +};
> > > +
> > > +&i2c1 {
> > > +     i2c-scl-internal-delay-ns = <10000>;
> > > +
> > > +     touchscreen: touchscreen at 10 {
> > > +             compatible = "hid-over-i2c";
> > > +             reg = <0x10>;
> > > +             interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
> > > +             pinctrl-names = "default";
> > > +             pinctrl-0 = <&touchscreen_pins>;
> > > +             post-power-on-delay-ms = <10>;
> > > +             hid-descr-addr = <0x0001>;
> > > +             vdd-supply = <&pp3300_s3>;
> > > +     };
> > > +};
> > > +
> > > +&i2c4 {
> > > +     pinctrl-names = "default";
> > > +     pinctrl-0 = <&i2c4_pins>;
> > > +     clock-frequency = <400000>;
> > > +     status = "okay";
> > > +
> > > +     proximity at 28 {
> > > +             compatible = "semtech,sx9324";
> > > +             reg = <0x28>;
> > > +             interrupts-extended = <&pio 5 IRQ_TYPE_LEVEL_LOW>;
> > > +             pinctrl-names = "default";
> > > +             pinctrl-0 = <&sar_sensor_pins>;
> > > +             vdd-supply = <&mt6366_vio18_reg>;
> > > +             svdd-supply = <&mt6366_vio18_reg>;
> > > +             #io-channel-cells = <1>;
> >
> >  From the newest DTS coding style document:
> >
> > The following order of properties in device nodes is preferred:
> >
> > 1. compatible
> > 2. reg
> > 3. ranges
> > 4. Standard/common properties (defined by common bindings, e.g. without
> >     vendor-prefixes)
> > 5. Vendor-specific properties
> > 6. status (if applicable)
> > 7. Child nodes, where each node is preceded with a blank line
> >
> > The "status" property is by default "okay", thus it can be omitted.
> >
> > The above-described ordering follows this approach:
> >
> > 1. Most important properties start the node: compatible then bus addressing to
> >     match unit address.
> > 2. Each node will have common properties in similar place.
> > 3. Status is the last information to annotate that device node is or is not
> >     finished (board resources are needed).
>
> Wishing for a checking tool now. :p
>
> > #io-channel-cells goes after `reg` (same for the other instances) :-)
>
> Ack (though it looks weird).
>
> > > +     };
> > > +};
> > > +
> > > +&pio {
> > > +     i2c4_pins: i2c4-pins {
> > > +             pins-bus {
> > > +                     pinmux = <PINMUX_GPIO136__FUNC_SDA4>,
> > > +                              <PINMUX_GPIO135__FUNC_SCL4>;
> > > +                     bias-disable;
> > > +                     drive-strength = <4>;
> > > +                     input-enable;
> > > +             };
> > > +     };
> > > +
> > > +     ps8640_pins: ps8640-pins {
> > > +             pins-pwrdn-rst {
> > > +                     pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
> > > +                              <PINMUX_GPIO98__FUNC_GPIO98>;
> > > +                     output-low;
> > > +             };
> > > +     };
> > > +
> > > +     sar_sensor_pins: sar-sensor-pins {
> > > +             pins-irq {
> > > +                     pinmux = <PINMUX_GPIO5__FUNC_GPIO5>;
> > > +                     input-enable;
> > > +                     bias-pull-up;
> > > +             };
> > > +     };
> > > +};
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> > > new file mode 100644
> > > index 000000000000..9bb64353ca65
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> > > @@ -0,0 +1,57 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > +/*
> > > + * Copyright 2022 Google LLC
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "mt8186-corsola-krabby.dtsi"
> > > +
> > > +/ {
> > > +     model = "Google Tentacool board";
> > > +     compatible = "google,tentacruel-sku327681", "google,tentacruel", "mediatek,mt8186";
> > > +     chassis-type = "laptop";
> > > +};
> > > +
> > > +/* Tentacool omits the pen. */
> > > +&gpio_keys {
> > > +     status = "disabled";
> > > +};
> > > +
> > > +/* Tentacool omits the touchscreen; nothing else is on i2c1. */
> > > +&i2c1 {
> > > +     status = "disabled";
> > > +};
> > > +
> > > +&keyboard_controller {
> > > +     function-row-physmap = <
> > > +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
> > > +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
> > > +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
> > > +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
> > > +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
> > > +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
> > > +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
> > > +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
> > > +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
> > > +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
> > > +     >;
> > > +
> > > +     linux,keymap = <
> > > +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
> > > +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> > > +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> > > +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> > > +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> > > +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> > > +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> > > +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> > > +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> > > +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> > > +             CROS_STD_MAIN_KEYMAP
> > > +     >;
> > > +};
> > > +
> > > +/* Tentacool omits the touchscreen. */
> > > +&touchscreen {
> > > +     status = "disabled";
> > > +};
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > > new file mode 100644
> > > index 000000000000..c3ae6f9616c8
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > > @@ -0,0 +1,24 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > +/*
> > > + * Copyright 2023 Google LLC
> > > + */
> > > +
> > > +#include "mt8186-corsola-tentacool-sku327681.dts"
> > > +
> > > +/ {
> > > +     compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
> > > +};
> > > +
> > > +/* This variant replaces only the trackpad controller. */
> > > +&i2c2 {
> > > +     /delete-node/ trackpad at 15;
> >
> > Why are you deleting the trackpad at 15 node?
> >
> > You can simply override the compatible, or actually omit the compatible string
> > in the *.dtsi file, and set just that in each board *.dts.
> >
> > dtsi:
> >         trackpad_a: trackpad at 15 {
> >                 /* Compatible is set in each board dts */
> >                 reg, interrupts, others
> >         }
> >
> > dts:
> >
> > &trackpad_a {
> >         compatible = "elan,ekth3000";
> > };
>
> The original trackpad at 15 comes from the base design and is used for all
> models other than the ones with the conflicting component. Hence I believe
> it should live in the base .dtsi.
>
> The delete-node makes it much less likely to have any lingering properties.
> These are not nodes that just differ in compatible strings like DSI panels.
> They have incompatible bindings. For example, elan,ekth3000 uses "vcc-supply",
> while "hid-over-i2c" uses "vdd-supply".
>
> And going back to my previous argument, the base design used one specific
> model which is carried over to all the other models.
>
> Suppose I add a phandle to the original trackpad, and do
>
>     /delete-node/ &trackpad;
>
> Would that be better?
>
> > other dts:
> >
> > &trackpad_a {
> >         compatible = "hid-over-i2c";
> > };
> >
> > > +
> > > +     trackpad at 15 {
> > > +             compatible = "hid-over-i2c";
> > > +             reg = <0x15>;
> > > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > > +             hid-descr-addr = <0x0001>;
> > > +             vdd-supply = <&pp3300_s3>;
> > > +             wakeup-source;
> > > +     };
> > > +};
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> > > new file mode 100644
> > > index 000000000000..26d3451a5e47
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> > > @@ -0,0 +1,44 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > +/*
> > > + * Copyright 2022 Google LLC
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "mt8186-corsola-krabby.dtsi"
> > > +
> > > +/ {
> > > +     model = "Google Tentacruel board";
> > > +     compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
> > > +                  "google,tentacruel-sku262145", "google,tentacruel-sku262144",
> > > +                  "google,tentacruel", "mediatek,mt8186";
> > > +     chassis-type = "convertible";
> > > +};
> > > +
> > > +&keyboard_controller {
> > > +     function-row-physmap = <
> > > +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
> > > +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
> > > +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
> > > +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
> > > +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
> > > +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
> > > +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
> > > +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
> > > +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
> > > +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
> > > +     >;
> > > +
> > > +     linux,keymap = <
> > > +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
> > > +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> > > +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> > > +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> > > +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> > > +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> > > +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> > > +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> > > +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> > > +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> > > +             CROS_STD_MAIN_KEYMAP
> > > +     >;
> > > +};
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > > new file mode 100644
> > > index 000000000000..447b57b12b41
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > > @@ -0,0 +1,26 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > +/*
> > > + * Copyright 2023 Google LLC
> > > + */
> > > +
> > > +#include "mt8186-corsola-tentacruel-sku262144.dts"
> > > +
> > > +/ {
> > > +     compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> > > +                  "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> > > +                  "google,tentacruel", "mediatek,mt8186";
> > > +};
> > > +
> > > +/* This variant replaces only the trackpad controller. */
> > > +&i2c2 {
> > > +     /delete-node/ trackpad at 15;
> > > +
> > > +     trackpad at 15 {
> > > +             compatible = "hid-over-i2c";
> > > +             reg = <0x15>;
> > > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > > +             hid-descr-addr = <0x0001>;
> > > +             vdd-supply = <&pp3300_s3>;
> > > +             wakeup-source;
> > > +     };
> > > +};
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > > new file mode 100644
> > > index 000000000000..8726b2916ef1
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > > @@ -0,0 +1,1719 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > +/*
> > > + * Copyright (C) 2022 MediaTek Inc.
> > > + */
> > > +/dts-v1/;
> > > +#include "mt8186.dtsi"
> > > +#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
> > > +#include <dt-bindings/gpio/gpio.h>
> > > +#include <dt-bindings/input/input.h>
> > > +#include <dt-bindings/input/gpio-keys.h>
> > > +#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
> > > +
> > > +/ {
> > > +     aliases {
> > > +             i2c0 = &i2c0;
> > > +             i2c1 = &i2c1;
> > > +             i2c2 = &i2c2;
> > > +             i2c3 = &i2c3;
> > > +             i2c5 = &i2c5;
> > > +             mmc0 = &mmc0;
> > > +             mmc1 = &mmc1;
> > > +             serial0 = &uart0;
> > > +     };
> > > +
> > > +     chosen {
> > > +             stdout-path = "serial0:115200n8";
> > > +     };
> > > +
> > > +     memory at 40000000 {
> > > +             device_type = "memory";
> > > +             /* The size should be filled in by the bootloader. */
> > > +             reg = <0 0x40000000 0 0>;
> > > +     };
> > > +
> > > +     backlight_lcd0: backlight-lcd0 {
> > > +             compatible = "pwm-backlight";
> > > +             pwms = <&pwm0 0 500000>;
> > > +             power-supply = <&ppvar_sys>;
> > > +             enable-gpios = <&pio 152 0>;
> > > +             brightness-levels = <0 1023>;
> > > +             num-interpolated-steps = <1023>;
> > > +             default-brightness-level = <576>;
> > > +     };
> > > +
> > > +     btsco: bt-sco {
> >
> > Do you really need the phandle to bt-sco?
>
> No. But the sound node probably should be referencing it and the dmic
> node via DT instead of hardcoding the DAI and codec names in the machine
> driver.
>
> Anyway, will remove the label for now.
>
> > Also, this node describes a codec, so: "bt-sco-codec" please!
>
> Ack.
>
> > > +             compatible = "linux,bt-sco";
> > > +             #sound-dai-cells = <0>;
> > > +     };
> > > +
> > > +     dmic_codec: dmic-codec {
> >
> > This phandle is unused...
>
> Removed.
>
> > ..snip..
> >
> > > +
> > > +&adsp {
> > > +     memory-region = <&adsp_dma_mem>, <&adsp_mem>;
> > > +     status = "disabled"; /* causes stall */
> >
> > This is a firmware issue: once the correct firmware is uploaded to linux-firmware
> > the dsp node can get enabled... so it we make sure that this happens before this
> > devicetree gets picked, we can avoid a second commit enabling audio.
> >
> > After all, since we *want to* use the Xtensa DSP for audio, without it booted
> > sound won't work *anyway*.... so having the firmware in place can also be seen
> > as a direct dependency of the entire audio functionality.
> >
> > P.S.: The FW that is distributed with ChromeOS works just fine!
>
> I'll give that a try.

I have:

sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-5494c
sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
sof-audio-of-mt8186 10680000.adsp: unknown sof_ext_man header type 3 size 0x30
sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-5494c

and it's still hanging.

And FTR, I think sound is also blocked on the it6505 audio support series.

ChenYu



> > > +};
> > > +
> > > +&afe {
> > > +     i2s0-share = "I2S1";
> > > +     i2s3-share = "I2S2";
> > > +     status = "okay";
> > > +};
> > > +
> >
> > ..snip..
> >
> > > +&i2c2 {
> > > +     pinctrl-names = "default";
> > > +     /*
> > > +      * Trackpad pin put here to work around second source components
> > > +      * sharing the pinmux in steelix designs.
> > > +      */
> > > +     pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
> >
> > There's no choice for now... even if this is not beautiful to see... but it's still
> > ok for me because we can revisit this later when the HW Prober mechanism will be
> > upstreamed.
>
> Yup. Working on that.
>
> > > +     clock-frequency = <400000>;
> > > +     i2c-scl-internal-delay-ns = <10000>;
> > > +     status = "okay";
> > > +
> > > +     trackpad at 15 {
> > > +             compatible = "elan,ekth3000";
> > > +             reg = <0x15>;
> > > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > > +             vcc-supply = <&pp3300_s3>;
> > > +             wakeup-source;
> > > +     };
> > > +};
> > > +
> >
> > Thanks,
> > Angelo
>
> Thanks for the review again.
>
> ChenYu


From david at redhat.com  Thu Dec  7 03:25:08 2023
From: david at redhat.com (David Hildenbrand)
Date: Thu, 7 Dec 2023 12:25:08 +0100
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <4aa520f0-7c84-4e93-88bf-aee6d8d3ea70@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
 <004ed23d-5571-4474-b7fe-7bc08817c165@redhat.com>
 <ca3a2b97-f08e-452a-91dc-1a53dece0aa6@arm.com>
 <378afc6b-f93a-48ad-8aa6-ab171f3b9613@redhat.com>
 <4aa520f0-7c84-4e93-88bf-aee6d8d3ea70@arm.com>
Message-ID: <44fdd46b-ad46-4ae2-a20f-20374acdf464@redhat.com>

On 07.12.23 12:22, Ryan Roberts wrote:
> On 07/12/2023 11:13, David Hildenbrand wrote:
>>>>
>>>>> +
>>>>>  ?????? if (!vma->vm_mm)??????? /* vdso */
>>>>> -??????? return false;
>>>>> +??????? return 0;
>>>>>  ?? ????? /*
>>>>>  ??????? * Explicitly disabled through madvise or prctl, or some
>>>>> @@ -88,16 +141,16 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>>>> unsigned long vm_flags,
>>>>>  ??????? * */
>>>>>  ?????? if ((vm_flags & VM_NOHUGEPAGE) ||
>>>>>  ?????????? test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
>>>>> -??????? return false;
>>>>> +??????? return 0;
>>>>>  ?????? /*
>>>>>  ??????? * If the hardware/firmware marked hugepage support disabled.
>>>>>  ??????? */
>>>>>  ?????? if (transparent_hugepage_flags & (1 <<
>>>>> TRANSPARENT_HUGEPAGE_UNSUPPORTED))
>>>>> -??????? return false;
>>>>> +??????? return 0;
>>>>>  ?? ????? /* khugepaged doesn't collapse DAX vma, but page fault is fine. */
>>>>>  ?????? if (vma_is_dax(vma))
>>>>> -??????? return in_pf;
>>>>> +??????? return in_pf ? orders : 0;
>>>>>  ?? ????? /*
>>>>>  ??????? * khugepaged special VMA and hugetlb VMA.
>>>>> @@ -105,17 +158,29 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>>>> unsigned long vm_flags,
>>>>>  ??????? * VM_MIXEDMAP set.
>>>>>  ??????? */
>>>>>  ?????? if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
>>>>> -??????? return false;
>>>>> +??????? return 0;
>>>>>  ?? ????? /*
>>>>> -???? * Check alignment for file vma and size for both file and anon vma.
>>>>> +???? * Check alignment for file vma and size for both file and anon vma by
>>>>> +???? * filtering out the unsuitable orders.
>>>>>  ??????? *
>>>>>  ??????? * Skip the check for page fault. Huge fault does the check in fault
>>>>> -???? * handlers. And this check is not suitable for huge PUD fault.
>>>>> +???? * handlers.
>>>>>  ??????? */
>>>>> -??? if (!in_pf &&
>>>>> -??????? !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
>>>>> -??????? return false;
>>>>> +??? if (!in_pf) {
>>>>> +??????? int order = first_order(orders);
>>>>> +??????? unsigned long addr;
>>>>> +
>>>>> +??????? while (orders) {
>>>>> +??????????? addr = vma->vm_end - (PAGE_SIZE << order);
>>>>> +??????????? if (thp_vma_suitable_orders(vma, addr, BIT(order)))
>>>>> +??????????????? break;
>>>>
>>>> Comment: you'd want a "thp_vma_suitable_order" helper here. But maybe the
>>>> compiler is smart enough to optimize the loop and everyything else out.
>>>
>>> I'm happy to refactor so that thp_vma_suitable_order() is the basic primitive,
>>> then make thp_vma_suitable_orders() a loop that calls thp_vma_suitable_order()
>>> (that's basically how it is laid out already, just all in one function). Is that
>>> what you are requesting?
>>
>> You got the spirit, yes.
>>
>>>>
>>>> [...]
>>>>
>>>>> +
>>>>> +static ssize_t thpsize_enabled_store(struct kobject *kobj,
>>>>> +???????????????????? struct kobj_attribute *attr,
>>>>> +???????????????????? const char *buf, size_t count)
>>>>> +{
>>>>> +??? int order = to_thpsize(kobj)->order;
>>>>> +??? ssize_t ret = count;
>>>>> +
>>>>> +??? if (sysfs_streq(buf, "always")) {
>>>>> +??????? set_bit(order, &huge_anon_orders_always);
>>>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>>>> +??? } else if (sysfs_streq(buf, "inherit")) {
>>>>> +??????? set_bit(order, &huge_anon_orders_inherit);
>>>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>>>> +??? } else if (sysfs_streq(buf, "madvise")) {
>>>>> +??????? set_bit(order, &huge_anon_orders_madvise);
>>>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>>>> +??? } else if (sysfs_streq(buf, "never")) {
>>>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>>>
>>>> Note: I was wondering for a second if some concurrent cames could lead to an
>>>> inconsistent state. I think in the worst case we'll simply end up with "never"
>>>> on races.
>>>
>>> You mean if different threads try to write different values to this file
>>> concurrently? Or if there is a concurrent fault that tries to read the flags
>>> while they are being modified?
>>
>> I thought about what you said first, but what you said last might also apply. As
>> long as "nothing breaks", all good.
>>
>>>
>>> I thought about this for a long time too and wasn't sure what was best. The
>>> existing global enabled store impl clears the bits first then sets the bit. With
>>> this approach you can end up with multiple bits set if there is a race to set
>>> diffierent values, and you can end up with a faulting thread seeing never if it
>>> reads the bits after they have been cleared but before setting them.
>>
>> Right, but user space is playing stupid games and can win stupid prices. As long
>> as nothing breaks, we're good.
>>
>>>
>>> I decided to set the new bit before clearing the old bits, which is different; A
>>> racing fault will never see "never" but as you say, a race to set the file could
>>> result in "never" being set.
>>>
>>> On reflection, it's probably best to set the bit *last* like the global control
>>> does?
>>
>> Probably might just slap a simple spinlock in there, so at least the writer side
>> is completely serialized. Then you can just set the bit last. It's unlikely that
>> readers will actually run into issues, and if they ever would, we could use some
>> rcu magic to let them read a consistent state.
> 
> I'd prefer to leave it as it is now; clear first, set last without any explicit
> serialization. I've convinced myself that nothing breaks and its the same
> pattern used by the global control so its consistent. Unless you're insisting on
> the spin lock?

No, not at all. But it would certainly remove any possible concerns :)

-- 
Cheers,

David / dhildenb



From fshao at chromium.org  Thu Dec  7 03:17:58 2023
From: fshao at chromium.org (Fei Shao)
Date: Thu, 7 Dec 2023 19:17:58 +0800
Subject: [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free()
 error log criteria
In-Reply-To: <6c693161-0e89-4f9d-9a92-18f3783eefd2@collabora.com>
References: <20231113123049.4117280-1-fshao@chromium.org> <20231113123049.4117280-4-fshao@chromium.org>
 <6c693161-0e89-4f9d-9a92-18f3783eefd2@collabora.com>
Message-ID: <CAC=S1nhp3HoKGQr1UgKtZJ9SLMqvm-G_YZi9dEWWF3tj2d=OFQ@mail.gmail.com>

Hi Angelo,

On Wed, Dec 6, 2023 at 6:19?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 13/11/23 13:26, Fei Shao ha scritto:
> > mtk_vcodec_mem_free() shouldn't print error if the target DMA buffer has
> > never been allocated or was freed properly in the previous call. That
> > makes log confusing.
> >
> > Update the error path to print log only when the caller attempts to free
> > nonzero-size buffer with VA being NULL, which indicates something indeed
> > went wrong.
> >
> > This brings another benefit that the callers no more need to check
> > mem->va explicitly to avoid the error, which can make the code more
> > compact and neat.
> >
> > Signed-off-by: Fei Shao <fshao at chromium.org>
>
> I think that this error is supposed to catch two issues in one:
>   - We're called to free no memory (something that does make no sense),
>     this may happen for example when calling xxx_free() twice, and it
>     is a mistake that *must* be fixed;
When I made the change, I was thinking of kfree() that doesn't warn
against a NULL pointer.
I imagine mtk_vcodec_mem_free() calls with NULL VA and mem size 0
probably have the similar nuance (if the buffer exists, free it; never
mind otherwise), but I could have missed some important differences
specific to the MTK vcodec driver.

Looking at the mtk_vcodec_mem_free() usages, almost every one of those
checks VA beforehand, but nothing else - they don't warn or do
anything special when they encounter a NULL VA, and they should if
that's a concern.
Some even don't check at all (and I think that's why I ended up seeing
the errors mentioned in the cover letter). As for that, I think
there's nothing else we can fix except prepending "if (mem->va)".
So from all this, I feel perhaps we don't need to worry much about
those NULL VA, and we can further remove the checks (or at least move
it into mtk_vcodec_mem_free()) to trim the lines in the driver. That's
the reason for patch [4/4].

Not sure if that makes sense to you.

>   - We're failing to free memory for real (which you covered)
>
> ....that said, I think that if you want to clarify the error messages
> in this function, it should look something like this:
>
> if (!mem->va) {
>         mtk_v4l2_err(plat_dev, "%s: Tried to free a NULL VA", __func__);
>         if (mem->size)
>                 mtk_v4l2_err(plat_dev, "Failed to free %lu bytes", mem->size);
>         return;
> }
Sure, I can revise the patch with this, but I also want to make sure
if the NULL VA print needs to be an error.
If you still think it should, I guess I'll drop the current patch
[4/4] and instead add the check before every mtk_vcodec_mem_free()
calls. This should also work for the issue I want to address in the
first place.

And thanks for the review.  :)

Regards,
Fei

> Cheers,
> Angelo
>


From quic_mnaresh at quicinc.com  Thu Dec  7 03:26:44 2023
From: quic_mnaresh at quicinc.com (Naresh Maramaina)
Date: Thu, 7 Dec 2023 16:56:44 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231206152646.GH12802@thinkpad>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <20231206152646.GH12802@thinkpad>
Message-ID: <090f3c8c-bbd8-4036-aaa1-d18c7a854ee9@quicinc.com>



On 12/6/2023 8:56 PM, Manivannan Sadhasivam wrote:
> On Mon, Dec 04, 2023 at 08:00:59PM +0530, Maramaina Naresh wrote:
>> Register ufs driver to CPU latency PM QoS framework can improves
>> ufs device random io performance.
>>
>> PM QoS initialization will insert new QoS request into the CPU
>> latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
>> value.
>>
>> UFS driver will vote for performance mode on scale up and power
>> save mode for scale down.
>>
>> If clock scaling feature is not enabled then voting will be based
>> on clock on or off condition.
>>
>> tiotest benchmark tool io performance results on sm8550 platform:
>>
>> 1. Without PM QoS support
>> 	Type (Speed in)    | Average of 18 iterations
>> 	Random Write(IPOS) | 41065.13
>> 	Random Read(IPOS)  | 37101.3
>>
>> 2. With PM QoS support
>> 	Type (Speed in)    | Average of 18 iterations
>> 	Random Write(IPOS) | 46784.9
>> 	Random Read(IPOS)  | 42943.4
>> (Improvement % with PM QoS = ~15%).
>>
>> Co-developed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
>> Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
>> Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall at quicinc.com>
>> Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
>> ---
>>   drivers/ufs/core/ufshcd-priv.h |  8 +++++
>>   drivers/ufs/core/ufshcd.c      | 62 ++++++++++++++++++++++++++++++++++
>>   include/ufs/ufshcd.h           | 16 +++++++++
>>   3 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/ufs/core/ufshcd-priv.h b/drivers/ufs/core/ufshcd-priv.h
>> index f42d99ce5bf1..536805f6c4e1 100644
>> --- a/drivers/ufs/core/ufshcd-priv.h
>> +++ b/drivers/ufs/core/ufshcd-priv.h
>> @@ -241,6 +241,14 @@ static inline void ufshcd_vops_config_scaling_param(struct ufs_hba *hba,
>>   		hba->vops->config_scaling_param(hba, p, data);
>>   }
>>   
>> +static inline u32 ufshcd_vops_config_qos_vote(struct ufs_hba *hba)
>> +{
>> +	if (hba->vops && hba->vops->config_qos_vote)
>> +		return hba->vops->config_qos_vote(hba);
> 
> Please remove this callback as Bart noted.
> 

Sure Mani, will takecare of this comment.

>> +
>> +	return UFSHCD_QOS_DEFAULT_VOTE;
>> +}
>> +
>>   static inline void ufshcd_vops_reinit_notify(struct ufs_hba *hba)
>>   {
>>   	if (hba->vops && hba->vops->reinit_notify)
>> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
>> index ae9936fc6ffb..13370febd2b5 100644
>> --- a/drivers/ufs/core/ufshcd.c
>> +++ b/drivers/ufs/core/ufshcd.c
>> @@ -1001,6 +1001,20 @@ static bool ufshcd_is_unipro_pa_params_tuning_req(struct ufs_hba *hba)
>>   	return ufshcd_get_local_unipro_ver(hba) < UFS_UNIPRO_VER_1_6;
>>   }
>>   
>> +/**
>> + * ufshcd_pm_qos_perf - vote for PM QoS performance or power save mode
> 
> ufshcd_pm_qos_update() - Update PM QoS request
> 

Sure Mani, will takecare of this comment.

>> + * @hba: per adapter instance
>> + * @on: If True, vote for perf PM QoS mode otherwise power save mode
>> + */
>> +static void ufshcd_pm_qos_perf(struct ufs_hba *hba, bool on)
>> +{
>> +	if (!hba->pm_qos_init)
>> +		return;
>> +
>> +	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? hba->qos_vote
>> +							: PM_QOS_DEFAULT_VALUE);
>> +}
>> +
>>   /**
>>    * ufshcd_set_clk_freq - set UFS controller clock frequencies
>>    * @hba: per adapter instance
>> @@ -1153,6 +1167,10 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, unsigned long freq,
>>   	trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
>>   			(scale_up ? "up" : "down"),
>>   			ktime_to_us(ktime_sub(ktime_get(), start)), ret);
>> +
>> +	if (!ret)
>> +		ufshcd_pm_qos_perf(hba, scale_up);
> 
> Can't you just move this before trace_ufshcd_profile_clk_scaling()? This also
> avoids checking for !ret.
> 

In this case, we need to use goto out; inside if(ret) of 
ufshcd_vops_clk_scale_notify.
will do the above change, to enable ufshcd_pm_qos_perf before the out flag.

>> +
>>   	return ret;
>>   }
>>   
>> @@ -9204,6 +9222,8 @@ static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
>>   	if (ret)
>>   		return ret;
>>   
>> +	if (!ufshcd_is_clkscaling_supported(hba))
>> +		ufshcd_pm_qos_perf(hba, on);
>>   out:
>>   	if (ret) {
>>   		list_for_each_entry(clki, head, list) {
>> @@ -9296,6 +9316,45 @@ static int ufshcd_init_clocks(struct ufs_hba *hba)
>>   	return ret;
>>   }
>>   
>> +/**
>> + * ufshcd_pm_qos_init - initialize PM QoS instance
> 
> "Initialize PM QoS request"
> 

Sure Mani, will takecare of this comment.

>> + * @hba: per adapter instance
>> + */
>> +static void ufshcd_pm_qos_init(struct ufs_hba *hba)
>> +{
>> +	if (!(hba->caps & UFSHCD_CAP_PM_QOS))
>> +		return;
>> +
>> +	/*
>> +	 * called to configure PM QoS vote value for UFS host,
>> +	 * expecting qos vote return value from caller else
>> +	 * default vote value will be return.
>> +	 */
>> +	hba->qos_vote = ufshcd_vops_config_qos_vote(hba);
> 
> No need of this variable too if you get rid of the callback.
> 
>> +	cpu_latency_qos_add_request(&hba->pm_qos_req,
>> +					PM_QOS_DEFAULT_VALUE);
>> +
>> +	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
>> +		hba->pm_qos_init = true;
> 
> Why do you need this flag?

this flag ensure UFS qos request got added into the Global PM QoS list.

> 
>> +
>> +	dev_dbg(hba->dev, "%s: QoS %s, qos_vote: %u\n", __func__,
>> +		hba->pm_qos_init ? "initialized" : "uninitialized",
>> +		hba->qos_vote);
>> +}
>> +
>> +/**
>> + * ufshcd_pm_qos_exit - remove instance from PM QoS
>> + * @hba: per adapter instance
>> + */
>> +static void ufshcd_pm_qos_exit(struct ufs_hba *hba)
>> +{
>> +	if (!hba->pm_qos_init)
>> +		return;
>> +
>> +	cpu_latency_qos_remove_request(&hba->pm_qos_req);
>> +	hba->pm_qos_init = false;
>> +}
>> +
> 
> [...]
> 
>>   /**
>>    * struct ufs_hba - per adapter private structure
>>    * @mmio_base: UFSHCI base register address
>> @@ -912,6 +923,8 @@ enum ufshcd_mcq_opr {
>>    * @mcq_base: Multi circular queue registers base address
>>    * @uhq: array of supported hardware queues
>>    * @dev_cmd_queue: Queue for issuing device management commands
>> + * @pm_qos_req: PM QoS request handle
>> + * @pm_qos_init: flag to check if pm qos init completed
>>    */
>>   struct ufs_hba {
>>   	void __iomem *mmio_base;
>> @@ -1076,6 +1089,9 @@ struct ufs_hba {
>>   	struct ufs_hw_queue *uhq;
>>   	struct ufs_hw_queue *dev_cmd_queue;
>>   	struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
>> +	struct pm_qos_request pm_qos_req;
>> +	bool pm_qos_init;
>> +	u32 qos_vote;
> 
> Order doesn't match Kdoc.
>

we are removing qos_vote variable in next patch series.

> - Mani
> 

Thanks,
Naresh.


From wenst at chromium.org  Thu Dec  7 03:28:05 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 7 Dec 2023 20:28:05 +0900
Subject: [PATCH v3 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <CAGXv+5H9dkYOUEDEYtDOzH9ma3wxuGMLfWy+9pE2swTFdNxOnQ@mail.gmail.com>
References: <20231204084012.2281292-1-wenst@chromium.org> <20231204084012.2281292-7-wenst@chromium.org>
 <ab7988af-e7f9-433d-b35e-138f79ce82c0@collabora.com> <CAGXv+5EyHXWgbvtxx-skzi6FNEnZD8QEHQ2Wq224anY+QKUrew@mail.gmail.com>
 <CAGXv+5H9dkYOUEDEYtDOzH9ma3wxuGMLfWy+9pE2swTFdNxOnQ@mail.gmail.com>
Message-ID: <CAGXv+5FhTwovv7qztGfC+FG8pb-kzZomRPgKboFYJmBTZ=mj6g@mail.gmail.com>

On Thu, Dec 7, 2023 at 8:23?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> On Thu, Dec 7, 2023 at 2:28?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >
> > On Mon, Dec 4, 2023 at 11:27?PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno at collabora.com> wrote:
> > >
> > > Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> > > > Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> > > > Krabby design.
> > > >
> > > > Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> > > > convertible device with touchscreen and stylus.
> > > >
> > > > Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> > > > device. It does not have a touchscreen or stylus.
> > > >
> > > > The two devices both have two variants. The difference is a second
> > > > source touchpad controller that shares the same address as the original,
> > > > but is incompatible.
> > > >
> > > > The extra SKU IDs for the Tentacruel devices map to different sensor
> > > > components attached to the Embedded Controller. These are not visible
> > > > to the main processor.
> > > >
> > > > Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> > > > Acked-by: Conor Dooley <conor.dooley at microchip.com>
> > > > ---
> > > > Changes since v2:
> > > > - Picked up Conor's ack
> > > > - Rename touchpad to trackpad
> > > > - Drop pinctrl properties from trackpad in tentacruel/tentacool second
> > > >    source trackpad
> > > >
> > > > Changes since v1:
> > > > - Reorder SKU numbers in descending order.
> > > > - Fixed pinconfig node names
> > > > - Moved pinctrl-* properties after interrupts-*
> > > > - Switched to interrupts-extended for external components
> > > > - Marked ADSP as explicitly disabled, with a comment explaining that it
> > > >    stalls the system
> > > > - Renamed "touchpad" to "trackpad"
> > > > - Dropped bogus "no-laneswap" property from it6505 node
> > > > - Moved "realtek,jd-src" property to after all the regulator supplies
> > > > - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> > > > - Renamed "vgpu" regulator name to allow coupling, with a comment
> > > >    containing the name used in the design
> > > > - Renamed "cr50" node name to "tpm"
> > > > - Moved trackpad_pins reference up to i2c2; workaround for second source
> > > >    component resource sharing.
> > > > - Fix copyright year
> > > > - Fixed touchscreen supply name
> > > >
> > > >   arch/arm64/boot/dts/mediatek/Makefile         |    4 +
> > > >   .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
> > > >   .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
> > > >   .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
> > > >   .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
> > > >   .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
> > > >   .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
> > > >   7 files changed, 2003 insertions(+)
> > > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> > > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> > > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> > > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > > >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > > >
> > > > diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> > > > index e6e7592a3645..442af61b1305 100644
> > > > --- a/arch/arm64/boot/dts/mediatek/Makefile
> > > > +++ b/arch/arm64/boot/dts/mediatek/Makefile
> > > > @@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
> > > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
> > > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
> > > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> > > > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
> > > > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
> > > > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> > > > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
> > > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
> > > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
> > > >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
> > > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> > > > new file mode 100644
> > > > index 000000000000..9b2b64525961
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> > > > @@ -0,0 +1,129 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > > +/*
> > > > + * Copyright 2022 Google LLC
> > > > + */
> > > > +
> > > > +/dts-v1/;
> > > > +#include "mt8186-corsola.dtsi"
> > > > +#include <dt-bindings/gpio/gpio.h>
> > > > +
> > > > +/ {
> > > > +     aliases {
> > > > +             i2c4 = &i2c4;
> > > > +     };
> > > > +};
> > > > +
> > > > +&dsi_out {
> > > > +     remote-endpoint = <&ps8640_in>;
> > > > +};
> > > > +
> > > > +&i2c0 {
> > > > +     clock-frequency = <400000>;
> > > > +
> > > > +     ps8640: edp-bridge at 8 {
> > > > +             compatible = "parade,ps8640";
> > > > +             reg = <0x8>;
> > > > +             powerdown-gpios = <&pio 96 GPIO_ACTIVE_LOW>;
> > > > +             reset-gpios = <&pio 98 GPIO_ACTIVE_LOW>;
> > > > +             pinctrl-names = "default";
> > > > +             pinctrl-0 = <&ps8640_pins>;
> > > > +             vdd12-supply = <&mt6366_vrf12_reg>;
> > > > +             vdd33-supply = <&mt6366_vcn33_reg>;
> > > > +
> > > > +             ports {
> > > > +                     #address-cells = <1>;
> > > > +                     #size-cells = <0>;
> > > > +
> > > > +                     port at 0 {
> > > > +                             reg = <0>;
> > > > +
> > > > +                             ps8640_in: endpoint {
> > > > +                                     remote-endpoint = <&dsi_out>;
> > > > +                             };
> > > > +                     };
> > > > +
> > > > +                     port at 1 {
> > > > +                             reg = <1>;
> > > > +
> > > > +                             ps8640_out: endpoint {
> > > > +                                     remote-endpoint = <&panel_in>;
> > > > +                             };
> > > > +                     };
> > > > +             };
> > > > +
> > > > +             aux-bus {
> > > > +                     panel {
> > > > +                             compatible = "edp-panel";
> > > > +                             power-supply = <&pp3300_disp_x>;
> > > > +                             backlight = <&backlight_lcd0>;
> > > > +
> > > > +                             port {
> > > > +                                     panel_in: endpoint {
> > > > +                                             remote-endpoint = <&ps8640_out>;
> > > > +                                     };
> > > > +                             };
> > > > +                     };
> > > > +             };
> > > > +     };
> > > > +};
> > > > +
> > > > +&i2c1 {
> > > > +     i2c-scl-internal-delay-ns = <10000>;
> > > > +
> > > > +     touchscreen: touchscreen at 10 {
> > > > +             compatible = "hid-over-i2c";
> > > > +             reg = <0x10>;
> > > > +             interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
> > > > +             pinctrl-names = "default";
> > > > +             pinctrl-0 = <&touchscreen_pins>;
> > > > +             post-power-on-delay-ms = <10>;
> > > > +             hid-descr-addr = <0x0001>;
> > > > +             vdd-supply = <&pp3300_s3>;
> > > > +     };
> > > > +};
> > > > +
> > > > +&i2c4 {
> > > > +     pinctrl-names = "default";
> > > > +     pinctrl-0 = <&i2c4_pins>;
> > > > +     clock-frequency = <400000>;
> > > > +     status = "okay";
> > > > +
> > > > +     proximity at 28 {
> > > > +             compatible = "semtech,sx9324";
> > > > +             reg = <0x28>;
> > > > +             interrupts-extended = <&pio 5 IRQ_TYPE_LEVEL_LOW>;
> > > > +             pinctrl-names = "default";
> > > > +             pinctrl-0 = <&sar_sensor_pins>;
> > > > +             vdd-supply = <&mt6366_vio18_reg>;
> > > > +             svdd-supply = <&mt6366_vio18_reg>;
> > > > +             #io-channel-cells = <1>;
> > >
> > >  From the newest DTS coding style document:
> > >
> > > The following order of properties in device nodes is preferred:
> > >
> > > 1. compatible
> > > 2. reg
> > > 3. ranges
> > > 4. Standard/common properties (defined by common bindings, e.g. without
> > >     vendor-prefixes)
> > > 5. Vendor-specific properties
> > > 6. status (if applicable)
> > > 7. Child nodes, where each node is preceded with a blank line
> > >
> > > The "status" property is by default "okay", thus it can be omitted.
> > >
> > > The above-described ordering follows this approach:
> > >
> > > 1. Most important properties start the node: compatible then bus addressing to
> > >     match unit address.
> > > 2. Each node will have common properties in similar place.
> > > 3. Status is the last information to annotate that device node is or is not
> > >     finished (board resources are needed).
> >
> > Wishing for a checking tool now. :p
> >
> > > #io-channel-cells goes after `reg` (same for the other instances) :-)
> >
> > Ack (though it looks weird).
> >
> > > > +     };
> > > > +};
> > > > +
> > > > +&pio {
> > > > +     i2c4_pins: i2c4-pins {
> > > > +             pins-bus {
> > > > +                     pinmux = <PINMUX_GPIO136__FUNC_SDA4>,
> > > > +                              <PINMUX_GPIO135__FUNC_SCL4>;
> > > > +                     bias-disable;
> > > > +                     drive-strength = <4>;
> > > > +                     input-enable;
> > > > +             };
> > > > +     };
> > > > +
> > > > +     ps8640_pins: ps8640-pins {
> > > > +             pins-pwrdn-rst {
> > > > +                     pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
> > > > +                              <PINMUX_GPIO98__FUNC_GPIO98>;
> > > > +                     output-low;
> > > > +             };
> > > > +     };
> > > > +
> > > > +     sar_sensor_pins: sar-sensor-pins {
> > > > +             pins-irq {
> > > > +                     pinmux = <PINMUX_GPIO5__FUNC_GPIO5>;
> > > > +                     input-enable;
> > > > +                     bias-pull-up;
> > > > +             };
> > > > +     };
> > > > +};
> > > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> > > > new file mode 100644
> > > > index 000000000000..9bb64353ca65
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> > > > @@ -0,0 +1,57 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > > +/*
> > > > + * Copyright 2022 Google LLC
> > > > + */
> > > > +
> > > > +/dts-v1/;
> > > > +#include "mt8186-corsola-krabby.dtsi"
> > > > +
> > > > +/ {
> > > > +     model = "Google Tentacool board";
> > > > +     compatible = "google,tentacruel-sku327681", "google,tentacruel", "mediatek,mt8186";
> > > > +     chassis-type = "laptop";
> > > > +};
> > > > +
> > > > +/* Tentacool omits the pen. */
> > > > +&gpio_keys {
> > > > +     status = "disabled";
> > > > +};
> > > > +
> > > > +/* Tentacool omits the touchscreen; nothing else is on i2c1. */
> > > > +&i2c1 {
> > > > +     status = "disabled";
> > > > +};
> > > > +
> > > > +&keyboard_controller {
> > > > +     function-row-physmap = <
> > > > +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
> > > > +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
> > > > +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
> > > > +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
> > > > +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
> > > > +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
> > > > +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
> > > > +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
> > > > +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
> > > > +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
> > > > +     >;
> > > > +
> > > > +     linux,keymap = <
> > > > +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
> > > > +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> > > > +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> > > > +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> > > > +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> > > > +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> > > > +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> > > > +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> > > > +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> > > > +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> > > > +             CROS_STD_MAIN_KEYMAP
> > > > +     >;
> > > > +};
> > > > +
> > > > +/* Tentacool omits the touchscreen. */
> > > > +&touchscreen {
> > > > +     status = "disabled";
> > > > +};
> > > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > > > new file mode 100644
> > > > index 000000000000..c3ae6f9616c8
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> > > > @@ -0,0 +1,24 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > > +/*
> > > > + * Copyright 2023 Google LLC
> > > > + */
> > > > +
> > > > +#include "mt8186-corsola-tentacool-sku327681.dts"
> > > > +
> > > > +/ {
> > > > +     compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
> > > > +};
> > > > +
> > > > +/* This variant replaces only the trackpad controller. */
> > > > +&i2c2 {
> > > > +     /delete-node/ trackpad at 15;
> > >
> > > Why are you deleting the trackpad at 15 node?
> > >
> > > You can simply override the compatible, or actually omit the compatible string
> > > in the *.dtsi file, and set just that in each board *.dts.
> > >
> > > dtsi:
> > >         trackpad_a: trackpad at 15 {
> > >                 /* Compatible is set in each board dts */
> > >                 reg, interrupts, others
> > >         }
> > >
> > > dts:
> > >
> > > &trackpad_a {
> > >         compatible = "elan,ekth3000";
> > > };
> >
> > The original trackpad at 15 comes from the base design and is used for all
> > models other than the ones with the conflicting component. Hence I believe
> > it should live in the base .dtsi.
> >
> > The delete-node makes it much less likely to have any lingering properties.
> > These are not nodes that just differ in compatible strings like DSI panels.
> > They have incompatible bindings. For example, elan,ekth3000 uses "vcc-supply",
> > while "hid-over-i2c" uses "vdd-supply".
> >
> > And going back to my previous argument, the base design used one specific
> > model which is carried over to all the other models.
> >
> > Suppose I add a phandle to the original trackpad, and do
> >
> >     /delete-node/ &trackpad;
> >
> > Would that be better?
> >
> > > other dts:
> > >
> > > &trackpad_a {
> > >         compatible = "hid-over-i2c";
> > > };
> > >
> > > > +
> > > > +     trackpad at 15 {
> > > > +             compatible = "hid-over-i2c";
> > > > +             reg = <0x15>;
> > > > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > > > +             hid-descr-addr = <0x0001>;
> > > > +             vdd-supply = <&pp3300_s3>;
> > > > +             wakeup-source;
> > > > +     };
> > > > +};
> > > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> > > > new file mode 100644
> > > > index 000000000000..26d3451a5e47
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> > > > @@ -0,0 +1,44 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > > +/*
> > > > + * Copyright 2022 Google LLC
> > > > + */
> > > > +
> > > > +/dts-v1/;
> > > > +#include "mt8186-corsola-krabby.dtsi"
> > > > +
> > > > +/ {
> > > > +     model = "Google Tentacruel board";
> > > > +     compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
> > > > +                  "google,tentacruel-sku262145", "google,tentacruel-sku262144",
> > > > +                  "google,tentacruel", "mediatek,mt8186";
> > > > +     chassis-type = "convertible";
> > > > +};
> > > > +
> > > > +&keyboard_controller {
> > > > +     function-row-physmap = <
> > > > +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
> > > > +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
> > > > +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
> > > > +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
> > > > +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
> > > > +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
> > > > +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
> > > > +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
> > > > +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
> > > > +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
> > > > +     >;
> > > > +
> > > > +     linux,keymap = <
> > > > +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
> > > > +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> > > > +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> > > > +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> > > > +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> > > > +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> > > > +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> > > > +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> > > > +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> > > > +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> > > > +             CROS_STD_MAIN_KEYMAP
> > > > +     >;
> > > > +};
> > > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > > > new file mode 100644
> > > > index 000000000000..447b57b12b41
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > > > @@ -0,0 +1,26 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > > +/*
> > > > + * Copyright 2023 Google LLC
> > > > + */
> > > > +
> > > > +#include "mt8186-corsola-tentacruel-sku262144.dts"
> > > > +
> > > > +/ {
> > > > +     compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> > > > +                  "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> > > > +                  "google,tentacruel", "mediatek,mt8186";
> > > > +};
> > > > +
> > > > +/* This variant replaces only the trackpad controller. */
> > > > +&i2c2 {
> > > > +     /delete-node/ trackpad at 15;
> > > > +
> > > > +     trackpad at 15 {
> > > > +             compatible = "hid-over-i2c";
> > > > +             reg = <0x15>;
> > > > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > > > +             hid-descr-addr = <0x0001>;
> > > > +             vdd-supply = <&pp3300_s3>;
> > > > +             wakeup-source;
> > > > +     };
> > > > +};
> > > > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > > > new file mode 100644
> > > > index 000000000000..8726b2916ef1
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > > > @@ -0,0 +1,1719 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > > +/*
> > > > + * Copyright (C) 2022 MediaTek Inc.
> > > > + */
> > > > +/dts-v1/;
> > > > +#include "mt8186.dtsi"
> > > > +#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
> > > > +#include <dt-bindings/gpio/gpio.h>
> > > > +#include <dt-bindings/input/input.h>
> > > > +#include <dt-bindings/input/gpio-keys.h>
> > > > +#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
> > > > +
> > > > +/ {
> > > > +     aliases {
> > > > +             i2c0 = &i2c0;
> > > > +             i2c1 = &i2c1;
> > > > +             i2c2 = &i2c2;
> > > > +             i2c3 = &i2c3;
> > > > +             i2c5 = &i2c5;
> > > > +             mmc0 = &mmc0;
> > > > +             mmc1 = &mmc1;
> > > > +             serial0 = &uart0;
> > > > +     };
> > > > +
> > > > +     chosen {
> > > > +             stdout-path = "serial0:115200n8";
> > > > +     };
> > > > +
> > > > +     memory at 40000000 {
> > > > +             device_type = "memory";
> > > > +             /* The size should be filled in by the bootloader. */
> > > > +             reg = <0 0x40000000 0 0>;
> > > > +     };
> > > > +
> > > > +     backlight_lcd0: backlight-lcd0 {
> > > > +             compatible = "pwm-backlight";
> > > > +             pwms = <&pwm0 0 500000>;
> > > > +             power-supply = <&ppvar_sys>;
> > > > +             enable-gpios = <&pio 152 0>;
> > > > +             brightness-levels = <0 1023>;
> > > > +             num-interpolated-steps = <1023>;
> > > > +             default-brightness-level = <576>;
> > > > +     };
> > > > +
> > > > +     btsco: bt-sco {
> > >
> > > Do you really need the phandle to bt-sco?
> >
> > No. But the sound node probably should be referencing it and the dmic
> > node via DT instead of hardcoding the DAI and codec names in the machine
> > driver.
> >
> > Anyway, will remove the label for now.
> >
> > > Also, this node describes a codec, so: "bt-sco-codec" please!
> >
> > Ack.
> >
> > > > +             compatible = "linux,bt-sco";
> > > > +             #sound-dai-cells = <0>;
> > > > +     };
> > > > +
> > > > +     dmic_codec: dmic-codec {
> > >
> > > This phandle is unused...
> >
> > Removed.
> >
> > > ..snip..
> > >
> > > > +
> > > > +&adsp {
> > > > +     memory-region = <&adsp_dma_mem>, <&adsp_mem>;
> > > > +     status = "disabled"; /* causes stall */
> > >
> > > This is a firmware issue: once the correct firmware is uploaded to linux-firmware
> > > the dsp node can get enabled... so it we make sure that this happens before this
> > > devicetree gets picked, we can avoid a second commit enabling audio.
> > >
> > > After all, since we *want to* use the Xtensa DSP for audio, without it booted
> > > sound won't work *anyway*.... so having the firmware in place can also be seen
> > > as a direct dependency of the entire audio functionality.
> > >
> > > P.S.: The FW that is distributed with ChromeOS works just fine!
> >
> > I'll give that a try.
>
> I have:
>
> sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-5494c
> sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
> sof-audio-of-mt8186 10680000.adsp: unknown sof_ext_man header type 3 size 0x30
> sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-5494c
>
> and it's still hanging.

Looks like I was still using the bad version due to module options...

After removing the options, I now have:

sof-audio-of-mt8186 10680000.adsp: DT DSP detected
sof-audio-of-mt8186 10680000.adsp: assigned reserved memory node memory at 61000000
sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-714c6
sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
sof-audio-of-mt8186 10680000.adsp: unknown sof_ext_man header type 3 size 0x30
sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-714c6
sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0

But sound is still deferring probe:

# cat /sys/kernel/debug/devices_deferred
sound    mt8186_mt6366_rt1019_rt5682s:
mt8186_mt6366_rt1019_rt5682s_dev_probe snd_soc_register_card fail

ChenYu

> And FTR, I think sound is also blocked on the it6505 audio support series.
>
> ChenYu
>
>
>
> > > > +};
> > > > +
> > > > +&afe {
> > > > +     i2s0-share = "I2S1";
> > > > +     i2s3-share = "I2S2";
> > > > +     status = "okay";
> > > > +};
> > > > +
> > >
> > > ..snip..
> > >
> > > > +&i2c2 {
> > > > +     pinctrl-names = "default";
> > > > +     /*
> > > > +      * Trackpad pin put here to work around second source components
> > > > +      * sharing the pinmux in steelix designs.
> > > > +      */
> > > > +     pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
> > >
> > > There's no choice for now... even if this is not beautiful to see... but it's still
> > > ok for me because we can revisit this later when the HW Prober mechanism will be
> > > upstreamed.
> >
> > Yup. Working on that.
> >
> > > > +     clock-frequency = <400000>;
> > > > +     i2c-scl-internal-delay-ns = <10000>;
> > > > +     status = "okay";
> > > > +
> > > > +     trackpad at 15 {
> > > > +             compatible = "elan,ekth3000";
> > > > +             reg = <0x15>;
> > > > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > > > +             vcc-supply = <&pp3300_s3>;
> > > > +             wakeup-source;
> > > > +     };
> > > > +};
> > > > +
> > >
> > > Thanks,
> > > Angelo
> >
> > Thanks for the review again.
> >
> > ChenYu


From sakari.ailus at linux.intel.com  Thu Dec  7 03:34:03 2023
From: sakari.ailus at linux.intel.com (Sakari Ailus)
Date: Thu, 7 Dec 2023 11:34:03 +0000
Subject: [PATCH 1/2] media: i2c: Add GC08A3 image sensor driver
In-Reply-To: <20231207052016.25954-2-zhi.mao@mediatek.com>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
 <20231207052016.25954-2-zhi.mao@mediatek.com>
Message-ID: <ZXGtqwjYruBQVaUr@kekkonen.localdomain>

Hi Zhi,

Thanks for the patch and please see my comments below.

On Thu, Dec 07, 2023 at 01:20:15PM +0800, Zhi Mao wrote:
> Add a V4L2 sub-device driver for Galaxycore GC08A3 image sensor.
> 
> Reviewed-By: yunkec at chromium.org
> Signed-off-by: Zhi Mao <zhi.mao at mediatek.com>
> ---
>  drivers/media/i2c/Kconfig  |   14 +
>  drivers/media/i2c/Makefile |    1 +
>  drivers/media/i2c/gc08a3.c | 1888 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 1903 insertions(+)
>  create mode 100644 drivers/media/i2c/gc08a3.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 59ee0ca2c978..e2718bfdf369 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -50,6 +50,20 @@ config VIDEO_AR0521
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called ar0521.
>  
> +config VIDEO_GC08A3
> +	tristate "GalaxyCore gc08a3 sensor support"
> +	depends on GPIOLIB && I2C && VIDEO_DEV
> +	select V4L2_FWNODE
> +	select MEDIA_CONTROLLER
> +	select VIDEO_V4L2_SUBDEV_API
> +	select REGMAP_I2C

These are already selected for all cameras (apart from REGMAP_I2C).
Regarding that, could you switch to V4L2 CCI (see
include/media/v4l2-cci.h)?

> +	help
> +	  This is a Video4Linux2 sensor driver for the GalaxyCore gc08a3
> +	  camera.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called gc08a3.
> +
>  config VIDEO_HI556
>  	tristate "Hynix Hi-556 sensor support"
>  	help
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index f5010f80a21f..ec40dbd75e7a 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_VIDEO_DW9719) += dw9719.o
>  obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
>  obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
>  obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8/
> +obj-$(CONFIG_VIDEO_GC08A3) += gc08a3.o
>  obj-$(CONFIG_VIDEO_HI556) += hi556.o
>  obj-$(CONFIG_VIDEO_HI846) += hi846.o
>  obj-$(CONFIG_VIDEO_HI847) += hi847.o
> diff --git a/drivers/media/i2c/gc08a3.c b/drivers/media/i2c/gc08a3.c
> new file mode 100644
> index 000000000000..5a9580f97807
> --- /dev/null
> +++ b/drivers/media/i2c/gc08a3.c
> @@ -0,0 +1,1888 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * gc08a3.c - gc08a3 sensor driver
> + *
> + * Copyright 2023 MediaTek
> + *
> + * Zhi Mao <zhi.mao at mediatek.com>
> + */
> +
> +#include <asm/unaligned.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regulator/consumer.h>
> +#include <media/media-entity.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-fwnode.h>
> +#include <media/v4l2-subdev.h>
> +
> +#define GC08A3_REG_VALUE_08BIT 1
> +#define GC08A3_REG_VALUE_16BIT 2
> +
> +#define GC08A3_REG_CHIP_ID 0x03f0
> +#define GC08A3_CHIP_ID 0x08a3
> +
> +#define GC08A3_NATIVE_WIDTH 3264
> +#define GC08A3_NATIVE_HEIGHT 2448
> +
> +#define GC08A3_REG_TEST_PATTERN_EN 0x008c
> +#define GC08A3_REG_TEST_PATTERN_IDX 0x008d
> +#define GC08A3_TEST_PATTERN_EN 0x01
> +
> +#define GC08A3_STRAEMING_REG 0x0100
> +
> +#define GC08A3_DEFAULT_CLK_FREQ 24000000
> +#define GC08A3_MBUS_CODE MEDIA_BUS_FMT_SRGGB10_1X10
> +#define GC08A3_DATA_LANES 4
> +
> +/* for 1920*1080 */
> +#define GC08A3_LINK_FREQ_207MHZ 207000000ULL
> +/* for 3264*2448 */
> +#define GC08A3_LINK_FREQ_336MHZ 336000000ULL
> +
> +#define GC08A3_RGB_DEPTH 10
> +
> +#define GC08A3_FRAME_LENGTH_REG 0x0340
> +#define GC08A3_VTS_30FPS 2548
> +#define GC08A3_VTS_30FPS_MIN 2548
> +#define GC08A3_VTS_60FPS 1276
> +#define GC08A3_VTS_60FPS_MIN 1276
> +#define GC08A3_VTS_MAX 0xfff0
> +
> +#define GC08A3_HTS_30FPS 3640
> +#define GC08A3_HTS_60FPS 3640
> +
> +#define GC08A3_EXP_REG 0x0202
> +#define GC08A3_EXP_MARGIN 16
> +#define GC08A3_EXP_MIN 4
> +#define GC08A3_EXP_STEP 1
> +
> +#define GC08A3_FLIP_REG 0x0101
> +#define GC08A3_FLIP_H_MASK 0x1
> +#define GC08A3_FLIP_V_MASK 0x2
> +
> +#define GC08A3_AGAIN_REG 0x0204
> +#define GC08A3_AGAIN_MIN 1024
> +#define GC08A3_AGAIN_MAX (1024 * 16)
> +#define GC08A3_AGAIN_STEP 1
> +
> +#define GC08A3_MIN_SLEEP_US  2000
> +#define GC08A3_MAX_SLEEP_US  3000
> +
> +static const char *const gc08a3_test_pattern_menu[] = {
> +	"No Pattern", "Solid Black", "Colour Bar", "Solid White",
> +	"Solid Red", "Solid Green", "Solid Blue", "Solid Yellow",
> +};
> +
> +enum {
> +	GC08A3_LINK_FREQ_336MHZ_INDEX,
> +	GC08A3_LINK_FREQ_207MHZ_INDEX,
> +};
> +
> +static const s64 link_freq_menu_items[] = {
> +	GC08A3_LINK_FREQ_336MHZ,
> +	GC08A3_LINK_FREQ_207MHZ,
> +};
> +
> +static const char *const gc08a3_supply_name[] = {
> +	"avdd",
> +	"dvdd",
> +	"dovdd",
> +};
> +
> +#define GC08A3_NUM_SUPPLIES ARRAY_SIZE(gc08a3_supply_name)

Please use ARRAY_SIZE(...) directly.

> +
> +struct gc08a3 {
> +	struct device *dev;
> +	struct v4l2_subdev sd;
> +	struct media_pad pad;
> +	struct v4l2_mbus_framefmt fmt;
> +	struct i2c_client *client;
> +
> +	struct v4l2_rect crop;
> +
> +	struct clk *xclk;
> +	struct regulator_bulk_data supplies[GC08A3_NUM_SUPPLIES];
> +	struct gpio_desc *enable_gpio;
> +
> +	struct v4l2_ctrl_handler ctrls;
> +	struct v4l2_ctrl *pixel_rate;
> +	struct v4l2_ctrl *link_freq;
> +	struct v4l2_ctrl *exposure;
> +	struct v4l2_ctrl *vblank;
> +	struct v4l2_ctrl *hblank;
> +
> +	/*
> +	 * Serialize control access, get/set format, get selection
> +	 * and start streaming.
> +	 */
> +	struct mutex mutex;
> +
> +	bool streaming;
> +
> +	/* Current mode */
> +	const struct gc08a3_mode *cur_mode;
> +};
> +
> +struct gc08a3_reg {
> +	u16 address;
> +	u8 val;
> +};
> +
> +struct gc08a3_reg_list {
> +	u32 num_of_regs;
> +	const struct gc08a3_reg *regs;
> +};
> +
> +struct gc08a3_link_freq_config {
> +	const struct gc08a3_reg_list reg_list;
> +};
> +
> +static const struct gc08a3_reg mode_3264x2448[] = {
> +	/* system */
> +	{ 0x031c, 0x60 },
> +	{ 0x0337, 0x04 },
> +	{ 0x0335, 0x51 },
> +	{ 0x0336, 0x70 },
> +	{ 0x0383, 0xbb },
> +	{ 0x031a, 0x00 },
> +	{ 0x0321, 0x10 },
> +	{ 0x0327, 0x03 },
> +	{ 0x0325, 0x40 },
> +	{ 0x0326, 0x23 },
> +	{ 0x0314, 0x11 },
> +	{ 0x0315, 0xd6 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0334, 0x40 },
> +	{ 0x0324, 0x42 },
> +	{ 0x031c, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x0344, 0x00 },
> +	{ 0x0345, 0x06 },
> +	{ 0x0346, 0x00 },
> +	{ 0x0347, 0x04 },
> +	{ 0x0348, 0x0c },
> +	{ 0x0349, 0xd0 },
> +	{ 0x034a, 0x09 },
> +	{ 0x034b, 0x9c },
> +	{ 0x0202, 0x09 },
> +	{ 0x0203, 0x04 },
> +	{ 0x0340, 0x09 },
> +	{ 0x0341, 0xf4 },
> +	{ 0x0342, 0x07 },
> +	{ 0x0343, 0x1c },
> +
> +	{ 0x0226, 0x00 },
> +	{ 0x0227, 0x28 },
> +	{ 0x0e38, 0x49 },
> +	{ 0x0210, 0x13 },
> +	{ 0x0218, 0x00 },
> +	{ 0x0241, 0x88 },
> +	{ 0x0392, 0x60 },
> +
> +	/* ISP */
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x00a2, 0x00 },
> +	{ 0x00a3, 0x00 },
> +	{ 0x00ab, 0x00 },
> +	{ 0x00ac, 0x00 },
> +	{ 0x05a0, 0x82 },
> +	{ 0x05ac, 0x00 },
> +	{ 0x05ad, 0x01 },
> +	{ 0x05ae, 0x00 },
> +	{ 0x0800, 0x0a },
> +	{ 0x0801, 0x14 },
> +	{ 0x0802, 0x28 },
> +	{ 0x0803, 0x34 },
> +	{ 0x0804, 0x0e },
> +	{ 0x0805, 0x33 },
> +	{ 0x0806, 0x03 },
> +	{ 0x0807, 0x8a },
> +	{ 0x0808, 0x50 },
> +	{ 0x0809, 0x00 },
> +	{ 0x080a, 0x34 },
> +	{ 0x080b, 0x03 },
> +	{ 0x080c, 0x26 },
> +	{ 0x080d, 0x03 },
> +	{ 0x080e, 0x18 },
> +	{ 0x080f, 0x03 },
> +	{ 0x0810, 0x10 },
> +	{ 0x0811, 0x03 },
> +	{ 0x0812, 0x00 },
> +	{ 0x0813, 0x00 },
> +	{ 0x0814, 0x01 },
> +	{ 0x0815, 0x00 },
> +	{ 0x0816, 0x01 },
> +	{ 0x0817, 0x00 },
> +	{ 0x0818, 0x00 },
> +	{ 0x0819, 0x0a },
> +	{ 0x081a, 0x01 },
> +	{ 0x081b, 0x6c },
> +	{ 0x081c, 0x00 },
> +	{ 0x081d, 0x0b },
> +	{ 0x081e, 0x02 },
> +	{ 0x081f, 0x00 },
> +	{ 0x0820, 0x00 },
> +	{ 0x0821, 0x0c },
> +	{ 0x0822, 0x02 },
> +	{ 0x0823, 0xd9 },
> +	{ 0x0824, 0x00 },
> +	{ 0x0825, 0x0d },
> +	{ 0x0826, 0x03 },
> +	{ 0x0827, 0xf0 },
> +	{ 0x0828, 0x00 },
> +	{ 0x0829, 0x0e },
> +	{ 0x082a, 0x05 },
> +	{ 0x082b, 0x94 },
> +	{ 0x082c, 0x09 },
> +	{ 0x082d, 0x6e },
> +	{ 0x082e, 0x07 },
> +	{ 0x082f, 0xe6 },
> +	{ 0x0830, 0x10 },
> +	{ 0x0831, 0x0e },
> +	{ 0x0832, 0x0b },
> +	{ 0x0833, 0x2c },
> +	{ 0x0834, 0x14 },
> +	{ 0x0835, 0xae },
> +	{ 0x0836, 0x0f },
> +	{ 0x0837, 0xc4 },
> +	{ 0x0838, 0x18 },
> +	{ 0x0839, 0x0e },
> +	{ 0x05ac, 0x01 },
> +	{ 0x059a, 0x00 },
> +	{ 0x059b, 0x00 },
> +	{ 0x059c, 0x01 },
> +	{ 0x0598, 0x00 },
> +	{ 0x0597, 0x14 },
> +	{ 0x05ab, 0x09 },
> +	{ 0x05a4, 0x02 },
> +	{ 0x05a3, 0x05 },
> +	{ 0x05a0, 0xc2 },
> +	{ 0x0207, 0xc4 },
> +
> +	/* GAIN */
> +	{ 0x0204, 0x04 },
> +	{ 0x0205, 0x00 },
> +	{ 0x0050, 0x5c },
> +	{ 0x0051, 0x44 },
> +
> +	/* out window */
> +	{ 0x009a, 0x66 },
> +	{ 0x0351, 0x00 },
> +	{ 0x0352, 0x06 },
> +	{ 0x0353, 0x00 },
> +	{ 0x0354, 0x08 },
> +	{ 0x034c, 0x0c },
> +	{ 0x034d, 0xc0 },
> +	{ 0x034e, 0x09 },
> +	{ 0x034f, 0x90 },
> +
> +	/* MIPI */
> +	{ 0x0114, 0x03 },
> +	{ 0x0180, 0x65 },
> +	{ 0x0181, 0xf0 },
> +	{ 0x0185, 0x01 },
> +	{ 0x0115, 0x30 },
> +	{ 0x011b, 0x12 },
> +	{ 0x011c, 0x12 },
> +	{ 0x0121, 0x06 },
> +	{ 0x0122, 0x06 },
> +	{ 0x0123, 0x15 },
> +	{ 0x0124, 0x01 },
> +	{ 0x0125, 0x0b },
> +	{ 0x0126, 0x08 },
> +	{ 0x0129, 0x06 },
> +	{ 0x012a, 0x08 },
> +	{ 0x012b, 0x08 },
> +
> +	{ 0x0a73, 0x60 },
> +	{ 0x0a70, 0x11 },
> +	{ 0x0313, 0x80 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0a70, 0x00 },
> +	{ 0x00a4, 0x80 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0a67, 0x00 },
> +	{ 0x0084, 0x10 },
> +	{ 0x0102, 0x09 },
> +};
> +
> +static const struct gc08a3_reg mode_1920x1080[] = {
> +	/* system */
> +	{ 0x031c, 0x60 },
> +	{ 0x0337, 0x04 },
> +	{ 0x0335, 0x51 },
> +	{ 0x0336, 0x45 },
> +	{ 0x0383, 0x8b },
> +	{ 0x031a, 0x00 },
> +	{ 0x0321, 0x10 },
> +	{ 0x0327, 0x03 },
> +	{ 0x0325, 0x40 },
> +	{ 0x0326, 0x23 },
> +	{ 0x0314, 0x11 },
> +	{ 0x0315, 0xd6 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0334, 0x40 },
> +	{ 0x0324, 0x42 },
> +	{ 0x031c, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x0344, 0x02 },
> +	{ 0x0345, 0xa6 },
> +	{ 0x0346, 0x02 },
> +	{ 0x0347, 0xb0 },
> +	{ 0x0348, 0x07 },
> +	{ 0x0349, 0x90 },
> +	{ 0x034a, 0x04 },
> +	{ 0x034b, 0x44 },
> +	{ 0x0202, 0x03 },
> +	{ 0x0203, 0x00 },
> +	{ 0x0340, 0x04 },
> +	{ 0x0341, 0xfc },
> +	{ 0x0342, 0x07 },
> +	{ 0x0343, 0x1c },
> +
> +	{ 0x0226, 0x00 },
> +	{ 0x0227, 0x88 },
> +	{ 0x0e38, 0x49 },
> +	{ 0x0210, 0x13 },
> +	{ 0x0218, 0x00 },
> +	{ 0x0241, 0x88 },
> +	{ 0x0392, 0x60 },
> +
> +	/* ISP */
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x00a2, 0xac },
> +	{ 0x00a3, 0x02 },
> +	{ 0x00ab, 0xa0 },
> +	{ 0x00ac, 0x02 },
> +	{ 0x05a0, 0x82 },
> +	{ 0x05ac, 0x00 },
> +	{ 0x05ad, 0x01 },
> +	{ 0x05ae, 0x00 },
> +	{ 0x0800, 0x0a },
> +	{ 0x0801, 0x14 },
> +	{ 0x0802, 0x28 },
> +	{ 0x0803, 0x34 },
> +	{ 0x0804, 0x0e },
> +	{ 0x0805, 0x33 },
> +	{ 0x0806, 0x03 },
> +	{ 0x0807, 0x8a },
> +	{ 0x0808, 0x50 },
> +	{ 0x0809, 0x00 },
> +	{ 0x080a, 0x34 },
> +	{ 0x080b, 0x03 },
> +	{ 0x080c, 0x26 },
> +	{ 0x080d, 0x03 },
> +	{ 0x080e, 0x18 },
> +	{ 0x080f, 0x03 },
> +	{ 0x0810, 0x10 },
> +	{ 0x0811, 0x03 },
> +	{ 0x0812, 0x00 },
> +	{ 0x0813, 0x00 },
> +	{ 0x0814, 0x01 },
> +	{ 0x0815, 0x00 },
> +	{ 0x0816, 0x01 },
> +	{ 0x0817, 0x00 },
> +	{ 0x0818, 0x00 },
> +	{ 0x0819, 0x0a },
> +	{ 0x081a, 0x01 },
> +	{ 0x081b, 0x6c },
> +	{ 0x081c, 0x00 },
> +	{ 0x081d, 0x0b },
> +	{ 0x081e, 0x02 },
> +	{ 0x081f, 0x00 },
> +	{ 0x0820, 0x00 },
> +	{ 0x0821, 0x0c },
> +	{ 0x0822, 0x02 },
> +	{ 0x0823, 0xd9 },
> +	{ 0x0824, 0x00 },
> +	{ 0x0825, 0x0d },
> +	{ 0x0826, 0x03 },
> +	{ 0x0827, 0xf0 },
> +	{ 0x0828, 0x00 },
> +	{ 0x0829, 0x0e },
> +	{ 0x082a, 0x05 },
> +	{ 0x082b, 0x94 },
> +	{ 0x082c, 0x09 },
> +	{ 0x082d, 0x6e },
> +	{ 0x082e, 0x07 },
> +	{ 0x082f, 0xe6 },
> +	{ 0x0830, 0x10 },
> +	{ 0x0831, 0x0e },
> +	{ 0x0832, 0x0b },
> +	{ 0x0833, 0x2c },
> +	{ 0x0834, 0x14 },
> +	{ 0x0835, 0xae },
> +	{ 0x0836, 0x0f },
> +	{ 0x0837, 0xc4 },
> +	{ 0x0838, 0x18 },
> +	{ 0x0839, 0x0e },
> +	{ 0x05ac, 0x01 },
> +	{ 0x059a, 0x00 },
> +	{ 0x059b, 0x00 },
> +	{ 0x059c, 0x01 },
> +	{ 0x0598, 0x00 },
> +	{ 0x0597, 0x14 },
> +	{ 0x05ab, 0x09 },
> +	{ 0x05a4, 0x02 },
> +	{ 0x05a3, 0x05 },
> +	{ 0x05a0, 0xc2 },
> +	{ 0x0207, 0xc4 },
> +
> +	/* GAIN */
> +	{ 0x0204, 0x04 },
> +	{ 0x0205, 0x00 },
> +	{ 0x0050, 0x38 },
> +	{ 0x0051, 0x20 },
> +
> +	/* out window */
> +	{ 0x009a, 0x66 },
> +	{ 0x0351, 0x00 },
> +	{ 0x0352, 0x06 },
> +	{ 0x0353, 0x00 },
> +	{ 0x0354, 0x08 },
> +	{ 0x034c, 0x07 },
> +	{ 0x034d, 0x80 },
> +	{ 0x034e, 0x04 },
> +	{ 0x034f, 0x38 },
> +
> +	/* MIPI */
> +	{ 0x0114, 0x03 },
> +	{ 0x0180, 0x65 },
> +	{ 0x0181, 0xf0 },
> +	{ 0x0185, 0x01 },
> +	{ 0x0115, 0x30 },
> +	{ 0x011b, 0x12 },
> +	{ 0x011c, 0x12 },
> +	{ 0x0121, 0x02 },
> +	{ 0x0122, 0x03 },
> +	{ 0x0123, 0x0c },
> +	{ 0x0124, 0x00 },
> +	{ 0x0125, 0x09 },
> +	{ 0x0126, 0x06 },
> +	{ 0x0129, 0x04 },
> +	{ 0x012a, 0x03 },
> +	{ 0x012b, 0x06 },
> +
> +	{ 0x0a73, 0x60 },
> +	{ 0x0a70, 0x11 },
> +	{ 0x0313, 0x80 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0aff, 0x00 },
> +	{ 0x0a70, 0x00 },
> +	{ 0x00a4, 0x80 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0a67, 0x00 },
> +	{ 0x0084, 0x10 },
> +	{ 0x0102, 0x09 },
> +};
> +
> +static const struct gc08a3_reg mode_table_common[] = {
> +	{ GC08A3_STRAEMING_REG, 0x00 },
> +	/* system */
> +	{ 0x031c, 0x60 },
> +	{ 0x0337, 0x04 },
> +	{ 0x0335, 0x51 },
> +	{ 0x0336, 0x70 },
> +	{ 0x0383, 0xbb },
> +	{ 0x031a, 0x00 },
> +	{ 0x0321, 0x10 },
> +	{ 0x0327, 0x03 },
> +	{ 0x0325, 0x40 },
> +	{ 0x0326, 0x23 },
> +	{ 0x0314, 0x11 },
> +	{ 0x0315, 0xd6 },
> +	{ 0x0316, 0x01 },
> +	{ 0x0334, 0x40 },
> +	{ 0x0324, 0x42 },
> +	{ 0x031c, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x039a, 0x13 },
> +	{ 0x0084, 0x30 },
> +	{ 0x02b3, 0x08 },
> +	{ 0x0057, 0x0c },
> +	{ 0x05c3, 0x50 },
> +	{ 0x0311, 0x90 },
> +	{ 0x05a0, 0x02 },
> +	{ 0x0074, 0x0a },
> +	{ 0x0059, 0x11 },
> +	{ 0x0070, 0x05 },
> +	{ 0x0101, 0x00 },
> +
> +	/* analog */
> +	{ 0x0344, 0x00 },
> +	{ 0x0345, 0x06 },
> +	{ 0x0346, 0x00 },
> +	{ 0x0347, 0x04 },
> +	{ 0x0348, 0x0c },
> +	{ 0x0349, 0xd0 },
> +	{ 0x034a, 0x09 },
> +	{ 0x034b, 0x9c },
> +	{ 0x0202, 0x09 },
> +	{ 0x0203, 0x04 },
> +
> +	{ 0x0219, 0x05 },
> +	{ 0x0226, 0x00 },
> +	{ 0x0227, 0x28 },
> +	{ 0x0e0a, 0x00 },
> +	{ 0x0e0b, 0x00 },
> +	{ 0x0e24, 0x04 },
> +	{ 0x0e25, 0x04 },
> +	{ 0x0e26, 0x00 },
> +	{ 0x0e27, 0x10 },
> +	{ 0x0e01, 0x74 },
> +	{ 0x0e03, 0x47 },
> +	{ 0x0e04, 0x33 },
> +	{ 0x0e05, 0x44 },
> +	{ 0x0e06, 0x44 },
> +	{ 0x0e0c, 0x1e },
> +	{ 0x0e17, 0x3a },
> +	{ 0x0e18, 0x3c },
> +	{ 0x0e19, 0x40 },
> +	{ 0x0e1a, 0x42 },
> +	{ 0x0e28, 0x21 },
> +	{ 0x0e2b, 0x68 },
> +	{ 0x0e2c, 0x0d },
> +	{ 0x0e2d, 0x08 },
> +	{ 0x0e34, 0xf4 },
> +	{ 0x0e35, 0x44 },
> +	{ 0x0e36, 0x07 },
> +	{ 0x0e38, 0x49 },
> +	{ 0x0210, 0x13 },
> +	{ 0x0218, 0x00 },
> +	{ 0x0241, 0x88 },
> +	{ 0x0e32, 0x00 },
> +	{ 0x0e33, 0x18 },
> +	{ 0x0e42, 0x03 },
> +	{ 0x0e43, 0x80 },
> +	{ 0x0e44, 0x04 },
> +	{ 0x0e45, 0x00 },
> +	{ 0x0e4f, 0x04 },
> +	{ 0x057a, 0x20 },
> +	{ 0x0381, 0x7c },
> +	{ 0x0382, 0x9b },
> +	{ 0x0384, 0xfb },
> +	{ 0x0389, 0x38 },
> +	{ 0x038a, 0x03 },
> +	{ 0x0390, 0x6a },
> +	{ 0x0391, 0x0b },
> +	{ 0x0392, 0x60 },
> +	{ 0x0393, 0xc1 },
> +	{ 0x0396, 0xff },
> +	{ 0x0398, 0x62 },
> +
> +	/* cisctl reset */
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x80 },
> +	{ 0x03fe, 0x10 },
> +	{ 0x03fe, 0x00 },
> +	{ 0x031c, 0x9f },
> +	{ 0x0360, 0x01 },
> +	{ 0x0360, 0x00 },
> +	{ 0x0316, 0x09 },
> +	{ 0x0a67, 0x80 },
> +	{ 0x0313, 0x00 },
> +	{ 0x0a53, 0x0e },
> +	{ 0x0a65, 0x17 },
> +	{ 0x0a68, 0xa1 },
> +	{ 0x0a58, 0x00 },
> +	{ 0x0ace, 0x0c },
> +	{ 0x00a4, 0x00 },
> +	{ 0x00a5, 0x01 },
> +	{ 0x00a7, 0x09 },
> +	{ 0x00a8, 0x9c },
> +	{ 0x00a9, 0x0c },
> +	{ 0x00aa, 0xd0 },
> +	{ 0x0a8a, 0x00 },
> +	{ 0x0a8b, 0xe0 },
> +	{ 0x0a8c, 0x13 },
> +	{ 0x0a8d, 0xe8 },
> +	{ 0x0a90, 0x0a },
> +	{ 0x0a91, 0x10 },
> +	{ 0x0a92, 0xf8 },
> +	{ 0x0a71, 0xf2 },
> +	{ 0x0a72, 0x12 },
> +	{ 0x0a73, 0x64 },
> +	{ 0x0a75, 0x41 },
> +	{ 0x0a70, 0x07 },
> +	{ 0x0313, 0x80 },
> +
> +	/* ISP */
> +	{ 0x00a0, 0x01 },
> +	{ 0x0080, 0xd2 },
> +	{ 0x0081, 0x3f },
> +	{ 0x0087, 0x51 },
> +	{ 0x0089, 0x03 },
> +	{ 0x009b, 0x40 },
> +	{ 0x05a0, 0x82 },
> +	{ 0x05ac, 0x00 },
> +	{ 0x05ad, 0x01 },
> +	{ 0x05ae, 0x00 },
> +	{ 0x0800, 0x0a },
> +	{ 0x0801, 0x14 },
> +	{ 0x0802, 0x28 },
> +	{ 0x0803, 0x34 },
> +	{ 0x0804, 0x0e },
> +	{ 0x0805, 0x33 },
> +	{ 0x0806, 0x03 },
> +	{ 0x0807, 0x8a },
> +	{ 0x0808, 0x50 },
> +	{ 0x0809, 0x00 },
> +	{ 0x080a, 0x34 },
> +	{ 0x080b, 0x03 },
> +	{ 0x080c, 0x26 },
> +	{ 0x080d, 0x03 },
> +	{ 0x080e, 0x18 },
> +	{ 0x080f, 0x03 },
> +	{ 0x0810, 0x10 },
> +	{ 0x0811, 0x03 },
> +	{ 0x0812, 0x00 },
> +	{ 0x0813, 0x00 },
> +	{ 0x0814, 0x01 },
> +	{ 0x0815, 0x00 },
> +	{ 0x0816, 0x01 },
> +	{ 0x0817, 0x00 },
> +	{ 0x0818, 0x00 },
> +	{ 0x0819, 0x0a },
> +	{ 0x081a, 0x01 },
> +	{ 0x081b, 0x6c },
> +	{ 0x081c, 0x00 },
> +	{ 0x081d, 0x0b },
> +	{ 0x081e, 0x02 },
> +	{ 0x081f, 0x00 },
> +	{ 0x0820, 0x00 },
> +	{ 0x0821, 0x0c },
> +	{ 0x0822, 0x02 },
> +	{ 0x0823, 0xd9 },
> +	{ 0x0824, 0x00 },
> +	{ 0x0825, 0x0d },
> +	{ 0x0826, 0x03 },
> +	{ 0x0827, 0xf0 },
> +	{ 0x0828, 0x00 },
> +	{ 0x0829, 0x0e },
> +	{ 0x082a, 0x05 },
> +	{ 0x082b, 0x94 },
> +	{ 0x082c, 0x09 },
> +	{ 0x082d, 0x6e },
> +	{ 0x082e, 0x07 },
> +	{ 0x082f, 0xe6 },
> +	{ 0x0830, 0x10 },
> +	{ 0x0831, 0x0e },
> +	{ 0x0832, 0x0b },
> +	{ 0x0833, 0x2c },
> +	{ 0x0834, 0x14 },
> +	{ 0x0835, 0xae },
> +	{ 0x0836, 0x0f },
> +	{ 0x0837, 0xc4 },
> +	{ 0x0838, 0x18 },
> +	{ 0x0839, 0x0e },
> +	{ 0x05ac, 0x01 },
> +	{ 0x059a, 0x00 },
> +	{ 0x059b, 0x00 },
> +	{ 0x059c, 0x01 },
> +	{ 0x0598, 0x00 },
> +	{ 0x0597, 0x14 },
> +	{ 0x05ab, 0x09 },
> +	{ 0x05a4, 0x02 },
> +	{ 0x05a3, 0x05 },
> +	{ 0x05a0, 0xc2 },
> +	{ 0x0207, 0xc4 },
> +
> +	/* GAIN */
> +	{ 0x0208, 0x01 },
> +	{ 0x0209, 0x72 },
> +	{ 0x0204, 0x04 },
> +	{ 0x0205, 0x00 },
> +
> +	{ 0x0040, 0x22 },
> +	{ 0x0041, 0x20 },
> +	{ 0x0043, 0x10 },
> +	{ 0x0044, 0x00 },
> +	{ 0x0046, 0x08 },
> +	{ 0x0047, 0xf0 },
> +	{ 0x0048, 0x0f },
> +	{ 0x004b, 0x0f },
> +	{ 0x004c, 0x00 },
> +	{ 0x0050, 0x5c },
> +	{ 0x0051, 0x44 },
> +	{ 0x005b, 0x03 },
> +	{ 0x00c0, 0x00 },
> +	{ 0x00c1, 0x80 },
> +	{ 0x00c2, 0x31 },
> +	{ 0x00c3, 0x00 },
> +	{ 0x0460, 0x04 },
> +	{ 0x0462, 0x08 },
> +	{ 0x0464, 0x0e },
> +	{ 0x0466, 0x0a },
> +	{ 0x0468, 0x12 },
> +	{ 0x046a, 0x12 },
> +	{ 0x046c, 0x10 },
> +	{ 0x046e, 0x0c },
> +	{ 0x0461, 0x03 },
> +	{ 0x0463, 0x03 },
> +	{ 0x0465, 0x03 },
> +	{ 0x0467, 0x03 },
> +	{ 0x0469, 0x04 },
> +	{ 0x046b, 0x04 },
> +	{ 0x046d, 0x04 },
> +	{ 0x046f, 0x04 },
> +	{ 0x0470, 0x04 },
> +	{ 0x0472, 0x10 },
> +	{ 0x0474, 0x26 },
> +	{ 0x0476, 0x38 },
> +	{ 0x0478, 0x20 },
> +	{ 0x047a, 0x30 },
> +	{ 0x047c, 0x38 },
> +	{ 0x047e, 0x60 },
> +	{ 0x0471, 0x05 },
> +	{ 0x0473, 0x05 },
> +	{ 0x0475, 0x05 },
> +	{ 0x0477, 0x05 },
> +	{ 0x0479, 0x04 },
> +	{ 0x047b, 0x04 },
> +	{ 0x047d, 0x04 },
> +	{ 0x047f, 0x04 },
> +};
> +
> +static const struct gc08a3_link_freq_config link_freq_configs[] = {
> +	[GC08A3_LINK_FREQ_336MHZ_INDEX] = {
> +		.reg_list = {
> +			.num_of_regs = ARRAY_SIZE(mode_table_common),
> +			.regs = mode_table_common,
> +		}
> +	},
> +	[GC08A3_LINK_FREQ_207MHZ_INDEX] = {
> +		.reg_list = {
> +			.num_of_regs = ARRAY_SIZE(mode_table_common),
> +			.regs = mode_table_common,
> +		}
> +	},
> +
> +};
> +
> +struct gc08a3_mode {
> +	u32 width;
> +	u32 height;
> +	const struct gc08a3_reg_list reg_list;
> +
> +	u32 hts; /* Horizontal timining size */
> +	u32 vts_def; /* Default vertical timining size */
> +	u32 vts_min; /* Min vertical timining size */
> +	u32 link_freq_index; /* Link frequency needed for this resolution */
> +	u32 max_framerate;
> +
> +};
> +
> +/*
> + * Declare modes in order, from biggest
> + * to smallest height.
> + */
> +static const struct gc08a3_mode gc08a3_modes[] = {
> +	{
> +		.width = GC08A3_NATIVE_WIDTH,
> +		.height = GC08A3_NATIVE_HEIGHT,
> +		.reg_list = {
> +			.num_of_regs = ARRAY_SIZE(mode_3264x2448),
> +			.regs = mode_3264x2448,
> +		},
> +		.link_freq_index = GC08A3_LINK_FREQ_336MHZ_INDEX,
> +
> +		.hts = GC08A3_HTS_30FPS,
> +		.vts_def = GC08A3_VTS_30FPS,
> +		.vts_min = GC08A3_VTS_30FPS_MIN,
> +		.max_framerate = 300,
> +	},
> +	{
> +		.width = 1920,
> +		.height = 1080,
> +		.reg_list = {
> +			.num_of_regs = ARRAY_SIZE(mode_1920x1080),
> +			.regs = mode_1920x1080,
> +		},
> +		.link_freq_index = GC08A3_LINK_FREQ_207MHZ_INDEX,
> +
> +		.hts = GC08A3_HTS_60FPS,
> +		.vts_def = GC08A3_VTS_60FPS,
> +		.vts_min = GC08A3_VTS_60FPS_MIN,
> +		.max_framerate = 600,
> +	},
> +};
> +
> +static u64 to_pixel_rate(u32 f_index)
> +{
> +	u64 pixel_rate = link_freq_menu_items[f_index] * 2 * GC08A3_DATA_LANES;
> +
> +	do_div(pixel_rate, GC08A3_RGB_DEPTH);
> +
> +	return pixel_rate;
> +}
> +
> +static int gc08a3_read_reg(struct gc08a3 *gc08a3, u16 reg, u16 len, u32 *val)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	struct i2c_msg msgs[2];
> +	u8 addr_buf[2];
> +	u8 data_buf[4] = { 0 };
> +	int ret;
> +
> +	if (len > 4)
> +		return -EINVAL;
> +
> +	put_unaligned_be16(reg, addr_buf);
> +	msgs[0].addr = client->addr;
> +	msgs[0].flags = 0;
> +	msgs[0].len = sizeof(addr_buf);
> +	msgs[0].buf = addr_buf;
> +	msgs[1].addr = client->addr;
> +	msgs[1].flags = I2C_M_RD;
> +	msgs[1].len = len;
> +	msgs[1].buf = &data_buf[4 - len];
> +
> +	ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
> +	if (ret != ARRAY_SIZE(msgs))
> +		return -EIO;
> +
> +	*val = get_unaligned_be32(data_buf);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_write_reg(struct gc08a3 *gc08a3, u16 reg, u16 len, u32 val)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	u8 buf[6];
> +
> +	if (len > 4)
> +		return -EINVAL;
> +
> +	put_unaligned_be16(reg, buf);
> +	put_unaligned_be32(val << 8 * (4 - len), buf + 2);
> +	if (i2c_master_send(client, buf, len + 2) != len + 2)
> +		return -EIO;
> +
> +	return 0;
> +}
> +
> +static int gc08a3_write_reg_list(struct gc08a3 *gc08a3,
> +				 const struct gc08a3_reg_list *r_list)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	unsigned int i;
> +	int ret;
> +
> +	for (i = 0; i < r_list->num_of_regs; i++) {
> +		ret = gc08a3_write_reg(gc08a3, r_list->regs[i].address,
> +				       GC08A3_REG_VALUE_08BIT,
> +				       r_list->regs[i].val);
> +		if (ret) {
> +			dev_err_ratelimited(&client->dev,
> +					    "failed to write reg 0x%4.4x. error = %d",
> +					    r_list->regs[i].address, ret);
> +			return ret;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static int gc08a3_identify_module(struct gc08a3 *gc08a3)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	u32 val = 0;
> +
> +	gc08a3_read_reg(gc08a3, GC08A3_REG_CHIP_ID, GC08A3_REG_VALUE_16BIT,
> +			&val);
> +
> +	if (val != GC08A3_CHIP_ID) {
> +		dev_err(&client->dev, "chip id mismatch: 0x%x!=0x%x",
> +			GC08A3_CHIP_ID, val);
> +		return -ENXIO;
> +	}
> +
> +	return 0;
> +}
> +
> +static inline struct gc08a3 *to_gc08a3(struct v4l2_subdev *sd)
> +{
> +	return container_of(sd, struct gc08a3, sd);
> +}
> +
> +static int gc08a3_power_on(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +	int ret;
> +
> +	gpiod_set_value_cansleep(gc08a3->enable_gpio, 0);
> +	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
> +
> +	ret = regulator_bulk_enable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
> +	if (ret < 0) {
> +		dev_err(gc08a3->dev, "failed to enable regulators: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = clk_prepare_enable(gc08a3->xclk);
> +	if (ret < 0) {
> +		regulator_bulk_disable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
> +		dev_err(gc08a3->dev, "clk prepare enable failed\n");
> +		return ret;
> +	}
> +
> +	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
> +
> +	gpiod_set_value_cansleep(gc08a3->enable_gpio, 1);
> +	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_power_off(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	gpiod_set_value_cansleep(gc08a3->enable_gpio, 0);
> +
> +	clk_disable_unprepare(gc08a3->xclk);
> +
> +	regulator_bulk_disable(GC08A3_NUM_SUPPLIES, gc08a3->supplies);
> +	usleep_range(GC08A3_MIN_SLEEP_US, GC08A3_MAX_SLEEP_US);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_enum_mbus_code(struct v4l2_subdev *sd,
> +				 struct v4l2_subdev_state *sd_state,
> +				 struct v4l2_subdev_mbus_code_enum *code)
> +{
> +	if (code->index > 0)
> +		return -EINVAL;
> +
> +	code->code = GC08A3_MBUS_CODE;
> +
> +	return 0;
> +}
> +
> +static int gc08a3_enum_frame_size(struct v4l2_subdev *subdev,
> +				  struct v4l2_subdev_state *sd_state,
> +				  struct v4l2_subdev_frame_size_enum *fse)
> +{
> +	if (fse->code != GC08A3_MBUS_CODE)
> +		return -EINVAL;
> +
> +	if (fse->index >= ARRAY_SIZE(gc08a3_modes))
> +		return -EINVAL;
> +
> +	fse->min_width = gc08a3_modes[fse->index].width;
> +	fse->max_width = gc08a3_modes[fse->index].width;
> +	fse->min_height = gc08a3_modes[fse->index].height;
> +	fse->max_height = gc08a3_modes[fse->index].height;
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +static int gc08a3_g_register(struct v4l2_subdev *subdev,
> +			     struct v4l2_dbg_register *reg)
> +{
> +	int ret;
> +	u32 val;
> +	struct gc08a3 *gc08a3 = container_of(subdev, struct gc08a3, sd);
> +
> +	ret = gc08a3_read_reg(gc08a3, reg->reg, GC08A3_REG_VALUE_08BIT, &val);
> +	if (ret < 0)
> +		return ret;
> +
> +	reg->val = val;
> +	reg->size = 1;
> +
> +	return 0;
> +}
> +
> +static int gc08a3_s_register(struct v4l2_subdev *subdev,
> +			     const struct v4l2_dbg_register *reg)
> +{
> +	struct gc08a3 *gc08a3 = container_of(subdev, struct gc08a3, sd);
> +
> +	return gc08a3_write_reg(gc08a3, reg->reg, GC08A3_REG_VALUE_08BIT,
> +				reg->val & 0xff);
> +}
> +
> +#endif
> +
> +static const struct v4l2_subdev_core_ops gc08a3_core_ops = {
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +	.g_register = gc08a3_g_register,
> +	.s_register = gc08a3_s_register,
> +#endif
> +};
> +
> +static struct v4l2_mbus_framefmt *
> +__gc08a3_get_pad_format(struct gc08a3 *gc08a3,
> +			struct v4l2_subdev_state *sd_state, unsigned int pad,
> +			enum v4l2_subdev_format_whence which)
> +{
> +	switch (which) {
> +	case V4L2_SUBDEV_FORMAT_TRY:
> +		return v4l2_subdev_state_get_format(sd_state, pad);

Please switch to sub-device state. An example of this can be found in
commit 289c25923ecdde90050a0cb3904f9295ca68b425 .

> +	case V4L2_SUBDEV_FORMAT_ACTIVE:
> +		return &gc08a3->fmt;
> +	default:
> +		return NULL;
> +	}
> +}
> +
> +static int gc08a3_get_format(struct v4l2_subdev *sd,
> +			     struct v4l2_subdev_state *sd_state,
> +			     struct v4l2_subdev_format *format)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	mutex_lock(&gc08a3->mutex);
> +	format->format = *__gc08a3_get_pad_format(gc08a3, sd_state, format->pad,
> +						  format->which);
> +	mutex_unlock(&gc08a3->mutex);
> +
> +	return 0;
> +}
> +
> +static struct v4l2_rect *
> +__gc08a3_get_pad_crop(struct gc08a3 *gc08a3, struct v4l2_subdev_state *sd_state,
> +		      unsigned int pad, enum v4l2_subdev_format_whence which)
> +{
> +	switch (which) {
> +	case V4L2_SUBDEV_FORMAT_TRY:
> +		return v4l2_subdev_state_get_crop(sd_state, pad);
> +	case V4L2_SUBDEV_FORMAT_ACTIVE:
> +		return &gc08a3->crop;
> +	default:
> +		return NULL;
> +	}
> +}
> +
> +static int gc08a3_update_cur_mode_controls(struct gc08a3 *gc08a3)
> +{
> +	s64 exposure_max, h_blank;
> +	int ret = 0;
> +
> +	ret = __v4l2_ctrl_modify_range(gc08a3->vblank,
> +				       gc08a3->cur_mode->vts_min - gc08a3->cur_mode->height,
> +				       GC08A3_VTS_MAX - gc08a3->cur_mode->height, 1,
> +				       gc08a3->cur_mode->vts_def - gc08a3->cur_mode->height);
> +	if (ret)
> +		dev_err(gc08a3->dev, "VB ctrl range update failed\n");
> +
> +	h_blank = gc08a3->cur_mode->hts - gc08a3->cur_mode->width;
> +	ret = __v4l2_ctrl_modify_range(gc08a3->hblank, h_blank, h_blank, 1,
> +				       h_blank);
> +	if (ret)
> +		dev_err(gc08a3->dev, "HB ctrl range update failed\n");
> +
> +	exposure_max = gc08a3->cur_mode->vts_def - GC08A3_EXP_MARGIN;
> +	ret = __v4l2_ctrl_modify_range(gc08a3->exposure, GC08A3_EXP_MIN,
> +				       exposure_max, GC08A3_EXP_STEP,
> +				       exposure_max);
> +	if (ret)
> +		dev_err(gc08a3->dev, "exposure ctrl range update failed\n");
> +
> +	return ret;
> +}
> +
> +static int gc08a3_set_format(struct v4l2_subdev *sd,
> +			     struct v4l2_subdev_state *sd_state,
> +			     struct v4l2_subdev_format *format)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +	struct v4l2_mbus_framefmt *fmt;
> +	struct v4l2_rect *crop;
> +	const struct gc08a3_mode *mode;
> +
> +	mutex_lock(&gc08a3->mutex);
> +
> +	crop = __gc08a3_get_pad_crop(gc08a3, sd_state, format->pad,
> +				     format->which);
> +
> +	mode = v4l2_find_nearest_size(gc08a3_modes, ARRAY_SIZE(gc08a3_modes),
> +				      width, height, format->format.width,
> +				      format->format.height);
> +
> +	crop->width = mode->width;
> +	crop->height = mode->height;
> +
> +	fmt = __gc08a3_get_pad_format(gc08a3, sd_state, format->pad,
> +				      format->which);
> +	fmt->width = crop->width;
> +	fmt->height = crop->height;
> +	fmt->code = GC08A3_MBUS_CODE;
> +	fmt->field = V4L2_FIELD_NONE;
> +	fmt->colorspace = V4L2_COLORSPACE_SRGB;
> +	fmt->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(fmt->colorspace);
> +	fmt->quantization =
> +		V4L2_MAP_QUANTIZATION_DEFAULT(true,
> +					      fmt->colorspace,
> +					      fmt->ycbcr_enc);
> +	fmt->xfer_func = V4L2_MAP_XFER_FUNC_DEFAULT(fmt->colorspace);
> +
> +	format->format = *fmt;
> +
> +	gc08a3->cur_mode = mode;
> +	gc08a3_update_cur_mode_controls(gc08a3);
> +
> +	mutex_unlock(&gc08a3->mutex);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_get_selection(struct v4l2_subdev *sd,
> +				struct v4l2_subdev_state *sd_state,
> +				struct v4l2_subdev_selection *sel)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	switch (sel->target) {
> +	case V4L2_SEL_TGT_CROP:
> +		mutex_lock(&gc08a3->mutex);
> +		sel->r = *__gc08a3_get_pad_crop(gc08a3, sd_state, sel->pad, sel->which);
> +		mutex_unlock(&gc08a3->mutex);
> +		break;
> +	case V4L2_SEL_TGT_CROP_BOUNDS:
> +		sel->r.top = 0;
> +		sel->r.left = 0;
> +		sel->r.width = GC08A3_NATIVE_WIDTH;
> +		sel->r.height = GC08A3_NATIVE_HEIGHT;
> +		break;
> +	case V4L2_SEL_TGT_CROP_DEFAULT:
> +		if (gc08a3->cur_mode->width == GC08A3_NATIVE_WIDTH) {
> +			sel->r.top = 0;
> +			sel->r.left = 0;
> +			sel->r.width = GC08A3_NATIVE_WIDTH;
> +			sel->r.height = GC08A3_NATIVE_HEIGHT;
> +		} else {
> +			sel->r.top = 0;
> +			sel->r.left = 0;
> +			sel->r.width = 1920;
> +			sel->r.height = 1080;
> +		}
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int gc08a3_entity_init_cfg(struct v4l2_subdev *subdev,
> +				  struct v4l2_subdev_state *sd_state)
> +{
> +	struct v4l2_subdev_format fmt = {};
> +
> +	fmt.which = sd_state ? V4L2_SUBDEV_FORMAT_TRY :
> +			       V4L2_SUBDEV_FORMAT_ACTIVE;
> +	fmt.format.width = gc08a3_modes[0].width;
> +	fmt.format.height = gc08a3_modes[0].height;
> +
> +	gc08a3_set_format(subdev, sd_state, &fmt);
> +
> +	return 0;
> +}
> +
> +static int gc08a3_set_ctrl_hflip(struct gc08a3 *gc08a3, u32 ctrl_val)
> +{
> +	int ret;
> +	u32 val;
> +
> +	ret = gc08a3_read_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
> +			      &val);
> +	if (ret) {
> +		dev_err(gc08a3->dev, "read hflip register failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	val = ctrl_val ? (val | GC08A3_FLIP_H_MASK) :
> +			   (val & ~GC08A3_FLIP_H_MASK);
> +	ret = gc08a3_write_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
> +			       val);
> +	if (ret < 0)
> +		dev_err(gc08a3->dev, "Error %d\n", ret);
> +
> +	return ret;
> +}
> +
> +static int gc08a3_set_ctrl_vflip(struct gc08a3 *gc08a3, u32 ctrl_val)
> +{
> +	int ret;
> +	u32 val;
> +
> +	ret = gc08a3_read_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
> +			      &val);
> +	if (ret) {
> +		dev_err(gc08a3->dev, "read vflip register failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	val = ctrl_val ? (val | GC08A3_FLIP_V_MASK) :
> +			   (val & ~GC08A3_FLIP_V_MASK);
> +	ret = gc08a3_write_reg(gc08a3, GC08A3_FLIP_REG, GC08A3_REG_VALUE_08BIT,
> +			       val);
> +	if (ret < 0)
> +		dev_err(gc08a3->dev, "Error %d\n", ret);
> +
> +	return ret;
> +}
> +
> +static int gc08a3_test_pattern(struct gc08a3 *gc08a3, u32 pattern_menu)
> +{
> +	int ret = 0;
> +	u32 pattern = 0;
> +
> +	if (pattern_menu) {
> +		switch (pattern_menu) {
> +		case 1:
> +			pattern = 0x00;
> +			break;
> +		case 2:
> +			pattern = 0x10;
> +			break;
> +		case 3:
> +		case 4:
> +		case 5:
> +		case 6:
> +		case 7:
> +			pattern = pattern_menu + 1;
> +			break;
> +		}
> +
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_REG_TEST_PATTERN_EN,
> +				       GC08A3_REG_VALUE_08BIT,
> +				       GC08A3_TEST_PATTERN_EN);
> +		if (ret) {
> +			dev_err(gc08a3->dev, "test pattern enable failed: %d\n", ret);
> +			return ret;
> +		}
> +
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_REG_TEST_PATTERN_IDX,
> +				       GC08A3_REG_VALUE_08BIT, pattern);
> +		if (ret < 0)
> +			dev_err(gc08a3->dev, "Error %d\n", ret);
> +
> +	} else {
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_REG_TEST_PATTERN_EN,
> +				       GC08A3_REG_VALUE_08BIT, 0x00);
> +		if (ret < 0)
> +			dev_err(gc08a3->dev, "test pattern disable failed: %d\n", ret);
> +	}
> +
> +	return ret;
> +}
> +
> +static int gc08a3_set_ctrl(struct v4l2_ctrl *ctrl)
> +{
> +	struct gc08a3 *gc08a3 =
> +		container_of(ctrl->handler, struct gc08a3, ctrls);
> +	int ret = 0;
> +	s64 exposure_max;
> +
> +	if (ctrl->id == V4L2_CID_VBLANK) {
> +		/* Update max exposure while meeting expected vblanking */
> +		exposure_max = gc08a3->cur_mode->height + ctrl->val -
> +			       GC08A3_EXP_MARGIN;
> +		__v4l2_ctrl_modify_range(gc08a3->exposure,
> +					 gc08a3->exposure->minimum,
> +					 exposure_max, gc08a3->exposure->step,
> +					 exposure_max);
> +	}
> +
> +	/*
> +	 * Applying V4L2 control value only happens
> +	 * when power is up for streaming
> +	 */
> +	if (!pm_runtime_get_if_in_use(gc08a3->dev))
> +		return 0;
> +
> +	switch (ctrl->id) {
> +	case V4L2_CID_EXPOSURE:
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_EXP_REG,
> +				       GC08A3_REG_VALUE_16BIT, ctrl->val);
> +		break;
> +
> +	case V4L2_CID_ANALOGUE_GAIN:
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_AGAIN_REG,
> +				       GC08A3_REG_VALUE_16BIT, ctrl->val);
> +		break;
> +
> +	case V4L2_CID_VBLANK:
> +		ret = gc08a3_write_reg(gc08a3, GC08A3_FRAME_LENGTH_REG,
> +				       GC08A3_REG_VALUE_16BIT,
> +				       gc08a3->cur_mode->height + ctrl->val);
> +		break;
> +
> +	case V4L2_CID_HFLIP:
> +		ret = gc08a3_set_ctrl_hflip(gc08a3, ctrl->val);
> +		break;
> +
> +	case V4L2_CID_VFLIP:
> +		ret = gc08a3_set_ctrl_vflip(gc08a3, ctrl->val);
> +		break;
> +
> +	case V4L2_CID_TEST_PATTERN:
> +		ret = gc08a3_test_pattern(gc08a3, ctrl->val);
> +		break;
> +
> +	default:
> +		break;
> +	}
> +
> +	pm_runtime_put(gc08a3->dev);
> +
> +	return ret;
> +}
> +
> +static int gc08a3_try_ctrl(struct v4l2_ctrl *ctrl)

No need to implement try_ctrl callback.

> +{
> +	int ret = 0;
> +
> +	switch (ctrl->id) {
> +	case V4L2_CID_EXPOSURE:
> +	case V4L2_CID_ANALOGUE_GAIN:
> +	case V4L2_CID_VBLANK:
> +	case V4L2_CID_HFLIP:
> +	case V4L2_CID_VFLIP:
> +	case V4L2_CID_TEST_PATTERN:
> +	default:
> +		return 0;
> +	}
> +
> +	return ret;
> +}
> +
> +static const struct v4l2_ctrl_ops gc08a3_ctrl_ops = {
> +	.try_ctrl = gc08a3_try_ctrl,
> +	.s_ctrl = gc08a3_set_ctrl,
> +};
> +
> +static int gc08a3_start_streaming(struct gc08a3 *gc08a3)
> +{
> +	const struct gc08a3_mode *mode;
> +	const struct gc08a3_reg_list *reg_list;
> +	int link_freq_index;
> +	int ret;
> +
> +	mutex_lock(&gc08a3->mutex);
> +
> +	link_freq_index = gc08a3->cur_mode->link_freq_index;
> +
> +	reg_list = &link_freq_configs[link_freq_index].reg_list;
> +	ret = gc08a3_write_reg_list(gc08a3, reg_list);
> +	if (ret) {
> +		dev_err(gc08a3->dev, "could not sent common table %d\n", ret);
> +		goto error;
> +	}
> +
> +	mode = gc08a3->cur_mode;
> +	reg_list = &mode->reg_list;
> +
> +	ret = gc08a3_write_reg_list(gc08a3, reg_list);
> +	if (ret < 0) {
> +		dev_err(gc08a3->dev, "could not sent mode table %d\n", ret);
> +		goto error;
> +	}
> +	ret = __v4l2_ctrl_handler_setup(&gc08a3->ctrls);
> +	if (ret < 0) {
> +		dev_err(gc08a3->dev, "could not sync v4l2 controls\n");
> +		goto error;
> +	}
> +
> +	ret = gc08a3_write_reg(gc08a3, GC08A3_STRAEMING_REG,
> +			       GC08A3_REG_VALUE_08BIT, 1);
> +	if (ret < 0) {
> +		dev_err(gc08a3->dev, "write STRAEMING_REG failed: %d\n", ret);
> +		goto error;
> +	}
> +
> +	mutex_unlock(&gc08a3->mutex);
> +
> +	return 0;
> +
> +error:
> +	mutex_unlock(&gc08a3->mutex);
> +	return ret;
> +}
> +
> +static int gc08a3_stop_streaming(struct gc08a3 *gc08a3)
> +{
> +	int ret;
> +
> +	ret = gc08a3_write_reg(gc08a3, GC08A3_STRAEMING_REG,
> +			       GC08A3_REG_VALUE_08BIT, 0);
> +	if (ret < 0)
> +		dev_err(gc08a3->dev, "could not sent stop streaming %d\n", ret);
> +
> +	return ret;
> +}
> +
> +static int gc08a3_s_stream(struct v4l2_subdev *subdev, int enable)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(subdev);
> +	int ret;
> +
> +	if (gc08a3->streaming == enable)
> +		return 0;

No need to check for this --- you can expect the caller not to call this
unnecessarily. Please drop this.

> +
> +	if (enable) {
> +		ret = pm_runtime_resume_and_get(gc08a3->dev);
> +		if (ret < 0)
> +			return ret;
> +
> +		ret = gc08a3_start_streaming(gc08a3);
> +		if (ret < 0)
> +			goto err_rpm_put;
> +	} else {
> +		ret = gc08a3_stop_streaming(gc08a3);
> +		if (ret < 0)
> +			goto err_rpm_put;
> +		pm_runtime_put(gc08a3->dev);
> +	}
> +
> +	gc08a3->streaming = enable;
> +	return 0;
> +
> +err_rpm_put:
> +	pm_runtime_put(gc08a3->dev);
> +	return ret;
> +}
> +
> +static int gc08a3_g_mbus_config(struct v4l2_subdev *sd, unsigned int pad,
> +				struct v4l2_mbus_config *config)
> +{
> +	config->type = V4L2_MBUS_CSI2_DPHY;
> +	config->bus.mipi_csi2.num_data_lanes = 4;
> +	config->bus.mipi_csi2.flags = 0;
> +	return 0;
> +}

As you return a static configuration, there's no need to implement
g_mbus_config().

> +
> +static int gc08a3_g_frame_interval(struct v4l2_subdev *subdev,
> +				   struct v4l2_subdev_frame_interval *fival)
> +{
> +	struct gc08a3 *gc08a3 = to_gc08a3(subdev);
> +
> +	fival->interval.numerator = 1;
> +	fival->interval.denominator = gc08a3->cur_mode->max_framerate / 10;
> +
> +	return 0;
> +}
> +
> +static int
> +gc08a3_enum_frame_interval(struct v4l2_subdev *subdev,
> +			   struct v4l2_subdev_state *sd_state,
> +			   struct v4l2_subdev_frame_interval_enum *fie)
> +{
> +	const struct gc08a3_mode *mode;
> +
> +	if (fie->index != 0)
> +		return -EINVAL;
> +
> +	mode = v4l2_find_nearest_size(gc08a3_modes, ARRAY_SIZE(gc08a3_modes),
> +				      width, height, fie->width, fie->height);

You should have an exact match here. I guess we could have a helper for
that but v4l2_find_nearest_size() doesn't do it.

> +
> +	fie->code = GC08A3_MBUS_CODE;
> +	fie->width = mode->width;
> +	fie->height = mode->height;
> +	fie->interval.numerator = 1;
> +	fie->interval.denominator = mode->max_framerate / 10;
> +
> +	return 0;
> +}
> +
> +static const struct v4l2_subdev_video_ops gc08a3_video_ops = {
> +	.s_stream = gc08a3_s_stream,
> +	.g_frame_interval = gc08a3_g_frame_interval,
> +	.s_frame_interval = gc08a3_g_frame_interval,
> +};
> +
> +static const struct v4l2_subdev_pad_ops gc08a3_subdev_pad_ops = {
> +	.enum_mbus_code = gc08a3_enum_mbus_code,
> +	.enum_frame_size = gc08a3_enum_frame_size,
> +	.enum_frame_interval = gc08a3_enum_frame_interval,
> +	.get_fmt = gc08a3_get_format,
> +	.set_fmt = gc08a3_set_format,
> +	.get_selection = gc08a3_get_selection,
> +	.init_cfg = gc08a3_entity_init_cfg,
> +	.get_mbus_config = gc08a3_g_mbus_config,
> +};
> +
> +static const struct v4l2_subdev_ops gc08a3_subdev_ops = {
> +	.core = &gc08a3_core_ops,
> +	.video = &gc08a3_video_ops,
> +	.pad = &gc08a3_subdev_pad_ops,
> +};
> +
> +static int gc08a3_get_regulators(struct device *dev, struct gc08a3 *gc08a3)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < GC08A3_NUM_SUPPLIES; i++)
> +		gc08a3->supplies[i].supply = gc08a3_supply_name[i];
> +
> +	return devm_regulator_bulk_get(dev, GC08A3_NUM_SUPPLIES,
> +				       gc08a3->supplies);
> +}
> +
> +static int gc08a3_parse_fwnode(struct device *dev)
> +{
> +	struct fwnode_handle *endpoint;
> +	struct v4l2_fwnode_endpoint bus_cfg = {
> +		.bus_type = V4L2_MBUS_CSI2_DPHY,
> +	};
> +	unsigned int i, j;
> +	int ret;
> +
> +	endpoint = fwnode_graph_get_next_endpoint(dev_fwnode(dev), NULL);
> +	if (!endpoint) {
> +		dev_err(dev, "endpoint node not found\n");
> +		return -EINVAL;
> +	}
> +
> +	ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, &bus_cfg);
> +	if (ret) {
> +		dev_err(dev, "parsing endpoint node failed\n");
> +		goto done;
> +	}
> +
> +	if (!bus_cfg.nr_of_link_frequencies) {
> +		dev_err(dev, "no link frequencies defined");
> +		ret = -EINVAL;
> +		goto done;
> +	}
> +
> +	for (i = 0; i < ARRAY_SIZE(link_freq_menu_items); i++) {
> +		for (j = 0; j < bus_cfg.nr_of_link_frequencies; j++) {
> +			if (link_freq_menu_items[i] ==
> +			    bus_cfg.link_frequencies[j])
> +				break;
> +		}
> +
> +		if (j == bus_cfg.nr_of_link_frequencies) {
> +			dev_err(dev,
> +				"no link frequency %lld supported, please check DT",
> +				link_freq_menu_items[i]);
> +			ret = -EINVAL;
> +			goto done;
> +		}
> +	}
> +
> +done:
> +	v4l2_fwnode_endpoint_free(&bus_cfg);
> +	fwnode_handle_put(endpoint);
> +	return ret;
> +}
> +
> +static int __maybe_unused gc08a3_suspend(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	if (gc08a3->streaming)
> +		gc08a3_stop_streaming(gc08a3);

Resuming (or suspending) streaming shouldn't be implemented in sensor
drivers. This is not well documented nor addressed right now, but please
remove these for now.

> +
> +	return 0;
> +}
> +
> +static int __maybe_unused gc08a3_resume(struct device *dev)
> +{
> +	struct i2c_client *client = to_i2c_client(dev);
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +	int ret;
> +
> +	if (gc08a3->streaming) {
> +		ret = gc08a3_start_streaming(gc08a3);
> +		if (ret)
> +			goto error;
> +	}
> +
> +	return 0;
> +
> +error:
> +	gc08a3_stop_streaming(gc08a3);
> +	gc08a3->streaming = 0;
> +	return ret;
> +}
> +
> +static int gc08a3_init_controls(struct gc08a3 *gc08a3)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&gc08a3->sd);
> +	const struct v4l2_ctrl_ops *ops = &gc08a3_ctrl_ops;
> +	struct v4l2_fwnode_device_properties props;
> +	struct v4l2_ctrl_handler *ctrl_hdlr;
> +	s64 exposure_max, h_blank;
> +	int ret;
> +
> +	ctrl_hdlr = &gc08a3->ctrls;
> +	ret = v4l2_ctrl_handler_init(ctrl_hdlr, 10);
> +	if (ret)
> +		return ret;
> +
> +	ctrl_hdlr->lock = &gc08a3->mutex;
> +
> +	gc08a3->link_freq =
> +		v4l2_ctrl_new_int_menu(ctrl_hdlr,
> +				       &gc08a3_ctrl_ops,
> +				       V4L2_CID_LINK_FREQ,
> +				       ARRAY_SIZE(link_freq_menu_items) - 1,
> +				       0, link_freq_menu_items);
> +	if (gc08a3->link_freq)
> +		gc08a3->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> +	gc08a3->pixel_rate =
> +		v4l2_ctrl_new_std(ctrl_hdlr,
> +				  &gc08a3_ctrl_ops,
> +				  V4L2_CID_PIXEL_RATE, 0,
> +				  to_pixel_rate(GC08A3_LINK_FREQ_336MHZ_INDEX), 1,
> +				  to_pixel_rate(GC08A3_LINK_FREQ_336MHZ_INDEX));
> +
> +	gc08a3->vblank =
> +		v4l2_ctrl_new_std(ctrl_hdlr,
> +				  &gc08a3_ctrl_ops, V4L2_CID_VBLANK,
> +				  gc08a3->cur_mode->vts_min - gc08a3->cur_mode->height,
> +				  GC08A3_VTS_MAX - gc08a3->cur_mode->height, 1,
> +				  gc08a3->cur_mode->vts_def - gc08a3->cur_mode->height);
> +
> +	h_blank = gc08a3->cur_mode->hts - gc08a3->cur_mode->width;
> +	gc08a3->hblank = v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops,
> +					   V4L2_CID_HBLANK, h_blank, h_blank, 1,
> +					   h_blank);
> +	if (gc08a3->hblank)
> +		gc08a3->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> +	v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops,
> +			  V4L2_CID_ANALOGUE_GAIN, GC08A3_AGAIN_MIN,
> +			  GC08A3_AGAIN_MAX, GC08A3_AGAIN_STEP,
> +			  GC08A3_AGAIN_MIN);
> +
> +	exposure_max = gc08a3->cur_mode->vts_def - GC08A3_EXP_MARGIN;
> +	gc08a3->exposure = v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops,
> +					     V4L2_CID_EXPOSURE, GC08A3_EXP_MIN,
> +					     exposure_max, GC08A3_EXP_STEP,
> +					     exposure_max);
> +
> +	v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &gc08a3_ctrl_ops,
> +				     V4L2_CID_TEST_PATTERN,
> +				     ARRAY_SIZE(gc08a3_test_pattern_menu) - 1,
> +				     0, 0, gc08a3_test_pattern_menu);
> +
> +	v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops, V4L2_CID_HFLIP, 0,
> +			  1, 1, 0);
> +
> +	v4l2_ctrl_new_std(ctrl_hdlr, &gc08a3_ctrl_ops, V4L2_CID_VFLIP, 0,
> +			  1, 1, 0);
> +
> +	/* register properties to fwnode (e.g. rotation, orientation) */
> +	ret = v4l2_fwnode_device_parse(&client->dev, &props);
> +	if (ret)
> +		goto error_ctrls;
> +
> +	ret = v4l2_ctrl_new_fwnode_properties(ctrl_hdlr, ops, &props);
> +	if (ret)
> +		goto error_ctrls;
> +
> +	if (ctrl_hdlr->error) {
> +		ret = ctrl_hdlr->error;
> +		goto error_ctrls;
> +	}
> +
> +	gc08a3->sd.ctrl_handler = ctrl_hdlr;
> +
> +	return 0;
> +
> +error_ctrls:
> +	v4l2_ctrl_handler_free(ctrl_hdlr);
> +
> +	return ret;
> +}
> +
> +static int gc08a3_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct gc08a3 *gc08a3;
> +	int ret;
> +
> +	ret = gc08a3_parse_fwnode(dev);
> +	if (ret)
> +		return ret;
> +
> +	gc08a3 = devm_kzalloc(dev, sizeof(*gc08a3), GFP_KERNEL);
> +	if (!gc08a3)
> +		return -ENOMEM;
> +
> +	gc08a3->dev = dev;
> +
> +	gc08a3->xclk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(gc08a3->xclk))
> +		return dev_err_probe(dev, PTR_ERR(gc08a3->xclk),
> +					 "failed to get xclk\n");
> +
> +	ret = clk_set_rate(gc08a3->xclk, GC08A3_DEFAULT_CLK_FREQ);

Please see:
<URL:https://hverkuil.home.xs4all.nl/spec/driver-api/camera-sensor.html#devicetree>.

> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +					 "failed to set xclk frequency\n");
> +
> +	ret = gc08a3_get_regulators(dev, gc08a3);
> +	if (ret < 0)
> +		return dev_err_probe(dev, ret,
> +					 "failed to get regulators\n");
> +
> +	gc08a3->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(gc08a3->enable_gpio))
> +		return dev_err_probe(dev, PTR_ERR(gc08a3->enable_gpio),
> +					 "failed to get gpio\n");
> +
> +	v4l2_i2c_subdev_init(&gc08a3->sd, client, &gc08a3_subdev_ops);
> +
> +	mutex_init(&gc08a3->mutex);
> +	gc08a3->cur_mode = &gc08a3_modes[0];
> +
> +	ret = gc08a3_power_on(gc08a3->dev);
> +	if (ret)
> +		goto err_mutex;
> +
> +	ret = gc08a3_identify_module(gc08a3);
> +	if (ret) {
> +		dev_err(&client->dev, "failed to find sensor: %d\n", ret);
> +		goto err_power_off;
> +	}
> +
> +	ret = gc08a3_init_controls(gc08a3);
> +	if (ret) {
> +		dev_err(&client->dev, "failed to init controls: %d", ret);
> +		goto err_power_off;
> +	}
> +
> +	gc08a3->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;

Please add: | V4L2_SUBDEV_FL_HAS_EVENTS;

> +	gc08a3->pad.flags = MEDIA_PAD_FL_SOURCE;
> +	gc08a3->sd.dev = &client->dev;
> +	gc08a3->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
> +
> +	ret = media_entity_pads_init(&gc08a3->sd.entity, 1, &gc08a3->pad);
> +	if (ret < 0) {
> +		dev_err(dev, "could not register media entity\n");
> +		goto err_v4l2_ctrl_handler_free;
> +	}
> +
> +	ret = v4l2_async_register_subdev_sensor(&gc08a3->sd);
> +	if (ret < 0) {
> +		dev_err(dev, "could not register v4l2 device\n");
> +		goto err_media_entity_cleanup;
> +	}
> +
> +	pm_runtime_set_active(gc08a3->dev);
> +	pm_runtime_enable(gc08a3->dev);
> +	pm_runtime_idle(gc08a3->dev);
> +
> +	return 0;
> +
> +err_media_entity_cleanup:
> +	media_entity_cleanup(&gc08a3->sd.entity);
> +
> +err_v4l2_ctrl_handler_free:
> +	v4l2_ctrl_handler_free(gc08a3->sd.ctrl_handler);
> +
> +err_power_off:
> +	gc08a3_power_off(gc08a3->dev);
> +
> +err_mutex:
> +	mutex_destroy(&gc08a3->mutex);
> +
> +	return ret;
> +}
> +
> +static void gc08a3_remove(struct i2c_client *client)
> +{
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct gc08a3 *gc08a3 = to_gc08a3(sd);
> +
> +	v4l2_async_unregister_subdev(&gc08a3->sd);
> +	media_entity_cleanup(&gc08a3->sd.entity);
> +	v4l2_ctrl_handler_free(&gc08a3->ctrls);
> +
> +	pm_runtime_disable(&client->dev);
> +	pm_runtime_set_suspended(&client->dev);
> +
> +	mutex_destroy(&gc08a3->mutex);
> +}
> +
> +static const struct of_device_id gc08a3_of_match[] = {
> +	{ .compatible = "galaxycore,gc08a3" },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, gc08a3_of_match);
> +
> +static const struct dev_pm_ops gc08a3_pm_ops = {
> +	SET_SYSTEM_SLEEP_PM_OPS(gc08a3_suspend, gc08a3_resume)
> +	SET_RUNTIME_PM_OPS(gc08a3_power_off, gc08a3_power_on, NULL)
> +};
> +
> +static struct i2c_driver gc08a3_i2c_driver = {
> +	.driver = {
> +		.of_match_table = gc08a3_of_match,
> +		.pm = &gc08a3_pm_ops,
> +		.name  = "gc08a3",
> +	},
> +	.probe = gc08a3_probe,
> +	.remove = gc08a3_remove,
> +};
> +
> +module_i2c_driver(gc08a3_i2c_driver);
> +
> +MODULE_DESCRIPTION("GalaxyCore gc08a3 Camera driver");
> +MODULE_AUTHOR("Zhi Mao <zhi.mao at mediatek.com>");
> +MODULE_LICENSE("GPL");

-- 
Kind regards,

Sakari Ailus


From heiko at sntech.de  Thu Dec  7 03:41:00 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Thu, 07 Dec 2023 12:41:00 +0100
Subject: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
In-Reply-To: <d38540c5-79a8-0582-87b9-0e99bf3044d5@gmail.com>
References: <20231205202900.4617-1-CFSworks@gmail.com> <3331042.e9J7NaK4W3@diego>
 <d38540c5-79a8-0582-87b9-0e99bf3044d5@gmail.com>
Message-ID: <2369165.PYKUYFuaPT@diego>

Am Mittwoch, 6. Dezember 2023, 19:26:40 CET schrieb Sam Edwards:
> 
> On 12/6/23 07:55, Heiko St?bner wrote:
> > Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards:
> >> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
> >> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
> >> will sometimes (varying between specific RK3588 chips, not over time) shut
> >> off the DBI block, and reads to this range will instead stall
> >> indefinitely.
> >>
> >> When this happens, it will prevent Linux from booting altogether. The
> >> PCIe driver will stall the CPU core once it attempts to read the version
> >> information from the DBI range.
> >>
> >> Fix this boot hang by adding the correct pinctrl configuration to the
> >> PCIe 3.0 device node, which is the proper thing to do anyway. While
> >> we're at it, also add the necessary configuration to the PCIe 2.0 node,
> >> which may or may not fix the equivalent problem over there -- but is the
> >> proper thing to do anyway. :)
> >>
> >> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
> >> Signed-off-by: Sam Edwards <CFSworks at gmail.com>
> >> ---
> >>   .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------
> >>   1 file changed, 2 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> >> index 9570b34aca2e..129f14dbd42f 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> >> @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy at 1 {
> >>   &pcie2x1l1 {
> >>   	linux,pci-domain = <1>;
> >>   	pinctrl-names = "default";
> >> -	pinctrl-0 = <&pcie2_reset>;
> >> +	pinctrl-0 = <&pcie30x1m1_pins>;
> >>   	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
> >>   	status = "okay";
> >>   };
> >> @@ -226,7 +226,7 @@ &pcie30phy {
> >>   &pcie3x4 {
> >>   	linux,pci-domain = <0>;
> >>   	pinctrl-names = "default";
> >> -	pinctrl-0 = <&pcie3_reset>;
> >> +	pinctrl-0 = <&pcie30x4m1_pins>;
> 
> Hi Heiko,
> 
> > 
> > also, why are you throwing out the pinctrl for the reset pin.
> > That seems not related to the regular pins and you could instead just do
> > 
> > +	pinctrl-0 = <&pcie30x4m1_pins>, <&pcie3_reset>;
> 
> The pcie30x4m1_pins def does include pinmuxing `4 RK_PB6` to the DW 
> controller already. The v2 patch should probably instead remove the 
> reset-gpios property, since an out-of-band GPIO reset is not needed when 
> the controller can do it.

yep, also because of the reset-gpios the pinctrl/gpio driver will mux the
pin to gpio function even though the pinctrl would've set if the pcie-
function before that.

So I'm really in favor of not mixing the two concepts :-)
When setting the pins, the reset-gpio should be gone and vice-versa.

> I'm still looking into the story with the PCIe 2.0 pins, since 2.0x1's 
> PERST# is definitely 4A2. I'll ask around and try to find out where the 
> corresponding CLKREQ# is going.

Yeah, I tried reading up in the TRM but it was really hard following
which pin-group actually goes to which controller and the naming
definitly does not help :-) .


Heiko



> >>   	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
> >>   	vpcie3v3-supply = <&vcc3v3_pcie30>;
> >>   	status = "okay";
> >> @@ -245,17 +245,7 @@ hym8563_int: hym8563-int {
> >>   		};
> >>   	};
> >>   
> >> -	pcie2 {
> >> -		pcie2_reset: pcie2-reset {
> >> -			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
> >> -		};
> >> -	};
> >> -
> >>   	pcie3 {
> >> -		pcie3_reset: pcie3-reset {
> >> -			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
> >> -		};
> >> -
> >>   		vcc3v3_pcie30_en: pcie3-reg {
> >>   			rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
> >>   		};
> >>
> > 
> > 
> > 
> > 
> 






From ryan.roberts at arm.com  Thu Dec  7 03:44:03 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 7 Dec 2023 11:44:03 +0000
Subject: [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <44fdd46b-ad46-4ae2-a20f-20374acdf464@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-4-ryan.roberts@arm.com>
 <004ed23d-5571-4474-b7fe-7bc08817c165@redhat.com>
 <ca3a2b97-f08e-452a-91dc-1a53dece0aa6@arm.com>
 <378afc6b-f93a-48ad-8aa6-ab171f3b9613@redhat.com>
 <4aa520f0-7c84-4e93-88bf-aee6d8d3ea70@arm.com>
 <44fdd46b-ad46-4ae2-a20f-20374acdf464@redhat.com>
Message-ID: <856f4317-43d9-41bb-8096-1eef69c86d3b@arm.com>

On 07/12/2023 11:25, David Hildenbrand wrote:
> On 07.12.23 12:22, Ryan Roberts wrote:
>> On 07/12/2023 11:13, David Hildenbrand wrote:
>>>>>
>>>>>> +
>>>>>> ??????? if (!vma->vm_mm)??????? /* vdso */
>>>>>> -??????? return false;
>>>>>> +??????? return 0;
>>>>>> ??? ????? /*
>>>>>> ???????? * Explicitly disabled through madvise or prctl, or some
>>>>>> @@ -88,16 +141,16 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>>>>> unsigned long vm_flags,
>>>>>> ???????? * */
>>>>>> ??????? if ((vm_flags & VM_NOHUGEPAGE) ||
>>>>>> ??????????? test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
>>>>>> -??????? return false;
>>>>>> +??????? return 0;
>>>>>> ??????? /*
>>>>>> ???????? * If the hardware/firmware marked hugepage support disabled.
>>>>>> ???????? */
>>>>>> ??????? if (transparent_hugepage_flags & (1 <<
>>>>>> TRANSPARENT_HUGEPAGE_UNSUPPORTED))
>>>>>> -??????? return false;
>>>>>> +??????? return 0;
>>>>>> ??? ????? /* khugepaged doesn't collapse DAX vma, but page fault is fine. */
>>>>>> ??????? if (vma_is_dax(vma))
>>>>>> -??????? return in_pf;
>>>>>> +??????? return in_pf ? orders : 0;
>>>>>> ??? ????? /*
>>>>>> ???????? * khugepaged special VMA and hugetlb VMA.
>>>>>> @@ -105,17 +158,29 @@ bool hugepage_vma_check(struct vm_area_struct *vma,
>>>>>> unsigned long vm_flags,
>>>>>> ???????? * VM_MIXEDMAP set.
>>>>>> ???????? */
>>>>>> ??????? if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
>>>>>> -??????? return false;
>>>>>> +??????? return 0;
>>>>>> ??? ????? /*
>>>>>> -???? * Check alignment for file vma and size for both file and anon vma.
>>>>>> +???? * Check alignment for file vma and size for both file and anon vma by
>>>>>> +???? * filtering out the unsuitable orders.
>>>>>> ???????? *
>>>>>> ???????? * Skip the check for page fault. Huge fault does the check in fault
>>>>>> -???? * handlers. And this check is not suitable for huge PUD fault.
>>>>>> +???? * handlers.
>>>>>> ???????? */
>>>>>> -??? if (!in_pf &&
>>>>>> -??????? !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
>>>>>> -??????? return false;
>>>>>> +??? if (!in_pf) {
>>>>>> +??????? int order = first_order(orders);
>>>>>> +??????? unsigned long addr;
>>>>>> +
>>>>>> +??????? while (orders) {
>>>>>> +??????????? addr = vma->vm_end - (PAGE_SIZE << order);
>>>>>> +??????????? if (thp_vma_suitable_orders(vma, addr, BIT(order)))
>>>>>> +??????????????? break;
>>>>>
>>>>> Comment: you'd want a "thp_vma_suitable_order" helper here. But maybe the
>>>>> compiler is smart enough to optimize the loop and everyything else out.
>>>>
>>>> I'm happy to refactor so that thp_vma_suitable_order() is the basic primitive,
>>>> then make thp_vma_suitable_orders() a loop that calls thp_vma_suitable_order()
>>>> (that's basically how it is laid out already, just all in one function). Is
>>>> that
>>>> what you are requesting?
>>>
>>> You got the spirit, yes.
>>>
>>>>>
>>>>> [...]
>>>>>
>>>>>> +
>>>>>> +static ssize_t thpsize_enabled_store(struct kobject *kobj,
>>>>>> +???????????????????? struct kobj_attribute *attr,
>>>>>> +???????????????????? const char *buf, size_t count)
>>>>>> +{
>>>>>> +??? int order = to_thpsize(kobj)->order;
>>>>>> +??? ssize_t ret = count;
>>>>>> +
>>>>>> +??? if (sysfs_streq(buf, "always")) {
>>>>>> +??????? set_bit(order, &huge_anon_orders_always);
>>>>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>>>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>>>>> +??? } else if (sysfs_streq(buf, "inherit")) {
>>>>>> +??????? set_bit(order, &huge_anon_orders_inherit);
>>>>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>>>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>>>>> +??? } else if (sysfs_streq(buf, "madvise")) {
>>>>>> +??????? set_bit(order, &huge_anon_orders_madvise);
>>>>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>>>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>>>>> +??? } else if (sysfs_streq(buf, "never")) {
>>>>>> +??????? clear_bit(order, &huge_anon_orders_always);
>>>>>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>>>>>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>>>>>
>>>>> Note: I was wondering for a second if some concurrent cames could lead to an
>>>>> inconsistent state. I think in the worst case we'll simply end up with "never"
>>>>> on races.
>>>>
>>>> You mean if different threads try to write different values to this file
>>>> concurrently? Or if there is a concurrent fault that tries to read the flags
>>>> while they are being modified?
>>>
>>> I thought about what you said first, but what you said last might also apply. As
>>> long as "nothing breaks", all good.
>>>
>>>>
>>>> I thought about this for a long time too and wasn't sure what was best. The
>>>> existing global enabled store impl clears the bits first then sets the bit.
>>>> With
>>>> this approach you can end up with multiple bits set if there is a race to set
>>>> diffierent values, and you can end up with a faulting thread seeing never if it
>>>> reads the bits after they have been cleared but before setting them.
>>>
>>> Right, but user space is playing stupid games and can win stupid prices. As long
>>> as nothing breaks, we're good.
>>>
>>>>
>>>> I decided to set the new bit before clearing the old bits, which is
>>>> different; A
>>>> racing fault will never see "never" but as you say, a race to set the file
>>>> could
>>>> result in "never" being set.
>>>>
>>>> On reflection, it's probably best to set the bit *last* like the global control
>>>> does?
>>>
>>> Probably might just slap a simple spinlock in there, so at least the writer side
>>> is completely serialized. Then you can just set the bit last. It's unlikely that
>>> readers will actually run into issues, and if they ever would, we could use some
>>> rcu magic to let them read a consistent state.
>>
>> I'd prefer to leave it as it is now; clear first, set last without any explicit
>> serialization. I've convinced myself that nothing breaks and its the same
>> pattern used by the global control so its consistent. Unless you're insisting on
>> the spin lock?
> 
> No, not at all. But it would certainly remove any possible concerns :)

OK fine, you win :). I'll add a spin lock on the writer side.




From laurent.pinchart at ideasonboard.com  Thu Dec  7 03:44:26 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 13:44:26 +0200
Subject: [PATCH v2 0/2] media: i2c: Add support for GC08A3 sensor
In-Reply-To: <c8e0ff23-9464-441d-bcaa-485a3eca0fcd@linaro.org>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
 <c8e0ff23-9464-441d-bcaa-485a3eca0fcd@linaro.org>
Message-ID: <20231207114426.GA6104@pendragon.ideasonboard.com>

On Thu, Dec 07, 2023 at 09:19:01AM +0100, Krzysztof Kozlowski wrote:
> On 07/12/2023 06:20, Zhi Mao wrote:
> > This series adds YAML DT binding and V4L2 sub-device driver for Galaxycore's
> > GC08A3 8-megapixel 10-bit RAW CMOS 1/4" sensor, with an MIPI CSI-2 image data
> > interface and the I2C control bus.
> > 
> > The driver is implemented with V4L2 framework.
> >  - Async registered as a V4L2 sub-device.
> >  - As the first component of camera system including Seninf, ISP pipeline.
> >  - A media entity that provides one source pad in common.
> >  - Used in camera features on ChromeOS application.
> > 
> > Also this driver supports following features:
> >  - manual exposure and analog gain control support
> >  - vertical blanking control support
> >  - test pattern support
> >  - media controller support
> >  - runtime PM support
> >  - support resolution: 3264x2448 at 30fps, 1920x1080 at 60fps
> > 
> > Previous versions of this patch-set can be found here:
> >  v1: https://lore.kernel.org/linux-media/20231123115104.32094-1-zhi.mao at mediatek.com/
> > 
> > Changes of v2 mainly address comments from Krzysztof/Rob Herring&Conor Dooley.
> > Compared to v1:
> >   - Fix some review comments  
> 
> What exactly fixed? This cannot be that vague!

Detailed changelogs are very useful for reviewers, and they should
ideally be recorded for each patch, not just in the cover letter. It's
not as difficult and time consuming as it sounds, here's how I usually
handle it when working on a patch series (the explanation is meant more
for Zhi Mao than Krzysztof :-)).

When taking review comments into account, I will take the comments one
by one, and update the code accordingly. I then compile-test the change,
and apply it as a new 'fixup' commit:

$ git commit -a --edit --fixup <id of the commit being fixed>

In the editor, I type a single line to describe the change.

The procedure is repeated for all review comments on all patches. When
I'm done, I test the final result, and then rebase the branch to
*squash* all the fixups with the original patch. git opens a text editor
with all the commit messages of the fixups being concatenated after the
commit message of the original patch. I edit that manually to format it
as a changelog, but adding

---
Changes since vX:

manually, and follow with the one-line descriptions of all the changes.

This is a fast process, it's much easier and faster to record a one-line
description of each change as I go along than trying to write a
changelog manually at the end, remembering all the changes I've made.

Krzysztof, if you plan to make a talk about tooling for Linux kernel
contributors, similar to your excellent talk at LPC about tooling for
maintainers, this is something you could include :-)

-- 
Regards,

Laurent Pinchart


From laurent.pinchart at ideasonboard.com  Thu Dec  7 03:45:13 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 13:45:13 +0200
Subject: [PATCH v2 0/2] media: i2c: Add support for GC08A3 sensor
In-Reply-To: <20231207052016.25954-1-zhi.mao@mediatek.com>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
Message-ID: <20231207114513.GB6104@pendragon.ideasonboard.com>

Hi Zhi Mao,

I have reviewed your v1 before noticing the v2, sorry about that. Most
of the comments I made on v1 are still applicable, so I'll skip v2 and
review v3.

On Thu, Dec 07, 2023 at 01:20:14PM +0800, Zhi Mao wrote:
> This series adds YAML DT binding and V4L2 sub-device driver for Galaxycore's
> GC08A3 8-megapixel 10-bit RAW CMOS 1/4" sensor, with an MIPI CSI-2 image data
> interface and the I2C control bus.
> 
> The driver is implemented with V4L2 framework.
>  - Async registered as a V4L2 sub-device.
>  - As the first component of camera system including Seninf, ISP pipeline.
>  - A media entity that provides one source pad in common.
>  - Used in camera features on ChromeOS application.
> 
> Also this driver supports following features:
>  - manual exposure and analog gain control support
>  - vertical blanking control support
>  - test pattern support
>  - media controller support
>  - runtime PM support
>  - support resolution: 3264x2448 at 30fps, 1920x1080 at 60fps
> 
> Previous versions of this patch-set can be found here:
>  v1: https://lore.kernel.org/linux-media/20231123115104.32094-1-zhi.mao at mediatek.com/
> 
> Changes of v2 mainly address comments from Krzysztof/Rob Herring&Conor Dooley.
> Compared to v1:
>   - Fix some review comments  
>   - Add reviewed-by for sensor driver
>   - Fix some build-error and warning message 
>  
> Thanks
> 
> 
> Zhi Mao (2):
>   media: i2c: Add GC08A3 image sensor driver
>   media: dt-bindings: media: i2c: Document GC08A3 bindings
> 
>  .../bindings/media/i2c/galaxycore,gc08a3.yaml |  127 ++
>  .../devicetree/bindings/vendor-prefixes.yaml  |    2 +
>  drivers/media/i2c/Kconfig                     |   14 +
>  drivers/media/i2c/Makefile                    |    1 +
>  drivers/media/i2c/gc08a3.c                    | 1888 +++++++++++++++++
>  5 files changed, 2032 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
>  create mode 100644 drivers/media/i2c/gc08a3.c

-- 
Regards,

Laurent Pinchart


From fancer.lancer at gmail.com  Thu Dec  7 03:56:25 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Thu, 7 Dec 2023 14:56:25 +0300
Subject: [PATCH net-next v2] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
References: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
Message-ID: <o3abmn7ocuksmjg23rrgsib7nfm4yo5rtzlqw2np2pplg73drd@7qe4vrsx2gyc>

Hi Andrew

On Wed, Dec 06, 2023 at 05:46:09PM -0600, Andrew Halaney wrote:
> The stmmac_dt_phy() function, which parses the devicetree node of the
> MAC and ultimately causes MDIO bus allocation, misinterprets what
> fixed-link means in relation to the MAC's MDIO bus. This results in
> a MDIO bus being created in situations it need not be.
> 
> Currently a MDIO bus is created if the description is either:
> 
>     1. Not fixed-link
>     2. fixed-link but contains a MDIO bus as well
> 
> The "1" case above isn't always accurate. If there's a phy-handle,
> it could be referencing a phy on another MDIO controller's bus[1]. In
> this case currently the MAC will make a MDIO bus and scan it all
> anyways unnecessarily.
> 
> There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> be created and scanned for a phy. This case can also be inferred from
> the platform description by not having a phy-handle && not being
> fixed-link. This hits case "1" in the current driver's logic.
> 
> Let's improve the logic to create a MDIO bus if either:
> 
>     - Devicetree contains a MDIO bus
>     - !fixed-link && !phy-handle (legacy handling)
> 
> Below upstream devicetree snippets can be found that explain some of
> the cases above more concretely.
> 
> Here's[0] a devicetree example where the MAC is both fixed-link and
> driving a switch on MDIO (case "2" above). This needs a MDIO bus to
> be created:
> 
>     &fec1 {
>             phy-mode = "rmii";
> 
>             fixed-link {
>                     speed = <100>;
>                     full-duplex;
>             };
> 
>             mdio1: mdio {
>                     switch0: switch0 at 0 {
>                             compatible = "marvell,mv88e6190";
>                             pinctrl-0 = <&pinctrl_gpio_switch0>;
>                     };
>             };
>     };
> 
> Here's[1] an example where there is no MDIO bus or fixed-link for
> the ethernet1 MAC, so no MDIO bus should be created since ethernet0
> is the MDIO master for ethernet1's phy:
> 
>     &ethernet0 {
>             phy-mode = "sgmii";
>             phy-handle = <&sgmii_phy0>;
> 
>             mdio {
>                     compatible = "snps,dwmac-mdio";
>                     sgmii_phy0: phy at 8 {
>                             compatible = "ethernet-phy-id0141.0dd4";
>                             reg = <0x8>;
>                             device_type = "ethernet-phy";
>                     };
> 
>                     sgmii_phy1: phy at a {
>                             compatible = "ethernet-phy-id0141.0dd4";
>                             reg = <0xa>;
>                             device_type = "ethernet-phy";
>                     };
>             };
>     };
> 
>     &ethernet1 {
>             phy-mode = "sgmii";
>             phy-handle = <&sgmii_phy1>;
>     };
> 
> Finally there's descriptions like this[2] which don't describe the
> MDIO bus but expect it to be created and the whole address space
> scanned for a phy since there's no phy-handle or fixed-link described:
> 
>     &gmac {
>             phy-supply = <&vcc_lan>;
>             phy-mode = "rmii";
>             snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
>             snps,reset-active-low;
>             snps,reset-delays-us = <0 10000 1000000>;
>     };
> 
> [0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts
> [1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
> [2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164

Thank you for the patch. Please find a comment below.

> 
> Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
> ---
>  .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 85 ++++++++++------------
>  1 file changed, 37 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 1ffde555da47..7da461fe93f6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -296,69 +296,39 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
>  }
>  
>  /**
> - * stmmac_dt_phy - parse device-tree driver parameters to allocate PHY resources
> - * @plat: driver data platform structure
> - * @np: device tree node
> - * @dev: device pointer
> - * Description:
> - * The mdio bus will be allocated in case of a phy transceiver is on board;
> - * it will be NULL if the fixed-link is configured.
> - * If there is the "snps,dwmac-mdio" sub-node the mdio will be allocated
> - * in any case (for DSA, mdio must be registered even if fixed-link).
> - * The table below sums the supported configurations:
> - *	-------------------------------
> - *	snps,phy-addr	|     Y
> - *	-------------------------------
> - *	phy-handle	|     Y
> - *	-------------------------------
> - *	fixed-link	|     N
> - *	-------------------------------
> - *	snps,dwmac-mdio	|
> - *	  even if	|     Y
> - *	fixed-link	|
> - *	-------------------------------
> + * stmmac_of_get_mdio() - Gets the MDIO bus from the devicetree
> + * @np: devicetree node
>   *
> - * It returns 0 in case of success otherwise -ENODEV.
> + * The MDIO bus will be searched for in the following ways:
> + * 1. The compatible is "snps,dwc-qos-ethernet-4.10" && a "mdio" named
> + *    child node exists
> + * 2. A child node with the "snps,dwmac-mdio" compatible is present
> + *
> + * Return: The MDIO node if present otherwise NULL
>   */
> -static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> -			 struct device_node *np, struct device *dev)
> +static struct device_node *stmmac_of_get_mdio(struct device_node *np)
>  {
> -	bool mdio = !of_phy_is_fixed_link(np);
>  	static const struct of_device_id need_mdio_ids[] = {
>  		{ .compatible = "snps,dwc-qos-ethernet-4.10" },
>  		{},
>  	};
> +	struct device_node *mdio_node = NULL;
>  
>  	if (of_match_node(need_mdio_ids, np)) {
> -		plat->mdio_node = of_get_child_by_name(np, "mdio");
> +		mdio_node = of_get_child_by_name(np, "mdio");
>  	} else {
>  		/**
>  		 * If snps,dwmac-mdio is passed from DT, always register
>  		 * the MDIO
>  		 */
> -		for_each_child_of_node(np, plat->mdio_node) {
> -			if (of_device_is_compatible(plat->mdio_node,
> +		for_each_child_of_node(np, mdio_node) {
> +			if (of_device_is_compatible(mdio_node,
>  						    "snps,dwmac-mdio"))
>  				break;
>  		}
>  	}
>  
> -	if (plat->mdio_node) {
> -		dev_dbg(dev, "Found MDIO subnode\n");
> -		mdio = true;
> -	}
> -
> -	if (mdio) {
> -		plat->mdio_bus_data =
> -			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
> -				     GFP_KERNEL);
> -		if (!plat->mdio_bus_data)
> -			return -ENOMEM;
> -
> -		plat->mdio_bus_data->needs_reset = true;
> -	}
> -
> -	return 0;
> +	return mdio_node;
>  }
>  
>  /**
> @@ -417,6 +387,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
>  	struct device_node *np = pdev->dev.of_node;
>  	struct plat_stmmacenet_data *plat;
>  	struct stmmac_dma_cfg *dma_cfg;
> +	bool legacy_mdio;
>  	int phy_mode;
>  	void *ret;
>  	int rc;
> @@ -471,10 +442,28 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
>  	if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
>  		dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
>  
> -	/* To Configure PHY by using all device-tree supported properties */
> -	rc = stmmac_dt_phy(plat, np, &pdev->dev);
> -	if (rc)
> -		return ERR_PTR(rc);
> +	plat->mdio_node = stmmac_of_get_mdio(np);
> +	if (plat->mdio_node)
> +		dev_dbg(&pdev->dev, "Found MDIO subnode\n");
> +

> +	/* Legacy devicetrees allowed for no MDIO bus description and expect
> +	 * the bus to be scanned for devices. If there's no phy or fixed-link
> +	 * described assume this is the case since there must be something
> +	 * connected to the MAC.
> +	 */
> +	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
> +	if (legacy_mdio)
> +		dev_info(&pdev->dev, "Deprecated MDIO bus assumption used\n");
> +
> +	if (plat->mdio_node || legacy_mdio) {
> +		plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
> +						   sizeof(struct stmmac_mdio_bus_data),
> +						   GFP_KERNEL);
> +		if (!plat->mdio_bus_data)
> +			return ERR_PTR(-ENOMEM);
> +
> +		plat->mdio_bus_data->needs_reset = true;
> +	}

Why did you decide to move this out of the dedicated function?
stmmac_probe_config_dt() is already overwhelmed with various
non-coherent actions. The method has already got to being too long to
follow the kernel coding style limit (I have got a not submitted yet
cleanup patchset which step-by-step fixes that). Could you please get
the chunk above back to the respective function and, for instance,
just change it's name to something like stmmac_mdio_setup()? (I prefer
having "_setup" suffix because some of the locally defined static
methods already use it: stmmac_axi_setup(), stmmac_mtl_setup().)

-Serge(y)

>  
>  	of_property_read_u32(np, "tx-fifo-depth", &plat->tx_fifo_size);
>  
> 
> ---
> base-commit: fd8a79b63710acb84321be3ce74be23c876873fb
> change-id: 20231127-stmmac-no-mdio-node-1db9da8a25d9
> 
> Best regards,
> -- 
> Andrew Halaney <ahalaney at redhat.com>
> 
> 


From ryan.roberts at arm.com  Thu Dec  7 04:08:22 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 7 Dec 2023 12:08:22 +0000
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <ca649aad-7b76-4c6d-b513-26b3d58f8e68@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
 <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
 <ca649aad-7b76-4c6d-b513-26b3d58f8e68@redhat.com>
Message-ID: <126c3b71-1acc-4851-9986-4228cb8a8660@arm.com>

On 07/12/2023 11:08, David Hildenbrand wrote:
> [...]
> 
>>>
>>> Nit: the orders = ... order = ... looks like this might deserve a helper
>>> function that makes this easier to read.
>>
>> To be honest, the existing function that I've modified is a bit of a mess.
> 
> It's all an ugly mess and I hate it.
> 
> It would be cleanest if we'd just have "thp_vma_configured_orders()" that gives
> us all configured orders for the given VMA+flags combination. No passing in of
> orders, try handling the masking in the caller.
> 
> Then, we move that nasty "transhuge_vma_suitable" handling for !in_pf out of
> there and handle that in the callers. The comment "Huge fault does the check in
> fault handlers. And this check is not suitable for huge PUD fault handlers."
> already makes me angry, what a mess.

My thp_vma_suitable_order[s]() does now at least work correctly for PUD.

> 
> 
> Then, we'd have a thp_vma_fitting_orders() / thp_vma_is_fitting_order() function
> that does the filtering only based on the given address + vma size/alignment.
> That's roughly "thp_vma_suitable_orders()".
> 
> 
> Finding a good name to combine both could be something like
> "thp_vma_possible_orders()".
> 
> 
> Would make more sense to me (but again, German guy, so it's probably all wrong).
> 
> 
>> thp_vma_allowable_orders() calls thp_vma_suitable_orders() if we are not in a
>> page fault, because the page fault handlers already do that check themselves. It
>> would be nice to refactor the whole thing so that thp_vma_allowable_orders() is
>> a strict superset of thp_vma_suitable_orders(). Then this can just call
>> thp_vma_allowable_orders(). But that's going to start touching the PMD and PUD
>> handlers, so prefer if we leave that for a separate patch set.
>>
>>>
>>> Nit: Why call thp_vma_suitable_orders if the orders are already 0? Again, some
>>> helper might be reasonable where that is handled internally.
>>
>> Because thp_vma_suitable_orders() will handle it safely and is inline, so it
>> should just as efficient? This would go away with the refactoring described
>> above.
> 
> Right. Won't win in a beauty contest. Some simple helper might make this much
> easier to digest.
> 
>>
>>>
>>> Comment: For order-0 we'll always perform a function call to both
>>> thp_vma_allowable_orders() / thp_vma_suitable_orders(). We should perform some
>>> fast and efficient check if any <PMD THP are even enabled in the system / for
>>> this VMA, and in that case just fallback before doing more expensive checks.
>>
>> thp_vma_allowable_orders() is inline as you mentioned.
>>
>> I was deliberately trying to keep all the decision logic in one place
>> (thp_vma_suitable_orders) because it's already pretty complicated. But if you
>> insist, how about this in the header:
>>
>> static inline
>> unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
>> ?????????????????????? unsigned long vm_flags, bool smaps,
>> ?????????????????????? bool in_pf, bool enforce_sysfs,
>> ?????????????????????? unsigned long orders)
>> {
>> ????/* Optimization to check if required orders are enabled early. */
>> ????if (enforce_sysfs && vma_is_anonymous(vma)) {
>> ??????? unsigned long mask = READ_ONCE(huge_anon_orders_always);
>>
>> ??????? if (vm_flags & VM_HUGEPAGE)
>> ??????????? mask |= READ_ONCE(huge_anon_orders_madvise);
>> ??????? if (hugepage_global_always() ||
>> ??????????? ((vm_flags & VM_HUGEPAGE) && hugepage_global_enabled()))
>> ??????????? mask |= READ_ONCE(huge_anon_orders_inherit);
>>
>> ??????? orders &= mask;
>> ??????? if (!orders)
>> ??????????? return 0;
>> ???????
>> ??????? enforce_sysfs = false;
>> ????}
>>
>> ????return __thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf,
>> ????????????????????? enforce_sysfs, orders);
>> }
>>
>> Then the above check can be removed from __thp_vma_allowable_orders() - it will
>> still retain the `if (enforce_sysfs && !vma_is_anonymous(vma))` part.
>>
> 
> Better. I still kind-of hate having to pass in orders here. Such masking is
> better done in the caller (see above how it might be done when moving the
> transhuge_vma_suitable() check out).
> 
>>
>>>
>>>> +
>>>> +??? if (!orders)
>>>> +??????? goto fallback;
>>>> +
>>>> +??? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>>> +??? if (!pte)
>>>> +??????? return ERR_PTR(-EAGAIN);
>>>> +
>>>> +??? order = first_order(orders);
>>>> +??? while (orders) {
>>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>> +??????? vmf->pte = pte + pte_index(addr);
>>>> +??????? if (pte_range_none(vmf->pte, 1 << order))
>>>> +??????????? break;
>>>
>>> Comment: Likely it would make sense to scan only once and determine the "largest
>>> none range" around that address, having the largest suitable order in mind.
>>
>> Yes, that's how I used to do it, but Yu Zhou requested simplifying to this,
>> IIRC. Perhaps this an optimization opportunity for later?
> 
> Yes, definetly.
> 
>>
>>>
>>>> +??????? order = next_order(&orders, order);
>>>> +??? }
>>>> +
>>>> +??? vmf->pte = NULL;
>>>
>>> Nit: Can you elaborate why you are messing with vmf->pte here? A simple helper
>>> variable will make this code look less magical. Unless I am missing something
>>> important :)
>>
>> Gahh, I used to pass the vmf to what pte_range_none() was refactored into (an
>> approach that was suggested by Yu Zhou IIRC). But since I did some refactoring
>> based on some comments from JohnH, I see I don't need that anymore. Agreed; it
>> will be much clearer just to use a local variable. Will fix.
>>
>>>
>>>> +??? pte_unmap(pte);
>>>> +
>>>> +??? gfp = vma_thp_gfp_mask(vma);
>>>> +
>>>> +??? while (orders) {
>>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>> +??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>>> +??????? if (folio) {
>>>> +??????????? clear_huge_page(&folio->page, addr, 1 << order);
>>>> +??????????? return folio;
>>>> +??????? }
>>>> +??????? order = next_order(&orders, order);
>>>> +??? }
>>>> +
>>>
>>> Queestion: would it make sense to combine both loops? I suspect memory
>>> allocations with pte_offset_map()/kmao are problematic.
>>
>> They are both operating on separate orders; next_order() is "consuming" an order
>> by removing the current one from the orders bitfield and returning the next one.
>>
>> So the first loop starts at the highest order and keeps checking lower orders
>> until one fully fits in the VMA. And the second loop starts at the first order
>> that was found to fully fits and loops to lower orders until an allocation is
>> successful.
> 
> Right, but you know from the first loop which order is applicable (and will be
> fed to the second loop) and could just pte_unmap(pte) + tryalloc. If that fails,
> remap and try with the next orders.

You mean something like this?

	pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
	if (!pte)
		return ERR_PTR(-EAGAIN);

	order = highest_order(orders);
	while (orders) {
		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
		if (!pte_range_none(pte + pte_index(addr), 1 << order)) {
			order = next_order(&orders, order);
			continue;
		}

		pte_unmap(pte);
		
		folio = vma_alloc_folio(gfp, order, vma, addr, true);
		if (folio) {
			clear_huge_page(&folio->page, vmf->address, 1 << order);
			return folio;
		}

		pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
		if (!pte)
			return ERR_PTR(-EAGAIN);

		order = next_order(&orders, order);
	}

	pte_unmap(pte);

I don't really like that because if high order folio allocations fail, then you
are calling pte_range_none() again for the next lower order; once that check has
succeeded for an order it shouldn't be required for any lower orders. In this
case you also have lots of pte map/unmap.

The original version feels more efficient to me.

> 
> That would make the code certainly easier to understand. That "orders" magic of
> constructing, filtering, walking is confusing :)
> 
> 
> I might find some time today to see if there is an easy way to cleanup all what
> I spelled out above. It really is a mess. But likely that cleanup could be
> deferred (but you're touching it, so ... :) ).

I'm going to ignore the last 5 words. I heard the "that cleanup could be
deferred" part loud and clear though :)


> 



From alexious at zju.edu.cn  Thu Dec  7 04:19:31 2023
From: alexious at zju.edu.cn (Zhipeng Lu)
Date: Thu,  7 Dec 2023 20:19:31 +0800
Subject: [PATCH] soc: realview: fix two memleaks in realview_soc_probe
Message-ID: <20231207121932.3353687-1-alexious@zju.edu.cn>

When of_property_read_string fails, it should free soc_dev_attr
allocated by kzalloc before. So as the failure of regmap_read, the
soc_dev needs to be unregistered and soc_dev_attr needs to be freed.

Fixes: a2974c9c1f83 ("soc: add driver for the ARM RealView")
Signed-off-by: Zhipeng Lu <alexious at zju.edu.cn>
---
 drivers/soc/versatile/soc-realview.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/versatile/soc-realview.c b/drivers/soc/versatile/soc-realview.c
index c6876d232d8f..19c4a9599c9f 100644
--- a/drivers/soc/versatile/soc-realview.c
+++ b/drivers/soc/versatile/soc-realview.c
@@ -99,8 +99,10 @@ static int realview_soc_probe(struct platform_device *pdev)
 
 	ret = of_property_read_string(np, "compatible",
 				      &soc_dev_attr->soc_id);
-	if (ret)
+	if (ret) {
+		kfree(soc_dev_attr);
 		return -EINVAL;
+	}
 
 	soc_dev_attr->machine = "RealView";
 	soc_dev_attr->family = "Versatile";
@@ -112,9 +114,11 @@ static int realview_soc_probe(struct platform_device *pdev)
 	}
 	ret = regmap_read(syscon_regmap, REALVIEW_SYS_ID_OFFSET,
 			  &realview_coreid);
-	if (ret)
+	if (ret) {
+		soc_device_unregister(soc_dev);
+		kfree(soc_dev_attr);
 		return -ENODEV;
-
+	}
 	dev_info(&pdev->dev, "RealView Syscon Core ID: 0x%08x, HBI-%03x\n",
 		 realview_coreid,
 		 ((realview_coreid >> 16) & 0xfff));
-- 
2.34.1



From festevam at gmail.com  Thu Dec  7 04:20:56 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 09:20:56 -0300
Subject: [PATCH] arm64: dts: imx93: Fix the micfil clock-names entries
Message-ID: <20231207122056.2526158-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

fsl,micfil.yaml defines the clock-names in the following sequence:

  clock-names:
    items:
      - const: ipg_clk
      - const: ipg_clk_app
      - const: pll8k
      - const: pll11k
      - const: clkext3
    minItems: 2

imx93.dtsi currently misses the 'pll11k' entry and jump to 'clkext3'.

This leads to the following dt-schema warning:

imx93-11x11-evk.dtb: micfil at 44520000: clock-names:3: 'pll11k' was expected
	from schema $id: http://devicetree.org/schemas/sound/fsl,micfil.yaml#

Fix the warning by describing the clocks up to 'pll8k' as 'clkext3'
is assigned to a dummy clock.

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm64/boot/dts/freescale/imx93.dtsi | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi b/arch/arm64/boot/dts/freescale/imx93.dtsi
index df064ecae6f3..0f4723bae43e 100644
--- a/arch/arm64/boot/dts/freescale/imx93.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
@@ -484,10 +484,8 @@ micfil: micfil at 44520000 {
 					     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clk IMX93_CLK_PDM_IPG>,
 					 <&clk IMX93_CLK_PDM_GATE>,
-					 <&clk IMX93_CLK_AUDIO_PLL>,
-					 <&clk IMX93_CLK_DUMMY>;
-				clock-names = "ipg_clk", "ipg_clk_app",
-					      "pll8k", "clkext3";
+					 <&clk IMX93_CLK_AUDIO_PLL>;
+				clock-names = "ipg_clk", "ipg_clk_app", "pll8k";
 				dmas = <&edma1 29 0 5>;
 				dma-names = "rx";
 				status = "disabled";
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Thu Dec  7 04:30:35 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 13:30:35 +0100
Subject: [PATCH 1/2] media: i2c: Add GC08A3 image sensor driver
In-Reply-To: <ZXGtqwjYruBQVaUr@kekkonen.localdomain>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
 <20231207052016.25954-2-zhi.mao@mediatek.com>
 <ZXGtqwjYruBQVaUr@kekkonen.localdomain>
Message-ID: <129e3a8b-5e91-424a-8ff8-b015d5175f1a@linaro.org>

On 07/12/2023 12:34, Sakari Ailus wrote:
>> +	ret = gc08a3_parse_fwnode(dev);
>> +	if (ret)
>> +		return ret;
>> +
>> +	gc08a3 = devm_kzalloc(dev, sizeof(*gc08a3), GFP_KERNEL);
>> +	if (!gc08a3)
>> +		return -ENOMEM;
>> +
>> +	gc08a3->dev = dev;
>> +
>> +	gc08a3->xclk = devm_clk_get(dev, NULL);
>> +	if (IS_ERR(gc08a3->xclk))
>> +		return dev_err_probe(dev, PTR_ERR(gc08a3->xclk),
>> +					 "failed to get xclk\n");
>> +
>> +	ret = clk_set_rate(gc08a3->xclk, GC08A3_DEFAULT_CLK_FREQ);
> 
> Please see:
> <URL:https://hverkuil.home.xs4all.nl/spec/driver-api/camera-sensor.html#devicetree>.


Oh, that's cool it was documented!

The canonical link would be:
https://www.kernel.org/doc/html/latest/driver-api/media/camera-sensor.html#devicetree



Best regards,
Krzysztof



From broonie at kernel.org  Thu Dec  7 04:30:45 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 7 Dec 2023 12:30:45 +0000
Subject: [PATCH v3 15/21] KVM: arm64: Support FEAT_FPMR for guests
In-Reply-To: <87cyvi8kz1.wl-maz@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
 <20231205-arm64-2023-dpisa-v3-15-dbcbcd867a7f@kernel.org>
 <87cyvi8kz1.wl-maz@kernel.org>
Message-ID: <08ae06c7-1654-4dfd-a789-b8e13c87d705@sirena.org.uk>

On Thu, Dec 07, 2023 at 08:39:46AM +0000, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> >  #define HCRX_GUEST_FLAGS \
> > -	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | \
> > +	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM | \

> We really should start making all of these things conditional. See
> below.

Is there an overarching theory behind how these things are intended to
work?  I agree with you that I'd have expected more conditionality here,
I was trying to fit in with the existing pattern.  It's kind of hard to
follow what the intention is, I think to some extent due to things
having evolved over time.

> > @@ -517,7 +519,6 @@ struct kvm_vcpu_arch {
> >  	enum fp_type fp_type;
> >  	unsigned int sve_max_vl;
> >  	u64 svcr;
> > -	u64 fpmr;

> Why do this change here? Why isn't done like that the first place?

It didn't seem right to add the register to struct vcpu_sysreg before it
was handled by KVM.  As referenced in the cover letter normally this
wouldn't come up because KVM doesn't rely on the host kernel for
managing register state so we add KVM support then enable the host
kernel but for FPSIMD we're reusing fpsimd_save() so we need the host
kernel support to be in place when we enable KVM.

> >  	CGT_MDCR_TDE,
> > @@ -279,6 +281,12 @@ static const struct trap_bits coarse_trap_bits[] = {
> >  		.mask		= HCR_TTLBOS,
> >  		.behaviour	= BEHAVE_FORWARD_ANY,
> >  	},
> > +	[CGT_HCRX_EnFPM] = {
> > +		.index		= HCRX_EL2,
> > +		.value		= HCRX_EL2_EnFPM,
> > +		.mask		= HCRX_EL2_EnFPM,
> > +		.behaviour	= BEHAVE_FORWARD_ANY,

> This looks wrong. HCRX_EL2.EnFPM is an enable bit.

Right, it's the wrong way round.

> > +static void *fpsimd_share_end(struct user_fpsimd_state *fpsimd)
> > +{
> > +	void *share_end = fpsimd + 1;
> > +
> > +	if (cpus_have_final_cap(ARM64_HAS_FPMR))
> > +		share_end += sizeof(u64);
> > +
> > +	return share_end;
> > +}

> This is horrible. Why can't you just have a new structure wrapping
> both user_fpsimd_state and fpmr? This is going to break in subtle
> ways, just like the SVE/SME stuff.

I agree that it's not great, the main issue was that fpsimd_state is
both already embedded in uw for hardened usercopy and very widely
referenced by exactly which struct it's in so I was taking a guess as to
what would get the least objections.  The obvious thing would be to add
FPMR to uw and share the whole thing with the hypervisor, if people
don't mind adding another field to uw I could do that?

> >  	vcpu->arch.host_fpsimd_state = kern_hyp_va(fpsimd);
> > +	if (cpus_have_final_cap(ARM64_HAS_FPMR)) {
> > +		WARN_ON_ONCE(&current->thread.fpmr + 1 != fpsimd_share_end(fpsimd));

> How can this happen?

It shouldn't, but it'd be bad if it did so I put a check in to make sure
we haven't messed up.

> > +		vcpu->arch.host_fpmr = kern_hyp_va(&current->thread.fpmr);
> > +	}

> We really need to stop piling the save/restore of stuff that isn't
> advertised to the guest.

I'm not clear what you're referencing here?  The feature is advertised
to the guest via the ID registers and in the past you've pushed back on
making things where the state is just a single register like this
optional.  Do you mean that we should be making this conditional on the
guest ID registers?  If that is the case is there a plan for how that's
supposed to work, set flags when kvm_vcpu_run_pid_change() happens for
example?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/3cbe1512/attachment.sig>

From angelogioacchino.delregno at collabora.com  Thu Dec  7 04:37:57 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 7 Dec 2023 13:37:57 +0100
Subject: [PATCH v4 2/2] mmc: mediatek: extend number of tuning steps
In-Reply-To: <20231207063535.29546-3-axe.yang@mediatek.com>
References: <20231207063535.29546-1-axe.yang@mediatek.com>
 <20231207063535.29546-3-axe.yang@mediatek.com>
Message-ID: <6c7c65a1-1398-43fc-8036-d901e8bc0934@collabora.com>

Il 07/12/23 07:35, Axe Yang ha scritto:
> Previously, during the MSDC calibration process, a full clock cycle
> actually not be covered, which in some cases didn't yield the best
> results and could cause CRC errors. This problem is particularly
> evident when MSDC is used as an SDIO host. In fact, MSDC support
> tuning up to a maximum of 64 steps, but by default, the step number
> is 32. By increase the tuning step, we are more likely to cover more
> parts of a clock cycle, and get better calibration result.
> 
> To illustrate, when tuning 32 steps, if the obtained window has a hole
> near the middle, like this: 0xffc07ff (hex), then the selected delay
> will be the 6 (counting from right to left).
> 
> (32 <- 1)
> 1111 1111 1100 0000 0000 0111 11(1)1 1111
> 
> However, if we tune 64 steps, the window obtained may look like this:
> 0xfffffffffffc07ff. The final selected delay will be 44, which is
> safer as it is further away from the hole:
> 
> (64 <- 1)
> 1111 ... (1)111 1111 1111 1111 1111 1100 0000 0000 0111 1111 1111
> 
> In this case, delay 6 selected through 32 steps tuning is obviously
> not optimal, and this delay is closer to the hole, using it would
> easily cause CRC problems.
> 
> As per mesaurements taken on mediatek SoC platform, the tuning phase
> will take:
> 	eMMC	- 32 steps: ~3ms
> 		- 64 steps: ~6ms
> 	SDIO	- 32 steps: ~4ms
> 		- 64 steos: ~7ms
> Tuning more steps won't prolong boot times by any meaningful amount
> of time, so for SD/SDIO the default tuning steps will be adjust to
> 64. But for eMMC, it is still preferred to use 32 steps tuning as
> otherwise there would be performance lose when accessing the RPMB
> partition(requiring retuning each time).
> 
> You can configure property "mediatek,tuning-step" in MSDC dts node
> to adjust the step number.
> 
> Signed-off-by: Axe Yang <axe.yang at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Thu Dec  7 04:37:58 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 7 Dec 2023 13:37:58 +0100
Subject: [PATCH v4 1/2] dt-bindings: mmc: mtk-sd: add tuning steps related
 property
In-Reply-To: <20231207063535.29546-2-axe.yang@mediatek.com>
References: <20231207063535.29546-1-axe.yang@mediatek.com>
 <20231207063535.29546-2-axe.yang@mediatek.com>
Message-ID: <8dbd5913-8448-468e-b99d-6e3820ff0c72@collabora.com>

Il 07/12/23 07:35, Axe Yang ha scritto:
> Add 'mediatek,tuning-steps' setting. This property will give MSDC
> a chance to extend tuning steps up to 64. With more tuning steps,
> MSDC may achieve a more optimal calibration result, thus avoiding
> potential CRC issues.
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Signed-off-by: Axe Yang <axe.yang at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Thu Dec  7 04:54:55 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 7 Dec 2023 13:54:55 +0100
Subject: [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free()
 error log criteria
In-Reply-To: <CAC=S1nhp3HoKGQr1UgKtZJ9SLMqvm-G_YZi9dEWWF3tj2d=OFQ@mail.gmail.com>
References: <20231113123049.4117280-1-fshao@chromium.org>
 <20231113123049.4117280-4-fshao@chromium.org>
 <6c693161-0e89-4f9d-9a92-18f3783eefd2@collabora.com>
 <CAC=S1nhp3HoKGQr1UgKtZJ9SLMqvm-G_YZi9dEWWF3tj2d=OFQ@mail.gmail.com>
Message-ID: <6046a40b-800c-4bf8-ab45-d7f1015b2d9c@collabora.com>

Il 07/12/23 12:17, Fei Shao ha scritto:
> Hi Angelo,
> 
> On Wed, Dec 6, 2023 at 6:19?PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno at collabora.com> wrote:
>>
>> Il 13/11/23 13:26, Fei Shao ha scritto:
>>> mtk_vcodec_mem_free() shouldn't print error if the target DMA buffer has
>>> never been allocated or was freed properly in the previous call. That
>>> makes log confusing.
>>>
>>> Update the error path to print log only when the caller attempts to free
>>> nonzero-size buffer with VA being NULL, which indicates something indeed
>>> went wrong.
>>>
>>> This brings another benefit that the callers no more need to check
>>> mem->va explicitly to avoid the error, which can make the code more
>>> compact and neat.
>>>
>>> Signed-off-by: Fei Shao <fshao at chromium.org>
>>
>> I think that this error is supposed to catch two issues in one:
>>    - We're called to free no memory (something that does make no sense),
>>      this may happen for example when calling xxx_free() twice, and it
>>      is a mistake that *must* be fixed;
> When I made the change, I was thinking of kfree() that doesn't warn
> against a NULL pointer.
> I imagine mtk_vcodec_mem_free() calls with NULL VA and mem size 0
> probably have the similar nuance (if the buffer exists, free it; never
> mind otherwise), but I could have missed some important differences
> specific to the MTK vcodec driver.
> 
> Looking at the mtk_vcodec_mem_free() usages, almost every one of those
> checks VA beforehand, but nothing else - they don't warn or do
> anything special when they encounter a NULL VA, and they should if
> that's a concern.
> Some even don't check at all (and I think that's why I ended up seeing
> the errors mentioned in the cover letter). As for that, I think
> there's nothing else we can fix except prepending "if (mem->va)".
> So from all this, I feel perhaps we don't need to worry much about
> those NULL VA, and we can further remove the checks (or at least move
> it into mtk_vcodec_mem_free()) to trim the lines in the driver. That's
> the reason for patch [4/4].
> 
> Not sure if that makes sense to you.

What you say does make sense - and a lot - but still, I think that freeing
a NULL VA (= freeing nothing) is something that shouldn't happen...

> 
>>    - We're failing to free memory for real (which you covered)
>>
>> ....that said, I think that if you want to clarify the error messages
>> in this function, it should look something like this:
>>
>> if (!mem->va) {
>>          mtk_v4l2_err(plat_dev, "%s: Tried to free a NULL VA", __func__);
>>          if (mem->size)
>>                  mtk_v4l2_err(plat_dev, "Failed to free %lu bytes", mem->size);
>>          return;
>> }
> Sure, I can revise the patch with this, but I also want to make sure
> if the NULL VA print needs to be an error.
> If you still think it should, I guess I'll drop the current patch
> [4/4] and instead add the check before every mtk_vcodec_mem_free()
> calls. This should also work for the issue I want to address in the
> first place.
> 

... because if you notice, some of the calls to mtk_vcodec_mem_free() are not
checked with `if (something->va)` beforehand, so I think that those are cases
in which freeing with a NULL VA would actually be an indication of something
going wrong and/or not as expected anyway (checking beforehand = error won't
get printed from mtk_vcodec_mem_free(), not checking = print error if va==NULL)

It's an easy check:
cd drivers/media/platform/mediatek/vcodec
grep -rb1 mtk_vcodec_mem_free

P.S.: h264_if, av1_req_lat :-)

That's why I think that you should drop your [4/4] - unless MediaTek comes in
stating that the missed checks are something unintended, and that every instance
of VA==NULL should print an error.

I honestly wouldn't be surprised if they did so, because anyway this occurs only
in two decoders...

Regards,
Angelo


From dmitry.baryshkov at linaro.org  Thu Dec  7 04:54:58 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu,  7 Dec 2023 15:54:58 +0300
Subject: [PATCH 1/3] iommu/msm-iommu: don't limit the driver too much
In-Reply-To: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>
References: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>
Message-ID: <20231207125500.3322229-2-dmitry.baryshkov@linaro.org>

In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
driver just to those machines. Allow it to be built for any 32-bit
Qualcomm platform (ARCH_QCOM).

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 7673bb82945b..fd67f586f010 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -178,7 +178,7 @@ config FSL_PAMU
 config MSM_IOMMU
 	bool "MSM IOMMU Support"
 	depends on ARM
-	depends on ARCH_MSM8X60 || ARCH_MSM8960 || COMPILE_TEST
+	depends on ARCH_QCOM || COMPILE_TEST
 	select IOMMU_API
 	select IOMMU_IO_PGTABLE_ARMV7S
 	help
-- 
2.39.2



From dmitry.baryshkov at linaro.org  Thu Dec  7 04:54:57 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu,  7 Dec 2023 15:54:57 +0300
Subject: [PATCH 0/3] ARM: qcom: drop 32-bit machine Kconfig entries.
Message-ID: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>

The Kconfig for 32-bit Qualcomm arch predates DT and multi-machine
support. It still defines ARCH_MSM* types for some (but not all) 32-bit
Qualcomm machines. The MSM_IOMMU driver has a strict dependency on one
of such kinds.

With the DT support in place, this has become obsolete quite a while
ago. Replace all 32-bit Qualcomm ARCH kinds with the single Kconfig
entry for the workaround required to be enabled for some of those 32-bit
platforms.

Dmitry Baryshkov (3):
  iommu/msm-iommu: don't limit the driver too much
  ARM: qcom: drop most of 32-bit ARCH_QCOM subtypes
  ARM: qcom: merge remaining subplatforms into sensible Kconfig entry

 arch/arm/Makefile          |  4 +---
 arch/arm/mach-qcom/Kconfig | 41 ++++++++------------------------------
 drivers/iommu/Kconfig      |  2 +-
 3 files changed, 10 insertions(+), 37 deletions(-)

-- 
2.39.2



From dmitry.baryshkov at linaro.org  Thu Dec  7 04:55:00 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu,  7 Dec 2023 15:55:00 +0300
Subject: [PATCH 3/3] ARM: qcom: merge remaining subplatforms into sensible Kconfig entry
In-Reply-To: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>
References: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>
Message-ID: <20231207125500.3322229-4-dmitry.baryshkov@linaro.org>

Three remaining Qualcomm platforms have special handling of the
TEXT_OFFSET to reserve the memory at the beginnig of the system RAM, see
the commit 9e775ad19f52 ("ARM: 7012/1: Set proper TEXT_OFFSET for newer
MSMs"). This is required for older platforms like IPQ40xx, MSM8x60,
MSM8960 and APQ8064 and is compatible with other 32-bit Qualcomm
platforms.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 arch/arm/Makefile          |  4 +---
 arch/arm/mach-qcom/Kconfig | 13 +++++--------
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5ba42f69f8ce..45fa8ac001c5 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -158,9 +158,7 @@ textofs-$(CONFIG_ARCH_REALTEK)  := 0x00108000
 ifeq ($(CONFIG_ARCH_SA1100),y)
 textofs-$(CONFIG_SA1111) := 0x00208000
 endif
-textofs-$(CONFIG_ARCH_IPQ40XX) := 0x00208000
-textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
-textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_ARCH_QCOM_SMEM) := 0x00208000
 textofs-$(CONFIG_ARCH_MESON) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 
diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
index 27d5ca0043be..0c99d0a746d4 100644
--- a/arch/arm/mach-qcom/Kconfig
+++ b/arch/arm/mach-qcom/Kconfig
@@ -15,13 +15,10 @@ menuconfig ARCH_QCOM
 
 if ARCH_QCOM
 
-config ARCH_IPQ40XX
-	bool "Enable support for IPQ40XX"
-
-config ARCH_MSM8X60
-	bool "Enable support for MSM8X60"
-
-config ARCH_MSM8960
-	bool "Enable support for MSM8960"
+config ARCH_QCOM_SMEM
+	bool "Reserve SMEM at the beginning of RAM"
+	help
+	  Reserve 2MB at the beginning of the System RAM for shared mem.
+	  This is required on IPQ40xx, MSM8x60 and MSM8960 platforms.
 
 endif
-- 
2.39.2



From dmitry.baryshkov at linaro.org  Thu Dec  7 04:54:59 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu,  7 Dec 2023 15:54:59 +0300
Subject: [PATCH 2/3] ARM: qcom: drop most of 32-bit ARCH_QCOM subtypes
In-Reply-To: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>
References: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>
Message-ID: <20231207125500.3322229-3-dmitry.baryshkov@linaro.org>

Historically we had several subtypes of 32-bit Qualcomm platforms.
Nowadays they became just useless symbols in Kconfig. Drop them and pull
corresponding clocksource entries towards top-level ARCH_QCOM entry.

Note, I've left ARCH_IPQ40XX, ARCH_MSM8x60 and ARCH_MSM8960 in place,
since they have special TEXT_OFFSET handling, which can be sorted out
separately.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 arch/arm/mach-qcom/Kconfig | 30 ++++--------------------------
 1 file changed, 4 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
index 12a812e61c16..27d5ca0043be 100644
--- a/arch/arm/mach-qcom/Kconfig
+++ b/arch/arm/mach-qcom/Kconfig
@@ -4,46 +4,24 @@ menuconfig ARCH_QCOM
 	depends on ARCH_MULTI_V7
 	select ARM_GIC
 	select ARM_AMBA
+	select CLKSRC_QCOM
+	select HAVE_ARM_ARCH_TIMER
 	select PINCTRL
 	select QCOM_SCM if SMP
 	help
 	  Support for Qualcomm's devicetree based systems.
+	  This includes support for a few devices with ARM64 SoC, that have
+	  ARM32 signed firmware that does not allow booting ARM64 kernels.
 
 if ARCH_QCOM
 
 config ARCH_IPQ40XX
 	bool "Enable support for IPQ40XX"
-	select CLKSRC_QCOM
-	select HAVE_ARM_ARCH_TIMER
 
 config ARCH_MSM8X60
 	bool "Enable support for MSM8X60"
-	select CLKSRC_QCOM
-
-config ARCH_MSM8909
-	bool "Enable support for MSM8909"
-	select HAVE_ARM_ARCH_TIMER
-
-config ARCH_MSM8916
-	bool "Enable support for MSM8916"
-	select HAVE_ARM_ARCH_TIMER
-	help
-	  Enable support for the Qualcomm Snapdragon 410 (MSM8916/APQ8016).
-
-	  Note that ARM64 is the main supported architecture for MSM8916.
-	  The ARM32 option is intended for a few devices with signed firmware
-	  that does not allow booting ARM64 kernels.
 
 config ARCH_MSM8960
 	bool "Enable support for MSM8960"
-	select CLKSRC_QCOM
-
-config ARCH_MSM8974
-	bool "Enable support for MSM8974"
-	select HAVE_ARM_ARCH_TIMER
-
-config ARCH_MDM9615
-	bool "Enable support for MDM9615"
-	select CLKSRC_QCOM
 
 endif
-- 
2.39.2



From angelogioacchino.delregno at collabora.com  Thu Dec  7 04:59:56 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 7 Dec 2023 13:59:56 +0100
Subject: [PATCH v3 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <CAGXv+5FhTwovv7qztGfC+FG8pb-kzZomRPgKboFYJmBTZ=mj6g@mail.gmail.com>
References: <20231204084012.2281292-1-wenst@chromium.org>
 <20231204084012.2281292-7-wenst@chromium.org>
 <ab7988af-e7f9-433d-b35e-138f79ce82c0@collabora.com>
 <CAGXv+5EyHXWgbvtxx-skzi6FNEnZD8QEHQ2Wq224anY+QKUrew@mail.gmail.com>
 <CAGXv+5H9dkYOUEDEYtDOzH9ma3wxuGMLfWy+9pE2swTFdNxOnQ@mail.gmail.com>
 <CAGXv+5FhTwovv7qztGfC+FG8pb-kzZomRPgKboFYJmBTZ=mj6g@mail.gmail.com>
Message-ID: <aaa55b65-0221-48a0-b78a-ff84f210d16b@collabora.com>

Il 07/12/23 12:28, Chen-Yu Tsai ha scritto:
> On Thu, Dec 7, 2023 at 8:23?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>>
>> On Thu, Dec 7, 2023 at 2:28?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>>>
>>> On Mon, Dec 4, 2023 at 11:27?PM AngeloGioacchino Del Regno
>>> <angelogioacchino.delregno at collabora.com> wrote:
>>>>
>>>> Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
>>>>> Tentacruel and Tentacool are MT8186 based Chromebooks based on the
>>>>> Krabby design.
>>>>>
>>>>> Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
>>>>> convertible device with touchscreen and stylus.
>>>>>
>>>>> Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
>>>>> device. It does not have a touchscreen or stylus.
>>>>>
>>>>> The two devices both have two variants. The difference is a second
>>>>> source touchpad controller that shares the same address as the original,
>>>>> but is incompatible.
>>>>>
>>>>> The extra SKU IDs for the Tentacruel devices map to different sensor
>>>>> components attached to the Embedded Controller. These are not visible
>>>>> to the main processor.
>>>>>
>>>>> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
>>>>> Acked-by: Conor Dooley <conor.dooley at microchip.com>
>>>>> ---
>>>>> Changes since v2:
>>>>> - Picked up Conor's ack
>>>>> - Rename touchpad to trackpad
>>>>> - Drop pinctrl properties from trackpad in tentacruel/tentacool second
>>>>>     source trackpad
>>>>>
>>>>> Changes since v1:
>>>>> - Reorder SKU numbers in descending order.
>>>>> - Fixed pinconfig node names
>>>>> - Moved pinctrl-* properties after interrupts-*
>>>>> - Switched to interrupts-extended for external components
>>>>> - Marked ADSP as explicitly disabled, with a comment explaining that it
>>>>>     stalls the system
>>>>> - Renamed "touchpad" to "trackpad"
>>>>> - Dropped bogus "no-laneswap" property from it6505 node
>>>>> - Moved "realtek,jd-src" property to after all the regulator supplies
>>>>> - Switched to macros for MT6366 regulator "regulator-allowed-modes"
>>>>> - Renamed "vgpu" regulator name to allow coupling, with a comment
>>>>>     containing the name used in the design
>>>>> - Renamed "cr50" node name to "tpm"
>>>>> - Moved trackpad_pins reference up to i2c2; workaround for second source
>>>>>     component resource sharing.
>>>>> - Fix copyright year
>>>>> - Fixed touchscreen supply name
>>>>>
>>>>>    arch/arm64/boot/dts/mediatek/Makefile         |    4 +
>>>>>    .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
>>>>>    .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
>>>>>    .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
>>>>>    .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
>>>>>    .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
>>>>>    .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
>>>>>    7 files changed, 2003 insertions(+)
>>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
>>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
>>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
>>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
>>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
>>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
>>>>> index e6e7592a3645..442af61b1305 100644
>>>>> --- a/arch/arm64/boot/dts/mediatek/Makefile
>>>>> +++ b/arch/arm64/boot/dts/mediatek/Makefile
>>>>> @@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
>>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
>>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
>>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
>>>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
>>>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
>>>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
>>>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
>>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
>>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
>>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
>>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
>>>>> new file mode 100644
>>>>> index 000000000000..9b2b64525961
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
>>>>> @@ -0,0 +1,129 @@
>>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>>>> +/*
>>>>> + * Copyright 2022 Google LLC
>>>>> + */
>>>>> +
>>>>> +/dts-v1/;
>>>>> +#include "mt8186-corsola.dtsi"
>>>>> +#include <dt-bindings/gpio/gpio.h>
>>>>> +
>>>>> +/ {
>>>>> +     aliases {
>>>>> +             i2c4 = &i2c4;
>>>>> +     };
>>>>> +};
>>>>> +
>>>>> +&dsi_out {
>>>>> +     remote-endpoint = <&ps8640_in>;
>>>>> +};
>>>>> +
>>>>> +&i2c0 {
>>>>> +     clock-frequency = <400000>;
>>>>> +
>>>>> +     ps8640: edp-bridge at 8 {
>>>>> +             compatible = "parade,ps8640";
>>>>> +             reg = <0x8>;
>>>>> +             powerdown-gpios = <&pio 96 GPIO_ACTIVE_LOW>;
>>>>> +             reset-gpios = <&pio 98 GPIO_ACTIVE_LOW>;
>>>>> +             pinctrl-names = "default";
>>>>> +             pinctrl-0 = <&ps8640_pins>;
>>>>> +             vdd12-supply = <&mt6366_vrf12_reg>;
>>>>> +             vdd33-supply = <&mt6366_vcn33_reg>;
>>>>> +
>>>>> +             ports {
>>>>> +                     #address-cells = <1>;
>>>>> +                     #size-cells = <0>;
>>>>> +
>>>>> +                     port at 0 {
>>>>> +                             reg = <0>;
>>>>> +
>>>>> +                             ps8640_in: endpoint {
>>>>> +                                     remote-endpoint = <&dsi_out>;
>>>>> +                             };
>>>>> +                     };
>>>>> +
>>>>> +                     port at 1 {
>>>>> +                             reg = <1>;
>>>>> +
>>>>> +                             ps8640_out: endpoint {
>>>>> +                                     remote-endpoint = <&panel_in>;
>>>>> +                             };
>>>>> +                     };
>>>>> +             };
>>>>> +
>>>>> +             aux-bus {
>>>>> +                     panel {
>>>>> +                             compatible = "edp-panel";
>>>>> +                             power-supply = <&pp3300_disp_x>;
>>>>> +                             backlight = <&backlight_lcd0>;
>>>>> +
>>>>> +                             port {
>>>>> +                                     panel_in: endpoint {
>>>>> +                                             remote-endpoint = <&ps8640_out>;
>>>>> +                                     };
>>>>> +                             };
>>>>> +                     };
>>>>> +             };
>>>>> +     };
>>>>> +};
>>>>> +
>>>>> +&i2c1 {
>>>>> +     i2c-scl-internal-delay-ns = <10000>;
>>>>> +
>>>>> +     touchscreen: touchscreen at 10 {
>>>>> +             compatible = "hid-over-i2c";
>>>>> +             reg = <0x10>;
>>>>> +             interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
>>>>> +             pinctrl-names = "default";
>>>>> +             pinctrl-0 = <&touchscreen_pins>;
>>>>> +             post-power-on-delay-ms = <10>;
>>>>> +             hid-descr-addr = <0x0001>;
>>>>> +             vdd-supply = <&pp3300_s3>;
>>>>> +     };
>>>>> +};
>>>>> +
>>>>> +&i2c4 {
>>>>> +     pinctrl-names = "default";
>>>>> +     pinctrl-0 = <&i2c4_pins>;
>>>>> +     clock-frequency = <400000>;
>>>>> +     status = "okay";
>>>>> +
>>>>> +     proximity at 28 {
>>>>> +             compatible = "semtech,sx9324";
>>>>> +             reg = <0x28>;
>>>>> +             interrupts-extended = <&pio 5 IRQ_TYPE_LEVEL_LOW>;
>>>>> +             pinctrl-names = "default";
>>>>> +             pinctrl-0 = <&sar_sensor_pins>;
>>>>> +             vdd-supply = <&mt6366_vio18_reg>;
>>>>> +             svdd-supply = <&mt6366_vio18_reg>;
>>>>> +             #io-channel-cells = <1>;
>>>>
>>>>   From the newest DTS coding style document:
>>>>
>>>> The following order of properties in device nodes is preferred:
>>>>
>>>> 1. compatible
>>>> 2. reg
>>>> 3. ranges
>>>> 4. Standard/common properties (defined by common bindings, e.g. without
>>>>      vendor-prefixes)
>>>> 5. Vendor-specific properties
>>>> 6. status (if applicable)
>>>> 7. Child nodes, where each node is preceded with a blank line
>>>>
>>>> The "status" property is by default "okay", thus it can be omitted.
>>>>
>>>> The above-described ordering follows this approach:
>>>>
>>>> 1. Most important properties start the node: compatible then bus addressing to
>>>>      match unit address.
>>>> 2. Each node will have common properties in similar place.
>>>> 3. Status is the last information to annotate that device node is or is not
>>>>      finished (board resources are needed).
>>>
>>> Wishing for a checking tool now. :p
>>>
>>>> #io-channel-cells goes after `reg` (same for the other instances) :-)
>>>
>>> Ack (though it looks weird).
>>>
>>>>> +     };
>>>>> +};
>>>>> +
>>>>> +&pio {
>>>>> +     i2c4_pins: i2c4-pins {
>>>>> +             pins-bus {
>>>>> +                     pinmux = <PINMUX_GPIO136__FUNC_SDA4>,
>>>>> +                              <PINMUX_GPIO135__FUNC_SCL4>;
>>>>> +                     bias-disable;
>>>>> +                     drive-strength = <4>;
>>>>> +                     input-enable;
>>>>> +             };
>>>>> +     };
>>>>> +
>>>>> +     ps8640_pins: ps8640-pins {
>>>>> +             pins-pwrdn-rst {
>>>>> +                     pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
>>>>> +                              <PINMUX_GPIO98__FUNC_GPIO98>;
>>>>> +                     output-low;
>>>>> +             };
>>>>> +     };
>>>>> +
>>>>> +     sar_sensor_pins: sar-sensor-pins {
>>>>> +             pins-irq {
>>>>> +                     pinmux = <PINMUX_GPIO5__FUNC_GPIO5>;
>>>>> +                     input-enable;
>>>>> +                     bias-pull-up;
>>>>> +             };
>>>>> +     };
>>>>> +};
>>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
>>>>> new file mode 100644
>>>>> index 000000000000..9bb64353ca65
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
>>>>> @@ -0,0 +1,57 @@
>>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>>>> +/*
>>>>> + * Copyright 2022 Google LLC
>>>>> + */
>>>>> +
>>>>> +/dts-v1/;
>>>>> +#include "mt8186-corsola-krabby.dtsi"
>>>>> +
>>>>> +/ {
>>>>> +     model = "Google Tentacool board";
>>>>> +     compatible = "google,tentacruel-sku327681", "google,tentacruel", "mediatek,mt8186";
>>>>> +     chassis-type = "laptop";
>>>>> +};
>>>>> +
>>>>> +/* Tentacool omits the pen. */
>>>>> +&gpio_keys {
>>>>> +     status = "disabled";
>>>>> +};
>>>>> +
>>>>> +/* Tentacool omits the touchscreen; nothing else is on i2c1. */
>>>>> +&i2c1 {
>>>>> +     status = "disabled";
>>>>> +};
>>>>> +
>>>>> +&keyboard_controller {
>>>>> +     function-row-physmap = <
>>>>> +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
>>>>> +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
>>>>> +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
>>>>> +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
>>>>> +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
>>>>> +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
>>>>> +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
>>>>> +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
>>>>> +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
>>>>> +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
>>>>> +     >;
>>>>> +
>>>>> +     linux,keymap = <
>>>>> +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
>>>>> +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
>>>>> +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
>>>>> +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
>>>>> +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
>>>>> +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
>>>>> +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
>>>>> +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
>>>>> +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
>>>>> +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
>>>>> +             CROS_STD_MAIN_KEYMAP
>>>>> +     >;
>>>>> +};
>>>>> +
>>>>> +/* Tentacool omits the touchscreen. */
>>>>> +&touchscreen {
>>>>> +     status = "disabled";
>>>>> +};
>>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
>>>>> new file mode 100644
>>>>> index 000000000000..c3ae6f9616c8
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
>>>>> @@ -0,0 +1,24 @@
>>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>>>> +/*
>>>>> + * Copyright 2023 Google LLC
>>>>> + */
>>>>> +
>>>>> +#include "mt8186-corsola-tentacool-sku327681.dts"
>>>>> +
>>>>> +/ {
>>>>> +     compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
>>>>> +};
>>>>> +
>>>>> +/* This variant replaces only the trackpad controller. */
>>>>> +&i2c2 {
>>>>> +     /delete-node/ trackpad at 15;
>>>>
>>>> Why are you deleting the trackpad at 15 node?
>>>>
>>>> You can simply override the compatible, or actually omit the compatible string
>>>> in the *.dtsi file, and set just that in each board *.dts.
>>>>
>>>> dtsi:
>>>>          trackpad_a: trackpad at 15 {
>>>>                  /* Compatible is set in each board dts */
>>>>                  reg, interrupts, others
>>>>          }
>>>>
>>>> dts:
>>>>
>>>> &trackpad_a {
>>>>          compatible = "elan,ekth3000";
>>>> };
>>>
>>> The original trackpad at 15 comes from the base design and is used for all
>>> models other than the ones with the conflicting component. Hence I believe
>>> it should live in the base .dtsi.
>>>
>>> The delete-node makes it much less likely to have any lingering properties.
>>> These are not nodes that just differ in compatible strings like DSI panels.
>>> They have incompatible bindings. For example, elan,ekth3000 uses "vcc-supply",
>>> while "hid-over-i2c" uses "vdd-supply".
>>>
>>> And going back to my previous argument, the base design used one specific
>>> model which is carried over to all the other models.
>>>
>>> Suppose I add a phandle to the original trackpad, and do
>>>
>>>      /delete-node/ &trackpad;
>>>
>>> Would that be better?
>>>
>>>> other dts:
>>>>
>>>> &trackpad_a {
>>>>          compatible = "hid-over-i2c";
>>>> };
>>>>
>>>>> +
>>>>> +     trackpad at 15 {
>>>>> +             compatible = "hid-over-i2c";
>>>>> +             reg = <0x15>;
>>>>> +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
>>>>> +             hid-descr-addr = <0x0001>;
>>>>> +             vdd-supply = <&pp3300_s3>;
>>>>> +             wakeup-source;
>>>>> +     };
>>>>> +};
>>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
>>>>> new file mode 100644
>>>>> index 000000000000..26d3451a5e47
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
>>>>> @@ -0,0 +1,44 @@
>>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>>>> +/*
>>>>> + * Copyright 2022 Google LLC
>>>>> + */
>>>>> +
>>>>> +/dts-v1/;
>>>>> +#include "mt8186-corsola-krabby.dtsi"
>>>>> +
>>>>> +/ {
>>>>> +     model = "Google Tentacruel board";
>>>>> +     compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
>>>>> +                  "google,tentacruel-sku262145", "google,tentacruel-sku262144",
>>>>> +                  "google,tentacruel", "mediatek,mt8186";
>>>>> +     chassis-type = "convertible";
>>>>> +};
>>>>> +
>>>>> +&keyboard_controller {
>>>>> +     function-row-physmap = <
>>>>> +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
>>>>> +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
>>>>> +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
>>>>> +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
>>>>> +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
>>>>> +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
>>>>> +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
>>>>> +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
>>>>> +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
>>>>> +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
>>>>> +     >;
>>>>> +
>>>>> +     linux,keymap = <
>>>>> +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
>>>>> +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
>>>>> +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
>>>>> +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
>>>>> +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
>>>>> +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
>>>>> +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
>>>>> +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
>>>>> +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
>>>>> +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
>>>>> +             CROS_STD_MAIN_KEYMAP
>>>>> +     >;
>>>>> +};
>>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
>>>>> new file mode 100644
>>>>> index 000000000000..447b57b12b41
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
>>>>> @@ -0,0 +1,26 @@
>>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>>>> +/*
>>>>> + * Copyright 2023 Google LLC
>>>>> + */
>>>>> +
>>>>> +#include "mt8186-corsola-tentacruel-sku262144.dts"
>>>>> +
>>>>> +/ {
>>>>> +     compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
>>>>> +                  "google,tentacruel-sku262149", "google,tentacruel-sku262148",
>>>>> +                  "google,tentacruel", "mediatek,mt8186";
>>>>> +};
>>>>> +
>>>>> +/* This variant replaces only the trackpad controller. */
>>>>> +&i2c2 {
>>>>> +     /delete-node/ trackpad at 15;
>>>>> +
>>>>> +     trackpad at 15 {
>>>>> +             compatible = "hid-over-i2c";
>>>>> +             reg = <0x15>;
>>>>> +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
>>>>> +             hid-descr-addr = <0x0001>;
>>>>> +             vdd-supply = <&pp3300_s3>;
>>>>> +             wakeup-source;
>>>>> +     };
>>>>> +};
>>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
>>>>> new file mode 100644
>>>>> index 000000000000..8726b2916ef1
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
>>>>> @@ -0,0 +1,1719 @@
>>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>>>> +/*
>>>>> + * Copyright (C) 2022 MediaTek Inc.
>>>>> + */
>>>>> +/dts-v1/;
>>>>> +#include "mt8186.dtsi"
>>>>> +#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
>>>>> +#include <dt-bindings/gpio/gpio.h>
>>>>> +#include <dt-bindings/input/input.h>
>>>>> +#include <dt-bindings/input/gpio-keys.h>
>>>>> +#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
>>>>> +
>>>>> +/ {
>>>>> +     aliases {
>>>>> +             i2c0 = &i2c0;
>>>>> +             i2c1 = &i2c1;
>>>>> +             i2c2 = &i2c2;
>>>>> +             i2c3 = &i2c3;
>>>>> +             i2c5 = &i2c5;
>>>>> +             mmc0 = &mmc0;
>>>>> +             mmc1 = &mmc1;
>>>>> +             serial0 = &uart0;
>>>>> +     };
>>>>> +
>>>>> +     chosen {
>>>>> +             stdout-path = "serial0:115200n8";
>>>>> +     };
>>>>> +
>>>>> +     memory at 40000000 {
>>>>> +             device_type = "memory";
>>>>> +             /* The size should be filled in by the bootloader. */
>>>>> +             reg = <0 0x40000000 0 0>;
>>>>> +     };
>>>>> +
>>>>> +     backlight_lcd0: backlight-lcd0 {
>>>>> +             compatible = "pwm-backlight";
>>>>> +             pwms = <&pwm0 0 500000>;
>>>>> +             power-supply = <&ppvar_sys>;
>>>>> +             enable-gpios = <&pio 152 0>;
>>>>> +             brightness-levels = <0 1023>;
>>>>> +             num-interpolated-steps = <1023>;
>>>>> +             default-brightness-level = <576>;
>>>>> +     };
>>>>> +
>>>>> +     btsco: bt-sco {
>>>>
>>>> Do you really need the phandle to bt-sco?
>>>
>>> No. But the sound node probably should be referencing it and the dmic
>>> node via DT instead of hardcoding the DAI and codec names in the machine
>>> driver.
>>>
>>> Anyway, will remove the label for now.
>>>
>>>> Also, this node describes a codec, so: "bt-sco-codec" please!
>>>
>>> Ack.
>>>
>>>>> +             compatible = "linux,bt-sco";
>>>>> +             #sound-dai-cells = <0>;
>>>>> +     };
>>>>> +
>>>>> +     dmic_codec: dmic-codec {
>>>>
>>>> This phandle is unused...
>>>
>>> Removed.
>>>
>>>> ..snip..
>>>>
>>>>> +
>>>>> +&adsp {
>>>>> +     memory-region = <&adsp_dma_mem>, <&adsp_mem>;
>>>>> +     status = "disabled"; /* causes stall */
>>>>
>>>> This is a firmware issue: once the correct firmware is uploaded to linux-firmware
>>>> the dsp node can get enabled... so it we make sure that this happens before this
>>>> devicetree gets picked, we can avoid a second commit enabling audio.
>>>>
>>>> After all, since we *want to* use the Xtensa DSP for audio, without it booted
>>>> sound won't work *anyway*.... so having the firmware in place can also be seen
>>>> as a direct dependency of the entire audio functionality.
>>>>
>>>> P.S.: The FW that is distributed with ChromeOS works just fine!
>>>
>>> I'll give that a try.
>>
>> I have:
>>
>> sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-5494c
>> sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
>> sof-audio-of-mt8186 10680000.adsp: unknown sof_ext_man header type 3 size 0x30
>> sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-5494c
>>
>> and it's still hanging.
> 
> Looks like I was still using the bad version due to module options...
> 
> After removing the options, I now have:
> 
> sof-audio-of-mt8186 10680000.adsp: DT DSP detected
> sof-audio-of-mt8186 10680000.adsp: assigned reserved memory node memory at 61000000
> sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-714c6
> sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
> sof-audio-of-mt8186 10680000.adsp: unknown sof_ext_man header type 3 size 0x30
> sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-714c6
> sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
> 
> But sound is still deferring probe:
> 
> # cat /sys/kernel/debug/devices_deferred
> sound    mt8186_mt6366_rt1019_rt5682s:
> mt8186_mt6366_rt1019_rt5682s_dev_probe snd_soc_register_card fail
> 

Yes, this happens because of the missing IT6505 HDMI audio support - but it's not
giving any side effect anyway... in this case, as far as DT is concerned... there
will be no change, and no side effects on working parts of the system, so we can
(imo) upstream this even if the driver-code-only dependency is not there yet.

Cheers!
Angelo

> ChenYu
> 
>> And FTR, I think sound is also blocked on the it6505 audio support series.
>>
>> ChenYu
>>
>>
>>
>>>>> +};
>>>>> +
>>>>> +&afe {
>>>>> +     i2s0-share = "I2S1";
>>>>> +     i2s3-share = "I2S2";
>>>>> +     status = "okay";
>>>>> +};
>>>>> +
>>>>
>>>> ..snip..
>>>>
>>>>> +&i2c2 {
>>>>> +     pinctrl-names = "default";
>>>>> +     /*
>>>>> +      * Trackpad pin put here to work around second source components
>>>>> +      * sharing the pinmux in steelix designs.
>>>>> +      */
>>>>> +     pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
>>>>
>>>> There's no choice for now... even if this is not beautiful to see... but it's still
>>>> ok for me because we can revisit this later when the HW Prober mechanism will be
>>>> upstreamed.
>>>
>>> Yup. Working on that.
>>>
>>>>> +     clock-frequency = <400000>;
>>>>> +     i2c-scl-internal-delay-ns = <10000>;
>>>>> +     status = "okay";
>>>>> +
>>>>> +     trackpad at 15 {
>>>>> +             compatible = "elan,ekth3000";
>>>>> +             reg = <0x15>;
>>>>> +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
>>>>> +             vcc-supply = <&pp3300_s3>;
>>>>> +             wakeup-source;
>>>>> +     };
>>>>> +};
>>>>> +
>>>>
>>>> Thanks,
>>>> Angelo
>>>
>>> Thanks for the review again.
>>>
>>> ChenYu



From robin.murphy at arm.com  Thu Dec  7 05:06:09 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 7 Dec 2023 13:06:09 +0000
Subject: [PATCH 1/3] iommu/msm-iommu: don't limit the driver too much
In-Reply-To: <20231207125500.3322229-2-dmitry.baryshkov@linaro.org>
References: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>
 <20231207125500.3322229-2-dmitry.baryshkov@linaro.org>
Message-ID: <6397268c-7990-42f6-9453-44fdc638d5c9@arm.com>

On 07/12/2023 12:54 pm, Dmitry Baryshkov wrote:
> In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
> driver just to those machines. Allow it to be built for any 32-bit
> Qualcomm platform (ARCH_QCOM).

Acked-by: Robin Murphy <robin.murphy at arm.com>

Unless Joerg disagrees, I think it should be fine if you want to take 
this via the SoC tree.

Thanks,
Robin.


> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> ---
>   drivers/iommu/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 7673bb82945b..fd67f586f010 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -178,7 +178,7 @@ config FSL_PAMU
>   config MSM_IOMMU
>   	bool "MSM IOMMU Support"
>   	depends on ARM
> -	depends on ARCH_MSM8X60 || ARCH_MSM8960 || COMPILE_TEST
> +	depends on ARCH_QCOM || COMPILE_TEST
>   	select IOMMU_API
>   	select IOMMU_IO_PGTABLE_ARMV7S
>   	help


From nm at ti.com  Thu Dec  7 05:18:18 2023
From: nm at ti.com (Nishanth Menon)
Date: Thu, 7 Dec 2023 07:18:18 -0600
Subject: [PATCH 2/3] arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet
 support
In-Reply-To: <20231207081917.340167-3-danishanwar@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-3-danishanwar@ti.com>
Message-ID: <20231207131818.3n7z64ve6izatlvs@unchanged>

On 13:49-20231207, MD Danish Anwar wrote:
> ICSSG1 provides dual Gigabit Ethernet support with proper FW loaded.
> 
> The ICSSG1 MII0 (RGMII1) has DP83869 PHY attached to it. The ICSSG1 shares
> MII1 (RGMII2) PHY DP83869 with CPSW3g and it's assigned by default to
> CPSW3g. The MDIO access to MII1 (RGMII2) PHY DP83869 is controlled by MDIO
> bus switch and also assigned to CPSW3g. Therefore the ICSSG1 MII1 (RGMII2)
> port is kept disable and ICSSG1 is enabled in single MAC mode by
> default.
> 
> Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
> ---
>  arch/arm64/boot/dts/ti/k3-am642-evm.dts | 105 ++++++++++++++++++++++++
>  1 file changed, 105 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> index 8c5651d2cf5d..04d1c0602d31 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> @@ -34,6 +34,11 @@ aliases {
>  		ethernet1 = &cpsw_port2;
>  	};
>  
> +	aliases {
> +		ethernet2 = &icssg1_emac0;
> +		ethernet3 = &icssg1_emac1;
> +	};

Why another aliases section?

> +
>  	memory at 80000000 {
>  		bootph-all;
>  		device_type = "memory";
> @@ -229,6 +234,70 @@ transceiver2: can-phy1 {
>  		max-bitrate = <5000000>;
>  		standby-gpios = <&exp1 9 GPIO_ACTIVE_HIGH>;
>  	};
> +
> +	icssg1_eth: icssg1-eth {
> +		compatible = "ti,am642-icssg-prueth";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&icssg1_rgmii1_pins_default>;
> +
> +		sram = <&oc_sram>;
> +		ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
> +		firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
> +				"ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
> +				"ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
> +				"ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
> +				"ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
> +				"ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";

Umm... am65x??? is that a typo? I'd rather keep it am64x here and drop
that sr2 thing. Tomorrow there will be a custom bug on am64 and then we
will have to respin this again.

> +
> +		ti,pruss-gp-mux-sel = <2>,	/* MII mode */
> +				      <2>,
> +				      <2>,
> +				      <2>,	/* MII mode */
> +				      <2>,
> +				      <2>;
> +
> +		ti,mii-g-rt = <&icssg1_mii_g_rt>;
> +		ti,mii-rt = <&icssg1_mii_rt>;
> +		ti,iep = <&icssg1_iep0>,  <&icssg1_iep1>;
> +
> +		interrupt-parent = <&icssg1_intc>;
> +		interrupts = <24 0 2>, <25 1 3>;
> +		interrupt-names = "tx_ts0", "tx_ts1";
> +
> +		dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
> +		       <&main_pktdma 0xc201 15>, /* egress slice 0 */
> +		       <&main_pktdma 0xc202 15>, /* egress slice 0 */
> +		       <&main_pktdma 0xc203 15>, /* egress slice 0 */
> +		       <&main_pktdma 0xc204 15>, /* egress slice 1 */
> +		       <&main_pktdma 0xc205 15>, /* egress slice 1 */
> +		       <&main_pktdma 0xc206 15>, /* egress slice 1 */
> +		       <&main_pktdma 0xc207 15>, /* egress slice 1 */
> +		       <&main_pktdma 0x4200 15>, /* ingress slice 0 */
> +		       <&main_pktdma 0x4201 15>; /* ingress slice 1 */
> +		dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
> +			    "tx1-0", "tx1-1", "tx1-2", "tx1-3",
> +			    "rx0", "rx1";
> +
> +		ethernet-ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			icssg1_emac0: port at 0 {
> +				reg = <0>;
> +				phy-handle = <&icssg1_phy1>;
> +				phy-mode = "rgmii-id";
> +				ti,syscon-rgmii-delay = <&main_conf 0x4110>;
> +				/* Filled in by bootloader */
> +				local-mac-address = [00 00 00 00 00 00];
> +			};
> +			icssg1_emac1: port at 1 {
> +				reg = <1>;
> +				ti,syscon-rgmii-delay = <&main_conf 0x4114>;
> +				/* Filled in by bootloader */
> +				local-mac-address = [00 00 00 00 00 00];
> +				status = "disabled";
> +			};
> +		};
> +	};
>  };
>  
>  &main_pmx0 {
> @@ -383,6 +452,30 @@ ddr_vtt_pins_default: ddr-vtt-default-pins {
>  			AM64X_IOPAD(0x0030, PIN_OUTPUT_PULLUP, 7) /* (L18) OSPI0_CSN1.GPIO0_12 */
>  		>;
>  	};
> +
> +	icssg1_mdio1_pins_default: icssg1-mdio1-default-pins {
> +		pinctrl-single,pins = <
> +			AM64X_IOPAD(0x015c, PIN_OUTPUT, 0) /* (Y6) PRG1_MDIO0_MDC */
> +			AM64X_IOPAD(0x0158, PIN_INPUT, 0) /* (AA6) PRG1_MDIO0_MDIO */
> +		>;
> +	};
> +
> +	icssg1_rgmii1_pins_default: icssg1-rgmii1-default-pins{
> +		pinctrl-single,pins = <
> +			AM64X_IOPAD(0x00b8, PIN_INPUT, 2) /* (Y7) PRG1_PRU0_GPO0.PRG1_RGMII1_RD0 */
> +			AM64X_IOPAD(0x00bc, PIN_INPUT, 2) /* (U8) PRG1_PRU0_GPO1.PRG1_RGMII1_RD1 */
> +			AM64X_IOPAD(0x00c0, PIN_INPUT, 2) /* (W8) PRG1_PRU0_GPO2.PRG1_RGMII1_RD2 */
> +			AM64X_IOPAD(0x00c4, PIN_INPUT, 2) /* (V8) PRG1_PRU0_GPO3.PRG1_RGMII1_RD3 */
> +			AM64X_IOPAD(0x00d0, PIN_INPUT, 2) /* (AA7) PRG1_PRU0_GPO6.PRG1_RGMII1_RXC */
> +			AM64X_IOPAD(0x00c8, PIN_INPUT, 2) /* (Y8) PRG1_PRU0_GPO4.PRG1_RGMII1_RX_CTL */
> +			AM64X_IOPAD(0x00e4, PIN_INPUT, 2) /* (AA8) PRG1_PRU0_GPO11.PRG1_RGMII1_TD0 */
> +			AM64X_IOPAD(0x00e8, PIN_INPUT, 2) /* (U9) PRG1_PRU0_GPO12.PRG1_RGMII1_TD1 */
> +			AM64X_IOPAD(0x00ec, PIN_INPUT, 2) /* (W9) PRG1_PRU0_GPO13.PRG1_RGMII1_TD2 */
> +			AM64X_IOPAD(0x00f0, PIN_INPUT, 2) /* (AA9) PRG1_PRU0_GPO14.PRG1_RGMII1_TD3 */
> +			AM64X_IOPAD(0x00f8, PIN_INPUT, 2) /* (V9) PRG1_PRU0_GPO16.PRG1_RGMII1_TXC */
> +			AM64X_IOPAD(0x00f4, PIN_INPUT, 2) /* (Y9) PRG1_PRU0_GPO15.PRG1_RGMII1_TX_CTL */
> +		>;
> +	};
>  };
>  
>  &main_uart0 {
> @@ -731,3 +824,15 @@ &main_mcan1 {
>  	pinctrl-0 = <&main_mcan1_pins_default>;
>  	phys = <&transceiver2>;
>  };
> +
> +&icssg1_mdio {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&icssg1_mdio1_pins_default>;
> +
> +	icssg1_phy1: ethernet-phy at 0 {
> +		reg = <0xf>;
> +		tx-internal-delay-ps = <250>;
> +		rx-internal-delay-ps = <2000>;
> +	};
> +};
> -- 
> 2.34.1
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From andriy.shevchenko at linux.intel.com  Thu Dec  7 05:14:14 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu, 7 Dec 2023 15:14:14 +0200
Subject: [PATCH v4 00/23] pinctrl: Convert struct group_desc to use
 struct pingroup
In-Reply-To: <CACRpkdaDDJfDznGZE1OGNt0Rc6Wbh0-0suu6PgL+veJea9rBRQ@mail.gmail.com>
References: <20231129161459.1002323-1-andriy.shevchenko@linux.intel.com>
 <CACRpkdZhpXcx2FZYKM69j3x4dP5Nu-=3sXW+BQAw3k6c5aRrWw@mail.gmail.com>
 <ZW3m-KDhs39i0E5n@smile.fi.intel.com>
 <CACRpkdaDDJfDznGZE1OGNt0Rc6Wbh0-0suu6PgL+veJea9rBRQ@mail.gmail.com>
Message-ID: <ZXHFJgs5y4RxhtBf@smile.fi.intel.com>

On Thu, Dec 07, 2023 at 10:50:29AM +0100, Linus Walleij wrote:
> On Mon, Dec 4, 2023 at 3:49?PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Mon, Dec 04, 2023 at 03:38:43PM +0100, Linus Walleij wrote:

...

> > > >   pinctrl: core: Make pins const unsigned int pointer in struct
> > > >     group_desc
> > > >   pinctrl: equilibrium: Convert to use struct pingroup
> > > >   pinctrl: keembay: Convert to use struct pingroup
> > > >   pinctrl: nuvoton: Convert to use struct pingroup and
> > > >     PINCTRL_PINGROUP()
> >
> > Hmm... Why these to be dropped?
> 
> I couldn't tell apart which ones could cross depend on the others,
> simple as that...

No problem as I have noticed a warning which had been fixed in a separate
series I sent earlier and which you already applied today. Thanks!

-- 
With Best Regards,
Andy Shevchenko




From nm at ti.com  Thu Dec  7 05:27:58 2023
From: nm at ti.com (Nishanth Menon)
Date: Thu, 7 Dec 2023 07:27:58 -0600
Subject: [PATCH 3/3] arm64: dts: ti: k3-am642-evm: add overlay for icssg1
 2nd port
In-Reply-To: <20231207081917.340167-4-danishanwar@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-4-danishanwar@ti.com>
Message-ID: <20231207132758.wbfn7timsqevdjpu@mortuary>

On 13:49-20231207, MD Danish Anwar wrote:
> The am642-evm doesn't allow to enable 2 x CPSW3g ports and 2 x ICSSG1 ports
> all together, so base k3-am642-evm.dts enables by default 2 x CPSW3g ports
> and 1 x ICSSG1 ports, but it also possible to support 1 x CPSW3g ports and
> 2 x ICSSG1 ports configuration.
> 
> This patch adds overlay to support 1 x CPSW3g ports and 2 x ICSSG1 ports
> configuration:
> - disable 2nd CPSW3g port
> - update CPSW3g pinmuxes to not use RGMII2
> - disable mdio-mux-1 and define mdio-mux-2 to route ICSSG1 MDIO to the
>   shared DP83869 PHY
> - add and enable ICSSG1 RGMII2 pinmuxes
> - enable ICSSG1 MII1 port
> 
> Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
> ---
>  arch/arm64/boot/dts/ti/Makefile               |  2 +
>  .../dts/ti/k3-am642-evm-icssg1-dualemac.dtso  | 80 +++++++++++++++++++
>  arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  2 +-
>  3 files changed, 83 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
> 
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 5ef49b02c71f..99a4dce47f02 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -35,12 +35,14 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62x-sk-csi2-imx219.dtbo
>  dtb-$(CONFIG_ARCH_K3) += k3-am62x-sk-hdmi-audio.dtbo
>  
>  # Boards with AM64x SoC
> +k3-am642-evm-icssg1-dtbs := k3-am642-evm.dtb k3-am642-evm-icssg1-dualemac.dtbo

Why not handle this for CONFIG_OF_ALL_DTBS alone? See commit
b0044823a6607e535fdb083c89f487fbf183b171

>  dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
>  dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
> +dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-icssg1.dtb
>  
>  # Boards with AM65x SoC
>  k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb k3-am654-base-board-rocktech-rk101-panel.dtbo
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
> new file mode 100644
> index 000000000000..6f33290c1ad6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
> @@ -0,0 +1,80 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/**
> + * DT overlay for enabling 2nd ICSSG1 port on AM642 EVM
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include "k3-pinctrl.h"
> +
> +&{/} {
> +	aliases {
> +		ethernet1 = "/icssg1-eth/ethernet-ports/port at 0";
> +		ethernet2 = "/icssg1-eth/ethernet-ports/port at 1";

I don't understand what you are overriding here. isn't patch #2 in your
series already introducing this in the base dts?

> +	};
> +
> +	mdio-mux-2 {
> +		compatible = "mdio-mux-multiplexer";
> +		mux-controls = <&mdio_mux>;
> +		mdio-parent-bus = <&icssg1_mdio>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		mdio at 0 {
> +			reg = <0x0>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			icssg1_phy2: ethernet-phy at 3 {
> +				reg = <3>;
> +				tx-internal-delay-ps = <250>;
> +				rx-internal-delay-ps = <2000>;
> +			};
> +		};
> +	};
> +};
> +
> +&main_pmx0 {
> +	icssg1_rgmii2_pins_default: icssg1-rgmii2-default-pins {
> +		pinctrl-single,pins = <
> +			AM64X_IOPAD(0x0108, PIN_INPUT, 2) /* (W11) PRG1_PRU1_GPO0.RGMII2_RD0 */
> +			AM64X_IOPAD(0x010c, PIN_INPUT, 2) /* (V11) PRG1_PRU1_GPO1.RGMII2_RD1 */
> +			AM64X_IOPAD(0x0110, PIN_INPUT, 2) /* (AA12) PRG1_PRU1_GPO2.RGMII2_RD2 */
> +			AM64X_IOPAD(0x0114, PIN_INPUT, 2) /* (Y12) PRG1_PRU1_GPO3.RGMII2_RD3 */
> +			AM64X_IOPAD(0x0120, PIN_INPUT, 2) /* (U11) PRG1_PRU1_GPO6.RGMII2_RXC */
> +			AM64X_IOPAD(0x0118, PIN_INPUT, 2) /* (W12) PRG1_PRU1_GPO4.RGMII2_RX_CTL */
> +			AM64X_IOPAD(0x0134, PIN_OUTPUT, 2) /* (AA10) PRG1_PRU1_GPO11.RGMII2_TD0 */
> +			AM64X_IOPAD(0x0138, PIN_OUTPUT, 2) /* (V10) PRG1_PRU1_GPO12.RGMII2_TD1 */
> +			AM64X_IOPAD(0x013c, PIN_OUTPUT, 2) /* (U10) PRG1_PRU1_GPO13.RGMII2_TD2 */
> +			AM64X_IOPAD(0x0140, PIN_OUTPUT, 2) /* (AA11) PRG1_PRU1_GPO14.RGMII2_TD3 */
> +			AM64X_IOPAD(0x0148, PIN_OUTPUT, 2) /* (Y10) PRG1_PRU1_GPO16.RGMII2_TXC */
> +			AM64X_IOPAD(0x0144, PIN_OUTPUT, 2) /* (Y11) PRG1_PRU1_GPO15.RGMII2_TX_CTL */
> +		>;
> +	};
> +};
> +
> +&cpsw3g {
> +	pinctrl-0 = <&rgmii1_pins_default>;
> +};
> +
> +&cpsw_port2 {
> +	status = "disabled";
> +};
> +
> +&mdio_mux_1 {
> +	status = "disabled";
> +};
> +
> +&icssg1_eth {
> +	pinctrl-0 = <&icssg1_rgmii1_pins_default &icssg1_rgmii2_pins_default>;

Grrr... No! I have been cleaning up after you folks and you folks should
take notice.

pinctrl-0 = <&icssg1_rgmii1_pins_default>, <&icssg1_rgmii2_pins_default>;


> +};
> +
> +&icssg1_emac1 {
> +	status = "okay";
> +	phy-handle = <&icssg1_phy2>;
> +	phy-mode = "rgmii-id";
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> index 04d1c0602d31..90867090e725 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> @@ -203,7 +203,7 @@ mdio_mux: mux-controller {
>  		mux-gpios = <&exp1 12 GPIO_ACTIVE_HIGH>;
>  	};
>  
> -	mdio-mux-1 {
> +	mdio_mux_1: mdio-mux-1 {

Commit message doesn't warn me for this change.
>  		compatible = "mdio-mux-multiplexer";
>  		mux-controls = <&mdio_mux>;
>  		mdio-parent-bus = <&cpsw3g_mdio>;
> -- 
> 2.34.1
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From david at redhat.com  Thu Dec  7 05:28:36 2023
From: david at redhat.com (David Hildenbrand)
Date: Thu, 7 Dec 2023 14:28:36 +0100
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <126c3b71-1acc-4851-9986-4228cb8a8660@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
 <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
 <ca649aad-7b76-4c6d-b513-26b3d58f8e68@redhat.com>
 <126c3b71-1acc-4851-9986-4228cb8a8660@arm.com>
Message-ID: <94806b4f-2370-4999-9586-2c936955cb87@redhat.com>

>>
>> Right, but you know from the first loop which order is applicable (and will be
>> fed to the second loop) and could just pte_unmap(pte) + tryalloc. If that fails,
>> remap and try with the next orders.
> 
> You mean something like this?
> 
> 	pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
> 	if (!pte)
> 		return ERR_PTR(-EAGAIN);
> 
> 	order = highest_order(orders);
> 	while (orders) {
> 		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> 		if (!pte_range_none(pte + pte_index(addr), 1 << order)) {
> 			order = next_order(&orders, order);
> 			continue;
> 		}
> 
> 		pte_unmap(pte);
> 		
> 		folio = vma_alloc_folio(gfp, order, vma, addr, true);
> 		if (folio) {
> 			clear_huge_page(&folio->page, vmf->address, 1 << order);
> 			return folio;
> 		}
> 
> 		pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
> 		if (!pte)
> 			return ERR_PTR(-EAGAIN);
> 
> 		order = next_order(&orders, order);
> 	}
> 
> 	pte_unmap(pte);
> 
> I don't really like that because if high order folio allocations fail, then you
> are calling pte_range_none() again for the next lower order; once that check has
> succeeded for an order it shouldn't be required for any lower orders. In this
> case you also have lots of pte map/unmap.

I see what you mean.

> 
> The original version feels more efficient to me.
Yes it is. Adding in some comments might help, like

/*
  * Find the largest order where the aligned range is completely prot_none(). Note
  * that all remaining orders will be completely prot_none().
  */
...

/* Try allocating the largest of the remaining orders. */

> 
>>
>> That would make the code certainly easier to understand. That "orders" magic of
>> constructing, filtering, walking is confusing :)
>>
>>
>> I might find some time today to see if there is an easy way to cleanup all what
>> I spelled out above. It really is a mess. But likely that cleanup could be
>> deferred (but you're touching it, so ... :) ).
> 
> I'm going to ignore the last 5 words. I heard the "that cleanup could be
> deferred" part loud and clear though :)

:)

If we could stop passing orders into thp_vma_allowable_orders(), that would probably
be the biggest win. It's just all a confusing mess.

-- 
Cheers,

David / dhildenb



From a0501179 at ti.com  Thu Dec  7 05:28:37 2023
From: a0501179 at ti.com (Anwar, Md Danish)
Date: Thu, 7 Dec 2023 18:58:37 +0530
Subject: [PATCH 2/3] arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet
 support
In-Reply-To: <20231207131818.3n7z64ve6izatlvs@unchanged>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-3-danishanwar@ti.com>
 <20231207131818.3n7z64ve6izatlvs@unchanged>
Message-ID: <f83f21c0-3f5f-4069-abab-2b47e371d3bd@ti.com>

On 12/7/2023 6:48 PM, Nishanth Menon wrote:
> On 13:49-20231207, MD Danish Anwar wrote:
>> ICSSG1 provides dual Gigabit Ethernet support with proper FW loaded.
>>
>> The ICSSG1 MII0 (RGMII1) has DP83869 PHY attached to it. The ICSSG1 shares
>> MII1 (RGMII2) PHY DP83869 with CPSW3g and it's assigned by default to
>> CPSW3g. The MDIO access to MII1 (RGMII2) PHY DP83869 is controlled by MDIO
>> bus switch and also assigned to CPSW3g. Therefore the ICSSG1 MII1 (RGMII2)
>> port is kept disable and ICSSG1 is enabled in single MAC mode by
>> default.
>>
>> Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
>> ---
>>  arch/arm64/boot/dts/ti/k3-am642-evm.dts | 105 ++++++++++++++++++++++++
>>  1 file changed, 105 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> index 8c5651d2cf5d..04d1c0602d31 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> @@ -34,6 +34,11 @@ aliases {
>>  		ethernet1 = &cpsw_port2;
>>  	};
>>  
>> +	aliases {
>> +		ethernet2 = &icssg1_emac0;
>> +		ethernet3 = &icssg1_emac1;
>> +	};
> 
> Why another aliases section?
> 

Sorry, My bad. I had created these patches a while back when there was
no alias section in this dts file, and applied them directly here. I
didn't notice the already existing alias section. I will remove this
aliases section and move these two aliases two the above section in v2.

>> +
>>  	memory at 80000000 {
>>  		bootph-all;
>>  		device_type = "memory";
>> @@ -229,6 +234,70 @@ transceiver2: can-phy1 {
>>  		max-bitrate = <5000000>;
>>  		standby-gpios = <&exp1 9 GPIO_ACTIVE_HIGH>;
>>  	};
>> +
>> +	icssg1_eth: icssg1-eth {
>> +		compatible = "ti,am642-icssg-prueth";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&icssg1_rgmii1_pins_default>;
>> +
>> +		sram = <&oc_sram>;
>> +		ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
>> +		firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
>> +				"ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
>> +				"ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
>> +				"ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
>> +				"ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
>> +				"ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
> 
> Umm... am65x??? is that a typo? I'd rather keep it am64x here and drop
> that sr2 thing. Tomorrow there will be a custom bug on am64 and then we
> will have to respin this again.
> 

No Nishant, this is not a typo. Both AM64x and AM65x use the same ICSSG
firmwares. We only have am65x-sr2-* firmwares and they are used by both
AM64x and AM65x and that is why I have kept the firmware-name here in dt
same as the files that we load on the pru cores.

>> +
>> +		ti,pruss-gp-mux-sel = <2>,	/* MII mode */
>> +				      <2>,
>> +				      <2>,
>> +				      <2>,	/* MII mode */
>> +				      <2>,
>> +				      <2>;
>> +
>> +		ti,mii-g-rt = <&icssg1_mii_g_rt>;
>> +		ti,mii-rt = <&icssg1_mii_rt>;
>> +		ti,iep = <&icssg1_iep0>,  <&icssg1_iep1>;
>> +
>> +		interrupt-parent = <&icssg1_intc>;
>> +		interrupts = <24 0 2>, <25 1 3>;
>> +		interrupt-names = "tx_ts0", "tx_ts1";
>> +
>> +		dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
>> +		       <&main_pktdma 0xc201 15>, /* egress slice 0 */
>> +		       <&main_pktdma 0xc202 15>, /* egress slice 0 */
>> +		       <&main_pktdma 0xc203 15>, /* egress slice 0 */
>> +		       <&main_pktdma 0xc204 15>, /* egress slice 1 */
>> +		       <&main_pktdma 0xc205 15>, /* egress slice 1 */
>> +		       <&main_pktdma 0xc206 15>, /* egress slice 1 */
>> +		       <&main_pktdma 0xc207 15>, /* egress slice 1 */
>> +		       <&main_pktdma 0x4200 15>, /* ingress slice 0 */
>> +		       <&main_pktdma 0x4201 15>; /* ingress slice 1 */
>> +		dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
>> +			    "tx1-0", "tx1-1", "tx1-2", "tx1-3",
>> +			    "rx0", "rx1";
>> +
>> +		ethernet-ports {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			icssg1_emac0: port at 0 {
>> +				reg = <0>;
>> +				phy-handle = <&icssg1_phy1>;
>> +				phy-mode = "rgmii-id";
>> +				ti,syscon-rgmii-delay = <&main_conf 0x4110>;
>> +				/* Filled in by bootloader */
>> +				local-mac-address = [00 00 00 00 00 00];
>> +			};
>> +			icssg1_emac1: port at 1 {
>> +				reg = <1>;
>> +				ti,syscon-rgmii-delay = <&main_conf 0x4114>;
>> +				/* Filled in by bootloader */
>> +				local-mac-address = [00 00 00 00 00 00];
>> +				status = "disabled";
>> +			};
>> +		};
>> +	};
>>  };
>>  
>>  &main_pmx0 {
>> @@ -383,6 +452,30 @@ ddr_vtt_pins_default: ddr-vtt-default-pins {
>>  			AM64X_IOPAD(0x0030, PIN_OUTPUT_PULLUP, 7) /* (L18) OSPI0_CSN1.GPIO0_12 */
>>  		>;
>>  	};
>> +
>> +	icssg1_mdio1_pins_default: icssg1-mdio1-default-pins {
>> +		pinctrl-single,pins = <
>> +			AM64X_IOPAD(0x015c, PIN_OUTPUT, 0) /* (Y6) PRG1_MDIO0_MDC */
>> +			AM64X_IOPAD(0x0158, PIN_INPUT, 0) /* (AA6) PRG1_MDIO0_MDIO */
>> +		>;
>> +	};
>> +
>> +	icssg1_rgmii1_pins_default: icssg1-rgmii1-default-pins{
>> +		pinctrl-single,pins = <
>> +			AM64X_IOPAD(0x00b8, PIN_INPUT, 2) /* (Y7) PRG1_PRU0_GPO0.PRG1_RGMII1_RD0 */
>> +			AM64X_IOPAD(0x00bc, PIN_INPUT, 2) /* (U8) PRG1_PRU0_GPO1.PRG1_RGMII1_RD1 */
>> +			AM64X_IOPAD(0x00c0, PIN_INPUT, 2) /* (W8) PRG1_PRU0_GPO2.PRG1_RGMII1_RD2 */
>> +			AM64X_IOPAD(0x00c4, PIN_INPUT, 2) /* (V8) PRG1_PRU0_GPO3.PRG1_RGMII1_RD3 */
>> +			AM64X_IOPAD(0x00d0, PIN_INPUT, 2) /* (AA7) PRG1_PRU0_GPO6.PRG1_RGMII1_RXC */
>> +			AM64X_IOPAD(0x00c8, PIN_INPUT, 2) /* (Y8) PRG1_PRU0_GPO4.PRG1_RGMII1_RX_CTL */
>> +			AM64X_IOPAD(0x00e4, PIN_INPUT, 2) /* (AA8) PRG1_PRU0_GPO11.PRG1_RGMII1_TD0 */
>> +			AM64X_IOPAD(0x00e8, PIN_INPUT, 2) /* (U9) PRG1_PRU0_GPO12.PRG1_RGMII1_TD1 */
>> +			AM64X_IOPAD(0x00ec, PIN_INPUT, 2) /* (W9) PRG1_PRU0_GPO13.PRG1_RGMII1_TD2 */
>> +			AM64X_IOPAD(0x00f0, PIN_INPUT, 2) /* (AA9) PRG1_PRU0_GPO14.PRG1_RGMII1_TD3 */
>> +			AM64X_IOPAD(0x00f8, PIN_INPUT, 2) /* (V9) PRG1_PRU0_GPO16.PRG1_RGMII1_TXC */
>> +			AM64X_IOPAD(0x00f4, PIN_INPUT, 2) /* (Y9) PRG1_PRU0_GPO15.PRG1_RGMII1_TX_CTL */
>> +		>;
>> +	};
>>  };
>>  
>>  &main_uart0 {
>> @@ -731,3 +824,15 @@ &main_mcan1 {
>>  	pinctrl-0 = <&main_mcan1_pins_default>;
>>  	phys = <&transceiver2>;
>>  };
>> +
>> +&icssg1_mdio {
>> +	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&icssg1_mdio1_pins_default>;
>> +
>> +	icssg1_phy1: ethernet-phy at 0 {
>> +		reg = <0xf>;
>> +		tx-internal-delay-ps = <250>;
>> +		rx-internal-delay-ps = <2000>;
>> +	};
>> +};
>> -- 
>> 2.34.1
>>
> 

-- 
Thanks and Regards,
Md Danish Anwar


From ahalaney at redhat.com  Thu Dec  7 05:32:29 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Thu, 7 Dec 2023 07:32:29 -0600
Subject: [PATCH net-next v2] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <o3abmn7ocuksmjg23rrgsib7nfm4yo5rtzlqw2np2pplg73drd@7qe4vrsx2gyc>
References: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
 <o3abmn7ocuksmjg23rrgsib7nfm4yo5rtzlqw2np2pplg73drd@7qe4vrsx2gyc>
Message-ID: <vmjpuli2l6r7awtiwip6hbgmc4m7hgtbyoqi3z4rhb5chfoiu4@5ebw7tepe6mp>

On Thu, Dec 07, 2023 at 02:56:25PM +0300, Serge Semin wrote:
> Hi Andrew
> 
> On Wed, Dec 06, 2023 at 05:46:09PM -0600, Andrew Halaney wrote:
> > The stmmac_dt_phy() function, which parses the devicetree node of the
> > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > fixed-link means in relation to the MAC's MDIO bus. This results in
> > a MDIO bus being created in situations it need not be.
> > 
> > Currently a MDIO bus is created if the description is either:
> > 
> >     1. Not fixed-link
> >     2. fixed-link but contains a MDIO bus as well
> > 
> > The "1" case above isn't always accurate. If there's a phy-handle,
> > it could be referencing a phy on another MDIO controller's bus[1]. In
> > this case currently the MAC will make a MDIO bus and scan it all
> > anyways unnecessarily.
> > 
> > There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> > be created and scanned for a phy. This case can also be inferred from
> > the platform description by not having a phy-handle && not being
> > fixed-link. This hits case "1" in the current driver's logic.
> > 
> > Let's improve the logic to create a MDIO bus if either:
> > 
> >     - Devicetree contains a MDIO bus
> >     - !fixed-link && !phy-handle (legacy handling)
> > 
> > Below upstream devicetree snippets can be found that explain some of
> > the cases above more concretely.
> > 
> > Here's[0] a devicetree example where the MAC is both fixed-link and
> > driving a switch on MDIO (case "2" above). This needs a MDIO bus to
> > be created:
> > 
> >     &fec1 {
> >             phy-mode = "rmii";
> > 
> >             fixed-link {
> >                     speed = <100>;
> >                     full-duplex;
> >             };
> > 
> >             mdio1: mdio {
> >                     switch0: switch0 at 0 {
> >                             compatible = "marvell,mv88e6190";
> >                             pinctrl-0 = <&pinctrl_gpio_switch0>;
> >                     };
> >             };
> >     };
> > 
> > Here's[1] an example where there is no MDIO bus or fixed-link for
> > the ethernet1 MAC, so no MDIO bus should be created since ethernet0
> > is the MDIO master for ethernet1's phy:
> > 
> >     &ethernet0 {
> >             phy-mode = "sgmii";
> >             phy-handle = <&sgmii_phy0>;
> > 
> >             mdio {
> >                     compatible = "snps,dwmac-mdio";
> >                     sgmii_phy0: phy at 8 {
> >                             compatible = "ethernet-phy-id0141.0dd4";
> >                             reg = <0x8>;
> >                             device_type = "ethernet-phy";
> >                     };
> > 
> >                     sgmii_phy1: phy at a {
> >                             compatible = "ethernet-phy-id0141.0dd4";
> >                             reg = <0xa>;
> >                             device_type = "ethernet-phy";
> >                     };
> >             };
> >     };
> > 
> >     &ethernet1 {
> >             phy-mode = "sgmii";
> >             phy-handle = <&sgmii_phy1>;
> >     };
> > 
> > Finally there's descriptions like this[2] which don't describe the
> > MDIO bus but expect it to be created and the whole address space
> > scanned for a phy since there's no phy-handle or fixed-link described:
> > 
> >     &gmac {
> >             phy-supply = <&vcc_lan>;
> >             phy-mode = "rmii";
> >             snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
> >             snps,reset-active-low;
> >             snps,reset-delays-us = <0 10000 1000000>;
> >     };
> > 
> > [0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts
> > [1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
> > [2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164
> 
> Thank you for the patch. Please find a comment below.
> 
> > 
> > Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> > Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
> > ---
> >  .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 85 ++++++++++------------
> >  1 file changed, 37 insertions(+), 48 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > index 1ffde555da47..7da461fe93f6 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > @@ -296,69 +296,39 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
> >  }
> >  
> >  /**
> > - * stmmac_dt_phy - parse device-tree driver parameters to allocate PHY resources
> > - * @plat: driver data platform structure
> > - * @np: device tree node
> > - * @dev: device pointer
> > - * Description:
> > - * The mdio bus will be allocated in case of a phy transceiver is on board;
> > - * it will be NULL if the fixed-link is configured.
> > - * If there is the "snps,dwmac-mdio" sub-node the mdio will be allocated
> > - * in any case (for DSA, mdio must be registered even if fixed-link).
> > - * The table below sums the supported configurations:
> > - *	-------------------------------
> > - *	snps,phy-addr	|     Y
> > - *	-------------------------------
> > - *	phy-handle	|     Y
> > - *	-------------------------------
> > - *	fixed-link	|     N
> > - *	-------------------------------
> > - *	snps,dwmac-mdio	|
> > - *	  even if	|     Y
> > - *	fixed-link	|
> > - *	-------------------------------
> > + * stmmac_of_get_mdio() - Gets the MDIO bus from the devicetree
> > + * @np: devicetree node
> >   *
> > - * It returns 0 in case of success otherwise -ENODEV.
> > + * The MDIO bus will be searched for in the following ways:
> > + * 1. The compatible is "snps,dwc-qos-ethernet-4.10" && a "mdio" named
> > + *    child node exists
> > + * 2. A child node with the "snps,dwmac-mdio" compatible is present
> > + *
> > + * Return: The MDIO node if present otherwise NULL
> >   */
> > -static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> > -			 struct device_node *np, struct device *dev)
> > +static struct device_node *stmmac_of_get_mdio(struct device_node *np)
> >  {
> > -	bool mdio = !of_phy_is_fixed_link(np);
> >  	static const struct of_device_id need_mdio_ids[] = {
> >  		{ .compatible = "snps,dwc-qos-ethernet-4.10" },
> >  		{},
> >  	};
> > +	struct device_node *mdio_node = NULL;
> >  
> >  	if (of_match_node(need_mdio_ids, np)) {
> > -		plat->mdio_node = of_get_child_by_name(np, "mdio");
> > +		mdio_node = of_get_child_by_name(np, "mdio");
> >  	} else {
> >  		/**
> >  		 * If snps,dwmac-mdio is passed from DT, always register
> >  		 * the MDIO
> >  		 */
> > -		for_each_child_of_node(np, plat->mdio_node) {
> > -			if (of_device_is_compatible(plat->mdio_node,
> > +		for_each_child_of_node(np, mdio_node) {
> > +			if (of_device_is_compatible(mdio_node,
> >  						    "snps,dwmac-mdio"))
> >  				break;
> >  		}
> >  	}
> >  
> > -	if (plat->mdio_node) {
> > -		dev_dbg(dev, "Found MDIO subnode\n");
> > -		mdio = true;
> > -	}
> > -
> > -	if (mdio) {
> > -		plat->mdio_bus_data =
> > -			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
> > -				     GFP_KERNEL);
> > -		if (!plat->mdio_bus_data)
> > -			return -ENOMEM;
> > -
> > -		plat->mdio_bus_data->needs_reset = true;
> > -	}
> > -
> > -	return 0;
> > +	return mdio_node;
> >  }
> >  
> >  /**
> > @@ -417,6 +387,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
> >  	struct device_node *np = pdev->dev.of_node;
> >  	struct plat_stmmacenet_data *plat;
> >  	struct stmmac_dma_cfg *dma_cfg;
> > +	bool legacy_mdio;
> >  	int phy_mode;
> >  	void *ret;
> >  	int rc;
> > @@ -471,10 +442,28 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
> >  	if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
> >  		dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
> >  
> > -	/* To Configure PHY by using all device-tree supported properties */
> > -	rc = stmmac_dt_phy(plat, np, &pdev->dev);
> > -	if (rc)
> > -		return ERR_PTR(rc);
> > +	plat->mdio_node = stmmac_of_get_mdio(np);
> > +	if (plat->mdio_node)
> > +		dev_dbg(&pdev->dev, "Found MDIO subnode\n");
> > +
> 
> > +	/* Legacy devicetrees allowed for no MDIO bus description and expect
> > +	 * the bus to be scanned for devices. If there's no phy or fixed-link
> > +	 * described assume this is the case since there must be something
> > +	 * connected to the MAC.
> > +	 */
> > +	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
> > +	if (legacy_mdio)
> > +		dev_info(&pdev->dev, "Deprecated MDIO bus assumption used\n");
> > +
> > +	if (plat->mdio_node || legacy_mdio) {
> > +		plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
> > +						   sizeof(struct stmmac_mdio_bus_data),
> > +						   GFP_KERNEL);
> > +		if (!plat->mdio_bus_data)
> > +			return ERR_PTR(-ENOMEM);
> > +
> > +		plat->mdio_bus_data->needs_reset = true;
> > +	}
> 
> Why did you decide to move this out of the dedicated function?
> stmmac_probe_config_dt() is already overwhelmed with various
> non-coherent actions. The method has already got to being too long to
> follow the kernel coding style limit (I have got a not submitted yet
> cleanup patchset which step-by-step fixes that). Could you please get
> the chunk above back to the respective function and, for instance,
> just change it's name to something like stmmac_mdio_setup()? (I prefer
> having "_setup" suffix because some of the locally defined static
> methods already use it: stmmac_axi_setup(), stmmac_mtl_setup().)

Sure, I can put it back in. I'll probably keep stmmac_of_get_mdio()
(which is named in the style I see in the current file -- although as
you highlight that shouldn't be taken as the best example of clean),
and have stmmac_mdio_setup() call that and and mimic the inputs/outputs
of the current function (moving the rest of the added code from
stmmac_probe_config_dt() back into that function).

Thanks for the feedback, let me know if you still think that abstraction
isn't ideal (or wait till I post it :P) and I'll go with exactly as you
said. I'm not _too_ opinionated on it, but thought stmmac_dt_phy()
didn't explain much and stmmac_of_get_mdio() was self-explanatory enough
that it helped readability.

> 
> -Serge(y)
> 
> >  
> >  	of_property_read_u32(np, "tx-fifo-depth", &plat->tx_fifo_size);
> >  
> > 
> > ---
> > base-commit: fd8a79b63710acb84321be3ce74be23c876873fb
> > change-id: 20231127-stmmac-no-mdio-node-1db9da8a25d9
> > 
> > Best regards,
> > -- 
> > Andrew Halaney <ahalaney at redhat.com>
> > 
> > 
> 



From linus.walleij at linaro.org  Thu Dec  7 05:33:35 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 07 Dec 2023 14:33:35 +0100
Subject: [PATCH v2] ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support
Message-ID: <20231207-drop-11mpcore-v2-1-560b396f3bf5@linaro.org>

This ARM11 SMP configuration was one of the first SMP configurations
the ARM kernel supported, but it has the downside of odd DMA handling,
odd cache tagging, and often (as of recent) completely broken cache
handling on the ARM RealView PB11MPCore test chips. To boot the
platform it was necessary to completely disable the cache.
When it comes to the EB 11MPCore it is unclear if this ever worked.

These reference designs are now the only ARMv6K SMP platforms.

As only reference designs of purely academic interest remain, and
since the special-cased DMA and PMU code is hard to maintain and
doesn't really work, it is not really worth our time.

Delete the ARM11MPCore support along with:

- The special DMA quirk CONFIG_DMA_CACHE_RWFO that is only used
  on ARMv6K SMP, and we are the last ARMV6K system leaving the
  building and the cache handling is awkward, so good-bye.

- The special PMU handling that was only used by ARM11MPCore.

The following is left behind:

- TIMER_OF_DECLARE(arm_twd_11mp, "arm,arm11mp-twd-timer", ...)
  in arch/arm/kernel/smp_twd.c, this is still in use by Marvell MMP3
  arch/arm/boot/dts/marvell/mmp3.dtsi

- IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", ...)
  in drivers/irqchip/irq-gic.c, this is still in use by Marvell MMP3
  arch/arm/boot/dts/marvell/mmp3.dtsi

- A compatible for the arm11mpcore SCU, since this was mistakedly
  used for the Cortex-A9 version of RealView EB.

These are unfortunate but will need to be kept around for
compatibility. New Marvell-specific compatibles should however probably
be added.

Acked-by: Mark Rutland <mark.rutland at arm.com>
Reviewed-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Changes in v2:
- Keep the PB11MPCore SCU compatible for a bit (until we delete these
  RealView EB device trees).
- Please apply this to the SoC tree once there is consensus.
- Link to v1: https://lore.kernel.org/r/20231204-drop-11mpcore-v1-1-f96cd3938cf1 at linaro.org
---
 arch/arm/kernel/perf_event_v6.c            | 34 ------------------------------
 arch/arm/mach-versatile/Kconfig            | 17 ---------------
 arch/arm/mach-versatile/platsmp-realview.c |  6 +++++-
 arch/arm/mach-versatile/realview.c         |  1 -
 arch/arm/mm/Kconfig                        | 18 ----------------
 arch/arm/mm/cache-v6.S                     | 31 ---------------------------
 6 files changed, 5 insertions(+), 102 deletions(-)

diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index 1ae99deeec54..3115077f6abc 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -525,40 +525,7 @@ static int armv6_1176_pmu_init(struct arm_pmu *cpu_pmu)
 	return 0;
 }
 
-/*
- * ARMv6mpcore is almost identical to single core ARMv6 with the exception
- * that some of the events have different enumerations and that there is no
- * *hack* to stop the programmable counters. To stop the counters we simply
- * disable the interrupt reporting and update the event. When unthrottling we
- * reset the period and enable the interrupt reporting.
- */
-
-static int armv6mpcore_map_event(struct perf_event *event)
-{
-	return armpmu_map_event(event, &armv6mpcore_perf_map,
-				&armv6mpcore_perf_cache_map, 0xFF);
-}
-
-static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
-{
-	cpu_pmu->name		= "armv6_11mpcore";
-	cpu_pmu->handle_irq	= armv6pmu_handle_irq;
-	cpu_pmu->enable		= armv6pmu_enable_event;
-	cpu_pmu->disable	= armv6mpcore_pmu_disable_event;
-	cpu_pmu->read_counter	= armv6pmu_read_counter;
-	cpu_pmu->write_counter	= armv6pmu_write_counter;
-	cpu_pmu->get_event_idx	= armv6pmu_get_event_idx;
-	cpu_pmu->clear_event_idx = armv6pmu_clear_event_idx;
-	cpu_pmu->start		= armv6pmu_start;
-	cpu_pmu->stop		= armv6pmu_stop;
-	cpu_pmu->map_event	= armv6mpcore_map_event;
-	cpu_pmu->num_events	= 3;
-
-	return 0;
-}
-
 static const struct of_device_id armv6_pmu_of_device_ids[] = {
-	{.compatible = "arm,arm11mpcore-pmu",	.data = armv6mpcore_pmu_init},
 	{.compatible = "arm,arm1176-pmu",	.data = armv6_1176_pmu_init},
 	{.compatible = "arm,arm1136-pmu",	.data = armv6_1136_pmu_init},
 	{ /* sentinel value */ }
@@ -568,7 +535,6 @@ static const struct pmu_probe_info armv6_pmu_probe_table[] = {
 	ARM_PMU_PROBE(ARM_CPU_PART_ARM1136, armv6_1136_pmu_init),
 	ARM_PMU_PROBE(ARM_CPU_PART_ARM1156, armv6_1156_pmu_init),
 	ARM_PMU_PROBE(ARM_CPU_PART_ARM1176, armv6_1176_pmu_init),
-	ARM_PMU_PROBE(ARM_CPU_PART_ARM11MPCORE, armv6mpcore_pmu_init),
 	{ /* sentinel value */ }
 };
 
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index b1519b4dc03a..e029270c2687 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -201,23 +201,6 @@ config REALVIEW_EB_A9MP
 	  Enable support for the Cortex-A9MPCore tile fitted to the
 	  Realview(R) Emulation Baseboard platform.
 
-config REALVIEW_EB_ARM11MP
-	bool "Support ARM11MPCore Tile"
-	depends on MACH_REALVIEW_EB && ARCH_MULTI_V6
-	select HAVE_SMP
-	help
-	  Enable support for the ARM11MPCore tile fitted to the Realview(R)
-	  Emulation Baseboard platform.
-
-config MACH_REALVIEW_PB11MP
-	bool "Support RealView(R) Platform Baseboard for ARM11MPCore"
-	depends on ARCH_MULTI_V6
-	select HAVE_SMP
-	help
-	  Include support for the ARM(R) RealView(R) Platform Baseboard for
-	  the ARM11MPCore.  This platform has an on-board ARM11MPCore and has
-	  support for PCI-E and Compact Flash.
-
 # ARMv6 CPU without K extensions, but does have the new exclusive ops
 config MACH_REALVIEW_PB1176
 	bool "Support RealView(R) Platform Baseboard for ARM1176JZF-S"
diff --git a/arch/arm/mach-versatile/platsmp-realview.c b/arch/arm/mach-versatile/platsmp-realview.c
index 5d363385c801..6965a1de727b 100644
--- a/arch/arm/mach-versatile/platsmp-realview.c
+++ b/arch/arm/mach-versatile/platsmp-realview.c
@@ -18,6 +18,11 @@
 #define REALVIEW_SYS_FLAGSSET_OFFSET	0x30
 
 static const struct of_device_id realview_scu_match[] = {
+	/*
+	 * The ARM11MP SCU compatible is only provided as fallback for
+	 * old RealView EB Cortex-A9 device trees that were using this
+	 * compatible by mistake.
+	 */
 	{ .compatible = "arm,arm11mp-scu", },
 	{ .compatible = "arm,cortex-a9-scu", },
 	{ .compatible = "arm,cortex-a5-scu", },
@@ -27,7 +32,6 @@ static const struct of_device_id realview_scu_match[] = {
 static const struct of_device_id realview_syscon_match[] = {
         { .compatible = "arm,core-module-integrator", },
         { .compatible = "arm,realview-eb-syscon", },
-        { .compatible = "arm,realview-pb11mp-syscon", },
         { .compatible = "arm,realview-pbx-syscon", },
         { },
 };
diff --git a/arch/arm/mach-versatile/realview.c b/arch/arm/mach-versatile/realview.c
index a3933e2373d5..36a6f6bc4fdd 100644
--- a/arch/arm/mach-versatile/realview.c
+++ b/arch/arm/mach-versatile/realview.c
@@ -9,7 +9,6 @@
 static const char *const realview_dt_platform_compat[] __initconst = {
 	"arm,realview-eb",
 	"arm,realview-pb1176",
-	"arm,realview-pb11mp",
 	"arm,realview-pba8",
 	"arm,realview-pbx",
 	NULL,
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c164cde50243..2b6f50dd5478 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -937,24 +937,6 @@ config VDSO
 	  You must have glibc 2.22 or later for programs to seamlessly
 	  take advantage of this.
 
-config DMA_CACHE_RWFO
-	bool "Enable read/write for ownership DMA cache maintenance"
-	depends on CPU_V6K && SMP
-	default y
-	help
-	  The Snoop Control Unit on ARM11MPCore does not detect the
-	  cache maintenance operations and the dma_{map,unmap}_area()
-	  functions may leave stale cache entries on other CPUs. By
-	  enabling this option, Read or Write For Ownership in the ARMv6
-	  DMA cache maintenance functions is performed. These LDR/STR
-	  instructions change the cache line state to shared or modified
-	  so that the cache operation has the desired effect.
-
-	  Note that the workaround is only valid on processors that do
-	  not perform speculative loads into the D-cache. For such
-	  processors, if cache maintenance operations are not broadcast
-	  in hardware, other workarounds are needed (e.g. cache
-	  maintenance broadcasting in software via FIQ).
 
 config OUTER_CACHE
 	bool
diff --git a/arch/arm/mm/cache-v6.S b/arch/arm/mm/cache-v6.S
index 250c83bf7158..44211d8a296f 100644
--- a/arch/arm/mm/cache-v6.S
+++ b/arch/arm/mm/cache-v6.S
@@ -201,10 +201,6 @@ ENTRY(v6_flush_kern_dcache_area)
  *	- end     - virtual end address of region
  */
 v6_dma_inv_range:
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrb	r2, [r0]			@ read for ownership
-	strb	r2, [r0]			@ write for ownership
-#endif
 	tst	r0, #D_CACHE_LINE_SIZE - 1
 	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
 #ifdef HARVARD_CACHE
@@ -213,10 +209,6 @@ v6_dma_inv_range:
 	mcrne	p15, 0, r0, c7, c11, 1		@ clean unified line
 #endif
 	tst	r1, #D_CACHE_LINE_SIZE - 1
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrbne	r2, [r1, #-1]			@ read for ownership
-	strbne	r2, [r1, #-1]			@ write for ownership
-#endif
 	bic	r1, r1, #D_CACHE_LINE_SIZE - 1
 #ifdef HARVARD_CACHE
 	mcrne	p15, 0, r1, c7, c14, 1		@ clean & invalidate D line
@@ -231,10 +223,6 @@ v6_dma_inv_range:
 #endif
 	add	r0, r0, #D_CACHE_LINE_SIZE
 	cmp	r0, r1
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrlo	r2, [r0]			@ read for ownership
-	strlo	r2, [r0]			@ write for ownership
-#endif
 	blo	1b
 	mov	r0, #0
 	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer
@@ -248,9 +236,6 @@ v6_dma_inv_range:
 v6_dma_clean_range:
 	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
 1:
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldr	r2, [r0]			@ read for ownership
-#endif
 #ifdef HARVARD_CACHE
 	mcr	p15, 0, r0, c7, c10, 1		@ clean D line
 #else
@@ -269,10 +254,6 @@ v6_dma_clean_range:
  *	- end     - virtual end address of region
  */
 ENTRY(v6_dma_flush_range)
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrb	r2, [r0]		@ read for ownership
-	strb	r2, [r0]		@ write for ownership
-#endif
 	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
 1:
 #ifdef HARVARD_CACHE
@@ -282,10 +263,6 @@ ENTRY(v6_dma_flush_range)
 #endif
 	add	r0, r0, #D_CACHE_LINE_SIZE
 	cmp	r0, r1
-#ifdef CONFIG_DMA_CACHE_RWFO
-	ldrblo	r2, [r0]			@ read for ownership
-	strblo	r2, [r0]			@ write for ownership
-#endif
 	blo	1b
 	mov	r0, #0
 	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer
@@ -301,13 +278,7 @@ ENTRY(v6_dma_map_area)
 	add	r1, r1, r0
 	teq	r2, #DMA_FROM_DEVICE
 	beq	v6_dma_inv_range
-#ifndef CONFIG_DMA_CACHE_RWFO
 	b	v6_dma_clean_range
-#else
-	teq	r2, #DMA_TO_DEVICE
-	beq	v6_dma_clean_range
-	b	v6_dma_flush_range
-#endif
 ENDPROC(v6_dma_map_area)
 
 /*
@@ -317,11 +288,9 @@ ENDPROC(v6_dma_map_area)
  *	- dir	- DMA direction
  */
 ENTRY(v6_dma_unmap_area)
-#ifndef CONFIG_DMA_CACHE_RWFO
 	add	r1, r1, r0
 	teq	r2, #DMA_TO_DEVICE
 	bne	v6_dma_inv_range
-#endif
 	ret	lr
 ENDPROC(v6_dma_unmap_area)
 

---
base-commit: d570fe67df85c84be7cc33ca9e9568d9601b494f
change-id: 20231202-drop-11mpcore-d556cc5f7d99

Best regards,
-- 
Linus Walleij <linus.walleij at linaro.org>



From krzysztof.kozlowski at linaro.org  Thu Dec  7 05:33:41 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 07 Dec 2023 14:33:41 +0100
Subject: [PATCH 0/6] dt-bindings: samsung: continued - add specific
 compatibles for Tesla FSD Hi,
In-Reply-To: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
Message-ID: <170195602173.92721.14927713507913101589.b4-ty@linaro.org>


On Tue, 05 Dec 2023 10:22:23 +0100, Krzysztof Kozlowski wrote:
> Merging
> =======
> I propose to take entire patchset through my tree (Samsung SoC), because:
> 1. I already took similar work this cycle:
>    https://lore.kernel.org/all/169997520487.6747.17671551558724027958.b4-ty at linaro.org/
> 2. Two new SoCs are coming (Google GS101 and ExynosAutov920) and they might
>    touch the same lines.  It is reasonable for me to take the bindings for the new
>    SoCs, to have clean `make dtbs_check` on the new DTS.
> 3. Having it together helps me to have clean `make dtbs_check` within my tree
>    on the existing DTS.
> 4. No drivers are affected by this change.
> 
> [...]

Applied, thanks!

[1/6] dt-bindings: i2c: exynos5: add specific compatible for Tesla FSD
      https://git.kernel.org/krzk/linux/c/7677fdbc036b93a882f660ca2484a6807e72f0be
[2/6] dt-bindings: pwm: samsung: add specific compatible for Tesla FSD
      https://git.kernel.org/krzk/linux/c/edb32ec3cea79b518e6af841ecb01c839818f562
[3/6] dt-bindings: serial: samsung: add specific compatible for Tesla FSD
      https://git.kernel.org/krzk/linux/c/921f4f1db7f5bf6798349db8a4382c032f144b98
[4/6] dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla FSD
      https://git.kernel.org/krzk/linux/c/54772f1d61cd99ea1ed0febd4187bf24ef63bccd
[5/6] dt-bindings: watchdog: samsung: add specific compatible for Tesla FSD
      https://git.kernel.org/krzk/linux/c/bf1e24c5330af06b2f7f1a166a1011d8d48e8651
[6/6] arm64: dts: fsd: add specific compatibles for Tesla FSD
      https://git.kernel.org/krzk/linux/c/5f257922c5948c58669346d5cda371632108f266

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From catalin.marinas at arm.com  Thu Dec  7 05:37:22 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 7 Dec 2023 13:37:22 +0000
Subject: [PATCH v3 04/25] arm64: disable trapping of POR_EL0 to EL2
In-Reply-To: <20231124163510.1835740-5-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-5-joey.gouly@arm.com>
Message-ID: <ZXHKkslcDy930IC7@arm.com>

On Fri, Nov 24, 2023 at 04:34:49PM +0000, Joey Gouly wrote:
> Allow EL0 or EL1 to access POR_EL0 without being trapped to EL2.
> 
> Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From jgg at nvidia.com  Thu Dec  7 05:38:25 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Thu, 7 Dec 2023 09:38:25 -0400
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <ZXGa4A6rfxLtkTB2@lpieralisi>
References: <20231205164318.GG2692119@nvidia.com>
 <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
 <ZXCJ3pVbKuHJ3LTz@arm.com>
 <20231206150556.GQ2692119@nvidia.com>
 <ZXCQrTbf6q0BIhSw@lpieralisi>
 <20231206153809.GS2692119@nvidia.com>
 <ZXCf_e-ACqrj6VrV@arm.com>
 <20231206164802.GT2692119@nvidia.com>
 <ZXGa4A6rfxLtkTB2@lpieralisi>
Message-ID: <20231207133825.GI2692119@nvidia.com>

On Thu, Dec 07, 2023 at 11:13:52AM +0100, Lorenzo Pieralisi wrote:
> > > What about the other way around - would we have a prefetchable BAR that
> > > has portions which are unprefetchable?
> > 
> > I would say possibly.
> > 
> > Prefetch is a dead concept in PCIe, it was obsoleted in PCI-X about 20
> > years ago. No PCIe system has ever done prefetch.
> > 
> > There is a strong incentive to mark BAR's as prefetchable because it
> > allows 64 bit addressing in configurations with bridges.
> 
> If by strong incentive you mean the "Additional guidance on the
> Prefetchable Bit in Memory Space BARs" in the PCI express specifications,
> I think it has been removed from the spec and the criteria that had to be
> met to implement it were basically impossible to fulfill on ARM systems,
> it did not make any sense in the first place.

No, I mean many systems don't have room to accommodate large 32 bit
BARs and the only real way to make stuff work is to have a 64 bit BAR
by setting prefetchable. Given mis-marking a read-side-effect region
as prefetchable has no actual consequence on PCI-E I would not be
surprised to learn people have done this.

> I agree on your statement related to the prefetchable concept but I
> believe that a prefetchable BAR containing regions that have
> read side-effects is essentially a borked design unless at system level
> speculative reads are prevented (as far as I understand the
> implementation note this could only be an endpoint integrated in a
> system where read speculation can't just happen (?)).

IMHO the PCIe concept of prefetchable has no intersection with the
CPU. The CPU chooses entirely on its own what rules to apply to the
PCI MMIO regions and no OS should drive that decision based on the
prefetchable BAR flag.

The *only* purpose of the prefetchable flag was to permit a classical
33/66MHz PCI bridge to prefetch reads because the physical bus
protocol back then did not include a read length.

For any system that does not have an ancient PCI bridge the indication
is totally useless.

Jason


From ulf.hansson at linaro.org  Thu Dec  7 05:37:57 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 7 Dec 2023 14:37:57 +0100
Subject: [v1,1/1] mmc: core: Add HS400es support in retune and
 initialization flow
In-Reply-To: <20231201030547.11553-1-mengqi.zhang@mediatek.com>
References: <20231201030547.11553-1-mengqi.zhang@mediatek.com>
Message-ID: <CAPDyKFqhGULWp3P2EpxUMLvdiijqu7qxPrY40GU2m3FM7XVCVQ@mail.gmail.com>

On Fri, 1 Dec 2023 at 04:06, Mengqi Zhang <mengqi.zhang at mediatek.com> wrote:
>
> In HS400es mode, when we enter mmc_retune(), we will be forced to
> the HS400 mode instead of HS400es mode. So we decided to add support
> for HS400es in the mmc_retune() process.

Hmm, I was under the impression that we really don't need to do
re-tuning at all, when using HS400es mode.

Are we calling mmc_retune_enable() from a place that we shouldn't?

>
> Additionally, during the initialization to the HS400es stage, add
> hs400 tuning as an optional process.
>
> Signed-off-by: Mengqi Zhang <mengqi.zhang at mediatek.com>

Kind regards
Uffe

> ---
>  drivers/mmc/core/host.c | 11 ++++++++++-
>  drivers/mmc/core/mmc.c  | 10 +++++++++-
>  2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 096093f7be00..4bddbbb3d539 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -179,7 +179,7 @@ EXPORT_SYMBOL(mmc_retune_release);
>  int mmc_retune(struct mmc_host *host)
>  {
>         bool return_to_hs400 = false;
> -       int err;
> +       int err = 0;
>
>         if (host->retune_now)
>                 host->retune_now = 0;
> @@ -194,6 +194,15 @@ int mmc_retune(struct mmc_host *host)
>         host->doing_retune = 1;
>
>         if (host->ios.timing == MMC_TIMING_MMC_HS400) {
> +               if (host->ios.enhanced_strobe) {
> +                       if (host->ops->execute_hs400_tuning) {
> +                               mmc_retune_disable(host);
> +                               err = host->ops->execute_hs400_tuning(host, host->card);
> +                               mmc_retune_enable(host);
> +                       }
> +                       goto out;
> +               }
> +
>                 err = mmc_hs400_to_hs200(host->card);
>                 if (err)
>                         goto out;
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 705942edacc6..9760eea2c104 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1823,7 +1823,15 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
>                 if (err)
>                         goto free_card;
>
> -       } else if (!mmc_card_hs400es(card)) {
> +       } else if (mmc_card_hs400es(card)) {
> +               if (host->ops->execute_hs400_tuning) {
> +                       mmc_retune_disable(host);
> +                       err = host->ops->execute_hs400_tuning(host, card);
> +                       mmc_retune_enable(host);
> +                       if (err)
> +                               goto free_card;
> +               }
> +       } else {
>                 /* Select the desired bus width optionally */
>                 err = mmc_select_bus_width(card);
>                 if (err > 0 && mmc_card_hs(card)) {
> --
> 2.25.1
>


From lee at kernel.org  Thu Dec  7 05:38:49 2023
From: lee at kernel.org (Lee Jones)
Date: Thu, 7 Dec 2023 13:38:49 +0000
Subject: [GIT PULL] Immutable branch between MFD and SPI due for the v6.8
 merge window
In-Reply-To: <395caa58-a8a0-4c75-85d3-4fa0f6f4a9ba@sirena.org.uk>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-2-amit.kumar-mahapatra@amd.com>
 <170142465659.3329910.8527538140063947758.b4-ty@kernel.org>
 <395caa58-a8a0-4c75-85d3-4fa0f6f4a9ba@sirena.org.uk>
Message-ID: <20231207133849.GB8867@google.com>

Good afternoon Mark,

> Is there a signed tag available for this - without this change the
> subsequent SPI changes introduce a build breakage.

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-spi-v6.8

for you to fetch changes up to 4ae08845db4c1f759b8382bc7527ab8249230e7f:

  mfd: tps6594: Use spi_get_chipselect() API to access spi->chip_select (2023-12-07 13:36:29 +0000)

----------------------------------------------------------------
Immutable branch between MFD and SPI due for the v6.8 merge window

----------------------------------------------------------------
Amit Kumar Mahapatra (1):
      mfd: tps6594: Use spi_get_chipselect() API to access spi->chip_select

 drivers/mfd/tps6594-spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Lee Jones [???]


From nm at ti.com  Thu Dec  7 05:43:43 2023
From: nm at ti.com (Nishanth Menon)
Date: Thu, 7 Dec 2023 07:43:43 -0600
Subject: [PATCH 2/3] arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet
 support
In-Reply-To: <f83f21c0-3f5f-4069-abab-2b47e371d3bd@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-3-danishanwar@ti.com>
 <20231207131818.3n7z64ve6izatlvs@unchanged>
 <f83f21c0-3f5f-4069-abab-2b47e371d3bd@ti.com>
Message-ID: <20231207134343.ufiy2owik5kn3y2r@degrease>

On 18:58-20231207, Anwar, Md Danish wrote:
[...]
> >> +
> >>  	memory at 80000000 {
> >>  		bootph-all;
> >>  		device_type = "memory";
> >> @@ -229,6 +234,70 @@ transceiver2: can-phy1 {
> >>  		max-bitrate = <5000000>;
> >>  		standby-gpios = <&exp1 9 GPIO_ACTIVE_HIGH>;
> >>  	};
> >> +
> >> +	icssg1_eth: icssg1-eth {
> >> +		compatible = "ti,am642-icssg-prueth";
> >> +		pinctrl-names = "default";
> >> +		pinctrl-0 = <&icssg1_rgmii1_pins_default>;
> >> +
> >> +		sram = <&oc_sram>;
> >> +		ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
> >> +		firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
> >> +				"ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
> >> +				"ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
> >> +				"ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
> >> +				"ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
> >> +				"ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
> > 
> > Umm... am65x??? is that a typo? I'd rather keep it am64x here and drop
> > that sr2 thing. Tomorrow there will be a custom bug on am64 and then we
> > will have to respin this again.
> > 
> 
> No Nishant, this is not a typo. Both AM64x and AM65x use the same ICSSG
> firmwares. We only have am65x-sr2-* firmwares and they are used by both
> AM64x and AM65x and that is why I have kept the firmware-name here in dt
> same as the files that we load on the pru cores.
> 

SoCs are different. The hardware as a result is different as well. In
fact, you do have a different compatible to distinguish the two. Some
day, there will be an erratum that is different and we will be stuck
with abi breakage across distros. So, unless you can explain why this
scenario will never occur, I don't buy the argument this will survive
long term.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From nm at ti.com  Thu Dec  7 05:49:12 2023
From: nm at ti.com (Nishanth Menon)
Date: Thu, 7 Dec 2023 07:49:12 -0600
Subject: [PATCH v9 6/7] arm64: dts: ti: k3-j721e-sk: Add TPS6594 family
 PMICs
In-Reply-To: <cc2c3e97-e2c6-487b-91a5-c5f5fbe2c3bc@ti.com>
References: <20231205093439.2298296-1-n-francis@ti.com>
 <20231205093439.2298296-7-n-francis@ti.com>
 <20231205151647.vh6rlhro7qlwoerc@knelt>
 <5e22f8cb-1004-4bcc-9bd0-2c30180ba10e@ti.com>
 <cc2c3e97-e2c6-487b-91a5-c5f5fbe2c3bc@ti.com>
Message-ID: <20231207134912.olfhmcz5kkbx47wo@landmine>

On 11:01-20231207, Neha Malcom Francis wrote:
> Hi Nishanth, Udit,
> 
> On 07/12/23 10:12, Kumar, Udit wrote:
> > 
> > On 12/5/2023 8:46 PM, Nishanth Menon wrote:
> > > On 15:04-20231205, Neha Malcom Francis wrote:
> > > > This patch adds support for TPS6594 PMIC family on wakeup I2C0 bus.
> > > > These devices provide regulators (bucks and LDOs), but also GPIOs, a
> > > > RTC, a watchdog, an ESM (Error Signal Monitor) which monitors the SoC
> > > > error output signal, and a PFSM (Pre-configurable Finite State Machine)
> > > > which manages the operational modes of the PMIC.
> > > > 
> > > > Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
> > > > ---
> > > > ? arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 158 +++++++++++++++++++++++++
> > > > ? 1 file changed, 158 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
> > > > b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
> > > > index 42fe8eee9ec8..e600825f7e78 100644
> > > > --- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
> > > > +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
> > > > @@ -459,6 +459,13 @@ J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3)
> > > > EXT_REFCLK1.GPIO1_12 */
> > > > ? };
> > > > ? &wkup_pmx0 {
> > > > +??? pmic_irq_pins_default: pmic-irq-default-pins {
> > > > +??????? bootph-pre-ram;
> > > > +??????? pinctrl-single,pins = <
> > > > +??????????? J721E_WKUP_IOPAD(0x0cc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
> > > > +??????? >;
> > > > +??? };
> > > > +
> > > > ????? mcu_cpsw_pins_default: mcu-cpsw-default-pins {
> > > > ????????? pinctrl-single,pins = <
> > > > ????????????? J721E_WKUP_IOPAD(0x84, PIN_INPUT, 0) /* (B24) MCU_RGMII1_RD0 */
> > > > @@ -560,6 +567,157 @@ eeprom at 51 {
> > > > ????????? compatible = "atmel,24c512";
> > > > ????????? reg = <0x51>;
> > > > ????? };
> > > > +
> > > > +??? tps659413: pmic at 48 {
> > > > +??????? bootph-pre-ram;
> > > only for the leaf nodes. See
> > > https://libera.irclog.whitequark.org/armlinux/2023-10-19
> > 
> > 
> > AFAIK, please correct me, u-boot still needs in all nodes ?
> > 
> 
> That's what I believe as well, is it better to have only the leaf nodes in
> kernel and have U-Boot DTSI handle the parent bootph properties? If so I'll
> send out v10 making change accordingly.
> 

Yes, u-boot today needs it in all nodes. BUT, u-boot needs to be fixed in
line to obey the rules of the schema convention that Rob clarified in
the discussion above.

The other choice is NOT to introduce new bootph properties till u-boot
is fixed up (this is also why I haven't sent out further updates for
bootph properties for kernel in this cycle).

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From catalin.marinas at arm.com  Thu Dec  7 05:51:36 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 7 Dec 2023 13:51:36 +0000
Subject: [PATCH v3 05/25] arm64: context switch POR_EL0 register
In-Reply-To: <20231124163510.1835740-6-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-6-joey.gouly@arm.com>
Message-ID: <ZXHN6IFeZLz-mFau@arm.com>

On Fri, Nov 24, 2023 at 04:34:50PM +0000, Joey Gouly wrote:
> @@ -498,6 +508,17 @@ static void erratum_1418040_new_exec(void)
>  	preempt_enable();
>  }
>  
> +static void permission_overlay_switch(struct task_struct *next)
> +{
> +	if (system_supports_poe()) {
> +		current->thread.por_el0 = read_sysreg_s(SYS_POR_EL0);
> +		if (current->thread.por_el0 != next->thread.por_el0) {
> +			write_sysreg_s(next->thread.por_el0, SYS_POR_EL0);
> +			isb();
> +		}
> +	}

Nitpick: use "if (!system_supports_poe()) return;" to avoid too much
indentation.

W.r.t. the isb(), I think we accumulated quite a lot on this path. It
might be worth going through them and having one at the end, where
possible.

-- 
Catalin


From a0501179 at ti.com  Thu Dec  7 05:53:59 2023
From: a0501179 at ti.com (Anwar, Md Danish)
Date: Thu, 7 Dec 2023 19:23:59 +0530
Subject: [PATCH 2/3] arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet
 support
In-Reply-To: <20231207134343.ufiy2owik5kn3y2r@degrease>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-3-danishanwar@ti.com>
 <20231207131818.3n7z64ve6izatlvs@unchanged>
 <f83f21c0-3f5f-4069-abab-2b47e371d3bd@ti.com>
 <20231207134343.ufiy2owik5kn3y2r@degrease>
Message-ID: <6f2c1c23-bed6-48be-8407-030f2993ec8a@ti.com>

On 12/7/2023 7:13 PM, Nishanth Menon wrote:
> On 18:58-20231207, Anwar, Md Danish wrote:
> [...]
>>>> +
>>>>  	memory at 80000000 {
>>>>  		bootph-all;
>>>>  		device_type = "memory";
>>>> @@ -229,6 +234,70 @@ transceiver2: can-phy1 {
>>>>  		max-bitrate = <5000000>;
>>>>  		standby-gpios = <&exp1 9 GPIO_ACTIVE_HIGH>;
>>>>  	};
>>>> +
>>>> +	icssg1_eth: icssg1-eth {
>>>> +		compatible = "ti,am642-icssg-prueth";
>>>> +		pinctrl-names = "default";
>>>> +		pinctrl-0 = <&icssg1_rgmii1_pins_default>;
>>>> +
>>>> +		sram = <&oc_sram>;
>>>> +		ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
>>>> +		firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
>>>> +				"ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
>>>> +				"ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
>>>> +				"ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
>>>> +				"ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
>>>> +				"ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
>>>
>>> Umm... am65x??? is that a typo? I'd rather keep it am64x here and drop
>>> that sr2 thing. Tomorrow there will be a custom bug on am64 and then we
>>> will have to respin this again.
>>>
>>
>> No Nishant, this is not a typo. Both AM64x and AM65x use the same ICSSG
>> firmwares. We only have am65x-sr2-* firmwares and they are used by both
>> AM64x and AM65x and that is why I have kept the firmware-name here in dt
>> same as the files that we load on the pru cores.
>>
> 
> SoCs are different. The hardware as a result is different as well. In
> fact, you do have a different compatible to distinguish the two. Some
> day, there will be an erratum that is different and we will be stuck
> with abi breakage across distros. So, unless you can explain why this
> scenario will never occur, I don't buy the argument this will survive
> long term.
> 

Agreed, this property was introduced for this purpose only. Today am65x
and am64x share the same firmware however in future the firmwares might
change and that is why we have this property. Currently this property is
not used in driver and firmware name is defined in the driver (with the
below structure) which is used for both am64x and am65x. I will rename
the firmware names here to am64x-sr2* in v2. In future when we have
different firmwares for different SoCs, we can stop using the below
structure and use the firmware-name property from dt.

static struct icssg_firmwares icssg_emac_firmwares[] = {
	{
		.pru = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
		.rtu = "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
		.txpru = "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
	},
	{
		.pru = "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
		.rtu = "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
		.txpru = "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf",
	}
};

-- 
Thanks and Regards,
Md Danish Anwar


From fancer.lancer at gmail.com  Thu Dec  7 05:55:19 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Thu, 7 Dec 2023 16:55:19 +0300
Subject: [PATCH net-next v2] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <vmjpuli2l6r7awtiwip6hbgmc4m7hgtbyoqi3z4rhb5chfoiu4@5ebw7tepe6mp>
References: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
 <o3abmn7ocuksmjg23rrgsib7nfm4yo5rtzlqw2np2pplg73drd@7qe4vrsx2gyc>
 <vmjpuli2l6r7awtiwip6hbgmc4m7hgtbyoqi3z4rhb5chfoiu4@5ebw7tepe6mp>
Message-ID: <rlq2eodwlesa4bvxz2ro24tsrhfd3cyz3blxhxzldrs3nuktzu@wspwzlz3umkh>

On Thu, Dec 07, 2023 at 07:32:29AM -0600, Andrew Halaney wrote:
> On Thu, Dec 07, 2023 at 02:56:25PM +0300, Serge Semin wrote:
> > Hi Andrew
> > 
> > On Wed, Dec 06, 2023 at 05:46:09PM -0600, Andrew Halaney wrote:
> > > The stmmac_dt_phy() function, which parses the devicetree node of the
> > > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > > fixed-link means in relation to the MAC's MDIO bus. This results in
> > > a MDIO bus being created in situations it need not be.
> > > 
> > > Currently a MDIO bus is created if the description is either:
> > > 
> > >     1. Not fixed-link
> > >     2. fixed-link but contains a MDIO bus as well
> > > 
> > > The "1" case above isn't always accurate. If there's a phy-handle,
> > > it could be referencing a phy on another MDIO controller's bus[1]. In
> > > this case currently the MAC will make a MDIO bus and scan it all
> > > anyways unnecessarily.
> > > 
> > > There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> > > be created and scanned for a phy. This case can also be inferred from
> > > the platform description by not having a phy-handle && not being
> > > fixed-link. This hits case "1" in the current driver's logic.
> > > 
> > > Let's improve the logic to create a MDIO bus if either:
> > > 
> > >     - Devicetree contains a MDIO bus
> > >     - !fixed-link && !phy-handle (legacy handling)
> > > 
> > > Below upstream devicetree snippets can be found that explain some of
> > > the cases above more concretely.
> > > 
> > > Here's[0] a devicetree example where the MAC is both fixed-link and
> > > driving a switch on MDIO (case "2" above). This needs a MDIO bus to
> > > be created:
> > > 
> > >     &fec1 {
> > >             phy-mode = "rmii";
> > > 
> > >             fixed-link {
> > >                     speed = <100>;
> > >                     full-duplex;
> > >             };
> > > 
> > >             mdio1: mdio {
> > >                     switch0: switch0 at 0 {
> > >                             compatible = "marvell,mv88e6190";
> > >                             pinctrl-0 = <&pinctrl_gpio_switch0>;
> > >                     };
> > >             };
> > >     };
> > > 
> > > Here's[1] an example where there is no MDIO bus or fixed-link for
> > > the ethernet1 MAC, so no MDIO bus should be created since ethernet0
> > > is the MDIO master for ethernet1's phy:
> > > 
> > >     &ethernet0 {
> > >             phy-mode = "sgmii";
> > >             phy-handle = <&sgmii_phy0>;
> > > 
> > >             mdio {
> > >                     compatible = "snps,dwmac-mdio";
> > >                     sgmii_phy0: phy at 8 {
> > >                             compatible = "ethernet-phy-id0141.0dd4";
> > >                             reg = <0x8>;
> > >                             device_type = "ethernet-phy";
> > >                     };
> > > 
> > >                     sgmii_phy1: phy at a {
> > >                             compatible = "ethernet-phy-id0141.0dd4";
> > >                             reg = <0xa>;
> > >                             device_type = "ethernet-phy";
> > >                     };
> > >             };
> > >     };
> > > 
> > >     &ethernet1 {
> > >             phy-mode = "sgmii";
> > >             phy-handle = <&sgmii_phy1>;
> > >     };
> > > 
> > > Finally there's descriptions like this[2] which don't describe the
> > > MDIO bus but expect it to be created and the whole address space
> > > scanned for a phy since there's no phy-handle or fixed-link described:
> > > 
> > >     &gmac {
> > >             phy-supply = <&vcc_lan>;
> > >             phy-mode = "rmii";
> > >             snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
> > >             snps,reset-active-low;
> > >             snps,reset-delays-us = <0 10000 1000000>;
> > >     };
> > > 
> > > [0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts
> > > [1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
> > > [2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164
> > 
> > Thank you for the patch. Please find a comment below.
> > 
> > > 
> > > Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> > > Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
> > > ---
> > >  .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 85 ++++++++++------------
> > >  1 file changed, 37 insertions(+), 48 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > > index 1ffde555da47..7da461fe93f6 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > > @@ -296,69 +296,39 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
> > >  }
> > >  
> > >  /**
> > > - * stmmac_dt_phy - parse device-tree driver parameters to allocate PHY resources
> > > - * @plat: driver data platform structure
> > > - * @np: device tree node
> > > - * @dev: device pointer
> > > - * Description:
> > > - * The mdio bus will be allocated in case of a phy transceiver is on board;
> > > - * it will be NULL if the fixed-link is configured.
> > > - * If there is the "snps,dwmac-mdio" sub-node the mdio will be allocated
> > > - * in any case (for DSA, mdio must be registered even if fixed-link).
> > > - * The table below sums the supported configurations:
> > > - *	-------------------------------
> > > - *	snps,phy-addr	|     Y
> > > - *	-------------------------------
> > > - *	phy-handle	|     Y
> > > - *	-------------------------------
> > > - *	fixed-link	|     N
> > > - *	-------------------------------
> > > - *	snps,dwmac-mdio	|
> > > - *	  even if	|     Y
> > > - *	fixed-link	|
> > > - *	-------------------------------
> > > + * stmmac_of_get_mdio() - Gets the MDIO bus from the devicetree
> > > + * @np: devicetree node
> > >   *
> > > - * It returns 0 in case of success otherwise -ENODEV.
> > > + * The MDIO bus will be searched for in the following ways:
> > > + * 1. The compatible is "snps,dwc-qos-ethernet-4.10" && a "mdio" named
> > > + *    child node exists
> > > + * 2. A child node with the "snps,dwmac-mdio" compatible is present
> > > + *
> > > + * Return: The MDIO node if present otherwise NULL
> > >   */
> > > -static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> > > -			 struct device_node *np, struct device *dev)
> > > +static struct device_node *stmmac_of_get_mdio(struct device_node *np)
> > >  {
> > > -	bool mdio = !of_phy_is_fixed_link(np);
> > >  	static const struct of_device_id need_mdio_ids[] = {
> > >  		{ .compatible = "snps,dwc-qos-ethernet-4.10" },
> > >  		{},
> > >  	};
> > > +	struct device_node *mdio_node = NULL;
> > >  
> > >  	if (of_match_node(need_mdio_ids, np)) {
> > > -		plat->mdio_node = of_get_child_by_name(np, "mdio");
> > > +		mdio_node = of_get_child_by_name(np, "mdio");
> > >  	} else {
> > >  		/**
> > >  		 * If snps,dwmac-mdio is passed from DT, always register
> > >  		 * the MDIO
> > >  		 */
> > > -		for_each_child_of_node(np, plat->mdio_node) {
> > > -			if (of_device_is_compatible(plat->mdio_node,
> > > +		for_each_child_of_node(np, mdio_node) {
> > > +			if (of_device_is_compatible(mdio_node,
> > >  						    "snps,dwmac-mdio"))
> > >  				break;
> > >  		}
> > >  	}
> > >  
> > > -	if (plat->mdio_node) {
> > > -		dev_dbg(dev, "Found MDIO subnode\n");
> > > -		mdio = true;
> > > -	}
> > > -
> > > -	if (mdio) {
> > > -		plat->mdio_bus_data =
> > > -			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
> > > -				     GFP_KERNEL);
> > > -		if (!plat->mdio_bus_data)
> > > -			return -ENOMEM;
> > > -
> > > -		plat->mdio_bus_data->needs_reset = true;
> > > -	}
> > > -
> > > -	return 0;
> > > +	return mdio_node;
> > >  }
> > >  
> > >  /**
> > > @@ -417,6 +387,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
> > >  	struct device_node *np = pdev->dev.of_node;
> > >  	struct plat_stmmacenet_data *plat;
> > >  	struct stmmac_dma_cfg *dma_cfg;
> > > +	bool legacy_mdio;
> > >  	int phy_mode;
> > >  	void *ret;
> > >  	int rc;
> > > @@ -471,10 +442,28 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
> > >  	if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
> > >  		dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
> > >  
> > > -	/* To Configure PHY by using all device-tree supported properties */
> > > -	rc = stmmac_dt_phy(plat, np, &pdev->dev);
> > > -	if (rc)
> > > -		return ERR_PTR(rc);
> > > +	plat->mdio_node = stmmac_of_get_mdio(np);
> > > +	if (plat->mdio_node)
> > > +		dev_dbg(&pdev->dev, "Found MDIO subnode\n");
> > > +
> > 
> > > +	/* Legacy devicetrees allowed for no MDIO bus description and expect
> > > +	 * the bus to be scanned for devices. If there's no phy or fixed-link
> > > +	 * described assume this is the case since there must be something
> > > +	 * connected to the MAC.
> > > +	 */
> > > +	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
> > > +	if (legacy_mdio)
> > > +		dev_info(&pdev->dev, "Deprecated MDIO bus assumption used\n");
> > > +
> > > +	if (plat->mdio_node || legacy_mdio) {
> > > +		plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
> > > +						   sizeof(struct stmmac_mdio_bus_data),
> > > +						   GFP_KERNEL);
> > > +		if (!plat->mdio_bus_data)
> > > +			return ERR_PTR(-ENOMEM);
> > > +
> > > +		plat->mdio_bus_data->needs_reset = true;
> > > +	}
> > 
> > Why did you decide to move this out of the dedicated function?
> > stmmac_probe_config_dt() is already overwhelmed with various
> > non-coherent actions. The method has already got to being too long to
> > follow the kernel coding style limit (I have got a not submitted yet
> > cleanup patchset which step-by-step fixes that). Could you please get
> > the chunk above back to the respective function and, for instance,
> > just change it's name to something like stmmac_mdio_setup()? (I prefer
> > having "_setup" suffix because some of the locally defined static
> > methods already use it: stmmac_axi_setup(), stmmac_mtl_setup().)
> 

> Sure, I can put it back in. I'll probably keep stmmac_of_get_mdio()
> (which is named in the style I see in the current file -- although as
> you highlight that shouldn't be taken as the best example of clean),
> and have stmmac_mdio_setup() call that and and mimic the inputs/outputs
> of the current function (moving the rest of the added code from
> stmmac_probe_config_dt() back into that function).
> 
> Thanks for the feedback, let me know if you still think that abstraction
> isn't ideal (or wait till I post it :P) and I'll go with exactly as you
> said.

Sounds good. Thanks for taking my comment into account.

> I'm not _too_ opinionated on it, but thought stmmac_dt_phy()
> didn't explain much and stmmac_of_get_mdio() was self-explanatory enough
> that it helped readability.

You were right. stmmac_dt_phy() hasn't been explicitly doing
PHY-related things since commit 74371272f97f ("net: stmmac: Convert to
phylink and remove phylib logic"), but has been left with the MDIO
stuff only. The function name wasn't that well chosen either.  It
didn't indicate what the function actually did, like "init", "get",
"setup", etc. From that perspective your naming is much better - short
and self-explanatory indeed.

-Serge(y)

> 
> > 
> > -Serge(y)
> > 
> > >  
> > >  	of_property_read_u32(np, "tx-fifo-depth", &plat->tx_fifo_size);
> > >  
> > > 
> > > ---
> > > base-commit: fd8a79b63710acb84321be3ce74be23c876873fb
> > > change-id: 20231127-stmmac-no-mdio-node-1db9da8a25d9
> > > 
> > > Best regards,
> > > -- 
> > > Andrew Halaney <ahalaney at redhat.com>
> > > 
> > > 
> > 
> 


From laurent.pinchart at ideasonboard.com  Thu Dec  7 05:55:39 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 15:55:39 +0200
Subject: [PATCH v2 1/1] media: nxp: imx8-isi-debug: Add missing 36-Bit
 DMA registers to debugfs output
In-Reply-To: <20231207110918.1338524-1-alexander.stein@ew.tq-group.com>
References: <20231207110918.1338524-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231207135539.GJ9675@pendragon.ideasonboard.com>

Hi Alexander,

Thank you for the patch.

On Thu, Dec 07, 2023 at 12:09:18PM +0100, Alexander Stein wrote:
> The extended address registers are missing in the debug output register
> list. These are only available on 36-Bit DMA platforms. Due to the
> prolonged name, the output width has to be adjusted as well.
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> ---
> Changes in v2:
> * Split register set into regular and 36-Bit DMA only
> * Adjust output width to address longer register names
> 
> Currently only tested on TQMa8MPxL (imx8mp-tqma8mpql-mba8mpxl.dts)
> 
>  .../platform/nxp/imx8-isi/imx8-isi-debug.c    | 28 +++++++++++++++++--
>  1 file changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> index 6709ab7ea1f3..398864b5e506 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> @@ -22,10 +22,11 @@ static inline u32 mxc_isi_read(struct mxc_isi_pipe *pipe, u32 reg)
>  static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
>  {
>  #define MXC_ISI_DEBUG_REG(name)		{ name, #name }
> -	static const struct {
> +	struct debug_regs {
>  		u32 offset;
>  		const char * const name;
> -	} registers[] = {
> +	};
> +	static const struct debug_regs registers[] = {
>  		MXC_ISI_DEBUG_REG(CHNL_CTRL),
>  		MXC_ISI_DEBUG_REG(CHNL_IMG_CTRL),
>  		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF_CTRL),
> @@ -67,6 +68,16 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
>  		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
>  		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
>  	};
> +	/* There registers contain the upper 4Bits of 36-Bit DMA addresses */

s/There/These/

> +	static const struct debug_regs registers_36bit_dma[] = {
> +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
> +		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),
> +	};
>  
>  	struct mxc_isi_pipe *pipe = m->private;
>  	unsigned int i;
> @@ -77,10 +88,21 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
>  	seq_printf(m, "--- ISI pipe %u registers ---\n", pipe->id);
>  
>  	for (i = 0; i < ARRAY_SIZE(registers); ++i)
> -		seq_printf(m, "%20s[0x%02x]: 0x%08x\n",
> +		seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
>  			   registers[i].name, registers[i].offset,
>  			   mxc_isi_read(pipe, registers[i].offset));
>  
> +	if (pipe->isi->pdata->has_36bit_dma) {
> +		for (i = 0; i < ARRAY_SIZE(registers_36bit_dma); ++i) {
> +			const struct debug_regs *reg = &registers_36bit_dma[i];
> +
> +			seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
> +				reg->name,
> +				reg->offset,
> +				mxc_isi_read(pipe, reg->offset));

Lines should be aligned under the "m" of the first line.

I'll fix these small issues when applying, no need to send a v3.

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> +		}
> +	}
> +
>  	pm_runtime_put(pipe->isi->dev);
>  
>  	return 0;

-- 
Regards,

Laurent Pinchart


From catalin.marinas at arm.com  Thu Dec  7 05:55:31 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 7 Dec 2023 13:55:31 +0000
Subject: [PATCH v3 05/25] arm64: context switch POR_EL0 register
In-Reply-To: <ZWHiaTO6VUzHmbDB@finisterre.sirena.org.uk>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-6-joey.gouly@arm.com>
 <ZWHiaTO6VUzHmbDB@finisterre.sirena.org.uk>
Message-ID: <ZXHO0_ypVTUb392K@arm.com>

On Sat, Nov 25, 2023 at 12:02:49PM +0000, Mark Brown wrote:
> On Fri, Nov 24, 2023 at 04:34:50PM +0000, Joey Gouly wrote:
> 
> > +static void flush_poe(void)
> > +{
> > +	if (system_supports_poe())
> > +		write_sysreg_s(POR_EL0_INIT, SYS_POR_EL0);
> > +}
> 
> Here we have no isb()...

My immediate thought was that we'd not care about the ISB here since
we'll have an ERET before getting to EL0. However, we may have some
LDTR/STTR populating the new process args page on exec which may, in
theory, pick up a stale POR_EL0.

-- 
Catalin


From krzysztof.kozlowski at linaro.org  Thu Dec  7 05:57:52 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 14:57:52 +0100
Subject: [PATCH] dt-bindings: marvell: move MMP boards to common marvell
 directory
In-Reply-To: <9c50d09e-98a0-416f-b779-9cf39d1a94b5@lunn.ch>
References: <20231201132306.60753-1-krzysztof.kozlowski@linaro.org>
 <1e25e2f4-e4b9-4219-a9c2-cb6230a62549@lunn.ch>
 <a44b7bb2-34ac-45ab-84c6-630d604f1bcf@linaro.org>
 <5d511e31-8ff5-4c23-a65e-8660833a9799@lunn.ch>
 <944c02f5-d0e6-4367-bb4d-b366054b3e4e@linaro.org>
 <9c50d09e-98a0-416f-b779-9cf39d1a94b5@lunn.ch>
Message-ID: <526bfe1e-7f6a-4402-80d6-2c97a1e3198e@linaro.org>

On 01/12/2023 17:17, Andrew Lunn wrote:
> On Fri, Dec 01, 2023 at 03:38:36PM +0100, Krzysztof Kozlowski wrote:
>> On 01/12/2023 15:34, Andrew Lunn wrote:
>>> On Fri, Dec 01, 2023 at 03:21:05PM +0100, Krzysztof Kozlowski wrote:
>>>> On 01/12/2023 14:51, Andrew Lunn wrote:
>>>>> On Fri, Dec 01, 2023 at 02:23:06PM +0100, Krzysztof Kozlowski wrote:
>>>>>> Marvell board bindings are spread over arm/marvell/ and arm/mrvl/
>>>>>> directories.  Move MMP board bindings from the latter to the former, to
>>>>>> keep all of them together.
>>>>>
>>>>> Hi Krzysztof
>>>>>
>>>>> Did you test get_maintainers.pl? MMP has a different maintainer to
>>>>> many of the other Marvell SoCs. We want emails going to the correct
>>>>> Maintainers, and ideally not spamming the others.
>>>>
>>>> The old binding was not referenced in MAINTAINERS, at least I could not
>>>> find it.
>>>> My change does not affect status quo - orphaned files.
>>>>
>>>> OTOH, some entries like Orion list specific files. Others like Marvell
>>>> list entire directory, which is their mistake in the first place.
>>>>
>>>> There is a mess in this approach, but the mess exists before my patch.
>>>
>>> I think these moved files will now match:
>>>
>>> ARM/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 SOC support
>>> M:      Andrew Lunn <andrew at lunn.ch>
>>> M:      Gregory Clement <gregory.clement at bootlin.com>
>>> M:      Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>>> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>>> S:      Maintained
>>> T:      git git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git
>>> F:      Documentation/devicetree/bindings/arm/marvell/
>>>
>>> But these files are not Gregory or my problem.
>>
>> Yeah, that's what I meant by listing entire directory.
>>
>>>
>>> If they were orphaned before, i would prefer they are either orphaned
>>> after the move, or associated to the correct maintainer. Being
>>> associated to the wrong maintainers is worse than having no
>>> maintainers at all.
>>
>> I can add this to existing maintainers entry. Which one? I see only two
>> ARM/Marvell.
> 
> MMP SUPPORT
> R:      Lubomir Rintel <lkundrak at v3.sk>
> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S:      Odd Fixes
> T:      git git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp.git
> F:      arch/arm/boot/dts/marvell/mmp*
> F:      arch/arm/mach-mmp/
> F:      include/linux/soc/mmp/
> 
> But you also need to modify the ARM/Marvell Kirkwood and ... so that
> it excludes these MMP files.

Let's make it then in subdirectory? There are like 20 items from
Marvell/Kirkwood, so I imagine all apply to it. At least currently they
are applying.

Best regards,
Krzysztof



From ulf.hansson at linaro.org  Thu Dec  7 06:01:25 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 7 Dec 2023 15:01:25 +0100
Subject: [PATCH v3] mmc: mtk-sd: Increase the verbosity of msdc_track_cmd_data
In-Reply-To: <20231201102747.3854573-1-treapking@chromium.org>
References: <20231201102747.3854573-1-treapking@chromium.org>
Message-ID: <CAPDyKFrAvkzgHUttY_mVAHK3HXCV_eE6=KhQkdQyLq22zstX8A@mail.gmail.com>

On Fri, 1 Dec 2023 at 11:27, Pin-yen Lin <treapking at chromium.org> wrote:
>
> This log message is necessary for debugging, so enable it by default to
> debug issues that are hard to reproduce locally.
>
> Signed-off-by: Pin-yen Lin <treapking at chromium.org>

Applied for next, thanks!

Kind regards
Uffe


>
> ---
>
> Changes in v3:
> - Only print the warning when -ETIMEDOUT or not in tuning process
>
> Changes in v2:
> - Use dev_warn() instead of dev_err()
>
>  drivers/mmc/host/mtk-sd.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 97f7c3d4be6e..6ae5e0a9fca9 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -1149,9 +1149,11 @@ static void msdc_recheck_sdio_irq(struct msdc_host *host)
>
>  static void msdc_track_cmd_data(struct msdc_host *host, struct mmc_command *cmd)
>  {
> -       if (host->error)
> -               dev_dbg(host->dev, "%s: cmd=%d arg=%08X; host->error=0x%08X\n",
> -                       __func__, cmd->opcode, cmd->arg, host->error);
> +       if (host->error &&
> +           ((!mmc_op_tuning(cmd->opcode) && !host->hs400_tuning) ||
> +            cmd->error == -ETIMEDOUT))
> +               dev_warn(host->dev, "%s: cmd=%d arg=%08X; host->error=0x%08X\n",
> +                        __func__, cmd->opcode, cmd->arg, host->error);
>  }
>
>  static void msdc_request_done(struct msdc_host *host, struct mmc_request *mrq)
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>


From a0501179 at ti.com  Thu Dec  7 06:06:09 2023
From: a0501179 at ti.com (Anwar, Md Danish)
Date: Thu, 7 Dec 2023 19:36:09 +0530
Subject: [PATCH 3/3] arm64: dts: ti: k3-am642-evm: add overlay for icssg1
 2nd port
In-Reply-To: <20231207132758.wbfn7timsqevdjpu@mortuary>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-4-danishanwar@ti.com>
 <20231207132758.wbfn7timsqevdjpu@mortuary>
Message-ID: <7323e86b-939a-4fd0-aac8-07fa47e00c9d@ti.com>

On 12/7/2023 6:57 PM, Nishanth Menon wrote:
> On 13:49-20231207, MD Danish Anwar wrote:
>> The am642-evm doesn't allow to enable 2 x CPSW3g ports and 2 x ICSSG1 ports
>> all together, so base k3-am642-evm.dts enables by default 2 x CPSW3g ports
>> and 1 x ICSSG1 ports, but it also possible to support 1 x CPSW3g ports and
>> 2 x ICSSG1 ports configuration.
>>
>> This patch adds overlay to support 1 x CPSW3g ports and 2 x ICSSG1 ports
>> configuration:
>> - disable 2nd CPSW3g port
>> - update CPSW3g pinmuxes to not use RGMII2
>> - disable mdio-mux-1 and define mdio-mux-2 to route ICSSG1 MDIO to the
>>   shared DP83869 PHY
>> - add and enable ICSSG1 RGMII2 pinmuxes
>> - enable ICSSG1 MII1 port
>>
>> Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
>> ---
>>  arch/arm64/boot/dts/ti/Makefile               |  2 +
>>  .../dts/ti/k3-am642-evm-icssg1-dualemac.dtso  | 80 +++++++++++++++++++
>>  arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  2 +-
>>  3 files changed, 83 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>>
>> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
>> index 5ef49b02c71f..99a4dce47f02 100644
>> --- a/arch/arm64/boot/dts/ti/Makefile
>> +++ b/arch/arm64/boot/dts/ti/Makefile
>> @@ -35,12 +35,14 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62x-sk-csi2-imx219.dtbo
>>  dtb-$(CONFIG_ARCH_K3) += k3-am62x-sk-hdmi-audio.dtbo
>>  
>>  # Boards with AM64x SoC
>> +k3-am642-evm-icssg1-dtbs := k3-am642-evm.dtb k3-am642-evm-icssg1-dualemac.dtbo
> 
> Why not handle this for CONFIG_OF_ALL_DTBS alone? See commit
> b0044823a6607e535fdb083c89f487fbf183b171
> 

I'll have to look into this.

I am merging this k3-am642-evm-icssg1-dualemac.dtbo with
k3-am642-evm.dtb because when I had posted patches for AM65x DTS, Andrew
had commented [1] saying we should not leave orphan dtbos and every dtbo
should be applied over some dtb by using `dtb- +=`.

Due to this I am applying the overlay on k3-am642-evm.dtb and creating
new dtb k3-am642-evm-icssg1.dtb which can be used when both ICSSG1 ports
are needed to be enabled.

[1] https://lore.kernel.org/all/ca832fe3-d5cf-b075-324b-50da40794bb7 at ti.com/

>>  dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
>>  dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
>> +dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-icssg1.dtb
>>  
>>  # Boards with AM65x SoC
>>  k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb k3-am654-base-board-rocktech-rk101-panel.dtbo
>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>> new file mode 100644
>> index 000000000000..6f33290c1ad6
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>> @@ -0,0 +1,80 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/**
>> + * DT overlay for enabling 2nd ICSSG1 port on AM642 EVM
>> + *
>> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +/dts-v1/;
>> +/plugin/;
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include "k3-pinctrl.h"
>> +
>> +&{/} {
>> +	aliases {
>> +		ethernet1 = "/icssg1-eth/ethernet-ports/port at 0";
>> +		ethernet2 = "/icssg1-eth/ethernet-ports/port at 1";
> 
> I don't understand what you are overriding here. isn't patch #2 in your
> series already introducing this in the base dts?
> 

Sorry, My bad. I will remove this in v2.

>> +	};
>> +
>> +	mdio-mux-2 {
>> +		compatible = "mdio-mux-multiplexer";
>> +		mux-controls = <&mdio_mux>;
>> +		mdio-parent-bus = <&icssg1_mdio>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		mdio at 0 {
>> +			reg = <0x0>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			icssg1_phy2: ethernet-phy at 3 {
>> +				reg = <3>;
>> +				tx-internal-delay-ps = <250>;
>> +				rx-internal-delay-ps = <2000>;
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&main_pmx0 {
>> +	icssg1_rgmii2_pins_default: icssg1-rgmii2-default-pins {
>> +		pinctrl-single,pins = <
>> +			AM64X_IOPAD(0x0108, PIN_INPUT, 2) /* (W11) PRG1_PRU1_GPO0.RGMII2_RD0 */
>> +			AM64X_IOPAD(0x010c, PIN_INPUT, 2) /* (V11) PRG1_PRU1_GPO1.RGMII2_RD1 */
>> +			AM64X_IOPAD(0x0110, PIN_INPUT, 2) /* (AA12) PRG1_PRU1_GPO2.RGMII2_RD2 */
>> +			AM64X_IOPAD(0x0114, PIN_INPUT, 2) /* (Y12) PRG1_PRU1_GPO3.RGMII2_RD3 */
>> +			AM64X_IOPAD(0x0120, PIN_INPUT, 2) /* (U11) PRG1_PRU1_GPO6.RGMII2_RXC */
>> +			AM64X_IOPAD(0x0118, PIN_INPUT, 2) /* (W12) PRG1_PRU1_GPO4.RGMII2_RX_CTL */
>> +			AM64X_IOPAD(0x0134, PIN_OUTPUT, 2) /* (AA10) PRG1_PRU1_GPO11.RGMII2_TD0 */
>> +			AM64X_IOPAD(0x0138, PIN_OUTPUT, 2) /* (V10) PRG1_PRU1_GPO12.RGMII2_TD1 */
>> +			AM64X_IOPAD(0x013c, PIN_OUTPUT, 2) /* (U10) PRG1_PRU1_GPO13.RGMII2_TD2 */
>> +			AM64X_IOPAD(0x0140, PIN_OUTPUT, 2) /* (AA11) PRG1_PRU1_GPO14.RGMII2_TD3 */
>> +			AM64X_IOPAD(0x0148, PIN_OUTPUT, 2) /* (Y10) PRG1_PRU1_GPO16.RGMII2_TXC */
>> +			AM64X_IOPAD(0x0144, PIN_OUTPUT, 2) /* (Y11) PRG1_PRU1_GPO15.RGMII2_TX_CTL */
>> +		>;
>> +	};
>> +};
>> +
>> +&cpsw3g {
>> +	pinctrl-0 = <&rgmii1_pins_default>;
>> +};
>> +
>> +&cpsw_port2 {
>> +	status = "disabled";
>> +};
>> +
>> +&mdio_mux_1 {
>> +	status = "disabled";
>> +};
>> +
>> +&icssg1_eth {
>> +	pinctrl-0 = <&icssg1_rgmii1_pins_default &icssg1_rgmii2_pins_default>;
> 
> Grrr... No! I have been cleaning up after you folks and you folks should
> take notice.
> 
> pinctrl-0 = <&icssg1_rgmii1_pins_default>, <&icssg1_rgmii2_pins_default>;
> 

Sorry, I was not aware of this. I will change it in v2.

> 
>> +};
>> +
>> +&icssg1_emac1 {
>> +	status = "okay";
>> +	phy-handle = <&icssg1_phy2>;
>> +	phy-mode = "rgmii-id";
>> +};
>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> index 04d1c0602d31..90867090e725 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>> @@ -203,7 +203,7 @@ mdio_mux: mux-controller {
>>  		mux-gpios = <&exp1 12 GPIO_ACTIVE_HIGH>;
>>  	};
>>  
>> -	mdio-mux-1 {
>> +	mdio_mux_1: mdio-mux-1 {
> 
> Commit message doesn't warn me for this change.

Sure. I will add details of this in commit message saying `Add label
name 'mdio_mux_1' for 'mdio-mux-1' node so that the node 'mdio-mux-1'
can be disabled in the overlay using the label name.`

>>  		compatible = "mdio-mux-multiplexer";
>>  		mux-controls = <&mdio_mux>;
>>  		mdio-parent-bus = <&cpsw3g_mdio>;
>> -- 
>> 2.34.1
>>
> 

-- 
Thanks and Regards,
Md Danish Anwar


From maz at kernel.org  Thu Dec  7 06:06:34 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 07 Dec 2023 14:06:34 +0000
Subject: [PATCH v3 15/21] KVM: arm64: Support FEAT_FPMR for guests
In-Reply-To: <08ae06c7-1654-4dfd-a789-b8e13c87d705@sirena.org.uk>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
	<20231205-arm64-2023-dpisa-v3-15-dbcbcd867a7f@kernel.org>
	<87cyvi8kz1.wl-maz@kernel.org>
	<08ae06c7-1654-4dfd-a789-b8e13c87d705@sirena.org.uk>
Message-ID: <87bkb285ud.wl-maz@kernel.org>

On Thu, 07 Dec 2023 12:30:45 +0000,
Mark Brown <broonie at kernel.org> wrote:
> 
> On Thu, Dec 07, 2023 at 08:39:46AM +0000, Marc Zyngier wrote:
> > Mark Brown <broonie at kernel.org> wrote:
> 
> > >  #define HCRX_GUEST_FLAGS \
> > > -	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | \
> > > +	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM | \
> 
> > We really should start making all of these things conditional. See
> > below.
> 
> Is there an overarching theory behind how these things are intended to
> work?  I agree with you that I'd have expected more conditionality here,
> I was trying to fit in with the existing pattern.  It's kind of hard to
> follow what the intention is, I think to some extent due to things
> having evolved over time.

The intention is that *everything* becomes conditional, based on both
the host CPU support and the feature set advertised to the guest.
Which means that we don't stuff that isn't advertised to the guest,
and instead make these things UNDEF. Just like on any real CPU
implementation.

>
> > > @@ -517,7 +519,6 @@ struct kvm_vcpu_arch {
> > >  	enum fp_type fp_type;
> > >  	unsigned int sve_max_vl;
> > >  	u64 svcr;
> > > -	u64 fpmr;
> 
> > Why do this change here? Why isn't done like that the first place?
> 
> It didn't seem right to add the register to struct vcpu_sysreg before it
> was handled by KVM.  As referenced in the cover letter normally this
> wouldn't come up because KVM doesn't rely on the host kernel for
> managing register state so we add KVM support then enable the host
> kernel but for FPSIMD we're reusing fpsimd_save() so we need the host
> kernel support to be in place when we enable KVM.

That doesn't explain why you can't be upfront with it and populate the
FPMR entry. In either case, you are wasting a u64.

> 
> > >  	CGT_MDCR_TDE,
> > > @@ -279,6 +281,12 @@ static const struct trap_bits coarse_trap_bits[] = {
> > >  		.mask		= HCR_TTLBOS,
> > >  		.behaviour	= BEHAVE_FORWARD_ANY,
> > >  	},
> > > +	[CGT_HCRX_EnFPM] = {
> > > +		.index		= HCRX_EL2,
> > > +		.value		= HCRX_EL2_EnFPM,
> > > +		.mask		= HCRX_EL2_EnFPM,
> > > +		.behaviour	= BEHAVE_FORWARD_ANY,
> 
> > This looks wrong. HCRX_EL2.EnFPM is an enable bit.
> 
> Right, it's the wrong way round.
> 
> > > +static void *fpsimd_share_end(struct user_fpsimd_state *fpsimd)
> > > +{
> > > +	void *share_end = fpsimd + 1;
> > > +
> > > +	if (cpus_have_final_cap(ARM64_HAS_FPMR))
> > > +		share_end += sizeof(u64);
> > > +
> > > +	return share_end;
> > > +}
> 
> > This is horrible. Why can't you just have a new structure wrapping
> > both user_fpsimd_state and fpmr? This is going to break in subtle
> > ways, just like the SVE/SME stuff.
> 
> I agree that it's not great, the main issue was that fpsimd_state is
> both already embedded in uw for hardened usercopy and very widely
> referenced by exactly which struct it's in so I was taking a guess as to
> what would get the least objections.  The obvious thing would be to add
> FPMR to uw and share the whole thing with the hypervisor, if people
> don't mind adding another field to uw I could do that?

Either that, or you create a KVM-specific structure that contains
these fields. If that results in KVM changes, so be it. But I won't
take this sort of pointer arithmetic that assumes some pre-defined
layout.

> 
> > >  	vcpu->arch.host_fpsimd_state = kern_hyp_va(fpsimd);
> > > +	if (cpus_have_final_cap(ARM64_HAS_FPMR)) {
> > > +		WARN_ON_ONCE(&current->thread.fpmr + 1 != fpsimd_share_end(fpsimd));
> 
> > How can this happen?
> 
> It shouldn't, but it'd be bad if it did so I put a check in to make sure
> we haven't messed up.

See my earlier point: you shouldn't have to check if you used a data
structure.

> 
> > > +		vcpu->arch.host_fpmr = kern_hyp_va(&current->thread.fpmr);
> > > +	}
> 
> > We really need to stop piling the save/restore of stuff that isn't
> > advertised to the guest.
> 
> I'm not clear what you're referencing here?  The feature is advertised
> to the guest via the ID registers and in the past you've pushed back on
> making things where the state is just a single register like this
> optional.  Do you mean that we should be making this conditional on the
> guest ID registers?  If that is the case is there a plan for how that's
> supposed to work, set flags when kvm_vcpu_run_pid_change() happens for
> example?

See the beginning of this email. It is high time that we stop enabling
everything by default, because this totally breaks VM migration. We
already have a huge backlog of these things, and I don't want to add
more of it.

Which means that at the very least, enabling *any* feature also comes
with sanitising the state one way or another when this feature is
disabled by userspace.

How this is being done is still a work in progress: my current plan is
based on a set of trap bits that are computed on a per-VM basis, and
some side state that indicates whether the trap handling is for
emulation or feature disabling purpose. This will probably reuse the
NV infrastructure which has an exhaustive list of the sysregs that can
be trapped from EL0/EL1.

At the very least, userspace shouldn't be able to observe the state
that a guest isn't supposed to generate, and we should be mindful of
not creating covert channels.

	M.

-- 
Without deviation from the norm, progress is not possible.


From catalin.marinas at arm.com  Thu Dec  7 06:08:29 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 7 Dec 2023 14:08:29 +0000
Subject: [PATCH v3 07/25] arm64: enable the Permission Overlay Extension
 for EL0
In-Reply-To: <20231124163510.1835740-8-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-8-joey.gouly@arm.com>
Message-ID: <ZXHR3YmNjZu92EbZ@arm.com>

On Fri, Nov 24, 2023 at 04:34:52PM +0000, Joey Gouly wrote:
> +#ifdef CONFIG_ARM64_POE
> +static void cpu_enable_poe(const struct arm64_cpu_capabilities *__unused)
> +{
> +	sysreg_clear_set(REG_TCR2_EL1, 0, TCR2_EL1x_E0POE);
> +	sysreg_clear_set(CPACR_EL1, 0, CPACR_ELx_E0POE);
> +}
> +#endif

Don't we need the TCR2_EL1x.POE bit (for EL1) enabled as well? I'm
thinking of the LDXR/STXR instructions accessing user memory (the futex
code).

-- 
Catalin


From dsimic at manjaro.org  Thu Dec  7 06:10:29 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Thu, 07 Dec 2023 15:10:29 +0100
Subject: [PATCH v2] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <CAMpZ1qHUnTDQ78gdrQF9Sx_-XfLM-B+H-0bL1-+twKsno+JOvg@mail.gmail.com>
References: <20231207082200.16388-1-jensenhuang@friendlyarm.com>
 <ebf6cf8ec3b5befd673d295061fa2738@manjaro.org>
 <CAMpZ1qHUnTDQ78gdrQF9Sx_-XfLM-B+H-0bL1-+twKsno+JOvg@mail.gmail.com>
Message-ID: <5e11553952c02ad20591992be4284bbd@manjaro.org>

On 2023-12-07 10:25, Jensen Huang wrote:
> On Thu, Dec 7, 2023 at 4:37?PM Dragan Simic <dsimic at manjaro.org> wrote:
>> 
>> On 2023-12-07 09:21, Jensen Huang wrote:
>> > Possible deadlock scenario (on reboot):
>> > rk3x_i2c_xfer_common(polling)
>> >     -> rk3x_i2c_wait_xfer_poll()
>> >         -> rk3x_i2c_irq(0, i2c);
>> >             --> spin_lock(&i2c->lock);
>> >             ...
>> >         <rk3x i2c interrupt>
>> >         -> rk3x_i2c_irq(0, i2c);
>> >             --> spin_lock(&i2c->lock); (deadlock here)
>> >
>> > Store the IRQ number and disable/enable it around the polling transfer.
>> > This patch has been tested on NanoPC-T4.
>> 
>> In case you haven't already seen the related discussion linked below,
>> please have a look.  I also added more people to the list of 
>> recipients,
>> in an attempt to make everyone aware of the different approaches to
>> solving this issue.
>> 
>> https://lore.kernel.org/all/655177f4.050a0220.d85c9.3ba0 at mx.google.com/T/#m6fc9c214452fec6681843e7f455978c35c6f6c8b
> 
> Thank you for providing the information. I hadn't seen this link 
> before.
> After carefully looking into the related discussion, it appears that
> Dmitry Osipenko is already working on a suitable patch. To avoid 
> duplication
> or conflicts, my patch can be discarded.

Thank you for responding so quickly.  Perhaps it would be best to hear 
from Dmitry as well, before discarding anything.  It's been a while 
since Dmitry wrote about working on the patch, so he might have 
abandoned it.


From broonie at kernel.org  Thu Dec  7 06:12:23 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 7 Dec 2023 14:12:23 +0000
Subject: [PATCH v3 05/25] arm64: context switch POR_EL0 register
In-Reply-To: <ZXHO0_ypVTUb392K@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-6-joey.gouly@arm.com>
 <ZWHiaTO6VUzHmbDB@finisterre.sirena.org.uk>
 <ZXHO0_ypVTUb392K@arm.com>
Message-ID: <6ff480e3-e2d4-472a-ba6f-4037e438f69b@sirena.org.uk>

On Thu, Dec 07, 2023 at 01:55:31PM +0000, Catalin Marinas wrote:
> On Sat, Nov 25, 2023 at 12:02:49PM +0000, Mark Brown wrote:
> > On Fri, Nov 24, 2023 at 04:34:50PM +0000, Joey Gouly wrote:

> > > +static void flush_poe(void)
> > > +{
> > > +	if (system_supports_poe())
> > > +		write_sysreg_s(POR_EL0_INIT, SYS_POR_EL0);
> > > +}

> > Here we have no isb()...

> My immediate thought was that we'd not care about the ISB here since
> we'll have an ERET before getting to EL0. However, we may have some
> LDTR/STTR populating the new process args page on exec which may, in
> theory, pick up a stale POR_EL0.

Yeah, it was a combination of the inconsistency and the lack of clarity
over there being a path which could potentially use POR_EL0 before ERET.
We at least probably need some comments with regard to the requirements
here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/8ed0b76e/attachment.sig>

From alexander.stein at ew.tq-group.com  Thu Dec  7 06:15:10 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 07 Dec 2023 15:15:10 +0100
Subject: [PATCH v2 1/1] media: nxp: imx8-isi-debug: Add missing 36-Bit DMA registers to debugfs output
In-Reply-To: <20231207135539.GJ9675@pendragon.ideasonboard.com>
References: <20231207110918.1338524-1-alexander.stein@ew.tq-group.com> <20231207135539.GJ9675@pendragon.ideasonboard.com>
Message-ID: <10383921.nUPlyArG6x@steina-w>

Am Donnerstag, 7. Dezember 2023, 14:55:39 CET schrieb Laurent Pinchart:
> Hi Alexander,
> 
> Thank you for the patch.
> 
> On Thu, Dec 07, 2023 at 12:09:18PM +0100, Alexander Stein wrote:
> > The extended address registers are missing in the debug output register
> > list. These are only available on 36-Bit DMA platforms. Due to the
> > prolonged name, the output width has to be adjusted as well.
> > 
> > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> > ---
> > Changes in v2:
> > * Split register set into regular and 36-Bit DMA only
> > * Adjust output width to address longer register names
> > 
> > Currently only tested on TQMa8MPxL (imx8mp-tqma8mpql-mba8mpxl.dts)
> > 
> >  .../platform/nxp/imx8-isi/imx8-isi-debug.c    | 28 +++++++++++++++++--
> >  1 file changed, 25 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c index
> > 6709ab7ea1f3..398864b5e506 100644
> > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > @@ -22,10 +22,11 @@ static inline u32 mxc_isi_read(struct mxc_isi_pipe
> > *pipe, u32 reg)> 
> >  static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
> >  {
> >  #define MXC_ISI_DEBUG_REG(name)		{ name, #name }
> > 
> > -	static const struct {
> > +	struct debug_regs {
> > 
> >  		u32 offset;
> >  		const char * const name;
> > 
> > -	} registers[] = {
> > +	};
> > +	static const struct debug_regs registers[] = {
> > 
> >  		MXC_ISI_DEBUG_REG(CHNL_CTRL),
> >  		MXC_ISI_DEBUG_REG(CHNL_IMG_CTRL),
> >  		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF_CTRL),
> > 
> > @@ -67,6 +68,16 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file
> > *m, void *p)> 
> >  		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
> >  		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
> >  	
> >  	};
> > 
> > +	/* There registers contain the upper 4Bits of 36-Bit DMA addresses 
*/
> 
> s/There/These/
> 
> > +	static const struct debug_regs registers_36bit_dma[] = {
> > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
> > +		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),
> > +	};
> > 
> >  	struct mxc_isi_pipe *pipe = m->private;
> >  	unsigned int i;
> > 
> > @@ -77,10 +88,21 @@ static int mxc_isi_debug_dump_regs_show(struct
> > seq_file *m, void *p)> 
> >  	seq_printf(m, "--- ISI pipe %u registers ---\n", pipe->id);
> >  	
> >  	for (i = 0; i < ARRAY_SIZE(registers); ++i)
> > 
> > -		seq_printf(m, "%20s[0x%02x]: 0x%08x\n",
> > +		seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
> > 
> >  			   registers[i].name, registers[i].offset,
> >  			   mxc_isi_read(pipe, registers[i].offset));
> > 
> > +	if (pipe->isi->pdata->has_36bit_dma) {
> > +		for (i = 0; i < ARRAY_SIZE(registers_36bit_dma); ++i) {
> > +			const struct debug_regs *reg = 
&registers_36bit_dma[i];
> > +
> > +			seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
> > +				reg->name,
> > +				reg->offset,
> > +				mxc_isi_read(pipe, reg->offset));
> 
> Lines should be aligned under the "m" of the first line.
> 
> I'll fix these small issues when applying, no need to send a v3.
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

For the records: Also tested on TQMa8MxNL (imx8mn-tqma8mqnl-mba8mx.dts). As 
expected it prints only the same registers as before.

Thanks
Alexander

> 
> > +		}
> > +	}
> > +
> > 
> >  	pm_runtime_put(pipe->isi->dev);
> >  	
> >  	return 0;


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From wenst at chromium.org  Thu Dec  7 06:15:29 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 7 Dec 2023 23:15:29 +0900
Subject: [PATCH v3 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <aaa55b65-0221-48a0-b78a-ff84f210d16b@collabora.com>
References: <20231204084012.2281292-1-wenst@chromium.org> <20231204084012.2281292-7-wenst@chromium.org>
 <ab7988af-e7f9-433d-b35e-138f79ce82c0@collabora.com> <CAGXv+5EyHXWgbvtxx-skzi6FNEnZD8QEHQ2Wq224anY+QKUrew@mail.gmail.com>
 <CAGXv+5H9dkYOUEDEYtDOzH9ma3wxuGMLfWy+9pE2swTFdNxOnQ@mail.gmail.com>
 <CAGXv+5FhTwovv7qztGfC+FG8pb-kzZomRPgKboFYJmBTZ=mj6g@mail.gmail.com> <aaa55b65-0221-48a0-b78a-ff84f210d16b@collabora.com>
Message-ID: <CAGXv+5EtcfvodjPrzAjArJvjAG+qGiPr-B87O8hOUE32emejaA@mail.gmail.com>

On Thu, Dec 7, 2023 at 10:00?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 07/12/23 12:28, Chen-Yu Tsai ha scritto:
> > On Thu, Dec 7, 2023 at 8:23?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >>
> >> On Thu, Dec 7, 2023 at 2:28?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >>>
> >>> On Mon, Dec 4, 2023 at 11:27?PM AngeloGioacchino Del Regno
> >>> <angelogioacchino.delregno at collabora.com> wrote:
> >>>>
> >>>> Il 04/12/23 09:40, Chen-Yu Tsai ha scritto:
> >>>>> Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> >>>>> Krabby design.
> >>>>>
> >>>>> Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> >>>>> convertible device with touchscreen and stylus.
> >>>>>
> >>>>> Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> >>>>> device. It does not have a touchscreen or stylus.
> >>>>>
> >>>>> The two devices both have two variants. The difference is a second
> >>>>> source touchpad controller that shares the same address as the original,
> >>>>> but is incompatible.
> >>>>>
> >>>>> The extra SKU IDs for the Tentacruel devices map to different sensor
> >>>>> components attached to the Embedded Controller. These are not visible
> >>>>> to the main processor.
> >>>>>
> >>>>> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> >>>>> Acked-by: Conor Dooley <conor.dooley at microchip.com>
> >>>>> ---
> >>>>> Changes since v2:
> >>>>> - Picked up Conor's ack
> >>>>> - Rename touchpad to trackpad
> >>>>> - Drop pinctrl properties from trackpad in tentacruel/tentacool second
> >>>>>     source trackpad
> >>>>>
> >>>>> Changes since v1:
> >>>>> - Reorder SKU numbers in descending order.
> >>>>> - Fixed pinconfig node names
> >>>>> - Moved pinctrl-* properties after interrupts-*
> >>>>> - Switched to interrupts-extended for external components
> >>>>> - Marked ADSP as explicitly disabled, with a comment explaining that it
> >>>>>     stalls the system
> >>>>> - Renamed "touchpad" to "trackpad"
> >>>>> - Dropped bogus "no-laneswap" property from it6505 node
> >>>>> - Moved "realtek,jd-src" property to after all the regulator supplies
> >>>>> - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> >>>>> - Renamed "vgpu" regulator name to allow coupling, with a comment
> >>>>>     containing the name used in the design
> >>>>> - Renamed "cr50" node name to "tpm"
> >>>>> - Moved trackpad_pins reference up to i2c2; workaround for second source
> >>>>>     component resource sharing.
> >>>>> - Fix copyright year
> >>>>> - Fixed touchscreen supply name
> >>>>>
> >>>>>    arch/arm64/boot/dts/mediatek/Makefile         |    4 +
> >>>>>    .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
> >>>>>    .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
> >>>>>    .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
> >>>>>    .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
> >>>>>    .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
> >>>>>    .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1719 +++++++++++++++++
> >>>>>    7 files changed, 2003 insertions(+)
> >>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> >>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> >>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> >>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> >>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> >>>>>    create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> >>>>>
> >>>>> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> >>>>> index e6e7592a3645..442af61b1305 100644
> >>>>> --- a/arch/arm64/boot/dts/mediatek/Makefile
> >>>>> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> >>>>> @@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
> >>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
> >>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
> >>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> >>>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
> >>>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
> >>>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> >>>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
> >>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
> >>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
> >>>>>    dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
> >>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> >>>>> new file mode 100644
> >>>>> index 000000000000..9b2b64525961
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> >>>>> @@ -0,0 +1,129 @@
> >>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >>>>> +/*
> >>>>> + * Copyright 2022 Google LLC
> >>>>> + */
> >>>>> +
> >>>>> +/dts-v1/;
> >>>>> +#include "mt8186-corsola.dtsi"
> >>>>> +#include <dt-bindings/gpio/gpio.h>
> >>>>> +
> >>>>> +/ {
> >>>>> +     aliases {
> >>>>> +             i2c4 = &i2c4;
> >>>>> +     };
> >>>>> +};
> >>>>> +
> >>>>> +&dsi_out {
> >>>>> +     remote-endpoint = <&ps8640_in>;
> >>>>> +};
> >>>>> +
> >>>>> +&i2c0 {
> >>>>> +     clock-frequency = <400000>;
> >>>>> +
> >>>>> +     ps8640: edp-bridge at 8 {
> >>>>> +             compatible = "parade,ps8640";
> >>>>> +             reg = <0x8>;
> >>>>> +             powerdown-gpios = <&pio 96 GPIO_ACTIVE_LOW>;
> >>>>> +             reset-gpios = <&pio 98 GPIO_ACTIVE_LOW>;
> >>>>> +             pinctrl-names = "default";
> >>>>> +             pinctrl-0 = <&ps8640_pins>;
> >>>>> +             vdd12-supply = <&mt6366_vrf12_reg>;
> >>>>> +             vdd33-supply = <&mt6366_vcn33_reg>;
> >>>>> +
> >>>>> +             ports {
> >>>>> +                     #address-cells = <1>;
> >>>>> +                     #size-cells = <0>;
> >>>>> +
> >>>>> +                     port at 0 {
> >>>>> +                             reg = <0>;
> >>>>> +
> >>>>> +                             ps8640_in: endpoint {
> >>>>> +                                     remote-endpoint = <&dsi_out>;
> >>>>> +                             };
> >>>>> +                     };
> >>>>> +
> >>>>> +                     port at 1 {
> >>>>> +                             reg = <1>;
> >>>>> +
> >>>>> +                             ps8640_out: endpoint {
> >>>>> +                                     remote-endpoint = <&panel_in>;
> >>>>> +                             };
> >>>>> +                     };
> >>>>> +             };
> >>>>> +
> >>>>> +             aux-bus {
> >>>>> +                     panel {
> >>>>> +                             compatible = "edp-panel";
> >>>>> +                             power-supply = <&pp3300_disp_x>;
> >>>>> +                             backlight = <&backlight_lcd0>;
> >>>>> +
> >>>>> +                             port {
> >>>>> +                                     panel_in: endpoint {
> >>>>> +                                             remote-endpoint = <&ps8640_out>;
> >>>>> +                                     };
> >>>>> +                             };
> >>>>> +                     };
> >>>>> +             };
> >>>>> +     };
> >>>>> +};
> >>>>> +
> >>>>> +&i2c1 {
> >>>>> +     i2c-scl-internal-delay-ns = <10000>;
> >>>>> +
> >>>>> +     touchscreen: touchscreen at 10 {
> >>>>> +             compatible = "hid-over-i2c";
> >>>>> +             reg = <0x10>;
> >>>>> +             interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
> >>>>> +             pinctrl-names = "default";
> >>>>> +             pinctrl-0 = <&touchscreen_pins>;
> >>>>> +             post-power-on-delay-ms = <10>;
> >>>>> +             hid-descr-addr = <0x0001>;
> >>>>> +             vdd-supply = <&pp3300_s3>;
> >>>>> +     };
> >>>>> +};
> >>>>> +
> >>>>> +&i2c4 {
> >>>>> +     pinctrl-names = "default";
> >>>>> +     pinctrl-0 = <&i2c4_pins>;
> >>>>> +     clock-frequency = <400000>;
> >>>>> +     status = "okay";
> >>>>> +
> >>>>> +     proximity at 28 {
> >>>>> +             compatible = "semtech,sx9324";
> >>>>> +             reg = <0x28>;
> >>>>> +             interrupts-extended = <&pio 5 IRQ_TYPE_LEVEL_LOW>;
> >>>>> +             pinctrl-names = "default";
> >>>>> +             pinctrl-0 = <&sar_sensor_pins>;
> >>>>> +             vdd-supply = <&mt6366_vio18_reg>;
> >>>>> +             svdd-supply = <&mt6366_vio18_reg>;
> >>>>> +             #io-channel-cells = <1>;
> >>>>
> >>>>   From the newest DTS coding style document:
> >>>>
> >>>> The following order of properties in device nodes is preferred:
> >>>>
> >>>> 1. compatible
> >>>> 2. reg
> >>>> 3. ranges
> >>>> 4. Standard/common properties (defined by common bindings, e.g. without
> >>>>      vendor-prefixes)
> >>>> 5. Vendor-specific properties
> >>>> 6. status (if applicable)
> >>>> 7. Child nodes, where each node is preceded with a blank line
> >>>>
> >>>> The "status" property is by default "okay", thus it can be omitted.
> >>>>
> >>>> The above-described ordering follows this approach:
> >>>>
> >>>> 1. Most important properties start the node: compatible then bus addressing to
> >>>>      match unit address.
> >>>> 2. Each node will have common properties in similar place.
> >>>> 3. Status is the last information to annotate that device node is or is not
> >>>>      finished (board resources are needed).
> >>>
> >>> Wishing for a checking tool now. :p
> >>>
> >>>> #io-channel-cells goes after `reg` (same for the other instances) :-)
> >>>
> >>> Ack (though it looks weird).
> >>>
> >>>>> +     };
> >>>>> +};
> >>>>> +
> >>>>> +&pio {
> >>>>> +     i2c4_pins: i2c4-pins {
> >>>>> +             pins-bus {
> >>>>> +                     pinmux = <PINMUX_GPIO136__FUNC_SDA4>,
> >>>>> +                              <PINMUX_GPIO135__FUNC_SCL4>;
> >>>>> +                     bias-disable;
> >>>>> +                     drive-strength = <4>;
> >>>>> +                     input-enable;
> >>>>> +             };
> >>>>> +     };
> >>>>> +
> >>>>> +     ps8640_pins: ps8640-pins {
> >>>>> +             pins-pwrdn-rst {
> >>>>> +                     pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
> >>>>> +                              <PINMUX_GPIO98__FUNC_GPIO98>;
> >>>>> +                     output-low;
> >>>>> +             };
> >>>>> +     };
> >>>>> +
> >>>>> +     sar_sensor_pins: sar-sensor-pins {
> >>>>> +             pins-irq {
> >>>>> +                     pinmux = <PINMUX_GPIO5__FUNC_GPIO5>;
> >>>>> +                     input-enable;
> >>>>> +                     bias-pull-up;
> >>>>> +             };
> >>>>> +     };
> >>>>> +};
> >>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> >>>>> new file mode 100644
> >>>>> index 000000000000..9bb64353ca65
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> >>>>> @@ -0,0 +1,57 @@
> >>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >>>>> +/*
> >>>>> + * Copyright 2022 Google LLC
> >>>>> + */
> >>>>> +
> >>>>> +/dts-v1/;
> >>>>> +#include "mt8186-corsola-krabby.dtsi"
> >>>>> +
> >>>>> +/ {
> >>>>> +     model = "Google Tentacool board";
> >>>>> +     compatible = "google,tentacruel-sku327681", "google,tentacruel", "mediatek,mt8186";
> >>>>> +     chassis-type = "laptop";
> >>>>> +};
> >>>>> +
> >>>>> +/* Tentacool omits the pen. */
> >>>>> +&gpio_keys {
> >>>>> +     status = "disabled";
> >>>>> +};
> >>>>> +
> >>>>> +/* Tentacool omits the touchscreen; nothing else is on i2c1. */
> >>>>> +&i2c1 {
> >>>>> +     status = "disabled";
> >>>>> +};
> >>>>> +
> >>>>> +&keyboard_controller {
> >>>>> +     function-row-physmap = <
> >>>>> +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
> >>>>> +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
> >>>>> +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
> >>>>> +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
> >>>>> +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
> >>>>> +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
> >>>>> +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
> >>>>> +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
> >>>>> +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
> >>>>> +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
> >>>>> +     >;
> >>>>> +
> >>>>> +     linux,keymap = <
> >>>>> +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
> >>>>> +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> >>>>> +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> >>>>> +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> >>>>> +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> >>>>> +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> >>>>> +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> >>>>> +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> >>>>> +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> >>>>> +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> >>>>> +             CROS_STD_MAIN_KEYMAP
> >>>>> +     >;
> >>>>> +};
> >>>>> +
> >>>>> +/* Tentacool omits the touchscreen. */
> >>>>> +&touchscreen {
> >>>>> +     status = "disabled";
> >>>>> +};
> >>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> >>>>> new file mode 100644
> >>>>> index 000000000000..c3ae6f9616c8
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> >>>>> @@ -0,0 +1,24 @@
> >>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >>>>> +/*
> >>>>> + * Copyright 2023 Google LLC
> >>>>> + */
> >>>>> +
> >>>>> +#include "mt8186-corsola-tentacool-sku327681.dts"
> >>>>> +
> >>>>> +/ {
> >>>>> +     compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
> >>>>> +};
> >>>>> +
> >>>>> +/* This variant replaces only the trackpad controller. */
> >>>>> +&i2c2 {
> >>>>> +     /delete-node/ trackpad at 15;
> >>>>
> >>>> Why are you deleting the trackpad at 15 node?
> >>>>
> >>>> You can simply override the compatible, or actually omit the compatible string
> >>>> in the *.dtsi file, and set just that in each board *.dts.
> >>>>
> >>>> dtsi:
> >>>>          trackpad_a: trackpad at 15 {
> >>>>                  /* Compatible is set in each board dts */
> >>>>                  reg, interrupts, others
> >>>>          }
> >>>>
> >>>> dts:
> >>>>
> >>>> &trackpad_a {
> >>>>          compatible = "elan,ekth3000";
> >>>> };
> >>>
> >>> The original trackpad at 15 comes from the base design and is used for all
> >>> models other than the ones with the conflicting component. Hence I believe
> >>> it should live in the base .dtsi.
> >>>
> >>> The delete-node makes it much less likely to have any lingering properties.
> >>> These are not nodes that just differ in compatible strings like DSI panels.
> >>> They have incompatible bindings. For example, elan,ekth3000 uses "vcc-supply",
> >>> while "hid-over-i2c" uses "vdd-supply".
> >>>
> >>> And going back to my previous argument, the base design used one specific
> >>> model which is carried over to all the other models.
> >>>
> >>> Suppose I add a phandle to the original trackpad, and do
> >>>
> >>>      /delete-node/ &trackpad;
> >>>
> >>> Would that be better?
> >>>
> >>>> other dts:
> >>>>
> >>>> &trackpad_a {
> >>>>          compatible = "hid-over-i2c";
> >>>> };
> >>>>
> >>>>> +
> >>>>> +     trackpad at 15 {
> >>>>> +             compatible = "hid-over-i2c";
> >>>>> +             reg = <0x15>;
> >>>>> +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> >>>>> +             hid-descr-addr = <0x0001>;
> >>>>> +             vdd-supply = <&pp3300_s3>;
> >>>>> +             wakeup-source;
> >>>>> +     };
> >>>>> +};
> >>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> >>>>> new file mode 100644
> >>>>> index 000000000000..26d3451a5e47
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> >>>>> @@ -0,0 +1,44 @@
> >>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >>>>> +/*
> >>>>> + * Copyright 2022 Google LLC
> >>>>> + */
> >>>>> +
> >>>>> +/dts-v1/;
> >>>>> +#include "mt8186-corsola-krabby.dtsi"
> >>>>> +
> >>>>> +/ {
> >>>>> +     model = "Google Tentacruel board";
> >>>>> +     compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
> >>>>> +                  "google,tentacruel-sku262145", "google,tentacruel-sku262144",
> >>>>> +                  "google,tentacruel", "mediatek,mt8186";
> >>>>> +     chassis-type = "convertible";
> >>>>> +};
> >>>>> +
> >>>>> +&keyboard_controller {
> >>>>> +     function-row-physmap = <
> >>>>> +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
> >>>>> +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
> >>>>> +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
> >>>>> +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
> >>>>> +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
> >>>>> +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
> >>>>> +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
> >>>>> +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
> >>>>> +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
> >>>>> +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
> >>>>> +     >;
> >>>>> +
> >>>>> +     linux,keymap = <
> >>>>> +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
> >>>>> +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> >>>>> +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> >>>>> +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> >>>>> +             MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
> >>>>> +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
> >>>>> +             MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
> >>>>> +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> >>>>> +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> >>>>> +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> >>>>> +             CROS_STD_MAIN_KEYMAP
> >>>>> +     >;
> >>>>> +};
> >>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> >>>>> new file mode 100644
> >>>>> index 000000000000..447b57b12b41
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> >>>>> @@ -0,0 +1,26 @@
> >>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >>>>> +/*
> >>>>> + * Copyright 2023 Google LLC
> >>>>> + */
> >>>>> +
> >>>>> +#include "mt8186-corsola-tentacruel-sku262144.dts"
> >>>>> +
> >>>>> +/ {
> >>>>> +     compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> >>>>> +                  "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> >>>>> +                  "google,tentacruel", "mediatek,mt8186";
> >>>>> +};
> >>>>> +
> >>>>> +/* This variant replaces only the trackpad controller. */
> >>>>> +&i2c2 {
> >>>>> +     /delete-node/ trackpad at 15;
> >>>>> +
> >>>>> +     trackpad at 15 {
> >>>>> +             compatible = "hid-over-i2c";
> >>>>> +             reg = <0x15>;
> >>>>> +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> >>>>> +             hid-descr-addr = <0x0001>;
> >>>>> +             vdd-supply = <&pp3300_s3>;
> >>>>> +             wakeup-source;
> >>>>> +     };
> >>>>> +};
> >>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> >>>>> new file mode 100644
> >>>>> index 000000000000..8726b2916ef1
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> >>>>> @@ -0,0 +1,1719 @@
> >>>>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >>>>> +/*
> >>>>> + * Copyright (C) 2022 MediaTek Inc.
> >>>>> + */
> >>>>> +/dts-v1/;
> >>>>> +#include "mt8186.dtsi"
> >>>>> +#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
> >>>>> +#include <dt-bindings/gpio/gpio.h>
> >>>>> +#include <dt-bindings/input/input.h>
> >>>>> +#include <dt-bindings/input/gpio-keys.h>
> >>>>> +#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
> >>>>> +
> >>>>> +/ {
> >>>>> +     aliases {
> >>>>> +             i2c0 = &i2c0;
> >>>>> +             i2c1 = &i2c1;
> >>>>> +             i2c2 = &i2c2;
> >>>>> +             i2c3 = &i2c3;
> >>>>> +             i2c5 = &i2c5;
> >>>>> +             mmc0 = &mmc0;
> >>>>> +             mmc1 = &mmc1;
> >>>>> +             serial0 = &uart0;
> >>>>> +     };
> >>>>> +
> >>>>> +     chosen {
> >>>>> +             stdout-path = "serial0:115200n8";
> >>>>> +     };
> >>>>> +
> >>>>> +     memory at 40000000 {
> >>>>> +             device_type = "memory";
> >>>>> +             /* The size should be filled in by the bootloader. */
> >>>>> +             reg = <0 0x40000000 0 0>;
> >>>>> +     };
> >>>>> +
> >>>>> +     backlight_lcd0: backlight-lcd0 {
> >>>>> +             compatible = "pwm-backlight";
> >>>>> +             pwms = <&pwm0 0 500000>;
> >>>>> +             power-supply = <&ppvar_sys>;
> >>>>> +             enable-gpios = <&pio 152 0>;
> >>>>> +             brightness-levels = <0 1023>;
> >>>>> +             num-interpolated-steps = <1023>;
> >>>>> +             default-brightness-level = <576>;
> >>>>> +     };
> >>>>> +
> >>>>> +     btsco: bt-sco {
> >>>>
> >>>> Do you really need the phandle to bt-sco?
> >>>
> >>> No. But the sound node probably should be referencing it and the dmic
> >>> node via DT instead of hardcoding the DAI and codec names in the machine
> >>> driver.
> >>>
> >>> Anyway, will remove the label for now.
> >>>
> >>>> Also, this node describes a codec, so: "bt-sco-codec" please!
> >>>
> >>> Ack.
> >>>
> >>>>> +             compatible = "linux,bt-sco";
> >>>>> +             #sound-dai-cells = <0>;
> >>>>> +     };
> >>>>> +
> >>>>> +     dmic_codec: dmic-codec {
> >>>>
> >>>> This phandle is unused...
> >>>
> >>> Removed.
> >>>
> >>>> ..snip..
> >>>>
> >>>>> +
> >>>>> +&adsp {
> >>>>> +     memory-region = <&adsp_dma_mem>, <&adsp_mem>;
> >>>>> +     status = "disabled"; /* causes stall */
> >>>>
> >>>> This is a firmware issue: once the correct firmware is uploaded to linux-firmware
> >>>> the dsp node can get enabled... so it we make sure that this happens before this
> >>>> devicetree gets picked, we can avoid a second commit enabling audio.
> >>>>
> >>>> After all, since we *want to* use the Xtensa DSP for audio, without it booted
> >>>> sound won't work *anyway*.... so having the firmware in place can also be seen
> >>>> as a direct dependency of the entire audio functionality.
> >>>>
> >>>> P.S.: The FW that is distributed with ChromeOS works just fine!
> >>>
> >>> I'll give that a try.
> >>
> >> I have:
> >>
> >> sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-5494c
> >> sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
> >> sof-audio-of-mt8186 10680000.adsp: unknown sof_ext_man header type 3 size 0x30
> >> sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-5494c
> >>
> >> and it's still hanging.
> >
> > Looks like I was still using the bad version due to module options...
> >
> > After removing the options, I now have:
> >
> > sof-audio-of-mt8186 10680000.adsp: DT DSP detected
> > sof-audio-of-mt8186 10680000.adsp: assigned reserved memory node memory at 61000000
> > sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-714c6
> > sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
> > sof-audio-of-mt8186 10680000.adsp: unknown sof_ext_man header type 3 size 0x30
> > sof-audio-of-mt8186 10680000.adsp: Firmware info: version 2:0:0-714c6
> > sof-audio-of-mt8186 10680000.adsp: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
> >
> > But sound is still deferring probe:
> >
> > # cat /sys/kernel/debug/devices_deferred
> > sound    mt8186_mt6366_rt1019_rt5682s:
> > mt8186_mt6366_rt1019_rt5682s_dev_probe snd_soc_register_card fail
> >
>
> Yes, this happens because of the missing IT6505 HDMI audio support - but it's not
> giving any side effect anyway... in this case, as far as DT is concerned... there
> will be no change, and no side effects on working parts of the system, so we can
> (imo) upstream this even if the driver-code-only dependency is not there yet.

I have the it6505 audio patches backported. But maybe they don't actually
work anymore. :(

> Cheers!
> Angelo
>
> > ChenYu
> >
> >> And FTR, I think sound is also blocked on the it6505 audio support series.
> >>
> >> ChenYu
> >>
> >>
> >>
> >>>>> +};
> >>>>> +
> >>>>> +&afe {
> >>>>> +     i2s0-share = "I2S1";
> >>>>> +     i2s3-share = "I2S2";
> >>>>> +     status = "okay";
> >>>>> +};
> >>>>> +
> >>>>
> >>>> ..snip..
> >>>>
> >>>>> +&i2c2 {
> >>>>> +     pinctrl-names = "default";
> >>>>> +     /*
> >>>>> +      * Trackpad pin put here to work around second source components
> >>>>> +      * sharing the pinmux in steelix designs.
> >>>>> +      */
> >>>>> +     pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
> >>>>
> >>>> There's no choice for now... even if this is not beautiful to see... but it's still
> >>>> ok for me because we can revisit this later when the HW Prober mechanism will be
> >>>> upstreamed.
> >>>
> >>> Yup. Working on that.
> >>>
> >>>>> +     clock-frequency = <400000>;
> >>>>> +     i2c-scl-internal-delay-ns = <10000>;
> >>>>> +     status = "okay";
> >>>>> +
> >>>>> +     trackpad at 15 {
> >>>>> +             compatible = "elan,ekth3000";
> >>>>> +             reg = <0x15>;
> >>>>> +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> >>>>> +             vcc-supply = <&pp3300_s3>;
> >>>>> +             wakeup-source;
> >>>>> +     };
> >>>>> +};
> >>>>> +
> >>>>
> >>>> Thanks,
> >>>> Angelo
> >>>
> >>> Thanks for the review again.
> >>>
> >>> ChenYu
>


From ulf.hansson at linaro.org  Thu Dec  7 06:16:46 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 7 Dec 2023 15:16:46 +0100
Subject: [PATCH v4 0/2] mmc: mediatek: add support for 64-steps tuning
In-Reply-To: <20231207063535.29546-1-axe.yang@mediatek.com>
References: <20231207063535.29546-1-axe.yang@mediatek.com>
Message-ID: <CAPDyKFoFexzhQ59O-v1X_QjgztYZbHfQtKqGKsHsnmU6Bf75YQ@mail.gmail.com>

On Thu, 7 Dec 2023 at 07:35, Axe Yang <axe.yang at mediatek.com> wrote:
>
> Change in v4:
> - for SD/SDIO, tune 64 steps by default
> - reduce some breaks to improve code readability
>
> Change in v3:
> - use BIT_ULL() instead of BIT() to avoid potential left shift operations
>   that could cause exceed boundary problem on 32-bit platforms
>
> Change in v2:
> - move the change made to document to the front
> - change mediatek,tune-step dts property type to enum for better scalability
>
> Axe Yang (2):
>   dt-bindings: mmc: mtk-sd: add tuning steps related property
>   mmc: mediatek: extend number of tuning steps
>
>  .../devicetree/bindings/mmc/mtk-sd.yaml       |   9 +
>  drivers/mmc/host/mtk-sd.c                     | 158 ++++++++++++------
>  2 files changed, 119 insertions(+), 48 deletions(-)
>

Applied for next, thanks!

Kind regards
Uffe


From dario.binacchi at amarulasolutions.com  Thu Dec  7 06:16:29 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Thu,  7 Dec 2023 15:16:29 +0100
Subject: [PATCH v5 00/10] Add displays support for bsh-smm-s2/pro boards
Message-ID: <20231207141723.108004-1-dario.binacchi@amarulasolutions.com>

The series adds drivers for the displays used by bsh-smm-s2/pro boards.
This required applying some patches to the samsung-dsim driver and the
drm_bridge.c module.

Changes in v5:
- Replace a 'return ret' with a 'goto fail' in the r63353_panel_activate()
- Add 'Reviewed-by' tag of Krzysztof Kozlowski

Changes in v4:
- Set the reset gpio to low in a single operation
- Remove duplicated code for prepare/unprepare callbacks
- Remove duplicated code for prepare/unprepare callbacks
- Add Reviewed-by tag of Neil Armstrong

Changes in v3:
- Add 'Reviewed-by' tag of Krzysztof Kozlowski.
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Drop power-supply
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties
- Adjust the timings of the panel reset
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Dario Binacchi (4):
  drm/bridge: Fix bridge disable logic
  drm/bridge: Fix a use case in the bridge disable logic
  drm: bridge: samsung-dsim: enter display mode in the enable() callback
  drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Michael Trimarchi (6):
  dt-bindings: display: panel: Add synaptics r63353 panel controller
  drm/panel: Add Synaptics R63353 panel driver
  dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  drm/panel: Add Ilitek ILI9805 panel driver
  drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup

 .../display/panel/ilitek,ili9805.yaml         |  62 +++
 .../display/panel/synaptics,r63353.yaml       |  61 +++
 MAINTAINERS                                   |  12 +
 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++
 drivers/gpu/drm/bridge/samsung-dsim.c         |  14 +-
 drivers/gpu/drm/drm_bridge.c                  |   9 +-
 drivers/gpu/drm/panel/Kconfig                 |  18 +
 drivers/gpu/drm/panel/Makefile                |   2 +
 drivers/gpu/drm/panel/panel-ilitek-ili9805.c  | 406 ++++++++++++++++++
 .../gpu/drm/panel/panel-synaptics-r63353.c    | 363 ++++++++++++++++
 11 files changed, 1062 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
 create mode 100644 Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9805.c
 create mode 100644 drivers/gpu/drm/panel/panel-synaptics-r63353.c

-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Thu Dec  7 06:16:39 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Thu,  7 Dec 2023 15:16:39 +0100
Subject: [PATCH v5 10/10] arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup
In-Reply-To: <20231207141723.108004-1-dario.binacchi@amarulasolutions.com>
References: <20231207141723.108004-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231207141723.108004-11-dario.binacchi@amarulasolutions.com>

From: Michael Trimarchi <michael at amarulasolutions.com>

Add the display and nodes required for its operation.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>

---

(no changes since v3)

Changes in v3:
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++++++++++++++
 2 files changed, 122 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
index 22a754d438f1..bbb07c650da9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
@@ -7,6 +7,7 @@
 /dts-v1/;
 
 #include "imx8mn.dtsi"
+#include "imx8mn-bsh-smm-s2-display.dtsi"
 
 / {
 	chosen {
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
new file mode 100644
index 000000000000..f0a924cbe548
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 BSH
+ */
+
+/ {
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm1 0 700000 0>;	/* 700000 ns = 1337Hz */
+		brightness-levels = <0 100>;
+		num-interpolated-steps = <100>;
+		default-brightness-level = <50>;
+		status = "okay";
+	};
+
+	reg_3v3_dvdd: regulator-3v3-O3 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_dvdd>;
+		regulator-name = "3v3-dvdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
+	};
+
+	reg_v3v3_avdd: regulator-3v3-O2 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_avdd>;
+		regulator-name = "3v3-avdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 5 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pwm1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_bl>;
+};
+
+&lcdif {
+	status = "okay";
+	assigned-clocks = <&clk IMX8MN_VIDEO_PLL1>;
+	assigned-clock-rates = <594000000>;
+};
+
+&pgc_dispmix {
+	assigned-clocks = <&clk IMX8MN_CLK_DISP_AXI>, <&clk IMX8MN_CLK_DISP_APB>;
+	assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_1000M>, <&clk IMX8MN_SYS_PLL1_800M>;
+	assigned-clock-rates = <500000000>, <200000000>;
+};
+
+&mipi_dsi {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+	samsung,esc-clock-frequency = <20000000>;
+	samsung,pll-clock-frequency = <12000000>;
+
+	panel at 0 {
+		compatible = "sharp,ls068b3sx02", "syna,r63353";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel>;
+		reg = <0>;
+
+		backlight = <&backlight>;
+		dvdd-supply = <&reg_3v3_dvdd>;
+		avdd-supply = <&reg_v3v3_avdd>;
+		reset-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+
+		port {
+			panel_in: endpoint {
+				remote-endpoint = <&mipi_dsi_out>;
+			};
+		};
+
+	};
+
+	ports {
+		port at 1 {
+			reg = <1>;
+			mipi_dsi_out: endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+	};
+};
+
+&gpu {
+	status = "okay";
+};
+
+&iomuxc {
+
+	/* This is for both PWM and voltage regulators for display */
+	pinctrl_bl: pwm1grp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO01_PWM1_OUT	0x16
+		>;
+	};
+
+	pinctrl_panel: panelgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_SAI3_RXC_GPIO4_IO29	0x16	/* panel reset */
+		>;
+	};
+
+	pinctrl_dvdd: dvddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x16	/* VDD 3V3_VO3 */
+		>;
+	};
+
+	pinctrl_avdd: avddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO05_GPIO1_IO5	0x16	/* VDD 3V3_VO2 */
+		>;
+	};
+};
-- 
2.43.0



From ravi.bangoria at amd.com  Thu Dec  7 06:21:43 2023
From: ravi.bangoria at amd.com (Ravi Bangoria)
Date: Thu, 7 Dec 2023 19:51:43 +0530
Subject: [PATCH 1/6] perf mem: Add mem_events into the supported perf_pmu
In-Reply-To: <20231206201324.184059-2-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
 <20231206201324.184059-2-kan.liang@linux.intel.com>
Message-ID: <13272300-1d7e-92e8-020e-54d9cfd12ca7@amd.com>

Hi Kan,

> +void perf_pmu__arch_init(struct perf_pmu *pmu)
> +{
> +	if (strcmp(pmu->name, "arm_spe_0"))

if (!strcmp(...))

> +	if (x86__is_amd_cpu()) {
> +		if (strcmp(pmu->name, "ibs_op"))

Ditto.

Thanks,
Ravi


From kan.liang at linux.intel.com  Thu Dec  7 06:27:14 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Thu, 7 Dec 2023 09:27:14 -0500
Subject: [PATCH 1/6] perf mem: Add mem_events into the supported perf_pmu
In-Reply-To: <13272300-1d7e-92e8-020e-54d9cfd12ca7@amd.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
 <20231206201324.184059-2-kan.liang@linux.intel.com>
 <13272300-1d7e-92e8-020e-54d9cfd12ca7@amd.com>
Message-ID: <c5e76546-c3e9-494b-a43c-3c088ad77167@linux.intel.com>



On 2023-12-07 9:21 a.m., Ravi Bangoria wrote:
> Hi Kan,
> 
>> +void perf_pmu__arch_init(struct perf_pmu *pmu)
>> +{
>> +	if (strcmp(pmu->name, "arm_spe_0"))
> 
> if (!strcmp(...))
> 
>> +	if (x86__is_amd_cpu()) {
>> +		if (strcmp(pmu->name, "ibs_op"))
> 
> Ditto.
> 

Thanks Ravi. I will fix it in V2.

Thanks,
Kan


From wenst at chromium.org  Thu Dec  7 06:27:23 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 7 Dec 2023 22:27:23 +0800
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231203153401.GV8402@pendragon.ideasonboard.com>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com>
Message-ID: <20231207142723.GA3187877@google.com>

On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> Thank you for the patch.
> 
> On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> > 
> > The files compress from about 86MB to 24MB using this approach.
> > 
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> > 
> > Add a 'make image.fit' build target for arm64, as well. Use
> > FIT_COMPRESSION to select a different algorithm.
> > 
> > The FIT can be examined using 'dumpimage -l'.
> > 
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> > 
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
> 
> FIT images are very useful, so I think this is a very welcome addition
> to the kernel build system. It can get tricky though: given the
> versatile nature of FIT images, there can't be any
> one-size-fits-them-all solution to build them, and striking the right
> balance between what makes sense for the kernel and the features that
> users may request will probably lead to bikeshedding. As we all love
> bikeshedding, I thought I would start selfishly, with a personal use
> case :-) This isn't a yak-shaving request though, I don't see any reason
> to delay merging this series.
> 
> Have you envisioned building FIT images with a subset of DTBs, or adding
> DTBOs ? Both would be fairly trivial extensions to this script by
> extending the supported command line arguments. It would perhaps be more
> difficult to integrate in the kernel build system though. This leads me
> to a second question: would you consider merging extensions to this
> script if they are not used by the kernel build system, but meant for
> users who manually invoke the script ? More generally, is the script

We'd also be interested in some customization, though in a different way.
We imagine having a rule file that says X compatible string should map
to A base DTB, plus B and C DTBO for the configuration section. The base
DTB would carry all common elements of some device, while the DTBOs
carry all the possible second source components, like different display
panels or MIPI cameras for instance. This could drastically reduce the
size of FIT images in ChromeOS by deduplicating all the common stuff.

> meant to be used stand-alone as well, in which case its command line
> arguments need to remain backward-compatible, or do you see it as being
> internal to the kernel ?

[...]

ChenYu


From laurent.pinchart at ideasonboard.com  Thu Dec  7 06:28:45 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 16:28:45 +0200
Subject: [PATCH v2 1/1] media: nxp: imx8-isi-debug: Add missing 36-Bit
 DMA registers to debugfs output
In-Reply-To: <10383921.nUPlyArG6x@steina-w>
References: <20231207110918.1338524-1-alexander.stein@ew.tq-group.com>
 <20231207135539.GJ9675@pendragon.ideasonboard.com>
 <10383921.nUPlyArG6x@steina-w>
Message-ID: <20231207142845.GB15521@pendragon.ideasonboard.com>

Hi Alexander,

On Thu, Dec 07, 2023 at 03:15:10PM +0100, Alexander Stein wrote:
> Am Donnerstag, 7. Dezember 2023, 14:55:39 CET schrieb Laurent Pinchart:
> > On Thu, Dec 07, 2023 at 12:09:18PM +0100, Alexander Stein wrote:
> > > The extended address registers are missing in the debug output register
> > > list. These are only available on 36-Bit DMA platforms. Due to the
> > > prolonged name, the output width has to be adjusted as well.
> > > 
> > > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> > > ---
> > > Changes in v2:
> > > * Split register set into regular and 36-Bit DMA only
> > > * Adjust output width to address longer register names
> > > 
> > > Currently only tested on TQMa8MPxL (imx8mp-tqma8mpql-mba8mpxl.dts)
> > > 
> > >  .../platform/nxp/imx8-isi/imx8-isi-debug.c    | 28 +++++++++++++++++--
> > >  1 file changed, 25 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c index
> > > 6709ab7ea1f3..398864b5e506 100644
> > > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > @@ -22,10 +22,11 @@ static inline u32 mxc_isi_read(struct mxc_isi_pipe
> > > *pipe, u32 reg)> 
> > >  static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
> > >  {
> > >  #define MXC_ISI_DEBUG_REG(name)		{ name, #name }
> > > 
> > > -	static const struct {
> > > +	struct debug_regs {
> > > 
> > >  		u32 offset;
> > >  		const char * const name;
> > > 
> > > -	} registers[] = {
> > > +	};
> > > +	static const struct debug_regs registers[] = {
> > > 
> > >  		MXC_ISI_DEBUG_REG(CHNL_CTRL),
> > >  		MXC_ISI_DEBUG_REG(CHNL_IMG_CTRL),
> > >  		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF_CTRL),
> > > 
> > > @@ -67,6 +68,16 @@ static int mxc_isi_debug_dump_regs_show(struct seq_file
> > > *m, void *p)> 
> > >  		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
> > >  		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
> > >  	
> > >  	};
> > > 
> > > +	/* There registers contain the upper 4Bits of 36-Bit DMA addresses */
> > 
> > s/There/These/
> > 
> > > +	static const struct debug_regs registers_36bit_dma[] = {
> > > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
> > > +		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),
> > > +	};
> > > 
> > >  	struct mxc_isi_pipe *pipe = m->private;
> > >  	unsigned int i;
> > > 
> > > @@ -77,10 +88,21 @@ static int mxc_isi_debug_dump_regs_show(struct
> > > seq_file *m, void *p)> 
> > >  	seq_printf(m, "--- ISI pipe %u registers ---\n", pipe->id);
> > >  	
> > >  	for (i = 0; i < ARRAY_SIZE(registers); ++i)
> > > 
> > > -		seq_printf(m, "%20s[0x%02x]: 0x%08x\n",
> > > +		seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
> > > 
> > >  			   registers[i].name, registers[i].offset,
> > >  			   mxc_isi_read(pipe, registers[i].offset));
> > > 
> > > +	if (pipe->isi->pdata->has_36bit_dma) {
> > > +		for (i = 0; i < ARRAY_SIZE(registers_36bit_dma); ++i) {
> > > +			const struct debug_regs *reg = aregisters_36bit_dma[i];
> > > +
> > > +			seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
> > > +				reg->name,
> > > +				reg->offset,
> > > +				mxc_isi_read(pipe, reg->offset));
> > 
> > Lines should be aligned under the "m" of the first line.
> > 
> > I'll fix these small issues when applying, no need to send a v3.
> > 
> > Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> 
> For the records: Also tested on TQMa8MxNL (imx8mn-tqma8mqnl-mba8mx.dts). As 
> expected it prints only the same registers as before.

Thank you. Can I add

    Tested-by: Alexander Stein <alexander.stein at ew.tq-group.com> # on imx8mn

?

> > > +		}
> > > +	}
> > > +
> > > 
> > >  	pm_runtime_put(pipe->isi->dev);
> > >  	
> > >  	return 0;

-- 
Regards,

Laurent Pinchart


From jisheng.teoh at starfivetech.com  Thu Dec  7 06:29:37 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Thu, 7 Dec 2023 22:29:37 +0800
Subject: [PATCH v5 0/3] StarFive's StarLink PMU Support
Message-ID: <20231207142940.1794032-1-jisheng.teoh@starfivetech.com>

Changes since v4:
- Add Reviewed-by tag from Conor to dt-bindings.
- Add Documentation/admin-guide/perf/starfive_starlink_pmu.rst.
- Rework starfive_starlink_pmu.c based on Jonathan's comment.

Changes since v3:
- Change dt-bindings filename along with the compatible field to
   "starfive,jh8100-starlink-pmu" with SOC specific naming
   convention.
- Drop unused label defined in examples section in dt-bindings.
- Update compatible field in starfive_starlink_pmu.c to the
  aforementioned.

Changes since v2:
- Change compatible field from generic "starfive,starlink-pmu"
   to "starfive,starlink-500-pmu" with specific IP versioning
   in bindings and driver.
- Fix warning '-Wmissing-prototypes' reported by kernel test robot,
   by appending static to starlink_pmu_set_event_period() in
   starfive_starlink_pmu.c.

Changes since v1:
- Change 'depends on SOC_STARFIVE' to 'depends on ARCH_STARFIVE'
   in Kconfig

----

This patch series adds support for StarFive's Starlink Performance
Monitor Unit(PMU).
StarFive's StarLink PMU integrates one or more CPU cores with
a shared L3 memory system. The PMU supports overflow interrupt,
up to 16 programmable 64bit event counters, and an independent
64bit cycle counter.
StarLink PMU is accessed via MMIO.

Example Perf stat output:
[root at user]# perf stat -a -e /starfive_starlink_pmu/cycles/ \
        -e /starfive_starlink_pmu/read_miss/ \
        -e /starfive_starlink_pmu/read_hit/ \
        -e /starfive_starlink_pmu/release_request/  \
        -e /starfive_starlink_pmu/write_hit/ \
        -e /starfive_starlink_pmu/write_miss/ \
        -e /starfive_starlink_pmu/write_request/ \
        -e /starfive_starlink_pmu/writeback/ \
        -e /starfive_starlink_pmu/read_request/ \
        -- openssl speed rsa2048
Doing 2048 bits private rsa's for 10s: 5 2048 bits private RSA's in
2.84s
Doing 2048 bits public rsa's for 10s: 169 2048 bits public RSA's in
2.42s
version: 3.0.11
built on: Tue Sep 19 13:02:31 2023 UTC
options: bn(64,64)
CPUINFO: N/A
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.568000s 0.014320s      1.8     69.8
/////////
 Performance counter stats for 'system wide':

         649991998      starfive_starlink_pmu/cycles/
           1009690      starfive_starlink_pmu/read_miss/
           1079750      starfive_starlink_pmu/read_hit/
           2089405      starfive_starlink_pmu/release_request/
               129      starfive_starlink_pmu/write_hit/
                70      starfive_starlink_pmu/write_miss/
               194      starfive_starlink_pmu/write_request/
            150080      starfive_starlink_pmu/writeback/
           2089423      starfive_starlink_pmu/read_request/

      27.062755678 seconds time elapsed

Ji Sheng Teoh (3):
  perf: starfive: Add StarLink PMU support
  dt-bindings: perf: starfive: Add JH8100 StarLink PMU
  docs: perf: Add description for StarFive's StarLink PMU

 Documentation/admin-guide/perf/index.rst      |   1 +
 .../perf/starfive_starlink_pmu.rst            |  46 ++
 .../perf/starfive,jh8100-starlink-pmu.yaml    |  46 ++
 drivers/perf/Kconfig                          |   9 +
 drivers/perf/Makefile                         |   1 +
 drivers/perf/starfive_starlink_pmu.c          | 643 ++++++++++++++++++
 6 files changed, 746 insertions(+)
 create mode 100644 Documentation/admin-guide/perf/starfive_starlink_pmu.rst
 create mode 100644 Documentation/devicetree/bindings/perf/starfive,jh8100-starlink-pmu.yaml
 create mode 100644 drivers/perf/starfive_starlink_pmu.c

-- 
2.25.1



From jisheng.teoh at starfivetech.com  Thu Dec  7 06:29:39 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Thu, 7 Dec 2023 22:29:39 +0800
Subject: [PATCH v5 2/3] dt-bindings: perf: starfive: Add JH8100 StarLink PMU
In-Reply-To: <20231207142940.1794032-1-jisheng.teoh@starfivetech.com>
References: <20231207142940.1794032-1-jisheng.teoh@starfivetech.com>
Message-ID: <20231207142940.1794032-3-jisheng.teoh@starfivetech.com>

Add device tree binding for StarFive's JH8100 StarLink PMU (Performance
Monitor Unit).

Signed-off-by: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
---
 .../perf/starfive,jh8100-starlink-pmu.yaml    | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/perf/starfive,jh8100-starlink-pmu.yaml

diff --git a/Documentation/devicetree/bindings/perf/starfive,jh8100-starlink-pmu.yaml b/Documentation/devicetree/bindings/perf/starfive,jh8100-starlink-pmu.yaml
new file mode 100644
index 000000000000..915c6b814026
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/starfive,jh8100-starlink-pmu.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/starfive,jh8100-starlink-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH8100 StarLink PMU
+
+maintainers:
+  - Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
+
+description:
+  StarFive's JH8100 StarLink PMU integrates one or more CPU cores with a
+  shared L3 memory system. The PMU support overflow interrupt, up to
+  16 programmable 64bit event counters, and an independent 64bit cycle
+  counter. StarFive's JH8100 StarLink PMU is accessed via MMIO.
+
+properties:
+  compatible:
+    const: starfive,jh8100-starlink-pmu
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pmu at 12900000 {
+            compatible = "starfive,jh8100-starlink-pmu";
+            reg = <0x0 0x12900000 0x0 0x10000>;
+            interrupts = <34>;
+        };
+    };
-- 
2.25.1



From jisheng.teoh at starfivetech.com  Thu Dec  7 06:29:38 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Thu, 7 Dec 2023 22:29:38 +0800
Subject: [PATCH v5 1/3] perf: starfive: Add StarLink PMU support
In-Reply-To: <20231207142940.1794032-1-jisheng.teoh@starfivetech.com>
References: <20231207142940.1794032-1-jisheng.teoh@starfivetech.com>
Message-ID: <20231207142940.1794032-2-jisheng.teoh@starfivetech.com>

This patch adds support for StarFive's StarLink PMU (Performance
Monitor Unit). StarLink PMU integrates one or more CPU cores with
a shared L3 memory system. The PMU supports overflow interrupt,
up to 16 programmable 64bit event counters, and an independent
64bit cycle counter. StarLink PMU is accessed via MMIO.

Example Perf stat output:
[root at user]# perf stat -a -e /starfive_starlink_pmu/cycles/ \
	-e /starfive_starlink_pmu/read_miss/ \
	-e /starfive_starlink_pmu/read_hit/ \
	-e /starfive_starlink_pmu/release_request/  \
	-e /starfive_starlink_pmu/write_hit/ \
	-e /starfive_starlink_pmu/write_miss/ \
	-e /starfive_starlink_pmu/write_request/ \
	-e /starfive_starlink_pmu/writeback/ \
	-e /starfive_starlink_pmu/read_request/ \
	-- openssl speed rsa2048
Doing 2048 bits private rsa's for 10s: 5 2048 bits private RSA's in
2.84s
Doing 2048 bits public rsa's for 10s: 169 2048 bits public RSA's in
2.42s
version: 3.0.11
built on: Tue Sep 19 13:02:31 2023 UTC
options: bn(64,64)
CPUINFO: N/A
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.568000s 0.014320s      1.8     69.8
/////////
 Performance counter stats for 'system wide':

         649991998      starfive_starlink_pmu/cycles/
           1009690      starfive_starlink_pmu/read_miss/
           1079750      starfive_starlink_pmu/read_hit/
           2089405      starfive_starlink_pmu/release_request/
               129      starfive_starlink_pmu/write_hit/
                70      starfive_starlink_pmu/write_miss/
               194      starfive_starlink_pmu/write_request/
            150080      starfive_starlink_pmu/writeback/
           2089423      starfive_starlink_pmu/read_request/

      27.062755678 seconds time elapsed

Signed-off-by: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
---
 drivers/perf/Kconfig                 |   9 +
 drivers/perf/Makefile                |   1 +
 drivers/perf/starfive_starlink_pmu.c | 643 +++++++++++++++++++++++++++
 3 files changed, 653 insertions(+)
 create mode 100644 drivers/perf/starfive_starlink_pmu.c

diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 273d67ecf6d2..41278742ef88 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -86,6 +86,15 @@ config RISCV_PMU_SBI
 	  full perf feature support i.e. counter overflow, privilege mode
 	  filtering, counter configuration.
 
+config STARFIVE_STARLINK_PMU
+	depends on ARCH_STARFIVE
+	bool "StarFive StarLink PMU"
+	help
+	   Provide support for StarLink Performance Monitor Unit.
+	   StarLink Performance Monitor Unit integrates one or more cores with
+	   an L3 memory system. The L3 cache events are added into perf event
+	   subsystem, allowing monitoring of various L3 cache perf events.
+
 config ARM_PMU_ACPI
 	depends on ARM_PMU && ACPI
 	def_bool y
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 16b3ec4db916..e2153aee1e04 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
 obj-$(CONFIG_RISCV_PMU) += riscv_pmu.o
 obj-$(CONFIG_RISCV_PMU_LEGACY) += riscv_pmu_legacy.o
 obj-$(CONFIG_RISCV_PMU_SBI) += riscv_pmu_sbi.o
+obj-$(CONFIG_STARFIVE_STARLINK_PMU) += starfive_starlink_pmu.o
 obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
 obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
diff --git a/drivers/perf/starfive_starlink_pmu.c b/drivers/perf/starfive_starlink_pmu.c
new file mode 100644
index 000000000000..2447ca09a471
--- /dev/null
+++ b/drivers/perf/starfive_starlink_pmu.c
@@ -0,0 +1,643 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * StarFive's StarLink PMU driver
+ *
+ * Copyright (C) 2023 StarFive Technology Co., Ltd.
+ *
+ * Author: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
+ *
+ */
+
+#define STARLINK_PMU_PDEV_NAME	"starfive_starlink_pmu"
+#define pr_fmt(fmt)	STARLINK_PMU_PDEV_NAME ": " fmt
+
+#include <linux/bitmap.h>
+#include <linux/cpu_pm.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/perf_event.h>
+#include <linux/platform_device.h>
+#include <linux/sysfs.h>
+
+#define STARLINK_PMU_MAX_COUNTERS			64
+#define STARLINK_PMU_NUM_COUNTERS			16
+#define STARLINK_PMU_IDX_CYCLE_COUNTER			63
+
+#define STARLINK_PMU_EVENT_SELECT			0x060
+#define STARLINK_PMU_EVENT_COUNTER			0x160
+#define STARLINK_PMU_COUNTER_MASK			GENMASK_ULL(63, 0)
+#define STARLINK_PMU_CYCLE_COUNTER			0x058
+
+#define STARLINK_PMU_CONTROL				0x040
+#define STARLINK_PMU_GLOBAL_ENABLE			BIT(0)
+
+#define STARLINK_PMU_INTERRUPT_ENABLE			0x050
+#define STARLINK_PMU_COUNTER_OVERFLOW_STATUS		0x048
+#define STARLINK_PMU_CYCLE_OVERFLOW_MASK		BIT(63)
+
+#define STARLINK_CYCLES				0x058
+#define CACHE_READ_REQUEST			0x04000701
+#define CACHE_WRITE_REQUEST			0x03000001
+#define CACHE_RELEASE_REQUEST			0x0003e001
+#define CACHE_READ_HIT				0x00901202
+#define CACHE_READ_MISS				0x04008002
+#define CACHE_WRITE_HIT				0x006c0002
+#define CACHE_WRITE_MISS			0x03000002
+#define CACHE_WRITEBACK				0x00000403
+
+#define to_starlink_pmu(p) (container_of(p, struct starlink_pmu, pmu))
+
+#define STARLINK_FORMAT_ATTR(_name, _config)				      \
+	(&((struct dev_ext_attribute[]) {				      \
+		{ .attr = __ATTR(_name, 0444, starlink_pmu_sysfs_format_show, NULL), \
+		  .var = (void *)_config, }				      \
+	})[0].attr.attr)
+
+#define STARLINK_EVENT_ATTR(_name, _id)					     \
+	PMU_EVENT_ATTR_ID(_name, starlink_pmu_sysfs_event_show, _id)
+
+static int starlink_pmu_cpuhp_state;
+
+struct starlink_hw_events {
+	struct perf_event	*events[STARLINK_PMU_MAX_COUNTERS];
+	DECLARE_BITMAP(used_mask, STARLINK_PMU_MAX_COUNTERS);
+};
+
+struct starlink_pmu {
+	struct pmu					pmu;
+	struct starlink_hw_events			__percpu *hw_events;
+	struct hlist_node				node;
+	struct notifier_block				starlink_pmu_pm_nb;
+	void __iomem					*pmu_base;
+	cpumask_t					cpumask;
+	int						irq;
+};
+
+static ssize_t
+starlink_pmu_sysfs_format_show(struct device *dev,
+			       struct device_attribute *attr,
+			       char *buf)
+{
+	struct dev_ext_attribute *eattr = container_of(attr,
+						       struct dev_ext_attribute, attr);
+
+	return sysfs_emit(buf, "%s\n", (char *)eattr->var);
+}
+
+static struct attribute *starlink_pmu_format_attrs[] = {
+	STARLINK_FORMAT_ATTR(event, "config:0-31"),
+	NULL
+};
+
+static const struct attribute_group starlink_pmu_format_attr_group = {
+	.name = "format",
+	.attrs = starlink_pmu_format_attrs,
+};
+
+static ssize_t
+starlink_pmu_sysfs_event_show(struct device *dev,
+			      struct device_attribute *attr,
+			      char *buf)
+{
+	struct perf_pmu_events_attr *eattr = container_of(attr,
+							  struct perf_pmu_events_attr, attr);
+
+	return sysfs_emit(buf, "event=0x%02llx\n", eattr->id);
+}
+
+static struct attribute *starlink_pmu_event_attrs[] = {
+	STARLINK_EVENT_ATTR(cycles, STARLINK_CYCLES),
+	STARLINK_EVENT_ATTR(read_request, CACHE_READ_REQUEST),
+	STARLINK_EVENT_ATTR(write_request, CACHE_WRITE_REQUEST),
+	STARLINK_EVENT_ATTR(release_request, CACHE_RELEASE_REQUEST),
+	STARLINK_EVENT_ATTR(read_hit, CACHE_READ_HIT),
+	STARLINK_EVENT_ATTR(read_miss, CACHE_READ_MISS),
+	STARLINK_EVENT_ATTR(write_hit, CACHE_WRITE_HIT),
+	STARLINK_EVENT_ATTR(write_miss, CACHE_WRITE_MISS),
+	STARLINK_EVENT_ATTR(writeback, CACHE_WRITEBACK),
+	NULL
+};
+
+static const struct attribute_group starlink_pmu_events_attr_group = {
+	.name = "events",
+	.attrs = starlink_pmu_event_attrs,
+};
+
+static ssize_t
+cpumask_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct starlink_pmu *starlink_pmu = to_starlink_pmu(dev_get_drvdata(dev));
+
+	return cpumap_print_to_pagebuf(true, buf, &starlink_pmu->cpumask);
+}
+
+static DEVICE_ATTR_RO(cpumask);
+
+static struct attribute *starlink_pmu_cpumask_attrs[] = {
+	&dev_attr_cpumask.attr,
+	NULL
+};
+
+static const struct attribute_group starlink_pmu_cpumask_attr_group = {
+	.attrs = starlink_pmu_cpumask_attrs,
+};
+
+static const struct attribute_group *starlink_pmu_attr_groups[] = {
+	&starlink_pmu_format_attr_group,
+	&starlink_pmu_events_attr_group,
+	&starlink_pmu_cpumask_attr_group,
+	NULL
+};
+
+static void starlink_pmu_set_event_period(struct perf_event *event)
+{
+	struct starlink_pmu *starlink_pmu = to_starlink_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	int idx = event->hw.idx;
+
+	/*
+	 * Program counter to half of it's max count to handle
+	 * cases of extreme interrupt latency.
+	 */
+	u64 val = STARLINK_PMU_COUNTER_MASK >> 1;
+
+	local64_set(&hwc->prev_count, val);
+	if (hwc->config == STARLINK_CYCLES)
+		writeq(val, starlink_pmu->pmu_base + STARLINK_PMU_CYCLE_COUNTER);
+	else
+		writeq(val, starlink_pmu->pmu_base + STARLINK_PMU_EVENT_COUNTER +
+		       idx * sizeof(u64));
+}
+
+static void starlink_pmu_counter_start(struct perf_event *event,
+				       struct starlink_pmu *starlink_pmu)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	int idx = event->hw.idx;
+	u64 val;
+
+	/*
+	 * Enable counter overflow interrupt[63:0],
+	 * which is mapped as follow:
+	 *
+	 * event counter 0	- Bit [0]
+	 * event counter 1	- Bit [1]
+	 * ...
+	 * cycle counter	- Bit [63]
+	 */
+	val = readq(starlink_pmu->pmu_base + STARLINK_PMU_INTERRUPT_ENABLE);
+
+	if (hwc->config == STARLINK_CYCLES) {
+		/*
+		 * Cycle count has its dedicated register, and it starts
+		 * counting as soon as STARLINK_PMU_GLOBAL_ENABLE is set.
+		 */
+		val |= STARLINK_PMU_CYCLE_OVERFLOW_MASK;
+	} else {
+		writeq(event->hw.config, starlink_pmu->pmu_base +
+		       STARLINK_PMU_EVENT_SELECT + idx * sizeof(u64));
+
+		val |= (1 << idx);
+	}
+
+	writeq(val, starlink_pmu->pmu_base + STARLINK_PMU_INTERRUPT_ENABLE);
+
+	writeq(STARLINK_PMU_GLOBAL_ENABLE, starlink_pmu->pmu_base +
+	       STARLINK_PMU_CONTROL);
+}
+
+static void starlink_pmu_counter_stop(struct perf_event *event,
+				      struct starlink_pmu *starlink_pmu)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	int idx = event->hw.idx;
+	u64 val;
+
+	val = readq(starlink_pmu->pmu_base + STARLINK_PMU_CONTROL);
+	val &= ~STARLINK_PMU_GLOBAL_ENABLE;
+	writeq(val, starlink_pmu->pmu_base + STARLINK_PMU_CONTROL);
+
+	val = readq(starlink_pmu->pmu_base + STARLINK_PMU_INTERRUPT_ENABLE);
+	if (hwc->config == STARLINK_CYCLES)
+		val &= ~STARLINK_PMU_CYCLE_OVERFLOW_MASK;
+	else
+		val &= ~(1 << idx);
+
+	writeq(val, starlink_pmu->pmu_base + STARLINK_PMU_INTERRUPT_ENABLE);
+}
+
+static void starlink_pmu_update(struct perf_event *event)
+{
+	struct starlink_pmu *starlink_pmu = to_starlink_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	int idx = hwc->idx;
+	u64 prev_raw_count, new_raw_count;
+	u64 oldval;
+	u64 delta;
+
+	do {
+		prev_raw_count = local64_read(&hwc->prev_count);
+		if (hwc->config == STARLINK_CYCLES)
+			new_raw_count = readq(starlink_pmu->pmu_base +
+					      STARLINK_PMU_CYCLE_COUNTER);
+		else
+			new_raw_count = readq(starlink_pmu->pmu_base +
+					      STARLINK_PMU_EVENT_COUNTER +
+					      idx * sizeof(u64));
+		oldval = local64_cmpxchg(&hwc->prev_count, prev_raw_count,
+					 new_raw_count);
+	} while (oldval != prev_raw_count);
+
+	delta = (new_raw_count - prev_raw_count) & STARLINK_PMU_COUNTER_MASK;
+	local64_add(delta, &event->count);
+}
+
+static void starlink_pmu_start(struct perf_event *event, int flags)
+{
+	struct starlink_pmu *starlink_pmu = to_starlink_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
+		return;
+
+	if (flags & PERF_EF_RELOAD)
+		WARN_ON_ONCE(!(event->hw.state & PERF_HES_UPTODATE));
+
+	hwc->state = 0;
+
+	starlink_pmu_set_event_period(event);
+	starlink_pmu_counter_start(event, starlink_pmu);
+
+	perf_event_update_userpage(event);
+}
+
+static void starlink_pmu_stop(struct perf_event *event, int flags)
+{
+	struct starlink_pmu *starlink_pmu = to_starlink_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	if (hwc->state & PERF_HES_STOPPED)
+		return;
+
+	starlink_pmu_counter_stop(event, starlink_pmu);
+	starlink_pmu_update(event);
+	hwc->state |= PERF_HES_STOPPED | PERF_HES_UPTODATE;
+}
+
+static int starlink_pmu_add(struct perf_event *event, int flags)
+{
+	struct starlink_pmu *starlink_pmu = to_starlink_pmu(event->pmu);
+	struct starlink_hw_events *hw_events =
+					this_cpu_ptr(starlink_pmu->hw_events);
+	struct hw_perf_event *hwc = &event->hw;
+	unsigned long *used_mask = hw_events->used_mask;
+	u32 n_events = STARLINK_PMU_NUM_COUNTERS;
+	int idx;
+
+	/*
+	 * Cycle counter has dedicated register to hold counter value.
+	 * Event other than cycle count has to be enabled through
+	 * event select register, and assigned with independent counter
+	 * as they appear.
+	 */
+
+	if (hwc->config == STARLINK_CYCLES) {
+		idx = STARLINK_PMU_IDX_CYCLE_COUNTER;
+	} else {
+		idx = find_first_zero_bit(used_mask, n_events);
+		/* All counter are in use */
+		if (idx < 0)
+			return idx;
+
+		set_bit(idx, used_mask);
+	}
+
+	hwc->idx = idx;
+	hw_events->events[idx] = event;
+	hwc->state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
+
+	if (flags & PERF_EF_START)
+		starlink_pmu_start(event, PERF_EF_RELOAD);
+
+	perf_event_update_userpage(event);
+
+	return 0;
+}
+
+static void starlink_pmu_del(struct perf_event *event, int flags)
+{
+	struct starlink_pmu *starlink_pmu = to_starlink_pmu(event->pmu);
+	struct starlink_hw_events *hw_events =
+					this_cpu_ptr(starlink_pmu->hw_events);
+	struct hw_perf_event *hwc = &event->hw;
+
+	starlink_pmu_stop(event, PERF_EF_UPDATE);
+	hw_events->events[hwc->idx] = NULL;
+	clear_bit(hwc->idx, hw_events->used_mask);
+
+	perf_event_update_userpage(event);
+}
+
+static bool starlink_pmu_validate_event_group(struct perf_event *event)
+{
+	struct perf_event *leader = event->group_leader;
+	struct perf_event *sibling;
+	int counter = 1;
+
+	/*
+	 * Ensure hardware events in the group are on the same PMU,
+	 * software events are acceptable.
+	 */
+	if (event->group_leader->pmu != event->pmu &&
+	    !is_software_event(event->group_leader))
+		return false;
+
+	for_each_sibling_event(sibling, leader) {
+		if (sibling->pmu != event->pmu && !is_software_event(sibling))
+			return false;
+
+		counter++;
+	}
+
+	return counter <= STARLINK_PMU_NUM_COUNTERS;
+}
+
+static int starlink_pmu_event_init(struct perf_event *event)
+{
+	struct starlink_pmu *starlink_pmu = to_starlink_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	/*
+	 * Sampling is not supported, as counters are shared
+	 * by all CPU.
+	 */
+	if (hwc->sample_period)
+		return -EOPNOTSUPP;
+
+	/*
+	 * Per-task and attach to a task are not supported,
+	 * as uncore events are not specific to any CPU.
+	 */
+	if (event->cpu < 0 || event->attach_state & PERF_ATTACH_TASK)
+		return -EOPNOTSUPP;
+
+	if (!starlink_pmu_validate_event_group(event))
+		return -EINVAL;
+
+	hwc->idx = -1;
+	hwc->config = event->attr.config;
+	event->cpu = cpumask_first(&starlink_pmu->cpumask);
+
+	return 0;
+}
+
+static irqreturn_t starlink_pmu_handle_irq(int irq_num, void *data)
+{
+	struct starlink_pmu *starlink_pmu = data;
+	struct starlink_hw_events *hw_events =
+			this_cpu_ptr(starlink_pmu->hw_events);
+	bool handled = false;
+	int idx;
+	u64 overflow_status;
+
+	for (idx = 0; idx < STARLINK_PMU_MAX_COUNTERS; idx++) {
+		struct perf_event *event = hw_events->events[idx];
+
+		if (!event)
+			continue;
+
+		overflow_status = readq(starlink_pmu->pmu_base +
+					STARLINK_PMU_COUNTER_OVERFLOW_STATUS);
+		if (!(overflow_status & BIT(idx)))
+			continue;
+
+		writeq(1 << idx, starlink_pmu->pmu_base +
+		       STARLINK_PMU_COUNTER_OVERFLOW_STATUS);
+
+		starlink_pmu_update(event);
+		starlink_pmu_set_event_period(event);
+		handled = true;
+	}
+	return IRQ_RETVAL(handled);
+}
+
+static int starlink_setup_irqs(struct starlink_pmu *starlink_pmu,
+			       struct platform_device *pdev)
+{
+	int ret, irq;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return -EINVAL;
+
+	ret = devm_request_irq(&pdev->dev, irq, starlink_pmu_handle_irq,
+			       0, STARLINK_PMU_PDEV_NAME, starlink_pmu);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret, "Failed to request IRQ\n");
+
+	starlink_pmu->irq = irq;
+
+	return 0;
+}
+
+static int starlink_pmu_pm_notify(struct notifier_block *b,
+				  unsigned long cmd, void *v)
+{
+	struct starlink_pmu *starlink_pmu = container_of(b, struct starlink_pmu,
+							 starlink_pmu_pm_nb);
+	struct starlink_hw_events *hw_events =
+					this_cpu_ptr(starlink_pmu->hw_events);
+	int enabled = bitmap_weight(hw_events->used_mask,
+				    STARLINK_PMU_MAX_COUNTERS);
+	struct perf_event *event;
+	int idx;
+
+	if (!enabled)
+		return NOTIFY_OK;
+
+	for (idx = 0; idx < STARLINK_PMU_MAX_COUNTERS; idx++) {
+		event = hw_events->events[idx];
+		if (!event)
+			continue;
+
+		switch (cmd) {
+		case CPU_PM_ENTER:
+			/* Stop and update the counter */
+			starlink_pmu_stop(event, PERF_EF_UPDATE);
+			break;
+		case CPU_PM_EXIT:
+		case CPU_PM_ENTER_FAILED:
+			/* Restore and enable the counter */
+			starlink_pmu_start(event, PERF_EF_RELOAD);
+			break;
+		default:
+			break;
+		}
+	}
+
+	return NOTIFY_OK;
+}
+
+static int starlink_pmu_pm_register(struct starlink_pmu *starlink_pmu)
+{
+	if (!IS_ENABLED(CONFIG_CPU_PM))
+		return 0;
+
+	starlink_pmu->starlink_pmu_pm_nb.notifier_call = starlink_pmu_pm_notify;
+	return cpu_pm_register_notifier(&starlink_pmu->starlink_pmu_pm_nb);
+}
+
+static void starlink_pmu_pm_unregister(struct starlink_pmu *starlink_pmu)
+{
+	if (!IS_ENABLED(CONFIG_CPU_PM))
+		return;
+
+	cpu_pm_unregister_notifier(&starlink_pmu->starlink_pmu_pm_nb);
+}
+
+static void starlink_pmu_destroy(struct starlink_pmu *starlink_pmu)
+{
+	starlink_pmu_pm_unregister(starlink_pmu);
+	cpuhp_state_remove_instance(starlink_pmu_cpuhp_state,
+				    &starlink_pmu->node);
+}
+
+static int starlink_pmu_probe(struct platform_device *pdev)
+{
+	struct starlink_pmu *starlink_pmu;
+	struct starlink_hw_events *hw_events;
+	struct resource *res;
+	int cpuid, i, ret;
+
+	starlink_pmu = devm_kzalloc(&pdev->dev, sizeof(*starlink_pmu), GFP_KERNEL);
+	if (!starlink_pmu)
+		return -ENOMEM;
+
+	starlink_pmu->pmu_base =
+			devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(starlink_pmu->pmu_base))
+		return PTR_ERR(starlink_pmu->pmu_base);
+
+	starlink_pmu->hw_events = alloc_percpu_gfp(struct starlink_hw_events,
+						   GFP_KERNEL);
+	if (!starlink_pmu->hw_events) {
+		dev_err(&pdev->dev, "Failed to allocate per-cpu PMU data\n");
+		kfree(starlink_pmu);
+		return -ENOMEM;
+	}
+
+	for_each_possible_cpu(cpuid) {
+		hw_events = per_cpu_ptr(starlink_pmu->hw_events, cpuid);
+		for (i = 0; i < STARLINK_PMU_MAX_COUNTERS; i++)
+			hw_events->events[i] = NULL;
+	}
+
+	ret = starlink_setup_irqs(starlink_pmu, pdev);
+	if (ret)
+		return ret;
+
+	ret = cpuhp_state_add_instance(starlink_pmu_cpuhp_state,
+				       &starlink_pmu->node);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to register hotplug\n");
+		return ret;
+	}
+
+	ret = starlink_pmu_pm_register(starlink_pmu);
+	if (ret) {
+		cpuhp_state_remove_instance(starlink_pmu_cpuhp_state,
+					    &starlink_pmu->node);
+		return ret;
+	}
+
+	starlink_pmu->pmu = (struct pmu) {
+		.task_ctx_nr	= perf_invalid_context,
+		.event_init	= starlink_pmu_event_init,
+		.add		= starlink_pmu_add,
+		.del		= starlink_pmu_del,
+		.start		= starlink_pmu_start,
+		.stop		= starlink_pmu_stop,
+		.read		= starlink_pmu_update,
+		.attr_groups	= starlink_pmu_attr_groups,
+	};
+
+	ret = perf_pmu_register(&starlink_pmu->pmu, STARLINK_PMU_PDEV_NAME, -1);
+	if (ret)
+		starlink_pmu_destroy(starlink_pmu);
+
+	return ret;
+}
+
+static const struct of_device_id starlink_pmu_of_match[] = {
+	{ .compatible = "starfive,jh8100-starlink-pmu" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, starlink_pmu_of_match);
+
+static struct platform_driver starlink_pmu_driver = {
+	.driver = {
+		.name	= STARLINK_PMU_PDEV_NAME,
+		.of_match_table = starlink_pmu_of_match,
+		.suppress_bind_attrs = true,
+	},
+	.probe = starlink_pmu_probe,
+};
+
+static int
+starlink_pmu_online_cpu(unsigned int cpu, struct hlist_node *node)
+{
+	struct starlink_pmu *starlink_pmu = hlist_entry_safe(node,
+							     struct starlink_pmu,
+							     node);
+
+	if (cpumask_empty(&starlink_pmu->cpumask))
+		cpumask_set_cpu(cpu, &starlink_pmu->cpumask);
+
+	WARN_ON(irq_set_affinity(starlink_pmu->irq, cpumask_of(cpu)));
+
+	return 0;
+}
+
+static int
+starlink_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
+{
+	struct starlink_pmu *starlink_pmu = hlist_entry_safe(node,
+							     struct starlink_pmu,
+							     node);
+	unsigned int target;
+
+	if (!cpumask_test_and_clear_cpu(cpu, &starlink_pmu->cpumask))
+		return 0;
+
+	target = cpumask_any_but(cpu_online_mask, cpu);
+	if (target >= nr_cpu_ids)
+		return 0;
+
+	perf_pmu_migrate_context(&starlink_pmu->pmu, cpu, target);
+
+	cpumask_set_cpu(target, &starlink_pmu->cpumask);
+	WARN_ON(irq_set_affinity(starlink_pmu->irq, cpumask_of(target)));
+
+	return 0;
+}
+
+static int __init starlink_pmu_init(void)
+{
+	int ret;
+
+	ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
+				      "soc/starfive/starlink_pmu:online",
+				      starlink_pmu_online_cpu,
+				      starlink_pmu_offline_cpu);
+	if (ret < 0)
+		return ret;
+
+	starlink_pmu_cpuhp_state = ret;
+
+	return platform_driver_register(&starlink_pmu_driver);
+}
+
+device_initcall(starlink_pmu_init);
-- 
2.25.1



From jisheng.teoh at starfivetech.com  Thu Dec  7 06:29:40 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Thu, 7 Dec 2023 22:29:40 +0800
Subject: [PATCH v5 3/3] docs: perf: Add description for StarFive's StarLink PMU
In-Reply-To: <20231207142940.1794032-1-jisheng.teoh@starfivetech.com>
References: <20231207142940.1794032-1-jisheng.teoh@starfivetech.com>
Message-ID: <20231207142940.1794032-4-jisheng.teoh@starfivetech.com>

StarFive StarLink PMU support monitoring L3 memory system PMU events.
Add documentation to describe StarFive StarLink PMU support and it's
usage.

Signed-off-by: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
---
 Documentation/admin-guide/perf/index.rst      |  1 +
 .../perf/starfive_starlink_pmu.rst            | 46 +++++++++++++++++++
 2 files changed, 47 insertions(+)
 create mode 100644 Documentation/admin-guide/perf/starfive_starlink_pmu.rst

diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst
index a2e6f2c81146..c5de7579a71b 100644
--- a/Documentation/admin-guide/perf/index.rst
+++ b/Documentation/admin-guide/perf/index.rst
@@ -13,6 +13,7 @@ Performance monitor support
    imx-ddr
    qcom_l2_pmu
    qcom_l3_pmu
+   starfive_starlink_pmu
    arm-ccn
    arm-cmn
    xgene-pmu
diff --git a/Documentation/admin-guide/perf/starfive_starlink_pmu.rst b/Documentation/admin-guide/perf/starfive_starlink_pmu.rst
new file mode 100644
index 000000000000..2932ddb4eb76
--- /dev/null
+++ b/Documentation/admin-guide/perf/starfive_starlink_pmu.rst
@@ -0,0 +1,46 @@
+================================================
+StarFive StarLink Performance Monitor Unit (PMU)
+================================================
+
+StarFive StarLink Performance Monitor Unit (PMU) exists within the
+StarLink Coherent Network on Chip (CNoC) that connects multiple CPU
+clusters with an L3 memory system.
+
+The uncore PMU supports overflow interrupt, up to 16 programmable 64bit
+event counters, and an independent 64bit cycle counter.
+The PMU can only be accessed via Memory Mapped I/O and are common to the
+cores connected to the same PMU.
+
+Driver exposes supported PMU events in sysfs "events" directory under::
+
+  /sys/bus/event_source/devices/starfive_starlink_pmu/events/
+
+Driver exposes cpu used to handle PMU events in sysfs "cpumask" directory
+under::
+
+  /sys/bus/event_source/devices/starfive_starlink_pmu/cpumask/
+
+Driver describes the format of config (event ID) in sysfs "format" directory
+under::
+
+  /sys/bus/event_source/devices/starfive_starlink_pmu/format/
+
+Example of perf usage::
+
+	$ perf list
+
+	starfive_starlink_pmu/cycles/                      [Kernel PMU event]
+	starfive_starlink_pmu/read_hit/                    [Kernel PMU event]
+	starfive_starlink_pmu/read_miss/                   [Kernel PMU event]
+	starfive_starlink_pmu/read_request/                [Kernel PMU event]
+	starfive_starlink_pmu/release_request/             [Kernel PMU event]
+	starfive_starlink_pmu/write_hit/                   [Kernel PMU event]
+	starfive_starlink_pmu/write_miss/                  [Kernel PMU event]
+	starfive_starlink_pmu/write_request/               [Kernel PMU event]
+	starfive_starlink_pmu/writeback/                   [Kernel PMU event]
+
+
+	$ perf stat -a -e /starfive_starlink_pmu/cycles/ sleep 1
+
+Sampling is not supported. As a result, "perf record" is not supported.
+Attaching to a task is not supported, only system-wide counting is supported.
-- 
2.25.1



From fancer.lancer at gmail.com  Thu Dec  7 06:37:03 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Thu, 7 Dec 2023 17:37:03 +0300
Subject: [PATCH net-next 11/16] net: pcs: xpcs: Change
 xpcs_create_mdiodev() suffix to "byaddr"
In-Reply-To: <202312060634.Cblfigt2-lkp@intel.com>
References: <20231205103559.9605-12-fancer.lancer@gmail.com>
 <202312060634.Cblfigt2-lkp@intel.com>
Message-ID: <jiblfzhnqjztssy76dojx6g7vyqgpjymnt4hz6yg6xv2psn3fo@pro373rkjbbq>

On Wed, Dec 06, 2023 at 07:03:46AM +0800, kernel test robot wrote:
> Hi Serge,
> 
> kernel test robot noticed the following build errors:
> 
> [auto build test ERROR on net-next/main]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Serge-Semin/net-pcs-xpcs-Drop-sentinel-entry-from-2500basex-ifaces-list/20231205-183808
> base:   net-next/main
> patch link:    https://lore.kernel.org/r/20231205103559.9605-12-fancer.lancer%40gmail.com
> patch subject: [PATCH net-next 11/16] net: pcs: xpcs: Change xpcs_create_mdiodev() suffix to "byaddr"
> config: arc-randconfig-001-20231206 (https://download.01.org/0day-ci/archive/20231206/202312060634.Cblfigt2-lkp at intel.com/config)
> compiler: arc-elf-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231206/202312060634.Cblfigt2-lkp at intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp at intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202312060634.Cblfigt2-lkp at intel.com/
> 
> All error/warnings (new ones prefixed by >>):
> 
>    drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c: In function 'txgbe_mdio_pcs_init':
> >> drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c:150:16: error: implicit declaration of function 'xpcs_create_mdiodev'; did you mean 'xpcs_create_byaddr'? [-Werror=implicit-function-declaration]
>      150 |         xpcs = xpcs_create_mdiodev(mii_bus, 0, PHY_INTERFACE_MODE_10GBASER);
>          |                ^~~~~~~~~~~~~~~~~~~
>          |                xpcs_create_byaddr
> >> drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c:150:14: warning: assignment to 'struct dw_xpcs *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
>      150 |         xpcs = xpcs_create_mdiodev(mii_bus, 0, PHY_INTERFACE_MODE_10GBASER);
>          |              ^
>    cc1: some warnings being treated as errors
> 
> 
> vim +150 drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c

Ah, right. I had been creating the series some times earlier than this
code was introduced and just missed it on the last rebase. I'll fix
this on v2.

-Serge(y)

> 
> 854cace61387b6 Jiawen Wu      2023-06-06  121  
> 854cace61387b6 Jiawen Wu      2023-06-06  122  static int txgbe_mdio_pcs_init(struct txgbe *txgbe)
> 854cace61387b6 Jiawen Wu      2023-06-06  123  {
> 854cace61387b6 Jiawen Wu      2023-06-06  124  	struct mii_bus *mii_bus;
> 854cace61387b6 Jiawen Wu      2023-06-06  125  	struct dw_xpcs *xpcs;
> 854cace61387b6 Jiawen Wu      2023-06-06  126  	struct pci_dev *pdev;
> 854cace61387b6 Jiawen Wu      2023-06-06  127  	struct wx *wx;
> 854cace61387b6 Jiawen Wu      2023-06-06  128  	int ret = 0;
> 854cace61387b6 Jiawen Wu      2023-06-06  129  
> 854cace61387b6 Jiawen Wu      2023-06-06  130  	wx = txgbe->wx;
> 854cace61387b6 Jiawen Wu      2023-06-06  131  	pdev = wx->pdev;
> 854cace61387b6 Jiawen Wu      2023-06-06  132  
> 854cace61387b6 Jiawen Wu      2023-06-06  133  	mii_bus = devm_mdiobus_alloc(&pdev->dev);
> 854cace61387b6 Jiawen Wu      2023-06-06  134  	if (!mii_bus)
> 854cace61387b6 Jiawen Wu      2023-06-06  135  		return -ENOMEM;
> 854cace61387b6 Jiawen Wu      2023-06-06  136  
> 854cace61387b6 Jiawen Wu      2023-06-06  137  	mii_bus->name = "txgbe_pcs_mdio_bus";
> 854cace61387b6 Jiawen Wu      2023-06-06  138  	mii_bus->read_c45 = &txgbe_pcs_read;
> 854cace61387b6 Jiawen Wu      2023-06-06  139  	mii_bus->write_c45 = &txgbe_pcs_write;
> 854cace61387b6 Jiawen Wu      2023-06-06  140  	mii_bus->parent = &pdev->dev;
> 854cace61387b6 Jiawen Wu      2023-06-06  141  	mii_bus->phy_mask = ~0;
> 854cace61387b6 Jiawen Wu      2023-06-06  142  	mii_bus->priv = wx;
> 854cace61387b6 Jiawen Wu      2023-06-06  143  	snprintf(mii_bus->id, MII_BUS_ID_SIZE, "txgbe_pcs-%x",
> d8c21ef7b2b147 Xiongfeng Wang 2023-08-08  144  		 pci_dev_id(pdev));
> 854cace61387b6 Jiawen Wu      2023-06-06  145  
> 854cace61387b6 Jiawen Wu      2023-06-06  146  	ret = devm_mdiobus_register(&pdev->dev, mii_bus);
> 854cace61387b6 Jiawen Wu      2023-06-06  147  	if (ret)
> 854cace61387b6 Jiawen Wu      2023-06-06  148  		return ret;
> 854cace61387b6 Jiawen Wu      2023-06-06  149  
> 854cace61387b6 Jiawen Wu      2023-06-06 @150  	xpcs = xpcs_create_mdiodev(mii_bus, 0, PHY_INTERFACE_MODE_10GBASER);
> 854cace61387b6 Jiawen Wu      2023-06-06  151  	if (IS_ERR(xpcs))
> 854cace61387b6 Jiawen Wu      2023-06-06  152  		return PTR_ERR(xpcs);
> 854cace61387b6 Jiawen Wu      2023-06-06  153  
> 854cace61387b6 Jiawen Wu      2023-06-06  154  	txgbe->xpcs = xpcs;
> 854cace61387b6 Jiawen Wu      2023-06-06  155  
> 854cace61387b6 Jiawen Wu      2023-06-06  156  	return 0;
> 854cace61387b6 Jiawen Wu      2023-06-06  157  }
> 854cace61387b6 Jiawen Wu      2023-06-06  158  
> 
> -- 
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki


From laurent.pinchart at ideasonboard.com  Thu Dec  7 06:38:14 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 16:38:14 +0200
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231207142723.GA3187877@google.com>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com>
 <20231207142723.GA3187877@google.com>
Message-ID: <20231207143814.GD15521@pendragon.ideasonboard.com>

On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > Hi Simon,
> > 
> > Thank you for the patch.
> > 
> > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > containing the built kernel and associated devicetree files.
> > > Compression defaults to gzip which gives a good balance of size and
> > > performance.
> > > 
> > > The files compress from about 86MB to 24MB using this approach.
> > > 
> > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > and Linuxboot. It permits automatic selection of the correct
> > > devicetree, matching the compatible string of the running board with
> > > the closest compatible string in the FIT. There is no need for
> > > filenames or other workarounds.
> > > 
> > > Add a 'make image.fit' build target for arm64, as well. Use
> > > FIT_COMPRESSION to select a different algorithm.
> > > 
> > > The FIT can be examined using 'dumpimage -l'.
> > > 
> > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > requires compression utilities for the algorithm being used. Supported
> > > compression options are the same as the Image.xxx files. For now there
> > > is no way to change the compression other than by editing the rule for
> > > $(obj)/image.fit
> > > 
> > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > this here, since it must be built separately from the Linux build.
> > 
> > FIT images are very useful, so I think this is a very welcome addition
> > to the kernel build system. It can get tricky though: given the
> > versatile nature of FIT images, there can't be any
> > one-size-fits-them-all solution to build them, and striking the right
> > balance between what makes sense for the kernel and the features that
> > users may request will probably lead to bikeshedding. As we all love
> > bikeshedding, I thought I would start selfishly, with a personal use
> > case :-) This isn't a yak-shaving request though, I don't see any reason
> > to delay merging this series.
> > 
> > Have you envisioned building FIT images with a subset of DTBs, or adding
> > DTBOs ? Both would be fairly trivial extensions to this script by
> > extending the supported command line arguments. It would perhaps be more
> > difficult to integrate in the kernel build system though. This leads me
> > to a second question: would you consider merging extensions to this
> > script if they are not used by the kernel build system, but meant for
> > users who manually invoke the script ? More generally, is the script
> 
> We'd also be interested in some customization, though in a different way.
> We imagine having a rule file that says X compatible string should map
> to A base DTB, plus B and C DTBO for the configuration section. The base
> DTB would carry all common elements of some device, while the DTBOs
> carry all the possible second source components, like different display
> panels or MIPI cameras for instance. This could drastically reduce the
> size of FIT images in ChromeOS by deduplicating all the common stuff.

Do you envision the "mapping" compatible string mapping to a config
section in the FIT image, that would bundle the base DTB and the DTBOs ?

> > meant to be used stand-alone as well, in which case its command line
> > arguments need to remain backward-compatible, or do you see it as being
> > internal to the kernel ?
> 
> [...]
> 
> ChenYu

-- 
Regards,

Laurent Pinchart


From laurent.pinchart at ideasonboard.com  Thu Dec  7 06:42:10 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 16:42:10 +0200
Subject: [PATCH v3 3/4] media: rkisp1: Store IRQ lines
In-Reply-To: <20231207-rkisp-irq-fix-v3-3-358a2c871a3c@ideasonboard.com>
References: <20231207-rkisp-irq-fix-v3-0-358a2c871a3c@ideasonboard.com>
 <20231207-rkisp-irq-fix-v3-3-358a2c871a3c@ideasonboard.com>
Message-ID: <20231207144210.GE15521@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Thu, Dec 07, 2023 at 09:57:47AM +0200, Tomi Valkeinen wrote:
> Store the IRQ lines used by the driver for easy access. These are needed
> in future patches which fix IRQ race issues.
> 
> Tested-by: Adam Ford <aford173 at gmail.com>  #imx8mp-beacon
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
>  drivers/media/platform/rockchip/rkisp1/rkisp1-common.h | 11 ++++++++++-
>  drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c    | 17 +++++++++++++----
>  2 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> index 1e7cea1bea5e..2d7f06281c39 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> @@ -61,6 +61,14 @@ struct dentry;
>  						 RKISP1_CIF_ISP_EXP_END |	\
>  						 RKISP1_CIF_ISP_HIST_MEASURE_RDY)
>  
> +/* IRQ lines */
> +enum rkisp1_irq_line {
> +	RKISP1_IRQ_ISP = 0,
> +	RKISP1_IRQ_MI,
> +	RKISP1_IRQ_MIPI,
> +	RKISP1_NUM_IRQS,
> +};
> +
>  /* enum for the resizer pads */
>  enum rkisp1_rsz_pad {
>  	RKISP1_RSZ_PAD_SINK,
> @@ -423,7 +431,6 @@ struct rkisp1_debug {
>   * struct rkisp1_device - ISP platform device
>   *
>   * @base_addr:	   base register address
> - * @irq:	   the irq number
>   * @dev:	   a pointer to the struct device
>   * @clk_size:	   number of clocks
>   * @clks:	   array of clocks
> @@ -441,6 +448,7 @@ struct rkisp1_debug {
>   * @stream_lock:   serializes {start/stop}_streaming callbacks between the capture devices.
>   * @debug:	   debug params to be exposed on debugfs
>   * @info:	   version-specific ISP information
> + * @irqs:          IRQ line numbers
>   */
>  struct rkisp1_device {
>  	void __iomem *base_addr;
> @@ -461,6 +469,7 @@ struct rkisp1_device {
>  	struct mutex stream_lock; /* serialize {start/stop}_streaming cb between capture devices */
>  	struct rkisp1_debug debug;
>  	const struct rkisp1_info *info;
> +	int irqs[RKISP1_NUM_IRQS];
>  };
>  
>  /*
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 22b2ae0e89c4..c3fa40976140 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -114,6 +114,7 @@
>  struct rkisp1_isr_data {
>  	const char *name;
>  	irqreturn_t (*isr)(int irq, void *ctx);
> +	u32 line_mask;
>  };
>  
>  /* ----------------------------------------------------------------------------
> @@ -471,9 +472,9 @@ static const char * const px30_isp_clks[] = {
>  };
>  
>  static const struct rkisp1_isr_data px30_isp_isrs[] = {
> -	{ "isp", rkisp1_isp_isr },
> -	{ "mi", rkisp1_capture_isr },
> -	{ "mipi", rkisp1_csi_isr },
> +	{ "isp", rkisp1_isp_isr, BIT(RKISP1_IRQ_ISP) },
> +	{ "mi", rkisp1_capture_isr, BIT(RKISP1_IRQ_MI) },
> +	{ "mipi", rkisp1_csi_isr, BIT(RKISP1_IRQ_MIPI) },
>  };
>  
>  static const struct rkisp1_info px30_isp_info = {
> @@ -492,7 +493,7 @@ static const char * const rk3399_isp_clks[] = {
>  };
>  
>  static const struct rkisp1_isr_data rk3399_isp_isrs[] = {
> -	{ NULL, rkisp1_isr },
> +	{ NULL, rkisp1_isr, BIT(RKISP1_IRQ_ISP) | BIT(RKISP1_IRQ_MI) | BIT(RKISP1_IRQ_MIPI) },
>  };
>  
>  static const struct rkisp1_info rk3399_isp_info = {
> @@ -543,6 +544,9 @@ static int rkisp1_probe(struct platform_device *pdev)
>  	if (IS_ERR(rkisp1->base_addr))
>  		return PTR_ERR(rkisp1->base_addr);
>  
> +	for (unsigned int il = 0; il < ARRAY_SIZE(rkisp1->irqs); ++il)
> +		rkisp1->irqs[il] = -1;
> +
>  	for (i = 0; i < info->isr_size; i++) {
>  		irq = info->isrs[i].name
>  		    ? platform_get_irq_byname(pdev, info->isrs[i].name)
> @@ -550,6 +554,11 @@ static int rkisp1_probe(struct platform_device *pdev)
>  		if (irq < 0)
>  			return irq;
>  
> +		for (unsigned int il = 0; il < ARRAY_SIZE(rkisp1->irqs); ++il) {
> +			if (info->isrs[i].line_mask & BIT(il))
> +				rkisp1->irqs[il] = irq;
> +		}
> +
>  		ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0,
>  				       dev_driver_string(dev), dev);
>  		if (ret) {
> 

-- 
Regards,

Laurent Pinchart


From kan.liang at linux.intel.com  Thu Dec  7 06:42:01 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Thu, 7 Dec 2023 09:42:01 -0500
Subject: [PATCH 2/6] perf mem: Clean up perf_mem_events__ptr()
In-Reply-To: <CAP-5=fUhaOgMZuhhsmjkTL6QqEQzcjq9GjJyteLG5RTWuBQ0gg@mail.gmail.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
 <20231206201324.184059-3-kan.liang@linux.intel.com>
 <CAP-5=fUhaOgMZuhhsmjkTL6QqEQzcjq9GjJyteLG5RTWuBQ0gg@mail.gmail.com>
Message-ID: <b4e6f20c-9845-4114-8f48-ef1f46869a09@linux.intel.com>



On 2023-12-06 4:04 p.m., Ian Rogers wrote:
>>                  * The load and store operations are required, use the event
>>                  * PERF_MEM_EVENTS__LOAD_STORE if it is supported.
>> @@ -3289,15 +3303,15 @@ static int perf_c2c__record(int argc, const char **argv)
>>                         e->record = true;
>>                         rec_argv[i++] = "-W";
>>                 } else {
>> -                       e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
>> +                       e = perf_mem_events__ptr(pmu, PERF_MEM_EVENTS__LOAD);
> Fwiw, it seems strange in cases like this that the function isn't:
> perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD)

Not just this one. The PMU is also added into other functions.
I will change the name for all of them in V2.

diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index 8c5694b2d0b0..0ad301a2e424 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -36,14 +36,15 @@ enum {
 extern unsigned int perf_mem_events__loads_ldlat;
 extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];

-int perf_mem_events__parse(const char *str);
-int perf_mem_events__init(void);
+int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str);
+int perf_pmu__mem_events_init(struct perf_pmu *pmu);

 const char *perf_mem_events__name(int i, const char *pmu_name);
-struct perf_mem_event *perf_mem_events__ptr(int i);
+struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu,
int i);
+struct perf_pmu *perf_mem_events_find_pmu(void);
 bool is_mem_loads_aux_event(struct evsel *leader);

-void perf_mem_events__list(void);
+void perf_pmu__mem_events_list(struct perf_pmu *pmu);
 int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
                                 char **rec_tmp, int *tmp_nr);

Thanks,
Kan



From kabel at kernel.org  Thu Dec  7 06:43:36 2023
From: kabel at kernel.org (Marek =?UTF-8?B?QmVow7pu?=)
Date: Thu, 7 Dec 2023 15:43:36 +0100
Subject: [PATCH v2 3/3] arm64: dts: armada-3720-turris-mox: set irq type
 for RTC
In-Reply-To: <20231128213536.3764212-4-sjoerd@collabora.com>
References: <20231128213536.3764212-1-sjoerd@collabora.com>
	<20231128213536.3764212-4-sjoerd@collabora.com>
Message-ID: <20231207154336.5bf6272e@dellmb>

On Tue, 28 Nov 2023 22:35:06 +0100
Sjoerd Simons <sjoerd at collabora.com> wrote:

> The rtc on the mox shares its interrupt line with the moxtet bus. Set
> the interrupt type to be consistent between both devices. This ensures
> correct setup of the interrupt line regardless of probing order.
> 
> Signed-off-by: Sjoerd Simons <sjoerd at collabora.com>
> Cc: stable at vger.kernel.org # v6.2+
> Fixes: 21aad8ba615e ("arm64: dts: armada-3720-turris-mox: Add missing interrupt for RTC")
> 
> ---
> 
> (no changes since v1)
> 
>  arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> index 9eab2bb22134..805ef2d79b40 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
> @@ -130,7 +130,7 @@ rtc at 6f {
>  		compatible = "microchip,mcp7940x";
>  		reg = <0x6f>;
>  		interrupt-parent = <&gpiosb>;
> -		interrupts = <5 0>; /* GPIO2_5 */
> +		interrupts = <5 IRQ_TYPE_EDGE_FALLING>; /* GPIO2_5 */
>  	};
>  };
>  

Reviewed-by: Marek Beh?n <kabel at kernel.org>


From ravi.bangoria at amd.com  Thu Dec  7 06:44:14 2023
From: ravi.bangoria at amd.com (Ravi Bangoria)
Date: Thu, 7 Dec 2023 20:14:14 +0530
Subject: [PATCH 0/6] Clean up perf mem
In-Reply-To: <20231206201324.184059-1-kan.liang@linux.intel.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
Message-ID: <0597b44c-226d-1180-d55d-bcf9bbd2e03f@amd.com>

> The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
> etc. But I can only test it on two Intel platforms.
> Please give it try, if you have machines with other ARCHs.

I did a quick perf mem and perf c2c test, with the fix I suggested
in patch #1, and things seems to be working fine.

[For AMD specific changes]
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>


From ryan.roberts at arm.com  Thu Dec  7 06:45:38 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 7 Dec 2023 14:45:38 +0000
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <94806b4f-2370-4999-9586-2c936955cb87@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
 <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
 <ca649aad-7b76-4c6d-b513-26b3d58f8e68@redhat.com>
 <126c3b71-1acc-4851-9986-4228cb8a8660@arm.com>
 <94806b4f-2370-4999-9586-2c936955cb87@redhat.com>
Message-ID: <3d49bcbf-1f9b-48e8-a91a-ede0762b795c@arm.com>

On 07/12/2023 13:28, David Hildenbrand wrote:
>>>
>>> Right, but you know from the first loop which order is applicable (and will be
>>> fed to the second loop) and could just pte_unmap(pte) + tryalloc. If that fails,
>>> remap and try with the next orders.
>>
>> You mean something like this?
>>
>> ????pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>> ????if (!pte)
>> ??????? return ERR_PTR(-EAGAIN);
>>
>> ????order = highest_order(orders);
>> ????while (orders) {
>> ??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>> ??????? if (!pte_range_none(pte + pte_index(addr), 1 << order)) {
>> ??????????? order = next_order(&orders, order);
>> ??????????? continue;
>> ??????? }
>>
>> ??????? pte_unmap(pte);
>> ???????
>> ??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>> ??????? if (folio) {
>> ??????????? clear_huge_page(&folio->page, vmf->address, 1 << order);
>> ??????????? return folio;
>> ??????? }
>>
>> ??????? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>> ??????? if (!pte)
>> ??????????? return ERR_PTR(-EAGAIN);
>>
>> ??????? order = next_order(&orders, order);
>> ????}
>>
>> ????pte_unmap(pte);
>>
>> I don't really like that because if high order folio allocations fail, then you
>> are calling pte_range_none() again for the next lower order; once that check has
>> succeeded for an order it shouldn't be required for any lower orders. In this
>> case you also have lots of pte map/unmap.
> 
> I see what you mean.
> 
>>
>> The original version feels more efficient to me.
> Yes it is. Adding in some comments might help, like
> 
> /*
> ?* Find the largest order where the aligned range is completely prot_none(). Note
> ?* that all remaining orders will be completely prot_none().
> ?*/
> ...
> 
> /* Try allocating the largest of the remaining orders. */

OK added.

> 
>>
>>>
>>> That would make the code certainly easier to understand. That "orders" magic of
>>> constructing, filtering, walking is confusing :)
>>>
>>>
>>> I might find some time today to see if there is an easy way to cleanup all what
>>> I spelled out above. It really is a mess. But likely that cleanup could be
>>> deferred (but you're touching it, so ... :) ).
>>
>> I'm going to ignore the last 5 words. I heard the "that cleanup could be
>> deferred" part loud and clear though :)
> 
> :)
> 
> If we could stop passing orders into thp_vma_allowable_orders(), that would
> probably
> be the biggest win. It's just all a confusing mess.



I tried an approach like you suggested in the other thread originally, but I
struggled to define exactly what "thp_vma_configured_orders()" should mean;
Ideally, I just want "all the THP orders that are currently enabled for this
VMA+flags". But some callers want to enforce_sysfs and others don't, so you
probably have to at least pass that flag. Then you have DAX which explicitly
ignores enforce_sysfs, but only in a page fault. And shmem, which ignores
enforce_sysfs, but only outside of a page fault. So it quickly becomes pretty
complex. It is basically thp_vma_allowable_orders() as currently defined.

If this could be a simple function then it could be inline and as you say, we
can do the masking in the caller and exit early for the order-0 case. But it is
very complex (at least if you want to retain the equivalent logic to what
thp_vma_allowable_orders() has) so I'm not sure how to do the order-0 early exit
without passing in the orders bitfield. And we are unlikely to exit early
because PMD-sized THP is likely enabled and because we didn't pass in a orders
bitfield, that wasn't filtered out.

In short, I can't see a solution that's better than the one I have. But if you
have something in mind, if you can spell it out, then I'll have a go at tidying
it up and integrating it into the series. Otherwise I really would prefer to
leave it for a separate series.


From hugo at hugovil.com  Thu Dec  7 06:46:25 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Thu, 7 Dec 2023 09:46:25 -0500
Subject: [PATCH 2/3] dt-bindings: arm: fsl: add Dimonoff gateway EVK
 board
In-Reply-To: <6035c4cc-afe1-456d-a4d0-16992da09a2e@linaro.org>
References: <20231206160303.33185-1-hugo@hugovil.com>
	<20231206160303.33185-3-hugo@hugovil.com>
	<6035c4cc-afe1-456d-a4d0-16992da09a2e@linaro.org>
Message-ID: <20231207094625.01d081092dd60ddc504d7f7b@hugovil.com>

On Thu, 7 Dec 2023 09:32:38 +0100
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

> On 06/12/2023 17:03, Hugo Villeneuve wrote:
> > From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> > 
> > Add DT compatible string for Dimonoff gateway EVK board based on a
> > Variscite VAR-SOM-NANO with a NXP MX8MN nano CPU.
> > 
> > Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> > ---
> >  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index cd87d1afe7b7..e445d65d6f17 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -1025,6 +1025,7 @@ properties:
> >        - description: Variscite VAR-SOM-MX8MN based boards
> >          items:
> >            - enum:
> > +              - dimonoff,dimonoff-gateway-evk # i.MX8MN Dimonoff Gateway EVK Board
> 
> Company name appears twice, which is not really helpful. What's the true
> name? Gateway EVK? Then keep only this.
> 
> Best regards,
> Krzysztof

Ok, will do for V2.

Thank you,
Hugo Villeneuve


From fancer.lancer at gmail.com  Thu Dec  7 06:47:11 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Thu, 7 Dec 2023 17:47:11 +0300
Subject: [PATCH net-next 13/16] net: stmmac: intel: Register generic MDIO
 device
In-Reply-To: <202312060845.lDDRDWET-lkp@intel.com>
References: <20231205103559.9605-14-fancer.lancer@gmail.com>
 <202312060845.lDDRDWET-lkp@intel.com>
Message-ID: <ohhgcfdvbxo3sffjpf7nedti3gujcwti4cysgim47jgcsum5ay@rrtsfnwktbqb>

On Wed, Dec 06, 2023 at 08:19:07AM +0800, kernel test robot wrote:
> Hi Serge,
> 
> kernel test robot noticed the following build errors:
> 
> [auto build test ERROR on net-next/main]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Serge-Semin/net-pcs-xpcs-Drop-sentinel-entry-from-2500basex-ifaces-list/20231205-183808
> base:   net-next/main
> patch link:    https://lore.kernel.org/r/20231205103559.9605-14-fancer.lancer%40gmail.com
> patch subject: [PATCH net-next 13/16] net: stmmac: intel: Register generic MDIO device
> config: x86_64-kexec (https://download.01.org/0day-ci/archive/20231206/202312060845.lDDRDWET-lkp at intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231206/202312060845.lDDRDWET-lkp at intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp at intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202312060845.lDDRDWET-lkp at intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>    drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c: In function 'intel_mgbe_common_data':
> >> drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:646:31: error: 'clk' undeclared (first use in this function)
>      646 |         clk_disable_unprepare(clk);
>          |                               ^~~
>    drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:646:31: note: each undeclared identifier is reported only once for each function it appears in
> 
> 
> vim +/clk +646 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c

Right, my series had been originally based on a branch which had some
of this driver parts fixed. I should have more thoroughly performed
the re-base process. I'll make sure it's fixed on v2.

-Serge(y)

> 
>    446	
>    447	static int intel_mgbe_common_data(struct pci_dev *pdev,
>    448					  struct plat_stmmacenet_data *plat)
>    449	{
>    450		struct fwnode_handle *fwnode;
>    451		char clk_name[20];
>    452		int ret;
>    453		int i;
>    454	
>    455		plat->pdev = pdev;
>    456		plat->phy_addr = -1;
>    457		plat->clk_csr = 5;
>    458		plat->has_gmac = 0;
>    459		plat->has_gmac4 = 1;
>    460		plat->force_sf_dma_mode = 0;
>    461		plat->flags |= (STMMAC_FLAG_TSO_EN | STMMAC_FLAG_SPH_DISABLE);
>    462	
>    463		/* Multiplying factor to the clk_eee_i clock time
>    464		 * period to make it closer to 100 ns. This value
>    465		 * should be programmed such that the clk_eee_time_period *
>    466		 * (MULT_FACT_100NS + 1) should be within 80 ns to 120 ns
>    467		 * clk_eee frequency is 19.2Mhz
>    468		 * clk_eee_time_period is 52ns
>    469		 * 52ns * (1 + 1) = 104ns
>    470		 * MULT_FACT_100NS = 1
>    471		 */
>    472		plat->mult_fact_100ns = 1;
>    473	
>    474		plat->rx_sched_algorithm = MTL_RX_ALGORITHM_SP;
>    475	
>    476		for (i = 0; i < plat->rx_queues_to_use; i++) {
>    477			plat->rx_queues_cfg[i].mode_to_use = MTL_QUEUE_DCB;
>    478			plat->rx_queues_cfg[i].chan = i;
>    479	
>    480			/* Disable Priority config by default */
>    481			plat->rx_queues_cfg[i].use_prio = false;
>    482	
>    483			/* Disable RX queues routing by default */
>    484			plat->rx_queues_cfg[i].pkt_route = 0x0;
>    485		}
>    486	
>    487		for (i = 0; i < plat->tx_queues_to_use; i++) {
>    488			plat->tx_queues_cfg[i].mode_to_use = MTL_QUEUE_DCB;
>    489	
>    490			/* Disable Priority config by default */
>    491			plat->tx_queues_cfg[i].use_prio = false;
>    492			/* Default TX Q0 to use TSO and rest TXQ for TBS */
>    493			if (i > 0)
>    494				plat->tx_queues_cfg[i].tbs_en = 1;
>    495		}
>    496	
>    497		/* FIFO size is 4096 bytes for 1 tx/rx queue */
>    498		plat->tx_fifo_size = plat->tx_queues_to_use * 4096;
>    499		plat->rx_fifo_size = plat->rx_queues_to_use * 4096;
>    500	
>    501		plat->tx_sched_algorithm = MTL_TX_ALGORITHM_WRR;
>    502		plat->tx_queues_cfg[0].weight = 0x09;
>    503		plat->tx_queues_cfg[1].weight = 0x0A;
>    504		plat->tx_queues_cfg[2].weight = 0x0B;
>    505		plat->tx_queues_cfg[3].weight = 0x0C;
>    506		plat->tx_queues_cfg[4].weight = 0x0D;
>    507		plat->tx_queues_cfg[5].weight = 0x0E;
>    508		plat->tx_queues_cfg[6].weight = 0x0F;
>    509		plat->tx_queues_cfg[7].weight = 0x10;
>    510	
>    511		plat->dma_cfg->pbl = 32;
>    512		plat->dma_cfg->pblx8 = true;
>    513		plat->dma_cfg->fixed_burst = 0;
>    514		plat->dma_cfg->mixed_burst = 0;
>    515		plat->dma_cfg->aal = 0;
>    516		plat->dma_cfg->dche = true;
>    517	
>    518		plat->axi = devm_kzalloc(&pdev->dev, sizeof(*plat->axi),
>    519					 GFP_KERNEL);
>    520		if (!plat->axi)
>    521			return -ENOMEM;
>    522	
>    523		plat->axi->axi_lpi_en = 0;
>    524		plat->axi->axi_xit_frm = 0;
>    525		plat->axi->axi_wr_osr_lmt = 1;
>    526		plat->axi->axi_rd_osr_lmt = 1;
>    527		plat->axi->axi_blen[0] = 4;
>    528		plat->axi->axi_blen[1] = 8;
>    529		plat->axi->axi_blen[2] = 16;
>    530	
>    531		plat->ptp_max_adj = plat->clk_ptp_rate;
>    532		plat->eee_usecs_rate = plat->clk_ptp_rate;
>    533	
>    534		/* Set system clock */
>    535		sprintf(clk_name, "%s-%s", "stmmac", pci_name(pdev));
>    536	
>    537		plat->stmmac_clk = clk_register_fixed_rate(&pdev->dev,
>    538							   clk_name, NULL, 0,
>    539							   plat->clk_ptp_rate);
>    540	
>    541		if (IS_ERR(plat->stmmac_clk)) {
>    542			dev_warn(&pdev->dev, "Fail to register stmmac-clk\n");
>    543			plat->stmmac_clk = NULL;
>    544		}
>    545	
>    546		ret = clk_prepare_enable(plat->stmmac_clk);
>    547		if (ret) {
>    548			clk_unregister_fixed_rate(plat->stmmac_clk);
>    549			return ret;
>    550		}
>    551	
>    552		plat->ptp_clk_freq_config = intel_mgbe_ptp_clk_freq_config;
>    553	
>    554		/* Set default value for multicast hash bins */
>    555		plat->multicast_filter_bins = HASH_TABLE_SIZE;
>    556	
>    557		/* Set default value for unicast filter entries */
>    558		plat->unicast_filter_entries = 1;
>    559	
>    560		/* Set the maxmtu to a default of JUMBO_LEN */
>    561		plat->maxmtu = JUMBO_LEN;
>    562	
>    563		plat->flags |= STMMAC_FLAG_VLAN_FAIL_Q_EN;
>    564	
>    565		/* Use the last Rx queue */
>    566		plat->vlan_fail_q = plat->rx_queues_to_use - 1;
>    567	
>    568		/* For fixed-link setup, we allow phy-mode setting */
>    569		fwnode = dev_fwnode(&pdev->dev);
>    570		if (fwnode) {
>    571			int phy_mode;
>    572	
>    573			/* "phy-mode" setting is optional. If it is set,
>    574			 *  we allow either sgmii or 1000base-x for now.
>    575			 */
>    576			phy_mode = fwnode_get_phy_mode(fwnode);
>    577			if (phy_mode >= 0) {
>    578				if (phy_mode == PHY_INTERFACE_MODE_SGMII ||
>    579				    phy_mode == PHY_INTERFACE_MODE_1000BASEX)
>    580					plat->phy_interface = phy_mode;
>    581				else
>    582					dev_warn(&pdev->dev, "Invalid phy-mode\n");
>    583			}
>    584		}
>    585	
>    586		/* Intel mgbe SGMII interface uses pcs-xcps */
>    587		if (plat->phy_interface == PHY_INTERFACE_MODE_SGMII ||
>    588		    plat->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
>    589			struct mdio_board_info *xpcs_info;
>    590	
>    591			xpcs_info = devm_kzalloc(&pdev->dev,
>    592						 sizeof(*xpcs_info) + MII_BUS_ID_SIZE,
>    593						 GFP_KERNEL);
>    594			if (!xpcs_info) {
>    595				ret = -ENOMEM;
>    596				goto err_alloc_info;
>    597			}
>    598	
>    599			xpcs_info->bus_id = (void *)xpcs_info + sizeof(*xpcs_info);
>    600			snprintf((char *)xpcs_info->bus_id, MII_BUS_ID_SIZE,
>    601				 "stmmac-%x", plat->bus_id);
>    602	
>    603			snprintf(xpcs_info->modalias, MDIO_NAME_SIZE, "dwxpcs");
>    604	
>    605			xpcs_info->mdio_addr = INTEL_MGBE_XPCS_ADDR;
>    606	
>    607			ret = mdiobus_register_board_info(xpcs_info, 1);
>    608			if (ret)
>    609				goto err_alloc_info;
>    610	
>    611			plat->mdio_bus_data->has_xpcs = true;
>    612			plat->mdio_bus_data->xpcs_an_inband = true;
>    613		}
>    614	
>    615		/* For fixed-link setup, we clear xpcs_an_inband */
>    616		if (fwnode) {
>    617			struct fwnode_handle *fixed_node;
>    618	
>    619			fixed_node = fwnode_get_named_child_node(fwnode, "fixed-link");
>    620			if (fixed_node)
>    621				plat->mdio_bus_data->xpcs_an_inband = false;
>    622	
>    623			fwnode_handle_put(fixed_node);
>    624		}
>    625	
>    626		/* Ensure mdio bus PHY-scan skips intel serdes and pcs-xpcs */
>    627		plat->mdio_bus_data->phy_mask = 1 << INTEL_MGBE_ADHOC_ADDR;
>    628		plat->mdio_bus_data->phy_mask |= 1 << INTEL_MGBE_XPCS_ADDR;
>    629	
>    630		plat->int_snapshot_num = AUX_SNAPSHOT1;
>    631	
>    632		plat->crosststamp = intel_crosststamp;
>    633		plat->flags &= ~STMMAC_FLAG_INT_SNAPSHOT_EN;
>    634	
>    635		/* Setup MSI vector offset specific to Intel mGbE controller */
>    636		plat->msi_mac_vec = 29;
>    637		plat->msi_lpi_vec = 28;
>    638		plat->msi_sfty_ce_vec = 27;
>    639		plat->msi_sfty_ue_vec = 26;
>    640		plat->msi_rx_base_vec = 0;
>    641		plat->msi_tx_base_vec = 1;
>    642	
>    643		return 0;
>    644	
>    645	err_alloc_info:
>  > 646		clk_disable_unprepare(clk);
>    647		clk_unregister_fixed_rate(clk);
>    648	
>    649		return ret;
>    650	}
>    651	
> 
> -- 
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki


From laurent.pinchart at ideasonboard.com  Thu Dec  7 06:50:20 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 16:50:20 +0200
Subject: [PATCH v2 4/4] media: rkisp1: debug: Consolidate counter debugfs
 files
In-Reply-To: <212f4a89-7135-41ca-9638-b36a474b1bfa@ideasonboard.com>
References: <20231201140433.2126011-1-paul.elder@ideasonboard.com>
 <20231201140433.2126011-5-paul.elder@ideasonboard.com>
 <212f4a89-7135-41ca-9638-b36a474b1bfa@ideasonboard.com>
Message-ID: <20231207145020.GA17373@pendragon.ideasonboard.com>

On Tue, Dec 05, 2023 at 10:22:47AM +0200, Tomi Valkeinen wrote:
> On 01/12/2023 16:04, Paul Elder wrote:
> > Consolidate all the debugfs files that were each a single counter into a
> > single "counters" file.
> > 
> > While at it, reset the counters at stream on time to make it easier for
> > to interpret the values in userspace.
> > 
> > Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
> > 
> > ---
> > New in v2
> > 
> >   .../platform/rockchip/rkisp1/rkisp1-capture.c |  2 +
> >   .../platform/rockchip/rkisp1/rkisp1-common.h  |  4 ++
> >   .../platform/rockchip/rkisp1/rkisp1-debug.c   | 69 ++++++++++++-------
> >   3 files changed, 50 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > index c6d7e01c8949..67b2e94dfd67 100644
> > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > @@ -1030,6 +1030,8 @@ rkisp1_vb2_start_streaming(struct vb2_queue *queue, unsigned int count)
> >   	struct media_entity *entity = &cap->vnode.vdev.entity;
> >   	int ret;
> >   
> > +	rkisp1_debug_reset_counters(cap->rkisp1);
> > +
> >   	mutex_lock(&cap->rkisp1->stream_lock);
> >   
> >   	ret = video_device_pipeline_start(&cap->vnode.vdev, &cap->rkisp1->pipe);
> > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> > index be69173958a4..789259fb304a 100644
> > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> > @@ -599,9 +599,13 @@ int rkisp1_params_register(struct rkisp1_device *rkisp1);
> >   void rkisp1_params_unregister(struct rkisp1_device *rkisp1);
> >   
> >   #if IS_ENABLED(CONFIG_DEBUG_FS)
> > +void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1);
> >   void rkisp1_debug_init(struct rkisp1_device *rkisp1);
> >   void rkisp1_debug_cleanup(struct rkisp1_device *rkisp1);
> >   #else
> > +static inline void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1)
> > +{
> > +}
> >   static inline void rkisp1_debug_init(struct rkisp1_device *rkisp1)
> >   {
> >   }
> > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
> > index 79cda589d935..4358ed1367ed 100644
> > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
> > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-debug.c
> > @@ -25,6 +25,11 @@ struct rkisp1_debug_register {
> >   	const char * const name;
> >   };
> >   
> > +struct rkisp1_debug_counter {
> > +	const char * const name;
> > +	unsigned long *value;
> > +};
> > +
> >   #define RKISP1_DEBUG_REG(name)		{ RKISP1_CIF_##name, 0, #name }
> >   #define RKISP1_DEBUG_SHD_REG(name) { \
> >   	RKISP1_CIF_##name, RKISP1_CIF_##name##_SHD, #name \
> > @@ -191,6 +196,43 @@ static int rkisp1_debug_input_status_show(struct seq_file *m, void *p)
> >   }
> >   DEFINE_SHOW_ATTRIBUTE(rkisp1_debug_input_status);
> >   
> > +static int rkisp1_debug_counters_show(struct seq_file *m, void *p)
> > +{
> > +	struct rkisp1_device *rkisp1 = m->private;
> > +	struct rkisp1_debug *debug = &rkisp1->debug;
> > +
> > +	const struct rkisp1_debug_counter counters[] = {
> > +		{ "data_loss", &debug->data_loss },
> > +		{ "outform_size_err", &debug->outform_size_error },
> > +		{ "img_stabilization_size_error", &debug->img_stabilization_size_error },
> > +		{ "inform_size_error", &debug->inform_size_error },
> > +		{ "irq_delay", &debug->irq_delay },
> > +		{ "mipi_error", &debug->mipi_error },
> > +		{ "stats_error", &debug->stats_error },
> > +		{ "mp_stop_timeout", &debug->stop_timeout[RKISP1_MAINPATH] },
> > +		{ "sp_stop_timeout", &debug->stop_timeout[RKISP1_SELFPATH] },
> > +		{ "mp_frame_drop", &debug->frame_drop[RKISP1_MAINPATH] },
> > +		{ "sp_frame_drop", &debug->frame_drop[RKISP1_SELFPATH] },
> > +		{ "complete_frames", &debug->complete_frames },
> > +		{ /* Sentinel */ },
> > +	};
> > +
> > +	const struct rkisp1_debug_counter *counter = counters;
> > +
> > +	for (; counter->name; ++counter)
> > +		seq_printf(m, "%s: %lu\n", counter->name, *counter->value);
> > +
> 
> You could also do:
> 
> 	const struct {
> 		const char *name;
> 		unsigned long value;
> 	} counters[] = {
> 		{ "data_loss", debug->data_loss },
> 		{ "outform_size_err", debug->outform_size_error },
> 		{ "img_stabilization_size_error", debug->img_stabilization_size_error },
> 		{ "inform_size_error", debug->inform_size_error },
> 		{ "irq_delay", debug->irq_delay },
> 		{ "mipi_error", debug->mipi_error },
> 		{ "stats_error", debug->stats_error },
> 		{ "mp_stop_timeout", debug->stop_timeout[RKISP1_MAINPATH] },
> 		{ "sp_stop_timeout", debug->stop_timeout[RKISP1_SELFPATH] },
> 		{ "mp_frame_drop", debug->frame_drop[RKISP1_MAINPATH] },
> 		{ "sp_frame_drop", debug->frame_drop[RKISP1_SELFPATH] },
> 		{ "complete_frames", debug->complete_frames },
> 	};
> 
> 	for (unsigned int i = 0; i < ARRAY_SIZE(counters); ++i)
> 		seq_printf(m, "%s: %lu\n", counters[i].name, counters[i].value);
> 
> Not a big difference, but this doesn't "leak" the struct used only inside the
> function, doesn't need the sentinel, and I don't see a reason to store pointers
> to values, instead of just storing the values.

Wouldn't it be nicer to avoid constructing this on the stack for every
call ? We could store the counters in an array:

enum rkisp1_debug_counter {
	RKISP1_DBG_COUNT_DATA_LOSS,
	...
	RKISP1_DBG_COUNT_FRAME_DROP_MP,
	RKISP1_DBG_COUNT_FRAME_DROP_SP,
	RKISP1_DBG_COUNT_MAX,
};

struct rksisp1_debug {
	struct dentry *debugfs_dir;
	unsigned long counters[RKISP1_DBG_COUNT_MAX];
};

The counters[] array above would become a

static const char * const counter_names[] = {
	[RKISP1_DBG_COUNT_DATA_LOSS] = "data_loss",
	...
};

> > +	return 0;
> > +}
> > +DEFINE_SHOW_ATTRIBUTE(rkisp1_debug_counters);
> > +
> > +void rkisp1_debug_reset_counters(struct rkisp1_device *rkisp1)
> > +{
> > +	struct dentry *debugfs_dir = rkisp1->debug.debugfs_dir;
> > +	memset(&rkisp1->debug, 0, sizeof(rkisp1->debug));
> > +	rkisp1->debug.debugfs_dir = debugfs_dir;
> > +}
> > +
> >   void rkisp1_debug_init(struct rkisp1_device *rkisp1)
> >   {
> >   	struct rkisp1_debug *debug = &rkisp1->debug;
> > @@ -198,31 +240,8 @@ void rkisp1_debug_init(struct rkisp1_device *rkisp1)
> >   
> >   	debug->debugfs_dir = debugfs_create_dir(dev_name(rkisp1->dev), NULL);
> >   
> > -	debugfs_create_ulong("data_loss", 0444, debug->debugfs_dir,
> > -			     &debug->data_loss);
> > -	debugfs_create_ulong("outform_size_err", 0444,  debug->debugfs_dir,
> > -			     &debug->outform_size_error);
> > -	debugfs_create_ulong("img_stabilization_size_error", 0444,
> > -			     debug->debugfs_dir,
> > -			     &debug->img_stabilization_size_error);
> > -	debugfs_create_ulong("inform_size_error", 0444,  debug->debugfs_dir,
> > -			     &debug->inform_size_error);
> > -	debugfs_create_ulong("irq_delay", 0444,  debug->debugfs_dir,
> > -			     &debug->irq_delay);
> > -	debugfs_create_ulong("mipi_error", 0444, debug->debugfs_dir,
> > -			     &debug->mipi_error);
> > -	debugfs_create_ulong("stats_error", 0444, debug->debugfs_dir,
> > -			     &debug->stats_error);
> > -	debugfs_create_ulong("mp_stop_timeout", 0444, debug->debugfs_dir,
> > -			     &debug->stop_timeout[RKISP1_MAINPATH]);
> > -	debugfs_create_ulong("sp_stop_timeout", 0444, debug->debugfs_dir,
> > -			     &debug->stop_timeout[RKISP1_SELFPATH]);
> > -	debugfs_create_ulong("mp_frame_drop", 0444, debug->debugfs_dir,
> > -			     &debug->frame_drop[RKISP1_MAINPATH]);
> > -	debugfs_create_ulong("sp_frame_drop", 0444, debug->debugfs_dir,
> > -			     &debug->frame_drop[RKISP1_SELFPATH]);
> > -	debugfs_create_ulong("complete_frames", 0444, debug->debugfs_dir,
> > -			     &debug->complete_frames);
> > +	debugfs_create_file("counters", 0444, debug->debugfs_dir, rkisp1,
> > +			    &rkisp1_debug_counters_fops);
> >   	debugfs_create_file("input_status", 0444, debug->debugfs_dir, rkisp1,
> >   			    &rkisp1_debug_input_status_fops);
> >   

-- 
Regards,

Laurent Pinchart


From lpieralisi at kernel.org  Thu Dec  7 06:50:09 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Thu, 7 Dec 2023 15:50:09 +0100
Subject: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
In-Reply-To: <20231207133825.GI2692119@nvidia.com>
References: <ZW949Tl3VmQfPk0L@arm.com>
 <20231205194822.GL2692119@nvidia.com>
 <ZXCJ3pVbKuHJ3LTz@arm.com>
 <20231206150556.GQ2692119@nvidia.com>
 <ZXCQrTbf6q0BIhSw@lpieralisi>
 <20231206153809.GS2692119@nvidia.com>
 <ZXCf_e-ACqrj6VrV@arm.com>
 <20231206164802.GT2692119@nvidia.com>
 <ZXGa4A6rfxLtkTB2@lpieralisi>
 <20231207133825.GI2692119@nvidia.com>
Message-ID: <ZXHbocMSiAtrFdyr@lpieralisi>

On Thu, Dec 07, 2023 at 09:38:25AM -0400, Jason Gunthorpe wrote:
> On Thu, Dec 07, 2023 at 11:13:52AM +0100, Lorenzo Pieralisi wrote:
> > > > What about the other way around - would we have a prefetchable BAR that
> > > > has portions which are unprefetchable?
> > > 
> > > I would say possibly.
> > > 
> > > Prefetch is a dead concept in PCIe, it was obsoleted in PCI-X about 20
> > > years ago. No PCIe system has ever done prefetch.
> > > 
> > > There is a strong incentive to mark BAR's as prefetchable because it
> > > allows 64 bit addressing in configurations with bridges.
> > 
> > If by strong incentive you mean the "Additional guidance on the
> > Prefetchable Bit in Memory Space BARs" in the PCI express specifications,
> > I think it has been removed from the spec and the criteria that had to be
> > met to implement it were basically impossible to fulfill on ARM systems,
> > it did not make any sense in the first place.
> 
> No, I mean many systems don't have room to accommodate large 32 bit
> BARs and the only real way to make stuff work is to have a 64 bit BAR
> by setting prefetchable.

That's what the implementation note I mentioned referred to ;)

> Given mis-marking a read-side-effect region as prefetchable has no
> actual consequence on PCI-E I would not be surprised to learn people
> have done this.

PCIe specs 6.1, 7.5.1.2.1 "Base Address Registers"

"A function is permitted to mark a range as prefetchable if there are
no side effects on reads..."

I don't think that an OS should use the prefetchable flag to infer
anything (even though we do at the moment -> sysfs mappings, I know that
the prefetchable concept is being scrapped from the PCI specs altogether
for a reason), I don't see though how we can say that's a SW bug at
present given what I quoted above.

I'd agree that it is best not to use that flag for new code we are adding
(because it will be deprecated soon).

Thanks,
Lorenzo


From alexander.stein at ew.tq-group.com  Thu Dec  7 06:54:01 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu,  7 Dec 2023 15:54:01 +0100
Subject: [PATCH 1/1] arm64: dts: imx8m*-tqma8m*: Add chassis-type
Message-ID: <20231207145401.2102898-1-alexander.stein@ew.tq-group.com>

Device tree specification 0.4 defines an optional, but recommended
'chassis-type' property. Add it to TQMa8M* based board files.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts   | 1 +
 arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl-mba8mx.dts   | 1 +
 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts | 1 +
 arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts     | 1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts
index 8c6dbcd4c83c..8aa268d4f571 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts
@@ -13,6 +13,7 @@
 / {
 	model = "TQ-Systems GmbH i.MX8MM TQMa8MxML on MBa8Mx";
 	compatible = "tq,imx8mm-tqma8mqml-mba8mx", "tq,imx8mm-tqma8mqml", "fsl,imx8mm";
+	chassis-type = "embedded";
 
 	aliases {
 		eeprom0 = &eeprom3;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl-mba8mx.dts b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl-mba8mx.dts
index 061b8eea89f8..7180f3342298 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl-mba8mx.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl-mba8mx.dts
@@ -11,6 +11,7 @@
 / {
 	model = "TQ-Systems GmbH i.MX8MN TQMa8MxNL on MBa8Mx";
 	compatible = "tq,imx8mn-tqma8mqnl-mba8mx", "tq,imx8mn-tqma8mqnl", "fsl,imx8mn";
+	chassis-type = "embedded";
 
 	aliases {
 		eeprom0 = &eeprom3;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
index 99fcf0ff639d..8234c92b55df 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
@@ -15,6 +15,7 @@
 / {
 	model = "TQ-Systems i.MX8MPlus TQMa8MPxL on MBa8MPxL";
 	compatible = "tq,imx8mp-tqma8mpql-mba8mpxl", "tq,imx8mp-tqma8mpql", "fsl,imx8mp";
+	chassis-type = "embedded";
 
 	chosen {
 		stdout-path = &uart4;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts b/arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts
index aa0dfdcec7a4..87fde6510734 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts
@@ -11,6 +11,7 @@
 / {
 	model = "TQ-Systems GmbH i.MX8MQ TQMa8MQ on MBa8Mx";
 	compatible = "tq,imx8mq-tqma8mq-mba8mx", "tq,imx8mq-tqma8mq", "fsl,imx8mq";
+	chassis-type = "embedded";
 
 	aliases {
 		eeprom0 = &eeprom3;
-- 
2.34.1



From hugo at hugovil.com  Thu Dec  7 06:55:48 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Thu, 7 Dec 2023 09:55:48 -0500
Subject: [PATCH 2/3] dt-bindings: arm: fsl: add Dimonoff gateway EVK
 board
In-Reply-To: <6035c4cc-afe1-456d-a4d0-16992da09a2e@linaro.org>
References: <20231206160303.33185-1-hugo@hugovil.com>
	<20231206160303.33185-3-hugo@hugovil.com>
	<6035c4cc-afe1-456d-a4d0-16992da09a2e@linaro.org>
Message-ID: <20231207095548.d7257f34496e78bf2e8890ad@hugovil.com>

On Thu, 7 Dec 2023 09:32:38 +0100
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

> On 06/12/2023 17:03, Hugo Villeneuve wrote:
> > From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> > 
> > Add DT compatible string for Dimonoff gateway EVK board based on a
> > Variscite VAR-SOM-NANO with a NXP MX8MN nano CPU.
> > 
> > Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> > ---
> >  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index cd87d1afe7b7..e445d65d6f17 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -1025,6 +1025,7 @@ properties:
> >        - description: Variscite VAR-SOM-MX8MN based boards
> >          items:
> >            - enum:
> > +              - dimonoff,dimonoff-gateway-evk # i.MX8MN Dimonoff Gateway EVK Board
> 
> Company name appears twice, which is not really helpful. What's the true
> name? Gateway EVK? Then keep only this.

Ok, will drop company name for V2.

Thank you,
Hugo


From joey.gouly at arm.com  Thu Dec  7 07:00:01 2023
From: joey.gouly at arm.com (Joey Gouly)
Date: Thu, 7 Dec 2023 15:00:01 +0000
Subject: [PATCH v2 06/12] KVM: arm64: Update and fix FGT register masks
In-Reply-To: <20231206100503.564090-7-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
 <20231206100503.564090-7-tabba@google.com>
Message-ID: <20231207150001.GA29745@e124191.cambridge.arm.com>

Hello Fuad,

On Wed, Dec 06, 2023 at 10:04:56AM +0000, Fuad Tabba wrote:
> New trap bits have been defined in the 2023-09 Arm Architecture
> System Registers xml specification [*]. Moreover, the existing
> definitions of some of the mask and the RES0 bits overlap, which
> could be wrong, confusing, or both.
> 
> Update the bits to represent the latest spec (as of this patch,
> 2023-09), and ensure that the existing bits are consistent.
> 
> Subsequent patches will use the generated RES0 fields instead of
> specifying them manually. This patch keeps the manual encoding of
> the bits to make it easier to review the series.
> 
> [*] https://developer.arm.com/downloads/-/exploration-tools
> 
> Fixes: 0fd76865006d ("KVM: arm64: Add nPIR{E0}_EL1 to HFG traps")
> Signed-off-by: Fuad Tabba <tabba at google.com>
> ---
>  arch/arm64/include/asm/kvm_arm.h | 39 ++++++++++++++++++++------------
>  1 file changed, 24 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 7de0a7062625..b0dc3249d5cd 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -344,30 +344,39 @@
>   * Once we get to a point where the two describe the same thing, we'll
>   * merge the definitions. One day.
>   */
> -#define __HFGRTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51))
> +#define __HFGRTR_EL2_RES0	BIT(51)
>  #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
> -#define __HFGRTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> +#define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
>  
> -#define __HFGWTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51) |	\
> -				 BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
> -				 GENMASK(26, 25) | BIT(21) | BIT(18) |	\
> +#define __HFGWTR_EL2_RES0	(BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
> +				 BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
>  				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
> -#define __HFGWTR_EL2_MASK	GENMASK(49, 0)
> -#define __HFGWTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> +#define __HFGWTR_EL2_MASK	(GENMASK(49, 47) | GENMASK(45, 43) | \
> +				 BIT(41) | GENMASK(39, 29) | BIT(27) | \
> +				 GENMASK(24, 22) | GENMASK(20, 19) | \
> +				 GENMASK(17, 16) | GENMASK(13, 11) | \
> +				 GENMASK(8, 3) | GENMASK(1, 0))
> +#define __HFGWTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))

By adding all these bits to *_nMASK, we're allowing a guest to access registers
which KVM doesn't (currently) deal with.  For example if I apply this patch
series, a guest can access S2POR_EL1, previously it would print something like:

	kvm [80]: Unsupported guest sys_reg access at: ffffc42969c1f270 [600000c5]                                                                      
	 { Op0( 3), Op1( 0), CRn(10), CRm( 2), Op2( 5), func_read }, 

After applying this patch series, the guest can read S2POR_EL1.

We don't expose S2POE to the guest through ID_AA64MMFR3_EL1, so a well behaved
guest shouldn't access it, but there's nothing stopping it.

My question is, is this intended? Or do we need to update the following code
(and comment!) to trap all the stuff we don't currently handle (along with
ACCDATA_EL1):

	static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
	{

		..

	        /* The default is not to trap anything but ACCDATA_EL1 */
        	r_val = __HFGRTR_EL2_nMASK & ~HFGxTR_EL2_nACCDATA_EL1;
	        r_val |= r_set;
        	r_val &= ~r_clr;


Thanks,
Joey

>  
> -#define __HFGITR_EL2_RES0	GENMASK(63, 57)
> -#define __HFGITR_EL2_MASK	GENMASK(54, 0)
> -#define __HFGITR_EL2_nMASK	GENMASK(56, 55)
> +#define __HFGITR_EL2_RES0	(BIT(63) | BIT(61))
> +#define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
> +#define __HFGITR_EL2_nMASK	GENMASK(59, 55)
>  
>  #define __HDFGRTR_EL2_RES0	(BIT(49) | BIT(42) | GENMASK(39, 38) |	\
>  				 GENMASK(21, 20) | BIT(8))
> -#define __HDFGRTR_EL2_MASK	~__HDFGRTR_EL2_nMASK
> +#define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
> +				 GENMASK(41, 40) | GENMASK(37, 22) | \
> +				 GENMASK(19, 9) | GENMASK(7, 0))
>  #define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
>  
>  #define __HDFGWTR_EL2_RES0	(BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
>  				 BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
>  				 BIT(22) | BIT(9) | BIT(6))
> -#define __HDFGWTR_EL2_MASK	~__HDFGWTR_EL2_nMASK
> +#define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
> +				 GENMASK(46, 44) | GENMASK(42, 41) | \
> +				 GENMASK(37, 35) | GENMASK(33, 31) | \
> +				 GENMASK(29, 23) | GENMASK(21, 10) | \
> +				 GENMASK(8, 7) | GENMASK(5, 0))
>  #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
>  
>  #define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
> @@ -375,9 +384,9 @@
>  #define __HAFGRTR_EL2_nMASK	0UL
>  
>  /* Similar definitions for HCRX_EL2 */
> -#define __HCRX_EL2_RES0		(GENMASK(63, 16) | GENMASK(13, 12))
> -#define __HCRX_EL2_MASK		(0)
> -#define __HCRX_EL2_nMASK	(GENMASK(15, 14) | GENMASK(4, 0))
> +#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
> +#define __HCRX_EL2_MASK		(BIT(6))
> +#define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
>  
>  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
>  #define HPFAR_MASK	(~UL(0xf))
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From david at redhat.com  Thu Dec  7 07:01:56 2023
From: david at redhat.com (David Hildenbrand)
Date: Thu, 7 Dec 2023 16:01:56 +0100
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <3d49bcbf-1f9b-48e8-a91a-ede0762b795c@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
 <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
 <ca649aad-7b76-4c6d-b513-26b3d58f8e68@redhat.com>
 <126c3b71-1acc-4851-9986-4228cb8a8660@arm.com>
 <94806b4f-2370-4999-9586-2c936955cb87@redhat.com>
 <3d49bcbf-1f9b-48e8-a91a-ede0762b795c@arm.com>
Message-ID: <369ec8d3-ef6a-4a4e-84e2-2c91b8293929@redhat.com>

On 07.12.23 15:45, Ryan Roberts wrote:
> On 07/12/2023 13:28, David Hildenbrand wrote:
>>>>
>>>> Right, but you know from the first loop which order is applicable (and will be
>>>> fed to the second loop) and could just pte_unmap(pte) + tryalloc. If that fails,
>>>> remap and try with the next orders.
>>>
>>> You mean something like this?
>>>
>>>  ????pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>>  ????if (!pte)
>>>  ??????? return ERR_PTR(-EAGAIN);
>>>
>>>  ????order = highest_order(orders);
>>>  ????while (orders) {
>>>  ??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>  ??????? if (!pte_range_none(pte + pte_index(addr), 1 << order)) {
>>>  ??????????? order = next_order(&orders, order);
>>>  ??????????? continue;
>>>  ??????? }
>>>
>>>  ??????? pte_unmap(pte);
>>>         
>>>  ??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>>  ??????? if (folio) {
>>>  ??????????? clear_huge_page(&folio->page, vmf->address, 1 << order);
>>>  ??????????? return folio;
>>>  ??????? }
>>>
>>>  ??????? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>>  ??????? if (!pte)
>>>  ??????????? return ERR_PTR(-EAGAIN);
>>>
>>>  ??????? order = next_order(&orders, order);
>>>  ????}
>>>
>>>  ????pte_unmap(pte);
>>>
>>> I don't really like that because if high order folio allocations fail, then you
>>> are calling pte_range_none() again for the next lower order; once that check has
>>> succeeded for an order it shouldn't be required for any lower orders. In this
>>> case you also have lots of pte map/unmap.
>>
>> I see what you mean.
>>
>>>
>>> The original version feels more efficient to me.
>> Yes it is. Adding in some comments might help, like
>>
>> /*
>>  ?* Find the largest order where the aligned range is completely prot_none(). Note
>>  ?* that all remaining orders will be completely prot_none().
>>  ?*/
>> ...
>>
>> /* Try allocating the largest of the remaining orders. */
> 
> OK added.
> 
>>
>>>
>>>>
>>>> That would make the code certainly easier to understand. That "orders" magic of
>>>> constructing, filtering, walking is confusing :)
>>>>
>>>>
>>>> I might find some time today to see if there is an easy way to cleanup all what
>>>> I spelled out above. It really is a mess. But likely that cleanup could be
>>>> deferred (but you're touching it, so ... :) ).
>>>
>>> I'm going to ignore the last 5 words. I heard the "that cleanup could be
>>> deferred" part loud and clear though :)
>>
>> :)
>>
>> If we could stop passing orders into thp_vma_allowable_orders(), that would
>> probably
>> be the biggest win. It's just all a confusing mess.
> 
> 
> 
> I tried an approach like you suggested in the other thread originally, but I
> struggled to define exactly what "thp_vma_configured_orders()" should mean;
> Ideally, I just want "all the THP orders that are currently enabled for this
> VMA+flags". But some callers want to enforce_sysfs and others don't, so you
> probably have to at least pass that flag. Then you have DAX which explicitly

Yes, the flags would still be passed. It's kind of the "context".

> ignores enforce_sysfs, but only in a page fault. And shmem, which ignores
> enforce_sysfs, but only outside of a page fault. So it quickly becomes pretty
> complex. It is basically thp_vma_allowable_orders() as currently defined.

Yeah, but moving the "can we actually fit a THP in there" check out of 
the picture.

> 
> If this could be a simple function then it could be inline and as you say, we
> can do the masking in the caller and exit early for the order-0 case. But it is
> very complex (at least if you want to retain the equivalent logic to what
> thp_vma_allowable_orders() has) so I'm not sure how to do the order-0 early exit
> without passing in the orders bitfield. And we are unlikely to exit early
> because PMD-sized THP is likely enabled and because we didn't pass in a orders
> bitfield, that wasn't filtered out.
> 
> In short, I can't see a solution that's better than the one I have. But if you
> have something in mind, if you can spell it out, then I'll have a go at tidying
> it up and integrating it into the series. Otherwise I really would prefer to
> leave it for a separate series.

I'm playing with some cleanups, but they can all be built on top if they 
materialize.

-- 
Cheers,

David / dhildenb



From alexghiti at rivosinc.com  Thu Dec  7 07:03:44 2023
From: alexghiti at rivosinc.com (Alexandre Ghiti)
Date: Thu,  7 Dec 2023 16:03:44 +0100
Subject: [PATCH RFC/RFT 0/4] Remove preventive sfence.vma
Message-ID: <20231207150348.82096-1-alexghiti@rivosinc.com>

In RISC-V, after a new mapping is established, a sfence.vma needs to be
emitted for different reasons:

- if the uarch caches invalid entries, we need to invalidate it otherwise
  we would trap on this invalid entry,
- if the uarch does not cache invalid entries, a reordered access could fail
  to see the new mapping and then trap (sfence.vma acts as a fence).

We can actually avoid emitting those (mostly) useless and costly sfence.vma
by handling the traps instead:

- for new kernel mappings: only vmalloc mappings need to be taken care of,
  other new mapping are rare and already emit the required sfence.vma if
  needed.
  That must be achieved very early in the exception path as explained in
  patch 1, and this also fixes our fragile way of dealing with vmalloc faults.

- for new user mappings: that can be handled in the page fault path as done
  in patch 3.

Patch 2 is certainly a TEMP patch which allows to detect at runtime if a
uarch caches invalid TLB entries.

Patch 4 is a TEMP patch which allows to expose through debugfs the different
sfence.vma that are emitted, which can be used for benchmarking.

On our uarch that does not cache invalid entries and a 6.5 kernel, the
gains are measurable:

* Kernel boot:                  6%
* ltp - mmapstress01:           8%
* lmbench - lat_pagefault:      20%
* lmbench - lat_mmap:           5%

On uarchs that cache invalid entries, the results are more mitigated and
need to be explored more thoroughly (if anyone is interested!): that can
be explained by the extra page faults, which depending on "how much" the
uarch caches invalid entries, could kill the benefits of removing the
preventive sfence.vma.

Ved Shanbhogue has prepared a new extension to be used by uarchs that do
not cache invalid entries, which will certainly be used instead of patch 2.

Thanks to Ved and Matt Evans for triggering the discussion that led to
this patchset!

That's an RFC, so please don't mind the checkpatch warnings and dirty
comments. It applies on 6.6.

Any feedback, test or relevant benchmark are welcome :)

Alexandre Ghiti (4):
  riscv: Stop emitting preventive sfence.vma for new vmalloc mappings
  riscv: Add a runtime detection of invalid TLB entries caching
  riscv: Stop emitting preventive sfence.vma for new userspace mappings
  TEMP: riscv: Add debugfs interface to retrieve #sfence.vma

 arch/arm64/include/asm/pgtable.h              |   2 +-
 arch/mips/include/asm/pgtable.h               |   6 +-
 arch/powerpc/include/asm/book3s/64/tlbflush.h |   8 +-
 arch/riscv/include/asm/cacheflush.h           |  19 ++-
 arch/riscv/include/asm/pgtable.h              |  45 ++++---
 arch/riscv/include/asm/thread_info.h          |   5 +
 arch/riscv/include/asm/tlbflush.h             |   4 +
 arch/riscv/kernel/asm-offsets.c               |   5 +
 arch/riscv/kernel/entry.S                     |  94 +++++++++++++
 arch/riscv/kernel/sbi.c                       |  12 ++
 arch/riscv/mm/init.c                          | 126 ++++++++++++++++++
 arch/riscv/mm/tlbflush.c                      |  17 +++
 include/linux/pgtable.h                       |   8 +-
 mm/memory.c                                   |  12 +-
 14 files changed, 331 insertions(+), 32 deletions(-)

-- 
2.39.2



From alexghiti at rivosinc.com  Thu Dec  7 07:03:45 2023
From: alexghiti at rivosinc.com (Alexandre Ghiti)
Date: Thu,  7 Dec 2023 16:03:45 +0100
Subject: [PATCH RFC/RFT 1/4] riscv: Stop emitting preventive sfence.vma for new vmalloc mappings
In-Reply-To: <20231207150348.82096-1-alexghiti@rivosinc.com>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
Message-ID: <20231207150348.82096-2-alexghiti@rivosinc.com>

In 6.5, we removed the vmalloc fault path because that can't work (see
[1] [2]). Then in order to make sure that new page table entries were
seen by the page table walker, we had to preventively emit a sfence.vma
on all harts [3] but this solution is very costly since it relies on IPI.

And even there, we could end up in a loop of vmalloc faults if a vmalloc
allocation is done in the IPI path (for example if it is traced, see
[4]), which could result in a kernel stack overflow.

Those preventive sfence.vma needed to be emitted because:

- if the uarch caches invalid entries, the new mapping may not be
  observed by the page table walker and an invalidation may be needed.
- if the uarch does not cache invalid entries, a reordered access
  could "miss" the new mapping and traps: in that case, we would actually
  only need to retry the access, no sfence.vma is required.

So this patch removes those preventive sfence.vma and actually handles
the possible (and unlikely) exceptions. And since the kernel stacks
mappings lie in the vmalloc area, this handling must be done very early
when the trap is taken, at the very beginning of handle_exception: this
also rules out the vmalloc allocations in the fault path.

Note that for now, we emit a sfence.vma even for uarchs that do not
cache invalid entries as we have no means to know that: that will be
fixed in the next patch.

Link: https://lore.kernel.org/linux-riscv/20230531093817.665799-1-bjorn at kernel.org/ [1]
Link: https://lore.kernel.org/linux-riscv/20230801090927.2018653-1-dylan at andestech.com [2]
Link: https://lore.kernel.org/linux-riscv/20230725132246.817726-1-alexghiti at rivosinc.com/ [3]
Link: https://lore.kernel.org/lkml/20200508144043.13893-1-joro at 8bytes.org/ [4]
Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
---
 arch/riscv/include/asm/cacheflush.h  | 19 +++++-
 arch/riscv/include/asm/thread_info.h |  5 ++
 arch/riscv/kernel/asm-offsets.c      |  5 ++
 arch/riscv/kernel/entry.S            | 94 ++++++++++++++++++++++++++++
 arch/riscv/mm/init.c                 |  2 +
 5 files changed, 124 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h
index 3cb53c4df27c..a916cbc69d47 100644
--- a/arch/riscv/include/asm/cacheflush.h
+++ b/arch/riscv/include/asm/cacheflush.h
@@ -37,7 +37,24 @@ static inline void flush_dcache_page(struct page *page)
 	flush_icache_mm(vma->vm_mm, 0)
 
 #ifdef CONFIG_64BIT
-#define flush_cache_vmap(start, end)	flush_tlb_kernel_range(start, end)
+extern u64 new_vmalloc[];
+extern char _end[];
+#define flush_cache_vmap flush_cache_vmap
+static inline void flush_cache_vmap(unsigned long start, unsigned long end)
+{
+	if ((start < VMALLOC_END && end > VMALLOC_START) ||
+	    (start < MODULES_END && end > MODULES_VADDR)) {
+		int i;
+
+		/*
+		 * We don't care if concurrently a cpu resets this value since
+		 * the only place this can happen is in handle_exception() where
+		 * an sfence.vma is emitted.
+		 */
+		for (i = 0; i < NR_CPUS / sizeof(u64) + 1; ++i)
+			new_vmalloc[i] = -1ULL;
+	}
+}
 #endif
 
 #ifndef CONFIG_SMP
diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h
index 1833beb00489..8fe12fa6c329 100644
--- a/arch/riscv/include/asm/thread_info.h
+++ b/arch/riscv/include/asm/thread_info.h
@@ -60,6 +60,11 @@ struct thread_info {
 	long			user_sp;	/* User stack pointer */
 	int			cpu;
 	unsigned long		syscall_work;	/* SYSCALL_WORK_ flags */
+	/*
+	 * Used in handle_exception() to save a0, a1 and a2 before knowing if we
+	 * can access the kernel stack.
+	 */
+	unsigned long		a0, a1, a2;
 };
 
 /*
diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
index d6a75aac1d27..340c1c84560d 100644
--- a/arch/riscv/kernel/asm-offsets.c
+++ b/arch/riscv/kernel/asm-offsets.c
@@ -34,10 +34,15 @@ void asm_offsets(void)
 	OFFSET(TASK_THREAD_S9, task_struct, thread.s[9]);
 	OFFSET(TASK_THREAD_S10, task_struct, thread.s[10]);
 	OFFSET(TASK_THREAD_S11, task_struct, thread.s[11]);
+
+	OFFSET(TASK_TI_CPU, task_struct, thread_info.cpu);
 	OFFSET(TASK_TI_FLAGS, task_struct, thread_info.flags);
 	OFFSET(TASK_TI_PREEMPT_COUNT, task_struct, thread_info.preempt_count);
 	OFFSET(TASK_TI_KERNEL_SP, task_struct, thread_info.kernel_sp);
 	OFFSET(TASK_TI_USER_SP, task_struct, thread_info.user_sp);
+	OFFSET(TASK_TI_A0, task_struct, thread_info.a0);
+	OFFSET(TASK_TI_A1, task_struct, thread_info.a1);
+	OFFSET(TASK_TI_A2, task_struct, thread_info.a2);
 
 	OFFSET(TASK_THREAD_F0,  task_struct, thread.fstate.f[0]);
 	OFFSET(TASK_THREAD_F1,  task_struct, thread.fstate.f[1]);
diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 143a2bb3e697..3a3c7b563816 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -14,6 +14,88 @@
 #include <asm/asm-offsets.h>
 #include <asm/errata_list.h>
 
+.macro new_vmalloc_check
+	REG_S 	a0, TASK_TI_A0(tp)
+	REG_S 	a1, TASK_TI_A1(tp)
+	REG_S	a2, TASK_TI_A2(tp)
+
+	csrr 	a0, CSR_CAUSE
+	/* Exclude IRQs */
+	blt  	a0, zero, _new_vmalloc_restore_context
+	/* Only check new_vmalloc if we are in page/protection fault */
+	li   	a1, EXC_LOAD_PAGE_FAULT
+	beq  	a0, a1, _new_vmalloc_kernel_address
+	li   	a1, EXC_STORE_PAGE_FAULT
+	beq  	a0, a1, _new_vmalloc_kernel_address
+	li   	a1, EXC_INST_PAGE_FAULT
+	bne  	a0, a1, _new_vmalloc_restore_context
+
+_new_vmalloc_kernel_address:
+	/* Is it a kernel address? */
+	csrr 	a0, CSR_TVAL
+	bge 	a0, zero, _new_vmalloc_restore_context
+
+	/* Check if a new vmalloc mapping appeared that could explain the trap */
+
+	/*
+	 * Computes:
+	 * a0 = &new_vmalloc[BIT_WORD(cpu)]
+	 * a1 = BIT_MASK(cpu)
+	 */
+	REG_L 	a2, TASK_TI_CPU(tp)
+	/*
+	 * Compute the new_vmalloc element position:
+	 * (cpu / 64) * 8 = (cpu >> 6) << 3
+	 */
+	srli	a1, a2, 6
+	slli	a1, a1, 3
+	la	a0, new_vmalloc
+	add	a0, a0, a1
+	/*
+	 * Compute the bit position in the new_vmalloc element:
+	 * bit_pos = cpu % 64 = cpu - (cpu / 64) * 64 = cpu - (cpu >> 6) << 6
+	 * 	   = cpu - ((cpu >> 6) << 3) << 3
+	 */
+	slli	a1, a1, 3
+	sub	a1, a2, a1
+	/* Compute the "get mask": 1 << bit_pos */
+	li	a2, 1
+	sll	a1, a2, a1
+
+	/* Check the value of new_vmalloc for this cpu */
+	ld	a2, 0(a0)
+	and	a2, a2, a1
+	beq	a2, zero, _new_vmalloc_restore_context
+
+	ld	a2, 0(a0)
+	not	a1, a1
+	and	a1, a2, a1
+	sd	a1, 0(a0)
+
+	/* Only emit a sfence.vma if the uarch caches invalid entries */
+	la	a0, tlb_caching_invalid_entries
+	lb	a0, 0(a0)
+	beqz	a0, _new_vmalloc_no_caching_invalid_entries
+	sfence.vma
+_new_vmalloc_no_caching_invalid_entries:
+	// debug
+	la	a0, nr_sfence_vma_handle_exception
+	li	a1, 1
+	amoadd.w    a0, a1, (a0)
+	// end debug
+	REG_L	a0, TASK_TI_A0(tp)
+	REG_L	a1, TASK_TI_A1(tp)
+	REG_L	a2, TASK_TI_A2(tp)
+	csrw	CSR_SCRATCH, x0
+	sret
+
+_new_vmalloc_restore_context:
+	REG_L	a0, TASK_TI_A0(tp)
+	REG_L 	a1, TASK_TI_A1(tp)
+	REG_L 	a2, TASK_TI_A2(tp)
+.endm
+
+
 SYM_CODE_START(handle_exception)
 	/*
 	 * If coming from userspace, preserve the user thread pointer and load
@@ -25,6 +107,18 @@ SYM_CODE_START(handle_exception)
 
 _restore_kernel_tpsp:
 	csrr tp, CSR_SCRATCH
+
+	/*
+	 * The RISC-V kernel does not eagerly emit a sfence.vma after each
+	 * new vmalloc mapping, which may result in exceptions:
+	 * - if the uarch caches invalid entries, the new mapping would not be
+	 *   observed by the page table walker and an invalidation is needed.
+	 * - if the uarch does not cache invalid entries, a reordered access
+	 *   could "miss" the new mapping and traps: in that case, we only need
+	 *   to retry the access, no sfence.vma is required.
+	 */
+	new_vmalloc_check
+
 	REG_S sp, TASK_TI_KERNEL_SP(tp)
 
 #ifdef CONFIG_VMAP_STACK
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 0798bd861dcb..379403de6c6f 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -36,6 +36,8 @@
 
 #include "../kernel/head.h"
 
+u64 new_vmalloc[NR_CPUS / sizeof(u64) + 1];
+
 struct kernel_mapping kernel_map __ro_after_init;
 EXPORT_SYMBOL(kernel_map);
 #ifdef CONFIG_XIP_KERNEL
-- 
2.39.2



From hugo at hugovil.com  Thu Dec  7 07:05:17 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Thu,  7 Dec 2023 10:05:17 -0500
Subject: [PATCH v2 1/3] dt-bindings: vendor-prefixes: add dimonoff
In-Reply-To: <20231207150519.1264808-1-hugo@hugovil.com>
References: <20231207150519.1264808-1-hugo@hugovil.com>
Message-ID: <20231207150519.1264808-2-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Add vendor prefix for Dimonoff, which provides
IoT smart solutions and custom engineering services.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 71dcd6240a99..338ad15a7ab2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -352,6 +352,8 @@ patternProperties:
     description: Digi International Inc.
   "^digilent,.*":
     description: Diglent, Inc.
+  "^dimonoff,.*":
+    description: Dimonoff inc.
   "^diodes,.*":
     description: Diodes, Inc.
   "^dioo,.*":
-- 
2.39.2



From hugo at hugovil.com  Thu Dec  7 07:05:16 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Thu,  7 Dec 2023 10:05:16 -0500
Subject: [PATCH v2 0/3] board: imx8mn-dimonoff-gateway-evk: add support for Dimonoff gateway EVK board
Message-ID: <20231207150519.1264808-1-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Hello,
this patch series add support for the Dimonoff gateway EVK board.

Based on shawnguo/for-next branch.

Thank you.

Link: [v1] https://lore.kernel.org/all/20231206160303.33185-1-hugo at hugovil.com/

Changes for V2:
- Add Krzysztof Acked-by tag
- Wrap lines at 80 columns in dts
- Remove company name from compatible property

Hugo Villeneuve (3):
  dt-bindings: vendor-prefixes: add dimonoff
  dt-bindings: arm: fsl: add Dimonoff gateway EVK board
  arm64: dts: freescale: introduce dimonoff-gateway-evk board

 .../devicetree/bindings/arm/fsl.yaml          |   1 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../freescale/imx8mn-dimonoff-gateway-evk.dts | 160 ++++++++++++++++++
 4 files changed, 164 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts


base-commit: 8c3c7094bf5b965a6dfc74864838fa4954dcf1c9
-- 
2.39.2



From hugo at hugovil.com  Thu Dec  7 07:05:18 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Thu,  7 Dec 2023 10:05:18 -0500
Subject: [PATCH v2 2/3] dt-bindings: arm: fsl: add Dimonoff gateway EVK board
In-Reply-To: <20231207150519.1264808-1-hugo@hugovil.com>
References: <20231207150519.1264808-1-hugo@hugovil.com>
Message-ID: <20231207150519.1264808-3-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

Add DT compatible string for Dimonoff gateway EVK board based on a
Variscite VAR-SOM-NANO with a NXP MX8MN nano CPU.

Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index cd87d1afe7b7..9fc2d73ed8d6 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1025,6 +1025,7 @@ properties:
       - description: Variscite VAR-SOM-MX8MN based boards
         items:
           - enum:
+              - dimonoff,gateway-evk # i.MX8MN Dimonoff Gateway EVK Board
               - rve,rve-gateway # i.MX8MN RVE Gateway Board
               - variscite,var-som-mx8mn-symphony
           - const: variscite,var-som-mx8mn
-- 
2.39.2



From hugo at hugovil.com  Thu Dec  7 07:05:19 2023
From: hugo at hugovil.com (Hugo Villeneuve)
Date: Thu,  7 Dec 2023 10:05:19 -0500
Subject: [PATCH v2 3/3] arm64: dts: freescale: introduce dimonoff-gateway-evk board
In-Reply-To: <20231207150519.1264808-1-hugo@hugovil.com>
References: <20231207150519.1264808-1-hugo@hugovil.com>
Message-ID: <20231207150519.1264808-4-hugo@hugovil.com>

From: Hugo Villeneuve <hvilleneuve at dimonoff.com>

The Dimonoff gateway EVK board is based on a Variscite
VAR-SOM-NANO, with a NXP MX8MN nano CPU and also based on a Symphony
mx8mn EVK.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
---
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../freescale/imx8mn-dimonoff-gateway-evk.dts | 160 ++++++++++++++++++
 2 files changed, 161 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index d22e4f4f886d..1f29215ea9bb 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -97,6 +97,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-bsh-smm-s2.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-bsh-smm-s2pro.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mn-dimonoff-gateway-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr3l-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts
new file mode 100644
index 000000000000..6f9b82958b96
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 DimOnOff
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx8mn-var-som-symphony.dts"
+
+/ {
+	model = "DimOnOff Gateway EVK board";
+	compatible = "dimonoff,gateway-evk", "variscite,var-som-mx8mn",
+		     "fsl,imx8mn";
+
+	/*
+	 * U30 FPF2193 regulator.
+	 * Source = BASE_PER_3V3 = SOM_3V3 (COM pin 49).
+	 */
+	reg_disp_3v3: regulator-disp-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "Display 3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpio_keys>;
+
+		key-enter {
+			label = "enter";
+			gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_ENTER>;
+			wakeup-source;
+		};
+	};
+
+	/* Bourns PEC12R rotary encoder, 24 steps. */
+	rotary: rotary-encoder {
+		compatible = "rotary-encoder";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_rotary>;
+		gpios = <&gpio5 12 GPIO_ACTIVE_LOW>, /* A */
+			<&gpio5 13 GPIO_ACTIVE_LOW>; /* B */
+		linux,axis = <0>; /* REL_X */
+		rotary-encoder,encoding = "gray";
+		rotary-encoder,relative-axis;
+	};
+};
+
+/* Disable Asynchronous Sample Rate Converter (audio) */
+&easrc {
+	status = "disabled";
+};
+
+&ecspi1 {
+	/* Resistive touch controller */
+	/delete-node/ touchscreen at 0;
+};
+
+&gpu {
+	status = "disabled";
+};
+
+&i2c2 {
+	adc at 48 {
+		compatible = "ti,ads7924";
+		reg = <0x48>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_adc>;
+		vref-supply = <&reg_disp_3v3>;
+		reset-gpios = <&gpio5 5 GPIO_ACTIVE_LOW>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		channel at 0 {
+			reg = <0>;
+			label = "Pot0";
+		};
+		channel at 1 {
+			reg = <1>;
+			label = "Pot1";
+		};
+		channel at 2 {
+			reg = <2>;
+			label = "Pot2";
+		};
+		channel at 3 {
+			reg = <3>;
+			label = "Pot3";
+		};
+	};
+
+	rtc at 51 {
+		compatible = "nxp,pcf2129";
+		reg = <0x51>;
+		reset-source; /* For watchdog. */
+	};
+
+	rtc at 53 {
+		compatible = "nxp,pcf2131";
+		reg = <0x53>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_rtc>;
+		reset-source; /* For watchdog. */
+		interrupt-parent = <&gpio5>;
+		interrupts = <10 IRQ_TYPE_EDGE_FALLING>; /* J17.6 on EVK */
+	};
+};
+
+&i2c3 {
+	touchscreen at 38 {
+		status = "disabled";
+	};
+
+	codec at 1a {
+		status = "disabled";
+	};
+
+	/* DS1337 RTC module */
+	rtc at 68 {
+		status = "disabled";
+	};
+};
+
+&sai5 {
+	status = "disabled";
+};
+
+&iomuxc {
+	pinctrl_gpio_keys: gpiokeysgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8	0xc6
+		>;
+	};
+
+	pinctrl_rotary: rotarygrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_ECSPI2_MISO_GPIO5_IO12	0x00000156
+			MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13	0x00000156
+		>;
+	};
+
+	pinctrl_adc: adcgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5	0x00000156
+		>;
+	};
+
+	pinctrl_rtc: rtcgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_ECSPI2_SCLK_GPIO5_IO10	0x00000156
+			MX8MN_IOMUXC_ECSPI2_MOSI_GPIO5_IO11	0x00000156
+		>;
+	};
+};
-- 
2.39.2



From alexghiti at rivosinc.com  Thu Dec  7 07:03:46 2023
From: alexghiti at rivosinc.com (Alexandre Ghiti)
Date: Thu,  7 Dec 2023 16:03:46 +0100
Subject: [PATCH RFC/RFT 2/4] riscv: Add a runtime detection of invalid TLB entries caching
In-Reply-To: <20231207150348.82096-1-alexghiti@rivosinc.com>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
Message-ID: <20231207150348.82096-3-alexghiti@rivosinc.com>

This mechanism allows to completely bypass the sfence.vma introduced by
the previous commit for uarchs that do not cache invalid TLB entries.

Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
---
 arch/riscv/mm/init.c | 124 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 124 insertions(+)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 379403de6c6f..2e854613740c 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -56,6 +56,8 @@ bool pgtable_l5_enabled = IS_ENABLED(CONFIG_64BIT) && !IS_ENABLED(CONFIG_XIP_KER
 EXPORT_SYMBOL(pgtable_l4_enabled);
 EXPORT_SYMBOL(pgtable_l5_enabled);
 
+bool tlb_caching_invalid_entries;
+
 phys_addr_t phys_ram_base __ro_after_init;
 EXPORT_SYMBOL(phys_ram_base);
 
@@ -750,6 +752,18 @@ static void __init disable_pgtable_l4(void)
 	satp_mode = SATP_MODE_39;
 }
 
+static void __init enable_pgtable_l5(void)
+{
+	pgtable_l5_enabled = true;
+	satp_mode = SATP_MODE_57;
+}
+
+static void __init enable_pgtable_l4(void)
+{
+	pgtable_l4_enabled = true;
+	satp_mode = SATP_MODE_48;
+}
+
 static int __init print_no4lvl(char *p)
 {
 	pr_info("Disabled 4-level and 5-level paging");
@@ -826,6 +840,112 @@ static __init void set_satp_mode(uintptr_t dtb_pa)
 	memset(early_pud, 0, PAGE_SIZE);
 	memset(early_pmd, 0, PAGE_SIZE);
 }
+
+/* Determine at runtime if the uarch caches invalid TLB entries */
+static __init void set_tlb_caching_invalid_entries(void)
+{
+#define NR_RETRIES_CACHING_INVALID_ENTRIES	50
+	uintptr_t set_tlb_caching_invalid_entries_pmd = ((unsigned long)set_tlb_caching_invalid_entries) & PMD_MASK;
+	// TODO the test_addr as defined below could go into another pud...
+	uintptr_t test_addr = set_tlb_caching_invalid_entries_pmd + 2 * PMD_SIZE;
+	pmd_t valid_pmd;
+	u64 satp;
+	int i = 0;
+
+	/* To ease the page table creation */
+	disable_pgtable_l5();
+	disable_pgtable_l4();
+
+	/* Establish a mapping for set_tlb_caching_invalid_entries() in sv39 */
+	create_pgd_mapping(early_pg_dir,
+			   set_tlb_caching_invalid_entries_pmd,
+			   (uintptr_t)early_pmd,
+			   PGDIR_SIZE, PAGE_TABLE);
+
+	/* Handle the case where set_tlb_caching_invalid_entries straddles 2 PMDs */
+	create_pmd_mapping(early_pmd,
+			   set_tlb_caching_invalid_entries_pmd,
+			   set_tlb_caching_invalid_entries_pmd,
+			   PMD_SIZE, PAGE_KERNEL_EXEC);
+	create_pmd_mapping(early_pmd,
+			   set_tlb_caching_invalid_entries_pmd + PMD_SIZE,
+			   set_tlb_caching_invalid_entries_pmd + PMD_SIZE,
+			   PMD_SIZE, PAGE_KERNEL_EXEC);
+
+	/* Establish an invalid mapping */
+	create_pmd_mapping(early_pmd, test_addr, 0, PMD_SIZE, __pgprot(0));
+
+	/* Precompute the valid pmd here because the mapping for pfn_pmd() won't exist */
+	valid_pmd = pfn_pmd(PFN_DOWN(set_tlb_caching_invalid_entries_pmd), PAGE_KERNEL);
+
+	local_flush_tlb_all();
+	satp = PFN_DOWN((uintptr_t)&early_pg_dir) | SATP_MODE_39;
+	csr_write(CSR_SATP, satp);
+
+	/*
+	 * Set stvec to after the trapping access, access this invalid mapping
+	 * and legitimately trap
+	 */
+	// TODO: Should I save the previous stvec?
+#define ASM_STR(x)	__ASM_STR(x)
+	asm volatile(
+		"la a0, 1f				\n"
+		"csrw " ASM_STR(CSR_TVEC) ", a0		\n"
+		"ld a0, 0(%0)				\n"
+		".align 2				\n"
+		"1:					\n"
+		:
+		: "r" (test_addr)
+		: "a0"
+	);
+
+	/* Now establish a valid mapping to check if the invalid one is cached */
+	early_pmd[pmd_index(test_addr)] = valid_pmd;
+
+	/*
+	 * Access the valid mapping multiple times: indeed, we can't use
+	 * sfence.vma as a barrier to make sure the cpu did not reorder accesses
+	 * so we may trap even if the uarch does not cache invalid entries. By
+	 * trying a few times, we make sure that those uarchs will see the right
+	 * mapping at some point.
+	 */
+
+	i = NR_RETRIES_CACHING_INVALID_ENTRIES;
+
+#define ASM_STR(x)	__ASM_STR(x)
+	asm_volatile_goto(
+		"la a0, 1f					\n"
+		"csrw " ASM_STR(CSR_TVEC) ", a0			\n"
+		".align 2					\n"
+		"1:						\n"
+		"addi %0, %0, -1				\n"
+		"blt %0, zero, %l[caching_invalid_entries]	\n"
+		"ld a0, 0(%1)					\n"
+		:
+		: "r" (i), "r" (test_addr)
+		: "a0"
+		: caching_invalid_entries
+	);
+
+	csr_write(CSR_SATP, 0ULL);
+	local_flush_tlb_all();
+
+	/* If we don't trap, the uarch does not cache invalid entries! */
+	tlb_caching_invalid_entries = false;
+	goto clean;
+
+caching_invalid_entries:
+	csr_write(CSR_SATP, 0ULL);
+	local_flush_tlb_all();
+
+	tlb_caching_invalid_entries = true;
+clean:
+	memset(early_pg_dir, 0, PAGE_SIZE);
+	memset(early_pmd, 0, PAGE_SIZE);
+
+	enable_pgtable_l4();
+	enable_pgtable_l5();
+}
 #endif
 
 /*
@@ -1072,6 +1192,7 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
 #endif
 
 #if defined(CONFIG_64BIT) && !defined(CONFIG_XIP_KERNEL)
+	set_tlb_caching_invalid_entries();
 	set_satp_mode(dtb_pa);
 #endif
 
@@ -1322,6 +1443,9 @@ static void __init setup_vm_final(void)
 	local_flush_tlb_all();
 
 	pt_ops_set_late();
+
+	pr_info("uarch caches invalid entries: %s",
+		tlb_caching_invalid_entries ? "yes" : "no");
 }
 #else
 asmlinkage void __init setup_vm(uintptr_t dtb_pa)
-- 
2.39.2



From alexghiti at rivosinc.com  Thu Dec  7 07:03:47 2023
From: alexghiti at rivosinc.com (Alexandre Ghiti)
Date: Thu,  7 Dec 2023 16:03:47 +0100
Subject: [PATCH RFC/RFT 3/4] riscv: Stop emitting preventive sfence.vma for new userspace mappings
In-Reply-To: <20231207150348.82096-1-alexghiti@rivosinc.com>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
Message-ID: <20231207150348.82096-4-alexghiti@rivosinc.com>

The preventive sfence.vma were emitted because new mappings must be made
visible to the page table walker, either the uarch caches invalid
entries or not.

Actually, there is no need to preventively sfence.vma on new mappings for
userspace, this should be handled only in the page fault path.

This allows to drastically reduce the number of sfence.vma emitted:

* Ubuntu boot to login:
Before: ~630k sfence.vma
After:  ~200k sfence.vma

* ltp - mmapstress01
Before: ~45k
After:  ~6.3k

* lmbench - lat_pagefault
Before: ~665k
After:   832 (!)

* lmbench - lat_mmap
Before: ~546k
After:   718 (!)

The only issue with the removal of sfence.vma in update_mmu_cache() is
that on uarchs that cache invalid entries, those won't be invalidated
until the process takes a fault: so that's an additional fault in those
cases.

Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
---
 arch/arm64/include/asm/pgtable.h              |  2 +-
 arch/mips/include/asm/pgtable.h               |  6 +--
 arch/powerpc/include/asm/book3s/64/tlbflush.h |  8 ++--
 arch/riscv/include/asm/pgtable.h              | 43 +++++++++++--------
 include/linux/pgtable.h                       |  8 +++-
 mm/memory.c                                   | 12 +++++-
 6 files changed, 48 insertions(+), 31 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 7f7d9b1df4e5..728f25f529a5 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -57,7 +57,7 @@ static inline bool arch_thp_swp_supported(void)
  * fault on one CPU which has been handled concurrently by another CPU
  * does not need to perform additional invalidation.
  */
-#define flush_tlb_fix_spurious_fault(vma, address, ptep) do { } while (0)
+#define flush_tlb_fix_spurious_write_fault(vma, address, ptep) do { } while (0)
 
 /*
  * ZERO_PAGE is a global shared page that is always zero: used
diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index 430b208c0130..84439fe6ed29 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -478,9 +478,9 @@ static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
 	return __pgprot(prot);
 }
 
-static inline void flush_tlb_fix_spurious_fault(struct vm_area_struct *vma,
-						unsigned long address,
-						pte_t *ptep)
+static inline void flush_tlb_fix_spurious_write_fault(struct vm_area_struct *vma,
+						      unsigned long address,
+						      pte_t *ptep)
 {
 }
 
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index 1950c1b825b4..7166d56f90db 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -128,10 +128,10 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
 #define flush_tlb_page(vma, addr)	local_flush_tlb_page(vma, addr)
 #endif /* CONFIG_SMP */
 
-#define flush_tlb_fix_spurious_fault flush_tlb_fix_spurious_fault
-static inline void flush_tlb_fix_spurious_fault(struct vm_area_struct *vma,
-						unsigned long address,
-						pte_t *ptep)
+#define flush_tlb_fix_spurious_write_fault flush_tlb_fix_spurious_write_fault
+static inline void flush_tlb_fix_spurious_write_fault(struct vm_area_struct *vma,
+						      unsigned long address,
+						      pte_t *ptep)
 {
 	/*
 	 * Book3S 64 does not require spurious fault flushes because the PTE
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index b2ba3f79cfe9..89aa5650f104 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -472,28 +472,20 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf,
 		struct vm_area_struct *vma, unsigned long address,
 		pte_t *ptep, unsigned int nr)
 {
-	/*
-	 * The kernel assumes that TLBs don't cache invalid entries, but
-	 * in RISC-V, SFENCE.VMA specifies an ordering constraint, not a
-	 * cache flush; it is necessary even after writing invalid entries.
-	 * Relying on flush_tlb_fix_spurious_fault would suffice, but
-	 * the extra traps reduce performance.  So, eagerly SFENCE.VMA.
-	 */
-	while (nr--)
-		local_flush_tlb_page(address + nr * PAGE_SIZE);
 }
 #define update_mmu_cache(vma, addr, ptep) \
 	update_mmu_cache_range(NULL, vma, addr, ptep, 1)
 
 #define __HAVE_ARCH_UPDATE_MMU_TLB
-#define update_mmu_tlb update_mmu_cache
+static inline void update_mmu_tlb(struct vm_area_struct *vma,
+				  unsigned long address, pte_t *ptep)
+{
+	flush_tlb_range(vma, address, address + PAGE_SIZE);
+}
 
 static inline void update_mmu_cache_pmd(struct vm_area_struct *vma,
 		unsigned long address, pmd_t *pmdp)
 {
-	pte_t *ptep = (pte_t *)pmdp;
-
-	update_mmu_cache(vma, address, ptep);
 }
 
 #define __HAVE_ARCH_PTE_SAME
@@ -548,13 +540,26 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma,
 					unsigned long address, pte_t *ptep,
 					pte_t entry, int dirty)
 {
-	if (!pte_same(*ptep, entry))
+	if (!pte_same(*ptep, entry)) {
 		__set_pte_at(ptep, entry);
-	/*
-	 * update_mmu_cache will unconditionally execute, handling both
-	 * the case that the PTE changed and the spurious fault case.
-	 */
-	return true;
+		/* Here only not svadu is impacted */
+		flush_tlb_page(vma, address);
+		return true;
+	}
+
+	return false;
+}
+
+extern u64 nr_sfence_vma_handle_exception;
+extern bool tlb_caching_invalid_entries;
+
+#define flush_tlb_fix_spurious_read_fault flush_tlb_fix_spurious_read_fault
+static inline void flush_tlb_fix_spurious_read_fault(struct vm_area_struct *vma,
+						     unsigned long address,
+						     pte_t *ptep)
+{
+	if (tlb_caching_invalid_entries)
+		flush_tlb_page(vma, address);
 }
 
 #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index af7639c3b0a3..7abaf42ef612 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -931,8 +931,12 @@ static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
 # define pte_accessible(mm, pte)	((void)(pte), 1)
 #endif
 
-#ifndef flush_tlb_fix_spurious_fault
-#define flush_tlb_fix_spurious_fault(vma, address, ptep) flush_tlb_page(vma, address)
+#ifndef flush_tlb_fix_spurious_write_fault
+#define flush_tlb_fix_spurious_write_fault(vma, address, ptep) flush_tlb_page(vma, address)
+#endif
+
+#ifndef flush_tlb_fix_spurious_read_fault
+#define flush_tlb_fix_spurious_read_fault(vma, address, ptep)
 #endif
 
 /*
diff --git a/mm/memory.c b/mm/memory.c
index 517221f01303..5cb0ccf0c03f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5014,8 +5014,16 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf)
 		 * with threads.
 		 */
 		if (vmf->flags & FAULT_FLAG_WRITE)
-			flush_tlb_fix_spurious_fault(vmf->vma, vmf->address,
-						     vmf->pte);
+			flush_tlb_fix_spurious_write_fault(vmf->vma, vmf->address,
+							   vmf->pte);
+		else
+			/*
+			 * With the pte_same(ptep_get(vmf->pte), entry) check
+			 * that calls update_mmu_tlb() above, multiple threads
+			 * faulting at the same time won't get there.
+			 */
+			flush_tlb_fix_spurious_read_fault(vmf->vma, vmf->address,
+							  vmf->pte);
 	}
 unlock:
 	pte_unmap_unlock(vmf->pte, vmf->ptl);
-- 
2.39.2



From kan.liang at linux.intel.com  Thu Dec  7 07:05:54 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Thu, 7 Dec 2023 10:05:54 -0500
Subject: [PATCH 0/6] Clean up perf mem
In-Reply-To: <0597b44c-226d-1180-d55d-bcf9bbd2e03f@amd.com>
References: <20231206201324.184059-1-kan.liang@linux.intel.com>
 <0597b44c-226d-1180-d55d-bcf9bbd2e03f@amd.com>
Message-ID: <a22be949-56fb-4e18-bd5a-5db441fd53df@linux.intel.com>



On 2023-12-07 9:44 a.m., Ravi Bangoria wrote:
>> The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
>> etc. But I can only test it on two Intel platforms.
>> Please give it try, if you have machines with other ARCHs.
> 
> I did a quick perf mem and perf c2c test, with the fix I suggested
> in patch #1, and things seems to be working fine.
> 
> [For AMD specific changes]
> Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>

Thanks Ravi.

Kan


From tabba at google.com  Thu Dec  7 07:06:44 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 7 Dec 2023 15:06:44 +0000
Subject: [PATCH v2 06/12] KVM: arm64: Update and fix FGT register masks
In-Reply-To: <20231207150001.GA29745@e124191.cambridge.arm.com>
References: <20231206100503.564090-1-tabba@google.com> <20231206100503.564090-7-tabba@google.com>
 <20231207150001.GA29745@e124191.cambridge.arm.com>
Message-ID: <CA+EHjTwC+66GyPma00XQ6VRzktYzxB7XXr+7zSKFrG6U-+EeEQ@mail.gmail.com>

Hi Joey,

On Thu, Dec 7, 2023 at 3:00?PM Joey Gouly <joey.gouly at arm.com> wrote:
>
> Hello Fuad,
>
> On Wed, Dec 06, 2023 at 10:04:56AM +0000, Fuad Tabba wrote:
> > New trap bits have been defined in the 2023-09 Arm Architecture
> > System Registers xml specification [*]. Moreover, the existing
> > definitions of some of the mask and the RES0 bits overlap, which
> > could be wrong, confusing, or both.
> >
> > Update the bits to represent the latest spec (as of this patch,
> > 2023-09), and ensure that the existing bits are consistent.
> >
> > Subsequent patches will use the generated RES0 fields instead of
> > specifying them manually. This patch keeps the manual encoding of
> > the bits to make it easier to review the series.
> >
> > [*] https://developer.arm.com/downloads/-/exploration-tools
> >
> > Fixes: 0fd76865006d ("KVM: arm64: Add nPIR{E0}_EL1 to HFG traps")
> > Signed-off-by: Fuad Tabba <tabba at google.com>
> > ---
> >  arch/arm64/include/asm/kvm_arm.h | 39 ++++++++++++++++++++------------
> >  1 file changed, 24 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> > index 7de0a7062625..b0dc3249d5cd 100644
> > --- a/arch/arm64/include/asm/kvm_arm.h
> > +++ b/arch/arm64/include/asm/kvm_arm.h
> > @@ -344,30 +344,39 @@
> >   * Once we get to a point where the two describe the same thing, we'll
> >   * merge the definitions. One day.
> >   */
> > -#define __HFGRTR_EL2_RES0    (GENMASK(63, 56) | GENMASK(53, 51))
> > +#define __HFGRTR_EL2_RES0    BIT(51)
> >  #define __HFGRTR_EL2_MASK    GENMASK(49, 0)
> > -#define __HFGRTR_EL2_nMASK   (GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> > +#define __HFGRTR_EL2_nMASK   (GENMASK(63, 52) | BIT(50))
> >
> > -#define __HFGWTR_EL2_RES0    (GENMASK(63, 56) | GENMASK(53, 51) |    \
> > -                              BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
> > -                              GENMASK(26, 25) | BIT(21) | BIT(18) |  \
> > +#define __HFGWTR_EL2_RES0    (BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
> > +                              BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
> >                                GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
> > -#define __HFGWTR_EL2_MASK    GENMASK(49, 0)
> > -#define __HFGWTR_EL2_nMASK   (GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> > +#define __HFGWTR_EL2_MASK    (GENMASK(49, 47) | GENMASK(45, 43) | \
> > +                              BIT(41) | GENMASK(39, 29) | BIT(27) | \
> > +                              GENMASK(24, 22) | GENMASK(20, 19) | \
> > +                              GENMASK(17, 16) | GENMASK(13, 11) | \
> > +                              GENMASK(8, 3) | GENMASK(1, 0))
> > +#define __HFGWTR_EL2_nMASK   (GENMASK(63, 52) | BIT(50))
>
> By adding all these bits to *_nMASK, we're allowing a guest to access registers
> which KVM doesn't (currently) deal with.  For example if I apply this patch
> series, a guest can access S2POR_EL1, previously it would print something like:
>
>         kvm [80]: Unsupported guest sys_reg access at: ffffc42969c1f270 [600000c5]
>          { Op0( 3), Op1( 0), CRn(10), CRm( 2), Op2( 5), func_read },
>
> After applying this patch series, the guest can read S2POR_EL1.
>
> We don't expose S2POE to the guest through ID_AA64MMFR3_EL1, so a well behaved
> guest shouldn't access it, but there's nothing stopping it.
>
> My question is, is this intended? Or do we need to update the following code
> (and comment!) to trap all the stuff we don't currently handle (along with
> ACCDATA_EL1):

Thanks for pointing this out, and no, it's not intended. For
consistency, I think it might be good to update the code, as you
suggest, to prevent these accesses. If you and the other reviewers are
happy with that solution I can respin with your suggested fix. I have
a couple of other minor fixes as well for the series.

What do you think?

Cheers,
/fuad


>
>         static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
>         {
>
>                 ..
>
>                 /* The default is not to trap anything but ACCDATA_EL1 */
>                 r_val = __HFGRTR_EL2_nMASK & ~HFGxTR_EL2_nACCDATA_EL1;
>                 r_val |= r_set;
>                 r_val &= ~r_clr;
>
>
> Thanks,
> Joey
>
> >
> > -#define __HFGITR_EL2_RES0    GENMASK(63, 57)
> > -#define __HFGITR_EL2_MASK    GENMASK(54, 0)
> > -#define __HFGITR_EL2_nMASK   GENMASK(56, 55)
> > +#define __HFGITR_EL2_RES0    (BIT(63) | BIT(61))
> > +#define __HFGITR_EL2_MASK    (BIT(62) | BIT(60) | GENMASK(54, 0))
> > +#define __HFGITR_EL2_nMASK   GENMASK(59, 55)
> >
> >  #define __HDFGRTR_EL2_RES0   (BIT(49) | BIT(42) | GENMASK(39, 38) |  \
> >                                GENMASK(21, 20) | BIT(8))
> > -#define __HDFGRTR_EL2_MASK   ~__HDFGRTR_EL2_nMASK
> > +#define __HDFGRTR_EL2_MASK   (BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
> > +                              GENMASK(41, 40) | GENMASK(37, 22) | \
> > +                              GENMASK(19, 9) | GENMASK(7, 0))
> >  #define __HDFGRTR_EL2_nMASK  GENMASK(62, 59)
> >
> >  #define __HDFGWTR_EL2_RES0   (BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
> >                                BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
> >                                BIT(22) | BIT(9) | BIT(6))
> > -#define __HDFGWTR_EL2_MASK   ~__HDFGWTR_EL2_nMASK
> > +#define __HDFGWTR_EL2_MASK   (GENMASK(57, 52) | GENMASK(50, 48) | \
> > +                              GENMASK(46, 44) | GENMASK(42, 41) | \
> > +                              GENMASK(37, 35) | GENMASK(33, 31) | \
> > +                              GENMASK(29, 23) | GENMASK(21, 10) | \
> > +                              GENMASK(8, 7) | GENMASK(5, 0))
> >  #define __HDFGWTR_EL2_nMASK  GENMASK(62, 60)
> >
> >  #define __HAFGRTR_EL2_RES0   (GENMASK(63, 50) | GENMASK(16, 5))
> > @@ -375,9 +384,9 @@
> >  #define __HAFGRTR_EL2_nMASK  0UL
> >
> >  /* Similar definitions for HCRX_EL2 */
> > -#define __HCRX_EL2_RES0              (GENMASK(63, 16) | GENMASK(13, 12))
> > -#define __HCRX_EL2_MASK              (0)
> > -#define __HCRX_EL2_nMASK     (GENMASK(15, 14) | GENMASK(4, 0))
> > +#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
> > +#define __HCRX_EL2_MASK              (BIT(6))
> > +#define __HCRX_EL2_nMASK     (GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
> >
> >  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
> >  #define HPFAR_MASK   (~UL(0xf))
> > --
> > 2.43.0.rc2.451.g8631bc7472-goog
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From alexghiti at rivosinc.com  Thu Dec  7 07:03:48 2023
From: alexghiti at rivosinc.com (Alexandre Ghiti)
Date: Thu,  7 Dec 2023 16:03:48 +0100
Subject: [PATCH RFC/RFT 4/4] TEMP: riscv: Add debugfs interface to retrieve #sfence.vma
In-Reply-To: <20231207150348.82096-1-alexghiti@rivosinc.com>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
Message-ID: <20231207150348.82096-5-alexghiti@rivosinc.com>

This is useful for testing/benchmarking.

Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
---
 arch/riscv/include/asm/pgtable.h  |  6 ++++--
 arch/riscv/include/asm/tlbflush.h |  4 ++++
 arch/riscv/kernel/sbi.c           | 12 ++++++++++++
 arch/riscv/mm/tlbflush.c          | 17 +++++++++++++++++
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 89aa5650f104..b0855a620cfd 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -550,7 +550,7 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma,
 	return false;
 }
 
-extern u64 nr_sfence_vma_handle_exception;
+extern u64 nr_sfence_vma_spurious_read;
 extern bool tlb_caching_invalid_entries;
 
 #define flush_tlb_fix_spurious_read_fault flush_tlb_fix_spurious_read_fault
@@ -558,8 +558,10 @@ static inline void flush_tlb_fix_spurious_read_fault(struct vm_area_struct *vma,
 						     unsigned long address,
 						     pte_t *ptep)
 {
-	if (tlb_caching_invalid_entries)
+	if (tlb_caching_invalid_entries) {
+		__sync_fetch_and_add(&nr_sfence_vma_spurious_read, 1UL);
 		flush_tlb_page(vma, address);
+	}
 }
 
 #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
diff --git a/arch/riscv/include/asm/tlbflush.h b/arch/riscv/include/asm/tlbflush.h
index a09196f8de68..f419ec9d2207 100644
--- a/arch/riscv/include/asm/tlbflush.h
+++ b/arch/riscv/include/asm/tlbflush.h
@@ -14,14 +14,18 @@
 #ifdef CONFIG_MMU
 extern unsigned long asid_mask;
 
+extern u64 nr_sfence_vma, nr_sfence_vma_all, nr_sfence_vma_all_asid;
+
 static inline void local_flush_tlb_all(void)
 {
+	__sync_fetch_and_add(&nr_sfence_vma_all, 1UL);
 	__asm__ __volatile__ ("sfence.vma" : : : "memory");
 }
 
 /* Flush one page from local TLB */
 static inline void local_flush_tlb_page(unsigned long addr)
 {
+	__sync_fetch_and_add(&nr_sfence_vma, 1UL);
 	ALT_FLUSH_TLB_PAGE(__asm__ __volatile__ ("sfence.vma %0" : : "r" (addr) : "memory"));
 }
 #else /* CONFIG_MMU */
diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
index c672c8ba9a2a..ac1617759583 100644
--- a/arch/riscv/kernel/sbi.c
+++ b/arch/riscv/kernel/sbi.c
@@ -376,6 +376,8 @@ int sbi_remote_fence_i(const struct cpumask *cpu_mask)
 }
 EXPORT_SYMBOL(sbi_remote_fence_i);
 
+extern u64 nr_sfence_vma, nr_sfence_vma_all, nr_sfence_vma_all_asid;
+
 /**
  * sbi_remote_sfence_vma() - Execute SFENCE.VMA instructions on given remote
  *			     harts for the specified virtual address range.
@@ -389,6 +391,11 @@ int sbi_remote_sfence_vma(const struct cpumask *cpu_mask,
 			   unsigned long start,
 			   unsigned long size)
 {
+	if (size == (unsigned long)-1)
+		__sync_fetch_and_add(&nr_sfence_vma_all, 1UL);
+	else
+		__sync_fetch_and_add(&nr_sfence_vma, ALIGN(size, PAGE_SIZE) / PAGE_SIZE);
+
 	return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
 			    cpu_mask, start, size, 0, 0);
 }
@@ -410,6 +417,11 @@ int sbi_remote_sfence_vma_asid(const struct cpumask *cpu_mask,
 				unsigned long size,
 				unsigned long asid)
 {
+	if (size == (unsigned long)-1)
+		__sync_fetch_and_add(&nr_sfence_vma_all_asid, 1UL);
+	else
+		__sync_fetch_and_add(&nr_sfence_vma, ALIGN(size, PAGE_SIZE) / PAGE_SIZE);
+
 	return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
 			    cpu_mask, start, size, asid, 0);
 }
diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c
index 77be59aadc73..75a3e2dff16a 100644
--- a/arch/riscv/mm/tlbflush.c
+++ b/arch/riscv/mm/tlbflush.c
@@ -3,11 +3,16 @@
 #include <linux/mm.h>
 #include <linux/smp.h>
 #include <linux/sched.h>
+#include <linux/debugfs.h>
 #include <asm/sbi.h>
 #include <asm/mmu_context.h>
 
+u64 nr_sfence_vma, nr_sfence_vma_all, nr_sfence_vma_all_asid,
+	nr_sfence_vma_handle_exception, nr_sfence_vma_spurious_read;
+
 static inline void local_flush_tlb_all_asid(unsigned long asid)
 {
+	__sync_fetch_and_add(&nr_sfence_vma_all_asid, 1);
 	__asm__ __volatile__ ("sfence.vma x0, %0"
 			:
 			: "r" (asid)
@@ -17,6 +22,7 @@ static inline void local_flush_tlb_all_asid(unsigned long asid)
 static inline void local_flush_tlb_page_asid(unsigned long addr,
 		unsigned long asid)
 {
+	__sync_fetch_and_add(&nr_sfence_vma, 1);
 	__asm__ __volatile__ ("sfence.vma %0, %1"
 			:
 			: "r" (addr), "r" (asid)
@@ -149,3 +155,14 @@ void flush_pmd_tlb_range(struct vm_area_struct *vma, unsigned long start,
 	__flush_tlb_range(vma->vm_mm, start, end - start, PMD_SIZE);
 }
 #endif
+
+static int debugfs_nr_sfence_vma(void)
+{
+	debugfs_create_u64("nr_sfence_vma", 0444, NULL, &nr_sfence_vma);
+	debugfs_create_u64("nr_sfence_vma_all", 0444, NULL, &nr_sfence_vma_all);
+	debugfs_create_u64("nr_sfence_vma_all_asid", 0444, NULL, &nr_sfence_vma_all_asid);
+	debugfs_create_u64("nr_sfence_vma_handle_exception", 0444, NULL, &nr_sfence_vma_handle_exception);
+	debugfs_create_u64("nr_sfence_vma_spurious_read", 0444, NULL, &nr_sfence_vma_spurious_read);
+	return 0;
+}
+device_initcall(debugfs_nr_sfence_vma);
-- 
2.39.2



From james.morse at arm.com  Thu Dec  7 07:08:00 2023
From: james.morse at arm.com (James Morse)
Date: Thu,  7 Dec 2023 15:08:00 +0000
Subject: [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest
Message-ID: <20231207150804.3425468-1-james.morse@arm.com>

'lo

This series fixes up a long standing bug where MPAM was accidentally exposed
to a guest, but the feature was not otherwise trapped or context switched.
This could result in KVM warning about unexpected traps, and injecting an
undef into the guest contradicting the ID registers.
This would prevent an MPAM aware kernel from booting - fortunately, there
aren't any of those.

Ideally, we'd take the MPAM feature away from the ID registers, but that
would leave existing guests unable to migrate to a newer kernel. Instead,
use the writable ID registers to allow MPAM to be re-enabled - but emulate
it as RAZ/WI for the system registers that are trapped.
This means KVM emulates a machine with 0 PARTID and 0 PMG, so the MPAMx_ELy
registers don't need to be preserved by KVM. This has the added advantage
that MPAMx_ELy's 'MPAMEN' bit will be read as zero, telling guests that
this feature is disabled.

Guests have never been able to make use of MPAM as these system registers
are only for configuring the CPU, to see any change in behaviour you need
to configure the Memory System Components (MSC) which are MMIO gadgets that
belong to the host.

This series includes the head.S and KVM changes to enable/disable traps. If
MPAM is neither enabled nor emulated by EL3 firmware, these system register
accesses will trap to EL3.
If your kernel doesn't boot, and the problem bisects here - please update
your firmware. MPAM has been supported by trusted firmware since v1.6 in
2018. (also noted on patch 2).

This series is based on v6.7-rc4 and can be retrieved from:
https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/log/?h=mpam/kvm_mpam_fix/v2


Thanks,

James Morse (4):
  arm64: head.S: Initialise MPAM EL2 registers and disable traps
  arm64: cpufeature: discover CPU support for MPAM
  KVM: arm64: Fix missing traps of guest accesses to the MPAM registers
  KVM: arm64: Disable MPAM visibility by default, and handle traps

 .../arch/arm64/cpu-feature-registers.rst      |  2 +
 arch/arm64/Kconfig                            | 19 ++++-
 arch/arm64/include/asm/cpu.h                  |  1 +
 arch/arm64/include/asm/cpufeature.h           | 13 ++++
 arch/arm64/include/asm/el2_setup.h            | 16 ++++
 arch/arm64/include/asm/kvm_arm.h              |  1 +
 arch/arm64/include/asm/mpam.h                 | 75 +++++++++++++++++++
 arch/arm64/include/asm/sysreg.h               |  8 ++
 arch/arm64/kernel/Makefile                    |  1 +
 arch/arm64/kernel/cpufeature.c                | 67 +++++++++++++++++
 arch/arm64/kernel/cpuinfo.c                   |  4 +
 arch/arm64/kernel/image-vars.h                |  5 ++
 arch/arm64/kernel/mpam.c                      |  8 ++
 arch/arm64/kvm/hyp/include/hyp/switch.h       | 32 ++++++++
 arch/arm64/kvm/sys_regs.c                     | 71 +++++++++++++++++-
 arch/arm64/tools/cpucaps                      |  1 +
 arch/arm64/tools/sysreg                       | 32 ++++++++
 17 files changed, 352 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm64/include/asm/mpam.h
 create mode 100644 arch/arm64/kernel/mpam.c

-- 
2.39.2



From james.morse at arm.com  Thu Dec  7 07:08:02 2023
From: james.morse at arm.com (James Morse)
Date: Thu,  7 Dec 2023 15:08:02 +0000
Subject: [PATCH v2 2/4] arm64: cpufeature: discover CPU support for MPAM
In-Reply-To: <20231207150804.3425468-1-james.morse@arm.com>
References: <20231207150804.3425468-1-james.morse@arm.com>
Message-ID: <20231207150804.3425468-3-james.morse@arm.com>

ARMv8.4 adds support for 'Memory Partitioning And Monitoring' (MPAM)
which describes an interface to cache and bandwidth controls wherever
they appear in the system.

Add support to detect MPAM. Like SVE, MPAM has an extra id register that
describes the virtualisation support, which is optional. Detect this
separately so we can detect mismatched/insane systems, but still use
MPAM on the host even if the virtualisation support is missing.

MPAM needs enabling at the highest implemented exception level, otherwise
the register accesses trap. The 'enabled' flag is accessible to lower
exception levels, but its in a register that traps when MPAM isn't enabled.
The cpufeature 'matches' hook is extended to test this on one of the
CPUs, so that firmware can emulate MPAM as disabled if it is reserved
for use by secure world.

(If you have a boot failure that bisects here its likely your CPUs
advertise MPAM in the id registers, but firmware failed to either enable
or MPAM, or emulate the trap as if it were disabled)

Signed-off-by: James Morse <james.morse at arm.com>
---
 .../arch/arm64/cpu-feature-registers.rst      |  2 +
 arch/arm64/Kconfig                            | 19 ++++-
 arch/arm64/include/asm/cpu.h                  |  1 +
 arch/arm64/include/asm/cpufeature.h           | 13 ++++
 arch/arm64/include/asm/mpam.h                 | 75 +++++++++++++++++++
 arch/arm64/include/asm/sysreg.h               |  8 ++
 arch/arm64/kernel/Makefile                    |  1 +
 arch/arm64/kernel/cpufeature.c                | 67 +++++++++++++++++
 arch/arm64/kernel/cpuinfo.c                   |  4 +
 arch/arm64/kernel/mpam.c                      |  8 ++
 arch/arm64/tools/cpucaps                      |  1 +
 arch/arm64/tools/sysreg                       | 32 ++++++++
 12 files changed, 230 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/include/asm/mpam.h
 create mode 100644 arch/arm64/kernel/mpam.c

diff --git a/Documentation/arch/arm64/cpu-feature-registers.rst b/Documentation/arch/arm64/cpu-feature-registers.rst
index 44f9bd78539d..253e9743de2f 100644
--- a/Documentation/arch/arm64/cpu-feature-registers.rst
+++ b/Documentation/arch/arm64/cpu-feature-registers.rst
@@ -152,6 +152,8 @@ infrastructure:
      +------------------------------+---------+---------+
      | DIT                          | [51-48] |    y    |
      +------------------------------+---------+---------+
+     | MPAM                         | [43-40] |    n    |
+     +------------------------------+---------+---------+
      | SVE                          | [35-32] |    y    |
      +------------------------------+---------+---------+
      | GIC                          | [27-24] |    n    |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..022af9712f90 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1959,7 +1959,24 @@ config ARM64_TLB_RANGE
 	  The feature introduces new assembly instructions, and they were
 	  support when binutils >= 2.30.
 
-endmenu # "ARMv8.4 architectural features"
+config ARM64_MPAM
+	bool "Enable support for MPAM"
+	help
+	  Memory Partitioning and Monitoring is an optional extension
+	  that allows the CPUs to mark load and store transactions with
+	  labels for partition-id and performance-monitoring-group.
+	  System components, such as the caches, can use the partition-id
+	  to apply a performance policy. MPAM monitors can use the
+	  partition-id and performance-monitoring-group to measure the
+	  cache occupancy or data throughput.
+
+	  Use of this extension requires CPU support, support in the
+	  memory system components (MSC), and a description from firmware
+	  of where the MSC are in the address space.
+
+	  MPAM is exposed to user-space via the resctrl pseudo filesystem.
+
+endmenu
 
 menu "ARMv8.5 architectural features"
 
diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
index f3034099fd95..9fe9d487f124 100644
--- a/arch/arm64/include/asm/cpu.h
+++ b/arch/arm64/include/asm/cpu.h
@@ -47,6 +47,7 @@ struct cpuinfo_arm64 {
 	u64		reg_revidr;
 	u64		reg_gmid;
 	u64		reg_smidr;
+	u64		reg_mpamidr;
 
 	u64		reg_id_aa64dfr0;
 	u64		reg_id_aa64dfr1;
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index f6d416fe49b0..9d324b48612f 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -610,6 +610,13 @@ static inline bool id_aa64pfr1_sme(u64 pfr1)
 	return val > 0;
 }
 
+static inline bool id_aa64pfr0_mpam(u64 pfr0)
+{
+	u32 val = cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_EL1_MPAM_SHIFT);
+
+	return val > 0;
+}
+
 static inline bool id_aa64pfr1_mte(u64 pfr1)
 {
 	u32 val = cpuid_feature_extract_unsigned_field(pfr1, ID_AA64PFR1_EL1_MTE_SHIFT);
@@ -819,6 +826,12 @@ static inline bool system_supports_tlb_range(void)
 	return alternative_has_cap_unlikely(ARM64_HAS_TLB_RANGE);
 }
 
+static inline bool cpus_support_mpam(void)
+{
+	return IS_ENABLED(CONFIG_ARM64_MPAM) &&
+		cpus_have_final_cap(ARM64_MPAM);
+}
+
 int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
 bool try_emulate_mrs(struct pt_regs *regs, u32 isn);
 
diff --git a/arch/arm64/include/asm/mpam.h b/arch/arm64/include/asm/mpam.h
new file mode 100644
index 000000000000..82d4f6008aeb
--- /dev/null
+++ b/arch/arm64/include/asm/mpam.h
@@ -0,0 +1,75 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2021 Arm Ltd. */
+
+#ifndef __ASM__MPAM_H
+#define __ASM__MPAM_H
+
+#include <linux/bitops.h>
+#include <linux/init.h>
+#include <linux/jump_label.h>
+
+#include <asm/cpucaps.h>
+#include <asm/cpufeature.h>
+#include <asm/sysreg.h>
+
+/* CPU Registers */
+#define MPAM_SYSREG_EN			BIT_ULL(63)
+#define MPAM_SYSREG_TRAP_IDR		BIT_ULL(58)
+#define MPAM_SYSREG_TRAP_MPAM0_EL1	BIT_ULL(49)
+#define MPAM_SYSREG_TRAP_MPAM1_EL1	BIT_ULL(48)
+#define MPAM_SYSREG_PMG_D		GENMASK(47, 40)
+#define MPAM_SYSREG_PMG_I		GENMASK(39, 32)
+#define MPAM_SYSREG_PARTID_D		GENMASK(31, 16)
+#define MPAM_SYSREG_PARTID_I		GENMASK(15, 0)
+
+#define MPAMIDR_PMG_MAX			GENMASK(40, 32)
+#define MPAMIDR_PMG_MAX_SHIFT		32
+#define MPAMIDR_PMG_MAX_LEN		8
+#define MPAMIDR_VPMR_MAX		GENMASK(20, 18)
+#define MPAMIDR_VPMR_MAX_SHIFT		18
+#define MPAMIDR_VPMR_MAX_LEN		3
+#define MPAMIDR_HAS_HCR			BIT(17)
+#define MPAMIDR_HAS_HCR_SHIFT		17
+#define MPAMIDR_PARTID_MAX		GENMASK(15, 0)
+#define MPAMIDR_PARTID_MAX_SHIFT	0
+#define MPAMIDR_PARTID_MAX_LEN		15
+
+#define MPAMHCR_EL0_VPMEN		BIT_ULL(0)
+#define MPAMHCR_EL1_VPMEN		BIT_ULL(1)
+#define MPAMHCR_GSTAPP_PLK		BIT_ULL(8)
+#define MPAMHCR_TRAP_MPAMIDR		BIT_ULL(31)
+
+/* Properties of the VPM registers */
+#define MPAM_VPM_NUM_REGS		8
+#define MPAM_VPM_PARTID_LEN		16
+#define MPAM_VPM_PARTID_MASK		0xffff
+#define MPAM_VPM_REG_LEN		64
+#define MPAM_VPM_PARTIDS_PER_REG	(MPAM_VPM_REG_LEN / MPAM_VPM_PARTID_LEN)
+#define MPAM_VPM_MAX_PARTID		(MPAM_VPM_NUM_REGS * MPAM_VPM_PARTIDS_PER_REG)
+
+DECLARE_STATIC_KEY_FALSE(arm64_mpam_has_hcr);
+
+/* check whether all CPUs have MPAM support */
+static inline bool mpam_cpus_have_feature(void)
+{
+	if (IS_ENABLED(CONFIG_ARM64_MPAM))
+		return cpus_have_final_cap(ARM64_MPAM);
+	return false;
+}
+
+/* check whether all CPUs have MPAM virtualisation support */
+static inline bool mpam_cpus_have_mpam_hcr(void)
+{
+	if (IS_ENABLED(CONFIG_ARM64_MPAM))
+		return static_branch_unlikely(&arm64_mpam_has_hcr);
+	return false;
+}
+
+/* enable MPAM virtualisation support */
+static inline void __init __enable_mpam_hcr(void)
+{
+	if (IS_ENABLED(CONFIG_ARM64_MPAM))
+		static_branch_enable(&arm64_mpam_has_hcr);
+}
+
+#endif /* __ASM__MPAM_H */
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 5e65f51c10d2..8bf4c359e19f 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -535,6 +535,13 @@
 #define SYS_MPAMVPM6_EL2		__SYS__MPAMVPMx_EL2(6)
 #define SYS_MPAMVPM7_EL2		__SYS__MPAMVPMx_EL2(7)
 
+#define SYS_MPAMHCR_EL2			sys_reg(3, 4, 10, 4, 0)
+#define SYS_MPAMVPMV_EL2		sys_reg(3, 4, 10, 4, 1)
+#define SYS_MPAM2_EL2			sys_reg(3, 4, 10, 5, 0)
+
+#define __VPMn_op2(n)			((n) & 0x7)
+#define SYS_MPAM_VPMn_EL2(n)		sys_reg(3, 4, 10, 6, __VPMn_op2(n))
+
 #define SYS_VBAR_EL2			sys_reg(3, 4, 12, 0, 0)
 #define SYS_RVBAR_EL2			sys_reg(3, 4, 12, 0, 1)
 #define SYS_RMR_EL2			sys_reg(3, 4, 12, 0, 2)
@@ -622,6 +629,7 @@
 #define SYS_PMSCR_EL12			sys_reg(3, 5, 9, 9, 0)
 #define SYS_MAIR_EL12			sys_reg(3, 5, 10, 2, 0)
 #define SYS_AMAIR_EL12			sys_reg(3, 5, 10, 3, 0)
+#define SYS_MPAM1_EL12			sys_reg(3, 5, 10, 5, 0)
 #define SYS_VBAR_EL12			sys_reg(3, 5, 12, 0, 0)
 #define SYS_CONTEXTIDR_EL12		sys_reg(3, 5, 13, 0, 1)
 #define SYS_SCXTNUM_EL12		sys_reg(3, 5, 13, 0, 7)
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index d95b3d6b471a..685e0a58a4c6 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_CRASH_DUMP)		+= crash_dump.o
 obj-$(CONFIG_CRASH_CORE)		+= crash_core.o
 obj-$(CONFIG_ARM_SDE_INTERFACE)		+= sdei.o
 obj-$(CONFIG_ARM64_PTR_AUTH)		+= pointer_auth.o
+obj-$(CONFIG_ARM64_MPAM)		+= mpam.o
 obj-$(CONFIG_ARM64_MTE)			+= mte.o
 obj-y					+= vdso-wrap.o
 obj-$(CONFIG_COMPAT_VDSO)		+= vdso32-wrap.o
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 91d2d6714969..609165eb89c6 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -84,6 +84,7 @@
 #include <asm/insn.h>
 #include <asm/kvm_host.h>
 #include <asm/mmu_context.h>
+#include <asm/mpam.h>
 #include <asm/mte.h>
 #include <asm/processor.h>
 #include <asm/smp.h>
@@ -613,6 +614,14 @@ static const struct arm64_ftr_bits ftr_id_dfr1[] = {
 	ARM64_FTR_END,
 };
 
+static const struct arm64_ftr_bits ftr_mpamidr[] = {
+	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, MPAMIDR_PMG_MAX_SHIFT, MPAMIDR_PMG_MAX_LEN, 0),        /* PMG_MAX */
+	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, MPAMIDR_VPMR_MAX_SHIFT, MPAMIDR_VPMR_MAX_LEN, 0),      /* VPMR_MAX */
+	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, MPAMIDR_HAS_HCR_SHIFT, 1, 0), /* HAS_HCR */
+	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, MPAMIDR_PARTID_MAX_SHIFT, MPAMIDR_PARTID_MAX_LEN, 0),  /* PARTID_MAX */
+	ARM64_FTR_END,
+};
+
 /*
  * Common ftr bits for a 32bit register with all hidden, strict
  * attributes, with 4bit feature fields and a default safe value of
@@ -725,6 +734,9 @@ static const struct __ftr_reg_entry {
 	ARM64_FTR_REG(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2),
 	ARM64_FTR_REG(SYS_ID_AA64MMFR3_EL1, ftr_id_aa64mmfr3),
 
+	/* Op1 = 0, CRn = 10, CRm = 4 */
+	ARM64_FTR_REG(SYS_MPAMIDR_EL1, ftr_mpamidr),
+
 	/* Op1 = 1, CRn = 0, CRm = 0 */
 	ARM64_FTR_REG(SYS_GMID_EL1, ftr_gmid),
 
@@ -1079,6 +1091,9 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
 		cpacr_restore(cpacr);
 	}
 
+	if (id_aa64pfr0_mpam(info->reg_id_aa64pfr0))
+		init_cpu_ftr_reg(SYS_MPAMIDR_EL1, info->reg_mpamidr);
+
 	if (id_aa64pfr1_mte(info->reg_id_aa64pfr1))
 		init_cpu_ftr_reg(SYS_GMID_EL1, info->reg_gmid);
 
@@ -1347,6 +1362,11 @@ void update_cpu_features(int cpu,
 		cpacr_restore(cpacr);
 	}
 
+	if (id_aa64pfr0_mpam(info->reg_id_aa64pfr0)) {
+		taint |= check_update_ftr_reg(SYS_MPAMIDR_EL1, cpu,
+					info->reg_mpamidr, boot->reg_mpamidr);
+	}
+
 	/*
 	 * The kernel uses the LDGM/STGM instructions and the number of tags
 	 * they read/write depends on the GMID_EL1.BS field. Check that the
@@ -2265,6 +2285,42 @@ cpucap_panic_on_conflict(const struct arm64_cpu_capabilities *cap)
 	return !!(cap->type & ARM64_CPUCAP_PANIC_ON_CONFLICT);
 }
 
+static bool __maybe_unused
+test_has_mpam(const struct arm64_cpu_capabilities *entry, int scope)
+{
+	if (!has_cpuid_feature(entry, scope))
+		return false;
+
+	/* Check firmware actually enabled MPAM on this cpu. */
+	return (read_sysreg_s(SYS_MPAM1_EL1) & MPAM_SYSREG_EN);
+}
+
+static void __maybe_unused
+cpu_enable_mpam(const struct arm64_cpu_capabilities *entry)
+{
+	/*
+	 * Access by the kernel (at EL1) should use the reserved PARTID
+	 * which is configured unrestricted. This avoids priority-inversion
+	 * where latency sensitive tasks have to wait for a task that has
+	 * been throttled to release the lock.
+	 */
+	write_sysreg_s(0, SYS_MPAM1_EL1);
+
+	/* The EL0 system register is not yet per-task, zero that too. */
+	write_sysreg_s(0, SYS_MPAM0_EL1);
+}
+
+static void mpam_extra_caps(void)
+{
+	u64 idr = read_sanitised_ftr_reg(SYS_MPAMIDR_EL1);
+
+	if (!IS_ENABLED(CONFIG_ARM64_MPAM))
+		return;
+
+	if (idr & MPAMIDR_HAS_HCR)
+		__enable_mpam_hcr();
+}
+
 static const struct arm64_cpu_capabilities arm64_features[] = {
 	{
 		.capability = ARM64_ALWAYS_BOOT,
@@ -2735,6 +2791,16 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.matches = has_cpuid_feature,
 		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP)
 	},
+#ifdef CONFIG_ARM64_MPAM
+	{
+		.desc = "Memory Partitioning And Monitoring",
+		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+		.capability = ARM64_MPAM,
+		.matches = test_has_mpam,
+		.cpu_enable = cpu_enable_mpam,
+		ARM64_CPUID_FIELDS(ID_AA64PFR0_EL1, MPAM, 1)
+	},
+#endif
 	{},
 };
 
@@ -3390,6 +3456,7 @@ void __init setup_user_features(void)
 	}
 
 	minsigstksz_setup();
+	mpam_extra_caps();
 }
 
 static int enable_mismatched_32bit_el0(unsigned int cpu)
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index a257da7b56fe..f117faa82ce5 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -463,6 +463,10 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
 	if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0))
 		__cpuinfo_store_cpu_32bit(&info->aarch32);
 
+	if (IS_ENABLED(CONFIG_ARM64_MPAM) &&
+	    id_aa64pfr0_mpam(info->reg_id_aa64pfr0))
+		info->reg_mpamidr = read_cpuid(MPAMIDR_EL1);
+
 	cpuinfo_detect_icache_policy(info);
 }
 
diff --git a/arch/arm64/kernel/mpam.c b/arch/arm64/kernel/mpam.c
new file mode 100644
index 000000000000..a29dc58c2da5
--- /dev/null
+++ b/arch/arm64/kernel/mpam.c
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2021 Arm Ltd. */
+
+#include <asm/mpam.h>
+
+#include <linux/jump_label.h>
+
+DEFINE_STATIC_KEY_FALSE(arm64_mpam_has_hcr);
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index b98c38288a9d..e6f425633d8d 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -56,6 +56,7 @@ HW_DBM
 KVM_HVHE
 KVM_PROTECTED_MODE
 MISMATCHED_CACHE_TYPE
+MPAM
 MTE
 MTE_ASYMM
 SME
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 96cbeeab4eec..6a120f987851 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2536,6 +2536,22 @@ Res0	1
 Field	0	EN
 EndSysreg
 
+Sysreg	MPAMIDR_EL1	3	0	10	4	4
+Res0	63:62
+Field	61	HAS_SDEFLT
+Field	60	HAS_FORCE_NS
+Field	59	SP4
+Field	58	HAS_TIDR
+Field	57	HAS_ALTSP
+Res0	56:40
+Field	39:32	PMG_MAX
+Res0	31:21
+Field	20:18	VPMR_MAX
+Field	17	HAS_HCR
+Res0	16
+Field	15:0	PARTID_MAX
+EndSysreg
+
 Sysreg	LORID_EL1	3	0	10	4	7
 Res0	63:24
 Field	23:16	LD
@@ -2543,6 +2559,22 @@ Res0	15:8
 Field	7:0	LR
 EndSysreg
 
+Sysreg	MPAM1_EL1	3	0	10	5	0
+Res0	63:48
+Field	47:40	PMG_D
+Field	39:32	PMG_I
+Field	31:16	PARTID_D
+Field	15:0	PARTID_I
+EndSysreg
+
+Sysreg	MPAM0_EL1	3	0	10	5	1
+Res0	63:48
+Field	47:40	PMG_D
+Field	39:32	PMG_I
+Field	31:16	PARTID_D
+Field	15:0	PARTID_I
+EndSysreg
+
 Sysreg	ISR_EL1	3	0	12	1	0
 Res0	63:11
 Field	10	IS
-- 
2.39.2



From james.morse at arm.com  Thu Dec  7 07:08:01 2023
From: james.morse at arm.com (James Morse)
Date: Thu,  7 Dec 2023 15:08:01 +0000
Subject: [PATCH v2 1/4] arm64: head.S: Initialise MPAM EL2 registers and disable traps
In-Reply-To: <20231207150804.3425468-1-james.morse@arm.com>
References: <20231207150804.3425468-1-james.morse@arm.com>
Message-ID: <20231207150804.3425468-2-james.morse@arm.com>

Add code to head.S's el2_setup to detect MPAM and disable any EL2 traps.
This register resets to an unknown value, setting it to the default
parititons/pmg before we enable the MMU is the best thing to do.

Kexec/kdump will depend on this if the previous kernel left the CPU
configured with a restrictive configuration.

If linux is booted at the highest implemented exception level el2_setup
will clear the enable bit, disabling MPAM.

This code can't be enabled until a subsequent patch adds the Kconfig
and cpufeature boiler plate.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/el2_setup.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index b7afaa026842..fb4ea2a94e10 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -208,6 +208,21 @@
 	msr	spsr_el2, x0
 .endm
 
+.macro __init_el2_mpam
+#ifdef CONFIG_ARM64_MPAM
+	/* Memory Partitioning And Monitoring: disable EL2 traps */
+	mrs	x1, id_aa64pfr0_el1
+	ubfx	x0, x1, #ID_AA64PFR0_EL1_MPAM_SHIFT, #4
+	cbz	x0, .Lskip_mpam_\@		// skip if no MPAM
+	msr_s	SYS_MPAM2_EL2, xzr		// use the default partition
+						// and disable lower traps
+	mrs_s	x0, SYS_MPAMIDR_EL1
+	tbz	x0, #17, .Lskip_mpam_\@		// skip if no MPAMHCR reg
+	msr_s	SYS_MPAMHCR_EL2, xzr		// clear TRAP_MPAMIDR_EL1 -> EL2
+.Lskip_mpam_\@:
+#endif /* CONFIG_ARM64_MPAM */
+.endm
+
 /**
  * Initialize EL2 registers to sane values. This should be called early on all
  * cores that were booted in EL2. Note that everything gets initialised as
@@ -225,6 +240,7 @@
 	__init_el2_stage2
 	__init_el2_gicv3
 	__init_el2_hstr
+	__init_el2_mpam
 	__init_el2_nvhe_idregs
 	__init_el2_cptr
 	__init_el2_fgt
-- 
2.39.2



From james.morse at arm.com  Thu Dec  7 07:08:03 2023
From: james.morse at arm.com (James Morse)
Date: Thu,  7 Dec 2023 15:08:03 +0000
Subject: [PATCH v2 3/4] KVM: arm64: Fix missing traps of guest accesses to the MPAM registers
In-Reply-To: <20231207150804.3425468-1-james.morse@arm.com>
References: <20231207150804.3425468-1-james.morse@arm.com>
Message-ID: <20231207150804.3425468-4-james.morse@arm.com>

commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature bits in
ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to guests,
but didn't add trap handling.

If you are unlucky, this results in an MPAM aware guest being delivered
an undef during boot. The host prints:
| kvm [97]: Unsupported guest sys_reg access at: ffff800080024c64 [00000005]
| { Op0( 3), Op1( 0), CRn(10), CRm( 5), Op2( 0), func_read },

Which results in:
| Internal error: Oops - Undefined instruction: 0000000002000000 [#1] PREEMPT SMP
| Modules linked in:
| CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.0-rc7-00559-gd89c186d50b2 #14616
| Hardware name: linux,dummy-virt (DT)
| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : test_has_mpam+0x18/0x30
| lr : test_has_mpam+0x10/0x30
| sp : ffff80008000bd90
...
| Call trace:
|  test_has_mpam+0x18/0x30
|  update_cpu_capabilities+0x7c/0x11c
|  setup_cpu_features+0x14/0xd8
|  smp_cpus_done+0x24/0xb8
|  smp_init+0x7c/0x8c
|  kernel_init_freeable+0xf8/0x280
|  kernel_init+0x24/0x1e0
|  ret_from_fork+0x10/0x20
| Code: 910003fd 97ffffde 72001c00 54000080 (d538a500)
| ---[ end trace 0000000000000000 ]---
| Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
| ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

Add the support to enable the traps, and handle the three guest accessible
registers as RAZ/WI. This allows guests to keep the invariant id-register
value, while advertising that MPAM isn't really supported.

With MPAM v1.0 we can trap the MPAMIDR_EL1 register only if
ARM64_HAS_MPAM_HCR, with v1.1 an additional MPAM2_EL2.TIDR bit traps
MPAMIDR_EL1 on platforms that don't have MPAMHCR_EL2. Enable one of
these if either is supported. If neither is supported, the guest can
discover that the CPU has MPAM support, and how many PARTID etc the
host has ... but it can't influence anything, so its harmless.

Full support for the feature would only expose MPAM to the guest
if a psuedo-device has been created to describe the virt->phys partid
mapping the VMM expects. This will depend on ARM64_HAS_MPAM_HCR.

Fixes: 011e5f5bf529 ("arm64/cpufeature: Add remaining feature bits in ID_AA64PFR0 register")
CC: Anshuman Khandual <anshuman.khandual at arm.com>
Link: https://lore.kernel.org/linux-arm-kernel/20200925160102.118858-1-james.morse at arm.com/
Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/kvm_arm.h        |  1 +
 arch/arm64/include/asm/mpam.h           |  4 ++--
 arch/arm64/kernel/image-vars.h          |  5 ++++
 arch/arm64/kvm/hyp/include/hyp/switch.h | 32 +++++++++++++++++++++++++
 arch/arm64/kvm/sys_regs.c               | 20 ++++++++++++++++
 5 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index b85f46a73e21..87aa442c2622 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -106,6 +106,7 @@
 	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | \
 	 (cpus_have_final_cap(ARM64_HAS_MOPS) ? (HCRX_EL2_MSCEn | HCRX_EL2_MCE2) : 0))
 #define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En)
+#define MPAMHCR_HOST_FLAGS	0
 
 /* TCR_EL2 Registers bits */
 #define TCR_EL2_RES1		((1U << 31) | (1 << 23))
diff --git a/arch/arm64/include/asm/mpam.h b/arch/arm64/include/asm/mpam.h
index 82d4f6008aeb..dd11e97d8317 100644
--- a/arch/arm64/include/asm/mpam.h
+++ b/arch/arm64/include/asm/mpam.h
@@ -50,7 +50,7 @@
 DECLARE_STATIC_KEY_FALSE(arm64_mpam_has_hcr);
 
 /* check whether all CPUs have MPAM support */
-static inline bool mpam_cpus_have_feature(void)
+static __always_inline bool mpam_cpus_have_feature(void)
 {
 	if (IS_ENABLED(CONFIG_ARM64_MPAM))
 		return cpus_have_final_cap(ARM64_MPAM);
@@ -58,7 +58,7 @@ static inline bool mpam_cpus_have_feature(void)
 }
 
 /* check whether all CPUs have MPAM virtualisation support */
-static inline bool mpam_cpus_have_mpam_hcr(void)
+static __always_inline bool mpam_cpus_have_mpam_hcr(void)
 {
 	if (IS_ENABLED(CONFIG_ARM64_MPAM))
 		return static_branch_unlikely(&arm64_mpam_has_hcr);
diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
index 5e4dc72ab1bd..b30046aaa171 100644
--- a/arch/arm64/kernel/image-vars.h
+++ b/arch/arm64/kernel/image-vars.h
@@ -66,6 +66,11 @@ KVM_NVHE_ALIAS(nvhe_hyp_panic_handler);
 /* Vectors installed by hyp-init on reset HVC. */
 KVM_NVHE_ALIAS(__hyp_stub_vectors);
 
+/* Additional static keys for cpufeatures */
+#ifdef CONFIG_ARM64_MPAM
+KVM_NVHE_ALIAS(arm64_mpam_has_hcr);
+#endif
+
 /* Static keys which are set if a vGIC trap should be handled in hyp. */
 KVM_NVHE_ALIAS(vgic_v2_cpuif_trap);
 KVM_NVHE_ALIAS(vgic_v3_cpuif_trap);
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index f99d8af0b9af..277373871b44 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -27,6 +27,7 @@
 #include <asm/kvm_hyp.h>
 #include <asm/kvm_mmu.h>
 #include <asm/kvm_nested.h>
+#include <asm/mpam.h>
 #include <asm/fpsimd.h>
 #include <asm/debug-monitors.h>
 #include <asm/processor.h>
@@ -173,6 +174,35 @@ static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 	write_sysreg_s(ctxt_sys_reg(hctxt, HDFGWTR_EL2), SYS_HDFGWTR_EL2);
 }
 
+static inline void  __activate_traps_mpam(struct kvm_vcpu *vcpu)
+{
+	u64 r = MPAM_SYSREG_TRAP_MPAM0_EL1 | MPAM_SYSREG_TRAP_MPAM1_EL1;
+
+	if (!mpam_cpus_have_feature())
+		return;
+
+	/* trap guest access to MPAMIDR_EL1 */
+	if (mpam_cpus_have_mpam_hcr()) {
+		write_sysreg_s(MPAMHCR_TRAP_MPAMIDR, SYS_MPAMHCR_EL2);
+	} else {
+		/* From v1.1 TIDR can trap MPAMIDR, set it unconditionally */
+		r |= MPAM_SYSREG_TRAP_IDR;
+	}
+
+	write_sysreg_s(r, SYS_MPAM2_EL2);
+}
+
+static inline void __deactivate_traps_mpam(void)
+{
+	if (!mpam_cpus_have_feature())
+		return;
+
+	write_sysreg_s(0, SYS_MPAM2_EL2);
+
+	if (mpam_cpus_have_mpam_hcr())
+		write_sysreg_s(MPAMHCR_HOST_FLAGS, SYS_MPAMHCR_EL2);
+}
+
 static inline void __activate_traps_common(struct kvm_vcpu *vcpu)
 {
 	/* Trap on AArch32 cp15 c15 (impdef sysregs) accesses (EL1 or EL0) */
@@ -213,6 +243,7 @@ static inline void __activate_traps_common(struct kvm_vcpu *vcpu)
 	}
 
 	__activate_traps_hfgxtr(vcpu);
+	__activate_traps_mpam(vcpu);
 }
 
 static inline void __deactivate_traps_common(struct kvm_vcpu *vcpu)
@@ -232,6 +263,7 @@ static inline void __deactivate_traps_common(struct kvm_vcpu *vcpu)
 		write_sysreg_s(HCRX_HOST_FLAGS, SYS_HCRX_EL2);
 
 	__deactivate_traps_hfgxtr(vcpu);
+	__deactivate_traps_mpam();
 }
 
 static inline void ___activate_traps(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4735e1b37fb3..15fb9f54e308 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -411,6 +411,23 @@ static bool trap_oslar_el1(struct kvm_vcpu *vcpu,
 	return true;
 }
 
+static bool workaround_bad_mpam_abi(struct kvm_vcpu *vcpu,
+				    struct sys_reg_params *p,
+				    const struct sys_reg_desc *r)
+{
+	/*
+	 * The ID register can't be removed without breaking migration,
+	 * but MPAMIDR_EL1 can advertise all-zeroes, indicating there are zero
+	 * PARTID/PMG supported by the CPU, allowing the other two trapped
+	 * registers (MPAM1_EL1 and MPAM0_EL1) to be treated as RAZ/WI.
+	 * Emulating MPAM1_EL1 as RAZ/WI means the guest sees the MPAMEN bit
+	 * as clear, and realises MPAM isn't usable on this CPU.
+	 */
+	p->regval = 0;
+
+	return true;
+}
+
 static bool trap_oslsr_el1(struct kvm_vcpu *vcpu,
 			   struct sys_reg_params *p,
 			   const struct sys_reg_desc *r)
@@ -2275,8 +2292,11 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_LOREA_EL1), trap_loregion },
 	{ SYS_DESC(SYS_LORN_EL1), trap_loregion },
 	{ SYS_DESC(SYS_LORC_EL1), trap_loregion },
+	{ SYS_DESC(SYS_MPAMIDR_EL1), workaround_bad_mpam_abi },
 	{ SYS_DESC(SYS_LORID_EL1), trap_loregion },
 
+	{ SYS_DESC(SYS_MPAM1_EL1), workaround_bad_mpam_abi },
+	{ SYS_DESC(SYS_MPAM0_EL1), workaround_bad_mpam_abi },
 	{ SYS_DESC(SYS_VBAR_EL1), access_rw, reset_val, VBAR_EL1, 0 },
 	{ SYS_DESC(SYS_DISR_EL1), NULL, reset_val, DISR_EL1, 0 },
 
-- 
2.39.2



From james.morse at arm.com  Thu Dec  7 07:08:04 2023
From: james.morse at arm.com (James Morse)
Date: Thu,  7 Dec 2023 15:08:04 +0000
Subject: [PATCH v2 4/4] KVM: arm64: Disable MPAM visibility by default, and handle traps
In-Reply-To: <20231207150804.3425468-1-james.morse@arm.com>
References: <20231207150804.3425468-1-james.morse@arm.com>
Message-ID: <20231207150804.3425468-5-james.morse@arm.com>

Currently KVM only allows certain writeable ID registers to be
downgraded from their reset value.

commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature bits in
ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to guests,
but didn't add trap handling. A previous patch supplied the missing trap
handling.

Existing VMs that have the MPAM field of AA64PFR0_EL1 need to be
migratable, but there is little point enabling the MPAM CPU interface
on new VMs until there is something a guest can do with it.

Clear the MPAM field from the guest's AA64PFR0_EL1 by default, but
allow user-space to set it again if the host supports MPAM. Add a
helper to return the maximum permitted value for an ID register.
For most this is the reset value. To allow the MPAM field to be
written as supported, check if the host sanitised value is '1'
and allow an upgrade from the reset value.

Finally, change the trap handling to inject an undef if MPAM was
not advertised to the guest.

Full support will depend on an psuedo-device being created that
describes the virt->phys PARTID mapping the VMM expects. Migration
would be expected to fail if this psuedo-device can't be created
on the remote end. This ID bit isn't needed to block migration.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/kvm/sys_regs.c | 75 +++++++++++++++++++++++++++++++--------
 1 file changed, 60 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 15fb9f54e308..055a72643aed 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -411,21 +411,29 @@ static bool trap_oslar_el1(struct kvm_vcpu *vcpu,
 	return true;
 }
 
-static bool workaround_bad_mpam_abi(struct kvm_vcpu *vcpu,
-				    struct sys_reg_params *p,
-				    const struct sys_reg_desc *r)
+static bool trap_mpam(struct kvm_vcpu *vcpu,
+		      struct sys_reg_params *p,
+		      const struct sys_reg_desc *r)
 {
+	u64 aa64pfr0_el1 = IDREG(vcpu->kvm, SYS_ID_AA64PFR0_EL1);
+
 	/*
-	 * The ID register can't be removed without breaking migration,
-	 * but MPAMIDR_EL1 can advertise all-zeroes, indicating there are zero
-	 * PARTID/PMG supported by the CPU, allowing the other two trapped
-	 * registers (MPAM1_EL1 and MPAM0_EL1) to be treated as RAZ/WI.
+	 * What did we expose to the guest?
+	 * Earlier guests may have seen the ID bits, which can't be removed
+	 * without breaking migration, but MPAMIDR_EL1 can advertise all-zeroes,
+	 * indicating there are zero PARTID/PMG supported by the CPU, allowing
+	 * the other two trapped registers (MPAM1_EL1 and MPAM0_EL1) to be
+	 * treated as RAZ/WI.
 	 * Emulating MPAM1_EL1 as RAZ/WI means the guest sees the MPAMEN bit
 	 * as clear, and realises MPAM isn't usable on this CPU.
 	 */
-	p->regval = 0;
+	if (FIELD_GET(ID_AA64PFR0_EL1_MPAM_MASK, aa64pfr0_el1)) {
+		p->regval = 0;
+		return true;
+	}
 
-	return true;
+	kvm_inject_undefined(vcpu);
+	return false;
 }
 
 static bool trap_oslsr_el1(struct kvm_vcpu *vcpu,
@@ -1326,6 +1334,36 @@ static s64 kvm_arm64_ftr_safe_value(u32 id, const struct arm64_ftr_bits *ftrp,
 	return arm64_ftr_safe_value(&kvm_ftr, new, cur);
 }
 
+static u64 kvm_arm64_ftr_max(struct kvm_vcpu *vcpu,
+			     const struct sys_reg_desc *rd)
+{
+	u64 pfr0, val = rd->reset(vcpu, rd);
+	u32 field, id = reg_to_encoding(rd);
+
+	/*
+	 * Some values may reset to a lower value than can be supported,
+	 * get the maximum feature value.
+	 */
+	switch (id) {
+	case SYS_ID_AA64PFR0_EL1:
+		pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
+
+		/*
+		 * MPAM resets to 0, but migration of MPAM=1 guests is needed.
+		 * See trap_mpam() for more.
+		 */
+		field = cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_EL1_MPAM_SHIFT);
+		if (field == ID_AA64PFR0_EL1_MPAM_1) {
+			val &= ~ID_AA64PFR0_EL1_MPAM_MASK;
+			val |= FIELD_PREP(ID_AA64PFR0_EL1_MPAM_MASK, ID_AA64PFR0_EL1_MPAM_1);
+		}
+
+		break;
+	}
+
+	return val;
+}
+
 /*
  * arm64_check_features() - Check if a feature register value constitutes
  * a subset of features indicated by the idreg's KVM sanitised limit.
@@ -1346,8 +1384,7 @@ static int arm64_check_features(struct kvm_vcpu *vcpu,
 	const struct arm64_ftr_bits *ftrp = NULL;
 	u32 id = reg_to_encoding(rd);
 	u64 writable_mask = rd->val;
-	u64 limit = rd->reset(vcpu, rd);
-	u64 mask = 0;
+	u64 limit, mask = 0;
 
 	/*
 	 * Hidden and unallocated ID registers may not have a corresponding
@@ -1361,6 +1398,7 @@ static int arm64_check_features(struct kvm_vcpu *vcpu,
 	if (!ftr_reg)
 		return -EINVAL;
 
+	limit = kvm_arm64_ftr_max(vcpu, rd);
 	ftrp = ftr_reg->ftr_bits;
 
 	for (; ftrp && ftrp->width; ftrp++) {
@@ -1570,6 +1608,14 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
 
 	val &= ~ID_AA64PFR0_EL1_AMU_MASK;
 
+	/*
+	 * MPAM is disabled by default as KVM also needs a set of PARTID to
+	 * program the MPAMVPMx_EL2 PARTID remapping registers with. But some
+	 * older kernels let the guest see the ID bit. Turning it on causes
+	 * the registers to be emulated as RAZ/WI. See trap_mpam() for more.
+	 */
+	val &= ~ID_AA64PFR0_EL1_MPAM_MASK;
+
 	return val;
 }
 
@@ -2149,7 +2195,6 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  .set_user = set_id_reg,
 	  .reset = read_sanitised_id_aa64pfr0_el1,
 	  .val = ~(ID_AA64PFR0_EL1_AMU |
-		   ID_AA64PFR0_EL1_MPAM |
 		   ID_AA64PFR0_EL1_SVE |
 		   ID_AA64PFR0_EL1_RAS |
 		   ID_AA64PFR0_EL1_GIC |
@@ -2292,11 +2337,11 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_LOREA_EL1), trap_loregion },
 	{ SYS_DESC(SYS_LORN_EL1), trap_loregion },
 	{ SYS_DESC(SYS_LORC_EL1), trap_loregion },
-	{ SYS_DESC(SYS_MPAMIDR_EL1), workaround_bad_mpam_abi },
+	{ SYS_DESC(SYS_MPAMIDR_EL1), trap_mpam },
 	{ SYS_DESC(SYS_LORID_EL1), trap_loregion },
 
-	{ SYS_DESC(SYS_MPAM1_EL1), workaround_bad_mpam_abi },
-	{ SYS_DESC(SYS_MPAM0_EL1), workaround_bad_mpam_abi },
+	{ SYS_DESC(SYS_MPAM1_EL1), trap_mpam },
+	{ SYS_DESC(SYS_MPAM0_EL1), trap_mpam },
 	{ SYS_DESC(SYS_VBAR_EL1), access_rw, reset_val, VBAR_EL1, 0 },
 	{ SYS_DESC(SYS_DISR_EL1), NULL, reset_val, DISR_EL1, 0 },
 
-- 
2.39.2



From catalin.marinas at arm.com  Thu Dec  7 07:10:58 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 7 Dec 2023 15:10:58 +0000
Subject: [PATCH v3 09/25] arm64: define VM_PKEY_BIT* for arm64
In-Reply-To: <20231124163510.1835740-10-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-10-joey.gouly@arm.com>
Message-ID: <ZXHggjY32Ypr5euK@arm.com>

On Fri, Nov 24, 2023 at 04:34:54PM +0000, Joey Gouly wrote:
>  arch/arm64/include/asm/mman.h   |  8 +++++++-
>  arch/arm64/include/asm/page.h   | 10 ++++++++++
>  arch/arm64/mm/mmap.c            |  9 +++++++++
>  arch/powerpc/include/asm/page.h | 11 +++++++++++
>  arch/x86/include/asm/page.h     | 10 ++++++++++
>  fs/proc/task_mmu.c              |  2 ++
>  include/linux/mm.h              | 13 -------------
>  7 files changed, 49 insertions(+), 14 deletions(-)

It might be worth splitting out the powerpc/x86/generic parts into a
separate patch.

> diff --git a/arch/arm64/include/asm/mman.h b/arch/arm64/include/asm/mman.h
> index 5966ee4a6154..ecb2d18dc4d7 100644
> --- a/arch/arm64/include/asm/mman.h
> +++ b/arch/arm64/include/asm/mman.h
> @@ -7,7 +7,7 @@
>  #include <uapi/asm/mman.h>
>  
>  static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot,
> -	unsigned long pkey __always_unused)
> +	unsigned long pkey)
>  {
>  	unsigned long ret = 0;
>  
> @@ -17,6 +17,12 @@ static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot,
>  	if (system_supports_mte() && (prot & PROT_MTE))
>  		ret |= VM_MTE;
>  
> +#if defined(CONFIG_ARCH_HAS_PKEYS)
> +	ret |= pkey & 0x1 ? VM_PKEY_BIT0 : 0;
> +	ret |= pkey & 0x2 ? VM_PKEY_BIT1 : 0;
> +	ret |= pkey & 0x4 ? VM_PKEY_BIT2 : 0;
> +#endif

Is there anywhere that rejects pkey & 8 on arm64? Because with 128-bit
PTEs, if we ever support them, we can have 4-bit pkeys.

>  #define arch_calc_vm_prot_bits(prot, pkey) arch_calc_vm_prot_bits(prot, pkey)
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 2312e6ee595f..aabfda2516d2 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -49,6 +49,16 @@ int pfn_is_map_memory(unsigned long pfn);
>  
>  #define VM_DATA_DEFAULT_FLAGS	(VM_DATA_FLAGS_TSK_EXEC | VM_MTE_ALLOWED)
>  
> +#if defined(CONFIG_ARCH_HAS_PKEYS)
> +/* A protection key is a 3-bit value */
> +# define VM_PKEY_SHIFT	VM_HIGH_ARCH_BIT_2
> +# define VM_PKEY_BIT0	VM_HIGH_ARCH_2
> +# define VM_PKEY_BIT1	VM_HIGH_ARCH_3
> +# define VM_PKEY_BIT2	VM_HIGH_ARCH_4
> +# define VM_PKEY_BIT3	0
> +# define VM_PKEY_BIT4	0
> +#endif

I think we should start from VM_HIGH_ARCH_BIT_0 and just move the
VM_MTE, VM_MTE_ALLOWED to VM_HIGH_ARCH_BIT_{4,5}.

> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index e5fcc79b5bfb..a5e75ec333ad 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -330,6 +330,17 @@ static inline unsigned long kaslr_offset(void)
>  }
>  
>  #include <asm-generic/memory_model.h>
> +
> +#if defined(CONFIG_ARCH_HAS_PKEYS)
> +# define VM_PKEY_SHIFT	VM_HIGH_ARCH_BIT_0
> +/* A protection key is a 5-bit value */
> +# define VM_PKEY_BIT0	VM_HIGH_ARCH_0
> +# define VM_PKEY_BIT1	VM_HIGH_ARCH_1
> +# define VM_PKEY_BIT2	VM_HIGH_ARCH_2
> +# define VM_PKEY_BIT3	VM_HIGH_ARCH_3
> +# define VM_PKEY_BIT4	VM_HIGH_ARCH_4
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
> +
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* _ASM_POWERPC_PAGE_H */
> diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
> index d18e5c332cb9..b770db1a21e7 100644
> --- a/arch/x86/include/asm/page.h
> +++ b/arch/x86/include/asm/page.h
> @@ -87,5 +87,15 @@ static __always_inline u64 __is_canonical_address(u64 vaddr, u8 vaddr_bits)
>  
>  #define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
>  
> +#if defined(CONFIG_ARCH_HAS_PKEYS)
> +# define VM_PKEY_SHIFT	VM_HIGH_ARCH_BIT_0
> +/* A protection key is a 4-bit value */
> +# define VM_PKEY_BIT0	VM_HIGH_ARCH_0
> +# define VM_PKEY_BIT1	VM_HIGH_ARCH_1
> +# define VM_PKEY_BIT2	VM_HIGH_ARCH_2
> +# define VM_PKEY_BIT3	VM_HIGH_ARCH_3
> +# define VM_PKEY_BIT4	0
> +#endif /* CONFIG_ARCH_HAS_PKEYS */

Rather than moving these to arch code, we could instead keep the generic
definitions with some additional CONFIG_ARCH_HAS_PKEYS_{3,4,5}BIT
selected from the arch code.

-- 
Catalin


From catalin.marinas at arm.com  Thu Dec  7 07:11:55 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 7 Dec 2023 15:11:55 +0000
Subject: [PATCH v3 10/25] arm64: mask out POIndex when modifying a PTE
In-Reply-To: <20231124163510.1835740-11-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-11-joey.gouly@arm.com>
Message-ID: <ZXHgu0rJb5u9sz3T@arm.com>

On Fri, Nov 24, 2023 at 04:34:55PM +0000, Joey Gouly wrote:
> When a PTE is modified, the POIndex must be masked off so that it can be modified.
> 
> Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>


From ryan.roberts at arm.com  Thu Dec  7 07:12:07 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 7 Dec 2023 15:12:07 +0000
Subject: [PATCH v8 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <369ec8d3-ef6a-4a4e-84e2-2c91b8293929@redhat.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <20231204102027.57185-5-ryan.roberts@arm.com>
 <71040a8c-4ea1-4f21-8ac8-65f7c25c217e@redhat.com>
 <f2896d7f-183b-48fb-a3aa-d21bf2257043@arm.com>
 <ca649aad-7b76-4c6d-b513-26b3d58f8e68@redhat.com>
 <126c3b71-1acc-4851-9986-4228cb8a8660@arm.com>
 <94806b4f-2370-4999-9586-2c936955cb87@redhat.com>
 <3d49bcbf-1f9b-48e8-a91a-ede0762b795c@arm.com>
 <369ec8d3-ef6a-4a4e-84e2-2c91b8293929@redhat.com>
Message-ID: <787eb131-759c-4cd3-a2b7-39caf818cffc@arm.com>

On 07/12/2023 15:01, David Hildenbrand wrote:
> On 07.12.23 15:45, Ryan Roberts wrote:
>> On 07/12/2023 13:28, David Hildenbrand wrote:
>>>>>
>>>>> Right, but you know from the first loop which order is applicable (and will be
>>>>> fed to the second loop) and could just pte_unmap(pte) + tryalloc. If that
>>>>> fails,
>>>>> remap and try with the next orders.
>>>>
>>>> You mean something like this?
>>>>
>>>> ?????pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>>> ?????if (!pte)
>>>> ???????? return ERR_PTR(-EAGAIN);
>>>>
>>>> ?????order = highest_order(orders);
>>>> ?????while (orders) {
>>>> ???????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>>> ???????? if (!pte_range_none(pte + pte_index(addr), 1 << order)) {
>>>> ???????????? order = next_order(&orders, order);
>>>> ???????????? continue;
>>>> ???????? }
>>>>
>>>> ???????? pte_unmap(pte);
>>>> ??????? ???????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>>> ???????? if (folio) {
>>>> ???????????? clear_huge_page(&folio->page, vmf->address, 1 << order);
>>>> ???????????? return folio;
>>>> ???????? }
>>>>
>>>> ???????? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>>> ???????? if (!pte)
>>>> ???????????? return ERR_PTR(-EAGAIN);
>>>>
>>>> ???????? order = next_order(&orders, order);
>>>> ?????}
>>>>
>>>> ?????pte_unmap(pte);
>>>>
>>>> I don't really like that because if high order folio allocations fail, then you
>>>> are calling pte_range_none() again for the next lower order; once that check
>>>> has
>>>> succeeded for an order it shouldn't be required for any lower orders. In this
>>>> case you also have lots of pte map/unmap.
>>>
>>> I see what you mean.
>>>
>>>>
>>>> The original version feels more efficient to me.
>>> Yes it is. Adding in some comments might help, like
>>>
>>> /*
>>> ??* Find the largest order where the aligned range is completely prot_none().
>>> Note
>>> ??* that all remaining orders will be completely prot_none().
>>> ??*/
>>> ...
>>>
>>> /* Try allocating the largest of the remaining orders. */
>>
>> OK added.
>>
>>>
>>>>
>>>>>
>>>>> That would make the code certainly easier to understand. That "orders"
>>>>> magic of
>>>>> constructing, filtering, walking is confusing :)
>>>>>
>>>>>
>>>>> I might find some time today to see if there is an easy way to cleanup all
>>>>> what
>>>>> I spelled out above. It really is a mess. But likely that cleanup could be
>>>>> deferred (but you're touching it, so ... :) ).
>>>>
>>>> I'm going to ignore the last 5 words. I heard the "that cleanup could be
>>>> deferred" part loud and clear though :)
>>>
>>> :)
>>>
>>> If we could stop passing orders into thp_vma_allowable_orders(), that would
>>> probably
>>> be the biggest win. It's just all a confusing mess.
>>
>>
>>
>> I tried an approach like you suggested in the other thread originally, but I
>> struggled to define exactly what "thp_vma_configured_orders()" should mean;
>> Ideally, I just want "all the THP orders that are currently enabled for this
>> VMA+flags". But some callers want to enforce_sysfs and others don't, so you
>> probably have to at least pass that flag. Then you have DAX which explicitly
> 
> Yes, the flags would still be passed. It's kind of the "context".
> 
>> ignores enforce_sysfs, but only in a page fault. And shmem, which ignores
>> enforce_sysfs, but only outside of a page fault. So it quickly becomes pretty
>> complex. It is basically thp_vma_allowable_orders() as currently defined.
> 
> Yeah, but moving the "can we actually fit a THP in there" check out of the picture.
> 
>>
>> If this could be a simple function then it could be inline and as you say, we
>> can do the masking in the caller and exit early for the order-0 case. But it is
>> very complex (at least if you want to retain the equivalent logic to what
>> thp_vma_allowable_orders() has) so I'm not sure how to do the order-0 early exit
>> without passing in the orders bitfield. And we are unlikely to exit early
>> because PMD-sized THP is likely enabled and because we didn't pass in a orders
>> bitfield, that wasn't filtered out.
>>
>> In short, I can't see a solution that's better than the one I have. But if you
>> have something in mind, if you can spell it out, then I'll have a go at tidying
>> it up and integrating it into the series. Otherwise I really would prefer to
>> leave it for a separate series.
> 
> I'm playing with some cleanups, but they can all be built on top if they
> materialize.

OK, I'm going to post a v9 then. And cross my fingers and hope that's the final
version.



From maz at kernel.org  Thu Dec  7 07:11:58 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  7 Dec 2023 15:11:58 +0000
Subject: [PATCH 2/5] KVM: arm64: vgic: Add a non-locking primitive for kvm_vgic_vcpu_destroy()
In-Reply-To: <20231207151201.3028710-1-maz@kernel.org>
References: <20231207151201.3028710-1-maz@kernel.org>
Message-ID: <20231207151201.3028710-3-maz@kernel.org>

As we are going to need to call into kvm_vgic_vcpu_destroy() without
prior holding of the slots_lock, introduce __kvm_vgic_vcpu_destroy()
as a non-locking primitive of kvm_vgic_vcpu_destroy().

Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/vgic/vgic-init.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index ad7e86879eb9..a86f300321a7 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -368,7 +368,7 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
 		vgic_v4_teardown(kvm);
 }
 
-void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
+static void __kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
 {
 	struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
 
@@ -382,6 +382,15 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
 	vgic_cpu->rd_iodev.base_addr = VGIC_ADDR_UNDEF;
 }
 
+void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
+{
+	struct kvm *kvm = vcpu->kvm;
+
+	mutex_lock(&kvm->slots_lock);
+	__kvm_vgic_vcpu_destroy(vcpu);
+	mutex_unlock(&kvm->slots_lock);
+}
+
 void kvm_vgic_destroy(struct kvm *kvm)
 {
 	struct kvm_vcpu *vcpu;
@@ -392,7 +401,7 @@ void kvm_vgic_destroy(struct kvm *kvm)
 	vgic_debug_destroy(kvm);
 
 	kvm_for_each_vcpu(i, vcpu, kvm)
-		kvm_vgic_vcpu_destroy(vcpu);
+		__kvm_vgic_vcpu_destroy(vcpu);
 
 	mutex_lock(&kvm->arch.config_lock);
 
-- 
2.39.2



From maz at kernel.org  Thu Dec  7 07:12:01 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  7 Dec 2023 15:12:01 +0000
Subject: [PATCH 5/5] KVM: Convert comment into an assertion in kvm_io_bus_register_dev()
In-Reply-To: <20231207151201.3028710-1-maz@kernel.org>
References: <20231207151201.3028710-1-maz@kernel.org>
Message-ID: <20231207151201.3028710-6-maz@kernel.org>

Instead of having a comment indicating the need to hold slots_lock
when calling kvm_io_bus_register_dev(), make it explicit with
a lockdep assertion.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 virt/kvm/kvm_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 486800a7024b..278d31ae45d8 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -5545,7 +5545,6 @@ int kvm_io_bus_read(struct kvm_vcpu *vcpu, enum kvm_bus bus_idx, gpa_t addr,
 	return r < 0 ? r : 0;
 }
 
-/* Caller must hold slots_lock. */
 int kvm_io_bus_register_dev(struct kvm *kvm, enum kvm_bus bus_idx, gpa_t addr,
 			    int len, struct kvm_io_device *dev)
 {
@@ -5553,6 +5552,8 @@ int kvm_io_bus_register_dev(struct kvm *kvm, enum kvm_bus bus_idx, gpa_t addr,
 	struct kvm_io_bus *new_bus, *bus;
 	struct kvm_io_range range;
 
+	lockdep_assert_held(&kvm->slots_lock);
+
 	bus = kvm_get_bus(kvm, bus_idx);
 	if (!bus)
 		return -ENOMEM;
-- 
2.39.2



From maz at kernel.org  Thu Dec  7 07:11:59 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  7 Dec 2023 15:11:59 +0000
Subject: [PATCH 3/5] KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy
In-Reply-To: <20231207151201.3028710-1-maz@kernel.org>
References: <20231207151201.3028710-1-maz@kernel.org>
Message-ID: <20231207151201.3028710-4-maz@kernel.org>

When failing to create a vcpu because (for example) it has a
duplicate vcpu_id, we destroy the vcpu. Amusingly, this leaves
the redistributor registered with the KVM_MMIO bus.

This is no good, and we should properly clean the mess. Force
a teardown of the vgic vcpu interface, including the RD device
before returning to the caller.

Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/arm.c               | 2 +-
 arch/arm64/kvm/vgic/vgic-init.c    | 5 ++++-
 arch/arm64/kvm/vgic/vgic-mmio-v3.c | 2 +-
 arch/arm64/kvm/vgic/vgic.h         | 1 +
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index e5f75f1f1085..4796104c4471 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -410,7 +410,7 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
 	kvm_mmu_free_memory_cache(&vcpu->arch.mmu_page_cache);
 	kvm_timer_vcpu_terminate(vcpu);
 	kvm_pmu_vcpu_destroy(vcpu);
-
+	kvm_vgic_vcpu_destroy(vcpu);
 	kvm_arm_vcpu_destroy(vcpu);
 }
 
diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index a86f300321a7..e949e1d0fd9f 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -379,7 +379,10 @@ static void __kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
 	vgic_flush_pending_lpis(vcpu);
 
 	INIT_LIST_HEAD(&vgic_cpu->ap_list_head);
-	vgic_cpu->rd_iodev.base_addr = VGIC_ADDR_UNDEF;
+	if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) {
+		vgic_unregister_redist_iodev(vcpu);
+		vgic_cpu->rd_iodev.base_addr = VGIC_ADDR_UNDEF;
+	}
 }
 
 void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 89117ba2528a..0f039d46d4fc 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -820,7 +820,7 @@ int vgic_register_redist_iodev(struct kvm_vcpu *vcpu)
 	return ret;
 }
 
-static void vgic_unregister_redist_iodev(struct kvm_vcpu *vcpu)
+void vgic_unregister_redist_iodev(struct kvm_vcpu *vcpu)
 {
 	struct vgic_io_device *rd_dev = &vcpu->arch.vgic_cpu.rd_iodev;
 
diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
index 0ab09b0d4440..8d134569d0a1 100644
--- a/arch/arm64/kvm/vgic/vgic.h
+++ b/arch/arm64/kvm/vgic/vgic.h
@@ -241,6 +241,7 @@ int vgic_v3_lpi_sync_pending_status(struct kvm *kvm, struct vgic_irq *irq);
 int vgic_v3_save_pending_tables(struct kvm *kvm);
 int vgic_v3_set_redist_base(struct kvm *kvm, u32 index, u64 addr, u32 count);
 int vgic_register_redist_iodev(struct kvm_vcpu *vcpu);
+void vgic_unregister_redist_iodev(struct kvm_vcpu *vcpu);
 bool vgic_v3_check_base(struct kvm *kvm);
 
 void vgic_v3_load(struct kvm_vcpu *vcpu);
-- 
2.39.2



From maz at kernel.org  Thu Dec  7 07:11:57 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  7 Dec 2023 15:11:57 +0000
Subject: [PATCH 1/5] KVM: arm64: vgic: Simplify kvm_vgic_destroy()
In-Reply-To: <20231207151201.3028710-1-maz@kernel.org>
References: <20231207151201.3028710-1-maz@kernel.org>
Message-ID: <20231207151201.3028710-2-maz@kernel.org>

When destroying a vgic, we have rather cumbersome rules about
when slots_lock and config_lock are held, resulting in fun
buglets.

The first port of call is to simplify kvm_vgic_map_resources()
so that there is only one call to kvm_vgic_destroy() instead of
two, with the second only holding half of the locks.

For that, we kill the non-locking primitive and move the call
outside of the locking altogether. This doesn't change anything
(we re-acquire the locks and teardown the whole vgic), and
simplifies the code significantly.

Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/vgic/vgic-init.c | 29 ++++++++++++++---------------
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index c8c3cb812783..ad7e86879eb9 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -382,26 +382,24 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
 	vgic_cpu->rd_iodev.base_addr = VGIC_ADDR_UNDEF;
 }
 
-static void __kvm_vgic_destroy(struct kvm *kvm)
+void kvm_vgic_destroy(struct kvm *kvm)
 {
 	struct kvm_vcpu *vcpu;
 	unsigned long i;
 
-	lockdep_assert_held(&kvm->arch.config_lock);
+	mutex_lock(&kvm->slots_lock);
 
 	vgic_debug_destroy(kvm);
 
 	kvm_for_each_vcpu(i, vcpu, kvm)
 		kvm_vgic_vcpu_destroy(vcpu);
 
+	mutex_lock(&kvm->arch.config_lock);
+
 	kvm_vgic_dist_destroy(kvm);
-}
 
-void kvm_vgic_destroy(struct kvm *kvm)
-{
-	mutex_lock(&kvm->arch.config_lock);
-	__kvm_vgic_destroy(kvm);
 	mutex_unlock(&kvm->arch.config_lock);
+	mutex_unlock(&kvm->slots_lock);
 }
 
 /**
@@ -469,25 +467,26 @@ int kvm_vgic_map_resources(struct kvm *kvm)
 		type = VGIC_V3;
 	}
 
-	if (ret) {
-		__kvm_vgic_destroy(kvm);
+	if (ret)
 		goto out;
-	}
+
 	dist->ready = true;
 	dist_base = dist->vgic_dist_base;
 	mutex_unlock(&kvm->arch.config_lock);
 
 	ret = vgic_register_dist_iodev(kvm, dist_base, type);
-	if (ret) {
+	if (ret)
 		kvm_err("Unable to register VGIC dist MMIO regions\n");
-		kvm_vgic_destroy(kvm);
-	}
-	mutex_unlock(&kvm->slots_lock);
-	return ret;
 
+	goto out_slots;
 out:
 	mutex_unlock(&kvm->arch.config_lock);
+out_slots:
 	mutex_unlock(&kvm->slots_lock);
+
+	if (ret)
+		kvm_vgic_destroy(kvm);
+
 	return ret;
 }
 
-- 
2.39.2



From maz at kernel.org  Thu Dec  7 07:12:00 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  7 Dec 2023 15:12:00 +0000
Subject: [PATCH 4/5] KVM: arm64: vgic: Ensure that slots_lock is held in vgic_register_all_redist_iodevs()
In-Reply-To: <20231207151201.3028710-1-maz@kernel.org>
References: <20231207151201.3028710-1-maz@kernel.org>
Message-ID: <20231207151201.3028710-5-maz@kernel.org>

Although we implicitly depend on slots_lock being held when registering
IO devices with the IO bus infrastructure, we don't enforce this
requirement. Make it explicit.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/vgic/vgic-mmio-v3.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 0f039d46d4fc..a764b0ab8bf9 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -833,6 +833,8 @@ static int vgic_register_all_redist_iodevs(struct kvm *kvm)
 	unsigned long c;
 	int ret = 0;
 
+	lockdep_assert_held(&kvm->slots_lock);
+
 	kvm_for_each_vcpu(c, vcpu, kvm) {
 		ret = vgic_register_redist_iodev(vcpu);
 		if (ret)
-- 
2.39.2



From maz at kernel.org  Thu Dec  7 07:11:56 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  7 Dec 2023 15:11:56 +0000
Subject: [PATCH 0/5] KVM: arm64: vgic fixes for 6.7
Message-ID: <20231207151201.3028710-1-maz@kernel.org>

It appears that under some cirumstances, the lifetime of a vcpu
doesn't correctly align with that of the structure describing the
redistributor associated with that vcpu. That's not great.

Fixing it is, unfortunately, not as trivial as it appears as the
required locking gets in the way.

The first two patches in this series amend that locking so that the
third patch, which is the actual fix, becomes almost trivial. The last
two patches are more cosmetic and only add assertions that helped me
debugging the whole thing.

I've earmarked the first 3 patches as stable candidates, and would
love to see them in 6.7. Patches on top of -rc4.

Marc Zyngier (5):
  KVM: arm64: vgic: Simplify kvm_vgic_destroy()
  KVM: arm64: vgic: Add a non-locking primitive for
    kvm_vgic_vcpu_destroy()
  KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy
  KVM: arm64: vgic: Ensure that slots_lock is held in
    vgic_register_all_redist_iodevs()
  KVM: Convert comment into an assertion in kvm_io_bus_register_dev()

 arch/arm64/kvm/arm.c               |  2 +-
 arch/arm64/kvm/vgic/vgic-init.c    | 47 ++++++++++++++++++------------
 arch/arm64/kvm/vgic/vgic-mmio-v3.c |  4 ++-
 arch/arm64/kvm/vgic/vgic.h         |  1 +
 virt/kvm/kvm_main.c                |  3 +-
 5 files changed, 36 insertions(+), 21 deletions(-)

-- 
2.39.2



From patchwork-bot+linux-riscv at kernel.org  Thu Dec  7 07:20:25 2023
From: patchwork-bot+linux-riscv at kernel.org (patchwork-bot+linux-riscv at kernel.org)
Date: Thu, 07 Dec 2023 15:20:25 +0000
Subject: [PATCH] dt-bindings: perf: riscv,pmu: drop unneeded quotes
In-Reply-To: <20231122224414.2809184-1-robh@kernel.org>
References: <20231122224414.2809184-1-robh@kernel.org>
Message-ID: <170196242567.12999.16480109529336505793.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to riscv/linux.git (fixes)
by Palmer Dabbelt <palmer at rivosinc.com>:

On Wed, 22 Nov 2023 15:44:14 -0700 you wrote:
> Drop unneeded quotes over simple string values to fix a soon to be
> enabled yamllint warning:
> 
>   [error] string value is redundantly quoted with any quotes (quoted-strings)
> 
> Signed-off-by: Rob Herring <robh at kernel.org>
> 
> [...]

Here is the summary with links:
  - dt-bindings: perf: riscv,pmu: drop unneeded quotes
    https://git.kernel.org/riscv/c/96ba4a47d147

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From krzysztof.kozlowski at linaro.org  Thu Dec  7 07:22:06 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 16:22:06 +0100
Subject: [PATCH v2 2/3] dt-bindings: arm: fsl: add Dimonoff gateway EVK
 board
In-Reply-To: <20231207150519.1264808-3-hugo@hugovil.com>
References: <20231207150519.1264808-1-hugo@hugovil.com>
 <20231207150519.1264808-3-hugo@hugovil.com>
Message-ID: <8e82dae7-342e-4985-b052-29778afe4b31@linaro.org>

On 07/12/2023 16:05, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> 
> Add DT compatible string for Dimonoff gateway EVK board based on a
> Variscite VAR-SOM-NANO with a NXP MX8MN nano CPU.
> 
> Signed-off-by: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> ---
>  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From michal.simek at amd.com  Thu Dec  7 07:24:08 2023
From: michal.simek at amd.com (Michal Simek)
Date: Thu, 7 Dec 2023 16:24:08 +0100
Subject: [PATCH] soc: xilinx: Add error message for invalid payload received from IPI callback.
Message-ID: <85749bde3e71148533d31ea2092f4514ec347768.1701962639.git.michal.simek@amd.com>

From: Naman Trivedi Manojbhai <naman.trivedimanojbhai at amd.com>

payload[0] of response buffer of zynqmp_pm_get_callback_data()
contains valid payload or error code in case of error.

Added error message to inform user about the error code received in
payload[0].

Signed-off-by: Naman Trivedi Manojbhai <naman.trivedimanojbhai at amd.com>
Signed-off-by: Michal Simek <michal.simek at amd.com>
---

 drivers/soc/xilinx/zynqmp_power.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/soc/xilinx/zynqmp_power.c b/drivers/soc/xilinx/zynqmp_power.c
index abcf7e883279..07d735b38b49 100644
--- a/drivers/soc/xilinx/zynqmp_power.c
+++ b/drivers/soc/xilinx/zynqmp_power.c
@@ -86,6 +86,8 @@ static irqreturn_t zynqmp_pm_isr(int irq, void *data)
 			pr_err("%s Unsupported InitSuspendCb reason code %d\n",
 			       __func__, payload[1]);
 		}
+	} else {
+		pr_err("%s() Unsupported Callback %d\n", __func__, payload[0]);
 	}
 
 	return IRQ_HANDLED;
-- 
2.36.1



From catalin.marinas at arm.com  Thu Dec  7 07:25:17 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 7 Dec 2023 15:25:17 +0000
Subject: [PATCH v3 11/25] arm64: enable ARCH_HAS_PKEYS on arm64
In-Reply-To: <20231124163510.1835740-12-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-12-joey.gouly@arm.com>
Message-ID: <ZXHj3TMuW7sPMqAc@arm.com>

On Fri, Nov 24, 2023 at 04:34:56PM +0000, Joey Gouly wrote:
> diff --git a/arch/arm64/include/asm/pkeys.h b/arch/arm64/include/asm/pkeys.h
> new file mode 100644
> index 000000000000..5761fb48fd53
> --- /dev/null
> +++ b/arch/arm64/include/asm/pkeys.h
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2023 Arm Ltd.
> + *
> + * Based on arch/x86/include/asm/pkeys.h
> +*/
> +
> +#ifndef _ASM_ARM64_PKEYS_H
> +#define _ASM_ARM64_PKEYS_H
> +
> +#define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2)
> +
> +#define arch_max_pkey() 0
> +
> +int arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
> +		unsigned long init_val);
> +
> +static inline bool arch_pkeys_enabled(void)
> +{
> +	return false;
> +}
> +
> +static inline int vma_pkey(struct vm_area_struct *vma)
> +{
> +	return -1;
> +}

What's the point of these dummies? I guess they'll be populated later
but I haven't reached that point. Could we not just leave them out for
now and add the complete version directly? This would work better with
an earlier comment to move the Kconfig entry towards the end of the
series.

Also, they don't seem to match the generic include/linux/pkeys.h
dummies. For example, vma_pkey() returns 0 in the generic version, -1
here. Should they actually match?

-- 
Catalin


From joey.gouly at arm.com  Thu Dec  7 07:44:44 2023
From: joey.gouly at arm.com (Joey Gouly)
Date: Thu, 7 Dec 2023 15:44:44 +0000
Subject: [PATCH v3 11/25] arm64: enable ARCH_HAS_PKEYS on arm64
In-Reply-To: <ZXHj3TMuW7sPMqAc@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-12-joey.gouly@arm.com>
 <ZXHj3TMuW7sPMqAc@arm.com>
Message-ID: <20231207154444.GA85238@e124191.cambridge.arm.com>

Hi,

Thanks to you and Mark for the comments so far!

On Thu, Dec 07, 2023 at 03:25:17PM +0000, Catalin Marinas wrote:
> On Fri, Nov 24, 2023 at 04:34:56PM +0000, Joey Gouly wrote:
> > diff --git a/arch/arm64/include/asm/pkeys.h b/arch/arm64/include/asm/pkeys.h
> > new file mode 100644
> > index 000000000000..5761fb48fd53
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/pkeys.h
> > @@ -0,0 +1,54 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2023 Arm Ltd.
> > + *
> > + * Based on arch/x86/include/asm/pkeys.h
> > +*/
> > +
> > +#ifndef _ASM_ARM64_PKEYS_H
> > +#define _ASM_ARM64_PKEYS_H
> > +
> > +#define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2)
> > +
> > +#define arch_max_pkey() 0
> > +
> > +int arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
> > +		unsigned long init_val);
> > +
> > +static inline bool arch_pkeys_enabled(void)
> > +{
> > +	return false;
> > +}
> > +
> > +static inline int vma_pkey(struct vm_area_struct *vma)
> > +{
> > +	return -1;
> > +}
> 
> What's the point of these dummies? I guess they'll be populated later
> but I haven't reached that point. Could we not just leave them out for
> now and add the complete version directly? This would work better with
> an earlier comment to move the Kconfig entry towards the end of the
> series.

I think the suggestion to move the Kconfig to the end is good, and I agree that
it will probably remove these dummy implementations.

> 
> Also, they don't seem to match the generic include/linux/pkeys.h
> dummies. For example, vma_pkey() returns 0 in the generic version, -1
> here. Should they actually match?

If for some reason I need to keep them after the Kconfig move, I will look into
this further.

Thanks,
Joey


From broonie at kernel.org  Thu Dec  7 07:47:58 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 7 Dec 2023 15:47:58 +0000
Subject: [PATCH v3 15/21] KVM: arm64: Support FEAT_FPMR for guests
In-Reply-To: <87bkb285ud.wl-maz@kernel.org>
References: <20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org>
 <20231205-arm64-2023-dpisa-v3-15-dbcbcd867a7f@kernel.org>
 <87cyvi8kz1.wl-maz@kernel.org>
 <08ae06c7-1654-4dfd-a789-b8e13c87d705@sirena.org.uk>
 <87bkb285ud.wl-maz@kernel.org>
Message-ID: <20074a3e-c735-4f30-b9b6-42ab15d94d5c@sirena.org.uk>

On Thu, Dec 07, 2023 at 02:06:34PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > > > @@ -517,7 +519,6 @@ struct kvm_vcpu_arch {
> > > >  	enum fp_type fp_type;
> > > >  	unsigned int sve_max_vl;
> > > >  	u64 svcr;
> > > > -	u64 fpmr;

> > > Why do this change here? Why isn't done like that the first place?

> > It didn't seem right to add the register to struct vcpu_sysreg before it
> > was handled by KVM.  As referenced in the cover letter normally this
> > wouldn't come up because KVM doesn't rely on the host kernel for
> > managing register state so we add KVM support then enable the host
> > kernel but for FPSIMD we're reusing fpsimd_save() so we need the host
> > kernel support to be in place when we enable KVM.

> That doesn't explain why you can't be upfront with it and populate the
> FPMR entry. In either case, you are wasting a u64.

So you'd rather just have the register listed in there as part of the
host support rather than initially excluding it?  Note that the current
series has the same approach as is currently used for SVCR which is in a
similar situation.

> > I agree that it's not great, the main issue was that fpsimd_state is
> > both already embedded in uw for hardened usercopy and very widely
> > referenced by exactly which struct it's in so I was taking a guess as to
> > what would get the least objections.  The obvious thing would be to add
> > FPMR to uw and share the whole thing with the hypervisor, if people
> > don't mind adding another field to uw I could do that?

> Either that, or you create a KVM-specific structure that contains
> these fields. If that results in KVM changes, so be it. But I won't
> take this sort of pointer arithmetic that assumes some pre-defined
> layout.

Moving fpsimd_state would have a big textual impact on the host code and
consequent issues with creating conflicts too so I'd rather avoid that.

> > > We really need to stop piling the save/restore of stuff that isn't
> > > advertised to the guest.

> > I'm not clear what you're referencing here?  The feature is advertised
> > to the guest via the ID registers and in the past you've pushed back on
> > making things where the state is just a single register like this
> > optional.  Do you mean that we should be making this conditional on the
> > guest ID registers?  If that is the case is there a plan for how that's
> > supposed to work, set flags when kvm_vcpu_run_pid_change() happens for
> > example?

> See the beginning of this email. It is high time that we stop enabling
> everything by default, because this totally breaks VM migration. We
> already have a huge backlog of these things, and I don't want to add
> more of it.

> Which means that at the very least, enabling *any* feature also comes
> with sanitising the state one way or another when this feature is
> disabled by userspace.

> How this is being done is still a work in progress: my current plan is
> based on a set of trap bits that are computed on a per-VM basis, and
> some side state that indicates whether the trap handling is for
> emulation or feature disabling purpose. This will probably reuse the
> NV infrastructure which has an exhaustive list of the sysregs that can
> be trapped from EL0/EL1.

> At the very least, userspace shouldn't be able to observe the state
> that a guest isn't supposed to generate, and we should be mindful of
> not creating covert channels.

OK, that does seem much more like what I'd have expected the enablement
of these extra features to look like (and may well simplify a bunch of
the existing trap management) though it is a big change in approach.  It
does greatly expand the scope of what's needed to virtualise the feature
though, and there's a bunch of other in flight serieses that'd be
impacted (eg, POR and GCS) and I'm expecting a bunch of overlap until
the general mechanism gets landed.

Based on that I think it might make sense to push the KVM guest support
for these features out and deal with them separately as part of the new
approach to trap/feature management.  Probably through pulling the KVM
bits to the end of the serieses so they're there for people to see.
Does that sound reasonable to you?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/01b76921/attachment.sig>

From mripard at kernel.org  Thu Dec  7 07:49:23 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:23 +0100
Subject: [PATCH v5 00/44] drm/connector: Create HDMI Connector
 infrastructure
Message-ID: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>

Hi,

Here's a series that creates some extra infrastructure specifically
targeted at HDMI controllers.

The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.

Infoframes generation code still requires some decent boilerplate, with
each driver doing some variation of it.

In parallel, while working on vc4, we ended up converting a lot of i915
logic (mostly around format / bpc selection, and scrambler setup) to
apply on top of a driver that relies only on helpers.

While currently sitting in the vc4 driver, none of that logic actually
relies on any driver or hardware-specific behaviour.

The only missing piece to make it shareable are a bunch of extra
variables stored in a state (current bpc, format, RGB range selection,
etc.).

The initial implementation was relying on some generic subclass of
drm_connector to address HDMI connectors, with a bunch of helpers that
will take care of all the "HDMI Spec" related code. Scrambler setup is
missing at the moment but can easily be plugged in.

The feedback was that creating a connector subclass like was done for
writeback would prevent the adoption of those helpers since it couldn't
be used in all situations (like when the connector driver can implement
multiple output) and required more churn to cast between the
drm_connector and its subclass. The decision was thus to provide a set
of helper and to store the required variables in drm_connector and
drm_connector_state. This what has been implemented now.

Hans Verkuil also expressed interest in implementing a mechanism in v4l2
to retrieve infoframes from HDMI receiver and implementing a tool to
decode (and eventually check) infoframes. His current work on
edid-decode to enable that based on that series can be found here:
https://git.linuxtv.org/hverkuil/edid-decode.git/log/?h=hverkuil

And some more context here:
https://lore.kernel.org/dri-devel/50db7366-cd3d-4675-aaad-b857202234de at xs4all.nl/

This series thus leverages the infoframe generation code to expose it
through debugfs.

I also used the occasion to unit-test everything but the infoframe
generation, which can come later once I get a proper understanding of
what the infoframe are supposed to look like. This required to add some
extra kunit helpers and infrastructure to have multiple EDIDs and allow
each test to run with a particular set of capabilities.

This entire series has been tested on a Pi4, passes all its unittests
(125 new tests), and has only been build-tested for sunxi and rockchip.

Let me know what you think,
Maxime

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
Changes in v5:
- Dropped the connector init arg checking patch, and the related kunit
  tests
- Dropped HDMI Vendor infoframes in rockchip inno_hdmi
- Fixed the build warnings
- Link to v4: https://lore.kernel.org/r/20231128-kms-hdmi-connector-state-v4-0-c7602158306e at kernel.org

Changes in v4:
- Create unit tests for everything but infoframes
- Fix a number of bugs identified by the unit tests
- Rename DRM (Dynamic Range and Mastering) infoframe file to HDR_DRM
- Drop RFC status
- Link to v3: https://lore.kernel.org/r/20231031-kms-hdmi-connector-state-v3-0-328b0fae43a7 at kernel.org

Changes in v3:
- Made sure the series work on the RaspberryPi4
- Handle YUV420 in the char clock rate computation
- Use the maximum bpc value the connector allows at reset
- Expose the RGB Limited vs Full Range value in the connector state
  instead of through a helper
- Fix Broadcast RGB documentation
- Add more debug logging
- Small fixes here and there
- Link to v2: https://lore.kernel.org/r/20230920-kms-hdmi-connector-state-v2-0-17932daddd7d at kernel.org

Changes in v2:
- Change from a subclass to a set of helpers for drm_connector and
  drm_connector state
- Don't assume that all drivers support RGB, YUV420 and YUV422 but make
  them provide a bitfield instead.
- Don't assume that all drivers support the Broadcast RGB property but
  make them call the registration helper.
- Document the Broacast RGB property
- Convert the inno_hdmi and sun4i_hdmi driver.
- Link to v1: https://lore.kernel.org/r/20230814-kms-hdmi-connector-state-v1-0-048054df3654 at kernel.org

---
Maxime Ripard (44):
      drm/tests: helpers: Include missing drm_drv header
      drm/tests: helpers: Add atomic helpers
      drm/tests: Add helper to create mock plane
      drm/tests: Add helper to create mock crtc
      drm/tests: connector: Add tests for drmm_connector_init
      drm/connector: Introduce an HDMI connector initialization function
      drm/connector: hdmi: Create an HDMI sub-state
      drm/connector: hdmi: Add Broadcast RGB property
      drm/connector: hdmi: Add RGB Quantization Range to the connector state
      drm/connector: hdmi: Add output BPC to the connector state
      drm/connector: hdmi: Add support for output format
      drm/connector: hdmi: Add HDMI compute clock helper
      drm/connector: hdmi: Calculate TMDS character rate
      drm/connector: hdmi: Add custom hook to filter TMDS character rate
      drm/connector: hdmi: Compute bpc and format automatically
      drm/connector: hdmi: Add Infoframes generation
      drm/connector: hdmi: Create Infoframe DebugFS entries
      drm/vc4: hdmi: Create destroy state implementation
      drm/vc4: hdmi: Switch to HDMI connector
      drm/vc4: tests: Remove vc4_dummy_plane structure
      drm/vc4: tests: Convert to plane creation helper
      drm/rockchip: inno_hdmi: Remove useless mode_fixup
      drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
      drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
      drm/rockchip: inno_hdmi: Get rid of mode_set
      drm/rockchip: inno_hdmi: no need to store vic
      drm/rockchip: inno_hdmi: Remove unneeded has audio flag
      drm/rockchip: inno_hdmi: Remove useless input format
      drm/rockchip: inno_hdmi: Remove useless output format
      drm/rockchip: inno_hdmi: Remove useless colorimetry
      drm/rockchip: inno_hdmi: Remove useless enum
      drm/rockchip: inno_hdmi: Remove tmds rate from structure
      drm/rockchip: inno_hdmi: Remove useless coeff_csc matrix
      drm/rockchip: inno_hdmi: Remove useless mode_valid
      drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support
      drm/rockchip: inno_hdmi: Move infoframe disable to separate function
      drm/rockchip: inno_hdmi: Switch to infoframe type
      drm/rockchip: inno_hdmi: Remove unused drm device pointer
      drm/rockchip: inno_hdmi: Switch to HDMI connector
      drm/sun4i: hdmi: Convert encoder to atomic
      drm/sun4i: hdmi: Move mode_set into enable
      drm/sun4i: hdmi: Switch to container_of_const
      drm/sun4i: hdmi: Consolidate atomic_check and mode_valid
      drm/sun4i: hdmi: Switch to HDMI connector

 Documentation/gpu/kms-properties.csv               |    1 -
 drivers/gpu/drm/Kconfig                            |    1 +
 drivers/gpu/drm/drm_atomic.c                       |   11 +
 drivers/gpu/drm/drm_atomic_state_helper.c          |  659 ++++++++
 drivers/gpu/drm/drm_atomic_uapi.c                  |    4 +
 drivers/gpu/drm/drm_connector.c                    |  243 +++
 drivers/gpu/drm/drm_debugfs.c                      |  110 ++
 drivers/gpu/drm/rockchip/inno_hdmi.c               |  346 +---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c             |  203 ++-
 drivers/gpu/drm/tests/Makefile                     |    1 +
 .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 1728 ++++++++++++++++++++
 drivers/gpu/drm/tests/drm_connector_test.c         | 1227 +++++++++++++-
 drivers/gpu/drm/tests/drm_kunit_edid.h             |  482 ++++++
 drivers/gpu/drm/tests/drm_kunit_helpers.c          |  150 ++
 drivers/gpu/drm/vc4/tests/vc4_mock.c               |    6 +-
 drivers/gpu/drm/vc4/tests/vc4_mock.h               |    9 +-
 drivers/gpu/drm/vc4/tests/vc4_mock_plane.c         |   44 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c                     |  626 +------
 drivers/gpu/drm/vc4/vc4_hdmi.h                     |   44 +-
 drivers/gpu/drm/vc4/vc4_hdmi_phy.c                 |    6 +-
 include/drm/drm_atomic_state_helper.h              |   12 +
 include/drm/drm_connector.h                        |  257 +++
 include/drm/drm_kunit_helpers.h                    |   23 +
 23 files changed, 5202 insertions(+), 991 deletions(-)
---
base-commit: 90d50b8d85834e73536fdccd5aa913b30494fef0
change-id: 20230814-kms-hdmi-connector-state-616787e67927

Best regards,
-- 
Maxime Ripard <mripard at kernel.org>



From mripard at kernel.org  Thu Dec  7 07:49:24 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:24 +0100
Subject: [PATCH v5 01/44] drm/tests: helpers: Include missing drm_drv
 header
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-1-6538e19d634d@kernel.org>

We have a few functions declared in our kunit helpers header, some of
them dereferencing the struct drm_driver.

However, we don't include the drm_drv.h header file defining that
structure, leading to compilation errors if we don't include both
headers.

Fixes: d98780310719 ("drm/tests: helpers: Allow to pass a custom drm_driver")
Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 include/drm/drm_kunit_helpers.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_kunit_helpers.h b/include/drm/drm_kunit_helpers.h
index ba483c87f0e7..3ae19892229d 100644
--- a/include/drm/drm_kunit_helpers.h
+++ b/include/drm/drm_kunit_helpers.h
@@ -3,6 +3,8 @@
 #ifndef DRM_KUNIT_HELPERS_H_
 #define DRM_KUNIT_HELPERS_H_
 
+#include <drm/drm_drv.h>
+
 #include <linux/device.h>
 
 #include <kunit/test.h>

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:25 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:25 +0100
Subject: [PATCH v5 02/44] drm/tests: helpers: Add atomic helpers
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-2-6538e19d634d@kernel.org>

The mock device we were creating was missing any of the driver-wide
helpers. That was fine before since we weren't testing the atomic state
path, but we're going to start, so let's use the default
implementations.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/tests/drm_kunit_helpers.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index bccb33b900f3..272a3ba46d60 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
 #include <drm/drm_atomic.h>
+#include <drm/drm_atomic_helper.h>
 #include <drm/drm_drv.h>
 #include <drm/drm_kunit_helpers.h>
 #include <drm/drm_managed.h>
@@ -13,6 +14,8 @@
 #define KUNIT_DEVICE_NAME	"drm-kunit-mock-device"
 
 static const struct drm_mode_config_funcs drm_mode_config_funcs = {
+	.atomic_check	= drm_atomic_helper_check,
+	.atomic_commit	= drm_atomic_helper_commit,
 };
 
 static int fake_probe(struct platform_device *pdev)

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:26 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:26 +0100
Subject: [PATCH v5 03/44] drm/tests: Add helper to create mock plane
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-3-6538e19d634d@kernel.org>

We're going to need a full-blown, functional, KMS device to test more
components of the atomic modesetting infrastructure.

Let's add a new helper to create a dumb, mocked, primary plane. By
default, it will create a linear XRGB8888 plane, using the default
helpers.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/tests/drm_kunit_helpers.c | 85 +++++++++++++++++++++++++++++++
 include/drm/drm_kunit_helpers.h           | 11 ++++
 2 files changed, 96 insertions(+)

diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 272a3ba46d60..e0778a7ec260 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -3,6 +3,7 @@
 #include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_fourcc.h>
 #include <drm/drm_kunit_helpers.h>
 #include <drm/drm_managed.h>
 
@@ -236,5 +237,89 @@ drm_kunit_helper_atomic_state_alloc(struct kunit *test,
 }
 EXPORT_SYMBOL_GPL(drm_kunit_helper_atomic_state_alloc);
 
+static const uint32_t default_plane_formats[] = {
+	DRM_FORMAT_XRGB8888,
+};
+
+static const uint64_t default_plane_modifiers[] = {
+	DRM_FORMAT_MOD_LINEAR,
+	DRM_FORMAT_MOD_INVALID
+};
+
+static const struct drm_plane_helper_funcs default_plane_helper_funcs = {
+};
+
+static const struct drm_plane_funcs default_plane_funcs = {
+	.atomic_destroy_state	= drm_atomic_helper_plane_destroy_state,
+	.atomic_duplicate_state	= drm_atomic_helper_plane_duplicate_state,
+	.reset			= drm_atomic_helper_plane_reset,
+};
+
+/**
+ * drm_kunit_helper_create_primary_plane - Creates a mock primary plane for a KUnit test
+ * @test: The test context object
+ * @drm: The device to alloc the plane for
+ * @funcs: Callbacks for the new plane. Optional.
+ * @helper_funcs: Helpers callbacks for the new plane. Optional.
+ * @formats: array of supported formats (DRM_FORMAT\_\*). Optional.
+ * @num_formats: number of elements in @formats
+ * @modifiers: array of struct drm_format modifiers terminated by
+ *             DRM_FORMAT_MOD_INVALID. Optional.
+ *
+ * This allocates and initializes a mock struct &drm_plane meant to be
+ * part of a mock device for a KUnit test.
+ *
+ * Resources will be cleaned up automatically.
+ *
+ * @funcs will default to the default helpers implementations.
+ * @helper_funcs will default to an empty implementation. @formats will
+ * default to XRGB8888 only. @modifiers will default to a linear
+ * modifier only.
+ *
+ * Returns:
+ * A pointer to the new plane, or an ERR_PTR() otherwise.
+ */
+struct drm_plane *
+drm_kunit_helper_create_primary_plane(struct kunit *test,
+				      struct drm_device *drm,
+				      const struct drm_plane_funcs *funcs,
+				      const struct drm_plane_helper_funcs *helper_funcs,
+				      const uint32_t *formats,
+				      unsigned int num_formats,
+				      const uint64_t *modifiers)
+{
+	struct drm_plane *plane;
+
+	if (!funcs)
+		funcs = &default_plane_funcs;
+
+	if (!helper_funcs)
+		helper_funcs = &default_plane_helper_funcs;
+
+	if (!formats || !num_formats) {
+		formats = default_plane_formats;
+		num_formats = ARRAY_SIZE(default_plane_formats);
+	}
+
+	if (!modifiers)
+		modifiers = default_plane_modifiers;
+
+	plane = __drmm_universal_plane_alloc(drm,
+					     sizeof(struct drm_plane), 0,
+					     0,
+					     funcs,
+					     formats,
+					     num_formats,
+					     default_plane_modifiers,
+					     DRM_PLANE_TYPE_PRIMARY,
+					     NULL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, plane);
+
+	drm_plane_helper_add(plane, helper_funcs);
+
+	return plane;
+}
+EXPORT_SYMBOL_GPL(drm_kunit_helper_create_primary_plane);
+
 MODULE_AUTHOR("Maxime Ripard <maxime at cerno.tech>");
 MODULE_LICENSE("GPL");
diff --git a/include/drm/drm_kunit_helpers.h b/include/drm/drm_kunit_helpers.h
index 3ae19892229d..38667d624aa8 100644
--- a/include/drm/drm_kunit_helpers.h
+++ b/include/drm/drm_kunit_helpers.h
@@ -10,6 +10,8 @@
 #include <kunit/test.h>
 
 struct drm_device;
+struct drm_plane_funcs;
+struct drm_plane_helper_funcs;
 struct kunit;
 
 struct device *drm_kunit_helper_alloc_device(struct kunit *test);
@@ -99,4 +101,13 @@ drm_kunit_helper_atomic_state_alloc(struct kunit *test,
 				    struct drm_device *drm,
 				    struct drm_modeset_acquire_ctx *ctx);
 
+struct drm_plane *
+drm_kunit_helper_create_primary_plane(struct kunit *test,
+				      struct drm_device *drm,
+				      const struct drm_plane_funcs *funcs,
+				      const struct drm_plane_helper_funcs *helper_funcs,
+				      const uint32_t *formats,
+				      unsigned int num_formats,
+				      const uint64_t *modifiers);
+
 #endif // DRM_KUNIT_HELPERS_H_

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:27 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:27 +0100
Subject: [PATCH v5 04/44] drm/tests: Add helper to create mock crtc
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-4-6538e19d634d@kernel.org>

We're going to need a full-blown, functional, KMS device to test more
components of the atomic modesetting infrastructure.

Let's add a new helper to create a dumb, mocked, CRTC. By default it
will create a CRTC relying only on the default helpers, but drivers are
free to deviate from that.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/tests/drm_kunit_helpers.c | 62 +++++++++++++++++++++++++++++++
 include/drm/drm_kunit_helpers.h           | 10 +++++
 2 files changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index e0778a7ec260..ca513235b5e2 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -321,5 +321,67 @@ drm_kunit_helper_create_primary_plane(struct kunit *test,
 }
 EXPORT_SYMBOL_GPL(drm_kunit_helper_create_primary_plane);
 
+static const struct drm_crtc_helper_funcs default_crtc_helper_funcs = {
+};
+
+static const struct drm_crtc_funcs default_crtc_funcs = {
+	.atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
+	.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+	.reset                  = drm_atomic_helper_crtc_reset,
+};
+
+/**
+ * drm_kunit_helper_create_crtc - Creates a mock CRTC for a KUnit test
+ * @test: The test context object
+ * @drm: The device to alloc the plane for
+ * @primary: Primary plane for CRTC
+ * @cursor: Cursor plane for CRTC. Optional.
+ * @funcs: Callbacks for the new plane. Optional.
+ * @helper_funcs: Helpers callbacks for the new plane. Optional.
+ *
+ * This allocates and initializes a mock struct &drm_crtc meant to be
+ * part of a mock device for a KUnit test.
+ *
+ * Resources will be cleaned up automatically.
+ *
+ * @funcs will default to the default helpers implementations.
+ * @helper_funcs will default to an empty implementation.
+ *
+ * Returns:
+ * A pointer to the new CRTC, or an ERR_PTR() otherwise.
+ */
+struct drm_crtc *
+drm_kunit_helper_create_crtc(struct kunit *test,
+			     struct drm_device *drm,
+			     struct drm_plane *primary,
+			     struct drm_plane *cursor,
+			     const struct drm_crtc_funcs *funcs,
+			     const struct drm_crtc_helper_funcs *helper_funcs)
+{
+	struct drm_crtc *crtc;
+	int ret;
+
+	if (!funcs)
+		funcs = &default_crtc_funcs;
+
+	if (!helper_funcs)
+		helper_funcs = &default_crtc_helper_funcs;
+
+	crtc = drmm_kzalloc(drm, sizeof(*crtc), GFP_KERNEL);
+	KUNIT_ASSERT_NOT_NULL(test, crtc);
+
+	ret = drmm_crtc_init_with_planes(drm, crtc,
+					 primary,
+					 cursor,
+					 funcs,
+					 NULL);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	drm_crtc_helper_add(crtc, helper_funcs);
+
+	return crtc;
+}
+EXPORT_SYMBOL_GPL(drm_kunit_helper_create_crtc);
+
 MODULE_AUTHOR("Maxime Ripard <maxime at cerno.tech>");
 MODULE_LICENSE("GPL");
diff --git a/include/drm/drm_kunit_helpers.h b/include/drm/drm_kunit_helpers.h
index 38667d624aa8..6e99627edf45 100644
--- a/include/drm/drm_kunit_helpers.h
+++ b/include/drm/drm_kunit_helpers.h
@@ -9,6 +9,8 @@
 
 #include <kunit/test.h>
 
+struct drm_crtc_funcs;
+struct drm_crtc_helper_funcs;
 struct drm_device;
 struct drm_plane_funcs;
 struct drm_plane_helper_funcs;
@@ -110,4 +112,12 @@ drm_kunit_helper_create_primary_plane(struct kunit *test,
 				      unsigned int num_formats,
 				      const uint64_t *modifiers);
 
+struct drm_crtc *
+drm_kunit_helper_create_crtc(struct kunit *test,
+			     struct drm_device *drm,
+			     struct drm_plane *primary,
+			     struct drm_plane *cursor,
+			     const struct drm_crtc_funcs *funcs,
+			     const struct drm_crtc_helper_funcs *helper_funcs);
+
 #endif // DRM_KUNIT_HELPERS_H_

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:28 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:28 +0100
Subject: [PATCH v5 05/44] drm/tests: connector: Add tests for
 drmm_connector_init
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-5-6538e19d634d@kernel.org>

drmm_connector_init is the preferred function to initialize a
drm_connector structure. Let's add a bunch of unit tests for it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/tests/drm_connector_test.c | 170 ++++++++++++++++++++++++++++-
 1 file changed, 169 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
index c66aa2dc8d9d..a268847be8d1 100644
--- a/drivers/gpu/drm/tests/drm_connector_test.c
+++ b/drivers/gpu/drm/tests/drm_connector_test.c
@@ -3,10 +3,175 @@
  * Kunit test for drm_modes functions
  */
 
+#include <linux/i2c.h>
+
+#include <drm/drm_atomic_state_helper.h>
 #include <drm/drm_connector.h>
+#include <drm/drm_drv.h>
+#include <drm/drm_kunit_helpers.h>
 
 #include <kunit/test.h>
 
+struct drm_connector_init_priv {
+	struct drm_device drm;
+	struct drm_connector connector;
+	struct i2c_adapter ddc;
+};
+
+static const struct drm_connector_funcs dummy_funcs = {
+	.atomic_destroy_state	= drm_atomic_helper_connector_destroy_state,
+	.atomic_duplicate_state	= drm_atomic_helper_connector_duplicate_state,
+	.reset			= drm_atomic_helper_connector_reset,
+};
+
+static int dummy_ddc_xfer(struct i2c_adapter *adapter,
+			  struct i2c_msg *msgs, int num)
+{
+	return num;
+}
+
+static u32 dummy_ddc_func(struct i2c_adapter *adapter)
+{
+	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static const struct i2c_algorithm dummy_ddc_algorithm = {
+	.master_xfer = dummy_ddc_xfer,
+	.functionality = dummy_ddc_func,
+};
+
+static void i2c_del_adapter_wrapper(void *ptr)
+{
+	struct i2c_adapter *adap = ptr;
+
+	i2c_del_adapter(adap);
+}
+
+static int drm_test_connector_init(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv;
+	struct device *dev;
+	int ret;
+
+	dev = drm_kunit_helper_alloc_device(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dev);
+
+	priv = drm_kunit_helper_alloc_drm_device(test, dev,
+						 struct drm_connector_init_priv, drm,
+						 DRIVER_MODESET | DRIVER_ATOMIC);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
+
+	strscpy(priv->ddc.name, "dummy-connector-ddc", sizeof(priv->ddc.name));
+	priv->ddc.owner = THIS_MODULE;
+	priv->ddc.algo = &dummy_ddc_algorithm;
+	priv->ddc.dev.parent = dev;
+
+	ret = i2c_add_adapter(&priv->ddc);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	ret = kunit_add_action_or_reset(test, i2c_del_adapter_wrapper, &priv->ddc);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	test->priv = priv;
+	return 0;
+}
+
+/*
+ * Test that the registration of a bog standard connector works as
+ * expected and doesn't report any error.
+ */
+static void drm_test_drmm_connector_init(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_init(&priv->drm, &priv->connector,
+				  &dummy_funcs,
+				  DRM_MODE_CONNECTOR_HDMIA,
+				  &priv->ddc);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+}
+
+/*
+ * Test that the registration of a connector without a DDC adapter
+ * doesn't report any error.
+ */
+static void drm_test_drmm_connector_init_null_ddc(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_init(&priv->drm, &priv->connector,
+				  &dummy_funcs,
+				  DRM_MODE_CONNECTOR_HDMIA,
+				  NULL);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+}
+
+/*
+ * Test that the registration of a connector succeeds for all possible
+ * connector types.
+ */
+static void drm_test_drmm_connector_init_type_valid(struct kunit *test)
+{
+       struct drm_connector_init_priv *priv = test->priv;
+       unsigned int connector_type = *(unsigned int *)test->param_value;
+       int ret;
+
+       ret = drmm_connector_init(&priv->drm, &priv->connector,
+				 &dummy_funcs,
+				 connector_type,
+				 &priv->ddc);
+       KUNIT_EXPECT_EQ(test, ret, 0);
+}
+
+static const unsigned int drm_connector_init_type_valid_tests[] = {
+	DRM_MODE_CONNECTOR_Unknown,
+	DRM_MODE_CONNECTOR_VGA,
+	DRM_MODE_CONNECTOR_DVII,
+	DRM_MODE_CONNECTOR_DVID,
+	DRM_MODE_CONNECTOR_DVIA,
+	DRM_MODE_CONNECTOR_Composite,
+	DRM_MODE_CONNECTOR_SVIDEO,
+	DRM_MODE_CONNECTOR_LVDS,
+	DRM_MODE_CONNECTOR_Component,
+	DRM_MODE_CONNECTOR_9PinDIN,
+	DRM_MODE_CONNECTOR_DisplayPort,
+	DRM_MODE_CONNECTOR_HDMIA,
+	DRM_MODE_CONNECTOR_HDMIB,
+	DRM_MODE_CONNECTOR_TV,
+	DRM_MODE_CONNECTOR_eDP,
+	DRM_MODE_CONNECTOR_VIRTUAL,
+	DRM_MODE_CONNECTOR_DSI,
+	DRM_MODE_CONNECTOR_DPI,
+	DRM_MODE_CONNECTOR_WRITEBACK,
+	DRM_MODE_CONNECTOR_SPI,
+	DRM_MODE_CONNECTOR_USB,
+};
+
+static void drm_connector_init_type_desc(const unsigned int *type, char *desc)
+{
+	sprintf(desc, "%s", drm_get_connector_type_name(*type));
+}
+
+KUNIT_ARRAY_PARAM(drm_connector_init_type_valid,
+		  drm_connector_init_type_valid_tests,
+		  drm_connector_init_type_desc);
+
+static struct kunit_case drmm_connector_init_tests[] = {
+	KUNIT_CASE(drm_test_drmm_connector_init),
+	KUNIT_CASE(drm_test_drmm_connector_init_null_ddc),
+	KUNIT_CASE_PARAM(drm_test_drmm_connector_init_type_valid,
+			 drm_connector_init_type_valid_gen_params),
+	{ }
+};
+
+static struct kunit_suite drmm_connector_init_test_suite = {
+	.name = "drmm_connector_init",
+	.init = drm_test_connector_init,
+	.test_cases = drmm_connector_init_tests,
+};
+
 struct drm_get_tv_mode_from_name_test {
 	const char *name;
 	enum drm_connector_tv_mode expected_mode;
@@ -70,7 +235,10 @@ static struct kunit_suite drm_get_tv_mode_from_name_test_suite = {
 	.test_cases = drm_get_tv_mode_from_name_tests,
 };
 
-kunit_test_suite(drm_get_tv_mode_from_name_test_suite);
+kunit_test_suites(
+	&drmm_connector_init_test_suite,
+	&drm_get_tv_mode_from_name_test_suite
+);
 
 MODULE_AUTHOR("Maxime Ripard <maxime at cerno.tech>");
 MODULE_LICENSE("GPL");

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:29 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:29 +0100
Subject: [PATCH v5 06/44] drm/connector: Introduce an HDMI connector
 initialization function
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-6-6538e19d634d@kernel.org>

A lot of the various HDMI drivers duplicate some logic that depends on
the HDMI spec itself and not really a particular hardware
implementation.

Output BPC or format selection, infoframe generation are good examples
of such areas.

This creates a lot of boilerplate, with a lot of variations, which makes
it hard for userspace to rely on, and makes it difficult to get it right
for drivers.

In the next patches, we'll add a lot of infrastructure around the
drm_connector and drm_connector_state structures, which will allow to
abstract away the duplicated logic. This infrastructure comes with a few
requirements though, and thus we need a new initialization function.

Hopefully, this will make drivers simpler to handle, and their behaviour
more consistent.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_connector.c            |  39 +++++++++
 drivers/gpu/drm/tests/drm_connector_test.c | 123 +++++++++++++++++++++++++++++
 include/drm/drm_connector.h                |   5 ++
 3 files changed, 167 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b0516505f7ae..d9961cce8245 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -452,6 +452,45 @@ int drmm_connector_init(struct drm_device *dev,
 }
 EXPORT_SYMBOL(drmm_connector_init);
 
+/**
+ * drmm_connector_hdmi_init - Init a preallocated HDMI connector
+ * @dev: DRM device
+ * @connector: A pointer to the HDMI connector to init
+ * @funcs: callbacks for this connector
+ * @connector_type: user visible type of the connector
+ * @ddc: optional pointer to the associated ddc adapter
+ *
+ * Initialises a preallocated HDMI connector. Connectors can be
+ * subclassed as part of driver connector objects.
+ *
+ * Cleanup is automatically handled with a call to
+ * drm_connector_cleanup() in a DRM-managed action.
+ *
+ * The connector structure should be allocated with drmm_kzalloc().
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drmm_connector_hdmi_init(struct drm_device *dev,
+			     struct drm_connector *connector,
+			     const struct drm_connector_funcs *funcs,
+			     int connector_type,
+			     struct i2c_adapter *ddc)
+{
+	int ret;
+
+	if (!(connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+	      connector_type == DRM_MODE_CONNECTOR_HDMIB))
+		return -EINVAL;
+
+	ret = drmm_connector_init(dev, connector, funcs, connector_type, ddc);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+EXPORT_SYMBOL(drmm_connector_hdmi_init);
+
 /**
  * drm_connector_attach_edid_property - attach edid property.
  * @connector: the connector
diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
index a268847be8d1..8f070cacab3b 100644
--- a/drivers/gpu/drm/tests/drm_connector_test.c
+++ b/drivers/gpu/drm/tests/drm_connector_test.c
@@ -172,6 +172,128 @@ static struct kunit_suite drmm_connector_init_test_suite = {
 	.test_cases = drmm_connector_init_tests,
 };
 
+/*
+ * Test that the registration of a bog standard connector works as
+ * expected and doesn't report any error.
+ */
+static void drm_test_connector_hdmi_init_valid(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+}
+
+/*
+ * Test that the registration of a connector without a DDC adapter
+ * doesn't report any error.
+ */
+static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       NULL);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+}
+
+/*
+ * Test that the registration of an HDMI connector with an HDMI
+ * connector type succeeds.
+ */
+static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	unsigned int connector_type = *(unsigned int *)test->param_value;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       &dummy_funcs,
+				       connector_type,
+				       &priv->ddc);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+}
+
+static const unsigned int drm_connector_hdmi_init_type_valid_tests[] = {
+	DRM_MODE_CONNECTOR_HDMIA,
+	DRM_MODE_CONNECTOR_HDMIB,
+};
+
+static void drm_connector_hdmi_init_type_desc(const unsigned int *type, char *desc)
+{
+	sprintf(desc, "%s", drm_get_connector_type_name(*type));
+}
+
+KUNIT_ARRAY_PARAM(drm_connector_hdmi_init_type_valid,
+		  drm_connector_hdmi_init_type_valid_tests,
+		  drm_connector_hdmi_init_type_desc);
+
+/*
+ * Test that the registration of an HDMI connector with an !HDMI
+ * connector type fails.
+ */
+static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	unsigned int connector_type = *(unsigned int *)test->param_value;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       &dummy_funcs,
+				       connector_type,
+				       &priv->ddc);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
+static const unsigned int drm_connector_hdmi_init_type_invalid_tests[] = {
+	DRM_MODE_CONNECTOR_Unknown,
+	DRM_MODE_CONNECTOR_VGA,
+	DRM_MODE_CONNECTOR_DVII,
+	DRM_MODE_CONNECTOR_DVID,
+	DRM_MODE_CONNECTOR_DVIA,
+	DRM_MODE_CONNECTOR_Composite,
+	DRM_MODE_CONNECTOR_SVIDEO,
+	DRM_MODE_CONNECTOR_LVDS,
+	DRM_MODE_CONNECTOR_Component,
+	DRM_MODE_CONNECTOR_9PinDIN,
+	DRM_MODE_CONNECTOR_DisplayPort,
+	DRM_MODE_CONNECTOR_TV,
+	DRM_MODE_CONNECTOR_eDP,
+	DRM_MODE_CONNECTOR_VIRTUAL,
+	DRM_MODE_CONNECTOR_DSI,
+	DRM_MODE_CONNECTOR_DPI,
+	DRM_MODE_CONNECTOR_WRITEBACK,
+	DRM_MODE_CONNECTOR_SPI,
+	DRM_MODE_CONNECTOR_USB,
+};
+
+KUNIT_ARRAY_PARAM(drm_connector_hdmi_init_type_invalid,
+		  drm_connector_hdmi_init_type_invalid_tests,
+		  drm_connector_hdmi_init_type_desc);
+
+static struct kunit_case drmm_connector_hdmi_init_tests[] = {
+	KUNIT_CASE(drm_test_connector_hdmi_init_valid),
+	KUNIT_CASE(drm_test_connector_hdmi_init_null_ddc),
+	KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_valid,
+			 drm_connector_hdmi_init_type_valid_gen_params),
+	KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_invalid,
+			 drm_connector_hdmi_init_type_invalid_gen_params),
+	{ }
+};
+
+static struct kunit_suite drmm_connector_hdmi_init_test_suite = {
+	.name = "drmm_connector_hdmi_init",
+	.init = drm_test_connector_init,
+	.test_cases = drmm_connector_hdmi_init_tests,
+};
+
 struct drm_get_tv_mode_from_name_test {
 	const char *name;
 	enum drm_connector_tv_mode expected_mode;
@@ -236,6 +358,7 @@ static struct kunit_suite drm_get_tv_mode_from_name_test_suite = {
 };
 
 kunit_test_suites(
+	&drmm_connector_hdmi_init_test_suite,
 	&drmm_connector_init_test_suite,
 	&drm_get_tv_mode_from_name_test_suite
 );
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..4491c4c2fb6e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1904,6 +1904,11 @@ int drmm_connector_init(struct drm_device *dev,
 			const struct drm_connector_funcs *funcs,
 			int connector_type,
 			struct i2c_adapter *ddc);
+int drmm_connector_hdmi_init(struct drm_device *dev,
+			     struct drm_connector *connector,
+			     const struct drm_connector_funcs *funcs,
+			     int connector_type,
+			     struct i2c_adapter *ddc);
 void drm_connector_attach_edid_property(struct drm_connector *connector);
 int drm_connector_register(struct drm_connector *connector);
 void drm_connector_unregister(struct drm_connector *connector);

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:30 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:30 +0100
Subject: [PATCH v5 07/44] drm/connector: hdmi: Create an HDMI sub-state
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-7-6538e19d634d@kernel.org>

The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.

Let's create a new connector sub-state dedicated to HDMI controllers,
that will eventually store everything we need.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_atomic_state_helper.c | 35 +++++++++++++++++++++++++++++++
 include/drm/drm_atomic_state_helper.h     |  4 ++++
 include/drm/drm_connector.h               |  7 +++++++
 3 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 54975de44a0e..e69c0cc1c6da 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -570,6 +570,22 @@ void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
 
+/**
+ * __drm_atomic_helper_connector_hdmi_reset() - Initializes all HDMI @drm_connector_state resources
+ * @connector: DRM connector
+ * @new_state: connector state to reset
+ *
+ * Initializes all HDMI resources from a @drm_connector_state without
+ * actually allocating it. This is useful for HDMI drivers, in
+ * combination with __drm_atomic_helper_connector_reset() or
+ * drm_atomic_helper_connector_reset().
+ */
+void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
+					      struct drm_connector_state *new_state)
+{
+}
+EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
+
 /**
  * drm_atomic_helper_connector_tv_check - Validate an analog TV connector state
  * @connector: DRM Connector
@@ -619,6 +635,25 @@ int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
 
+/**
+ * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
+ * @connector: DRM Connector
+ * @state: the DRM State object
+ *
+ * Provides a default connector state check handler for HDMI connectors.
+ * Checks that a desired connector update is valid, and updates various
+ * fields of derived state.
+ *
+ * RETURNS:
+ * Zero on success, or an errno code otherwise.
+ */
+int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
+					   struct drm_atomic_state *state)
+{
+	return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_check);
+
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
  * @connector: connector object
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index b9740edb2658..d59d2b3aef9a 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -71,7 +71,11 @@ void __drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_
 void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
 					 struct drm_connector_state *conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
+void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
+					      struct drm_connector_state *new_state);
 void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
+					   struct drm_atomic_state *state);
 int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
 					 struct drm_atomic_state *state);
 void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4491c4c2fb6e..000a2a156619 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1031,6 +1031,13 @@ struct drm_connector_state {
 	 * DRM blob property for HDR output metadata
 	 */
 	struct drm_property_blob *hdr_output_metadata;
+
+	/**
+	 * @hdmi: HDMI-related variable and properties. Filled by
+	 * @drm_atomic_helper_connector_hdmi_check().
+	 */
+	struct {
+	} hdmi;
 };
 
 /**

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:31 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:31 +0100
Subject: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-8-6538e19d634d@kernel.org>

The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.

Both drivers implementing the same property with the same semantics,
plus the userspace having support for it, is proof enough that it's
pretty much a de-facto standard now and we can provide helpers for it.

Let's plumb it into the newly created HDMI connector.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 Documentation/gpu/kms-properties.csv               |   1 -
 drivers/gpu/drm/drm_atomic.c                       |   5 +
 drivers/gpu/drm/drm_atomic_state_helper.c          |  17 +
 drivers/gpu/drm/drm_atomic_uapi.c                  |   4 +
 drivers/gpu/drm/drm_connector.c                    |  76 +++++
 drivers/gpu/drm/tests/Makefile                     |   1 +
 .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 376 +++++++++++++++++++++
 drivers/gpu/drm/tests/drm_connector_test.c         | 117 ++++++-
 drivers/gpu/drm/tests/drm_kunit_edid.h             | 106 ++++++
 include/drm/drm_connector.h                        |  36 ++
 10 files changed, 737 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv
index 0f9590834829..caef14c532d4 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,7 +17,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,De
 ,Virtual GPU,?suggested X?,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector
 ,,?suggested Y?,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB
-i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normally in the range 0..1.0 are remapped to the range 16/255..235/255."
 ,,?audio?,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,?mode?,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD
 ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c31fc0b48c31..1465a7f09a0b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1142,6 +1142,11 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
 	drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
 	drm_printf(p, "\tcolorspace=%s\n", drm_get_colorspace_name(state->colorspace));
 
+	if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+	    connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)
+		drm_printf(p, "\tbroadcast_rgb=%s\n",
+			   drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
+
 	if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
 		if (state->writeback_job && state->writeback_job->fb)
 			drm_printf(p, "\tfb=%d\n", state->writeback_job->fb->base.id);
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index e69c0cc1c6da..10d98620a358 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -583,6 +583,7 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
 void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
 					      struct drm_connector_state *new_state)
 {
+	new_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
 
@@ -650,6 +651,22 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
 int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
 					   struct drm_atomic_state *state)
 {
+	struct drm_connector_state *old_state =
+		drm_atomic_get_old_connector_state(state, connector);
+	struct drm_connector_state *new_state =
+		drm_atomic_get_new_connector_state(state, connector);
+
+	if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb) {
+		struct drm_crtc *crtc = new_state->crtc;
+		struct drm_crtc_state *crtc_state;
+
+		crtc_state = drm_atomic_get_crtc_state(state, crtc);
+		if (IS_ERR(crtc_state))
+			return PTR_ERR(crtc_state);
+
+		crtc_state->mode_changed = true;
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_check);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index aee4a65d4959..3eb4f4bc8b71 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -818,6 +818,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
 		state->max_requested_bpc = val;
 	} else if (property == connector->privacy_screen_sw_state_property) {
 		state->privacy_screen_sw_state = val;
+	} else if (property == connector->broadcast_rgb_property) {
+		state->hdmi.broadcast_rgb = val;
 	} else if (connector->funcs->atomic_set_property) {
 		return connector->funcs->atomic_set_property(connector,
 				state, property, val);
@@ -901,6 +903,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		*val = state->max_requested_bpc;
 	} else if (property == connector->privacy_screen_sw_state_property) {
 		*val = state->privacy_screen_sw_state;
+	} else if (property == connector->broadcast_rgb_property) {
+		*val = state->hdmi.broadcast_rgb;
 	} else if (connector->funcs->atomic_get_property) {
 		return connector->funcs->atomic_get_property(connector,
 				state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d9961cce8245..929b0a911f62 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1183,6 +1183,29 @@ static const u32 dp_colorspaces =
 	BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
 	BIT(DRM_MODE_COLORIMETRY_BT2020_YCC);
 
+static const struct drm_prop_enum_list broadcast_rgb_names[] = {
+	{ DRM_HDMI_BROADCAST_RGB_AUTO, "Automatic" },
+	{ DRM_HDMI_BROADCAST_RGB_FULL, "Full" },
+	{ DRM_HDMI_BROADCAST_RGB_LIMITED, "Limited 16:235" },
+};
+
+/*
+ * drm_hdmi_connector_get_broadcast_rgb_name - Return a string for HDMI connector RGB broadcast selection
+ * @broadcast_rgb: Broadcast RGB selection to compute name of
+ *
+ * Returns: the name of the Broadcast RGB selection, or NULL if the type
+ * is not valid.
+ */
+const char *
+drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_rgb)
+{
+	if (broadcast_rgb > DRM_HDMI_BROADCAST_RGB_LIMITED)
+		return NULL;
+
+	return broadcast_rgb_names[broadcast_rgb].name;
+}
+EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name);
+
 /**
  * DOC: standard connector properties
  *
@@ -1655,6 +1678,26 @@ EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
 /**
  * DOC: HDMI connector properties
  *
+ * Broadcast RGB
+ *      Indicates the RGB Quantization Range (Full vs Limited) used.
+ *      Infoframes will be generated according to that value.
+ *
+ *      The value of this property can be one of the following:
+ *
+ *      Automatic:
+ *              RGB Range is selected automatically based on the mode
+ *              according to the HDMI specifications.
+ *
+ *      Full:
+ *              Full RGB Range is forced.
+ *
+ *      Limited 16:235:
+ *              Limited RGB Range is forced. Unlike the name suggests,
+ *              this works for any number of bits-per-component.
+ *
+ *      Drivers can set up this property by calling
+ *      drm_connector_attach_broadcast_rgb_property().
+ *
  * content type (HDMI specific):
  *	Indicates content type setting to be used in HDMI infoframes to indicate
  *	content type for the external device, so that it adjusts its display
@@ -2517,6 +2560,39 @@ int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
 }
 EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
 
+/**
+ * drm_connector_attach_broadcast_rgb_property - attach "Broadcast RGB" property
+ * @connector: connector to attach the property on.
+ *
+ * This is used to add support for forcing the RGB range on a connector
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_broadcast_rgb_property(struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	prop = connector->broadcast_rgb_property;
+	if (!prop) {
+		prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+						"Broadcast RGB",
+						broadcast_rgb_names,
+						ARRAY_SIZE(broadcast_rgb_names));
+		if (!prop)
+			return -EINVAL;
+
+		connector->broadcast_rgb_property = prop;
+	}
+
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_HDMI_BROADCAST_RGB_AUTO);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_broadcast_rgb_property);
+
 /**
  * drm_connector_attach_colorspace_property - attach "Colorspace" property
  * @connector: connector to attach the property on.
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index d6183b3d7688..b29ddfd90596 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST_HELPERS) += \
 	drm_kunit_helpers.o
 
 obj-$(CONFIG_DRM_KUNIT_TEST) += \
+	drm_atomic_state_helper_test.o \
 	drm_buddy_test.o \
 	drm_cmdline_parser_test.o \
 	drm_connector_test.o \
diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
new file mode 100644
index 000000000000..21e6f796ee13
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
@@ -0,0 +1,376 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Kunit test for drm_atomic_state_helper functions
+ */
+
+#include <drm/drm_atomic.h>
+#include <drm/drm_atomic_state_helper.h>
+#include <drm/drm_atomic_uapi.h>
+#include <drm/drm_drv.h>
+#include <drm/drm_edid.h>
+#include <drm/drm_connector.h>
+#include <drm/drm_fourcc.h>
+#include <drm/drm_kunit_helpers.h>
+#include <drm/drm_managed.h>
+#include <drm/drm_modeset_helper_vtables.h>
+#include <drm/drm_probe_helper.h>
+
+#include <drm/drm_print.h>
+#include "../drm_crtc_internal.h"
+
+#include <kunit/test.h>
+
+#include "drm_kunit_edid.h"
+
+struct drm_atomic_helper_connector_hdmi_priv {
+	struct drm_device drm;
+	struct drm_plane *plane;
+	struct drm_crtc *crtc;
+	struct drm_encoder encoder;
+	struct drm_connector connector;
+
+	const char *current_edid;
+	size_t current_edid_len;
+};
+
+#define connector_to_priv(c) \
+	container_of_const(c, struct drm_atomic_helper_connector_hdmi_priv, connector)
+
+static struct drm_display_mode *find_preferred_mode(struct drm_connector *connector)
+{
+	struct drm_device *drm = connector->dev;
+	struct drm_display_mode *mode, *preferred;
+
+	mutex_lock(&drm->mode_config.mutex);
+	preferred = list_first_entry(&connector->modes, struct drm_display_mode, head);
+	list_for_each_entry(mode, &connector->modes, head)
+		if (mode->type & DRM_MODE_TYPE_PREFERRED)
+			preferred = mode;
+	mutex_unlock(&drm->mode_config.mutex);
+
+	return preferred;
+}
+
+static int light_up_connector(struct kunit *test,
+			      struct drm_device *drm,
+			      struct drm_crtc *crtc,
+			      struct drm_connector *connector,
+			      struct drm_display_mode *mode,
+			      struct drm_modeset_acquire_ctx *ctx)
+{
+	struct drm_atomic_state *state;
+	struct drm_connector_state *conn_state;
+	struct drm_crtc_state *crtc_state;
+	int ret;
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	conn_state = drm_atomic_get_connector_state(state, connector);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	ret = drm_atomic_set_crtc_for_connector(conn_state, crtc);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	crtc_state = drm_atomic_get_crtc_state(state, crtc);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
+
+	ret = drm_atomic_set_mode_for_crtc(crtc_state, mode);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	crtc_state->enable = true;
+	crtc_state->active = true;
+
+	ret = drm_atomic_commit(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	return 0;
+}
+
+static int set_connector_edid(struct kunit *test, struct drm_connector *connector,
+			      const char *edid, size_t edid_len)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv =
+		connector_to_priv(connector);
+	struct drm_device *drm = connector->dev;
+	int ret;
+
+	priv->current_edid = edid;
+	priv->current_edid_len = edid_len;
+
+	mutex_lock(&drm->mode_config.mutex);
+	ret = connector->funcs->fill_modes(connector, 4096, 4096);
+	mutex_unlock(&drm->mode_config.mutex);
+	KUNIT_ASSERT_GT(test, ret, 0);
+
+	return 0;
+}
+
+static int dummy_connector_get_modes(struct drm_connector *connector)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv =
+		connector_to_priv(connector);
+	const struct drm_edid *edid;
+	unsigned int num_modes;
+
+	edid = drm_edid_alloc(priv->current_edid, priv->current_edid_len);
+	if (!edid)
+		return -EINVAL;
+
+	drm_edid_connector_update(connector, edid);
+	num_modes = drm_edid_connector_add_modes(connector);
+
+	drm_edid_free(edid);
+
+	return num_modes;
+}
+
+static const struct drm_connector_helper_funcs dummy_connector_helper_funcs = {
+	.atomic_check	= drm_atomic_helper_connector_hdmi_check,
+	.get_modes	= dummy_connector_get_modes,
+};
+
+static void dummy_hdmi_connector_reset(struct drm_connector *connector)
+{
+	drm_atomic_helper_connector_reset(connector);
+	__drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
+}
+
+static const struct drm_connector_funcs dummy_connector_funcs = {
+	.atomic_destroy_state	= drm_atomic_helper_connector_destroy_state,
+	.atomic_duplicate_state	= drm_atomic_helper_connector_duplicate_state,
+	.fill_modes		= drm_helper_probe_single_connector_modes,
+	.reset			= dummy_hdmi_connector_reset,
+};
+
+static
+struct drm_atomic_helper_connector_hdmi_priv *
+drm_atomic_helper_connector_hdmi_init(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_connector *conn;
+	struct drm_encoder *enc;
+	struct drm_device *drm;
+	struct device *dev;
+	int ret;
+
+	dev = drm_kunit_helper_alloc_device(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dev);
+
+	priv = drm_kunit_helper_alloc_drm_device(test, dev,
+						 struct drm_atomic_helper_connector_hdmi_priv, drm,
+						 DRIVER_MODESET | DRIVER_ATOMIC);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
+	test->priv = priv;
+
+	drm = &priv->drm;
+	priv->plane = drm_kunit_helper_create_primary_plane(test, drm,
+							    NULL,
+							    NULL,
+							    NULL, 0,
+							    NULL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->plane);
+
+	priv->crtc = drm_kunit_helper_create_crtc(test, drm,
+						  priv->plane, NULL,
+						  NULL,
+						  NULL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->crtc);
+
+	enc = &priv->encoder;
+	ret = drmm_encoder_init(drm, enc, NULL, DRM_MODE_ENCODER_TMDS, NULL);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	enc->possible_crtcs = drm_crtc_mask(priv->crtc);
+
+	conn = &priv->connector;
+	ret = drmm_connector_hdmi_init(drm, conn,
+				       &dummy_connector_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       NULL);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	drm_connector_helper_add(conn, &dummy_connector_helper_funcs);
+	drm_connector_attach_encoder(conn, enc);
+
+	drm_mode_config_reset(drm);
+
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_max_200mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_200mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	return priv;
+}
+
+/*
+ * Test that if we change the RGB quantization property to a different
+ * value, we trigger a mode change on the connector's CRTC, which will
+ * in turn disable/enable the connector.
+ */
+static void drm_test_check_broadcast_rgb_crtc_mode_changed(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *old_conn_state;
+	struct drm_connector_state *new_conn_state;
+	struct drm_crtc_state *crtc_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	conn = &priv->connector;
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	new_conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
+
+	old_conn_state = drm_atomic_get_old_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
+
+	new_conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_FULL;
+
+	KUNIT_ASSERT_NE(test,
+			old_conn_state->hdmi.broadcast_rgb,
+			new_conn_state->hdmi.broadcast_rgb);
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	new_conn_state = drm_atomic_get_new_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
+	KUNIT_EXPECT_EQ(test, new_conn_state->hdmi.broadcast_rgb, DRM_HDMI_BROADCAST_RGB_FULL);
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
+	KUNIT_EXPECT_TRUE(test, crtc_state->mode_changed);
+}
+
+/*
+ * Test that if we set the RGB quantization property to the same value,
+ * we don't trigger a mode change on the connector's CRTC and leave the
+ * connector unaffected.
+ */
+static void drm_test_check_broadcast_rgb_crtc_mode_not_changed(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *old_conn_state;
+	struct drm_connector_state *new_conn_state;
+	struct drm_crtc_state *crtc_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	conn = &priv->connector;
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	new_conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
+
+	old_conn_state = drm_atomic_get_old_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
+
+	new_conn_state->hdmi.broadcast_rgb = old_conn_state->hdmi.broadcast_rgb;
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	old_conn_state = drm_atomic_get_old_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
+
+	new_conn_state = drm_atomic_get_new_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
+
+	KUNIT_EXPECT_EQ(test,
+			old_conn_state->hdmi.broadcast_rgb,
+			new_conn_state->hdmi.broadcast_rgb);
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
+	KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
+}
+
+static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
+	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
+	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
+	{ }
+};
+
+static struct kunit_suite drm_atomic_helper_connector_hdmi_check_test_suite = {
+	.name		= "drm_atomic_helper_connector_hdmi_check",
+	.test_cases	= drm_atomic_helper_connector_hdmi_check_tests,
+};
+
+/*
+ * Test that the value of the Broadcast RGB property out of reset is set
+ * to auto.
+ */
+static void drm_test_check_broadcast_rgb_value(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_connector_state *conn_state;
+	struct drm_connector *conn;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	conn_state = conn->state;
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.broadcast_rgb, DRM_HDMI_BROADCAST_RGB_AUTO);
+}
+
+static struct kunit_case drm_atomic_helper_connector_hdmi_reset_tests[] = {
+	KUNIT_CASE(drm_test_check_broadcast_rgb_value),
+	{ }
+};
+
+static struct kunit_suite drm_atomic_helper_connector_hdmi_reset_test_suite = {
+	.name		= "drm_atomic_helper_connector_hdmi_reset",
+	.test_cases 	= drm_atomic_helper_connector_hdmi_reset_tests,
+};
+
+kunit_test_suites(
+	&drm_atomic_helper_connector_hdmi_check_test_suite,
+	&drm_atomic_helper_connector_hdmi_reset_test_suite,
+);
+
+MODULE_AUTHOR("Maxime Ripard <mripard at kernel.org>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
index 8f070cacab3b..41d33dea30af 100644
--- a/drivers/gpu/drm/tests/drm_connector_test.c
+++ b/drivers/gpu/drm/tests/drm_connector_test.c
@@ -12,6 +12,8 @@
 
 #include <kunit/test.h>
 
+#include "../drm_crtc_internal.h"
+
 struct drm_connector_init_priv {
 	struct drm_device drm;
 	struct drm_connector connector;
@@ -357,10 +359,123 @@ static struct kunit_suite drm_get_tv_mode_from_name_test_suite = {
 	.test_cases = drm_get_tv_mode_from_name_tests,
 };
 
+struct drm_hdmi_connector_get_broadcast_rgb_name_test {
+	unsigned int kind;
+	const char *expected_name;
+};
+
+#define BROADCAST_RGB_TEST(_kind, _name)	\
+	{					\
+		.kind = _kind,			\
+		.expected_name = _name,		\
+	}
+
+static void drm_test_drm_hdmi_connector_get_broadcast_rgb_name(struct kunit *test)
+{
+	const struct drm_hdmi_connector_get_broadcast_rgb_name_test *params =
+		test->param_value;
+
+	KUNIT_EXPECT_STREQ(test,
+			   drm_hdmi_connector_get_broadcast_rgb_name(params->kind),
+			   params->expected_name);
+}
+
+static const
+struct drm_hdmi_connector_get_broadcast_rgb_name_test
+drm_hdmi_connector_get_broadcast_rgb_name_valid_tests[] = {
+	BROADCAST_RGB_TEST(DRM_HDMI_BROADCAST_RGB_AUTO, "Automatic"),
+	BROADCAST_RGB_TEST(DRM_HDMI_BROADCAST_RGB_FULL, "Full"),
+	BROADCAST_RGB_TEST(DRM_HDMI_BROADCAST_RGB_LIMITED, "Limited 16:235"),
+};
+
+static void
+drm_hdmi_connector_get_broadcast_rgb_name_valid_desc(const struct drm_hdmi_connector_get_broadcast_rgb_name_test *t,
+						     char *desc)
+{
+	sprintf(desc, "%s", t->expected_name);
+}
+
+KUNIT_ARRAY_PARAM(drm_hdmi_connector_get_broadcast_rgb_name_valid,
+		  drm_hdmi_connector_get_broadcast_rgb_name_valid_tests,
+		  drm_hdmi_connector_get_broadcast_rgb_name_valid_desc);
+
+static void drm_test_drm_hdmi_connector_get_broadcast_rgb_name_invalid(struct kunit *test)
+{
+	KUNIT_EXPECT_NULL(test, drm_hdmi_connector_get_broadcast_rgb_name(3));
+};
+
+static struct kunit_case drm_hdmi_connector_get_broadcast_rgb_name_tests[] = {
+	KUNIT_CASE_PARAM(drm_test_drm_hdmi_connector_get_broadcast_rgb_name,
+			 drm_hdmi_connector_get_broadcast_rgb_name_valid_gen_params),
+	KUNIT_CASE(drm_test_drm_hdmi_connector_get_broadcast_rgb_name_invalid),
+	{ }
+};
+
+static struct kunit_suite drm_hdmi_connector_get_broadcast_rgb_name_test_suite = {
+	.name = "drm_hdmi_connector_get_broadcast_rgb_name",
+	.test_cases = drm_hdmi_connector_get_broadcast_rgb_name_tests,
+};
+
+static void drm_test_drm_connector_attach_broadcast_rgb_property(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_property *prop;
+	int ret;
+
+	ret = drmm_connector_init(&priv->drm, connector,
+				  &dummy_funcs,
+				  DRM_MODE_CONNECTOR_HDMIA,
+				  &priv->ddc);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	ret = drm_connector_attach_broadcast_rgb_property(connector);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	prop = connector->broadcast_rgb_property;
+	KUNIT_ASSERT_NOT_NULL(test, prop);
+	KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
+}
+
+static void drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_property *prop;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	ret = drm_connector_attach_broadcast_rgb_property(connector);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	prop = connector->broadcast_rgb_property;
+	KUNIT_ASSERT_NOT_NULL(test, prop);
+	KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
+}
+
+static struct kunit_case drm_connector_attach_broadcast_rgb_property_tests[] = {
+	KUNIT_CASE(drm_test_drm_connector_attach_broadcast_rgb_property),
+	KUNIT_CASE(drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector),
+	{ }
+};
+
+static struct kunit_suite drm_connector_attach_broadcast_rgb_property_test_suite = {
+	.name = "drm_connector_attach_broadcast_rgb_property",
+	.init = drm_test_connector_init,
+	.test_cases = drm_connector_attach_broadcast_rgb_property_tests,
+};
+
 kunit_test_suites(
 	&drmm_connector_hdmi_init_test_suite,
 	&drmm_connector_init_test_suite,
-	&drm_get_tv_mode_from_name_test_suite
+	&drm_connector_attach_broadcast_rgb_property_test_suite,
+	&drm_get_tv_mode_from_name_test_suite,
+	&drm_hdmi_connector_get_broadcast_rgb_name_test_suite
 );
 
 MODULE_AUTHOR("Maxime Ripard <maxime at cerno.tech>");
diff --git a/drivers/gpu/drm/tests/drm_kunit_edid.h b/drivers/gpu/drm/tests/drm_kunit_edid.h
new file mode 100644
index 000000000000..2bba316de064
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_kunit_edid.h
@@ -0,0 +1,106 @@
+#ifndef DRM_KUNIT_EDID_H_
+#define DRM_KUNIT_EDID_H_
+
+/*
+ * edid-decode (hex):
+ *
+ * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
+ * 00 21 01 03 81 a0 5a 78 02 00 00 00 00 00 00 00
+ * 00 00 00 20 00 00 01 01 01 01 01 01 01 01 01 01
+ * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
+ * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
+ * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
+ * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 92
+ *
+ * 02 03 1b 81 e3 05 00 20 41 10 e2 00 4a 6d 03 0c
+ * 00 12 34 00 28 20 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0
+ *
+ * ----------------
+ *
+ * Block 0, Base EDID:
+ *   EDID Structure Version & Revision: 1.3
+ *   Vendor & Product Identification:
+ *     Manufacturer: LNX
+ *     Model: 42
+ *     Made in: 2023
+ *   Basic Display Parameters & Features:
+ *     Digital display
+ *     DFP 1.x compatible TMDS
+ *     Maximum image size: 160 cm x 90 cm
+ *     Gamma: 2.20
+ *     Monochrome or grayscale display
+ *     First detailed timing is the preferred timing
+ *   Color Characteristics:
+ *     Red  : 0.0000, 0.0000
+ *     Green: 0.0000, 0.0000
+ *     Blue : 0.0000, 0.0000
+ *     White: 0.0000, 0.0000
+ *   Established Timings I & II:
+ *     DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
+ *   Standard Timings: none
+ *   Detailed Timing Descriptors:
+ *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
+ *                  Hfront   88 Hsync  44 Hback  148 Hpol P
+ *                  Vfront    4 Vsync   5 Vback   36 Vpol P
+ *     Display Product Name: 'Test EDID'
+ *     Display Range Limits:
+ *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
+ *     Dummy Descriptor:
+ *   Extension blocks: 1
+ * Checksum: 0x92
+ *
+ * ----------------
+ *
+ * Block 1, CTA-861 Extension Block:
+ *   Revision: 3
+ *   Underscans IT Video Formats by default
+ *   Native detailed modes: 1
+ *   Colorimetry Data Block:
+ *     sRGB
+ *   Video Data Block:
+ *     VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
+ *   Video Capability Data Block:
+ *     YCbCr quantization: No Data
+ *     RGB quantization: Selectable (via AVI Q)
+ *     PT scan behavior: No Data
+ *     IT scan behavior: Always Underscanned
+ *     CE scan behavior: Always Underscanned
+ *   Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
+ *     Source physical address: 1.2.3.4
+ *     Maximum TMDS clock: 200 MHz
+ *     Extended HDMI video details:
+ * Checksum: 0xd0  Unused space in Extension Block: 100 bytes
+ */
+const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz[] = {
+  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
+  0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20,
+  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
+  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
+  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
+  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
+  0x46, 0x00, 0x00, 0xc4, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
+  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x41, 0x02, 0x03, 0x1b, 0x81,
+  0xe3, 0x05, 0x00, 0x20, 0x41, 0x10, 0xe2, 0x00, 0x4a, 0x6d, 0x03, 0x0c,
+  0x00, 0x12, 0x34, 0x00, 0x28, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0xd0
+};
+
+#endif // DRM_KUNIT_EDID_H_
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 000a2a156619..3867a4c01b78 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -368,6 +368,30 @@ enum drm_panel_orientation {
 	DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
 };
 
+/**
+ * enum drm_hdmi_broadcast_rgb - Broadcast RGB Selection for an HDMI @drm_connector
+ */
+enum drm_hdmi_broadcast_rgb {
+	/**
+	 * @DRM_HDMI_BROADCAST_RGB_AUTO: The RGB range is selected
+	 * automatically based on the mode.
+	 */
+	DRM_HDMI_BROADCAST_RGB_AUTO,
+
+	/**
+	 * @DRM_HDMI_BROADCAST_RGB_FULL: Full range RGB is forced.
+	 */
+	DRM_HDMI_BROADCAST_RGB_FULL,
+
+	/**
+	 * @DRM_HDMI_BROADCAST_RGB_LIMITED: Limited range RGB is forced.
+	 */
+	DRM_HDMI_BROADCAST_RGB_LIMITED,
+};
+
+const char *
+drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_rgb);
+
 /**
  * struct drm_monitor_range_info - Panel's Monitor range in EDID for
  * &drm_display_info
@@ -1037,6 +1061,11 @@ struct drm_connector_state {
 	 * @drm_atomic_helper_connector_hdmi_check().
 	 */
 	struct {
+		/**
+		 * @broadcast_rgb: Connector property to pass the
+		 * Broadcast RGB selection value.
+		 */
+		enum drm_hdmi_broadcast_rgb broadcast_rgb;
 	} hdmi;
 };
 
@@ -1706,6 +1735,12 @@ struct drm_connector {
 	 */
 	struct drm_property *privacy_screen_hw_state_property;
 
+	/**
+	 * @broadcast_rgb_property: Connector property to set the
+	 * Broadcast RGB selection to output with.
+	 */
+	struct drm_property *broadcast_rgb_property;
+
 #define DRM_CONNECTOR_POLL_HPD (1 << 0)
 #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
 #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -2026,6 +2061,7 @@ int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
 					       u32 scaling_mode_mask);
 int drm_connector_attach_vrr_capable_property(
 		struct drm_connector *connector);
+int drm_connector_attach_broadcast_rgb_property(struct drm_connector *connector);
 int drm_connector_attach_colorspace_property(struct drm_connector *connector);
 int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *connector);
 bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state *old_state,

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:32 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:32 +0100
Subject: [PATCH v5 09/44] drm/connector: hdmi: Add RGB Quantization Range
 to the connector state
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-9-6538e19d634d@kernel.org>

HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_atomic.c                       |   4 +-
 drivers/gpu/drm/drm_atomic_state_helper.c          |  44 +++
 .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 335 +++++++++++++++++++++
 include/drm/drm_atomic_state_helper.h              |   1 +
 include/drm/drm_connector.h                        |   6 +
 5 files changed, 389 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1465a7f09a0b..e4ad53e64e07 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1143,9 +1143,11 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
 	drm_printf(p, "\tcolorspace=%s\n", drm_get_colorspace_name(state->colorspace));
 
 	if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
-	    connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)
+	    connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
 		drm_printf(p, "\tbroadcast_rgb=%s\n",
 			   drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
+		drm_printf(p, "\tis_full_range=%c\n", state->hdmi.is_full_range ? 'y' : 'n');
+	}
 
 	if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
 		if (state->writeback_job && state->writeback_job->fb)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 10d98620a358..4a7114978c47 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -31,6 +31,7 @@
 #include <drm/drm_connector.h>
 #include <drm/drm_crtc.h>
 #include <drm/drm_device.h>
+#include <drm/drm_edid.h>
 #include <drm/drm_framebuffer.h>
 #include <drm/drm_plane.h>
 #include <drm/drm_print.h>
@@ -636,6 +637,47 @@ int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
 
+static const struct drm_display_mode *
+connector_state_get_mode(const struct drm_connector_state *conn_state)
+{
+	struct drm_atomic_state *state;
+	struct drm_crtc_state *crtc_state;
+	struct drm_crtc *crtc;
+
+	state = conn_state->state;
+	if (!state)
+		return NULL;
+
+	crtc = conn_state->crtc;
+	if (!crtc)
+		return NULL;
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+	if (!crtc_state)
+		return NULL;
+
+	return &crtc_state->mode;
+}
+
+static bool hdmi_is_full_range(const struct drm_connector *connector,
+			       const struct drm_connector_state *state)
+{
+	const struct drm_display_info *display = &connector->display_info;
+	const struct drm_display_mode *mode =
+		connector_state_get_mode(state);
+
+	if (state->hdmi.broadcast_rgb == DRM_HDMI_BROADCAST_RGB_FULL)
+		return true;
+
+	if (state->hdmi.broadcast_rgb == DRM_HDMI_BROADCAST_RGB_LIMITED)
+		return false;
+
+	if (!display->is_hdmi)
+		return true;
+
+	return drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_FULL ? true : false;
+}
+
 /**
  * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
  * @connector: DRM Connector
@@ -656,6 +698,8 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
 	struct drm_connector_state *new_state =
 		drm_atomic_get_new_connector_state(state, connector);
 
+	new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
+
 	if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb) {
 		struct drm_crtc *crtc = new_state->crtc;
 		struct drm_crtc_state *crtc_state;
diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
index 21e6f796ee13..7750c3d214a4 100644
--- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
@@ -328,7 +328,342 @@ static void drm_test_check_broadcast_rgb_crtc_mode_not_changed(struct kunit *tes
 	KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
 }
 
+/*
+ * Test that for an HDMI connector, with an HDMI monitor, if the
+ * Broadcast RGB property is set to auto with a mode that isn't the
+ * VIC-1 mode, we will get a limited RGB Quantization Range.
+ */
+static void drm_test_check_broadcast_rgb_auto_cea_mode(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+	KUNIT_ASSERT_NE(test, drm_match_cea_mode(preferred), 1);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	KUNIT_ASSERT_EQ(test,
+			conn_state->hdmi.broadcast_rgb,
+			DRM_HDMI_BROADCAST_RGB_AUTO);
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	KUNIT_EXPECT_FALSE(test, conn_state->hdmi.is_full_range);
+}
+
+/*
+ * Test that for an HDMI connector, with an HDMI monitor, if the
+ * Broadcast RGB property is set to auto with a VIC-1 mode, we will get
+ * a full RGB Quantization Range.
+ */
+static void drm_test_check_broadcast_rgb_auto_cea_mode_vic_1(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *mode;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	mode = drm_display_mode_from_cea_vic(drm, 1);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, mode, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	KUNIT_ASSERT_EQ(test,
+			conn_state->hdmi.broadcast_rgb,
+			DRM_HDMI_BROADCAST_RGB_AUTO);
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	KUNIT_EXPECT_TRUE(test, conn_state->hdmi.is_full_range);
+}
+
+/*
+ * Test that for an HDMI connector, with an HDMI monitor, if the
+ * Broadcast RGB property is set to full with a mode that isn't the
+ * VIC-1 mode, we will get a full RGB Quantization Range.
+ */
+static void drm_test_check_broadcast_rgb_full_cea_mode(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+	KUNIT_ASSERT_NE(test, drm_match_cea_mode(preferred), 1);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_FULL;
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	KUNIT_ASSERT_EQ(test,
+			conn_state->hdmi.broadcast_rgb,
+			DRM_HDMI_BROADCAST_RGB_FULL);
+
+	KUNIT_EXPECT_TRUE(test, conn_state->hdmi.is_full_range);
+}
+
+/*
+ * Test that for an HDMI connector, with an HDMI monitor, if the
+ * Broadcast RGB property is set to full with a VIC-1 mode, we will get
+ * a full RGB Quantization Range.
+ */
+static void drm_test_check_broadcast_rgb_full_cea_mode_vic_1(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *mode;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	mode = drm_display_mode_from_cea_vic(drm, 1);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, mode, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_FULL;
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	KUNIT_ASSERT_EQ(test,
+			conn_state->hdmi.broadcast_rgb,
+			DRM_HDMI_BROADCAST_RGB_FULL);
+
+	KUNIT_EXPECT_TRUE(test, conn_state->hdmi.is_full_range);
+}
+
+/*
+ * Test that for an HDMI connector, with an HDMI monitor, if the
+ * Broadcast RGB property is set to limited with a mode that isn't the
+ * VIC-1 mode, we will get a limited RGB Quantization Range.
+ */
+static void drm_test_check_broadcast_rgb_limited_cea_mode(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+	KUNIT_ASSERT_NE(test, drm_match_cea_mode(preferred), 1);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_LIMITED;
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	KUNIT_ASSERT_EQ(test,
+			conn_state->hdmi.broadcast_rgb,
+			DRM_HDMI_BROADCAST_RGB_LIMITED);
+
+	KUNIT_EXPECT_FALSE(test, conn_state->hdmi.is_full_range);
+}
+
+/*
+ * Test that for an HDMI connector, with an HDMI monitor, if the
+ * Broadcast RGB property is set to limited with a VIC-1 mode, we will
+ * get a limited RGB Quantization Range.
+ */
+static void drm_test_check_broadcast_rgb_limited_cea_mode_vic_1(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *mode;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	mode = drm_display_mode_from_cea_vic(drm, 1);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, mode, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_LIMITED;
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+	KUNIT_ASSERT_EQ(test,
+			conn_state->hdmi.broadcast_rgb,
+			DRM_HDMI_BROADCAST_RGB_LIMITED);
+
+	KUNIT_EXPECT_FALSE(test, conn_state->hdmi.is_full_range);
+}
+
 static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
+	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
+	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
+	KUNIT_CASE(drm_test_check_broadcast_rgb_full_cea_mode),
+	KUNIT_CASE(drm_test_check_broadcast_rgb_full_cea_mode_vic_1),
+	KUNIT_CASE(drm_test_check_broadcast_rgb_limited_cea_mode),
+	KUNIT_CASE(drm_test_check_broadcast_rgb_limited_cea_mode_vic_1),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
 	{ }
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index d59d2b3aef9a..8072ac18e536 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -88,6 +88,7 @@ void
 __drm_atomic_helper_connector_destroy_state(struct drm_connector_state *state);
 void drm_atomic_helper_connector_destroy_state(struct drm_connector *connector,
 					  struct drm_connector_state *state);
+
 void __drm_atomic_helper_private_obj_duplicate_state(struct drm_private_obj *obj,
 						     struct drm_private_state *state);
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3867a4c01b78..76eecd449fb8 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1066,6 +1066,12 @@ struct drm_connector_state {
 		 * Broadcast RGB selection value.
 		 */
 		enum drm_hdmi_broadcast_rgb broadcast_rgb;
+
+		/**
+		 * @is_full_range: Is the output supposed to use a full
+		 * RGB Quantization Range or not?
+		 */
+		bool is_full_range;
 	} hdmi;
 };
 

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:33 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:33 +0100
Subject: [PATCH v5 10/44] drm/connector: hdmi: Add output BPC to the
 connector state
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-10-6538e19d634d@kernel.org>

We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_atomic.c                       |   1 +
 drivers/gpu/drm/drm_atomic_state_helper.c          |   7 +-
 drivers/gpu/drm/drm_connector.c                    |  20 +-
 .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 227 ++++++++++++++++++++-
 drivers/gpu/drm/tests/drm_connector_test.c         | 153 +++++++++++++-
 include/drm/drm_connector.h                        |  13 +-
 6 files changed, 402 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e4ad53e64e07..76c63ed04af4 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1147,6 +1147,7 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
 		drm_printf(p, "\tbroadcast_rgb=%s\n",
 			   drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
 		drm_printf(p, "\tis_full_range=%c\n", state->hdmi.is_full_range ? 'y' : 'n');
+		drm_printf(p, "\toutput_bpc=%u\n", state->hdmi.output_bpc);
 	}
 
 	if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 4a7114978c47..883bdc0349c0 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -584,6 +584,10 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
 void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
 					      struct drm_connector_state *new_state)
 {
+	unsigned int max_bpc = connector->max_bpc;
+
+	new_state->max_bpc = max_bpc;
+	new_state->max_requested_bpc = max_bpc;
 	new_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
@@ -700,7 +704,8 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
 
 	new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
 
-	if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb) {
+	if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb ||
+	    old_state->hdmi.output_bpc != new_state->hdmi.output_bpc) {
 		struct drm_crtc *crtc = new_state->crtc;
 		struct drm_crtc_state *crtc_state;
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 929b0a911f62..139ac3d8160c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -459,6 +459,7 @@ EXPORT_SYMBOL(drmm_connector_init);
  * @funcs: callbacks for this connector
  * @connector_type: user visible type of the connector
  * @ddc: optional pointer to the associated ddc adapter
+ * @max_bpc: Maximum bits per char the HDMI connector supports
  *
  * Initialises a preallocated HDMI connector. Connectors can be
  * subclassed as part of driver connector objects.
@@ -475,7 +476,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 			     struct drm_connector *connector,
 			     const struct drm_connector_funcs *funcs,
 			     int connector_type,
-			     struct i2c_adapter *ddc)
+			     struct i2c_adapter *ddc,
+			     unsigned int max_bpc)
 {
 	int ret;
 
@@ -483,10 +485,26 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 	      connector_type == DRM_MODE_CONNECTOR_HDMIB))
 		return -EINVAL;
 
+	if (!(max_bpc == 8 || max_bpc == 10 || max_bpc == 12))
+		return -EINVAL;
+
 	ret = drmm_connector_init(dev, connector, funcs, connector_type, ddc);
 	if (ret)
 		return ret;
 
+	/*
+	 * drm_connector_attach_max_bpc_property() requires the
+	 * connector to have a state.
+	 */
+	if (connector->funcs->reset)
+		connector->funcs->reset(connector);
+
+	drm_connector_attach_max_bpc_property(connector, 8, max_bpc);
+	connector->max_bpc = max_bpc;
+
+	if (max_bpc > 8)
+		drm_connector_attach_hdr_output_metadata_property(connector);
+
 	return 0;
 }
 EXPORT_SYMBOL(drmm_connector_hdmi_init);
diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
index 7750c3d214a4..a1b0e6914cf8 100644
--- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
@@ -146,7 +146,8 @@ static const struct drm_connector_funcs dummy_connector_funcs = {
 
 static
 struct drm_atomic_helper_connector_hdmi_priv *
-drm_atomic_helper_connector_hdmi_init(struct kunit *test)
+drm_atomic_helper_connector_hdmi_init(struct kunit *test,
+				      unsigned int max_bpc)
 {
 	struct drm_atomic_helper_connector_hdmi_priv *priv;
 	struct drm_connector *conn;
@@ -188,7 +189,8 @@ drm_atomic_helper_connector_hdmi_init(struct kunit *test)
 	ret = drmm_connector_hdmi_init(drm, conn,
 				       &dummy_connector_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
-				       NULL);
+				       NULL,
+				       max_bpc);
 	KUNIT_ASSERT_EQ(test, ret, 0);
 
 	drm_connector_helper_add(conn, &dummy_connector_helper_funcs);
@@ -223,7 +225,7 @@ static void drm_test_check_broadcast_rgb_crtc_mode_changed(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test);
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
@@ -284,7 +286,7 @@ static void drm_test_check_broadcast_rgb_crtc_mode_not_changed(struct kunit *tes
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test);
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
@@ -345,7 +347,7 @@ static void drm_test_check_broadcast_rgb_auto_cea_mode(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test);
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -399,7 +401,7 @@ static void drm_test_check_broadcast_rgb_auto_cea_mode_vic_1(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test);
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -452,7 +454,7 @@ static void drm_test_check_broadcast_rgb_full_cea_mode(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test);
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -508,7 +510,7 @@ static void drm_test_check_broadcast_rgb_full_cea_mode_vic_1(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test);
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -563,7 +565,7 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test);
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -619,7 +621,7 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode_vic_1(struct kunit *te
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test);
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -657,6 +659,138 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode_vic_1(struct kunit *te
 	KUNIT_EXPECT_FALSE(test, conn_state->hdmi.is_full_range);
 }
 
+/*
+ * Test that if we change the maximum bpc property to a different value,
+ * we trigger a mode change on the connector's CRTC, which will in turn
+ * disable/enable the connector.
+ */
+static void drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *old_conn_state;
+	struct drm_connector_state *new_conn_state;
+	struct drm_crtc_state *crtc_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test, 10);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	conn = &priv->connector;
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	new_conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
+
+	old_conn_state = drm_atomic_get_old_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
+
+	new_conn_state->hdmi.output_bpc = 8;
+
+	KUNIT_ASSERT_NE(test,
+			old_conn_state->hdmi.output_bpc,
+			new_conn_state->hdmi.output_bpc);
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	old_conn_state = drm_atomic_get_old_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
+
+	new_conn_state = drm_atomic_get_new_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
+
+	KUNIT_ASSERT_NE(test,
+			old_conn_state->hdmi.output_bpc,
+			new_conn_state->hdmi.output_bpc);
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
+	KUNIT_EXPECT_TRUE(test, crtc_state->mode_changed);
+}
+
+/*
+ * Test that if we set the output bpc property to the same value, we
+ * don't trigger a mode change on the connector's CRTC and leave the
+ * connector unaffected.
+ */
+static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *old_conn_state;
+	struct drm_connector_state *new_conn_state;
+	struct drm_crtc_state *crtc_state;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test, 10);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	conn = &priv->connector;
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	new_conn_state = drm_atomic_get_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
+
+	old_conn_state = drm_atomic_get_old_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
+
+	KUNIT_ASSERT_EQ(test,
+			new_conn_state->hdmi.output_bpc,
+			old_conn_state->hdmi.output_bpc);
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	old_conn_state = drm_atomic_get_old_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
+
+	new_conn_state = drm_atomic_get_new_connector_state(state, conn);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
+
+	KUNIT_EXPECT_EQ(test,
+			old_conn_state->hdmi.output_bpc,
+			new_conn_state->hdmi.output_bpc);
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
+	KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
+}
+
 static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
@@ -666,6 +800,8 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_limited_cea_mode_vic_1),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
+	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
+	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
 	{ }
 };
 
@@ -684,7 +820,7 @@ static void drm_test_check_broadcast_rgb_value(struct kunit *test)
 	struct drm_connector_state *conn_state;
 	struct drm_connector *conn;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test);
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -692,8 +828,77 @@ static void drm_test_check_broadcast_rgb_value(struct kunit *test)
 	KUNIT_EXPECT_EQ(test, conn_state->hdmi.broadcast_rgb, DRM_HDMI_BROADCAST_RGB_AUTO);
 }
 
+/*
+ * Test that if the connector was initialised with a maximum bpc of 8,
+ * the value of the max_bpc and max_requested_bpc properties out of
+ * reset are also set to 8, and output_bpc is set to 0 and will be
+ * filled at atomic_check time.
+ */
+static void drm_test_check_bpc_8_value(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_connector_state *conn_state;
+	struct drm_connector *conn;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	conn_state = conn->state;
+	KUNIT_EXPECT_EQ(test, conn_state->max_bpc, 8);
+	KUNIT_EXPECT_EQ(test, conn_state->max_requested_bpc, 8);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 0);
+}
+
+/*
+ * Test that if the connector was initialised with a maximum bpc of 10,
+ * the value of the max_bpc and max_requested_bpc properties out of
+ * reset are also set to 10, and output_bpc is set to 0 and will be
+ * filled at atomic_check time.
+ */
+static void drm_test_check_bpc_10_value(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_connector_state *conn_state;
+	struct drm_connector *conn;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test, 10);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	conn_state = conn->state;
+	KUNIT_EXPECT_EQ(test, conn_state->max_bpc, 10);
+	KUNIT_EXPECT_EQ(test, conn_state->max_requested_bpc, 10);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 0);
+}
+
+/*
+ * Test that if the connector was initialised with a maximum bpc of 12,
+ * the value of the max_bpc and max_requested_bpc properties out of
+ * reset are also set to 12, and output_bpc is set to 0 and will be
+ * filled at atomic_check time.
+ */
+static void drm_test_check_bpc_12_value(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_connector_state *conn_state;
+	struct drm_connector *conn;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test, 12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	conn_state = conn->state;
+	KUNIT_EXPECT_EQ(test, conn_state->max_bpc, 12);
+	KUNIT_EXPECT_EQ(test, conn_state->max_requested_bpc, 12);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 0);
+}
+
 static struct kunit_case drm_atomic_helper_connector_hdmi_reset_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_value),
+	KUNIT_CASE(drm_test_check_bpc_8_value),
+	KUNIT_CASE(drm_test_check_bpc_10_value),
+	KUNIT_CASE(drm_test_check_bpc_12_value),
 	{ }
 };
 
diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
index 41d33dea30af..fef7d53d34d4 100644
--- a/drivers/gpu/drm/tests/drm_connector_test.c
+++ b/drivers/gpu/drm/tests/drm_connector_test.c
@@ -186,7 +186,8 @@ static void drm_test_connector_hdmi_init_valid(struct kunit *test)
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
-				       &priv->ddc);
+				       &priv->ddc,
+				       8);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 }
 
@@ -202,10 +203,144 @@ static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
-				       NULL);
+				       NULL,
+				       8);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 }
 
+/*
+ * Test that the registration of a connector with an invalid maximum bpc
+ * count fails.
+ */
+static void drm_test_connector_hdmi_init_bpc_invalid(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       9);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
+/*
+ * Test that the registration of a connector with a null maximum bpc
+ * count fails.
+ */
+static void drm_test_connector_hdmi_init_bpc_null(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       0);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
+/*
+ * Test that the registration of a connector with a maximum bpc count of
+ * 8 succeeds, registers the max bpc property, but doesn't register the
+ * HDR output metadata one.
+ */
+static void drm_test_connector_hdmi_init_bpc_8(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_property *prop;
+	uint64_t val;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       8);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	prop = connector->max_bpc_property;
+	KUNIT_ASSERT_NOT_NULL(test, prop);
+	KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
+
+	ret = drm_object_property_get_value(&connector->base, prop, &val);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+	KUNIT_EXPECT_EQ(test, val, 8);
+
+	prop = priv->drm.mode_config.hdr_output_metadata_property;
+	KUNIT_ASSERT_NOT_NULL(test, prop);
+	KUNIT_EXPECT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
+}
+
+/*
+ * Test that the registration of a connector with a maximum bpc count of
+ * 10 succeeds and registers the max bpc and HDR output metadata
+ * properties.
+ */
+static void drm_test_connector_hdmi_init_bpc_10(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_property *prop;
+	uint64_t val;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       10);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	prop = connector->max_bpc_property;
+	KUNIT_ASSERT_NOT_NULL(test, prop);
+	KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
+
+	ret = drm_object_property_get_value(&connector->base, prop, &val);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+	KUNIT_EXPECT_EQ(test, val, 10);
+
+	prop = priv->drm.mode_config.hdr_output_metadata_property;
+	KUNIT_ASSERT_NOT_NULL(test, prop);
+	KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
+}
+
+/*
+ * Test that the registration of a connector with a maximum bpc count of
+ * 12 succeeds and registers the max bpc and HDR output metadata
+ * properties.
+ */
+static void drm_test_connector_hdmi_init_bpc_12(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_property *prop;
+	uint64_t val;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       12);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	prop = connector->max_bpc_property;
+	KUNIT_ASSERT_NOT_NULL(test, prop);
+	KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
+
+	ret = drm_object_property_get_value(&connector->base, prop, &val);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+	KUNIT_EXPECT_EQ(test, val, 12);
+
+	prop = priv->drm.mode_config.hdr_output_metadata_property;
+	KUNIT_ASSERT_NOT_NULL(test, prop);
+	KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
+}
+
 /*
  * Test that the registration of an HDMI connector with an HDMI
  * connector type succeeds.
@@ -219,7 +354,8 @@ static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
 				       connector_type,
-				       &priv->ddc);
+				       &priv->ddc,
+				       8);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 }
 
@@ -250,7 +386,8 @@ static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
 				       connector_type,
-				       &priv->ddc);
+				       &priv->ddc,
+				       8);
 	KUNIT_EXPECT_LT(test, ret, 0);
 }
 
@@ -282,6 +419,11 @@ KUNIT_ARRAY_PARAM(drm_connector_hdmi_init_type_invalid,
 
 static struct kunit_case drmm_connector_hdmi_init_tests[] = {
 	KUNIT_CASE(drm_test_connector_hdmi_init_valid),
+	KUNIT_CASE(drm_test_connector_hdmi_init_bpc_8),
+	KUNIT_CASE(drm_test_connector_hdmi_init_bpc_10),
+	KUNIT_CASE(drm_test_connector_hdmi_init_bpc_12),
+	KUNIT_CASE(drm_test_connector_hdmi_init_bpc_invalid),
+	KUNIT_CASE(drm_test_connector_hdmi_init_bpc_null),
 	KUNIT_CASE(drm_test_connector_hdmi_init_null_ddc),
 	KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_valid,
 			 drm_connector_hdmi_init_type_valid_gen_params),
@@ -447,7 +589,8 @@ static void drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector(
 	ret = drmm_connector_hdmi_init(&priv->drm, connector,
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
-				       &priv->ddc);
+				       &priv->ddc,
+				       8);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 
 	ret = drm_connector_attach_broadcast_rgb_property(connector);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 76eecd449fb8..1b1b6aed04ee 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1072,6 +1072,11 @@ struct drm_connector_state {
 		 * RGB Quantization Range or not?
 		 */
 		bool is_full_range;
+
+		/**
+		 * @output_bpc: Bits per color channel to output.
+		 */
+		unsigned int output_bpc;
 	} hdmi;
 };
 
@@ -1717,6 +1722,11 @@ struct drm_connector {
 	 */
 	struct drm_property_blob *path_blob_ptr;
 
+	/**
+	 * @max_bpc: Maximum bits per color channel the connector supports.
+	 */
+	unsigned int max_bpc;
+
 	/**
 	 * @max_bpc_property: Default connector property for the max bpc to be
 	 * driven out of the connector.
@@ -1956,7 +1966,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 			     struct drm_connector *connector,
 			     const struct drm_connector_funcs *funcs,
 			     int connector_type,
-			     struct i2c_adapter *ddc);
+			     struct i2c_adapter *ddc,
+			     unsigned int max_bpc);
 void drm_connector_attach_edid_property(struct drm_connector *connector);
 int drm_connector_register(struct drm_connector *connector);
 void drm_connector_unregister(struct drm_connector *connector);

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:35 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:35 +0100
Subject: [PATCH v5 12/44] drm/connector: hdmi: Add HDMI compute clock
 helper
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-12-6538e19d634d@kernel.org>

A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.

Let's create a helper to provide that rate taking all parameters into
account.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_connector.c            |  59 ++++++
 drivers/gpu/drm/tests/drm_connector_test.c | 323 +++++++++++++++++++++++++++++
 include/drm/drm_connector.h                |   5 +
 3 files changed, 387 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a72f38b6dbc8..667326b09acc 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2973,6 +2973,65 @@ void drm_connector_update_privacy_screen(const struct drm_connector_state *conne
 }
 EXPORT_SYMBOL(drm_connector_update_privacy_screen);
 
+/**
+ * drm_connector_hdmi_compute_mode_clock() - Computes the TMDS Character Rate
+ * @mode: Display mode to compute the clock for
+ * @bpc: Bits per character
+ * @fmt: Output Pixel Format used
+ *
+ * Returns the TMDS Character Rate for a given mode, bpc count and output format.
+ *
+ * RETURNS:
+ * The TMDS Character Rate, in Hertz, or 0 on error.
+ */
+unsigned long long
+drm_connector_hdmi_compute_mode_clock(const struct drm_display_mode *mode,
+				      unsigned int bpc,
+				      enum hdmi_colorspace fmt)
+{
+	unsigned long long clock = mode->clock * 1000ULL;
+	unsigned int vic = drm_match_cea_mode(mode);
+
+	/*
+	 * CTA-861-G Spec, section 5.4 - Color Coding and Quantization
+	 * mandates that VIC 1 always uses 8 bpc.
+	 */
+	if (vic == 1 && bpc != 8)
+		return 0;
+
+	/*
+	 * HDMI 2.0 Spec, section 7.1 - YCbCr 4:2:0 Pixel Encoding
+	 * specifies that YUV420 encoding is only available for those
+	 * VICs.
+	 */
+	if (fmt == HDMI_COLORSPACE_YUV420 &&
+	    !(vic == 96 || vic == 97 || vic == 101 ||
+	      vic == 102 || vic == 106 || vic == 107))
+		return 0;
+
+	/*
+	 * HDMI 1.4b Spec, section 6.2.3 - Pixel Encoding Requirements
+	 * specifies that YUV422 is 36-bit only.
+	 */
+	if (fmt == HDMI_COLORSPACE_YUV422 && bpc != 12)
+		return 0;
+
+	if (fmt == HDMI_COLORSPACE_YUV420)
+		clock = clock / 2;
+
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+		clock = clock * 2;
+
+	if (fmt == HDMI_COLORSPACE_YUV422)
+		bpc = 8;
+
+	clock = clock * bpc;
+	do_div(clock, 8);
+
+	return clock;
+}
+EXPORT_SYMBOL(drm_connector_hdmi_compute_mode_clock);
+
 int drm_connector_set_obj_prop(struct drm_mode_object *obj,
 				    struct drm_property *property,
 				    uint64_t value)
diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
index fa6fe8084107..0a838924a546 100644
--- a/drivers/gpu/drm/tests/drm_connector_test.c
+++ b/drivers/gpu/drm/tests/drm_connector_test.c
@@ -8,7 +8,9 @@
 #include <drm/drm_atomic_state_helper.h>
 #include <drm/drm_connector.h>
 #include <drm/drm_drv.h>
+#include <drm/drm_edid.h>
 #include <drm/drm_kunit_helpers.h>
+#include <drm/drm_modes.h>
 
 #include <kunit/test.h>
 
@@ -719,10 +721,331 @@ static struct kunit_suite drm_connector_attach_broadcast_rgb_property_test_suite
 	.test_cases = drm_connector_attach_broadcast_rgb_property_tests,
 };
 
+/*
+ * Test that for a given mode, with 8bpc and an RGB output the TMDS
+ * character rate is equal to the mode pixel clock.
+ */
+static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	unsigned long long rate;
+	struct drm_device *drm = &priv->drm;
+
+	mode = drm_display_mode_from_cea_vic(drm, 16);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_GT(test, rate, 0);
+	KUNIT_EXPECT_EQ(test, mode->clock * 1000ULL, rate);
+}
+
+/*
+ * Test that for a given mode, with 10bpc and an RGB output the TMDS
+ * character rate is equal to 1.25 times the mode pixel clock.
+ */
+static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_10bpc(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	unsigned long long rate;
+	struct drm_device *drm = &priv->drm;
+
+	mode = drm_display_mode_from_cea_vic(drm, 16);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 10, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_GT(test, rate, 0);
+	KUNIT_EXPECT_EQ(test, mode->clock * 1250, rate);
+}
+
+/*
+ * Test that for the VIC-1 mode, with 10bpc and an RGB output the TMDS
+ * character rate computation fails.
+ */
+static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_10bpc_vic_1(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	unsigned long long rate;
+	struct drm_device *drm = &priv->drm;
+
+	mode = drm_display_mode_from_cea_vic(drm, 1);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 10, HDMI_COLORSPACE_RGB);
+	KUNIT_EXPECT_EQ(test, rate, 0);
+}
+
+/*
+ * Test that for a given mode, with 12bpc and an RGB output the TMDS
+ * character rate is equal to 1.5 times the mode pixel clock.
+ */
+static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_12bpc(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	unsigned long long rate;
+	struct drm_device *drm = &priv->drm;
+
+	mode = drm_display_mode_from_cea_vic(drm, 16);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 12, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_GT(test, rate, 0);
+	KUNIT_EXPECT_EQ(test, mode->clock * 1500, rate);
+}
+
+/*
+ * Test that for the VIC-1 mode, with 12bpc and an RGB output the TMDS
+ * character rate computation fails.
+ */
+static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_12bpc_vic_1(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	unsigned long long rate;
+	struct drm_device *drm = &priv->drm;
+
+	mode = drm_display_mode_from_cea_vic(drm, 1);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 12, HDMI_COLORSPACE_RGB);
+	KUNIT_EXPECT_EQ(test, rate, 0);
+}
+
+/*
+ * Test that for a mode with the pixel repetition flag, the TMDS
+ * character rate is indeed double the mode pixel clock.
+ */
+static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_double(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	unsigned long long rate;
+	struct drm_device *drm = &priv->drm;
+
+	mode = drm_display_mode_from_cea_vic(drm, 6);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_TRUE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_GT(test, rate, 0);
+	KUNIT_EXPECT_EQ(test, (mode->clock * 1000ULL) * 2, rate);
+}
+
+/*
+ * Test that the TMDS character rate computation for the VIC modes
+ * explicitly listed in the spec as supporting YUV420 succeed and return
+ * half the mode pixel clock.
+ */
+static void drm_test_connector_hdmi_compute_mode_clock_yuv420_valid(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	struct drm_device *drm = &priv->drm;
+	unsigned long long rate;
+	unsigned int vic = *(unsigned int *)test->param_value;
+
+	mode = drm_display_mode_from_cea_vic(drm, vic);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_YUV420);
+	KUNIT_ASSERT_GT(test, rate, 0);
+	KUNIT_EXPECT_EQ(test, (mode->clock * 1000ULL) / 2, rate);
+}
+
+static const unsigned int drm_connector_hdmi_compute_mode_clock_yuv420_vic_valid_tests[] = {
+	96, 97, 101, 102, 106, 107,
+};
+
+static void drm_connector_hdmi_compute_mode_clock_yuv420_vic_desc(const unsigned int *vic, char *desc)
+{
+	sprintf(desc, "VIC %u", *vic);
+}
+
+KUNIT_ARRAY_PARAM(drm_connector_hdmi_compute_mode_clock_yuv420_valid,
+		  drm_connector_hdmi_compute_mode_clock_yuv420_vic_valid_tests,
+		  drm_connector_hdmi_compute_mode_clock_yuv420_vic_desc);
+
+/*
+ * Test that trying to compute the TMDS char rate with the YUV420 format
+ * for a mode that doesn't support the YUV420 encoding returns an error.
+ *
+ * TODO: We should probably test this with all the VIC but the
+ * explicitly supported ones. Since the list of VIC is quite long and
+ * not linear, the best way to support it at the moment would be to
+ * create a custom gen_params function that would only return valid
+ * VICs. At the moment, that function expects to get a pointer back
+ * however, and compilers don't really like casting between integer and
+ * pointers.
+ */
+static void drm_test_connector_hdmi_compute_mode_clock_yuv420_invalid(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	struct drm_device *drm = &priv->drm;
+	unsigned long long rate;
+
+	mode = drm_display_mode_from_cea_vic(drm, 42);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_YUV420);
+	KUNIT_EXPECT_EQ(test, rate, 0);
+}
+
+/*
+ * Test that for a given mode listed supporting it and an YUV420 output
+ * with 10bpc, the TMDS character rate is equal to 0.625 times the mode
+ * pixel clock.
+ */
+static void drm_test_connector_hdmi_compute_mode_clock_yuv420_10_bpc(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	struct drm_device *drm = &priv->drm;
+	unsigned int vic =
+		drm_connector_hdmi_compute_mode_clock_yuv420_vic_valid_tests[0];
+	unsigned long long rate;
+
+	mode = drm_display_mode_from_cea_vic(drm, vic);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 10, HDMI_COLORSPACE_YUV420);
+	KUNIT_ASSERT_GT(test, rate, 0);
+
+	KUNIT_EXPECT_EQ(test, mode->clock * 625, rate);
+}
+
+/*
+ * Test that for a given mode listed supporting it and an YUV420 output
+ * with 12bpc, the TMDS character rate is equal to 0.75 times the mode
+ * pixel clock.
+ */
+static void drm_test_connector_hdmi_compute_mode_clock_yuv420_12_bpc(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	struct drm_device *drm = &priv->drm;
+	unsigned int vic =
+		drm_connector_hdmi_compute_mode_clock_yuv420_vic_valid_tests[0];
+	unsigned long long rate;
+
+	mode = drm_display_mode_from_cea_vic(drm, vic);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 12, HDMI_COLORSPACE_YUV420);
+	KUNIT_ASSERT_GT(test, rate, 0);
+
+	KUNIT_EXPECT_EQ(test, mode->clock * 750, rate);
+}
+
+/*
+ * Test that for a given mode, the computation of the TMDS character
+ * rate with 8bpc and a YUV422 output fails.
+ */
+static void drm_test_connector_hdmi_compute_mode_clock_yuv422_8_bpc(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	struct drm_device *drm = &priv->drm;
+	unsigned long long rate;
+
+	mode = drm_display_mode_from_cea_vic(drm, 16);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_YUV422);
+	KUNIT_EXPECT_EQ(test, rate, 0);
+}
+
+/*
+ * Test that for a given mode, the computation of the TMDS character
+ * rate with 10bpc and a YUV422 output fails.
+ */
+static void drm_test_connector_hdmi_compute_mode_clock_yuv422_10_bpc(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	struct drm_device *drm = &priv->drm;
+	unsigned long long rate;
+
+	mode = drm_display_mode_from_cea_vic(drm, 16);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 10, HDMI_COLORSPACE_YUV422);
+	KUNIT_EXPECT_EQ(test, rate, 0);
+}
+
+/*
+ * Test that for a given mode, the computation of the TMDS character
+ * rate with 12bpc and a YUV422 output succeeds and returns a rate equal
+ * to the mode pixel clock.
+ */
+static void drm_test_connector_hdmi_compute_mode_clock_yuv422_12_bpc(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const struct drm_display_mode *mode;
+	struct drm_device *drm = &priv->drm;
+	unsigned long long rate;
+
+	mode = drm_display_mode_from_cea_vic(drm, 16);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 12, HDMI_COLORSPACE_YUV422);
+	KUNIT_ASSERT_GT(test, rate, 0);
+	KUNIT_EXPECT_EQ(test, mode->clock * 1000, rate);
+}
+
+static struct kunit_case drm_connector_hdmi_compute_mode_clock_tests[] = {
+	KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb),
+	KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_10bpc),
+	KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_10bpc_vic_1),
+	KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_12bpc),
+	KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_12bpc_vic_1),
+	KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_double),
+	KUNIT_CASE_PARAM(drm_test_connector_hdmi_compute_mode_clock_yuv420_valid,
+			 drm_connector_hdmi_compute_mode_clock_yuv420_valid_gen_params),
+	KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv420_invalid),
+	KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv420_10_bpc),
+	KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv420_12_bpc),
+	KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv422_8_bpc),
+	KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv422_10_bpc),
+	KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv422_12_bpc),
+	{ }
+};
+
+static struct kunit_suite drm_connector_hdmi_compute_mode_clock_test_suite = {
+	.name = "drm_test_connector_hdmi_compute_mode_clock",
+	.init = drm_test_connector_init,
+	.test_cases = drm_connector_hdmi_compute_mode_clock_tests,
+};
+
 kunit_test_suites(
 	&drmm_connector_hdmi_init_test_suite,
 	&drmm_connector_init_test_suite,
 	&drm_connector_attach_broadcast_rgb_property_test_suite,
+	&drm_connector_hdmi_compute_mode_clock_test_suite,
 	&drm_get_tv_mode_from_name_test_suite,
 	&drm_hdmi_connector_get_broadcast_rgb_name_test_suite,
 	&drm_hdmi_connector_get_output_format_name_test_suite
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 74db5ce47e01..0cc5a8732664 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -38,6 +38,7 @@ struct drm_connector_helper_funcs;
 struct drm_modeset_acquire_ctx;
 struct drm_device;
 struct drm_crtc;
+struct drm_display_mode;
 struct drm_encoder;
 struct drm_panel;
 struct drm_property;
@@ -2136,6 +2137,10 @@ void drm_connector_attach_privacy_screen_properties(struct drm_connector *conn);
 void drm_connector_attach_privacy_screen_provider(
 	struct drm_connector *connector, struct drm_privacy_screen *priv);
 void drm_connector_update_privacy_screen(const struct drm_connector_state *connector_state);
+unsigned long long
+drm_connector_hdmi_compute_mode_clock(const struct drm_display_mode *mode,
+				      unsigned int bpc,
+				      enum hdmi_colorspace fmt);
 
 /**
  * struct drm_tile_group - Tile group metadata

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:34 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:34 +0100
Subject: [PATCH v5 11/44] drm/connector: hdmi: Add support for output
 format
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-11-6538e19d634d@kernel.org>

Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.

Let's add the needed defaults and fields for now.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_atomic.c                       |   2 +
 drivers/gpu/drm/drm_atomic_state_helper.c          |   3 +-
 drivers/gpu/drm/drm_connector.c                    |  31 ++++++
 .../gpu/drm/tests/drm_atomic_state_helper_test.c   |  90 ++++++++++++++---
 drivers/gpu/drm/tests/drm_connector_test.c         | 109 ++++++++++++++++++++-
 include/drm/drm_connector.h                        |  19 ++++
 6 files changed, 238 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 76c63ed04af4..7aaa2a4d70d9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1148,6 +1148,8 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
 			   drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
 		drm_printf(p, "\tis_full_range=%c\n", state->hdmi.is_full_range ? 'y' : 'n');
 		drm_printf(p, "\toutput_bpc=%u\n", state->hdmi.output_bpc);
+		drm_printf(p, "\toutput_format=%s\n",
+			   drm_hdmi_connector_get_output_format_name(state->hdmi.output_format));
 	}
 
 	if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 883bdc0349c0..92e1b087c3d0 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -705,7 +705,8 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
 	new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
 
 	if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb ||
-	    old_state->hdmi.output_bpc != new_state->hdmi.output_bpc) {
+	    old_state->hdmi.output_bpc != new_state->hdmi.output_bpc ||
+	    old_state->hdmi.output_format != new_state->hdmi.output_format) {
 		struct drm_crtc *crtc = new_state->crtc;
 		struct drm_crtc_state *crtc_state;
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 139ac3d8160c..a72f38b6dbc8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -459,6 +459,7 @@ EXPORT_SYMBOL(drmm_connector_init);
  * @funcs: callbacks for this connector
  * @connector_type: user visible type of the connector
  * @ddc: optional pointer to the associated ddc adapter
+ * @supported_formats: Bitmask of @hdmi_colorspace listing supported output formats
  * @max_bpc: Maximum bits per char the HDMI connector supports
  *
  * Initialises a preallocated HDMI connector. Connectors can be
@@ -477,6 +478,7 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 			     const struct drm_connector_funcs *funcs,
 			     int connector_type,
 			     struct i2c_adapter *ddc,
+			     unsigned long supported_formats,
 			     unsigned int max_bpc)
 {
 	int ret;
@@ -485,6 +487,9 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 	      connector_type == DRM_MODE_CONNECTOR_HDMIB))
 		return -EINVAL;
 
+	if (!supported_formats || !(supported_formats & BIT(HDMI_COLORSPACE_RGB)))
+		return -EINVAL;
+
 	if (!(max_bpc == 8 || max_bpc == 10 || max_bpc == 12))
 		return -EINVAL;
 
@@ -492,6 +497,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 	if (ret)
 		return ret;
 
+	connector->hdmi.supported_formats = supported_formats;
+
 	/*
 	 * drm_connector_attach_max_bpc_property() requires the
 	 * connector to have a state.
@@ -1224,6 +1231,30 @@ drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_
 }
 EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name);
 
+static const char * const output_format_str[] = {
+	[HDMI_COLORSPACE_RGB]		= "RGB",
+	[HDMI_COLORSPACE_YUV420]	= "YUV 4:2:0",
+	[HDMI_COLORSPACE_YUV422]	= "YUV 4:2:2",
+	[HDMI_COLORSPACE_YUV444]	= "YUV 4:4:4",
+};
+
+/*
+ * drm_hdmi_connector_get_output_format_name() - Return a string for HDMI connector output format
+ * @fmt: Output format to compute name of
+ *
+ * Returns: the name of the output format, or NULL if the type is not
+ * valid.
+ */
+const char *
+drm_hdmi_connector_get_output_format_name(enum hdmi_colorspace fmt)
+{
+	if (fmt >= ARRAY_SIZE(output_format_str))
+		return NULL;
+
+	return output_format_str[fmt];
+}
+EXPORT_SYMBOL(drm_hdmi_connector_get_output_format_name);
+
 /**
  * DOC: standard connector properties
  *
diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
index a1b0e6914cf8..4e2ec436987b 100644
--- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
@@ -147,6 +147,7 @@ static const struct drm_connector_funcs dummy_connector_funcs = {
 static
 struct drm_atomic_helper_connector_hdmi_priv *
 drm_atomic_helper_connector_hdmi_init(struct kunit *test,
+				      unsigned int formats,
 				      unsigned int max_bpc)
 {
 	struct drm_atomic_helper_connector_hdmi_priv *priv;
@@ -190,6 +191,7 @@ drm_atomic_helper_connector_hdmi_init(struct kunit *test,
 				       &dummy_connector_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       NULL,
+				       formats,
 				       max_bpc);
 	KUNIT_ASSERT_EQ(test, ret, 0);
 
@@ -225,7 +227,9 @@ static void drm_test_check_broadcast_rgb_crtc_mode_changed(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
@@ -286,7 +290,9 @@ static void drm_test_check_broadcast_rgb_crtc_mode_not_changed(struct kunit *tes
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
@@ -347,7 +353,9 @@ static void drm_test_check_broadcast_rgb_auto_cea_mode(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -401,7 +409,9 @@ static void drm_test_check_broadcast_rgb_auto_cea_mode_vic_1(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -454,7 +464,9 @@ static void drm_test_check_broadcast_rgb_full_cea_mode(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -510,7 +522,9 @@ static void drm_test_check_broadcast_rgb_full_cea_mode_vic_1(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -565,7 +579,9 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -621,7 +637,9 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode_vic_1(struct kunit *te
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -678,7 +696,9 @@ static void drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 10);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     10);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
@@ -745,7 +765,9 @@ static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
 	struct drm_crtc *crtc;
 	int ret;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 10);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     10);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
@@ -802,6 +824,15 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
 	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
 	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
+	/*
+	 * TODO: We should have tests to check that a change in the
+	 * format triggers a CRTC mode change just like we do for the
+	 * RGB Quantization and BPC.
+	 *
+	 * However, we don't have any way to control which format gets
+	 * picked up aside from changing the BPC or mode which would
+	 * already trigger a mode change.
+	 */
 	{ }
 };
 
@@ -820,7 +851,9 @@ static void drm_test_check_broadcast_rgb_value(struct kunit *test)
 	struct drm_connector_state *conn_state;
 	struct drm_connector *conn;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -840,7 +873,9 @@ static void drm_test_check_bpc_8_value(struct kunit *test)
 	struct drm_connector_state *conn_state;
 	struct drm_connector *conn;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 8);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -862,7 +897,9 @@ static void drm_test_check_bpc_10_value(struct kunit *test)
 	struct drm_connector_state *conn_state;
 	struct drm_connector *conn;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 10);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     10);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -884,7 +921,9 @@ static void drm_test_check_bpc_12_value(struct kunit *test)
 	struct drm_connector_state *conn_state;
 	struct drm_connector *conn;
 
-	priv = drm_atomic_helper_connector_hdmi_init(test, 12);
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     12);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
 	conn = &priv->connector;
@@ -894,11 +933,34 @@ static void drm_test_check_bpc_12_value(struct kunit *test)
 	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 0);
 }
 
+/*
+ * Test that the value of the output format property out of reset is set
+ * to RGB, even if the driver supports more than that.
+ */
+static void drm_test_check_format_value(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_connector_state *conn_state;
+	struct drm_connector *conn;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB) |
+						     BIT(HDMI_COLORSPACE_YUV422) |
+						     BIT(HDMI_COLORSPACE_YUV444),
+						     8);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	conn_state = conn->state;
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+}
+
 static struct kunit_case drm_atomic_helper_connector_hdmi_reset_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_value),
 	KUNIT_CASE(drm_test_check_bpc_8_value),
 	KUNIT_CASE(drm_test_check_bpc_10_value),
 	KUNIT_CASE(drm_test_check_bpc_12_value),
+	KUNIT_CASE(drm_test_check_format_value),
 	{ }
 };
 
diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
index fef7d53d34d4..fa6fe8084107 100644
--- a/drivers/gpu/drm/tests/drm_connector_test.c
+++ b/drivers/gpu/drm/tests/drm_connector_test.c
@@ -187,6 +187,7 @@ static void drm_test_connector_hdmi_init_valid(struct kunit *test)
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       8);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 }
@@ -204,6 +205,7 @@ static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       NULL,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       8);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 }
@@ -221,6 +223,7 @@ static void drm_test_connector_hdmi_init_bpc_invalid(struct kunit *test)
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       9);
 	KUNIT_EXPECT_LT(test, ret, 0);
 }
@@ -238,6 +241,7 @@ static void drm_test_connector_hdmi_init_bpc_null(struct kunit *test)
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       0);
 	KUNIT_EXPECT_LT(test, ret, 0);
 }
@@ -259,6 +263,7 @@ static void drm_test_connector_hdmi_init_bpc_8(struct kunit *test)
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       8);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 
@@ -292,6 +297,7 @@ static void drm_test_connector_hdmi_init_bpc_10(struct kunit *test)
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       10);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 
@@ -325,6 +331,7 @@ static void drm_test_connector_hdmi_init_bpc_12(struct kunit *test)
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       12);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 
@@ -341,6 +348,42 @@ static void drm_test_connector_hdmi_init_bpc_12(struct kunit *test)
 	KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
 }
 
+/*
+ * Test that the registration of an HDMI connector with no supported
+ * format fails.
+ */
+static void drm_test_connector_hdmi_init_formats_empty(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       0,
+				       8);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
+/*
+ * Test that the registration of an HDMI connector not listing RGB as a
+ * supported format fails.
+ */
+static void drm_test_connector_hdmi_init_formats_no_rgb(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       &dummy_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_YUV422),
+				       8);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
 /*
  * Test that the registration of an HDMI connector with an HDMI
  * connector type succeeds.
@@ -355,6 +398,7 @@ static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
 				       &dummy_funcs,
 				       connector_type,
 				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       8);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 }
@@ -387,6 +431,7 @@ static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
 				       &dummy_funcs,
 				       connector_type,
 				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       8);
 	KUNIT_EXPECT_LT(test, ret, 0);
 }
@@ -424,6 +469,8 @@ static struct kunit_case drmm_connector_hdmi_init_tests[] = {
 	KUNIT_CASE(drm_test_connector_hdmi_init_bpc_12),
 	KUNIT_CASE(drm_test_connector_hdmi_init_bpc_invalid),
 	KUNIT_CASE(drm_test_connector_hdmi_init_bpc_null),
+	KUNIT_CASE(drm_test_connector_hdmi_init_formats_empty),
+	KUNIT_CASE(drm_test_connector_hdmi_init_formats_no_rgb),
 	KUNIT_CASE(drm_test_connector_hdmi_init_null_ddc),
 	KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_valid,
 			 drm_connector_hdmi_init_type_valid_gen_params),
@@ -558,6 +605,64 @@ static struct kunit_suite drm_hdmi_connector_get_broadcast_rgb_name_test_suite =
 	.test_cases = drm_hdmi_connector_get_broadcast_rgb_name_tests,
 };
 
+struct drm_hdmi_connector_get_output_format_name_test {
+	unsigned int kind;
+	const char *expected_name;
+};
+
+#define OUTPUT_FORMAT_TEST(_kind, _name)	\
+	{					\
+		.kind = _kind,			\
+		.expected_name = _name,		\
+	}
+
+static void drm_test_drm_hdmi_connector_get_output_format_name(struct kunit *test)
+{
+	const struct drm_hdmi_connector_get_output_format_name_test *params =
+		test->param_value;
+
+	KUNIT_EXPECT_STREQ(test,
+			   drm_hdmi_connector_get_output_format_name(params->kind),
+			   params->expected_name);
+}
+
+static const
+struct drm_hdmi_connector_get_output_format_name_test
+drm_hdmi_connector_get_output_format_name_valid_tests[] = {
+	OUTPUT_FORMAT_TEST(HDMI_COLORSPACE_RGB, "RGB"),
+	OUTPUT_FORMAT_TEST(HDMI_COLORSPACE_YUV420, "YUV 4:2:0"),
+	OUTPUT_FORMAT_TEST(HDMI_COLORSPACE_YUV422, "YUV 4:2:2"),
+	OUTPUT_FORMAT_TEST(HDMI_COLORSPACE_YUV444, "YUV 4:4:4"),
+};
+
+static void
+drm_hdmi_connector_get_output_format_name_valid_desc(const struct drm_hdmi_connector_get_output_format_name_test *t,
+						     char *desc)
+{
+	sprintf(desc, "%s", t->expected_name);
+}
+
+KUNIT_ARRAY_PARAM(drm_hdmi_connector_get_output_format_name_valid,
+		  drm_hdmi_connector_get_output_format_name_valid_tests,
+		  drm_hdmi_connector_get_output_format_name_valid_desc);
+
+static void drm_test_drm_hdmi_connector_get_output_format_name_invalid(struct kunit *test)
+{
+	KUNIT_EXPECT_NULL(test, drm_hdmi_connector_get_output_format_name(4));
+};
+
+static struct kunit_case drm_hdmi_connector_get_output_format_name_tests[] = {
+	KUNIT_CASE_PARAM(drm_test_drm_hdmi_connector_get_output_format_name,
+			 drm_hdmi_connector_get_output_format_name_valid_gen_params),
+	KUNIT_CASE(drm_test_drm_hdmi_connector_get_output_format_name_invalid),
+	{ }
+};
+
+static struct kunit_suite drm_hdmi_connector_get_output_format_name_test_suite = {
+	.name = "drm_hdmi_connector_get_output_format_name",
+	.test_cases = drm_hdmi_connector_get_output_format_name_tests,
+};
+
 static void drm_test_drm_connector_attach_broadcast_rgb_property(struct kunit *test)
 {
 	struct drm_connector_init_priv *priv = test->priv;
@@ -590,6 +695,7 @@ static void drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector(
 				       &dummy_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
 				       8);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 
@@ -618,7 +724,8 @@ kunit_test_suites(
 	&drmm_connector_init_test_suite,
 	&drm_connector_attach_broadcast_rgb_property_test_suite,
 	&drm_get_tv_mode_from_name_test_suite,
-	&drm_hdmi_connector_get_broadcast_rgb_name_test_suite
+	&drm_hdmi_connector_get_broadcast_rgb_name_test_suite,
+	&drm_hdmi_connector_get_output_format_name_test_suite
 );
 
 MODULE_AUTHOR("Maxime Ripard <maxime at cerno.tech>");
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1b1b6aed04ee..74db5ce47e01 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -391,6 +391,8 @@ enum drm_hdmi_broadcast_rgb {
 
 const char *
 drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_rgb);
+const char *
+drm_hdmi_connector_get_output_format_name(enum hdmi_colorspace fmt);
 
 /**
  * struct drm_monitor_range_info - Panel's Monitor range in EDID for
@@ -1077,6 +1079,11 @@ struct drm_connector_state {
 		 * @output_bpc: Bits per color channel to output.
 		 */
 		unsigned int output_bpc;
+
+		/**
+		 * @output_format: Pixel format to output in.
+		 */
+		enum hdmi_colorspace output_format;
 	} hdmi;
 };
 
@@ -1944,6 +1951,17 @@ struct drm_connector {
 
 	/** @hdr_sink_metadata: HDR Metadata Information read from sink */
 	struct hdr_sink_metadata hdr_sink_metadata;
+
+	/**
+	 * @hdmi: HDMI-related variable and properties.
+	 */
+	struct {
+		/**
+		 * @supported_formats: Bitmask of @hdmi_colorspace
+		 * supported by the controller.
+		 */
+		unsigned long supported_formats;
+	} hdmi;
 };
 
 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
@@ -1967,6 +1985,7 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 			     const struct drm_connector_funcs *funcs,
 			     int connector_type,
 			     struct i2c_adapter *ddc,
+			     unsigned long supported_formats,
 			     unsigned int max_bpc);
 void drm_connector_attach_edid_property(struct drm_connector *connector);
 int drm_connector_register(struct drm_connector *connector);

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:37 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:37 +0100
Subject: [PATCH v5 14/44] drm/connector: hdmi: Add custom hook to filter
 TMDS character rate
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-14-6538e19d634d@kernel.org>

Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.

To make that easier to handle for drivers, let's provide an optional
hook to be implemented by drivers so they can tell the HDMI controller
helpers if a given TMDS character rate is reachable for them or not.

This will then be useful to figure out the best format and bpc count for
a given mode.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_atomic_state_helper.c          |  9 +++
 drivers/gpu/drm/drm_connector.c                    |  4 ++
 .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 69 ++++++++++++++++++++++
 drivers/gpu/drm/tests/drm_connector_test.c         | 15 +++++
 include/drm/drm_connector.h                        | 30 ++++++++++
 5 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 74bc3cc53c2d..a36edda590f8 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -687,11 +687,20 @@ hdmi_clock_valid(const struct drm_connector *connector,
 		 const struct drm_display_mode *mode,
 		 unsigned long long clock)
 {
+	const struct drm_connector_hdmi_funcs *funcs = connector->hdmi.funcs;
 	const struct drm_display_info *info = &connector->display_info;
 
 	if (info->max_tmds_clock && clock > info->max_tmds_clock * 1000)
 		return MODE_CLOCK_HIGH;
 
+	if (funcs && funcs->tmds_char_rate_valid) {
+		enum drm_mode_status status;
+
+		status = funcs->tmds_char_rate_valid(connector, mode, clock);
+		if (status != MODE_OK)
+			return status;
+	}
+
 	return MODE_OK;
 }
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 667326b09acc..9f314fee26ce 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -457,6 +457,7 @@ EXPORT_SYMBOL(drmm_connector_init);
  * @dev: DRM device
  * @connector: A pointer to the HDMI connector to init
  * @funcs: callbacks for this connector
+ * @hdmi_funcs: HDMI-related callbacks for this connector
  * @connector_type: user visible type of the connector
  * @ddc: optional pointer to the associated ddc adapter
  * @supported_formats: Bitmask of @hdmi_colorspace listing supported output formats
@@ -476,6 +477,7 @@ EXPORT_SYMBOL(drmm_connector_init);
 int drmm_connector_hdmi_init(struct drm_device *dev,
 			     struct drm_connector *connector,
 			     const struct drm_connector_funcs *funcs,
+			     const struct drm_connector_hdmi_funcs *hdmi_funcs,
 			     int connector_type,
 			     struct i2c_adapter *ddc,
 			     unsigned long supported_formats,
@@ -512,6 +514,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 	if (max_bpc > 8)
 		drm_connector_attach_hdr_output_metadata_property(connector);
 
+	connector->hdmi.funcs = hdmi_funcs;
+
 	return 0;
 }
 EXPORT_SYMBOL(drmm_connector_hdmi_init);
diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
index d76fafb91025..e7dbdd4a4e7f 100644
--- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
@@ -110,6 +110,21 @@ static int set_connector_edid(struct kunit *test, struct drm_connector *connecto
 	return 0;
 }
 
+static const struct drm_connector_hdmi_funcs dummy_connector_hdmi_funcs = {
+};
+
+static enum drm_mode_status
+reject_connector_tmds_char_rate_valid(const struct drm_connector *connector,
+				       const struct drm_display_mode *mode,
+				       unsigned long long tmds_rate)
+{
+	return MODE_BAD;
+}
+
+static const struct drm_connector_hdmi_funcs reject_connector_hdmi_funcs = {
+	.tmds_char_rate_valid	= reject_connector_tmds_char_rate_valid,
+};
+
 static int dummy_connector_get_modes(struct drm_connector *connector)
 {
 	struct drm_atomic_helper_connector_hdmi_priv *priv =
@@ -192,6 +207,7 @@ drm_atomic_helper_connector_hdmi_init(struct kunit *test,
 	conn = &priv->connector;
 	ret = drmm_connector_hdmi_init(drm, conn,
 				       &dummy_connector_funcs,
+				       &dummy_connector_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       NULL,
 				       formats,
@@ -956,6 +972,58 @@ static void drm_test_check_tmds_char_rate_rgb_12bpc(struct kunit *test)
 	KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1500);
 }
 
+/*
+ * Test that if we filter a rate through our hook, it's indeed rejected
+ * by the whole atomic_check logic.
+ *
+ * We do so by first doing a commit on the pipeline to make sure that it
+ * works, change the HDMI helpers pointer, and then try the same commit
+ * again to see if it fails as it should.
+ */
+static void drm_test_check_hdmi_funcs_reject_rate(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_atomic_state *state;
+	struct drm_display_mode *preferred;
+	struct drm_crtc_state *crtc_state;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	conn = &priv->connector;
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	/* You shouldn't be doing that at home. */
+	conn->hdmi.funcs = &reject_connector_hdmi_funcs;
+
+	state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+	crtc_state = drm_atomic_get_crtc_state(state, crtc);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
+
+	crtc_state->connectors_changed = true;
+
+	ret = drm_atomic_check_only(state);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
 static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
@@ -965,6 +1033,7 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_limited_cea_mode_vic_1),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
+	KUNIT_CASE(drm_test_check_hdmi_funcs_reject_rate),
 	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
 	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
 	KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_8bpc),
diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
index 0a838924a546..6a3651b08c81 100644
--- a/drivers/gpu/drm/tests/drm_connector_test.c
+++ b/drivers/gpu/drm/tests/drm_connector_test.c
@@ -22,6 +22,9 @@ struct drm_connector_init_priv {
 	struct i2c_adapter ddc;
 };
 
+static const struct drm_connector_hdmi_funcs dummy_hdmi_funcs = {
+};
+
 static const struct drm_connector_funcs dummy_funcs = {
 	.atomic_destroy_state	= drm_atomic_helper_connector_destroy_state,
 	.atomic_duplicate_state	= drm_atomic_helper_connector_duplicate_state,
@@ -187,6 +190,7 @@ static void drm_test_connector_hdmi_init_valid(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_RGB),
@@ -205,6 +209,7 @@ static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       NULL,
 				       BIT(HDMI_COLORSPACE_RGB),
@@ -223,6 +228,7 @@ static void drm_test_connector_hdmi_init_bpc_invalid(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_RGB),
@@ -241,6 +247,7 @@ static void drm_test_connector_hdmi_init_bpc_null(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_RGB),
@@ -263,6 +270,7 @@ static void drm_test_connector_hdmi_init_bpc_8(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_RGB),
@@ -297,6 +305,7 @@ static void drm_test_connector_hdmi_init_bpc_10(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_RGB),
@@ -331,6 +340,7 @@ static void drm_test_connector_hdmi_init_bpc_12(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_RGB),
@@ -361,6 +371,7 @@ static void drm_test_connector_hdmi_init_formats_empty(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
 				       0,
@@ -379,6 +390,7 @@ static void drm_test_connector_hdmi_init_formats_no_rgb(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_YUV422),
@@ -398,6 +410,7 @@ static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       connector_type,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_RGB),
@@ -431,6 +444,7 @@ static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       connector_type,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_RGB),
@@ -695,6 +709,7 @@ static void drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector(
 
 	ret = drmm_connector_hdmi_init(&priv->drm, connector,
 				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
 				       &priv->ddc,
 				       BIT(HDMI_COLORSPACE_RGB),
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 59016d9c17f5..3eaf4d54364d 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1093,6 +1093,30 @@ struct drm_connector_state {
 	} hdmi;
 };
 
+/**
+ * struct drm_connector_hdmi_funcs - drm_hdmi_connector control functions
+ */
+struct drm_connector_hdmi_funcs {
+	/**
+	 * @tmds_char_rate_valid:
+	 *
+	 * This callback is invoked at atomic_check time to figure out
+	 * whether a particular TMDS character rate is supported by the
+	 * driver.
+	 *
+	 * The @tmds_char_rate_valid callback is optional.
+	 *
+	 * Returns:
+	 *
+	 * Either &drm_mode_status.MODE_OK or one of the failure reasons
+	 * in &enum drm_mode_status.
+	 */
+	enum drm_mode_status
+	(*tmds_char_rate_valid)(const struct drm_connector *connector,
+				const struct drm_display_mode *mode,
+				unsigned long long tmds_rate);
+};
+
 /**
  * struct drm_connector_funcs - control connectors on a given device
  *
@@ -1967,6 +1991,11 @@ struct drm_connector {
 		 * supported by the controller.
 		 */
 		unsigned long supported_formats;
+
+		/**
+		 * @funcs: HDMI connector Control Functions
+		 */
+		const struct drm_connector_hdmi_funcs *funcs;
 	} hdmi;
 };
 
@@ -1989,6 +2018,7 @@ int drmm_connector_init(struct drm_device *dev,
 int drmm_connector_hdmi_init(struct drm_device *dev,
 			     struct drm_connector *connector,
 			     const struct drm_connector_funcs *funcs,
+			     const struct drm_connector_hdmi_funcs *hdmi_funcs,
 			     int connector_type,
 			     struct i2c_adapter *ddc,
 			     unsigned long supported_formats,

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:36 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:36 +0100
Subject: [PATCH v5 13/44] drm/connector: hdmi: Calculate TMDS character
 rate
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-13-6538e19d634d@kernel.org>

Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.

Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it from the HDMI connector state that stores all those infos
and remove the duplication from drivers.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_atomic.c                       |   1 +
 drivers/gpu/drm/drm_atomic_state_helper.c          |  44 +++++
 .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 169 ++++++++++++++++
 drivers/gpu/drm/tests/drm_kunit_edid.h             | 216 +++++++++++++++++++++
 include/drm/drm_connector.h                        |   5 +
 5 files changed, 435 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7aaa2a4d70d9..4f6493f91eed 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1150,6 +1150,7 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
 		drm_printf(p, "\toutput_bpc=%u\n", state->hdmi.output_bpc);
 		drm_printf(p, "\toutput_format=%s\n",
 			   drm_hdmi_connector_get_output_format_name(state->hdmi.output_format));
+		drm_printf(p, "\ttmds_char_rate=%llu\n", state->hdmi.tmds_char_rate);
 	}
 
 	if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 92e1b087c3d0..74bc3cc53c2d 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -682,6 +682,41 @@ static bool hdmi_is_full_range(const struct drm_connector *connector,
 	return drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_FULL ? true : false;
 }
 
+static enum drm_mode_status
+hdmi_clock_valid(const struct drm_connector *connector,
+		 const struct drm_display_mode *mode,
+		 unsigned long long clock)
+{
+	const struct drm_display_info *info = &connector->display_info;
+
+	if (info->max_tmds_clock && clock > info->max_tmds_clock * 1000)
+		return MODE_CLOCK_HIGH;
+
+	return MODE_OK;
+}
+
+static int
+hdmi_compute_clock(const struct drm_connector *connector,
+		   struct drm_connector_state *state,
+		   const struct drm_display_mode *mode,
+		   unsigned int bpc, enum hdmi_colorspace fmt)
+{
+	enum drm_mode_status status;
+	unsigned long long clock;
+
+	clock = drm_connector_hdmi_compute_mode_clock(mode, bpc, fmt);
+	if (!clock)
+		return -EINVAL;
+
+	status = hdmi_clock_valid(connector, mode, clock);
+	if (status != MODE_OK)
+		return -EINVAL;
+
+	state->hdmi.tmds_char_rate = clock;
+
+	return 0;
+}
+
 /**
  * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
  * @connector: DRM Connector
@@ -701,9 +736,18 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
 		drm_atomic_get_old_connector_state(state, connector);
 	struct drm_connector_state *new_state =
 		drm_atomic_get_new_connector_state(state, connector);
+	const struct drm_display_mode *mode =
+		connector_state_get_mode(new_state);
+	int ret;
 
 	new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
 
+	ret = hdmi_compute_clock(connector, new_state, mode,
+				 new_state->hdmi.output_bpc,
+				 new_state->hdmi.output_format);
+	if (ret)
+		return ret;
+
 	if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb ||
 	    old_state->hdmi.output_bpc != new_state->hdmi.output_bpc ||
 	    old_state->hdmi.output_format != new_state->hdmi.output_format) {
diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
index 4e2ec436987b..d76fafb91025 100644
--- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
@@ -70,6 +70,9 @@ static int light_up_connector(struct kunit *test,
 	conn_state = drm_atomic_get_connector_state(state, connector);
 	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
 
+	conn_state->hdmi.output_bpc = connector->max_bpc;
+	conn_state->hdmi.output_format = HDMI_COLORSPACE_RGB;
+
 	ret = drm_atomic_set_crtc_for_connector(conn_state, crtc);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 
@@ -813,6 +816,146 @@ static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
 	KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
 }
 
+/*
+ * Test that when doing a commit which would use RGB 8bpc, the TMDS
+ * clock rate stored in the connector state is equal to the mode clock
+ */
+static void drm_test_check_tmds_char_rate_rgb_8bpc(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_max_200mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_200mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+	KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_bpc, 8);
+	KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1000);
+}
+
+/*
+ * Test that when doing a commit which would use RGB 10bpc, the TMDS
+ * clock rate stored in the connector state is equal to 1.25 times the
+ * mode pixel clock
+ */
+static void drm_test_check_tmds_char_rate_rgb_10bpc(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     10);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+	KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_bpc, 10);
+	KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1250);
+}
+
+/*
+ * Test that when doing a commit which would use RGB 12bpc, the TMDS
+ * clock rate stored in the connector state is equal to 1.5 times the
+ * mode pixel clock
+ */
+static void drm_test_check_tmds_char_rate_rgb_12bpc(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+	KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_bpc, 12);
+	KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1500);
+}
+
 static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
@@ -824,6 +967,9 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
 	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
 	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
+	KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_8bpc),
+	KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_10bpc),
+	KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_12bpc),
 	/*
 	 * TODO: We should have tests to check that a change in the
 	 * format triggers a CRTC mode change just like we do for the
@@ -955,12 +1101,35 @@ static void drm_test_check_format_value(struct kunit *test)
 	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
 }
 
+/*
+ * Test that the value of the output format property out of reset is set
+ * to 0, and will be computed at atomic_check time.
+ */
+static void drm_test_check_tmds_char_value(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_connector_state *conn_state;
+	struct drm_connector *conn;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB) |
+						     BIT(HDMI_COLORSPACE_YUV422) |
+						     BIT(HDMI_COLORSPACE_YUV444),
+						     12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	conn_state = conn->state;
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, 0);
+}
+
 static struct kunit_case drm_atomic_helper_connector_hdmi_reset_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_value),
 	KUNIT_CASE(drm_test_check_bpc_8_value),
 	KUNIT_CASE(drm_test_check_bpc_10_value),
 	KUNIT_CASE(drm_test_check_bpc_12_value),
 	KUNIT_CASE(drm_test_check_format_value),
+	KUNIT_CASE(drm_test_check_tmds_char_value),
 	{ }
 };
 
diff --git a/drivers/gpu/drm/tests/drm_kunit_edid.h b/drivers/gpu/drm/tests/drm_kunit_edid.h
index 2bba316de064..24f3377ef0f0 100644
--- a/drivers/gpu/drm/tests/drm_kunit_edid.h
+++ b/drivers/gpu/drm/tests/drm_kunit_edid.h
@@ -103,4 +103,220 @@ const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz[] = {
   0x00, 0x00, 0x00, 0xd0
 };
 
+/*
+ * edid-decode (hex):
+ *
+ * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
+ * 00 21 01 03 81 a0 5a 78 1a 00 00 00 00 00 00 00
+ * 00 00 00 20 00 00 01 01 01 01 01 01 01 01 01 01
+ * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
+ * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
+ * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
+ * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 7a
+ *
+ * 02 03 1b b1 e3 05 00 20 41 10 e2 00 ca 6d 03 0c
+ * 00 12 34 78 28 20 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a8
+ *
+ * ----------------
+ *
+ * Block 0, Base EDID:
+ *   EDID Structure Version & Revision: 1.3
+ *   Vendor & Product Identification:
+ *     Manufacturer: LNX
+ *     Model: 42
+ *     Made in: 2023
+ *   Basic Display Parameters & Features:
+ *     Digital display
+ *     DFP 1.x compatible TMDS
+ *     Maximum image size: 160 cm x 90 cm
+ *     Gamma: 2.20
+ *     Undefined display color type
+ *     First detailed timing is the preferred timing
+ *   Color Characteristics:
+ *     Red  : 0.0000, 0.0000
+ *     Green: 0.0000, 0.0000
+ *     Blue : 0.0000, 0.0000
+ *     White: 0.0000, 0.0000
+ *   Established Timings I & II:
+ *     DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
+ *   Standard Timings: none
+ *   Detailed Timing Descriptors:
+ *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
+ *                  Hfront   88 Hsync  44 Hback  148 Hpol P
+ *                  Vfront    4 Vsync   5 Vback   36 Vpol P
+ *     Display Product Name: 'Test EDID'
+ *     Display Range Limits:
+ *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
+ *     Dummy Descriptor:
+ *   Extension blocks: 1
+ * Checksum: 0x7a
+ *
+ * ----------------
+ *
+ * Block 1, CTA-861 Extension Block:
+ *   Revision: 3
+ *   Underscans IT Video Formats by default
+ *   Supports YCbCr 4:4:4
+ *   Supports YCbCr 4:2:2
+ *   Native detailed modes: 1
+ *   Colorimetry Data Block:
+ *     sRGB
+ *   Video Data Block:
+ *     VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
+ *   Video Capability Data Block:
+ *     YCbCr quantization: Selectable (via AVI YQ)
+ *     RGB quantization: Selectable (via AVI Q)
+ *     PT scan behavior: No Data
+ *     IT scan behavior: Always Underscanned
+ *     CE scan behavior: Always Underscanned
+ *   Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
+ *     Source physical address: 1.2.3.4
+ *     DC_48bit
+ *     DC_36bit
+ *     DC_30bit
+ *     DC_Y444
+ *     Maximum TMDS clock: 200 MHz
+ *     Extended HDMI video details:
+ * Checksum: 0xa8  Unused space in Extension Block: 100 bytes
+ */
+const unsigned char test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz[] = {
+  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
+  0x1a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20,
+  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
+  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
+  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
+  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
+  0x46, 0x1e, 0x46, 0x0f, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
+  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x7a, 0x02, 0x03, 0x1b, 0xb1,
+  0xe3, 0x05, 0x00, 0x20, 0x41, 0x10, 0xe2, 0x00, 0xca, 0x6d, 0x03, 0x0c,
+  0x00, 0x12, 0x34, 0x78, 0x28, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0xa8
+};
+
+/*
+ * edid-decode (hex):
+ *
+ * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
+ * 00 21 01 03 81 a0 5a 78 0a 00 00 00 00 00 00 00
+ * 00 00 00 20 00 00 01 01 01 01 01 01 01 01 01 01
+ * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
+ * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
+ * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
+ * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 8a
+ *
+ * 02 03 1b b1 e3 05 00 20 41 10 e2 00 ca 6d 03 0c
+ * 00 12 34 78 44 20 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8c
+ *
+ * ----------------
+ *
+ * Block 0, Base EDID:
+ *   EDID Structure Version & Revision: 1.3
+ *   Vendor & Product Identification:
+ *     Manufacturer: LNX
+ *     Model: 42
+ *     Made in: 2023
+ *   Basic Display Parameters & Features:
+ *     Digital display
+ *     DFP 1.x compatible TMDS
+ *     Maximum image size: 160 cm x 90 cm
+ *     Gamma: 2.20
+ *     RGB color display
+ *     First detailed timing is the preferred timing
+ *   Color Characteristics:
+ *     Red  : 0.0000, 0.0000
+ *     Green: 0.0000, 0.0000
+ *     Blue : 0.0000, 0.0000
+ *     White: 0.0000, 0.0000
+ *   Established Timings I & II:
+ *     DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
+ *   Standard Timings: none
+ *   Detailed Timing Descriptors:
+ *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
+ *                  Hfront   88 Hsync  44 Hback  148 Hpol P
+ *                  Vfront    4 Vsync   5 Vback   36 Vpol P
+ *     Display Product Name: 'Test EDID'
+ *     Display Range Limits:
+ *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
+ *     Dummy Descriptor:
+ *   Extension blocks: 1
+ * Checksum: 0x8a
+ *
+ * ----------------
+ *
+ * Block 1, CTA-861 Extension Block:
+ *   Revision: 3
+ *   Underscans IT Video Formats by default
+ *   Supports YCbCr 4:4:4
+ *   Supports YCbCr 4:2:2
+ *   Native detailed modes: 1
+ *   Colorimetry Data Block:
+ *     sRGB
+ *   Video Data Block:
+ *     VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
+ *   Video Capability Data Block:
+ *     YCbCr quantization: Selectable (via AVI YQ)
+ *     RGB quantization: Selectable (via AVI Q)
+ *     PT scan behavior: No Data
+ *     IT scan behavior: Always Underscanned
+ *     CE scan behavior: Always Underscanned
+ *   Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
+ *     Source physical address: 1.2.3.4
+ *     DC_48bit
+ *     DC_36bit
+ *     DC_30bit
+ *     DC_Y444
+ *     Maximum TMDS clock: 340 MHz
+ *     Extended HDMI video details:
+ * Checksum: 0x8c  Unused space in Extension Block: 100 bytes
+ */
+const unsigned char test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz[] = {
+  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
+  0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20,
+  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
+  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
+  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
+  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
+  0x46, 0x1e, 0x46, 0x0f, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
+  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x8a, 0x02, 0x03, 0x1b, 0xb1,
+  0xe3, 0x05, 0x00, 0x20, 0x41, 0x10, 0xe2, 0x00, 0xca, 0x6d, 0x03, 0x0c,
+  0x00, 0x12, 0x34, 0x78, 0x44, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x8c
+};
+
 #endif // DRM_KUNIT_EDID_H_
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 0cc5a8732664..59016d9c17f5 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1085,6 +1085,11 @@ struct drm_connector_state {
 		 * @output_format: Pixel format to output in.
 		 */
 		enum hdmi_colorspace output_format;
+
+		/**
+		 * @tmds_char_rate: TMDS Character Rate, in Hz.
+		 */
+		unsigned long long tmds_char_rate;
 	} hdmi;
 };
 

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:39 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:39 +0100
Subject: [PATCH v5 16/44] drm/connector: hdmi: Add Infoframes generation
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-16-6538e19d634d@kernel.org>

Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.

Now that we have everything needed to generate them in the HDMI
connector state, we can generate them in our common logic so that
drivers can simply reuse what we precomputed.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/Kconfig                            |   1 +
 drivers/gpu/drm/drm_atomic_state_helper.c          | 327 +++++++++++++++++++++
 drivers/gpu/drm/drm_connector.c                    |  16 +
 .../gpu/drm/tests/drm_atomic_state_helper_test.c   |   1 +
 drivers/gpu/drm/tests/drm_connector_test.c         | 231 +++++++++++++++
 include/drm/drm_atomic_state_helper.h              |   7 +
 include/drm/drm_connector.h                        | 133 +++++++++
 7 files changed, 716 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 31cfe2c2a2af..acf733426bde 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -100,6 +100,7 @@ config DRM_KUNIT_TEST
 config DRM_KMS_HELPER
 	tristate
 	depends on DRM
+	select DRM_DISPLAY_HDMI_HELPER
 	help
 	  CRTC helpers for KMS drivers.
 
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 2442b5a2d94f..78e5d3463570 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -38,6 +38,8 @@
 #include <drm/drm_vblank.h>
 #include <drm/drm_writeback.h>
 
+#include <drm/display/drm_hdmi_helper.h>
+
 #include <linux/slab.h>
 #include <linux/dma-fence.h>
 
@@ -905,6 +907,142 @@ hdmi_compute_config(const struct drm_connector *connector,
 	return -EINVAL;
 }
 
+static int hdmi_generate_avi_infoframe(const struct drm_connector *connector,
+				       struct drm_connector_state *state)
+{
+	const struct drm_display_mode *mode =
+		connector_state_get_mode(state);
+	struct drm_connector_hdmi_infoframe *infoframe =
+		&state->hdmi.infoframes.avi;
+	struct hdmi_avi_infoframe *frame =
+		&infoframe->data.avi;
+	bool is_full_range = state->hdmi.is_full_range;
+	enum hdmi_quantization_range rgb_quant_range =
+		is_full_range ? HDMI_QUANTIZATION_RANGE_FULL : HDMI_QUANTIZATION_RANGE_LIMITED;
+	int ret;
+
+	ret = drm_hdmi_avi_infoframe_from_display_mode(frame, connector, mode);
+	if (ret)
+		return ret;
+
+	frame->colorspace = state->hdmi.output_format;
+
+	drm_hdmi_avi_infoframe_quant_range(frame, connector, mode, rgb_quant_range);
+	drm_hdmi_avi_infoframe_colorimetry(frame, state);
+	drm_hdmi_avi_infoframe_bars(frame, state);
+
+	infoframe->set = true;
+
+	return 0;
+}
+
+static int hdmi_generate_spd_infoframe(const struct drm_connector *connector,
+				       struct drm_connector_state *state)
+{
+	struct drm_connector_hdmi_infoframe *infoframe =
+		&state->hdmi.infoframes.spd;
+	struct hdmi_spd_infoframe *frame =
+		&infoframe->data.spd;
+	int ret;
+
+	ret = hdmi_spd_infoframe_init(frame,
+				      connector->hdmi.vendor,
+				      connector->hdmi.product);
+	if (ret)
+		return ret;
+
+	frame->sdi = HDMI_SPD_SDI_PC;
+
+	infoframe->set = true;
+
+	return 0;
+}
+
+static int hdmi_generate_hdr_infoframe(const struct drm_connector *connector,
+				       struct drm_connector_state *state)
+{
+	struct drm_connector_hdmi_infoframe *infoframe =
+		&state->hdmi.infoframes.hdr_drm;
+	struct hdmi_drm_infoframe *frame =
+		&infoframe->data.drm;
+	int ret;
+
+	if (connector->max_bpc < 10)
+		return 0;
+
+	if (!state->hdr_output_metadata)
+		return 0;
+
+	ret = drm_hdmi_infoframe_set_hdr_metadata(frame, state);
+	if (ret)
+		return ret;
+
+	infoframe->set = true;
+
+	return 0;
+}
+
+static int hdmi_generate_hdmi_vendor_infoframe(const struct drm_connector *connector,
+					       struct drm_connector_state *state)
+{
+	const struct drm_display_mode *mode =
+		connector_state_get_mode(state);
+	struct drm_connector_hdmi_infoframe *infoframe =
+		&state->hdmi.infoframes.hdmi;
+	struct hdmi_vendor_infoframe *frame =
+		&infoframe->data.vendor.hdmi;
+	int ret;
+
+	ret = drm_hdmi_vendor_infoframe_from_display_mode(frame, connector, mode);
+	if (ret) {
+		if (ret == -EINVAL)
+			return 0;
+
+		return ret;
+	}
+
+	infoframe->set = true;
+
+	return 0;
+}
+
+static int
+hdmi_generate_infoframes(const struct drm_connector *connector,
+			 struct drm_connector_state *state)
+{
+	const struct drm_display_info *info = &connector->display_info;
+	int ret;
+
+	if (!info->is_hdmi)
+		return 0;
+
+	if (!info->has_hdmi_infoframe)
+		return 0;
+
+	ret = hdmi_generate_avi_infoframe(connector, state);
+	if (ret)
+		return ret;
+
+	ret = hdmi_generate_spd_infoframe(connector, state);
+	if (ret)
+		return ret;
+
+	/*
+	 * Audio Infoframes will be generated by ALSA, and updated by
+	 * drm_atomic_helper_connector_hdmi_update_audio_infoframe().
+	 */
+
+	ret = hdmi_generate_hdr_infoframe(connector, state);
+	if (ret)
+		return ret;
+
+	ret = hdmi_generate_hdmi_vendor_infoframe(connector, state);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 /**
  * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
  * @connector: DRM Connector
@@ -934,6 +1072,10 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
 	if (ret)
 		return ret;
 
+	ret = hdmi_generate_infoframes(connector, new_state);
+	if (ret)
+		return ret;
+
 	if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb ||
 	    old_state->hdmi.output_bpc != new_state->hdmi.output_bpc ||
 	    old_state->hdmi.output_format != new_state->hdmi.output_format) {
@@ -951,6 +1093,191 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_check);
 
+#define HDMI_MAX_INFOFRAME_SIZE		29
+
+static int clear_device_infoframe(struct drm_connector *connector,
+				  enum hdmi_infoframe_type type)
+{
+	const struct drm_connector_hdmi_funcs *funcs = connector->hdmi.funcs;
+
+	if (!funcs || !funcs->clear_infoframe)
+		return 0;
+
+	return funcs->clear_infoframe(connector, type);
+}
+
+static int clear_infoframe(struct drm_connector *connector,
+			   struct drm_connector_hdmi_infoframe *conn_frame,
+			   struct drm_connector_hdmi_infoframe *old_frame)
+{
+	int ret;
+
+	ret = clear_device_infoframe(connector, old_frame->data.any.type);
+	if (ret)
+		return ret;
+
+	memset(old_frame, 0, sizeof(*old_frame));
+
+	return 0;
+}
+
+static int write_device_infoframe(struct drm_connector *connector,
+				  union hdmi_infoframe *frame)
+{
+	const struct drm_connector_hdmi_funcs *funcs = connector->hdmi.funcs;
+	u8 buffer[HDMI_MAX_INFOFRAME_SIZE];
+	int len;
+
+	if (!funcs || !funcs->write_infoframe)
+		return -ENOSYS;
+
+	len = hdmi_infoframe_pack(frame, buffer, sizeof(buffer));
+	if (len < 0)
+		return len;
+
+	return funcs->write_infoframe(connector, frame->any.type, buffer, len);
+}
+
+static int write_infoframe(struct drm_connector *connector,
+			   struct drm_connector_hdmi_infoframe *conn_frame,
+			   struct drm_connector_hdmi_infoframe *new_frame)
+{
+	int ret;
+
+	ret = write_device_infoframe(connector, &new_frame->data);
+	if (ret)
+		return ret;
+
+	if (conn_frame)
+		memcpy(conn_frame, new_frame, sizeof(*conn_frame));
+
+	return 0;
+}
+
+static int write_or_clear_infoframe(struct drm_connector *connector,
+				    struct drm_connector_hdmi_infoframe *conn_frame,
+				    struct drm_connector_hdmi_infoframe *old_frame,
+				    struct drm_connector_hdmi_infoframe *new_frame)
+{
+	if (new_frame->set)
+		return write_infoframe(connector, conn_frame, new_frame);
+
+	if (old_frame->set && !new_frame->set)
+		return clear_infoframe(connector, conn_frame, old_frame);
+
+	return 0;
+}
+
+#define UPDATE_INFOFRAME(c, os, ns, i)				\
+	write_or_clear_infoframe(c,				\
+				 &(c)->hdmi.infoframes.i,	\
+				 &(os)->hdmi.infoframes.i,	\
+				 &(ns)->hdmi.infoframes.i)
+
+/**
+ * drm_atomic_helper_connector_hdmi_update_infoframes - Update the Infoframes
+ * @connector: A pointer to the HDMI connector
+ * @state: The HDMI connector state to generate the infoframe from
+ *
+ * This function is meant for HDMI connector drivers to write their
+ * infoframes. It will typically be used in a
+ * @drm_connector_helper_funcs.atomic_enable implementation.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_atomic_helper_connector_hdmi_update_infoframes(struct drm_connector *connector,
+						       struct drm_atomic_state *state)
+{
+	struct drm_connector_state *old_state =
+		drm_atomic_get_old_connector_state(state, connector);
+	struct drm_connector_state *new_state =
+		drm_atomic_get_new_connector_state(state, connector);
+	struct drm_display_info *info = &connector->display_info;
+	int ret;
+
+	if (!info->is_hdmi)
+		return 0;
+
+	if (!info->has_hdmi_infoframe)
+		return 0;
+
+	mutex_lock(&connector->hdmi.infoframes.lock);
+
+	ret = UPDATE_INFOFRAME(connector, old_state, new_state, avi);
+	if (ret)
+		goto out;
+
+	if (connector->hdmi.infoframes.audio.set) {
+		ret = write_infoframe(connector,
+				      NULL,
+				      &connector->hdmi.infoframes.audio);
+		if (ret)
+			goto out;
+	}
+
+	ret = UPDATE_INFOFRAME(connector, old_state, new_state, hdr_drm);
+	if (ret)
+		goto out;
+
+	ret = UPDATE_INFOFRAME(connector, old_state, new_state, spd);
+	if (ret)
+		goto out;
+
+	ret = UPDATE_INFOFRAME(connector, old_state, new_state, hdmi);
+	if (ret)
+		goto out;
+
+out:
+	mutex_unlock(&connector->hdmi.infoframes.lock);
+	return ret;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_update_infoframes);
+
+#undef UPDATE_INFOFRAME
+#undef UPDATE_INFOFRAME_TOGGLE
+
+/**
+ * drm_atomic_helper_connector_hdmi_update_audio_infoframe - Update the Audio Infoframe
+ * @connector: A pointer to the HDMI connector
+ * @frame: A pointer to the audio infoframe to write
+ *
+ * This function is meant for HDMI connector drivers to update their
+ * audio infoframe. It will typically be used in one of the ALSA hooks
+ * (most likely prepare).
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int
+drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct drm_connector *connector,
+							struct hdmi_audio_infoframe *frame)
+{
+	struct drm_connector_hdmi_infoframe infoframe = {};
+	struct drm_display_info *info = &connector->display_info;
+	int ret;
+
+	if (!info->is_hdmi)
+		return 0;
+
+	if (!info->has_hdmi_infoframe)
+		return 0;
+
+	memcpy(&infoframe.data, frame, sizeof(infoframe.data));
+	infoframe.set = true;
+
+	mutex_lock(&connector->hdmi.infoframes.lock);
+
+	ret = write_infoframe(connector,
+			      &connector->hdmi.infoframes.audio,
+			      &infoframe);
+
+	mutex_unlock(&connector->hdmi.infoframes.lock);
+
+	return ret;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_update_audio_infoframe);
+
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
  * @connector: connector object
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9f314fee26ce..1f783f82423b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -456,6 +456,8 @@ EXPORT_SYMBOL(drmm_connector_init);
  * drmm_connector_hdmi_init - Init a preallocated HDMI connector
  * @dev: DRM device
  * @connector: A pointer to the HDMI connector to init
+ * @vendor: HDMI Controller Vendor name
+ * @product: HDMI Controller Product name
  * @funcs: callbacks for this connector
  * @hdmi_funcs: HDMI-related callbacks for this connector
  * @connector_type: user visible type of the connector
@@ -476,6 +478,7 @@ EXPORT_SYMBOL(drmm_connector_init);
  */
 int drmm_connector_hdmi_init(struct drm_device *dev,
 			     struct drm_connector *connector,
+			     const char *vendor, const char *product,
 			     const struct drm_connector_funcs *funcs,
 			     const struct drm_connector_hdmi_funcs *hdmi_funcs,
 			     int connector_type,
@@ -485,6 +488,13 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 {
 	int ret;
 
+	if (!vendor || !product)
+		return -EINVAL;
+
+	if ((strlen(vendor) > DRM_CONNECTOR_HDMI_VENDOR_LEN) ||
+	    (strlen(product) > DRM_CONNECTOR_HDMI_PRODUCT_LEN))
+		return -EINVAL;
+
 	if (!(connector_type == DRM_MODE_CONNECTOR_HDMIA ||
 	      connector_type == DRM_MODE_CONNECTOR_HDMIB))
 		return -EINVAL;
@@ -500,6 +510,12 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 		return ret;
 
 	connector->hdmi.supported_formats = supported_formats;
+	strtomem_pad(connector->hdmi.vendor, vendor, 0);
+	strtomem_pad(connector->hdmi.product, product, 0);
+
+	ret = drmm_mutex_init(dev, &connector->hdmi.infoframes.lock);
+	if (ret)
+		return ret;
 
 	/*
 	 * drm_connector_attach_max_bpc_property() requires the
diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
index 860e34b00fee..1eaa83af9dd0 100644
--- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
@@ -203,6 +203,7 @@ drm_atomic_helper_connector_hdmi_init(struct kunit *test,
 
 	conn = &priv->connector;
 	ret = drmm_connector_hdmi_init(drm, conn,
+				       "Vendor", "Product",
 				       &dummy_connector_funcs,
 				       &dummy_connector_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
index 6a3651b08c81..07066b704b36 100644
--- a/drivers/gpu/drm/tests/drm_connector_test.c
+++ b/drivers/gpu/drm/tests/drm_connector_test.c
@@ -189,6 +189,7 @@ static void drm_test_connector_hdmi_init_valid(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
@@ -208,6 +209,7 @@ static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
@@ -217,6 +219,217 @@ static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
 	KUNIT_EXPECT_EQ(test, ret, 0);
 }
 
+/*
+ * Test that the registration of an HDMI connector with a NULL vendor
+ * fails.
+ */
+static void drm_test_connector_hdmi_init_null_vendor(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       NULL, "Product",
+				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
+				       8);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
+/*
+ * Test that the registration of an HDMI connector with a NULL product
+ * fails.
+ */
+static void drm_test_connector_hdmi_init_null_product(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	int ret;
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", NULL,
+				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
+				       8);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
+/*
+ * Test that the registration of a connector with a valid, shorter than
+ * the max length, product name succeeds, and is stored padded with 0.
+ */
+static void drm_test_connector_hdmi_init_product_valid(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const unsigned char expected_product[DRM_CONNECTOR_HDMI_PRODUCT_LEN] = {
+		'P', 'r', 'o', 'd',
+	};
+	const char *product_name = "Prod";
+	int ret;
+
+	KUNIT_ASSERT_LT(test, strlen(product_name), DRM_CONNECTOR_HDMI_PRODUCT_LEN);
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", product_name,
+				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
+				       8);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+	KUNIT_EXPECT_MEMEQ(test,
+			   priv->connector.hdmi.product,
+			   expected_product,
+			   sizeof(priv->connector.hdmi.product));
+}
+
+/*
+ * Test that the registration of a connector with a valid, at max
+ * length, product name succeeds, and is stored padded without any
+ * trailing \0.
+ */
+static void drm_test_connector_hdmi_init_product_length_exact(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const unsigned char expected_product[DRM_CONNECTOR_HDMI_PRODUCT_LEN] = {
+		'P', 'r', 'o', 'd', 'u', 'c', 't',
+		'P', 'r', 'o', 'd', 'u', 'c', 't',
+		'P', 'r',
+	};
+	const char *product_name = "ProductProductPr";
+	int ret;
+
+	KUNIT_ASSERT_EQ(test, strlen(product_name), DRM_CONNECTOR_HDMI_PRODUCT_LEN);
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", product_name,
+				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
+				       8);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+	KUNIT_EXPECT_MEMEQ(test,
+			   priv->connector.hdmi.product,
+			   expected_product,
+			   sizeof(priv->connector.hdmi.product));
+}
+
+/*
+ * Test that the registration of a connector with a product name larger
+ * than the maximum length fails.
+ */
+static void drm_test_connector_hdmi_init_product_length_too_long(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const char *product_name = "ProductProductProduct";
+	int ret;
+
+	KUNIT_ASSERT_GT(test, strlen(product_name), DRM_CONNECTOR_HDMI_PRODUCT_LEN);
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", product_name,
+				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
+				       8);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
+/*
+ * Test that the registration of a connector with a vendor name smaller
+ * than the maximum length succeeds, and is stored padded with zeros.
+ */
+static void drm_test_connector_hdmi_init_vendor_valid(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const char expected_vendor[DRM_CONNECTOR_HDMI_VENDOR_LEN] = {
+		'V', 'e', 'n', 'd',
+	};
+	const char *vendor_name = "Vend";
+	int ret;
+
+	KUNIT_ASSERT_LT(test, strlen(vendor_name), DRM_CONNECTOR_HDMI_VENDOR_LEN);
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       vendor_name, "Product",
+				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
+				       8);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+	KUNIT_EXPECT_MEMEQ(test,
+			   priv->connector.hdmi.vendor,
+			   expected_vendor,
+			   sizeof(priv->connector.hdmi.vendor));
+}
+
+/*
+ * Test that the registration of a connector with a vendor name at the
+ * maximum length succeeds, and is stored padded without the trailing
+ * zero.
+ */
+static void drm_test_connector_hdmi_init_vendor_length_exact(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const char expected_vendor[DRM_CONNECTOR_HDMI_VENDOR_LEN] = {
+		'V', 'e', 'n', 'd', 'o', 'r',
+		'V', 'e',
+	};
+	const char *vendor_name = "VendorVe";
+	int ret;
+
+	KUNIT_ASSERT_EQ(test, strlen(vendor_name), DRM_CONNECTOR_HDMI_VENDOR_LEN);
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       vendor_name, "Product",
+				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
+				       8);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+	KUNIT_EXPECT_MEMEQ(test,
+			   priv->connector.hdmi.vendor,
+			   expected_vendor,
+			   sizeof(priv->connector.hdmi.vendor));
+}
+
+/*
+ * Test that the registration of a connector with a vendor name larger
+ * than the maximum length fails.
+ */
+static void drm_test_connector_hdmi_init_vendor_length_too_long(struct kunit *test)
+{
+	struct drm_connector_init_priv *priv = test->priv;
+	const char *vendor_name = "VendorVendor";
+	int ret;
+
+	KUNIT_ASSERT_GT(test, strlen(vendor_name), DRM_CONNECTOR_HDMI_VENDOR_LEN);
+
+	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       vendor_name, "Product",
+				       &dummy_funcs,
+				       &dummy_hdmi_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       &priv->ddc,
+				       BIT(HDMI_COLORSPACE_RGB),
+				       8);
+	KUNIT_EXPECT_LT(test, ret, 0);
+}
+
 /*
  * Test that the registration of a connector with an invalid maximum bpc
  * count fails.
@@ -227,6 +440,7 @@ static void drm_test_connector_hdmi_init_bpc_invalid(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
@@ -246,6 +460,7 @@ static void drm_test_connector_hdmi_init_bpc_null(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
@@ -269,6 +484,7 @@ static void drm_test_connector_hdmi_init_bpc_8(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
@@ -304,6 +520,7 @@ static void drm_test_connector_hdmi_init_bpc_10(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
@@ -339,6 +556,7 @@ static void drm_test_connector_hdmi_init_bpc_12(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
@@ -370,6 +588,7 @@ static void drm_test_connector_hdmi_init_formats_empty(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
@@ -389,6 +608,7 @@ static void drm_test_connector_hdmi_init_formats_no_rgb(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
@@ -409,6 +629,7 @@ static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       connector_type,
@@ -443,6 +664,7 @@ static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       connector_type,
@@ -488,6 +710,14 @@ static struct kunit_case drmm_connector_hdmi_init_tests[] = {
 	KUNIT_CASE(drm_test_connector_hdmi_init_formats_empty),
 	KUNIT_CASE(drm_test_connector_hdmi_init_formats_no_rgb),
 	KUNIT_CASE(drm_test_connector_hdmi_init_null_ddc),
+	KUNIT_CASE(drm_test_connector_hdmi_init_null_product),
+	KUNIT_CASE(drm_test_connector_hdmi_init_null_vendor),
+	KUNIT_CASE(drm_test_connector_hdmi_init_product_length_exact),
+	KUNIT_CASE(drm_test_connector_hdmi_init_product_length_too_long),
+	KUNIT_CASE(drm_test_connector_hdmi_init_product_valid),
+	KUNIT_CASE(drm_test_connector_hdmi_init_vendor_length_exact),
+	KUNIT_CASE(drm_test_connector_hdmi_init_vendor_length_too_long),
+	KUNIT_CASE(drm_test_connector_hdmi_init_vendor_valid),
 	KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_valid,
 			 drm_connector_hdmi_init_type_valid_gen_params),
 	KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_invalid,
@@ -708,6 +938,7 @@ static void drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector(
 	int ret;
 
 	ret = drmm_connector_hdmi_init(&priv->drm, connector,
+				       "Vendor", "Product",
 				       &dummy_funcs,
 				       &dummy_hdmi_funcs,
 				       DRM_MODE_CONNECTOR_HDMIA,
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index 8072ac18e536..22f083968aa8 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -40,6 +40,8 @@ struct drm_private_state;
 struct drm_modeset_acquire_ctx;
 struct drm_device;
 
+struct hdmi_audio_infoframe;
+
 void __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *state,
 					  struct drm_crtc *crtc);
 void __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
@@ -89,6 +91,11 @@ __drm_atomic_helper_connector_destroy_state(struct drm_connector_state *state);
 void drm_atomic_helper_connector_destroy_state(struct drm_connector *connector,
 					  struct drm_connector_state *state);
 
+int drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct drm_connector *connector,
+							    struct hdmi_audio_infoframe *frame);
+int drm_atomic_helper_connector_hdmi_update_infoframes(struct drm_connector *connector,
+						       struct drm_atomic_state *state);
+
 void __drm_atomic_helper_private_obj_duplicate_state(struct drm_private_obj *obj,
 						     struct drm_private_state *state);
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3eaf4d54364d..5964ef283022 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -914,6 +914,21 @@ struct drm_tv_connector_state {
 	unsigned int hue;
 };
 
+/**
+ * struct drm_connector_hdmi_infoframe - HDMI Infoframe container
+ */
+struct drm_connector_hdmi_infoframe {
+	/**
+	 * @data: HDMI Infoframe structure
+	 */
+	union hdmi_infoframe data;
+
+	/**
+	 * @set: Is the content of @data valid?
+	 */
+	bool set;
+};
+
 /**
  * struct drm_connector_state - mutable connector state
  */
@@ -1070,6 +1085,35 @@ struct drm_connector_state {
 		 */
 		enum drm_hdmi_broadcast_rgb broadcast_rgb;
 
+		/**
+		 * @infoframes: HDMI Infoframes matching that state
+		 */
+		struct {
+			/**
+			 * @avi: AVI Infoframes structure matching our
+			 * state.
+			 */
+			struct drm_connector_hdmi_infoframe avi;
+
+			/**
+			 * @hdr_drm: DRM (Dynamic Range and Mastering)
+			 * Infoframes structure matching our state.
+			 */
+			struct drm_connector_hdmi_infoframe hdr_drm;
+
+			/**
+			 * @spd: SPD Infoframes structure matching our
+			 * state.
+			 */
+			struct drm_connector_hdmi_infoframe spd;
+
+			/**
+			 * @vendor: HDMI Vendor Infoframes structure
+			 * matching our state.
+			 */
+			struct drm_connector_hdmi_infoframe hdmi;
+		} infoframes;
+
 		/**
 		 * @is_full_range: Is the output supposed to use a full
 		 * RGB Quantization Range or not?
@@ -1115,6 +1159,41 @@ struct drm_connector_hdmi_funcs {
 	(*tmds_char_rate_valid)(const struct drm_connector *connector,
 				const struct drm_display_mode *mode,
 				unsigned long long tmds_rate);
+
+	/**
+	 * @clear_infoframe:
+	 *
+	 * This callback is invoked through
+	 * @drm_atomic_helper_hdmi_connector_update_infoframes during a
+	 * commit to clear the infoframes into the hardware. It will be
+	 * called multiple times, once for every disabled infoframe
+	 * type.
+	 *
+	 * The @clear_infoframe callback is optional.
+	 *
+	 * Returns:
+	 * 0 on success, a negative error code otherwise
+	 */
+	int (*clear_infoframe)(struct drm_connector *connector,
+			       enum hdmi_infoframe_type type);
+
+	/**
+	 * @write_infoframe:
+	 *
+	 * This callback is invoked through
+	 * @drm_atomic_helper_hdmi_connector_update_infoframes during a
+	 * commit to program the infoframes into the hardware. It will
+	 * be called multiple times, once for every updated infoframe
+	 * type.
+	 *
+	 * The @write_infoframe callback is mandatory.
+	 *
+	 * Returns:
+	 * 0 on success, a negative error code otherwise
+	 */
+	int (*write_infoframe)(struct drm_connector *connector,
+			       enum hdmi_infoframe_type type,
+			       const u8 *buffer, size_t len);
 };
 
 /**
@@ -1986,6 +2065,18 @@ struct drm_connector {
 	 * @hdmi: HDMI-related variable and properties.
 	 */
 	struct {
+#define DRM_CONNECTOR_HDMI_VENDOR_LEN	8
+		/**
+		 * @vendor: HDMI Controller Vendor Name
+		 */
+		unsigned char vendor[DRM_CONNECTOR_HDMI_VENDOR_LEN] __nonstring;
+
+#define DRM_CONNECTOR_HDMI_PRODUCT_LEN	16
+		/**
+		 * @product: HDMI Controller Product Name
+		 */
+		unsigned char product[DRM_CONNECTOR_HDMI_PRODUCT_LEN] __nonstring;
+
 		/**
 		 * @supported_formats: Bitmask of @hdmi_colorspace
 		 * supported by the controller.
@@ -1996,6 +2087,47 @@ struct drm_connector {
 		 * @funcs: HDMI connector Control Functions
 		 */
 		const struct drm_connector_hdmi_funcs *funcs;
+
+		/**
+		 * @infoframes: Current Infoframes output by the connector
+		 */
+		struct {
+			/**
+			 * @lock: Mutex protecting against concurrent access to
+			 * the infoframes, most notably between KMS and ALSA.
+			 */
+			struct mutex lock;
+
+			/**
+			 * @audio: Current Audio Infoframes structure. Protected
+			 * by @lock.
+			 */
+			struct drm_connector_hdmi_infoframe audio;
+
+			/**
+			 * @avi: Current AVI Infoframes structure. Protected by
+			 * @lock.
+			 */
+			struct drm_connector_hdmi_infoframe avi;
+
+			/**
+			 * @hdr_drm: Current DRM (Dynamic Range and Mastering)
+			 * Infoframes structure. Protected by @lock.
+			 */
+			struct drm_connector_hdmi_infoframe hdr_drm;
+
+			/**
+			 * @spd: Current SPD Infoframes structure. Protected by
+			 * @lock.
+			 */
+			struct drm_connector_hdmi_infoframe spd;
+
+			/**
+			 * @vendor: Current HDMI Vendor Infoframes structure.
+			 * Protected by @lock.
+			 */
+			struct drm_connector_hdmi_infoframe hdmi;
+		} infoframes;
 	} hdmi;
 };
 
@@ -2017,6 +2149,7 @@ int drmm_connector_init(struct drm_device *dev,
 			struct i2c_adapter *ddc);
 int drmm_connector_hdmi_init(struct drm_device *dev,
 			     struct drm_connector *connector,
+			     const char *vendor, const char *product,
 			     const struct drm_connector_funcs *funcs,
 			     const struct drm_connector_hdmi_funcs *hdmi_funcs,
 			     int connector_type,

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:41 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:41 +0100
Subject: [PATCH v5 18/44] drm/vc4: hdmi: Create destroy state
 implementation
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-18-6538e19d634d@kernel.org>

Even though we were rolling our own custom state for the vc4 HDMI
controller driver, we were still using the generic helper to destroy
that state.

It was mostly working since the underlying state is the first member of
our state so the pointers are probably equal in all relevant cases, but
it's still fragile so let's fix this properly.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 25c9c71256d3..f05e2c95a60d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -672,11 +672,21 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
 	return &new_state->base;
 }
 
+static void vc4_hdmi_connector_destroy_state(struct drm_connector *connector,
+					     struct drm_connector_state *state)
+{
+	struct vc4_hdmi_connector_state *vc4_state =
+		conn_state_to_vc4_hdmi_conn_state(state);
+
+	__drm_atomic_helper_connector_destroy_state(state);
+	kfree(vc4_state);
+}
+
 static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
 	.fill_modes = drm_helper_probe_single_connector_modes,
 	.reset = vc4_hdmi_connector_reset,
 	.atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
-	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+	.atomic_destroy_state = vc4_hdmi_connector_destroy_state,
 	.atomic_get_property = vc4_hdmi_connector_get_property,
 	.atomic_set_property = vc4_hdmi_connector_set_property,
 };

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:42 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:42 +0100
Subject: [PATCH v5 19/44] drm/vc4: hdmi: Switch to HDMI connector
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-19-6538e19d634d@kernel.org>

The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/vc4/vc4_hdmi.c     | 638 +++++--------------------------------
 drivers/gpu/drm/vc4/vc4_hdmi.h     |  44 +--
 drivers/gpu/drm/vc4/vc4_hdmi_phy.c |   6 +-
 3 files changed, 86 insertions(+), 602 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index f05e2c95a60d..3e3a2afdc730 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -109,25 +109,6 @@
 
 #define HDMI_14_MAX_TMDS_CLK   (340 * 1000 * 1000)
 
-static const char * const output_format_str[] = {
-	[VC4_HDMI_OUTPUT_RGB]		= "RGB",
-	[VC4_HDMI_OUTPUT_YUV420]	= "YUV 4:2:0",
-	[VC4_HDMI_OUTPUT_YUV422]	= "YUV 4:2:2",
-	[VC4_HDMI_OUTPUT_YUV444]	= "YUV 4:4:4",
-};
-
-static const char *vc4_hdmi_output_fmt_str(enum vc4_hdmi_output_format fmt)
-{
-	if (fmt >= ARRAY_SIZE(output_format_str))
-		return "invalid";
-
-	return output_format_str[fmt];
-}
-
-static unsigned long long
-vc4_hdmi_encoder_compute_mode_clock(const struct drm_display_mode *mode,
-				    unsigned int bpc, enum vc4_hdmi_output_format fmt);
-
 static bool vc4_hdmi_supports_scrambling(struct vc4_hdmi *vc4_hdmi)
 {
 	struct drm_display_info *display = &vc4_hdmi->connector.display_info;
@@ -146,28 +127,13 @@ static bool vc4_hdmi_supports_scrambling(struct vc4_hdmi *vc4_hdmi)
 
 static bool vc4_hdmi_mode_needs_scrambling(const struct drm_display_mode *mode,
 					   unsigned int bpc,
-					   enum vc4_hdmi_output_format fmt)
+					   enum hdmi_colorspace fmt)
 {
-	unsigned long long clock = vc4_hdmi_encoder_compute_mode_clock(mode, bpc, fmt);
+	unsigned long long clock = drm_connector_hdmi_compute_mode_clock(mode, bpc, fmt);
 
 	return clock > HDMI_14_MAX_TMDS_CLK;
 }
 
-static bool vc4_hdmi_is_full_range(struct vc4_hdmi *vc4_hdmi,
-				   struct vc4_hdmi_connector_state *vc4_state)
-{
-	const struct drm_display_mode *mode = &vc4_hdmi->saved_adjusted_mode;
-	struct drm_display_info *display = &vc4_hdmi->connector.display_info;
-
-	if (vc4_state->broadcast_rgb == VC4_HDMI_BROADCAST_RGB_LIMITED)
-		return false;
-	else if (vc4_state->broadcast_rgb == VC4_HDMI_BROADCAST_RGB_FULL)
-		return true;
-
-	return !display->is_hdmi ||
-		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_FULL;
-}
-
 static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
 {
 	struct drm_debugfs_entry *entry = m->private;
@@ -519,7 +485,7 @@ static int vc4_hdmi_connector_get_modes(struct drm_connector *connector)
 		const struct drm_display_mode *mode;
 
 		list_for_each_entry(mode, &connector->probed_modes, head) {
-			if (vc4_hdmi_mode_needs_scrambling(mode, 8, VC4_HDMI_OUTPUT_RGB)) {
+			if (vc4_hdmi_mode_needs_scrambling(mode, 8, HDMI_COLORSPACE_RGB)) {
 				drm_warn_once(drm, "The core clock cannot reach frequencies high enough to support 4k @ 60Hz.");
 				drm_warn_once(drm, "Please change your config.txt file to add hdmi_enable_4kp60.");
 			}
@@ -534,12 +500,8 @@ static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
 {
 	struct drm_connector_state *old_state =
 		drm_atomic_get_old_connector_state(state, connector);
-	struct vc4_hdmi_connector_state *old_vc4_state =
-		conn_state_to_vc4_hdmi_conn_state(old_state);
 	struct drm_connector_state *new_state =
 		drm_atomic_get_new_connector_state(state, connector);
-	struct vc4_hdmi_connector_state *new_vc4_state =
-		conn_state_to_vc4_hdmi_conn_state(new_state);
 	struct drm_crtc *crtc = new_state->crtc;
 
 	if (!crtc)
@@ -571,9 +533,7 @@ static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
 			return ret;
 	}
 
-	if (old_state->colorspace != new_state->colorspace ||
-	    old_vc4_state->broadcast_rgb != new_vc4_state->broadcast_rgb ||
-	    !drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
+	if (old_state->colorspace != new_state->colorspace) {
 		struct drm_crtc_state *crtc_state;
 
 		crtc_state = drm_atomic_get_crtc_state(state, crtc);
@@ -583,112 +543,21 @@ static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
 		crtc_state->mode_changed = true;
 	}
 
-	return 0;
-}
-
-static int vc4_hdmi_connector_get_property(struct drm_connector *connector,
-					   const struct drm_connector_state *state,
-					   struct drm_property *property,
-					   uint64_t *val)
-{
-	struct drm_device *drm = connector->dev;
-	struct vc4_hdmi *vc4_hdmi =
-		connector_to_vc4_hdmi(connector);
-	const struct vc4_hdmi_connector_state *vc4_conn_state =
-		conn_state_to_vc4_hdmi_conn_state(state);
-
-	if (property == vc4_hdmi->broadcast_rgb_property) {
-		*val = vc4_conn_state->broadcast_rgb;
-	} else {
-		drm_dbg(drm, "Unknown property [PROP:%d:%s]\n",
-			property->base.id, property->name);
-		return -EINVAL;
-	}
-
-	return 0;
-}
-
-static int vc4_hdmi_connector_set_property(struct drm_connector *connector,
-					   struct drm_connector_state *state,
-					   struct drm_property *property,
-					   uint64_t val)
-{
-	struct drm_device *drm = connector->dev;
-	struct vc4_hdmi *vc4_hdmi =
-		connector_to_vc4_hdmi(connector);
-	struct vc4_hdmi_connector_state *vc4_conn_state =
-		conn_state_to_vc4_hdmi_conn_state(state);
-
-	if (property == vc4_hdmi->broadcast_rgb_property) {
-		vc4_conn_state->broadcast_rgb = val;
-		return 0;
-	}
-
-	drm_dbg(drm, "Unknown property [PROP:%d:%s]\n",
-		property->base.id, property->name);
-	return -EINVAL;
+	return drm_atomic_helper_connector_hdmi_check(connector, state);
 }
 
 static void vc4_hdmi_connector_reset(struct drm_connector *connector)
 {
-	struct vc4_hdmi_connector_state *old_state =
-		conn_state_to_vc4_hdmi_conn_state(connector->state);
-	struct vc4_hdmi_connector_state *new_state =
-		kzalloc(sizeof(*new_state), GFP_KERNEL);
-
-	if (connector->state)
-		__drm_atomic_helper_connector_destroy_state(connector->state);
-
-	kfree(old_state);
-	__drm_atomic_helper_connector_reset(connector, &new_state->base);
-
-	if (!new_state)
-		return;
-
-	new_state->base.max_bpc = 8;
-	new_state->base.max_requested_bpc = 8;
-	new_state->output_format = VC4_HDMI_OUTPUT_RGB;
-	new_state->broadcast_rgb = VC4_HDMI_BROADCAST_RGB_AUTO;
+	drm_atomic_helper_connector_reset(connector);
+	__drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
 	drm_atomic_helper_connector_tv_margins_reset(connector);
 }
 
-static struct drm_connector_state *
-vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
-{
-	struct drm_connector_state *conn_state = connector->state;
-	struct vc4_hdmi_connector_state *vc4_state = conn_state_to_vc4_hdmi_conn_state(conn_state);
-	struct vc4_hdmi_connector_state *new_state;
-
-	new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
-	if (!new_state)
-		return NULL;
-
-	new_state->tmds_char_rate = vc4_state->tmds_char_rate;
-	new_state->output_bpc = vc4_state->output_bpc;
-	new_state->output_format = vc4_state->output_format;
-	new_state->broadcast_rgb = vc4_state->broadcast_rgb;
-	__drm_atomic_helper_connector_duplicate_state(connector, &new_state->base);
-
-	return &new_state->base;
-}
-
-static void vc4_hdmi_connector_destroy_state(struct drm_connector *connector,
-					     struct drm_connector_state *state)
-{
-	struct vc4_hdmi_connector_state *vc4_state =
-		conn_state_to_vc4_hdmi_conn_state(state);
-
-	__drm_atomic_helper_connector_destroy_state(state);
-	kfree(vc4_state);
-}
-
 static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
 	.fill_modes = drm_helper_probe_single_connector_modes,
 	.reset = vc4_hdmi_connector_reset,
-	.atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
-	.atomic_destroy_state = vc4_hdmi_connector_destroy_state,
-	.atomic_get_property = vc4_hdmi_connector_get_property,
-	.atomic_set_property = vc4_hdmi_connector_set_property,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
 static const struct drm_connector_helper_funcs vc4_hdmi_connector_helper_funcs = {
@@ -697,32 +566,7 @@ static const struct drm_connector_helper_funcs vc4_hdmi_connector_helper_funcs =
 	.atomic_check = vc4_hdmi_connector_atomic_check,
 };
 
-static const struct drm_prop_enum_list broadcast_rgb_names[] = {
-	{ VC4_HDMI_BROADCAST_RGB_AUTO, "Automatic" },
-	{ VC4_HDMI_BROADCAST_RGB_FULL, "Full" },
-	{ VC4_HDMI_BROADCAST_RGB_LIMITED, "Limited 16:235" },
-};
-
-static void
-vc4_hdmi_attach_broadcast_rgb_property(struct drm_device *dev,
-				       struct vc4_hdmi *vc4_hdmi)
-{
-	struct drm_property *prop = vc4_hdmi->broadcast_rgb_property;
-
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
-						"Broadcast RGB",
-						broadcast_rgb_names,
-						ARRAY_SIZE(broadcast_rgb_names));
-		if (!prop)
-			return;
-
-		vc4_hdmi->broadcast_rgb_property = prop;
-	}
-
-	drm_object_attach_property(&vc4_hdmi->connector.base, prop,
-				   VC4_HDMI_BROADCAST_RGB_AUTO);
-}
+static const struct drm_connector_hdmi_funcs vc4_hdmi_hdmi_connector_funcs;
 
 static int vc4_hdmi_connector_init(struct drm_device *dev,
 				   struct vc4_hdmi *vc4_hdmi)
@@ -731,10 +575,16 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
 	struct drm_encoder *encoder = &vc4_hdmi->encoder.base;
 	int ret;
 
-	ret = drmm_connector_init(dev, connector,
-				  &vc4_hdmi_connector_funcs,
-				  DRM_MODE_CONNECTOR_HDMIA,
-				  vc4_hdmi->ddc);
+	ret = drmm_connector_hdmi_init(dev, connector,
+				       "Broadcom", "Videocore",
+				       &vc4_hdmi_connector_funcs,
+				       &vc4_hdmi_hdmi_connector_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       vc4_hdmi->ddc,
+				       BIT(HDMI_COLORSPACE_RGB) |
+				       BIT(HDMI_COLORSPACE_YUV422) |
+				       BIT(HDMI_COLORSPACE_YUV444),
+				       12);
 	if (ret)
 		return ret;
 
@@ -758,7 +608,6 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
 
 	drm_connector_attach_colorspace_property(connector);
 	drm_connector_attach_tv_margin_properties(connector);
-	drm_connector_attach_max_bpc_property(connector, 8, 12);
 
 	connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
 			     DRM_CONNECTOR_POLL_DISCONNECT);
@@ -767,21 +616,19 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
 	connector->doublescan_allowed = 0;
 	connector->stereo_allowed = 1;
 
-	if (vc4_hdmi->variant->supports_hdr)
-		drm_connector_attach_hdr_output_metadata_property(connector);
-
-	vc4_hdmi_attach_broadcast_rgb_property(dev, vc4_hdmi);
+	ret = drm_connector_attach_broadcast_rgb_property(connector);
+	if (ret)
+		return ret;
 
 	drm_connector_attach_encoder(connector, encoder);
 
 	return 0;
 }
 
-static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
+static int vc4_hdmi_stop_packet(struct vc4_hdmi *vc4_hdmi,
 				enum hdmi_infoframe_type type,
 				bool poll)
 {
-	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
 	struct drm_device *drm = vc4_hdmi->connector.dev;
 	u32 packet_id = type - 0x80;
 	unsigned long flags;
@@ -805,12 +652,13 @@ static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
 	return ret;
 }
 
-static void vc4_hdmi_write_infoframe(struct drm_encoder *encoder,
-				     union hdmi_infoframe *frame)
+static int vc4_hdmi_write_infoframe(struct drm_connector *connector,
+				    enum hdmi_infoframe_type type,
+				    const u8 *infoframe, size_t len)
 {
-	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
-	struct drm_device *drm = vc4_hdmi->connector.dev;
-	u32 packet_id = frame->any.type - 0x80;
+	struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
+	struct drm_device *drm = connector->dev;
+	u32 packet_id = type - 0x80;
 	const struct vc4_hdmi_register *ram_packet_start =
 		&vc4_hdmi->variant->registers[HDMI_RAM_PACKET_START];
 	u32 packet_reg = ram_packet_start->offset + VC4_HDMI_PACKET_STRIDE * packet_id;
@@ -820,22 +668,25 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder *encoder,
 						       ram_packet_start->reg);
 	uint8_t buffer[VC4_HDMI_PACKET_STRIDE] = {};
 	unsigned long flags;
-	ssize_t len, i;
+	ssize_t i;
 	int ret;
 	int idx;
 
 	if (!drm_dev_enter(drm, &idx))
-		return;
+		return 0;
+
+	if (len > sizeof(buffer)) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	memcpy(buffer, infoframe, len);
 
 	WARN_ONCE(!(HDMI_READ(HDMI_RAM_PACKET_CONFIG) &
 		    VC4_HDMI_RAM_PACKET_ENABLE),
 		  "Packet RAM has to be on to store the packet.");
 
-	len = hdmi_infoframe_pack(frame, buffer, sizeof(buffer));
-	if (len < 0)
-		goto out;
-
-	ret = vc4_hdmi_stop_packet(encoder, frame->any.type, true);
+	ret = vc4_hdmi_stop_packet(vc4_hdmi, type, true);
 	if (ret) {
 		DRM_ERROR("Failed to wait for infoframe to go idle: %d\n", ret);
 		goto out;
@@ -877,130 +728,7 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder *encoder,
 
 out:
 	drm_dev_exit(idx);
-}
-
-static void vc4_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
-					      enum vc4_hdmi_output_format fmt)
-{
-	switch (fmt) {
-	case VC4_HDMI_OUTPUT_RGB:
-		frame->colorspace = HDMI_COLORSPACE_RGB;
-		break;
-
-	case VC4_HDMI_OUTPUT_YUV420:
-		frame->colorspace = HDMI_COLORSPACE_YUV420;
-		break;
-
-	case VC4_HDMI_OUTPUT_YUV422:
-		frame->colorspace = HDMI_COLORSPACE_YUV422;
-		break;
-
-	case VC4_HDMI_OUTPUT_YUV444:
-		frame->colorspace = HDMI_COLORSPACE_YUV444;
-		break;
-
-	default:
-		break;
-	}
-}
-
-static void vc4_hdmi_set_avi_infoframe(struct drm_encoder *encoder)
-{
-	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
-	struct drm_connector *connector = &vc4_hdmi->connector;
-	struct drm_connector_state *cstate = connector->state;
-	struct vc4_hdmi_connector_state *vc4_state =
-		conn_state_to_vc4_hdmi_conn_state(cstate);
-	const struct drm_display_mode *mode = &vc4_hdmi->saved_adjusted_mode;
-	union hdmi_infoframe frame;
-	int ret;
-
-	lockdep_assert_held(&vc4_hdmi->mutex);
-
-	ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
-						       connector, mode);
-	if (ret < 0) {
-		DRM_ERROR("couldn't fill AVI infoframe\n");
-		return;
-	}
-
-	drm_hdmi_avi_infoframe_quant_range(&frame.avi,
-					   connector, mode,
-					   vc4_hdmi_is_full_range(vc4_hdmi, vc4_state) ?
-					   HDMI_QUANTIZATION_RANGE_FULL :
-					   HDMI_QUANTIZATION_RANGE_LIMITED);
-	drm_hdmi_avi_infoframe_colorimetry(&frame.avi, cstate);
-	vc4_hdmi_avi_infoframe_colorspace(&frame.avi, vc4_state->output_format);
-	drm_hdmi_avi_infoframe_bars(&frame.avi, cstate);
-
-	vc4_hdmi_write_infoframe(encoder, &frame);
-}
-
-static void vc4_hdmi_set_spd_infoframe(struct drm_encoder *encoder)
-{
-	union hdmi_infoframe frame;
-	int ret;
-
-	ret = hdmi_spd_infoframe_init(&frame.spd, "Broadcom", "Videocore");
-	if (ret < 0) {
-		DRM_ERROR("couldn't fill SPD infoframe\n");
-		return;
-	}
-
-	frame.spd.sdi = HDMI_SPD_SDI_PC;
-
-	vc4_hdmi_write_infoframe(encoder, &frame);
-}
-
-static void vc4_hdmi_set_audio_infoframe(struct drm_encoder *encoder)
-{
-	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
-	struct hdmi_audio_infoframe *audio = &vc4_hdmi->audio.infoframe;
-	union hdmi_infoframe frame;
-
-	memcpy(&frame.audio, audio, sizeof(*audio));
-
-	if (vc4_hdmi->packet_ram_enabled)
-		vc4_hdmi_write_infoframe(encoder, &frame);
-}
-
-static void vc4_hdmi_set_hdr_infoframe(struct drm_encoder *encoder)
-{
-	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
-	struct drm_connector *connector = &vc4_hdmi->connector;
-	struct drm_connector_state *conn_state = connector->state;
-	union hdmi_infoframe frame;
-
-	lockdep_assert_held(&vc4_hdmi->mutex);
-
-	if (!vc4_hdmi->variant->supports_hdr)
-		return;
-
-	if (!conn_state->hdr_output_metadata)
-		return;
-
-	if (drm_hdmi_infoframe_set_hdr_metadata(&frame.drm, conn_state))
-		return;
-
-	vc4_hdmi_write_infoframe(encoder, &frame);
-}
-
-static void vc4_hdmi_set_infoframes(struct drm_encoder *encoder)
-{
-	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
-
-	lockdep_assert_held(&vc4_hdmi->mutex);
-
-	vc4_hdmi_set_avi_infoframe(encoder);
-	vc4_hdmi_set_spd_infoframe(encoder);
-	/*
-	 * If audio was streaming, then we need to reenabled the audio
-	 * infoframe here during encoder_enable.
-	 */
-	if (vc4_hdmi->audio.streaming)
-		vc4_hdmi_set_audio_infoframe(encoder);
-
-	vc4_hdmi_set_hdr_infoframe(encoder);
+	return ret;
 }
 
 #define SCRAMBLING_POLLING_DELAY_MS	1000
@@ -1169,9 +897,8 @@ static void vc4_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
 			       struct drm_connector_state *state,
 			       const struct drm_display_mode *mode)
 {
-	struct vc4_hdmi_connector_state *vc4_state =
-		conn_state_to_vc4_hdmi_conn_state(state);
 	struct drm_device *drm = vc4_hdmi->connector.dev;
+	bool is_lim_range = !state->hdmi.is_full_range;
 	unsigned long flags;
 	u32 csc_ctl;
 	int idx;
@@ -1184,7 +911,7 @@ static void vc4_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
 	csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
 				VC4_HD_CSC_CTL_ORDER);
 
-	if (!vc4_hdmi_is_full_range(vc4_hdmi, vc4_state)) {
+	if (is_lim_range) {
 		/* CEA VICs other than #1 requre limited range RGB
 		 * output unless overridden by an AVI infoframe.
 		 * Apply a colorspace conversion to squash 0-255 down
@@ -1407,9 +1134,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
 			       const struct drm_display_mode *mode)
 {
 	struct drm_device *drm = vc4_hdmi->connector.dev;
-	struct vc4_hdmi_connector_state *vc4_state =
-		conn_state_to_vc4_hdmi_conn_state(state);
-	unsigned int lim_range = vc4_hdmi_is_full_range(vc4_hdmi, vc4_state) ? 0 : 1;
+	unsigned int lim_range = state->hdmi.is_full_range ? 0 : 1;
 	unsigned long flags;
 	const u16 (*csc)[4];
 	u32 if_cfg = 0;
@@ -1424,14 +1149,14 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
 
 	spin_lock_irqsave(&vc4_hdmi->hw_lock, flags);
 
-	switch (vc4_state->output_format) {
-	case VC4_HDMI_OUTPUT_YUV444:
+	switch (state->hdmi.output_format) {
+	case HDMI_COLORSPACE_YUV444:
 		csc = vc5_hdmi_find_yuv_csc_coeffs(vc4_hdmi, state->colorspace, !!lim_range);
 
 		vc5_hdmi_set_csc_coeffs_swap(vc4_hdmi, csc);
 		break;
 
-	case VC4_HDMI_OUTPUT_YUV422:
+	case HDMI_COLORSPACE_YUV422:
 		csc = vc5_hdmi_find_yuv_csc_coeffs(vc4_hdmi, state->colorspace, !!lim_range);
 
 		csc_ctl |= VC4_SET_FIELD(VC5_MT_CP_CSC_CTL_FILTER_MODE_444_TO_422_STANDARD,
@@ -1448,7 +1173,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
 		vc5_hdmi_set_csc_coeffs(vc4_hdmi, csc);
 		break;
 
-	case VC4_HDMI_OUTPUT_RGB:
+	case HDMI_COLORSPACE_RGB:
 		if_xbar = 0x354021;
 
 		vc5_hdmi_set_csc_coeffs(vc4_hdmi, vc5_hdmi_csc_full_rgb_to_rgb[lim_range]);
@@ -1537,8 +1262,6 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
 				 const struct drm_display_mode *mode)
 {
 	struct drm_device *drm = vc4_hdmi->connector.dev;
-	const struct vc4_hdmi_connector_state *vc4_state =
-		conn_state_to_vc4_hdmi_conn_state(state);
 	bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
 	bool vsync_pos = mode->flags & DRM_MODE_FLAG_PVSYNC;
 	bool interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
@@ -1590,7 +1313,7 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
 	HDMI_WRITE(HDMI_VERTB0, vertb_even);
 	HDMI_WRITE(HDMI_VERTB1, vertb);
 
-	switch (vc4_state->output_bpc) {
+	switch (state->hdmi.output_bpc) {
 	case 12:
 		gcp = 6;
 		break;
@@ -1607,7 +1330,7 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
 	 * YCC422 is always 36-bit and not considered deep colour so
 	 * doesn't signal in GCP.
 	 */
-	if (vc4_state->output_format == VC4_HDMI_OUTPUT_YUV422) {
+	if (state->hdmi.output_format == HDMI_COLORSPACE_YUV422) {
 		gcp = 0;
 	}
 
@@ -1691,10 +1414,8 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
 	struct drm_connector *connector = &vc4_hdmi->connector;
 	struct drm_connector_state *conn_state =
 		drm_atomic_get_new_connector_state(state, connector);
-	struct vc4_hdmi_connector_state *vc4_conn_state =
-		conn_state_to_vc4_hdmi_conn_state(conn_state);
 	const struct drm_display_mode *mode = &vc4_hdmi->saved_adjusted_mode;
-	unsigned long tmds_char_rate = vc4_conn_state->tmds_char_rate;
+	unsigned long tmds_char_rate = conn_state->hdmi.tmds_char_rate;
 	unsigned long bvb_rate, hsm_rate;
 	unsigned long flags;
 	int ret;
@@ -1771,7 +1492,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
 	}
 
 	if (vc4_hdmi->variant->phy_init)
-		vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
+		vc4_hdmi->variant->phy_init(vc4_hdmi, conn_state);
 
 	spin_lock_irqsave(&vc4_hdmi->hw_lock, flags);
 
@@ -1836,7 +1557,8 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct drm_encoder *encoder,
 					      struct drm_atomic_state *state)
 {
 	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
-	struct drm_device *drm = vc4_hdmi->connector.dev;
+	struct drm_connector *connector = &vc4_hdmi->connector;
+	struct drm_device *drm = connector->dev;
 	const struct drm_display_mode *mode = &vc4_hdmi->saved_adjusted_mode;
 	struct drm_display_info *display = &vc4_hdmi->connector.display_info;
 	bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -1902,7 +1624,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct drm_encoder *encoder,
 		spin_unlock_irqrestore(&vc4_hdmi->hw_lock, flags);
 		vc4_hdmi->packet_ram_enabled = true;
 
-		vc4_hdmi_set_infoframes(encoder);
+		drm_atomic_helper_connector_hdmi_update_infoframes(connector, state);
 	}
 
 	vc4_hdmi_recenter_fifo(vc4_hdmi);
@@ -1919,108 +1641,21 @@ static void vc4_hdmi_encoder_atomic_mode_set(struct drm_encoder *encoder,
 					     struct drm_connector_state *conn_state)
 {
 	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
-	struct vc4_hdmi_connector_state *vc4_state =
-		conn_state_to_vc4_hdmi_conn_state(conn_state);
 
 	mutex_lock(&vc4_hdmi->mutex);
 	drm_mode_copy(&vc4_hdmi->saved_adjusted_mode,
 		      &crtc_state->adjusted_mode);
-	vc4_hdmi->output_bpc = vc4_state->output_bpc;
-	vc4_hdmi->output_format = vc4_state->output_format;
+	vc4_hdmi->output_bpc = conn_state->hdmi.output_bpc;
+	vc4_hdmi->output_format = conn_state->hdmi.output_format;
 	mutex_unlock(&vc4_hdmi->mutex);
 }
 
-static bool
-vc4_hdmi_sink_supports_format_bpc(const struct vc4_hdmi *vc4_hdmi,
-				  const struct drm_display_info *info,
-				  const struct drm_display_mode *mode,
-				  unsigned int format, unsigned int bpc)
-{
-	struct drm_device *dev = vc4_hdmi->connector.dev;
-	u8 vic = drm_match_cea_mode(mode);
-
-	if (vic == 1 && bpc != 8) {
-		drm_dbg(dev, "VIC1 requires a bpc of 8, got %u\n", bpc);
-		return false;
-	}
-
-	if (!info->is_hdmi &&
-	    (format != VC4_HDMI_OUTPUT_RGB || bpc != 8)) {
-		drm_dbg(dev, "DVI Monitors require an RGB output at 8 bpc\n");
-		return false;
-	}
-
-	switch (format) {
-	case VC4_HDMI_OUTPUT_RGB:
-		drm_dbg(dev, "RGB Format, checking the constraints.\n");
-
-		if (!(info->color_formats & DRM_COLOR_FORMAT_RGB444))
-			return false;
-
-		if (bpc == 10 && !(info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_30)) {
-			drm_dbg(dev, "10 BPC but sink doesn't support Deep Color 30.\n");
-			return false;
-		}
-
-		if (bpc == 12 && !(info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_36)) {
-			drm_dbg(dev, "12 BPC but sink doesn't support Deep Color 36.\n");
-			return false;
-		}
-
-		drm_dbg(dev, "RGB format supported in that configuration.\n");
-
-		return true;
-
-	case VC4_HDMI_OUTPUT_YUV422:
-		drm_dbg(dev, "YUV422 format, checking the constraints.\n");
-
-		if (!(info->color_formats & DRM_COLOR_FORMAT_YCBCR422)) {
-			drm_dbg(dev, "Sink doesn't support YUV422.\n");
-			return false;
-		}
-
-		if (bpc != 12) {
-			drm_dbg(dev, "YUV422 only supports 12 bpc.\n");
-			return false;
-		}
-
-		drm_dbg(dev, "YUV422 format supported in that configuration.\n");
-
-		return true;
-
-	case VC4_HDMI_OUTPUT_YUV444:
-		drm_dbg(dev, "YUV444 format, checking the constraints.\n");
-
-		if (!(info->color_formats & DRM_COLOR_FORMAT_YCBCR444)) {
-			drm_dbg(dev, "Sink doesn't support YUV444.\n");
-			return false;
-		}
-
-		if (bpc == 10 && !(info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_30)) {
-			drm_dbg(dev, "10 BPC but sink doesn't support Deep Color 30.\n");
-			return false;
-		}
-
-		if (bpc == 12 && !(info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_36)) {
-			drm_dbg(dev, "12 BPC but sink doesn't support Deep Color 36.\n");
-			return false;
-		}
-
-		drm_dbg(dev, "YUV444 format supported in that configuration.\n");
-
-		return true;
-	}
-
-	return false;
-}
-
 static enum drm_mode_status
-vc4_hdmi_encoder_clock_valid(const struct vc4_hdmi *vc4_hdmi,
-			     const struct drm_display_mode *mode,
-			     unsigned long long clock)
+vc4_hdmi_connector_clock_valid(const struct drm_connector *connector,
+			       const struct drm_display_mode *mode,
+			       unsigned long long clock)
 {
-	const struct drm_connector *connector = &vc4_hdmi->connector;
-	const struct drm_display_info *info = &connector->display_info;
+	const struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
 	struct vc4_dev *vc4 = to_vc4_dev(connector->dev);
 
 	if (clock > vc4_hdmi->variant->max_pixel_clock)
@@ -2035,125 +1670,13 @@ vc4_hdmi_encoder_clock_valid(const struct vc4_hdmi *vc4_hdmi,
 	    drm_mode_vrefresh(mode) >= 50)
 		return MODE_CLOCK_HIGH;
 
-	if (info->max_tmds_clock && clock > (info->max_tmds_clock * 1000))
-		return MODE_CLOCK_HIGH;
-
 	return MODE_OK;
 }
 
-static unsigned long long
-vc4_hdmi_encoder_compute_mode_clock(const struct drm_display_mode *mode,
-				    unsigned int bpc,
-				    enum vc4_hdmi_output_format fmt)
-{
-	unsigned long long clock = mode->clock * 1000ULL;
-
-	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
-		clock = clock * 2;
-
-	if (fmt == VC4_HDMI_OUTPUT_YUV422)
-		bpc = 8;
-
-	clock = clock * bpc;
-	do_div(clock, 8);
-
-	return clock;
-}
-
-static int
-vc4_hdmi_encoder_compute_clock(const struct vc4_hdmi *vc4_hdmi,
-			       struct vc4_hdmi_connector_state *vc4_state,
-			       const struct drm_display_mode *mode,
-			       unsigned int bpc, unsigned int fmt)
-{
-	unsigned long long clock;
-
-	clock = vc4_hdmi_encoder_compute_mode_clock(mode, bpc, fmt);
-	if (vc4_hdmi_encoder_clock_valid(vc4_hdmi, mode, clock) != MODE_OK)
-		return -EINVAL;
-
-	vc4_state->tmds_char_rate = clock;
-
-	return 0;
-}
-
-static int
-vc4_hdmi_encoder_compute_format(const struct vc4_hdmi *vc4_hdmi,
-				struct vc4_hdmi_connector_state *vc4_state,
-				const struct drm_display_mode *mode,
-				unsigned int bpc)
-{
-	struct drm_device *dev = vc4_hdmi->connector.dev;
-	const struct drm_connector *connector = &vc4_hdmi->connector;
-	const struct drm_display_info *info = &connector->display_info;
-	unsigned int format;
-
-	drm_dbg(dev, "Trying with an RGB output\n");
-
-	format = VC4_HDMI_OUTPUT_RGB;
-	if (vc4_hdmi_sink_supports_format_bpc(vc4_hdmi, info, mode, format, bpc)) {
-		int ret;
-
-		ret = vc4_hdmi_encoder_compute_clock(vc4_hdmi, vc4_state,
-						     mode, bpc, format);
-		if (!ret) {
-			vc4_state->output_format = format;
-			return 0;
-		}
-	}
-
-	drm_dbg(dev, "Failed, Trying with an YUV422 output\n");
-
-	format = VC4_HDMI_OUTPUT_YUV422;
-	if (vc4_hdmi_sink_supports_format_bpc(vc4_hdmi, info, mode, format, bpc)) {
-		int ret;
-
-		ret = vc4_hdmi_encoder_compute_clock(vc4_hdmi, vc4_state,
-						     mode, bpc, format);
-		if (!ret) {
-			vc4_state->output_format = format;
-			return 0;
-		}
-	}
-
-	drm_dbg(dev, "Failed. No Format Supported for that bpc count.\n");
-
-	return -EINVAL;
-}
-
-static int
-vc4_hdmi_encoder_compute_config(const struct vc4_hdmi *vc4_hdmi,
-				struct vc4_hdmi_connector_state *vc4_state,
-				const struct drm_display_mode *mode)
-{
-	struct drm_device *dev = vc4_hdmi->connector.dev;
-	struct drm_connector_state *conn_state = &vc4_state->base;
-	unsigned int max_bpc = clamp_t(unsigned int, conn_state->max_bpc, 8, 12);
-	unsigned int bpc;
-	int ret;
-
-	for (bpc = max_bpc; bpc >= 8; bpc -= 2) {
-		drm_dbg(dev, "Trying with a %d bpc output\n", bpc);
-
-		ret = vc4_hdmi_encoder_compute_format(vc4_hdmi, vc4_state,
-						      mode, bpc);
-		if (ret)
-			continue;
-
-		vc4_state->output_bpc = bpc;
-
-		drm_dbg(dev,
-			"Mode %ux%u @ %uHz: Found configuration: bpc: %u, fmt: %s, clock: %llu\n",
-			mode->hdisplay, mode->vdisplay, drm_mode_vrefresh(mode),
-			vc4_state->output_bpc,
-			vc4_hdmi_output_fmt_str(vc4_state->output_format),
-			vc4_state->tmds_char_rate);
-
-		break;
-	}
-
-	return ret;
-}
+static const struct drm_connector_hdmi_funcs vc4_hdmi_hdmi_connector_funcs = {
+	.tmds_char_rate_valid	= vc4_hdmi_connector_clock_valid,
+	.write_infoframe	= vc4_hdmi_write_infoframe,
+};
 
 #define WIFI_2_4GHz_CH1_MIN_FREQ	2400000000ULL
 #define WIFI_2_4GHz_CH1_MAX_FREQ	2422000000ULL
@@ -2163,16 +1686,9 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 					 struct drm_connector_state *conn_state)
 {
 	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
-	struct drm_connector *connector = &vc4_hdmi->connector;
-	struct drm_connector_state *old_conn_state =
-		drm_atomic_get_old_connector_state(conn_state->state, connector);
-	struct vc4_hdmi_connector_state *old_vc4_state =
-		conn_state_to_vc4_hdmi_conn_state(old_conn_state);
-	struct vc4_hdmi_connector_state *vc4_state = conn_state_to_vc4_hdmi_conn_state(conn_state);
 	struct drm_display_mode *mode = &crtc_state->adjusted_mode;
 	unsigned long long tmds_char_rate = mode->clock * 1000;
 	unsigned long long tmds_bit_rate;
-	int ret;
 
 	if (vc4_hdmi->variant->unsupported_odd_h_timings) {
 		if (mode->flags & DRM_MODE_FLAG_DBLCLK) {
@@ -2208,15 +1724,6 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 		tmds_char_rate = mode->clock * 1000;
 	}
 
-	ret = vc4_hdmi_encoder_compute_config(vc4_hdmi, vc4_state, mode);
-	if (ret)
-		return ret;
-
-	/* vc4_hdmi_encoder_compute_config may have changed output_bpc and/or output_format */
-	if (vc4_state->output_bpc != old_vc4_state->output_bpc ||
-	    vc4_state->output_format != old_vc4_state->output_format)
-		crtc_state->mode_changed = true;
-
 	return 0;
 }
 
@@ -2225,6 +1732,7 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
 			    const struct drm_display_mode *mode)
 {
 	struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+	unsigned long long rate;
 
 	if (vc4_hdmi->variant->unsupported_odd_h_timings &&
 	    !(mode->flags & DRM_MODE_FLAG_DBLCLK) &&
@@ -2232,7 +1740,8 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
 	     (mode->hsync_end % 2) || (mode->htotal % 2)))
 		return MODE_H_ILLEGAL;
 
-	return vc4_hdmi_encoder_clock_valid(vc4_hdmi, mode, mode->clock * 1000);
+	rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_RGB);
+	return vc4_hdmi_connector_clock_valid(&vc4_hdmi->connector, mode, rate);
 }
 
 static const struct drm_encoder_helper_funcs vc4_hdmi_encoder_helper_funcs = {
@@ -2424,7 +1933,6 @@ static int vc4_hdmi_audio_startup(struct device *dev, void *data)
 
 static void vc4_hdmi_audio_reset(struct vc4_hdmi *vc4_hdmi)
 {
-	struct drm_encoder *encoder = &vc4_hdmi->encoder.base;
 	struct device *dev = &vc4_hdmi->pdev->dev;
 	unsigned long flags;
 	int ret;
@@ -2432,7 +1940,7 @@ static void vc4_hdmi_audio_reset(struct vc4_hdmi *vc4_hdmi)
 	lockdep_assert_held(&vc4_hdmi->mutex);
 
 	vc4_hdmi->audio.streaming = false;
-	ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO, false);
+	ret = vc4_hdmi_stop_packet(vc4_hdmi, HDMI_INFOFRAME_TYPE_AUDIO, false);
 	if (ret)
 		dev_err(dev, "Failed to stop audio infoframe: %d\n", ret);
 
@@ -2523,7 +2031,7 @@ static int vc4_hdmi_audio_prepare(struct device *dev, void *data,
 {
 	struct vc4_hdmi *vc4_hdmi = dev_get_drvdata(dev);
 	struct drm_device *drm = vc4_hdmi->connector.dev;
-	struct drm_encoder *encoder = &vc4_hdmi->encoder.base;
+	struct drm_connector *connector = &vc4_hdmi->connector;
 	unsigned int sample_rate = params->sample_rate;
 	unsigned int channels = params->channels;
 	unsigned long flags;
@@ -2600,8 +2108,10 @@ static int vc4_hdmi_audio_prepare(struct device *dev, void *data,
 
 	spin_unlock_irqrestore(&vc4_hdmi->hw_lock, flags);
 
-	memcpy(&vc4_hdmi->audio.infoframe, &params->cea, sizeof(params->cea));
-	vc4_hdmi_set_audio_infoframe(encoder);
+	ret = drm_atomic_helper_connector_hdmi_update_audio_infoframe(connector,
+								      &params->cea);
+	if (ret)
+		goto out_dev_exit;
 
 out_dev_exit:
 	drm_dev_exit(idx);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 934d5d61485a..b37f1d2c3fe5 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -10,7 +10,6 @@
 
 struct vc4_hdmi;
 struct vc4_hdmi_register;
-struct vc4_hdmi_connector_state;
 
 enum vc4_hdmi_phy_channel {
 	PHY_LANE_0 = 0,
@@ -76,7 +75,7 @@ struct vc4_hdmi_variant {
 
 	/* Callback to initialize the PHY according to the connector state */
 	void (*phy_init)(struct vc4_hdmi *vc4_hdmi,
-			 struct vc4_hdmi_connector_state *vc4_conn_state);
+			 struct drm_connector_state *conn_state);
 
 	/* Callback to disable the PHY */
 	void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
@@ -110,19 +109,6 @@ struct vc4_hdmi_audio {
 	bool streaming;
 };
 
-enum vc4_hdmi_output_format {
-	VC4_HDMI_OUTPUT_RGB,
-	VC4_HDMI_OUTPUT_YUV422,
-	VC4_HDMI_OUTPUT_YUV444,
-	VC4_HDMI_OUTPUT_YUV420,
-};
-
-enum vc4_hdmi_broadcast_rgb {
-	VC4_HDMI_BROADCAST_RGB_AUTO,
-	VC4_HDMI_BROADCAST_RGB_FULL,
-	VC4_HDMI_BROADCAST_RGB_LIMITED,
-};
-
 /* General HDMI hardware state. */
 struct vc4_hdmi {
 	struct vc4_hdmi_audio audio;
@@ -135,8 +121,6 @@ struct vc4_hdmi {
 
 	struct delayed_work scrambling_work;
 
-	struct drm_property *broadcast_rgb_property;
-
 	struct i2c_adapter *ddc;
 	void __iomem *hdmicore_regs;
 	void __iomem *hd_regs;
@@ -218,16 +202,17 @@ struct vc4_hdmi {
 	bool scdc_enabled;
 
 	/**
-	 * @output_bpc: Copy of @vc4_connector_state.output_bpc for use
-	 * outside of KMS hooks. Protected by @mutex.
+	 * @output_bpc: Copy of @drm_connector_state.hdmi.output_bpc for
+	 * use outside of KMS hooks. Protected by @mutex.
 	 */
 	unsigned int output_bpc;
 
 	/**
-	 * @output_format: Copy of @vc4_connector_state.output_format
-	 * for use outside of KMS hooks. Protected by @mutex.
+	 * @output_format: Copy of
+	 * @drm_connector_state.hdmi.output_format for use outside of
+	 * KMS hooks. Protected by @mutex.
 	 */
-	enum vc4_hdmi_output_format output_format;
+	enum hdmi_colorspace output_format;
 };
 
 #define connector_to_vc4_hdmi(_connector)				\
@@ -240,25 +225,14 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
 	return container_of_const(_encoder, struct vc4_hdmi, encoder);
 }
 
-struct vc4_hdmi_connector_state {
-	struct drm_connector_state	base;
-	unsigned long long		tmds_char_rate;
-	unsigned int 			output_bpc;
-	enum vc4_hdmi_output_format	output_format;
-	enum vc4_hdmi_broadcast_rgb	broadcast_rgb;
-};
-
-#define conn_state_to_vc4_hdmi_conn_state(_state)			\
-	container_of_const(_state, struct vc4_hdmi_connector_state, base)
-
 void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
-		       struct vc4_hdmi_connector_state *vc4_conn_state);
+		       struct drm_connector_state *conn_state);
 void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
 void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
 void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
 
 void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
-		       struct vc4_hdmi_connector_state *vc4_conn_state);
+		       struct drm_connector_state *conn_state);
 void vc5_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
 void vc5_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
 void vc5_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
index ec24999bf96d..1f5507fc7a03 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
@@ -128,7 +128,7 @@
 #define OSCILLATOR_FREQUENCY	54000000
 
 void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
-		       struct vc4_hdmi_connector_state *conn_state)
+		       struct drm_connector_state *conn_state)
 {
 	unsigned long flags;
 
@@ -361,11 +361,11 @@ static void vc5_hdmi_reset_phy(struct vc4_hdmi *vc4_hdmi)
 }
 
 void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
-		       struct vc4_hdmi_connector_state *conn_state)
+		       struct drm_connector_state *conn_state)
 {
 	const struct phy_lane_settings *chan0_settings, *chan1_settings, *chan2_settings, *clock_settings;
 	const struct vc4_hdmi_variant *variant = vc4_hdmi->variant;
-	unsigned long long pixel_freq = conn_state->tmds_char_rate;
+	unsigned long long pixel_freq = conn_state->hdmi.tmds_char_rate;
 	unsigned long long vco_freq;
 	unsigned char word_sel;
 	unsigned long flags;

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:43 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:43 +0100
Subject: [PATCH v5 20/44] drm/vc4: tests: Remove vc4_dummy_plane structure
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-20-6538e19d634d@kernel.org>

The vc4_dummy_plane structure is an exact equivalent to vc4_plane, so we
don't need it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/vc4/tests/vc4_mock.c       |  6 ++----
 drivers/gpu/drm/vc4/tests/vc4_mock.h       |  9 ++-------
 drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 14 +++++---------
 3 files changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/vc4/tests/vc4_mock.c b/drivers/gpu/drm/vc4/tests/vc4_mock.c
index 63ca46f4cb35..1c1be39141ba 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_mock.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_mock.c
@@ -109,16 +109,14 @@ static const struct vc4_mock_desc vc5_mock =
 static int __build_one_pipe(struct kunit *test, struct drm_device *drm,
 			    const struct vc4_mock_pipe_desc *pipe)
 {
-	struct vc4_dummy_plane *dummy_plane;
 	struct drm_plane *plane;
 	struct vc4_dummy_crtc *dummy_crtc;
 	struct drm_crtc *crtc;
 	unsigned int i;
 
-	dummy_plane = vc4_dummy_plane(test, drm, DRM_PLANE_TYPE_PRIMARY);
-	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dummy_plane);
+	plane = vc4_dummy_plane(test, drm, DRM_PLANE_TYPE_PRIMARY);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, plane);
 
-	plane = &dummy_plane->plane.base;
 	dummy_crtc = vc4_mock_pv(test, drm, plane, pipe->data);
 	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dummy_crtc);
 
diff --git a/drivers/gpu/drm/vc4/tests/vc4_mock.h b/drivers/gpu/drm/vc4/tests/vc4_mock.h
index 2d0b339bd9f3..002b6218960c 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_mock.h
+++ b/drivers/gpu/drm/vc4/tests/vc4_mock.h
@@ -21,13 +21,8 @@ struct drm_crtc *vc4_find_crtc_for_encoder(struct kunit *test,
 	return NULL;
 }
 
-struct vc4_dummy_plane {
-	struct vc4_plane plane;
-};
-
-struct vc4_dummy_plane *vc4_dummy_plane(struct kunit *test,
-					struct drm_device *drm,
-					enum drm_plane_type type);
+struct drm_plane *vc4_dummy_plane(struct kunit *test, struct drm_device *drm,
+				  enum drm_plane_type type);
 
 struct vc4_dummy_crtc {
 	struct vc4_crtc crtc;
diff --git a/drivers/gpu/drm/vc4/tests/vc4_mock_plane.c b/drivers/gpu/drm/vc4/tests/vc4_mock_plane.c
index 62b18f5f41db..973f5f929097 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_mock_plane.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_mock_plane.c
@@ -22,15 +22,12 @@ static const uint32_t vc4_dummy_plane_formats[] = {
 	DRM_FORMAT_XRGB8888,
 };
 
-struct vc4_dummy_plane *vc4_dummy_plane(struct kunit *test,
-					struct drm_device *drm,
-					enum drm_plane_type type)
+struct drm_plane *vc4_dummy_plane(struct kunit *test, struct drm_device *drm,
+				  enum drm_plane_type type)
 {
-	struct vc4_dummy_plane *dummy_plane;
 	struct drm_plane *plane;
 
-	dummy_plane = drmm_universal_plane_alloc(drm,
-						 struct vc4_dummy_plane, plane.base,
+	plane = __drmm_universal_plane_alloc(drm, sizeof(struct drm_plane), 0,
 						 0,
 						 &vc4_dummy_plane_funcs,
 						 vc4_dummy_plane_formats,
@@ -38,10 +35,9 @@ struct vc4_dummy_plane *vc4_dummy_plane(struct kunit *test,
 						 NULL,
 						 DRM_PLANE_TYPE_PRIMARY,
 						 NULL);
-	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dummy_plane);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, plane);
 
-	plane = &dummy_plane->plane.base;
 	drm_plane_helper_add(plane, &vc4_dummy_plane_helper_funcs);
 
-	return dummy_plane;
+	return plane;
 }

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:38 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:38 +0100
Subject: [PATCH v5 15/44] drm/connector: hdmi: Compute bpc and format
 automatically
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-15-6538e19d634d@kernel.org>

Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.

The algorithm is the same one than the one already found in i915 and
vc4.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_atomic_state_helper.c          | 183 ++++++-
 .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 529 ++++++++++++++++++++-
 drivers/gpu/drm/tests/drm_kunit_edid.h             | 160 +++++++
 3 files changed, 860 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index a36edda590f8..2442b5a2d94f 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -682,6 +682,96 @@ static bool hdmi_is_full_range(const struct drm_connector *connector,
 	return drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_FULL ? true : false;
 }
 
+static bool
+sink_supports_format_bpc(const struct drm_connector *connector,
+			 const struct drm_display_info *info,
+			 const struct drm_display_mode *mode,
+			 unsigned int format, unsigned int bpc)
+{
+	struct drm_device *dev = connector->dev;
+	u8 vic = drm_match_cea_mode(mode);
+
+	if (vic == 1 && bpc != 8) {
+		drm_dbg(dev, "VIC1 requires a bpc of 8, got %u\n", bpc);
+		return false;
+	}
+
+	if (!info->is_hdmi &&
+	    (format != HDMI_COLORSPACE_RGB || bpc != 8)) {
+		drm_dbg(dev, "DVI Monitors require an RGB output at 8 bpc\n");
+		return false;
+	}
+
+	if (!(connector->hdmi.supported_formats & BIT(format))) {
+		drm_dbg(dev, "%s format unsupported by the connector.\n",
+			drm_hdmi_connector_get_output_format_name(format));
+		return false;
+	}
+
+	switch (format) {
+	case HDMI_COLORSPACE_RGB:
+		drm_dbg(dev, "RGB Format, checking the constraints.\n");
+
+		if (!(info->color_formats & DRM_COLOR_FORMAT_RGB444))
+			return false;
+
+		if (bpc == 10 && !(info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_30)) {
+			drm_dbg(dev, "10 BPC but sink doesn't support Deep Color 30.\n");
+			return false;
+		}
+
+		if (bpc == 12 && !(info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_36)) {
+			drm_dbg(dev, "12 BPC but sink doesn't support Deep Color 36.\n");
+			return false;
+		}
+
+		drm_dbg(dev, "RGB format supported in that configuration.\n");
+
+		return true;
+
+	case HDMI_COLORSPACE_YUV422:
+		drm_dbg(dev, "YUV422 format, checking the constraints.\n");
+
+		if (!(info->color_formats & DRM_COLOR_FORMAT_YCBCR422)) {
+			drm_dbg(dev, "Sink doesn't support YUV422.\n");
+			return false;
+		}
+
+		if (bpc != 12) {
+			drm_dbg(dev, "YUV422 only supports 12 bpc.\n");
+			return false;
+		}
+
+		drm_dbg(dev, "YUV422 format supported in that configuration.\n");
+
+		return true;
+
+	case HDMI_COLORSPACE_YUV444:
+		drm_dbg(dev, "YUV444 format, checking the constraints.\n");
+
+		if (!(info->color_formats & DRM_COLOR_FORMAT_YCBCR444)) {
+			drm_dbg(dev, "Sink doesn't support YUV444.\n");
+			return false;
+		}
+
+		if (bpc == 10 && !(info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_30)) {
+			drm_dbg(dev, "10 BPC but sink doesn't support Deep Color 30.\n");
+			return false;
+		}
+
+		if (bpc == 12 && !(info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_36)) {
+			drm_dbg(dev, "12 BPC but sink doesn't support Deep Color 36.\n");
+			return false;
+		}
+
+		drm_dbg(dev, "YUV444 format supported in that configuration.\n");
+
+		return true;
+	}
+
+	return false;
+}
+
 static enum drm_mode_status
 hdmi_clock_valid(const struct drm_connector *connector,
 		 const struct drm_display_mode *mode,
@@ -726,6 +816,95 @@ hdmi_compute_clock(const struct drm_connector *connector,
 	return 0;
 }
 
+static bool
+hdmi_try_format_bpc(const struct drm_connector *connector,
+		    struct drm_connector_state *state,
+		    const struct drm_display_mode *mode,
+		    unsigned int bpc, enum hdmi_colorspace fmt)
+{
+	const struct drm_display_info *info = &connector->display_info;
+	struct drm_device *dev = connector->dev;
+	int ret;
+
+	drm_dbg(dev, "Trying %s output format\n",
+		drm_hdmi_connector_get_output_format_name(fmt));
+
+	if (!sink_supports_format_bpc(connector, info, mode, fmt, bpc)) {
+		drm_dbg(dev, "%s output format not supported with %u bpc\n",
+			drm_hdmi_connector_get_output_format_name(fmt), bpc);
+		return false;
+	}
+
+	ret = hdmi_compute_clock(connector, state, mode, bpc, fmt);
+	if (ret) {
+		drm_dbg(dev, "Couldn't compute clock for %s output format and %u bpc\n",
+			drm_hdmi_connector_get_output_format_name(fmt), bpc);
+		return false;
+	}
+
+	drm_dbg(dev, "%s output format supported with %u (TMDS char rate: %llu Hz)\n",
+		drm_hdmi_connector_get_output_format_name(fmt), bpc, state->hdmi.tmds_char_rate);
+
+	return true;
+}
+
+static int
+hdmi_compute_format(const struct drm_connector *connector,
+		    struct drm_connector_state *state,
+		    const struct drm_display_mode *mode,
+		    unsigned int bpc)
+{
+	struct drm_device *dev = connector->dev;
+
+	if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_RGB)) {
+		state->hdmi.output_format = HDMI_COLORSPACE_RGB;
+		return 0;
+	}
+
+	if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_YUV422)) {
+		state->hdmi.output_format = HDMI_COLORSPACE_YUV422;
+		return 0;
+	}
+
+	drm_dbg(dev, "Failed. No Format Supported for that bpc count.\n");
+
+	return -EINVAL;
+}
+
+static int
+hdmi_compute_config(const struct drm_connector *connector,
+		    struct drm_connector_state *state,
+		    const struct drm_display_mode *mode)
+{
+	struct drm_device *dev = connector->dev;
+	unsigned int max_bpc = clamp_t(unsigned int,
+				       state->max_bpc,
+				       8, connector->max_bpc);
+	unsigned int bpc;
+	int ret;
+
+	for (bpc = max_bpc; bpc >= 8; bpc -= 2) {
+		drm_dbg(dev, "Trying with a %d bpc output\n", bpc);
+
+		ret = hdmi_compute_format(connector, state, mode, bpc);
+		if (ret)
+			continue;
+
+		state->hdmi.output_bpc = bpc;
+
+		drm_dbg(dev,
+			"Mode %ux%u @ %uHz: Found configuration: bpc: %u, fmt: %s, clock: %llu\n",
+			mode->hdisplay, mode->vdisplay, drm_mode_vrefresh(mode),
+			state->hdmi.output_bpc,
+			drm_hdmi_connector_get_output_format_name(state->hdmi.output_format),
+			state->hdmi.tmds_char_rate);
+
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
 /**
  * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
  * @connector: DRM Connector
@@ -751,9 +930,7 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
 
 	new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
 
-	ret = hdmi_compute_clock(connector, new_state, mode,
-				 new_state->hdmi.output_bpc,
-				 new_state->hdmi.output_format);
+	ret = hdmi_compute_config(connector, new_state, mode);
 	if (ret)
 		return ret;
 
diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
index e7dbdd4a4e7f..860e34b00fee 100644
--- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
@@ -70,9 +70,6 @@ static int light_up_connector(struct kunit *test,
 	conn_state = drm_atomic_get_connector_state(state, connector);
 	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
 
-	conn_state->hdmi.output_bpc = connector->max_bpc;
-	conn_state->hdmi.output_format = HDMI_COLORSPACE_RGB;
-
 	ret = drm_atomic_set_crtc_for_connector(conn_state, crtc);
 	KUNIT_EXPECT_EQ(test, ret, 0);
 
@@ -720,10 +717,15 @@ static void drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
 						     10);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
 	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
 	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
 
-	conn = &priv->connector;
 	preferred = find_preferred_mode(conn);
 	KUNIT_ASSERT_NOT_NULL(test, preferred);
 
@@ -741,11 +743,11 @@ static void drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
 	old_conn_state = drm_atomic_get_old_connector_state(state, conn);
 	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
 
-	new_conn_state->hdmi.output_bpc = 8;
+	new_conn_state->max_requested_bpc = 8;
 
 	KUNIT_ASSERT_NE(test,
-			old_conn_state->hdmi.output_bpc,
-			new_conn_state->hdmi.output_bpc);
+			old_conn_state->max_requested_bpc,
+			new_conn_state->max_requested_bpc);
 
 	ret = drm_atomic_check_only(state);
 	KUNIT_ASSERT_EQ(test, ret, 0);
@@ -789,10 +791,15 @@ static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
 						     10);
 	KUNIT_ASSERT_NOT_NULL(test, priv);
 
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
 	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
 	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
 
-	conn = &priv->connector;
 	preferred = find_preferred_mode(conn);
 	KUNIT_ASSERT_NOT_NULL(test, preferred);
 
@@ -832,6 +839,56 @@ static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
 	KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
 }
 
+/*
+ * Test that if we have an HDMI connector but a !HDMI display, we always
+ * output RGB with 8 bpc.
+ */
+static void drm_test_check_output_bpc_dvi(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_info *info;
+	struct drm_display_mode *preferred;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB) |
+						     BIT(HDMI_COLORSPACE_YUV422) |
+						     BIT(HDMI_COLORSPACE_YUV444),
+						     12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_dvi_1080p,
+				 ARRAY_SIZE(test_edid_dvi_1080p));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	info = &conn->display_info;
+	KUNIT_ASSERT_FALSE(test, info->is_hdmi);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 8);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+}
+
 /*
  * Test that when doing a commit which would use RGB 8bpc, the TMDS
  * clock rate stored in the connector state is equal to the mode clock
@@ -1024,6 +1081,452 @@ static void drm_test_check_hdmi_funcs_reject_rate(struct kunit *test)
 	KUNIT_EXPECT_LT(test, ret, 0);
 }
 
+/*
+ * Test that if:
+ * - We have an HDMI connector supporting RGB only
+ * - The chosen mode has a TMDS character rate higher than the display
+ *   supports in RGB/12bpc
+ * - The chosen mode has a TMDS character rate lower than the display
+ *   supports in RGB/10bpc.
+ *
+ * Then we will pick the latter, and the computed TMDS character rate
+ * will be equal to 1.25 times the mode pixel clock.
+ */
+static void drm_test_check_max_tmds_rate_bpc_fallback(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_info *info;
+	struct drm_display_mode *preferred;
+	unsigned long long rate;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	info = &conn->display_info;
+	KUNIT_ASSERT_TRUE(test, info->is_hdmi);
+	KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+	KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_GT(test, rate, info->max_tmds_clock * 1000);
+
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 10, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 10);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1250);
+}
+
+/*
+ * Test that if:
+ * - We have an HDMI connector supporting both RGB and YUV422 and up to
+ *   12 bpc
+ * - The chosen mode has a TMDS character rate higher than the display
+ *   supports in RGB/12bpc
+ * - The chosen mode has a TMDS character rate lower than the display
+ *   supports in YUV422/12bpc.
+ *
+ * Then we will pick the latter, and the computed TMDS character rate
+ * will be equal to the mode pixel clock.
+ */
+static void drm_test_check_max_tmds_rate_format_fallback(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_info *info;
+	struct drm_display_mode *preferred;
+	unsigned long long rate;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB) |
+						     BIT(HDMI_COLORSPACE_YUV422) |
+						     BIT(HDMI_COLORSPACE_YUV444),
+						     12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	info = &conn->display_info;
+	KUNIT_ASSERT_TRUE(test, info->is_hdmi);
+	KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+	KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
+
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_GT(test, rate, info->max_tmds_clock * 1000);
+
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_YUV422);
+	KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 12);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_YUV422);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1000);
+}
+
+/*
+ * Test that if a driver and screen supports RGB and YUV formats, and we
+ * try to set the VIC 1 mode, we end up with 8bpc RGB even if we could
+ * have had a higher bpc.
+ */
+static void drm_test_check_output_bpc_format_vic_1(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_info *info;
+	struct drm_display_mode *mode;
+	unsigned long long rate;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB) |
+						     BIT(HDMI_COLORSPACE_YUV422) |
+						     BIT(HDMI_COLORSPACE_YUV444),
+						     12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	info = &conn->display_info;
+	KUNIT_ASSERT_TRUE(test, info->is_hdmi);
+	KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	mode = drm_display_mode_from_cea_vic(drm, 1);
+	KUNIT_ASSERT_NOT_NULL(test, mode);
+
+	/*
+	 * NOTE: We can't use drm_connector_hdmi_compute_mode_clock()
+	 * here because we're trying to get the rate of an invalid
+	 * configuration.
+	 *
+	 * Thus, we have to calculate the rate by hand.
+	 */
+	rate = mode->clock * 1500;
+	KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, mode, ctx);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 8);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+}
+
+/*
+ * Test that if a driver supports only RGB but the screen also supports
+ * YUV formats, we only end up with an RGB format.
+ */
+static void drm_test_check_output_bpc_format_driver_rgb_only(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_info *info;
+	struct drm_display_mode *preferred;
+	unsigned long long rate;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	info = &conn->display_info;
+	KUNIT_ASSERT_TRUE(test, info->is_hdmi);
+	KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	/*
+	 * We're making sure that YUV422 would be the preferred option
+	 * here: we're always favouring higher bpc, we can't have RGB
+	 * because the TMDS character rate exceeds the maximum supported
+	 * by the display, and YUV422 works for that display.
+	 *
+	 * But since the driver only supports RGB, we should fallback to
+	 * a lower bpc with RGB.
+	 */
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_GT(test, rate, info->max_tmds_clock * 1000);
+
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_YUV422);
+	KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_EXPECT_LT(test, conn_state->hdmi.output_bpc, 12);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+}
+
+/*
+ * Test that if a screen supports only RGB but the driver also supports
+ * YUV formats, we only end up with an RGB format.
+ */
+static void drm_test_check_output_bpc_format_display_rgb_only(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_info *info;
+	struct drm_display_mode *preferred;
+	unsigned long long rate;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB) |
+						     BIT(HDMI_COLORSPACE_YUV422) |
+						     BIT(HDMI_COLORSPACE_YUV444),
+						     12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_max_200mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_200mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	info = &conn->display_info;
+	KUNIT_ASSERT_TRUE(test, info->is_hdmi);
+	KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	/*
+	 * We're making sure that YUV422 would be the preferred option
+	 * here: we're always favouring higher bpc, we can't have RGB
+	 * because the TMDS character rate exceeds the maximum supported
+	 * by the display, and YUV422 works for that display.
+	 *
+	 * But since the display only supports RGB, we should fallback to
+	 * a lower bpc with RGB.
+	 */
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_GT(test, rate, info->max_tmds_clock * 1000);
+
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_YUV422);
+	KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_EXPECT_LT(test, conn_state->hdmi.output_bpc, 12);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+}
+
+/*
+ * Test that if a display supports higher bpc but the driver only
+ * supports 8 bpc, we only end up with 8 bpc even if we could have had a
+ * higher bpc.
+ */
+static void drm_test_check_output_bpc_format_driver_8bpc_only(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_info *info;
+	struct drm_display_mode *preferred;
+	unsigned long long rate;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB),
+						     8);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	info = &conn->display_info;
+	KUNIT_ASSERT_TRUE(test, info->is_hdmi);
+	KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	/*
+	 * We're making sure that we have headroom on the TMDS character
+	 * clock to actually use 12bpc.
+	 */
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 8);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+}
+
+/*
+ * Test that if a driver supports higher bpc but the display only
+ * supports 8 bpc, we only end up with 8 bpc even if we could have had a
+ * higher bpc.
+ */
+static void drm_test_check_output_bpc_format_display_8bpc_only(struct kunit *test)
+{
+	struct drm_atomic_helper_connector_hdmi_priv *priv;
+	struct drm_modeset_acquire_ctx *ctx;
+	struct drm_connector_state *conn_state;
+	struct drm_display_info *info;
+	struct drm_display_mode *preferred;
+	unsigned long long rate;
+	struct drm_connector *conn;
+	struct drm_device *drm;
+	struct drm_crtc *crtc;
+	int ret;
+
+	priv = drm_atomic_helper_connector_hdmi_init(test,
+						     BIT(HDMI_COLORSPACE_RGB) |
+						     BIT(HDMI_COLORSPACE_YUV422) |
+						     BIT(HDMI_COLORSPACE_YUV444),
+						     12);
+	KUNIT_ASSERT_NOT_NULL(test, priv);
+
+	conn = &priv->connector;
+	ret = set_connector_edid(test, conn,
+				 test_edid_hdmi_1080p_rgb_max_340mhz,
+				 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_340mhz));
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	info = &conn->display_info;
+	KUNIT_ASSERT_TRUE(test, info->is_hdmi);
+	KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
+
+	ctx = drm_kunit_helper_acquire_ctx_alloc(test);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	preferred = find_preferred_mode(conn);
+	KUNIT_ASSERT_NOT_NULL(test, preferred);
+
+	/*
+	 * We're making sure that we have headroom on the TMDS character
+	 * clock to actually use 12bpc.
+	 */
+	rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
+	KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
+
+	drm = &priv->drm;
+	crtc = priv->crtc;
+	ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
+	KUNIT_EXPECT_EQ(test, ret, 0);
+
+	conn_state = conn->state;
+	KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 8);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+}
+
 static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
@@ -1034,8 +1537,16 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
 	KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
 	KUNIT_CASE(drm_test_check_hdmi_funcs_reject_rate),
+	KUNIT_CASE(drm_test_check_max_tmds_rate_bpc_fallback),
+	KUNIT_CASE(drm_test_check_max_tmds_rate_format_fallback),
 	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
 	KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
+	KUNIT_CASE(drm_test_check_output_bpc_dvi),
+	KUNIT_CASE(drm_test_check_output_bpc_format_vic_1),
+	KUNIT_CASE(drm_test_check_output_bpc_format_display_8bpc_only),
+	KUNIT_CASE(drm_test_check_output_bpc_format_display_rgb_only),
+	KUNIT_CASE(drm_test_check_output_bpc_format_driver_8bpc_only),
+	KUNIT_CASE(drm_test_check_output_bpc_format_driver_rgb_only),
 	KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_8bpc),
 	KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_10bpc),
 	KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_12bpc),
@@ -1167,7 +1678,7 @@ static void drm_test_check_format_value(struct kunit *test)
 
 	conn = &priv->connector;
 	conn_state = conn->state;
-	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
+	KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, 0);
 }
 
 /*
diff --git a/drivers/gpu/drm/tests/drm_kunit_edid.h b/drivers/gpu/drm/tests/drm_kunit_edid.h
index 24f3377ef0f0..3e3527c58c31 100644
--- a/drivers/gpu/drm/tests/drm_kunit_edid.h
+++ b/drivers/gpu/drm/tests/drm_kunit_edid.h
@@ -1,6 +1,64 @@
 #ifndef DRM_KUNIT_EDID_H_
 #define DRM_KUNIT_EDID_H_
 
+/*
+ * edid-decode (hex):
+ *
+ * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
+ * 00 21 01 03 81 a0 5a 78 0a 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01
+ * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
+ * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
+ * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
+ * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ab
+ *
+ * ----------------
+ *
+ * Block 0, Base EDID:
+ *   EDID Structure Version & Revision: 1.3
+ *   Vendor & Product Identification:
+ *     Manufacturer: LNX
+ *     Model: 42
+ *     Made in: 2023
+ *   Basic Display Parameters & Features:
+ *     Digital display
+ *     DFP 1.x compatible TMDS
+ *     Maximum image size: 160 cm x 90 cm
+ *     Gamma: 2.20
+ *     RGB color display
+ *     First detailed timing is the preferred timing
+ *   Color Characteristics:
+ *     Red  : 0.0000, 0.0000
+ *     Green: 0.0000, 0.0000
+ *     Blue : 0.0000, 0.0000
+ *     White: 0.0000, 0.0000
+ *   Established Timings I & II: none
+ *   Standard Timings: none
+ *   Detailed Timing Descriptors:
+ *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
+ *                  Hfront   88 Hsync  44 Hback  148 Hpol P
+ *                  Vfront    4 Vsync   5 Vback   36 Vpol P
+ *     Display Product Name: 'Test EDID'
+ *     Display Range Limits:
+ *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
+ *     Dummy Descriptor:
+ * Checksum: 0xab
+ */
+const unsigned char test_edid_dvi_1080p[] = {
+  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
+  0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
+  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
+  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
+  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
+  0x46, 0x1e, 0x46, 0x0f, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
+  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xab
+};
+
 /*
  * edid-decode (hex):
  *
@@ -103,6 +161,108 @@ const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz[] = {
   0x00, 0x00, 0x00, 0xd0
 };
 
+/*
+ * edid-decode (hex):
+ *
+ * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
+ * 00 21 01 03 81 a0 5a 78 02 00 00 00 00 00 00 00
+ * 00 00 00 20 00 00 01 01 01 01 01 01 01 01 01 01
+ * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
+ * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
+ * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
+ * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 92
+ *
+ * 02 03 1b 81 e3 05 00 20 41 10 e2 00 4a 6d 03 0c
+ * 00 12 34 00 28 20 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0
+ *
+ * ----------------
+ *
+ * Block 0, Base EDID:
+ *   EDID Structure Version & Revision: 1.3
+ *   Vendor & Product Identification:
+ *     Manufacturer: LNX
+ *     Model: 42
+ *     Made in: 2023
+ *   Basic Display Parameters & Features:
+ *     Digital display
+ *     DFP 1.x compatible TMDS
+ *     Maximum image size: 160 cm x 90 cm
+ *     Gamma: 2.20
+ *     Monochrome or grayscale display
+ *     First detailed timing is the preferred timing
+ *   Color Characteristics:
+ *     Red  : 0.0000, 0.0000
+ *     Green: 0.0000, 0.0000
+ *     Blue : 0.0000, 0.0000
+ *     White: 0.0000, 0.0000
+ *   Established Timings I & II:
+ *     DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
+ *   Standard Timings: none
+ *   Detailed Timing Descriptors:
+ *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
+ *                  Hfront   88 Hsync  44 Hback  148 Hpol P
+ *                  Vfront    4 Vsync   5 Vback   36 Vpol P
+ *     Display Product Name: 'Test EDID'
+ *     Display Range Limits:
+ *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
+ *     Dummy Descriptor:
+ *   Extension blocks: 1
+ * Checksum: 0x92
+ *
+ * ----------------
+ *
+ * Block 1, CTA-861 Extension Block:
+ *   Revision: 3
+ *   Underscans IT Video Formats by default
+ *   Native detailed modes: 1
+ *   Colorimetry Data Block:
+ *     sRGB
+ *   Video Data Block:
+ *     VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
+ *   Video Capability Data Block:
+ *     YCbCr quantization: No Data
+ *     RGB quantization: Selectable (via AVI Q)
+ *     PT scan behavior: No Data
+ *     IT scan behavior: Always Underscanned
+ *     CE scan behavior: Always Underscanned
+ *   Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
+ *     Source physical address: 1.2.3.4
+ *     Maximum TMDS clock: 340 MHz
+ *     Extended HDMI video details:
+ * Checksum: 0xd0  Unused space in Extension Block: 100 bytes
+ */
+const unsigned char test_edid_hdmi_1080p_rgb_max_340mhz[] = {
+  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
+  0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20,
+  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
+  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
+  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
+  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
+  0x46, 0x00, 0x00, 0xc4, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
+  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x41, 0x02, 0x03, 0x1b, 0x81,
+  0xe3, 0x05, 0x00, 0x20, 0x41, 0x10, 0xe2, 0x00, 0x4a, 0x6d, 0x03, 0x0c,
+  0x00, 0x12, 0x34, 0x00, 0x44, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0xd0
+};
+
 /*
  * edid-decode (hex):
  *

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:40 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:40 +0100
Subject: [PATCH v5 17/44] drm/connector: hdmi: Create Infoframe DebugFS
 entries
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-17-6538e19d634d@kernel.org>

There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.

In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.

Both would be much easier if we were to expose the infoframes programmed
in the hardware. It won't be perfect since we have no guarantee that
it's actually what goes through the wire, but it's the best we can do.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/drm_debugfs.c | 110 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 110 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 02e7481758c0..dab54f14d313 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -522,6 +522,114 @@ static const struct file_operations drm_connector_fops = {
 	.write = connector_write
 };
 
+struct debugfs_wrapper {
+	struct drm_connector *connector;
+	struct drm_connector_hdmi_infoframe *frame;
+};
+
+#define HDMI_MAX_INFOFRAME_SIZE		29
+
+static ssize_t
+infoframe_read(struct file *filp, char __user *ubuf, size_t count, loff_t *ppos)
+{
+	const struct debugfs_wrapper *wrapper = filp->private_data;
+	struct drm_connector *connector = wrapper->connector;
+	struct drm_connector_hdmi_infoframe *infoframe = wrapper->frame;
+	union hdmi_infoframe *frame = &infoframe->data;
+	u8 buf[HDMI_MAX_INFOFRAME_SIZE];
+	ssize_t len = 0;
+
+	mutex_lock(&connector->hdmi.infoframes.lock);
+
+	if (!infoframe->set)
+		goto out;
+
+	len = hdmi_infoframe_pack(frame, buf, sizeof(buf));
+	if (len < 0)
+		goto out;
+
+	len = simple_read_from_buffer(ubuf, count, ppos, buf, len);
+
+out:
+	mutex_unlock(&connector->hdmi.infoframes.lock);
+	return len;
+}
+
+static const struct file_operations infoframe_fops = {
+	.owner   = THIS_MODULE,
+	.open    = simple_open,
+	.read    = infoframe_read,
+};
+
+static int create_hdmi_infoframe_file(struct drm_connector *connector,
+				      struct dentry *parent,
+				      const char *filename,
+				      struct drm_connector_hdmi_infoframe *frame)
+{
+	struct drm_device *dev = connector->dev;
+	struct debugfs_wrapper *wrapper;
+	struct dentry *file;
+
+	wrapper = drmm_kzalloc(dev, sizeof(*wrapper), GFP_KERNEL);
+	if (!wrapper)
+		return -ENOMEM;
+
+	wrapper->connector = connector;
+	wrapper->frame = frame;
+
+	file = debugfs_create_file(filename, 0400, parent, wrapper, &infoframe_fops);
+	if (IS_ERR(file))
+		return PTR_ERR(file);
+
+	return 0;
+}
+
+#define CREATE_HDMI_INFOFRAME_FILE(c, p, i)		\
+	create_hdmi_infoframe_file(c, p, #i, &(c)->hdmi.infoframes.i)
+
+static int create_hdmi_infoframe_files(struct drm_connector *connector,
+				       struct dentry *parent)
+{
+	int ret;
+
+	ret = CREATE_HDMI_INFOFRAME_FILE(connector, parent, audio);
+	if (ret)
+		return ret;
+
+	ret = CREATE_HDMI_INFOFRAME_FILE(connector, parent, avi);
+	if (ret)
+		return ret;
+
+	ret = CREATE_HDMI_INFOFRAME_FILE(connector, parent, hdr_drm);
+	if (ret)
+		return ret;
+
+	ret = CREATE_HDMI_INFOFRAME_FILE(connector, parent, spd);
+	if (ret)
+		return ret;
+
+	ret = CREATE_HDMI_INFOFRAME_FILE(connector, parent, hdmi);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static void hdmi_debugfs_add(struct drm_connector *connector)
+{
+	struct dentry *dir;
+
+	if (!(connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+	      connector->connector_type == DRM_MODE_CONNECTOR_HDMIB))
+		return;
+
+	dir = debugfs_create_dir("infoframes", connector->debugfs_entry);
+	if (IS_ERR(dir))
+		return;
+
+	create_hdmi_infoframe_files(connector, dir);
+}
+
 void drm_debugfs_connector_add(struct drm_connector *connector)
 {
 	struct drm_device *dev = connector->dev;
@@ -549,6 +657,8 @@ void drm_debugfs_connector_add(struct drm_connector *connector)
 	debugfs_create_file("output_bpc", 0444, root, connector,
 			    &output_bpc_fops);
 
+	hdmi_debugfs_add(connector);
+
 	if (connector->funcs->debugfs_init)
 		connector->funcs->debugfs_init(connector, root);
 }

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:44 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:44 +0100
Subject: [PATCH v5 21/44] drm/vc4: tests: Convert to plane creation helper
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-21-6538e19d634d@kernel.org>

Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++++++-----------------------
 1 file changed, 8 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vc4/tests/vc4_mock_plane.c b/drivers/gpu/drm/vc4/tests/vc4_mock_plane.c
index 973f5f929097..14357db82238 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_mock_plane.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_mock_plane.c
@@ -1,43 +1,25 @@
 // SPDX-License-Identifier: GPL-2.0
 
-#include <drm/drm_atomic_state_helper.h>
-#include <drm/drm_fourcc.h>
-#include <drm/drm_modeset_helper_vtables.h>
+#include <drm/drm_kunit_helpers.h>
 #include <drm/drm_plane.h>
 
 #include <kunit/test.h>
 
 #include "vc4_mock.h"
 
-static const struct drm_plane_helper_funcs vc4_dummy_plane_helper_funcs = {
-};
-
-static const struct drm_plane_funcs vc4_dummy_plane_funcs = {
-	.atomic_destroy_state	= drm_atomic_helper_plane_destroy_state,
-	.atomic_duplicate_state	= drm_atomic_helper_plane_duplicate_state,
-	.reset			= drm_atomic_helper_plane_reset,
-};
-
-static const uint32_t vc4_dummy_plane_formats[] = {
-	DRM_FORMAT_XRGB8888,
-};
-
 struct drm_plane *vc4_dummy_plane(struct kunit *test, struct drm_device *drm,
 				  enum drm_plane_type type)
 {
 	struct drm_plane *plane;
 
-	plane = __drmm_universal_plane_alloc(drm, sizeof(struct drm_plane), 0,
-						 0,
-						 &vc4_dummy_plane_funcs,
-						 vc4_dummy_plane_formats,
-						 ARRAY_SIZE(vc4_dummy_plane_formats),
-						 NULL,
-						 DRM_PLANE_TYPE_PRIMARY,
-						 NULL);
+	KUNIT_ASSERT_EQ(test, type, DRM_PLANE_TYPE_PRIMARY);
+
+	plane = drm_kunit_helper_create_primary_plane(test, drm,
+						      NULL,
+						      NULL,
+						      NULL, 0,
+						      NULL);
 	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, plane);
 
-	drm_plane_helper_add(plane, &vc4_dummy_plane_helper_funcs);
-
 	return plane;
 }

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:45 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:45 +0100
Subject: [PATCH v5 22/44] drm/rockchip: inno_hdmi: Remove useless
 mode_fixup
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-22-6538e19d634d@kernel.org>

The mode_fixup implementation doesn't do anything, so we can simply
remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 6e5b922a121e..cc48cbf85f31 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -517,13 +517,6 @@ static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
 	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
 }
 
-static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
-					 const struct drm_display_mode *mode,
-					 struct drm_display_mode *adj_mode)
-{
-	return true;
-}
-
 static int
 inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 			       struct drm_crtc_state *crtc_state,
@@ -540,7 +533,6 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
 	.enable     = inno_hdmi_encoder_enable,
 	.disable    = inno_hdmi_encoder_disable,
-	.mode_fixup = inno_hdmi_encoder_mode_fixup,
 	.mode_set   = inno_hdmi_encoder_mode_set,
 	.atomic_check = inno_hdmi_encoder_atomic_check,
 };

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:47 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:47 +0100
Subject: [PATCH v5 24/44] drm/rockchip: inno_hdmi: Switch encoder hooks to
 atomic
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-24-6538e19d634d@kernel.org>

The inno_hdmi encoder still uses the !atomic variants of enable, disable
and modeset. Convert to their atomic equivalents.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 4f5844fc115a..cc86d273ca4a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -491,22 +491,25 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 }
 
 static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-				       struct drm_display_mode *mode,
-				       struct drm_display_mode *adj_mode)
+				       struct drm_crtc_state *crtc_state,
+				       struct drm_connector_state *conn_state)
 {
+	struct drm_display_mode *adj_mode = &crtc_state->adjusted_mode;
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_setup(hdmi, adj_mode);
 }
 
-static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
+				     struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
+				      struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
@@ -527,10 +530,10 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 }
 
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
-	.enable     = inno_hdmi_encoder_enable,
-	.disable    = inno_hdmi_encoder_disable,
-	.mode_set   = inno_hdmi_encoder_mode_set,
-	.atomic_check = inno_hdmi_encoder_atomic_check,
+	.atomic_check	= inno_hdmi_encoder_atomic_check,
+	.atomic_enable	= inno_hdmi_encoder_enable,
+	.atomic_disable	= inno_hdmi_encoder_disable,
+	.atomic_mode_set	= inno_hdmi_encoder_mode_set,
 };
 
 static enum drm_connector_status

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:46 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:46 +0100
Subject: [PATCH v5 23/44] drm/rockchip: inno_hdmi: Remove useless copy of
 drm_display_mode
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-23-6538e19d634d@kernel.org>

The driver maintains a copy of the adjusted mode but doesn't use it
anywhere. Remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index cc48cbf85f31..4f5844fc115a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -62,7 +62,6 @@ struct inno_hdmi {
 	unsigned int tmds_rate;
 
 	struct hdmi_data_info	hdmi_data;
-	struct drm_display_mode previous_mode;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -498,9 +497,6 @@ static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_setup(hdmi, adj_mode);
-
-	/* Store the display mode for plugin/DPMS poweron events */
-	drm_mode_copy(&hdmi->previous_mode, adj_mode);
 }
 
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)

-- 
2.43.0



From wangkefeng.wang at huawei.com  Thu Dec  7 07:50:32 2023
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Thu, 7 Dec 2023 23:50:32 +0800
Subject: [PATCH v8 00/10] Multi-size THP for anonymous memory
In-Reply-To: <82068e6a-937b-43db-8496-76fdf3158080@arm.com>
References: <20231204102027.57185-1-ryan.roberts@arm.com>
 <b8f5a47a-af1e-44ed-a89b-460d0be56d2c@huawei.com>
 <82068e6a-937b-43db-8496-76fdf3158080@arm.com>
Message-ID: <b2876d37-a342-41f6-9613-dd4bfaa5841b@huawei.com>



On 2023/12/6 18:08, Ryan Roberts wrote:
> On 05/12/2023 14:19, Kefeng Wang wrote:
>>
>>
>> On 2023/12/4 18:20, Ryan Roberts wrote:
>>> Hi All,
>>>
>>> A new week, a new version, a new name... This is v8 of a series to implement
>>> multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
>>> and "large anonymous folios"). Matthew objected to "small huge" so hopefully
>>> this fares better.
>>>
>>> The objective of this is to improve performance by allocating larger chunks of
>>> memory during anonymous page faults:
>>>
>>> 1) Since SW (the kernel) is dealing with larger chunks of memory than base
>>>  ??? pages, there are efficiency savings to be had; fewer page faults, batched PTE
>>>  ??? and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
>>>  ??? overhead. This should benefit all architectures.
>>> 2) Since we are now mapping physically contiguous chunks of memory, we can take
>>>  ??? advantage of HW TLB compression techniques. A reduction in TLB pressure
>>>  ??? speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
>>>  ??? TLB entries; "the contiguous bit" (architectural) and HPA (uarch).
>>>
>>> This version changes the name and tidies up some of the kernel code and test
>>> code, based on feedback against v7 (see change log for details).
>>>
>>> By default, the existing behaviour (and performance) is maintained. The user
>>> must explicitly enable multi-size THP to see the performance benefit. This is
>>> done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
>>> David for the suggestion)! This interface is inspired by the existing
>>> per-hugepage-size sysfs interface used by hugetlb, provides full backwards
>>> compatibility with the existing PMD-size THP interface, and provides a base for
>>> future extensibility. See [8] for detailed discussion of the interface.
>>>
>>> This series is based on mm-unstable (715b67adf4c8).
>>>
>>>
>>> Prerequisites
>>> =============
>>>
>>> Some work items identified as being prerequisites are listed on page 3 at [9].
>>> The summary is:
>>>
>>> | item????????????????????????? | status????????????????? |
>>> |:------------------------------|:------------------------|
>>> | mlock???????????????????????? | In mainline (v6.7)????? |
>>> | madvise?????????????????????? | In mainline (v6.6)????? |
>>> | compaction??????????????????? | v1 posted [10]????????? |
>>> | numa balancing??????????????? | Investigated: see below |
>>> | user-triggered page migration | In mainline (v6.7)????? |
>>> | khugepaged collapse?????????? | In mainline (NOP)?????? |
>>>
>>> On NUMA balancing, which currently ignores any PTE-mapped THPs it encounters,
>>> John Hubbard has investigated this and concluded that it is A) not clear at the
>>> moment what a better policy might be for PTE-mapped THP and B) questions whether
>>> this should really be considered a prerequisite given no regression is caused
>>> for the default "multi-size THP disabled" case, and there is no correctness
>>> issue when it is enabled - its just a potential for non-optimal performance.
>>>
>>> If there are no disagreements about removing numa balancing from the list (none
>>> were raised when I first posted this comment against v7), then that just leaves
>>> compaction which is in review on list at the moment.
>>>
>>> I really would like to get this series (and its remaining comapction
>>> prerequisite) in for v6.8. I accept that it may be a bit optimistic at this
>>> point, but lets see where we get to with review?
>>>
>>>
>>> Testing
>>> =======
>>>
>>> The series includes patches for mm selftests to enlighten the cow and khugepaged
>>> tests to explicitly test with multi-size THP, in the same way that PMD-sized
>>> THP is tested. The new tests all pass, and no regressions are observed in the mm
>>> selftest suite. I've also run my usual kernel compilation and java script
>>> benchmarks without any issues.
>>>
>>> Refer to my performance numbers posted with v6 [6]. (These are for multi-size
>>> THP only - they do not include the arm64 contpte follow-on series).
>>>
>>> John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
>>> some workloads at [11]. (Observed using v6 of this series as well as the arm64
>>> contpte series).
>>>
>>> Kefeng Wang at Huawei has also indicated he sees improvements at [12] although
>>> there are some latency regressions also.
>>
>> Hi Ryan,
>>
>> Here is some test results based on v6.7-rc1 +
>> [PATCH v7 00/10] Small-sized THP for anonymous memory +
>> [PATCH v2 00/14] Transparent Contiguous PTEs for User Mappings
>>
>> case1: basepage 64K
>> case2: basepage 4K + thp=64k + PAGE_ALLOC_COSTLY_ORDER = 3
>> case3: basepage 4K + thp=64k + PAGE_ALLOC_COSTLY_ORDER = 4
> 
> Thanks for sharing these results. With the exception of a few outliers, It looks
> like the ~rough conclusion is that bandwidth improves, but not as much as 64K
> base pages, and latency regresses, but also not as much as 64K base pages?

It depends on the test cases, both sides have their own advantages and
disadvantages, but 64k base page is still better in most cases.

> 
> I expect that over time, as we add more optimizations, we will get bandwidth
> closer to 64K base pages; one crucial one is getting executable file-backed
> memory into contpte mappings, for example.

Yes, this should spend some time to optimize, also maybe provide more
policy, eg order chosen, per-task/per-cg control?

> 
> It's probably not time to switch PAGE_ALLOC_COSTLY_ORDER quite yet; but
> something to keep an eye on and consider down the road?

This one just for test and it seems not to obtain large gain in
unixbench/lmbench testcases, also it shouldn't be considered in this
patchset.


From mripard at kernel.org  Thu Dec  7 07:49:48 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:48 +0100
Subject: [PATCH v5 25/44] drm/rockchip: inno_hdmi: Get rid of mode_set
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-25-6538e19d634d@kernel.org>

We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index cc86d273ca4a..4db18195246e 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -490,21 +490,22 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	return 0;
 }
 
-static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-				       struct drm_crtc_state *crtc_state,
-				       struct drm_connector_state *conn_state)
-{
-	struct drm_display_mode *adj_mode = &crtc_state->adjusted_mode;
-	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
-
-	inno_hdmi_setup(hdmi, adj_mode);
-}
-
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 				     struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
+	struct drm_connector_state *conn_state;
+	struct drm_crtc_state *crtc_state;
 
+	conn_state = drm_atomic_get_new_connector_state(state, &hdmi->connector);
+	if (WARN_ON(!conn_state))
+		return;
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+	if (WARN_ON(!crtc_state))
+		return;
+
+	inno_hdmi_setup(hdmi, &crtc_state->adjusted_mode);
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
@@ -533,7 +534,6 @@ static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
 	.atomic_check	= inno_hdmi_encoder_atomic_check,
 	.atomic_enable	= inno_hdmi_encoder_enable,
 	.atomic_disable	= inno_hdmi_encoder_disable,
-	.atomic_mode_set	= inno_hdmi_encoder_mode_set,
 };
 
 static enum drm_connector_status

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:49 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:49 +0100
Subject: [PATCH v5 26/44] drm/rockchip: inno_hdmi: no need to store vic
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-26-6538e19d634d@kernel.org>

The mode's VIC is only ever used in the inno_hdmi_setup() function so
there's no need to store it in the main structure.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 4db18195246e..294f0d442c0c 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	int vic;
 	bool sink_has_audio;
 	unsigned int enc_in_format;
 	unsigned int enc_out_format;
@@ -443,16 +442,15 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 			   struct drm_display_mode *mode)
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
-
-	hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
+	u8 vic = drm_match_cea_mode(mode);
 
 	hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
 	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
 
-	if ((hdmi->hdmi_data.vic == 6) || (hdmi->hdmi_data.vic == 7) ||
-	    (hdmi->hdmi_data.vic == 21) || (hdmi->hdmi_data.vic == 22) ||
-	    (hdmi->hdmi_data.vic == 2) || (hdmi->hdmi_data.vic == 3) ||
-	    (hdmi->hdmi_data.vic == 17) || (hdmi->hdmi_data.vic == 18))
+	if ((vic == 6) || (vic == 7) ||
+	    (vic == 21) || (vic == 22) ||
+	    (vic == 2) || (vic == 3) ||
+	    (vic == 17) || (vic == 18))
 		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
 	else
 		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:51 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:51 +0100
Subject: [PATCH v5 28/44] drm/rockchip: inno_hdmi: Remove useless input
 format
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-28-6538e19d634d@kernel.org>

The driver has a lot of logic to deal with multiple input formats, but
hardcodes it to RGB. This means that most of that code has been dead
code, so let's get rid of it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 39 +++++++++---------------------------
 1 file changed, 10 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 3908dc09d85f..e0696ab16da3 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	unsigned int enc_in_format;
 	unsigned int enc_out_format;
 	unsigned int colorimetry;
 };
@@ -328,47 +327,30 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		v_VIDEO_INPUT_CSP(0);
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
-	if (data->enc_in_format == data->enc_out_format) {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
-		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
-			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
-			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+	if (HDMI_COLORSPACE_RGB == data->enc_out_format) {
+		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
 
-			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
-				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
-				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
-				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
-			return 0;
-		}
+		hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+			  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+			  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+			  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+		return 0;
 	}
 
 	if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
-		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
-		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
-			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
-			csc_mode = CSC_ITU601_16_235_TO_RGB_0_255_8BIT;
-			auto_csc = AUTO_CSC_ENABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_DISABLE;
 		}
 	} else {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
-		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
-		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
-			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
-			csc_mode = CSC_ITU709_16_235_TO_RGB_0_255_8BIT;
-			auto_csc = AUTO_CSC_ENABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_DISABLE;
 		}
 	}
 
@@ -443,7 +425,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	struct drm_display_info *display = &hdmi->connector.display_info;
 	u8 vic = drm_match_cea_mode(mode);
 
-	hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
 	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
 
 	if ((vic == 6) || (vic == 7) ||

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:53 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:53 +0100
Subject: [PATCH v5 30/44] drm/rockchip: inno_hdmi: Remove useless
 colorimetry
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-30-6538e19d634d@kernel.org>

The colorimetry field of hdmi_data_info is not used anywhere so we can
get rid of it. This was the last field left in that structure so we can
get rid of it too.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 0c6c550e0ce7..c342bc8b3a23 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -27,10 +27,6 @@
 
 #include "inno_hdmi.h"
 
-struct hdmi_data_info {
-	unsigned int colorimetry;
-};
-
 struct inno_hdmi_i2c {
 	struct i2c_adapter adap;
 
@@ -56,8 +52,6 @@ struct inno_hdmi {
 	struct i2c_adapter *ddc;
 
 	unsigned int tmds_rate;
-
-	struct hdmi_data_info	hdmi_data;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -380,15 +374,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 			   struct drm_display_mode *mode)
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
-	u8 vic = drm_match_cea_mode(mode);
-
-	if ((vic == 6) || (vic == 7) ||
-	    (vic == 21) || (vic == 22) ||
-	    (vic == 2) || (vic == 3) ||
-	    (vic == 17) || (vic == 18))
-		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
-	else
-		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
 
 	/* Mute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:55 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:55 +0100
Subject: [PATCH v5 32/44] drm/rockchip: inno_hdmi: Remove tmds rate from
 structure
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-32-6538e19d634d@kernel.org>

The tmds_rate field in the inno_hdmi structure is used mostly to
configure the internal i2c controller divider through a call to the
inno_hdmi_i2c_init() function.

We can simply make that rate an argument to that function, which also
removes a workaround to initialize the divider at probe time when we
don't have a mode yet.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f05417c6b637..35f44e556fcf 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -50,8 +50,6 @@ struct inno_hdmi {
 
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
-
-	unsigned int tmds_rate;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -155,11 +153,11 @@ static inline void hdmi_modb(struct inno_hdmi *hdmi, u16 offset,
 	hdmi_writeb(hdmi, offset, temp);
 }
 
-static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
+static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi, unsigned long long rate)
 {
-	int ddc_bus_freq;
+	unsigned long long ddc_bus_freq = rate >> 2;
 
-	ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE;
+	do_div(ddc_bus_freq, HDMI_SCL_RATE);
 
 	hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
 	hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
@@ -389,8 +387,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
 	 * clock rate, and reconfigure the DDC clock.
 	 */
-	hdmi->tmds_rate = mode->clock * 1000;
-	inno_hdmi_i2c_init(hdmi);
+	inno_hdmi_i2c_init(hdmi, mode->clock * 1000);
 
 	/* Unmute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -768,8 +765,7 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
 	 * and reconfigure the DDC clock.
 	 */
-	hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
-	inno_hdmi_i2c_init(hdmi);
+	inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
 
 	ret = inno_hdmi_register(drm, hdmi);
 	if (ret)

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:54 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:54 +0100
Subject: [PATCH v5 31/44] drm/rockchip: inno_hdmi: Remove useless enum
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-31-6538e19d634d@kernel.org>

The CSC_* enum has no users left, so let's remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index c342bc8b3a23..f05417c6b637 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -66,15 +66,6 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct drm_connector *connector)
 	return container_of(connector, struct inno_hdmi, connector);
 }
 
-enum {
-	CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
-	CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
-	CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
-	CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
-	CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
-	CSC_RGB_0_255_TO_RGB_16_235_8BIT,
-};
-
 static const char coeff_csc[][24] = {
 	/*
 	 * YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:56 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:56 +0100
Subject: [PATCH v5 33/44] drm/rockchip: inno_hdmi: Remove useless coeff_csc
 matrix
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-33-6538e19d634d@kernel.org>

The coeff_csc matrix isn't used anymore, let's remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 70 ------------------------------------
 1 file changed, 70 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 35f44e556fcf..e4fe02b79a98 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -64,76 +64,6 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct drm_connector *connector)
 	return container_of(connector, struct inno_hdmi, connector);
 }
 
-static const char coeff_csc[][24] = {
-	/*
-	 * YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
-	 *   R = 1.164*Y + 1.596*V - 204
-	 *   G = 1.164*Y - 0.391*U - 0.813*V + 154
-	 *   B = 1.164*Y + 2.018*U - 258
-	 */
-	{
-		0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
-		0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
-		0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
-	},
-	/*
-	 * YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
-	 *   R = Y + 1.402*V - 248
-	 *   G = Y - 0.344*U - 0.714*V + 135
-	 *   B = Y + 1.772*U - 227
-	 */
-	{
-		0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 0xf8,
-		0x04, 0x00, 0x11, 0x60, 0x12, 0xdb, 0x00, 0x87,
-		0x04, 0x00, 0x07, 0x16, 0x00, 0x00, 0x02, 0xe3
-	},
-	/*
-	 * YUV2RGB:709 HD mode(Y[16:235],UV[16:240],RGB[0:255]):
-	 *   R = 1.164*Y + 1.793*V - 248
-	 *   G = 1.164*Y - 0.213*U - 0.534*V + 77
-	 *   B = 1.164*Y + 2.115*U - 289
-	 */
-	{
-		0x04, 0xa7, 0x00, 0x00, 0x07, 0x2c, 0x02, 0xf8,
-		0x04, 0xa7, 0x10, 0xda, 0x12, 0x22, 0x00, 0x4d,
-		0x04, 0xa7, 0x08, 0x74, 0x00, 0x00, 0x03, 0x21
-	},
-
-	/*
-	 * RGB2YUV:601 SD mode:
-	 *   Cb = -0.291G - 0.148R + 0.439B + 128
-	 *   Y  = 0.504G  + 0.257R + 0.098B + 16
-	 *   Cr = -0.368G + 0.439R - 0.071B + 128
-	 */
-	{
-		0x11, 0x5f, 0x01, 0x82, 0x10, 0x23, 0x00, 0x80,
-		0x02, 0x1c, 0x00, 0xa1, 0x00, 0x36, 0x00, 0x1e,
-		0x11, 0x29, 0x10, 0x59, 0x01, 0x82, 0x00, 0x80
-	},
-	/*
-	 * RGB2YUV:709 HD mode:
-	 *   Cb = - 0.338G - 0.101R + 0.439B + 128
-	 *   Y  = 0.614G   + 0.183R + 0.062B + 16
-	 *   Cr = - 0.399G + 0.439R - 0.040B + 128
-	 */
-	{
-		0x11, 0x98, 0x01, 0xc1, 0x10, 0x28, 0x00, 0x80,
-		0x02, 0x74, 0x00, 0xbb, 0x00, 0x3f, 0x00, 0x10,
-		0x11, 0x5a, 0x10, 0x67, 0x01, 0xc1, 0x00, 0x80
-	},
-	/*
-	 * RGB[0:255]2RGB[16:235]:
-	 *   R' = R x (235-16)/255 + 16;
-	 *   G' = G x (235-16)/255 + 16;
-	 *   B' = B x (235-16)/255 + 16;
-	 */
-	{
-		0x00, 0x00, 0x03, 0x6F, 0x00, 0x00, 0x00, 0x10,
-		0x03, 0x6F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10,
-		0x00, 0x00, 0x00, 0x00, 0x03, 0x6F, 0x00, 0x10
-	},
-};
-
 static inline u8 hdmi_readb(struct inno_hdmi *hdmi, u16 offset)
 {
 	return readl_relaxed(hdmi->regs + (offset) * 0x04);

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:50 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:50 +0100
Subject: [PATCH v5 27/44] drm/rockchip: inno_hdmi: Remove unneeded has
 audio flag
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-27-6538e19d634d@kernel.org>

The sink_has_audio flag is not used anywhere in the driver so let's get
rid of it. It's redundant with drm_display_info.has_audio anyway.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 294f0d442c0c..3908dc09d85f 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	bool sink_has_audio;
 	unsigned int enc_in_format;
 	unsigned int enc_out_format;
 	unsigned int colorimetry;
@@ -554,7 +553,6 @@ static int inno_hdmi_connector_get_modes(struct drm_connector *connector)
 
 	edid = drm_get_edid(connector, hdmi->ddc);
 	if (edid) {
-		hdmi->hdmi_data.sink_has_audio = drm_detect_monitor_audio(edid);
 		drm_connector_update_edid_property(connector, edid);
 		ret = drm_add_edid_modes(connector, edid);
 		kfree(edid);

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:57 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:57 +0100
Subject: [PATCH v5 34/44] drm/rockchip: inno_hdmi: Remove useless
 mode_valid
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-34-6538e19d634d@kernel.org>

The inno_hdmi mode_valid implementation always return MODE_OK which is
what the core assumes when we don't have an implementation.

Let's get rid of it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e4fe02b79a98..59b2b676b7b8 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -400,13 +400,6 @@ static int inno_hdmi_connector_get_modes(struct drm_connector *connector)
 	return ret;
 }
 
-static enum drm_mode_status
-inno_hdmi_connector_mode_valid(struct drm_connector *connector,
-			       struct drm_display_mode *mode)
-{
-	return MODE_OK;
-}
-
 static int
 inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
 				       uint32_t maxX, uint32_t maxY)
@@ -431,7 +424,6 @@ static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
 
 static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = {
 	.get_modes = inno_hdmi_connector_get_modes,
-	.mode_valid = inno_hdmi_connector_mode_valid,
 };
 
 static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi)

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:52 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:52 +0100
Subject: [PATCH v5 29/44] drm/rockchip: inno_hdmi: Remove useless output
 format
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-29-6538e19d634d@kernel.org>

Similarly to the input format, the driver has a lot of code to deal with
various output format, but the driver hardcodes it to RGB always.

Let's get rid of the dead code.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 57 ++++--------------------------------
 1 file changed, 6 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e0696ab16da3..0c6c550e0ce7 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	unsigned int enc_out_format;
 	unsigned int colorimetry;
 };
 
@@ -296,26 +295,14 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
 						      &hdmi->connector,
 						      mode);
-
-	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
-		frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
-	else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
-		frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
-	else
-		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+	frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
 	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 {
-	struct hdmi_data_info *data = &hdmi->hdmi_data;
-	int c0_c2_change = 0;
-	int csc_enable = 0;
-	int csc_mode = 0;
-	int auto_csc = 0;
 	int value;
-	int i;
 
 	/* Input video mode is SDR RGB24bit, data enable signal from external */
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL1, v_DE_EXTERNAL |
@@ -327,43 +314,13 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		v_VIDEO_INPUT_CSP(0);
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
-	if (HDMI_COLORSPACE_RGB == data->enc_out_format) {
-		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
-		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
-		hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
-			  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
-			  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
-			  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
-		return 0;
-	}
-
-	if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
-			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
-			auto_csc = AUTO_CSC_DISABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_ENABLE;
-		}
-	} else {
-		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
-			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
-			auto_csc = AUTO_CSC_DISABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_ENABLE;
-		}
-	}
-
-	for (i = 0; i < 24; i++)
-		hdmi_writeb(hdmi, HDMI_VIDEO_CSC_COEF + i,
-			    coeff_csc[csc_mode][i]);
-
-	value = v_SOF_DISABLE | csc_enable | v_COLOR_DEPTH_NOT_INDICATED(1);
+	value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-	hdmi_modb(hdmi, HDMI_VIDEO_CONTRL, m_VIDEO_AUTO_CSC |
-		  m_VIDEO_C0_C2_SWAP, v_VIDEO_AUTO_CSC(auto_csc) |
-		  v_VIDEO_C0_C2_SWAP(c0_c2_change));
 
+	hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+		  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+		  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+		  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
 	return 0;
 }
 
@@ -425,8 +382,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	struct drm_display_info *display = &hdmi->connector.display_info;
 	u8 vic = drm_match_cea_mode(mode);
 
-	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
-
 	if ((vic == 6) || (vic == 7) ||
 	    (vic == 21) || (vic == 22) ||
 	    (vic == 2) || (vic == 3) ||

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:58 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:58 +0100
Subject: [PATCH v5 35/44] drm/rockchip: inno_hdmi: Drop HDMI Vendor
 Infoframe support
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-35-6538e19d634d@kernel.org>

The HDMI vendor infoframe is only meant to be sent with 4k60 modes and
higher, but the controller doesn't support them. Let's drop them from
the kernel.

Suggested-by: Johan Jonker <jbx6244 at gmail.com>
Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 35 ++++++++++-------------------------
 1 file changed, 10 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 59b2b676b7b8..9c64f94ede6f 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -157,11 +157,15 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 }
 
 static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
-				  union hdmi_infoframe *frame, u32 frame_index,
-				  u32 mask, u32 disable, u32 enable)
+				  union hdmi_infoframe *frame, u32 frame_index)
 {
-	if (mask)
-		hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, disable);
+	struct drm_connector *connector = &hdmi->connector;
+
+	if (frame_index != INFOFRAME_AVI) {
+		drm_err(connector->dev,
+			"Unsupported infoframe type: %u\n", frame_index);
+		return 0;
+	}
 
 	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
 
@@ -177,28 +181,11 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
 		for (i = 0; i < rc; i++)
 			hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
 				    packed_frame[i]);
-
-		if (mask)
-			hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, enable);
 	}
 
 	return setup_rc;
 }
 
-static int inno_hdmi_config_video_vsi(struct inno_hdmi *hdmi,
-				      struct drm_display_mode *mode)
-{
-	union hdmi_infoframe frame;
-	int rc;
-
-	rc = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
-							 &hdmi->connector,
-							 mode);
-
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_VSI,
-		m_PACKET_VSI_EN, v_PACKET_VSI_EN(0), v_PACKET_VSI_EN(1));
-}
-
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 				      struct drm_display_mode *mode)
 {
@@ -210,7 +197,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 						      mode);
 	frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
+	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
@@ -306,10 +293,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 
 	inno_hdmi_config_video_csc(hdmi);
 
-	if (display->is_hdmi) {
+	if (display->is_hdmi)
 		inno_hdmi_config_video_avi(hdmi, mode);
-		inno_hdmi_config_video_vsi(hdmi, mode);
-	}
 
 	/*
 	 * When IP controller have configured to an accurate video

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:49:59 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:49:59 +0100
Subject: [PATCH v5 36/44] drm/rockchip: inno_hdmi: Move infoframe disable
 to separate function
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-36-6538e19d634d@kernel.org>

The code to upload infoframes to the controller uses a weird construct
which, based on the previous function call return code, will either
disable or enable that infoframe.

In order to get rid of that argument, let's split the function to
disable the infoframe into a separate function and make it obvious what
we are doing in the error path.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 47 ++++++++++++++++++++++++------------
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 9c64f94ede6f..b68cd3a6a0d1 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -156,34 +156,44 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
-				  union hdmi_infoframe *frame, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
 {
 	struct drm_connector *connector = &hdmi->connector;
 
 	if (frame_index != INFOFRAME_AVI) {
 		drm_err(connector->dev,
 			"Unsupported infoframe type: %u\n", frame_index);
-		return 0;
+		return;
 	}
 
 	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+}
 
-	if (setup_rc >= 0) {
-		u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
-		ssize_t rc, i;
+static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
+				  union hdmi_infoframe *frame, u32 frame_index)
+{
+	struct drm_connector *connector = &hdmi->connector;
+	u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
+	ssize_t rc, i;
 
-		rc = hdmi_infoframe_pack(frame, packed_frame,
-					 sizeof(packed_frame));
-		if (rc < 0)
-			return rc;
-
-		for (i = 0; i < rc; i++)
-			hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
-				    packed_frame[i]);
+	if (frame_index != INFOFRAME_AVI) {
+		drm_err(connector->dev,
+			"Unsupported infoframe type: %u\n", frame_index);
+		return 0;
 	}
 
-	return setup_rc;
+	inno_hdmi_disable_frame(hdmi, frame_index);
+
+	rc = hdmi_infoframe_pack(frame, packed_frame,
+				 sizeof(packed_frame));
+	if (rc < 0)
+		return rc;
+
+	for (i = 0; i < rc; i++)
+		hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
+			    packed_frame[i]);
+
+	return 0;
 }
 
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
@@ -195,9 +205,14 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
 						      &hdmi->connector,
 						      mode);
+	if (rc) {
+		inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+		return rc;
+	}
+
 	frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI);
+	return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:50:00 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:50:00 +0100
Subject: [PATCH v5 37/44] drm/rockchip: inno_hdmi: Switch to infoframe type
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-37-6538e19d634d@kernel.org>

The inno_hdmi driver relies on its own internal infoframe type matching
the hardware.

This works fine, but in order to make further reworks easier, let's
switch to the HDMI spec definition of those types.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index b68cd3a6a0d1..77b530f377c0 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -156,33 +156,34 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
+				    enum hdmi_infoframe_type type)
 {
 	struct drm_connector *connector = &hdmi->connector;
 
-	if (frame_index != INFOFRAME_AVI) {
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
-			"Unsupported infoframe type: %u\n", frame_index);
+			"Unsupported infoframe type: %u\n", type);
 		return;
 	}
 
-	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
-				  union hdmi_infoframe *frame, u32 frame_index)
+				  union hdmi_infoframe *frame, enum hdmi_infoframe_type type)
 {
 	struct drm_connector *connector = &hdmi->connector;
 	u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
 	ssize_t rc, i;
 
-	if (frame_index != INFOFRAME_AVI) {
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
-			"Unsupported infoframe type: %u\n", frame_index);
+			"Unsupported infoframe type: %u\n", type);
 		return 0;
 	}
 
-	inno_hdmi_disable_frame(hdmi, frame_index);
+	inno_hdmi_disable_frame(hdmi, type);
 
 	rc = hdmi_infoframe_pack(frame, packed_frame,
 				 sizeof(packed_frame));
@@ -206,13 +207,13 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 						      &hdmi->connector,
 						      mode);
 	if (rc) {
-		inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+		inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI);
 		return rc;
 	}
 
 	frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI);
+	return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:50:01 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:50:01 +0100
Subject: [PATCH v5 38/44] drm/rockchip: inno_hdmi: Remove unused drm device
 pointer
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-38-6538e19d634d@kernel.org>

The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 77b530f377c0..0f3ec6eaf270 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -39,7 +39,6 @@ struct inno_hdmi_i2c {
 
 struct inno_hdmi {
 	struct device *dev;
-	struct drm_device *drm_dev;
 
 	int irq;
 	struct clk *pclk;
@@ -648,7 +647,6 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		return -ENOMEM;
 
 	hdmi->dev = dev;
-	hdmi->drm_dev = drm;
 
 	hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hdmi->regs))

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:50:04 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:50:04 +0100
Subject: [PATCH v5 41/44] drm/sun4i: hdmi: Move mode_set into enable
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-41-6538e19d634d@kernel.org>

We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 38 +++++++++++++---------------------
 1 file changed, 14 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 799a26215cc2..bae69d696765 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -103,33 +103,11 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder,
 	struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
 	struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
 	struct drm_display_info *display = &hdmi->connector.display_info;
+	unsigned int x, y;
 	u32 val = 0;
 
 	DRM_DEBUG_DRIVER("Enabling the HDMI Output\n");
 
-	clk_prepare_enable(hdmi->tmds_clk);
-
-	sun4i_hdmi_setup_avi_infoframes(hdmi, mode);
-	val |= SUN4I_HDMI_PKT_CTRL_TYPE(0, SUN4I_HDMI_PKT_AVI);
-	val |= SUN4I_HDMI_PKT_CTRL_TYPE(1, SUN4I_HDMI_PKT_END);
-	writel(val, hdmi->base + SUN4I_HDMI_PKT_CTRL_REG(0));
-
-	val = SUN4I_HDMI_VID_CTRL_ENABLE;
-	if (display->is_hdmi)
-		val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
-
-	writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
-}
-
-static void sun4i_hdmi_mode_set(struct drm_encoder *encoder,
-				struct drm_crtc_state *crtc_state,
-				struct drm_connector_state *conn_state)
-{
-	const struct drm_display_mode *mode = &crtc_state->mode;
-	struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
-	unsigned int x, y;
-	u32 val;
-
 	clk_set_rate(hdmi->mod_clk, mode->crtc_clock * 1000);
 	clk_set_rate(hdmi->tmds_clk, mode->crtc_clock * 1000);
 
@@ -181,6 +159,19 @@ static void sun4i_hdmi_mode_set(struct drm_encoder *encoder,
 		val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
 
 	writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
+
+	clk_prepare_enable(hdmi->tmds_clk);
+
+	sun4i_hdmi_setup_avi_infoframes(hdmi, mode);
+	val |= SUN4I_HDMI_PKT_CTRL_TYPE(0, SUN4I_HDMI_PKT_AVI);
+	val |= SUN4I_HDMI_PKT_CTRL_TYPE(1, SUN4I_HDMI_PKT_END);
+	writel(val, hdmi->base + SUN4I_HDMI_PKT_CTRL_REG(0));
+
+	val = SUN4I_HDMI_VID_CTRL_ENABLE;
+	if (display->is_hdmi)
+		val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
+
+	writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
 }
 
 static enum drm_mode_status sun4i_hdmi_mode_valid(struct drm_encoder *encoder,
@@ -206,7 +197,6 @@ static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = {
 	.atomic_check	= sun4i_hdmi_atomic_check,
 	.atomic_disable	= sun4i_hdmi_disable,
 	.atomic_enable	= sun4i_hdmi_enable,
-	.atomic_mode_set	= sun4i_hdmi_mode_set,
 	.mode_valid	= sun4i_hdmi_mode_valid,
 };
 

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:50:03 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:50:03 +0100
Subject: [PATCH v5 40/44] drm/sun4i: hdmi: Convert encoder to atomic
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-40-6538e19d634d@kernel.org>

The sun4i_hdmi driver still uses the non-atomic variants of the encoder
hooks, so let's convert to their atomic equivalents.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 152375f3de2e..799a26215cc2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -82,7 +82,8 @@ static int sun4i_hdmi_atomic_check(struct drm_encoder *encoder,
 	return 0;
 }
 
-static void sun4i_hdmi_disable(struct drm_encoder *encoder)
+static void sun4i_hdmi_disable(struct drm_encoder *encoder,
+			       struct drm_atomic_state *state)
 {
 	struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
 	u32 val;
@@ -96,7 +97,8 @@ static void sun4i_hdmi_disable(struct drm_encoder *encoder)
 	clk_disable_unprepare(hdmi->tmds_clk);
 }
 
-static void sun4i_hdmi_enable(struct drm_encoder *encoder)
+static void sun4i_hdmi_enable(struct drm_encoder *encoder,
+			      struct drm_atomic_state *state)
 {
 	struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
 	struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
@@ -120,9 +122,10 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder)
 }
 
 static void sun4i_hdmi_mode_set(struct drm_encoder *encoder,
-				struct drm_display_mode *mode,
-				struct drm_display_mode *adjusted_mode)
+				struct drm_crtc_state *crtc_state,
+				struct drm_connector_state *conn_state)
 {
+	const struct drm_display_mode *mode = &crtc_state->mode;
 	struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
 	unsigned int x, y;
 	u32 val;
@@ -201,9 +204,9 @@ static enum drm_mode_status sun4i_hdmi_mode_valid(struct drm_encoder *encoder,
 
 static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = {
 	.atomic_check	= sun4i_hdmi_atomic_check,
-	.disable	= sun4i_hdmi_disable,
-	.enable		= sun4i_hdmi_enable,
-	.mode_set	= sun4i_hdmi_mode_set,
+	.atomic_disable	= sun4i_hdmi_disable,
+	.atomic_enable	= sun4i_hdmi_enable,
+	.atomic_mode_set	= sun4i_hdmi_mode_set,
 	.mode_valid	= sun4i_hdmi_mode_valid,
 };
 

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:50:02 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:50:02 +0100
Subject: [PATCH v5 39/44] drm/rockchip: inno_hdmi: Switch to HDMI connector
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-39-6538e19d634d@kernel.org>

The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 86 ++++++++++++++++++------------------
 1 file changed, 42 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 0f3ec6eaf270..97fb4268bd7f 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -155,26 +155,29 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
-				    enum hdmi_infoframe_type type)
+static int inno_hdmi_disable_frame(struct drm_connector *connector,
+				   enum hdmi_infoframe_type type)
 {
-	struct drm_connector *connector = &hdmi->connector;
+	struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
 
 	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
 			"Unsupported infoframe type: %u\n", type);
-		return;
+		return 0;
 	}
 
 	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI);
+
+	return 0;
 }
 
-static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
-				  union hdmi_infoframe *frame, enum hdmi_infoframe_type type)
+static int inno_hdmi_upload_frame(struct drm_connector *connector,
+				  enum hdmi_infoframe_type type,
+				  const u8 *buffer, size_t len)
 {
-	struct drm_connector *connector = &hdmi->connector;
+	struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
 	u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
-	ssize_t rc, i;
+	ssize_t i;
 
 	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
@@ -182,38 +185,19 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
 		return 0;
 	}
 
-	inno_hdmi_disable_frame(hdmi, type);
+	inno_hdmi_disable_frame(connector, type);
 
-	rc = hdmi_infoframe_pack(frame, packed_frame,
-				 sizeof(packed_frame));
-	if (rc < 0)
-		return rc;
-
-	for (i = 0; i < rc; i++)
+	for (i = 0; i < len; i++)
 		hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
 			    packed_frame[i]);
 
 	return 0;
 }
 
-static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
-				      struct drm_display_mode *mode)
-{
-	union hdmi_infoframe frame;
-	int rc;
-
-	rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
-						      &hdmi->connector,
-						      mode);
-	if (rc) {
-		inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI);
-		return rc;
-	}
-
-	frame.avi.colorspace = HDMI_COLORSPACE_RGB;
-
-	return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI);
-}
+static const struct drm_connector_hdmi_funcs inno_hdmi_hdmi_connector_funcs = {
+	.clear_infoframe	= inno_hdmi_disable_frame,
+	.write_infoframe	= inno_hdmi_upload_frame,
+};
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 {
@@ -292,9 +276,12 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
 }
 
 static int inno_hdmi_setup(struct inno_hdmi *hdmi,
-			   struct drm_display_mode *mode)
+			   struct drm_crtc_state *new_crtc_state,
+			   struct drm_connector_state *new_conn_state)
 {
-	struct drm_display_info *display = &hdmi->connector.display_info;
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_display_info *display = &connector->display_info;
+	struct drm_display_mode *mode = &new_crtc_state->adjusted_mode;
 
 	/* Mute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -308,8 +295,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 
 	inno_hdmi_config_video_csc(hdmi);
 
-	if (display->is_hdmi)
-		inno_hdmi_config_video_avi(hdmi, mode);
+	drm_atomic_helper_connector_hdmi_update_infoframes(connector,
+							   new_conn_state->state);
 
 	/*
 	 * When IP controller have configured to an accurate video
@@ -317,7 +304,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
 	 * clock rate, and reconfigure the DDC clock.
 	 */
-	inno_hdmi_i2c_init(hdmi, mode->clock * 1000);
+	inno_hdmi_i2c_init(hdmi, new_conn_state->hdmi.tmds_char_rate);
 
 	/* Unmute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -341,7 +328,7 @@ static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 	if (WARN_ON(!crtc_state))
 		return;
 
-	inno_hdmi_setup(hdmi, &crtc_state->adjusted_mode);
+	inno_hdmi_setup(hdmi, crtc_state, conn_state);
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
@@ -407,6 +394,12 @@ inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
 	return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
 }
 
+static void inno_hdmi_connector_reset(struct drm_connector *connector)
+{
+	drm_atomic_helper_connector_reset(connector);
+	__drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
+}
+
 static void inno_hdmi_connector_destroy(struct drm_connector *connector)
 {
 	drm_connector_unregister(connector);
@@ -417,12 +410,13 @@ static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
 	.fill_modes = inno_hdmi_probe_single_connector_modes,
 	.detect = inno_hdmi_connector_detect,
 	.destroy = inno_hdmi_connector_destroy,
-	.reset = drm_atomic_helper_connector_reset,
+	.reset = inno_hdmi_connector_reset,
 	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
 	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
 static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = {
+	.atomic_check = drm_atomic_helper_connector_hdmi_check,
 	.get_modes = inno_hdmi_connector_get_modes,
 };
 
@@ -449,10 +443,14 @@ static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi)
 
 	drm_connector_helper_add(&hdmi->connector,
 				 &inno_hdmi_connector_helper_funcs);
-	drm_connector_init_with_ddc(drm, &hdmi->connector,
-				    &inno_hdmi_connector_funcs,
-				    DRM_MODE_CONNECTOR_HDMIA,
-				    hdmi->ddc);
+	drmm_connector_hdmi_init(drm, &hdmi->connector,
+				 "Rockchip", "Inno HDMI",
+				 &inno_hdmi_connector_funcs,
+				 &inno_hdmi_hdmi_connector_funcs,
+				 DRM_MODE_CONNECTOR_HDMIA,
+				 hdmi->ddc,
+				 BIT(HDMI_COLORSPACE_RGB),
+				 8);
 
 	drm_connector_attach_encoder(&hdmi->connector, encoder);
 

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:50:05 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:50:05 +0100
Subject: [PATCH v5 42/44] drm/sun4i: hdmi: Switch to container_of_const
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-42-6538e19d634d@kernel.org>

container_of_const() allows to preserve the pointer constness and is
thus more flexible than inline functions.

Let's switch all our instances of container_of() to container_of_const().

Reviewed-by: Sui Jingfeng <sui.jingfeng at linux.dev>
Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index bae69d696765..c276d984da6b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -30,19 +30,11 @@
 #include "sun4i_drv.h"
 #include "sun4i_hdmi.h"
 
-static inline struct sun4i_hdmi *
-drm_encoder_to_sun4i_hdmi(struct drm_encoder *encoder)
-{
-	return container_of(encoder, struct sun4i_hdmi,
-			    encoder);
-}
+#define drm_encoder_to_sun4i_hdmi(e)		\
+	container_of_const(e, struct sun4i_hdmi, encoder)
 
-static inline struct sun4i_hdmi *
-drm_connector_to_sun4i_hdmi(struct drm_connector *connector)
-{
-	return container_of(connector, struct sun4i_hdmi,
-			    connector);
-}
+#define drm_connector_to_sun4i_hdmi(c)		\
+	container_of_const(c, struct sun4i_hdmi, connector)
 
 static int sun4i_hdmi_setup_avi_infoframes(struct sun4i_hdmi *hdmi,
 					   struct drm_display_mode *mode)

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:50:06 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:50:06 +0100
Subject: [PATCH v5 43/44] drm/sun4i: hdmi: Consolidate atomic_check and
 mode_valid
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-43-6538e19d634d@kernel.org>

atomic_check and mode_valid do not check for the same things which can
lead to surprising result if the userspace commits a mode that didn't go
through mode_valid. Let's merge the two implementations into a function
called by both.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 74 +++++++++++++++++++++-------------
 1 file changed, 47 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index c276d984da6b..b7cf369b1906 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -62,18 +62,6 @@ static int sun4i_hdmi_setup_avi_infoframes(struct sun4i_hdmi *hdmi,
 	return 0;
 }
 
-static int sun4i_hdmi_atomic_check(struct drm_encoder *encoder,
-				   struct drm_crtc_state *crtc_state,
-				   struct drm_connector_state *conn_state)
-{
-	struct drm_display_mode *mode = &crtc_state->mode;
-
-	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
-		return -EINVAL;
-
-	return 0;
-}
-
 static void sun4i_hdmi_disable(struct drm_encoder *encoder,
 			       struct drm_atomic_state *state)
 {
@@ -166,31 +154,61 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder,
 	writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
 }
 
-static enum drm_mode_status sun4i_hdmi_mode_valid(struct drm_encoder *encoder,
-					const struct drm_display_mode *mode)
+static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = {
+	.atomic_disable	= sun4i_hdmi_disable,
+	.atomic_enable	= sun4i_hdmi_enable,
+};
+
+static enum drm_mode_status
+sun4i_hdmi_connector_clock_valid(const struct drm_connector *connector,
+				 const struct drm_display_mode *mode,
+				 unsigned long long clock)
 {
-	struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
-	unsigned long rate = mode->clock * 1000;
-	unsigned long diff = rate / 200; /* +-0.5% allowed by HDMI spec */
+	const struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
+	unsigned long diff = clock / 200; /* +-0.5% allowed by HDMI spec */
 	long rounded_rate;
 
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+		return MODE_BAD;
+
 	/* 165 MHz is the typical max pixelclock frequency for HDMI <= 1.2 */
-	if (rate > 165000000)
+	if (clock > 165000000)
 		return MODE_CLOCK_HIGH;
-	rounded_rate = clk_round_rate(hdmi->tmds_clk, rate);
+
+	rounded_rate = clk_round_rate(hdmi->tmds_clk, clock);
 	if (rounded_rate > 0 &&
-	    max_t(unsigned long, rounded_rate, rate) -
-	    min_t(unsigned long, rounded_rate, rate) < diff)
+	    max_t(unsigned long, rounded_rate, clock) -
+	    min_t(unsigned long, rounded_rate, clock) < diff)
 		return MODE_OK;
+
 	return MODE_NOCLOCK;
 }
 
-static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = {
-	.atomic_check	= sun4i_hdmi_atomic_check,
-	.atomic_disable	= sun4i_hdmi_disable,
-	.atomic_enable	= sun4i_hdmi_enable,
-	.mode_valid	= sun4i_hdmi_mode_valid,
-};
+static int sun4i_hdmi_connector_atomic_check(struct drm_connector *connector,
+					     struct drm_atomic_state *state)
+{
+	struct drm_connector_state *conn_state =
+		drm_atomic_get_new_connector_state(state, connector);
+	struct drm_crtc *crtc = conn_state->crtc;
+	struct drm_crtc_state *crtc_state = crtc->state;
+	struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+	enum drm_mode_status status;
+
+	status = sun4i_hdmi_connector_clock_valid(connector, mode,
+						  mode->clock * 1000);
+	if (status != MODE_OK)
+		return -EINVAL;
+
+	return 0;
+}
+
+static enum drm_mode_status
+sun4i_hdmi_connector_mode_valid(struct drm_connector *connector,
+				struct drm_display_mode *mode)
+{
+	return sun4i_hdmi_connector_clock_valid(connector, mode,
+						mode->clock * 1000);
+}
 
 static int sun4i_hdmi_get_modes(struct drm_connector *connector)
 {
@@ -236,6 +254,8 @@ static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev)
 }
 
 static const struct drm_connector_helper_funcs sun4i_hdmi_connector_helper_funcs = {
+	.atomic_check	= sun4i_hdmi_connector_atomic_check,
+	.mode_valid	= sun4i_hdmi_connector_mode_valid,
 	.get_modes	= sun4i_hdmi_get_modes,
 };
 

-- 
2.43.0



From mripard at kernel.org  Thu Dec  7 07:50:07 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 07 Dec 2023 16:50:07 +0100
Subject: [PATCH v5 44/44] drm/sun4i: hdmi: Switch to HDMI connector
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
Message-ID: <20231207-kms-hdmi-connector-state-v5-44-6538e19d634d@kernel.org>

The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 ++++++++++++++++++++++------------
 1 file changed, 51 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index b7cf369b1906..8a9106a39f23 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -36,30 +36,24 @@
 #define drm_connector_to_sun4i_hdmi(c)		\
 	container_of_const(c, struct sun4i_hdmi, connector)
 
-static int sun4i_hdmi_setup_avi_infoframes(struct sun4i_hdmi *hdmi,
-					   struct drm_display_mode *mode)
+static int sun4i_hdmi_write_infoframe(struct drm_connector *connector,
+				      enum hdmi_infoframe_type type,
+				      const u8 *buffer, size_t len)
 {
-	struct hdmi_avi_infoframe frame;
-	u8 buffer[17];
-	int i, ret;
+	struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
+	int i;
 
-	ret = drm_hdmi_avi_infoframe_from_display_mode(&frame,
-						       &hdmi->connector, mode);
-	if (ret < 0) {
-		DRM_ERROR("Failed to get infoframes from mode\n");
-		return ret;
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
+		drm_err(connector->dev,
+			"Unsupported infoframe type: %u\n", type);
+		return 0;
 	}
 
-	ret = hdmi_avi_infoframe_pack(&frame, buffer, sizeof(buffer));
-	if (ret < 0) {
-		DRM_ERROR("Failed to pack infoframes\n");
-		return ret;
-	}
-
-	for (i = 0; i < sizeof(buffer); i++)
+	for (i = 0; i < len; i++)
 		writeb(buffer[i], hdmi->base + SUN4I_HDMI_AVI_INFOFRAME_REG(i));
 
 	return 0;
+
 }
 
 static void sun4i_hdmi_disable(struct drm_encoder *encoder,
@@ -82,14 +76,18 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder,
 {
 	struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
 	struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
-	struct drm_display_info *display = &hdmi->connector.display_info;
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_display_info *display = &connector->display_info;
+	struct drm_connector_state *conn_state =
+		drm_atomic_get_new_connector_state(state, connector);
+	unsigned long long tmds_rate = conn_state->hdmi.tmds_char_rate;
 	unsigned int x, y;
 	u32 val = 0;
 
 	DRM_DEBUG_DRIVER("Enabling the HDMI Output\n");
 
-	clk_set_rate(hdmi->mod_clk, mode->crtc_clock * 1000);
-	clk_set_rate(hdmi->tmds_clk, mode->crtc_clock * 1000);
+	clk_set_rate(hdmi->mod_clk, tmds_rate);
+	clk_set_rate(hdmi->tmds_clk, tmds_rate);
 
 	/* Set input sync enable */
 	writel(SUN4I_HDMI_UNKNOWN_INPUT_SYNC,
@@ -142,7 +140,8 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder,
 
 	clk_prepare_enable(hdmi->tmds_clk);
 
-	sun4i_hdmi_setup_avi_infoframes(hdmi, mode);
+	drm_atomic_helper_connector_hdmi_update_infoframes(connector, state);
+
 	val |= SUN4I_HDMI_PKT_CTRL_TYPE(0, SUN4I_HDMI_PKT_AVI);
 	val |= SUN4I_HDMI_PKT_CTRL_TYPE(1, SUN4I_HDMI_PKT_END);
 	writel(val, hdmi->base + SUN4I_HDMI_PKT_CTRL_REG(0));
@@ -195,7 +194,7 @@ static int sun4i_hdmi_connector_atomic_check(struct drm_connector *connector,
 	enum drm_mode_status status;
 
 	status = sun4i_hdmi_connector_clock_valid(connector, mode,
-						  mode->clock * 1000);
+						  conn_state->hdmi.tmds_char_rate);
 	if (status != MODE_OK)
 		return -EINVAL;
 
@@ -206,8 +205,11 @@ static enum drm_mode_status
 sun4i_hdmi_connector_mode_valid(struct drm_connector *connector,
 				struct drm_display_mode *mode)
 {
-	return sun4i_hdmi_connector_clock_valid(connector, mode,
-						mode->clock * 1000);
+	unsigned long long rate =
+		drm_connector_hdmi_compute_mode_clock(mode, 8,
+						      HDMI_COLORSPACE_RGB);
+
+	return sun4i_hdmi_connector_clock_valid(connector, mode, rate);
 }
 
 static int sun4i_hdmi_get_modes(struct drm_connector *connector)
@@ -253,6 +255,11 @@ static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev)
 	return ddc;
 }
 
+static const struct drm_connector_hdmi_funcs sun4i_hdmi_hdmi_connector_funcs = {
+	.tmds_char_rate_valid	= sun4i_hdmi_connector_clock_valid,
+	.write_infoframe	= sun4i_hdmi_write_infoframe,
+};
+
 static const struct drm_connector_helper_funcs sun4i_hdmi_connector_helper_funcs = {
 	.atomic_check	= sun4i_hdmi_connector_atomic_check,
 	.mode_valid	= sun4i_hdmi_connector_mode_valid,
@@ -274,11 +281,17 @@ sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
 	return connector_status_connected;
 }
 
+static void sun4i_hdmi_connector_reset(struct drm_connector *connector)
+{
+	drm_atomic_helper_connector_reset(connector);
+	__drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
+}
+
 static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
 	.detect			= sun4i_hdmi_connector_detect,
 	.fill_modes		= drm_helper_probe_single_connector_modes,
 	.destroy		= drm_connector_cleanup,
-	.reset			= drm_atomic_helper_connector_reset,
+	.reset			= sun4i_hdmi_connector_reset,
 	.atomic_duplicate_state	= drm_atomic_helper_connector_duplicate_state,
 	.atomic_destroy_state	= drm_atomic_helper_connector_destroy_state,
 };
@@ -637,10 +650,19 @@ static int sun4i_hdmi_bind(struct device *dev, struct device *master,
 
 	drm_connector_helper_add(&hdmi->connector,
 				 &sun4i_hdmi_connector_helper_funcs);
-	ret = drm_connector_init_with_ddc(drm, &hdmi->connector,
-					  &sun4i_hdmi_connector_funcs,
-					  DRM_MODE_CONNECTOR_HDMIA,
-					  hdmi->ddc_i2c);
+	ret = drmm_connector_hdmi_init(drm, &hdmi->connector,
+				       /*
+					* NOTE: Those are likely to be
+					* wrong, but I couldn't find the
+					* actual ones in the BSP.
+					*/
+				       "AW", "HDMI",
+				       &sun4i_hdmi_connector_funcs,
+				       &sun4i_hdmi_hdmi_connector_funcs,
+				       DRM_MODE_CONNECTOR_HDMIA,
+				       hdmi->ddc_i2c,
+				       BIT(HDMI_COLORSPACE_RGB),
+				       8);
 	if (ret) {
 		dev_err(dev,
 			"Couldn't initialise the HDMI connector\n");

-- 
2.43.0



From christophe.leroy at csgroup.eu  Thu Dec  7 07:52:34 2023
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 7 Dec 2023 15:52:34 +0000
Subject: [PATCH RFC/RFT 1/4] riscv: Stop emitting preventive sfence.vma
 for new vmalloc mappings
In-Reply-To: <20231207150348.82096-2-alexghiti@rivosinc.com>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
 <20231207150348.82096-2-alexghiti@rivosinc.com>
Message-ID: <27d8dffc-cfd8-4f07-9c0a-b7101963c2ae@csgroup.eu>



Le 07/12/2023 ? 16:03, Alexandre Ghiti a ?crit?:
> In 6.5, we removed the vmalloc fault path because that can't work (see
> [1] [2]). Then in order to make sure that new page table entries were
> seen by the page table walker, we had to preventively emit a sfence.vma
> on all harts [3] but this solution is very costly since it relies on IPI.
> 
> And even there, we could end up in a loop of vmalloc faults if a vmalloc
> allocation is done in the IPI path (for example if it is traced, see
> [4]), which could result in a kernel stack overflow.
> 
> Those preventive sfence.vma needed to be emitted because:
> 
> - if the uarch caches invalid entries, the new mapping may not be
>    observed by the page table walker and an invalidation may be needed.
> - if the uarch does not cache invalid entries, a reordered access
>    could "miss" the new mapping and traps: in that case, we would actually
>    only need to retry the access, no sfence.vma is required.
> 
> So this patch removes those preventive sfence.vma and actually handles
> the possible (and unlikely) exceptions. And since the kernel stacks
> mappings lie in the vmalloc area, this handling must be done very early
> when the trap is taken, at the very beginning of handle_exception: this
> also rules out the vmalloc allocations in the fault path.
> 
> Note that for now, we emit a sfence.vma even for uarchs that do not
> cache invalid entries as we have no means to know that: that will be
> fixed in the next patch.
> 
> Link: https://lore.kernel.org/linux-riscv/20230531093817.665799-1-bjorn at kernel.org/ [1]
> Link: https://lore.kernel.org/linux-riscv/20230801090927.2018653-1-dylan at andestech.com [2]
> Link: https://lore.kernel.org/linux-riscv/20230725132246.817726-1-alexghiti at rivosinc.com/ [3]
> Link: https://lore.kernel.org/lkml/20200508144043.13893-1-joro at 8bytes.org/ [4]
> Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
> ---
>   arch/riscv/include/asm/cacheflush.h  | 19 +++++-
>   arch/riscv/include/asm/thread_info.h |  5 ++
>   arch/riscv/kernel/asm-offsets.c      |  5 ++
>   arch/riscv/kernel/entry.S            | 94 ++++++++++++++++++++++++++++
>   arch/riscv/mm/init.c                 |  2 +
>   5 files changed, 124 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h
> index 3cb53c4df27c..a916cbc69d47 100644
> --- a/arch/riscv/include/asm/cacheflush.h
> +++ b/arch/riscv/include/asm/cacheflush.h
> @@ -37,7 +37,24 @@ static inline void flush_dcache_page(struct page *page)
>   	flush_icache_mm(vma->vm_mm, 0)
>   
>   #ifdef CONFIG_64BIT
> -#define flush_cache_vmap(start, end)	flush_tlb_kernel_range(start, end)
> +extern u64 new_vmalloc[];

Can you have the table size here ? Would help GCC static analysis for 
boundary checking.

> +extern char _end[];
> +#define flush_cache_vmap flush_cache_vmap
> +static inline void flush_cache_vmap(unsigned long start, unsigned long end)
> +{
> +	if ((start < VMALLOC_END && end > VMALLOC_START) ||
> +	    (start < MODULES_END && end > MODULES_VADDR)) {

Can you use is_vmalloc_or_module_addr() instead ?


> +		int i;
> +
> +		/*
> +		 * We don't care if concurrently a cpu resets this value since
> +		 * the only place this can happen is in handle_exception() where
> +		 * an sfence.vma is emitted.
> +		 */
> +		for (i = 0; i < NR_CPUS / sizeof(u64) + 1; ++i)

Use ARRAY_SIZE() ?

> +			new_vmalloc[i] = -1ULL;
> +	}
> +}
>   #endif
>   
>   #ifndef CONFIG_SMP
> diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h
> index 1833beb00489..8fe12fa6c329 100644
> --- a/arch/riscv/include/asm/thread_info.h
> +++ b/arch/riscv/include/asm/thread_info.h
> @@ -60,6 +60,11 @@ struct thread_info {
>   	long			user_sp;	/* User stack pointer */
>   	int			cpu;
>   	unsigned long		syscall_work;	/* SYSCALL_WORK_ flags */
> +	/*
> +	 * Used in handle_exception() to save a0, a1 and a2 before knowing if we
> +	 * can access the kernel stack.
> +	 */
> +	unsigned long		a0, a1, a2;
>   };
>   
>   /*
> diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
> index d6a75aac1d27..340c1c84560d 100644
> --- a/arch/riscv/kernel/asm-offsets.c
> +++ b/arch/riscv/kernel/asm-offsets.c
> @@ -34,10 +34,15 @@ void asm_offsets(void)
>   	OFFSET(TASK_THREAD_S9, task_struct, thread.s[9]);
>   	OFFSET(TASK_THREAD_S10, task_struct, thread.s[10]);
>   	OFFSET(TASK_THREAD_S11, task_struct, thread.s[11]);
> +
> +	OFFSET(TASK_TI_CPU, task_struct, thread_info.cpu);
>   	OFFSET(TASK_TI_FLAGS, task_struct, thread_info.flags);
>   	OFFSET(TASK_TI_PREEMPT_COUNT, task_struct, thread_info.preempt_count);
>   	OFFSET(TASK_TI_KERNEL_SP, task_struct, thread_info.kernel_sp);
>   	OFFSET(TASK_TI_USER_SP, task_struct, thread_info.user_sp);
> +	OFFSET(TASK_TI_A0, task_struct, thread_info.a0);
> +	OFFSET(TASK_TI_A1, task_struct, thread_info.a1);
> +	OFFSET(TASK_TI_A2, task_struct, thread_info.a2);
>   
>   	OFFSET(TASK_THREAD_F0,  task_struct, thread.fstate.f[0]);
>   	OFFSET(TASK_THREAD_F1,  task_struct, thread.fstate.f[1]);
> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
> index 143a2bb3e697..3a3c7b563816 100644
> --- a/arch/riscv/kernel/entry.S
> +++ b/arch/riscv/kernel/entry.S
> @@ -14,6 +14,88 @@
>   #include <asm/asm-offsets.h>
>   #include <asm/errata_list.h>
>   
> +.macro new_vmalloc_check
> +	REG_S 	a0, TASK_TI_A0(tp)
> +	REG_S 	a1, TASK_TI_A1(tp)
> +	REG_S	a2, TASK_TI_A2(tp)
> +
> +	csrr 	a0, CSR_CAUSE
> +	/* Exclude IRQs */
> +	blt  	a0, zero, _new_vmalloc_restore_context
> +	/* Only check new_vmalloc if we are in page/protection fault */
> +	li   	a1, EXC_LOAD_PAGE_FAULT
> +	beq  	a0, a1, _new_vmalloc_kernel_address
> +	li   	a1, EXC_STORE_PAGE_FAULT
> +	beq  	a0, a1, _new_vmalloc_kernel_address
> +	li   	a1, EXC_INST_PAGE_FAULT
> +	bne  	a0, a1, _new_vmalloc_restore_context
> +
> +_new_vmalloc_kernel_address:
> +	/* Is it a kernel address? */
> +	csrr 	a0, CSR_TVAL
> +	bge 	a0, zero, _new_vmalloc_restore_context
> +
> +	/* Check if a new vmalloc mapping appeared that could explain the trap */
> +
> +	/*
> +	 * Computes:
> +	 * a0 = &new_vmalloc[BIT_WORD(cpu)]
> +	 * a1 = BIT_MASK(cpu)
> +	 */
> +	REG_L 	a2, TASK_TI_CPU(tp)
> +	/*
> +	 * Compute the new_vmalloc element position:
> +	 * (cpu / 64) * 8 = (cpu >> 6) << 3
> +	 */
> +	srli	a1, a2, 6
> +	slli	a1, a1, 3
> +	la	a0, new_vmalloc
> +	add	a0, a0, a1
> +	/*
> +	 * Compute the bit position in the new_vmalloc element:
> +	 * bit_pos = cpu % 64 = cpu - (cpu / 64) * 64 = cpu - (cpu >> 6) << 6
> +	 * 	   = cpu - ((cpu >> 6) << 3) << 3
> +	 */
> +	slli	a1, a1, 3
> +	sub	a1, a2, a1
> +	/* Compute the "get mask": 1 << bit_pos */
> +	li	a2, 1
> +	sll	a1, a2, a1
> +
> +	/* Check the value of new_vmalloc for this cpu */
> +	ld	a2, 0(a0)
> +	and	a2, a2, a1
> +	beq	a2, zero, _new_vmalloc_restore_context
> +
> +	ld	a2, 0(a0)
> +	not	a1, a1
> +	and	a1, a2, a1
> +	sd	a1, 0(a0)
> +
> +	/* Only emit a sfence.vma if the uarch caches invalid entries */
> +	la	a0, tlb_caching_invalid_entries
> +	lb	a0, 0(a0)
> +	beqz	a0, _new_vmalloc_no_caching_invalid_entries
> +	sfence.vma
> +_new_vmalloc_no_caching_invalid_entries:
> +	// debug
> +	la	a0, nr_sfence_vma_handle_exception
> +	li	a1, 1
> +	amoadd.w    a0, a1, (a0)
> +	// end debug
> +	REG_L	a0, TASK_TI_A0(tp)
> +	REG_L	a1, TASK_TI_A1(tp)
> +	REG_L	a2, TASK_TI_A2(tp)
> +	csrw	CSR_SCRATCH, x0
> +	sret
> +
> +_new_vmalloc_restore_context:
> +	REG_L	a0, TASK_TI_A0(tp)
> +	REG_L 	a1, TASK_TI_A1(tp)
> +	REG_L 	a2, TASK_TI_A2(tp)
> +.endm
> +
> +
>   SYM_CODE_START(handle_exception)
>   	/*
>   	 * If coming from userspace, preserve the user thread pointer and load
> @@ -25,6 +107,18 @@ SYM_CODE_START(handle_exception)
>   
>   _restore_kernel_tpsp:
>   	csrr tp, CSR_SCRATCH
> +
> +	/*
> +	 * The RISC-V kernel does not eagerly emit a sfence.vma after each
> +	 * new vmalloc mapping, which may result in exceptions:
> +	 * - if the uarch caches invalid entries, the new mapping would not be
> +	 *   observed by the page table walker and an invalidation is needed.
> +	 * - if the uarch does not cache invalid entries, a reordered access
> +	 *   could "miss" the new mapping and traps: in that case, we only need
> +	 *   to retry the access, no sfence.vma is required.
> +	 */
> +	new_vmalloc_check
> +
>   	REG_S sp, TASK_TI_KERNEL_SP(tp)
>   
>   #ifdef CONFIG_VMAP_STACK
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 0798bd861dcb..379403de6c6f 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -36,6 +36,8 @@
>   
>   #include "../kernel/head.h"
>   
> +u64 new_vmalloc[NR_CPUS / sizeof(u64) + 1];
> +
>   struct kernel_mapping kernel_map __ro_after_init;
>   EXPORT_SYMBOL(kernel_map);
>   #ifdef CONFIG_XIP_KERNEL

From christophe.leroy at csgroup.eu  Thu Dec  7 07:55:39 2023
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 7 Dec 2023 15:55:39 +0000
Subject: [PATCH RFC/RFT 2/4] riscv: Add a runtime detection of invalid TLB
 entries caching
In-Reply-To: <20231207150348.82096-3-alexghiti@rivosinc.com>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
 <20231207150348.82096-3-alexghiti@rivosinc.com>
Message-ID: <6e3fb7b0-f47d-4d2f-b1b8-3ecc047b9ebf@csgroup.eu>



Le 07/12/2023 ? 16:03, Alexandre Ghiti a ?crit?:
> This mechanism allows to completely bypass the sfence.vma introduced by
> the previous commit for uarchs that do not cache invalid TLB entries.
> 
> Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
> ---
>   arch/riscv/mm/init.c | 124 +++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 124 insertions(+)
> 
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 379403de6c6f..2e854613740c 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -56,6 +56,8 @@ bool pgtable_l5_enabled = IS_ENABLED(CONFIG_64BIT) && !IS_ENABLED(CONFIG_XIP_KER
>   EXPORT_SYMBOL(pgtable_l4_enabled);
>   EXPORT_SYMBOL(pgtable_l5_enabled);
>   
> +bool tlb_caching_invalid_entries;
> +
>   phys_addr_t phys_ram_base __ro_after_init;
>   EXPORT_SYMBOL(phys_ram_base);
>   
> @@ -750,6 +752,18 @@ static void __init disable_pgtable_l4(void)
>   	satp_mode = SATP_MODE_39;
>   }
>   
> +static void __init enable_pgtable_l5(void)
> +{
> +	pgtable_l5_enabled = true;
> +	satp_mode = SATP_MODE_57;
> +}
> +
> +static void __init enable_pgtable_l4(void)
> +{
> +	pgtable_l4_enabled = true;
> +	satp_mode = SATP_MODE_48;
> +}
> +
>   static int __init print_no4lvl(char *p)
>   {
>   	pr_info("Disabled 4-level and 5-level paging");
> @@ -826,6 +840,112 @@ static __init void set_satp_mode(uintptr_t dtb_pa)
>   	memset(early_pud, 0, PAGE_SIZE);
>   	memset(early_pmd, 0, PAGE_SIZE);
>   }
> +
> +/* Determine at runtime if the uarch caches invalid TLB entries */
> +static __init void set_tlb_caching_invalid_entries(void)
> +{
> +#define NR_RETRIES_CACHING_INVALID_ENTRIES	50

Looks odd to have macros nested in the middle of a function.

> +	uintptr_t set_tlb_caching_invalid_entries_pmd = ((unsigned long)set_tlb_caching_invalid_entries) & PMD_MASK;
> +	// TODO the test_addr as defined below could go into another pud...
> +	uintptr_t test_addr = set_tlb_caching_invalid_entries_pmd + 2 * PMD_SIZE;
> +	pmd_t valid_pmd;
> +	u64 satp;
> +	int i = 0;
> +
> +	/* To ease the page table creation */
> +	disable_pgtable_l5();
> +	disable_pgtable_l4();
> +
> +	/* Establish a mapping for set_tlb_caching_invalid_entries() in sv39 */
> +	create_pgd_mapping(early_pg_dir,
> +			   set_tlb_caching_invalid_entries_pmd,
> +			   (uintptr_t)early_pmd,
> +			   PGDIR_SIZE, PAGE_TABLE);
> +
> +	/* Handle the case where set_tlb_caching_invalid_entries straddles 2 PMDs */
> +	create_pmd_mapping(early_pmd,
> +			   set_tlb_caching_invalid_entries_pmd,
> +			   set_tlb_caching_invalid_entries_pmd,
> +			   PMD_SIZE, PAGE_KERNEL_EXEC);
> +	create_pmd_mapping(early_pmd,
> +			   set_tlb_caching_invalid_entries_pmd + PMD_SIZE,
> +			   set_tlb_caching_invalid_entries_pmd + PMD_SIZE,
> +			   PMD_SIZE, PAGE_KERNEL_EXEC);
> +
> +	/* Establish an invalid mapping */
> +	create_pmd_mapping(early_pmd, test_addr, 0, PMD_SIZE, __pgprot(0));
> +
> +	/* Precompute the valid pmd here because the mapping for pfn_pmd() won't exist */
> +	valid_pmd = pfn_pmd(PFN_DOWN(set_tlb_caching_invalid_entries_pmd), PAGE_KERNEL);
> +
> +	local_flush_tlb_all();
> +	satp = PFN_DOWN((uintptr_t)&early_pg_dir) | SATP_MODE_39;
> +	csr_write(CSR_SATP, satp);
> +
> +	/*
> +	 * Set stvec to after the trapping access, access this invalid mapping
> +	 * and legitimately trap
> +	 */
> +	// TODO: Should I save the previous stvec?
> +#define ASM_STR(x)	__ASM_STR(x)

Looks odd to have macros nested in the middle of a function.


> +	asm volatile(
> +		"la a0, 1f				\n"
> +		"csrw " ASM_STR(CSR_TVEC) ", a0		\n"
> +		"ld a0, 0(%0)				\n"
> +		".align 2				\n"
> +		"1:					\n"
> +		:
> +		: "r" (test_addr)
> +		: "a0"
> +	);
> +
> +	/* Now establish a valid mapping to check if the invalid one is cached */
> +	early_pmd[pmd_index(test_addr)] = valid_pmd;
> +
> +	/*
> +	 * Access the valid mapping multiple times: indeed, we can't use
> +	 * sfence.vma as a barrier to make sure the cpu did not reorder accesses
> +	 * so we may trap even if the uarch does not cache invalid entries. By
> +	 * trying a few times, we make sure that those uarchs will see the right
> +	 * mapping at some point.
> +	 */
> +
> +	i = NR_RETRIES_CACHING_INVALID_ENTRIES;
> +
> +#define ASM_STR(x)	__ASM_STR(x)

Deplicate define ?

> +	asm_volatile_goto(
> +		"la a0, 1f					\n"
> +		"csrw " ASM_STR(CSR_TVEC) ", a0			\n"
> +		".align 2					\n"
> +		"1:						\n"
> +		"addi %0, %0, -1				\n"
> +		"blt %0, zero, %l[caching_invalid_entries]	\n"
> +		"ld a0, 0(%1)					\n"
> +		:
> +		: "r" (i), "r" (test_addr)
> +		: "a0"
> +		: caching_invalid_entries
> +	);
> +
> +	csr_write(CSR_SATP, 0ULL);
> +	local_flush_tlb_all();
> +
> +	/* If we don't trap, the uarch does not cache invalid entries! */
> +	tlb_caching_invalid_entries = false;
> +	goto clean;
> +
> +caching_invalid_entries:
> +	csr_write(CSR_SATP, 0ULL);
> +	local_flush_tlb_all();
> +
> +	tlb_caching_invalid_entries = true;
> +clean:
> +	memset(early_pg_dir, 0, PAGE_SIZE);
> +	memset(early_pmd, 0, PAGE_SIZE);

Use clear_page() instead ?

> +
> +	enable_pgtable_l4();
> +	enable_pgtable_l5();
> +}
>   #endif
>   
>   /*
> @@ -1072,6 +1192,7 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
>   #endif
>   
>   #if defined(CONFIG_64BIT) && !defined(CONFIG_XIP_KERNEL)
> +	set_tlb_caching_invalid_entries();
>   	set_satp_mode(dtb_pa);
>   #endif
>   
> @@ -1322,6 +1443,9 @@ static void __init setup_vm_final(void)
>   	local_flush_tlb_all();
>   
>   	pt_ops_set_late();
> +
> +	pr_info("uarch caches invalid entries: %s",
> +		tlb_caching_invalid_entries ? "yes" : "no");
>   }
>   #else
>   asmlinkage void __init setup_vm(uintptr_t dtb_pa)

From lkp at intel.com  Thu Dec  7 07:56:26 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 07 Dec 2023 23:56:26 +0800
Subject: [soc:soc/dt] BUILD SUCCESS
 9ea6b7dfff2c782954e90da5f49e539104e9d27a
Message-ID: <202312072324.goKDyoNL-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/dt
branch HEAD: 9ea6b7dfff2c782954e90da5f49e539104e9d27a  Merge tag 'renesas-dts-for-v6.8-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt

elapsed time: 1372m

configs tested: 159
configs skipped: 88

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231207   gcc  
arc                   randconfig-002-20231207   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                                 defconfig   clang
arm                           h3600_defconfig   gcc  
arm                      jornada720_defconfig   gcc  
arm                        multi_v7_defconfig   gcc  
arm                   randconfig-001-20231207   gcc  
arm                   randconfig-002-20231207   gcc  
arm                   randconfig-003-20231207   gcc  
arm                   randconfig-004-20231207   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231207   gcc  
arm64                 randconfig-002-20231207   gcc  
arm64                 randconfig-003-20231207   gcc  
arm64                 randconfig-004-20231207   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231207   gcc  
csky                  randconfig-002-20231207   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231207   clang
i386                  randconfig-012-20231207   clang
i386                  randconfig-013-20231207   clang
i386                  randconfig-014-20231207   clang
i386                  randconfig-015-20231207   clang
i386                  randconfig-016-20231207   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231207   gcc  
loongarch             randconfig-002-20231207   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5272c3_defconfig   gcc  
m68k                        mvme147_defconfig   gcc  
m68k                        stmark2_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                       bmips_be_defconfig   gcc  
mips                           ci20_defconfig   gcc  
mips                           ip27_defconfig   gcc  
mips                      loongson3_defconfig   gcc  
mips                         rt305x_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231207   gcc  
nios2                 randconfig-002-20231207   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231207   gcc  
parisc                randconfig-002-20231207   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                      ep88xc_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                     mpc83xx_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc               randconfig-001-20231207   gcc  
powerpc               randconfig-002-20231207   gcc  
powerpc               randconfig-003-20231207   gcc  
powerpc                    socrates_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
powerpc64             randconfig-001-20231207   gcc  
powerpc64             randconfig-002-20231207   gcc  
powerpc64             randconfig-003-20231207   gcc  
riscv                            allmodconfig   gcc  
riscv                             allnoconfig   clang
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231207   gcc  
riscv                 randconfig-002-20231207   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                         ap325rxa_defconfig   gcc  
sh                                  defconfig   gcc  
sh                        dreamcast_defconfig   gcc  
sh                         ecovec24_defconfig   gcc  
sh                    randconfig-001-20231207   gcc  
sh                    randconfig-002-20231207   gcc  
sh                           se7722_defconfig   gcc  
sh                           se7750_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sh                              ul2_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231207   gcc  
sparc64               randconfig-002-20231207   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231207   gcc  
um                    randconfig-002-20231207   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231207   gcc  
x86_64       buildonly-randconfig-002-20231207   gcc  
x86_64       buildonly-randconfig-003-20231207   gcc  
x86_64       buildonly-randconfig-004-20231207   gcc  
x86_64       buildonly-randconfig-005-20231207   gcc  
x86_64       buildonly-randconfig-006-20231207   gcc  
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231207   gcc  
x86_64                randconfig-012-20231207   gcc  
x86_64                randconfig-013-20231207   gcc  
x86_64                randconfig-014-20231207   gcc  
x86_64                randconfig-015-20231207   gcc  
x86_64                randconfig-016-20231207   gcc  
x86_64                randconfig-071-20231207   gcc  
x86_64                randconfig-072-20231207   gcc  
x86_64                randconfig-073-20231207   gcc  
x86_64                randconfig-074-20231207   gcc  
x86_64                randconfig-075-20231207   gcc  
x86_64                randconfig-076-20231207   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231207   gcc  
xtensa                randconfig-002-20231207   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From festevam at gmail.com  Thu Dec  7 07:58:41 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 12:58:41 -0300
Subject: [PATCH 1/2] arm64: dts: imx8mm-evk: Move port under USB connector
Message-ID: <20231207155842.2645290-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per nxp,ptn5110.yaml, 'port' should be placed under 'connector'.

Do as requested to fix the following dt-schema warning:

imx8mm-evkb.dtb: tcpc at 50: 'port' does not match any of the regexes: 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index a882c86ec313..b53104ed8919 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -367,12 +367,6 @@ ptn5110: tcpc at 50 {
 		interrupts = <11 8>;
 		status = "okay";
 
-		port {
-			typec1_dr_sw: endpoint {
-				remote-endpoint = <&usb1_drd_sw>;
-			};
-		};
-
 		typec1_con: connector {
 			compatible = "usb-c-connector";
 			label = "USB-C";
@@ -384,6 +378,12 @@ typec1_con: connector {
 				     PDO_VAR(5000, 20000, 3000)>;
 			op-sink-microwatt = <15000000>;
 			self-powered;
+
+			port {
+				typec1_dr_sw: endpoint {
+					remote-endpoint = <&usb1_drd_sw>;
+				};
+			};
 		};
 	};
 };
-- 
2.34.1



From festevam at gmail.com  Thu Dec  7 07:58:42 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 12:58:42 -0300
Subject: [PATCH 2/2] arm64: dts: imx8mn-evk: Move port under USB connector
In-Reply-To: <20231207155842.2645290-1-festevam@gmail.com>
References: <20231207155842.2645290-1-festevam@gmail.com>
Message-ID: <20231207155842.2645290-2-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per nxp,ptn5110.yaml, 'port' should be placed under 'connector'.

Do as requested to fix the following dt-schema warning:

imx8mn-evk.dtb: tcpc at 50: 'port' does not match any of the regexes: 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
	
Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
index 3f6a19839c9e..a0e13d3324ed 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
@@ -221,12 +221,6 @@ ptn5110: tcpc at 50 {
 		interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
 		status = "okay";
 
-		port {
-			typec1_dr_sw: endpoint {
-				remote-endpoint = <&usb1_drd_sw>;
-			};
-		};
-
 		typec1_con: connector {
 			compatible = "usb-c-connector";
 			label = "USB-C";
@@ -238,6 +232,12 @@ typec1_con: connector {
 				     PDO_VAR(5000, 20000, 3000)>;
 			op-sink-microwatt = <15000000>;
 			self-powered;
+
+			port {
+				typec1_dr_sw: endpoint {
+					remote-endpoint = <&usb1_drd_sw>;
+				};
+			};
 		};
 	};
 };
-- 
2.34.1



From dmitry.osipenko at collabora.com  Thu Dec  7 08:00:42 2023
From: dmitry.osipenko at collabora.com (Dmitry Osipenko)
Date: Thu, 7 Dec 2023 19:00:42 +0300
Subject: [PATCH v2] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <5e11553952c02ad20591992be4284bbd@manjaro.org>
References: <20231207082200.16388-1-jensenhuang@friendlyarm.com>
 <ebf6cf8ec3b5befd673d295061fa2738@manjaro.org>
 <CAMpZ1qHUnTDQ78gdrQF9Sx_-XfLM-B+H-0bL1-+twKsno+JOvg@mail.gmail.com>
 <5e11553952c02ad20591992be4284bbd@manjaro.org>
Message-ID: <95cc7716-ba01-e239-e7c0-eba0b7da7955@collabora.com>

On 12/7/23 17:10, Dragan Simic wrote:
> On 2023-12-07 10:25, Jensen Huang wrote:
>> On Thu, Dec 7, 2023 at 4:37?PM Dragan Simic <dsimic at manjaro.org> wrote:
>>>
>>> On 2023-12-07 09:21, Jensen Huang wrote:
>>> > Possible deadlock scenario (on reboot):
>>> > rk3x_i2c_xfer_common(polling)
>>> >???? -> rk3x_i2c_wait_xfer_poll()
>>> >???????? -> rk3x_i2c_irq(0, i2c);
>>> >???????????? --> spin_lock(&i2c->lock);
>>> >???????????? ...
>>> >???????? <rk3x i2c interrupt>
>>> >???????? -> rk3x_i2c_irq(0, i2c);
>>> >???????????? --> spin_lock(&i2c->lock); (deadlock here)
>>> >
>>> > Store the IRQ number and disable/enable it around the polling
>>> transfer.
>>> > This patch has been tested on NanoPC-T4.
>>>
>>> In case you haven't already seen the related discussion linked below,
>>> please have a look.? I also added more people to the list of recipients,
>>> in an attempt to make everyone aware of the different approaches to
>>> solving this issue.
>>>
>>> https://lore.kernel.org/all/655177f4.050a0220.d85c9.3ba0 at mx.google.com/T/#m6fc9c214452fec6681843e7f455978c35c6f6c8b
>>
>> Thank you for providing the information. I hadn't seen this link before.
>> After carefully looking into the related discussion, it appears that
>> Dmitry Osipenko is already working on a suitable patch. To avoid
>> duplication
>> or conflicts, my patch can be discarded.
> 
> Thank you for responding so quickly.? Perhaps it would be best to hear
> from Dmitry as well, before discarding anything.? It's been a while
> since Dmitry wrote about working on the patch, so he might have
> abandoned it.

This patch is okay. In general, will be better to have IRQ disabled by
default like I did in my variant, it should allow to remove the spinlock
entirely. Of course this also can be done later on in a follow up
patches. Jensen, feel free to use my variant of the patch, add my
s-o-b+co-developed tags to the commit msg if you'll do. Otherwise I'll
be able to send my patch next week.

-- 
Best regards,
Dmitry



From chunkuang.hu at kernel.org  Thu Dec  7 08:03:51 2023
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Fri, 8 Dec 2023 00:03:51 +0800
Subject: [PATCH -next 3/3] drm/mediatek: Use devm_platform_ioremap_resource()
In-Reply-To: <de13cb5f-abf2-86b3-d2e0-2b1131cd8dfa@baylibre.com>
References: <20230412064635.41315-1-yang.lee@linux.alibaba.com>
 <20230412064635.41315-3-yang.lee@linux.alibaba.com> <de13cb5f-abf2-86b3-d2e0-2b1131cd8dfa@baylibre.com>
Message-ID: <CAAOTY_-cO3P2GnMPK68GSRJKe8jguCK-cWENiu-3mXaRaHwmMA@mail.gmail.com>

Hi, Yang:

Alexandre Mergnat <amergnat at baylibre.com> ? 2023?4?12? ?? ??9:49???
>
> On 12/04/2023 08:46, Yang Li wrote:
> > Remove variable 'res' and convert platform_get_resource(),
> > devm_ioremap_resource() to a single call to
> > devm_platform_ioremap_resource(), as this is exactly what this function
> > does.
> >
> > Signed-off-by: Yang Li<yang.lee at linux.alibaba.com>
>
> Reviewed-by: Alexandre Mergnat <amergnat at baylibre.com>
>

Applied to mediatek-drm-next [1], thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

> --
> Regards,
> Alexandre
>


From ryan.roberts at arm.com  Thu Dec  7 08:12:01 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:01 +0000
Subject: [PATCH v9 00/10] Multi-size THP for anonymous memory
Message-ID: <20231207161211.2374093-1-ryan.roberts@arm.com>

Hi All,

This is v9 (and hopefully the last) of a series to implement multi-size THP
(mTHP) for anonymous memory (previously called "small-sized THP" and "large
anonymous folios").

The objective of this is to improve performance by allocating larger chunks of
memory during anonymous page faults:

1) Since SW (the kernel) is dealing with larger chunks of memory than base
   pages, there are efficiency savings to be had; fewer page faults, batched PTE
   and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
   overhead. This should benefit all architectures.
2) Since we are now mapping physically contiguous chunks of memory, we can take
   advantage of HW TLB compression techniques. A reduction in TLB pressure
   speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
   TLB entries; "the contiguous bit" (architectural) and HPA (uarch).

This version incorporates David's feedback on the core patches (#3, #4) and adds
some RB and TB tags (see change log for details).

By default, the existing behaviour (and performance) is maintained. The user
must explicitly enable multi-size THP to see the performance benefit. This is
done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
David for the suggestion)! This interface is inspired by the existing
per-hugepage-size sysfs interface used by hugetlb, provides full backwards
compatibility with the existing PMD-size THP interface, and provides a base for
future extensibility. See [9] for detailed discussion of the interface.

This series is based on mm-unstable (715b67adf4c8).


Prerequisites
=============

I'm removing this section on the basis that I don't believe what we were
previously calling prerequisites are really prerequisites anymore. We originally
defined them when mTHP was a compile-time feature. There is now a runtime
control to opt-in to mTHP; when disabled, correctness and performance are as
before. When enabled, the code is still correct/robust, but in the absence of
the one remaining item (compaction) there may be a performance impact in some
corners. See the old list in the v8 cover letter at [8]. And a longer
explanation of my thinking here [10].

SUMMARY: I don't think we should hold this series up, waiting for the items on
the prerequisites list. I believe this series should be ready now so hopefully
can be added to mm-unstable for some testing, then fingers crossed for v6.8.


Testing
=======

The series includes patches for mm selftests to enlighten the cow and khugepaged
tests to explicitly test with multi-size THP, in the same way that PMD-sized
THP is tested. The new tests all pass, and no regressions are observed in the mm
selftest suite. I've also run my usual kernel compilation and java script
benchmarks without any issues.

Refer to my performance numbers posted with v6 [6]. (These are for multi-size
THP only - they do not include the arm64 contpte follow-on series).

John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
some workloads at [11]. (Observed using v6 of this series as well as the arm64
contpte series).

Kefeng Wang at Huawei has also indicated he sees improvements at [12] although
there are some latency regressions also.

I've also checked that there is no regression in the write fault path when mTHP
is disabled using a microbenchmark. I ran it for a baseline kernel, as well as
v8 and v9. I repeated on Ampere Altra (bare metal) and Apple M2 (VM):

|              |        m2 vm        |        altra        |
|--------------|---------------------|---------------------|
| kernel       |     mean |  std_rel |     mean |  std_rel |
|--------------|----------|----------|----------|----------|
| baseline     |   0.000% |   0.341% |   0.000% |   3.581% |
| anonfolio-v8 |   0.005% |   0.272% |   5.068% |   1.128% |
| anonfolio-v9 |  -0.013% |   0.442% |   0.107% |   1.788% |

There is no measurable difference on M2, but altra has a slow down in v8 which
is fixed in v9 by moving the THP order check to be inline within
thp_vma_allowable_orders(), as suggested by David.


Changes since v8 [8]
====================

  - Added various Reviewed-by/Tested-by tags (Barry, David, Kefeng, John)
  - Patch 3:
      - Renamed first_order() -> highest_order() (David)
      - Made helpers for thp_vma_suitable_orders() thp_vma_allowable_orders()
        that take a single unencoded order parameter: thp_vma_suitable_order()
        and thp_vma_allowable_order(), and use them to aid readability (David)
      - Split thp_vma_allowable_orders() into an order-0 fast-path inline and
        slow-path __thp_vma_allowable_orders() part (David)
      - Added spin lock to serialize changes to huge_anon_orders_* fields to
        prevent possibility of clearing all bits when threads are racing (David)
  - Patch 4:
      - Pass address of faulting page (not start of folio) to clear_huge_page()
      - Reverse xmas tree for variable lists (David)
      - Added unlikely() for uffd check (David)
      - tidied up a local variable in alloc_anon_folio() (David)
      - Separated update_mmu_tlb() handling for nr_pages == 1 vs > 1 (David)


Changes since v7 [7]
====================

  - Renamed "small-sized THP" -> "multi-size THP" in commit logs
  - Added various Reviewed-by/Tested-by tags (Barry, David, Alistair)
  - Patch 3:
      - Fine-tuned transhuge documentation multi-size THP (JohnH)
      - Converted hugepage_global_enabled() and hugepage_global_always() macros
        to static inline functions (JohnH)
      - Renamed hugepage_vma_check() to thp_vma_allowable_orders() (JohnH)
      - Renamed transhuge_vma_suitable() to thp_vma_suitable_orders() (JohnH)
      - Renamed "global" enabled sysfs file option to "inherit" (JohnH)
  - Patch 9:
      - cow selftest: Renamed param size -> thpsize (David)
      - cow selftest: Changed test fail to assert() (David)
      - cow selftest: Log PMD size separately from all the supported THP sizes
        (David)
  - Patch 10:
      - cow selftest: No longer special case pmdsize; keep all THP sizes in
        thpsizes[]


Changes since v6 [6]
====================

  - Refactored vmf_pte_range_changed() to remove uffd special-case (suggested by
    JohnH)
  - Dropped accounting patch (#3 in v6) (suggested by DavidH)
      - Continue to account *PMD-sized* THP only for now
      - Can add more counters in future if needed
      - Page cache large folios haven't needed any new counters yet
  - Pivot to sysfs ABI proposed by DavidH
      - per-size directories in a similar shape to that used by hugetlb
  - Dropped "recommend" keyword patch (#6 in v6) (suggested by DavidH, Yu Zhou)
      - For now, users need to understand implicitly which sizes are beneficial
        to their HW/SW
  - Dropped arch_wants_pte_order() patch (#7 in v6)
      - No longer needed due to dropping patch "recommend" keyword patch
  - Enlightened khugepaged mm selftest to explicitly test with small-size THP
  - Scrubbed commit logs to use "small-sized THP" consistently (suggested by
    DavidH)


Changes since v5 [5]
====================

  - Added accounting for PTE-mapped THPs (patch 3)
  - Added runtime control mechanism via sysfs as extension to THP (patch 4)
  - Minor refactoring of alloc_anon_folio() to integrate with runtime controls
  - Stripped out hardcoded policy for allocation order; its now all user space
    controlled (although user space can request "recommend" which will configure
    the HW-preferred order)


Changes since v4 [4]
====================

  - Removed "arm64: mm: Override arch_wants_pte_order()" patch; arm64
    now uses the default order-3 size. I have moved this patch over to
    the contpte series.
  - Added "mm: Allow deferred splitting of arbitrary large anon folios" back
    into series. I originally removed this at v2 to add to a separate series,
    but that series has transformed significantly and it no longer fits, so
    bringing it back here.
  - Reintroduced dependency on set_ptes(); Originally dropped this at v2, but
    set_ptes() is in mm-unstable now.
  - Updated policy for when to allocate LAF; only fallback to order-0 if
    MADV_NOHUGEPAGE is present or if THP disabled via prctl; no longer rely on
    sysfs's never/madvise/always knob.
  - Fallback to order-0 whenever uffd is armed for the vma, not just when
    uffd-wp is set on the pte.
  - alloc_anon_folio() now returns `struct folio *`, where errors are encoded
    with ERR_PTR().

  The last 3 changes were proposed by Yu Zhao - thanks!


Changes since v3 [3]
====================

  - Renamed feature from FLEXIBLE_THP to LARGE_ANON_FOLIO.
  - Removed `flexthp_unhinted_max` boot parameter. Discussion concluded that a
    sysctl is preferable but we will wait until real workload needs it.
  - Fixed uninitialized `addr` on read fault path in do_anonymous_page().
  - Added mm selftests for large anon folios in cow test suite.


Changes since v2 [2]
====================

  - Dropped commit "Allow deferred splitting of arbitrary large anon folios"
      - Huang, Ying suggested the "batch zap" work (which I dropped from this
        series after v1) is a prerequisite for merging FLXEIBLE_THP, so I've
        moved the deferred split patch to a separate series along with the batch
        zap changes. I plan to submit this series early next week.
  - Changed folio order fallback policy
      - We no longer iterate from preferred to 0 looking for acceptable policy
      - Instead we iterate through preferred, PAGE_ALLOC_COSTLY_ORDER and 0 only
  - Removed vma parameter from arch_wants_pte_order()
  - Added command line parameter `flexthp_unhinted_max`
      - clamps preferred order when vma hasn't explicitly opted-in to THP
  - Never allocate large folio for MADV_NOHUGEPAGE vma (or when THP is disabled
    for process or system).
  - Simplified implementation and integration with do_anonymous_page()
  - Removed dependency on set_ptes()


Changes since v1 [1]
====================

  - removed changes to arch-dependent vma_alloc_zeroed_movable_folio()
  - replaced with arch-independent alloc_anon_folio()
      - follows THP allocation approach
  - no longer retry with intermediate orders if allocation fails
      - fallback directly to order-0
  - remove folio_add_new_anon_rmap_range() patch
      - instead add its new functionality to folio_add_new_anon_rmap()
  - remove batch-zap pte mappings optimization patch
      - remove enabler folio_remove_rmap_range() patch too
      - These offer real perf improvement so will submit separately
  - simplify Kconfig
      - single FLEXIBLE_THP option, which is independent of arch
      - depends on TRANSPARENT_HUGEPAGE
      - when enabled default to max anon folio size of 64K unless arch
        explicitly overrides
  - simplify changes to do_anonymous_page():
      - no more retry loop


[1] https://lore.kernel.org/linux-mm/20230626171430.3167004-1-ryan.roberts at arm.com/
[2] https://lore.kernel.org/linux-mm/20230703135330.1865927-1-ryan.roberts at arm.com/
[3] https://lore.kernel.org/linux-mm/20230714160407.4142030-1-ryan.roberts at arm.com/
[4] https://lore.kernel.org/linux-mm/20230726095146.2826796-1-ryan.roberts at arm.com/
[5] https://lore.kernel.org/linux-mm/20230810142942.3169679-1-ryan.roberts at arm.com/
[6] https://lore.kernel.org/linux-mm/20230929114421.3761121-1-ryan.roberts at arm.com/
[7] https://lore.kernel.org/linux-mm/20231122162950.3854897-1-ryan.roberts at arm.com/
[8] https://lore.kernel.org/linux-mm/20231204102027.57185-1-ryan.roberts at arm.com/
[9] https://lore.kernel.org/linux-mm/6d89fdc9-ef55-d44e-bf12-fafff318aef8 at redhat.com/
[10] https://lore.kernel.org/linux-mm/2de0617e-d1d7-49ec-9cb8-206eaf37caed at arm.com/
[11] https://lore.kernel.org/linux-mm/c507308d-bdd4-5f9e-d4ff-e96e4520be85 at nvidia.com/
[12] https://lore.kernel.org/linux-mm/b8f5a47a-af1e-44ed-a89b-460d0be56d2c at huawei.com/


Thanks,
Ryan

Ryan Roberts (10):
  mm: Allow deferred splitting of arbitrary anon large folios
  mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()
  mm: thp: Introduce multi-size THP sysfs interface
  mm: thp: Support allocation of anonymous multi-size THP
  selftests/mm/kugepaged: Restore thp settings at exit
  selftests/mm: Factor out thp settings management
  selftests/mm: Support multi-size THP interface in thp_settings
  selftests/mm/khugepaged: Enlighten for multi-size THP
  selftests/mm/cow: Generalize do_run_with_thp() helper
  selftests/mm/cow: Add tests for anonymous multi-size THP

 Documentation/admin-guide/mm/transhuge.rst |  97 ++++-
 Documentation/filesystems/proc.rst         |   6 +-
 fs/proc/task_mmu.c                         |   3 +-
 include/linux/huge_mm.h                    | 183 +++++++--
 mm/huge_memory.c                           | 231 ++++++++++--
 mm/khugepaged.c                            |  20 +-
 mm/memory.c                                | 117 +++++-
 mm/page_vma_mapped.c                       |   3 +-
 mm/rmap.c                                  |  32 +-
 tools/testing/selftests/mm/Makefile        |   4 +-
 tools/testing/selftests/mm/cow.c           | 185 +++++++---
 tools/testing/selftests/mm/khugepaged.c    | 410 ++++-----------------
 tools/testing/selftests/mm/run_vmtests.sh  |   2 +
 tools/testing/selftests/mm/thp_settings.c  | 349 ++++++++++++++++++
 tools/testing/selftests/mm/thp_settings.h  |  80 ++++
 15 files changed, 1218 insertions(+), 504 deletions(-)
 create mode 100644 tools/testing/selftests/mm/thp_settings.c
 create mode 100644 tools/testing/selftests/mm/thp_settings.h

--
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:02 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:02 +0000
Subject: [PATCH v9 01/10] mm: Allow deferred splitting of arbitrary anon large folios
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-2-ryan.roberts@arm.com>

In preparation for the introduction of anonymous multi-size THP, we
would like to be able to split them when they have unmapped subpages, in
order to free those unused pages under memory pressure. So remove the
artificial requirement that the large folio needed to be at least
PMD-sized.

Reviewed-by: Yu Zhao <yuzhao at google.com>
Reviewed-by: Yin Fengwei <fengwei.yin at intel.com>
Reviewed-by: Matthew Wilcox (Oracle) <willy at infradead.org>
Reviewed-by: David Hildenbrand <david at redhat.com>
Reviewed-by: Barry Song <v-songbaohua at oppo.com>
Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 mm/rmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index de9426ad0f1b..2a1e45e6419f 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1518,11 +1518,11 @@ void page_remove_rmap(struct page *page, struct vm_area_struct *vma,
 		__lruvec_stat_mod_folio(folio, idx, -nr);
 
 		/*
-		 * Queue anon THP for deferred split if at least one
+		 * Queue anon large folio for deferred split if at least one
 		 * page of the folio is unmapped and at least one page
 		 * is still mapped.
 		 */
-		if (folio_test_pmd_mappable(folio) && folio_test_anon(folio))
+		if (folio_test_large(folio) && folio_test_anon(folio))
 			if (!compound || nr < nr_pmdmapped)
 				deferred_split_folio(folio);
 	}
-- 
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:03 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:03 +0000
Subject: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-3-ryan.roberts@arm.com>

In preparation for supporting anonymous multi-size THP, improve
folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be
passed to it. In this case, all contained pages are accounted using the
order-0 folio (or base page) scheme.

Reviewed-by: Yu Zhao <yuzhao at google.com>
Reviewed-by: Yin Fengwei <fengwei.yin at intel.com>
Reviewed-by: David Hildenbrand <david at redhat.com>
Reviewed-by: Barry Song <v-songbaohua at oppo.com>
Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 mm/rmap.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index 2a1e45e6419f..846fc79f3ca9 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma,
  * This means the inc-and-test can be bypassed.
  * The folio does not have to be locked.
  *
- * If the folio is large, it is accounted as a THP.  As the folio
+ * If the folio is pmd-mappable, it is accounted as a THP.  As the folio
  * is new, it's assumed to be mapped exclusively by a single process.
  */
 void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
 		unsigned long address)
 {
-	int nr;
+	int nr = folio_nr_pages(folio);
 
-	VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
+	VM_BUG_ON_VMA(address < vma->vm_start ||
+			address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
 	__folio_set_swapbacked(folio);
+	__folio_set_anon(folio, vma, address, true);
 
-	if (likely(!folio_test_pmd_mappable(folio))) {
+	if (likely(!folio_test_large(folio))) {
 		/* increment count (starts at -1) */
 		atomic_set(&folio->_mapcount, 0);
-		nr = 1;
+		SetPageAnonExclusive(&folio->page);
+	} else if (!folio_test_pmd_mappable(folio)) {
+		int i;
+
+		for (i = 0; i < nr; i++) {
+			struct page *page = folio_page(folio, i);
+
+			/* increment count (starts at -1) */
+			atomic_set(&page->_mapcount, 0);
+			SetPageAnonExclusive(page);
+		}
+
+		atomic_set(&folio->_nr_pages_mapped, nr);
 	} else {
 		/* increment count (starts at -1) */
 		atomic_set(&folio->_entire_mapcount, 0);
 		atomic_set(&folio->_nr_pages_mapped, COMPOUND_MAPPED);
-		nr = folio_nr_pages(folio);
+		SetPageAnonExclusive(&folio->page);
 		__lruvec_stat_mod_folio(folio, NR_ANON_THPS, nr);
 	}
 
 	__lruvec_stat_mod_folio(folio, NR_ANON_MAPPED, nr);
-	__folio_set_anon(folio, vma, address, true);
-	SetPageAnonExclusive(&folio->page);
 }
 
 /**
-- 
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:04 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:04 +0000
Subject: [PATCH v9 03/10] mm: thp: Introduce multi-size THP sysfs interface
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-4-ryan.roberts@arm.com>

In preparation for adding support for anonymous multi-size THP,
introduce new sysfs structure that will be used to control the new
behaviours. A new directory is added under transparent_hugepage for each
supported THP size, and contains an `enabled` file, which can be set to
"inherit" (to inherit the global setting), "always", "madvise" or
"never". For now, the kernel still only supports PMD-sized anonymous
THP, so only 1 directory is populated.

The first half of the change converts transhuge_vma_suitable() and
hugepage_vma_check() so that they take a bitfield of orders for which
the user wants to determine support, and the functions filter out all
the orders that can't be supported, given the current sysfs
configuration and the VMA dimensions. The resulting functions are
renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
respectively. Convenience functions that take a single, unencoded order
and return a boolean are also defined as thp_vma_suitable_order() and
thp_vma_allowable_order().

The second half of the change implements the new sysfs interface. It has
been done so that each supported THP size has a `struct thpsize`, which
describes the relevant metadata and is itself a kobject. This is pretty
minimal for now, but should make it easy to add new per-thpsize files to
the interface if needed in future (e.g. per-size defrag). Rather than
keep the `enabled` state directly in the struct thpsize, I've elected to
directly encode it into huge_anon_orders_[always|madvise|inherit]
bitfields since this reduces the amount of work required in
thp_vma_allowable_orders() which is called for every page fault.

See Documentation/admin-guide/mm/transhuge.rst, as modified by this
commit, for details of how the new sysfs interface works.

Reviewed-by: Barry Song <v-songbaohua at oppo.com>
Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 Documentation/admin-guide/mm/transhuge.rst |  97 +++++++--
 Documentation/filesystems/proc.rst         |   6 +-
 fs/proc/task_mmu.c                         |   3 +-
 include/linux/huge_mm.h                    | 181 +++++++++++++---
 mm/huge_memory.c                           | 231 ++++++++++++++++++---
 mm/khugepaged.c                            |  20 +-
 mm/memory.c                                |   6 +-
 mm/page_vma_mapped.c                       |   3 +-
 8 files changed, 459 insertions(+), 88 deletions(-)

diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
index b0cc8243e093..04eb45a2f940 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -45,10 +45,25 @@ components:
    the two is using hugepages just because of the fact the TLB miss is
    going to run faster.
 
+Modern kernels support "multi-size THP" (mTHP), which introduces the
+ability to allocate memory in blocks that are bigger than a base page
+but smaller than traditional PMD-size (as described above), in
+increments of a power-of-2 number of pages. mTHP can back anonymous
+memory (for example 16K, 32K, 64K, etc). These THPs continue to be
+PTE-mapped, but in many cases can still provide similar benefits to
+those outlined above: Page faults are significantly reduced (by a
+factor of e.g. 4, 8, 16, etc), but latency spikes are much less
+prominent because the size of each page isn't as huge as the PMD-sized
+variant and there is less memory to clear in each page fault. Some
+architectures also employ TLB compression mechanisms to squeeze more
+entries in when a set of PTEs are virtually and physically contiguous
+and approporiately aligned. In this case, TLB misses will occur less
+often.
+
 THP can be enabled system wide or restricted to certain tasks or even
 memory ranges inside task's address space. Unless THP is completely
 disabled, there is ``khugepaged`` daemon that scans memory and
-collapses sequences of basic pages into huge pages.
+collapses sequences of basic pages into PMD-sized huge pages.
 
 The THP behaviour is controlled via :ref:`sysfs <thp_sysfs>`
 interface and using madvise(2) and prctl(2) system calls.
@@ -95,12 +110,40 @@ Global THP controls
 Transparent Hugepage Support for anonymous memory can be entirely disabled
 (mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE
 regions (to avoid the risk of consuming more memory resources) or enabled
-system wide. This can be achieved with one of::
+system wide. This can be achieved per-supported-THP-size with one of::
+
+	echo always >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+	echo madvise >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+	echo never >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+
+where <size> is the hugepage size being addressed, the available sizes
+for which vary by system.
+
+For example::
+
+	echo always >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
+
+Alternatively it is possible to specify that a given hugepage size
+will inherit the top-level "enabled" value::
+
+	echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+
+For example::
+
+	echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
+
+The top-level setting (for use with "inherit") can be set by issuing
+one of the following commands::
 
 	echo always >/sys/kernel/mm/transparent_hugepage/enabled
 	echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
 	echo never >/sys/kernel/mm/transparent_hugepage/enabled
 
+By default, PMD-sized hugepages have enabled="inherit" and all other
+hugepage sizes have enabled="never". If enabling multiple hugepage
+sizes, the kernel will select the most appropriate enabled size for a
+given allocation.
+
 It's also possible to limit defrag efforts in the VM to generate
 anonymous hugepages in case they're not immediately free to madvise
 regions or to never try to defrag memory and simply fallback to regular
@@ -146,25 +189,34 @@ madvise
 never
 	should be self-explanatory.
 
-By default kernel tries to use huge zero page on read page fault to
-anonymous mapping. It's possible to disable huge zero page by writing 0
-or enable it back by writing 1::
+By default kernel tries to use huge, PMD-mappable zero page on read
+page fault to anonymous mapping. It's possible to disable huge zero
+page by writing 0 or enable it back by writing 1::
 
 	echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page
 	echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
 
-Some userspace (such as a test program, or an optimized memory allocation
-library) may want to know the size (in bytes) of a transparent hugepage::
+Some userspace (such as a test program, or an optimized memory
+allocation library) may want to know the size (in bytes) of a
+PMD-mappable transparent hugepage::
 
 	cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
 
-khugepaged will be automatically started when
-transparent_hugepage/enabled is set to "always" or "madvise, and it'll
-be automatically shutdown if it's set to "never".
+khugepaged will be automatically started when one or more hugepage
+sizes are enabled (either by directly setting "always" or "madvise",
+or by setting "inherit" while the top-level enabled is set to "always"
+or "madvise"), and it'll be automatically shutdown when the last
+hugepage size is disabled (either by directly setting "never", or by
+setting "inherit" while the top-level enabled is set to "never").
 
 Khugepaged controls
 -------------------
 
+.. note::
+   khugepaged currently only searches for opportunities to collapse to
+   PMD-sized THP and no attempt is made to collapse to other THP
+   sizes.
+
 khugepaged runs usually at low frequency so while one may not want to
 invoke defrag algorithms synchronously during the page faults, it
 should be worth invoking defrag at least in khugepaged. However it's
@@ -282,19 +334,26 @@ force
 Need of application restart
 ===========================
 
-The transparent_hugepage/enabled values and tmpfs mount option only affect
-future behavior. So to make them effective you need to restart any
-application that could have been using hugepages. This also applies to the
-regions registered in khugepaged.
+The transparent_hugepage/enabled and
+transparent_hugepage/hugepages-<size>kB/enabled values and tmpfs mount
+option only affect future behavior. So to make them effective you need
+to restart any application that could have been using hugepages. This
+also applies to the regions registered in khugepaged.
 
 Monitoring usage
 ================
 
-The number of anonymous transparent huge pages currently used by the
+.. note::
+   Currently the below counters only record events relating to
+   PMD-sized THP. Events relating to other THP sizes are not included.
+
+The number of PMD-sized anonymous transparent huge pages currently used by the
 system is available by reading the AnonHugePages field in ``/proc/meminfo``.
-To identify what applications are using anonymous transparent huge pages,
-it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages fields
-for each mapping.
+To identify what applications are using PMD-sized anonymous transparent huge
+pages, it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages
+fields for each mapping. (Note that AnonHugePages only applies to traditional
+PMD-sized THP for historical reasons and should have been called
+AnonHugePmdMapped).
 
 The number of file transparent huge pages mapped to userspace is available
 by reading ShmemPmdMapped and ShmemHugePages fields in ``/proc/meminfo``.
@@ -413,7 +472,7 @@ for huge pages.
 Optimizing the applications
 ===========================
 
-To be guaranteed that the kernel will map a 2M page immediately in any
+To be guaranteed that the kernel will map a THP immediately in any
 memory region, the mmap region has to be hugepage naturally
 aligned. posix_memalign() can provide that guarantee.
 
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 49ef12df631b..104c6d047d9b 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -528,9 +528,9 @@ replaced by copy-on-write) part of the underlying shmem object out on swap.
 does not take into account swapped out page of underlying shmem objects.
 "Locked" indicates whether the mapping is locked in memory or not.
 
-"THPeligible" indicates whether the mapping is eligible for allocating THP
-pages as well as the THP is PMD mappable or not - 1 if true, 0 otherwise.
-It just shows the current status.
+"THPeligible" indicates whether the mapping is eligible for allocating
+naturally aligned THP pages of any currently enabled size. 1 if true, 0
+otherwise.
 
 "VmFlags" field deserves a separate description. This member represents the
 kernel flags associated with the particular virtual memory area in two letter
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index d19924bf0a39..79855e1c5b57 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -865,7 +865,8 @@ static int show_smap(struct seq_file *m, void *v)
 	__show_smap(m, &mss, false);
 
 	seq_printf(m, "THPeligible:    %8u\n",
-		   hugepage_vma_check(vma, vma->vm_flags, true, false, true));
+		   !!thp_vma_allowable_orders(vma, vma->vm_flags, true, false,
+					      true, THP_ORDERS_ALL));
 
 	if (arch_pkeys_enabled())
 		seq_printf(m, "ProtectionKey:  %8u\n", vma_pkey(vma));
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index fa0350b0812a..609c153bae57 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -67,6 +67,24 @@ extern struct kobj_attribute shmem_enabled_attr;
 #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
 #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
 
+/*
+ * Mask of all large folio orders supported for anonymous THP.
+ */
+#define THP_ORDERS_ALL_ANON	BIT(PMD_ORDER)
+
+/*
+ * Mask of all large folio orders supported for file THP.
+ */
+#define THP_ORDERS_ALL_FILE	(BIT(PMD_ORDER) | BIT(PUD_ORDER))
+
+/*
+ * Mask of all large folio orders supported for THP.
+ */
+#define THP_ORDERS_ALL		(THP_ORDERS_ALL_ANON | THP_ORDERS_ALL_FILE)
+
+#define thp_vma_allowable_order(vma, vm_flags, smaps, in_pf, enforce_sysfs, order) \
+	(!!thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf, enforce_sysfs, BIT(order)))
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 #define HPAGE_PMD_SHIFT PMD_SHIFT
 #define HPAGE_PMD_SIZE	((1UL) << HPAGE_PMD_SHIFT)
@@ -77,45 +95,105 @@ extern struct kobj_attribute shmem_enabled_attr;
 #define HPAGE_PUD_MASK	(~(HPAGE_PUD_SIZE - 1))
 
 extern unsigned long transparent_hugepage_flags;
+extern unsigned long huge_anon_orders_always;
+extern unsigned long huge_anon_orders_madvise;
+extern unsigned long huge_anon_orders_inherit;
 
-#define hugepage_flags_enabled()					       \
-	(transparent_hugepage_flags &				       \
-	 ((1<<TRANSPARENT_HUGEPAGE_FLAG) |		       \
-	  (1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG)))
-#define hugepage_flags_always()				\
-	(transparent_hugepage_flags &			\
-	 (1<<TRANSPARENT_HUGEPAGE_FLAG))
+static inline bool hugepage_global_enabled(void)
+{
+	return transparent_hugepage_flags &
+			((1<<TRANSPARENT_HUGEPAGE_FLAG) |
+			(1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG));
+}
+
+static inline bool hugepage_global_always(void)
+{
+	return transparent_hugepage_flags &
+			(1<<TRANSPARENT_HUGEPAGE_FLAG);
+}
+
+static inline bool hugepage_flags_enabled(void)
+{
+	/*
+	 * We cover both the anon and the file-backed case here; we must return
+	 * true if globally enabled, even when all anon sizes are set to never.
+	 * So we don't need to look at huge_anon_orders_inherit.
+	 */
+	return hugepage_global_enabled() ||
+	       huge_anon_orders_always ||
+	       huge_anon_orders_madvise;
+}
+
+static inline int highest_order(unsigned long orders)
+{
+	return fls_long(orders) - 1;
+}
+
+static inline int next_order(unsigned long *orders, int prev)
+{
+	*orders &= ~BIT(prev);
+	return highest_order(*orders);
+}
 
 /*
  * Do the below checks:
  *   - For file vma, check if the linear page offset of vma is
- *     HPAGE_PMD_NR aligned within the file.  The hugepage is
- *     guaranteed to be hugepage-aligned within the file, but we must
- *     check that the PMD-aligned addresses in the VMA map to
- *     PMD-aligned offsets within the file, else the hugepage will
- *     not be PMD-mappable.
- *   - For all vmas, check if the haddr is in an aligned HPAGE_PMD_SIZE
+ *     order-aligned within the file.  The hugepage is
+ *     guaranteed to be order-aligned within the file, but we must
+ *     check that the order-aligned addresses in the VMA map to
+ *     order-aligned offsets within the file, else the hugepage will
+ *     not be mappable.
+ *   - For all vmas, check if the haddr is in an aligned hugepage
  *     area.
  */
-static inline bool transhuge_vma_suitable(struct vm_area_struct *vma,
-		unsigned long addr)
+static inline bool thp_vma_suitable_order(struct vm_area_struct *vma,
+		unsigned long addr, int order)
 {
+	unsigned long hpage_size = PAGE_SIZE << order;
 	unsigned long haddr;
 
 	/* Don't have to check pgoff for anonymous vma */
 	if (!vma_is_anonymous(vma)) {
 		if (!IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) - vma->vm_pgoff,
-				HPAGE_PMD_NR))
+				hpage_size >> PAGE_SHIFT))
 			return false;
 	}
 
-	haddr = addr & HPAGE_PMD_MASK;
+	haddr = ALIGN_DOWN(addr, hpage_size);
 
-	if (haddr < vma->vm_start || haddr + HPAGE_PMD_SIZE > vma->vm_end)
+	if (haddr < vma->vm_start || haddr + hpage_size > vma->vm_end)
 		return false;
 	return true;
 }
 
+/*
+ * Filter the bitfield of input orders to the ones suitable for use in the vma.
+ * See thp_vma_suitable_order().
+ * All orders that pass the checks are returned as a bitfield.
+ */
+static inline unsigned long thp_vma_suitable_orders(struct vm_area_struct *vma,
+		unsigned long addr, unsigned long orders)
+{
+	int order;
+
+	/*
+	 * Iterate over orders, highest to lowest, removing orders that don't
+	 * meet alignment requirements from the set. Exit loop at first order
+	 * that meets requirements, since all lower orders must also meet
+	 * requirements.
+	 */
+
+	order = highest_order(orders);
+
+	while (orders) {
+		if (thp_vma_suitable_order(vma, addr, order))
+			break;
+		order = next_order(&orders, order);
+	}
+
+	return orders;
+}
+
 static inline bool file_thp_enabled(struct vm_area_struct *vma)
 {
 	struct inode *inode;
@@ -130,8 +208,52 @@ static inline bool file_thp_enabled(struct vm_area_struct *vma)
 	       !inode_is_open_for_write(inode) && S_ISREG(inode->i_mode);
 }
 
-bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
-			bool smaps, bool in_pf, bool enforce_sysfs);
+unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
+					 unsigned long vm_flags, bool smaps,
+					 bool in_pf, bool enforce_sysfs,
+					 unsigned long orders);
+
+/**
+ * thp_vma_allowable_orders - determine hugepage orders that are allowed for vma
+ * @vma:  the vm area to check
+ * @vm_flags: use these vm_flags instead of vma->vm_flags
+ * @smaps: whether answer will be used for smaps file
+ * @in_pf: whether answer will be used by page fault handler
+ * @enforce_sysfs: whether sysfs config should be taken into account
+ * @orders: bitfield of all orders to consider
+ *
+ * Calculates the intersection of the requested hugepage orders and the allowed
+ * hugepage orders for the provided vma. Permitted orders are encoded as a set
+ * bit at the corresponding bit position (bit-2 corresponds to order-2, bit-3
+ * corresponds to order-3, etc). Order-0 is never considered a hugepage order.
+ *
+ * Return: bitfield of orders allowed for hugepage in the vma. 0 if no hugepage
+ * orders are allowed.
+ */
+static inline
+unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
+				       unsigned long vm_flags, bool smaps,
+				       bool in_pf, bool enforce_sysfs,
+				       unsigned long orders)
+{
+	/* Optimization to check if required orders are enabled early. */
+	if (enforce_sysfs && vma_is_anonymous(vma)) {
+		unsigned long mask = READ_ONCE(huge_anon_orders_always);
+
+		if (vm_flags & VM_HUGEPAGE)
+			mask |= READ_ONCE(huge_anon_orders_madvise);
+		if (hugepage_global_always() ||
+		    ((vm_flags & VM_HUGEPAGE) && hugepage_global_enabled()))
+			mask |= READ_ONCE(huge_anon_orders_inherit);
+
+		orders &= mask;
+		if (!orders)
+			return 0;
+	}
+
+	return __thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf,
+					  enforce_sysfs, orders);
+}
 
 #define transparent_hugepage_use_zero_page()				\
 	(transparent_hugepage_flags &					\
@@ -267,17 +389,24 @@ static inline bool folio_test_pmd_mappable(struct folio *folio)
 	return false;
 }
 
-static inline bool transhuge_vma_suitable(struct vm_area_struct *vma,
-		unsigned long addr)
+static inline bool thp_vma_suitable_order(struct vm_area_struct *vma,
+		unsigned long addr, int order)
 {
 	return false;
 }
 
-static inline bool hugepage_vma_check(struct vm_area_struct *vma,
-				      unsigned long vm_flags, bool smaps,
-				      bool in_pf, bool enforce_sysfs)
+static inline unsigned long thp_vma_suitable_orders(struct vm_area_struct *vma,
+		unsigned long addr, unsigned long orders)
 {
-	return false;
+	return 0;
+}
+
+static inline unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
+					unsigned long vm_flags, bool smaps,
+					bool in_pf, bool enforce_sysfs,
+					unsigned long orders)
+{
+	return 0;
 }
 
 static inline void folio_prep_large_rmappable(struct folio *folio) {}
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 8a65e2cb6126..cfb1d04a71b1 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -74,12 +74,24 @@ static unsigned long deferred_split_scan(struct shrinker *shrink,
 static atomic_t huge_zero_refcount;
 struct page *huge_zero_page __read_mostly;
 unsigned long huge_zero_pfn __read_mostly = ~0UL;
+unsigned long huge_anon_orders_always __read_mostly;
+unsigned long huge_anon_orders_madvise __read_mostly;
+unsigned long huge_anon_orders_inherit __read_mostly;
+static DEFINE_SPINLOCK(huge_anon_orders_lock);
+
+unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
+					 unsigned long vm_flags, bool smaps,
+					 bool in_pf, bool enforce_sysfs,
+					 unsigned long orders)
+{
+	/* Check the intersection of requested and supported orders. */
+	orders &= vma_is_anonymous(vma) ?
+			THP_ORDERS_ALL_ANON : THP_ORDERS_ALL_FILE;
+	if (!orders)
+		return 0;
 
-bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
-			bool smaps, bool in_pf, bool enforce_sysfs)
-{
 	if (!vma->vm_mm)		/* vdso */
-		return false;
+		return 0;
 
 	/*
 	 * Explicitly disabled through madvise or prctl, or some
@@ -88,16 +100,16 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
 	 * */
 	if ((vm_flags & VM_NOHUGEPAGE) ||
 	    test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
-		return false;
+		return 0;
 	/*
 	 * If the hardware/firmware marked hugepage support disabled.
 	 */
 	if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED))
-		return false;
+		return 0;
 
 	/* khugepaged doesn't collapse DAX vma, but page fault is fine. */
 	if (vma_is_dax(vma))
-		return in_pf;
+		return in_pf ? orders : 0;
 
 	/*
 	 * khugepaged special VMA and hugetlb VMA.
@@ -105,17 +117,29 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
 	 * VM_MIXEDMAP set.
 	 */
 	if (!in_pf && !smaps && (vm_flags & VM_NO_KHUGEPAGED))
-		return false;
+		return 0;
 
 	/*
-	 * Check alignment for file vma and size for both file and anon vma.
+	 * Check alignment for file vma and size for both file and anon vma by
+	 * filtering out the unsuitable orders.
 	 *
 	 * Skip the check for page fault. Huge fault does the check in fault
-	 * handlers. And this check is not suitable for huge PUD fault.
+	 * handlers.
 	 */
-	if (!in_pf &&
-	    !transhuge_vma_suitable(vma, (vma->vm_end - HPAGE_PMD_SIZE)))
-		return false;
+	if (!in_pf) {
+		int order = highest_order(orders);
+		unsigned long addr;
+
+		while (orders) {
+			addr = vma->vm_end - (PAGE_SIZE << order);
+			if (thp_vma_suitable_order(vma, addr, order))
+				break;
+			order = next_order(&orders, order);
+		}
+
+		if (!orders)
+			return 0;
+	}
 
 	/*
 	 * Enabled via shmem mount options or sysfs settings.
@@ -124,29 +148,33 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
 	 */
 	if (!in_pf && shmem_file(vma->vm_file))
 		return shmem_is_huge(file_inode(vma->vm_file), vma->vm_pgoff,
-				     !enforce_sysfs, vma->vm_mm, vm_flags);
-
-	/* Enforce sysfs THP requirements as necessary */
-	if (enforce_sysfs &&
-	    (!hugepage_flags_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
-					   !hugepage_flags_always())))
-		return false;
+				     !enforce_sysfs, vma->vm_mm, vm_flags)
+			? orders : 0;
 
 	if (!vma_is_anonymous(vma)) {
+		/*
+		 * Enforce sysfs THP requirements as necessary. Anonymous vmas
+		 * were already handled in thp_vma_allowable_orders().
+		 */
+		if (enforce_sysfs &&
+		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
+						    !hugepage_global_always())))
+			return 0;
+
 		/*
 		 * Trust that ->huge_fault() handlers know what they are doing
 		 * in fault path.
 		 */
 		if (((in_pf || smaps)) && vma->vm_ops->huge_fault)
-			return true;
+			return orders;
 		/* Only regular file is valid in collapse path */
 		if (((!in_pf || smaps)) && file_thp_enabled(vma))
-			return true;
-		return false;
+			return orders;
+		return 0;
 	}
 
 	if (vma_is_temporary_stack(vma))
-		return false;
+		return 0;
 
 	/*
 	 * THPeligible bit of smaps should show 1 for proper VMAs even
@@ -156,9 +184,9 @@ bool hugepage_vma_check(struct vm_area_struct *vma, unsigned long vm_flags,
 	 * the first page fault.
 	 */
 	if (!vma->anon_vma)
-		return (smaps || in_pf);
+		return (smaps || in_pf) ? orders : 0;
 
-	return true;
+	return orders;
 }
 
 static bool get_huge_zero_page(void)
@@ -412,9 +440,135 @@ static const struct attribute_group hugepage_attr_group = {
 	.attrs = hugepage_attr,
 };
 
+static void hugepage_exit_sysfs(struct kobject *hugepage_kobj);
+static void thpsize_release(struct kobject *kobj);
+static LIST_HEAD(thpsize_list);
+
+struct thpsize {
+	struct kobject kobj;
+	struct list_head node;
+	int order;
+};
+
+#define to_thpsize(kobj) container_of(kobj, struct thpsize, kobj)
+
+static ssize_t thpsize_enabled_show(struct kobject *kobj,
+				    struct kobj_attribute *attr, char *buf)
+{
+	int order = to_thpsize(kobj)->order;
+	const char *output;
+
+	if (test_bit(order, &huge_anon_orders_always))
+		output = "[always] inherit madvise never";
+	else if (test_bit(order, &huge_anon_orders_inherit))
+		output = "always [inherit] madvise never";
+	else if (test_bit(order, &huge_anon_orders_madvise))
+		output = "always inherit [madvise] never";
+	else
+		output = "always inherit madvise [never]";
+
+	return sysfs_emit(buf, "%s\n", output);
+}
+
+static ssize_t thpsize_enabled_store(struct kobject *kobj,
+				     struct kobj_attribute *attr,
+				     const char *buf, size_t count)
+{
+	int order = to_thpsize(kobj)->order;
+	ssize_t ret = count;
+
+	if (sysfs_streq(buf, "always")) {
+		spin_lock(&huge_anon_orders_lock);
+		clear_bit(order, &huge_anon_orders_inherit);
+		clear_bit(order, &huge_anon_orders_madvise);
+		set_bit(order, &huge_anon_orders_always);
+		spin_unlock(&huge_anon_orders_lock);
+	} else if (sysfs_streq(buf, "inherit")) {
+		spin_lock(&huge_anon_orders_lock);
+		clear_bit(order, &huge_anon_orders_always);
+		clear_bit(order, &huge_anon_orders_madvise);
+		set_bit(order, &huge_anon_orders_inherit);
+		spin_unlock(&huge_anon_orders_lock);
+	} else if (sysfs_streq(buf, "madvise")) {
+		spin_lock(&huge_anon_orders_lock);
+		clear_bit(order, &huge_anon_orders_always);
+		clear_bit(order, &huge_anon_orders_inherit);
+		set_bit(order, &huge_anon_orders_madvise);
+		spin_unlock(&huge_anon_orders_lock);
+	} else if (sysfs_streq(buf, "never")) {
+		spin_lock(&huge_anon_orders_lock);
+		clear_bit(order, &huge_anon_orders_always);
+		clear_bit(order, &huge_anon_orders_inherit);
+		clear_bit(order, &huge_anon_orders_madvise);
+		spin_unlock(&huge_anon_orders_lock);
+	} else
+		ret = -EINVAL;
+
+	return ret;
+}
+
+static struct kobj_attribute thpsize_enabled_attr =
+	__ATTR(enabled, 0644, thpsize_enabled_show, thpsize_enabled_store);
+
+static struct attribute *thpsize_attrs[] = {
+	&thpsize_enabled_attr.attr,
+	NULL,
+};
+
+static const struct attribute_group thpsize_attr_group = {
+	.attrs = thpsize_attrs,
+};
+
+static const struct kobj_type thpsize_ktype = {
+	.release = &thpsize_release,
+	.sysfs_ops = &kobj_sysfs_ops,
+};
+
+static struct thpsize *thpsize_create(int order, struct kobject *parent)
+{
+	unsigned long size = (PAGE_SIZE << order) / SZ_1K;
+	struct thpsize *thpsize;
+	int ret;
+
+	thpsize = kzalloc(sizeof(*thpsize), GFP_KERNEL);
+	if (!thpsize)
+		return ERR_PTR(-ENOMEM);
+
+	ret = kobject_init_and_add(&thpsize->kobj, &thpsize_ktype, parent,
+				   "hugepages-%lukB", size);
+	if (ret) {
+		kfree(thpsize);
+		return ERR_PTR(ret);
+	}
+
+	ret = sysfs_create_group(&thpsize->kobj, &thpsize_attr_group);
+	if (ret) {
+		kobject_put(&thpsize->kobj);
+		return ERR_PTR(ret);
+	}
+
+	thpsize->order = order;
+	return thpsize;
+}
+
+static void thpsize_release(struct kobject *kobj)
+{
+	kfree(to_thpsize(kobj));
+}
+
 static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
 {
 	int err;
+	struct thpsize *thpsize;
+	unsigned long orders;
+	int order;
+
+	/*
+	 * Default to setting PMD-sized THP to inherit the global setting and
+	 * disable all other sizes. powerpc's PMD_ORDER isn't a compile-time
+	 * constant so we have to do this here.
+	 */
+	huge_anon_orders_inherit = BIT(PMD_ORDER);
 
 	*hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
 	if (unlikely(!*hugepage_kobj)) {
@@ -434,8 +588,24 @@ static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
 		goto remove_hp_group;
 	}
 
+	orders = THP_ORDERS_ALL_ANON;
+	order = highest_order(orders);
+	while (orders) {
+		thpsize = thpsize_create(order, *hugepage_kobj);
+		if (IS_ERR(thpsize)) {
+			pr_err("failed to create thpsize for order %d\n", order);
+			err = PTR_ERR(thpsize);
+			goto remove_all;
+		}
+		list_add(&thpsize->node, &thpsize_list);
+		order = next_order(&orders, order);
+	}
+
 	return 0;
 
+remove_all:
+	hugepage_exit_sysfs(*hugepage_kobj);
+	return err;
 remove_hp_group:
 	sysfs_remove_group(*hugepage_kobj, &hugepage_attr_group);
 delete_obj:
@@ -445,6 +615,13 @@ static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj)
 
 static void __init hugepage_exit_sysfs(struct kobject *hugepage_kobj)
 {
+	struct thpsize *thpsize, *tmp;
+
+	list_for_each_entry_safe(thpsize, tmp, &thpsize_list, node) {
+		list_del(&thpsize->node);
+		kobject_put(&thpsize->kobj);
+	}
+
 	sysfs_remove_group(hugepage_kobj, &khugepaged_attr_group);
 	sysfs_remove_group(hugepage_kobj, &hugepage_attr_group);
 	kobject_put(hugepage_kobj);
@@ -811,7 +988,7 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf)
 	struct folio *folio;
 	unsigned long haddr = vmf->address & HPAGE_PMD_MASK;
 
-	if (!transhuge_vma_suitable(vma, haddr))
+	if (!thp_vma_suitable_order(vma, haddr, PMD_ORDER))
 		return VM_FAULT_FALLBACK;
 	if (unlikely(anon_vma_prepare(vma)))
 		return VM_FAULT_OOM;
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 0da6937572cf..de174d049e71 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -446,7 +446,8 @@ void khugepaged_enter_vma(struct vm_area_struct *vma,
 {
 	if (!test_bit(MMF_VM_HUGEPAGE, &vma->vm_mm->flags) &&
 	    hugepage_flags_enabled()) {
-		if (hugepage_vma_check(vma, vm_flags, false, false, true))
+		if (thp_vma_allowable_order(vma, vm_flags, false, false, true,
+					    PMD_ORDER))
 			__khugepaged_enter(vma->vm_mm);
 	}
 }
@@ -922,16 +923,16 @@ static int hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address,
 	if (!vma)
 		return SCAN_VMA_NULL;
 
-	if (!transhuge_vma_suitable(vma, address))
+	if (!thp_vma_suitable_order(vma, address, PMD_ORDER))
 		return SCAN_ADDRESS_RANGE;
-	if (!hugepage_vma_check(vma, vma->vm_flags, false, false,
-				cc->is_khugepaged))
+	if (!thp_vma_allowable_order(vma, vma->vm_flags, false, false,
+				     cc->is_khugepaged, PMD_ORDER))
 		return SCAN_VMA_CHECK;
 	/*
 	 * Anon VMA expected, the address may be unmapped then
 	 * remapped to file after khugepaged reaquired the mmap_lock.
 	 *
-	 * hugepage_vma_check may return true for qualified file
+	 * thp_vma_allowable_order may return true for qualified file
 	 * vmas.
 	 */
 	if (expect_anon && (!(*vmap)->anon_vma || !vma_is_anonymous(*vmap)))
@@ -1506,7 +1507,8 @@ int collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr,
 	 * and map it by a PMD, regardless of sysfs THP settings. As such, let's
 	 * analogously elide sysfs THP settings here.
 	 */
-	if (!hugepage_vma_check(vma, vma->vm_flags, false, false, false))
+	if (!thp_vma_allowable_order(vma, vma->vm_flags, false, false, false,
+				     PMD_ORDER))
 		return SCAN_VMA_CHECK;
 
 	/* Keep pmd pgtable for uffd-wp; see comment in retract_page_tables() */
@@ -2371,7 +2373,8 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
 			progress++;
 			break;
 		}
-		if (!hugepage_vma_check(vma, vma->vm_flags, false, false, true)) {
+		if (!thp_vma_allowable_order(vma, vma->vm_flags, false, false,
+					     true, PMD_ORDER)) {
 skip:
 			progress++;
 			continue;
@@ -2708,7 +2711,8 @@ int madvise_collapse(struct vm_area_struct *vma, struct vm_area_struct **prev,
 
 	*prev = vma;
 
-	if (!hugepage_vma_check(vma, vma->vm_flags, false, false, false))
+	if (!thp_vma_allowable_order(vma, vma->vm_flags, false, false, false,
+				     PMD_ORDER))
 		return -EINVAL;
 
 	cc = kmalloc(sizeof(*cc), GFP_KERNEL);
diff --git a/mm/memory.c b/mm/memory.c
index 99582b188ed2..8ab2d994d997 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4322,7 +4322,7 @@ vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
 	pmd_t entry;
 	vm_fault_t ret = VM_FAULT_FALLBACK;
 
-	if (!transhuge_vma_suitable(vma, haddr))
+	if (!thp_vma_suitable_order(vma, haddr, PMD_ORDER))
 		return ret;
 
 	page = compound_head(page);
@@ -5116,7 +5116,7 @@ static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma,
 		return VM_FAULT_OOM;
 retry_pud:
 	if (pud_none(*vmf.pud) &&
-	    hugepage_vma_check(vma, vm_flags, false, true, true)) {
+	    thp_vma_allowable_order(vma, vm_flags, false, true, true, PUD_ORDER)) {
 		ret = create_huge_pud(&vmf);
 		if (!(ret & VM_FAULT_FALLBACK))
 			return ret;
@@ -5150,7 +5150,7 @@ static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma,
 		goto retry_pud;
 
 	if (pmd_none(*vmf.pmd) &&
-	    hugepage_vma_check(vma, vm_flags, false, true, true)) {
+	    thp_vma_allowable_order(vma, vm_flags, false, true, true, PMD_ORDER)) {
 		ret = create_huge_pmd(&vmf);
 		if (!(ret & VM_FAULT_FALLBACK))
 			return ret;
diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
index e0b368e545ed..74d2de15fb5e 100644
--- a/mm/page_vma_mapped.c
+++ b/mm/page_vma_mapped.c
@@ -268,7 +268,8 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw)
 			 * cleared *pmd but not decremented compound_mapcount().
 			 */
 			if ((pvmw->flags & PVMW_SYNC) &&
-			    transhuge_vma_suitable(vma, pvmw->address) &&
+			    thp_vma_suitable_order(vma, pvmw->address,
+						   PMD_ORDER) &&
 			    (pvmw->nr_pages >= HPAGE_PMD_NR)) {
 				spinlock_t *ptl = pmd_lock(mm, pvmw->pmd);
 
-- 
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:05 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:05 +0000
Subject: [PATCH v9 04/10] mm: thp: Support allocation of anonymous multi-size THP
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-5-ryan.roberts@arm.com>

Introduce the logic to allow THP to be configured (through the new sysfs
interface we just added) to allocate large folios to back anonymous
memory, which are larger than the base page size but smaller than
PMD-size. We call this new THP extension "multi-size THP" (mTHP).

mTHP continues to be PTE-mapped, but in many cases can still provide
similar benefits to traditional PMD-sized THP: Page faults are
significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
the configured order), but latency spikes are much less prominent
because the size of each page isn't as huge as the PMD-sized variant and
there is less memory to clear in each page fault. The number of per-page
operations (e.g. ref counting, rmap management, lru list management) are
also significantly reduced since those ops now become per-folio.

Some architectures also employ TLB compression mechanisms to squeeze
more entries in when a set of PTEs are virtually and physically
contiguous and approporiately aligned. In this case, TLB misses will
occur less often.

The new behaviour is disabled by default, but can be enabled at runtime
by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
(see documentation in previous commit). The long term aim is to change
the default to include suitable lower orders, but there are some risks
around internal fragmentation that need to be better understood first.

Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 include/linux/huge_mm.h |   6 ++-
 mm/memory.c             | 111 ++++++++++++++++++++++++++++++++++++----
 2 files changed, 106 insertions(+), 11 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 609c153bae57..fa7a38a30fc6 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
 #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
 
 /*
- * Mask of all large folio orders supported for anonymous THP.
+ * Mask of all large folio orders supported for anonymous THP; all orders up to
+ * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
+ * (which is a limitation of the THP implementation).
  */
-#define THP_ORDERS_ALL_ANON	BIT(PMD_ORDER)
+#define THP_ORDERS_ALL_ANON	((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
 
 /*
  * Mask of all large folio orders supported for file THP.
diff --git a/mm/memory.c b/mm/memory.c
index 8ab2d994d997..8f0b936b90b5 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4125,6 +4125,87 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
 	return ret;
 }
 
+static bool pte_range_none(pte_t *pte, int nr_pages)
+{
+	int i;
+
+	for (i = 0; i < nr_pages; i++) {
+		if (!pte_none(ptep_get_lockless(pte + i)))
+			return false;
+	}
+
+	return true;
+}
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+static struct folio *alloc_anon_folio(struct vm_fault *vmf)
+{
+	struct vm_area_struct *vma = vmf->vma;
+	unsigned long orders;
+	struct folio *folio;
+	unsigned long addr;
+	pte_t *pte;
+	gfp_t gfp;
+	int order;
+
+	/*
+	 * If uffd is active for the vma we need per-page fault fidelity to
+	 * maintain the uffd semantics.
+	 */
+	if (unlikely(userfaultfd_armed(vma)))
+		goto fallback;
+
+	/*
+	 * Get a list of all the (large) orders below PMD_ORDER that are enabled
+	 * for this vma. Then filter out the orders that can't be allocated over
+	 * the faulting address and still be fully contained in the vma.
+	 */
+	orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
+					  BIT(PMD_ORDER) - 1);
+	orders = thp_vma_suitable_orders(vma, vmf->address, orders);
+
+	if (!orders)
+		goto fallback;
+
+	pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
+	if (!pte)
+		return ERR_PTR(-EAGAIN);
+
+	/*
+	 * Find the highest order where the aligned range is completely
+	 * pte_none(). Note that all remaining orders will be completely
+	 * pte_none().
+	 */
+	order = highest_order(orders);
+	while (orders) {
+		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
+		if (pte_range_none(pte + pte_index(addr), 1 << order))
+			break;
+		order = next_order(&orders, order);
+	}
+
+	pte_unmap(pte);
+
+	/* Try allocating the highest of the remaining orders. */
+	gfp = vma_thp_gfp_mask(vma);
+	while (orders) {
+		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
+		folio = vma_alloc_folio(gfp, order, vma, addr, true);
+		if (folio) {
+			clear_huge_page(&folio->page, vmf->address, 1 << order);
+			return folio;
+		}
+		order = next_order(&orders, order);
+	}
+
+fallback:
+	return vma_alloc_zeroed_movable_folio(vma, vmf->address);
+}
+#else
+#define alloc_anon_folio(vmf) \
+		vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
+#endif
+
 /*
  * We enter with non-exclusive mmap_lock (to exclude vma changes,
  * but allow concurrent faults), and pte mapped but not yet locked.
@@ -4134,9 +4215,12 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 {
 	bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
 	struct vm_area_struct *vma = vmf->vma;
+	unsigned long addr = vmf->address;
 	struct folio *folio;
 	vm_fault_t ret = 0;
+	int nr_pages = 1;
 	pte_t entry;
+	int i;
 
 	/* File mapping without ->vm_ops ? */
 	if (vma->vm_flags & VM_SHARED)
@@ -4176,10 +4260,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 	/* Allocate our own private page. */
 	if (unlikely(anon_vma_prepare(vma)))
 		goto oom;
-	folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
+	folio = alloc_anon_folio(vmf);
+	if (IS_ERR(folio))
+		return 0;
 	if (!folio)
 		goto oom;
 
+	nr_pages = folio_nr_pages(folio);
+	addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
+
 	if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
 		goto oom_free_page;
 	folio_throttle_swaprate(folio, GFP_KERNEL);
@@ -4196,12 +4285,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 	if (vma->vm_flags & VM_WRITE)
 		entry = pte_mkwrite(pte_mkdirty(entry), vma);
 
-	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
-			&vmf->ptl);
+	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
 	if (!vmf->pte)
 		goto release;
-	if (vmf_pte_changed(vmf)) {
-		update_mmu_tlb(vma, vmf->address, vmf->pte);
+	if (nr_pages == 1 && vmf_pte_changed(vmf)) {
+		update_mmu_tlb(vma, addr, vmf->pte);
+		goto release;
+	} else if (nr_pages > 1 && !pte_range_none(vmf->pte, nr_pages)) {
+		for (i = 0; i < nr_pages; i++)
+			update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i);
 		goto release;
 	}
 
@@ -4216,16 +4308,17 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 		return handle_userfault(vmf, VM_UFFD_MISSING);
 	}
 
-	inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
-	folio_add_new_anon_rmap(folio, vma, vmf->address);
+	folio_ref_add(folio, nr_pages - 1);
+	add_mm_counter(vma->vm_mm, MM_ANONPAGES, nr_pages);
+	folio_add_new_anon_rmap(folio, vma, addr);
 	folio_add_lru_vma(folio, vma);
 setpte:
 	if (uffd_wp)
 		entry = pte_mkuffd_wp(entry);
-	set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
+	set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
 
 	/* No need to invalidate - it was non-present before */
-	update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
+	update_mmu_cache_range(vmf, vma, addr, vmf->pte, nr_pages);
 unlock:
 	if (vmf->pte)
 		pte_unmap_unlock(vmf->pte, vmf->ptl);
-- 
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:06 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:06 +0000
Subject: [PATCH v9 05/10] selftests/mm/kugepaged: Restore thp settings at exit
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-6-ryan.roberts@arm.com>

Previously, the saved thp settings would be restored upon a signal or at
the natural end of the test suite. But there are some tests that
directly call exit() upon failure. In this case, the thp settings were
not being restored, which could then influence other tests.

Fix this by installing an atexit() handler to do the actual restore. The
signal handler can now just call exit() and the atexit handler is
invoked.

Reviewed-by: Alistair Popple <apopple at nvidia.com>
Reviewed-by: David Hildenbrand <david at redhat.com>
Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/khugepaged.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
index 030667cb5533..fc47a1c4944c 100644
--- a/tools/testing/selftests/mm/khugepaged.c
+++ b/tools/testing/selftests/mm/khugepaged.c
@@ -374,18 +374,22 @@ static void pop_settings(void)
 	write_settings(current_settings());
 }
 
-static void restore_settings(int sig)
+static void restore_settings_atexit(void)
 {
 	if (skip_settings_restore)
-		goto out;
+		return;
 
 	printf("Restore THP and khugepaged settings...");
 	write_settings(&saved_settings);
 	success("OK");
-	if (sig)
-		exit(EXIT_FAILURE);
-out:
-	exit(exit_status);
+
+	skip_settings_restore = true;
+}
+
+static void restore_settings(int sig)
+{
+	/* exit() will invoke the restore_settings_atexit handler. */
+	exit(sig ? EXIT_FAILURE : exit_status);
 }
 
 static void save_settings(void)
@@ -415,6 +419,7 @@ static void save_settings(void)
 
 	success("OK");
 
+	atexit(restore_settings_atexit);
 	signal(SIGTERM, restore_settings);
 	signal(SIGINT, restore_settings);
 	signal(SIGHUP, restore_settings);
-- 
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:07 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:07 +0000
Subject: [PATCH v9 06/10] selftests/mm: Factor out thp settings management
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-7-ryan.roberts@arm.com>

The khugepaged test has a useful framework for save/restore/pop/push of
all thp settings via the sysfs interface. This will be useful to
explicitly control multi-size THP settings in other tests, so let's
move it out of khugepaged and into its own thp_settings.[c|h] utility.

Tested-by: Alistair Popple <apopple at nvidia.com>
Acked-by: David Hildenbrand <david at redhat.com>
Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/Makefile       |   4 +-
 tools/testing/selftests/mm/khugepaged.c   | 346 ++--------------------
 tools/testing/selftests/mm/thp_settings.c | 296 ++++++++++++++++++
 tools/testing/selftests/mm/thp_settings.h |  71 +++++
 4 files changed, 391 insertions(+), 326 deletions(-)
 create mode 100644 tools/testing/selftests/mm/thp_settings.c
 create mode 100644 tools/testing/selftests/mm/thp_settings.h

diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile
index dede0bcf97a3..2453add65d12 100644
--- a/tools/testing/selftests/mm/Makefile
+++ b/tools/testing/selftests/mm/Makefile
@@ -117,8 +117,8 @@ TEST_FILES += va_high_addr_switch.sh
 
 include ../lib.mk
 
-$(TEST_GEN_PROGS): vm_util.c
-$(TEST_GEN_FILES): vm_util.c
+$(TEST_GEN_PROGS): vm_util.c thp_settings.c
+$(TEST_GEN_FILES): vm_util.c thp_settings.c
 
 $(OUTPUT)/uffd-stress: uffd-common.c
 $(OUTPUT)/uffd-unit-tests: uffd-common.c
diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
index fc47a1c4944c..b15e7fd70176 100644
--- a/tools/testing/selftests/mm/khugepaged.c
+++ b/tools/testing/selftests/mm/khugepaged.c
@@ -22,13 +22,13 @@
 #include "linux/magic.h"
 
 #include "vm_util.h"
+#include "thp_settings.h"
 
 #define BASE_ADDR ((void *)(1UL << 30))
 static unsigned long hpage_pmd_size;
 static unsigned long page_size;
 static int hpage_pmd_nr;
 
-#define THP_SYSFS "/sys/kernel/mm/transparent_hugepage/"
 #define PID_SMAPS "/proc/self/smaps"
 #define TEST_FILE "collapse_test_file"
 
@@ -71,78 +71,7 @@ struct file_info {
 };
 
 static struct file_info finfo;
-
-enum thp_enabled {
-	THP_ALWAYS,
-	THP_MADVISE,
-	THP_NEVER,
-};
-
-static const char *thp_enabled_strings[] = {
-	"always",
-	"madvise",
-	"never",
-	NULL
-};
-
-enum thp_defrag {
-	THP_DEFRAG_ALWAYS,
-	THP_DEFRAG_DEFER,
-	THP_DEFRAG_DEFER_MADVISE,
-	THP_DEFRAG_MADVISE,
-	THP_DEFRAG_NEVER,
-};
-
-static const char *thp_defrag_strings[] = {
-	"always",
-	"defer",
-	"defer+madvise",
-	"madvise",
-	"never",
-	NULL
-};
-
-enum shmem_enabled {
-	SHMEM_ALWAYS,
-	SHMEM_WITHIN_SIZE,
-	SHMEM_ADVISE,
-	SHMEM_NEVER,
-	SHMEM_DENY,
-	SHMEM_FORCE,
-};
-
-static const char *shmem_enabled_strings[] = {
-	"always",
-	"within_size",
-	"advise",
-	"never",
-	"deny",
-	"force",
-	NULL
-};
-
-struct khugepaged_settings {
-	bool defrag;
-	unsigned int alloc_sleep_millisecs;
-	unsigned int scan_sleep_millisecs;
-	unsigned int max_ptes_none;
-	unsigned int max_ptes_swap;
-	unsigned int max_ptes_shared;
-	unsigned long pages_to_scan;
-};
-
-struct settings {
-	enum thp_enabled thp_enabled;
-	enum thp_defrag thp_defrag;
-	enum shmem_enabled shmem_enabled;
-	bool use_zero_page;
-	struct khugepaged_settings khugepaged;
-	unsigned long read_ahead_kb;
-};
-
-static struct settings saved_settings;
 static bool skip_settings_restore;
-
 static int exit_status;
 
 static void success(const char *msg)
@@ -161,226 +90,13 @@ static void skip(const char *msg)
 	printf(" \e[33m%s\e[0m\n", msg);
 }
 
-static int read_file(const char *path, char *buf, size_t buflen)
-{
-	int fd;
-	ssize_t numread;
-
-	fd = open(path, O_RDONLY);
-	if (fd == -1)
-		return 0;
-
-	numread = read(fd, buf, buflen - 1);
-	if (numread < 1) {
-		close(fd);
-		return 0;
-	}
-
-	buf[numread] = '\0';
-	close(fd);
-
-	return (unsigned int) numread;
-}
-
-static int write_file(const char *path, const char *buf, size_t buflen)
-{
-	int fd;
-	ssize_t numwritten;
-
-	fd = open(path, O_WRONLY);
-	if (fd == -1) {
-		printf("open(%s)\n", path);
-		exit(EXIT_FAILURE);
-		return 0;
-	}
-
-	numwritten = write(fd, buf, buflen - 1);
-	close(fd);
-	if (numwritten < 1) {
-		printf("write(%s)\n", buf);
-		exit(EXIT_FAILURE);
-		return 0;
-	}
-
-	return (unsigned int) numwritten;
-}
-
-static int read_string(const char *name, const char *strings[])
-{
-	char path[PATH_MAX];
-	char buf[256];
-	char *c;
-	int ret;
-
-	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
-	if (ret >= PATH_MAX) {
-		printf("%s: Pathname is too long\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-
-	if (!read_file(path, buf, sizeof(buf))) {
-		perror(path);
-		exit(EXIT_FAILURE);
-	}
-
-	c = strchr(buf, '[');
-	if (!c) {
-		printf("%s: Parse failure\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-
-	c++;
-	memmove(buf, c, sizeof(buf) - (c - buf));
-
-	c = strchr(buf, ']');
-	if (!c) {
-		printf("%s: Parse failure\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-	*c = '\0';
-
-	ret = 0;
-	while (strings[ret]) {
-		if (!strcmp(strings[ret], buf))
-			return ret;
-		ret++;
-	}
-
-	printf("Failed to parse %s\n", name);
-	exit(EXIT_FAILURE);
-}
-
-static void write_string(const char *name, const char *val)
-{
-	char path[PATH_MAX];
-	int ret;
-
-	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
-	if (ret >= PATH_MAX) {
-		printf("%s: Pathname is too long\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-
-	if (!write_file(path, val, strlen(val) + 1)) {
-		perror(path);
-		exit(EXIT_FAILURE);
-	}
-}
-
-static const unsigned long _read_num(const char *path)
-{
-	char buf[21];
-
-	if (read_file(path, buf, sizeof(buf)) < 0) {
-		perror("read_file(read_num)");
-		exit(EXIT_FAILURE);
-	}
-
-	return strtoul(buf, NULL, 10);
-}
-
-static const unsigned long read_num(const char *name)
-{
-	char path[PATH_MAX];
-	int ret;
-
-	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
-	if (ret >= PATH_MAX) {
-		printf("%s: Pathname is too long\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-	return _read_num(path);
-}
-
-static void _write_num(const char *path, unsigned long num)
-{
-	char buf[21];
-
-	sprintf(buf, "%ld", num);
-	if (!write_file(path, buf, strlen(buf) + 1)) {
-		perror(path);
-		exit(EXIT_FAILURE);
-	}
-}
-
-static void write_num(const char *name, unsigned long num)
-{
-	char path[PATH_MAX];
-	int ret;
-
-	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
-	if (ret >= PATH_MAX) {
-		printf("%s: Pathname is too long\n", __func__);
-		exit(EXIT_FAILURE);
-	}
-	_write_num(path, num);
-}
-
-static void write_settings(struct settings *settings)
-{
-	struct khugepaged_settings *khugepaged = &settings->khugepaged;
-
-	write_string("enabled", thp_enabled_strings[settings->thp_enabled]);
-	write_string("defrag", thp_defrag_strings[settings->thp_defrag]);
-	write_string("shmem_enabled",
-			shmem_enabled_strings[settings->shmem_enabled]);
-	write_num("use_zero_page", settings->use_zero_page);
-
-	write_num("khugepaged/defrag", khugepaged->defrag);
-	write_num("khugepaged/alloc_sleep_millisecs",
-			khugepaged->alloc_sleep_millisecs);
-	write_num("khugepaged/scan_sleep_millisecs",
-			khugepaged->scan_sleep_millisecs);
-	write_num("khugepaged/max_ptes_none", khugepaged->max_ptes_none);
-	write_num("khugepaged/max_ptes_swap", khugepaged->max_ptes_swap);
-	write_num("khugepaged/max_ptes_shared", khugepaged->max_ptes_shared);
-	write_num("khugepaged/pages_to_scan", khugepaged->pages_to_scan);
-
-	if (file_ops && finfo.type == VMA_FILE)
-		_write_num(finfo.dev_queue_read_ahead_path,
-			   settings->read_ahead_kb);
-}
-
-#define MAX_SETTINGS_DEPTH 4
-static struct settings settings_stack[MAX_SETTINGS_DEPTH];
-static int settings_index;
-
-static struct settings *current_settings(void)
-{
-	if (!settings_index) {
-		printf("Fail: No settings set");
-		exit(EXIT_FAILURE);
-	}
-	return settings_stack + settings_index - 1;
-}
-
-static void push_settings(struct settings *settings)
-{
-	if (settings_index >= MAX_SETTINGS_DEPTH) {
-		printf("Fail: Settings stack exceeded");
-		exit(EXIT_FAILURE);
-	}
-	settings_stack[settings_index++] = *settings;
-	write_settings(current_settings());
-}
-
-static void pop_settings(void)
-{
-	if (settings_index <= 0) {
-		printf("Fail: Settings stack empty");
-		exit(EXIT_FAILURE);
-	}
-	--settings_index;
-	write_settings(current_settings());
-}
-
 static void restore_settings_atexit(void)
 {
 	if (skip_settings_restore)
 		return;
 
 	printf("Restore THP and khugepaged settings...");
-	write_settings(&saved_settings);
+	thp_restore_settings();
 	success("OK");
 
 	skip_settings_restore = true;
@@ -395,27 +111,9 @@ static void restore_settings(int sig)
 static void save_settings(void)
 {
 	printf("Save THP and khugepaged settings...");
-	saved_settings = (struct settings) {
-		.thp_enabled = read_string("enabled", thp_enabled_strings),
-		.thp_defrag = read_string("defrag", thp_defrag_strings),
-		.shmem_enabled =
-			read_string("shmem_enabled", shmem_enabled_strings),
-		.use_zero_page = read_num("use_zero_page"),
-	};
-	saved_settings.khugepaged = (struct khugepaged_settings) {
-		.defrag = read_num("khugepaged/defrag"),
-		.alloc_sleep_millisecs =
-			read_num("khugepaged/alloc_sleep_millisecs"),
-		.scan_sleep_millisecs =
-			read_num("khugepaged/scan_sleep_millisecs"),
-		.max_ptes_none = read_num("khugepaged/max_ptes_none"),
-		.max_ptes_swap = read_num("khugepaged/max_ptes_swap"),
-		.max_ptes_shared = read_num("khugepaged/max_ptes_shared"),
-		.pages_to_scan = read_num("khugepaged/pages_to_scan"),
-	};
 	if (file_ops && finfo.type == VMA_FILE)
-		saved_settings.read_ahead_kb =
-				_read_num(finfo.dev_queue_read_ahead_path);
+		thp_set_read_ahead_path(finfo.dev_queue_read_ahead_path);
+	thp_save_settings();
 
 	success("OK");
 
@@ -798,7 +496,7 @@ static void __madvise_collapse(const char *msg, char *p, int nr_hpages,
 			       struct mem_ops *ops, bool expect)
 {
 	int ret;
-	struct settings settings = *current_settings();
+	struct thp_settings settings = *thp_current_settings();
 
 	printf("%s...", msg);
 
@@ -808,7 +506,7 @@ static void __madvise_collapse(const char *msg, char *p, int nr_hpages,
 	 */
 	settings.thp_enabled = THP_NEVER;
 	settings.shmem_enabled = SHMEM_NEVER;
-	push_settings(&settings);
+	thp_push_settings(&settings);
 
 	/* Clear VM_NOHUGEPAGE */
 	madvise(p, nr_hpages * hpage_pmd_size, MADV_HUGEPAGE);
@@ -820,7 +518,7 @@ static void __madvise_collapse(const char *msg, char *p, int nr_hpages,
 	else
 		success("OK");
 
-	pop_settings();
+	thp_pop_settings();
 }
 
 static void madvise_collapse(const char *msg, char *p, int nr_hpages,
@@ -850,13 +548,13 @@ static bool wait_for_scan(const char *msg, char *p, int nr_hpages,
 	madvise(p, nr_hpages * hpage_pmd_size, MADV_HUGEPAGE);
 
 	/* Wait until the second full_scan completed */
-	full_scans = read_num("khugepaged/full_scans") + 2;
+	full_scans = thp_read_num("khugepaged/full_scans") + 2;
 
 	printf("%s...", msg);
 	while (timeout--) {
 		if (ops->check_huge(p, nr_hpages))
 			break;
-		if (read_num("khugepaged/full_scans") >= full_scans)
+		if (thp_read_num("khugepaged/full_scans") >= full_scans)
 			break;
 		printf(".");
 		usleep(TICK);
@@ -911,11 +609,11 @@ static bool is_tmpfs(struct mem_ops *ops)
 
 static void alloc_at_fault(void)
 {
-	struct settings settings = *current_settings();
+	struct thp_settings settings = *thp_current_settings();
 	char *p;
 
 	settings.thp_enabled = THP_ALWAYS;
-	push_settings(&settings);
+	thp_push_settings(&settings);
 
 	p = alloc_mapping(1);
 	*p = 1;
@@ -925,7 +623,7 @@ static void alloc_at_fault(void)
 	else
 		fail("Fail");
 
-	pop_settings();
+	thp_pop_settings();
 
 	madvise(p, page_size, MADV_DONTNEED);
 	printf("Split huge PMD on MADV_DONTNEED...");
@@ -973,11 +671,11 @@ static void collapse_single_pte_entry(struct collapse_context *c, struct mem_ops
 static void collapse_max_ptes_none(struct collapse_context *c, struct mem_ops *ops)
 {
 	int max_ptes_none = hpage_pmd_nr / 2;
-	struct settings settings = *current_settings();
+	struct thp_settings settings = *thp_current_settings();
 	void *p;
 
 	settings.khugepaged.max_ptes_none = max_ptes_none;
-	push_settings(&settings);
+	thp_push_settings(&settings);
 
 	p = ops->setup_area(1);
 
@@ -1002,7 +700,7 @@ static void collapse_max_ptes_none(struct collapse_context *c, struct mem_ops *o
 	}
 skip:
 	ops->cleanup_area(p, hpage_pmd_size);
-	pop_settings();
+	thp_pop_settings();
 }
 
 static void collapse_swapin_single_pte(struct collapse_context *c, struct mem_ops *ops)
@@ -1033,7 +731,7 @@ static void collapse_swapin_single_pte(struct collapse_context *c, struct mem_op
 
 static void collapse_max_ptes_swap(struct collapse_context *c, struct mem_ops *ops)
 {
-	int max_ptes_swap = read_num("khugepaged/max_ptes_swap");
+	int max_ptes_swap = thp_read_num("khugepaged/max_ptes_swap");
 	void *p;
 
 	p = ops->setup_area(1);
@@ -1250,11 +948,11 @@ static void collapse_fork_compound(struct collapse_context *c, struct mem_ops *o
 			fail("Fail");
 		ops->fault(p, 0, page_size);
 
-		write_num("khugepaged/max_ptes_shared", hpage_pmd_nr - 1);
+		thp_write_num("khugepaged/max_ptes_shared", hpage_pmd_nr - 1);
 		c->collapse("Collapse PTE table full of compound pages in child",
 			    p, 1, ops, true);
-		write_num("khugepaged/max_ptes_shared",
-			  current_settings()->khugepaged.max_ptes_shared);
+		thp_write_num("khugepaged/max_ptes_shared",
+			  thp_current_settings()->khugepaged.max_ptes_shared);
 
 		validate_memory(p, 0, hpage_pmd_size);
 		ops->cleanup_area(p, hpage_pmd_size);
@@ -1275,7 +973,7 @@ static void collapse_fork_compound(struct collapse_context *c, struct mem_ops *o
 
 static void collapse_max_ptes_shared(struct collapse_context *c, struct mem_ops *ops)
 {
-	int max_ptes_shared = read_num("khugepaged/max_ptes_shared");
+	int max_ptes_shared = thp_read_num("khugepaged/max_ptes_shared");
 	int wstatus;
 	void *p;
 
@@ -1443,7 +1141,7 @@ static void parse_test_type(int argc, const char **argv)
 
 int main(int argc, const char **argv)
 {
-	struct settings default_settings = {
+	struct thp_settings default_settings = {
 		.thp_enabled = THP_MADVISE,
 		.thp_defrag = THP_DEFRAG_ALWAYS,
 		.shmem_enabled = SHMEM_ADVISE,
@@ -1484,7 +1182,7 @@ int main(int argc, const char **argv)
 	default_settings.khugepaged.pages_to_scan = hpage_pmd_nr * 8;
 
 	save_settings();
-	push_settings(&default_settings);
+	thp_push_settings(&default_settings);
 
 	alloc_at_fault();
 
diff --git a/tools/testing/selftests/mm/thp_settings.c b/tools/testing/selftests/mm/thp_settings.c
new file mode 100644
index 000000000000..5e8ec792cac7
--- /dev/null
+++ b/tools/testing/selftests/mm/thp_settings.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <fcntl.h>
+#include <limits.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#include "thp_settings.h"
+
+#define THP_SYSFS "/sys/kernel/mm/transparent_hugepage/"
+#define MAX_SETTINGS_DEPTH 4
+static struct thp_settings settings_stack[MAX_SETTINGS_DEPTH];
+static int settings_index;
+static struct thp_settings saved_settings;
+static char dev_queue_read_ahead_path[PATH_MAX];
+
+static const char * const thp_enabled_strings[] = {
+	"always",
+	"madvise",
+	"never",
+	NULL
+};
+
+static const char * const thp_defrag_strings[] = {
+	"always",
+	"defer",
+	"defer+madvise",
+	"madvise",
+	"never",
+	NULL
+};
+
+static const char * const shmem_enabled_strings[] = {
+	"always",
+	"within_size",
+	"advise",
+	"never",
+	"deny",
+	"force",
+	NULL
+};
+
+int read_file(const char *path, char *buf, size_t buflen)
+{
+	int fd;
+	ssize_t numread;
+
+	fd = open(path, O_RDONLY);
+	if (fd == -1)
+		return 0;
+
+	numread = read(fd, buf, buflen - 1);
+	if (numread < 1) {
+		close(fd);
+		return 0;
+	}
+
+	buf[numread] = '\0';
+	close(fd);
+
+	return (unsigned int) numread;
+}
+
+int write_file(const char *path, const char *buf, size_t buflen)
+{
+	int fd;
+	ssize_t numwritten;
+
+	fd = open(path, O_WRONLY);
+	if (fd == -1) {
+		printf("open(%s)\n", path);
+		exit(EXIT_FAILURE);
+		return 0;
+	}
+
+	numwritten = write(fd, buf, buflen - 1);
+	close(fd);
+	if (numwritten < 1) {
+		printf("write(%s)\n", buf);
+		exit(EXIT_FAILURE);
+		return 0;
+	}
+
+	return (unsigned int) numwritten;
+}
+
+const unsigned long read_num(const char *path)
+{
+	char buf[21];
+
+	if (read_file(path, buf, sizeof(buf)) < 0) {
+		perror("read_file()");
+		exit(EXIT_FAILURE);
+	}
+
+	return strtoul(buf, NULL, 10);
+}
+
+void write_num(const char *path, unsigned long num)
+{
+	char buf[21];
+
+	sprintf(buf, "%ld", num);
+	if (!write_file(path, buf, strlen(buf) + 1)) {
+		perror(path);
+		exit(EXIT_FAILURE);
+	}
+}
+
+int thp_read_string(const char *name, const char * const strings[])
+{
+	char path[PATH_MAX];
+	char buf[256];
+	char *c;
+	int ret;
+
+	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
+	if (ret >= PATH_MAX) {
+		printf("%s: Pathname is too long\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+
+	if (!read_file(path, buf, sizeof(buf))) {
+		perror(path);
+		exit(EXIT_FAILURE);
+	}
+
+	c = strchr(buf, '[');
+	if (!c) {
+		printf("%s: Parse failure\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+
+	c++;
+	memmove(buf, c, sizeof(buf) - (c - buf));
+
+	c = strchr(buf, ']');
+	if (!c) {
+		printf("%s: Parse failure\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+	*c = '\0';
+
+	ret = 0;
+	while (strings[ret]) {
+		if (!strcmp(strings[ret], buf))
+			return ret;
+		ret++;
+	}
+
+	printf("Failed to parse %s\n", name);
+	exit(EXIT_FAILURE);
+}
+
+void thp_write_string(const char *name, const char *val)
+{
+	char path[PATH_MAX];
+	int ret;
+
+	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
+	if (ret >= PATH_MAX) {
+		printf("%s: Pathname is too long\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+
+	if (!write_file(path, val, strlen(val) + 1)) {
+		perror(path);
+		exit(EXIT_FAILURE);
+	}
+}
+
+const unsigned long thp_read_num(const char *name)
+{
+	char path[PATH_MAX];
+	int ret;
+
+	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
+	if (ret >= PATH_MAX) {
+		printf("%s: Pathname is too long\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+	return read_num(path);
+}
+
+void thp_write_num(const char *name, unsigned long num)
+{
+	char path[PATH_MAX];
+	int ret;
+
+	ret = snprintf(path, PATH_MAX, THP_SYSFS "%s", name);
+	if (ret >= PATH_MAX) {
+		printf("%s: Pathname is too long\n", __func__);
+		exit(EXIT_FAILURE);
+	}
+	write_num(path, num);
+}
+
+void thp_read_settings(struct thp_settings *settings)
+{
+	*settings = (struct thp_settings) {
+		.thp_enabled = thp_read_string("enabled", thp_enabled_strings),
+		.thp_defrag = thp_read_string("defrag", thp_defrag_strings),
+		.shmem_enabled =
+			thp_read_string("shmem_enabled", shmem_enabled_strings),
+		.use_zero_page = thp_read_num("use_zero_page"),
+	};
+	settings->khugepaged = (struct khugepaged_settings) {
+		.defrag = thp_read_num("khugepaged/defrag"),
+		.alloc_sleep_millisecs =
+			thp_read_num("khugepaged/alloc_sleep_millisecs"),
+		.scan_sleep_millisecs =
+			thp_read_num("khugepaged/scan_sleep_millisecs"),
+		.max_ptes_none = thp_read_num("khugepaged/max_ptes_none"),
+		.max_ptes_swap = thp_read_num("khugepaged/max_ptes_swap"),
+		.max_ptes_shared = thp_read_num("khugepaged/max_ptes_shared"),
+		.pages_to_scan = thp_read_num("khugepaged/pages_to_scan"),
+	};
+	if (dev_queue_read_ahead_path[0])
+		settings->read_ahead_kb = read_num(dev_queue_read_ahead_path);
+}
+
+void thp_write_settings(struct thp_settings *settings)
+{
+	struct khugepaged_settings *khugepaged = &settings->khugepaged;
+
+	thp_write_string("enabled", thp_enabled_strings[settings->thp_enabled]);
+	thp_write_string("defrag", thp_defrag_strings[settings->thp_defrag]);
+	thp_write_string("shmem_enabled",
+			shmem_enabled_strings[settings->shmem_enabled]);
+	thp_write_num("use_zero_page", settings->use_zero_page);
+
+	thp_write_num("khugepaged/defrag", khugepaged->defrag);
+	thp_write_num("khugepaged/alloc_sleep_millisecs",
+			khugepaged->alloc_sleep_millisecs);
+	thp_write_num("khugepaged/scan_sleep_millisecs",
+			khugepaged->scan_sleep_millisecs);
+	thp_write_num("khugepaged/max_ptes_none", khugepaged->max_ptes_none);
+	thp_write_num("khugepaged/max_ptes_swap", khugepaged->max_ptes_swap);
+	thp_write_num("khugepaged/max_ptes_shared", khugepaged->max_ptes_shared);
+	thp_write_num("khugepaged/pages_to_scan", khugepaged->pages_to_scan);
+
+	if (dev_queue_read_ahead_path[0])
+		write_num(dev_queue_read_ahead_path, settings->read_ahead_kb);
+}
+
+struct thp_settings *thp_current_settings(void)
+{
+	if (!settings_index) {
+		printf("Fail: No settings set");
+		exit(EXIT_FAILURE);
+	}
+	return settings_stack + settings_index - 1;
+}
+
+void thp_push_settings(struct thp_settings *settings)
+{
+	if (settings_index >= MAX_SETTINGS_DEPTH) {
+		printf("Fail: Settings stack exceeded");
+		exit(EXIT_FAILURE);
+	}
+	settings_stack[settings_index++] = *settings;
+	thp_write_settings(thp_current_settings());
+}
+
+void thp_pop_settings(void)
+{
+	if (settings_index <= 0) {
+		printf("Fail: Settings stack empty");
+		exit(EXIT_FAILURE);
+	}
+	--settings_index;
+	thp_write_settings(thp_current_settings());
+}
+
+void thp_restore_settings(void)
+{
+	thp_write_settings(&saved_settings);
+}
+
+void thp_save_settings(void)
+{
+	thp_read_settings(&saved_settings);
+}
+
+void thp_set_read_ahead_path(char *path)
+{
+	if (!path) {
+		dev_queue_read_ahead_path[0] = '\0';
+		return;
+	}
+
+	strncpy(dev_queue_read_ahead_path, path,
+		sizeof(dev_queue_read_ahead_path));
+	dev_queue_read_ahead_path[sizeof(dev_queue_read_ahead_path) - 1] = '\0';
+}
diff --git a/tools/testing/selftests/mm/thp_settings.h b/tools/testing/selftests/mm/thp_settings.h
new file mode 100644
index 000000000000..ff3d98c30617
--- /dev/null
+++ b/tools/testing/selftests/mm/thp_settings.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __THP_SETTINGS_H__
+#define __THP_SETTINGS_H__
+
+#include <stdbool.h>
+#include <stddef.h>
+#include <stdint.h>
+
+enum thp_enabled {
+	THP_ALWAYS,
+	THP_MADVISE,
+	THP_NEVER,
+};
+
+enum thp_defrag {
+	THP_DEFRAG_ALWAYS,
+	THP_DEFRAG_DEFER,
+	THP_DEFRAG_DEFER_MADVISE,
+	THP_DEFRAG_MADVISE,
+	THP_DEFRAG_NEVER,
+};
+
+enum shmem_enabled {
+	SHMEM_ALWAYS,
+	SHMEM_WITHIN_SIZE,
+	SHMEM_ADVISE,
+	SHMEM_NEVER,
+	SHMEM_DENY,
+	SHMEM_FORCE,
+};
+
+struct khugepaged_settings {
+	bool defrag;
+	unsigned int alloc_sleep_millisecs;
+	unsigned int scan_sleep_millisecs;
+	unsigned int max_ptes_none;
+	unsigned int max_ptes_swap;
+	unsigned int max_ptes_shared;
+	unsigned long pages_to_scan;
+};
+
+struct thp_settings {
+	enum thp_enabled thp_enabled;
+	enum thp_defrag thp_defrag;
+	enum shmem_enabled shmem_enabled;
+	bool use_zero_page;
+	struct khugepaged_settings khugepaged;
+	unsigned long read_ahead_kb;
+};
+
+int read_file(const char *path, char *buf, size_t buflen);
+int write_file(const char *path, const char *buf, size_t buflen);
+const unsigned long read_num(const char *path);
+void write_num(const char *path, unsigned long num);
+
+int thp_read_string(const char *name, const char * const strings[]);
+void thp_write_string(const char *name, const char *val);
+const unsigned long thp_read_num(const char *name);
+void thp_write_num(const char *name, unsigned long num);
+
+void thp_write_settings(struct thp_settings *settings);
+void thp_read_settings(struct thp_settings *settings);
+struct thp_settings *thp_current_settings(void);
+void thp_push_settings(struct thp_settings *settings);
+void thp_pop_settings(void);
+void thp_restore_settings(void);
+void thp_save_settings(void);
+
+void thp_set_read_ahead_path(char *path);
+
+#endif /* __THP_SETTINGS_H__ */
-- 
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:08 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:08 +0000
Subject: [PATCH v9 07/10] selftests/mm: Support multi-size THP interface in thp_settings
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-8-ryan.roberts@arm.com>

Save and restore the new per-size hugepage enabled setting, if available
on the running kernel.

Since the number of per-size directories is not fixed, solve this as
simply as possible by catering for a maximum number in the thp_settings
struct (20). Each array index is the order. The value of THP_NEVER is
changed to 0 so that all of these new settings default to THP_NEVER and
the user only needs to fill in the ones they want to enable.

Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/khugepaged.c   |  3 ++
 tools/testing/selftests/mm/thp_settings.c | 55 ++++++++++++++++++++++-
 tools/testing/selftests/mm/thp_settings.h | 11 ++++-
 3 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
index b15e7fd70176..7bd3baa9d34b 100644
--- a/tools/testing/selftests/mm/khugepaged.c
+++ b/tools/testing/selftests/mm/khugepaged.c
@@ -1141,6 +1141,7 @@ static void parse_test_type(int argc, const char **argv)
 
 int main(int argc, const char **argv)
 {
+	int hpage_pmd_order;
 	struct thp_settings default_settings = {
 		.thp_enabled = THP_MADVISE,
 		.thp_defrag = THP_DEFRAG_ALWAYS,
@@ -1175,11 +1176,13 @@ int main(int argc, const char **argv)
 		exit(EXIT_FAILURE);
 	}
 	hpage_pmd_nr = hpage_pmd_size / page_size;
+	hpage_pmd_order = __builtin_ctz(hpage_pmd_nr);
 
 	default_settings.khugepaged.max_ptes_none = hpage_pmd_nr - 1;
 	default_settings.khugepaged.max_ptes_swap = hpage_pmd_nr / 8;
 	default_settings.khugepaged.max_ptes_shared = hpage_pmd_nr / 2;
 	default_settings.khugepaged.pages_to_scan = hpage_pmd_nr * 8;
+	default_settings.hugepages[hpage_pmd_order].enabled = THP_INHERIT;
 
 	save_settings();
 	thp_push_settings(&default_settings);
diff --git a/tools/testing/selftests/mm/thp_settings.c b/tools/testing/selftests/mm/thp_settings.c
index 5e8ec792cac7..a4163438108e 100644
--- a/tools/testing/selftests/mm/thp_settings.c
+++ b/tools/testing/selftests/mm/thp_settings.c
@@ -16,9 +16,10 @@ static struct thp_settings saved_settings;
 static char dev_queue_read_ahead_path[PATH_MAX];
 
 static const char * const thp_enabled_strings[] = {
+	"never",
 	"always",
+	"inherit",
 	"madvise",
-	"never",
 	NULL
 };
 
@@ -198,6 +199,10 @@ void thp_write_num(const char *name, unsigned long num)
 
 void thp_read_settings(struct thp_settings *settings)
 {
+	unsigned long orders = thp_supported_orders();
+	char path[PATH_MAX];
+	int i;
+
 	*settings = (struct thp_settings) {
 		.thp_enabled = thp_read_string("enabled", thp_enabled_strings),
 		.thp_defrag = thp_read_string("defrag", thp_defrag_strings),
@@ -218,11 +223,26 @@ void thp_read_settings(struct thp_settings *settings)
 	};
 	if (dev_queue_read_ahead_path[0])
 		settings->read_ahead_kb = read_num(dev_queue_read_ahead_path);
+
+	for (i = 0; i < NR_ORDERS; i++) {
+		if (!((1 << i) & orders)) {
+			settings->hugepages[i].enabled = THP_NEVER;
+			continue;
+		}
+		snprintf(path, PATH_MAX, "hugepages-%ukB/enabled",
+			(getpagesize() >> 10) << i);
+		settings->hugepages[i].enabled =
+			thp_read_string(path, thp_enabled_strings);
+	}
 }
 
 void thp_write_settings(struct thp_settings *settings)
 {
 	struct khugepaged_settings *khugepaged = &settings->khugepaged;
+	unsigned long orders = thp_supported_orders();
+	char path[PATH_MAX];
+	int enabled;
+	int i;
 
 	thp_write_string("enabled", thp_enabled_strings[settings->thp_enabled]);
 	thp_write_string("defrag", thp_defrag_strings[settings->thp_defrag]);
@@ -242,6 +262,15 @@ void thp_write_settings(struct thp_settings *settings)
 
 	if (dev_queue_read_ahead_path[0])
 		write_num(dev_queue_read_ahead_path, settings->read_ahead_kb);
+
+	for (i = 0; i < NR_ORDERS; i++) {
+		if (!((1 << i) & orders))
+			continue;
+		snprintf(path, PATH_MAX, "hugepages-%ukB/enabled",
+			(getpagesize() >> 10) << i);
+		enabled = settings->hugepages[i].enabled;
+		thp_write_string(path, thp_enabled_strings[enabled]);
+	}
 }
 
 struct thp_settings *thp_current_settings(void)
@@ -294,3 +323,27 @@ void thp_set_read_ahead_path(char *path)
 		sizeof(dev_queue_read_ahead_path));
 	dev_queue_read_ahead_path[sizeof(dev_queue_read_ahead_path) - 1] = '\0';
 }
+
+unsigned long thp_supported_orders(void)
+{
+	unsigned long orders = 0;
+	char path[PATH_MAX];
+	char buf[256];
+	int ret;
+	int i;
+
+	for (i = 0; i < NR_ORDERS; i++) {
+		ret = snprintf(path, PATH_MAX, THP_SYSFS "hugepages-%ukB/enabled",
+			(getpagesize() >> 10) << i);
+		if (ret >= PATH_MAX) {
+			printf("%s: Pathname is too long\n", __func__);
+			exit(EXIT_FAILURE);
+		}
+
+		ret = read_file(path, buf, sizeof(buf));
+		if (ret)
+			orders |= 1UL << i;
+	}
+
+	return orders;
+}
diff --git a/tools/testing/selftests/mm/thp_settings.h b/tools/testing/selftests/mm/thp_settings.h
index ff3d98c30617..71cbff05f4c7 100644
--- a/tools/testing/selftests/mm/thp_settings.h
+++ b/tools/testing/selftests/mm/thp_settings.h
@@ -7,9 +7,10 @@
 #include <stdint.h>
 
 enum thp_enabled {
+	THP_NEVER,
 	THP_ALWAYS,
+	THP_INHERIT,
 	THP_MADVISE,
-	THP_NEVER,
 };
 
 enum thp_defrag {
@@ -29,6 +30,12 @@ enum shmem_enabled {
 	SHMEM_FORCE,
 };
 
+#define NR_ORDERS 20
+
+struct hugepages_settings {
+	enum thp_enabled enabled;
+};
+
 struct khugepaged_settings {
 	bool defrag;
 	unsigned int alloc_sleep_millisecs;
@@ -46,6 +53,7 @@ struct thp_settings {
 	bool use_zero_page;
 	struct khugepaged_settings khugepaged;
 	unsigned long read_ahead_kb;
+	struct hugepages_settings hugepages[NR_ORDERS];
 };
 
 int read_file(const char *path, char *buf, size_t buflen);
@@ -67,5 +75,6 @@ void thp_restore_settings(void);
 void thp_save_settings(void);
 
 void thp_set_read_ahead_path(char *path);
+unsigned long thp_supported_orders(void);
 
 #endif /* __THP_SETTINGS_H__ */
-- 
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:09 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:09 +0000
Subject: [PATCH v9 08/10] selftests/mm/khugepaged: Enlighten for multi-size THP
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-9-ryan.roberts@arm.com>

The `collapse_max_ptes_none` test was previously failing when a THP size
less than PMD-size had enabled="always". The root cause is because the
test faults in 1 page less than the threshold it set for collapsing. But
when THP is enabled always, we "over allocate" and therefore the
threshold is passed, and collapse unexpectedly succeeds.

Solve this by enlightening khugepaged selftest. Add a command line
option to pass in the desired THP size that should be used for all
anonymous allocations. The harness will then explicitly configure a THP
size as requested and modify the `collapse_max_ptes_none` test so that
it faults in the threshold minus the number of pages in the configured
THP size. If no command line option is provided, default to order 0, as
per previous behaviour.

I chose to use an order in the command line interface, since this makes
the interface agnostic of base page size, making it easier to invoke
from run_vmtests.sh.

Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/khugepaged.c   | 48 +++++++++++++++++------
 tools/testing/selftests/mm/run_vmtests.sh |  2 +
 2 files changed, 39 insertions(+), 11 deletions(-)

diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
index 7bd3baa9d34b..829320a519e7 100644
--- a/tools/testing/selftests/mm/khugepaged.c
+++ b/tools/testing/selftests/mm/khugepaged.c
@@ -28,6 +28,7 @@
 static unsigned long hpage_pmd_size;
 static unsigned long page_size;
 static int hpage_pmd_nr;
+static int anon_order;
 
 #define PID_SMAPS "/proc/self/smaps"
 #define TEST_FILE "collapse_test_file"
@@ -607,6 +608,11 @@ static bool is_tmpfs(struct mem_ops *ops)
 	return ops == &__file_ops && finfo.type == VMA_SHMEM;
 }
 
+static bool is_anon(struct mem_ops *ops)
+{
+	return ops == &__anon_ops;
+}
+
 static void alloc_at_fault(void)
 {
 	struct thp_settings settings = *thp_current_settings();
@@ -673,6 +679,7 @@ static void collapse_max_ptes_none(struct collapse_context *c, struct mem_ops *o
 	int max_ptes_none = hpage_pmd_nr / 2;
 	struct thp_settings settings = *thp_current_settings();
 	void *p;
+	int fault_nr_pages = is_anon(ops) ? 1 << anon_order : 1;
 
 	settings.khugepaged.max_ptes_none = max_ptes_none;
 	thp_push_settings(&settings);
@@ -686,10 +693,10 @@ static void collapse_max_ptes_none(struct collapse_context *c, struct mem_ops *o
 		goto skip;
 	}
 
-	ops->fault(p, 0, (hpage_pmd_nr - max_ptes_none - 1) * page_size);
+	ops->fault(p, 0, (hpage_pmd_nr - max_ptes_none - fault_nr_pages) * page_size);
 	c->collapse("Maybe collapse with max_ptes_none exceeded", p, 1,
 		    ops, !c->enforce_pte_scan_limits);
-	validate_memory(p, 0, (hpage_pmd_nr - max_ptes_none - 1) * page_size);
+	validate_memory(p, 0, (hpage_pmd_nr - max_ptes_none - fault_nr_pages) * page_size);
 
 	if (c->enforce_pte_scan_limits) {
 		ops->fault(p, 0, (hpage_pmd_nr - max_ptes_none) * page_size);
@@ -1076,7 +1083,7 @@ static void madvise_retracted_page_tables(struct collapse_context *c,
 
 static void usage(void)
 {
-	fprintf(stderr, "\nUsage: ./khugepaged <test type> [dir]\n\n");
+	fprintf(stderr, "\nUsage: ./khugepaged [OPTIONS] <test type> [dir]\n\n");
 	fprintf(stderr, "\t<test type>\t: <context>:<mem_type>\n");
 	fprintf(stderr, "\t<context>\t: [all|khugepaged|madvise]\n");
 	fprintf(stderr, "\t<mem_type>\t: [all|anon|file|shmem]\n");
@@ -1085,15 +1092,34 @@ static void usage(void)
 	fprintf(stderr,	"\tCONFIG_READ_ONLY_THP_FOR_FS=y\n");
 	fprintf(stderr, "\n\tif [dir] is a (sub)directory of a tmpfs mount, tmpfs must be\n");
 	fprintf(stderr,	"\tmounted with huge=madvise option for khugepaged tests to work\n");
+	fprintf(stderr,	"\n\tSupported Options:\n");
+	fprintf(stderr,	"\t\t-h: This help message.\n");
+	fprintf(stderr,	"\t\t-s: mTHP size, expressed as page order.\n");
+	fprintf(stderr,	"\t\t    Defaults to 0. Use this size for anon allocations.\n");
 	exit(1);
 }
 
-static void parse_test_type(int argc, const char **argv)
+static void parse_test_type(int argc, char **argv)
 {
+	int opt;
 	char *buf;
 	const char *token;
 
-	if (argc == 1) {
+	while ((opt = getopt(argc, argv, "s:h")) != -1) {
+		switch (opt) {
+		case 's':
+			anon_order = atoi(optarg);
+			break;
+		case 'h':
+		default:
+			usage();
+		}
+	}
+
+	argv += optind;
+	argc -= optind;
+
+	if (argc == 0) {
 		/* Backwards compatibility */
 		khugepaged_context =  &__khugepaged_context;
 		madvise_context =  &__madvise_context;
@@ -1101,7 +1127,7 @@ static void parse_test_type(int argc, const char **argv)
 		return;
 	}
 
-	buf = strdup(argv[1]);
+	buf = strdup(argv[0]);
 	token = strsep(&buf, ":");
 
 	if (!strcmp(token, "all")) {
@@ -1135,11 +1161,13 @@ static void parse_test_type(int argc, const char **argv)
 	if (!file_ops)
 		return;
 
-	if (argc != 3)
+	if (argc != 2)
 		usage();
+
+	get_finfo(argv[1]);
 }
 
-int main(int argc, const char **argv)
+int main(int argc, char **argv)
 {
 	int hpage_pmd_order;
 	struct thp_settings default_settings = {
@@ -1164,9 +1192,6 @@ int main(int argc, const char **argv)
 
 	parse_test_type(argc, argv);
 
-	if (file_ops)
-		get_finfo(argv[2]);
-
 	setbuf(stdout, NULL);
 
 	page_size = getpagesize();
@@ -1183,6 +1208,7 @@ int main(int argc, const char **argv)
 	default_settings.khugepaged.max_ptes_shared = hpage_pmd_nr / 2;
 	default_settings.khugepaged.pages_to_scan = hpage_pmd_nr * 8;
 	default_settings.hugepages[hpage_pmd_order].enabled = THP_INHERIT;
+	default_settings.hugepages[anon_order].enabled = THP_ALWAYS;
 
 	save_settings();
 	thp_push_settings(&default_settings);
diff --git a/tools/testing/selftests/mm/run_vmtests.sh b/tools/testing/selftests/mm/run_vmtests.sh
index c0212258b852..87f513f5cf91 100755
--- a/tools/testing/selftests/mm/run_vmtests.sh
+++ b/tools/testing/selftests/mm/run_vmtests.sh
@@ -357,6 +357,8 @@ CATEGORY="cow" run_test ./cow
 
 CATEGORY="thp" run_test ./khugepaged
 
+CATEGORY="thp" run_test ./khugepaged -s 2
+
 CATEGORY="thp" run_test ./transhuge-stress -d 20
 
 CATEGORY="thp" run_test ./split_huge_page_test
-- 
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:10 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:10 +0000
Subject: [PATCH v9 09/10] selftests/mm/cow: Generalize do_run_with_thp() helper
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-10-ryan.roberts@arm.com>

do_run_with_thp() prepares (PMD-sized) THP memory into different states
before running tests. With the introduction of multi-size THP, we would
like to reuse this logic to also test those smaller THP sizes. So let's
add a thpsize parameter which tells the function what size THP it should
operate on.

A separate commit will utilize this change to add new tests for
multi-size THP, where available.

Reviewed-by: David Hildenbrand <david at redhat.com>
Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/cow.c | 121 +++++++++++++++++--------------
 1 file changed, 67 insertions(+), 54 deletions(-)

diff --git a/tools/testing/selftests/mm/cow.c b/tools/testing/selftests/mm/cow.c
index 7324ce5363c0..4d0b5a125d3c 100644
--- a/tools/testing/selftests/mm/cow.c
+++ b/tools/testing/selftests/mm/cow.c
@@ -32,7 +32,7 @@
 
 static size_t pagesize;
 static int pagemap_fd;
-static size_t thpsize;
+static size_t pmdsize;
 static int nr_hugetlbsizes;
 static size_t hugetlbsizes[10];
 static int gup_fd;
@@ -734,7 +734,7 @@ enum thp_run {
 	THP_RUN_PARTIAL_SHARED,
 };
 
-static void do_run_with_thp(test_fn fn, enum thp_run thp_run)
+static void do_run_with_thp(test_fn fn, enum thp_run thp_run, size_t thpsize)
 {
 	char *mem, *mmap_mem, *tmp, *mremap_mem = MAP_FAILED;
 	size_t size, mmap_size, mremap_size;
@@ -759,11 +759,11 @@ static void do_run_with_thp(test_fn fn, enum thp_run thp_run)
 	}
 
 	/*
-	 * Try to populate a THP. Touch the first sub-page and test if we get
-	 * another sub-page populated automatically.
+	 * Try to populate a THP. Touch the first sub-page and test if
+	 * we get the last sub-page populated automatically.
 	 */
 	mem[0] = 0;
-	if (!pagemap_is_populated(pagemap_fd, mem + pagesize)) {
+	if (!pagemap_is_populated(pagemap_fd, mem + thpsize - pagesize)) {
 		ksft_test_result_skip("Did not get a THP populated\n");
 		goto munmap;
 	}
@@ -773,12 +773,14 @@ static void do_run_with_thp(test_fn fn, enum thp_run thp_run)
 	switch (thp_run) {
 	case THP_RUN_PMD:
 	case THP_RUN_PMD_SWAPOUT:
+		assert(thpsize == pmdsize);
 		break;
 	case THP_RUN_PTE:
 	case THP_RUN_PTE_SWAPOUT:
 		/*
 		 * Trigger PTE-mapping the THP by temporarily mapping a single
-		 * subpage R/O.
+		 * subpage R/O. This is a noop if the THP is not pmdsize (and
+		 * therefore already PTE-mapped).
 		 */
 		ret = mprotect(mem + pagesize, pagesize, PROT_READ);
 		if (ret) {
@@ -875,52 +877,60 @@ static void do_run_with_thp(test_fn fn, enum thp_run thp_run)
 		munmap(mremap_mem, mremap_size);
 }
 
-static void run_with_thp(test_fn fn, const char *desc)
+static void run_with_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PMD);
+	ksft_print_msg("[RUN] %s ... with THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PMD, size);
 }
 
-static void run_with_thp_swap(test_fn fn, const char *desc)
+static void run_with_thp_swap(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with swapped-out THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PMD_SWAPOUT);
+	ksft_print_msg("[RUN] %s ... with swapped-out THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PMD_SWAPOUT, size);
 }
 
-static void run_with_pte_mapped_thp(test_fn fn, const char *desc)
+static void run_with_pte_mapped_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with PTE-mapped THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PTE);
+	ksft_print_msg("[RUN] %s ... with PTE-mapped THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PTE, size);
 }
 
-static void run_with_pte_mapped_thp_swap(test_fn fn, const char *desc)
+static void run_with_pte_mapped_thp_swap(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with swapped-out, PTE-mapped THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PTE_SWAPOUT);
+	ksft_print_msg("[RUN] %s ... with swapped-out, PTE-mapped THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PTE_SWAPOUT, size);
 }
 
-static void run_with_single_pte_of_thp(test_fn fn, const char *desc)
+static void run_with_single_pte_of_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with single PTE of THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_SINGLE_PTE);
+	ksft_print_msg("[RUN] %s ... with single PTE of THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_SINGLE_PTE, size);
 }
 
-static void run_with_single_pte_of_thp_swap(test_fn fn, const char *desc)
+static void run_with_single_pte_of_thp_swap(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with single PTE of swapped-out THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_SINGLE_PTE_SWAPOUT);
+	ksft_print_msg("[RUN] %s ... with single PTE of swapped-out THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_SINGLE_PTE_SWAPOUT, size);
 }
 
-static void run_with_partial_mremap_thp(test_fn fn, const char *desc)
+static void run_with_partial_mremap_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with partially mremap()'ed THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PARTIAL_MREMAP);
+	ksft_print_msg("[RUN] %s ... with partially mremap()'ed THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PARTIAL_MREMAP, size);
 }
 
-static void run_with_partial_shared_thp(test_fn fn, const char *desc)
+static void run_with_partial_shared_thp(test_fn fn, const char *desc, size_t size)
 {
-	ksft_print_msg("[RUN] %s ... with partially shared THP\n", desc);
-	do_run_with_thp(fn, THP_RUN_PARTIAL_SHARED);
+	ksft_print_msg("[RUN] %s ... with partially shared THP (%zu kB)\n",
+		desc, size / 1024);
+	do_run_with_thp(fn, THP_RUN_PARTIAL_SHARED, size);
 }
 
 static void run_with_hugetlb(test_fn fn, const char *desc, size_t hugetlbsize)
@@ -1091,15 +1101,15 @@ static void run_anon_test_case(struct test_case const *test_case)
 
 	run_with_base_page(test_case->fn, test_case->desc);
 	run_with_base_page_swap(test_case->fn, test_case->desc);
-	if (thpsize) {
-		run_with_thp(test_case->fn, test_case->desc);
-		run_with_thp_swap(test_case->fn, test_case->desc);
-		run_with_pte_mapped_thp(test_case->fn, test_case->desc);
-		run_with_pte_mapped_thp_swap(test_case->fn, test_case->desc);
-		run_with_single_pte_of_thp(test_case->fn, test_case->desc);
-		run_with_single_pte_of_thp_swap(test_case->fn, test_case->desc);
-		run_with_partial_mremap_thp(test_case->fn, test_case->desc);
-		run_with_partial_shared_thp(test_case->fn, test_case->desc);
+	if (pmdsize) {
+		run_with_thp(test_case->fn, test_case->desc, pmdsize);
+		run_with_thp_swap(test_case->fn, test_case->desc, pmdsize);
+		run_with_pte_mapped_thp(test_case->fn, test_case->desc, pmdsize);
+		run_with_pte_mapped_thp_swap(test_case->fn, test_case->desc, pmdsize);
+		run_with_single_pte_of_thp(test_case->fn, test_case->desc, pmdsize);
+		run_with_single_pte_of_thp_swap(test_case->fn, test_case->desc, pmdsize);
+		run_with_partial_mremap_thp(test_case->fn, test_case->desc, pmdsize);
+		run_with_partial_shared_thp(test_case->fn, test_case->desc, pmdsize);
 	}
 	for (i = 0; i < nr_hugetlbsizes; i++)
 		run_with_hugetlb(test_case->fn, test_case->desc,
@@ -1120,7 +1130,7 @@ static int tests_per_anon_test_case(void)
 {
 	int tests = 2 + nr_hugetlbsizes;
 
-	if (thpsize)
+	if (pmdsize)
 		tests += 8;
 	return tests;
 }
@@ -1329,7 +1339,7 @@ static void run_anon_thp_test_cases(void)
 {
 	int i;
 
-	if (!thpsize)
+	if (!pmdsize)
 		return;
 
 	ksft_print_msg("[INFO] Anonymous THP tests\n");
@@ -1338,13 +1348,13 @@ static void run_anon_thp_test_cases(void)
 		struct test_case const *test_case = &anon_thp_test_cases[i];
 
 		ksft_print_msg("[RUN] %s\n", test_case->desc);
-		do_run_with_thp(test_case->fn, THP_RUN_PMD);
+		do_run_with_thp(test_case->fn, THP_RUN_PMD, pmdsize);
 	}
 }
 
 static int tests_per_anon_thp_test_case(void)
 {
-	return thpsize ? 1 : 0;
+	return pmdsize ? 1 : 0;
 }
 
 typedef void (*non_anon_test_fn)(char *mem, const char *smem, size_t size);
@@ -1419,7 +1429,7 @@ static void run_with_huge_zeropage(non_anon_test_fn fn, const char *desc)
 	}
 
 	/* For alignment purposes, we need twice the thp size. */
-	mmap_size = 2 * thpsize;
+	mmap_size = 2 * pmdsize;
 	mmap_mem = mmap(NULL, mmap_size, PROT_READ | PROT_WRITE,
 			MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
 	if (mmap_mem == MAP_FAILED) {
@@ -1434,11 +1444,11 @@ static void run_with_huge_zeropage(non_anon_test_fn fn, const char *desc)
 	}
 
 	/* We need a THP-aligned memory area. */
-	mem = (char *)(((uintptr_t)mmap_mem + thpsize) & ~(thpsize - 1));
-	smem = (char *)(((uintptr_t)mmap_smem + thpsize) & ~(thpsize - 1));
+	mem = (char *)(((uintptr_t)mmap_mem + pmdsize) & ~(pmdsize - 1));
+	smem = (char *)(((uintptr_t)mmap_smem + pmdsize) & ~(pmdsize - 1));
 
-	ret = madvise(mem, thpsize, MADV_HUGEPAGE);
-	ret |= madvise(smem, thpsize, MADV_HUGEPAGE);
+	ret = madvise(mem, pmdsize, MADV_HUGEPAGE);
+	ret |= madvise(smem, pmdsize, MADV_HUGEPAGE);
 	if (ret) {
 		ksft_test_result_fail("MADV_HUGEPAGE failed\n");
 		goto munmap;
@@ -1457,7 +1467,7 @@ static void run_with_huge_zeropage(non_anon_test_fn fn, const char *desc)
 		goto munmap;
 	}
 
-	fn(mem, smem, thpsize);
+	fn(mem, smem, pmdsize);
 munmap:
 	munmap(mmap_mem, mmap_size);
 	if (mmap_smem != MAP_FAILED)
@@ -1650,7 +1660,7 @@ static void run_non_anon_test_case(struct non_anon_test_case const *test_case)
 	run_with_zeropage(test_case->fn, test_case->desc);
 	run_with_memfd(test_case->fn, test_case->desc);
 	run_with_tmpfile(test_case->fn, test_case->desc);
-	if (thpsize)
+	if (pmdsize)
 		run_with_huge_zeropage(test_case->fn, test_case->desc);
 	for (i = 0; i < nr_hugetlbsizes; i++)
 		run_with_memfd_hugetlb(test_case->fn, test_case->desc,
@@ -1671,7 +1681,7 @@ static int tests_per_non_anon_test_case(void)
 {
 	int tests = 3 + nr_hugetlbsizes;
 
-	if (thpsize)
+	if (pmdsize)
 		tests += 1;
 	return tests;
 }
@@ -1681,10 +1691,13 @@ int main(int argc, char **argv)
 	int err;
 
 	pagesize = getpagesize();
-	thpsize = read_pmd_pagesize();
-	if (thpsize)
+	pmdsize = read_pmd_pagesize();
+	if (pmdsize) {
+		ksft_print_msg("[INFO] detected PMD size: %zu KiB\n",
+			       pmdsize / 1024);
 		ksft_print_msg("[INFO] detected THP size: %zu KiB\n",
-			       thpsize / 1024);
+			       pmdsize / 1024);
+	}
 	nr_hugetlbsizes = detect_hugetlb_page_sizes(hugetlbsizes,
 						    ARRAY_SIZE(hugetlbsizes));
 	detect_huge_zeropage();
-- 
2.25.1



From ryan.roberts at arm.com  Thu Dec  7 08:12:11 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu,  7 Dec 2023 16:12:11 +0000
Subject: [PATCH v9 10/10] selftests/mm/cow: Add tests for anonymous multi-size THP
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207161211.2374093-11-ryan.roberts@arm.com>

Add tests similar to the existing PMD-sized THP tests, but which operate
on memory backed by (PTE-mapped) multi-size THP. This reuses all the
existing infrastructure. If the test suite detects that multi-size THP
is not supported by the kernel, the new tests are skipped.

Reviewed-by: David Hildenbrand <david at redhat.com>
Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 tools/testing/selftests/mm/cow.c | 84 +++++++++++++++++++++++++++-----
 1 file changed, 72 insertions(+), 12 deletions(-)

diff --git a/tools/testing/selftests/mm/cow.c b/tools/testing/selftests/mm/cow.c
index 4d0b5a125d3c..37b4d7d28ae9 100644
--- a/tools/testing/selftests/mm/cow.c
+++ b/tools/testing/selftests/mm/cow.c
@@ -29,15 +29,49 @@
 #include "../../../../mm/gup_test.h"
 #include "../kselftest.h"
 #include "vm_util.h"
+#include "thp_settings.h"
 
 static size_t pagesize;
 static int pagemap_fd;
 static size_t pmdsize;
+static int nr_thpsizes;
+static size_t thpsizes[20];
 static int nr_hugetlbsizes;
 static size_t hugetlbsizes[10];
 static int gup_fd;
 static bool has_huge_zeropage;
 
+static int sz2ord(size_t size)
+{
+	return __builtin_ctzll(size / pagesize);
+}
+
+static int detect_thp_sizes(size_t sizes[], int max)
+{
+	int count = 0;
+	unsigned long orders;
+	size_t kb;
+	int i;
+
+	/* thp not supported at all. */
+	if (!pmdsize)
+		return 0;
+
+	orders = 1UL << sz2ord(pmdsize);
+	orders |= thp_supported_orders();
+
+	for (i = 0; orders && count < max; i++) {
+		if (!(orders & (1UL << i)))
+			continue;
+		orders &= ~(1UL << i);
+		kb = (pagesize >> 10) << i;
+		sizes[count++] = kb * 1024;
+		ksft_print_msg("[INFO] detected THP size: %zu KiB\n", kb);
+	}
+
+	return count;
+}
+
 static void detect_huge_zeropage(void)
 {
 	int fd = open("/sys/kernel/mm/transparent_hugepage/use_zero_page",
@@ -1101,15 +1135,27 @@ static void run_anon_test_case(struct test_case const *test_case)
 
 	run_with_base_page(test_case->fn, test_case->desc);
 	run_with_base_page_swap(test_case->fn, test_case->desc);
-	if (pmdsize) {
-		run_with_thp(test_case->fn, test_case->desc, pmdsize);
-		run_with_thp_swap(test_case->fn, test_case->desc, pmdsize);
-		run_with_pte_mapped_thp(test_case->fn, test_case->desc, pmdsize);
-		run_with_pte_mapped_thp_swap(test_case->fn, test_case->desc, pmdsize);
-		run_with_single_pte_of_thp(test_case->fn, test_case->desc, pmdsize);
-		run_with_single_pte_of_thp_swap(test_case->fn, test_case->desc, pmdsize);
-		run_with_partial_mremap_thp(test_case->fn, test_case->desc, pmdsize);
-		run_with_partial_shared_thp(test_case->fn, test_case->desc, pmdsize);
+	for (i = 0; i < nr_thpsizes; i++) {
+		size_t size = thpsizes[i];
+		struct thp_settings settings = *thp_current_settings();
+
+		settings.hugepages[sz2ord(pmdsize)].enabled = THP_NEVER;
+		settings.hugepages[sz2ord(size)].enabled = THP_ALWAYS;
+		thp_push_settings(&settings);
+
+		if (size == pmdsize) {
+			run_with_thp(test_case->fn, test_case->desc, size);
+			run_with_thp_swap(test_case->fn, test_case->desc, size);
+		}
+
+		run_with_pte_mapped_thp(test_case->fn, test_case->desc, size);
+		run_with_pte_mapped_thp_swap(test_case->fn, test_case->desc, size);
+		run_with_single_pte_of_thp(test_case->fn, test_case->desc, size);
+		run_with_single_pte_of_thp_swap(test_case->fn, test_case->desc, size);
+		run_with_partial_mremap_thp(test_case->fn, test_case->desc, size);
+		run_with_partial_shared_thp(test_case->fn, test_case->desc, size);
+
+		thp_pop_settings();
 	}
 	for (i = 0; i < nr_hugetlbsizes; i++)
 		run_with_hugetlb(test_case->fn, test_case->desc,
@@ -1130,8 +1176,9 @@ static int tests_per_anon_test_case(void)
 {
 	int tests = 2 + nr_hugetlbsizes;
 
+	tests += 6 * nr_thpsizes;
 	if (pmdsize)
-		tests += 8;
+		tests += 2;
 	return tests;
 }
 
@@ -1689,15 +1736,23 @@ static int tests_per_non_anon_test_case(void)
 int main(int argc, char **argv)
 {
 	int err;
+	struct thp_settings default_settings;
 
 	pagesize = getpagesize();
 	pmdsize = read_pmd_pagesize();
 	if (pmdsize) {
+		/* Only if THP is supported. */
+		thp_read_settings(&default_settings);
+		default_settings.hugepages[sz2ord(pmdsize)].enabled = THP_INHERIT;
+		thp_save_settings();
+		thp_push_settings(&default_settings);
+
 		ksft_print_msg("[INFO] detected PMD size: %zu KiB\n",
 			       pmdsize / 1024);
-		ksft_print_msg("[INFO] detected THP size: %zu KiB\n",
-			       pmdsize / 1024);
+
+		nr_thpsizes = detect_thp_sizes(thpsizes, ARRAY_SIZE(thpsizes));
 	}
+
 	nr_hugetlbsizes = detect_hugetlb_page_sizes(hugetlbsizes,
 						    ARRAY_SIZE(hugetlbsizes));
 	detect_huge_zeropage();
@@ -1716,6 +1771,11 @@ int main(int argc, char **argv)
 	run_anon_thp_test_cases();
 	run_non_anon_test_cases();
 
+	if (pmdsize) {
+		/* Only if THP is supported. */
+		thp_restore_settings();
+	}
+
 	err = ksft_get_fail_cnt();
 	if (err)
 		ksft_exit_fail_msg("%d out of %d tests failed\n",
-- 
2.25.1



From broonie at kernel.org  Thu Dec  7 08:20:43 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 7 Dec 2023 16:20:43 +0000
Subject: [GIT PULL] Immutable branch between MFD and SPI due for the v6.8
 merge window
In-Reply-To: <20231207133849.GB8867@google.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-2-amit.kumar-mahapatra@amd.com>
 <170142465659.3329910.8527538140063947758.b4-ty@kernel.org>
 <395caa58-a8a0-4c75-85d3-4fa0f6f4a9ba@sirena.org.uk>
 <20231207133849.GB8867@google.com>
Message-ID: <d12da7b2-f18c-4b56-85be-6d98b62d6ddd@sirena.org.uk>

On Thu, Dec 07, 2023 at 01:38:49PM +0000, Lee Jones wrote:
> Good afternoon Mark,
> 
> > Is there a signed tag available for this - without this change the
> > subsequent SPI changes introduce a build breakage.
> 
> The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
> 
>   Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-spi-v6.8
> 
> for you to fetch changes up to 4ae08845db4c1f759b8382bc7527ab8249230e7f:
> 
>   mfd: tps6594: Use spi_get_chipselect() API to access spi->chip_select (2023-12-07 13:36:29 +0000)

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/272b3876/attachment.sig>

From seanjc at google.com  Thu Dec  7 08:21:02 2023
From: seanjc at google.com (Sean Christopherson)
Date: Thu, 7 Dec 2023 08:21:02 -0800
Subject: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()
In-Reply-To: <20231207010302.2240506-1-jmattson@google.com>
References: <20220921003201.1441511-11-seanjc@google.com> <20231207010302.2240506-1-jmattson@google.com>
Message-ID: <ZXHw7tykubfG04Um@google.com>

On Wed, Dec 06, 2023, Jim Mattson wrote:
> kvm_vcpu_check_block() is called while not in TASK_RUNNING, and therefore
> it cannot sleep.  Writing to guest memory is therefore forbidden, but it
> can happen on AMD processors if kvm_check_nested_events() causes a vmexit.
> 
> Fortunately, all events that are caught by kvm_check_nested_events() are
> also recognized by kvm_vcpu_has_events() through vendor callbacks such as
> kvm_x86_interrupt_allowed() or kvm_x86_ops.nested_ops->has_events(), so
> remove the call and postpone the actual processing to vcpu_block().
> 
> Opportunistically honor the return of kvm_check_nested_events().  KVM
> punted on the check in kvm_vcpu_running() because the only error path is
> if vmx_complete_nested_posted_interrupt() fails, in which case KVM exits
> to userspace with "internal error" i.e. the VM is likely dead anyways so
> it wasn't worth overloading the return of kvm_vcpu_running().
> 
> Add the check mostly so that KVM is consistent with itself; the return of
> the call via kvm_apic_accept_events()=>kvm_check_nested_events() that
> immediately follows  _is_ checked.
> 
> Reported-by: Maxim Levitsky <mlevitsk at redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini at redhat.com>
> [sean: check and handle return of kvm_check_nested_events()]
> Signed-off-by: Sean Christopherson <seanjc at google.com>
> ---
>  arch/x86/kvm/x86.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index dcc675d4e44b..8aeacbc2bff9 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10815,6 +10815,17 @@ static inline int vcpu_block(struct kvm_vcpu *vcpu)
>  			return 1;
>  	}
>  
> +	/*
> +	 * Evaluate nested events before exiting the halted state.  This allows
> +	 * the halt state to be recorded properly in the VMCS12's activity
> +	 * state field (AMD does not have a similar field and a VM-Exit always
> +	 * causes a spurious wakeup from HLT).
> +	 */
> +	if (is_guest_mode(vcpu)) {
> +		if (kvm_check_nested_events(vcpu) < 0)
> +			return 0;
> +	}
> +
>  	if (kvm_apic_accept_events(vcpu) < 0)
>  		return 0;
>  	switch(vcpu->arch.mp_state) {
> @@ -10837,9 +10848,6 @@ static inline int vcpu_block(struct kvm_vcpu *vcpu)
>  
>  static inline bool kvm_vcpu_running(struct kvm_vcpu *vcpu)
>  {
> -	if (is_guest_mode(vcpu))
> -		kvm_check_nested_events(vcpu);
> -
>  	return (vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE &&
>  		!vcpu->arch.apf.halted);
>  }
> 
> This commit breaks delivery of a (virtualized) posted interrupt from
> an L1 vCPU to a halted L2 vCPU.
> 
> Looking back at commit e6c67d8cf117 ("KVM: nVMX: Wake blocked vCPU in
> guest-mode if pending interrupt in virtual APICv"), Liran wrote:
> 
>     Note that this also handles the case of nested posted-interrupt by the
>     fact RVI is updated in vmx_complete_nested_posted_interrupt() which is
>     called from kvm_vcpu_check_block() -> kvm_arch_vcpu_runnable() ->
>     kvm_vcpu_running() -> vmx_check_nested_events() ->
>     vmx_complete_nested_posted_interrupt().
> 
> Clearly, that is no longer the case.

Doh.  We got the less obvious cases and missed the obvious one.

Ugh, and we also missed a related mess in kvm_guest_apic_has_interrupt().  That
thing should really be folded into vmx_has_nested_events().

Good gravy.  And vmx_interrupt_blocked() does the wrong thing because that
specifically checks if L1 interrupts are blocked.

Compile tested only, and definitely needs to be chunked into multiple patches,
but I think something like this mess?

---
 arch/x86/include/asm/kvm-x86-ops.h |  1 -
 arch/x86/include/asm/kvm_host.h    |  1 -
 arch/x86/kvm/lapic.c               | 20 ++---------------
 arch/x86/kvm/lapic.h               | 12 ++++++++++
 arch/x86/kvm/vmx/nested.c          | 36 ++++++++++++++++++++++++++++--
 arch/x86/kvm/vmx/vmx.c             | 34 ++++++++--------------------
 arch/x86/kvm/vmx/vmx.h             |  1 +
 arch/x86/kvm/x86.c                 | 10 +--------
 8 files changed, 59 insertions(+), 56 deletions(-)

diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-x86-ops.h
index 378ed944b849..6f81774c1dd0 100644
--- a/arch/x86/include/asm/kvm-x86-ops.h
+++ b/arch/x86/include/asm/kvm-x86-ops.h
@@ -85,7 +85,6 @@ KVM_X86_OP_OPTIONAL(update_cr8_intercept)
 KVM_X86_OP(refresh_apicv_exec_ctrl)
 KVM_X86_OP_OPTIONAL(hwapic_irr_update)
 KVM_X86_OP_OPTIONAL(hwapic_isr_update)
-KVM_X86_OP_OPTIONAL_RET0(guest_apic_has_interrupt)
 KVM_X86_OP_OPTIONAL(load_eoi_exitmap)
 KVM_X86_OP_OPTIONAL(set_virtual_apic_mode)
 KVM_X86_OP_OPTIONAL(set_apic_access_page_addr)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c8c7e2475a18..fc1466035a8c 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1685,7 +1685,6 @@ struct kvm_x86_ops {
 	void (*refresh_apicv_exec_ctrl)(struct kvm_vcpu *vcpu);
 	void (*hwapic_irr_update)(struct kvm_vcpu *vcpu, int max_irr);
 	void (*hwapic_isr_update)(int isr);
-	bool (*guest_apic_has_interrupt)(struct kvm_vcpu *vcpu);
 	void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
 	void (*set_virtual_apic_mode)(struct kvm_vcpu *vcpu);
 	void (*set_apic_access_page_addr)(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 245b20973cae..6d74c42accdf 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -55,7 +55,6 @@
 #define APIC_VERSION			0x14UL
 #define LAPIC_MMIO_LENGTH		(1 << 12)
 /* followed define is not in apicdef.h */
-#define MAX_APIC_VECTOR			256
 #define APIC_VECTORS_PER_REG		32
 
 static bool lapic_timer_advance_dynamic __read_mostly;
@@ -619,21 +618,6 @@ static const unsigned int apic_lvt_mask[KVM_APIC_MAX_NR_LVT_ENTRIES] = {
 	[LVT_CMCI] = LVT_MASK | APIC_MODE_MASK
 };
 
-static int find_highest_vector(void *bitmap)
-{
-	int vec;
-	u32 *reg;
-
-	for (vec = MAX_APIC_VECTOR - APIC_VECTORS_PER_REG;
-	     vec >= 0; vec -= APIC_VECTORS_PER_REG) {
-		reg = bitmap + REG_POS(vec);
-		if (*reg)
-			return __fls(*reg) + vec;
-	}
-
-	return -1;
-}
-
 static u8 count_vectors(void *bitmap)
 {
 	int vec;
@@ -697,7 +681,7 @@ EXPORT_SYMBOL_GPL(kvm_apic_update_irr);
 
 static inline int apic_search_irr(struct kvm_lapic *apic)
 {
-	return find_highest_vector(apic->regs + APIC_IRR);
+	return kvm_apic_find_highest_vector(apic->regs + APIC_IRR);
 }
 
 static inline int apic_find_highest_irr(struct kvm_lapic *apic)
@@ -775,7 +759,7 @@ static inline int apic_find_highest_isr(struct kvm_lapic *apic)
 	if (likely(apic->highest_isr_cache != -1))
 		return apic->highest_isr_cache;
 
-	result = find_highest_vector(apic->regs + APIC_ISR);
+	result = kvm_apic_find_highest_vector(apic->regs + APIC_ISR);
 	ASSERT(result == -1 || result >= 16);
 
 	return result;
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index 0a0ea4b5dd8c..4239bf329748 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -12,6 +12,8 @@
 #define KVM_APIC_INIT		0
 #define KVM_APIC_SIPI		1
 
+#define MAX_APIC_VECTOR			256
+
 #define APIC_SHORT_MASK			0xc0000
 #define APIC_DEST_NOSHORT		0x0
 #define APIC_DEST_MASK			0x800
@@ -151,6 +153,16 @@ u64 kvm_lapic_readable_reg_mask(struct kvm_lapic *apic);
 #define VEC_POS(v) ((v) & (32 - 1))
 #define REG_POS(v) (((v) >> 5) << 4)
 
+static inline int kvm_apic_find_highest_vector(unsigned long *bitmap)
+{
+	unsigned long bit = find_last_bit(bitmap, MAX_APIC_VECTOR);
+
+	if (bit == MAX_APIC_VECTOR)
+		return -1;
+
+	return bit;
+}
+
 static inline void kvm_lapic_clear_vector(int vec, void *bitmap)
 {
 	clear_bit(VEC_POS(vec), (bitmap) + REG_POS(vec));
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 4ba46e1b29d2..28b3c1c0830f 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -3964,8 +3964,40 @@ static bool nested_vmx_preemption_timer_pending(struct kvm_vcpu *vcpu)
 
 static bool vmx_has_nested_events(struct kvm_vcpu *vcpu)
 {
-	return nested_vmx_preemption_timer_pending(vcpu) ||
-	       to_vmx(vcpu)->nested.mtf_pending;
+	struct vcpu_vmx *vmx = to_vmx(vcpu);
+	void *vapic = vmx->nested.virtual_apic_map.hva;
+	int max_irr, vppr;
+
+	if (nested_vmx_preemption_timer_pending(vcpu) ||
+	    vmx->nested.mtf_pending)
+		return true;
+
+	if (!nested_cpu_has_vid(get_vmcs12(vcpu)) ||
+	    __vmx_interrupt_blocked(vcpu))
+		return false;
+
+	if (!vapic)
+		return false;
+
+	vppr = *((u32 *)(vapic + APIC_PROCPRI));
+
+	max_irr = vmx_get_rvi();
+	if ((max_irr & 0xf0) > (vppr & 0xf0))
+		return true;
+
+	max_irr = kvm_apic_find_highest_vector(vapic + APIC_IRR);
+	if (max_irr > 0 && (max_irr & 0xf0) > (vppr & 0xf0))
+		return true;
+
+	if (vmx->nested.pi_desc && pi_test_on(vmx->nested.pi_desc)) {
+		void *pir = vmx->nested.pi_desc->pir;
+
+		max_irr = kvm_apic_find_highest_vector(pir);
+		if (max_irr > 0 && (max_irr & 0xf0) > (vppr & 0xf0))
+			return true;
+	}
+
+	return false;
 }
 
 /*
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index d30df9b3fe3e..be8ab49e9965 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -4107,26 +4107,6 @@ void pt_update_intercept_for_msr(struct kvm_vcpu *vcpu)
 	}
 }
 
-static bool vmx_guest_apic_has_interrupt(struct kvm_vcpu *vcpu)
-{
-	struct vcpu_vmx *vmx = to_vmx(vcpu);
-	void *vapic_page;
-	u32 vppr;
-	int rvi;
-
-	if (WARN_ON_ONCE(!is_guest_mode(vcpu)) ||
-		!nested_cpu_has_vid(get_vmcs12(vcpu)) ||
-		WARN_ON_ONCE(!vmx->nested.virtual_apic_map.gfn))
-		return false;
-
-	rvi = vmx_get_rvi();
-
-	vapic_page = vmx->nested.virtual_apic_map.hva;
-	vppr = *((u32 *)(vapic_page + APIC_PROCPRI));
-
-	return ((rvi & 0xf0) > (vppr & 0xf0));
-}
-
 static void vmx_msr_filter_changed(struct kvm_vcpu *vcpu)
 {
 	struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -5040,16 +5020,21 @@ static int vmx_nmi_allowed(struct kvm_vcpu *vcpu, bool for_injection)
 	return !vmx_nmi_blocked(vcpu);
 }
 
-bool vmx_interrupt_blocked(struct kvm_vcpu *vcpu)
+bool __vmx_interrupt_blocked(struct kvm_vcpu *vcpu)
 {
-	if (is_guest_mode(vcpu) && nested_exit_on_intr(vcpu))
-		return false;
-
 	return !(vmx_get_rflags(vcpu) & X86_EFLAGS_IF) ||
 	       (vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) &
 		(GUEST_INTR_STATE_STI | GUEST_INTR_STATE_MOV_SS));
 }
 
+bool vmx_interrupt_blocked(struct kvm_vcpu *vcpu)
+{
+	if (is_guest_mode(vcpu) && nested_exit_on_intr(vcpu))
+		return false;
+
+	return __vmx_interrupt_blocked(vcpu);
+}
+
 static int vmx_interrupt_allowed(struct kvm_vcpu *vcpu, bool for_injection)
 {
 	if (to_vmx(vcpu)->nested.nested_run_pending)
@@ -8335,7 +8320,6 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = {
 	.required_apicv_inhibits = VMX_REQUIRED_APICV_INHIBITS,
 	.hwapic_irr_update = vmx_hwapic_irr_update,
 	.hwapic_isr_update = vmx_hwapic_isr_update,
-	.guest_apic_has_interrupt = vmx_guest_apic_has_interrupt,
 	.sync_pir_to_irr = vmx_sync_pir_to_irr,
 	.deliver_interrupt = vmx_deliver_interrupt,
 	.dy_apicv_has_pending_interrupt = pi_has_pending_interrupt,
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 45cee1a8bc0a..4097afed4425 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -400,6 +400,7 @@ u64 construct_eptp(struct kvm_vcpu *vcpu, hpa_t root_hpa, int root_level);
 bool vmx_guest_inject_ac(struct kvm_vcpu *vcpu);
 void vmx_update_exception_bitmap(struct kvm_vcpu *vcpu);
 bool vmx_nmi_blocked(struct kvm_vcpu *vcpu);
+bool __vmx_interrupt_blocked(struct kvm_vcpu *vcpu);
 bool vmx_interrupt_blocked(struct kvm_vcpu *vcpu);
 bool vmx_get_nmi_mask(struct kvm_vcpu *vcpu);
 void vmx_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1983947b8965..b9e599a4b487 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12974,12 +12974,6 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
 		kvm_arch_free_memslot(kvm, old);
 }
 
-static inline bool kvm_guest_apic_has_interrupt(struct kvm_vcpu *vcpu)
-{
-	return (is_guest_mode(vcpu) &&
-		static_call(kvm_x86_guest_apic_has_interrupt)(vcpu));
-}
-
 static inline bool kvm_vcpu_has_events(struct kvm_vcpu *vcpu)
 {
 	if (!list_empty_careful(&vcpu->async_pf.done))
@@ -13010,9 +13004,7 @@ static inline bool kvm_vcpu_has_events(struct kvm_vcpu *vcpu)
 	if (kvm_test_request(KVM_REQ_PMI, vcpu))
 		return true;
 
-	if (kvm_arch_interrupt_allowed(vcpu) &&
-	    (kvm_cpu_has_interrupt(vcpu) ||
-	    kvm_guest_apic_has_interrupt(vcpu)))
+	if (kvm_arch_interrupt_allowed(vcpu) && kvm_cpu_has_interrupt(vcpu))
 		return true;
 
 	if (kvm_hv_has_stimer_pending(vcpu))

base-commit: 1ab097653e4dd8d23272d028a61352c23486fd4a
-- 



From lkp at intel.com  Thu Dec  7 08:32:08 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 08 Dec 2023 00:32:08 +0800
Subject: [soc:soc/defconfig] BUILD SUCCESS
 542b667fe9ee139d8c36e41fa25460f0d67b20ac
Message-ID: <202312080005.L0tchnBu-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/defconfig
branch HEAD: 542b667fe9ee139d8c36e41fa25460f0d67b20ac  Merge tag 'renesas-arm-defconfig-for-v6.8-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/defconfig

elapsed time: 1408m

configs tested: 157
configs skipped: 108

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231207   gcc  
arc                   randconfig-002-20231207   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                                 defconfig   clang
arm                           h3600_defconfig   gcc  
arm                      jornada720_defconfig   gcc  
arm                        multi_v7_defconfig   gcc  
arm                   randconfig-001-20231207   gcc  
arm                   randconfig-002-20231207   gcc  
arm                   randconfig-003-20231207   gcc  
arm                   randconfig-004-20231207   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231207   gcc  
arm64                 randconfig-002-20231207   gcc  
arm64                 randconfig-003-20231207   gcc  
arm64                 randconfig-004-20231207   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231207   gcc  
csky                  randconfig-002-20231207   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231207   clang
i386                  randconfig-012-20231207   clang
i386                  randconfig-013-20231207   clang
i386                  randconfig-014-20231207   clang
i386                  randconfig-015-20231207   clang
i386                  randconfig-016-20231207   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231207   gcc  
loongarch             randconfig-002-20231207   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5272c3_defconfig   gcc  
m68k                        mvme147_defconfig   gcc  
m68k                        stmark2_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                       bmips_be_defconfig   gcc  
mips                           ci20_defconfig   gcc  
mips                           ip27_defconfig   gcc  
mips                      loongson3_defconfig   gcc  
mips                         rt305x_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231207   gcc  
nios2                 randconfig-002-20231207   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231207   gcc  
parisc                randconfig-002-20231207   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                      ep88xc_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                     mpc83xx_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc               randconfig-001-20231207   gcc  
powerpc               randconfig-002-20231207   gcc  
powerpc               randconfig-003-20231207   gcc  
powerpc                    socrates_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
powerpc64             randconfig-001-20231207   gcc  
powerpc64             randconfig-002-20231207   gcc  
powerpc64             randconfig-003-20231207   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231207   gcc  
riscv                 randconfig-002-20231207   gcc  
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                         ap325rxa_defconfig   gcc  
sh                                  defconfig   gcc  
sh                        dreamcast_defconfig   gcc  
sh                         ecovec24_defconfig   gcc  
sh                    randconfig-001-20231207   gcc  
sh                    randconfig-002-20231207   gcc  
sh                           se7722_defconfig   gcc  
sh                           se7750_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sh                              ul2_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231207   gcc  
sparc64               randconfig-002-20231207   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231207   gcc  
um                    randconfig-002-20231207   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231207   gcc  
x86_64       buildonly-randconfig-002-20231207   gcc  
x86_64       buildonly-randconfig-003-20231207   gcc  
x86_64       buildonly-randconfig-004-20231207   gcc  
x86_64       buildonly-randconfig-005-20231207   gcc  
x86_64       buildonly-randconfig-006-20231207   gcc  
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231207   gcc  
x86_64                randconfig-012-20231207   gcc  
x86_64                randconfig-013-20231207   gcc  
x86_64                randconfig-014-20231207   gcc  
x86_64                randconfig-015-20231207   gcc  
x86_64                randconfig-016-20231207   gcc  
x86_64                randconfig-071-20231207   gcc  
x86_64                randconfig-072-20231207   gcc  
x86_64                randconfig-073-20231207   gcc  
x86_64                randconfig-074-20231207   gcc  
x86_64                randconfig-075-20231207   gcc  
x86_64                randconfig-076-20231207   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231207   gcc  
xtensa                randconfig-002-20231207   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From christophe.leroy at csgroup.eu  Thu Dec  7 08:37:04 2023
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 7 Dec 2023 16:37:04 +0000
Subject: [PATCH RFC/RFT 3/4] riscv: Stop emitting preventive sfence.vma
 for new userspace mappings
In-Reply-To: <20231207150348.82096-4-alexghiti@rivosinc.com>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
 <20231207150348.82096-4-alexghiti@rivosinc.com>
Message-ID: <e783436f-631c-4b02-ba9c-b6145e0e8b5a@csgroup.eu>

The subject says "riscv:" but it changes core part and several arch. 
Maybe this commit should be split in two commits, one for API changes 
that changes flush_tlb_fix_spurious_fault() to 
flush_tlb_fix_spurious_write_fault() and adds 
flush_tlb_fix_spurious_read_fault() including the change in memory.c, 
then a second patch with the changes to riscv.

Le 07/12/2023 ? 16:03, Alexandre Ghiti a ?crit?:
> The preventive sfence.vma were emitted because new mappings must be made
> visible to the page table walker, either the uarch caches invalid
> entries or not.
> 
> Actually, there is no need to preventively sfence.vma on new mappings for
> userspace, this should be handled only in the page fault path.
> 
> This allows to drastically reduce the number of sfence.vma emitted:
> 
> * Ubuntu boot to login:
> Before: ~630k sfence.vma
> After:  ~200k sfence.vma
> 
> * ltp - mmapstress01
> Before: ~45k
> After:  ~6.3k
> 
> * lmbench - lat_pagefault
> Before: ~665k
> After:   832 (!)
> 
> * lmbench - lat_mmap
> Before: ~546k
> After:   718 (!)
> 
> The only issue with the removal of sfence.vma in update_mmu_cache() is
> that on uarchs that cache invalid entries, those won't be invalidated
> until the process takes a fault: so that's an additional fault in those
> cases.
> 
> Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
> ---
>   arch/arm64/include/asm/pgtable.h              |  2 +-
>   arch/mips/include/asm/pgtable.h               |  6 +--
>   arch/powerpc/include/asm/book3s/64/tlbflush.h |  8 ++--
>   arch/riscv/include/asm/pgtable.h              | 43 +++++++++++--------
>   include/linux/pgtable.h                       |  8 +++-
>   mm/memory.c                                   | 12 +++++-
>   6 files changed, 48 insertions(+), 31 deletions(-)

Did you forget mm/pgtable-generic.c ?

> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 7f7d9b1df4e5..728f25f529a5 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -57,7 +57,7 @@ static inline bool arch_thp_swp_supported(void)
>    * fault on one CPU which has been handled concurrently by another CPU
>    * does not need to perform additional invalidation.
>    */
> -#define flush_tlb_fix_spurious_fault(vma, address, ptep) do { } while (0)
> +#define flush_tlb_fix_spurious_write_fault(vma, address, ptep) do { } while (0)

Why do you need to do that change ? Nothing is explained about that in 
the commit message.

>   
>   /*
>    * ZERO_PAGE is a global shared page that is always zero: used
> diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
> index 430b208c0130..84439fe6ed29 100644
> --- a/arch/mips/include/asm/pgtable.h
> +++ b/arch/mips/include/asm/pgtable.h
> @@ -478,9 +478,9 @@ static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
>   	return __pgprot(prot);
>   }
>   
> -static inline void flush_tlb_fix_spurious_fault(struct vm_area_struct *vma,
> -						unsigned long address,
> -						pte_t *ptep)
> +static inline void flush_tlb_fix_spurious_write_fault(struct vm_area_struct *vma,
> +						      unsigned long address,
> +						      pte_t *ptep)
>   {
>   }
>   
> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h b/arch/powerpc/include/asm/book3s/64/tlbflush.h
> index 1950c1b825b4..7166d56f90db 100644
> --- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
> +++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
> @@ -128,10 +128,10 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
>   #define flush_tlb_page(vma, addr)	local_flush_tlb_page(vma, addr)
>   #endif /* CONFIG_SMP */
>   
> -#define flush_tlb_fix_spurious_fault flush_tlb_fix_spurious_fault
> -static inline void flush_tlb_fix_spurious_fault(struct vm_area_struct *vma,
> -						unsigned long address,
> -						pte_t *ptep)
> +#define flush_tlb_fix_spurious_write_fault flush_tlb_fix_spurious_write_fault
> +static inline void flush_tlb_fix_spurious_write_fault(struct vm_area_struct *vma,
> +						      unsigned long address,
> +						      pte_t *ptep)
>   {
>   	/*
>   	 * Book3S 64 does not require spurious fault flushes because the PTE
> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> index b2ba3f79cfe9..89aa5650f104 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -472,28 +472,20 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf,
>   		struct vm_area_struct *vma, unsigned long address,
>   		pte_t *ptep, unsigned int nr)
>   {
> -	/*
> -	 * The kernel assumes that TLBs don't cache invalid entries, but
> -	 * in RISC-V, SFENCE.VMA specifies an ordering constraint, not a
> -	 * cache flush; it is necessary even after writing invalid entries.
> -	 * Relying on flush_tlb_fix_spurious_fault would suffice, but
> -	 * the extra traps reduce performance.  So, eagerly SFENCE.VMA.
> -	 */
> -	while (nr--)
> -		local_flush_tlb_page(address + nr * PAGE_SIZE);
>   }
>   #define update_mmu_cache(vma, addr, ptep) \
>   	update_mmu_cache_range(NULL, vma, addr, ptep, 1)
>   
>   #define __HAVE_ARCH_UPDATE_MMU_TLB
> -#define update_mmu_tlb update_mmu_cache
> +static inline void update_mmu_tlb(struct vm_area_struct *vma,
> +				  unsigned long address, pte_t *ptep)
> +{
> +	flush_tlb_range(vma, address, address + PAGE_SIZE);
> +}
>   
>   static inline void update_mmu_cache_pmd(struct vm_area_struct *vma,
>   		unsigned long address, pmd_t *pmdp)
>   {
> -	pte_t *ptep = (pte_t *)pmdp;
> -
> -	update_mmu_cache(vma, address, ptep);
>   }
>   
>   #define __HAVE_ARCH_PTE_SAME
> @@ -548,13 +540,26 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma,
>   					unsigned long address, pte_t *ptep,
>   					pte_t entry, int dirty)
>   {
> -	if (!pte_same(*ptep, entry))
> +	if (!pte_same(*ptep, entry)) {
>   		__set_pte_at(ptep, entry);
> -	/*
> -	 * update_mmu_cache will unconditionally execute, handling both
> -	 * the case that the PTE changed and the spurious fault case.
> -	 */
> -	return true;
> +		/* Here only not svadu is impacted */
> +		flush_tlb_page(vma, address);
> +		return true;
> +	}
> +
> +	return false;
> +}
> +
> +extern u64 nr_sfence_vma_handle_exception;
> +extern bool tlb_caching_invalid_entries;
> +
> +#define flush_tlb_fix_spurious_read_fault flush_tlb_fix_spurious_read_fault
> +static inline void flush_tlb_fix_spurious_read_fault(struct vm_area_struct *vma,
> +						     unsigned long address,
> +						     pte_t *ptep)
> +{
> +	if (tlb_caching_invalid_entries)
> +		flush_tlb_page(vma, address);
>   }
>   
>   #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index af7639c3b0a3..7abaf42ef612 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -931,8 +931,12 @@ static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
>   # define pte_accessible(mm, pte)	((void)(pte), 1)
>   #endif
>   
> -#ifndef flush_tlb_fix_spurious_fault
> -#define flush_tlb_fix_spurious_fault(vma, address, ptep) flush_tlb_page(vma, address)
> +#ifndef flush_tlb_fix_spurious_write_fault
> +#define flush_tlb_fix_spurious_write_fault(vma, address, ptep) flush_tlb_page(vma, address)
> +#endif
> +
> +#ifndef flush_tlb_fix_spurious_read_fault
> +#define flush_tlb_fix_spurious_read_fault(vma, address, ptep)
>   #endif
>   
>   /*
> diff --git a/mm/memory.c b/mm/memory.c
> index 517221f01303..5cb0ccf0c03f 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -5014,8 +5014,16 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf)
>   		 * with threads.
>   		 */
>   		if (vmf->flags & FAULT_FLAG_WRITE)
> -			flush_tlb_fix_spurious_fault(vmf->vma, vmf->address,
> -						     vmf->pte);
> +			flush_tlb_fix_spurious_write_fault(vmf->vma, vmf->address,
> +							   vmf->pte);
> +		else
> +			/*
> +			 * With the pte_same(ptep_get(vmf->pte), entry) check
> +			 * that calls update_mmu_tlb() above, multiple threads
> +			 * faulting at the same time won't get there.
> +			 */
> +			flush_tlb_fix_spurious_read_fault(vmf->vma, vmf->address,
> +							  vmf->pte);
>   	}
>   unlock:
>   	pte_unmap_unlock(vmf->pte, vmf->ptl);

From afd at ti.com  Thu Dec  7 08:44:52 2023
From: afd at ti.com (Andrew Davis)
Date: Thu, 7 Dec 2023 10:44:52 -0600
Subject: [PATCH 3/3] arm64: dts: ti: k3-am642-evm: add overlay for icssg1
 2nd port
In-Reply-To: <7323e86b-939a-4fd0-aac8-07fa47e00c9d@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-4-danishanwar@ti.com>
 <20231207132758.wbfn7timsqevdjpu@mortuary>
 <7323e86b-939a-4fd0-aac8-07fa47e00c9d@ti.com>
Message-ID: <b913dc5d-0dc1-478b-b4ca-cc049c3df58d@ti.com>

On 12/7/23 8:06 AM, Anwar, Md Danish wrote:
> On 12/7/2023 6:57 PM, Nishanth Menon wrote:
>> On 13:49-20231207, MD Danish Anwar wrote:
>>> The am642-evm doesn't allow to enable 2 x CPSW3g ports and 2 x ICSSG1 ports
>>> all together, so base k3-am642-evm.dts enables by default 2 x CPSW3g ports
>>> and 1 x ICSSG1 ports, but it also possible to support 1 x CPSW3g ports and
>>> 2 x ICSSG1 ports configuration.
>>>
>>> This patch adds overlay to support 1 x CPSW3g ports and 2 x ICSSG1 ports
>>> configuration:
>>> - disable 2nd CPSW3g port
>>> - update CPSW3g pinmuxes to not use RGMII2
>>> - disable mdio-mux-1 and define mdio-mux-2 to route ICSSG1 MDIO to the
>>>    shared DP83869 PHY
>>> - add and enable ICSSG1 RGMII2 pinmuxes
>>> - enable ICSSG1 MII1 port
>>>
>>> Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
>>> ---
>>>   arch/arm64/boot/dts/ti/Makefile               |  2 +
>>>   .../dts/ti/k3-am642-evm-icssg1-dualemac.dtso  | 80 +++++++++++++++++++
>>>   arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  2 +-
>>>   3 files changed, 83 insertions(+), 1 deletion(-)
>>>   create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
>>> index 5ef49b02c71f..99a4dce47f02 100644
>>> --- a/arch/arm64/boot/dts/ti/Makefile
>>> +++ b/arch/arm64/boot/dts/ti/Makefile
>>> @@ -35,12 +35,14 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62x-sk-csi2-imx219.dtbo
>>>   dtb-$(CONFIG_ARCH_K3) += k3-am62x-sk-hdmi-audio.dtbo
>>>   
>>>   # Boards with AM64x SoC
>>> +k3-am642-evm-icssg1-dtbs := k3-am642-evm.dtb k3-am642-evm-icssg1-dualemac.dtbo
>>
>> Why not handle this for CONFIG_OF_ALL_DTBS alone? See commit
>> b0044823a6607e535fdb083c89f487fbf183b171
>>
> 
> I'll have to look into this.
> 
> I am merging this k3-am642-evm-icssg1-dualemac.dtbo with
> k3-am642-evm.dtb because when I had posted patches for AM65x DTS, Andrew
> had commented [1] saying we should not leave orphan dtbos and every dtbo
> should be applied over some dtb by using `dtb- +=`.
> 

And my comment on not having orphan DTBOs is still true. But that was back
in September, we now have a new way of accomplishing that without needing
to produce a bunch of temporary combined DTB files, which is what Nishanth
is pointing out with CONFIG_OF_ALL_DTBS.

So, no need for `k3-am642-evm-icssg1.dtb`, you can add the overlay target
directly, then create a fake target to test DTBO application by adding to
the `dtb- += ` lines below.

Andrew

> Due to this I am applying the overlay on k3-am642-evm.dtb and creating
> new dtb k3-am642-evm-icssg1.dtb which can be used when both ICSSG1 ports
> are needed to be enabled.
> 
> [1] https://lore.kernel.org/all/ca832fe3-d5cf-b075-324b-50da40794bb7 at ti.com/
> 
>>>   dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
>>>   dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
>>>   dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
>>>   dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
>>>   dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
>>>   dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
>>> +dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-icssg1.dtb
>>>   
>>>   # Boards with AM65x SoC
>>>   k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb k3-am654-base-board-rocktech-rk101-panel.dtbo
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>>> new file mode 100644
>>> index 000000000000..6f33290c1ad6
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>>> @@ -0,0 +1,80 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/**
>>> + * DT overlay for enabling 2nd ICSSG1 port on AM642 EVM
>>> + *
>>> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
>>> + */
>>> +
>>> +/dts-v1/;
>>> +/plugin/;
>>> +
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +#include "k3-pinctrl.h"
>>> +
>>> +&{/} {
>>> +	aliases {
>>> +		ethernet1 = "/icssg1-eth/ethernet-ports/port at 0";
>>> +		ethernet2 = "/icssg1-eth/ethernet-ports/port at 1";
>>
>> I don't understand what you are overriding here. isn't patch #2 in your
>> series already introducing this in the base dts?
>>
> 
> Sorry, My bad. I will remove this in v2.
> 
>>> +	};
>>> +
>>> +	mdio-mux-2 {
>>> +		compatible = "mdio-mux-multiplexer";
>>> +		mux-controls = <&mdio_mux>;
>>> +		mdio-parent-bus = <&icssg1_mdio>;
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +
>>> +		mdio at 0 {
>>> +			reg = <0x0>;
>>> +			#address-cells = <1>;
>>> +			#size-cells = <0>;
>>> +
>>> +			icssg1_phy2: ethernet-phy at 3 {
>>> +				reg = <3>;
>>> +				tx-internal-delay-ps = <250>;
>>> +				rx-internal-delay-ps = <2000>;
>>> +			};
>>> +		};
>>> +	};
>>> +};
>>> +
>>> +&main_pmx0 {
>>> +	icssg1_rgmii2_pins_default: icssg1-rgmii2-default-pins {
>>> +		pinctrl-single,pins = <
>>> +			AM64X_IOPAD(0x0108, PIN_INPUT, 2) /* (W11) PRG1_PRU1_GPO0.RGMII2_RD0 */
>>> +			AM64X_IOPAD(0x010c, PIN_INPUT, 2) /* (V11) PRG1_PRU1_GPO1.RGMII2_RD1 */
>>> +			AM64X_IOPAD(0x0110, PIN_INPUT, 2) /* (AA12) PRG1_PRU1_GPO2.RGMII2_RD2 */
>>> +			AM64X_IOPAD(0x0114, PIN_INPUT, 2) /* (Y12) PRG1_PRU1_GPO3.RGMII2_RD3 */
>>> +			AM64X_IOPAD(0x0120, PIN_INPUT, 2) /* (U11) PRG1_PRU1_GPO6.RGMII2_RXC */
>>> +			AM64X_IOPAD(0x0118, PIN_INPUT, 2) /* (W12) PRG1_PRU1_GPO4.RGMII2_RX_CTL */
>>> +			AM64X_IOPAD(0x0134, PIN_OUTPUT, 2) /* (AA10) PRG1_PRU1_GPO11.RGMII2_TD0 */
>>> +			AM64X_IOPAD(0x0138, PIN_OUTPUT, 2) /* (V10) PRG1_PRU1_GPO12.RGMII2_TD1 */
>>> +			AM64X_IOPAD(0x013c, PIN_OUTPUT, 2) /* (U10) PRG1_PRU1_GPO13.RGMII2_TD2 */
>>> +			AM64X_IOPAD(0x0140, PIN_OUTPUT, 2) /* (AA11) PRG1_PRU1_GPO14.RGMII2_TD3 */
>>> +			AM64X_IOPAD(0x0148, PIN_OUTPUT, 2) /* (Y10) PRG1_PRU1_GPO16.RGMII2_TXC */
>>> +			AM64X_IOPAD(0x0144, PIN_OUTPUT, 2) /* (Y11) PRG1_PRU1_GPO15.RGMII2_TX_CTL */
>>> +		>;
>>> +	};
>>> +};
>>> +
>>> +&cpsw3g {
>>> +	pinctrl-0 = <&rgmii1_pins_default>;
>>> +};
>>> +
>>> +&cpsw_port2 {
>>> +	status = "disabled";
>>> +};
>>> +
>>> +&mdio_mux_1 {
>>> +	status = "disabled";
>>> +};
>>> +
>>> +&icssg1_eth {
>>> +	pinctrl-0 = <&icssg1_rgmii1_pins_default &icssg1_rgmii2_pins_default>;
>>
>> Grrr... No! I have been cleaning up after you folks and you folks should
>> take notice.
>>
>> pinctrl-0 = <&icssg1_rgmii1_pins_default>, <&icssg1_rgmii2_pins_default>;
>>
> 
> Sorry, I was not aware of this. I will change it in v2.
> 
>>
>>> +};
>>> +
>>> +&icssg1_emac1 {
>>> +	status = "okay";
>>> +	phy-handle = <&icssg1_phy2>;
>>> +	phy-mode = "rgmii-id";
>>> +};
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>>> index 04d1c0602d31..90867090e725 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>>> @@ -203,7 +203,7 @@ mdio_mux: mux-controller {
>>>   		mux-gpios = <&exp1 12 GPIO_ACTIVE_HIGH>;
>>>   	};
>>>   
>>> -	mdio-mux-1 {
>>> +	mdio_mux_1: mdio-mux-1 {
>>
>> Commit message doesn't warn me for this change.
> 
> Sure. I will add details of this in commit message saying `Add label
> name 'mdio_mux_1' for 'mdio-mux-1' node so that the node 'mdio-mux-1'
> can be disabled in the overlay using the label name.`
> 
>>>   		compatible = "mdio-mux-multiplexer";
>>>   		mux-controls = <&mdio_mux>;
>>>   		mdio-parent-bus = <&cpsw3g_mdio>;
>>> -- 
>>> 2.34.1
>>>
>>
> 


From broonie at kernel.org  Thu Dec  7 08:57:37 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 7 Dec 2023 16:57:37 +0000
Subject: [PATCH v2 01/12] KVM: Add missing HCRX_EL2 field definitions
In-Reply-To: <20231206100503.564090-2-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
 <20231206100503.564090-2-tabba@google.com>
Message-ID: <7c85421b-5dfd-4931-bb14-aa2416e54b58@sirena.org.uk>

On Wed, Dec 06, 2023 at 10:04:51AM +0000, Fuad Tabba wrote:
> Add the latest field definitions to HCRX_EL2 from the 2023-09 Arm
> Architecture System Registers xml specification [*].
> 
> These fields aren't used yet. This is done mainly to get the
> correct generated value for the register's RES0 mask.

> ---
>  arch/arm64/tools/sysreg | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

This isn't a KVM specific patch, this is an arch patch - I'd have
expected a subject line "arm64/sysreg:" or something...

>  Sysreg	HCRX_EL2	3	4	1	2	2
> -Res0	63:23
> +Res0	63:25
> +Field	24	PACMEn
> +Field	23	EnFPM
>  Field	22	GCSEn
>  Field	21	EnIDCP128
>  Field	20	EnSDERR

This is the same as my equivalent patch in the 2023 dpISA series:

   https://lore.kernel.org/linux-arm-kernel/20231205-arm64-2023-dpisa-v3-7-dbcbcd867a7f at kernel.org/

Reviewed-by: Mark Brown <broonie at kernel.org>

(that series does make use of EnFPM).  Given the likelyhood of overlaps
like this I really think we should be merging these sysreg updates even
if the serieses that depend on them are still in flight, it doesn't make
sense for multiple people to end up doing the typing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/fae19210/attachment.sig>

From krzysztof.kozlowski at linaro.org  Thu Dec  7 08:59:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 17:59:08 +0100
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-in-suspend property
In-Reply-To: <20231207111300.80581-2-eichest@gmail.com>
References: <20231207111300.80581-1-eichest@gmail.com>
 <20231207111300.80581-2-eichest@gmail.com>
Message-ID: <b9868bd4-6f14-4628-88ea-56d06027739e@linaro.org>

On 07/12/2023 12:12, Stefan Eichenberger wrote:
> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> index c40799355ed7..047a5101341c 100644
> --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> @@ -87,6 +87,12 @@ properties:
>        - 2 # ATMEL_MXT_WAKEUP_GPIO
>      default: 0
>  
> +  atmel,poweroff-in-suspend:
> +    description: |
> +      When this property is set, all supplies are turned off when the system is
> +      going to suspend.

You described the desired Linux feature or behavior, not the actual
hardware. The bindings are about the latter, so instead you need to
rephrase the property and its description to match actual hardware
capabilities/features/configuration etc.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec  7 09:03:44 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 18:03:44 +0100
Subject: [PATCH v3 2/4] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <ZXBs9GOOOlZrMuSW@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
 <def05aac79ddff872d3e56698b736cb445f14116.1701823757.git.daniel@makrotopia.org>
 <3e72bff6-9f4d-4cd4-845e-b065f1233ec6@collabora.com>
 <ZXBs9GOOOlZrMuSW@makrotopia.org>
Message-ID: <64ee48fc-4f77-48cc-b235-c9fb2b10afc4@linaro.org>

On 06/12/2023 13:45, Daniel Golle wrote:
>>> +properties:
>>> +  compatible:
>>> +    items:
>>> +      - const: mediatek,mt7988-ethwarp
>>> +      - const: syscon
>>> +      - const: simple-mfd
>>
>> No, this is not a mfd, I say.
>>
>> Prove me wrong! :-)
> 
> https://github.com/dangowrt/linux/blob/mt7988-for-next/arch/arm64/boot/dts/mediatek/mt7988a.dtsi#L564
> 
> The 'simple-mfd' compatible is required to have the Linux
> kernel probe drivers for sub-nodes -- several drivers will act on
> the different aspects of the circuit exposed at this memory range.
> From what I understand, this is the definition of a MFD.

We know what is MFD, so no need to teach us. We expect you to look at
this. You do not have subnodes, so MFD is pointless. Showing DTSI means
nothing except that you did not test your bindings.

Best regards,
Krzysztof



From broonie at kernel.org  Thu Dec  7 09:06:08 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 7 Dec 2023 17:06:08 +0000
Subject: [PATCH v2 02/12] KVM: arm64: Add latest HFGxTR_EL2 FGT entries
 to nested virt
In-Reply-To: <20231206100503.564090-3-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
 <20231206100503.564090-3-tabba@google.com>
Message-ID: <13427a09-025b-414c-adad-6a13c58df54e@sirena.org.uk>

On Wed, Dec 06, 2023 at 10:04:52AM +0000, Fuad Tabba wrote:

> +#define SYS_GCSCR_EL1			sys_reg(3, 0, 2, 5, 0)
> +#define SYS_GCSPR_EL1			sys_reg(3, 0, 2, 5, 1)
> +#define SYS_GCSCRE0_EL1			sys_reg(3, 0, 2, 5, 2)
> +

> +#define SYS_GCSPR_EL0			sys_reg(3, 3, 2, 5, 1)
> +

Unless there's some complication with representing them (mainly register
layouts that aren't representable with the language or *very* repetitive
blocks of registers) we should be adding any new sysregs to the sysreg
file rather than manually encoding them.  We're trying to move things
out of sysreg.h as much as possible.

For the above you can pick up the patch from my GCS series:

  https://lore.kernel.org/linux-arm-kernel/20231122-arm64-gcs-v7-6-201c483bd775 at kernel.org/

> @@ -412,6 +423,8 @@
>  #define SYS_PMUSERENR_EL0		sys_reg(3, 3, 9, 14, 0)
>  #define SYS_PMOVSSET_EL0		sys_reg(3, 3, 9, 14, 3)
>  
> +#define SYS_POR_EL0			sys_reg(3, 3, 10, 2, 4)
> +

This is in Joey's POR series:

  https://lore.kernel.org/linux-arm-kernel/20231124163510.1835740-2-joey.gouly at arm.com/

Unfortunately I'm not aware of anyone having already done the rest.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/ccd1661a/attachment.sig>

From Frank.li at nxp.com  Thu Dec  7 09:10:26 2023
From: Frank.li at nxp.com (Frank Li)
Date: Thu, 7 Dec 2023 12:10:26 -0500
Subject: [PATCH 3/9] PCI: imx6: Simplify reset handling by using by using
 *_FLAG_HAS_*_RESET
In-Reply-To: <e314466b31dd8e88212ae5d7ac2fecf26b851829.camel@pengutronix.de>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
 <20231206155903.566194-4-Frank.Li@nxp.com>
 <e314466b31dd8e88212ae5d7ac2fecf26b851829.camel@pengutronix.de>
Message-ID: <ZXH8guDh+pLbg0Tn@lizhi-Precision-Tower-5810>

On Wed, Dec 06, 2023 at 05:52:23PM +0100, Philipp Zabel wrote:
> Hi Frank,
> 
> On Mi, 2023-12-06 at 10:58 -0500, Frank Li wrote:
> > Refactors the reset handling logic in the imx6 PCI driver by adding
> > IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.
> > 
> > The drvdata::flags and a bitmask ensures a cleaner and more scalable
> > switch-case structure for handling reset.
> > 
> > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > ---
> >  drivers/pci/controller/dwc/pci-imx6.c | 115 +++++++++++---------------
> >  1 file changed, 47 insertions(+), 68 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> > index bcf52aa86462..62d77fabd82a 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> [...]
> > @@ -696,18 +698,13 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
> >  
> >  static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
> >  {
> > -	switch (imx6_pcie->drvdata->variant) {
> > -	case IMX7D:
> > -	case IMX8MQ:
> > -	case IMX8MQ_EP:
> > +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET))
> 
> This check is not strictly necessary. If the flag is not set,
> imx6_pcie->pciephy_reset is guaranteed to be NULL, and then
> reset_control_assert() is a no-op. Same for the other (de)assert
> calls below.
> 
> [...]
> 
> > @@ -1335,36 +1319,24 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> >  					     "failed to get pcie phy\n");
> >  	}
> >  
> > -	switch (imx6_pcie->drvdata->variant) {
> > -	case IMX7D:
> > -		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> > -			imx6_pcie->controller_id = 1;
> > -
> > -		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
> > -									    "pciephy");
> > -		if (IS_ERR(imx6_pcie->pciephy_reset)) {
> > -			dev_err(dev, "Failed to get PCIEPHY reset control\n");
> > -			return PTR_ERR(imx6_pcie->pciephy_reset);
> > -		}
> > -
> > -		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> > -									 "apps");
> > -		if (IS_ERR(imx6_pcie->apps_reset)) {
> > -			dev_err(dev, "Failed to get PCIE APPS reset control\n");
> > -			return PTR_ERR(imx6_pcie->apps_reset);
> > -		}
> > -		break;
> > -	case IMX8MM:
> > -	case IMX8MM_EP:
> > -	case IMX8MP:
> > -	case IMX8MP_EP:
> > -		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> > -									 "apps");
> > +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET)) {
> > +		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev, "apps");
> [...]
> 
> I wonder whether we should just defer the check whether apps/pciephy
> resets should be used to the device tree validation, and make this an
> unconditional call to get an optional reset control:
> 
> 	imx6_pcie->apps_reset = devm_reset_control_get_optional_exclusive(dev, "apps");

I think double check here is neccesary. No sure if dts file version
binding yaml was exactly matched driver. Sometime user use old version dts. 
Double check here will help identify the dts problem. 

Frank 
> 
> regards
> Philipp


From joey.gouly at arm.com  Thu Dec  7 09:12:37 2023
From: joey.gouly at arm.com (Joey Gouly)
Date: Thu, 7 Dec 2023 17:12:37 +0000
Subject: [PATCH v2 06/12] KVM: arm64: Update and fix FGT register masks
In-Reply-To: <CA+EHjTwC+66GyPma00XQ6VRzktYzxB7XXr+7zSKFrG6U-+EeEQ@mail.gmail.com>
References: <20231206100503.564090-1-tabba@google.com>
 <20231206100503.564090-7-tabba@google.com>
 <20231207150001.GA29745@e124191.cambridge.arm.com>
 <CA+EHjTwC+66GyPma00XQ6VRzktYzxB7XXr+7zSKFrG6U-+EeEQ@mail.gmail.com>
Message-ID: <20231207171237.GA87398@e124191.cambridge.arm.com>

On Thu, Dec 07, 2023 at 03:06:44PM +0000, Fuad Tabba wrote:
> Hi Joey,
> 
> On Thu, Dec 7, 2023 at 3:00?PM Joey Gouly <joey.gouly at arm.com> wrote:
> >
> > Hello Fuad,
> >
> > On Wed, Dec 06, 2023 at 10:04:56AM +0000, Fuad Tabba wrote:
> > > New trap bits have been defined in the 2023-09 Arm Architecture
> > > System Registers xml specification [*]. Moreover, the existing
> > > definitions of some of the mask and the RES0 bits overlap, which
> > > could be wrong, confusing, or both.
> > >
> > > Update the bits to represent the latest spec (as of this patch,
> > > 2023-09), and ensure that the existing bits are consistent.
> > >
> > > Subsequent patches will use the generated RES0 fields instead of
> > > specifying them manually. This patch keeps the manual encoding of
> > > the bits to make it easier to review the series.
> > >
> > > [*] https://developer.arm.com/downloads/-/exploration-tools
> > >
> > > Fixes: 0fd76865006d ("KVM: arm64: Add nPIR{E0}_EL1 to HFG traps")
> > > Signed-off-by: Fuad Tabba <tabba at google.com>
> > > ---
> > >  arch/arm64/include/asm/kvm_arm.h | 39 ++++++++++++++++++++------------
> > >  1 file changed, 24 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> > > index 7de0a7062625..b0dc3249d5cd 100644
> > > --- a/arch/arm64/include/asm/kvm_arm.h
> > > +++ b/arch/arm64/include/asm/kvm_arm.h
> > > @@ -344,30 +344,39 @@
> > >   * Once we get to a point where the two describe the same thing, we'll
> > >   * merge the definitions. One day.
> > >   */
> > > -#define __HFGRTR_EL2_RES0    (GENMASK(63, 56) | GENMASK(53, 51))
> > > +#define __HFGRTR_EL2_RES0    BIT(51)
> > >  #define __HFGRTR_EL2_MASK    GENMASK(49, 0)
> > > -#define __HFGRTR_EL2_nMASK   (GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> > > +#define __HFGRTR_EL2_nMASK   (GENMASK(63, 52) | BIT(50))
> > >
> > > -#define __HFGWTR_EL2_RES0    (GENMASK(63, 56) | GENMASK(53, 51) |    \
> > > -                              BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
> > > -                              GENMASK(26, 25) | BIT(21) | BIT(18) |  \
> > > +#define __HFGWTR_EL2_RES0    (BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
> > > +                              BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
> > >                                GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
> > > -#define __HFGWTR_EL2_MASK    GENMASK(49, 0)
> > > -#define __HFGWTR_EL2_nMASK   (GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> > > +#define __HFGWTR_EL2_MASK    (GENMASK(49, 47) | GENMASK(45, 43) | \
> > > +                              BIT(41) | GENMASK(39, 29) | BIT(27) | \
> > > +                              GENMASK(24, 22) | GENMASK(20, 19) | \
> > > +                              GENMASK(17, 16) | GENMASK(13, 11) | \
> > > +                              GENMASK(8, 3) | GENMASK(1, 0))
> > > +#define __HFGWTR_EL2_nMASK   (GENMASK(63, 52) | BIT(50))
> >
> > By adding all these bits to *_nMASK, we're allowing a guest to access registers
> > which KVM doesn't (currently) deal with.  For example if I apply this patch
> > series, a guest can access S2POR_EL1, previously it would print something like:
> >
> >         kvm [80]: Unsupported guest sys_reg access at: ffffc42969c1f270 [600000c5]
> >          { Op0( 3), Op1( 0), CRn(10), CRm( 2), Op2( 5), func_read },
> >
> > After applying this patch series, the guest can read S2POR_EL1.
> >
> > We don't expose S2POE to the guest through ID_AA64MMFR3_EL1, so a well behaved
> > guest shouldn't access it, but there's nothing stopping it.
> >
> > My question is, is this intended? Or do we need to update the following code
> > (and comment!) to trap all the stuff we don't currently handle (along with
> > ACCDATA_EL1):
> 
> Thanks for pointing this out, and no, it's not intended. For
> consistency, I think it might be good to update the code, as you
> suggest, to prevent these accesses. If you and the other reviewers are
> happy with that solution I can respin with your suggested fix. I have
> a couple of other minor fixes as well for the series.
> 

Thanks for clarifying that.

To me it seems weird to use the generated bits directly, and I think that's why
the code seems confusing?

I think we should stop using __HFGRTR_EL2_nMASK directly in that function, and
build it up from '0'. This also matches, I think, with Marc Z wanting to move
towards setting these things based on features [1], so maybe something like:

	u64 r_val = 0;

	if (cpus_have_final_cap(ARM64_HAS_S1PIE))
		r_set |= HFGxTR_EL2_nPIR_EL1 | HFGxTR_EL2_nPIREO_EL1;

	r_val |= r_set;
	r_val &= ~r_clr;

	write_sysreg_s(r_val, SYS_HFGRTR_EL2);

That way we just explicitly set which bits we don't want to trap on. We have
some weird behaviour right now were we set nSMPRI_EL1 to 1, unless you have
FEAT_SME where we set it to 0.. but if you don't have FEAT_SME it's RES0
anyway? The above approach would fix that.

Thanks,
Joey

[1] https://lore.kernel.org/linux-arm-kernel/87bkb285ud.wl-maz at kernel.org/ (last paragraph)

> 
> Cheers,
> /fuad
> 
> 
> >
> >         static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
> >         {
> >
> >                 ..
> >
> >                 /* The default is not to trap anything but ACCDATA_EL1 */
> >                 r_val = __HFGRTR_EL2_nMASK & ~HFGxTR_EL2_nACCDATA_EL1;
> >                 r_val |= r_set;
> >                 r_val &= ~r_clr;
> >
> >
> > Thanks,
> > Joey
> >
> > >
> > > -#define __HFGITR_EL2_RES0    GENMASK(63, 57)
> > > -#define __HFGITR_EL2_MASK    GENMASK(54, 0)
> > > -#define __HFGITR_EL2_nMASK   GENMASK(56, 55)
> > > +#define __HFGITR_EL2_RES0    (BIT(63) | BIT(61))
> > > +#define __HFGITR_EL2_MASK    (BIT(62) | BIT(60) | GENMASK(54, 0))
> > > +#define __HFGITR_EL2_nMASK   GENMASK(59, 55)
> > >
> > >  #define __HDFGRTR_EL2_RES0   (BIT(49) | BIT(42) | GENMASK(39, 38) |  \
> > >                                GENMASK(21, 20) | BIT(8))
> > > -#define __HDFGRTR_EL2_MASK   ~__HDFGRTR_EL2_nMASK
> > > +#define __HDFGRTR_EL2_MASK   (BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
> > > +                              GENMASK(41, 40) | GENMASK(37, 22) | \
> > > +                              GENMASK(19, 9) | GENMASK(7, 0))
> > >  #define __HDFGRTR_EL2_nMASK  GENMASK(62, 59)
> > >
> > >  #define __HDFGWTR_EL2_RES0   (BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
> > >                                BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
> > >                                BIT(22) | BIT(9) | BIT(6))
> > > -#define __HDFGWTR_EL2_MASK   ~__HDFGWTR_EL2_nMASK
> > > +#define __HDFGWTR_EL2_MASK   (GENMASK(57, 52) | GENMASK(50, 48) | \
> > > +                              GENMASK(46, 44) | GENMASK(42, 41) | \
> > > +                              GENMASK(37, 35) | GENMASK(33, 31) | \
> > > +                              GENMASK(29, 23) | GENMASK(21, 10) | \
> > > +                              GENMASK(8, 7) | GENMASK(5, 0))
> > >  #define __HDFGWTR_EL2_nMASK  GENMASK(62, 60)
> > >
> > >  #define __HAFGRTR_EL2_RES0   (GENMASK(63, 50) | GENMASK(16, 5))
> > > @@ -375,9 +384,9 @@
> > >  #define __HAFGRTR_EL2_nMASK  0UL
> > >
> > >  /* Similar definitions for HCRX_EL2 */
> > > -#define __HCRX_EL2_RES0              (GENMASK(63, 16) | GENMASK(13, 12))
> > > -#define __HCRX_EL2_MASK              (0)
> > > -#define __HCRX_EL2_nMASK     (GENMASK(15, 14) | GENMASK(4, 0))
> > > +#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
> > > +#define __HCRX_EL2_MASK              (BIT(6))
> > > +#define __HCRX_EL2_nMASK     (GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
> > >
> > >  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
> > >  #define HPFAR_MASK   (~UL(0xf))
> > > --
> > > 2.43.0.rc2.451.g8631bc7472-goog
> > >
> > >


From conor at kernel.org  Thu Dec  7 09:12:57 2023
From: conor at kernel.org (Conor Dooley)
Date: Thu, 7 Dec 2023 17:12:57 +0000
Subject: [PATCH v7 2/3] dt-bindings: arm64: add Marvell COM Express boards
In-Reply-To: <20231207143248.2439926-3-enachman@marvell.com>
References: <20231207143248.2439926-1-enachman@marvell.com>
 <20231207143248.2439926-3-enachman@marvell.com>
Message-ID: <20231207-dallying-tablet-c5f32f91373c@spud>

On Thu, Dec 07, 2023 at 04:32:47PM +0200, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> Add dt bindings for:
> CN9130 COM Express CPU module
> CN9131 COM Express CPU module
> AC5X RD COM Express Type 7 carrier board.
> AC5X RD COM Express board with a CN9131 COM Express Type 7 CPU module.
> 
> Signed-off-by: Elad Nachman <enachman at marvell.com>
> ---
>  .../bindings/arm/marvell/armada-7k-8k.yaml    | 24 +++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> index 52d78521e412..d00866aeaa8d 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> @@ -60,4 +60,28 @@ properties:
>            - const: marvell,armada-ap807-quad
>            - const: marvell,armada-ap807
>  
> +      - description:
> +          Alleycat5X (98DX35xx) Reference Design as COM Express Carrier plus
> +          Armada CN9130 COM Express CPU module
> +        items:
> +          - enum:
> +              - marvell,cn9130-ac5x-carrier

There's so many compatibles here that it is a bit hard for me to follow,
but I am wondering why you have the "enum" here.
The description seems to define this as being for one specific carrier
and you have two entries here for carriers compatible with the rd-ac5x.
It looks like you should either a) combine both of these or b) swap the
enum for const.

Thanks,
Conor.

> +          - const: marvell,rd-ac5x-carrier
> +          - const: marvell,cn9130-cpu-module
> +          - const: marvell,cn9130
> +          - const: marvell,armada-ap807-quad
> +          - const: marvell,armada-ap807
> +
> +      - description:
> +          Alleycat5X (98DX35xx) Reference Design as COM Express Carrier plus
> +          Armada CN9131 COM Express CPU module
> +        items:
> +          - enum:
> +              - marvell,cn9131-ac5x-carrier
> +          - const: marvell,rd-ac5x-carrier
> +          - const: marvell,cn9131-cpu-module
> +          - const: marvell,cn9131
> +          - const: marvell,armada-ap807-quad
> +          - const: marvell,armada-ap807
> +
>  additionalProperties: true
> -- 
> 2.25.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/df301c6e/attachment.sig>

From broonie at kernel.org  Thu Dec  7 09:14:21 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 7 Dec 2023 17:14:21 +0000
Subject: [PATCH v2 03/12] KVM: arm64: Add latest HFGITR_EL2 FGT entries
 to nested virt
In-Reply-To: <20231206100503.564090-4-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
 <20231206100503.564090-4-tabba@google.com>
Message-ID: <bbe3b916-9db3-403c-acdf-8472c750bfcd@sirena.org.uk>

On Wed, Dec 06, 2023 at 10:04:53AM +0000, Fuad Tabba wrote:

> Add the missing nested virt FGT table entries HFGITR_EL2. Based
> on the 2023-09 Arm Architecture System Registers xml
> specification [*]. Add the missing field definitions as well,
> both to generate the correct RES0 mask and to be able to toggle
> their FGT bits.
> 
> Also adds definitions of some of the missing system registers and
> instructions, which can be trapped by the FGT bits.
> 
> [*] https://developer.arm.com/downloads/-/exploration-tools

That should be a reference to DDI0602 (for the instruction XML) and
DD0601 (for the system register XML) - it's the same content, just a
more stable name.

>  Sysreg HFGITR_EL2	3	4	1	1	6
> -Res0	63:61
> +Res0	63
> +Field	62	ATS1E1A
> +Res0	61
>  Field	60	COSPRCTX
>  Field	59	nGCSEPP
>  Field	58	nGCSSTR_EL1

The sysreg looks good:

Reviewed-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/f6d62a73/attachment.sig>

From lkp at intel.com  Thu Dec  7 09:16:54 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 08 Dec 2023 01:16:54 +0800
Subject: [soc:for-next] BUILD SUCCESS
 5c69f40cff48709e8beafa081759f1e23094f247
Message-ID: <202312080151.EkPiUmg1-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 5c69f40cff48709e8beafa081759f1e23094f247  soc: document merges

elapsed time: 1452m

configs tested: 185
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231207   gcc  
arc                   randconfig-002-20231207   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                                 defconfig   clang
arm                           h3600_defconfig   gcc  
arm                      jornada720_defconfig   gcc  
arm                        multi_v7_defconfig   gcc  
arm                   randconfig-001-20231207   gcc  
arm                   randconfig-002-20231207   gcc  
arm                   randconfig-003-20231207   gcc  
arm                   randconfig-004-20231207   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231207   gcc  
arm64                 randconfig-002-20231207   gcc  
arm64                 randconfig-003-20231207   gcc  
arm64                 randconfig-004-20231207   gcc  
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231207   gcc  
csky                  randconfig-002-20231207   gcc  
hexagon                          allmodconfig   clang
hexagon                           allnoconfig   clang
hexagon                          allyesconfig   clang
hexagon                             defconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231207   gcc  
i386         buildonly-randconfig-002-20231207   gcc  
i386         buildonly-randconfig-003-20231207   gcc  
i386         buildonly-randconfig-004-20231207   gcc  
i386         buildonly-randconfig-005-20231207   gcc  
i386         buildonly-randconfig-006-20231207   gcc  
i386                                defconfig   gcc  
i386                  randconfig-001-20231207   gcc  
i386                  randconfig-002-20231207   gcc  
i386                  randconfig-003-20231207   gcc  
i386                  randconfig-004-20231207   gcc  
i386                  randconfig-005-20231207   gcc  
i386                  randconfig-006-20231207   gcc  
i386                  randconfig-011-20231207   clang
i386                  randconfig-012-20231207   clang
i386                  randconfig-013-20231207   clang
i386                  randconfig-014-20231207   clang
i386                  randconfig-015-20231207   clang
i386                  randconfig-016-20231207   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231207   gcc  
loongarch             randconfig-002-20231207   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5272c3_defconfig   gcc  
m68k                        mvme147_defconfig   gcc  
m68k                        stmark2_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
mips                       bmips_be_defconfig   gcc  
mips                           ci20_defconfig   gcc  
mips                           ip27_defconfig   gcc  
mips                      loongson3_defconfig   gcc  
mips                         rt305x_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231207   gcc  
nios2                 randconfig-002-20231207   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231207   gcc  
parisc                randconfig-002-20231207   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                      ep88xc_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                     mpc83xx_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc               randconfig-001-20231207   gcc  
powerpc               randconfig-002-20231207   gcc  
powerpc               randconfig-003-20231207   gcc  
powerpc                    socrates_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
powerpc64             randconfig-001-20231207   gcc  
powerpc64             randconfig-002-20231207   gcc  
powerpc64             randconfig-003-20231207   gcc  
riscv                            allmodconfig   gcc  
riscv                             allnoconfig   clang
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231207   gcc  
riscv                 randconfig-002-20231207   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                         ap325rxa_defconfig   gcc  
sh                                  defconfig   gcc  
sh                        dreamcast_defconfig   gcc  
sh                         ecovec24_defconfig   gcc  
sh                    randconfig-001-20231207   gcc  
sh                    randconfig-002-20231207   gcc  
sh                           se7722_defconfig   gcc  
sh                           se7750_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sh                              ul2_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231207   gcc  
sparc64               randconfig-002-20231207   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231207   gcc  
um                    randconfig-002-20231207   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231207   gcc  
x86_64       buildonly-randconfig-002-20231207   gcc  
x86_64       buildonly-randconfig-003-20231207   gcc  
x86_64       buildonly-randconfig-004-20231207   gcc  
x86_64       buildonly-randconfig-005-20231207   gcc  
x86_64       buildonly-randconfig-006-20231207   gcc  
x86_64                              defconfig   gcc  
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231207   gcc  
x86_64                randconfig-012-20231207   gcc  
x86_64                randconfig-013-20231207   gcc  
x86_64                randconfig-014-20231207   gcc  
x86_64                randconfig-015-20231207   gcc  
x86_64                randconfig-016-20231207   gcc  
x86_64                randconfig-071-20231207   gcc  
x86_64                randconfig-072-20231207   gcc  
x86_64                randconfig-073-20231207   gcc  
x86_64                randconfig-074-20231207   gcc  
x86_64                randconfig-075-20231207   gcc  
x86_64                randconfig-076-20231207   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231207   gcc  
xtensa                randconfig-002-20231207   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From daniel at makrotopia.org  Thu Dec  7 09:17:38 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Thu, 7 Dec 2023 17:17:38 +0000
Subject: [PATCH v3 2/4] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <64ee48fc-4f77-48cc-b235-c9fb2b10afc4@linaro.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
 <def05aac79ddff872d3e56698b736cb445f14116.1701823757.git.daniel@makrotopia.org>
 <3e72bff6-9f4d-4cd4-845e-b065f1233ec6@collabora.com>
 <ZXBs9GOOOlZrMuSW@makrotopia.org>
 <64ee48fc-4f77-48cc-b235-c9fb2b10afc4@linaro.org>
Message-ID: <ZXH-Mq_DlW5Oodwt@makrotopia.org>

On Thu, Dec 07, 2023 at 06:03:44PM +0100, Krzysztof Kozlowski wrote:
> On 06/12/2023 13:45, Daniel Golle wrote:
> >>> +properties:
> >>> +  compatible:
> >>> +    items:
> >>> +      - const: mediatek,mt7988-ethwarp
> >>> +      - const: syscon
> >>> +      - const: simple-mfd
> >>
> >> No, this is not a mfd, I say.
> >>
> >> Prove me wrong! :-)
> > 
> > https://github.com/dangowrt/linux/blob/mt7988-for-next/arch/arm64/boot/dts/mediatek/mt7988a.dtsi#L564
> > 
> > The 'simple-mfd' compatible is required to have the Linux
> > kernel probe drivers for sub-nodes -- several drivers will act on
> > the different aspects of the circuit exposed at this memory range.
> > From what I understand, this is the definition of a MFD.
> 
> We know what is MFD, so no need to teach us. We expect you to look at
> this. You do not have subnodes, so MFD is pointless. Showing DTSI means
> nothing except that you did not test your bindings.

Sorry, I simply wasn't aware that this is what I'm being asked for.
Is the device a MFD? - Yes it is.

In this case the child node would be a 'ti,syscon-reset' which doesn't
have YAML bindings. Should I include it as object without $ref or do I
need to convert ti,syscon-reset.txt to yaml first, and then reference
it as child node in the MFD?


From broonie at kernel.org  Thu Dec  7 09:19:17 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 7 Dec 2023 17:19:17 +0000
Subject: [PATCH v2 04/12] KVM: arm64: Add bit masks for HAFGRTR_EL2
In-Reply-To: <20231206100503.564090-5-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
 <20231206100503.564090-5-tabba@google.com>
Message-ID: <268ebe97-1f79-416e-805e-9a67144f6a99@sirena.org.uk>

On Wed, Dec 06, 2023 at 10:04:54AM +0000, Fuad Tabba wrote:
> To support HAFGRTR_EL2 supported in nested virt in the following
> patch, first add its bitmask definitions based on the 2023-09
> Arm Architecture System Registers xml specification [*].
> 
> [*] https://developer.arm.com/downloads/-/exploration-tools

DDI0601 is a more stable name, and I'd have expected an "arm64/sysreg"
subject.

> +#define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
> +#define __HAFGRTR_EL2_MASK	(GENMASK(49, 17) | GENMASK(4, 0))
> +#define __HAFGRTR_EL2_nMASK	0UL
> +

This one is an example of something where some manual encoding does make
sense given all the AMCNTEN<x> and so on fields so:

Reviewed-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/6b47a2fa/attachment.sig>

From krzysztof.kozlowski at linaro.org  Thu Dec  7 09:23:02 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 7 Dec 2023 18:23:02 +0100
Subject: [PATCH v3 2/4] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <ZXH-Mq_DlW5Oodwt@makrotopia.org>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
 <def05aac79ddff872d3e56698b736cb445f14116.1701823757.git.daniel@makrotopia.org>
 <3e72bff6-9f4d-4cd4-845e-b065f1233ec6@collabora.com>
 <ZXBs9GOOOlZrMuSW@makrotopia.org>
 <64ee48fc-4f77-48cc-b235-c9fb2b10afc4@linaro.org>
 <ZXH-Mq_DlW5Oodwt@makrotopia.org>
Message-ID: <5ec5ee0f-c490-418e-9d37-fdcb67325843@linaro.org>

On 07/12/2023 18:17, Daniel Golle wrote:
> On Thu, Dec 07, 2023 at 06:03:44PM +0100, Krzysztof Kozlowski wrote:
>> On 06/12/2023 13:45, Daniel Golle wrote:
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    items:
>>>>> +      - const: mediatek,mt7988-ethwarp
>>>>> +      - const: syscon
>>>>> +      - const: simple-mfd
>>>>
>>>> No, this is not a mfd, I say.
>>>>
>>>> Prove me wrong! :-)
>>>
>>> https://github.com/dangowrt/linux/blob/mt7988-for-next/arch/arm64/boot/dts/mediatek/mt7988a.dtsi#L564
>>>
>>> The 'simple-mfd' compatible is required to have the Linux
>>> kernel probe drivers for sub-nodes -- several drivers will act on
>>> the different aspects of the circuit exposed at this memory range.
>>> From what I understand, this is the definition of a MFD.
>>
>> We know what is MFD, so no need to teach us. We expect you to look at
>> this. You do not have subnodes, so MFD is pointless. Showing DTSI means
>> nothing except that you did not test your bindings.
> 
> Sorry, I simply wasn't aware that this is what I'm being asked for.
> Is the device a MFD? - Yes it is.

You need to answer this :)

> 
> In this case the child node would be a 'ti,syscon-reset' which doesn't
> have YAML bindings. Should I include it as object without $ref or do I
> need to convert ti,syscon-reset.txt to yaml first, and then reference
> it as child node in the MFD?

It would be enough to have:
  system-controller:
    properties:
      compatible:
        foo-bar
    # TODO: Convert to DT schema
    additionalProperties: true

(so no ref, but comaptible present)

Best regards,
Krzysztof



From tudor.ambarus at linaro.org  Thu Dec  7 09:24:48 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 7 Dec 2023 17:24:48 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
Message-ID: <797b9023-e56b-404b-bb4e-6e178b7ada88@linaro.org>



On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
> The current implementation assumes that a maximum of two flashes are
> connected in stacked mode and both the flashes are of same make but can
> differ in sizes. So, except the sizes all other flash parameters of both
> the flashes are identical.

Too much restrictions, isn't it? Have you thought about adding a layer
on top of SPI NOR managing the stacked/parallel flashes?


From broonie at kernel.org  Thu Dec  7 09:28:18 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 7 Dec 2023 17:28:18 +0000
Subject: [PATCH v2 05/12] KVM: arm64: Handle HAFGRTR_EL2 trapping in
 nested virt
In-Reply-To: <20231206100503.564090-6-tabba@google.com>
References: <20231206100503.564090-1-tabba@google.com>
 <20231206100503.564090-6-tabba@google.com>
Message-ID: <006ec2b0-6263-4e86-8641-d81c01a91c8e@sirena.org.uk>

On Wed, Dec 06, 2023 at 10:04:55AM +0000, Fuad Tabba wrote:

> Add the encodings to fine grain trapping fields for HAFGRTR_EL2
> and add the associated handling code in nested virt. Based on
> the 2023-09 Arm Architecture System Registers xml
> specification [*]. Add the missing field definitions as well,
> both to generate the correct RES0 mask and to be able to toggle
> their FGT bits.

> Also add the code for handling FGT trapping, reading of the
> register, to nested virt.

> [*] https://developer.arm.com/downloads/-/exploration-tools

DDI0601.

> +Sysreg HAFGRTR_EL2	3	4	3	1	6
> +Res0	63:50
> +Field	49	AMEVTYPER115_EL0
> +Field	48	AMEVCNTR115_EL0
> +Field	47	AMEVTYPER114_EL0
> +Field	46	AMEVCNTR114_EL0
> +Field	45	AMEVTYPER113_EL0
> +Field	44	AMEVCNTR113_EL0
> +Field	43	AMEVTYPER112_EL0
> +Field	42	AMEVCNTR112_EL0
> +Field	41	AMEVTYPER111_EL0
> +Field	40	AMEVCNTR111_EL0
> +Field	39	AMEVTYPER110_EL0
> +Field	38	AMEVCNTR110_EL0
> +Field	37	AMEVTYPER19_EL0
> +Field	36	AMEVCNTR19_EL0
> +Field	35	AMEVTYPER18_EL0
> +Field	34	AMEVCNTR18_EL0
> +Field	33	AMEVTYPER17_EL0
> +Field	32	AMEVCNTR17_EL0
> +Field	31	AMEVTYPER16_EL0
> +Field	30	AMEVCNTR16_EL0
> +Field	29	AMEVTYPER15_EL0
> +Field	28	AMEVCNTR15_EL0
> +Field	27	AMEVTYPER14_EL0
> +Field	26	AMEVCNTR14_EL0
> +Field	25	AMEVTYPER13_EL0
> +Field	24	AMEVCNTR13_EL0
> +Field	23	AMEVTYPER12_EL0
> +Field	22	AMEVCNTR12_EL0
> +Field	21	AMEVTYPER11_EL0
> +Field	20	AMEVCNTR11_EL0
> +Field	19	AMEVTYPER10_EL0
> +Field	18	AMEVCNTR10_EL0
> +Field	17	AMCNTEN1
> +Res0	16:5
> +Field	4	AMEVCNTR03_EL0
> +Field	3	AMEVCNTR02_EL0
> +Field	2	AMEVCNTR01_EL0
> +Field	1	AMEVCNTR00_EL0
> +Field	0	AMCNTEN0
> +EndSysreg
> +

Oh, we actually have the register fully encoded since we needed the
fields.  Given this why did we need the manual encoding in the previous
patch?  In any case this looks good according to DDI0601 2023-09:

Reviewed-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/735becdc/attachment-0001.sig>

From conor at kernel.org  Thu Dec  7 09:44:32 2023
From: conor at kernel.org (Conor Dooley)
Date: Thu, 7 Dec 2023 17:44:32 +0000
Subject: [PATCH 1/2] media: i2c: Add GC08A3 image sensor driver
In-Reply-To: <129e3a8b-5e91-424a-8ff8-b015d5175f1a@linaro.org>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
 <20231207052016.25954-2-zhi.mao@mediatek.com>
 <ZXGtqwjYruBQVaUr@kekkonen.localdomain>
 <129e3a8b-5e91-424a-8ff8-b015d5175f1a@linaro.org>
Message-ID: <20231207-outcome-acclaim-d179c8c07fff@spud>

On Thu, Dec 07, 2023 at 01:30:35PM +0100, Krzysztof Kozlowski wrote:
> On 07/12/2023 12:34, Sakari Ailus wrote:
> >> +	ret = gc08a3_parse_fwnode(dev);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	gc08a3 = devm_kzalloc(dev, sizeof(*gc08a3), GFP_KERNEL);
> >> +	if (!gc08a3)
> >> +		return -ENOMEM;
> >> +
> >> +	gc08a3->dev = dev;
> >> +
> >> +	gc08a3->xclk = devm_clk_get(dev, NULL);
> >> +	if (IS_ERR(gc08a3->xclk))
> >> +		return dev_err_probe(dev, PTR_ERR(gc08a3->xclk),
> >> +					 "failed to get xclk\n");
> >> +
> >> +	ret = clk_set_rate(gc08a3->xclk, GC08A3_DEFAULT_CLK_FREQ);
> > 
> > Please see:
> > <URL:https://hverkuil.home.xs4all.nl/spec/driver-api/camera-sensor.html#devicetree>.
> 
> 
> Oh, that's cool it was documented!
> 
> The canonical link would be:
> https://www.kernel.org/doc/html/latest/driver-api/media/camera-sensor.html#devicetree

I believe this is that answer to the "why are these needed" that I asked
on the previous version and never got a response to. Instead, they were
just removed from the binding etc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231207/bd60f4cd/attachment.sig>

From lkp at intel.com  Thu Dec  7 09:45:45 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 08 Dec 2023 01:45:45 +0800
Subject: [soc:drivers/bus-cleanup] BUILD SUCCESS
 fc540426f7baa0c7d4b477e80435d075659092a2
Message-ID: <202312080143.Jb4Ggu6c-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git drivers/bus-cleanup
branch HEAD: fc540426f7baa0c7d4b477e80435d075659092a2  bus: ts-nbus: Convert to platform remove callback returning void

elapsed time: 1481m

configs tested: 185
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231207   gcc  
arc                   randconfig-002-20231207   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                                 defconfig   clang
arm                           h3600_defconfig   gcc  
arm                      jornada720_defconfig   gcc  
arm                        multi_v7_defconfig   gcc  
arm                   randconfig-001-20231207   gcc  
arm                   randconfig-002-20231207   gcc  
arm                   randconfig-003-20231207   gcc  
arm                   randconfig-004-20231207   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231207   gcc  
arm64                 randconfig-002-20231207   gcc  
arm64                 randconfig-003-20231207   gcc  
arm64                 randconfig-004-20231207   gcc  
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231207   gcc  
csky                  randconfig-002-20231207   gcc  
hexagon                          allmodconfig   clang
hexagon                           allnoconfig   clang
hexagon                          allyesconfig   clang
hexagon                             defconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231207   gcc  
i386         buildonly-randconfig-002-20231207   gcc  
i386         buildonly-randconfig-003-20231207   gcc  
i386         buildonly-randconfig-004-20231207   gcc  
i386         buildonly-randconfig-005-20231207   gcc  
i386         buildonly-randconfig-006-20231207   gcc  
i386                                defconfig   gcc  
i386                  randconfig-001-20231207   gcc  
i386                  randconfig-002-20231207   gcc  
i386                  randconfig-003-20231207   gcc  
i386                  randconfig-004-20231207   gcc  
i386                  randconfig-005-20231207   gcc  
i386                  randconfig-006-20231207   gcc  
i386                  randconfig-011-20231207   clang
i386                  randconfig-012-20231207   clang
i386                  randconfig-013-20231207   clang
i386                  randconfig-014-20231207   clang
i386                  randconfig-015-20231207   clang
i386                  randconfig-016-20231207   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231207   gcc  
loongarch             randconfig-002-20231207   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5272c3_defconfig   gcc  
m68k                        mvme147_defconfig   gcc  
m68k                        stmark2_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
mips                       bmips_be_defconfig   gcc  
mips                           ci20_defconfig   gcc  
mips                           ip27_defconfig   gcc  
mips                      loongson3_defconfig   gcc  
mips                         rt305x_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231207   gcc  
nios2                 randconfig-002-20231207   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231207   gcc  
parisc                randconfig-002-20231207   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                      ep88xc_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                     mpc83xx_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc               randconfig-001-20231207   gcc  
powerpc               randconfig-002-20231207   gcc  
powerpc               randconfig-003-20231207   gcc  
powerpc                    socrates_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
powerpc64             randconfig-001-20231207   gcc  
powerpc64             randconfig-002-20231207   gcc  
powerpc64             randconfig-003-20231207   gcc  
riscv                            allmodconfig   gcc  
riscv                             allnoconfig   clang
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231207   gcc  
riscv                 randconfig-002-20231207   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                         ap325rxa_defconfig   gcc  
sh                                  defconfig   gcc  
sh                        dreamcast_defconfig   gcc  
sh                         ecovec24_defconfig   gcc  
sh                    randconfig-001-20231207   gcc  
sh                    randconfig-002-20231207   gcc  
sh                           se7722_defconfig   gcc  
sh                           se7750_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sh                              ul2_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231207   gcc  
sparc64               randconfig-002-20231207   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231207   gcc  
um                    randconfig-002-20231207   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231207   gcc  
x86_64       buildonly-randconfig-002-20231207   gcc  
x86_64       buildonly-randconfig-003-20231207   gcc  
x86_64       buildonly-randconfig-004-20231207   gcc  
x86_64       buildonly-randconfig-005-20231207   gcc  
x86_64       buildonly-randconfig-006-20231207   gcc  
x86_64                              defconfig   gcc  
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231207   gcc  
x86_64                randconfig-012-20231207   gcc  
x86_64                randconfig-013-20231207   gcc  
x86_64                randconfig-014-20231207   gcc  
x86_64                randconfig-015-20231207   gcc  
x86_64                randconfig-016-20231207   gcc  
x86_64                randconfig-071-20231207   gcc  
x86_64                randconfig-072-20231207   gcc  
x86_64                randconfig-073-20231207   gcc  
x86_64                randconfig-074-20231207   gcc  
x86_64                randconfig-075-20231207   gcc  
x86_64                randconfig-076-20231207   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231207   gcc  
xtensa                randconfig-002-20231207   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From olteanv at gmail.com  Thu Dec  7 09:48:29 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Thu, 7 Dec 2023 19:48:29 +0200
Subject: [PATCH net-next 01/15] net: dsa: mt7530: always trap frames to
 active CPU port on MT7530
In-Reply-To: <ffaa26b3-eb25-47cc-8891-fe3cbcc724da@arinc9.com>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-2-arinc.unal@arinc9.com>
 <ZVjLj6/iCL/muzmH@shell.armlinux.org.uk>
 <ffaa26b3-eb25-47cc-8891-fe3cbcc724da@arinc9.com>
Message-ID: <20231207174829.jccyws7myhxbgr5k@skbuf>

On Sat, Dec 02, 2023 at 11:29:18AM +0300, Ar?n? ?NAL wrote:
> > I would be tempted to write this as:
> > 
> > 	mask = BIT(cpu_dp->index);
> > 
> > 	if (operational)
> > 		priv->active_cpu_ports |= mask;
> > 	else
> > 		priv->active_cpu_ports &= ~mask;
> > 
> > Now, what happens when active_cpu_ports is zero? Doesn't that mean there
> > is no active CPU port? In which case, wouldn't disabling the CPU port
> > direction be appropriate, such as:
> > 
> > 	if (priv->active_cpu_ports)
> > 		val = CPU_EN | CPU_PORT(__ffs(priv->active_cpu_ports));
> > 	else
> > 		val = 0;
> > 
> > 	mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val);	
> > 
> > ?
> 
> In practice, it doesn't seem to matter. The CPU_EN bit enables the CPU port
> defined on CPU_PORT_MASK which is used for trapping frames. No active CPU
> ports would mean that all the DSA conduits are down. In that case, all the
> user ports will be down also. So there won't be any traffic. But disabling
> it is of course more appropriate here.

Ack, DSA takes down the user ports which are affine to a certain conduit
interface when that goes down. See the NETDEV_GOING_DOWN handling in
net/dsa/user.c.

> > 
> > >   struct mt7530_priv {
> > >   	struct device		*dev;
> > > @@ -786,6 +787,7 @@ struct mt7530_priv {
> > >   	struct irq_domain *irq_domain;
> > >   	u32 irq_enable;
> > >   	int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii);
> > > +	unsigned long active_cpu_ports;
> > 
> > So this will be 32 or 64 bit in size. Presumably you know how many CPU
> > ports there can be, which looking at this code must be less than 8 as
> > CPU_PORT_MASK is only 3 bits in size. So, maybe use a u8, and check
> > that cpu_dp->index <= 7 ?

We picked "unsigned long" as storage because that's also the size of the
argument that __ffs() takes. But admittedly, we could have also stored a
smaller variable and promote it to unsigned long when we pass it to __ffs().

> Aren't there other mechanisms to check that cpu_dp->index is a valid port?

cpu_dp->index is guaranteed by DSA to be valid (according to the "reg"
value from the device tree and smaller than ds->num_ports). It's just a
question of balancing this kind of optimization with the possibility
that a future switch appears which has more than MT7530_NUM_PORTS (7) ports.

> At least with phylink_get_caps(), only ports lower than 7 will have proper
> interface modes allowed.
> 
> Here's the code after you and Vladimir's review:
> 
> static void
> mt753x_conduit_state_change(struct dsa_switch *ds,
> 			    const struct net_device *conduit,
> 			    bool operational)
> {
> 	struct dsa_port *cpu_dp = conduit->dsa_ptr;
> 	struct mt7530_priv *priv = ds->priv;
> 	u8 mask;
> 	int val;
> 
> 	/* Set the CPU port to trap frames to for MT7530. Trapped frames will be
> 	 * forwarded to the numerically smallest CPU port which the DSA conduit
> 	 * interface its affine to is up.
> 	 */
> 	if (priv->id != ID_MT7530 && priv->id != ID_MT7621)
> 		return;
> 
> 	mask = BIT(cpu_dp->index);
> 
> 	if (operational)
> 		priv->active_cpu_ports |= mask;
> 	else
> 		priv->active_cpu_ports &= ~mask;
> 
> 	if (priv->active_cpu_ports)
> 		val = CPU_EN | CPU_PORT(__ffs(priv->active_cpu_ports));
> 	else
> 		val = 0;

You could initialize "val" with 0 at declaration time and you wouldn't
need the "else" branch.

> 
> 	mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val);
> }
> 
> struct mt7530_priv {
> 	[...]
> 	u8 active_cpu_ports;
> };

Actually, looking at the code now, I don't understand why we even keep
track of the active_cpu_ports mask in the driver. We could read the
MT7530_MFC register in mt753x_conduit_state_change(), flip the bit
corresponding just to cpu_dp->index (rather than rmw all of CPU_PORT_MASK),
and write back the result. And to address Russell's concern, we could test
whether the resulting CPU_PORT_MASK portion of what we're going to write
back is all-zeroes or not, and if it is, clear the CPU_EN bit, otherwise
set it.

> 
> > 
> > I would also suggest moving irq_enable after create_sgmii, to avoid
> > holes in the struct.
> 
> Sorry, I've got no idea about this. Could you explain why would there
> possibly be holes in the struct with the current ordering of the members of
> the mt7530_priv structure?
> 
> Ar?n?

FWIW:

$ pahole -C mt7530_priv $KBUILD_OUTPUT/drivers/net/dsa/mt7530.o
struct mt7530_priv {
        struct device *            dev;                  /*     0     8 */
        struct dsa_switch *        ds;                   /*     8     8 */
        struct mii_bus *           bus;                  /*    16     8 */
        struct regmap *            regmap;               /*    24     8 */
        struct reset_control *     rstc;                 /*    32     8 */
        struct regulator *         core_pwr;             /*    40     8 */
        struct regulator *         io_pwr;               /*    48     8 */
        struct gpio_desc *         reset;                /*    56     8 */
        /* --- cacheline 1 boundary (64 bytes) --- */
        const struct mt753x_info  * info;                /*    64     8 */
        unsigned int               id;                   /*    72     4 */
        bool                       mcm;                  /*    76     1 */

        /* XXX 3 bytes hole, try to pack */

        phy_interface_t            p6_interface;         /*    80     4 */
        phy_interface_t            p5_interface;         /*    84     4 */
        unsigned int               p5_intf_sel;          /*    88     4 */
        u8                         mirror_rx;            /*    92     1 */
        u8                         mirror_tx;            /*    93     1 */

        /* XXX 2 bytes hole, try to pack */

        struct mt7530_port         ports[7];             /*    96   168 */
        /* --- cacheline 4 boundary (256 bytes) was 8 bytes ago --- */
        struct mt753x_pcs          pcs[7];               /*   264   280 */
        /* --- cacheline 8 boundary (512 bytes) was 32 bytes ago --- */
        struct mutex               reg_mutex;            /*   544    32 */
        /* --- cacheline 9 boundary (576 bytes) --- */
        int                        irq;                  /*   576     4 */

        /* XXX 4 bytes hole, try to pack */

        struct irq_domain *        irq_domain;           /*   584     8 */
        u32                        irq_enable;           /*   592     4 */

        /* XXX 4 bytes hole, try to pack */

        int                        (*create_sgmii)(struct mt7530_priv *, bool); /*   600     8 */
        unsigned long              active_cpu_ports;     /*   608     8 */

        /* size: 616, cachelines: 10, members: 24 */
        /* sum members: 603, holes: 4, sum holes: 13 */
        /* last cacheline: 40 bytes */
};

It's not like this makes any practical difference, as struct mt7530_priv
isn't used from hot paths, but tidying it up is a good sign of clean,
careful development, and of understanding memory alignment.


From lkp at intel.com  Thu Dec  7 09:48:10 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 08 Dec 2023 01:48:10 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS
 b0b2981c49ff43f2c547c3a7c82869d6135cfb9a
Message-ID: <202312080108.6m1Og15o-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: b0b2981c49ff43f2c547c3a7c82869d6135cfb9a  Merge tag 'ffa-fixes-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes

elapsed time: 1484m

configs tested: 172
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231207   gcc  
arc                   randconfig-002-20231207   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                                 defconfig   clang
arm                           h3600_defconfig   gcc  
arm                      jornada720_defconfig   gcc  
arm                        multi_v7_defconfig   gcc  
arm                   randconfig-001-20231207   gcc  
arm                   randconfig-002-20231207   gcc  
arm                   randconfig-003-20231207   gcc  
arm                   randconfig-004-20231207   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231207   gcc  
arm64                 randconfig-002-20231207   gcc  
arm64                 randconfig-003-20231207   gcc  
arm64                 randconfig-004-20231207   gcc  
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231207   gcc  
csky                  randconfig-002-20231207   gcc  
hexagon                          allmodconfig   clang
hexagon                           allnoconfig   clang
hexagon                          allyesconfig   clang
hexagon                             defconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231207   gcc  
i386         buildonly-randconfig-002-20231207   gcc  
i386         buildonly-randconfig-003-20231207   gcc  
i386         buildonly-randconfig-004-20231207   gcc  
i386         buildonly-randconfig-005-20231207   gcc  
i386         buildonly-randconfig-006-20231207   gcc  
i386                                defconfig   gcc  
i386                  randconfig-001-20231207   gcc  
i386                  randconfig-002-20231207   gcc  
i386                  randconfig-003-20231207   gcc  
i386                  randconfig-004-20231207   gcc  
i386                  randconfig-005-20231207   gcc  
i386                  randconfig-006-20231207   gcc  
i386                  randconfig-011-20231207   clang
i386                  randconfig-012-20231207   clang
i386                  randconfig-013-20231207   clang
i386                  randconfig-014-20231207   clang
i386                  randconfig-015-20231207   clang
i386                  randconfig-016-20231207   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231207   gcc  
loongarch             randconfig-002-20231207   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
mips                           ci20_defconfig   gcc  
mips                      loongson3_defconfig   gcc  
mips                         rt305x_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231207   gcc  
nios2                 randconfig-002-20231207   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231207   gcc  
parisc                randconfig-002-20231207   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                      ep88xc_defconfig   gcc  
powerpc               randconfig-001-20231207   gcc  
powerpc               randconfig-002-20231207   gcc  
powerpc               randconfig-003-20231207   gcc  
powerpc                     stx_gp3_defconfig   gcc  
powerpc64             randconfig-001-20231207   gcc  
powerpc64             randconfig-002-20231207   gcc  
powerpc64             randconfig-003-20231207   gcc  
riscv                            allmodconfig   gcc  
riscv                             allnoconfig   clang
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231207   gcc  
riscv                 randconfig-002-20231207   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                         ap325rxa_defconfig   gcc  
sh                                  defconfig   gcc  
sh                         ecovec24_defconfig   gcc  
sh                    randconfig-001-20231207   gcc  
sh                    randconfig-002-20231207   gcc  
sh                           se7722_defconfig   gcc  
sh                              ul2_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231207   gcc  
sparc64               randconfig-002-20231207   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231207   gcc  
um                    randconfig-002-20231207   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231207   gcc  
x86_64       buildonly-randconfig-002-20231207   gcc  
x86_64       buildonly-randconfig-003-20231207   gcc  
x86_64       buildonly-randconfig-004-20231207   gcc  
x86_64       buildonly-randconfig-005-20231207   gcc  
x86_64       buildonly-randconfig-006-20231207   gcc  
x86_64                              defconfig   gcc  
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231207   gcc  
x86_64                randconfig-012-20231207   gcc  
x86_64                randconfig-013-20231207   gcc  
x86_64                randconfig-014-20231207   gcc  
x86_64                randconfig-015-20231207   gcc  
x86_64                randconfig-016-20231207   gcc  
x86_64                randconfig-071-20231207   gcc  
x86_64                randconfig-072-20231207   gcc  
x86_64                randconfig-073-20231207   gcc  
x86_64                randconfig-074-20231207   gcc  
x86_64                randconfig-075-20231207   gcc  
x86_64                randconfig-076-20231207   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231207   gcc  
xtensa                randconfig-002-20231207   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Thu Dec  7 09:49:44 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 08 Dec 2023 01:49:44 +0800
Subject: [soc:soc/drivers] BUILD SUCCESS
 a351940d61e608c363c86462f2355e3896e1636d
Message-ID: <202312080141.P249aWxn-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/drivers
branch HEAD: a351940d61e608c363c86462f2355e3896e1636d  Merge tag 'bus-platform-remove-void' of https://git.pengutronix.de/git/ukl/linux into soc/drivers

elapsed time: 1485m

configs tested: 185
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231207   gcc  
arc                   randconfig-002-20231207   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                                 defconfig   clang
arm                           h3600_defconfig   gcc  
arm                      jornada720_defconfig   gcc  
arm                        multi_v7_defconfig   gcc  
arm                   randconfig-001-20231207   gcc  
arm                   randconfig-002-20231207   gcc  
arm                   randconfig-003-20231207   gcc  
arm                   randconfig-004-20231207   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231207   gcc  
arm64                 randconfig-002-20231207   gcc  
arm64                 randconfig-003-20231207   gcc  
arm64                 randconfig-004-20231207   gcc  
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231207   gcc  
csky                  randconfig-002-20231207   gcc  
hexagon                          allmodconfig   clang
hexagon                           allnoconfig   clang
hexagon                          allyesconfig   clang
hexagon                             defconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231207   gcc  
i386         buildonly-randconfig-002-20231207   gcc  
i386         buildonly-randconfig-003-20231207   gcc  
i386         buildonly-randconfig-004-20231207   gcc  
i386         buildonly-randconfig-005-20231207   gcc  
i386         buildonly-randconfig-006-20231207   gcc  
i386                                defconfig   gcc  
i386                  randconfig-001-20231207   gcc  
i386                  randconfig-002-20231207   gcc  
i386                  randconfig-003-20231207   gcc  
i386                  randconfig-004-20231207   gcc  
i386                  randconfig-005-20231207   gcc  
i386                  randconfig-006-20231207   gcc  
i386                  randconfig-011-20231207   clang
i386                  randconfig-012-20231207   clang
i386                  randconfig-013-20231207   clang
i386                  randconfig-014-20231207   clang
i386                  randconfig-015-20231207   clang
i386                  randconfig-016-20231207   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231207   gcc  
loongarch             randconfig-002-20231207   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5272c3_defconfig   gcc  
m68k                        mvme147_defconfig   gcc  
m68k                        stmark2_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
mips                       bmips_be_defconfig   gcc  
mips                           ci20_defconfig   gcc  
mips                           ip27_defconfig   gcc  
mips                      loongson3_defconfig   gcc  
mips                         rt305x_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231207   gcc  
nios2                 randconfig-002-20231207   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231207   gcc  
parisc                randconfig-002-20231207   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                      ep88xc_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                     mpc83xx_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc               randconfig-001-20231207   gcc  
powerpc               randconfig-002-20231207   gcc  
powerpc               randconfig-003-20231207   gcc  
powerpc                    socrates_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
powerpc64             randconfig-001-20231207   gcc  
powerpc64             randconfig-002-20231207   gcc  
powerpc64             randconfig-003-20231207   gcc  
riscv                            allmodconfig   gcc  
riscv                             allnoconfig   clang
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231207   gcc  
riscv                 randconfig-002-20231207   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                         ap325rxa_defconfig   gcc  
sh                                  defconfig   gcc  
sh                        dreamcast_defconfig   gcc  
sh                         ecovec24_defconfig   gcc  
sh                    randconfig-001-20231207   gcc  
sh                    randconfig-002-20231207   gcc  
sh                           se7722_defconfig   gcc  
sh                           se7750_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sh                              ul2_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231207   gcc  
sparc64               randconfig-002-20231207   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231207   gcc  
um                    randconfig-002-20231207   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231207   gcc  
x86_64       buildonly-randconfig-002-20231207   gcc  
x86_64       buildonly-randconfig-003-20231207   gcc  
x86_64       buildonly-randconfig-004-20231207   gcc  
x86_64       buildonly-randconfig-005-20231207   gcc  
x86_64       buildonly-randconfig-006-20231207   gcc  
x86_64                              defconfig   gcc  
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231207   gcc  
x86_64                randconfig-012-20231207   gcc  
x86_64                randconfig-013-20231207   gcc  
x86_64                randconfig-014-20231207   gcc  
x86_64                randconfig-015-20231207   gcc  
x86_64                randconfig-016-20231207   gcc  
x86_64                randconfig-071-20231207   gcc  
x86_64                randconfig-072-20231207   gcc  
x86_64                randconfig-073-20231207   gcc  
x86_64                randconfig-074-20231207   gcc  
x86_64                randconfig-075-20231207   gcc  
x86_64                randconfig-076-20231207   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231207   gcc  
xtensa                randconfig-002-20231207   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From robh at kernel.org  Thu Dec  7 09:58:20 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 7 Dec 2023 11:58:20 -0600
Subject: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
References: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
Message-ID: <170197172648.2974247.13097453111547800548.robh@kernel.org>


On Sun, 03 Dec 2023 18:46:22 +0100, Krzysztof Kozlowski wrote:
> Document preferred coding style for Devicetree sources (DTS and DTSI),
> to bring consistency among all (sub)architectures and ease in reviews.
> 
> Cc: Andrew Davis <afd at ti.com>
> cc: Andrew Lunn <andrew at lunn.ch>
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Bjorn Andersson <andersson at kernel.org>
> Cc: Chen-Yu Tsai <wens at kernel.org>
> Cc: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> Cc: Jonathan Corbet <corbet at lwn.net>
> Cc: Matthias Brugger <matthias.bgg at gmail.com>
> Cc: Michal Simek <michal.simek at amd.com>
> Cc: Neil Armstrong <neil.armstrong at linaro.org>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Olof Johansson <olof at lixom.net>
> Cc: Rafa? Mi?ecki <zajec5 at gmail.com>
> Acked-by: Neil Armstrong <neil.armstrong at linaro.org>
> Acked-by: Heiko Stuebner <heiko at sntech.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Acked-by: Konrad Dybcio <konradybcio at kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> ---
> 
> Merging idea: Rob/DT bindings
> 
> Changes in v4
> =============
> 1. Drop label at the top (Jon)
> 2. Grammar fixes (Laurent, Dragan)
> 3. "Unless a bus defines differently, unit addresses shall ..." (Rob)
> 4. Use hex in example of dma-controller (Andrew)
> 5. Example: soc@ -> soc at 0
> 6. Reverse points 2 and 3 in "Indentation" (Andrew)
> 7. Use full path to coding style doc (Conor)
> 
> Changes in v3
> =============
> 1. should->shall (Angelo)
> 2. Comments // -> /* (Angelo, Michal)
> 3. Use imaginary example in "Order of Properties in Device Node"
>    (Angelo)
> 4. Added paragraphs for three sections with justifications of chosen
>    style.
> 5. Allow two style of ordering overrides in board DTS: alphabetically or
>    by order of DTSI (Rob).
> 6. I did not incorporate feedback about, due to lack of consensus and my
>    disagreement:
>    a. SoM being DTS without DTSI in "Organizing DTSI and DTS"
> 
> Changes in v2
> =============
> 1. Hopefully incorporate entire feedback from comments:
> a. Fix \ { => / { (Rob)
> b. Name: dts-coding-style (Rob)
> c. Exceptions for ordering nodes by name for Renesas and pinctrl (Geert,
>    Konrad)
> d. Ordering properties by common/vendor (Rob)
> e. Array entries in <> (Rob)
> 
> 2. New chapter: Organizing DTSI and DTS
> 
> 3. Several grammar fixes (missing articles)
> 
> Cc: linux-rockchip at lists.infradead.org
> Cc: linux-mediatek at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-amlogic at lists.infradead.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-arm-msm at vger.kernel.org
> Cc: workflows at vger.kernel.org
> Cc: linux-doc at vger.kernel.org
> ---
>  .../devicetree/bindings/dts-coding-style.rst  | 196 ++++++++++++++++++
>  Documentation/devicetree/bindings/index.rst   |   1 +
>  2 files changed, 197 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dts-coding-style.rst
> 

I added the quotes as discussed and applied, thanks!

Rob


From olteanv at gmail.com  Thu Dec  7 10:03:32 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Thu, 7 Dec 2023 20:03:32 +0200
Subject: [PATCH net-next 05/15] net: dsa: mt7530: improve code path for
 setting up port 5
In-Reply-To: <5e95a436-189f-412e-b409-89a003003292@arinc9.com>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-6-arinc.unal@arinc9.com>
 <ZVjNJ0nf7Mp0kHzH@shell.armlinux.org.uk>
 <5e95a436-189f-412e-b409-89a003003292@arinc9.com>
Message-ID: <20231207180332.ugfp33xcdkw3elrw@skbuf>

On Sat, Dec 02, 2023 at 11:36:03AM +0300, Ar?n? ?NAL wrote:
> On 18.11.2023 17:41, Russell King (Oracle) wrote:
> > > For the cases of PHY muxing or the port being disabled, call
> > > mt7530_setup_port5() from mt7530_setup(). mt7530_setup_port5() from
> > > mt753x_phylink_mac_config() won't run when port 5 is disabled or used for
> > > PHY muxing as port 5 won't be defined on the devicetree.
> > 
> > ... and this should state why this needs to happen - in other words,
> > the commit message should state why is it critical that port 5 is
> > always setup.
> 
> Actually, port 5 must not always be setup. With patch 7, I explain this
> while preventing mt7530_setup_port5() from running if port 5 is disabled.
> 
> Ar?n?

Then change that last paragraph. You could say something like this:

To keep the cases where port 5 isn't controlled by phylink working as
before, we need to preserve the mt7530_setup_port5() call from mt7530_setup().

I think it's a case of saying too much, which sparks too many unresolved
questions in the reader's mind, which are irrelevant for the purpose of
this specific change: eliminating the overlap between DSA's setup() time
and phylink.


From olteanv at gmail.com  Thu Dec  7 10:18:58 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Thu, 7 Dec 2023 20:18:58 +0200
Subject: [PATCH net-next 06/15] net: dsa: mt7530: do not set
 priv->p5_interface on mt7530_setup_port5()
In-Reply-To: <20231118123205.266819-7-arinc.unal@arinc9.com>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-7-arinc.unal@arinc9.com>
Message-ID: <20231207181858.ojbgt5pwyqq3tzjk@skbuf>

On Sat, Nov 18, 2023 at 03:31:56PM +0300, Ar?n? ?NAL wrote:
> Do not set priv->p5_interface on mt7530_setup_port5(). There isn't a case
> where mt753x_phylink_mac_config() runs after mt7530_setup_port5() which
> setting priv->p5_interface would prevent mt7530_setup_port5() from running
> more than once.
> 
> Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
> ---
>  drivers/net/dsa/mt7530.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 069b3dfca6fa..fc87ec817672 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -978,8 +978,6 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
>  	dev_dbg(ds->dev, "Setup P5, HWTRAP=0x%x, intf_sel=%s, phy-mode=%s\n",
>  		val, p5_intf_modes(priv->p5_intf_sel), phy_modes(interface));
>  
> -	priv->p5_interface = interface;
> -
>  unlock_exit:
>  	mutex_unlock(&priv->reg_mutex);
>  }
> -- 
> 2.40.1
> 

Purely as a matter of theory, mt753x_phylink_mac_config() itself could
be called more than once, at any time there is a phylink_major_config() -
first during initial one, then upon any change of the phy_interface_t.
With the port being fixed and internal, maybe that is unlikely.

Destroying and re-creating the phylink instance could also make the
driver see more than 1 mt753x_phylink_mac_config() call. During periods
of -EPROBE_DEFER, maybe this could even happen.

I think what we need to see is a description of what the priv->p5_interface
test is really protecting against, because it certainly is uncommon in other
drivers to have this much logic to avoid mt753x_mac_config() being
called twice.

If there's nothing wrong with calling it twice and it's just an optimization,
I think that's enough of a justification for removing that extra protection.
At the same time, the optimization (and simplification) that we should
pursue is that we should remove the overlap between phylink and the
initial port setup made by the driver.


From liviu.dudau at arm.com  Thu Dec  7 10:30:57 2023
From: liviu.dudau at arm.com (Liviu Dudau)
Date: Thu, 7 Dec 2023 18:30:57 +0000
Subject: [PATCH v2] ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support
In-Reply-To: <20231207-drop-11mpcore-v2-1-560b396f3bf5@linaro.org>
References: <20231207-drop-11mpcore-v2-1-560b396f3bf5@linaro.org>
Message-ID: <ZXIPYUrtitafCKH8@e110455-lin.cambridge.arm.com>

On Thu, Dec 07, 2023 at 02:33:35PM +0100, Linus Walleij wrote:
> This ARM11 SMP configuration was one of the first SMP configurations
> the ARM kernel supported, but it has the downside of odd DMA handling,
> odd cache tagging, and often (as of recent) completely broken cache
> handling on the ARM RealView PB11MPCore test chips. To boot the
> platform it was necessary to completely disable the cache.
> When it comes to the EB 11MPCore it is unclear if this ever worked.
> 
> These reference designs are now the only ARMv6K SMP platforms.
> 
> As only reference designs of purely academic interest remain, and
> since the special-cased DMA and PMU code is hard to maintain and
> doesn't really work, it is not really worth our time.
> 
> Delete the ARM11MPCore support along with:
> 
> - The special DMA quirk CONFIG_DMA_CACHE_RWFO that is only used
>   on ARMv6K SMP, and we are the last ARMV6K system leaving the
>   building and the cache handling is awkward, so good-bye.
> 
> - The special PMU handling that was only used by ARM11MPCore.
> 
> The following is left behind:
> 
> - TIMER_OF_DECLARE(arm_twd_11mp, "arm,arm11mp-twd-timer", ...)
>   in arch/arm/kernel/smp_twd.c, this is still in use by Marvell MMP3
>   arch/arm/boot/dts/marvell/mmp3.dtsi
> 
> - IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", ...)
>   in drivers/irqchip/irq-gic.c, this is still in use by Marvell MMP3
>   arch/arm/boot/dts/marvell/mmp3.dtsi
> 
> - A compatible for the arm11mpcore SCU, since this was mistakedly
>   used for the Cortex-A9 version of RealView EB.
> 
> These are unfortunate but will need to be kept around for
> compatibility. New Marvell-specific compatibles should however probably
> be added.

I remember seeing a decade ago some evaluation boards with ARM11MPCore
but that's as far as I have ever come close to this platform.

For what is worth:

Acked-by: Liviu Dudau <liviu.dudau at arm.com>

Best regards,
Liviu

> 
> Acked-by: Mark Rutland <mark.rutland at arm.com>
> Reviewed-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> Changes in v2:
> - Keep the PB11MPCore SCU compatible for a bit (until we delete these
>   RealView EB device trees).
> - Please apply this to the SoC tree once there is consensus.
> - Link to v1: https://lore.kernel.org/r/20231204-drop-11mpcore-v1-1-f96cd3938cf1 at linaro.org
> ---
>  arch/arm/kernel/perf_event_v6.c            | 34 ------------------------------
>  arch/arm/mach-versatile/Kconfig            | 17 ---------------
>  arch/arm/mach-versatile/platsmp-realview.c |  6 +++++-
>  arch/arm/mach-versatile/realview.c         |  1 -
>  arch/arm/mm/Kconfig                        | 18 ----------------
>  arch/arm/mm/cache-v6.S                     | 31 ---------------------------
>  6 files changed, 5 insertions(+), 102 deletions(-)
> 
> diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
> index 1ae99deeec54..3115077f6abc 100644
> --- a/arch/arm/kernel/perf_event_v6.c
> +++ b/arch/arm/kernel/perf_event_v6.c
> @@ -525,40 +525,7 @@ static int armv6_1176_pmu_init(struct arm_pmu *cpu_pmu)
>  	return 0;
>  }
>  
> -/*
> - * ARMv6mpcore is almost identical to single core ARMv6 with the exception
> - * that some of the events have different enumerations and that there is no
> - * *hack* to stop the programmable counters. To stop the counters we simply
> - * disable the interrupt reporting and update the event. When unthrottling we
> - * reset the period and enable the interrupt reporting.
> - */
> -
> -static int armv6mpcore_map_event(struct perf_event *event)
> -{
> -	return armpmu_map_event(event, &armv6mpcore_perf_map,
> -				&armv6mpcore_perf_cache_map, 0xFF);
> -}
> -
> -static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
> -{
> -	cpu_pmu->name		= "armv6_11mpcore";
> -	cpu_pmu->handle_irq	= armv6pmu_handle_irq;
> -	cpu_pmu->enable		= armv6pmu_enable_event;
> -	cpu_pmu->disable	= armv6mpcore_pmu_disable_event;
> -	cpu_pmu->read_counter	= armv6pmu_read_counter;
> -	cpu_pmu->write_counter	= armv6pmu_write_counter;
> -	cpu_pmu->get_event_idx	= armv6pmu_get_event_idx;
> -	cpu_pmu->clear_event_idx = armv6pmu_clear_event_idx;
> -	cpu_pmu->start		= armv6pmu_start;
> -	cpu_pmu->stop		= armv6pmu_stop;
> -	cpu_pmu->map_event	= armv6mpcore_map_event;
> -	cpu_pmu->num_events	= 3;
> -
> -	return 0;
> -}
> -
>  static const struct of_device_id armv6_pmu_of_device_ids[] = {
> -	{.compatible = "arm,arm11mpcore-pmu",	.data = armv6mpcore_pmu_init},
>  	{.compatible = "arm,arm1176-pmu",	.data = armv6_1176_pmu_init},
>  	{.compatible = "arm,arm1136-pmu",	.data = armv6_1136_pmu_init},
>  	{ /* sentinel value */ }
> @@ -568,7 +535,6 @@ static const struct pmu_probe_info armv6_pmu_probe_table[] = {
>  	ARM_PMU_PROBE(ARM_CPU_PART_ARM1136, armv6_1136_pmu_init),
>  	ARM_PMU_PROBE(ARM_CPU_PART_ARM1156, armv6_1156_pmu_init),
>  	ARM_PMU_PROBE(ARM_CPU_PART_ARM1176, armv6_1176_pmu_init),
> -	ARM_PMU_PROBE(ARM_CPU_PART_ARM11MPCORE, armv6mpcore_pmu_init),
>  	{ /* sentinel value */ }
>  };
>  
> diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
> index b1519b4dc03a..e029270c2687 100644
> --- a/arch/arm/mach-versatile/Kconfig
> +++ b/arch/arm/mach-versatile/Kconfig
> @@ -201,23 +201,6 @@ config REALVIEW_EB_A9MP
>  	  Enable support for the Cortex-A9MPCore tile fitted to the
>  	  Realview(R) Emulation Baseboard platform.
>  
> -config REALVIEW_EB_ARM11MP
> -	bool "Support ARM11MPCore Tile"
> -	depends on MACH_REALVIEW_EB && ARCH_MULTI_V6
> -	select HAVE_SMP
> -	help
> -	  Enable support for the ARM11MPCore tile fitted to the Realview(R)
> -	  Emulation Baseboard platform.
> -
> -config MACH_REALVIEW_PB11MP
> -	bool "Support RealView(R) Platform Baseboard for ARM11MPCore"
> -	depends on ARCH_MULTI_V6
> -	select HAVE_SMP
> -	help
> -	  Include support for the ARM(R) RealView(R) Platform Baseboard for
> -	  the ARM11MPCore.  This platform has an on-board ARM11MPCore and has
> -	  support for PCI-E and Compact Flash.
> -
>  # ARMv6 CPU without K extensions, but does have the new exclusive ops
>  config MACH_REALVIEW_PB1176
>  	bool "Support RealView(R) Platform Baseboard for ARM1176JZF-S"
> diff --git a/arch/arm/mach-versatile/platsmp-realview.c b/arch/arm/mach-versatile/platsmp-realview.c
> index 5d363385c801..6965a1de727b 100644
> --- a/arch/arm/mach-versatile/platsmp-realview.c
> +++ b/arch/arm/mach-versatile/platsmp-realview.c
> @@ -18,6 +18,11 @@
>  #define REALVIEW_SYS_FLAGSSET_OFFSET	0x30
>  
>  static const struct of_device_id realview_scu_match[] = {
> +	/*
> +	 * The ARM11MP SCU compatible is only provided as fallback for
> +	 * old RealView EB Cortex-A9 device trees that were using this
> +	 * compatible by mistake.
> +	 */
>  	{ .compatible = "arm,arm11mp-scu", },
>  	{ .compatible = "arm,cortex-a9-scu", },
>  	{ .compatible = "arm,cortex-a5-scu", },
> @@ -27,7 +32,6 @@ static const struct of_device_id realview_scu_match[] = {
>  static const struct of_device_id realview_syscon_match[] = {
>          { .compatible = "arm,core-module-integrator", },
>          { .compatible = "arm,realview-eb-syscon", },
> -        { .compatible = "arm,realview-pb11mp-syscon", },
>          { .compatible = "arm,realview-pbx-syscon", },
>          { },
>  };
> diff --git a/arch/arm/mach-versatile/realview.c b/arch/arm/mach-versatile/realview.c
> index a3933e2373d5..36a6f6bc4fdd 100644
> --- a/arch/arm/mach-versatile/realview.c
> +++ b/arch/arm/mach-versatile/realview.c
> @@ -9,7 +9,6 @@
>  static const char *const realview_dt_platform_compat[] __initconst = {
>  	"arm,realview-eb",
>  	"arm,realview-pb1176",
> -	"arm,realview-pb11mp",
>  	"arm,realview-pba8",
>  	"arm,realview-pbx",
>  	NULL,
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index c164cde50243..2b6f50dd5478 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -937,24 +937,6 @@ config VDSO
>  	  You must have glibc 2.22 or later for programs to seamlessly
>  	  take advantage of this.
>  
> -config DMA_CACHE_RWFO
> -	bool "Enable read/write for ownership DMA cache maintenance"
> -	depends on CPU_V6K && SMP
> -	default y
> -	help
> -	  The Snoop Control Unit on ARM11MPCore does not detect the
> -	  cache maintenance operations and the dma_{map,unmap}_area()
> -	  functions may leave stale cache entries on other CPUs. By
> -	  enabling this option, Read or Write For Ownership in the ARMv6
> -	  DMA cache maintenance functions is performed. These LDR/STR
> -	  instructions change the cache line state to shared or modified
> -	  so that the cache operation has the desired effect.
> -
> -	  Note that the workaround is only valid on processors that do
> -	  not perform speculative loads into the D-cache. For such
> -	  processors, if cache maintenance operations are not broadcast
> -	  in hardware, other workarounds are needed (e.g. cache
> -	  maintenance broadcasting in software via FIQ).
>  
>  config OUTER_CACHE
>  	bool
> diff --git a/arch/arm/mm/cache-v6.S b/arch/arm/mm/cache-v6.S
> index 250c83bf7158..44211d8a296f 100644
> --- a/arch/arm/mm/cache-v6.S
> +++ b/arch/arm/mm/cache-v6.S
> @@ -201,10 +201,6 @@ ENTRY(v6_flush_kern_dcache_area)
>   *	- end     - virtual end address of region
>   */
>  v6_dma_inv_range:
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrb	r2, [r0]			@ read for ownership
> -	strb	r2, [r0]			@ write for ownership
> -#endif
>  	tst	r0, #D_CACHE_LINE_SIZE - 1
>  	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
>  #ifdef HARVARD_CACHE
> @@ -213,10 +209,6 @@ v6_dma_inv_range:
>  	mcrne	p15, 0, r0, c7, c11, 1		@ clean unified line
>  #endif
>  	tst	r1, #D_CACHE_LINE_SIZE - 1
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrbne	r2, [r1, #-1]			@ read for ownership
> -	strbne	r2, [r1, #-1]			@ write for ownership
> -#endif
>  	bic	r1, r1, #D_CACHE_LINE_SIZE - 1
>  #ifdef HARVARD_CACHE
>  	mcrne	p15, 0, r1, c7, c14, 1		@ clean & invalidate D line
> @@ -231,10 +223,6 @@ v6_dma_inv_range:
>  #endif
>  	add	r0, r0, #D_CACHE_LINE_SIZE
>  	cmp	r0, r1
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrlo	r2, [r0]			@ read for ownership
> -	strlo	r2, [r0]			@ write for ownership
> -#endif
>  	blo	1b
>  	mov	r0, #0
>  	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer
> @@ -248,9 +236,6 @@ v6_dma_inv_range:
>  v6_dma_clean_range:
>  	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
>  1:
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldr	r2, [r0]			@ read for ownership
> -#endif
>  #ifdef HARVARD_CACHE
>  	mcr	p15, 0, r0, c7, c10, 1		@ clean D line
>  #else
> @@ -269,10 +254,6 @@ v6_dma_clean_range:
>   *	- end     - virtual end address of region
>   */
>  ENTRY(v6_dma_flush_range)
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrb	r2, [r0]		@ read for ownership
> -	strb	r2, [r0]		@ write for ownership
> -#endif
>  	bic	r0, r0, #D_CACHE_LINE_SIZE - 1
>  1:
>  #ifdef HARVARD_CACHE
> @@ -282,10 +263,6 @@ ENTRY(v6_dma_flush_range)
>  #endif
>  	add	r0, r0, #D_CACHE_LINE_SIZE
>  	cmp	r0, r1
> -#ifdef CONFIG_DMA_CACHE_RWFO
> -	ldrblo	r2, [r0]			@ read for ownership
> -	strblo	r2, [r0]			@ write for ownership
> -#endif
>  	blo	1b
>  	mov	r0, #0
>  	mcr	p15, 0, r0, c7, c10, 4		@ drain write buffer
> @@ -301,13 +278,7 @@ ENTRY(v6_dma_map_area)
>  	add	r1, r1, r0
>  	teq	r2, #DMA_FROM_DEVICE
>  	beq	v6_dma_inv_range
> -#ifndef CONFIG_DMA_CACHE_RWFO
>  	b	v6_dma_clean_range
> -#else
> -	teq	r2, #DMA_TO_DEVICE
> -	beq	v6_dma_clean_range
> -	b	v6_dma_flush_range
> -#endif
>  ENDPROC(v6_dma_map_area)
>  
>  /*
> @@ -317,11 +288,9 @@ ENDPROC(v6_dma_map_area)
>   *	- dir	- DMA direction
>   */
>  ENTRY(v6_dma_unmap_area)
> -#ifndef CONFIG_DMA_CACHE_RWFO
>  	add	r1, r1, r0
>  	teq	r2, #DMA_TO_DEVICE
>  	bne	v6_dma_inv_range
> -#endif
>  	ret	lr
>  ENDPROC(v6_dma_unmap_area)
>  
> 
> ---
> base-commit: d570fe67df85c84be7cc33ca9e9568d9601b494f
> change-id: 20231202-drop-11mpcore-d556cc5f7d99
> 
> Best regards,
> -- 
> Linus Walleij <linus.walleij at linaro.org>
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?


From olteanv at gmail.com  Thu Dec  7 10:40:15 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Thu, 7 Dec 2023 20:40:15 +0200
Subject: [PATCH net-next 07/15] net: dsa: mt7530: do not run
 mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <90fde560-054e-4188-b15c-df2e082d3e33@moroto.mountain>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-8-arinc.unal@arinc9.com>
 <20231121185358.GA16629@kernel.org>
 <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
 <90fde560-054e-4188-b15c-df2e082d3e33@moroto.mountain>
Message-ID: <20231207184015.u7uoyfhdxiyuw6hh@skbuf>

On Thu, Dec 07, 2023 at 09:51:07AM +0300, Dan Carpenter wrote:
> On Sat, Dec 02, 2023 at 11:45:42AM +0300, Ar?n? ?NAL wrote:
> > 
> > I'm not sure why it doesn't catch that for mt7530_setup_port5() to run
> > here, priv->p5_intf_sel must be either P5_INTF_SEL_PHY_P0 or
> > P5_INTF_SEL_PHY_P4. And for that to happen, the interface variable will be
> > initialised.
> > 
> > for_each_child_of_node(dn, mac_np) {
> > 	if (!of_device_is_compatible(mac_np,
> > 				     "mediatek,eth-mac"))
> > 		continue;
> > 
> > 	ret = of_property_read_u32(mac_np, "reg", &id);
> > 	if (ret < 0 || id != 1)
> > 		continue;
> > 
> > 	phy_node = of_parse_phandle(mac_np, "phy-handle", 0);
> > 	if (!phy_node)
> > 		continue;
> > 
> > 	if (phy_node->parent == priv->dev->of_node->parent) {
> > 		ret = of_get_phy_mode(mac_np, &interface);
> > 		if (ret && ret != -ENODEV) {
> > 			of_node_put(mac_np);
> > 			of_node_put(phy_node);
> > 			return ret;
> > 		}
> > 		id = of_mdio_parse_addr(ds->dev, phy_node);
> > 		if (id == 0)
> > 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P0;
> > 		if (id == 4)
> > 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P4;
> > 	}
> > 	of_node_put(mac_np);
> > 	of_node_put(phy_node);
> > 	break;
> > }
> > 
> > if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 ||
> >     priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
> > 	mt7530_setup_port5(ds, interface);
> 
> Smatch doesn't know:
> 1) What the value of priv->p5_intf_sel is going into this function
> 2) We enter the for_each_child_of_node() loop
> 3) That if (phy_node->parent == priv->dev->of_node->parent) { is
>    definitely true for one element on the list.
> 
> Looking at how Smatch parses this code, I could probably improve problem
> #1 a bit.  Right now Smatch sees "struct mt7530_priv *priv = ds->priv;"
> and "priv->p5_intf_sel" is unknown, but I could probably improve it to
> where it says that it's in the 1-3 range.  But that doesn't help here
> and it doesn't address problems 2 and 3.
> 
> It's a hard problem.
> 
> regards,
> dan carpenter
> 

We could be more pragmatic about this whole sparse false positive warning,
and just move the "if" block which calls mt7530_setup_port5() right
after the priv->p5_intf_sel assignments, instead of waiting to "break;"
from the for_each_child_of_node() loop.

for_each_child_of_node(dn, mac_np) {
	if (!of_device_is_compatible(mac_np,
				     "mediatek,eth-mac"))
		continue;

	ret = of_property_read_u32(mac_np, "reg", &id);
	if (ret < 0 || id != 1)
		continue;

	phy_node = of_parse_phandle(mac_np, "phy-handle", 0);
	if (!phy_node)
		continue;

	if (phy_node->parent == priv->dev->of_node->parent) {
		ret = of_get_phy_mode(mac_np, &interface);
		if (ret && ret != -ENODEV) {
			of_node_put(mac_np);
			of_node_put(phy_node);
			return ret;
		}
		id = of_mdio_parse_addr(ds->dev, phy_node);
		if (id == 0)
			priv->p5_intf_sel = P5_INTF_SEL_PHY_P0;
		if (id == 4)
			priv->p5_intf_sel = P5_INTF_SEL_PHY_P4;

		if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 || <---- here
		    priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
			mt7530_setup_port5(ds, interface);
	}
	of_node_put(mac_np);
	of_node_put(phy_node);
	break;
}

I hope it's now much clearer to sparse that "interface" is used within
the same basic block in which it also got assigned, and that determination
does not depend upon the values taken by a second variable.

Maybe it's also a bit clearer for us humans.

What would also help us humans even more is to extract the entire "dn"
handling from mt7530_setup() into a separate mt7530_setup_phy_muxing()
function, and put a good comment there about what's going on with this
PHY muxing thing.

The advantage of splitting this up is that we don't pollute mt7530_setup()
with finding the "dn" if dsa_is_unused_port(ds, 5) returns false.

Also, reducing the indentation level of for_each_child_of_node() by one
can't be bad. Maybe even by more. There's this pattern:

for_each_child_of_node(dn, mac_np) {
	// do stuff with mac_np
	break;
}

aka we only care about the first child of dn. We could find the mac_np
as the only operation inside for_each_child_of_node(), break directly,
and "do stuff with mac_np" could be done outside, further reducing the
indentation by 1 level.


From festevam at gmail.com  Thu Dec  7 10:55:41 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 15:55:41 -0300
Subject: [PATCH 1/3] arm64: dts: imx8mp-verdin: Fix USB connector description
Message-ID: <20231207185543.2699697-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The USB connector should not be placed under the dwc3 node.

Move the USB connector out of the SoC level and use port to describe
the connection to the dwc3 controller.

This fixes the following dt-schema warning:

imx8mp-verdin-wifi-mallow.dtb: usb at 32f10100: usb at 38100000: Unevaluated properties are not allowed ('connector' was unexpected)
	from schema $id: http://devicetree.org/schemas/usb/fsl,imx8mp-dwc3.yaml#
	
Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 .../boot/dts/freescale/imx8mp-verdin.dtsi     | 30 +++++++++++++------
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
index 04f2083c4ab2..c3305f0d4001 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
@@ -45,6 +45,23 @@ backlight_mezzanine: backlight-mezzanine {
 		status = "disabled";
 	};
 
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		id-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
+		label = "Type-C";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usb_1_id>;
+		self-powered;
+		type = "micro";
+		vbus-supply = <&reg_usb1_vbus>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 		pinctrl-names = "default";
@@ -835,15 +852,10 @@ &usb_dwc3_0 {
 	srp-disable;
 	usb-role-switch;
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		id-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
-		label = "Type-C";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usb_1_id>;
-		self-powered;
-		type = "micro";
-		vbus-supply = <&reg_usb1_vbus>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
-- 
2.34.1



From festevam at gmail.com  Thu Dec  7 10:55:42 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 15:55:42 -0300
Subject: [PATCH 2/3] arm64: dts: imx8mp-venice: Fix USB connector description
In-Reply-To: <20231207185543.2699697-1-festevam@gmail.com>
References: <20231207185543.2699697-1-festevam@gmail.com>
Message-ID: <20231207185543.2699697-2-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The USB connector should not be placed under the dwc3 node.

Move the USB connector out of the SoC level and use port to describe
the connection to the dwc3 controller.

This fixes the following dt-schema warning:

imx8mp-venice-gw72xx-2x.dtb: usb at 38100000: Unevaluated properties are not allowed ('connector' was unexpected)
	from schema $id: http://devicetree.org/schemas/usb/snps,dwc3.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 .../dts/freescale/imx8mp-venice-gw71xx.dtsi   | 26 +++++++++++++-----
 .../dts/freescale/imx8mp-venice-gw72xx.dtsi   | 27 ++++++++++++++-----
 .../dts/freescale/imx8mp-venice-gw73xx.dtsi   | 27 ++++++++++++++-----
 .../dts/freescale/imx8mp-venice-gw74xx.dts    | 27 ++++++++++++++-----
 4 files changed, 79 insertions(+), 28 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi
index bf47b5e9dd8c..0e8d0f3c7ea8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi
@@ -8,6 +8,21 @@
 #include <dt-bindings/phy/phy-imx8-pcie.h>
 
 / {
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon1>;
+		type = "micro";
+		label = "Type-C";
+		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	led-controller {
 		compatible = "gpio-leds";
 		pinctrl-names = "default";
@@ -132,13 +147,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon1>;
-		type = "micro";
-		label = "Type-C";
-		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi
index 28eb7c00a1d9..f8ad5ea96330 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi
@@ -8,6 +8,22 @@
 #include <dt-bindings/phy/phy-imx8-pcie.h>
 
 / {
+
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon1>;
+		type = "micro";
+		label = "otg";
+		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	led-controller {
 		compatible = "gpio-leds";
 		pinctrl-names = "default";
@@ -182,13 +198,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon1>;
-		type = "micro";
-		label = "otg";
-		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi
index b0d42b18c5ce..0b89aa73998c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi
@@ -8,6 +8,22 @@
 #include <dt-bindings/phy/phy-imx8-pcie.h>
 
 / {
+
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon1>;
+		type = "micro";
+		label = "otg";
+		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	led-controller {
 		compatible = "gpio-leds";
 		pinctrl-names = "default";
@@ -201,13 +217,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon1>;
-		type = "micro";
-		label = "otg";
-		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts
index dcf9bababffc..b323711fa090 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts
@@ -35,6 +35,22 @@ memory at 40000000 {
 		reg = <0x0 0x40000000 0 0x80000000>;
 	};
 
+
+	connector {
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon1>;
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		type = "micro";
+		label = "Type-C";
+		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
@@ -692,13 +708,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon1>;
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		type = "micro";
-		label = "Type-C";
-		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
-- 
2.34.1



From festevam at gmail.com  Thu Dec  7 10:55:43 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu,  7 Dec 2023 15:55:43 -0300
Subject: [PATCH 3/3] arm64: dts: imx8mp-tqma8mpql-mba8mpxl: Fix USB connector description
In-Reply-To: <20231207185543.2699697-1-festevam@gmail.com>
References: <20231207185543.2699697-1-festevam@gmail.com>
Message-ID: <20231207185543.2699697-3-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The USB connector should not be placed under the dwc3 node.

Move the USB connector out of the SoC level and use port to describe
the connection to the dwc3 controller.

This fixes the following dt-schema warning:

imx8mp-tqma8mpql-mba8mpxl.dtb: usb at 38100000: Unevaluated properties are not allowed ('connector' was unexpected)
	from schema $id: http://devicetree.org/schemas/usb/snps,dwc3.yaml#
	
Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 .../freescale/imx8mp-tqma8mpql-mba8mpxl.dts   | 26 ++++++++++++++-----
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
index 4b161564a284..505b70cb2bd7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
@@ -55,6 +55,21 @@ clk_xtal25: clk-xtal25 {
 		clock-frequency = <25000000>;
 	};
 
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		type = "micro";
+		label = "X29";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon0>;
+		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	fan0: pwm-fan {
 		compatible = "pwm-fan";
 		pinctrl-names = "default";
@@ -625,13 +640,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		type = "micro";
-		label = "X29";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon0>;
-		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
-- 
2.34.1



From lkp at intel.com  Thu Dec  7 11:06:59 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 8 Dec 2023 03:06:59 +0800
Subject: [PATCH net-next v3 5/8] net: qualcomm: ipqess: add bridge
 offloading features to the IPQESS driver
In-Reply-To: <20231114105600.1012056-6-romain.gantois@bootlin.com>
References: <20231114105600.1012056-6-romain.gantois@bootlin.com>
Message-ID: <202312080233.sRrkY9Q5-lkp@intel.com>

Hi Romain,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Romain-Gantois/dt-bindings-net-Introduce-the-Qualcomm-IPQESS-Ethernet-switch/20231114-185953
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231114105600.1012056-6-romain.gantois%40bootlin.com
patch subject: [PATCH net-next v3 5/8] net: qualcomm: ipqess: add bridge offloading features to the IPQESS driver
config: arc-randconfig-r112-20231116 (https://download.01.org/0day-ci/archive/20231208/202312080233.sRrkY9Q5-lkp at intel.com/config)
compiler: arc-elf-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231208/202312080233.sRrkY9Q5-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312080233.sRrkY9Q5-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/net/dsa/qca/qca8k-8xxx.c:1982:5: sparse: sparse: symbol 'qca8k_dsa_port_fdb_dump' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:1988:6: sparse: sparse: symbol 'qca8k_dsa_port_stp_state_set' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:1995:6: sparse: sparse: symbol 'qca8k_dsa_port_fast_age' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2000:5: sparse: sparse: symbol 'qca8k_dsa_set_ageing_time' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2005:5: sparse: sparse: symbol 'qca8k_dsa_port_vlan_filtering' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2012:5: sparse: sparse: symbol 'qca8k_dsa_vlan_add' was not declared. Should it be static?

vim +/qca8k_dsa_port_fdb_dump +1982 drivers/net/dsa/qca/qca8k-8xxx.c

  1981	
> 1982	int qca8k_dsa_port_fdb_dump(struct dsa_switch *ds, int port,
  1983				    dsa_fdb_dump_cb_t *cb, void *data)
  1984	{
  1985		return qca8k_port_fdb_dump(ds->priv, port, cb, data);
  1986	}
  1987	
> 1988	void qca8k_dsa_port_stp_state_set(struct dsa_switch *ds, int port,
  1989					  u8 state)
  1990	{
  1991		qca8k_port_stp_state_set(ds->priv, port, state,
  1992					 dsa_to_port(ds, port)->learning, true);
  1993	}
  1994	
> 1995	void qca8k_dsa_port_fast_age(struct dsa_switch *ds, int port)
  1996	{
  1997		qca8k_port_fast_age(ds->priv, port);
  1998	}
  1999	
> 2000	int qca8k_dsa_set_ageing_time(struct dsa_switch *ds, unsigned int msecs)
  2001	{
  2002		return qca8k_set_ageing_time(ds->priv, msecs);
  2003	}
  2004	
> 2005	int qca8k_dsa_port_vlan_filtering(struct dsa_switch *ds, int port,
  2006					  bool vlan_filtering,
  2007					  struct netlink_ext_ack *extack)
  2008	{
  2009		return qca8k_port_vlan_filtering(ds->priv, port, vlan_filtering);
  2010	}
  2011	
> 2012	int qca8k_dsa_vlan_add(struct dsa_switch *ds, int port,
  2013			       const struct switchdev_obj_port_vlan *vlan,
  2014			       struct netlink_ext_ack *extack)
  2015	{
  2016		return qca8k_port_vlan_add(ds->priv, port, vlan, extack);
  2017	}
  2018	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From sdonthineni at nvidia.com  Thu Dec  7 11:21:43 2023
From: sdonthineni at nvidia.com (Shanker Donthineni)
Date: Thu, 7 Dec 2023 13:21:43 -0600
Subject: [PATCH v2 1/1] arm_mpam: Introduce resctrl_arch_mbm_has_long_counter()
Message-ID: <20231207192143.302910-1-sdonthineni@nvidia.com>

It takes a substantial amount of time for long counters, which have more
than 32 bits, to cause overflow. To support enable/disable of a periodic
handler for monitoring memory bandwidth, introduce a common function
resctrl_arch_mbm_has_long_counter(). FOr MPAM, disable periodic handler
if the MSC component is capable of supporting 63-bit counters.

Signed-off-by: Shanker Donthineni <sdonthineni at nvidia.com>
---
Changes since v1:
 - Skip 32bit overflow of MBW when checking config mismatch

 arch/x86/include/asm/resctrl.h       |  5 +++++
 drivers/platform/mpam/mpam_devices.c |  2 ++
 drivers/platform/mpam/mpam_resctrl.c | 11 +++++++++++
 fs/resctrl/rdtgroup.c                |  9 +++++----
 include/linux/arm_mpam.h             |  1 +
 5 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/resctrl.h b/arch/x86/include/asm/resctrl.h
index 1adf16660ac10..96c7d86ab9b69 100644
--- a/arch/x86/include/asm/resctrl.h
+++ b/arch/x86/include/asm/resctrl.h
@@ -100,6 +100,11 @@ static inline bool resctrl_arch_is_mbm_local_enabled(void)
 	return (rdt_mon_features & (1 << QOS_L3_MBM_LOCAL_EVENT_ID));
 }
 
+static bool resctrl_arch_mbm_has_long_counter(void)
+{
+	return false;
+}
+
 /*
  * __resctrl_sched_in() - Writes the task's CLOSid/RMID to IA32_PQR_MSR
  *
diff --git a/drivers/platform/mpam/mpam_devices.c b/drivers/platform/mpam/mpam_devices.c
index f7bcf9737dcf8..5d90eaa66711d 100644
--- a/drivers/platform/mpam/mpam_devices.c
+++ b/drivers/platform/mpam/mpam_devices.c
@@ -870,6 +870,8 @@ static void read_msmon_ctl_flt_vals(struct mon_read *m, u32 *ctl_val,
 	case mpam_feat_msmon_mbwu:
 		*ctl_val = mpam_read_monsel_reg(msc, CFG_MBWU_CTL);
 		*flt_val = mpam_read_monsel_reg(msc, CFG_MBWU_FLT);
+		if (mpam_ris_has_mbwu_long_counter(m->ris))
+			*ctl_val &= ~MSMON_CFG_x_CTL_OFLOW_STATUS;
 		break;
 	default:
 		return;
diff --git a/drivers/platform/mpam/mpam_resctrl.c b/drivers/platform/mpam/mpam_resctrl.c
index 8ec963aca9d49..dee82b3c0dbe3 100644
--- a/drivers/platform/mpam/mpam_resctrl.c
+++ b/drivers/platform/mpam/mpam_resctrl.c
@@ -81,6 +81,17 @@ bool resctrl_arch_is_mbm_total_enabled(void)
 	return mbm_total_class;
 }
 
+bool resctrl_arch_mbm_has_long_counter(void)
+{
+	if (mbm_local_class)
+		return !!mpam_has_feature(mpam_feat_msmon_mbwu_63counter, &mbm_local_class->props);
+
+	if (mbm_total_class)
+		return !!mpam_has_feature(mpam_feat_msmon_mbwu_63counter, &mbm_total_class->props);
+
+	return false;
+}
+
 bool resctrl_arch_get_cdp_enabled(enum resctrl_res_level rid)
 {
 	switch (rid) {
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 43efed317f1b7..cff77915395b0 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -2774,7 +2774,7 @@ static int rdt_get_tree(struct fs_context *fc)
 	if (resctrl_arch_alloc_capable() || resctrl_arch_mon_capable())
 		resctrl_mounted = true;
 
-	if (resctrl_is_mbm_enabled()) {
+	if (resctrl_is_mbm_enabled() && (!resctrl_arch_mbm_has_long_counter())) {
 		list_for_each_entry(dom, &l3->domains, list)
 			mbm_setup_overflow_handler(dom, MBM_OVERFLOW_INTERVAL,
 						   RESCTRL_PICK_ANY_CPU);
@@ -4014,7 +4014,7 @@ static void _resctrl_offline_domain(struct rdt_resource *r,
 	if (resctrl_mounted && resctrl_arch_mon_capable())
 		rmdir_mondata_subdir_allrdtgrp(r, d->id);
 
-	if (resctrl_is_mbm_enabled())
+	if (resctrl_is_mbm_enabled() && (!resctrl_arch_mbm_has_long_counter()))
 		cancel_delayed_work(&d->mbm_over);
 	if (resctrl_arch_is_llc_occupancy_enabled() && has_busy_rmid(d)) {
 		/*
@@ -4087,7 +4087,7 @@ static int _resctrl_online_domain(struct rdt_resource *r, struct rdt_domain *d)
 	if (err)
 		return err;
 
-	if (resctrl_is_mbm_enabled()) {
+	if (resctrl_is_mbm_enabled() && (!resctrl_arch_mbm_has_long_counter())) {
 		INIT_DELAYED_WORK(&d->mbm_over, mbm_handle_overflow);
 		mbm_setup_overflow_handler(d, MBM_OVERFLOW_INTERVAL,
 					   RESCTRL_PICK_ANY_CPU);
@@ -4155,7 +4155,8 @@ void resctrl_offline_cpu(unsigned int cpu)
 
 	d = resctrl_get_domain_from_cpu(cpu, l3);
 	if (d) {
-		if (resctrl_is_mbm_enabled() && cpu == d->mbm_work_cpu) {
+		if (resctrl_is_mbm_enabled() && (!resctrl_arch_mbm_has_long_counter()) &&
+			cpu == d->mbm_work_cpu) {
 			cancel_delayed_work(&d->mbm_over);
 			mbm_setup_overflow_handler(d, 0, cpu);
 		}
diff --git a/include/linux/arm_mpam.h b/include/linux/arm_mpam.h
index 8b80745132723..766117c5ff555 100644
--- a/include/linux/arm_mpam.h
+++ b/include/linux/arm_mpam.h
@@ -79,6 +79,7 @@ bool resctrl_arch_mon_capable(void);
 bool resctrl_arch_is_llc_occupancy_enabled(void);
 bool resctrl_arch_is_mbm_local_enabled(void);
 bool resctrl_arch_is_mbm_total_enabled(void);
+bool resctrl_arch_mbm_has_long_counter(void);
 
 /* reset cached configurations, then all devices */
 void resctrl_arch_reset_resources(void);
-- 
2.25.1



From kan.liang at linux.intel.com  Thu Dec  7 11:23:33 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Thu,  7 Dec 2023 11:23:33 -0800
Subject: [PATCH V2 0/5] Clean up perf mem
Message-ID: <20231207192338.400336-1-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

Changes since V1:
- Fix strcmp of PMU name checking (Ravi)
- Fix "/," typo (Ian)
- Rename several functions with perf_pmu__mem_events prefix. (Ian)
- Fold the header removal patch into the patch where the cleanups made.
  (Arnaldo)
- Add reviewed-by and tested-by from Ian and Ravi

As discussed in the below thread, the patch set is to clean up perf mem.
https://lore.kernel.org/lkml/afefab15-cffc-4345-9cf4-c6a4128d4d9c at linux.intel.com/

Introduce generic functions perf_mem_events__ptr(),
perf_mem_events__name() ,and is_mem_loads_aux_event() to replace the
ARCH specific ones.
Simplify the perf_mem_event__supported().

Only keeps the ARCH-specific perf_mem_events array in the corresponding
mem-events.c for each ARCH.

There is no functional change.

The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
etc. But I can only test it on two Intel platforms.
Please give it try, if you have machines with other ARCHs.

Here are the test results:
Intel hybrid machine:

$perf mem record -e list
ldlat-loads  : available
ldlat-stores : available

$perf mem record -e ldlat-loads -v --ldlat 50
calling: record -e cpu_atom/mem-loads,ldlat=50/P -e cpu_core/mem-loads,ldlat=50/P

$perf mem record -v
calling: record -e cpu_atom/mem-loads,ldlat=30/P -e cpu_atom/mem-stores/P -e cpu_core/mem-loads,ldlat=30/P -e cpu_core/mem-stores/P

$perf mem record -t store -v
calling: record -e cpu_atom/mem-stores/P -e cpu_core/mem-stores/P


Intel SPR:
$perf mem record -e list
ldlat-loads  : available
ldlat-stores : available

$perf mem record -e ldlat-loads -v --ldlat 50
calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=50/}:P

$perf mem record -v
calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=30/}:P -e cpu/mem-stores/P

$perf mem record -t store -v
calling: record -e cpu/mem-stores/P

Kan Liang (5):
  perf mem: Add mem_events into the supported perf_pmu
  perf mem: Clean up perf_mem_events__ptr()
  perf mem: Clean up perf_mem_events__name()
  perf mem: Clean up perf_mem_event__supported()
  perf mem: Clean up is_mem_loads_aux_event()

 tools/perf/arch/arm64/util/mem-events.c   |  36 +----
 tools/perf/arch/arm64/util/pmu.c          |   6 +
 tools/perf/arch/powerpc/util/mem-events.c |  13 +-
 tools/perf/arch/powerpc/util/mem-events.h |   7 +
 tools/perf/arch/powerpc/util/pmu.c        |  11 ++
 tools/perf/arch/s390/util/pmu.c           |   3 +
 tools/perf/arch/x86/util/mem-events.c     |  99 ++----------
 tools/perf/arch/x86/util/pmu.c            |  11 ++
 tools/perf/builtin-c2c.c                  |  28 +++-
 tools/perf/builtin-mem.c                  |  28 +++-
 tools/perf/util/mem-events.c              | 181 +++++++++++++---------
 tools/perf/util/mem-events.h              |  15 +-
 tools/perf/util/pmu.c                     |   4 +-
 tools/perf/util/pmu.h                     |   7 +
 14 files changed, 233 insertions(+), 216 deletions(-)
 create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
 create mode 100644 tools/perf/arch/powerpc/util/pmu.c

-- 
2.35.1



From kan.liang at linux.intel.com  Thu Dec  7 11:23:34 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Thu,  7 Dec 2023 11:23:34 -0800
Subject: [PATCH V2 1/5] perf mem: Add mem_events into the supported perf_pmu
In-Reply-To: <20231207192338.400336-1-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
Message-ID: <20231207192338.400336-2-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

With the mem_events, perf doesn't need to read sysfs for each PMU to
find the mem-events-supported PMU. The patch also makes it possible to
clean up the related __weak functions later.

The patch is only to add the mem_events into the perf_pmu for all ARCHs.
It will be used in the later cleanup patches.

Reviewed-by: Ian Rogers <irogers at google.com>
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c | 4 ++--
 tools/perf/arch/arm64/util/mem-events.h | 7 +++++++
 tools/perf/arch/arm64/util/pmu.c        | 6 ++++++
 tools/perf/arch/s390/util/pmu.c         | 3 +++
 tools/perf/arch/x86/util/mem-events.c   | 4 ++--
 tools/perf/arch/x86/util/mem-events.h   | 9 +++++++++
 tools/perf/arch/x86/util/pmu.c          | 7 +++++++
 tools/perf/util/mem-events.c            | 2 +-
 tools/perf/util/mem-events.h            | 1 +
 tools/perf/util/pmu.c                   | 4 +++-
 tools/perf/util/pmu.h                   | 7 +++++++
 11 files changed, 48 insertions(+), 6 deletions(-)
 create mode 100644 tools/perf/arch/arm64/util/mem-events.h
 create mode 100644 tools/perf/arch/x86/util/mem-events.h

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index 3bcc5c7035c2..aaa4804922b4 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -4,7 +4,7 @@
 
 #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
 
-static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
 	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
 	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
 	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
@@ -17,7 +17,7 @@ struct perf_mem_event *perf_mem_events__ptr(int i)
 	if (i >= PERF_MEM_EVENTS__MAX)
 		return NULL;
 
-	return &perf_mem_events[i];
+	return &perf_mem_events_arm[i];
 }
 
 const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
diff --git a/tools/perf/arch/arm64/util/mem-events.h b/tools/perf/arch/arm64/util/mem-events.h
new file mode 100644
index 000000000000..5fc50be4be38
--- /dev/null
+++ b/tools/perf/arch/arm64/util/mem-events.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ARM64_MEM_EVENTS_H
+#define _ARM64_MEM_EVENTS_H
+
+extern struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX];
+
+#endif /* _ARM64_MEM_EVENTS_H */
diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
index 2a4eab2d160e..06ec9b838807 100644
--- a/tools/perf/arch/arm64/util/pmu.c
+++ b/tools/perf/arch/arm64/util/pmu.c
@@ -8,6 +8,12 @@
 #include <api/fs/fs.h>
 #include <math.h>
 
+void perf_pmu__arch_init(struct perf_pmu *pmu)
+{
+	if (!strcmp(pmu->name, "arm_spe_0"))
+		pmu->mem_events = perf_mem_events_arm;
+}
+
 const struct pmu_metrics_table *pmu_metrics_table__find(void)
 {
 	struct perf_pmu *pmu;
diff --git a/tools/perf/arch/s390/util/pmu.c b/tools/perf/arch/s390/util/pmu.c
index 886c30e001fa..225d7dc2379c 100644
--- a/tools/perf/arch/s390/util/pmu.c
+++ b/tools/perf/arch/s390/util/pmu.c
@@ -19,4 +19,7 @@ void perf_pmu__arch_init(struct perf_pmu *pmu)
 	    !strcmp(pmu->name, S390_PMUPAI_EXT) ||
 	    !strcmp(pmu->name, S390_PMUCPUM_CF))
 		pmu->selectable = true;
+
+	if (pmu->is_core)
+		pmu->mem_events = perf_mem_events;
 }
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 191b372f9a2d..2b81d229982c 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -16,13 +16,13 @@ static char mem_stores_name[100];
 
 #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
 
-static struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
 	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads"),
 	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores"),
 	E(NULL,			NULL,				NULL),
 };
 
-static struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
 	E(NULL,		NULL,		NULL),
 	E(NULL,		NULL,		NULL),
 	E("mem-ldst",	"ibs_op//",	"ibs_op"),
diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
new file mode 100644
index 000000000000..3959e427f482
--- /dev/null
+++ b/tools/perf/arch/x86/util/mem-events.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _X86_MEM_EVENTS_H
+#define _X86_MEM_EVENTS_H
+
+extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
+
+extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
+
+#endif /* _X86_MEM_EVENTS_H */
diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
index 469555ae9b3c..cd22e80e5657 100644
--- a/tools/perf/arch/x86/util/pmu.c
+++ b/tools/perf/arch/x86/util/pmu.c
@@ -15,6 +15,7 @@
 #include "../../../util/pmu.h"
 #include "../../../util/fncache.h"
 #include "../../../util/pmus.h"
+#include "mem-events.h"
 #include "env.h"
 
 void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
@@ -30,6 +31,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
 		pmu->selectable = true;
 	}
 #endif
+
+	if (x86__is_amd_cpu()) {
+		if (!strcmp(pmu->name, "ibs_op"))
+			pmu->mem_events = perf_mem_events_amd;
+	} else if (pmu->is_core)
+		pmu->mem_events = perf_mem_events_intel;
 }
 
 int perf_pmus__num_mem_pmus(void)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 3a2e3687878c..0a8f415f5efe 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -19,7 +19,7 @@ unsigned int perf_mem_events__loads_ldlat = 30;
 
 #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
 
-static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
 	E("ldlat-loads",	"cpu/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads"),
 	E("ldlat-stores",	"cpu/mem-stores/P",		"cpu/events/mem-stores"),
 	E(NULL,			NULL,				NULL),
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index b40ad6ea93fc..8c5694b2d0b0 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -34,6 +34,7 @@ enum {
 };
 
 extern unsigned int perf_mem_events__loads_ldlat;
+extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
 
 int perf_mem_events__parse(const char *str);
 int perf_mem_events__init(void);
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 3c9609944a2f..3d4373b8ab63 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -986,8 +986,10 @@ static int pmu_max_precise(int dirfd, struct perf_pmu *pmu)
 }
 
 void __weak
-perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
+perf_pmu__arch_init(struct perf_pmu *pmu)
 {
+	if (pmu->is_core)
+		pmu->mem_events = perf_mem_events;
 }
 
 struct perf_pmu *perf_pmu__lookup(struct list_head *pmus, int dirfd, const char *name)
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 424c3fee0949..e35d985206db 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -10,6 +10,8 @@
 #include <stdio.h>
 #include "parse-events.h"
 #include "pmu-events/pmu-events.h"
+#include "map_symbol.h"
+#include "mem-events.h"
 
 struct evsel_config_term;
 struct perf_cpu_map;
@@ -162,6 +164,11 @@ struct perf_pmu {
 		 */
 		bool exclude_guest;
 	} missing_features;
+
+	/**
+	 * @mem_events: List of the supported mem events
+	 */
+	struct perf_mem_event *mem_events;
 };
 
 /** @perf_pmu__fake: A special global PMU used for testing. */
-- 
2.35.1



From kan.liang at linux.intel.com  Thu Dec  7 11:23:36 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Thu,  7 Dec 2023 11:23:36 -0800
Subject: [PATCH V2 3/5] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <20231207192338.400336-1-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
Message-ID: <20231207192338.400336-4-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
one.

The mem_load events may have a different format. Add ldlat and aux_event
in the struct perf_mem_event to indicate the format and the extra aux
event.

Add perf_mem_events_intel_aux[] to support the extra mem_load_aux event.

Rename perf_mem_events__name to perf_pmu__mem_events_name.

Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c   | 26 ++-------
 tools/perf/arch/powerpc/util/mem-events.c | 13 ++---
 tools/perf/arch/powerpc/util/mem-events.h |  7 +++
 tools/perf/arch/powerpc/util/pmu.c        | 11 ++++
 tools/perf/arch/x86/util/mem-events.c     | 70 +++++------------------
 tools/perf/arch/x86/util/mem-events.h     |  1 +
 tools/perf/arch/x86/util/pmu.c            |  8 ++-
 tools/perf/util/mem-events.c              | 56 ++++++++++++------
 tools/perf/util/mem-events.h              |  3 +-
 9 files changed, 89 insertions(+), 106 deletions(-)
 create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
 create mode 100644 tools/perf/arch/powerpc/util/pmu.c

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index 2602e8688727..eb2ef84f0fc8 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -2,28 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
-	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
-	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
-	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
+	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0",	true,	0),
+	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0",	false,	0),
+	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0",	true,	0),
 };
-
-static char mem_ev_name[100];
-
-const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
-{
-	struct perf_mem_event *e = &perf_mem_events_arm[i];
-
-	if (i >= PERF_MEM_EVENTS__MAX)
-		return NULL;
-
-	if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE)
-		scnprintf(mem_ev_name, sizeof(mem_ev_name),
-			  e->name, perf_mem_events__loads_ldlat);
-	else /* PERF_MEM_EVENTS__STORE */
-		scnprintf(mem_ev_name, sizeof(mem_ev_name), e->name);
-
-	return mem_ev_name;
-}
diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
index 78b986e5268d..b7883e38950f 100644
--- a/tools/perf/arch/powerpc/util/mem-events.c
+++ b/tools/perf/arch/powerpc/util/mem-events.c
@@ -2,11 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-/* PowerPC does not support 'ldlat' parameter. */
-const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
-{
-	if (i == PERF_MEM_EVENTS__LOAD)
-		return "cpu/mem-loads/";
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
-	return "cpu/mem-stores/";
-}
+struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
+	E("ldlat-loads",	"%s/mem-loads/",	"cpu/events/mem-loads",		false,	0),
+	E("ldlat-stores",	"%s/mem-stores/",	"cpu/events/mem-stores",	false,	0),
+	E(NULL,			NULL,			NULL,				false,	0),
+};
diff --git a/tools/perf/arch/powerpc/util/mem-events.h b/tools/perf/arch/powerpc/util/mem-events.h
new file mode 100644
index 000000000000..6acc3d1b6873
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/mem-events.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _POWER_MEM_EVENTS_H
+#define _POWER_MEM_EVENTS_H
+
+extern struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX];
+
+#endif /* _POWER_MEM_EVENTS_H */
diff --git a/tools/perf/arch/powerpc/util/pmu.c b/tools/perf/arch/powerpc/util/pmu.c
new file mode 100644
index 000000000000..168173f88ddb
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/pmu.c
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <string.h>
+
+#include "../../../util/pmu.h"
+
+void perf_pmu__arch_init(struct perf_pmu *pmu)
+{
+	if (pmu->is_core)
+		pmu->mem_events = perf_mem_events_power;
+}
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 5fb41d50118d..f0e66a0151a0 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -7,25 +7,26 @@
 #include "linux/string.h"
 #include "env.h"
 
-static char mem_loads_name[100];
-static bool mem_loads_name__init;
-static char mem_stores_name[100];
-
 #define MEM_LOADS_AUX		0x8203
-#define MEM_LOADS_AUX_NAME     "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P"
 
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads"),
-	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores"),
-	E(NULL,			NULL,				NULL),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads",	true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,			false,	0),
+};
+
+struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
+	E("ldlat-loads",	"{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P",	"%s/events/mem-loads",	true,	MEM_LOADS_AUX),
+	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,			false,	0),
 };
 
 struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
-	E(NULL,		NULL,		NULL),
-	E(NULL,		NULL,		NULL),
-	E("mem-ldst",	"ibs_op//",	"ibs_op"),
+	E(NULL,		NULL,		NULL,		false,	0),
+	E(NULL,		NULL,		NULL,		false,	0),
+	E("mem-ldst",	"%s//",		"ibs_op",	false,	0),
 };
 
 bool is_mem_loads_aux_event(struct evsel *leader)
@@ -40,48 +41,3 @@ bool is_mem_loads_aux_event(struct evsel *leader)
 
 	return leader->core.attr.config == MEM_LOADS_AUX;
 }
-
-const char *perf_mem_events__name(int i, const char *pmu_name)
-{
-	struct perf_mem_event *e;
-
-	if (x86__is_amd_cpu())
-		e = &perf_mem_events_amd[i];
-	else
-		e = &perf_mem_events_intel[i];
-
-	if (!e)
-		return NULL;
-
-	if (i == PERF_MEM_EVENTS__LOAD) {
-		if (mem_loads_name__init && !pmu_name)
-			return mem_loads_name;
-
-		if (!pmu_name) {
-			mem_loads_name__init = true;
-			pmu_name = "cpu";
-		}
-
-		if (perf_pmus__have_event(pmu_name, "mem-loads-aux")) {
-			scnprintf(mem_loads_name, sizeof(mem_loads_name),
-				  MEM_LOADS_AUX_NAME, pmu_name, pmu_name,
-				  perf_mem_events__loads_ldlat);
-		} else {
-			scnprintf(mem_loads_name, sizeof(mem_loads_name),
-				  e->name, pmu_name,
-				  perf_mem_events__loads_ldlat);
-		}
-		return mem_loads_name;
-	}
-
-	if (i == PERF_MEM_EVENTS__STORE) {
-		if (!pmu_name)
-			pmu_name = "cpu";
-
-		scnprintf(mem_stores_name, sizeof(mem_stores_name),
-			  e->name, pmu_name);
-		return mem_stores_name;
-	}
-
-	return e->name;
-}
diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
index 3959e427f482..f55c8d3b7d59 100644
--- a/tools/perf/arch/x86/util/mem-events.h
+++ b/tools/perf/arch/x86/util/mem-events.h
@@ -3,6 +3,7 @@
 #define _X86_MEM_EVENTS_H
 
 extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
+extern struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX];
 
 extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
 
diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
index cd22e80e5657..0f49ff13cfe2 100644
--- a/tools/perf/arch/x86/util/pmu.c
+++ b/tools/perf/arch/x86/util/pmu.c
@@ -35,8 +35,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
 	if (x86__is_amd_cpu()) {
 		if (!strcmp(pmu->name, "ibs_op"))
 			pmu->mem_events = perf_mem_events_amd;
-	} else if (pmu->is_core)
-		pmu->mem_events = perf_mem_events_intel;
+	} else if (pmu->is_core) {
+		if (perf_pmu__have_event(pmu, "mem-loads-aux"))
+			pmu->mem_events = perf_mem_events_intel_aux;
+		else
+			pmu->mem_events = perf_mem_events_intel;
+	}
 }
 
 int perf_pmus__num_mem_pmus(void)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 27a33dc44964..c9a40b64e538 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -17,17 +17,17 @@
 
 unsigned int perf_mem_events__loads_ldlat = 30;
 
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"cpu/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads"),
-	E("ldlat-stores",	"cpu/mem-stores/P",		"cpu/events/mem-stores"),
-	E(NULL,			NULL,				NULL),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads",		true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"cpu/events/mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,				false,	0),
 };
 #undef E
 
 static char mem_loads_name[100];
-static bool mem_loads_name__init;
+static char mem_stores_name[100];
 
 struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i)
 {
@@ -62,23 +62,45 @@ struct perf_pmu *perf_mem_events_find_pmu(void)
 	return perf_pmus__scan_mem(NULL);
 }
 
-const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
+static const char *perf_pmu__mem_events_name(int i, struct perf_pmu *pmu)
 {
-	struct perf_mem_event *e = &perf_mem_events[i];
+	struct perf_mem_event *e = &pmu->mem_events[i];
 
 	if (!e)
 		return NULL;
 
-	if (i == PERF_MEM_EVENTS__LOAD) {
-		if (!mem_loads_name__init) {
-			mem_loads_name__init = true;
-			scnprintf(mem_loads_name, sizeof(mem_loads_name),
-				  e->name, perf_mem_events__loads_ldlat);
+	if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE) {
+		if (e->ldlat) {
+			if (!e->aux_event) {
+				/* ARM and Most of Intel */
+				scnprintf(mem_loads_name, sizeof(mem_loads_name),
+					  e->name, pmu->name,
+					  perf_mem_events__loads_ldlat);
+			} else {
+				/* Intel with mem-loads-aux event */
+				scnprintf(mem_loads_name, sizeof(mem_loads_name),
+					  e->name, pmu->name, pmu->name,
+					  perf_mem_events__loads_ldlat);
+			}
+		} else {
+			if (!e->aux_event) {
+				/* AMD and POWER */
+				scnprintf(mem_loads_name, sizeof(mem_loads_name),
+					  e->name, pmu->name);
+			} else
+				return NULL;
 		}
+
 		return mem_loads_name;
 	}
 
-	return e->name;
+	if (i == PERF_MEM_EVENTS__STORE) {
+		scnprintf(mem_stores_name, sizeof(mem_stores_name),
+			  e->name, pmu->name);
+		return mem_stores_name;
+	}
+
+	return NULL;
 }
 
 __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
@@ -175,7 +197,7 @@ void perf_pmu__mem_events_list(struct perf_pmu *pmu)
 			e->tag ? 13 : 0,
 			e->tag ? : "",
 			e->tag && verbose > 0 ? 25 : 0,
-			e->tag && verbose > 0 ? perf_mem_events__name(j, NULL) : "",
+			e->tag && verbose > 0 ? perf_pmu__mem_events_name(j, pmu) : "",
 			e->supported ? ": available\n" : "");
 	}
 }
@@ -198,15 +220,15 @@ int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 
 			if (!e->supported) {
 				pr_err("failed: event '%s' not supported\n",
-					perf_mem_events__name(j, pmu->name));
+					perf_pmu__mem_events_name(j, pmu));
 				return -1;
 			}
 
 			if (perf_pmus__num_mem_pmus() == 1) {
 				rec_argv[i++] = "-e";
-				rec_argv[i++] = perf_mem_events__name(j, NULL);
+				rec_argv[i++] = perf_pmu__mem_events_name(j, pmu);
 			} else {
-				const char *s = perf_mem_events__name(j, pmu->name);
+				const char *s = perf_pmu__mem_events_name(j, pmu);
 
 				if (!perf_mem_event__supported(mnt, pmu, e))
 					continue;
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index 0ad301a2e424..79d342768d12 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -14,6 +14,8 @@
 struct perf_mem_event {
 	bool		record;
 	bool		supported;
+	bool		ldlat;
+	u32		aux_event;
 	const char	*tag;
 	const char	*name;
 	const char	*sysfs_name;
@@ -39,7 +41,6 @@ extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
 int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str);
 int perf_pmu__mem_events_init(struct perf_pmu *pmu);
 
-const char *perf_mem_events__name(int i, const char *pmu_name);
 struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i);
 struct perf_pmu *perf_mem_events_find_pmu(void);
 bool is_mem_loads_aux_event(struct evsel *leader);
-- 
2.35.1



From kan.liang at linux.intel.com  Thu Dec  7 11:23:35 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Thu,  7 Dec 2023 11:23:35 -0800
Subject: [PATCH V2 2/5] perf mem: Clean up perf_mem_events__ptr()
In-Reply-To: <20231207192338.400336-1-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
Message-ID: <20231207192338.400336-3-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

The mem_events can be retrieved from the struct perf_pmu now. An ARCH
specific perf_mem_events__ptr() is not required anymore. Remove all of
them.

The Intel hybrid has multiple mem-events-supported PMUs. But they share
the same mem_events. Other ARCHs only support one mem-events-supported
PMU. In the configuration, it's good enough to only configure the
mem_events for one PMU. Add perf_mem_events_find_pmu() which returns the
first mem-events-supported PMU.

In the perf_mem_events__init(), the perf_pmus__scan() is not required
anymore. It avoids checking the sysfs for every PMU on the system.

Make the perf_mem_events__record_args() more generic. Remove the
perf_mem_events__print_unsupport_hybrid().

Since pmu is added as a new parameter, rename perf_mem_events__ptr() to
perf_pmu__mem_events_ptr(). Several other functions also do a similar
rename.

Reviewed-by: Ian Rogers <irogers at google.com>
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c |  10 +--
 tools/perf/arch/x86/util/mem-events.c   |  18 ++---
 tools/perf/builtin-c2c.c                |  28 +++++--
 tools/perf/builtin-mem.c                |  28 +++++--
 tools/perf/util/mem-events.c            | 103 ++++++++++++------------
 tools/perf/util/mem-events.h            |   9 ++-
 6 files changed, 104 insertions(+), 92 deletions(-)

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index aaa4804922b4..2602e8688727 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -12,17 +12,9 @@ struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
 
 static char mem_ev_name[100];
 
-struct perf_mem_event *perf_mem_events__ptr(int i)
-{
-	if (i >= PERF_MEM_EVENTS__MAX)
-		return NULL;
-
-	return &perf_mem_events_arm[i];
-}
-
 const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
 {
-	struct perf_mem_event *e = perf_mem_events__ptr(i);
+	struct perf_mem_event *e = &perf_mem_events_arm[i];
 
 	if (i >= PERF_MEM_EVENTS__MAX)
 		return NULL;
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 2b81d229982c..5fb41d50118d 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -28,17 +28,6 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
 	E("mem-ldst",	"ibs_op//",	"ibs_op"),
 };
 
-struct perf_mem_event *perf_mem_events__ptr(int i)
-{
-	if (i >= PERF_MEM_EVENTS__MAX)
-		return NULL;
-
-	if (x86__is_amd_cpu())
-		return &perf_mem_events_amd[i];
-
-	return &perf_mem_events_intel[i];
-}
-
 bool is_mem_loads_aux_event(struct evsel *leader)
 {
 	struct perf_pmu *pmu = perf_pmus__find("cpu");
@@ -54,7 +43,12 @@ bool is_mem_loads_aux_event(struct evsel *leader)
 
 const char *perf_mem_events__name(int i, const char *pmu_name)
 {
-	struct perf_mem_event *e = perf_mem_events__ptr(i);
+	struct perf_mem_event *e;
+
+	if (x86__is_amd_cpu())
+		e = &perf_mem_events_amd[i];
+	else
+		e = &perf_mem_events_intel[i];
 
 	if (!e)
 		return NULL;
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index a4cf9de7a7b5..e5b7dc7a80e3 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -3215,12 +3215,19 @@ static int parse_record_events(const struct option *opt,
 			       const char *str, int unset __maybe_unused)
 {
 	bool *event_set = (bool *) opt->value;
+	struct perf_pmu *pmu;
+
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: there is no PMU that supports perf c2c\n");
+		exit(-1);
+	}
 
 	if (!strcmp(str, "list")) {
-		perf_mem_events__list();
+		perf_pmu__mem_events_list(pmu);
 		exit(0);
 	}
-	if (perf_mem_events__parse(str))
+	if (perf_pmu__mem_events_parse(pmu, str))
 		exit(-1);
 
 	*event_set = true;
@@ -3245,6 +3252,7 @@ static int perf_c2c__record(int argc, const char **argv)
 	bool all_user = false, all_kernel = false;
 	bool event_set = false;
 	struct perf_mem_event *e;
+	struct perf_pmu *pmu;
 	struct option options[] = {
 	OPT_CALLBACK('e', "event", &event_set, "event",
 		     "event selector. Use 'perf c2c record -e list' to list available events",
@@ -3256,7 +3264,13 @@ static int perf_c2c__record(int argc, const char **argv)
 	OPT_END()
 	};
 
-	if (perf_mem_events__init()) {
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: no PMU supports the memory events\n");
+		return -1;
+	}
+
+	if (perf_pmu__mem_events_init(pmu)) {
 		pr_err("failed: memory events not supported\n");
 		return -1;
 	}
@@ -3280,7 +3294,7 @@ static int perf_c2c__record(int argc, const char **argv)
 	rec_argv[i++] = "record";
 
 	if (!event_set) {
-		e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD_STORE);
+		e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD_STORE);
 		/*
 		 * The load and store operations are required, use the event
 		 * PERF_MEM_EVENTS__LOAD_STORE if it is supported.
@@ -3289,15 +3303,15 @@ static int perf_c2c__record(int argc, const char **argv)
 			e->record = true;
 			rec_argv[i++] = "-W";
 		} else {
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+			e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD);
 			e->record = true;
 
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__STORE);
+			e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__STORE);
 			e->record = true;
 		}
 	}
 
-	e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+	e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD);
 	if (e->record)
 		rec_argv[i++] = "-W";
 
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index 51499c20da01..ef64bae77ca7 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -43,12 +43,19 @@ static int parse_record_events(const struct option *opt,
 			       const char *str, int unset __maybe_unused)
 {
 	struct perf_mem *mem = *(struct perf_mem **)opt->value;
+	struct perf_pmu *pmu;
+
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: there is no PMU that supports perf mem\n");
+		exit(-1);
+	}
 
 	if (!strcmp(str, "list")) {
-		perf_mem_events__list();
+		perf_pmu__mem_events_list(pmu);
 		exit(0);
 	}
-	if (perf_mem_events__parse(str))
+	if (perf_pmu__mem_events_parse(pmu, str))
 		exit(-1);
 
 	mem->operation = 0;
@@ -72,6 +79,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 	int ret;
 	bool all_user = false, all_kernel = false;
 	struct perf_mem_event *e;
+	struct perf_pmu *pmu;
 	struct option options[] = {
 	OPT_CALLBACK('e', "event", &mem, "event",
 		     "event selector. use 'perf mem record -e list' to list available events",
@@ -84,7 +92,13 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 	OPT_END()
 	};
 
-	if (perf_mem_events__init()) {
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: no PMU supports the memory events\n");
+		return -1;
+	}
+
+	if (perf_pmu__mem_events_init(pmu)) {
 		pr_err("failed: memory events not supported\n");
 		return -1;
 	}
@@ -113,7 +127,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 
 	rec_argv[i++] = "record";
 
-	e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD_STORE);
+	e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD_STORE);
 
 	/*
 	 * The load and store operations are required, use the event
@@ -126,17 +140,17 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 		rec_argv[i++] = "-W";
 	} else {
 		if (mem->operation & MEM_OPERATION_LOAD) {
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+			e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD);
 			e->record = true;
 		}
 
 		if (mem->operation & MEM_OPERATION_STORE) {
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__STORE);
+			e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__STORE);
 			e->record = true;
 		}
 	}
 
-	e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+	e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD);
 	if (e->record)
 		rec_argv[i++] = "-W";
 
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 0a8f415f5efe..27a33dc44964 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -29,17 +29,42 @@ struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
 static char mem_loads_name[100];
 static bool mem_loads_name__init;
 
-struct perf_mem_event * __weak perf_mem_events__ptr(int i)
+struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i)
 {
-	if (i >= PERF_MEM_EVENTS__MAX)
+	if (i >= PERF_MEM_EVENTS__MAX || !pmu)
 		return NULL;
 
-	return &perf_mem_events[i];
+	return &pmu->mem_events[i];
+}
+
+static struct perf_pmu *perf_pmus__scan_mem(struct perf_pmu *pmu)
+{
+	while ((pmu = perf_pmus__scan(pmu)) != NULL) {
+		if (pmu->mem_events)
+			return pmu;
+	}
+	return NULL;
+}
+
+struct perf_pmu *perf_mem_events_find_pmu(void)
+{
+	/*
+	 * The current perf mem doesn't support per-PMU configuration.
+	 * The exact same configuration is applied to all the
+	 * mem_events supported PMUs.
+	 * Return the first mem_events supported PMU.
+	 *
+	 * Notes: The only case which may support multiple mem_events
+	 * supported PMUs is Intel hybrid. The exact same mem_events
+	 * is shared among the PMUs. Only configure the first PMU
+	 * is good enough as well.
+	 */
+	return perf_pmus__scan_mem(NULL);
 }
 
 const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
 {
-	struct perf_mem_event *e = perf_mem_events__ptr(i);
+	struct perf_mem_event *e = &perf_mem_events[i];
 
 	if (!e)
 		return NULL;
@@ -61,7 +86,7 @@ __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
 	return false;
 }
 
-int perf_mem_events__parse(const char *str)
+int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str)
 {
 	char *tok, *saveptr = NULL;
 	bool found = false;
@@ -79,7 +104,7 @@ int perf_mem_events__parse(const char *str)
 
 	while (tok) {
 		for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-			struct perf_mem_event *e = perf_mem_events__ptr(j);
+			struct perf_mem_event *e = perf_pmu__mem_events_ptr(pmu, j);
 
 			if (!e->tag)
 				continue;
@@ -112,7 +137,7 @@ static bool perf_mem_event__supported(const char *mnt, struct perf_pmu *pmu,
 	return !stat(path, &st);
 }
 
-int perf_mem_events__init(void)
+int perf_pmu__mem_events_init(struct perf_pmu *pmu)
 {
 	const char *mnt = sysfs__mount();
 	bool found = false;
@@ -122,8 +147,7 @@ int perf_mem_events__init(void)
 		return -ENOENT;
 
 	for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-		struct perf_mem_event *e = perf_mem_events__ptr(j);
-		struct perf_pmu *pmu = NULL;
+		struct perf_mem_event *e = perf_pmu__mem_events_ptr(pmu, j);
 
 		/*
 		 * If the event entry isn't valid, skip initialization
@@ -132,29 +156,20 @@ int perf_mem_events__init(void)
 		if (!e->tag)
 			continue;
 
-		/*
-		 * Scan all PMUs not just core ones, since perf mem/c2c on
-		 * platforms like AMD uses IBS OP PMU which is independent
-		 * of core PMU.
-		 */
-		while ((pmu = perf_pmus__scan(pmu)) != NULL) {
-			e->supported |= perf_mem_event__supported(mnt, pmu, e);
-			if (e->supported) {
-				found = true;
-				break;
-			}
-		}
+		e->supported |= perf_mem_event__supported(mnt, pmu, e);
+		if (e->supported)
+			found = true;
 	}
 
 	return found ? 0 : -ENOENT;
 }
 
-void perf_mem_events__list(void)
+void perf_pmu__mem_events_list(struct perf_pmu *pmu)
 {
 	int j;
 
 	for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-		struct perf_mem_event *e = perf_mem_events__ptr(j);
+		struct perf_mem_event *e = perf_pmu__mem_events_ptr(pmu, j);
 
 		fprintf(stderr, "%-*s%-*s%s",
 			e->tag ? 13 : 0,
@@ -165,50 +180,32 @@ void perf_mem_events__list(void)
 	}
 }
 
-static void perf_mem_events__print_unsupport_hybrid(struct perf_mem_event *e,
-						    int idx)
-{
-	const char *mnt = sysfs__mount();
-	struct perf_pmu *pmu = NULL;
-
-	while ((pmu = perf_pmus__scan(pmu)) != NULL) {
-		if (!perf_mem_event__supported(mnt, pmu, e)) {
-			pr_err("failed: event '%s' not supported\n",
-			       perf_mem_events__name(idx, pmu->name));
-		}
-	}
-}
-
 int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 				 char **rec_tmp, int *tmp_nr)
 {
 	const char *mnt = sysfs__mount();
+	struct perf_pmu *pmu = NULL;
 	int i = *argv_nr, k = 0;
 	struct perf_mem_event *e;
 
-	for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-		e = perf_mem_events__ptr(j);
-		if (!e->record)
-			continue;
 
-		if (perf_pmus__num_mem_pmus() == 1) {
-			if (!e->supported) {
-				pr_err("failed: event '%s' not supported\n",
-				       perf_mem_events__name(j, NULL));
-				return -1;
-			}
+	while ((pmu = perf_pmus__scan_mem(pmu)) != NULL) {
+		for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
+			e = perf_pmu__mem_events_ptr(pmu, j);
 
-			rec_argv[i++] = "-e";
-			rec_argv[i++] = perf_mem_events__name(j, NULL);
-		} else {
-			struct perf_pmu *pmu = NULL;
+			if (!e->record)
+				continue;
 
 			if (!e->supported) {
-				perf_mem_events__print_unsupport_hybrid(e, j);
+				pr_err("failed: event '%s' not supported\n",
+					perf_mem_events__name(j, pmu->name));
 				return -1;
 			}
 
-			while ((pmu = perf_pmus__scan(pmu)) != NULL) {
+			if (perf_pmus__num_mem_pmus() == 1) {
+				rec_argv[i++] = "-e";
+				rec_argv[i++] = perf_mem_events__name(j, NULL);
+			} else {
 				const char *s = perf_mem_events__name(j, pmu->name);
 
 				if (!perf_mem_event__supported(mnt, pmu, e))
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index 8c5694b2d0b0..0ad301a2e424 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -36,14 +36,15 @@ enum {
 extern unsigned int perf_mem_events__loads_ldlat;
 extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
 
-int perf_mem_events__parse(const char *str);
-int perf_mem_events__init(void);
+int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str);
+int perf_pmu__mem_events_init(struct perf_pmu *pmu);
 
 const char *perf_mem_events__name(int i, const char *pmu_name);
-struct perf_mem_event *perf_mem_events__ptr(int i);
+struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i);
+struct perf_pmu *perf_mem_events_find_pmu(void);
 bool is_mem_loads_aux_event(struct evsel *leader);
 
-void perf_mem_events__list(void);
+void perf_pmu__mem_events_list(struct perf_pmu *pmu);
 int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 				 char **rec_tmp, int *tmp_nr);
 
-- 
2.35.1



From kan.liang at linux.intel.com  Thu Dec  7 11:23:38 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Thu,  7 Dec 2023 11:23:38 -0800
Subject: [PATCH V2 5/5] perf mem: Clean up is_mem_loads_aux_event()
In-Reply-To: <20231207192338.400336-1-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
Message-ID: <20231207192338.400336-6-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

The aux_event can be retrieved from the perf_pmu now. Implement a
generic support.

Reviewed-by: Ian Rogers <irogers at google.com>
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/x86/util/mem-events.c | 23 ++++-------------------
 tools/perf/util/mem-events.c          | 14 ++++++++++++--
 2 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index b776d849fc64..62df03e91c7e 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -1,11 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
-#include "util/pmu.h"
-#include "util/pmus.h"
-#include "util/env.h"
-#include "map_symbol.h"
-#include "mem-events.h"
 #include "linux/string.h"
-#include "env.h"
+#include "util/map_symbol.h"
+#include "util/mem-events.h"
+#include "mem-events.h"
+
 
 #define MEM_LOADS_AUX		0x8203
 
@@ -28,16 +26,3 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
 	E(NULL,		NULL,		NULL,	false,	0),
 	E("mem-ldst",	"%s//",		NULL,	false,	0),
 };
-
-bool is_mem_loads_aux_event(struct evsel *leader)
-{
-	struct perf_pmu *pmu = perf_pmus__find("cpu");
-
-	if (!pmu)
-		pmu = perf_pmus__find("cpu_core");
-
-	if (pmu && !perf_pmu__have_event(pmu, "mem-loads-aux"))
-		return false;
-
-	return leader->core.attr.config == MEM_LOADS_AUX;
-}
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 0d174f161034..d418320e52e3 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -103,9 +103,19 @@ static const char *perf_pmu__mem_events_name(int i, struct perf_pmu *pmu)
 	return NULL;
 }
 
-__weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
+bool is_mem_loads_aux_event(struct evsel *leader)
 {
-	return false;
+	struct perf_pmu *pmu = leader->pmu;
+	struct perf_mem_event *e;
+
+	if (!pmu || !pmu->mem_events)
+		return false;
+
+	e = &pmu->mem_events[PERF_MEM_EVENTS__LOAD];
+	if (!e->aux_event)
+		return false;
+
+	return leader->core.attr.config == e->aux_event;
 }
 
 int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str)
-- 
2.35.1



From kan.liang at linux.intel.com  Thu Dec  7 11:23:37 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Thu,  7 Dec 2023 11:23:37 -0800
Subject: [PATCH V2 4/5] perf mem: Clean up perf_mem_event__supported()
In-Reply-To: <20231207192338.400336-1-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
Message-ID: <20231207192338.400336-5-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

For some ARCHs, e.g., ARM and AMD, to get the availability of the
mem-events, perf checks the existence of a specific PMU. For the other
ARCHs, e.g., Intel and Power, perf has to check the existence of some
specific events.

The current perf only iterates the mem-events-supported PMUs. It's not
required to check the existence of a specific PMU anymore.

Rename sysfs_name to event_name, which stores the specific mem-events.
Perf only needs to check those events for the availability of the
mem-events.

Rename perf_mem_event__supported to perf_pmu__mem_events_supported.

Reviewed-by: Ian Rogers <irogers at google.com>
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c   |  8 ++++----
 tools/perf/arch/powerpc/util/mem-events.c |  8 ++++----
 tools/perf/arch/x86/util/mem-events.c     | 20 ++++++++++----------
 tools/perf/util/mem-events.c              | 22 ++++++++++++----------
 tools/perf/util/mem-events.h              |  2 +-
 5 files changed, 31 insertions(+), 29 deletions(-)

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index eb2ef84f0fc8..590dddd6b0ab 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -2,10 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
-	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0",	true,	0),
-	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0",	false,	0),
-	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0",	true,	0),
+	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	NULL,	true,	0),
+	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			NULL,	false,	0),
+	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	NULL,	true,	0),
 };
diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
index b7883e38950f..72a6ac2b52f5 100644
--- a/tools/perf/arch/powerpc/util/mem-events.c
+++ b/tools/perf/arch/powerpc/util/mem-events.c
@@ -2,10 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads/",	"cpu/events/mem-loads",		false,	0),
-	E("ldlat-stores",	"%s/mem-stores/",	"cpu/events/mem-stores",	false,	0),
-	E(NULL,			NULL,			NULL,				false,	0),
+	E("ldlat-loads",	"%s/mem-loads/",	"mem-loads",	false,	0),
+	E("ldlat-stores",	"%s/mem-stores/",	"mem-stores",	false,	0),
+	E(NULL,			NULL,			NULL,		false,	0),
 };
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index f0e66a0151a0..b776d849fc64 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -9,24 +9,24 @@
 
 #define MEM_LOADS_AUX		0x8203
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads",	true,	0),
-	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
-	E(NULL,			NULL,				NULL,			false,	0),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"mem-loads",	true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,		false,	0),
 };
 
 struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P",	"%s/events/mem-loads",	true,	MEM_LOADS_AUX),
-	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
-	E(NULL,			NULL,				NULL,			false,	0),
+	E("ldlat-loads",	"{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P",	"mem-loads",	true,	MEM_LOADS_AUX),
+	E("ldlat-stores",	"%s/mem-stores/P",		"mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,		false,	0),
 };
 
 struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
-	E(NULL,		NULL,		NULL,		false,	0),
-	E(NULL,		NULL,		NULL,		false,	0),
-	E("mem-ldst",	"%s//",		"ibs_op",	false,	0),
+	E(NULL,		NULL,		NULL,	false,	0),
+	E(NULL,		NULL,		NULL,	false,	0),
+	E("mem-ldst",	"%s//",		NULL,	false,	0),
 };
 
 bool is_mem_loads_aux_event(struct evsel *leader)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index c9a40b64e538..0d174f161034 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -17,12 +17,12 @@
 
 unsigned int perf_mem_events__loads_ldlat = 30;
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads",		true,	0),
-	E("ldlat-stores",	"%s/mem-stores/P",		"cpu/events/mem-stores",	false,	0),
-	E(NULL,			NULL,				NULL,				false,	0),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"mem-loads",	true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,		false,	0),
 };
 #undef E
 
@@ -147,15 +147,17 @@ int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str)
 	return -1;
 }
 
-static bool perf_mem_event__supported(const char *mnt, struct perf_pmu *pmu,
+static bool perf_pmu__mem_events_supported(const char *mnt, struct perf_pmu *pmu,
 				      struct perf_mem_event *e)
 {
-	char sysfs_name[100];
 	char path[PATH_MAX];
 	struct stat st;
 
-	scnprintf(sysfs_name, sizeof(sysfs_name), e->sysfs_name, pmu->name);
-	scnprintf(path, PATH_MAX, "%s/devices/%s", mnt, sysfs_name);
+	if (!e->event_name)
+		return true;
+
+	scnprintf(path, PATH_MAX, "%s/devices/%s/events/%s", mnt, pmu->name, e->event_name);
+
 	return !stat(path, &st);
 }
 
@@ -178,7 +180,7 @@ int perf_pmu__mem_events_init(struct perf_pmu *pmu)
 		if (!e->tag)
 			continue;
 
-		e->supported |= perf_mem_event__supported(mnt, pmu, e);
+		e->supported |= perf_pmu__mem_events_supported(mnt, pmu, e);
 		if (e->supported)
 			found = true;
 	}
@@ -230,7 +232,7 @@ int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 			} else {
 				const char *s = perf_pmu__mem_events_name(j, pmu);
 
-				if (!perf_mem_event__supported(mnt, pmu, e))
+				if (!perf_pmu__mem_events_supported(mnt, pmu, e))
 					continue;
 
 				rec_argv[i++] = "-e";
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index 79d342768d12..f817a507b106 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -18,7 +18,7 @@ struct perf_mem_event {
 	u32		aux_event;
 	const char	*tag;
 	const char	*name;
-	const char	*sysfs_name;
+	const char	*event_name;
 };
 
 struct mem_info {
-- 
2.35.1



From Liam.Howlett at oracle.com  Thu Dec  7 11:33:19 2023
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Thu,  7 Dec 2023 14:33:19 -0500
Subject: [PATCH] maple_tree: Fix mas_prev() state separation code
In-Reply-To: <20231207014104.n6vul2ylgqjnsfia@revolve>
References: <20231207014104.n6vul2ylgqjnsfia@revolve>
Message-ID: <20231207193319.4025462-1-Liam.Howlett@oracle.com>

mas_prev() was setting the ma_underflow condition when the limit was
reached and not when the limit was attempting to go lower.  This
resulted in the incorrect behaviour on subsequent actions.

This commit fixes the status setting to only set ma_underflow when the
lower limit is attempted to be decremented, and modifies the testing to
ensure that's the case.

Signed-off-by: Liam R. Howlett <Liam.Howlett at oracle.com>
---

Andrew,

This should be clean to squash into 7f79fdb1d94d7 ("maple_tree: separate
ma_state node from status.") which is currently in your mm-unstable
branch.

Thanks,
Liam


 lib/maple_tree.c      | 16 ++++++++++++----
 lib/test_maple_tree.c |  9 +++++++--
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 89f8d21602774..47f2a7a973852 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -4432,6 +4432,9 @@ static void *mas_prev_slot(struct ma_state *mas, unsigned long min, bool empty)
 		mas->last = mas->index - 1;
 		mas->index = mas_safe_min(mas, pivots, mas->offset);
 	} else  {
+		if (mas->index <= min)
+			goto underflow;
+
 		if (mas_prev_node(mas, min)) {
 			mas_rewalk(mas, save_point);
 			goto retry;
@@ -4452,15 +4455,15 @@ static void *mas_prev_slot(struct ma_state *mas, unsigned long min, bool empty)
 	if (unlikely(mas_rewalk_if_dead(mas, node, save_point)))
 		goto retry;
 
-	if (mas->index <= min)
-		mas->status = ma_underflow;
 
 	if (likely(entry))
 		return entry;
 
 	if (!empty) {
-		if (mas_is_underflow(mas))
+		if (mas->index <= min) {
+			mas->status = ma_underflow;
 			return NULL;
+		}
 
 		goto again;
 	}
@@ -4596,7 +4599,7 @@ static void *mas_next_slot(struct ma_state *mas, unsigned long max, bool empty)
 		if (unlikely(mas_rewalk_if_dead(mas, node, save_point)))
 			goto retry;
 
-		if (pivot >= max) {
+		if (pivot >= max) { /* Was at the limit, next will extend beyond */
 			mas->status = ma_overflow;
 			return NULL;
 		}
@@ -4611,6 +4614,11 @@ static void *mas_next_slot(struct ma_state *mas, unsigned long max, bool empty)
 		else
 			mas->last = mas->max;
 	} else  {
+		if (mas->last >= max) {
+			mas->status = ma_overflow;
+			return NULL;
+		}
+
 		if (mas_next_node(mas, node, max)) {
 			mas_rewalk(mas, save_point);
 			goto retry;
diff --git a/lib/test_maple_tree.c b/lib/test_maple_tree.c
index 15fbeb788f3ac..29185ac5c727f 100644
--- a/lib/test_maple_tree.c
+++ b/lib/test_maple_tree.c
@@ -3294,8 +3294,8 @@ static noinline void __init check_state_handling(struct maple_tree *mt)
 	MT_BUG_ON(mt, mas.last != 0x1500);
 	MT_BUG_ON(mt, !mas_is_active(&mas));
 
-	/* next:active ->active */
-	entry = mas_next(&mas, ULONG_MAX);
+	/* next:active ->active (spanning limit) */
+	entry = mas_next(&mas, 0x2100);
 	MT_BUG_ON(mt, entry != ptr2);
 	MT_BUG_ON(mt, mas.index != 0x2000);
 	MT_BUG_ON(mt, mas.last != 0x2500);
@@ -3360,6 +3360,11 @@ static noinline void __init check_state_handling(struct maple_tree *mt)
 	MT_BUG_ON(mt, entry != ptr);
 	MT_BUG_ON(mt, mas.index != 0x1000);
 	MT_BUG_ON(mt, mas.last != 0x1500);
+	MT_BUG_ON(mt, !mas_is_active(&mas)); /* spanning limit */
+	entry = mas_prev(&mas, 0x1200); /* underflow */
+	MT_BUG_ON(mt, entry != NULL);
+	MT_BUG_ON(mt, mas.index != 0x1000);
+	MT_BUG_ON(mt, mas.last != 0x1500);
 	MT_BUG_ON(mt, !mas_is_underflow(&mas));
 
 	/* prev:underflow -> underflow (lower limit) spanning end range */
-- 
2.40.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:21 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:21 -0500
Subject: [PATCH v2 0/9] PCI: imx6: Clean up and add imx95 pci support
Message-ID: <20231207193430.431994-1-Frank.Li@nxp.com>

first 6 patches use drvdata: flags to simplify some switch-case code.
Improve maintaince and easy to read code.

Then add imx95 basic pci host function.

Change log see each patch.
Means no change if not specific change in notes.

Frank Li (8):
  PCI: imx6: Simplify clock handling by using HAS_CLK_* bitmask
  PCI: imx6: Simplify phy handling by using by using
    IMX6_PCIE_FLAG_HAS_PHY
  PCI: imx6: Simplify reset handling by using by using
    *_FLAG_HAS_*_RESET
  PCI: imx6: Using "linux,pci-domain" as slot ID
  PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
  PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
  PCI: imx6: Simplify switch-case logic by involve init_phy callback
  PCI: imx6: Add iMX95 PCIe support

Richard Zhu (1):
  dt-bindings: imx6q-pcie: Add imx95 pcie compatible string

 .../bindings/pci/fsl,imx6q-pcie.yaml          |   1 +
 drivers/pci/controller/dwc/pci-imx6.c         | 514 ++++++++++--------
 2 files changed, 300 insertions(+), 215 deletions(-)

-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:22 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:22 -0500
Subject: [PATCH v2 1/9] PCI: imx6: Simplify clock handling by using HAS_CLK_* bitmask
In-Reply-To: <20231207193430.431994-1-Frank.Li@nxp.com>
References: <20231207193430.431994-1-Frank.Li@nxp.com>
Message-ID: <20231207193430.431994-2-Frank.Li@nxp.com>

Refactors the clock handling logic in the imx6 PCI driver by adding
HAS_CLK_* bitmask define for drvdata::flags . Simplifies the code and makes
it more maintainable, as future additions of SOC support will only require
straightforward changes. The drvdata::flags and a bitmask ensures a cleaner
and more scalable switch-case structure for handling clocks.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 84 +++++++++++++--------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 74703362aeec7..8a9b527934f80 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -60,6 +60,10 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
+#define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
+#define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
+
+#define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
@@ -550,19 +554,23 @@ static int imx6_pcie_attach_pd(struct device *dev)
 
 static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	struct dw_pcie *pci = imx6_pcie->pci;
-	struct device *dev = pci->dev;
 	unsigned int offset;
 	int ret = 0;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
 		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_axi clock\n");
-			break;
-		}
+		if (ret)
+			return ret;
+	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
+		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
+		if (ret)
+			return ret;
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
 		break;
@@ -589,12 +597,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_aux clock\n");
-			break;
-		}
-
 		offset = imx6_pcie_grp_offset(imx6_pcie);
 		/*
 		 * Set the over ride low and enabled
@@ -614,10 +616,13 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI))
 		clk_disable_unprepare(imx6_pcie->pcie_inbound_axi);
-		break;
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX))
+		clk_disable_unprepare(imx6_pcie->pcie_aux);
+
+	switch (imx6_pcie->drvdata->variant) {
 	case IMX6QP:
 	case IMX6Q:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
@@ -631,14 +636,6 @@ static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		clk_disable_unprepare(imx6_pcie->pcie_aux);
-		break;
 	default:
 		break;
 	}
@@ -1316,21 +1313,21 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
 				     "pcie clock source missing or invalid\n");
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
-							   "pcie_inbound_axi");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
+		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev, "pcie_inbound_axi");
 		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
-					     "pcie_inbound_axi clock missing or invalid\n");
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
+			dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
+				      "pcie_inbound_axi clock missing or invalid\n");
+	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
 		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
 		if (IS_ERR(imx6_pcie->pcie_aux))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
 					     "pcie_aux clock source missing or invalid\n");
-		fallthrough;
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
 			imx6_pcie->controller_id = 1;
@@ -1353,10 +1350,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	case IMX8MM_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
 		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
 									 "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
@@ -1482,7 +1475,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.variant = IMX6SX,
 		.flags = IMX6_PCIE_FLAG_IMX6_PHY |
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
-			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 	},
 	[IMX6QP] = {
@@ -1500,30 +1494,36 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:23 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:23 -0500
Subject: [PATCH v2 2/9] PCI: imx6: Simplify phy handling by using by using IMX6_PCIE_FLAG_HAS_PHY
In-Reply-To: <20231207193430.431994-1-Frank.Li@nxp.com>
References: <20231207193430.431994-1-Frank.Li@nxp.com>
Message-ID: <20231207193430.431994-3-Frank.Li@nxp.com>

Refactors the phy handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_PHY bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling phy.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 8a9b527934f80..bcf52aa86462e 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -62,6 +62,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 #define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
 #define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
+#define IMX6_PCIE_FLAG_HAS_PHY			BIT(5)
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
@@ -1327,6 +1328,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "pcie_aux clock source missing or invalid\n");
 	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY)) {
+		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+		if (IS_ERR(imx6_pcie->phy))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
+					     "failed to get pcie phy\n");
+	}
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
@@ -1356,11 +1364,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
 
-		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
-		if (IS_ERR(imx6_pcie->phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
-					     "failed to get pcie phy\n");
-
 		break;
 	default:
 		break;
@@ -1500,24 +1503,28 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
-		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:24 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:24 -0500
Subject: [PATCH v2 3/9] PCI: imx6: Simplify reset handling by using by using *_FLAG_HAS_*_RESET
In-Reply-To: <20231207193430.431994-1-Frank.Li@nxp.com>
References: <20231207193430.431994-1-Frank.Li@nxp.com>
Message-ID: <20231207193430.431994-4-Frank.Li@nxp.com>

Refactors the reset handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling reset.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
    none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
    problem.

 drivers/pci/controller/dwc/pci-imx6.c | 111 ++++++++++----------------
 1 file changed, 42 insertions(+), 69 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index bcf52aa86462e..509d459bdc5a1 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -63,6 +63,8 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
 #define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(5)
+#define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(6)
+#define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(7)
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
@@ -696,18 +698,10 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 {
+	reset_control_assert(imx6_pcie->pciephy_reset);
+	reset_control_assert(imx6_pcie->apps_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_assert(imx6_pcie->pciephy_reset);
-		fallthrough;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
-		break;
 	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
@@ -728,6 +722,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
 		break;
+	default:
+		break;
 	}
 
 	/* Some boards don't have PCIe reset GPIO. */
@@ -741,14 +737,10 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
 
+	reset_control_deassert(imx6_pcie->pciephy_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-		break;
 	case IMX7D:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
 		 * Corrector" and other mysterious undocumented things.
@@ -780,11 +772,7 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 
 		usleep_range(200, 500);
 		break;
-	case IMX6Q:		/* Nothing to do */
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
+	default:
 		break;
 	}
 
@@ -831,16 +819,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2,
 				   IMX6Q_GPR12_PCIE_CTL_2);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_deassert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_deassert(imx6_pcie->apps_reset);
 }
 
 static void imx6_pcie_ltssm_disable(struct device *dev)
@@ -854,16 +837,11 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_assert(imx6_pcie->apps_reset);
 }
 
 static int imx6_pcie_start_link(struct dw_pcie *pci)
@@ -1335,36 +1313,24 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "failed to get pcie phy\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-
-		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
-									    "pciephy");
-		if (IS_ERR(imx6_pcie->pciephy_reset)) {
-			dev_err(dev, "Failed to get PCIEPHY reset control\n");
-			return PTR_ERR(imx6_pcie->pciephy_reset);
-		}
-
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
-		if (IS_ERR(imx6_pcie->apps_reset)) {
-			dev_err(dev, "Failed to get PCIE APPS reset control\n");
-			return PTR_ERR(imx6_pcie->apps_reset);
-		}
-		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET)) {
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev, "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
+	}
 
-		break;
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET)) {
+		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev, "pciephy");
+		if (IS_ERR(imx6_pcie->pciephy_reset))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pciephy_reset),
+					     "Failed to get PCIEPHY reset control\n");
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX7D:
+		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
+			imx6_pcie->controller_id = 1;
 	default:
 		break;
 	}
@@ -1492,32 +1458,39 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
-		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
 			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
 			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:25 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:25 -0500
Subject: [PATCH v2 4/9] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231207193430.431994-1-Frank.Li@nxp.com>
References: <20231207193430.431994-1-Frank.Li@nxp.com>
Message-ID: <20231207193430.431994-5-Frank.Li@nxp.com>

Avoid use get slot id by compared with register physical address. If there
are more than 2 slots, compared logic will become complex.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v2
    - fix of_get_pci_domain_nr return value check logic

 drivers/pci/controller/dwc/pci-imx6.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 509d459bdc5a1..548034151ee1a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -33,6 +33,7 @@
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
+#include "../../pci.h"
 #include "pcie-designware.h"
 
 #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
@@ -1327,6 +1328,12 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "Failed to get PCIEPHY reset control\n");
 	}
 
+	/* Using linux,pci-domain as PCI slot id */
+	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
+	/* If there are not "linux,pci-domain" in dts file, means only 1 controller */
+	if (imx6_pcie->controller_id < 0)
+		imx6_pcie->controller_id = 0;
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:26 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:26 -0500
Subject: [PATCH v2 5/9] PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
In-Reply-To: <20231207193430.431994-1-Frank.Li@nxp.com>
References: <20231207193430.431994-1-Frank.Li@nxp.com>
Message-ID: <20231207193430.431994-6-Frank.Li@nxp.com>

Add drvdata::ltssm_off and drvdata::ltssm_mask to simple
imx6_pcie_ltssm_enable(disable)() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 37 ++++++++++++---------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 548034151ee1a..5bfb780e441fd 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,8 @@ struct imx6_pcie_drvdata {
 	u32 flags;
 	int dbi_length;
 	const char *gpr;
+	const u32 ltssm_off;
+	const u32 ltssm_mask;
 };
 
 struct imx6_pcie {
@@ -811,18 +813,11 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_ltssm_enable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2,
-				   IMX6Q_GPR12_PCIE_CTL_2);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off, drvdata->ltssm_mask,
+				   drvdata->ltssm_mask);
 
 	reset_control_deassert(imx6_pcie->apps_reset);
 }
@@ -830,17 +825,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 static void imx6_pcie_ltssm_disable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2, 0);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off,
+				   drvdata->ltssm_mask, 0);
 
 	reset_control_assert(imx6_pcie->apps_reset);
 }
@@ -1446,6 +1435,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1454,6 +1445,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
 			 IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1462,6 +1455,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:27 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:27 -0500
Subject: [PATCH v2 6/9] PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
In-Reply-To: <20231207193430.431994-1-Frank.Li@nxp.com>
References: <20231207193430.431994-1-Frank.Li@nxp.com>
Message-ID: <20231207193430.431994-7-Frank.Li@nxp.com>

Add drvdata::mode_off and drvdata::mode_mask to simple
imx6_pcie_configure_type() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v2
    - use ffs() to fixe build error.
    
    powerpc-linux-ld: drivers/pci/controller/dwc/pci-imx6.o: in function `imx6_pcie_host_init':
    >> pci-imx6.c:(.text.imx6_pcie_host_init+0x120): undefined reference to `__ffsdi2'

 drivers/pci/controller/dwc/pci-imx6.c | 60 ++++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 5bfb780e441fd..1fac6129eeb5f 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -69,6 +69,7 @@ enum imx6_pcie_variants {
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
+#define IMX6_PCIE_MAX_INSTANCES			2
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -77,6 +78,8 @@ struct imx6_pcie_drvdata {
 	const char *gpr;
 	const u32 ltssm_off;
 	const u32 ltssm_mask;
+	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
+	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
 };
 
 struct imx6_pcie {
@@ -177,32 +180,25 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
-	unsigned int mask, val, mode;
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
+	unsigned int mask, val, mode, id;
 
-	if (imx6_pcie->drvdata->mode == DW_PCIE_EP_TYPE)
+	if (drvdata->mode == DW_PCIE_EP_TYPE)
 		mode = PCI_EXP_TYPE_ENDPOINT;
 	else
 		mode = PCI_EXP_TYPE_ROOT_PORT;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		if (imx6_pcie->controller_id == 1) {
-			mask = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
-					  mode);
-		} else {
-			mask = IMX6Q_GPR12_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		}
-		break;
-	default:
-		mask = IMX6Q_GPR12_DEVICE_TYPE;
-		val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		break;
-	}
+	id = imx6_pcie->controller_id;
+
+	/* If mode_mask[id] is zero, means each controller have its individual gpr */
+	if (!drvdata->mode_mask[id])
+		id = 0;
+
+	mask = drvdata->mode_mask[id];
+	/* FIELD_PREP mask have been constant */
+	val = mode << (ffs(mask) - 1);
 
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, mask, val);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->mode_off[id], mask, val);
 }
 
 static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
@@ -1437,6 +1433,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1447,6 +1445,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1457,6 +1457,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1464,6 +1466,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET |
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1471,6 +1475,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET |
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1479,6 +1487,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY |
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
@@ -1487,6 +1497,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY |
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
@@ -1495,6 +1507,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
@@ -1502,12 +1518,16 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:28 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:28 -0500
Subject: [PATCH v2 7/9] PCI: imx6: Simplify switch-case logic by involve init_phy callback
In-Reply-To: <20231207193430.431994-1-Frank.Li@nxp.com>
References: <20231207193430.431994-1-Frank.Li@nxp.com>
Message-ID: <20231207193430.431994-8-Frank.Li@nxp.com>

Add drvdata::init_phy() callback function, so difference SOC choose
difference callback function to simple switch-case logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 135 ++++++++++++++------------
 1 file changed, 71 insertions(+), 64 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 1fac6129eeb5f..4e55b629d4efb 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -70,6 +70,9 @@ enum imx6_pcie_variants {
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
 #define IMX6_PCIE_MAX_INSTANCES			2
+
+struct imx6_pcie;
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -80,6 +83,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
 struct imx6_pcie {
@@ -326,76 +330,69 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
 	return 0;
 }
 
-static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+static int imx8mq_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		/*
-		 * The PHY initialization had been done in the PHY
-		 * driver, break here directly.
-		 */
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		/*
-		 * TODO: Currently this code assumes external
-		 * oscillator is being used
-		 */
+	/*
+	 * TODO: Currently this code assumes external
+	 * oscillator is being used
+	 */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   imx6_pcie_grp_offset(imx6_pcie),
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD,
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD);
+	/*
+	 * Regarding the datasheet, the PCIE_VPH is suggested
+	 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
+	 * VREG_BYPASS should be cleared to zero.
+	 */
+	if (imx6_pcie->vph && regulator_get_voltage(imx6_pcie->vph) > 3000000)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr,
 				   imx6_pcie_grp_offset(imx6_pcie),
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD,
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD);
-		/*
-		 * Regarding the datasheet, the PCIE_VPH is suggested
-		 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
-		 * VREG_BYPASS should be cleared to zero.
-		 */
-		if (imx6_pcie->vph &&
-		    regulator_get_voltage(imx6_pcie->vph) > 3000000)
-			regmap_update_bits(imx6_pcie->iomuxc_gpr,
-					   imx6_pcie_grp_offset(imx6_pcie),
-					   IMX8MQ_GPR_PCIE_VREG_BYPASS,
-					   0);
-		break;
-	case IMX7D:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX8MQ_GPR_PCIE_VREG_BYPASS,
+				   0);
+
+	return 0;
+}
+
+static int imx7d_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	return	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
-		break;
-	case IMX6SX:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6SX_GPR12_PCIE_RX_EQ_MASK,
-				   IMX6SX_GPR12_PCIE_RX_EQ_2);
-		fallthrough;
-	default:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+}
+
+static int imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 
-		/* configure constant input signal to the pcie ctrl and phy */
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
-
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN1,
-				   imx6_pcie->tx_deemph_gen1 << 0);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
-				   imx6_pcie->tx_deemph_gen2_3p5db << 6);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
-				   imx6_pcie->tx_deemph_gen2_6db << 12);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_FULL,
-				   imx6_pcie->tx_swing_full << 18);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_LOW,
-				   imx6_pcie->tx_swing_low << 25);
-		break;
-	}
+	/* configure constant input signal to the pcie ctrl and phy */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN1,
+			   imx6_pcie->tx_deemph_gen1 << 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
+			   imx6_pcie->tx_deemph_gen2_3p5db << 6);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
+			   imx6_pcie->tx_deemph_gen2_6db << 12);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_FULL,
+			   imx6_pcie->tx_swing_full << 18);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_LOW,
+			   imx6_pcie->tx_swing_low << 25);
+	return 0;
+}
 
-	imx6_pcie_configure_type(imx6_pcie);
+static int imx6sx_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6SX_GPR12_PCIE_RX_EQ_MASK, IMX6SX_GPR12_PCIE_RX_EQ_2);
+
+	return imx6_pcie_init_phy(imx6_pcie);
 }
 
 static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
@@ -939,7 +936,11 @@ static int imx6_pcie_host_init(struct dw_pcie_rp *pp)
 	}
 
 	imx6_pcie_assert_core_reset(imx6_pcie);
-	imx6_pcie_init_phy(imx6_pcie);
+
+	if (imx6_pcie->drvdata->init_phy)
+		imx6_pcie->drvdata->init_phy(imx6_pcie);
+
+	imx6_pcie_configure_type(imx6_pcie);
 
 	ret = imx6_pcie_clk_enable(imx6_pcie);
 	if (ret) {
@@ -1435,6 +1436,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1447,6 +1449,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6sx_pcie_init_phy,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1459,6 +1462,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1468,6 +1472,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx7d_pcie_init_phy,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1479,6 +1484,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1511,6 +1517,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:29 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:29 -0500
Subject: [PATCH v2 8/9] dt-bindings: imx6q-pcie: Add imx95 pcie compatible string
In-Reply-To: <20231207193430.431994-1-Frank.Li@nxp.com>
References: <20231207193430.431994-1-Frank.Li@nxp.com>
Message-ID: <20231207193430.431994-9-Frank.Li@nxp.com>

From: Richard Zhu <hongxing.zhu at nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
---

Notes:
    Change from v1 to v2
    - add Krzy's ACK tag

 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 81bbb8728f0f9..7233357678431 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -29,6 +29,7 @@ properties:
       - fsl,imx8mq-pcie
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
+      - fsl,imx95-pcie
 
   reg:
     items:
-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec  7 11:34:30 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu,  7 Dec 2023 14:34:30 -0500
Subject: [PATCH v2 9/9] PCI: imx6: Add iMX95 PCIe support
In-Reply-To: <20231207193430.431994-1-Frank.Li@nxp.com>
References: <20231207193430.431994-1-Frank.Li@nxp.com>
Message-ID: <20231207193430.431994-10-Frank.Li@nxp.com>

Add iMX95 PCIe basic root complex function support.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 85 +++++++++++++++++++++++++--
 1 file changed, 80 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 4e55b629d4efb..670d8d410febf 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -43,6 +43,25 @@
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
 #define IMX8MQ_PCIE2_BASE_ADDR			0x33c00000
 
+#define IMX95_PCIE_PHY_GEN_CTRL			0x0
+#define IMX95_PCIE_REF_USE_PAD			BIT(17)
+
+#define IMX95_PCIE_PHY_MPLLA_CTRL		0x10
+#define IMX95_PCIE_PHY_MPLL_STATE		BIT(30)
+
+#define IMX95_PCIE_SS_RW_REG_0			0xf0
+#define IMX95_PCIE_REF_CLKEN			BIT(23)
+#define IMX95_PCIE_PHY_CR_PARA_SEL		BIT(9)
+
+#define IMX95_PE0_GEN_CTRL_1			0x1050
+#define IMX95_PCIE_DEVICE_TYPE			GENMASK(3, 0)
+
+#define IMX95_PE0_GEN_CTRL_3			0x1058
+#define IMX95_PCIE_LTSSM_EN			BIT(0)
+
+#define IMX95_PE0_PM_STS			0x1064
+#define IMX95_PCIE_PM_LINKST_IN_L2		BIT(14)
+
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -53,6 +72,7 @@ enum imx6_pcie_variants {
 	IMX8MQ,
 	IMX8MM,
 	IMX8MP,
+	IMX95,
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
@@ -79,6 +99,7 @@ struct imx6_pcie_drvdata {
 	u32 flags;
 	int dbi_length;
 	const char *gpr;
+	u32 pf_lut_offset;
 	const u32 ltssm_off;
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
@@ -182,6 +203,24 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
+static int imx95_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			IMX95_PCIE_SS_RW_REG_0,
+			IMX95_PCIE_PHY_CR_PARA_SEL,
+			IMX95_PCIE_PHY_CR_PARA_SEL);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_PHY_GEN_CTRL,
+			   IMX95_PCIE_REF_USE_PAD, 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_SS_RW_REG_0,
+			   IMX95_PCIE_REF_CLKEN,
+			   IMX95_PCIE_REF_CLKEN);
+
+	return 0;
+}
+
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
 	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
@@ -589,6 +628,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
 		break;
 	case IMX7D:
+	case IMX95:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -732,10 +772,19 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 {
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
+	u32 val;
 
 	reset_control_deassert(imx6_pcie->pciephy_reset);
 
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX95:
+		/* Polling the MPLL_STATE */
+		if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+					IMX95_PCIE_PHY_MPLLA_CTRL, val,
+					val & IMX95_PCIE_PHY_MPLL_STATE,
+					10, 10000))
+			dev_err(dev, "PCIe PLL lock timeout\n");
+		break;
 	case IMX7D:
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
@@ -1343,12 +1392,27 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(imx6_pcie->turnoff_reset);
 	}
 
+	if (imx6_pcie->drvdata->gpr) {
 	/* Grab GPR config register range */
-	imx6_pcie->iomuxc_gpr =
-		 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
-	if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
-		dev_err(dev, "unable to find iomuxc registers\n");
-		return PTR_ERR(imx6_pcie->iomuxc_gpr);
+		imx6_pcie->iomuxc_gpr =
+			 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
+	}
+
+	if (imx6_pcie->drvdata->pf_lut_offset) {
+		void __iomem *off = pci->dbi_base + imx6_pcie->drvdata->pf_lut_offset;
+		static struct regmap_config regmap_config = {
+			.reg_bits = 32,
+			.val_bits = 32,
+			.reg_stride = 4,
+		};
+
+		imx6_pcie->iomuxc_gpr = devm_regmap_init_mmio(dev, off, &regmap_config);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
 	}
 
 	/* Grab PCIe PHY Tx Settings */
@@ -1506,6 +1570,16 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
+	[IMX95] = {
+		.variant = IMX8MP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.pf_lut_offset = 0x40000,
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
@@ -1546,6 +1620,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
 	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{ .compatible = "fsl,imx8mp-pcie", .data = &drvdata[IMX8MP], },
+	{ .compatible = "fsl,imx95-pcie", .data = &drvdata[IMX95], },
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
-- 
2.34.1



From olteanv at gmail.com  Thu Dec  7 12:01:32 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Thu, 7 Dec 2023 22:01:32 +0200
Subject: [PATCH net-next 07/15] net: dsa: mt7530: do not run
 mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <20231207184015.u7uoyfhdxiyuw6hh@skbuf>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-8-arinc.unal@arinc9.com>
 <20231121185358.GA16629@kernel.org>
 <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
 <90fde560-054e-4188-b15c-df2e082d3e33@moroto.mountain>
 <20231207184015.u7uoyfhdxiyuw6hh@skbuf>
Message-ID: <20231207200132.772h3t3l6coan6ht@skbuf>

On Thu, Dec 07, 2023 at 08:40:15PM +0200, Vladimir Oltean wrote:
> Also, reducing the indentation level of for_each_child_of_node() by one
> can't be bad. Maybe even by more. There's this pattern:
> 
> for_each_child_of_node(dn, mac_np) {
> 	// do stuff with mac_np
> 	break;
> }
> 
> aka we only care about the first child of dn. We could find the mac_np
> as the only operation inside for_each_child_of_node(), break directly,
> and "do stuff with mac_np" could be done outside, further reducing the
> indentation by 1 level.

I noticed just now that there is further filtering on the child OF node
by of_device_is_compatible(). In that case, of_get_compatible_child()
could be used to eliminate for_each_child_of_node() completely.


From heiko at sntech.de  Thu Dec  7 12:30:59 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu,  7 Dec 2023 21:30:59 +0100
Subject: [PATCH] arm64: dts: rockchip: Add dynamic-power-coefficient to rk3399 GPU
In-Reply-To: <20231127081511.1911706-1-lukasz.luba@arm.com>
References: <20231127081511.1911706-1-lukasz.luba@arm.com>
Message-ID: <170198105573.18516.6264175947902125145.b4-ty@sntech.de>

On Mon, 27 Nov 2023 08:15:11 +0000, Lukasz Luba wrote:
> Add dynamic-power-coefficient to the GPU node. That will create Energy
> Model for the GPU based on the coefficient and OPP table information.
> It will enable mechanism such as DTMP or IPA to work with the GPU DVFS.
> In similar way the Energy Model for CPUs in rk3399 is created, so both
> are aligned in power scale. The maximum power used from this coefficient
> is 1.5W at 600MHz.
> 
> [...]

Applied, thanks!

[1/1] arm64: dts: rockchip: Add dynamic-power-coefficient to rk3399 GPU
      commit: 381d48fbada9b5b39f5a811bb8fe76365d6bdd5c

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From acme at kernel.org  Thu Dec  7 12:31:49 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Thu, 7 Dec 2023 17:31:49 -0300
Subject: [PATCH V2 0/5] Clean up perf mem
In-Reply-To: <20231207192338.400336-1-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
Message-ID: <ZXIrtcYkvpA8Uwj1@kernel.org>

Em Thu, Dec 07, 2023 at 11:23:33AM -0800, kan.liang at linux.intel.com escreveu:
> From: Kan Liang <kan.liang at linux.intel.com>
> 
> Changes since V1:
> - Fix strcmp of PMU name checking (Ravi)
> - Fix "/," typo (Ian)
> - Rename several functions with perf_pmu__mem_events prefix. (Ian)
> - Fold the header removal patch into the patch where the cleanups made.
>   (Arnaldo)
> - Add reviewed-by and tested-by from Ian and Ravi

It would be good to have a Tested-by from people working in all the
architectures affectes, like we got from Ravi for AMD, can we get those?

I'm applying it locally for test building, will push to
perf-tools-next/tmp.perf-tools-next for a while, so there is some time
to test.

ARM64 (Leo?) and ppc, for PPC... humm Ravi did it, who could test it now?

- Arnaldo
 
> As discussed in the below thread, the patch set is to clean up perf mem.
> https://lore.kernel.org/lkml/afefab15-cffc-4345-9cf4-c6a4128d4d9c at linux.intel.com/
> 
> Introduce generic functions perf_mem_events__ptr(),
> perf_mem_events__name() ,and is_mem_loads_aux_event() to replace the
> ARCH specific ones.
> Simplify the perf_mem_event__supported().
> 
> Only keeps the ARCH-specific perf_mem_events array in the corresponding
> mem-events.c for each ARCH.
> 
> There is no functional change.
> 
> The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
> etc. But I can only test it on two Intel platforms.
> Please give it try, if you have machines with other ARCHs.
> 
> Here are the test results:
> Intel hybrid machine:
> 
> $perf mem record -e list
> ldlat-loads  : available
> ldlat-stores : available
> 
> $perf mem record -e ldlat-loads -v --ldlat 50
> calling: record -e cpu_atom/mem-loads,ldlat=50/P -e cpu_core/mem-loads,ldlat=50/P
> 
> $perf mem record -v
> calling: record -e cpu_atom/mem-loads,ldlat=30/P -e cpu_atom/mem-stores/P -e cpu_core/mem-loads,ldlat=30/P -e cpu_core/mem-stores/P
> 
> $perf mem record -t store -v
> calling: record -e cpu_atom/mem-stores/P -e cpu_core/mem-stores/P
> 
> 
> Intel SPR:
> $perf mem record -e list
> ldlat-loads  : available
> ldlat-stores : available
> 
> $perf mem record -e ldlat-loads -v --ldlat 50
> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=50/}:P
> 
> $perf mem record -v
> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=30/}:P -e cpu/mem-stores/P
> 
> $perf mem record -t store -v
> calling: record -e cpu/mem-stores/P
> 
> Kan Liang (5):
>   perf mem: Add mem_events into the supported perf_pmu
>   perf mem: Clean up perf_mem_events__ptr()
>   perf mem: Clean up perf_mem_events__name()
>   perf mem: Clean up perf_mem_event__supported()
>   perf mem: Clean up is_mem_loads_aux_event()
> 
>  tools/perf/arch/arm64/util/mem-events.c   |  36 +----
>  tools/perf/arch/arm64/util/pmu.c          |   6 +
>  tools/perf/arch/powerpc/util/mem-events.c |  13 +-
>  tools/perf/arch/powerpc/util/mem-events.h |   7 +
>  tools/perf/arch/powerpc/util/pmu.c        |  11 ++
>  tools/perf/arch/s390/util/pmu.c           |   3 +
>  tools/perf/arch/x86/util/mem-events.c     |  99 ++----------
>  tools/perf/arch/x86/util/pmu.c            |  11 ++
>  tools/perf/builtin-c2c.c                  |  28 +++-
>  tools/perf/builtin-mem.c                  |  28 +++-
>  tools/perf/util/mem-events.c              | 181 +++++++++++++---------
>  tools/perf/util/mem-events.h              |  15 +-
>  tools/perf/util/pmu.c                     |   4 +-
>  tools/perf/util/pmu.h                     |   7 +
>  14 files changed, 233 insertions(+), 216 deletions(-)
>  create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
>  create mode 100644 tools/perf/arch/powerpc/util/pmu.c
> 
> -- 
> 2.35.1
> 

-- 

- Arnaldo


From heiko at sntech.de  Thu Dec  7 12:41:37 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 07 Dec 2023 21:41:37 +0100
Subject: [GIT PULL] Rockchip dts fixes for 6.7
Message-ID: <2709704.mvXUDI8C0e@phil>

Hi Arnd, Kevin, Olof,

please find a below a collection of fixes for the current release 6.7
cycle.

Please pull

Thanks
Heiko


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v6.7-rockchip-dtsfixes1

for you to fetch changes up to 37f3d6108730713c411827ab4af764909f4dfc78:

  arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588 (2023-12-06 10:38:03 +0100)

----------------------------------------------------------------
Devicetree fixes for the 6.7-cycle.

All over the place this time. From adapting the size of the vdec nodes
on rk3328 and rk3399, fixing some wrong pinctrl settings on rk3128 and
the Turing RK1 board, emmc-settings fixes on rk3588 and interrupt-name
mishaps, down to some dt-cleanups.

Also this adds the missing rockchip,rk3588-pmugrf compatible to the soc
grf binding, that I somehow messed up during the pull requests for the
-rc1 . At least with it included the dt-checker is happier.

----------------------------------------------------------------
Alex Bee (2):
      arm64: dts: rockchip: Expand reg size of vdec node for RK3399
      ARM: dts: rockchip: Fix sdmmc_pwren's pinmux setting for RK3128

Heiko Stuebner (2):
      arm64: dts: rockchip: fix rk356x pcie msg interrupt name
      arm64: dts: rockchip: drop interrupt-names property from rk3588s dfi

Jonas Karlman (1):
      arm64: dts: rockchip: Expand reg size of vdec node for RK3328

Krzysztof Kozlowski (2):
      ARM: dts: rockchip: minor whitespace cleanup around '='
      arm64: dts: rockchip: minor whitespace cleanup around '='

Rob Herring (1):
      arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru

Sam Edwards (2):
      arm64: dts: rockchip: Fix Turing RK1 interrupt pinctrls
      arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588

Sascha Hauer (1):
      dt-bindings: soc: rockchip: grf: add rockchip,rk3588-pmugrf

 Documentation/devicetree/bindings/soc/rockchip/grf.yaml  | 1 +
 arch/arm/boot/dts/rockchip/rk3128.dtsi                   | 2 +-
 arch/arm/boot/dts/rockchip/rk322x.dtsi                   | 6 +++---
 arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts    | 2 +-
 arch/arm64/boot/dts/rockchip/rk3328.dtsi                 | 2 +-
 arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi  | 3 +--
 arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts | 4 ++--
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi             | 1 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi                 | 6 ++++--
 arch/arm64/boot/dts/rockchip/rk356x.dtsi                 | 2 +-
 arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi      | 4 ++--
 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts      | 2 +-
 arch/arm64/boot/dts/rockchip/rk3588s-pinctrl.dtsi        | 2 +-
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi                | 1 -
 14 files changed, 20 insertions(+), 18 deletions(-)





From sjg at chromium.org  Thu Dec  7 12:52:53 2023
From: sjg at chromium.org (Simon Glass)
Date: Thu, 7 Dec 2023 13:52:53 -0700
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231207143814.GD15521@pendragon.ideasonboard.com>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com>
Message-ID: <CAPnjgZ1q3yBeyYfjLumJ03HR7JM1xwN7sMbNJqfUWpsVxFTs4Q@mail.gmail.com>

Hi,

On Thu, 7 Dec 2023 at 07:38, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>
> On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > Hi Simon,
> > >
> > > Thank you for the patch.
> > >
> > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > containing the built kernel and associated devicetree files.
> > > > Compression defaults to gzip which gives a good balance of size and
> > > > performance.
> > > >
> > > > The files compress from about 86MB to 24MB using this approach.
> > > >
> > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > and Linuxboot. It permits automatic selection of the correct
> > > > devicetree, matching the compatible string of the running board with
> > > > the closest compatible string in the FIT. There is no need for
> > > > filenames or other workarounds.
> > > >
> > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > FIT_COMPRESSION to select a different algorithm.
> > > >
> > > > The FIT can be examined using 'dumpimage -l'.
> > > >
> > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > requires compression utilities for the algorithm being used. Supported
> > > > compression options are the same as the Image.xxx files. For now there
> > > > is no way to change the compression other than by editing the rule for
> > > > $(obj)/image.fit
> > > >
> > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > this here, since it must be built separately from the Linux build.
> > >
> > > FIT images are very useful, so I think this is a very welcome addition
> > > to the kernel build system. It can get tricky though: given the
> > > versatile nature of FIT images, there can't be any
> > > one-size-fits-them-all solution to build them, and striking the right
> > > balance between what makes sense for the kernel and the features that
> > > users may request will probably lead to bikeshedding. As we all love
> > > bikeshedding, I thought I would start selfishly, with a personal use
> > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > to delay merging this series.
> > >
> > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > extending the supported command line arguments. It would perhaps be more
> > > difficult to integrate in the kernel build system though. This leads me
> > > to a second question: would you consider merging extensions to this
> > > script if they are not used by the kernel build system, but meant for
> > > users who manually invoke the script ? More generally, is the script
> >
> > We'd also be interested in some customization, though in a different way.
> > We imagine having a rule file that says X compatible string should map
> > to A base DTB, plus B and C DTBO for the configuration section. The base
> > DTB would carry all common elements of some device, while the DTBOs
> > carry all the possible second source components, like different display
> > panels or MIPI cameras for instance. This could drastically reduce the
> > size of FIT images in ChromeOS by deduplicating all the common stuff.
>
> Do you envision the "mapping" compatible string mapping to a config
> section in the FIT image, that would bundle the base DTB and the DTBOs ?
>
> > > meant to be used stand-alone as well, in which case its command line
> > > arguments need to remain backward-compatible, or do you see it as being
> > > internal to the kernel ?

It is great to see all this discussion! I did send a proposal to the
U-Boot ML about extensions but it was mixed up with other things, so
I'll start a new thread.

For now, I am really just waiting for this to be applied, before
talking too much about future possibilities.

Regards,
SImon


From heiko at sntech.de  Thu Dec  7 12:57:30 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu,  7 Dec 2023 21:57:30 +0100
Subject: [PATCH v1 1/2] ARM: dts: rockchip: add gpio alias for gpio dt nodes
In-Reply-To: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
References: <89f2a229-9f14-d43f-c53d-5d4688e70456@gmail.com>
Message-ID: <170198261663.24767.3042454537755741300.b4-ty@sntech.de>

On Sat, 2 Dec 2023 19:22:01 +0100, Johan Jonker wrote:
> Rockchip SoC TRM, SoC datasheet and board schematics always refer to
> the same gpio numbers - even if not all are used for a specific board.
> In order to not have to re-define them for every board add the
> aliases to SoC dtsi files.
> 
> 

Applied, thanks!

[1/2] ARM: dts: rockchip: add gpio alias for gpio dt nodes
      commit: 04c521c3bec1fa0ccb97a1fbf74f0faeda3f4a53
[2/2] arm64: dts: rockchip: add gpio alias for gpio dt nodes
      commit: cfb0264f3654e357bcdfe27c2f7240241c2ac6c5

Added the Co-developed-by for Jianqun before applying.

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From keescook at chromium.org  Thu Dec  7 13:04:39 2023
From: keescook at chromium.org (Kees Cook)
Date: Thu, 7 Dec 2023 13:04:39 -0800
Subject: [PATCH] maple_tree: Fix mas_prev() state separation code
In-Reply-To: <20231207193319.4025462-1-Liam.Howlett@oracle.com>
References: <20231207014104.n6vul2ylgqjnsfia@revolve>
 <20231207193319.4025462-1-Liam.Howlett@oracle.com>
Message-ID: <202312071302.99D5B1BB76@keescook>

On Thu, Dec 07, 2023 at 02:33:19PM -0500, Liam R. Howlett wrote:
> mas_prev() was setting the ma_underflow condition when the limit was
> reached and not when the limit was attempting to go lower.  This
> resulted in the incorrect behaviour on subsequent actions.
> 
> This commit fixes the status setting to only set ma_underflow when the
> lower limit is attempted to be decremented, and modifies the testing to
> ensure that's the case.
> 
> Signed-off-by: Liam R. Howlett <Liam.Howlett at oracle.com>

Is this is related to the report[1] I forwarded? If so, please add these tags
too:

 Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
 Closes: https://lore.kernel.org/all/CA+G9fYs-j2FYZSFSVZj48mgoM9gQd4-7M2mu2Ez3D1DqDdW2bQ at mail.gmail.com/ [1]

Thanks either way!

-Kees

> ---
> 
> Andrew,
> 
> This should be clean to squash into 7f79fdb1d94d7 ("maple_tree: separate
> ma_state node from status.") which is currently in your mm-unstable
> branch.
> 
> Thanks,
> Liam
> 
> 
>  lib/maple_tree.c      | 16 ++++++++++++----
>  lib/test_maple_tree.c |  9 +++++++--
>  2 files changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 89f8d21602774..47f2a7a973852 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -4432,6 +4432,9 @@ static void *mas_prev_slot(struct ma_state *mas, unsigned long min, bool empty)
>  		mas->last = mas->index - 1;
>  		mas->index = mas_safe_min(mas, pivots, mas->offset);
>  	} else  {
> +		if (mas->index <= min)
> +			goto underflow;
> +
>  		if (mas_prev_node(mas, min)) {
>  			mas_rewalk(mas, save_point);
>  			goto retry;
> @@ -4452,15 +4455,15 @@ static void *mas_prev_slot(struct ma_state *mas, unsigned long min, bool empty)
>  	if (unlikely(mas_rewalk_if_dead(mas, node, save_point)))
>  		goto retry;
>  
> -	if (mas->index <= min)
> -		mas->status = ma_underflow;
>  
>  	if (likely(entry))
>  		return entry;
>  
>  	if (!empty) {
> -		if (mas_is_underflow(mas))
> +		if (mas->index <= min) {
> +			mas->status = ma_underflow;
>  			return NULL;
> +		}
>  
>  		goto again;
>  	}
> @@ -4596,7 +4599,7 @@ static void *mas_next_slot(struct ma_state *mas, unsigned long max, bool empty)
>  		if (unlikely(mas_rewalk_if_dead(mas, node, save_point)))
>  			goto retry;
>  
> -		if (pivot >= max) {
> +		if (pivot >= max) { /* Was at the limit, next will extend beyond */
>  			mas->status = ma_overflow;
>  			return NULL;
>  		}
> @@ -4611,6 +4614,11 @@ static void *mas_next_slot(struct ma_state *mas, unsigned long max, bool empty)
>  		else
>  			mas->last = mas->max;
>  	} else  {
> +		if (mas->last >= max) {
> +			mas->status = ma_overflow;
> +			return NULL;
> +		}
> +
>  		if (mas_next_node(mas, node, max)) {
>  			mas_rewalk(mas, save_point);
>  			goto retry;
> diff --git a/lib/test_maple_tree.c b/lib/test_maple_tree.c
> index 15fbeb788f3ac..29185ac5c727f 100644
> --- a/lib/test_maple_tree.c
> +++ b/lib/test_maple_tree.c
> @@ -3294,8 +3294,8 @@ static noinline void __init check_state_handling(struct maple_tree *mt)
>  	MT_BUG_ON(mt, mas.last != 0x1500);
>  	MT_BUG_ON(mt, !mas_is_active(&mas));
>  
> -	/* next:active ->active */
> -	entry = mas_next(&mas, ULONG_MAX);
> +	/* next:active ->active (spanning limit) */
> +	entry = mas_next(&mas, 0x2100);
>  	MT_BUG_ON(mt, entry != ptr2);
>  	MT_BUG_ON(mt, mas.index != 0x2000);
>  	MT_BUG_ON(mt, mas.last != 0x2500);
> @@ -3360,6 +3360,11 @@ static noinline void __init check_state_handling(struct maple_tree *mt)
>  	MT_BUG_ON(mt, entry != ptr);
>  	MT_BUG_ON(mt, mas.index != 0x1000);
>  	MT_BUG_ON(mt, mas.last != 0x1500);
> +	MT_BUG_ON(mt, !mas_is_active(&mas)); /* spanning limit */
> +	entry = mas_prev(&mas, 0x1200); /* underflow */
> +	MT_BUG_ON(mt, entry != NULL);
> +	MT_BUG_ON(mt, mas.index != 0x1000);
> +	MT_BUG_ON(mt, mas.last != 0x1500);
>  	MT_BUG_ON(mt, !mas_is_underflow(&mas));
>  
>  	/* prev:underflow -> underflow (lower limit) spanning end range */
> -- 
> 2.40.1
> 

-- 
Kees Cook


From ahalaney at redhat.com  Thu Dec  7 13:12:40 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Thu, 07 Dec 2023 15:12:40 -0600
Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if
 unnecessary
Message-ID: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>

The stmmac_dt_phy() function, which parses the devicetree node of the
MAC and ultimately causes MDIO bus allocation, misinterprets what
fixed-link means in relation to the MAC's MDIO bus. This results in
a MDIO bus being created in situations it need not be.

Currently a MDIO bus is created if the description is either:

    1. Not fixed-link
    2. fixed-link but contains a MDIO bus as well

The "1" case above isn't always accurate. If there's a phy-handle,
it could be referencing a phy on another MDIO controller's bus[1]. In
this case currently the MAC will make a MDIO bus and scan it all
anyways unnecessarily.

There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
be created and scanned for a phy. This case can also be inferred from
the platform description by not having a phy-handle && not being
fixed-link. This hits case "1" in the current driver's logic.

Let's improve the logic to create a MDIO bus if either:

    - Devicetree contains a MDIO bus
    - !fixed-link && !phy-handle (legacy handling)

Below upstream devicetree snippets can be found that explain some of
the cases above more concretely.

Here's[0] a devicetree example where the MAC is both fixed-link and
driving a switch on MDIO (case "2" above). This needs a MDIO bus to
be created:

    &fec1 {
            phy-mode = "rmii";

            fixed-link {
                    speed = <100>;
                    full-duplex;
            };

            mdio1: mdio {
                    switch0: switch0 at 0 {
                            compatible = "marvell,mv88e6190";
                            pinctrl-0 = <&pinctrl_gpio_switch0>;
                    };
            };
    };

Here's[1] an example where there is no MDIO bus or fixed-link for
the ethernet1 MAC, so no MDIO bus should be created since ethernet0
is the MDIO master for ethernet1's phy:

    &ethernet0 {
            phy-mode = "sgmii";
            phy-handle = <&sgmii_phy0>;

            mdio {
                    compatible = "snps,dwmac-mdio";
                    sgmii_phy0: phy at 8 {
                            compatible = "ethernet-phy-id0141.0dd4";
                            reg = <0x8>;
                            device_type = "ethernet-phy";
                    };

                    sgmii_phy1: phy at a {
                            compatible = "ethernet-phy-id0141.0dd4";
                            reg = <0xa>;
                            device_type = "ethernet-phy";
                    };
            };
    };

    &ethernet1 {
            phy-mode = "sgmii";
            phy-handle = <&sgmii_phy1>;
    };

Finally there's descriptions like this[2] which don't describe the
MDIO bus but expect it to be created and the whole address space
scanned for a phy since there's no phy-handle or fixed-link described:

    &gmac {
            phy-supply = <&vcc_lan>;
            phy-mode = "rmii";
            snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
            snps,reset-active-low;
            snps,reset-delays-us = <0 10000 1000000>;
    };

[0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts
[1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
[2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164

Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
---
Changes in v3:
    - Keep logic out of stmmac_probe_config_dt() since it's already massive (Serge)

Changes in v2:
    - Handle the fixed-link + mdio case (Andrew Lunn)
    - Reworded commit message
    - Still handle the "legacy" case mentioned in the commit
    - Bit further refactoring of the function for readability

- Link to v2: https://lore.kernel.org/r/20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca at redhat.com
- Link to v1: https://lore.kernel.org/netdev/20230808120254.11653-1-brgl at bgdev.pl/
---
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 91 +++++++++++++---------
 1 file changed, 54 insertions(+), 37 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1ffde555da47..d6079c1432c7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -296,62 +296,80 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
 }
 
 /**
- * stmmac_dt_phy - parse device-tree driver parameters to allocate PHY resources
- * @plat: driver data platform structure
- * @np: device tree node
- * @dev: device pointer
- * Description:
- * The mdio bus will be allocated in case of a phy transceiver is on board;
- * it will be NULL if the fixed-link is configured.
- * If there is the "snps,dwmac-mdio" sub-node the mdio will be allocated
- * in any case (for DSA, mdio must be registered even if fixed-link).
- * The table below sums the supported configurations:
- *	-------------------------------
- *	snps,phy-addr	|     Y
- *	-------------------------------
- *	phy-handle	|     Y
- *	-------------------------------
- *	fixed-link	|     N
- *	-------------------------------
- *	snps,dwmac-mdio	|
- *	  even if	|     Y
- *	fixed-link	|
- *	-------------------------------
+ * stmmac_of_get_mdio() - Gets the MDIO bus from the devicetree.
+ * @np: devicetree node
  *
- * It returns 0 in case of success otherwise -ENODEV.
+ * The MDIO bus will be searched for in the following ways:
+ * 1. The compatible is "snps,dwc-qos-ethernet-4.10" && a "mdio" named
+ *    child node exists
+ * 2. A child node with the "snps,dwmac-mdio" compatible is present
+ *
+ * Return: The MDIO node if present otherwise NULL
  */
-static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
-			 struct device_node *np, struct device *dev)
+static struct device_node *stmmac_of_get_mdio(struct device_node *np)
 {
-	bool mdio = !of_phy_is_fixed_link(np);
 	static const struct of_device_id need_mdio_ids[] = {
 		{ .compatible = "snps,dwc-qos-ethernet-4.10" },
 		{},
 	};
+	struct device_node *mdio_node = NULL;
 
 	if (of_match_node(need_mdio_ids, np)) {
-		plat->mdio_node = of_get_child_by_name(np, "mdio");
+		mdio_node = of_get_child_by_name(np, "mdio");
 	} else {
 		/**
 		 * If snps,dwmac-mdio is passed from DT, always register
 		 * the MDIO
 		 */
-		for_each_child_of_node(np, plat->mdio_node) {
-			if (of_device_is_compatible(plat->mdio_node,
+		for_each_child_of_node(np, mdio_node) {
+			if (of_device_is_compatible(mdio_node,
 						    "snps,dwmac-mdio"))
 				break;
 		}
 	}
 
-	if (plat->mdio_node) {
+	return mdio_node;
+}
+
+/**
+ * stmmac_mdio_setup() - Populate platform related MDIO structures.
+ * @plat: driver data platform structure
+ * @np: devicetree node
+ * @dev: device pointer
+ *
+ * This searches for MDIO information from the devicetree.
+ * If an MDIO node is found, it's assigned to plat->mdio_node and
+ * plat->mdio_bus_data is allocated.
+ * If no connection can be determined, just plat->mdio_bus_data is allocated
+ * to indicate a bus should be created and scanned for a phy.
+ * If it's determined there's no MDIO bus needed, both are left NULL.
+ *
+ * This expects that plat->phy_node has already been searched for.
+ *
+ * Return: 0 on success, errno otherwise.
+ */
+static int stmmac_mdio_setup(struct plat_stmmacenet_data *plat,
+			     struct device_node *np, struct device *dev)
+{
+	bool legacy_mdio;
+
+	plat->mdio_node = stmmac_of_get_mdio(np);
+	if (plat->mdio_node)
 		dev_dbg(dev, "Found MDIO subnode\n");
-		mdio = true;
-	}
 
-	if (mdio) {
-		plat->mdio_bus_data =
-			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
-				     GFP_KERNEL);
+	/* Legacy devicetrees allowed for no MDIO bus description and expect
+	 * the bus to be scanned for devices. If there's no phy or fixed-link
+	 * described assume this is the case since there must be something
+	 * connected to the MAC.
+	 */
+	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
+	if (legacy_mdio)
+		dev_info(dev, "Deprecated MDIO bus assumption used\n");
+
+	if (plat->mdio_node || legacy_mdio) {
+		plat->mdio_bus_data = devm_kzalloc(dev,
+						   sizeof(struct stmmac_mdio_bus_data),
+						   GFP_KERNEL);
 		if (!plat->mdio_bus_data)
 			return -ENOMEM;
 
@@ -471,8 +489,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
 	if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
 		dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
 
-	/* To Configure PHY by using all device-tree supported properties */
-	rc = stmmac_dt_phy(plat, np, &pdev->dev);
+	rc = stmmac_mdio_setup(plat, np, &pdev->dev);
 	if (rc)
 		return ERR_PTR(rc);
 

---
base-commit: fd8a79b63710acb84321be3ce74be23c876873fb
change-id: 20231127-stmmac-no-mdio-node-1db9da8a25d9

Best regards,
-- 
Andrew Halaney <ahalaney at redhat.com>



From robdclark at gmail.com  Thu Dec  7 13:24:39 2023
From: robdclark at gmail.com (Rob Clark)
Date: Thu,  7 Dec 2023 13:24:39 -0800
Subject: [PATCH] iommu/arm-smmu-qcom: Add missing GMU entry to match table
Message-ID: <20231207212441.6199-1-robdclark@gmail.com>

From: Rob Clark <robdclark at chromium.org>

We also want the default domain for the GMU to be an identy domain,
so it does not get a context bank assigned.  Without this, both
of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
allocating and configuring a context bank.  So GMU ends up attached
to both cbndx 1 and cbndx 2.  This arrangement seemingly confounds
and surprises the firmware if the GPU later triggers a translation
fault, resulting (on sc8280xp / lenovo x13s, at least) in the SMMU
getting wedged and the GPU stuck without memory access.

Signed-off-by: Rob Clark <robdclark at chromium.org>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 549ae4dba3a6..d326fa230b96 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -243,6 +243,7 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 
 static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
 	{ .compatible = "qcom,adreno" },
+	{ .compatible = "qcom,adreno-gmu" },
 	{ .compatible = "qcom,mdp4" },
 	{ .compatible = "qcom,mdss" },
 	{ .compatible = "qcom,sc7180-mdss" },
-- 
2.43.0



From andrew at lunn.ch  Thu Dec  7 13:30:23 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 7 Dec 2023 22:30:23 +0100
Subject: [PATCH net-next v2] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
References: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
Message-ID: <e64b14c3-4b80-4120-8cc4-9baa40cdcb75@lunn.ch>

On Wed, Dec 06, 2023 at 05:46:09PM -0600, Andrew Halaney wrote:
> The stmmac_dt_phy() function, which parses the devicetree node of the
> MAC and ultimately causes MDIO bus allocation, misinterprets what
> fixed-link means in relation to the MAC's MDIO bus. This results in
> a MDIO bus being created in situations it need not be.

Please extend that with something like....

This is bad, because ....

Most 'clean' driver unconditionally create the MDIO bus. But stmmac is
not that clean, and has to keep backwards compatibility to some old
usage. I'm just wondering what this patch actually brings us, and is
it worth it. Is it fixing a real bug, or just an optimisation?

   Andrew


From laurent.pinchart at ideasonboard.com  Thu Dec  7 13:30:52 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 7 Dec 2023 23:30:52 +0200
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAPnjgZ1q3yBeyYfjLumJ03HR7JM1xwN7sMbNJqfUWpsVxFTs4Q@mail.gmail.com>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com>
 <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com>
 <CAPnjgZ1q3yBeyYfjLumJ03HR7JM1xwN7sMbNJqfUWpsVxFTs4Q@mail.gmail.com>
Message-ID: <20231207213052.GD25616@pendragon.ideasonboard.com>

On Thu, Dec 07, 2023 at 01:52:53PM -0700, Simon Glass wrote:
> On Thu, 7 Dec 2023 at 07:38, Laurent Pinchart wrote:
> > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > Hi Simon,
> > > >
> > > > Thank you for the patch.
> > > >
> > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > containing the built kernel and associated devicetree files.
> > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > performance.
> > > > >
> > > > > The files compress from about 86MB to 24MB using this approach.
> > > > >
> > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > devicetree, matching the compatible string of the running board with
> > > > > the closest compatible string in the FIT. There is no need for
> > > > > filenames or other workarounds.
> > > > >
> > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > FIT_COMPRESSION to select a different algorithm.
> > > > >
> > > > > The FIT can be examined using 'dumpimage -l'.
> > > > >
> > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > requires compression utilities for the algorithm being used. Supported
> > > > > compression options are the same as the Image.xxx files. For now there
> > > > > is no way to change the compression other than by editing the rule for
> > > > > $(obj)/image.fit
> > > > >
> > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > this here, since it must be built separately from the Linux build.
> > > >
> > > > FIT images are very useful, so I think this is a very welcome addition
> > > > to the kernel build system. It can get tricky though: given the
> > > > versatile nature of FIT images, there can't be any
> > > > one-size-fits-them-all solution to build them, and striking the right
> > > > balance between what makes sense for the kernel and the features that
> > > > users may request will probably lead to bikeshedding. As we all love
> > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > to delay merging this series.
> > > >
> > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > extending the supported command line arguments. It would perhaps be more
> > > > difficult to integrate in the kernel build system though. This leads me
> > > > to a second question: would you consider merging extensions to this
> > > > script if they are not used by the kernel build system, but meant for
> > > > users who manually invoke the script ? More generally, is the script
> > >
> > > We'd also be interested in some customization, though in a different way.
> > > We imagine having a rule file that says X compatible string should map
> > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > DTB would carry all common elements of some device, while the DTBOs
> > > carry all the possible second source components, like different display
> > > panels or MIPI cameras for instance. This could drastically reduce the
> > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> >
> > Do you envision the "mapping" compatible string mapping to a config
> > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> >
> > > > meant to be used stand-alone as well, in which case its command line
> > > > arguments need to remain backward-compatible, or do you see it as being
> > > > internal to the kernel ?
> 
> It is great to see all this discussion! I did send a proposal to the
> U-Boot ML about extensions but it was mixed up with other things, so
> I'll start a new thread.
> 
> For now, I am really just waiting for this to be applied, before
> talking too much about future possibilities.

Sure, I don't see any reason to delay this series until you have fixed
everybody's system images problems :-)

-- 
Regards,

Laurent Pinchart


From andrew at lunn.ch  Thu Dec  7 13:34:51 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 7 Dec 2023 22:34:51 +0100
Subject: [PATCH 2/3] arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet
 support
In-Reply-To: <20231207081917.340167-3-danishanwar@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-3-danishanwar@ti.com>
Message-ID: <9e0067dd-4865-4afc-ba42-bda504459ad8@lunn.ch>

> +&icssg1_mdio {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&icssg1_mdio1_pins_default>;
> +
> +	icssg1_phy1: ethernet-phy at 0 {
> +		reg = <0xf>;

reg = 0xf, so this is ethernet-phy at f.

    Andrew


From andrew at lunn.ch  Thu Dec  7 13:40:27 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 7 Dec 2023 22:40:27 +0100
Subject: [PATCH 3/3] arm64: dts: ti: k3-am642-evm: add overlay for icssg1
 2nd port
In-Reply-To: <20231207081917.340167-4-danishanwar@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-4-danishanwar@ti.com>
Message-ID: <fe6499b3-fbda-4e2d-9b5e-92cc60d3a79c@lunn.ch>

> +	mdio-mux-2 {
> +		compatible = "mdio-mux-multiplexer";
> +		mux-controls = <&mdio_mux>;
> +		mdio-parent-bus = <&icssg1_mdio>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		mdio at 0 {
> +			reg = <0x0>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			icssg1_phy2: ethernet-phy at 3 {
> +				reg = <3>;
> +				tx-internal-delay-ps = <250>;
> +				rx-internal-delay-ps = <2000>;
> +			};
> +		};

That looks odd. A mux generally has > 1 mdio bus. Otherwise its not
really a mux.

And this mux hardware exists all the time right? So it should be in
the .dtsi file.

	Andrew


From akpm at linux-foundation.org  Thu Dec  7 14:05:02 2023
From: akpm at linux-foundation.org (Andrew Morton)
Date: Thu, 7 Dec 2023 14:05:02 -0800
Subject: [PATCH v9 00/10] Multi-size THP for anonymous memory
In-Reply-To: <20231207161211.2374093-1-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
Message-ID: <20231207140502.e7dff5d1cfb195b1644b61a5@linux-foundation.org>

On Thu,  7 Dec 2023 16:12:01 +0000 Ryan Roberts <ryan.roberts at arm.com> wrote:

> Hi All,
> 
> This is v9 (and hopefully the last) of a series to implement multi-size THP
> (mTHP) for anonymous memory (previously called "small-sized THP" and "large
> anonymous folios").

A general point on the [0/N] intro.  Bear in mind that this is
(intended to be) for ever.  Five years hence, people won't be
interested in knowing which version the patchset was, in seeing what
changed from the previous iteration, etc.  This is all important and
useful info, of course.  But it's best suited for being below the
"^---$" separator.

Also, those five-years-from-now people won't want to have to go click
on some link to find the performance testing results and suchlike. 
It's better to paste such important info right into their faces.





From fancer.lancer at gmail.com  Thu Dec  7 14:16:12 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Fri, 8 Dec 2023 01:16:12 +0300
Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>
References: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>
Message-ID: <jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz@ntepnnzzelta>

On Thu, Dec 07, 2023 at 03:12:40PM -0600, Andrew Halaney wrote:
> The stmmac_dt_phy() function, which parses the devicetree node of the
> MAC and ultimately causes MDIO bus allocation, misinterprets what
> fixed-link means in relation to the MAC's MDIO bus. This results in
> a MDIO bus being created in situations it need not be.
> 
> Currently a MDIO bus is created if the description is either:
> 
>     1. Not fixed-link
>     2. fixed-link but contains a MDIO bus as well
> 
> The "1" case above isn't always accurate. If there's a phy-handle,
> it could be referencing a phy on another MDIO controller's bus[1]. In
> this case currently the MAC will make a MDIO bus and scan it all
> anyways unnecessarily.
> 
> There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> be created and scanned for a phy. This case can also be inferred from
> the platform description by not having a phy-handle && not being
> fixed-link. This hits case "1" in the current driver's logic.
> 
> Let's improve the logic to create a MDIO bus if either:
> 

>     - Devicetree contains a MDIO bus
>     - !fixed-link && !phy-handle (legacy handling)

If what you suggest here is a free from regressions semantics change
(really hope it is) I will be with both my hands for it. This will
solve the problem we have with one of our device which doesn't have
SMA interface (hardware designers decided to save ~4K gates of the
chip area) but has a PHY externally attached to the DW XGMAC<->XPCS
interface. PHY is accessible via a GPIO-based MDIO bus. BTW having no
SMA interface available on a DW *MAC device but creating the MDIO-bus
on top of the non-existent SMA CSRs anyway causes having _32_ dummy
PHYs created with zero IDs.

> 
> Below upstream devicetree snippets can be found that explain some of
> the cases above more concretely.
> 
> Here's[0] a devicetree example where the MAC is both fixed-link and
> driving a switch on MDIO (case "2" above). This needs a MDIO bus to
> be created:
> 
>     &fec1 {
>             phy-mode = "rmii";
> 
>             fixed-link {
>                     speed = <100>;
>                     full-duplex;
>             };
> 
>             mdio1: mdio {
>                     switch0: switch0 at 0 {
>                             compatible = "marvell,mv88e6190";
>                             pinctrl-0 = <&pinctrl_gpio_switch0>;
>                     };
>             };
>     };
> 
> Here's[1] an example where there is no MDIO bus or fixed-link for
> the ethernet1 MAC, so no MDIO bus should be created since ethernet0
> is the MDIO master for ethernet1's phy:
> 
>     &ethernet0 {
>             phy-mode = "sgmii";
>             phy-handle = <&sgmii_phy0>;
> 
>             mdio {
>                     compatible = "snps,dwmac-mdio";
>                     sgmii_phy0: phy at 8 {
>                             compatible = "ethernet-phy-id0141.0dd4";
>                             reg = <0x8>;
>                             device_type = "ethernet-phy";
>                     };
> 
>                     sgmii_phy1: phy at a {
>                             compatible = "ethernet-phy-id0141.0dd4";
>                             reg = <0xa>;
>                             device_type = "ethernet-phy";
>                     };
>             };
>     };
> 
>     &ethernet1 {
>             phy-mode = "sgmii";
>             phy-handle = <&sgmii_phy1>;
>     };
> 
> Finally there's descriptions like this[2] which don't describe the
> MDIO bus but expect it to be created and the whole address space
> scanned for a phy since there's no phy-handle or fixed-link described:
> 
>     &gmac {
>             phy-supply = <&vcc_lan>;
>             phy-mode = "rmii";
>             snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
>             snps,reset-active-low;
>             snps,reset-delays-us = <0 10000 1000000>;
>     };
> 
> [0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts
> [1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
> [2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164
> 
> Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
> ---
> Changes in v3:

>     - Keep logic out of stmmac_probe_config_dt() since it's already massive (Serge)

Thanks for taking my note into account. The change turned out even
better than I thought it would look like. The MDIO-bus setup procedure
is much more readable now. A small nitpick below.

> 
> Changes in v2:
>     - Handle the fixed-link + mdio case (Andrew Lunn)
>     - Reworded commit message
>     - Still handle the "legacy" case mentioned in the commit
>     - Bit further refactoring of the function for readability
> 
> - Link to v2: https://lore.kernel.org/r/20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca at redhat.com
> - Link to v1: https://lore.kernel.org/netdev/20230808120254.11653-1-brgl at bgdev.pl/
> ---
>  .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 91 +++++++++++++---------
>  1 file changed, 54 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 1ffde555da47..d6079c1432c7 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -296,62 +296,80 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
>  }
>  
>  /**
> - * stmmac_dt_phy - parse device-tree driver parameters to allocate PHY resources
> - * @plat: driver data platform structure
> - * @np: device tree node
> - * @dev: device pointer
> - * Description:
> - * The mdio bus will be allocated in case of a phy transceiver is on board;
> - * it will be NULL if the fixed-link is configured.
> - * If there is the "snps,dwmac-mdio" sub-node the mdio will be allocated
> - * in any case (for DSA, mdio must be registered even if fixed-link).
> - * The table below sums the supported configurations:
> - *	-------------------------------
> - *	snps,phy-addr	|     Y
> - *	-------------------------------
> - *	phy-handle	|     Y
> - *	-------------------------------
> - *	fixed-link	|     N
> - *	-------------------------------
> - *	snps,dwmac-mdio	|
> - *	  even if	|     Y
> - *	fixed-link	|
> - *	-------------------------------
> + * stmmac_of_get_mdio() - Gets the MDIO bus from the devicetree.
> + * @np: devicetree node
>   *
> - * It returns 0 in case of success otherwise -ENODEV.
> + * The MDIO bus will be searched for in the following ways:
> + * 1. The compatible is "snps,dwc-qos-ethernet-4.10" && a "mdio" named
> + *    child node exists
> + * 2. A child node with the "snps,dwmac-mdio" compatible is present
> + *
> + * Return: The MDIO node if present otherwise NULL
>   */
> -static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> -			 struct device_node *np, struct device *dev)
> +static struct device_node *stmmac_of_get_mdio(struct device_node *np)
>  {
> -	bool mdio = !of_phy_is_fixed_link(np);
>  	static const struct of_device_id need_mdio_ids[] = {
>  		{ .compatible = "snps,dwc-qos-ethernet-4.10" },
>  		{},
>  	};
> +	struct device_node *mdio_node = NULL;
>  
>  	if (of_match_node(need_mdio_ids, np)) {
> -		plat->mdio_node = of_get_child_by_name(np, "mdio");
> +		mdio_node = of_get_child_by_name(np, "mdio");
>  	} else {
>  		/**
>  		 * If snps,dwmac-mdio is passed from DT, always register
>  		 * the MDIO
>  		 */
> -		for_each_child_of_node(np, plat->mdio_node) {
> -			if (of_device_is_compatible(plat->mdio_node,
> +		for_each_child_of_node(np, mdio_node) {
> +			if (of_device_is_compatible(mdio_node,
>  						    "snps,dwmac-mdio"))
>  				break;
>  		}
>  	}
>  
> -	if (plat->mdio_node) {
> +	return mdio_node;
> +}
> +
> +/**
> + * stmmac_mdio_setup() - Populate platform related MDIO structures.
> + * @plat: driver data platform structure
> + * @np: devicetree node
> + * @dev: device pointer
> + *
> + * This searches for MDIO information from the devicetree.
> + * If an MDIO node is found, it's assigned to plat->mdio_node and
> + * plat->mdio_bus_data is allocated.
> + * If no connection can be determined, just plat->mdio_bus_data is allocated
> + * to indicate a bus should be created and scanned for a phy.
> + * If it's determined there's no MDIO bus needed, both are left NULL.
> + *
> + * This expects that plat->phy_node has already been searched for.
> + *
> + * Return: 0 on success, errno otherwise.
> + */
> +static int stmmac_mdio_setup(struct plat_stmmacenet_data *plat,
> +			     struct device_node *np, struct device *dev)
> +{
> +	bool legacy_mdio;
> +
> +	plat->mdio_node = stmmac_of_get_mdio(np);
> +	if (plat->mdio_node)
>  		dev_dbg(dev, "Found MDIO subnode\n");
> -		mdio = true;
> -	}
>  
> -	if (mdio) {
> -		plat->mdio_bus_data =
> -			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
> -				     GFP_KERNEL);

> +	/* Legacy devicetrees allowed for no MDIO bus description and expect
> +	 * the bus to be scanned for devices. If there's no phy or fixed-link
> +	 * described assume this is the case since there must be something
> +	 * connected to the MAC.
> +	 */
> +	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
> +	if (legacy_mdio)
> +		dev_info(dev, "Deprecated MDIO bus assumption used\n");
> +
> +	if (plat->mdio_node || legacy_mdio) {
> +		plat->mdio_bus_data = devm_kzalloc(dev,

Special thanks for adding the comment above this code. It will really
save time of figuring out why MDIO-bus needs to be created anyway.

> +						   sizeof(struct stmmac_mdio_bus_data),

Should v4 is required I would suggest to change this to
sizeof(*plat->mdio_bus_data).

Anyway feel free to add:
Reviewed-by: Serge Semin <fancer.lancer at gmail.com>

-Serge(y)

> +						   GFP_KERNEL);
>  		if (!plat->mdio_bus_data)
>  			return -ENOMEM;
>  
> @@ -471,8 +489,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
>  	if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
>  		dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
>  
> -	/* To Configure PHY by using all device-tree supported properties */
> -	rc = stmmac_dt_phy(plat, np, &pdev->dev);
> +	rc = stmmac_mdio_setup(plat, np, &pdev->dev);
>  	if (rc)
>  		return ERR_PTR(rc);
>  
> 
> ---
> base-commit: fd8a79b63710acb84321be3ce74be23c876873fb
> change-id: 20231127-stmmac-no-mdio-node-1db9da8a25d9
> 
> Best regards,
> -- 
> Andrew Halaney <ahalaney at redhat.com>
> 
> 


From wahrenst at gmx.net  Thu Dec  7 14:28:49 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Thu, 7 Dec 2023 23:28:49 +0100
Subject: [PATCH v3 1/4] staging: vc04_services: Drop vchiq_log_error() in
 favour of dev_err
In-Reply-To: <855cd4ee-86db-ca46-ce91-17303941ff82@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-2-umang.jain@ideasonboard.com>
 <d6bf7115-dd15-43a0-b45a-41fc778ff160@gmx.net>
 <6a8566c0-bd26-4ec1-9f7d-d58bbed8411c@ideasonboard.com>
 <3920385c-3c10-471a-ba82-8e48ba34f6a5@gmx.net>
 <855cd4ee-86db-ca46-ce91-17303941ff82@ideasonboard.com>
Message-ID: <12236d9d-fe18-439e-b622-0e64ef112400@gmx.net>

Hi Umang,

Am 07.12.23 um 09:41 schrieb Umang Jain:
> Hi Stefan
>
> On 12/7/23 3:04 AM, Stefan Wahren wrote:
>> Hi Umang,
>>
>> Am 06.12.23 um 06:27 schrieb Umang Jain:
>>> Hi Stefan
>>>
>>> On 12/6/23 1:02 AM, Stefan Wahren wrote:
>>>> Hi Umang,
>>>>
>>>> Am 05.12.23 um 09:41 schrieb Umang Jain:
>>>>> Drop vchiq_log_error() macro which wraps dev_dbg(). Introduce the
>>>>> usage
>>>>> of dev_err() directly.
>>>> sorry, i missed to review the last change. So the change won't be that
>>>> trivial.
>>>
>>> All the changes you said are valid and I have taken a note of it.
>>>
>>> However, I think it would best that if we can address them in a
>>> separate series on top of this (and I will do it). It would seem to be
>>> streamlined on top of this.
>> i would address the comments as separate patches and then finally
>> convert the trivial rest with such a patch within one series. This
>> avoids unnecessary changes and reviewes. But that's just my opinion.
>>
>
> Series is merged by Greg KH (Thank you).
>
> Do you have more comments on 3/4 and 4/4 or are they waiting on your
> review queue. Let me know so that I can prepare a follow up series in
> -one- go.
i was busy. I will look at the rest tomorrow.

Best regards
>
> thanks!
>> Best regards
>



From broonie at kernel.org  Thu Dec  7 14:34:55 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 07 Dec 2023 22:34:55 +0000
Subject: (subset) [PATCH v10 0/8] spi: Add support for stacked/parallel
 memories
In-Reply-To: <20231118135446.52783-1-amit.kumar-mahapatra@amd.com>
References: <20231118135446.52783-1-amit.kumar-mahapatra@amd.com>
Message-ID: <170198849588.340565.18426692818757581382.b4-ty@kernel.org>

On Sat, 18 Nov 2023 19:24:38 +0530, Amit Kumar Mahapatra wrote:
> This patch is in the continuation to the discussions which happened on
> 'commit f89504300e94 ("spi: Stacked/parallel memories bindings")' for
> adding dt-binding support for stacked/parallel memories.
> 
> This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI
> driver to add stacked and parallel memories support.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/8] spi: Add multi-cs memories support in SPI core
      commit: 4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b
[6/8] spi: spi-zynqmp-gqspi: Add stacked memories support in GQSPI driver
      (no commit info)

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From broonie at kernel.org  Thu Dec  7 14:35:00 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 07 Dec 2023 22:35:00 +0000
Subject: (subset) [PATCH v11 00/10] spi: Add support for
 stacked/parallel memories
In-Reply-To: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
Message-ID: <170198850030.340565.15742297562436442635.b4-ty@kernel.org>

On Sat, 25 Nov 2023 14:51:27 +0530, Amit Kumar Mahapatra wrote:
> This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI
> driver to add stacked and parallel memories support.
> 
> The first nine patches
> https://lore.kernel.org/all/20230119185342.2093323-1-amit.kumar-mahapatra at amd.com/
> https://lore.kernel.org/all/20230310173217.3429788-2-amit.kumar-mahapatra at amd.com/
> https://lore.kernel.org/all/20230310173217.3429788-3-amit.kumar-mahapatra at amd.com/
> https://lore.kernel.org/all/20230310173217.3429788-4-amit.kumar-mahapatra at amd.com/
> https://lore.kernel.org/all/20230310173217.3429788-5-amit.kumar-mahapatra at amd.com/
> https://lore.kernel.org/all/20230310173217.3429788-6-amit.kumar-mahapatra at amd.com/
> https://lore.kernel.org/all/20230310173217.3429788-7-amit.kumar-mahapatra at amd.com/
> https://lore.kernel.org/all/20230310173217.3429788-8-amit.kumar-mahapatra at amd.com/
> https://lore.kernel.org/all/20230310173217.3429788-9-amit.kumar-mahapatra at amd.com/
> of the previous series got applied to
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
> for-next But the rest of the patches in the series did not get applied as
> failure was reported for spi driver with GPIO CS, so send the remaining
> patches in the series after rebasing it on top of for-next branch and
> fixing the issue.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[02/10] ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select
        commit: f05e2f61fe88092e0d341ea27644a84e3386358d
[03/10] spi: Add multi-cs memories support in SPI core
        commit: 4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From ahalaney at redhat.com  Thu Dec  7 15:00:15 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Thu, 7 Dec 2023 17:00:15 -0600
Subject: [PATCH net-next v2] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <e64b14c3-4b80-4120-8cc4-9baa40cdcb75@lunn.ch>
References: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
 <e64b14c3-4b80-4120-8cc4-9baa40cdcb75@lunn.ch>
Message-ID: <nx2qggr3aget4t57qbosj6ya5ocq47t6w33ve5ycabs5mzvo7c@vctjvc5gip5d>

On Thu, Dec 07, 2023 at 10:30:23PM +0100, Andrew Lunn wrote:
> On Wed, Dec 06, 2023 at 05:46:09PM -0600, Andrew Halaney wrote:
> > The stmmac_dt_phy() function, which parses the devicetree node of the
> > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > fixed-link means in relation to the MAC's MDIO bus. This results in
> > a MDIO bus being created in situations it need not be.
>
> Please extend that with something like....
>
> This is bad, because ....
>
> Most 'clean' driver unconditionally create the MDIO bus. But stmmac is
> not that clean, and has to keep backwards compatibility to some old
> usage. I'm just wondering what this patch actually brings us, and is
> it worth it. Is it fixing a real bug, or just an optimisation?
>
>    Andrew
>

It is an optimization for speeding up time to link up. I already sent
out v3 moments before this arrived, I'll be sure to capture that more
clearly in v4 (and wait a little longer before respinning it).

I'm trying to optimize this device configuration (as shown in the commit):
"""
    Here's[1] an example where there is no MDIO bus or fixed-link for
    the ethernet1 MAC, so no MDIO bus should be created since ethernet0
    is the MDIO master for ethernet1's phy:

        &ethernet0 {
                phy-mode = "sgmii";
                phy-handle = <&sgmii_phy0>;

                mdio {
                        compatible = "snps,dwmac-mdio";
                        sgmii_phy0: phy at 8 {
                                compatible = "ethernet-phy-id0141.0dd4";
                                reg = <0x8>;
                                device_type = "ethernet-phy";
                        };

                        sgmii_phy1: phy at a {
                                compatible = "ethernet-phy-id0141.0dd4";
                                reg = <0xa>;
                                device_type = "ethernet-phy";
                        };
                };
        };

        &ethernet1 {
                phy-mode = "sgmii";
                phy-handle = <&sgmii_phy1>;
        };
"""

I'm seeing that ethernet1 scans the whole MDIO bus created for it, and
finds nothing, wasting time in the process. Since there's no mdio bus
described (since it's vacant) you get something like this call order:

    stmmac_mdio_register()
    of_mdiobus_register(new_bus, mdio_node) // mdio_node is NULL in this case
    __of_mdiobus_register(mdio, np, owner)  // this doesn't set phy_mask since np == NULL
    __mdiobus_register(mdio, owner)
    mdiobus_scan_bus_c22(bus)
    mdiobus_scan_c22()                      // Called PHY_MAX_ADDR times, probing an empty bus

Which is causing a good bit of delay in the time to link up, each
attempted probe is taking about 5 ms and that's just benchmarking the
get_phy_c22_id() calls, if you look at the whole loop it's greater (but I
am unsure if that's just scheduling contention or something else going
on, once I realized we were doing this work unnecessarily I decided to
try and remove it)

I know you said the standard is to make the MDIO bus unconditionally, but
to me that feels like a waste, and describing say an empty MDIO bus
(which would set the phy_mask for us eventually and not scan a
bunch of phys, untested but I think that would work) seems like a bad
description in the devicetree (I could definitely see describing an
empty MDIO bus getting NACKed, but that's a guess).

Please let me know if you disagree with that logic and have some
alternative solutions for optimizing. In either case I think this code
needs some cleaning so I'll carry this through. It also seems that
unconditional creation of the MDIO bus is something that's biting some
stmmac variants that lack an MDIO controller based on Serge's latest
comments on v3:

    https://lore.kernel.org/netdev/jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz at ntepnnzzelta/

Thanks,
Andrew



From ahalaney at redhat.com  Thu Dec  7 15:07:24 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Thu, 7 Dec 2023 17:07:24 -0600
Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz@ntepnnzzelta>
References: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>
 <jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz@ntepnnzzelta>
Message-ID: <hxds75erxqcfkufxnfbyo2up4b4jeicmi3f5xr6qlb3yf7fe76@4byeq62jhu4o>

On Fri, Dec 08, 2023 at 01:16:12AM +0300, Serge Semin wrote:
> On Thu, Dec 07, 2023 at 03:12:40PM -0600, Andrew Halaney wrote:
> > The stmmac_dt_phy() function, which parses the devicetree node of the
> > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > fixed-link means in relation to the MAC's MDIO bus. This results in
> > a MDIO bus being created in situations it need not be.
> > 
> > Currently a MDIO bus is created if the description is either:
> > 
> >     1. Not fixed-link
> >     2. fixed-link but contains a MDIO bus as well
> > 
> > The "1" case above isn't always accurate. If there's a phy-handle,
> > it could be referencing a phy on another MDIO controller's bus[1]. In
> > this case currently the MAC will make a MDIO bus and scan it all
> > anyways unnecessarily.
> > 
> > There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> > be created and scanned for a phy. This case can also be inferred from
> > the platform description by not having a phy-handle && not being
> > fixed-link. This hits case "1" in the current driver's logic.
> > 
> > Let's improve the logic to create a MDIO bus if either:
> > 
> 
> >     - Devicetree contains a MDIO bus
> >     - !fixed-link && !phy-handle (legacy handling)
> 
> If what you suggest here is a free from regressions semantics change
> (really hope it is) I will be with both my hands for it. This will
> solve the problem we have with one of our device which doesn't have
> SMA interface (hardware designers decided to save ~4K gates of the
> chip area) but has a PHY externally attached to the DW XGMAC<->XPCS
> interface. PHY is accessible via a GPIO-based MDIO bus. BTW having no
> SMA interface available on a DW *MAC device but creating the MDIO-bus
> on top of the non-existent SMA CSRs anyway causes having _32_ dummy
> PHYs created with zero IDs.

I hope it is regression free! I have tested both the [1] and [2] cases
(I hacked up the devicetree for [1] to make it look like [2]) without
any issue.

Sorry, I don't have any docs for stmmac hardware so this might be
answered in there (or just common net knowledge that I can't find
online)... what's SMA stand for? I assume it's the MDIO interface.

I agree though, if you have a phy-handle and no mdio node in your
devicetree this patch series should bail out without registering a bus
in stmmac_mdio_register().

> 
> > 
> > Below upstream devicetree snippets can be found that explain some of
> > the cases above more concretely.

<snip>

> > -	if (mdio) {
> > -		plat->mdio_bus_data =
> > -			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
> > -				     GFP_KERNEL);
> 
> > +	/* Legacy devicetrees allowed for no MDIO bus description and expect
> > +	 * the bus to be scanned for devices. If there's no phy or fixed-link
> > +	 * described assume this is the case since there must be something
> > +	 * connected to the MAC.
> > +	 */
> > +	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
> > +	if (legacy_mdio)
> > +		dev_info(dev, "Deprecated MDIO bus assumption used\n");
> > +
> > +	if (plat->mdio_node || legacy_mdio) {
> > +		plat->mdio_bus_data = devm_kzalloc(dev,
> 
> Special thanks for adding the comment above this code. It will really
> save time of figuring out why MDIO-bus needs to be created anyway.
> 
> > +						   sizeof(struct stmmac_mdio_bus_data),
> 
> Should v4 is required I would suggest to change this to
> sizeof(*plat->mdio_bus_data).
> 
> Anyway feel free to add:
> Reviewed-by: Serge Semin <fancer.lancer at gmail.com>
> 
> -Serge(y)

Sure I will spin v4 to pick that up, thanks for catching it. I'll also
improve the motivation in the commit message a hair more per Andrew
Lunn's request over here on v2 (and will hold off a little bit just to
make sure reviews come in before a respin):

    https://lore.kernel.org/netdev/e64b14c3-4b80-4120-8cc4-9baa40cdcb75 at lunn.ch/

Thanks,
Andrew



From chunkuang.hu at kernel.org  Thu Dec  7 15:31:56 2023
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Fri, 8 Dec 2023 07:31:56 +0800
Subject: [PATCH v3] drm/mediatek: Stop using iommu_present()
In-Reply-To: <fd1b62aa006556f29f37535814abfe41be63f7ae.1700746094.git.robin.murphy@arm.com>
References: <fd1b62aa006556f29f37535814abfe41be63f7ae.1700746094.git.robin.murphy@arm.com>
Message-ID: <CAAOTY_9HG_Y+vJ4g_V+5DXEFsPP=2vudyxbhcrTXYKn0E=9sLQ@mail.gmail.com>

Hi, Robin:

Robin Murphy <robin.murphy at arm.com> ? 2023?11?23? ?? ??9:41???
>
> Remove the pointless check. If an IOMMU is providing transparent DMA API
> ops for any device(s) we care about, the DT code will have enforced the
> appropriate probe ordering already. And if the IOMMU *is* entirely
> absent, then attempting to go ahead with CMA and either suceeding or
> failing decisively seems more useful than deferring forever.

Applied to mediatek-drm-next [1], thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>
> I realised that last time I sent this I probably should have CCed a
> wider audience of reviewers, so here's one with an updated commit
> message as well to make the resend more worthwhile.
>
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ----
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 2dfaa613276a..48581da51857 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -5,7 +5,6 @@
>   */
>
>  #include <linux/component.h>
> -#include <linux/iommu.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_platform.h>
> @@ -608,9 +607,6 @@ static int mtk_drm_bind(struct device *dev)
>         struct drm_device *drm;
>         int ret, i;
>
> -       if (!iommu_present(&platform_bus_type))
> -               return -EPROBE_DEFER;
> -
>         pdev = of_find_device_by_node(private->mutex_node);
>         if (!pdev) {
>                 dev_err(dev, "Waiting for disp-mutex device %pOF\n",
> --
> 2.39.2.101.g768bb238c484.dirty
>


From chunkuang.hu at kernel.org  Thu Dec  7 15:54:00 2023
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Fri, 8 Dec 2023 07:54:00 +0800
Subject: [PATCH v4 1/2] drm/mediatek: fix kernel oops if no crtc is found
In-Reply-To: <20230905084922.3908121-1-mwalle@kernel.org>
References: <20230905084922.3908121-1-mwalle@kernel.org>
Message-ID: <CAAOTY_9xrt_ku-fZotJAnPa2ns-2PCGken4TepMrQYG9KEJcFA@mail.gmail.com>

Hi, Michael:

Michael Walle <mwalle at kernel.org> ? 2023?9?5? ?? ??4:49???
>
> drm_crtc_from_index(0) might return NULL if there are no CRTCs
> registered at all which will lead to a kernel oops in
> mtk_drm_crtc_dma_dev_get(). Add the missing return value check.

Applied to mediatek-drm-fixes [1], thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes

Regards,
Chun-Kuang.

>
> Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195")
> Signed-off-by: Michael Walle <mwalle at kernel.org>
> Reviewed-by: N?colas F. R. A. Prado <nfraprado at collabora.com>
> Tested-by: N?colas F. R. A. Prado <nfraprado at collabora.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> ---
> v4:
>  - collected tags
> v3:
>  - none
> v2:
>  - collected tags
>  - fixed typos
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 93552d76b6e7..2c582498817e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -420,6 +420,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>         struct mtk_drm_private *private = drm->dev_private;
>         struct mtk_drm_private *priv_n;
>         struct device *dma_dev = NULL;
> +       struct drm_crtc *crtc;
>         int ret, i, j;
>
>         if (drm_firmware_drivers_only())
> @@ -494,7 +495,9 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>         }
>
>         /* Use OVL device for all DMA memory allocations */
> -       dma_dev = mtk_drm_crtc_dma_dev_get(drm_crtc_from_index(drm, 0));
> +       crtc = drm_crtc_from_index(drm, 0);
> +       if (crtc)
> +               dma_dev = mtk_drm_crtc_dma_dev_get(crtc);
>         if (!dma_dev) {
>                 ret = -ENODEV;
>                 dev_err(drm->dev, "Need at least one OVL device\n");
> --
> 2.39.2
>


From irogers at google.com  Thu Dec  7 16:01:07 2023
From: irogers at google.com (Ian Rogers)
Date: Thu, 7 Dec 2023 16:01:07 -0800
Subject: [PATCH V2 3/5] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <20231207192338.400336-4-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com> <20231207192338.400336-4-kan.liang@linux.intel.com>
Message-ID: <CAP-5=fWh00C+A5rqOuqj_MEcipENcXM0zzjqMkeDDU8+WV=3eA@mail.gmail.com>

On Thu, Dec 7, 2023 at 11:24?AM <kan.liang at linux.intel.com> wrote:
>
> From: Kan Liang <kan.liang at linux.intel.com>
>
> Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
> one.
>
> The mem_load events may have a different format. Add ldlat and aux_event
> in the struct perf_mem_event to indicate the format and the extra aux
> event.
>
> Add perf_mem_events_intel_aux[] to support the extra mem_load_aux event.
>
> Rename perf_mem_events__name to perf_pmu__mem_events_name.
>
> Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>

Reviewed-by: Ian Rogers <irogers at google.com>

Thanks,
Ian

> ---
>  tools/perf/arch/arm64/util/mem-events.c   | 26 ++-------
>  tools/perf/arch/powerpc/util/mem-events.c | 13 ++---
>  tools/perf/arch/powerpc/util/mem-events.h |  7 +++
>  tools/perf/arch/powerpc/util/pmu.c        | 11 ++++
>  tools/perf/arch/x86/util/mem-events.c     | 70 +++++------------------
>  tools/perf/arch/x86/util/mem-events.h     |  1 +
>  tools/perf/arch/x86/util/pmu.c            |  8 ++-
>  tools/perf/util/mem-events.c              | 56 ++++++++++++------
>  tools/perf/util/mem-events.h              |  3 +-
>  9 files changed, 89 insertions(+), 106 deletions(-)
>  create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
>  create mode 100644 tools/perf/arch/powerpc/util/pmu.c
>
> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
> index 2602e8688727..eb2ef84f0fc8 100644
> --- a/tools/perf/arch/arm64/util/mem-events.c
> +++ b/tools/perf/arch/arm64/util/mem-events.c
> @@ -2,28 +2,10 @@
>  #include "map_symbol.h"
>  #include "mem-events.h"
>
> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
> -       E("spe-load",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",       "arm_spe_0"),
> -       E("spe-store",  "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                      "arm_spe_0"),
> -       E("spe-ldst",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",       "arm_spe_0"),
> +       E("spe-load",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",      "arm_spe_0",    true,   0),
> +       E("spe-store",  "%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                     "arm_spe_0",    false,  0),
> +       E("spe-ldst",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",      "arm_spe_0",    true,   0),
>  };
> -
> -static char mem_ev_name[100];
> -
> -const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
> -{
> -       struct perf_mem_event *e = &perf_mem_events_arm[i];
> -
> -       if (i >= PERF_MEM_EVENTS__MAX)
> -               return NULL;
> -
> -       if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE)
> -               scnprintf(mem_ev_name, sizeof(mem_ev_name),
> -                         e->name, perf_mem_events__loads_ldlat);
> -       else /* PERF_MEM_EVENTS__STORE */
> -               scnprintf(mem_ev_name, sizeof(mem_ev_name), e->name);
> -
> -       return mem_ev_name;
> -}
> diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
> index 78b986e5268d..b7883e38950f 100644
> --- a/tools/perf/arch/powerpc/util/mem-events.c
> +++ b/tools/perf/arch/powerpc/util/mem-events.c
> @@ -2,11 +2,10 @@
>  #include "map_symbol.h"
>  #include "mem-events.h"
>
> -/* PowerPC does not support 'ldlat' parameter. */
> -const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
> -{
> -       if (i == PERF_MEM_EVENTS__LOAD)
> -               return "cpu/mem-loads/";
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>
> -       return "cpu/mem-stores/";
> -}
> +struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
> +       E("ldlat-loads",        "%s/mem-loads/",        "cpu/events/mem-loads",         false,  0),
> +       E("ldlat-stores",       "%s/mem-stores/",       "cpu/events/mem-stores",        false,  0),
> +       E(NULL,                 NULL,                   NULL,                           false,  0),
> +};
> diff --git a/tools/perf/arch/powerpc/util/mem-events.h b/tools/perf/arch/powerpc/util/mem-events.h
> new file mode 100644
> index 000000000000..6acc3d1b6873
> --- /dev/null
> +++ b/tools/perf/arch/powerpc/util/mem-events.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _POWER_MEM_EVENTS_H
> +#define _POWER_MEM_EVENTS_H
> +
> +extern struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX];
> +
> +#endif /* _POWER_MEM_EVENTS_H */
> diff --git a/tools/perf/arch/powerpc/util/pmu.c b/tools/perf/arch/powerpc/util/pmu.c
> new file mode 100644
> index 000000000000..168173f88ddb
> --- /dev/null
> +++ b/tools/perf/arch/powerpc/util/pmu.c
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <string.h>
> +
> +#include "../../../util/pmu.h"
> +
> +void perf_pmu__arch_init(struct perf_pmu *pmu)
> +{
> +       if (pmu->is_core)
> +               pmu->mem_events = perf_mem_events_power;
> +}
> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index 5fb41d50118d..f0e66a0151a0 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -7,25 +7,26 @@
>  #include "linux/string.h"
>  #include "env.h"
>
> -static char mem_loads_name[100];
> -static bool mem_loads_name__init;
> -static char mem_stores_name[100];
> -
>  #define MEM_LOADS_AUX          0x8203
> -#define MEM_LOADS_AUX_NAME     "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P"
>
> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
> -       E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "%s/events/mem-loads"),
> -       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores"),
> -       E(NULL,                 NULL,                           NULL),
> +       E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "%s/events/mem-loads",  true,   0),
> +       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores", false,  0),
> +       E(NULL,                 NULL,                           NULL,                   false,  0),
> +};
> +
> +struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
> +       E("ldlat-loads",        "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P", "%s/events/mem-loads",  true,   MEM_LOADS_AUX),
> +       E("ldlat-stores",       "%s/mem-stores/P",              "%s/events/mem-stores", false,  0),
> +       E(NULL,                 NULL,                           NULL,                   false,  0),
>  };
>
>  struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
> -       E(NULL,         NULL,           NULL),
> -       E(NULL,         NULL,           NULL),
> -       E("mem-ldst",   "ibs_op//",     "ibs_op"),
> +       E(NULL,         NULL,           NULL,           false,  0),
> +       E(NULL,         NULL,           NULL,           false,  0),
> +       E("mem-ldst",   "%s//",         "ibs_op",       false,  0),
>  };
>
>  bool is_mem_loads_aux_event(struct evsel *leader)
> @@ -40,48 +41,3 @@ bool is_mem_loads_aux_event(struct evsel *leader)
>
>         return leader->core.attr.config == MEM_LOADS_AUX;
>  }
> -
> -const char *perf_mem_events__name(int i, const char *pmu_name)
> -{
> -       struct perf_mem_event *e;
> -
> -       if (x86__is_amd_cpu())
> -               e = &perf_mem_events_amd[i];
> -       else
> -               e = &perf_mem_events_intel[i];
> -
> -       if (!e)
> -               return NULL;
> -
> -       if (i == PERF_MEM_EVENTS__LOAD) {
> -               if (mem_loads_name__init && !pmu_name)
> -                       return mem_loads_name;
> -
> -               if (!pmu_name) {
> -                       mem_loads_name__init = true;
> -                       pmu_name = "cpu";
> -               }
> -
> -               if (perf_pmus__have_event(pmu_name, "mem-loads-aux")) {
> -                       scnprintf(mem_loads_name, sizeof(mem_loads_name),
> -                                 MEM_LOADS_AUX_NAME, pmu_name, pmu_name,
> -                                 perf_mem_events__loads_ldlat);
> -               } else {
> -                       scnprintf(mem_loads_name, sizeof(mem_loads_name),
> -                                 e->name, pmu_name,
> -                                 perf_mem_events__loads_ldlat);
> -               }
> -               return mem_loads_name;
> -       }
> -
> -       if (i == PERF_MEM_EVENTS__STORE) {
> -               if (!pmu_name)
> -                       pmu_name = "cpu";
> -
> -               scnprintf(mem_stores_name, sizeof(mem_stores_name),
> -                         e->name, pmu_name);
> -               return mem_stores_name;
> -       }
> -
> -       return e->name;
> -}
> diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
> index 3959e427f482..f55c8d3b7d59 100644
> --- a/tools/perf/arch/x86/util/mem-events.h
> +++ b/tools/perf/arch/x86/util/mem-events.h
> @@ -3,6 +3,7 @@
>  #define _X86_MEM_EVENTS_H
>
>  extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
> +extern struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX];
>
>  extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
>
> diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
> index cd22e80e5657..0f49ff13cfe2 100644
> --- a/tools/perf/arch/x86/util/pmu.c
> +++ b/tools/perf/arch/x86/util/pmu.c
> @@ -35,8 +35,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
>         if (x86__is_amd_cpu()) {
>                 if (!strcmp(pmu->name, "ibs_op"))
>                         pmu->mem_events = perf_mem_events_amd;
> -       } else if (pmu->is_core)
> -               pmu->mem_events = perf_mem_events_intel;
> +       } else if (pmu->is_core) {
> +               if (perf_pmu__have_event(pmu, "mem-loads-aux"))
> +                       pmu->mem_events = perf_mem_events_intel_aux;
> +               else
> +                       pmu->mem_events = perf_mem_events_intel;
> +       }
>  }
>
>  int perf_pmus__num_mem_pmus(void)
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index 27a33dc44964..c9a40b64e538 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -17,17 +17,17 @@
>
>  unsigned int perf_mem_events__loads_ldlat = 30;
>
> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>
>  struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
> -       E("ldlat-loads",        "cpu/mem-loads,ldlat=%u/P",     "cpu/events/mem-loads"),
> -       E("ldlat-stores",       "cpu/mem-stores/P",             "cpu/events/mem-stores"),
> -       E(NULL,                 NULL,                           NULL),
> +       E("ldlat-loads",        "%s/mem-loads,ldlat=%u/P",      "cpu/events/mem-loads",         true,   0),
> +       E("ldlat-stores",       "%s/mem-stores/P",              "cpu/events/mem-stores",        false,  0),
> +       E(NULL,                 NULL,                           NULL,                           false,  0),
>  };
>  #undef E
>
>  static char mem_loads_name[100];
> -static bool mem_loads_name__init;
> +static char mem_stores_name[100];
>
>  struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i)
>  {
> @@ -62,23 +62,45 @@ struct perf_pmu *perf_mem_events_find_pmu(void)
>         return perf_pmus__scan_mem(NULL);
>  }
>
> -const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
> +static const char *perf_pmu__mem_events_name(int i, struct perf_pmu *pmu)
>  {
> -       struct perf_mem_event *e = &perf_mem_events[i];
> +       struct perf_mem_event *e = &pmu->mem_events[i];
>
>         if (!e)
>                 return NULL;
>
> -       if (i == PERF_MEM_EVENTS__LOAD) {
> -               if (!mem_loads_name__init) {
> -                       mem_loads_name__init = true;
> -                       scnprintf(mem_loads_name, sizeof(mem_loads_name),
> -                                 e->name, perf_mem_events__loads_ldlat);
> +       if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE) {
> +               if (e->ldlat) {
> +                       if (!e->aux_event) {
> +                               /* ARM and Most of Intel */
> +                               scnprintf(mem_loads_name, sizeof(mem_loads_name),
> +                                         e->name, pmu->name,
> +                                         perf_mem_events__loads_ldlat);
> +                       } else {
> +                               /* Intel with mem-loads-aux event */
> +                               scnprintf(mem_loads_name, sizeof(mem_loads_name),
> +                                         e->name, pmu->name, pmu->name,
> +                                         perf_mem_events__loads_ldlat);
> +                       }
> +               } else {
> +                       if (!e->aux_event) {
> +                               /* AMD and POWER */
> +                               scnprintf(mem_loads_name, sizeof(mem_loads_name),
> +                                         e->name, pmu->name);
> +                       } else
> +                               return NULL;
>                 }
> +
>                 return mem_loads_name;
>         }
>
> -       return e->name;
> +       if (i == PERF_MEM_EVENTS__STORE) {
> +               scnprintf(mem_stores_name, sizeof(mem_stores_name),
> +                         e->name, pmu->name);
> +               return mem_stores_name;
> +       }
> +
> +       return NULL;
>  }
>
>  __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
> @@ -175,7 +197,7 @@ void perf_pmu__mem_events_list(struct perf_pmu *pmu)
>                         e->tag ? 13 : 0,
>                         e->tag ? : "",
>                         e->tag && verbose > 0 ? 25 : 0,
> -                       e->tag && verbose > 0 ? perf_mem_events__name(j, NULL) : "",
> +                       e->tag && verbose > 0 ? perf_pmu__mem_events_name(j, pmu) : "",
>                         e->supported ? ": available\n" : "");
>         }
>  }
> @@ -198,15 +220,15 @@ int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
>
>                         if (!e->supported) {
>                                 pr_err("failed: event '%s' not supported\n",
> -                                       perf_mem_events__name(j, pmu->name));
> +                                       perf_pmu__mem_events_name(j, pmu));
>                                 return -1;
>                         }
>
>                         if (perf_pmus__num_mem_pmus() == 1) {
>                                 rec_argv[i++] = "-e";
> -                               rec_argv[i++] = perf_mem_events__name(j, NULL);
> +                               rec_argv[i++] = perf_pmu__mem_events_name(j, pmu);
>                         } else {
> -                               const char *s = perf_mem_events__name(j, pmu->name);
> +                               const char *s = perf_pmu__mem_events_name(j, pmu);
>
>                                 if (!perf_mem_event__supported(mnt, pmu, e))
>                                         continue;
> diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
> index 0ad301a2e424..79d342768d12 100644
> --- a/tools/perf/util/mem-events.h
> +++ b/tools/perf/util/mem-events.h
> @@ -14,6 +14,8 @@
>  struct perf_mem_event {
>         bool            record;
>         bool            supported;
> +       bool            ldlat;
> +       u32             aux_event;
>         const char      *tag;
>         const char      *name;
>         const char      *sysfs_name;
> @@ -39,7 +41,6 @@ extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
>  int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str);
>  int perf_pmu__mem_events_init(struct perf_pmu *pmu);
>
> -const char *perf_mem_events__name(int i, const char *pmu_name);
>  struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i);
>  struct perf_pmu *perf_mem_events_find_pmu(void);
>  bool is_mem_loads_aux_event(struct evsel *leader);
> --
> 2.35.1
>


From apopple at nvidia.com  Thu Dec  7 16:32:38 2023
From: apopple at nvidia.com (Alistair Popple)
Date: Fri, 08 Dec 2023 11:32:38 +1100
Subject: [PATCH v3 01/15] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <20231204105440.61448-2-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-2-ryan.roberts@arm.com>
Message-ID: <87lea5a5qm.fsf@nvdebian.thelocal>


Ryan Roberts <ryan.roberts at arm.com> writes:

<snip>

>  /*
>   * On some architectures hardware does not set page access bit when accessing
>   * memory page, it is responsibility of software setting this bit. It brings
> diff --git a/mm/memory.c b/mm/memory.c
> index 1f18ed4a5497..8a87a488950c 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -924,68 +924,162 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
>  	return 0;
>  }
>  
> +static int folio_nr_pages_cont_mapped(struct folio *folio,
> +				      struct page *page, pte_t *pte,
> +				      unsigned long addr, unsigned long end,
> +				      pte_t ptent, bool enforce_uffd_wp,
> +				      int *dirty_nr, int *writable_nr)
> +{
> +	int floops;
> +	int i;
> +	unsigned long pfn;
> +	bool prot_none;
> +	bool uffd_wp;
> +
> +	if (!folio_test_large(folio))
> +		return 1;
> +
> +	/*
> +	 * Loop either to `end` or to end of folio if its contiguously mapped,
> +	 * whichever is smaller.
> +	 */
> +	floops = (end - addr) >> PAGE_SHIFT;
> +	floops = min_t(int, floops,
> +		       folio_pfn(folio_next(folio)) - page_to_pfn(page));

Much better, thanks for addressing my comments here.

> +
> +	pfn = page_to_pfn(page);
> +	prot_none = pte_protnone(ptent);
> +	uffd_wp = pte_uffd_wp(ptent);
> +
> +	*dirty_nr = !!pte_dirty(ptent);
> +	*writable_nr = !!pte_write(ptent);
> +
> +	pfn++;
> +	pte++;
> +
> +	for (i = 1; i < floops; i++) {
> +		ptent = ptep_get(pte);
> +
> +		if (!pte_present(ptent) || pte_pfn(ptent) != pfn ||
> +		    prot_none != pte_protnone(ptent) ||
> +		    (enforce_uffd_wp && uffd_wp != pte_uffd_wp(ptent)))
> +			break;
> +
> +		if (pte_dirty(ptent))
> +			(*dirty_nr)++;
> +		if (pte_write(ptent))
> +			(*writable_nr)++;
> +
> +		pfn++;
> +		pte++;
> +	}
> +
> +	return i;
> +}
> +
>  /*
> - * Copy one pte.  Returns 0 if succeeded, or -EAGAIN if one preallocated page
> - * is required to copy this pte.
> + * Copy set of contiguous ptes.  Returns number of ptes copied if succeeded
> + * (always gte 1), or -EAGAIN if one preallocated page is required to copy the
> + * first pte.
>   */
>  static inline int
> -copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
> -		 pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
> -		 struct folio **prealloc)
> +copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
> +		  pte_t *dst_pte, pte_t *src_pte,
> +		  unsigned long addr, unsigned long end,
> +		  int *rss, struct folio **prealloc)
>  {
>  	struct mm_struct *src_mm = src_vma->vm_mm;
>  	unsigned long vm_flags = src_vma->vm_flags;
>  	pte_t pte = ptep_get(src_pte);
>  	struct page *page;
>  	struct folio *folio;
> +	int nr = 1;
> +	bool anon = false;
> +	bool enforce_uffd_wp = userfaultfd_wp(dst_vma);
> +	int nr_dirty = !!pte_dirty(pte);
> +	int nr_writable = !!pte_write(pte);
> +	int i, ret;
>  
>  	page = vm_normal_page(src_vma, addr, pte);
> -	if (page)
> +	if (page) {
>  		folio = page_folio(page);
> -	if (page && folio_test_anon(folio)) {
> -		/*
> -		 * If this page may have been pinned by the parent process,
> -		 * copy the page immediately for the child so that we'll always
> -		 * guarantee the pinned page won't be randomly replaced in the
> -		 * future.
> -		 */
> -		folio_get(folio);
> -		if (unlikely(page_try_dup_anon_rmap(page, false, src_vma))) {
> -			/* Page may be pinned, we have to copy. */
> -			folio_put(folio);
> -			return copy_present_page(dst_vma, src_vma, dst_pte, src_pte,
> -						 addr, rss, prealloc, page);
> +		anon = folio_test_anon(folio);
> +		nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
> +						pte, enforce_uffd_wp, &nr_dirty,
> +						&nr_writable);
> +		folio_ref_add(folio, nr);
> +
> +		for (i = 0; i < nr; i++, page++) {
> +			if (anon) {
> +				/*
> +				 * If this page may have been pinned by the
> +				 * parent process, copy the page immediately for
> +				 * the child so that we'll always guarantee the
> +				 * pinned page won't be randomly replaced in the
> +				 * future.
> +				 */
> +				if (unlikely(page_try_dup_anon_rmap(
> +						page, false, src_vma))) {
> +					if (i != 0)
> +						break;
> +					/* Page may be pinned, we have to copy. */
> +					folio_ref_sub(folio, nr);
> +					ret = copy_present_page(
> +						dst_vma, src_vma, dst_pte,
> +						src_pte, addr, rss, prealloc,
> +						page);
> +					return ret == 0 ? 1 : ret;
> +				}
> +				rss[MM_ANONPAGES]++;
> +				VM_BUG_ON(PageAnonExclusive(page));
> +			} else {
> +				page_dup_file_rmap(page, false);
> +				rss[mm_counter_file(page)]++;
> +			}
>  		}
> -		rss[MM_ANONPAGES]++;
> -	} else if (page) {
> -		folio_get(folio);
> -		page_dup_file_rmap(page, false);
> -		rss[mm_counter_file(page)]++;
> -	}
>  
> -	/*
> -	 * If it's a COW mapping, write protect it both
> -	 * in the parent and the child
> -	 */
> -	if (is_cow_mapping(vm_flags) && pte_write(pte)) {
> -		ptep_set_wrprotect(src_mm, addr, src_pte);
> -		pte = pte_wrprotect(pte);
> +		if (i < nr) {
> +			folio_ref_sub(folio, nr - i);
> +			nr = i;
> +		}
>  	}
> -	VM_BUG_ON(page && folio_test_anon(folio) && PageAnonExclusive(page));
>  
>  	/*
> -	 * If it's a shared mapping, mark it clean in
> -	 * the child
> +	 * If it's a shared mapping, mark it clean and write protected in the
> +	 * child, and rely on a write fault to fix up the permissions. This
> +	 * allows determining batch size without having to consider RO/RW
> +	 * permissions. As an optimization, skip wrprotect if all ptes in the
> +	 * batch have the same permissions.
> +	 *
> +	 * If its a private (CoW) mapping, mark it dirty in the child if _any_
> +	 * of the parent mappings in the block were marked dirty. The contiguous
> +	 * block of mappings are all backed by the same folio, so if any are
> +	 * dirty then the whole folio is dirty. This allows determining batch
> +	 * size without having to consider the dirty bit. Further, write protect
> +	 * it both in the parent and the child so that a future write will cause
> +	 * a CoW. As as an optimization, skip the wrprotect if all the ptes in
> +	 * the batch are already readonly.
>  	 */
> -	if (vm_flags & VM_SHARED)
> +	if (vm_flags & VM_SHARED) {
>  		pte = pte_mkclean(pte);
> -	pte = pte_mkold(pte);
> +		if (nr_writable > 0 && nr_writable < nr)
> +			pte = pte_wrprotect(pte);
> +	} else {
> +		if (nr_dirty)
> +			pte = pte_mkdirty(pte);
> +		if (nr_writable) {
> +			ptep_set_wrprotects(src_mm, addr, src_pte, nr);
> +			pte = pte_wrprotect(pte);
> +		}
> +	}
>  
> -	if (!userfaultfd_wp(dst_vma))
> +	pte = pte_mkold(pte);
> +	pte = pte_clear_soft_dirty(pte);
> +	if (!enforce_uffd_wp)
>  		pte = pte_clear_uffd_wp(pte);
>  
> -	set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte);
> -	return 0;
> +	set_ptes(dst_vma->vm_mm, addr, dst_pte, pte, nr);
> +	return nr;

I don't have any further comments and you have addressed my previous
ones so feel free to add:

Reviewed-by: Alistair Popple <apopple at nvidia.com>

However whilst I think the above CoW sequence looks correct it would be
nice if someone else could take a look as well.

>  }
>  
>  static inline struct folio *page_copy_prealloc(struct mm_struct *src_mm,
> @@ -1021,6 +1115,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  	int rss[NR_MM_COUNTERS];
>  	swp_entry_t entry = (swp_entry_t){0};
>  	struct folio *prealloc = NULL;
> +	int nr_ptes;
>  
>  again:
>  	progress = 0;
> @@ -1051,6 +1146,8 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  	arch_enter_lazy_mmu_mode();
>  
>  	do {
> +		nr_ptes = 1;
> +
>  		/*
>  		 * We are holding two locks at this point - either of them
>  		 * could generate latencies in another task on another CPU.
> @@ -1086,16 +1183,21 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  			 * the now present pte.
>  			 */
>  			WARN_ON_ONCE(ret != -ENOENT);
> +			ret = 0;
>  		}
> -		/* copy_present_pte() will clear `*prealloc' if consumed */
> -		ret = copy_present_pte(dst_vma, src_vma, dst_pte, src_pte,
> -				       addr, rss, &prealloc);
> +		/* copy_present_ptes() will clear `*prealloc' if consumed */
> +		nr_ptes = copy_present_ptes(dst_vma, src_vma, dst_pte, src_pte,
> +					    addr, end, rss, &prealloc);
> +
>  		/*
>  		 * If we need a pre-allocated page for this pte, drop the
>  		 * locks, allocate, and try again.
>  		 */
> -		if (unlikely(ret == -EAGAIN))
> +		if (unlikely(nr_ptes == -EAGAIN)) {
> +			ret = -EAGAIN;
>  			break;
> +		}
> +
>  		if (unlikely(prealloc)) {
>  			/*
>  			 * pre-alloc page cannot be reused by next time so as
> @@ -1106,8 +1208,9 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>  			folio_put(prealloc);
>  			prealloc = NULL;
>  		}
> -		progress += 8;
> -	} while (dst_pte++, src_pte++, addr += PAGE_SIZE, addr != end);
> +		progress += 8 * nr_ptes;
> +	} while (dst_pte += nr_ptes, src_pte += nr_ptes,
> +		 addr += PAGE_SIZE * nr_ptes, addr != end);
>  
>  	arch_leave_lazy_mmu_mode();
>  	pte_unmap_unlock(orig_src_pte, src_ptl);



From dianders at chromium.org  Thu Dec  7 17:02:56 2023
From: dianders at chromium.org (Douglas Anderson)
Date: Thu,  7 Dec 2023 17:02:56 -0800
Subject: [PATCH] arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI first
Message-ID: <20231207170251.1.Id4817adef610302554b8aa42b090d57270dc119c@changeid>

When testing hard lockup handling on my sc7180-trogdor-lazor device
with pseudo-NMI enabled, with serial console enabled and with kgdb
disabled, I found that the stack crawls printed to the serial console
ended up as a jumbled mess. After rebooting, the pstore-based console
looked fine though. Also, enabling kgdb to trap the panic made the
console look fine and avoided the mess.

After a bit of tracking down, I came to the conclusion that this was
what was happening:
1. The panic path was stopping all other CPUs with
   panic_other_cpus_shutdown().
2. At least one of those other CPUs was in the middle of printing to
   the serial console and holding the console port's lock, which is
   grabbed with "irqsave". ...but since we were stopping with an NMI
   we didn't care about the "irqsave" and interrupted anyway.
3. Since we stopped the CPU while it was holding the lock it would
   never release it.
4. All future calls to output to the console would end up failing to
   get the lock in qcom_geni_serial_console_write(). This isn't
   _totally_ unexpected at panic time but it's a code path that's not
   well tested, hard to get right, and apparently doesn't work
   terribly well on the Qualcomm geni serial driver.

It would probably be a reasonable idea to try to make the Qualcomm
geni serial driver work better, but also it's nice not to get into
this situation in the first place.

Taking a page from what x86 appears to do in native_stop_other_cpus(),
let's do this:
1. First, we'll try to stop other CPUs with a normal IPI and wait a
   second. This gives them a chance to leave critical sections.
2. If CPUs fail to stop then we'll retry with an NMI, but give a much
   lower timeout since there's no good reason for a CPU not to react
   quickly to a NMI.

This works well and avoids the corrupted console and (presumably)
could help avoid other similar issues.

In order to do this, we need to do a little re-organization of our
IPIs since we don't have any more free IDs. We'll do what was
suggested in previous conversations and combine "stop" and "crash
stop". That frees up an IPI so now we can have a "stop" and "stop
NMI".

In order to do this we also need a slight change in the way we keep
track of which CPUs still need to be stopped. We need to know
specifically which CPUs haven't stopped yet when we fall back to NMI
but in the "crash stop" case the "cpu_online_mask" isn't updated as
CPUs go down. This is why that code path had an atomic of the number
of CPUs left. We'll solve this by making the cpumask into a
global. This has a potential memory implication--with NR_CPUs = 4096
this is 4096/8 = 512 bytes of globals. On the upside in that same case
we take 512 bytes off the stack which could potentially have made the
stop code less reliable. It can be noted that the NMI backtrace code
(lib/nmi_backtrace.c) uses the same approach and that use also
confirms that updating the mask is safe from NMI.

All of the above lets us combine the logic for "stop" and "crash stop"
code, which appeared to have a bunch of arbitrary implementation
differences. Possibly this could make up for some of the 512 wasted
bytes. ;-)

Aside from the above change where we try a normal IPI and then an NMI,
the combined function has a few subtle differences:
* In the normal smp_send_stop(), if we fail to stop one or more CPUs
  then we won't include the current CPU (the one running
  smp_send_stop()) in the error message.
* In crash_smp_send_stop(), if we fail to stop some CPUs we'll print
  the CPUs that we failed to stop instead of printing all _but_ the
  current running CPU.
* In crash_smp_send_stop(), we will now only print "SMP: stopping
  secondary CPUs" if (system_state <= SYSTEM_RUNNING).

Fixes: d7402513c935 ("arm64: smp: IPI_CPU_STOP and IPI_CPU_CRASH_STOP should try for NMI")
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
I'm not setup to test the crash_smp_send_stop(). I made sure it
compiled and hacked the panic() method to call it, but I haven't
actually run kexec. Hopefully others can confirm that it's working for
them.

 arch/arm64/kernel/smp.c | 115 +++++++++++++++++++---------------------
 1 file changed, 54 insertions(+), 61 deletions(-)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index defbab84e9e5..9fe9d4342517 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -71,7 +71,7 @@ enum ipi_msg_type {
 	IPI_RESCHEDULE,
 	IPI_CALL_FUNC,
 	IPI_CPU_STOP,
-	IPI_CPU_CRASH_STOP,
+	IPI_CPU_STOP_NMI,
 	IPI_TIMER,
 	IPI_IRQ_WORK,
 	NR_IPI,
@@ -88,6 +88,9 @@ static int ipi_irq_base __ro_after_init;
 static int nr_ipi __ro_after_init = NR_IPI;
 static struct irq_desc *ipi_desc[MAX_IPI] __ro_after_init;
 
+static DECLARE_BITMAP(stop_mask, NR_CPUS) __read_mostly;
+static bool crash_stop;
+
 static void ipi_setup(int cpu);
 
 #ifdef CONFIG_HOTPLUG_CPU
@@ -770,7 +773,7 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
 	[IPI_RESCHEDULE]	= "Rescheduling interrupts",
 	[IPI_CALL_FUNC]		= "Function call interrupts",
 	[IPI_CPU_STOP]		= "CPU stop interrupts",
-	[IPI_CPU_CRASH_STOP]	= "CPU stop (for crash dump) interrupts",
+	[IPI_CPU_STOP_NMI]	= "CPU stop NMIs",
 	[IPI_TIMER]		= "Timer broadcast interrupts",
 	[IPI_IRQ_WORK]		= "IRQ work interrupts",
 };
@@ -831,17 +834,11 @@ void __noreturn panic_smp_self_stop(void)
 	local_cpu_stop();
 }
 
-#ifdef CONFIG_KEXEC_CORE
-static atomic_t waiting_for_crash_ipi = ATOMIC_INIT(0);
-#endif
-
 static void __noreturn ipi_cpu_crash_stop(unsigned int cpu, struct pt_regs *regs)
 {
 #ifdef CONFIG_KEXEC_CORE
 	crash_save_cpu(regs, cpu);
 
-	atomic_dec(&waiting_for_crash_ipi);
-
 	local_irq_disable();
 	sdei_mask_local_cpu();
 
@@ -907,14 +904,13 @@ static void do_handle_IPI(int ipinr)
 		break;
 
 	case IPI_CPU_STOP:
-		local_cpu_stop();
-		break;
-
-	case IPI_CPU_CRASH_STOP:
-		if (IS_ENABLED(CONFIG_KEXEC_CORE)) {
+	case IPI_CPU_STOP_NMI:
+		cpumask_clear_cpu(cpu, to_cpumask(stop_mask));
+		if (IS_ENABLED(CONFIG_KEXEC_CORE) && crash_stop) {
 			ipi_cpu_crash_stop(cpu, get_irq_regs());
-
 			unreachable();
+		} else {
+			local_cpu_stop();
 		}
 		break;
 
@@ -969,8 +965,7 @@ static bool ipi_should_be_nmi(enum ipi_msg_type ipi)
 		return false;
 
 	switch (ipi) {
-	case IPI_CPU_STOP:
-	case IPI_CPU_CRASH_STOP:
+	case IPI_CPU_STOP_NMI:
 	case IPI_CPU_BACKTRACE:
 	case IPI_KGDB_ROUNDUP:
 		return true;
@@ -1085,77 +1080,75 @@ void smp_send_stop(void)
 {
 	unsigned long timeout;
 
-	if (num_other_online_cpus()) {
-		cpumask_t mask;
+	/*
+	 * If this cpu is the only one alive at this point in time, online or
+	 * not, there are no stop messages to be sent around, so just back out.
+	 */
+	if (num_other_online_cpus() == 0)
+		goto skip_ipi;
 
-		cpumask_copy(&mask, cpu_online_mask);
-		cpumask_clear_cpu(smp_processor_id(), &mask);
+	cpumask_copy(to_cpumask(stop_mask), cpu_online_mask);
+	cpumask_clear_cpu(smp_processor_id(), to_cpumask(stop_mask));
 
-		if (system_state <= SYSTEM_RUNNING)
-			pr_crit("SMP: stopping secondary CPUs\n");
-		smp_cross_call(&mask, IPI_CPU_STOP);
-	}
+	if (system_state <= SYSTEM_RUNNING)
+		pr_crit("SMP: stopping secondary CPUs\n");
 
-	/* Wait up to one second for other CPUs to stop */
+	/*
+	 * Start with a normal IPI and wait up to one second for other CPUs to
+	 * stop. We do this first because it gives other processors a chance
+	 * to exit critical sections / drop locks and makes the rest of the
+	 * stop process (especially console flush) more robust.
+	 */
+	smp_cross_call(to_cpumask(stop_mask), IPI_CPU_STOP);
 	timeout = USEC_PER_SEC;
-	while (num_other_online_cpus() && timeout--)
+	while (!cpumask_empty(to_cpumask(stop_mask)) && timeout--)
 		udelay(1);
 
-	if (num_other_online_cpus())
+	/*
+	 * If CPUs are still online, try an NMI. There's no excuse for this to
+	 * be slow, so we only give them an extra 10 ms to respond.
+	 */
+	if (!cpumask_empty(to_cpumask(stop_mask)) &&
+	    ipi_should_be_nmi(IPI_CPU_STOP_NMI)) {
+		pr_info("SMP: retry stop with NMI for CPUs %*pbl\n",
+			cpumask_pr_args(to_cpumask(stop_mask)));
+
+		smp_cross_call(to_cpumask(stop_mask), IPI_CPU_STOP_NMI);
+		timeout = USEC_PER_MSEC * 10;
+		while (!cpumask_empty(to_cpumask(stop_mask)) && timeout--)
+			udelay(1);
+	}
+
+	if (!cpumask_empty(to_cpumask(stop_mask)))
 		pr_warn("SMP: failed to stop secondary CPUs %*pbl\n",
-			cpumask_pr_args(cpu_online_mask));
+			cpumask_pr_args(to_cpumask(stop_mask)));
 
+skip_ipi:
 	sdei_mask_local_cpu();
 }
 
 #ifdef CONFIG_KEXEC_CORE
 void crash_smp_send_stop(void)
 {
-	static int cpus_stopped;
-	cpumask_t mask;
-	unsigned long timeout;
-
 	/*
 	 * This function can be called twice in panic path, but obviously
 	 * we execute this only once.
+	 *
+	 * We use this same boolean to tell whether the IPI we send was a
+	 * stop or a "crash stop".
 	 */
-	if (cpus_stopped)
+	if (crash_stop)
 		return;
+	crash_stop = 1;
 
-	cpus_stopped = 1;
-
-	/*
-	 * If this cpu is the only one alive at this point in time, online or
-	 * not, there are no stop messages to be sent around, so just back out.
-	 */
-	if (num_other_online_cpus() == 0)
-		goto skip_ipi;
-
-	cpumask_copy(&mask, cpu_online_mask);
-	cpumask_clear_cpu(smp_processor_id(), &mask);
-
-	atomic_set(&waiting_for_crash_ipi, num_other_online_cpus());
+	smp_send_stop();
 
-	pr_crit("SMP: stopping secondary CPUs\n");
-	smp_cross_call(&mask, IPI_CPU_CRASH_STOP);
-
-	/* Wait up to one second for other CPUs to stop */
-	timeout = USEC_PER_SEC;
-	while ((atomic_read(&waiting_for_crash_ipi) > 0) && timeout--)
-		udelay(1);
-
-	if (atomic_read(&waiting_for_crash_ipi) > 0)
-		pr_warn("SMP: failed to stop secondary CPUs %*pbl\n",
-			cpumask_pr_args(&mask));
-
-skip_ipi:
-	sdei_mask_local_cpu();
 	sdei_handler_abort();
 }
 
 bool smp_crash_stop_failed(void)
 {
-	return (atomic_read(&waiting_for_crash_ipi) > 0);
+	return !cpumask_empty(to_cpumask(stop_mask));
 }
 #endif
 
-- 
2.43.0.472.g3155946c3a-goog



From apopple at nvidia.com  Thu Dec  7 17:30:40 2023
From: apopple at nvidia.com (Alistair Popple)
Date: Fri, 08 Dec 2023 12:30:40 +1100
Subject: [PATCH v3 02/15] mm: Batch-clear PTE ranges during zap_pte_range()
In-Reply-To: <20231204105440.61448-3-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-3-ryan.roberts@arm.com>
Message-ID: <87h6kta3ap.fsf@nvdebian.thelocal>


Ryan Roberts <ryan.roberts at arm.com> writes:

> Convert zap_pte_range() to clear a set of ptes in a batch. A given batch
> maps a physically contiguous block of memory, all belonging to the same
> folio. This will likely improve performance by a tiny amount due to
> removing duplicate calls to mark the folio dirty and accessed. And also
> provides us with a future opportunity to batch the rmap removal.
>
> However, the primary motivation for this change is to reduce the number
> of tlb maintenance operations that the arm64 backend has to perform
> during exit and other syscalls that cause zap_pte_range() (e.g. munmap,
> madvise(DONTNEED), etc.), as it is about to add transparent support for
> the "contiguous bit" in its ptes. By clearing ptes using the new
> clear_ptes() API, the backend doesn't have to perform an expensive
> unfold operation when a PTE being cleared is part of a contpte block.
> Instead it can just clear the whole block immediately.
>
> This change addresses the core-mm refactoring only, and introduces
> clear_ptes() with a default implementation that calls
> ptep_get_and_clear_full() for each pte in the range. Note that this API
> returns the pte at the beginning of the batch, but with the dirty and
> young bits set if ANY of the ptes in the cleared batch had those bits
> set; this information is applied to the folio by the core-mm. Given the
> batch is garranteed to cover only a single folio, collapsing this state

Nit: s/garranteed/guaranteed/

> does not lose any useful information.
>
> A separate change will implement clear_ptes() in the arm64 backend to
> realize the performance improvement as part of the work to enable
> contpte mappings.
>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>  include/asm-generic/tlb.h |  9 ++++++
>  include/linux/pgtable.h   | 26 ++++++++++++++++
>  mm/memory.c               | 63 ++++++++++++++++++++++++++-------------
>  mm/mmu_gather.c           | 14 +++++++++
>  4 files changed, 92 insertions(+), 20 deletions(-)

<snip>

> diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
> index 4f559f4ddd21..57b4d5f0dfa4 100644
> --- a/mm/mmu_gather.c
> +++ b/mm/mmu_gather.c
> @@ -47,6 +47,20 @@ static bool tlb_next_batch(struct mmu_gather *tlb)
>  	return true;
>  }
>  
> +unsigned int tlb_get_guaranteed_space(struct mmu_gather *tlb)
> +{
> +	struct mmu_gather_batch *batch = tlb->active;
> +	unsigned int nr_next = 0;
> +
> +	/* Allocate next batch so we can guarrantee at least one batch. */
> +	if (tlb_next_batch(tlb)) {
> +		tlb->active = batch;

Rather than calling tlb_next_batch(tlb) and then undoing some of what it
does I think it would be clearer to factor out the allocation part of
tlb_next_batch(tlb) into a separate function (eg. tlb_alloc_batch) that
you can call from both here and tlb_next_batch().

Otherwise I think this overall direction looks better than trying to
play funny games in the arch layer as it's much clearer what's going on
to core-mm code.

 - Alistair

> +		nr_next = batch->next->max;
> +	}
> +
> +	return batch->max - batch->nr + nr_next;
> +}
> +
>  #ifdef CONFIG_SMP
>  static void tlb_flush_rmap_batch(struct mmu_gather_batch *batch, struct vm_area_struct *vma)
>  {



From apopple at nvidia.com  Thu Dec  7 17:37:32 2023
From: apopple at nvidia.com (Alistair Popple)
Date: Fri, 08 Dec 2023 12:37:32 +1100
Subject: [PATCH v3 14/15] arm64/mm: Implement ptep_set_wrprotects() to
 optimize fork()
In-Reply-To: <20231204105440.61448-15-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-15-ryan.roberts@arm.com>
Message-ID: <87cyvha2xd.fsf@nvdebian.thelocal>


Ryan Roberts <ryan.roberts at arm.com> writes:

> With the core-mm changes in place to batch-copy ptes during fork, we can
> take advantage of this in arm64 to greatly reduce the number of tlbis we
> have to issue, and recover the lost fork performance incured when adding
> support for transparent contiguous ptes.
>
> If we are write-protecting a whole contig range, we can apply the
> write-protection to the whole range and know that it won't change
> whether the range should have the contiguous bit set or not. For ranges
> smaller than the contig range, we will still have to unfold, apply the
> write-protection, then fold if the change now means the range is
> foldable.
>
> This optimization is possible thanks to the tightening of the Arm ARM in
> respect to the definition and behaviour when 'Misprogramming the
> Contiguous bit'. See section D21194 at
> https://developer.arm.com/documentation/102105/latest/
>
> Performance tested with the following test written for the will-it-scale
> framework:
>
> -------
>
> char *testcase_description = "fork and exit";
>
> void testcase(unsigned long long *iterations, unsigned long nr)
> {
> 	int pid;
> 	char *mem;
>
> 	mem = malloc(SZ_128M);
> 	assert(mem);
> 	memset(mem, 1, SZ_128M);
>
> 	while (1) {
> 		pid = fork();
> 		assert(pid >= 0);
>
> 		if (!pid)
> 			exit(0);
>
> 		waitpid(pid, NULL, 0);
>
> 		(*iterations)++;
> 	}
> }
>
> -------
>
> I see huge performance regression when PTE_CONT support was added, then
> the regression is mostly fixed with the addition of this change. The
> following shows regression relative to before PTE_CONT was enabled
> (bigger negative value is bigger regression):
>
> |   cpus |   before opt |   after opt |
> |-------:|-------------:|------------:|
> |      1 |       -10.4% |       -5.2% |
> |      8 |       -15.4% |       -3.5% |
> |     16 |       -38.7% |       -3.7% |
> |     24 |       -57.0% |       -4.4% |
> |     32 |       -65.8% |       -5.4% |
>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>  arch/arm64/include/asm/pgtable.h | 30 ++++++++++++++++++++---
>  arch/arm64/mm/contpte.c          | 42 ++++++++++++++++++++++++++++++++
>  2 files changed, 69 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 15bc9cf1eef4..9bd2f57a9e11 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -984,6 +984,16 @@ static inline void __ptep_set_wrprotect(struct mm_struct *mm,
>  	} while (pte_val(pte) != pte_val(old_pte));
>  }
>  
> +static inline void __ptep_set_wrprotects(struct mm_struct *mm,
> +					unsigned long address, pte_t *ptep,
> +					unsigned int nr)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
> +		__ptep_set_wrprotect(mm, address, ptep);
> +}
> +
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  #define __HAVE_ARCH_PMDP_SET_WRPROTECT
>  static inline void pmdp_set_wrprotect(struct mm_struct *mm,
> @@ -1139,6 +1149,8 @@ extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>  				unsigned long addr, pte_t *ptep);
>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>  				unsigned long addr, pte_t *ptep);
> +extern void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
> +				pte_t *ptep, unsigned int nr);
>  extern int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
>  				unsigned long addr, pte_t *ptep,
>  				pte_t entry, int dirty);
> @@ -1290,13 +1302,25 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
>  	return contpte_ptep_clear_flush_young(vma, addr, ptep);
>  }
>  
> +#define ptep_set_wrprotects ptep_set_wrprotects
> +static inline void ptep_set_wrprotects(struct mm_struct *mm, unsigned long addr,
> +				pte_t *ptep, unsigned int nr)
> +{
> +	if (!contpte_is_enabled(mm))
> +		__ptep_set_wrprotects(mm, addr, ptep, nr);
> +	else if (nr == 1) {

Why do we need the special case here? Couldn't we just call
contpte_set_wrprotects() with nr == 1?

> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
> +		__ptep_set_wrprotects(mm, addr, ptep, 1);
> +		contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
> +	} else
> +		contpte_set_wrprotects(mm, addr, ptep, nr);
> +}
> +
>  #define __HAVE_ARCH_PTEP_SET_WRPROTECT
>  static inline void ptep_set_wrprotect(struct mm_struct *mm,
>  				unsigned long addr, pte_t *ptep)
>  {
> -	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
> -	__ptep_set_wrprotect(mm, addr, ptep);
> -	contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
> +	ptep_set_wrprotects(mm, addr, ptep, 1);
>  }
>  
>  #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
> index e079ec61d7d1..2a57df16bf58 100644
> --- a/arch/arm64/mm/contpte.c
> +++ b/arch/arm64/mm/contpte.c
> @@ -303,6 +303,48 @@ int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>  }
>  EXPORT_SYMBOL(contpte_ptep_clear_flush_young);
>  
> +void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
> +					pte_t *ptep, unsigned int nr)
> +{
> +	unsigned long next;
> +	unsigned long end = addr + (nr << PAGE_SHIFT);
> +
> +	do {
> +		next = pte_cont_addr_end(addr, end);
> +		nr = (next - addr) >> PAGE_SHIFT;
> +
> +		/*
> +		 * If wrprotecting an entire contig range, we can avoid
> +		 * unfolding. Just set wrprotect and wait for the later
> +		 * mmu_gather flush to invalidate the tlb. Until the flush, the
> +		 * page may or may not be wrprotected. After the flush, it is
> +		 * guarranteed wrprotected. If its a partial range though, we
> +		 * must unfold, because we can't have a case where CONT_PTE is
> +		 * set but wrprotect applies to a subset of the PTEs; this would
> +		 * cause it to continue to be unpredictable after the flush.
> +		 */
> +		if (nr != CONT_PTES)
> +			contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
> +
> +		__ptep_set_wrprotects(mm, addr, ptep, nr);
> +
> +		addr = next;
> +		ptep += nr;
> +
> +		/*
> +		 * If applying to a partial contig range, the change could have
> +		 * made the range foldable. Use the last pte in the range we
> +		 * just set for comparison, since contpte_try_fold() only
> +		 * triggers when acting on the last pte in the contig range.
> +		 */
> +		if (nr != CONT_PTES)
> +			contpte_try_fold(mm, addr - PAGE_SIZE, ptep - 1,
> +					 __ptep_get(ptep - 1));
> +
> +	} while (addr != end);
> +}
> +EXPORT_SYMBOL(contpte_set_wrprotects);
> +
>  int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
>  					unsigned long addr, pte_t *ptep,
>  					pte_t entry, int dirty)



From apopple at nvidia.com  Thu Dec  7 17:45:27 2023
From: apopple at nvidia.com (Alistair Popple)
Date: Fri, 08 Dec 2023 12:45:27 +1100
Subject: [PATCH v3 15/15] arm64/mm: Implement clear_ptes() to optimize
 exit()
In-Reply-To: <20231204105440.61448-16-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-16-ryan.roberts@arm.com>
Message-ID: <878r65a2m2.fsf@nvdebian.thelocal>


Ryan Roberts <ryan.roberts at arm.com> writes:

> With the core-mm changes in place to batch-clear ptes during
> zap_pte_range(), we can take advantage of this in arm64 to greatly
> reduce the number of tlbis we have to issue, and recover the lost exit
> performance incured when adding support for transparent contiguous ptes.
>
> If we are clearing a whole contpte range, we can elide first unfolding
> that range and save the tlbis. We just clear the whole range.
>
> The following shows the results of running a kernel compilation workload
> and measuring the cost of arm64_sys_exit_group() (which at ~1.5% is a
> very small part of the overall workload).
>
> Benchmarks were run on Ampere Altra in 2 configs; single numa node and 2
> numa nodes (tlbis are more expensive in 2 node config).
>
>  - baseline: v6.7-rc1 + anonfolio-v7
>  - no-opt: contpte series without any attempt to optimize exit()
>  - simple-ptep_get_clear_full: simple optimization to exploit full=1.
>    ptep_get_clear_full() does not fully conform to its intended semantic
>  - robust-ptep_get_clear_full: similar to previous but
>    ptep_get_clear_full() fully conforms to its intended semantic
>  - clear_ptes: optimization implemented by this patch
>
> | config                     | numa=1 | numa=2 |
> |----------------------------|--------|--------|
> | baseline                   |     0% |     0% |
> | no-opt                     |   190% |   768% |
> | simple-ptep_get_clear_full |     8% |    29% |
> | robust-ptep_get_clear_full |    21% |    19% |
> | clear_ptes                 |    13% |     9% |
>
> In all cases, the cost of arm64_sys_exit_group() increases; this is
> anticipated because there is more work to do to tear down the page
> tables. But clear_ptes() gives the smallest increase overall.
>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>  arch/arm64/include/asm/pgtable.h | 32 ++++++++++++++++++++++++
>  arch/arm64/mm/contpte.c          | 42 ++++++++++++++++++++++++++++++++
>  2 files changed, 74 insertions(+)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 9bd2f57a9e11..ff6b3cc9e819 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -1145,6 +1145,8 @@ extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
>  extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
>  extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>  				pte_t *ptep, pte_t pte, unsigned int nr);
> +extern pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr,
> +				pte_t *ptep, unsigned int nr);
>  extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>  				unsigned long addr, pte_t *ptep);
>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
> @@ -1270,6 +1272,36 @@ static inline void pte_clear(struct mm_struct *mm,
>  	__pte_clear(mm, addr, ptep);
>  }
>  
> +#define clear_ptes clear_ptes
> +static inline pte_t clear_ptes(struct mm_struct *mm,
> +				unsigned long addr, pte_t *ptep, int full,
> +				unsigned int nr)
> +{
> +	pte_t pte;
> +
> +	if (!contpte_is_enabled(mm)) {

I think it would be better to call the generic definition of
clear_ptes() here. Obviously that won't exist if clear_ptes is defined
here, but you could alcall it __clear_ptes() and #define clear_ptes
__clear_ptes when the arch specific helper isn't defined.

> +		unsigned int i;
> +		pte_t tail;
> +
> +		pte = __ptep_get_and_clear(mm, addr, ptep);
> +		for (i = 1; i < nr; i++) {
> +			addr += PAGE_SIZE;
> +			ptep++;
> +			tail = __ptep_get_and_clear(mm, addr, ptep);
> +			if (pte_dirty(tail))
> +				pte = pte_mkdirty(pte);
> +			if (pte_young(tail))
> +				pte = pte_mkyoung(pte);
> +		}
> +	} else if (nr == 1) {
> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
> +		pte = __ptep_get_and_clear(mm, addr, ptep);
> +	} else
> +		pte = contpte_clear_ptes(mm, addr, ptep, nr);
> +
> +	return pte;
> +}
> +
>  #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
>  static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
>  				unsigned long addr, pte_t *ptep)
> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
> index 2a57df16bf58..34b43bde3fcd 100644
> --- a/arch/arm64/mm/contpte.c
> +++ b/arch/arm64/mm/contpte.c
> @@ -257,6 +257,48 @@ void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>  }
>  EXPORT_SYMBOL(contpte_set_ptes);
>  
> +pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
> +					unsigned int nr)
> +{
> +	/*
> +	 * If we cover a partial contpte block at the beginning or end of the
> +	 * batch, unfold if currently folded. This makes it safe to clear some
> +	 * of the entries while keeping others. contpte blocks in the middle of
> +	 * the range, which are fully covered don't need to be unfolded because
> +	 * we will clear the full block.
> +	 */
> +
> +	unsigned int i;
> +	pte_t pte;
> +	pte_t tail;
> +
> +	if (ptep != contpte_align_down(ptep) || nr < CONT_PTES)
> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
> +
> +	if (ptep + nr != contpte_align_down(ptep + nr))
> +		contpte_try_unfold(mm, addr + PAGE_SIZE * (nr - 1),
> +				   ptep + nr - 1,
> +				   __ptep_get(ptep + nr - 1));
> +
> +	pte = __ptep_get_and_clear(mm, addr, ptep);
> +
> +	for (i = 1; i < nr; i++) {
> +		addr += PAGE_SIZE;
> +		ptep++;
> +
> +		tail = __ptep_get_and_clear(mm, addr, ptep);
> +
> +		if (pte_dirty(tail))
> +			pte = pte_mkdirty(pte);
> +
> +		if (pte_young(tail))
> +			pte = pte_mkyoung(pte);
> +	}
> +
> +	return pte;
> +}
> +EXPORT_SYMBOL(contpte_clear_ptes);
> +
>  int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>  					unsigned long addr, pte_t *ptep)
>  {



From alice.yuan at nxp.com  Thu Dec  7 18:19:40 2023
From: alice.yuan at nxp.com (Alice Yuan)
Date: Fri,  8 Dec 2023 10:19:40 +0800
Subject: [PATCH linux-next/master 1/1] media: staging/imx7: Add handler the abnormal interrupt BIT_STATFF_INT
Message-ID: <20231208021940.883259-1-alice.yuan@nxp.com>

From: "alice.yuan" <alice.yuan at nxp.com>

When do 2592x1944 resolution capture, we found some times the
"BIT_STATFF_INT" is abnormal, the stat fifo is not full, but
still the DMA transfer done interrupts generate, at this time
we will get broken frames.

>From the reference manual of imx8mm, we know the STATFIFO full
interrupt status, that indicates the number of data in the
STATFIFO reaches the trigger level. It defined clearly about
BIT_STATFF_INT, 0: STATFIFO is not full, 1: STATFIFO is full.

So we should handler the abnormal interrupts when BIT_STATFF_INT
is 0, the stat fifo is not full, we need to drop the broken
frames, and recovery from the abnormal status.

Signed-off-by: alice.yuan <alice.yuan at nxp.com>
---
 drivers/media/platform/nxp/imx7-media-csi.c | 25 ++++++++++++++++-----
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/nxp/imx7-media-csi.c b/drivers/media/platform/nxp/imx7-media-csi.c
index 15049c6aab37..9012b155c2d7 100644
--- a/drivers/media/platform/nxp/imx7-media-csi.c
+++ b/drivers/media/platform/nxp/imx7-media-csi.c
@@ -249,6 +249,7 @@ struct imx7_csi {
 	bool is_streaming;
 	int buf_num;
 	u32 frame_sequence;
+	int frame_skip;
 
 	bool last_eof;
 	struct completion last_eof_completion;
@@ -686,6 +687,7 @@ static void imx7_csi_enable(struct imx7_csi *csi)
 	imx7_csi_dmareq_rff_enable(csi);
 	imx7_csi_hw_enable(csi);
 
+	csi->frame_skip = 0;
 	if (csi->model == IMX7_CSI_IMX8MQ)
 		imx7_csi_baseaddr_switch_on_second_frame(csi);
 }
@@ -764,6 +766,12 @@ static irqreturn_t imx7_csi_irq_handler(int irq, void *data)
 		imx7_csi_error_recovery(csi);
 	}
 
+	if (!(status & BIT_STATFF_INT)) {
+		dev_warn(csi->dev, "Stat fifo is not full\n");
+		imx7_csi_error_recovery(csi);
+		csi->frame_skip++;
+	}
+
 	if (status & BIT_ADDR_CH_ERR_INT) {
 		imx7_csi_hw_disable(csi);
 
@@ -790,14 +798,19 @@ static irqreturn_t imx7_csi_irq_handler(int irq, void *data)
 
 	if ((status & BIT_DMA_TSF_DONE_FB1) ||
 	    (status & BIT_DMA_TSF_DONE_FB2)) {
-		imx7_csi_vb2_buf_done(csi);
-
-		if (csi->last_eof) {
-			complete(&csi->last_eof_completion);
-			csi->last_eof = false;
+		if (csi->frame_skip) {
+			dev_warn(csi->dev, "skip frame: %d\n", csi->frame_skip);
+			csi->frame_skip--;
+			goto out;
+		} else {
+			imx7_csi_vb2_buf_done(csi);
+			if (csi->last_eof) {
+				complete(&csi->last_eof_completion);
+				csi->last_eof = false;
+			}
 		}
 	}
-
+out:
 	spin_unlock(&csi->irqlock);
 
 	return IRQ_HANDLED;
-- 
2.37.1



From zhi.mao at mediatek.com  Thu Dec  7 18:07:36 2023
From: zhi.mao at mediatek.com (=?utf-8?B?WmhpIE1hbyAo5q+b5pm6KQ==?=)
Date: Fri, 8 Dec 2023 02:07:36 +0000
Subject: [PATCH 1/2] media: i2c: Add GC08A3 image sensor driver
In-Reply-To: <20231207-outcome-acclaim-d179c8c07fff@spud>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
	 <20231207052016.25954-2-zhi.mao@mediatek.com>
	 <ZXGtqwjYruBQVaUr@kekkonen.localdomain>
	 <129e3a8b-5e91-424a-8ff8-b015d5175f1a@linaro.org>
	 <20231207-outcome-acclaim-d179c8c07fff@spud>
Message-ID: <0580bc5be77c5e293770f42b661a41c80e1986dd.camel@mediatek.com>

On Thu, 2023-12-07 at 17:44 +0000, Conor Dooley wrote:
> On Thu, Dec 07, 2023 at 01:30:35PM +0100, Krzysztof Kozlowski wrote:
> > On 07/12/2023 12:34, Sakari Ailus wrote:
> > > > +	ret = gc08a3_parse_fwnode(dev);
> > > > +	if (ret)
> > > > +		return ret;
> > > > +
> > > > +	gc08a3 = devm_kzalloc(dev, sizeof(*gc08a3),
> > > > GFP_KERNEL);
> > > > +	if (!gc08a3)
> > > > +		return -ENOMEM;
> > > > +
> > > > +	gc08a3->dev = dev;
> > > > +
> > > > +	gc08a3->xclk = devm_clk_get(dev, NULL);
> > > > +	if (IS_ERR(gc08a3->xclk))
> > > > +		return dev_err_probe(dev, PTR_ERR(gc08a3-
> > > > >xclk),
> > > > +					 "failed to get
> > > > xclk\n");
> > > > +
> > > > +	ret = clk_set_rate(gc08a3->xclk,
> > > > GC08A3_DEFAULT_CLK_FREQ);
> > > 
> > > Please see:
> > > <URL:
> > > https://hverkuil.home.xs4all.nl/spec/driver-api/camera-sensor.html#devicetree>
> > > ;.
> > 
> > 
> > Oh, that's cool it was documented!
> > 
> > The canonical link would be:
> > 
https://www.kernel.org/doc/html/latest/driver-api/media/camera-sensor.html#devicetree
> 
> I believe this is that answer to the "why are these needed" that I
> asked
> on the previous version and never got a response to. Instead, they
> were
> just removed from the binding etc.

About "assigned-clocks" & "assigned-clock-rates" in v1 patch, as they
are not used in sensor driver, I have removed them in sensor dts-
bindind file. And "clock-names" & "clock-frequency" are also the same,
they will be removed in next version.


From xueshuai at linux.alibaba.com  Thu Dec  7 18:56:49 2023
From: xueshuai at linux.alibaba.com (Shuai Xue)
Date: Fri,  8 Dec 2023 10:56:49 +0800
Subject: [PATCH v12 2/5] PCI: Add Alibaba Vendor ID to linux/pci_ids.h
In-Reply-To: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
References: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
Message-ID: <20231208025652.87192-3-xueshuai@linux.alibaba.com>

The Alibaba Vendor ID (0x1ded) is now used by Alibaba elasticRDMA ("erdma")
and will be shared with the upcoming PCIe PMU ("dwc_pcie_pmu"). Move the
Vendor ID to linux/pci_ids.h so that it can shared by several drivers
later.

Signed-off-by: Shuai Xue <xueshuai at linux.alibaba.com>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>	# pci_ids.h
Tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
---
 drivers/infiniband/hw/erdma/erdma_hw.h | 2 --
 include/linux/pci_ids.h                | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/erdma/erdma_hw.h b/drivers/infiniband/hw/erdma/erdma_hw.h
index 9d316fdc6f9a..a155519a862f 100644
--- a/drivers/infiniband/hw/erdma/erdma_hw.h
+++ b/drivers/infiniband/hw/erdma/erdma_hw.h
@@ -11,8 +11,6 @@
 #include <linux/types.h>
 
 /* PCIe device related definition. */
-#define PCI_VENDOR_ID_ALIBABA 0x1ded
-
 #define ERDMA_PCI_WIDTH 64
 #define ERDMA_FUNC_BAR 0
 #define ERDMA_MISX_BAR 2
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 5fb3d4c393a9..d8760daf9e5a 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2601,6 +2601,8 @@
 #define PCI_VENDOR_ID_TEKRAM		0x1de1
 #define PCI_DEVICE_ID_TEKRAM_DC290	0xdc29
 
+#define PCI_VENDOR_ID_ALIBABA		0x1ded
+
 #define PCI_VENDOR_ID_TEHUTI		0x1fc9
 #define PCI_DEVICE_ID_TEHUTI_3009	0x3009
 #define PCI_DEVICE_ID_TEHUTI_3010	0x3010
-- 
2.39.3



From xueshuai at linux.alibaba.com  Thu Dec  7 18:56:48 2023
From: xueshuai at linux.alibaba.com (Shuai Xue)
Date: Fri,  8 Dec 2023 10:56:48 +0800
Subject: [PATCH v12 1/5] docs: perf: Add description for Synopsys DesignWare PCIe PMU driver
In-Reply-To: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
References: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
Message-ID: <20231208025652.87192-2-xueshuai@linux.alibaba.com>

Alibaba's T-Head Yitan 710 SoC includes Synopsys' DesignWare Core PCIe
controller which implements PMU for performance and functional debugging to
facilitate system maintenance.

Document it to provide guidance on how to use it.

Signed-off-by: Shuai Xue <xueshuai at linux.alibaba.com>
Reviewed-by: Baolin Wang <baolin.wang at linux.alibaba.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Reviewed-by: Yicong Yang <yangyicong at hisilicon.com>
Tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
---
 .../admin-guide/perf/dwc_pcie_pmu.rst         | 94 +++++++++++++++++++
 Documentation/admin-guide/perf/index.rst      |  1 +
 2 files changed, 95 insertions(+)
 create mode 100644 Documentation/admin-guide/perf/dwc_pcie_pmu.rst

diff --git a/Documentation/admin-guide/perf/dwc_pcie_pmu.rst b/Documentation/admin-guide/perf/dwc_pcie_pmu.rst
new file mode 100644
index 000000000000..d47cd229d710
--- /dev/null
+++ b/Documentation/admin-guide/perf/dwc_pcie_pmu.rst
@@ -0,0 +1,94 @@
+======================================================================
+Synopsys DesignWare Cores (DWC) PCIe Performance Monitoring Unit (PMU)
+======================================================================
+
+DesignWare Cores (DWC) PCIe PMU
+===============================
+
+The PMU is a PCIe configuration space register block provided by each PCIe Root
+Port in a Vendor-Specific Extended Capability named RAS D.E.S (Debug, Error
+injection, and Statistics).
+
+As the name indicates, the RAS DES capability supports system level
+debugging, AER error injection, and collection of statistics. To facilitate
+collection of statistics, Synopsys DesignWare Cores PCIe controller
+provides the following two features:
+
+- one 64-bit counter for Time Based Analysis (RX/TX data throughput and
+  time spent in each low-power LTSSM state) and
+- one 32-bit counter for Event Counting (error and non-error events for
+  a specified lane)
+
+Note: There is no interrupt for counter overflow.
+
+Time Based Analysis
+-------------------
+
+Using this feature you can obtain information regarding RX/TX data
+throughput and time spent in each low-power LTSSM state by the controller.
+The PMU measures data in two categories:
+
+- Group#0: Percentage of time the controller stays in LTSSM states.
+- Group#1: Amount of data processed (Units of 16 bytes).
+
+Lane Event counters
+-------------------
+
+Using this feature you can obtain Error and Non-Error information in
+specific lane by the controller. The PMU event is selected by all of:
+
+- Group i
+- Event j within the Group i
+- Lane k
+
+Some of the events only exist for specific configurations.
+
+DesignWare Cores (DWC) PCIe PMU Driver
+=======================================
+
+This driver adds PMU devices for each PCIe Root Port named based on the BDF of
+the Root Port. For example,
+
+    30:03.0 PCI bridge: Device 1ded:8000 (rev 01)
+
+the PMU device name for this Root Port is dwc_rootport_3018.
+
+The DWC PCIe PMU driver registers a perf PMU driver, which provides
+description of available events and configuration options in sysfs, see
+/sys/bus/event_source/devices/dwc_rootport_{bdf}.
+
+The "format" directory describes format of the config fields of the
+perf_event_attr structure. The "events" directory provides configuration
+templates for all documented events.  For example,
+"Rx_PCIe_TLP_Data_Payload" is an equivalent of "eventid=0x22,type=0x1".
+
+The "perf list" command shall list the available events from sysfs, e.g.::
+
+    $# perf list | grep dwc_rootport
+    <...>
+    dwc_rootport_3018/Rx_PCIe_TLP_Data_Payload/        [Kernel PMU event]
+    <...>
+    dwc_rootport_3018/rx_memory_read,lane=?/               [Kernel PMU event]
+
+Time Based Analysis Event Usage
+-------------------------------
+
+Example usage of counting PCIe RX TLP data payload (Units of bytes)::
+
+    $# perf stat -a -e dwc_rootport_3018/Rx_PCIe_TLP_Data_Payload/
+
+The average RX/TX bandwidth can be calculated using the following formula:
+
+    PCIe RX Bandwidth = Rx_PCIe_TLP_Data_Payload / Measure_Time_Window
+    PCIe TX Bandwidth = Tx_PCIe_TLP_Data_Payload / Measure_Time_Window
+
+Lane Event Usage
+-------------------------------
+
+Each lane has the same event set and to avoid generating a list of hundreds
+of events, the user need to specify the lane ID explicitly, e.g.::
+
+    $# perf stat -a -e dwc_rootport_3018/rx_memory_read,lane=4/
+
+The driver does not support sampling, therefore "perf record" will not
+work. Per-task (without "-a") perf sessions are not supported.
diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst
index f60be04e4e33..6bc7739fddb5 100644
--- a/Documentation/admin-guide/perf/index.rst
+++ b/Documentation/admin-guide/perf/index.rst
@@ -19,6 +19,7 @@ Performance monitor support
    arm_dsu_pmu
    thunderx2-pmu
    alibaba_pmu
+   dwc_pcie_pmu
    nvidia-pmu
    meson-ddr-pmu
    cxl
-- 
2.39.3



From xueshuai at linux.alibaba.com  Thu Dec  7 18:56:51 2023
From: xueshuai at linux.alibaba.com (Shuai Xue)
Date: Fri,  8 Dec 2023 10:56:51 +0800
Subject: [PATCH v12 4/5] drivers/perf: add DesignWare PCIe PMU driver
In-Reply-To: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
References: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
Message-ID: <20231208025652.87192-5-xueshuai@linux.alibaba.com>

This commit adds the PCIe Performance Monitoring Unit (PMU) driver support
for T-Head Yitian SoC chip. Yitian is based on the Synopsys PCI Express
Core controller IP which provides statistics feature. The PMU is a PCIe
configuration space register block provided by each PCIe Root Port in a
Vendor-Specific Extended Capability named RAS D.E.S (Debug, Error
injection, and Statistics).

To facilitate collection of statistics the controller provides the
following two features for each Root Port:

- one 64-bit counter for Time Based Analysis (RX/TX data throughput and
  time spent in each low-power LTSSM state) and
- one 32-bit counter for Event Counting (error and non-error events for
  a specified lane)

Note: There is no interrupt for counter overflow.

This driver adds PMU devices for each PCIe Root Port. And the PMU device is
named based the BDF of Root Port. For example,

    30:03.0 PCI bridge: Device 1ded:8000 (rev 01)

the PMU device name for this Root Port is dwc_rootport_3018.

Example usage of counting PCIe RX TLP data payload (Units of bytes)::

    $# perf stat -a -e dwc_rootport_3018/Rx_PCIe_TLP_Data_Payload/

average RX bandwidth can be calculated like this:

    PCIe TX Bandwidth = Rx_PCIe_TLP_Data_Payload / Measure_Time_Window

Signed-off-by: Shuai Xue <xueshuai at linux.alibaba.com>
Reviewed-by: Baolin Wang <baolin.wang at linux.alibaba.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Reviewed-by: Yicong Yang <yangyicong at hisilicon.com>
Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
---
 drivers/perf/Kconfig        |   7 +
 drivers/perf/Makefile       |   1 +
 drivers/perf/dwc_pcie_pmu.c | 792 ++++++++++++++++++++++++++++++++++++
 3 files changed, 800 insertions(+)
 create mode 100644 drivers/perf/dwc_pcie_pmu.c

diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 273d67ecf6d2..ec6e0d9194a1 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -217,6 +217,13 @@ config MARVELL_CN10K_DDR_PMU
 	  Enable perf support for Marvell DDR Performance monitoring
 	  event on CN10K platform.
 
+config DWC_PCIE_PMU
+	tristate "Synopsys DesignWare PCIe PMU"
+	depends on PCI
+	help
+	  Enable perf support for Synopsys DesignWare PCIe PMU Performance
+	  monitoring event on platform including the Alibaba Yitian 710.
+
 source "drivers/perf/arm_cspmu/Kconfig"
 
 source "drivers/perf/amlogic/Kconfig"
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 16b3ec4db916..a06338e3401c 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_MARVELL_CN10K_TAD_PMU) += marvell_cn10k_tad_pmu.o
 obj-$(CONFIG_MARVELL_CN10K_DDR_PMU) += marvell_cn10k_ddr_pmu.o
 obj-$(CONFIG_APPLE_M1_CPU_PMU) += apple_m1_cpu_pmu.o
 obj-$(CONFIG_ALIBABA_UNCORE_DRW_PMU) += alibaba_uncore_drw_pmu.o
+obj-$(CONFIG_DWC_PCIE_PMU) += dwc_pcie_pmu.o
 obj-$(CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU) += arm_cspmu/
 obj-$(CONFIG_MESON_DDR_PMU) += amlogic/
 obj-$(CONFIG_CXL_PMU) += cxl_pmu.o
diff --git a/drivers/perf/dwc_pcie_pmu.c b/drivers/perf/dwc_pcie_pmu.c
new file mode 100644
index 000000000000..6ee66c4b44bf
--- /dev/null
+++ b/drivers/perf/dwc_pcie_pmu.c
@@ -0,0 +1,792 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Synopsys DesignWare PCIe PMU driver
+ *
+ * Copyright (C) 2021-2023 Alibaba Inc.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/cpuhotplug.h>
+#include <linux/cpumask.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/perf_event.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/smp.h>
+#include <linux/sysfs.h>
+#include <linux/types.h>
+
+#define DWC_PCIE_VSEC_RAS_DES_ID		0x02
+#define DWC_PCIE_EVENT_CNT_CTL			0x8
+
+/*
+ * Event Counter Data Select includes two parts:
+ * - 27-24: Group number(4-bit: 0..0x7)
+ * - 23-16: Event number(8-bit: 0..0x13) within the Group
+ *
+ * Put them together as in TRM.
+ */
+#define DWC_PCIE_CNT_EVENT_SEL			GENMASK(27, 16)
+#define DWC_PCIE_CNT_LANE_SEL			GENMASK(11, 8)
+#define DWC_PCIE_CNT_STATUS			BIT(7)
+#define DWC_PCIE_CNT_ENABLE			GENMASK(4, 2)
+#define DWC_PCIE_PER_EVENT_OFF			0x1
+#define DWC_PCIE_PER_EVENT_ON			0x3
+#define DWC_PCIE_EVENT_CLEAR			GENMASK(1, 0)
+#define DWC_PCIE_EVENT_PER_CLEAR		0x1
+
+#define DWC_PCIE_EVENT_CNT_DATA			0xC
+
+#define DWC_PCIE_TIME_BASED_ANAL_CTL		0x10
+#define DWC_PCIE_TIME_BASED_REPORT_SEL		GENMASK(31, 24)
+#define DWC_PCIE_TIME_BASED_DURATION_SEL	GENMASK(15, 8)
+#define DWC_PCIE_DURATION_MANUAL_CTL		0x0
+#define DWC_PCIE_DURATION_1MS			0x1
+#define DWC_PCIE_DURATION_10MS			0x2
+#define DWC_PCIE_DURATION_100MS			0x3
+#define DWC_PCIE_DURATION_1S			0x4
+#define DWC_PCIE_DURATION_2S			0x5
+#define DWC_PCIE_DURATION_4S			0x6
+#define DWC_PCIE_DURATION_4US			0xFF
+#define DWC_PCIE_TIME_BASED_TIMER_START		BIT(0)
+#define DWC_PCIE_TIME_BASED_CNT_ENABLE		0x1
+
+#define DWC_PCIE_TIME_BASED_ANAL_DATA_REG_LOW	0x14
+#define DWC_PCIE_TIME_BASED_ANAL_DATA_REG_HIGH	0x18
+
+/* Event attributes */
+#define DWC_PCIE_CONFIG_EVENTID			GENMASK(15, 0)
+#define DWC_PCIE_CONFIG_TYPE			GENMASK(19, 16)
+#define DWC_PCIE_CONFIG_LANE			GENMASK(27, 20)
+
+#define DWC_PCIE_EVENT_ID(event)	FIELD_GET(DWC_PCIE_CONFIG_EVENTID, (event)->attr.config)
+#define DWC_PCIE_EVENT_TYPE(event)	FIELD_GET(DWC_PCIE_CONFIG_TYPE, (event)->attr.config)
+#define DWC_PCIE_EVENT_LANE(event)	FIELD_GET(DWC_PCIE_CONFIG_LANE, (event)->attr.config)
+
+enum dwc_pcie_event_type {
+	DWC_PCIE_TIME_BASE_EVENT,
+	DWC_PCIE_LANE_EVENT,
+	DWC_PCIE_EVENT_TYPE_MAX,
+};
+
+#define DWC_PCIE_LANE_EVENT_MAX_PERIOD		GENMASK_ULL(31, 0)
+#define DWC_PCIE_MAX_PERIOD			GENMASK_ULL(63, 0)
+
+struct dwc_pcie_pmu {
+	struct pmu		pmu;
+	struct pci_dev		*pdev;		/* Root Port device */
+	u16			ras_des_offset;
+	u32			nr_lanes;
+
+	struct list_head	pmu_node;
+	struct hlist_node	cpuhp_node;
+	struct perf_event	*event[DWC_PCIE_EVENT_TYPE_MAX];
+	int			on_cpu;
+};
+
+#define to_dwc_pcie_pmu(p) (container_of(p, struct dwc_pcie_pmu, pmu))
+
+static int dwc_pcie_pmu_hp_state;
+static struct list_head dwc_pcie_dev_info_head =
+				LIST_HEAD_INIT(dwc_pcie_dev_info_head);
+static bool notify;
+
+struct dwc_pcie_dev_info {
+	struct platform_device *plat_dev;
+	struct pci_dev *pdev;
+	struct list_head dev_node;
+};
+
+struct dwc_pcie_vendor_id {
+	int vendor_id;
+};
+
+static const struct dwc_pcie_vendor_id dwc_pcie_vendor_ids[] = {
+	{.vendor_id = PCI_VENDOR_ID_ALIBABA },
+	{} /* terminator */
+};
+
+static ssize_t cpumask_show(struct device *dev,
+					 struct device_attribute *attr,
+					 char *buf)
+{
+	struct dwc_pcie_pmu *pcie_pmu = to_dwc_pcie_pmu(dev_get_drvdata(dev));
+
+	return cpumap_print_to_pagebuf(true, buf, cpumask_of(pcie_pmu->on_cpu));
+}
+static DEVICE_ATTR_RO(cpumask);
+
+static struct attribute *dwc_pcie_pmu_cpumask_attrs[] = {
+	&dev_attr_cpumask.attr,
+	NULL
+};
+
+static struct attribute_group dwc_pcie_cpumask_attr_group = {
+	.attrs = dwc_pcie_pmu_cpumask_attrs,
+};
+
+struct dwc_pcie_format_attr {
+	struct device_attribute attr;
+	u64 field;
+	int config;
+};
+
+PMU_FORMAT_ATTR(eventid, "config:0-15");
+PMU_FORMAT_ATTR(type, "config:16-19");
+PMU_FORMAT_ATTR(lane, "config:20-27");
+
+static struct attribute *dwc_pcie_format_attrs[] = {
+	&format_attr_type.attr,
+	&format_attr_eventid.attr,
+	&format_attr_lane.attr,
+	NULL,
+};
+
+static struct attribute_group dwc_pcie_format_attrs_group = {
+	.name = "format",
+	.attrs = dwc_pcie_format_attrs,
+};
+
+struct dwc_pcie_event_attr {
+	struct device_attribute attr;
+	enum dwc_pcie_event_type type;
+	u16 eventid;
+	u8 lane;
+};
+
+static ssize_t dwc_pcie_event_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct dwc_pcie_event_attr *eattr;
+
+	eattr = container_of(attr, typeof(*eattr), attr);
+
+	if (eattr->type == DWC_PCIE_LANE_EVENT)
+		return sysfs_emit(buf, "eventid=0x%x,type=0x%x,lane=?\n",
+				  eattr->eventid, eattr->type);
+	else if (eattr->type == DWC_PCIE_TIME_BASE_EVENT)
+		return sysfs_emit(buf, "eventid=0x%x,type=0x%x\n",
+				  eattr->eventid, eattr->type);
+
+	return 0;
+}
+
+#define DWC_PCIE_EVENT_ATTR(_name, _type, _eventid, _lane)		\
+	(&((struct dwc_pcie_event_attr[]) {{				\
+		.attr = __ATTR(_name, 0444, dwc_pcie_event_show, NULL),	\
+		.type = _type,						\
+		.eventid = _eventid,					\
+		.lane = _lane,						\
+	}})[0].attr.attr)
+
+#define DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(_name, _eventid)		\
+	DWC_PCIE_EVENT_ATTR(_name, DWC_PCIE_TIME_BASE_EVENT, _eventid, 0)
+#define DWC_PCIE_PMU_LANE_EVENT_ATTR(_name, _eventid)			\
+	DWC_PCIE_EVENT_ATTR(_name, DWC_PCIE_LANE_EVENT, _eventid, 0)
+
+static struct attribute *dwc_pcie_pmu_time_event_attrs[] = {
+	/* Group #0 */
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(one_cycle, 0x00),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(TX_L0S, 0x01),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(RX_L0S, 0x02),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(L0, 0x03),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(L1, 0x04),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(L1_1, 0x05),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(L1_2, 0x06),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(CFG_RCVRY, 0x07),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(TX_RX_L0S, 0x08),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(L1_AUX, 0x09),
+
+	/* Group #1 */
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(Tx_PCIe_TLP_Data_Payload, 0x20),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(Rx_PCIe_TLP_Data_Payload, 0x21),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(Tx_CCIX_TLP_Data_Payload, 0x22),
+	DWC_PCIE_PMU_TIME_BASE_EVENT_ATTR(Rx_CCIX_TLP_Data_Payload, 0x23),
+
+	/*
+	 * Leave it to the user to specify the lane ID to avoid generating
+	 * a list of hundreds of events.
+	 */
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_ack_dllp, 0x600),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_update_fc_dllp, 0x601),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_ack_dllp, 0x602),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_update_fc_dllp, 0x603),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_nulified_tlp, 0x604),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_nulified_tlp, 0x605),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_duplicate_tl, 0x606),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_memory_write, 0x700),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_memory_read, 0x701),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_configuration_write, 0x702),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_configuration_read, 0x703),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_io_write, 0x704),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_io_read, 0x705),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_completion_without_data, 0x706),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_completion_with_data, 0x707),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_message_tlp, 0x708),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_atomic, 0x709),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_tlp_with_prefix, 0x70A),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_memory_write, 0x70B),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_memory_read, 0x70C),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_io_write, 0x70F),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_io_read, 0x710),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_completion_without_data, 0x711),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_completion_with_data, 0x712),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_message_tlp, 0x713),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_atomic, 0x714),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_tlp_with_prefix, 0x715),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(tx_ccix_tlp, 0x716),
+	DWC_PCIE_PMU_LANE_EVENT_ATTR(rx_ccix_tlp, 0x717),
+	NULL
+};
+
+static const struct attribute_group dwc_pcie_event_attrs_group = {
+	.name = "events",
+	.attrs = dwc_pcie_pmu_time_event_attrs,
+};
+
+static const struct attribute_group *dwc_pcie_attr_groups[] = {
+	&dwc_pcie_event_attrs_group,
+	&dwc_pcie_format_attrs_group,
+	&dwc_pcie_cpumask_attr_group,
+	NULL
+};
+
+static void dwc_pcie_pmu_lane_event_enable(struct dwc_pcie_pmu *pcie_pmu,
+					   bool enable)
+{
+	struct pci_dev *pdev = pcie_pmu->pdev;
+	u16 ras_des_offset = pcie_pmu->ras_des_offset;
+
+	if (enable)
+		pci_clear_and_set_config_dword(pdev,
+					ras_des_offset + DWC_PCIE_EVENT_CNT_CTL,
+					DWC_PCIE_CNT_ENABLE, DWC_PCIE_PER_EVENT_ON);
+	else
+		pci_clear_and_set_config_dword(pdev,
+					ras_des_offset + DWC_PCIE_EVENT_CNT_CTL,
+					DWC_PCIE_CNT_ENABLE, DWC_PCIE_PER_EVENT_OFF);
+}
+
+static void dwc_pcie_pmu_time_based_event_enable(struct dwc_pcie_pmu *pcie_pmu,
+					  bool enable)
+{
+	struct pci_dev *pdev = pcie_pmu->pdev;
+	u16 ras_des_offset = pcie_pmu->ras_des_offset;
+
+	pci_clear_and_set_config_dword(pdev,
+				       ras_des_offset + DWC_PCIE_TIME_BASED_ANAL_CTL,
+				       DWC_PCIE_TIME_BASED_TIMER_START, enable);
+}
+
+static u64 dwc_pcie_pmu_read_lane_event_counter(struct perf_event *event)
+{
+	struct dwc_pcie_pmu *pcie_pmu = to_dwc_pcie_pmu(event->pmu);
+	struct pci_dev *pdev = pcie_pmu->pdev;
+	u16 ras_des_offset = pcie_pmu->ras_des_offset;
+	u32 val;
+
+	pci_read_config_dword(pdev, ras_des_offset + DWC_PCIE_EVENT_CNT_DATA, &val);
+
+	return val;
+}
+
+static u64 dwc_pcie_pmu_read_time_based_counter(struct perf_event *event)
+{
+	struct dwc_pcie_pmu *pcie_pmu = to_dwc_pcie_pmu(event->pmu);
+	struct pci_dev *pdev = pcie_pmu->pdev;
+	int event_id = DWC_PCIE_EVENT_ID(event);
+	u16 ras_des_offset = pcie_pmu->ras_des_offset;
+	u32 lo, hi, ss;
+	u64 val;
+
+	/*
+	 * The 64-bit value of the data counter is spread across two
+	 * registers that are not synchronized. In order to read them
+	 * atomically, ensure that the high 32 bits match before and after
+	 * reading the low 32 bits.
+	 */
+	pci_read_config_dword(pdev,
+		ras_des_offset + DWC_PCIE_TIME_BASED_ANAL_DATA_REG_HIGH, &hi);
+	do {
+		/* snapshot the high 32 bits */
+		ss = hi;
+
+		pci_read_config_dword(
+			pdev, ras_des_offset + DWC_PCIE_TIME_BASED_ANAL_DATA_REG_LOW,
+			&lo);
+		pci_read_config_dword(
+			pdev, ras_des_offset + DWC_PCIE_TIME_BASED_ANAL_DATA_REG_HIGH,
+			&hi);
+	} while (hi != ss);
+
+	val = ((u64)hi << 32) | lo;
+	/*
+	 * The Group#1 event measures the amount of data processed in 16-byte
+	 * units. Simplify the end-user interface by multiplying the counter
+	 * at the point of read.
+	 */
+	if (event_id >= 0x20 && event_id <= 0x23)
+		val *= 16;
+
+	return val;
+}
+
+static void dwc_pcie_pmu_event_update(struct perf_event *event)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	enum dwc_pcie_event_type type = DWC_PCIE_EVENT_TYPE(event);
+	u64 delta, prev, now = 0;
+
+	do {
+		prev = local64_read(&hwc->prev_count);
+
+		if (type == DWC_PCIE_LANE_EVENT)
+			now = dwc_pcie_pmu_read_lane_event_counter(event);
+		else if (type == DWC_PCIE_TIME_BASE_EVENT)
+			now = dwc_pcie_pmu_read_time_based_counter(event);
+
+	} while (local64_cmpxchg(&hwc->prev_count, prev, now) != prev);
+
+	delta = (now - prev) & DWC_PCIE_MAX_PERIOD;
+	/* 32-bit counter for Lane Event Counting */
+	if (type == DWC_PCIE_LANE_EVENT)
+		delta &= DWC_PCIE_LANE_EVENT_MAX_PERIOD;
+
+	local64_add(delta, &event->count);
+}
+
+static int dwc_pcie_pmu_event_init(struct perf_event *event)
+{
+	struct dwc_pcie_pmu *pcie_pmu = to_dwc_pcie_pmu(event->pmu);
+	enum dwc_pcie_event_type type = DWC_PCIE_EVENT_TYPE(event);
+	struct perf_event *sibling;
+	u32 lane;
+
+	if (event->attr.type != event->pmu->type)
+		return -ENOENT;
+
+	/* We don't support sampling */
+	if (is_sampling_event(event))
+		return -EINVAL;
+
+	/* We cannot support task bound events */
+	if (event->cpu < 0 || event->attach_state & PERF_ATTACH_TASK)
+		return -EINVAL;
+
+	if (event->group_leader != event &&
+	    !is_software_event(event->group_leader))
+		return -EINVAL;
+
+	for_each_sibling_event(sibling, event->group_leader) {
+		if (sibling->pmu != event->pmu && !is_software_event(sibling))
+			return -EINVAL;
+	}
+
+	if (type < 0 || type >= DWC_PCIE_EVENT_TYPE_MAX)
+		return -EINVAL;
+
+	if (type == DWC_PCIE_LANE_EVENT) {
+		lane = DWC_PCIE_EVENT_LANE(event);
+		if (lane < 0 || lane >= pcie_pmu->nr_lanes)
+			return -EINVAL;
+	}
+
+	event->cpu = pcie_pmu->on_cpu;
+
+	return 0;
+}
+
+static void dwc_pcie_pmu_event_start(struct perf_event *event, int flags)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	struct dwc_pcie_pmu *pcie_pmu = to_dwc_pcie_pmu(event->pmu);
+	enum dwc_pcie_event_type type = DWC_PCIE_EVENT_TYPE(event);
+
+	hwc->state = 0;
+	local64_set(&hwc->prev_count, 0);
+
+	if (type == DWC_PCIE_LANE_EVENT)
+		dwc_pcie_pmu_lane_event_enable(pcie_pmu, true);
+	else if (type == DWC_PCIE_TIME_BASE_EVENT)
+		dwc_pcie_pmu_time_based_event_enable(pcie_pmu, true);
+}
+
+static void dwc_pcie_pmu_event_stop(struct perf_event *event, int flags)
+{
+	struct dwc_pcie_pmu *pcie_pmu = to_dwc_pcie_pmu(event->pmu);
+	enum dwc_pcie_event_type type = DWC_PCIE_EVENT_TYPE(event);
+	struct hw_perf_event *hwc = &event->hw;
+
+	if (event->hw.state & PERF_HES_STOPPED)
+		return;
+
+	if (type == DWC_PCIE_LANE_EVENT)
+		dwc_pcie_pmu_lane_event_enable(pcie_pmu, false);
+	else if (type == DWC_PCIE_TIME_BASE_EVENT)
+		dwc_pcie_pmu_time_based_event_enable(pcie_pmu, false);
+
+	dwc_pcie_pmu_event_update(event);
+	hwc->state |= PERF_HES_STOPPED | PERF_HES_UPTODATE;
+}
+
+static int dwc_pcie_pmu_event_add(struct perf_event *event, int flags)
+{
+	struct dwc_pcie_pmu *pcie_pmu = to_dwc_pcie_pmu(event->pmu);
+	struct pci_dev *pdev = pcie_pmu->pdev;
+	struct hw_perf_event *hwc = &event->hw;
+	enum dwc_pcie_event_type type = DWC_PCIE_EVENT_TYPE(event);
+	int event_id = DWC_PCIE_EVENT_ID(event);
+	int lane = DWC_PCIE_EVENT_LANE(event);
+	u16 ras_des_offset = pcie_pmu->ras_des_offset;
+	u32 ctrl;
+
+	/* one counter for each type and it is in use */
+	if (pcie_pmu->event[type])
+		return -ENOSPC;
+
+	pcie_pmu->event[type] = event;
+	hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
+
+	if (type == DWC_PCIE_LANE_EVENT) {
+		/* EVENT_COUNTER_DATA_REG needs clear manually */
+		ctrl = FIELD_PREP(DWC_PCIE_CNT_EVENT_SEL, event_id) |
+			FIELD_PREP(DWC_PCIE_CNT_LANE_SEL, lane) |
+			FIELD_PREP(DWC_PCIE_CNT_ENABLE, DWC_PCIE_PER_EVENT_OFF) |
+			FIELD_PREP(DWC_PCIE_EVENT_CLEAR, DWC_PCIE_EVENT_PER_CLEAR);
+		pci_write_config_dword(pdev, ras_des_offset + DWC_PCIE_EVENT_CNT_CTL,
+				       ctrl);
+	} else if (type == DWC_PCIE_TIME_BASE_EVENT) {
+		/*
+		 * TIME_BASED_ANAL_DATA_REG is a 64 bit register, we can safely
+		 * use it with any manually controlled duration. And it is
+		 * cleared when next measurement starts.
+		 */
+		ctrl = FIELD_PREP(DWC_PCIE_TIME_BASED_REPORT_SEL, event_id) |
+			FIELD_PREP(DWC_PCIE_TIME_BASED_DURATION_SEL,
+				   DWC_PCIE_DURATION_MANUAL_CTL) |
+			DWC_PCIE_TIME_BASED_CNT_ENABLE;
+		pci_write_config_dword(
+			pdev, ras_des_offset + DWC_PCIE_TIME_BASED_ANAL_CTL, ctrl);
+	}
+
+	if (flags & PERF_EF_START)
+		dwc_pcie_pmu_event_start(event, PERF_EF_RELOAD);
+
+	perf_event_update_userpage(event);
+
+	return 0;
+}
+
+static void dwc_pcie_pmu_event_del(struct perf_event *event, int flags)
+{
+	struct dwc_pcie_pmu *pcie_pmu = to_dwc_pcie_pmu(event->pmu);
+	enum dwc_pcie_event_type type = DWC_PCIE_EVENT_TYPE(event);
+
+	dwc_pcie_pmu_event_stop(event, flags | PERF_EF_UPDATE);
+	perf_event_update_userpage(event);
+	pcie_pmu->event[type] = NULL;
+}
+
+static void dwc_pcie_pmu_remove_cpuhp_instance(void *hotplug_node)
+{
+	cpuhp_state_remove_instance_nocalls(dwc_pcie_pmu_hp_state, hotplug_node);
+}
+
+/*
+ * Find the binded DES capability device info of a PCI device.
+ * @pdev: The PCI device.
+ */
+static struct dwc_pcie_dev_info *dwc_pcie_find_dev_info(struct pci_dev *pdev)
+{
+	struct dwc_pcie_dev_info *dev_info;
+
+	list_for_each_entry(dev_info, &dwc_pcie_dev_info_head, dev_node)
+		if (dev_info->pdev == pdev)
+			return dev_info;
+
+	return NULL;
+}
+
+static void dwc_pcie_unregister_pmu(void *data)
+{
+	struct dwc_pcie_pmu *pcie_pmu = data;
+
+	perf_pmu_unregister(&pcie_pmu->pmu);
+}
+
+static bool dwc_pcie_match_des_cap(struct pci_dev *pdev)
+{
+	const struct dwc_pcie_vendor_id *vid;
+	u16 vsec;
+	u32 val;
+
+	if (!pci_is_pcie(pdev) || !(pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT))
+		return false;
+
+	for (vid = dwc_pcie_vendor_ids; vid->vendor_id; vid++) {
+		vsec = pci_find_vsec_capability(pdev, vid->vendor_id,
+						DWC_PCIE_VSEC_RAS_DES_ID);
+		if (vsec)
+			break;
+	}
+	if (!vsec)
+		return false;
+
+	pci_read_config_dword(pdev, vsec + PCI_VNDR_HEADER, &val);
+	if (PCI_VNDR_HEADER_REV(val) != 0x04)
+		return false;
+
+	pci_dbg(pdev,
+		"Detected PCIe Vendor-Specific Extended Capability RAS DES\n");
+	return true;
+}
+
+static void dwc_pcie_unregister_dev(struct dwc_pcie_dev_info *dev_info)
+{
+	platform_device_unregister(dev_info->plat_dev);
+	list_del(&dev_info->dev_node);
+	kfree(dev_info);
+}
+
+static int dwc_pcie_register_dev(struct pci_dev *pdev)
+{
+	struct platform_device *plat_dev;
+	struct dwc_pcie_dev_info *dev_info;
+	u32 bdf;
+
+	bdf = PCI_DEVID(pdev->bus->number, pdev->devfn);
+	plat_dev = platform_device_register_data(NULL, "dwc_pcie_pmu", bdf,
+						 pdev, sizeof(*pdev));
+
+	if (IS_ERR(plat_dev))
+		return PTR_ERR(plat_dev);
+
+	dev_info = kzalloc(sizeof(*dev_info), GFP_KERNEL);
+	if (!dev_info)
+		return -ENOMEM;
+
+	/* Cache platform device to handle pci device hotplug */
+	dev_info->plat_dev = plat_dev;
+	dev_info->pdev = pdev;
+	list_add(&dev_info->dev_node, &dwc_pcie_dev_info_head);
+
+	return 0;
+}
+
+static int dwc_pcie_pmu_notifier(struct notifier_block *nb,
+				     unsigned long action, void *data)
+{
+	struct device *dev = data;
+	struct pci_dev *pdev = to_pci_dev(dev);
+	struct dwc_pcie_dev_info *dev_info;
+
+	switch (action) {
+	case BUS_NOTIFY_ADD_DEVICE:
+		if (!dwc_pcie_match_des_cap(pdev))
+			return NOTIFY_DONE;
+		if (dwc_pcie_register_dev(pdev))
+			return NOTIFY_BAD;
+		break;
+	case BUS_NOTIFY_DEL_DEVICE:
+		dev_info = dwc_pcie_find_dev_info(pdev);
+		if (!dev_info)
+			return NOTIFY_DONE;
+		dwc_pcie_unregister_dev(dev_info);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block dwc_pcie_pmu_nb = {
+	.notifier_call = dwc_pcie_pmu_notifier,
+};
+
+static int dwc_pcie_pmu_probe(struct platform_device *plat_dev)
+{
+	struct pci_dev *pdev = plat_dev->dev.platform_data;
+	struct dwc_pcie_pmu *pcie_pmu;
+	char *name;
+	u32 bdf, val;
+	u16 vsec;
+	int ret;
+
+	vsec = pci_find_vsec_capability(pdev, pdev->vendor,
+					DWC_PCIE_VSEC_RAS_DES_ID);
+	pci_read_config_dword(pdev, vsec + PCI_VNDR_HEADER, &val);
+	bdf = PCI_DEVID(pdev->bus->number, pdev->devfn);
+	name = devm_kasprintf(&plat_dev->dev, GFP_KERNEL, "dwc_rootport_%x", bdf);
+	if (!name)
+		return -ENOMEM;
+
+	pcie_pmu = devm_kzalloc(&plat_dev->dev, sizeof(*pcie_pmu), GFP_KERNEL);
+	if (!pcie_pmu)
+		return -ENOMEM;
+
+	pcie_pmu->pdev = pdev;
+	pcie_pmu->ras_des_offset = vsec;
+	pcie_pmu->nr_lanes = pcie_get_width_cap(pdev);
+	pcie_pmu->on_cpu = -1;
+	pcie_pmu->pmu = (struct pmu){
+		.name		= name,
+		.parent		= &pdev->dev,
+		.module		= THIS_MODULE,
+		.attr_groups	= dwc_pcie_attr_groups,
+		.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
+		.task_ctx_nr	= perf_invalid_context,
+		.event_init	= dwc_pcie_pmu_event_init,
+		.add		= dwc_pcie_pmu_event_add,
+		.del		= dwc_pcie_pmu_event_del,
+		.start		= dwc_pcie_pmu_event_start,
+		.stop		= dwc_pcie_pmu_event_stop,
+		.read		= dwc_pcie_pmu_event_update,
+	};
+
+	/* Add this instance to the list used by the offline callback */
+	ret = cpuhp_state_add_instance(dwc_pcie_pmu_hp_state,
+				       &pcie_pmu->cpuhp_node);
+	if (ret) {
+		pci_err(pdev, "Error %d registering hotplug @%x\n", ret, bdf);
+		return ret;
+	}
+
+	/* Unwind when platform driver removes */
+	ret = devm_add_action_or_reset(&plat_dev->dev,
+				       dwc_pcie_pmu_remove_cpuhp_instance,
+				       &pcie_pmu->cpuhp_node);
+	if (ret)
+		return ret;
+
+	ret = perf_pmu_register(&pcie_pmu->pmu, name, -1);
+	if (ret) {
+		pci_err(pdev, "Error %d registering PMU @%x\n", ret, bdf);
+		return ret;
+	}
+	ret = devm_add_action_or_reset(&plat_dev->dev, dwc_pcie_unregister_pmu,
+				       pcie_pmu);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int dwc_pcie_pmu_online_cpu(unsigned int cpu, struct hlist_node *cpuhp_node)
+{
+	struct dwc_pcie_pmu *pcie_pmu;
+
+	pcie_pmu = hlist_entry_safe(cpuhp_node, struct dwc_pcie_pmu, cpuhp_node);
+	if (pcie_pmu->on_cpu == -1)
+		pcie_pmu->on_cpu = cpumask_local_spread(
+			0, dev_to_node(&pcie_pmu->pdev->dev));
+
+	return 0;
+}
+
+static int dwc_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *cpuhp_node)
+{
+	struct dwc_pcie_pmu *pcie_pmu;
+	struct pci_dev *pdev;
+	int node;
+	cpumask_t mask;
+	unsigned int target;
+
+	pcie_pmu = hlist_entry_safe(cpuhp_node, struct dwc_pcie_pmu, cpuhp_node);
+	/* Nothing to do if this CPU doesn't own the PMU */
+	if (cpu != pcie_pmu->on_cpu)
+		return 0;
+
+	pcie_pmu->on_cpu = -1;
+	pdev = pcie_pmu->pdev;
+	node = dev_to_node(&pdev->dev);
+	if (cpumask_and(&mask, cpumask_of_node(node), cpu_online_mask) &&
+	    cpumask_andnot(&mask, &mask, cpumask_of(cpu)))
+		target = cpumask_any(&mask);
+	else
+		target = cpumask_any_but(cpu_online_mask, cpu);
+
+	if (target >= nr_cpu_ids) {
+		pci_err(pdev, "There is no CPU to set\n");
+		return 0;
+	}
+
+	/* This PMU does NOT support interrupt, just migrate context. */
+	perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
+	pcie_pmu->on_cpu = target;
+
+	return 0;
+}
+
+static struct platform_driver dwc_pcie_pmu_driver = {
+	.probe = dwc_pcie_pmu_probe,
+	.driver = {.name = "dwc_pcie_pmu",},
+};
+
+static int __init dwc_pcie_pmu_init(void)
+{
+	struct pci_dev *pdev = NULL;
+	bool found = false;
+	int ret;
+
+	for_each_pci_dev(pdev) {
+		if (!dwc_pcie_match_des_cap(pdev))
+			continue;
+
+		ret = dwc_pcie_register_dev(pdev);
+		if (ret) {
+			pci_dev_put(pdev);
+			return ret;
+		}
+
+		found = true;
+	}
+	if (!found)
+		return -ENODEV;
+
+	ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
+				      "perf/dwc_pcie_pmu:online",
+				      dwc_pcie_pmu_online_cpu,
+				      dwc_pcie_pmu_offline_cpu);
+	if (ret < 0)
+		return ret;
+
+	dwc_pcie_pmu_hp_state = ret;
+
+	ret = platform_driver_register(&dwc_pcie_pmu_driver);
+	if (ret)
+		goto platform_driver_register_err;
+
+	ret = bus_register_notifier(&pci_bus_type, &dwc_pcie_pmu_nb);
+	if (ret)
+		goto platform_driver_register_err;
+	notify = true;
+
+	return 0;
+
+platform_driver_register_err:
+	cpuhp_remove_multi_state(dwc_pcie_pmu_hp_state);
+
+	return ret;
+}
+
+static void __exit dwc_pcie_pmu_exit(void)
+{
+	struct dwc_pcie_dev_info *dev_info, *tmp;
+
+	if (notify)
+		bus_unregister_notifier(&pci_bus_type, &dwc_pcie_pmu_nb);
+	list_for_each_entry_safe(dev_info, tmp, &dwc_pcie_dev_info_head, dev_node)
+		dwc_pcie_unregister_dev(dev_info);
+	platform_driver_unregister(&dwc_pcie_pmu_driver);
+	cpuhp_remove_multi_state(dwc_pcie_pmu_hp_state);
+}
+
+module_init(dwc_pcie_pmu_init);
+module_exit(dwc_pcie_pmu_exit);
+
+MODULE_DESCRIPTION("PMU driver for DesignWare Cores PCI Express Controller");
+MODULE_AUTHOR("Shuai Xue <xueshuai at linux.alibaba.com>");
+MODULE_LICENSE("GPL v2");
-- 
2.39.3



From xueshuai at linux.alibaba.com  Thu Dec  7 18:56:52 2023
From: xueshuai at linux.alibaba.com (Shuai Xue)
Date: Fri,  8 Dec 2023 10:56:52 +0800
Subject: [PATCH v12 5/5] MAINTAINERS: add maintainers for DesignWare PCIe PMU driver
In-Reply-To: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
References: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
Message-ID: <20231208025652.87192-6-xueshuai@linux.alibaba.com>

Add maintainers for Synopsys DesignWare PCIe PMU driver and driver
document.

Signed-off-by: Shuai Xue <xueshuai at linux.alibaba.com>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6c4cce45a09d..71f363f836ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20866,6 +20866,13 @@ L:	linux-mmc at vger.kernel.org
 S:	Maintained
 F:	drivers/mmc/host/dw_mmc*
 
+SYNOPSYS DESIGNWARE PCIE PMU DRIVER
+M:	Shuai Xue <xueshuai at linux.alibaba.com>
+M:	Jing Zhang <renyu.zj at linux.alibaba.com>
+S:	Supported
+F:	Documentation/admin-guide/perf/dwc_pcie_pmu.rst
+F:	drivers/perf/dwc_pcie_pmu.c
+
 SYNOPSYS HSDK RESET CONTROLLER DRIVER
 M:	Eugeniy Paltsev <Eugeniy.Paltsev at synopsys.com>
 S:	Supported
-- 
2.39.3



From xueshuai at linux.alibaba.com  Thu Dec  7 18:56:50 2023
From: xueshuai at linux.alibaba.com (Shuai Xue)
Date: Fri,  8 Dec 2023 10:56:50 +0800
Subject: [PATCH v12 3/5] PCI: Move pci_clear_and_set_dword() helper to PCI header
In-Reply-To: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
References: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
Message-ID: <20231208025652.87192-4-xueshuai@linux.alibaba.com>

The clear and set pattern is commonly used for accessing PCI config,
move the helper pci_clear_and_set_dword() from aspm.c into PCI header.
In addition, rename to pci_clear_and_set_config_dword() to retain the
"config" information and match the other accessors.

No functional change intended.

Signed-off-by: Shuai Xue <xueshuai at linux.alibaba.com>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
Tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
---
 drivers/pci/access.c    | 12 ++++++++
 drivers/pci/pcie/aspm.c | 65 +++++++++++++++++++----------------------
 include/linux/pci.h     |  2 ++
 3 files changed, 44 insertions(+), 35 deletions(-)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 6554a2e89d36..6449056b57dd 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -598,3 +598,15 @@ int pci_write_config_dword(const struct pci_dev *dev, int where,
 	return pci_bus_write_config_dword(dev->bus, dev->devfn, where, val);
 }
 EXPORT_SYMBOL(pci_write_config_dword);
+
+void pci_clear_and_set_config_dword(const struct pci_dev *dev, int pos,
+				    u32 clear, u32 set)
+{
+	u32 val;
+
+	pci_read_config_dword(dev, pos, &val);
+	val &= ~clear;
+	val |= set;
+	pci_write_config_dword(dev, pos, val);
+}
+EXPORT_SYMBOL(pci_clear_and_set_config_dword);
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 1bf630059264..9dbc4d3c2591 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -423,17 +423,6 @@ static void pcie_aspm_check_latency(struct pci_dev *endpoint)
 	}
 }
 
-static void pci_clear_and_set_dword(struct pci_dev *pdev, int pos,
-				    u32 clear, u32 set)
-{
-	u32 val;
-
-	pci_read_config_dword(pdev, pos, &val);
-	val &= ~clear;
-	val |= set;
-	pci_write_config_dword(pdev, pos, val);
-}
-
 /* Calculate L1.2 PM substate timing parameters */
 static void aspm_calc_l12_info(struct pcie_link_state *link,
 				u32 parent_l1ss_cap, u32 child_l1ss_cap)
@@ -494,10 +483,12 @@ static void aspm_calc_l12_info(struct pcie_link_state *link,
 	cl1_2_enables = cctl1 & PCI_L1SS_CTL1_L1_2_MASK;
 
 	if (pl1_2_enables || cl1_2_enables) {
-		pci_clear_and_set_dword(child, child->l1ss + PCI_L1SS_CTL1,
-					PCI_L1SS_CTL1_L1_2_MASK, 0);
-		pci_clear_and_set_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
-					PCI_L1SS_CTL1_L1_2_MASK, 0);
+		pci_clear_and_set_config_dword(child,
+					       child->l1ss + PCI_L1SS_CTL1,
+					       PCI_L1SS_CTL1_L1_2_MASK, 0);
+		pci_clear_and_set_config_dword(parent,
+					       parent->l1ss + PCI_L1SS_CTL1,
+					       PCI_L1SS_CTL1_L1_2_MASK, 0);
 	}
 
 	/* Program T_POWER_ON times in both ports */
@@ -505,22 +496,26 @@ static void aspm_calc_l12_info(struct pcie_link_state *link,
 	pci_write_config_dword(child, child->l1ss + PCI_L1SS_CTL2, ctl2);
 
 	/* Program Common_Mode_Restore_Time in upstream device */
-	pci_clear_and_set_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
-				PCI_L1SS_CTL1_CM_RESTORE_TIME, ctl1);
+	pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
+				       PCI_L1SS_CTL1_CM_RESTORE_TIME, ctl1);
 
 	/* Program LTR_L1.2_THRESHOLD time in both ports */
-	pci_clear_and_set_dword(parent,	parent->l1ss + PCI_L1SS_CTL1,
-				PCI_L1SS_CTL1_LTR_L12_TH_VALUE |
-				PCI_L1SS_CTL1_LTR_L12_TH_SCALE, ctl1);
-	pci_clear_and_set_dword(child, child->l1ss + PCI_L1SS_CTL1,
-				PCI_L1SS_CTL1_LTR_L12_TH_VALUE |
-				PCI_L1SS_CTL1_LTR_L12_TH_SCALE, ctl1);
+	pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
+				       PCI_L1SS_CTL1_LTR_L12_TH_VALUE |
+				       PCI_L1SS_CTL1_LTR_L12_TH_SCALE,
+				       ctl1);
+	pci_clear_and_set_config_dword(child, child->l1ss + PCI_L1SS_CTL1,
+				       PCI_L1SS_CTL1_LTR_L12_TH_VALUE |
+				       PCI_L1SS_CTL1_LTR_L12_TH_SCALE,
+				       ctl1);
 
 	if (pl1_2_enables || cl1_2_enables) {
-		pci_clear_and_set_dword(parent, parent->l1ss + PCI_L1SS_CTL1, 0,
-					pl1_2_enables);
-		pci_clear_and_set_dword(child, child->l1ss + PCI_L1SS_CTL1, 0,
-					cl1_2_enables);
+		pci_clear_and_set_config_dword(parent,
+					       parent->l1ss + PCI_L1SS_CTL1, 0,
+					       pl1_2_enables);
+		pci_clear_and_set_config_dword(child,
+					       child->l1ss + PCI_L1SS_CTL1, 0,
+					       cl1_2_enables);
 	}
 }
 
@@ -680,10 +675,10 @@ static void pcie_config_aspm_l1ss(struct pcie_link_state *link, u32 state)
 	 */
 
 	/* Disable all L1 substates */
-	pci_clear_and_set_dword(child, child->l1ss + PCI_L1SS_CTL1,
-				PCI_L1SS_CTL1_L1SS_MASK, 0);
-	pci_clear_and_set_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
-				PCI_L1SS_CTL1_L1SS_MASK, 0);
+	pci_clear_and_set_config_dword(child, child->l1ss + PCI_L1SS_CTL1,
+				       PCI_L1SS_CTL1_L1SS_MASK, 0);
+	pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
+				       PCI_L1SS_CTL1_L1SS_MASK, 0);
 	/*
 	 * If needed, disable L1, and it gets enabled later
 	 * in pcie_config_aspm_link().
@@ -706,10 +701,10 @@ static void pcie_config_aspm_l1ss(struct pcie_link_state *link, u32 state)
 		val |= PCI_L1SS_CTL1_PCIPM_L1_2;
 
 	/* Enable what we need to enable */
-	pci_clear_and_set_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
-				PCI_L1SS_CTL1_L1SS_MASK, val);
-	pci_clear_and_set_dword(child, child->l1ss + PCI_L1SS_CTL1,
-				PCI_L1SS_CTL1_L1SS_MASK, val);
+	pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1,
+				       PCI_L1SS_CTL1_L1SS_MASK, val);
+	pci_clear_and_set_config_dword(child, child->l1ss + PCI_L1SS_CTL1,
+				       PCI_L1SS_CTL1_L1SS_MASK, val);
 }
 
 static void pcie_config_aspm_dev(struct pci_dev *pdev, u32 val)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 8c7c2c3c6c65..72b0fb82a820 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1213,6 +1213,8 @@ int pci_read_config_dword(const struct pci_dev *dev, int where, u32 *val);
 int pci_write_config_byte(const struct pci_dev *dev, int where, u8 val);
 int pci_write_config_word(const struct pci_dev *dev, int where, u16 val);
 int pci_write_config_dword(const struct pci_dev *dev, int where, u32 val);
+void pci_clear_and_set_config_dword(const struct pci_dev *dev, int pos,
+				    u32 clear, u32 set);
 
 int pcie_capability_read_word(struct pci_dev *dev, int pos, u16 *val);
 int pcie_capability_read_dword(struct pci_dev *dev, int pos, u32 *val);
-- 
2.39.3



From xueshuai at linux.alibaba.com  Thu Dec  7 18:56:47 2023
From: xueshuai at linux.alibaba.com (Shuai Xue)
Date: Fri,  8 Dec 2023 10:56:47 +0800
Subject: [PATCH v12 0/5] drivers/perf: add Synopsys DesignWare PCIe PMU driver support
Message-ID: <20231208025652.87192-1-xueshuai@linux.alibaba.com>

Change Log
==========
change sinces v11:
- Fix uninitialized symbol 'now' (Per Dan and Will)
- Pick up Reviewed-and-tested-by tag from Ilkka for Patch 4/5

change sinces v10:
- Rename to pci_clear_and_set_config_dword() to retain the "config"
  information and match the other accessors. (Per Bjorn)
- Align pci_clear_and_set_config_dword() and its call site (Per Bjorn)
- Polish commit log (Per Bjorn)
- Simplify dwc_pcie_pmu_time_based_event_enable() with bool value (Per Ilkka)
- Fix dwc_pcie_register_dev() return value (Per Ilkka)
- Fix vesc capability discovery by pdev->vendor (Per Ilkka)
- pick up Acked-by tag from Bjorn for Patch 3/5
- pick up Tested-by tag from Ilkka for all patch set

changes since v9:
- move the &plat_dev->dev to previous line to warp more beautiful (Per Jonathan)
- rename error label with the same suffix 'err'  (Per Jonathan)
- drop unnecessary else branch and return directly (Per Baolin)
- warp out set prev_count from dwc_pcie_pmu_set_period (Per Baolin)
- use PMU_FORMAT_ATTR to simplify format sysfs stuff (Per Will)
- export pci_clear_and_set_dword() to simplify _enable() functions  (Per Will)
- simplify _read() function by unconditionally calculate with unit in bytes plused if branch for group#1 event (Per Will and Robin)
- simplify _update() function by unconditionally mask with 64-bit width plused if branch for lane event (Per Will)
- add type sanity check in _init() (Per Will)
- test with fuzzing tool before this new version (Per Will)
- register a platform device for each PCI device to probe RAS_DES PMU cap (Per Robin)
- add dwc_pcie_vendor_ids to extend vendor id for future added device (Per Krishna)
- pickup review-by tag from Baolin, Yicong and Jonathan 


changes since v8:
- tidy up doc and pick up Reviewed-by tag in pathc 1/4 (Per Yicong and Jonathan)
- rename ras_des as ras_des_offset and remove coment about it (Per Jonathan)
- keep exact reverse order of what happened in probe when unregister pmu (Per Jonathan)
- remove the hender length check to make the driver more compatible (Per Jonathan)
- move unwind of register pmu forward to fix list_del() on something that was never added (Per Jonathan)
- use devm_add_action_or_reset() to unwind bus_register_notifier() (Per Jonathan)
- use local pdev directly in dwc_pcie_pmu_offline_cpu() and dwc_pcie_pmu_probe() (Per Jonathan)
- use the approach of a gotos to handle errors in dwc_pcie_pmu_init() (Per Jonathan)
- multiply the counter value at point of read by 16 for group#1 events (Per Jonathan)

changes since v7:
- add config help with alibaba name (per Bjorn)
- remove the ARM64 dependency (per Bjorn and Jonathan)
- fix typo and column warp (per Bjorn) 
- move list_del() after perf_pmu_unregister() (per Bjorn) 
- reorder the functions by interests (per Bjorn)
- rewrite commit log about PMU counters, also update doc (per Bjorn)
- extend to support stat time-based analysis and lane event at the same time (per Bjorn and Jonathan)
Link: https://lore.kernel.org/linux-arm-kernel/20231012032856.2640-2-xueshuai at linux.alibaba.com/T/

changes since v6:
- improve editorial things in doc (Per Jonathan)
- change config help to generic text (Per Jonathan)
- remove macro to_dwc_pcie_pmu by moving pmu as the first member to struct dwc_pcie_pmu (Per Yicong)
- add event type check in dwc_pcie_event_show() to keep consistent with other function (Per Jonathan)
- remove intended blank line (Per Yicong)
- protect against lower 32 bits of counter overflow by try again trick (Per Jonathan)
- call pci_dev_put on all the return branch to keep the refcnt balance (Per Jonathan and Yicong)
- use devm_add_action_or_reset() to automatic unwind (Per Jonathan)
- fix picking numa-aware context cpu up when offline and offline cpu (Per Jonathan)
- simplify online cpu by init pcie_pmu->on_cpu as -1 (Per Jonathan)
- add bus_register_notifier() to handle rootport hotplug (Per Yicong)
- pick up Acked-by from Bjorn for patch 2/4 (Per Bjorn)
Link: https://lore.kernel.org/lkml/20230606074938.97724-1-xueshuai at linux.alibaba.com/T/

changes since v5:
- Rewrite the commit log to follow policy in pci_ids.h (Bjorn Helgaas)
- return error code when __dwc_pcie_pmu_probe failed (Baolin Wang)
- call 'cpuhp_remove_multi_state()' when exiting the driver. (Baolin Wang)
- pick up Review-by tag from Baolin for Patch 1 and 3
Link: https://lore.kernel.org/lkml/ZGuSimj1cuQl3W5L at bhelgaas/T/#mba3fa2572dde0deddb40b5b24a31f4df41004bdf

changes since v4:

1. addressing commens from Bjorn Helgaas:
- reorder the includes by alpha
- change all macros with upper-case hex
- change ras_des type into u16
- remove unnecessary outer "()"
- minor format changes

2. Address commensts from Jonathan Cameron:
- rewrite doc and add a example to show how to use lane event

3. fix compile error reported by: kernel test robot
- remove COMPILE_TEST and add depend on PCI in kconfig
- add Reported-by: kernel test robot <lkp at intel.com>

Changes since v3:

1. addressing comments from Robin Murphy:
- add a prepare patch to define pci id in linux/pci_ids.h
- remove unnecessary 64BIT dependency
- fix DWC_PCIE_PER_EVENT_OFF/ON macro
- remove dwc_pcie_pmu struct and move all its fileds into dwc_pcie_rp_info
- remove unnecessary format field show
- use sysfs_emit() instead of all the assorted sprintf() and snprintf() calls.
- remove unnecessary spaces and remove unnecessary cast to follow event show convention
- remove pcie_pmu_event_attr_is_visible
- fix a refcout leak on error branch when walk pci device in for_each_pci_dev
- remove bdf field from dwc_pcie_rp_info and calculate it at runtime
- finish all the checks before allocating rp_info to avoid hanging wasted memory
- remove some unused fields
- warp out control register configuration from sub function to .add()
- make function return type with a proper signature
- fix lane event count enable by clear DWC_PCIE_CNT_ENABLE field first
- pass rp_info directly to the read_*_counter helpers and in start, stop and add callbacks
- move event type validtion into .event_init()
- use is_sampling_event() to be consistent with everything else of pmu drivers
- remove unnecessary dev_err message in .event_init()
- return EINVAL instead EOPNOTSUPP for not a valid event 
- finish all the checks before start modifying the event
- fix sibling event check by comparing event->pmu with sibling->pmu
- probe PMU for each rootport independently
- use .update() as .read() directly
- remove dynamically generating symbolic name of lane event
- redefine static symbolic name of lane event and leave lane filed to user
- add CPU hotplug support

2. addressing comments from Baolin:
- add a mask to avoid possible overflow

Changes since v2 addressing comments from Baolin:
- remove redundant macro definitions
- use dev_err to print error message
- change pmu_is_register to boolean
- use PLATFORM_DEVID_NONE macro
- fix module author format

Changes since v1:

1. address comments from Jonathan:
- drop marco for PMU name and VSEC version
- simplify code with PCI standard marco
- simplify code with FIELD_PREP()/FIELD_GET() to replace shift marco
- name register filed with single _ instead double
- wrap dwc_pcie_pmu_{write}_dword out and drop meaningless snaity check 
- check vendor id while matching vesc with pci_find_vsec_capability()
- remove RP_NUM_MAX and use a list to organize PMU devices for rootports
- replace DWC_PCIE_CREATE_BDF with standard PCI_DEVID
- comments on riping register together

2. address comments from Bjorn:
- rename DWC_PCIE_VSEC_ID to DWC_PCIE_VSEC_RAS_DES_ID
- rename cap_pos to ras_des
- simplify declare of device_attribute with DEVICE_ATTR_RO
- simplify code with PCI standard macro and API like pcie_get_width_cap()
- fix some code style problem and typo
- drop meaningless snaity check of container_of

3. address comments from Yicong:
- use sysfs_emit() to replace sprintf()
- simplify iteration of pci device with for_each_pci_dev
- pick preferred CPUs on a near die and add comments
- unregister PMU drivers only for failed ones
- log on behalf PMU device and give more hint
- fix some code style problem

(Thanks for all comments and they are very valuable to me)

This patchset adds the PCIe Performance Monitoring Unit (PMU) driver support
for T-Head Yitian 710 SoC chip. Yitian 710 is based on the Synopsys PCI Express
Core controller IP which provides statistics feature.

Shuai Xue (5):
  docs: perf: Add description for Synopsys DesignWare PCIe PMU driver
  PCI: Add Alibaba Vendor ID to linux/pci_ids.h
  PCI: Move pci_clear_and_set_dword() helper to PCI header
  drivers/perf: add DesignWare PCIe PMU driver
  MAINTAINERS: add maintainers for DesignWare PCIe PMU driver

 .../admin-guide/perf/dwc_pcie_pmu.rst         |  94 +++
 Documentation/admin-guide/perf/index.rst      |   1 +
 MAINTAINERS                                   |   7 +
 drivers/infiniband/hw/erdma/erdma_hw.h        |   2 -
 drivers/pci/access.c                          |  12 +
 drivers/pci/pcie/aspm.c                       |  65 +-
 drivers/perf/Kconfig                          |   7 +
 drivers/perf/Makefile                         |   1 +
 drivers/perf/dwc_pcie_pmu.c                   | 792 ++++++++++++++++++
 include/linux/pci.h                           |   2 +
 include/linux/pci_ids.h                       |   2 +
 11 files changed, 948 insertions(+), 37 deletions(-)
 create mode 100644 Documentation/admin-guide/perf/dwc_pcie_pmu.rst
 create mode 100644 drivers/perf/dwc_pcie_pmu.c

-- 
2.39.3



From quan at os.amperecomputing.com  Thu Dec  7 19:31:40 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Fri,  8 Dec 2023 10:31:40 +0700
Subject: [PATCH v3 0/2] i2c: aspeed: Late ack Tx done irqs and handle coalesced start with stop conditions
Message-ID: <20231208033142.1673232-1-quan@os.amperecomputing.com>

This series consists of two patches to handle the below issues observed
when testing with slave mode:
  + The coalesced stop condition with the start conditions
  + Early ack'ed of Tx done (ACK and NAK) causing "Unexpected Ack on
  read request".

This series was verified with ast2500 and ast2600.

The prior discussion could be found at:
https://lore.kernel.org/all/20231128075236.2724038-1-quan at os.amperecomputing.com/

v3:
  + Fix the unconditional write when ack the irqs              [Andrew]
  + Handle the coalesced stop condition with the
start conditions                                               [Andrew]
  + Refactor the code to enhance code readability                [Quan]
  + Revised commit message                                       [Quan]

v2:
  + Split these patches to separate series                       [Joel]
  + Added the Fixes lines                                        [Joel]
  + Fixed multiline comment                                      [Joel]
  + Refactor irq clearing code                          [Joel, Guenter]
  + Revised commit message                                 [Joel, Quan]

v1:
  + These patches are first introduced from this disscusstion
https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/

Quan Nguyen (2):
  i2c: aspeed: Handle the coalesced stop conditions with the start
    conditions.
  i2c: aspeed: Acknowledge Tx done with and without ACK irq late

 drivers/i2c/busses/i2c-aspeed.c | 68 +++++++++++++++++++++------------
 1 file changed, 44 insertions(+), 24 deletions(-)

-- 
2.35.1



From quan at os.amperecomputing.com  Thu Dec  7 19:31:41 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Fri,  8 Dec 2023 10:31:41 +0700
Subject: [PATCH v3 1/2] i2c: aspeed: Handle the coalesced stop conditions with the start conditions.
In-Reply-To: <20231208033142.1673232-1-quan@os.amperecomputing.com>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
Message-ID: <20231208033142.1673232-2-quan@os.amperecomputing.com>

Some masters may drive the transfers with low enough latency between
the nak/stop phase of the current command and the start/address phase
of the following command that the interrupts are coalesced by the
time we process them.
Handle the stop conditions before processing SLAVE_MATCH to fix the
complaints that sometimes occur below.

"aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
0x00000086, but was 0x00000084"

Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
---
v3:
  + Change to handle the coalesced stop condition with the start
conditions                                                            [Andrew]
  + Revised commit message                                              [Quan]

v2:
  + Split to separate series                                            [Joel]
  + Added the Fixes line                                                [Joel]
  + Revised commit message                                              [Quan]

v1:
  + First introduced in
https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/
---
 drivers/i2c/busses/i2c-aspeed.c | 47 ++++++++++++++++++++++-----------
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index 28e2a5fc4528..1c2a4f4c4e1b 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -249,18 +249,45 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 	if (!slave)
 		return 0;
 
-	command = readl(bus->base + ASPEED_I2C_CMD_REG);
+	/*
+	 * Handle stop conditions early, prior to SLAVE_MATCH. Some masters may drive
+	 * transfers with low enough latency between the nak/stop phase of the current
+	 * command and the start/address phase of the following command that the
+	 * interrupts are coalesced by the time we process them.
+	 */
+	if (irq_status & ASPEED_I2CD_INTR_NORMAL_STOP) {
+		irq_handled |= ASPEED_I2CD_INTR_NORMAL_STOP;
+		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
+	}
 
-	/* Slave was requested, restart state machine. */
+	if (irq_status & ASPEED_I2CD_INTR_TX_NAK &&
+	    bus->slave_state == ASPEED_I2C_SLAVE_READ_PROCESSED) {
+		irq_handled |= ASPEED_I2CD_INTR_TX_NAK;
+		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
+	}
+
+	/* Propagate any stop conditions to the slave implementation. */
+	if (bus->slave_state == ASPEED_I2C_SLAVE_STOP) {
+		i2c_slave_event(slave, I2C_SLAVE_STOP, &value);
+		bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
+	}
+	/*
+	 * Now that we've dealt with any potentially coalesced stop conditions,
+	 * address any start conditions.
+	 */
 	if (irq_status & ASPEED_I2CD_INTR_SLAVE_MATCH) {
 		irq_handled |= ASPEED_I2CD_INTR_SLAVE_MATCH;
 		bus->slave_state = ASPEED_I2C_SLAVE_START;
 	}
 
-	/* Slave is not currently active, irq was for someone else. */
+	/*
+	 * If the slave has been stopped and not started then slave interrupt
+	 * handling is complete.
+	 */
 	if (bus->slave_state == ASPEED_I2C_SLAVE_INACTIVE)
 		return irq_handled;
 
+	command = readl(bus->base + ASPEED_I2C_CMD_REG);
 	dev_dbg(bus->dev, "slave irq status 0x%08x, cmd 0x%08x\n",
 		irq_status, command);
 
@@ -279,17 +306,6 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 		irq_handled |= ASPEED_I2CD_INTR_RX_DONE;
 	}
 
-	/* Slave was asked to stop. */
-	if (irq_status & ASPEED_I2CD_INTR_NORMAL_STOP) {
-		irq_handled |= ASPEED_I2CD_INTR_NORMAL_STOP;
-		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
-	}
-	if (irq_status & ASPEED_I2CD_INTR_TX_NAK &&
-	    bus->slave_state == ASPEED_I2C_SLAVE_READ_PROCESSED) {
-		irq_handled |= ASPEED_I2CD_INTR_TX_NAK;
-		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
-	}
-
 	switch (bus->slave_state) {
 	case ASPEED_I2C_SLAVE_READ_REQUESTED:
 		if (unlikely(irq_status & ASPEED_I2CD_INTR_TX_ACK))
@@ -324,8 +340,7 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 		i2c_slave_event(slave, I2C_SLAVE_WRITE_RECEIVED, &value);
 		break;
 	case ASPEED_I2C_SLAVE_STOP:
-		i2c_slave_event(slave, I2C_SLAVE_STOP, &value);
-		bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
+		/* Stop event handling is done early. Unreachable. */
 		break;
 	case ASPEED_I2C_SLAVE_START:
 		/* Slave was just started. Waiting for the next event. */;
-- 
2.35.1



From quan at os.amperecomputing.com  Thu Dec  7 19:31:42 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Fri,  8 Dec 2023 10:31:42 +0700
Subject: [PATCH v3 2/2] i2c: aspeed: Acknowledge Tx done with and without ACK irq late
In-Reply-To: <20231208033142.1673232-1-quan@os.amperecomputing.com>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
Message-ID: <20231208033142.1673232-3-quan@os.amperecomputing.com>

Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
interrupt handler") acknowledges most interrupts early before the slave
irq handler is executed, except for the "Receive Done Interrupt status"
which is acknowledged late in the interrupt.
However, it has been observed that the early acknowledgment of "Transmit
Done Interrupt Status" (with ACK or NACK) often causes the interrupt to
be raised in READ REQUEST state, that shows the
"Unexpected ACK on read request." complaint messages.

Assuming that the "Transmit Done" interrupt should only be acknowledged
once it is truly processed, this commit fixes that issue by acknowledging
interrupts for both ACK and NACK cases late in the interrupt handler.

Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
---
v3:
  + Fix the unconditinal write when ack the irqs               [Andrew]
  + Refactor the code to enhance code readability                [Quan]
  + Fix grammar in commit message                                [Quan]

v2:
  + Split to separate series                                     [Joel]
  + Added the Fixes line                                         [Joel]
  + Fixed multiline comment                                      [Joel]
  + Refactor irq clearing code                          [Joel, Guenter]
  + Revised commit message                                       [Joel]
  + Revised commit message                                       [Quan]
  + About a note to remind why the readl() should immediately follow the
writel() to fix the race condition when clearing irq status from commit
c926c87b8e36 ("i2c: aspeed: Avoid i2c interrupt status clear race
condition"), I think it looks straight forward in this patch and decided
not to add that note.                                            [Joel]

v1:
  + First introduced in
https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/
---
 drivers/i2c/busses/i2c-aspeed.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index 1c2a4f4c4e1b..967a26dd4ffa 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -617,13 +617,19 @@ static u32 aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
 {
 	struct aspeed_i2c_bus *bus = dev_id;
-	u32 irq_received, irq_remaining, irq_handled;
+	u32 irq_received, irq_remaining, irq_handled, irq_ack_last;
 
 	spin_lock(&bus->lock);
 	irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
-	/* Ack all interrupts except for Rx done */
-	writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
-	       bus->base + ASPEED_I2C_INTR_STS_REG);
+
+	/*
+	 * Early acking of INTR_RX_DONE and INTR_TX_[ACK|NAK] would indicate HW to
+	 * start receiving or sending new data, and this may cause a race condition
+	 * as the irq handler has not yet handled these irqs but is being acked.
+	 * Let's ack them late at the end of the irq handler when those are truly processed.
+	 */
+	irq_ack_last = ASPEED_I2CD_INTR_RX_DONE | ASPEED_I2CD_INTR_TX_ACK | ASPEED_I2CD_INTR_TX_NAK;
+	writel(irq_received & ~irq_ack_last, bus->base + ASPEED_I2C_INTR_STS_REG);
 	readl(bus->base + ASPEED_I2C_INTR_STS_REG);
 	irq_received &= ASPEED_I2CD_INTR_RECV_MASK;
 	irq_remaining = irq_received;
@@ -667,12 +673,11 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
 			"irq handled != irq. expected 0x%08x, but was 0x%08x\n",
 			irq_received, irq_handled);
 
-	/* Ack Rx done */
-	if (irq_received & ASPEED_I2CD_INTR_RX_DONE) {
-		writel(ASPEED_I2CD_INTR_RX_DONE,
-		       bus->base + ASPEED_I2C_INTR_STS_REG);
+	if (irq_received & irq_ack_last) {
+		writel(irq_received & irq_ack_last, bus->base + ASPEED_I2C_INTR_STS_REG);
 		readl(bus->base + ASPEED_I2C_INTR_STS_REG);
 	}
+
 	spin_unlock(&bus->lock);
 	return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
 }
-- 
2.35.1



From andrew at codeconstruct.com.au  Thu Dec  7 19:56:31 2023
From: andrew at codeconstruct.com.au (Andrew Jeffery)
Date: Fri, 08 Dec 2023 14:26:31 +1030
Subject: [PATCH v3 1/2] i2c: aspeed: Handle the coalesced stop
 conditions with the start conditions.
In-Reply-To: <20231208033142.1673232-2-quan@os.amperecomputing.com>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
	 <20231208033142.1673232-2-quan@os.amperecomputing.com>
Message-ID: <79ce9162faeb113ecb13efeb58d95f8a71e1a060.camel@codeconstruct.com.au>

On Fri, 2023-12-08 at 10:31 +0700, Quan Nguyen wrote:
> Some masters may drive the transfers with low enough latency between
> the nak/stop phase of the current command and the start/address phase
> of the following command that the interrupts are coalesced by the
> time we process them.
> Handle the stop conditions before processing SLAVE_MATCH to fix the
> complaints that sometimes occur below.
> 
> "aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
> 0x00000086, but was 0x00000084"
> 
> Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> ---
> v3:
>   + Change to handle the coalesced stop condition with the start
> conditions                                                            [Andrew]
>   + Revised commit message                                              [Quan]
> 
> v2:
>   + Split to separate series                                            [Joel]
>   + Added the Fixes line                                                [Joel]
>   + Revised commit message                                              [Quan]
> 
> v1:
>   + First introduced in
> https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/
> ---
>  drivers/i2c/busses/i2c-aspeed.c | 47 ++++++++++++++++++++++-----------
>  1 file changed, 31 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index 28e2a5fc4528..1c2a4f4c4e1b 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -249,18 +249,45 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
>  	if (!slave)
>  		return 0;
>  
> -	command = readl(bus->base + ASPEED_I2C_CMD_REG);
> +	/*
> +	 * Handle stop conditions early, prior to SLAVE_MATCH. Some masters may drive
> +	 * transfers with low enough latency between the nak/stop phase of the current
> +	 * command and the start/address phase of the following command that the
> +	 * interrupts are coalesced by the time we process them.
> +	 */
> +	if (irq_status & ASPEED_I2CD_INTR_NORMAL_STOP) {
> +		irq_handled |= ASPEED_I2CD_INTR_NORMAL_STOP;
> +		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
> +	}
>  
> -	/* Slave was requested, restart state machine. */
> +	if (irq_status & ASPEED_I2CD_INTR_TX_NAK &&
> +	    bus->slave_state == ASPEED_I2C_SLAVE_READ_PROCESSED) {
> +		irq_handled |= ASPEED_I2CD_INTR_TX_NAK;
> +		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
> +	}
> +
> +	/* Propagate any stop conditions to the slave implementation. */
> +	if (bus->slave_state == ASPEED_I2C_SLAVE_STOP) {
> +		i2c_slave_event(slave, I2C_SLAVE_STOP, &value);
> +		bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
> +	}
> +	/*

If there's a reason to do a v4 then an extra empty line above the
comment would be nice. But let's not get hung up on that if everyone
else is happy.

Thanks for the fixes!

Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>

> +	 * Now that we've dealt with any potentially coalesced stop conditions,
> +	 * address any start conditions.
> +	 */
>  	if (irq_status & ASPEED_I2CD_INTR_SLAVE_MATCH) {
>  		irq_handled |= ASPEED_I2CD_INTR_SLAVE_MATCH;
>  		bus->slave_state = ASPEED_I2C_SLAVE_START;
>  	}
>  


From andrew at codeconstruct.com.au  Thu Dec  7 20:00:18 2023
From: andrew at codeconstruct.com.au (Andrew Jeffery)
Date: Fri, 08 Dec 2023 14:30:18 +1030
Subject: [PATCH v3 2/2] i2c: aspeed: Acknowledge Tx done with and
 without ACK irq late
In-Reply-To: <20231208033142.1673232-3-quan@os.amperecomputing.com>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
	 <20231208033142.1673232-3-quan@os.amperecomputing.com>
Message-ID: <dc36d61aedd2b2389eb366b27436f19d934fc93b.camel@codeconstruct.com.au>

On Fri, 2023-12-08 at 10:31 +0700, Quan Nguyen wrote:
> Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
> interrupt handler") acknowledges most interrupts early before the slave
> irq handler is executed, except for the "Receive Done Interrupt status"
> which is acknowledged late in the interrupt.
> However, it has been observed that the early acknowledgment of "Transmit
> Done Interrupt Status" (with ACK or NACK) often causes the interrupt to
> be raised in READ REQUEST state, that shows the
> "Unexpected ACK on read request." complaint messages.
> 
> Assuming that the "Transmit Done" interrupt should only be acknowledged
> once it is truly processed, this commit fixes that issue by acknowledging
> interrupts for both ACK and NACK cases late in the interrupt handler.
> 
> Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> ---
> v3:
>   + Fix the unconditinal write when ack the irqs               [Andrew]
>   + Refactor the code to enhance code readability                [Quan]
>   + Fix grammar in commit message                                [Quan]
> 
> v2:
>   + Split to separate series                                     [Joel]
>   + Added the Fixes line                                         [Joel]
>   + Fixed multiline comment                                      [Joel]
>   + Refactor irq clearing code                          [Joel, Guenter]
>   + Revised commit message                                       [Joel]
>   + Revised commit message                                       [Quan]
>   + About a note to remind why the readl() should immediately follow the
> writel() to fix the race condition when clearing irq status from commit
> c926c87b8e36 ("i2c: aspeed: Avoid i2c interrupt status clear race
> condition"), I think it looks straight forward in this patch and decided
> not to add that note.                                            [Joel]
> 
> v1:
>   + First introduced in
> https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/
> ---
>  drivers/i2c/busses/i2c-aspeed.c | 21 +++++++++++++--------
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index 1c2a4f4c4e1b..967a26dd4ffa 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -617,13 +617,19 @@ static u32 aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
>  static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
>  {
>  	struct aspeed_i2c_bus *bus = dev_id;
> -	u32 irq_received, irq_remaining, irq_handled;
> +	u32 irq_received, irq_remaining, irq_handled, irq_ack_last;

`irq_ack_last` might be better as a macro, but you're probably saved by
the optimiser anyway. If there's another reason to do a v4 or others
are unhappy with it then consider fixing it, otherwise:

Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>

Thanks.


From fshao at chromium.org  Thu Dec  7 20:22:24 2023
From: fshao at chromium.org (Fei Shao)
Date: Fri, 8 Dec 2023 12:22:24 +0800
Subject: [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free()
 error log criteria
In-Reply-To: <6046a40b-800c-4bf8-ab45-d7f1015b2d9c@collabora.com>
References: <20231113123049.4117280-1-fshao@chromium.org> <20231113123049.4117280-4-fshao@chromium.org>
 <6c693161-0e89-4f9d-9a92-18f3783eefd2@collabora.com> <CAC=S1nhp3HoKGQr1UgKtZJ9SLMqvm-G_YZi9dEWWF3tj2d=OFQ@mail.gmail.com>
 <6046a40b-800c-4bf8-ab45-d7f1015b2d9c@collabora.com>
Message-ID: <CAC=S1niMVxoryzg6X+vFcDpMRuO6YCzUFj4A+2yex+mfOBALRg@mail.gmail.com>

On Thu, Dec 7, 2023 at 8:55?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 07/12/23 12:17, Fei Shao ha scritto:
> > Hi Angelo,
> >
> > On Wed, Dec 6, 2023 at 6:19?PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno at collabora.com> wrote:
> >>
> >> Il 13/11/23 13:26, Fei Shao ha scritto:
> >>> mtk_vcodec_mem_free() shouldn't print error if the target DMA buffer has
> >>> never been allocated or was freed properly in the previous call. That
> >>> makes log confusing.
> >>>
> >>> Update the error path to print log only when the caller attempts to free
> >>> nonzero-size buffer with VA being NULL, which indicates something indeed
> >>> went wrong.
> >>>
> >>> This brings another benefit that the callers no more need to check
> >>> mem->va explicitly to avoid the error, which can make the code more
> >>> compact and neat.
> >>>
> >>> Signed-off-by: Fei Shao <fshao at chromium.org>
> >>
> >> I think that this error is supposed to catch two issues in one:
> >>    - We're called to free no memory (something that does make no sense),
> >>      this may happen for example when calling xxx_free() twice, and it
> >>      is a mistake that *must* be fixed;
> > When I made the change, I was thinking of kfree() that doesn't warn
> > against a NULL pointer.
> > I imagine mtk_vcodec_mem_free() calls with NULL VA and mem size 0
> > probably have the similar nuance (if the buffer exists, free it; never
> > mind otherwise), but I could have missed some important differences
> > specific to the MTK vcodec driver.
> >
> > Looking at the mtk_vcodec_mem_free() usages, almost every one of those
> > checks VA beforehand, but nothing else - they don't warn or do
> > anything special when they encounter a NULL VA, and they should if
> > that's a concern.
> > Some even don't check at all (and I think that's why I ended up seeing
> > the errors mentioned in the cover letter). As for that, I think
> > there's nothing else we can fix except prepending "if (mem->va)".
> > So from all this, I feel perhaps we don't need to worry much about
> > those NULL VA, and we can further remove the checks (or at least move
> > it into mtk_vcodec_mem_free()) to trim the lines in the driver. That's
> > the reason for patch [4/4].
> >
> > Not sure if that makes sense to you.
>
> What you say does make sense - and a lot - but still, I think that freeing
> a NULL VA (= freeing nothing) is something that shouldn't happen...
>
> >
> >>    - We're failing to free memory for real (which you covered)
> >>
> >> ....that said, I think that if you want to clarify the error messages
> >> in this function, it should look something like this:
> >>
> >> if (!mem->va) {
> >>          mtk_v4l2_err(plat_dev, "%s: Tried to free a NULL VA", __func__);
> >>          if (mem->size)
> >>                  mtk_v4l2_err(plat_dev, "Failed to free %lu bytes", mem->size);
> >>          return;
> >> }
> > Sure, I can revise the patch with this, but I also want to make sure
> > if the NULL VA print needs to be an error.
> > If you still think it should, I guess I'll drop the current patch
> > [4/4] and instead add the check before every mtk_vcodec_mem_free()
> > calls. This should also work for the issue I want to address in the
> > first place.
> >
>
> ... because if you notice, some of the calls to mtk_vcodec_mem_free() are not
> checked with `if (something->va)` beforehand, so I think that those are cases
> in which freeing with a NULL VA would actually be an indication of something
> going wrong and/or not as expected anyway (checking beforehand = error won't
> get printed from mtk_vcodec_mem_free(), not checking = print error if va==NULL)
>
> It's an easy check:
> cd drivers/media/platform/mediatek/vcodec
> grep -rb1 mtk_vcodec_mem_free
>
> P.S.: h264_if, av1_req_lat :-)
Yes, these are exactly what I wanted to imply in ">> Some even don't
check at all", and I should have pointed them out to avoid
ambiguity...
And I understand your concern. Presuming the NULL VA case is and will
always be safe to ignore can be too assertive, and getting explicit
error logs is always better than lurking bugs.

>
> That's why I think that you should drop your [4/4] - unless MediaTek comes in
> stating that the missed checks are something unintended, and that every instance
> of VA==NULL should print an error.
>
> I honestly wouldn't be surprised if they did so, because anyway this occurs only
> in two decoders...
Agree, it would be nice if Yunfei can share some thoughts here, or I
can reach out to him through other channels for alignment first, and
adjust this series based on the response.
The h264_if part was written a while ago (2016) and the av1_req_lat
part is relatively new (mid 2023), I hope it won't be too hard to
reach a conclusion for those.

Regards,
Fei

>
> Regards,
> Angelo


From dan.carpenter at linaro.org  Thu Dec  7 20:23:38 2023
From: dan.carpenter at linaro.org (Dan Carpenter)
Date: Fri, 8 Dec 2023 07:23:38 +0300
Subject: [PATCH net-next 07/15] net: dsa: mt7530: do not run
 mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <20231207184015.u7uoyfhdxiyuw6hh@skbuf>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-8-arinc.unal@arinc9.com>
 <20231121185358.GA16629@kernel.org>
 <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
 <90fde560-054e-4188-b15c-df2e082d3e33@moroto.mountain>
 <20231207184015.u7uoyfhdxiyuw6hh@skbuf>
Message-ID: <9b729dab-aebc-4c0c-a5e1-164845cd0948@suswa.mountain>

On Thu, Dec 07, 2023 at 08:40:15PM +0200, Vladimir Oltean wrote:
> 
> We could be more pragmatic about this whole sparse false positive warning,
> and just move the "if" block which calls mt7530_setup_port5() right
> after the priv->p5_intf_sel assignments, instead of waiting to "break;"
> from the for_each_child_of_node() loop.
> 
> for_each_child_of_node(dn, mac_np) {
> 	if (!of_device_is_compatible(mac_np,
> 				     "mediatek,eth-mac"))
> 		continue;
> 
> 	ret = of_property_read_u32(mac_np, "reg", &id);
> 	if (ret < 0 || id != 1)
> 		continue;
> 
> 	phy_node = of_parse_phandle(mac_np, "phy-handle", 0);
> 	if (!phy_node)
> 		continue;
> 
> 	if (phy_node->parent == priv->dev->of_node->parent) {
> 		ret = of_get_phy_mode(mac_np, &interface);
> 		if (ret && ret != -ENODEV) {
> 			of_node_put(mac_np);
> 			of_node_put(phy_node);
> 			return ret;
> 		}
> 		id = of_mdio_parse_addr(ds->dev, phy_node);
> 		if (id == 0)
> 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P0;
> 		if (id == 4)
> 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P4;
> 
> 		if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 || <---- here
> 		    priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
> 			mt7530_setup_port5(ds, interface);

This doesn't solve the problem that Smatch doesn't know what the
original value of priv->p5_intf_sel.  And also I don't like this code
because now we call mt7530_setup_port5() on every iteration after
we find the first P5_INTF_SEL_PHY_P0.

> 	}
> 	of_node_put(mac_np);
> 	of_node_put(phy_node);
> 	break;
> }

Let's not worry too much about false positives.  We can just ignore
them.  There is always a trade off between false positives and false
negatives.  With GCC we try to get a clean run with no warnings, but
with Smatch I'm targetting the false positive ratio at "this is worth
reviewing one time."

regards,
dan carpenter



From a0501179 at ti.com  Thu Dec  7 20:34:43 2023
From: a0501179 at ti.com (Anwar, Md Danish)
Date: Fri, 8 Dec 2023 10:04:43 +0530
Subject: [PATCH 3/3] arm64: dts: ti: k3-am642-evm: add overlay for icssg1
 2nd port
In-Reply-To: <b913dc5d-0dc1-478b-b4ca-cc049c3df58d@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-4-danishanwar@ti.com>
 <20231207132758.wbfn7timsqevdjpu@mortuary>
 <7323e86b-939a-4fd0-aac8-07fa47e00c9d@ti.com>
 <b913dc5d-0dc1-478b-b4ca-cc049c3df58d@ti.com>
Message-ID: <502101db-26b2-4a0d-8bb7-6a71a3ab4ca0@ti.com>

On 12/7/2023 10:14 PM, Andrew Davis wrote:
> On 12/7/23 8:06 AM, Anwar, Md Danish wrote:
>> On 12/7/2023 6:57 PM, Nishanth Menon wrote:
>>> On 13:49-20231207, MD Danish Anwar wrote:
>>>> The am642-evm doesn't allow to enable 2 x CPSW3g ports and 2 x
>>>> ICSSG1 ports
>>>> all together, so base k3-am642-evm.dts enables by default 2 x CPSW3g
>>>> ports
>>>> and 1 x ICSSG1 ports, but it also possible to support 1 x CPSW3g
>>>> ports and
>>>> 2 x ICSSG1 ports configuration.
>>>>
>>>> This patch adds overlay to support 1 x CPSW3g ports and 2 x ICSSG1
>>>> ports
>>>> configuration:
>>>> - disable 2nd CPSW3g port
>>>> - update CPSW3g pinmuxes to not use RGMII2
>>>> - disable mdio-mux-1 and define mdio-mux-2 to route ICSSG1 MDIO to the
>>>> ?? shared DP83869 PHY
>>>> - add and enable ICSSG1 RGMII2 pinmuxes
>>>> - enable ICSSG1 MII1 port
>>>>
>>>> Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
>>>> ---
>>>> ? arch/arm64/boot/dts/ti/Makefile?????????????? |? 2 +
>>>> ? .../dts/ti/k3-am642-evm-icssg1-dualemac.dtso? | 80
>>>> +++++++++++++++++++
>>>> ? arch/arm64/boot/dts/ti/k3-am642-evm.dts?????? |? 2 +-
>>>> ? 3 files changed, 83 insertions(+), 1 deletion(-)
>>>> ? create mode 100644
>>>> arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/Makefile
>>>> b/arch/arm64/boot/dts/ti/Makefile
>>>> index 5ef49b02c71f..99a4dce47f02 100644
>>>> --- a/arch/arm64/boot/dts/ti/Makefile
>>>> +++ b/arch/arm64/boot/dts/ti/Makefile
>>>> @@ -35,12 +35,14 @@ dtb-$(CONFIG_ARCH_K3) +=
>>>> k3-am62x-sk-csi2-imx219.dtbo
>>>> ? dtb-$(CONFIG_ARCH_K3) += k3-am62x-sk-hdmi-audio.dtbo
>>>> ? ? # Boards with AM64x SoC
>>>> +k3-am642-evm-icssg1-dtbs := k3-am642-evm.dtb
>>>> k3-am642-evm-icssg1-dualemac.dtbo
>>>
>>> Why not handle this for CONFIG_OF_ALL_DTBS alone? See commit
>>> b0044823a6607e535fdb083c89f487fbf183b171
>>>
>>
>> I'll have to look into this.
>>
>> I am merging this k3-am642-evm-icssg1-dualemac.dtbo with
>> k3-am642-evm.dtb because when I had posted patches for AM65x DTS, Andrew
>> had commented [1] saying we should not leave orphan dtbos and every dtbo
>> should be applied over some dtb by using `dtb- +=`.
>>
> 
> And my comment on not having orphan DTBOs is still true. But that was back
> in September, we now have a new way of accomplishing that without needing
> to produce a bunch of temporary combined DTB files, which is what Nishanth
> is pointing out with CONFIG_OF_ALL_DTBS.
> 
> So, no need for `k3-am642-evm-icssg1.dtb`, you can add the overlay target
> directly, then create a fake target to test DTBO application by adding to
> the `dtb- += ` lines below.
> 
> Andrew
> 

Sure Andrew. I'll do that and re-spin this series.

>> Due to this I am applying the overlay on k3-am642-evm.dtb and creating
>> new dtb k3-am642-evm-icssg1.dtb which can be used when both ICSSG1 ports
>> are needed to be enabled.
>>
>> [1]
>> https://lore.kernel.org/all/ca832fe3-d5cf-b075-324b-50da40794bb7 at ti.com/
>>
>>>> ? dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
>>>> ? dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
>>>> ? dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
>>>> ? dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
>>>> ? dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
>>>> ? dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
>>>> +dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-icssg1.dtb
>>>> ? ? # Boards with AM65x SoC
>>>> ? k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb
>>>> k3-am654-base-board-rocktech-rk101-panel.dtbo
>>>> diff --git
>>>> a/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>>>> b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>>>> new file mode 100644
>>>> index 000000000000..6f33290c1ad6
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
>>>> @@ -0,0 +1,80 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/**
>>>> + * DT overlay for enabling 2nd ICSSG1 port on AM642 EVM
>>>> + *
>>>> + * Copyright (C) 2023 Texas Instruments Incorporated -
>>>> https://www.ti.com/
>>>> + */
>>>> +
>>>> +/dts-v1/;
>>>> +/plugin/;
>>>> +
>>>> +#include <dt-bindings/gpio/gpio.h>
>>>> +#include "k3-pinctrl.h"
>>>> +
>>>> +&{/} {
>>>> +??? aliases {
>>>> +??????? ethernet1 = "/icssg1-eth/ethernet-ports/port at 0";
>>>> +??????? ethernet2 = "/icssg1-eth/ethernet-ports/port at 1";
>>>
>>> I don't understand what you are overriding here. isn't patch #2 in your
>>> series already introducing this in the base dts?
>>>
>>
>> Sorry, My bad. I will remove this in v2.
>>
>>>> +??? };
>>>> +
>>>> +??? mdio-mux-2 {
>>>> +??????? compatible = "mdio-mux-multiplexer";
>>>> +??????? mux-controls = <&mdio_mux>;
>>>> +??????? mdio-parent-bus = <&icssg1_mdio>;
>>>> +??????? #address-cells = <1>;
>>>> +??????? #size-cells = <0>;
>>>> +
>>>> +??????? mdio at 0 {
>>>> +??????????? reg = <0x0>;
>>>> +??????????? #address-cells = <1>;
>>>> +??????????? #size-cells = <0>;
>>>> +
>>>> +??????????? icssg1_phy2: ethernet-phy at 3 {
>>>> +??????????????? reg = <3>;
>>>> +??????????????? tx-internal-delay-ps = <250>;
>>>> +??????????????? rx-internal-delay-ps = <2000>;
>>>> +??????????? };
>>>> +??????? };
>>>> +??? };
>>>> +};
>>>> +
>>>> +&main_pmx0 {
>>>> +??? icssg1_rgmii2_pins_default: icssg1-rgmii2-default-pins {
>>>> +??????? pinctrl-single,pins = <
>>>> +??????????? AM64X_IOPAD(0x0108, PIN_INPUT, 2) /* (W11)
>>>> PRG1_PRU1_GPO0.RGMII2_RD0 */
>>>> +??????????? AM64X_IOPAD(0x010c, PIN_INPUT, 2) /* (V11)
>>>> PRG1_PRU1_GPO1.RGMII2_RD1 */
>>>> +??????????? AM64X_IOPAD(0x0110, PIN_INPUT, 2) /* (AA12)
>>>> PRG1_PRU1_GPO2.RGMII2_RD2 */
>>>> +??????????? AM64X_IOPAD(0x0114, PIN_INPUT, 2) /* (Y12)
>>>> PRG1_PRU1_GPO3.RGMII2_RD3 */
>>>> +??????????? AM64X_IOPAD(0x0120, PIN_INPUT, 2) /* (U11)
>>>> PRG1_PRU1_GPO6.RGMII2_RXC */
>>>> +??????????? AM64X_IOPAD(0x0118, PIN_INPUT, 2) /* (W12)
>>>> PRG1_PRU1_GPO4.RGMII2_RX_CTL */
>>>> +??????????? AM64X_IOPAD(0x0134, PIN_OUTPUT, 2) /* (AA10)
>>>> PRG1_PRU1_GPO11.RGMII2_TD0 */
>>>> +??????????? AM64X_IOPAD(0x0138, PIN_OUTPUT, 2) /* (V10)
>>>> PRG1_PRU1_GPO12.RGMII2_TD1 */
>>>> +??????????? AM64X_IOPAD(0x013c, PIN_OUTPUT, 2) /* (U10)
>>>> PRG1_PRU1_GPO13.RGMII2_TD2 */
>>>> +??????????? AM64X_IOPAD(0x0140, PIN_OUTPUT, 2) /* (AA11)
>>>> PRG1_PRU1_GPO14.RGMII2_TD3 */
>>>> +??????????? AM64X_IOPAD(0x0148, PIN_OUTPUT, 2) /* (Y10)
>>>> PRG1_PRU1_GPO16.RGMII2_TXC */
>>>> +??????????? AM64X_IOPAD(0x0144, PIN_OUTPUT, 2) /* (Y11)
>>>> PRG1_PRU1_GPO15.RGMII2_TX_CTL */
>>>> +??????? >;
>>>> +??? };
>>>> +};
>>>> +
>>>> +&cpsw3g {
>>>> +??? pinctrl-0 = <&rgmii1_pins_default>;
>>>> +};
>>>> +
>>>> +&cpsw_port2 {
>>>> +??? status = "disabled";
>>>> +};
>>>> +
>>>> +&mdio_mux_1 {
>>>> +??? status = "disabled";
>>>> +};
>>>> +
>>>> +&icssg1_eth {
>>>> +??? pinctrl-0 = <&icssg1_rgmii1_pins_default
>>>> &icssg1_rgmii2_pins_default>;
>>>
>>> Grrr... No! I have been cleaning up after you folks and you folks should
>>> take notice.
>>>
>>> pinctrl-0 = <&icssg1_rgmii1_pins_default>,
>>> <&icssg1_rgmii2_pins_default>;
>>>
>>
>> Sorry, I was not aware of this. I will change it in v2.
>>
>>>
>>>> +};
>>>> +
>>>> +&icssg1_emac1 {
>>>> +??? status = "okay";
>>>> +??? phy-handle = <&icssg1_phy2>;
>>>> +??? phy-mode = "rgmii-id";
>>>> +};
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>>>> b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>>>> index 04d1c0602d31..90867090e725 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
>>>> @@ -203,7 +203,7 @@ mdio_mux: mux-controller {
>>>> ????????? mux-gpios = <&exp1 12 GPIO_ACTIVE_HIGH>;
>>>> ????? };
>>>> ? -??? mdio-mux-1 {
>>>> +??? mdio_mux_1: mdio-mux-1 {
>>>
>>> Commit message doesn't warn me for this change.
>>
>> Sure. I will add details of this in commit message saying `Add label
>> name 'mdio_mux_1' for 'mdio-mux-1' node so that the node 'mdio-mux-1'
>> can be disabled in the overlay using the label name.`
>>
>>>> ????????? compatible = "mdio-mux-multiplexer";
>>>> ????????? mux-controls = <&mdio_mux>;
>>>> ????????? mdio-parent-bus = <&cpsw3g_mdio>;
>>>> --?
>>>> 2.34.1
>>>>
>>>
>>

-- 
Thanks and Regards,
Md Danish Anwar


From a0501179 at ti.com  Thu Dec  7 20:35:25 2023
From: a0501179 at ti.com (Anwar, Md Danish)
Date: Fri, 8 Dec 2023 10:05:25 +0530
Subject: [PATCH 2/3] arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet
 support
In-Reply-To: <9e0067dd-4865-4afc-ba42-bda504459ad8@lunn.ch>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-3-danishanwar@ti.com>
 <9e0067dd-4865-4afc-ba42-bda504459ad8@lunn.ch>
Message-ID: <fa5c273d-2b03-4f8b-b94d-4110a4b70d16@ti.com>



On 12/8/2023 3:04 AM, Andrew Lunn wrote:
>> +&icssg1_mdio {
>> +	status = "okay";
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&icssg1_mdio1_pins_default>;
>> +
>> +	icssg1_phy1: ethernet-phy at 0 {
>> +		reg = <0xf>;
> 
> reg = 0xf, so this is ethernet-phy at f.
> 
>     Andrew

Sure Andrew. I'll update this.

-- 
Thanks and Regards,
Md Danish Anwar


From f.fainelli at gmail.com  Thu Dec  7 20:49:25 2023
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 7 Dec 2023 20:49:25 -0800
Subject: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
In-Reply-To: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
References: <20231203174622.18402-1-krzysztof.kozlowski@linaro.org>
Message-ID: <a3f24fdf-946c-4253-956d-4d345decdeb6@gmail.com>



On 12/3/2023 9:46 AM, Krzysztof Kozlowski wrote:
> Document preferred coding style for Devicetree sources (DTS and DTSI),
> to bring consistency among all (sub)architectures and ease in reviews.
> 
> Cc: Andrew Davis <afd at ti.com>
> cc: Andrew Lunn <andrew at lunn.ch>
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Bjorn Andersson <andersson at kernel.org>
> Cc: Chen-Yu Tsai <wens at kernel.org>
> Cc: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> Cc: Jonathan Corbet <corbet at lwn.net>
> Cc: Matthias Brugger <matthias.bgg at gmail.com>
> Cc: Michal Simek <michal.simek at amd.com>
> Cc: Neil Armstrong <neil.armstrong at linaro.org>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Olof Johansson <olof at lixom.net>
> Cc: Rafa? Mi?ecki <zajec5 at gmail.com>
> Acked-by: Neil Armstrong <neil.armstrong at linaro.org>
> Acked-by: Heiko Stuebner <heiko at sntech.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Acked-by: Konrad Dybcio <konradybcio at kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian


From samuel.holland at sifive.com  Thu Dec  7 20:49:53 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu, 7 Dec 2023 22:49:53 -0600
Subject: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
In-Reply-To: <ZV2+f/yu3C6xTVqn@infradead.org>
References: <20231122030621.3759313-1-samuel.holland@sifive.com>
 <20231122030621.3759313-4-samuel.holland@sifive.com>
 <ZV2+f/yu3C6xTVqn@infradead.org>
Message-ID: <6d4cecd5-9083-4d68-a7e2-266dae9e3952@sifive.com>

Hi Christoph,

On 2023-11-22 2:40 AM, Christoph Hellwig wrote:
>> -	select DRM_AMD_DC_FP if (X86 || LOONGARCH || (PPC64 && ALTIVEC) || (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
>> +	select DRM_AMD_DC_FP if ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG
>> +	select DRM_AMD_DC_FP if PPC64 && ALTIVEC
>> +	select DRM_AMD_DC_FP if RISCV && FPU
>> +	select DRM_AMD_DC_FP if LOONGARCH || X86
> 
> This really is a mess.  Can you add a ARCH_HAS_KERNEL_FPU_SUPPORT
> symbol that all architetures that have it select instead, and them
> make DRM_AMD_DC_FP depend on it?

Yes, I have done this for v2, which I will send shortly.

>> -#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
>> +#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH) || defined(CONFIG_RISCV)
>>  		kernel_fpu_begin();
>>  #elif defined(CONFIG_PPC64)
>>  		if (cpu_has_feature(CPU_FTR_VSX_COMP))
>> @@ -122,7 +124,7 @@ void dc_fpu_end(const char *function_name, const int line)
>>  
>>  	depth = __this_cpu_dec_return(fpu_recursion_depth);
>>  	if (depth == 0) {
>> -#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
>> +#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH) || defined(CONFIG_RISCV)
>>  		kernel_fpu_end();
>>  #elif defined(CONFIG_PPC64)
>>  		if (cpu_has_feature(CPU_FTR_VSX_COMP))
> 
> And then this mess can go away.  We'll need to decide if we want to
> cover all the in-kernel vector support as part of it, which would
> seem reasonable to me, or have a separate generic kernel_vector_begin
> with it's own option.

I think we may want to keep vector separate for performance on architectures
with separate FP and vector register files. For now, I have limited my changes
to FPU support only, which means I have removed VSX/Altivec from here; the
AMDGPU code doesn't need Altivec anyway.

>> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>> index ea7d60f9a9b4..5c8f840ef323 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
>> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>> @@ -43,6 +43,12 @@ dml_ccflags := -mfpu=64
>>  dml_rcflags := -msoft-float
>>  endif
>>  
>> +ifdef CONFIG_RISCV
>> +include $(srctree)/arch/riscv/Makefile.isa
>> +# Remove V from the ISA string, like in arch/riscv/Makefile, but keep F and D.
>> +dml_ccflags := -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)([^v_]*)v?/\1\2/')
>> +endif
>> +
>>  ifdef CONFIG_CC_IS_GCC
>>  ifneq ($(call gcc-min-version, 70100),y)
>>  IS_OLD_GCC = 1
> 
> And this is again not really something we should be doing.
> Instead we need a generic way in Kconfig to enable FPU support
> for an object file or set of, that the arch support can hook
> into.

I've included this in v2 as well.

> Btw, I'm also really worried about folks using the FPU instructions
> outside the kernel_fpu_begin/end windows in general (not directly
> related to the RISC-V support).  Can we have objecttool checks
> for that similar to only allowing the unsafe uaccess in the
> uaccess begin/end pairs?

ARM partially enforces this at compile time: it disallows calling
kernel_neon_begin() inside a translation unit that has NEON enabled. That
doesn't prevent the programmer from calling a FPU-enabled function from outside
a begin/end section, but it does prevent the compiler from generating unexpected
FPU usage behind your back. I implemented this same functionality for RISC-V.

Actually tracking all possibly-FPU-tainted functions and their call sites is
probably possible, but a much larger task.

Regards,
Samuel



From hyesoo.yu at samsung.com  Thu Dec  7 21:03:44 2023
From: hyesoo.yu at samsung.com (Hyesoo Yu)
Date: Fri, 8 Dec 2023 14:03:44 +0900
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <ZWxxJipc2STxHHKn@raptor>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
	<CGME20231119165840epcas2p2c99f1dd358f716c103c16f47cc23bf2a@epcas2p2.samsung.com>
	<20231119165721.9849-12-alexandru.elisei@arm.com>
	<20231129084424.GA2988384@tiffany> <ZWxxJipc2STxHHKn@raptor>
Message-ID: <20231208050340.GA1359878@tiffany>

Hi, 

I'm sorry for the late response, I was on vacation.

On Sun, Dec 03, 2023 at 12:14:30PM +0000, Alexandru Elisei wrote:
> Hi,
> 
> On Wed, Nov 29, 2023 at 05:44:24PM +0900, Hyesoo Yu wrote:
> > Hello.
> > 
> > On Sun, Nov 19, 2023 at 04:57:05PM +0000, Alexandru Elisei wrote:
> > > Allow the kernel to get the size and location of the MTE tag storage
> > > regions from the DTB. This memory is marked as reserved for now.
> > > 
> > > The DTB node for the tag storage region is defined as:
> > > 
> > >         tags0: tag-storage at 8f8000000 {
> > >                 compatible = "arm,mte-tag-storage";
> > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > >                 block-size = <0x1000>;
> > >                 memory = <&memory0>;	// Associated tagged memory node
> > >         };
> > >
> > 
> > How about using compatible = "shared-dma-pool" like below ?
> > 
> > &reserved_memory {
> > 	tags0: tag0 at 8f8000000 {
> > 		compatible = "arm,mte-tag-storage";
> >         	reg = <0x08 0xf8000000 0x00 0x4000000>;
> > 	};
> > }
> > 
> > tag-storage {
> >         compatible = "arm,mte-tag-storage";
> > 	memory-region = <&tag>;
> >         memory = <&memory0>;
> > 	block-size = <0x1000>;
> > }
> > 
> > And then, the activation of CMA would be performed in the CMA code.
> > We just can get the region information from memory-region and allocate it directly
> > like alloc_contig_range, take_page_off_buddy. It seems like we can remove a lots of code.
>

Sorry, that example was my mistake. Actually I wanted to write like this. 

&reserved_memory {
	tags0: tag0 at 8f8000000 {
		compatible = "shared-dma-pool";
        	reg = <0x08 0xf8000000 0x00 0x4000000>;
		reusable;
	};
}

tag-storage {
        compatible = "arm,mte-tag-storage";
 	memory-region = <&tag>;
        memory = <&memory0>;
	block-size = <0x1000>;
}


> Played with reserved_mem a bit. I don't think that's the correct path
> forward.
> 
> The location of the tag storage is a hardware property, independent of how
> Linux is configured.
> 
> early_init_fdt_scan_reserved_mem() is called from arm64_memblock_init(),
> **after** the kernel enforces an upper address for various reasons. One of
> the reasons can be that it's been compiled with 39 bits VA.
> 

I'm not sure about this part. What is the upper address enforced by the kernel ?
Where can I check the code ? Do you means that memblock_end_of_DRAM() ?  

> After early_init_fdt_scan_reserved_mem() returns, the kernel sets the
> maximum address, stored in the variable "high_memory".
>
> What can happen is that tag storage is present at an address above the
> maximum addressable by the kernel, and the CMA code will trigger an
> unrecovrable page fault.
> 
> I was able to trigger this with the dts change:
> 
> diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> index 60472d65a355..201359d014e4 100644
> --- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> +++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> @@ -183,6 +183,13 @@ vram: vram at 18000000 {
>                         reg = <0x00000000 0x18000000 0 0x00800000>;
>                         no-map;
>                 };
> +
> +
> +               linux,cma {
> +                       compatible = "shared-dma-pool";
> +                       reg = <0x100 0x0 0x00 0x4000000>;
> +                       reusable;
> +               };
>         };
> 
>         gic: interrupt-controller at 2f000000 {
> 
> And the error I got:
> 
> [    0.000000] Reserved memory: created CMA memory pool at 0x0000010000000000, size 64 MiB
> [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> [    0.000000] OF: reserved mem: 0x0000010000000000..0x0000010003ffffff (65536 KiB) map reusable linux,cma
> [..]
> [    0.793193] WARNING: CPU: 0 PID: 1 at mm/cma.c:111 cma_init_reserved_areas+0xa8/0x378
> [..]
> [    0.806945] Unable to handle kernel paging request at virtual address 00000001fe000000
> [    0.807277] Mem abort info:
> [    0.807277]   ESR = 0x0000000096000005
> [    0.807693]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    0.808110]   SET = 0, FnV = 0
> [    0.808443]   EA = 0, S1PTW = 0
> [    0.808526]   FSC = 0x05: level 1 translation fault
> [    0.808943] Data abort info:
> [    0.808943]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
> [    0.809360]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [    0.809776]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [    0.810221] [00000001fe000000] user address but active_mm is swapper
> [..]
> [    0.820887] Call trace:
> [    0.821027]  cma_init_reserved_areas+0xc4/0x378
> [    0.821443]  do_one_initcall+0x7c/0x1c0
> [    0.821860]  kernel_init_freeable+0x1bc/0x284
> [    0.822277]  kernel_init+0x24/0x1dc
> [    0.822693]  ret_from_fork+0x10/0x20
> [    0.823554] Code: 9127a29a cb813321 d37ae421 8b030020 (f8636822)
> [    0.823554] ---[ end trace 0000000000000000 ]---
> [    0.824360] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [    0.824443] SMP: stopping secondary CPUs
> [    0.825193] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> 
> Should reserved mem check if the reserved memory is actually addressable by
> the kernel if it's not "no-map"? Should cma fail gracefully if
> !pfn_valid(base_pfn)? Shold early_init_fdt_scan_reserved_mem() be moved
> because arm64_bootmem_init()? I don't have the answer to any of those. And
> I got a kernel panic because the kernel cannot address that memory (39 bits
> VA). I don't know what would happen if the upper limit is reduced for
> another reason.
> 

My answer may not be accurate because I don't understand what this upper limit is.
Is this a problem caused by the tag storage area not being included in the memory node ?

The reason for not including it in the memory node is to enable static mte when dmte
initilization fails, right ? I think I missed that. I thought the tag storage is included
in the memory node and registered as cma.

> What I think should happen:
> 
> 1. Add the tag storage memory before any limits are enforced by
> arm64_bootmem_init().
>
> 2. Call cma_declare_contiguous_nid() after arm64_bootmem_init(), because
> the function will check the memory limit.
> 
> 3. Have an arch initcall that checks that the CMA regions corresponding to
> the tag storage have been activated successfully (cma_init_reserved_areas()
> is a core initcall). If not, then don't enable tag storage.
> 
> How does that sound to you?
> 
> Thanks,
> Alex
> 

I think this is a good way to utilize the cma code !

Thanks,
Regards.

> > > +	ret = tag_storage_of_flat_read_u32(node, "block-size", &block_size_bytes);
> > > +	if (ret || block_size_bytes == 0) {
> > > +		pr_err("Invalid or missing 'block-size' property");
> > > +		return -EINVAL;
> > > +	}
> > > +	region->block_size = get_block_size_pages(block_size_bytes);
> > > +	if (range_len(tag_range) % region->block_size != 0) {
> > > +		pr_err("Tag storage region size 0x%llx is not a multiple of block size %u",
> > > +		       PFN_PHYS(range_len(tag_range)), region->block_size);
> > > +		return -EINVAL;
> > > +	}
> > > +
> > 
> > I was confused about the variable "block_size", The block size declared in the device tree is
> > in bytes, but the actual block size used is in pages. I think the term "block_size" can cause
> > confusion as it might be interpreted as bytes. If possible, I suggest changing the term "block_size"
> > to something more readable, such as "block_nr_pages" (This is just a example!)
> > 
> > Thanks,
> > Regards.
>>

What do you think about this ?

Thanks,
Regards.

> > > +	ret = tag_storage_of_flat_read_u32(mem_node, "numa-node-id", &nid);
> > > +	if (ret)
> > > +		nid = numa_node_id();
> > > +
> > > +	ret = memblock_add_node(PFN_PHYS(tag_range->start), PFN_PHYS(range_len(tag_range)),
> > > +				nid, MEMBLOCK_NONE);
> > > +	if (ret) {
> > > +		pr_err("Error adding tag memblock (%d)", ret);
> > > +		return ret;
> > > +	}
> > > +	memblock_reserve(PFN_PHYS(tag_range->start), PFN_PHYS(range_len(tag_range)));
> > > +
> > > +	pr_info("Found tag storage region 0x%llx-0x%llx, block size %u pages",
> > > +		PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->end), region->block_size);
> > > +
> > > +	num_tag_regions++;
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +void __init mte_tag_storage_init(void)
> > > +{
> > > +	struct range *tag_range;
> > > +	int i, ret;
> > > +
> > > +	ret = of_scan_flat_dt(fdt_init_tag_storage, NULL);
> > > +	if (ret) {
> > > +		for (i = 0; i < num_tag_regions; i++) {
> > > +			tag_range = &tag_regions[i].tag_range;
> > > +			memblock_remove(PFN_PHYS(tag_range->start), PFN_PHYS(range_len(tag_range)));
> > > +		}
> > > +		num_tag_regions = 0;
> > > +		pr_info("MTE tag storage region management disabled");
> > > +	}
> > > +}
> > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > index 417a8a86b2db..1b77138c1aa5 100644
> > > --- a/arch/arm64/kernel/setup.c
> > > +++ b/arch/arm64/kernel/setup.c
> > > @@ -42,6 +42,7 @@
> > >  #include <asm/cpufeature.h>
> > >  #include <asm/cpu_ops.h>
> > >  #include <asm/kasan.h>
> > > +#include <asm/mte_tag_storage.h>
> > >  #include <asm/numa.h>
> > >  #include <asm/scs.h>
> > >  #include <asm/sections.h>
> > > @@ -342,6 +343,12 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
> > >  			   FW_BUG "Booted with MMU enabled!");
> > >  	}
> > >  
> > > +	/*
> > > +	 * Must be called before memory limits are enforced by
> > > +	 * arm64_memblock_init().
> > > +	 */
> > > +	mte_tag_storage_init();
> > > +
> > >  	arm64_memblock_init();
> > >  
> > >  	paging_init();
> > > -- 
> > > 2.42.1
> > > 
> > > 
> 
> 
> 

From hyesoo.yu at samsung.com  Thu Dec  7 21:27:39 2023
From: hyesoo.yu at samsung.com (Hyesoo Yu)
Date: Fri, 8 Dec 2023 14:27:39 +0900
Subject: [PATCH RFC v2 15/27] arm64: mte: Check that tag storage blocks
 are in the same zone
In-Reply-To: <ZWh5S9BoO5bG5nQM@raptor>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
	<CGME20231119165900epcas2p3efd0f3ac19b7bcf7883e8d3945e63326@epcas2p3.samsung.com>
	<20231119165721.9849-16-alexandru.elisei@arm.com>
	<20231129085744.GB2988384@tiffany> <ZWh5S9BoO5bG5nQM@raptor>
Message-ID: <20231208052739.GB1359878@tiffany>

Hi~

On Thu, Nov 30, 2023 at 12:00:11PM +0000, Alexandru Elisei wrote:
> Hi,
> 
> On Wed, Nov 29, 2023 at 05:57:44PM +0900, Hyesoo Yu wrote:
> > On Sun, Nov 19, 2023 at 04:57:09PM +0000, Alexandru Elisei wrote:
> > > alloc_contig_range() requires that the requested pages are in the same
> > > zone. Check that this is indeed the case before initializing the tag
> > > storage blocks.
> > > 
> > > Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
> > > ---
> > >  arch/arm64/kernel/mte_tag_storage.c | 33 +++++++++++++++++++++++++++++
> > >  1 file changed, 33 insertions(+)
> > > 
> > > diff --git a/arch/arm64/kernel/mte_tag_storage.c b/arch/arm64/kernel/mte_tag_storage.c
> > > index 8b9bedf7575d..fd63430d4dc0 100644
> > > --- a/arch/arm64/kernel/mte_tag_storage.c
> > > +++ b/arch/arm64/kernel/mte_tag_storage.c
> > > @@ -265,6 +265,35 @@ void __init mte_tag_storage_init(void)
> > >  	}
> > >  }
> > >  
> > > +/* alloc_contig_range() requires all pages to be in the same zone. */
> > > +static int __init mte_tag_storage_check_zone(void)
> > > +{
> > > +	struct range *tag_range;
> > > +	struct zone *zone;
> > > +	unsigned long pfn;
> > > +	u32 block_size;
> > > +	int i, j;
> > > +
> > > +	for (i = 0; i < num_tag_regions; i++) {
> > > +		block_size = tag_regions[i].block_size;
> > > +		if (block_size == 1)
> > > +			continue;
> > > +
> > > +		tag_range = &tag_regions[i].tag_range;
> > > +		for (pfn = tag_range->start; pfn <= tag_range->end; pfn += block_size) {
> > > +			zone = page_zone(pfn_to_page(pfn));
> > 
> > Hello.
> > 
> > Since the blocks within the tag_range must all be in the same zone, can we move the "page_zone"
> > out of the loop ?
> `
> Hmm.. why do you say that the pages in a tag_range must be in the same
> zone? I am not very familiar with how the memory management code puts pages
> into zones, but I would imagine that pages in a tag range straddling the
> 4GB limit (so, let's say, from 3GB to 5GB) will end up in both ZONE_DMA and
> ZONE_NORMAL.
> 
> Thanks,
> Alex
> 

Oh, I see that reserve_tag_storage only calls alloc_contig_rnage in units of block_size,
I thought it could be called for the entire range the page needed at once.
(Maybe it could be a bit faster ? It doesn't seem like unnecessary drain and
other operation are repeated.)

If we use the cma code when activating the tag storage, it will be error if the
entire area of tag region is not in the same zone, so there should be a constraint
that it must be in the same zone when defining the tag region on device tree.

Thanks,
Regards.

> > 
> > Thanks,
> > Regards.
> > 
> > > +			for (j = 1; j < block_size; j++) {
> > > +				if (page_zone(pfn_to_page(pfn + j)) != zone) {
> > > +					pr_err("Tag storage block pages in different zones");
> > > +					return -EINVAL;
> > > +				}
> > > +			}
> > > +		}
> > > +	}
> > > +
> > > +	 return 0;
> > > +}
> > > +
> > >  static int __init mte_tag_storage_activate_regions(void)
> > >  {
> > >  	phys_addr_t dram_start, dram_end;
> > > @@ -321,6 +350,10 @@ static int __init mte_tag_storage_activate_regions(void)
> > >  		goto out_disabled;
> > >  	}
> > >  
> > > +	ret = mte_tag_storage_check_zone();
> > > +	if (ret)
> > > +		goto out_disabled;
> > > +
> > >  	for (i = 0; i < num_tag_regions; i++) {
> > >  		tag_range = &tag_regions[i].tag_range;
> > >  		for (pfn = tag_range->start; pfn <= tag_range->end; pfn += pageblock_nr_pages)
> > > -- 
> > > 2.42.1
> > > 
> > > 
> 
> 
> 

From anshuman.khandual at arm.com  Thu Dec  7 21:39:29 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:29 +0530
Subject: [PATCH V3 00/10] coresight: Move remaining AMBA ACPI devices into platform driver
Message-ID: <20231208053939.42901-1-anshuman.khandual@arm.com>

This moves remaining AMBA ACPI devices into respective platform drivers for
enabling ACPI based power management support. This series applies on latest
coresight/next branch. This series has been built, and boot tested on a DT
based coresight platform. Although this still requires some more testing on
ACPI based coresight platforms.

https://git.gitlab.arm.com/linux-arm/linux-anshuman.git (amba_other_acpi_migration_v3)

Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: linux-acpi at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: coresight at lists.linaro.org
Cc: linux-stm32 at st-md-mailman.stormreply.com

Changes in V3:

- Split coresight_init_driver/remove_driver() helpers into a separate patch
- Added 'drvdata->pclk' comments in replicator, funnel, tpiu, tmc, and stm devices
- Updated funnel, and replicator drivers to use these new helpers
- Check for drvdata instead of drvdata->pclk in suspend and resume paths in catu,
  tmc and debug devices
- Added patch to extract device name from AMBA pid based table lookup for stm
- Added patch to extract device properties from AMBA pid based table look for tmc
- Dropped pm_runtime_put() from common __probe() functions
- Handled pm_runtime_put() in AMBA driver in success path
- Handled pm_runtime_put() in platform driver in both success and error paths

Changes in V2:

https://lore.kernel.org/all/20231201062053.1268492-1-anshuman.khandual at arm.com/

- Dropped redundant devm_ioremap_resource() hunk from tmc_platform_probe()
- Defined coresight_[init|remove]_driver() for both AMBA/platform drivers
- Changed catu, tmc, tpiu, stm and debug coresight drivers to use the new
  helpers avoiding build issues arising from module_amba_driver(), and
  module_platform_driver() being on the same file

Changes in V1:

https://lore.kernel.org/all/20231027072943.3418997-1-anshuman.khandual at arm.com/

- Replaced all IS_ERR() instances with IS_ERR_OR_NULL() as per Suzuki

Changes in RFC:

https://lore.kernel.org/all/20230921042040.1334641-1-anshuman.khandual at arm.com/

Anshuman Khandual (10):
  coresight: stm: Extract device name from AMBA pid based table lookup
  coresight: tmc: Extract device properties from AMBA pid based table lookup
  coresight: Add helpers registering/removing both AMBA and platform drivers
  coresight: replicator: Move ACPI support from AMBA driver to platform driver
  coresight: funnel: Move ACPI support from AMBA driver to platform driver
  coresight: catu: Move ACPI support from AMBA driver to platform driver
  coresight: tpiu: Move ACPI support from AMBA driver to platform driver
  coresight: tmc: Move ACPI support from AMBA driver to platform driver
  coresight: stm: Move ACPI support from AMBA driver to platform driver
  coresight: debug: Move ACPI support from AMBA driver to platform driver

 drivers/acpi/arm64/amba.c                     |   8 -
 drivers/hwtracing/coresight/coresight-catu.c  | 140 +++++++++++++---
 drivers/hwtracing/coresight/coresight-catu.h  |   1 +
 drivers/hwtracing/coresight/coresight-core.c  |  29 ++++
 .../hwtracing/coresight/coresight-cpu-debug.c | 141 ++++++++++++++--
 .../hwtracing/coresight/coresight-funnel.c    |  87 +++++-----
 drivers/hwtracing/coresight/coresight-priv.h  |  10 ++
 .../coresight/coresight-replicator.c          |  81 ++++-----
 drivers/hwtracing/coresight/coresight-stm.c   | 115 +++++++++++--
 .../hwtracing/coresight/coresight-tmc-core.c  | 156 +++++++++++++++---
 drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
 drivers/hwtracing/coresight/coresight-tpiu.c  |  99 +++++++++--
 include/linux/coresight.h                     |   7 +
 13 files changed, 713 insertions(+), 163 deletions(-)

-- 
2.25.1



From anshuman.khandual at arm.com  Thu Dec  7 21:39:30 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:30 +0530
Subject: [PATCH V3 01/10] coresight: stm: Extract device name from AMBA pid based table lookup
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-2-anshuman.khandual@arm.com>

Instead of using AMBA private data field, extract the device name from AMBA
pid based table lookup using new coresight_get_uci_data_from_amba() helper.

Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: coresight at lists.linaro.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- New patch in the series

 drivers/hwtracing/coresight/coresight-priv.h | 10 ++++++++++
 drivers/hwtracing/coresight/coresight-stm.c  | 14 +++++++++++++-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 767076e07970..68cbb036cec8 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -221,6 +221,16 @@ static inline void *coresight_get_uci_data(const struct amba_id *id)
 	return uci_id->data;
 }
 
+static inline void *coresight_get_uci_data_from_amba(const struct amba_id *table, u32 pid)
+{
+	while (table->mask) {
+		if ((table->id & table->mask) == pid)
+			return coresight_get_uci_data(table);
+		table++;
+	};
+	return NULL;
+}
+
 void coresight_release_platform_data(struct coresight_device *csdev,
 				     struct device *dev,
 				     struct coresight_platform_data *pdata);
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index a1c27c901ad1..9cdca4f86cab 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -804,6 +804,18 @@ static void stm_init_generic_data(struct stm_drvdata *drvdata,
 	drvdata->stm.set_options = stm_generic_set_options;
 }
 
+#define STM_AMBA_MASK 0xfffff
+
+static const struct amba_id stm_ids[];
+
+static char *stm_csdev_name(struct coresight_device *csdev)
+{
+	u32 stm_pid = coresight_get_pid(&csdev->access) & STM_AMBA_MASK;
+	void *uci_data = coresight_get_uci_data_from_amba(stm_ids, stm_pid);
+
+	return uci_data ? (char *)uci_data : "STM";
+}
+
 static int stm_probe(struct amba_device *adev, const struct amba_id *id)
 {
 	int ret, trace_id;
@@ -900,7 +912,7 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id)
 	pm_runtime_put(&adev->dev);
 
 	dev_info(&drvdata->csdev->dev, "%s initialized\n",
-		 (char *)coresight_get_uci_data(id));
+		 stm_csdev_name(drvdata->csdev));
 	return 0;
 
 cs_unregister:
-- 
2.25.1



From anshuman.khandual at arm.com  Thu Dec  7 21:39:31 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:31 +0530
Subject: [PATCH V3 02/10] coresight: tmc: Extract device properties from AMBA pid based table lookup
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-3-anshuman.khandual@arm.com>

This extracts device properties from AMBA pid based table lookup. This also
defers tmc_etr_setup_caps() after the coresight device has been initialized
so that pid value can be read.

Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: coresight at lists.linaro.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- New patch in the series

 .../hwtracing/coresight/coresight-tmc-core.c  | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index c106d142e632..ad61d02f5f75 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -362,16 +362,24 @@ static inline bool tmc_etr_has_non_secure_access(struct tmc_drvdata *drvdata)
 	return (auth & TMC_AUTH_NSID_MASK) == 0x3;
 }
 
+#define TMC_AMBA_MASK 0xfffff
+
+static const struct amba_id tmc_ids[];
+
 /* Detect and initialise the capabilities of a TMC ETR */
-static int tmc_etr_setup_caps(struct device *parent, u32 devid, void *dev_caps)
+static int tmc_etr_setup_caps(struct device *parent, u32 devid)
 {
 	int rc;
-	u32 dma_mask = 0;
+	u32 tmc_pid, dma_mask = 0;
 	struct tmc_drvdata *drvdata = dev_get_drvdata(parent);
+	void *dev_caps;
 
 	if (!tmc_etr_has_non_secure_access(drvdata))
 		return -EACCES;
 
+	tmc_pid = coresight_get_pid(&drvdata->csdev->access) & TMC_AMBA_MASK;
+	dev_caps = coresight_get_uci_data_from_amba(tmc_ids, tmc_pid);
+
 	/* Set the unadvertised capabilities */
 	tmc_etr_init_caps(drvdata, (u32)(unsigned long)dev_caps);
 
@@ -487,10 +495,6 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
 		desc.type = CORESIGHT_DEV_TYPE_SINK;
 		desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM;
 		desc.ops = &tmc_etr_cs_ops;
-		ret = tmc_etr_setup_caps(dev, devid,
-					 coresight_get_uci_data(id));
-		if (ret)
-			goto out;
 		idr_init(&drvdata->idr);
 		mutex_init(&drvdata->idr_mutex);
 		dev_list = &etr_devs;
@@ -528,6 +532,9 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
 		goto out;
 	}
 
+	if (drvdata->config_type == TMC_CONFIG_TYPE_ETR)
+		ret = tmc_etr_setup_caps(dev, devid);
+
 	drvdata->miscdev.name = desc.name;
 	drvdata->miscdev.minor = MISC_DYNAMIC_MINOR;
 	drvdata->miscdev.fops = &tmc_fops;
-- 
2.25.1



From n-francis at ti.com  Thu Dec  7 21:39:45 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 8 Dec 2023 11:09:45 +0530
Subject: [PATCH v9 6/7] arm64: dts: ti: k3-j721e-sk: Add TPS6594 family
 PMICs
In-Reply-To: <20231207134912.olfhmcz5kkbx47wo@landmine>
References: <20231205093439.2298296-1-n-francis@ti.com>
 <20231205093439.2298296-7-n-francis@ti.com>
 <20231205151647.vh6rlhro7qlwoerc@knelt>
 <5e22f8cb-1004-4bcc-9bd0-2c30180ba10e@ti.com>
 <cc2c3e97-e2c6-487b-91a5-c5f5fbe2c3bc@ti.com>
 <20231207134912.olfhmcz5kkbx47wo@landmine>
Message-ID: <35402c39-a089-404c-a1da-5b398ede793a@ti.com>

Hi Nishanth

On 07/12/23 19:19, Nishanth Menon wrote:
> On 11:01-20231207, Neha Malcom Francis wrote:
>> Hi Nishanth, Udit,
>>
>> On 07/12/23 10:12, Kumar, Udit wrote:
>>>
>>> On 12/5/2023 8:46 PM, Nishanth Menon wrote:
>>>> On 15:04-20231205, Neha Malcom Francis wrote:
>>>>> This patch adds support for TPS6594 PMIC family on wakeup I2C0 bus.
>>>>> These devices provide regulators (bucks and LDOs), but also GPIOs, a
>>>>> RTC, a watchdog, an ESM (Error Signal Monitor) which monitors the SoC
>>>>> error output signal, and a PFSM (Pre-configurable Finite State Machine)
>>>>> which manages the operational modes of the PMIC.
>>>>>
>>>>> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
>>>>> ---
>>>>>  ? arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 158 +++++++++++++++++++++++++
>>>>>  ? 1 file changed, 158 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>>>>> b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>>>>> index 42fe8eee9ec8..e600825f7e78 100644
>>>>> --- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>>>>> +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
>>>>> @@ -459,6 +459,13 @@ J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3)
>>>>> EXT_REFCLK1.GPIO1_12 */
>>>>>  ? };
>>>>>  ? &wkup_pmx0 {
>>>>> +??? pmic_irq_pins_default: pmic-irq-default-pins {
>>>>> +??????? bootph-pre-ram;
>>>>> +??????? pinctrl-single,pins = <
>>>>> +??????????? J721E_WKUP_IOPAD(0x0cc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
>>>>> +??????? >;
>>>>> +??? };
>>>>> +
>>>>>  ????? mcu_cpsw_pins_default: mcu-cpsw-default-pins {
>>>>>  ????????? pinctrl-single,pins = <
>>>>>  ????????????? J721E_WKUP_IOPAD(0x84, PIN_INPUT, 0) /* (B24) MCU_RGMII1_RD0 */
>>>>> @@ -560,6 +567,157 @@ eeprom at 51 {
>>>>>  ????????? compatible = "atmel,24c512";
>>>>>  ????????? reg = <0x51>;
>>>>>  ????? };
>>>>> +
>>>>> +??? tps659413: pmic at 48 {
>>>>> +??????? bootph-pre-ram;
>>>> only for the leaf nodes. See
>>>> https://libera.irclog.whitequark.org/armlinux/2023-10-19
>>>
>>>
>>> AFAIK, please correct me, u-boot still needs in all nodes ?
>>>
>>
>> That's what I believe as well, is it better to have only the leaf nodes in
>> kernel and have U-Boot DTSI handle the parent bootph properties? If so I'll
>> send out v10 making change accordingly.
>>
> 
> Yes, u-boot today needs it in all nodes. BUT, u-boot needs to be fixed in
> line to obey the rules of the schema convention that Rob clarified in
> the discussion above.
> 
> The other choice is NOT to introduce new bootph properties till u-boot
> is fixed up (this is also why I haven't sent out further updates for
> bootph properties for kernel in this cycle).
> 

I think we can have it following kernel convention here and fix up in the U-Boot 
DTSI for this series since PMIC nodes are needed. Thanks!

-- 
Thanking You
Neha Malcom Francis


From anshuman.khandual at arm.com  Thu Dec  7 21:39:32 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:32 +0530
Subject: [PATCH V3 03/10] coresight: Add helpers registering/removing both AMBA and platform drivers
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-4-anshuman.khandual@arm.com>

This adds two different helpers i.e coresight_init_driver()/remove_driver()
enabling coresight devices to register or remove AMBA and platform drivers.

Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: Leo Yan <leo.yan at linaro.org>
Cc: Alexander Shishkin <alexander.shishkin at linux.intel.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: coresight at lists.linaro.org
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- New patch in the series

 drivers/hwtracing/coresight/coresight-core.c | 29 ++++++++++++++++++++
 include/linux/coresight.h                    |  7 +++++
 2 files changed, 36 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 9fabe00a40d6..ede9b0723f95 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1833,6 +1833,35 @@ static void __exit coresight_exit(void)
 module_init(coresight_init);
 module_exit(coresight_exit);
 
+int coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
+			  struct platform_driver *pdev_drv)
+{
+	int ret;
+
+	ret = amba_driver_register(amba_drv);
+	if (ret) {
+		pr_err("%s: error registering AMBA driver\n", drv);
+		return ret;
+	}
+
+	ret = platform_driver_register(pdev_drv);
+	if (!ret)
+		return 0;
+
+	pr_err("%s: error registering platform driver\n", drv);
+	amba_driver_unregister(amba_drv);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(coresight_init_driver);
+
+void coresight_remove_driver(struct amba_driver *amba_drv,
+			     struct platform_driver *pdev_drv)
+{
+	amba_driver_unregister(amba_drv);
+	platform_driver_unregister(pdev_drv);
+}
+EXPORT_SYMBOL_GPL(coresight_remove_driver);
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Pratik Patel <pratikp at codeaurora.org>");
 MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier at linaro.org>");
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index a269fffaf991..be7fe3793763 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -12,6 +12,8 @@
 #include <linux/io.h>
 #include <linux/perf_event.h>
 #include <linux/sched.h>
+#include <linux/amba/bus.h>
+#include <linux/platform_device.h>
 
 /* Peripheral id registers (0xFD0-0xFEC) */
 #define CORESIGHT_PERIPHIDR4	0xfd0
@@ -597,6 +599,11 @@ void coresight_relaxed_write64(struct coresight_device *csdev,
 			       u64 val, u32 offset);
 void coresight_write64(struct coresight_device *csdev, u64 val, u32 offset);
 
+int coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
+			  struct platform_driver *pdev_drv);
+
+void coresight_remove_driver(struct amba_driver *amba_drv,
+			     struct platform_driver *pdev_drv);
 #else
 static inline struct coresight_device *
 coresight_register(struct coresight_desc *desc) { return NULL; }
-- 
2.25.1



From anshuman.khandual at arm.com  Thu Dec  7 21:39:33 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:33 +0530
Subject: [PATCH V3 04/10] coresight: replicator: Move ACPI support from AMBA driver to platform driver
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-5-anshuman.khandual@arm.com>

Add support for the dynamic replicator device in the platform driver, which
can then be used on ACPI based platforms. This change would now allow
runtime power management for repliacator devices on ACPI based systems.

The driver would try to enable the APB clock if available. Also, rename the
code to reflect the fact that it now handles both static and dynamic
replicators.

Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: linux-acpi at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: coresight at lists.linaro.org
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- Added commnets for 'drvdata->pclk'
- Used coresight_init_driver()/coresight_remove_driver() helpers instead
- Dropped pm_runtime_put() from replicator_probe()
- Added pm_runtime_put() on success path in dynamic_replicator_probe()
- Added pm_runtime_put() on success/error paths in
  replicator_platform_probe()

 drivers/acpi/arm64/amba.c                     |  1 -
 .../coresight/coresight-replicator.c          | 81 ++++++++++---------
 2 files changed, 42 insertions(+), 40 deletions(-)

diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
index 171b5c2c7edd..270f4e3819a2 100644
--- a/drivers/acpi/arm64/amba.c
+++ b/drivers/acpi/arm64/amba.c
@@ -27,7 +27,6 @@ static const struct acpi_device_id amba_id_list[] = {
 	{"ARMHC503", 0}, /* ARM CoreSight Debug */
 	{"ARMHC979", 0}, /* ARM CoreSight TPIU */
 	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
-	{"ARMHC98D", 0}, /* ARM CoreSight Dynamic Replicator */
 	{"ARMHC9CA", 0}, /* ARM CoreSight CATU */
 	{"ARMHC9FF", 0}, /* ARM CoreSight Dynamic Funnel */
 	{"", 0},
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index b6be73034996..125b256cb8db 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -31,6 +31,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
  * @base:	memory mapped base address for this component. Also indicates
  *		whether this one is programmable or not.
  * @atclk:	optional clock for the core parts of the replicator.
+ * @pclk:	APB clock if present, otherwise NULL
  * @csdev:	component vitals needed by the framework
  * @spinlock:	serialize enable/disable operations.
  * @check_idfilter_val: check if the context is lost upon clock removal.
@@ -38,6 +39,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
 struct replicator_drvdata {
 	void __iomem		*base;
 	struct clk		*atclk;
+	struct clk		*pclk;
 	struct coresight_device	*csdev;
 	spinlock_t		spinlock;
 	bool			check_idfilter_val;
@@ -243,6 +245,10 @@ static int replicator_probe(struct device *dev, struct resource *res)
 			return ret;
 	}
 
+	drvdata->pclk = coresight_get_enable_apb_pclk(dev);
+	if (IS_ERR(drvdata->pclk))
+		return -ENODEV;
+
 	/*
 	 * Map the device base for dynamic-replicator, which has been
 	 * validated by AMBA core
@@ -285,7 +291,6 @@ static int replicator_probe(struct device *dev, struct resource *res)
 	}
 
 	replicator_reset(drvdata);
-	pm_runtime_put(dev);
 
 out_disable_clk:
 	if (ret && !IS_ERR_OR_NULL(drvdata->atclk))
@@ -301,29 +306,31 @@ static int replicator_remove(struct device *dev)
 	return 0;
 }
 
-static int static_replicator_probe(struct platform_device *pdev)
+static int replicator_platform_probe(struct platform_device *pdev)
 {
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	int ret;
 
 	pm_runtime_get_noresume(&pdev->dev);
 	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
 
-	/* Static replicators do not have programming base */
-	ret = replicator_probe(&pdev->dev, NULL);
-
-	if (ret) {
-		pm_runtime_put_noidle(&pdev->dev);
-		pm_runtime_disable(&pdev->dev);
-	}
+	ret = replicator_probe(&pdev->dev, res);
+	pm_runtime_put(&pdev->dev);
 
 	return ret;
 }
 
-static int static_replicator_remove(struct platform_device *pdev)
+static int replicator_platform_remove(struct platform_device *pdev)
 {
-	replicator_remove(&pdev->dev);
+	struct replicator_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
+
+	if (drvdata)
+		replicator_remove(&pdev->dev);
+
 	pm_runtime_disable(&pdev->dev);
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_put(drvdata->pclk);
 	return 0;
 }
 
@@ -335,6 +342,8 @@ static int replicator_runtime_suspend(struct device *dev)
 	if (drvdata && !IS_ERR(drvdata->atclk))
 		clk_disable_unprepare(drvdata->atclk);
 
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_disable_unprepare(drvdata->pclk);
 	return 0;
 }
 
@@ -345,6 +354,8 @@ static int replicator_runtime_resume(struct device *dev)
 	if (drvdata && !IS_ERR(drvdata->atclk))
 		clk_prepare_enable(drvdata->atclk);
 
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_prepare_enable(drvdata->pclk);
 	return 0;
 }
 #endif
@@ -354,31 +365,32 @@ static const struct dev_pm_ops replicator_dev_pm_ops = {
 			   replicator_runtime_resume, NULL)
 };
 
-static const struct of_device_id static_replicator_match[] = {
+static const struct of_device_id replicator_match[] = {
 	{.compatible = "arm,coresight-replicator"},
 	{.compatible = "arm,coresight-static-replicator"},
 	{}
 };
 
-MODULE_DEVICE_TABLE(of, static_replicator_match);
+MODULE_DEVICE_TABLE(of, replicator_match);
 
 #ifdef CONFIG_ACPI
-static const struct acpi_device_id static_replicator_acpi_ids[] = {
+static const struct acpi_device_id replicator_acpi_ids[] = {
 	{"ARMHC985", 0}, /* ARM CoreSight Static Replicator */
+	{"ARMHC98D", 0}, /* ARM CoreSight Dynamic Replicator */
 	{}
 };
 
-MODULE_DEVICE_TABLE(acpi, static_replicator_acpi_ids);
+MODULE_DEVICE_TABLE(acpi, replicator_acpi_ids);
 #endif
 
-static struct platform_driver static_replicator_driver = {
-	.probe          = static_replicator_probe,
-	.remove         = static_replicator_remove,
+static struct platform_driver replicator_driver = {
+	.probe          = replicator_platform_probe,
+	.remove         = replicator_platform_remove,
 	.driver         = {
-		.name   = "coresight-static-replicator",
+		.name   = "coresight-replicator",
 		/* THIS_MODULE is taken care of by platform_driver_register() */
-		.of_match_table = of_match_ptr(static_replicator_match),
-		.acpi_match_table = ACPI_PTR(static_replicator_acpi_ids),
+		.of_match_table = of_match_ptr(replicator_match),
+		.acpi_match_table = ACPI_PTR(replicator_acpi_ids),
 		.pm	= &replicator_dev_pm_ops,
 		.suppress_bind_attrs = true,
 	},
@@ -387,7 +399,13 @@ static struct platform_driver static_replicator_driver = {
 static int dynamic_replicator_probe(struct amba_device *adev,
 				    const struct amba_id *id)
 {
-	return replicator_probe(&adev->dev, &adev->res);
+	int ret;
+
+	ret = replicator_probe(&adev->dev, &adev->res);
+	if (!ret)
+		pm_runtime_put(&adev->dev);
+
+	return ret;
 }
 
 static void dynamic_replicator_remove(struct amba_device *adev)
@@ -417,27 +435,12 @@ static struct amba_driver dynamic_replicator_driver = {
 
 static int __init replicator_init(void)
 {
-	int ret;
-
-	ret = platform_driver_register(&static_replicator_driver);
-	if (ret) {
-		pr_info("Error registering platform driver\n");
-		return ret;
-	}
-
-	ret = amba_driver_register(&dynamic_replicator_driver);
-	if (ret) {
-		pr_info("Error registering amba driver\n");
-		platform_driver_unregister(&static_replicator_driver);
-	}
-
-	return ret;
+	return coresight_init_driver("replicator", &dynamic_replicator_driver, &replicator_driver);
 }
 
 static void __exit replicator_exit(void)
 {
-	platform_driver_unregister(&static_replicator_driver);
-	amba_driver_unregister(&dynamic_replicator_driver);
+	coresight_remove_driver(&dynamic_replicator_driver, &replicator_driver);
 }
 
 module_init(replicator_init);
-- 
2.25.1



From anshuman.khandual at arm.com  Thu Dec  7 21:39:34 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:34 +0530
Subject: [PATCH V3 05/10] coresight: funnel: Move ACPI support from AMBA driver to platform driver
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-6-anshuman.khandual@arm.com>

Add support for the dynamic funnel device in the platform driver, which can
then be used on ACPI based platforms. This change would allow runtime power
management for ACPI based systems.

The driver would try to enable the APB clock if available. Also, rename the
code to reflect the fact that it now handles both static and dynamic
funnels.

Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: linux-acpi at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: coresight at lists.linaro.org
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- Added commnets for 'drvdata->pclk'
- Used coresight_init_driver()/coresight_remove_driver() helpers instead
- Dropped pm_runtime_put() from funnel_probe()
- Added pm_runtime_put() on success path in dynamic_funnel_probe()
- Added pm_runtime_put() on success/error paths in
  funnel_platform_probe()

 drivers/acpi/arm64/amba.c                     |  1 -
 .../hwtracing/coresight/coresight-funnel.c    | 87 ++++++++++---------
 2 files changed, 46 insertions(+), 42 deletions(-)

diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
index 270f4e3819a2..afb6afb66967 100644
--- a/drivers/acpi/arm64/amba.c
+++ b/drivers/acpi/arm64/amba.c
@@ -28,7 +28,6 @@ static const struct acpi_device_id amba_id_list[] = {
 	{"ARMHC979", 0}, /* ARM CoreSight TPIU */
 	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
 	{"ARMHC9CA", 0}, /* ARM CoreSight CATU */
-	{"ARMHC9FF", 0}, /* ARM CoreSight Dynamic Funnel */
 	{"", 0},
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index b8e150e45b27..f92a96872a5e 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -36,6 +36,7 @@ DEFINE_CORESIGHT_DEVLIST(funnel_devs, "funnel");
  * struct funnel_drvdata - specifics associated to a funnel component
  * @base:	memory mapped base address for this component.
  * @atclk:	optional clock for the core parts of the funnel.
+ * @pclk:	APB clock if present, otherwise NULL
  * @csdev:	component vitals needed by the framework.
  * @priority:	port selection order.
  * @spinlock:	serialize enable/disable operations.
@@ -43,6 +44,7 @@ DEFINE_CORESIGHT_DEVLIST(funnel_devs, "funnel");
 struct funnel_drvdata {
 	void __iomem		*base;
 	struct clk		*atclk;
+	struct clk		*pclk;
 	struct coresight_device	*csdev;
 	unsigned long		priority;
 	spinlock_t		spinlock;
@@ -236,6 +238,10 @@ static int funnel_probe(struct device *dev, struct resource *res)
 			return ret;
 	}
 
+	drvdata->pclk = coresight_get_enable_apb_pclk(dev);
+	if (IS_ERR(drvdata->pclk))
+		return -ENODEV;
+
 	/*
 	 * Map the device base for dynamic-funnel, which has been
 	 * validated by AMBA core.
@@ -272,7 +278,6 @@ static int funnel_probe(struct device *dev, struct resource *res)
 		goto out_disable_clk;
 	}
 
-	pm_runtime_put(dev);
 	ret = 0;
 
 out_disable_clk:
@@ -298,6 +303,9 @@ static int funnel_runtime_suspend(struct device *dev)
 	if (drvdata && !IS_ERR(drvdata->atclk))
 		clk_disable_unprepare(drvdata->atclk);
 
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_disable_unprepare(drvdata->pclk);
+
 	return 0;
 }
 
@@ -308,6 +316,8 @@ static int funnel_runtime_resume(struct device *dev)
 	if (drvdata && !IS_ERR(drvdata->atclk))
 		clk_prepare_enable(drvdata->atclk);
 
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_prepare_enable(drvdata->pclk);
 	return 0;
 }
 #endif
@@ -316,56 +326,60 @@ static const struct dev_pm_ops funnel_dev_pm_ops = {
 	SET_RUNTIME_PM_OPS(funnel_runtime_suspend, funnel_runtime_resume, NULL)
 };
 
-static int static_funnel_probe(struct platform_device *pdev)
+static int funnel_platform_probe(struct platform_device *pdev)
 {
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	int ret;
 
 	pm_runtime_get_noresume(&pdev->dev);
 	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
 
-	/* Static funnel do not have programming base */
-	ret = funnel_probe(&pdev->dev, NULL);
-
-	if (ret) {
-		pm_runtime_put_noidle(&pdev->dev);
-		pm_runtime_disable(&pdev->dev);
-	}
+	ret = funnel_probe(&pdev->dev, res);
+	pm_runtime_put(&pdev->dev);
 
 	return ret;
 }
 
-static int static_funnel_remove(struct platform_device *pdev)
+static int funnel_platform_remove(struct platform_device *pdev)
 {
-	funnel_remove(&pdev->dev);
+	struct funnel_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
+
+	if (drvdata)
+		funnel_remove(&pdev->dev);
+
 	pm_runtime_disable(&pdev->dev);
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_put(drvdata->pclk);
+
 	return 0;
 }
 
-static const struct of_device_id static_funnel_match[] = {
+static const struct of_device_id funnel_match[] = {
 	{.compatible = "arm,coresight-static-funnel"},
 	{}
 };
 
-MODULE_DEVICE_TABLE(of, static_funnel_match);
+MODULE_DEVICE_TABLE(of, funnel_match);
 
 #ifdef CONFIG_ACPI
-static const struct acpi_device_id static_funnel_ids[] = {
-	{"ARMHC9FE", 0},
+static const struct acpi_device_id funnel_acpi_ids[] = {
+	{"ARMHC9FE", 0}, /* ARM Coresight Static Funnel */
+	{"ARMHC9FF", 0}, /* ARM CoreSight Dynamic Funnel */
 	{},
 };
 
-MODULE_DEVICE_TABLE(acpi, static_funnel_ids);
+MODULE_DEVICE_TABLE(acpi, funnel_acpi_ids);
 #endif
 
-static struct platform_driver static_funnel_driver = {
-	.probe          = static_funnel_probe,
-	.remove          = static_funnel_remove,
-	.driver         = {
-		.name   = "coresight-static-funnel",
+static struct platform_driver funnel_driver = {
+	.probe	= funnel_platform_probe,
+	.remove	= funnel_platform_remove,
+	.driver	= {
+		.name   = "coresight-funnel",
 		/* THIS_MODULE is taken care of by platform_driver_register() */
-		.of_match_table = static_funnel_match,
-		.acpi_match_table = ACPI_PTR(static_funnel_ids),
+		.of_match_table = funnel_match,
+		.acpi_match_table = ACPI_PTR(funnel_acpi_ids),
 		.pm	= &funnel_dev_pm_ops,
 		.suppress_bind_attrs = true,
 	},
@@ -374,7 +388,13 @@ static struct platform_driver static_funnel_driver = {
 static int dynamic_funnel_probe(struct amba_device *adev,
 				const struct amba_id *id)
 {
-	return funnel_probe(&adev->dev, &adev->res);
+	int ret;
+
+	ret = funnel_probe(&adev->dev, &adev->res);
+	if (!ret)
+		pm_runtime_put(&adev->dev);
+
+	return ret;
 }
 
 static void dynamic_funnel_remove(struct amba_device *adev)
@@ -411,27 +431,12 @@ static struct amba_driver dynamic_funnel_driver = {
 
 static int __init funnel_init(void)
 {
-	int ret;
-
-	ret = platform_driver_register(&static_funnel_driver);
-	if (ret) {
-		pr_info("Error registering platform driver\n");
-		return ret;
-	}
-
-	ret = amba_driver_register(&dynamic_funnel_driver);
-	if (ret) {
-		pr_info("Error registering amba driver\n");
-		platform_driver_unregister(&static_funnel_driver);
-	}
-
-	return ret;
+	return coresight_init_driver("funnel", &dynamic_funnel_driver, &funnel_driver);
 }
 
 static void __exit funnel_exit(void)
 {
-	platform_driver_unregister(&static_funnel_driver);
-	amba_driver_unregister(&dynamic_funnel_driver);
+	coresight_remove_driver(&dynamic_funnel_driver, &funnel_driver);
 }
 
 module_init(funnel_init);
-- 
2.25.1



From anshuman.khandual at arm.com  Thu Dec  7 21:39:35 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:35 +0530
Subject: [PATCH V3 06/10] coresight: catu: Move ACPI support from AMBA driver to platform driver
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-7-anshuman.khandual@arm.com>

Add support for the catu devices in a new platform driver, which can then
be used on ACPI based platforms. This change would now allow runtime power
management for ACPI based systems. The driver would try to enable the APB
clock if available.

Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: linux-acpi at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: coresight at lists.linaro.org
Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- Added commnets for 'drvdata->pclk'
- Used coresight_init_driver()/coresight_remove_driver() helpers instead
- Dropped pm_runtime_put() from __catu_probe()
- Added pm_runtime_put() on success path in catu_probe()
- Added pm_runtime_put() on success/error paths in catu_platform_probe()
- Moved out coresight_init_driver()/coresight_remove_driver() helpers
- Check for drvdata instead of drvdata->pclk in suspend and resume paths

 drivers/acpi/arm64/amba.c                    |   1 -
 drivers/hwtracing/coresight/coresight-catu.c | 140 ++++++++++++++++---
 drivers/hwtracing/coresight/coresight-catu.h |   1 +
 3 files changed, 122 insertions(+), 20 deletions(-)

diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
index afb6afb66967..587061b0fd2f 100644
--- a/drivers/acpi/arm64/amba.c
+++ b/drivers/acpi/arm64/amba.c
@@ -27,7 +27,6 @@ static const struct acpi_device_id amba_id_list[] = {
 	{"ARMHC503", 0}, /* ARM CoreSight Debug */
 	{"ARMHC979", 0}, /* ARM CoreSight TPIU */
 	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
-	{"ARMHC9CA", 0}, /* ARM CoreSight CATU */
 	{"", 0},
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
index 3949ded0d4fa..daea7c6ba959 100644
--- a/drivers/hwtracing/coresight/coresight-catu.c
+++ b/drivers/hwtracing/coresight/coresight-catu.c
@@ -7,6 +7,8 @@
  * Author: Suzuki K Poulose <suzuki.poulose at arm.com>
  */
 
+#include <linux/platform_device.h>
+#include <linux/acpi.h>
 #include <linux/amba/bus.h>
 #include <linux/device.h>
 #include <linux/dma-mapping.h>
@@ -502,28 +504,20 @@ static const struct coresight_ops catu_ops = {
 	.helper_ops = &catu_helper_ops,
 };
 
-static int catu_probe(struct amba_device *adev, const struct amba_id *id)
+static int __catu_probe(struct device *dev, struct resource *res)
 {
 	int ret = 0;
 	u32 dma_mask;
-	struct catu_drvdata *drvdata;
+	struct catu_drvdata *drvdata = dev_get_drvdata(dev);
 	struct coresight_desc catu_desc;
 	struct coresight_platform_data *pdata = NULL;
-	struct device *dev = &adev->dev;
 	void __iomem *base;
 
 	catu_desc.name = coresight_alloc_device_name(&catu_devs, dev);
 	if (!catu_desc.name)
 		return -ENOMEM;
 
-	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
-	if (!drvdata) {
-		ret = -ENOMEM;
-		goto out;
-	}
-
-	dev_set_drvdata(dev, drvdata);
-	base = devm_ioremap_resource(dev, &adev->res);
+	base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(base)) {
 		ret = PTR_ERR(base);
 		goto out;
@@ -567,19 +561,39 @@ static int catu_probe(struct amba_device *adev, const struct amba_id *id)
 	drvdata->csdev = coresight_register(&catu_desc);
 	if (IS_ERR(drvdata->csdev))
 		ret = PTR_ERR(drvdata->csdev);
-	else
-		pm_runtime_put(&adev->dev);
 out:
 	return ret;
 }
 
-static void catu_remove(struct amba_device *adev)
+static int catu_probe(struct amba_device *adev, const struct amba_id *id)
+{
+	struct catu_drvdata *drvdata;
+	int ret;
+
+	drvdata = devm_kzalloc(&adev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	amba_set_drvdata(adev, drvdata);
+	ret = __catu_probe(&adev->dev, &adev->res);
+	if (!ret)
+		pm_runtime_put(&adev->dev);
+
+	return ret;
+}
+
+static void __catu_remove(struct device *dev)
 {
-	struct catu_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+	struct catu_drvdata *drvdata = dev_get_drvdata(dev);
 
 	coresight_unregister(drvdata->csdev);
 }
 
+static void catu_remove(struct amba_device *adev)
+{
+	__catu_remove(&adev->dev);
+}
+
 static struct amba_id catu_ids[] = {
 	CS_AMBA_ID(0x000bb9ee),
 	{},
@@ -598,13 +612,101 @@ static struct amba_driver catu_driver = {
 	.id_table			= catu_ids,
 };
 
+static int catu_platform_probe(struct platform_device *pdev)
+{
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	struct catu_drvdata *drvdata;
+	int ret = 0;
+
+	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
+	if (IS_ERR(drvdata->pclk))
+		return -ENODEV;
+
+	if (res) {
+		drvdata->base = devm_ioremap_resource(&pdev->dev, res);
+		if (IS_ERR(drvdata->base)) {
+			clk_put(drvdata->pclk);
+			return PTR_ERR(drvdata->base);
+		}
+	}
+
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
+	dev_set_drvdata(&pdev->dev, drvdata);
+	ret = __catu_probe(&pdev->dev, res);
+	pm_runtime_put(&pdev->dev);
+
+	return ret;
+}
+
+static int catu_platform_remove(struct platform_device *pdev)
+{
+	struct catu_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
+
+	if (drvdata)
+		__catu_remove(&pdev->dev);
+
+	pm_runtime_disable(&pdev->dev);
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_put(drvdata->pclk);
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int catu_runtime_suspend(struct device *dev)
+{
+	struct catu_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_disable_unprepare(drvdata->pclk);
+	return 0;
+}
+
+static int catu_runtime_resume(struct device *dev)
+{
+	struct catu_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_prepare_enable(drvdata->pclk);
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops catu_dev_pm_ops = {
+	SET_RUNTIME_PM_OPS(catu_runtime_suspend, catu_runtime_resume, NULL)
+};
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id catu_acpi_ids[] = {
+	{"ARMHC9CA", 0}, /* ARM CoreSight CATU */
+	{},
+};
+
+MODULE_DEVICE_TABLE(acpi, catu_acpi_ids);
+#endif
+
+static struct platform_driver catu_platform_driver = {
+	.probe	= catu_platform_probe,
+	.remove	= catu_platform_remove,
+	.driver	= {
+		.name			= "coresight-catu-platform",
+		.acpi_match_table	= ACPI_PTR(catu_acpi_ids),
+		.suppress_bind_attrs	= true,
+		.pm			= &catu_dev_pm_ops,
+	},
+};
+
 static int __init catu_init(void)
 {
 	int ret;
 
-	ret = amba_driver_register(&catu_driver);
-	if (ret)
-		pr_info("Error registering catu driver\n");
+	ret = coresight_init_driver("catu", &catu_driver, &catu_platform_driver);
 	tmc_etr_set_catu_ops(&etr_catu_buf_ops);
 	return ret;
 }
@@ -612,7 +714,7 @@ static int __init catu_init(void)
 static void __exit catu_exit(void)
 {
 	tmc_etr_remove_catu_ops();
-	amba_driver_unregister(&catu_driver);
+	coresight_remove_driver(&catu_driver, &catu_platform_driver);
 }
 
 module_init(catu_init);
diff --git a/drivers/hwtracing/coresight/coresight-catu.h b/drivers/hwtracing/coresight/coresight-catu.h
index 442e034bbfba..141feac1c14b 100644
--- a/drivers/hwtracing/coresight/coresight-catu.h
+++ b/drivers/hwtracing/coresight/coresight-catu.h
@@ -61,6 +61,7 @@
 #define CATU_IRQEN_OFF		0x0
 
 struct catu_drvdata {
+	struct clk *pclk;
 	void __iomem *base;
 	struct coresight_device *csdev;
 	int irq;
-- 
2.25.1



From anshuman.khandual at arm.com  Thu Dec  7 21:39:36 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:36 +0530
Subject: [PATCH V3 07/10] coresight: tpiu: Move ACPI support from AMBA driver to platform driver
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-8-anshuman.khandual@arm.com>

Add support for the tpiu device in the platform driver, which can then be
used on ACPI based platforms. This change would now allow runtime power
management for ACPI based systems. The driver would try to enable the APB
clock if available.

Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: linux-acpi at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: coresight at lists.linaro.org
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- Added commnets for 'drvdata->pclk'
- Used coresight_init_driver()/coresight_remove_driver() helpers instead
- Dropped pm_runtime_put() from __tpiu_probe()
- Added pm_runtime_put() on success path in tpiu_probe()
- Added pm_runtime_put() on success/error paths in tpiu_platform_probe()

 drivers/acpi/arm64/amba.c                    |  1 -
 drivers/hwtracing/coresight/coresight-tpiu.c | 99 ++++++++++++++++++--
 2 files changed, 89 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
index 587061b0fd2f..6d24a8f7914b 100644
--- a/drivers/acpi/arm64/amba.c
+++ b/drivers/acpi/arm64/amba.c
@@ -25,7 +25,6 @@ static const struct acpi_device_id amba_id_list[] = {
 	{"ARMHC501", 0}, /* ARM CoreSight ETR */
 	{"ARMHC502", 0}, /* ARM CoreSight STM */
 	{"ARMHC503", 0}, /* ARM CoreSight Debug */
-	{"ARMHC979", 0}, /* ARM CoreSight TPIU */
 	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
 	{"", 0},
 };
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 59eac93fd6bb..ddb214838239 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -5,6 +5,8 @@
  * Description: CoreSight Trace Port Interface Unit driver
  */
 
+#include <linux/platform_device.h>
+#include <linux/acpi.h>
 #include <linux/atomic.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
@@ -52,11 +54,13 @@ DEFINE_CORESIGHT_DEVLIST(tpiu_devs, "tpiu");
 /*
  * @base:	memory mapped base address for this component.
  * @atclk:	optional clock for the core parts of the TPIU.
+ * @pclk:	APB clock if present, otherwise NULL
  * @csdev:	component vitals needed by the framework.
  */
 struct tpiu_drvdata {
 	void __iomem		*base;
 	struct clk		*atclk;
+	struct clk		*pclk;
 	struct coresight_device	*csdev;
 };
 
@@ -114,14 +118,12 @@ static const struct coresight_ops tpiu_cs_ops = {
 	.sink_ops	= &tpiu_sink_ops,
 };
 
-static int tpiu_probe(struct amba_device *adev, const struct amba_id *id)
+static int __tpiu_probe(struct device *dev, struct resource *res)
 {
 	int ret;
 	void __iomem *base;
-	struct device *dev = &adev->dev;
 	struct coresight_platform_data *pdata = NULL;
 	struct tpiu_drvdata *drvdata;
-	struct resource *res = &adev->res;
 	struct coresight_desc desc = { 0 };
 
 	desc.name = coresight_alloc_device_name(&tpiu_devs, dev);
@@ -132,12 +134,16 @@ static int tpiu_probe(struct amba_device *adev, const struct amba_id *id)
 	if (!drvdata)
 		return -ENOMEM;
 
-	drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
+	drvdata->atclk = devm_clk_get(dev, "atclk"); /* optional */
 	if (!IS_ERR(drvdata->atclk)) {
 		ret = clk_prepare_enable(drvdata->atclk);
 		if (ret)
 			return ret;
 	}
+
+	drvdata->pclk = coresight_get_enable_apb_pclk(dev);
+	if (IS_ERR(drvdata->pclk))
+		return -ENODEV;
 	dev_set_drvdata(dev, drvdata);
 
 	/* Validity for the resource is already checked by the AMBA core */
@@ -163,21 +169,34 @@ static int tpiu_probe(struct amba_device *adev, const struct amba_id *id)
 	desc.dev = dev;
 	drvdata->csdev = coresight_register(&desc);
 
-	if (!IS_ERR(drvdata->csdev)) {
-		pm_runtime_put(&adev->dev);
+	if (!IS_ERR(drvdata->csdev))
 		return 0;
-	}
 
 	return PTR_ERR(drvdata->csdev);
 }
 
-static void tpiu_remove(struct amba_device *adev)
+static int tpiu_probe(struct amba_device *adev, const struct amba_id *id)
+{
+	int ret;
+
+	ret = __tpiu_probe(&adev->dev, &adev->res);
+	if (!ret)
+		pm_runtime_put(&adev->dev);
+	return ret;
+}
+
+static void __tpiu_remove(struct device *dev)
 {
-	struct tpiu_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+	struct tpiu_drvdata *drvdata = dev_get_drvdata(dev);
 
 	coresight_unregister(drvdata->csdev);
 }
 
+static void tpiu_remove(struct amba_device *adev)
+{
+	__tpiu_remove(&adev->dev);
+}
+
 #ifdef CONFIG_PM
 static int tpiu_runtime_suspend(struct device *dev)
 {
@@ -186,6 +205,8 @@ static int tpiu_runtime_suspend(struct device *dev)
 	if (drvdata && !IS_ERR(drvdata->atclk))
 		clk_disable_unprepare(drvdata->atclk);
 
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_disable_unprepare(drvdata->pclk);
 	return 0;
 }
 
@@ -196,6 +217,8 @@ static int tpiu_runtime_resume(struct device *dev)
 	if (drvdata && !IS_ERR(drvdata->atclk))
 		clk_prepare_enable(drvdata->atclk);
 
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_prepare_enable(drvdata->pclk);
 	return 0;
 }
 #endif
@@ -235,7 +258,63 @@ static struct amba_driver tpiu_driver = {
 	.id_table	= tpiu_ids,
 };
 
-module_amba_driver(tpiu_driver);
+static int tpiu_platform_probe(struct platform_device *pdev)
+{
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	int ret;
+
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
+	ret = __tpiu_probe(&pdev->dev, res);
+	pm_runtime_put(&pdev->dev);
+	return ret;
+}
+
+static int tpiu_platform_remove(struct platform_device *pdev)
+{
+	struct tpiu_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
+
+	if (drvdata)
+		__tpiu_remove(&pdev->dev);
+
+	pm_runtime_disable(&pdev->dev);
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_put(drvdata->pclk);
+	return 0;
+}
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id tpiu_acpi_ids[] = {
+	{"ARMHC979", 0}, /* ARM CoreSight TPIU */
+	{}
+};
+MODULE_DEVICE_TABLE(acpi, tpiu_acpi_ids);
+#endif
+
+static struct platform_driver tpiu_platform_driver = {
+	.probe	= tpiu_platform_probe,
+	.remove	= tpiu_platform_remove,
+	.driver = {
+		.name			= "coresight-tpiu-platform",
+		.acpi_match_table	= ACPI_PTR(tpiu_acpi_ids),
+		.suppress_bind_attrs	= true,
+		.pm			= &tpiu_dev_pm_ops,
+	},
+};
+
+static int __init tpiu_init(void)
+{
+	return coresight_init_driver("tpiu", &tpiu_driver, &tpiu_platform_driver);
+}
+
+static void __exit tpiu_exit(void)
+{
+	coresight_remove_driver(&tpiu_driver, &tpiu_platform_driver);
+}
+module_init(tpiu_init);
+module_exit(tpiu_exit);
 
 MODULE_AUTHOR("Pratik Patel <pratikp at codeaurora.org>");
 MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier at linaro.org>");
-- 
2.25.1



From anshuman.khandual at arm.com  Thu Dec  7 21:39:37 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:37 +0530
Subject: [PATCH V3 08/10] coresight: tmc: Move ACPI support from AMBA driver to platform driver
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-9-anshuman.khandual@arm.com>

Add support for the tmc devices in the platform driver, which can then be
used on ACPI based platforms. This change would now allow runtime power
management for ACPI based systems. The driver would try to enable the APB
clock if available.

Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: linux-acpi at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: coresight at lists.linaro.org
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- Added commnets for 'drvdata->pclk'
- Used coresight_init_driver()/coresight_remove_driver() helpers instead
- Dropped pm_runtime_put() from __tmc_probe()
- Added pm_runtime_put() on success path in tmc_probe()
- Added pm_runtime_put() on success/error paths in tmc_platform_probe()
- Check for drvdata instead of drvdata->pclk in suspend and resume paths

 drivers/acpi/arm64/amba.c                     |   2 -
 .../hwtracing/coresight/coresight-tmc-core.c  | 137 ++++++++++++++++--
 drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
 3 files changed, 124 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
index 6d24a8f7914b..d3c1defa7bc8 100644
--- a/drivers/acpi/arm64/amba.c
+++ b/drivers/acpi/arm64/amba.c
@@ -22,10 +22,8 @@
 static const struct acpi_device_id amba_id_list[] = {
 	{"ARMH0061", 0}, /* PL061 GPIO Device */
 	{"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
-	{"ARMHC501", 0}, /* ARM CoreSight ETR */
 	{"ARMHC502", 0}, /* ARM CoreSight STM */
 	{"ARMHC503", 0}, /* ARM CoreSight Debug */
-	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
 	{"", 0},
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index ad61d02f5f75..8482830d73ef 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -23,6 +23,8 @@
 #include <linux/of.h>
 #include <linux/coresight.h>
 #include <linux/amba/bus.h>
+#include <linux/platform_device.h>
+#include <linux/acpi.h>
 
 #include "coresight-priv.h"
 #include "coresight-tmc.h"
@@ -437,24 +439,17 @@ static u32 tmc_etr_get_max_burst_size(struct device *dev)
 	return burst_size;
 }
 
-static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
+static int __tmc_probe(struct device *dev, struct resource *res, void *dev_caps)
 {
 	int ret = 0;
 	u32 devid;
 	void __iomem *base;
-	struct device *dev = &adev->dev;
 	struct coresight_platform_data *pdata = NULL;
-	struct tmc_drvdata *drvdata;
-	struct resource *res = &adev->res;
+	struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
 	struct coresight_desc desc = { 0 };
 	struct coresight_dev_list *dev_list = NULL;
 
 	ret = -ENOMEM;
-	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
-	if (!drvdata)
-		goto out;
-
-	dev_set_drvdata(dev, drvdata);
 
 	/* Validity for the resource is already checked by the AMBA core */
 	base = devm_ioremap_resource(dev, res);
@@ -523,7 +518,7 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
 		ret = PTR_ERR(pdata);
 		goto out;
 	}
-	adev->dev.platform_data = pdata;
+	dev->platform_data = pdata;
 	desc.pdata = pdata;
 
 	drvdata->csdev = coresight_register(&desc);
@@ -541,12 +536,27 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
 	ret = misc_register(&drvdata->miscdev);
 	if (ret)
 		coresight_unregister(drvdata->csdev);
-	else
-		pm_runtime_put(&adev->dev);
 out:
 	return ret;
 }
 
+static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
+{
+	struct tmc_drvdata *drvdata;
+	int ret;
+
+	drvdata = devm_kzalloc(&adev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	amba_set_drvdata(adev, drvdata);
+	ret = __tmc_probe(&adev->dev, &adev->res, coresight_get_uci_data(id));
+	if (!ret)
+		pm_runtime_put(&adev->dev);
+
+	return ret;
+}
+
 static void tmc_shutdown(struct amba_device *adev)
 {
 	unsigned long flags;
@@ -569,9 +579,9 @@ static void tmc_shutdown(struct amba_device *adev)
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 }
 
-static void tmc_remove(struct amba_device *adev)
+static void __tmc_remove(struct device *dev)
 {
-	struct tmc_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+	struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
 
 	/*
 	 * Since misc_open() holds a refcount on the f_ops, which is
@@ -582,6 +592,11 @@ static void tmc_remove(struct amba_device *adev)
 	coresight_unregister(drvdata->csdev);
 }
 
+static void tmc_remove(struct amba_device *adev)
+{
+	__tmc_remove(&adev->dev);
+}
+
 static const struct amba_id tmc_ids[] = {
 	CS_AMBA_ID(0x000bb961),
 	/* Coresight SoC 600 TMC-ETR/ETS */
@@ -607,7 +622,99 @@ static struct amba_driver tmc_driver = {
 	.id_table	= tmc_ids,
 };
 
-module_amba_driver(tmc_driver);
+static int tmc_platform_probe(struct platform_device *pdev)
+{
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	struct tmc_drvdata *drvdata;
+	int ret = 0;
+
+	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
+	if (IS_ERR(drvdata->pclk))
+		return -ENODEV;
+
+	dev_set_drvdata(&pdev->dev, drvdata);
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
+	ret = __tmc_probe(&pdev->dev, res, NULL);
+	pm_runtime_put(&pdev->dev);
+
+	return ret;
+}
+
+static int tmc_platform_remove(struct platform_device *pdev)
+{
+	struct tmc_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
+
+	if (drvdata)
+		__tmc_remove(&pdev->dev);
+
+	pm_runtime_disable(&pdev->dev);
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_put(drvdata->pclk);
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int tmc_runtime_suspend(struct device *dev)
+{
+	struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_disable_unprepare(drvdata->pclk);
+	return 0;
+}
+
+static int tmc_runtime_resume(struct device *dev)
+{
+	struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_prepare_enable(drvdata->pclk);
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops tmc_dev_pm_ops = {
+	SET_RUNTIME_PM_OPS(tmc_runtime_suspend, tmc_runtime_resume, NULL)
+};
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id tmc_acpi_ids[] = {
+	{"ARMHC501", 0}, /* ARM CoreSight ETR */
+	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
+	{},
+};
+MODULE_DEVICE_TABLE(acpi, tmc_acpi_ids);
+#endif
+
+static struct platform_driver tmc_platform_driver = {
+	.probe	= tmc_platform_probe,
+	.remove	= tmc_platform_remove,
+	.driver	= {
+		.name			= "coresight-tmc-platform",
+		.acpi_match_table	= ACPI_PTR(tmc_acpi_ids),
+		.suppress_bind_attrs	= true,
+		.pm			= &tmc_dev_pm_ops,
+	},
+};
+
+static int __init tmc_init(void)
+{
+	return coresight_init_driver("tmc", &tmc_driver, &tmc_platform_driver);
+}
+
+static void __exit tmc_exit(void)
+{
+	coresight_remove_driver(&tmc_driver, &tmc_platform_driver);
+}
+module_init(tmc_init);
+module_exit(tmc_exit);
 
 MODULE_AUTHOR("Pratik Patel <pratikp at codeaurora.org>");
 MODULE_DESCRIPTION("Arm CoreSight Trace Memory Controller driver");
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index 0ee48c5ba764..072befcf21cf 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -165,6 +165,7 @@ struct etr_buf {
 
 /**
  * struct tmc_drvdata - specifics associated to an TMC component
+ * @pclk:	APB clock if present, otherwise NULL
  * @base:	memory mapped base address for this component.
  * @csdev:	component vitals needed by the framework.
  * @miscdev:	specifics to handle "/dev/xyz.tmc" entry.
@@ -189,6 +190,7 @@ struct etr_buf {
  * @perf_buf:	PERF buffer for ETR.
  */
 struct tmc_drvdata {
+	struct clk		*pclk;
 	void __iomem		*base;
 	struct coresight_device	*csdev;
 	struct miscdevice	miscdev;
-- 
2.25.1



From anshuman.khandual at arm.com  Thu Dec  7 21:39:38 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:38 +0530
Subject: [PATCH V3 09/10] coresight: stm: Move ACPI support from AMBA driver to platform driver
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-10-anshuman.khandual@arm.com>

Add support for the stm devices in the platform driver, which can then be
used on ACPI based platforms. This change would now allow runtime power
management for ACPI based systems. The driver would try to enable the APB
clock if available.

Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: linux-acpi at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: coresight at lists.linaro.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- Added commnets for 'drvdata->pclk'
- Used coresight_init_driver()/coresight_remove_driver() helpers instead
- Dropped pm_runtime_put() from __stm_probe()
- Added pm_runtime_put() on success path in stm_probe()
- Added pm_runtime_put() on success/error paths in stm_platform_probe()

 drivers/acpi/arm64/amba.c                   |   1 -
 drivers/hwtracing/coresight/coresight-stm.c | 101 ++++++++++++++++++--
 2 files changed, 91 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
index d3c1defa7bc8..bec0976541da 100644
--- a/drivers/acpi/arm64/amba.c
+++ b/drivers/acpi/arm64/amba.c
@@ -22,7 +22,6 @@
 static const struct acpi_device_id amba_id_list[] = {
 	{"ARMH0061", 0}, /* PL061 GPIO Device */
 	{"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
-	{"ARMHC502", 0}, /* ARM CoreSight STM */
 	{"ARMHC503", 0}, /* ARM CoreSight Debug */
 	{"", 0},
 };
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index 9cdca4f86cab..a5f1da1e230e 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -29,6 +29,8 @@
 #include <linux/perf_event.h>
 #include <linux/pm_runtime.h>
 #include <linux/stm.h>
+#include <linux/platform_device.h>
+#include <linux/acpi.h>
 
 #include "coresight-priv.h"
 #include "coresight-trace-id.h"
@@ -115,6 +117,7 @@ DEFINE_CORESIGHT_DEVLIST(stm_devs, "stm");
  * struct stm_drvdata - specifics associated to an STM component
  * @base:		memory mapped base address for this component.
  * @atclk:		optional clock for the core parts of the STM.
+ * @pclk:		APB clock if present, otherwise NULL
  * @csdev:		component vitals needed by the framework.
  * @spinlock:		only one at a time pls.
  * @chs:		the channels accociated to this STM.
@@ -132,6 +135,7 @@ DEFINE_CORESIGHT_DEVLIST(stm_devs, "stm");
 struct stm_drvdata {
 	void __iomem		*base;
 	struct clk		*atclk;
+	struct clk		*pclk;
 	struct coresight_device	*csdev;
 	spinlock_t		spinlock;
 	struct channel_space	chs;
@@ -816,14 +820,12 @@ static char *stm_csdev_name(struct coresight_device *csdev)
 	return uci_data ? (char *)uci_data : "STM";
 }
 
-static int stm_probe(struct amba_device *adev, const struct amba_id *id)
+static int __stm_probe(struct device *dev, struct resource *res)
 {
 	int ret, trace_id;
 	void __iomem *base;
-	struct device *dev = &adev->dev;
 	struct coresight_platform_data *pdata = NULL;
 	struct stm_drvdata *drvdata;
-	struct resource *res = &adev->res;
 	struct resource ch_res;
 	struct coresight_desc desc = { 0 };
 
@@ -835,12 +837,16 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id)
 	if (!drvdata)
 		return -ENOMEM;
 
-	drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
+	drvdata->atclk = devm_clk_get(dev, "atclk"); /* optional */
 	if (!IS_ERR(drvdata->atclk)) {
 		ret = clk_prepare_enable(drvdata->atclk);
 		if (ret)
 			return ret;
 	}
+
+	drvdata->pclk = coresight_get_enable_apb_pclk(dev);
+	if (IS_ERR(drvdata->pclk))
+		return -ENODEV;
 	dev_set_drvdata(dev, drvdata);
 
 	base = devm_ioremap_resource(dev, res);
@@ -888,7 +894,7 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id)
 		ret = PTR_ERR(pdata);
 		goto stm_unregister;
 	}
-	adev->dev.platform_data = pdata;
+	dev->platform_data = pdata;
 
 	desc.type = CORESIGHT_DEV_TYPE_SOURCE;
 	desc.subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE;
@@ -909,8 +915,6 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id)
 	}
 	drvdata->traceid = (u8)trace_id;
 
-	pm_runtime_put(&adev->dev);
-
 	dev_info(&drvdata->csdev->dev, "%s initialized\n",
 		 stm_csdev_name(drvdata->csdev));
 	return 0;
@@ -923,9 +927,20 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id)
 	return ret;
 }
 
-static void stm_remove(struct amba_device *adev)
+static int stm_probe(struct amba_device *adev, const struct amba_id *id)
+{
+	int ret;
+
+	ret = __stm_probe(&adev->dev, &adev->res);
+	if (!ret)
+		pm_runtime_put(&adev->dev);
+
+	return ret;
+}
+
+static void __stm_remove(struct device *dev)
 {
-	struct stm_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev);
 
 	coresight_trace_id_put_system_id(drvdata->traceid);
 	coresight_unregister(drvdata->csdev);
@@ -933,6 +948,11 @@ static void stm_remove(struct amba_device *adev)
 	stm_unregister_device(&drvdata->stm);
 }
 
+static void stm_remove(struct amba_device *adev)
+{
+	__stm_remove(&adev->dev);
+}
+
 #ifdef CONFIG_PM
 static int stm_runtime_suspend(struct device *dev)
 {
@@ -941,6 +961,8 @@ static int stm_runtime_suspend(struct device *dev)
 	if (drvdata && !IS_ERR(drvdata->atclk))
 		clk_disable_unprepare(drvdata->atclk);
 
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_disable_unprepare(drvdata->pclk);
 	return 0;
 }
 
@@ -951,6 +973,8 @@ static int stm_runtime_resume(struct device *dev)
 	if (drvdata && !IS_ERR(drvdata->atclk))
 		clk_prepare_enable(drvdata->atclk);
 
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_prepare_enable(drvdata->pclk);
 	return 0;
 }
 #endif
@@ -979,7 +1003,64 @@ static struct amba_driver stm_driver = {
 	.id_table	= stm_ids,
 };
 
-module_amba_driver(stm_driver);
+static int stm_platform_probe(struct platform_device *pdev)
+{
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	int ret = 0;
+
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
+	ret = __stm_probe(&pdev->dev, res);
+	pm_runtime_put(&pdev->dev);
+
+	return ret;
+}
+
+static int stm_platform_remove(struct platform_device *pdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
+
+	if (drvdata)
+		__stm_remove(&pdev->dev);
+
+	pm_runtime_disable(&pdev->dev);
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_put(drvdata->pclk);
+	return 0;
+}
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id stm_acpi_ids[] = {
+	{"ARMHC502", 0}, /* ARM CoreSight STM */
+	{},
+};
+MODULE_DEVICE_TABLE(acpi, stm_acpi_ids);
+#endif
+
+static struct platform_driver stm_platform_driver = {
+	.probe	= stm_platform_probe,
+	.remove	= stm_platform_remove,
+	.driver	= {
+		.name			= "coresight-stm-platform",
+		.acpi_match_table	= ACPI_PTR(stm_acpi_ids),
+		.suppress_bind_attrs	= true,
+		.pm			= &stm_dev_pm_ops,
+	},
+};
+
+static int __init stm_init(void)
+{
+	return coresight_init_driver("stm", &stm_driver, &stm_platform_driver);
+}
+
+static void __exit stm_exit(void)
+{
+	coresight_remove_driver(&stm_driver, &stm_platform_driver);
+}
+module_init(stm_init);
+module_exit(stm_exit);
 
 MODULE_AUTHOR("Pratik Patel <pratikp at codeaurora.org>");
 MODULE_DESCRIPTION("Arm CoreSight System Trace Macrocell driver");
-- 
2.25.1



From anshuman.khandual at arm.com  Thu Dec  7 21:39:39 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri,  8 Dec 2023 11:09:39 +0530
Subject: [PATCH V3 10/10] coresight: debug: Move ACPI support from AMBA driver to platform driver
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <20231208053939.42901-11-anshuman.khandual@arm.com>

Add support for the cpu debug devices in a new platform driver, which can
then be used on ACPI based platforms. This change would now allow runtime
power management for ACPI based systems. The driver would try to enable
the APB clock if available.

Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: James Clark <james.clark at arm.com>
Cc: linux-acpi at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: coresight at lists.linaro.org
Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
Changes in V3:

- Check for drvdata instead of drvdata->pclk in suspend and resume paths

 drivers/acpi/arm64/amba.c                     |   1 -
 .../hwtracing/coresight/coresight-cpu-debug.c | 141 ++++++++++++++++--
 2 files changed, 127 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
index bec0976541da..e1f0bbb8f393 100644
--- a/drivers/acpi/arm64/amba.c
+++ b/drivers/acpi/arm64/amba.c
@@ -22,7 +22,6 @@
 static const struct acpi_device_id amba_id_list[] = {
 	{"ARMH0061", 0}, /* PL061 GPIO Device */
 	{"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
-	{"ARMHC503", 0}, /* ARM CoreSight Debug */
 	{"", 0},
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c
index 1874df7c6a73..9a0978f3c5b3 100644
--- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -23,6 +23,8 @@
 #include <linux/smp.h>
 #include <linux/types.h>
 #include <linux/uaccess.h>
+#include <linux/platform_device.h>
+#include <linux/acpi.h>
 
 #include "coresight-priv.h"
 
@@ -84,6 +86,7 @@
 #define DEBUG_WAIT_TIMEOUT		32000
 
 struct debug_drvdata {
+	struct clk	*pclk;
 	void __iomem	*base;
 	struct device	*dev;
 	int		cpu;
@@ -557,18 +560,12 @@ static void debug_func_exit(void)
 	debugfs_remove_recursive(debug_debugfs_dir);
 }
 
-static int debug_probe(struct amba_device *adev, const struct amba_id *id)
+static int __debug_probe(struct device *dev, struct resource *res)
 {
+	struct debug_drvdata *drvdata = dev_get_drvdata(dev);
 	void __iomem *base;
-	struct device *dev = &adev->dev;
-	struct debug_drvdata *drvdata;
-	struct resource *res = &adev->res;
 	int ret;
 
-	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
-	if (!drvdata)
-		return -ENOMEM;
-
 	drvdata->cpu = coresight_get_cpu(dev);
 	if (drvdata->cpu < 0)
 		return drvdata->cpu;
@@ -579,8 +576,7 @@ static int debug_probe(struct amba_device *adev, const struct amba_id *id)
 		return -EBUSY;
 	}
 
-	drvdata->dev = &adev->dev;
-	amba_set_drvdata(adev, drvdata);
+	drvdata->dev = dev;
 
 	/* Validity for the resource is already checked by the AMBA core */
 	base = devm_ioremap_resource(dev, res);
@@ -629,10 +625,21 @@ static int debug_probe(struct amba_device *adev, const struct amba_id *id)
 	return ret;
 }
 
-static void debug_remove(struct amba_device *adev)
+static int debug_probe(struct amba_device *adev, const struct amba_id *id)
+{
+	struct debug_drvdata *drvdata;
+
+	drvdata = devm_kzalloc(&adev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	amba_set_drvdata(adev, drvdata);
+	return __debug_probe(&adev->dev, &adev->res);
+}
+
+static void __debug_remove(struct device *dev)
 {
-	struct device *dev = &adev->dev;
-	struct debug_drvdata *drvdata = amba_get_drvdata(adev);
+	struct debug_drvdata *drvdata = dev_get_drvdata(dev);
 
 	per_cpu(debug_drvdata, drvdata->cpu) = NULL;
 
@@ -646,6 +653,11 @@ static void debug_remove(struct amba_device *adev)
 		debug_func_exit();
 }
 
+static void debug_remove(struct amba_device *adev)
+{
+	__debug_remove(&adev->dev);
+}
+
 static const struct amba_cs_uci_id uci_id_debug[] = {
 	{
 		/*  CPU Debug UCI data */
@@ -677,7 +689,108 @@ static struct amba_driver debug_driver = {
 	.id_table	= debug_ids,
 };
 
-module_amba_driver(debug_driver);
+static int debug_platform_probe(struct platform_device *pdev)
+{
+	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	struct debug_drvdata *drvdata;
+	int ret = 0;
+
+	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
+	if (IS_ERR(drvdata->pclk))
+		return -ENODEV;
+
+	if (res) {
+		drvdata->base = devm_ioremap_resource(&pdev->dev, res);
+		if (IS_ERR(drvdata->base)) {
+			clk_put(drvdata->pclk);
+			return PTR_ERR(drvdata->base);
+		}
+	}
+
+	dev_set_drvdata(&pdev->dev, drvdata);
+	pm_runtime_get_noresume(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
+	ret = __debug_probe(&pdev->dev, res);
+	if (ret) {
+		pm_runtime_put_noidle(&pdev->dev);
+		pm_runtime_disable(&pdev->dev);
+	}
+	return ret;
+}
+
+static int debug_platform_remove(struct platform_device *pdev)
+{
+	struct debug_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
+
+	if (drvdata)
+		__debug_remove(&pdev->dev);
+
+	pm_runtime_disable(&pdev->dev);
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_put(drvdata->pclk);
+	return 0;
+}
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id debug_platform_ids[] = {
+	{"ARMHC503", 0}, /* ARM CoreSight Debug */
+	{},
+};
+MODULE_DEVICE_TABLE(acpi, debug_platform_ids);
+#endif
+
+#ifdef CONFIG_PM
+static int debug_runtime_suspend(struct device *dev)
+{
+	struct debug_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_disable_unprepare(drvdata->pclk);
+	return 0;
+}
+
+static int debug_runtime_resume(struct device *dev)
+{
+	struct debug_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
+		clk_prepare_enable(drvdata->pclk);
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops debug_dev_pm_ops = {
+	SET_RUNTIME_PM_OPS(debug_runtime_suspend, debug_runtime_resume, NULL)
+};
+
+static struct platform_driver debug_platform_driver = {
+	.probe	= debug_platform_probe,
+	.remove	= debug_platform_remove,
+	.driver	= {
+		.name			= "coresight-debug-platform",
+		.acpi_match_table	= ACPI_PTR(debug_platform_ids),
+		.suppress_bind_attrs	= true,
+		.pm			= &debug_dev_pm_ops,
+	},
+};
+
+static int __init debug_init(void)
+{
+	return coresight_init_driver("tmc", &debug_driver, &debug_platform_driver);
+}
+
+static void __exit debug_exit(void)
+{
+	coresight_remove_driver(&debug_driver, &debug_platform_driver);
+}
+module_init(debug_init);
+module_exit(debug_exit);
 
 MODULE_AUTHOR("Leo Yan <leo.yan at linaro.org>");
 MODULE_DESCRIPTION("ARM Coresight CPU Debug Driver");
-- 
2.25.1



From hyesoo.yu at samsung.com  Thu Dec  7 21:29:38 2023
From: hyesoo.yu at samsung.com (Hyesoo Yu)
Date: Fri, 8 Dec 2023 14:29:38 +0900
Subject: [PATCH RFC v2 16/27] arm64: mte: Manage tag storage on page
 allocation
In-Reply-To: <ZWc9sVTCHTBcp2Z2@raptor>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
	<CGME20231119165906epcas2p4c6691d274bec428329b193b99119a8d1@epcas2p4.samsung.com>
	<20231119165721.9849-17-alexandru.elisei@arm.com>
	<20231129091040.GC2988384@tiffany> <ZWc9sVTCHTBcp2Z2@raptor>
Message-ID: <20231208052938.GC1359878@tiffany>

Hi.

On Wed, Nov 29, 2023 at 01:33:37PM +0000, Alexandru Elisei wrote:
> Hi,
> 
> On Wed, Nov 29, 2023 at 06:10:40PM +0900, Hyesoo Yu wrote:
> > On Sun, Nov 19, 2023 at 04:57:10PM +0000, Alexandru Elisei wrote:
> > > [..]
> > > +static int order_to_num_blocks(int order)
> > > +{
> > > +	return max((1 << order) / 32, 1);
> > > +}
> > > [..]
> > > +int reserve_tag_storage(struct page *page, int order, gfp_t gfp)
> > > +{
> > > +	unsigned long start_block, end_block;
> > > +	struct tag_region *region;
> > > +	unsigned long block;
> > > +	unsigned long flags;
> > > +	unsigned int tries;
> > > +	int ret = 0;
> > > +
> > > +	VM_WARN_ON_ONCE(!preemptible());
> > > +
> > > +	if (page_tag_storage_reserved(page))
> > > +		return 0;
> > > +
> > > +	/*
> > > +	 * __alloc_contig_migrate_range() ignores gfp when allocating the
> > > +	 * destination page for migration. Regardless, massage gfp flags and
> > > +	 * remove __GFP_TAGGED to avoid recursion in case gfp stops being
> > > +	 * ignored.
> > > +	 */
> > > +	gfp &= ~__GFP_TAGGED;
> > > +	if (!(gfp & __GFP_NORETRY))
> > > +		gfp |= __GFP_RETRY_MAYFAIL;
> > > +
> > > +	ret = tag_storage_find_block(page, &start_block, &region);
> > > +	if (WARN_ONCE(ret, "Missing tag storage block for pfn 0x%lx", page_to_pfn(page)))
> > > +		return 0;
> > > +	end_block = start_block + order_to_num_blocks(order) * region->block_size;
> > > +
> > 
> > Hello.
> > 
> > If the page size is 4K,  block size is 2 (block size bytes 8K), and order is 6,
> > then we need 2 pages for the tag. However according to the equation, order_to_num_blocks
> > is 2 and block_size is also 2, so end block will be incremented by 4.
> > 
> > However we actually only need 8K of tag, right for 256K ?
> > Could you explain order_to_num_blocks * region->block_size more detail ?
> 
> I think you are correct, thank you for pointing it out. The formula should
> probably be something like:
> 
> static int order_to_num_blocks(int order, u32 block_size)
> {
> 	int num_tag_pages = max((1 << order) / 32, 1);
> 
> 	return DIV_ROUND_UP(num_tag_pages, block_size);
> }
> 
> and that will make end_block = start_block + 2 in your scenario.
> 
> Does that look correct to you?
> 
> Thanks,
> Alex
> 

That looks great!

Thanks,
Regards.

> > 
> > Thanks,
> > Regards.
> > 
> > > +	mutex_lock(&tag_blocks_lock);
> > > +
> > > +	/* Check again, this time with the lock held. */
> > > +	if (page_tag_storage_reserved(page))
> > > +		goto out_unlock;
> > > +
> > > +	/* Make sure existing entries are not freed from out under out feet. */
> > > +	xa_lock_irqsave(&tag_blocks_reserved, flags);
> > > +	for (block = start_block; block < end_block; block += region->block_size) {
> > > +		if (tag_storage_block_is_reserved(block))
> > > +			block_ref_add(block, region, order);
> > > +	}
> > > +	xa_unlock_irqrestore(&tag_blocks_reserved, flags);
> > > +
> > > +	for (block = start_block; block < end_block; block += region->block_size) {
> > > +		/* Refcount incremented above. */
> > > +		if (tag_storage_block_is_reserved(block))
> > > +			continue;
> > > +
> > > +		tries = 3;
> > > +		while (tries--) {
> > > +			ret = alloc_contig_range(block, block + region->block_size, MIGRATE_CMA, gfp);
> > > +			if (ret == 0 || ret != -EBUSY)
> > > +				break;
> > > +		}
> > > +
> > > +		if (ret)
> > > +			goto out_error;
> > > +
> > > +		ret = tag_storage_reserve_block(block, region, order);
> > > +		if (ret) {
> > > +			free_contig_range(block, region->block_size);
> > > +			goto out_error;
> > > +		}
> > > +
> > > +		count_vm_events(CMA_ALLOC_SUCCESS, region->block_size);
> > > +	}
> > > +
> > > +	page_set_tag_storage_reserved(page, order);
> > > +out_unlock:
> > > +	mutex_unlock(&tag_blocks_lock);
> > > +
> > > +	return 0;
> > > +
> > > +out_error:
> > > +	xa_lock_irqsave(&tag_blocks_reserved, flags);
> > > +	for (block = start_block; block < end_block; block += region->block_size) {
> > > +		if (tag_storage_block_is_reserved(block) &&
> > > +		    block_ref_sub_return(block, region, order) == 1) {
> > > +			__xa_erase(&tag_blocks_reserved, block);
> > > +			free_contig_range(block, region->block_size);
> > > +		}
> > > +	}
> > > +	xa_unlock_irqrestore(&tag_blocks_reserved, flags);
> > > +
> > > +	mutex_unlock(&tag_blocks_lock);
> > > +
> > > +	count_vm_events(CMA_ALLOC_FAIL, region->block_size);
> > > +
> > > +	return ret;
> > > +}
> > > +
> > > +void free_tag_storage(struct page *page, int order)
> > > +{
> > > +	unsigned long block, start_block, end_block;
> > > +	struct tag_region *region;
> > > +	unsigned long flags;
> > > +	int ret;
> > > +
> > > +	ret = tag_storage_find_block(page, &start_block, &region);
> > > +	if (WARN_ONCE(ret, "Missing tag storage block for pfn 0x%lx", page_to_pfn(page)))
> > > +		return;
> > > +
> > > +	end_block = start_block + order_to_num_blocks(order) * region->block_size;
> > > +
> > > +	xa_lock_irqsave(&tag_blocks_reserved, flags);
> > > +	for (block = start_block; block < end_block; block += region->block_size) {
> > > +		if (WARN_ONCE(!tag_storage_block_is_reserved(block),
> > > +		    "Block 0x%lx is not reserved for pfn 0x%lx", block, page_to_pfn(page)))
> > > +			continue;
> > > +
> > > +		if (block_ref_sub_return(block, region, order) == 1) {
> > > +			__xa_erase(&tag_blocks_reserved, block);
> > > +			free_contig_range(block, region->block_size);
> > > +		}
> > > +	}
> > > +	xa_unlock_irqrestore(&tag_blocks_reserved, flags);
> > > +}
> > > diff --git a/fs/proc/page.c b/fs/proc/page.c
> > > index 195b077c0fac..e7eb584a9234 100644
> > > --- a/fs/proc/page.c
> > > +++ b/fs/proc/page.c
> > > @@ -221,6 +221,7 @@ u64 stable_page_flags(struct page *page)
> > >  #ifdef CONFIG_ARCH_USES_PG_ARCH_X
> > >  	u |= kpf_copy_bit(k, KPF_ARCH_2,	PG_arch_2);
> > >  	u |= kpf_copy_bit(k, KPF_ARCH_3,	PG_arch_3);
> > > +	u |= kpf_copy_bit(k, KPF_ARCH_4,	PG_arch_4);
> > >  #endif
> > >  
> > >  	return u;
> > > diff --git a/include/linux/kernel-page-flags.h b/include/linux/kernel-page-flags.h
> > > index 859f4b0c1b2b..4a0d719ffdd4 100644
> > > --- a/include/linux/kernel-page-flags.h
> > > +++ b/include/linux/kernel-page-flags.h
> > > @@ -19,5 +19,6 @@
> > >  #define KPF_SOFTDIRTY		40
> > >  #define KPF_ARCH_2		41
> > >  #define KPF_ARCH_3		42
> > > +#define KPF_ARCH_4		43
> > >  
> > >  #endif /* LINUX_KERNEL_PAGE_FLAGS_H */
> > > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> > > index a88e64acebfe..7915165a51bd 100644
> > > --- a/include/linux/page-flags.h
> > > +++ b/include/linux/page-flags.h
> > > @@ -135,6 +135,7 @@ enum pageflags {
> > >  #ifdef CONFIG_ARCH_USES_PG_ARCH_X
> > >  	PG_arch_2,
> > >  	PG_arch_3,
> > > +	PG_arch_4,
> > >  #endif
> > >  	__NR_PAGEFLAGS,
> > >  
> > > diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
> > > index 6ca0d5ed46c0..ba962fd10a2c 100644
> > > --- a/include/trace/events/mmflags.h
> > > +++ b/include/trace/events/mmflags.h
> > > @@ -125,7 +125,8 @@ IF_HAVE_PG_HWPOISON(hwpoison)						\
> > >  IF_HAVE_PG_IDLE(idle)							\
> > >  IF_HAVE_PG_IDLE(young)							\
> > >  IF_HAVE_PG_ARCH_X(arch_2)						\
> > > -IF_HAVE_PG_ARCH_X(arch_3)
> > > +IF_HAVE_PG_ARCH_X(arch_3)						\
> > > +IF_HAVE_PG_ARCH_X(arch_4)
> > >  
> > >  #define show_page_flags(flags)						\
> > >  	(flags) ? __print_flags(flags, "|",				\
> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > index f31f02472396..9beead961a65 100644
> > > --- a/mm/huge_memory.c
> > > +++ b/mm/huge_memory.c
> > > @@ -2474,6 +2474,7 @@ static void __split_huge_page_tail(struct folio *folio, int tail,
> > >  #ifdef CONFIG_ARCH_USES_PG_ARCH_X
> > >  			 (1L << PG_arch_2) |
> > >  			 (1L << PG_arch_3) |
> > > +			 (1L << PG_arch_4) |
> > >  #endif
> > >  			 (1L << PG_dirty) |
> > >  			 LRU_GEN_MASK | LRU_REFS_MASK));
> > > -- 
> > > 2.42.1
> > > 
> > > 
> 
> 
> 

From samuel.holland at sifive.com  Thu Dec  7 21:54:31 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:31 -0800
Subject: [RFC PATCH 01/12] arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-2-samuel.holland@sifive.com>

Several architectures provide an API to enable the FPU and run
floating-point SIMD code in kernel space. However, the function names,
header locations, and semantics are inconsistent across architectures,
and FPU support may be gated behind other Kconfig options.

Provide a standard way for architectures to declare that kernel space
FPU support is available. Architectures selecting this option must
implement what is currently the most common API (kernel_fpu_begin() and
kernel_fpu_end(), plus a new function kernel_fpu_available()) and
provide the appropriate CFLAGS for compiling floating-point C code.

Suggested-by: Christoph Hellwig <hch at infradead.org>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 Makefile     | 4 ++++
 arch/Kconfig | 9 +++++++++
 2 files changed, 13 insertions(+)

diff --git a/Makefile b/Makefile
index 511b5616aa41..e65c186cf2c9 100644
--- a/Makefile
+++ b/Makefile
@@ -969,6 +969,10 @@ KBUILD_CFLAGS	+= $(CC_FLAGS_CFI)
 export CC_FLAGS_CFI
 endif
 
+# Architectures can define flags to add/remove for floating-point support
+export CC_FLAGS_FPU
+export CC_FLAGS_NO_FPU
+
 ifneq ($(CONFIG_FUNCTION_ALIGNMENT),0)
 KBUILD_CFLAGS += -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT)
 endif
diff --git a/arch/Kconfig b/arch/Kconfig
index f4b210ab0612..6df834e18e9c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1478,6 +1478,15 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG
 	  address translations. Page table walkers that clear the accessed bit
 	  may use this capability to reduce their search space.
 
+config ARCH_HAS_KERNEL_FPU_SUPPORT
+	bool
+	help
+	  An architecture should select this option if it supports running
+	  floating-point code in kernel space. It must export the functions
+	  kernel_fpu_available(), kernel_fpu_begin(), and kernel_fpu_end() from
+	  <asm/fpu.h>, and define CC_FLAGS_FPU and/or CC_FLAGS_NO_FPU as
+	  necessary in its Makefile.
+
 source "kernel/gcov/Kconfig"
 
 source "scripts/gcc-plugins/Kconfig"
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:32 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:32 -0800
Subject: [RFC PATCH 02/12] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-3-samuel.holland@sifive.com>

ARM provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 arch/arm/Kconfig           |  1 +
 arch/arm/Makefile          |  7 +++++++
 arch/arm/include/asm/fpu.h | 17 +++++++++++++++++
 3 files changed, 25 insertions(+)
 create mode 100644 arch/arm/include/asm/fpu.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f8567e95f98b..92e21a4a2903 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_KEEPINITRD
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT if KERNEL_MODE_NEON
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
 	select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5ba42f69f8ce..1dd860dba5f5 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -130,6 +130,13 @@ endif
 # Accept old syntax despite ".syntax unified"
 AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
 
+# The GCC option -ffreestanding is required in order to compile code containing
+# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
+CC_FLAGS_FPU	:= -ffreestanding
+# Enable <arm_neon.h>
+CC_FLAGS_FPU	+= -isystem $(shell $(CC) -print-file-name=include)
+CC_FLAGS_FPU	+= -march=armv7-a -mfloat-abi=softfp -mfpu=neon
+
 ifeq ($(CONFIG_THUMB2_KERNEL),y)
 CFLAGS_ISA	:=-Wa,-mimplicit-it=always $(AFLAGS_NOWARN)
 AFLAGS_ISA	:=$(CFLAGS_ISA) -Wa$(comma)-mthumb
diff --git a/arch/arm/include/asm/fpu.h b/arch/arm/include/asm/fpu.h
new file mode 100644
index 000000000000..d01ca06e700a
--- /dev/null
+++ b/arch/arm/include/asm/fpu.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * linux/arch/arm/include/asm/fpu.h
+ *
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef __ASM_FPU_H
+#define __ASM_FPU_H
+
+#include <asm/neon.h>
+
+#define kernel_fpu_available()	cpu_has_neon()
+#define kernel_fpu_begin()	kernel_neon_begin()
+#define kernel_fpu_end()	kernel_neon_end()
+
+#endif /* ! __ASM_FPU_H */
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:30 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:30 -0800
Subject: [RFC PATCH 00/12] Unified cross-architecture kernel-mode FPU API
Message-ID: <20231208055501.2916202-1-samuel.holland@sifive.com>

This series supersedes my earier RISC-V specific series[1].

This series unifies the kernel-mode FPU API across several architectures
by wrapping the existing functions (where needed) in consistently-named
functions placed in a consistent header location, with mostly the same
semantics: they can be called from preemptible or non-preemptible task
context, and are not assumed to be reentrant. Architectures are also
expected to provide CFLAGS adjustments for compiling FPU-dependent code.
For the moment, SIMD/vector units are out of scope for this common API.

This allows us to remove the ifdeffery and duplicated Makefile logic at
each FPU user. It then implements the common API on RISC-V, and converts
a couple of users to the new API: the AMDGPU DRM driver, and the FPU
self test.

The underlying goal of this series is to allow using newer AMD GPUs
(e.g. Navi) on RISC-V boards such as SiFive's HiFive Unmatched. Those
GPUs need CONFIG_DRM_AMD_DC_FP to initialize, which requires kernel-mode
FPU support.

[1]: https://lore.kernel.org/linux-riscv/20231122030621.3759313-1-samuel.holland at sifive.com/


Samuel Holland (12):
  arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
  ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  ARM: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
  arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
  LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  powerpc: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  x86: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  riscv: Add support for kernel-mode FPU
  drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
  selftests/fpu: Move FP code to a separate translation unit
  selftests/fpu: Allow building on other architectures

 Makefile                                      |  4 ++
 arch/Kconfig                                  |  9 +++++
 arch/arm/Kconfig                              |  1 +
 arch/arm/Makefile                             |  7 ++++
 arch/arm/include/asm/fpu.h                    | 17 +++++++++
 arch/arm/lib/Makefile                         |  3 +-
 arch/arm64/Kconfig                            |  1 +
 arch/arm64/Makefile                           |  9 ++++-
 arch/arm64/include/asm/fpu.h                  | 17 +++++++++
 arch/loongarch/Kconfig                        |  1 +
 arch/loongarch/Makefile                       |  5 ++-
 arch/loongarch/include/asm/fpu.h              |  1 +
 arch/powerpc/Kconfig                          |  1 +
 arch/powerpc/Makefile                         |  5 ++-
 arch/powerpc/include/asm/fpu.h                | 28 ++++++++++++++
 arch/riscv/Kconfig                            |  1 +
 arch/riscv/Makefile                           |  3 ++
 arch/riscv/include/asm/fpu.h                  | 26 +++++++++++++
 arch/riscv/kernel/Makefile                    |  1 +
 arch/riscv/kernel/kernel_mode_fpu.c           | 28 ++++++++++++++
 arch/x86/Kconfig                              |  1 +
 arch/x86/Makefile                             | 20 ++++++++++
 arch/x86/include/asm/fpu.h                    | 13 +++++++
 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 .../gpu/drm/amd/display/amdgpu_dm/dc_fpu.c    | 33 +----------------
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 36 +-----------------
 drivers/gpu/drm/amd/display/dc/dml2/Makefile  | 36 +-----------------
 lib/Kconfig.debug                             |  2 +-
 lib/Makefile                                  | 26 ++-----------
 lib/raid6/Makefile                            | 31 ++++------------
 lib/{test_fpu.c => test_fpu_glue.c}           | 37 +++----------------
 lib/test_fpu_impl.c                           | 35 ++++++++++++++++++
 32 files changed, 255 insertions(+), 185 deletions(-)
 create mode 100644 arch/arm/include/asm/fpu.h
 create mode 100644 arch/arm64/include/asm/fpu.h
 create mode 100644 arch/powerpc/include/asm/fpu.h
 create mode 100644 arch/riscv/include/asm/fpu.h
 create mode 100644 arch/riscv/kernel/kernel_mode_fpu.c
 create mode 100644 arch/x86/include/asm/fpu.h
 rename lib/{test_fpu.c => test_fpu_glue.c} (71%)
 create mode 100644 lib/test_fpu_impl.c

-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:33 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:33 -0800
Subject: [RFC PATCH 03/12] ARM: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-4-samuel.holland@sifive.com>

Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 arch/arm/lib/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 650404be6768..0ca5aae1bcc3 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -40,8 +40,7 @@ $(obj)/csumpartialcopy.o:	$(obj)/csumpartialcopygeneric.S
 $(obj)/csumpartialcopyuser.o:	$(obj)/csumpartialcopygeneric.S
 
 ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
-  NEON_FLAGS			:= -march=armv7-a -mfloat-abi=softfp -mfpu=neon
-  CFLAGS_xor-neon.o		+= $(NEON_FLAGS)
+  CFLAGS_xor-neon.o		+= $(CC_FLAGS_FPU)
   obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
 endif
 
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:35 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:35 -0800
Subject: [RFC PATCH 05/12] lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-6-samuel.holland@sifive.com>

Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 lib/raid6/Makefile | 31 ++++++++-----------------------
 1 file changed, 8 insertions(+), 23 deletions(-)

diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 1c5420ff254e..309fea97efc6 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -33,25 +33,6 @@ CFLAGS_REMOVE_vpermxor8.o += -msoft-float
 endif
 endif
 
-# The GCC option -ffreestanding is required in order to compile code containing
-# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
-ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
-NEON_FLAGS := -ffreestanding
-# Enable <arm_neon.h>
-NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include)
-ifeq ($(ARCH),arm)
-NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
-endif
-CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
-ifeq ($(ARCH),arm64)
-CFLAGS_REMOVE_recov_neon_inner.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon2.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon4.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon8.o += -mgeneral-regs-only
-endif
-endif
-
 quiet_cmd_unroll = UNROLL  $@
       cmd_unroll = $(AWK) -v N=$* -f $(srctree)/$(src)/unroll.awk < $< > $@
 
@@ -75,10 +56,14 @@ targets += vpermxor1.c vpermxor2.c vpermxor4.c vpermxor8.c
 $(obj)/vpermxor%.c: $(src)/vpermxor.uc $(src)/unroll.awk FORCE
 	$(call if_changed,unroll)
 
-CFLAGS_neon1.o += $(NEON_FLAGS)
-CFLAGS_neon2.o += $(NEON_FLAGS)
-CFLAGS_neon4.o += $(NEON_FLAGS)
-CFLAGS_neon8.o += $(NEON_FLAGS)
+CFLAGS_neon1.o += $(CC_FLAGS_FPU)
+CFLAGS_neon2.o += $(CC_FLAGS_FPU)
+CFLAGS_neon4.o += $(CC_FLAGS_FPU)
+CFLAGS_neon8.o += $(CC_FLAGS_FPU)
+CFLAGS_REMOVE_neon1.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
 targets += neon1.c neon2.c neon4.c neon8.c
 $(obj)/neon%.c: $(src)/neon.uc $(src)/unroll.awk FORCE
 	$(call if_changed,unroll)
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:34 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:34 -0800
Subject: [RFC PATCH 04/12] arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-5-samuel.holland@sifive.com>

arm64 provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 arch/arm64/Kconfig           |  1 +
 arch/arm64/Makefile          |  9 ++++++++-
 arch/arm64/include/asm/fpu.h | 17 +++++++++++++++++
 3 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/include/asm/fpu.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..485ac389ac11 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -30,6 +30,7 @@ config ARM64
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_GIGANTIC_PAGE
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT if KERNEL_MODE_NEON
 	select ARCH_HAS_KEEPINITRD
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 9a2d3723cd0f..4a65f24c7998 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -36,7 +36,14 @@ ifeq ($(CONFIG_BROKEN_GAS_INST),y)
 $(warning Detected assembler with broken .inst; disassembly will be unreliable)
 endif
 
-KBUILD_CFLAGS	+= -mgeneral-regs-only	\
+# The GCC option -ffreestanding is required in order to compile code containing
+# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
+CC_FLAGS_FPU	:= -ffreestanding
+# Enable <arm_neon.h>
+CC_FLAGS_FPU	+= -isystem $(shell $(CC) -print-file-name=include)
+CC_FLAGS_NO_FPU	:= -mgeneral-regs-only
+
+KBUILD_CFLAGS	+= $(CC_FLAGS_NO_FPU) \
 		   $(compat_vdso) $(cc_has_k_constraint)
 KBUILD_CFLAGS	+= $(call cc-disable-warning, psabi)
 KBUILD_AFLAGS	+= $(compat_vdso)
diff --git a/arch/arm64/include/asm/fpu.h b/arch/arm64/include/asm/fpu.h
new file mode 100644
index 000000000000..664c0a192ab1
--- /dev/null
+++ b/arch/arm64/include/asm/fpu.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * linux/arch/arm64/include/asm/fpu.h
+ *
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef __ASM_FPU_H
+#define __ASM_FPU_H
+
+#include <asm/neon.h>
+
+#define kernel_fpu_available()	cpu_has_neon()
+#define kernel_fpu_begin()	kernel_neon_begin()
+#define kernel_fpu_end()	kernel_neon_end()
+
+#endif /* ! __ASM_FPU_H */
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:36 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:36 -0800
Subject: [RFC PATCH 06/12] LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-7-samuel.holland@sifive.com>

LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
asm/fpu.h, so it only needs to add kernel_fpu_available() and export
the CFLAGS adjustments.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 arch/loongarch/Kconfig           | 1 +
 arch/loongarch/Makefile          | 5 ++++-
 arch/loongarch/include/asm/fpu.h | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index ee123820a476..65d4475565b8 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -15,6 +15,7 @@ config LOONGARCH
 	select ARCH_HAS_CPU_FINALIZE_INIT
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT if CPU_HAS_FPU
 	select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
 	select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
 	select ARCH_HAS_PTE_SPECIAL
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index 204b94b2e6aa..f5c4f7e921db 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -25,6 +25,9 @@ endif
 32bit-emul		= elf32loongarch
 64bit-emul		= elf64loongarch
 
+CC_FLAGS_FPU		:= -mfpu=64
+CC_FLAGS_NO_FPU		:= -msoft-float
+
 ifdef CONFIG_DYNAMIC_FTRACE
 KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
 CC_FLAGS_FTRACE := -fpatchable-function-entry=2
@@ -46,7 +49,7 @@ ld-emul			= $(64bit-emul)
 cflags-y		+= -mabi=lp64s
 endif
 
-cflags-y			+= -pipe -msoft-float
+cflags-y			+= -pipe $(CC_FLAGS_NO_FPU)
 LDFLAGS_vmlinux			+= -static -n -nostdlib
 
 # When the assembler supports explicit relocation hint, we must use it.
diff --git a/arch/loongarch/include/asm/fpu.h b/arch/loongarch/include/asm/fpu.h
index c2d8962fda00..3177674228f8 100644
--- a/arch/loongarch/include/asm/fpu.h
+++ b/arch/loongarch/include/asm/fpu.h
@@ -21,6 +21,7 @@
 
 struct sigcontext;
 
+#define kernel_fpu_available() cpu_has_fpu
 extern void kernel_fpu_begin(void);
 extern void kernel_fpu_end(void);
 
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:37 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:37 -0800
Subject: [RFC PATCH 07/12] powerpc: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-8-samuel.holland@sifive.com>

PowerPC provides an equivalent to the common kernel-mode FPU API, but in
a different header and using different function names. The PowerPC API
also requires a non-preemptible context. Add a wrapper header, and
export the CFLAGS adjustments.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 arch/powerpc/Kconfig           |  1 +
 arch/powerpc/Makefile          |  5 ++++-
 arch/powerpc/include/asm/fpu.h | 28 ++++++++++++++++++++++++++++
 3 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/include/asm/fpu.h

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6f105ee4f3cf..e96cb5b7c571 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -137,6 +137,7 @@ config PPC
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_HUGEPD			if HUGETLB_PAGE
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT	if PPC_FPU
 	select ARCH_HAS_MEMBARRIER_CALLBACKS
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_MEMREMAP_COMPAT_ALIGN	if PPC_64S_HASH_MMU
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f19dbaa1d541..2d5f21baf6ff 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -142,6 +142,9 @@ CFLAGS-$(CONFIG_PPC32)	+= $(call cc-option, $(MULTIPLEWORD))
 
 CFLAGS-$(CONFIG_PPC32)	+= $(call cc-option,-mno-readonly-in-sdata)
 
+CC_FLAGS_FPU		:= $(call cc-option,-mhard-float)
+CC_FLAGS_NO_FPU		+= $(call cc-option,-msoft-float)
+
 ifdef CONFIG_FUNCTION_TRACER
 ifdef CONFIG_ARCH_USING_PATCHABLE_FUNCTION_ENTRY
 KBUILD_CPPFLAGS	+= -DCC_USING_PATCHABLE_FUNCTION_ENTRY
@@ -163,7 +166,7 @@ asinstr := $(call as-instr,lis 9$(comma)foo at high,-DHAVE_AS_ATHIGH=1)
 
 KBUILD_CPPFLAGS	+= -I $(srctree)/arch/$(ARCH) $(asinstr)
 KBUILD_AFLAGS	+= $(AFLAGS-y)
-KBUILD_CFLAGS	+= $(call cc-option,-msoft-float)
+KBUILD_CFLAGS	+= $(CC_FLAGS_NO_FPU)
 KBUILD_CFLAGS	+= $(CFLAGS-y)
 CPP		= $(CC) -E $(KBUILD_CFLAGS)
 
diff --git a/arch/powerpc/include/asm/fpu.h b/arch/powerpc/include/asm/fpu.h
new file mode 100644
index 000000000000..ca584e4bc40f
--- /dev/null
+++ b/arch/powerpc/include/asm/fpu.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef _ASM_POWERPC_FPU_H
+#define _ASM_POWERPC_FPU_H
+
+#include <linux/preempt.h>
+
+#include <asm/cpu_has_feature.h>
+#include <asm/switch_to.h>
+
+#define kernel_fpu_available()	(!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
+
+static inline void kernel_fpu_begin(void)
+{
+	preempt_disable();
+	enable_kernel_fp();
+}
+
+static inline void kernel_fpu_end(void)
+{
+	disable_kernel_fp();
+	preempt_enable();
+}
+
+#endif /* ! _ASM_POWERPC_FPU_H */
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:38 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:38 -0800
Subject: [RFC PATCH 08/12] x86: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-9-samuel.holland@sifive.com>

x86 already provides kernel_fpu_begin() and kernel_fpu_end(), but in a
different header. Add a wrapper header, and export the CFLAGS
adjustments as found in lib/Makefile.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 arch/x86/Kconfig           |  1 +
 arch/x86/Makefile          | 20 ++++++++++++++++++++
 arch/x86/include/asm/fpu.h | 13 +++++++++++++
 3 files changed, 34 insertions(+)
 create mode 100644 arch/x86/include/asm/fpu.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3762f41bb092..1fe7f2d8d017 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -81,6 +81,7 @@ config X86
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_KCOV			if X86_64
+	select ARCH_HAS_KERNEL_FPU_SUPPORT
 	select ARCH_HAS_MEM_ENCRYPT
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 1a068de12a56..71576c8dbe79 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -70,6 +70,26 @@ export BITS
 KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
 KBUILD_RUSTFLAGS += -Ctarget-feature=-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2
 
+#
+# CFLAGS for compiling floating point code inside the kernel.
+#
+CC_FLAGS_FPU := -msse -msse2
+ifdef CONFIG_CC_IS_GCC
+# Stack alignment mismatch, proceed with caution.
+# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3
+# (8B stack alignment).
+# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
+#
+# The "-msse" in the first argument is there so that the
+# -mpreferred-stack-boundary=3 build error:
+#
+#  -mpreferred-stack-boundary=3 is not between 4 and 12
+#
+# can be triggered. Otherwise gcc doesn't complain.
+CC_FLAGS_FPU += -mhard-float
+CC_FLAGS_FPU += $(call cc-option,-msse -mpreferred-stack-boundary=3,-mpreferred-stack-boundary=4)
+endif
+
 ifeq ($(CONFIG_X86_KERNEL_IBT),y)
 #
 # Kernel IBT has S_CET.NOTRACK_EN=0, as such the compilers must not generate
diff --git a/arch/x86/include/asm/fpu.h b/arch/x86/include/asm/fpu.h
new file mode 100644
index 000000000000..b2743fe19339
--- /dev/null
+++ b/arch/x86/include/asm/fpu.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef _ASM_X86_FPU_H
+#define _ASM_X86_FPU_H
+
+#include <asm/fpu/api.h>
+
+#define kernel_fpu_available()	true
+
+#endif /* ! _ASM_X86_FPU_H */
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:39 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:39 -0800
Subject: [RFC PATCH 09/12] riscv: Add support for kernel-mode FPU
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-10-samuel.holland@sifive.com>

This is motivated by the amdgpu DRM driver, which needs floating-point
code to support recent hardware. That code is not performance-critical,
so only provide a minimal non-preemptible implementation for now.

Use a similar trick as ARM to force placing floating-point code in a
separate translation unit, so it is not possible for compiler-generated
floating-point code to appear outside kernel_fpu_{begin,end}().

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 arch/riscv/Kconfig                  |  1 +
 arch/riscv/Makefile                 |  3 +++
 arch/riscv/include/asm/fpu.h        | 26 ++++++++++++++++++++++++++
 arch/riscv/kernel/Makefile          |  1 +
 arch/riscv/kernel/kernel_mode_fpu.c | 28 ++++++++++++++++++++++++++++
 5 files changed, 59 insertions(+)
 create mode 100644 arch/riscv/include/asm/fpu.h
 create mode 100644 arch/riscv/kernel/kernel_mode_fpu.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 95a2a06acc6a..cf0967928e6d 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -27,6 +27,7 @@ config RISCV
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_GIGANTIC_PAGE
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT if FPU
 	select ARCH_HAS_MMIOWB
 	select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
 	select ARCH_HAS_PMEM_API
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index a74be78678eb..2e719c369210 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -81,6 +81,9 @@ KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64i
 
 KBUILD_AFLAGS += -march=$(riscv-march-y)
 
+# For C code built with floating-point support, exclude V but keep F and D.
+CC_FLAGS_FPU  := -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)([^v_]*)v?/\1\2/')
+
 KBUILD_CFLAGS += -mno-save-restore
 KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET)
 
diff --git a/arch/riscv/include/asm/fpu.h b/arch/riscv/include/asm/fpu.h
new file mode 100644
index 000000000000..8cd027acc015
--- /dev/null
+++ b/arch/riscv/include/asm/fpu.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef _ASM_RISCV_FPU_H
+#define _ASM_RISCV_FPU_H
+
+#include <asm/switch_to.h>
+
+#define kernel_fpu_available()	has_fpu()
+
+#ifdef __riscv_f
+
+#define kernel_fpu_begin() \
+	static_assert(false, "floating-point code must use a separate translation unit")
+#define kernel_fpu_end() kernel_fpu_begin()
+
+#else
+
+void kernel_fpu_begin(void);
+void kernel_fpu_end(void);
+
+#endif
+
+#endif /* ! _ASM_RISCV_FPU_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index fee22a3d1b53..662c483e338d 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_MMU) += vdso.o vdso/
 
 obj-$(CONFIG_RISCV_MISALIGNED)	+= traps_misaligned.o
 obj-$(CONFIG_FPU)		+= fpu.o
+obj-$(CONFIG_FPU)		+= kernel_mode_fpu.o
 obj-$(CONFIG_RISCV_ISA_V)	+= vector.o
 obj-$(CONFIG_SMP)		+= smpboot.o
 obj-$(CONFIG_SMP)		+= smp.o
diff --git a/arch/riscv/kernel/kernel_mode_fpu.c b/arch/riscv/kernel/kernel_mode_fpu.c
new file mode 100644
index 000000000000..9b2024cc056b
--- /dev/null
+++ b/arch/riscv/kernel/kernel_mode_fpu.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#include <linux/export.h>
+#include <linux/preempt.h>
+
+#include <asm/csr.h>
+#include <asm/fpu.h>
+#include <asm/processor.h>
+#include <asm/switch_to.h>
+
+void kernel_fpu_begin(void)
+{
+	preempt_disable();
+	fstate_save(current, task_pt_regs(current));
+	csr_set(CSR_SSTATUS, SR_FS);
+}
+EXPORT_SYMBOL_GPL(kernel_fpu_begin);
+
+void kernel_fpu_end(void)
+{
+	csr_clear(CSR_SSTATUS, SR_FS);
+	fstate_restore(current, task_pt_regs(current));
+	preempt_enable();
+}
+EXPORT_SYMBOL_GPL(kernel_fpu_end);
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:41 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:41 -0800
Subject: [RFC PATCH 11/12] selftests/fpu: Move FP code to a separate translation unit
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-12-samuel.holland@sifive.com>

This ensures no compiler-generated floating-point code can appear
outside kernel_fpu_{begin,end}() sections, and some architectures
enforce this separation.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 lib/Makefile                        |  3 ++-
 lib/{test_fpu.c => test_fpu_glue.c} | 32 +-------------------------
 lib/test_fpu_impl.c                 | 35 +++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+), 32 deletions(-)
 rename lib/{test_fpu.c => test_fpu_glue.c} (71%)
 create mode 100644 lib/test_fpu_impl.c

diff --git a/lib/Makefile b/lib/Makefile
index 6b09731d8e61..e7cbd54944a2 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -132,7 +132,8 @@ FPU_CFLAGS += $(call cc-option,-msse -mpreferred-stack-boundary=3,-mpreferred-st
 endif
 
 obj-$(CONFIG_TEST_FPU) += test_fpu.o
-CFLAGS_test_fpu.o += $(FPU_CFLAGS)
+test_fpu-y := test_fpu_glue.o test_fpu_impl.o
+CFLAGS_test_fpu_impl.o += $(FPU_CFLAGS)
 
 obj-$(CONFIG_TEST_LIVEPATCH) += livepatch/
 
diff --git a/lib/test_fpu.c b/lib/test_fpu_glue.c
similarity index 71%
rename from lib/test_fpu.c
rename to lib/test_fpu_glue.c
index e82db19fed84..2761b51117b0 100644
--- a/lib/test_fpu.c
+++ b/lib/test_fpu_glue.c
@@ -19,37 +19,7 @@
 #include <linux/debugfs.h>
 #include <asm/fpu/api.h>
 
-static int test_fpu(void)
-{
-	/*
-	 * This sequence of operations tests that rounding mode is
-	 * to nearest and that denormal numbers are supported.
-	 * Volatile variables are used to avoid compiler optimizing
-	 * the calculations away.
-	 */
-	volatile double a, b, c, d, e, f, g;
-
-	a = 4.0;
-	b = 1e-15;
-	c = 1e-310;
-
-	/* Sets precision flag */
-	d = a + b;
-
-	/* Result depends on rounding mode */
-	e = a + b / 2;
-
-	/* Denormal and very large values */
-	f = b / c;
-
-	/* Depends on denormal support */
-	g = a + c * f;
-
-	if (d > a && e > a && g > a)
-		return 0;
-	else
-		return -EINVAL;
-}
+int test_fpu(void);
 
 static int test_fpu_get(void *data, u64 *val)
 {
diff --git a/lib/test_fpu_impl.c b/lib/test_fpu_impl.c
new file mode 100644
index 000000000000..2ff01980bc22
--- /dev/null
+++ b/lib/test_fpu_impl.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/errno.h>
+
+int test_fpu(void)
+{
+	/*
+	 * This sequence of operations tests that rounding mode is
+	 * to nearest and that denormal numbers are supported.
+	 * Volatile variables are used to avoid compiler optimizing
+	 * the calculations away.
+	 */
+	volatile double a, b, c, d, e, f, g;
+
+	a = 4.0;
+	b = 1e-15;
+	c = 1e-310;
+
+	/* Sets precision flag */
+	d = a + b;
+
+	/* Result depends on rounding mode */
+	e = a + b / 2;
+
+	/* Denormal and very large values */
+	f = b / c;
+
+	/* Depends on denormal support */
+	g = a + c * f;
+
+	if (d > a && e > a && g > a)
+		return 0;
+	else
+		return -EINVAL;
+}
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:42 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:42 -0800
Subject: [RFC PATCH 12/12] selftests/fpu: Allow building on other architectures
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-13-samuel.holland@sifive.com>

Now that ARCH_HAS_KERNEL_FPU_SUPPORT provides a common way to compile
and run floating-point code, this test is no longer x86-specific.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 lib/Kconfig.debug   |  2 +-
 lib/Makefile        | 25 ++-----------------------
 lib/test_fpu_glue.c |  5 ++++-
 3 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index cc7d53d9dc01..bbab0b054e09 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2933,7 +2933,7 @@ config TEST_FREE_PAGES
 
 config TEST_FPU
 	tristate "Test floating point operations in kernel space"
-	depends on X86 && !KCOV_INSTRUMENT_ALL
+	depends on ARCH_HAS_KERNEL_FPU_SUPPORT && !KCOV_INSTRUMENT_ALL
 	help
 	  Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu
 	  which will trigger a sequence of floating point operations. This is used
diff --git a/lib/Makefile b/lib/Makefile
index e7cbd54944a2..b9f28558c9bd 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -109,31 +109,10 @@ CFLAGS_test_fprobe.o += $(CC_FLAGS_FTRACE)
 obj-$(CONFIG_FPROBE_SANITY_TEST) += test_fprobe.o
 obj-$(CONFIG_TEST_OBJPOOL) += test_objpool.o
 
-#
-# CFLAGS for compiling floating point code inside the kernel. x86/Makefile turns
-# off the generation of FPU/SSE* instructions for kernel proper but FPU_FLAGS
-# get appended last to CFLAGS and thus override those previous compiler options.
-#
-FPU_CFLAGS := -msse -msse2
-ifdef CONFIG_CC_IS_GCC
-# Stack alignment mismatch, proceed with caution.
-# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3
-# (8B stack alignment).
-# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
-#
-# The "-msse" in the first argument is there so that the
-# -mpreferred-stack-boundary=3 build error:
-#
-#  -mpreferred-stack-boundary=3 is not between 4 and 12
-#
-# can be triggered. Otherwise gcc doesn't complain.
-FPU_CFLAGS += -mhard-float
-FPU_CFLAGS += $(call cc-option,-msse -mpreferred-stack-boundary=3,-mpreferred-stack-boundary=4)
-endif
-
 obj-$(CONFIG_TEST_FPU) += test_fpu.o
 test_fpu-y := test_fpu_glue.o test_fpu_impl.o
-CFLAGS_test_fpu_impl.o += $(FPU_CFLAGS)
+CFLAGS_test_fpu_impl.o += $(CC_FLAGS_FPU)
+CFLAGS_REMOVE_test_fpu_impl.o += $(CC_FLAGS_NO_FPU)
 
 obj-$(CONFIG_TEST_LIVEPATCH) += livepatch/
 
diff --git a/lib/test_fpu_glue.c b/lib/test_fpu_glue.c
index 2761b51117b0..2e0b4027a5e3 100644
--- a/lib/test_fpu_glue.c
+++ b/lib/test_fpu_glue.c
@@ -17,7 +17,7 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/debugfs.h>
-#include <asm/fpu/api.h>
+#include <asm/fpu.h>
 
 int test_fpu(void);
 
@@ -38,6 +38,9 @@ static struct dentry *selftest_dir;
 
 static int __init test_fpu_init(void)
 {
+	if (!kernel_fpu_available())
+		return -EINVAL;
+
 	selftest_dir = debugfs_create_dir("selftest_helpers", NULL);
 	if (!selftest_dir)
 		return -ENOMEM;
-- 
2.42.0



From samuel.holland at sifive.com  Thu Dec  7 21:54:40 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Thu,  7 Dec 2023 21:54:40 -0800
Subject: [RFC PATCH 10/12] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-1-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
Message-ID: <20231208055501.2916202-11-samuel.holland@sifive.com>

Now that all previously-supported architectures select
ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
of the existing list of architectures. It can also take advantage of the
common kernel-mode FPU API and method of adjusting CFLAGS.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 .../gpu/drm/amd/display/amdgpu_dm/dc_fpu.c    | 33 +----------------
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 36 ++-----------------
 drivers/gpu/drm/amd/display/dc/dml2/Makefile  | 36 ++-----------------
 4 files changed, 6 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig
index 901d1961b739..5fcd4f778dc3 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -8,7 +8,7 @@ config DRM_AMD_DC
 	depends on BROKEN || !CC_IS_CLANG || ARM64 || RISCV || SPARC64 || X86_64
 	select SND_HDA_COMPONENT if SND_HDA_CORE
 	# !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
-	select DRM_AMD_DC_FP if (X86 || LOONGARCH || (PPC64 && ALTIVEC) || (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
+	select DRM_AMD_DC_FP if ARCH_HAS_KERNEL_FPU_SUPPORT && (!ARM64 || !CC_IS_CLANG)
 	help
 	  Choose this option if you want to use the new display engine
 	  support for AMDGPU. This adds required support for Vega and
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
index 4ae4720535a5..b64f917174ca 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
@@ -26,16 +26,7 @@
 
 #include "dc_trace.h"
 
-#if defined(CONFIG_X86)
-#include <asm/fpu/api.h>
-#elif defined(CONFIG_PPC64)
-#include <asm/switch_to.h>
-#include <asm/cputable.h>
-#elif defined(CONFIG_ARM64)
-#include <asm/neon.h>
-#elif defined(CONFIG_LOONGARCH)
 #include <asm/fpu.h>
-#endif
 
 /**
  * DOC: DC FPU manipulation overview
@@ -87,20 +78,9 @@ void dc_fpu_begin(const char *function_name, const int line)
 	WARN_ON_ONCE(!in_task());
 	preempt_disable();
 	depth = __this_cpu_inc_return(fpu_recursion_depth);
-
 	if (depth == 1) {
-#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
+		BUG_ON(!kernel_fpu_available());
 		kernel_fpu_begin();
-#elif defined(CONFIG_PPC64)
-		if (cpu_has_feature(CPU_FTR_VSX_COMP))
-			enable_kernel_vsx();
-		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
-			enable_kernel_altivec();
-		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
-			enable_kernel_fp();
-#elif defined(CONFIG_ARM64)
-		kernel_neon_begin();
-#endif
 	}
 
 	TRACE_DCN_FPU(true, function_name, line, depth);
@@ -122,18 +102,7 @@ void dc_fpu_end(const char *function_name, const int line)
 
 	depth = __this_cpu_dec_return(fpu_recursion_depth);
 	if (depth == 0) {
-#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 		kernel_fpu_end();
-#elif defined(CONFIG_PPC64)
-		if (cpu_has_feature(CPU_FTR_VSX_COMP))
-			disable_kernel_vsx();
-		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
-			disable_kernel_altivec();
-		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
-			disable_kernel_fp();
-#elif defined(CONFIG_ARM64)
-		kernel_neon_end();
-#endif
 	} else {
 		WARN_ON_ONCE(depth < 0);
 	}
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index ea7d60f9a9b4..5aad0f572ba3 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -25,40 +25,8 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-ifdef CONFIG_X86
-dml_ccflags-$(CONFIG_CC_IS_GCC) := -mhard-float
-dml_ccflags := $(dml_ccflags-y) -msse
-endif
-
-ifdef CONFIG_PPC64
-dml_ccflags := -mhard-float -maltivec
-endif
-
-ifdef CONFIG_ARM64
-dml_rcflags := -mgeneral-regs-only
-endif
-
-ifdef CONFIG_LOONGARCH
-dml_ccflags := -mfpu=64
-dml_rcflags := -msoft-float
-endif
-
-ifdef CONFIG_CC_IS_GCC
-ifneq ($(call gcc-min-version, 70100),y)
-IS_OLD_GCC = 1
-endif
-endif
-
-ifdef CONFIG_X86
-ifdef IS_OLD_GCC
-# Stack alignment mismatch, proceed with caution.
-# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3
-# (8B stack alignment).
-dml_ccflags += -mpreferred-stack-boundary=4
-else
-dml_ccflags += -msse2
-endif
-endif
+dml_ccflags := $(CC_FLAGS_FPU)
+dml_rcflags := $(CC_FLAGS_NO_FPU)
 
 ifneq ($(CONFIG_FRAME_WARN),0)
 frame_warn_flag := -Wframe-larger-than=2048
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index acff3449b8d7..4f6c804a26ad 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -24,40 +24,8 @@
 #
 # Makefile for dml2.
 
-ifdef CONFIG_X86
-dml2_ccflags-$(CONFIG_CC_IS_GCC) := -mhard-float
-dml2_ccflags := $(dml2_ccflags-y) -msse
-endif
-
-ifdef CONFIG_PPC64
-dml2_ccflags := -mhard-float -maltivec
-endif
-
-ifdef CONFIG_ARM64
-dml2_rcflags := -mgeneral-regs-only
-endif
-
-ifdef CONFIG_LOONGARCH
-dml2_ccflags := -mfpu=64
-dml2_rcflags := -msoft-float
-endif
-
-ifdef CONFIG_CC_IS_GCC
-ifeq ($(call cc-ifversion, -lt, 0701, y), y)
-IS_OLD_GCC = 1
-endif
-endif
-
-ifdef CONFIG_X86
-ifdef IS_OLD_GCC
-# Stack alignment mismatch, proceed with caution.
-# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3
-# (8B stack alignment).
-dml2_ccflags += -mpreferred-stack-boundary=4
-else
-dml2_ccflags += -msse2
-endif
-endif
+dml2_ccflags := $(CC_FLAGS_FPU)
+dml2_rcflags := $(CC_FLAGS_NO_FPU)
 
 ifneq ($(CONFIG_FRAME_WARN),0)
 ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
-- 
2.42.0



From quic_snehshah at quicinc.com  Thu Dec  7 22:25:02 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Fri,  8 Dec 2023 11:55:02 +0530
Subject: [PATCH net v3] net: stmmac: update Rx clk divider for 10M SGMII
Message-ID: <20231208062502.13124-1-quic_snehshah@quicinc.com>

SGMII 10MBPS mode needs RX clock divider to avoid drops in Rx.
Update configure SGMII function with rx clk divider programming.

Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
---
v3 changelog:
- Added comment to explain why MAC needs to be reconfigured for SGMII
v2 changelog:
- Use FIELD_PREP to prepare bifield values in place of GENMASK
- Add fixes tag
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index d3bf42d0fceb..ab2245995bc6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -34,6 +34,7 @@
 #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
 #define RGMII_CONFIG_PROG_SWAP			BIT(1)
 #define RGMII_CONFIG_DDR_MODE			BIT(0)
+#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)
 
 /* SDCC_HC_REG_DLL_CONFIG fields */
 #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
@@ -598,6 +599,9 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
 	return 0;
 }
 
+/* On interface toggle MAC registetrs gets reset.
+ * Configure MAC block for SGMII on ethernet phy link up
+ */
 static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
 {
 	int val;
@@ -617,6 +621,9 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
 	case SPEED_10:
 		val |= ETHQOS_MAC_CTRL_PORT_SEL;
 		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
+		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
+			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR, 0x31),
+			      RGMII_IO_MACRO_CONFIG);
 		break;
 	}
 
-- 
2.17.1



From cfsworks at gmail.com  Thu Dec  7 22:25:10 2023
From: cfsworks at gmail.com (Sam Edwards)
Date: Thu,  7 Dec 2023 23:25:10 -0700
Subject: [PATCH v2] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
Message-ID: <20231208062510.893392-1-CFSworks@gmail.com>

The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
will sometimes (varying between specific RK3588 chips, not over time) shut
off the DBI block, and reads to this range will instead stall
indefinitely.

When this happens, it will prevent Linux from booting altogether. The
PCIe driver will stall the CPU core once it attempts to read the version
information from the DBI range.

Fix this boot hang by adding the correct pinctrl configuration to the
PCIe 3.0 device node, which is the proper thing to do anyway. While
we're at it, also add the necessary configuration to the PCIe 2.0 node,
which may or may not fix the equivalent problem over there -- but is the
proper thing to do anyway. :)

Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
Signed-off-by: Sam Edwards <CFSworks at gmail.com>
---

Hi list,

Compared to v1, v2 removes the `reset-gpios` properties as well -- this should
give control of the PCIe resets exclusively to the PCIe cores. (And even if the
`reset-gpios` props had no effect in v1, it'd be confusing to have them there.)

Note that it is OK for the pcie2x1l1 node to refer to pcie30x1m1_pins. The
pcie2x1l1 device is *in fact* a PCIe 3.0 controller, and the pcie30x1m1_pins
pinmux setting is so-named to reflect this. The pcie2x1l1 node is so-named
because Linux does not (currently) support routing it to a PCIe 3.0 PHY; so in
practice it is effectively a PCIe 2.0 controller, for the time being.

Cheers and thank you for your time,
Sam

---
 .../boot/dts/rockchip/rk3588-turing-rk1.dtsi     | 16 ++--------------
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
index 9570b34aca2e..875446fdb67e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
@@ -214,8 +214,7 @@ rgmii_phy: ethernet-phy at 1 {
 &pcie2x1l1 {
 	linux,pci-domain = <1>;
 	pinctrl-names = "default";
-	pinctrl-0 = <&pcie2_reset>;
-	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+	pinctrl-0 = <&pcie30x1m1_pins>;
 	status = "okay";
 };
 
@@ -226,8 +225,7 @@ &pcie30phy {
 &pcie3x4 {
 	linux,pci-domain = <0>;
 	pinctrl-names = "default";
-	pinctrl-0 = <&pcie3_reset>;
-	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+	pinctrl-0 = <&pcie30x4m1_pins>;
 	vpcie3v3-supply = <&vcc3v3_pcie30>;
 	status = "okay";
 };
@@ -245,17 +243,7 @@ hym8563_int: hym8563-int {
 		};
 	};
 
-	pcie2 {
-		pcie2_reset: pcie2-reset {
-			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
-		};
-	};
-
 	pcie3 {
-		pcie3_reset: pcie3-reset {
-			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
-		};
-
 		vcc3v3_pcie30_en: pcie3-reg {
 			rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
-- 
2.41.0



From quic_snehshah at quicinc.com  Thu Dec  7 22:28:26 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Fri, 8 Dec 2023 11:58:26 +0530
Subject: [PATCH net-next] net: stmmac: qcom-ethqos: Add sysfs nodes for
 qcom ethqos
In-Reply-To: <0c966845-2bbc-4196-806d-6a33e435bf7d@lunn.ch>
References: <20231204084854.31543-1-quic_snehshah@quicinc.com>
 <3e4a1b9c-ed0f-466e-ba11-fc5b7ef308a1@lunn.ch>
 <5d5f3955-fc30-428c-99f4-42f9b7580a84@quicinc.com>
 <0c966845-2bbc-4196-806d-6a33e435bf7d@lunn.ch>
Message-ID: <dd585977-50c4-40a4-a664-0ecb5a84807a@quicinc.com>



On 12/6/2023 7:22 PM, Andrew Lunn wrote:
> On Wed, Dec 06, 2023 at 05:17:25PM +0530, Sneh Shah wrote:
>>
>>
>> On 12/5/2023 8:38 PM, Andrew Lunn wrote:
>>> On Mon, Dec 04, 2023 at 02:18:54PM +0530, Sneh Shah wrote:
>>>> Add sysfs nodes to conifigure routing of specific vlan id to GVM queue.
>>>> GVM queue is not exposed to PVM stmmac, so TC ops can't configure routing.
>>>
>>> Adding files in /sysfs has ~0 chance of being accepted.
>>>
>>> As requested, please explain what all these different hardware blocks
>>> are, and what you are trying to achieve. We can then recommend the
>>> correct interface.
>>>
>>>     Andrew
>>>
>>> ---
>>> pw-bot: cr
>>
> 
>> We have multiVM Architecture here. PVM will have stmmac running with
>> 4 Rx Tx queues. stmmac in PVM is responsible to configure whole
>> ethernet HW MAC/DMA/MTL ( including clocks, regulators and other
>> core bsp elements).
> 
> Please remember that stmmac is mostly used in embedded systems. People
> used to embedded systems generally don't know virtual machine
> terminology. So please spell out what PBM, GVM, etc mean.
> 
>> In GVM we have thin Ethernet driver, which is responsible to
>> configure and manage only 1 Rx/TX queue, i.e 5th Rx/Tx ethernet
>> queue. GVM can't access any other resisters apart from this 5th
>> queue specific MTL and DMA registers.
>  
>> We need to route vlan traffic of a specific Priority to GVM Queue
>> (Ethernet queue 5) via programming a MAC register. The MAC register
>> is not accessible in GVM and has to be programmed from PVM. stmmac
>> already has TC OPS to program this routing via vlan
>> priority. However, as PVM has only 4 queues enabled, TC tool will
>> not take 5th queue as input. Hence, these nodes were added to
>> conifure the MAC register to route specific vlan packets to 5th
>> queue in GVM.
>  
>> Note: The queues mentioned above are HW MTL Queues and DMA
>> Channels. The routing can be done in the HW itself based on vlan pcp
>> before the packets reach to driver.
> 
> Is the normal way you would do this is like this:
> 
> tc qdisc add dev eth1 parent root handle 100 \
> mqprio num_tc 4 \
> map 0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0 \
> queues 1 at 0 1 at 1 1 at 2 1 at 3 \
> hw 1
> 
> But you are saying that you cannot extend this to 5 queues?
> 
>     Andrew

Yes this can't extend to 5 queues. Because, stmmac in primary virtual machine will only have 4 netdev queues. So TC won't take input for 5th queue.


From ilkka at os.amperecomputing.com  Thu Dec  7 22:35:38 2023
From: ilkka at os.amperecomputing.com (Ilkka Koskinen)
Date: Thu, 7 Dec 2023 22:35:38 -0800 (PST)
Subject: [PATCH 5/5] perf/arm_cspmu: Add devicetree support
In-Reply-To: <23c9fc1e-dedd-4f27-8d84-3839b23c832d@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com> <7000cdf3a22afe684793863e81a1d96bbddb5db1.1701793996.git.robin.murphy@arm.com> <b7905a93-e4c-b6a6-d584-389131f4276@os.amperecomputing.com> <23c9fc1e-dedd-4f27-8d84-3839b23c832d@arm.com>
Message-ID: <38e991f1-5d4e-467a-7f9b-3cebd71fae7@os.amperecomputing.com>


On Thu, 7 Dec 2023, Robin Murphy wrote:
> On 2023-12-06 11:43 pm, Ilkka Koskinen wrote:
>> 
>> Hi Robin,
>> 
>> On Tue, 5 Dec 2023, Robin Murphy wrote:
>>> Hook up devicetree probing support. For now let's hope that people
>>> implement PMIIDR properly and we don't need an override mechanism.
>>> 
>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>> ---
>>> drivers/perf/arm_cspmu/arm_cspmu.c | 71 +++++++++++++++++++++++-------
>>> 1 file changed, 56 insertions(+), 15 deletions(-)
>>> 
>>> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c 
>>> b/drivers/perf/arm_cspmu/arm_cspmu.c
>>> index b64de4d800c7..80b5fc417ee3 100644
>>> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
>>> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
>>> @@ -27,6 +27,7 @@
>>> #include <linux/io-64-nonatomic-lo-hi.h>
>>> #include <linux/module.h>
>>> #include <linux/mutex.h>
>>> +#include <linux/of.h>
>>> #include <linux/perf_event.h>
>>> #include <linux/platform_device.h>
>>> 
>>> @@ -309,6 +310,10 @@ static const char *arm_cspmu_get_name(const struct 
>>> arm_cspmu *cspmu)
>>> ????static atomic_t pmu_idx[ACPI_APMT_NODE_TYPE_COUNT] = { 0 };
>>> 
>>> ????dev = cspmu->dev;
>>> +??? if (!has_acpi_companion(dev))
>> 
>> Am I missing something since this doesn't work on top of v6.7-rc4?
>> The problem I see is that has_acpi_companion() calls is_acpi_device_node(), 
>> which compares whether
>>
>>  ????fwnode->ops == &acpi_device_fwnode_ops;
>> 
>> However, the acpi/apmt code allocates fwnode by calling
>> acpi_alloc_fwnode_static(), which assigns &acpi_static_fwnode_ops
>> to ops.
>
> Ah, I hadn't got as far as considering that has_acpi_companion() might only 
> work for namespace devices, but it makes sense now that you point it out. I 
> should have clarified that I don't have any suitable ACPI system to test this 
> on, and have only been able to verify basic DT probing on an FPGA.

Ok, no problem. I'm always happy to give them a spin as soon as I find a 
little time.

Cheers, Ilkka


>
>> I wonder though, if is_acpi_device_node() should check the static variant 
>> too? :/
>
> Thanks for the tip, I'll look into that and try to come up with something 
> that works for a v2 (at worst there's always the traditional assumption that 
> !dev->of_node implies ACPI)
>
> Cheers,
> Robin.
>
>> 
>> Cheers, Ilkka
>> 
>>> +??????? return devm_kasprintf(dev, GFP_KERNEL, PMUNAME "_%u",
>>> +????????????????????? atomic_fetch_inc(&pmu_idx[0]));
>>> +
>>> ????apmt_node = arm_cspmu_apmt_node(dev);
>>> ????pmu_type = apmt_node->type;
>>> 
>>> @@ -406,7 +411,6 @@ static struct arm_cspmu_impl_match 
>>> *arm_cspmu_impl_match_get(u32 pmiidr)
>>> static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
>>> {
>>> ????int ret = 0;
>>> -??? struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(cspmu->dev);
>>> ????struct arm_cspmu_impl_match *match;
>>> 
>>> ????/* Start with a default PMU implementation */
>>> @@ -425,8 +429,12 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu 
>>> *cspmu)
>>> ????};
>>> 
>>> ????/* Firmware may override implementer/product ID from PMIIDR */
>>> -??? if (apmt_node->impl_id)
>>> -??????? cspmu->impl.pmiidr = apmt_node->impl_id;
>>> +??? if (has_acpi_companion(cspmu->dev)) {
>>> +??????? struct acpi_apmt_node *apmt_node = 
>>> arm_cspmu_apmt_node(cspmu->dev);
>>> +
>>> +??????? if (apmt_node->impl_id)
>>> +??????????? cspmu->impl.pmiidr = apmt_node->impl_id;
>>> +??? }
>>> 
>>> ????/* Find implementer specific attribute ops. */
>>> ????match = arm_cspmu_impl_match_get(cspmu->impl.pmiidr);
>>> @@ -928,7 +936,6 @@ static void arm_cspmu_read(struct perf_event *event)
>>> 
>>> static struct arm_cspmu *arm_cspmu_alloc(struct platform_device *pdev)
>>> {
>>> -??? struct acpi_apmt_node *apmt_node;
>>> ????struct arm_cspmu *cspmu;
>>> ????struct device *dev = &pdev->dev;
>>> 
>>> @@ -939,8 +946,13 @@ static struct arm_cspmu *arm_cspmu_alloc(struct 
>>> platform_device *pdev)
>>> ????cspmu->dev = dev;
>>> ????platform_set_drvdata(pdev, cspmu);
>>> 
>>> -??? apmt_node = arm_cspmu_apmt_node(dev);
>>> -??? cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
>>> +??? if (has_acpi_companion(dev)) {
>>> +??????? struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(dev);
>>> +
>>> +??????? cspmu->has_atomic_dword = apmt_node->flags & 
>>> ACPI_APMT_FLAGS_ATOMIC;
>>> +??? } else {
>>> +??????? cspmu->has_atomic_dword = device_property_read_bool(dev, 
>>> "arm,64-bit-atomic");
>>> +??? }
>>> 
>>> ????return cspmu;
>>> }
>>> @@ -1133,11 +1145,6 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu 
>>> *cspmu)
>>> ??????? }
>>> ????}
>>> 
>>> -??? if (cpumask_empty(&cspmu->associated_cpus)) {
>>> -??????? dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
>>> -??????? return -ENODEV;
>>> -??? }
>>> -
>>> ????return 0;
>>> }
>>> #else
>>> @@ -1147,9 +1154,36 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu 
>>> *cspmu)
>>> }
>>> #endif
>>> 
>>> +static int arm_cspmu_of_get_cpus(struct arm_cspmu *cspmu)
>>> +{
>>> +??? struct of_phandle_iterator it;
>>> +??? int ret, cpu;
>>> +
>>> +??? of_for_each_phandle(&it, ret, cspmu->dev->of_node, "cpus", NULL, 0) {
>>> +??????? cpu = of_cpu_node_to_id(it.node);
>>> +??????? if (cpu < 0)
>>> +??????????? continue;
>>> +??????? cpumask_set_cpu(cpu, &cspmu->associated_cpus);
>>> +??? }
>>> +??? return ret;
>>> +}
>>> +
>>> static int arm_cspmu_get_cpus(struct arm_cspmu *cspmu)
>>> {
>>> -??? return arm_cspmu_acpi_get_cpus(cspmu);
>>> +??? int ret = 0;
>>> +
>>> +??? if (has_acpi_companion(cspmu->dev))
>>> +??????? ret = arm_cspmu_acpi_get_cpus(cspmu);
>>> +??? else if (of_property_present(cspmu->dev->of_node, "cpus"))
>>> +??????? ret = arm_cspmu_of_get_cpus(cspmu);
>>> +??? else
>>> +??????? cpumask_copy(&cspmu->associated_cpus, cpu_possible_mask);
>>> +
>>> +??? if (!ret && cpumask_empty(&cspmu->associated_cpus)) {
>>> +??????? dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
>>> +??????? ret = -ENODEV;
>>> +??? }
>>> +??? return ret;
>>> }
>>> 
>>> static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
>>> @@ -1246,11 +1280,18 @@ static const struct platform_device_id 
>>> arm_cspmu_id[] = {
>>> };
>>> MODULE_DEVICE_TABLE(platform, arm_cspmu_id);
>>> 
>>> +static const struct of_device_id arm_cspmu_of_match[] = {
>>> +??? { .compatible = "arm,coresight-pmu" },
>>> +??? {}
>>> +};
>>> +MODULE_DEVICE_TABLE(of, arm_cspmu_of_match);
>>> +
>>> static struct platform_driver arm_cspmu_driver = {
>>> ????.driver = {
>>> -??????????? .name = DRVNAME,
>>> -??????????? .suppress_bind_attrs = true,
>>> -??????? },
>>> +??????? .name = DRVNAME,
>>> +??????? .of_match_table = arm_cspmu_of_match,
>>> +??????? .suppress_bind_attrs = true,
>>> +??? },
>>> ????.probe = arm_cspmu_device_probe,
>>> ????.remove = arm_cspmu_device_remove,
>>> ????.id_table = arm_cspmu_id,
>>> -- 
>>> 2.39.2.101.g768bb238c484.dirty
>>> 
>>> 
>

From yangyicong at huawei.com  Thu Dec  7 22:36:40 2023
From: yangyicong at huawei.com (Yicong Yang)
Date: Fri, 8 Dec 2023 14:36:40 +0800
Subject: [PATCH v4] perf stat: Support per-cluster aggregation
Message-ID: <20231208063640.25877-1-yangyicong@huawei.com>

From: Yicong Yang <yangyicong at hisilicon.com>

Some platforms have 'cluster' topology and CPUs in the cluster will
share resources like L3 Cache Tag (for HiSilicon Kunpeng SoC) or L2
cache (for Intel Jacobsville). Currently parsing and building cluster
topology have been supported since [1].

perf stat has already supported aggregation for other topologies like
die or socket, etc. It'll be useful to aggregate per-cluster to find
problems like L3T bandwidth contention.

This patch add support for "--per-cluster" option for per-cluster
aggregation. Also update the docs and related test. The output will
be like:

[root at localhost tmp]# perf stat -a -e LLC-load --per-cluster -- sleep 5

 Performance counter stats for 'system wide':

S56-D0-CLS158    4      1,321,521,570      LLC-load
S56-D0-CLS594    4        794,211,453      LLC-load
S56-D0-CLS1030    4             41,623      LLC-load
S56-D0-CLS1466    4             41,646      LLC-load
S56-D0-CLS1902    4             16,863      LLC-load
S56-D0-CLS2338    4             15,721      LLC-load
S56-D0-CLS2774    4             22,671      LLC-load
[...]

On a legacy system without cluster or cluster support, the output will
be look like:
[root at localhost perf]# perf stat -a -e cycles --per-cluster -- sleep 1

 Performance counter stats for 'system wide':

S56-D0-CLS0   64         18,011,485      cycles
S7182-D0-CLS0   64         16,548,835      cycles

Note that this patch doesn't mix the cluster information in the outputs
of --per-core to avoid breaking any tools/scripts using it.

Note that perf recently supports "--per-cache" aggregation, but it's not
the same with the cluster although cluster CPUs may share some cache
resources. For example on my machine all clusters within a die share the
same L3 cache:
$ cat /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list
0-31
$ cat /sys/devices/system/cpu/cpu0/topology/cluster_cpus_list
0-3

[1] commit c5e22feffdd7 ("topology: Represent clusters of CPUs within a die")
Tested-by: Jie Zhan <zhanjie9 at hisilicon.com>
Reviewed-by: Tim Chen <tim.c.chen at linux.intel.com>
Signed-off-by: Yicong Yang <yangyicong at hisilicon.com>
---
Change since v3:
- Rebase on v6.7-rc4 and resolve the conflicts
Link: https://lore.kernel.org/all/20230404104951.27537-1-yangyicong at huawei.com/

Change since v2:
- Use 0 as cluster ID on legacy system without cluster support, keep consistenct
  with what --per-die does.
Link: https://lore.kernel.org/all/20230328112717.19573-1-yangyicong at huawei.com/

Change since v1:
- Provides the information about how to map the cluster to the CPUs in the manual
- Thanks the review from Tim and test from Jie.
Link: https://lore.kernel.org/all/20230313085911.61359-1-yangyicong at huawei.com/

 tools/perf/Documentation/perf-stat.txt        | 11 ++++
 tools/perf/builtin-stat.c                     | 52 +++++++++++++++++--
 .../tests/shell/lib/perf_json_output_lint.py  |  4 +-
 tools/perf/tests/shell/lib/stat_output.sh     | 12 +++++
 tools/perf/tests/shell/stat+csv_output.sh     |  2 +
 tools/perf/tests/shell/stat+json_output.sh    | 13 +++++
 tools/perf/util/cpumap.c                      | 32 +++++++++++-
 tools/perf/util/cpumap.h                      | 19 +++++--
 tools/perf/util/env.h                         |  1 +
 tools/perf/util/stat-display.c                | 13 +++++
 tools/perf/util/stat.h                        |  1 +
 11 files changed, 151 insertions(+), 9 deletions(-)

diff --git a/tools/perf/Documentation/perf-stat.txt b/tools/perf/Documentation/perf-stat.txt
index 8f789fa1242e..2a34edda1763 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -308,6 +308,14 @@ use --per-die in addition to -a. (system-wide).  The output includes the
 die number and the number of online processors on that die. This is
 useful to gauge the amount of aggregation.
 
+--per-cluster::
+Aggregate counts per processor cluster for system-wide mode measurement.  This
+is a useful mode to detect imbalance between clusters.  To enable this mode,
+use --per-cluster in addition to -a. (system-wide).  The output includes the
+cluster number and the number of online processors on that cluster. This is
+useful to gauge the amount of aggregation. The information of cluster ID and
+related CPUs can be gotten from /sys/devices/system/cpu/cpuX/topology/cluster_{id, cpus}.
+
 --per-cache::
 Aggregate counts per cache instance for system-wide mode measurements.  By
 default, the aggregation happens for the cache level at the highest index
@@ -396,6 +404,9 @@ Aggregate counts per processor socket for system-wide mode measurements.
 --per-die::
 Aggregate counts per processor die for system-wide mode measurements.
 
+--per-cluster::
+Aggregate counts perf processor cluster for system-wide mode measurements.
+
 --per-cache::
 Aggregate counts per cache instance for system-wide mode measurements.  By
 default, the aggregation happens for the cache level at the highest index
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index a3af805a1d57..7cd93d3827b1 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1237,6 +1237,8 @@ static struct option stat_options[] = {
 		     "aggregate counts per processor socket", AGGR_SOCKET),
 	OPT_SET_UINT(0, "per-die", &stat_config.aggr_mode,
 		     "aggregate counts per processor die", AGGR_DIE),
+	OPT_SET_UINT(0, "per-cluster", &stat_config.aggr_mode,
+		     "aggregate counts per processor cluster", AGGR_CLUSTER),
 	OPT_CALLBACK_OPTARG(0, "per-cache", &stat_config.aggr_mode, &stat_config.aggr_level,
 			    "cache level", "aggregate count at this cache level (Default: LLC)",
 			    parse_cache_level),
@@ -1427,6 +1429,7 @@ static struct aggr_cpu_id aggr_cpu_id__cache(struct perf_cpu cpu, void *data)
 static const char *const aggr_mode__string[] = {
 	[AGGR_CORE] = "core",
 	[AGGR_CACHE] = "cache",
+	[AGGR_CLUSTER] = "cluster",
 	[AGGR_DIE] = "die",
 	[AGGR_GLOBAL] = "global",
 	[AGGR_NODE] = "node",
@@ -1454,6 +1457,12 @@ static struct aggr_cpu_id perf_stat__get_cache_id(struct perf_stat_config *confi
 	return aggr_cpu_id__cache(cpu, /*data=*/NULL);
 }
 
+static struct aggr_cpu_id perf_stat__get_cluster(struct perf_stat_config *config __maybe_unused,
+						 struct perf_cpu cpu)
+{
+	return aggr_cpu_id__cluster(cpu, /*data=*/NULL);
+}
+
 static struct aggr_cpu_id perf_stat__get_core(struct perf_stat_config *config __maybe_unused,
 					      struct perf_cpu cpu)
 {
@@ -1506,6 +1515,12 @@ static struct aggr_cpu_id perf_stat__get_die_cached(struct perf_stat_config *con
 	return perf_stat__get_aggr(config, perf_stat__get_die, cpu);
 }
 
+static struct aggr_cpu_id perf_stat__get_cluster_cached(struct perf_stat_config *config,
+							struct perf_cpu cpu)
+{
+	return perf_stat__get_aggr(config, perf_stat__get_cluster, cpu);
+}
+
 static struct aggr_cpu_id perf_stat__get_cache_id_cached(struct perf_stat_config *config,
 							 struct perf_cpu cpu)
 {
@@ -1543,6 +1558,8 @@ static aggr_cpu_id_get_t aggr_mode__get_aggr(enum aggr_mode aggr_mode)
 		return aggr_cpu_id__socket;
 	case AGGR_DIE:
 		return aggr_cpu_id__die;
+	case AGGR_CLUSTER:
+		return aggr_cpu_id__cluster;
 	case AGGR_CACHE:
 		return aggr_cpu_id__cache;
 	case AGGR_CORE:
@@ -1568,6 +1585,8 @@ static aggr_get_id_t aggr_mode__get_id(enum aggr_mode aggr_mode)
 		return perf_stat__get_socket_cached;
 	case AGGR_DIE:
 		return perf_stat__get_die_cached;
+	case AGGR_CLUSTER:
+		return perf_stat__get_cluster_cached;
 	case AGGR_CACHE:
 		return perf_stat__get_cache_id_cached;
 	case AGGR_CORE:
@@ -1736,6 +1755,21 @@ static struct aggr_cpu_id perf_env__get_cache_aggr_by_cpu(struct perf_cpu cpu,
 	return id;
 }
 
+static struct aggr_cpu_id perf_env__get_cluster_aggr_by_cpu(struct perf_cpu cpu,
+							    void *data)
+{
+	struct perf_env *env = data;
+	struct aggr_cpu_id id = aggr_cpu_id__empty();
+
+	if (cpu.cpu != -1) {
+		id.socket = env->cpu[cpu.cpu].socket_id;
+		id.die = env->cpu[cpu.cpu].die_id;
+		id.cluster = env->cpu[cpu.cpu].cluster_id;
+	}
+
+	return id;
+}
+
 static struct aggr_cpu_id perf_env__get_core_aggr_by_cpu(struct perf_cpu cpu, void *data)
 {
 	struct perf_env *env = data;
@@ -1743,12 +1777,12 @@ static struct aggr_cpu_id perf_env__get_core_aggr_by_cpu(struct perf_cpu cpu, vo
 
 	if (cpu.cpu != -1) {
 		/*
-		 * core_id is relative to socket and die,
-		 * we need a global id. So we set
-		 * socket, die id and core id
+		 * core_id is relative to socket, die and cluster, we need a
+		 * global id. So we set socket, die id, cluster id and core id.
 		 */
 		id.socket = env->cpu[cpu.cpu].socket_id;
 		id.die = env->cpu[cpu.cpu].die_id;
+		id.cluster = env->cpu[cpu.cpu].cluster_id;
 		id.core = env->cpu[cpu.cpu].core_id;
 	}
 
@@ -1804,6 +1838,12 @@ static struct aggr_cpu_id perf_stat__get_die_file(struct perf_stat_config *confi
 	return perf_env__get_die_aggr_by_cpu(cpu, &perf_stat.session->header.env);
 }
 
+static struct aggr_cpu_id perf_stat__get_cluster_file(struct perf_stat_config *config __maybe_unused,
+						      struct perf_cpu cpu)
+{
+	return perf_env__get_cluster_aggr_by_cpu(cpu, &perf_stat.session->header.env);
+}
+
 static struct aggr_cpu_id perf_stat__get_cache_file(struct perf_stat_config *config __maybe_unused,
 						    struct perf_cpu cpu)
 {
@@ -1841,6 +1881,8 @@ static aggr_cpu_id_get_t aggr_mode__get_aggr_file(enum aggr_mode aggr_mode)
 		return perf_env__get_socket_aggr_by_cpu;
 	case AGGR_DIE:
 		return perf_env__get_die_aggr_by_cpu;
+	case AGGR_CLUSTER:
+		return perf_env__get_cluster_aggr_by_cpu;
 	case AGGR_CACHE:
 		return perf_env__get_cache_aggr_by_cpu;
 	case AGGR_CORE:
@@ -1866,6 +1908,8 @@ static aggr_get_id_t aggr_mode__get_id_file(enum aggr_mode aggr_mode)
 		return perf_stat__get_socket_file;
 	case AGGR_DIE:
 		return perf_stat__get_die_file;
+	case AGGR_CLUSTER:
+		return perf_stat__get_cluster_file;
 	case AGGR_CACHE:
 		return perf_stat__get_cache_file;
 	case AGGR_CORE:
@@ -2397,6 +2441,8 @@ static int __cmd_report(int argc, const char **argv)
 		     "aggregate counts per processor socket", AGGR_SOCKET),
 	OPT_SET_UINT(0, "per-die", &perf_stat.aggr_mode,
 		     "aggregate counts per processor die", AGGR_DIE),
+	OPT_SET_UINT(0, "per-cluster", &perf_stat.aggr_mode,
+		     "aggregate counts perf processor cluster", AGGR_CLUSTER),
 	OPT_CALLBACK_OPTARG(0, "per-cache", &perf_stat.aggr_mode, &perf_stat.aggr_level,
 			    "cache level",
 			    "aggregate count at this cache level (Default: LLC)",
diff --git a/tools/perf/tests/shell/lib/perf_json_output_lint.py b/tools/perf/tests/shell/lib/perf_json_output_lint.py
index ea55d5ea1ced..abc1fd737782 100644
--- a/tools/perf/tests/shell/lib/perf_json_output_lint.py
+++ b/tools/perf/tests/shell/lib/perf_json_output_lint.py
@@ -15,6 +15,7 @@ ap.add_argument('--event', action='store_true')
 ap.add_argument('--per-core', action='store_true')
 ap.add_argument('--per-thread', action='store_true')
 ap.add_argument('--per-cache', action='store_true')
+ap.add_argument('--per-cluster', action='store_true')
 ap.add_argument('--per-die', action='store_true')
 ap.add_argument('--per-node', action='store_true')
 ap.add_argument('--per-socket', action='store_true')
@@ -49,6 +50,7 @@ def check_json_output(expected_items):
       'cgroup': lambda x: True,
       'cpu': lambda x: isint(x),
       'cache': lambda x: True,
+      'cluster': lambda x: True,
       'die': lambda x: True,
       'event': lambda x: True,
       'event-runtime': lambda x: isfloat(x),
@@ -88,7 +90,7 @@ try:
     expected_items = 7
   elif args.interval or args.per_thread or args.system_wide_no_aggr:
     expected_items = 8
-  elif args.per_core or args.per_socket or args.per_node or args.per_die or args.per_cache:
+  elif args.per_core or args.per_socket or args.per_node or args.per_die or args.per_cluster or args.per_cache:
     expected_items = 9
   else:
     # If no option is specified, don't check the number of items.
diff --git a/tools/perf/tests/shell/lib/stat_output.sh b/tools/perf/tests/shell/lib/stat_output.sh
index 3cc158a64326..c81d6a9f7983 100644
--- a/tools/perf/tests/shell/lib/stat_output.sh
+++ b/tools/perf/tests/shell/lib/stat_output.sh
@@ -97,6 +97,18 @@ check_per_cache_instance()
 	echo "[Success]"
 }
 
+check_per_cluster()
+{
+	echo -n "Checking $1 output: per cluster "
+	if ParanoidAndNotRoot 0
+	then
+		echo "[Skip] paranoid and not root"
+		return
+	fi
+	perf stat --per-cluster -a $2 true
+	echo "[Success]"
+}
+
 check_per_die()
 {
 	echo -n "Checking $1 output: per die "
diff --git a/tools/perf/tests/shell/stat+csv_output.sh b/tools/perf/tests/shell/stat+csv_output.sh
index f1818fa6d9ce..fc2d8cc6e5e0 100755
--- a/tools/perf/tests/shell/stat+csv_output.sh
+++ b/tools/perf/tests/shell/stat+csv_output.sh
@@ -42,6 +42,7 @@ function commachecker()
 	;; "--per-socket")	exp=8
 	;; "--per-node")	exp=8
 	;; "--per-die")		exp=8
+	;; "--per-cluster")	exp=8
 	;; "--per-cache")	exp=8
 	esac
 
@@ -79,6 +80,7 @@ then
 	check_system_wide_no_aggr "CSV" "$perf_cmd"
 	check_per_core "CSV" "$perf_cmd"
 	check_per_cache_instance "CSV" "$perf_cmd"
+	check_per_cluster "CSV" "$perf_cmd"
 	check_per_die "CSV" "$perf_cmd"
 	check_per_socket "CSV" "$perf_cmd"
 else
diff --git a/tools/perf/tests/shell/stat+json_output.sh b/tools/perf/tests/shell/stat+json_output.sh
index 196e22672c50..4e278fb3a9dd 100755
--- a/tools/perf/tests/shell/stat+json_output.sh
+++ b/tools/perf/tests/shell/stat+json_output.sh
@@ -132,6 +132,18 @@ check_per_cache_instance()
 	echo "[Success]"
 }
 
+check_per_cluster()
+{
+	echo -n "Checking json output: per cluster "
+	if ParanoidAndNotRoot 0
+	then
+		echo "[Skip] paranoia and not root"
+		return
+	fi
+	perf stat -j --per-cluster -a true 2>&1 | $PYTHON $pythonchecker --per-cluster
+	echo "[Success]"
+}
+
 check_per_die()
 {
 	echo -n "Checking json output: per die "
@@ -210,6 +222,7 @@ then
 	check_system_wide_no_aggr
 	check_per_core
 	check_per_cache_instance
+	check_per_cluster
 	check_per_die
 	check_per_socket
 else
diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
index 0e090e8bc334..565a8ecb65a8 100644
--- a/tools/perf/util/cpumap.c
+++ b/tools/perf/util/cpumap.c
@@ -222,6 +222,8 @@ static int aggr_cpu_id__cmp(const void *a_pointer, const void *b_pointer)
 		return a->socket - b->socket;
 	else if (a->die != b->die)
 		return a->die - b->die;
+	else if (a->cluster != b->cluster)
+		return a->cluster - b->cluster;
 	else if (a->cache_lvl != b->cache_lvl)
 		return a->cache_lvl - b->cache_lvl;
 	else if (a->cache != b->cache)
@@ -309,6 +311,29 @@ struct aggr_cpu_id aggr_cpu_id__die(struct perf_cpu cpu, void *data)
 	return id;
 }
 
+int cpu__get_cluster_id(struct perf_cpu cpu)
+{
+	int value, ret = cpu__get_topology_int(cpu.cpu, "cluster_id", &value);
+	return ret ?: value;
+}
+
+struct aggr_cpu_id aggr_cpu_id__cluster(struct perf_cpu cpu, void *data)
+{
+	int cluster = cpu__get_cluster_id(cpu);
+	struct aggr_cpu_id id;
+
+	/* There is no cluster_id on legacy system. */
+	if (cluster == -1)
+		cluster = 0;
+
+	id = aggr_cpu_id__die(cpu, data);
+	if (aggr_cpu_id__is_empty(&id))
+		return id;
+
+	id.cluster = cluster;
+	return id;
+}
+
 int cpu__get_core_id(struct perf_cpu cpu)
 {
 	int value, ret = cpu__get_topology_int(cpu.cpu, "core_id", &value);
@@ -320,8 +345,8 @@ struct aggr_cpu_id aggr_cpu_id__core(struct perf_cpu cpu, void *data)
 	struct aggr_cpu_id id;
 	int core = cpu__get_core_id(cpu);
 
-	/* aggr_cpu_id__die returns a struct with socket and die set. */
-	id = aggr_cpu_id__die(cpu, data);
+	/* aggr_cpu_id__die returns a struct with socket die, and cluster set. */
+	id = aggr_cpu_id__cluster(cpu, data);
 	if (aggr_cpu_id__is_empty(&id))
 		return id;
 
@@ -683,6 +708,7 @@ bool aggr_cpu_id__equal(const struct aggr_cpu_id *a, const struct aggr_cpu_id *b
 		a->node == b->node &&
 		a->socket == b->socket &&
 		a->die == b->die &&
+		a->cluster == b->cluster &&
 		a->cache_lvl == b->cache_lvl &&
 		a->cache == b->cache &&
 		a->core == b->core &&
@@ -695,6 +721,7 @@ bool aggr_cpu_id__is_empty(const struct aggr_cpu_id *a)
 		a->node == -1 &&
 		a->socket == -1 &&
 		a->die == -1 &&
+		a->cluster == -1 &&
 		a->cache_lvl == -1 &&
 		a->cache == -1 &&
 		a->core == -1 &&
@@ -708,6 +735,7 @@ struct aggr_cpu_id aggr_cpu_id__empty(void)
 		.node = -1,
 		.socket = -1,
 		.die = -1,
+		.cluster = -1,
 		.cache_lvl = -1,
 		.cache = -1,
 		.core = -1,
diff --git a/tools/perf/util/cpumap.h b/tools/perf/util/cpumap.h
index 9df2aeb34d3d..26cf76c693f5 100644
--- a/tools/perf/util/cpumap.h
+++ b/tools/perf/util/cpumap.h
@@ -20,6 +20,8 @@ struct aggr_cpu_id {
 	int socket;
 	/** The die id as read from /sys/devices/system/cpu/cpuX/topology/die_id. */
 	int die;
+	/** The cluster id as read from /sys/devices/system/cpu/cpuX/topology/cluster_id */
+	int cluster;
 	/** The cache level as read from /sys/devices/system/cpu/cpuX/cache/indexY/level */
 	int cache_lvl;
 	/**
@@ -86,6 +88,11 @@ int cpu__get_socket_id(struct perf_cpu cpu);
  * /sys/devices/system/cpu/cpuX/topology/die_id for the given CPU.
  */
 int cpu__get_die_id(struct perf_cpu cpu);
+/**
+ * cpu__get_cluster_id - Returns the cluster id as read from
+ * /sys/devices/system/cpu/cpuX/topology/cluster_id for the given CPU
+ */
+int cpu__get_cluster_id(struct perf_cpu cpu);
 /**
  * cpu__get_core_id - Returns the core id as read from
  * /sys/devices/system/cpu/cpuX/topology/core_id for the given CPU.
@@ -127,9 +134,15 @@ struct aggr_cpu_id aggr_cpu_id__socket(struct perf_cpu cpu, void *data);
  */
 struct aggr_cpu_id aggr_cpu_id__die(struct perf_cpu cpu, void *data);
 /**
- * aggr_cpu_id__core - Create an aggr_cpu_id with the core, die and socket
- * populated with the core, die and socket for cpu. The function signature is
- * compatible with aggr_cpu_id_get_t.
+ * aggr_cpu_id__cluster - Create an aggr_cpu_id with cluster, die and socket
+ * populated with the cluster, die and socket for cpu. The function signature
+ * is compatible with aggr_cpu_id_get_t.
+ */
+struct aggr_cpu_id aggr_cpu_id__cluster(struct perf_cpu cpu, void *data);
+/**
+ * aggr_cpu_id__core - Create an aggr_cpu_id with the core, cluster, die and
+ * socket populated with the core, die and socket for cpu. The function
+ * signature is compatible with aggr_cpu_id_get_t.
  */
 struct aggr_cpu_id aggr_cpu_id__core(struct perf_cpu cpu, void *data);
 /**
diff --git a/tools/perf/util/env.h b/tools/perf/util/env.h
index 4566c51f2fd9..e288649627d5 100644
--- a/tools/perf/util/env.h
+++ b/tools/perf/util/env.h
@@ -12,6 +12,7 @@ struct perf_cpu_map;
 struct cpu_topology_map {
 	int	socket_id;
 	int	die_id;
+	int	cluster_id;
 	int	core_id;
 };
 
diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
index afe6db8e7bf4..7309c43cdba7 100644
--- a/tools/perf/util/stat-display.c
+++ b/tools/perf/util/stat-display.c
@@ -201,6 +201,9 @@ static void print_aggr_id_std(struct perf_stat_config *config,
 		snprintf(buf, sizeof(buf), "S%d-D%d-L%d-ID%d",
 			 id.socket, id.die, id.cache_lvl, id.cache);
 		break;
+	case AGGR_CLUSTER:
+		snprintf(buf, sizeof(buf), "S%d-D%d-CLS%d", id.socket, id.die, id.cluster);
+		break;
 	case AGGR_DIE:
 		snprintf(buf, sizeof(buf), "S%d-D%d", id.socket, id.die);
 		break;
@@ -251,6 +254,10 @@ static void print_aggr_id_csv(struct perf_stat_config *config,
 		fprintf(config->output, "S%d-D%d-L%d-ID%d%s%d%s",
 			id.socket, id.die, id.cache_lvl, id.cache, sep, aggr_nr, sep);
 		break;
+	case AGGR_CLUSTER:
+		fprintf(config->output, "S%d-D%d-CLS%d%s%d%s",
+			id.socket, id.die, id.cluster, sep, aggr_nr, sep);
+		break;
 	case AGGR_DIE:
 		fprintf(output, "S%d-D%d%s%d%s",
 			id.socket, id.die, sep, aggr_nr, sep);
@@ -300,6 +307,10 @@ static void print_aggr_id_json(struct perf_stat_config *config,
 		fprintf(output, "\"cache\" : \"S%d-D%d-L%d-ID%d\", \"aggregate-number\" : %d, ",
 			id.socket, id.die, id.cache_lvl, id.cache, aggr_nr);
 		break;
+	case AGGR_CLUSTER:
+		fprintf(output, "\"cluster\" : \"S%d-D%d-CLS%d\", \"aggregate-number\" : %d, ",
+			id.socket, id.die, id.cluster, aggr_nr);
+		break;
 	case AGGR_DIE:
 		fprintf(output, "\"die\" : \"S%d-D%d\", \"aggregate-number\" : %d, ",
 			id.socket, id.die, aggr_nr);
@@ -1248,6 +1259,7 @@ static void print_header_interval_std(struct perf_stat_config *config,
 	case AGGR_NODE:
 	case AGGR_SOCKET:
 	case AGGR_DIE:
+	case AGGR_CLUSTER:
 	case AGGR_CACHE:
 	case AGGR_CORE:
 		fprintf(output, "#%*s %-*s cpus",
@@ -1550,6 +1562,7 @@ void evlist__print_counters(struct evlist *evlist, struct perf_stat_config *conf
 	switch (config->aggr_mode) {
 	case AGGR_CORE:
 	case AGGR_CACHE:
+	case AGGR_CLUSTER:
 	case AGGR_DIE:
 	case AGGR_SOCKET:
 	case AGGR_NODE:
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index 325d0fad1842..df8732f8f898 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -48,6 +48,7 @@ enum aggr_mode {
 	AGGR_GLOBAL,
 	AGGR_SOCKET,
 	AGGR_DIE,
+	AGGR_CLUSTER,
 	AGGR_CACHE,
 	AGGR_CORE,
 	AGGR_THREAD,
-- 
2.24.0



From Jiangfeng.Ma at synopsys.com  Thu Dec  7 23:02:19 2023
From: Jiangfeng.Ma at synopsys.com (Jiangfeng Ma)
Date: Fri, 8 Dec 2023 07:02:19 +0000
Subject: [PATCH] net:stmmac:stmmac_platform:Add snps,xpcs devicetree parsing
Message-ID: <SA0PR12MB44138E48A245378CF54D2F9ED98AA@SA0PR12MB4413.namprd12.prod.outlook.com>

In order to setup xpcs, has_xpcs must be set to a non-zero value.
Add new optional devicetree properties representing this.

If has_xpcs is set to true, then xpcs_an_inband should preferably be
consistent with it, Otherwise, some errors may occur when starting
the network, For example, the phy interface that xpcs already supports,
but link up fails.

The types of has_xpcs and xpcs_an_inband are unsigned int,
and generally used as flags. So it may be more reasonable to set them to
bool type. This can also be confirmed from the type of @ovr_an_inband.

Signed-off-by: Jiangfeng Ma <Jiangfeng.Ma at synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +++++
 include/linux/stmmac.h                                | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1ffde55..6ebc2a9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -324,6 +324,7 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
 			 struct device_node *np, struct device *dev)
 {
 	bool mdio = !of_phy_is_fixed_link(np);
+	bool has_xpcs = false;
 	static const struct of_device_id need_mdio_ids[] = {
 		{ .compatible = "snps,dwc-qos-ethernet-4.10" },
 		{},
@@ -345,6 +346,7 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
 
 	if (plat->mdio_node) {
 		dev_dbg(dev, "Found MDIO subnode\n");
+		has_xpcs = of_property_read_bool(plat->mdio_node, "snps,xpcs");
 		mdio = true;
 	}
 
@@ -356,6 +358,9 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
 			return -ENOMEM;
 
 		plat->mdio_bus_data->needs_reset = true;
+		plat->mdio_bus_data->has_xpcs = has_xpcs;
+		if (plat->mdio_bus_data->has_xpcs)
+			plat->mdio_bus_data->xpcs_an_inband = true;
 	}
 
 	return 0;
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index dee5ad6..dea35ee 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -82,8 +82,8 @@
 
 struct stmmac_mdio_bus_data {
 	unsigned int phy_mask;
-	unsigned int has_xpcs;
-	unsigned int xpcs_an_inband;
+	bool has_xpcs;
+	bool xpcs_an_inband;
 	int *irqs;
 	int probed_phy_irq;
 	bool needs_reset;
-- 
1.8.3.1


From devnull+xianwei.zhao.amlogic.com at kernel.org  Thu Dec  7 23:16:25 2023
From: devnull+xianwei.zhao.amlogic.com at kernel.org (Xianwei Zhao via B4 Relay)
Date: Fri, 08 Dec 2023 15:16:25 +0800
Subject: [PATCH v2 0/2] Add some devices nodes for S4.
Message-ID: <20231208-s4-dts-v2-0-5a93fa356c5d@amlogic.com>

Add some device nodes for SoC S4, including periphs clock controller
node, PLL clock controller node, I2C nodes, SPICC node, NAND
controller node, Ethernet MAC and PHY node.

Add reserved memory for board AQ222 which is used by ATF.
Enable NAND, SPICC nodes for board AQ222.

---
Changes in v2:
- Separate and independent commit for dts file.
- Revision format error.
- Add comment for resered memory.
- Link to v1: https://lore.kernel.org/all/20231129092949.2103338-1-xianwei.zhao at amlogic.com/

Signed-off-by: Xianwei Zhao <xianwei.zhao at amlogic.com>

---
Xianwei Zhao (2):
      arm64: dts: amlogic: add some device nodes for S4
      arm64: dts: amlogic: enable some nodes for board AQ222

 .../boot/dts/amlogic/meson-s4-s805x2-aq222.dts     |  56 ++++
 arch/arm64/boot/dts/amlogic/meson-s4.dtsi          | 350 ++++++++++++++++++++-
 2 files changed, 405 insertions(+), 1 deletion(-)
---
base-commit: 093098370b4693b0da8b7fdf5fd212cb46705928
change-id: 20231208-s4-dts-24debd656209

Best regards,
-- 
Xianwei Zhao <xianwei.zhao at amlogic.com>



From devnull+xianwei.zhao.amlogic.com at kernel.org  Thu Dec  7 23:16:27 2023
From: devnull+xianwei.zhao.amlogic.com at kernel.org (Xianwei Zhao via B4 Relay)
Date: Fri, 08 Dec 2023 15:16:27 +0800
Subject: [PATCH v2 2/2] arm64: dts: amlogic: enable some nodes for board
 AQ222
In-Reply-To: <20231208-s4-dts-v2-0-5a93fa356c5d@amlogic.com>
References: <20231208-s4-dts-v2-0-5a93fa356c5d@amlogic.com>
Message-ID: <20231208-s4-dts-v2-2-5a93fa356c5d@amlogic.com>

From: Xianwei Zhao <xianwei.zhao at amlogic.com>

Add reserved memory for board AQ222 which is used by ATF.
Enable NAND, SPICC nodes for board AQ222.

Signed-off-by: Xianwei Zhao <xianwei.zhao at amlogic.com>
---
 .../boot/dts/amlogic/meson-s4-s805x2-aq222.dts     | 56 ++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
index c1f322c73982..18789242f05f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
@@ -23,6 +23,17 @@ memory at 0 {
 		reg = <0x0 0x0 0x0 0x40000000>;
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/* 52 MiB reserved for ARM Trusted Firmware */
+		secmon_reserved: secmon at 5000000 {
+			reg = <0x0 0x05000000 0x0 0x3400000>;
+			no-map;
+		};
+	};
 };
 
 &uart_B {
@@ -34,3 +45,48 @@ &ir {
 	pinctrl-0 = <&remote_pins>;
 	pinctrl-names = "default";
 };
+
+&nand {
+	status = "okay";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	pinctrl-0 = <&nand_pins>;
+	pinctrl-names = "default";
+
+	nand at 0 {
+		reg = <0>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		nand-on-flash-bbt;
+
+		partition at 0 {
+			label = "boot";
+			reg = <0x0 0x00200000>;
+		};
+		partition at 200000 {
+			label = "env";
+			reg = <0x00200000 0x00400000>;
+		};
+		partition at 600000 {
+			label = "system";
+			reg = <0x00600000 0x00a00000>;
+		};
+		partition at 1000000 {
+			label = "rootfs";
+			reg = <0x01000000 0x03000000>;
+		};
+		partition at 4000000 {
+			label = "media";
+			reg = <0x04000000 0x8000000>;
+		};
+	};
+};
+
+&spicc0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&spicc0_pins_x>;
+	cs-gpios = <&gpio GPIOX_10 GPIO_ACTIVE_LOW>;
+};

-- 
2.37.1



From devnull+xianwei.zhao.amlogic.com at kernel.org  Thu Dec  7 23:16:26 2023
From: devnull+xianwei.zhao.amlogic.com at kernel.org (Xianwei Zhao via B4 Relay)
Date: Fri, 08 Dec 2023 15:16:26 +0800
Subject: [PATCH v2 1/2] arm64: dts: amlogic: add some device nodes for S4
In-Reply-To: <20231208-s4-dts-v2-0-5a93fa356c5d@amlogic.com>
References: <20231208-s4-dts-v2-0-5a93fa356c5d@amlogic.com>
Message-ID: <20231208-s4-dts-v2-1-5a93fa356c5d@amlogic.com>

From: Xianwei Zhao <xianwei.zhao at amlogic.com>

Add some device nodes for SoC S4, including periphs clock controller
node, PLL clock controller node, I2C nodes, SPICC node, NAND
controller node, Ethernet MAC and PHY node.

Signed-off-by: Xianwei Zhao <xianwei.zhao at amlogic.com>
---
 arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 350 +++++++++++++++++++++++++++++-
 1 file changed, 349 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
index 2344b2d741c3..c6b524e1a1ee 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
@@ -6,6 +6,10 @@
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/gpio/meson-s4-gpio.h>
+#include <dt-bindings/clock/amlogic,s4-pll-clkc.h>
+#include <dt-bindings/clock/amlogic,s4-peripherals-clkc.h>
+#include <dt-bindings/power/meson-s4-power.h>
 
 / {
 	cpus {
@@ -92,6 +96,38 @@ apb4: bus at fe000000 {
 			#size-cells = <2>;
 			ranges = <0x0 0x0 0x0 0xfe000000 0x0 0x480000>;
 
+			clkc_periphs: clock-controller at 0 {
+				compatible = "amlogic,s4-peripherals-clkc";
+				reg = <0x0 0x0 0x0 0x49c>;
+				clocks = <&clkc_pll CLKID_FCLK_DIV2>,
+					<&clkc_pll CLKID_FCLK_DIV2P5>,
+					<&clkc_pll CLKID_FCLK_DIV3>,
+					<&clkc_pll CLKID_FCLK_DIV4>,
+					<&clkc_pll CLKID_FCLK_DIV5>,
+					<&clkc_pll CLKID_FCLK_DIV7>,
+					<&clkc_pll CLKID_HIFI_PLL>,
+					<&clkc_pll CLKID_GP0_PLL>,
+					<&clkc_pll CLKID_MPLL0>,
+					<&clkc_pll CLKID_MPLL1>,
+					<&clkc_pll CLKID_MPLL2>,
+					<&clkc_pll CLKID_MPLL3>,
+					<&clkc_pll CLKID_HDMI_PLL>,
+					<&xtal>;
+				clock-names = "fclk_div2", "fclk_div2p5", "fclk_div3",
+						"fclk_div4", "fclk_div5", "fclk_div7",
+						"hifi_pll", "gp0_pll", "mpll0", "mpll1",
+						"mpll2", "mpll3", "hdmi_pll", "xtal";
+				#clock-cells = <1>;
+			};
+
+			clkc_pll: clock-controller at 8000 {
+				compatible = "amlogic,s4-pll-clkc";
+				reg = <0x0 0x8000 0x0 0x1e8>;
+				clocks = <&xtal>;
+				clock-names = "xtal";
+				#clock-cells = <1>;
+			};
+
 			watchdog at 2100 {
 				compatible = "amlogic,s4-wdt", "amlogic,t7-wdt";
 				reg = <0x0 0x2100 0x0 0x10>;
@@ -120,6 +156,187 @@ mux {
 						bias-disable;
 					};
 				};
+
+				i2c0_pins1: i2c0-pins1 {
+					mux {
+						groups = "i2c0_sda",
+						       "i2c0_scl";
+						function = "i2c0";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c1_pins1: i2c1-pins1 {
+					mux {
+						groups = "i2c1_sda_c",
+						       "i2c1_scl_c";
+						function = "i2c1";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c1_pins2: i2c1-pins2 {
+					mux {
+						groups = "i2c1_sda_d",
+						       "i2c1_scl_d";
+						function = "i2c1";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c1_pins3: i2c1-pins3 {
+					mux {
+						groups = "i2c1_sda_h",
+						       "i2c1_scl_h";
+						function = "i2c1";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c1_pins4: i2c1-pins4 {
+					mux {
+						groups = "i2c1_sda_x",
+						       "i2c1_scl_x";
+						function = "i2c1";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c2_pins1: i2c2-pins1 {
+					mux {
+						groups = "i2c2_sda_d",
+						       "i2c2_scl_d";
+						function = "i2c2";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c2_pins2: i2c2-pins2 {
+					mux {
+						groups = "i2c2_sda_h8",
+						       "i2c2_scl_h9";
+						function = "i2c2";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c2_pins3: i2c2-pins3 {
+					mux {
+						groups = "i2c2_sda_h0",
+						       "i2c2_scl_h1";
+						function = "i2c2";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c3_pins1: i2c3-pins1 {
+					mux {
+						groups = "i2c3_sda_x",
+						       "i2c3_scl_x";
+						function = "i2c3";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c3_pins2: i2c3-pins2 {
+					mux {
+						groups = "i2c3_sda_z",
+						       "i2c3_scl_z";
+						function = "i2c3";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c4_pins1: i2c4-pins1 {
+					mux {
+						groups = "i2c4_sda_c",
+						       "i2c4_scl_c";
+						function = "i2c4";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c4_pins2: i2c4-pins2 {
+					mux {
+						groups = "i2c4_sda_d",
+						       "i2c4_scl_d";
+						function = "i2c4";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				i2c4_pins3: i2c4-pins3 {
+					mux {
+						groups = "i2c4_sda_z",
+						       "i2c4_scl_z";
+						function = "i2c4";
+						drive-strength-microamp = <3000>;
+						bias-disable;
+					};
+				};
+
+				nand_pins: nand-pins {
+					mux {
+						groups = "emmc_nand_d0",
+						       "emmc_nand_d1",
+						       "emmc_nand_d2",
+						       "emmc_nand_d3",
+						       "emmc_nand_d4",
+						       "emmc_nand_d5",
+						       "emmc_nand_d6",
+						       "emmc_nand_d7",
+						       "nand_ce0",
+						       "nand_ale",
+						       "nand_cle",
+						       "nand_wen_clk",
+						       "nand_ren_wr";
+						function = "nand";
+						input-enable;
+					};
+				};
+
+				spicc0_pins_x: spicc0-pins_x {
+					mux {
+						groups = "spi_a_mosi_x",
+						       "spi_a_miso_x",
+						       "spi_a_clk_x";
+						function = "spi_a";
+						drive-strength-microamp = <3000>;
+					};
+				};
+
+				spicc0_pins_h: spicc0-pins-h {
+					mux {
+						groups = "spi_a_mosi_h",
+						       "spi_a_miso_h",
+						       "spi_a_clk_h";
+						function = "spi_a";
+						drive-strength-microamp = <3000>;
+					};
+				};
+
+				spicc0_pins_z: spicc0-pins-z {
+					mux {
+						groups = "spi_a_mosi_z",
+						       "spi_a_miso_z",
+						       "spi_a_clk_z";
+						function = "spi_a";
+						drive-strength-microamp = <3000>;
+					};
+				};
+
 			};
 
 			gpio_intc: interrupt-controller at 4080 {
@@ -132,13 +349,119 @@ gpio_intc: interrupt-controller at 4080 {
 					<10 11 12 13 14 15 16 17 18 19 20 21>;
 			};
 
+			eth_phy: mdio-multiplexer at 28000 {
+				compatible = "amlogic,g12a-mdio-mux";
+				reg = <0x0 0x28000 0x0 0xa4>;
+
+				#address-cells = <1>;
+				#size-cells = <0>;
+				clocks = <&clkc_periphs CLKID_ETHPHY>,
+					 <&xtal>,
+					 <&clkc_pll CLKID_MPLL_50M>;
+				clock-names = "pclk", "clkin0", "clkin1";
+				mdio-parent-bus = <&mdio0>;
+
+				ext_mdio: mdio at 0 {
+					reg = <0>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+				};
+
+				int_mdio: mdio at 1 {
+					reg = <1>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					internal_ephy: ethernet-phy at 8 {
+						compatible = "ethernet-phy-id0180.3301",
+							     "ethernet-phy-ieee802.3-c22";
+						interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+						reg = <8>;
+						max-speed = <100>;
+					};
+				};
+			};
+
+			spicc0: spi at 50000 {
+				compatible = "amlogic,meson-g12a-spicc";
+				reg = <0x0 0x50000 0x0 0x44>;
+				interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&clkc_periphs CLKID_SPICC0>,
+					 <&clkc_periphs CLKID_SPICC0_EN>;
+				clock-names = "core", "pclk";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c0: i2c at 66000 {
+				compatible = "amlogic,meson-axg-i2c";
+				reg = <0x0 0x66000 0x0 0x20>;
+				interrupts = <GIC_SPI 160 IRQ_TYPE_EDGE_RISING>;
+				clocks = <&clkc_periphs CLKID_I2C_M_A>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c1: i2c at 68000 {
+				compatible = "amlogic,meson-axg-i2c";
+				reg = <0x0 0x68000 0x0 0x20>;
+				interrupts = <GIC_SPI 161 IRQ_TYPE_EDGE_RISING>;
+				clocks = <&clkc_periphs CLKID_I2C_M_B>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c2: i2c at 6a000 {
+				compatible = "amlogic,meson-axg-i2c";
+				reg = <0x0 0x6a000 0x0 0x20>;
+				interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
+				clocks = <&clkc_periphs CLKID_I2C_M_C>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c3: i2c at 6c000 {
+				compatible = "amlogic,meson-axg-i2c";
+				reg = <0x0 0x6c000 0x0 0x20>;
+				interrupts = <GIC_SPI 163 IRQ_TYPE_EDGE_RISING>;
+				clocks = <&clkc_periphs CLKID_I2C_M_D>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c4: i2c at 6e000 {
+				compatible = "amlogic,meson-axg-i2c";
+				reg = <0x0 0x6e000 0x0 0x20>;
+				interrupts = <GIC_SPI 164 IRQ_TYPE_EDGE_RISING>;
+				clocks = <&clkc_periphs CLKID_I2C_M_E>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			nand: nand-controller at 8c800 {
+				compatible = "amlogic,meson-axg-nfc";
+				reg = <0x0 0x8c800 0x0 0x100>, <0x0 0x8c000 0x0 0x4>;
+				reg-names = "nfc", "emmc";
+				interrupts = <GIC_SPI 175 IRQ_TYPE_EDGE_RISING>;
+				clocks = <&clkc_periphs CLKID_SD_EMMC_C>,
+					<&clkc_pll CLKID_FCLK_DIV2>;
+				clock-names = "core", "device";
+				status = "disabled";
+			};
+
 			uart_B: serial at 7a000 {
 				compatible = "amlogic,meson-s4-uart",
 					     "amlogic,meson-ao-uart";
 				reg = <0x0 0x7a000 0x0 0x18>;
 				interrupts = <GIC_SPI 169 IRQ_TYPE_EDGE_RISING>;
 				status = "disabled";
-				clocks = <&xtal>, <&xtal>, <&xtal>;
+				clocks = <&xtal>, <&clkc_periphs CLKID_UART_B>, <&xtal>;
 				clock-names = "xtal", "pclk", "baud";
 			};
 
@@ -160,5 +483,30 @@ hwrng: rng at 440788 {
 				reg = <0x0 0x440788 0x0 0x0c>;
 			};
 		};
+
+		ethmac: ethernet at fdc00000 {
+			compatible = "amlogic,meson-axg-dwmac",
+				     "snps,dwmac-3.70a",
+				     "snps,dwmac";
+			reg = <0x0 0xfdc00000 0x0 0x10000>,
+			      <0x0 0xfe024000 0x0 0x8>;
+
+			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq";
+			power-domains = <&pwrc PWRC_S4_ETH_ID>;
+			clocks = <&clkc_periphs CLKID_ETH>,
+				 <&clkc_pll CLKID_FCLK_DIV2>,
+				 <&clkc_pll CLKID_MPLL2>;
+			clock-names = "stmmaceth", "clkin0", "clkin1";
+			rx-fifo-depth = <4096>;
+			tx-fifo-depth = <2048>;
+			status = "disabled";
+
+			mdio0: mdio {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "snps,dwmac-mdio";
+			};
+		};
 	};
 };

-- 
2.37.1



From xuwei5 at hisilicon.com  Thu Dec  7 23:17:06 2023
From: xuwei5 at hisilicon.com (Wei Xu)
Date: Fri, 8 Dec 2023 15:17:06 +0800
Subject: [PATCH 0/2] arm64: dts: hisilicon: hikey970-pmic: clean up PMIC
 nodes
In-Reply-To: <20231130175635.14251-1-johan+linaro@kernel.org>
References: <20231130175635.14251-1-johan+linaro@kernel.org>
Message-ID: <6572C2F2.9090202@hisilicon.com>

Hi Johan,

On 2023/12/1 1:56, Johan Hovold wrote:
> When reviewing the various SPMI PMIC bindings, I noticed that several
> examples were incorrect and misleading and could also use some cleanup.
> 
> This series cleans up the hisilicon hikey970 PMIC dtsi which appears to
> have been used as the basis for some of the examples.
> 
> Note that the binding documents "hisilicon,hi6421v600-spmi" while the
> devicetree and driver only uses and recognises "hisilicon,hi6421-spmi".
> I'll leave that as is for now...
> 
> Johan
> 
> 
> Johan Hovold (2):
>   arm64: dts: hisilicon: hikey970-pmic: fix regulator cells properties
>   arm64: dts: hisilicon: hikey970-pmic: clean up SPMI node
> 
>  arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 

Series applied to the HiSilicon arm64 dt tree as the binding part has been applied.
Thanks!

Best Regards,
Wei


From xuwei5 at hisilicon.com  Thu Dec  7 23:18:34 2023
From: xuwei5 at hisilicon.com (Wei Xu)
Date: Fri, 8 Dec 2023 15:18:34 +0800
Subject: [PATCH v3 0/5] soc: hisilicon: kunpeng_hccs: Support the platform
 with PCC type3 and interrupt ack
In-Reply-To: <20231201034534.7276-1-lihuisong@huawei.com>
References: <20231109054526.27270-1-lihuisong@huawei.com> <20231201034534.7276-1-lihuisong@huawei.com>
Message-ID: <6572C34A.7010101@hisilicon.com>

Hi Huisong,

On 2023/12/1 11:45, Huisong Li wrote:
> The main purpose of this series is to support the platform with PCC type3
> and interrupt ack. At the same time, this series also fix some clean codes
> and modify the incorrect email domain name.
> 
> ---
>  v3:
>   - remove inline tag of two wait_cmd_complete function.
>   - delete variable 'ret' in hccs_wait_cmd_complete_by_irq()
>   - add a new patch which fix incorrect email domain name in document.
> 
>  v2:
>   - using a version specific structure to replace device version according
>     to Jonathan's advice.
>   - add a new patch that remove an unused blank line.
> 
> Huisong Li (5):
>   soc: hisilicon: kunpeng_hccs: Fix some incorrect format strings
>   soc: hisilicon: kunpeng_hccs: Add failure log for no _CRS method
>   soc: hisilicon: kunpeng_hccs: Remove an unused blank line
>   doc: kunpeng_hccs: Fix incorrect email domain name
>   soc: hisilicon: kunpeng_hccs: Support the platform with PCC type3 and
>     interrupt ack
> 
>  .../sysfs-devices-platform-kunpeng_hccs       |   6 +-
>  drivers/soc/hisilicon/kunpeng_hccs.c          | 152 ++++++++++++++----
>  drivers/soc/hisilicon/kunpeng_hccs.h          |  15 ++
>  3 files changed, 137 insertions(+), 36 deletions(-)
> 

Thanks!
Series applied to the HiSilicon driver tree.

Best Regards,
Wei


From xuwei5 at hisilicon.com  Thu Dec  7 23:22:03 2023
From: xuwei5 at hisilicon.com (Wei Xu)
Date: Fri, 8 Dec 2023 15:22:03 +0800
Subject: [GIT,PULL] hisilicon: driver updates for v6.8
Message-ID: <6572C41B.6050703@hisilicon.com>

Hi ARM SoC maintainers,

Please consider to pull the following changes.
Thanks!

Best Regards,
Wei

---

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://github.com/hisilicon/linux-hisi.git tags/hisi-drivers-for-6.8

for you to fetch changes up to be2f78a8a638e71bbbc2109bc052524143e8f42a:

  soc: hisilicon: kunpeng_hccs: Support the platform with PCC type3 and interrupt ack (2023-12-07 06:16:35 +0000)

----------------------------------------------------------------
HiSilicon driver updates for v6.8

- Add support for the platform with PCC type3 and interrupt ack
- Few cleanups and improvements: correct the format of some strings and domain typo,
add failure log

----------------------------------------------------------------
Huisong Li (5):
      soc: hisilicon: kunpeng_hccs: Fix some incorrect format strings
      soc: hisilicon: kunpeng_hccs: Add failure log for no _CRS method
      soc: hisilicon: kunpeng_hccs: Remove an unused blank line
      doc: kunpeng_hccs: Fix incorrect email domain name
      soc: hisilicon: kunpeng_hccs: Support the platform with PCC type3 and interrupt ack

 .../testing/sysfs-devices-platform-kunpeng_hccs    |   6 +-
 drivers/soc/hisilicon/kunpeng_hccs.c               | 152 ++++++++++++++++-----
 drivers/soc/hisilicon/kunpeng_hccs.h               |  15 ++
 3 files changed, 137 insertions(+), 36 deletions(-)


From xuwei5 at hisilicon.com  Thu Dec  7 23:24:56 2023
From: xuwei5 at hisilicon.com (Wei Xu)
Date: Fri, 8 Dec 2023 15:24:56 +0800
Subject: [GIT,PULL] arm64: dts: hisilicon dts updates for v6.8
Message-ID: <6572C4C8.6050401@hisilicon.com>

Hi ARM SoC maintainers,

Please consider to pull the following changes.
Thanks!

Best Regards,
Wei

---

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-6.8

for you to fetch changes up to 94fa073377db02ef0ca391f32e11e0f4649b2657:

  arm64: dts: hisilicon: hikey970-pmic: clean up SPMI node (2023-12-08 06:14:05 +0000)

----------------------------------------------------------------
ARM64: DT: HiSilicon ARM64 DT updates for v6.8

- Merge the hi3620-clock binding into hisilicon,sysctrl
- Clean up the hikey970 PMIC dtsi

----------------------------------------------------------------
Johan Hovold (2):
      arm64: dts: hisilicon: hikey970-pmic: fix regulator cells properties
      arm64: dts: hisilicon: hikey970-pmic: clean up SPMI node

Rob Herring (1):
      dt-bindings: hisilicon: Merge hi3620-clock into hisilicon,sysctrl binding

 .../bindings/arm/hisilicon/controller/sysctrl.yaml   | 17 +++++++++++++++++
 .../devicetree/bindings/clock/hi3620-clock.txt       | 20 --------------------
 arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi     |  6 +-----
 3 files changed, 18 insertions(+), 25 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/clock/hi3620-clock.txt


From a0501179 at ti.com  Thu Dec  7 23:28:38 2023
From: a0501179 at ti.com (Anwar, Md Danish)
Date: Fri, 8 Dec 2023 12:58:38 +0530
Subject: [PATCH 3/3] arm64: dts: ti: k3-am642-evm: add overlay for icssg1
 2nd port
In-Reply-To: <fe6499b3-fbda-4e2d-9b5e-92cc60d3a79c@lunn.ch>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-4-danishanwar@ti.com>
 <fe6499b3-fbda-4e2d-9b5e-92cc60d3a79c@lunn.ch>
Message-ID: <afec7eaa-9ef5-447f-9619-9721937fe805@ti.com>

On 12/8/2023 3:10 AM, Andrew Lunn wrote:
>> +	mdio-mux-2 {
>> +		compatible = "mdio-mux-multiplexer";
>> +		mux-controls = <&mdio_mux>;
>> +		mdio-parent-bus = <&icssg1_mdio>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		mdio at 0 {
>> +			reg = <0x0>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			icssg1_phy2: ethernet-phy at 3 {
>> +				reg = <3>;
>> +				tx-internal-delay-ps = <250>;
>> +				rx-internal-delay-ps = <2000>;
>> +			};
>> +		};
> 
> That looks odd. A mux generally has > 1 mdio bus. Otherwise its not
> really a mux.
> 

We are disabling node `mdio-mux-1` which has the `cpsw3g_mdio` bus and
then adding a new node `mdio-mux-2` which has the `icssg1_mdio` bus. The
mux can actually have two different mdio buses. The patch actually
disables the mux1 node and creates a new node for icssg1_mdio bus so
that cpsw3g mdio bus is disabled properly.

We can modify the existing `mdio-mux-1` as well (added the code below)
instead of disabling mux1 and creating mux2 node.

&mdio_mux_1 {
	mdio-parent-bus = <&icssg1_mdio>;
	#address-cells = <1>;
	#size-cells = <0>;

	mdio at 0 {
		reg = <0x0>;
		#address-cells = <1>;
		#size-cells = <0>;

		icssg1_phy2: ethernet-phy at 3 {
			reg = <3>;
			tx-internal-delay-ps = <250>;
			rx-internal-delay-ps = <2000>;
		};
	};
};

Let me know what do you think. Is the approach in the patch correct or
should I modify existing mux node only?

> And this mux hardware exists all the time right? So it should be in
> the .dtsi file.
> 

Agreed. But the mdio-mux-1 node was added in k3-am642-evm.dts by the
commit 985204ecae1c37d55372874ff9146231d28fccc6. I did the same with
mdio-mux-2 node.

> 	Andrew

-- 
Thanks and Regards,
Md Danish Anwar


From ming.qian at nxp.com  Thu Dec  7 23:33:42 2023
From: ming.qian at nxp.com (Ming Qian)
Date: Fri,  8 Dec 2023 15:33:42 +0800
Subject: [PATCH] media: amphion: remove mutext lock in condition of wait_event
Message-ID: <20231208073342.276143-1-ming.qian@nxp.com>

mutext_lock should not be called in condition of wait_event, otherwise,
when CONFIG_DEBUG_ATOMIC_SLEEP is enabled, we may meet the following
warning:
do not call blocking ops when !TASK_RUNNING; state=2
WARNING: CPU: 5 PID: 741 at kernel/sched/core.c:9859
__might_sleep+0x80/0xa4
Hardware name: Freescale i.MX8QM MEK (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)  pc :
__might_sleep+0x80/0xa4  lr : __might_sleep+0x80/0xa4  sp : ffffffc0123738a0
x29: ffffffc0123738a0 x28: ffffffc009194c48 x27: ffffffc00bbc1050
x26: ffffff8814b282f0 x25: ffffff8814b280d0 x24: ffffff8814b28080
x23: 0000000000000001 x22: 0000000000000032 x21: ffffffc00bbc1000
x20: 000000000000011b x19: ffffffc009324670 x18: 00000000fffffffd
x17: 30303c5b20746120 x16: 74657320323d6574 x15: 617473203b474e49
x14: 00058b5b8b9aa1f1 x13: ffffffc00903cda0 x12: 00000000d744fcc9
x11: 000000000000001c x10: 00000000000009a0 x9 : ffffffc0090201f4
x8 : ffffff8828245000 x7 : 0000000000000001 x6 : 0000000000000001
x5 : 00000000410fd080 x4 : 0000000000000002 x3 : ffffff8815aab4c8
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8828244600
Call trace:
 __might_sleep+0x80/0xa4
 mutex_lock+0x2c/0x80
 sync_session_response+0x110/0x310
 vpu_session_send_cmd+0x18c/0x244
 vpu_session_start+0x38/0x70
 vdec_start_session+0x1b4/0x3e0
 vpu_vb2_start_streaming+0xa0/0x1c4
 vb2_start_streaming+0x74/0x160
 vb2_core_qbuf+0x488/0x650
 vb2_qbuf+0x9c/0x100
 v4l2_m2m_qbuf+0x7c/0x224
 v4l2_m2m_ioctl_qbuf+0x20/0x2c
 v4l_qbuf+0x50/0x6c
 __video_do_ioctl+0x174/0x3f0
 video_usercopy+0x210/0x7cc
 video_ioctl2+0x20/0x30
 v4l2_ioctl+0x48/0x6c

we need to refine check_is_responsed() to remove the mutext_lock, each
cmd has a monotonically increasing id, and cmds are executed
sequentially, so we can check the id of the last reponsed cmd, then
determine whether a command has been responded or not.

Signed-off-by: Ming Qian <ming.qian at nxp.com>
CC: Xiaolei Wang <xiaolei.wang at windriver.com>
---
 drivers/media/platform/amphion/vpu.h      |  3 ++-
 drivers/media/platform/amphion/vpu_cmds.c | 28 ++++++++---------------
 drivers/media/platform/amphion/vpu_v4l2.c |  1 +
 3 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/amphion/vpu.h b/drivers/media/platform/amphion/vpu.h
index 5a701f64289e..0246cf0ac3a8 100644
--- a/drivers/media/platform/amphion/vpu.h
+++ b/drivers/media/platform/amphion/vpu.h
@@ -154,7 +154,6 @@ struct vpu_core {
 	struct vpu_mbox tx_type;
 	struct vpu_mbox tx_data;
 	struct vpu_mbox rx;
-	unsigned long cmd_seq;
 
 	wait_queue_head_t ack_wq;
 	struct completion cmp;
@@ -253,6 +252,8 @@ struct vpu_inst {
 
 	struct list_head cmd_q;
 	void *pending;
+	unsigned long cmd_seq;
+	atomic_long_t last_response_cmd;
 
 	struct vpu_inst_ops *ops;
 	const struct vpu_format *formats;
diff --git a/drivers/media/platform/amphion/vpu_cmds.c b/drivers/media/platform/amphion/vpu_cmds.c
index c2337812573e..5695f5c1cb3e 100644
--- a/drivers/media/platform/amphion/vpu_cmds.c
+++ b/drivers/media/platform/amphion/vpu_cmds.c
@@ -32,6 +32,7 @@ struct vpu_cmd_t {
 	struct vpu_cmd_request *request;
 	struct vpu_rpc_event *pkt;
 	unsigned long key;
+	atomic_long_t *last_response_cmd;
 };
 
 static struct vpu_cmd_request vpu_cmd_requests[] = {
@@ -115,6 +116,8 @@ static void vpu_free_cmd(struct vpu_cmd_t *cmd)
 {
 	if (!cmd)
 		return;
+	if (cmd->last_response_cmd)
+		atomic_long_set(cmd->last_response_cmd, cmd->key);
 	vfree(cmd->pkt);
 	vfree(cmd);
 }
@@ -172,7 +175,8 @@ static int vpu_request_cmd(struct vpu_inst *inst, u32 id, void *data,
 		return -ENOMEM;
 
 	mutex_lock(&core->cmd_lock);
-	cmd->key = core->cmd_seq++;
+	cmd->key = ++inst->cmd_seq;
+	cmd->last_response_cmd = &inst->last_response_cmd;
 	if (key)
 		*key = cmd->key;
 	if (sync)
@@ -246,26 +250,12 @@ void vpu_clear_request(struct vpu_inst *inst)
 
 static bool check_is_responsed(struct vpu_inst *inst, unsigned long key)
 {
-	struct vpu_core *core = inst->core;
-	struct vpu_cmd_t *cmd;
-	bool flag = true;
+	unsigned long last_response = atomic_long_read(&inst->last_response_cmd);
 
-	mutex_lock(&core->cmd_lock);
-	cmd = inst->pending;
-	if (cmd && key == cmd->key) {
-		flag = false;
-		goto exit;
-	}
-	list_for_each_entry(cmd, &inst->cmd_q, list) {
-		if (key == cmd->key) {
-			flag = false;
-			break;
-		}
-	}
-exit:
-	mutex_unlock(&core->cmd_lock);
+	if (key <= last_response && (last_response - key) < (ULONG_MAX >> 1))
+		return true;
 
-	return flag;
+	return false;
 }
 
 static int sync_session_response(struct vpu_inst *inst, unsigned long key, long timeout, int try)
diff --git a/drivers/media/platform/amphion/vpu_v4l2.c b/drivers/media/platform/amphion/vpu_v4l2.c
index 0f6e4c666440..d7e0de49b3dc 100644
--- a/drivers/media/platform/amphion/vpu_v4l2.c
+++ b/drivers/media/platform/amphion/vpu_v4l2.c
@@ -716,6 +716,7 @@ int vpu_v4l2_open(struct file *file, struct vpu_inst *inst)
 		func = &vpu->decoder;
 
 	atomic_set(&inst->ref_count, 0);
+	atomic_long_set(&inst->last_response_cmd, 0);
 	vpu_inst_get(inst);
 	inst->vpu = vpu;
 	inst->core = vpu_request_core(vpu, inst->type);
-- 
2.43.0-rc1



From 21cnbao at gmail.com  Thu Dec  7 23:34:01 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Fri,  8 Dec 2023 20:34:01 +1300
Subject: [PATCH] arm64: mm: support THP_SWAP on hardware with MTE
Message-ID: <20231208073401.70153-1-v-songbaohua@oppo.com>

Commit d0637c505f8a1 ("arm64: enable THP_SWAP for arm64") brings up
THP_SWAP on ARM64, but it doesn't enable THP_SWP on hardware with
MTE as the MTE code works with the assumption tags save/restore is
always handling a folio with only one page.

The limitation should be removed as more and more ARM64 SoCs have
this feature. Co-existence of MTE and THP_SWAP becomes more and
more important.

This patch makes MTE tags saving support large folios, then we don't
need to split large folios into base pages for swapping out on ARM64
SoCs with MTE any more.

arch_prepare_to_swap() should take folio rather than page as parameter
because we support THP swap-out as a whole. It saves tags for all
pages in a large folio.

Meanwhile, arch_swap_restore() now moves to use page parameter rather
than folio because swap-in, refault and MTE tags are working at the
granularity of base pages rather than folio:
1. a large folio in swapcache can be partially unmapped, thus, MTE
tags for the unmapped pages will be invalidated;
2. users might use mprotect() to set MTEs on a part of a large folio.

Thus, it won't be easy to manage MTE tags at the granularity of folios
since we do have some cases in which a part of pages in a large folios
have valid tags, while the other part of pages haven't. Furthermore,
trying to restore MTE tags for a whole folio can lead to many loops and
early exiting even if the large folio in swapcache are still entirely
mapped since do_swap_page() only sets PTE and frees swap for the base
page where PF is happening.

But we still have a chance to restore tags for a whole large folio
once we support swap-in large folio. So this job is deferred till we
can do refault and swap-in as a large folio.

arch_thp_swp_supported() is dropped since ARM64 MTE was the only one
who needed it.

Reviewed-by: Steven Price <steven.price at arm.com>
Signed-off-by: Barry Song <v-songbaohua at oppo.com>
---
 -v1:
   collected reviewed-by from Steven;
   refine commit log;
 -rfc v3:
   https://lore.kernel.org/linux-mm/20231114014313.67232-1-v-songbaohua at oppo.com/
 -rfc v2:
   https://lore.kernel.org/lkml/20231104093423.170054-1-v-songbaohua at oppo.com/
 -rfc v1:
   https://lore.kernel.org/lkml/20231102223643.7733-1-v-songbaohua at oppo.com/

 arch/arm64/include/asm/pgtable.h | 21 ++++---------------
 arch/arm64/mm/mteswap.c          | 35 ++++++++++++++++++++++++++++++++
 include/linux/huge_mm.h          | 12 -----------
 include/linux/pgtable.h          |  4 ++--
 mm/memory.c                      |  2 +-
 mm/page_io.c                     |  2 +-
 mm/shmem.c                       |  2 +-
 mm/swap_slots.c                  |  2 +-
 mm/swapfile.c                    |  2 +-
 9 files changed, 46 insertions(+), 36 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b19a8aee684c..c3eef11c1a9e 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -45,12 +45,6 @@
 	__flush_tlb_range(vma, addr, end, PUD_SIZE, false, 1)
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
-static inline bool arch_thp_swp_supported(void)
-{
-	return !system_supports_mte();
-}
-#define arch_thp_swp_supported arch_thp_swp_supported
-
 /*
  * Outside of a few very special situations (e.g. hibernation), we always
  * use broadcast TLB invalidation instructions, therefore a spurious page
@@ -1036,12 +1030,8 @@ static inline pmd_t pmdp_establish(struct vm_area_struct *vma,
 #ifdef CONFIG_ARM64_MTE
 
 #define __HAVE_ARCH_PREPARE_TO_SWAP
-static inline int arch_prepare_to_swap(struct page *page)
-{
-	if (system_supports_mte())
-		return mte_save_tags(page);
-	return 0;
-}
+#define arch_prepare_to_swap arch_prepare_to_swap
+extern int arch_prepare_to_swap(struct folio *folio);
 
 #define __HAVE_ARCH_SWAP_INVALIDATE
 static inline void arch_swap_invalidate_page(int type, pgoff_t offset)
@@ -1057,11 +1047,8 @@ static inline void arch_swap_invalidate_area(int type)
 }
 
 #define __HAVE_ARCH_SWAP_RESTORE
-static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
-{
-	if (system_supports_mte())
-		mte_restore_tags(entry, &folio->page);
-}
+#define arch_swap_restore arch_swap_restore
+extern void arch_swap_restore(swp_entry_t entry, struct page *page);
 
 #endif /* CONFIG_ARM64_MTE */
 
diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
index a31833e3ddc5..d0ebed4e002f 100644
--- a/arch/arm64/mm/mteswap.c
+++ b/arch/arm64/mm/mteswap.c
@@ -68,6 +68,13 @@ void mte_invalidate_tags(int type, pgoff_t offset)
 	mte_free_tag_storage(tags);
 }
 
+static inline void __mte_invalidate_tags(struct page *page)
+{
+	swp_entry_t entry = page_swap_entry(page);
+
+	mte_invalidate_tags(swp_type(entry), swp_offset(entry));
+}
+
 void mte_invalidate_tags_area(int type)
 {
 	swp_entry_t entry = swp_entry(type, 0);
@@ -83,3 +90,31 @@ void mte_invalidate_tags_area(int type)
 	}
 	xa_unlock(&mte_pages);
 }
+
+int arch_prepare_to_swap(struct folio *folio)
+{
+	int err;
+	long i;
+
+	if (system_supports_mte()) {
+		long nr = folio_nr_pages(folio);
+
+		for (i = 0; i < nr; i++) {
+			err = mte_save_tags(folio_page(folio, i));
+			if (err)
+				goto out;
+		}
+	}
+	return 0;
+
+out:
+	while (i--)
+		__mte_invalidate_tags(folio_page(folio, i));
+	return err;
+}
+
+void arch_swap_restore(swp_entry_t entry, struct page *page)
+{
+	if (system_supports_mte())
+		mte_restore_tags(entry, page);
+}
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index fa0350b0812a..f83fb8d5241e 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -400,16 +400,4 @@ static inline int split_folio(struct folio *folio)
 	return split_folio_to_list(folio, NULL);
 }
 
-/*
- * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to
- * limitations in the implementation like arm64 MTE can override this to
- * false
- */
-#ifndef arch_thp_swp_supported
-static inline bool arch_thp_swp_supported(void)
-{
-	return true;
-}
-#endif
-
 #endif /* _LINUX_HUGE_MM_H */
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index af7639c3b0a3..87e3140a55ca 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -897,7 +897,7 @@ static inline int arch_unmap_one(struct mm_struct *mm,
  * prototypes must be defined in the arch-specific asm/pgtable.h file.
  */
 #ifndef __HAVE_ARCH_PREPARE_TO_SWAP
-static inline int arch_prepare_to_swap(struct page *page)
+static inline int arch_prepare_to_swap(struct folio *folio)
 {
 	return 0;
 }
@@ -914,7 +914,7 @@ static inline void arch_swap_invalidate_area(int type)
 #endif
 
 #ifndef __HAVE_ARCH_SWAP_RESTORE
-static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
+static inline void arch_swap_restore(swp_entry_t entry, struct page *page)
 {
 }
 #endif
diff --git a/mm/memory.c b/mm/memory.c
index 1f18ed4a5497..fad238dd38e7 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4022,7 +4022,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
 	 * when reading from swap. This metadata may be indexed by swap entry
 	 * so this must be called before swap_free().
 	 */
-	arch_swap_restore(entry, folio);
+	arch_swap_restore(entry, page);
 
 	/*
 	 * Remove the swap entry and conditionally try to free up the swapcache.
diff --git a/mm/page_io.c b/mm/page_io.c
index cb559ae324c6..0fd832474c1d 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -189,7 +189,7 @@ int swap_writepage(struct page *page, struct writeback_control *wbc)
 	 * Arch code may have to preserve more data than just the page
 	 * contents, e.g. memory tags.
 	 */
-	ret = arch_prepare_to_swap(&folio->page);
+	ret = arch_prepare_to_swap(folio);
 	if (ret) {
 		folio_mark_dirty(folio);
 		folio_unlock(folio);
diff --git a/mm/shmem.c b/mm/shmem.c
index 91e2620148b2..7d32e50da121 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1892,7 +1892,7 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
 	 * Some architectures may have to restore extra metadata to the
 	 * folio after reading from swap.
 	 */
-	arch_swap_restore(swap, folio);
+	arch_swap_restore(swap, &folio->page);
 
 	if (shmem_should_replace_folio(folio, gfp)) {
 		error = shmem_replace_folio(&folio, gfp, info, index);
diff --git a/mm/swap_slots.c b/mm/swap_slots.c
index 0bec1f705f8e..2325adbb1f19 100644
--- a/mm/swap_slots.c
+++ b/mm/swap_slots.c
@@ -307,7 +307,7 @@ swp_entry_t folio_alloc_swap(struct folio *folio)
 	entry.val = 0;
 
 	if (folio_test_large(folio)) {
-		if (IS_ENABLED(CONFIG_THP_SWAP) && arch_thp_swp_supported())
+		if (IS_ENABLED(CONFIG_THP_SWAP))
 			get_swap_pages(1, &entry, folio_nr_pages(folio));
 		goto out;
 	}
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 4bc70f459164..6450e0279e35 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1784,7 +1784,7 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd,
 	 * when reading from swap. This metadata may be indexed by swap entry
 	 * so this must be called before swap_free().
 	 */
-	arch_swap_restore(entry, page_folio(page));
+	arch_swap_restore(entry, page);
 
 	/* See do_swap_page() */
 	BUG_ON(!PageAnon(page) && PageMappedToDisk(page));
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec  7 23:36:14 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Fri, 08 Dec 2023 08:36:14 +0100
Subject: [PATCH v2 1/1] media: nxp: imx8-isi-debug: Add missing 36-Bit DMA registers to debugfs output
In-Reply-To: <20231207142845.GB15521@pendragon.ideasonboard.com>
References: <20231207110918.1338524-1-alexander.stein@ew.tq-group.com> <10383921.nUPlyArG6x@steina-w> <20231207142845.GB15521@pendragon.ideasonboard.com>
Message-ID: <22110294.EfDdHjke4D@steina-w>

Hi Laurent,

Am Donnerstag, 7. Dezember 2023, 15:28:45 CET schrieb Laurent Pinchart:
> Hi Alexander,
> 
> On Thu, Dec 07, 2023 at 03:15:10PM +0100, Alexander Stein wrote:
> > Am Donnerstag, 7. Dezember 2023, 14:55:39 CET schrieb Laurent Pinchart:
> > > On Thu, Dec 07, 2023 at 12:09:18PM +0100, Alexander Stein wrote:
> > > > The extended address registers are missing in the debug output
> > > > register
> > > > list. These are only available on 36-Bit DMA platforms. Due to the
> > > > prolonged name, the output width has to be adjusted as well.
> > > > 
> > > > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> > > > ---
> > > > Changes in v2:
> > > > * Split register set into regular and 36-Bit DMA only
> > > > * Adjust output width to address longer register names
> > > > 
> > > > Currently only tested on TQMa8MPxL (imx8mp-tqma8mpql-mba8mpxl.dts)
> > > > 
> > > >  .../platform/nxp/imx8-isi/imx8-isi-debug.c    | 28
> > > >  +++++++++++++++++--
> > > >  1 file changed, 25 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > > b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c index
> > > > 6709ab7ea1f3..398864b5e506 100644
> > > > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-debug.c
> > > > @@ -22,10 +22,11 @@ static inline u32 mxc_isi_read(struct mxc_isi_pipe
> > > > *pipe, u32 reg)>
> > > > 
> > > >  static int mxc_isi_debug_dump_regs_show(struct seq_file *m, void *p)
> > > >  {
> > > >  #define MXC_ISI_DEBUG_REG(name)		{ name, #name }
> > > > 
> > > > -	static const struct {
> > > > +	struct debug_regs {
> > > > 
> > > >  		u32 offset;
> > > >  		const char * const name;
> > > > 
> > > > -	} registers[] = {
> > > > +	};
> > > > +	static const struct debug_regs registers[] = {
> > > > 
> > > >  		MXC_ISI_DEBUG_REG(CHNL_CTRL),
> > > >  		MXC_ISI_DEBUG_REG(CHNL_IMG_CTRL),
> > > >  		MXC_ISI_DEBUG_REG(CHNL_OUT_BUF_CTRL),
> > > > 
> > > > @@ -67,6 +68,16 @@ static int mxc_isi_debug_dump_regs_show(struct
> > > > seq_file
> > > > *m, void *p)>
> > > > 
> > > >  		MXC_ISI_DEBUG_REG(CHNL_SCL_IMG_CFG),
> > > >  		MXC_ISI_DEBUG_REG(CHNL_FLOW_CTRL),
> > > >  	
> > > >  	};
> > > > 
> > > > +	/* There registers contain the upper 4Bits of 36-Bit DMA addresses
> > > > */
> > > 
> > > s/There/These/
> > > 
> > > > +	static const struct debug_regs registers_36bit_dma[] = {
> > > > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF1_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF1_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF1_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_Y_BUF2_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_U_BUF2_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_V_BUF2_XTND_ADDR),
> > > > +		MXC_ISI_DEBUG_REG(CHNL_IN_BUF_XTND_ADDR),
> > > > +	};
> > > > 
> > > >  	struct mxc_isi_pipe *pipe = m->private;
> > > >  	unsigned int i;
> > > > 
> > > > @@ -77,10 +88,21 @@ static int mxc_isi_debug_dump_regs_show(struct
> > > > seq_file *m, void *p)>
> > > > 
> > > >  	seq_printf(m, "--- ISI pipe %u registers ---\n", pipe->id);
> > > >  	
> > > >  	for (i = 0; i < ARRAY_SIZE(registers); ++i)
> > > > 
> > > > -		seq_printf(m, "%20s[0x%02x]: 0x%08x\n",
> > > > +		seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
> > > > 
> > > >  			   registers[i].name, registers[i].offset,
> > > >  			   mxc_isi_read(pipe, registers[i].offset));
> > > > 
> > > > +	if (pipe->isi->pdata->has_36bit_dma) {
> > > > +		for (i = 0; i < ARRAY_SIZE(registers_36bit_dma); ++i) {
> > > > +			const struct debug_regs *reg = 
aregisters_36bit_dma[i];
> > > > +
> > > > +			seq_printf(m, "%21s[0x%02x]: 0x%08x\n",
> > > > +				reg->name,
> > > > +				reg->offset,
> > > > +				mxc_isi_read(pipe, reg->offset));
> > > 
> > > Lines should be aligned under the "m" of the first line.
> > > 
> > > I'll fix these small issues when applying, no need to send a v3.
> > > 
> > > Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > 
> > For the records: Also tested on TQMa8MxNL (imx8mn-tqma8mqnl-mba8mx.dts).
> > As
> > expected it prints only the same registers as before.
> 
> Thank you. Can I add
> 
>     Tested-by: Alexander Stein <alexander.stein at ew.tq-group.com> # on imx8mn
> 
> ?

Sure, you can add it for imx8mn, imx8mp and imx93 actually.

Best regards,
Alexander

> 
> > > > +		}
> > > > +	}
> > > > +
> > > > 
> > > >  	pm_runtime_put(pipe->isi->dev);
> > > >  	
> > > >  	return 0;


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From jaewon02.kim at samsung.com  Thu Dec  7 23:45:23 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Fri,  8 Dec 2023 16:45:23 +0900
Subject: [PATCH v3 0/4] Introduce ExynosAutov920 SoC and SADK board
References: <CGME20231208075019epcas2p4cef1190e41adeaaf47b7763cc86c3d26@epcas2p4.samsung.com>
Message-ID: <20231208074527.50840-1-jaewon02.kim@samsung.com>

ExynosAutov920[1] is ARMv8-based automotive-oriented SoC.
This SoC is the next generation of exynosautov9 and AE(Automotive Enhanced)
IPs are used for safety.

This patchset is the minimal set for ExynosAutov920 SoC and SADK board.
Currently, ramdisk console is available and Clock, UFS, and USI will be
added after this patchset.

[1] : https://semiconductor.samsung.com/processor/automotive-processor/exynos-auto-v920

---
Changes in v3:
 - Split pinctrl driver change patch  and v920 support patch
 - Remove 'combine' variable and use offset variable
 - Fix coding style warning in checkpatch with --strict option
 - Fix CHECK_DTBS=y waring with W=1 option
 - dt-binding document merged in v2

Changes in v2:
 - Rebase to git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
             branch : for-v6.8/samsung-bindings-compatibles
 - Specific exynosautov920 compatible
 - Add dt-binding patch for pmu, chipid


Jaewon Kim (4):
  arm64: dts: exynos: add initial support for exynosautov920 SoC
  arm64: dts: exynos: add minimal support for exynosautov920 sadk board
  pinctrl: samsung: support ExynosAuto GPIO structure
  pinctrl: samsung: add exynosautov920 pinctrl

 arch/arm64/boot/dts/exynos/Makefile           |    3 +-
 .../dts/exynos/exynosautov920-pinctrl.dtsi    | 1266 +++++++++++++++++
 .../boot/dts/exynos/exynosautov920-sadk.dts   |   88 ++
 .../arm64/boot/dts/exynos/exynosautov920.dtsi |  314 ++++
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  140 ++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |   99 +-
 drivers/pinctrl/samsung/pinctrl-exynos.h      |   25 +
 drivers/pinctrl/samsung/pinctrl-samsung.c     |    5 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   13 +
 9 files changed, 1945 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920.dtsi

-- 
2.43.0



From jaewon02.kim at samsung.com  Thu Dec  7 23:45:27 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Fri,  8 Dec 2023 16:45:27 +0900
Subject: [PATCH v3 4/4] pinctrl: samsung: add exynosautov920 pinctrl
In-Reply-To: <20231208074527.50840-1-jaewon02.kim@samsung.com>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
	<CGME20231208075020epcas2p414c85e03d18327665eeff54082314b56@epcas2p4.samsung.com>
Message-ID: <20231208074527.50840-5-jaewon02.kim@samsung.com>

Add pinctrl data for ExynosAutov920 SoC.

Pinctrl data for ExynosAutoV920 SoC.
 - GPA0,GPA1 (10): External wake up interrupt
 - GPQ0 (2): SPMI (PMIC I/F)
 - GPB0,GPB1,GPB2,GPB3,GPB4,GPB5,GPB6 (47): I2S Audio
 - GPH0,GPH1,GPH2,GPH3,GPH4,GPH5,GPH6,GPH8 (49): PCIE, UFS, Ethernet
 - GPG0,GPG1,GPG2,GPG3,GPG4,GPG5 (29): General purpose
 - GPP0,GPP1,GPP2,GPP3,GPP4,GPP5,GPP6,GPP7,GPP8,GPP9,GPP10 (77): USI

Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
---
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 140 ++++++++++++++++++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |  18 +++
 drivers/pinctrl/samsung/pinctrl-exynos.h      |  24 +++
 drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
 5 files changed, 185 insertions(+)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index cb965cf93705..a998c296dd05 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -796,3 +796,143 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
 	.ctrl		= fsd_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
 };
+
+/* pin banks of exynosautov920 pin-controller 0 (ALIVE) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks0[] = {
+	EXYNOSV920_PIN_BANK_EINTW(8, 0x0000, "gpa0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTW(2, 0x1000, "gpa1", 0x18, 0x20, 0x24),
+	EXYNOS850_PIN_BANK_EINTN(2, 0x2000, "gpq0"),
+};
+
+/* pin banks of exynosautov920 pin-controller 1 (AUD) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks1[] = {
+	EXYNOSV920_PIN_BANK_EINTG(7, 0x0000, "gpb0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(6, 0x1000, "gpb1", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x2000, "gpb2", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x3000, "gpb3", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x4000, "gpb4", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x5000, "gpb5", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x6000, "gpb6", 0x18, 0x24, 0x28),
+};
+
+/* pin banks of exynosautov920 pin-controller 2 (HSI0) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks2[] = {
+	EXYNOSV920_PIN_BANK_EINTG(6, 0x0000, "gph0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(2, 0x1000, "gph1", 0x18, 0x20, 0x24),
+};
+
+/* pin banks of exynosautov920 pin-controller 3 (HSI1) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks3[] = {
+	EXYNOSV920_PIN_BANK_EINTG(7, 0x000, "gph8", 0x18, 0x24, 0x28),
+};
+
+/* pin banks of exynosautov920 pin-controller 4 (HSI2) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks4[] = {
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x0000, "gph3", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(7, 0x1000, "gph4", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x2000, "gph5", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(7, 0x3000, "gph6", 0x18, 0x24, 0x28),
+};
+
+/* pin banks of exynosautov920 pin-controller 5 (HSI2UFS) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks5[] = {
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x000, "gph2", 0x18, 0x20, 0x24),
+};
+
+/* pin banks of exynosautov920 pin-controller 6 (PERIC0) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks6[] = {
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x0000, "gpp0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x1000, "gpp1", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x2000, "gpp2", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x3000, "gpg0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x4000, "gpp3", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x5000, "gpp4", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x6000, "gpg2", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x7000, "gpg5", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(3, 0x8000, "gpg3", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x9000, "gpg4", 0x18, 0x24, 0x28),
+};
+
+/* pin banks of exynosautov920 pin-controller 7 (PERIC1) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks7[] = {
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x0000, "gpp5",  0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x1000, "gpp6",  0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x2000, "gpp10", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x3000, "gpp7",  0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x4000, "gpp8",  0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x5000, "gpp11", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x6000, "gpp9",  0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x7000, "gpp12", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x8000, "gpg1",  0x18, 0x24, 0x28),
+};
+
+static const struct samsung_retention_data exynosautov920_retention_data __initconst = {
+	.regs	 = NULL,
+	.nr_regs = 0,
+	.value	 = 0,
+	.refcnt	 = &exynos_shared_retention_refcnt,
+	.init	 = exynos_retention_init,
+};
+
+static const struct samsung_pin_ctrl exynosautov920_pin_ctrl[] = {
+	{
+		/* pin-controller instance 0 ALIVE data */
+		.pin_banks	= exynosautov920_pin_banks0,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks0),
+		.eint_wkup_init	= exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+		.retention_data	= &exynosautov920_retention_data,
+	}, {
+		/* pin-controller instance 1 AUD data */
+		.pin_banks	= exynosautov920_pin_banks1,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks1),
+	}, {
+		/* pin-controller instance 2 HSI0 data */
+		.pin_banks	= exynosautov920_pin_banks2,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks2),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 3 HSI1 data */
+		.pin_banks	= exynosautov920_pin_banks3,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks3),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 4 HSI2 data */
+		.pin_banks	= exynosautov920_pin_banks4,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks4),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 5 HSI2UFS data */
+		.pin_banks	= exynosautov920_pin_banks5,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks5),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 6 PERIC0 data */
+		.pin_banks	= exynosautov920_pin_banks6,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks6),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 7 PERIC1 data */
+		.pin_banks	= exynosautov920_pin_banks7,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks7),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	},
+};
+
+const struct samsung_pinctrl_of_match_data exynosautov920_of_data __initconst = {
+	.ctrl		= exynosautov920_pin_ctrl,
+	.num_ctrl	= ARRAY_SIZE(exynosautov920_pin_ctrl),
+};
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index f798f64b1122..593633d09aa2 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -487,6 +487,22 @@ static const struct exynos_irq_chip exynos7_wkup_irq_chip __initconst = {
 	.set_eint_wakeup_mask = exynos_pinctrl_set_eint_wakeup_mask,
 };
 
+static const struct exynos_irq_chip exynosautov920_wkup_irq_chip __initconst = {
+	.chip = {
+		.name = "exynosautov920_wkup_irq_chip",
+		.irq_unmask = exynos_irq_unmask,
+		.irq_mask = exynos_irq_mask,
+		.irq_ack = exynos_irq_ack,
+		.irq_set_type = exynos_irq_set_type,
+		.irq_set_wake = exynos_wkup_irq_set_wake,
+		.irq_request_resources = exynos_irq_request_resources,
+		.irq_release_resources = exynos_irq_release_resources,
+	},
+	.eint_wake_mask_value = &eint_wake_mask_value,
+	.eint_wake_mask_reg = EXYNOS5433_EINT_WAKEUP_MASK,
+	.set_eint_wakeup_mask = exynos_pinctrl_set_eint_wakeup_mask,
+};
+
 /* list of external wakeup controllers supported */
 static const struct of_device_id exynos_wkup_irq_ids[] = {
 	{ .compatible = "samsung,s5pv210-wakeup-eint",
@@ -499,6 +515,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
 			.data = &exynos7_wkup_irq_chip },
 	{ .compatible = "samsung,exynosautov9-wakeup-eint",
 			.data = &exynos7_wkup_irq_chip },
+	{ .compatible = "samsung,exynosautov920-wakeup-eint",
+			.data = &exynosautov920_wkup_irq_chip },
 	{ }
 };
 
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index 5049c170e958..305cb1d31de4 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -141,6 +141,30 @@
 		.name		= id				\
 	}
 
+#define EXYNOSV920_PIN_BANK_EINTG(pins, reg, id, con_offs, mask_offs, pend_offs)	\
+	{							\
+		.type			= &exynos850_bank_type_off,	\
+		.pctl_offset		= reg,				\
+		.nr_pins		= pins,				\
+		.eint_type		= EINT_TYPE_GPIO,		\
+		.eint_con_offset	= con_offs,			\
+		.eint_mask_offset	= mask_offs,			\
+		.eint_pend_offset	= pend_offs,			\
+		.name			= id				\
+	}
+
+#define EXYNOSV920_PIN_BANK_EINTW(pins, reg, id, con_offs, mask_offs, pend_offs)	\
+	{							\
+		.type			= &exynos850_bank_type_alive,	\
+		.pctl_offset		= reg,				\
+		.nr_pins		= pins,				\
+		.eint_type		= EINT_TYPE_WKUP,		\
+		.eint_con_offset	= con_offs,			\
+		.eint_mask_offset	= mask_offs,			\
+		.eint_pend_offset	= pend_offs,			\
+		.name			= id				\
+	}
+
 /**
  * struct exynos_weint_data: irq specific data for all the wakeup interrupts
  * generated by the external wakeup interrupt controller.
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 362e99566919..800a2f0a026a 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1324,6 +1324,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 		.data = &exynosautov9_of_data },
 	{ .compatible = "tesla,fsd-pinctrl",
 		.data = &fsd_of_data },
+	{ .compatible = "samsung,exynosautov920-pinctrl",
+		.data = &exynosautov920_of_data },
 #endif
 #ifdef CONFIG_PINCTRL_S3C64XX
 	{ .compatible = "samsung,s3c64xx-pinctrl",
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 789358bcd9c5..987086fa0d1d 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -362,6 +362,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7_of_data;
 extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
 extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
 extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
+extern const struct samsung_pinctrl_of_match_data exynosautov920_of_data;
 extern const struct samsung_pinctrl_of_match_data fsd_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
-- 
2.43.0



From jaewon02.kim at samsung.com  Thu Dec  7 23:45:25 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Fri,  8 Dec 2023 16:45:25 +0900
Subject: [PATCH v3 2/4] arm64: dts: exynos: add minimal support for
 exynosautov920 sadk board
In-Reply-To: <20231208074527.50840-1-jaewon02.kim@samsung.com>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
	<CGME20231208075020epcas2p30e46ea65e921664930b337510461892f@epcas2p3.samsung.com>
Message-ID: <20231208074527.50840-3-jaewon02.kim@samsung.com>

ExynosAutov920 SADK is ExynosAutov920 SoC based SADK(Samsung Automotive
Development Kit) board. It has 16GB(8GB + 8GB) LPDDR5 RAM and 256GB
(128GB + 128GB) UFS.

This is minimal support board device-tree.
 * Serial console
 * GPIO Key
 * PWM FAN

Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
---
 arch/arm64/boot/dts/exynos/Makefile           |  3 +-
 .../boot/dts/exynos/exynosautov920-sadk.dts   | 88 +++++++++++++++++++
 2 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts

diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
index 6e4ba69268e5..da06e1a9456c 100644
--- a/arch/arm64/boot/dts/exynos/Makefile
+++ b/arch/arm64/boot/dts/exynos/Makefile
@@ -5,4 +5,5 @@ dtb-$(CONFIG_ARCH_EXYNOS) += \
 	exynos7-espresso.dtb		\
 	exynos7885-jackpotlte.dtb	\
 	exynos850-e850-96.dtb		\
-	exynosautov9-sadk.dtb
+	exynosautov9-sadk.dtb		\
+	exynosautov920-sadk.dtb
diff --git a/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts b/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
new file mode 100644
index 000000000000..e250b5594b58
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung's ExynosAutov920 SADK board device tree source
+ *
+ * Copyright (c) 2023 Samsung Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+#include "exynosautov920.dtsi"
+#include "exynos-pinctrl.h"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "Samsung ExynosAutov920 SADK board";
+	compatible = "samsung,exynosautov920-sadk", "samsung,exynosautov920";
+
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &serial_0;
+	};
+
+	chosen {
+		stdout-path = &serial_0;
+	};
+
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0x0 0x70000000>,
+		      <0x8 0x80000000 0x1 0xfba00000>,
+		      <0xa 0x00000000 0x2 0x00000000>;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&key_wakeup &key_back>;
+
+		key-wakeup {
+			label = "KEY_WAKEUP";
+			linux,code = <KEY_WAKEUP>;
+			gpios = <&gpa0 0 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		key-back {
+			label = "KEY_BACK";
+			linux,code = <KEY_BACK>;
+			gpios = <&gpp6 3 GPIO_ACTIVE_LOW>;
+		};
+	};
+};
+
+&pinctrl_alive {
+	key_wakeup: key-wakeup-pins {
+		samsung,pins = "gpa0-0";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_EINT>;
+	};
+};
+
+&pinctrl_peric1 {
+	key_back: key-back-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_EINT>;
+	};
+};
+
+&pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm_tout0>;
+	status = "okay";
+};
+
+&serial_0 {
+	status = "okay";
+};
+
+&usi_0 {
+	samsung,clkreq-on; /* needed for UART mode */
+	status = "okay";
+};
+
+&xtcxo {
+	clock-frequency = <38400000>;
+};
-- 
2.43.0



From jaewon02.kim at samsung.com  Thu Dec  7 23:45:24 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Fri,  8 Dec 2023 16:45:24 +0900
Subject: [PATCH v3 1/4] arm64: dts: exynos: add initial support for
 exynosautov920 SoC
In-Reply-To: <20231208074527.50840-1-jaewon02.kim@samsung.com>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
	<CGME20231208075020epcas2p25f18d225f91f185085078461b290cb19@epcas2p2.samsung.com>
Message-ID: <20231208074527.50840-2-jaewon02.kim@samsung.com>

Samsung ExynosAutov920 is ARMv8-based automotive-oriented SoC.
It has AE(Automotive Enhanced) IPs for safety.
 * Cortex-A78AE 10-cores
 * GIC-600AE

This is minimal support for ExynosAutov920 SoC.
 * Enumerate all pinctrl nodes
 * Enable Chip-Id
 * Serial0 for console
 * PWM

Since the clock driver is not yet implemented, it is supported as
fixed-clock.

Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
---
 .../dts/exynos/exynosautov920-pinctrl.dtsi    | 1266 +++++++++++++++++
 .../arm64/boot/dts/exynos/exynosautov920.dtsi |  314 ++++
 2 files changed, 1580 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynosautov920-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/exynosautov920-pinctrl.dtsi
new file mode 100644
index 000000000000..63b958b96c48
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynosautov920-pinctrl.dtsi
@@ -0,0 +1,1266 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung's ExynosAutov920 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2023 Samsung Electronics Co., Ltd.
+ *
+ * Samsung's ExynosAutov920 SoC pin-mux and pin-config options are listed as
+ * device tree nodes in this file.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+#include "exynos-pinctrl.h"
+
+&pinctrl_alive {
+	gpa0: gpa0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa1: gpa1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpq0: gpq0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_aud {
+	gpb0: gpb0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpb1: gpb1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpb2: gpb2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpb3: gpb3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpb4: gpb4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpb5: gpb5-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpb6: gpb6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_hsi0 {
+	gph0: gph0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph1: gph1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_hsi1 {
+	gph8: gph8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_hsi2 {
+	gph3: gph3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph4: gph4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph5: gph5-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph6: gph6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_hsi2ufs {
+	gph2: gph2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	ufs_rst_n: ufs-rst-n-pins {
+		samsung,pins = "gph2-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <EXYNOS_PIN_PULL_DOWN>;
+	};
+
+	ufs_refclk_out: ufs-refclk-out-pins {
+		samsung,pins = "gph2-0";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	ufs_rst_n_1: ufs-rst-n-1-pins {
+		samsung,pins = "gph2-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <EXYNOS_PIN_PULL_DOWN>;
+	};
+
+	ufs_refclk_out_1: ufs-refclk-out-1-pins {
+		samsung,pins = "gph2-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <EXYNOS_PIN_PULL_DOWN>;
+	};
+};
+
+&pinctrl_peric0 {
+	gpp0: gpp0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp1: gpp1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp2: gpp2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp3: gpp3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp4: gpp4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpg0: gpg0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpg2: gpg2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpg3: gpg3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpg4: gpg4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpg5: gpg5-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	/* UART PERIC0_USI00 */
+	uart0_bus: uart0-bus-pins {
+		samsung,pins = "gpp0-0", "gpp0-1", "gpp0-2", "gpp0-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart0_bus_dual: uart0-bus-dual-pins {
+		samsung,pins = "gpp0-0", "gpp0-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC0_USI01 */
+	uart1_bus: uart1-bus-pins {
+		samsung,pins = "gpp0-4", "gpp0-5", "gpp0-6", "gpp0-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart1_bus_dual: uart1-bus-dual-pins {
+		samsung,pins = "gpp0-4", "gpp0-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC0_USI02 */
+	uart2_bus: uart2-bus-pins {
+		samsung,pins = "gpp1-0", "gpp1-1", "gpp1-2", "gpp1-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart2_bus_dual: uart2-bus-dual-pins {
+		samsung,pins = "gpp1-0", "gpp1-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC0_USI03 */
+	uart3_bus: uart3-bus-pins {
+		samsung,pins = "gpp1-4", "gpp1-5", "gpp1-6", "gpp1-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart3_bus_dual: uart3-bus-dual-pins {
+		samsung,pins = "gpp1-4", "gpp1-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC0_USI04 */
+	uart4_bus: uart4-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1", "gpp2-2", "gpp2-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart4_bus_dual: uart4-bus-dual-pins {
+		samsung,pins = "gpp2-0", "gpp2-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC0_USI05 */
+	uart5_bus: uart5-bus-pins {
+		samsung,pins = "gpp2-4", "gpp2-5", "gpp2-6", "gpp2-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart5_bus_dual: uart5-bus-dual-pins {
+		samsung,pins = "gpp2-4", "gpp2-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC0_USI06 */
+	uart6_bus: uart6-bus-pins {
+		samsung,pins = "gpp3-0", "gpp3-1", "gpp3-2", "gpp3-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart6_bus_dual: uart6-bus-dual-pins {
+		samsung,pins = "gpp3-0", "gpp3-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC0_USI07 */
+	uart7_bus: uart7-bus-pins {
+		samsung,pins = "gpp3-4", "gpp3-5", "gpp3-6", "gpp3-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart7_bus_dual: uart7-bus-dual-pins {
+		samsung,pins = "gpp3-4", "gpp3-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC0_USI08 */
+	uart8_bus: uart8-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1", "gpp4-2", "gpp4-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart8_bus_dual: uart8-bus-dual-pins {
+		samsung,pins = "gpp4-0", "gpp4-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI00  */
+	hsi2c0_bus: hsi2c0-bus-pins {
+		samsung,pins = "gpp0-0", "gpp0-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI00_I2C */
+	hsi2c1_bus: hsi2c1-bus-pins {
+		samsung,pins = "gpp0-2", "gpp0-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI01 */
+	hsi2c2_bus: hsi2c2-bus-pins {
+		samsung,pins = "gpp0-4", "gpp0-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI01_I2C */
+	hsi2c3_bus: hsi2c3-bus-pins {
+		samsung,pins = "gpp0-6", "gpp0-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI02 */
+	hsi2c4_bus: hsi2c4-bus-pins {
+		samsung,pins = "gpp1-0", "gpp1-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI02_I2C */
+	hsi2c5_bus: hsi2c5-bus-pins {
+		samsung,pins = "gpp1-2", "gpp1-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI03 */
+	hsi2c6_bus: hsi2c6-bus-pins {
+		samsung,pins = "gpp1-4", "gpp1-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI03_I2C */
+	hsi2c7_bus: hsi2c7-bus-pins {
+		samsung,pins = "gpp1-6", "gpp1-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI04 */
+	hsi2c8_bus: hsi2c8-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI04_I2C */
+	hsi2c9_bus: hsi2c9-bus-pins {
+		samsung,pins = "gpp2-2", "gpp2-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI05 */
+	hsi2c10_bus: hsi2c10-bus-pins {
+		samsung,pins = "gpp2-4", "gpp2-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI05_I2C */
+	hsi2c11_bus: hsi2c11-bus-pins {
+		samsung,pins = "gpp2-6", "gpp2-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI06 */
+	hsi2c12_bus: hsi2c12-bus-pins {
+		samsung,pins = "gpp3-0", "gpp3-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI06_I2C */
+	hsi2c13_bus: hsi2c13-bus-pins {
+		samsung,pins = "gpp3-2", "gpp3-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI07 */
+	hsi2c14_bus: hsi2c14-bus-pins {
+		samsung,pins = "gpp3-4", "gpp3-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI07_I2C */
+	hsi2c15_bus: hsi2c15-bus-pins {
+		samsung,pins = "gpp3-6", "gpp3-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI08 */
+	hsi2c16_bus: hsi2c16-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC0 USI08_I2C */
+	hsi2c17_bus: hsi2c17-bus-pins {
+		samsung,pins = "gpp4-2", "gpp4-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC0 USI00 */
+	spi0_bus: spi0-bus-pins {
+		samsung,pins = "gpp0-0", "gpp0-1", "gpp0-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi0_cs: spi0-cs-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi0_cs_func: spi0-cs-func-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC0 USI01 */
+	spi1_bus: spi1-bus-pins {
+		samsung,pins = "gpp0-4", "gpp0-5", "gpp0-6";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi1_cs: spi1-cs-pins {
+		samsung,pins = "gpp0-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi1_cs_func: spi1-cs-func-pins {
+		samsung,pins = "gpp0-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC0 USI02 */
+	spi2_bus: spi2-bus-pins {
+		samsung,pins = "gpp1-0", "gpp1-1", "gpp1-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi2_cs: spi2-cs-pins {
+		samsung,pins = "gpp1-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi2_cs_func: spi2-cs-func-pins {
+		samsung,pins = "gpp1-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC0 USI03 */
+	spi3_bus: spi3-bus-pins {
+		samsung,pins = "gpp1-4", "gpp1-5", "gpp1-6";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi3_cs: spi3-cs-pins {
+		samsung,pins = "gpp1-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi3_cs_func: spi3-cs-func-pins {
+		samsung,pins = "gpp1-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC0 USI04 */
+	spi4_bus: spi4-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1", "gpp2-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi4_cs: spi4-cs-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi4_cs_func: spi4-cs-func-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC0 USI05 */
+	spi5_bus: spi5-bus-pins {
+		samsung,pins = "gpp2-4", "gpp2-5", "gpp2-6";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi5_cs: spi5-cs-pins {
+		samsung,pins = "gpp2-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi5_cs_func: spi5-cs-func-pins {
+		samsung,pins = "gpp2-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC0 USI06 */
+	spi6_bus: spi6-bus-pins {
+		samsung,pins = "gpp3-0", "gpp3-1", "gpp3-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi6_cs: spi6-cs-pins {
+		samsung,pins = "gpp3-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi6_cs_func: spi6-cs-func-pins {
+		samsung,pins = "gpp3-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC0 USI07 */
+	spi7_bus: spi7-bus-pins {
+		samsung,pins = "gpp3-4", "gpp3-5", "gpp3-6";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi7_cs: spi7-cs-pins {
+		samsung,pins = "gpp3-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi7_cs_func: spi7-cs-func-pins {
+		samsung,pins = "gpp3-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC0 USI08 */
+	spi8_bus: spi8-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1", "gpp4-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi8_cs: spi8-cs-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi8_cs_func: spi8-cs-func-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I3C PERIC0 */
+	i3c0_bus: i3c0-bus-pins {
+		samsung,pins = "gpp2-6", "gpp2-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	i3c1_bus: i3c1-bus-pins {
+		samsung,pins = "gpp3-2", "gpp3-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	i3c2_bus: i3c2-bus-pins {
+		samsung,pins = "gpp3-6", "gpp3-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	i3c3_bus: i3c3-bus-pins {
+		samsung,pins = "gpp4-2", "gpp4-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* PWM PERIC0 */
+	pwm_tout0: pwm-tout0-pins {
+		samsung,pins = "gpg0-0";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	pwm_tout1: pwm-tout1-pins {
+		samsung,pins = "gpg0-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	pwm_tout2: pwm-tout2-pins {
+		samsung,pins = "gpg0-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	pwm_tout3: pwm-tout3-pins {
+		samsung,pins = "gpg0-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+};
+
+&pinctrl_peric1 {
+	gpp5: gpp5-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp6: gpp6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp7: gpp7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp8: gpp8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp9: gpp9-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp10: gpp10-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp11: gpp11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp12: gpp12-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpg1: gpg1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	/* UART PERIC1 USI09 */
+	uart9_bus: uart9-bus-pins {
+		samsung,pins = "gpp5-0", "gpp5-1", "gpp5-2", "gpp5-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart9_bus_dual: uart9-bus-dual-pins {
+		samsung,pins = "gpp5-0", "gpp5-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC1 USI10 */
+	uart10_bus: uart10-bus-pins {
+		samsung,pins = "gpp5-4", "gpp5-5", "gpp5-6", "gpp5-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart10_bus_dual: uart10-bus-dual-pins {
+		samsung,pins = "gpp5-4", "gpp5-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC1 USI11 */
+	uart11_bus: uart11-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1", "gpp10-2", "gpp10-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart11_bus_dual: uart11-bus-dual-pins {
+		samsung,pins = "gpp10-0", "gpp10-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC1_USI12 */
+	uart12_bus: uart12-bus-pins {
+		samsung,pins = "gpp7-0", "gpp7-1", "gpp7-2", "gpp7-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart12_bus_dual: uart12-bus-dual-pins {
+		samsung,pins = "gpp7-0", "gpp7-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC1_USI13 */
+	uart13_bus: uart13-bus-pins {
+		samsung,pins = "gpp7-4", "gpp7-5", "gpp7-6", "gpp7-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart13_bus_dual: uart13-bus-dual-pins {
+		samsung,pins = "gpp7-4", "gpp7-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC1 USI14 */
+	uart14_bus: uart14-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1", "gpp8-2", "gpp8-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart14_bus_dual: uart14-bus-dual-pins {
+		samsung,pins = "gpp8-0", "gpp8-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC1 USI15 */
+	uart15_bus: uart15-bus-pins {
+		samsung,pins = "gpp11-0", "gpp11-1", "gpp11-2", "gpp11-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart15_bus_dual: uart15-bus-dual-pins {
+		samsung,pins = "gpp11-0", "gpp11-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC1 USI16 */
+	uart16_bus: uart16-bus-pins {
+		samsung,pins = "gpp9-0", "gpp9-1", "gpp9-2", "gpp9-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart16_bus_dual: uart16-bus-dual-pins {
+		samsung,pins = "gpp9-0", "gpp9-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* UART PERIC1 USI17 */
+	uart17_bus: uart17-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1", "gpp12-2", "gpp12-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	uart17_bus_dual: uart17-bus-dual-pins {
+		samsung,pins = "gpp12-0", "gpp12-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI09 */
+	hsi2c18_bus: hsi2c18-bus-pins {
+		samsung,pins = "gpp5-0", "gpp5-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI09_I2C */
+	hsi2c19_bus: hsi2c19-bus-pins {
+		samsung,pins = "gpp5-2", "gpp5-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI10 */
+	hsi2c20_bus: hsi2c20-bus-pins {
+		samsung,pins = "gpp5-4", "gpp5-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI10_I2C */
+	hsi2c21_bus: hsi2c21-bus-pins {
+		samsung,pins = "gpp5-6", "gpp5-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI11 */
+	hsi2c22_bus: hsi2c22-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI11_I2C */
+	hsi2c23_bus: hsi2c23-bus-pins {
+		samsung,pins = "gpp10-2", "gpp10-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI12 */
+	hsi2c24_bus: hsi2c24-bus-pins {
+		samsung,pins = "gpp7-0", "gpp7-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI12_I2C */
+	hsi2c25_bus: hsi2c25-bus-pins {
+		samsung,pins = "gpp7-2", "gpp7-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI13 */
+	hsi2c26_bus: hsi2c26-bus-pins {
+		samsung,pins = "gpp7-4", "gpp7-5";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI13_I2C */
+	hsi2c27_bus: hsi2c27-bus-pins {
+		samsung,pins = "gpp7-6", "gpp7-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI14 */
+	hsi2c28_bus: hsi2c28-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI14_I2C */
+	hsi2c29_bus: hsi2c29-bus-pins {
+		samsung,pins = "gpp8-2", "gpp8-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI15 */
+	hsi2c30_bus: hsi2c30-bus-pins {
+		samsung,pins = "gpp11-0", "gpp11-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI15_I2C */
+	hsi2c31_bus: hsi2c31-bus-pins {
+		samsung,pins = "gpp11-2", "gpp11-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI16 */
+	hsi2c32_bus: hsi2c32-bus-pins {
+		samsung,pins = "gpp9-0", "gpp9-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI16_I2C */
+	hsi2c33_bus: hsi2c33-bus-pins {
+		samsung,pins = "gpp9-2", "gpp9-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI17 */
+	hsi2c34_bus: hsi2c34-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I2C PERIC1 USI17_I2C */
+	hsi2c35_bus: hsi2c35-bus-pins {
+		samsung,pins = "gpp12-2", "gpp12-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC1 USI09 */
+	spi9_bus: spi9-bus-pins {
+		samsung,pins = "gpp5-0", "gpp5-1", "gpp5-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi9_cs: spi9-cs-pins {
+		samsung,pins = "gpp5-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi9_cs_func: spi9-cs-func-pins {
+		samsung,pins = "gpp5-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC1 USI10 */
+	spi10_bus: spi10-bus-pins {
+		samsung,pins = "gpp5-4", "gpp5-5", "gpp5-6";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi10_cs: spi10-cs-pins {
+		samsung,pins = "gpp5-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi10_cs_func: spi10-cs-func-pins {
+		samsung,pins = "gpp5-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC1 USI11 */
+	spi11_bus: spi11-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1", "gpp10-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi11_cs: spi11-cs-pins {
+		samsung,pins = "gpp10-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi11_cs_func: spi11-cs-func-pins {
+		samsung,pins = "gpp10-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC1 USI12 */
+	spi12_bus: spi12-bus-pins {
+		samsung,pins = "gpp7-0", "gpp7-1", "gpp7-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi12_cs: spi12-cs-pins {
+		samsung,pins = "gpp7-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi12_cs_func: spi12-cs-func-pins {
+		samsung,pins = "gpp7-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC1 USI13 */
+	spi13_bus: spi13-bus-pins {
+		samsung,pins = "gpp7-4", "gpp7-5", "gpp7-6";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi13_cs: spi13-cs-pins {
+		samsung,pins = "gpp7-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi13_cs_func: spi13-cs-func-pins {
+		samsung,pins = "gpp7-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC1 USI14 */
+	spi14_bus: spi14-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1", "gpp8-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi14_cs: spi14-cs-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi14_cs_func: spi14-cs-func-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC1 USI15 */
+	spi15_bus: spi15-bus-pins {
+		samsung,pins = "gpp11-0", "gpp11-1", "gpp11-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi15_cs: spi15-cs-pins {
+		samsung,pins = "gpp11-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi15_cs_func: spi15-cs-func-pins {
+		samsung,pins = "gpp11-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC1 USI16 */
+	spi16_bus: spi16-bus-pins {
+		samsung,pins = "gpp9-0", "gpp9-1", "gpp9-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi16_cs: spi16-cs-pins {
+		samsung,pins = "gpp9-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi16_cs_func: spi16-cs-func-pins {
+		samsung,pins = "gpp9-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* SPI PERIC1 USI17 */
+	spi17_bus: spi17-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1", "gpp12-2";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi17_cs: spi17-cs-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	spi17_cs_func: spi17-cs-func-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	/* I3C PERIC1 */
+	i3c4_bus: i3c4-bus-pins {
+		samsung,pins = "gpp7-2", "gpp7-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	i3c5_bus: i3c5-bus-pins {
+		samsung,pins = "gpp7-6", "gpp7-7";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	i3c6_bus: i3c6-bus-pins {
+		samsung,pins = "gpp8-2", "gpp8-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
+	i3c7_bus: i3c7-bus-pins {
+		samsung,pins = "gpp11-2", "gpp11-3";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+};
diff --git a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
new file mode 100644
index 000000000000..8756df584b10
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung's ExynosAutov920 SoC device tree source
+ *
+ * Copyright (c) 2023 Samsung Electronics Co., Ltd.
+ *
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/samsung,exynos-usi.h>
+
+/ {
+	compatible = "samsung,exynosautov920";
+	#address-cells = <2>;
+	#size-cells = <1>;
+
+	interrupt-parent = <&gic>;
+
+	aliases {
+		pinctrl0 = &pinctrl_alive;
+		pinctrl1 = &pinctrl_aud;
+		pinctrl2 = &pinctrl_hsi0;
+		pinctrl3 = &pinctrl_hsi1;
+		pinctrl4 = &pinctrl_hsi2;
+		pinctrl5 = &pinctrl_hsi2ufs;
+		pinctrl6 = &pinctrl_peric0;
+		pinctrl7 = &pinctrl_peric1;
+	};
+
+	arm-pmu {
+		compatible = "arm,cortex-a78-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
+	};
+
+	xtcxo: clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-output-names = "oscclk";
+	};
+
+	/*
+	 * FIXME: Keep the stub clock for serial driver, until proper clock
+	 * driver is implemented.
+	 */
+	clock_usi: clock-usi {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <200000000>;
+		clock-output-names = "usi";
+	};
+
+	cpus: cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+				core1 {
+					cpu = <&cpu1>;
+				};
+				core2 {
+					cpu = <&cpu2>;
+				};
+				core3 {
+					cpu = <&cpu3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu4>;
+				};
+				core1 {
+					cpu = <&cpu5>;
+				};
+				core2 {
+					cpu = <&cpu6>;
+				};
+				core3 {
+					cpu = <&cpu7>;
+				};
+			};
+
+			cluster2 {
+				core0 {
+					cpu = <&cpu8>;
+				};
+				core1 {
+					cpu = <&cpu9>;
+				};
+			};
+		};
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+		};
+
+		cpu1: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x100>;
+			enable-method = "psci";
+		};
+
+		cpu2: cpu at 200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x200>;
+			enable-method = "psci";
+		};
+
+		cpu3: cpu at 300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x300>;
+			enable-method = "psci";
+		};
+
+		cpu4: cpu at 10000 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x10000>;
+			enable-method = "psci";
+		};
+
+		cpu5: cpu at 10100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x10100>;
+			enable-method = "psci";
+		};
+
+		cpu6: cpu at 10200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x10200>;
+			enable-method = "psci";
+		};
+
+		cpu7: cpu at 10300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x10300>;
+			enable-method = "psci";
+		};
+
+		cpu8: cpu at 20000 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x20000>;
+			enable-method = "psci";
+		};
+
+		cpu9: cpu at 20100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a78ae";
+			reg = <0x0 0x20100>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	soc: soc at 0 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0x0 0x20000000>;
+
+		chipid at 10000000 {
+			compatible = "samsung,exynosautov920-chipid",
+				     "samsung,exynos850-chipid";
+			reg = <0x10000000 0x24>;
+		};
+
+		gic: interrupt-controller at 10400000 {
+			compatible = "arm,gic-v3";
+			#interrupt-cells = <3>;
+			#address-cells = <0>;
+			interrupt-controller;
+			reg = <0x10400000 0x10000>,
+			      <0x10460000 0x140000>;
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		pinctrl_alive: pinctrl at 11850000 {
+			compatible = "samsung,exynosautov920-pinctrl";
+			reg = <0x11850000 0x10000>;
+
+			wakeup-interrupt-controller {
+				compatible = "samsung,exynosautov920-wakeup-eint",
+					     "samsung,exynos850-wakeup-eint",
+					     "samsung,exynos7-wakeup-eint";
+			};
+		};
+
+		pinctrl_aud: pinctrl at 1a460000 {
+			compatible = "samsung,exynosautov920-pinctrl";
+			reg = <0x1a460000 0x10000>;
+		};
+
+		pinctrl_hsi0: pinctrl at 16040000 {
+			compatible = "samsung,exynosautov920-pinctrl";
+			reg = <0x16040000 0x10000>;
+			interrupts = <GIC_SPI 442 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		pinctrl_hsi1: pinctrl at 16450000 {
+			compatible = "samsung,exynosautov920-pinctrl";
+			reg = <0x16450000 0x10000>;
+			interrupts = <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		pinctrl_hsi2: pinctrl at 16c10000 {
+			compatible = "samsung,exynosautov920-pinctrl";
+			reg = <0x16c10000 0x10000>;
+			interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		pinctrl_hsi2ufs: pinctrl at 16d20000 {
+			compatible = "samsung,exynosautov920-pinctrl";
+			reg = <0x16d20000 0x10000>;
+			interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		pinctrl_peric0: pinctrl at 10830000 {
+			compatible = "samsung,exynosautov920-pinctrl";
+			reg = <0x10830000 0x10000>;
+			interrupts = <GIC_SPI 753 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		pinctrl_peric1: pinctrl at 10c30000 {
+			compatible = "samsung,exynosautov920-pinctrl";
+			reg = <0x10c30000 0x10000>;
+			interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		pmu_system_controller: system-controller at 11860000 {
+			compatible = "samsung,exynosautov920-pmu",
+				     "samsung,exynos7-pmu","syscon";
+			reg = <0x11860000 0x10000>;
+		};
+
+		pwm: pwm at 109b0000 {
+			compatible = "samsung,exynosautov920-pwm",
+				     "samsung,exynos4210-pwm";
+			reg = <0x109b0000 0x100>;
+			samsung,pwm-outputs = <0>, <1>, <2>, <3>;
+			#pwm-cells = <3>;
+			clocks = <&xtcxo>;
+			clock-names = "timers";
+			status = "disabled";
+		};
+
+		syscon_peric0: syscon at 10820000 {
+			compatible = "samsung,exynosautov920-peric0-sysreg",
+				     "syscon";
+			reg = <0x10820000 0x2000>;
+		};
+
+		syscon_peric1: syscon at 10c20000 {
+			compatible = "samsung,exynosautov920-peric1-sysreg",
+				     "syscon";
+			reg = <0x10c20000 0x2000>;
+		};
+
+		usi_0: usi at 108800c0 {
+			compatible = "samsung,exynosautov920-usi",
+				     "samsung,exynos850-usi";
+			reg = <0x108800c0 0x20>;
+			samsung,sysreg = <&syscon_peric0 0x1000>;
+			samsung,mode = <USI_V2_UART>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+			clocks = <&clock_usi>, <&clock_usi>;
+			clock-names = "pclk", "ipclk";
+			status = "disabled";
+
+			serial_0: serial at 10880000 {
+				compatible = "samsung,exynosautov920-uart",
+					     "samsung,exynos850-uart";
+				reg = <0x10880000 0xc0>;
+				interrupts = <GIC_SPI 764 IRQ_TYPE_LEVEL_HIGH>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&uart0_bus>;
+				clocks = <&clock_usi>, <&clock_usi>;
+				clock-names = "uart", "clk_uart_baud0";
+				samsung,uart-fifosize = <256>;
+				status = "disabled";
+			};
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+#include "exynosautov920-pinctrl.dtsi"
-- 
2.43.0



From jaewon02.kim at samsung.com  Thu Dec  7 23:45:26 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Fri,  8 Dec 2023 16:45:26 +0900
Subject: [PATCH v3 3/4] pinctrl: samsung: support ExynosAuto GPIO structure
In-Reply-To: <20231208074527.50840-1-jaewon02.kim@samsung.com>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
	<CGME20231208075020epcas2p260c65fa8d33e0cd97806f065bb8a044d@epcas2p2.samsung.com>
Message-ID: <20231208074527.50840-4-jaewon02.kim@samsung.com>

New ExynosAuto series GPIO have a different register structure.
In the existing Exynos series, EINT control register enumerated after
a specific offset (e.g EXYNOS_GPIO_ECON_OFFSET, EXYNOS_GPIO_EMASK_OFFSET).
However, from ExynosAutov920 SoC, the register that controls EINT belongs
to each GPIO bank, and each GPIO bank has 0x1000 align.

This is a structure to protect the GPIO bank using S2MPU in VM environment,
and will only be applied in ExynosAuto series SoCs.

-------------------------------------------------
| original		| ExynosAutov920	|
|-----------------------------------------------|
| 0x0	GPIO_CON	| 0x0	GPIO_CON	|
| 0x4	GPIO_DAT	| 0x4	GPIO_DAT	|
| 0x8	GPIO_PUD	| 0x8	GPIO_PUD	|
| 0xc	GPIO_DRV	| 0xc	GPIO_DRV	|
| 0x10	GPIO_CONPDN	| 0x10	GPIO_CONPDN	|
| 0x14	GPIO_PUDPDN	| 0x14	GPIO_PUDPDN	|
| 0x700	EINT_CON	| 0x18	EINT_CON	|
| 0x800	EINT_FLTCON	| 0x1c	EINT_FLTCON0	|
| 0x900	EINT_MASK	| 0x20	EINT_FLTCON1	|
| 0xa00	EINT_PEND	| 0x24	EINT_MASK	|
|			| 0x28	EINT_PEND	|
-------------------------------------------------

Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 81 +++++++++++++++++++++--
 drivers/pinctrl/samsung/pinctrl-exynos.h  |  1 +
 drivers/pinctrl/samsung/pinctrl-samsung.c |  3 +
 drivers/pinctrl/samsung/pinctrl-samsung.h | 12 ++++
 4 files changed, 90 insertions(+), 7 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 6b58ec84e34b..f798f64b1122 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -56,6 +56,9 @@ static void exynos_irq_mask(struct irq_data *irqd)
 	unsigned int mask;
 	unsigned long flags;
 
+	if (bank->eint_mask_offset)
+		reg_mask = bank->pctl_offset + bank->eint_mask_offset;
+
 	raw_spin_lock_irqsave(&bank->slock, flags);
 
 	mask = readl(bank->eint_base + reg_mask);
@@ -72,6 +75,9 @@ static void exynos_irq_ack(struct irq_data *irqd)
 	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
 	unsigned long reg_pend = our_chip->eint_pend + bank->eint_offset;
 
+	if (bank->eint_pend_offset)
+		reg_pend = bank->pctl_offset + bank->eint_pend_offset;
+
 	writel(1 << irqd->hwirq, bank->eint_base + reg_pend);
 }
 
@@ -95,6 +101,9 @@ static void exynos_irq_unmask(struct irq_data *irqd)
 	if (irqd_get_trigger_type(irqd) & IRQ_TYPE_LEVEL_MASK)
 		exynos_irq_ack(irqd);
 
+	if (bank->eint_mask_offset)
+		reg_mask = bank->pctl_offset + bank->eint_mask_offset;
+
 	raw_spin_lock_irqsave(&bank->slock, flags);
 
 	mask = readl(bank->eint_base + reg_mask);
@@ -139,6 +148,9 @@ static int exynos_irq_set_type(struct irq_data *irqd, unsigned int type)
 	else
 		irq_set_handler_locked(irqd, handle_level_irq);
 
+	if (bank->eint_con_offset)
+		reg_con = bank->pctl_offset + bank->eint_con_offset;
+
 	con = readl(bank->eint_base + reg_con);
 	con &= ~(EXYNOS_EINT_CON_MASK << shift);
 	con |= trig_type << shift;
@@ -221,6 +233,18 @@ static const struct exynos_irq_chip exynos_gpio_irq_chip __initconst = {
 	/* eint_wake_mask_value not used */
 };
 
+static const struct exynos_irq_chip exynosauto_gpio_irq_chip __initconst = {
+	.chip = {
+		.name = "exynosauto_gpio_irq_chip",
+		.irq_unmask = exynos_irq_unmask,
+		.irq_mask = exynos_irq_mask,
+		.irq_ack = exynos_irq_ack,
+		.irq_set_type = exynos_irq_set_type,
+		.irq_request_resources = exynos_irq_request_resources,
+		.irq_release_resources = exynos_irq_release_resources,
+	},
+};
+
 static int exynos_eint_irq_map(struct irq_domain *h, unsigned int virq,
 					irq_hw_number_t hw)
 {
@@ -247,7 +271,10 @@ static irqreturn_t exynos_eint_gpio_irq(int irq, void *data)
 	unsigned int svc, group, pin;
 	int ret;
 
-	svc = readl(bank->eint_base + EXYNOS_SVC_OFFSET);
+	if (bank->eint_con_offset)
+		svc = readl(bank->eint_base + EXYNOSAUTO_SVC_OFFSET);
+	else
+		svc = readl(bank->eint_base + EXYNOS_SVC_OFFSET);
 	group = EXYNOS_SVC_GROUP(svc);
 	pin = svc & EXYNOS_SVC_NUM_MASK;
 
@@ -297,8 +324,12 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
 		if (bank->eint_type != EINT_TYPE_GPIO)
 			continue;
 
-		bank->irq_chip = devm_kmemdup(dev, &exynos_gpio_irq_chip,
-					   sizeof(*bank->irq_chip), GFP_KERNEL);
+		if (bank->eint_con_offset)
+			bank->irq_chip = devm_kmemdup(dev, &exynosauto_gpio_irq_chip,
+						      sizeof(*bank->irq_chip), GFP_KERNEL);
+		else
+			bank->irq_chip = devm_kmemdup(dev, &exynos_gpio_irq_chip,
+						      sizeof(*bank->irq_chip), GFP_KERNEL);
 		if (!bank->irq_chip) {
 			ret = -ENOMEM;
 			goto err_domains;
@@ -655,6 +686,19 @@ static void exynos_pinctrl_suspend_bank(
 	pr_debug("%s: save    mask %#010x\n", bank->name, save->eint_mask);
 }
 
+static void exynosauto_pinctrl_suspend_bank(struct samsung_pinctrl_drv_data *drvdata,
+					    struct samsung_pin_bank *bank)
+{
+	struct exynos_eint_gpio_save *save = bank->soc_priv;
+	void __iomem *regs = bank->eint_base;
+
+	save->eint_con = readl(regs + bank->pctl_offset + bank->eint_con_offset);
+	save->eint_mask = readl(regs + bank->pctl_offset + bank->eint_mask_offset);
+
+	pr_debug("%s: save     con %#010x\n", bank->name, save->eint_con);
+	pr_debug("%s: save    mask %#010x\n", bank->name, save->eint_mask);
+}
+
 void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
@@ -662,8 +706,12 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 	int i;
 
 	for (i = 0; i < drvdata->nr_banks; ++i, ++bank) {
-		if (bank->eint_type == EINT_TYPE_GPIO)
-			exynos_pinctrl_suspend_bank(drvdata, bank);
+		if (bank->eint_type == EINT_TYPE_GPIO) {
+			if (bank->eint_con_offset)
+				exynosauto_pinctrl_suspend_bank(drvdata, bank);
+			else
+				exynos_pinctrl_suspend_bank(drvdata, bank);
+		}
 		else if (bank->eint_type == EINT_TYPE_WKUP) {
 			if (!irq_chip) {
 				irq_chip = bank->irq_chip;
@@ -704,14 +752,33 @@ static void exynos_pinctrl_resume_bank(
 						+ bank->eint_offset);
 }
 
+static void exynosauto_pinctrl_resume_bank(struct samsung_pinctrl_drv_data *drvdata,
+					   struct samsung_pin_bank *bank)
+{
+	struct exynos_eint_gpio_save *save = bank->soc_priv;
+	void __iomem *regs = bank->eint_base;
+
+	pr_debug("%s:     con %#010x => %#010x\n", bank->name,
+		 readl(regs + bank->pctl_offset + bank->eint_con_offset), save->eint_con);
+	pr_debug("%s:    mask %#010x => %#010x\n", bank->name,
+		 readl(regs + bank->pctl_offset + bank->eint_mask_offset), save->eint_mask);
+
+	writel(save->eint_con, regs + bank->pctl_offset + bank->eint_con_offset);
+	writel(save->eint_mask, regs + bank->pctl_offset + bank->eint_mask_offset);
+}
+
 void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
 	int i;
 
 	for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
-		if (bank->eint_type == EINT_TYPE_GPIO)
-			exynos_pinctrl_resume_bank(drvdata, bank);
+		if (bank->eint_type == EINT_TYPE_GPIO) {
+			if (bank->eint_con_offset)
+				exynosauto_pinctrl_resume_bank(drvdata, bank);
+			else
+				exynos_pinctrl_resume_bank(drvdata, bank);
+		}
 }
 
 static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index 3ac52c2cf998..5049c170e958 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -31,6 +31,7 @@
 #define EXYNOS7_WKUP_EMASK_OFFSET	0x900
 #define EXYNOS7_WKUP_EPEND_OFFSET	0xA00
 #define EXYNOS_SVC_OFFSET		0xB08
+#define EXYNOSAUTO_SVC_OFFSET		0xF008
 
 /* helpers to access interrupt service register */
 #define EXYNOS_SVC_GROUP_SHIFT		3
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 79babbb39ced..362e99566919 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1106,6 +1106,9 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
 		bank->eint_type = bdata->eint_type;
 		bank->eint_mask = bdata->eint_mask;
 		bank->eint_offset = bdata->eint_offset;
+		bank->eint_con_offset = bdata->eint_con_offset;
+		bank->eint_mask_offset = bdata->eint_mask_offset;
+		bank->eint_pend_offset = bdata->eint_pend_offset;
 		bank->name = bdata->name;
 
 		raw_spin_lock_init(&bank->slock);
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 9b3db50adef3..789358bcd9c5 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -122,6 +122,9 @@ struct samsung_pin_bank_type {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @eint_con_offset: ExynosAuto SoC-specific EINT control register offset of bank.
+ * @eint_mask_offset: ExynosAuto SoC-specific EINT mask register offset of bank.
+ * @eint_pend_offset: ExynosAuto SoC-specific EINT pend register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  */
 struct samsung_pin_bank_data {
@@ -133,6 +136,9 @@ struct samsung_pin_bank_data {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	u32		eint_con_offset;
+	u32		eint_mask_offset;
+	u32		eint_pend_offset;
 	const char	*name;
 };
 
@@ -147,6 +153,9 @@ struct samsung_pin_bank_data {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @eint_con_offset: ExynosAuto SoC-specific EINT register or interrupt offset of bank.
+ * @eint_mask_offset: ExynosAuto SoC-specific EINT mask register offset of bank.
+ * @eint_pend_offset: ExynosAuto SoC-specific EINT pend register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  * @id: id of the bank, propagated to the pin range.
  * @pin_base: starting pin number of the bank.
@@ -170,6 +179,9 @@ struct samsung_pin_bank {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	u32		eint_con_offset;
+	u32		eint_mask_offset;
+	u32		eint_pend_offset;
 	const char	*name;
 	u32		id;
 
-- 
2.43.0



From lukasz.luba at arm.com  Thu Dec  7 23:58:19 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Fri, 8 Dec 2023 07:58:19 +0000
Subject: [PATCH] arm64: dts: rockchip: Add dynamic-power-coefficient to
 rk3399 GPU
In-Reply-To: <170198105573.18516.6264175947902125145.b4-ty@sntech.de>
References: <20231127081511.1911706-1-lukasz.luba@arm.com>
 <170198105573.18516.6264175947902125145.b4-ty@sntech.de>
Message-ID: <adf5cfa3-b38c-42b5-a98d-c8738c36737f@arm.com>



On 12/7/23 20:30, Heiko Stuebner wrote:
> On Mon, 27 Nov 2023 08:15:11 +0000, Lukasz Luba wrote:
>> Add dynamic-power-coefficient to the GPU node. That will create Energy
>> Model for the GPU based on the coefficient and OPP table information.
>> It will enable mechanism such as DTMP or IPA to work with the GPU DVFS.
>> In similar way the Energy Model for CPUs in rk3399 is created, so both
>> are aligned in power scale. The maximum power used from this coefficient
>> is 1.5W at 600MHz.
>>
>> [...]
> 
> Applied, thanks!

Thank you Heiko!

> 
> [1/1] arm64: dts: rockchip: Add dynamic-power-coefficient to rk3399 GPU
>        commit: 381d48fbada9b5b39f5a811bb8fe76365d6bdd5c
> 
> Best regards,


From maxime.chevallier at bootlin.com  Fri Dec  8 00:14:08 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 8 Dec 2023 09:14:08 +0100
Subject: [PATCH] net:stmmac:stmmac_platform:Add snps,xpcs devicetree
 parsing
In-Reply-To: <SA0PR12MB44138E48A245378CF54D2F9ED98AA@SA0PR12MB4413.namprd12.prod.outlook.com>
References: <SA0PR12MB44138E48A245378CF54D2F9ED98AA@SA0PR12MB4413.namprd12.prod.outlook.com>
Message-ID: <20231208091408.071680db@device.home>

Hello,

On Fri, 8 Dec 2023 07:02:19 +0000
Jiangfeng Ma <Jiangfeng.Ma at synopsys.com> wrote:

> In order to setup xpcs, has_xpcs must be set to a non-zero value.
> Add new optional devicetree properties representing this.
> 
> If has_xpcs is set to true, then xpcs_an_inband should preferably be
> consistent with it, Otherwise, some errors may occur when starting
> the network, For example, the phy interface that xpcs already supports,
> but link up fails.

Can you elaborate on why you need this, and on which platform
especially ? Usually drivers for the various stmmac variants know if
they have XPCS or not, or can guess it based on some info such as the
configured PHY mode (dwmac-intel).

Besides that, there are a few issues with your submission. If DT is the
way to go (and I don't say it is), you would also need to update the
bindings to document that property.

> The types of has_xpcs and xpcs_an_inband are unsigned int,
> and generally used as flags. So it may be more reasonable to set them to
> bool type. This can also be confirmed from the type of @ovr_an_inband.

And this part would go into a separate patch.

Thanks,

Maxime


From tabba at google.com  Fri Dec  8 00:14:58 2023
From: tabba at google.com (Fuad Tabba)
Date: Fri, 8 Dec 2023 08:14:58 +0000
Subject: [PATCH v2 01/12] KVM: Add missing HCRX_EL2 field definitions
In-Reply-To: <7c85421b-5dfd-4931-bb14-aa2416e54b58@sirena.org.uk>
References: <20231206100503.564090-1-tabba@google.com> <20231206100503.564090-2-tabba@google.com>
 <7c85421b-5dfd-4931-bb14-aa2416e54b58@sirena.org.uk>
Message-ID: <CA+EHjTx7LJJzOHbO=ubWtuwhbVXd3FyX99Y6LxkT6u9vSx8qxA@mail.gmail.com>

Hi Mark,

Thanks for your reviews!

On Thu, Dec 7, 2023 at 4:57?PM Mark Brown <broonie at kernel.org> wrote:
>
> On Wed, Dec 06, 2023 at 10:04:51AM +0000, Fuad Tabba wrote:
> > Add the latest field definitions to HCRX_EL2 from the 2023-09 Arm
> > Architecture System Registers xml specification [*].
> >
> > These fields aren't used yet. This is done mainly to get the
> > correct generated value for the register's RES0 mask.
>
> > ---
> >  arch/arm64/tools/sysreg | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
>
> This isn't a KVM specific patch, this is an arch patch - I'd have
> expected a subject line "arm64/sysreg:" or something...

Sorry. That was the intention, instead of removing the KVM for my
"KVM:arm64"s I removed the arm. Will fix it on the respin.

>
> >  Sysreg       HCRX_EL2        3       4       1       2       2
> > -Res0 63:23
> > +Res0 63:25
> > +Field        24      PACMEn
> > +Field        23      EnFPM
> >  Field        22      GCSEn
> >  Field        21      EnIDCP128
> >  Field        20      EnSDERR
>
> This is the same as my equivalent patch in the 2023 dpISA series:
>
>    https://lore.kernel.org/linux-arm-kernel/20231205-arm64-2023-dpisa-v3-7-dbcbcd867a7f at kernel.org/
>
> Reviewed-by: Mark Brown <broonie at kernel.org>
>
> (that series does make use of EnFPM).  Given the likelyhood of overlaps
> like this I really think we should be merging these sysreg updates even
> if the serieses that depend on them are still in flight, it doesn't make
> sense for multiple people to end up doing the typing.

Makes sense. We'll ask one of the maintainers to pick up your updates.

Cheers,
/fuad


From tabba at google.com  Fri Dec  8 00:16:51 2023
From: tabba at google.com (Fuad Tabba)
Date: Fri, 8 Dec 2023 08:16:51 +0000
Subject: [PATCH v2 02/12] KVM: arm64: Add latest HFGxTR_EL2 FGT entries to
 nested virt
In-Reply-To: <13427a09-025b-414c-adad-6a13c58df54e@sirena.org.uk>
References: <20231206100503.564090-1-tabba@google.com> <20231206100503.564090-3-tabba@google.com>
 <13427a09-025b-414c-adad-6a13c58df54e@sirena.org.uk>
Message-ID: <CA+EHjTy=nXeb-hWMMts6nvuSo32+bMG=FrjGhpLBsEnqKh4H0w@mail.gmail.com>

Hi Mark,

On Thu, Dec 7, 2023 at 5:06?PM Mark Brown <broonie at kernel.org> wrote:
>
> On Wed, Dec 06, 2023 at 10:04:52AM +0000, Fuad Tabba wrote:
>
> > +#define SYS_GCSCR_EL1                        sys_reg(3, 0, 2, 5, 0)
> > +#define SYS_GCSPR_EL1                        sys_reg(3, 0, 2, 5, 1)
> > +#define SYS_GCSCRE0_EL1                      sys_reg(3, 0, 2, 5, 2)
> > +
>
> > +#define SYS_GCSPR_EL0                        sys_reg(3, 3, 2, 5, 1)
> > +
>
> Unless there's some complication with representing them (mainly register
> layouts that aren't representable with the language or *very* repetitive
> blocks of registers) we should be adding any new sysregs to the sysreg
> file rather than manually encoding them.  We're trying to move things
> out of sysreg.h as much as possible.

I thought that we're still using the encoded ones if we're not using
the fields of the registers. That said, I'll move to the generated one
in the respin.

>
> For the above you can pick up the patch from my GCS series:
>
>   https://lore.kernel.org/linux-arm-kernel/20231122-arm64-gcs-v7-6-201c483bd775 at kernel.org/
>
> > @@ -412,6 +423,8 @@
> >  #define SYS_PMUSERENR_EL0            sys_reg(3, 3, 9, 14, 0)
> >  #define SYS_PMOVSSET_EL0             sys_reg(3, 3, 9, 14, 3)
> >
> > +#define SYS_POR_EL0                  sys_reg(3, 3, 10, 2, 4)
> > +
>
> This is in Joey's POR series:
>
>   https://lore.kernel.org/linux-arm-kernel/20231124163510.1835740-2-joey.gouly at arm.com/
>
> Unfortunately I'm not aware of anyone having already done the rest.

I'll pick up what you and Joey have done and add the rest.

Thanks,
/fuad


From tabba at google.com  Fri Dec  8 00:17:19 2023
From: tabba at google.com (Fuad Tabba)
Date: Fri, 8 Dec 2023 08:17:19 +0000
Subject: [PATCH v2 03/12] KVM: arm64: Add latest HFGITR_EL2 FGT entries to
 nested virt
In-Reply-To: <bbe3b916-9db3-403c-acdf-8472c750bfcd@sirena.org.uk>
References: <20231206100503.564090-1-tabba@google.com> <20231206100503.564090-4-tabba@google.com>
 <bbe3b916-9db3-403c-acdf-8472c750bfcd@sirena.org.uk>
Message-ID: <CA+EHjTzwNnfwANuKmWtoipwb4nGhTt7RNtP=6ngfRqSErzAsuQ@mail.gmail.com>

Hi Mark,

On Thu, Dec 7, 2023 at 5:14?PM Mark Brown <broonie at kernel.org> wrote:
>
> On Wed, Dec 06, 2023 at 10:04:53AM +0000, Fuad Tabba wrote:
>
> > Add the missing nested virt FGT table entries HFGITR_EL2. Based
> > on the 2023-09 Arm Architecture System Registers xml
> > specification [*]. Add the missing field definitions as well,
> > both to generate the correct RES0 mask and to be able to toggle
> > their FGT bits.
> >
> > Also adds definitions of some of the missing system registers and
> > instructions, which can be trapped by the FGT bits.
> >
> > [*] https://developer.arm.com/downloads/-/exploration-tools
>
> That should be a reference to DDI0602 (for the instruction XML) and
> DD0601 (for the system register XML) - it's the same content, just a
> more stable name.

Got it. Will fix it on the respin.

Cheers,
/fuad

>
> >  Sysreg HFGITR_EL2    3       4       1       1       6
> > -Res0 63:61
> > +Res0 63
> > +Field        62      ATS1E1A
> > +Res0 61
> >  Field        60      COSPRCTX
> >  Field        59      nGCSEPP
> >  Field        58      nGCSSTR_EL1
>
> The sysreg looks good:
>
> Reviewed-by: Mark Brown <broonie at kernel.org>


From tabba at google.com  Fri Dec  8 00:17:44 2023
From: tabba at google.com (Fuad Tabba)
Date: Fri, 8 Dec 2023 08:17:44 +0000
Subject: [PATCH v2 04/12] KVM: arm64: Add bit masks for HAFGRTR_EL2
In-Reply-To: <268ebe97-1f79-416e-805e-9a67144f6a99@sirena.org.uk>
References: <20231206100503.564090-1-tabba@google.com> <20231206100503.564090-5-tabba@google.com>
 <268ebe97-1f79-416e-805e-9a67144f6a99@sirena.org.uk>
Message-ID: <CA+EHjTy53FTm6QtwhDhRNQrz-7CNnQro4VS67eWq+_z5KBofmA@mail.gmail.com>

Hi,

On Thu, Dec 7, 2023 at 5:19?PM Mark Brown <broonie at kernel.org> wrote:
>
> On Wed, Dec 06, 2023 at 10:04:54AM +0000, Fuad Tabba wrote:
> > To support HAFGRTR_EL2 supported in nested virt in the following
> > patch, first add its bitmask definitions based on the 2023-09
> > Arm Architecture System Registers xml specification [*].
> >
> > [*] https://developer.arm.com/downloads/-/exploration-tools
>
> DDI0601 is a more stable name, and I'd have expected an "arm64/sysreg"
> subject.

Got it.

Cheers,
/fuad

>
> > +#define __HAFGRTR_EL2_RES0   (GENMASK(63, 50) | GENMASK(16, 5))
> > +#define __HAFGRTR_EL2_MASK   (GENMASK(49, 17) | GENMASK(4, 0))
> > +#define __HAFGRTR_EL2_nMASK  0UL
> > +
>
> This one is an example of something where some manual encoding does make
> sense given all the AMCNTEN<x> and so on fields so:
>
> Reviewed-by: Mark Brown <broonie at kernel.org>


From johan at kernel.org  Fri Dec  8 00:19:24 2023
From: johan at kernel.org (Johan Hovold)
Date: Fri, 8 Dec 2023 09:19:24 +0100
Subject: [PATCH] iommu/arm-smmu-qcom: Add missing GMU entry to match table
In-Reply-To: <20231207212441.6199-1-robdclark@gmail.com>
References: <20231207212441.6199-1-robdclark@gmail.com>
Message-ID: <ZXLRjDZn9bgiREPf@hovoldconsulting.com>

On Thu, Dec 07, 2023 at 01:24:39PM -0800, Rob Clark wrote:
> From: Rob Clark <robdclark at chromium.org>
> 
> We also want the default domain for the GMU to be an identy domain,
> so it does not get a context bank assigned.  Without this, both
> of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
> allocating and configuring a context bank.  So GMU ends up attached
> to both cbndx 1 and cbndx 2.  This arrangement seemingly confounds
> and surprises the firmware if the GPU later triggers a translation
> fault, resulting (on sc8280xp / lenovo x13s, at least) in the SMMU
> getting wedged and the GPU stuck without memory access.

This sounds like something that should be backported. Should you add a
Fixes and CC-stable tag?
 
> Signed-off-by: Rob Clark <robdclark at chromium.org>

Johan


From tabba at google.com  Fri Dec  8 00:19:43 2023
From: tabba at google.com (Fuad Tabba)
Date: Fri, 8 Dec 2023 08:19:43 +0000
Subject: [PATCH v2 05/12] KVM: arm64: Handle HAFGRTR_EL2 trapping in
 nested virt
In-Reply-To: <006ec2b0-6263-4e86-8641-d81c01a91c8e@sirena.org.uk>
References: <20231206100503.564090-1-tabba@google.com> <20231206100503.564090-6-tabba@google.com>
 <006ec2b0-6263-4e86-8641-d81c01a91c8e@sirena.org.uk>
Message-ID: <CA+EHjTx42qgepOaFMt1wLSQ6uPUv8wQTa2z-Z_PEiVPUwYAL8A@mail.gmail.com>

Hi,

On Thu, Dec 7, 2023 at 5:28?PM Mark Brown <broonie at kernel.org> wrote:
>
> On Wed, Dec 06, 2023 at 10:04:55AM +0000, Fuad Tabba wrote:
>
> > Add the encodings to fine grain trapping fields for HAFGRTR_EL2
> > and add the associated handling code in nested virt. Based on
> > the 2023-09 Arm Architecture System Registers xml
> > specification [*]. Add the missing field definitions as well,
> > both to generate the correct RES0 mask and to be able to toggle
> > their FGT bits.
>
> > Also add the code for handling FGT trapping, reading of the
> > register, to nested virt.
>
> > [*] https://developer.arm.com/downloads/-/exploration-tools
>
> DDI0601.

Yup! :)

> > +Sysreg HAFGRTR_EL2   3       4       3       1       6
> > +Res0 63:50
> > +Field        49      AMEVTYPER115_EL0
> > +Field        48      AMEVCNTR115_EL0
> > +Field        47      AMEVTYPER114_EL0
> > +Field        46      AMEVCNTR114_EL0
> > +Field        45      AMEVTYPER113_EL0
> > +Field        44      AMEVCNTR113_EL0
> > +Field        43      AMEVTYPER112_EL0
> > +Field        42      AMEVCNTR112_EL0
> > +Field        41      AMEVTYPER111_EL0
> > +Field        40      AMEVCNTR111_EL0
> > +Field        39      AMEVTYPER110_EL0
> > +Field        38      AMEVCNTR110_EL0
> > +Field        37      AMEVTYPER19_EL0
> > +Field        36      AMEVCNTR19_EL0
> > +Field        35      AMEVTYPER18_EL0
> > +Field        34      AMEVCNTR18_EL0
> > +Field        33      AMEVTYPER17_EL0
> > +Field        32      AMEVCNTR17_EL0
> > +Field        31      AMEVTYPER16_EL0
> > +Field        30      AMEVCNTR16_EL0
> > +Field        29      AMEVTYPER15_EL0
> > +Field        28      AMEVCNTR15_EL0
> > +Field        27      AMEVTYPER14_EL0
> > +Field        26      AMEVCNTR14_EL0
> > +Field        25      AMEVTYPER13_EL0
> > +Field        24      AMEVCNTR13_EL0
> > +Field        23      AMEVTYPER12_EL0
> > +Field        22      AMEVCNTR12_EL0
> > +Field        21      AMEVTYPER11_EL0
> > +Field        20      AMEVCNTR11_EL0
> > +Field        19      AMEVTYPER10_EL0
> > +Field        18      AMEVCNTR10_EL0
> > +Field        17      AMCNTEN1
> > +Res0 16:5
> > +Field        4       AMEVCNTR03_EL0
> > +Field        3       AMEVCNTR02_EL0
> > +Field        2       AMEVCNTR01_EL0
> > +Field        1       AMEVCNTR00_EL0
> > +Field        0       AMCNTEN0
> > +EndSysreg
> > +
>
> Oh, we actually have the register fully encoded since we needed the
> fields.  Given this why did we need the manual encoding in the previous
> patch?  In any case this looks good according to DDI0601 2023-09:

We need both because we need to know the polarity. RES0 and the valid
bits are generated. In later patches in this series I move completely
to using the generated RES0, and to calculating nMASK based on the
other fields. But we still need the definitions in kvm_arm.h for the
polarity.

> Reviewed-by: Mark Brown <broonie at kernel.org>

Thanks!
/fuad


From tabba at google.com  Fri Dec  8 00:23:05 2023
From: tabba at google.com (Fuad Tabba)
Date: Fri, 8 Dec 2023 08:23:05 +0000
Subject: [PATCH v2 06/12] KVM: arm64: Update and fix FGT register masks
In-Reply-To: <20231207171237.GA87398@e124191.cambridge.arm.com>
References: <20231206100503.564090-1-tabba@google.com> <20231206100503.564090-7-tabba@google.com>
 <20231207150001.GA29745@e124191.cambridge.arm.com> <CA+EHjTwC+66GyPma00XQ6VRzktYzxB7XXr+7zSKFrG6U-+EeEQ@mail.gmail.com>
 <20231207171237.GA87398@e124191.cambridge.arm.com>
Message-ID: <CA+EHjTy7R6SmXwk5wGLuSpW1_Y5_VRA2==r0ix0g_Yr2rJXbbw@mail.gmail.com>

Hi Joey,

On Thu, Dec 7, 2023 at 5:12?PM Joey Gouly <joey.gouly at arm.com> wrote:
>
> On Thu, Dec 07, 2023 at 03:06:44PM +0000, Fuad Tabba wrote:
> > Hi Joey,
> >
> > On Thu, Dec 7, 2023 at 3:00?PM Joey Gouly <joey.gouly at arm.com> wrote:
> > >
> > > Hello Fuad,
> > >
> > > On Wed, Dec 06, 2023 at 10:04:56AM +0000, Fuad Tabba wrote:
> > > > New trap bits have been defined in the 2023-09 Arm Architecture
> > > > System Registers xml specification [*]. Moreover, the existing
> > > > definitions of some of the mask and the RES0 bits overlap, which
> > > > could be wrong, confusing, or both.
> > > >
> > > > Update the bits to represent the latest spec (as of this patch,
> > > > 2023-09), and ensure that the existing bits are consistent.
> > > >
> > > > Subsequent patches will use the generated RES0 fields instead of
> > > > specifying them manually. This patch keeps the manual encoding of
> > > > the bits to make it easier to review the series.
> > > >
> > > > [*] https://developer.arm.com/downloads/-/exploration-tools
> > > >
> > > > Fixes: 0fd76865006d ("KVM: arm64: Add nPIR{E0}_EL1 to HFG traps")
> > > > Signed-off-by: Fuad Tabba <tabba at google.com>
> > > > ---
> > > >  arch/arm64/include/asm/kvm_arm.h | 39 ++++++++++++++++++++------------
> > > >  1 file changed, 24 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> > > > index 7de0a7062625..b0dc3249d5cd 100644
> > > > --- a/arch/arm64/include/asm/kvm_arm.h
> > > > +++ b/arch/arm64/include/asm/kvm_arm.h
> > > > @@ -344,30 +344,39 @@
> > > >   * Once we get to a point where the two describe the same thing, we'll
> > > >   * merge the definitions. One day.
> > > >   */
> > > > -#define __HFGRTR_EL2_RES0    (GENMASK(63, 56) | GENMASK(53, 51))
> > > > +#define __HFGRTR_EL2_RES0    BIT(51)
> > > >  #define __HFGRTR_EL2_MASK    GENMASK(49, 0)
> > > > -#define __HFGRTR_EL2_nMASK   (GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> > > > +#define __HFGRTR_EL2_nMASK   (GENMASK(63, 52) | BIT(50))
> > > >
> > > > -#define __HFGWTR_EL2_RES0    (GENMASK(63, 56) | GENMASK(53, 51) |    \
> > > > -                              BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
> > > > -                              GENMASK(26, 25) | BIT(21) | BIT(18) |  \
> > > > +#define __HFGWTR_EL2_RES0    (BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
> > > > +                              BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
> > > >                                GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
> > > > -#define __HFGWTR_EL2_MASK    GENMASK(49, 0)
> > > > -#define __HFGWTR_EL2_nMASK   (GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
> > > > +#define __HFGWTR_EL2_MASK    (GENMASK(49, 47) | GENMASK(45, 43) | \
> > > > +                              BIT(41) | GENMASK(39, 29) | BIT(27) | \
> > > > +                              GENMASK(24, 22) | GENMASK(20, 19) | \
> > > > +                              GENMASK(17, 16) | GENMASK(13, 11) | \
> > > > +                              GENMASK(8, 3) | GENMASK(1, 0))
> > > > +#define __HFGWTR_EL2_nMASK   (GENMASK(63, 52) | BIT(50))
> > >
> > > By adding all these bits to *_nMASK, we're allowing a guest to access registers
> > > which KVM doesn't (currently) deal with.  For example if I apply this patch
> > > series, a guest can access S2POR_EL1, previously it would print something like:
> > >
> > >         kvm [80]: Unsupported guest sys_reg access at: ffffc42969c1f270 [600000c5]
> > >          { Op0( 3), Op1( 0), CRn(10), CRm( 2), Op2( 5), func_read },
> > >
> > > After applying this patch series, the guest can read S2POR_EL1.
> > >
> > > We don't expose S2POE to the guest through ID_AA64MMFR3_EL1, so a well behaved
> > > guest shouldn't access it, but there's nothing stopping it.
> > >
> > > My question is, is this intended? Or do we need to update the following code
> > > (and comment!) to trap all the stuff we don't currently handle (along with
> > > ACCDATA_EL1):
> >
> > Thanks for pointing this out, and no, it's not intended. For
> > consistency, I think it might be good to update the code, as you
> > suggest, to prevent these accesses. If you and the other reviewers are
> > happy with that solution I can respin with your suggested fix. I have
> > a couple of other minor fixes as well for the series.
> >
>
> Thanks for clarifying that.
>
> To me it seems weird to use the generated bits directly, and I think that's why
> the code seems confusing?
>
> I think we should stop using __HFGRTR_EL2_nMASK directly in that function, and
> build it up from '0'. This also matches, I think, with Marc Z wanting to move
> towards setting these things based on features [1], so maybe something like:
>
>         u64 r_val = 0;
>
>         if (cpus_have_final_cap(ARM64_HAS_S1PIE))
>                 r_set |= HFGxTR_EL2_nPIR_EL1 | HFGxTR_EL2_nPIREO_EL1;
>
>         r_val |= r_set;
>         r_val &= ~r_clr;
>
>         write_sysreg_s(r_val, SYS_HFGRTR_EL2);
>
> That way we just explicitly set which bits we don't want to trap on. We have
> some weird behaviour right now were we set nSMPRI_EL1 to 1, unless you have
> FEAT_SME where we set it to 0.. but if you don't have FEAT_SME it's RES0
> anyway? The above approach would fix that.

I don't have a strong opinion about that, but I am inclined to agree
with you. Let's also hear what Marc Zygier (since he's the author of
that part) opinion is, and I'm happy either way.

Cheers,
/fuad

> Thanks,
> Joey
>
> [1] https://lore.kernel.org/linux-arm-kernel/87bkb285ud.wl-maz at kernel.org/ (last paragraph)
>
> >
> > Cheers,
> > /fuad
> >
> >
> > >
> > >         static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
> > >         {
> > >
> > >                 ..
> > >
> > >                 /* The default is not to trap anything but ACCDATA_EL1 */
> > >                 r_val = __HFGRTR_EL2_nMASK & ~HFGxTR_EL2_nACCDATA_EL1;
> > >                 r_val |= r_set;
> > >                 r_val &= ~r_clr;
> > >
> > >
> > > Thanks,
> > > Joey
> > >
> > > >
> > > > -#define __HFGITR_EL2_RES0    GENMASK(63, 57)
> > > > -#define __HFGITR_EL2_MASK    GENMASK(54, 0)
> > > > -#define __HFGITR_EL2_nMASK   GENMASK(56, 55)
> > > > +#define __HFGITR_EL2_RES0    (BIT(63) | BIT(61))
> > > > +#define __HFGITR_EL2_MASK    (BIT(62) | BIT(60) | GENMASK(54, 0))
> > > > +#define __HFGITR_EL2_nMASK   GENMASK(59, 55)
> > > >
> > > >  #define __HDFGRTR_EL2_RES0   (BIT(49) | BIT(42) | GENMASK(39, 38) |  \
> > > >                                GENMASK(21, 20) | BIT(8))
> > > > -#define __HDFGRTR_EL2_MASK   ~__HDFGRTR_EL2_nMASK
> > > > +#define __HDFGRTR_EL2_MASK   (BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
> > > > +                              GENMASK(41, 40) | GENMASK(37, 22) | \
> > > > +                              GENMASK(19, 9) | GENMASK(7, 0))
> > > >  #define __HDFGRTR_EL2_nMASK  GENMASK(62, 59)
> > > >
> > > >  #define __HDFGWTR_EL2_RES0   (BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
> > > >                                BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
> > > >                                BIT(22) | BIT(9) | BIT(6))
> > > > -#define __HDFGWTR_EL2_MASK   ~__HDFGWTR_EL2_nMASK
> > > > +#define __HDFGWTR_EL2_MASK   (GENMASK(57, 52) | GENMASK(50, 48) | \
> > > > +                              GENMASK(46, 44) | GENMASK(42, 41) | \
> > > > +                              GENMASK(37, 35) | GENMASK(33, 31) | \
> > > > +                              GENMASK(29, 23) | GENMASK(21, 10) | \
> > > > +                              GENMASK(8, 7) | GENMASK(5, 0))
> > > >  #define __HDFGWTR_EL2_nMASK  GENMASK(62, 60)
> > > >
> > > >  #define __HAFGRTR_EL2_RES0   (GENMASK(63, 50) | GENMASK(16, 5))
> > > > @@ -375,9 +384,9 @@
> > > >  #define __HAFGRTR_EL2_nMASK  0UL
> > > >
> > > >  /* Similar definitions for HCRX_EL2 */
> > > > -#define __HCRX_EL2_RES0              (GENMASK(63, 16) | GENMASK(13, 12))
> > > > -#define __HCRX_EL2_MASK              (0)
> > > > -#define __HCRX_EL2_nMASK     (GENMASK(15, 14) | GENMASK(4, 0))
> > > > +#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
> > > > +#define __HCRX_EL2_MASK              (BIT(6))
> > > > +#define __HCRX_EL2_nMASK     (GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
> > > >
> > > >  /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
> > > >  #define HPFAR_MASK   (~UL(0xf))
> > > > --
> > > > 2.43.0.rc2.451.g8631bc7472-goog
> > > >
> > > >


From xu.yang_2 at nxp.com  Fri Dec  8 00:53:59 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri,  8 Dec 2023 16:53:59 +0800
Subject: [PATCH v2 1/4] dt-bindings: perf: fsl-imx-ddr: Add i.MX95 compatible
Message-ID: <20231208085402.2106904-1-xu.yang_2@nxp.com>

i.MX95 has a DDR pmu. This will add a compatible for it.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - no changes
---
 Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
index e9fad4b3de68..1bc7bf1c8368 100644
--- a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
+++ b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
@@ -20,6 +20,7 @@ properties:
           - fsl,imx8mn-ddr-pmu
           - fsl,imx8mp-ddr-pmu
           - fsl,imx93-ddr-pmu
+          - fsl,imx95-ddr-pmu
       - items:
           - enum:
               - fsl,imx8mm-ddr-pmu
-- 
2.34.1



From xu.yang_2 at nxp.com  Fri Dec  8 00:54:00 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri,  8 Dec 2023 16:54:00 +0800
Subject: [PATCH v2 2/4] perf: imx_perf: add support for i.MX95 platform
In-Reply-To: <20231208085402.2106904-1-xu.yang_2@nxp.com>
References: <20231208085402.2106904-1-xu.yang_2@nxp.com>
Message-ID: <20231208085402.2106904-2-xu.yang_2@nxp.com>

i.MX95 has a DDR PMU which is almostly same as i.MX93, it now supports
read beat and write beat filter capabilities. This will add support for
i.MX95 and enhance the driver to support specific filter handling for it.

Usage:

For read beat:
~# perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_rd_beat_filt2,counter=3,axi_mask=ID_MASK,axi_id=ID/
~# perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_rd_beat_filt1,counter=4,axi_mask=ID_MASK,axi_id=ID/
~# perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_rd_beat_filt0,counter=5,axi_mask=ID_MASK,axi_id=ID/
eg: For edma2: perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_rd_beat_filt0,counter=5,axi_mask=0x00f,axi_id=0x00c/

For write beat:
~# perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_wr_beat_filt,counter=2,axi_mask=ID_MASK,axi_id=ID/
eg: For edma2: perf stat -a -I 1000 -e imx9_ddr0/eddrtq_pm_wr_beat_filt,counter=2,axi_mask=0x00f,axi_id=0x00c/

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - put soc spefific axi filter events to drvdata according
   to franks suggestions.
 - adjust pmcfg axi_id and axi_mask config
---
 drivers/perf/fsl_imx9_ddr_perf.c | 203 +++++++++++++++++++++++++------
 1 file changed, 169 insertions(+), 34 deletions(-)

diff --git a/drivers/perf/fsl_imx9_ddr_perf.c b/drivers/perf/fsl_imx9_ddr_perf.c
index 5cf770a1bc31..261fa7d85753 100644
--- a/drivers/perf/fsl_imx9_ddr_perf.c
+++ b/drivers/perf/fsl_imx9_ddr_perf.c
@@ -11,14 +11,24 @@
 #include <linux/perf_event.h>
 
 /* Performance monitor configuration */
-#define PMCFG1  			0x00
-#define PMCFG1_RD_TRANS_FILT_EN 	BIT(31)
-#define PMCFG1_WR_TRANS_FILT_EN 	BIT(30)
-#define PMCFG1_RD_BT_FILT_EN 		BIT(29)
-#define PMCFG1_ID_MASK  		GENMASK(17, 0)
+#define PMCFG1				0x00
+#define MX93_PMCFG1_RD_TRANS_FILT_EN	BIT(31)
+#define MX93_PMCFG1_WR_TRANS_FILT_EN	BIT(30)
+#define MX93_PMCFG1_RD_BT_FILT_EN	BIT(29)
+#define MX93_PMCFG1_ID_MASK		GENMASK(17, 0)
 
-#define PMCFG2  			0x04
-#define PMCFG2_ID			GENMASK(17, 0)
+#define MX95_PMCFG1_WR_BEAT_FILT_EN	BIT(31)
+#define MX95_PMCFG1_RD_BEAT_FILT_EN	BIT(30)
+
+#define PMCFG2				0x04
+#define MX93_PMCFG2_ID			GENMASK(17, 0)
+
+#define PMCFG3				0x08
+#define PMCFG4				0x0C
+#define PMCFG5				0x10
+#define PMCFG6				0x14
+#define MX95_PMCFG_ID_MASK		GENMASK(9, 0)
+#define MX95_PMCFG_ID			GENMASK(25, 16)
 
 /* Global control register affects all counters and takes priority over local control registers */
 #define PMGC0		0x40
@@ -51,6 +61,7 @@ static DEFINE_IDA(ddr_ida);
 
 struct imx_ddr_devtype_data {
 	const char *identifier;		/* system PMU identifier for userspace */
+	struct attribute **attrs;	/* AXI filter attributes */
 };
 
 struct ddr_pmu {
@@ -67,16 +78,6 @@ struct ddr_pmu {
 	int id;
 };
 
-static const struct imx_ddr_devtype_data imx93_devtype_data = {
-	.identifier = "imx93",
-};
-
-static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
-	{.compatible = "fsl,imx93-ddr-pmu", .data = &imx93_devtype_data},
-	{ /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids);
-
 static ssize_t ddr_perf_identifier_show(struct device *dev,
 					struct device_attribute *attr,
 					char *page)
@@ -178,7 +179,6 @@ static struct attribute *ddr_perf_events_attrs[] = {
 	IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_6, 70),
 	IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_7, 71),
 	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_empty, 72),
-	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_trans_filt, 73),
 
 	/* counter3 specific events */
 	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_0, 64),
@@ -190,7 +190,6 @@ static struct attribute *ddr_perf_events_attrs[] = {
 	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_6, 70),
 	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_7, 71),
 	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_full, 72),
-	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_trans_filt, 73),
 
 	/* counter4 specific events */
 	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_0, 64),
@@ -202,7 +201,6 @@ static struct attribute *ddr_perf_events_attrs[] = {
 	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_6, 70),
 	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_7, 71),
 	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq2_rmw, 72),
-	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt, 73),
 
 	/* counter5 specific events */
 	IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_0, 64),
@@ -242,6 +240,28 @@ static const struct attribute_group ddr_perf_events_attr_group = {
 	.attrs = ddr_perf_events_attrs,
 };
 
+static struct attribute *imx93_ddr_perf_events_attrs[] = {
+	/* counter2 specific events */
+	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_trans_filt, 73),
+	/* counter3 specific events */
+	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_trans_filt, 73),
+	/* counter4 specific events */
+	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt, 73),
+	NULL,
+};
+
+static struct attribute *imx95_ddr_perf_events_attrs[] = {
+	/* counter2 specific events */
+	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_beat_filt, 73),
+	/* counter3 specific events */
+	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt2, 73),
+	/* counter4 specific events */
+	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt1, 73),
+	/* counter5 specific events */
+	IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt0, 73),
+	NULL,
+};
+
 PMU_FORMAT_ATTR(event, "config:0-7");
 PMU_FORMAT_ATTR(counter, "config:8-15");
 PMU_FORMAT_ATTR(axi_id, "config1:0-17");
@@ -268,6 +288,28 @@ static const struct attribute_group *attr_groups[] = {
 	NULL,
 };
 
+static const struct imx_ddr_devtype_data imx93_devtype_data = {
+	.identifier = "imx93",
+	.attrs = imx93_ddr_perf_events_attrs,
+};
+
+static const struct imx_ddr_devtype_data imx95_devtype_data = {
+	.identifier = "imx95",
+	.attrs = imx95_ddr_perf_events_attrs,
+};
+
+static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
+	{ .compatible = "fsl,imx93-ddr-pmu", .data = &imx93_devtype_data },
+	{ .compatible = "fsl,imx95-ddr-pmu", .data = &imx95_devtype_data },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids);
+
+static inline bool is_imx93(struct ddr_pmu *pmu)
+{
+	return pmu->devtype_data == &imx93_devtype_data;
+}
+
 static void ddr_perf_clear_counter(struct ddr_pmu *pmu, int counter)
 {
 	if (counter == CYCLES_COUNTER) {
@@ -361,7 +403,7 @@ static void ddr_perf_counter_local_config(struct ddr_pmu *pmu, int config,
 	}
 }
 
-static void ddr_perf_monitor_config(struct ddr_pmu *pmu, int cfg, int cfg1, int cfg2)
+static void imx93_ddr_perf_monitor_config(struct ddr_pmu *pmu, int cfg, int cfg1, int cfg2)
 {
 	u32 pmcfg1, pmcfg2;
 	int event, counter;
@@ -372,30 +414,80 @@ static void ddr_perf_monitor_config(struct ddr_pmu *pmu, int cfg, int cfg1, int
 	pmcfg1 = readl_relaxed(pmu->base + PMCFG1);
 
 	if (counter == 2 && event == 73)
-		pmcfg1 |= PMCFG1_RD_TRANS_FILT_EN;
+		pmcfg1 |= MX93_PMCFG1_RD_TRANS_FILT_EN;
 	else if (counter == 2 && event != 73)
-		pmcfg1 &= ~PMCFG1_RD_TRANS_FILT_EN;
+		pmcfg1 &= ~MX93_PMCFG1_RD_TRANS_FILT_EN;
 
 	if (counter == 3 && event == 73)
-		pmcfg1 |= PMCFG1_WR_TRANS_FILT_EN;
+		pmcfg1 |= MX93_PMCFG1_WR_TRANS_FILT_EN;
 	else if (counter == 3 && event != 73)
-		pmcfg1 &= ~PMCFG1_WR_TRANS_FILT_EN;
+		pmcfg1 &= ~MX93_PMCFG1_WR_TRANS_FILT_EN;
 
 	if (counter == 4 && event == 73)
-		pmcfg1 |= PMCFG1_RD_BT_FILT_EN;
+		pmcfg1 |= MX93_PMCFG1_RD_BT_FILT_EN;
 	else if (counter == 4 && event != 73)
-		pmcfg1 &= ~PMCFG1_RD_BT_FILT_EN;
+		pmcfg1 &= ~MX93_PMCFG1_RD_BT_FILT_EN;
 
-	pmcfg1 &= ~FIELD_PREP(PMCFG1_ID_MASK, 0x3FFFF);
-	pmcfg1 |= FIELD_PREP(PMCFG1_ID_MASK, cfg2);
+	pmcfg1 &= ~FIELD_PREP(MX93_PMCFG1_ID_MASK, 0x3FFFF);
+	pmcfg1 |= FIELD_PREP(MX93_PMCFG1_ID_MASK, cfg2);
 	writel(pmcfg1, pmu->base + PMCFG1);
 
 	pmcfg2 = readl_relaxed(pmu->base + PMCFG2);
-	pmcfg2 &= ~FIELD_PREP(PMCFG2_ID, 0x3FFFF);
-	pmcfg2 |= FIELD_PREP(PMCFG2_ID, cfg1);
+	pmcfg2 &= ~FIELD_PREP(MX93_PMCFG2_ID, 0x3FFFF);
+	pmcfg2 |= FIELD_PREP(MX93_PMCFG2_ID, cfg1);
 	writel(pmcfg2, pmu->base + PMCFG2);
 }
 
+static void imx95_ddr_perf_monitor_config(struct ddr_pmu *pmu, int cfg, int cfg1, int cfg2)
+{
+	u32 pmcfg1, pmcfg, offset = 0;
+	int event, counter;
+
+	event = cfg & 0x000000FF;
+	counter = (cfg & 0x0000FF00) >> 8;
+
+	pmcfg1 = readl_relaxed(pmu->base + PMCFG1);
+
+	if (counter == 2 && event == 73) {
+		pmcfg1 |= MX95_PMCFG1_WR_BEAT_FILT_EN;
+		offset = PMCFG3;
+	} else if (counter == 2 && event != 73) {
+		pmcfg1 &= ~MX95_PMCFG1_WR_BEAT_FILT_EN;
+	}
+
+	if (counter == 3 && event == 73) {
+		pmcfg1 |= MX95_PMCFG1_RD_BEAT_FILT_EN;
+		offset = PMCFG4;
+	} else if (counter == 3 && event != 73) {
+		pmcfg1 &= ~MX95_PMCFG1_RD_BEAT_FILT_EN;
+	}
+
+	if (counter == 4 && event == 73) {
+		pmcfg1 |= MX95_PMCFG1_RD_BEAT_FILT_EN;
+		offset = PMCFG5;
+	} else if (counter == 4 && event != 73) {
+		pmcfg1 &= ~MX95_PMCFG1_RD_BEAT_FILT_EN;
+	}
+
+	if (counter == 5 && event == 73) {
+		pmcfg1 |= MX95_PMCFG1_RD_BEAT_FILT_EN;
+		offset = PMCFG6;
+	} else if (counter == 5 && event != 73) {
+		pmcfg1 &= ~MX95_PMCFG1_RD_BEAT_FILT_EN;
+	}
+
+	writel(pmcfg1, pmu->base + PMCFG1);
+
+	if (offset) {
+		pmcfg = readl_relaxed(pmu->base + offset);
+		pmcfg &= ~(FIELD_PREP(MX95_PMCFG_ID_MASK, 0x3FF) |
+				FIELD_PREP(MX95_PMCFG_ID, 0x3FF));
+		pmcfg |= (FIELD_PREP(MX95_PMCFG_ID_MASK, cfg2) |
+				FIELD_PREP(MX95_PMCFG_ID, cfg1));
+		writel(pmcfg, pmu->base + offset);
+	}
+}
+
 static void ddr_perf_event_update(struct perf_event *event)
 {
 	struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
@@ -476,12 +568,16 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
 	hwc->idx = counter;
 	hwc->state |= PERF_HES_STOPPED;
 
+	if (is_imx93(pmu))
+		/* read trans, write trans, read beat */
+		imx93_ddr_perf_monitor_config(pmu, cfg, cfg1, cfg2);
+	else
+		/* write beat, read beat2, read beat1, read beat */
+		imx95_ddr_perf_monitor_config(pmu, cfg, cfg1, cfg2);
+
 	if (flags & PERF_EF_START)
 		ddr_perf_event_start(event, flags);
 
-	/* read trans, write trans, read beat */
-	ddr_perf_monitor_config(pmu, cfg, cfg1, cfg2);
-
 	return 0;
 }
 
@@ -596,6 +692,39 @@ static int ddr_perf_offline_cpu(unsigned int cpu, struct hlist_node *node)
 	return 0;
 }
 
+static int ddr_perf_add_events(struct ddr_pmu *pmu)
+{
+	int i, ret;
+	struct attribute **attrs = pmu->devtype_data->attrs;
+	struct device *pmu_dev = pmu->pmu.dev;
+
+	if (!attrs)
+		return 0;
+
+	for (i = 0; attrs[i]; i++) {
+		ret = sysfs_add_file_to_group(&pmu_dev->kobj, attrs[i], "events");
+		if (ret) {
+			dev_warn(pmu->dev, "i.MX9 DDR Perf add events failed (%d)\n", ret);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static void ddr_perf_remove_events(struct ddr_pmu *pmu)
+{
+	int i;
+	struct attribute **attrs = pmu->devtype_data->attrs;
+	struct device *pmu_dev = pmu->pmu.dev;
+
+	if (!attrs)
+		return;
+
+	for (i = 0; attrs[i]; i++)
+		sysfs_remove_file_from_group(&pmu_dev->kobj, attrs[i], "events");
+}
+
 static int ddr_perf_probe(struct platform_device *pdev)
 {
 	struct ddr_pmu *pmu;
@@ -666,6 +795,10 @@ static int ddr_perf_probe(struct platform_device *pdev)
 	if (ret)
 		goto ddr_perf_err;
 
+	ret = ddr_perf_add_events(pmu);
+	if (ret)
+		dev_warn(&pdev->dev, "i.MX9 DDR Perf filter events are missing\n");
+
 	return 0;
 
 ddr_perf_err:
@@ -683,6 +816,8 @@ static int ddr_perf_remove(struct platform_device *pdev)
 {
 	struct ddr_pmu *pmu = platform_get_drvdata(pdev);
 
+	ddr_perf_remove_events(pmu);
+
 	cpuhp_state_remove_instance_nocalls(pmu->cpuhp_state, &pmu->node);
 	cpuhp_remove_multi_state(pmu->cpuhp_state);
 
-- 
2.34.1



From xu.yang_2 at nxp.com  Fri Dec  8 00:54:01 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri,  8 Dec 2023 16:54:01 +0800
Subject: [PATCH v2 3/4] perf: imx_perf: limit counter ID from user space and optimize counter usage
In-Reply-To: <20231208085402.2106904-1-xu.yang_2@nxp.com>
References: <20231208085402.2106904-1-xu.yang_2@nxp.com>
Message-ID: <20231208085402.2106904-3-xu.yang_2@nxp.com>

The user can pass any counter ID to perf app. However, current pmu driver
doesn't judge the validity of the counter ID. This will add necessary
check for counter ID from user space. Besides, this pmu has 10 counters
except cycle counter which can be used to count reference events and
counter specific evnets. This will also add supports to auto allocate
counter if the user doesn't pass it the perf. Then, the usage of counter
will be optimized.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - limit counter ID from user to 0-10
 - combine dynamic and static allocation of counter
---
 drivers/perf/fsl_imx9_ddr_perf.c | 69 +++++++++++++++++++++++++++++++-
 1 file changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/perf/fsl_imx9_ddr_perf.c b/drivers/perf/fsl_imx9_ddr_perf.c
index 261fa7d85753..1a4fe247006b 100644
--- a/drivers/perf/fsl_imx9_ddr_perf.c
+++ b/drivers/perf/fsl_imx9_ddr_perf.c
@@ -51,6 +51,7 @@
 
 #define NUM_COUNTERS		11
 #define CYCLES_COUNTER		0
+#define CYCLES_EVENT_ID		0
 
 #define to_ddr_pmu(p)		container_of(p, struct ddr_pmu, pmu)
 
@@ -235,6 +236,14 @@ static struct attribute *ddr_perf_events_attrs[] = {
 	NULL,
 };
 
+static bool ddr_perf_is_specific_event(int event)
+{
+	if (event >= 64 && event <= 73)
+		return true;
+	else
+		return false;
+}
+
 static const struct attribute_group ddr_perf_events_attr_group = {
 	.name = "events",
 	.attrs = ddr_perf_events_attrs,
@@ -507,6 +516,7 @@ static int ddr_perf_event_init(struct perf_event *event)
 	struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
 	struct perf_event *sibling;
+	int event_id, counter;
 
 	if (event->attr.type != event->pmu->type)
 		return -ENOENT;
@@ -519,6 +529,18 @@ static int ddr_perf_event_init(struct perf_event *event)
 		return -EOPNOTSUPP;
 	}
 
+	counter = (event->attr.config & 0xFF00) >> 8;
+	if (counter > NUM_COUNTERS) {
+		dev_warn(pmu->dev, "Only counter 0-10 is supported!\n");
+		return -EINVAL;
+	}
+
+	event_id = event->attr.config & 0x00FF;
+	if (ddr_perf_is_specific_event(event_id) && counter == 0) {
+		dev_err(pmu->dev, "Need specify counter for counter specific events!\n");
+		return -EINVAL;
+	}
+
 	/*
 	 * We must NOT create groups containing mixed PMUs, although software
 	 * events are acceptable (for example to create a CCN group
@@ -552,6 +574,39 @@ static void ddr_perf_event_start(struct perf_event *event, int flags)
 	hwc->state = 0;
 }
 
+static int ddr_perf_alloc_counter(struct ddr_pmu *pmu, int event, int counter)
+{
+	int i;
+
+	if (event == CYCLES_EVENT_ID) {
+		/*
+		 * Always map cycle event to counter 0.
+		 * Cycles counter is dedicated for cycle event
+		 * can't used for the other events.
+		 */
+		if (pmu->events[CYCLES_COUNTER] == NULL)
+			return CYCLES_COUNTER;
+	} else if (counter != 0) {
+		/*
+		 * 1. ddr_perf_event_init() will make sure counter
+		 *    is not 0 for counter specific events.
+		 * 2. Allow specify counter for referene event too.
+		 */
+		if (pmu->events[counter] == NULL)
+			return counter;
+	} else {
+		/*
+		 * Counter may be 0 if user doesn't specify it.
+		 * Auto allocate counter for referene event.
+		 */
+		for (i = 1; i < NUM_COUNTERS; i++)
+			if (pmu->events[i] == NULL)
+				return i;
+	}
+
+	return -ENOENT;
+}
+
 static int ddr_perf_event_add(struct perf_event *event, int flags)
 {
 	struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
@@ -559,9 +614,17 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
 	int cfg = event->attr.config;
 	int cfg1 = event->attr.config1;
 	int cfg2 = event->attr.config2;
-	int counter;
+	int event_id, counter;
 
-	counter = (cfg & 0x0000FF00) >> 8;
+	event_id = cfg & 0x00FF;
+	counter = (cfg & 0xFF00) >> 8;
+
+	/* check if counter is available */
+	counter = ddr_perf_alloc_counter(pmu, event_id, counter);
+	if (counter < 0) {
+		dev_dbg(pmu->dev, "There are not enough counters\n");
+		return -EOPNOTSUPP;
+	}
 
 	pmu->events[counter] = event;
 	pmu->active_events++;
@@ -597,9 +660,11 @@ static void ddr_perf_event_del(struct perf_event *event, int flags)
 {
 	struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
+	int counter = hwc->idx;
 
 	ddr_perf_event_stop(event, PERF_EF_UPDATE);
 
+	pmu->events[counter] = NULL;
 	pmu->active_events--;
 	hwc->idx = -1;
 }
-- 
2.34.1



From xu.yang_2 at nxp.com  Fri Dec  8 00:54:02 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri,  8 Dec 2023 16:54:02 +0800
Subject: [PATCH v2 4/4] perf vendor events arm64:: Add i.MX95 DDR Performane Monitor metrics
In-Reply-To: <20231208085402.2106904-1-xu.yang_2@nxp.com>
References: <20231208085402.2106904-1-xu.yang_2@nxp.com>
Message-ID: <20231208085402.2106904-4-xu.yang_2@nxp.com>

Add JSON metrics for i.MX95 DDR Performane Monitor.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - fix wrong AXI_MASK setting
 - remove unnecessary metrics
 - add bandwidth_usage, camera_all, disp_all metrics
---
 .../arch/arm64/freescale/imx95/sys/ddrc.json  |   9 +
 .../arm64/freescale/imx95/sys/metrics.json    | 778 ++++++++++++++++++
 tools/perf/pmu-events/jevents.py              |   1 +
 3 files changed, 788 insertions(+)
 create mode 100644 tools/perf/pmu-events/arch/arm64/freescale/imx95/sys/ddrc.json
 create mode 100644 tools/perf/pmu-events/arch/arm64/freescale/imx95/sys/metrics.json

diff --git a/tools/perf/pmu-events/arch/arm64/freescale/imx95/sys/ddrc.json b/tools/perf/pmu-events/arch/arm64/freescale/imx95/sys/ddrc.json
new file mode 100644
index 000000000000..4dc9d2968bdc
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/freescale/imx95/sys/ddrc.json
@@ -0,0 +1,9 @@
+[
+   {
+           "BriefDescription": "ddr cycles event",
+           "EventCode": "0x00",
+           "EventName": "imx95_ddr.cycles",
+           "Unit": "imx9_ddr",
+           "Compat": "imx95"
+   }
+]
diff --git a/tools/perf/pmu-events/arch/arm64/freescale/imx95/sys/metrics.json b/tools/perf/pmu-events/arch/arm64/freescale/imx95/sys/metrics.json
new file mode 100644
index 000000000000..2bfcd4d574a8
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/freescale/imx95/sys/metrics.json
@@ -0,0 +1,778 @@
+[
+	{
+		"BriefDescription": "bandwidth usage for lpddr5 evk board",
+		"MetricName": "imx95_bandwidth_usage.lpddr5",
+		"MetricExpr": "(( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x000\\,axi_id\\=0x000@ + imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x000\\,axi_id\\=0x000@ ) * 32 / duration_time) / (6400 * 1000000 * 4)",
+		"ScaleUnit": "1e2%",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all masters read from ddr",
+		"MetricName": "imx95_ddr_read.all",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x000\\,axi_id\\=0x000@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all masters write to ddr",
+		"MetricName": "imx95_ddr_write.all",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x000\\,axi_id\\=0x000@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all a55 read from ddr",
+		"MetricName": "imx95_ddr_read.a55_all",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3fc\\,axi_id\\=0x000@ + imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3fe\\,axi_id\\=0x004@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all a55 write to ddr (part1)",
+		"MetricName": "imx95_ddr_write.a55_all_1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3fc\\,axi_id\\=0x000@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all a55 write to ddr (part2)",
+		"MetricName": "imx95_ddr_write.a55_all_2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3fe\\,axi_id\\=0x004@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 0 read from ddr",
+		"MetricName": "imx95_ddr_read.a55_0",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3ff\\,axi_id\\=0x000@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 0 write to ddr",
+		"MetricName": "imx95_ddr_write.a55_0",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3ff\\,axi_id\\=0x000@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 1 read from ddr",
+		"MetricName": "imx95_ddr_read.a55_1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x00f\\,axi_id\\=0x001@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 1 write to ddr",
+		"MetricName": "imx95_ddr_write.a55_1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x001@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 2 read from ddr",
+		"MetricName": "imx95_ddr_read.a55_2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x00f\\,axi_id\\=0x002@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 2 write to ddr",
+		"MetricName": "imx95_ddr_write.a55_2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x002@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 3 read from ddr",
+		"MetricName": "imx95_ddr_read.a55_3",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x00f\\,axi_id\\=0x003@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 3 write to ddr",
+		"MetricName": "imx95_ddr_write.a55_3",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x003@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 4 read from ddr",
+		"MetricName": "imx95_ddr_read.a55_4",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x00f\\,axi_id\\=0x004@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 4 write to ddr",
+		"MetricName": "imx95_ddr_write.a55_4",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x004@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 5 read from ddr",
+		"MetricName": "imx95_ddr_read.a55_5",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x00f\\,axi_id\\=0x005@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of a55 core 5 write to ddr",
+		"MetricName": "imx95_ddr_write.a55_5",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x005@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of Cortex-A DSU L3 evicted/ACP transactions read from ddr",
+		"MetricName": "imx95_ddr_read.cortexa_dsu_l3",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x00f\\,axi_id\\=0x007@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of Cortex-A DSU L3 evicted/ACP transactions write to ddr",
+		"MetricName": "imx95_ddr_write.cortexa_dsu_l3",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x007@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of m33 read from ddr",
+		"MetricName": "imx95_ddr_read.m33",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x00f\\,axi_id\\=0x008@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of m33 write to ddr",
+		"MetricName": "imx95_ddr_write.m33",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x008@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of m7 read from ddr",
+		"MetricName": "imx95_ddr_read.m7",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x00f\\,axi_id\\=0x009@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of m7 write to ddr",
+		"MetricName": "imx95_ddr_write.m7",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x009@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of sentinel read from ddr",
+		"MetricName": "imx95_ddr_read.sentinel",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x00f\\,axi_id\\=0x00a@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of sentinel write to ddr",
+		"MetricName": "imx95_ddr_write.sentinel",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x00a@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of edma1 read from ddr",
+		"MetricName": "imx95_ddr_read.edma1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x00f\\,axi_id\\=0x00b@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of edma1 write to ddr",
+		"MetricName": "imx95_ddr_write.edma1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x00b@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of edma2 read from ddr",
+		"MetricName": "imx95_ddr_read.edma2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x00f\\,axi_id\\=0x00c@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of edma2 write to ddr",
+		"MetricName": "imx95_ddr_write.edma2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x00c@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of netc read from ddr",
+		"MetricName": "imx95_ddr_read.netc",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x00f\\,axi_id\\=0x00d@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of netc write to ddr",
+		"MetricName": "imx95_ddr_write.netc",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x00d@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of npu read from ddr",
+		"MetricName": "imx95_ddr_read.npu",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x010@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of npu write to ddr",
+		"MetricName": "imx95_ddr_write.npu",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x010@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of gpu read from ddr",
+		"MetricName": "imx95_ddr_read.gpu",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3f0\\,axi_id\\=0x020@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of gpu write to ddr",
+		"MetricName": "imx95_ddr_write.gpu",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x020@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usdhc1 read from ddr",
+		"MetricName": "imx95_ddr_read.usdhc1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x0b0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usdhc1 write to ddr",
+		"MetricName": "imx95_ddr_write.usdhc1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x0b0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usdhc2 read from ddr",
+		"MetricName": "imx95_ddr_read.usdhc2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x0c0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usdhc2 write to ddr",
+		"MetricName": "imx95_ddr_write.usdhc2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x0c0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usdhc3 read from ddr",
+		"MetricName": "imx95_ddr_read.usdhc3",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3f0\\,axi_id\\=0x0d0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usdhc3 write to ddr",
+		"MetricName": "imx95_ddr_write.usdhc3",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x0d0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of xspi read from ddr",
+		"MetricName": "imx95_ddr_read.xspi",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x0f0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of xspi write to ddr",
+		"MetricName": "imx95_ddr_write.xspi",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x0f0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of pcie1 read from ddr",
+		"MetricName": "imx95_ddr_read.pcie1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x100@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of pcie1 write to ddr",
+		"MetricName": "imx95_ddr_write.pcie1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x100@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of pcie2 read from ddr",
+		"MetricName": "imx95_ddr_read.pcie2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x00f\\,axi_id\\=0x006@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of pcie2 write to ddr",
+		"MetricName": "imx95_ddr_write.pcie2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x00f\\,axi_id\\=0x006@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of pcie3 read from ddr",
+		"MetricName": "imx95_ddr_read.pcie3",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x120@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of pcie3 write to ddr",
+		"MetricName": "imx95_ddr_write.pcie3",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x120@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of pcie4 read from ddr",
+		"MetricName": "imx95_ddr_read.pcie4",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x130@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of pcie4 write to ddr",
+		"MetricName": "imx95_ddr_write.pcie4",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x130@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usb1 read from ddr",
+		"MetricName": "imx95_ddr_read.usb1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3f0\\,axi_id\\=0x140@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usb1 write to ddr",
+		"MetricName": "imx95_ddr_write.usb1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x140@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usb2 read from ddr",
+		"MetricName": "imx95_ddr_read.usb2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x150@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of usb2 write to ddr",
+		"MetricName": "imx95_ddr_write.usb2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x150@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of vpu codec primary bus read from ddr",
+		"MetricName": "imx95_ddr_read.vpu_primy",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x180@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of vpu codec primary bus write to ddr",
+		"MetricName": "imx95_ddr_write.vpu_primy",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x180@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of vpu codec secondary bus read from ddr",
+		"MetricName": "imx95_ddr_read.vpu_secndy",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3f0\\,axi_id\\=0x190@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of vpu codec secondary bus write to ddr",
+		"MetricName": "imx95_ddr_write.vpu_secndy",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x190@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of jpeg decoder read from ddr",
+		"MetricName": "imx95_ddr_read.jpeg_dec",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x1a0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of jpeg decoder write to ddr",
+		"MetricName": "imx95_ddr_write.jpeg_dec",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x1a0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of jpeg encoder read from ddr",
+		"MetricName": "imx95_ddr_read.jpeg_dec",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x1b0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of jpeg encoder write to ddr",
+		"MetricName": "imx95_ddr_write.jpeg_enc",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x1b0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all vpu submodules read from ddr",
+		"MetricName": "imx95_ddr_read.vpu_all",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x380\\,axi_id\\=0x180@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all vpu submodules write to ddr",
+		"MetricName": "imx95_ddr_write.vpu_all",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x380\\,axi_id\\=0x180@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of cortex m0+ read from ddr",
+		"MetricName": "imx95_ddr_read.m0",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x200@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of cortex m0+ write to ddr",
+		"MetricName": "imx95_ddr_write.m0",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x200@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of camera edma read from ddr",
+		"MetricName": "imx95_ddr_read.camera_edma",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x210@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of camera edma write to ddr",
+		"MetricName": "imx95_ddr_write.camera_edma",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x210@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isi rd read from ddr",
+		"MetricName": "imx95_ddr_read.isi_rd",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3f0\\,axi_id\\=0x220@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isi rd write to ddr",
+		"MetricName": "imx95_ddr_write.isi_rd",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x220@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isi wr y read from ddr",
+		"MetricName": "imx95_ddr_read.isi_wr_y",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x230@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isi wr y write to ddr",
+		"MetricName": "imx95_ddr_write.isi_wr_y",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x230@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isi wr u read from ddr",
+		"MetricName": "imx95_ddr_read.isi_wr_u",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x240@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isi wr u write to ddr",
+		"MetricName": "imx95_ddr_write.isi_wr_u",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x240@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isi wr v read from ddr",
+		"MetricName": "imx95_ddr_read.isi_wr_v",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3f0\\,axi_id\\=0x250@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isi wr v write to ddr",
+		"MetricName": "imx95_ddr_write.isi_wr_v",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x250@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isp input dma1 read from ddr",
+		"MetricName": "imx95_ddr_read.isp_in_dma1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x260@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isp input dma1 write to ddr",
+		"MetricName": "imx95_ddr_write.isp_in_dma1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x260@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isp input dma2 read from ddr",
+		"MetricName": "imx95_ddr_read.isp_in_dma2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x270@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isp input dma2 write to ddr",
+		"MetricName": "imx95_ddr_write.isp_in_dma2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x270@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isp output dma1 read from ddr",
+		"MetricName": "imx95_ddr_read.isp_out_dma1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3f0\\,axi_id\\=0x280@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isp output dma1 write to ddr",
+		"MetricName": "imx95_ddr_write.isp_out_dma1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x280@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isp output dma2 read from ddr",
+		"MetricName": "imx95_ddr_read.isp_out_dma2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x290@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of isp output dma2 write to ddr",
+		"MetricName": "imx95_ddr_write.isp_out_dma2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x290@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all camera submodules read from ddr",
+		"MetricName": "imx95_ddr_read.camera_all",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x380\\,axi_id\\=0x200@ + imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3f0\\,axi_id\\=0x280@ + imx9_ddr0 at eddrtq_pm_rd_beat_filt2\\,counter\\=3\\,axi_mask\\=0x3f0\\,axi_id\\=0x290@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all camera submodules write to ddr (part1)",
+		"MetricName": "imx95_ddr_write.camera_all_1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x380\\,axi_id\\=0x200@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all camera submodules write to ddr (part2)",
+		"MetricName": "imx95_ddr_write.camera_all_2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x280@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all camera submodules write to ddr (part3)",
+		"MetricName": "imx95_ddr_write.camera_all_3",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x290@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of display blitter store read from ddr",
+		"MetricName": "imx95_ddr_read.disp_blit",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x3f0\\,axi_id\\=0x2a0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of display blitter write to ddr",
+		"MetricName": "imx95_ddr_write.disp_blit",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x2a0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of display command sequencer read from ddr",
+		"MetricName": "imx95_ddr_read.disp_cmd",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3f0\\,axi_id\\=0x2b0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of display command sequencer write to ddr",
+		"MetricName": "imx95_ddr_write.disp_cmd",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3f0\\,axi_id\\=0x2b0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all display submodules read from ddr",
+		"MetricName": "imx95_ddr_read.disp_all",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_rd_beat_filt0\\,counter\\=5\\,axi_mask\\=0x300\\,axi_id\\=0x300@ + imx9_ddr0 at eddrtq_pm_rd_beat_filt1\\,counter\\=4\\,axi_mask\\=0x3a0\\,axi_id\\=0x2a0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all display submodules write to ddr (part1)",
+		"MetricName": "imx95_ddr_write.disp_all_1",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x300\\,axi_id\\=0x300@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	},
+	{
+		"BriefDescription": "bytes of all display submodules write to ddr (part2)",
+		"MetricName": "imx95_ddr_write.disp_all_2",
+		"MetricExpr": "( imx9_ddr0 at eddrtq_pm_wr_beat_filt\\,counter\\=2\\,axi_mask\\=0x3a0\\,axi_id\\=0x2a0@ ) * 32",
+		"ScaleUnit": "9.765625e-4KB",
+		"Unit": "imx9_ddr",
+		"Compat": "imx95"
+	}
+]
diff --git a/tools/perf/pmu-events/jevents.py b/tools/perf/pmu-events/jevents.py
index 3c091ab75305..89652b32fdec 100755
--- a/tools/perf/pmu-events/jevents.py
+++ b/tools/perf/pmu-events/jevents.py
@@ -284,6 +284,7 @@ class JsonEvent:
           'hisi_sccl,hha': 'hisi_sccl,hha',
           'hisi_sccl,l3c': 'hisi_sccl,l3c',
           'imx8_ddr': 'imx8_ddr',
+          'imx9_ddr': 'imx9_ddr',
           'L3PMC': 'amd_l3',
           'DFPMC': 'amd_df',
           'cpu_core': 'cpu_core',
-- 
2.34.1



From jensenhuang at friendlyarm.com  Fri Dec  8 00:53:47 2023
From: jensenhuang at friendlyarm.com (Jensen Huang)
Date: Fri, 8 Dec 2023 16:53:47 +0800
Subject: [PATCH v2] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <95cc7716-ba01-e239-e7c0-eba0b7da7955@collabora.com>
References: <20231207082200.16388-1-jensenhuang@friendlyarm.com>
 <ebf6cf8ec3b5befd673d295061fa2738@manjaro.org> <CAMpZ1qHUnTDQ78gdrQF9Sx_-XfLM-B+H-0bL1-+twKsno+JOvg@mail.gmail.com>
 <5e11553952c02ad20591992be4284bbd@manjaro.org> <95cc7716-ba01-e239-e7c0-eba0b7da7955@collabora.com>
Message-ID: <CAMpZ1qENxWsDnvke4jMvK9tYpta3dThHUHxjDWO-u2JV+8dZdQ@mail.gmail.com>

On Fri, Dec 8, 2023 at 12:00?AM Dmitry Osipenko
<dmitry.osipenko at collabora.com> wrote:
>
> On 12/7/23 17:10, Dragan Simic wrote:
> > On 2023-12-07 10:25, Jensen Huang wrote:
> >> On Thu, Dec 7, 2023 at 4:37?PM Dragan Simic <dsimic at manjaro.org> wrote:
> >>>
> >>> On 2023-12-07 09:21, Jensen Huang wrote:
> >>> > Possible deadlock scenario (on reboot):
> >>> > rk3x_i2c_xfer_common(polling)
> >>> >     -> rk3x_i2c_wait_xfer_poll()
> >>> >         -> rk3x_i2c_irq(0, i2c);
> >>> >             --> spin_lock(&i2c->lock);
> >>> >             ...
> >>> >         <rk3x i2c interrupt>
> >>> >         -> rk3x_i2c_irq(0, i2c);
> >>> >             --> spin_lock(&i2c->lock); (deadlock here)
> >>> >
> >>> > Store the IRQ number and disable/enable it around the polling
> >>> transfer.
> >>> > This patch has been tested on NanoPC-T4.
> >>>
> >>> In case you haven't already seen the related discussion linked below,
> >>> please have a look.  I also added more people to the list of recipients,
> >>> in an attempt to make everyone aware of the different approaches to
> >>> solving this issue.
> >>>
> >>> https://lore.kernel.org/all/655177f4.050a0220.d85c9.3ba0 at mx.google.com/T/#m6fc9c214452fec6681843e7f455978c35c6f6c8b
> >>
> >> Thank you for providing the information. I hadn't seen this link before.
> >> After carefully looking into the related discussion, it appears that
> >> Dmitry Osipenko is already working on a suitable patch. To avoid
> >> duplication
> >> or conflicts, my patch can be discarded.
> >
> > Thank you for responding so quickly.  Perhaps it would be best to hear
> > from Dmitry as well, before discarding anything.  It's been a while
> > since Dmitry wrote about working on the patch, so he might have
> > abandoned it.
>
> This patch is okay. In general, will be better to have IRQ disabled by
> default like I did in my variant, it should allow to remove the spinlock
> entirely. Of course this also can be done later on in a follow up
> patches. Jensen, feel free to use my variant of the patch, add my
> s-o-b+co-developed tags to the commit msg if you'll do. Otherwise I'll
> be able to send my patch next week.

Thank you for the suggestion. I've updated the patch to your variant, and
as confirmed by others, reboots are functioning correctly. I measured the
overhead of enable_irq/disable_irq() by calculating ktime in the
updated version,
and on rk3399, the minimum delta I observed was 291/875 ns. This extra
cost may impact most interrupt-based transfers. Therefore, I personally lean
towards the current v2 patch and handle the spinlock and irqsave/restore in
a follow up patch. I'd like to hear everyone's thoughts on this.

--
Best regards,
Jensen


From sherry.sun at nxp.com  Fri Dec  8 01:13:53 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Fri,  8 Dec 2023 17:13:53 +0800
Subject: [PATCH 2/4] dt-bindings: imx6q-pcie: Add host-wake-gpio property
In-Reply-To: <20231208091355.1417292-1-sherry.sun@nxp.com>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
Message-ID: <20231208091355.1417292-3-sherry.sun@nxp.com>

Add host-wake-gpio property that can be used to wakeup the host
processor.

Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
---
 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 81bbb8728f0f..944f0f961809 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -72,6 +72,10 @@ properties:
       L=operation state) (optional required).
     type: boolean
 
+  host-wake-gpio:
+    description: Should specify the GPIO for controlling the PCI bus device
+      wake signal, used to wakeup the host processor. Default to active-low.
+
 required:
   - compatible
   - reg
-- 
2.34.1



From sherry.sun at nxp.com  Fri Dec  8 01:13:54 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Fri,  8 Dec 2023 17:13:54 +0800
Subject: [PATCH 3/4] arm64: dts: imx8mp-evk: add host-wake-gpio property for pci bus
In-Reply-To: <20231208091355.1417292-1-sherry.sun@nxp.com>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
Message-ID: <20231208091355.1417292-4-sherry.sun@nxp.com>

The host wake pin is a standard feature in the PCIe bus specification,
so we add this property under PCI dts node to enable the host wake
function.

Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
index f87fa5a948cc..cc9e5e599a33 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -542,6 +542,7 @@ &pcie {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_pcie0>;
 	reset-gpio = <&gpio2 7 GPIO_ACTIVE_LOW>;
+	host-wake-gpio = <&gpio5 21 GPIO_ACTIVE_LOW>;
 	vpcie-supply = <&reg_pcie0>;
 	status = "okay";
 };
@@ -772,6 +773,7 @@ pinctrl_pcie0: pcie0grp {
 		fsl,pins = <
 			MX8MP_IOMUXC_I2C4_SCL__PCIE_CLKREQ_B	0x60 /* open drain, pull up */
 			MX8MP_IOMUXC_SD1_DATA5__GPIO2_IO07	0x40
+			MX8MP_IOMUXC_I2C4_SDA__GPIO5_IO21	0x1c4
 		>;
 	};
 
-- 
2.34.1



From sherry.sun at nxp.com  Fri Dec  8 01:13:55 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Fri,  8 Dec 2023 17:13:55 +0800
Subject: [PATCH 4/4] arm64: dts: imx8mq-evk: add host-wake-gpio property for pci bus
In-Reply-To: <20231208091355.1417292-1-sherry.sun@nxp.com>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
Message-ID: <20231208091355.1417292-5-sherry.sun@nxp.com>

The host wake pin is a standard feature in the PCIe bus specification,
so we add this property under PCI dts node to enable the host wake
function.

Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index 7507548cdb16..ac824046c594 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -367,6 +367,7 @@ &pcie1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_pcie1>;
 	reset-gpio = <&gpio5 12 GPIO_ACTIVE_LOW>;
+	host-wake-gpio = <&gpio5 11 GPIO_ACTIVE_LOW>;
 	clocks = <&clk IMX8MQ_CLK_PCIE2_ROOT>,
 		 <&pcie0_refclk>,
 		 <&clk IMX8MQ_CLK_PCIE2_PHY>,
@@ -545,6 +546,7 @@ pinctrl_pcie1: pcie1grp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_I2C4_SDA_PCIE2_CLKREQ_B		0x76
 			MX8MQ_IOMUXC_ECSPI2_MISO_GPIO5_IO12		0x16
+			MX8MQ_IOMUXC_ECSPI2_MOSI_GPIO5_IO11		0x41
 		>;
 	};
 
-- 
2.34.1



From sherry.sun at nxp.com  Fri Dec  8 01:13:51 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Fri,  8 Dec 2023 17:13:51 +0800
Subject: [PATCH 0/4] PCI: imx6: Add pci host wakeup support
Message-ID: <20231208091355.1417292-1-sherry.sun@nxp.com>

Add pci host wakeup feature for imx platforms. The host wake pin is a
standard feature in the PCIe bus specification, so we can add this
property under PCI dts node to support the host gpio wakeup feature.

Example of configuring the corresponding dts property under the PCI node:
    host-wake-gpio = <&gpio5 21 GPIO_ACTIVE_LOW>;

Sherry Sun (4):
  PCI: imx6: Add pci host wakeup support on imx platforms.
  dt-bindings: imx6q-pcie: Add host-wake-gpio property
  arm64: dts: imx8mp-evk: add host-wake-gpio property for pci bus
  arm64: dts: imx8mq-evk: add host-wake-gpio property for pci bus

 .../bindings/pci/fsl,imx6q-pcie.yaml          |  4 ++
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts  |  2 +
 arch/arm64/boot/dts/freescale/imx8mq-evk.dts  |  2 +
 drivers/pci/controller/dwc/pci-imx6.c         | 69 +++++++++++++++++++
 4 files changed, 77 insertions(+)

-- 
2.34.1



From sherry.sun at nxp.com  Fri Dec  8 01:13:52 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Fri,  8 Dec 2023 17:13:52 +0800
Subject: [PATCH 1/4] PCI: imx6: Add pci host wakeup support on imx platforms.
In-Reply-To: <20231208091355.1417292-1-sherry.sun@nxp.com>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
Message-ID: <20231208091355.1417292-2-sherry.sun@nxp.com>

Add pci host wakeup feature for imx platforms.
Example of configuring the corresponding dts property under the PCI
node:
host-wake-gpio = <&gpio5 21 GPIO_ACTIVE_LOW>;

Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 69 +++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 74703362aeec..050c9140f4a3 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -72,6 +72,7 @@ struct imx6_pcie_drvdata {
 struct imx6_pcie {
 	struct dw_pcie		*pci;
 	int			reset_gpio;
+	int			host_wake_irq;
 	bool			gpio_active_high;
 	bool			link_is_up;
 	struct clk		*pcie_bus;
@@ -1237,11 +1238,46 @@ static int imx6_pcie_resume_noirq(struct device *dev)
 	return 0;
 }
 
+static int imx6_pcie_suspend(struct device *dev)
+{
+	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+
+	if (imx6_pcie->host_wake_irq >= 0)
+		enable_irq_wake(imx6_pcie->host_wake_irq);
+
+	return 0;
+}
+
+static int imx6_pcie_resume(struct device *dev)
+{
+	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+
+	if (imx6_pcie->host_wake_irq >= 0)
+		disable_irq_wake(imx6_pcie->host_wake_irq);
+
+	return 0;
+}
+
 static const struct dev_pm_ops imx6_pcie_pm_ops = {
 	NOIRQ_SYSTEM_SLEEP_PM_OPS(imx6_pcie_suspend_noirq,
 				  imx6_pcie_resume_noirq)
+	SYSTEM_SLEEP_PM_OPS(imx6_pcie_suspend, imx6_pcie_resume)
 };
 
+irqreturn_t host_wake_irq_handler(int irq, void *priv)
+{
+	struct imx6_pcie *imx6_pcie = priv;
+	struct device *dev = imx6_pcie->pci->dev;
+
+	dev_dbg(dev, "%s: host wakeup by pcie", __func__);
+
+	/* Notify PM core we are wakeup source */
+	pm_wakeup_event(dev, 0);
+	pm_system_wakeup();
+
+	return IRQ_HANDLED;
+}
+
 static int imx6_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1250,6 +1286,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	struct device_node *np;
 	struct resource *dbi_base;
 	struct device_node *node = dev->of_node;
+	struct gpio_desc *host_wake_gpio;
 	int ret;
 	u16 val;
 
@@ -1457,6 +1494,32 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			val |= PCI_MSI_FLAGS_ENABLE;
 			dw_pcie_writew_dbi(pci, offset + PCI_MSI_FLAGS, val);
 		}
+
+		/* host wakeup support */
+		imx6_pcie->host_wake_irq = -1;
+		host_wake_gpio = devm_gpiod_get_optional(dev, "host-wake", GPIOD_IN);
+		if (IS_ERR(host_wake_gpio))
+			return PTR_ERR(host_wake_gpio);
+
+		if (host_wake_gpio != NULL) {
+			imx6_pcie->host_wake_irq = gpiod_to_irq(host_wake_gpio);
+			ret = devm_request_threaded_irq(dev, imx6_pcie->host_wake_irq, NULL,
+							host_wake_irq_handler,
+							IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
+							"host_wake", imx6_pcie);
+			if (ret) {
+				dev_err(dev, "Failed to request host_wake_irq %d (%d)\n",
+					imx6_pcie->host_wake_irq, ret);
+				imx6_pcie->host_wake_irq = -1;
+				return ret;
+			}
+
+			if (device_init_wakeup(dev, true)) {
+				dev_err(dev, "fail to init host_wake_irq\n");
+				imx6_pcie->host_wake_irq = -1;
+				return ret;
+			}
+		}
 	}
 
 	return 0;
@@ -1466,6 +1529,12 @@ static void imx6_pcie_shutdown(struct platform_device *pdev)
 {
 	struct imx6_pcie *imx6_pcie = platform_get_drvdata(pdev);
 
+	if (imx6_pcie->host_wake_irq >= 0) {
+		device_init_wakeup(&pdev->dev, false);
+		disable_irq(imx6_pcie->host_wake_irq);
+		imx6_pcie->host_wake_irq = -1;
+	}
+
 	/* bring down link, so bootloader gets clean state in case of reboot */
 	imx6_pcie_assert_core_reset(imx6_pcie);
 }
-- 
2.34.1



From sakari.ailus at linux.intel.com  Fri Dec  8 01:54:11 2023
From: sakari.ailus at linux.intel.com (sakari.ailus at linux.intel.com)
Date: Fri, 8 Dec 2023 09:54:11 +0000
Subject: [PATCH 1/2] media: i2c: Add GC08A3 image sensor driver
In-Reply-To: <0580bc5be77c5e293770f42b661a41c80e1986dd.camel@mediatek.com>
References: <20231207052016.25954-1-zhi.mao@mediatek.com>
 <20231207052016.25954-2-zhi.mao@mediatek.com>
 <ZXGtqwjYruBQVaUr@kekkonen.localdomain>
 <129e3a8b-5e91-424a-8ff8-b015d5175f1a@linaro.org>
 <20231207-outcome-acclaim-d179c8c07fff@spud>
 <0580bc5be77c5e293770f42b661a41c80e1986dd.camel@mediatek.com>
Message-ID: <ZXLnwzeD_DSuIyil@kekkonen.localdomain>

Hi Zhi,

On Fri, Dec 08, 2023 at 02:07:36AM +0000, Zhi Mao (??) wrote:
> On Thu, 2023-12-07 at 17:44 +0000, Conor Dooley wrote:
> > On Thu, Dec 07, 2023 at 01:30:35PM +0100, Krzysztof Kozlowski wrote:
> > > On 07/12/2023 12:34, Sakari Ailus wrote:
> > > > > +	ret = gc08a3_parse_fwnode(dev);
> > > > > +	if (ret)
> > > > > +		return ret;
> > > > > +
> > > > > +	gc08a3 = devm_kzalloc(dev, sizeof(*gc08a3),
> > > > > GFP_KERNEL);
> > > > > +	if (!gc08a3)
> > > > > +		return -ENOMEM;
> > > > > +
> > > > > +	gc08a3->dev = dev;
> > > > > +
> > > > > +	gc08a3->xclk = devm_clk_get(dev, NULL);
> > > > > +	if (IS_ERR(gc08a3->xclk))
> > > > > +		return dev_err_probe(dev, PTR_ERR(gc08a3-
> > > > > >xclk),
> > > > > +					 "failed to get
> > > > > xclk\n");
> > > > > +
> > > > > +	ret = clk_set_rate(gc08a3->xclk,
> > > > > GC08A3_DEFAULT_CLK_FREQ);
> > > > 
> > > > Please see:
> > > > <URL:
> > > > https://hverkuil.home.xs4all.nl/spec/driver-api/camera-sensor.html#devicetree>
> > > > ;.
> > > 
> > > 
> > > Oh, that's cool it was documented!
> > > 
> > > The canonical link would be:
> > > 
> https://www.kernel.org/doc/html/latest/driver-api/media/camera-sensor.html#devicetree
> > 
> > I believe this is that answer to the "why are these needed" that I
> > asked
> > on the previous version and never got a response to. Instead, they
> > were
> > just removed from the binding etc.
> 
> About "assigned-clocks" & "assigned-clock-rates" in v1 patch, as they
> are not used in sensor driver, I have removed them in sensor dts-
> bindind file. And "clock-names" & "clock-frequency" are also the same,
> they will be removed in next version.

Ack. You should only need "clocks" there, indeed.

-- 
Regards,

Sakari Ailus


From l.stach at pengutronix.de  Fri Dec  8 02:00:19 2023
From: l.stach at pengutronix.de (Lucas Stach)
Date: Fri, 08 Dec 2023 11:00:19 +0100
Subject: [PATCH 2/4] dt-bindings: imx6q-pcie: Add host-wake-gpio property
In-Reply-To: <20231208091355.1417292-3-sherry.sun@nxp.com>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
	 <20231208091355.1417292-3-sherry.sun@nxp.com>
Message-ID: <83ca3d88cdaa7bc6e6bd3c4e88518b155a6b0f05.camel@pengutronix.de>

Hi Sherry,

Am Freitag, dem 08.12.2023 um 17:13 +0800 schrieb Sherry Sun:
> Add host-wake-gpio property that can be used to wakeup the host
> processor.
> 
> Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
> Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
> ---
>  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> index 81bbb8728f0f..944f0f961809 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> @@ -72,6 +72,10 @@ properties:
>        L=operation state) (optional required).
>      type: boolean
>  
> +  host-wake-gpio:

There is only one wake signal in PCIe and it has a defined direction,
so there is no point in specifying that it is a host wakeup. Also GPIO
handles without a traling 's' are deprecated. So this should be

wake-gpios

> +    description: Should specify the GPIO for controlling the PCI bus device
> +      wake signal, used to wakeup the host processor. Default to active-low.

The description is wrong. For the RC complex case (which is the binding
you are modifying here) the controller does not control the wake
signal, but instead uses it as a input. The description should reflect
that.

The default is also quite useless, as your implementation does not
allow to change it. Please translate the GPIO active flags from the DT
to the proper IRQ flags and drop this default here. The DT should
simply carry the proper polarity.

Regards,
Lucas

> +
>  required:
>    - compatible
>    - reg



From linus.walleij at linaro.org  Fri Dec  8 02:09:24 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 08 Dec 2023 11:09:24 +0100
Subject: [PATCH 0/5] GPIO descriptor cleanup for some Wolfson codecs
Message-ID: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>

This converts the remaining Wolfson ASoC codecs to
use GPIO descriptors.

These Wolfson codecs are mostly used with different
Samsung S3C (especially Cragganmore 6410) board files,
so the in-tree users are fixed up in the process.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Linus Walleij (5):
      ASoC: wm0010: Convert to GPIO descriptors
      ASoC: wm1250-ev1: Convert to GPIO descriptors
      ASoC: wm2200: Convert to GPIO descriptors
      ASoC: wm5100: Convert to GPIO descriptors
      ASoC: wm8996: Convert to GPIO descriptors

 arch/arm/mach-s3c/mach-crag6410-module.c |  60 ++++++++++++----
 arch/arm/mach-s3c/mach-crag6410.c        |  24 +++----
 include/sound/wm0010.h                   |   6 --
 include/sound/wm1250-ev1.h               |  24 -------
 include/sound/wm2200.h                   |   2 -
 include/sound/wm5100.h                   |   4 --
 include/sound/wm8996.h                   |   3 -
 sound/soc/codecs/wm0010.c                |  44 +++---------
 sound/soc/codecs/wm1250-ev1.c            | 118 ++++++++++++-------------------
 sound/soc/codecs/wm2200.c                |  67 +++++++++---------
 sound/soc/codecs/wm5100.c                | 107 ++++++++++------------------
 sound/soc/codecs/wm8996.c                |  58 +++++++--------
 12 files changed, 211 insertions(+), 306 deletions(-)
---
base-commit: cbf5552fa580b78c690ca5829264f2fd2e2bafc1
change-id: 20231205-descriptors-sound-wlf-e6caec3cc642

Best regards,
-- 
Linus Walleij <linus.walleij at linaro.org>



From linus.walleij at linaro.org  Fri Dec  8 02:09:25 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 08 Dec 2023 11:09:25 +0100
Subject: [PATCH 1/5] ASoC: wm0010: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
Message-ID: <20231208-descriptors-sound-wlf-v1-1-c4dab6f521ec@linaro.org>

This converts the WM0010 codec to use GPIO descriptors.
It's a pretty straight-forward conversion also switching over
the single in-tree user in the S3C Cragganmore module
for S3C 6410.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-s3c/mach-crag6410-module.c | 16 +++++++++---
 include/sound/wm0010.h                   |  6 -----
 sound/soc/codecs/wm0010.c                | 44 ++++++++------------------------
 3 files changed, 23 insertions(+), 43 deletions(-)

diff --git a/arch/arm/mach-s3c/mach-crag6410-module.c b/arch/arm/mach-s3c/mach-crag6410-module.c
index 8fce1e815ee8..a9a713641047 100644
--- a/arch/arm/mach-s3c/mach-crag6410-module.c
+++ b/arch/arm/mach-s3c/mach-crag6410-module.c
@@ -32,9 +32,18 @@
 
 #include "crag6410.h"
 
+static struct gpiod_lookup_table wm0010_gpiod_table = {
+	.dev_id = "spi0.0", /* SPI device name */
+	.table = {
+		/* Active high for Glenfarclas Rev 2 */
+		GPIO_LOOKUP("GPION", 6,
+			    "reset", GPIO_ACTIVE_HIGH),
+		{ },
+	},
+};
+
 static struct wm0010_pdata wm0010_pdata = {
-	.gpio_reset = S3C64XX_GPN(6),
-	.reset_active_high = 1, /* Active high for Glenfarclas Rev 2 */
+	/* Intentionally left blank */
 };
 
 static struct spi_board_info wm1253_devs[] = {
@@ -337,7 +346,8 @@ static const struct {
 	{ .id = 0x21, .rev = 0xff, .name = "1275-EV1 Mortlach" },
 	{ .id = 0x25, .rev = 0xff, .name = "1274-EV1 Glencadam" },
 	{ .id = 0x31, .rev = 0xff, .name = "1253-EV1 Tomatin",
-	  .spi_devs = wm1253_devs, .num_spi_devs = ARRAY_SIZE(wm1253_devs) },
+	  .spi_devs = wm1253_devs, .num_spi_devs = ARRAY_SIZE(wm1253_devs),
+	  .gpiod_table = &wm0010_gpiod_table },
 	{ .id = 0x32, .rev = 0xff, .name = "XXXX-EV1 Caol Illa" },
 	{ .id = 0x33, .rev = 0xff, .name = "XXXX-EV1 Oban" },
 	{ .id = 0x34, .rev = 0xff, .name = "WM0010-6320-CS42 Balblair",
diff --git a/include/sound/wm0010.h b/include/sound/wm0010.h
index 13b473935ca1..14ff9056c5d0 100644
--- a/include/sound/wm0010.h
+++ b/include/sound/wm0010.h
@@ -11,12 +11,6 @@
 #define WM0010_PDATA_H
 
 struct wm0010_pdata {
-	int gpio_reset;
-
-	/* Set if there is an inverter between the GPIO controlling
-	 * the reset signal and the device.
-	 */
-	int reset_active_high;
 	int irq_flags;
 };
 
diff --git a/sound/soc/codecs/wm0010.c b/sound/soc/codecs/wm0010.c
index 1d4259433f47..8f862729a2ca 100644
--- a/sound/soc/codecs/wm0010.c
+++ b/sound/soc/codecs/wm0010.c
@@ -18,7 +18,7 @@
 #include <linux/firmware.h>
 #include <linux/delay.h>
 #include <linux/fs.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/regulator/consumer.h>
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
@@ -94,8 +94,7 @@ struct wm0010_priv {
 
 	struct wm0010_pdata pdata;
 
-	int gpio_reset;
-	int gpio_reset_value;
+	struct gpio_desc *reset;
 
 	struct regulator_bulk_data core_supplies[2];
 	struct regulator *dbvdd;
@@ -174,8 +173,7 @@ static void wm0010_halt(struct snd_soc_component *component)
 	case WM0010_STAGE2:
 	case WM0010_FIRMWARE:
 		/* Remember to put chip back into reset */
-		gpio_set_value_cansleep(wm0010->gpio_reset,
-					wm0010->gpio_reset_value);
+		gpiod_set_value_cansleep(wm0010->reset, 1);
 		/* Disable the regulators */
 		regulator_disable(wm0010->dbvdd);
 		regulator_bulk_disable(ARRAY_SIZE(wm0010->core_supplies),
@@ -610,7 +608,7 @@ static int wm0010_boot(struct snd_soc_component *component)
 	}
 
 	/* Release reset */
-	gpio_set_value_cansleep(wm0010->gpio_reset, !wm0010->gpio_reset_value);
+	gpiod_set_value_cansleep(wm0010->reset, 0);
 	spin_lock_irqsave(&wm0010->irq_lock, flags);
 	wm0010->state = WM0010_OUT_OF_RESET;
 	spin_unlock_irqrestore(&wm0010->irq_lock, flags);
@@ -863,7 +861,6 @@ static int wm0010_probe(struct snd_soc_component *component)
 
 static int wm0010_spi_probe(struct spi_device *spi)
 {
-	unsigned long gpio_flags;
 	int ret;
 	int trigger;
 	int irq;
@@ -903,31 +900,11 @@ static int wm0010_spi_probe(struct spi_device *spi)
 		return ret;
 	}
 
-	if (wm0010->pdata.gpio_reset) {
-		wm0010->gpio_reset = wm0010->pdata.gpio_reset;
-
-		if (wm0010->pdata.reset_active_high)
-			wm0010->gpio_reset_value = 1;
-		else
-			wm0010->gpio_reset_value = 0;
-
-		if (wm0010->gpio_reset_value)
-			gpio_flags = GPIOF_OUT_INIT_HIGH;
-		else
-			gpio_flags = GPIOF_OUT_INIT_LOW;
-
-		ret = devm_gpio_request_one(wm0010->dev, wm0010->gpio_reset,
-					    gpio_flags, "wm0010 reset");
-		if (ret < 0) {
-			dev_err(wm0010->dev,
-				"Failed to request GPIO for DSP reset: %d\n",
-				ret);
-			return ret;
-		}
-	} else {
-		dev_err(wm0010->dev, "No reset GPIO configured\n");
-		return -EINVAL;
-	}
+	wm0010->reset = devm_gpiod_get(wm0010->dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(wm0010->reset))
+		return dev_err_probe(wm0010->dev, PTR_ERR(wm0010->reset),
+				     "could not get RESET GPIO\n");
+	gpiod_set_consumer_name(wm0010->reset, "wm0010 reset");
 
 	wm0010->state = WM0010_POWER_OFF;
 
@@ -972,8 +949,7 @@ static void wm0010_spi_remove(struct spi_device *spi)
 {
 	struct wm0010_priv *wm0010 = spi_get_drvdata(spi);
 
-	gpio_set_value_cansleep(wm0010->gpio_reset,
-				wm0010->gpio_reset_value);
+	gpiod_set_value_cansleep(wm0010->reset, 1);
 
 	irq_set_irq_wake(wm0010->irq, 0);
 

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  8 02:09:28 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 08 Dec 2023 11:09:28 +0100
Subject: [PATCH 4/5] ASoC: wm5100: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
Message-ID: <20231208-descriptors-sound-wlf-v1-4-c4dab6f521ec@linaro.org>

This converts the WM5100 codec to use GPIO descriptors, a pretty
straight-forward conversion with the following peculiarities:

- The driver is instantiating a GPIO chip named wm5100, and the
  headphone polarity detection GPIO is lifted from there. We add
  this to the GPIO descriptor table as well, and we can then get
  rid of also the base address for the GPIO chip from the
  platform data and just use dynamic numbering.

- Fix up the only in-tree user which is the Cragganmore 6410
  module.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-s3c/mach-crag6410-module.c |  17 +++--
 include/sound/wm5100.h                   |   4 --
 sound/soc/codecs/wm5100.c                | 107 +++++++++++--------------------
 3 files changed, 52 insertions(+), 76 deletions(-)

diff --git a/arch/arm/mach-s3c/mach-crag6410-module.c b/arch/arm/mach-s3c/mach-crag6410-module.c
index 1df6b7e52c9d..59456fbebf1b 100644
--- a/arch/arm/mach-s3c/mach-crag6410-module.c
+++ b/arch/arm/mach-s3c/mach-crag6410-module.c
@@ -70,10 +70,19 @@ static struct spi_board_info balblair_devs[] = {
 	},
 };
 
+static struct gpiod_lookup_table wm5100_gpiod_table = {
+	.dev_id = "1-001a", /* Device 001a on I2C bus 1 */
+	.table = {
+		GPIO_LOOKUP("GPION", 7,
+			    "wlf,ldo1ena", GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP("wm5100", 3,
+			    "hp-pol", GPIO_ACTIVE_HIGH),
+		{ },
+	},
+};
+
 static struct wm5100_pdata wm5100_pdata = {
-	.ldo_ena = S3C64XX_GPN(7),
 	.irq_flags = IRQF_TRIGGER_HIGH,
-	.gpio_base = CODEC_GPIO_BASE,
 
 	.in_mode = {
 		WM5100_IN_DIFF,
@@ -82,7 +91,6 @@ static struct wm5100_pdata wm5100_pdata = {
 		WM5100_IN_SE,
 	},
 
-	.hp_pol = CODEC_GPIO_BASE + 3,
 	.jack_modes = {
 		{ WM5100_MICDET_MICBIAS3, 0, 0 },
 		{ WM5100_MICDET_MICBIAS2, 1, 1 },
@@ -366,7 +374,8 @@ static const struct {
 	{ .id = 0x3a, .rev = 0xff, .name = "1259-EV1 Tobermory",
 	  .i2c_devs = wm1259_devs, .num_i2c_devs = ARRAY_SIZE(wm1259_devs) },
 	{ .id = 0x3b, .rev = 0xff, .name = "1255-EV1 Kilchoman",
-	  .i2c_devs = wm1255_devs, .num_i2c_devs = ARRAY_SIZE(wm1255_devs) },
+	  .i2c_devs = wm1255_devs, .num_i2c_devs = ARRAY_SIZE(wm1255_devs),
+	  .gpiod_table = &wm5100_gpiod_table },
 	{ .id = 0x3c, .rev = 0xff, .name = "1273-EV1 Longmorn" },
 	{ .id = 0x3d, .rev = 0xff, .name = "1277-EV1 Littlemill",
 	  .i2c_devs = wm1277_devs, .num_i2c_devs = ARRAY_SIZE(wm1277_devs),
diff --git a/include/sound/wm5100.h b/include/sound/wm5100.h
index b94badf72947..1c48090fdb2c 100644
--- a/include/sound/wm5100.h
+++ b/include/sound/wm5100.h
@@ -36,11 +36,7 @@ struct wm5100_jack_mode {
 #define WM5100_GPIO_SET 0x10000
 
 struct wm5100_pdata {
-	int reset;      /** GPIO controlling /RESET, if any */
-	int ldo_ena;    /** GPIO controlling LODENA, if any */
-	int hp_pol;     /** GPIO controlling headset polarity, if any */
 	int irq_flags;
-	int gpio_base;
 
 	struct wm5100_jack_mode jack_modes[2];
 
diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c
index ff63723928a1..7ee4b45c0834 100644
--- a/sound/soc/codecs/wm5100.c
+++ b/sound/soc/codecs/wm5100.c
@@ -15,7 +15,7 @@
 #include <linux/pm.h>
 #include <linux/gcd.h>
 #include <linux/gpio/driver.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/i2c.h>
 #include <linux/pm_runtime.h>
 #include <linux/regulator/consumer.h>
@@ -55,6 +55,9 @@ struct wm5100_priv {
 	struct snd_soc_component *component;
 
 	struct regulator_bulk_data core_supplies[WM5100_NUM_CORE_SUPPLIES];
+	struct gpio_desc *reset;
+	struct gpio_desc *ldo_ena;
+	struct gpio_desc *hp_pol;
 
 	int rev;
 
@@ -205,9 +208,9 @@ static void wm5100_free_sr(struct snd_soc_component *component, int rate)
 
 static int wm5100_reset(struct wm5100_priv *wm5100)
 {
-	if (wm5100->pdata.reset) {
-		gpio_set_value_cansleep(wm5100->pdata.reset, 0);
-		gpio_set_value_cansleep(wm5100->pdata.reset, 1);
+	if (wm5100->reset) {
+		gpiod_set_value_cansleep(wm5100->reset, 1);
+		gpiod_set_value_cansleep(wm5100->reset, 0);
 
 		return 0;
 	} else {
@@ -1974,7 +1977,7 @@ static void wm5100_set_detect_mode(struct wm5100_priv *wm5100, int the_mode)
 	if (WARN_ON(the_mode >= ARRAY_SIZE(wm5100->pdata.jack_modes)))
 		return;
 
-	gpio_set_value_cansleep(wm5100->pdata.hp_pol, mode->hp_pol);
+	gpiod_set_value_cansleep(wm5100->hp_pol, mode->hp_pol);
 	regmap_update_bits(wm5100->regmap, WM5100_ACCESSORY_DETECT_MODE_1,
 			   WM5100_ACCDET_BIAS_SRC_MASK |
 			   WM5100_ACCDET_SRC,
@@ -2299,11 +2302,7 @@ static void wm5100_init_gpio(struct i2c_client *i2c)
 	wm5100->gpio_chip = wm5100_template_chip;
 	wm5100->gpio_chip.ngpio = 6;
 	wm5100->gpio_chip.parent = &i2c->dev;
-
-	if (wm5100->pdata.gpio_base)
-		wm5100->gpio_chip.base = wm5100->pdata.gpio_base;
-	else
-		wm5100->gpio_chip.base = -1;
+	wm5100->gpio_chip.base = -1;
 
 	ret = gpiochip_add_data(&wm5100->gpio_chip, wm5100);
 	if (ret != 0)
@@ -2349,35 +2348,20 @@ static int wm5100_probe(struct snd_soc_component *component)
 		snd_soc_dapm_new_controls(dapm, wm5100_dapm_widgets_noirq,
 					  ARRAY_SIZE(wm5100_dapm_widgets_noirq));
 
-	if (wm5100->pdata.hp_pol) {
-		ret = gpio_request_one(wm5100->pdata.hp_pol,
-				       GPIOF_OUT_INIT_HIGH, "WM5100 HP_POL");
-		if (ret < 0) {
-			dev_err(&i2c->dev, "Failed to request HP_POL %d: %d\n",
-				wm5100->pdata.hp_pol, ret);
-			goto err_gpio;
-		}
+	wm5100->hp_pol = devm_gpiod_get_optional(&i2c->dev, "hp-pol",
+						 GPIOD_OUT_HIGH);
+	if (IS_ERR(wm5100->hp_pol)) {
+		ret = PTR_ERR(wm5100->hp_pol);
+		dev_err(&i2c->dev, "Failed to request HP_POL GPIO: %d\n",
+			ret);
+		return ret;
 	}
 
 	return 0;
-
-err_gpio:
-
-	return ret;
-}
-
-static void wm5100_remove(struct snd_soc_component *component)
-{
-	struct wm5100_priv *wm5100 = snd_soc_component_get_drvdata(component);
-
-	if (wm5100->pdata.hp_pol) {
-		gpio_free(wm5100->pdata.hp_pol);
-	}
 }
 
 static const struct snd_soc_component_driver soc_component_dev_wm5100 = {
 	.probe			= wm5100_probe,
-	.remove			= wm5100_remove,
 	.set_sysclk		= wm5100_set_sysclk,
 	.set_pll		= wm5100_set_fll,
 	.seq_notifier		= wm5100_seq_notifier,
@@ -2460,26 +2444,26 @@ static int wm5100_i2c_probe(struct i2c_client *i2c)
 		goto err;
 	}
 
-	if (wm5100->pdata.ldo_ena) {
-		ret = gpio_request_one(wm5100->pdata.ldo_ena,
-				       GPIOF_OUT_INIT_HIGH, "WM5100 LDOENA");
-		if (ret < 0) {
-			dev_err(&i2c->dev, "Failed to request LDOENA %d: %d\n",
-				wm5100->pdata.ldo_ena, ret);
-			goto err_enable;
-		}
+	wm5100->ldo_ena = devm_gpiod_get_optional(&i2c->dev, "wlf,ldo1ena",
+						  GPIOD_OUT_HIGH);
+	if (IS_ERR(wm5100->ldo_ena)) {
+		ret = PTR_ERR(wm5100->ldo_ena);
+		dev_err(&i2c->dev, "Failed to request LDOENA GPIO: %d\n", ret);
+		goto err_enable;
+	}
+	if (wm5100->ldo_ena) {
+		gpiod_set_consumer_name(wm5100->ldo_ena, "WM5100 LDOENA");
 		msleep(2);
 	}
 
-	if (wm5100->pdata.reset) {
-		ret = gpio_request_one(wm5100->pdata.reset,
-				       GPIOF_OUT_INIT_HIGH, "WM5100 /RESET");
-		if (ret < 0) {
-			dev_err(&i2c->dev, "Failed to request /RESET %d: %d\n",
-				wm5100->pdata.reset, ret);
-			goto err_ldo;
-		}
+	wm5100->reset = devm_gpiod_get_optional(&i2c->dev, "reset",
+						GPIOD_OUT_LOW);
+	if (IS_ERR(wm5100->reset)) {
+		ret = PTR_ERR(wm5100->reset);
+		dev_err(&i2c->dev, "Failed to request /RESET GPIO: %d\n", ret);
+		goto err_ldo;
 	}
+	gpiod_set_consumer_name(wm5100->reset, "WM5100 /RESET");
 
 	ret = regmap_read(wm5100->regmap, WM5100_SOFTWARE_RESET, &reg);
 	if (ret < 0) {
@@ -2619,15 +2603,9 @@ static int wm5100_i2c_probe(struct i2c_client *i2c)
 	if (i2c->irq)
 		free_irq(i2c->irq, wm5100);
 	wm5100_free_gpio(i2c);
-	if (wm5100->pdata.reset) {
-		gpio_set_value_cansleep(wm5100->pdata.reset, 0);
-		gpio_free(wm5100->pdata.reset);
-	}
+	gpiod_set_value_cansleep(wm5100->reset, 1);
 err_ldo:
-	if (wm5100->pdata.ldo_ena) {
-		gpio_set_value_cansleep(wm5100->pdata.ldo_ena, 0);
-		gpio_free(wm5100->pdata.ldo_ena);
-	}
+	gpiod_set_value_cansleep(wm5100->ldo_ena, 0);
 err_enable:
 	regulator_bulk_disable(ARRAY_SIZE(wm5100->core_supplies),
 			       wm5100->core_supplies);
@@ -2643,14 +2621,8 @@ static void wm5100_i2c_remove(struct i2c_client *i2c)
 	if (i2c->irq)
 		free_irq(i2c->irq, wm5100);
 	wm5100_free_gpio(i2c);
-	if (wm5100->pdata.reset) {
-		gpio_set_value_cansleep(wm5100->pdata.reset, 0);
-		gpio_free(wm5100->pdata.reset);
-	}
-	if (wm5100->pdata.ldo_ena) {
-		gpio_set_value_cansleep(wm5100->pdata.ldo_ena, 0);
-		gpio_free(wm5100->pdata.ldo_ena);
-	}
+	gpiod_set_value_cansleep(wm5100->reset, 1);
+	gpiod_set_value_cansleep(wm5100->ldo_ena, 0);
 }
 
 #ifdef CONFIG_PM
@@ -2660,8 +2632,7 @@ static int wm5100_runtime_suspend(struct device *dev)
 
 	regcache_cache_only(wm5100->regmap, true);
 	regcache_mark_dirty(wm5100->regmap);
-	if (wm5100->pdata.ldo_ena)
-		gpio_set_value_cansleep(wm5100->pdata.ldo_ena, 0);
+	gpiod_set_value_cansleep(wm5100->ldo_ena, 0);
 	regulator_bulk_disable(ARRAY_SIZE(wm5100->core_supplies),
 			       wm5100->core_supplies);
 
@@ -2681,8 +2652,8 @@ static int wm5100_runtime_resume(struct device *dev)
 		return ret;
 	}
 
-	if (wm5100->pdata.ldo_ena) {
-		gpio_set_value_cansleep(wm5100->pdata.ldo_ena, 1);
+	if (wm5100->ldo_ena) {
+		gpiod_set_value_cansleep(wm5100->ldo_ena, 1);
 		msleep(2);
 	}
 

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  8 02:09:27 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 08 Dec 2023 11:09:27 +0100
Subject: [PATCH 3/5] ASoC: wm2200: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
Message-ID: <20231208-descriptors-sound-wlf-v1-3-c4dab6f521ec@linaro.org>

This converts the WM2200 codec to use GPIO descriptors.
This is a pretty straight-forward conversion, and it also
switches over the single in-tree user in the S3C
Cragganmore module for S3C 6410.

This coded does not seem to get selected or be selectable
through Kconfig, I had to hack another soundcard Kconfig
entry to select it for compile tests.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-s3c/mach-crag6410-module.c | 13 ++++++-
 include/sound/wm2200.h                   |  2 -
 sound/soc/codecs/wm2200.c                | 67 ++++++++++++++++----------------
 3 files changed, 44 insertions(+), 38 deletions(-)

diff --git a/arch/arm/mach-s3c/mach-crag6410-module.c b/arch/arm/mach-s3c/mach-crag6410-module.c
index a9a713641047..1df6b7e52c9d 100644
--- a/arch/arm/mach-s3c/mach-crag6410-module.c
+++ b/arch/arm/mach-s3c/mach-crag6410-module.c
@@ -305,12 +305,20 @@ static const struct i2c_board_info wm6230_i2c_devs[] = {
 };
 
 static struct wm2200_pdata wm2200_pdata = {
-	.ldo_ena = S3C64XX_GPN(7),
 	.gpio_defaults = {
 		[2] = 0x0005,  /* GPIO3 24.576MHz output clock */
 	},
 };
 
+static struct gpiod_lookup_table wm2200_gpiod_table = {
+	.dev_id = "1-003a", /* Device 003a on I2C bus 1 */
+	.table = {
+		GPIO_LOOKUP("GPION", 7,
+			    "wlf,ldo1ena", GPIO_ACTIVE_HIGH),
+		{ },
+	},
+};
+
 static const struct i2c_board_info wm2200_i2c[] = {
 	{ I2C_BOARD_INFO("wm2200", 0x3a),
 	  .platform_data = &wm2200_pdata, },
@@ -372,7 +380,8 @@ static const struct {
 	  .num_spi_devs = ARRAY_SIZE(wm5102_spi_devs),
 	  .gpiod_table = &wm5102_gpiod_table },
 	{ .id = 0x3f, .rev = -1, .name = "WM2200-6271-CS90-M-REV1",
-	  .i2c_devs = wm2200_i2c, .num_i2c_devs = ARRAY_SIZE(wm2200_i2c) },
+	  .i2c_devs = wm2200_i2c, .num_i2c_devs = ARRAY_SIZE(wm2200_i2c),
+	  .gpiod_table = &wm2200_gpiod_table },
 };
 
 static int wlf_gf_module_probe(struct i2c_client *i2c)
diff --git a/include/sound/wm2200.h b/include/sound/wm2200.h
index 9987e6c09bdc..2e4913ee2505 100644
--- a/include/sound/wm2200.h
+++ b/include/sound/wm2200.h
@@ -42,8 +42,6 @@ struct wm2200_micbias {
 };
 
 struct wm2200_pdata {
-	int reset;      /** GPIO controlling /RESET, if any */
-	int ldo_ena;    /** GPIO controlling LODENA, if any */
 	int irq_flags;
 
 	int gpio_defaults[4];
diff --git a/sound/soc/codecs/wm2200.c b/sound/soc/codecs/wm2200.c
index 9679906c6bd5..69c9c2bd7e7b 100644
--- a/sound/soc/codecs/wm2200.c
+++ b/sound/soc/codecs/wm2200.c
@@ -14,7 +14,7 @@
 #include <linux/pm.h>
 #include <linux/firmware.h>
 #include <linux/gcd.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/i2c.h>
 #include <linux/pm_runtime.h>
 #include <linux/regulator/consumer.h>
@@ -79,6 +79,8 @@ struct wm2200_priv {
 	struct snd_soc_component *component;
 	struct wm2200_pdata pdata;
 	struct regulator_bulk_data core_supplies[WM2200_NUM_CORE_SUPPLIES];
+	struct gpio_desc *ldo_ena;
+	struct gpio_desc *reset;
 
 	struct completion fll_lock;
 	int fll_fout;
@@ -975,9 +977,10 @@ static const struct reg_sequence wm2200_reva_patch[] = {
 
 static int wm2200_reset(struct wm2200_priv *wm2200)
 {
-	if (wm2200->pdata.reset) {
-		gpio_set_value_cansleep(wm2200->pdata.reset, 0);
-		gpio_set_value_cansleep(wm2200->pdata.reset, 1);
+	if (wm2200->reset) {
+		/* Descriptor flagged active low, so this will be inverted */
+		gpiod_set_value_cansleep(wm2200->reset, 1);
+		gpiod_set_value_cansleep(wm2200->reset, 0);
 
 		return 0;
 	} else {
@@ -2246,28 +2249,28 @@ static int wm2200_i2c_probe(struct i2c_client *i2c)
 		return ret;
 	}
 
-	if (wm2200->pdata.ldo_ena) {
-		ret = devm_gpio_request_one(&i2c->dev, wm2200->pdata.ldo_ena,
-					    GPIOF_OUT_INIT_HIGH,
-					    "WM2200 LDOENA");
-		if (ret < 0) {
-			dev_err(&i2c->dev, "Failed to request LDOENA %d: %d\n",
-				wm2200->pdata.ldo_ena, ret);
-			goto err_enable;
-		}
+	wm2200->ldo_ena = devm_gpiod_get_optional(&i2c->dev, "wlf,ldo1ena",
+						  GPIOD_OUT_HIGH);
+	if (IS_ERR(wm2200->ldo_ena)) {
+		ret = PTR_ERR(wm2200->ldo_ena);
+		dev_err(&i2c->dev, "Failed to request LDOENA GPIO %d\n",
+			ret);
+		goto err_enable;
+	}
+	if (wm2200->ldo_ena) {
+		gpiod_set_consumer_name(wm2200->ldo_ena, "WM2200 LDOENA");
 		msleep(2);
 	}
 
-	if (wm2200->pdata.reset) {
-		ret = devm_gpio_request_one(&i2c->dev, wm2200->pdata.reset,
-					    GPIOF_OUT_INIT_HIGH,
-					    "WM2200 /RESET");
-		if (ret < 0) {
-			dev_err(&i2c->dev, "Failed to request /RESET %d: %d\n",
-				wm2200->pdata.reset, ret);
-			goto err_ldo;
-		}
+	wm2200->reset = devm_gpiod_get_optional(&i2c->dev, "reset",
+						GPIOD_OUT_LOW);
+	if (IS_ERR(wm2200->reset)) {
+		ret = PTR_ERR(wm2200->reset);
+		dev_err(&i2c->dev, "Failed to request RESET GPIO %d\n",
+			ret);
+		goto err_ldo;
 	}
+	gpiod_set_consumer_name(wm2200->reset, "WM2200 /RESET");
 
 	ret = regmap_read(wm2200->regmap, WM2200_SOFTWARE_RESET, &reg);
 	if (ret < 0) {
@@ -2403,11 +2406,9 @@ static int wm2200_i2c_probe(struct i2c_client *i2c)
 	if (i2c->irq)
 		free_irq(i2c->irq, wm2200);
 err_reset:
-	if (wm2200->pdata.reset)
-		gpio_set_value_cansleep(wm2200->pdata.reset, 0);
+	gpiod_set_value_cansleep(wm2200->reset, 1);
 err_ldo:
-	if (wm2200->pdata.ldo_ena)
-		gpio_set_value_cansleep(wm2200->pdata.ldo_ena, 0);
+	gpiod_set_value_cansleep(wm2200->ldo_ena, 0);
 err_enable:
 	regulator_bulk_disable(ARRAY_SIZE(wm2200->core_supplies),
 			       wm2200->core_supplies);
@@ -2421,10 +2422,9 @@ static void wm2200_i2c_remove(struct i2c_client *i2c)
 	pm_runtime_disable(&i2c->dev);
 	if (i2c->irq)
 		free_irq(i2c->irq, wm2200);
-	if (wm2200->pdata.reset)
-		gpio_set_value_cansleep(wm2200->pdata.reset, 0);
-	if (wm2200->pdata.ldo_ena)
-		gpio_set_value_cansleep(wm2200->pdata.ldo_ena, 0);
+	/* Assert RESET, disable LDO */
+	gpiod_set_value_cansleep(wm2200->reset, 1);
+	gpiod_set_value_cansleep(wm2200->ldo_ena, 0);
 	regulator_bulk_disable(ARRAY_SIZE(wm2200->core_supplies),
 			       wm2200->core_supplies);
 }
@@ -2436,8 +2436,7 @@ static int wm2200_runtime_suspend(struct device *dev)
 
 	regcache_cache_only(wm2200->regmap, true);
 	regcache_mark_dirty(wm2200->regmap);
-	if (wm2200->pdata.ldo_ena)
-		gpio_set_value_cansleep(wm2200->pdata.ldo_ena, 0);
+	gpiod_set_value_cansleep(wm2200->ldo_ena, 0);
 	regulator_bulk_disable(ARRAY_SIZE(wm2200->core_supplies),
 			       wm2200->core_supplies);
 
@@ -2457,8 +2456,8 @@ static int wm2200_runtime_resume(struct device *dev)
 		return ret;
 	}
 
-	if (wm2200->pdata.ldo_ena) {
-		gpio_set_value_cansleep(wm2200->pdata.ldo_ena, 1);
+	if (wm2200->ldo_ena) {
+		gpiod_set_value_cansleep(wm2200->ldo_ena, 1);
 		msleep(2);
 	}
 

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  8 02:09:26 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 08 Dec 2023 11:09:26 +0100
Subject: [PATCH 2/5] ASoC: wm1250-ev1: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
Message-ID: <20231208-descriptors-sound-wlf-v1-2-c4dab6f521ec@linaro.org>

This converts the WM1250-EV1 codec to use GPIO descriptors.
It turns out that the platform data was only used to pass some
global GPIO numbers from a board file, so we get rid of this
and also switch over the single in-tree user in the S3C
Cragganmore module for S3C 6410.

The driver obtains two GPIO lines named OSR and master and just
pull them low, we leave this behaviour as it was.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-s3c/mach-crag6410.c |  24 ++++----
 include/sound/wm1250-ev1.h        |  24 --------
 sound/soc/codecs/wm1250-ev1.c     | 118 ++++++++++++++------------------------
 3 files changed, 56 insertions(+), 110 deletions(-)

diff --git a/arch/arm/mach-s3c/mach-crag6410.c b/arch/arm/mach-s3c/mach-crag6410.c
index 7c4bed4370a1..e5df2cb51ab2 100644
--- a/arch/arm/mach-s3c/mach-crag6410.c
+++ b/arch/arm/mach-s3c/mach-crag6410.c
@@ -39,8 +39,6 @@
 #include <linux/mfd/wm831x/irq.h>
 #include <linux/mfd/wm831x/gpio.h>
 
-#include <sound/wm1250-ev1.h>
-
 #include <asm/mach/arch.h>
 #include <asm/mach-types.h>
 
@@ -713,13 +711,16 @@ static struct wm831x_pdata glenfarclas_pmic_pdata = {
 	.disable_touch = true,
 };
 
-static struct wm1250_ev1_pdata wm1250_ev1_pdata = {
-	.gpios = {
-		[WM1250_EV1_GPIO_CLK_ENA] = S3C64XX_GPN(12),
-		[WM1250_EV1_GPIO_CLK_SEL0] = S3C64XX_GPL(12),
-		[WM1250_EV1_GPIO_CLK_SEL1] = S3C64XX_GPL(13),
-		[WM1250_EV1_GPIO_OSR] = S3C64XX_GPL(14),
-		[WM1250_EV1_GPIO_MASTER] = S3C64XX_GPL(8),
+static struct gpiod_lookup_table crag_wm1250_ev1_gpiod_table = {
+	/* The WM1250-EV1 is device 0027 on I2C bus 1 */
+	.dev_id = "1-0027",
+	.table = {
+		GPIO_LOOKUP("GPION", 12, "clk-ena", GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP("GPIOL", 12, "clk-sel0", GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP("GPIOL", 13, "clk-sel1", GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP("GPIOL", 14, "osr", GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP("GPIOL", 8, "master", GPIO_ACTIVE_HIGH),
+		{ },
 	},
 };
 
@@ -733,9 +734,7 @@ static struct i2c_board_info i2c_devs1[] = {
 	{ I2C_BOARD_INFO("wlf-gf-module", 0x24) },
 	{ I2C_BOARD_INFO("wlf-gf-module", 0x25) },
 	{ I2C_BOARD_INFO("wlf-gf-module", 0x26) },
-
-	{ I2C_BOARD_INFO("wm1250-ev1", 0x27),
-	  .platform_data = &wm1250_ev1_pdata },
+	{ I2C_BOARD_INFO("wm1250-ev1", 0x27), },
 };
 
 static struct s3c2410_platform_i2c i2c1_pdata = {
@@ -862,6 +861,7 @@ static void __init crag6410_machine_init(void)
 
 	gpiod_add_lookup_table(&crag_pmic_gpiod_table);
 	i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
+	gpiod_add_lookup_table(&crag_wm1250_ev1_gpiod_table);
 	i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
 
 	samsung_keypad_set_platdata(&crag6410_keypad_data);
diff --git a/include/sound/wm1250-ev1.h b/include/sound/wm1250-ev1.h
deleted file mode 100644
index d16614ebecb4..000000000000
--- a/include/sound/wm1250-ev1.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * linux/sound/wm1250-ev1.h - Platform data for WM1250-EV1
- *
- * Copyright 2011 Wolfson Microelectronics. PLC.
- */
-
-#ifndef __LINUX_SND_WM1250_EV1_H
-#define __LINUX_SND_WM1250_EV1_H
-
-#define WM1250_EV1_NUM_GPIOS 5
-
-#define WM1250_EV1_GPIO_CLK_ENA  0
-#define WM1250_EV1_GPIO_CLK_SEL0 1
-#define WM1250_EV1_GPIO_CLK_SEL1 2
-#define WM1250_EV1_GPIO_OSR      3
-#define WM1250_EV1_GPIO_MASTER   4
-
-
-struct wm1250_ev1_pdata {
-	int gpios[WM1250_EV1_NUM_GPIOS];
-};
-
-#endif
diff --git a/sound/soc/codecs/wm1250-ev1.c b/sound/soc/codecs/wm1250-ev1.c
index d7eeb41ba60f..a2a8b2a4b19b 100644
--- a/sound/soc/codecs/wm1250-ev1.c
+++ b/sound/soc/codecs/wm1250-ev1.c
@@ -9,34 +9,23 @@
 #include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/i2c.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 
 #include <sound/soc.h>
 #include <sound/soc-dapm.h>
-#include <sound/wm1250-ev1.h>
-
-static const char *wm1250_gpio_names[WM1250_EV1_NUM_GPIOS] = {
-	"WM1250 CLK_ENA",
-	"WM1250 CLK_SEL0",
-	"WM1250 CLK_SEL1",
-	"WM1250 OSR",
-	"WM1250 MASTER",
-};
 
 struct wm1250_priv {
-	struct gpio gpios[WM1250_EV1_NUM_GPIOS];
+	struct gpio_desc *clk_ena;
+	struct gpio_desc *clk_sel0;
+	struct gpio_desc *clk_sel1;
+	struct gpio_desc *osr;
+	struct gpio_desc *master;
 };
 
 static int wm1250_ev1_set_bias_level(struct snd_soc_component *component,
 				     enum snd_soc_bias_level level)
 {
 	struct wm1250_priv *wm1250 = dev_get_drvdata(component->dev);
-	int ena;
-
-	if (wm1250)
-		ena = wm1250->gpios[WM1250_EV1_GPIO_CLK_ENA].gpio;
-	else
-		ena = -1;
 
 	switch (level) {
 	case SND_SOC_BIAS_ON:
@@ -46,13 +35,11 @@ static int wm1250_ev1_set_bias_level(struct snd_soc_component *component,
 		break;
 
 	case SND_SOC_BIAS_STANDBY:
-		if (ena >= 0)
-			gpio_set_value_cansleep(ena, 1);
+		gpiod_set_value_cansleep(wm1250->clk_ena, 1);
 		break;
 
 	case SND_SOC_BIAS_OFF:
-		if (ena >= 0)
-			gpio_set_value_cansleep(ena, 0);
+		gpiod_set_value_cansleep(wm1250->clk_ena, 0);
 		break;
 	}
 
@@ -80,28 +67,20 @@ static int wm1250_ev1_hw_params(struct snd_pcm_substream *substream,
 
 	switch (params_rate(params)) {
 	case 8000:
-		gpio_set_value(wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL0].gpio,
-			       1);
-		gpio_set_value(wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL1].gpio,
-			       1);
+		gpiod_set_value(wm1250->clk_sel0, 1);
+		gpiod_set_value(wm1250->clk_sel1, 1);
 		break;
 	case 16000:
-		gpio_set_value(wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL0].gpio,
-			       0);
-		gpio_set_value(wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL1].gpio,
-			       1);
+		gpiod_set_value(wm1250->clk_sel0, 0);
+		gpiod_set_value(wm1250->clk_sel1, 1);
 		break;
 	case 32000:
-		gpio_set_value(wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL0].gpio,
-			       1);
-		gpio_set_value(wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL1].gpio,
-			       0);
+		gpiod_set_value(wm1250->clk_sel0, 1);
+		gpiod_set_value(wm1250->clk_sel1, 0);
 		break;
 	case 64000:
-		gpio_set_value(wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL0].gpio,
-			       0);
-		gpio_set_value(wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL1].gpio,
-			       0);
+		gpiod_set_value(wm1250->clk_sel0, 0);
+		gpiod_set_value(wm1250->clk_sel1, 0);
 		break;
 	default:
 		return -EINVAL;
@@ -150,45 +129,43 @@ static int wm1250_ev1_pdata(struct i2c_client *i2c)
 {
 	struct wm1250_ev1_pdata *pdata = dev_get_platdata(&i2c->dev);
 	struct wm1250_priv *wm1250;
-	int i, ret;
+	int ret;
 
 	if (!pdata)
 		return 0;
 
 	wm1250 = devm_kzalloc(&i2c->dev, sizeof(*wm1250), GFP_KERNEL);
-	if (!wm1250) {
-		ret = -ENOMEM;
-		goto err;
-	}
-
-	for (i = 0; i < ARRAY_SIZE(wm1250->gpios); i++) {
-		wm1250->gpios[i].gpio = pdata->gpios[i];
-		wm1250->gpios[i].label = wm1250_gpio_names[i];
-		wm1250->gpios[i].flags = GPIOF_OUT_INIT_LOW;
-	}
-	wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL0].flags = GPIOF_OUT_INIT_HIGH;
-	wm1250->gpios[WM1250_EV1_GPIO_CLK_SEL1].flags = GPIOF_OUT_INIT_HIGH;
-
-	ret = gpio_request_array(wm1250->gpios, ARRAY_SIZE(wm1250->gpios));
-	if (ret != 0) {
-		dev_err(&i2c->dev, "Failed to get GPIOs: %d\n", ret);
-		goto err;
-	}
+	if (!wm1250)
+		return -ENOMEM;
+
+	wm1250->clk_ena = devm_gpiod_get(&i2c->dev, "clk-ena", GPIOD_OUT_LOW);
+	if (IS_ERR(wm1250->clk_ena))
+		return dev_err_probe(&i2c->dev, PTR_ERR(wm1250->clk_ena),
+				     "failed to get clock enable GPIO\n");
+
+	wm1250->clk_sel0 = devm_gpiod_get(&i2c->dev, "clk-sel0", GPIOD_OUT_HIGH);
+	if (IS_ERR(wm1250->clk_sel0))
+		return dev_err_probe(&i2c->dev, PTR_ERR(wm1250->clk_sel0),
+				     "failed to get clock sel0 GPIO\n");
+
+	wm1250->clk_sel1 = devm_gpiod_get(&i2c->dev, "clk-sel1", GPIOD_OUT_HIGH);
+	if (IS_ERR(wm1250->clk_sel1))
+		return dev_err_probe(&i2c->dev, PTR_ERR(wm1250->clk_sel1),
+				     "failed to get clock sel1 GPIO\n");
+
+	wm1250->osr = devm_gpiod_get(&i2c->dev, "osr", GPIOD_OUT_LOW);
+	if (IS_ERR(wm1250->osr))
+		return dev_err_probe(&i2c->dev, PTR_ERR(wm1250->osr),
+				     "failed to get OSR GPIO\n");
+
+	wm1250->master = devm_gpiod_get(&i2c->dev, "master", GPIOD_OUT_LOW);
+	if (IS_ERR(wm1250->master))
+		return dev_err_probe(&i2c->dev, PTR_ERR(wm1250->master),
+				     "failed to get MASTER GPIO\n");
 
 	dev_set_drvdata(&i2c->dev, wm1250);
 
 	return ret;
-
-err:
-	return ret;
-}
-
-static void wm1250_ev1_free(struct i2c_client *i2c)
-{
-	struct wm1250_priv *wm1250 = dev_get_drvdata(&i2c->dev);
-
-	if (wm1250)
-		gpio_free_array(wm1250->gpios, ARRAY_SIZE(wm1250->gpios));
 }
 
 static int wm1250_ev1_probe(struct i2c_client *i2c)
@@ -221,18 +198,12 @@ static int wm1250_ev1_probe(struct i2c_client *i2c)
 				     &wm1250_ev1_dai, 1);
 	if (ret != 0) {
 		dev_err(&i2c->dev, "Failed to register CODEC: %d\n", ret);
-		wm1250_ev1_free(i2c);
 		return ret;
 	}
 
 	return 0;
 }
 
-static void wm1250_ev1_remove(struct i2c_client *i2c)
-{
-	wm1250_ev1_free(i2c);
-}
-
 static const struct i2c_device_id wm1250_ev1_i2c_id[] = {
 	{ "wm1250-ev1", 0 },
 	{ }
@@ -244,7 +215,6 @@ static struct i2c_driver wm1250_ev1_i2c_driver = {
 		.name = "wm1250-ev1",
 	},
 	.probe =    wm1250_ev1_probe,
-	.remove =   wm1250_ev1_remove,
 	.id_table = wm1250_ev1_i2c_id,
 };
 

-- 
2.34.1



From linus.walleij at linaro.org  Fri Dec  8 02:09:29 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 08 Dec 2023 11:09:29 +0100
Subject: [PATCH 5/5] ASoC: wm8996: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
Message-ID: <20231208-descriptors-sound-wlf-v1-5-c4dab6f521ec@linaro.org>

This converts the WM8996 codec to use GPIO descriptors, an a similar
way to WM5100.

The driver is instantiating a GPIO chip named wm8996, and we get
rid of the base address for the GPIO chip from the platform data and
just use dynamic numbering. Move base and ngpio into the static
gpio_chip template.

Fix up the only in-tree user which is the Cragganmore 6410 module.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-s3c/mach-crag6410-module.c | 14 ++++++--
 include/sound/wm8996.h                   |  3 --
 sound/soc/codecs/wm8996.c                | 58 ++++++++++++++------------------
 3 files changed, 36 insertions(+), 39 deletions(-)

diff --git a/arch/arm/mach-s3c/mach-crag6410-module.c b/arch/arm/mach-s3c/mach-crag6410-module.c
index 59456fbebf1b..2de1a89f6e99 100644
--- a/arch/arm/mach-s3c/mach-crag6410-module.c
+++ b/arch/arm/mach-s3c/mach-crag6410-module.c
@@ -127,9 +127,16 @@ static struct wm8996_retune_mobile_config wm8996_retune[] = {
 	},
 };
 
+static struct gpiod_lookup_table wm8996_gpiod_table = {
+	.dev_id = "1-001a", /* Device 001a on I2C bus 1 */
+	.table = {
+		GPIO_LOOKUP("GPION", 7,
+			    "wlf,ldo1ena", GPIO_ACTIVE_HIGH),
+		{ },
+	},
+};
+
 static struct wm8996_pdata wm8996_pdata __initdata = {
-	.ldo_ena = S3C64XX_GPN(7),
-	.gpio_base = CODEC_GPIO_BASE,
 	.micdet_def = 1,
 	.inl_mode = WM8996_DIFFERRENTIAL_1,
 	.inr_mode = WM8996_DIFFERRENTIAL_1,
@@ -370,7 +377,8 @@ static const struct {
 	  .spi_devs = balblair_devs,
 	  .num_spi_devs = ARRAY_SIZE(balblair_devs) },
 	{ .id = 0x39, .rev = 0xff, .name = "1254-EV1 Dallas Dhu",
-	  .i2c_devs = wm1254_devs, .num_i2c_devs = ARRAY_SIZE(wm1254_devs) },
+	  .i2c_devs = wm1254_devs, .num_i2c_devs = ARRAY_SIZE(wm1254_devs),
+	  .gpiod_table = &wm8996_gpiod_table },
 	{ .id = 0x3a, .rev = 0xff, .name = "1259-EV1 Tobermory",
 	  .i2c_devs = wm1259_devs, .num_i2c_devs = ARRAY_SIZE(wm1259_devs) },
 	{ .id = 0x3b, .rev = 0xff, .name = "1255-EV1 Kilchoman",
diff --git a/include/sound/wm8996.h b/include/sound/wm8996.h
index 247f9917e33d..342abeef288f 100644
--- a/include/sound/wm8996.h
+++ b/include/sound/wm8996.h
@@ -33,8 +33,6 @@ struct wm8996_retune_mobile_config {
 struct wm8996_pdata {
 	int irq_flags;  /** Set IRQ trigger flags; default active low */
 
-	int ldo_ena;  /** GPIO for LDO1; -1 for none */
-
 	int micdet_def;  /** Default MICDET_SRC/HP1FB_SRC/MICD_BIAS */
 
 	enum wm8996_inmode inl_mode;
@@ -42,7 +40,6 @@ struct wm8996_pdata {
 
 	u32 spkmute_seq;  /** Value for register 0x802 */
 
-	int gpio_base;
 	u32 gpio_default[5];
 
 	int num_retune_mobile_cfgs;
diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index df6195778c57..e738326e33ed 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -14,7 +14,7 @@
 #include <linux/pm.h>
 #include <linux/gcd.h>
 #include <linux/gpio/driver.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/i2c.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
@@ -51,7 +51,7 @@ struct wm8996_priv {
 	struct regmap *regmap;
 	struct snd_soc_component *component;
 
-	int ldo1ena;
+	struct gpio_desc *ldo_ena;
 
 	int sysclk;
 	int sysclk_src;
@@ -1596,9 +1596,9 @@ static int wm8996_set_bias_level(struct snd_soc_component *component,
 				return ret;
 			}
 
-			if (wm8996->pdata.ldo_ena >= 0) {
-				gpio_set_value_cansleep(wm8996->pdata.ldo_ena,
-							1);
+			if (wm8996->ldo_ena) {
+				gpiod_set_value_cansleep(wm8996->ldo_ena,
+							 1);
 				msleep(5);
 			}
 
@@ -1615,8 +1615,8 @@ static int wm8996_set_bias_level(struct snd_soc_component *component,
 
 	case SND_SOC_BIAS_OFF:
 		regcache_cache_only(wm8996->regmap, true);
-		if (wm8996->pdata.ldo_ena >= 0) {
-			gpio_set_value_cansleep(wm8996->pdata.ldo_ena, 0);
+		if (wm8996->ldo_ena) {
+			gpiod_set_value_cansleep(wm8996->ldo_ena, 0);
 			regcache_cache_only(wm8996->regmap, true);
 		}
 		regulator_bulk_disable(ARRAY_SIZE(wm8996->supplies),
@@ -2188,6 +2188,8 @@ static const struct gpio_chip wm8996_template_chip = {
 	.direction_input	= wm8996_gpio_direction_in,
 	.get			= wm8996_gpio_get,
 	.can_sleep		= 1,
+	.ngpio			= 5,
+	.base			= -1,
 };
 
 static void wm8996_init_gpio(struct wm8996_priv *wm8996)
@@ -2195,14 +2197,8 @@ static void wm8996_init_gpio(struct wm8996_priv *wm8996)
 	int ret;
 
 	wm8996->gpio_chip = wm8996_template_chip;
-	wm8996->gpio_chip.ngpio = 5;
 	wm8996->gpio_chip.parent = wm8996->dev;
 
-	if (wm8996->pdata.gpio_base)
-		wm8996->gpio_chip.base = wm8996->pdata.gpio_base;
-	else
-		wm8996->gpio_chip.base = -1;
-
 	ret = gpiochip_add_data(&wm8996->gpio_chip, wm8996);
 	if (ret != 0)
 		dev_err(wm8996->dev, "Failed to add GPIOs: %d\n", ret);
@@ -2771,15 +2767,15 @@ static int wm8996_i2c_probe(struct i2c_client *i2c)
 		memcpy(&wm8996->pdata, dev_get_platdata(&i2c->dev),
 		       sizeof(wm8996->pdata));
 
-	if (wm8996->pdata.ldo_ena > 0) {
-		ret = gpio_request_one(wm8996->pdata.ldo_ena,
-				       GPIOF_OUT_INIT_LOW, "WM8996 ENA");
-		if (ret < 0) {
-			dev_err(&i2c->dev, "Failed to request GPIO %d: %d\n",
-				wm8996->pdata.ldo_ena, ret);
-			goto err;
-		}
+	wm8996->ldo_ena = devm_gpiod_get_optional(&i2c->dev, "wlf,ldo1ena",
+						  GPIOD_OUT_LOW);
+	if (IS_ERR(wm8996->ldo_ena)) {
+		ret = PTR_ERR(wm8996->ldo_ena);
+		dev_err(&i2c->dev, "Failed to request LDO ENA GPIO: %d\n",
+			ret);
+		goto err;
 	}
+	gpiod_set_consumer_name(wm8996->ldo_ena, "WM8996 ENA");
 
 	for (i = 0; i < ARRAY_SIZE(wm8996->supplies); i++)
 		wm8996->supplies[i].supply = wm8996_supply_names[i];
@@ -2814,8 +2810,8 @@ static int wm8996_i2c_probe(struct i2c_client *i2c)
 		goto err_gpio;
 	}
 
-	if (wm8996->pdata.ldo_ena > 0) {
-		gpio_set_value_cansleep(wm8996->pdata.ldo_ena, 1);
+	if (wm8996->ldo_ena) {
+		gpiod_set_value_cansleep(wm8996->ldo_ena, 1);
 		msleep(5);
 	}
 
@@ -2847,8 +2843,8 @@ static int wm8996_i2c_probe(struct i2c_client *i2c)
 	dev_info(&i2c->dev, "revision %c\n",
 		 (reg & WM8996_CHIP_REV_MASK) + 'A');
 
-	if (wm8996->pdata.ldo_ena > 0) {
-		gpio_set_value_cansleep(wm8996->pdata.ldo_ena, 0);
+	if (wm8996->ldo_ena) {
+		gpiod_set_value_cansleep(wm8996->ldo_ena, 0);
 		regcache_cache_only(wm8996->regmap, true);
 	} else {
 		ret = regmap_write(wm8996->regmap, WM8996_SOFTWARE_RESET,
@@ -3054,12 +3050,10 @@ static int wm8996_i2c_probe(struct i2c_client *i2c)
 	wm8996_free_gpio(wm8996);
 err_regmap:
 err_enable:
-	if (wm8996->pdata.ldo_ena > 0)
-		gpio_set_value_cansleep(wm8996->pdata.ldo_ena, 0);
+	if (wm8996->ldo_ena)
+		gpiod_set_value_cansleep(wm8996->ldo_ena, 0);
 	regulator_bulk_disable(ARRAY_SIZE(wm8996->supplies), wm8996->supplies);
 err_gpio:
-	if (wm8996->pdata.ldo_ena > 0)
-		gpio_free(wm8996->pdata.ldo_ena);
 err:
 
 	return ret;
@@ -3070,10 +3064,8 @@ static void wm8996_i2c_remove(struct i2c_client *client)
 	struct wm8996_priv *wm8996 = i2c_get_clientdata(client);
 
 	wm8996_free_gpio(wm8996);
-	if (wm8996->pdata.ldo_ena > 0) {
-		gpio_set_value_cansleep(wm8996->pdata.ldo_ena, 0);
-		gpio_free(wm8996->pdata.ldo_ena);
-	}
+	if (wm8996->ldo_ena)
+		gpiod_set_value_cansleep(wm8996->ldo_ena, 0);
 }
 
 static const struct i2c_device_id wm8996_i2c_id[] = {

-- 
2.34.1



From l.stach at pengutronix.de  Fri Dec  8 02:16:23 2023
From: l.stach at pengutronix.de (Lucas Stach)
Date: Fri, 08 Dec 2023 11:16:23 +0100
Subject: [PATCH 1/4] PCI: imx6: Add pci host wakeup support on imx
 platforms.
In-Reply-To: <20231208091355.1417292-2-sherry.sun@nxp.com>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
	 <20231208091355.1417292-2-sherry.sun@nxp.com>
Message-ID: <0cd40cf388e70b101b3857220fd7a74cf75cfa81.camel@pengutronix.de>

Am Freitag, dem 08.12.2023 um 17:13 +0800 schrieb Sherry Sun:
> Add pci host wakeup feature for imx platforms.
> Example of configuring the corresponding dts property under the PCI
> node:
> host-wake-gpio = <&gpio5 21 GPIO_ACTIVE_LOW>;
> 
> Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
> Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 69 +++++++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 74703362aeec..050c9140f4a3 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -72,6 +72,7 @@ struct imx6_pcie_drvdata {
>  struct imx6_pcie {
>  	struct dw_pcie		*pci;
>  	int			reset_gpio;
> +	int			host_wake_irq;
>  	bool			gpio_active_high;
>  	bool			link_is_up;
>  	struct clk		*pcie_bus;
> @@ -1237,11 +1238,46 @@ static int imx6_pcie_resume_noirq(struct device *dev)
>  	return 0;
>  }
>  
> +static int imx6_pcie_suspend(struct device *dev)
> +{
> +	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> +
> +	if (imx6_pcie->host_wake_irq >= 0)
> +		enable_irq_wake(imx6_pcie->host_wake_irq);
> +
> +	return 0;
> +}
> +
> +static int imx6_pcie_resume(struct device *dev)
> +{
> +	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> +
> +	if (imx6_pcie->host_wake_irq >= 0)
> +		disable_irq_wake(imx6_pcie->host_wake_irq);
> +
> +	return 0;
> +}
> +
>  static const struct dev_pm_ops imx6_pcie_pm_ops = {
>  	NOIRQ_SYSTEM_SLEEP_PM_OPS(imx6_pcie_suspend_noirq,
>  				  imx6_pcie_resume_noirq)
> +	SYSTEM_SLEEP_PM_OPS(imx6_pcie_suspend, imx6_pcie_resume)
>  };
>  
> +irqreturn_t host_wake_irq_handler(int irq, void *priv)
> +{
> +	struct imx6_pcie *imx6_pcie = priv;
> +	struct device *dev = imx6_pcie->pci->dev;
> +
> +	dev_dbg(dev, "%s: host wakeup by pcie", __func__);
> +
Not sure how much value this debug print carries. If you want to keep
it, drop the __func__. There is no other place in this driver handling
the wakeup, so the function name in the print is pure noise.

> +	/* Notify PM core we are wakeup source */
> +	pm_wakeup_event(dev, 0);
> +	pm_system_wakeup();
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static int imx6_pcie_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -1250,6 +1286,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	struct device_node *np;
>  	struct resource *dbi_base;
>  	struct device_node *node = dev->of_node;
> +	struct gpio_desc *host_wake_gpio;
>  	int ret;
>  	u16 val;
>  
> @@ -1457,6 +1494,32 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  			val |= PCI_MSI_FLAGS_ENABLE;
>  			dw_pcie_writew_dbi(pci, offset + PCI_MSI_FLAGS, val);
>  		}
> +
> +		/* host wakeup support */
> +		imx6_pcie->host_wake_irq = -1;
> +		host_wake_gpio = devm_gpiod_get_optional(dev, "host-wake", GPIOD_IN);
> +		if (IS_ERR(host_wake_gpio))
> +			return PTR_ERR(host_wake_gpio);
> +
> +		if (host_wake_gpio != NULL) {
> +			imx6_pcie->host_wake_irq = gpiod_to_irq(host_wake_gpio);
> +			ret = devm_request_threaded_irq(dev, imx6_pcie->host_wake_irq, NULL,
> +							host_wake_irq_handler,
> +							IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
> +							"host_wake", imx6_pcie);
> +			if (ret) {
> +				dev_err(dev, "Failed to request host_wake_irq %d (%d)\n",
> +					imx6_pcie->host_wake_irq, ret);
> +				imx6_pcie->host_wake_irq = -1;

What's the point of resetting host_wake_irq to -1 in those error paths?
Nobody is going to access this member anymore after the error. Just
drop this.

You could simplify all those error paths to
if (err)
    return dev_err_probe(...);

> +				return ret;
> +			}
> +
> +			if (device_init_wakeup(dev, true)) {
> +				dev_err(dev, "fail to init host_wake_irq\n");
> +				imx6_pcie->host_wake_irq = -1;
> +				return ret;
> +			}
> +		}
>  	}
>  
>  	return 0;
> @@ -1466,6 +1529,12 @@ static void imx6_pcie_shutdown(struct platform_device *pdev)
>  {
>  	struct imx6_pcie *imx6_pcie = platform_get_drvdata(pdev);
>  
> +	if (imx6_pcie->host_wake_irq >= 0) {
> +		device_init_wakeup(&pdev->dev, false);
> +		disable_irq(imx6_pcie->host_wake_irq);
> +		imx6_pcie->host_wake_irq = -1;
> +	}
> +
>  	/* bring down link, so bootloader gets clean state in case of reboot */
>  	imx6_pcie_assert_core_reset(imx6_pcie);
>  }



From colin.i.king at gmail.com  Fri Dec  8 02:23:31 2023
From: colin.i.king at gmail.com (Colin Ian King)
Date: Fri,  8 Dec 2023 10:23:31 +0000
Subject: [PATCH][next] serial: ma35d1: Fix spelling mistake "ononsole" -> "console"
Message-ID: <20231208102331.3267192-1-colin.i.king@gmail.com>

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

Signed-off-by: Colin Ian King <colin.i.king at gmail.com>
---
 drivers/tty/serial/ma35d1_serial.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/ma35d1_serial.c b/drivers/tty/serial/ma35d1_serial.c
index b4dcbd0c95bf..19f0a305cc43 100644
--- a/drivers/tty/serial/ma35d1_serial.c
+++ b/drivers/tty/serial/ma35d1_serial.c
@@ -558,7 +558,7 @@ static void ma35d1serial_console_write(struct console *co, const char *s, u32 co
 	u32 ier;
 
 	if ((co->index < 0) || (co->index >= MA35_UART_NR)) {
-		pr_warn("Failed to write on ononsole port %x, out of range\n",
+		pr_warn("Failed to write on console port %x, out of range\n",
 			co->index);
 		return;
 	}
-- 
2.39.2



From leo.yan at linaro.org  Fri Dec  8 02:29:22 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 8 Dec 2023 18:29:22 +0800
Subject: [PATCH V2 1/5] perf mem: Add mem_events into the supported
 perf_pmu
In-Reply-To: <20231207192338.400336-2-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-2-kan.liang@linux.intel.com>
Message-ID: <20231208102922.GB769184@leoy-huanghe.lan>

On Thu, Dec 07, 2023 at 11:23:34AM -0800, kan.liang at linux.intel.com wrote:
> From: Kan Liang <kan.liang at linux.intel.com>
> 
> With the mem_events, perf doesn't need to read sysfs for each PMU to
> find the mem-events-supported PMU. The patch also makes it possible to
> clean up the related __weak functions later.
> 
> The patch is only to add the mem_events into the perf_pmu for all ARCHs.
> It will be used in the later cleanup patches.
> 
> Reviewed-by: Ian Rogers <irogers at google.com>
> Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
> ---
>  tools/perf/arch/arm64/util/mem-events.c | 4 ++--
>  tools/perf/arch/arm64/util/mem-events.h | 7 +++++++
>  tools/perf/arch/arm64/util/pmu.c        | 6 ++++++
>  tools/perf/arch/s390/util/pmu.c         | 3 +++
>  tools/perf/arch/x86/util/mem-events.c   | 4 ++--
>  tools/perf/arch/x86/util/mem-events.h   | 9 +++++++++
>  tools/perf/arch/x86/util/pmu.c          | 7 +++++++
>  tools/perf/util/mem-events.c            | 2 +-
>  tools/perf/util/mem-events.h            | 1 +
>  tools/perf/util/pmu.c                   | 4 +++-
>  tools/perf/util/pmu.h                   | 7 +++++++
>  11 files changed, 48 insertions(+), 6 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/mem-events.h
>  create mode 100644 tools/perf/arch/x86/util/mem-events.h
> 
> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
> index 3bcc5c7035c2..aaa4804922b4 100644
> --- a/tools/perf/arch/arm64/util/mem-events.c
> +++ b/tools/perf/arch/arm64/util/mem-events.c
> @@ -4,7 +4,7 @@
>  
>  #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>  
> -static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
> +struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
>  	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
>  	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
>  	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
> @@ -17,7 +17,7 @@ struct perf_mem_event *perf_mem_events__ptr(int i)
>  	if (i >= PERF_MEM_EVENTS__MAX)
>  		return NULL;
>  
> -	return &perf_mem_events[i];
> +	return &perf_mem_events_arm[i];

I recognized that it's hard code to "arm_spe_0", which might break if
system registers different Arm SPE groups.  But this is not the issue
introduced by this patch, we might need to consider to fix it later.

>  }
>  
>  const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
> diff --git a/tools/perf/arch/arm64/util/mem-events.h b/tools/perf/arch/arm64/util/mem-events.h
> new file mode 100644
> index 000000000000..5fc50be4be38
> --- /dev/null
> +++ b/tools/perf/arch/arm64/util/mem-events.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ARM64_MEM_EVENTS_H
> +#define _ARM64_MEM_EVENTS_H
> +
> +extern struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX];
> +
> +#endif /* _ARM64_MEM_EVENTS_H */
> diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
> index 2a4eab2d160e..06ec9b838807 100644
> --- a/tools/perf/arch/arm64/util/pmu.c
> +++ b/tools/perf/arch/arm64/util/pmu.c
> @@ -8,6 +8,12 @@
>  #include <api/fs/fs.h>
>  #include <math.h>
>  
> +void perf_pmu__arch_init(struct perf_pmu *pmu)
> +{
> +	if (!strcmp(pmu->name, "arm_spe_0"))
> +		pmu->mem_events = perf_mem_events_arm;

This is not right and it should cause building failure on aarch64.

aarch64 reuses aarch32's file arch/arm/util/pmu.c, and this file has
already defined perf_pmu__arch_init(), you should add above change in
the file arch/arm/util/pmu.c.

Now I cannot access a machine for testing Arm SPE, but I will play
a bit for this patch set to ensure it can pass compilation.  After
that, I will seek Arm maintainers/reviewers help for the test.

Thanks,
Leo


From anders.roxell at linaro.org  Fri Dec  8 02:33:32 2023
From: anders.roxell at linaro.org (Anders Roxell)
Date: Fri,  8 Dec 2023 11:33:32 +0100
Subject: [PATCH] drivers: acpi: arm64: thermal_cpufreq: export module
Message-ID: <20231208103332.2829631-1-anders.roxell@linaro.org>

The following build error shows up when building an allmodconfig kernel
on arch=arm64:

ERROR: modpost: "acpi_arch_thermal_cpufreq_pctg" [drivers/acpi/processor.ko] undefined!
make[3]: *** [/next/scripts/Makefile.modpost:145: Module.symvers] Error 1
make[3]: Target '__modpost' not remade because of errors.
make[2]: *** [/tmp/next/Makefile:1876: modpost] Error 2
make[2]: Target '__all' not remade because of errors.
make[1]: *** [/tmp/next/Makefile:243: __sub-make] Error 2
make[1]: Target '__all' not remade because of errors.
make: *** [Makefile:243: __sub-make] Error 2
make: Target '__all' not remade because of errors.

Solve the issue by export acpi_arch_thermal_cpufreq_pctg() since the
function are used in function 'acpi_thermal_cpufreq_config()'.

Fixes: a02f66bb3cf4 ("ACPI: Move ACPI_HOTPLUG_CPU to be disabled on arm64 and riscv")
Suggested-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Anders Roxell <anders.roxell at linaro.org>
---
 drivers/acpi/arm64/thermal_cpufreq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/acpi/arm64/thermal_cpufreq.c b/drivers/acpi/arm64/thermal_cpufreq.c
index d524f2cd6044..582854914c5c 100644
--- a/drivers/acpi/arm64/thermal_cpufreq.c
+++ b/drivers/acpi/arm64/thermal_cpufreq.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 #include <linux/acpi.h>
+#include <linux/export.h>
 
 #include "../internal.h"
 
@@ -18,3 +19,4 @@ int acpi_arch_thermal_cpufreq_pctg(void)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(acpi_arch_thermal_cpufreq_pctg);
-- 
2.42.0



From srinivas.kandagatla at linaro.org  Fri Dec  8 02:59:51 2023
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri, 08 Dec 2023 10:59:51 +0000
Subject: [PATCH v3] dt-bindings: nvmem: mxs-ocotp: Document fsl,ocotp
In-Reply-To: <20231207101659.2496154-1-festevam@gmail.com>
References: <20231207101659.2496154-1-festevam@gmail.com>
Message-ID: <170203319147.19447.10192597758196822617.b4-ty@linaro.org>


On Thu, 07 Dec 2023 07:16:59 -0300, Fabio Estevam wrote:
> Both imx23.dtsi and imx28.dtsi describe the OCOTP nodes in
> the format:
> 
> compatible = "fsl,imx28-ocotp", "fsl,ocotp";
> 
> Document the "fsl,ocotp" entry to fix the following schema
> warning:
> 
> [...]

Applied, thanks!

[1/1] dt-bindings: nvmem: mxs-ocotp: Document fsl,ocotp
      commit: 46a8c57f38fd50b26c74c2663fc9262668d364f6

Best regards,
-- 
Srinivas Kandagatla <srinivas.kandagatla at linaro.org>



From srinivas.kandagatla at linaro.org  Fri Dec  8 03:03:07 2023
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri, 08 Dec 2023 11:03:07 +0000
Subject: (subset) [PATCH 0/4] stm32: add support for STM32MP25 BSEC to
 control OTP data
In-Reply-To: <20231117143338.1173475-1-patrick.delaunay@foss.st.com>
References: <20231117143338.1173475-1-patrick.delaunay@foss.st.com>
Message-ID: <170203338747.19730.10941929995611139048.b4-ty@linaro.org>


On Fri, 17 Nov 2023 15:33:33 +0100, Patrick Delaunay wrote:
> Non volatile memory area is available on STM32MP25 with OTP in BSEC.
> 
> The 12 Kbits of OTP (effective) for STM32MP25x SoC Family
> are organized into the following regions:
> - lower OTP (OTP0 to OTP127) = 4096 lower OTP bits,
>   bitwise (1-bit) programmable
> - mid OTP (OTP128 to OTP255) = 4096 middle OTP bits,
>   bulk (32-bit) programmable
> - upper OTP (OTP256 to OTP383) = 4096 upper OTP bits,
>   bulk (32-bit) programmable,
>   only accessible when BSEC is in closed state.
> 
> [...]

Applied, thanks!

[1/4] dt-bindings: nvmem: add new stm32mp25 compatible for stm32-romem
      commit: d062d18d0e30e46e88a3b0f9fb2549393b7d7adf
[2/4] nvmem: stm32: add support for STM32MP25 BSEC to control OTP data
      commit: 2015e5f4d01fb76fca69047f870035e214d6d2d0

Best regards,
-- 
Srinivas Kandagatla <srinivas.kandagatla at linaro.org>



From heiko at sntech.de  Fri Dec  8 03:05:36 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Fri, 08 Dec 2023 12:05:36 +0100
Subject: [PATCH v2] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
In-Reply-To: <20231208062510.893392-1-CFSworks@gmail.com>
References: <20231208062510.893392-1-CFSworks@gmail.com>
Message-ID: <6311244.MhkbZ0Pkbq@diego>

Hi Sam,

Am Freitag, 8. Dezember 2023, 07:25:10 CET schrieb Sam Edwards:
> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
> will sometimes (varying between specific RK3588 chips, not over time) shut
> off the DBI block, and reads to this range will instead stall
> indefinitely.
> 
> When this happens, it will prevent Linux from booting altogether. The
> PCIe driver will stall the CPU core once it attempts to read the version
> information from the DBI range.
> 
> Fix this boot hang by adding the correct pinctrl configuration to the
> PCIe 3.0 device node, which is the proper thing to do anyway. While
> we're at it, also add the necessary configuration to the PCIe 2.0 node,
> which may or may not fix the equivalent problem over there -- but is the
> proper thing to do anyway. :)
> 
> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
> Signed-off-by: Sam Edwards <CFSworks at gmail.com>
> ---
> 
> Hi list,
> 
> Compared to v1, v2 removes the `reset-gpios` properties as well -- this should
> give control of the PCIe resets exclusively to the PCIe cores. (And even if the
> `reset-gpios` props had no effect in v1, it'd be confusing to have them there.)

Hmm, I'd think this could result in differing behaviour.

I.e. I tried the same on a different board with a nvme drive on the pci30x4
controller. But moving the reset from the gpio-way to "just" setting the
perstn pinctrl, simply hung the controller when probing the device.

So I guess I'd think the best way would be to split the pinctrl up into the
3 separate functions (clkreqn, perstn, waken) so that boards can include
them individually.

Nobody is using the controller pinctrl entries so far anyway :-) .


Heiko


> Note that it is OK for the pcie2x1l1 node to refer to pcie30x1m1_pins. The
> pcie2x1l1 device is *in fact* a PCIe 3.0 controller, and the pcie30x1m1_pins
> pinmux setting is so-named to reflect this. The pcie2x1l1 node is so-named
> because Linux does not (currently) support routing it to a PCIe 3.0 PHY; so in
> practice it is effectively a PCIe 2.0 controller, for the time being.
> 
> Cheers and thank you for your time,
> Sam
> 
> ---
>  .../boot/dts/rockchip/rk3588-turing-rk1.dtsi     | 16 ++--------------
>  1 file changed, 2 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> index 9570b34aca2e..875446fdb67e 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
> @@ -214,8 +214,7 @@ rgmii_phy: ethernet-phy at 1 {
>  &pcie2x1l1 {
>  	linux,pci-domain = <1>;
>  	pinctrl-names = "default";
> -	pinctrl-0 = <&pcie2_reset>;
> -	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
> +	pinctrl-0 = <&pcie30x1m1_pins>;
>  	status = "okay";
>  };
>  
> @@ -226,8 +225,7 @@ &pcie30phy {
>  &pcie3x4 {
>  	linux,pci-domain = <0>;
>  	pinctrl-names = "default";
> -	pinctrl-0 = <&pcie3_reset>;
> -	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
> +	pinctrl-0 = <&pcie30x4m1_pins>;
>  	vpcie3v3-supply = <&vcc3v3_pcie30>;
>  	status = "okay";
>  };
> @@ -245,17 +243,7 @@ hym8563_int: hym8563-int {
>  		};
>  	};
>  
> -	pcie2 {
> -		pcie2_reset: pcie2-reset {
> -			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
> -		};
> -	};
> -
>  	pcie3 {
> -		pcie3_reset: pcie3-reset {
> -			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
> -		};
> -
>  		vcc3v3_pcie30_en: pcie3-reg {
>  			rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
>  		};
> 






From srinivas.kandagatla at linaro.org  Fri Dec  8 03:15:24 2023
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri, 8 Dec 2023 11:15:24 +0000
Subject: [PATCH V3] nvmem: brcm_nvram: store a copy of NVRAM content
In-Reply-To: <20231102062848.23965-1-zajec5@gmail.com>
References: <20231102062848.23965-1-zajec5@gmail.com>
Message-ID: <29d2f463-90c2-4c96-8828-96806679db8e@linaro.org>

Thank you for the patch,

On 02/11/2023 06:28, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> This driver uses MMIO access for reading NVRAM from a flash device.
> Underneath there is a flash controller that reads data and provides
> mapping window.
> 
> Using MMIO interface affects controller configuration and may break real
> controller driver. It was reported by multiple users of devices with
> NVRAM stored on NAND.
> 
> Modify driver to read & cache NVRAM content during init and use that
> copy to provide NVMEM data when requested. On NAND flashes due to their
> alignment NVRAM partitions can be quite big (1 MiB and more) while
> actual NVRAM content stays quite small (usually 16 to 32 KiB). To avoid
> allocating so much memory check for actual data length.
> 
> Link: https://lore.kernel.org/linux-mtd/CACna6rwf3_9QVjYcM+847biTX=K0EoWXuXcSMkJO1Vy_5vmVqA at mail.gmail.com/
> Fixes: 3fef9ed0627a ("nvmem: brcm_nvram: new driver exposing Broadcom's NVRAM")

Any reason not to add
Cc: <Stable at vger.kernel.org>
?

--srini
> Cc: Ar?n? ?NAL <arinc.unal at arinc9.com>
> Cc: Florian Fainelli <florian.fainelli at broadcom.com>
> Cc: Scott Branden <scott.branden at broadcom.com>
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> Acked-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
> ---
> V2: Minialize amount of allocated memory (check for actual data length)
> V3: Document missed fields in struct brcm_nvram
> 
>   drivers/nvmem/brcm_nvram.c | 134 ++++++++++++++++++++++++++-----------
>   1 file changed, 94 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/nvmem/brcm_nvram.c b/drivers/nvmem/brcm_nvram.c
> index 9737104f3b76..5cdf339cfbec 100644
> --- a/drivers/nvmem/brcm_nvram.c
> +++ b/drivers/nvmem/brcm_nvram.c
> @@ -17,9 +17,23 @@
>   
>   #define NVRAM_MAGIC			"FLSH"
>   
> +/**
> + * struct brcm_nvram - driver state internal struct
> + *
> + * @dev:		NVMEM device pointer
> + * @nvmem_size:		Size of the whole space available for NVRAM
> + * @data:		NVRAM data copy stored to avoid poking underlaying flash controller
> + * @data_len:		NVRAM data size
> + * @padding_byte:	Padding value used to fill remaining space
> + * @cells:		Array of discovered NVMEM cells
> + * @ncells:		Number of elements in cells
> + */
>   struct brcm_nvram {
>   	struct device *dev;
> -	void __iomem *base;
> +	size_t nvmem_size;
> +	uint8_t *data;
> +	size_t data_len;
> +	uint8_t padding_byte;
>   	struct nvmem_cell_info *cells;
>   	int ncells;
>   };
> @@ -36,10 +50,47 @@ static int brcm_nvram_read(void *context, unsigned int offset, void *val,
>   			   size_t bytes)
>   {
>   	struct brcm_nvram *priv = context;
> -	u8 *dst = val;
> +	size_t to_copy;
> +
> +	if (offset + bytes > priv->data_len)
> +		to_copy = max_t(ssize_t, (ssize_t)priv->data_len - offset, 0);
> +	else
> +		to_copy = bytes;
> +
> +	memcpy(val, priv->data + offset, to_copy);
> +
> +	memset((uint8_t *)val + to_copy, priv->padding_byte, bytes - to_copy);
> +
> +	return 0;
> +}
> +
> +static int brcm_nvram_copy_data(struct brcm_nvram *priv, struct platform_device *pdev)
> +{
> +	struct resource *res;
> +	void __iomem *base;
> +
> +	base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	priv->nvmem_size = resource_size(res);
> +
> +	priv->padding_byte = readb(base + priv->nvmem_size - 1);
> +	for (priv->data_len = priv->nvmem_size;
> +	     priv->data_len;
> +	     priv->data_len--) {
> +		if (readb(base + priv->data_len - 1) != priv->padding_byte)
> +			break;
> +	}
> +	WARN(priv->data_len > SZ_128K, "Unexpected (big) NVRAM size: %zu B\n", priv->data_len);
> +
> +	priv->data = devm_kzalloc(priv->dev, priv->data_len, GFP_KERNEL);
> +	if (!priv->data)
> +		return -ENOMEM;
> +
> +	memcpy_fromio(priv->data, base, priv->data_len);
>   
> -	while (bytes--)
> -		*dst++ = readb(priv->base + offset++);
> +	bcm47xx_nvram_init_from_iomem(base, priv->data_len);
>   
>   	return 0;
>   }
> @@ -67,8 +118,13 @@ static int brcm_nvram_add_cells(struct brcm_nvram *priv, uint8_t *data,
>   				size_t len)
>   {
>   	struct device *dev = priv->dev;
> -	char *var, *value, *eq;
> +	char *var, *value;
> +	uint8_t tmp;
>   	int idx;
> +	int err = 0;
> +
> +	tmp = priv->data[len - 1];
> +	priv->data[len - 1] = '\0';
>   
>   	priv->ncells = 0;
>   	for (var = data + sizeof(struct brcm_nvram_header);
> @@ -78,67 +134,68 @@ static int brcm_nvram_add_cells(struct brcm_nvram *priv, uint8_t *data,
>   	}
>   
>   	priv->cells = devm_kcalloc(dev, priv->ncells, sizeof(*priv->cells), GFP_KERNEL);
> -	if (!priv->cells)
> -		return -ENOMEM;
> +	if (!priv->cells) {
> +		err = -ENOMEM;
> +		goto out;
> +	}
>   
>   	for (var = data + sizeof(struct brcm_nvram_header), idx = 0;
>   	     var < (char *)data + len && *var;
>   	     var = value + strlen(value) + 1, idx++) {
> +		char *eq, *name;
> +
>   		eq = strchr(var, '=');
>   		if (!eq)
>   			break;
>   		*eq = '\0';
> +		name = devm_kstrdup(dev, var, GFP_KERNEL);
> +		*eq = '=';
> +		if (!name) {
> +			err = -ENOMEM;
> +			goto out;
> +		}
>   		value = eq + 1;
>   
> -		priv->cells[idx].name = devm_kstrdup(dev, var, GFP_KERNEL);
> -		if (!priv->cells[idx].name)
> -			return -ENOMEM;
> +		priv->cells[idx].name = name;
>   		priv->cells[idx].offset = value - (char *)data;
>   		priv->cells[idx].bytes = strlen(value);
>   		priv->cells[idx].np = of_get_child_by_name(dev->of_node, priv->cells[idx].name);
> -		if (!strcmp(var, "et0macaddr") ||
> -		    !strcmp(var, "et1macaddr") ||
> -		    !strcmp(var, "et2macaddr")) {
> +		if (!strcmp(name, "et0macaddr") ||
> +		    !strcmp(name, "et1macaddr") ||
> +		    !strcmp(name, "et2macaddr")) {
>   			priv->cells[idx].raw_len = strlen(value);
>   			priv->cells[idx].bytes = ETH_ALEN;
>   			priv->cells[idx].read_post_process = brcm_nvram_read_post_process_macaddr;
>   		}
>   	}
>   
> -	return 0;
> +out:
> +	priv->data[len - 1] = tmp;
> +	return err;
>   }
>   
>   static int brcm_nvram_parse(struct brcm_nvram *priv)
>   {
> +	struct brcm_nvram_header *header = (struct brcm_nvram_header *)priv->data;
>   	struct device *dev = priv->dev;
> -	struct brcm_nvram_header header;
> -	uint8_t *data;
>   	size_t len;
>   	int err;
>   
> -	memcpy_fromio(&header, priv->base, sizeof(header));
> -
> -	if (memcmp(header.magic, NVRAM_MAGIC, 4)) {
> +	if (memcmp(header->magic, NVRAM_MAGIC, 4)) {
>   		dev_err(dev, "Invalid NVRAM magic\n");
>   		return -EINVAL;
>   	}
>   
> -	len = le32_to_cpu(header.len);
> -
> -	data = kzalloc(len, GFP_KERNEL);
> -	if (!data)
> -		return -ENOMEM;
> -
> -	memcpy_fromio(data, priv->base, len);
> -	data[len - 1] = '\0';
> -
> -	err = brcm_nvram_add_cells(priv, data, len);
> -	if (err) {
> -		dev_err(dev, "Failed to add cells: %d\n", err);
> -		return err;
> +	len = le32_to_cpu(header->len);
> +	if (len > priv->nvmem_size) {
> +		dev_err(dev, "NVRAM length (%zd) exceeds mapped size (%zd)\n", len,
> +			priv->nvmem_size);
> +		return -EINVAL;
>   	}
>   
> -	kfree(data);
> +	err = brcm_nvram_add_cells(priv, priv->data, len);
> +	if (err)
> +		dev_err(dev, "Failed to add cells: %d\n", err);
>   
>   	return 0;
>   }
> @@ -150,7 +207,6 @@ static int brcm_nvram_probe(struct platform_device *pdev)
>   		.reg_read = brcm_nvram_read,
>   	};
>   	struct device *dev = &pdev->dev;
> -	struct resource *res;
>   	struct brcm_nvram *priv;
>   	int err;
>   
> @@ -159,21 +215,19 @@ static int brcm_nvram_probe(struct platform_device *pdev)
>   		return -ENOMEM;
>   	priv->dev = dev;
>   
> -	priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> -	if (IS_ERR(priv->base))
> -		return PTR_ERR(priv->base);
> +	err = brcm_nvram_copy_data(priv, pdev);
> +	if (err)
> +		return err;
>   
>   	err = brcm_nvram_parse(priv);
>   	if (err)
>   		return err;
>   
> -	bcm47xx_nvram_init_from_iomem(priv->base, resource_size(res));
> -
>   	config.dev = dev;
>   	config.cells = priv->cells;
>   	config.ncells = priv->ncells;
>   	config.priv = priv;
> -	config.size = resource_size(res);
> +	config.size = priv->nvmem_size;
>   
>   	return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &config));
>   }


From hnagalla at ti.com  Fri Dec  8 03:21:42 2023
From: hnagalla at ti.com (Hari Nagalla)
Date: Fri, 8 Dec 2023 05:21:42 -0600
Subject: [PATCH v3 3/5] remoteproc: k3-r5: Add support for IPC-only mode
 for all R5Fs
In-Reply-To: <106f3a36-16d8-4272-ad7a-287e6a3acfb5@siemens.com>
References: <20220213201246.25952-1-s-anna@ti.com>
 <20220213201246.25952-4-s-anna@ti.com>
 <e0bc7eb5-f1b9-4e99-a39f-ca6f31daa9d8@siemens.com> <ZUPDrlVLkDDgJpWm@p14s>
 <106f3a36-16d8-4272-ad7a-287e6a3acfb5@siemens.com>
Message-ID: <d582b9fa-a2bf-c522-278d-58ddf9353be8@ti.com>

On 11/2/23 11:43, Jan Kiszka wrote:
>>> RTI1 watchdog also powers up R5F core 1. And this could happen either in
>> When writing "... also powers up...", other than R5F core 1, what else is being
>> powered?
> Would be a question for the SoC vendor - I assumed that only mcu_rti1
> [1] goes on when enabling it. But also mcu_r5fss0_core1 is enabled after
> that, at least according to the respective TI-SCI query that the is_on
> handler is performing. I've tested that under Linux and in U-Boot.
> 
As described in section 12.5.2.1 of AM64x TRM 
(https://www.ti.com/lit/pdf/SPRUIM2) -There is a RTI for each CPU core. 
And it is not intended to be use RTI provisioned for a particular CPU 
core with a different core.
And also as shown in section (5.2.2.2.1.3.1) the CPU core and 
corresponding RTI share the same power sub module (LPSC), so enabling 
one powers on the other.

As Suman suggested, it seems more appropriate to enable the RTI watchdog 
timers in the remoteproc driver. Legacy omap remoteproc drivers have 
this support and needs to be extended to k3 remoteproc drivers.
Another option could be to DEFER RTI probe until corresponding 
remoteproc driver is probed.

Any other solutions to maintain this order of enabling remote core and 
the corresponding RTI/WDT?


From rafal at milecki.pl  Fri Dec  8 03:25:07 2023
From: rafal at milecki.pl (=?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?=)
Date: Fri, 08 Dec 2023 12:25:07 +0100
Subject: [PATCH V3] nvmem: brcm_nvram: store a copy of NVRAM content
In-Reply-To: <29d2f463-90c2-4c96-8828-96806679db8e@linaro.org>
References: <20231102062848.23965-1-zajec5@gmail.com>
 <29d2f463-90c2-4c96-8828-96806679db8e@linaro.org>
Message-ID: <7cb70a8ead5f6b74f0a287ac8832873c@milecki.pl>

On 2023-12-08 12:15, Srinivas Kandagatla wrote:
> Thank you for the patch,
> 
> On 02/11/2023 06:28, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>> 
>> This driver uses MMIO access for reading NVRAM from a flash device.
>> Underneath there is a flash controller that reads data and provides
>> mapping window.
>> 
>> Using MMIO interface affects controller configuration and may break 
>> real
>> controller driver. It was reported by multiple users of devices with
>> NVRAM stored on NAND.
>> 
>> Modify driver to read & cache NVRAM content during init and use that
>> copy to provide NVMEM data when requested. On NAND flashes due to 
>> their
>> alignment NVRAM partitions can be quite big (1 MiB and more) while
>> actual NVRAM content stays quite small (usually 16 to 32 KiB). To 
>> avoid
>> allocating so much memory check for actual data length.
>> 
>> Link: 
>> https://lore.kernel.org/linux-mtd/CACna6rwf3_9QVjYcM+847biTX=K0EoWXuXcSMkJO1Vy_5vmVqA at mail.gmail.com/
>> Fixes: 3fef9ed0627a ("nvmem: brcm_nvram: new driver exposing 
>> Broadcom's NVRAM")
> 
> Any reason not to add
> Cc: <Stable at vger.kernel.org>
> ?

Not really. I believe stable team would pick this fix anyway (thanks to
the Fixes:) but doing
Cc: stable at vger.kernel.org
is described as strongly preferred.

Do you think you can just ammend my patch while applying it and add
Cc: stable at vger.kernel.org
to it?

-- 
Rafa? Mi?ecki


From srinivas.kandagatla at linaro.org  Fri Dec  8 03:26:00 2023
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri, 8 Dec 2023 11:26:00 +0000
Subject: [PATCH V3] nvmem: brcm_nvram: store a copy of NVRAM content
In-Reply-To: <7cb70a8ead5f6b74f0a287ac8832873c@milecki.pl>
References: <20231102062848.23965-1-zajec5@gmail.com>
 <29d2f463-90c2-4c96-8828-96806679db8e@linaro.org>
 <7cb70a8ead5f6b74f0a287ac8832873c@milecki.pl>
Message-ID: <28ece7fb-53a9-48d3-9e40-0ef06d5821ce@linaro.org>



On 08/12/2023 11:25, Rafa? Mi?ecki wrote:
> On 2023-12-08 12:15, Srinivas Kandagatla wrote:
>> Thank you for the patch,
>>
>> On 02/11/2023 06:28, Rafa? Mi?ecki wrote:
>>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>>
>>> This driver uses MMIO access for reading NVRAM from a flash device.
>>> Underneath there is a flash controller that reads data and provides
>>> mapping window.
>>>
>>> Using MMIO interface affects controller configuration and may break real
>>> controller driver. It was reported by multiple users of devices with
>>> NVRAM stored on NAND.
>>>
>>> Modify driver to read & cache NVRAM content during init and use that
>>> copy to provide NVMEM data when requested. On NAND flashes due to their
>>> alignment NVRAM partitions can be quite big (1 MiB and more) while
>>> actual NVRAM content stays quite small (usually 16 to 32 KiB). To avoid
>>> allocating so much memory check for actual data length.
>>>
>>> Link: 
>>> https://lore.kernel.org/linux-mtd/CACna6rwf3_9QVjYcM+847biTX=K0EoWXuXcSMkJO1Vy_5vmVqA at mail.gmail.com/
>>> Fixes: 3fef9ed0627a ("nvmem: brcm_nvram: new driver exposing 
>>> Broadcom's NVRAM")
>>
>> Any reason not to add
>> Cc: <Stable at vger.kernel.org>
>> ?
> 
> Not really. I believe stable team would pick this fix anyway (thanks to
> the Fixes:) but doing
> Cc: stable at vger.kernel.org
> is described as strongly preferred.
> 
> Do you think you can just ammend my patch while applying it and add
> Cc: stable at vger.kernel.org
> to it?
Will do.

--srini
> 


From ardb at google.com  Fri Dec  8 03:32:19 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Fri,  8 Dec 2023 12:32:19 +0100
Subject: [PATCH v4 0/4] arm64: Run kernel mode NEON with preemption enabled
Message-ID: <20231208113218.3001940-6-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

Currently, kernel mode NEON (SIMD) support is implemented in a way that
requires preemption to be disabled while the SIMD registers are live.
The reason for this is that those registers are not in the set that is
preserved/restored on exception entry/exit and context switch, as this
would impact performance generally, even for workloads where kernel mode
SIMD is not the bottleneck.

However, doing substantial work with preemption disabled is not great,
as it affects scheduling latency, which is especially problematic for
real-time use cases. So ideally, we should keep preemption enabled when
we can, and find another way to ensure that this does not corrupt the
NEON register state of in-kernel SIMD users.

This series implements a suggestion by Mark Rutland, and introduces a
thread_info flag TIF_KERNEL_FPSTATE, which indicates to the thread
switch machinery that the task in question has live kernel mode SIMD
state which needs to be preserved and restored. The space needed for
this is allocated in thread_struct. (*)

Given that currently, we run kernel mode NEON with softirqs disabled (to
avoid the need for preserving kernel mode NEON context belonging to task
context while the SIMD unit is being used by code running in softirq
context), just removing the preempt_disable/enable calls is not
sufficient, and we also need to leave softirqs enabled. This means that
we may need to preserve kernel mode NEON state not only on a context
switch, but also when code running in softirq context takes ownership of
the SIMD unit, but this is straight-forward once we add the scratch
space to thread_struct. (On PREEMPT_RT, softirqs execute with preemption
enabled, making kernel mode FPSIMD in softirq context preemptible as
well. We rely on the fact that the task that hosts the softirq dispatch
logic does not itself use kernel mode FPSIMD in task context to ensure
that there is only a single kernel mode FPSIMD state that may need to be
preserved and restored.)

(*) We might decide to allocate this space (~512 bytes) dynamically, if
the thread_struct memory footprint causes issues. However, we should
also explore doing the same for the user space FPSIMD state, as kernel
threads never return to user space and have no need for this allocation.

v4:
- for the time being, make the existing yield logic depend on
  CONFIG_PREEMPT_VOLUNTARY, so it can be retired once the prerequisite
  core preempt changes (which remove CONFIG_PREEMPT_VOLUNTARY) have been
  merged [0]
- incorporate feedback from Mark Rutland and include his acks

v3:
- add patch to drop yield logic from crypto C glue code
- add R-b from Mark

v2:
- tweak some commit logs for clarity
- integrate with the existing lazy restore logic
- add Mark's R-b to patch #1

[0] https://lore.kernel.org/lkml/20231107215742.363031-1-ankur.a.arora at oracle.com/

Cc: Marc Zyngier <maz at kernel.org>
Cc: Will Deacon <will at kernel.org>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Kees Cook <keescook at chromium.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Mark Brown <broonie at kernel.org>
Cc: Eric Biggers <ebiggers at google.com>
Cc: Sebastian Andrzej Siewior <bigeasy at linutronix.de>

Ard Biesheuvel (4):
  arm64: fpsimd: Drop unneeded 'busy' flag
  arm64: fpsimd: Preserve/restore kernel mode NEON at context switch
  arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD
  arm64: crypto: Disable yielding logic unless
    CONFIG_PREEMPT_VOLUNTARY=y

 arch/arm64/crypto/aes-ce-ccm-glue.c      |   8 +-
 arch/arm64/crypto/chacha-neon-glue.c     |   5 +-
 arch/arm64/crypto/crct10dif-ce-glue.c    |   6 +-
 arch/arm64/crypto/nhpoly1305-neon-glue.c |   5 +-
 arch/arm64/crypto/poly1305-glue.c        |   5 +-
 arch/arm64/crypto/polyval-ce-glue.c      |   9 +-
 arch/arm64/include/asm/assembler.h       |   4 +-
 arch/arm64/include/asm/processor.h       |   3 +
 arch/arm64/include/asm/simd.h            |  11 +-
 arch/arm64/include/asm/thread_info.h     |   1 +
 arch/arm64/kernel/fpsimd.c               | 163 +++++++++++++-------
 11 files changed, 140 insertions(+), 80 deletions(-)

-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Fri Dec  8 03:32:20 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Fri,  8 Dec 2023 12:32:20 +0100
Subject: [PATCH v4 1/4] arm64: fpsimd: Drop unneeded 'busy' flag
In-Reply-To: <20231208113218.3001940-6-ardb@google.com>
References: <20231208113218.3001940-6-ardb@google.com>
Message-ID: <20231208113218.3001940-7-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

Kernel mode NEON will preserve the user mode FPSIMD state by saving it
into the task struct before clobbering the registers. In order to avoid
the need for preserving kernel mode state too, we disallow nested use of
kernel mode NEON, i..e, use in softirq context while the interrupted
task context was using kernel mode NEON too.

Originally, this policy was implemented using a per-CPU flag which was
exposed via may_use_simd(), requiring the users of the kernel mode NEON
to deal with the possibility that it might return false, and having NEON
and non-NEON code paths. This policy was changed by commit
13150149aa6ded1 ("arm64: fpsimd: run kernel mode NEON with softirqs
disabled"), and now, softirq processing is disabled entirely instead,
and so may_use_simd() can never fail when called from task or softirq
context.

This means we can drop the fpsimd_context_busy flag entirely, and
instead, ensure that we disable softirq processing in places where we
formerly relied on the flag for preventing races in the FPSIMD preserve
routines.

Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
Reviewed-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/simd.h | 11 +---
 arch/arm64/kernel/fpsimd.c    | 53 +++++---------------
 2 files changed, 13 insertions(+), 51 deletions(-)

diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
index 6a75d7ecdcaa..8e86c9e70e48 100644
--- a/arch/arm64/include/asm/simd.h
+++ b/arch/arm64/include/asm/simd.h
@@ -12,8 +12,6 @@
 #include <linux/preempt.h>
 #include <linux/types.h>
 
-DECLARE_PER_CPU(bool, fpsimd_context_busy);
-
 #ifdef CONFIG_KERNEL_MODE_NEON
 
 /*
@@ -28,17 +26,10 @@ static __must_check inline bool may_use_simd(void)
 	/*
 	 * We must make sure that the SVE has been initialized properly
 	 * before using the SIMD in kernel.
-	 * fpsimd_context_busy is only set while preemption is disabled,
-	 * and is clear whenever preemption is enabled. Since
-	 * this_cpu_read() is atomic w.r.t. preemption, fpsimd_context_busy
-	 * cannot change under our feet -- if it's set we cannot be
-	 * migrated, and if it's clear we cannot be migrated to a CPU
-	 * where it is set.
 	 */
 	return !WARN_ON(!system_capabilities_finalized()) &&
 	       system_supports_fpsimd() &&
-	       !in_hardirq() && !irqs_disabled() && !in_nmi() &&
-	       !this_cpu_read(fpsimd_context_busy);
+	       !in_hardirq() && !irqs_disabled() && !in_nmi();
 }
 
 #else /* ! CONFIG_KERNEL_MODE_NEON */
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 1559c706d32d..ccc4a78a70e4 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -85,13 +85,13 @@
  * softirq kicks in. Upon vcpu_put(), KVM will save the vcpu FP state and
  * flag the register state as invalid.
  *
- * In order to allow softirq handlers to use FPSIMD, kernel_neon_begin() may
- * save the task's FPSIMD context back to task_struct from softirq context.
- * To prevent this from racing with the manipulation of the task's FPSIMD state
- * from task context and thereby corrupting the state, it is necessary to
- * protect any manipulation of a task's fpsimd_state or TIF_FOREIGN_FPSTATE
- * flag with {, __}get_cpu_fpsimd_context(). This will still allow softirqs to
- * run but prevent them to use FPSIMD.
+ * In order to allow softirq handlers to use FPSIMD, kernel_neon_begin() may be
+ * called from softirq context, which will save the task's FPSIMD context back
+ * to task_struct. To prevent this from racing with the manipulation of the
+ * task's FPSIMD state from task context and thereby corrupting the state, it
+ * is necessary to protect any manipulation of a task's fpsimd_state or
+ * TIF_FOREIGN_FPSTATE flag with get_cpu_fpsimd_context(), which will suspend
+ * softirq servicing entirely until put_cpu_fpsimd_context() is called.
  *
  * For a certain task, the sequence may look something like this:
  * - the task gets scheduled in; if both the task's fpsimd_cpu field
@@ -209,27 +209,14 @@ static inline void sme_free(struct task_struct *t) { }
 
 #endif
 
-DEFINE_PER_CPU(bool, fpsimd_context_busy);
-EXPORT_PER_CPU_SYMBOL(fpsimd_context_busy);
-
 static void fpsimd_bind_task_to_cpu(void);
 
-static void __get_cpu_fpsimd_context(void)
-{
-	bool busy = __this_cpu_xchg(fpsimd_context_busy, true);
-
-	WARN_ON(busy);
-}
-
 /*
  * Claim ownership of the CPU FPSIMD context for use by the calling context.
  *
  * The caller may freely manipulate the FPSIMD context metadata until
  * put_cpu_fpsimd_context() is called.
  *
- * The double-underscore version must only be called if you know the task
- * can't be preempted.
- *
  * On RT kernels local_bh_disable() is not sufficient because it only
  * serializes soft interrupt related sections via a local lock, but stays
  * preemptible. Disabling preemption is the right choice here as bottom
@@ -242,14 +229,6 @@ static void get_cpu_fpsimd_context(void)
 		local_bh_disable();
 	else
 		preempt_disable();
-	__get_cpu_fpsimd_context();
-}
-
-static void __put_cpu_fpsimd_context(void)
-{
-	bool busy = __this_cpu_xchg(fpsimd_context_busy, false);
-
-	WARN_ON(!busy); /* No matching get_cpu_fpsimd_context()? */
 }
 
 /*
@@ -261,18 +240,12 @@ static void __put_cpu_fpsimd_context(void)
  */
 static void put_cpu_fpsimd_context(void)
 {
-	__put_cpu_fpsimd_context();
 	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
 		local_bh_enable();
 	else
 		preempt_enable();
 }
 
-static bool have_cpu_fpsimd_context(void)
-{
-	return !preemptible() && __this_cpu_read(fpsimd_context_busy);
-}
-
 unsigned int task_get_vl(const struct task_struct *task, enum vec_type type)
 {
 	return task->thread.vl[type];
@@ -383,7 +356,7 @@ static void task_fpsimd_load(void)
 	bool restore_ffr;
 
 	WARN_ON(!system_supports_fpsimd());
-	WARN_ON(!have_cpu_fpsimd_context());
+	WARN_ON(preemptible());
 
 	if (system_supports_sve() || system_supports_sme()) {
 		switch (current->thread.fp_type) {
@@ -467,7 +440,7 @@ static void fpsimd_save(void)
 	unsigned int vl;
 
 	WARN_ON(!system_supports_fpsimd());
-	WARN_ON(!have_cpu_fpsimd_context());
+	WARN_ON(preemptible());
 
 	if (test_thread_flag(TIF_FOREIGN_FPSTATE))
 		return;
@@ -1507,7 +1480,7 @@ void fpsimd_thread_switch(struct task_struct *next)
 	if (!system_supports_fpsimd())
 		return;
 
-	__get_cpu_fpsimd_context();
+	WARN_ON_ONCE(!irqs_disabled());
 
 	/* Save unsaved fpsimd state, if any: */
 	fpsimd_save();
@@ -1523,8 +1496,6 @@ void fpsimd_thread_switch(struct task_struct *next)
 
 	update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
 			       wrong_task || wrong_cpu);
-
-	__put_cpu_fpsimd_context();
 }
 
 static void fpsimd_flush_thread_vl(enum vec_type type)
@@ -1829,10 +1800,10 @@ void fpsimd_save_and_flush_cpu_state(void)
 	if (!system_supports_fpsimd())
 		return;
 	WARN_ON(preemptible());
-	__get_cpu_fpsimd_context();
+	get_cpu_fpsimd_context();
 	fpsimd_save();
 	fpsimd_flush_cpu_state();
-	__put_cpu_fpsimd_context();
+	put_cpu_fpsimd_context();
 }
 
 #ifdef CONFIG_KERNEL_MODE_NEON
-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Fri Dec  8 03:32:21 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Fri,  8 Dec 2023 12:32:21 +0100
Subject: [PATCH v4 2/4] arm64: fpsimd: Preserve/restore kernel mode NEON at
 context switch
In-Reply-To: <20231208113218.3001940-6-ardb@google.com>
References: <20231208113218.3001940-6-ardb@google.com>
Message-ID: <20231208113218.3001940-8-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

Currently, the FPSIMD register file is not preserved and restored along
with the general registers on exception entry/exit or context switch.
For this reason, we disable preemption when enabling FPSIMD for kernel
mode use in task context, and suspend the processing of softirqs so that
there are no concurrent uses in the kernel. (Kernel mode FPSIMD may not
be used at all in other contexts).

Disabling preemption while doing CPU intensive work on inputs of
potentially unbounded size is bad for real-time performance, which is
why we try and ensure that SIMD crypto code does not operate on more
than ~4k at a time, which is an arbitrary limit and requires assembler
code to implement efficiently.

We can avoid the need for disabling preemption if we can ensure that any
in-kernel users of the NEON will not lose the FPSIMD register state
across a context switch. And given that disabling softirqs implicitly
disables preemption as well, we will also have to ensure that a softirq
that runs code using FPSIMD can safely interrupt an in-kernel user.

So introduce a thread_info flag TIF_USING_KMODE_FPSIMD, and modify the
context switch hook for FPSIMD to preserve and restore the kernel mode
FPSIMD to/from struct thread_struct when it is set. This avoids any
scheduling blackouts due to prolonged use of FPSIMD in kernel mode,
without the need for manual yielding.

In order to support softirq processing while FPSIMD is being used in
kernel task context, use the same flag to decide whether the kernel mode
FPSIMD state needs to be preserved and restored before allowing FPSIMD
to be used in softirq context.

Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
Reviewed-by: Mark Brown <broonie at kernel.org>
Reviewed-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/include/asm/processor.h   |  2 +
 arch/arm64/include/asm/thread_info.h |  1 +
 arch/arm64/kernel/fpsimd.c           | 92 ++++++++++++++++----
 3 files changed, 77 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index e5bc54522e71..ce6eebd6c08b 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -167,6 +167,8 @@ struct thread_struct {
 	unsigned long		fault_address;	/* fault info */
 	unsigned long		fault_code;	/* ESR_EL1 value */
 	struct debug_info	debug;		/* debugging */
+
+	struct user_fpsimd_state	kernel_fpsimd_state;
 #ifdef CONFIG_ARM64_PTR_AUTH
 	struct ptrauth_keys_user	keys_user;
 #ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index 553d1bc559c6..e72a3bf9e563 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -80,6 +80,7 @@ void arch_setup_new_exec(void);
 #define TIF_TAGGED_ADDR		26	/* Allow tagged user addresses */
 #define TIF_SME			27	/* SME in use */
 #define TIF_SME_VL_INHERIT	28	/* Inherit SME vl_onexec across exec */
+#define TIF_KERNEL_FPSTATE	29	/* Task is in a kernel mode FPSIMD section */
 
 #define _TIF_SIGPENDING		(1 << TIF_SIGPENDING)
 #define _TIF_NEED_RESCHED	(1 << TIF_NEED_RESCHED)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index ccc4a78a70e4..c2d05de677d1 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -357,6 +357,7 @@ static void task_fpsimd_load(void)
 
 	WARN_ON(!system_supports_fpsimd());
 	WARN_ON(preemptible());
+	WARN_ON(test_thread_flag(TIF_KERNEL_FPSTATE));
 
 	if (system_supports_sve() || system_supports_sme()) {
 		switch (current->thread.fp_type) {
@@ -379,7 +380,7 @@ static void task_fpsimd_load(void)
 		default:
 			/*
 			 * This indicates either a bug in
-			 * fpsimd_save() or memory corruption, we
+			 * fpsimd_save_user_state() or memory corruption, we
 			 * should always record an explicit format
 			 * when we save. We always at least have the
 			 * memory allocated for FPSMID registers so
@@ -430,7 +431,7 @@ static void task_fpsimd_load(void)
  * than via current, if we are saving KVM state then it will have
  * ensured that the type of registers to save is set in last->to_save.
  */
-static void fpsimd_save(void)
+static void fpsimd_save_user_state(void)
 {
 	struct cpu_fp_state const *last =
 		this_cpu_ptr(&fpsimd_last_state);
@@ -861,7 +862,7 @@ int vec_set_vector_length(struct task_struct *task, enum vec_type type,
 	if (task == current) {
 		get_cpu_fpsimd_context();
 
-		fpsimd_save();
+		fpsimd_save_user_state();
 	}
 
 	fpsimd_flush_task_state(task);
@@ -1473,6 +1474,16 @@ void do_fpsimd_exc(unsigned long esr, struct pt_regs *regs)
 		       current);
 }
 
+static void fpsimd_load_kernel_state(struct task_struct *task)
+{
+	fpsimd_load_state(&task->thread.kernel_fpsimd_state);
+}
+
+static void fpsimd_save_kernel_state(struct task_struct *task)
+{
+	fpsimd_save_state(&task->thread.kernel_fpsimd_state);
+}
+
 void fpsimd_thread_switch(struct task_struct *next)
 {
 	bool wrong_task, wrong_cpu;
@@ -1483,19 +1494,28 @@ void fpsimd_thread_switch(struct task_struct *next)
 	WARN_ON_ONCE(!irqs_disabled());
 
 	/* Save unsaved fpsimd state, if any: */
-	fpsimd_save();
+	if (test_thread_flag(TIF_KERNEL_FPSTATE))
+		fpsimd_save_kernel_state(current);
+	else
+		fpsimd_save_user_state();
 
-	/*
-	 * Fix up TIF_FOREIGN_FPSTATE to correctly describe next's
-	 * state.  For kernel threads, FPSIMD registers are never loaded
-	 * and wrong_task and wrong_cpu will always be true.
-	 */
-	wrong_task = __this_cpu_read(fpsimd_last_state.st) !=
-					&next->thread.uw.fpsimd_state;
-	wrong_cpu = next->thread.fpsimd_cpu != smp_processor_id();
+	if (test_tsk_thread_flag(next, TIF_KERNEL_FPSTATE)) {
+		fpsimd_load_kernel_state(next);
+		set_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
+	} else {
+		/*
+		 * Fix up TIF_FOREIGN_FPSTATE to correctly describe next's
+		 * state.  For kernel threads, FPSIMD registers are never
+		 * loaded with user mode FPSIMD state and so wrong_task and
+		 * wrong_cpu will always be true.
+		 */
+		wrong_task = __this_cpu_read(fpsimd_last_state.st) !=
+			&next->thread.uw.fpsimd_state;
+		wrong_cpu = next->thread.fpsimd_cpu != smp_processor_id();
 
-	update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
-			       wrong_task || wrong_cpu);
+		update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
+				       wrong_task || wrong_cpu);
+	}
 }
 
 static void fpsimd_flush_thread_vl(enum vec_type type)
@@ -1585,7 +1605,7 @@ void fpsimd_preserve_current_state(void)
 		return;
 
 	get_cpu_fpsimd_context();
-	fpsimd_save();
+	fpsimd_save_user_state();
 	put_cpu_fpsimd_context();
 }
 
@@ -1801,7 +1821,7 @@ void fpsimd_save_and_flush_cpu_state(void)
 		return;
 	WARN_ON(preemptible());
 	get_cpu_fpsimd_context();
-	fpsimd_save();
+	fpsimd_save_user_state();
 	fpsimd_flush_cpu_state();
 	put_cpu_fpsimd_context();
 }
@@ -1835,10 +1855,37 @@ void kernel_neon_begin(void)
 	get_cpu_fpsimd_context();
 
 	/* Save unsaved fpsimd state, if any: */
-	fpsimd_save();
+	if (test_thread_flag(TIF_KERNEL_FPSTATE)) {
+		BUG_ON(IS_ENABLED(CONFIG_PREEMPT_RT) || !in_serving_softirq());
+		fpsimd_save_kernel_state(current);
+	} else {
+		fpsimd_save_user_state();
+
+		/*
+		 * Set the thread flag so that the kernel mode FPSIMD state
+		 * will be context switched along with the rest of the task
+		 * state.
+		 *
+		 * On non-PREEMPT_RT, softirqs may interrupt task level kernel
+		 * mode FPSIMD, but the task will not be preemptible so setting
+		 * TIF_KERNEL_FPSTATE for those would be both wrong (as it
+		 * would mark the task context FPSIMD state as requiring a
+		 * context switch) and unnecessary.
+		 *
+		 * On PREEMPT_RT, softirqs are serviced from a separate thread,
+		 * which is scheduled as usual, and this guarantees that these
+		 * softirqs are not interrupting use of the FPSIMD in kernel
+		 * mode in task context. So in this case, setting the flag here
+		 * is always appropriate.
+		 */
+		if (IS_ENABLED(CONFIG_PREEMPT_RT) || !in_serving_softirq())
+			set_thread_flag(TIF_KERNEL_FPSTATE);
+	}
 
 	/* Invalidate any task state remaining in the fpsimd regs: */
 	fpsimd_flush_cpu_state();
+
+	put_cpu_fpsimd_context();
 }
 EXPORT_SYMBOL_GPL(kernel_neon_begin);
 
@@ -1856,7 +1903,16 @@ void kernel_neon_end(void)
 	if (!system_supports_fpsimd())
 		return;
 
-	put_cpu_fpsimd_context();
+	/*
+	 * If we are returning from a nested use of kernel mode FPSIMD, restore
+	 * the task context kernel mode FPSIMD state. This can only happen when
+	 * running in softirq context on non-PREEMPT_RT.
+	 */
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT) && in_serving_softirq() &&
+	    test_thread_flag(TIF_KERNEL_FPSTATE))
+		fpsimd_load_kernel_state(current);
+	else
+		clear_thread_flag(TIF_KERNEL_FPSTATE);
 }
 EXPORT_SYMBOL_GPL(kernel_neon_end);
 
-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Fri Dec  8 03:32:22 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Fri,  8 Dec 2023 12:32:22 +0100
Subject: [PATCH v4 3/4] arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD
In-Reply-To: <20231208113218.3001940-6-ardb@google.com>
References: <20231208113218.3001940-6-ardb@google.com>
Message-ID: <20231208113218.3001940-9-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

Now that kernel mode FPSIMD state is context switched along with other
task state, we can enable the existing logic that keeps track of which
task's FPSIMD state the CPU is holding in its registers. If it is the
context of the task that we are switching to, we can elide the reload of
the FPSIMD state from memory.

Note that we also need to check whether the FPSIMD state on this CPU is
the most recent: if a task gets migrated away and back again, the state
in memory may be more recent than the state in the CPU. So add another
CPU id field to task_struct to keep track of this. (We could reuse the
existing CPU id field used for user mode context, but that might result
in user state to be discarded unnecessarily, given that two distinct
CPUs could be holding the most recent user mode state and the most
recent kernel mode state)

Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
Reviewed-by: Mark Brown <broonie at kernel.org>
Acked-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/include/asm/processor.h |  1 +
 arch/arm64/kernel/fpsimd.c         | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index ce6eebd6c08b..5b0a04810b23 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -169,6 +169,7 @@ struct thread_struct {
 	struct debug_info	debug;		/* debugging */
 
 	struct user_fpsimd_state	kernel_fpsimd_state;
+	unsigned int			kernel_fpsimd_cpu;
 #ifdef CONFIG_ARM64_PTR_AUTH
 	struct ptrauth_keys_user	keys_user;
 #ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index c2d05de677d1..50ae93d9baec 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -1476,12 +1476,30 @@ void do_fpsimd_exc(unsigned long esr, struct pt_regs *regs)
 
 static void fpsimd_load_kernel_state(struct task_struct *task)
 {
+	struct cpu_fp_state *last = this_cpu_ptr(&fpsimd_last_state);
+
+	/*
+	 * Elide the load if this CPU holds the most recent kernel mode
+	 * FPSIMD context of the current task.
+	 */
+	if (last->st == &task->thread.kernel_fpsimd_state &&
+	    task->thread.kernel_fpsimd_cpu == smp_processor_id())
+		return;
+
 	fpsimd_load_state(&task->thread.kernel_fpsimd_state);
 }
 
 static void fpsimd_save_kernel_state(struct task_struct *task)
 {
+	struct cpu_fp_state cpu_fp_state = {
+		.st		= &task->thread.kernel_fpsimd_state,
+		.to_save	= FP_STATE_FPSIMD,
+	};
+
 	fpsimd_save_state(&task->thread.kernel_fpsimd_state);
+	fpsimd_bind_state_to_cpu(&cpu_fp_state);
+
+	task->thread.kernel_fpsimd_cpu = smp_processor_id();
 }
 
 void fpsimd_thread_switch(struct task_struct *next)
-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Fri Dec  8 03:32:23 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Fri,  8 Dec 2023 12:32:23 +0100
Subject: [PATCH v4 4/4] arm64: crypto: Disable yielding logic unless CONFIG_PREEMPT_VOLUNTARY=y
In-Reply-To: <20231208113218.3001940-6-ardb@google.com>
References: <20231208113218.3001940-6-ardb@google.com>
Message-ID: <20231208113218.3001940-10-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

Now that kernel mode use of SIMD runs with preemption enabled, the
explicit yield logic is redundant for preemptible builds, and since it
should not actually be used at all on non-preemptible builds (where
kernel work is supposed to run to completion and not give up its time
slice prematurely), let's make it depend on CONFIG_PREEMPT_VOLUNTARY.

Once CONFIG_PREEMPT_VOLUNTARY is removed, all the logic it guards can be
removed as well.

Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
---
 arch/arm64/crypto/aes-ce-ccm-glue.c      | 8 ++++++--
 arch/arm64/crypto/chacha-neon-glue.c     | 5 ++++-
 arch/arm64/crypto/crct10dif-ce-glue.c    | 6 ++++--
 arch/arm64/crypto/nhpoly1305-neon-glue.c | 5 ++++-
 arch/arm64/crypto/poly1305-glue.c        | 5 ++++-
 arch/arm64/crypto/polyval-ce-glue.c      | 9 +++++++--
 arch/arm64/include/asm/assembler.h       | 4 ++--
 7 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c
index 25cd3808ecbe..82e293a698ff 100644
--- a/arch/arm64/crypto/aes-ce-ccm-glue.c
+++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
@@ -125,13 +125,17 @@ static void ccm_calculate_auth_mac(struct aead_request *req, u8 mac[])
 			scatterwalk_start(&walk, sg_next(walk.sg));
 			n = scatterwalk_clamp(&walk, len);
 		}
-		n = min_t(u32, n, SZ_4K); /* yield NEON at least every 4k */
+
+		if (IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY))
+			n = min_t(u32, n, SZ_4K); /* yield NEON at least every 4k */
+
 		p = scatterwalk_map(&walk);
 
 		macp = ce_aes_ccm_auth_data(mac, p, n, macp, ctx->key_enc,
 					    num_rounds(ctx));
 
-		if (len / SZ_4K > (len - n) / SZ_4K) {
+		if (IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY) &&
+		    len / SZ_4K > (len - n) / SZ_4K) {
 			kernel_neon_end();
 			kernel_neon_begin();
 		}
diff --git a/arch/arm64/crypto/chacha-neon-glue.c b/arch/arm64/crypto/chacha-neon-glue.c
index af2bbca38e70..655b250cef4a 100644
--- a/arch/arm64/crypto/chacha-neon-glue.c
+++ b/arch/arm64/crypto/chacha-neon-glue.c
@@ -88,7 +88,10 @@ void chacha_crypt_arch(u32 *state, u8 *dst, const u8 *src, unsigned int bytes,
 		return chacha_crypt_generic(state, dst, src, bytes, nrounds);
 
 	do {
-		unsigned int todo = min_t(unsigned int, bytes, SZ_4K);
+		unsigned int todo = bytes;
+
+		if (IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY))
+			todo = min_t(unsigned int, todo, SZ_4K);
 
 		kernel_neon_begin();
 		chacha_doneon(state, dst, src, todo, nrounds);
diff --git a/arch/arm64/crypto/crct10dif-ce-glue.c b/arch/arm64/crypto/crct10dif-ce-glue.c
index 09eb1456aed4..c6e8cf4f56da 100644
--- a/arch/arm64/crypto/crct10dif-ce-glue.c
+++ b/arch/arm64/crypto/crct10dif-ce-glue.c
@@ -40,7 +40,8 @@ static int crct10dif_update_pmull_p8(struct shash_desc *desc, const u8 *data,
 		do {
 			unsigned int chunk = length;
 
-			if (chunk > SZ_4K + CRC_T10DIF_PMULL_CHUNK_SIZE)
+			if (IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY) &&
+			    chunk > SZ_4K + CRC_T10DIF_PMULL_CHUNK_SIZE)
 				chunk = SZ_4K;
 
 			kernel_neon_begin();
@@ -65,7 +66,8 @@ static int crct10dif_update_pmull_p64(struct shash_desc *desc, const u8 *data,
 		do {
 			unsigned int chunk = length;
 
-			if (chunk > SZ_4K + CRC_T10DIF_PMULL_CHUNK_SIZE)
+			if (IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY) &&
+			    chunk > SZ_4K + CRC_T10DIF_PMULL_CHUNK_SIZE)
 				chunk = SZ_4K;
 
 			kernel_neon_begin();
diff --git a/arch/arm64/crypto/nhpoly1305-neon-glue.c b/arch/arm64/crypto/nhpoly1305-neon-glue.c
index e4a0b463f080..cbbc51b27d93 100644
--- a/arch/arm64/crypto/nhpoly1305-neon-glue.c
+++ b/arch/arm64/crypto/nhpoly1305-neon-glue.c
@@ -23,7 +23,10 @@ static int nhpoly1305_neon_update(struct shash_desc *desc,
 		return crypto_nhpoly1305_update(desc, src, srclen);
 
 	do {
-		unsigned int n = min_t(unsigned int, srclen, SZ_4K);
+		unsigned int n = srclen;
+
+		if (IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY))
+			n = min_t(unsigned int, n, SZ_4K);
 
 		kernel_neon_begin();
 		crypto_nhpoly1305_update_helper(desc, src, n, nh_neon);
diff --git a/arch/arm64/crypto/poly1305-glue.c b/arch/arm64/crypto/poly1305-glue.c
index 1fae18ba11ed..27f84f5bfc98 100644
--- a/arch/arm64/crypto/poly1305-glue.c
+++ b/arch/arm64/crypto/poly1305-glue.c
@@ -144,7 +144,10 @@ void poly1305_update_arch(struct poly1305_desc_ctx *dctx, const u8 *src,
 
 		if (static_branch_likely(&have_neon) && crypto_simd_usable()) {
 			do {
-				unsigned int todo = min_t(unsigned int, len, SZ_4K);
+				unsigned int todo = len;
+
+				if (IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY))
+					todo = min_t(unsigned int, todo, SZ_4K);
 
 				kernel_neon_begin();
 				poly1305_blocks_neon(&dctx->h, src, todo, 1);
diff --git a/arch/arm64/crypto/polyval-ce-glue.c b/arch/arm64/crypto/polyval-ce-glue.c
index 0a3b5718df85..c4c0fb3fcaf4 100644
--- a/arch/arm64/crypto/polyval-ce-glue.c
+++ b/arch/arm64/crypto/polyval-ce-glue.c
@@ -123,8 +123,13 @@ static int polyval_arm64_update(struct shash_desc *desc,
 	}
 
 	while (srclen >= POLYVAL_BLOCK_SIZE) {
-		/* allow rescheduling every 4K bytes */
-		nblocks = min(srclen, 4096U) / POLYVAL_BLOCK_SIZE;
+		unsigned int len = srclen;
+
+		if (IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY))
+			/* allow rescheduling every 4K bytes */
+			len = min(len, 4096U);
+
+		nblocks = len / POLYVAL_BLOCK_SIZE;
 		internal_polyval_update(tctx, src, nblocks, dctx->buffer);
 		srclen -= nblocks * POLYVAL_BLOCK_SIZE;
 		src += nblocks * POLYVAL_BLOCK_SIZE;
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 376a980f2bad..0180ac1f9b8b 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -769,6 +769,7 @@ alternative_endif
 	 * field)
 	 */
 	.macro		cond_yield, lbl:req, tmp:req, tmp2:req
+#ifdef CONFIG_PREEMPT_VOLUNTARY
 	get_current_task \tmp
 	ldr		\tmp, [\tmp, #TSK_TI_PREEMPT]
 	/*
@@ -777,15 +778,14 @@ alternative_endif
 	 * run to completion as quickly as we can.
 	 */
 	tbnz		\tmp, #SOFTIRQ_SHIFT, .Lnoyield_\@
-#ifdef CONFIG_PREEMPTION
 	sub		\tmp, \tmp, #PREEMPT_DISABLE_OFFSET
 	cbz		\tmp, \lbl
-#endif
 	adr_l		\tmp, irq_stat + IRQ_CPUSTAT_SOFTIRQ_PENDING
 	get_this_cpu_offset	\tmp2
 	ldr		w\tmp, [\tmp, \tmp2]
 	cbnz		w\tmp, \lbl	// yield on pending softirq in task context
 .Lnoyield_\@:
+#endif
 	.endm
 
 /*
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Fri Dec  8 03:35:07 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 8 Dec 2023 11:35:07 +0000
Subject: [PATCH v5 12/20] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <CAPLW+4nAwWBHkAe2Wg2b+URsgN8ienPh14L=Fu8PUxf4gxq0ow@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-13-peter.griffin@linaro.org> <CAPLW+4nAwWBHkAe2Wg2b+URsgN8ienPh14L=Fu8PUxf4gxq0ow@mail.gmail.com>
Message-ID: <CADrjBPqWHOn+oW=cueuOVKHD9ErAG-wo=0xUHU1wTorDdUuLxA@mail.gmail.com>

Hi Sam,

Thanks for your review. I've trimmed the non relevant parts of the
email a bit at Krzysztofs request.

On Fri, 1 Dec 2023 at 22:40, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > cmu_top is the top level clock management unit which contains PLLs, muxes,
> > dividers and gates that feed the other clock management units.
> >
> > cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> > APM module.
> >
> > Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> > Tested-by: Will McVicker <willmcvicker at google.com>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  drivers/clk/samsung/Makefile    |    1 +
> >  drivers/clk/samsung/clk-gs101.c | 2495 +++++++++++++++++++++++++++++++
> >  2 files changed, 2496 insertions(+)
> >  create mode 100644 drivers/clk/samsung/clk-gs101.c
> >
> > diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> > index ebbeacabe88f..3056944a5a54 100644
> > --- a/drivers/clk/samsung/Makefile
> > +++ b/drivers/clk/samsung/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK) += clk-exynos7.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynos7885.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynos850.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynosautov9.o
> > +obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-gs101.o
> >  obj-$(CONFIG_S3C64XX_COMMON_CLK)       += clk-s3c64xx.o
> >  obj-$(CONFIG_S5PV210_COMMON_CLK)       += clk-s5pv210.o clk-s5pv210-audss.o
> >  obj-$(CONFIG_TESLA_FSD_COMMON_CLK)     += clk-fsd.o
> > diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> > new file mode 100644
> > index 000000000000..6bd233a7ab63
> > --- /dev/null
> > +++ b/drivers/clk/samsung/clk-gs101.c
> > @@ -0,0 +1,2495 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2023 Linaro Ltd.
> > + * Author: Peter Griffin <peter.griffin at linaro.org>
> > + *
> > + * Common Clock Framework support for GS101.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include <dt-bindings/clock/google,gs101.h>
> > +
> > +#include "clk.h"
> > +#include "clk-exynos-arm64.h"
> > +
> > +/* NOTE: Must be equal to the last clock ID increased by one */
> > +#define TOP_NR_CLK     (CLK_GOUT_TPU_UART + 1)
> > +#define APM_NR_CLK     (CLK_APM_PLL_DIV16_APM + 1)
> > +#define MISC_NR_CLK    (CLK_GOUT_MISC_XIU_D_MISC_IPCLKPORT_ACLK + 1)
> > +
>
> Suggest using CLKS_NR_* naming, to follow other drivers for consistency.

Will fix

>
> > +/* ---- CMU_TOP ------------------------------------------------------------- */
> > +
> > +/* Register Offset definitions for CMU_TOP (0x1e080000) */
> > +
> > +#define PLL_LOCKTIME_PLL_SHARED0                       0x0000
> > +#define PLL_LOCKTIME_PLL_SHARED1                       0x0004
> > +#define PLL_LOCKTIME_PLL_SHARED2                       0x0008
> > +#define PLL_LOCKTIME_PLL_SHARED3                       0x000c
<cut>
> > +       DIV(CLK_DOUT_MFC_MFC, "dout_cmu_mfc_mfc", "gout_cmu_mfc_mfc",
> > +           CLK_CON_DIV_CLKCMU_MFC_MFC, 0, 4),
> > +       DIV(CLK_DOUT_MIF_BUSP, "dout_cmu_mif_busp", "gout_cmu_mif_busp",
> > +           CLK_CON_DIV_CLKCMU_MIF_BUSP, 0, 4),
> > +       DIV(CLK_DOUT_MISC_BUS, "dout_cmu_misc_bus", "gout_cmu_misc_bus",
> > +           CLK_CON_DIV_CLKCMU_MISC_BUS, 0, 4),
> > +       DIV(CLK_DOUT_MISC_SSS, "dout_cmu_misc_sss", "gout_cmu_misc_sss",
> > +           CLK_CON_DIV_CLKCMU_MISC_SSS, 0, 4),
> > +       /* CLK_CON_DIV_CLKCMU_OTP lower bits reserved*/
>
> Why the above clock where bits are reserved is declared, but this one
> is not? Also, above comment is marked as TODO, but this one is not.
> And there is no space before */.

Good spot! These two dividers with reserved lower bits should be fixed
factor clocks. I've fixed in v6.

>
> > +       DIV(CLK_DOUT_PDP_BUS, "dout_cmu_pdp_bus", "gout_cmu_pdp_bus",
> > +           CLK_CON_DIV_CLKCMU_PDP_BUS, 0, 4),
> > +       DIV(CLK_DOUT_PDP_VRA, "dout_cmu_pdp_vra", "gout_cmu_pdp_vra",
> > +           CLK_CON_DIV_CLKCMU_PDP_VRA, 0, 4),
> > +       DIV(CLK_DOUT_PERIC0_BUS, "dout_cmu_peric0_bus", "gout_cmu_peric0_bus",
> > +           CLK_CON_DIV_CLKCMU_PERIC0_BUS, 0, 4),
<cut>
> > +       DIV(CLK_DOUT_SHARED1_DIV2, "dout_shared1_div2", "mout_shared1_pll",
> > +           CLK_CON_DIV_PLL_SHARED1_DIV2, 0, 1),
> > +       DIV(CLK_DOUT_SHARED1_DIV3, "dout_shared1_div3", "mout_shared1_pll",
> > +           CLK_CON_DIV_PLL_SHARED1_DIV3, 0, 2),
> > +       DIV(CLK_DOUT_SHARED1_DIV4, "dout_shared1_div4", "mout_shared1_pll",
> > +           CLK_CON_DIV_PLL_SHARED1_DIV4, 0, 1),
> > +       DIV(CLK_DOUT_SHARED2_DIV2, "dout_shared2_div2", "mout_shared2_pll",
> > +           CLK_CON_DIV_PLL_SHARED2_DIV2, 0, 1),
> > +       DIV(CLK_DOUT_SHARED3_DIV2, "dout_shared3_div2", "mout_shared3_pll",
> > +           CLK_CON_DIV_PLL_SHARED3_DIV2, 0, 1),
> > +};
> > +
> > +static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> > +       GATE(CLK_GOUT_BUS0_BOOST, "gout_cmu_bus0_boost", "mout_cmu_boost_option1",
>
> Please stick to 80 characters length, here and below.

Will fix.

>
> > +            CLK_CON_GAT_CLKCMU_BUS0_BOOST, 21, 0, 0),
> > +       GATE(CLK_GOUT_BUS1_BOOST, "gout_cmu_bus1_boost", "mout_cmu_boost_option1",
> > +            CLK_CON_GAT_CLKCMU_BUS1_BOOST, 21, 0, 0),
> > +       GATE(CLK_GOUT_BUS2_BOOST, "gout_cmu_bus2_boost", "mout_cmu_boost_option1",
> > +            CLK_CON_GAT_CLKCMU_BUS2_BOOST, 21, 0, 0),
> > +       GATE(CLK_GOUT_CORE_BOOST, "gout_cmu_core_boost", "mout_cmu_boost_option1",
> > +            CLK_CON_GAT_CLKCMU_CORE_BOOST, 21, 0, 0),

> > +static void __init gs101_cmu_top_init(struct device_node *np)
> > +{
> > +       exynos_arm64_register_cmu(NULL, np, &top_cmu_info);
> > +}
> > +
> > +/* Register CMU_TOP early, as it's a dependency for other early domains */
> > +CLK_OF_DECLARE(gs101_cmu_top, "google,gs101-cmu-top",
> > +              gs101_cmu_top_init);
> > +
> > +/* ---- CMU_APM ------------------------------------------------------------- */
>
> Suggest adding an empty line here.

Will fix

>
> > +/* Register Offset definitions for CMU_APM (0x17400000) */
> > +#define APM_CMU_APM_CONTROLLER_OPTION                                                  0x0800
> > +#define CLKOUT_CON_BLK_APM_CMU_APM_CLKOUT0                                             0x0810
> > +#define CLK_CON_MUX_MUX_CLKCMU_APM_FUNC                                                        0x1000
> > +#define CLK_CON_MUX_MUX_CLKCMU_APM_FUNCSRC                                             0x1004
> > +#define CLK_CON_DIV_DIV_CLK_APM_BOOST                                                  0x1800
> > +#define CLK_CON_DIV_DIV_CLK_APM_USI0_UART                                              0x1804
> > +#define CLK_CON_DIV_DIV_CLK_APM_USI0_USI                                               0x1808
> > +#define CLK_CON_DIV_DIV_CLK_APM_USI1_UART                                              0x180c
> > +#define CLK_CON_GAT_CLK_BLK_APM_UID_APM_CMU_APM_IPCLKPORT_PCLK                         0x2000
> > +#define CLK_CON_GAT_CLK_BUS0_BOOST_OPTION1                                             0x2004
> > +#define CLK_CON_GAT_CLK_CMU_BOOST_OPTION1                                              0x2008
> > +#define CLK_CON_GAT_CLK_CORE_BOOST_OPTION1                                             0x200c
<cut>
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_APM_IPCLKPORT_PCLK                         0x20a8
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_SUB_APM_IPCLKPORT_PCLK                     0x20ac
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_ACLK                         0x20b0
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_PCLK                         0x20b4
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_ACLK                     0x20b8
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_PCLK                     0x20bc
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SS_DBGCORE_IPCLKPORT_SS_DBGCORE_IPCLKPORT_HCLK    0x20c0
>
> As I understand, all those parts like IPCLKPORT, BLK, UID (RSTNSYNC
> probably too) -- they don't really mean anything in the context of the
> driver, just noise. And if you remove those -- there won't be any
> conflicts with other names, because those bits are not the unique
> parts. Following the TRM letter for letter in this case just makes
> things extremely long without adding any value IMHO. For example, that
> name above might be:
>
>     CLK_CON_GAT_GOUT_APM_SS_DBGCORE_SS_DBGCORE_HCLK
>
> or even
>
>     CLK_CON_GAT_GOUT_APM_SS_DBGCORE_HCLK
>
> would be fine.
>
> In clk-exynos850 driver I removed all those parts, because they make
> it pretty much impossible to read both the driver and dts. And yeah,
> because those names consequenty lead to very long string names, dts
> will be hard to read too, which is even worse. But again, that's only
> my IMHO.

I would like to keep the register names unmodified, as I mentioned
previously mangling them makes checking with the datasheet much
harder. As the name in the header and string are already mangled a bit
I'm OK with mangling that a bit more.

With that in mind I've done the following mangling in v6: -

Register name: CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK

Replace `CLK_CON_GAT_GOUT_BLK_<blockname>_UID_` with `CLK_GOUT_<blockname>_`
Replace ` _IPCLKPORT` with nothing
Replace `_RSTNSYNC` with nothing

So you end up with:

GATE(CLK_GOUT_APM_APBIF_GPIO_ALIVE_PCLK,
            "gout_apm_apbif_gpio_alive_pclk", "gout_apm_func",
             CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK,
             21, 0, 0),

That still enables cross referencing with the datasheet via the
unmodified register name, but the dt binding define and string are
slightly shorter like you wanted. The mangling described above the
vast majority of clock names look fine. There are a couple of
anomalies though like  `CLK_GOUT_MISC_MISC_CMU_MISC_PCLK` and
`CLK_GOUT_APM_APM_CMU_APM_PCLK`. I think it is a *really* bad idea to
do custom mangling on these specific names though.

>
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SYSMMU_D_APM_IPCLKPORT_CLK_S2                     0x20c4
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_SYSREG_APM_IPCLKPORT_PCLK                         0x20cc
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_ACLK                           0x20d0
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_PCLK                           0x20d4
> > +#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_DBGCORE_IPCLKPORT_ACLK                       0x20d8

<cut>

> > +       GATE(CLK_GOUT_APM_APBIF_RTC_IPCLKPORT_PCLK,
> > +            "gout_apm_apbif_rtc_ipclkport_pclk", "gout_apm_func",
> > +            CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_RTC_IPCLKPORT_PCLK, 21, 0, 0),
> > +       GATE(CLK_GOUT_APM_APBIF_TRTC_IPCLKPORT_PCLK,
> > +            "gout_apm_apbif_trtc_ipclkport_pclk", "gout_apm_func",
> > +            CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_TRTC_IPCLKPORT_PCLK, 21, 0, 0),
> > +       GATE(CLK_GOUT_APM_APM_USI0_UART_IPCLKPORT_PCLK,
> > +            "gout_apm_apm_usi0_uart_ipclkport_pclk", "gout_apm_func",
> > +            CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_PCLK,
> > +            21, 0, 0),
> > +       GATE(CLK_GOUT_APM_APM_USI0_USI_IPCLKPORT_IPCLK,
> > +            "gout_apm_apm_usi0_usi_ipclkport_ipclk", "dout_apm_usi0_uart",
> > +            CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_PCLK,
>
> PCLK vs IPCLK?

Will fix. The order here should match the register offsets

CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_IPCLK,
CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_PCLK,
CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_IPCLK,
CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_PCLK,
CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_IPCLK,
CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_PCLK,

>
> > +            21, 0, 0),
> > +       GATE(CLK_GOUT_APM_APM_USI0_USI_IPCLKPORT_PCLK,
> > +            "gout_apm_apm_usi0_usi_ipclkport_pclk", "gout_apm_func",
> > +            CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_PCLK, 21, 0, 0),
>
> Should it be USI0 instead of USI1? It's the same as the definition
> below. Also, please stick to 80 characters per line, here and below.

I've revisited the 6 clock gates described above to ensure they are in
register offset order.

>
> > +       GATE(CLK_GOUT_APM_APM_USI1_UART_IPCLKPORT_IPCLK,
> > +            "gout_apm_apm_usi1_uart_ipclkport_ipclk", "dout_apm_usi1_uart",
> > +            CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_IPCLK, 21, 0, 0),
> > +       GATE(CLK_GOUT_APM_APM_USI1_UART_IPCLKPORT_PCLK,
> > +            "gout_apm_apm_usi1_uart_ipclkport_pclk", "gout_apm_func",

<cut>

> > +static const struct samsung_cmu_info apm_cmu_info __initconst = {
> > +       .mux_clks               = apm_mux_clks,
> > +       .nr_mux_clks            = ARRAY_SIZE(apm_mux_clks),
> > +       .div_clks               = apm_div_clks,
> > +       .nr_div_clks            = ARRAY_SIZE(apm_div_clks),
> > +       .gate_clks              = apm_gate_clks,
> > +       .nr_gate_clks           = ARRAY_SIZE(apm_gate_clks),
> > +       .fixed_clks             = apm_fixed_clks,
> > +       .nr_fixed_clks          = ARRAY_SIZE(apm_fixed_clks),
> > +       .nr_clk_ids             = APM_NR_CLK,
> > +       .clk_regs               = apm_clk_regs,
> > +       .nr_clk_regs            = ARRAY_SIZE(apm_clk_regs),
> > +};
> > +
> > +/* ---- CMU_MISC ------------------------------------------------------------- */
>
> Suggest adding an empty line here.

Will fix
>
> > +/* Register Offset definitions for CMU_MISC (0x10010000) */
> > +#define PLL_CON0_MUX_CLKCMU_MISC_BUS_USER      0x0600
> > +#define PLL_CON1_MUX_CLKCMU_MISC_BUS_USER      0x0604
> > +#define PLL_CON0_MUX_CLKCMU_MISC_SSS_USER      0x0610
> > +#define PLL_CON1_MUX_CLKCMU_MISC_SSS_USER      0x0614
> > +#define MISC_CMU_MISC_CONTROLLER_OPTION                0x0800
> > +#define CLKOUT_CON_BLK_MISC_CMU_MISC_CLKOUT0   0x0810
> > +#define CLK_CON_MUX_MUX_CLK_MISC_GIC           0x1000
> > +#define CLK_CON_DIV_DIV_CLK_MISC_BUSP          0x1800
> > +#define CLK_CON_DIV_DIV_CLK_MISC_GIC           0x1804
>
> Please align all values for this group at the same indentation level.

Will fix

>
> > +#define CLK_CON_GAT_CLK_BLK_MISC_UID_MISC_CMU_MISC_IPCLKPORT_PCLK              0x2000
> > +#define CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK           0x2004
> > +#define CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_I_OSCCLK           0x2008
> > +#define CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_TOP_IPCLKPORT_I_OSCCLK            0x200c
> > +#define CLK_CON_GAT_CLK_BLK_MISC_UID_RSTNSYNC_CLK_MISC_OSCCLK_IPCLKPORT_CLK    0x2010
>
> Just want to give you one more example for my rant above. Look how
> much easier it is to understand this name (than above one):
>
>     CLK_CON_GAT_MISC_OSCCLK_CLK
>
> Which also turns this (public API!):
>
>     "gout_misc_rstnsync_clk_misc_oscclk_ipclkport_clk"
>
> into this:
>
>     "gout_misc_oscclk_clk"

In v6 this becomes

GATE(CLK_GOUT_MISC_CLK_MISC_OSCCLK_CLK,
     "gout_misc_clk_misc_oscclk_clk", "dout_misc_busp",
     CLK_CON_GAT_CLK_BLK_MISC_UID_RSTNSYNC_CLK_MISC_OSCCLK_IPCLKPORT_CLK,
     21, 0, 0),

<cut>
>
> > +#define CLK_CON_GAT_GOUT_BLK_MISC_UID_ADM_AHB_SSS_IPCLKPORT_HCLKM              0x2014
> > +#define CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_DIT_IPCLKPORT_PCLKM               0x2018
> > +#define CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_PUF_IPCLKPORT_PCLKM               0x201c
> > +#define CLK_CON_GAT_GOUT_BLK_MISC_UID_DIT_IPCLKPORT_ICLKL2A                    0x2020
> > +#define CLK_CON_GAT_GOUT_BLK_MISC_UID_D_TZPC_MISC_IPCLKPORT_PCLK               0x2024
> > +#define CLK_CON_GAT_GOUT_BLK_MISC_UID_GIC_IPCLKPORT_GICCLK                     0x2028
> > +#define CLK_CON_GAT_GOUT_BLK_MISC_UID_GPC_MISC_IPCLKPORT_PCLK                  0x202c

<cut>

> > +static const struct samsung_div_clock misc_div_clks[] __initconst = {
> > +       DIV(CLK_DOUT_MISC_BUSP, "dout_misc_busp", "mout_misc_bus_user",
> > +           CLK_CON_DIV_DIV_CLK_MISC_BUSP, 0, 3),
> > +       DIV(CLK_DOUT_MISC_GIC, "dout_misc_gic", "mout_misc_bus_user",
> > +           CLK_CON_DIV_DIV_CLK_MISC_GIC, 0, 3),
> > +};
> > +
> > +static const struct samsung_gate_clock misc_gate_clks[] __initconst = {
> > +       GATE(CLK_GOUT_MISC_MISC_CMU_MISC_IPCLKPORT_PCLK,
> > +            "gout_misc_ipclkport_pclk", "dout_misc_busp",
>
> So if you want to be consistent, it should be
> "gout_misc_misc_misc_....". My point is -- Samsung's naming in TRM is
> insane. They wanted to stick to some very detailed and unified naming
> schema (or just generated those names from some internal clock tree
> data), granted. But I'm just not sure if it's the best idea to follow
> it in driver's code.

With the naming described above it becomes
"gout_misc_misc_cmu_misc_pclk". Not ideal, and this is one of the
clocks I mentioned above. The overwhelming majority of the clock names
don't have such repetition in their name though. If we start doing
custom mangling on specific clocks it is going to become a nightmare
to track. As I mentioned previously there are thousands of clocks in
the SoC. Most upstream platforms only seem to implement a small subset
of clocks in each CMU which maybe makes it easier to track. Our goal
though is to have full functionality upstream.

>
> > +            CLK_CON_GAT_CLK_BLK_MISC_UID_MISC_CMU_MISC_IPCLKPORT_PCLK,
> > +            21, 0, 0),
> > +       GATE(CLK_GOUT_MISC_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK,
> > +            "gout_misc_otp_con_bira_ipclkport_i_oscclk", "dout_misc_busp",
> > +            CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK,
> > +            21, 0, 0),
> > +       GATE(CLK_GOUT_MISC_OTP_CON_BISR_IPCLKPORT_I_OSCCLK,
> > +            "gout_misc_otp_con_bisr_ipclkport_i_oscclk", "dout_misc_busp",
> > +            CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_I_OSCCLK,
> > +            21, 0, 0),
<snip>
> > +       GATE(CLK_GOUT_MISC_RTIC_IPCLKPORT_I_ACLK,
> > +            "gout_misc_rtic_ipclkport_i_aclk", "dout_misc_busp",
> > +            CLK_CON_GAT_GOUT_BLK_MISC_UID_RTIC_IPCLKPORT_I_ACLK,
> > +            21, 0, 0),
> > +       GATE(CLK_GOUT_MISC_RTIC_IPCLKPORT_I_PCLK, "gout_misc_rtic_ipclkport_i_pclk",
>
> 80 characters per line please.

Will fix

regards,

Peter


From nicolas at fjasle.eu  Fri Dec  8 03:48:11 2023
From: nicolas at fjasle.eu (Nicolas Schier)
Date: Fri, 8 Dec 2023 12:48:11 +0100
Subject: [PATCH v9 1/2] arm64: Add BOOT_TARGETS variable
In-Reply-To: <20231202035511.487946-2-sjg@chromium.org>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-2-sjg@chromium.org>
Message-ID: <ZXMCfVw7kwvfGn/i@buildd.core.avm.de>

On Fri, Dec 01, 2023 at 08:54:41PM -0700, Simon Glass wrote:
> Add a new variable containing a list of possible targets. Mark them as
> phony. This matches the approach taken for arch/arm
> 
> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---

Reviewed-by: Nicolas Schier <n.schier at avm.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/f1a879bb/attachment.sig>

From n.schier at avm.de  Fri Dec  8 03:49:05 2023
From: n.schier at avm.de (Nicolas Schier)
Date: Fri, 8 Dec 2023 12:49:05 +0100
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231202035511.487946-3-sjg@chromium.org>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-3-sjg@chromium.org>
Message-ID: <ZXMCsRgYbXXMTyHA@buildd.core.avm.de>

On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> Add a script which produces a Flat Image Tree (FIT), a single file
> containing the built kernel and associated devicetree files.
> Compression defaults to gzip which gives a good balance of size and
> performance.
> 
> The files compress from about 86MB to 24MB using this approach.
> 
> The FIT can be used by bootloaders which support it, such as U-Boot
> and Linuxboot. It permits automatic selection of the correct
> devicetree, matching the compatible string of the running board with
> the closest compatible string in the FIT. There is no need for
> filenames or other workarounds.
> 
> Add a 'make image.fit' build target for arm64, as well. Use
> FIT_COMPRESSION to select a different algorithm.
> 
> The FIT can be examined using 'dumpimage -l'.
> 
> This features requires pylibfdt (use 'pip install libfdt'). It also
> requires compression utilities for the algorithm being used. Supported
> compression options are the same as the Image.xxx files. For now there
> is no way to change the compression other than by editing the rule for
> $(obj)/image.fit
> 
> While FIT supports a ramdisk / initrd, no attempt is made to support
> this here, since it must be built separately from the Linux build.
> 
> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---

for the kbuild parts:

Reviewed-by: Nicolas Schier <n.schier at avm.de>



> Changes in v9:
> - Move the compression control into Makefile.lib
> 
> Changes in v8:
> - Drop compatible string in FDT node
> - Correct sorting of MAINTAINERS to before ARM64 PORT
> - Turn compress part of the make_fit.py comment in to a sentence
> - Add two blank lines before parse_args() and setup_fit()
> - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> - Use '$(<D)/dts' instead of '$(dir $<)dts'
> - Add 'mkimage' details Documentation/process/changes.rst
> - Allow changing the compression used
> - Tweak cover letter since there is only one clean-up patch
> 
> Changes in v7:
> - Add Image as a dependency of image.fit
> - Drop kbuild tag
> - Add dependency on dtbs
> - Drop unnecessary path separator for dtbs
> - Rebase to -next
> 
> Changes in v5:
> - Drop patch previously applied
> - Correct compression rule which was broken in v4
> 
> Changes in v4:
> - Use single quotes for UIMAGE_NAME
> 
> Changes in v3:
> - Drop temporary file image.itk
> - Drop patch 'Use double quotes for image name'
> - Drop double quotes in use of UIMAGE_NAME
> - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> - Avoid hard-coding "arm64" for the DT architecture
> 
> Changes in v2:
> - Drop patch previously applied
> - Add .gitignore file
> - Move fit rule to Makefile.lib using an intermediate file
> - Drop dependency on CONFIG_EFI_ZBOOT
> - Pick up .dtb files separately from the kernel
> - Correct pylint too-many-args warning for write_kernel()
> - Include the kernel image in the file count
> - Add a pointer to the FIT spec and mention of its wide industry usage
> - Mention the kernel version in the FIT description
> 
>  Documentation/process/changes.rst |   9 +
>  MAINTAINERS                       |   7 +
>  arch/arm64/Makefile               |   7 +-
>  arch/arm64/boot/.gitignore        |   1 +
>  arch/arm64/boot/Makefile          |   6 +-
>  scripts/Makefile.lib              |  16 ++
>  scripts/make_fit.py               | 291 ++++++++++++++++++++++++++++++
>  7 files changed, 334 insertions(+), 3 deletions(-)
>  create mode 100755 scripts/make_fit.py
> 
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index bb96ca0f774b..cad51bd5bd62 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -62,6 +62,7 @@ Sphinx\ [#f1]_         1.7              sphinx-build --version
>  cpio                   any              cpio --version
>  GNU tar                1.28             tar --version
>  gtags (optional)       6.6.5            gtags --version
> +mkimage (optional)     2017.01          mkimage --version
>  ====================== ===============  ========================================
>  
>  .. [#f1] Sphinx is needed only to build the Kernel documentation
> @@ -189,6 +190,14 @@ The kernel build requires GNU GLOBAL version 6.6.5 or later to generate
>  tag files through ``make gtags``.  This is due to its use of the gtags
>  ``-C (--directory)`` flag.
>  
> +mkimage
> +-------
> +
> +This tool is used when building a Flat Image Tree (FIT), commonly used on ARM
> +platforms. The tool is available via the ``u-boot-tools`` package or can be
> +built from the U-Boot source code. See the instructions at
> +https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
> +
>  System utilities
>  ****************
>  
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9d46229fe21b..d2d17f0d6e64 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3037,6 +3037,13 @@ F:	drivers/mmc/host/sdhci-of-arasan.c
>  N:	zynq
>  N:	xilinx
>  
> +ARM64 FIT SUPPORT
> +M:	Simon Glass <sjg at chromium.org>
> +L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S:	Maintained
> +F:	arch/arm64/boot/Makefile
> +F:	scripts/make_fit.py
> +
>  ARM64 PORT (AARCH64 ARCHITECTURE)
>  M:	Catalin Marinas <catalin.marinas at arm.com>
>  M:	Will Deacon <will at kernel.org>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 1bd4fae6e806..6b893dc454b7 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -150,7 +150,7 @@ libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>  # Default target when executing plain make
>  boot		:= arch/arm64/boot
>  
> -BOOT_TARGETS	:= Image vmlinuz.efi
> +BOOT_TARGETS	:= Image vmlinuz.efi image.fit
>  
>  PHONY += $(BOOT_TARGETS)
>  
> @@ -162,7 +162,9 @@ endif
>  
>  all:	$(notdir $(KBUILD_IMAGE))
>  
> -vmlinuz.efi: Image
> +image.fit: dtbs
> +
> +vmlinuz.efi image.fit: Image
>  $(BOOT_TARGETS): vmlinux
>  	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
>  
> @@ -215,6 +217,7 @@ virtconfig:
>  define archhelp
>    echo  '* Image.gz      - Compressed kernel image (arch/$(ARCH)/boot/Image.gz)'
>    echo  '  Image         - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
> +  echo  '  image.fit     - Flat Image Tree (arch/$(ARCH)/boot/image.fit)'
>    echo  '  install       - Install uncompressed kernel'
>    echo  '  zinstall      - Install compressed kernel'
>    echo  '                  Install using (your) ~/bin/installkernel or'
> diff --git a/arch/arm64/boot/.gitignore b/arch/arm64/boot/.gitignore
> index af5dc61f8b43..abaae9de1bdd 100644
> --- a/arch/arm64/boot/.gitignore
> +++ b/arch/arm64/boot/.gitignore
> @@ -2,3 +2,4 @@
>  Image
>  Image.gz
>  vmlinuz*
> +image.fit
> diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
> index 1761f5972443..b835c0880d1c 100644
> --- a/arch/arm64/boot/Makefile
> +++ b/arch/arm64/boot/Makefile
> @@ -16,7 +16,8 @@
>  
>  OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
>  
> -targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo Image.zst
> +targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo \
> +	Image.zst image.fit
>  
>  $(obj)/Image: vmlinux FORCE
>  	$(call if_changed,objcopy)
> @@ -39,6 +40,9 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
>  $(obj)/Image.zst: $(obj)/Image FORCE
>  	$(call if_changed,zstd)
>  
> +$(obj)/image.fit: $(obj)/Image FORCE
> +	$(call cmd,fit)
> +
>  EFI_ZBOOT_PAYLOAD	:= Image
>  EFI_ZBOOT_BFD_TARGET	:= elf64-littleaarch64
>  EFI_ZBOOT_MACH_TYPE	:= ARM64
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 1a965fe68e01..1c60d594932c 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -496,6 +496,22 @@ quiet_cmd_uimage = UIMAGE  $@
>  			-a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \
>  			-n '$(UIMAGE_NAME)' -d $< $@
>  
> +# Flat Image Tree (FIT)
> +# This allows for packaging of a kernel and all devicetrees files, using
> +# compression.
> +# ---------------------------------------------------------------------------
> +
> +MAKE_FIT := $(srctree)/scripts/make_fit.py
> +
> +# Use this to override the compression algorithm
> +FIT_COMPRESSION ?= gzip
> +
> +quiet_cmd_fit = FIT     $@
> +      cmd_fit = $(MAKE_FIT) -f $@ --arch $(UIMAGE_ARCH) --os linux \
> +			--name '$(UIMAGE_NAME)' \
> +			--compress $(FIT_COMPRESSION) -k $< \
> +			$(<D)/dts
> +
>  # XZ
>  # ---------------------------------------------------------------------------
>  # Use xzkern to compress the kernel image and xzmisc to compress other things.
> diff --git a/scripts/make_fit.py b/scripts/make_fit.py
> new file mode 100755
> index 000000000000..e616b0d7a84a
> --- /dev/null
> +++ b/scripts/make_fit.py
> @@ -0,0 +1,291 @@
> +#!/usr/bin/env python3
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright 2023 Google LLC
> +# Written by Simon Glass <sjg at chromium.org>
> +#
> +
> +"""Build a FIT containing a lot of devicetree files
> +
> +Usage:
> +    make_fit.py -A arm64 -n 'Linux-6.6' -O linux
> +        -f arch/arm64/boot/image.fit -k /tmp/kern/arch/arm64/boot/image.itk
> +        /tmp/kern/arch/arm64/boot/dts/ -E -c gzip
> +
> +Creates a FIT containing the supplied kernel and a directory containing the
> +devicetree files.
> +
> +Use -E to generate an external FIT (where the data is placed after the
> +FIT data structure). This allows parsing of the data without loading
> +the entire FIT.
> +
> +Use -c to compress the data, using bzip2, gzip, lz4, lzma, lzo and
> +zstd algorithms.
> +
> +The resulting FIT can be booted by bootloaders which support FIT, such
> +as U-Boot, Linuxboot, Tianocore, etc.
> +
> +Note that this tool does not yet support adding a ramdisk / initrd.
> +"""
> +
> +import argparse
> +import collections
> +import os
> +import subprocess
> +import sys
> +import tempfile
> +import time
> +
> +import libfdt
> +
> +
> +# Tool extension and the name of the command-line tools
> +CompTool = collections.namedtuple('CompTool', 'ext,tools')
> +
> +COMP_TOOLS = {
> +    'bzip2': CompTool('.bz2', 'bzip2'),
> +    'gzip': CompTool('.gz', 'pigz,gzip'),
> +    'lz4': CompTool('.lz4', 'lz4'),
> +    'lzma': CompTool('.lzma', 'lzma'),
> +    'lzo': CompTool('.lzo', 'lzop'),
> +    'zstd': CompTool('.zstd', 'zstd'),
> +}
> +
> +
> +def parse_args():
> +    """Parse the program ArgumentParser
> +
> +    Returns:
> +        Namespace object containing the arguments
> +    """
> +    epilog = 'Build a FIT from a directory tree containing .dtb files'
> +    parser = argparse.ArgumentParser(epilog=epilog)
> +    parser.add_argument('-A', '--arch', type=str, required=True,
> +          help='Specifies the architecture')
> +    parser.add_argument('-c', '--compress', type=str, default='none',
> +          help='Specifies the compression')
> +    parser.add_argument('-E', '--external', action='store_true',
> +          help='Convert the FIT to use external data')
> +    parser.add_argument('-n', '--name', type=str, required=True,
> +          help='Specifies the name')
> +    parser.add_argument('-O', '--os', type=str, required=True,
> +          help='Specifies the operating system')
> +    parser.add_argument('-f', '--fit', type=str, required=True,
> +          help='Specifies the output file (.fit)')
> +    parser.add_argument('-k', '--kernel', type=str, required=True,
> +          help='Specifies the (uncompressed) kernel input file (.itk)')
> +    parser.add_argument('srcdir', type=str, nargs='*',
> +          help='Specifies the directory tree that contains .dtb files')
> +
> +    return parser.parse_args()
> +
> +
> +def setup_fit(fsw, name):
> +    """Make a start on writing the FIT
> +
> +    Outputs the root properties and the 'images' node
> +
> +    Args:
> +        fsw (libfdt.FdtSw): Object to use for writing
> +        name (str): Name of kernel image
> +    """
> +    fsw.INC_SIZE = 65536
> +    fsw.finish_reservemap()
> +    fsw.begin_node('')
> +    fsw.property_string('description', f'{name} with devicetree set')
> +    fsw.property_u32('#address-cells', 1)
> +
> +    fsw.property_u32('timestamp', int(time.time()))
> +    fsw.begin_node('images')
> +
> +
> +def write_kernel(fsw, data, args):
> +    """Write out the kernel image
> +
> +    Writes a kernel node along with the required properties
> +
> +    Args:
> +        fsw (libfdt.FdtSw): Object to use for writing
> +        data (bytes): Data to write (possibly compressed)
> +        args (Namespace): Contains necessary strings:
> +            arch: FIT architecture, e.g. 'arm64'
> +            fit_os: Operating Systems, e.g. 'linux'
> +            name: Name of OS, e.g. 'Linux-6.6.0-rc7'
> +            compress: Compression algorithm to use, e.g. 'gzip'
> +    """
> +    with fsw.add_node('kernel'):
> +        fsw.property_string('description', args.name)
> +        fsw.property_string('type', 'kernel_noload')
> +        fsw.property_string('arch', args.arch)
> +        fsw.property_string('os', args.os)
> +        fsw.property_string('compression', args.compress)
> +        fsw.property('data', data)
> +        fsw.property_u32('load', 0)
> +        fsw.property_u32('entry', 0)
> +
> +
> +def finish_fit(fsw, entries):
> +    """Finish the FIT ready for use
> +
> +    Writes the /configurations node and subnodes
> +
> +    Args:
> +        fsw (libfdt.FdtSw): Object to use for writing
> +        entries (list of tuple): List of configurations:
> +            str: Description of model
> +            str: Compatible stringlist
> +    """
> +    fsw.end_node()
> +    seq = 0
> +    with fsw.add_node('configurations'):
> +        for model, compat in entries:
> +            seq += 1
> +            with fsw.add_node(f'conf-{seq}'):
> +                fsw.property('compatible', bytes(compat))
> +                fsw.property_string('description', model)
> +                fsw.property_string('fdt', f'fdt-{seq}')
> +                fsw.property_string('kernel', 'kernel')
> +    fsw.end_node()
> +
> +
> +def compress_data(inf, compress):
> +    """Compress data using a selected algorithm
> +
> +    Args:
> +        inf (IOBase): Filename containing the data to compress
> +        compress (str): Compression algorithm, e.g. 'gzip'
> +
> +    Return:
> +        bytes: Compressed data
> +    """
> +    if compress == 'none':
> +        return inf.read()
> +
> +    comp = COMP_TOOLS.get(compress)
> +    if not comp:
> +        raise ValueError(f"Unknown compression algorithm '{compress}'")
> +
> +    with tempfile.NamedTemporaryFile() as comp_fname:
> +        with open(comp_fname.name, 'wb') as outf:
> +            done = False
> +            for tool in comp.tools.split(','):
> +                try:
> +                    subprocess.call([tool, '-c'], stdin=inf, stdout=outf)
> +                    done = True
> +                    break
> +                except FileNotFoundError:
> +                    pass
> +            if not done:
> +                raise ValueError(f'Missing tool(s): {comp.tools}\n')
> +            with open(comp_fname.name, 'rb') as compf:
> +                comp_data = compf.read()
> +    return comp_data
> +
> +
> +def output_dtb(fsw, seq, fname, arch, compress):
> +    """Write out a single devicetree to the FIT
> +
> +    Args:
> +        fsw (libfdt.FdtSw): Object to use for writing
> +        seq (int): Sequence number (1 for first)
> +        fmame (str): Filename containing the DTB
> +        arch: FIT architecture, e.g. 'arm64'
> +        compress (str): Compressed algorithm, e.g. 'gzip'
> +
> +    Returns:
> +        tuple:
> +            str: Model name
> +            bytes: Compatible stringlist
> +    """
> +    with fsw.add_node(f'fdt-{seq}'):
> +        # Get the compatible / model information
> +        with open(fname, 'rb') as inf:
> +            data = inf.read()
> +        fdt = libfdt.FdtRo(data)
> +        model = fdt.getprop(0, 'model').as_str()
> +        compat = fdt.getprop(0, 'compatible')
> +
> +        fsw.property_string('description', model)
> +        fsw.property_string('type', 'flat_dt')
> +        fsw.property_string('arch', arch)
> +        fsw.property_string('compression', compress)
> +        fsw.property('compatible', bytes(compat))
> +
> +        with open(fname, 'rb') as inf:
> +            compressed = compress_data(inf, compress)
> +        fsw.property('data', compressed)
> +    return model, compat
> +
> +
> +def build_fit(args):
> +    """Build the FIT from the provided files and arguments
> +
> +    Args:
> +        args (Namespace): Program arguments
> +
> +    Returns:
> +        tuple:
> +            bytes: FIT data
> +            int: Number of configurations generated
> +            size: Total uncompressed size of data
> +    """
> +    fsw = libfdt.FdtSw()
> +    setup_fit(fsw, args.name)
> +    seq = 0
> +    size = 0
> +    entries = []
> +
> +    # Handle the kernel
> +    with open(args.kernel, 'rb') as inf:
> +        comp_data = compress_data(inf, args.compress)
> +    size += os.path.getsize(args.kernel)
> +    write_kernel(fsw, comp_data, args)
> +
> +    for path in args.srcdir:
> +        # Handle devicetree files
> +        if os.path.isdir(path):
> +            for dirpath, _, fnames in os.walk(path):
> +                for fname in fnames:
> +                    if os.path.splitext(fname)[1] != '.dtb':
> +                        continue
> +                    pathname = os.path.join(dirpath, fname)
> +                    seq += 1
> +                    size += os.path.getsize(pathname)
> +                    model, compat = output_dtb(fsw, seq, pathname,
> +                                               args.arch, args.compress)
> +                    entries.append([model, compat])
> +
> +    finish_fit(fsw, entries)
> +
> +    # Include the kernel itself in the returned file count
> +    return fsw.as_fdt().as_bytearray(), seq + 1, size
> +
> +
> +def run_make_fit():
> +    """Run the tool's main logic"""
> +    args = parse_args()
> +
> +    out_data, count, size = build_fit(args)
> +    with open(args.fit, 'wb') as outf:
> +        outf.write(out_data)
> +
> +    ext_fit_size = None
> +    if args.external:
> +        mkimage = os.environ.get('MKIMAGE', 'mkimage')
> +        subprocess.check_call([mkimage, '-E', '-F', args.fit],
> +                              stdout=subprocess.DEVNULL)
> +
> +        with open(args.fit, 'rb') as inf:
> +            data = inf.read()
> +        ext_fit = libfdt.FdtRo(data)
> +        ext_fit_size = ext_fit.totalsize()
> +
> +    comp_size = len(out_data)
> +    print(f'FIT size {comp_size:#x}/{comp_size / 1024 / 1024:.1f} MB', end='')
> +    if ext_fit_size:
> +        print(f', header {ext_fit_size:#x}/{ext_fit_size / 1024:.1f} KB', end='')
> +    print(f', {count} files, uncompressed {size / 1024 / 1024:.1f} MB')
> +
> +
> +if __name__ == "__main__":
> +    sys.exit(run_make_fit())
> -- 
> 2.43.0.rc2.451.g8631bc7472-goog
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/cf3966e1/attachment-0001.sig>

From robin.murphy at arm.com  Fri Dec  8 03:49:10 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 8 Dec 2023 11:49:10 +0000
Subject: [PATCH] iommu/arm-smmu-qcom: Add missing GMU entry to match table
In-Reply-To: <20231207212441.6199-1-robdclark@gmail.com>
References: <20231207212441.6199-1-robdclark@gmail.com>
Message-ID: <8e4b3c92-f2e4-48f3-848e-776a64fe1d31@arm.com>

On 07/12/2023 9:24 pm, Rob Clark wrote:
> From: Rob Clark <robdclark at chromium.org>
> 
> We also want the default domain for the GMU to be an identy domain,
> so it does not get a context bank assigned.  Without this, both
> of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
> allocating and configuring a context bank.  So GMU ends up attached
> to both cbndx 1 and cbndx 2.

I can't help but read this as implying that it gets attached to both *at 
the same time*, which would be indicative of a far more serious problem 
in the main driver and/or IOMMU core code.

However, from what we discussed on IRC last night, it sounds like the 
key point here is more straightforwardly that firmware expects the GMU 
to be using context bank 1, in a vaguely similar fashion to how context 
bank 0 is special for the GPU. Clarifying that would help explain why 
we're just doing this as a trick to influence the allocator (i.e. unlike 
some of the other devices in this list we don't actually need the 
properties of the identity domain itself).

In future it might be nice to reserve this explicitly on platforms which 
need it and extend qcom_adreno_smmu_alloc_context_bank() to handle the 
GMU as well, but I don't object to this patch as an immediate quick fix 
for now, especially as something nice and easy for stable (I'd agree 
with Johan in that regard).

Thanks,
Robin.

>  This arrangement seemingly confounds
> and surprises the firmware if the GPU later triggers a translation
> fault, resulting (on sc8280xp / lenovo x13s, at least) in the SMMU
> getting wedged and the GPU stuck without memory access.
> 
> Signed-off-by: Rob Clark <robdclark at chromium.org>
> ---
>   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index 549ae4dba3a6..d326fa230b96 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -243,6 +243,7 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
>   
>   static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
>   	{ .compatible = "qcom,adreno" },
> +	{ .compatible = "qcom,adreno-gmu" },
>   	{ .compatible = "qcom,mdp4" },
>   	{ .compatible = "qcom,mdss" },
>   	{ .compatible = "qcom,sc7180-mdss" },


From p.zabel at pengutronix.de  Fri Dec  8 03:49:05 2023
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 08 Dec 2023 12:49:05 +0100
Subject: [PATCH 3/9] PCI: imx6: Simplify reset handling by using by
 using *_FLAG_HAS_*_RESET
In-Reply-To: <ZXH8guDh+pLbg0Tn@lizhi-Precision-Tower-5810>
References: <20231206155903.566194-1-Frank.Li@nxp.com>
	 <20231206155903.566194-4-Frank.Li@nxp.com>
	 <e314466b31dd8e88212ae5d7ac2fecf26b851829.camel@pengutronix.de>
	 <ZXH8guDh+pLbg0Tn@lizhi-Precision-Tower-5810>
Message-ID: <95ef7a9fa76bf3d6fd17c9fbf00d7d561883765c.camel@pengutronix.de>

On Do, 2023-12-07 at 12:10 -0500, Frank Li wrote:
> On Wed, Dec 06, 2023 at 05:52:23PM +0100, Philipp Zabel wrote:
[...]
> > I wonder whether we should just defer the check whether apps/pciephy
> > resets should be used to the device tree validation, and make this an
> > unconditional call to get an optional reset control:
> > 
> > 	imx6_pcie->apps_reset = devm_reset_control_get_optional_exclusive(dev, "apps");
> 
> I think double check here is neccesary. No sure if dts file version
> binding yaml was exactly matched driver. Sometime user use old version dts. 
> Double check here will help identify the dts problem. 

Makes sense to me,

Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>

regards
Philipp


From n-francis at ti.com  Fri Dec  8 03:49:12 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 8 Dec 2023 17:19:12 +0530
Subject: [PATCH v10 0/7] Add TPS6594 PMIC support on several boards
Message-ID: <20231208114919.3429562-1-n-francis@ti.com>

TPS6594 is a Power Management IC which provides regulators and others
features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can
communicate through the I2C or SPI interfaces.
TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives.

This series adds device tree nodes for TI TPS6594 PMICs found in the
following boards:
- J721EXSOMXEVM:
  Link: https://www.ti.com/tool/J721EXSOMXEVM
- J721S2XSOMXEVM:
  Link: https://www.ti.com/tool/J721S2XSOMXEVM
- J7200XSOMXEVM:
  Link: https://www.ti.com/tool/J7200XSOMXEVM
- J784S4XEVM
  Link: https://www.ti.com/tool/J784S4XEVM
- SK-AM69
  Link: https://www.ti.com/tool/SK-AM69
- SK-TDA4VM (J721E-SK)
  Link: https://www.ti.com/tool/SK-TDA4VM

Boot Logs with required config (DONOTMERGE patch) enabled:
https://gist.github.com/nehamalcom/f47fcd6183360ed8a146c9ba456202c3
Boot Logs without config enabled:
https://gist.github.com/nehamalcom/58217b100e614ae55726f314e02b5001

---
Changes from v9:
https://lore.kernel.org/all/20231205093439.2298296-1-n-francis at ti.com/
- moved from wkup_pmx1 to wkup_pmx2 (Udit)
- changed boot logs for AM68-SK to the latest one
- removed Tested-by tag for AM68-SK
- modified order of properties in line with latest kernel DTS
  conventions

Changes from v8:
https://lore.kernel.org/all/20231128055230.342547-4-n-francis at ti.com/
- added bootph-pre-ram to AVS regulator (Udit)
- keeping boot logs and Tested-by tags the same (no effect to kernel)

Changes from v7:
https://lore.kernel.org/all/20231122104513.2335757-1-n-francis at ti.com/
- (New Patches) Add support for SK boards that have TPS6594xx PMIC
  present (J721E-SK and AM69-SK) (Nishanth)
- Add DONOTMERGE defconfig patch to show test logs

Changes from v6:
https://lore.kernel.org/all/20230810-tps6594-v6-0-2b2e2399e2ef at ti.com/
- Modify patch series to include only patches not merged (J7)
- Add boot logs for all affected boards

Changes from v5:
https://lore.kernel.org/all/20230809-tps6594-v5-0-485fd3d63670 at ti.com
- Range-diff: http://0x0.st/H_fD.diff
- Reword the patch fixing interrupt ranges for mcu domain gpio intr, and
  add Fixes: tag
- Also fix interrupt ranges for main domain gpio intr in the same patch
- Change pinctrl node names to end in -pins to fix dtbs_check warnings
- (New Patch) Enable TPS6594 in defconfig

Changes from v4:
https://lore.kernel.org/all/20230727130908.10656-1-eblanc at baylibre.com/
- Range-diff: https://0x0.st/H_L7.diff
- Rebased on top of linux-next
- Fix min voltage on vdd_usb_3v3 regulator (ldo2) on j721e-som
- Use 3-hex-digit format for pinctrl values

Changes from v3:
https://lore.kernel.org/all/20230417154832.216774-1-eblanc at baylibre.com/
- Rebased on top of v6.5-rc1.
- Change pinctrl number for irq pin as wkup_pmx0 was split on some boards.
- Use already present wkup_i2c0 node instead of creating a new one.

Changes from v2:
https://lore.kernel.org/lkml/20230414112843.1358067-1-eblanc at baylibre.com/
- Change node name as per Krzysztof review.
- Add a fix for the interrupt range of wakeup gpio used by TPS6594 pmic
  on J784S4.
  The interruptions of the PMIC were not working before that.
- Remove dependencies on other patch series as that was a mistake, see
  https://lore.kernel.org/lkml/CRYY2V3HJ0CP.96JQ18PLZB3C at burritosblues/

Changes from v1:
https://lore.kernel.org/lkml/20230329142948.833800-1-eblanc at baylibre.com/
- Harmonize regulators names across the different boards.
- Adjust AVS voltage range.
- Remove some outdated comments.
- Add PMIC to J784S4 board.
- Compatible string modified to match dt-bindings.
- Add gpio-controller and gpio-cells properties.

Esteban Blanc (2):
  arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
  arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs

Jerome Neanne (2):
  arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
  arm64: dts: ti: k3-j784s4-evm: Add support for TPS6594 PMIC

Neha Malcom Francis (3):
  arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC
  arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs
  DONOTMERGE: arm64: defconfig: Enable TPS6594 PMIC for J7 devices

 arch/arm64/boot/dts/ti/k3-am69-sk.dts        |  94 +++++++++
 arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi  | 153 +++++++++++++++
 arch/arm64/boot/dts/ti/k3-j721e-sk.dts       | 151 +++++++++++++++
 arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi  | 160 +++++++++++++++
 arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 193 +++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-j784s4-evm.dts     | 102 ++++++++++
 arch/arm64/configs/defconfig                 |   2 +-
 7 files changed, 854 insertions(+), 1 deletion(-)

-- 
2.34.1



From n-francis at ti.com  Fri Dec  8 03:49:13 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 8 Dec 2023 17:19:13 +0530
Subject: [PATCH v10 1/7] arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
In-Reply-To: <20231208114919.3429562-1-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
Message-ID: <20231208114919.3429562-2-n-francis@ti.com>

From: Esteban Blanc <eblanc at baylibre.com>

This patch adds support for TPS6594 PMIC family on wakup I2C0 bus.
Theses devices provides regulators (bucks and LDOs), but also
GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
which monitors the SoC error output signal, and a PFSM
(Pre-configurable Finite State Machine) which manages the
operational modes of the PMIC.

Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
Signed-off-by: Jai Luthra <j-luthra at ti.com>
Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 153 ++++++++++++++++++++
 1 file changed, 153 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
index 5a300d4c8ba0..ea47f10d393a 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
@@ -127,6 +127,14 @@ J721E_WKUP_IOPAD(0x9c, PIN_INPUT_PULLUP, 0) /* (H21) WKUP_I2C0_SDA */
 	};
 };
 
+&wkup_pmx3 {
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		pinctrl-single,pins = <
+			J721E_WKUP_IOPAD(0x01c, PIN_INPUT, 7) /* (E18) WKUP_GPIO0_84 */
+		>;
+	};
+};
+
 &main_pmx0 {
 	main_i2c0_pins_default: main-i2c0-default-pins {
 		pinctrl-single,pins = <
@@ -264,6 +272,151 @@ eeprom at 50 {
 		compatible = "atmel,24c256";
 		reg = <0x50>;
 	};
+
+	tps659414: pmic at 48 {
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <84 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ti,primary-pmic;
+		buck1-supply = <&vsys_3v3>;
+		buck2-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bucka1: buck1 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka2: buck2 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka3: buck3 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_phyio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd1_lpddr4_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vda_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vdd_wk_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_pll_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	lp876441: pmic at 4c {
+		compatible = "ti,lp8764-q1";
+		reg = <0x4c>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <84 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		buck1-supply = <&vsys_3v3>;
+		buck2-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+
+		regulators: regulators {
+			buckb1: buck1 {
+				regulator-name = "vdd_cpu_avs";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <900000>;
+				regulator-always-on;
+				regulator-boot-on;
+				bootph-pre-ram;
+			};
+
+			buckb2: buck2 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb3: buck3 {
+				regulator-name = "vdd_core_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb4: buck4 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &ospi0 {
-- 
2.34.1



From n-francis at ti.com  Fri Dec  8 03:49:14 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 8 Dec 2023 17:19:14 +0530
Subject: [PATCH v10 2/7] arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs
In-Reply-To: <20231208114919.3429562-1-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
Message-ID: <20231208114919.3429562-3-n-francis@ti.com>

From: Esteban Blanc <eblanc at baylibre.com>

This patch adds support for TPS6594 PMIC family on wakup I2C0 bus.
Theses devices provides regulators (bucks and LDOs), but also
GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
which monitors the SoC error output signal, and a PFSM
(Pre-configurable Finite State Machine) which manages the
operational modes of the PMIC.

Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
Signed-off-by: Jai Luthra <j-luthra at ti.com>
Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 193 +++++++++++++++++++
 1 file changed, 193 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
index dcad372620b1..da3237b23b63 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
@@ -172,6 +172,15 @@ J721S2_WKUP_IOPAD(0x004, PIN_INPUT, 0) /* (E20) MCU_OSPI0_LBCLKO */
 	};
 };
 
+&wkup_pmx1 {
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		pinctrl-single,pins = <
+			/* (C21) MCU_OSPI1_CSn1.WKUP_GPIO0_39 */
+			J721S2_WKUP_IOPAD(0x028, PIN_INPUT, 7)
+		>;
+	};
+};
+
 &wkup_pmx2 {
 	wkup_i2c0_pins_default: wkup-i2c0-default-pins {
 		pinctrl-single,pins = <
@@ -208,6 +217,190 @@ eeprom at 50 {
 		compatible = "atmel,24c256";
 		reg = <0x50>;
 	};
+
+	tps659411: pmic at 48 {
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ti,primary-pmic;
+		buck1234-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bucka1234: buck1234 {
+				regulator-name = "vdd_cpu_avs";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <900000>;
+				regulator-boot-on;
+				regulator-always-on;
+				bootph-pre-ram;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd_mcuwk_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcu_gpioret_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	tps659414: pmic at 4c {
+		compatible = "ti,tps6594-q1";
+		reg = <0x4c>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		buck1-supply = <&vsys_3v3>;
+		buck2-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			buckb1: buck1 {
+				regulator-name = "vdd_io_1v8_reg";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			buckb2: buck2 {
+				regulator-name = "vdd_fpd_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb3: buck3 {
+				regulator-name = "vdd_phy_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb4: buck4 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb5: buck5 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob1: ldo1 {
+				regulator-name = "vdd_wk_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob2: ldo2 {
+				regulator-name = "vdd_gpioret_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob3: ldo3 {
+				regulator-name = "vda_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob4: ldo4 {
+				regulator-name = "vda_pll_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	lp876411: pmic at 58 {
+		compatible = "ti,lp8764-q1";
+		reg = <0x58>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		buck1234-supply = <&vsys_3v3>;
+
+		regulators {
+			buckc1234: buck1234 {
+				regulator-name = "vdd_core_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &main_i2c0 {
-- 
2.34.1



From n-francis at ti.com  Fri Dec  8 03:49:15 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 8 Dec 2023 17:19:15 +0530
Subject: [PATCH v10 3/7] arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
In-Reply-To: <20231208114919.3429562-1-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
Message-ID: <20231208114919.3429562-4-n-francis@ti.com>

From: Jerome Neanne <jneanne at baylibre.com>

This patch adds support for TPS6594 PMIC family on wakup I2C0 bus.
Theses devices provides regulators (bucks and LDOs), but also
GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
which monitors the SoC error output signal, and a PFSM
(Pre-configurable Finite State Machine) which manages the
operational modes of the PMIC.

Signed-off-by: Jerome Neanne <jneanne at baylibre.com>
Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
Signed-off-by: Jai Luthra <j-luthra at ti.com>
Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi | 160 ++++++++++++++++++++
 1 file changed, 160 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
index 7f0686c2ce37..a75611eec791 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
@@ -152,6 +152,12 @@ J721E_WKUP_IOPAD(0xfc, PIN_INPUT_PULLUP, 0) /* (H24) WKUP_I2C0_SDA */
 		>;
 	};
 
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		pinctrl-single,pins = <
+			J721E_WKUP_IOPAD(0x0d4, PIN_INPUT, 7) /* (G26) WKUP_GPIO0_9 */
+		>;
+	};
+
 	mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-default-pins {
 		pinctrl-single,pins = <
 			J721E_WKUP_IOPAD(0x0000, PIN_OUTPUT, 0) /* MCU_OSPI0_CLK */
@@ -199,6 +205,160 @@ eeprom at 50 {
 		compatible = "atmel,24c256";
 		reg = <0x50>;
 	};
+
+	tps659413: pmic at 48 {
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ti,primary-pmic;
+		buck12-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bucka12: buck12 {
+				regulator-name = "vdd_cpu_avs";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <900000>;
+				regulator-boot-on;
+				regulator-always-on;
+				bootph-pre-ram;
+			};
+
+			bucka3: buck3 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_phyio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd1_lpddr4_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vdda_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	tps659411: pmic at 4c {
+		compatible = "ti,tps6594-q1";
+		reg = <0x4c>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		buck1234-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			buckb1234: buck1234 {
+				regulator-name = "vdd_core_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb5: buck5 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob1: ldo1 {
+				regulator-name = "vdd_sd_dv";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob2: ldo2 {
+				regulator-name = "vdd_usb_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob3: ldo3 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob4: ldo4 {
+				regulator-name = "vda_pll_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &ospi0 {
-- 
2.34.1



From n-francis at ti.com  Fri Dec  8 03:49:16 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 8 Dec 2023 17:19:16 +0530
Subject: [PATCH v10 4/7] arm64: dts: ti: k3-j784s4-evm: Add support for TPS6594 PMIC
In-Reply-To: <20231208114919.3429562-1-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
Message-ID: <20231208114919.3429562-5-n-francis@ti.com>

From: Jerome Neanne <jneanne at baylibre.com>

This patch adds support for TPS6593 PMIC on wkup I2C0 bus.
This device provides regulators (bucks and LDOs), but also
GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
which monitors the SoC error output signal, and a PFSM
(Pre-configurable Finite State Machine) which manages the
operational modes of the PMIC.

Signed-off-by: Jerome Neanne <jneanne at baylibre.com>
Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
Signed-off-by: Jai Luthra <j-luthra at ti.com>
Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 102 +++++++++++++++++++++++
 1 file changed, 102 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
index f1f4c8634ab6..f34b92acc56d 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
@@ -273,6 +273,10 @@ dp0_connector_in: endpoint {
 	};
 };
 
+&wkup_gpio0 {
+	status = "okay";
+};
+
 &main_pmx0 {
 	bootph-all;
 	main_uart8_pins_default: main-uart8-default-pins {
@@ -407,6 +411,17 @@ J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
 	};
 };
 
+&wkup_pmx1 {
+	status = "okay";
+
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		pinctrl-single,pins = <
+			/* (G33) MCU_OSPI1_CSn1.WKUP_GPIO0_39 */
+			J784S4_WKUP_IOPAD(0x028, PIN_INPUT, 7)
+		>;
+	};
+};
+
 &wkup_pmx0 {
 	bootph-all;
 	mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-default-pins {
@@ -471,6 +486,93 @@ eeprom at 50 {
 		compatible = "atmel,24c256";
 		reg = <0x50>;
 	};
+
+	tps659413: pmic at 48 {
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ti,primary-pmic;
+		buck12-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bucka12: buck12 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka3: buck3 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcuio_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vds_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &mcu_uart0 {
-- 
2.34.1



From n-francis at ti.com  Fri Dec  8 03:49:17 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 8 Dec 2023 17:19:17 +0530
Subject: [PATCH v10 5/7] arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC
In-Reply-To: <20231208114919.3429562-1-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
Message-ID: <20231208114919.3429562-6-n-francis@ti.com>

This patch adds support for TPS6594 PMIC on wkup I2C0 bus. This device
provides regulators (bucks and LDOs), but also GPIOs, a RTC, a watchdog,
an ESM (Error Signal Monitor) which monitors the SoC error output
signal, and a PFSM (Pre-configurable Finite State Machine) which manages
the operational modes of the PMIC.

Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am69-sk.dts | 94 +++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
index d6a7ae086244..8da591579868 100644
--- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
@@ -433,6 +433,13 @@ J784S4_IOPAD(0x000, PIN_INPUT, 7) /* (AN35) EXTINTN.GPIO0_0 */
 
 &wkup_pmx2 {
 	bootph-all;
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		pinctrl-single,pins = <
+			/* (AA37) MCU_ADC1_AIN4.WKUP_GPIO0_83 */
+			J784S4_WKUP_IOPAD(0x0fc, PIN_INPUT, 7)
+		>;
+	};
+
 	wkup_uart0_pins_default: wkup-uart0-default-pins {
 		bootph-all;
 		pinctrl-single,pins = <
@@ -631,6 +638,93 @@ eeprom at 51 {
 		compatible = "atmel,24c512";
 		reg = <0x51>;
 	};
+
+	tps659413: pmic at 48 {
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ti,primary-pmic;
+		buck12-supply = <&vsys_3v3>;
+		buck3-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bucka12: buck12 {
+				regulator-name = "vdd_ddr_1v1";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka3: buck3 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcuio_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vds_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &wkup_gpio0 {
-- 
2.34.1



From n-francis at ti.com  Fri Dec  8 03:49:18 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 8 Dec 2023 17:19:18 +0530
Subject: [PATCH v10 6/7] arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs
In-Reply-To: <20231208114919.3429562-1-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
Message-ID: <20231208114919.3429562-7-n-francis@ti.com>

This patch adds support for TPS6594 PMIC family on wakeup I2C0 bus.
These devices provide regulators (bucks and LDOs), but also GPIOs, a
RTC, a watchdog, an ESM (Error Signal Monitor) which monitors the SoC
error output signal, and a PFSM (Pre-configurable Finite State Machine)
which manages the operational modes of the PMIC.

Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 151 +++++++++++++++++++++++++
 1 file changed, 151 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
index 42fe8eee9ec8..188dfe291a32 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
@@ -459,6 +459,12 @@ J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3) EXT_REFCLK1.GPIO1_12 */
 };
 
 &wkup_pmx0 {
+	pmic_irq_pins_default: pmic-irq-default-pins {
+		pinctrl-single,pins = <
+			J721E_WKUP_IOPAD(0x0cc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
+		>;
+	};
+
 	mcu_cpsw_pins_default: mcu-cpsw-default-pins {
 		pinctrl-single,pins = <
 			J721E_WKUP_IOPAD(0x84, PIN_INPUT, 0) /* (B24) MCU_RGMII1_RD0 */
@@ -560,6 +566,151 @@ eeprom at 51 {
 		compatible = "atmel,24c512";
 		reg = <0x51>;
 	};
+
+	tps659413: pmic at 48 {
+		compatible = "ti,tps6594-q1";
+		reg = <0x48>;
+		system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_irq_pins_default>;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ti,primary-pmic;
+		buck123-supply = <&vsys_3v3>;
+		buck4-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			bucka123: buck123 {
+				regulator-name = "vdd_cpu_avs";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <900000>;
+				regulator-boot-on;
+				regulator-always-on;
+				bootph-pre-ram;
+			};
+
+			bucka4: buck4 {
+				regulator-name = "vdd_mcu_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			bucka5: buck5 {
+				regulator-name = "vdd_phyio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa1: ldo1 {
+				regulator-name = "vdd1_lpddr4_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa2: ldo2 {
+				regulator-name = "vdd_mcuio_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa3: ldo3 {
+				regulator-name = "vdda_dll_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldoa4: ldo4 {
+				regulator-name = "vda_mcu_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	tps659411: pmic at 4c {
+		compatible = "ti,tps6594-q1";
+		reg = <0x4c>;
+		system-power-controller;
+		interrupt-parent = <&wkup_gpio0>;
+		interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		buck1234-supply = <&vsys_3v3>;
+		buck5-supply = <&vsys_3v3>;
+		ldo1-supply = <&vsys_3v3>;
+		ldo2-supply = <&vsys_3v3>;
+		ldo3-supply = <&vsys_3v3>;
+		ldo4-supply = <&vsys_3v3>;
+
+		regulators {
+			buckb1234: buck1234 {
+				regulator-name = "vdd_core_0v8";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buckb5: buck5 {
+				regulator-name = "vdd_ram_0v85";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob1: ldo1 {
+				regulator-name = "vdd_sd_dv";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob2: ldo2 {
+				regulator-name = "vdd_usb_3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob3: ldo3 {
+				regulator-name = "vdd_io_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldob4: ldo4 {
+				regulator-name = "vda_pll_1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
 };
 
 &mcu_uart0 {
-- 
2.34.1



From n-francis at ti.com  Fri Dec  8 03:49:19 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 8 Dec 2023 17:19:19 +0530
Subject: [PATCH v10 7/7] DONOTMERGE: arm64: defconfig: Enable TPS6594 PMIC for J7 devices
In-Reply-To: <20231208114919.3429562-1-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
Message-ID: <20231208114919.3429562-8-n-francis@ti.com>

J7 (J721E-EVM, J721E-SK, J721S2, AM68-SK, J784S4, AM69-SK) devices use
TPS6594x PMIC (interfaced over I2C) to power the SoC and various other
peripherals on the board [1].

Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
 arch/arm64/configs/defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index be89fa9e6468..a4b84b21b0df 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -729,7 +729,7 @@ CONFIG_MFD_SEC_CORE=y
 CONFIG_MFD_SL28CPLD=y
 CONFIG_RZ_MTU3=y
 CONFIG_MFD_TPS65219=y
-CONFIG_MFD_TPS6594_I2C=m
+CONFIG_MFD_TPS6594_I2C=y
 CONFIG_MFD_TI_AM335X_TSCADC=m
 CONFIG_MFD_ROHM_BD718XX=y
 CONFIG_MFD_WCD934X=m
-- 
2.34.1



From wahrenst at gmx.net  Fri Dec  8 04:08:04 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Fri, 8 Dec 2023 13:08:04 +0100
Subject: [PATCH v3 3/4] staging: vc04_services: Drop vchiq_log_trace() in
 favour of dev_dbg
In-Reply-To: <20231205084157.73819-4-umang.jain@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-4-umang.jain@ideasonboard.com>
Message-ID: <46e42bbf-e99b-4e61-a207-35e150fe4fd2@gmx.net>

Hi Umang,

Am 05.12.23 um 09:41 schrieb Umang Jain:
> Drop vchiq_log_trace() macro which wraps dev_dbg(). Introduce the usage
> of dev_dbg() directly.
>
> Meanwhile at it, drop the usage of __func__ from the logs.
> Dynamic debug supports this via the 'f'  decorator flag.
>
> Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
in general i'm fine with this patch:

Reviewed-by: Stefan Wahren <wahrenst at gmx.net>

but there some improvements, which could be addressed/improved later
> ---
>   .../interface/vchiq_arm/vchiq_arm.c           |  53 ++++-----
>   .../interface/vchiq_arm/vchiq_core.c          | 101 +++++++++---------
>   .../interface/vchiq_arm/vchiq_core.h          |   4 -
>   .../interface/vchiq_arm/vchiq_dev.c           |  15 ++-
>   4 files changed, 78 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> index 56326b59a718..e337b8387647 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -255,8 +255,7 @@ create_pagelist(struct vchiq_instance *instance, char *buf, char __user *ubuf,
>   	pagelist = dma_alloc_coherent(instance->state->dev, pagelist_size, &dma_addr,
>   				      GFP_KERNEL);
>
> -	vchiq_log_trace(instance->state->dev, VCHIQ_ARM,
> -			"%s - %pK", __func__, pagelist);
> +	dev_dbg(instance->state->dev, "arm: %pK\n", pagelist);
>
>   	if (!pagelist)
>   		return NULL;
> @@ -407,8 +406,7 @@ free_pagelist(struct vchiq_instance *instance, struct vchiq_pagelist_info *pagel
>   	struct page **pages = pagelistinfo->pages;
>   	unsigned int num_pages = pagelistinfo->num_pages;
>
> -	vchiq_log_trace(instance->state->dev, VCHIQ_ARM,
> -			"%s - %pK, %d", __func__, pagelistinfo->pagelist, actual);
> +	dev_dbg(instance->state->dev, "arm: %pK, %d\n", pagelistinfo->pagelist, actual);
>
>   	/*
>   	 * NOTE: dma_unmap_sg must be called before the
> @@ -708,8 +706,7 @@ int vchiq_initialise(struct vchiq_instance **instance_out)
>   	ret = 0;
>
>   failed:
> -	vchiq_log_trace(state->dev, VCHIQ_CORE,
> -			"%s(%p): returning %d", __func__, instance, ret);
> +	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, ret);
>
>   	return ret;
>   }
> @@ -742,8 +739,7 @@ int vchiq_shutdown(struct vchiq_instance *instance)
>
>   	mutex_unlock(&state->mutex);
>
> -	vchiq_log_trace(state->dev, VCHIQ_CORE,
> -			"%s(%p): returning %d", __func__, instance, status);
> +	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, status);
>
>   	free_bulk_waiter(instance);
>   	kfree(instance);
> @@ -763,8 +759,8 @@ int vchiq_connect(struct vchiq_instance *instance)
>   	struct vchiq_state *state = instance->state;
>
>   	if (mutex_lock_killable(&state->mutex)) {
> -		vchiq_log_trace(state->dev, VCHIQ_CORE,
> -				"%s: call to mutex_lock failed", __func__);
> +		dev_dbg(state->dev,
> +			"core: call to mutex_lock failed\n");
>   		status = -EAGAIN;
>   		goto failed;
>   	}
> @@ -776,8 +772,7 @@ int vchiq_connect(struct vchiq_instance *instance)
>   	mutex_unlock(&state->mutex);
>
>   failed:
> -	vchiq_log_trace(state->dev, VCHIQ_CORE,
> -			"%s(%p): returning %d", __func__, instance, status);
> +	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, status);
>
>   	return status;
>   }
> @@ -808,8 +803,7 @@ vchiq_add_service(struct vchiq_instance *instance,
>   		status = -EINVAL;
>   	}
>
> -	vchiq_log_trace(state->dev, VCHIQ_CORE,
> -			"%s(%p): returning %d", __func__, instance, status);
> +	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, status);
>
>   	return status;
>   }
> @@ -840,8 +834,7 @@ vchiq_open_service(struct vchiq_instance *instance,
>   	}
>
>   failed:
> -	vchiq_log_trace(state->dev, VCHIQ_CORE,
> -			"%s(%p): returning %d", __func__, instance, status);
> +	dev_dbg(state->dev, "core: (%p): returning %d\n", instance, status);
>
>   	return status;
>   }
> @@ -1010,8 +1003,7 @@ add_completion(struct vchiq_instance *instance, enum vchiq_reason reason,
>   	while ((insert - instance->completion_remove) >= MAX_COMPLETIONS) {
>   		/* Out of space - wait for the client */
>   		DEBUG_TRACE(SERVICE_CALLBACK_LINE);
> -		vchiq_log_trace(instance->state->dev, VCHIQ_CORE,
> -				"%s - completion queue full", __func__);
> +		dev_dbg(instance->state->dev, "core: completion queue full\n");
>   		DEBUG_COUNT(COMPLETION_QUEUE_FULL_COUNT);
>   		if (wait_for_completion_interruptible(&instance->remove_event)) {
>   			vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
> @@ -1099,11 +1091,11 @@ service_callback(struct vchiq_instance *instance, enum vchiq_reason reason,
>   	vchiq_service_get(service);
>   	rcu_read_unlock();
>
> -	vchiq_log_trace(service->state->dev, VCHIQ_ARM,
> -			"%s - service %lx(%d,%p), reason %d, header %lx, instance %lx, bulk_userdata %lx",
> -			__func__, (unsigned long)user_service, service->localport,
> -			user_service->userdata, reason, (unsigned long)header,
> -			(unsigned long)instance, (unsigned long)bulk_userdata);
> +	dev_dbg(service->state->dev,
> +		"arm: service %lx(%d,%p), reason %d, header %lx, instance %lx, bulk_userdata %lx\n",
> +		(unsigned long)user_service, service->localport,
> +		user_service->userdata, reason, (unsigned long)header,
> +		(unsigned long)instance, (unsigned long)bulk_userdata);
>
>   	if (header && user_service->is_vchi) {
>   		spin_lock(&msg_queue_spinlock);
> @@ -1112,8 +1104,7 @@ service_callback(struct vchiq_instance *instance, enum vchiq_reason reason,
>   			spin_unlock(&msg_queue_spinlock);
>   			DEBUG_TRACE(SERVICE_CALLBACK_LINE);
>   			DEBUG_COUNT(MSG_QUEUE_FULL_COUNT);
> -			vchiq_log_trace(service->state->dev, VCHIQ_ARM,
> -					"%s - msg queue full", __func__);
> +			dev_dbg(service->state->dev, "arm: msg queue full\n");
>   			/*
>   			 * If there is no MESSAGE_AVAILABLE in the completion
>   			 * queue, add one
> @@ -1405,8 +1396,8 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
>   	local_uc = ++arm_state->videocore_use_count;
>   	++(*entity_uc);
>
> -	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s %s count %d, state count %d",
> -			__func__, entity, *entity_uc, local_uc);
> +	dev_dbg(state->dev, "suspend: %s count %d, state count %d\n",
> +		entity, *entity_uc, local_uc);
>
>   	write_unlock_bh(&arm_state->susp_res_lock);
>
> @@ -1425,7 +1416,7 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
>   	}
>
>   out:
> -	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s exit %d", __func__, ret);
> +	dev_dbg(state->dev, "suspend: exit %d\n", ret);
In case we want to keep this kind of debug messages, i prefer to have a
common format:

returning %d vs exit %d
>   	return ret;
>   }
>
> @@ -1463,14 +1454,14 @@ vchiq_release_internal(struct vchiq_state *state, struct vchiq_service *service)
>   	--arm_state->videocore_use_count;
>   	--(*entity_uc);
>
> -	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s %s count %d, state count %d",
> -			__func__, entity, *entity_uc, arm_state->videocore_use_count);
> +	dev_dbg(state->dev, "suspend: %s count %d, state count %d\n",
> +		entity, *entity_uc, arm_state->videocore_use_count);
>
>   unlock:
>   	write_unlock_bh(&arm_state->susp_res_lock);
>
>   out:
> -	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s exit %d", __func__, ret);
> +	dev_dbg(state->dev, "suspend: exit %d\n", ret);
ditto
>   	return ret;
>   }
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> index 2fd793954001..d197e4504bd4 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> @@ -459,9 +459,9 @@ make_service_callback(struct vchiq_service *service, enum vchiq_reason reason,
>   {
>   	int status;
>
> -	vchiq_log_trace(service->state->dev, VCHIQ_CORE, "%d: callback:%d (%s, %pK, %pK)",
> -			service->state->id, service->localport, reason_names[reason],
> -			header, bulk_userdata);
> +	dev_dbg(service->state->dev, "core: %d: callback:%d (%s, %pK, %pK)\n",
> +		service->state->id, service->localport, reason_names[reason],
> +		header, bulk_userdata);
>   	status = service->base.callback(service->instance, reason, header, service->handle,
>   					bulk_userdata);
>   	if (status && (status != -EAGAIN)) {
> @@ -763,8 +763,8 @@ process_free_data_message(struct vchiq_state *state, u32 *service_found,
>   			 * it has dropped below its quota
>   			 */
>   			complete(&quota->quota_event);
> -			vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: pfq:%d %x@%pK - slot_use->%d",
> -					state->id, port, header->size, header, count - 1);
> +			dev_dbg(state->dev, "core: %d: pfq:%d %x@%pK - slot_use->%d\n",
> +				state->id, port, header->size, header, count - 1);
>   		} else {
>   			dev_err(state->dev,
>   				"core: service %d slot_use_count=%d (header %pK, msgid %x, header->msgid %x, header->size %x)\n",
> @@ -809,9 +809,9 @@ process_free_queue(struct vchiq_state *state, u32 *service_found,
>   		 */
>   		rmb();
>
> -		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: pfq %d=%pK %x %x",
> -				state->id, slot_index, data, local->slot_queue_recycle,
> -				slot_queue_available);
> +		dev_dbg(state->dev, "core: %d: pfq %d=%pK %x %x\n",
> +			state->id, slot_index, data, local->slot_queue_recycle,
> +			slot_queue_available);
>
>   		/* Initialise the bitmask for services which have used this slot */
>   		memset(service_found, 0, length);
> @@ -980,10 +980,10 @@ queue_message(struct vchiq_state *state, struct vchiq_service *service,
>   		       ((tx_end_index != quota->previous_tx_index) &&
>   			(quota->slot_use_count == quota->slot_quota))) {
>   			spin_unlock(&quota_spinlock);
> -			vchiq_log_trace(state->dev, VCHIQ_CORE,
> -					"%d: qm:%d %s,%zx - quota stall (msg %d, slot %d)",
> -					state->id, service->localport, msg_type_str(type), size,
> -					quota->message_use_count, quota->slot_use_count);
> +			dev_dbg(state->dev,
> +				"core: %d: qm:%d %s,%zx - quota stall (msg %d, slot %d)\n",
> +				state->id, service->localport, msg_type_str(type), size,
> +				quota->message_use_count, quota->slot_use_count);
>   			VCHIQ_SERVICE_STATS_INC(service, quota_stalls);
>   			mutex_unlock(&state->slot_mutex);
>   			if (wait_for_completion_interruptible(&quota->quota_event))
> @@ -1073,10 +1073,9 @@ queue_message(struct vchiq_state *state, struct vchiq_service *service,
>   		spin_unlock(&quota_spinlock);
>
>   		if (slot_use_count)
> -			vchiq_log_trace(state->dev, VCHIQ_CORE,
> -					"%d: qm:%d %s,%zx - slot_use->%d (hdr %p)", state->id,
> -					service->localport, msg_type_str(VCHIQ_MSG_TYPE(msgid)),
> -					size, slot_use_count, header);
> +			dev_dbg(state->dev, "core: %d: qm:%d %s,%zx - slot_use->%d (hdr %p)\n",
> +				state->id, service->localport, msg_type_str(VCHIQ_MSG_TYPE(msgid)),
> +				size, slot_use_count, header);
>
>   		VCHIQ_SERVICE_STATS_INC(service, ctrl_tx_count);
>   		VCHIQ_SERVICE_STATS_ADD(service, ctrl_tx_bytes, size);
> @@ -1205,11 +1204,11 @@ queue_message_sync(struct vchiq_state *state, struct vchiq_service *service,
>   	svc_fourcc = service ? service->base.fourcc
>   			     : VCHIQ_MAKE_FOURCC('?', '?', '?', '?');
>
> -	vchiq_log_trace(state->dev, VCHIQ_SYNC,
> -			"Sent Sync Msg %s(%u) to %p4cc s:%u d:%d len:%d",
> -			msg_type_str(VCHIQ_MSG_TYPE(msgid)), VCHIQ_MSG_TYPE(msgid),
> -			&svc_fourcc, VCHIQ_MSG_SRCPORT(msgid),
> -			VCHIQ_MSG_DSTPORT(msgid), size);
> +	dev_dbg(state->dev,
> +		"sync: Sent Sync Msg %s(%u) to %p4cc s:%u d:%d len:%d\n",
> +		msg_type_str(VCHIQ_MSG_TYPE(msgid)), VCHIQ_MSG_TYPE(msgid),
> +		&svc_fourcc, VCHIQ_MSG_SRCPORT(msgid),
> +		VCHIQ_MSG_DSTPORT(msgid), size);
>
>   	remote_event_signal(&state->remote->sync_trigger);
>
> @@ -1298,11 +1297,11 @@ notify_bulks(struct vchiq_service *service, struct vchiq_bulk_queue *queue,
>   {
>   	int status = 0;
>
> -	vchiq_log_trace(service->state->dev, VCHIQ_CORE,
> -			"%d: nb:%d %cx - p=%x rn=%x r=%x",
> -			service->state->id, service->localport,
> -			(queue == &service->bulk_tx) ? 't' : 'r',
> -			queue->process, queue->remote_notify, queue->remove);
> +	dev_dbg(service->state->dev,
> +		"core: %d: nb:%d %cx - p=%x rn=%x r=%x\n",
> +		service->state->id, service->localport,
> +		(queue == &service->bulk_tx) ? 't' : 'r',
> +		queue->process, queue->remote_notify, queue->remove);
>
>   	queue->remote_notify = queue->process;
>
> @@ -1425,11 +1424,11 @@ abort_outstanding_bulks(struct vchiq_service *service,
>   {
>   	int is_tx = (queue == &service->bulk_tx);
>
> -	vchiq_log_trace(service->state->dev, VCHIQ_CORE,
> -			"%d: aob:%d %cx - li=%x ri=%x p=%x",
> -			service->state->id, service->localport,
> -			is_tx ? 't' : 'r', queue->local_insert,
> -			queue->remote_insert, queue->process);
> +	dev_dbg(service->state->dev,
> +		"core: %d: aob:%d %cx - li=%x ri=%x p=%x\n",
> +		service->state->id, service->localport,
> +		is_tx ? 't' : 'r', queue->local_insert,
> +		queue->remote_insert, queue->process);
>
>   	WARN_ON((int)(queue->local_insert - queue->process) < 0);
>   	WARN_ON((int)(queue->remote_insert - queue->process) < 0);
> @@ -1764,10 +1763,10 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>   					state->id, msg_type_str(type), header, remoteport,
>   					localport, bulk->actual, &bulk->data);
>
> -			vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs:%d %cx li=%x ri=%x p=%x",
> -					state->id, localport,
> -					(type == VCHIQ_MSG_BULK_RX_DONE) ? 'r' : 't',
> -					queue->local_insert, queue->remote_insert, queue->process);
> +			dev_dbg(state->dev, "core: %d: prs:%d %cx li=%x ri=%x p=%x\n",
> +				state->id, localport,
> +				(type == VCHIQ_MSG_BULK_RX_DONE) ? 'r' : 't',
> +				queue->local_insert, queue->remote_insert, queue->process);
>
>   			DEBUG_TRACE(PARSE_LINE);
>   			WARN_ON(queue->process == queue->local_insert);
> @@ -1780,13 +1779,13 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>   		}
>   		break;
>   	case VCHIQ_MSG_PADDING:
> -		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs PADDING@%pK,%x",
> -				state->id, header, size);
> +		dev_dbg(state->dev, "core: %d: prs PADDING@%pK,%x\n",
> +			state->id, header, size);
>   		break;
>   	case VCHIQ_MSG_PAUSE:
>   		/* If initiated, signal the application thread */
> -		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs PAUSE@%pK,%x",
> -				state->id, header, size);
> +		dev_dbg(state->dev, "core: %d: prs PAUSE@%pK,%x\n",
> +			state->id, header, size);
>   		if (state->conn_state == VCHIQ_CONNSTATE_PAUSED) {
>   			dev_err(state->dev, "core: %d: PAUSE received in state PAUSED\n",
>   				state->id);
> @@ -1802,8 +1801,8 @@ parse_message(struct vchiq_state *state, struct vchiq_header *header)
>   		vchiq_set_conn_state(state, VCHIQ_CONNSTATE_PAUSED);
>   		break;
>   	case VCHIQ_MSG_RESUME:
> -		vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: prs RESUME@%pK,%x",
> -				state->id, header, size);
> +		dev_dbg(state->dev, "core: %d: prs RESUME@%pK,%x\n",
> +			state->id, header, size);
>   		/* Release the slot mutex */
>   		mutex_unlock(&state->slot_mutex);
>   		vchiq_set_conn_state(state, VCHIQ_CONNSTATE_CONNECTED);
> @@ -2040,10 +2039,8 @@ sync_func(void *v)
>
>   		svc_fourcc = service->base.fourcc;
>
> -		vchiq_log_trace(state->dev, VCHIQ_SYNC,
> -				"Rcvd Msg %s from %p4cc s:%d d:%d len:%d",
> -				msg_type_str(type), &svc_fourcc,
> -				remoteport, localport, size);
> +		dev_dbg(state->dev, "sync: Rcvd Msg %s from %p4cc s:%d d:%d len:%d\n",
> +			msg_type_str(type), &svc_fourcc, remoteport, localport, size);
>   		if (size > 0)
>   			vchiq_log_dump_mem(state->dev, "Rcvd", 0, header->data, min(16, size));
>
> @@ -2068,8 +2065,8 @@ sync_func(void *v)
>   			break;
>
>   		case VCHIQ_MSG_DATA:
> -			vchiq_log_trace(state->dev, VCHIQ_SYNC, "%d: sf DATA@%pK,%x (%d->%d)",
> -					state->id, header, size, remoteport, localport);
> +			dev_dbg(state->dev, "sync: %d: sf DATA@%pK,%x (%d->%d)\n",
> +				state->id, header, size, remoteport, localport);
>
>   			if ((service->remoteport == remoteport) &&
>   			    (service->srvstate == VCHIQ_SRVSTATE_OPENSYNC)) {
> @@ -3111,9 +3108,9 @@ int vchiq_bulk_transfer(struct vchiq_instance *instance, unsigned int handle,
>   	mutex_unlock(&state->slot_mutex);
>   	mutex_unlock(&service->bulk_mutex);
>
> -	vchiq_log_trace(state->dev, VCHIQ_CORE, "%d: bt:%d %cx li=%x ri=%x p=%x",
> -			state->id, service->localport, dir_char, queue->local_insert,
> -			queue->remote_insert, queue->process);
> +	dev_dbg(state->dev, "core: %d: bt:%d %cx li=%x ri=%x p=%x\n",
> +		state->id, service->localport, dir_char, queue->local_insert,
> +		queue->remote_insert, queue->process);
>
>   waiting:
>   	vchiq_service_put(service);
> @@ -3579,9 +3576,9 @@ void vchiq_log_dump_mem(struct device *dev, const char *label, u32 addr,
>   		*s++ = '\0';
>
>   		if (label && (*label != '\0'))
> -			vchiq_log_trace(dev, VCHIQ_CORE, "%s: %08x: %s", label, addr, line_buf);
> +			dev_dbg(dev, "core: %s: %08x: %s\n", label, addr, line_buf);
>   		else
> -			vchiq_log_trace(dev, VCHIQ_CORE, "%s: %08x: %s", label, addr, line_buf);
> +			dev_dbg(dev, "core: %s: %08x: %s\n", label, addr, line_buf);
This looks like a open-coded version of a hexdump. AFAIR the kernel
already has such logging functions.

Best regards


From neil.armstrong at linaro.org  Fri Dec  8 04:14:46 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Fri, 8 Dec 2023 13:14:46 +0100
Subject: [PATCH v2 1/2] arm64: dts: amlogic: add some device nodes for S4
In-Reply-To: <20231208-s4-dts-v2-1-5a93fa356c5d@amlogic.com>
References: <20231208-s4-dts-v2-0-5a93fa356c5d@amlogic.com>
 <20231208-s4-dts-v2-1-5a93fa356c5d@amlogic.com>
Message-ID: <5b03c354-2582-46c0-8574-8a5d59cb6cfc@linaro.org>

On 08/12/2023 08:16, Xianwei Zhao via B4 Relay wrote:
> From: Xianwei Zhao <xianwei.zhao at amlogic.com>
> 
> Add some device nodes for SoC S4, including periphs clock controller
> node, PLL clock controller node, I2C nodes, SPICC node, NAND
> controller node, Ethernet MAC and PHY node.
> 
> Signed-off-by: Xianwei Zhao <xianwei.zhao at amlogic.com>
> ---
>   arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 350 +++++++++++++++++++++++++++++-
>   1 file changed, 349 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> index 2344b2d741c3..c6b524e1a1ee 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> @@ -6,6 +6,10 @@
>   #include <dt-bindings/interrupt-controller/irq.h>
>   #include <dt-bindings/interrupt-controller/arm-gic.h>
>   #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/gpio/meson-s4-gpio.h>
> +#include <dt-bindings/clock/amlogic,s4-pll-clkc.h>
> +#include <dt-bindings/clock/amlogic,s4-peripherals-clkc.h>
> +#include <dt-bindings/power/meson-s4-power.h>
>   
>   / {
>   	cpus {
> @@ -92,6 +96,38 @@ apb4: bus at fe000000 {
>   			#size-cells = <2>;
>   			ranges = <0x0 0x0 0x0 0xfe000000 0x0 0x480000>;
>   
> +			clkc_periphs: clock-controller at 0 {
> +				compatible = "amlogic,s4-peripherals-clkc";
> +				reg = <0x0 0x0 0x0 0x49c>;
> +				clocks = <&clkc_pll CLKID_FCLK_DIV2>,
> +					<&clkc_pll CLKID_FCLK_DIV2P5>,
> +					<&clkc_pll CLKID_FCLK_DIV3>,
> +					<&clkc_pll CLKID_FCLK_DIV4>,
> +					<&clkc_pll CLKID_FCLK_DIV5>,
> +					<&clkc_pll CLKID_FCLK_DIV7>,
> +					<&clkc_pll CLKID_HIFI_PLL>,
> +					<&clkc_pll CLKID_GP0_PLL>,
> +					<&clkc_pll CLKID_MPLL0>,
> +					<&clkc_pll CLKID_MPLL1>,
> +					<&clkc_pll CLKID_MPLL2>,
> +					<&clkc_pll CLKID_MPLL3>,
> +					<&clkc_pll CLKID_HDMI_PLL>,
> +					<&xtal>;
> +				clock-names = "fclk_div2", "fclk_div2p5", "fclk_div3",
> +						"fclk_div4", "fclk_div5", "fclk_div7",
> +						"hifi_pll", "gp0_pll", "mpll0", "mpll1",
> +						"mpll2", "mpll3", "hdmi_pll", "xtal";
> +				#clock-cells = <1>;
> +			};
> +
> +			clkc_pll: clock-controller at 8000 {
> +				compatible = "amlogic,s4-pll-clkc";
> +				reg = <0x0 0x8000 0x0 0x1e8>;
> +				clocks = <&xtal>;
> +				clock-names = "xtal";
> +				#clock-cells = <1>;
> +			};
> +
>   			watchdog at 2100 {
>   				compatible = "amlogic,s4-wdt", "amlogic,t7-wdt";
>   				reg = <0x0 0x2100 0x0 0x10>;
> @@ -120,6 +156,187 @@ mux {
>   						bias-disable;
>   					};
>   				};
> +
> +				i2c0_pins1: i2c0-pins1 {
> +					mux {
> +						groups = "i2c0_sda",
> +						       "i2c0_scl";
> +						function = "i2c0";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c1_pins1: i2c1-pins1 {
> +					mux {
> +						groups = "i2c1_sda_c",
> +						       "i2c1_scl_c";
> +						function = "i2c1";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c1_pins2: i2c1-pins2 {
> +					mux {
> +						groups = "i2c1_sda_d",
> +						       "i2c1_scl_d";
> +						function = "i2c1";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c1_pins3: i2c1-pins3 {
> +					mux {
> +						groups = "i2c1_sda_h",
> +						       "i2c1_scl_h";
> +						function = "i2c1";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c1_pins4: i2c1-pins4 {
> +					mux {
> +						groups = "i2c1_sda_x",
> +						       "i2c1_scl_x";
> +						function = "i2c1";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c2_pins1: i2c2-pins1 {
> +					mux {
> +						groups = "i2c2_sda_d",
> +						       "i2c2_scl_d";
> +						function = "i2c2";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c2_pins2: i2c2-pins2 {
> +					mux {
> +						groups = "i2c2_sda_h8",
> +						       "i2c2_scl_h9";
> +						function = "i2c2";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c2_pins3: i2c2-pins3 {
> +					mux {
> +						groups = "i2c2_sda_h0",
> +						       "i2c2_scl_h1";
> +						function = "i2c2";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c3_pins1: i2c3-pins1 {
> +					mux {
> +						groups = "i2c3_sda_x",
> +						       "i2c3_scl_x";
> +						function = "i2c3";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c3_pins2: i2c3-pins2 {
> +					mux {
> +						groups = "i2c3_sda_z",
> +						       "i2c3_scl_z";
> +						function = "i2c3";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c4_pins1: i2c4-pins1 {
> +					mux {
> +						groups = "i2c4_sda_c",
> +						       "i2c4_scl_c";
> +						function = "i2c4";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c4_pins2: i2c4-pins2 {
> +					mux {
> +						groups = "i2c4_sda_d",
> +						       "i2c4_scl_d";
> +						function = "i2c4";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				i2c4_pins3: i2c4-pins3 {
> +					mux {
> +						groups = "i2c4_sda_z",
> +						       "i2c4_scl_z";
> +						function = "i2c4";
> +						drive-strength-microamp = <3000>;
> +						bias-disable;
> +					};
> +				};
> +
> +				nand_pins: nand-pins {
> +					mux {
> +						groups = "emmc_nand_d0",
> +						       "emmc_nand_d1",
> +						       "emmc_nand_d2",
> +						       "emmc_nand_d3",
> +						       "emmc_nand_d4",
> +						       "emmc_nand_d5",
> +						       "emmc_nand_d6",
> +						       "emmc_nand_d7",
> +						       "nand_ce0",
> +						       "nand_ale",
> +						       "nand_cle",
> +						       "nand_wen_clk",
> +						       "nand_ren_wr";
> +						function = "nand";
> +						input-enable;
> +					};
> +				};
> +
> +				spicc0_pins_x: spicc0-pins_x {
> +					mux {
> +						groups = "spi_a_mosi_x",
> +						       "spi_a_miso_x",
> +						       "spi_a_clk_x";
> +						function = "spi_a";
> +						drive-strength-microamp = <3000>;
> +					};
> +				};
> +
> +				spicc0_pins_h: spicc0-pins-h {
> +					mux {
> +						groups = "spi_a_mosi_h",
> +						       "spi_a_miso_h",
> +						       "spi_a_clk_h";
> +						function = "spi_a";
> +						drive-strength-microamp = <3000>;
> +					};
> +				};
> +
> +				spicc0_pins_z: spicc0-pins-z {
> +					mux {
> +						groups = "spi_a_mosi_z",
> +						       "spi_a_miso_z",
> +						       "spi_a_clk_z";
> +						function = "spi_a";
> +						drive-strength-microamp = <3000>;
> +					};
> +				};
> +
>   			};
>   
>   			gpio_intc: interrupt-controller at 4080 {
> @@ -132,13 +349,119 @@ gpio_intc: interrupt-controller at 4080 {
>   					<10 11 12 13 14 15 16 17 18 19 20 21>;
>   			};
>   
> +			eth_phy: mdio-multiplexer at 28000 {
> +				compatible = "amlogic,g12a-mdio-mux";
> +				reg = <0x0 0x28000 0x0 0xa4>;
> +
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				clocks = <&clkc_periphs CLKID_ETHPHY>,
> +					 <&xtal>,
> +					 <&clkc_pll CLKID_MPLL_50M>;
> +				clock-names = "pclk", "clkin0", "clkin1";
> +				mdio-parent-bus = <&mdio0>;
> +
> +				ext_mdio: mdio at 0 {
> +					reg = <0>;
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +				};
> +
> +				int_mdio: mdio at 1 {
> +					reg = <1>;
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +
> +					internal_ephy: ethernet-phy at 8 {
> +						compatible = "ethernet-phy-id0180.3301",
> +							     "ethernet-phy-ieee802.3-c22";
> +						interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> +						reg = <8>;
> +						max-speed = <100>;
> +					};
> +				};
> +			};
> +
> +			spicc0: spi at 50000 {
> +				compatible = "amlogic,meson-g12a-spicc";
> +				reg = <0x0 0x50000 0x0 0x44>;
> +				interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
> +				clocks = <&clkc_periphs CLKID_SPICC0>,
> +					 <&clkc_periphs CLKID_SPICC0_EN>;
> +				clock-names = "core", "pclk";
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				status = "disabled";
> +			};
> +
> +			i2c0: i2c at 66000 {
> +				compatible = "amlogic,meson-axg-i2c";
> +				reg = <0x0 0x66000 0x0 0x20>;
> +				interrupts = <GIC_SPI 160 IRQ_TYPE_EDGE_RISING>;
> +				clocks = <&clkc_periphs CLKID_I2C_M_A>;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				status = "disabled";
> +			};
> +
> +			i2c1: i2c at 68000 {
> +				compatible = "amlogic,meson-axg-i2c";
> +				reg = <0x0 0x68000 0x0 0x20>;
> +				interrupts = <GIC_SPI 161 IRQ_TYPE_EDGE_RISING>;
> +				clocks = <&clkc_periphs CLKID_I2C_M_B>;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				status = "disabled";
> +			};
> +
> +			i2c2: i2c at 6a000 {
> +				compatible = "amlogic,meson-axg-i2c";
> +				reg = <0x0 0x6a000 0x0 0x20>;
> +				interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
> +				clocks = <&clkc_periphs CLKID_I2C_M_C>;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				status = "disabled";
> +			};
> +
> +			i2c3: i2c at 6c000 {
> +				compatible = "amlogic,meson-axg-i2c";
> +				reg = <0x0 0x6c000 0x0 0x20>;
> +				interrupts = <GIC_SPI 163 IRQ_TYPE_EDGE_RISING>;
> +				clocks = <&clkc_periphs CLKID_I2C_M_D>;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				status = "disabled";
> +			};
> +
> +			i2c4: i2c at 6e000 {
> +				compatible = "amlogic,meson-axg-i2c";
> +				reg = <0x0 0x6e000 0x0 0x20>;
> +				interrupts = <GIC_SPI 164 IRQ_TYPE_EDGE_RISING>;
> +				clocks = <&clkc_periphs CLKID_I2C_M_E>;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				status = "disabled";
> +			};
> +
> +			nand: nand-controller at 8c800 {
> +				compatible = "amlogic,meson-axg-nfc";
> +				reg = <0x0 0x8c800 0x0 0x100>, <0x0 0x8c000 0x0 0x4>;
> +				reg-names = "nfc", "emmc";
> +				interrupts = <GIC_SPI 175 IRQ_TYPE_EDGE_RISING>;
> +				clocks = <&clkc_periphs CLKID_SD_EMMC_C>,
> +					<&clkc_pll CLKID_FCLK_DIV2>;
> +				clock-names = "core", "device";
> +				status = "disabled";
> +			};
> +
>   			uart_B: serial at 7a000 {
>   				compatible = "amlogic,meson-s4-uart",
>   					     "amlogic,meson-ao-uart";
>   				reg = <0x0 0x7a000 0x0 0x18>;
>   				interrupts = <GIC_SPI 169 IRQ_TYPE_EDGE_RISING>;
>   				status = "disabled";
> -				clocks = <&xtal>, <&xtal>, <&xtal>;
> +				clocks = <&xtal>, <&clkc_periphs CLKID_UART_B>, <&xtal>;
>   				clock-names = "xtal", "pclk", "baud";
>   			};
>   
> @@ -160,5 +483,30 @@ hwrng: rng at 440788 {
>   				reg = <0x0 0x440788 0x0 0x0c>;
>   			};
>   		};
> +
> +		ethmac: ethernet at fdc00000 {
> +			compatible = "amlogic,meson-axg-dwmac",
> +				     "snps,dwmac-3.70a",
> +				     "snps,dwmac";
> +			reg = <0x0 0xfdc00000 0x0 0x10000>,
> +			      <0x0 0xfe024000 0x0 0x8>;
> +
> +			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "macirq";
> +			power-domains = <&pwrc PWRC_S4_ETH_ID>;
> +			clocks = <&clkc_periphs CLKID_ETH>,
> +				 <&clkc_pll CLKID_FCLK_DIV2>,
> +				 <&clkc_pll CLKID_MPLL2>;
> +			clock-names = "stmmaceth", "clkin0", "clkin1";
> +			rx-fifo-depth = <4096>;
> +			tx-fifo-depth = <2048>;
> +			status = "disabled";
> +
> +			mdio0: mdio {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				compatible = "snps,dwmac-mdio";
> +			};
> +		};
>   	};
>   };
> 

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>


From neil.armstrong at linaro.org  Fri Dec  8 04:14:59 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Fri, 8 Dec 2023 13:14:59 +0100
Subject: [PATCH v2 2/2] arm64: dts: amlogic: enable some nodes for board
 AQ222
In-Reply-To: <20231208-s4-dts-v2-2-5a93fa356c5d@amlogic.com>
References: <20231208-s4-dts-v2-0-5a93fa356c5d@amlogic.com>
 <20231208-s4-dts-v2-2-5a93fa356c5d@amlogic.com>
Message-ID: <ee82eefc-d979-4183-b679-cb4f79b559fa@linaro.org>

On 08/12/2023 08:16, Xianwei Zhao via B4 Relay wrote:
> From: Xianwei Zhao <xianwei.zhao at amlogic.com>
> 
> Add reserved memory for board AQ222 which is used by ATF.
> Enable NAND, SPICC nodes for board AQ222.
> 
> Signed-off-by: Xianwei Zhao <xianwei.zhao at amlogic.com>
> ---
>   .../boot/dts/amlogic/meson-s4-s805x2-aq222.dts     | 56 ++++++++++++++++++++++
>   1 file changed, 56 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
> index c1f322c73982..18789242f05f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
> @@ -23,6 +23,17 @@ memory at 0 {
>   		reg = <0x0 0x0 0x0 0x40000000>;
>   	};
>   
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		/* 52 MiB reserved for ARM Trusted Firmware */
> +		secmon_reserved: secmon at 5000000 {
> +			reg = <0x0 0x05000000 0x0 0x3400000>;
> +			no-map;
> +		};
> +	};
>   };
>   
>   &uart_B {
> @@ -34,3 +45,48 @@ &ir {
>   	pinctrl-0 = <&remote_pins>;
>   	pinctrl-names = "default";
>   };
> +
> +&nand {
> +	status = "okay";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	pinctrl-0 = <&nand_pins>;
> +	pinctrl-names = "default";
> +
> +	nand at 0 {
> +		reg = <0>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +
> +		nand-on-flash-bbt;
> +
> +		partition at 0 {
> +			label = "boot";
> +			reg = <0x0 0x00200000>;
> +		};
> +		partition at 200000 {
> +			label = "env";
> +			reg = <0x00200000 0x00400000>;
> +		};
> +		partition at 600000 {
> +			label = "system";
> +			reg = <0x00600000 0x00a00000>;
> +		};
> +		partition at 1000000 {
> +			label = "rootfs";
> +			reg = <0x01000000 0x03000000>;
> +		};
> +		partition at 4000000 {
> +			label = "media";
> +			reg = <0x04000000 0x8000000>;
> +		};
> +	};
> +};
> +
> +&spicc0 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spicc0_pins_x>;
> +	cs-gpios = <&gpio GPIOX_10 GPIO_ACTIVE_LOW>;
> +};
> 

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>


From dmitry.osipenko at collabora.com  Fri Dec  8 04:17:25 2023
From: dmitry.osipenko at collabora.com (Dmitry Osipenko)
Date: Fri, 8 Dec 2023 15:17:25 +0300
Subject: [PATCH v2] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <CAMpZ1qENxWsDnvke4jMvK9tYpta3dThHUHxjDWO-u2JV+8dZdQ@mail.gmail.com>
References: <20231207082200.16388-1-jensenhuang@friendlyarm.com>
 <ebf6cf8ec3b5befd673d295061fa2738@manjaro.org>
 <CAMpZ1qHUnTDQ78gdrQF9Sx_-XfLM-B+H-0bL1-+twKsno+JOvg@mail.gmail.com>
 <5e11553952c02ad20591992be4284bbd@manjaro.org>
 <95cc7716-ba01-e239-e7c0-eba0b7da7955@collabora.com>
 <CAMpZ1qENxWsDnvke4jMvK9tYpta3dThHUHxjDWO-u2JV+8dZdQ@mail.gmail.com>
Message-ID: <94bf6180-8abf-777d-2dce-498efafb57c1@collabora.com>

On 12/8/23 11:53, Jensen Huang wrote:
> On Fri, Dec 8, 2023 at 12:00?AM Dmitry Osipenko
> <dmitry.osipenko at collabora.com> wrote:
>>
>> On 12/7/23 17:10, Dragan Simic wrote:
>>> On 2023-12-07 10:25, Jensen Huang wrote:
>>>> On Thu, Dec 7, 2023 at 4:37?PM Dragan Simic <dsimic at manjaro.org> wrote:
>>>>>
>>>>> On 2023-12-07 09:21, Jensen Huang wrote:
>>>>>> Possible deadlock scenario (on reboot):
>>>>>> rk3x_i2c_xfer_common(polling)
>>>>>>     -> rk3x_i2c_wait_xfer_poll()
>>>>>>         -> rk3x_i2c_irq(0, i2c);
>>>>>>             --> spin_lock(&i2c->lock);
>>>>>>             ...
>>>>>>         <rk3x i2c interrupt>
>>>>>>         -> rk3x_i2c_irq(0, i2c);
>>>>>>             --> spin_lock(&i2c->lock); (deadlock here)
>>>>>>
>>>>>> Store the IRQ number and disable/enable it around the polling
>>>>> transfer.
>>>>>> This patch has been tested on NanoPC-T4.
>>>>>
>>>>> In case you haven't already seen the related discussion linked below,
>>>>> please have a look.  I also added more people to the list of recipients,
>>>>> in an attempt to make everyone aware of the different approaches to
>>>>> solving this issue.
>>>>>
>>>>> https://lore.kernel.org/all/655177f4.050a0220.d85c9.3ba0 at mx.google.com/T/#m6fc9c214452fec6681843e7f455978c35c6f6c8b
>>>>
>>>> Thank you for providing the information. I hadn't seen this link before.
>>>> After carefully looking into the related discussion, it appears that
>>>> Dmitry Osipenko is already working on a suitable patch. To avoid
>>>> duplication
>>>> or conflicts, my patch can be discarded.
>>>
>>> Thank you for responding so quickly.  Perhaps it would be best to hear
>>> from Dmitry as well, before discarding anything.  It's been a while
>>> since Dmitry wrote about working on the patch, so he might have
>>> abandoned it.
>>
>> This patch is okay. In general, will be better to have IRQ disabled by
>> default like I did in my variant, it should allow to remove the spinlock
>> entirely. Of course this also can be done later on in a follow up
>> patches. Jensen, feel free to use my variant of the patch, add my
>> s-o-b+co-developed tags to the commit msg if you'll do. Otherwise I'll
>> be able to send my patch next week.
> 
> Thank you for the suggestion. I've updated the patch to your variant, and
> as confirmed by others, reboots are functioning correctly. I measured the
> overhead of enable_irq/disable_irq() by calculating ktime in the
> updated version,
> and on rk3399, the minimum delta I observed was 291/875 ns. This extra
> cost may impact most interrupt-based transfers. Therefore, I personally lean
> towards the current v2 patch and handle the spinlock and irqsave/restore in
> a follow up patch. I'd like to hear everyone's thoughts on this.

Please don't use ktime for perf measurements, ktime itself is a slow API
and it should be 200us that ktime takes itself. Also, the 0.2us is
practically nothing, especially compared to I2C transfers measured in ms.

I'm fine with keeping your v2 variant for the bug fix if you prefer
that. Thanks for addressing the issue :)

-- 
Best regards,
Dmitry



From tony at atomide.com  Fri Dec  8 04:17:15 2023
From: tony at atomide.com (Tony Lindgren)
Date: Fri,  8 Dec 2023 14:17:15 +0200
Subject: [GIT PULL] Fixes for omaps
Message-ID: <pull-1702037799-781982@atomide.com>

From: "Tony Lindgren" <tony at atomide.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v6.7/fixes-signed

for you to fetch changes up to c72b9c33ef9695ad7ce7a6eb39a9df8a01b70796:

  ARM: OMAP2+: Fix null pointer dereference and memory leak in omap_soc_device_init (2023-11-30 13:57:00 +0200)

----------------------------------------------------------------
Fixes for omaps

A few fixes for omaps:

- A regression fix for ti-sysc interconnect target module driver to not access
  registers after reset if srst_udelay quirk is needed

- DRA7 L3 NoC node register size fix

----------------------------------------------------------------
Andrew Davis (1):
      ARM: dts: dra7: Fix DRA7 L3 NoC node register size

Kunwu Chan (1):
      ARM: OMAP2+: Fix null pointer dereference and memory leak in omap_soc_device_init

Tony Lindgren (1):
      bus: ti-sysc: Flush posted write only after srst_udelay

 arch/arm/boot/dts/ti/omap/dra7.dtsi |  2 +-
 arch/arm/mach-omap2/id.c            |  5 +++++
 drivers/bus/ti-sysc.c               | 18 ++++++++++++++----
 3 files changed, 20 insertions(+), 5 deletions(-)


From tony at atomide.com  Fri Dec  8 04:18:17 2023
From: tony at atomide.com (Tony Lindgren)
Date: Fri,  8 Dec 2023 14:18:17 +0200
Subject: [GIT PULL 1/3] Devicetree changes for omaps for v6.8
Message-ID: <pull-1702037869-295608@atomide.com>

From: "Tony Lindgren" <tony at atomide.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v6.8/dt-signed

for you to fetch changes up to 10dfde4bec529aa1d78e4b3acce7882a312880b7:

  ARM: dts: omap4-embt2ws: Add Bluetooth (2023-12-01 08:24:55 +0200)

----------------------------------------------------------------
Devicetree changes for omaps

- A series of patches to reorganize Motorola Mapphone related files to add
  support for tablets as the peripherals are different compared to the
  phones

- Apply am57xx-idk overlays to base dtbs

- Extcon update to use id-gpios and vbus-gpios

- Update omap4-epson-embt2ws to enable wlan clock and bluetooth-gnss

- Update for logicpd-torpedo to use bluetooth-gnss node name

----------------------------------------------------------------
Alexander Stein (1):
      ARM: dts: ti/omap: Replace deprecated extcon-usb-gpio id-gpio/vbus-gpio properties

Andreas Kemnade (3):
      ARM: dts: omap4-embt2ws: enable 32K clock on WLAN
      ARM: dts: omap: logicpd-torpedo: do not disguise GNSS device
      ARM: dts: omap4-embt2ws: Add Bluetooth

Rob Herring (1):
      arm: dts: omap: Apply am57xx-idk overlays to base dtbs

Tony Lindgren (4):
      dt-bindings: omap: Add Motorola mapphone mz609 and mz617 tablets
      ARM: dts: motorola-mapphone: Move LCD to common file for xt875 and xt894
      ARM: dts: motorola-mapphone: Move handset devices to a common file
      ARM: dts: motorola-mapphone: Add basic support for mz609 and mz617

 Documentation/devicetree/bindings/arm/ti/omap.yaml |   2 +
 arch/arm/boot/dts/ti/omap/Makefile                 |  14 +-
 arch/arm/boot/dts/ti/omap/am571x-idk.dts           |   4 +-
 arch/arm/boot/dts/ti/omap/am5729-beagleboneai.dts  |   2 +-
 arch/arm/boot/dts/ti/omap/am572x-idk-common.dtsi   |   4 +-
 arch/arm/boot/dts/ti/omap/dra7-evm-common.dtsi     |   4 +-
 arch/arm/boot/dts/ti/omap/dra71-evm.dts            |   4 +-
 arch/arm/boot/dts/ti/omap/dra72-evm-common.dtsi    |   4 +-
 arch/arm/boot/dts/ti/omap/dra76-evm.dts            |   4 +-
 .../dts/ti/omap/logicpd-torpedo-37xx-devkit.dts    |   2 +-
 .../boot/dts/ti/omap/motorola-mapphone-common.dtsi | 298 ---------------------
 .../dts/ti/omap/motorola-mapphone-handset.dtsi     | 234 ++++++++++++++++
 .../dts/ti/omap/motorola-mapphone-mz607-mz617.dtsi |  21 ++
 .../boot/dts/ti/omap/motorola-mapphone-xt8xx.dtsi  |  75 ++++++
 .../boot/dts/ti/omap/omap4-droid-bionic-xt875.dts  |  11 +-
 arch/arm/boot/dts/ti/omap/omap4-droid4-xt894.dts   |  19 +-
 arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts  |  18 +-
 arch/arm/boot/dts/ti/omap/omap4-xyboard-mz609.dts  |  46 ++++
 arch/arm/boot/dts/ti/omap/omap4-xyboard-mz617.dts  |  17 ++
 19 files changed, 459 insertions(+), 324 deletions(-)
 create mode 100644 arch/arm/boot/dts/ti/omap/motorola-mapphone-handset.dtsi
 create mode 100644 arch/arm/boot/dts/ti/omap/motorola-mapphone-mz607-mz617.dtsi
 create mode 100644 arch/arm/boot/dts/ti/omap/motorola-mapphone-xt8xx.dtsi
 create mode 100644 arch/arm/boot/dts/ti/omap/omap4-xyboard-mz609.dts
 create mode 100644 arch/arm/boot/dts/ti/omap/omap4-xyboard-mz617.dts


From tony at atomide.com  Fri Dec  8 04:18:18 2023
From: tony at atomide.com (Tony Lindgren)
Date: Fri,  8 Dec 2023 14:18:18 +0200
Subject: [GIT PULL 2/3] Defconfig changes for omaps for v6.8
In-Reply-To: <pull-1702037869-295608@atomide.com>
References: <pull-1702037869-295608@atomide.com>
Message-ID: <pull-1702037869-295608@atomide.com-2>

From: "Tony Lindgren" <tony at atomide.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v6.8/defconfig-signed

for you to fetch changes up to ac10d6c3c5f9b85e780ec5cfaf0608ae048c5205:

  ARM: omap2plus_defconfig: enable I2C devcies of bt200 (2023-12-01 08:48:15 +0200)

----------------------------------------------------------------
Defconfig changes for omaps

Defconfig changes to enable I2C devices for bt200 as loadable modules
for the PMIC, sensors and LEDs.

----------------------------------------------------------------
Andreas Kemnade (1):
      ARM: omap2plus_defconfig: enable I2C devcies of bt200

 arch/arm/configs/omap2plus_defconfig | 5 +++++
 1 file changed, 5 insertions(+)


From tony at atomide.com  Fri Dec  8 04:18:19 2023
From: tony at atomide.com (Tony Lindgren)
Date: Fri,  8 Dec 2023 14:18:19 +0200
Subject: [GIT PULL 3/3] Maintainer changes for v6.8
In-Reply-To: <pull-1702037869-295608@atomide.com>
References: <pull-1702037869-295608@atomide.com>
Message-ID: <pull-1702037869-295608@atomide.com-3>

From: "Tony Lindgren" <tony at atomide.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v6.8/maintainers-signed

for you to fetch changes up to 6353ed6f311b9daab93df4d968d72ddf2070fe7f:

  MAINTAINERS: add omap bus drivers to OMAP2+ SUPPORT (2023-12-01 08:49:45 +0200)

----------------------------------------------------------------
Maintainer update for drivers/bus/omap* files

Add for drivers/bus/omap* files to the omap section in the
MAINTAINERS file.

----------------------------------------------------------------
Lukas Bulwahn (1):
      MAINTAINERS: add omap bus drivers to OMAP2+ SUPPORT

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)


From ckeepax at opensource.cirrus.com  Fri Dec  8 04:30:35 2023
From: ckeepax at opensource.cirrus.com (Charles Keepax)
Date: Fri, 8 Dec 2023 12:30:35 +0000
Subject: [PATCH 1/5] ASoC: wm0010: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-1-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-1-c4dab6f521ec@linaro.org>
Message-ID: <20231208123035.GP14858@ediswmail.ad.cirrus.com>

On Fri, Dec 08, 2023 at 11:09:25AM +0100, Linus Walleij wrote:
> This converts the WM0010 codec to use GPIO descriptors.
> It's a pretty straight-forward conversion also switching over
> the single in-tree user in the S3C Cragganmore module
> for S3C 6410.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---

Reviewed-by: Charles Keepax <ckeepax at opensource.cirrus.com>

Thanks,
Charles


From eichest at gmail.com  Fri Dec  8 04:37:08 2023
From: eichest at gmail.com (Stefan Eichenberger)
Date: Fri, 8 Dec 2023 13:37:08 +0100
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-in-suspend property
In-Reply-To: <b9868bd4-6f14-4628-88ea-56d06027739e@linaro.org>
References: <20231207111300.80581-1-eichest@gmail.com>
 <20231207111300.80581-2-eichest@gmail.com>
 <b9868bd4-6f14-4628-88ea-56d06027739e@linaro.org>
Message-ID: <ZXMN9EgWRjtJyybr@eichest-laptop>

Hi Krzysztof,

On Thu, Dec 07, 2023 at 05:59:08PM +0100, Krzysztof Kozlowski wrote:
> On 07/12/2023 12:12, Stefan Eichenberger wrote:
> > diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> > index c40799355ed7..047a5101341c 100644
> > --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> > +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> > @@ -87,6 +87,12 @@ properties:
> >        - 2 # ATMEL_MXT_WAKEUP_GPIO
> >      default: 0
> >  
> > +  atmel,poweroff-in-suspend:
> > +    description: |
> > +      When this property is set, all supplies are turned off when the system is
> > +      going to suspend.
> 
> You described the desired Linux feature or behavior, not the actual
> hardware. The bindings are about the latter, so instead you need to
> rephrase the property and its description to match actual hardware
> capabilities/features/configuration etc.

Thanks a lot for the feedback. Would the following be okay as a
description?

vdda and vdd are switched off in suspend mode.

Best regards,
Stefan


From srinivas.kandagatla at linaro.org  Fri Dec  8 04:42:39 2023
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri, 08 Dec 2023 12:42:39 +0000
Subject: [PATCH V3] nvmem: brcm_nvram: store a copy of NVRAM content
In-Reply-To: <20231102062848.23965-1-zajec5@gmail.com>
References: <20231102062848.23965-1-zajec5@gmail.com>
Message-ID: <170203935960.22033.10753187984539476656.b4-ty@linaro.org>


On Thu, 02 Nov 2023 07:28:48 +0100, Rafa? Mi?ecki wrote:
> This driver uses MMIO access for reading NVRAM from a flash device.
> Underneath there is a flash controller that reads data and provides
> mapping window.
> 
> Using MMIO interface affects controller configuration and may break real
> controller driver. It was reported by multiple users of devices with
> NVRAM stored on NAND.
> 
> [...]

Applied, thanks!

[1/1] nvmem: brcm_nvram: store a copy of NVRAM content
      commit: f019a0e9c19aaa532cb46142e1f333c9daff92ff

Best regards,
-- 
Srinivas Kandagatla <srinivas.kandagatla at linaro.org>



From ckeepax at opensource.cirrus.com  Fri Dec  8 04:42:57 2023
From: ckeepax at opensource.cirrus.com (Charles Keepax)
Date: Fri, 8 Dec 2023 12:42:57 +0000
Subject: [PATCH 2/5] ASoC: wm1250-ev1: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-2-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-2-c4dab6f521ec@linaro.org>
Message-ID: <20231208124257.GQ14858@ediswmail.ad.cirrus.com>

On Fri, Dec 08, 2023 at 11:09:26AM +0100, Linus Walleij wrote:
> This converts the WM1250-EV1 codec to use GPIO descriptors.
> It turns out that the platform data was only used to pass some
> global GPIO numbers from a board file, so we get rid of this
> and also switch over the single in-tree user in the S3C
> Cragganmore module for S3C 6410.
> 
> The driver obtains two GPIO lines named OSR and master and just
> pull them low, we leave this behaviour as it was.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> +	.table = {
> +		GPIO_LOOKUP("GPION", 12, "clk-ena", GPIO_ACTIVE_HIGH),
> +		GPIO_LOOKUP("GPIOL", 12, "clk-sel0", GPIO_ACTIVE_HIGH),
> +		GPIO_LOOKUP("GPIOL", 13, "clk-sel1", GPIO_ACTIVE_HIGH),
> +		GPIO_LOOKUP("GPIOL", 14, "osr", GPIO_ACTIVE_HIGH),
> +		GPIO_LOOKUP("GPIOL", 8, "master", GPIO_ACTIVE_HIGH),
> +		{ },

For my curiousity, what is the significance of GPION vs GPIOL here?

But looks fine to me:

Reviewed-by: Charles Keepax <ckeepax at opensource.cirrus.com>

Thanks,
Charles


From ckeepax at opensource.cirrus.com  Fri Dec  8 04:45:42 2023
From: ckeepax at opensource.cirrus.com (Charles Keepax)
Date: Fri, 8 Dec 2023 12:45:42 +0000
Subject: [PATCH 3/5] ASoC: wm2200: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-3-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-3-c4dab6f521ec@linaro.org>
Message-ID: <20231208124542.GR14858@ediswmail.ad.cirrus.com>

On Fri, Dec 08, 2023 at 11:09:27AM +0100, Linus Walleij wrote:
> This converts the WM2200 codec to use GPIO descriptors.
> This is a pretty straight-forward conversion, and it also
> switches over the single in-tree user in the S3C
> Cragganmore module for S3C 6410.
> 
> This coded does not seem to get selected or be selectable
> through Kconfig, I had to hack another soundcard Kconfig
> entry to select it for compile tests.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---

Reviewed-by: Charles Keepax <ckeepax at opensource.cirrus.com>

Thanks,
Charles


From krzysztof.kozlowski at linaro.org  Fri Dec  8 04:47:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 8 Dec 2023 13:47:32 +0100
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-in-suspend property
In-Reply-To: <ZXMN9EgWRjtJyybr@eichest-laptop>
References: <20231207111300.80581-1-eichest@gmail.com>
 <20231207111300.80581-2-eichest@gmail.com>
 <b9868bd4-6f14-4628-88ea-56d06027739e@linaro.org>
 <ZXMN9EgWRjtJyybr@eichest-laptop>
Message-ID: <7f5fd234-f608-477a-9032-9008e5d88c05@linaro.org>

On 08/12/2023 13:37, Stefan Eichenberger wrote:
> Hi Krzysztof,
> 
> On Thu, Dec 07, 2023 at 05:59:08PM +0100, Krzysztof Kozlowski wrote:
>> On 07/12/2023 12:12, Stefan Eichenberger wrote:
>>> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
>>> index c40799355ed7..047a5101341c 100644
>>> --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
>>> +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
>>> @@ -87,6 +87,12 @@ properties:
>>>        - 2 # ATMEL_MXT_WAKEUP_GPIO
>>>      default: 0
>>>  
>>> +  atmel,poweroff-in-suspend:
>>> +    description: |
>>> +      When this property is set, all supplies are turned off when the system is
>>> +      going to suspend.
>>
>> You described the desired Linux feature or behavior, not the actual
>> hardware. The bindings are about the latter, so instead you need to
>> rephrase the property and its description to match actual hardware
>> capabilities/features/configuration etc.
> 
> Thanks a lot for the feedback. Would the following be okay as a
> description?
> 
> vdda and vdd are switched off in suspend mode.

Are switched by who? Linux driver? Then nothing changed...

Best regards,
Krzysztof



From ckeepax at opensource.cirrus.com  Fri Dec  8 04:47:34 2023
From: ckeepax at opensource.cirrus.com (Charles Keepax)
Date: Fri, 8 Dec 2023 12:47:34 +0000
Subject: [PATCH 4/5] ASoC: wm5100: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-4-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-4-c4dab6f521ec@linaro.org>
Message-ID: <20231208124734.GS14858@ediswmail.ad.cirrus.com>

On Fri, Dec 08, 2023 at 11:09:28AM +0100, Linus Walleij wrote:
> This converts the WM5100 codec to use GPIO descriptors, a pretty
> straight-forward conversion with the following peculiarities:
> 
> - The driver is instantiating a GPIO chip named wm5100, and the
>   headphone polarity detection GPIO is lifted from there. We add
>   this to the GPIO descriptor table as well, and we can then get
>   rid of also the base address for the GPIO chip from the
>   platform data and just use dynamic numbering.
> 
> - Fix up the only in-tree user which is the Cragganmore 6410
>   module.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---

Reviewed-by: Charles Keepax <ckeepax at opensource.cirrus.com>

Thanks,
Charles


From ckeepax at opensource.cirrus.com  Fri Dec  8 04:48:47 2023
From: ckeepax at opensource.cirrus.com (Charles Keepax)
Date: Fri, 8 Dec 2023 12:48:47 +0000
Subject: [PATCH 2/5] ASoC: wm1250-ev1: Convert to GPIO descriptors
In-Reply-To: <20231208124257.GQ14858@ediswmail.ad.cirrus.com>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-2-c4dab6f521ec@linaro.org>
 <20231208124257.GQ14858@ediswmail.ad.cirrus.com>
Message-ID: <20231208124847.GT14858@ediswmail.ad.cirrus.com>

On Fri, Dec 08, 2023 at 12:42:57PM +0000, Charles Keepax wrote:
> On Fri, Dec 08, 2023 at 11:09:26AM +0100, Linus Walleij wrote:
> > This converts the WM1250-EV1 codec to use GPIO descriptors.
> > It turns out that the platform data was only used to pass some
> > global GPIO numbers from a board file, so we get rid of this
> > and also switch over the single in-tree user in the S3C
> > Cragganmore module for S3C 6410.
> > 
> > The driver obtains two GPIO lines named OSR and master and just
> > pull them low, we leave this behaviour as it was.
> > 
> > Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> > ---
> > +	.table = {
> > +		GPIO_LOOKUP("GPION", 12, "clk-ena", GPIO_ACTIVE_HIGH),
> > +		GPIO_LOOKUP("GPIOL", 12, "clk-sel0", GPIO_ACTIVE_HIGH),
> > +		GPIO_LOOKUP("GPIOL", 13, "clk-sel1", GPIO_ACTIVE_HIGH),
> > +		GPIO_LOOKUP("GPIOL", 14, "osr", GPIO_ACTIVE_HIGH),
> > +		GPIO_LOOKUP("GPIOL", 8, "master", GPIO_ACTIVE_HIGH),
> > +		{ },
> 
> For my curiousity, what is the significance of GPION vs GPIOL here?
> 

oops nvm I see it.

Thanks,
Charles


From ckeepax at opensource.cirrus.com  Fri Dec  8 04:50:51 2023
From: ckeepax at opensource.cirrus.com (Charles Keepax)
Date: Fri, 8 Dec 2023 12:50:51 +0000
Subject: [PATCH 5/5] ASoC: wm8996: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-5-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-5-c4dab6f521ec@linaro.org>
Message-ID: <20231208125051.GU14858@ediswmail.ad.cirrus.com>

On Fri, Dec 08, 2023 at 11:09:29AM +0100, Linus Walleij wrote:
> This converts the WM8996 codec to use GPIO descriptors, an a similar
> way to WM5100.
> 
> The driver is instantiating a GPIO chip named wm8996, and we get
> rid of the base address for the GPIO chip from the platform data and
> just use dynamic numbering. Move base and ngpio into the static
> gpio_chip template.
> 
> Fix up the only in-tree user which is the Cragganmore 6410 module.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---

Reviewed-by: Charles Keepax <ckeepax at opensource.cirrus.com>

Thanks,
Charles


From lkp at intel.com  Fri Dec  8 04:49:59 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 8 Dec 2023 20:49:59 +0800
Subject: [PATCH v2] coresight: Make current W=1 warnings default
In-Reply-To: <20231115162834.355598-1-james.clark@arm.com>
References: <20231115162834.355598-1-james.clark@arm.com>
Message-ID: <202312082029.j4D5rwSe-lkp@intel.com>

Hi James,

kernel test robot noticed the following build warnings:

[auto build test WARNING on atorgue-stm32/stm32-next]
[also build test WARNING on soc/for-next linus/master v6.7-rc4 next-20231208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/James-Clark/coresight-Make-current-W-1-warnings-default/20231116-004818
base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
patch link:    https://lore.kernel.org/r/20231115162834.355598-1-james.clark%40arm.com
patch subject: [PATCH v2] coresight: Make current W=1 warnings default
config: arm-randconfig-r131-20231117 (https://download.01.org/0day-ci/archive/20231208/202312082029.j4D5rwSe-lkp at intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231208/202312082029.j4D5rwSe-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312082029.j4D5rwSe-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/hwtracing/coresight/coresight-tpdm.c:242:17: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-tpdm.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
--
>> drivers/hwtracing/coresight/coresight-etb10.c:840:17: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-etb10.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
--
>> drivers/hwtracing/coresight/coresight-funnel.c:395:17: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-funnel.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/slab.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false

vim +242 drivers/hwtracing/coresight/coresight-tpdm.c

   232	
   233	/*
   234	 * Different TPDM has different periph id.
   235	 * The difference is 0-7 bits' value. So ignore 0-7 bits.
   236	 */
   237	static struct amba_id tpdm_ids[] = {
   238		{
   239			.id = 0x000f0e00,
   240			.mask = 0x000fff00,
   241		},
 > 242		{ 0, 0, 0 },
   243	};
   244	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From linus.walleij at linaro.org  Fri Dec  8 04:54:21 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 8 Dec 2023 13:54:21 +0100
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-in-suspend property
In-Reply-To: <20231207111300.80581-2-eichest@gmail.com>
References: <20231207111300.80581-1-eichest@gmail.com> <20231207111300.80581-2-eichest@gmail.com>
Message-ID: <CACRpkdbSs-vebvchxx-Tg+O5CUF5M3vZf-iytuW=ZECnHb2anA@mail.gmail.com>

On Thu, Dec 7, 2023 at 12:13?PM Stefan Eichenberger <eichest at gmail.com> wrote:

> From: Stefan Eichenberger <stefan.eichenberger at toradex.com>
>
> Add a new property to indicate that the device should be powered off in
> suspend mode.
>
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>
(...)
> +  atmel,poweroff-in-suspend:
> +    description: |
> +      When this property is set, all supplies are turned off when the system is
> +      going to suspend.
> +    type: boolean
   wakeup-source:
     type: boolean

As Krzysztof says it seems you are describing an operating system feature.

I can't help but wonder: shouldn't that pretty much be the default behaviour
if wakeup-source is *not* specified?

I.e. the property kind of describes !wakeup-source.

Yours,
Linus Walleij


From wahrenst at gmx.net  Fri Dec  8 05:00:05 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Fri, 8 Dec 2023 14:00:05 +0100
Subject: [PATCH v3 4/4] staging: vc04_services: Drop vchiq_log_debug() in
 favour of dev_dbg
In-Reply-To: <20231205084157.73819-5-umang.jain@ideasonboard.com>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-5-umang.jain@ideasonboard.com>
Message-ID: <21f30b11-6695-4540-80b7-5f7b9b4325b2@gmx.net>

Hi Umang,

Am 05.12.23 um 09:41 schrieb Umang Jain:
> Drop vchiq_log_debug() macro which wraps dev_dbg(). Introduce the usage
> of dev_dbg() directly.
>
> Meanwhile at it, drop the usage of __func__ from the logs.
> Dynamic debug supports this via the 'f'  decorator flag.
>
> Remove the entry from TODO regarding custom logging. VC04 is now
> aligned according to the standard kernel logging mechanisms.
personally i would have mentioned that this patch also drop the now
unused logging categories. Except of this i'm fine with the patch.

Possibled future improvements are mentioned below
>
> Signed-off-by: Umang Jain <umang.jain at ideasonboard.com>
> ---
>   drivers/staging/vc04_services/interface/TODO  |   5 -
>   .../interface/vchiq_arm/vchiq_arm.c           |  45 +++--
>   .../interface/vchiq_arm/vchiq_core.c          | 159 ++++++++----------
>   .../interface/vchiq_arm/vchiq_core.h          |  26 ---
>   .../interface/vchiq_arm/vchiq_dev.c           |  32 ++--
>   5 files changed, 106 insertions(+), 161 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/TODO b/drivers/staging/vc04_services/interface/TODO
> index 6d9d4a800aa7..05eb5140d096 100644
> --- a/drivers/staging/vc04_services/interface/TODO
> +++ b/drivers/staging/vc04_services/interface/TODO
> @@ -23,11 +23,6 @@ should properly handle a module unload. This also includes that all
>   resources must be freed (kthreads, debugfs entries, ...) and global
>   variables avoided.
>
> -* Cleanup logging mechanism
> -
> -The driver should probably be using the standard kernel logging mechanisms
> -such as dev_info, dev_dbg, and friends.
> -
>   * Documentation
>
>   A short top-down description of this driver's architecture (function of
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> index e337b8387647..4b4ff469d3a3 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -310,9 +310,8 @@ create_pagelist(struct vchiq_instance *instance, char *buf, char __user *ubuf,
>   						   type == PAGELIST_READ, pages);
>
>   		if (actual_pages != num_pages) {
> -			vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
> -					"%s - only %d/%d pages locked",
> -					__func__, actual_pages, num_pages);
> +			dev_dbg(instance->state->dev, "arm: Only %d/%d pages locked\n",
> +				actual_pages, num_pages);
>
>   			/* This is probably due to the process being killed */
>   			if (actual_pages > 0)
> @@ -554,8 +553,8 @@ static int vchiq_platform_init(struct platform_device *pdev, struct vchiq_state
>   		return -ENXIO;
>   	}
>
> -	vchiq_log_debug(&pdev->dev, VCHIQ_ARM, "vchiq_init - done (slots %pK, phys %pad)",
> -			vchiq_slot_zero, &slot_phys);
> +	dev_dbg(&pdev->dev, "arm: vchiq_init - done (slots %pK, phys %pad)\n",
> +		vchiq_slot_zero, &slot_phys);
>
>   	vchiq_call_connected_callbacks();
>
> @@ -719,9 +718,9 @@ void free_bulk_waiter(struct vchiq_instance *instance)
>   	list_for_each_entry_safe(waiter, next,
>   				 &instance->bulk_waiter_list, list) {
>   		list_del(&waiter->list);
> -		vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
> -				"bulk_waiter - cleaned up %pK for pid %d",
> -				waiter, waiter->pid);
> +		dev_dbg(instance->state->dev,
> +			"arm: bulk_waiter - cleaned up %pK for pid %d\n",
> +			waiter, waiter->pid);
>   		kfree(waiter);
>   	}
>   }
> @@ -981,9 +980,8 @@ vchiq_blocking_bulk_transfer(struct vchiq_instance *instance, unsigned int handl
>   		mutex_lock(&instance->bulk_waiter_list_mutex);
>   		list_add(&waiter->list, &instance->bulk_waiter_list);
>   		mutex_unlock(&instance->bulk_waiter_list_mutex);
> -		vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
> -				"saved bulk_waiter %pK for pid %d", waiter,
> -				current->pid);
> +		dev_dbg(instance->state->dev, "arm: saved bulk_waiter %pK for pid %d\n",
> +			waiter, current->pid);
>   	}
>
>   	return status;
> @@ -1006,12 +1004,10 @@ add_completion(struct vchiq_instance *instance, enum vchiq_reason reason,
>   		dev_dbg(instance->state->dev, "core: completion queue full\n");
>   		DEBUG_COUNT(COMPLETION_QUEUE_FULL_COUNT);
>   		if (wait_for_completion_interruptible(&instance->remove_event)) {
> -			vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
> -					"service_callback interrupted");
> +			dev_dbg(instance->state->dev, "arm: service_callback interrupted\n");
>   			return -EAGAIN;
>   		} else if (instance->closing) {
> -			vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
> -					"service_callback closing");
> +			dev_dbg(instance->state->dev, "arm: service_callback closing\n");
>   			return 0;
>   		}
>   		DEBUG_TRACE(SERVICE_CALLBACK_LINE);
> @@ -1113,8 +1109,8 @@ service_callback(struct vchiq_instance *instance, enum vchiq_reason reason,
>   				instance->completion_remove) < 0) {
>   				int status;
>
> -				vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
> -						"Inserting extra MESSAGE_AVAILABLE");
> +				dev_dbg(instance->state->dev,
> +					"arm: Inserting extra MESSAGE_AVAILABLE\n");
>   				DEBUG_TRACE(SERVICE_CALLBACK_LINE);
>   				status = add_completion(instance, reason, NULL, user_service,
>   							bulk_userdata);
> @@ -1127,14 +1123,12 @@ service_callback(struct vchiq_instance *instance, enum vchiq_reason reason,
>
>   			DEBUG_TRACE(SERVICE_CALLBACK_LINE);
>   			if (wait_for_completion_interruptible(&user_service->remove_event)) {
> -				vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
> -						"%s interrupted", __func__);
> +				dev_dbg(instance->state->dev, "arm: interrupted\n");
>   				DEBUG_TRACE(SERVICE_CALLBACK_LINE);
>   				vchiq_service_put(service);
>   				return -EAGAIN;
>   			} else if (instance->closing) {
> -				vchiq_log_debug(instance->state->dev, VCHIQ_ARM,
> -						"%s closing", __func__);
> +				dev_dbg(instance->state->dev, "arm: closing\n");
>   				DEBUG_TRACE(SERVICE_CALLBACK_LINE);
>   				vchiq_service_put(service);
>   				return -EINVAL;
> @@ -1686,8 +1680,8 @@ void vchiq_platform_conn_state_changed(struct vchiq_state *state,
>   	struct vchiq_arm_state *arm_state = vchiq_platform_get_arm_state(state);
>   	char threadname[16];
>
> -	vchiq_log_debug(state->dev, VCHIQ_SUSPEND, "%d: %s->%s", state->id,
> -			get_conn_state_name(oldstate), get_conn_state_name(newstate));
> +	dev_dbg(state->dev, "suspend: %d: %s->%s\n",
> +		state->id, get_conn_state_name(oldstate), get_conn_state_name(newstate));
>   	if (state->conn_state != VCHIQ_CONNSTATE_CONNECTED)
>   		return;
>
> @@ -1751,9 +1745,8 @@ static int vchiq_probe(struct platform_device *pdev)
>
>   	vchiq_debugfs_init();
>
> -	vchiq_log_debug(&pdev->dev, VCHIQ_ARM,
> -			"vchiq: platform initialised - version %d (min %d)",
> -			VCHIQ_VERSION, VCHIQ_VERSION_MIN);
> +	dev_dbg(&pdev->dev, "arm: platform initialised - version %d (min %d)\n",
> +		VCHIQ_VERSION, VCHIQ_VERSION_MIN);
>
>   	/*
>   	 * Simply exit on error since the function handles cleanup in
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> index d197e4504bd4..76c27778154a 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> @@ -217,10 +217,10 @@ static const char *msg_type_str(unsigned int msg_type)
>   static inline void
>   set_service_state(struct vchiq_service *service, int newstate)
>   {
> -	vchiq_log_debug(service->state->dev, VCHIQ_CORE, "%d: srv:%d %s->%s",
> -			service->state->id, service->localport,
> -			srvstate_names[service->srvstate],
> -			srvstate_names[newstate]);
> +	dev_dbg(service->state->dev, "core: %d: srv:%d %s->%s\n",
> +		service->state->id, service->localport,
> +		srvstate_names[service->srvstate],
> +		srvstate_names[newstate]);
>   	service->srvstate = newstate;
>   }
>
> @@ -245,8 +245,7 @@ find_service_by_handle(struct vchiq_instance *instance, unsigned int handle)
>   		return service;
>   	}
>   	rcu_read_unlock();
> -	vchiq_log_debug(instance->state->dev, VCHIQ_CORE,
> -			"Invalid service handle 0x%x", handle);
> +	dev_dbg(instance->state->dev, "core: Invalid service handle 0x%x\n", handle);
 From my PoV this is a real error, so maybe a WARN_ONCE. But looking
deeper at this shows that the error handling must be reworked first :-(


From eichest at gmail.com  Fri Dec  8 05:11:18 2023
From: eichest at gmail.com (Stefan Eichenberger)
Date: Fri, 8 Dec 2023 14:11:18 +0100
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-in-suspend property
In-Reply-To: <CACRpkdbSs-vebvchxx-Tg+O5CUF5M3vZf-iytuW=ZECnHb2anA@mail.gmail.com>
References: <20231207111300.80581-1-eichest@gmail.com>
 <20231207111300.80581-2-eichest@gmail.com>
 <CACRpkdbSs-vebvchxx-Tg+O5CUF5M3vZf-iytuW=ZECnHb2anA@mail.gmail.com>
Message-ID: <ZXMV9gzFbc05IEKg@eichest-laptop>

Hi Krzysztof and Linux,

On Fri, Dec 08, 2023 at 01:54:21PM +0100, Linus Walleij wrote:
> On Thu, Dec 7, 2023 at 12:13?PM Stefan Eichenberger <eichest at gmail.com> wrote:
> 
> > From: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> >
> > Add a new property to indicate that the device should be powered off in
> > suspend mode.
> >
> > Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> (...)
> > +  atmel,poweroff-in-suspend:
> > +    description: |
> > +      When this property is set, all supplies are turned off when the system is
> > +      going to suspend.
> > +    type: boolean
>    wakeup-source:
>      type: boolean
> 
> As Krzysztof says it seems you are describing an operating system feature.
> 
> I can't help but wonder: shouldn't that pretty much be the default behaviour
> if wakeup-source is *not* specified?
> 
> I.e. the property kind of describes !wakeup-source.

The maxtouch controller has a deep sleep mode which is currently used
without powering down vdd and vdda. However, because we have a shared
regulator which powers other peripherals that we want to shut down in
suspend we need a way to power down vdd and vdda. However, I agree this
is not really a feature of the device. The feature would basically be
the internal deep sleep mode. I didn't want to change the default
behaviour of the driver, so I added this property but maybe I could
change it to:

atmel,deep-sleep:
  description: |
     Use the maxtouch deep-sleep mode instead of powering down vdd and
     vdda.

Or to not change the default behaviour:
atmel,no-deep-sleep:
  description: |
     Do not use the maxtouch deep-sleep mode but power down vdd and vdda
     in suspend.

As I understand the datasheet even if the maxtouch is using its deep
sleep mode it does not act as a wakeup source. It is just faster in
waking up because it can keep the configuration in memory.

Regards,
Stefan


From andrew at lunn.ch  Fri Dec  8 05:14:41 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 8 Dec 2023 14:14:41 +0100
Subject: [PATCH net-next v2] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <nx2qggr3aget4t57qbosj6ya5ocq47t6w33ve5ycabs5mzvo7c@vctjvc5gip5d>
References: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
 <e64b14c3-4b80-4120-8cc4-9baa40cdcb75@lunn.ch>
 <nx2qggr3aget4t57qbosj6ya5ocq47t6w33ve5ycabs5mzvo7c@vctjvc5gip5d>
Message-ID: <9eddb32d-c798-4e1b-b0ea-c44d31cc29bf@lunn.ch>

> I know you said the standard is to make the MDIO bus unconditionally, but
> to me that feels like a waste, and describing say an empty MDIO bus
> (which would set the phy_mask for us eventually and not scan a
> bunch of phys, untested but I think that would work) seems like a bad
> description in the devicetree (I could definitely see describing an
> empty MDIO bus getting NACKed, but that's a guess).

DT describes the hardware. The MDIO bus master exists. So typically
the SoC .dtsi file would include it in the Ethernet node. At the SoC
level it is empty, unless there is an integrated PHY in the SoC. The
board .dts file then adds any PHYs to the node which the board
actually has.

So i doubt adding an empty MDIO node to the SoC .dtsi file will get
NACKed, it correctly describes the hardware.

	Andrew


From willy at infradead.org  Fri Dec  8 05:22:03 2023
From: willy at infradead.org (Matthew Wilcox)
Date: Fri, 8 Dec 2023 13:22:03 +0000
Subject: [PATCH] arm64: mm: support THP_SWAP on hardware with MTE
In-Reply-To: <20231208073401.70153-1-v-songbaohua@oppo.com>
References: <20231208073401.70153-1-v-songbaohua@oppo.com>
Message-ID: <ZXMYe2IDVll6pBn9@casper.infradead.org>

On Fri, Dec 08, 2023 at 08:34:01PM +1300, Barry Song wrote:
> arch_prepare_to_swap() should take folio rather than page as parameter
> because we support THP swap-out as a whole. It saves tags for all
> pages in a large folio.
> 
> Meanwhile, arch_swap_restore() now moves to use page parameter rather
> than folio because swap-in, refault and MTE tags are working at the
> granularity of base pages rather than folio:
> 1. a large folio in swapcache can be partially unmapped, thus, MTE
> tags for the unmapped pages will be invalidated;
> 2. users might use mprotect() to set MTEs on a part of a large folio.

I would argue that using mprotect() to set MTEs on part of a large folio
should cause that folio to be split.  Could the user give us any
stronger signal that this memory is being used for different purposes,
and therefore should not be managed as a single entity?

> Thus, it won't be easy to manage MTE tags at the granularity of folios
> since we do have some cases in which a part of pages in a large folios
> have valid tags, while the other part of pages haven't. Furthermore,
> trying to restore MTE tags for a whole folio can lead to many loops and
> early exiting even if the large folio in swapcache are still entirely
> mapped since do_swap_page() only sets PTE and frees swap for the base
> page where PF is happening.
> 
> But we still have a chance to restore tags for a whole large folio
> once we support swap-in large folio. So this job is deferred till we
> can do refault and swap-in as a large folio.

I strongly disagree with changing the interface to arch_swap_restore()
from folio to page.


From broonie at kernel.org  Fri Dec  8 05:43:06 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 8 Dec 2023 13:43:06 +0000
Subject: [PATCH v2 01/12] KVM: Add missing HCRX_EL2 field definitions
In-Reply-To: <CA+EHjTx7LJJzOHbO=ubWtuwhbVXd3FyX99Y6LxkT6u9vSx8qxA@mail.gmail.com>
References: <20231206100503.564090-1-tabba@google.com>
 <20231206100503.564090-2-tabba@google.com>
 <7c85421b-5dfd-4931-bb14-aa2416e54b58@sirena.org.uk>
 <CA+EHjTx7LJJzOHbO=ubWtuwhbVXd3FyX99Y6LxkT6u9vSx8qxA@mail.gmail.com>
Message-ID: <ZXMdasQNGNPFPP3E@finisterre.sirena.org.uk>

On Fri, Dec 08, 2023 at 08:14:58AM +0000, Fuad Tabba wrote:
> On Thu, Dec 7, 2023 at 4:57?PM Mark Brown <broonie at kernel.org> wrote:

> > (that series does make use of EnFPM).  Given the likelyhood of overlaps
> > like this I really think we should be merging these sysreg updates even
> > if the serieses that depend on them are still in flight, it doesn't make
> > sense for multiple people to end up doing the typing.

> Makes sense. We'll ask one of the maintainers to pick up your updates.

Thanks.  I'm in the middle of pulling a series together which gathers
all the sysreg additions I'm aware of together which are ready
(including yours from this series) - should be out later today unless
something unexpected happens in my CI, hopefully one way or another
everything will get pulled in.  I'll Cc you when I post.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/38a02835/attachment.sig>

From broonie at kernel.org  Fri Dec  8 05:51:25 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 8 Dec 2023 13:51:25 +0000
Subject: [PATCH v2 05/12] KVM: arm64: Handle HAFGRTR_EL2 trapping in
 nested virt
In-Reply-To: <CA+EHjTx42qgepOaFMt1wLSQ6uPUv8wQTa2z-Z_PEiVPUwYAL8A@mail.gmail.com>
References: <20231206100503.564090-1-tabba@google.com>
 <20231206100503.564090-6-tabba@google.com>
 <006ec2b0-6263-4e86-8641-d81c01a91c8e@sirena.org.uk>
 <CA+EHjTx42qgepOaFMt1wLSQ6uPUv8wQTa2z-Z_PEiVPUwYAL8A@mail.gmail.com>
Message-ID: <ZXMfXb44R5mZHm5m@finisterre.sirena.org.uk>

On Fri, Dec 08, 2023 at 08:19:43AM +0000, Fuad Tabba wrote:
> On Thu, Dec 7, 2023 at 5:28?PM Mark Brown <broonie at kernel.org> wrote:

> > > +Sysreg HAFGRTR_EL2   3       4       3       1       6
> > > +Res0 63:50

> > Oh, we actually have the register fully encoded since we needed the
> > fields.  Given this why did we need the manual encoding in the previous
> > patch?  In any case this looks good according to DDI0601 2023-09:

> We need both because we need to know the polarity. RES0 and the valid
> bits are generated. In later patches in this series I move completely
> to using the generated RES0, and to calculating nMASK based on the
> other fields. But we still need the definitions in kvm_arm.h for the
> polarity.

Ah, I see - that makes sense.  We could consider extending the language
to capture this information in the sysreg definition rather than typing
it in separately, though it's not going to get that much usage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/1a8e5144/attachment.sig>

From ryan.roberts at arm.com  Fri Dec  8 06:00:34 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Fri, 8 Dec 2023 14:00:34 +0000
Subject: [PATCH] arm64: mm: support THP_SWAP on hardware with MTE
In-Reply-To: <ZXMYe2IDVll6pBn9@casper.infradead.org>
References: <20231208073401.70153-1-v-songbaohua@oppo.com>
 <ZXMYe2IDVll6pBn9@casper.infradead.org>
Message-ID: <992ba52a-fcbc-4a6a-9bd1-416b4ae60cc8@arm.com>

On 08/12/2023 13:22, Matthew Wilcox wrote:
> On Fri, Dec 08, 2023 at 08:34:01PM +1300, Barry Song wrote:
>> arch_prepare_to_swap() should take folio rather than page as parameter
>> because we support THP swap-out as a whole. It saves tags for all
>> pages in a large folio.
>>
>> Meanwhile, arch_swap_restore() now moves to use page parameter rather
>> than folio because swap-in, refault and MTE tags are working at the
>> granularity of base pages rather than folio:
>> 1. a large folio in swapcache can be partially unmapped, thus, MTE
>> tags for the unmapped pages will be invalidated;
>> 2. users might use mprotect() to set MTEs on a part of a large folio.
> 
> I would argue that using mprotect() to set MTEs on part of a large folio
> should cause that folio to be split.  Could the user give us any
> stronger signal that this memory is being used for different purposes,
> and therefore should not be managed as a single entity?

I agree this probably makes sense here. But splitting is best effort as I
understand it? It can fail due to long-term GUP, right? In which case we still
have to handle the MTE on partial large folio case safely, even if not performantly.

As an aside, I don't think it's clear cut that we would always prefer to split
based on user space mprotect/madvise/etc calls. IIUC, there are garbage
collectors that temporarily mark pages RO then switch back to RW. I wouldn't
want to split here and lose the benefits of contpte forever. I'm handwaving
because I haven't looked into the exact mechanisms yet. But I think we need to
understand these users better before deciding on an "always split based on user
hints" policy.

> 
>> Thus, it won't be easy to manage MTE tags at the granularity of folios
>> since we do have some cases in which a part of pages in a large folios
>> have valid tags, while the other part of pages haven't. Furthermore,
>> trying to restore MTE tags for a whole folio can lead to many loops and
>> early exiting even if the large folio in swapcache are still entirely
>> mapped since do_swap_page() only sets PTE and frees swap for the base
>> page where PF is happening.
>>
>> But we still have a chance to restore tags for a whole large folio
>> once we support swap-in large folio. So this job is deferred till we
>> can do refault and swap-in as a large folio.
> 
> I strongly disagree with changing the interface to arch_swap_restore()
> from folio to page.



From arnd at arndb.de  Fri Dec  8 05:59:56 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 08 Dec 2023 14:59:56 +0100
Subject: [GIT PULL] ARM: SoC fixes for v6.7
Message-ID: <90aa3b5f-a0d4-4609-85c2-e3d4cc944102@app.fastmail.com>

The following changes since commit 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab:

  Linux 6.7-rc3 (2023-11-26 19:59:33 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-fixes-6.7-1

for you to fetch changes up to fd1e5745f87a9e06974d2f42d22b3e1682c99105:

  Merge tag 'v6.7-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes (2023-12-08 08:36:25 +0100)

----------------------------------------------------------------
ARM: SoC fixes for v6.7

Most of the changes are devicetree fixes for NXP, Mediatek, Rockchips
Arm machines as well as Microchip RISC-V, and most of these address
build-time warnings for spec violations and other minor issues. One of
the Mediatek warnings was enabled by default and prevented a clean build.
The ones that address serious runtime issues are all on the i.MX platform:

 - a boot time panic on imx8qm
 - USB hanging under load on imx8
 - regressions on the imx93 ethernet phy

Code fixes include a minor error handling for the i.MX PMU driver, and
a number of firmware driver fixes:

 - OP-TEE fix for supplicant based device enumeration, and a new
   sysfs attribute to needed to fix a race against userspace

 - Arm SCMI fix for possible truncation/overflow in the frequency
   computations

 - Multiple FF-A fixes for the newly added notification support.

----------------------------------------------------------------
Ahmad Fatoum (1):
      MAINTAINERS: reinstate freescale ARM64 DT directory in i.MX entry

Alex Bee (2):
      arm64: dts: rockchip: Expand reg size of vdec node for RK3399
      ARM: dts: rockchip: Fix sdmmc_pwren's pinmux setting for RK3128

Alexander Stein (4):
      arm64: dt: imx93: tqma9352-mba93xxla: Fix LPUART2 pad config
      dt-bindings: pwm: imx-pwm: Unify #pwm-cells for all compatibles
      arm64: dts: freescale: imx8-ss-lsio: Fix #pwm-cells
      arm64: dts: freescale: imx8-ss-dma: Fix #pwm-cells

AngeloGioacchino Del Regno (7):
      arm64: dts: mediatek: mt8195: Fix PM suspend/resume with venc clocks
      arm64: dts: mediatek: mt8183: Fix unit address for scp reserved memory
      arm64: dts: mediatek: mt8183-evb: Fix unit_address_vs_reg warning on ntc
      arm64: dts: mediatek: mt8173-evb: Fix regulator-fixed node names
      arm64: dts: mediatek: mt8183: Move thermal-zones to the root node
      arm64: dts: mediatek: mt8186: Change gpu speedbin nvmem cell name
      arm64: dts: mediatek: cherry: Fix interrupt cells for MT6360 on I2C7

Arnd Bergmann (8):
      Merge tag 'optee-supplicant-fix-for-v6.7' of git://git.linaro.org:/people/jens.wiklander/linux-tee into arm/fixes
      Merge tag 'mtk-dts64-fixes-for-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into arm/fixes
      Merge tag 'riscv-dt-fixes-for-v6.7-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes
      Merge tag 'scmi-fixes-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
      Merge tag 'arm-soc/for-6.7/devicetree-fixes' of https://github.com/Broadcom/stblinux into arm/fixes
      Merge tag 'ffa-fixes-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
      Merge tag 'imx-fixes-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
      Merge tag 'v6.7-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes

Chester Lin (1):
      MAINTAINERS: change the S32G2 maintainer's email address.

Conor Dooley (2):
      riscv: dts: sophgo: remove address-cells from intc node
      riscv: dts: microchip: move timebase-frequency to mpfs.dtsi

Eric Woudstra (1):
      arm64: dts: mt7986: fix emmc hs400 mode without uboot initialization

Eugen Hristev (3):
      arm64: dts: mediatek: mt8186: fix clock names for power domains
      arm64: dts: mediatek: mt7622: fix memory node warning check
      arm64: dts: mediatek: mt8183-kukui-jacuzzi: fix dsi unnecessary cells properties

Fabio Estevam (2):
      ARM: dts: imx6ul-pico: Describe the Ethernet PHY clock
      ARM: dts: imx28-xea: Pass the 'model' property

Frank Wunderlich (2):
      arm64: dts: mt7986: define 3W max power to both SFP on BPI-R3
      arm64: dts: mt7986: change cooling trips

Haibo Chen (2):
      arm64: dts: imx93: update gpio node name to align with register address
      arm64: dts: imx8ulp: update gpio node name to align with register address

Heiko Stuebner (2):
      arm64: dts: rockchip: fix rk356x pcie msg interrupt name
      arm64: dts: rockchip: drop interrupt-names property from rk3588s dfi

Hsin-Yi Wang (1):
      arm64: dts: mt8183: kukui: Fix underscores in node names

Jonas Karlman (1):
      arm64: dts: rockchip: Expand reg size of vdec node for RK3328

Krzysztof Kozlowski (2):
      ARM: dts: rockchip: minor whitespace cleanup around '='
      arm64: dts: rockchip: minor whitespace cleanup around '='

Kunwu Chan (1):
      ARM: imx: Check return value of devm_kasprintf in imx_mmdc_perf_init

Lorenzo Pieralisi (1):
      firmware: arm_ffa: Fix ffa_notification_info_get() IDs handling

Nathan Rossi (1):
      arm64: dts: imx8mp: imx8mq: Add parkmode-disable-ss-quirk on DWC3

Peng Fan (1):
      arm64: dts: imx93: correct mediamix power

Philipp Zabel (1):
      ARM: dts: imx7: Declare timers compatible with fsl,imx6dl-gpt

Rob Herring (1):
      arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru

Sam Edwards (2):
      arm64: dts: rockchip: Fix Turing RK1 interrupt pinctrls
      arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588

Sascha Hauer (1):
      dt-bindings: soc: rockchip: grf: add rockchip,rk3588-pmugrf

Stefan Eichenberger (1):
      arm64: dts: imx8-apalis: set wifi regulator to always-on

Stefan Kerkmann (1):
      ARM: dts: imx6q: skov: fix ethernet clock regression

Stefan Wahren (1):
      ARM: dts: bcm2711-rpi-400: Fix delete-node of led_act

Sudeep Holla (8):
      firmware: arm_ffa: Declare ffa_bus_type structure in the header
      firmware: arm_ffa: Allow FF-A initialisation even when notification fails
      firmware: arm_ffa: Setup the partitions after the notification initialisation
      firmware: arm_ffa: Add checks for the notification enabled state
      firmware: arm_ffa: Fix FFA notifications cleanup path
      firmware: arm_ffa: Fix the size of the allocation in ffa_partitions_cleanup()
      firmware: arm_scmi: Fix frequency truncation by promoting multiplier type
      firmware: arm_scmi: Fix possible frequency truncation when using level indexing mode

Sumit Garg (1):
      tee: optee: Fix supplicant based device enumeration

Xiaolei Wang (1):
      arm64: dts: imx8qm: Add imx8qm's own pm to avoid panic during startup

 Documentation/ABI/testing/sysfs-bus-optee-devices  |   9 +
 Documentation/devicetree/bindings/pwm/imx-pwm.yaml |  10 +-
 .../devicetree/bindings/soc/rockchip/grf.yaml      |   1 +
 MAINTAINERS                                        |   3 +-
 arch/arm/boot/dts/broadcom/bcm2711-rpi-400.dts     |   4 +-
 .../dts/nxp/imx/imx6q-skov-reve-mi1010ait-1cp1.dts |   4 +-
 arch/arm/boot/dts/nxp/imx/imx6ul-pico.dtsi         |   2 +
 arch/arm/boot/dts/nxp/imx/imx7s.dtsi               |   8 +-
 arch/arm/boot/dts/nxp/mxs/imx28-xea.dts            |   1 +
 arch/arm/boot/dts/rockchip/rk3128.dtsi             |   2 +-
 arch/arm/boot/dts/rockchip/rk322x.dtsi             |   6 +-
 arch/arm/mach-imx/mmdc.c                           |   7 +-
 .../arm64/boot/dts/freescale/imx8-apalis-v1.1.dtsi |   5 +-
 arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi     |   2 +-
 arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi    |   8 +-
 arch/arm64/boot/dts/freescale/imx8mp.dtsi          |   2 +
 arch/arm64/boot/dts/freescale/imx8mq.dtsi          |   2 +
 arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi   |  11 +
 arch/arm64/boot/dts/freescale/imx8ulp.dtsi         |   6 +-
 .../dts/freescale/imx93-tqma9352-mba93xxla.dts     |   2 +-
 arch/arm64/boot/dts/freescale/imx93.dtsi           |  10 +-
 .../boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts  |   2 +-
 arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts       |   2 +-
 .../boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts  |  12 +-
 arch/arm64/boot/dts/mediatek/mt7986a.dtsi          |  24 +-
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts        |   4 +-
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts        |   4 +-
 .../boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi    |   8 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi     |  96 ++++----
 arch/arm64/boot/dts/mediatek/mt8183.dtsi           | 242 ++++++++++-----------
 arch/arm64/boot/dts/mediatek/mt8186.dtsi           |  44 ++--
 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi    |   2 +-
 arch/arm64/boot/dts/mediatek/mt8195.dtsi           |   6 +-
 .../boot/dts/rockchip/px30-ringneck-haikou.dts     |   2 +-
 arch/arm64/boot/dts/rockchip/rk3328.dtsi           |   2 +-
 .../boot/dts/rockchip/rk3399-gru-chromebook.dtsi   |   3 +-
 .../boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts  |   4 +-
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi       |   1 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |   6 +-
 arch/arm64/boot/dts/rockchip/rk356x.dtsi           |   2 +-
 .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |   4 +-
 .../arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts |   2 +-
 arch/arm64/boot/dts/rockchip/rk3588s-pinctrl.dtsi  |   2 +-
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi          |   1 -
 arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts  |   7 -
 arch/riscv/boot/dts/microchip/mpfs-m100pfsevp.dts  |   7 -
 arch/riscv/boot/dts/microchip/mpfs-polarberry.dts  |   7 -
 arch/riscv/boot/dts/microchip/mpfs-sev-kit.dts     |   7 -
 arch/riscv/boot/dts/microchip/mpfs-tysom-m.dts     |   7 -
 arch/riscv/boot/dts/microchip/mpfs.dtsi            |   1 +
 arch/riscv/boot/dts/sophgo/cv1800b.dtsi            |   1 -
 drivers/firmware/arm_ffa/driver.c                  |  70 ++++--
 drivers/firmware/arm_scmi/perf.c                   |  18 +-
 drivers/tee/optee/device.c                         |  17 +-
 include/linux/arm_ffa.h                            |   2 +
 55 files changed, 396 insertions(+), 328 deletions(-)


From cki-project at redhat.com  Fri Dec  8 06:21:14 2023
From: cki-project at redhat.com (cki-project at redhat.com)
Date: Fri, 08 Dec 2023 14:21:14 -0000
Subject: =?utf-8?b?4p2M?= FAIL (MISSED 7 of 103): Test report for for-kernelci
 (6.7.0-rc4, arm-next, d46efae3)
Message-ID: <35819.123120809211500223@us-mta-578.us.mimecast.lan>

Hi, we tested your kernel and here are the results:

    Overall result: FAILED
             Merge: OK
           Compile: OK
              Test: FAILED


Kernel information:
    Commit message: Merge branch 'for-next/core' into for-kernelci

You can find all the details about the test run at
    https://datawarehouse.cki-project.org/kcidb/checkouts/117721

One or more kernel tests failed:
    Unrecognized or new issues:
         aarch64 - Reboot test
                   Logs: https://datawarehouse.cki-project.org/kcidb/tests/10533972
                   Non-passing ran subtests:
                       ? FAIL misc/reboot-test/journalctl-check

    We also see the following known issues which are not related to your changes:
        Issue: [rawhide] SELinux is preventing systemd-userdbd from map_read, map_write access on the bpf labeled init_t.
            URL: https://bugzilla.redhat.com/show_bug.cgi?id=2250930
            Affected tests:
                 aarch64 - machineinfo
                 aarch64 - Boot test
                 aarch64 - Hardware - IPMItool loop stress test
                 aarch64 - Storage - blktests - blk
                 aarch64 - Storage - blktests - nvme-tcp
                 aarch64 - Storage - block - filesystem fio test
                 aarch64 - Storage - swraid scsi_raid
                 aarch64 - stress: stress-ng - cpu-cache
                 aarch64 - stress: stress-ng - memory
                 aarch64 - Reboot test
                 aarch64 - Storage - block - queue scheduler test
                 aarch64 - Hardware - ACPI table test
                 aarch64 - POSIX pjd-fstest suites
                 aarch64 - Filesystem - Loopdev Sanity
                 aarch64 - Memory function: memfd_create
                 aarch64 - AMTU (Abstract Machine Test Utility)
                 aarch64 - Networking - Ethernet drivers sanity
                 aarch64 - Networking cki netfilter test
                 aarch64 - Networking vnic: ipvlan/basic
                 aarch64 - Libkcapi AF_ALG test
                 aarch64 - Storage - multipath mapping test
                 aarch64 - Storage - lvm thinp sanity
                 aarch64 - xfstests - ext4
                 aarch64 - xfstests - xfs
                 aarch64 - xfstests - btrfs
        Issue: nvme authentication setup failed observed during blktests nvme/041 nvme/042 nvme/043 nvme/044 nvme/045
            URL: https://lore.kernel.org/linux-nvme/CAHj4cs8vqrePA-TE_GGNAZLG3iqZBq9L1GkanA4A0wRF_TXDeA at mail.gmail.com/
            Affected tests:
                 aarch64 - Storage - blktests - blk
                 aarch64 - Storage - blktests - nvme-tcp
        Issue: [upstream] stress-ng: avc denial on secretmemory
            URL: https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issues/1752
            Affected tests:
                 aarch64 - stress: stress-ng - memory

Tests that were not ran because of internal issues: 
     aarch64 - CKI/restraint
     aarch64 - SELinux Custom Module Setup
     aarch64 - machineinfo
     aarch64 - Boot test
     aarch64 - selinux-policy: serge-testsuite
     aarch64 - Hardware - Firmware test suite
     aarch64 - Reboot test


If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.

Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.

        ,-.   ,-.
       ( C ) ( K )  Continuous
        `-',-.`-'   Kernel
          ( I )     Integration
           `-'
______________________________________________________________________________



From linus.walleij at linaro.org  Fri Dec  8 06:23:54 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 8 Dec 2023 15:23:54 +0100
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-in-suspend property
In-Reply-To: <ZXMV9gzFbc05IEKg@eichest-laptop>
References: <20231207111300.80581-1-eichest@gmail.com> <20231207111300.80581-2-eichest@gmail.com>
 <CACRpkdbSs-vebvchxx-Tg+O5CUF5M3vZf-iytuW=ZECnHb2anA@mail.gmail.com> <ZXMV9gzFbc05IEKg@eichest-laptop>
Message-ID: <CACRpkdao83-nALj2YOq-XHrOh6GEaxufN3Fn+3W52qkL2x+VUQ@mail.gmail.com>

On Fri, Dec 8, 2023 at 2:11?PM Stefan Eichenberger <eichest at gmail.com> wrote:

> > I can't help but wonder: shouldn't that pretty much be the default behaviour
> > if wakeup-source is *not* specified?
> >
> > I.e. the property kind of describes !wakeup-source.
>
> The maxtouch controller has a deep sleep mode which is currently used
> without powering down vdd and vdda. However, because we have a shared
> regulator which powers other peripherals that we want to shut down in
> suspend we need a way to power down vdd and vdda. However, I agree this
> is not really a feature of the device. The feature would basically be
> the internal deep sleep mode.

While it is of no concern to the device tree bindings, Linux regulators
are counting meaning that you need to make all peripherals disable
their regulators and it will come down.

> I didn't want to change the default
> behaviour of the driver, so I added this property but maybe I could
> change it to:
>
> atmel,deep-sleep:
>   description: |
>      Use the maxtouch deep-sleep mode instead of powering down vdd and
>      vdda.
>
> Or to not change the default behaviour:
> atmel,no-deep-sleep:
>   description: |
>      Do not use the maxtouch deep-sleep mode but power down vdd and vdda
>      in suspend.
>
> As I understand the datasheet even if the maxtouch is using its deep
> sleep mode it does not act as a wakeup source.

Do you mean it can still work as a wakeup source in deep sleep mode?
(there is a "not" too much above ...)

> It is just faster in
> waking up because it can keep the configuration in memory.

That sounds like a good reason to have the property, because that
means that if you can control the wakeup latency and specify in the binding
how much in absolute time units it is affected.

I would define it in positive terms instead of reverse "no-deep-sleep"
though such as "atmel,fast-wakeup".

And: If you disable the regulators it will probably *not* be able to wake the
system up, right? And that is just a few lines of code in the driver such as:

go_to_sleep():
  if (!wakeup_source):
     disable_regulators()

Yours,
Linus Walleij


From peter.griffin at linaro.org  Fri Dec  8 06:27:44 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 8 Dec 2023 14:27:44 +0000
Subject: [PATCH v5 12/20] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <20bf05b9d9ccc5c11ef17500ac7a97c46dd46a9a.camel@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-13-peter.griffin@linaro.org> <20bf05b9d9ccc5c11ef17500ac7a97c46dd46a9a.camel@linaro.org>
Message-ID: <CADrjBPr_sv29Dc3F-4wVvH_N+qU6509kvHqkyZG==Q1RRpi5gA@mail.gmail.com>

Hi Andr?,

Thanks for the review

On Mon, 4 Dec 2023 at 17:51, Andr? Draszik <andre.draszik at linaro.org> wrote:
>
> On Fri, 2023-12-01 at 16:09 +0000, Peter Griffin wrote:
> > cmu_top is the top level clock management unit which contains PLLs, muxes,
> > dividers and gates that feed the other clock management units.
> >
> > cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> > APM module.
> >
> > Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> > Tested-by: Will McVicker <willmcvicker at google.com>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  drivers/clk/samsung/Makefile    |    1 +
> >  drivers/clk/samsung/clk-gs101.c | 2495 +++++++++++++++++++++++++++++++
> >  2 files changed, 2496 insertions(+)
> >  create mode 100644 drivers/clk/samsung/clk-gs101.c
> >
> > diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> > index ebbeacabe88f..3056944a5a54 100644
> > --- a/drivers/clk/samsung/Makefile
> > +++ b/drivers/clk/samsung/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)       += clk-exynos7.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)        += clk-exynos7885.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)        += clk-exynos850.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)        += clk-exynosautov9.o
> > +obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)        += clk-gs101.o
> >  obj-$(CONFIG_S3C64XX_COMMON_CLK)     += clk-s3c64xx.o
> >  obj-$(CONFIG_S5PV210_COMMON_CLK)     += clk-s5pv210.o clk-s5pv210-audss.o
> >  obj-$(CONFIG_TESLA_FSD_COMMON_CLK)   += clk-fsd.o
> > diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> > new file mode 100644
> > index 000000000000..6bd233a7ab63
> > --- /dev/null
> > +++ b/drivers/clk/samsung/clk-gs101.c
> > @@ -0,0 +1,2495 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2023 Linaro Ltd.
> > + * Author: Peter Griffin <peter.griffin at linaro.org>
> > + *
> > + * Common Clock Framework support for GS101.
> > + */
> > [...]
> > +
> > +/* List of parent clocks for Muxes in CMU_TOP: for CMU_HSI0 */
> > +PNAME(mout_cmu_hsi0_usb31drd_p)      = { "oscclk", "dout_shared2_div2" };
> > +
> > +PNAME(mout_cmu_hsi0_bus_p)   = { "dout_shared0_div4", "dout_shared1_div4",
> > +                                 "dout_shared2_div2", "dout_shared3_div2",
> > +                                 "fout_spare_pll" };
>
> This should also be updated....
>
> > [...]
> > +     MUX(CLK_MOUT_HSI0_BUS, "mout_cmu_hsi0_bus", mout_cmu_hsi0_bus_p,
> > +         CLK_CON_MUX_MUX_CLKCMU_HSI0_BUS, 0, 3),
>
> ...because we have 8 possibilities now.

Interesting, unfortunately there is some discrepancy between the
documentation again :( All the cmu_top clock parents were authored
using the cmu_diagrams which only shows the 5 parents listed above.
Checking the mux register definition it lists 5-7 as being oscclk
5=osclk
6=osclk
7=oscclk

Downstream clock implementation lists these oscclk 5-7 as well, so I
guess we should add them...sigh

> (I didn't check the other parents, but you mentioned you updated field widths
> in other registers, too, so maybe need to double check the parent strings as well)

Yes I will go through and re-check these parent names again.

Peter


From alexghiti at rivosinc.com  Fri Dec  8 06:28:06 2023
From: alexghiti at rivosinc.com (Alexandre Ghiti)
Date: Fri, 8 Dec 2023 15:28:06 +0100
Subject: [PATCH RFC/RFT 1/4] riscv: Stop emitting preventive sfence.vma
 for new vmalloc mappings
In-Reply-To: <27d8dffc-cfd8-4f07-9c0a-b7101963c2ae@csgroup.eu>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
 <20231207150348.82096-2-alexghiti@rivosinc.com> <27d8dffc-cfd8-4f07-9c0a-b7101963c2ae@csgroup.eu>
Message-ID: <CAHVXubjtb-bq1o=jxAavMc5h9T-a_Z0=xxkPgerycQEDdhLd3Q@mail.gmail.com>

Hi Christophe,

On Thu, Dec 7, 2023 at 4:52?PM Christophe Leroy
<christophe.leroy at csgroup.eu> wrote:
>
>
>
> Le 07/12/2023 ? 16:03, Alexandre Ghiti a ?crit :
> > In 6.5, we removed the vmalloc fault path because that can't work (see
> > [1] [2]). Then in order to make sure that new page table entries were
> > seen by the page table walker, we had to preventively emit a sfence.vma
> > on all harts [3] but this solution is very costly since it relies on IPI.
> >
> > And even there, we could end up in a loop of vmalloc faults if a vmalloc
> > allocation is done in the IPI path (for example if it is traced, see
> > [4]), which could result in a kernel stack overflow.
> >
> > Those preventive sfence.vma needed to be emitted because:
> >
> > - if the uarch caches invalid entries, the new mapping may not be
> >    observed by the page table walker and an invalidation may be needed.
> > - if the uarch does not cache invalid entries, a reordered access
> >    could "miss" the new mapping and traps: in that case, we would actually
> >    only need to retry the access, no sfence.vma is required.
> >
> > So this patch removes those preventive sfence.vma and actually handles
> > the possible (and unlikely) exceptions. And since the kernel stacks
> > mappings lie in the vmalloc area, this handling must be done very early
> > when the trap is taken, at the very beginning of handle_exception: this
> > also rules out the vmalloc allocations in the fault path.
> >
> > Note that for now, we emit a sfence.vma even for uarchs that do not
> > cache invalid entries as we have no means to know that: that will be
> > fixed in the next patch.
> >
> > Link: https://lore.kernel.org/linux-riscv/20230531093817.665799-1-bjorn at kernel.org/ [1]
> > Link: https://lore.kernel.org/linux-riscv/20230801090927.2018653-1-dylan at andestech.com [2]
> > Link: https://lore.kernel.org/linux-riscv/20230725132246.817726-1-alexghiti at rivosinc.com/ [3]
> > Link: https://lore.kernel.org/lkml/20200508144043.13893-1-joro at 8bytes.org/ [4]
> > Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
> > ---
> >   arch/riscv/include/asm/cacheflush.h  | 19 +++++-
> >   arch/riscv/include/asm/thread_info.h |  5 ++
> >   arch/riscv/kernel/asm-offsets.c      |  5 ++
> >   arch/riscv/kernel/entry.S            | 94 ++++++++++++++++++++++++++++
> >   arch/riscv/mm/init.c                 |  2 +
> >   5 files changed, 124 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h
> > index 3cb53c4df27c..a916cbc69d47 100644
> > --- a/arch/riscv/include/asm/cacheflush.h
> > +++ b/arch/riscv/include/asm/cacheflush.h
> > @@ -37,7 +37,24 @@ static inline void flush_dcache_page(struct page *page)
> >       flush_icache_mm(vma->vm_mm, 0)
> >
> >   #ifdef CONFIG_64BIT
> > -#define flush_cache_vmap(start, end) flush_tlb_kernel_range(start, end)
> > +extern u64 new_vmalloc[];
>
> Can you have the table size here ? Would help GCC static analysis for
> boundary checking.

Yes, I'll do

>
> > +extern char _end[];
> > +#define flush_cache_vmap flush_cache_vmap
> > +static inline void flush_cache_vmap(unsigned long start, unsigned long end)
> > +{
> > +     if ((start < VMALLOC_END && end > VMALLOC_START) ||
> > +         (start < MODULES_END && end > MODULES_VADDR)) {
>
> Can you use is_vmalloc_or_module_addr() instead ?

Yes, I'll do

>
>
> > +             int i;
> > +
> > +             /*
> > +              * We don't care if concurrently a cpu resets this value since
> > +              * the only place this can happen is in handle_exception() where
> > +              * an sfence.vma is emitted.
> > +              */
> > +             for (i = 0; i < NR_CPUS / sizeof(u64) + 1; ++i)
>
> Use ARRAY_SIZE() ?

And that too :)

Thanks for the review,

Alex

>
> > +                     new_vmalloc[i] = -1ULL;
> > +     }
> > +}
> >   #endif
> >
> >   #ifndef CONFIG_SMP
> > diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h
> > index 1833beb00489..8fe12fa6c329 100644
> > --- a/arch/riscv/include/asm/thread_info.h
> > +++ b/arch/riscv/include/asm/thread_info.h
> > @@ -60,6 +60,11 @@ struct thread_info {
> >       long                    user_sp;        /* User stack pointer */
> >       int                     cpu;
> >       unsigned long           syscall_work;   /* SYSCALL_WORK_ flags */
> > +     /*
> > +      * Used in handle_exception() to save a0, a1 and a2 before knowing if we
> > +      * can access the kernel stack.
> > +      */
> > +     unsigned long           a0, a1, a2;
> >   };
> >
> >   /*
> > diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
> > index d6a75aac1d27..340c1c84560d 100644
> > --- a/arch/riscv/kernel/asm-offsets.c
> > +++ b/arch/riscv/kernel/asm-offsets.c
> > @@ -34,10 +34,15 @@ void asm_offsets(void)
> >       OFFSET(TASK_THREAD_S9, task_struct, thread.s[9]);
> >       OFFSET(TASK_THREAD_S10, task_struct, thread.s[10]);
> >       OFFSET(TASK_THREAD_S11, task_struct, thread.s[11]);
> > +
> > +     OFFSET(TASK_TI_CPU, task_struct, thread_info.cpu);
> >       OFFSET(TASK_TI_FLAGS, task_struct, thread_info.flags);
> >       OFFSET(TASK_TI_PREEMPT_COUNT, task_struct, thread_info.preempt_count);
> >       OFFSET(TASK_TI_KERNEL_SP, task_struct, thread_info.kernel_sp);
> >       OFFSET(TASK_TI_USER_SP, task_struct, thread_info.user_sp);
> > +     OFFSET(TASK_TI_A0, task_struct, thread_info.a0);
> > +     OFFSET(TASK_TI_A1, task_struct, thread_info.a1);
> > +     OFFSET(TASK_TI_A2, task_struct, thread_info.a2);
> >
> >       OFFSET(TASK_THREAD_F0,  task_struct, thread.fstate.f[0]);
> >       OFFSET(TASK_THREAD_F1,  task_struct, thread.fstate.f[1]);
> > diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
> > index 143a2bb3e697..3a3c7b563816 100644
> > --- a/arch/riscv/kernel/entry.S
> > +++ b/arch/riscv/kernel/entry.S
> > @@ -14,6 +14,88 @@
> >   #include <asm/asm-offsets.h>
> >   #include <asm/errata_list.h>
> >
> > +.macro new_vmalloc_check
> > +     REG_S   a0, TASK_TI_A0(tp)
> > +     REG_S   a1, TASK_TI_A1(tp)
> > +     REG_S   a2, TASK_TI_A2(tp)
> > +
> > +     csrr    a0, CSR_CAUSE
> > +     /* Exclude IRQs */
> > +     blt     a0, zero, _new_vmalloc_restore_context
> > +     /* Only check new_vmalloc if we are in page/protection fault */
> > +     li      a1, EXC_LOAD_PAGE_FAULT
> > +     beq     a0, a1, _new_vmalloc_kernel_address
> > +     li      a1, EXC_STORE_PAGE_FAULT
> > +     beq     a0, a1, _new_vmalloc_kernel_address
> > +     li      a1, EXC_INST_PAGE_FAULT
> > +     bne     a0, a1, _new_vmalloc_restore_context
> > +
> > +_new_vmalloc_kernel_address:
> > +     /* Is it a kernel address? */
> > +     csrr    a0, CSR_TVAL
> > +     bge     a0, zero, _new_vmalloc_restore_context
> > +
> > +     /* Check if a new vmalloc mapping appeared that could explain the trap */
> > +
> > +     /*
> > +      * Computes:
> > +      * a0 = &new_vmalloc[BIT_WORD(cpu)]
> > +      * a1 = BIT_MASK(cpu)
> > +      */
> > +     REG_L   a2, TASK_TI_CPU(tp)
> > +     /*
> > +      * Compute the new_vmalloc element position:
> > +      * (cpu / 64) * 8 = (cpu >> 6) << 3
> > +      */
> > +     srli    a1, a2, 6
> > +     slli    a1, a1, 3
> > +     la      a0, new_vmalloc
> > +     add     a0, a0, a1
> > +     /*
> > +      * Compute the bit position in the new_vmalloc element:
> > +      * bit_pos = cpu % 64 = cpu - (cpu / 64) * 64 = cpu - (cpu >> 6) << 6
> > +      *         = cpu - ((cpu >> 6) << 3) << 3
> > +      */
> > +     slli    a1, a1, 3
> > +     sub     a1, a2, a1
> > +     /* Compute the "get mask": 1 << bit_pos */
> > +     li      a2, 1
> > +     sll     a1, a2, a1
> > +
> > +     /* Check the value of new_vmalloc for this cpu */
> > +     ld      a2, 0(a0)
> > +     and     a2, a2, a1
> > +     beq     a2, zero, _new_vmalloc_restore_context
> > +
> > +     ld      a2, 0(a0)
> > +     not     a1, a1
> > +     and     a1, a2, a1
> > +     sd      a1, 0(a0)
> > +
> > +     /* Only emit a sfence.vma if the uarch caches invalid entries */
> > +     la      a0, tlb_caching_invalid_entries
> > +     lb      a0, 0(a0)
> > +     beqz    a0, _new_vmalloc_no_caching_invalid_entries
> > +     sfence.vma
> > +_new_vmalloc_no_caching_invalid_entries:
> > +     // debug
> > +     la      a0, nr_sfence_vma_handle_exception
> > +     li      a1, 1
> > +     amoadd.w    a0, a1, (a0)
> > +     // end debug
> > +     REG_L   a0, TASK_TI_A0(tp)
> > +     REG_L   a1, TASK_TI_A1(tp)
> > +     REG_L   a2, TASK_TI_A2(tp)
> > +     csrw    CSR_SCRATCH, x0
> > +     sret
> > +
> > +_new_vmalloc_restore_context:
> > +     REG_L   a0, TASK_TI_A0(tp)
> > +     REG_L   a1, TASK_TI_A1(tp)
> > +     REG_L   a2, TASK_TI_A2(tp)
> > +.endm
> > +
> > +
> >   SYM_CODE_START(handle_exception)
> >       /*
> >        * If coming from userspace, preserve the user thread pointer and load
> > @@ -25,6 +107,18 @@ SYM_CODE_START(handle_exception)
> >
> >   _restore_kernel_tpsp:
> >       csrr tp, CSR_SCRATCH
> > +
> > +     /*
> > +      * The RISC-V kernel does not eagerly emit a sfence.vma after each
> > +      * new vmalloc mapping, which may result in exceptions:
> > +      * - if the uarch caches invalid entries, the new mapping would not be
> > +      *   observed by the page table walker and an invalidation is needed.
> > +      * - if the uarch does not cache invalid entries, a reordered access
> > +      *   could "miss" the new mapping and traps: in that case, we only need
> > +      *   to retry the access, no sfence.vma is required.
> > +      */
> > +     new_vmalloc_check
> > +
> >       REG_S sp, TASK_TI_KERNEL_SP(tp)
> >
> >   #ifdef CONFIG_VMAP_STACK
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index 0798bd861dcb..379403de6c6f 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -36,6 +36,8 @@
> >
> >   #include "../kernel/head.h"
> >
> > +u64 new_vmalloc[NR_CPUS / sizeof(u64) + 1];
> > +
> >   struct kernel_mapping kernel_map __ro_after_init;
> >   EXPORT_SYMBOL(kernel_map);
> >   #ifdef CONFIG_XIP_KERNEL


From fancer.lancer at gmail.com  Fri Dec  8 06:28:20 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Fri, 8 Dec 2023 17:28:20 +0300
Subject: [PATCH] net:stmmac:stmmac_platform:Add snps,xpcs devicetree
 parsing
In-Reply-To: <20231208091408.071680db@device.home>
References: <SA0PR12MB44138E48A245378CF54D2F9ED98AA@SA0PR12MB4413.namprd12.prod.outlook.com>
 <20231208091408.071680db@device.home>
Message-ID: <uzss3af2cklc5bx5apszoegafeaaiv7o7iwgrgrml4grkyev6p@6tme4hdb4mkn>

Hi Maxime, Jiangfeng

On Fri, Dec 08, 2023 at 09:14:08AM +0100, Maxime Chevallier wrote:
> Hello,
> 
> On Fri, 8 Dec 2023 07:02:19 +0000
> Jiangfeng Ma <Jiangfeng.Ma at synopsys.com> wrote:
> 
> > In order to setup xpcs, has_xpcs must be set to a non-zero value.
> > Add new optional devicetree properties representing this.
> > 
> > If has_xpcs is set to true, then xpcs_an_inband should preferably be
> > consistent with it, Otherwise, some errors may occur when starting
> > the network, For example, the phy interface that xpcs already supports,
> > but link up fails.
> 
> Can you elaborate on why you need this, and on which platform
> especially ? Usually drivers for the various stmmac variants know if
> they have XPCS or not, or can guess it based on some info such as the
> configured PHY mode (dwmac-intel).
> 
> Besides that, there are a few issues with your submission. If DT is the
> way to go (and I don't say it is), you would also need to update the
> bindings to document that property.
> 
> > The types of has_xpcs and xpcs_an_inband are unsigned int,
> > and generally used as flags. So it may be more reasonable to set them to
> > bool type. This can also be confirmed from the type of @ovr_an_inband.
> 
> And this part would go into a separate patch.

In addition to what Maxime already said having DT-bindings adjusted to
fit to the pattern implemented in the software part is a wrong way to
go. The best choice in this case is to add the DW XPCS DT-node to the
DW MAC MDIO/MI bus and then use the "pcs-handle" to inform the MAC
(mainly it's driver) of what PCS-device is actually attached to it.
The series I submitted on this week is exactly about that:
https://lore.kernel.org/netdev/20231205103559.9605-1-fancer.lancer at gmail.com/
I guess I'll need about a month or so to settle all the comments, but
the solution implemented there will be better than this one really.

-Serge(y)

> 
> Thanks,
> 
> Maxime
> 


From alexghiti at rivosinc.com  Fri Dec  8 06:30:16 2023
From: alexghiti at rivosinc.com (Alexandre Ghiti)
Date: Fri, 8 Dec 2023 15:30:16 +0100
Subject: [PATCH RFC/RFT 2/4] riscv: Add a runtime detection of invalid TLB
 entries caching
In-Reply-To: <6e3fb7b0-f47d-4d2f-b1b8-3ecc047b9ebf@csgroup.eu>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
 <20231207150348.82096-3-alexghiti@rivosinc.com> <6e3fb7b0-f47d-4d2f-b1b8-3ecc047b9ebf@csgroup.eu>
Message-ID: <CAHVXubg3rX_HOq=v4GCOVmDGVB3AA8kWWUsZTcZu6Y+Y2XmYQw@mail.gmail.com>

On Thu, Dec 7, 2023 at 4:55?PM Christophe Leroy
<christophe.leroy at csgroup.eu> wrote:
>
>
>
> Le 07/12/2023 ? 16:03, Alexandre Ghiti a ?crit :
> > This mechanism allows to completely bypass the sfence.vma introduced by
> > the previous commit for uarchs that do not cache invalid TLB entries.
> >
> > Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
> > ---
> >   arch/riscv/mm/init.c | 124 +++++++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 124 insertions(+)
> >
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index 379403de6c6f..2e854613740c 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -56,6 +56,8 @@ bool pgtable_l5_enabled = IS_ENABLED(CONFIG_64BIT) && !IS_ENABLED(CONFIG_XIP_KER
> >   EXPORT_SYMBOL(pgtable_l4_enabled);
> >   EXPORT_SYMBOL(pgtable_l5_enabled);
> >
> > +bool tlb_caching_invalid_entries;
> > +
> >   phys_addr_t phys_ram_base __ro_after_init;
> >   EXPORT_SYMBOL(phys_ram_base);
> >
> > @@ -750,6 +752,18 @@ static void __init disable_pgtable_l4(void)
> >       satp_mode = SATP_MODE_39;
> >   }
> >
> > +static void __init enable_pgtable_l5(void)
> > +{
> > +     pgtable_l5_enabled = true;
> > +     satp_mode = SATP_MODE_57;
> > +}
> > +
> > +static void __init enable_pgtable_l4(void)
> > +{
> > +     pgtable_l4_enabled = true;
> > +     satp_mode = SATP_MODE_48;
> > +}
> > +
> >   static int __init print_no4lvl(char *p)
> >   {
> >       pr_info("Disabled 4-level and 5-level paging");
> > @@ -826,6 +840,112 @@ static __init void set_satp_mode(uintptr_t dtb_pa)
> >       memset(early_pud, 0, PAGE_SIZE);
> >       memset(early_pmd, 0, PAGE_SIZE);
> >   }
> > +
> > +/* Determine at runtime if the uarch caches invalid TLB entries */
> > +static __init void set_tlb_caching_invalid_entries(void)
> > +{
> > +#define NR_RETRIES_CACHING_INVALID_ENTRIES   50
>
> Looks odd to have macros nested in the middle of a function.
>
> > +     uintptr_t set_tlb_caching_invalid_entries_pmd = ((unsigned long)set_tlb_caching_invalid_entries) & PMD_MASK;
> > +     // TODO the test_addr as defined below could go into another pud...
> > +     uintptr_t test_addr = set_tlb_caching_invalid_entries_pmd + 2 * PMD_SIZE;
> > +     pmd_t valid_pmd;
> > +     u64 satp;
> > +     int i = 0;
> > +
> > +     /* To ease the page table creation */
> > +     disable_pgtable_l5();
> > +     disable_pgtable_l4();
> > +
> > +     /* Establish a mapping for set_tlb_caching_invalid_entries() in sv39 */
> > +     create_pgd_mapping(early_pg_dir,
> > +                        set_tlb_caching_invalid_entries_pmd,
> > +                        (uintptr_t)early_pmd,
> > +                        PGDIR_SIZE, PAGE_TABLE);
> > +
> > +     /* Handle the case where set_tlb_caching_invalid_entries straddles 2 PMDs */
> > +     create_pmd_mapping(early_pmd,
> > +                        set_tlb_caching_invalid_entries_pmd,
> > +                        set_tlb_caching_invalid_entries_pmd,
> > +                        PMD_SIZE, PAGE_KERNEL_EXEC);
> > +     create_pmd_mapping(early_pmd,
> > +                        set_tlb_caching_invalid_entries_pmd + PMD_SIZE,
> > +                        set_tlb_caching_invalid_entries_pmd + PMD_SIZE,
> > +                        PMD_SIZE, PAGE_KERNEL_EXEC);
> > +
> > +     /* Establish an invalid mapping */
> > +     create_pmd_mapping(early_pmd, test_addr, 0, PMD_SIZE, __pgprot(0));
> > +
> > +     /* Precompute the valid pmd here because the mapping for pfn_pmd() won't exist */
> > +     valid_pmd = pfn_pmd(PFN_DOWN(set_tlb_caching_invalid_entries_pmd), PAGE_KERNEL);
> > +
> > +     local_flush_tlb_all();
> > +     satp = PFN_DOWN((uintptr_t)&early_pg_dir) | SATP_MODE_39;
> > +     csr_write(CSR_SATP, satp);
> > +
> > +     /*
> > +      * Set stvec to after the trapping access, access this invalid mapping
> > +      * and legitimately trap
> > +      */
> > +     // TODO: Should I save the previous stvec?
> > +#define ASM_STR(x)   __ASM_STR(x)
>
> Looks odd to have macros nested in the middle of a function.
>
>
> > +     asm volatile(
> > +             "la a0, 1f                              \n"
> > +             "csrw " ASM_STR(CSR_TVEC) ", a0         \n"
> > +             "ld a0, 0(%0)                           \n"
> > +             ".align 2                               \n"
> > +             "1:                                     \n"
> > +             :
> > +             : "r" (test_addr)
> > +             : "a0"
> > +     );
> > +
> > +     /* Now establish a valid mapping to check if the invalid one is cached */
> > +     early_pmd[pmd_index(test_addr)] = valid_pmd;
> > +
> > +     /*
> > +      * Access the valid mapping multiple times: indeed, we can't use
> > +      * sfence.vma as a barrier to make sure the cpu did not reorder accesses
> > +      * so we may trap even if the uarch does not cache invalid entries. By
> > +      * trying a few times, we make sure that those uarchs will see the right
> > +      * mapping at some point.
> > +      */
> > +
> > +     i = NR_RETRIES_CACHING_INVALID_ENTRIES;
> > +
> > +#define ASM_STR(x)   __ASM_STR(x)
>
> Deplicate define ?
>
> > +     asm_volatile_goto(
> > +             "la a0, 1f                                      \n"
> > +             "csrw " ASM_STR(CSR_TVEC) ", a0                 \n"
> > +             ".align 2                                       \n"
> > +             "1:                                             \n"
> > +             "addi %0, %0, -1                                \n"
> > +             "blt %0, zero, %l[caching_invalid_entries]      \n"
> > +             "ld a0, 0(%1)                                   \n"
> > +             :
> > +             : "r" (i), "r" (test_addr)
> > +             : "a0"
> > +             : caching_invalid_entries
> > +     );
> > +
> > +     csr_write(CSR_SATP, 0ULL);
> > +     local_flush_tlb_all();
> > +
> > +     /* If we don't trap, the uarch does not cache invalid entries! */
> > +     tlb_caching_invalid_entries = false;
> > +     goto clean;
> > +
> > +caching_invalid_entries:
> > +     csr_write(CSR_SATP, 0ULL);
> > +     local_flush_tlb_all();
> > +
> > +     tlb_caching_invalid_entries = true;
> > +clean:
> > +     memset(early_pg_dir, 0, PAGE_SIZE);
> > +     memset(early_pmd, 0, PAGE_SIZE);
>
> Use clear_page() instead ?
>
> > +
> > +     enable_pgtable_l4();
> > +     enable_pgtable_l5();
> > +}
> >   #endif
> >
> >   /*
> > @@ -1072,6 +1192,7 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
> >   #endif
> >
> >   #if defined(CONFIG_64BIT) && !defined(CONFIG_XIP_KERNEL)
> > +     set_tlb_caching_invalid_entries();
> >       set_satp_mode(dtb_pa);
> >   #endif
> >
> > @@ -1322,6 +1443,9 @@ static void __init setup_vm_final(void)
> >       local_flush_tlb_all();
> >
> >       pt_ops_set_late();
> > +
> > +     pr_info("uarch caches invalid entries: %s",
> > +             tlb_caching_invalid_entries ? "yes" : "no");
> >   }
> >   #else
> >   asmlinkage void __init setup_vm(uintptr_t dtb_pa)

I left this patch so that people can easily test this without knowing
what their uarch is actually doing, but it will very likely be dropped
as a new extension has just been proposed for that.

Thanks anyway, I should have been more clear in the patch title,

Alex


From gabriel.fernandez at foss.st.com  Fri Dec  8 06:36:56 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Fri, 8 Dec 2023 15:36:56 +0100
Subject: [PATCH v6 1/5] clk: stm32mp1: move stm32mp1 clock driver into stm32 directory
In-Reply-To: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
References: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231208143700.354785-2-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Move all STM32MP clock drivers into same directory (stm32).

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/Kconfig                    | 11 +---------
 drivers/clk/Makefile                   |  1 -
 drivers/clk/stm32/Kconfig              | 29 ++++++++++++++++++++++++++
 drivers/clk/stm32/Makefile             |  1 +
 drivers/clk/{ => stm32}/clk-stm32mp1.c |  0
 5 files changed, 31 insertions(+), 11 deletions(-)
 create mode 100644 drivers/clk/stm32/Kconfig
 rename drivers/clk/{ => stm32}/clk-stm32mp1.c (100%)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c30d0d396f7a..50af5fc7f570 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -414,16 +414,6 @@ config COMMON_CLK_VC7
 	  Renesas Versaclock7 is a family of configurable clock generator
 	  and jitter attenuator ICs with fractional and integer dividers.
 
-config COMMON_CLK_STM32MP135
-	def_bool COMMON_CLK && MACH_STM32MP13
-	help
-	  Support for stm32mp135 SoC family clocks
-
-config COMMON_CLK_STM32MP157
-	def_bool COMMON_CLK && MACH_STM32MP157
-	help
-	  Support for stm32mp157 SoC family clocks
-
 config COMMON_CLK_STM32F
 	def_bool COMMON_CLK && (MACH_STM32F429 || MACH_STM32F469 || MACH_STM32F746)
 	help
@@ -504,6 +494,7 @@ source "drivers/clk/starfive/Kconfig"
 source "drivers/clk/sunxi/Kconfig"
 source "drivers/clk/sunxi-ng/Kconfig"
 source "drivers/clk/tegra/Kconfig"
+source "drivers/clk/stm32/Kconfig"
 source "drivers/clk/ti/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
 source "drivers/clk/visconti/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ed71f2e0ee36..14fa8d4ecc1f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -70,7 +70,6 @@ obj-$(CONFIG_COMMON_CLK_SI570)		+= clk-si570.o
 obj-$(CONFIG_COMMON_CLK_SP7021)		+= clk-sp7021.o
 obj-$(CONFIG_COMMON_CLK_STM32F)		+= clk-stm32f4.o
 obj-$(CONFIG_COMMON_CLK_STM32H7)	+= clk-stm32h7.o
-obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o
 obj-$(CONFIG_COMMON_CLK_TPS68470)      += clk-tps68470.o
 obj-$(CONFIG_CLK_TWL6040)		+= clk-twl6040.o
 obj-$(CONFIG_CLK_TWL)			+= clk-twl.o
diff --git a/drivers/clk/stm32/Kconfig b/drivers/clk/stm32/Kconfig
new file mode 100644
index 000000000000..3c8493a94a11
--- /dev/null
+++ b/drivers/clk/stm32/Kconfig
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# common clock support for STMicroelectronics SoC family.
+
+menuconfig COMMON_CLK_STM32MP
+	bool "Clock support for common STM32MP clocks"
+	depends on ARCH_STM32 || COMPILE_TEST
+	default y
+	select RESET_CONTROLLER
+	help
+	  Support for STM32MP SoC family clocks.
+
+if COMMON_CLK_STM32MP
+
+config COMMON_CLK_STM32MP135
+	bool "Clock driver for stm32mp13x clocks"
+	depends on ARM || COMPILE_TEST
+	default y
+	help
+	  Support for stm32mp13x SoC family clocks.
+
+config COMMON_CLK_STM32MP157
+	bool "Clock driver for stm32mp15x clocks"
+	depends on ARM || COMPILE_TEST
+	default y
+	help
+	  Support for stm32mp15x SoC family clocks.
+
+endif
+
diff --git a/drivers/clk/stm32/Makefile b/drivers/clk/stm32/Makefile
index 95bd2230bba0..c154ef3e88f9 100644
--- a/drivers/clk/stm32/Makefile
+++ b/drivers/clk/stm32/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_COMMON_CLK_STM32MP135)	+= clk-stm32mp13.o clk-stm32-core.o reset-stm32.o
+obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o
diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/stm32/clk-stm32mp1.c
similarity index 100%
rename from drivers/clk/clk-stm32mp1.c
rename to drivers/clk/stm32/clk-stm32mp1.c
-- 
2.25.1



From gabriel.fernandez at foss.st.com  Fri Dec  8 06:36:58 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Fri, 8 Dec 2023 15:36:58 +0100
Subject: [PATCH v6 3/5] dt-bindings: stm32: add clocks and reset binding for stm32mp25 platform
In-Reply-To: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
References: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231208143700.354785-4-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Adds clock and reset binding entries for STM32MP25 SoC family

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/clock/st,stm32mp25-rcc.yaml      |  76 +++
 include/dt-bindings/clock/st,stm32mp25-rcc.h  | 492 ++++++++++++++++++
 include/dt-bindings/reset/st,stm32mp25-rcc.h  | 167 ++++++
 3 files changed, 735 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
 create mode 100644 include/dt-bindings/clock/st,stm32mp25-rcc.h
 create mode 100644 include/dt-bindings/reset/st,stm32mp25-rcc.h

diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
new file mode 100644
index 000000000000..7732e79a42b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/st,stm32mp25-rcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32MP25 Reset Clock Controller
+
+maintainers:
+  - Gabriel Fernandez <gabriel.fernandez at foss.st.com>
+
+description: |
+  The RCC hardware block is both a reset and a clock controller.
+  RCC makes also power management (resume/supend).
+
+  See also::
+    include/dt-bindings/clock/st,stm32mp25-rcc.h
+    include/dt-bindings/reset/st,stm32mp25-rcc.h
+
+properties:
+  compatible:
+    enum:
+      - st,stm32mp25-rcc
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+  '#reset-cells':
+    const: 1
+
+  clocks:
+    items:
+      - description: CK_SCMI_HSE High Speed External oscillator (8 to 48 MHz)
+      - description: CK_SCMI_HSI High Speed Internal oscillator (~ 64 MHz)
+      - description: CK_SCMI_MSI Low Power Internal oscillator (~ 4 MHz or ~ 16 MHz)
+      - description: CK_SCMI_LSE Low Speed External oscillator (32 KHz)
+      - description: CK_SCMI_LSI Low Speed Internal oscillator (~ 32 KHz)
+
+  clock-names:
+    items:
+      - const: hse
+      - const: hsi
+      - const: msi
+      - const: lse
+      - const: lsi
+
+required:
+  - compatible
+  - reg
+  - '#clock-cells'
+  - '#reset-cells'
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+
+    rcc: clock-controller at 44200000 {
+        compatible = "st,stm32mp25-rcc";
+        reg = <0x44200000 0x10000>;
+        #clock-cells = <1>;
+        #reset-cells = <1>;
+        clock-names = "hse", "hsi", "msi", "lse", "lsi";
+        clocks = <&scmi_clk CK_SCMI_HSE>,
+                 <&scmi_clk CK_SCMI_HSI>,
+                 <&scmi_clk CK_SCMI_MSI>,
+                 <&scmi_clk CK_SCMI_LSE>,
+                 <&scmi_clk CK_SCMI_LSI>;
+    };
+...
diff --git a/include/dt-bindings/clock/st,stm32mp25-rcc.h b/include/dt-bindings/clock/st,stm32mp25-rcc.h
new file mode 100644
index 000000000000..b6cf05ad4be6
--- /dev/null
+++ b/include/dt-bindings/clock/st,stm32mp25-rcc.h
@@ -0,0 +1,492 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
+/*
+ * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
+ * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
+ */
+
+#ifndef _DT_BINDINGS_STM32MP25_CLKS_H_
+#define _DT_BINDINGS_STM32MP25_CLKS_H_
+
+/* INTERNAL/EXTERNAL OSCILLATORS */
+#define HSI_CK			0
+#define HSE_CK			1
+#define MSI_CK			2
+#define LSI_CK			3
+#define LSE_CK			4
+#define I2S_CK			5
+#define RTC_CK			6
+#define SPDIF_CK_SYMB		7
+
+/* PLL CLOCKS */
+#define PLL1_CK			8
+#define PLL2_CK			9
+#define PLL3_CK			10
+#define PLL4_CK			11
+#define PLL5_CK			12
+#define PLL6_CK			13
+#define PLL7_CK			14
+#define PLL8_CK			15
+
+#define CK_CPU1			16
+
+/* APB DIV CLOCKS */
+#define CK_ICN_APB1		17
+#define CK_ICN_APB2		18
+#define CK_ICN_APB3		19
+#define CK_ICN_APB4		20
+#define CK_ICN_APBDBG		21
+
+/* GLOBAL TIMER */
+#define TIMG1_CK		22
+#define TIMG2_CK		23
+
+/* FLEXGEN CLOCKS */
+#define CK_ICN_HS_MCU		24
+#define CK_ICN_SDMMC		25
+#define CK_ICN_DDR		26
+#define CK_ICN_DISPLAY		27
+#define CK_ICN_HSL		28
+#define CK_ICN_NIC		29
+#define CK_ICN_VID		30
+#define CK_FLEXGEN_07		31
+#define CK_FLEXGEN_08		32
+#define CK_FLEXGEN_09		33
+#define CK_FLEXGEN_10		34
+#define CK_FLEXGEN_11		35
+#define CK_FLEXGEN_12		36
+#define CK_FLEXGEN_13		37
+#define CK_FLEXGEN_14		38
+#define CK_FLEXGEN_15		39
+#define CK_FLEXGEN_16		40
+#define CK_FLEXGEN_17		41
+#define CK_FLEXGEN_18		42
+#define CK_FLEXGEN_19		43
+#define CK_FLEXGEN_20		44
+#define CK_FLEXGEN_21		45
+#define CK_FLEXGEN_22		46
+#define CK_FLEXGEN_23		47
+#define CK_FLEXGEN_24		48
+#define CK_FLEXGEN_25		49
+#define CK_FLEXGEN_26		50
+#define CK_FLEXGEN_27		51
+#define CK_FLEXGEN_28		52
+#define CK_FLEXGEN_29		53
+#define CK_FLEXGEN_30		54
+#define CK_FLEXGEN_31		55
+#define CK_FLEXGEN_32		56
+#define CK_FLEXGEN_33		57
+#define CK_FLEXGEN_34		58
+#define CK_FLEXGEN_35		59
+#define CK_FLEXGEN_36		60
+#define CK_FLEXGEN_37		61
+#define CK_FLEXGEN_38		62
+#define CK_FLEXGEN_39		63
+#define CK_FLEXGEN_40		64
+#define CK_FLEXGEN_41		65
+#define CK_FLEXGEN_42		66
+#define CK_FLEXGEN_43		67
+#define CK_FLEXGEN_44		68
+#define CK_FLEXGEN_45		69
+#define CK_FLEXGEN_46		70
+#define CK_FLEXGEN_47		71
+#define CK_FLEXGEN_48		72
+#define CK_FLEXGEN_49		73
+#define CK_FLEXGEN_50		74
+#define CK_FLEXGEN_51		75
+#define CK_FLEXGEN_52		76
+#define CK_FLEXGEN_53		77
+#define CK_FLEXGEN_54		78
+#define CK_FLEXGEN_55		79
+#define CK_FLEXGEN_56		80
+#define CK_FLEXGEN_57		81
+#define CK_FLEXGEN_58		82
+#define CK_FLEXGEN_59		83
+#define CK_FLEXGEN_60		84
+#define CK_FLEXGEN_61		85
+#define CK_FLEXGEN_62		86
+#define CK_FLEXGEN_63		87
+
+/* LOW SPEED MCU CLOCK */
+#define CK_ICN_LS_MCU		88
+
+#define CK_BUS_STM500		89
+#define CK_BUS_FMC		90
+#define CK_BUS_GPU		91
+#define CK_BUS_ETH1		92
+#define CK_BUS_ETH2		93
+#define CK_BUS_PCIE		94
+#define CK_BUS_DDRPHYC		95
+#define CK_BUS_SYSCPU1		96
+#define CK_BUS_ETHSW		97
+#define CK_BUS_HPDMA1		98
+#define CK_BUS_HPDMA2		99
+#define CK_BUS_HPDMA3		100
+#define CK_BUS_ADC12		101
+#define CK_BUS_ADC3		102
+#define CK_BUS_IPCC1		103
+#define CK_BUS_CCI		104
+#define CK_BUS_CRC		105
+#define CK_BUS_MDF1		106
+#define CK_BUS_OSPIIOM		107
+#define CK_BUS_BKPSRAM		108
+#define CK_BUS_HASH		109
+#define CK_BUS_RNG		110
+#define CK_BUS_CRYP1		111
+#define CK_BUS_CRYP2		112
+#define CK_BUS_SAES		113
+#define CK_BUS_PKA		114
+#define CK_BUS_GPIOA		115
+#define CK_BUS_GPIOB		116
+#define CK_BUS_GPIOC		117
+#define CK_BUS_GPIOD		118
+#define CK_BUS_GPIOE		119
+#define CK_BUS_GPIOF		120
+#define CK_BUS_GPIOG		121
+#define CK_BUS_GPIOH		122
+#define CK_BUS_GPIOI		123
+#define CK_BUS_GPIOJ		124
+#define CK_BUS_GPIOK		125
+#define CK_BUS_LPSRAM1		126
+#define CK_BUS_LPSRAM2		127
+#define CK_BUS_LPSRAM3		128
+#define CK_BUS_GPIOZ		129
+#define CK_BUS_LPDMA		130
+#define CK_BUS_HSEM		131
+#define CK_BUS_IPCC2		132
+#define CK_BUS_RTC		133
+#define CK_BUS_SPI8		134
+#define CK_BUS_LPUART1		135
+#define CK_BUS_I2C8		136
+#define CK_BUS_LPTIM3		137
+#define CK_BUS_LPTIM4		138
+#define CK_BUS_LPTIM5		139
+#define CK_BUS_IWDG5		140
+#define CK_BUS_WWDG2		141
+#define CK_BUS_I3C4		142
+#define CK_BUS_TIM2		143
+#define CK_BUS_TIM3		144
+#define CK_BUS_TIM4		145
+#define CK_BUS_TIM5		146
+#define CK_BUS_TIM6		147
+#define CK_BUS_TIM7		148
+#define CK_BUS_TIM10		149
+#define CK_BUS_TIM11		150
+#define CK_BUS_TIM12		151
+#define CK_BUS_TIM13		152
+#define CK_BUS_TIM14		153
+#define CK_BUS_LPTIM1		154
+#define CK_BUS_LPTIM2		155
+#define CK_BUS_SPI2		156
+#define CK_BUS_SPI3		157
+#define CK_BUS_SPDIFRX		158
+#define CK_BUS_USART2		159
+#define CK_BUS_USART3		160
+#define CK_BUS_UART4		161
+#define CK_BUS_UART5		162
+#define CK_BUS_I2C1		163
+#define CK_BUS_I2C2		164
+#define CK_BUS_I2C3		165
+#define CK_BUS_I2C4		166
+#define CK_BUS_I2C5		167
+#define CK_BUS_I2C6		168
+#define CK_BUS_I2C7		169
+#define CK_BUS_I3C1		170
+#define CK_BUS_I3C2		171
+#define CK_BUS_I3C3		172
+#define CK_BUS_TIM1		173
+#define CK_BUS_TIM8		174
+#define CK_BUS_TIM15		175
+#define CK_BUS_TIM16		176
+#define CK_BUS_TIM17		177
+#define CK_BUS_TIM20		178
+#define CK_BUS_SAI1		179
+#define CK_BUS_SAI2		180
+#define CK_BUS_SAI3		181
+#define CK_BUS_SAI4		182
+#define CK_BUS_USART1		183
+#define CK_BUS_USART6		184
+#define CK_BUS_UART7		185
+#define CK_BUS_UART8		186
+#define CK_BUS_UART9		187
+#define CK_BUS_FDCAN		188
+#define CK_BUS_SPI1		189
+#define CK_BUS_SPI4		190
+#define CK_BUS_SPI5		191
+#define CK_BUS_SPI6		192
+#define CK_BUS_SPI7		193
+#define CK_BUS_BSEC		194
+#define CK_BUS_IWDG1		195
+#define CK_BUS_IWDG2		196
+#define CK_BUS_IWDG3		197
+#define CK_BUS_IWDG4		198
+#define CK_BUS_WWDG1		199
+#define CK_BUS_VREF		200
+#define CK_BUS_DTS		201
+#define CK_BUS_SERC		202
+#define CK_BUS_HDP		203
+#define CK_BUS_IS2M		204
+#define CK_BUS_DSI		205
+#define CK_BUS_LTDC		206
+#define CK_BUS_CSI		207
+#define CK_BUS_DCMIPP		208
+#define CK_BUS_DDRC		209
+#define CK_BUS_DDRCFG		210
+#define CK_BUS_GICV2M		211
+#define CK_BUS_USBTC		212
+#define CK_BUS_USB3PCIEPHY	214
+#define CK_BUS_STGEN		215
+#define CK_BUS_VDEC		216
+#define CK_BUS_VENC		217
+#define CK_SYSDBG		218
+#define CK_KER_TIM2		219
+#define CK_KER_TIM3		220
+#define CK_KER_TIM4		221
+#define CK_KER_TIM5		222
+#define CK_KER_TIM6		223
+#define CK_KER_TIM7		224
+#define CK_KER_TIM10		225
+#define CK_KER_TIM11		226
+#define CK_KER_TIM12		227
+#define CK_KER_TIM13		228
+#define CK_KER_TIM14		229
+#define CK_KER_TIM1		230
+#define CK_KER_TIM8		231
+#define CK_KER_TIM15		232
+#define CK_KER_TIM16		233
+#define CK_KER_TIM17		234
+#define CK_KER_TIM20		235
+#define CK_BUS_SYSRAM		236
+#define CK_BUS_VDERAM		237
+#define CK_BUS_RETRAM		238
+#define CK_BUS_OSPI1		239
+#define CK_BUS_OSPI2		240
+#define CK_BUS_OTFD1		241
+#define CK_BUS_OTFD2		242
+#define CK_BUS_SRAM1		243
+#define CK_BUS_SRAM2		244
+#define CK_BUS_SDMMC1		245
+#define CK_BUS_SDMMC2		246
+#define CK_BUS_SDMMC3		247
+#define CK_BUS_DDR		248
+#define CK_BUS_RISAF4		249
+#define CK_BUS_USB2OHCI		250
+#define CK_BUS_USB2EHCI		251
+#define CK_BUS_USB3DR		252
+#define CK_KER_LPTIM1		253
+#define CK_KER_LPTIM2		254
+#define CK_KER_USART2		255
+#define CK_KER_UART4		256
+#define CK_KER_USART3		257
+#define CK_KER_UART5		258
+#define CK_KER_SPI2		259
+#define CK_KER_SPI3		260
+#define CK_KER_SPDIFRX		261
+#define CK_KER_I2C1		262
+#define CK_KER_I2C2		263
+#define CK_KER_I3C1		264
+#define CK_KER_I3C2		265
+#define CK_KER_I2C3		266
+#define CK_KER_I2C5		267
+#define CK_KER_I3C3		268
+#define CK_KER_I2C4		269
+#define CK_KER_I2C6		270
+#define CK_KER_I2C7		271
+#define CK_KER_SPI1		272
+#define CK_KER_SPI4		273
+#define CK_KER_SPI5		274
+#define CK_KER_SPI6		275
+#define CK_KER_SPI7		276
+#define CK_KER_USART1		277
+#define CK_KER_USART6		278
+#define CK_KER_UART7		279
+#define CK_KER_UART8		280
+#define CK_KER_UART9		281
+#define CK_KER_MDF1		282
+#define CK_KER_SAI1		283
+#define CK_KER_SAI2		284
+#define CK_KER_SAI3		285
+#define CK_KER_SAI4		286
+#define CK_KER_FDCAN		287
+#define CK_KER_DSIBLANE		288
+#define CK_KER_DSIPHY		289
+#define CK_KER_CSI		290
+#define CK_KER_CSITXESC		291
+#define CK_KER_CSIPHY		292
+#define CK_KER_LVDSPHY		293
+#define CK_KER_STGEN		294
+#define CK_KER_USB3PCIEPHY	295
+#define CK_KER_USB2PHY2EN	296
+#define CK_KER_I3C4		297
+#define CK_KER_SPI8		298
+#define CK_KER_I2C8		299
+#define CK_KER_LPUART1		300
+#define CK_KER_LPTIM3		301
+#define CK_KER_LPTIM4		302
+#define CK_KER_LPTIM5		303
+#define CK_KER_TSDBG		304
+#define CK_KER_TPIU		305
+#define CK_BUS_ETR		306
+#define CK_BUS_SYSATB		307
+#define CK_KER_ADC12		308
+#define CK_KER_ADC3		309
+#define CK_KER_OSPI1		310
+#define CK_KER_OSPI2		311
+#define CK_KER_FMC		312
+#define CK_KER_SDMMC1		313
+#define CK_KER_SDMMC2		314
+#define CK_KER_SDMMC3		315
+#define CK_KER_ETH1		316
+#define CK_KER_ETH2		317
+#define CK_KER_ETH1PTP		318
+#define CK_KER_ETH2PTP		319
+#define CK_KER_USB2PHY1		320
+#define CK_KER_USB2PHY2		321
+#define CK_KER_ETHSW		322
+#define CK_KER_ETHSWREF		323
+#define CK_MCO1			324
+#define CK_MCO2			325
+#define CK_KER_DTS		326
+#define CK_ETH1_RX		327
+#define CK_ETH1_TX		328
+#define CK_ETH1_MAC		329
+#define CK_ETH2_RX		330
+#define CK_ETH2_TX		331
+#define CK_ETH2_MAC		332
+#define CK_ETH1_STP		333
+#define CK_ETH2_STP		334
+#define CK_KER_USBTC		335
+#define CK_BUS_ADF1		336
+#define CK_KER_ADF1		337
+#define CK_BUS_LVDS		338
+#define CK_KER_LTDC		339
+#define CK_KER_GPU		340
+#define CK_BUS_ETHSWACMCFG	341
+#define CK_BUS_ETHSWACMMSG	342
+#define HSE_DIV2_CK		343
+
+#define STM32MP25_LAST_CLK	344
+
+#define CK_SCMI_ICN_HS_MCU	0
+#define CK_SCMI_ICN_SDMMC	1
+#define CK_SCMI_ICN_DDR		2
+#define CK_SCMI_ICN_DISPLAY	3
+#define CK_SCMI_ICN_HSL		4
+#define CK_SCMI_ICN_NIC		5
+#define CK_SCMI_ICN_VID		6
+#define CK_SCMI_FLEXGEN_07	7
+#define CK_SCMI_FLEXGEN_08	8
+#define CK_SCMI_FLEXGEN_09	9
+#define CK_SCMI_FLEXGEN_10	10
+#define CK_SCMI_FLEXGEN_11	11
+#define CK_SCMI_FLEXGEN_12	12
+#define CK_SCMI_FLEXGEN_13	13
+#define CK_SCMI_FLEXGEN_14	14
+#define CK_SCMI_FLEXGEN_15	15
+#define CK_SCMI_FLEXGEN_16	16
+#define CK_SCMI_FLEXGEN_17	17
+#define CK_SCMI_FLEXGEN_18	18
+#define CK_SCMI_FLEXGEN_19	19
+#define CK_SCMI_FLEXGEN_20	20
+#define CK_SCMI_FLEXGEN_21	21
+#define CK_SCMI_FLEXGEN_22	22
+#define CK_SCMI_FLEXGEN_23	23
+#define CK_SCMI_FLEXGEN_24	24
+#define CK_SCMI_FLEXGEN_25	25
+#define CK_SCMI_FLEXGEN_26	26
+#define CK_SCMI_FLEXGEN_27	27
+#define CK_SCMI_FLEXGEN_28	28
+#define CK_SCMI_FLEXGEN_29	29
+#define CK_SCMI_FLEXGEN_30	30
+#define CK_SCMI_FLEXGEN_31	31
+#define CK_SCMI_FLEXGEN_32	32
+#define CK_SCMI_FLEXGEN_33	33
+#define CK_SCMI_FLEXGEN_34	34
+#define CK_SCMI_FLEXGEN_35	35
+#define CK_SCMI_FLEXGEN_36	36
+#define CK_SCMI_FLEXGEN_37	37
+#define CK_SCMI_FLEXGEN_38	38
+#define CK_SCMI_FLEXGEN_39	39
+#define CK_SCMI_FLEXGEN_40	40
+#define CK_SCMI_FLEXGEN_41	41
+#define CK_SCMI_FLEXGEN_42	42
+#define CK_SCMI_FLEXGEN_43	43
+#define CK_SCMI_FLEXGEN_44	44
+#define CK_SCMI_FLEXGEN_45	45
+#define CK_SCMI_FLEXGEN_46	46
+#define CK_SCMI_FLEXGEN_47	47
+#define CK_SCMI_FLEXGEN_48	48
+#define CK_SCMI_FLEXGEN_49	49
+#define CK_SCMI_FLEXGEN_50	50
+#define CK_SCMI_FLEXGEN_51	51
+#define CK_SCMI_FLEXGEN_52	52
+#define CK_SCMI_FLEXGEN_53	53
+#define CK_SCMI_FLEXGEN_54	54
+#define CK_SCMI_FLEXGEN_55	55
+#define CK_SCMI_FLEXGEN_56	56
+#define CK_SCMI_FLEXGEN_57	57
+#define CK_SCMI_FLEXGEN_58	58
+#define CK_SCMI_FLEXGEN_59	59
+#define CK_SCMI_FLEXGEN_60	60
+#define CK_SCMI_FLEXGEN_61	61
+#define CK_SCMI_FLEXGEN_62	62
+#define CK_SCMI_FLEXGEN_63	63
+#define CK_SCMI_ICN_LS_MCU	64
+#define CK_SCMI_HSE		65
+#define CK_SCMI_LSE		66
+#define CK_SCMI_HSI		67
+#define CK_SCMI_LSI		68
+#define CK_SCMI_MSI		69
+#define CK_SCMI_HSE_DIV2	70
+#define CK_SCMI_CPU1		71
+#define CK_SCMI_SYSCPU1		72
+#define CK_SCMI_PLL2		73
+#define CK_SCMI_PLL3		74
+#define CK_SCMI_RTC		75
+#define CK_SCMI_RTCCK		76
+#define CK_SCMI_ICN_APB1	77
+#define CK_SCMI_ICN_APB2	78
+#define CK_SCMI_ICN_APB3	79
+#define CK_SCMI_ICN_APB4	80
+#define CK_SCMI_ICN_APBDBG	81
+#define CK_SCMI_TIMG1		82
+#define CK_SCMI_TIMG2		83
+#define CK_SCMI_BKPSRAM		84
+#define CK_SCMI_BSEC		85
+#define CK_SCMI_ETR		87
+#define CK_SCMI_FMC		88
+#define CK_SCMI_GPIOA		89
+#define CK_SCMI_GPIOB		90
+#define CK_SCMI_GPIOC		91
+#define CK_SCMI_GPIOD		92
+#define CK_SCMI_GPIOE		93
+#define CK_SCMI_GPIOF		94
+#define CK_SCMI_GPIOG		95
+#define CK_SCMI_GPIOH		96
+#define CK_SCMI_GPIOI		97
+#define CK_SCMI_GPIOJ		98
+#define CK_SCMI_GPIOK		99
+#define CK_SCMI_GPIOZ		100
+#define CK_SCMI_HPDMA1		101
+#define CK_SCMI_HPDMA2		102
+#define CK_SCMI_HPDMA3		103
+#define CK_SCMI_HSEM		104
+#define CK_SCMI_IPCC1		105
+#define CK_SCMI_IPCC2		106
+#define CK_SCMI_LPDMA		107
+#define CK_SCMI_RETRAM		108
+#define CK_SCMI_SRAM1		109
+#define CK_SCMI_SRAM2		110
+#define CK_SCMI_LPSRAM1		111
+#define CK_SCMI_LPSRAM2		112
+#define CK_SCMI_LPSRAM3		113
+#define CK_SCMI_VDERAM		114
+#define CK_SCMI_SYSRAM		115
+#define CK_SCMI_OSPI1		116
+#define CK_SCMI_OSPI2		117
+#define CK_SCMI_TPIU		118
+#define CK_SCMI_SYSDBG		119
+#define CK_SCMI_SYSATB		120
+#define CK_SCMI_TSDBG		121
+#define CK_SCMI_STM500		122
+
+#endif /* _DT_BINDINGS_STM32MP25_CLKS_H_ */
diff --git a/include/dt-bindings/reset/st,stm32mp25-rcc.h b/include/dt-bindings/reset/st,stm32mp25-rcc.h
new file mode 100644
index 000000000000..d5615930bcc8
--- /dev/null
+++ b/include/dt-bindings/reset/st,stm32mp25-rcc.h
@@ -0,0 +1,167 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
+/*
+ * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
+ * Author(s): Gabriel Fernandez <gabriel.fernandez at foss.st.com>
+ */
+
+#ifndef _DT_BINDINGS_STM32MP25_RESET_H_
+#define _DT_BINDINGS_STM32MP25_RESET_H_
+
+#define TIM1_R		0
+#define TIM2_R		1
+#define TIM3_R		2
+#define TIM4_R		3
+#define TIM5_R		4
+#define TIM6_R		5
+#define TIM7_R		6
+#define TIM8_R		7
+#define TIM10_R		8
+#define TIM11_R		9
+#define TIM12_R		10
+#define TIM13_R		11
+#define TIM14_R		12
+#define TIM15_R		13
+#define TIM16_R		14
+#define TIM17_R		15
+#define TIM20_R		16
+#define LPTIM1_R	17
+#define LPTIM2_R	18
+#define LPTIM3_R	19
+#define LPTIM4_R	20
+#define LPTIM5_R	21
+#define SPI1_R		22
+#define SPI2_R		23
+#define SPI3_R		24
+#define SPI4_R		25
+#define SPI5_R		26
+#define SPI6_R		27
+#define SPI7_R		28
+#define SPI8_R		29
+#define SPDIFRX_R	30
+#define USART1_R	31
+#define USART2_R	32
+#define USART3_R	33
+#define UART4_R		34
+#define UART5_R		35
+#define USART6_R	36
+#define UART7_R		37
+#define UART8_R		38
+#define UART9_R		39
+#define LPUART1_R	40
+#define IS2M_R		41
+#define I2C1_R		42
+#define I2C2_R		43
+#define I2C3_R		44
+#define I2C4_R		45
+#define I2C5_R		46
+#define I2C6_R		47
+#define I2C7_R		48
+#define I2C8_R		49
+#define SAI1_R		50
+#define SAI2_R		51
+#define SAI3_R		52
+#define SAI4_R		53
+#define MDF1_R		54
+#define MDF2_R		55
+#define FDCAN_R		56
+#define HDP_R		57
+#define ADC12_R		58
+#define ADC3_R		59
+#define ETH1_R		60
+#define ETH2_R		61
+#define USB2_R		62
+#define USB2PHY1_R	63
+#define USB2PHY2_R	64
+#define USB3DR_R	65
+#define USB3PCIEPHY_R	66
+#define USBTC_R		67
+#define ETHSW_R		68
+#define SDMMC1_R	69
+#define SDMMC1DLL_R	70
+#define SDMMC2_R	71
+#define SDMMC2DLL_R	72
+#define SDMMC3_R	73
+#define SDMMC3DLL_R	74
+#define GPU_R		75
+#define LTDC_R		76
+#define DSI_R		77
+#define LVDS_R		78
+#define CSI_R		79
+#define DCMIPP_R	80
+#define CCI_R		81
+#define VDEC_R		82
+#define VENC_R		83
+#define WWDG1_R		84
+#define WWDG2_R		85
+#define VREF_R		86
+#define DTS_R		87
+#define CRC_R		88
+#define SERC_R		89
+#define OSPIIOM_R	90
+#define I3C1_R		91
+#define I3C2_R		92
+#define I3C3_R		93
+#define I3C4_R		94
+#define IWDG2_KER_R	95
+#define IWDG4_KER_R	96
+#define RNG_R		97
+#define PKA_R		98
+#define SAES_R		99
+#define HASH_R		100
+#define CRYP1_R		101
+#define CRYP2_R		102
+#define PCIE_R		103
+#define OSPI1_R		104
+#define OSPI1DLL_R	105
+#define OSPI2_R		106
+#define OSPI2DLL_R	107
+#define FMC_R		108
+#define DBG_R		109
+#define GPIOA_R		110
+#define GPIOB_R		111
+#define GPIOC_R		112
+#define GPIOD_R		113
+#define GPIOE_R		114
+#define GPIOF_R		115
+#define GPIOG_R		116
+#define GPIOH_R		117
+#define GPIOI_R		118
+#define GPIOJ_R		119
+#define GPIOK_R		120
+#define GPIOZ_R		121
+#define HPDMA1_R	122
+#define HPDMA2_R	123
+#define HPDMA3_R	124
+#define LPDMA_R		125
+#define HSEM_R		126
+#define IPCC1_R		127
+#define IPCC2_R		128
+#define C2_HOLDBOOT_R	129
+#define C1_HOLDBOOT_R	130
+#define C1_R		131
+#define C1P1POR_R	132
+#define C1P1_R		133
+#define C2_R		134
+#define C3_R		135
+#define SYS_R		136
+#define VSW_R		137
+#define C1MS_R		138
+#define DDRCP_R		139
+#define DDRCAPB_R	140
+#define DDRPHYCAPB_R	141
+#define DDRCFG_R	142
+#define DDR_R		143
+
+#define STM32MP25_LAST_RESET	144
+
+#define RST_SCMI_C1_R		0
+#define RST_SCMI_C2_R		1
+#define RST_SCMI_C1_HOLDBOOT_R	2
+#define RST_SCMI_C2_HOLDBOOT_R	3
+#define RST_SCMI_FMC		4
+#define RST_SCMI_OSPI1		5
+#define RST_SCMI_OSPI1DLL	6
+#define RST_SCMI_OSPI2		7
+#define RST_SCMI_OSPI2DLL	8
+
+#endif /* _DT_BINDINGS_STM32MP25_RESET_H_ */
-- 
2.25.1



From gabriel.fernandez at foss.st.com  Fri Dec  8 06:36:55 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Fri, 8 Dec 2023 15:36:55 +0100
Subject: [PATCH v6 0/5] Introduce STM32MP257 clock driver
Message-ID: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

This patch-set introduces clock driver for STM32MP257 based on Arm Cortex-35.
It creates also a menuconfig for all STM32MP clock drivers.
The STM32MP1 and STM32MP13 are now in same stm32 directory

v6:
  - remove useless defines in drivers/clk/stm32/stm32mp25_rcc.h

v5:
  - Fix sparse warnings: was not declared. Should it be static?
    drivers/clk/stm32/clk-stm32mp13.c:1516:29: symbol 'stm32mp13_reset_data'
    drivers/clk/stm32/clk-stm32mp1.c:2148:29: symbol 'stm32mp1_reset_data'
    drivers/clk/stm32/clk-stm32mp25.c:1003:5: symbol 'stm32mp25_cpt_gate'
    drivers/clk/stm32/clk-stm32mp25.c:1005:29: symbol 'stm32mp25_clock_data'
    drivers/clk/stm32/clk-stm32mp25.c:1011:29: symbol 'stm32mp25_reset_data'

v4:
  - use GPL-2.0-only OR BSD-2-Clause for clock and reset binding files
  - use quotes ' for #clock-cells and #reset-cells in YAML documentation
  - reset binding start now to 0 instead 1
  - improve management of reset lines that are not managed

v3:
  - from Rob Herring change clock item description in YAML documentation
v2:
  - rework reset binding (use ID witch start from 0)
  - rework reset driver to manage STM32MP13 / STM32MP15 / STM32MP25
  - rework YAML documentation

Gabriel Fernandez (5):
  clk: stm32mp1: move stm32mp1 clock driver into stm32 directory
  clk: stm32mp1: use stm32mp13 reset driver
  dt-bindings: stm32: add clocks and reset binding for stm32mp25
    platform
  clk: stm32: introduce clocks for STM32MP257 platform
  arm64: dts: st: add rcc support in stm32mp251

 .../bindings/clock/st,stm32mp25-rcc.yaml      |   76 ++
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |   59 +-
 drivers/clk/Kconfig                           |   11 +-
 drivers/clk/Makefile                          |    1 -
 drivers/clk/stm32/Kconfig                     |   36 +
 drivers/clk/stm32/Makefile                    |    2 +
 drivers/clk/stm32/clk-stm32-core.c            |    5 +-
 drivers/clk/stm32/clk-stm32-core.h            |    5 +-
 drivers/clk/{ => stm32}/clk-stm32mp1.c        |  127 +-
 drivers/clk/stm32/clk-stm32mp13.c             |    9 +-
 drivers/clk/stm32/clk-stm32mp25.c             | 1125 +++++++++++++++++
 drivers/clk/stm32/reset-stm32.c               |   73 +-
 drivers/clk/stm32/reset-stm32.h               |   15 +-
 drivers/clk/stm32/stm32mp25_rcc.h             |  712 +++++++++++
 include/dt-bindings/clock/st,stm32mp25-rcc.h  |  492 +++++++
 include/dt-bindings/reset/st,stm32mp25-rcc.h  |  167 +++
 16 files changed, 2734 insertions(+), 181 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
 create mode 100644 drivers/clk/stm32/Kconfig
 rename drivers/clk/{ => stm32}/clk-stm32mp1.c (95%)
 create mode 100644 drivers/clk/stm32/clk-stm32mp25.c
 create mode 100644 drivers/clk/stm32/stm32mp25_rcc.h
 create mode 100644 include/dt-bindings/clock/st,stm32mp25-rcc.h
 create mode 100644 include/dt-bindings/reset/st,stm32mp25-rcc.h

-- 
2.25.1



From gabriel.fernandez at foss.st.com  Fri Dec  8 06:36:57 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Fri, 8 Dec 2023 15:36:57 +0100
Subject: [PATCH v6 2/5] clk: stm32mp1: use stm32mp13 reset driver
In-Reply-To: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
References: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231208143700.354785-3-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

STM32MP15 is now using the same reset driver as STM32MP13 as they
have the same binding requirement.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/stm32/Makefile         |   2 +-
 drivers/clk/stm32/clk-stm32-core.c |   5 +-
 drivers/clk/stm32/clk-stm32-core.h |   5 +-
 drivers/clk/stm32/clk-stm32mp1.c   | 127 ++++-------------------------
 drivers/clk/stm32/clk-stm32mp13.c  |   9 +-
 drivers/clk/stm32/reset-stm32.c    |  14 ++--
 drivers/clk/stm32/reset-stm32.h    |   8 +-
 7 files changed, 42 insertions(+), 128 deletions(-)

diff --git a/drivers/clk/stm32/Makefile b/drivers/clk/stm32/Makefile
index c154ef3e88f9..5ced7fe3ddec 100644
--- a/drivers/clk/stm32/Makefile
+++ b/drivers/clk/stm32/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_COMMON_CLK_STM32MP135)	+= clk-stm32mp13.o clk-stm32-core.o reset-stm32.o
-obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o
+obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o reset-stm32.o
diff --git a/drivers/clk/stm32/clk-stm32-core.c b/drivers/clk/stm32/clk-stm32-core.c
index 067b918a8894..58705fcad334 100644
--- a/drivers/clk/stm32/clk-stm32-core.c
+++ b/drivers/clk/stm32/clk-stm32-core.c
@@ -70,6 +70,7 @@ static int stm32_rcc_clock_init(struct device *dev,
 int stm32_rcc_init(struct device *dev, const struct of_device_id *match_data,
 		   void __iomem *base)
 {
+	const struct stm32_rcc_match_data *rcc_match_data;
 	const struct of_device_id *match;
 	int err;
 
@@ -79,8 +80,10 @@ int stm32_rcc_init(struct device *dev, const struct of_device_id *match_data,
 		return -ENODEV;
 	}
 
+	rcc_match_data = match->data;
+
 	/* RCC Reset Configuration */
-	err = stm32_rcc_reset_init(dev, match, base);
+	err = stm32_rcc_reset_init(dev, rcc_match_data->reset_data, base);
 	if (err) {
 		pr_err("stm32 reset failed to initialize\n");
 		return err;
diff --git a/drivers/clk/stm32/clk-stm32-core.h b/drivers/clk/stm32/clk-stm32-core.h
index 76cffda02308..bb5aa19a792d 100644
--- a/drivers/clk/stm32/clk-stm32-core.h
+++ b/drivers/clk/stm32/clk-stm32-core.h
@@ -70,15 +70,12 @@ struct stm32_rcc_match_data {
 	const struct clock_config	*tab_clocks;
 	unsigned int			maxbinding;
 	struct clk_stm32_clock_data	*clock_data;
-	u32				clear_offset;
+	struct clk_stm32_reset_data	*reset_data;
 	int (*check_security)(void __iomem *base,
 			      const struct clock_config *cfg);
 	int (*multi_mux)(void __iomem *base, const struct clock_config *cfg);
 };
 
-int stm32_rcc_reset_init(struct device *dev, const struct of_device_id *match,
-			 void __iomem *base);
-
 int stm32_rcc_init(struct device *dev, const struct of_device_id *match_data,
 		   void __iomem *base);
 
diff --git a/drivers/clk/stm32/clk-stm32mp1.c b/drivers/clk/stm32/clk-stm32mp1.c
index 939779f66867..7e2337297402 100644
--- a/drivers/clk/stm32/clk-stm32mp1.c
+++ b/drivers/clk/stm32/clk-stm32mp1.c
@@ -20,6 +20,10 @@
 
 #include <dt-bindings/clock/stm32mp1-clks.h>
 
+#include "reset-stm32.h"
+
+#define STM32MP1_RESET_ID_MASK GENMASK(15, 0)
+
 static DEFINE_SPINLOCK(rlock);
 
 #define RCC_OCENSETR		0x0C
@@ -2137,22 +2141,27 @@ struct stm32_rcc_match_data {
 	const struct clock_config *cfg;
 	unsigned int num;
 	unsigned int maxbinding;
-	u32 clear_offset;
+	struct clk_stm32_reset_data *reset_data;
 	bool (*check_security)(const struct clock_config *cfg);
 };
 
+static struct clk_stm32_reset_data stm32mp1_reset_data = {
+	.nr_lines	= STM32MP1_RESET_ID_MASK,
+	.clear_offset	= RCC_CLR,
+};
+
 static struct stm32_rcc_match_data stm32mp1_data = {
 	.cfg		= stm32mp1_clock_cfg,
 	.num		= ARRAY_SIZE(stm32mp1_clock_cfg),
 	.maxbinding	= STM32MP1_LAST_CLK,
-	.clear_offset	= RCC_CLR,
+	.reset_data	= &stm32mp1_reset_data,
 };
 
 static struct stm32_rcc_match_data stm32mp1_data_secure = {
 	.cfg		= stm32mp1_clock_cfg,
 	.num		= ARRAY_SIZE(stm32mp1_clock_cfg),
 	.maxbinding	= STM32MP1_LAST_CLK,
-	.clear_offset	= RCC_CLR,
+	.reset_data	= &stm32mp1_reset_data,
 	.check_security = &stm32_check_security
 };
 
@@ -2193,113 +2202,6 @@ static int stm32_register_hw_clk(struct device *dev,
 	return 0;
 }
 
-#define STM32_RESET_ID_MASK GENMASK(15, 0)
-
-struct stm32_reset_data {
-	/* reset lock */
-	spinlock_t			lock;
-	struct reset_controller_dev	rcdev;
-	void __iomem			*membase;
-	u32				clear_offset;
-};
-
-static inline struct stm32_reset_data *
-to_stm32_reset_data(struct reset_controller_dev *rcdev)
-{
-	return container_of(rcdev, struct stm32_reset_data, rcdev);
-}
-
-static int stm32_reset_update(struct reset_controller_dev *rcdev,
-			      unsigned long id, bool assert)
-{
-	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
-
-	if (data->clear_offset) {
-		void __iomem *addr;
-
-		addr = data->membase + (bank * reg_width);
-		if (!assert)
-			addr += data->clear_offset;
-
-		writel(BIT(offset), addr);
-
-	} else {
-		unsigned long flags;
-		u32 reg;
-
-		spin_lock_irqsave(&data->lock, flags);
-
-		reg = readl(data->membase + (bank * reg_width));
-
-		if (assert)
-			reg |= BIT(offset);
-		else
-			reg &= ~BIT(offset);
-
-		writel(reg, data->membase + (bank * reg_width));
-
-		spin_unlock_irqrestore(&data->lock, flags);
-	}
-
-	return 0;
-}
-
-static int stm32_reset_assert(struct reset_controller_dev *rcdev,
-			      unsigned long id)
-{
-	return stm32_reset_update(rcdev, id, true);
-}
-
-static int stm32_reset_deassert(struct reset_controller_dev *rcdev,
-				unsigned long id)
-{
-	return stm32_reset_update(rcdev, id, false);
-}
-
-static int stm32_reset_status(struct reset_controller_dev *rcdev,
-			      unsigned long id)
-{
-	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
-	u32 reg;
-
-	reg = readl(data->membase + (bank * reg_width));
-
-	return !!(reg & BIT(offset));
-}
-
-static const struct reset_control_ops stm32_reset_ops = {
-	.assert		= stm32_reset_assert,
-	.deassert	= stm32_reset_deassert,
-	.status		= stm32_reset_status,
-};
-
-static int stm32_rcc_reset_init(struct device *dev, void __iomem *base,
-				const struct of_device_id *match)
-{
-	const struct stm32_rcc_match_data *data = match->data;
-	struct stm32_reset_data *reset_data = NULL;
-
-	reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
-	if (!reset_data)
-		return -ENOMEM;
-
-	spin_lock_init(&reset_data->lock);
-	reset_data->membase = base;
-	reset_data->rcdev.owner = THIS_MODULE;
-	reset_data->rcdev.ops = &stm32_reset_ops;
-	reset_data->rcdev.of_node = dev_of_node(dev);
-	reset_data->rcdev.nr_resets = STM32_RESET_ID_MASK;
-	reset_data->clear_offset = data->clear_offset;
-
-	return reset_controller_register(&reset_data->rcdev);
-}
-
 static int stm32_rcc_clock_init(struct device *dev, void __iomem *base,
 				const struct of_device_id *match)
 {
@@ -2342,6 +2244,7 @@ static int stm32_rcc_clock_init(struct device *dev, void __iomem *base,
 static int stm32_rcc_init(struct device *dev, void __iomem *base,
 			  const struct of_device_id *match_data)
 {
+	const struct stm32_rcc_match_data *rcc_match_data;
 	const struct of_device_id *match;
 	int err;
 
@@ -2351,8 +2254,10 @@ static int stm32_rcc_init(struct device *dev, void __iomem *base,
 		return -ENODEV;
 	}
 
+	rcc_match_data = match->data;
+
 	/* RCC Reset Configuration */
-	err = stm32_rcc_reset_init(dev, base, match);
+	err = stm32_rcc_reset_init(dev, rcc_match_data->reset_data, base);
 	if (err) {
 		pr_err("stm32mp1 reset failed to initialize\n");
 		return err;
diff --git a/drivers/clk/stm32/clk-stm32mp13.c b/drivers/clk/stm32/clk-stm32mp13.c
index c4a737482fe5..d4ecb3c34a1b 100644
--- a/drivers/clk/stm32/clk-stm32mp13.c
+++ b/drivers/clk/stm32/clk-stm32mp13.c
@@ -10,8 +10,10 @@
 #include <linux/platform_device.h>
 #include <dt-bindings/clock/stm32mp13-clks.h>
 #include "clk-stm32-core.h"
+#include "reset-stm32.h"
 #include "stm32mp13_rcc.h"
 
+#define STM32MP1_RESET_ID_MASK GENMASK(15, 0)
 #define RCC_CLR_OFFSET		0x4
 
 /* STM32 Gates definition */
@@ -1511,13 +1513,18 @@ static struct clk_stm32_clock_data stm32mp13_clock_data = {
 	.is_multi_mux	= stm32mp13_is_multi_mux,
 };
 
+static struct clk_stm32_reset_data stm32mp13_reset_data = {
+	.nr_lines	= STM32MP1_RESET_ID_MASK,
+	.clear_offset	= RCC_CLR_OFFSET,
+};
+
 static const struct stm32_rcc_match_data stm32mp13_data = {
 	.tab_clocks	= stm32mp13_clock_cfg,
 	.num_clocks	= ARRAY_SIZE(stm32mp13_clock_cfg),
 	.clock_data	= &stm32mp13_clock_data,
 	.check_security = &stm32mp13_clock_is_provided_by_secure,
 	.maxbinding	= STM32MP1_LAST_CLK,
-	.clear_offset	= RCC_CLR_OFFSET,
+	.reset_data	= &stm32mp13_reset_data,
 };
 
 static const struct of_device_id stm32mp13_match_data[] = {
diff --git a/drivers/clk/stm32/reset-stm32.c b/drivers/clk/stm32/reset-stm32.c
index e89381528af9..14c2ee1eebee 100644
--- a/drivers/clk/stm32/reset-stm32.c
+++ b/drivers/clk/stm32/reset-stm32.c
@@ -11,9 +11,7 @@
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 
-#include "clk-stm32-core.h"
-
-#define STM32_RESET_ID_MASK GENMASK(15, 0)
+#include "reset-stm32.h"
 
 struct stm32_reset_data {
 	/* reset lock */
@@ -99,24 +97,22 @@ static const struct reset_control_ops stm32_reset_ops = {
 	.status		= stm32_reset_status,
 };
 
-int stm32_rcc_reset_init(struct device *dev, const struct of_device_id *match,
+int stm32_rcc_reset_init(struct device *dev, struct clk_stm32_reset_data *data,
 			 void __iomem *base)
 {
-	const struct stm32_rcc_match_data *data = match->data;
-	struct stm32_reset_data *reset_data = NULL;
-
-	data = match->data;
+	struct stm32_reset_data *reset_data;
 
 	reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
 	if (!reset_data)
 		return -ENOMEM;
 
 	spin_lock_init(&reset_data->lock);
+
 	reset_data->membase = base;
 	reset_data->rcdev.owner = THIS_MODULE;
 	reset_data->rcdev.ops = &stm32_reset_ops;
 	reset_data->rcdev.of_node = dev_of_node(dev);
-	reset_data->rcdev.nr_resets = STM32_RESET_ID_MASK;
+	reset_data->rcdev.nr_resets = data->nr_lines;
 	reset_data->clear_offset = data->clear_offset;
 
 	return reset_controller_register(&reset_data->rcdev);
diff --git a/drivers/clk/stm32/reset-stm32.h b/drivers/clk/stm32/reset-stm32.h
index 6eb6ea4b55ab..8cf1cc9be480 100644
--- a/drivers/clk/stm32/reset-stm32.h
+++ b/drivers/clk/stm32/reset-stm32.h
@@ -4,5 +4,11 @@
  * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
  */
 
-int stm32_rcc_reset_init(struct device *dev, const struct of_device_id *match,
+struct clk_stm32_reset_data {
+	const struct reset_control_ops *ops;
+	unsigned int nr_lines;
+	u32 clear_offset;
+};
+
+int stm32_rcc_reset_init(struct device *dev, struct clk_stm32_reset_data *data,
 			 void __iomem *base);
-- 
2.25.1



From gabriel.fernandez at foss.st.com  Fri Dec  8 06:37:00 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Fri, 8 Dec 2023 15:37:00 +0100
Subject: [PATCH v6 5/5] arm64: dts: st: add rcc support in stm32mp251
In-Reply-To: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
References: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231208143700.354785-6-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Add RCC support to manage clocks and resets on the STM32MP251.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 59 ++++++++++++++------------
 1 file changed, 31 insertions(+), 28 deletions(-)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 124403f5f1f4..dfbdb3a773e4 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -3,7 +3,9 @@
  * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
  * Author: Alexandre Torgue <alexandre.torgue at foss.st.com> for STMicroelectronics.
  */
+#include <dt-bindings/clock/st,stm32mp25-rcc.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset/st,stm32mp25-rcc.h>
 
 / {
 	#address-cells = <2>;
@@ -35,22 +37,10 @@ arm_wdt: watchdog {
 	};
 
 	clocks {
-		ck_flexgen_08: ck-flexgen-08 {
+		clk_rcbsec: clk-rcbsec {
 			#clock-cells = <0>;
 			compatible = "fixed-clock";
-			clock-frequency = <100000000>;
-		};
-
-		ck_flexgen_51: ck-flexgen-51 {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <200000000>;
-		};
-
-		ck_icn_ls_mcu: ck-icn-ls-mcu {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <200000000>;
+			clock-frequency = <64000000>;
 		};
 	};
 
@@ -122,7 +112,7 @@ usart2: serial at 400e0000 {
 				compatible = "st,stm32h7-uart";
 				reg = <0x400e0000 0x400>;
 				interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&ck_flexgen_08>;
+				clocks = <&rcc CK_KER_USART2>;
 				status = "disabled";
 			};
 
@@ -131,7 +121,7 @@ sdmmc1: mmc at 48220000 {
 				arm,primecell-periphid = <0x00353180>;
 				reg = <0x48220000 0x400>, <0x44230400 0x8>;
 				interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&ck_flexgen_51>;
+				clocks = <&rcc CK_KER_SDMMC1 >;
 				clock-names = "apb_pclk";
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
@@ -140,6 +130,19 @@ sdmmc1: mmc at 48220000 {
 			};
 		};
 
+		rcc: clock-controller at 44200000 {
+			compatible = "st,stm32mp25-rcc";
+			reg = <0x44200000 0x10000>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+			clock-names = "hse", "hsi", "msi", "lse", "lsi";
+			clocks = <&scmi_clk CK_SCMI_HSE>,
+				<&scmi_clk CK_SCMI_HSI>,
+				<&scmi_clk CK_SCMI_MSI>,
+				<&scmi_clk CK_SCMI_LSE>,
+				<&scmi_clk CK_SCMI_LSI>;
+		};
+
 		syscfg: syscon at 44230000 {
 			compatible = "st,stm32mp25-syscfg", "syscon";
 			reg = <0x44230000 0x10000>;
@@ -158,7 +161,7 @@ gpioa: gpio at 44240000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x0 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOA>;
 				st,bank-name = "GPIOA";
 				status = "disabled";
 			};
@@ -169,7 +172,7 @@ gpiob: gpio at 44250000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x10000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOB>;
 				st,bank-name = "GPIOB";
 				status = "disabled";
 			};
@@ -180,7 +183,7 @@ gpioc: gpio at 44260000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x20000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOC>;
 				st,bank-name = "GPIOC";
 				status = "disabled";
 			};
@@ -191,7 +194,7 @@ gpiod: gpio at 44270000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x30000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOD>;
 				st,bank-name = "GPIOD";
 				status = "disabled";
 			};
@@ -202,7 +205,7 @@ gpioe: gpio at 44280000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x40000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOE>;
 				st,bank-name = "GPIOE";
 				status = "disabled";
 			};
@@ -213,7 +216,7 @@ gpiof: gpio at 44290000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x50000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOF>;
 				st,bank-name = "GPIOF";
 				status = "disabled";
 			};
@@ -224,7 +227,7 @@ gpiog: gpio at 442a0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x60000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOG>;
 				st,bank-name = "GPIOG";
 				status = "disabled";
 			};
@@ -235,7 +238,7 @@ gpioh: gpio at 442b0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x70000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOH>;
 				st,bank-name = "GPIOH";
 				status = "disabled";
 			};
@@ -246,7 +249,7 @@ gpioi: gpio at 442c0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x80000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOI>;
 				st,bank-name = "GPIOI";
 				status = "disabled";
 			};
@@ -257,7 +260,7 @@ gpioj: gpio at 442d0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x90000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOJ>;
 				st,bank-name = "GPIOJ";
 				status = "disabled";
 			};
@@ -268,7 +271,7 @@ gpiok: gpio at 442e0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0xa0000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOK>;
 				st,bank-name = "GPIOK";
 				status = "disabled";
 			};
@@ -287,7 +290,7 @@ gpioz: gpio at 46200000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOZ>;
 				st,bank-name = "GPIOZ";
 				st,bank-ioport = <11>;
 				status = "disabled";
-- 
2.25.1



From gabriel.fernandez at foss.st.com  Fri Dec  8 06:36:59 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Fri, 8 Dec 2023 15:36:59 +0100
Subject: [PATCH v6 4/5] clk: stm32: introduce clocks for STM32MP257 platform
In-Reply-To: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
References: <20231208143700.354785-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231208143700.354785-5-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

This driver is intended for the STM32MP25 clock family and utilizes
the stm32-core API, similar to the stm32mp13 clock driver.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/stm32/Kconfig         |    7 +
 drivers/clk/stm32/Makefile        |    1 +
 drivers/clk/stm32/clk-stm32mp25.c | 1125 +++++++++++++++++++++++++++++
 drivers/clk/stm32/reset-stm32.c   |   59 +-
 drivers/clk/stm32/reset-stm32.h   |    7 +
 drivers/clk/stm32/stm32mp25_rcc.h |  712 ++++++++++++++++++
 6 files changed, 1896 insertions(+), 15 deletions(-)
 create mode 100644 drivers/clk/stm32/clk-stm32mp25.c
 create mode 100644 drivers/clk/stm32/stm32mp25_rcc.h

diff --git a/drivers/clk/stm32/Kconfig b/drivers/clk/stm32/Kconfig
index 3c8493a94a11..dca409d52652 100644
--- a/drivers/clk/stm32/Kconfig
+++ b/drivers/clk/stm32/Kconfig
@@ -25,5 +25,12 @@ config COMMON_CLK_STM32MP157
 	help
 	  Support for stm32mp15x SoC family clocks.
 
+config COMMON_CLK_STM32MP257
+	bool "Clock driver for stm32mp25x clocks"
+	depends on ARM64 || COMPILE_TEST
+	default y
+	help
+	  Support for stm32mp25x SoC family clocks.
+
 endif
 
diff --git a/drivers/clk/stm32/Makefile b/drivers/clk/stm32/Makefile
index 5ced7fe3ddec..0a627164fcce 100644
--- a/drivers/clk/stm32/Makefile
+++ b/drivers/clk/stm32/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_COMMON_CLK_STM32MP135)	+= clk-stm32mp13.o clk-stm32-core.o reset-stm32.o
 obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o reset-stm32.o
+obj-$(CONFIG_COMMON_CLK_STM32MP257)	+= clk-stm32mp25.o clk-stm32-core.o reset-stm32.o
diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
new file mode 100644
index 000000000000..36321fd6142e
--- /dev/null
+++ b/drivers/clk/stm32/clk-stm32mp25.c
@@ -0,0 +1,1125 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
+ * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+#include "clk-stm32-core.h"
+#include "reset-stm32.h"
+
+#include <dt-bindings/clock/st,stm32mp25-rcc.h>
+#include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+#include "stm32mp25_rcc.h"
+
+static const char * const adc12_src[] = {
+	"ck_flexgen_46", "ck_icn_ls_mcu"
+};
+
+static const char * const adc3_src[] = {
+	"ck_flexgen_47", "ck_icn_ls_mcu", "ck_flexgen_46"
+};
+
+static const char * const usb2phy1_src[] = {
+	"ck_flexgen_57", "hse_div2_ck"
+};
+
+static const char * const usb2phy2_src[] = {
+	"ck_flexgen_58", "hse_div2_ck"
+};
+
+static const char * const usb3pciphy_src[] = {
+	"ck_flexgen_34", "hse_div2_ck"
+};
+
+static const char * const dsiblane_src[] = {
+	"txbyteclk", "ck_ker_ltdc"
+};
+
+static const char * const dsiphy_src[] = {
+	"ck_flexgen_28", "hse_ck"
+};
+
+static const char * const lvdsphy_src[] = {
+	"ck_flexgen_32", "hse_ck"
+};
+
+static const char * const dts_src[] = {
+	"hsi_ck", "hse_ck", "msi_ck"
+};
+
+static const char * const mco1_src[] = {
+	"ck_flexgen_61", "ck_obs0"
+};
+
+static const char * const mco2_src[] = {
+	"ck_flexgen_62", "ck_obs1"
+};
+
+enum enum_mux_cfg {
+	MUX_ADC12,
+	MUX_ADC3,
+	MUX_DSIBLANE,
+	MUX_DSIPHY,
+	MUX_DTS,
+	MUX_LVDSPHY,
+	MUX_MCO1,
+	MUX_MCO2,
+	MUX_USB2PHY1,
+	MUX_USB2PHY2,
+	MUX_USB3PCIEPHY,
+	MUX_NB
+};
+
+#define MUX_CFG(id, _offset, _shift, _witdh)\
+	[id] = {\
+		.offset		= (_offset),\
+		.shift		= (_shift),\
+		.width		= (_witdh),\
+	}
+
+static const struct stm32_mux_cfg stm32mp25_muxes[MUX_NB] = {
+	MUX_CFG(MUX_ADC12,		RCC_ADC12CFGR,		12,	1),
+	MUX_CFG(MUX_ADC3,		RCC_ADC3CFGR,		12,	2),
+	MUX_CFG(MUX_DSIBLANE,		RCC_DSICFGR,		12,	1),
+	MUX_CFG(MUX_DSIPHY,		RCC_DSICFGR,		15,	1),
+	MUX_CFG(MUX_DTS,		RCC_DTSCFGR,		12,	2),
+	MUX_CFG(MUX_LVDSPHY,		RCC_LVDSCFGR,		15,	1),
+	MUX_CFG(MUX_MCO1,		RCC_MCO1CFGR,		0,	1),
+	MUX_CFG(MUX_MCO2,		RCC_MCO2CFGR,		0,	1),
+	MUX_CFG(MUX_USB2PHY1,		RCC_USB2PHY1CFGR,	15,	1),
+	MUX_CFG(MUX_USB2PHY2,		RCC_USB2PHY2CFGR,	15,	1),
+	MUX_CFG(MUX_USB3PCIEPHY,	RCC_USB3PCIEPHYCFGR,	15,	1),
+};
+
+enum enum_gate_cfg {
+	GATE_ADC12,
+	GATE_ADC3,
+	GATE_ADF1,
+	GATE_CCI,
+	GATE_CRC,
+	GATE_CRYP1,
+	GATE_CRYP2,
+	GATE_CSI,
+	GATE_DCMIPP,
+	GATE_DSI,
+	GATE_DTS,
+	GATE_ETH1,
+	GATE_ETH1MAC,
+	GATE_ETH1RX,
+	GATE_ETH1STP,
+	GATE_ETH1TX,
+	GATE_ETH2,
+	GATE_ETH2MAC,
+	GATE_ETH2RX,
+	GATE_ETH2STP,
+	GATE_ETH2TX,
+	GATE_ETHSW,
+	GATE_ETHSWACMCFG,
+	GATE_ETHSWACMMSG,
+	GATE_ETHSWMAC,
+	GATE_ETHSWREF,
+	GATE_FDCAN,
+	GATE_GPU,
+	GATE_HASH,
+	GATE_HDP,
+	GATE_I2C1,
+	GATE_I2C2,
+	GATE_I2C3,
+	GATE_I2C4,
+	GATE_I2C5,
+	GATE_I2C6,
+	GATE_I2C7,
+	GATE_I2C8,
+	GATE_I3C1,
+	GATE_I3C2,
+	GATE_I3C3,
+	GATE_I3C4,
+	GATE_IS2M,
+	GATE_IWDG1,
+	GATE_IWDG2,
+	GATE_IWDG3,
+	GATE_IWDG4,
+	GATE_IWDG5,
+	GATE_LPTIM1,
+	GATE_LPTIM2,
+	GATE_LPTIM3,
+	GATE_LPTIM4,
+	GATE_LPTIM5,
+	GATE_LPUART1,
+	GATE_LTDC,
+	GATE_LVDS,
+	GATE_MCO1,
+	GATE_MCO2,
+	GATE_MDF1,
+	GATE_OSPIIOM,
+	GATE_PCIE,
+	GATE_PKA,
+	GATE_RNG,
+	GATE_SAES,
+	GATE_SAI1,
+	GATE_SAI2,
+	GATE_SAI3,
+	GATE_SAI4,
+	GATE_SDMMC1,
+	GATE_SDMMC2,
+	GATE_SDMMC3,
+	GATE_SERC,
+	GATE_SPDIFRX,
+	GATE_SPI1,
+	GATE_SPI2,
+	GATE_SPI3,
+	GATE_SPI4,
+	GATE_SPI5,
+	GATE_SPI6,
+	GATE_SPI7,
+	GATE_SPI8,
+	GATE_TIM1,
+	GATE_TIM10,
+	GATE_TIM11,
+	GATE_TIM12,
+	GATE_TIM13,
+	GATE_TIM14,
+	GATE_TIM15,
+	GATE_TIM16,
+	GATE_TIM17,
+	GATE_TIM2,
+	GATE_TIM20,
+	GATE_TIM3,
+	GATE_TIM4,
+	GATE_TIM5,
+	GATE_TIM6,
+	GATE_TIM7,
+	GATE_TIM8,
+	GATE_UART4,
+	GATE_UART5,
+	GATE_UART7,
+	GATE_UART8,
+	GATE_UART9,
+	GATE_USART1,
+	GATE_USART2,
+	GATE_USART3,
+	GATE_USART6,
+	GATE_USB2,
+	GATE_USB2PHY1,
+	GATE_USB2PHY2,
+	GATE_USB3DR,
+	GATE_USB3PCIEPHY,
+	GATE_USBTC,
+	GATE_VDEC,
+	GATE_VENC,
+	GATE_VREF,
+	GATE_WWDG1,
+	GATE_WWDG2,
+	GATE_NB
+};
+
+#define GATE_CFG(id, _offset, _bit_idx, _offset_clr)\
+	[id] = {\
+		.offset		= (_offset),\
+		.bit_idx	= (_bit_idx),\
+		.set_clr	= (_offset_clr),\
+	}
+
+static const struct stm32_gate_cfg stm32mp25_gates[GATE_NB] = {
+	GATE_CFG(GATE_ADC12,		RCC_ADC12CFGR,		1,	0),
+	GATE_CFG(GATE_ADC3,		RCC_ADC3CFGR,		1,	0),
+	GATE_CFG(GATE_ADF1,		RCC_ADF1CFGR,		1,	0),
+	GATE_CFG(GATE_CCI,		RCC_CCICFGR,		1,	0),
+	GATE_CFG(GATE_CRC,		RCC_CRCCFGR,		1,	0),
+	GATE_CFG(GATE_CRYP1,		RCC_CRYP1CFGR,		1,	0),
+	GATE_CFG(GATE_CRYP2,		RCC_CRYP2CFGR,		1,	0),
+	GATE_CFG(GATE_CSI,		RCC_CSICFGR,		1,	0),
+	GATE_CFG(GATE_DCMIPP,		RCC_DCMIPPCFGR,		1,	0),
+	GATE_CFG(GATE_DSI,		RCC_DSICFGR,		1,	0),
+	GATE_CFG(GATE_DTS,		RCC_DTSCFGR,		1,	0),
+	GATE_CFG(GATE_ETH1,		RCC_ETH1CFGR,		5,	0),
+	GATE_CFG(GATE_ETH1MAC,		RCC_ETH1CFGR,		1,	0),
+	GATE_CFG(GATE_ETH1RX,		RCC_ETH1CFGR,		10,	0),
+	GATE_CFG(GATE_ETH1STP,		RCC_ETH1CFGR,		4,	0),
+	GATE_CFG(GATE_ETH1TX,		RCC_ETH1CFGR,		8,	0),
+	GATE_CFG(GATE_ETH2,		RCC_ETH2CFGR,		5,	0),
+	GATE_CFG(GATE_ETH2MAC,		RCC_ETH2CFGR,		1,	0),
+	GATE_CFG(GATE_ETH2RX,		RCC_ETH2CFGR,		10,	0),
+	GATE_CFG(GATE_ETH2STP,		RCC_ETH2CFGR,		4,	0),
+	GATE_CFG(GATE_ETH2TX,		RCC_ETH2CFGR,		8,	0),
+	GATE_CFG(GATE_ETHSW,		RCC_ETHSWCFGR,		5,	0),
+	GATE_CFG(GATE_ETHSWACMCFG,	RCC_ETHSWACMCFGR,	1,	0),
+	GATE_CFG(GATE_ETHSWACMMSG,	RCC_ETHSWACMMSGCFGR,	1,	0),
+	GATE_CFG(GATE_ETHSWMAC,		RCC_ETHSWCFGR,		1,	0),
+	GATE_CFG(GATE_ETHSWREF,		RCC_ETHSWCFGR,		21,	0),
+	GATE_CFG(GATE_FDCAN,		RCC_FDCANCFGR,		1,	0),
+	GATE_CFG(GATE_GPU,		RCC_GPUCFGR,		1,	0),
+	GATE_CFG(GATE_HASH,		RCC_HASHCFGR,		1,	0),
+	GATE_CFG(GATE_HDP,		RCC_HDPCFGR,		1,	0),
+	GATE_CFG(GATE_I2C1,		RCC_I2C1CFGR,		1,	0),
+	GATE_CFG(GATE_I2C2,		RCC_I2C2CFGR,		1,	0),
+	GATE_CFG(GATE_I2C3,		RCC_I2C3CFGR,		1,	0),
+	GATE_CFG(GATE_I2C4,		RCC_I2C4CFGR,		1,	0),
+	GATE_CFG(GATE_I2C5,		RCC_I2C5CFGR,		1,	0),
+	GATE_CFG(GATE_I2C6,		RCC_I2C6CFGR,		1,	0),
+	GATE_CFG(GATE_I2C7,		RCC_I2C7CFGR,		1,	0),
+	GATE_CFG(GATE_I2C8,		RCC_I2C8CFGR,		1,	0),
+	GATE_CFG(GATE_I3C1,		RCC_I3C1CFGR,		1,	0),
+	GATE_CFG(GATE_I3C2,		RCC_I3C2CFGR,		1,	0),
+	GATE_CFG(GATE_I3C3,		RCC_I3C3CFGR,		1,	0),
+	GATE_CFG(GATE_I3C4,		RCC_I3C4CFGR,		1,	0),
+	GATE_CFG(GATE_IS2M,		RCC_IS2MCFGR,		1,	0),
+	GATE_CFG(GATE_IWDG1,		RCC_IWDG1CFGR,		1,	0),
+	GATE_CFG(GATE_IWDG2,		RCC_IWDG2CFGR,		1,	0),
+	GATE_CFG(GATE_IWDG3,		RCC_IWDG3CFGR,		1,	0),
+	GATE_CFG(GATE_IWDG4,		RCC_IWDG4CFGR,		1,	0),
+	GATE_CFG(GATE_IWDG5,		RCC_IWDG5CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM1,		RCC_LPTIM1CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM2,		RCC_LPTIM2CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM3,		RCC_LPTIM3CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM4,		RCC_LPTIM4CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM5,		RCC_LPTIM5CFGR,		1,	0),
+	GATE_CFG(GATE_LPUART1,		RCC_LPUART1CFGR,	1,	0),
+	GATE_CFG(GATE_LTDC,		RCC_LTDCCFGR,		1,	0),
+	GATE_CFG(GATE_LVDS,		RCC_LVDSCFGR,		1,	0),
+	GATE_CFG(GATE_MCO1,		RCC_MCO1CFGR,		8,	0),
+	GATE_CFG(GATE_MCO2,		RCC_MCO2CFGR,		8,	0),
+	GATE_CFG(GATE_MDF1,		RCC_MDF1CFGR,		1,	0),
+	GATE_CFG(GATE_OSPIIOM,		RCC_OSPIIOMCFGR,	1,	0),
+	GATE_CFG(GATE_PCIE,		RCC_PCIECFGR,		1,	0),
+	GATE_CFG(GATE_PKA,		RCC_PKACFGR,		1,	0),
+	GATE_CFG(GATE_RNG,		RCC_RNGCFGR,		1,	0),
+	GATE_CFG(GATE_SAES,		RCC_SAESCFGR,		1,	0),
+	GATE_CFG(GATE_SAI1,		RCC_SAI1CFGR,		1,	0),
+	GATE_CFG(GATE_SAI2,		RCC_SAI2CFGR,		1,	0),
+	GATE_CFG(GATE_SAI3,		RCC_SAI3CFGR,		1,	0),
+	GATE_CFG(GATE_SAI4,		RCC_SAI4CFGR,		1,	0),
+	GATE_CFG(GATE_SDMMC1,		RCC_SDMMC1CFGR,		1,	0),
+	GATE_CFG(GATE_SDMMC2,		RCC_SDMMC2CFGR,		1,	0),
+	GATE_CFG(GATE_SDMMC3,		RCC_SDMMC3CFGR,		1,	0),
+	GATE_CFG(GATE_SERC,		RCC_SERCCFGR,		1,	0),
+	GATE_CFG(GATE_SPDIFRX,		RCC_SPDIFRXCFGR,	1,	0),
+	GATE_CFG(GATE_SPI1,		RCC_SPI1CFGR,		1,	0),
+	GATE_CFG(GATE_SPI2,		RCC_SPI2CFGR,		1,	0),
+	GATE_CFG(GATE_SPI3,		RCC_SPI3CFGR,		1,	0),
+	GATE_CFG(GATE_SPI4,		RCC_SPI4CFGR,		1,	0),
+	GATE_CFG(GATE_SPI5,		RCC_SPI5CFGR,		1,	0),
+	GATE_CFG(GATE_SPI6,		RCC_SPI6CFGR,		1,	0),
+	GATE_CFG(GATE_SPI7,		RCC_SPI7CFGR,		1,	0),
+	GATE_CFG(GATE_SPI8,		RCC_SPI8CFGR,		1,	0),
+	GATE_CFG(GATE_TIM1,		RCC_TIM1CFGR,		1,	0),
+	GATE_CFG(GATE_TIM10,		RCC_TIM10CFGR,		1,	0),
+	GATE_CFG(GATE_TIM11,		RCC_TIM11CFGR,		1,	0),
+	GATE_CFG(GATE_TIM12,		RCC_TIM12CFGR,		1,	0),
+	GATE_CFG(GATE_TIM13,		RCC_TIM13CFGR,		1,	0),
+	GATE_CFG(GATE_TIM14,		RCC_TIM14CFGR,		1,	0),
+	GATE_CFG(GATE_TIM15,		RCC_TIM15CFGR,		1,	0),
+	GATE_CFG(GATE_TIM16,		RCC_TIM16CFGR,		1,	0),
+	GATE_CFG(GATE_TIM17,		RCC_TIM17CFGR,		1,	0),
+	GATE_CFG(GATE_TIM2,		RCC_TIM2CFGR,		1,	0),
+	GATE_CFG(GATE_TIM20,		RCC_TIM20CFGR,		1,	0),
+	GATE_CFG(GATE_TIM3,		RCC_TIM3CFGR,		1,	0),
+	GATE_CFG(GATE_TIM4,		RCC_TIM4CFGR,		1,	0),
+	GATE_CFG(GATE_TIM5,		RCC_TIM5CFGR,		1,	0),
+	GATE_CFG(GATE_TIM6,		RCC_TIM6CFGR,		1,	0),
+	GATE_CFG(GATE_TIM7,		RCC_TIM7CFGR,		1,	0),
+	GATE_CFG(GATE_TIM8,		RCC_TIM8CFGR,		1,	0),
+	GATE_CFG(GATE_UART4,		RCC_UART4CFGR,		1,	0),
+	GATE_CFG(GATE_UART5,		RCC_UART5CFGR,		1,	0),
+	GATE_CFG(GATE_UART7,		RCC_UART7CFGR,		1,	0),
+	GATE_CFG(GATE_UART8,		RCC_UART8CFGR,		1,	0),
+	GATE_CFG(GATE_UART9,		RCC_UART9CFGR,		1,	0),
+	GATE_CFG(GATE_USART1,		RCC_USART1CFGR,		1,	0),
+	GATE_CFG(GATE_USART2,		RCC_USART2CFGR,		1,	0),
+	GATE_CFG(GATE_USART3,		RCC_USART3CFGR,		1,	0),
+	GATE_CFG(GATE_USART6,		RCC_USART6CFGR,		1,	0),
+	GATE_CFG(GATE_USB2,		RCC_USB2CFGR,		1,	0),
+	GATE_CFG(GATE_USB2PHY1,		RCC_USB2PHY1CFGR,	1,	0),
+	GATE_CFG(GATE_USB2PHY2,		RCC_USB2PHY2CFGR,	1,	0),
+	GATE_CFG(GATE_USB3DR,		RCC_USB3DRCFGR,		1,	0),
+	GATE_CFG(GATE_USB3PCIEPHY,	RCC_USB3PCIEPHYCFGR,	1,	0),
+	GATE_CFG(GATE_USBTC,		RCC_USBTCCFGR,		1,	0),
+	GATE_CFG(GATE_VDEC,		RCC_VDECCFGR,		1,	0),
+	GATE_CFG(GATE_VENC,		RCC_VENCCFGR,		1,	0),
+	GATE_CFG(GATE_VREF,		RCC_VREFCFGR,		1,	0),
+	GATE_CFG(GATE_WWDG1,		RCC_WWDG1CFGR,		1,	0),
+	GATE_CFG(GATE_WWDG2,		RCC_WWDG2CFGR,		1,	0),
+};
+
+#define CLK_STM32_GATE(_name, _parent, _flags, _gate_id)\
+struct clk_stm32_gate _name = {\
+	.gate_id = _gate_id,\
+	.hw.init = CLK_HW_INIT(#_name, _parent, &clk_stm32_gate_ops, _flags),\
+}
+
+#define CLK_STM32_MUX(_name, _parents, _flags, _mux_id)\
+struct clk_stm32_mux _name = {\
+	.mux_id = _mux_id,\
+	.hw.init = CLK_HW_INIT_PARENTS(#_name, _parents, &clk_stm32_mux_ops, _flags),\
+}
+
+#define CLK_STM32_DIV(_name, _parent, _flags, _div_id)\
+struct clk_stm32_div _name = {\
+	.div_id = _div_id,\
+	.hw.init = CLK_HW_INIT(#_name, _parent, &clk_stm32_divider_ops, _flags),\
+}
+
+#define CLK_STM32_COMPOSITE(_name, _parents, _flags, _gate_id, _mux_id, _div_id)\
+struct clk_stm32_composite _name = {\
+	.gate_id = _gate_id,\
+	.mux_id = _mux_id,\
+	.div_id = _div_id,\
+	.hw.init = CLK_HW_INIT_PARENTS(#_name, _parents, &clk_stm32_composite_ops, _flags),\
+}
+
+/* ADC */
+static CLK_STM32_GATE(ck_icn_p_adc12, "ck_icn_ls_mcu", 0, GATE_ADC12);
+static CLK_STM32_COMPOSITE(ck_ker_adc12, adc12_src, 0, GATE_ADC12, MUX_ADC12, NO_STM32_DIV);
+static CLK_STM32_GATE(ck_icn_p_adc3, "ck_icn_ls_mcu", 0, GATE_ADC3);
+static CLK_STM32_COMPOSITE(ck_ker_adc3, adc3_src, 0, GATE_ADC3, MUX_ADC3, NO_STM32_DIV);
+
+/* ADF */
+static CLK_STM32_GATE(ck_icn_p_adf1, "ck_icn_ls_mcu", 0, GATE_ADF1);
+static CLK_STM32_GATE(ck_ker_adf1, "ck_flexgen_42", 0, GATE_ADF1);
+
+/* DCMI */
+static CLK_STM32_GATE(ck_icn_p_cci, "ck_icn_ls_mcu", 0, GATE_CCI);
+
+/* CSI-HOST */
+static CLK_STM32_GATE(ck_icn_p_csi, "ck_icn_apb4", 0, GATE_CSI);
+static CLK_STM32_GATE(ck_ker_csi, "ck_flexgen_29", 0, GATE_CSI);
+static CLK_STM32_GATE(ck_ker_csitxesc, "ck_flexgen_30", 0, GATE_CSI);
+
+/* CSI-PHY */
+static CLK_STM32_GATE(ck_ker_csiphy, "ck_flexgen_31", 0, GATE_CSI);
+
+/* DCMIPP */
+static CLK_STM32_GATE(ck_icn_p_dcmipp, "ck_icn_apb4", 0, GATE_DCMIPP);
+
+/* CRC */
+static CLK_STM32_GATE(ck_icn_p_crc, "ck_icn_ls_mcu", 0, GATE_CRC);
+
+/* CRYP */
+static CLK_STM32_GATE(ck_icn_p_cryp1, "ck_icn_ls_mcu", 0, GATE_CRYP1);
+static CLK_STM32_GATE(ck_icn_p_cryp2, "ck_icn_ls_mcu", 0, GATE_CRYP2);
+
+/* DBG & TRACE*/
+/* Trace and debug clocks are managed by SCMI */
+
+/* LTDC */
+static CLK_STM32_GATE(ck_icn_p_ltdc, "ck_icn_apb4", 0, GATE_LTDC);
+static CLK_STM32_GATE(ck_ker_ltdc, "ck_flexgen_27", CLK_SET_RATE_PARENT, GATE_LTDC);
+
+/* DSI */
+static CLK_STM32_GATE(ck_icn_p_dsi, "ck_icn_apb4", 0, GATE_DSI);
+static CLK_STM32_COMPOSITE(clk_lanebyte, dsiblane_src, 0, GATE_DSI, MUX_DSIBLANE, NO_STM32_DIV);
+
+/* LVDS */
+static CLK_STM32_GATE(ck_icn_p_lvds, "ck_icn_apb4", 0, GATE_LVDS);
+
+/* DSI PHY */
+static CLK_STM32_COMPOSITE(clk_phy_dsi, dsiphy_src, 0, GATE_DSI, MUX_DSIPHY, NO_STM32_DIV);
+
+/* LVDS PHY */
+static CLK_STM32_COMPOSITE(ck_ker_lvdsphy, lvdsphy_src, 0, GATE_LVDS, MUX_LVDSPHY, NO_STM32_DIV);
+
+/* DTS */
+static CLK_STM32_COMPOSITE(ck_ker_dts, dts_src, 0, GATE_DTS, MUX_DTS, NO_STM32_DIV);
+
+/* ETHERNET */
+static CLK_STM32_GATE(ck_icn_p_eth1, "ck_icn_ls_mcu", 0, GATE_ETH1);
+static CLK_STM32_GATE(ck_ker_eth1stp, "ck_icn_ls_mcu", 0, GATE_ETH1STP);
+static CLK_STM32_GATE(ck_ker_eth1, "ck_flexgen_54", 0, GATE_ETH1);
+static CLK_STM32_GATE(ck_ker_eth1ptp, "ck_flexgen_56", 0, GATE_ETH1);
+static CLK_STM32_GATE(ck_ker_eth1mac, "ck_icn_ls_mcu", 0, GATE_ETH1MAC);
+static CLK_STM32_GATE(ck_ker_eth1tx, "ck_icn_ls_mcu", 0, GATE_ETH1TX);
+static CLK_STM32_GATE(ck_ker_eth1rx, "ck_icn_ls_mcu", 0, GATE_ETH1RX);
+
+static CLK_STM32_GATE(ck_icn_p_eth2, "ck_icn_ls_mcu", 0, GATE_ETH2);
+static CLK_STM32_GATE(ck_ker_eth2stp, "ck_icn_ls_mcu", 0, GATE_ETH2STP);
+static CLK_STM32_GATE(ck_ker_eth2, "ck_flexgen_55", 0, GATE_ETH2);
+static CLK_STM32_GATE(ck_ker_eth2ptp, "ck_flexgen_56", 0, GATE_ETH2);
+static CLK_STM32_GATE(ck_ker_eth2mac, "ck_icn_ls_mcu", 0, GATE_ETH2MAC);
+static CLK_STM32_GATE(ck_ker_eth2tx, "ck_icn_ls_mcu", 0, GATE_ETH2TX);
+static CLK_STM32_GATE(ck_ker_eth2rx, "ck_icn_ls_mcu", 0, GATE_ETH2RX);
+
+static CLK_STM32_GATE(ck_icn_p_ethsw, "ck_icn_ls_mcu", 0, GATE_ETHSWMAC);
+static CLK_STM32_GATE(ck_ker_ethsw, "ck_flexgen_54", 0, GATE_ETHSW);
+static CLK_STM32_GATE(ck_ker_ethswref, "ck_flexgen_60", 0, GATE_ETHSWREF);
+
+static CLK_STM32_GATE(ck_icn_p_ethsw_acm_cfg, "ck_icn_ls_mcu", 0, GATE_ETHSWACMCFG);
+static CLK_STM32_GATE(ck_icn_p_ethsw_acm_msg, "ck_icn_ls_mcu", 0, GATE_ETHSWACMMSG);
+
+/* FDCAN */
+static CLK_STM32_GATE(ck_icn_p_fdcan, "ck_icn_apb2", 0, GATE_FDCAN);
+static CLK_STM32_GATE(ck_ker_fdcan, "ck_flexgen_26", 0, GATE_FDCAN);
+
+/* GPU */
+static CLK_STM32_GATE(ck_icn_m_gpu, "ck_flexgen_59", 0, GATE_GPU);
+static CLK_STM32_GATE(ck_ker_gpu, "ck_pll3", 0, GATE_GPU);
+
+/* HASH */
+static CLK_STM32_GATE(ck_icn_p_hash, "ck_icn_ls_mcu", 0, GATE_HASH);
+
+/* HDP */
+static CLK_STM32_GATE(ck_icn_p_hdp, "ck_icn_apb3", 0, GATE_HDP);
+
+/* I2C */
+static CLK_STM32_GATE(ck_icn_p_i2c8, "ck_icn_ls_mcu", 0, GATE_I2C8);
+static CLK_STM32_GATE(ck_icn_p_i2c1, "ck_icn_apb1", 0, GATE_I2C1);
+static CLK_STM32_GATE(ck_icn_p_i2c2, "ck_icn_apb1", 0, GATE_I2C2);
+static CLK_STM32_GATE(ck_icn_p_i2c3, "ck_icn_apb1", 0, GATE_I2C3);
+static CLK_STM32_GATE(ck_icn_p_i2c4, "ck_icn_apb1", 0, GATE_I2C4);
+static CLK_STM32_GATE(ck_icn_p_i2c5, "ck_icn_apb1", 0, GATE_I2C5);
+static CLK_STM32_GATE(ck_icn_p_i2c6, "ck_icn_apb1", 0, GATE_I2C6);
+static CLK_STM32_GATE(ck_icn_p_i2c7, "ck_icn_apb1", 0, GATE_I2C7);
+
+static CLK_STM32_GATE(ck_ker_i2c1, "ck_flexgen_12", 0, GATE_I2C1);
+static CLK_STM32_GATE(ck_ker_i2c2, "ck_flexgen_12", 0, GATE_I2C2);
+static CLK_STM32_GATE(ck_ker_i2c3, "ck_flexgen_13", 0, GATE_I2C3);
+static CLK_STM32_GATE(ck_ker_i2c5, "ck_flexgen_13", 0, GATE_I2C5);
+static CLK_STM32_GATE(ck_ker_i2c4, "ck_flexgen_14", 0, GATE_I2C4);
+static CLK_STM32_GATE(ck_ker_i2c6, "ck_flexgen_14", 0, GATE_I2C6);
+static CLK_STM32_GATE(ck_ker_i2c7, "ck_flexgen_15", 0, GATE_I2C7);
+static CLK_STM32_GATE(ck_ker_i2c8, "ck_flexgen_38", 0, GATE_I2C8);
+
+/* I3C */
+static CLK_STM32_GATE(ck_icn_p_i3c1, "ck_icn_apb1", 0, GATE_I3C1);
+static CLK_STM32_GATE(ck_icn_p_i3c2, "ck_icn_apb1", 0, GATE_I3C2);
+static CLK_STM32_GATE(ck_icn_p_i3c3, "ck_icn_apb1", 0, GATE_I3C3);
+static CLK_STM32_GATE(ck_icn_p_i3c4, "ck_icn_ls_mcu", 0, GATE_I3C4);
+
+static CLK_STM32_GATE(ck_ker_i3c1, "ck_flexgen_12", 0, GATE_I3C1);
+static CLK_STM32_GATE(ck_ker_i3c2, "ck_flexgen_12", 0, GATE_I3C2);
+static CLK_STM32_GATE(ck_ker_i3c3, "ck_flexgen_13", 0, GATE_I3C3);
+static CLK_STM32_GATE(ck_ker_i3c4, "ck_flexgen_36", 0, GATE_I3C4);
+
+/* I2S */
+static CLK_STM32_GATE(ck_icn_p_is2m, "ck_icn_apb3", 0, GATE_IS2M);
+
+/* IWDG */
+static CLK_STM32_GATE(ck_icn_p_iwdg2, "ck_icn_apb3", 0, GATE_IWDG2);
+static CLK_STM32_GATE(ck_icn_p_iwdg3, "ck_icn_apb3", 0, GATE_IWDG3);
+static CLK_STM32_GATE(ck_icn_p_iwdg4, "ck_icn_apb3", 0, GATE_IWDG4);
+static CLK_STM32_GATE(ck_icn_p_iwdg5, "ck_icn_ls_mcu", 0, GATE_IWDG5);
+
+/* LPTIM */
+static CLK_STM32_GATE(ck_icn_p_lptim1, "ck_icn_apb1", 0, GATE_LPTIM1);
+static CLK_STM32_GATE(ck_icn_p_lptim2, "ck_icn_apb1", 0, GATE_LPTIM2);
+static CLK_STM32_GATE(ck_icn_p_lptim3, "ck_icn_ls_mcu", 0, GATE_LPTIM3);
+static CLK_STM32_GATE(ck_icn_p_lptim4, "ck_icn_ls_mcu", 0, GATE_LPTIM4);
+static CLK_STM32_GATE(ck_icn_p_lptim5, "ck_icn_ls_mcu", 0, GATE_LPTIM5);
+
+static CLK_STM32_GATE(ck_ker_lptim1, "ck_flexgen_07", 0, GATE_LPTIM1);
+static CLK_STM32_GATE(ck_ker_lptim2, "ck_flexgen_07", 0, GATE_LPTIM2);
+static CLK_STM32_GATE(ck_ker_lptim3, "ck_flexgen_40", 0, GATE_LPTIM3);
+static CLK_STM32_GATE(ck_ker_lptim4, "ck_flexgen_41", 0, GATE_LPTIM4);
+static CLK_STM32_GATE(ck_ker_lptim5, "ck_flexgen_41", 0, GATE_LPTIM5);
+
+/* LPUART */
+static CLK_STM32_GATE(ck_icn_p_lpuart1, "ck_icn_ls_mcu", 0, GATE_LPUART1);
+static CLK_STM32_GATE(ck_ker_lpuart1, "ck_flexgen_39", 0, GATE_LPUART1);
+
+/* MCO1 & MCO2 */
+static CLK_STM32_COMPOSITE(ck_mco1, mco1_src, 0, GATE_MCO1, MUX_MCO1, NO_STM32_DIV);
+static CLK_STM32_COMPOSITE(ck_mco2, mco2_src, 0, GATE_MCO2, MUX_MCO2, NO_STM32_DIV);
+
+/* MDF */
+static CLK_STM32_GATE(ck_icn_p_mdf1, "ck_icn_ls_mcu", 0, GATE_MDF1);
+static CLK_STM32_GATE(ck_ker_mdf1, "ck_flexgen_23", 0, GATE_MDF1);
+
+/* OSPI */
+static CLK_STM32_GATE(ck_icn_p_ospiiom, "ck_icn_ls_mcu", 0, GATE_OSPIIOM);
+
+/* PCIE */
+static CLK_STM32_GATE(ck_icn_p_pcie, "ck_icn_ls_mcu", 0, GATE_PCIE);
+
+/* SAI */
+static CLK_STM32_GATE(ck_icn_p_sai1, "ck_icn_apb2", 0, GATE_SAI1);
+static CLK_STM32_GATE(ck_icn_p_sai2, "ck_icn_apb2", 0, GATE_SAI2);
+static CLK_STM32_GATE(ck_icn_p_sai3, "ck_icn_apb2", 0, GATE_SAI3);
+static CLK_STM32_GATE(ck_icn_p_sai4, "ck_icn_apb2", 0, GATE_SAI4);
+static CLK_STM32_GATE(ck_ker_sai1, "ck_flexgen_23", CLK_SET_RATE_PARENT, GATE_SAI1);
+static CLK_STM32_GATE(ck_ker_sai2, "ck_flexgen_24", CLK_SET_RATE_PARENT, GATE_SAI2);
+static CLK_STM32_GATE(ck_ker_sai3, "ck_flexgen_25", CLK_SET_RATE_PARENT, GATE_SAI3);
+static CLK_STM32_GATE(ck_ker_sai4, "ck_flexgen_25", CLK_SET_RATE_PARENT, GATE_SAI4);
+
+/* SDMMC */
+static CLK_STM32_GATE(ck_icn_m_sdmmc1, "ck_icn_sdmmc", 0, GATE_SDMMC1);
+static CLK_STM32_GATE(ck_icn_m_sdmmc2, "ck_icn_sdmmc", 0, GATE_SDMMC2);
+static CLK_STM32_GATE(ck_icn_m_sdmmc3, "ck_icn_sdmmc", 0, GATE_SDMMC3);
+static CLK_STM32_GATE(ck_ker_sdmmc1, "ck_flexgen_51", 0, GATE_SDMMC1);
+static CLK_STM32_GATE(ck_ker_sdmmc2, "ck_flexgen_52", 0, GATE_SDMMC2);
+static CLK_STM32_GATE(ck_ker_sdmmc3, "ck_flexgen_53", 0, GATE_SDMMC3);
+
+/* SERC */
+static CLK_STM32_GATE(ck_icn_p_serc, "ck_icn_apb3", 0, GATE_SERC);
+
+/* SPDIF */
+static CLK_STM32_GATE(ck_icn_p_spdifrx, "ck_icn_apb1", 0, GATE_SPDIFRX);
+static CLK_STM32_GATE(ck_ker_spdifrx, "ck_flexgen_11", 0, GATE_SPDIFRX);
+
+/* SPI */
+static CLK_STM32_GATE(ck_icn_p_spi1, "ck_icn_apb2", 0, GATE_SPI1);
+static CLK_STM32_GATE(ck_icn_p_spi2, "ck_icn_apb1", 0, GATE_SPI2);
+static CLK_STM32_GATE(ck_icn_p_spi3, "ck_icn_apb1", 0, GATE_SPI3);
+static CLK_STM32_GATE(ck_icn_p_spi4, "ck_icn_apb2", 0, GATE_SPI4);
+static CLK_STM32_GATE(ck_icn_p_spi5, "ck_icn_apb2", 0, GATE_SPI5);
+static CLK_STM32_GATE(ck_icn_p_spi6, "ck_icn_apb2", 0, GATE_SPI6);
+static CLK_STM32_GATE(ck_icn_p_spi7, "ck_icn_apb2", 0, GATE_SPI7);
+static CLK_STM32_GATE(ck_icn_p_spi8, "ck_icn_ls_mcu", 0, GATE_SPI8);
+
+static CLK_STM32_GATE(ck_ker_spi1, "ck_flexgen_16", CLK_SET_RATE_PARENT, GATE_SPI1);
+static CLK_STM32_GATE(ck_ker_spi2, "ck_flexgen_10", CLK_SET_RATE_PARENT, GATE_SPI2);
+static CLK_STM32_GATE(ck_ker_spi3, "ck_flexgen_10", CLK_SET_RATE_PARENT, GATE_SPI3);
+static CLK_STM32_GATE(ck_ker_spi4, "ck_flexgen_17", 0, GATE_SPI4);
+static CLK_STM32_GATE(ck_ker_spi5, "ck_flexgen_17", 0, GATE_SPI5);
+static CLK_STM32_GATE(ck_ker_spi6, "ck_flexgen_18", 0, GATE_SPI6);
+static CLK_STM32_GATE(ck_ker_spi7, "ck_flexgen_18", 0, GATE_SPI7);
+static CLK_STM32_GATE(ck_ker_spi8, "ck_flexgen_37", 0, GATE_SPI8);
+
+/* Timers */
+static CLK_STM32_GATE(ck_icn_p_tim2, "ck_icn_apb1", 0, GATE_TIM2);
+static CLK_STM32_GATE(ck_icn_p_tim3, "ck_icn_apb1", 0, GATE_TIM3);
+static CLK_STM32_GATE(ck_icn_p_tim4, "ck_icn_apb1", 0, GATE_TIM4);
+static CLK_STM32_GATE(ck_icn_p_tim5, "ck_icn_apb1", 0, GATE_TIM5);
+static CLK_STM32_GATE(ck_icn_p_tim6, "ck_icn_apb1", 0, GATE_TIM6);
+static CLK_STM32_GATE(ck_icn_p_tim7, "ck_icn_apb1", 0, GATE_TIM7);
+static CLK_STM32_GATE(ck_icn_p_tim10, "ck_icn_apb1", 0, GATE_TIM10);
+static CLK_STM32_GATE(ck_icn_p_tim11, "ck_icn_apb1", 0, GATE_TIM11);
+static CLK_STM32_GATE(ck_icn_p_tim12, "ck_icn_apb1", 0, GATE_TIM12);
+static CLK_STM32_GATE(ck_icn_p_tim13, "ck_icn_apb1", 0, GATE_TIM13);
+static CLK_STM32_GATE(ck_icn_p_tim14, "ck_icn_apb1", 0, GATE_TIM14);
+
+static CLK_STM32_GATE(ck_icn_p_tim1, "ck_icn_apb2", 0, GATE_TIM1);
+static CLK_STM32_GATE(ck_icn_p_tim8, "ck_icn_apb2", 0, GATE_TIM8);
+static CLK_STM32_GATE(ck_icn_p_tim15, "ck_icn_apb2", 0, GATE_TIM15);
+static CLK_STM32_GATE(ck_icn_p_tim16, "ck_icn_apb2", 0, GATE_TIM16);
+static CLK_STM32_GATE(ck_icn_p_tim17, "ck_icn_apb2", 0, GATE_TIM17);
+static CLK_STM32_GATE(ck_icn_p_tim20, "ck_icn_apb2", 0, GATE_TIM20);
+
+static CLK_STM32_GATE(ck_ker_tim2, "timg1_ck", 0, GATE_TIM2);
+static CLK_STM32_GATE(ck_ker_tim3, "timg1_ck", 0, GATE_TIM3);
+static CLK_STM32_GATE(ck_ker_tim4, "timg1_ck", 0, GATE_TIM4);
+static CLK_STM32_GATE(ck_ker_tim5, "timg1_ck", 0, GATE_TIM5);
+static CLK_STM32_GATE(ck_ker_tim6, "timg1_ck", 0, GATE_TIM6);
+static CLK_STM32_GATE(ck_ker_tim7, "timg1_ck", 0, GATE_TIM7);
+static CLK_STM32_GATE(ck_ker_tim10, "timg1_ck", 0, GATE_TIM10);
+static CLK_STM32_GATE(ck_ker_tim11, "timg1_ck", 0, GATE_TIM11);
+static CLK_STM32_GATE(ck_ker_tim12, "timg1_ck", 0, GATE_TIM12);
+static CLK_STM32_GATE(ck_ker_tim13, "timg1_ck", 0, GATE_TIM13);
+static CLK_STM32_GATE(ck_ker_tim14, "timg1_ck", 0, GATE_TIM14);
+
+static CLK_STM32_GATE(ck_ker_tim1, "timg2_ck", 0, GATE_TIM1);
+static CLK_STM32_GATE(ck_ker_tim8, "timg2_ck", 0, GATE_TIM8);
+static CLK_STM32_GATE(ck_ker_tim15, "timg2_ck", 0, GATE_TIM15);
+static CLK_STM32_GATE(ck_ker_tim16, "timg2_ck", 0, GATE_TIM16);
+static CLK_STM32_GATE(ck_ker_tim17, "timg2_ck", 0, GATE_TIM17);
+static CLK_STM32_GATE(ck_ker_tim20, "timg2_ck", 0, GATE_TIM20);
+
+/* UART/USART */
+static CLK_STM32_GATE(ck_icn_p_usart2, "ck_icn_apb1", 0, GATE_USART2);
+static CLK_STM32_GATE(ck_icn_p_usart3, "ck_icn_apb1", 0, GATE_USART3);
+static CLK_STM32_GATE(ck_icn_p_uart4, "ck_icn_apb1", 0, GATE_UART4);
+static CLK_STM32_GATE(ck_icn_p_uart5, "ck_icn_apb1", 0, GATE_UART5);
+static CLK_STM32_GATE(ck_icn_p_usart1, "ck_icn_apb2", 0, GATE_USART1);
+static CLK_STM32_GATE(ck_icn_p_usart6, "ck_icn_apb2", 0, GATE_USART6);
+static CLK_STM32_GATE(ck_icn_p_uart7, "ck_icn_apb2", 0, GATE_UART7);
+static CLK_STM32_GATE(ck_icn_p_uart8, "ck_icn_apb2", 0, GATE_UART8);
+static CLK_STM32_GATE(ck_icn_p_uart9, "ck_icn_apb2", 0, GATE_UART9);
+
+static CLK_STM32_GATE(ck_ker_usart2, "ck_flexgen_08", 0, GATE_USART2);
+static CLK_STM32_GATE(ck_ker_uart4, "ck_flexgen_08", 0, GATE_UART4);
+static CLK_STM32_GATE(ck_ker_usart3, "ck_flexgen_09", 0, GATE_USART3);
+static CLK_STM32_GATE(ck_ker_uart5, "ck_flexgen_09", 0, GATE_UART5);
+static CLK_STM32_GATE(ck_ker_usart1, "ck_flexgen_19", 0, GATE_USART1);
+static CLK_STM32_GATE(ck_ker_usart6, "ck_flexgen_20", 0, GATE_USART6);
+static CLK_STM32_GATE(ck_ker_uart7, "ck_flexgen_21", 0, GATE_UART7);
+static CLK_STM32_GATE(ck_ker_uart8, "ck_flexgen_21", 0, GATE_UART8);
+static CLK_STM32_GATE(ck_ker_uart9, "ck_flexgen_22", 0, GATE_UART9);
+
+/* USB2PHY1 */
+static CLK_STM32_COMPOSITE(ck_ker_usb2phy1, usb2phy1_src, 0,
+			   GATE_USB2PHY1, MUX_USB2PHY1, NO_STM32_DIV);
+
+/* USB2H */
+static CLK_STM32_GATE(ck_icn_m_usb2ehci, "ck_icn_hsl", 0, GATE_USB2);
+static CLK_STM32_GATE(ck_icn_m_usb2ohci, "ck_icn_hsl", 0, GATE_USB2);
+
+/* USB2PHY2 */
+static CLK_STM32_COMPOSITE(ck_ker_usb2phy2_en, usb2phy2_src, 0,
+			   GATE_USB2PHY2, MUX_USB2PHY2, NO_STM32_DIV);
+
+/* USB3 PCIe COMBOPHY */
+static CLK_STM32_GATE(ck_icn_p_usb3pciephy, "ck_icn_apb4", 0, GATE_USB3PCIEPHY);
+
+static CLK_STM32_COMPOSITE(ck_ker_usb3pciephy, usb3pciphy_src, 0,
+			   GATE_USB3PCIEPHY, MUX_USB3PCIEPHY, NO_STM32_DIV);
+
+/* USB3 DRD */
+static CLK_STM32_GATE(ck_icn_m_usb3dr, "ck_icn_hsl", 0, GATE_USB3DR);
+static CLK_STM32_GATE(ck_ker_usb2phy2, "ck_flexgen_58", 0, GATE_USB3DR);
+
+/* USBTC */
+static CLK_STM32_GATE(ck_icn_p_usbtc, "ck_icn_apb4", 0, GATE_USBTC);
+static CLK_STM32_GATE(ck_ker_usbtc, "ck_flexgen_35", 0, GATE_USBTC);
+
+/* VDEC / VENC */
+static CLK_STM32_GATE(ck_icn_p_vdec, "ck_icn_apb4", 0, GATE_VDEC);
+static CLK_STM32_GATE(ck_icn_p_venc, "ck_icn_apb4", 0, GATE_VENC);
+
+/* VREF */
+static CLK_STM32_GATE(ck_icn_p_vref, "ck_icn_apb3", 0, GATE_VREF);
+
+/* WWDG */
+static CLK_STM32_GATE(ck_icn_p_wwdg1, "ck_icn_apb3", 0, GATE_WWDG1);
+static CLK_STM32_GATE(ck_icn_p_wwdg2, "ck_icn_ls_mcu", 0, GATE_WWDG2);
+
+enum security_clk {
+	SECF_NONE,
+};
+
+static const struct clock_config stm32mp25_clock_cfg[] = {
+	STM32_GATE_CFG(CK_BUS_ETH1,		ck_icn_p_eth1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETH2,		ck_icn_p_eth2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_PCIE,		ck_icn_p_pcie,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETHSW,		ck_icn_p_ethsw,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ADC12,		ck_icn_p_adc12,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ADC3,		ck_icn_p_adc3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CCI,		ck_icn_p_cci,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CRC,		ck_icn_p_crc,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_MDF1,		ck_icn_p_mdf1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_OSPIIOM,		ck_icn_p_ospiiom,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_HASH,		ck_icn_p_hash,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CRYP1,		ck_icn_p_cryp1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CRYP2,		ck_icn_p_cryp2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ADF1,		ck_icn_p_adf1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI8,		ck_icn_p_spi8,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPUART1,		ck_icn_p_lpuart1,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C8,		ck_icn_p_i2c8,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM3,		ck_icn_p_lptim3,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM4,		ck_icn_p_lptim4,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM5,		ck_icn_p_lptim5,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IWDG5,		ck_icn_p_iwdg5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_WWDG2,		ck_icn_p_wwdg2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I3C4,		ck_icn_p_i3c4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SDMMC1,		ck_icn_m_sdmmc1,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SDMMC2,		ck_icn_m_sdmmc2,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SDMMC3,		ck_icn_m_sdmmc3,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USB2OHCI,		ck_icn_m_usb2ohci,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USB2EHCI,		ck_icn_m_usb2ehci,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USB3DR,		ck_icn_m_usb3dr,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM2,		ck_icn_p_tim2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM3,		ck_icn_p_tim3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM4,		ck_icn_p_tim4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM5,		ck_icn_p_tim5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM6,		ck_icn_p_tim6,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM7,		ck_icn_p_tim7,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM10,		ck_icn_p_tim10,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM11,		ck_icn_p_tim11,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM12,		ck_icn_p_tim12,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM13,		ck_icn_p_tim13,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM14,		ck_icn_p_tim14,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM1,		ck_icn_p_lptim1,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM2,		ck_icn_p_lptim2,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI2,		ck_icn_p_spi2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI3,		ck_icn_p_spi3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPDIFRX,		ck_icn_p_spdifrx,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USART2,		ck_icn_p_usart2,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USART3,		ck_icn_p_usart3,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART4,		ck_icn_p_uart4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART5,		ck_icn_p_uart5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C1,		ck_icn_p_i2c1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C2,		ck_icn_p_i2c2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C3,		ck_icn_p_i2c3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C4,		ck_icn_p_i2c4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C5,		ck_icn_p_i2c5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C6,		ck_icn_p_i2c6,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C7,		ck_icn_p_i2c7,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I3C1,		ck_icn_p_i3c1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I3C2,		ck_icn_p_i3c2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I3C3,		ck_icn_p_i3c3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM1,		ck_icn_p_tim1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM8,		ck_icn_p_tim8,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM15,		ck_icn_p_tim15,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM16,		ck_icn_p_tim16,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM17,		ck_icn_p_tim17,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM20,		ck_icn_p_tim20,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SAI1,		ck_icn_p_sai1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SAI2,		ck_icn_p_sai2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SAI3,		ck_icn_p_sai3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SAI4,		ck_icn_p_sai4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USART1,		ck_icn_p_usart1,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USART6,		ck_icn_p_usart6,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART7,		ck_icn_p_uart7,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART8,		ck_icn_p_uart8,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART9,		ck_icn_p_uart9,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_FDCAN,		ck_icn_p_fdcan,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI1,		ck_icn_p_spi1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI4,		ck_icn_p_spi4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI5,		ck_icn_p_spi5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI6,		ck_icn_p_spi6,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI7,		ck_icn_p_spi7,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IWDG2,		ck_icn_p_iwdg2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IWDG3,		ck_icn_p_iwdg3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IWDG4,		ck_icn_p_iwdg4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_WWDG1,		ck_icn_p_wwdg1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_VREF,		ck_icn_p_vref,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SERC,		ck_icn_p_serc,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_HDP,		ck_icn_p_hdp,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IS2M,		ck_icn_p_is2m,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_DSI,		ck_icn_p_dsi,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LTDC,		ck_icn_p_ltdc,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CSI,		ck_icn_p_csi,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_DCMIPP,		ck_icn_p_dcmipp,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LVDS,		ck_icn_p_lvds,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USBTC,		ck_icn_p_usbtc,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USB3PCIEPHY,	ck_icn_p_usb3pciephy,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_VDEC,		ck_icn_p_vdec,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_VENC,		ck_icn_p_venc,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM2,		ck_ker_tim2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM3,		ck_ker_tim3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM4,		ck_ker_tim4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM5,		ck_ker_tim5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM6,		ck_ker_tim6,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM7,		ck_ker_tim7,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM10,		ck_ker_tim10,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM11,		ck_ker_tim11,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM12,		ck_ker_tim12,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM13,		ck_ker_tim13,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM14,		ck_ker_tim14,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM1,		ck_ker_tim1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM8,		ck_ker_tim8,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM15,		ck_ker_tim15,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM16,		ck_ker_tim16,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM17,		ck_ker_tim17,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM20,		ck_ker_tim20,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM1,		ck_ker_lptim1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM2,		ck_ker_lptim2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USART2,		ck_ker_usart2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART4,		ck_ker_uart4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USART3,		ck_ker_usart3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART5,		ck_ker_uart5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI2,		ck_ker_spi2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI3,		ck_ker_spi3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPDIFRX,		ck_ker_spdifrx,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C1,		ck_ker_i2c1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C2,		ck_ker_i2c2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I3C1,		ck_ker_i3c1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I3C2,		ck_ker_i3c2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C3,		ck_ker_i2c3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C5,		ck_ker_i2c5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I3C3,		ck_ker_i3c3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C4,		ck_ker_i2c4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C6,		ck_ker_i2c6,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C7,		ck_ker_i2c7,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI1,		ck_ker_spi1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI4,		ck_ker_spi4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI5,		ck_ker_spi5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI6,		ck_ker_spi6,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI7,		ck_ker_spi7,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USART1,		ck_ker_usart1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USART6,		ck_ker_usart6,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART7,		ck_ker_uart7,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART8,		ck_ker_uart8,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART9,		ck_ker_uart9,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_MDF1,		ck_ker_mdf1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SAI1,		ck_ker_sai1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SAI2,		ck_ker_sai2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SAI3,		ck_ker_sai3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SAI4,		ck_ker_sai4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_FDCAN,		ck_ker_fdcan,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_CSI,		ck_ker_csi,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_CSITXESC,		ck_ker_csitxesc,	SECF_NONE),
+	STM32_GATE_CFG(CK_KER_CSIPHY,		ck_ker_csiphy,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USBTC,		ck_ker_usbtc,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I3C4,		ck_ker_i3c4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI8,		ck_ker_spi8,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C8,		ck_ker_i2c8,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPUART1,		ck_ker_lpuart1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM3,		ck_ker_lptim3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM4,		ck_ker_lptim4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM5,		ck_ker_lptim5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ADF1,		ck_ker_adf1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SDMMC1,		ck_ker_sdmmc1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SDMMC2,		ck_ker_sdmmc2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SDMMC3,		ck_ker_sdmmc3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETH1,		ck_ker_eth1,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH1_STP,		ck_ker_eth1stp,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETHSW,		ck_ker_ethsw,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETH2,		ck_ker_eth2,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH2_STP,		ck_ker_eth2stp,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETH1PTP,		ck_ker_eth1ptp,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETH2PTP,		ck_ker_eth2ptp,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_GPU,		ck_icn_m_gpu,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_GPU,		ck_ker_gpu,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETHSWREF,		ck_ker_ethswref,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETHSWACMCFG,	ck_icn_p_ethsw_acm_cfg,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETHSWACMMSG, ck_icn_p_ethsw_acm_msg,	SECF_NONE),
+	STM32_GATE_CFG(CK_ETH1_MAC,		ck_ker_eth1mac,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH1_TX,		ck_ker_eth1tx,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH1_RX,		ck_ker_eth1rx,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH2_MAC,		ck_ker_eth2mac,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH2_TX,		ck_ker_eth2tx,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH2_RX,		ck_ker_eth2rx,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_MCO1,		ck_mco1,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_MCO2,		ck_mco2,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_ADC12,	ck_ker_adc12,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_ADC3,	ck_ker_adc3,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_USB2PHY1,	ck_ker_usb2phy1,	SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USB2PHY2,		ck_ker_usb2phy2,	SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_USB2PHY2EN,	ck_ker_usb2phy2_en,	SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_USB3PCIEPHY,	ck_ker_usb3pciephy,	SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_DSIBLANE,	clk_lanebyte,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_DSIPHY,	clk_phy_dsi,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_LVDSPHY,	ck_ker_lvdsphy,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_DTS,		ck_ker_dts,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LTDC,		ck_ker_ltdc,		SECF_NONE),
+};
+
+#define RESET_MP25(id, _offset, _bit_idx, _set_clr)\
+	[id] = &(struct stm32_reset_cfg){\
+		.offset		= (_offset),\
+		.bit_idx	= (_bit_idx),\
+		.set_clr	= (_set_clr),\
+	}
+
+static const struct stm32_reset_cfg *stm32mp25_reset_cfg[STM32MP25_LAST_RESET] = {
+	RESET_MP25(TIM1_R,		RCC_TIM1CFGR,		0,	0),
+	RESET_MP25(TIM2_R,		RCC_TIM2CFGR,		0,	0),
+	RESET_MP25(TIM3_R,		RCC_TIM3CFGR,		0,	0),
+	RESET_MP25(TIM4_R,		RCC_TIM4CFGR,		0,	0),
+	RESET_MP25(TIM5_R,		RCC_TIM5CFGR,		0,	0),
+	RESET_MP25(TIM6_R,		RCC_TIM6CFGR,		0,	0),
+	RESET_MP25(TIM7_R,		RCC_TIM7CFGR,		0,	0),
+	RESET_MP25(TIM8_R,		RCC_TIM8CFGR,		0,	0),
+	RESET_MP25(TIM10_R,		RCC_TIM10CFGR,		0,	0),
+	RESET_MP25(TIM11_R,		RCC_TIM11CFGR,		0,	0),
+	RESET_MP25(TIM12_R,		RCC_TIM12CFGR,		0,	0),
+	RESET_MP25(TIM13_R,		RCC_TIM13CFGR,		0,	0),
+	RESET_MP25(TIM14_R,		RCC_TIM14CFGR,		0,	0),
+	RESET_MP25(TIM15_R,		RCC_TIM15CFGR,		0,	0),
+	RESET_MP25(TIM16_R,		RCC_TIM16CFGR,		0,	0),
+	RESET_MP25(TIM17_R,		RCC_TIM17CFGR,		0,	0),
+	RESET_MP25(TIM20_R,		RCC_TIM20CFGR,		0,	0),
+	RESET_MP25(LPTIM1_R,		RCC_LPTIM1CFGR,		0,	0),
+	RESET_MP25(LPTIM2_R,		RCC_LPTIM2CFGR,		0,	0),
+	RESET_MP25(LPTIM3_R,		RCC_LPTIM3CFGR,		0,	0),
+	RESET_MP25(LPTIM4_R,		RCC_LPTIM4CFGR,		0,	0),
+	RESET_MP25(LPTIM5_R,		RCC_LPTIM5CFGR,		0,	0),
+	RESET_MP25(SPI1_R,		RCC_SPI1CFGR,		0,	0),
+	RESET_MP25(SPI2_R,		RCC_SPI2CFGR,		0,	0),
+	RESET_MP25(SPI3_R,		RCC_SPI3CFGR,		0,	0),
+	RESET_MP25(SPI4_R,		RCC_SPI4CFGR,		0,	0),
+	RESET_MP25(SPI5_R,		RCC_SPI5CFGR,		0,	0),
+	RESET_MP25(SPI6_R,		RCC_SPI6CFGR,		0,	0),
+	RESET_MP25(SPI7_R,		RCC_SPI7CFGR,		0,	0),
+	RESET_MP25(SPI8_R,		RCC_SPI8CFGR,		0,	0),
+	RESET_MP25(SPDIFRX_R,		RCC_SPDIFRXCFGR,	0,	0),
+	RESET_MP25(USART1_R,		RCC_USART1CFGR,		0,	0),
+	RESET_MP25(USART2_R,		RCC_USART2CFGR,		0,	0),
+	RESET_MP25(USART3_R,		RCC_USART3CFGR,		0,	0),
+	RESET_MP25(UART4_R,		RCC_UART4CFGR,		0,	0),
+	RESET_MP25(UART5_R,		RCC_UART5CFGR,		0,	0),
+	RESET_MP25(USART6_R,		RCC_USART6CFGR,		0,	0),
+	RESET_MP25(UART7_R,		RCC_UART7CFGR,		0,	0),
+	RESET_MP25(UART8_R,		RCC_UART8CFGR,		0,	0),
+	RESET_MP25(UART9_R,		RCC_UART9CFGR,		0,	0),
+	RESET_MP25(LPUART1_R,		RCC_LPUART1CFGR,	0,	0),
+	RESET_MP25(IS2M_R,		RCC_IS2MCFGR,		0,	0),
+	RESET_MP25(I2C1_R,		RCC_I2C1CFGR,		0,	0),
+	RESET_MP25(I2C2_R,		RCC_I2C2CFGR,		0,	0),
+	RESET_MP25(I2C3_R,		RCC_I2C3CFGR,		0,	0),
+	RESET_MP25(I2C4_R,		RCC_I2C4CFGR,		0,	0),
+	RESET_MP25(I2C5_R,		RCC_I2C5CFGR,		0,	0),
+	RESET_MP25(I2C6_R,		RCC_I2C6CFGR,		0,	0),
+	RESET_MP25(I2C7_R,		RCC_I2C7CFGR,		0,	0),
+	RESET_MP25(I2C8_R,		RCC_I2C8CFGR,		0,	0),
+	RESET_MP25(SAI1_R,		RCC_SAI1CFGR,		0,	0),
+	RESET_MP25(SAI2_R,		RCC_SAI2CFGR,		0,	0),
+	RESET_MP25(SAI3_R,		RCC_SAI3CFGR,		0,	0),
+	RESET_MP25(SAI4_R,		RCC_SAI4CFGR,		0,	0),
+	RESET_MP25(MDF1_R,		RCC_MDF1CFGR,		0,	0),
+	RESET_MP25(MDF2_R,		RCC_ADF1CFGR,		0,	0),
+	RESET_MP25(FDCAN_R,		RCC_FDCANCFGR,		0,	0),
+	RESET_MP25(HDP_R,		RCC_HDPCFGR,		0,	0),
+	RESET_MP25(ADC12_R,		RCC_ADC12CFGR,		0,	0),
+	RESET_MP25(ADC3_R,		RCC_ADC3CFGR,		0,	0),
+	RESET_MP25(ETH1_R,		RCC_ETH1CFGR,		0,	0),
+	RESET_MP25(ETH2_R,		RCC_ETH2CFGR,		0,	0),
+	RESET_MP25(USB2_R,		RCC_USB2CFGR,		0,	0),
+	RESET_MP25(USB2PHY1_R,		RCC_USB2PHY1CFGR,	0,	0),
+	RESET_MP25(USB2PHY2_R,		RCC_USB2PHY2CFGR,	0,	0),
+	RESET_MP25(USB3DR_R,		RCC_USB3DRCFGR,		0,	0),
+	RESET_MP25(USB3PCIEPHY_R,	RCC_USB3PCIEPHYCFGR,	0,	0),
+	RESET_MP25(USBTC_R,		RCC_USBTCCFGR,		0,	0),
+	RESET_MP25(ETHSW_R,		RCC_ETHSWCFGR,		0,	0),
+	RESET_MP25(SDMMC1_R,		RCC_SDMMC1CFGR,		0,	0),
+	RESET_MP25(SDMMC1DLL_R,		RCC_SDMMC1CFGR,		16,	0),
+	RESET_MP25(SDMMC2_R,		RCC_SDMMC2CFGR,		0,	0),
+	RESET_MP25(SDMMC2DLL_R,		RCC_SDMMC2CFGR,		16,	0),
+	RESET_MP25(SDMMC3_R,		RCC_SDMMC3CFGR,		0,	0),
+	RESET_MP25(SDMMC3DLL_R,		RCC_SDMMC3CFGR,		16,	0),
+	RESET_MP25(GPU_R,		RCC_GPUCFGR,		0,	0),
+	RESET_MP25(LTDC_R,		RCC_LTDCCFGR,		0,	0),
+	RESET_MP25(DSI_R,		RCC_DSICFGR,		0,	0),
+	RESET_MP25(LVDS_R,		RCC_LVDSCFGR,		0,	0),
+	RESET_MP25(CSI_R,		RCC_CSICFGR,		0,	0),
+	RESET_MP25(DCMIPP_R,		RCC_DCMIPPCFGR,		0,	0),
+	RESET_MP25(CCI_R,		RCC_CCICFGR,		0,	0),
+	RESET_MP25(VDEC_R,		RCC_VDECCFGR,		0,	0),
+	RESET_MP25(VENC_R,		RCC_VENCCFGR,		0,	0),
+	RESET_MP25(WWDG1_R,		RCC_WWDG1CFGR,		0,	0),
+	RESET_MP25(WWDG2_R,		RCC_WWDG2CFGR,		0,	0),
+	RESET_MP25(VREF_R,		RCC_VREFCFGR,		0,	0),
+	RESET_MP25(DTS_R,		RCC_DTSCFGR,		0,	0),
+	RESET_MP25(CRC_R,		RCC_CRCCFGR,		0,	0),
+	RESET_MP25(SERC_R,		RCC_SERCCFGR,		0,	0),
+	RESET_MP25(OSPIIOM_R,		RCC_OSPIIOMCFGR,	0,	0),
+	RESET_MP25(I3C1_R,		RCC_I3C1CFGR,		0,	0),
+	RESET_MP25(I3C2_R,		RCC_I3C2CFGR,		0,	0),
+	RESET_MP25(I3C3_R,		RCC_I3C3CFGR,		0,	0),
+	RESET_MP25(I3C4_R,		RCC_I3C4CFGR,		0,	0),
+	RESET_MP25(IWDG2_KER_R,		RCC_IWDGC1CFGSETR,	18,	1),
+	RESET_MP25(IWDG4_KER_R,		RCC_IWDGC2CFGSETR,	18,	1),
+	RESET_MP25(RNG_R,		RCC_RNGCFGR,		0,	0),
+	RESET_MP25(PKA_R,		RCC_PKACFGR,		0,	0),
+	RESET_MP25(SAES_R,		RCC_SAESCFGR,		0,	0),
+	RESET_MP25(HASH_R,		RCC_HASHCFGR,		0,	0),
+	RESET_MP25(CRYP1_R,		RCC_CRYP1CFGR,		0,	0),
+	RESET_MP25(CRYP2_R,		RCC_CRYP2CFGR,		0,	0),
+	RESET_MP25(PCIE_R,		RCC_PCIECFGR,		0,	0),
+};
+
+static u16 stm32mp25_cpt_gate[GATE_NB];
+
+static struct clk_stm32_clock_data stm32mp25_clock_data = {
+	.gate_cpt	= stm32mp25_cpt_gate,
+	.gates		= stm32mp25_gates,
+	.muxes		= stm32mp25_muxes,
+};
+
+static struct clk_stm32_reset_data stm32mp25_reset_data = {
+	.reset_lines	= stm32mp25_reset_cfg,
+	.nr_lines	= ARRAY_SIZE(stm32mp25_reset_cfg),
+};
+
+static struct stm32_rcc_match_data stm32mp25_data = {
+	.tab_clocks	= stm32mp25_clock_cfg,
+	.num_clocks	= ARRAY_SIZE(stm32mp25_clock_cfg),
+	.maxbinding	= STM32MP25_LAST_CLK,
+	.clock_data	= &stm32mp25_clock_data,
+	.reset_data	= &stm32mp25_reset_data,
+};
+
+static const struct of_device_id stm32mp25_match_data[] = {
+	{
+		.compatible = "st,stm32mp25-rcc",
+		.data = &stm32mp25_data,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, stm32mp25_match_data);
+
+static int stm32mp25_rcc_init(struct device *dev)
+{
+	void __iomem *base;
+	int ret;
+
+	base = of_iomap(dev_of_node(dev), 0);
+	if (!base) {
+		dev_err(dev, "%pOFn: unable to map resource", dev_of_node(dev));
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	ret = stm32_rcc_init(dev, stm32mp25_match_data, base);
+
+out:
+	if (ret) {
+		if (base)
+			iounmap(base);
+
+		of_node_put(dev_of_node(dev));
+	}
+
+	return ret;
+}
+
+static int get_clock_deps(struct device *dev)
+{
+	static const char * const clock_deps_name[] = {
+		"hsi", "hse", "msi", "lsi", "lse",
+	};
+	size_t deps_size = sizeof(struct clk *) * ARRAY_SIZE(clock_deps_name);
+	struct clk **clk_deps;
+	int i;
+
+	clk_deps = devm_kzalloc(dev, deps_size, GFP_KERNEL);
+	if (!clk_deps)
+		return -ENOMEM;
+
+	for (i = 0; i < ARRAY_SIZE(clock_deps_name); i++) {
+		struct clk *clk;
+
+		clk = of_clk_get_by_name(dev_of_node(dev), clock_deps_name[i]);
+
+		if (IS_ERR(clk)) {
+			if (PTR_ERR(clk) != -EINVAL && PTR_ERR(clk) != -ENOENT)
+				return PTR_ERR(clk);
+		} else {
+			/* Device gets a reference count on the clock */
+			clk_deps[i] = devm_clk_get(dev, __clk_get_name(clk));
+			clk_put(clk);
+		}
+	}
+
+	return 0;
+}
+
+static int stm32mp25_rcc_clocks_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	int ret = get_clock_deps(dev);
+
+	if (!ret)
+		ret = stm32mp25_rcc_init(dev);
+
+	return ret;
+}
+
+static int stm32mp25_rcc_clocks_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *child, *np = dev_of_node(dev);
+
+	for_each_available_child_of_node(np, child)
+		of_clk_del_provider(child);
+
+	return 0;
+}
+
+static struct platform_driver stm32mp25_rcc_clocks_driver = {
+	.driver	= {
+		.name = "stm32mp25_rcc",
+		.of_match_table = stm32mp25_match_data,
+	},
+	.probe = stm32mp25_rcc_clocks_probe,
+	.remove = stm32mp25_rcc_clocks_remove,
+};
+
+static int __init stm32mp25_clocks_init(void)
+{
+	return platform_driver_register(&stm32mp25_rcc_clocks_driver);
+}
+
+core_initcall(stm32mp25_clocks_init);
diff --git a/drivers/clk/stm32/reset-stm32.c b/drivers/clk/stm32/reset-stm32.c
index 14c2ee1eebee..5a8f525842ce 100644
--- a/drivers/clk/stm32/reset-stm32.c
+++ b/drivers/clk/stm32/reset-stm32.c
@@ -19,6 +19,7 @@ struct stm32_reset_data {
 	struct reset_controller_dev	rcdev;
 	void __iomem			*membase;
 	u32				clear_offset;
+	const struct stm32_reset_cfg	**reset_lines;
 };
 
 static inline struct stm32_reset_data *
@@ -27,22 +28,46 @@ to_stm32_reset_data(struct reset_controller_dev *rcdev)
 	return container_of(rcdev, struct stm32_reset_data, rcdev);
 }
 
+static const struct stm32_reset_cfg *stm32_get_reset_line(struct reset_controller_dev *rcdev,
+							  unsigned long id,
+							  struct stm32_reset_cfg *line)
+{
+	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
+
+	if (!data->reset_lines) {
+		int reg_width = sizeof(u32);
+		int bank = id / (reg_width * BITS_PER_BYTE);
+		int offset = id % (reg_width * BITS_PER_BYTE);
+
+		line->offset = bank * reg_width;
+		line->bit_idx = offset;
+		line->set_clr = (data->clear_offset ? true : false);
+
+		return line;
+	}
+
+	return data->reset_lines[id];
+}
+
 static int stm32_reset_update(struct reset_controller_dev *rcdev,
 			      unsigned long id, bool assert)
 {
 	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
+	struct stm32_reset_cfg line_reset;
+	const struct stm32_reset_cfg *ptr_line;
 
-	if (data->clear_offset) {
+	ptr_line = stm32_get_reset_line(rcdev, id, &line_reset);
+	if (!ptr_line)
+		return -EPERM;
+
+	if (ptr_line->set_clr) {
 		void __iomem *addr;
 
-		addr = data->membase + (bank * reg_width);
+		addr = data->membase + ptr_line->offset;
 		if (!assert)
 			addr += data->clear_offset;
 
-		writel(BIT(offset), addr);
+		writel(BIT(ptr_line->bit_idx), addr);
 
 	} else {
 		unsigned long flags;
@@ -50,14 +75,14 @@ static int stm32_reset_update(struct reset_controller_dev *rcdev,
 
 		spin_lock_irqsave(&data->lock, flags);
 
-		reg = readl(data->membase + (bank * reg_width));
+		reg = readl(data->membase + ptr_line->offset);
 
 		if (assert)
-			reg |= BIT(offset);
+			reg |= BIT(ptr_line->bit_idx);
 		else
-			reg &= ~BIT(offset);
+			reg &= ~BIT(ptr_line->bit_idx);
 
-		writel(reg, data->membase + (bank * reg_width));
+		writel(reg, data->membase + ptr_line->offset);
 
 		spin_unlock_irqrestore(&data->lock, flags);
 	}
@@ -81,14 +106,17 @@ static int stm32_reset_status(struct reset_controller_dev *rcdev,
 			      unsigned long id)
 {
 	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
+	struct stm32_reset_cfg line_reset;
+	const struct stm32_reset_cfg *ptr_line;
 	u32 reg;
 
-	reg = readl(data->membase + (bank * reg_width));
+	ptr_line = stm32_get_reset_line(rcdev, id, &line_reset);
+	if (!ptr_line)
+		return -EPERM;
+
+	reg = readl(data->membase + ptr_line->offset);
 
-	return !!(reg & BIT(offset));
+	return !!(reg & BIT(ptr_line->bit_idx));
 }
 
 static const struct reset_control_ops stm32_reset_ops = {
@@ -113,6 +141,7 @@ int stm32_rcc_reset_init(struct device *dev, struct clk_stm32_reset_data *data,
 	reset_data->rcdev.ops = &stm32_reset_ops;
 	reset_data->rcdev.of_node = dev_of_node(dev);
 	reset_data->rcdev.nr_resets = data->nr_lines;
+	reset_data->reset_lines = data->reset_lines;
 	reset_data->clear_offset = data->clear_offset;
 
 	return reset_controller_register(&reset_data->rcdev);
diff --git a/drivers/clk/stm32/reset-stm32.h b/drivers/clk/stm32/reset-stm32.h
index 8cf1cc9be480..f79cad21dfd6 100644
--- a/drivers/clk/stm32/reset-stm32.h
+++ b/drivers/clk/stm32/reset-stm32.h
@@ -4,8 +4,15 @@
  * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
  */
 
+struct stm32_reset_cfg {
+	u16 offset;
+	u8 bit_idx;
+	bool set_clr;
+};
+
 struct clk_stm32_reset_data {
 	const struct reset_control_ops *ops;
+	const struct stm32_reset_cfg **reset_lines;
 	unsigned int nr_lines;
 	u32 clear_offset;
 };
diff --git a/drivers/clk/stm32/stm32mp25_rcc.h b/drivers/clk/stm32/stm32mp25_rcc.h
new file mode 100644
index 000000000000..6ba13cc2ae16
--- /dev/null
+++ b/drivers/clk/stm32/stm32mp25_rcc.h
@@ -0,0 +1,712 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
+ * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
+ */
+
+#ifndef STM32MP25_RCC_H
+#define STM32MP25_RCC_H
+
+#define RCC_SECCFGR0				0x0
+#define RCC_SECCFGR1				0x4
+#define RCC_SECCFGR2				0x8
+#define RCC_SECCFGR3				0xC
+#define RCC_PRIVCFGR0				0x10
+#define RCC_PRIVCFGR1				0x14
+#define RCC_PRIVCFGR2				0x18
+#define RCC_PRIVCFGR3				0x1C
+#define RCC_RCFGLOCKR0				0x20
+#define RCC_RCFGLOCKR1				0x24
+#define RCC_RCFGLOCKR2				0x28
+#define RCC_RCFGLOCKR3				0x2C
+#define RCC_R0CIDCFGR				0x30
+#define RCC_R0SEMCR				0x34
+#define RCC_R1CIDCFGR				0x38
+#define RCC_R1SEMCR				0x3C
+#define RCC_R2CIDCFGR				0x40
+#define RCC_R2SEMCR				0x44
+#define RCC_R3CIDCFGR				0x48
+#define RCC_R3SEMCR				0x4C
+#define RCC_R4CIDCFGR				0x50
+#define RCC_R4SEMCR				0x54
+#define RCC_R5CIDCFGR				0x58
+#define RCC_R5SEMCR				0x5C
+#define RCC_R6CIDCFGR				0x60
+#define RCC_R6SEMCR				0x64
+#define RCC_R7CIDCFGR				0x68
+#define RCC_R7SEMCR				0x6C
+#define RCC_R8CIDCFGR				0x70
+#define RCC_R8SEMCR				0x74
+#define RCC_R9CIDCFGR				0x78
+#define RCC_R9SEMCR				0x7C
+#define RCC_R10CIDCFGR				0x80
+#define RCC_R10SEMCR				0x84
+#define RCC_R11CIDCFGR				0x88
+#define RCC_R11SEMCR				0x8C
+#define RCC_R12CIDCFGR				0x90
+#define RCC_R12SEMCR				0x94
+#define RCC_R13CIDCFGR				0x98
+#define RCC_R13SEMCR				0x9C
+#define RCC_R14CIDCFGR				0xA0
+#define RCC_R14SEMCR				0xA4
+#define RCC_R15CIDCFGR				0xA8
+#define RCC_R15SEMCR				0xAC
+#define RCC_R16CIDCFGR				0xB0
+#define RCC_R16SEMCR				0xB4
+#define RCC_R17CIDCFGR				0xB8
+#define RCC_R17SEMCR				0xBC
+#define RCC_R18CIDCFGR				0xC0
+#define RCC_R18SEMCR				0xC4
+#define RCC_R19CIDCFGR				0xC8
+#define RCC_R19SEMCR				0xCC
+#define RCC_R20CIDCFGR				0xD0
+#define RCC_R20SEMCR				0xD4
+#define RCC_R21CIDCFGR				0xD8
+#define RCC_R21SEMCR				0xDC
+#define RCC_R22CIDCFGR				0xE0
+#define RCC_R22SEMCR				0xE4
+#define RCC_R23CIDCFGR				0xE8
+#define RCC_R23SEMCR				0xEC
+#define RCC_R24CIDCFGR				0xF0
+#define RCC_R24SEMCR				0xF4
+#define RCC_R25CIDCFGR				0xF8
+#define RCC_R25SEMCR				0xFC
+#define RCC_R26CIDCFGR				0x100
+#define RCC_R26SEMCR				0x104
+#define RCC_R27CIDCFGR				0x108
+#define RCC_R27SEMCR				0x10C
+#define RCC_R28CIDCFGR				0x110
+#define RCC_R28SEMCR				0x114
+#define RCC_R29CIDCFGR				0x118
+#define RCC_R29SEMCR				0x11C
+#define RCC_R30CIDCFGR				0x120
+#define RCC_R30SEMCR				0x124
+#define RCC_R31CIDCFGR				0x128
+#define RCC_R31SEMCR				0x12C
+#define RCC_R32CIDCFGR				0x130
+#define RCC_R32SEMCR				0x134
+#define RCC_R33CIDCFGR				0x138
+#define RCC_R33SEMCR				0x13C
+#define RCC_R34CIDCFGR				0x140
+#define RCC_R34SEMCR				0x144
+#define RCC_R35CIDCFGR				0x148
+#define RCC_R35SEMCR				0x14C
+#define RCC_R36CIDCFGR				0x150
+#define RCC_R36SEMCR				0x154
+#define RCC_R37CIDCFGR				0x158
+#define RCC_R37SEMCR				0x15C
+#define RCC_R38CIDCFGR				0x160
+#define RCC_R38SEMCR				0x164
+#define RCC_R39CIDCFGR				0x168
+#define RCC_R39SEMCR				0x16C
+#define RCC_R40CIDCFGR				0x170
+#define RCC_R40SEMCR				0x174
+#define RCC_R41CIDCFGR				0x178
+#define RCC_R41SEMCR				0x17C
+#define RCC_R42CIDCFGR				0x180
+#define RCC_R42SEMCR				0x184
+#define RCC_R43CIDCFGR				0x188
+#define RCC_R43SEMCR				0x18C
+#define RCC_R44CIDCFGR				0x190
+#define RCC_R44SEMCR				0x194
+#define RCC_R45CIDCFGR				0x198
+#define RCC_R45SEMCR				0x19C
+#define RCC_R46CIDCFGR				0x1A0
+#define RCC_R46SEMCR				0x1A4
+#define RCC_R47CIDCFGR				0x1A8
+#define RCC_R47SEMCR				0x1AC
+#define RCC_R48CIDCFGR				0x1B0
+#define RCC_R48SEMCR				0x1B4
+#define RCC_R49CIDCFGR				0x1B8
+#define RCC_R49SEMCR				0x1BC
+#define RCC_R50CIDCFGR				0x1C0
+#define RCC_R50SEMCR				0x1C4
+#define RCC_R51CIDCFGR				0x1C8
+#define RCC_R51SEMCR				0x1CC
+#define RCC_R52CIDCFGR				0x1D0
+#define RCC_R52SEMCR				0x1D4
+#define RCC_R53CIDCFGR				0x1D8
+#define RCC_R53SEMCR				0x1DC
+#define RCC_R54CIDCFGR				0x1E0
+#define RCC_R54SEMCR				0x1E4
+#define RCC_R55CIDCFGR				0x1E8
+#define RCC_R55SEMCR				0x1EC
+#define RCC_R56CIDCFGR				0x1F0
+#define RCC_R56SEMCR				0x1F4
+#define RCC_R57CIDCFGR				0x1F8
+#define RCC_R57SEMCR				0x1FC
+#define RCC_R58CIDCFGR				0x200
+#define RCC_R58SEMCR				0x204
+#define RCC_R59CIDCFGR				0x208
+#define RCC_R59SEMCR				0x20C
+#define RCC_R60CIDCFGR				0x210
+#define RCC_R60SEMCR				0x214
+#define RCC_R61CIDCFGR				0x218
+#define RCC_R61SEMCR				0x21C
+#define RCC_R62CIDCFGR				0x220
+#define RCC_R62SEMCR				0x224
+#define RCC_R63CIDCFGR				0x228
+#define RCC_R63SEMCR				0x22C
+#define RCC_R64CIDCFGR				0x230
+#define RCC_R64SEMCR				0x234
+#define RCC_R65CIDCFGR				0x238
+#define RCC_R65SEMCR				0x23C
+#define RCC_R66CIDCFGR				0x240
+#define RCC_R66SEMCR				0x244
+#define RCC_R67CIDCFGR				0x248
+#define RCC_R67SEMCR				0x24C
+#define RCC_R68CIDCFGR				0x250
+#define RCC_R68SEMCR				0x254
+#define RCC_R69CIDCFGR				0x258
+#define RCC_R69SEMCR				0x25C
+#define RCC_R70CIDCFGR				0x260
+#define RCC_R70SEMCR				0x264
+#define RCC_R71CIDCFGR				0x268
+#define RCC_R71SEMCR				0x26C
+#define RCC_R72CIDCFGR				0x270
+#define RCC_R72SEMCR				0x274
+#define RCC_R73CIDCFGR				0x278
+#define RCC_R73SEMCR				0x27C
+#define RCC_R74CIDCFGR				0x280
+#define RCC_R74SEMCR				0x284
+#define RCC_R75CIDCFGR				0x288
+#define RCC_R75SEMCR				0x28C
+#define RCC_R76CIDCFGR				0x290
+#define RCC_R76SEMCR				0x294
+#define RCC_R77CIDCFGR				0x298
+#define RCC_R77SEMCR				0x29C
+#define RCC_R78CIDCFGR				0x2A0
+#define RCC_R78SEMCR				0x2A4
+#define RCC_R79CIDCFGR				0x2A8
+#define RCC_R79SEMCR				0x2AC
+#define RCC_R80CIDCFGR				0x2B0
+#define RCC_R80SEMCR				0x2B4
+#define RCC_R81CIDCFGR				0x2B8
+#define RCC_R81SEMCR				0x2BC
+#define RCC_R82CIDCFGR				0x2C0
+#define RCC_R82SEMCR				0x2C4
+#define RCC_R83CIDCFGR				0x2C8
+#define RCC_R83SEMCR				0x2CC
+#define RCC_R84CIDCFGR				0x2D0
+#define RCC_R84SEMCR				0x2D4
+#define RCC_R85CIDCFGR				0x2D8
+#define RCC_R85SEMCR				0x2DC
+#define RCC_R86CIDCFGR				0x2E0
+#define RCC_R86SEMCR				0x2E4
+#define RCC_R87CIDCFGR				0x2E8
+#define RCC_R87SEMCR				0x2EC
+#define RCC_R88CIDCFGR				0x2F0
+#define RCC_R88SEMCR				0x2F4
+#define RCC_R89CIDCFGR				0x2F8
+#define RCC_R89SEMCR				0x2FC
+#define RCC_R90CIDCFGR				0x300
+#define RCC_R90SEMCR				0x304
+#define RCC_R91CIDCFGR				0x308
+#define RCC_R91SEMCR				0x30C
+#define RCC_R92CIDCFGR				0x310
+#define RCC_R92SEMCR				0x314
+#define RCC_R93CIDCFGR				0x318
+#define RCC_R93SEMCR				0x31C
+#define RCC_R94CIDCFGR				0x320
+#define RCC_R94SEMCR				0x324
+#define RCC_R95CIDCFGR				0x328
+#define RCC_R95SEMCR				0x32C
+#define RCC_R96CIDCFGR				0x330
+#define RCC_R96SEMCR				0x334
+#define RCC_R97CIDCFGR				0x338
+#define RCC_R97SEMCR				0x33C
+#define RCC_R98CIDCFGR				0x340
+#define RCC_R98SEMCR				0x344
+#define RCC_R99CIDCFGR				0x348
+#define RCC_R99SEMCR				0x34C
+#define RCC_R100CIDCFGR				0x350
+#define RCC_R100SEMCR				0x354
+#define RCC_R101CIDCFGR				0x358
+#define RCC_R101SEMCR				0x35C
+#define RCC_R102CIDCFGR				0x360
+#define RCC_R102SEMCR				0x364
+#define RCC_R103CIDCFGR				0x368
+#define RCC_R103SEMCR				0x36C
+#define RCC_R104CIDCFGR				0x370
+#define RCC_R104SEMCR				0x374
+#define RCC_R105CIDCFGR				0x378
+#define RCC_R105SEMCR				0x37C
+#define RCC_R106CIDCFGR				0x380
+#define RCC_R106SEMCR				0x384
+#define RCC_R107CIDCFGR				0x388
+#define RCC_R107SEMCR				0x38C
+#define RCC_R108CIDCFGR				0x390
+#define RCC_R108SEMCR				0x394
+#define RCC_R109CIDCFGR				0x398
+#define RCC_R109SEMCR				0x39C
+#define RCC_R110CIDCFGR				0x3A0
+#define RCC_R110SEMCR				0x3A4
+#define RCC_R111CIDCFGR				0x3A8
+#define RCC_R111SEMCR				0x3AC
+#define RCC_R112CIDCFGR				0x3B0
+#define RCC_R112SEMCR				0x3B4
+#define RCC_R113CIDCFGR				0x3B8
+#define RCC_R113SEMCR				0x3BC
+#define RCC_GRSTCSETR				0x400
+#define RCC_C1RSTCSETR				0x404
+#define RCC_C1P1RSTCSETR			0x408
+#define RCC_C2RSTCSETR				0x40C
+#define RCC_HWRSTSCLRR				0x410
+#define RCC_C1HWRSTSCLRR			0x414
+#define RCC_C2HWRSTSCLRR			0x418
+#define RCC_C1BOOTRSTSSETR			0x41C
+#define RCC_C1BOOTRSTSCLRR			0x420
+#define RCC_C2BOOTRSTSSETR			0x424
+#define RCC_C2BOOTRSTSCLRR			0x428
+#define RCC_C1SREQSETR				0x42C
+#define RCC_C1SREQCLRR				0x430
+#define RCC_CPUBOOTCR				0x434
+#define RCC_STBYBOOTCR				0x438
+#define RCC_LEGBOOTCR				0x43C
+#define RCC_BDCR				0x440
+#define RCC_D3DCR				0x444
+#define RCC_D3DSR				0x448
+#define RCC_RDCR				0x44C
+#define RCC_C1MSRDCR				0x450
+#define RCC_PWRLPDLYCR				0x454
+#define RCC_C1CIESETR				0x458
+#define RCC_C1CIFCLRR				0x45C
+#define RCC_C2CIESETR				0x460
+#define RCC_C2CIFCLRR				0x464
+#define RCC_IWDGC1FZSETR			0x468
+#define RCC_IWDGC1FZCLRR			0x46C
+#define RCC_IWDGC1CFGSETR			0x470
+#define RCC_IWDGC1CFGCLRR			0x474
+#define RCC_IWDGC2FZSETR			0x478
+#define RCC_IWDGC2FZCLRR			0x47C
+#define RCC_IWDGC2CFGSETR			0x480
+#define RCC_IWDGC2CFGCLRR			0x484
+#define RCC_IWDGC3CFGSETR			0x488
+#define RCC_IWDGC3CFGCLRR			0x48C
+#define RCC_C3CFGR				0x490
+#define RCC_MCO1CFGR				0x494
+#define RCC_MCO2CFGR				0x498
+#define RCC_OCENSETR				0x49C
+#define RCC_OCENCLRR				0x4A0
+#define RCC_OCRDYR				0x4A4
+#define RCC_HSICFGR				0x4A8
+#define RCC_MSICFGR				0x4AC
+#define RCC_RTCDIVR				0x4B0
+#define RCC_APB1DIVR				0x4B4
+#define RCC_APB2DIVR				0x4B8
+#define RCC_APB3DIVR				0x4BC
+#define RCC_APB4DIVR				0x4C0
+#define RCC_APBDBGDIVR				0x4C4
+#define RCC_TIMG1PRER				0x4C8
+#define RCC_TIMG2PRER				0x4CC
+#define RCC_LSMCUDIVR				0x4D0
+#define RCC_DDRCPCFGR				0x4D4
+#define RCC_DDRCAPBCFGR				0x4D8
+#define RCC_DDRPHYCAPBCFGR			0x4DC
+#define RCC_DDRPHYCCFGR				0x4E0
+#define RCC_DDRCFGR				0x4E4
+#define RCC_DDRITFCFGR				0x4E8
+#define RCC_SYSRAMCFGR				0x4F0
+#define RCC_VDERAMCFGR				0x4F4
+#define RCC_SRAM1CFGR				0x4F8
+#define RCC_SRAM2CFGR				0x4FC
+#define RCC_RETRAMCFGR				0x500
+#define RCC_BKPSRAMCFGR				0x504
+#define RCC_LPSRAM1CFGR				0x508
+#define RCC_LPSRAM2CFGR				0x50C
+#define RCC_LPSRAM3CFGR				0x510
+#define RCC_OSPI1CFGR				0x514
+#define RCC_OSPI2CFGR				0x518
+#define RCC_FMCCFGR				0x51C
+#define RCC_DBGCFGR				0x520
+#define RCC_STM500CFGR				0x524
+#define RCC_ETRCFGR				0x528
+#define RCC_GPIOACFGR				0x52C
+#define RCC_GPIOBCFGR				0x530
+#define RCC_GPIOCCFGR				0x534
+#define RCC_GPIODCFGR				0x538
+#define RCC_GPIOECFGR				0x53C
+#define RCC_GPIOFCFGR				0x540
+#define RCC_GPIOGCFGR				0x544
+#define RCC_GPIOHCFGR				0x548
+#define RCC_GPIOICFGR				0x54C
+#define RCC_GPIOJCFGR				0x550
+#define RCC_GPIOKCFGR				0x554
+#define RCC_GPIOZCFGR				0x558
+#define RCC_HPDMA1CFGR				0x55C
+#define RCC_HPDMA2CFGR				0x560
+#define RCC_HPDMA3CFGR				0x564
+#define RCC_LPDMACFGR				0x568
+#define RCC_HSEMCFGR				0x56C
+#define RCC_IPCC1CFGR				0x570
+#define RCC_IPCC2CFGR				0x574
+#define RCC_RTCCFGR				0x578
+#define RCC_SYSCPU1CFGR				0x580
+#define RCC_BSECCFGR				0x584
+#define RCC_IS2MCFGR				0x58C
+#define RCC_PLL2CFGR1				0x590
+#define RCC_PLL2CFGR2				0x594
+#define RCC_PLL2CFGR3				0x598
+#define RCC_PLL2CFGR4				0x59C
+#define RCC_PLL2CFGR5				0x5A0
+#define RCC_PLL2CFGR6				0x5A8
+#define RCC_PLL2CFGR7				0x5AC
+#define RCC_PLL3CFGR1				0x5B8
+#define RCC_PLL3CFGR2				0x5BC
+#define RCC_PLL3CFGR3				0x5C0
+#define RCC_PLL3CFGR4				0x5C4
+#define RCC_PLL3CFGR5				0x5C8
+#define RCC_PLL3CFGR6				0x5D0
+#define RCC_PLL3CFGR7				0x5D4
+#define RCC_HSIFMONCR				0x5E0
+#define RCC_HSIFVALR				0x5E4
+#define RCC_TIM1CFGR				0x700
+#define RCC_TIM2CFGR				0x704
+#define RCC_TIM3CFGR				0x708
+#define RCC_TIM4CFGR				0x70C
+#define RCC_TIM5CFGR				0x710
+#define RCC_TIM6CFGR				0x714
+#define RCC_TIM7CFGR				0x718
+#define RCC_TIM8CFGR				0x71C
+#define RCC_TIM10CFGR				0x720
+#define RCC_TIM11CFGR				0x724
+#define RCC_TIM12CFGR				0x728
+#define RCC_TIM13CFGR				0x72C
+#define RCC_TIM14CFGR				0x730
+#define RCC_TIM15CFGR				0x734
+#define RCC_TIM16CFGR				0x738
+#define RCC_TIM17CFGR				0x73C
+#define RCC_TIM20CFGR				0x740
+#define RCC_LPTIM1CFGR				0x744
+#define RCC_LPTIM2CFGR				0x748
+#define RCC_LPTIM3CFGR				0x74C
+#define RCC_LPTIM4CFGR				0x750
+#define RCC_LPTIM5CFGR				0x754
+#define RCC_SPI1CFGR				0x758
+#define RCC_SPI2CFGR				0x75C
+#define RCC_SPI3CFGR				0x760
+#define RCC_SPI4CFGR				0x764
+#define RCC_SPI5CFGR				0x768
+#define RCC_SPI6CFGR				0x76C
+#define RCC_SPI7CFGR				0x770
+#define RCC_SPI8CFGR				0x774
+#define RCC_SPDIFRXCFGR				0x778
+#define RCC_USART1CFGR				0x77C
+#define RCC_USART2CFGR				0x780
+#define RCC_USART3CFGR				0x784
+#define RCC_UART4CFGR				0x788
+#define RCC_UART5CFGR				0x78C
+#define RCC_USART6CFGR				0x790
+#define RCC_UART7CFGR				0x794
+#define RCC_UART8CFGR				0x798
+#define RCC_UART9CFGR				0x79C
+#define RCC_LPUART1CFGR				0x7A0
+#define RCC_I2C1CFGR				0x7A4
+#define RCC_I2C2CFGR				0x7A8
+#define RCC_I2C3CFGR				0x7AC
+#define RCC_I2C4CFGR				0x7B0
+#define RCC_I2C5CFGR				0x7B4
+#define RCC_I2C6CFGR				0x7B8
+#define RCC_I2C7CFGR				0x7BC
+#define RCC_I2C8CFGR				0x7C0
+#define RCC_SAI1CFGR				0x7C4
+#define RCC_SAI2CFGR				0x7C8
+#define RCC_SAI3CFGR				0x7CC
+#define RCC_SAI4CFGR				0x7D0
+#define RCC_MDF1CFGR				0x7D8
+#define RCC_ADF1CFGR				0x7DC
+#define RCC_FDCANCFGR				0x7E0
+#define RCC_HDPCFGR				0x7E4
+#define RCC_ADC12CFGR				0x7E8
+#define RCC_ADC3CFGR				0x7EC
+#define RCC_ETH1CFGR				0x7F0
+#define RCC_ETH2CFGR				0x7F4
+#define RCC_USB2CFGR				0x7FC
+#define RCC_USB2PHY1CFGR			0x800
+#define RCC_USB2PHY2CFGR			0x804
+#define RCC_USB3DRCFGR				0x808
+#define RCC_USB3PCIEPHYCFGR			0x80C
+#define RCC_PCIECFGR				0x810
+#define RCC_USBTCCFGR				0x814
+#define RCC_ETHSWCFGR				0x818
+#define RCC_ETHSWACMCFGR			0x81C
+#define RCC_ETHSWACMMSGCFGR			0x820
+#define RCC_STGENCFGR				0x824
+#define RCC_SDMMC1CFGR				0x830
+#define RCC_SDMMC2CFGR				0x834
+#define RCC_SDMMC3CFGR				0x838
+#define RCC_GPUCFGR				0x83C
+#define RCC_LTDCCFGR				0x840
+#define RCC_DSICFGR				0x844
+#define RCC_LVDSCFGR				0x850
+#define RCC_CSICFGR				0x858
+#define RCC_DCMIPPCFGR				0x85C
+#define RCC_CCICFGR				0x860
+#define RCC_VDECCFGR				0x864
+#define RCC_VENCCFGR				0x868
+#define RCC_RNGCFGR				0x870
+#define RCC_PKACFGR				0x874
+#define RCC_SAESCFGR				0x878
+#define RCC_HASHCFGR				0x87C
+#define RCC_CRYP1CFGR				0x880
+#define RCC_CRYP2CFGR				0x884
+#define RCC_IWDG1CFGR				0x888
+#define RCC_IWDG2CFGR				0x88C
+#define RCC_IWDG3CFGR				0x890
+#define RCC_IWDG4CFGR				0x894
+#define RCC_IWDG5CFGR				0x898
+#define RCC_WWDG1CFGR				0x89C
+#define RCC_WWDG2CFGR				0x8A0
+#define RCC_VREFCFGR				0x8A8
+#define RCC_DTSCFGR				0x8AC
+#define RCC_CRCCFGR				0x8B4
+#define RCC_SERCCFGR				0x8B8
+#define RCC_OSPIIOMCFGR				0x8BC
+#define RCC_GICV2MCFGR				0x8C0
+#define RCC_I3C1CFGR				0x8C8
+#define RCC_I3C2CFGR				0x8CC
+#define RCC_I3C3CFGR				0x8D0
+#define RCC_I3C4CFGR				0x8D4
+#define RCC_MUXSELCFGR				0x1000
+#define RCC_XBAR0CFGR				0x1018
+#define RCC_XBAR1CFGR				0x101C
+#define RCC_XBAR2CFGR				0x1020
+#define RCC_XBAR3CFGR				0x1024
+#define RCC_XBAR4CFGR				0x1028
+#define RCC_XBAR5CFGR				0x102C
+#define RCC_XBAR6CFGR				0x1030
+#define RCC_XBAR7CFGR				0x1034
+#define RCC_XBAR8CFGR				0x1038
+#define RCC_XBAR9CFGR				0x103C
+#define RCC_XBAR10CFGR				0x1040
+#define RCC_XBAR11CFGR				0x1044
+#define RCC_XBAR12CFGR				0x1048
+#define RCC_XBAR13CFGR				0x104C
+#define RCC_XBAR14CFGR				0x1050
+#define RCC_XBAR15CFGR				0x1054
+#define RCC_XBAR16CFGR				0x1058
+#define RCC_XBAR17CFGR				0x105C
+#define RCC_XBAR18CFGR				0x1060
+#define RCC_XBAR19CFGR				0x1064
+#define RCC_XBAR20CFGR				0x1068
+#define RCC_XBAR21CFGR				0x106C
+#define RCC_XBAR22CFGR				0x1070
+#define RCC_XBAR23CFGR				0x1074
+#define RCC_XBAR24CFGR				0x1078
+#define RCC_XBAR25CFGR				0x107C
+#define RCC_XBAR26CFGR				0x1080
+#define RCC_XBAR27CFGR				0x1084
+#define RCC_XBAR28CFGR				0x1088
+#define RCC_XBAR29CFGR				0x108C
+#define RCC_XBAR30CFGR				0x1090
+#define RCC_XBAR31CFGR				0x1094
+#define RCC_XBAR32CFGR				0x1098
+#define RCC_XBAR33CFGR				0x109C
+#define RCC_XBAR34CFGR				0x10A0
+#define RCC_XBAR35CFGR				0x10A4
+#define RCC_XBAR36CFGR				0x10A8
+#define RCC_XBAR37CFGR				0x10AC
+#define RCC_XBAR38CFGR				0x10B0
+#define RCC_XBAR39CFGR				0x10B4
+#define RCC_XBAR40CFGR				0x10B8
+#define RCC_XBAR41CFGR				0x10BC
+#define RCC_XBAR42CFGR				0x10C0
+#define RCC_XBAR43CFGR				0x10C4
+#define RCC_XBAR44CFGR				0x10C8
+#define RCC_XBAR45CFGR				0x10CC
+#define RCC_XBAR46CFGR				0x10D0
+#define RCC_XBAR47CFGR				0x10D4
+#define RCC_XBAR48CFGR				0x10D8
+#define RCC_XBAR49CFGR				0x10DC
+#define RCC_XBAR50CFGR				0x10E0
+#define RCC_XBAR51CFGR				0x10E4
+#define RCC_XBAR52CFGR				0x10E8
+#define RCC_XBAR53CFGR				0x10EC
+#define RCC_XBAR54CFGR				0x10F0
+#define RCC_XBAR55CFGR				0x10F4
+#define RCC_XBAR56CFGR				0x10F8
+#define RCC_XBAR57CFGR				0x10FC
+#define RCC_XBAR58CFGR				0x1100
+#define RCC_XBAR59CFGR				0x1104
+#define RCC_XBAR60CFGR				0x1108
+#define RCC_XBAR61CFGR				0x110C
+#define RCC_XBAR62CFGR				0x1110
+#define RCC_XBAR63CFGR				0x1114
+#define RCC_PREDIV0CFGR				0x1118
+#define RCC_PREDIV1CFGR				0x111C
+#define RCC_PREDIV2CFGR				0x1120
+#define RCC_PREDIV3CFGR				0x1124
+#define RCC_PREDIV4CFGR				0x1128
+#define RCC_PREDIV5CFGR				0x112C
+#define RCC_PREDIV6CFGR				0x1130
+#define RCC_PREDIV7CFGR				0x1134
+#define RCC_PREDIV8CFGR				0x1138
+#define RCC_PREDIV9CFGR				0x113C
+#define RCC_PREDIV10CFGR			0x1140
+#define RCC_PREDIV11CFGR			0x1144
+#define RCC_PREDIV12CFGR			0x1148
+#define RCC_PREDIV13CFGR			0x114C
+#define RCC_PREDIV14CFGR			0x1150
+#define RCC_PREDIV15CFGR			0x1154
+#define RCC_PREDIV16CFGR			0x1158
+#define RCC_PREDIV17CFGR			0x115C
+#define RCC_PREDIV18CFGR			0x1160
+#define RCC_PREDIV19CFGR			0x1164
+#define RCC_PREDIV20CFGR			0x1168
+#define RCC_PREDIV21CFGR			0x116C
+#define RCC_PREDIV22CFGR			0x1170
+#define RCC_PREDIV23CFGR			0x1174
+#define RCC_PREDIV24CFGR			0x1178
+#define RCC_PREDIV25CFGR			0x117C
+#define RCC_PREDIV26CFGR			0x1180
+#define RCC_PREDIV27CFGR			0x1184
+#define RCC_PREDIV28CFGR			0x1188
+#define RCC_PREDIV29CFGR			0x118C
+#define RCC_PREDIV30CFGR			0x1190
+#define RCC_PREDIV31CFGR			0x1194
+#define RCC_PREDIV32CFGR			0x1198
+#define RCC_PREDIV33CFGR			0x119C
+#define RCC_PREDIV34CFGR			0x11A0
+#define RCC_PREDIV35CFGR			0x11A4
+#define RCC_PREDIV36CFGR			0x11A8
+#define RCC_PREDIV37CFGR			0x11AC
+#define RCC_PREDIV38CFGR			0x11B0
+#define RCC_PREDIV39CFGR			0x11B4
+#define RCC_PREDIV40CFGR			0x11B8
+#define RCC_PREDIV41CFGR			0x11BC
+#define RCC_PREDIV42CFGR			0x11C0
+#define RCC_PREDIV43CFGR			0x11C4
+#define RCC_PREDIV44CFGR			0x11C8
+#define RCC_PREDIV45CFGR			0x11CC
+#define RCC_PREDIV46CFGR			0x11D0
+#define RCC_PREDIV47CFGR			0x11D4
+#define RCC_PREDIV48CFGR			0x11D8
+#define RCC_PREDIV49CFGR			0x11DC
+#define RCC_PREDIV50CFGR			0x11E0
+#define RCC_PREDIV51CFGR			0x11E4
+#define RCC_PREDIV52CFGR			0x11E8
+#define RCC_PREDIV53CFGR			0x11EC
+#define RCC_PREDIV54CFGR			0x11F0
+#define RCC_PREDIV55CFGR			0x11F4
+#define RCC_PREDIV56CFGR			0x11F8
+#define RCC_PREDIV57CFGR			0x11FC
+#define RCC_PREDIV58CFGR			0x1200
+#define RCC_PREDIV59CFGR			0x1204
+#define RCC_PREDIV60CFGR			0x1208
+#define RCC_PREDIV61CFGR			0x120C
+#define RCC_PREDIV62CFGR			0x1210
+#define RCC_PREDIV63CFGR			0x1214
+#define RCC_PREDIVSR1				0x1218
+#define RCC_PREDIVSR2				0x121C
+#define RCC_FINDIV0CFGR				0x1224
+#define RCC_FINDIV1CFGR				0x1228
+#define RCC_FINDIV2CFGR				0x122C
+#define RCC_FINDIV3CFGR				0x1230
+#define RCC_FINDIV4CFGR				0x1234
+#define RCC_FINDIV5CFGR				0x1238
+#define RCC_FINDIV6CFGR				0x123C
+#define RCC_FINDIV7CFGR				0x1240
+#define RCC_FINDIV8CFGR				0x1244
+#define RCC_FINDIV9CFGR				0x1248
+#define RCC_FINDIV10CFGR			0x124C
+#define RCC_FINDIV11CFGR			0x1250
+#define RCC_FINDIV12CFGR			0x1254
+#define RCC_FINDIV13CFGR			0x1258
+#define RCC_FINDIV14CFGR			0x125C
+#define RCC_FINDIV15CFGR			0x1260
+#define RCC_FINDIV16CFGR			0x1264
+#define RCC_FINDIV17CFGR			0x1268
+#define RCC_FINDIV18CFGR			0x126C
+#define RCC_FINDIV19CFGR			0x1270
+#define RCC_FINDIV20CFGR			0x1274
+#define RCC_FINDIV21CFGR			0x1278
+#define RCC_FINDIV22CFGR			0x127C
+#define RCC_FINDIV23CFGR			0x1280
+#define RCC_FINDIV24CFGR			0x1284
+#define RCC_FINDIV25CFGR			0x1288
+#define RCC_FINDIV26CFGR			0x128C
+#define RCC_FINDIV27CFGR			0x1290
+#define RCC_FINDIV28CFGR			0x1294
+#define RCC_FINDIV29CFGR			0x1298
+#define RCC_FINDIV30CFGR			0x129C
+#define RCC_FINDIV31CFGR			0x12A0
+#define RCC_FINDIV32CFGR			0x12A4
+#define RCC_FINDIV33CFGR			0x12A8
+#define RCC_FINDIV34CFGR			0x12AC
+#define RCC_FINDIV35CFGR			0x12B0
+#define RCC_FINDIV36CFGR			0x12B4
+#define RCC_FINDIV37CFGR			0x12B8
+#define RCC_FINDIV38CFGR			0x12BC
+#define RCC_FINDIV39CFGR			0x12C0
+#define RCC_FINDIV40CFGR			0x12C4
+#define RCC_FINDIV41CFGR			0x12C8
+#define RCC_FINDIV42CFGR			0x12CC
+#define RCC_FINDIV43CFGR			0x12D0
+#define RCC_FINDIV44CFGR			0x12D4
+#define RCC_FINDIV45CFGR			0x12D8
+#define RCC_FINDIV46CFGR			0x12DC
+#define RCC_FINDIV47CFGR			0x12E0
+#define RCC_FINDIV48CFGR			0x12E4
+#define RCC_FINDIV49CFGR			0x12E8
+#define RCC_FINDIV50CFGR			0x12EC
+#define RCC_FINDIV51CFGR			0x12F0
+#define RCC_FINDIV52CFGR			0x12F4
+#define RCC_FINDIV53CFGR			0x12F8
+#define RCC_FINDIV54CFGR			0x12FC
+#define RCC_FINDIV55CFGR			0x1300
+#define RCC_FINDIV56CFGR			0x1304
+#define RCC_FINDIV57CFGR			0x1308
+#define RCC_FINDIV58CFGR			0x130C
+#define RCC_FINDIV59CFGR			0x1310
+#define RCC_FINDIV60CFGR			0x1314
+#define RCC_FINDIV61CFGR			0x1318
+#define RCC_FINDIV62CFGR			0x131C
+#define RCC_FINDIV63CFGR			0x1320
+#define RCC_FINDIVSR1				0x1324
+#define RCC_FINDIVSR2				0x1328
+#define RCC_FCALCOBS0CFGR			0x1340
+#define RCC_FCALCOBS1CFGR			0x1344
+#define RCC_FCALCREFCFGR			0x1348
+#define RCC_FCALCCR1				0x134C
+#define RCC_FCALCCR2				0x1354
+#define RCC_FCALCSR				0x1358
+#define RCC_PLL4CFGR1				0x1360
+#define RCC_PLL4CFGR2				0x1364
+#define RCC_PLL4CFGR3				0x1368
+#define RCC_PLL4CFGR4				0x136C
+#define RCC_PLL4CFGR5				0x1370
+#define RCC_PLL4CFGR6				0x1378
+#define RCC_PLL4CFGR7				0x137C
+#define RCC_PLL5CFGR1				0x1388
+#define RCC_PLL5CFGR2				0x138C
+#define RCC_PLL5CFGR3				0x1390
+#define RCC_PLL5CFGR4				0x1394
+#define RCC_PLL5CFGR5				0x1398
+#define RCC_PLL5CFGR6				0x13A0
+#define RCC_PLL5CFGR7				0x13A4
+#define RCC_PLL6CFGR1				0x13B0
+#define RCC_PLL6CFGR2				0x13B4
+#define RCC_PLL6CFGR3				0x13B8
+#define RCC_PLL6CFGR4				0x13BC
+#define RCC_PLL6CFGR5				0x13C0
+#define RCC_PLL6CFGR6				0x13C8
+#define RCC_PLL6CFGR7				0x13CC
+#define RCC_PLL7CFGR1				0x13D8
+#define RCC_PLL7CFGR2				0x13DC
+#define RCC_PLL7CFGR3				0x13E0
+#define RCC_PLL7CFGR4				0x13E4
+#define RCC_PLL7CFGR5				0x13E8
+#define RCC_PLL7CFGR6				0x13F0
+#define RCC_PLL7CFGR7				0x13F4
+#define RCC_PLL8CFGR1				0x1400
+#define RCC_PLL8CFGR2				0x1404
+#define RCC_PLL8CFGR3				0x1408
+#define RCC_PLL8CFGR4				0x140C
+#define RCC_PLL8CFGR5				0x1410
+#define RCC_PLL8CFGR6				0x1418
+#define RCC_PLL8CFGR7				0x141C
+#define RCC_VERR				0xFFF4
+#define RCC_IDR					0xFFF8
+#define RCC_SIDR				0xFFFC
+
+#endif /* STM32MP25_RCC_H */
-- 
2.25.1



From alexghiti at rivosinc.com  Fri Dec  8 06:39:22 2023
From: alexghiti at rivosinc.com (Alexandre Ghiti)
Date: Fri, 8 Dec 2023 15:39:22 +0100
Subject: [PATCH RFC/RFT 3/4] riscv: Stop emitting preventive sfence.vma
 for new userspace mappings
In-Reply-To: <e783436f-631c-4b02-ba9c-b6145e0e8b5a@csgroup.eu>
References: <20231207150348.82096-1-alexghiti@rivosinc.com>
 <20231207150348.82096-4-alexghiti@rivosinc.com> <e783436f-631c-4b02-ba9c-b6145e0e8b5a@csgroup.eu>
Message-ID: <CAHVXubit2NjBREKFb=s14q13PvtcjuthLn2oKnBq8PfFnVMieQ@mail.gmail.com>

On Thu, Dec 7, 2023 at 5:37?PM Christophe Leroy
<christophe.leroy at csgroup.eu> wrote:
>
> The subject says "riscv:" but it changes core part and several arch.
> Maybe this commit should be split in two commits, one for API changes
> that changes flush_tlb_fix_spurious_fault() to
> flush_tlb_fix_spurious_write_fault() and adds
> flush_tlb_fix_spurious_read_fault() including the change in memory.c,
> then a second patch with the changes to riscv.

You're right, I'll do that, thanks.

>
> Le 07/12/2023 ? 16:03, Alexandre Ghiti a ?crit :
> > The preventive sfence.vma were emitted because new mappings must be made
> > visible to the page table walker, either the uarch caches invalid
> > entries or not.
> >
> > Actually, there is no need to preventively sfence.vma on new mappings for
> > userspace, this should be handled only in the page fault path.
> >
> > This allows to drastically reduce the number of sfence.vma emitted:
> >
> > * Ubuntu boot to login:
> > Before: ~630k sfence.vma
> > After:  ~200k sfence.vma
> >
> > * ltp - mmapstress01
> > Before: ~45k
> > After:  ~6.3k
> >
> > * lmbench - lat_pagefault
> > Before: ~665k
> > After:   832 (!)
> >
> > * lmbench - lat_mmap
> > Before: ~546k
> > After:   718 (!)
> >
> > The only issue with the removal of sfence.vma in update_mmu_cache() is
> > that on uarchs that cache invalid entries, those won't be invalidated
> > until the process takes a fault: so that's an additional fault in those
> > cases.
> >
> > Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
> > ---
> >   arch/arm64/include/asm/pgtable.h              |  2 +-
> >   arch/mips/include/asm/pgtable.h               |  6 +--
> >   arch/powerpc/include/asm/book3s/64/tlbflush.h |  8 ++--
> >   arch/riscv/include/asm/pgtable.h              | 43 +++++++++++--------
> >   include/linux/pgtable.h                       |  8 +++-
> >   mm/memory.c                                   | 12 +++++-
> >   6 files changed, 48 insertions(+), 31 deletions(-)
>
> Did you forget mm/pgtable-generic.c ?

Indeed, I "missed" the occurrence of flush_tlb_fix_spurious_fault()
there, thanks.

>
> >
> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> > index 7f7d9b1df4e5..728f25f529a5 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -57,7 +57,7 @@ static inline bool arch_thp_swp_supported(void)
> >    * fault on one CPU which has been handled concurrently by another CPU
> >    * does not need to perform additional invalidation.
> >    */
> > -#define flush_tlb_fix_spurious_fault(vma, address, ptep) do { } while (0)
> > +#define flush_tlb_fix_spurious_write_fault(vma, address, ptep) do { } while (0)
>
> Why do you need to do that change ? Nothing is explained about that in
> the commit message.

I renamed this macro because in the page fault path,
flush_tlb_fix_spurious_fault() is called only when the fault is a
write fault (see
https://elixir.bootlin.com/linux/latest/source/mm/memory.c#L5016).
I'll check if that fits the occurrence in mm/pgtable-generic.c too.

Thanks again for the review,

Alex

>
> >
> >   /*
> >    * ZERO_PAGE is a global shared page that is always zero: used
> > diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
> > index 430b208c0130..84439fe6ed29 100644
> > --- a/arch/mips/include/asm/pgtable.h
> > +++ b/arch/mips/include/asm/pgtable.h
> > @@ -478,9 +478,9 @@ static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> >       return __pgprot(prot);
> >   }
> >
> > -static inline void flush_tlb_fix_spurious_fault(struct vm_area_struct *vma,
> > -                                             unsigned long address,
> > -                                             pte_t *ptep)
> > +static inline void flush_tlb_fix_spurious_write_fault(struct vm_area_struct *vma,
> > +                                                   unsigned long address,
> > +                                                   pte_t *ptep)
> >   {
> >   }
> >
> > diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h b/arch/powerpc/include/asm/book3s/64/tlbflush.h
> > index 1950c1b825b4..7166d56f90db 100644
> > --- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
> > +++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
> > @@ -128,10 +128,10 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
> >   #define flush_tlb_page(vma, addr)   local_flush_tlb_page(vma, addr)
> >   #endif /* CONFIG_SMP */
> >
> > -#define flush_tlb_fix_spurious_fault flush_tlb_fix_spurious_fault
> > -static inline void flush_tlb_fix_spurious_fault(struct vm_area_struct *vma,
> > -                                             unsigned long address,
> > -                                             pte_t *ptep)
> > +#define flush_tlb_fix_spurious_write_fault flush_tlb_fix_spurious_write_fault
> > +static inline void flush_tlb_fix_spurious_write_fault(struct vm_area_struct *vma,
> > +                                                   unsigned long address,
> > +                                                   pte_t *ptep)
> >   {
> >       /*
> >        * Book3S 64 does not require spurious fault flushes because the PTE
> > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> > index b2ba3f79cfe9..89aa5650f104 100644
> > --- a/arch/riscv/include/asm/pgtable.h
> > +++ b/arch/riscv/include/asm/pgtable.h
> > @@ -472,28 +472,20 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf,
> >               struct vm_area_struct *vma, unsigned long address,
> >               pte_t *ptep, unsigned int nr)
> >   {
> > -     /*
> > -      * The kernel assumes that TLBs don't cache invalid entries, but
> > -      * in RISC-V, SFENCE.VMA specifies an ordering constraint, not a
> > -      * cache flush; it is necessary even after writing invalid entries.
> > -      * Relying on flush_tlb_fix_spurious_fault would suffice, but
> > -      * the extra traps reduce performance.  So, eagerly SFENCE.VMA.
> > -      */
> > -     while (nr--)
> > -             local_flush_tlb_page(address + nr * PAGE_SIZE);
> >   }
> >   #define update_mmu_cache(vma, addr, ptep) \
> >       update_mmu_cache_range(NULL, vma, addr, ptep, 1)
> >
> >   #define __HAVE_ARCH_UPDATE_MMU_TLB
> > -#define update_mmu_tlb update_mmu_cache
> > +static inline void update_mmu_tlb(struct vm_area_struct *vma,
> > +                               unsigned long address, pte_t *ptep)
> > +{
> > +     flush_tlb_range(vma, address, address + PAGE_SIZE);
> > +}
> >
> >   static inline void update_mmu_cache_pmd(struct vm_area_struct *vma,
> >               unsigned long address, pmd_t *pmdp)
> >   {
> > -     pte_t *ptep = (pte_t *)pmdp;
> > -
> > -     update_mmu_cache(vma, address, ptep);
> >   }
> >
> >   #define __HAVE_ARCH_PTE_SAME
> > @@ -548,13 +540,26 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma,
> >                                       unsigned long address, pte_t *ptep,
> >                                       pte_t entry, int dirty)
> >   {
> > -     if (!pte_same(*ptep, entry))
> > +     if (!pte_same(*ptep, entry)) {
> >               __set_pte_at(ptep, entry);
> > -     /*
> > -      * update_mmu_cache will unconditionally execute, handling both
> > -      * the case that the PTE changed and the spurious fault case.
> > -      */
> > -     return true;
> > +             /* Here only not svadu is impacted */
> > +             flush_tlb_page(vma, address);
> > +             return true;
> > +     }
> > +
> > +     return false;
> > +}
> > +
> > +extern u64 nr_sfence_vma_handle_exception;
> > +extern bool tlb_caching_invalid_entries;
> > +
> > +#define flush_tlb_fix_spurious_read_fault flush_tlb_fix_spurious_read_fault
> > +static inline void flush_tlb_fix_spurious_read_fault(struct vm_area_struct *vma,
> > +                                                  unsigned long address,
> > +                                                  pte_t *ptep)
> > +{
> > +     if (tlb_caching_invalid_entries)
> > +             flush_tlb_page(vma, address);
> >   }
> >
> >   #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
> > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> > index af7639c3b0a3..7abaf42ef612 100644
> > --- a/include/linux/pgtable.h
> > +++ b/include/linux/pgtable.h
> > @@ -931,8 +931,12 @@ static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
> >   # define pte_accessible(mm, pte)    ((void)(pte), 1)
> >   #endif
> >
> > -#ifndef flush_tlb_fix_spurious_fault
> > -#define flush_tlb_fix_spurious_fault(vma, address, ptep) flush_tlb_page(vma, address)
> > +#ifndef flush_tlb_fix_spurious_write_fault
> > +#define flush_tlb_fix_spurious_write_fault(vma, address, ptep) flush_tlb_page(vma, address)
> > +#endif
> > +
> > +#ifndef flush_tlb_fix_spurious_read_fault
> > +#define flush_tlb_fix_spurious_read_fault(vma, address, ptep)
> >   #endif
> >
> >   /*
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 517221f01303..5cb0ccf0c03f 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -5014,8 +5014,16 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf)
> >                * with threads.
> >                */
> >               if (vmf->flags & FAULT_FLAG_WRITE)
> > -                     flush_tlb_fix_spurious_fault(vmf->vma, vmf->address,
> > -                                                  vmf->pte);
> > +                     flush_tlb_fix_spurious_write_fault(vmf->vma, vmf->address,
> > +                                                        vmf->pte);
> > +             else
> > +                     /*
> > +                      * With the pte_same(ptep_get(vmf->pte), entry) check
> > +                      * that calls update_mmu_tlb() above, multiple threads
> > +                      * faulting at the same time won't get there.
> > +                      */
> > +                     flush_tlb_fix_spurious_read_fault(vmf->vma, vmf->address,
> > +                                                       vmf->pte);
> >       }
> >   unlock:
> >       pte_unmap_unlock(vmf->pte, vmf->ptl);


From andersson at kernel.org  Fri Dec  8 06:55:22 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Fri,  8 Dec 2023 06:55:22 -0800
Subject: [PATCH] arm64: deconfig: enable Qualcomm SM8650 SoC drivers
In-Reply-To: <20231121-topic-sm8650-upstream-defconfig-v1-1-2500565fc21b@linaro.org>
References: <20231121-topic-sm8650-upstream-defconfig-v1-1-2500565fc21b@linaro.org>
Message-ID: <170204733625.342318.16325609104952222149.b4-ty@kernel.org>


On Tue, 21 Nov 2023 10:51:11 +0100, Neil Armstrong wrote:
> Enable Clocks, Pinctrl and Interconnect drivers in the ARM64
> defconfig for the Qualcomm SM8650 SoC to boot the SM8650 MTP
> (Mobile Test Platform) and QRD (Qualcomm Reference Device) boards.
> 
> TCSRCC, GCC, Interconnect, and Pinctrl config are marked as builtin and
> not modules due to boot dependencies.
> 
> [...]

Applied, thanks!

[1/1] arm64: deconfig: enable Qualcomm SM8650 SoC drivers
      commit: 17fc6f391932dfc8c11634667ca2d1d24c961cf5

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From andersson at kernel.org  Fri Dec  8 06:55:19 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Fri,  8 Dec 2023 06:55:19 -0800
Subject: (subset) [PATCH v3 00/12] RB1/QCM2290 features
In-Reply-To: <20231125-topic-rb1_feat-v3-0-4cbb567743bb@linaro.org>
References: <20231125-topic-rb1_feat-v3-0-4cbb567743bb@linaro.org>
Message-ID: <170204733634.342318.13908717706706425417.b4-ty@kernel.org>


On Wed, 29 Nov 2023 15:43:57 +0100, Konrad Dybcio wrote:
> This series brings:
> - interconnect plumbing
> - display setup
> 
> for QCM2290/QRB2210 and
> 
> - CAN bus controller
> - HDMI display
> - wifi fw variant name
> 
> [...]

Applied, thanks!

[04/12] dt-bindings: firmware: qcom,scm: Allow interconnect for everyone
        commit: 56fdc35ef067c8dffee22038dd3a84bb3fa6d2a4

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From gregory.clement at bootlin.com  Fri Dec  8 06:51:20 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 08 Dec 2023 15:51:20 +0100
Subject: [PATCH v2 0/3] Moxtet bus fixes
In-Reply-To: <20231128213536.3764212-1-sjoerd@collabora.com>
References: <20231128213536.3764212-1-sjoerd@collabora.com>
Message-ID: <87fs0ceoif.fsf@BL-laptop>

Hello Marek and Sjoerd,

> It seems the moxtet bus support was broken since 21aad8ba615e ("arm64:
> dts: armada-3720-turris-mox: Add missing interrupt for RTC") for two
> reasons:
> * The moxtet irq isn't marked as shared so the driver fails to load if
>   the rtc driver gets set up first.
> * The dts change didn't set the IRQ type, so in case the rtc driver got
>   probed first irq setup ended up wrong (rising instead of falling edge).
>
> On top of that the moxtet module isn't auto-loading due to a missing spi
> table
>
> Changes in v2:
> - Add cover letter
> - Add patch to set the irq type
>
> Sjoerd Simons (3):
>   bus: moxtet: Mark the irq as shared
>   bus: moxtet: Add spi device table
>   arm64: dts: armada-3720-turris-mox: set irq type for RTC

I only received the previous patch in my inbox, I plan to apply it. But
what about the 2 other patches ? Marek will you do a pull request with
these 2 patches or do you expect that I take them also ?

Regards,

Gregory


>
>  arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 +-
>  drivers/bus/moxtet.c                                   | 9 ++++++++-
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> -- 
> 2.43.0
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From andersson at kernel.org  Fri Dec  8 06:55:32 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Fri,  8 Dec 2023 06:55:32 -0800
Subject: [PATCH v3] arm64: defconfig: Enable GCC, pinctrl and interconnect for SDX75
In-Reply-To: <20231117055849.534671-1-quic_rohiagar@quicinc.com>
References: <20231117055849.534671-1-quic_rohiagar@quicinc.com>
Message-ID: <170204733621.342318.8169147134821175341.b4-ty@kernel.org>


On Fri, 17 Nov 2023 11:28:49 +0530, Rohit Agarwal wrote:
> Enable Global Clock controller, pinctrl and interconnect framework
> support for Qualcomm's SDX75 SoC which is required to boot to
> console on sdx75-idp platform.
> 
> 

Applied, thanks!

[1/1] arm64: defconfig: Enable GCC, pinctrl and interconnect for SDX75
      commit: 3515c3172f66ad4b3f485862f858f76a3e49c659

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From andersson at kernel.org  Fri Dec  8 06:55:36 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Fri,  8 Dec 2023 06:55:36 -0800
Subject: (subset) [PATCH V5 0/5] dts: qcom: Introduce X1E80100 platforms device tree
In-Reply-To: <20231205062403.14848-1-quic_sibis@quicinc.com>
References: <20231205062403.14848-1-quic_sibis@quicinc.com>
Message-ID: <170204733638.342318.11497127096348386267.b4-ty@kernel.org>


On Tue, 05 Dec 2023 11:53:58 +0530, Sibi Sankar wrote:
> This series adds the initial (clocks, pinctrl, rpmhpd, regulator, interconnect,
> CPU, SoC and board compatibles) device tree support to boot to shell on the
> Qualcomm X1E80100 platform, aka Snapdragon X Elite.
> 
> Our v1 post of the patchsets adding support for Snapdragon X Elite SoC had
> the part number sc8380xp which is now updated to the new part number x1e80100
> based on the new branding scheme and refers to the exact same SoC.
> 
> [...]

Applied, thanks!

[1/5] dt-bindings: arm: cpus: Add qcom,oryon compatible
      commit: bfea2924fc28b1b9985a208223f315992a68fc56
[2/5] dt-bindings: arm: qcom: Document X1E80100 SoC and boards
      commit: 7a85cecf98ca175d11b7133f7c4e88bbcc0fe5d3
[3/5] arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts
      commit: af16b00578a7a1d9fb99e81282b1b22cd8d32607
[4/5] arm64: dts: qcom: x1e80100: Add Compute Reference Device
      commit: bd50b1f5b6f38b2970841e78513c33fbd736cf40

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From conor at kernel.org  Fri Dec  8 06:57:35 2023
From: conor at kernel.org (Conor Dooley)
Date: Fri, 8 Dec 2023 14:57:35 +0000
Subject: [PATCH v2 1/4] dt-bindings: perf: fsl-imx-ddr: Add i.MX95
 compatible
In-Reply-To: <20231208085402.2106904-1-xu.yang_2@nxp.com>
References: <20231208085402.2106904-1-xu.yang_2@nxp.com>
Message-ID: <20231208-depress-smuggler-f3069487a067@spud>

On Fri, Dec 08, 2023 at 04:53:59PM +0800, Xu Yang wrote:
> i.MX95 has a DDR pmu. This will add a compatible for it.

On v1 we had a discussion because the commit message wasn't clear about
whether or not the device was compatible with existing ones. For some
reason, the v2 patch _removes_ information from the commit message
rather than tries to explain.
This [1] message of yours, that I didn't get a chance to reply to before
you sent this new version, seems to say that there should be an
imx93-ddr-pmu fallback.

Cheers,
Conor.

1 - https://lore.kernel.org/all/DB7PR04MB514668A8B172CD1A2187BC408C84A at DB7PR04MB5146.eurprd04.prod.outlook.com/

> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> ---
> Changes in v2:
>  - no changes
> ---
>  Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
> index e9fad4b3de68..1bc7bf1c8368 100644
> --- a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
> +++ b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
> @@ -20,6 +20,7 @@ properties:
>            - fsl,imx8mn-ddr-pmu
>            - fsl,imx8mp-ddr-pmu
>            - fsl,imx93-ddr-pmu
> +          - fsl,imx95-ddr-pmu
>        - items:
>            - enum:
>                - fsl,imx8mm-ddr-pmu
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/a53ad0cd/attachment.sig>

From gregory.clement at bootlin.com  Fri Dec  8 07:06:21 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 08 Dec 2023 16:06:21 +0100
Subject: [PATCH] MAINTAINERS: add Marvell MBus driver to Marvell EBU
 SoCs support
In-Reply-To: <20231121093414.11926-1-lukas.bulwahn@gmail.com>
References: <20231121093414.11926-1-lukas.bulwahn@gmail.com>
Message-ID: <87cyvgente.fsf@BL-laptop>

Lukas Bulwahn <lukas.bulwahn at gmail.com> writes:

> While doing some code cleanup in drivers/bus/, I noticed that the file
> drivers/bus/mvebu-mbus.c has no maintainer.
>
> Although the file has not been touched a lot lately, the git history tells
> us that Gregory Clement and Andrew Lunn integrated patches specific to
> this driver code. Further, the driver's config depends on config
> PLAT_ORION, and the code for this platform is defined in
> arch/arm/plat-orion/, which is part of ARM/Marvell Dove/MV78xx0/Orion SOC
> support with Gregory and Andrew already being its maintainer.
>
> Add drivers/bus/mvebu-mbus.c to ARM/Marvell Dove/MV78xx0/Orion SOC support.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn at gmail.com>

Applied on mvebu/arm

Thanks,

Gregory
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9cbf6e353bd..9613c9c3cc97 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2317,6 +2317,7 @@ F:	arch/arm/mach-dove/
>  F:	arch/arm/mach-mv78xx0/
>  F:	arch/arm/mach-orion5x/
>  F:	arch/arm/plat-orion/
> +F:	drivers/bus/mvebu-mbus.c
>  F:	drivers/soc/dove/
>  
>  ARM/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 SOC support
> -- 
> 2.17.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From eichest at gmail.com  Fri Dec  8 07:05:50 2023
From: eichest at gmail.com (Stefan Eichenberger)
Date: Fri, 8 Dec 2023 16:05:50 +0100
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-in-suspend property
In-Reply-To: <CACRpkdao83-nALj2YOq-XHrOh6GEaxufN3Fn+3W52qkL2x+VUQ@mail.gmail.com>
References: <20231207111300.80581-1-eichest@gmail.com>
 <20231207111300.80581-2-eichest@gmail.com>
 <CACRpkdbSs-vebvchxx-Tg+O5CUF5M3vZf-iytuW=ZECnHb2anA@mail.gmail.com>
 <ZXMV9gzFbc05IEKg@eichest-laptop>
 <CACRpkdao83-nALj2YOq-XHrOh6GEaxufN3Fn+3W52qkL2x+VUQ@mail.gmail.com>
Message-ID: <ZXMwzqF8tHZuWVBN@eichest-laptop>

Hi Linus,

On Fri, Dec 08, 2023 at 03:23:54PM +0100, Linus Walleij wrote:
> On Fri, Dec 8, 2023 at 2:11?PM Stefan Eichenberger <eichest at gmail.com> wrote:
> 
> > > I can't help but wonder: shouldn't that pretty much be the default behaviour
> > > if wakeup-source is *not* specified?
> > >
> > > I.e. the property kind of describes !wakeup-source.
> >
> > The maxtouch controller has a deep sleep mode which is currently used
> > without powering down vdd and vdda. However, because we have a shared
> > regulator which powers other peripherals that we want to shut down in
> > suspend we need a way to power down vdd and vdda. However, I agree this
> > is not really a feature of the device. The feature would basically be
> > the internal deep sleep mode.
> 
> While it is of no concern to the device tree bindings, Linux regulators
> are counting meaning that you need to make all peripherals disable
> their regulators and it will come down.

Yes we are working on that one. This is the last driver we need to allow
disabling the regulator, afterward it should hoepfully work on our
target system.

> 
> > I didn't want to change the default
> > behaviour of the driver, so I added this property but maybe I could
> > change it to:
> >
> > atmel,deep-sleep:
> >   description: |
> >      Use the maxtouch deep-sleep mode instead of powering down vdd and
> >      vdda.
> >
> > Or to not change the default behaviour:
> > atmel,no-deep-sleep:
> >   description: |
> >      Do not use the maxtouch deep-sleep mode but power down vdd and vdda
> >      in suspend.
> >
> > As I understand the datasheet even if the maxtouch is using its deep
> > sleep mode it does not act as a wakeup source.
> 
> Do you mean it can still work as a wakeup source in deep sleep mode?
> (there is a "not" too much above ...)

Sorry for the confusion. As it is configured now, it can not work as
wakeup source in deep sleep mode. Touch is completely disabled.

> > It is just faster in
> > waking up because it can keep the configuration in memory.
> 
> That sounds like a good reason to have the property, because that
> means that if you can control the wakeup latency and specify in the binding
> how much in absolute time units it is affected.
> 
> I would define it in positive terms instead of reverse "no-deep-sleep"
> though such as "atmel,fast-wakeup".
> 
> And: If you disable the regulators it will probably *not* be able to wake the
> system up, right? And that is just a few lines of code in the driver such as:
> 
> go_to_sleep():
>   if (!wakeup_source):
>      disable_regulators()

So to not change the default behaviour I would have to name it:
atmel,slow-wakeup
or maybe even full wakeup because it does a wakeup from the disabled
state?
atmel,full-wakeup

Exactly, the added code looks more or less exactly as you wrote. And on
resume it does the opposite + configure it:

resume():
  if (!wakeup_source):
     enable_regulators()
     configure_maxtouch()

Regards,
Stefan


From fancer.lancer at gmail.com  Fri Dec  8 07:07:06 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Fri, 8 Dec 2023 18:07:06 +0300
Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <hxds75erxqcfkufxnfbyo2up4b4jeicmi3f5xr6qlb3yf7fe76@4byeq62jhu4o>
References: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>
 <jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz@ntepnnzzelta>
 <hxds75erxqcfkufxnfbyo2up4b4jeicmi3f5xr6qlb3yf7fe76@4byeq62jhu4o>
Message-ID: <hgz3pt625kggix6kzincohw7kr2okcumrwfkmjgiauw2yvhrzt@ekeygo4b7k3b>

On Thu, Dec 07, 2023 at 05:07:24PM -0600, Andrew Halaney wrote:
> On Fri, Dec 08, 2023 at 01:16:12AM +0300, Serge Semin wrote:
> > On Thu, Dec 07, 2023 at 03:12:40PM -0600, Andrew Halaney wrote:
> > > The stmmac_dt_phy() function, which parses the devicetree node of the
> > > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > > fixed-link means in relation to the MAC's MDIO bus. This results in
> > > a MDIO bus being created in situations it need not be.
> > > 
> > > Currently a MDIO bus is created if the description is either:
> > > 
> > >     1. Not fixed-link
> > >     2. fixed-link but contains a MDIO bus as well
> > > 
> > > The "1" case above isn't always accurate. If there's a phy-handle,
> > > it could be referencing a phy on another MDIO controller's bus[1]. In
> > > this case currently the MAC will make a MDIO bus and scan it all
> > > anyways unnecessarily.
> > > 
> > > There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> > > be created and scanned for a phy. This case can also be inferred from
> > > the platform description by not having a phy-handle && not being
> > > fixed-link. This hits case "1" in the current driver's logic.
> > > 
> > > Let's improve the logic to create a MDIO bus if either:
> > > 
> > 
> > >     - Devicetree contains a MDIO bus
> > >     - !fixed-link && !phy-handle (legacy handling)
> > 
> > If what you suggest here is a free from regressions semantics change
> > (really hope it is) I will be with both my hands for it. This will
> > solve the problem we have with one of our device which doesn't have
> > SMA interface (hardware designers decided to save ~4K gates of the
> > chip area) but has a PHY externally attached to the DW XGMAC<->XPCS
> > interface. PHY is accessible via a GPIO-based MDIO bus. BTW having no
> > SMA interface available on a DW *MAC device but creating the MDIO-bus
> > on top of the non-existent SMA CSRs anyway causes having _32_ dummy
> > PHYs created with zero IDs.
> 

> I hope it is regression free! I have tested both the [1] and [2] cases
> (I hacked up the devicetree for [1] to make it look like [2]) without
> any issue.
> 

I doubt you could have tested it on all the possible hardware the
STMMAC driver supports. The problem is that the DT-bindings thing is a
kind of contract which can't be changed that easily. It's like ABI but
for the hardware description so the kernel would bootup correctly on
the platforms with the old DT blobs. But if the change isn't that
critical, if the device-tree sources in the kernel fit to the updated
semantics, if the networking subsystem maintainers aren't against it
and I guess with the Rob, Krzysztof or Conor blessing (at least it
won't hurt to add them to the Cc-list together with the devicetree
mailing-list), then it will likely be accepted.

> Sorry, I don't have any docs for stmmac hardware so this might be
> answered in there (or just common net knowledge that I can't find
> online)... what's SMA stand for? I assume it's the MDIO interface.

Right. Synopsys names the MDIO-bus interface as Station Management
Agent MDIO module.

> 
> I agree though, if you have a phy-handle and no mdio node in your
> devicetree this patch series should bail out without registering a bus
> in stmmac_mdio_register().

On the other hand why would the MDIO-bus needed in such case? If the
phy-handle property is specified with no MDIO-bus DT-subnode, then it
will point out to a PHY residing an external bus. The only case I can
imagine though is that the DW XPCS device could be still auto-detected
on the internal SMA-MDIO-bus. But the only driver which currently has
XPCS auto-detection activated is the Intel glue layer (see
dwmac-intel.c and has_xpcs flag), but it doesn't use DT interface
since it handles a PCIe-based device.  So this case is out of
brackets.

> 
> > 
> > > 
> > > Below upstream devicetree snippets can be found that explain some of
> > > the cases above more concretely.
> 
> <snip>
> 
> > > -	if (mdio) {
> > > -		plat->mdio_bus_data =
> > > -			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
> > > -				     GFP_KERNEL);
> > 
> > > +	/* Legacy devicetrees allowed for no MDIO bus description and expect
> > > +	 * the bus to be scanned for devices. If there's no phy or fixed-link
> > > +	 * described assume this is the case since there must be something
> > > +	 * connected to the MAC.
> > > +	 */
> > > +	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
> > > +	if (legacy_mdio)
> > > +		dev_info(dev, "Deprecated MDIO bus assumption used\n");
> > > +
> > > +	if (plat->mdio_node || legacy_mdio) {
> > > +		plat->mdio_bus_data = devm_kzalloc(dev,
> > 
> > Special thanks for adding the comment above this code. It will really
> > save time of figuring out why MDIO-bus needs to be created anyway.
> > 
> > > +						   sizeof(struct stmmac_mdio_bus_data),
> > 
> > Should v4 is required I would suggest to change this to
> > sizeof(*plat->mdio_bus_data).
> > 
> > Anyway feel free to add:
> > Reviewed-by: Serge Semin <fancer.lancer at gmail.com>
> > 
> > -Serge(y)
> 

> Sure I will spin v4 to pick that up, thanks for catching it. I'll also
> improve the motivation in the commit message a hair more per Andrew
> Lunn's request over here on v2 (and will hold off a little bit just to
> make sure reviews come in before a respin):
> 
>     https://lore.kernel.org/netdev/e64b14c3-4b80-4120-8cc4-9baa40cdcb75 at lunn.ch/

Ok. Thanks.

-Serge(y)

> 
> Thanks,
> Andrew
> 


From umang.jain at ideasonboard.com  Fri Dec  8 07:07:47 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Fri,  8 Dec 2023 20:37:47 +0530
Subject: [PATCH v3 1/8] media: dt-bindings: media: imx335: Add supply bindings
In-Reply-To: <20231208150756.124720-1-umang.jain@ideasonboard.com>
References: <20231208150756.124720-1-umang.jain@ideasonboard.com>
Message-ID: <20231208150756.124720-2-umang.jain@ideasonboard.com>

From: Kieran Bingham <kieran.bingham at ideasonboard.com>

Add the bindings for the supply references used on the IMX335.

Reviewed-by: Umang Jain <umang.jain at ideasonboard.com>
Reviewed-by: Marco Felsch <m.felsch at pengutronix.de>
Signed-off-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
 .../devicetree/bindings/media/i2c/sony,imx335.yaml  | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
index a167dcdb3a32..106c36ee966d 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
@@ -32,6 +32,15 @@ properties:
     description: Clock frequency from 6 to 27 MHz, 37.125MHz, 74.25MHz
     maxItems: 1
 
+  avdd-supply:
+    description: Analog power supply (2.9V)
+
+  ovdd-supply:
+    description: Interface power supply (1.8V)
+
+  dvdd-supply:
+    description: Digital power supply (1.2V)
+
   reset-gpios:
     description: Reference to the GPIO connected to the XCLR pin, if any.
     maxItems: 1
@@ -79,6 +88,10 @@ examples:
             assigned-clock-parents = <&imx335_clk_parent>;
             assigned-clock-rates = <24000000>;
 
+            avdd-supply = <&camera_vdda_2v9>;
+            ovdd-supply = <&camera_vddo_1v8>;
+            dvdd-supply = <&camera_vddd_1v2>;
+
             port {
                 imx335: endpoint {
                     remote-endpoint = <&cam>;
-- 
2.41.0



From robh at kernel.org  Fri Dec  8 07:10:11 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 8 Dec 2023 09:10:11 -0600
Subject: [RFC PATCH v3 2/5] i2c: of: Introduce component probe function
In-Reply-To: <CAD=FV=U_+iQJtV0Wii89DQT1V_fJCeS9wcqA8EJAs-hmmmLLLg@mail.gmail.com>
References: <20231128084236.157152-1-wenst@chromium.org>
 <20231128084236.157152-3-wenst@chromium.org>
 <CAD=FV=U_+iQJtV0Wii89DQT1V_fJCeS9wcqA8EJAs-hmmmLLLg@mail.gmail.com>
Message-ID: <20231208151011.GA1289359-robh@kernel.org>

On Fri, Dec 01, 2023 at 04:57:46PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Tue, Nov 28, 2023 at 12:45?AM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >
> > @@ -217,4 +217,114 @@ static int of_i2c_notify(struct notifier_block *nb, unsigned long action,
> >  struct notifier_block i2c_of_notifier = {
> >         .notifier_call = of_i2c_notify,
> >  };
> > +
> > +/*
> > + * Some devices, such as Google Hana Chromebooks, are produced by multiple
> > + * vendors each using their preferred components. Such components are all
> > + * in the device tree. Instead of having all of them enabled and having each
> > + * driver separately try and probe its device while fighting over shared
> > + * resources, they can be marked as "fail-needs-probe" and have a prober
> > + * figure out which one is actually used beforehand.
> > + *
> > + * This prober assumes such drop-in parts are on the same I2C bus, have
> > + * non-conflicting addresses, and can be directly probed by seeing which
> > + * address responds.
> > + *
> > + * TODO:
> > + * - Support handling common regulators and GPIOs.
> 
> IMO you should prototype how you're going to handle regulators and
> GPIOs before finalizing the design. I was going to write that you
> should just document that it was up to the caller to power things up
> before calling this function, but then I realized that the caller
> would have to duplicate much of this function in order to do so. In
> the very least they'd have to find the nodes of the relevant devices
> so that they could grab regulators and/or GPIOs. In order to avoid
> this duplication, would the design need to change? Perhaps this would
> be as simple as adding a callback function here that's called with all
> of the nodes before probing? If that's right, it would be nice to have
> that callback from the beginning so we don't need two variants of the
> function...
> 
> > + * - Support I2C muxes
> > + */
> > +
> > +/**
> > + * i2c_of_probe_component() - probe for devices of "type" on the same i2c bus
> > + * @dev: &struct device of the caller, only used for dev_* printk messages
> > + * @type: a string to match the device node name prefix to probe for
> > + *
> > + * Probe for possible I2C components of the same "type" on the same I2C bus
> > + * that have their status marked as "fail".
> 
> Should document these current limitations with the code:
> 
> * Assumes that across the entire device tree the only instances of
> nodes named "type" are ones we're trying to handle second sourcing
> for. In other words if we're searching for "touchscreen" then all
> nodes named "touchscreen" are ones that need to be probed.

named "type" and marked as needs probe.

> 
> * Assumes that there is exactly one group of each "type". In other
> words, if we're searching for "touchscreen" then exactly one
> touchscreen will be enabled across the whole tree.

Does that need to be a limitation? If you just keep going thru all 
devices, wouldn't that just work?

Rob


From gregory.clement at bootlin.com  Fri Dec  8 07:10:20 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 08 Dec 2023 16:10:20 +0100
Subject: [PATCH v9 1/3] ARM: dts: marvell: Fix some common switch mistakes
In-Reply-To: <20231127-mv88e6xxx-mvebu-fixes-v9-1-d19b963e81fb@linaro.org>
References: <20231127-mv88e6xxx-mvebu-fixes-v9-0-d19b963e81fb@linaro.org>
 <20231127-mv88e6xxx-mvebu-fixes-v9-1-d19b963e81fb@linaro.org>
Message-ID: <87a5qkenmr.fsf@BL-laptop>

Linus Walleij <linus.walleij at linaro.org> writes:

> Fix some errors in the Marvell MV88E6xxx switch descriptions:
> - The top node had no address size or cells.
> - switch0 at 0 is not OK, should be ethernet-switch at 0.
> - The ports node should be named ethernet-ports
> - The ethernet-ports node should have port at 0 etc children, no
>   plural "ports" in the children.
> - Ports should be named ethernet-port at 0 etc
> - PHYs should be named ethernet-phy at 0 etc
>
> This serves as an example of fixes needed for introducing a
> schema for the bindings, but the patch can simply be applied.
>
> Reviewed-by: Andrew Lunn <andrew at lunn.ch>
> Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Applied on mvebu/dt

Thanks,

Gregory

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Fri Dec  8 07:11:04 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 08 Dec 2023 16:11:04 +0100
Subject: [PATCH v9 2/3] ARM64: dts: marvell: Fix some common switch
 mistakes
In-Reply-To: <20231127-mv88e6xxx-mvebu-fixes-v9-2-d19b963e81fb@linaro.org>
References: <20231127-mv88e6xxx-mvebu-fixes-v9-0-d19b963e81fb@linaro.org>
 <20231127-mv88e6xxx-mvebu-fixes-v9-2-d19b963e81fb@linaro.org>
Message-ID: <877cloenlj.fsf@BL-laptop>

Linus Walleij <linus.walleij at linaro.org> writes:

> Fix some errors in the Marvell MV88E6xxx switch descriptions:
> - The top node had no address size or cells.
> - switch0 at 0 is not OK, should be ethernet-switch at 0.
> - ports should be ethernet-ports
> - port at 0 should be ethernet-port at 0
> - PHYs should be named ethernet-phy@
>
> Reviewed-by: Andrew Lunn <andrew at lunn.ch>
> Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Applied on mvebu/dt64

Thanks,

Gregory

> ---
>  .../dts/marvell/armada-3720-espressobin-ultra.dts  | 14 ++--
>  .../boot/dts/marvell/armada-3720-espressobin.dtsi  | 20 +++--
>  .../boot/dts/marvell/armada-3720-gl-mv1000.dts     | 20 +++--
>  .../boot/dts/marvell/armada-3720-turris-mox.dts    | 85 ++++++++++++----------
>  .../boot/dts/marvell/armada-7040-mochabin.dts      | 24 +++---
>  .../dts/marvell/armada-8040-clearfog-gt-8k.dts     | 22 +++---
>  arch/arm64/boot/dts/marvell/cn9130-crb.dtsi        | 42 +++++------
>  7 files changed, 115 insertions(+), 112 deletions(-)

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Fri Dec  8 07:11:52 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 08 Dec 2023 16:11:52 +0100
Subject: [PATCH v9 3/3] ARM64: dts: Add special compatibles for the
 Turris Mox
In-Reply-To: <20231127-mv88e6xxx-mvebu-fixes-v9-3-d19b963e81fb@linaro.org>
References: <20231127-mv88e6xxx-mvebu-fixes-v9-0-d19b963e81fb@linaro.org>
 <20231127-mv88e6xxx-mvebu-fixes-v9-3-d19b963e81fb@linaro.org>
Message-ID: <874jgsenk7.fsf@BL-laptop>

Linus Walleij <linus.walleij at linaro.org> writes:

> These special compatibles are added to the Marvell Armada 3720
> Turris Mox in order to be able to special-case and avoid
> warnings on the non-standard nodenames that are ABI on this
> one board due to being used in deployed versions of U-Boot.
>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Applied on mvebu/dt64

Thanks,

Gregory
> ---
>  arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From kabel at kernel.org  Fri Dec  8 07:17:24 2023
From: kabel at kernel.org (Marek =?UTF-8?B?QmVow7pu?=)
Date: Fri, 8 Dec 2023 16:17:24 +0100
Subject: [PATCH v2 0/3] Moxtet bus fixes
In-Reply-To: <87fs0ceoif.fsf@BL-laptop>
References: <20231128213536.3764212-1-sjoerd@collabora.com>
	<87fs0ceoif.fsf@BL-laptop>
Message-ID: <20231208161724.5f4f626a@dellmb>

On Fri, 08 Dec 2023 15:51:20 +0100
Gregory CLEMENT <gregory.clement at bootlin.com> wrote:

> Hello Marek and Sjoerd,
> 
> > It seems the moxtet bus support was broken since 21aad8ba615e ("arm64:
> > dts: armada-3720-turris-mox: Add missing interrupt for RTC") for two
> > reasons:
> > * The moxtet irq isn't marked as shared so the driver fails to load if
> >   the rtc driver gets set up first.
> > * The dts change didn't set the IRQ type, so in case the rtc driver got
> >   probed first irq setup ended up wrong (rising instead of falling edge).
> >
> > On top of that the moxtet module isn't auto-loading due to a missing spi
> > table
> >
> > Changes in v2:
> > - Add cover letter
> > - Add patch to set the irq type
> >
> > Sjoerd Simons (3):
> >   bus: moxtet: Mark the irq as shared
> >   bus: moxtet: Add spi device table
> >   arm64: dts: armada-3720-turris-mox: set irq type for RTC  
> 
> I only received the previous patch in my inbox, I plan to apply it. But
> what about the 2 other patches ? Marek will you do a pull request with
> these 2 patches or do you expect that I take them also ?
> 
> Regards,
> 
> Gregory

Gregory, as of yet I've never done a pull request. If you are willing
to take all 3 patches now, please do. In the future I would like to
start doing it for Turris stuff, if you are OK with it.

Marek


From neil.armstrong at linaro.org  Fri Dec  8 07:18:33 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Fri, 08 Dec 2023 16:18:33 +0100
Subject: [PATCH v2 0/2] Add some devices nodes for S4.
In-Reply-To: <20231208-s4-dts-v2-0-5a93fa356c5d@amlogic.com>
References: <20231208-s4-dts-v2-0-5a93fa356c5d@amlogic.com>
Message-ID: <170204871348.55256.16571594130908656997.b4-ty@linaro.org>

Hi,

On Fri, 08 Dec 2023 15:16:25 +0800, Xianwei Zhao wrote:
> Add some device nodes for SoC S4, including periphs clock controller
> node, PLL clock controller node, I2C nodes, SPICC node, NAND
> controller node, Ethernet MAC and PHY node.
> 
> Add reserved memory for board AQ222 which is used by ATF.
> Enable NAND, SPICC nodes for board AQ222.
> 
> [...]

Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.8/arm64-dt)

[1/2] arm64: dts: amlogic: add some device nodes for S4
      https://git.kernel.org/amlogic/c/528016cd2b52001564792c4a68483d44a6fbedad
[2/2] arm64: dts: amlogic: enable some nodes for board AQ222
      https://git.kernel.org/amlogic/c/66fdf773ccffcb5b6673f0a5b6693739e33b5181

These changes has been applied on the intermediate git tree [1].

The v6.8/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.

In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].

The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.

If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

-- 
Neil



From robh at kernel.org  Fri Dec  8 07:29:08 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 8 Dec 2023 09:29:08 -0600
Subject: [PATCH v2 1/5] pmdomain: rockchip: Add missing powerdomains for
 RK3128
In-Reply-To: <20231202125144.66052-2-knaerzche@gmail.com>
References: <20231202125144.66052-1-knaerzche@gmail.com>
 <20231202125144.66052-2-knaerzche@gmail.com>
Message-ID: <20231208152908.GA1378274-robh@kernel.org>

On Sat, Dec 02, 2023 at 01:51:40PM +0100, Alex Bee wrote:
> For RK3128 the powerdomains PD_PERI, PD_SYS and PD_CRYPTO are currently
> missing.
> Add them.
> 
> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> ---
>  drivers/pmdomain/rockchip/pm-domains.c   | 13 ++++++++-----
>  include/dt-bindings/power/rk3128-power.h |  3 +++

Bindings (and DT headers are bindings) should be separate patch.

Rob


From james.clark at arm.com  Fri Dec  8 07:31:32 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 8 Dec 2023 15:31:32 +0000
Subject: [PATCH V3 08/10] coresight: tmc: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <20231208053939.42901-9-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
 <20231208053939.42901-9-anshuman.khandual@arm.com>
Message-ID: <22cfb197-b8bd-46c5-f3cb-ea04b95c0792@arm.com>



On 08/12/2023 05:39, Anshuman Khandual wrote:
> Add support for the tmc devices in the platform driver, which can then be
> used on ACPI based platforms. This change would now allow runtime power
> management for ACPI based systems. The driver would try to enable the APB
> clock if available.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Cc: Mike Leach <mike.leach at linaro.org>
> Cc: James Clark <james.clark at arm.com>
> Cc: linux-acpi at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: coresight at lists.linaro.org
> Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
> Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
> Changes in V3:
> 
> - Added commnets for 'drvdata->pclk'
> - Used coresight_init_driver()/coresight_remove_driver() helpers instead
> - Dropped pm_runtime_put() from __tmc_probe()
> - Added pm_runtime_put() on success path in tmc_probe()
> - Added pm_runtime_put() on success/error paths in tmc_platform_probe()
> - Check for drvdata instead of drvdata->pclk in suspend and resume paths
> 
>  drivers/acpi/arm64/amba.c                     |   2 -
>  .../hwtracing/coresight/coresight-tmc-core.c  | 137 ++++++++++++++++--
>  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
>  3 files changed, 124 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
> index 6d24a8f7914b..d3c1defa7bc8 100644
> --- a/drivers/acpi/arm64/amba.c
> +++ b/drivers/acpi/arm64/amba.c
> @@ -22,10 +22,8 @@
>  static const struct acpi_device_id amba_id_list[] = {
>  	{"ARMH0061", 0}, /* PL061 GPIO Device */
>  	{"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
> -	{"ARMHC501", 0}, /* ARM CoreSight ETR */
>  	{"ARMHC502", 0}, /* ARM CoreSight STM */
>  	{"ARMHC503", 0}, /* ARM CoreSight Debug */
> -	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
>  	{"", 0},
>  };
>  
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
> index ad61d02f5f75..8482830d73ef 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-core.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
> @@ -23,6 +23,8 @@
>  #include <linux/of.h>
>  #include <linux/coresight.h>
>  #include <linux/amba/bus.h>
> +#include <linux/platform_device.h>
> +#include <linux/acpi.h>
>  
>  #include "coresight-priv.h"
>  #include "coresight-tmc.h"
> @@ -437,24 +439,17 @@ static u32 tmc_etr_get_max_burst_size(struct device *dev)
>  	return burst_size;
>  }
>  
> -static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
> +static int __tmc_probe(struct device *dev, struct resource *res, void *dev_caps)

I don't think the dev_caps argument is used anymore since the v3 changes.



From james.clark at arm.com  Fri Dec  8 07:32:07 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 8 Dec 2023 15:32:07 +0000
Subject: [PATCH V3 00/10] coresight: Move remaining AMBA ACPI devices into
 platform driver
In-Reply-To: <20231208053939.42901-1-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
Message-ID: <b7270822-efe5-da15-49ea-0028031e38ce@arm.com>



On 08/12/2023 05:39, Anshuman Khandual wrote:
> This moves remaining AMBA ACPI devices into respective platform drivers for
> enabling ACPI based power management support. This series applies on latest
> coresight/next branch. This series has been built, and boot tested on a DT
> based coresight platform. Although this still requires some more testing on
> ACPI based coresight platforms.
> 
> https://git.gitlab.arm.com/linux-arm/linux-anshuman.git (amba_other_acpi_migration_v3)
> 

Reviewed-by: James Clark <james.clark at arm.com>

> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Cc: Mike Leach <mike.leach at linaro.org>
> Cc: James Clark <james.clark at arm.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> Cc: linux-acpi at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: coresight at lists.linaro.org
> Cc: linux-stm32 at st-md-mailman.stormreply.com
> 
> Changes in V3:
> 
> - Split coresight_init_driver/remove_driver() helpers into a separate patch
> - Added 'drvdata->pclk' comments in replicator, funnel, tpiu, tmc, and stm devices
> - Updated funnel, and replicator drivers to use these new helpers
> - Check for drvdata instead of drvdata->pclk in suspend and resume paths in catu,
>   tmc and debug devices
> - Added patch to extract device name from AMBA pid based table lookup for stm
> - Added patch to extract device properties from AMBA pid based table look for tmc
> - Dropped pm_runtime_put() from common __probe() functions
> - Handled pm_runtime_put() in AMBA driver in success path
> - Handled pm_runtime_put() in platform driver in both success and error paths
> 
> Changes in V2:
> 
> https://lore.kernel.org/all/20231201062053.1268492-1-anshuman.khandual at arm.com/
> 
> - Dropped redundant devm_ioremap_resource() hunk from tmc_platform_probe()
> - Defined coresight_[init|remove]_driver() for both AMBA/platform drivers
> - Changed catu, tmc, tpiu, stm and debug coresight drivers to use the new
>   helpers avoiding build issues arising from module_amba_driver(), and
>   module_platform_driver() being on the same file
> 
> Changes in V1:
> 
> https://lore.kernel.org/all/20231027072943.3418997-1-anshuman.khandual at arm.com/
> 
> - Replaced all IS_ERR() instances with IS_ERR_OR_NULL() as per Suzuki
> 
> Changes in RFC:
> 
> https://lore.kernel.org/all/20230921042040.1334641-1-anshuman.khandual at arm.com/
> 
> Anshuman Khandual (10):
>   coresight: stm: Extract device name from AMBA pid based table lookup
>   coresight: tmc: Extract device properties from AMBA pid based table lookup
>   coresight: Add helpers registering/removing both AMBA and platform drivers
>   coresight: replicator: Move ACPI support from AMBA driver to platform driver
>   coresight: funnel: Move ACPI support from AMBA driver to platform driver
>   coresight: catu: Move ACPI support from AMBA driver to platform driver
>   coresight: tpiu: Move ACPI support from AMBA driver to platform driver
>   coresight: tmc: Move ACPI support from AMBA driver to platform driver
>   coresight: stm: Move ACPI support from AMBA driver to platform driver
>   coresight: debug: Move ACPI support from AMBA driver to platform driver
> 
>  drivers/acpi/arm64/amba.c                     |   8 -
>  drivers/hwtracing/coresight/coresight-catu.c  | 140 +++++++++++++---
>  drivers/hwtracing/coresight/coresight-catu.h  |   1 +
>  drivers/hwtracing/coresight/coresight-core.c  |  29 ++++
>  .../hwtracing/coresight/coresight-cpu-debug.c | 141 ++++++++++++++--
>  .../hwtracing/coresight/coresight-funnel.c    |  87 +++++-----
>  drivers/hwtracing/coresight/coresight-priv.h  |  10 ++
>  .../coresight/coresight-replicator.c          |  81 ++++-----
>  drivers/hwtracing/coresight/coresight-stm.c   | 115 +++++++++++--
>  .../hwtracing/coresight/coresight-tmc-core.c  | 156 +++++++++++++++---
>  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
>  drivers/hwtracing/coresight/coresight-tpiu.c  |  99 +++++++++--
>  include/linux/coresight.h                     |   7 +
>  13 files changed, 713 insertions(+), 163 deletions(-)
> 


From gregory.clement at bootlin.com  Fri Dec  8 07:33:10 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 08 Dec 2023 16:33:10 +0100
Subject: [PATCH v3 5/5] ARM: dts: marvell: make dts use gpio-fan matrix
 instead of array
In-Reply-To: <20231202222934.137191-5-david@ixit.cz>
References: <20231202222934.137191-1-david@ixit.cz>
 <20231202222934.137191-5-david@ixit.cz>
Message-ID: <87y1e4d809.fsf@BL-laptop>

David Heidelberg <david at ixit.cz> writes:

> No functional changes.
>
> Adjust to comply with dt-schema requirements
> and make possible to validate values.
>
> Acked-by: Simon Guinot <simon.guinot at sequanux.org>
> Signed-off-by: David Heidelberg <david at ixit.cz>

Applied on mvebu/dt

Thanks,

Gregory
> ---
>  arch/arm/boot/dts/marvell/armada-370-rd.dts   |   2 +-
>  .../marvell/armada-370-seagate-nas-2bay.dts   |   8 +-
>  .../marvell/armada-370-seagate-nas-4bay.dts   |   8 +-
>  .../marvell/armada-370-synology-ds213j.dts    |  16 +--
>  .../dts/marvell/armada-385-synology-ds116.dts |  16 +--
>  arch/arm/boot/dts/marvell/armada-388-gp.dts   |   4 +-
>  arch/arm/boot/dts/marvell/kirkwood-dnskw.dtsi |   6 +-
>  .../marvell/kirkwood-linkstation-6282.dtsi    |   9 +-
>  .../marvell/kirkwood-linkstation-lswxl.dts    |   9 +-
>  arch/arm/boot/dts/marvell/kirkwood-lsxl.dtsi  |   9 +-
>  arch/arm/boot/dts/marvell/kirkwood-ns2max.dts |  18 ++--
>  .../arm/boot/dts/marvell/kirkwood-ns2mini.dts |  18 ++--
>  .../boot/dts/marvell/kirkwood-synology.dtsi   | 102 +++++++++---------
>  .../dts/marvell/mvebu-linkstation-fan.dtsi    |   8 +-
>  14 files changed, 121 insertions(+), 112 deletions(-)
-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From sumitg at nvidia.com  Fri Dec  8 07:34:32 2023
From: sumitg at nvidia.com (Sumit Gupta)
Date: Fri, 8 Dec 2023 21:04:32 +0530
Subject: [PATCH v2 2/2] cpufreq: Wire-up arch-flavored freq info into
 cpufreq_verify_current_freq
In-Reply-To: <ZXGOvsE4mKOsdoLp@arm.com>
References: <20231127160838.1403404-1-beata.michalska@arm.com>
 <20231127160838.1403404-3-beata.michalska@arm.com> <ZWXy0h/fFfQh+Rhy@arm.com>
 <3e6077bb-907c-057f-0896-d0a5814a4229@nvidia.com> <ZW8D5TfSwuJfdYeD@arm.com>
 <c8b4d391-681e-f4a6-2839-e5951429f043@nvidia.com> <ZXGOvsE4mKOsdoLp@arm.com>
Message-ID: <2cfbc633-1e94-d741-2337-e1b0cf48b81b@nvidia.com>



>>>>>> --- a/drivers/cpufreq/cpufreq.c
>>>>>> +++ b/drivers/cpufreq/cpufreq.c
>>>>>> @@ -1756,7 +1756,8 @@ static unsigned int cpufreq_verify_current_freq(struct cpufreq_policy *policy, b
>>>>>>     {
>>>>>>          unsigned int new_freq;
>>>>>>
>>>>>> -     new_freq = cpufreq_driver->get(policy->cpu);
>>>>>> +     new_freq = arch_freq_get_on_cpu(policy->cpu);
>>>>>> +     new_freq = new_freq ?: cpufreq_driver->get(policy->cpu);
>>>>>
>>>>> Given that arch_freq_get_on_cpu() is an average frequency, it does not
>>>>> seem right to me to trigger the sync & update process of
>>>>> cpufreq_verify_current_freq() based on it.
>>>>>
>>>>> cpufreq_verify_current_freq() will at least modify the internal state of
>>>>> the policy and send PRE and POST notifications, if not do a full frequency
>>>>> update, based on this average frequency, which is likely different from
>>>>> the current frequency, even beyond the 1MHz threshold.
>>>>>
>>>>> While I believe it's okay to return this average frequency in
>>>>> cpuinfo_cur_freq, I don't think it should be used as an indication of
>>>>> an accurate current frequency, which is what
>>>>> cpufreq_verify_current_freq() expects.
>>>>>
>>>>> Sumit, can you give more details on the issue at [1] and why this change
>>>>> fixes it?
>>>>>
>>>>> [1] https://lore.kernel.org/lkml/6a5710f6-bfbb-5dfd-11cd-0cd02220cee7 at nvidia.com/
>>>>>
>>>>> Thank you,
>>>>> Ionela.
>>>>>
>>>> cpufreq_verify_current_freq() also updates 'policy->cur' in POST
>>>> notification if the frequency from hardware has more delta (out of sync).
>>>>
>>>> As the value from 'cpufreq_driver->get()' is not reliable due to [1],
>>>> calling the 'get' hook can update the 'policy->cur' with a wrong value when
>>>> governor starts in cpufreq_start_governor().
>>>> And if the frequency is never changed after the governor starts during
>>>> boot e.g. when performance governor is set as default, then
>>>> 'scaling_cur_freq' always returns wrong value.
>>>>
>>>> Instead, the arch_freq_get_on_cpu() API updates 'policy->cur' with a more
>>>> stable freq value.
>>>>
>>>> [1] https://lore.kernel.org/lkml/20230418113459.12860-7-sumitg at nvidia.com/
>>>
>>> Got it, many thanks!
>>>
>>> As the code is right now in v2, arch_freq_get_on_cpu() is called on
>>> show_scaling_cur_freq(), so the problem you describe would not show up.
>>> policy->cur would still be incorrect, but 'scaling_cur_freq' would
>>> return the value from arch_freq_get_on_cpu().
>>>
>>> Would it be enough if arch_freq_get_on_cpu() gets also called from
>>> show_cpuinfo_cur_freq() instead of cpufreq_verify_current_freq()?
>>>
>>> Thanks,
>>> Ionela.
>>>
>>
>> Yes.
>> I am not sure if making both the nodes 'scaling_cur_freq' and
>> 'cpuinfo_cur_freq' same is fine?
> 
> That would happen anyway if arch_freq_get_on_cpu() is called from
> cpufreq_verify_current_freq().
> 
Yes, that will happen in both the cases.

> In principle, according to [1], it would be correct to use it for
> 'cpuinfo_cur_freq' and not 'scaling_cur_freq'. But the call from
> show_scaling_cur_freq() is already there before these patches,
> introduced a long time ago for x86.
> 
> The topic was discussed at [2] and the agreement so far was that it
> would be best to keep the behaviour the same for both x86 and arm.
> 
Looking at the previous discussion in [2], seems to be fine.

Best Regards,
Sumit Gupta

> I don't like going against the user-guide, but these patches don't
> actually go against the user-guide. The old call to
> arch_freq_get_on_cpu() from show_scaling_cur_freq() goes against it.
> But I agree that's something necessary to keep, as legacy for x86.
> Additionally, you also mentioned that you'd prefer to have a more
> accurate frequency returned for 'scaling_cur_freq'.
> 
> [1] https://www.kernel.org/doc/Documentation/cpu-freq/user-guide.txt
> [2] https://lore.kernel.org/lkml/20230609043922.eyyqutbwlofqaddz at vireshk-i7/
> 
> Thanks,
> Ionela.
> 
>>
>> Best Regards,
>> Sumit Gupta


From thierry.reding at gmail.com  Fri Dec  8 07:41:39 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 8 Dec 2023 16:41:39 +0100
Subject: [PATCH v4 000/115] pwm: Fix lifetime issues for pwm_chips
In-Reply-To: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <ZXM4CdJxg-XrYhkn@orome.fritz.box>

On Wed, Dec 06, 2023 at 12:43:14PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> This series is based on Thierry's for-next.
> 
> It starts with some cleanups that were all sent out separately already:
> 
>  - "pwm: Reduce number of pointer dereferences in pwm_device_request()"
>    https://lore.kernel.org/linux-pwm/20231130072105.966848-1-u.kleine-koenig at pengutronix.de
>  - "pwm: crc: Use consistent variable naming for driver data"
>    https://lore.kernel.org/linux-pwm/20231130074133.969806-1-u.kleine-koenig at pengutronix.de
>  - Two leds/qcom-lpg patches
>    https://lore.kernel.org/linux-leds/20231126095230.683204-1-u.kleine-koenig at pengutronix.de
>    Lee already claimed to have taken the series already, but it's not yet in
>    next.
>  - "leds: qcom-lpg: Introduce a wrapper for getting driver data from a pwm chip"
>    https://lore.kernel.org/linux-leds/20231124215208.616551-3-u.kleine-koenig at pengutronix.de
> 
> In the following patches I changed:
> 
>  - "pwm: cros-ec: Change prototype of helper to prepare further changes" +
>    This was simplified in response to feedback by Tzung-Bi Shih
>  - Make pwmchip_priv() static (and don't export it), let drivers use a new
>    pwmchip_get_drvdata() instead.
>  - For drm/ti-sn65dsi86.c and leds/qcom-lpg make use of
>    pwmchip_set_drvdata() which makes the conversion to
>    devm_pwmchip_alloc() much prettier.
>  - Some cleanups here and there
>  - Add review tags received in v3
>    I kept all tags even though the pwmchip_alloc() patches changed
>    slightly. Most of the time that's only
>    s/pwmchip_priv/pwmchip_get_drvdata/ though. Still, if you object,
>    just tell me. (This affects Paul Cercueil on patch #68, Conor Dooley
>    on patch #76 and Greg for patch #109.)
> 
> I kept the pwmchip_alloc() + pwmchip_register() approach despite Bart
> not liking it. To balance that out I don't like Bart's alternative
> approach. There are no technically relevant differences between the two
> approaches and no benchmarks that show either of the two to be better
> than the other. Conceptually the design ideas around pwmchip_alloc() +
> pwmchip_register() are used in several other subsystems, so it's a
> proven way to do things.

[Trimming the recipients, keeping only Bart and the mailing lists.]

I do think there are technically relevant differences. For one, the
better we isolate the internal data structure, the easier this becomes
to manage. I'm attaching a patch that I've prototyped which should
basically get us to somewhere around patch 110 of this series but with
something like 1/8th of the changes. It doesn't need every driver to
change and (mostly) decouples driver code from the core code.

Now, I know that you think this is all bad because it's not a single
allocation, but I much prefer the end result because it's got the driver
and internals much more cleanly separated. Going forward I think it
would be easier to apply all the ref-counting on top of that because we
only need to keep the PWM framework-internal data structure alive after
a PWM chip has gone away.

Thierry
-------------- next part --------------
From 72ea79887d96850f9ccc832ce52b907ca276c940 Mon Sep 17 00:00:00 2001
From: Thierry Reding <thierry.reding at gmail.com>
Date: Tue, 28 Nov 2023 15:42:39 +0100
Subject: [PATCH] pwm: Isolate internal data into a separate structure

In order to prepare for proper reference counting of PWM chips and PWM
devices, move the internal data from the public PWM chip to a private
PWM chip structure. This ensures that the data that the subsystem core
may need to reference later on can stick around beyond the lifetime of
the driver-private data.

Signed-off-by: Thierry Reding <thierry.reding at gmail.com>
---
 drivers/pwm/core.c            | 185 +++++++++++++++++++++-------------
 drivers/pwm/internal.h        |  38 +++++++
 drivers/pwm/pwm-atmel-hlcdc.c |   8 +-
 drivers/pwm/pwm-fsl-ftm.c     |   6 +-
 drivers/pwm/pwm-lpc18xx-sct.c |   4 +-
 drivers/pwm/pwm-lpss.c        |  14 +--
 drivers/pwm/pwm-pca9685.c     |   6 +-
 drivers/pwm/pwm-samsung.c     |   6 +-
 drivers/pwm/pwm-sifive.c      |   4 +-
 drivers/pwm/pwm-stm32-lp.c    |   6 +-
 drivers/pwm/pwm-stm32.c       |   6 +-
 drivers/pwm/pwm-tiecap.c      |   6 +-
 drivers/pwm/pwm-tiehrpwm.c    |   6 +-
 drivers/pwm/sysfs.c           |  48 ++++-----
 include/linux/pwm.h           |  26 +----
 15 files changed, 228 insertions(+), 141 deletions(-)
 create mode 100644 drivers/pwm/internal.h

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f60b715abe62..54d57dec6dce 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -24,17 +24,19 @@
 #define CREATE_TRACE_POINTS
 #include <trace/events/pwm.h>
 
+#include "internal.h"
+
 static DEFINE_MUTEX(pwm_lookup_lock);
 static LIST_HEAD(pwm_lookup_list);
 
-/* protects access to pwmchip_idr */
+/* protects access to pwm_chips */
 static DEFINE_MUTEX(pwm_lock);
 
-static DEFINE_IDR(pwmchip_idr);
+static DEFINE_IDR(pwm_chips);
 
 static struct pwm_chip *pwmchip_find_by_name(const char *name)
 {
-	struct pwm_chip *chip;
+	struct pwm_chip_private *priv;
 	unsigned long id, tmp;
 
 	if (!name)
@@ -42,12 +44,12 @@ static struct pwm_chip *pwmchip_find_by_name(const char *name)
 
 	mutex_lock(&pwm_lock);
 
-	idr_for_each_entry_ul(&pwmchip_idr, chip, tmp, id) {
-		const char *chip_name = dev_name(chip->dev);
+	idr_for_each_entry_ul(&pwm_chips, priv, tmp, id) {
+		const char *chip_name = dev_name(priv->chip->dev);
 
 		if (chip_name && strcmp(chip_name, name) == 0) {
 			mutex_unlock(&pwm_lock);
-			return chip;
+			return priv->chip;
 		}
 	}
 
@@ -58,23 +60,24 @@ static struct pwm_chip *pwmchip_find_by_name(const char *name)
 
 static int pwm_device_request(struct pwm_device *pwm, const char *label)
 {
+	struct pwm_chip *chip = pwm->priv->chip;
 	int err;
 
 	if (test_bit(PWMF_REQUESTED, &pwm->flags))
 		return -EBUSY;
 
-	if (!try_module_get(pwm->chip->owner))
+	if (!try_module_get(pwm->priv->owner))
 		return -ENODEV;
 
-	if (pwm->chip->ops->request) {
-		err = pwm->chip->ops->request(pwm->chip, pwm);
+	if (chip->ops->request) {
+		err = chip->ops->request(chip, pwm);
 		if (err) {
-			module_put(pwm->chip->owner);
+			module_put(pwm->priv->owner);
 			return err;
 		}
 	}
 
-	if (pwm->chip->ops->get_state) {
+	if (chip->ops->get_state) {
 		/*
 		 * Zero-initialize state because most drivers are unaware of
 		 * .usage_power. The other members of state are supposed to be
@@ -84,7 +87,7 @@ static int pwm_device_request(struct pwm_device *pwm, const char *label)
 		 */
 		struct pwm_state state = { 0, };
 
-		err = pwm->chip->ops->get_state(pwm->chip, pwm, &state);
+		err = chip->ops->get_state(chip, pwm, &state);
 		trace_pwm_get(pwm, &state, err);
 
 		if (!err)
@@ -196,6 +199,64 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
 	return true;
 }
 
+static struct pwm_chip_private *pwmchip_alloc(struct pwm_chip *chip,
+					      struct module *owner)
+{
+	struct pwm_chip_private *priv;
+	struct pwm_device *pwm;
+	unsigned int i;
+	int err;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return ERR_PTR(-ENOMEM);
+
+	priv->pwms = kcalloc(chip->npwm, sizeof(*pwm), GFP_KERNEL);
+	if (!priv->pwms) {
+		err = -ENOMEM;
+		goto free;
+	}
+
+	priv->owner = owner;
+	priv->chip = chip;
+
+	for (i = 0; i < chip->npwm; i++) {
+		struct pwm_device *pwm = &priv->pwms[i];
+
+		pwm->priv = priv;
+		pwm->hwpwm = i;
+	}
+
+	mutex_lock(&pwm_lock);
+
+	err = idr_alloc(&pwm_chips, priv, 0, 0, GFP_KERNEL);
+	if (err < 0) {
+		mutex_unlock(&pwm_lock);
+		goto free;
+	}
+
+	mutex_unlock(&pwm_lock);
+
+	priv->id = err;
+
+	return priv;
+
+free:
+	kfree(priv->pwms);
+	kfree(priv);
+	return ERR_PTR(err);
+}
+
+static void pwmchip_free(struct pwm_chip_private *priv)
+{
+	mutex_lock(&pwm_lock);
+	idr_remove(&pwm_chips, priv->id);
+	mutex_unlock(&pwm_lock);
+
+	kfree(priv->pwms);
+	kfree(priv);
+}
+
 /**
  * __pwmchip_add() - register a new PWM chip
  * @chip: the PWM chip to add
@@ -208,8 +269,7 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
  */
 int __pwmchip_add(struct pwm_chip *chip, struct module *owner)
 {
-	unsigned int i;
-	int ret;
+	struct pwm_chip_private *priv;
 
 	if (!chip || !chip->dev || !chip->ops || !chip->npwm)
 		return -EINVAL;
@@ -217,36 +277,16 @@ int __pwmchip_add(struct pwm_chip *chip, struct module *owner)
 	if (!pwm_ops_check(chip))
 		return -EINVAL;
 
-	chip->owner = owner;
-
-	chip->pwms = kcalloc(chip->npwm, sizeof(*chip->pwms), GFP_KERNEL);
-	if (!chip->pwms)
+	priv = pwmchip_alloc(chip, owner);
+	if (!priv)
 		return -ENOMEM;
 
-	mutex_lock(&pwm_lock);
-
-	ret = idr_alloc(&pwmchip_idr, chip, 0, 0, GFP_KERNEL);
-	if (ret < 0) {
-		mutex_unlock(&pwm_lock);
-		kfree(chip->pwms);
-		return ret;
-	}
-
-	chip->id = ret;
-
-	for (i = 0; i < chip->npwm; i++) {
-		struct pwm_device *pwm = &chip->pwms[i];
-
-		pwm->chip = chip;
-		pwm->hwpwm = i;
-	}
-
-	mutex_unlock(&pwm_lock);
+	chip->priv = priv;
 
 	if (IS_ENABLED(CONFIG_OF))
 		of_pwmchip_add(chip);
 
-	pwmchip_sysfs_export(chip);
+	pwmchip_sysfs_export(priv);
 
 	return 0;
 }
@@ -260,18 +300,14 @@ EXPORT_SYMBOL_GPL(__pwmchip_add);
  */
 void pwmchip_remove(struct pwm_chip *chip)
 {
-	pwmchip_sysfs_unexport(chip);
-
-	if (IS_ENABLED(CONFIG_OF))
-		of_pwmchip_remove(chip);
-
 	mutex_lock(&pwm_lock);
 
-	idr_remove(&pwmchip_idr, chip->id);
+	pwmchip_sysfs_unexport(chip->priv);
 
-	mutex_unlock(&pwm_lock);
+	if (IS_ENABLED(CONFIG_OF))
+		of_pwmchip_remove(chip);
 
-	kfree(chip->pwms);
+	pwmchip_free(chip->priv);
 }
 EXPORT_SYMBOL_GPL(pwmchip_remove);
 
@@ -315,7 +351,7 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
 		return ERR_PTR(-EINVAL);
 
 	mutex_lock(&pwm_lock);
-	pwm = &chip->pwms[index];
+	pwm = &chip->priv->pwms[index];
 
 	err = pwm_device_request(pwm, label);
 	if (err < 0)
@@ -329,9 +365,9 @@ EXPORT_SYMBOL_GPL(pwm_request_from_chip);
 static void pwm_apply_state_debug(struct pwm_device *pwm,
 				  const struct pwm_state *state)
 {
-	struct pwm_state *last = &pwm->last;
-	struct pwm_chip *chip = pwm->chip;
+	struct pwm_chip *chip = pwm->priv->chip;
 	struct pwm_state s1 = { 0 }, s2 = { 0 };
+	struct pwm_state *last = &pwm->last;
 	int err;
 
 	if (!IS_ENABLED(CONFIG_PWM_DEBUG))
@@ -439,7 +475,6 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
  */
 int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 {
-	struct pwm_chip *chip;
 	int err;
 
 	/*
@@ -455,8 +490,6 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	    state->duty_cycle > state->period)
 		return -EINVAL;
 
-	chip = pwm->chip;
-
 	if (state->period == pwm->state.period &&
 	    state->duty_cycle == pwm->state.duty_cycle &&
 	    state->polarity == pwm->state.polarity &&
@@ -464,7 +497,7 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	    state->usage_power == pwm->state.usage_power)
 		return 0;
 
-	err = chip->ops->apply(chip, pwm, state);
+	err = pwm->priv->chip->ops->apply(pwm->priv->chip, pwm, state);
 	trace_pwm_apply(pwm, state, err);
 	if (err)
 		return err;
@@ -492,16 +525,19 @@ EXPORT_SYMBOL_GPL(pwm_apply_state);
 int pwm_capture(struct pwm_device *pwm, struct pwm_capture *result,
 		unsigned long timeout)
 {
+	struct pwm_chip *chip;
 	int err;
 
-	if (!pwm || !pwm->chip->ops)
+	if (!pwm)
 		return -EINVAL;
 
-	if (!pwm->chip->ops->capture)
+	chip = pwm->priv->chip;
+
+	if (!chip || !chip->ops || !chip->ops->capture)
 		return -ENOSYS;
 
 	mutex_lock(&pwm_lock);
-	err = pwm->chip->ops->capture(pwm->chip, pwm, result, timeout);
+	err = chip->ops->capture(chip, pwm, result, timeout);
 	mutex_unlock(&pwm_lock);
 
 	return err;
@@ -566,16 +602,19 @@ EXPORT_SYMBOL_GPL(pwm_adjust_config);
 
 static struct pwm_chip *fwnode_to_pwmchip(struct fwnode_handle *fwnode)
 {
-	struct pwm_chip *chip;
+	struct pwm_chip_private *priv;
 	unsigned long id, tmp;
 
 	mutex_lock(&pwm_lock);
 
-	idr_for_each_entry_ul(&pwmchip_idr, chip, tmp, id)
+	idr_for_each_entry_ul(&pwm_chips, priv, tmp, id) {
+		struct pwm_chip *chip = priv->chip;
+
 		if (chip->dev && device_match_fwnode(chip->dev, fwnode)) {
 			mutex_unlock(&pwm_lock);
 			return chip;
 		}
+	}
 
 	mutex_unlock(&pwm_lock);
 
@@ -585,6 +624,7 @@ static struct pwm_chip *fwnode_to_pwmchip(struct fwnode_handle *fwnode)
 static struct device_link *pwm_device_link_add(struct device *dev,
 					       struct pwm_device *pwm)
 {
+	struct pwm_chip *chip = pwm->priv->chip;
 	struct device_link *dl;
 
 	if (!dev) {
@@ -593,15 +633,15 @@ static struct device_link *pwm_device_link_add(struct device *dev,
 		 * impact the PM sequence ordering: the PWM supplier may get
 		 * suspended before the consumer.
 		 */
-		dev_warn(pwm->chip->dev,
+		dev_warn(chip->dev,
 			 "No consumer device specified to create a link to\n");
 		return NULL;
 	}
 
-	dl = device_link_add(dev, pwm->chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
+	dl = device_link_add(dev, chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
 	if (!dl) {
 		dev_err(dev, "failed to create device link to %s\n",
-			dev_name(pwm->chip->dev));
+			dev_name(chip->dev));
 		return ERR_PTR(-EINVAL);
 	}
 
@@ -918,12 +958,12 @@ void pwm_put(struct pwm_device *pwm)
 		goto out;
 	}
 
-	if (pwm->chip->ops->free)
-		pwm->chip->ops->free(pwm->chip, pwm);
+	if (pwm->priv->chip->ops->free)
+		pwm->priv->chip->ops->free(pwm->priv->chip, pwm);
 
 	pwm->label = NULL;
 
-	module_put(pwm->chip->owner);
+	module_put(pwm->priv->owner);
 out:
 	mutex_unlock(&pwm_lock);
 }
@@ -997,12 +1037,12 @@ struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
 EXPORT_SYMBOL_GPL(devm_fwnode_pwm_get);
 
 #ifdef CONFIG_DEBUG_FS
-static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
+static void pwm_dbg_show(struct pwm_chip_private *priv, struct seq_file *s)
 {
 	unsigned int i;
 
-	for (i = 0; i < chip->npwm; i++) {
-		struct pwm_device *pwm = &chip->pwms[i];
+	for (i = 0; i < priv->chip->npwm; i++) {
+		struct pwm_device *pwm = &priv->pwms[i];
 		struct pwm_state state;
 
 		pwm_get_state(pwm, &state);
@@ -1035,7 +1075,7 @@ static void *pwm_seq_start(struct seq_file *s, loff_t *pos)
 	mutex_lock(&pwm_lock);
 	s->private = "";
 
-	ret = idr_get_next_ul(&pwmchip_idr, &id);
+	ret = idr_get_next_ul(&pwm_chips, &id);
 	*pos = id;
 	return ret;
 }
@@ -1047,7 +1087,7 @@ static void *pwm_seq_next(struct seq_file *s, void *v, loff_t *pos)
 
 	s->private = "\n";
 
-	ret = idr_get_next_ul(&pwmchip_idr, &id);
+	ret = idr_get_next_ul(&pwm_chips, &id);
 	*pos = id;
 	return ret;
 }
@@ -1059,15 +1099,16 @@ static void pwm_seq_stop(struct seq_file *s, void *v)
 
 static int pwm_seq_show(struct seq_file *s, void *v)
 {
-	struct pwm_chip *chip = v;
+	struct pwm_chip_private *priv = v;
+	struct pwm_chip *chip = priv->chip;
 
 	seq_printf(s, "%s%d: %s/%s, %d PWM device%s\n",
-		   (char *)s->private, chip->id,
+		   (char *)s->private, priv->id,
 		   chip->dev->bus ? chip->dev->bus->name : "no-bus",
 		   dev_name(chip->dev), chip->npwm,
 		   (chip->npwm != 1) ? "s" : "");
 
-	pwm_dbg_show(chip, s);
+	pwm_dbg_show(priv, s);
 
 	return 0;
 }
diff --git a/drivers/pwm/internal.h b/drivers/pwm/internal.h
new file mode 100644
index 000000000000..44fffd3b6744
--- /dev/null
+++ b/drivers/pwm/internal.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef PWM_INTERNAL_H
+#define PWM_INTERNAL_H
+
+#include <linux/list.h>
+
+struct pwm_chip;
+struct pwm_device;
+
+/**
+ * struct pwm_chip_private - subsystem-private PWM chip data
+ * @chip: driver-private PWM chip data
+ * @owner: module providing the chip
+ * @pwms: array of PWM devices allocated by the framework
+ * @base: number of first PWM controlled by this chip
+ */
+struct pwm_chip_private {
+	struct pwm_chip *chip;
+	struct module *owner;
+	struct pwm_device *pwms;
+	unsigned int id;
+};
+
+#ifdef CONFIG_PWM_SYSFS
+void pwmchip_sysfs_export(struct pwm_chip_private *priv);
+void pwmchip_sysfs_unexport(struct pwm_chip_private *priv);
+#else
+static inline void pwmchip_sysfs_export(struct pwm_chip_private *priv)
+{
+}
+
+static inline void pwmchip_sysfs_unexport(struct pwm_chip_private *priv)
+{
+}
+#endif /* CONFIG_PWM_SYSFS */
+
+#endif /* PWM_INTERNAL_H */
diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
index 3f2c5031a3ba..6bbbfaa582c1 100644
--- a/drivers/pwm/pwm-atmel-hlcdc.c
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -15,6 +15,8 @@
 #include <linux/pwm.h>
 #include <linux/regmap.h>
 
+#include "internal.h"
+
 #define ATMEL_HLCDC_PWMCVAL_MASK	GENMASK(15, 8)
 #define ATMEL_HLCDC_PWMCVAL(x)		(((x) << 8) & ATMEL_HLCDC_PWMCVAL_MASK)
 #define ATMEL_HLCDC_PWMPOL		BIT(4)
@@ -185,7 +187,7 @@ static int atmel_hlcdc_pwm_suspend(struct device *dev)
 	struct atmel_hlcdc_pwm *atmel = dev_get_drvdata(dev);
 
 	/* Keep the periph clock enabled if the PWM is still running. */
-	if (pwm_is_enabled(&atmel->chip.pwms[0]))
+	if (pwm_is_enabled(&atmel->chip.priv->pwms[0]))
 		clk_disable_unprepare(atmel->hlcdc->periph_clk);
 
 	return 0;
@@ -197,7 +199,7 @@ static int atmel_hlcdc_pwm_resume(struct device *dev)
 	struct pwm_state state;
 	int ret;
 
-	pwm_get_state(&atmel->chip.pwms[0], &state);
+	pwm_get_state(&atmel->chip.priv->pwms[0], &state);
 
 	/* Re-enable the periph clock it was stopped during suspend. */
 	if (!state.enabled) {
@@ -206,7 +208,7 @@ static int atmel_hlcdc_pwm_resume(struct device *dev)
 			return ret;
 	}
 
-	return atmel_hlcdc_pwm_apply(&atmel->chip, &atmel->chip.pwms[0],
+	return atmel_hlcdc_pwm_apply(&atmel->chip, &atmel->chip.priv->pwms[0],
 				     &state);
 }
 
diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
index d1b6d1aa4773..72467d620a90 100644
--- a/drivers/pwm/pwm-fsl-ftm.c
+++ b/drivers/pwm/pwm-fsl-ftm.c
@@ -19,6 +19,8 @@
 #include <linux/slab.h>
 #include <linux/fsl/ftm.h>
 
+#include "internal.h"
+
 #define FTM_SC_CLK(c)	(((c) + 1) << FTM_SC_CLK_MASK_SHIFT)
 
 enum fsl_pwm_clk {
@@ -468,7 +470,7 @@ static int fsl_pwm_suspend(struct device *dev)
 	regcache_mark_dirty(fpc->regmap);
 
 	for (i = 0; i < fpc->chip.npwm; i++) {
-		struct pwm_device *pwm = &fpc->chip.pwms[i];
+		struct pwm_device *pwm = &fpc->chip.priv->pwms[i];
 
 		if (!test_bit(PWMF_REQUESTED, &pwm->flags))
 			continue;
@@ -491,7 +493,7 @@ static int fsl_pwm_resume(struct device *dev)
 	int i;
 
 	for (i = 0; i < fpc->chip.npwm; i++) {
-		struct pwm_device *pwm = &fpc->chip.pwms[i];
+		struct pwm_device *pwm = &fpc->chip.priv->pwms[i];
 
 		if (!test_bit(PWMF_REQUESTED, &pwm->flags))
 			continue;
diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
index b3d4a955aa31..80f89ad2bc8f 100644
--- a/drivers/pwm/pwm-lpc18xx-sct.c
+++ b/drivers/pwm/pwm-lpc18xx-sct.c
@@ -27,6 +27,8 @@
 #include <linux/platform_device.h>
 #include <linux/pwm.h>
 
+#include "internal.h"
+
 /* LPC18xx SCT registers */
 #define LPC18XX_PWM_CONFIG		0x000
 #define LPC18XX_PWM_CONFIG_UNIFY	BIT(0)
@@ -224,7 +226,7 @@ static int lpc18xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	    !lpc18xx_pwm->period_ns) {
 		lpc18xx_pwm->period_ns = period_ns;
 		for (i = 0; i < chip->npwm; i++)
-			pwm_set_period(&chip->pwms[i], period_ns);
+			pwm_set_period(&chip->priv->pwms[i], period_ns);
 		lpc18xx_pwm_config_period(chip, period_ns);
 	}
 
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index a6ea3ce7e019..085d3c17f96b 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -19,6 +19,8 @@
 #include <linux/pm_runtime.h>
 #include <linux/time.h>
 
+#include "internal.h"
+
 #define DEFAULT_SYMBOL_NAMESPACE PWM_LPSS
 
 #include "pwm-lpss.h"
@@ -73,21 +75,21 @@ static inline struct pwm_lpss_chip *to_lpwm(struct pwm_chip *chip)
 
 static inline u32 pwm_lpss_read(const struct pwm_device *pwm)
 {
-	struct pwm_lpss_chip *lpwm = to_lpwm(pwm->chip);
+	struct pwm_lpss_chip *lpwm = to_lpwm(pwm->priv->chip);
 
 	return readl(lpwm->regs + pwm->hwpwm * PWM_SIZE + PWM);
 }
 
 static inline void pwm_lpss_write(const struct pwm_device *pwm, u32 value)
 {
-	struct pwm_lpss_chip *lpwm = to_lpwm(pwm->chip);
+	struct pwm_lpss_chip *lpwm = to_lpwm(pwm->priv->chip);
 
 	writel(value, lpwm->regs + pwm->hwpwm * PWM_SIZE + PWM);
 }
 
 static int pwm_lpss_wait_for_update(struct pwm_device *pwm)
 {
-	struct pwm_lpss_chip *lpwm = to_lpwm(pwm->chip);
+	struct pwm_lpss_chip *lpwm = to_lpwm(pwm->priv->chip);
 	const void __iomem *addr = lpwm->regs + pwm->hwpwm * PWM_SIZE + PWM;
 	const unsigned int ms = 500 * USEC_PER_MSEC;
 	u32 val;
@@ -106,7 +108,7 @@ static int pwm_lpss_wait_for_update(struct pwm_device *pwm)
 	 */
 	err = readl_poll_timeout(addr, val, !(val & PWM_SW_UPDATE), 40, ms);
 	if (err)
-		dev_err(pwm->chip->dev, "PWM_SW_UPDATE was not cleared\n");
+		dev_err(pwm->priv->chip->dev, "PWM_SW_UPDATE was not cleared\n");
 
 	return err;
 }
@@ -114,7 +116,7 @@ static int pwm_lpss_wait_for_update(struct pwm_device *pwm)
 static inline int pwm_lpss_is_updating(struct pwm_device *pwm)
 {
 	if (pwm_lpss_read(pwm) & PWM_SW_UPDATE) {
-		dev_err(pwm->chip->dev, "PWM_SW_UPDATE is still set, skipping update\n");
+		dev_err(pwm->priv->chip->dev, "PWM_SW_UPDATE is still set, skipping update\n");
 		return -EBUSY;
 	}
 
@@ -278,7 +280,7 @@ struct pwm_lpss_chip *devm_pwm_lpss_probe(struct device *dev, void __iomem *base
 	}
 
 	for (i = 0; i < lpwm->info->npwm; i++) {
-		ctrl = pwm_lpss_read(&lpwm->chip.pwms[i]);
+		ctrl = pwm_lpss_read(&lpwm->chip.priv->pwms[i]);
 		if (ctrl & PWM_ENABLE)
 			pm_runtime_get(dev);
 	}
diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
index e79b1de8c4d8..d82cca90dba9 100644
--- a/drivers/pwm/pwm-pca9685.c
+++ b/drivers/pwm/pwm-pca9685.c
@@ -22,6 +22,8 @@
 #include <linux/pm_runtime.h>
 #include <linux/bitmap.h>
 
+#include "internal.h"
+
 /*
  * Because the PCA9685 has only one prescaler per chip, only the first channel
  * that is enabled is allowed to change the prescale register.
@@ -134,7 +136,7 @@ static int pca9685_write_reg(struct pca9685 *pca, unsigned int reg, unsigned int
 /* Helper function to set the duty cycle ratio to duty/4096 (e.g. duty=2048 -> 50%) */
 static void pca9685_pwm_set_duty(struct pca9685 *pca, int channel, unsigned int duty)
 {
-	struct pwm_device *pwm = &pca->chip.pwms[channel];
+	struct pwm_device *pwm = &pca->chip.priv->pwms[channel];
 	unsigned int on, off;
 
 	if (duty == 0) {
@@ -173,7 +175,7 @@ static void pca9685_pwm_set_duty(struct pca9685 *pca, int channel, unsigned int
 
 static unsigned int pca9685_pwm_get_duty(struct pca9685 *pca, int channel)
 {
-	struct pwm_device *pwm = &pca->chip.pwms[channel];
+	struct pwm_device *pwm = &pca->chip.priv->pwms[channel];
 	unsigned int off = 0, on = 0, val = 0;
 
 	if (WARN_ON(channel >= PCA9685_MAXCHAN)) {
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 6e77302f7368..e1baede405bc 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -26,6 +26,8 @@
 /* For struct samsung_timer_variant and samsung_pwm_lock. */
 #include <clocksource/samsung_pwm.h>
 
+#include "internal.h"
+
 #define REG_TCFG0			0x00
 #define REG_TCFG1			0x04
 #define REG_TCON			0x08
@@ -627,10 +629,10 @@ static int pwm_samsung_resume(struct device *dev)
 	unsigned int i;
 
 	for (i = 0; i < SAMSUNG_PWM_NUM; i++) {
-		struct pwm_device *pwm = &chip->pwms[i];
+		struct pwm_device *pwm = &chip->priv->pwms[i];
 		struct samsung_pwm_channel *chan = &our_chip->channel[i];
 
-		if (!test_bit(PWMF_REQUESTED, &pwm->flags))
+		if (WARN_ON(!pwm) || !test_bit(PWMF_REQUESTED, &pwm->flags))
 			continue;
 
 		if (our_chip->variant.output_mask & BIT(i))
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index 089e50bdbbf0..e1dccaf33398 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -20,6 +20,8 @@
 #include <linux/slab.h>
 #include <linux/bitfield.h>
 
+#include "internal.h"
+
 /* Register offsets */
 #define PWM_SIFIVE_PWMCFG		0x0
 #define PWM_SIFIVE_PWMCOUNT		0x8
@@ -322,7 +324,7 @@ static void pwm_sifive_remove(struct platform_device *dev)
 	clk_notifier_unregister(ddata->clk, &ddata->notifier);
 
 	for (ch = 0; ch < ddata->chip.npwm; ch++) {
-		pwm = &ddata->chip.pwms[ch];
+		pwm = &ddata->chip.priv->pwms[ch];
 		if (pwm->state.enabled)
 			clk_disable(ddata->clk);
 	}
diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 439068f3eca1..cb32caf5368a 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -17,6 +17,8 @@
 #include <linux/platform_device.h>
 #include <linux/pwm.h>
 
+#include "internal.h"
+
 struct stm32_pwm_lp {
 	struct pwm_chip chip;
 	struct clk *clk;
@@ -223,10 +225,10 @@ static int stm32_pwm_lp_suspend(struct device *dev)
 	struct stm32_pwm_lp *priv = dev_get_drvdata(dev);
 	struct pwm_state state;
 
-	pwm_get_state(&priv->chip.pwms[0], &state);
+	pwm_get_state(&priv->chip.priv->pwms[0], &state);
 	if (state.enabled) {
 		dev_err(dev, "The consumer didn't stop us (%s)\n",
-			priv->chip.pwms[0].label);
+			priv->chip.priv->pwms[0].label);
 		return -EBUSY;
 	}
 
diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 5f10cba492ec..81933df80768 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -16,6 +16,8 @@
 #include <linux/platform_device.h>
 #include <linux/pwm.h>
 
+#include "internal.h"
+
 #define CCMR_CHANNEL_SHIFT 8
 #define CCMR_CHANNEL_MASK  0xFF
 #define MAX_BREAKINPUT 2
@@ -127,7 +129,7 @@ static int stm32_pwm_raw_capture(struct stm32_pwm *priv, struct pwm_device *pwm,
 		*raw_prd = priv->max_arr - priv->capture[0] + priv->capture[2];
 
 	/* Duty cycle capture requires at least two capture units */
-	if (pwm->chip->npwm < 2)
+	if (priv->chip.npwm < 2)
 		*raw_dty = 0;
 	else if (priv->capture[0] <= priv->capture[3])
 		*raw_dty = priv->capture[3] - priv->capture[0];
@@ -682,7 +684,7 @@ static int stm32_pwm_suspend(struct device *dev)
 		mask = TIM_CCER_CC1E << (i * 4);
 		if (ccer & mask) {
 			dev_err(dev, "PWM %u still in use by consumer %s\n",
-				i, priv->chip.pwms[i].label);
+				i, priv->chip.priv->pwms[i].label);
 			return -EBUSY;
 		}
 	}
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index d974f4414ac9..f089257051d1 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -14,6 +14,8 @@
 #include <linux/pwm.h>
 #include <linux/of.h>
 
+#include "internal.h"
+
 /* ECAP registers and bits definitions */
 #define CAP1			0x08
 #define CAP2			0x0C
@@ -288,7 +290,7 @@ static void ecap_pwm_restore_context(struct ecap_pwm_chip *pc)
 static int ecap_pwm_suspend(struct device *dev)
 {
 	struct ecap_pwm_chip *pc = dev_get_drvdata(dev);
-	struct pwm_device *pwm = pc->chip.pwms;
+	struct pwm_device *pwm = pc->chip.priv->pwms;
 
 	ecap_pwm_save_context(pc);
 
@@ -302,7 +304,7 @@ static int ecap_pwm_suspend(struct device *dev)
 static int ecap_pwm_resume(struct device *dev)
 {
 	struct ecap_pwm_chip *pc = dev_get_drvdata(dev);
-	struct pwm_device *pwm = pc->chip.pwms;
+	struct pwm_device *pwm = pc->chip.priv->pwms;
 
 	/* Enable explicitly if PWM was running */
 	if (pwm_is_enabled(pwm))
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index af231fa74fa9..0d137100b040 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -14,6 +14,8 @@
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
 
+#include "internal.h"
+
 /* EHRPWM registers and bits definitions */
 
 /* Time base module registers */
@@ -557,7 +559,7 @@ static int ehrpwm_pwm_suspend(struct device *dev)
 	ehrpwm_pwm_save_context(pc);
 
 	for (i = 0; i < pc->chip.npwm; i++) {
-		struct pwm_device *pwm = &pc->chip.pwms[i];
+		struct pwm_device *pwm = &pc->chip.priv->pwms[i];
 
 		if (!pwm_is_enabled(pwm))
 			continue;
@@ -575,7 +577,7 @@ static int ehrpwm_pwm_resume(struct device *dev)
 	unsigned int i;
 
 	for (i = 0; i < pc->chip.npwm; i++) {
-		struct pwm_device *pwm = &pc->chip.pwms[i];
+		struct pwm_device *pwm = &pc->chip.priv->pwms[i];
 
 		if (!pwm_is_enabled(pwm))
 			continue;
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 4edb994fa2e1..653df20afe1c 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -14,6 +14,8 @@
 #include <linux/kdev_t.h>
 #include <linux/pwm.h>
 
+#include "internal.h"
+
 struct pwm_export {
 	struct device child;
 	struct pwm_device *pwm;
@@ -311,7 +313,7 @@ static ssize_t export_store(struct device *parent,
 			    struct device_attribute *attr,
 			    const char *buf, size_t len)
 {
-	struct pwm_chip *chip = dev_get_drvdata(parent);
+	struct pwm_chip_private *priv = dev_get_drvdata(parent);
 	struct pwm_device *pwm;
 	unsigned int hwpwm;
 	int ret;
@@ -320,10 +322,10 @@ static ssize_t export_store(struct device *parent,
 	if (ret < 0)
 		return ret;
 
-	if (hwpwm >= chip->npwm)
+	if (hwpwm >= priv->chip->npwm)
 		return -ENODEV;
 
-	pwm = pwm_request_from_chip(chip, hwpwm, "sysfs");
+	pwm = pwm_request_from_chip(priv->chip, hwpwm, "sysfs");
 	if (IS_ERR(pwm))
 		return PTR_ERR(pwm);
 
@@ -339,7 +341,7 @@ static ssize_t unexport_store(struct device *parent,
 			      struct device_attribute *attr,
 			      const char *buf, size_t len)
 {
-	struct pwm_chip *chip = dev_get_drvdata(parent);
+	struct pwm_chip_private *priv = dev_get_drvdata(parent);
 	unsigned int hwpwm;
 	int ret;
 
@@ -347,10 +349,10 @@ static ssize_t unexport_store(struct device *parent,
 	if (ret < 0)
 		return ret;
 
-	if (hwpwm >= chip->npwm)
+	if (hwpwm >= priv->chip->npwm)
 		return -ENODEV;
 
-	ret = pwm_unexport_child(parent, &chip->pwms[hwpwm]);
+	ret = pwm_unexport_child(parent, &priv->pwms[hwpwm]);
 
 	return ret ? : len;
 }
@@ -359,9 +361,9 @@ static DEVICE_ATTR_WO(unexport);
 static ssize_t npwm_show(struct device *parent, struct device_attribute *attr,
 			 char *buf)
 {
-	const struct pwm_chip *chip = dev_get_drvdata(parent);
+	const struct pwm_chip_private *priv = dev_get_drvdata(parent);
 
-	return sysfs_emit(buf, "%u\n", chip->npwm);
+	return sysfs_emit(buf, "%u\n", priv->chip->npwm);
 }
 static DEVICE_ATTR_RO(npwm);
 
@@ -411,12 +413,12 @@ static int pwm_class_apply_state(struct pwm_export *export,
 
 static int pwm_class_resume_npwm(struct device *parent, unsigned int npwm)
 {
-	struct pwm_chip *chip = dev_get_drvdata(parent);
+	struct pwm_chip_private *priv = dev_get_drvdata(parent);
 	unsigned int i;
 	int ret = 0;
 
 	for (i = 0; i < npwm; i++) {
-		struct pwm_device *pwm = &chip->pwms[i];
+		struct pwm_device *pwm = &priv->pwms[i];
 		struct pwm_state state;
 		struct pwm_export *export;
 
@@ -442,12 +444,12 @@ static int pwm_class_resume_npwm(struct device *parent, unsigned int npwm)
 
 static int pwm_class_suspend(struct device *parent)
 {
-	struct pwm_chip *chip = dev_get_drvdata(parent);
+	struct pwm_chip_private *priv = dev_get_drvdata(parent);
 	unsigned int i;
 	int ret = 0;
 
-	for (i = 0; i < chip->npwm; i++) {
-		struct pwm_device *pwm = &chip->pwms[i];
+	for (i = 0; i < priv->chip->npwm; i++) {
+		struct pwm_device *pwm = &priv->pwms[i];
 		struct pwm_state state;
 		struct pwm_export *export;
 
@@ -483,9 +485,9 @@ static int pwm_class_suspend(struct device *parent)
 
 static int pwm_class_resume(struct device *parent)
 {
-	struct pwm_chip *chip = dev_get_drvdata(parent);
+	struct pwm_chip_private *priv = dev_get_drvdata(parent);
 
-	return pwm_class_resume_npwm(parent, chip->npwm);
+	return pwm_class_resume_npwm(parent, priv->chip->npwm);
 }
 
 static DEFINE_SIMPLE_DEV_PM_OPS(pwm_class_pm_ops, pwm_class_suspend, pwm_class_resume);
@@ -501,7 +503,7 @@ static int pwmchip_sysfs_match(struct device *parent, const void *data)
 	return dev_get_drvdata(parent) == data;
 }
 
-void pwmchip_sysfs_export(struct pwm_chip *chip)
+void pwmchip_sysfs_export(struct pwm_chip_private *priv)
 {
 	struct device *parent;
 
@@ -509,26 +511,26 @@ void pwmchip_sysfs_export(struct pwm_chip *chip)
 	 * If device_create() fails the pwm_chip is still usable by
 	 * the kernel it's just not exported.
 	 */
-	parent = device_create(&pwm_class, chip->dev, MKDEV(0, 0), chip,
-			       "pwmchip%d", chip->id);
+	parent = device_create(&pwm_class, priv->chip->dev, MKDEV(0, 0), priv,
+			       "pwmchip%d", priv->id);
 	if (IS_ERR(parent)) {
-		dev_warn(chip->dev,
+		dev_warn(priv->chip->dev,
 			 "device_create failed for pwm_chip sysfs export\n");
 	}
 }
 
-void pwmchip_sysfs_unexport(struct pwm_chip *chip)
+void pwmchip_sysfs_unexport(struct pwm_chip_private *priv)
 {
 	struct device *parent;
 	unsigned int i;
 
-	parent = class_find_device(&pwm_class, NULL, chip,
+	parent = class_find_device(&pwm_class, NULL, priv,
 				   pwmchip_sysfs_match);
 	if (!parent)
 		return;
 
-	for (i = 0; i < chip->npwm; i++) {
-		struct pwm_device *pwm = &chip->pwms[i];
+	for (i = 0; i < priv->chip->npwm; i++) {
+		struct pwm_device *pwm = &priv->pwms[i];
 
 		if (test_bit(PWMF_EXPORTED, &pwm->flags))
 			pwm_unexport_child(parent, pwm);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index f87655c06c82..5c478cd592d7 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -6,6 +6,7 @@
 #include <linux/mutex.h>
 #include <linux/of.h>
 
+struct pwm_chip_private;
 struct pwm_chip;
 
 /**
@@ -79,11 +80,12 @@ struct pwm_device {
 	const char *label;
 	unsigned long flags;
 	unsigned int hwpwm;
-	struct pwm_chip *chip;
 
 	struct pwm_args args;
 	struct pwm_state state;
 	struct pwm_state last;
+
+	struct pwm_chip_private *priv;
 };
 
 /**
@@ -280,26 +282,21 @@ struct pwm_ops {
  * struct pwm_chip - abstract a PWM controller
  * @dev: device providing the PWMs
  * @ops: callbacks for this PWM controller
- * @owner: module providing this chip
- * @id: unique number of this PWM chip
  * @npwm: number of PWMs controlled by this chip
  * @of_xlate: request a PWM device given a device tree PWM specifier
  * @of_pwm_n_cells: number of cells expected in the device tree PWM specifier
- * @pwms: array of PWM devices allocated by the framework
+ * @priv: subsystem internal chip data
  */
 struct pwm_chip {
 	struct device *dev;
 	const struct pwm_ops *ops;
-	struct module *owner;
-	unsigned int id;
 	unsigned int npwm;
 
 	struct pwm_device * (*of_xlate)(struct pwm_chip *chip,
 					const struct of_phandle_args *args);
 	unsigned int of_pwm_n_cells;
 
-	/* only used internally by the PWM framework */
-	struct pwm_device *pwms;
+	struct pwm_chip_private *priv;
 };
 
 #if IS_ENABLED(CONFIG_PWM)
@@ -564,17 +561,4 @@ static inline void pwm_remove_table(struct pwm_lookup *table, size_t num)
 }
 #endif
 
-#ifdef CONFIG_PWM_SYSFS
-void pwmchip_sysfs_export(struct pwm_chip *chip);
-void pwmchip_sysfs_unexport(struct pwm_chip *chip);
-#else
-static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
-{
-}
-
-static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
-{
-}
-#endif /* CONFIG_PWM_SYSFS */
-
 #endif /* __LINUX_PWM_H */
-- 
2.43.0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/625347ce/attachment-0001.sig>

From krzysztof.kozlowski at linaro.org  Fri Dec  8 07:43:42 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 8 Dec 2023 16:43:42 +0100
Subject: [PATCH 1/5] ASoC: wm0010: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-1-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-1-c4dab6f521ec@linaro.org>
Message-ID: <e905fc9c-fe10-4b2f-83f4-e0e5d389b2ca@linaro.org>

On 08/12/2023 11:09, Linus Walleij wrote:
> This converts the WM0010 codec to use GPIO descriptors.
> It's a pretty straight-forward conversion also switching over
> the single in-tree user in the S3C Cragganmore module
> for S3C 6410.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec  8 07:43:52 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 8 Dec 2023 16:43:52 +0100
Subject: [PATCH 2/5] ASoC: wm1250-ev1: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-2-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-2-c4dab6f521ec@linaro.org>
Message-ID: <631fed44-ff9b-419f-a4cc-7b02cc7b4302@linaro.org>

On 08/12/2023 11:09, Linus Walleij wrote:
> This converts the WM1250-EV1 codec to use GPIO descriptors.
> It turns out that the platform data was only used to pass some
> global GPIO numbers from a board file, so we get rid of this
> and also switch over the single in-tree user in the S3C
> Cragganmore module for S3C 6410.
> 
> The driver obtains two GPIO lines named OSR and master and just
> pull them low, we leave this behaviour as it was.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec  8 07:44:01 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 8 Dec 2023 16:44:01 +0100
Subject: [PATCH 3/5] ASoC: wm2200: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-3-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-3-c4dab6f521ec@linaro.org>
Message-ID: <8c4c6dd3-62ac-4a6d-986b-bb1a451b8f81@linaro.org>

On 08/12/2023 11:09, Linus Walleij wrote:
> This converts the WM2200 codec to use GPIO descriptors.
> This is a pretty straight-forward conversion, and it also
> switches over the single in-tree user in the S3C
> Cragganmore module for S3C 6410.
> 
> This coded does not seem to get selected or be selectable
> through Kconfig, I had to hack another soundcard Kconfig
> entry to select it for compile tests.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec  8 07:44:10 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 8 Dec 2023 16:44:10 +0100
Subject: [PATCH 4/5] ASoC: wm5100: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-4-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-4-c4dab6f521ec@linaro.org>
Message-ID: <cbe7e756-b4b6-4583-ab82-f9fc882703c6@linaro.org>

On 08/12/2023 11:09, Linus Walleij wrote:
> This converts the WM5100 codec to use GPIO descriptors, a pretty
> straight-forward conversion with the following peculiarities:
> 
> - The driver is instantiating a GPIO chip named wm5100, and the
>   headphone polarity detection GPIO is lifted from there. We add
>   this to the GPIO descriptor table as well, and we can then get
>   rid of also the base address for the GPIO chip from the
>   platform data and just use dynamic numbering.
> 
> - Fix up the only in-tree user which is the Cragganmore 6410
>   module.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  arch/arm/mach-s3c/mach-crag6410-module.c |  17 +++--

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec  8 07:44:18 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 8 Dec 2023 16:44:18 +0100
Subject: [PATCH 5/5] ASoC: wm8996: Convert to GPIO descriptors
In-Reply-To: <20231208-descriptors-sound-wlf-v1-5-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
 <20231208-descriptors-sound-wlf-v1-5-c4dab6f521ec@linaro.org>
Message-ID: <e5cf9c71-5526-4f99-809f-404a8c7b0366@linaro.org>

On 08/12/2023 11:09, Linus Walleij wrote:
> This converts the WM8996 codec to use GPIO descriptors, an a similar
> way to WM5100.
> 
> The driver is instantiating a GPIO chip named wm8996, and we get
> rid of the base address for the GPIO chip from the platform data and
> just use dynamic numbering. Move base and ngpio into the static
> gpio_chip template.
> 
> Fix up the only in-tree user which is the Cragganmore 6410 module.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  arch/arm/mach-s3c/mach-crag6410-module.c | 14 ++++++--

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From mathieu.poirier at linaro.org  Fri Dec  8 07:51:33 2023
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 8 Dec 2023 08:51:33 -0700
Subject: [PATCH v7 3/4] remoteproc: zynqmp: add pm domains support
In-Reply-To: <2e24d9be-be10-4f80-b3af-c3e0ed003e7b@amd.com>
References: <20231117174238.1876655-1-tanmay.shah@amd.com>
 <20231117174238.1876655-4-tanmay.shah@amd.com>
 <ZV02P3bHEhPLQHBo@p14s>
 <93487d3c-c324-4b9b-8b25-0b4ea52237b4@amd.com>
 <ZV+V6V2sEWgsqngk@p14s>
 <a75b22c1-66e3-4fce-ae64-de79e73f3cfa@amd.com>
 <ZWdwl/8LC2Nn+vCq@p14s>
 <ea2edc6e-6655-47f8-8b6d-242f5a0ef804@amd.com>
 <CANLsYkzJgZRSz5=nzW+ATmBKemoSd3ybhKuz1CJy33hftAGiqw@mail.gmail.com>
 <2e24d9be-be10-4f80-b3af-c3e0ed003e7b@amd.com>
Message-ID: <ZXM7hZlTAbBb8Iox@p14s>

On Wed, Dec 06, 2023 at 12:06:45PM -0600, Tanmay Shah wrote:
> 
> On 12/6/23 9:43 AM, Mathieu Poirier wrote:
> > On Fri, 1 Dec 2023 at 11:10, Tanmay Shah <tanmay.shah at amd.com> wrote:
> > >
> > >
> > > On 11/29/23 11:10 AM, Mathieu Poirier wrote:
> > > > On Mon, Nov 27, 2023 at 10:33:05AM -0600, Tanmay Shah wrote:
> > > > >
> > > > > On 11/23/23 12:11 PM, Mathieu Poirier wrote:
> > > > > > On Wed, Nov 22, 2023 at 03:00:36PM -0600, Tanmay Shah wrote:
> > > > > > > Hi Mathieu,
> > > > > > >
> > > > > > > Please find my comments below.
> > > > > > >
> > > > > > > On 11/21/23 4:59 PM, Mathieu Poirier wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Fri, Nov 17, 2023 at 09:42:37AM -0800, Tanmay Shah wrote:
> > > > > > > > > Use TCM pm domains extracted from device-tree
> > > > > > > > > to power on/off TCM using general pm domain framework.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > Changes in v7:
> > > > > > > > >   - %s/pm_dev1/pm_dev_core0/r
> > > > > > > > >   - %s/pm_dev_link1/pm_dev_core0_link/r
> > > > > > > > >   - %s/pm_dev2/pm_dev_core1/r
> > > > > > > > >   - %s/pm_dev_link2/pm_dev_core1_link/r
> > > > > > > > >   - remove pm_domain_id check to move next patch
> > > > > > > > >   - add comment about how 1st entry in pm domain list is used
> > > > > > > > >   - fix loop when jump to fail_add_pm_domains loop
> > > > > > > > >
> > > > > > > > >  drivers/remoteproc/xlnx_r5_remoteproc.c | 215 +++++++++++++++++++++++-
> > > > > > > > >  1 file changed, 212 insertions(+), 3 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > > > index 4395edea9a64..22bccc5075a0 100644
> > > > > > > > > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > > > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > > > @@ -16,6 +16,7 @@
> > > > > > > > >  #include <linux/of_reserved_mem.h>
> > > > > > > > >  #include <linux/platform_device.h>
> > > > > > > > >  #include <linux/remoteproc.h>
> > > > > > > > > +#include <linux/pm_domain.h>
> > > > > > > > >
> > > > > > > > >  #include "remoteproc_internal.h"
> > > > > > > > >
> > > > > > > > > @@ -102,6 +103,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
> > > > > > > > >   * @rproc: rproc handle
> > > > > > > > >   * @pm_domain_id: RPU CPU power domain id
> > > > > > > > >   * @ipi: pointer to mailbox information
> > > > > > > > > + * @num_pm_dev: number of tcm pm domain devices for this core
> > > > > > > > > + * @pm_dev_core0: pm domain virtual devices for power domain framework
> > > > > > > > > + * @pm_dev_core0_link: pm domain device links after registration
> > > > > > > > > + * @pm_dev_core1: used only in lockstep mode. second core's pm domain virtual devices
> > > > > > > > > + * @pm_dev_core1_link: used only in lockstep mode. second core's pm device links after
> > > > > > > > > + * registration
> > > > > > > > >   */
> > > > > > > > >  struct zynqmp_r5_core {
> > > > > > > > >     struct device *dev;
> > > > > > > > > @@ -111,6 +118,11 @@ struct zynqmp_r5_core {
> > > > > > > > >     struct rproc *rproc;
> > > > > > > > >     u32 pm_domain_id;
> > > > > > > > >     struct mbox_info *ipi;
> > > > > > > > > +   int num_pm_dev;
> > > > > > > > > +   struct device **pm_dev_core0;
> > > > > > > > > +   struct device_link **pm_dev_core0_link;
> > > > > > > > > +   struct device **pm_dev_core1;
> > > > > > > > > +   struct device_link **pm_dev_core1_link;
> > > > > > > > >  };
> > > > > > > > >
> > > > > > > > >  /**
> > > > > > > > > @@ -651,7 +663,8 @@ static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
> > > > > > > > >                                          ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> > > > > > > > >                                          ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> > > > > > > > >             if (ret < 0) {
> > > > > > > > > -                   dev_err(dev, "failed to turn on TCM 0x%x", pm_domain_id);
> > > > > > > > > +                   dev_err(dev, "failed to turn on TCM 0x%x",
> > > > > > > > > +                           pm_domain_id);
> > > > > > > >
> > > > > > > > Spurious change, you should have caught that.
> > > > > > >
> > > > > > > Ack, need to observe changes more closely before sending them.
> > > > > > >
> > > > > > > >
> > > > > > > > >                     goto release_tcm_lockstep;
> > > > > > > > >             }
> > > > > > > > >
> > > > > > > > > @@ -758,6 +771,189 @@ static int zynqmp_r5_parse_fw(struct rproc *rproc, const struct firmware *fw)
> > > > > > > > >     return ret;
> > > > > > > > >  }
> > > > > > > > >
> > > > > > > > > +static void zynqmp_r5_remove_pm_domains(struct rproc *rproc)
> > > > > > > > > +{
> > > > > > > > > +   struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > > > > +   struct device *dev = r5_core->dev;
> > > > > > > > > +   struct zynqmp_r5_cluster *cluster;
> > > > > > > > > +   int i;
> > > > > > > > > +
> > > > > > > > > +   cluster = platform_get_drvdata(to_platform_device(dev->parent));
> > > > > > > > > +
> > > > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > > > +           device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core0[i], false);
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +   kfree(r5_core->pm_dev_core0);
> > > > > > > > > +   r5_core->pm_dev_core0 = NULL;
> > > > > > > > > +   kfree(r5_core->pm_dev_core0_link);
> > > > > > > > > +   r5_core->pm_dev_core0_link = NULL;
> > > > > > > > > +
> > > > > > > > > +   if (cluster->mode == SPLIT_MODE) {
> > > > > > > > > +           r5_core->num_pm_dev = 0;
> > > > > > > > > +           return;
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > > > +           device_link_del(r5_core->pm_dev_core1_link[i]);
> > > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core1[i], false);
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +   kfree(r5_core->pm_dev_core1);
> > > > > > > > > +   r5_core->pm_dev_core1 = NULL;
> > > > > > > > > +   kfree(r5_core->pm_dev_core1_link);
> > > > > > > > > +   r5_core->pm_dev_core1_link = NULL;
> > > > > > > > > +   r5_core->num_pm_dev = 0;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +static int zynqmp_r5_add_pm_domains(struct rproc *rproc)
> > > > > > > > > +{
> > > > > > > > > +   struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > > > > +   struct device *dev = r5_core->dev, *dev2;
> > > > > > > > > +   struct zynqmp_r5_cluster *cluster;
> > > > > > > > > +   struct platform_device *pdev;
> > > > > > > > > +   struct device_node *np;
> > > > > > > > > +   int i, j, num_pm_dev, ret;
> > > > > > > > > +
> > > > > > > > > +   cluster = dev_get_drvdata(dev->parent);
> > > > > > > > > +
> > > > > > > > > +   /* get number of power-domains */
> > > > > > > > > +   num_pm_dev = of_count_phandle_with_args(r5_core->np, "power-domains",
> > > > > > > > > +                                           "#power-domain-cells");
> > > > > > > > > +
> > > > > > > > > +   if (num_pm_dev <= 0)
> > > > > > > > > +           return -EINVAL;
> > > > > > > > > +
> > > > > > > > > +   r5_core->pm_dev_core0 = kcalloc(num_pm_dev,
> > > > > > > > > +                                   sizeof(struct device *),
> > > > > > > > > +                                   GFP_KERNEL);
> > > > > > > > > +   if (!r5_core->pm_dev_core0)
> > > > > > > > > +           ret = -ENOMEM;
> > > > > > > > > +
> > > > > > > > > +   r5_core->pm_dev_core0_link = kcalloc(num_pm_dev,
> > > > > > > > > +                                        sizeof(struct device_link *),
> > > > > > > > > +                                        GFP_KERNEL);
> > > > > > > > > +   if (!r5_core->pm_dev_core0_link) {
> > > > > > > > > +           kfree(r5_core->pm_dev_core0);
> > > > > > > > > +           r5_core->pm_dev_core0 = NULL;
> > > > > > > > > +           return -ENOMEM;
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +   r5_core->num_pm_dev = num_pm_dev;
> > > > > > > > > +
> > > > > > > > > +   /*
> > > > > > > > > +    * start from 2nd entry in power-domains property list as
> > > > > > > > > +    * for zynqmp we only add TCM power domains and not core's power domain.
> > > > > > > > > +    * 1st entry is used to configure r5 operation mode.
> > > > > > > >
> > > > > > > > You are still not saying _where_ ->pm_dev_core0[0] gets added.
> > > > > > >
> > > > > > > So, pm_dev_core0[0] isn't really need to be added for zynqmp platform, as firmware starts it with call,
> > > > > > >
> > > > > > > zynqmp_pm_request_wake during rproc_start callback. I will document this in next
> > > > > > >
> > > > > >
> > > > > > That is exactly what I am looking for.  That way people don't have to go through
> > > > > > the entire driver trying to figure out what is happening with pm_dev_core[0].
> > > > > >
> > > > > > I'm also not sure about the power-up order.  Logically the TCMs should be
> > > > > > powered up before the R5 in order to put code in them.  The R5s are powered in
> > > > > > zynqmp_r5_rproc_start() but I am unclear as to where in the boot sequence the
> > > > > > TCMs are powered - can you expand on that?
> > > > >
> > > > >
> > > > > Sure. Following is call sequece
> > > > >
> > > > > zynqmp_r5_rproc_prepare
> > > > >
> > > > > zynqmp_r5_add_pm_domains -> Here TCM is powered on when device_link_add is called via zynqmp-pm-domains.c driver.
> > > > >
> > > > > . . .
> > > > >
> > > > > zynqmp_r5_rproc_start -> load firmware and Starts RPU
> > > > >
> > > > > So what you mentioned is correct, TCM is being powerd-on before we load firmware and start RPU.
> > > > >
> > > > >
> > > > > >
> > > > > > > revision. For new platforms pm_dev_core0[0] will be added in future.
> > > > > >
> > > > > > Now I'm really confused - what do you mean by "pm_dev_core0[0] will be added in
> > > > > > future"?
> > > > >
> > > > >
> > > > > ZynqMP platform has platform management firmware running on microblaze.
> > > > >
> > > > > This firmware design does not expect R5 pm domains to be requested explicitly.
> > > > >
> > > > > This means, during zynqmp_r5_rproc_start when "zynqmp_pm_request_wake" is called,
> > > > >
> > > > > firmware powers on R5. So, pm_dev_core[0] is not really used for ZynqMP.
> > > > >
> > > > > However, this design was changed for new platforms i.e. "versal" and onwards.
> > > > >
> > > > > Firmware of new platform expects pm domains to be requested explicitly for R5 cores before
> > > > >
> > > > > waking them up.
> > > > >
> > > > > That means, pm_dev_core[0] for R5 cores on new platform (Versal) needs to be used same as TCM.
> > > > >
> > > > > Then, we should wake it up on r5_core.
> > > > >
> > > > > To summarize:
> > > > >
> > > > > For zynqmp only following call needed to start R5:
> > > > >
> > > > > zynqmp_pm_request_wake
> > > > >
> > > > > For "versal" and onwards we need two calls to start R5:
> > > > >
> > > > > "device_link_add" and zynqmp_pm_request_wake
> > > > >
> > > > > So, in future pm_core_dev[0] will be used.
> > > > >
> > > >
> > > > Thanks for the clarification on both front.  The problem here is that we are
> > > > keeping R5 power domain information in two different places, i.e
> > > > zynqmp_r5_core::pm_domain_id and zynqmp_r5_core::pm_dev_core0[0].
> > > >
> > > > Please see if you can retreive the power domain ID from
> > > > zynqmp_r5_core::pm_dev_core0[0].  That way you can get the power domain ID when
> > > > calling zynqmp_pm_request_wake() and zynqmp_pm_force_pwrdwn() and get rid of
> > > > zynqmp_r5_core::pm_domain_id.
> > >
> > > Hi Mathieu,
> > >
> > > I looked into this. Probably I can't retrieve pm_domain_id from pm_dev_core0[0],
> > >
> > > However, I can retrieve it from device-tree when calling zynqmp_pm_request_wake
> > >
> > > and zynqmp_pm_force_pwrdwn.
> > >
> > > zynqmp_r5_core::pm_domain_id is caching that value during probe, and use it during
> > > rest of the driver lifecycle.
> > >
> > > I am okay either way, (keeping it as it is, or get it from device-tree). Let me know your
> > >
> > > preference.
> > >
> >
> > Humm...  Then I suggest to simply get rid of the device linking to
> > deal with the TCMs' power management.  From where I stand it provides
> > more confusion than benefits, and that is without considering the
> > extra complexity.
> 
> 
> Do you mean to get rid of pm_dev_core0[1], and pm_dev_core0[2] as well ?
>

Yes

> If yes, its preferred to use pm_domain framework to power-on/off TCM.
> 

That is when the pm runtime subsystem is used extensively but it isn't
the case here.  In this scenario using device linking is adding a lot of
complexity for something that could be done in a single line of code.   

> If we want to get rid of zynqmp_r5_core::pm_domain_id, I will do what's done in
> 
> __genpd_dev_pm_attach API where, pm_domain_id is retrieved using of_node of pm_dev_core0[*] device.
> 
> ??? ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
> ??????????????????????????? "#power-domain-cells", index, &pd_args);

That is what I asked for in my previous email, i.e use ->pm_dev_core0[0] to
retrieve the domain ID.

> 
> However, Its preferred to use pm_domain framework when power-domains are available in device-tree.
> 
> Let? me know.
> 
> Thanks,
> 
> Tanmay
> 
> 
> > > Thanks,
> > >
> > > Tanmay
> > >
> > > > >
> > > > > > >
> > > > > > > I hope this meets expectations.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > +    */
> > > > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > > > +           r5_core->pm_dev_core0[i] = dev_pm_domain_attach_by_id(dev, i);
> > > > > > > > > +           if (IS_ERR_OR_NULL(r5_core->pm_dev_core0[i])) {
> > > > > > > >
> > > > > > > > Here IS_ERR_OR_NULL() is used while two if conditions for NULL and an error
> > > > > > > > code are used in the loop for the lockstep mode.  Please pick one heuristic and
> > > > > > > > stick with it.  I have no preference on which one.
> > > > > > >
> > > > > > > Ok, I think IS_ERR_OR_NULL is more cleaner, I will address it in next revision.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > +                   dev_dbg(dev, "failed to attach pm domain %d, ret=%ld\n", i,
> > > > > > > > > +                           PTR_ERR(r5_core->pm_dev_core0[i]));
> > > > > > > > > +                   ret = -EINVAL;
> > > > > > > > > +                   goto fail_add_pm_domains;
> > > > > > > > > +           }
> > > > > > > > > +           r5_core->pm_dev_core0_link[i] = device_link_add(dev,
> > > > > > > > > +                                                           r5_core->pm_dev_core0[i],
> > > > > > > > > +                                                           DL_FLAG_STATELESS |
> > > > > > > > > +                                                           DL_FLAG_RPM_ACTIVE |
> > > > > > > > > +                                                           DL_FLAG_PM_RUNTIME);
> > > > > > > > > +           if (!r5_core->pm_dev_core0_link[i]) {
> > > > > > > > > +                   dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > > > > +                   r5_core->pm_dev_core0[i] = NULL;
> > > > > > > > > +                   ret = -EINVAL;
> > > > > > > > > +                   goto fail_add_pm_domains;
> > > > > > > > > +           }
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +   if (cluster->mode == SPLIT_MODE)
> > > > > > > > > +           return 0;
> > > > > > > > > +
> > > > > > > > > +   r5_core->pm_dev_core1 = kcalloc(num_pm_dev,
> > > > > > > > > +                                   sizeof(struct device *),
> > > > > > > > > +                                   GFP_KERNEL);
> > > > > > > > > +   if (!r5_core->pm_dev_core1) {
> > > > > > > > > +           ret = -ENOMEM;
> > > > > > > > > +           goto fail_add_pm_domains;
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +   r5_core->pm_dev_core1_link = kcalloc(num_pm_dev,
> > > > > > > > > +                                        sizeof(struct device_link *),
> > > > > > > > > +                                        GFP_KERNEL);
> > > > > > > > > +   if (!r5_core->pm_dev_core1_link) {
> > > > > > > > > +           kfree(r5_core->pm_dev_core1);
> > > > > > > > > +           r5_core->pm_dev_core1 = NULL;
> > > > > > > > > +           ret = -ENOMEM;
> > > > > > > > > +           goto fail_add_pm_domains;
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +   /* get second core's device to detach its power-domains */
> > > > > > > > > +   np = of_get_next_child(cluster->dev->of_node, of_node_get(dev->of_node));
> > > > > > > > > +
> > > > > > > > > +   pdev = of_find_device_by_node(np);
> > > > > > > > > +   if (!pdev) {
> > > > > > > > > +           dev_err(cluster->dev, "core1 platform device not available\n");
> > > > > > > > > +           kfree(r5_core->pm_dev_core1);
> > > > > > > > > +           kfree(r5_core->pm_dev_core1_link);
> > > > > > > > > +           r5_core->pm_dev_core1 = NULL;
> > > > > > > > > +           r5_core->pm_dev_core1_link = NULL;
> > > > > > > > > +           ret = -EINVAL;
> > > > > > > > > +           goto fail_add_pm_domains;
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +   dev2 = &pdev->dev;
> > > > > > > > > +
> > > > > > > > > +   /* for zynqmp we only add TCM power domains and not core's power domain */
> > > > > > > > > +   for (j = 1; j < r5_core->num_pm_dev; j++) {
> > > > > > > > > +           r5_core->pm_dev_core1[j] = dev_pm_domain_attach_by_id(dev2, j);
> > > > > > > > > +           if (!r5_core->pm_dev_core1[j]) {
> > > > > > > > > +                   dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > > > > +                   ret = -EINVAL;
> > > > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > > > +           } else if (IS_ERR(r5_core->pm_dev_core1[j])) {
> > > > > > > > > +                   dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > > > > +                   ret = PTR_ERR(r5_core->pm_dev_core1[j]);
> > > > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > > > +           }
> > > > > > > > > +
> > > > > > > > > +           r5_core->pm_dev_core1_link[j] = device_link_add(dev,
> > > > > > > > > +                                                           r5_core->pm_dev_core1[j],
> > > > > > > > > +                                                           DL_FLAG_STATELESS |
> > > > > > > > > +                                                           DL_FLAG_RPM_ACTIVE |
> > > > > > > > > +                                                           DL_FLAG_PM_RUNTIME);
> > > > > > > > > +           if (!r5_core->pm_dev_core1_link[j]) {
> > > > > > > > > +                   dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > > > > +                   r5_core->pm_dev_core1[j] = NULL;
> > > > > > > > > +                   ret = -ENODEV;
> > > > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > > > +           }
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +fail_add_pm_domains_lockstep:
> > > > > > > > > +   while (--j >= 0) {
> > > > > > > > > +           device_link_del(r5_core->pm_dev_core1_link[j]);
> > > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > > > > +   }
> > > > > > > > > +   kfree(r5_core->pm_dev_core1);
> > > > > > > > > +   r5_core->pm_dev_core1 = NULL;
> > > > > > > > > +   kfree(r5_core->pm_dev_core1_link);
> > > > > > > > > +   r5_core->pm_dev_core1_link = NULL;
> > > > > > > > > +
> > > > > > > > > +fail_add_pm_domains:
> > > > > > > > > +   while (--i >= 0) {
> > > > > > > > > +           device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > > > > +   }
> > > > > > > > > +   kfree(r5_core->pm_dev_core0);
> > > > > > > > > +   r5_core->pm_dev_core0 = NULL;
> > > > > > > > > +   kfree(r5_core->pm_dev_core0_link);
> > > > > > > > > +   r5_core->pm_dev_core0_link = NULL;
> > > > > > > > > +
> > > > > > > >
> > > > > > > > The error path is much cleaner and readable now.
> > > > > > > >
> > > > > > > > I will continue tomorrow.
> > > > > > > >
> > > > > > > > Mathieu
> > > > > > > >
> > > > > > > > > +   return ret;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > >  /**
> > > > > > > > >   * zynqmp_r5_rproc_prepare()
> > > > > > > > >   * adds carveouts for TCM bank and reserved memory regions
> > > > > > > > > @@ -770,19 +966,30 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
> > > > > > > > >  {
> > > > > > > > >     int ret;
> > > > > > > > >
> > > > > > > > > +   ret = zynqmp_r5_add_pm_domains(rproc);
> > > > > > > > > +   if (ret) {
> > > > > > > > > +           dev_err(&rproc->dev, "failed to add pm domains\n");
> > > > > > > > > +           return ret;
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > >     ret = add_tcm_banks(rproc);
> > > > > > > > >     if (ret) {
> > > > > > > > >             dev_err(&rproc->dev, "failed to get TCM banks, err %d\n", ret);
> > > > > > > > > -           return ret;
> > > > > > > > > +           goto fail_prepare;
> > > > > > > > >     }
> > > > > > > > >
> > > > > > > > >     ret = add_mem_regions_carveout(rproc);
> > > > > > > > >     if (ret) {
> > > > > > > > >             dev_err(&rproc->dev, "failed to get reserve mem regions %d\n", ret);
> > > > > > > > > -           return ret;
> > > > > > > > > +           goto fail_prepare;
> > > > > > > > >     }
> > > > > > > > >
> > > > > > > > >     return 0;
> > > > > > > > > +
> > > > > > > > > +fail_prepare:
> > > > > > > > > +   zynqmp_r5_remove_pm_domains(rproc);
> > > > > > > > > +
> > > > > > > > > +   return ret;
> > > > > > > > >  }
> > > > > > > > >
> > > > > > > > >  /**
> > > > > > > > > @@ -801,6 +1008,8 @@ static int zynqmp_r5_rproc_unprepare(struct rproc *rproc)
> > > > > > > > >
> > > > > > > > >     r5_core = rproc->priv;
> > > > > > > > >
> > > > > > > > > +   zynqmp_r5_remove_pm_domains(rproc);
> > > > > > > > > +
> > > > > > > > >     for (i = 0; i < r5_core->tcm_bank_count; i++) {
> > > > > > > > >             pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
> > > > > > > > >             if (zynqmp_pm_release_node(pm_domain_id))
> > > > > > > > > --
> > > > > > > > > 2.25.1
> > > > > > > > >


From thierry.reding at gmail.com  Fri Dec  8 07:52:57 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 8 Dec 2023 16:52:57 +0100
Subject: [PATCH] pwm: meson: Simplify using dev_err_probe()
In-Reply-To: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
Message-ID: <ZXM72QYBbb32Q_aL@orome.fritz.box>

On Wed, Dec 06, 2023 at 10:48:18PM +0100, Uwe Kleine-K?nig wrote:
> Using dev_err_probe() emitting an error message mentioning a return
> value and returning that value can be done in a single statement. Make
> use of that to simplify the probe part of the driver. This has the
> additional advantage to emit the symbolic name for the error instead of
> the integer error value.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
> Hello,
> 
> while trying to understand Jerome's series[1] I noticed this patch
> opportunity.
> 
> Best regards
> Uwe
> 
> [1] https://lore.kernel.org/linux-pwm/20231129134004.3642121-1-jbrunet at baylibre.com
> 
>  drivers/pwm/pwm-meson.c | 35 ++++++++++++++---------------------
>  1 file changed, 14 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
> index 5bea53243ed2..2971bbf3b5e7 100644
> --- a/drivers/pwm/pwm-meson.c
> +++ b/drivers/pwm/pwm-meson.c
> @@ -468,10 +468,9 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
>  		channel->mux.hw.init = &init;
>  
>  		err = devm_clk_hw_register(dev, &channel->mux.hw);
> -		if (err) {
> -			dev_err(dev, "failed to register %s: %d\n", name, err);
> -			return err;
> -		}
> +		if (err)
> +			return dev_err_probe(dev, err,
> +					     "failed to register %s\n", name);
>  
>  		snprintf(name, sizeof(name), "%s#div%u", dev_name(dev), i);
>  
> @@ -491,10 +490,9 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
>  		channel->div.lock = &meson->lock;
>  
>  		err = devm_clk_hw_register(dev, &channel->div.hw);
> -		if (err) {
> -			dev_err(dev, "failed to register %s: %d\n", name, err);
> -			return err;
> -		}
> +		if (err)
> +			return dev_err_probe(dev, err,
> +					     "failed to register %s\n", name);
>  
>  		snprintf(name, sizeof(name), "%s#gate%u", dev_name(dev), i);
>  
> @@ -513,17 +511,13 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
>  		channel->gate.lock = &meson->lock;
>  
>  		err = devm_clk_hw_register(dev, &channel->gate.hw);
> -		if (err) {
> -			dev_err(dev, "failed to register %s: %d\n", name, err);
> -			return err;
> -		}
> +		if (err)
> +			return dev_err_probe(dev, err, "failed to register %s\n", name);
>  
>  		channel->clk = devm_clk_hw_get_clk(dev, &channel->gate.hw, NULL);
> -		if (IS_ERR(channel->clk)) {
> -			err = PTR_ERR(channel->clk);
> -			dev_err(dev, "failed to register %s: %d\n", name, err);
> -			return err;
> -		}
> +		if (IS_ERR(channel->clk))
> +			return dev_err_probe(dev, PTR_ERR(channel->clk),
> +					     "failed to register %s\n", name);
>  	}
>  
>  	return 0;
> @@ -554,10 +548,9 @@ static int meson_pwm_probe(struct platform_device *pdev)
>  		return err;
>  
>  	err = devm_pwmchip_add(&pdev->dev, &meson->chip);
> -	if (err < 0) {
> -		dev_err(&pdev->dev, "failed to register PWM chip: %d\n", err);
> -		return err;
> -	}
> +	if (err < 0)
> +		return dev_err_probe(&pdev->dev, err,
> +				     "failed to register PWM chip\n");
>  
>  	return 0;
>  }

This is a lot of churn for very little gain. None of these functions are
ever going to return -EPROBE_DEFER. And yes, I know that function's doc
says that it is "deemed acceptable to use" elsewhere. However, the
existing error messages are just fine, no need to churn just for the
sake of it.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/a8d8472f/attachment.sig>

From tanmay.shah at amd.com  Fri Dec  8 08:05:51 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Fri, 8 Dec 2023 10:05:51 -0600
Subject: [PATCH v7 3/4] remoteproc: zynqmp: add pm domains support
In-Reply-To: <ZXM7hZlTAbBb8Iox@p14s>
References: <20231117174238.1876655-1-tanmay.shah@amd.com>
 <20231117174238.1876655-4-tanmay.shah@amd.com> <ZV02P3bHEhPLQHBo@p14s>
 <93487d3c-c324-4b9b-8b25-0b4ea52237b4@amd.com> <ZV+V6V2sEWgsqngk@p14s>
 <a75b22c1-66e3-4fce-ae64-de79e73f3cfa@amd.com> <ZWdwl/8LC2Nn+vCq@p14s>
 <ea2edc6e-6655-47f8-8b6d-242f5a0ef804@amd.com>
 <CANLsYkzJgZRSz5=nzW+ATmBKemoSd3ybhKuz1CJy33hftAGiqw@mail.gmail.com>
 <2e24d9be-be10-4f80-b3af-c3e0ed003e7b@amd.com> <ZXM7hZlTAbBb8Iox@p14s>
Message-ID: <e59205ec-3ad5-4c58-a8aa-6e2957c3decf@amd.com>


On 12/8/23 9:51 AM, Mathieu Poirier wrote:
> On Wed, Dec 06, 2023 at 12:06:45PM -0600, Tanmay Shah wrote:
> > 
> > On 12/6/23 9:43 AM, Mathieu Poirier wrote:
> > > On Fri, 1 Dec 2023 at 11:10, Tanmay Shah <tanmay.shah at amd.com> wrote:
> > > >
> > > >
> > > > On 11/29/23 11:10 AM, Mathieu Poirier wrote:
> > > > > On Mon, Nov 27, 2023 at 10:33:05AM -0600, Tanmay Shah wrote:
> > > > > >
> > > > > > On 11/23/23 12:11 PM, Mathieu Poirier wrote:
> > > > > > > On Wed, Nov 22, 2023 at 03:00:36PM -0600, Tanmay Shah wrote:
> > > > > > > > Hi Mathieu,
> > > > > > > >
> > > > > > > > Please find my comments below.
> > > > > > > >
> > > > > > > > On 11/21/23 4:59 PM, Mathieu Poirier wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On Fri, Nov 17, 2023 at 09:42:37AM -0800, Tanmay Shah wrote:
> > > > > > > > > > Use TCM pm domains extracted from device-tree
> > > > > > > > > > to power on/off TCM using general pm domain framework.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > Changes in v7:
> > > > > > > > > >   - %s/pm_dev1/pm_dev_core0/r
> > > > > > > > > >   - %s/pm_dev_link1/pm_dev_core0_link/r
> > > > > > > > > >   - %s/pm_dev2/pm_dev_core1/r
> > > > > > > > > >   - %s/pm_dev_link2/pm_dev_core1_link/r
> > > > > > > > > >   - remove pm_domain_id check to move next patch
> > > > > > > > > >   - add comment about how 1st entry in pm domain list is used
> > > > > > > > > >   - fix loop when jump to fail_add_pm_domains loop
> > > > > > > > > >
> > > > > > > > > >  drivers/remoteproc/xlnx_r5_remoteproc.c | 215 +++++++++++++++++++++++-
> > > > > > > > > >  1 file changed, 212 insertions(+), 3 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > > > > index 4395edea9a64..22bccc5075a0 100644
> > > > > > > > > > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > > > > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > > > > > > > > > @@ -16,6 +16,7 @@
> > > > > > > > > >  #include <linux/of_reserved_mem.h>
> > > > > > > > > >  #include <linux/platform_device.h>
> > > > > > > > > >  #include <linux/remoteproc.h>
> > > > > > > > > > +#include <linux/pm_domain.h>
> > > > > > > > > >
> > > > > > > > > >  #include "remoteproc_internal.h"
> > > > > > > > > >
> > > > > > > > > > @@ -102,6 +103,12 @@ static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
> > > > > > > > > >   * @rproc: rproc handle
> > > > > > > > > >   * @pm_domain_id: RPU CPU power domain id
> > > > > > > > > >   * @ipi: pointer to mailbox information
> > > > > > > > > > + * @num_pm_dev: number of tcm pm domain devices for this core
> > > > > > > > > > + * @pm_dev_core0: pm domain virtual devices for power domain framework
> > > > > > > > > > + * @pm_dev_core0_link: pm domain device links after registration
> > > > > > > > > > + * @pm_dev_core1: used only in lockstep mode. second core's pm domain virtual devices
> > > > > > > > > > + * @pm_dev_core1_link: used only in lockstep mode. second core's pm device links after
> > > > > > > > > > + * registration
> > > > > > > > > >   */
> > > > > > > > > >  struct zynqmp_r5_core {
> > > > > > > > > >     struct device *dev;
> > > > > > > > > > @@ -111,6 +118,11 @@ struct zynqmp_r5_core {
> > > > > > > > > >     struct rproc *rproc;
> > > > > > > > > >     u32 pm_domain_id;
> > > > > > > > > >     struct mbox_info *ipi;
> > > > > > > > > > +   int num_pm_dev;
> > > > > > > > > > +   struct device **pm_dev_core0;
> > > > > > > > > > +   struct device_link **pm_dev_core0_link;
> > > > > > > > > > +   struct device **pm_dev_core1;
> > > > > > > > > > +   struct device_link **pm_dev_core1_link;
> > > > > > > > > >  };
> > > > > > > > > >
> > > > > > > > > >  /**
> > > > > > > > > > @@ -651,7 +663,8 @@ static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
> > > > > > > > > >                                          ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> > > > > > > > > >                                          ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> > > > > > > > > >             if (ret < 0) {
> > > > > > > > > > -                   dev_err(dev, "failed to turn on TCM 0x%x", pm_domain_id);
> > > > > > > > > > +                   dev_err(dev, "failed to turn on TCM 0x%x",
> > > > > > > > > > +                           pm_domain_id);
> > > > > > > > >
> > > > > > > > > Spurious change, you should have caught that.
> > > > > > > >
> > > > > > > > Ack, need to observe changes more closely before sending them.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >                     goto release_tcm_lockstep;
> > > > > > > > > >             }
> > > > > > > > > >
> > > > > > > > > > @@ -758,6 +771,189 @@ static int zynqmp_r5_parse_fw(struct rproc *rproc, const struct firmware *fw)
> > > > > > > > > >     return ret;
> > > > > > > > > >  }
> > > > > > > > > >
> > > > > > > > > > +static void zynqmp_r5_remove_pm_domains(struct rproc *rproc)
> > > > > > > > > > +{
> > > > > > > > > > +   struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > > > > > +   struct device *dev = r5_core->dev;
> > > > > > > > > > +   struct zynqmp_r5_cluster *cluster;
> > > > > > > > > > +   int i;
> > > > > > > > > > +
> > > > > > > > > > +   cluster = platform_get_drvdata(to_platform_device(dev->parent));
> > > > > > > > > > +
> > > > > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > > > > +           device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core0[i], false);
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   kfree(r5_core->pm_dev_core0);
> > > > > > > > > > +   r5_core->pm_dev_core0 = NULL;
> > > > > > > > > > +   kfree(r5_core->pm_dev_core0_link);
> > > > > > > > > > +   r5_core->pm_dev_core0_link = NULL;
> > > > > > > > > > +
> > > > > > > > > > +   if (cluster->mode == SPLIT_MODE) {
> > > > > > > > > > +           r5_core->num_pm_dev = 0;
> > > > > > > > > > +           return;
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > > > > +           device_link_del(r5_core->pm_dev_core1_link[i]);
> > > > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core1[i], false);
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   kfree(r5_core->pm_dev_core1);
> > > > > > > > > > +   r5_core->pm_dev_core1 = NULL;
> > > > > > > > > > +   kfree(r5_core->pm_dev_core1_link);
> > > > > > > > > > +   r5_core->pm_dev_core1_link = NULL;
> > > > > > > > > > +   r5_core->num_pm_dev = 0;
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > > +static int zynqmp_r5_add_pm_domains(struct rproc *rproc)
> > > > > > > > > > +{
> > > > > > > > > > +   struct zynqmp_r5_core *r5_core = rproc->priv;
> > > > > > > > > > +   struct device *dev = r5_core->dev, *dev2;
> > > > > > > > > > +   struct zynqmp_r5_cluster *cluster;
> > > > > > > > > > +   struct platform_device *pdev;
> > > > > > > > > > +   struct device_node *np;
> > > > > > > > > > +   int i, j, num_pm_dev, ret;
> > > > > > > > > > +
> > > > > > > > > > +   cluster = dev_get_drvdata(dev->parent);
> > > > > > > > > > +
> > > > > > > > > > +   /* get number of power-domains */
> > > > > > > > > > +   num_pm_dev = of_count_phandle_with_args(r5_core->np, "power-domains",
> > > > > > > > > > +                                           "#power-domain-cells");
> > > > > > > > > > +
> > > > > > > > > > +   if (num_pm_dev <= 0)
> > > > > > > > > > +           return -EINVAL;
> > > > > > > > > > +
> > > > > > > > > > +   r5_core->pm_dev_core0 = kcalloc(num_pm_dev,
> > > > > > > > > > +                                   sizeof(struct device *),
> > > > > > > > > > +                                   GFP_KERNEL);
> > > > > > > > > > +   if (!r5_core->pm_dev_core0)
> > > > > > > > > > +           ret = -ENOMEM;
> > > > > > > > > > +
> > > > > > > > > > +   r5_core->pm_dev_core0_link = kcalloc(num_pm_dev,
> > > > > > > > > > +                                        sizeof(struct device_link *),
> > > > > > > > > > +                                        GFP_KERNEL);
> > > > > > > > > > +   if (!r5_core->pm_dev_core0_link) {
> > > > > > > > > > +           kfree(r5_core->pm_dev_core0);
> > > > > > > > > > +           r5_core->pm_dev_core0 = NULL;
> > > > > > > > > > +           return -ENOMEM;
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   r5_core->num_pm_dev = num_pm_dev;
> > > > > > > > > > +
> > > > > > > > > > +   /*
> > > > > > > > > > +    * start from 2nd entry in power-domains property list as
> > > > > > > > > > +    * for zynqmp we only add TCM power domains and not core's power domain.
> > > > > > > > > > +    * 1st entry is used to configure r5 operation mode.
> > > > > > > > >
> > > > > > > > > You are still not saying _where_ ->pm_dev_core0[0] gets added.
> > > > > > > >
> > > > > > > > So, pm_dev_core0[0] isn't really need to be added for zynqmp platform, as firmware starts it with call,
> > > > > > > >
> > > > > > > > zynqmp_pm_request_wake during rproc_start callback. I will document this in next
> > > > > > > >
> > > > > > >
> > > > > > > That is exactly what I am looking for.  That way people don't have to go through
> > > > > > > the entire driver trying to figure out what is happening with pm_dev_core[0].
> > > > > > >
> > > > > > > I'm also not sure about the power-up order.  Logically the TCMs should be
> > > > > > > powered up before the R5 in order to put code in them.  The R5s are powered in
> > > > > > > zynqmp_r5_rproc_start() but I am unclear as to where in the boot sequence the
> > > > > > > TCMs are powered - can you expand on that?
> > > > > >
> > > > > >
> > > > > > Sure. Following is call sequece
> > > > > >
> > > > > > zynqmp_r5_rproc_prepare
> > > > > >
> > > > > > zynqmp_r5_add_pm_domains -> Here TCM is powered on when device_link_add is called via zynqmp-pm-domains.c driver.
> > > > > >
> > > > > > . . .
> > > > > >
> > > > > > zynqmp_r5_rproc_start -> load firmware and Starts RPU
> > > > > >
> > > > > > So what you mentioned is correct, TCM is being powerd-on before we load firmware and start RPU.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > > revision. For new platforms pm_dev_core0[0] will be added in future.
> > > > > > >
> > > > > > > Now I'm really confused - what do you mean by "pm_dev_core0[0] will be added in
> > > > > > > future"?
> > > > > >
> > > > > >
> > > > > > ZynqMP platform has platform management firmware running on microblaze.
> > > > > >
> > > > > > This firmware design does not expect R5 pm domains to be requested explicitly.
> > > > > >
> > > > > > This means, during zynqmp_r5_rproc_start when "zynqmp_pm_request_wake" is called,
> > > > > >
> > > > > > firmware powers on R5. So, pm_dev_core[0] is not really used for ZynqMP.
> > > > > >
> > > > > > However, this design was changed for new platforms i.e. "versal" and onwards.
> > > > > >
> > > > > > Firmware of new platform expects pm domains to be requested explicitly for R5 cores before
> > > > > >
> > > > > > waking them up.
> > > > > >
> > > > > > That means, pm_dev_core[0] for R5 cores on new platform (Versal) needs to be used same as TCM.
> > > > > >
> > > > > > Then, we should wake it up on r5_core.
> > > > > >
> > > > > > To summarize:
> > > > > >
> > > > > > For zynqmp only following call needed to start R5:
> > > > > >
> > > > > > zynqmp_pm_request_wake
> > > > > >
> > > > > > For "versal" and onwards we need two calls to start R5:
> > > > > >
> > > > > > "device_link_add" and zynqmp_pm_request_wake
> > > > > >
> > > > > > So, in future pm_core_dev[0] will be used.
> > > > > >
> > > > >
> > > > > Thanks for the clarification on both front.  The problem here is that we are
> > > > > keeping R5 power domain information in two different places, i.e
> > > > > zynqmp_r5_core::pm_domain_id and zynqmp_r5_core::pm_dev_core0[0].
> > > > >
> > > > > Please see if you can retreive the power domain ID from
> > > > > zynqmp_r5_core::pm_dev_core0[0].  That way you can get the power domain ID when
> > > > > calling zynqmp_pm_request_wake() and zynqmp_pm_force_pwrdwn() and get rid of
> > > > > zynqmp_r5_core::pm_domain_id.
> > > >
> > > > Hi Mathieu,
> > > >
> > > > I looked into this. Probably I can't retrieve pm_domain_id from pm_dev_core0[0],
> > > >
> > > > However, I can retrieve it from device-tree when calling zynqmp_pm_request_wake
> > > >
> > > > and zynqmp_pm_force_pwrdwn.
> > > >
> > > > zynqmp_r5_core::pm_domain_id is caching that value during probe, and use it during
> > > > rest of the driver lifecycle.
> > > >
> > > > I am okay either way, (keeping it as it is, or get it from device-tree). Let me know your
> > > >
> > > > preference.
> > > >
> > >
> > > Humm...  Then I suggest to simply get rid of the device linking to
> > > deal with the TCMs' power management.  From where I stand it provides
> > > more confusion than benefits, and that is without considering the
> > > extra complexity.
> > 
> > 
> > Do you mean to get rid of pm_dev_core0[1], and pm_dev_core0[2] as well ?
> >
>
> Yes
>
> > If yes, its preferred to use pm_domain framework to power-on/off TCM.
> > 
>
> That is when the pm runtime subsystem is used extensively but it isn't
> the case here.  In this scenario using device linking is adding a lot of
> complexity for something that could be done in a single line of code.   

Ok fair point, please give me sometime to explore more.

I don't mind getting rid of pm domain framework usage. For some reason, if we must use it,

we can always introduce it later.

I just want to make sure if we don't use pm domains framework, then remoteproc works for

future platforms as well. I will get back to you as need to do more testing after removing pm domains framework.

Thanks,

Tanmay


> > If we want to get rid of zynqmp_r5_core::pm_domain_id, I will do what's done in
> > 
> > __genpd_dev_pm_attach API where, pm_domain_id is retrieved using of_node of pm_dev_core0[*] device.
> > 
> > ??? ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
> > ??????????????????????????? "#power-domain-cells", index, &pd_args);
>
> That is what I asked for in my previous email, i.e use ->pm_dev_core0[0] to
> retrieve the domain ID.
>
> > 
> > However, Its preferred to use pm_domain framework when power-domains are available in device-tree.
> > 
> > Let? me know.
> > 
> > Thanks,
> > 
> > Tanmay
> > 
> > 
> > > > Thanks,
> > > >
> > > > Tanmay
> > > >
> > > > > >
> > > > > > > >
> > > > > > > > I hope this meets expectations.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > +    */
> > > > > > > > > > +   for (i = 1; i < r5_core->num_pm_dev; i++) {
> > > > > > > > > > +           r5_core->pm_dev_core0[i] = dev_pm_domain_attach_by_id(dev, i);
> > > > > > > > > > +           if (IS_ERR_OR_NULL(r5_core->pm_dev_core0[i])) {
> > > > > > > > >
> > > > > > > > > Here IS_ERR_OR_NULL() is used while two if conditions for NULL and an error
> > > > > > > > > code are used in the loop for the lockstep mode.  Please pick one heuristic and
> > > > > > > > > stick with it.  I have no preference on which one.
> > > > > > > >
> > > > > > > > Ok, I think IS_ERR_OR_NULL is more cleaner, I will address it in next revision.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > +                   dev_dbg(dev, "failed to attach pm domain %d, ret=%ld\n", i,
> > > > > > > > > > +                           PTR_ERR(r5_core->pm_dev_core0[i]));
> > > > > > > > > > +                   ret = -EINVAL;
> > > > > > > > > > +                   goto fail_add_pm_domains;
> > > > > > > > > > +           }
> > > > > > > > > > +           r5_core->pm_dev_core0_link[i] = device_link_add(dev,
> > > > > > > > > > +                                                           r5_core->pm_dev_core0[i],
> > > > > > > > > > +                                                           DL_FLAG_STATELESS |
> > > > > > > > > > +                                                           DL_FLAG_RPM_ACTIVE |
> > > > > > > > > > +                                                           DL_FLAG_PM_RUNTIME);
> > > > > > > > > > +           if (!r5_core->pm_dev_core0_link[i]) {
> > > > > > > > > > +                   dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > > > > > +                   r5_core->pm_dev_core0[i] = NULL;
> > > > > > > > > > +                   ret = -EINVAL;
> > > > > > > > > > +                   goto fail_add_pm_domains;
> > > > > > > > > > +           }
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   if (cluster->mode == SPLIT_MODE)
> > > > > > > > > > +           return 0;
> > > > > > > > > > +
> > > > > > > > > > +   r5_core->pm_dev_core1 = kcalloc(num_pm_dev,
> > > > > > > > > > +                                   sizeof(struct device *),
> > > > > > > > > > +                                   GFP_KERNEL);
> > > > > > > > > > +   if (!r5_core->pm_dev_core1) {
> > > > > > > > > > +           ret = -ENOMEM;
> > > > > > > > > > +           goto fail_add_pm_domains;
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   r5_core->pm_dev_core1_link = kcalloc(num_pm_dev,
> > > > > > > > > > +                                        sizeof(struct device_link *),
> > > > > > > > > > +                                        GFP_KERNEL);
> > > > > > > > > > +   if (!r5_core->pm_dev_core1_link) {
> > > > > > > > > > +           kfree(r5_core->pm_dev_core1);
> > > > > > > > > > +           r5_core->pm_dev_core1 = NULL;
> > > > > > > > > > +           ret = -ENOMEM;
> > > > > > > > > > +           goto fail_add_pm_domains;
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   /* get second core's device to detach its power-domains */
> > > > > > > > > > +   np = of_get_next_child(cluster->dev->of_node, of_node_get(dev->of_node));
> > > > > > > > > > +
> > > > > > > > > > +   pdev = of_find_device_by_node(np);
> > > > > > > > > > +   if (!pdev) {
> > > > > > > > > > +           dev_err(cluster->dev, "core1 platform device not available\n");
> > > > > > > > > > +           kfree(r5_core->pm_dev_core1);
> > > > > > > > > > +           kfree(r5_core->pm_dev_core1_link);
> > > > > > > > > > +           r5_core->pm_dev_core1 = NULL;
> > > > > > > > > > +           r5_core->pm_dev_core1_link = NULL;
> > > > > > > > > > +           ret = -EINVAL;
> > > > > > > > > > +           goto fail_add_pm_domains;
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   dev2 = &pdev->dev;
> > > > > > > > > > +
> > > > > > > > > > +   /* for zynqmp we only add TCM power domains and not core's power domain */
> > > > > > > > > > +   for (j = 1; j < r5_core->num_pm_dev; j++) {
> > > > > > > > > > +           r5_core->pm_dev_core1[j] = dev_pm_domain_attach_by_id(dev2, j);
> > > > > > > > > > +           if (!r5_core->pm_dev_core1[j]) {
> > > > > > > > > > +                   dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > > > > > +                   ret = -EINVAL;
> > > > > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > > > > +           } else if (IS_ERR(r5_core->pm_dev_core1[j])) {
> > > > > > > > > > +                   dev_dbg(dev, "can't attach to pm domain %d\n", j);
> > > > > > > > > > +                   ret = PTR_ERR(r5_core->pm_dev_core1[j]);
> > > > > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > > > > +           }
> > > > > > > > > > +
> > > > > > > > > > +           r5_core->pm_dev_core1_link[j] = device_link_add(dev,
> > > > > > > > > > +                                                           r5_core->pm_dev_core1[j],
> > > > > > > > > > +                                                           DL_FLAG_STATELESS |
> > > > > > > > > > +                                                           DL_FLAG_RPM_ACTIVE |
> > > > > > > > > > +                                                           DL_FLAG_PM_RUNTIME);
> > > > > > > > > > +           if (!r5_core->pm_dev_core1_link[j]) {
> > > > > > > > > > +                   dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > > > > > +                   r5_core->pm_dev_core1[j] = NULL;
> > > > > > > > > > +                   ret = -ENODEV;
> > > > > > > > > > +                   goto fail_add_pm_domains_lockstep;
> > > > > > > > > > +           }
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +fail_add_pm_domains_lockstep:
> > > > > > > > > > +   while (--j >= 0) {
> > > > > > > > > > +           device_link_del(r5_core->pm_dev_core1_link[j]);
> > > > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core1[j], true);
> > > > > > > > > > +   }
> > > > > > > > > > +   kfree(r5_core->pm_dev_core1);
> > > > > > > > > > +   r5_core->pm_dev_core1 = NULL;
> > > > > > > > > > +   kfree(r5_core->pm_dev_core1_link);
> > > > > > > > > > +   r5_core->pm_dev_core1_link = NULL;
> > > > > > > > > > +
> > > > > > > > > > +fail_add_pm_domains:
> > > > > > > > > > +   while (--i >= 0) {
> > > > > > > > > > +           device_link_del(r5_core->pm_dev_core0_link[i]);
> > > > > > > > > > +           dev_pm_domain_detach(r5_core->pm_dev_core0[i], true);
> > > > > > > > > > +   }
> > > > > > > > > > +   kfree(r5_core->pm_dev_core0);
> > > > > > > > > > +   r5_core->pm_dev_core0 = NULL;
> > > > > > > > > > +   kfree(r5_core->pm_dev_core0_link);
> > > > > > > > > > +   r5_core->pm_dev_core0_link = NULL;
> > > > > > > > > > +
> > > > > > > > >
> > > > > > > > > The error path is much cleaner and readable now.
> > > > > > > > >
> > > > > > > > > I will continue tomorrow.
> > > > > > > > >
> > > > > > > > > Mathieu
> > > > > > > > >
> > > > > > > > > > +   return ret;
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > >  /**
> > > > > > > > > >   * zynqmp_r5_rproc_prepare()
> > > > > > > > > >   * adds carveouts for TCM bank and reserved memory regions
> > > > > > > > > > @@ -770,19 +966,30 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
> > > > > > > > > >  {
> > > > > > > > > >     int ret;
> > > > > > > > > >
> > > > > > > > > > +   ret = zynqmp_r5_add_pm_domains(rproc);
> > > > > > > > > > +   if (ret) {
> > > > > > > > > > +           dev_err(&rproc->dev, "failed to add pm domains\n");
> > > > > > > > > > +           return ret;
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > >     ret = add_tcm_banks(rproc);
> > > > > > > > > >     if (ret) {
> > > > > > > > > >             dev_err(&rproc->dev, "failed to get TCM banks, err %d\n", ret);
> > > > > > > > > > -           return ret;
> > > > > > > > > > +           goto fail_prepare;
> > > > > > > > > >     }
> > > > > > > > > >
> > > > > > > > > >     ret = add_mem_regions_carveout(rproc);
> > > > > > > > > >     if (ret) {
> > > > > > > > > >             dev_err(&rproc->dev, "failed to get reserve mem regions %d\n", ret);
> > > > > > > > > > -           return ret;
> > > > > > > > > > +           goto fail_prepare;
> > > > > > > > > >     }
> > > > > > > > > >
> > > > > > > > > >     return 0;
> > > > > > > > > > +
> > > > > > > > > > +fail_prepare:
> > > > > > > > > > +   zynqmp_r5_remove_pm_domains(rproc);
> > > > > > > > > > +
> > > > > > > > > > +   return ret;
> > > > > > > > > >  }
> > > > > > > > > >
> > > > > > > > > >  /**
> > > > > > > > > > @@ -801,6 +1008,8 @@ static int zynqmp_r5_rproc_unprepare(struct rproc *rproc)
> > > > > > > > > >
> > > > > > > > > >     r5_core = rproc->priv;
> > > > > > > > > >
> > > > > > > > > > +   zynqmp_r5_remove_pm_domains(rproc);
> > > > > > > > > > +
> > > > > > > > > >     for (i = 0; i < r5_core->tcm_bank_count; i++) {
> > > > > > > > > >             pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
> > > > > > > > > >             if (zynqmp_pm_release_node(pm_domain_id))
> > > > > > > > > > --
> > > > > > > > > > 2.25.1
> > > > > > > > > >


From u.kleine-koenig at pengutronix.de  Fri Dec  8 08:08:10 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri,  8 Dec 2023 17:08:10 +0100
Subject: [PATCH 5/7] pcmcia: pxa2xx: Convert to platform remove callback returning void
In-Reply-To: <cover.1702051073.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702051073.git.u.kleine-koenig@pengutronix.de>
Message-ID: <fb750d46ac80b6dfdeaa26053a2cf9d2dc875d4d.1702051073.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pcmcia/pxa2xx_base.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pcmcia/pxa2xx_base.c b/drivers/pcmcia/pxa2xx_base.c
index 5254028354f4..457fb81b497a 100644
--- a/drivers/pcmcia/pxa2xx_base.c
+++ b/drivers/pcmcia/pxa2xx_base.c
@@ -313,15 +313,13 @@ static int pxa2xx_drv_pcmcia_probe(struct platform_device *dev)
 	return ret;
 }
 
-static int pxa2xx_drv_pcmcia_remove(struct platform_device *dev)
+static void pxa2xx_drv_pcmcia_remove(struct platform_device *dev)
 {
 	struct skt_dev_info *sinfo = platform_get_drvdata(dev);
 	int i;
 
 	for (i = 0; i < sinfo->nskt; i++)
 		soc_pcmcia_remove_one(&sinfo->skt[i]);
-
-	return 0;
 }
 
 static int pxa2xx_drv_pcmcia_resume(struct device *dev)
@@ -338,7 +336,7 @@ static const struct dev_pm_ops pxa2xx_drv_pcmcia_pm_ops = {
 
 static struct platform_driver pxa2xx_pcmcia_driver = {
 	.probe		= pxa2xx_drv_pcmcia_probe,
-	.remove		= pxa2xx_drv_pcmcia_remove,
+	.remove_new	= pxa2xx_drv_pcmcia_remove,
 	.driver		= {
 		.name	= "pxa2xx-pcmcia",
 		.pm	= &pxa2xx_drv_pcmcia_pm_ops,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec  8 08:08:05 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri,  8 Dec 2023 17:08:05 +0100
Subject: [PATCH 0/7] pcmcia: Convert to platform remove callback returning void
Message-ID: <cover.1702051073.git.u.kleine-koenig@pengutronix.de>

Hello,

this series changes all platform drivers in drivers/pcmcia to use the
.remove_new() callback. See commit 5c5a7680e67b ("platform: Provide a
remove callback that returns no value") for an extended explanation and
the eventual goal.

All conversations are trivial, because all .remove() callbacks returned
zero unconditionally already.

There are no interdependencies between these patches, so they could be
picked up individually. However I'd expect them to go in all together.
It's unclrear to me though, who will pick them up. Dominik? Greg?

Best regards
Uwe

Uwe Kleine-K?nig (7):
  pcmcia: bcm63xx: Convert to platform remove callback returning void
  pcmcia: db1xxx_ss: Convert to platform remove callback returning void
  pcmcia: electra_cf: Convert to platform remove callback returning void
  pcmcia: omap_cf: Convert to platform remove callback returning void
  pcmcia: pxa2xx: Convert to platform remove callback returning void
  pcmcia: sa1100: Convert to platform remove callback returning void
  pcmcia: xxs1500_ss: Convert to platform remove callback returning void

 drivers/pcmcia/bcm63xx_pcmcia.c | 5 ++---
 drivers/pcmcia/db1xxx_ss.c      | 6 ++----
 drivers/pcmcia/electra_cf.c     | 6 ++----
 drivers/pcmcia/omap_cf.c        | 5 ++---
 drivers/pcmcia/pxa2xx_base.c    | 6 ++----
 drivers/pcmcia/sa1100_generic.c | 8 +++-----
 drivers/pcmcia/xxs1500_ss.c     | 6 ++----
 7 files changed, 15 insertions(+), 27 deletions(-)

base-commit: 8e00ce02066e8f6f1ad5eab49a2ede7bf7a5ef64
-- 
2.42.0



From thierry.reding at gmail.com  Fri Dec  8 08:22:52 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 8 Dec 2023 17:22:52 +0100
Subject: [PATCH v6 3/4] pwm: bcm2835: allow pwm driver to be used in
 atomic context
In-Reply-To: <179dc1ce85702a8b64b43c0e0df656b0c5e3ce30.1701248996.git.sean@mess.org>
References: <cover.1701248996.git.sean@mess.org>
 <179dc1ce85702a8b64b43c0e0df656b0c5e3ce30.1701248996.git.sean@mess.org>
Message-ID: <ZXNC3JYy7CTfYsyC@orome.fritz.box>

On Wed, Nov 29, 2023 at 09:13:36AM +0000, Sean Young wrote:
> clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
> rate changes using clk_rate_exclusive_get().
> 
> Signed-off-by: Sean Young <sean at mess.org>
> ---
>  drivers/pwm/pwm-bcm2835.c | 31 +++++++++++++++++++++----------
>  1 file changed, 21 insertions(+), 10 deletions(-)

s/pwm/PWM/ in the subject. Although, I guess you could just drop the
"PWM" altogether because the subject prefix implies that this is for
PWM. Also, please capitalize after the subject prefix.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/9fae49b9/attachment.sig>

From ahalaney at redhat.com  Fri Dec  8 08:33:41 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Fri, 8 Dec 2023 10:33:41 -0600
Subject: [PATCH net-next v2] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <9eddb32d-c798-4e1b-b0ea-c44d31cc29bf@lunn.ch>
References: <20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca@redhat.com>
 <e64b14c3-4b80-4120-8cc4-9baa40cdcb75@lunn.ch>
 <nx2qggr3aget4t57qbosj6ya5ocq47t6w33ve5ycabs5mzvo7c@vctjvc5gip5d>
 <9eddb32d-c798-4e1b-b0ea-c44d31cc29bf@lunn.ch>
Message-ID: <plvbqgi2bwlv5quvpiwplq7cxx6m5rl3ghnfhuxfx4bpuhyihl@zmydwrtwdeg6>

On Fri, Dec 08, 2023 at 02:14:41PM +0100, Andrew Lunn wrote:
> > I know you said the standard is to make the MDIO bus unconditionally, but
> > to me that feels like a waste, and describing say an empty MDIO bus
> > (which would set the phy_mask for us eventually and not scan a
> > bunch of phys, untested but I think that would work) seems like a bad
> > description in the devicetree (I could definitely see describing an
> > empty MDIO bus getting NACKed, but that's a guess).
> 
> DT describes the hardware. The MDIO bus master exists. So typically
> the SoC .dtsi file would include it in the Ethernet node. At the SoC
> level it is empty, unless there is an integrated PHY in the SoC. The
> board .dts file then adds any PHYs to the node which the board
> actually has.
> 
> So i doubt adding an empty MDIO node to the SoC .dtsi file will get
> NACKed, it correctly describes the hardware.

Agreed, thanks for helping me consider all the cases. In my particular
example it would make sense to have SoC dtsi describe the mdio bus,
leave it disabled, and boards enable it and describe components as
necessary.

So you have let's say these 8 abbreviated cases:

Case 1 (MDIO bus used with phy on bus connected to MAC):

	ethernet {
		status = "okay";
		phy-handle = <&phy0>;
		phy-mode = "rgmii";

		mdio {
			status = "okay";

			phy0: phy at 0 {
			};
		};
	};

Case 2 (MDIO bus used but MAC's connect fixed-link):

	ethernet {
		status = "okay";
		phy-mode = "rgmii";

		fixed-link {
		};

		mdio {
			status = "okay";

			switch/unrelated-phy {
			};
		};
	};

Case 3 (MDIO bus used but MAC's connected to another bus's phy):

	ethernet {
		status = "okay";
		phy-handle = <&phy1>;
		phy-mode = "rgmii";

		mdio {
			status = "okay";

			switch/unrelated-phy {
			};
		};
	};

Case 4 (MDIO bus disabled/unused, connected fixed-link):

	ethernet {
		status = "okay";
		phy-mode = "rgmii";

		fixed-link {
		};

		mdio {
			status = "disabled";
		};
	};

Case 5 (MDIO bus disabled/unused, connected to another bus's phy):

	ethernet {
		status = "okay";
		phy-handle = <&phy1>;
		phy-mode = "rgmii";

		mdio {
			status = "disabled";
		};
	};

Case 6 (MDIO bus not described, connected fixed-link):

	ethernet {
		status = "okay";
		phy-mode = "rgmii";

		fixed-link {
		};
	};

Case 7 (MDIO bus not described, connected to a different bus's phy):

	ethernet {
		status = "okay";
		phy-handle = <&phy1>;
		phy-mode = "rgmii";
	};

Case 8 (MDIO bus not described, but phy on MDIO bus is connected to MAC,
        legacy description[2] in my commit message):

	ethernet {
		status = "okay";
	};


If we look at the logic in stmmac today about how to handle the MDIO
bus, you've got basically:

	if !fixed-link || mdio_node_present()
		of_mdiobus_register(np)

Applying current stmmac logic to our cases...

Case 1 (MDIO bus used with phy on bus connected to MAC):
    MDIO bus made, no unnecessary scanning

Case 2 (MDIO bus used but MAC's fixed-link):
    MDIO bus made, no unnecessary scanning

Case 3 (MDIO bus used but MAC's connected to another bus's phy):
    MDIO bus made, no unnecessary scanning

Case 4 (MDIO bus disabled/unused, connected fixed-link):
    MDIO bus attempted to be made, fails -ENODEV due to disabled
    and stmmac returns -ENODEV from probe too

Case 5 (MDIO bus disabled/unused, connected to another bus's phy):
    MDIO bus attempted to be made, fails -ENODEV due to disabled
    and stmmac returns -ENODEV from probe too

Case 6 (MDIO bus not described, connected fixed-link):
    MDIO bus not created

Case 7 (MDIO bus not described, connected to a different bus's phy):
    MDIO bus created, but the whole bus is scanned

Case 8 (MDIO bus not described, but phy on MDIO bus is connected to MAC,
        legacy description[2] in my commit message):
    MDIO bus created, the whole bus is scanned and the undescribed but
    necessary phy is found


The things I note of interest are cases 4, 5, 7, 8. Cases 4/5 are a bug in
stmmac IMO, which breaks the devicetree description you mentioned as
ideal in my case. Case 7 is the one I'm currently working with, and the
devicetree can be updated to match case 5, but right now case 7 makes a
bus and scans it needlessly which isn't great. It _sounds_ like to me
Serge knows of stmmac variants that also *do not* have an MDIO controller,
so they'd fall in this case too and really shouldn't create a bus. Case 8
is the legacy one that I wish didn't exist, but it does, and for that
reason we should continue to make a bus and scan the whole thing if we can't
figure out what the MAC's connected to.

So in my opinion there's 3 changes I want to make based on all the
use cases I could think of:

    1. This patch, which improves the stmmac logic and stops making
       a bus for case 7
    2. A new patch to gracefully handle cases 4/5, where currently if the
       MDIO bus is disabled in the devicetree, as it should be,
       stmmac handles -ENODEV from of_mdiobus_register() as a failure
       instead of gracefully continuing knowing this is fine and dandy.
    3. Clean up the sa8775p dts to have the MDIO bus described in the
       SoC dtsi and left disabled instead of undescribed (a more
       accurate hardware description).

Please let me know if you see any holes in my logic, hopefully the
wall of text is useful in explaining how I got here.

Thanks,
Andrew



From robh at kernel.org  Fri Dec  8 08:44:41 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 8 Dec 2023 10:44:41 -0600
Subject: [PATCH v1 1/3] dt-bindings: drm: rockchip: convert
 inno_hdmi-rockchip.txt to yaml
In-Reply-To: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
References: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
Message-ID: <170205385847.1747356.13765108616438619401.robh@kernel.org>


On Mon, 04 Dec 2023 18:39:03 +0100, Johan Jonker wrote:
> Convert inno_hdmi-rockchip.txt to yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> 
> Note for rob+dt:
>   Used enum to "soon" be able to add "rockchip,rk3128-inno-hdmi"
> 
> Changed V1:
>   Rename file to more common layout
>   Add/fix hdmi_out port example
> ---
>  .../display/rockchip/inno_hdmi-rockchip.txt   |  49 ---------
>  .../display/rockchip/rockchip,inno-hdmi.yaml  | 103 ++++++++++++++++++
>  2 files changed, 103 insertions(+), 49 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>  create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> 

Applied, thanks!



From alain.volmat at foss.st.com  Fri Dec  8 08:47:09 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 8 Dec 2023 17:47:09 +0100
Subject: [PATCH v2 0/7] i2c: stm32f7: enhancements and support for stm32mp25
Message-ID: <20231208164719.3584028-1-alain.volmat@foss.st.com>

This series first perform enhancements in the way interrupt are handled
and cleanup in messages.
Then it adds support for the stm32mp25 which differs in that
it only has a single irq line for both event/error and has a
different handling of the FastModePlus.
Support is then enabled within the stm32mp25 related device-trees.

Changelog:
v2: - correct st,stm32-i2c.yaml.  Use if then else scheme to indicate
      number of interrupts / interrupt-names depending on the
      compatible while keeping the description within the common part

    - correct 2 maybe-uninitialized warnings
          * ret in stm32f7_i2c_write_fm_plus_bits
          * irq_error in stm32f7_i2c_probe, move the platform_get_irq
            within the same if block as devm_request_threaded_irq

Alain Volmat (7):
  i2c: stm32f7: perform most of irq job in threaded handler
  i2c: stm32f7: simplify status messages in case of errors
  dt-bindings: i2c: document st,stm32mp25-i2c compatible
  i2c: stm32f7: add support for stm32mp25 soc
  arm64: dts: st: add all 8 i2c nodes on stm32mp251
  arm64: dts: st: add i2c2/i2c8 pins for stm32mp25
  arm64: dts: st: add i2c2 / i2c8 properties on stm32mp257f-ev1

 .../devicetree/bindings/i2c/st,stm32-i2c.yaml |  28 ++
 arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi |  36 ++
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  96 +++++
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |  20 ++
 drivers/i2c/busses/i2c-stm32f7.c              | 334 ++++++++++--------
 5 files changed, 357 insertions(+), 157 deletions(-)

-- 
2.25.1



From ankita at nvidia.com  Fri Dec  8 08:47:07 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Fri, 8 Dec 2023 22:17:07 +0530
Subject: [PATCH v3 0/2]  kvm: arm64: allow vm to select DEVICE_* and
Message-ID: <20231208164709.23101-1-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

Currently, KVM for ARM64 maps at stage 2 memory that is considered device
(i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting
overrides (as per the ARM architecture [1]) any device MMIO mapping
present at stage 1, resulting in a set-up whereby a guest operating
system cannot determine device MMIO mapping memory attributes on its
own but it is always overridden by the KVM stage 2 default.

This set-up does not allow guest operating systems to select device
memory attributes independently from KVM stage-2 mappings
(refer to [1], "Combining stage 1 and stage 2 memory type attributes"),
which turns out to be an issue in that guest operating systems
(e.g. Linux) may request to map devices MMIO regions with memory
attributes that guarantee better performance (e.g. gathering
attribute - that for some devices can generate larger PCIe memory
writes TLPs) and specific operations (e.g. unaligned transactions)
such as the NormalNC memory type.

The default device stage 2 mapping was chosen in KVM for ARM64 since
it was considered safer (i.e. it would not allow guests to trigger
uncontained failures ultimately crashing the machine) but this
turned out to be asynchronous (SError) defeating the purpose.

Failures containability is a property of the platform and is independent
from the memory type used for MMIO device memory mappings.

Actually, DEVICE_nGnRE memory type is even more problematic than
Normal-NC memory type in terms of faults containability in that e.g.
aborts triggered on DEVICE_nGnRE loads cannot be made, architecturally,
synchronous (i.e. that would imply that the processor should issue at
most 1 load transaction at a time - it cannot pipeline them - otherwise
the synchronous abort semantics would break the no-speculation attribute
attached to DEVICE_XXX memory).

This means that regardless of the combined stage1+stage2 mappings a
platform is safe if and only if device transactions cannot trigger
uncontained failures and that in turn relies on platform capabilities
and the device type being assigned (i.e. PCIe AER/DPC error containment
and RAS architecture[3]); therefore the default KVM device stage 2
memory attributes play no role in making device assignment safer
for a given platform (if the platform design adheres to design
guidelines outlined in [3]) and therefore can be relaxed.

For all these reasons, relax the KVM stage 2 device memory attributes
from DEVICE_nGnRE to Normal-NC.

The NormalNC was chosen over a different Normal memory type default
at stage-2 (e.g. Normal Write-through) to avoid cache allocation/snooping.

Relaxing S2 KVM device MMIO mappings to Normal-NC is not expected to
trigger any issue on guest device reclaim use cases either (i.e. device
MMIO unmap followed by a device reset) at least for PCIe devices, in that
in PCIe a device reset is architected and carried out through PCI config
space transactions that are naturally ordered with respect to MMIO
transactions according to the PCI ordering rules.

Having Normal-NC S2 default puts guests in control (thanks to
stage1+stage2 combined memory attributes rules [1]) of device MMIO
regions memory mappings, according to the rules described in [1]
and summarized here ([(S1) - stage1], [(S2) - stage 2]):

S1           |  S2           | Result
NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>

It is worth noting that currently, to map devices MMIO space to user
space in a device pass-through use case the VFIO framework applies memory
attributes derived from pgprot_noncached() settings applied to VMAs, which
result in device-nGnRnE memory attributes for the stage-1 VMM mappings.

This means that a userspace mapping for device MMIO space carried
out with the current VFIO framework and a guest OS mapping for the same
MMIO space may result in a mismatched alias as described in [2].

Defaulting KVM device stage-2 mappings to Normal-NC attributes does not
change anything in this respect, in that the mismatched aliases would
only affect (refer to [2] for a detailed explanation) ordering between
the userspace and GuestOS mappings resulting stream of transactions
(i.e. it does not cause loss of property for either stream of
transactions on its own), which is harmless given that the userspace
and GuestOS access to the device is carried out through independent
transactions streams.

Generalizing to other devices may be problematic. E.g. GICv2 VCPU
interface, which is effectively a shared peripheral, can allow a
guest to affect another guest's interrupt distribution. Hence
limit the change to VFIO PCI as caution. This is achieved by
making the VFIO PCI core module set a flag that is tested by KVM
to activate the code. This could be extended to other devices in
the future once that is deemed safe.

[1] section D8.5 - DDI0487J_a_a-profile_architecture_reference_manual.pdf
[2] section B2.8 - DDI0487J_a_a-profile_architecture_reference_manual.pdf
[3] sections 1.7.7.3/1.8.5.2/appendix C - DEN0029H_SBSA_7.1.pdf

Applied over next-20231201

History
=======
v2 -> v3
- Added a new patch (and converted to patch series) suggested by
  Catalin Marinas to ensure the code changes are restricted to
  VFIO PCI devices.
- Introduced VM_VFIO_ALLOW_WC flag for VFIO PCI to communicate
  with VMM.
- Reverted GIC mapping to DEVICE.

v1 -> v2
- Updated commit log to the one posted by
  Lorenzo Pieralisi <lpieralisi at kernel.org> (Thanks!)
- Added new flag to represent the NORMAL_NC setting. Updated
  stage2_set_prot_attr() to handle new flag.

v2 Link:
https://lore.kernel.org/all/20231205033015.10044-1-ankita at nvidia.com/

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>

Ankit Agrawal (2):
  kvm: arm64: introduce new flag for non-cacheable IO memory
  kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices

 arch/arm64/include/asm/kvm_pgtable.h |  2 ++
 arch/arm64/include/asm/memory.h      |  2 ++
 arch/arm64/kvm/hyp/pgtable.c         | 14 ++++++++++++--
 arch/arm64/kvm/mmu.c                 | 16 +++++++++++++---
 drivers/vfio/pci/vfio_pci_core.c     |  3 ++-
 include/linux/mm.h                   |  7 +++++++
 6 files changed, 38 insertions(+), 6 deletions(-)

-- 
2.17.1



From alain.volmat at foss.st.com  Fri Dec  8 08:47:10 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 8 Dec 2023 17:47:10 +0100
Subject: [PATCH v2 1/7] i2c: stm32f7: perform most of irq job in threaded handler
In-Reply-To: <20231208164719.3584028-1-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
Message-ID: <20231208164719.3584028-2-alain.volmat@foss.st.com>

The irq handling is currently split between the irq handler
and the threaded irq handler.  Some of the handling (such as
dma related stuffs) done within the irq handler might sleep or
take some time leading to issues if the kernel is built with
realtime constraints.  In order to fix that, perform an overall
rework to perform most of the job within the threaded handler
and only keep fifo access in the non threaded handler.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 drivers/i2c/busses/i2c-stm32f7.c | 126 ++++++++++++++-----------------
 1 file changed, 56 insertions(+), 70 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 983509936727..34dcc370e615 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -1497,17 +1497,11 @@ static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev)
 static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
-	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
-	struct stm32_i2c_dma *dma = i2c_dev->dma;
-	void __iomem *base = i2c_dev->base;
-	u32 status, mask;
-	int ret = IRQ_HANDLED;
+	u32 status;
 
-	/* Check if the interrupt if for a slave device */
-	if (!i2c_dev->master_mode) {
-		ret = stm32f7_i2c_slave_isr_event(i2c_dev);
-		return ret;
-	}
+	/* Check if the interrupt is for a slave device */
+	if (!i2c_dev->master_mode)
+		return IRQ_WAKE_THREAD;
 
 	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
 
@@ -1519,6 +1513,29 @@ static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 	if (status & STM32F7_I2C_ISR_RXNE)
 		stm32f7_i2c_read_rx_data(i2c_dev);
 
+	/* Wake up the thread if other flags are raised */
+	if (status &
+	    (STM32F7_I2C_ISR_NACKF | STM32F7_I2C_ISR_STOPF |
+	     STM32F7_I2C_ISR_TC | STM32F7_I2C_ISR_TCR))
+		return IRQ_WAKE_THREAD;
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
+{
+	struct stm32f7_i2c_dev *i2c_dev = data;
+	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
+	struct stm32_i2c_dma *dma = i2c_dev->dma;
+	void __iomem *base = i2c_dev->base;
+	u32 status, mask;
+	int ret;
+
+	if (!i2c_dev->master_mode)
+		return stm32f7_i2c_slave_isr_event(i2c_dev);
+
+	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
+
 	/* NACK received */
 	if (status & STM32F7_I2C_ISR_NACKF) {
 		dev_dbg(i2c_dev->dev, "<%s>: Receive NACK (addr %x)\n",
@@ -1531,33 +1548,28 @@ static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 		f7_msg->result = -ENXIO;
 	}
 
-	/* STOP detection flag */
-	if (status & STM32F7_I2C_ISR_STOPF) {
-		/* Disable interrupts */
-		if (stm32f7_i2c_is_slave_registered(i2c_dev))
-			mask = STM32F7_I2C_XFER_IRQ_MASK;
+	if (status & STM32F7_I2C_ISR_TCR) {
+		if (f7_msg->smbus)
+			stm32f7_i2c_smbus_reload(i2c_dev);
 		else
-			mask = STM32F7_I2C_ALL_IRQ_MASK;
-		stm32f7_i2c_disable_irq(i2c_dev, mask);
-
-		/* Clear STOP flag */
-		writel_relaxed(STM32F7_I2C_ICR_STOPCF, base + STM32F7_I2C_ICR);
-
-		if (i2c_dev->use_dma && !f7_msg->result) {
-			ret = IRQ_WAKE_THREAD;
-		} else {
-			i2c_dev->master_mode = false;
-			complete(&i2c_dev->complete);
-		}
+			stm32f7_i2c_reload(i2c_dev);
 	}
 
 	/* Transfer complete */
 	if (status & STM32F7_I2C_ISR_TC) {
+		/* Wait for dma transfer completion before sending next message */
+		if (i2c_dev->use_dma && !f7_msg->result) {
+			ret = wait_for_completion_timeout(&i2c_dev->dma->dma_complete, HZ);
+			if (!ret) {
+				dev_dbg(i2c_dev->dev, "<%s>: Timed out\n", __func__);
+				stm32f7_i2c_disable_dma_req(i2c_dev);
+				dmaengine_terminate_async(dma->chan_using);
+				f7_msg->result = -ETIMEDOUT;
+			}
+		}
 		if (f7_msg->stop) {
 			mask = STM32F7_I2C_CR2_STOP;
 			stm32f7_i2c_set_bits(base + STM32F7_I2C_CR2, mask);
-		} else if (i2c_dev->use_dma && !f7_msg->result) {
-			ret = IRQ_WAKE_THREAD;
 		} else if (f7_msg->smbus) {
 			stm32f7_i2c_smbus_rep_start(i2c_dev);
 		} else {
@@ -1567,47 +1579,18 @@ static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 		}
 	}
 
-	if (status & STM32F7_I2C_ISR_TCR) {
-		if (f7_msg->smbus)
-			stm32f7_i2c_smbus_reload(i2c_dev);
+	/* STOP detection flag */
+	if (status & STM32F7_I2C_ISR_STOPF) {
+		/* Disable interrupts */
+		if (stm32f7_i2c_is_slave_registered(i2c_dev))
+			mask = STM32F7_I2C_XFER_IRQ_MASK;
 		else
-			stm32f7_i2c_reload(i2c_dev);
-	}
-
-	return ret;
-}
-
-static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
-{
-	struct stm32f7_i2c_dev *i2c_dev = data;
-	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
-	struct stm32_i2c_dma *dma = i2c_dev->dma;
-	u32 status;
-	int ret;
-
-	/*
-	 * Wait for dma transfer completion before sending next message or
-	 * notity the end of xfer to the client
-	 */
-	ret = wait_for_completion_timeout(&i2c_dev->dma->dma_complete, HZ);
-	if (!ret) {
-		dev_dbg(i2c_dev->dev, "<%s>: Timed out\n", __func__);
-		stm32f7_i2c_disable_dma_req(i2c_dev);
-		dmaengine_terminate_async(dma->chan_using);
-		f7_msg->result = -ETIMEDOUT;
-	}
+			mask = STM32F7_I2C_ALL_IRQ_MASK;
+		stm32f7_i2c_disable_irq(i2c_dev, mask);
 
-	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
+		/* Clear STOP flag */
+		writel_relaxed(STM32F7_I2C_ICR_STOPCF, base + STM32F7_I2C_ICR);
 
-	if (status & STM32F7_I2C_ISR_TC) {
-		if (f7_msg->smbus) {
-			stm32f7_i2c_smbus_rep_start(i2c_dev);
-		} else {
-			i2c_dev->msg_id++;
-			i2c_dev->msg++;
-			stm32f7_i2c_xfer_msg(i2c_dev, i2c_dev->msg);
-		}
-	} else {
 		i2c_dev->master_mode = false;
 		complete(&i2c_dev->complete);
 	}
@@ -1615,7 +1598,7 @@ static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
-static irqreturn_t stm32f7_i2c_isr_error(int irq, void *data)
+static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
 	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
@@ -2205,8 +2188,11 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	ret = devm_request_irq(&pdev->dev, irq_error, stm32f7_i2c_isr_error, 0,
-			       pdev->name, i2c_dev);
+	ret = devm_request_threaded_irq(&pdev->dev, irq_error,
+					NULL,
+					stm32f7_i2c_isr_error_thread,
+					IRQF_ONESHOT,
+					pdev->name, i2c_dev);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to request irq error %i\n",
 			irq_error);
-- 
2.25.1



From ankita at nvidia.com  Fri Dec  8 08:47:08 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Fri, 8 Dec 2023 22:17:08 +0530
Subject: [PATCH v3 1/2] kvm: arm64: introduce new flag for non-cacheable IO memory
In-Reply-To: <20231208164709.23101-1-ankita@nvidia.com>
References: <20231208164709.23101-1-ankita@nvidia.com>
Message-ID: <20231208164709.23101-2-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

For various reasons described in the cover letter, and primarily to
allow VM get IO memory with NORMALNC properties, it is desired
to relax the KVM stage 2 device memory attributes from DEVICE_nGnRE
to NormalNC. So set S2 PTE for IO memory as NORMAL_NC.

A Normal-NC flag is not present today. So add a new kvm_pgtable_prot
(KVM_PGTABLE_PROT_NORMAL_NC) flag for it, along with its
corresponding PTE value 0x5 (0b101) determined from [1].

Lastly, adapt the stage2 PTE property setter function
(stage2_set_prot_attr) to handle the NormalNC attribute.

[1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>
---
 arch/arm64/include/asm/kvm_pgtable.h |  2 ++
 arch/arm64/include/asm/memory.h      |  2 ++
 arch/arm64/kvm/hyp/pgtable.c         | 11 +++++++++--
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index cfdf40f734b1..19278dfe7978 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -197,6 +197,7 @@ enum kvm_pgtable_stage2_flags {
  * @KVM_PGTABLE_PROT_W:		Write permission.
  * @KVM_PGTABLE_PROT_R:		Read permission.
  * @KVM_PGTABLE_PROT_DEVICE:	Device attributes.
+ * @KVM_PGTABLE_PROT_NORMAL_NC:	Normal noncacheable attributes.
  * @KVM_PGTABLE_PROT_SW0:	Software bit 0.
  * @KVM_PGTABLE_PROT_SW1:	Software bit 1.
  * @KVM_PGTABLE_PROT_SW2:	Software bit 2.
@@ -208,6 +209,7 @@ enum kvm_pgtable_prot {
 	KVM_PGTABLE_PROT_R			= BIT(2),
 
 	KVM_PGTABLE_PROT_DEVICE			= BIT(3),
+	KVM_PGTABLE_PROT_NORMAL_NC		= BIT(4),
 
 	KVM_PGTABLE_PROT_SW0			= BIT(55),
 	KVM_PGTABLE_PROT_SW1			= BIT(56),
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index fde4186cc387..c247e5f29d5a 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -147,6 +147,7 @@
  * Memory types for Stage-2 translation
  */
 #define MT_S2_NORMAL		0xf
+#define MT_S2_NORMAL_NC		0x5
 #define MT_S2_DEVICE_nGnRE	0x1
 
 /*
@@ -154,6 +155,7 @@
  * Stage-2 enforces Normal-WB and Device-nGnRE
  */
 #define MT_S2_FWB_NORMAL	6
+#define MT_S2_FWB_NORMAL_NC	5
 #define MT_S2_FWB_DEVICE_nGnRE	1
 
 #ifdef CONFIG_ARM64_4K_PAGES
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index c651df904fe3..d4835d553c61 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -718,10 +718,17 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
 				kvm_pte_t *ptep)
 {
 	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
-	kvm_pte_t attr = device ? KVM_S2_MEMATTR(pgt, DEVICE_nGnRE) :
-			    KVM_S2_MEMATTR(pgt, NORMAL);
+	bool normal_nc = prot & KVM_PGTABLE_PROT_NORMAL_NC;
+	kvm_pte_t attr;
 	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
 
+	if (device)
+		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
+	else if (normal_nc)
+		attr = KVM_S2_MEMATTR(pgt, NORMAL_NC);
+	else
+		attr = KVM_S2_MEMATTR(pgt, NORMAL);
+
 	if (!(prot & KVM_PGTABLE_PROT_X))
 		attr |= KVM_PTE_LEAF_ATTR_HI_S2_XN;
 	else if (device)
-- 
2.17.1



From ankita at nvidia.com  Fri Dec  8 08:47:09 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Fri, 8 Dec 2023 22:17:09 +0530
Subject: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices
In-Reply-To: <20231208164709.23101-1-ankita@nvidia.com>
References: <20231208164709.23101-1-ankita@nvidia.com>
Message-ID: <20231208164709.23101-3-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

To provide VM with the ability to get device IO memory with NormalNC
property, map device MMIO in KVM for ARM64 at stage2 as NormalNC.
Having NormalNC S2 default puts guests in control (based on [1],
"Combining stage 1 and stage 2 memory type attributes") of device
MMIO regions memory mappings. The rules are summarized below:
([(S1) - stage1], [(S2) - stage 2])

S1           |  S2           | Result
NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>

Generalizing this to non PCI devices may be problematic. E.g. GICv2
vCPU interface, which is effectively a shared peripheral, can allow
a guest to affect another guest's interrupt distribution. The issue
may be solved by limiting the relaxation to mappings that have a user
VMA. Still There is insufficient information and uncertainity in the
behavior of non PCI driver. Hence caution is maintained and the change
is restricted to the VFIO-PCI devices. PCIe on the other hand is safe
because the PCI bridge does not generate errors, and thus do not cause
uncontained failures.

Limiting to the VFIO PCI module is done with the help of a new mm
flag VM_VFIO_ALLOW_WC. The VFIO PCI core module set this flag to
communicate to KVM. KVM use this flag to activate the code.

This could be extended to other devices in the future once that
is deemed safe.

[1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Jason Gunthorpe <jgg at nvidia.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>
---
 arch/arm64/kvm/hyp/pgtable.c     |  3 +++
 arch/arm64/kvm/mmu.c             | 16 +++++++++++++---
 drivers/vfio/pci/vfio_pci_core.c |  3 ++-
 include/linux/mm.h               |  7 +++++++
 4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index d4835d553c61..c8696c9e7a60 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -722,6 +722,9 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
 	kvm_pte_t attr;
 	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
 
+	if (device && normal_nc)
+		return -EINVAL;
+
 	if (device)
 		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
 	else if (normal_nc)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index d14504821b79..1ce1b6d89bf9 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1381,7 +1381,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	int ret = 0;
 	bool write_fault, writable, force_pte = false;
 	bool exec_fault, mte_allowed;
-	bool device = false;
+	bool device = false, vfio_pci_device = false;
 	unsigned long mmu_seq;
 	struct kvm *kvm = vcpu->kvm;
 	struct kvm_mmu_memory_cache *memcache = &vcpu->arch.mmu_page_cache;
@@ -1472,6 +1472,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	gfn = fault_ipa >> PAGE_SHIFT;
 	mte_allowed = kvm_vma_mte_allowed(vma);
 
+	vfio_pci_device = !!(vma->vm_flags & VM_VFIO_ALLOW_WC);
+
 	/* Don't use the VMA after the unlock -- it may have vanished */
 	vma = NULL;
 
@@ -1557,8 +1559,16 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	if (exec_fault)
 		prot |= KVM_PGTABLE_PROT_X;
 
-	if (device)
-		prot |= KVM_PGTABLE_PROT_DEVICE;
+	if (device) {
+		/*
+		 * To provide VM with the ability to get device IO memory
+		 * with NormalNC property, map device MMIO as NormalNC in S2.
+		 */
+		if (vfio_pci_device)
+			prot |= KVM_PGTABLE_PROT_NORMAL_NC;
+		else
+			prot |= KVM_PGTABLE_PROT_DEVICE;
+	}
 	else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
 		prot |= KVM_PGTABLE_PROT_X;
 
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 1cbc990d42e0..c3f95ec7fc3a 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1863,7 +1863,8 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
 	 * See remap_pfn_range(), called from vfio_pci_fault() but we can't
 	 * change vm_flags within the fault handler.  Set them now.
 	 */
-	vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
+	vm_flags_set(vma, VM_VFIO_ALLOW_WC | VM_IO | VM_PFNMAP |
+			VM_DONTEXPAND | VM_DONTDUMP);
 	vma->vm_ops = &vfio_pci_mmap_ops;
 
 	return 0;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a422cc123a2d..8d3c4820c492 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -391,6 +391,13 @@ extern unsigned int kobjsize(const void *objp);
 # define VM_UFFD_MINOR		VM_NONE
 #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
 
+#ifdef CONFIG_64BIT
+#define VM_VFIO_ALLOW_WC_BIT	39	/* Convey KVM to map S2 NORMAL_NC */
+#define VM_VFIO_ALLOW_WC	BIT(VM_VFIO_ALLOW_WC_BIT)
+#else
+#define VM_VFIO_ALLOW_WC	VM_NONE
+#endif
+
 /* Bits set in the VMA until the stack is in its final location */
 #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
 
-- 
2.17.1



From alain.volmat at foss.st.com  Fri Dec  8 08:47:11 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 8 Dec 2023 17:47:11 +0100
Subject: [PATCH v2 2/7] i2c: stm32f7: simplify status messages in case of errors
In-Reply-To: <20231208164719.3584028-1-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
Message-ID: <20231208164719.3584028-3-alain.volmat@foss.st.com>

Avoid usage of __func__ when reporting an error message
since dev_err/dev_dbg are already providing enough details
to identify the source of the message.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 drivers/i2c/busses/i2c-stm32f7.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 34dcc370e615..2a011deec3c5 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -1602,6 +1602,7 @@ static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
 	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
+	u16 addr = f7_msg->addr;
 	void __iomem *base = i2c_dev->base;
 	struct device *dev = i2c_dev->dev;
 	struct stm32_i2c_dma *dma = i2c_dev->dma;
@@ -1611,8 +1612,7 @@ static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 
 	/* Bus error */
 	if (status & STM32F7_I2C_ISR_BERR) {
-		dev_err(dev, "<%s>: Bus error accessing addr 0x%x\n",
-			__func__, f7_msg->addr);
+		dev_err(dev, "Bus error accessing addr 0x%x\n", addr);
 		writel_relaxed(STM32F7_I2C_ICR_BERRCF, base + STM32F7_I2C_ICR);
 		stm32f7_i2c_release_bus(&i2c_dev->adap);
 		f7_msg->result = -EIO;
@@ -1620,21 +1620,19 @@ static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 
 	/* Arbitration loss */
 	if (status & STM32F7_I2C_ISR_ARLO) {
-		dev_dbg(dev, "<%s>: Arbitration loss accessing addr 0x%x\n",
-			__func__, f7_msg->addr);
+		dev_dbg(dev, "Arbitration loss accessing addr 0x%x\n", addr);
 		writel_relaxed(STM32F7_I2C_ICR_ARLOCF, base + STM32F7_I2C_ICR);
 		f7_msg->result = -EAGAIN;
 	}
 
 	if (status & STM32F7_I2C_ISR_PECERR) {
-		dev_err(dev, "<%s>: PEC error in reception accessing addr 0x%x\n",
-			__func__, f7_msg->addr);
+		dev_err(dev, "PEC error in reception accessing addr 0x%x\n", addr);
 		writel_relaxed(STM32F7_I2C_ICR_PECCF, base + STM32F7_I2C_ICR);
 		f7_msg->result = -EINVAL;
 	}
 
 	if (status & STM32F7_I2C_ISR_ALERT) {
-		dev_dbg(dev, "<%s>: SMBus alert received\n", __func__);
+		dev_dbg(dev, "SMBus alert received\n");
 		writel_relaxed(STM32F7_I2C_ICR_ALERTCF, base + STM32F7_I2C_ICR);
 		i2c_handle_smbus_alert(i2c_dev->alert->ara);
 		return IRQ_HANDLED;
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec  8 08:47:12 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 8 Dec 2023 17:47:12 +0100
Subject: [PATCH v2 3/7] dt-bindings: i2c: document st,stm32mp25-i2c compatible
In-Reply-To: <20231208164719.3584028-1-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
Message-ID: <20231208164719.3584028-4-alain.volmat@foss.st.com>

Add a new compatible st,stm32mp25-i2c for the STM32MP25 series which
has only one interrupt line for both events and errors and differs in
term of handling of FastModePlus.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
index 94b75d9f66cd..1b31b87c1800 100644
--- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
@@ -19,6 +19,7 @@ allOf:
               - st,stm32f7-i2c
               - st,stm32mp13-i2c
               - st,stm32mp15-i2c
+              - st,stm32mp25-i2c
     then:
       properties:
         i2c-scl-rising-time-ns:
@@ -41,6 +42,30 @@ allOf:
         clock-frequency:
           enum: [100000, 400000]
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - st,stm32f4-i2c
+              - st,stm32f7-i2c
+              - st,stm32mp13-i2c
+              - st,stm32mp15-i2c
+    then:
+      properties:
+        interrupts:
+          minItems: 2
+
+        interrupt-names:
+          minItems: 2
+    else:
+      properties:
+        interrupts:
+          maxItems: 1
+
+        interrupt-names:
+          maxItems: 1
+
 properties:
   compatible:
     enum:
@@ -48,6 +73,7 @@ properties:
       - st,stm32f7-i2c
       - st,stm32mp13-i2c
       - st,stm32mp15-i2c
+      - st,stm32mp25-i2c
 
   reg:
     maxItems: 1
@@ -56,11 +82,13 @@ properties:
     items:
       - description: interrupt ID for I2C event
       - description: interrupt ID for I2C error
+    minItems: 1
 
   interrupt-names:
     items:
       - const: event
       - const: error
+    minItems: 1
 
   resets:
     maxItems: 1
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec  8 08:47:13 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 8 Dec 2023 17:47:13 +0100
Subject: [PATCH v2 4/7] i2c: stm32f7: add support for stm32mp25 soc
In-Reply-To: <20231208164719.3584028-1-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
Message-ID: <20231208164719.3584028-5-alain.volmat@foss.st.com>

The stm32mp25 has only a single interrupt line used for both
events and errors. In order to cope with that, reorganise the
error handling code so that it can be called either from the
common handler (used in case of SoC having only a single IT line)
and the error handler for others.
The CR1 register also embeds a new FMP bit, necessary when running
at Fast Mode Plus frequency. This bit should be used instead of
the SYSCFG bit used on other platforms.
Add a new compatible to distinguish between the SoCs and two
boolean within the setup structure in order to know if the
platform has a single/multiple IT lines and if the FMP bit
within CR1 is available or not.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
Signed-off-by: Valentin Caron <valentin.caron at foss.st.com>
---
 drivers/i2c/busses/i2c-stm32f7.c | 230 ++++++++++++++++++-------------
 1 file changed, 133 insertions(+), 97 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 2a011deec3c5..5634332900fb 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -50,6 +50,7 @@
 #define STM32F7_I2C_TXDR			0x28
 
 /* STM32F7 I2C control 1 */
+#define STM32_I2C_CR1_FMP			BIT(24)
 #define STM32F7_I2C_CR1_PECEN			BIT(23)
 #define STM32F7_I2C_CR1_ALERTEN			BIT(22)
 #define STM32F7_I2C_CR1_SMBHEN			BIT(20)
@@ -226,6 +227,8 @@ struct stm32f7_i2c_spec {
  * @rise_time: Rise time (ns)
  * @fall_time: Fall time (ns)
  * @fmp_clr_offset: Fast Mode Plus clear register offset from set register
+ * @single_it_line: Only a single IT line is used for both events/errors
+ * @fmp_cr1_bit: Fast Mode Plus control is done via a bit in CR1
  */
 struct stm32f7_i2c_setup {
 	u32 speed_freq;
@@ -233,6 +236,8 @@ struct stm32f7_i2c_setup {
 	u32 rise_time;
 	u32 fall_time;
 	u32 fmp_clr_offset;
+	bool single_it_line;
+	bool fmp_cr1_bit;
 };
 
 /**
@@ -418,6 +423,13 @@ static const struct stm32f7_i2c_setup stm32mp13_setup = {
 	.fmp_clr_offset = 0x4,
 };
 
+static const struct stm32f7_i2c_setup stm32mp25_setup = {
+	.rise_time = STM32F7_I2C_RISE_TIME_DEFAULT,
+	.fall_time = STM32F7_I2C_FALL_TIME_DEFAULT,
+	.single_it_line = true,
+	.fmp_cr1_bit = true,
+};
+
 static inline void stm32f7_i2c_set_bits(void __iomem *reg, u32 mask)
 {
 	writel_relaxed(readl_relaxed(reg) | mask, reg);
@@ -1419,15 +1431,13 @@ static bool stm32f7_i2c_is_slave_busy(struct stm32f7_i2c_dev *i2c_dev)
 	return i == busy;
 }
 
-static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev)
+static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev, u32 status)
 {
 	void __iomem *base = i2c_dev->base;
-	u32 cr2, status, mask;
+	u32 cr2, mask;
 	u8 val;
 	int ret;
 
-	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
-
 	/* Slave transmitter mode */
 	if (status & STM32F7_I2C_ISR_TXIS) {
 		i2c_slave_event(i2c_dev->slave_running,
@@ -1494,17 +1504,81 @@ static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t stm32f7_i2c_handle_isr_errs(struct stm32f7_i2c_dev *i2c_dev, u32 status)
+{
+	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
+	u16 addr = f7_msg->addr;
+	void __iomem *base = i2c_dev->base;
+	struct device *dev = i2c_dev->dev;
+	struct stm32_i2c_dma *dma = i2c_dev->dma;
+
+	/* Bus error */
+	if (status & STM32F7_I2C_ISR_BERR) {
+		dev_err(dev, "Bus error accessing addr 0x%x\n", addr);
+		writel_relaxed(STM32F7_I2C_ICR_BERRCF, base + STM32F7_I2C_ICR);
+		stm32f7_i2c_release_bus(&i2c_dev->adap);
+		f7_msg->result = -EIO;
+	}
+
+	/* Arbitration loss */
+	if (status & STM32F7_I2C_ISR_ARLO) {
+		dev_dbg(dev, "Arbitration loss accessing addr 0x%x\n", addr);
+		writel_relaxed(STM32F7_I2C_ICR_ARLOCF, base + STM32F7_I2C_ICR);
+		f7_msg->result = -EAGAIN;
+	}
+
+	if (status & STM32F7_I2C_ISR_PECERR) {
+		dev_err(dev, "PEC error in reception accessing addr 0x%x\n", addr);
+		writel_relaxed(STM32F7_I2C_ICR_PECCF, base + STM32F7_I2C_ICR);
+		f7_msg->result = -EINVAL;
+	}
+
+	if (status & STM32F7_I2C_ISR_ALERT) {
+		dev_dbg(dev, "SMBus alert received\n");
+		writel_relaxed(STM32F7_I2C_ICR_ALERTCF, base + STM32F7_I2C_ICR);
+		i2c_handle_smbus_alert(i2c_dev->alert->ara);
+		return IRQ_HANDLED;
+	}
+
+	if (!i2c_dev->slave_running) {
+		u32 mask;
+		/* Disable interrupts */
+		if (stm32f7_i2c_is_slave_registered(i2c_dev))
+			mask = STM32F7_I2C_XFER_IRQ_MASK;
+		else
+			mask = STM32F7_I2C_ALL_IRQ_MASK;
+		stm32f7_i2c_disable_irq(i2c_dev, mask);
+	}
+
+	/* Disable dma */
+	if (i2c_dev->use_dma) {
+		stm32f7_i2c_disable_dma_req(i2c_dev);
+		dmaengine_terminate_async(dma->chan_using);
+	}
+
+	i2c_dev->master_mode = false;
+	complete(&i2c_dev->complete);
+
+	return IRQ_HANDLED;
+}
+
+#define STM32F7_ERR_EVENTS (STM32F7_I2C_ISR_BERR | STM32F7_I2C_ISR_ARLO |\
+			    STM32F7_I2C_ISR_PECERR | STM32F7_I2C_ISR_ALERT)
 static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
 	u32 status;
 
-	/* Check if the interrupt is for a slave device */
-	if (!i2c_dev->master_mode)
-		return IRQ_WAKE_THREAD;
-
 	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
 
+	/*
+	 * Check if the interrupt is for a slave device or related
+	 * to errors flags (in case of single it line mode)
+	 */
+	if (!i2c_dev->master_mode ||
+	    (i2c_dev->setup.single_it_line && (status & STM32F7_ERR_EVENTS)))
+		return IRQ_WAKE_THREAD;
+
 	/* Tx empty */
 	if (status & STM32F7_I2C_ISR_TXIS)
 		stm32f7_i2c_write_tx_data(i2c_dev);
@@ -1531,10 +1605,14 @@ static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
 	u32 status, mask;
 	int ret;
 
+	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
+
 	if (!i2c_dev->master_mode)
-		return stm32f7_i2c_slave_isr_event(i2c_dev);
+		return stm32f7_i2c_slave_isr_event(i2c_dev, status);
 
-	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
+	/* Handle errors in case of this handler is used for events/errors */
+	if (i2c_dev->setup.single_it_line && (status & STM32F7_ERR_EVENTS))
+		return stm32f7_i2c_handle_isr_errs(i2c_dev, status);
 
 	/* NACK received */
 	if (status & STM32F7_I2C_ISR_NACKF) {
@@ -1601,63 +1679,11 @@ static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
 static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
-	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
-	u16 addr = f7_msg->addr;
-	void __iomem *base = i2c_dev->base;
-	struct device *dev = i2c_dev->dev;
-	struct stm32_i2c_dma *dma = i2c_dev->dma;
 	u32 status;
 
 	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
 
-	/* Bus error */
-	if (status & STM32F7_I2C_ISR_BERR) {
-		dev_err(dev, "Bus error accessing addr 0x%x\n", addr);
-		writel_relaxed(STM32F7_I2C_ICR_BERRCF, base + STM32F7_I2C_ICR);
-		stm32f7_i2c_release_bus(&i2c_dev->adap);
-		f7_msg->result = -EIO;
-	}
-
-	/* Arbitration loss */
-	if (status & STM32F7_I2C_ISR_ARLO) {
-		dev_dbg(dev, "Arbitration loss accessing addr 0x%x\n", addr);
-		writel_relaxed(STM32F7_I2C_ICR_ARLOCF, base + STM32F7_I2C_ICR);
-		f7_msg->result = -EAGAIN;
-	}
-
-	if (status & STM32F7_I2C_ISR_PECERR) {
-		dev_err(dev, "PEC error in reception accessing addr 0x%x\n", addr);
-		writel_relaxed(STM32F7_I2C_ICR_PECCF, base + STM32F7_I2C_ICR);
-		f7_msg->result = -EINVAL;
-	}
-
-	if (status & STM32F7_I2C_ISR_ALERT) {
-		dev_dbg(dev, "SMBus alert received\n");
-		writel_relaxed(STM32F7_I2C_ICR_ALERTCF, base + STM32F7_I2C_ICR);
-		i2c_handle_smbus_alert(i2c_dev->alert->ara);
-		return IRQ_HANDLED;
-	}
-
-	if (!i2c_dev->slave_running) {
-		u32 mask;
-		/* Disable interrupts */
-		if (stm32f7_i2c_is_slave_registered(i2c_dev))
-			mask = STM32F7_I2C_XFER_IRQ_MASK;
-		else
-			mask = STM32F7_I2C_ALL_IRQ_MASK;
-		stm32f7_i2c_disable_irq(i2c_dev, mask);
-	}
-
-	/* Disable dma */
-	if (i2c_dev->use_dma) {
-		stm32f7_i2c_disable_dma_req(i2c_dev);
-		dmaengine_terminate_async(dma->chan_using);
-	}
-
-	i2c_dev->master_mode = false;
-	complete(&i2c_dev->complete);
-
-	return IRQ_HANDLED;
+	return stm32f7_i2c_handle_isr_errs(i2c_dev, status);
 }
 
 static int stm32f7_i2c_wait_polling(struct stm32f7_i2c_dev *i2c_dev)
@@ -1993,23 +2019,27 @@ static int stm32f7_i2c_unreg_slave(struct i2c_client *slave)
 static int stm32f7_i2c_write_fm_plus_bits(struct stm32f7_i2c_dev *i2c_dev,
 					  bool enable)
 {
-	int ret;
+	int ret = 0;
 
 	if (i2c_dev->bus_rate <= I2C_MAX_FAST_MODE_FREQ ||
-	    IS_ERR_OR_NULL(i2c_dev->regmap))
+	    (!i2c_dev->setup.fmp_cr1_bit && IS_ERR_OR_NULL(i2c_dev->regmap)))
 		/* Optional */
 		return 0;
 
-	if (i2c_dev->fmp_sreg == i2c_dev->fmp_creg)
-		ret = regmap_update_bits(i2c_dev->regmap,
-					 i2c_dev->fmp_sreg,
-					 i2c_dev->fmp_mask,
-					 enable ? i2c_dev->fmp_mask : 0);
-	else
-		ret = regmap_write(i2c_dev->regmap,
-				   enable ? i2c_dev->fmp_sreg :
-					    i2c_dev->fmp_creg,
-				   i2c_dev->fmp_mask);
+	if (i2c_dev->setup.fmp_cr1_bit) {
+		if (enable)
+			stm32f7_i2c_set_bits(i2c_dev->base + STM32F7_I2C_CR1, STM32_I2C_CR1_FMP);
+		else
+			stm32f7_i2c_clr_bits(i2c_dev->base + STM32F7_I2C_CR1, STM32_I2C_CR1_FMP);
+	} else {
+		if (i2c_dev->fmp_sreg == i2c_dev->fmp_creg)
+			ret = regmap_update_bits(i2c_dev->regmap, i2c_dev->fmp_sreg,
+						 i2c_dev->fmp_mask, enable ? i2c_dev->fmp_mask : 0);
+		else
+			ret = regmap_write(i2c_dev->regmap,
+					   enable ? i2c_dev->fmp_sreg : i2c_dev->fmp_creg,
+					   i2c_dev->fmp_mask);
+	}
 
 	return ret;
 }
@@ -2143,6 +2173,13 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 	if (!i2c_dev)
 		return -ENOMEM;
 
+	setup = of_device_get_match_data(&pdev->dev);
+	if (!setup) {
+		dev_err(&pdev->dev, "Can't get device data\n");
+		return -ENODEV;
+	}
+	i2c_dev->setup = *setup;
+
 	i2c_dev->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
 	if (IS_ERR(i2c_dev->base))
 		return PTR_ERR(i2c_dev->base);
@@ -2152,10 +2189,6 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 	if (irq_event < 0)
 		return irq_event;
 
-	irq_error = platform_get_irq(pdev, 1);
-	if (irq_error < 0)
-		return irq_error;
-
 	i2c_dev->wakeup_src = of_property_read_bool(pdev->dev.of_node,
 						    "wakeup-source");
 
@@ -2186,23 +2219,22 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	ret = devm_request_threaded_irq(&pdev->dev, irq_error,
-					NULL,
-					stm32f7_i2c_isr_error_thread,
-					IRQF_ONESHOT,
-					pdev->name, i2c_dev);
-	if (ret) {
-		dev_err(&pdev->dev, "Failed to request irq error %i\n",
-			irq_error);
-		return ret;
-	}
+	if (!i2c_dev->setup.single_it_line) {
+		irq_error = platform_get_irq(pdev, 1);
+		if (irq_error < 0)
+			return irq_error;
 
-	setup = of_device_get_match_data(&pdev->dev);
-	if (!setup) {
-		dev_err(&pdev->dev, "Can't get device data\n");
-		return -ENODEV;
+		ret = devm_request_threaded_irq(&pdev->dev, irq_error,
+						NULL,
+						stm32f7_i2c_isr_error_thread,
+						IRQF_ONESHOT,
+						pdev->name, i2c_dev);
+		if (ret) {
+			dev_err(&pdev->dev, "Failed to request irq error %i\n",
+				irq_error);
+			return ret;
+		}
 	}
-	i2c_dev->setup = *setup;
 
 	ret = stm32f7_i2c_setup_timing(i2c_dev, &i2c_dev->setup);
 	if (ret)
@@ -2210,9 +2242,12 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 
 	/* Setup Fast mode plus if necessary */
 	if (i2c_dev->bus_rate > I2C_MAX_FAST_MODE_FREQ) {
-		ret = stm32f7_i2c_setup_fm_plus_bits(pdev, i2c_dev);
-		if (ret)
-			return ret;
+		if (!i2c_dev->setup.fmp_cr1_bit) {
+			ret = stm32f7_i2c_setup_fm_plus_bits(pdev, i2c_dev);
+			if (ret)
+				return ret;
+		}
+
 		ret = stm32f7_i2c_write_fm_plus_bits(i2c_dev, true);
 		if (ret)
 			return ret;
@@ -2491,6 +2526,7 @@ static const struct of_device_id stm32f7_i2c_match[] = {
 	{ .compatible = "st,stm32f7-i2c", .data = &stm32f7_setup},
 	{ .compatible = "st,stm32mp15-i2c", .data = &stm32mp15_setup},
 	{ .compatible = "st,stm32mp13-i2c", .data = &stm32mp13_setup},
+	{ .compatible = "st,stm32mp25-i2c", .data = &stm32mp25_setup},
 	{},
 };
 MODULE_DEVICE_TABLE(of, stm32f7_i2c_match);
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec  8 08:47:14 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 8 Dec 2023 17:47:14 +0100
Subject: [PATCH v2 5/7] arm64: dts: st: add all 8 i2c nodes on stm32mp251
In-Reply-To: <20231208164719.3584028-1-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
Message-ID: <20231208164719.3584028-6-alain.volmat@foss.st.com>

Add the 8 nodes for all i2c instances available on the stm32mp251.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 96 ++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index dfbdb3a773e4..93bc8a8908ce 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -116,6 +116,102 @@ usart2: serial at 400e0000 {
 				status = "disabled";
 			};
 
+			i2c1: i2c at 40120000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40120000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C1>;
+				resets = <&rcc I2C1_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c2: i2c at 40130000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40130000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C2>;
+				resets = <&rcc I2C2_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c3: i2c at 40140000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40140000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C3>;
+				resets = <&rcc I2C3_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c4: i2c at 40150000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40150000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C4>;
+				resets = <&rcc I2C4_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c5: i2c at 40160000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40160000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C5>;
+				resets = <&rcc I2C5_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c6: i2c at 40170000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40170000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C6>;
+				resets = <&rcc I2C6_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c7: i2c at 40180000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40180000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C7>;
+				resets = <&rcc I2C7_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c8: i2c at 46040000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x46040000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C8>;
+				resets = <&rcc I2C8_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
 			sdmmc1: mmc at 48220000 {
 				compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
 				arm,primecell-periphid = <0x00353180>;
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec  8 08:47:15 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 8 Dec 2023 17:47:15 +0100
Subject: [PATCH v2 6/7] arm64: dts: st: add i2c2/i2c8 pins for stm32mp25
In-Reply-To: <20231208164719.3584028-1-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
Message-ID: <20231208164719.3584028-7-alain.volmat@foss.st.com>

Add the i2c2 and i2c8 pins used on STM32MP257F-EV1 board.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 36 +++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 66791a974f8f..4194807606ce 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -6,6 +6,23 @@
 #include <dt-bindings/pinctrl/stm32-pinfunc.h>
 
 &pinctrl {
+	i2c2_pins_a: i2c2-0 {
+		pins {
+			pinmux = <STM32_PINMUX('B', 5, AF9)>, /* I2C2_SCL */
+				 <STM32_PINMUX('B', 4, AF9)>; /* I2C2_SDA */
+			bias-disable;
+			drive-open-drain;
+			slew-rate = <0>;
+		};
+	};
+
+	i2c2_sleep_pins_a: i2c2-sleep-0 {
+		pins {
+			pinmux = <STM32_PINMUX('B', 5, ANALOG)>, /* I2C2_SCL */
+				 <STM32_PINMUX('B', 4, ANALOG)>; /* I2C2_SDA */
+		};
+	};
+
 	sdmmc1_b4_pins_a: sdmmc1-b4-0 {
 		pins1 {
 			pinmux = <STM32_PINMUX('E', 4, AF10)>, /* SDMMC1_D0 */
@@ -90,3 +107,22 @@ pins {
 		};
 	};
 };
+
+&pinctrl_z {
+	i2c8_pins_a: i2c8-0 {
+		pins {
+			pinmux = <STM32_PINMUX('Z', 4, AF8)>, /* I2C8_SCL */
+				 <STM32_PINMUX('Z', 3, AF8)>; /* I2C8_SDA */
+			bias-disable;
+			drive-open-drain;
+			slew-rate = <0>;
+		};
+	};
+
+	i2c8_sleep_pins_a: i2c8-sleep-0 {
+		pins {
+			pinmux = <STM32_PINMUX('Z', 4, ANALOG)>, /* I2C8_SCL */
+				 <STM32_PINMUX('Z', 3, ANALOG)>; /* I2C8_SDA */
+		};
+	};
+};
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec  8 08:47:16 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 8 Dec 2023 17:47:16 +0100
Subject: [PATCH v2 7/7] arm64: dts: st: add i2c2 / i2c8 properties on stm32mp257f-ev1
In-Reply-To: <20231208164719.3584028-1-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
Message-ID: <20231208164719.3584028-8-alain.volmat@foss.st.com>

Add properties for i2c2 and i2c8 available on the stm32mp257f-ev1.
i2c2 is enabled since several devices are attached to it while
i2c8 is kept disabled since only used via the gpio expansion connector.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index b2d3afb15758..0ea8e69bfb3d 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -55,6 +55,26 @@ &arm_wdt {
 	status = "okay";
 };
 
+&i2c2 {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&i2c2_pins_a>;
+	pinctrl-1 = <&i2c2_sleep_pins_a>;
+	i2c-scl-rising-time-ns = <100>;
+	i2c-scl-falling-time-ns = <13>;
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&i2c8 {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&i2c8_pins_a>;
+	pinctrl-1 = <&i2c8_sleep_pins_a>;
+	i2c-scl-rising-time-ns = <57>;
+	i2c-scl-falling-time-ns = <7>;
+	clock-frequency = <400000>;
+	status = "disabled";
+};
+
 &sdmmc1 {
 	pinctrl-names = "default", "opendrain", "sleep";
 	pinctrl-0 = <&sdmmc1_b4_pins_a>;
-- 
2.25.1



From ahalaney at redhat.com  Fri Dec  8 08:50:29 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Fri, 8 Dec 2023 10:50:29 -0600
Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <hgz3pt625kggix6kzincohw7kr2okcumrwfkmjgiauw2yvhrzt@ekeygo4b7k3b>
References: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>
 <jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz@ntepnnzzelta>
 <hxds75erxqcfkufxnfbyo2up4b4jeicmi3f5xr6qlb3yf7fe76@4byeq62jhu4o>
 <hgz3pt625kggix6kzincohw7kr2okcumrwfkmjgiauw2yvhrzt@ekeygo4b7k3b>
Message-ID: <h5ucipgjtsesrz3jyul5xohu4pqom56v6ayx7aonnfesret3ht@wmblmndj6zir>

On Fri, Dec 08, 2023 at 06:07:06PM +0300, Serge Semin wrote:
> On Thu, Dec 07, 2023 at 05:07:24PM -0600, Andrew Halaney wrote:
> > On Fri, Dec 08, 2023 at 01:16:12AM +0300, Serge Semin wrote:
> > > On Thu, Dec 07, 2023 at 03:12:40PM -0600, Andrew Halaney wrote:
> > > > The stmmac_dt_phy() function, which parses the devicetree node of the
> > > > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > > > fixed-link means in relation to the MAC's MDIO bus. This results in
> > > > a MDIO bus being created in situations it need not be.
> > > > 
> > > > Currently a MDIO bus is created if the description is either:
> > > > 
> > > >     1. Not fixed-link
> > > >     2. fixed-link but contains a MDIO bus as well
> > > > 
> > > > The "1" case above isn't always accurate. If there's a phy-handle,
> > > > it could be referencing a phy on another MDIO controller's bus[1]. In
> > > > this case currently the MAC will make a MDIO bus and scan it all
> > > > anyways unnecessarily.
> > > > 
> > > > There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> > > > be created and scanned for a phy. This case can also be inferred from
> > > > the platform description by not having a phy-handle && not being
> > > > fixed-link. This hits case "1" in the current driver's logic.
> > > > 
> > > > Let's improve the logic to create a MDIO bus if either:
> > > > 
> > > 
> > > >     - Devicetree contains a MDIO bus
> > > >     - !fixed-link && !phy-handle (legacy handling)
> > > 
> > > If what you suggest here is a free from regressions semantics change
> > > (really hope it is) I will be with both my hands for it. This will
> > > solve the problem we have with one of our device which doesn't have
> > > SMA interface (hardware designers decided to save ~4K gates of the
> > > chip area) but has a PHY externally attached to the DW XGMAC<->XPCS
> > > interface. PHY is accessible via a GPIO-based MDIO bus. BTW having no
> > > SMA interface available on a DW *MAC device but creating the MDIO-bus
> > > on top of the non-existent SMA CSRs anyway causes having _32_ dummy
> > > PHYs created with zero IDs.
> > 
> 
> > I hope it is regression free! I have tested both the [1] and [2] cases
> > (I hacked up the devicetree for [1] to make it look like [2]) without
> > any issue.
> > 
> 
> I doubt you could have tested it on all the possible hardware the
> STMMAC driver supports. The problem is that the DT-bindings thing is a
> kind of contract which can't be changed that easily. It's like ABI but
> for the hardware description so the kernel would bootup correctly on
> the platforms with the old DT blobs. But if the change isn't that
> critical, if the device-tree sources in the kernel fit to the updated
> semantics, if the networking subsystem maintainers aren't against it
> and I guess with the Rob, Krzysztof or Conor blessing (at least it
> won't hurt to add them to the Cc-list together with the devicetree
> mailing-list), then it will likely be accepted.

To be clear, I don't think we're violating the dt-binding ABI contract
here. My intention is that all the existing use cases continue to work,
and this just improves one use case. I did a write up
over on v2 about the use cases I see and the current logic vs what
changes with this patch series:

    https://lore.kernel.org/netdev/plvbqgi2bwlv5quvpiwplq7cxx6m5rl3ghnfhuxfx4bpuhyihl at zmydwrtwdeg6/

Please comment if you think I have broken some backwards
compatibility. If I _could_ break compatibility, I'd make everyone
describe their busses entirely... but as you said that's against the
spirit of dt-bindings and would upset a lot of people. That's why I've
left the "!fixed-link && !phy-handle (legacy handling) logic :)

> 
> > Sorry, I don't have any docs for stmmac hardware so this might be
> > answered in there (or just common net knowledge that I can't find
> > online)... what's SMA stand for? I assume it's the MDIO interface.
> 
> Right. Synopsys names the MDIO-bus interface as Station Management
> Agent MDIO module.
> 
> > 
> > I agree though, if you have a phy-handle and no mdio node in your
> > devicetree this patch series should bail out without registering a bus
> > in stmmac_mdio_register().
> 
> On the other hand why would the MDIO-bus needed in such case? If the
> phy-handle property is specified with no MDIO-bus DT-subnode, then it
> will point out to a PHY residing an external bus. The only case I can
> imagine though is that the DW XPCS device could be still auto-detected
> on the internal SMA-MDIO-bus. But the only driver which currently has
> XPCS auto-detection activated is the Intel glue layer (see
> dwmac-intel.c and has_xpcs flag), but it doesn't use DT interface
> since it handles a PCIe-based device.  So this case is out of
> brackets.

Agreed, I think making the bus is not needed in the driver as is in that
case.

I'd like to think (but am not sure) that when a devicetree based DW XPCS
description comes around it will allow you to describe it exactly
instead of doing auto-detection (i.e. something like phy-handle), but I
am not very familiar with PCS and friends in the stack so that may be a
crude extension from my knowledge of MDIO.

Thanks,
Andrew

> 
> > 
> > > 
> > > > 
> > > > Below upstream devicetree snippets can be found that explain some of
> > > > the cases above more concretely.
> > 
> > <snip>
> > 
> > > > -	if (mdio) {
> > > > -		plat->mdio_bus_data =
> > > > -			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
> > > > -				     GFP_KERNEL);
> > > 
> > > > +	/* Legacy devicetrees allowed for no MDIO bus description and expect
> > > > +	 * the bus to be scanned for devices. If there's no phy or fixed-link
> > > > +	 * described assume this is the case since there must be something
> > > > +	 * connected to the MAC.
> > > > +	 */
> > > > +	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
> > > > +	if (legacy_mdio)
> > > > +		dev_info(dev, "Deprecated MDIO bus assumption used\n");
> > > > +
> > > > +	if (plat->mdio_node || legacy_mdio) {
> > > > +		plat->mdio_bus_data = devm_kzalloc(dev,
> > > 
> > > Special thanks for adding the comment above this code. It will really
> > > save time of figuring out why MDIO-bus needs to be created anyway.
> > > 
> > > > +						   sizeof(struct stmmac_mdio_bus_data),
> > > 
> > > Should v4 is required I would suggest to change this to
> > > sizeof(*plat->mdio_bus_data).
> > > 
> > > Anyway feel free to add:
> > > Reviewed-by: Serge Semin <fancer.lancer at gmail.com>
> > > 
> > > -Serge(y)
> > 
> 
> > Sure I will spin v4 to pick that up, thanks for catching it. I'll also
> > improve the motivation in the commit message a hair more per Andrew
> > Lunn's request over here on v2 (and will hold off a little bit just to
> > make sure reviews come in before a respin):
> > 
> >     https://lore.kernel.org/netdev/e64b14c3-4b80-4120-8cc4-9baa40cdcb75 at lunn.ch/
> 
> Ok. Thanks.
> 
> -Serge(y)
> 
> > 
> > Thanks,
> > Andrew
> > 
> 



From horms at kernel.org  Fri Dec  8 08:58:55 2023
From: horms at kernel.org (Simon Horman)
Date: Fri, 8 Dec 2023 16:58:55 +0000
Subject: [PATCH v2 3/4] drm/stm: dsi: expose DSI PHY internal clock
In-Reply-To: <20231204101113.276368-4-raphael.gallais-pou@foss.st.com>
References: <20231204101113.276368-1-raphael.gallais-pou@foss.st.com>
 <20231204101113.276368-4-raphael.gallais-pou@foss.st.com>
Message-ID: <20231208165855.GA8459@kernel.org>

On Mon, Dec 04, 2023 at 11:11:12AM +0100, Raphael Gallais-Pou wrote:

...

> @@ -514,18 +675,40 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
>  		dsi->lane_max_kbps *= 2;
>  	}
>  
> -	dw_mipi_dsi_stm_plat_data.base = dsi->base;
> -	dw_mipi_dsi_stm_plat_data.priv_data = dsi;
> +	dsi->pdata = *pdata;
> +	dsi->pdata.base = dsi->base;
> +	dsi->pdata.priv_data = dsi;
> +
> +	dsi->pdata.max_data_lanes = 2;
> +	dsi->pdata.phy_ops = &dw_mipi_dsi_stm_phy_ops;
>  
>  	platform_set_drvdata(pdev, dsi);
>  
> -	dsi->dsi = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
> +	dsi->dsi = dw_mipi_dsi_probe(pdev, &dsi->pdata);
>  	if (IS_ERR(dsi->dsi)) {
>  		ret = PTR_ERR(dsi->dsi);
>  		dev_err_probe(dev, ret, "Failed to initialize mipi dsi host\n");
>  		goto err_dsi_probe;
>  	}
>  
> +	/*
> +	 * We need to wait for the generic bridge to probe before enabling and
> +	 * register the internal pixel clock.
> +	 */
> +	ret = clk_prepare_enable(dsi->pclk);
> +	if (ret) {
> +		DRM_ERROR("%s: Failed to enable peripheral clk\n", __func__);
> +		goto err_dsi_probe;
> +	}
> +
> +	ret = dw_mipi_dsi_clk_register(dsi, dev);
> +	if (ret) {
> +		DRM_ERROR("Failed to register DSI pixel clock: %d\n", ret);

Hi Raphael,

Does clk_disable_unprepare(dsi->pclk) need to be added to this unwind
chain?

Flagged by Smatch.

> +		goto err_dsi_probe;
> +	}
> +
> +	clk_disable_unprepare(dsi->pclk);
> +
>  	return 0;
>  
>  err_dsi_probe:

...


From sean at mess.org  Fri Dec  8 09:01:26 2023
From: sean at mess.org (Sean Young)
Date: Fri, 8 Dec 2023 17:01:26 +0000
Subject: [PATCH v6 3/4] pwm: bcm2835: allow pwm driver to be used in
 atomic context
In-Reply-To: <ZXNC3JYy7CTfYsyC@orome.fritz.box>
References: <cover.1701248996.git.sean@mess.org>
 <179dc1ce85702a8b64b43c0e0df656b0c5e3ce30.1701248996.git.sean@mess.org>
 <ZXNC3JYy7CTfYsyC@orome.fritz.box>
Message-ID: <ZXNL5upeUPc4gC1R@gofer.mess.org>

On Fri, Dec 08, 2023 at 05:22:52PM +0100, Thierry Reding wrote:
> On Wed, Nov 29, 2023 at 09:13:36AM +0000, Sean Young wrote:
> > clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
> > rate changes using clk_rate_exclusive_get().
> > 
> > Signed-off-by: Sean Young <sean at mess.org>
> > ---
> >  drivers/pwm/pwm-bcm2835.c | 31 +++++++++++++++++++++----------
> >  1 file changed, 21 insertions(+), 10 deletions(-)
> 
> s/pwm/PWM/ in the subject. Although, I guess you could just drop the
> "PWM" altogether because the subject prefix implies that this is for
> PWM.

$ git log --no-merges --oneline drivers/pwm/ | sed -r 's/^\w* ([^:]+): .*/\1/' | sort | uniq -c
   1197 pwm
      1 PWM
  ...

The vast majority of the commits use pwm: as a prefix, only one uses PWM:. 
In fact if you look across the tree almost everywhere lower case is used
for the prefix.

I'm just trying to follow convention.

Having said that, I think the prefix is totally redundant, it is clear from
the commit files what they are affecting. I am not sure what it really adds.

> Also, please capitalize after the subject prefix.

$ git log --no-merges --oneline drivers/pwm/ | grep -E '^\w* ([^:]+): [A-Z]' | wc -l
217
$ git log --no-merges --oneline drivers/pwm/ | grep -E '^\w* ([^:]+): [a-z]' | wc -l
1069

Although not as clear, convention seems to be lower case for commits. The
first line of a commit is not really a sentence, there is no trailing
period.

I am happy to oblige, just wanted to point this out. Sorry if this starts
a bikeshed discussion.

Thanks,

Sean


From Ryan.Wanner at microchip.com  Fri Dec  8 09:02:30 2023
From: Ryan.Wanner at microchip.com (Ryan.Wanner at microchip.com)
Date: Fri, 8 Dec 2023 10:02:30 -0700
Subject: [PATCH] drivers: soc: atmel: Adjust defines to follow alphabetical order
Message-ID: <20231208170230.551265-1-Ryan.Wanner@microchip.com>

From: Ryan Wanner <Ryan.Wanner at microchip.com>

Move the defines so that they are in aphabetical order based on SOC.

Signed-off-by: Ryan Wanner <Ryan.Wanner at microchip.com>
---
 drivers/soc/atmel/soc.h | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/soc/atmel/soc.h b/drivers/soc/atmel/soc.h
index 26dd26b4f179..9b2d31073b88 100644
--- a/drivers/soc/atmel/soc.h
+++ b/drivers/soc/atmel/soc.h
@@ -39,13 +39,13 @@ at91_soc_init(const struct at91_soc *socs);
 #define AT91SAM9261_CIDR_MATCH		0x019703a0
 #define AT91SAM9263_CIDR_MATCH		0x019607a0
 #define AT91SAM9G20_CIDR_MATCH		0x019905a0
-#define AT91SAM9RL64_CIDR_MATCH		0x019b03a0
 #define AT91SAM9G45_CIDR_MATCH		0x019b05a0
-#define AT91SAM9X5_CIDR_MATCH		0x019a05a0
 #define AT91SAM9N12_CIDR_MATCH		0x019a07a0
+#define AT91SAM9RL64_CIDR_MATCH		0x019b03a0
+#define AT91SAM9X5_CIDR_MATCH		0x019a05a0
 #define SAM9X60_CIDR_MATCH		0x019b35a0
-#define SAMA7G5_CIDR_MATCH		0x00162100
 #define SAM9X7_CIDR_MATCH		0x09750020
+#define SAMA7G5_CIDR_MATCH		0x00162100
 
 #define AT91SAM9M11_EXID_MATCH		0x00000001
 #define AT91SAM9M10_EXID_MATCH		0x00000002
@@ -62,19 +62,15 @@ at91_soc_init(const struct at91_soc *socs);
 #define AT91SAM9N12_EXID_MATCH		0x00000006
 #define AT91SAM9CN11_EXID_MATCH		0x00000009
 
+#define AT91SAM9XE128_CIDR_MATCH	0x329973a0
+#define AT91SAM9XE256_CIDR_MATCH	0x329a93a0
+#define AT91SAM9XE512_CIDR_MATCH	0x329aa3a0
+
 #define SAM9X60_EXID_MATCH		0x00000000
 #define SAM9X60_D5M_EXID_MATCH		0x00000001
 #define SAM9X60_D1G_EXID_MATCH		0x00000010
 #define SAM9X60_D6K_EXID_MATCH		0x00000011
 
-#define SAMA7G51_EXID_MATCH		0x3
-#define SAMA7G52_EXID_MATCH		0x2
-#define SAMA7G53_EXID_MATCH		0x1
-#define SAMA7G54_EXID_MATCH		0x0
-#define SAMA7G54_D1G_EXID_MATCH		0x00000018
-#define SAMA7G54_D2G_EXID_MATCH		0x00000020
-#define SAMA7G54_D4G_EXID_MATCH		0x00000028
-
 #define SAM9X75_EXID_MATCH		0x00000000
 #define SAM9X72_EXID_MATCH		0x00000004
 #define SAM9X70_EXID_MATCH		0x00000005
@@ -83,10 +79,6 @@ at91_soc_init(const struct at91_soc *socs);
 #define SAM9X75_D1M_EXID_MATCH		0x00000003
 #define SAM9X75_D2G_EXID_MATCH		0x00000006
 
-#define AT91SAM9XE128_CIDR_MATCH	0x329973a0
-#define AT91SAM9XE256_CIDR_MATCH	0x329a93a0
-#define AT91SAM9XE512_CIDR_MATCH	0x329aa3a0
-
 #define SAMA5D2_CIDR_MATCH		0x0a5c08c0
 #define SAMA5D21CU_EXID_MATCH		0x0000005a
 #define SAMA5D225C_D1M_EXID_MATCH	0x00000053
@@ -122,6 +114,14 @@ at91_soc_init(const struct at91_soc *socs);
 #define SAMA5D43_EXID_MATCH		0x00000003
 #define SAMA5D44_EXID_MATCH		0x00000004
 
+#define SAMA7G51_EXID_MATCH		0x3
+#define SAMA7G52_EXID_MATCH		0x2
+#define SAMA7G53_EXID_MATCH		0x1
+#define SAMA7G54_EXID_MATCH		0x0
+#define SAMA7G54_D1G_EXID_MATCH		0x00000018
+#define SAMA7G54_D2G_EXID_MATCH		0x00000020
+#define SAMA7G54_D4G_EXID_MATCH		0x00000028
+
 #define SAME70Q21_CIDR_MATCH		0x21020e00
 #define SAME70Q21_EXID_MATCH		0x00000002
 #define SAME70Q20_CIDR_MATCH		0x21020c00
-- 
2.39.2



From amit.kumar-mahapatra at amd.com  Fri Dec  8 09:05:34 2023
From: amit.kumar-mahapatra at amd.com (Mahapatra, Amit Kumar)
Date: Fri, 8 Dec 2023 17:05:34 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
Message-ID: <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>

Hello Tudor,

> -----Original Message-----
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> Sent: Wednesday, December 6, 2023 8:00 PM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> michael at walle.cc; linux-mtd at lists.infradead.org;
> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
> in spi-nor
> 
> Hi, Amit,
> 
> On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
> > Each flash that is connected in stacked mode should have a separate
> > parameter structure. So, the flash parameter member(*params) of the
> > spi_nor structure is changed to an array (*params[2]). The array is
> > used to store the parameters of each flash connected in stacked
> configuration.
> >
> > The current implementation assumes that a maximum of two flashes are
> > connected in stacked mode and both the flashes are of same make but
> > can differ in sizes. So, except the sizes all other flash parameters
> > of both the flashes are identical.
> 
> Do you plan to add support for different flashes in stacked mode? If not,

No, according to the current implementation, in stacked mode, both flashes 
must be of the same make.

> wouldn't it be simpler to have just an array of flash sizes instead of
> duplicating the entire params struct?

Yes, that is accurate. In alignment with our current stacked support use case we 
can have an array of flash sizes instead.
The primary purpose of having an array of params struct was to facilitate 
potential future extensions, allowing the addition of stacked support for 
different flashes

> 
> >
> > SPI-NOR is not aware of the chip_select values, for any incoming
> > request SPI-NOR will decide the flash index with the help of
> > individual flash size and the configuration type (single/stacked).
> > SPI-NOR will pass on the flash index information to the SPI core & SPI
> > driver by setting the appropriate bit in
> > nor->spimem->spi->cs_index_mask. For example, if nth bit of
> > nor->spimem->spi->cs_index_mask is set then the driver would
> > assert/de-assert spi->chip_slect[n].
> >
> > Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at amd.com>
> > ---
> >  drivers/mtd/spi-nor/core.c  | 272 +++++++++++++++++++++++++++++-------
> >  drivers/mtd/spi-nor/core.h  |   4 +
> >  include/linux/mtd/spi-nor.h |  15 +-
> >  3 files changed, 240 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > index 93ae69b7ff83..e990be7c7eb6 100644
> > --- a/drivers/mtd/spi-nor/core.c
> > +++ b/drivers/mtd/spi-nor/core.c
> 
> cut
> 
> > @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct
> > spi_nor *nor)  static int spi_nor_late_init_params(struct spi_nor
> > *nor)  {
> >  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
> 0);
> > -	int ret;
> > +	struct device_node *np = spi_nor_get_flash_node(nor);
> > +	u64 flash_size[SNOR_FLASH_CNT_MAX];
> > +	u32 idx = 0;
> > +	int rc, ret;
> >
> >  	if (nor->manufacturer && nor->manufacturer->fixups &&
> >  	    nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
> > static int spi_nor_late_init_params(struct spi_nor *nor)
> >  	if (params->n_banks > 1)
> >  		params->bank_size = div64_u64(params->size, params-
> >n_banks);
> >
> > +	nor->num_flash = 0;
> > +
> > +	/*
> > +	 * The flashes that are connected in stacked mode should be of same
> make.
> > +	 * Except the flash size all other properties are identical for all the
> > +	 * flashes connected in stacked mode.
> > +	 * The flashes that are connected in parallel mode should be identical.
> > +	 */
> > +	while (idx < SNOR_FLASH_CNT_MAX) {
> > +		rc = of_property_read_u64_index(np, "stacked-memories",
> idx,
> > +&flash_size[idx]);
> 
> This is a little late in my opinion, as we don't have any sanity check on the
> flashes that are stacked on top of the first. We shall at least read and compare
> the ID for all.

Alright, I will incorporate a sanity check for reading and comparing the 
ID of the stacked flash. Subsequently, I believe this stacked logic 
should be relocated to spi_nor_get_flash_info() where we identify the 
first flash. Please share your thoughts on this. Additionally, do you 
anticipate that SPI-NOR should throw an error if the second or any 
subsequent flash within the stacked connection is different? Or would you 
prefer it to print a warning and operate in single mode (i.e., only the 
first flash)?

Regards,
Amit
> 
> Cheers,
> ta

From amit.kumar-mahapatra at amd.com  Fri Dec  8 09:06:24 2023
From: amit.kumar-mahapatra at amd.com (Mahapatra, Amit Kumar)
Date: Fri, 8 Dec 2023 17:06:24 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <9f577482-30d9-4e1d-9469-812d323b18c6@linaro.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <9f577482-30d9-4e1d-9469-812d323b18c6@linaro.org>
Message-ID: <BN7PR12MB2802C8279CA95FA08F8DDCF2DC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>

Hello Tudor,

> -----Original Message-----
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> Sent: Wednesday, December 6, 2023 8:14 PM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> michael at walle.cc; linux-mtd at lists.infradead.org;
> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
> in spi-nor
> 
> 
> 
> On 12/6/23 14:30, Tudor Ambarus wrote:
> > Hi, Amit,
> >
> > On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
> >> Each flash that is connected in stacked mode should have a separate
> >> parameter structure. So, the flash parameter member(*params) of the
> >> spi_nor structure is changed to an array (*params[2]). The array is
> >> used to store the parameters of each flash connected in stacked
> configuration.
> >>
> >> The current implementation assumes that a maximum of two flashes are
> >> connected in stacked mode and both the flashes are of same make but
> >> can differ in sizes. So, except the sizes all other flash parameters
> >> of both the flashes are identical.
> >
> > Do you plan to add support for different flashes in stacked mode? If
> > not, wouldn't it be simpler to have just an array of flash sizes
> > instead of duplicating the entire params struct?
> >
> >>
> >> SPI-NOR is not aware of the chip_select values, for any incoming
> >> request SPI-NOR will decide the flash index with the help of
> >> individual flash size and the configuration type (single/stacked).
> >> SPI-NOR will pass on the flash index information to the SPI core &
> >> SPI driver by setting the appropriate bit in
> >> nor->spimem->spi->cs_index_mask. For example, if nth bit of
> >> nor->spimem->spi->cs_index_mask is set then the driver would
> >> assert/de-assert spi->chip_slect[n].
> >>
> >> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
> mahapatra at amd.com>
> >> ---
> >>  drivers/mtd/spi-nor/core.c  | 272 +++++++++++++++++++++++++++++-------
> >>  drivers/mtd/spi-nor/core.h  |   4 +
> >>  include/linux/mtd/spi-nor.h |  15 +-
> >>  3 files changed, 240 insertions(+), 51 deletions(-)
> >>
> >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> >> index 93ae69b7ff83..e990be7c7eb6 100644
> >> --- a/drivers/mtd/spi-nor/core.c
> >> +++ b/drivers/mtd/spi-nor/core.c
> >
> > cut
> >
> >> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct
> >> spi_nor *nor)  static int spi_nor_late_init_params(struct spi_nor
> >> *nor)  {
> >>  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
> 0);
> >> -	int ret;
> >> +	struct device_node *np = spi_nor_get_flash_node(nor);
> >> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
> >> +	u32 idx = 0;
> >> +	int rc, ret;
> >>
> >>  	if (nor->manufacturer && nor->manufacturer->fixups &&
> >>  	    nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
> >> static int spi_nor_late_init_params(struct spi_nor *nor)
> >>  	if (params->n_banks > 1)
> >>  		params->bank_size = div64_u64(params->size, params-
> >n_banks);
> >>
> >> +	nor->num_flash = 0;
> >> +
> >> +	/*
> >> +	 * The flashes that are connected in stacked mode should be of same
> make.
> >> +	 * Except the flash size all other properties are identical for all the
> >> +	 * flashes connected in stacked mode.
> >> +	 * The flashes that are connected in parallel mode should be identical.
> >> +	 */
> >> +	while (idx < SNOR_FLASH_CNT_MAX) {
> >> +		rc = of_property_read_u64_index(np, "stacked-memories",
> idx,
> >> +&flash_size[idx]);
> 
> also, it's not clear to me why you read this property multiple times.
> Have you sent a device tree patch somewhere? It will help me understand
> what you're trying to achieve.

Miquel submitted the device tree patch; here is the series.
https://lore.kernel.org/all/20220126112608.955728-1-miquel.raynal at bootlin.com/

Regards,
Amit
> 
> >
> > This is a little late in my opinion, as we don't have any sanity check
> > on the flashes that are stacked on top of the first. We shall at least
> > read and compare the ID for all.
> >
> > Cheers,
> > ta

From pr-tracker-bot at kernel.org  Fri Dec  8 09:08:34 2023
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Fri, 08 Dec 2023 17:08:34 +0000
Subject: [GIT PULL] ARM: SoC fixes for v6.7
In-Reply-To: <90aa3b5f-a0d4-4609-85c2-e3d4cc944102@app.fastmail.com>
References: <90aa3b5f-a0d4-4609-85c2-e3d4cc944102@app.fastmail.com>
Message-ID: <170205531495.9242.2736142793084399675.pr-tracker-bot@kernel.org>

The pull request you sent on Fri, 08 Dec 2023 14:59:56 +0100:

> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-fixes-6.7-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a6adef898741eb07526aaf9d8b982d3dff4a9e67

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From khilman at kernel.org  Fri Dec  8 09:13:43 2023
From: khilman at kernel.org (Kevin Hilman)
Date: Fri, 08 Dec 2023 09:13:43 -0800
Subject: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure
 ti-sysc for wkup_uart0
In-Reply-To: <20231207060854.GQ5169@atomide.com>
References: <20231114073209.40756-1-tony@atomide.com>
 <7h5y1c7c0q.fsf@baylibre.com> <20231207060854.GQ5169@atomide.com>
Message-ID: <7hedfwd3co.fsf@baylibre.com>

Tony Lindgren <tony at atomide.com> writes:

> * Kevin Hilman <khilman at kernel.org> [231205 18:14]:
>> I'm a little confused why these power-domain and clocks stay here and
>> are not moved under the wkup_uart0 node... 
>
> The resources are also needed by the interconnect target module. It's the
> wrapper IP for the child device(s). In this case there's one chip 8250 IP
> instance. In some other devices there can be multiple child IP devices
> wired to one target module.
>
>> > -		clock-names = "fclk";
>> > -		status = "disabled";
>> > +		clock-names = "fck";
>> > +		#address-cells = <1>;
>> > +		#size-cells = <1>;
>> > +		ranges = <0 0 0x2b300000 0x100000>;
>> > +
>> > +		wkup_uart0: serial at 2b300000 {
>> > +			compatible = "ti,am64-uart", "ti,am654-uart";
>> > +			reg = <0 0x100>;
>> > +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
>> > +			status = "disabled";
>> 
>> ...here.
>> 
>> The SCI device ID 114 is specifically for wkup_uart0[1], so it seems to
>> me those should be in the wkup_uart0 node.
>
> Those resources are also needed for the parent target module for revision
> detection, quirks, reset, idle register configuration, and to probe the
> child devices.
>
> Here the 8250 IP can be set to status = "reserved" when used by the
> firmware, and 8250 not touched by Linux. However, the parent interconnect
> target module still needs to be configured for idle registers and wake-up
> path register bit so the wake-up from deeper suspend states works.

OK, makes sense.  Thanks for the clarification.

In that case, shouldn't the same be done for the other wakeup sources
there (e.g. wkup_rtc0) ?

Kevin



From u.kleine-koenig at pengutronix.de  Fri Dec  8 09:20:40 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 8 Dec 2023 18:20:40 +0100
Subject: [PATCH v6 3/4] pwm: bcm2835: allow pwm driver to be used in
 atomic context
In-Reply-To: <ZXNL5upeUPc4gC1R@gofer.mess.org>
References: <cover.1701248996.git.sean@mess.org>
 <179dc1ce85702a8b64b43c0e0df656b0c5e3ce30.1701248996.git.sean@mess.org>
 <ZXNC3JYy7CTfYsyC@orome.fritz.box>
 <ZXNL5upeUPc4gC1R@gofer.mess.org>
Message-ID: <20231208172040.mgw7aicmwlw6yjyb@pengutronix.de>

On Fri, Dec 08, 2023 at 05:01:26PM +0000, Sean Young wrote:
> On Fri, Dec 08, 2023 at 05:22:52PM +0100, Thierry Reding wrote:
> > On Wed, Nov 29, 2023 at 09:13:36AM +0000, Sean Young wrote:
> > > clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
> > > rate changes using clk_rate_exclusive_get().
> > > 
> > > Signed-off-by: Sean Young <sean at mess.org>
> > > ---
> > >  drivers/pwm/pwm-bcm2835.c | 31 +++++++++++++++++++++----------
> > >  1 file changed, 21 insertions(+), 10 deletions(-)
> > 
> > s/pwm/PWM/ in the subject. Although, I guess you could just drop the
> > "PWM" altogether because the subject prefix implies that this is for
> > PWM.
> 
> $ git log --no-merges --oneline drivers/pwm/ | sed -r 's/^\w* ([^:]+): .*/\1/' | sort | uniq -c
>    1197 pwm
>       1 PWM
>   ...
> 
> The vast majority of the commits use pwm: as a prefix, only one uses PWM:. 
> In fact if you look across the tree almost everywhere lower case is used
> for the prefix.

Thierry doesn't want you to change the subject prefix, but only the
second "pwm" to make it read:

	pwm: bcm2835: allow PWM driver to be used in atomic context

While I understand Thierry here, I'm fine with a lowercase pwm here,
too. In my book a PWM in all uppercase is the type of hardware and pwm
in all lowercase is the framework's name. If you use "PWM driver" or
"pwm driver" then doesn't matter much.

	
> 
> I'm just trying to follow convention.
> 
> Having said that, I think the prefix is totally redundant, it is clear from
> the commit files what they are affecting. I am not sure what it really adds.
> 
> > Also, please capitalize after the subject prefix.
> 
> $ git log --no-merges --oneline drivers/pwm/ | grep -E '^\w* ([^:]+): [A-Z]' | wc -l
> 217
> $ git log --no-merges --oneline drivers/pwm/ | grep -E '^\w* ([^:]+): [a-z]' | wc -l
> 1069

Your matching things like:

	pwm: pwm-tiehrpwm: Add support for configuring polarity of PWM

with the second command. These are perfectly fine as pwm-tiehrpwm is the
driver name and so shouldn't be capitalized. With a bit more care here,
we get:

	$ git log --no-merges --oneline drivers/pwm/ | grep -E '^.+: [a-z][^:]*$' | wc -l
	114
	$ git log --no-merges --oneline drivers/pwm/ | grep -E '^.+: [A-Z][^:]*$' | wc -l
	1167

And the newest of the 114 with a small letter is from 2013.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/aceddde8/attachment-0001.sig>

From adrian.hunter at intel.com  Fri Dec  8 09:24:45 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri,  8 Dec 2023 19:24:45 +0200
Subject: [PATCH RFC V2 0/4] perf/core: Add ability for an event to "pause" or "resume" AUX area tracing
Message-ID: <20231208172449.35444-1-adrian.hunter@intel.com>

Hi

Hardware traces, such as instruction traces, can produce a vast amount of
trace data, so being able to reduce tracing to more specific circumstances
can be useful.

The ability to pause or resume tracing when another event happens, can do
that.

These patches add such a facilty and show how it would work for Intel
Processor Trace.

Maintainers of other AUX area tracing implementations are requested to
consider if this is something they might employ and then whether or not
the ABI would work for them.

Changes to perf tools are not fleshed out yet.


Changes in RFC V2:

      Use ->stop() / ->start() instead of ->pause_resume()
      Move aux_start_paused bit into aux_output_cfg
      Tighten up when Intel PT pause / resume is allowed
      Add an example of how it might work for CoreSight


Adrian Hunter (4):
      perf/core: Add aux_pause, aux_resume, aux_start_paused
      perf/x86/intel/pt: Add support for pause / resume
      perf tools: Add support for AUX area pause / resume
      coresight: Have a stab at support for pause / resume

 arch/x86/events/intel/pt.c                       | 63 ++++++++++++++++++++-
 arch/x86/events/intel/pt.h                       |  4 ++
 drivers/hwtracing/coresight/coresight-etm-perf.c | 29 ++++++++--
 include/linux/perf_event.h                       | 15 +++++
 include/uapi/linux/perf_event.h                  | 11 +++-
 kernel/events/core.c                             | 72 +++++++++++++++++++++++-
 kernel/events/internal.h                         |  1 +
 tools/include/uapi/linux/perf_event.h            | 11 +++-
 tools/perf/util/auxtrace.c                       |  4 ++
 tools/perf/util/evsel.c                          |  9 +++
 tools/perf/util/evsel_config.h                   |  6 ++
 tools/perf/util/parse-events.c                   | 33 +++++++++++
 tools/perf/util/parse-events.h                   |  3 +
 tools/perf/util/parse-events.l                   |  3 +
 tools/perf/util/perf_event_attr_fprintf.c        |  3 +
 15 files changed, 255 insertions(+), 12 deletions(-)


Regards
Adrian


From adrian.hunter at intel.com  Fri Dec  8 09:24:46 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri,  8 Dec 2023 19:24:46 +0200
Subject: [PATCH RFC V2 1/4] perf/core: Add aux_pause, aux_resume, aux_start_paused
In-Reply-To: <20231208172449.35444-1-adrian.hunter@intel.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
Message-ID: <20231208172449.35444-2-adrian.hunter@intel.com>

Hardware traces, such as instruction traces, can produce a vast amount of
trace data, so being able to reduce tracing to more specific circumstances
can be useful.

The ability to pause or resume tracing when another event happens, can do
that.

Add ability for an event to "pause" or "resume" AUX area tracing.

Add aux_pause bit to perf_event_attr to indicate that, if the event
happens, the associated AUX area tracing should be paused. Ditto
aux_resume. Do not allow aux_pause and aux_resume to be set together.

Add aux_start_paused bit to perf_event_attr to indicate to an AUX area
event that it should start in a "paused" state.

Add aux_paused to struct perf_event for AUX area events to keep track of
the "paused" state. aux_paused is initialized to aux_start_paused.

Add PERF_EF_PAUSE and PERF_EF_RESUME modes for ->stop() and ->start()
callbacks. Call as needed, during __perf_event_output(). Add
aux_in_pause_resume to struct perf_buffer to prevent races with the NMI
handler. Pause/resume in NMI context will miss out if it coincides with
another pause/resume.

To use aux_pause or aux_resume, an event must be in a group with the AUX
area event as the group leader.

Example (requires Intel PT and tools patches also):

 $ perf record --kcore -e '{intel_pt/aux-start-paused/k,syscalls:sys_enter_newuname/aux-resume/,syscalls:sys_exit_newuname/aux-pause/}' uname
 Linux
 [ perf record: Woken up 1 times to write data ]
 [ perf record: Captured and wrote 0.041 MB perf.data ]
 $ perf script --call-trace
 uname    5712 [007]    83.855580930: name: 0x7ffd9dcebec0
 uname    5712 [007]    83.855582518:  psb offs: 0
 uname    5712 [007]    83.855582518:  cbr: 42 freq: 4205 MHz (150%)
 uname    5712 [007]    83.855582723: ([kernel.kallsyms])    debug_smp_processor_id
 uname    5712 [007]    83.855582723: ([kernel.kallsyms])    __x64_sys_newuname
 uname    5712 [007]    83.855582723: ([kernel.kallsyms])        down_read
 uname    5712 [007]    83.855582723: ([kernel.kallsyms])            __cond_resched
 uname    5712 [007]    83.855582932: ([kernel.kallsyms])            preempt_count_add
 uname    5712 [007]    83.855582932: ([kernel.kallsyms])                in_lock_functions
 uname    5712 [007]    83.855582932: ([kernel.kallsyms])            preempt_count_sub
 uname    5712 [007]    83.855582932: ([kernel.kallsyms])        up_read
 uname    5712 [007]    83.855582932: ([kernel.kallsyms])            preempt_count_add
 uname    5712 [007]    83.855583348: ([kernel.kallsyms])                in_lock_functions
 uname    5712 [007]    83.855583348: ([kernel.kallsyms])            preempt_count_sub
 uname    5712 [007]    83.855583348: ([kernel.kallsyms])        _copy_to_user
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])    syscall_exit_to_user_mode
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])        syscall_exit_work
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])            perf_syscall_exit
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])                debug_smp_processor_id
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])                perf_trace_buf_alloc
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    perf_swevent_get_recursion_context
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])                        debug_smp_processor_id
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    debug_smp_processor_id
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])                perf_tp_event
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    perf_trace_buf_update
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])                        tracing_gen_ctx_irq_test
 uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    perf_swevent_event
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                        __perf_event_account_interrupt
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                            __this_cpu_preempt_check
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                        perf_event_output_forward
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                            perf_event_aux_pause
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                ring_buffer_get
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    __rcu_read_lock
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    __rcu_read_unlock
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                pt_event_stop
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    debug_smp_processor_id
 uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    debug_smp_processor_id
 uname    5712 [007]    83.855583973: ([kernel.kallsyms])                                    native_write_msr
 uname    5712 [007]    83.855583973: ([kernel.kallsyms])                                    native_write_msr
 uname    5712 [007]    83.855584175: 0x0

Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
---
 include/linux/perf_event.h      | 15 +++++++
 include/uapi/linux/perf_event.h | 11 ++++-
 kernel/events/core.c            | 72 +++++++++++++++++++++++++++++++--
 kernel/events/internal.h        |  1 +
 4 files changed, 95 insertions(+), 4 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index e85cd1c0eaf3..252c4aac3b79 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -291,6 +291,7 @@ struct perf_event_pmu_context;
 #define PERF_PMU_CAP_NO_EXCLUDE			0x0040
 #define PERF_PMU_CAP_AUX_OUTPUT			0x0080
 #define PERF_PMU_CAP_EXTENDED_HW_TYPE		0x0100
+#define PERF_PMU_CAP_AUX_PAUSE			0x0200
 
 struct perf_output_handle;
 
@@ -363,6 +364,8 @@ struct pmu {
 #define PERF_EF_START	0x01		/* start the counter when adding    */
 #define PERF_EF_RELOAD	0x02		/* reload the counter when starting */
 #define PERF_EF_UPDATE	0x04		/* update the counter when stopping */
+#define PERF_EF_PAUSE	0x08		/* AUX area event, pause tracing */
+#define PERF_EF_RESUME	0x10		/* AUX area event, resume tracing */
 
 	/*
 	 * Adds/Removes a counter to/from the PMU, can be done inside a
@@ -402,6 +405,15 @@ struct pmu {
 	 *
 	 * ->start() with PERF_EF_RELOAD will reprogram the counter
 	 *  value, must be preceded by a ->stop() with PERF_EF_UPDATE.
+	 *
+	 * ->stop() with PERF_EF_PAUSE will stop as simply as possible. Will not
+	 * overlap another ->stop() with PERF_EF_PAUSE nor ->start() with
+	 * PERF_EF_RESUME.
+	 *
+	 * ->start() with PERF_EF_RESUME will start as simply as possible but
+	 * only if the counter is not otherwise stopped. Will not overlap
+	 * another ->start() with PERF_EF_RESUME nor ->stop() with
+	 * PERF_EF_PAUSE.
 	 */
 	void (*start)			(struct perf_event *event, int flags);
 	void (*stop)			(struct perf_event *event, int flags);
@@ -797,6 +809,9 @@ struct perf_event {
 	/* for aux_output events */
 	struct perf_event		*aux_event;
 
+	/* for AUX area events */
+	unsigned int			aux_paused;
+
 	void (*destroy)(struct perf_event *);
 	struct rcu_head			rcu_head;
 
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 39c6a250dd1b..437bc2a8d50c 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -507,7 +507,16 @@ struct perf_event_attr {
 	__u16	sample_max_stack;
 	__u16	__reserved_2;
 	__u32	aux_sample_size;
-	__u32	__reserved_3;
+
+	union {
+		__u32	aux_output_cfg;
+		struct {
+			__u64	aux_pause        :  1, /* on overflow, pause AUX area tracing */
+				aux_resume       :  1, /* on overflow, resume AUX area tracing */
+				aux_start_paused :  1, /* start AUX area tracing paused */
+				__reserved_3     : 29;
+		};
+	};
 
 	/*
 	 * User provided data if sigtrap=1, passed back to user via
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4c72a41f11af..c1e11884d06e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2060,7 +2060,8 @@ static void perf_put_aux_event(struct perf_event *event)
 
 static bool perf_need_aux_event(struct perf_event *event)
 {
-	return !!event->attr.aux_output || !!event->attr.aux_sample_size;
+	return event->attr.aux_output || event->attr.aux_sample_size ||
+	       event->attr.aux_pause || event->attr.aux_resume;
 }
 
 static int perf_get_aux_event(struct perf_event *event,
@@ -2085,6 +2086,10 @@ static int perf_get_aux_event(struct perf_event *event,
 	    !perf_aux_output_match(event, group_leader))
 		return 0;
 
+	if ((event->attr.aux_pause || event->attr.aux_resume) &&
+	    !(group_leader->pmu->capabilities & PERF_PMU_CAP_AUX_PAUSE))
+		return 0;
+
 	if (event->attr.aux_sample_size && !group_leader->pmu->snapshot_aux)
 		return 0;
 
@@ -7773,6 +7778,47 @@ void perf_prepare_header(struct perf_event_header *header,
 	WARN_ON_ONCE(header->size & 7);
 }
 
+static void __perf_event_aux_pause(struct perf_event *event, bool pause)
+{
+	if (pause) {
+		if (!READ_ONCE(event->aux_paused)) {
+			WRITE_ONCE(event->aux_paused, 1);
+			event->pmu->stop(event, PERF_EF_PAUSE);
+		}
+	} else {
+		if (READ_ONCE(event->aux_paused)) {
+			WRITE_ONCE(event->aux_paused, 0);
+			event->pmu->start(event, PERF_EF_RESUME);
+		}
+	}
+}
+
+static void perf_event_aux_pause(struct perf_event *event, bool pause)
+{
+	struct perf_buffer *rb;
+	unsigned long flags;
+
+	if (WARN_ON_ONCE(!event))
+		return;
+
+	rb = ring_buffer_get(event);
+	if (!rb)
+		return;
+
+	local_irq_save(flags);
+	/* Guard against NMI, NMI loses here */
+	if (READ_ONCE(rb->aux_in_pause_resume))
+		goto out_restore;
+	WRITE_ONCE(rb->aux_in_pause_resume, 1);
+	barrier();
+	__perf_event_aux_pause(event, pause);
+	barrier();
+	WRITE_ONCE(rb->aux_in_pause_resume, 0);
+out_restore:
+	local_irq_restore(flags);
+	ring_buffer_put(rb);
+}
+
 static __always_inline int
 __perf_event_output(struct perf_event *event,
 		    struct perf_sample_data *data,
@@ -7786,6 +7832,9 @@ __perf_event_output(struct perf_event *event,
 	struct perf_event_header header;
 	int err;
 
+	if (event->attr.aux_pause)
+		perf_event_aux_pause(event->aux_event, true);
+
 	/* protect the callchain buffers */
 	rcu_read_lock();
 
@@ -7802,6 +7851,10 @@ __perf_event_output(struct perf_event *event,
 
 exit:
 	rcu_read_unlock();
+
+	if (event->attr.aux_resume)
+		perf_event_aux_pause(event->aux_event, false);
+
 	return err;
 }
 
@@ -11941,10 +11994,23 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
 	}
 
 	if (event->attr.aux_output &&
-	    !(pmu->capabilities & PERF_PMU_CAP_AUX_OUTPUT)) {
+	    (!(pmu->capabilities & PERF_PMU_CAP_AUX_OUTPUT) ||
+	     event->attr.aux_pause || event->attr.aux_resume)) {
+		err = -EOPNOTSUPP;
+		goto err_pmu;
+	}
+
+	if (event->attr.aux_pause && event->attr.aux_resume) {
+		err = -EINVAL;
+		goto err_pmu;
+	}
+
+	if (event->attr.aux_start_paused &&
+	    !(pmu->capabilities & PERF_PMU_CAP_AUX_PAUSE)) {
 		err = -EOPNOTSUPP;
 		goto err_pmu;
 	}
+	event->aux_paused = event->attr.aux_start_paused;
 
 	if (cgroup_fd != -1) {
 		err = perf_cgroup_connect(cgroup_fd, event, attr, group_leader);
@@ -12741,7 +12807,7 @@ perf_event_create_kernel_counter(struct perf_event_attr *attr, int cpu,
 	 * Grouping is not supported for kernel events, neither is 'AUX',
 	 * make sure the caller's intentions are adjusted.
 	 */
-	if (attr->aux_output)
+	if (attr->aux_output || attr->aux_output_cfg)
 		return ERR_PTR(-EINVAL);
 
 	event = perf_event_alloc(attr, cpu, task, NULL, NULL,
diff --git a/kernel/events/internal.h b/kernel/events/internal.h
index 5150d5f84c03..3320f78117dc 100644
--- a/kernel/events/internal.h
+++ b/kernel/events/internal.h
@@ -51,6 +51,7 @@ struct perf_buffer {
 	void				(*free_aux)(void *);
 	refcount_t			aux_refcount;
 	int				aux_in_sampling;
+	int				aux_in_pause_resume;
 	void				**aux_pages;
 	void				*aux_priv;
 
-- 
2.34.1



From adrian.hunter at intel.com  Fri Dec  8 09:24:47 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri,  8 Dec 2023 19:24:47 +0200
Subject: [PATCH RFC V2 2/4] perf/x86/intel/pt: Add support for pause / resume
In-Reply-To: <20231208172449.35444-1-adrian.hunter@intel.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
Message-ID: <20231208172449.35444-3-adrian.hunter@intel.com>

Prevent tracing to start if aux_paused.

Implement support for PERF_EF_PAUSE / PERF_EF_RESUME. When aux_paused, stop
tracing. When not aux_paused, only start tracing if it isn't currently
meant to be stopped.

Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
---
 arch/x86/events/intel/pt.c | 63 ++++++++++++++++++++++++++++++++++++--
 arch/x86/events/intel/pt.h |  4 +++
 2 files changed, 64 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 42a55794004a..692b51849d1c 100644
--- a/arch/x86/events/intel/pt.c
+++ b/arch/x86/events/intel/pt.c
@@ -418,6 +418,9 @@ static void pt_config_start(struct perf_event *event)
 	struct pt *pt = this_cpu_ptr(&pt_ctx);
 	u64 ctl = event->hw.config;
 
+	if (READ_ONCE(event->aux_paused))
+		return;
+
 	ctl |= RTIT_CTL_TRACEEN;
 	if (READ_ONCE(pt->vmx_on))
 		perf_aux_output_flag(&pt->handle, PERF_AUX_FLAG_PARTIAL);
@@ -534,7 +537,20 @@ static void pt_config(struct perf_event *event)
 	reg |= (event->attr.config & PT_CONFIG_MASK);
 
 	event->hw.config = reg;
+
+	/*
+	 * Allow resume before starting so as not to overwrite a value set by a
+	 * PMI.
+	 */
+	WRITE_ONCE(pt->resume_allowed, 1);
+
 	pt_config_start(event);
+
+	/*
+	 * Allow pause after starting so its pt_config_stop() doesn't race with
+	 * pt_config_start().
+	 */
+	WRITE_ONCE(pt->pause_allowed, 1);
 }
 
 static void pt_config_stop(struct perf_event *event)
@@ -1507,6 +1523,7 @@ void intel_pt_interrupt(void)
 		buf = perf_aux_output_begin(&pt->handle, event);
 		if (!buf) {
 			event->hw.state = PERF_HES_STOPPED;
+			pt->resume_allowed = 0;
 			return;
 		}
 
@@ -1515,6 +1532,7 @@ void intel_pt_interrupt(void)
 		ret = pt_buffer_reset_markers(buf, &pt->handle);
 		if (ret) {
 			perf_aux_output_end(&pt->handle, 0);
+			pt->resume_allowed = 0;
 			return;
 		}
 
@@ -1569,6 +1587,26 @@ static void pt_event_start(struct perf_event *event, int mode)
 	struct pt *pt = this_cpu_ptr(&pt_ctx);
 	struct pt_buffer *buf;
 
+	if (mode & PERF_EF_RESUME) {
+		if (READ_ONCE(pt->resume_allowed)) {
+			u64 status;
+
+			/*
+			 * Only if the trace is not active and the error and
+			 * stopped bits are clear, is it safe to start, but a
+			 * PMI might have just cleared these, so resume_allowed
+			 * must be checked again also.
+			 */
+			rdmsrl(MSR_IA32_RTIT_STATUS, status);
+			if (!(status & (RTIT_STATUS_TRIGGEREN |
+					RTIT_STATUS_ERROR |
+					RTIT_STATUS_STOPPED)) &&
+			   READ_ONCE(pt->resume_allowed))
+				pt_config_start(event);
+		}
+		return;
+	}
+
 	buf = perf_aux_output_begin(&pt->handle, event);
 	if (!buf)
 		goto fail_stop;
@@ -1597,6 +1635,16 @@ static void pt_event_stop(struct perf_event *event, int mode)
 {
 	struct pt *pt = this_cpu_ptr(&pt_ctx);
 
+	if (mode & PERF_EF_PAUSE) {
+		if (READ_ONCE(pt->pause_allowed))
+			pt_config_stop(event);
+		return;
+	}
+
+	/* Protect against racing */
+	WRITE_ONCE(pt->pause_allowed, 0);
+	WRITE_ONCE(pt->resume_allowed, 0);
+
 	/*
 	 * Protect against the PMI racing with disabling wrmsr,
 	 * see comment in intel_pt_interrupt().
@@ -1655,8 +1703,12 @@ static long pt_event_snapshot_aux(struct perf_event *event,
 	/*
 	 * Here, handle_nmi tells us if the tracing is on
 	 */
-	if (READ_ONCE(pt->handle_nmi))
+	if (READ_ONCE(pt->handle_nmi)) {
+		/* Protect against racing */
+		WRITE_ONCE(pt->pause_allowed, 0);
+		WRITE_ONCE(pt->resume_allowed, 0);
 		pt_config_stop(event);
+	}
 
 	pt_read_offset(buf);
 	pt_update_head(pt);
@@ -1673,8 +1725,11 @@ static long pt_event_snapshot_aux(struct perf_event *event,
 	 * Compiler barrier not needed as we couldn't have been
 	 * preempted by anything that touches pt->handle_nmi.
 	 */
-	if (pt->handle_nmi)
+	if (pt->handle_nmi) {
+		WRITE_ONCE(pt->resume_allowed, 1);
 		pt_config_start(event);
+		WRITE_ONCE(pt->pause_allowed, 1);
+	}
 
 	return ret;
 }
@@ -1790,7 +1845,9 @@ static __init int pt_init(void)
 	if (!intel_pt_validate_hw_cap(PT_CAP_topa_multiple_entries))
 		pt_pmu.pmu.capabilities = PERF_PMU_CAP_AUX_NO_SG;
 
-	pt_pmu.pmu.capabilities	|= PERF_PMU_CAP_EXCLUSIVE | PERF_PMU_CAP_ITRACE;
+	pt_pmu.pmu.capabilities		|= PERF_PMU_CAP_EXCLUSIVE |
+					   PERF_PMU_CAP_ITRACE |
+					   PERF_PMU_CAP_AUX_PAUSE;
 	pt_pmu.pmu.attr_groups		 = pt_attr_groups;
 	pt_pmu.pmu.task_ctx_nr		 = perf_sw_context;
 	pt_pmu.pmu.event_init		 = pt_event_init;
diff --git a/arch/x86/events/intel/pt.h b/arch/x86/events/intel/pt.h
index 96906a62aacd..b9527205e028 100644
--- a/arch/x86/events/intel/pt.h
+++ b/arch/x86/events/intel/pt.h
@@ -117,6 +117,8 @@ struct pt_filters {
  * @filters:		last configured filters
  * @handle_nmi:		do handle PT PMI on this cpu, there's an active event
  * @vmx_on:		1 if VMX is ON on this cpu
+ * @pause_allowed:	PERF_EF_PAUSE is allowed to stop tracing
+ * @resume_allowed:	PERF_EF_RESUME is allowed to start tracing
  * @output_base:	cached RTIT_OUTPUT_BASE MSR value
  * @output_mask:	cached RTIT_OUTPUT_MASK MSR value
  */
@@ -125,6 +127,8 @@ struct pt {
 	struct pt_filters	filters;
 	int			handle_nmi;
 	int			vmx_on;
+	int			pause_allowed;
+	int			resume_allowed;
 	u64			output_base;
 	u64			output_mask;
 };
-- 
2.34.1



From adrian.hunter at intel.com  Fri Dec  8 09:24:48 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri,  8 Dec 2023 19:24:48 +0200
Subject: [PATCH RFC V2 3/4] perf tools: Add support for AUX area pause / resume
In-Reply-To: <20231208172449.35444-1-adrian.hunter@intel.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
Message-ID: <20231208172449.35444-4-adrian.hunter@intel.com>

Add config terms aux-pause, aux-resume and aux-start-paused.

Still to do: validation, fallbacks for perf_event_open, documentation.

Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
---
 tools/include/uapi/linux/perf_event.h     | 11 +++++++-
 tools/perf/util/auxtrace.c                |  4 +++
 tools/perf/util/evsel.c                   |  9 +++++++
 tools/perf/util/evsel_config.h            |  6 +++++
 tools/perf/util/parse-events.c            | 33 +++++++++++++++++++++++
 tools/perf/util/parse-events.h            |  3 +++
 tools/perf/util/parse-events.l            |  3 +++
 tools/perf/util/perf_event_attr_fprintf.c |  3 +++
 8 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
index 3a64499b0f5d..9db32bc10d5b 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -511,7 +511,16 @@ struct perf_event_attr {
 	__u16	sample_max_stack;
 	__u16	__reserved_2;
 	__u32	aux_sample_size;
-	__u32	__reserved_3;
+
+	union {
+		__u32	aux_output_cfg;
+		struct {
+			__u64	aux_pause        :  1, /* on overflow, pause AUX area tracing */
+				aux_resume       :  1, /* on overflow, resume AUX area tracing */
+				aux_start_paused :  1, /* start AUX area tracing paused */
+				__reserved_3     : 29;
+		};
+	};
 
 	/*
 	 * User provided data if sigtrap=1, passed back to user via
diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index a0368202a746..4a7ca8b0d100 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -814,6 +814,10 @@ void auxtrace_regroup_aux_output(struct evlist *evlist)
 		if (evsel__is_aux_event(evsel))
 			aux_evsel = evsel;
 		term = evsel__get_config_term(evsel, AUX_OUTPUT);
+		if (!term)
+			term = evsel__get_config_term(evsel, AUX_PAUSE);
+		if (!term)
+			term = evsel__get_config_term(evsel, AUX_RESUME);
 		/* If possible, group with the AUX event */
 		if (term && aux_evsel)
 			evlist__regroup(evlist, aux_evsel, evsel);
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index a5da74e3a517..03553c104954 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1001,6 +1001,15 @@ static void evsel__apply_config_terms(struct evsel *evsel,
 		case EVSEL__CONFIG_TERM_AUX_OUTPUT:
 			attr->aux_output = term->val.aux_output ? 1 : 0;
 			break;
+		case EVSEL__CONFIG_TERM_AUX_PAUSE:
+			attr->aux_pause = term->val.aux_pause ? 1 : 0;
+			break;
+		case EVSEL__CONFIG_TERM_AUX_RESUME:
+			attr->aux_resume = term->val.aux_resume ? 1 : 0;
+			break;
+		case EVSEL__CONFIG_TERM_AUX_START_PAUSED:
+			attr->aux_start_paused = term->val.aux_start_paused ? 1 : 0;
+			break;
 		case EVSEL__CONFIG_TERM_AUX_SAMPLE_SIZE:
 			/* Already applied by auxtrace */
 			break;
diff --git a/tools/perf/util/evsel_config.h b/tools/perf/util/evsel_config.h
index aee6f808b512..85ad183b5637 100644
--- a/tools/perf/util/evsel_config.h
+++ b/tools/perf/util/evsel_config.h
@@ -25,6 +25,9 @@ enum evsel_term_type {
 	EVSEL__CONFIG_TERM_BRANCH,
 	EVSEL__CONFIG_TERM_PERCORE,
 	EVSEL__CONFIG_TERM_AUX_OUTPUT,
+	EVSEL__CONFIG_TERM_AUX_PAUSE,
+	EVSEL__CONFIG_TERM_AUX_RESUME,
+	EVSEL__CONFIG_TERM_AUX_START_PAUSED,
 	EVSEL__CONFIG_TERM_AUX_SAMPLE_SIZE,
 	EVSEL__CONFIG_TERM_CFG_CHG,
 };
@@ -44,6 +47,9 @@ struct evsel_config_term {
 		unsigned long max_events;
 		bool	      percore;
 		bool	      aux_output;
+		bool	      aux_pause;
+		bool	      aux_resume;
+		bool	      aux_start_paused;
 		u32	      aux_sample_size;
 		u64	      cfg_chg;
 		char	      *str;
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index aa2f5c6fc7fc..615b04d5fb30 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -768,6 +768,9 @@ static const char *config_term_name(enum parse_events__term_type term_type)
 		[PARSE_EVENTS__TERM_TYPE_DRV_CFG]		= "driver-config",
 		[PARSE_EVENTS__TERM_TYPE_PERCORE]		= "percore",
 		[PARSE_EVENTS__TERM_TYPE_AUX_OUTPUT]		= "aux-output",
+		[PARSE_EVENTS__TERM_TYPE_AUX_PAUSE]		= "aux-pause",
+		[PARSE_EVENTS__TERM_TYPE_AUX_RESUME]		= "aux-resume",
+		[PARSE_EVENTS__TERM_TYPE_AUX_START_PAUSED]	= "aux-start-paused",
 		[PARSE_EVENTS__TERM_TYPE_AUX_SAMPLE_SIZE]	= "aux-sample-size",
 		[PARSE_EVENTS__TERM_TYPE_METRIC_ID]		= "metric-id",
 		[PARSE_EVENTS__TERM_TYPE_RAW]                   = "raw",
@@ -817,6 +820,9 @@ config_term_avail(enum parse_events__term_type term_type, struct parse_events_er
 	case PARSE_EVENTS__TERM_TYPE_OVERWRITE:
 	case PARSE_EVENTS__TERM_TYPE_DRV_CFG:
 	case PARSE_EVENTS__TERM_TYPE_AUX_OUTPUT:
+	case PARSE_EVENTS__TERM_TYPE_AUX_PAUSE:
+	case PARSE_EVENTS__TERM_TYPE_AUX_RESUME:
+	case PARSE_EVENTS__TERM_TYPE_AUX_START_PAUSED:
 	case PARSE_EVENTS__TERM_TYPE_AUX_SAMPLE_SIZE:
 	case PARSE_EVENTS__TERM_TYPE_RAW:
 	case PARSE_EVENTS__TERM_TYPE_LEGACY_CACHE:
@@ -936,6 +942,15 @@ do {									   \
 	case PARSE_EVENTS__TERM_TYPE_AUX_OUTPUT:
 		CHECK_TYPE_VAL(NUM);
 		break;
+	case PARSE_EVENTS__TERM_TYPE_AUX_PAUSE:
+		CHECK_TYPE_VAL(NUM);
+		break;
+	case PARSE_EVENTS__TERM_TYPE_AUX_RESUME:
+		CHECK_TYPE_VAL(NUM);
+		break;
+	case PARSE_EVENTS__TERM_TYPE_AUX_START_PAUSED:
+		CHECK_TYPE_VAL(NUM);
+		break;
 	case PARSE_EVENTS__TERM_TYPE_AUX_SAMPLE_SIZE:
 		CHECK_TYPE_VAL(NUM);
 		if (term->val.num > UINT_MAX) {
@@ -1036,6 +1051,9 @@ static int config_term_tracepoint(struct perf_event_attr *attr,
 	case PARSE_EVENTS__TERM_TYPE_OVERWRITE:
 	case PARSE_EVENTS__TERM_TYPE_NOOVERWRITE:
 	case PARSE_EVENTS__TERM_TYPE_AUX_OUTPUT:
+	case PARSE_EVENTS__TERM_TYPE_AUX_PAUSE:
+	case PARSE_EVENTS__TERM_TYPE_AUX_RESUME:
+	case PARSE_EVENTS__TERM_TYPE_AUX_START_PAUSED:
 	case PARSE_EVENTS__TERM_TYPE_AUX_SAMPLE_SIZE:
 		return config_term_common(attr, term, err);
 	case PARSE_EVENTS__TERM_TYPE_USER:
@@ -1170,6 +1188,18 @@ do {								\
 			ADD_CONFIG_TERM_VAL(AUX_OUTPUT, aux_output,
 					    term->val.num ? 1 : 0, term->weak);
 			break;
+		case PARSE_EVENTS__TERM_TYPE_AUX_PAUSE:
+			ADD_CONFIG_TERM_VAL(AUX_PAUSE, aux_pause,
+					    term->val.num ? 1 : 0, term->weak);
+			break;
+		case PARSE_EVENTS__TERM_TYPE_AUX_RESUME:
+			ADD_CONFIG_TERM_VAL(AUX_RESUME, aux_resume,
+					    term->val.num ? 1 : 0, term->weak);
+			break;
+		case PARSE_EVENTS__TERM_TYPE_AUX_START_PAUSED:
+			ADD_CONFIG_TERM_VAL(AUX_START_PAUSED, aux_start_paused,
+					    term->val.num ? 1 : 0, term->weak);
+			break;
 		case PARSE_EVENTS__TERM_TYPE_AUX_SAMPLE_SIZE:
 			ADD_CONFIG_TERM_VAL(AUX_SAMPLE_SIZE, aux_sample_size,
 					    term->val.num, term->weak);
@@ -1232,6 +1262,9 @@ static int get_config_chgs(struct perf_pmu *pmu, struct parse_events_terms *head
 		case PARSE_EVENTS__TERM_TYPE_DRV_CFG:
 		case PARSE_EVENTS__TERM_TYPE_PERCORE:
 		case PARSE_EVENTS__TERM_TYPE_AUX_OUTPUT:
+		case PARSE_EVENTS__TERM_TYPE_AUX_PAUSE:
+		case PARSE_EVENTS__TERM_TYPE_AUX_RESUME:
+		case PARSE_EVENTS__TERM_TYPE_AUX_START_PAUSED:
 		case PARSE_EVENTS__TERM_TYPE_AUX_SAMPLE_SIZE:
 		case PARSE_EVENTS__TERM_TYPE_METRIC_ID:
 		case PARSE_EVENTS__TERM_TYPE_RAW:
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index 63c0a36a4bf1..ff0871385b50 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -74,6 +74,9 @@ enum parse_events__term_type {
 	PARSE_EVENTS__TERM_TYPE_DRV_CFG,
 	PARSE_EVENTS__TERM_TYPE_PERCORE,
 	PARSE_EVENTS__TERM_TYPE_AUX_OUTPUT,
+	PARSE_EVENTS__TERM_TYPE_AUX_PAUSE,
+	PARSE_EVENTS__TERM_TYPE_AUX_RESUME,
+	PARSE_EVENTS__TERM_TYPE_AUX_START_PAUSED,
 	PARSE_EVENTS__TERM_TYPE_AUX_SAMPLE_SIZE,
 	PARSE_EVENTS__TERM_TYPE_METRIC_ID,
 	PARSE_EVENTS__TERM_TYPE_RAW,
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index e86c45675e1d..56963013c3af 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -244,6 +244,9 @@ overwrite		{ return term(yyscanner, PARSE_EVENTS__TERM_TYPE_OVERWRITE); }
 no-overwrite		{ return term(yyscanner, PARSE_EVENTS__TERM_TYPE_NOOVERWRITE); }
 percore			{ return term(yyscanner, PARSE_EVENTS__TERM_TYPE_PERCORE); }
 aux-output		{ return term(yyscanner, PARSE_EVENTS__TERM_TYPE_AUX_OUTPUT); }
+aux-pause		{ return term(yyscanner, PARSE_EVENTS__TERM_TYPE_AUX_PAUSE); }
+aux-resume		{ return term(yyscanner, PARSE_EVENTS__TERM_TYPE_AUX_RESUME); }
+aux-start-paused	{ return term(yyscanner, PARSE_EVENTS__TERM_TYPE_AUX_START_PAUSED); }
 aux-sample-size		{ return term(yyscanner, PARSE_EVENTS__TERM_TYPE_AUX_SAMPLE_SIZE); }
 metric-id		{ return term(yyscanner, PARSE_EVENTS__TERM_TYPE_METRIC_ID); }
 cpu-cycles|cycles				{ return hw_term(yyscanner, PERF_COUNT_HW_CPU_CYCLES); }
diff --git a/tools/perf/util/perf_event_attr_fprintf.c b/tools/perf/util/perf_event_attr_fprintf.c
index 8f04d3b7f3ec..e6ba0ac73182 100644
--- a/tools/perf/util/perf_event_attr_fprintf.c
+++ b/tools/perf/util/perf_event_attr_fprintf.c
@@ -309,6 +309,7 @@ int perf_event_attr__fprintf(FILE *fp, struct perf_event_attr *attr,
 	PRINT_ATTRf(inherit_thread, p_unsigned);
 	PRINT_ATTRf(remove_on_exec, p_unsigned);
 	PRINT_ATTRf(sigtrap, p_unsigned);
+	PRINT_ATTRf(aux_start_paused, p_unsigned);
 
 	PRINT_ATTRn("{ wakeup_events, wakeup_watermark }", wakeup_events, p_unsigned, false);
 	PRINT_ATTRf(bp_type, p_unsigned);
@@ -323,6 +324,8 @@ int perf_event_attr__fprintf(FILE *fp, struct perf_event_attr *attr,
 	PRINT_ATTRf(sample_max_stack, p_unsigned);
 	PRINT_ATTRf(aux_sample_size, p_unsigned);
 	PRINT_ATTRf(sig_data, p_unsigned);
+	PRINT_ATTRf(aux_pause, p_unsigned);
+	PRINT_ATTRf(aux_resume, p_unsigned);
 
 	return ret;
 }
-- 
2.34.1



From adrian.hunter at intel.com  Fri Dec  8 09:24:49 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri,  8 Dec 2023 19:24:49 +0200
Subject: [PATCH RFC V2 4/4] coresight: Have a stab at support for pause / resume
In-Reply-To: <20231208172449.35444-1-adrian.hunter@intel.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
Message-ID: <20231208172449.35444-5-adrian.hunter@intel.com>

For discussion only, un-tested, not even compiled...

Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
---
 .../hwtracing/coresight/coresight-etm-perf.c  | 29 ++++++++++++++++---
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 5ca6278baff4..36e774405c51 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -45,6 +45,7 @@ static bool etm_perf_up;
 struct etm_ctxt {
 	struct perf_output_handle handle;
 	struct etm_event_data *event_data;
+	int pr_allowed;
 };
 
 static DEFINE_PER_CPU(struct etm_ctxt, etm_ctxt);
@@ -452,6 +453,13 @@ static void etm_event_start(struct perf_event *event, int flags)
 	struct list_head *path;
 	u64 hw_id;
 
+	if (mode & PERF_EF_RESUME) {
+		if (!READ_ONCE(ctxt->pr_allowed))
+			return;
+	} else if (READ_ONCE(event->aux_paused)) {
+		goto out_pr_allowed;
+	}
+
 	if (!csdev)
 		goto fail;
 
@@ -514,6 +522,8 @@ static void etm_event_start(struct perf_event *event, int flags)
 	event->hw.state = 0;
 	/* Save the event_data for this ETM */
 	ctxt->event_data = event_data;
+out_pr_allowed:
+	WRITE_ONCE(ctxt->pr_allowed, 1);
 	return;
 
 fail_disable_path:
@@ -530,6 +540,7 @@ static void etm_event_start(struct perf_event *event, int flags)
 	}
 fail:
 	event->hw.state = PERF_HES_STOPPED;
+	WRITE_ONCE(ctxt->pr_allowed, 0);
 	return;
 }
 
@@ -543,6 +554,11 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	struct etm_event_data *event_data;
 	struct list_head *path;
 
+	if (mode & PERF_EF_PAUSE && !READ_ONCE(ctxt->pr_allowed))
+		return;
+
+	WRITE_ONCE(ctxt->pr_allowed, 0);
+
 	/*
 	 * If we still have access to the event_data via handle,
 	 * confirm that we haven't messed up the tracking.
@@ -556,7 +572,7 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	ctxt->event_data = NULL;
 
 	if (event->hw.state == PERF_HES_STOPPED)
-		return;
+		goto out_pr_allowed;
 
 	/* We must have a valid event_data for a running event */
 	if (WARN_ON(!event_data))
@@ -627,6 +643,10 @@ static void etm_event_stop(struct perf_event *event, int mode)
 
 	/* Disabling the path make its elements available to other sessions */
 	coresight_disable_path(path);
+
+out_pr_allowed:
+	if (mode & PERF_EF_PAUSE)
+		WRITE_ONCE(ctxt->pr_allowed, 1);
 }
 
 static int etm_event_add(struct perf_event *event, int mode)
@@ -634,7 +654,7 @@ static int etm_event_add(struct perf_event *event, int mode)
 	int ret = 0;
 	struct hw_perf_event *hwc = &event->hw;
 
-	if (mode & PERF_EF_START) {
+	if (mode & PERF_EF_START && !READ_ONCE(event->aux_paused)) {
 		etm_event_start(event, 0);
 		if (hwc->state & PERF_HES_STOPPED)
 			ret = -EINVAL;
@@ -886,8 +906,9 @@ int __init etm_perf_init(void)
 {
 	int ret;
 
-	etm_pmu.capabilities		= (PERF_PMU_CAP_EXCLUSIVE |
-					   PERF_PMU_CAP_ITRACE);
+	etm_pmu.capabilities		= PERF_PMU_CAP_EXCLUSIVE |
+					  PERF_PMU_CAP_ITRACE |
+					  PERF_PMU_CAP_AUX_PAUSE;
 
 	etm_pmu.attr_groups		= etm_pmu_attr_groups;
 	etm_pmu.task_ctx_nr		= perf_sw_context;
-- 
2.34.1



From cfsworks at gmail.com  Fri Dec  8 09:27:10 2023
From: cfsworks at gmail.com (Sam Edwards)
Date: Fri, 8 Dec 2023 10:27:10 -0700
Subject: [PATCH v2] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
In-Reply-To: <6311244.MhkbZ0Pkbq@diego>
References: <20231208062510.893392-1-CFSworks@gmail.com>
 <6311244.MhkbZ0Pkbq@diego>
Message-ID: <66f413d2-1a5b-b9e3-3c86-35a1d150f486@gmail.com>



On 12/8/23 04:05, Heiko St?bner wrote:
> Hi Sam,
> 
> Am Freitag, 8. Dezember 2023, 07:25:10 CET schrieb Sam Edwards:
>> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
>> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
>> will sometimes (varying between specific RK3588 chips, not over time) shut
>> off the DBI block, and reads to this range will instead stall
>> indefinitely.
>>
>> When this happens, it will prevent Linux from booting altogether. The
>> PCIe driver will stall the CPU core once it attempts to read the version
>> information from the DBI range.
>>
>> Fix this boot hang by adding the correct pinctrl configuration to the
>> PCIe 3.0 device node, which is the proper thing to do anyway. While
>> we're at it, also add the necessary configuration to the PCIe 2.0 node,
>> which may or may not fix the equivalent problem over there -- but is the
>> proper thing to do anyway. :)
>>
>> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
>> Signed-off-by: Sam Edwards <CFSworks at gmail.com>
>> ---
>>
>> Hi list,
>>
>> Compared to v1, v2 removes the `reset-gpios` properties as well -- this should
>> give control of the PCIe resets exclusively to the PCIe cores. (And even if the
>> `reset-gpios` props had no effect in v1, it'd be confusing to have them there.)
> 
> Hmm, I'd think this could result in differing behaviour.
> 
> I.e. I tried the same on a different board with a nvme drive on the pci30x4
> controller. But moving the reset from the gpio-way to "just" setting the
> perstn pinctrl, simply hung the controller when probing the device.

Ah, I'm guessing it died in:
ver = dw_pcie_readl_dbi(pci, PCIE_VERSION_NUMBER);

If so, that's the same hang that this patch is aiming to solve. I'm 
starting to wonder if having muxed pins != 1 for a given signal upsets 
the RC(s). Is your board (in an earlier boot stage: 
reset/maskrom/bootloader) muxing a different perstn pin option to that 
controller (and Linux doesn't know to clear it away)? Then when you add 
the perstn pinctrl the total number of perstns muxed to the controller 
comes to 2, and without a reset-gpios = <...>; to take it away again, 
that number stays at 2 to cause the hang upon the DBI read?

If so, that'd mean the change resolves the hang for me, because it 
brings the total up to 1 (from 0), but also causes the hang for you, 
because it brings the total up to 2 (away from 1).

> 
> So I guess I'd think the best way would be to split the pinctrl up into the
> 3 separate functions (clkreqn, perstn, waken) so that boards can include
> them individually.

Mm, maybe. Though that might be more appropriate if a board comes along 
that doesn't connect all of those signals to the same group of pins. I 
worry that attempting to solve this hang by doing that will instead just 
mask the real problem.

> 
> Nobody is using the controller pinctrl entries so far anyway :-) .

Then it's interesting that this board requires them in order to avoid a 
hang on boot. I'll see if there's anything else that I can find out.

Happy Friday,
Sam

> 
> 
> Heiko
> 
> 
>> Note that it is OK for the pcie2x1l1 node to refer to pcie30x1m1_pins. The
>> pcie2x1l1 device is *in fact* a PCIe 3.0 controller, and the pcie30x1m1_pins
>> pinmux setting is so-named to reflect this. The pcie2x1l1 node is so-named
>> because Linux does not (currently) support routing it to a PCIe 3.0 PHY; so in
>> practice it is effectively a PCIe 2.0 controller, for the time being.
>>
>> Cheers and thank you for your time,
>> Sam
>>
>> ---
>>   .../boot/dts/rockchip/rk3588-turing-rk1.dtsi     | 16 ++--------------
>>   1 file changed, 2 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
>> index 9570b34aca2e..875446fdb67e 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
>> @@ -214,8 +214,7 @@ rgmii_phy: ethernet-phy at 1 {
>>   &pcie2x1l1 {
>>   	linux,pci-domain = <1>;
>>   	pinctrl-names = "default";
>> -	pinctrl-0 = <&pcie2_reset>;
>> -	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
>> +	pinctrl-0 = <&pcie30x1m1_pins>;
>>   	status = "okay";
>>   };
>>   
>> @@ -226,8 +225,7 @@ &pcie30phy {
>>   &pcie3x4 {
>>   	linux,pci-domain = <0>;
>>   	pinctrl-names = "default";
>> -	pinctrl-0 = <&pcie3_reset>;
>> -	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
>> +	pinctrl-0 = <&pcie30x4m1_pins>;
>>   	vpcie3v3-supply = <&vcc3v3_pcie30>;
>>   	status = "okay";
>>   };
>> @@ -245,17 +243,7 @@ hym8563_int: hym8563-int {
>>   		};
>>   	};
>>   
>> -	pcie2 {
>> -		pcie2_reset: pcie2-reset {
>> -			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
>> -		};
>> -	};
>> -
>>   	pcie3 {
>> -		pcie3_reset: pcie3-reset {
>> -			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
>> -		};
>> -
>>   		vcc3v3_pcie30_en: pcie3-reg {
>>   			rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
>>   		};
>>
> 
> 
> 
> 


From Liam.Howlett at Oracle.com  Fri Dec  8 09:54:02 2023
From: Liam.Howlett at Oracle.com (Liam R. Howlett)
Date: Fri, 8 Dec 2023 12:54:02 -0500
Subject: [PATCH] maple_tree: Fix mas_prev() state separation code
In-Reply-To: <202312071302.99D5B1BB76@keescook>
References: <20231207014104.n6vul2ylgqjnsfia@revolve>
 <20231207193319.4025462-1-Liam.Howlett@oracle.com>
 <202312071302.99D5B1BB76@keescook>
Message-ID: <20231208175402.hvy2htzs45oa5psx@revolver>

* Kees Cook <keescook at chromium.org> [231207 16:04]:
> On Thu, Dec 07, 2023 at 02:33:19PM -0500, Liam R. Howlett wrote:
> > mas_prev() was setting the ma_underflow condition when the limit was
> > reached and not when the limit was attempting to go lower.  This
> > resulted in the incorrect behaviour on subsequent actions.
> > 
> > This commit fixes the status setting to only set ma_underflow when the
> > lower limit is attempted to be decremented, and modifies the testing to
> > ensure that's the case.
> > 
> > Signed-off-by: Liam R. Howlett <Liam.Howlett at oracle.com>
> 
> Is this is related to the report[1] I forwarded? If so, please add these tags
> too:
> 
>  Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
>  Closes: https://lore.kernel.org/all/CA+G9fYs-j2FYZSFSVZj48mgoM9gQd4-7M2mu2Ez3D1DqDdW2bQ at mail.gmail.com/ [1]
> 

Ah, yes it is.  I missed these tags. Sorry about that.

I have another patch to send in regards to this area on the
mmap_region() side but it's less urgent.  I'll Cc you on that one as
well.


> Thanks either way!
> 
> -Kees
> 
> > ---
> > 
> > Andrew,
> > 
> > This should be clean to squash into 7f79fdb1d94d7 ("maple_tree: separate
> > ma_state node from status.") which is currently in your mm-unstable
> > branch.
> > 
> > Thanks,
> > Liam
> > 
> > 
> >  lib/maple_tree.c      | 16 ++++++++++++----
> >  lib/test_maple_tree.c |  9 +++++++--
> >  2 files changed, 19 insertions(+), 6 deletions(-)
> > 
> > diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> > index 89f8d21602774..47f2a7a973852 100644
> > --- a/lib/maple_tree.c
> > +++ b/lib/maple_tree.c
> > @@ -4432,6 +4432,9 @@ static void *mas_prev_slot(struct ma_state *mas, unsigned long min, bool empty)
> >  		mas->last = mas->index - 1;
> >  		mas->index = mas_safe_min(mas, pivots, mas->offset);
> >  	} else  {
> > +		if (mas->index <= min)
> > +			goto underflow;
> > +
> >  		if (mas_prev_node(mas, min)) {
> >  			mas_rewalk(mas, save_point);
> >  			goto retry;
> > @@ -4452,15 +4455,15 @@ static void *mas_prev_slot(struct ma_state *mas, unsigned long min, bool empty)
> >  	if (unlikely(mas_rewalk_if_dead(mas, node, save_point)))
> >  		goto retry;
> >  
> > -	if (mas->index <= min)
> > -		mas->status = ma_underflow;
> >  
> >  	if (likely(entry))
> >  		return entry;
> >  
> >  	if (!empty) {
> > -		if (mas_is_underflow(mas))
> > +		if (mas->index <= min) {
> > +			mas->status = ma_underflow;
> >  			return NULL;
> > +		}
> >  
> >  		goto again;
> >  	}
> > @@ -4596,7 +4599,7 @@ static void *mas_next_slot(struct ma_state *mas, unsigned long max, bool empty)
> >  		if (unlikely(mas_rewalk_if_dead(mas, node, save_point)))
> >  			goto retry;
> >  
> > -		if (pivot >= max) {
> > +		if (pivot >= max) { /* Was at the limit, next will extend beyond */
> >  			mas->status = ma_overflow;
> >  			return NULL;
> >  		}
> > @@ -4611,6 +4614,11 @@ static void *mas_next_slot(struct ma_state *mas, unsigned long max, bool empty)
> >  		else
> >  			mas->last = mas->max;
> >  	} else  {
> > +		if (mas->last >= max) {
> > +			mas->status = ma_overflow;
> > +			return NULL;
> > +		}
> > +
> >  		if (mas_next_node(mas, node, max)) {
> >  			mas_rewalk(mas, save_point);
> >  			goto retry;
> > diff --git a/lib/test_maple_tree.c b/lib/test_maple_tree.c
> > index 15fbeb788f3ac..29185ac5c727f 100644
> > --- a/lib/test_maple_tree.c
> > +++ b/lib/test_maple_tree.c
> > @@ -3294,8 +3294,8 @@ static noinline void __init check_state_handling(struct maple_tree *mt)
> >  	MT_BUG_ON(mt, mas.last != 0x1500);
> >  	MT_BUG_ON(mt, !mas_is_active(&mas));
> >  
> > -	/* next:active ->active */
> > -	entry = mas_next(&mas, ULONG_MAX);
> > +	/* next:active ->active (spanning limit) */
> > +	entry = mas_next(&mas, 0x2100);
> >  	MT_BUG_ON(mt, entry != ptr2);
> >  	MT_BUG_ON(mt, mas.index != 0x2000);
> >  	MT_BUG_ON(mt, mas.last != 0x2500);
> > @@ -3360,6 +3360,11 @@ static noinline void __init check_state_handling(struct maple_tree *mt)
> >  	MT_BUG_ON(mt, entry != ptr);
> >  	MT_BUG_ON(mt, mas.index != 0x1000);
> >  	MT_BUG_ON(mt, mas.last != 0x1500);
> > +	MT_BUG_ON(mt, !mas_is_active(&mas)); /* spanning limit */
> > +	entry = mas_prev(&mas, 0x1200); /* underflow */
> > +	MT_BUG_ON(mt, entry != NULL);
> > +	MT_BUG_ON(mt, mas.index != 0x1000);
> > +	MT_BUG_ON(mt, mas.last != 0x1500);
> >  	MT_BUG_ON(mt, !mas_is_underflow(&mas));
> >  
> >  	/* prev:underflow -> underflow (lower limit) spanning end range */
> > -- 
> > 2.40.1
> > 
> 
> -- 
> Kees Cook


From kan.liang at linux.intel.com  Fri Dec  8 10:14:28 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Fri, 8 Dec 2023 13:14:28 -0500
Subject: [PATCH V2 1/5] perf mem: Add mem_events into the supported
 perf_pmu
In-Reply-To: <20231208102922.GB769184@leoy-huanghe.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-2-kan.liang@linux.intel.com>
 <20231208102922.GB769184@leoy-huanghe.lan>
Message-ID: <98863f44-4a35-4910-8db0-dbbf0474f6ae@linux.intel.com>



On 2023-12-08 5:29 a.m., Leo Yan wrote:
> On Thu, Dec 07, 2023 at 11:23:34AM -0800, kan.liang at linux.intel.com wrote:
>> From: Kan Liang <kan.liang at linux.intel.com>
>>
>> With the mem_events, perf doesn't need to read sysfs for each PMU to
>> find the mem-events-supported PMU. The patch also makes it possible to
>> clean up the related __weak functions later.
>>
>> The patch is only to add the mem_events into the perf_pmu for all ARCHs.
>> It will be used in the later cleanup patches.
>>
>> Reviewed-by: Ian Rogers <irogers at google.com>
>> Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
>> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
>> ---
>>  tools/perf/arch/arm64/util/mem-events.c | 4 ++--
>>  tools/perf/arch/arm64/util/mem-events.h | 7 +++++++
>>  tools/perf/arch/arm64/util/pmu.c        | 6 ++++++
>>  tools/perf/arch/s390/util/pmu.c         | 3 +++
>>  tools/perf/arch/x86/util/mem-events.c   | 4 ++--
>>  tools/perf/arch/x86/util/mem-events.h   | 9 +++++++++
>>  tools/perf/arch/x86/util/pmu.c          | 7 +++++++
>>  tools/perf/util/mem-events.c            | 2 +-
>>  tools/perf/util/mem-events.h            | 1 +
>>  tools/perf/util/pmu.c                   | 4 +++-
>>  tools/perf/util/pmu.h                   | 7 +++++++
>>  11 files changed, 48 insertions(+), 6 deletions(-)
>>  create mode 100644 tools/perf/arch/arm64/util/mem-events.h
>>  create mode 100644 tools/perf/arch/x86/util/mem-events.h
>>
>> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
>> index 3bcc5c7035c2..aaa4804922b4 100644
>> --- a/tools/perf/arch/arm64/util/mem-events.c
>> +++ b/tools/perf/arch/arm64/util/mem-events.c
>> @@ -4,7 +4,7 @@
>>  
>>  #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>>  
>> -static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
>> +struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
>>  	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
>>  	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
>>  	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
>> @@ -17,7 +17,7 @@ struct perf_mem_event *perf_mem_events__ptr(int i)
>>  	if (i >= PERF_MEM_EVENTS__MAX)
>>  		return NULL;
>>  
>> -	return &perf_mem_events[i];
>> +	return &perf_mem_events_arm[i];
> 
> I recognized that it's hard code to "arm_spe_0", which might break if
> system registers different Arm SPE groups.  But this is not the issue
> introduced by this patch, we might need to consider to fix it later.
> 
>>  }
>>  
>>  const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
>> diff --git a/tools/perf/arch/arm64/util/mem-events.h b/tools/perf/arch/arm64/util/mem-events.h
>> new file mode 100644
>> index 000000000000..5fc50be4be38
>> --- /dev/null
>> +++ b/tools/perf/arch/arm64/util/mem-events.h
>> @@ -0,0 +1,7 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _ARM64_MEM_EVENTS_H
>> +#define _ARM64_MEM_EVENTS_H
>> +
>> +extern struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX];
>> +
>> +#endif /* _ARM64_MEM_EVENTS_H */
>> diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
>> index 2a4eab2d160e..06ec9b838807 100644
>> --- a/tools/perf/arch/arm64/util/pmu.c
>> +++ b/tools/perf/arch/arm64/util/pmu.c
>> @@ -8,6 +8,12 @@
>>  #include <api/fs/fs.h>
>>  #include <math.h>
>>  
>> +void perf_pmu__arch_init(struct perf_pmu *pmu)
>> +{
>> +	if (!strcmp(pmu->name, "arm_spe_0"))
>> +		pmu->mem_events = perf_mem_events_arm;
> 
> This is not right and it should cause building failure on aarch64.
> 
> aarch64 reuses aarch32's file arch/arm/util/pmu.c, and this file has
> already defined perf_pmu__arch_init(), you should add above change in
> the file arch/arm/util/pmu.c.
> 

Sure.

> Now I cannot access a machine for testing Arm SPE, but I will play
> a bit for this patch set to ensure it can pass compilation.  After
> that, I will seek Arm maintainers/reviewers help for the test.
>

Thanks. I guess I will hold the v3 until the test is done in case there
are other issues found in ARM.

Thanks,
Kan


From olteanv at gmail.com  Fri Dec  8 10:46:52 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Fri, 8 Dec 2023 20:46:52 +0200
Subject: [PATCH net-next 07/15] net: dsa: mt7530: do not run
 mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <9b729dab-aebc-4c0c-a5e1-164845cd0948@suswa.mountain>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-8-arinc.unal@arinc9.com>
 <20231121185358.GA16629@kernel.org>
 <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
 <90fde560-054e-4188-b15c-df2e082d3e33@moroto.mountain>
 <20231207184015.u7uoyfhdxiyuw6hh@skbuf>
 <9b729dab-aebc-4c0c-a5e1-164845cd0948@suswa.mountain>
Message-ID: <20231208184652.k2max4kf7r3fgksg@skbuf>

On Fri, Dec 08, 2023 at 07:23:38AM +0300, Dan Carpenter wrote:
> On Thu, Dec 07, 2023 at 08:40:15PM +0200, Vladimir Oltean wrote:
> > 
> > We could be more pragmatic about this whole sparse false positive warning,
> > and just move the "if" block which calls mt7530_setup_port5() right
> > after the priv->p5_intf_sel assignments, instead of waiting to "break;"
> > from the for_each_child_of_node() loop.
> > 
> > for_each_child_of_node(dn, mac_np) {
> > 	if (!of_device_is_compatible(mac_np,
> > 				     "mediatek,eth-mac"))
> > 		continue;
> > 
> > 	ret = of_property_read_u32(mac_np, "reg", &id);
> > 	if (ret < 0 || id != 1)
> > 		continue;
> > 
> > 	phy_node = of_parse_phandle(mac_np, "phy-handle", 0);
> > 	if (!phy_node)
> > 		continue;
> > 
> > 	if (phy_node->parent == priv->dev->of_node->parent) {
> > 		ret = of_get_phy_mode(mac_np, &interface);
> > 		if (ret && ret != -ENODEV) {
> > 			of_node_put(mac_np);
> > 			of_node_put(phy_node);
> > 			return ret;
> > 		}
> > 		id = of_mdio_parse_addr(ds->dev, phy_node);
> > 		if (id == 0)
> > 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P0;
> > 		if (id == 4)
> > 			priv->p5_intf_sel = P5_INTF_SEL_PHY_P4;
> > 
> > 		if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 || <---- here
> > 		    priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
> > 			mt7530_setup_port5(ds, interface);
> 
> This doesn't solve the problem that Smatch doesn't know what the
> original value of priv->p5_intf_sel.  And also I don't like this code
> because now we call mt7530_setup_port5() on every iteration after
> we find the first P5_INTF_SEL_PHY_P0.

You seem to have not parsed the "break" from 4 lines below. There is at
most one iteration through for_each_child_of_node().

And why would the "original" value of priv->p5_intf_sel matter? Original
or modified by the "if (id == 0)" and "if (id == 4)" blocks, the code
has already executed the of_get_phy_mode(&interface) call, by the time
we reach the "if" that calls mt7530_setup_port5().

Hmm, maybe the problem, all along, was that we let the -ENODEV return
code from of_get_phy_mode() pass through? "interface" will really be
uninitialized in that case. It's not a false positive.

Instead of:

	ret = of_get_phy_mode(mac_np, &interface);
	if (ret && ret != -ENODEV) {
		...
		return ret;
	}

it should have been like this, to not complain:

	ret = of_get_phy_mode(mac_np, &interface);
	if (ret) {
		...
		return ret;
	}

> > 	}
> > 	of_node_put(mac_np);
> > 	of_node_put(phy_node);
> > 	break;
> > }


From u.kleine-koenig at pengutronix.de  Fri Dec  8 10:50:33 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 8 Dec 2023 19:50:33 +0100
Subject: [PATCH v4 000/115] pwm: Fix lifetime issues for pwm_chips
In-Reply-To: <ZXM4CdJxg-XrYhkn@orome.fritz.box>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
 <ZXM4CdJxg-XrYhkn@orome.fritz.box>
Message-ID: <20231208185033.e6ty2cajcfle6dgk@pengutronix.de>

Hello Thierry,

On Fri, Dec 08, 2023 at 04:41:39PM +0100, Thierry Reding wrote:
> On Wed, Dec 06, 2023 at 12:43:14PM +0100, Uwe Kleine-K?nig wrote:
> > This series is based on Thierry's for-next.
> > 
> > It starts with some cleanups that were all sent out separately already:
> > 
> >  - "pwm: Reduce number of pointer dereferences in pwm_device_request()"
> >    https://lore.kernel.org/linux-pwm/20231130072105.966848-1-u.kleine-koenig at pengutronix.de
> >  - "pwm: crc: Use consistent variable naming for driver data"
> >    https://lore.kernel.org/linux-pwm/20231130074133.969806-1-u.kleine-koenig at pengutronix.de
> >  - Two leds/qcom-lpg patches
> >    https://lore.kernel.org/linux-leds/20231126095230.683204-1-u.kleine-koenig at pengutronix.de
> >    Lee already claimed to have taken the series already, but it's not yet in
> >    next.
> >  - "leds: qcom-lpg: Introduce a wrapper for getting driver data from a pwm chip"
> >    https://lore.kernel.org/linux-leds/20231124215208.616551-3-u.kleine-koenig at pengutronix.de
> > 
> > In the following patches I changed:
> > 
> >  - "pwm: cros-ec: Change prototype of helper to prepare further changes" +
> >    This was simplified in response to feedback by Tzung-Bi Shih
> >  - Make pwmchip_priv() static (and don't export it), let drivers use a new
> >    pwmchip_get_drvdata() instead.
> >  - For drm/ti-sn65dsi86.c and leds/qcom-lpg make use of
> >    pwmchip_set_drvdata() which makes the conversion to
> >    devm_pwmchip_alloc() much prettier.
> >  - Some cleanups here and there
> >  - Add review tags received in v3
> >    I kept all tags even though the pwmchip_alloc() patches changed
> >    slightly. Most of the time that's only
> >    s/pwmchip_priv/pwmchip_get_drvdata/ though. Still, if you object,
> >    just tell me. (This affects Paul Cercueil on patch #68, Conor Dooley
> >    on patch #76 and Greg for patch #109.)
> > 
> > I kept the pwmchip_alloc() + pwmchip_register() approach despite Bart
> > not liking it. To balance that out I don't like Bart's alternative
> > approach. There are no technically relevant differences between the two
> > approaches and no benchmarks that show either of the two to be better
> > than the other. Conceptually the design ideas around pwmchip_alloc() +
> > pwmchip_register() are used in several other subsystems, so it's a
> > proven way to do things.
> 
> [Trimming the recipients, keeping only Bart and the mailing lists.]
> 
> I do think there are technically relevant differences. For one, the
> better we isolate the internal data structure, the easier this becomes
> to manage. I'm attaching a patch that I've prototyped which should
> basically get us to somewhere around patch 110 of this series but with
> something like 1/8th of the changes. It doesn't need every driver to
> change and (mostly) decouples driver code from the core code.

You don't need to touch all drivers because you didn't change struct
pwm_chip::dev yet. (If you really want, you don't need to change that,
but then you have some duplication as chip->dev holds the same value as
priv->dev.parent in the end.)

> Now, I know that you think this is all bad because it's not a single
> allocation, but I much prefer the end result because it's got the driver
> and internals much more cleanly separated. Going forward I think it
> would be easier to apply all the ref-counting on top of that because we
> only need to keep the PWM framework-internal data structure alive after
> a PWM chip has gone away.

Nearly all drivers need driver private data. Isn't it a nice service by
the pwm core to make handling this private data easier for the lowlevel
drivers?

> From 72ea79887d96850f9ccc832ce52b907ca276c940 Mon Sep 17 00:00:00 2001
> From: Thierry Reding <thierry.reding at gmail.com>
> Date: Tue, 28 Nov 2023 15:42:39 +0100
> Subject: [PATCH] pwm: Isolate internal data into a separate structure
> 
> In order to prepare for proper reference counting of PWM chips and PWM
> devices, move the internal data from the public PWM chip to a private
> PWM chip structure. This ensures that the data that the subsystem core
> may need to reference later on can stick around beyond the lifetime of
> the driver-private data.
> 
> Signed-off-by: Thierry Reding <thierry.reding at gmail.com>
> ---
>  drivers/pwm/core.c            | 185 +++++++++++++++++++++-------------
>  drivers/pwm/internal.h        |  38 +++++++
>  drivers/pwm/pwm-atmel-hlcdc.c |   8 +-
>  drivers/pwm/pwm-fsl-ftm.c     |   6 +-
>  drivers/pwm/pwm-lpc18xx-sct.c |   4 +-
>  drivers/pwm/pwm-lpss.c        |  14 +--
>  drivers/pwm/pwm-pca9685.c     |   6 +-
>  drivers/pwm/pwm-samsung.c     |   6 +-
>  drivers/pwm/pwm-sifive.c      |   4 +-
>  drivers/pwm/pwm-stm32-lp.c    |   6 +-
>  drivers/pwm/pwm-stm32.c       |   6 +-
>  drivers/pwm/pwm-tiecap.c      |   6 +-
>  drivers/pwm/pwm-tiehrpwm.c    |   6 +-
>  drivers/pwm/sysfs.c           |  48 ++++-----
>  include/linux/pwm.h           |  26 +----
>  15 files changed, 228 insertions(+), 141 deletions(-)
>  create mode 100644 drivers/pwm/internal.h
> 
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index f60b715abe62..54d57dec6dce 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -24,17 +24,19 @@
>  #define CREATE_TRACE_POINTS
>  #include <trace/events/pwm.h>
>  
> +#include "internal.h"
> +
>  static DEFINE_MUTEX(pwm_lookup_lock);
>  static LIST_HEAD(pwm_lookup_list);
>  
> -/* protects access to pwmchip_idr */
> +/* protects access to pwm_chips */
>  static DEFINE_MUTEX(pwm_lock);
>  
> -static DEFINE_IDR(pwmchip_idr);
> +static DEFINE_IDR(pwm_chips);

That's an unrelated change.

>  static struct pwm_chip *pwmchip_find_by_name(const char *name)
>  {
> -	struct pwm_chip *chip;
> +	struct pwm_chip_private *priv;
>  	unsigned long id, tmp;
>  
>  	if (!name)
> @@ -42,12 +44,12 @@ static struct pwm_chip *pwmchip_find_by_name(const char *name)
>  
>  	mutex_lock(&pwm_lock);
>  
> -	idr_for_each_entry_ul(&pwmchip_idr, chip, tmp, id) {
> -		const char *chip_name = dev_name(chip->dev);
> +	idr_for_each_entry_ul(&pwm_chips, priv, tmp, id) {
> +		const char *chip_name = dev_name(priv->chip->dev);

two pointer dereferences instead of one before.

>  		if (chip_name && strcmp(chip_name, name) == 0) {
>  			mutex_unlock(&pwm_lock);
> -			return chip;
> +			return priv->chip;

one pointer reference instead of none before.

>  		}
>  	}
>  
> @@ -58,23 +60,24 @@ static struct pwm_chip *pwmchip_find_by_name(const char *name)
>  
>  static int pwm_device_request(struct pwm_device *pwm, const char *label)
>  {
> +	struct pwm_chip *chip = pwm->priv->chip;

With my approach getting the chip of a struct pwm_device is only one
pointer dereference away. You need two.

>  	int err;
>  
>  	if (test_bit(PWMF_REQUESTED, &pwm->flags))
>  		return -EBUSY;
>  
> -	if (!try_module_get(pwm->chip->owner))
> +	if (!try_module_get(pwm->priv->owner))
>  		return -ENODEV;
>  
> -	if (pwm->chip->ops->request) {
> -		err = pwm->chip->ops->request(pwm->chip, pwm);
> +	if (chip->ops->request) {
> +		err = chip->ops->request(chip, pwm);

You seem to have reimplemented half of
https://lore.kernel.org/linux-pwm/20231130072105.966848-1-u.kleine-koenig at pengutronix.de
here.

>  		if (err) {
> -			module_put(pwm->chip->owner);
> +			module_put(pwm->priv->owner);
>  			return err;
>  		}
>  	}
>  
> -	if (pwm->chip->ops->get_state) {
> +	if (chip->ops->get_state) {
>  		/*
>  		 * Zero-initialize state because most drivers are unaware of
>  		 * .usage_power. The other members of state are supposed to be
> @@ -84,7 +87,7 @@ static int pwm_device_request(struct pwm_device *pwm, const char *label)
>  		 */
>  		struct pwm_state state = { 0, };
>  
> -		err = pwm->chip->ops->get_state(pwm->chip, pwm, &state);
> +		err = chip->ops->get_state(chip, pwm, &state);
>  		trace_pwm_get(pwm, &state, err);
>  
>  		if (!err)
> @@ -196,6 +199,64 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
>  	return true;
>  }
>  
> +static struct pwm_chip_private *pwmchip_alloc(struct pwm_chip *chip,
> +					      struct module *owner)
> +{
> +	struct pwm_chip_private *priv;
> +	struct pwm_device *pwm;
> +	unsigned int i;
> +	int err;
> +
> +	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return ERR_PTR(-ENOMEM);
> +
> +	priv->pwms = kcalloc(chip->npwm, sizeof(*pwm), GFP_KERNEL);
> +	if (!priv->pwms) {
> +		err = -ENOMEM;
> +		goto free;
> +	}

Oh, so you don't use one additional allocation but two.

> +	priv->owner = owner;
> +	priv->chip = chip;
> +
> +	for (i = 0; i < chip->npwm; i++) {
> +		struct pwm_device *pwm = &priv->pwms[i];
> +
> +		pwm->priv = priv;
> +		pwm->hwpwm = i;
> +	}
> +
> +	mutex_lock(&pwm_lock);
> +
> +	err = idr_alloc(&pwm_chips, priv, 0, 0, GFP_KERNEL);
> +	if (err < 0) {
> +		mutex_unlock(&pwm_lock);
> +		goto free;
> +	}
> +
> +	mutex_unlock(&pwm_lock);
> +
> +	priv->id = err;
> +
> +	return priv;
> +
> +free:
> +	kfree(priv->pwms);
> +	kfree(priv);
> +	return ERR_PTR(err);
> +}
> +
> +static void pwmchip_free(struct pwm_chip_private *priv)
> +{
> +	mutex_lock(&pwm_lock);
> +	idr_remove(&pwm_chips, priv->id);
> +	mutex_unlock(&pwm_lock);
> +
> +	kfree(priv->pwms);
> +	kfree(priv);
> +}
> +
>  /**
>   * __pwmchip_add() - register a new PWM chip
>   * @chip: the PWM chip to add
> @@ -208,8 +269,7 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
>   */
>  int __pwmchip_add(struct pwm_chip *chip, struct module *owner)
>  {
> -	unsigned int i;
> -	int ret;
> +	struct pwm_chip_private *priv;
>  
>  	if (!chip || !chip->dev || !chip->ops || !chip->npwm)
>  		return -EINVAL;
> @@ -217,36 +277,16 @@ int __pwmchip_add(struct pwm_chip *chip, struct module *owner)
>  	if (!pwm_ops_check(chip))
>  		return -EINVAL;
>  
> -	chip->owner = owner;
> -
> -	chip->pwms = kcalloc(chip->npwm, sizeof(*chip->pwms), GFP_KERNEL);
> -	if (!chip->pwms)
> +	priv = pwmchip_alloc(chip, owner);
> +	if (!priv)
>  		return -ENOMEM;
>  
> -	mutex_lock(&pwm_lock);
> -
> -	ret = idr_alloc(&pwmchip_idr, chip, 0, 0, GFP_KERNEL);
> -	if (ret < 0) {
> -		mutex_unlock(&pwm_lock);
> -		kfree(chip->pwms);
> -		return ret;
> -	}
> -
> -	chip->id = ret;
> -
> -	for (i = 0; i < chip->npwm; i++) {
> -		struct pwm_device *pwm = &chip->pwms[i];
> -
> -		pwm->chip = chip;
> -		pwm->hwpwm = i;
> -	}
> -
> -	mutex_unlock(&pwm_lock);
> +	chip->priv = priv;
>  
>  	if (IS_ENABLED(CONFIG_OF))
>  		of_pwmchip_add(chip);
>  
> -	pwmchip_sysfs_export(chip);
> +	pwmchip_sysfs_export(priv);
>  
>  	return 0;
>  }
> @@ -260,18 +300,14 @@ EXPORT_SYMBOL_GPL(__pwmchip_add);
>   */
>  void pwmchip_remove(struct pwm_chip *chip)
>  {
> -	pwmchip_sysfs_unexport(chip);
> -
> -	if (IS_ENABLED(CONFIG_OF))
> -		of_pwmchip_remove(chip);
> -
>  	mutex_lock(&pwm_lock);
>  
> -	idr_remove(&pwmchip_idr, chip->id);
> +	pwmchip_sysfs_unexport(chip->priv);
>  
> -	mutex_unlock(&pwm_lock);
> +	if (IS_ENABLED(CONFIG_OF))
> +		of_pwmchip_remove(chip);
>  
> -	kfree(chip->pwms);
> +	pwmchip_free(chip->priv);
>  }
>  EXPORT_SYMBOL_GPL(pwmchip_remove);
>  
> @@ -315,7 +351,7 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
>  		return ERR_PTR(-EINVAL);
>  
>  	mutex_lock(&pwm_lock);
> -	pwm = &chip->pwms[index];
> +	pwm = &chip->priv->pwms[index];

two pointer dereferences instead of one before.

>  	err = pwm_device_request(pwm, label);
>  	if (err < 0)
> @@ -329,9 +365,9 @@ EXPORT_SYMBOL_GPL(pwm_request_from_chip);
>  static void pwm_apply_state_debug(struct pwm_device *pwm,
>  				  const struct pwm_state *state)
>  {
> -	struct pwm_state *last = &pwm->last;
> -	struct pwm_chip *chip = pwm->chip;
> +	struct pwm_chip *chip = pwm->priv->chip;
>  	struct pwm_state s1 = { 0 }, s2 = { 0 };
> +	struct pwm_state *last = &pwm->last;
>  	int err;
>  
>  	if (!IS_ENABLED(CONFIG_PWM_DEBUG))
> @@ -439,7 +475,6 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
>   */
>  int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
>  {
> -	struct pwm_chip *chip;
>  	int err;
>  
>  	/*
> @@ -455,8 +490,6 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
>  	    state->duty_cycle > state->period)
>  		return -EINVAL;
>  
> -	chip = pwm->chip;
> -
>  	if (state->period == pwm->state.period &&
>  	    state->duty_cycle == pwm->state.duty_cycle &&
>  	    state->polarity == pwm->state.polarity &&
> @@ -464,7 +497,7 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
>  	    state->usage_power == pwm->state.usage_power)
>  		return 0;
>  
> -	err = chip->ops->apply(chip, pwm, state);
> +	err = pwm->priv->chip->ops->apply(pwm->priv->chip, pwm, state);

four pointer dereferences instead of two before.

>  	trace_pwm_apply(pwm, state, err);
>  	if (err)
>  		return err;
> @@ -492,16 +525,19 @@ EXPORT_SYMBOL_GPL(pwm_apply_state);
>  int pwm_capture(struct pwm_device *pwm, struct pwm_capture *result,
>  		unsigned long timeout)
>  {
> +	struct pwm_chip *chip;
>  	int err;
>  
> -	if (!pwm || !pwm->chip->ops)
> +	if (!pwm)
>  		return -EINVAL;
>  
> -	if (!pwm->chip->ops->capture)
> +	chip = pwm->priv->chip;

One pointer deference more than before (assuming sensible compilation).

> +	if (!chip || !chip->ops || !chip->ops->capture)
>  		return -ENOSYS;

Changing the return code for !chip->ops isn't intended, is it?

>  	mutex_lock(&pwm_lock);
> -	err = pwm->chip->ops->capture(pwm->chip, pwm, result, timeout);
> +	err = chip->ops->capture(chip, pwm, result, timeout);
>  	mutex_unlock(&pwm_lock);
>  
>  	return err;
> @@ -566,16 +602,19 @@ EXPORT_SYMBOL_GPL(pwm_adjust_config);
>  
>  static struct pwm_chip *fwnode_to_pwmchip(struct fwnode_handle *fwnode)
>  {
> -	struct pwm_chip *chip;
> +	struct pwm_chip_private *priv;
>  	unsigned long id, tmp;
>  
>  	mutex_lock(&pwm_lock);
>  
> -	idr_for_each_entry_ul(&pwmchip_idr, chip, tmp, id)
> +	idr_for_each_entry_ul(&pwm_chips, priv, tmp, id) {
> +		struct pwm_chip *chip = priv->chip;
> +

One pointer dereference more per iteration than before.

>  		if (chip->dev && device_match_fwnode(chip->dev, fwnode)) {
>  			mutex_unlock(&pwm_lock);
>  			return chip;
>  		}
> +	}
>  
>  	mutex_unlock(&pwm_lock);
>  
> @@ -585,6 +624,7 @@ static struct pwm_chip *fwnode_to_pwmchip(struct fwnode_handle *fwnode)
>  static struct device_link *pwm_device_link_add(struct device *dev,
>  					       struct pwm_device *pwm)
>  {
> +	struct pwm_chip *chip = pwm->priv->chip;
>  	struct device_link *dl;
>  
>  	if (!dev) {
> @@ -593,15 +633,15 @@ static struct device_link *pwm_device_link_add(struct device *dev,
>  		 * impact the PM sequence ordering: the PWM supplier may get
>  		 * suspended before the consumer.
>  		 */
> -		dev_warn(pwm->chip->dev,
> +		dev_warn(chip->dev,

One pointer deference more than before (assuming sensible compilation).

>  			 "No consumer device specified to create a link to\n");
>  		return NULL;
>  	}
>  
> -	dl = device_link_add(dev, pwm->chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
> +	dl = device_link_add(dev, chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
>  	if (!dl) {
>  		dev_err(dev, "failed to create device link to %s\n",
> -			dev_name(pwm->chip->dev));
> +			dev_name(chip->dev));
>  		return ERR_PTR(-EINVAL);
>  	}
>  
> @@ -918,12 +958,12 @@ void pwm_put(struct pwm_device *pwm)
>  		goto out;
>  	}
>  
> -	if (pwm->chip->ops->free)
> -		pwm->chip->ops->free(pwm->chip, pwm);
> +	if (pwm->priv->chip->ops->free)
> +		pwm->priv->chip->ops->free(pwm->priv->chip, pwm);

One pointer deference more than before (assuming sensible compilation).

>  	pwm->label = NULL;
>  
> -	module_put(pwm->chip->owner);
> +	module_put(pwm->priv->owner);
>  out:
>  	mutex_unlock(&pwm_lock);
>  }
> @@ -997,12 +1037,12 @@ struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
>  EXPORT_SYMBOL_GPL(devm_fwnode_pwm_get);
>  
>  #ifdef CONFIG_DEBUG_FS
> -static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
> +static void pwm_dbg_show(struct pwm_chip_private *priv, struct seq_file *s)
>  {
>  	unsigned int i;
>  
> -	for (i = 0; i < chip->npwm; i++) {
> -		struct pwm_device *pwm = &chip->pwms[i];
> +	for (i = 0; i < priv->chip->npwm; i++) {
> +		struct pwm_device *pwm = &priv->pwms[i];
>  		struct pwm_state state;
>  
>  		pwm_get_state(pwm, &state);
> @@ -1035,7 +1075,7 @@ static void *pwm_seq_start(struct seq_file *s, loff_t *pos)
>  	mutex_lock(&pwm_lock);
>  	s->private = "";
>  
> -	ret = idr_get_next_ul(&pwmchip_idr, &id);
> +	ret = idr_get_next_ul(&pwm_chips, &id);
>  	*pos = id;
>  	return ret;
>  }
> @@ -1047,7 +1087,7 @@ static void *pwm_seq_next(struct seq_file *s, void *v, loff_t *pos)
>  
>  	s->private = "\n";
>  
> -	ret = idr_get_next_ul(&pwmchip_idr, &id);
> +	ret = idr_get_next_ul(&pwm_chips, &id);
>  	*pos = id;
>  	return ret;
>  }
> @@ -1059,15 +1099,16 @@ static void pwm_seq_stop(struct seq_file *s, void *v)
>  
>  static int pwm_seq_show(struct seq_file *s, void *v)
>  {
> -	struct pwm_chip *chip = v;
> +	struct pwm_chip_private *priv = v;
> +	struct pwm_chip *chip = priv->chip;

And another additional pointer dereference.

>  	seq_printf(s, "%s%d: %s/%s, %d PWM device%s\n",
> -		   (char *)s->private, chip->id,
> +		   (char *)s->private, priv->id,
>  		   chip->dev->bus ? chip->dev->bus->name : "no-bus",
>  		   dev_name(chip->dev), chip->npwm,
>  		   (chip->npwm != 1) ? "s" : "");
>  
> -	pwm_dbg_show(chip, s);
> +	pwm_dbg_show(priv, s);
>  
>  	return 0;
>  }
> diff --git a/drivers/pwm/internal.h b/drivers/pwm/internal.h
> new file mode 100644
> index 000000000000..44fffd3b6744
> --- /dev/null
> +++ b/drivers/pwm/internal.h
> @@ -0,0 +1,38 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef PWM_INTERNAL_H
> +#define PWM_INTERNAL_H
> +
> +#include <linux/list.h>

This is unused?

> +struct pwm_chip;
> +struct pwm_device;
> +
> +/**
> + * struct pwm_chip_private - subsystem-private PWM chip data
> + * @chip: driver-private PWM chip data
> + * @owner: module providing the chip
> + * @pwms: array of PWM devices allocated by the framework
> + * @base: number of first PWM controlled by this chip
> + */
> +struct pwm_chip_private {
> +	struct pwm_chip *chip;
> +	struct module *owner;
> +	struct pwm_device *pwms;
> +	unsigned int id;
> +};

With my approach the struct pwm_chip * pointer isn't needed because it's
all in one structure. So you have two structures where I only have one
and your two are bigger in sum than my single one (not counting memory
management overhead and alignment).

> +#ifdef CONFIG_PWM_SYSFS
> +void pwmchip_sysfs_export(struct pwm_chip_private *priv);
> +void pwmchip_sysfs_unexport(struct pwm_chip_private *priv);
> +#else
> +static inline void pwmchip_sysfs_export(struct pwm_chip_private *priv)
> +{
> +}
> +
> +static inline void pwmchip_sysfs_unexport(struct pwm_chip_private *priv)
> +{
> +}
> +#endif /* CONFIG_PWM_SYSFS */
> +
> +#endif /* PWM_INTERNAL_H */
> diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
> index 3f2c5031a3ba..6bbbfaa582c1 100644
> --- a/drivers/pwm/pwm-atmel-hlcdc.c
> +++ b/drivers/pwm/pwm-atmel-hlcdc.c
> @@ -15,6 +15,8 @@
>  #include <linux/pwm.h>
>  #include <linux/regmap.h>
>  
> +#include "internal.h"
> +
>  #define ATMEL_HLCDC_PWMCVAL_MASK	GENMASK(15, 8)
>  #define ATMEL_HLCDC_PWMCVAL(x)		(((x) << 8) & ATMEL_HLCDC_PWMCVAL_MASK)
>  #define ATMEL_HLCDC_PWMPOL		BIT(4)
> @@ -185,7 +187,7 @@ static int atmel_hlcdc_pwm_suspend(struct device *dev)
>  	struct atmel_hlcdc_pwm *atmel = dev_get_drvdata(dev);
>  
>  	/* Keep the periph clock enabled if the PWM is still running. */
> -	if (pwm_is_enabled(&atmel->chip.pwms[0]))
> +	if (pwm_is_enabled(&atmel->chip.priv->pwms[0]))

Didn't work so well to hide the internals of pwm_chip_private from the
drivers?

>  		clk_disable_unprepare(atmel->hlcdc->periph_clk);
>  
>  	return 0;
>  

[... a few more drivers where hiding the internals failed ...]

> diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> index 4edb994fa2e1..653df20afe1c 100644
> --- a/drivers/pwm/sysfs.c
> +++ b/drivers/pwm/sysfs.c
> @@ -14,6 +14,8 @@
>  #include <linux/kdev_t.h>
>  #include <linux/pwm.h>
>  
> +#include "internal.h"
> +
>  struct pwm_export {
>  	struct device child;
>  	struct pwm_device *pwm;
> @@ -311,7 +313,7 @@ static ssize_t export_store(struct device *parent,
>  			    struct device_attribute *attr,
>  			    const char *buf, size_t len)
>  {
> -	struct pwm_chip *chip = dev_get_drvdata(parent);
> +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
>  	struct pwm_device *pwm;
>  	unsigned int hwpwm;
>  	int ret;
> @@ -320,10 +322,10 @@ static ssize_t export_store(struct device *parent,
>  	if (ret < 0)
>  		return ret;
>  
> -	if (hwpwm >= chip->npwm)
> +	if (hwpwm >= priv->chip->npwm)

One more pointer dereference than before. You could trade that for some
data duplication by copying npwm to struct pwmchip_priv for the case
when you need .npwm but the chip is already gone.

>  		return -ENODEV;
>  
> -	pwm = pwm_request_from_chip(chip, hwpwm, "sysfs");
> +	pwm = pwm_request_from_chip(priv->chip, hwpwm, "sysfs");
>  	if (IS_ERR(pwm))
>  		return PTR_ERR(pwm);
>  
> @@ -339,7 +341,7 @@ static ssize_t unexport_store(struct device *parent,
>  			      struct device_attribute *attr,
>  			      const char *buf, size_t len)
>  {
> -	struct pwm_chip *chip = dev_get_drvdata(parent);
> +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
>  	unsigned int hwpwm;
>  	int ret;
>  
> @@ -347,10 +349,10 @@ static ssize_t unexport_store(struct device *parent,
>  	if (ret < 0)
>  		return ret;
>  
> -	if (hwpwm >= chip->npwm)
> +	if (hwpwm >= priv->chip->npwm)

One more pointer dereference than before.

>  		return -ENODEV;
>  
> -	ret = pwm_unexport_child(parent, &chip->pwms[hwpwm]);
> +	ret = pwm_unexport_child(parent, &priv->pwms[hwpwm]);
>  
>  	return ret ? : len;
>  }
> @@ -359,9 +361,9 @@ static DEVICE_ATTR_WO(unexport);
>  static ssize_t npwm_show(struct device *parent, struct device_attribute *attr,
>  			 char *buf)
>  {
> -	const struct pwm_chip *chip = dev_get_drvdata(parent);
> +	const struct pwm_chip_private *priv = dev_get_drvdata(parent);
>  
> -	return sysfs_emit(buf, "%u\n", chip->npwm);
> +	return sysfs_emit(buf, "%u\n", priv->chip->npwm);
>  }
>  static DEVICE_ATTR_RO(npwm);
>  
> @@ -411,12 +413,12 @@ static int pwm_class_apply_state(struct pwm_export *export,
>  
>  static int pwm_class_resume_npwm(struct device *parent, unsigned int npwm)
>  {
> -	struct pwm_chip *chip = dev_get_drvdata(parent);
> +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
>  	unsigned int i;
>  	int ret = 0;
>  
>  	for (i = 0; i < npwm; i++) {
> -		struct pwm_device *pwm = &chip->pwms[i];
> +		struct pwm_device *pwm = &priv->pwms[i];
>  		struct pwm_state state;
>  		struct pwm_export *export;
>  
> @@ -442,12 +444,12 @@ static int pwm_class_resume_npwm(struct device *parent, unsigned int npwm)
>  
>  static int pwm_class_suspend(struct device *parent)
>  {
> -	struct pwm_chip *chip = dev_get_drvdata(parent);
> +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
>  	unsigned int i;
>  	int ret = 0;
>  
> -	for (i = 0; i < chip->npwm; i++) {
> -		struct pwm_device *pwm = &chip->pwms[i];
> +	for (i = 0; i < priv->chip->npwm; i++) {
> +		struct pwm_device *pwm = &priv->pwms[i];
>  		struct pwm_state state;
>  		struct pwm_export *export;
>  
> @@ -483,9 +485,9 @@ static int pwm_class_suspend(struct device *parent)
>  
>  static int pwm_class_resume(struct device *parent)
>  {
> -	struct pwm_chip *chip = dev_get_drvdata(parent);
> +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
>  
> -	return pwm_class_resume_npwm(parent, chip->npwm);
> +	return pwm_class_resume_npwm(parent, priv->chip->npwm);

One more pointer dereference than before.

>  }
>  
>  static DEFINE_SIMPLE_DEV_PM_OPS(pwm_class_pm_ops, pwm_class_suspend, pwm_class_resume);
> @@ -501,7 +503,7 @@ static int pwmchip_sysfs_match(struct device *parent, const void *data)
>  	return dev_get_drvdata(parent) == data;
>  }
>  
> -void pwmchip_sysfs_export(struct pwm_chip *chip)
> +void pwmchip_sysfs_export(struct pwm_chip_private *priv)
>  {
>  	struct device *parent;
>  
> @@ -509,26 +511,26 @@ void pwmchip_sysfs_export(struct pwm_chip *chip)
>  	 * If device_create() fails the pwm_chip is still usable by
>  	 * the kernel it's just not exported.
>  	 */
> -	parent = device_create(&pwm_class, chip->dev, MKDEV(0, 0), chip,
> -			       "pwmchip%d", chip->id);
> +	parent = device_create(&pwm_class, priv->chip->dev, MKDEV(0, 0), priv,
> +			       "pwmchip%d", priv->id);
>  	if (IS_ERR(parent)) {
> -		dev_warn(chip->dev,
> +		dev_warn(priv->chip->dev,

One more pointer dereference than before.

>  			 "device_create failed for pwm_chip sysfs export\n");
>  	}
>  }

The TL;DR; is essentially what I already wrote in my last reply to Bart
in the v3 thread[1]:

 - My approach needs more changes to the individual drivers (which I
   don't consider a relevant disadvantage given that the resulting code
   is better);
 - My approach works with less pointer dereferences which IMHO also
   simplifies understanding the code as all relevant data is in a single
   place.
 - My approach has a weaker separation between the core and the lowlevel
   drivers. That's ok in my book given that this doesn't complicate the
   lowlevel drivers and that hiding details considerably better doesn't
   work anyhow (see the drivers that need internal.h in your patch).

For me the single allocation issue is only an added bonus. The relevant
advantage of my approach is that the code is easier and (probably) more
efficient.

Best regards
Uwe

[1] https://lore.kernel.org/linux-pwm/20231205093145.l7p52xtw2ak756ra at pengutronix.de


-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/250a0c0f/attachment-0001.sig>

From u.kleine-koenig at pengutronix.de  Fri Dec  8 11:06:20 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 8 Dec 2023 20:06:20 +0100
Subject: [PATCH] pwm: meson: Simplify using dev_err_probe()
In-Reply-To: <ZXM72QYBbb32Q_aL@orome.fritz.box>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
Message-ID: <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>

Hello Thierry,

On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> This is a lot of churn for very little gain.

We seem to have different conceptions of churn. Each hunk here is an
improvement for both SLOC count and usefulness of the generated error
message.

	failed to register somename: -5

is worse than

	error EIO: failed to register somename

, isn't it?

> None of these functions are ever going to return -EPROBE_DEFER. And
> yes, I know that function's doc says that it is "deemed acceptable to
> use" elsewhere. However, the existing error messages are just fine, no
> need to churn just for the sake of it.

We had this disagreement already before. Yes dev_err_probe() is useful
for three reasons and this driver only benefits from two of these.
That's IMHO still one reason more than needed to justify such a change.

And if you think that a function should only be used if all advantages
are useful for the caller, let us reconsider if we really need capture
support in the pwm framework as only two of the 68 drivers make use of
it.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/796b97f6/attachment.sig>

From linux at dominikbrodowski.net  Fri Dec  8 11:19:08 2023
From: linux at dominikbrodowski.net (Dominik Brodowski)
Date: Fri, 8 Dec 2023 20:19:08 +0100
Subject: [PATCH 0/7] pcmcia: Convert to platform remove callback
 returning void
In-Reply-To: <cover.1702051073.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702051073.git.u.kleine-koenig@pengutronix.de>
Message-ID: <ZXNsLJfqs9DLHb1Q@shine.dominikbrodowski.net>

Am Fri, Dec 08, 2023 at 05:08:05PM +0100 schrieb Uwe Kleine-K?nig:
> Hello,
> 
> this series changes all platform drivers in drivers/pcmcia to use the
> .remove_new() callback. See commit 5c5a7680e67b ("platform: Provide a
> remove callback that returns no value") for an extended explanation and
> the eventual goal.
> 
> All conversations are trivial, because all .remove() callbacks returned
> zero unconditionally already.
> 
> There are no interdependencies between these patches, so they could be
> picked up individually. However I'd expect them to go in all together.
> It's unclrear to me though, who will pick them up. Dominik? Greg?

Both options are fine with me. In the latter case:

	Acked-by: Dominik Brodowski <linux at dominikbrodowski.net>

Best
	Dominik


From claudiu.beznea at tuxon.dev  Fri Dec  8 11:23:11 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Fri, 8 Dec 2023 21:23:11 +0200
Subject: [PATCH] drivers: soc: atmel: Adjust defines to follow
 alphabetical order
In-Reply-To: <20231208170230.551265-1-Ryan.Wanner@microchip.com>
References: <20231208170230.551265-1-Ryan.Wanner@microchip.com>
Message-ID: <e062a92a-b82d-4d7e-8111-fa901067be57@tuxon.dev>

Hi, Ryan,

On 08.12.2023 19:02, Ryan.Wanner at microchip.com wrote:
> From: Ryan Wanner <Ryan.Wanner at microchip.com>
> 
> Move the defines so that they are in aphabetical order based on SOC.
> 
> Signed-off-by: Ryan Wanner <Ryan.Wanner at microchip.com>

This doesn't apply clean on top of v6.7-rc1. I guess it's related to SAM9X7
defines that are not yet in v6.7-rc1.

Thank you,
Claudiu Beznea

> ---
>  drivers/soc/atmel/soc.h | 30 +++++++++++++++---------------
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/soc/atmel/soc.h b/drivers/soc/atmel/soc.h
> index 26dd26b4f179..9b2d31073b88 100644
> --- a/drivers/soc/atmel/soc.h
> +++ b/drivers/soc/atmel/soc.h
> @@ -39,13 +39,13 @@ at91_soc_init(const struct at91_soc *socs);
>  #define AT91SAM9261_CIDR_MATCH		0x019703a0
>  #define AT91SAM9263_CIDR_MATCH		0x019607a0
>  #define AT91SAM9G20_CIDR_MATCH		0x019905a0
> -#define AT91SAM9RL64_CIDR_MATCH		0x019b03a0
>  #define AT91SAM9G45_CIDR_MATCH		0x019b05a0
> -#define AT91SAM9X5_CIDR_MATCH		0x019a05a0
>  #define AT91SAM9N12_CIDR_MATCH		0x019a07a0
> +#define AT91SAM9RL64_CIDR_MATCH		0x019b03a0
> +#define AT91SAM9X5_CIDR_MATCH		0x019a05a0
>  #define SAM9X60_CIDR_MATCH		0x019b35a0
> -#define SAMA7G5_CIDR_MATCH		0x00162100
>  #define SAM9X7_CIDR_MATCH		0x09750020
> +#define SAMA7G5_CIDR_MATCH		0x00162100
>  
>  #define AT91SAM9M11_EXID_MATCH		0x00000001
>  #define AT91SAM9M10_EXID_MATCH		0x00000002
> @@ -62,19 +62,15 @@ at91_soc_init(const struct at91_soc *socs);
>  #define AT91SAM9N12_EXID_MATCH		0x00000006
>  #define AT91SAM9CN11_EXID_MATCH		0x00000009
>  
> +#define AT91SAM9XE128_CIDR_MATCH	0x329973a0
> +#define AT91SAM9XE256_CIDR_MATCH	0x329a93a0
> +#define AT91SAM9XE512_CIDR_MATCH	0x329aa3a0
> +
>  #define SAM9X60_EXID_MATCH		0x00000000
>  #define SAM9X60_D5M_EXID_MATCH		0x00000001
>  #define SAM9X60_D1G_EXID_MATCH		0x00000010
>  #define SAM9X60_D6K_EXID_MATCH		0x00000011
>  
> -#define SAMA7G51_EXID_MATCH		0x3
> -#define SAMA7G52_EXID_MATCH		0x2
> -#define SAMA7G53_EXID_MATCH		0x1
> -#define SAMA7G54_EXID_MATCH		0x0
> -#define SAMA7G54_D1G_EXID_MATCH		0x00000018
> -#define SAMA7G54_D2G_EXID_MATCH		0x00000020
> -#define SAMA7G54_D4G_EXID_MATCH		0x00000028
> -
>  #define SAM9X75_EXID_MATCH		0x00000000
>  #define SAM9X72_EXID_MATCH		0x00000004
>  #define SAM9X70_EXID_MATCH		0x00000005
> @@ -83,10 +79,6 @@ at91_soc_init(const struct at91_soc *socs);
>  #define SAM9X75_D1M_EXID_MATCH		0x00000003
>  #define SAM9X75_D2G_EXID_MATCH		0x00000006
>  
> -#define AT91SAM9XE128_CIDR_MATCH	0x329973a0
> -#define AT91SAM9XE256_CIDR_MATCH	0x329a93a0
> -#define AT91SAM9XE512_CIDR_MATCH	0x329aa3a0
> -
>  #define SAMA5D2_CIDR_MATCH		0x0a5c08c0
>  #define SAMA5D21CU_EXID_MATCH		0x0000005a
>  #define SAMA5D225C_D1M_EXID_MATCH	0x00000053
> @@ -122,6 +114,14 @@ at91_soc_init(const struct at91_soc *socs);
>  #define SAMA5D43_EXID_MATCH		0x00000003
>  #define SAMA5D44_EXID_MATCH		0x00000004
>  
> +#define SAMA7G51_EXID_MATCH		0x3
> +#define SAMA7G52_EXID_MATCH		0x2
> +#define SAMA7G53_EXID_MATCH		0x1
> +#define SAMA7G54_EXID_MATCH		0x0
> +#define SAMA7G54_D1G_EXID_MATCH		0x00000018
> +#define SAMA7G54_D2G_EXID_MATCH		0x00000020
> +#define SAMA7G54_D4G_EXID_MATCH		0x00000028
> +
>  #define SAME70Q21_CIDR_MATCH		0x21020e00
>  #define SAME70Q21_EXID_MATCH		0x00000002
>  #define SAME70Q20_CIDR_MATCH		0x21020c00


From robh at kernel.org  Fri Dec  8 11:33:52 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 8 Dec 2023 13:33:52 -0600
Subject: [PATCH 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <bbb4262065cfc906f98165cac074e86dce19599e.1701793996.git.robin.murphy@arm.com>
References: <cover.1701793996.git.robin.murphy@arm.com>
 <bbb4262065cfc906f98165cac074e86dce19599e.1701793996.git.robin.murphy@arm.com>
Message-ID: <20231208193352.GA1865260-robh@kernel.org>

On Tue, Dec 05, 2023 at 04:51:57PM +0000, Robin Murphy wrote:
> Add a binding for implementations of the Arm CoreSight Performance
> Monitoring Unit Architecture. Not to be confused with CoreSight debug
> and trace, the PMU architecture defines a standard MMIO interface for
> event counters similar to the CPU PMU architecture, where the
> implementation and most of its features are discoverable through ID
> registers.

The implementation is separate from the CPU PMU rather than an MMIO view 
of it. Not really clear in my quick read of the spec.

> CC: Rob Herring <robh+dt at kernel.org>
> CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
> CC: Conor Dooley <conor+dt at kernel.org>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  .../bindings/perf/arm,coresight-pmu.yaml      | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
> new file mode 100644
> index 000000000000..12c7b28eee35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/perf/arm,coresight-pmu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Arm Coresight Performance Monitoring Unit Architecture
> +
> +maintainers:
> +  - Robin Murphy <robin.murphy at arm.com>
> +
> +properties:
> +  compatible:
> +    const: arm,coresight-pmu
> +
> +  reg:
> +    items:
> +      - description: Register page 0
> +      - description: Register page 1 (if dual-page extension implemented)
> +    minItems: 1
> +
> +  interrupts:
> +    items:
> +      - description: Overflow interrupt
> +
> +  cpus:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array

Don't need a type. Already defined.

> +    minItems: 1

1 is always the minimum.

> +    description: List of CPUs with which the PMU is associated, if applicable

When is it applicable? Presumably when it is associated with only a 
subset of CPUs?

> +
> +  arm,64-bit-atomic:
> +    type: boolean
> +    description: Register accesses are single-copy atomic at doubleword granularity

As this is recommended, shouldn't the property be the inverse.

Maybe the standard 'reg-io-width = <4>' would be sufficient here?

Rob


From krzysztof.kozlowski at linaro.org  Fri Dec  8 11:43:24 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 08 Dec 2023 20:43:24 +0100
Subject: [PATCH 0/3] ARM: dts: samsung: exynos4210-i9100 updates
In-Reply-To: <20231206221556.15348-1-paul@crapouillou.net>
References: <20231206221556.15348-1-paul@crapouillou.net>
Message-ID: <170206460423.126390.6462198989409881978.b4-ty@linaro.org>


On Wed, 06 Dec 2023 23:15:53 +0100, Paul Cercueil wrote:
> Here a small patchset with a fix and some improvements to the DTS for
> the Galaxy S2 (aka. i9100) phone.
> 
> The first patch unconditionally enables a regulator, which seems to be
> needed for the phone to boot properly. I do not know what it is
> connected to.
> 
> [...]

Applied, thanks!

[1/3] ARM: dts: samsung: exynos4210-i9100: Unconditionally enable LDO12
      https://git.kernel.org/krzk/linux/c/84228d5e29dbc7a6be51e221000e1d122125826c
[2/3] ARM: dts: samsung: exynos4210-i9100: Add node for touch keys
      https://git.kernel.org/krzk/linux/c/6e73b11062b2e3e873666ba35577437502cf1dd2
[3/3] ARM: dts: samsung: exynos4210-i9100: Add accelerometer node
      https://git.kernel.org/krzk/linux/c/50c7cdc9a4d2d21373c1ab52c131109ab30c53f5

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Fri Dec  8 11:44:21 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 8 Dec 2023 20:44:21 +0100
Subject: [PATCH 3/3] ARM: dts: samsung: exynos4210-i9100: Add
 accelerometer node
In-Reply-To: <20231206221556.15348-4-paul@crapouillou.net>
References: <20231206221556.15348-1-paul@crapouillou.net>
 <20231206221556.15348-4-paul@crapouillou.net>
Message-ID: <814c1c83-c058-49be-951a-55c24a9bd4f3@linaro.org>

On 06/12/2023 23:15, Paul Cercueil wrote:
> Add a Device Tree node for the ST Microelectronics "K3D" accelerometer
> chip found in the Galaxy S2.
> 
> Signed-off-by: Paul Cercueil <paul at crapouillou.net>
> ---
>  arch/arm/boot/dts/samsung/exynos4210-i9100.dts | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
> index f03b03dbe9f2..7e57fe033e2b 100644
> --- a/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
> +++ b/arch/arm/boot/dts/samsung/exynos4210-i9100.dts
> @@ -421,6 +421,23 @@ touchscreen at 4a {
>  	};
>  };
>  
> +&i2c_1 {

Fixed placement, so nodes are ordered. If it was not the case in your
DTS, it means you worked on some old tree, which should be avoided.
Please work on mainline.

Best regards,
Krzysztof



From Ryan.Wanner at microchip.com  Fri Dec  8 11:45:32 2023
From: Ryan.Wanner at microchip.com (Ryan.Wanner at microchip.com)
Date: Fri, 8 Dec 2023 12:45:32 -0700
Subject: [PATCH v2] drivers: soc: atmel: Adjust defines to follow aphabetical order
Message-ID: <20231208194532.579893-1-Ryan.Wanner@microchip.com>

From: Ryan Wanner <Ryan.Wanner at microchip.com>

Move the defines so that they are in aphabetical order based on SOC.

Signed-off-by: Ryan Wanner <Ryan.Wanner at microchip.com>
---
Changes from v1 -> v2:
- Remove defines that are not yet in v6.7.

 drivers/soc/atmel/soc.h | 38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/soc/atmel/soc.h b/drivers/soc/atmel/soc.h
index 7a9f47ce85fb..1f2af6f74160 100644
--- a/drivers/soc/atmel/soc.h
+++ b/drivers/soc/atmel/soc.h
@@ -39,10 +39,10 @@ at91_soc_init(const struct at91_soc *socs);
 #define AT91SAM9261_CIDR_MATCH		0x019703a0
 #define AT91SAM9263_CIDR_MATCH		0x019607a0
 #define AT91SAM9G20_CIDR_MATCH		0x019905a0
-#define AT91SAM9RL64_CIDR_MATCH		0x019b03a0
 #define AT91SAM9G45_CIDR_MATCH		0x019b05a0
-#define AT91SAM9X5_CIDR_MATCH		0x019a05a0
 #define AT91SAM9N12_CIDR_MATCH		0x019a07a0
+#define AT91SAM9RL64_CIDR_MATCH		0x019b03a0
+#define AT91SAM9X5_CIDR_MATCH		0x019a05a0
 #define SAM9X60_CIDR_MATCH		0x019b35a0
 #define SAMA7G5_CIDR_MATCH		0x00162100
 
@@ -61,23 +61,15 @@ at91_soc_init(const struct at91_soc *socs);
 #define AT91SAM9N12_EXID_MATCH		0x00000006
 #define AT91SAM9CN11_EXID_MATCH		0x00000009
 
+#define AT91SAM9XE128_CIDR_MATCH	0x329973a0
+#define AT91SAM9XE256_CIDR_MATCH	0x329a93a0
+#define AT91SAM9XE512_CIDR_MATCH	0x329aa3a0
+
 #define SAM9X60_EXID_MATCH		0x00000000
 #define SAM9X60_D5M_EXID_MATCH		0x00000001
 #define SAM9X60_D1G_EXID_MATCH		0x00000010
 #define SAM9X60_D6K_EXID_MATCH		0x00000011
 
-#define SAMA7G51_EXID_MATCH		0x3
-#define SAMA7G52_EXID_MATCH		0x2
-#define SAMA7G53_EXID_MATCH		0x1
-#define SAMA7G54_EXID_MATCH		0x0
-#define SAMA7G54_D1G_EXID_MATCH		0x00000018
-#define SAMA7G54_D2G_EXID_MATCH		0x00000020
-#define SAMA7G54_D4G_EXID_MATCH		0x00000028
-
-#define AT91SAM9XE128_CIDR_MATCH	0x329973a0
-#define AT91SAM9XE256_CIDR_MATCH	0x329a93a0
-#define AT91SAM9XE512_CIDR_MATCH	0x329aa3a0
-
 #define SAMA5D2_CIDR_MATCH		0x0a5c08c0
 #define SAMA5D21CU_EXID_MATCH		0x0000005a
 #define SAMA5D225C_D1M_EXID_MATCH	0x00000053
@@ -113,6 +105,14 @@ at91_soc_init(const struct at91_soc *socs);
 #define SAMA5D43_EXID_MATCH		0x00000003
 #define SAMA5D44_EXID_MATCH		0x00000004
 
+#define SAMA7G51_EXID_MATCH		0x3
+#define SAMA7G52_EXID_MATCH		0x2
+#define SAMA7G53_EXID_MATCH		0x1
+#define SAMA7G54_EXID_MATCH		0x0
+#define SAMA7G54_D1G_EXID_MATCH		0x00000018
+#define SAMA7G54_D2G_EXID_MATCH		0x00000020
+#define SAMA7G54_D4G_EXID_MATCH		0x00000028
+
 #define SAME70Q21_CIDR_MATCH		0x21020e00
 #define SAME70Q21_EXID_MATCH		0x00000002
 #define SAME70Q20_CIDR_MATCH		0x21020c00
@@ -127,6 +127,11 @@ at91_soc_init(const struct at91_soc *socs);
 #define SAMS70Q19_CIDR_MATCH		0x211d0a00
 #define SAMS70Q19_EXID_MATCH		0x00000002
 
+#define SAMV70Q20_CIDR_MATCH		0x21320c00
+#define SAMV70Q20_EXID_MATCH		0x00000002
+#define SAMV70Q19_CIDR_MATCH		0x213d0a00
+#define SAMV70Q19_EXID_MATCH		0x00000002
+
 #define SAMV71Q21_CIDR_MATCH		0x21220e00
 #define SAMV71Q21_EXID_MATCH		0x00000002
 #define SAMV71Q20_CIDR_MATCH		0x21220c00
@@ -134,9 +139,4 @@ at91_soc_init(const struct at91_soc *socs);
 #define SAMV71Q19_CIDR_MATCH		0x212d0a00
 #define SAMV71Q19_EXID_MATCH		0x00000002
 
-#define SAMV70Q20_CIDR_MATCH		0x21320c00
-#define SAMV70Q20_EXID_MATCH		0x00000002
-#define SAMV70Q19_CIDR_MATCH		0x213d0a00
-#define SAMV70Q19_EXID_MATCH		0x00000002
-
 #endif /* __AT91_SOC_H */
-- 
2.39.2



From andi.shyti at kernel.org  Fri Dec  8 12:04:25 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Fri, 8 Dec 2023 21:04:25 +0100
Subject: [PATCH v2 1/7] i2c: stm32f7: perform most of irq job in threaded
 handler
In-Reply-To: <20231208164719.3584028-2-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
 <20231208164719.3584028-2-alain.volmat@foss.st.com>
Message-ID: <20231208200425.zli2j6b4lt4shasn@zenone.zhora.eu>

Hi Alain,

On Fri, Dec 08, 2023 at 05:47:10PM +0100, Alain Volmat wrote:
> The irq handling is currently split between the irq handler
> and the threaded irq handler.  Some of the handling (such as
> dma related stuffs) done within the irq handler might sleep or
> take some time leading to issues if the kernel is built with
> realtime constraints.  In order to fix that, perform an overall
> rework to perform most of the job within the threaded handler
> and only keep fifo access in the non threaded handler.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>

quite a difficult review because this git diff algorithm makes it
difficult to read throuhg.

But it looks like just a copy paste from to
stm32f7_i2c_isr_event() to stm32f7_i2c_isr_event_thread() of the
STM32F7_I2C_ISR_NACKF, STM32F7_I2C_ISR_STOPF, STM32F7_I2C_ISR_TC
and STM32F7_I2C_ISR_TCR.

[...]

> +static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
> +{
> +	struct stm32f7_i2c_dev *i2c_dev = data;
> +	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
> +	struct stm32_i2c_dma *dma = i2c_dev->dma;
> +	void __iomem *base = i2c_dev->base;
> +	u32 status, mask;
> +	int ret;
> +
> +	if (!i2c_dev->master_mode)
> +		return stm32f7_i2c_slave_isr_event(i2c_dev);
> +
> +	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);

looks to me like this readl_relaxed is read too many times during
the whole irq handling.

Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Thanks,
Andi


From andi.shyti at kernel.org  Fri Dec  8 12:06:10 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Fri, 8 Dec 2023 21:06:10 +0100
Subject: [PATCH v2 2/7] i2c: stm32f7: simplify status messages in case of
 errors
In-Reply-To: <20231208164719.3584028-3-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
 <20231208164719.3584028-3-alain.volmat@foss.st.com>
Message-ID: <20231208200610.hrpup7ghhjtehcsc@zenone.zhora.eu>

Hi Alain,

On Fri, Dec 08, 2023 at 05:47:11PM +0100, Alain Volmat wrote:
> Avoid usage of __func__ when reporting an error message
> since dev_err/dev_dbg are already providing enough details
> to identify the source of the message.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>

Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Thanks,
Andi


From ahalaney at redhat.com  Fri Dec  8 12:20:27 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Fri, 8 Dec 2023 14:20:27 -0600
Subject: [PATCH net v3] net: stmmac: update Rx clk divider for 10M SGMII
In-Reply-To: <20231208062502.13124-1-quic_snehshah@quicinc.com>
References: <20231208062502.13124-1-quic_snehshah@quicinc.com>
Message-ID: <2yx7snbvbvjycuszzonmwxokr4pvqslz2bpy4eoyrri5tzlymb@t3t23x7eeknq>

On Fri, Dec 08, 2023 at 11:55:02AM +0530, Sneh Shah wrote:
> SGMII 10MBPS mode needs RX clock divider to avoid drops in Rx.
> Update configure SGMII function with rx clk divider programming.
> 
> Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")

You didn't add my:

    Tested-by: Andrew Halaney <ahalaney at redhat.com>

from the last version. Typically that's fine to do even if you post a
new version as long as the changes are minor (in your case it's just the
comment that was added since I tested, so definitely fine to do).

> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> ---
> v3 changelog:
> - Added comment to explain why MAC needs to be reconfigured for SGMII
> v2 changelog:
> - Use FIELD_PREP to prepare bifield values in place of GENMASK
> - Add fixes tag
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index d3bf42d0fceb..ab2245995bc6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -34,6 +34,7 @@
>  #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
>  #define RGMII_CONFIG_PROG_SWAP			BIT(1)
>  #define RGMII_CONFIG_DDR_MODE			BIT(0)
> +#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)
>  
>  /* SDCC_HC_REG_DLL_CONFIG fields */
>  #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
> @@ -598,6 +599,9 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>  	return 0;
>  }
>  
> +/* On interface toggle MAC registetrs gets reset.
> + * Configure MAC block for SGMII on ethernet phy link up
> + */

s/registetrs/registers/

>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  {
>  	int val;
> @@ -617,6 +621,9 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  	case SPEED_10:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> +		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
> +			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR, 0x31),
> +			      RGMII_IO_MACRO_CONFIG);
>  		break;
>  	}
>  
> -- 
> 2.17.1
> 



From kamal.dasu at broadcom.com  Fri Dec  8 12:21:07 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Fri,  8 Dec 2023 15:21:07 -0500
Subject: [PATCH 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
Message-ID: <20231208202108.7468-1-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

With newer sdio controller core used for 74165b0 we need to update
the compatibility with "brcm,bcm74165b0-sdhci".

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
---
 .../devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml          | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
index c028039bc477..cec9ff063794 100644
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
+++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
@@ -13,6 +13,11 @@ maintainers:
 properties:
   compatible:
     oneOf:
+      - items:
+          - enum:
+              - brcm,bcm74165b0-sdhci
+          - const: brcm,bcm74165-sdhci
+          - const: brcm,sdhci-brcmstb
       - items:
           - enum:
               - brcm,bcm7216-sdhci
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/ca8ae6f2/attachment-0001.p7s>

From kamal.dasu at broadcom.com  Fri Dec  8 12:21:08 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Fri,  8 Dec 2023 15:21:08 -0500
Subject: [PATCH 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231208202108.7468-1-kamal.dasu@broadcom.com>
References: <20231208202108.7468-1-kamal.dasu@broadcom.com>
Message-ID: <20231208202108.7468-2-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

74165b0 shall use a new sdio controller core version which
requires a different reset sequence. For core reset we use
sdhci_reset. For CMD and/or DATA reset added a new function
to also enable SDCHI clocks SDHCI_CLOCK_CARD_EN
SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
SDHCI_RESET_DATA fields.

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
---
 drivers/mmc/host/sdhci-brcmstb.c | 69 +++++++++++++++++++++++++++++---
 1 file changed, 64 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index c23251bb95f3..3fac471b5b5d 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -44,8 +44,13 @@ struct brcmstb_match_priv {
 
 static inline void enable_clock_gating(struct sdhci_host *host)
 {
+	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
 	u32 reg;
 
+	if (!(priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK))
+		return;
+
 	reg = sdhci_readl(host, SDHCI_VENDOR);
 	reg |= SDHCI_VENDOR_GATE_SDCLK_EN;
 	sdhci_writel(host, reg, SDHCI_VENDOR);
@@ -53,14 +58,54 @@ static inline void enable_clock_gating(struct sdhci_host *host)
 
 static void brcmstb_reset(struct sdhci_host *host, u8 mask)
 {
-	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
-
 	sdhci_and_cqhci_reset(host, mask);
 
 	/* Reset will clear this, so re-enable it */
-	if (priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK)
-		enable_clock_gating(host);
+	enable_clock_gating(host);
+}
+
+static void brcmstb_sdhci_reset_cmd_data(struct sdhci_host *host, u8 mask)
+{
+	ktime_t timeout;
+	u32 reg;
+	u32 new_mask = (mask &  (SDHCI_RESET_CMD | SDHCI_RESET_DATA)) << 24;
+
+	new_mask |= SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN;
+	reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
+	sdhci_writel(host, reg | new_mask, SDHCI_CLOCK_CONTROL);
+
+	/* Wait max 10 ms */
+	timeout = ktime_add_ms(ktime_get(), 10);
+
+	/* hw clears the bit when it's done */
+	while (1) {
+		bool timedout = ktime_after(ktime_get(), timeout);
+
+		if (!(sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask))
+			break;
+		if (timedout) {
+			pr_err("%s: Reset 0x%x never completed.\n",
+				mmc_hostname(host->mmc), (int)mask);
+			sdhci_err_stats_inc(host, CTRL_TIMEOUT);
+			sdhci_dumpregs(host);
+			return;
+		}
+		udelay(10);
+	}
+}
+
+static void brcmstb_reset_74165b0(struct sdhci_host *host, u8 mask)
+{
+	/* take care of RESET_ALL as usual */
+	if (mask & SDHCI_RESET_ALL)
+		sdhci_and_cqhci_reset(host, SDHCI_RESET_ALL);
+
+	/* cmd and/or data treated differently on this core */
+	if (mask & (SDHCI_RESET_CMD | SDHCI_RESET_DATA))
+		brcmstb_sdhci_reset_cmd_data(host, mask);
+
+	/* Reset will clear this, so re-enable it */
+	enable_clock_gating(host);
 }
 
 static void sdhci_brcmstb_hs400es(struct mmc_host *mmc, struct mmc_ios *ios)
@@ -162,6 +207,13 @@ static struct sdhci_ops sdhci_brcmstb_ops_7216 = {
 	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
 };
 
+static const struct sdhci_ops sdhci_brcmstb_ops_74165b0 = {
+	.set_clock = sdhci_brcmstb_set_clock,
+	.set_bus_width = sdhci_set_bus_width,
+	.reset = brcmstb_reset_74165b0,
+	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
+};
+
 static struct brcmstb_match_priv match_priv_7425 = {
 	.flags = BRCMSTB_MATCH_FLAGS_NO_64BIT |
 	BRCMSTB_MATCH_FLAGS_BROKEN_TIMEOUT,
@@ -179,10 +231,17 @@ static const struct brcmstb_match_priv match_priv_7216 = {
 	.ops = &sdhci_brcmstb_ops_7216,
 };
 
+static const struct brcmstb_match_priv match_priv_74165b0 = {
+	.flags = BRCMSTB_MATCH_FLAGS_HAS_CLOCK_GATE,
+	.hs400es = sdhci_brcmstb_hs400es,
+	.ops = &sdhci_brcmstb_ops_74165b0,
+};
+
 static const struct of_device_id __maybe_unused sdhci_brcm_of_match[] = {
 	{ .compatible = "brcm,bcm7425-sdhci", .data = &match_priv_7425 },
 	{ .compatible = "brcm,bcm7445-sdhci", .data = &match_priv_7445 },
 	{ .compatible = "brcm,bcm7216-sdhci", .data = &match_priv_7216 },
+	{ .compatible = "brcm,bcm74165b0-sdhci", .data = &match_priv_74165b0 },
 	{},
 };
 
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/6dcfe15f/attachment.p7s>

From robh at kernel.org  Fri Dec  8 12:24:36 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 8 Dec 2023 14:24:36 -0600
Subject: [PATCH 1/3] dt-bindings: arm: coresight: restrict single port
 subnodes
In-Reply-To: <20231206115332.22712-1-krzysztof.kozlowski@linaro.org>
References: <20231206115332.22712-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231208202436.GA2627018-robh@kernel.org>

On Wed, Dec 06, 2023 at 12:53:30PM +0100, Krzysztof Kozlowski wrote:
> "in-ports" and "out-ports" with single "port" subnode should use
> "additionalProperties: false" to disallow any other properties mentioned
> by graph schema which are not applicable for this case, e.g.
> "address-cells".

The graph schema should already check this case with this subschema:

    oneOf:
      - required:
          - port
      - required:
          - "#address-cells"
          - "#size-cells"

However, I now see this would allow port and #address-cells if 
#size-cells is omitted. (#address-cells is a dependency for 
##size-cells, but not vice-versa because interrupt-controllers can have 
##just #address-cells). Perhaps this should instead be:

    oneOf:
      - required:
          - port
      - anyOf:
	  - required:
              - "#address-cells"
	  - required:
              - "#size-cells"

We're missing a similar check on endpoint. Or I'm forgetting why I 
didn't add it.

I suspect there are a lot more cases if we fixed these in the users.

Rob


From robh at kernel.org  Fri Dec  8 12:25:08 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 8 Dec 2023 14:25:08 -0600
Subject: [PATCH 2/3] dt-bindings: arm: qcom,coresight-tpda: drop
 redundant type from ports
In-Reply-To: <20231206115332.22712-2-krzysztof.kozlowski@linaro.org>
References: <20231206115332.22712-1-krzysztof.kozlowski@linaro.org>
 <20231206115332.22712-2-krzysztof.kozlowski@linaro.org>
Message-ID: <170206710810.2645438.5895151737393865069.robh@kernel.org>


On Wed, 06 Dec 2023 12:53:31 +0100, Krzysztof Kozlowski wrote:
> "in-ports" and "out-ports" are defined by graph schema, so defining its
> type is redundant.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml | 2 --
>  1 file changed, 2 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Fri Dec  8 12:25:40 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 8 Dec 2023 14:25:40 -0600
Subject: [PATCH 3/3] dt-bindings: arm: qcom,coresight-tpda: fix
 indentation in the example
In-Reply-To: <20231206115332.22712-3-krzysztof.kozlowski@linaro.org>
References: <20231206115332.22712-1-krzysztof.kozlowski@linaro.org>
 <20231206115332.22712-3-krzysztof.kozlowski@linaro.org>
Message-ID: <170206713968.2646196.10411372196062019776.robh@kernel.org>


On Wed, 06 Dec 2023 12:53:32 +0100, Krzysztof Kozlowski wrote:
> Fix triple-space indentation to double-space in the example DTS.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  .../bindings/arm/qcom,coresight-tpda.yaml     | 32 +++++++++----------
>  1 file changed, 15 insertions(+), 17 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>



From krzysztof.kozlowski at linaro.org  Fri Dec  8 12:28:52 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 8 Dec 2023 21:28:52 +0100
Subject: [PATCH 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for
 74165b0
In-Reply-To: <20231208202108.7468-1-kamal.dasu@broadcom.com>
References: <20231208202108.7468-1-kamal.dasu@broadcom.com>
Message-ID: <12b3dce8-92c4-4084-9cc2-4e0d6432c6f3@linaro.org>

On 08/12/2023 21:21, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> With newer sdio controller core used for 74165b0 we need to update
> the compatibility with "brcm,bcm74165b0-sdhci".
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> ---
>  .../devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml          | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
> index c028039bc477..cec9ff063794 100644
> --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
> +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
> @@ -13,6 +13,11 @@ maintainers:
>  properties:
>    compatible:
>      oneOf:
> +      - items:
> +          - enum:
> +              - brcm,bcm74165b0-sdhci
> +          - const: brcm,bcm74165-sdhci

What is exactly the difference between bcm74165b0 and bcm74165? Your
driver does not use bcm74165, so I wonder what its purpose is.

Few days ago, for different patchset, I was asking "why", because the
motivation was not clear from the code. Here you said "we need to", but
I would argue: no you do not need to add bcm74165 if it means nothing,
thus this commit msg has similar problem. Does not answer why it is done
like this.

Best regards,
Krzysztof



From tglx at linutronix.de  Fri Dec  8 12:43:21 2023
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 08 Dec 2023 21:43:21 +0100
Subject: [PATCH 2/2] pinctrl: stm32: fix GPIO level interrupts
In-Reply-To: <20231204203357.2897008-3-ben.wolsieffer@hefring.com>
References: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>
 <20231204203357.2897008-3-ben.wolsieffer@hefring.com>
Message-ID: <87ttosqvbq.ffs@tglx>

Ben!

On Mon, Dec 04 2023 at 15:33, Ben Wolsieffer wrote:
> The STM32 doesn't support GPIO level interrupts in hardware, so the
> driver tries to emulate them using edge interrupts, by retriggering the
> interrupt if necessary based on the pin state after the handler
> finishes.
>
> Currently, this functionality does not work because the irqchip uses
> handle_edge_irq(), which doesn't run the irq_eoi() or irq_unmask()
> callbacks after handling the interrupt. This patch fixes this by using
> handle_level_irq() for level interrupts, which causes irq_unmask() to be
> called to retrigger the interrupt.

This does not make any sense at all. irq_unmask() does not retrigger
anything. It sets the corresponding bit in the mask register, not more
not less.

Switching to handle_level_irq() makes the following difference
vs. handle_edge_irq() when an interrupt is handled (ignoring the inner
loop):

      + irq_mask();
        irq_ack();
        ....
        handle();
        ....
      + irq_unmask();

So in both cases irq_ack() clears the interrupt in the Pending register,
right?

Now comes the interesting difference.

When the interrupt is raised again after irq_ack() while the handler is
running, i.e. a full toggle from active to inactive and back to active
where the back to active transition causes the edge detector to trigger,
then:

  1) in case of handle_edge_irq() this should immediately set it in the
     pending register again and raise another CPU interrupt, which
     should be handled once the interrupt service routine returned.

  2) in case of handle_level_irq() this does not set it in the pending
     register because it's masked. The unmask will set the pending
     register bit _if_ and only _if_ the edge detector has latched the
     detection. No idea whether that's the case. The manual is
     exceptionally blury about this.

So in theory both #1 and #2 should work. But the explanation in the
changelog is fairy tale material.

As I couldn't figure out why #1 would not work, I looked at the driver
in more detail and also at the STM32 manual. That tells me that the
irqchip driver is at least suboptimal. Why?

The EXTI controller is just an intermediate between the peripheral
(including GPIO pins) and the NVIC:

         |--------------|
         | Edge config  |   |-----------------|
 Source -|              |---| Int. Mask logic |---> Dedicated NVIC interrupt
         | Edge detect  | | |-----------------|
         |--------------| |
                          | |-----------------|   
                          |-| Evt. Mask logic |---> CPU event input
                          | |-----------------|   
                          |
                          | |-----------------|   
                          |-| Wakeup logic    |--->....
                            |-----------------|   

So there are two classes of sources conntect to EXTI:

   1) Direct events

      - Have a fixed edge
      - Can be masked for Interrupt and Event generation
      - No software trigger
      - Not tracked in the Pending register
      - Can evtl. wakeup the CPUs or from D3

   2) Configurable events

      - Have a configurable edge
      - Can be masked for Interrupt and Event generation
      - Software trigger
      - Tracked in the Pending register
      - Can evtl. wakeup the CPUs or from D3

The CPU event is a single input to the CPU which can be triggered by any
source which has the Event mask enabled.

For both classes there are sources which have no connection to the NVIC,
they can only be used to generate CPU events or trigger the wakeup
logic.

For direct events there is a category where the peripherial interrupt is
routed to both the EXTI and the NVIC directly. The EXTI does not provide
a connection to the NVIC and the event cannot be masked in EXTI to
prevent CPU interrupts. Only the CPU event masking works.

GPIO pins are configurable events which are connected to the NVIC via
the EXTI.

But the EXTI driver implements a chained interrupt handler which listens
on a ton of NVIC interrupts. I.e. for the STM32H7 on:

  <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <62>, <76>

NVIC   1: PVD_PVM           EXTI-SRC 16
NVIC   2: RTC_TAMP_STAMP    EXTI-SRC 18
NVIC   3: RTC_WAKEUP        EXTI-SRC 19
NVIC   6: EXTI0             EXTI-SRC  0
NVIC   7: EXTI1             EXTI-SRC  1
NVIC   8: EXTI2             EXTI-SRC  2
NVIC   9: EXTI3             EXTI-SRC  3
NVIC  10: EXTI4             EXTI-SRC  4
NVIC  23: EXTI5-9           EXTI-SRC  5-9
NVIC  40: EXTI10-15         EXTI-SRC 10-15
NVIC  41: RTC_ALARM         EXTI-SRC 17
NVIC  62: ETH_WKUP          EXTI-SRC 86
NVIC  76: OTG_HS_WKUP       EXTI-SRC 43

Each of these chained interrupts handles the full EXTI interrupt domain
with all three banks. This does not make any sense at all especially not
on a SMP machine.

Though it _should_ work, but it might cause interrupts handlers to be
invoked when nothing is pending when the edge handler is active. Which
in turn can confuse the underlying device driver depending on the
quality...

CPU0					CPU1

NVIC int X                      	NVIC int Y

 // read_pending() is serialized by a lock, but both read the same state
 pend = read_pending()			pend = read_pending()
 
 for_each_bit(bit, pend)	 	for_each_bit(bit, pend)	
    handle_irq(domain, base + bit)         handle_irq(domain, base + bit)
      lock(desc);                            lock(desc);
      ack();
      do {
         clear(PENDING);
         set(IN_PROGRESS);
         unlock(desc);
         handle();                           if (IN_PROGRESS) {
         lock(desc);                           ack();
                                               set(PENDING);
         				       unlock(desc);
         clear(IN_PROGRESS);                   return;
                                             }
      } while (PENDING); <- Will loop

See?

In fact the only NVIC interrupts which actually need demultiplexing are
NVIC #23 and NVIC #40 and those should only care about the EXTI
interrupts which are actually multiplexed on them. This let's randomly
run whatever is pending on any demux handler is far from correct.

All others are direct NVIC interrupts which just have the extra EXTI
interrupt masking, event masking and the wakeup magic. The indirection
via the chained handler is just pointless overhead and not necessarily
correct.

The exti_h variant of that driver does the right thing and installs a
hierarchical interrupt domain which acts as man in the middle between
the source and the NVIC. Though granted they don't have the odd problem
of multiplexing several GPIO interrupts to a single NVIC interrupt.

But in fact the regular exti driver could do the same and just handle
the two NVIC interrupts which need demultiplexing separately and let
everything else go through the hierarchy without bells and whistles.

Thanks,

        tglx


From robh at kernel.org  Fri Dec  8 12:55:45 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 8 Dec 2023 14:55:45 -0600
Subject: [PATCH 2/4] dt-bindings: imx6q-pcie: Add host-wake-gpio property
In-Reply-To: <83ca3d88cdaa7bc6e6bd3c4e88518b155a6b0f05.camel@pengutronix.de>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
 <20231208091355.1417292-3-sherry.sun@nxp.com>
 <83ca3d88cdaa7bc6e6bd3c4e88518b155a6b0f05.camel@pengutronix.de>
Message-ID: <20231208205545.GA2675840-robh@kernel.org>

On Fri, Dec 08, 2023 at 11:00:19AM +0100, Lucas Stach wrote:
> Hi Sherry,
> 
> Am Freitag, dem 08.12.2023 um 17:13 +0800 schrieb Sherry Sun:
> > Add host-wake-gpio property that can be used to wakeup the host
> > processor.
> > 
> > Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
> > Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
> > ---
> >  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > index 81bbb8728f0f..944f0f961809 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > @@ -72,6 +72,10 @@ properties:
> >        L=operation state) (optional required).
> >      type: boolean
> >  
> > +  host-wake-gpio:
> 
> There is only one wake signal in PCIe and it has a defined direction,
> so there is no point in specifying that it is a host wakeup. Also GPIO
> handles without a traling 's' are deprecated. So this should be
> 
> wake-gpios

Any standard PCI slot signals need to be documented in common PCI 
schema. And they should start going into root port nodes rather than the 
host bridge node because it's the root ports that correspond to slots 
rather than the host bridge. We've just taken shortcuts because many 
host bridges only have 1 root port.

Note that I'm in the middle of splitting pci-bus.yaml into host bridge, 
PCI-PCI bridge (and RP), and common device schemas.

Rob


From kamal.dasu at broadcom.com  Fri Dec  8 13:02:30 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Fri,  8 Dec 2023 16:02:30 -0500
Subject: [V2, 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
Message-ID: <20231208210230.8191-1-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

With newer sdio controller core used for 74165b0 we need to update
the compatibility with "brcm,bcm74165b0-sdhci".

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
---
 Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
index c028039bc477..178d47ed65ca 100644
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
+++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
@@ -13,6 +13,10 @@ maintainers:
 properties:
   compatible:
     oneOf:
+      - items:
+          - enum:
+              - brcm,bcm74165b0-sdhci
+          - const: brcm,sdhci-brcmstb
       - items:
           - enum:
               - brcm,bcm7216-sdhci
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231208/75321593/attachment-0001.p7s>

From jiangzp at google.com  Fri Dec  8 13:07:06 2023
From: jiangzp at google.com (Zhengping Jiang)
Date: Fri,  8 Dec 2023 13:07:06 -0800
Subject: [kernel PATCH v1] Bluetooth: btmtksdio: clear BTMTKSDIO_BT_WAKE_ENABLED
 after resume
Message-ID: <20231208130705.kernel.v1.1.Ic5024b3da99b11e39c247a5b8ba44876c18880a0@changeid>

Always clear BTMTKSDIO_BT_WAKE_ENABLED bit after resume. When Bluetooth
does not generate interrupts, the bit will not be cleared and causes
premature wakeup.

Fixes: 4ed924fc122f ("Bluetooth: btmtksdio: enable bluetooth wakeup in system suspend")
Signed-off-by: Zhengping Jiang <jiangzp at google.com>
---

Changes in v1:
- Clear BTMTKSDIO_BT_WAKE_ENABLED flag on resume

 drivers/bluetooth/btmtksdio.c    | 10 ++++++++++
 include/net/bluetooth/hci_core.h |  1 +
 net/bluetooth/hci_sync.c         |  2 ++
 3 files changed, 13 insertions(+)

diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
index ff4868c83cd8..8f00b71573c8 100644
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -1296,6 +1296,15 @@ static bool btmtksdio_sdio_inband_wakeup(struct hci_dev *hdev)
 	return device_may_wakeup(bdev->dev);
 }
 
+static void btmtksdio_disable_bt_wakeup(struct hci_dev *hdev)
+{
+	struct btmtksdio_dev *bdev = hci_get_drvdata(hdev);
+
+	if (!bdev)
+		return;
+	clear_bit(BTMTKSDIO_BT_WAKE_ENABLED, &bdev->tx_state);
+}
+
 static bool btmtksdio_sdio_wakeup(struct hci_dev *hdev)
 {
 	struct btmtksdio_dev *bdev = hci_get_drvdata(hdev);
@@ -1363,6 +1372,7 @@ static int btmtksdio_probe(struct sdio_func *func,
 	hdev->shutdown = btmtksdio_shutdown;
 	hdev->send     = btmtksdio_send_frame;
 	hdev->wakeup   = btmtksdio_sdio_wakeup;
+	hdev->clear_wakeup = btmtksdio_disable_bt_wakeup;
 	/*
 	 * If SDIO controller supports wake on Bluetooth, sending a wakeon
 	 * command is not necessary.
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 0c1754f416bd..4bbd55335269 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -672,6 +672,7 @@ struct hci_dev {
 	int (*get_codec_config_data)(struct hci_dev *hdev, __u8 type,
 				     struct bt_codec *codec, __u8 *vnd_len,
 				     __u8 **vnd_data);
+	void (*clear_wakeup)(struct hci_dev *hdev);
 };
 
 #define HCI_PHY_HANDLE(handle)	(handle & 0xff)
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 3563a90ed2ac..6c4d5ce40524 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -5947,6 +5947,8 @@ int hci_resume_sync(struct hci_dev *hdev)
 		return 0;
 
 	hdev->suspended = false;
+	if (hdev->clear_wakeup)
+		hdev->clear_wakeup(hdev);
 
 	/* Restore event mask */
 	hci_set_event_mask_sync(hdev);
-- 
2.43.0.472.g3155946c3a-goog



From cl at gentwo.org  Fri Dec  8 13:11:58 2023
From: cl at gentwo.org (Christoph Lameter (Ampere))
Date: Fri, 8 Dec 2023 13:11:58 -0800 (PST)
Subject: [PATCH] ARM64: Implement arch_report_meminfo()
Message-ID: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org>

X86 has information in /proc/meminfo showing the use of large mappings
for the kernel direct map. This has now also become important for
ARM since the kernel default CONFIG_RODATA_FULL_DEFAULT_ENABLED
forces 4K PTE use for the direct map and users may not be aware
of the performance impact of the increased TLB use etc.

The output of /proc/meminfo on ARM64 is then after this patch:

4K page size:

Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      155912 kB
CONT DMap4k:        1176 kB
DirectMap2M:      722944 kB
CONT DMap2M:       28672 kB
DirectMap1G:   534773760 kB

64K page size:

Hugepagesize:     524288 kB
Hugetlb:               0 kB
DirectMap64k:      882624 kB
CONT DMap64k:       19904 kB
DirectMap512M:    534773760 kB
CONT DMap512M:           0 kB
DirectMap4096G:           0 kB

Signed-off-by: Christoph Lameter <cl at linux.com>

Index: linux/arch/arm64/mm/mmu.c
===================================================================
--- linux.orig/arch/arm64/mm/mmu.c
+++ linux/arch/arm64/mm/mmu.c
@@ -66,6 +66,12 @@ u32 __boot_cpu_mode[] = { BOOT_CPU_MODE_
   */
  long __section(".mmuoff.data.write") __early_cpu_boot_status;

+static atomic_t nr_pte;
+static atomic_t nr_pmd;
+static atomic_t nr_pud;
+static atomic_t nr_pte_cont;
+static atomic_t nr_pmd_cont;
+
  /*
   * Empty_zero_page is a special page that is used for zero-initialized data
   * and COW.
@@ -179,6 +185,7 @@ static void init_pte(pmd_t *pmdp, unsign
  		pte_t old_pte = READ_ONCE(*ptep);

  		set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
+		atomic_inc(&nr_pte);

  		/*
  		 * After the PTE entry has been populated once, we
@@ -223,8 +230,10 @@ static void alloc_init_cont_pte(pmd_t *p

  		/* use a contiguous mapping if the range is suitably aligned */
  		if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
+		    (flags & NO_CONT_MAPPINGS) == 0) {
  			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+			atomic_inc(&nr_pte_cont);
+		}

  		init_pte(pmdp, addr, next, phys, __prot);

@@ -249,6 +258,7 @@ static void init_pmd(pud_t *pudp, unsign
  		if (((addr | next | phys) & ~PMD_MASK) == 0 &&
  		    (flags & NO_BLOCK_MAPPINGS) == 0) {
  			pmd_set_huge(pmdp, phys, prot);
+			atomic_inc(&nr_pmd);

  			/*
  			 * After the PMD entry has been populated once, we
@@ -301,8 +311,10 @@ static void alloc_init_cont_pmd(pud_t *p

  		/* use a contiguous mapping if the range is suitably aligned */
  		if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
+		    (flags & NO_CONT_MAPPINGS) == 0) {
  			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+			atomic_inc(&nr_pmd_cont);
+		}

  		init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);

@@ -346,7 +358,7 @@ static void alloc_init_pud(pgd_t *pgdp,
  		   ((addr | next | phys) & ~PUD_MASK) == 0 &&
  		    (flags & NO_BLOCK_MAPPINGS) == 0) {
  			pud_set_huge(pudp, phys, prot);
-
+			atomic_inc(&nr_pud);
  			/*
  			 * After the PUD entry has been populated once, we
  			 * only allow updates to the permission attributes.
@@ -1486,3 +1498,35 @@ void ptep_modify_prot_commit(struct vm_a
  {
  	set_pte_at(vma->vm_mm, addr, ptep, pte);
  }
+
+#ifdef CONFIG_PROC_FS
+void arch_report_meminfo(struct seq_file *m)
+{
+	unsigned long pagesize_in_kb = PAGE_SIZE / 1024;
+
+	seq_printf(m, "DirectMap%luk:    %8lu kB\n",
+			pagesize_in_kb,
+		  	(unsigned long)atomic_read(&nr_pte) * pagesize_in_kb);
+
+        seq_printf(m, "CONT DMap%luk:    %8lu kB\n",
+			pagesize_in_kb,
+			(unsigned long)atomic_read(&nr_pte_cont) * pagesize_in_kb);
+
+	pagesize_in_kb = PMD_SIZE / 1024;
+
+        seq_printf(m, "DirectMap%luM:    %8lu kB\n",
+			pagesize_in_kb / 1024,
+			(unsigned long)atomic_read(&nr_pmd) * pagesize_in_kb);
+
+	seq_printf(m, "CONT DMap%luM:    %8lu kB\n",
+			pagesize_in_kb / 1024,
+			(unsigned long)atomic_read(&nr_pmd_cont) * pagesize_in_kb);
+
+	pagesize_in_kb = PUD_SIZE / 1024;
+
+	seq_printf(m, "DirectMap%luG:  %10lu kB\n",
+		       	pagesize_in_kb >> 20,
+                        (unsigned long)atomic_read(&nr_pud) * pagesize_in_kb);
+}
+#endif
+


From peter.griffin at linaro.org  Fri Dec  8 13:14:21 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 8 Dec 2023 21:14:21 +0000
Subject: [PATCH v5 12/20] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <5e9c0b1c5885775a7bc32ef59cb09a2a93d4cbe1.camel@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-13-peter.griffin@linaro.org> <5e9c0b1c5885775a7bc32ef59cb09a2a93d4cbe1.camel@linaro.org>
Message-ID: <CADrjBPqAjqW27TvvT3BpEovOsouRedsnB49qdkkgSto=z0jM3Q@mail.gmail.com>

Hi Andr?

On Tue, 5 Dec 2023 at 07:52, Andr? Draszik <andre.draszik at linaro.org> wrote:
>
> Hi Pete,
>
> On Fri, 2023-12-01 at 16:09 +0000, Peter Griffin wrote:
> > cmu_top is the top level clock management unit which contains PLLs, muxes,
> > dividers and gates that feed the other clock management units.
> >
> > cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> > APM module.
> >
> > Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> > Tested-by: Will McVicker <willmcvicker at google.com>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  drivers/clk/samsung/Makefile    |    1 +
> >  drivers/clk/samsung/clk-gs101.c | 2495 +++++++++++++++++++++++++++++++
> >  2 files changed, 2496 insertions(+)
> >  create mode 100644 drivers/clk/samsung/clk-gs101.c
> >
> > diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> > index ebbeacabe88f..3056944a5a54 100644
> > --- a/drivers/clk/samsung/Makefile
> > +++ b/drivers/clk/samsung/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)       += clk-exynos7.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)        += clk-exynos7885.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)        += clk-exynos850.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)        += clk-exynosautov9.o
> > +obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)        += clk-gs101.o
> >  obj-$(CONFIG_S3C64XX_COMMON_CLK)     += clk-s3c64xx.o
> >  obj-$(CONFIG_S5PV210_COMMON_CLK)     += clk-s5pv210.o clk-s5pv210-audss.o
> >  obj-$(CONFIG_TESLA_FSD_COMMON_CLK)   += clk-fsd.o
> > diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> > new file mode 100644
> > index 000000000000..6bd233a7ab63
> > --- /dev/null
> > +++ b/drivers/clk/samsung/clk-gs101.c
> > @@ -0,0 +1,2495 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2023 Linaro Ltd.
> > + * Author: Peter Griffin <peter.griffin at linaro.org>
> > + *
> > + * Common Clock Framework support for GS101.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include <dt-bindings/clock/google,gs101.h>
> > +
> > +#include "clk.h"
> > +#include "clk-exynos-arm64.h"
> > +
> > +/* NOTE: Must be equal to the last clock ID increased by one */
> > +#define TOP_NR_CLK   (CLK_GOUT_TPU_UART + 1)
> > +#define APM_NR_CLK   (CLK_APM_PLL_DIV16_APM + 1)
> > +#define MISC_NR_CLK  (CLK_GOUT_MISC_XIU_D_MISC_IPCLKPORT_ACLK + 1)
> > +
> > +/* ---- CMU_TOP ------------------------------------------------------------- */
> > +
> > [...]
> > +
> > +/* ---- CMU_APM ------------------------------------------------------------- */
> > [..]
> > +
> > +/* ---- CMU_MISC ------------------------------------------------------------- */
>
> nit - the CMU_MISC comment here is an outlier.

Will fix.

Peter.


From robin.murphy at arm.com  Fri Dec  8 13:56:37 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 8 Dec 2023 21:56:37 +0000
Subject: [PATCH 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <20231208193352.GA1865260-robh@kernel.org>
References: <cover.1701793996.git.robin.murphy@arm.com>
 <bbb4262065cfc906f98165cac074e86dce19599e.1701793996.git.robin.murphy@arm.com>
 <20231208193352.GA1865260-robh@kernel.org>
Message-ID: <9136a4c3-4846-411f-8380-6bcb07c64c67@arm.com>

On 2023-12-08 7:33 pm, Rob Herring wrote:
> On Tue, Dec 05, 2023 at 04:51:57PM +0000, Robin Murphy wrote:
>> Add a binding for implementations of the Arm CoreSight Performance
>> Monitoring Unit Architecture. Not to be confused with CoreSight debug
>> and trace, the PMU architecture defines a standard MMIO interface for
>> event counters similar to the CPU PMU architecture, where the
>> implementation and most of its features are discoverable through ID
>> registers.
> 
> The implementation is separate from the CPU PMU rather than an MMIO view
> of it. Not really clear in my quick read of the spec.

Yeah, the architecture seems to have aspirations of being able to 
describe the CPU PMU, but the main intent of this binding is to 
accommodate all of the arbitrary MMIO non-CPU things. However that's not 
to say it *couldn't* ever be used for the memory-mapped view of a CPU's 
PMU via its external debug interface, if it is suitably compatible. I 
concur that I'm rather light on description here, but that's mostly 
because the architecture itself isn't prescriptive - it really is pretty 
much just an interface to whatever PMU functionality can be made to fit 
it (and with plenty of imp-def leeway).

>> CC: Rob Herring <robh+dt at kernel.org>
>> CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
>> CC: Conor Dooley <conor+dt at kernel.org>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> ---
>>   .../bindings/perf/arm,coresight-pmu.yaml      | 39 +++++++++++++++++++
>>   1 file changed, 39 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
>> new file mode 100644
>> index 000000000000..12c7b28eee35
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
>> @@ -0,0 +1,39 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/perf/arm,coresight-pmu.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Arm Coresight Performance Monitoring Unit Architecture
>> +
>> +maintainers:
>> +  - Robin Murphy <robin.murphy at arm.com>
>> +
>> +properties:
>> +  compatible:
>> +    const: arm,coresight-pmu
>> +
>> +  reg:
>> +    items:
>> +      - description: Register page 0
>> +      - description: Register page 1 (if dual-page extension implemented)
>> +    minItems: 1
>> +
>> +  interrupts:
>> +    items:
>> +      - description: Overflow interrupt
>> +
>> +  cpus:
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> 
> Don't need a type. Already defined.

Ah, I hadn't noticed this was a common property now. Good to know, thanks.

>> +    minItems: 1
> 
> 1 is always the minimum.
> 
>> +    description: List of CPUs with which the PMU is associated, if applicable
> 
> When is it applicable? Presumably when it is associated with only a
> subset of CPUs?

Affinity to one CPU or some subset, for things like tightly coupled 
accelerators or cluster-level things like DSU, would want explicitly 
describing, but for interconnects, memory controllers and random other 
standalone devices usually no meaningful association will exist (either 
they can be considered affine to no CPUs, or to all of them in an 
implicit manner).

>> +
>> +  arm,64-bit-atomic:
>> +    type: boolean
>> +    description: Register accesses are single-copy atomic at doubleword granularity
> 
> As this is recommended, shouldn't the property be the inverse.

It may be recommended, but in practice I'm convinced it's going to 
remain the exception. It's mandatory (and thus assumable) for the 64-bit 
programmers model extension, and effectively moot if only 32-bit or 
smaller counters are implemented, so it's really only relevant to the 
in-between case of the standard "32-bit" programmers model with 64-bit 
(or at least >32-bit) counters, but even then I'd bet most folks are 
still going to implement those behind an APB interface that ends up with 
larger accesses split into 32-bit bursts if they're even accepted at 
all. I'm aware of 3 implementations so far; one I'm not sure how wide 
the counters are, while the other two have proven to be 64-bit *without* 
atomic access ;)

> Maybe the standard 'reg-io-width = <4>' would be sufficient here?

Oh, indeed I'd forgotten that was a thing - IIRC in common cases like 
UARTs it's used to represent a *minimum* access size, whereas here it 
would represent a maximum, but I imagine that ambiguity may well already 
exist via other bindings, so as long as that's OK I'm happy to go with 
it. As above I would still be inclined to make it default to 4 if 
absent, but permit either 4 or 8 to be specified.

Thanks,
Robin.


From helgaas at kernel.org  Fri Dec  8 14:27:57 2023
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Fri, 8 Dec 2023 16:27:57 -0600
Subject: [PATCH 2/4] dt-bindings: imx6q-pcie: Add host-wake-gpio property
In-Reply-To: <20231208205545.GA2675840-robh@kernel.org>
Message-ID: <20231208222757.GA834524@bhelgaas>

On Fri, Dec 08, 2023 at 02:55:45PM -0600, Rob Herring wrote:
> ...

> And they should start going into root port nodes rather than the 
> host bridge node because it's the root ports that correspond to slots 
> rather than the host bridge. We've just taken shortcuts because many 
> host bridges only have 1 root port.
> 
> Note that I'm in the middle of splitting pci-bus.yaml into host bridge, 
> PCI-PCI bridge (and RP), and common device schemas.

Hooray!  Thanks for working on that; the conflation of host bridge and
Root Port is a real annoyance.

Bjorn


From dmitry.torokhov at gmail.com  Fri Dec  8 15:37:47 2023
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Fri, 8 Dec 2023 23:37:47 +0000
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-in-suspend property
In-Reply-To: <CACRpkdbSs-vebvchxx-Tg+O5CUF5M3vZf-iytuW=ZECnHb2anA@mail.gmail.com>
References: <20231207111300.80581-1-eichest@gmail.com>
 <20231207111300.80581-2-eichest@gmail.com>
 <CACRpkdbSs-vebvchxx-Tg+O5CUF5M3vZf-iytuW=ZECnHb2anA@mail.gmail.com>
Message-ID: <ZXOoy8mFdhUQsZAu@google.com>

Hi Linus, Krzysztof,

On Fri, Dec 08, 2023 at 01:54:21PM +0100, Linus Walleij wrote:
> On Thu, Dec 7, 2023 at 12:13?PM Stefan Eichenberger <eichest at gmail.com> wrote:
> 
> > From: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> >
> > Add a new property to indicate that the device should be powered off in
> > suspend mode.
> >
> > Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> (...)
> > +  atmel,poweroff-in-suspend:
> > +    description: |
> > +      When this property is set, all supplies are turned off when the system is
> > +      going to suspend.
> > +    type: boolean
>    wakeup-source:
>      type: boolean
> 
> As Krzysztof says it seems you are describing an operating system feature.

It appears to be an OS feature, but I would argue that it is also a
property of a board. It is tempting to say that if DTS defines supplies
for the controller we should use them to power off the controller in
suspend, otherwise we should use the deep sleep functionality of the
controller. But a mere presence of regulators does not indicate if they
can actually be powered off in suspend (i.e. if controllers shares power
rails with another device that can be a wakeup source), so we need to
have additional hints on how OS should behave on a given device.

On top of that we have regulator framework supplying dummy regulators...

Thanks.

-- 
Dmitry


From andi.shyti at kernel.org  Fri Dec  8 16:07:47 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Sat, 9 Dec 2023 01:07:47 +0100
Subject: [PATCH v2 4/7] i2c: stm32f7: add support for stm32mp25 soc
In-Reply-To: <20231208164719.3584028-5-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
 <20231208164719.3584028-5-alain.volmat@foss.st.com>
Message-ID: <20231209000747.4l6462nlzj3po3sf@zenone.zhora.eu>

Hi Alain,

On Fri, Dec 08, 2023 at 05:47:13PM +0100, Alain Volmat wrote:
> The stm32mp25 has only a single interrupt line used for both
> events and errors. In order to cope with that, reorganise the
> error handling code so that it can be called either from the
> common handler (used in case of SoC having only a single IT line)
> and the error handler for others.
> The CR1 register also embeds a new FMP bit, necessary when running
> at Fast Mode Plus frequency. This bit should be used instead of
> the SYSCFG bit used on other platforms.
> Add a new compatible to distinguish between the SoCs and two
> boolean within the setup structure in order to know if the
> platform has a single/multiple IT lines and if the FMP bit
> within CR1 is available or not.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
> Signed-off-by: Valentin Caron <valentin.caron at foss.st.com>

your SoB here should come last because you are the one sending
the patch.

> ---
>  drivers/i2c/busses/i2c-stm32f7.c | 230 ++++++++++++++++++-------------
>  1 file changed, 133 insertions(+), 97 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
> index 2a011deec3c5..5634332900fb 100644
> --- a/drivers/i2c/busses/i2c-stm32f7.c
> +++ b/drivers/i2c/busses/i2c-stm32f7.c
> @@ -50,6 +50,7 @@
>  #define STM32F7_I2C_TXDR			0x28
>  
>  /* STM32F7 I2C control 1 */
> +#define STM32_I2C_CR1_FMP			BIT(24)
>  #define STM32F7_I2C_CR1_PECEN			BIT(23)
>  #define STM32F7_I2C_CR1_ALERTEN			BIT(22)
>  #define STM32F7_I2C_CR1_SMBHEN			BIT(20)
> @@ -226,6 +227,8 @@ struct stm32f7_i2c_spec {
>   * @rise_time: Rise time (ns)
>   * @fall_time: Fall time (ns)
>   * @fmp_clr_offset: Fast Mode Plus clear register offset from set register
> + * @single_it_line: Only a single IT line is used for both events/errors
> + * @fmp_cr1_bit: Fast Mode Plus control is done via a bit in CR1

Is the Fast Mode Plus an optional feature?

>   */
>  struct stm32f7_i2c_setup {
>  	u32 speed_freq;
> @@ -233,6 +236,8 @@ struct stm32f7_i2c_setup {
>  	u32 rise_time;
>  	u32 fall_time;
>  	u32 fmp_clr_offset;
> +	bool single_it_line;
> +	bool fmp_cr1_bit;
>  };

[...]

> -static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev)
> +static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev, u32 status)
>  {
>  	void __iomem *base = i2c_dev->base;
> -	u32 cr2, status, mask;
> +	u32 cr2, mask;
>  	u8 val;
>  	int ret;
>  
> -	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
> -

good to see this change here, relates to my comment in patch 1.
But I think this should go on a different patch.

>  	/* Slave transmitter mode */
>  	if (status & STM32F7_I2C_ISR_TXIS) {
>  		i2c_slave_event(i2c_dev->slave_running,
> @@ -1494,17 +1504,81 @@ static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev)
>  	return IRQ_HANDLED;
>  }

[...]

> -	setup = of_device_get_match_data(&pdev->dev);
> -	if (!setup) {
> -		dev_err(&pdev->dev, "Can't get device data\n");
> -		return -ENODEV;
> +		ret = devm_request_threaded_irq(&pdev->dev, irq_error,
> +						NULL,
> +						stm32f7_i2c_isr_error_thread,
> +						IRQF_ONESHOT,
> +						pdev->name, i2c_dev);
> +		if (ret) {
> +			dev_err(&pdev->dev, "Failed to request irq error %i\n",
> +				irq_error);

please use dev_err_probe();

> +			return ret;
> +		}

out of the scope of the patch and just for curiosity: does the
driver work without being able to signal on the error interrupt
line?

Overall the patch looks good to me, though.

Andi


From peter.griffin at linaro.org  Fri Dec  8 16:10:10 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat, 9 Dec 2023 00:10:10 +0000
Subject: [PATCH v5 02/20] dt-bindings: clock: Add Google gs101 clock
 management unit bindings
In-Reply-To: <6e595a110444033de6ecd35bedc6e84ea1c43fdc.camel@linaro.org>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-3-peter.griffin@linaro.org> <6e595a110444033de6ecd35bedc6e84ea1c43fdc.camel@linaro.org>
Message-ID: <CADrjBPq+jvULhG4vezCCt4xXsQrybTsOuiCBB3LZZq32OrJjoA@mail.gmail.com>

Hi Andr?

On Wed, 6 Dec 2023 at 12:30, Andr? Draszik <andre.draszik at linaro.org> wrote:
>

<cut>

> > +#define CLK_DOUT_HSI2_PCIE           118
> > +#define CLK_DOUT_HSI2_UFS_EMBD               119
> > +#define CLK_DOUT_IPP_BUS             107
>
> You're restarting at 107 here, but the numbers should continue at 120...

I've fixed this in v6.

Peter.


From daniel at makrotopia.org  Fri Dec  8 16:10:13 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 9 Dec 2023 00:10:13 +0000
Subject: [PATCH v3 3/4] clk: mediatek: Add pcw_chg_shift control
In-Reply-To: <0ebce75d-0074-4128-b35e-e86ee3ee546b@collabora.com>
References: <23bc89d407e7797e97b703fa939b43bfe79296ce.1701823757.git.daniel@makrotopia.org>
 <40981d0bb722eb509628bcf82c31f632e4cf747a.1701823757.git.daniel@makrotopia.org>
 <0ebce75d-0074-4128-b35e-e86ee3ee546b@collabora.com>
Message-ID: <ZXOwZdyAJoyLRbk5@makrotopia.org>

Hi Angelo,

thank you for taking the time to review and for the helpful comments.

On Wed, Dec 06, 2023 at 11:38:36AM +0100, AngeloGioacchino Del Regno wrote:
> Il 06/12/23 01:57, Daniel Golle ha scritto:
> > From: Sam Shih <sam.shih at mediatek.com>
> > 
> > Introduce pcw_chg_shfit control to optionally use that instead of the
> > hardcoded PCW_CHG_MASK macro.
> > This will needed for clocks on the MT7988 SoC.
> > 
> > Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> > Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> > ---
> > v3: use git --from ...
> > v2: no changes
> > 
> >   drivers/clk/mediatek/clk-pll.c | 5 ++++-
> >   drivers/clk/mediatek/clk-pll.h | 1 +
> >   2 files changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
> > index 513ab6b1b3229..9f08bc5d2a8a2 100644
> > --- a/drivers/clk/mediatek/clk-pll.c
> > +++ b/drivers/clk/mediatek/clk-pll.c
> > @@ -114,7 +114,10 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll, u32 pcw,
> >   			pll->data->pcw_shift);
> >   	val |= pcw << pll->data->pcw_shift;
> >   	writel(val, pll->pcw_addr);
> > -	chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
> > +	if (pll->data->pcw_chg_shift)
> > +		chg = readl(pll->pcw_chg_addr) | BIT(pll->data->pcw_chg_shift);
> > +	else
> > +		chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
> >   	writel(chg, pll->pcw_chg_addr);
> >   	if (pll->tuner_addr)
> >   		writel(val + 1, pll->tuner_addr);
> > diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
> > index f17278ff15d78..d28d317e84377 100644
> > --- a/drivers/clk/mediatek/clk-pll.h
> > +++ b/drivers/clk/mediatek/clk-pll.h
> > @@ -44,6 +44,7 @@ struct mtk_pll_data {
> >   	u32 pcw_reg;
> >   	int pcw_shift;
> >   	u32 pcw_chg_reg;
> > +	int pcw_chg_shift;
> >   	const struct mtk_pll_div_table *div_table;
> >   	const char *parent_name;
> >   	u32 en_reg;
> 
> Hmm... no, this is not the best at all and can be improved.
> 
> Okay, so, the situation here is that one or some PLL(s) on MT7988 have a different
> PCW_CHG_MASK as far as I understand.

Correct. *All* clocks of MT7988 have a different PCW_CHG_MASK, BIT(2)
instead of BIT(31).

> 
> Situation here is:
>  - Each PLL must be registered to clk-pll
>  - Each driver declaring a PLL does exactly so
>    - There's a function to register the PLL
> 
> You definitely don't want to add a conditional in pll_set_rate(): even though
> this is technically not a performance path on the current SoCs (and will probably
> never be), it's simply useless to have this (very small) overhead there.
> 
> The solution is to:
>  - Change that pcw_chg_shift to an unsigned short int type (or u8, your call):
>    you don't need 32 bits for this number, as the expected range of this member
>    is [0-31], and this can be expressed in just 4 bits (u8 is the smallest though)

Ack will use u8 instead, despite the struct not being packed, so I
wonder if it actually makes a difference.

>  - Add that to function mtk_clk_register_pll_ops()
>  - Change mtk_pll_set_rate_regs() to always do
>    chg = readl(pll->pcw_chg_addr) | BIT(pll->data->pcw_chg_shift);

As mtk_pll_data is a read-only member of the mtk_pll struct, we can't
set pcw_chg_shift to 31 in mtk_clk_register_pll_ops() in case it
is set to 0.
The only (much more intrusive change) would be to explicitely declare
.pcw_chg_shift = 31 in all current drivers setting .pcs_chg_reg != 0.
Should I do that instead?


From peter.griffin at linaro.org  Fri Dec  8 17:00:53 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat, 9 Dec 2023 01:00:53 +0000
Subject: [PATCH v5 18/20] arm64: dts: exynos: google: Add initial Google
 gs101 SoC support
In-Reply-To: <CAPLW+4ki_GUAnor4sTanXFLzKrAB9JpxK98PED1fUY-MLCzUdA@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-19-peter.griffin@linaro.org> <CAPLW+4ki_GUAnor4sTanXFLzKrAB9JpxK98PED1fUY-MLCzUdA@mail.gmail.com>
Message-ID: <CADrjBPq-MLBVrW0ju64JdXia+QnDSsKR9+DSi==rkZXokMzt+g@mail.gmail.com>

Hi Sam,

On Sat, 2 Dec 2023 at 01:54, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > Google gs101 SoC is ARMv8 mobile SoC found in the Pixel 6,
> > (oriole) Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
> > phones. It features:
> > * 4xA55 little cluster
> > * 2xA76 Mid cluster
> > * 2xX1 Big cluster
> >
> > This commit adds the basic device tree for gs101 (SoC).
> > Further platform support will be added over time.

[cut]

> > +       spi0_cs_func: spi0-cs-func-pins {
> > +               samsung,pins = "gpp20-3";
> > +               samsung,pin-function = <GS101_PIN_FUNC_3>;
> > +               samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> > +               samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> > +       };
> > +};
> > +
>
> Nitpick: this empty line is not needed.

Ok will fix

[cut]

> > +
> > +       aliases {
> > +               pinctrl0 = &pinctrl_gpio_alive;
> > +               pinctrl1 = &pinctrl_far_alive;
> > +               pinctrl2 = &pinctrl_gsacore;
> > +               pinctrl3 = &pinctrl_gsactrl;
> > +               pinctrl4 = &pinctrl_peric0;
> > +               pinctrl5 = &pinctrl_peric1;
> > +               pinctrl6 = &pinctrl_hsi1;
> > +               pinctrl7 = &pinctrl_hsi2;
> > +               serial0 = &serial_0;
>
> Please check commit f4324583cd4d ("arm64: dts: exynos: move aliases to
> board in Exynos850"). At least for Exynos850 the serial alias was
> moved to the board dts by Krzysztof.

Ok will fix

>
> > +       };
> > +
> > +       pmu-0 {
> > +               compatible = "arm,cortex-a55-pmu";
> > +               interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
> > +       };
> > +
> > +       pmu-1 {
> > +               compatible = "arm,cortex-a76-pmu";
> > +               interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
> > +       };
> > +
> > +       pmu-2 {
> > +               compatible = "arm,cortex-x1-pmu";
> > +               interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster2>;
> > +       };
> > +
> > +       pmu-3 {
> > +               compatible = "arm,dsu-pmu";
> > +               interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH 0>;
> > +               cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
> > +                      <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
> > +       };
> > +
> > +       /* TODO replace with CCF clock */
> > +       dummy_clk: oscillator {
> > +               compatible = "fixed-clock";
> > +               #clock-cells = <0>;
> > +               clock-frequency = <12345>;
> > +               clock-output-names = "pclk";
> > +       };
>
> Don't you already have real USI/UART clocks implemented in your clock driver?

No, not yet, hence the dummy clock.

[cut]

> > +
> > +               usi_uart: usi at 10a000c0 {
> > +                       compatible = "google,gs101-usi",
>
> I can't see this compatible in USI driver. Does it make sense to add it there?

It is not required at the moment, as it is compatible with
samsung,exynos850-usi. I don't want to keep adding more patches to
this series, and then having an endless cycle of nits.

>
> > +                                    "samsung,exynos850-usi";
> > +                       reg = <0x10a000c0 0x20>;
> > +                       samsung,sysreg = <&sysreg_peric0 0x1020>;
> > +                       samsung,mode = <USI_V2_UART>;
> > +                       #address-cells = <1>;
> > +                       #size-cells = <1>;
> > +                       ranges;
> > +                       clocks = <&dummy_clk>, <&dummy_clk>;
>
> The same concern as above. I think I saw those clocks already
> implemented in gs101 clock driver.

No, these clocks have not been implemented yet, hence the dummy clock.
There is no support for cmu_peric0 bank yet in the clock driver.

>
> > +                       clock-names = "pclk", "ipclk";
> > +                       status = "disabled";
> > +
> > +                       serial_0: serial at 10a00000 {
> > +                               compatible = "google,gs101-uart";
> > +                               reg = <0x10a00000 0xc0>;
> > +                               reg-io-width = <4>;
> > +                               samsung,uart-fifosize = <256>;
> > +                               interrupts = <GIC_SPI 634
> > +                                             IRQ_TYPE_LEVEL_HIGH 0>;
> > +                               clocks = <&dummy_clk 0>, <&dummy_clk 0>;
>
> Ditto.

See above

>
> > +                               clock-names = "uart", "clk_uart_baud0";
> > +                               status = "disabled";
> > +                       };
> > +               };
> > +
> > +               pinctrl_peric1: pinctrl at 10c40000 {
> > +                       compatible = "google,gs101-pinctrl";
> > +                       reg = <0x10C40000 0x00001000>;
> > +                       interrupts = <GIC_SPI 644 IRQ_TYPE_LEVEL_HIGH 0>;
> > +               };
> > +
> > +               sysreg_peric1: syscon at 10c20000 {
> > +                       compatible = "google,gs101-peric1-sysreg", "syscon";
> > +                       reg = <0x10C20000 0x10000>;
> > +               };
> > +
> > +               pinctrl_hsi1: pinctrl at 11840000 {
> > +                       compatible = "google,gs101-pinctrl";
> > +                       reg = <0x11840000 0x00001000>;
> > +                       interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH 0>;
> > +               };
> > +
> > +               pinctrl_hsi2: pinctrl at 14440000 {
> > +                       compatible = "google,gs101-pinctrl";
> > +                       reg = <0x14440000 0x00001000>;
> > +                       interrupts = <GIC_SPI 503 IRQ_TYPE_LEVEL_HIGH 0>;
> > +               };
> > +
> > +               cmu_apm: clock-controller at 17400000 {
> > +                       compatible = "google,gs101-cmu-apm";
> > +                       reg = <0x17400000 0x8000>;
> > +                       #clock-cells = <1>;
> > +
> > +                       clocks = <&ext_24_5m>;
> > +                       clock-names = "oscclk";
>
> Doesn't CMU_APM take any clocks from CMU_TOP?

No it doesn't.

>
> > +               };
> > +
> > +               sysreg_apm: syscon at 174204e0 {
> > +                       compatible = "google,gs101-apm-sysreg", "syscon";
> > +                       reg = <0x174204e0 0x1000>;
> > +               };
> > +
> > +               pmu_system_controller: system-controller at 17460000 {
> > +                       compatible = "google,gs101-pmu", "syscon";
> > +                       reg = <0x17460000 0x10000>;
> > +               };
>
> Just a suggestion: it might be relatively simple to add syscon-reboot
> node in pmu_system_controller, and it might just work. One more
> feature for free! :)

Thanks for the suggestion. I tried that previously and it is not
included here deliberately because it relies on more than that to be
functional. Although the register offsets are the same, the PMU
registers are protected from the kernel and are only write accessible
via SMC call on this platform. I have patches ready to send out as a
RFC for that once this initial series is merged and we can discuss
that then.

regards,

Peter.


From broonie at kernel.org  Fri Dec  8 17:02:46 2023
From: broonie at kernel.org (broonie at kernel.org)
Date: Sat, 09 Dec 2023 01:02:46 +0000
Subject: [PATCH 00/13] arm64/sysreg: System register updates from the
 2023-09 XML release
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>

A number of serieses on the list have updates updates and additions to
the system registers, and as a result of the work being done on KVM
(especially nested virtualisation) there are overlaps and duplication of
work between people unaware of other pending serieses.  This series
collects together all the work that's been done on updating the system
register definitions that don't have pending review issues which I'm
aware of with the aim of at least making it easier to find things.

Since the system register definitions are part of the architecture
they're unlikely to change based on review of the serieses that they are
included in so it seems like it might make life easier to merge these
updates even without their users.  There is a small amount of overhead
from the increased size of the source and generated files but on the
other hand it would reduce the size of the serieses while they are in
review and make it less likely that we get duplicated work.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
Fuad Tabba (2):
      arm64/sysreg: Update HFGITR_EL2 definiton to DDI0601 2023-09
      arm64/sysreg: Add definition for HAFGRTR_EL2

Joey Gouly (2):
      arm64/sysreg: add system register POR_EL{0,1}
      arm64/sysreg: update CPACR_EL1 register

Mark Brown (9):
      arm64/sysreg: Add definition for ID_AA64PFR2_EL1
      arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion for DDI0601 2023-09
      arm64/sysreg: Add definition for ID_AA64ISAR3_EL1
      arm64/sysreg: Add definition for ID_AA64FPFR0_EL1
      arm64/sysreg: Update ID_AA64SMFR0_EL1 definition for DDI0601 2023-09
      arm64/sysreg: Update SCTLR_EL1 for DDI0601 2023-09
      arm64/sysreg: Update HCRX_EL2 definition for DDI0601 2023-09
      arm64/sysreg: Add definition for FPMR
      arm64/sysreg: Add new system registers for GCS

 arch/arm64/include/asm/sysreg.h |  13 ++
 arch/arm64/tools/sysreg         | 270 ++++++++++++++++++++++++++++++++++++++--
 2 files changed, 273 insertions(+), 10 deletions(-)
---
base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab
change-id: 20231208-b4-arm64-sysreg-additions-c1f3b4acdff8

Best regards,
-- 
Mark Brown <broonie at kernel.org>



From broonie at kernel.org  Fri Dec  8 17:02:47 2023
From: broonie at kernel.org (broonie at kernel.org)
Date: Sat, 09 Dec 2023 01:02:47 +0000
Subject: [PATCH 01/13] arm64/sysreg: Update HFGITR_EL2 definiton to DDI0601
 2023-09
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-1-45284e538474@kernel.org>

From: Fuad Tabba <tabba at google.com>

The 2023-09 release of the architecture XML (DDI0601) adds a new field
ATS1E1A to HFGITR_EL2, update our definition of the register to match.

This was extracted from Faud Tabba's patch "KVM: arm64: Add latest
HFGITR_EL2 FGT entries to nested virt"

Signed-off-by: Fuad Tabba <tabba at google.com>
Message-Id: <20231206100503.564090-4-tabba at google.com>
[Extracted the sysreg definition from Faud's original patch and reword
 subject to match -- broonie]
Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 96cbeeab4eec..8faeab1ee024 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2102,7 +2102,9 @@ Fields	HFGxTR_EL2
 EndSysreg
 
 Sysreg HFGITR_EL2	3	4	1	1	6
-Res0	63:61
+Res0	63
+Field	62	ATS1E1A
+Res0	61
 Field	60	COSPRCTX
 Field	59	nGCSEPP
 Field	58	nGCSSTR_EL1

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:48 2023
From: broonie at kernel.org (broonie at kernel.org)
Date: Sat, 09 Dec 2023 01:02:48 +0000
Subject: [PATCH 02/13] arm64/sysreg: Add definition for HAFGRTR_EL2
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-2-45284e538474@kernel.org>

From: Fuad Tabba <tabba at google.com>

Add a definition of HAFGRTR_EL2 (fine grained trap control for the AMU) as
per DDI0601 2023-09.

This was extracted from Fuad Tabba's patch "KVM: arm64: Handle
HAFGRTR_EL2 trapping in nested virt".

Signed-off-by: Fuad Tabba <tabba at google.com>
Link: https://lore.kernel.org/r/20231206100503.564090-6-tabba at google.com
[Extract sysreg update and rewrite commit message -- broonie]
Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 8faeab1ee024..145b33f75a96 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2297,6 +2297,49 @@ Field	1	DBGBVRn_EL1
 Field	0	DBGBCRn_EL1
 EndSysreg
 
+Sysreg HAFGRTR_EL2	3	4	3	1	6
+Res0	63:50
+Field	49	AMEVTYPER115_EL0
+Field	48	AMEVCNTR115_EL0
+Field	47	AMEVTYPER114_EL0
+Field	46	AMEVCNTR114_EL0
+Field	45	AMEVTYPER113_EL0
+Field	44	AMEVCNTR113_EL0
+Field	43	AMEVTYPER112_EL0
+Field	42	AMEVCNTR112_EL0
+Field	41	AMEVTYPER111_EL0
+Field	40	AMEVCNTR111_EL0
+Field	39	AMEVTYPER110_EL0
+Field	38	AMEVCNTR110_EL0
+Field	37	AMEVTYPER19_EL0
+Field	36	AMEVCNTR19_EL0
+Field	35	AMEVTYPER18_EL0
+Field	34	AMEVCNTR18_EL0
+Field	33	AMEVTYPER17_EL0
+Field	32	AMEVCNTR17_EL0
+Field	31	AMEVTYPER16_EL0
+Field	30	AMEVCNTR16_EL0
+Field	29	AMEVTYPER15_EL0
+Field	28	AMEVCNTR15_EL0
+Field	27	AMEVTYPER14_EL0
+Field	26	AMEVCNTR14_EL0
+Field	25	AMEVTYPER13_EL0
+Field	24	AMEVCNTR13_EL0
+Field	23	AMEVTYPER12_EL0
+Field	22	AMEVCNTR12_EL0
+Field	21	AMEVTYPER11_EL0
+Field	20	AMEVCNTR11_EL0
+Field	19	AMEVTYPER10_EL0
+Field	18	AMEVCNTR10_EL0
+Field	17	AMCNTEN1
+Res0	16:5
+Field	4	AMEVCNTR03_EL0
+Field	3	AMEVCNTR02_EL0
+Field	2	AMEVCNTR01_EL0
+Field	1	AMEVCNTR00_EL0
+Field	0	AMCNTEN0
+EndSysreg
+
 Sysreg	ZCR_EL2	3	4	1	2	0
 Fields	ZCR_ELx
 EndSysreg

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:49 2023
From: broonie at kernel.org (broonie at kernel.org)
Date: Sat, 09 Dec 2023 01:02:49 +0000
Subject: [PATCH 03/13] arm64/sysreg: add system register POR_EL{0,1}
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-3-45284e538474@kernel.org>

From: Joey Gouly <joey.gouly at arm.com>

Add POR_EL{0,1} according to DDI0601 2023-03.

Signed-off-by: Joey Gouly <joey.gouly at arm.com>
Reviewed-by: Mark Brown <broonie at kernel.org>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/sysreg.h | 13 +++++++++++++
 arch/arm64/tools/sysreg         | 12 ++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 5e65f51c10d2..9c2caf0efdc7 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -1039,6 +1039,19 @@
 
 #define PIRx_ELx_PERM(idx, perm)	((perm) << ((idx) * 4))
 
+/*
+ * Permission Overlay Extension (POE) permission encodings.
+ */
+#define POE_NONE	UL(0x0)
+#define POE_R		UL(0x1)
+#define POE_X		UL(0x2)
+#define POE_RX		UL(0x3)
+#define POE_W		UL(0x4)
+#define POE_RW		UL(0x5)
+#define POE_XW		UL(0x6)
+#define POE_RXW		UL(0x7)
+#define POE_MASK	UL(0xf)
+
 #define ARM64_FEATURE_FIELD_BITS	4
 
 /* Defined for compatibility only, do not add new users. */
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 145b33f75a96..1d371a24da6e 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2555,6 +2555,18 @@ Sysreg	PIR_EL2		3	4	10	2	3
 Fields	PIRx_ELx
 EndSysreg
 
+Sysreg	POR_EL0		3	3	10	2	4
+Fields	PIRx_ELx
+EndSysreg
+
+Sysreg	POR_EL1		3	0	10	2	4
+Fields	PIRx_ELx
+EndSysreg
+
+Sysreg	POR_EL12	3	5	10	2	4
+Fields	PIRx_ELx
+EndSysreg
+
 Sysreg	LORSA_EL1	3	0	10	4	0
 Res0	63:52
 Field	51:16	SA

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:50 2023
From: broonie at kernel.org (broonie at kernel.org)
Date: Sat, 09 Dec 2023 01:02:50 +0000
Subject: [PATCH 04/13] arm64/sysreg: update CPACR_EL1 register
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-4-45284e538474@kernel.org>

From: Joey Gouly <joey.gouly at arm.com>

Add E0POE bit that traps accesses to POR_EL0 from EL0.
Updated according to DDI0601 2023-03.

Signed-off-by: Joey Gouly <joey.gouly at arm.com>
Reviewed-by: Mark Brown <broonie at kernel.org>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 1d371a24da6e..c2dbbaa22620 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1747,7 +1747,8 @@ Field	0	M
 EndSysreg
 
 SysregFields	CPACR_ELx
-Res0	63:29
+Res0	63:30
+Field	29	E0POE
 Field	28	TTA
 Res0	27:26
 Field	25:24	SMEN

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:51 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:02:51 +0000
Subject: [PATCH 05/13] arm64/sysreg: Add definition for ID_AA64PFR2_EL1
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-5-45284e538474@kernel.org>

DDI0601 2023-09 defines a new system register ID_AA64PFR2_EL1 which
enumerates FPMR and some new MTE features. Add a definition of this
register.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index c2dbbaa22620..c48a3b8d00ad 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1002,6 +1002,27 @@ UnsignedEnum	3:0	BT
 EndEnum
 EndSysreg
 
+Sysreg	ID_AA64PFR2_EL1	3	0	0	4	2
+Res0	63:36
+UnsignedEnum	35:32	FPMR
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Res0	31:12
+UnsignedEnum	11:8	MTEFAR
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	7:4	MTESTOREONLY
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	3:0	MTEPERM
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+EndSysreg
+
 Sysreg	ID_AA64ZFR0_EL1	3	0	0	4	4
 Res0	63:60
 UnsignedEnum	59:56	F64MM

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:52 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:02:52 +0000
Subject: [PATCH 06/13] arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion for
 DDI0601 2023-09
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-6-45284e538474@kernel.org>

DDI0601 2023-09 defines some new fields in previously RES0 space in
ID_AA64ISAR2_EL1, together with one new enum value. Update the system
register definition to reflect this.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index c48a3b8d00ad..3f382f8d0f4a 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1365,7 +1365,14 @@ EndEnum
 EndSysreg
 
 Sysreg	ID_AA64ISAR2_EL1	3	0	0	6	2
-Res0	63:56
+UnsignedEnum	63:60	ATS1A
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	59:56	LUT
+	0b0000	NI
+	0b0001	IMP
+EndEnum
 UnsignedEnum	55:52	CSSC
 	0b0000	NI
 	0b0001	IMP
@@ -1374,7 +1381,19 @@ UnsignedEnum	51:48	RPRFM
 	0b0000	NI
 	0b0001	IMP
 EndEnum
-Res0	47:32
+Res0	47:44
+UnsignedEnum	43:40	PRFMSLC
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	39:36	SYSINSTR_128
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	35:32	SYSREG_128
+	0b0000	NI
+	0b0001	IMP
+EndEnum
 UnsignedEnum	31:28	CLRBHB
 	0b0000	NI
 	0b0001	IMP
@@ -1398,6 +1417,7 @@ UnsignedEnum	15:12	APA3
 	0b0011	PAuth2
 	0b0100	FPAC
 	0b0101	FPACCOMBINE
+	0b0110	PAUTH_LR
 EndEnum
 UnsignedEnum	11:8	GPA3
 	0b0000	NI

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:53 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:02:53 +0000
Subject: [PATCH 07/13] arm64/sysreg: Add definition for ID_AA64ISAR3_EL1
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-7-45284e538474@kernel.org>

DDI0601 2023-09 adds a new system register ID_AA64ISAR3_EL1 enumerating
new floating point and TLB invalidation features. Add a defintion for it.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 3f382f8d0f4a..d1bb6ebcd959 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1433,6 +1433,23 @@ UnsignedEnum	3:0	WFxT
 EndEnum
 EndSysreg
 
+Sysreg	ID_AA64ISAR3_EL1	3	0	0	6	3
+Res0	63:12
+UnsignedEnum	11:8	TLBIW
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	7:4	FAMINMAX
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+UnsignedEnum	3:0	CPA
+	0b0000	NI
+	0b0001	IMP
+	0b0010	CPA2
+EndEnum
+EndSysreg
+
 Sysreg	ID_AA64MMFR0_EL1	3	0	0	7	0
 UnsignedEnum	63:60	ECV
 	0b0000	NI

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:54 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:02:54 +0000
Subject: [PATCH 08/13] arm64/sysreg: Add definition for ID_AA64FPFR0_EL1
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-8-45284e538474@kernel.org>

DDI0601 2023-09 defines a new feature register ID_AA64FPFR0_EL1 which
enumerates a number of FP8 related features. Add a definition for it.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index d1bb6ebcd959..68236cf1abda 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1131,6 +1131,35 @@ EndEnum
 Res0	31:0
 EndSysreg
 
+Sysreg	ID_AA64FPFR0_EL1	3	0	0	4	7
+Res0	63:32
+UnsignedEnum	31	F8CVT
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	30	F8FMA
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	29	F8DP4
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	28	F8DP2
+	0b0	NI
+	0b1	IMP
+EndEnum
+Res0	27:2
+UnsignedEnum	1	F8E4M3
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	0	F8E5M2
+	0b0	NI
+	0b1	IMP
+EndEnum
+EndSysreg
+
 Sysreg	ID_AA64DFR0_EL1	3	0	0	5	0
 Enum	63:60	HPMN0
 	0b0000	UNPREDICTABLE

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:55 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:02:55 +0000
Subject: [PATCH 09/13] arm64/sysreg: Update ID_AA64SMFR0_EL1 definition for
 DDI0601 2023-09
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-9-45284e538474@kernel.org>

The 2023-09 release of DDI0601 defines a number of new feature enumeration
fields in ID_AA64SMFR0_EL1. Add these fields.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 68236cf1abda..839f7cca53e0 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1079,7 +1079,11 @@ UnsignedEnum	63	FA64
 	0b0	NI
 	0b1	IMP
 EndEnum
-Res0	62:60
+Res0	62:61
+UnsignedEnum	60	LUTv2
+	0b0	NI
+	0b1	IMP
+EndEnum
 UnsignedEnum	59:56	SMEver
 	0b0000	SME
 	0b0001	SME2
@@ -1107,7 +1111,14 @@ UnsignedEnum	42	F16F16
 	0b0	NI
 	0b1	IMP
 EndEnum
-Res0	41:40
+UnsignedEnum	41	F8F16
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	40	F8F32
+	0b0	NI
+	0b1	IMP
+EndEnum
 UnsignedEnum	39:36	I8I32
 	0b0000	NI
 	0b1111	IMP
@@ -1128,7 +1139,20 @@ UnsignedEnum	32	F32F32
 	0b0	NI
 	0b1	IMP
 EndEnum
-Res0	31:0
+Res0	31
+UnsignedEnum	30	SF8FMA
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	29	SF8DP4
+	0b0	NI
+	0b1	IMP
+EndEnum
+UnsignedEnum	28	SF8DP2
+	0b0	NI
+	0b1	IMP
+EndEnum
+Res0	27:0
 EndSysreg
 
 Sysreg	ID_AA64FPFR0_EL1	3	0	0	4	7

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:56 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:02:56 +0000
Subject: [PATCH 10/13] arm64/sysreg: Update SCTLR_EL1 for DDI0601 2023-09
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-10-45284e538474@kernel.org>

DDI0601 2023-09 defines some new fields in SCTLR_EL1 controlling new MTE
and floating point features. Update our sysreg definition to reflect these.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 839f7cca53e0..4137179e7570 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1791,7 +1791,8 @@ Field	63	TIDCP
 Field	62	SPINTMASK
 Field	61	NMI
 Field	60	EnTP2
-Res0	59:58
+Field	59	TCSO
+Field	58	TCSO0
 Field	57	EPAN
 Field	56	EnALS
 Field	55	EnAS0
@@ -1820,7 +1821,7 @@ EndEnum
 Field	37	ITFSB
 Field	36	BT1
 Field	35	BT0
-Res0	34
+Field	34	EnFPM
 Field	33	MSCEn
 Field	32	CMOW
 Field	31	EnIA

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:57 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:02:57 +0000
Subject: [PATCH 11/13] arm64/sysreg: Update HCRX_EL2 definition for DDI0601
 2023-09
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-11-45284e538474@kernel.org>

DDI0601 2023-09 defines new fields in HCRX_EL2 controlling access to new
system registers, update our definition of HCRX_EL2 to reflect this.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 4137179e7570..1acec8f5c37d 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2458,7 +2458,9 @@ Fields	ZCR_ELx
 EndSysreg
 
 Sysreg	HCRX_EL2	3	4	1	2	2
-Res0	63:23
+Res0	63:25
+Field	24	PACMEn
+Field	23	EnFPM
 Field	22	GCSEn
 Field	21	EnIDCP128
 Field	20	EnSDERR

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:58 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:02:58 +0000
Subject: [PATCH 12/13] arm64/sysreg: Add definition for FPMR
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-12-45284e538474@kernel.org>

DDI0601 2023-09 defines a new sysrem register FPMR (Floating Point Mode
Register) which configures the new FP8 features. Add a definition of this
register.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 1acec8f5c37d..1c6d1c904750 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2139,6 +2139,29 @@ Field	1	ZA
 Field	0	SM
 EndSysreg
 
+Sysreg	FPMR	3	3	4	4	2
+Res0	63:38
+Field	37:32	LSCALE2
+Field	31:24	NSCALE
+Res0	23
+Field	22:16	LSCALE
+Field	15	OSC
+Field	14	OSM
+Res0	13:9
+UnsignedEnum	8:6	F8D
+	0b000	E5M2
+	0b001	E4M3
+EndEnum
+UnsignedEnum	5:3	F8S2
+	0b000	E5M2
+	0b001	E4M3
+EndEnum
+UnsignedEnum	2:0	F8S1
+	0b000	E5M2
+	0b001	E4M3
+EndEnum
+EndSysreg
+
 SysregFields	HFGxTR_EL2
 Field	63	nAMAIR2_EL1
 Field	62	nMAIR2_EL1

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:02:59 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:02:59 +0000
Subject: [PATCH 13/13] arm64/sysreg: Add new system registers for GCS
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <20231209-b4-arm64-sysreg-additions-v1-13-45284e538474@kernel.org>

FEAT_GCS introduces a number of new system registers. Add the registers
available up to EL2 to sysreg as per DDI0601 2022-12.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/tools/sysreg | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 1c6d1c904750..b2007963523e 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1903,6 +1903,41 @@ Sysreg	SMCR_EL1	3	0	1	2	6
 Fields	SMCR_ELx
 EndSysreg
 
+SysregFields	GCSCR_ELx
+Res0	63:10
+Field	9	STREn
+Field	8	PUSHMEn
+Res0	7
+Field	6	EXLOCKEN
+Field	5	RVCHKEN
+Res0	4:1
+Field	0	PCRSEL
+EndSysregFields
+
+Sysreg	GCSCR_EL1	3	0	2	5	0
+Fields	GCSCR_ELx
+EndSysreg
+
+SysregFields	GCSPR_ELx
+Field	63:3	PTR
+Res0	2:0
+EndSysregFields
+
+Sysreg	GCSPR_EL1	3	0	2	5	1
+Fields	GCSPR_ELx
+EndSysreg
+
+Sysreg	GCSCRE0_EL1	3	0	2	5	2
+Res0	63:11
+Field	10	nTR
+Field	9	STREn
+Field	8	PUSHMEn
+Res0	7:6
+Field	5	RVCHKEN
+Res0	4:1
+Field	0	PCRSEL
+EndSysreg
+
 Sysreg	ALLINT	3	0	4	3	0
 Res0	63:14
 Field	13	ALLINT
@@ -2133,6 +2168,10 @@ Field	4	DZP
 Field	3:0	BS
 EndSysreg
 
+Sysreg	GCSPR_EL0	3	3	2	5	1
+Fields	GCSPR_ELx
+EndSysreg
+
 Sysreg	SVCR	3	3	4	2	2
 Res0	63:2
 Field	1	ZA
@@ -2531,6 +2570,14 @@ Sysreg	SMCR_EL2	3	4	1	2	6
 Fields	SMCR_ELx
 EndSysreg
 
+Sysreg	GCSCR_EL2	3	4	2	5	0
+Fields	GCSCR_ELx
+EndSysreg
+
+Sysreg	GCSPR_EL2	3	4	2	5	1
+Fields	GCSPR_ELx
+EndSysreg
+
 Sysreg	DACR32_EL2	3	4	3	0	0
 Res0	63:32
 Field	31:30	D15
@@ -2590,6 +2637,14 @@ Sysreg	SMCR_EL12	3	5	1	2	6
 Fields	SMCR_ELx
 EndSysreg
 
+Sysreg	GCSCR_EL12	3	5	2	5	0
+Fields	GCSCR_ELx
+EndSysreg
+
+Sysreg	GCSPR_EL12	3	5	2	5	1
+Fields	GCSPR_ELx
+EndSysreg
+
 Sysreg	FAR_EL12	3	5	6	0	0
 Field	63:0	ADDR
 EndSysreg

-- 
2.39.2



From broonie at kernel.org  Fri Dec  8 17:07:58 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:07:58 +0000
Subject: [PATCH 0/5] GPIO descriptor cleanup for some Wolfson codecs
In-Reply-To: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
References: <20231208-descriptors-sound-wlf-v1-0-c4dab6f521ec@linaro.org>
Message-ID: <170208407816.2911119.4303388917102358684.b4-ty@kernel.org>

On Fri, 08 Dec 2023 11:09:24 +0100, Linus Walleij wrote:
> This converts the remaining Wolfson ASoC codecs to
> use GPIO descriptors.
> 
> These Wolfson codecs are mostly used with different
> Samsung S3C (especially Cragganmore 6410) board files,
> so the in-tree users are fixed up in the process.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/5] ASoC: wm0010: Convert to GPIO descriptors
      commit: b53d47775651aa51bb98cdeb968dedb45699d9a1
[2/5] ASoC: wm1250-ev1: Convert to GPIO descriptors
      commit: 10a366f36e2a2e240d9db6da90e501fa16655282
[3/5] ASoC: wm2200: Convert to GPIO descriptors
      commit: 0119b2a24eb592f967a2849b772887c96617ad80
[4/5] ASoC: wm5100: Convert to GPIO descriptors
      commit: 8563cfe39ba5d00d974df25e310fb61b5b3687e1
[5/5] ASoC: wm8996: Convert to GPIO descriptors
      commit: 729f02ec02ae12e5d8a53171bd37e9de56f33677

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From broonie at kernel.org  Fri Dec  8 17:08:04 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 09 Dec 2023 01:08:04 +0000
Subject: (subset) [PATCH v9 0/8] spi: Add support for stacked/parallel
 memories
In-Reply-To: <20231018213328.40131-1-amit.kumar-mahapatra@amd.com>
References: <20231018213328.40131-1-amit.kumar-mahapatra@amd.com>
Message-ID: <170208408432.2911266.7193653673078869891.b4-ty@kernel.org>

On Thu, 19 Oct 2023 03:03:20 +0530, Amit Kumar Mahapatra wrote:
> This patch is in the continuation to the discussions which happened on
> 'commit f89504300e94 ("spi: Stacked/parallel memories bindings")' for
> adding dt-binding support for stacked/parallel memories.
> 
> This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI
> driver to add stacked and parallel memories support.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/8] spi: Add multi-cs memories support in SPI core
      commit: 4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b
[6/8] spi: spi-zynqmp-gqspi: Add stacked memories support in GQSPI driver
      (no commit info)
[8/8] spi: spi-zynqmp-gqspi: Add parallel memories support in GQSPI driver
      (no commit info)

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From andyshrk at 163.com  Fri Dec  8 17:50:38 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sat,  9 Dec 2023 09:50:38 +0800
Subject: [PATCH] dt-bindings: iommu: rockchip: Add Rockchip RK3588
Message-ID: <20231209015038.1457967-1-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>

Add a Rockchip RK3588 compatible

I split it from the vop2 patch series as suggested by Heiko[0]

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

[0]https://patchwork.kernel.org/project/dri-devel/patch/20231207080235.652719-1-andyshrk at 163.com/

---

 .../devicetree/bindings/iommu/rockchip,iommu.yaml     | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
index ba9124f721f1..621dde0e45d8 100644
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
@@ -19,9 +19,14 @@ description: |+
 
 properties:
   compatible:
-    enum:
-      - rockchip,iommu
-      - rockchip,rk3568-iommu
+    oneOf:
+      - enum:
+          - rockchip,iommu
+          - rockchip,rk3568-iommu
+      - items:
+          - enum:
+              - rockchip,rk3588-iommu
+          - const: rockchip,rk3568-iommu
 
   reg:
     items:
-- 
2.34.1



From jisheng.teoh at starfivetech.com  Fri Dec  8 19:09:55 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Sat, 9 Dec 2023 11:09:55 +0800
Subject: [PATCH v1] i2c: cadence: Add system suspend and resume PM support
Message-ID: <20231209030955.1156905-1-jisheng.teoh@starfivetech.com>

Enable device system suspend and resume PM support, and mark the device
state as suspended during system suspend to reject any data transfer.

Signed-off-by: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
---
 drivers/i2c/busses/i2c-cadence.c | 33 ++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index de3f58b60dce..c42d6afded2a 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -1176,6 +1176,18 @@ static int __maybe_unused cdns_i2c_runtime_suspend(struct device *dev)
 	return 0;
 }
 
+static int __maybe_unused cdns_i2c_suspend(struct device *dev)
+{
+	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
+
+	i2c_mark_adapter_suspended(&xi2c->adap);
+
+	if (!pm_runtime_status_suspended(dev))
+		return cdns_i2c_runtime_suspend(dev);
+
+	return 0;
+}
+
 /**
  * cdns_i2c_init -  Controller initialisation
  * @id:		Device private data structure
@@ -1219,7 +1231,28 @@ static int __maybe_unused cdns_i2c_runtime_resume(struct device *dev)
 	return 0;
 }
 
+static int __maybe_unused cdns_i2c_resume(struct device *dev)
+{
+	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
+	int err;
+
+	err = cdns_i2c_runtime_resume(dev);
+	if (err)
+		return err;
+
+	if (pm_runtime_status_suspended(dev)) {
+		cdns_i2c_runtime_suspend(dev);
+		if (err)
+			return err;
+	}
+
+	i2c_mark_adapter_resumed(&xi2c->adap);
+
+	return 0;
+}
+
 static const struct dev_pm_ops cdns_i2c_dev_pm_ops = {
+	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(cdns_i2c_suspend, cdns_i2c_resume)
 	SET_RUNTIME_PM_OPS(cdns_i2c_runtime_suspend,
 			   cdns_i2c_runtime_resume, NULL)
 };
-- 
2.25.1



From thiago.bauermann at linaro.org  Fri Dec  8 19:15:22 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Sat, 09 Dec 2023 00:15:22 -0300
Subject: [PATCH v7 24/39] arm64/signal: Set up and restore the GCS
 context for signal handlers
In-Reply-To: <20231122-arm64-gcs-v7-24-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-24-201c483bd775@kernel.org>
Message-ID: <8734wcgj79.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

> +static bool gcs_signal_cap_valid(u64 addr, u64 val)
> +{
> +	/*
> +	 * The top bit should be set, this is an invalid address for
> +	 * EL0 and will only be set for caps created by signals.
> +	 */
> +	if (!(val & GCS_SIGNAL_CAP_FLAG))
> +		return false;
> +
> +	/* The rest should be a standard architectural cap token. */
> +	val &= ~GCS_SIGNAL_CAP_FLAG;
> +
> +	/* The cap must have the low bits set to a token value */
> +	if (GCS_CAP_TOKEN(val) != 0)
> +		return false;

I found the comment above a little confusing, since the if condition
actually checks that low bits aren't set at all. Perhaps reword to
something like "The token value of a signal cap must be 0"?

> +
> +	/* The cap must store the VA the cap was stored at */
> +	if (GCS_CAP_ADDR(addr) != GCS_CAP_ADDR(val))
> +		return false;
> +
> +	return true;
> +}
> +#endif
> +
>  /*
>   * Do a signal return; undo the signal stack. These are aligned to 128-bit.
>   */
> @@ -815,6 +847,45 @@ static int restore_sigframe(struct pt_regs *regs,
>  	return err;
>  }
>  
> +#ifdef CONFIG_ARM64_GCS
> +static int gcs_restore_signal(void)
> +{
> +	u64 gcspr_el0, cap;
> +	int ret;
> +
> +	if (!system_supports_gcs())
> +		return 0;
> +
> +	if (!(current->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE))
> +		return 0;
> +
> +	gcspr_el0 = read_sysreg_s(SYS_GCSPR_EL0);
> +
> +	/*
> +	 * GCSPR_EL0 should be pointing at a capped GCS, read the cap...
> +	 */
> +	gcsb_dsync();
> +	ret = copy_from_user(&cap, (__user void*)gcspr_el0, sizeof(cap));
> +	if (ret)
> +		return -EFAULT;
> +
> +	/*
> +	 * ...then check that the cap is the actual GCS before
> +	 * restoring it.
> +	 */
> +	if (!gcs_signal_cap_valid(gcspr_el0, cap))
> +		return -EINVAL;
> +
> +	current->thread.gcspr_el0 = gcspr_el0 + sizeof(cap);
> +	write_sysreg_s(current->thread.gcspr_el0, SYS_GCSPR_EL0);

At this point, there's an inactive but valid cap just below the GCS.
Over time, as different signals are received when the GCSPR is pointing
at different locations of the stack, there could be a number of valid
inactive caps available for misuse.

I'm still not proficient enough in GCS to know how exactly this could be
abused (e.g., somehow writing the desired return location right above
one of these inactive caps and arranging for GCSPR to point to the cap
before returning from a signal) but to be safe or paranoid, perhaps zero
the location of the cap before returning?

> +
> +	return 0;
> +}
> +
> +#else
> +static int gcs_restore_signal(void) { return 0; }
> +#endif
> +
>  SYSCALL_DEFINE0(rt_sigreturn)
>  {
>  	struct pt_regs *regs = current_pt_regs();
> @@ -841,6 +912,9 @@ SYSCALL_DEFINE0(rt_sigreturn)
>  	if (restore_altstack(&frame->uc.uc_stack))
>  		goto badframe;
>  
> +	if (gcs_restore_signal())
> +		goto badframe;
> +
>  	return regs->regs[0];
>  
>  badframe:
> @@ -1071,7 +1145,50 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
>  	return 0;
>  }
>  
> -static void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
> +#ifdef CONFIG_ARM64_GCS
> +
> +static int gcs_signal_entry(__sigrestore_t sigtramp, struct ksignal *ksig)

The ksig argument is unused, so it can be removed.

> +{
> +	unsigned long __user *gcspr_el0;
> +	int ret = 0;
> +
> +	if (!system_supports_gcs())
> +		return 0;
> +
> +	if (!task_gcs_el0_enabled(current))
> +		return 0;
> +
> +	/*
> +	 * We are entering a signal handler, current register state is
> +	 * active.
> +	 */
> +	gcspr_el0 = (unsigned long __user *)read_sysreg_s(SYS_GCSPR_EL0);
> +
> +	/*
> +	 * Push a cap and the GCS entry for the trampoline onto the GCS.
> +	 */
> +	put_user_gcs((unsigned long)sigtramp, gcspr_el0 - 2, &ret);
> +	put_user_gcs(GCS_SIGNAL_CAP(gcspr_el0 - 1), gcspr_el0 - 1, &ret);
> +	if (ret != 0)
> +		return ret;
> +
> +	gcsb_dsync();
> +
> +	gcspr_el0 -= 2;
> +	write_sysreg_s((unsigned long)gcspr_el0, SYS_GCSPR_EL0);
> +
> +	return 0;
> +}
> +#else
> +
> +static int gcs_signal_entry(__sigrestore_t sigtramp, struct ksignal *ksig)
> +{
> +	return 0;
> +}
> +
> +#endif
> +
> +static int setup_return(struct pt_regs *regs, struct ksignal *ksig,
>  			 struct rt_sigframe_user_layout *user, int usig)

Since the ksig argument isn't used by gcs_signal_entry(), setup_return()
can keep the ka argument and the changes below from ka to ksic->ka are
unnecessary.

>  {
>  	__sigrestore_t sigtramp;
> @@ -1079,7 +1196,7 @@ static void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
>  	regs->regs[0] = usig;
>  	regs->sp = (unsigned long)user->sigframe;
>  	regs->regs[29] = (unsigned long)&user->next_frame->fp;
> -	regs->pc = (unsigned long)ka->sa.sa_handler;
> +	regs->pc = (unsigned long)ksig->ka.sa.sa_handler;
>  
>  	/*
>  	 * Signal delivery is a (wacky) indirect function call in
> @@ -1119,12 +1236,14 @@ static void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
>  		sme_smstop();
>  	}
>  
> -	if (ka->sa.sa_flags & SA_RESTORER)
> -		sigtramp = ka->sa.sa_restorer;
> +	if (ksig->ka.sa.sa_flags & SA_RESTORER)
> +		sigtramp = ksig->ka.sa.sa_restorer;
>  	else
>  		sigtramp = VDSO_SYMBOL(current->mm->context.vdso, sigtramp);
>  
>  	regs->regs[30] = (unsigned long)sigtramp;
> +
> +	return gcs_signal_entry(sigtramp, ksig);
>  }
>  
>  static int setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
> @@ -1147,7 +1266,7 @@ static int setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
>  	err |= __save_altstack(&frame->uc.uc_stack, regs->sp);
>  	err |= setup_sigframe(&user, regs, set);
>  	if (err == 0) {
> -		setup_return(regs, &ksig->ka, &user, usig);
> +		err = setup_return(regs, ksig, &user, usig);
>  		if (ksig->ka.sa.sa_flags & SA_SIGINFO) {
>  			err |= copy_siginfo_to_user(&frame->info, &ksig->info);
>  			regs->regs[1] = (unsigned long)&frame->info;
> diff --git a/arch/arm64/mm/gcs.c b/arch/arm64/mm/gcs.c
> index 02f8f6046c10..6f51429c5a46 100644
> --- a/arch/arm64/mm/gcs.c
> +++ b/arch/arm64/mm/gcs.c
> @@ -6,6 +6,7 @@
>  #include <linux/types.h>
>  
>  #include <asm/cpufeature.h>
> +#include <asm/gcs.h>
>  #include <asm/page.h>

This is #include isn't needed by this patch. Probably better as part of
another one.

-- 
Thiago


From tony at atomide.com  Fri Dec  8 19:59:00 2023
From: tony at atomide.com (Tony Lindgren)
Date: Sat, 9 Dec 2023 05:59:00 +0200
Subject: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc
 for wkup_uart0
In-Reply-To: <7hedfwd3co.fsf@baylibre.com>
References: <20231114073209.40756-1-tony@atomide.com>
 <7h5y1c7c0q.fsf@baylibre.com>
 <20231207060854.GQ5169@atomide.com>
 <7hedfwd3co.fsf@baylibre.com>
Message-ID: <20231209035900.GW5169@atomide.com>

* Kevin Hilman <khilman at kernel.org> [231208 17:13]:
> Tony Lindgren <tony at atomide.com> writes:
> 
> > * Kevin Hilman <khilman at kernel.org> [231205 18:14]:
> >> I'm a little confused why these power-domain and clocks stay here and
> >> are not moved under the wkup_uart0 node... 
> >
> > The resources are also needed by the interconnect target module. It's the
> > wrapper IP for the child device(s). In this case there's one chip 8250 IP
> > instance. In some other devices there can be multiple child IP devices
> > wired to one target module.
> >
> >> > -		clock-names = "fclk";
> >> > -		status = "disabled";
> >> > +		clock-names = "fck";
> >> > +		#address-cells = <1>;
> >> > +		#size-cells = <1>;
> >> > +		ranges = <0 0 0x2b300000 0x100000>;
> >> > +
> >> > +		wkup_uart0: serial at 2b300000 {
> >> > +			compatible = "ti,am64-uart", "ti,am654-uart";
> >> > +			reg = <0 0x100>;
> >> > +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> >> > +			status = "disabled";
> >> 
> >> ...here.
> >> 
> >> The SCI device ID 114 is specifically for wkup_uart0[1], so it seems to
> >> me those should be in the wkup_uart0 node.
> >
> > Those resources are also needed for the parent target module for revision
> > detection, quirks, reset, idle register configuration, and to probe the
> > child devices.
> >
> > Here the 8250 IP can be set to status = "reserved" when used by the
> > firmware, and 8250 not touched by Linux. However, the parent interconnect
> > target module still needs to be configured for idle registers and wake-up
> > path register bit so the wake-up from deeper suspend states works.
> 
> OK, makes sense.  Thanks for the clarification.

One more thing to clarify, there's nothing stopping also mapping the needed
resources for the child IP too if needed by the driver or the dts binding.
The calls for resources by the 8250 driver just won't do anything as the
resources are already enabled by the parent.

> In that case, shouldn't the same be done for the other wakeup sources
> there (e.g. wkup_rtc0) ?

Yes it should be done for devices with the wake-up path wired like
wkup_rtc0.

Regards,

Tony


From andersson at kernel.org  Fri Dec  8 20:24:44 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Fri, 8 Dec 2023 20:24:44 -0800
Subject: [PATCH net v3] net: stmmac: update Rx clk divider for 10M SGMII
In-Reply-To: <20231208062502.13124-1-quic_snehshah@quicinc.com>
References: <20231208062502.13124-1-quic_snehshah@quicinc.com>
Message-ID: <5luxwdjyzkg5o6w27mqixggr65ebosnn53vaqrbtsclfudet4v@kse23pgyj7ld>

On Fri, Dec 08, 2023 at 11:55:02AM +0530, Sneh Shah wrote:
> SGMII 10MBPS mode needs RX clock divider to avoid drops in Rx.
> Update configure SGMII function with rx clk divider programming.

Are you trying saying that the RX clock is completely wrong in 10MBps
mode? Or is the RX clock good, but without some division of some other
clock signal you loose some packets now and then?

Please write your commit message such that it describe the actual
problem you're having. This will help others to know if this fix is
applicable to some issue they are seeing on their hardware, now and in
the future.

> 
> Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> ---
> v3 changelog:
> - Added comment to explain why MAC needs to be reconfigured for SGMII
> v2 changelog:
> - Use FIELD_PREP to prepare bifield values in place of GENMASK
> - Add fixes tag
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index d3bf42d0fceb..ab2245995bc6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -34,6 +34,7 @@
>  #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
>  #define RGMII_CONFIG_PROG_SWAP			BIT(1)
>  #define RGMII_CONFIG_DDR_MODE			BIT(0)
> +#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)

This new bitfield overlaps with existing fields, is it the same
register? Did the fields move? Is it applicable to all versions?

What will existing writes to RGMII_IO_MACRO_CONFIG do to this new
layout? What will the new write do to hardware with the existing field
layout?

>  
>  /* SDCC_HC_REG_DLL_CONFIG fields */
>  #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
> @@ -598,6 +599,9 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>  	return 0;
>  }
>  
> +/* On interface toggle MAC registetrs gets reset.
> + * Configure MAC block for SGMII on ethernet phy link up
> + */
>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  {
>  	int val;
> @@ -617,6 +621,9 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  	case SPEED_10:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> +		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
> +			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR, 0x31),

Is this just a magic constant, or does 0x31 of some convenient unit?
Could we give it name/define?

Regards,
Bjorn

> +			      RGMII_IO_MACRO_CONFIG);
>  		break;
>  	}
>  
> -- 
> 2.17.1
> 
> 


From leo.yan at linaro.org  Fri Dec  8 20:31:35 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 9 Dec 2023 12:31:35 +0800
Subject: [PATCH V2 2/5] perf mem: Clean up perf_mem_events__ptr()
In-Reply-To: <20231207192338.400336-3-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-3-kan.liang@linux.intel.com>
Message-ID: <20231209043135.GA2116834@leoy-yangtze.lan>

On Thu, Dec 07, 2023 at 11:23:35AM -0800, kan.liang at linux.intel.com wrote:
> From: Kan Liang <kan.liang at linux.intel.com>
> 
> The mem_events can be retrieved from the struct perf_pmu now. An ARCH
> specific perf_mem_events__ptr() is not required anymore. Remove all of
> them.
> 
> The Intel hybrid has multiple mem-events-supported PMUs. But they share
> the same mem_events. Other ARCHs only support one mem-events-supported
> PMU. In the configuration, it's good enough to only configure the
> mem_events for one PMU. Add perf_mem_events_find_pmu() which returns the
> first mem-events-supported PMU.
> 
> In the perf_mem_events__init(), the perf_pmus__scan() is not required
> anymore. It avoids checking the sysfs for every PMU on the system.
> 
> Make the perf_mem_events__record_args() more generic. Remove the
> perf_mem_events__print_unsupport_hybrid().
> 
> Since pmu is added as a new parameter, rename perf_mem_events__ptr() to
> perf_pmu__mem_events_ptr(). Several other functions also do a similar
> rename.
> 
> Reviewed-by: Ian Rogers <irogers at google.com>
> Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
> ---
>  tools/perf/arch/arm64/util/mem-events.c |  10 +--
>  tools/perf/arch/x86/util/mem-events.c   |  18 ++---
>  tools/perf/builtin-c2c.c                |  28 +++++--
>  tools/perf/builtin-mem.c                |  28 +++++--
>  tools/perf/util/mem-events.c            | 103 ++++++++++++------------
>  tools/perf/util/mem-events.h            |   9 ++-
>  6 files changed, 104 insertions(+), 92 deletions(-)
> 
> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
> index aaa4804922b4..2602e8688727 100644
> --- a/tools/perf/arch/arm64/util/mem-events.c
> +++ b/tools/perf/arch/arm64/util/mem-events.c
> @@ -12,17 +12,9 @@ struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
>  
>  static char mem_ev_name[100];
>  
> -struct perf_mem_event *perf_mem_events__ptr(int i)
> -{
> -	if (i >= PERF_MEM_EVENTS__MAX)
> -		return NULL;
> -
> -	return &perf_mem_events_arm[i];
> -}
> -
>  const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
>  {
> -	struct perf_mem_event *e = perf_mem_events__ptr(i);
> +	struct perf_mem_event *e = &perf_mem_events_arm[i];
>  
>  	if (i >= PERF_MEM_EVENTS__MAX)
>  		return NULL;

Nitpick: it's good to check if 'i' is a valid value and then access the
array with a valid index.

        if (i >= PERF_MEM_EVENTS__MAX)
                return NULL;

        e = &perf_mem_events_arm[i];

> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index 2b81d229982c..5fb41d50118d 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -28,17 +28,6 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
>  	E("mem-ldst",	"ibs_op//",	"ibs_op"),
>  };
>  
> -struct perf_mem_event *perf_mem_events__ptr(int i)
> -{
> -	if (i >= PERF_MEM_EVENTS__MAX)
> -		return NULL;
> -
> -	if (x86__is_amd_cpu())
> -		return &perf_mem_events_amd[i];
> -
> -	return &perf_mem_events_intel[i];
> -}
> -
>  bool is_mem_loads_aux_event(struct evsel *leader)
>  {
>  	struct perf_pmu *pmu = perf_pmus__find("cpu");
> @@ -54,7 +43,12 @@ bool is_mem_loads_aux_event(struct evsel *leader)
>  
>  const char *perf_mem_events__name(int i, const char *pmu_name)
>  {
> -	struct perf_mem_event *e = perf_mem_events__ptr(i);
> +	struct perf_mem_event *e;

A nitpick as well:

Given perf's mem/c2c, callers will almostly invoke a valid index via the
argument 'i', but I still think here is a best place to return NULL
pointer for an invalid index rather than returning a wild pointer.

Thus I suggest to apply checking for x86 and other archs:

        if (i >= PERF_MEM_EVENTS__MAX)
                return NULL;

> +
> +	if (x86__is_amd_cpu())
> +		e = &perf_mem_events_amd[i];
> +	else
> +		e = &perf_mem_events_intel[i];
>  
>  	if (!e)
>  		return NULL;

[...]

>  int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
>  				 char **rec_tmp, int *tmp_nr)
>  {
>  	const char *mnt = sysfs__mount();
> +	struct perf_pmu *pmu = NULL;
>  	int i = *argv_nr, k = 0;
>  	struct perf_mem_event *e;
>  
> -	for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
> -		e = perf_mem_events__ptr(j);
> -		if (!e->record)
> -			continue;
>  
> -		if (perf_pmus__num_mem_pmus() == 1) {
> -			if (!e->supported) {
> -				pr_err("failed: event '%s' not supported\n",
> -				       perf_mem_events__name(j, NULL));
> -				return -1;
> -			}
> +	while ((pmu = perf_pmus__scan_mem(pmu)) != NULL) {
> +		for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
> +			e = perf_pmu__mem_events_ptr(pmu, j);
>  
> -			rec_argv[i++] = "-e";
> -			rec_argv[i++] = perf_mem_events__name(j, NULL);
> -		} else {
> -			struct perf_pmu *pmu = NULL;
> +			if (!e->record)
> +				continue;
>  
>  			if (!e->supported) {
> -				perf_mem_events__print_unsupport_hybrid(e, j);
> +				pr_err("failed: event '%s' not supported\n",
> +					perf_mem_events__name(j, pmu->name));
>  				return -1;
>  			}
>  
> -			while ((pmu = perf_pmus__scan(pmu)) != NULL) {
> +			if (perf_pmus__num_mem_pmus() == 1) {
> +				rec_argv[i++] = "-e";
> +				rec_argv[i++] = perf_mem_events__name(j, NULL);
> +			} else {
>  				const char *s = perf_mem_events__name(j, pmu->name);
>  
>  				if (!perf_mem_event__supported(mnt, pmu, e))

I think we can improve a bit for this part.

Current implementation uses perf_pmus__num_mem_pmus() to decide if
system has only one memory PMU or multiple PMUs, and multiple PMUs
the tool iterates all memory PMUs to synthesize event options.

In this patch, it has changed to iterate all memory PMUs, no matter the
system has only one memory PMU or multiple PMUs. Thus, I don't see the
point for the condition checking for "perf_pmus__num_mem_pmus() == 1".
We can consolidate into the unified code like:

        char *copy;
        const char *s = perf_pmu__mem_events_name(j, pmu);

        if (!s)
                continue;

        if (!perf_pmu__mem_events_supported(mnt, pmu, e))
                continue;

        copy = strdup(s);
        if (!copy)
                return -1;

        rec_argv[i++] = "-e";
        rec_argv[i++] = copy;
        rec_tmp[k++] = copy;

Thanks,
Leo


From lkp at intel.com  Fri Dec  8 20:37:31 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 9 Dec 2023 12:37:31 +0800
Subject: [PATCH 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231208202108.7468-2-kamal.dasu@broadcom.com>
References: <20231208202108.7468-2-kamal.dasu@broadcom.com>
Message-ID: <202312091235.tzqwgYfT-lkp@intel.com>

Hi Kamal,

kernel test robot noticed the following build warnings:

[auto build test WARNING on robh/for-next]
[also build test WARNING on soc/for-next linus/master v6.7-rc4 next-20231208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Kamal-Dasu/mmc-add-new-sdhci-reset-sequence-for-brcm-74165b0/20231209-042222
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/20231208202108.7468-2-kamal.dasu%40broadcom.com
patch subject: [PATCH 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
config: arc-randconfig-001-20231209 (https://download.01.org/0day-ci/archive/20231209/202312091235.tzqwgYfT-lkp at intel.com/config)
compiler: arceb-elf-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231209/202312091235.tzqwgYfT-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312091235.tzqwgYfT-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> drivers/mmc/host/sdhci-brcmstb.c:237:16: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
     237 |         .ops = &sdhci_brcmstb_ops_74165b0,
         |                ^


vim +/const +237 drivers/mmc/host/sdhci-brcmstb.c

   233	
   234	static const struct brcmstb_match_priv match_priv_74165b0 = {
   235		.flags = BRCMSTB_MATCH_FLAGS_HAS_CLOCK_GATE,
   236		.hs400es = sdhci_brcmstb_hs400es,
 > 237		.ops = &sdhci_brcmstb_ops_74165b0,
   238	};
   239	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From leo.yan at linaro.org  Fri Dec  8 21:48:09 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 9 Dec 2023 13:48:09 +0800
Subject: [PATCH V2 3/5] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <20231207192338.400336-4-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-4-kan.liang@linux.intel.com>
Message-ID: <20231209054809.GB2116834@leoy-yangtze.lan>

On Thu, Dec 07, 2023 at 11:23:36AM -0800, kan.liang at linux.intel.com wrote:
> From: Kan Liang <kan.liang at linux.intel.com>
> 
> Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
> one.

Now memory event naming is arch dependent, this is because every arch
has different memory PMU names, and it appends specific configurations
(e.g. aarch64 appends 'ts_enable=1,...,min_latency=%u', and x86_64
appends 'ldlat=%u', etc).  This is not friendly for extension, e.g. it's
impossible for users to specify any extra attributes for memory events.

This patch tries to consolidate in a central place for generating memory
event names, its approach is to add more flags to meet special usage
cases, which means the code gets more complex (and more difficult for
later's maintenance).

I think we need to distinguish the event naming into two levels: in
util/mem-events.c, we can consider it as a common layer, and we maintain
common options in it, e.g. 'latency', 'all-user', 'all-kernel',
'timestamp', 'physical_address', etc.  In every arch's mem-events.c
file, it converts the common options to arch specific configurations.

In the end, this can avoid to add more and more flags into the
structure perf_mem_event.

Anyway, I also have a question for this patch itself, please see below
inline comment.

[...]

> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
> index 2602e8688727..eb2ef84f0fc8 100644
> --- a/tools/perf/arch/arm64/util/mem-events.c
> +++ b/tools/perf/arch/arm64/util/mem-events.c
> @@ -2,28 +2,10 @@
>  #include "map_symbol.h"
>  #include "mem-events.h"
>  
> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>  
>  struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
> -	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
> -	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
> -	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
> +	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0",	true,	0),
> +	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0",	false,	0),
> +	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0",	true,	0),

Arm SPE is AUX event, should set '1' to the field '.aux_event'.

I am a bit suspect if we really need the field '.aux_event', the
'.aux_event' field is only used for generating event string.

So in the below function perf_pmu__mem_events_name(), I prefer to call
an arch specific function, e.g. arch_memory_event_name(event_id, cfg),
the parameter 'event_id' passes memory event ID for load, store, and
load-store, and the parameter 'cfg' which is a pointer to the common
memory options (as mentioned above for latency, all-user or all-kernel
mode, timestamp tracing, etc).

In the end, the common layer just passes the common options to low
level arch's layer and get a event string for recording.

Thanks,
Leo


From leo.yan at linaro.org  Fri Dec  8 22:17:23 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 9 Dec 2023 14:17:23 +0800
Subject: [PATCH V2 4/5] perf mem: Clean up perf_mem_event__supported()
In-Reply-To: <20231207192338.400336-5-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-5-kan.liang@linux.intel.com>
Message-ID: <20231209061723.GC2116834@leoy-yangtze.lan>

On Thu, Dec 07, 2023 at 11:23:37AM -0800, kan.liang at linux.intel.com wrote:
> From: Kan Liang <kan.liang at linux.intel.com>
> 
> For some ARCHs, e.g., ARM and AMD, to get the availability of the
> mem-events, perf checks the existence of a specific PMU. For the other
> ARCHs, e.g., Intel and Power, perf has to check the existence of some
> specific events.
> 
> The current perf only iterates the mem-events-supported PMUs. It's not
> required to check the existence of a specific PMU anymore.

With this change, both Arm and AMD archs have no chance to detect if the
hardware (or the device driver) is supported and the tool will always
take the memory events are exited on the system, right?

Thanks,
Leo


From leo.yan at linaro.org  Fri Dec  8 22:27:09 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 9 Dec 2023 14:27:09 +0800
Subject: [PATCH V2 5/5] perf mem: Clean up is_mem_loads_aux_event()
In-Reply-To: <20231207192338.400336-6-kan.liang@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-6-kan.liang@linux.intel.com>
Message-ID: <20231209062709.GD2116834@leoy-yangtze.lan>

On Thu, Dec 07, 2023 at 11:23:38AM -0800, kan.liang at linux.intel.com wrote:
> From: Kan Liang <kan.liang at linux.intel.com>
> 
> The aux_event can be retrieved from the perf_pmu now. Implement a
> generic support.
> 
> Reviewed-by: Ian Rogers <irogers at google.com>
> Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
> ---
>  tools/perf/arch/x86/util/mem-events.c | 23 ++++-------------------
>  tools/perf/util/mem-events.c          | 14 ++++++++++++--
>  2 files changed, 16 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index b776d849fc64..62df03e91c7e 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -1,11 +1,9 @@
>  // SPDX-License-Identifier: GPL-2.0
> -#include "util/pmu.h"
> -#include "util/pmus.h"
> -#include "util/env.h"
> -#include "map_symbol.h"
> -#include "mem-events.h"
>  #include "linux/string.h"
> -#include "env.h"
> +#include "util/map_symbol.h"
> +#include "util/mem-events.h"
> +#include "mem-events.h"
> +
>  
>  #define MEM_LOADS_AUX		0x8203
>  
> @@ -28,16 +26,3 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
>  	E(NULL,		NULL,		NULL,	false,	0),
>  	E("mem-ldst",	"%s//",		NULL,	false,	0),
>  };
> -
> -bool is_mem_loads_aux_event(struct evsel *leader)
> -{
> -	struct perf_pmu *pmu = perf_pmus__find("cpu");
> -
> -	if (!pmu)
> -		pmu = perf_pmus__find("cpu_core");
> -
> -	if (pmu && !perf_pmu__have_event(pmu, "mem-loads-aux"))
> -		return false;
> -
> -	return leader->core.attr.config == MEM_LOADS_AUX;
> -}
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index 0d174f161034..d418320e52e3 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -103,9 +103,19 @@ static const char *perf_pmu__mem_events_name(int i, struct perf_pmu *pmu)
>  	return NULL;
>  }
>  
> -__weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
> +bool is_mem_loads_aux_event(struct evsel *leader)
>  {
> -	return false;
> +	struct perf_pmu *pmu = leader->pmu;
> +	struct perf_mem_event *e;
> +
> +	if (!pmu || !pmu->mem_events)
> +		return false;
> +
> +	e = &pmu->mem_events[PERF_MEM_EVENTS__LOAD];
> +	if (!e->aux_event)
> +		return false;
> +
> +	return leader->core.attr.config == e->aux_event;
>  }

I am wandering if we need to set the field 'aux_event' for Arm SPE.

So a quesiton maybe is not relevant with this patch actually, we can
see is_mem_loads_aux_event() is invoked in the file util/record.c:

  static struct evsel *evsel__read_sampler(struct evsel *evsel, struct evlist *evlist)
  {
          struct evsel *leader = evsel__leader(evsel);

          if (evsel__is_aux_event(leader) || arch_topdown_sample_read(leader) ||
              is_mem_loads_aux_event(leader)) {
              ...
          }
  
          return leader;
  }

Has evsel__is_aux_event() covered the memory load aux event?  If it's,
then is_mem_loads_aux_event() is not needed anymore.

Thanks,
Leo


From dan.carpenter at linaro.org  Fri Dec  8 22:27:42 2023
From: dan.carpenter at linaro.org (Dan Carpenter)
Date: Sat, 9 Dec 2023 09:27:42 +0300
Subject: [PATCH v3 3/4] staging: vc04_services: Drop vchiq_log_trace() in
 favour of dev_dbg
In-Reply-To: <46e42bbf-e99b-4e61-a207-35e150fe4fd2@gmx.net>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-4-umang.jain@ideasonboard.com>
 <46e42bbf-e99b-4e61-a207-35e150fe4fd2@gmx.net>
Message-ID: <1883402c-edad-48b7-9081-32ec3538667b@suswa.mountain>

On Fri, Dec 08, 2023 at 01:08:04PM +0100, Stefan Wahren wrote:
> > @@ -1425,7 +1416,7 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
> >   	}
> > 
> >   out:
> > -	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s exit %d", __func__, ret);
> > +	dev_dbg(state->dev, "suspend: exit %d\n", ret);
> In case we want to keep this kind of debug messages, i prefer to have a
> common format:
> 
> returning %d vs exit %d

Someone was trying to make ftrace track return values...  Whatever
happened with that work?

regards,
dan carpenter



From leo.yan at linaro.org  Fri Dec  8 22:34:40 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 9 Dec 2023 14:34:40 +0800
Subject: [PATCH V2 1/5] perf mem: Add mem_events into the supported
 perf_pmu
In-Reply-To: <98863f44-4a35-4910-8db0-dbbf0474f6ae@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-2-kan.liang@linux.intel.com>
 <20231208102922.GB769184@leoy-huanghe.lan>
 <98863f44-4a35-4910-8db0-dbbf0474f6ae@linux.intel.com>
Message-ID: <20231209063440.GE2116834@leoy-yangtze.lan>

Hi Kan,

On Fri, Dec 08, 2023 at 01:14:28PM -0500, Liang, Kan wrote:

[...]

> > Now I cannot access a machine for testing Arm SPE, but I will play
> > a bit for this patch set to ensure it can pass compilation.  After
> > that, I will seek Arm maintainers/reviewers help for the test.
> 
> Thanks. I guess I will hold the v3 until the test is done in case there
> are other issues found in ARM.

I will hold on a bit for the test until this patch set addresses the
concern for the breakage issues on Arm64.  Please check my review in
other replies.

Thanks,
Leo


From krzysztof.kozlowski at linaro.org  Fri Dec  8 23:52:49 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 9 Dec 2023 08:52:49 +0100
Subject: [V2, 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for
 74165b0
In-Reply-To: <20231208210230.8191-1-kamal.dasu@broadcom.com>
References: <20231208210230.8191-1-kamal.dasu@broadcom.com>
Message-ID: <15edf785-3fab-4c0e-a96a-9753c3446370@linaro.org>

On 08/12/2023 22:02, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> With newer sdio controller core used for 74165b0 we need to update
> the compatibility with "brcm,bcm74165b0-sdhci".
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> ---
>  Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
> index c028039bc477..178d47ed65ca 100644
> --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
> +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
> @@ -13,6 +13,10 @@ maintainers:
>  properties:
>    compatible:
>      oneOf:
> +      - items:
> +          - enum:
> +              - brcm,bcm74165b0-sdhci

If this is enum, then it should be combined with other enums like that.
Someone already duplicated this once, so don't make it third time. One
enum for all your variants with the same fallback.

Best regards,
Krzysztof



From lkp at intel.com  Sat Dec  9 00:42:07 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 9 Dec 2023 16:42:07 +0800
Subject: [PATCH 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231208202108.7468-2-kamal.dasu@broadcom.com>
References: <20231208202108.7468-2-kamal.dasu@broadcom.com>
Message-ID: <202312091608.0VbkRxlh-lkp@intel.com>

Hi Kamal,

kernel test robot noticed the following build errors:

[auto build test ERROR on robh/for-next]
[also build test ERROR on soc/for-next linus/master v6.7-rc4 next-20231208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Kamal-Dasu/mmc-add-new-sdhci-reset-sequence-for-brcm-74165b0/20231209-042222
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/20231208202108.7468-2-kamal.dasu%40broadcom.com
patch subject: [PATCH 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
config: arm-defconfig (https://download.01.org/0day-ci/archive/20231209/202312091608.0VbkRxlh-lkp at intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project.git f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231209/202312091608.0VbkRxlh-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312091608.0VbkRxlh-lkp at intel.com/

All errors (new ones prefixed by >>):

>> drivers/mmc/host/sdhci-brcmstb.c:237:9: error: initializing 'struct sdhci_ops *' with an expression of type 'const struct sdhci_ops *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
           .ops = &sdhci_brcmstb_ops_74165b0,
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~
   1 error generated.


vim +237 drivers/mmc/host/sdhci-brcmstb.c

   233	
   234	static const struct brcmstb_match_priv match_priv_74165b0 = {
   235		.flags = BRCMSTB_MATCH_FLAGS_HAS_CLOCK_GATE,
   236		.hs400es = sdhci_brcmstb_hs400es,
 > 237		.ops = &sdhci_brcmstb_ops_74165b0,
   238	};
   239	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From raag.jadav at intel.com  Sat Dec  9 00:48:23 2023
From: raag.jadav at intel.com (Raag Jadav)
Date: Sat, 9 Dec 2023 10:48:23 +0200
Subject: [PATCH v3 5/5] perf: arm_cspmu: drop redundant
 acpi_dev_uid_to_integer()
In-Reply-To: <20231123100617.28020-6-raag.jadav@intel.com>
References: <20231123100617.28020-1-raag.jadav@intel.com>
 <20231123100617.28020-6-raag.jadav@intel.com>
Message-ID: <ZXQp18e9IR5w41wW@black.fi.intel.com>

On Thu, Nov 23, 2023 at 03:36:17PM +0530, Raag Jadav wrote:
> Now that we have _UID matching support for integer types, we can use
> acpi_dev_hid_uid_match() for it.
> 
> Signed-off-by: Raag Jadav <raag.jadav at intel.com>
> Acked-by: Will Deacon <will at kernel.org>
> ---
>  drivers/perf/arm_cspmu/arm_cspmu.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
> index 2cc35dded007..50b89b989ce7 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> @@ -1108,7 +1108,6 @@ static int arm_cspmu_request_irq(struct arm_cspmu *cspmu)
>  
>  static inline int arm_cspmu_find_cpu_container(int cpu, u32 container_uid)
>  {
> -	u64 acpi_uid;
>  	struct device *cpu_dev;
>  	struct acpi_device *acpi_dev;
>  
> @@ -1118,8 +1117,7 @@ static inline int arm_cspmu_find_cpu_container(int cpu, u32 container_uid)
>  
>  	acpi_dev = ACPI_COMPANION(cpu_dev);
>  	while (acpi_dev) {
> -		if (acpi_dev_hid_uid_match(acpi_dev, ACPI_PROCESSOR_CONTAINER_HID, NULL) &&
> -		    !acpi_dev_uid_to_integer(acpi_dev, &acpi_uid) && acpi_uid == container_uid)
> +		if (acpi_dev_hid_uid_match(acpi_dev, ACPI_PROCESSOR_CONTAINER_HID, container_uid))
>  			return 0;

On second thought, I just realized that this can cause false positive
in case container_uid is integer 0.

I'm not aware if that's a valid value to match against in APMT.
If it is, it's better to drop patches 2 and 5 for now.

Raag


From sean at mess.org  Sat Dec  9 01:11:17 2023
From: sean at mess.org (Sean Young)
Date: Sat, 9 Dec 2023 09:11:17 +0000
Subject: [PATCH v6 3/4] pwm: bcm2835: allow pwm driver to be used in
 atomic context
In-Reply-To: <20231208172040.mgw7aicmwlw6yjyb@pengutronix.de>
References: <cover.1701248996.git.sean@mess.org>
 <179dc1ce85702a8b64b43c0e0df656b0c5e3ce30.1701248996.git.sean@mess.org>
 <ZXNC3JYy7CTfYsyC@orome.fritz.box>
 <ZXNL5upeUPc4gC1R@gofer.mess.org>
 <20231208172040.mgw7aicmwlw6yjyb@pengutronix.de>
Message-ID: <ZXQvNfLy9mySdrfM@gofer.mess.org>

On Fri, Dec 08, 2023 at 06:20:40PM +0100, Uwe Kleine-K?nig wrote:
> On Fri, Dec 08, 2023 at 05:01:26PM +0000, Sean Young wrote:
> > On Fri, Dec 08, 2023 at 05:22:52PM +0100, Thierry Reding wrote:
> > > On Wed, Nov 29, 2023 at 09:13:36AM +0000, Sean Young wrote:
> > > > clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
> > > > rate changes using clk_rate_exclusive_get().
> > > > 
> > > > Signed-off-by: Sean Young <sean at mess.org>
> > > > ---
> > > >  drivers/pwm/pwm-bcm2835.c | 31 +++++++++++++++++++++----------
> > > >  1 file changed, 21 insertions(+), 10 deletions(-)
> > > 
> > > s/pwm/PWM/ in the subject. Although, I guess you could just drop the
> > > "PWM" altogether because the subject prefix implies that this is for
> > > PWM.
> > 
> > $ git log --no-merges --oneline drivers/pwm/ | sed -r 's/^\w* ([^:]+): .*/\1/' | sort | uniq -c
> >    1197 pwm
> >       1 PWM
> >   ...
> > 
> > The vast majority of the commits use pwm: as a prefix, only one uses PWM:. 
> > In fact if you look across the tree almost everywhere lower case is used
> > for the prefix.
> 
> Thierry doesn't want you to change the subject prefix, but only the
> second "pwm" to make it read:
> 
> 	pwm: bcm2835: allow PWM driver to be used in atomic context

Ah of course, my bad.

> While I understand Thierry here, I'm fine with a lowercase pwm here,
> too. In my book a PWM in all uppercase is the type of hardware and pwm
> in all lowercase is the framework's name. If you use "PWM driver" or
> "pwm driver" then doesn't matter much.
> 
> 	
> > 
> > I'm just trying to follow convention.
> > 
> > Having said that, I think the prefix is totally redundant, it is clear from
> > the commit files what they are affecting. I am not sure what it really adds.
> > 
> > > Also, please capitalize after the subject prefix.
> > 
> > $ git log --no-merges --oneline drivers/pwm/ | grep -E '^\w* ([^:]+): [A-Z]' | wc -l
> > 217
> > $ git log --no-merges --oneline drivers/pwm/ | grep -E '^\w* ([^:]+): [a-z]' | wc -l
> > 1069
> 
> Your matching things like:
> 
> 	pwm: pwm-tiehrpwm: Add support for configuring polarity of PWM
> 
> with the second command. These are perfectly fine as pwm-tiehrpwm is the
> driver name and so shouldn't be capitalized. With a bit more care here,
> we get:
> 
> 	$ git log --no-merges --oneline drivers/pwm/ | grep -E '^.+: [a-z][^:]*$' | wc -l
> 	114
> 	$ git log --no-merges --oneline drivers/pwm/ | grep -E '^.+: [A-Z][^:]*$' | wc -l
> 	1167
> 
> And the newest of the 114 with a small letter is from 2013.

Again, I stand corrected.

Thanks for pointing it out, I will fix in the next version.


Sean


From gregkh at linuxfoundation.org  Sat Dec  9 01:28:36 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Sat, 9 Dec 2023 10:28:36 +0100
Subject: [PATCH 0/7] pcmcia: Convert to platform remove callback
 returning void
In-Reply-To: <ZXNsLJfqs9DLHb1Q@shine.dominikbrodowski.net>
References: <cover.1702051073.git.u.kleine-koenig@pengutronix.de>
 <ZXNsLJfqs9DLHb1Q@shine.dominikbrodowski.net>
Message-ID: <2023120930-possum-ignore-e8df@gregkh>

On Fri, Dec 08, 2023 at 08:19:08PM +0100, Dominik Brodowski wrote:
> Am Fri, Dec 08, 2023 at 05:08:05PM +0100 schrieb Uwe Kleine-K?nig:
> > Hello,
> > 
> > this series changes all platform drivers in drivers/pcmcia to use the
> > .remove_new() callback. See commit 5c5a7680e67b ("platform: Provide a
> > remove callback that returns no value") for an extended explanation and
> > the eventual goal.
> > 
> > All conversations are trivial, because all .remove() callbacks returned
> > zero unconditionally already.
> > 
> > There are no interdependencies between these patches, so they could be
> > picked up individually. However I'd expect them to go in all together.
> > It's unclrear to me though, who will pick them up. Dominik? Greg?
> 
> Both options are fine with me. In the latter case:
> 
> 	Acked-by: Dominik Brodowski <linux at dominikbrodowski.net>

I can take these, thanks!

greg k-h


From wahrenst at gmx.net  Sat Dec  9 01:33:21 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Sat, 9 Dec 2023 10:33:21 +0100
Subject: [PATCH v3 3/4] staging: vc04_services: Drop vchiq_log_trace() in
 favour of dev_dbg
In-Reply-To: <1883402c-edad-48b7-9081-32ec3538667b@suswa.mountain>
References: <20231205084157.73819-1-umang.jain@ideasonboard.com>
 <20231205084157.73819-4-umang.jain@ideasonboard.com>
 <46e42bbf-e99b-4e61-a207-35e150fe4fd2@gmx.net>
 <1883402c-edad-48b7-9081-32ec3538667b@suswa.mountain>
Message-ID: <1adbbd28-bdd0-4c65-bc59-fc0b8d6d034a@gmx.net>

Hi Dan,

Am 09.12.23 um 07:27 schrieb Dan Carpenter:
> On Fri, Dec 08, 2023 at 01:08:04PM +0100, Stefan Wahren wrote:
>>> @@ -1425,7 +1416,7 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
>>>    	}
>>>
>>>    out:
>>> -	vchiq_log_trace(state->dev, VCHIQ_SUSPEND, "%s exit %d", __func__, ret);
>>> +	dev_dbg(state->dev, "suspend: exit %d\n", ret);
>> In case we want to keep this kind of debug messages, i prefer to have a
>> common format:
>>
>> returning %d vs exit %d
> Someone was trying to make ftrace track return values...  Whatever
> happened with that work?
this feature has been merged, but it doesn't seem to be available for arm:

find -name Kconfig | xargs grep HAVE_FUNCTION_GRAPH_RETVAL
./kernel/trace/Kconfig:config HAVE_FUNCTION_GRAPH_RETVAL
./kernel/trace/Kconfig:??? depends on HAVE_FUNCTION_GRAPH_RETVAL
./arch/x86/Kconfig:??? select HAVE_FUNCTION_GRAPH_RETVAL??? if
HAVE_FUNCTION_GRAPH_TRACER
./arch/arm64/Kconfig:??? select HAVE_FUNCTION_GRAPH_RETVAL if
HAVE_FUNCTION_GRAPH_TRACER
./arch/s390/Kconfig:??? select HAVE_FUNCTION_GRAPH_RETVAL
./arch/riscv/Kconfig:??? select HAVE_FUNCTION_GRAPH_RETVAL if
HAVE_FUNCTION_GRAPH_TRACER
./arch/loongarch/Kconfig:??? select HAVE_FUNCTION_GRAPH_RETVAL if
HAVE_FUNCTION_GRAPH_TRACER

These debug messages are only in the error path, so i'm not sure if
someone what to hunt bugs by searching all that return values without
knowing which function is possibly affected.
>
> regards,
> dan carpenter
>



From lkp at intel.com  Sat Dec  9 01:58:55 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 09 Dec 2023 17:58:55 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS
 fd1e5745f87a9e06974d2f42d22b3e1682c99105
Message-ID: <202312091752.vFketA5Y-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: fd1e5745f87a9e06974d2f42d22b3e1682c99105  Merge tag 'v6.7-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes

elapsed time: 1471m

configs tested: 124
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              alldefconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                          axs101_defconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231209   gcc  
arc                   randconfig-002-20231209   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                                 defconfig   clang
arm                         lpc32xx_defconfig   clang
arm                   randconfig-001-20231209   gcc  
arm                   randconfig-002-20231209   gcc  
arm                   randconfig-003-20231209   gcc  
arm                   randconfig-004-20231209   gcc  
arm                           sama5_defconfig   gcc  
arm                        spear3xx_defconfig   clang
arm                        spear6xx_defconfig   gcc  
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231209   gcc  
arm64                 randconfig-002-20231209   gcc  
arm64                 randconfig-003-20231209   gcc  
arm64                 randconfig-004-20231209   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231209   gcc  
csky                  randconfig-002-20231209   gcc  
hexagon                           allnoconfig   clang
hexagon                             defconfig   clang
hexagon               randconfig-001-20231209   clang
hexagon               randconfig-002-20231209   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231208   clang
i386         buildonly-randconfig-002-20231208   clang
i386         buildonly-randconfig-003-20231208   clang
i386         buildonly-randconfig-004-20231208   clang
i386         buildonly-randconfig-005-20231208   clang
i386         buildonly-randconfig-006-20231208   clang
i386                                defconfig   gcc  
i386                  randconfig-001-20231208   clang
i386                  randconfig-002-20231208   clang
i386                  randconfig-003-20231208   clang
i386                  randconfig-004-20231208   clang
i386                  randconfig-005-20231208   clang
i386                  randconfig-006-20231208   clang
i386                  randconfig-011-20231208   gcc  
i386                  randconfig-012-20231208   gcc  
i386                  randconfig-013-20231208   gcc  
i386                  randconfig-014-20231208   gcc  
i386                  randconfig-015-20231208   gcc  
i386                  randconfig-016-20231208   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231209   gcc  
loongarch             randconfig-002-20231209   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                       m5208evb_defconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                          defconfig   gcc  
mips                              allnoconfig   clang
mips                      maltaaprp_defconfig   clang
mips                      pic32mzda_defconfig   clang
nios2                             allnoconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231209   gcc  
nios2                 randconfig-002-20231209   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231209   gcc  
parisc                randconfig-002-20231209   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                    mvme5100_defconfig   clang
powerpc               randconfig-001-20231209   gcc  
powerpc               randconfig-002-20231209   gcc  
powerpc               randconfig-003-20231209   gcc  
powerpc                     skiroot_defconfig   clang
powerpc64             randconfig-001-20231209   gcc  
powerpc64             randconfig-002-20231209   gcc  
powerpc64             randconfig-003-20231209   gcc  
riscv                             allnoconfig   clang
riscv                 randconfig-001-20231209   gcc  
riscv                 randconfig-002-20231209   gcc  
s390                             allmodconfig   gcc  
s390                             allyesconfig   gcc  
s390                  randconfig-001-20231209   clang
s390                  randconfig-002-20231209   clang
sh                               allmodconfig   gcc  
sh                               allyesconfig   gcc  
sh                    randconfig-001-20231209   gcc  
sh                    randconfig-002-20231209   gcc  
sh                           se7712_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64               randconfig-001-20231209   gcc  
sparc64               randconfig-002-20231209   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                    randconfig-001-20231209   gcc  
um                    randconfig-002-20231209   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64                              defconfig   gcc  
x86_64                          rhel-8.3-rust   clang
xtensa                randconfig-001-20231209   gcc  
xtensa                randconfig-002-20231209   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Sat Dec  9 02:03:03 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 09 Dec 2023 18:03:03 +0800
Subject: [soc:for-next] BUILD SUCCESS
 52cff57c4356cdbc6059cac327760f2797dc24a7
Message-ID: <202312091800.0dKiuxa9-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 52cff57c4356cdbc6059cac327760f2797dc24a7  Merge branch 'arm/fixes' into for-next

elapsed time: 1475m

configs tested: 143
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                          axs103_defconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231209   gcc  
arc                   randconfig-002-20231209   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                         bcm2835_defconfig   clang
arm                                 defconfig   clang
arm                          gemini_defconfig   gcc  
arm                            mps2_defconfig   gcc  
arm                         orion5x_defconfig   clang
arm                   randconfig-001-20231209   gcc  
arm                   randconfig-002-20231209   gcc  
arm                   randconfig-003-20231209   gcc  
arm                   randconfig-004-20231209   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231209   gcc  
arm64                 randconfig-002-20231209   gcc  
arm64                 randconfig-003-20231209   gcc  
arm64                 randconfig-004-20231209   gcc  
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231209   gcc  
csky                  randconfig-002-20231209   gcc  
hexagon                           allnoconfig   clang
hexagon                             defconfig   clang
hexagon               randconfig-001-20231209   clang
hexagon               randconfig-002-20231209   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231208   clang
i386         buildonly-randconfig-002-20231208   clang
i386         buildonly-randconfig-003-20231208   clang
i386         buildonly-randconfig-004-20231208   clang
i386         buildonly-randconfig-005-20231208   clang
i386         buildonly-randconfig-006-20231208   clang
i386                                defconfig   gcc  
i386                  randconfig-001-20231208   clang
i386                  randconfig-002-20231208   clang
i386                  randconfig-003-20231208   clang
i386                  randconfig-004-20231208   clang
i386                  randconfig-005-20231208   clang
i386                  randconfig-006-20231208   clang
i386                  randconfig-011-20231208   gcc  
i386                  randconfig-012-20231208   gcc  
i386                  randconfig-013-20231208   gcc  
i386                  randconfig-014-20231208   gcc  
i386                  randconfig-015-20231208   gcc  
i386                  randconfig-016-20231208   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231209   gcc  
loongarch             randconfig-002-20231209   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
mips                       bmips_be_defconfig   gcc  
mips                           xway_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231209   gcc  
nios2                 randconfig-002-20231209   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231209   gcc  
parisc                randconfig-002-20231209   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                     kilauea_defconfig   clang
powerpc               randconfig-001-20231209   gcc  
powerpc               randconfig-002-20231209   gcc  
powerpc               randconfig-003-20231209   gcc  
powerpc                      tqm8xx_defconfig   gcc  
powerpc64             randconfig-001-20231209   gcc  
powerpc64             randconfig-002-20231209   gcc  
powerpc64             randconfig-003-20231209   gcc  
riscv                             allnoconfig   clang
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231209   gcc  
riscv                 randconfig-002-20231209   gcc  
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231209   clang
s390                  randconfig-002-20231209   clang
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                          r7780mp_defconfig   gcc  
sh                    randconfig-001-20231209   gcc  
sh                    randconfig-002-20231209   gcc  
sh                          rsk7264_defconfig   gcc  
sh                             shx3_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231209   gcc  
sparc64               randconfig-002-20231209   gcc  
um                               alldefconfig   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                    randconfig-001-20231209   gcc  
um                    randconfig-002-20231209   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64                              defconfig   gcc  
x86_64                          rhel-8.3-rust   clang
xtensa                       common_defconfig   gcc  
xtensa                randconfig-001-20231209   gcc  
xtensa                randconfig-002-20231209   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From andyshrk at 163.com  Sat Dec  9 02:36:22 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sat,  9 Dec 2023 18:36:22 +0800
Subject: [PATCH 0/5] Add 2 rk3588 based boards from Cool Pi
Message-ID: <20231209103622.1568289-1-andyshrk@163.com>


This series add support for rk3588s based SBC Cool Pi 4B
and rk3588 based board Cool Pi CM5 EVB


Andy Yan (5):
  dt-bindings: vendor-prefixes: Add Cool Pi
  dt-bindings: arm: rockchip: Add Cool Pi 4B
  arm64: dts: rockchip: Add support for rk3588s based board CoolPi 4B
  dt-bindings: arm: rockchip: Add Cool Pi CM5 EVB
  arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5
    EVB

 .../devicetree/bindings/arm/rockchip.yaml     |  10 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/rockchip/Makefile         |   2 +
 .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 887 ++++++++++++++++++
 .../boot/dts/rockchip/rk3588s-coolpi-4b.dts   | 850 +++++++++++++++++
 5 files changed, 1751 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts

-- 
2.34.1



From andyshrk at 163.com  Sat Dec  9 02:37:07 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sat,  9 Dec 2023 18:37:07 +0800
Subject: [PATCH 1/5] dt-bindings: vendor-prefixes: Add Cool Pi
In-Reply-To: <20231209103622.1568289-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
Message-ID: <20231209103707.1568381-1-andyshrk@163.com>

Add vendor prefix for Cool Pi(https://cool-pi.com/)

Signed-off-by: Andy Yan <andyshrk at 163.com>

---

 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c8..ddbba46fcbad 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -294,6 +294,8 @@ patternProperties:
     description: CompuLab Ltd.
   "^congatec,.*":
     description: congatec GmbH
+  "^coolpi,.*":
+    description: cool-pi.com
   "^coreriver,.*":
     description: CORERIVER Semiconductor Co.,Ltd.
   "^corpro,.*":
-- 
2.34.1



From andyshrk at 163.com  Sat Dec  9 02:37:48 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sat,  9 Dec 2023 18:37:48 +0800
Subject: [PATCH 2/5] dt-bindings: arm: rockchip: Add Cool Pi 4B
In-Reply-To: <20231209103622.1568289-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
Message-ID: <20231209103748.1568462-1-andyshrk@163.com>

Add Cool Pi 4B, a SBC powered by RK3588S

Signed-off-by: Andy Yan <andyshrk at 163.com>
---

 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5deb66a5c7d9..5de9f3090be1 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -95,6 +95,11 @@ properties:
           - const: chipspark,rayeager-px2
           - const: rockchip,rk3066a
 
+      - description: Cool Pi 4 Model B
+        items:
+          - const: CoolPi 4 Model B
+          - const: rockchip,rk3588s
+
       - description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
         items:
           - const: edgeble,neural-compute-module-2-io   # Edgeble Neural Compute Module 2 IO Board
-- 
2.34.1



From andyshrk at 163.com  Sat Dec  9 02:38:02 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sat,  9 Dec 2023 18:38:02 +0800
Subject: [PATCH 3/5] arm64: dts: rockchip: Add support for rk3588s based board CoolPi 4B
In-Reply-To: <20231209103622.1568289-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
Message-ID: <20231209103802.1568552-1-andyshrk@163.com>

CoolPi 4B is a rk3588s based SBC.
Specification:
- Rockchip RK3588S
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- Gigabit ethernet drived by PCIE with RTL8111HS
- HDMI Type D out
- Mini DP out
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- WIFI/BT module AIC8800
- 40 pin header

Signed-off-by: Andy Yan <andyshrk at 163.com>
---

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3588s-coolpi-4b.dts   | 850 ++++++++++++++++++
 2 files changed, 851 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 41276ca535de..e59682691eb0 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -109,6 +109,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-orangepi-5-plus.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-quartzpro64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-turing-rk1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-coolpi-4b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
new file mode 100644
index 000000000000..cdfcdb2539ac
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
@@ -0,0 +1,850 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ * https://cool-pi.com/topic/130/coolpi-4b-product-spec-introduction
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3588s.dtsi"
+
+/ {
+	model = "RK3588S CoolPi 4B";
+	compatible = "CoolPi 4 Model B", "rockchip,rk3588s";
+
+	aliases {
+		mmc0 = &sdhci;
+		mmc1 = &sdio;
+		mmc2 = &sdmmc;
+		serial2 = &uart2;
+	};
+
+	analog-sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
+
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+
+		dais = <&i2s0_8ch_p0>;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl- = <&gpio_leds>;
+		status = "okay";
+
+		led0: led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led1: led-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_WLAN;
+			gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "phy0tx";
+			default-state = "off";
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&hym8563>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_h>;
+		/*
+		 * On the module itself this is one of these (depending
+		 * on the actual card populated):
+		 * - SDIO_RESET_L_WL_REG_ON
+		 * - PDN (power down when low)
+		 */
+		post-power-on-delay-ms = <200>;
+		reset-gpios = <&gpio0 RK_PC7 GPIO_ACTIVE_LOW>;
+	};
+
+	vcc12v_dcin: vcc12v-dcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usbdcin: vcc5v0-usbdcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usbdcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usbdcin>;
+	};
+
+	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v85_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <850000>;
+		regulator-max-microvolt = <850000>;
+		vin-supply = <&vdd_0v85_s0>;
+	};
+
+	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd1v8_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	vcc3v3_mipi: vcc3v3-mipi-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_mipi";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_otg: vcc5v0-otg-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_otg";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_u3host_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+};
+
+&i2s0_8ch {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
+		};
+	};
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	status = "okay";
+};
+
+&sdio {
+	max-frequency = <150000000>;
+	no-sd;
+	no-mmc;
+	bus-width = <4>;
+	disable-wp;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdiom1_pins>,<&wifi_poweren_gpio>;
+	status = "okay";
+};
+
+&sdmmc {
+	max-frequency = <150000000>;
+	no-sdio;
+	no-mmc;
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	num-cs = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	status = "okay";
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		reg = <0x0>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		spi-max-frequency = <1000000>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-name = "vdd_gpu_s0";
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-name = "vdd_cpu_lit_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-name = "vdd_log_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-name = "vdd_vdenc_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-name = "vdd_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-name = "vdd2_ddr_s3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-name = "vdd_2v0_pldo_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-name = "vcc_3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-name = "vddq_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-name = "vcc_1v8_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-name = "avcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-name = "vcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-name = "avdd_1v2_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-name = "vcc_3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-name = "vccio_sd_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-name = "pldo6_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-name = "vdd_0v75_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-name = "vdd_ddr_pll_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-name = "avdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-name = "vdd_0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-name = "vdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&u2phy3_host {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&hdmi0 {
+	enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+	pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd &hdmim0_tx0_scl &hdmim0_tx0_sda>;
+	status = "okay";
+};
+
+&i2c6 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c6m3_xfer>;
+	status = "okay";
+
+	hym8563: hym8563 at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hym8563_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+		status = "okay";
+	};
+
+};
+
+&i2c7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c7m0_xfer>;
+	status = "okay";
+
+	es8316: audio-codec at 11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		#sound-dai-cells = <0>;
+
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
+		};
+	};
+
+};
+
+&pcie2x1l1 {
+	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+	status = "disabled";
+};
+
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	rockchip,skip-scan-in-resume;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rtl8111_isolate>;
+	status = "okay";
+};
+
+&pwm2 {
+	pinctrl-0 = <&pwm2m1_pins>;
+	status = "okay";
+};
+
+&pwm11 {
+	pinctrl-0 = <&pwm11m1_pins>;
+	status = "disabled";
+};
+
+&pwm13 {
+	status = "okay";
+	pinctrl-names = "active";
+	pinctrl-0 = <&pwm13m2_pins>;
+};
+
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+//bt
+&uart9 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn>;
+};
+
+&pinctrl {
+	hym8563 {
+		hym8563_int: hym8563-int {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	rtl8111 {
+		rtl8111_isolate: rtl8111-isolate {
+			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	led {
+		gpio_leds: gpio-leds {
+			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>,
+					<0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	usb {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins = <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>,
+					<4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		vcc5v0_u3host_en: vcc5v0-u3host-en {
+			rockchip,pins = <3 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sdio-pwrseq {
+		wifi_enable_h: wifi-enable-h {
+			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	wireless-bluetooth {
+		uart9_gpios: uart9-gpios {
+			rockchip,pins = <3 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_reset_gpio: bt-reset-gpio {
+			rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_gpio: bt-wake-gpio {
+			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_host_irq: bt-wake-host-irq {
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	wireless-wlan {
+		wifi_host_wake_irq: wifi-host-wake-irq {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		wifi_poweren_gpio: wifi-poweren-gpio {
+			rockchip,pins = <1 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
-- 
2.34.1



From andyshrk at 163.com  Sat Dec  9 02:38:15 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sat,  9 Dec 2023 18:38:15 +0800
Subject: [PATCH 4/5] dt-bindings: arm: rockchip: Add Cool Pi CM5 EVB
In-Reply-To: <20231209103622.1568289-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
Message-ID: <20231209103815.1568614-1-andyshrk@163.com>

Add Cool Pi CM5 EVB, a board powered by RK3588

Signed-off-by: Andy Yan <andyshrk at 163.com>
---

 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5de9f3090be1..24dc6dfb8285 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -95,6 +95,11 @@ properties:
           - const: chipspark,rayeager-px2
           - const: rockchip,rk3066a
 
+      - description: Cool Pi Compute Module 5(CM5) EVB
+        items:
+          - const: CoolPi CM5 EVB
+          - const: rockchip,rk3588
+
       - description: Cool Pi 4 Model B
         items:
           - const: CoolPi 4 Model B
-- 
2.34.1



From andyshrk at 163.com  Sat Dec  9 02:38:27 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sat,  9 Dec 2023 18:38:27 +0800
Subject: [PATCH 5/5] arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5 EVB
In-Reply-To: <20231209103622.1568289-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
Message-ID: <20231209103827.1568675-1-andyshrk@163.com>

Cool Pi CM5 EVB is a board based on rk3588.

Specification:
- Rockchip RK3588
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- Gigabit ethernet x 1 with PHY YT8531
- Gigabit ethernet x 1 drived by PCIE with YT6801S
- HDMI Type A out x 2
- HDMI Type D in x 1
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- PCIE M.2 E Key for Wireless connection
- PCIE M.2 M Key for NVME connection
- 40 pin header

Signed-off-by: Andy Yan <andyshrk at 163.com>
---

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 887 ++++++++++++++++++
 2 files changed, 888 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index e59682691eb0..9be8e4830158 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-odroid-m1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-radxa-e25.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-roc-pc.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-coolpi-cm5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6b-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
new file mode 100644
index 000000000000..da72174c8e9d
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
@@ -0,0 +1,887 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3588.dtsi"
+
+/ {
+	model = "RK3588 CoolPi CM5 EVB Board";
+	compatible = "CoolPi CM5 EVB", "rockchip,rk3588";
+
+	aliases {
+		mmc0 = &sdhci;
+		mmc1 = &sdio;
+		mmc2 = &sdmmc;
+		serial2 = &uart2;
+	};
+
+	analog-sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
+
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+
+		dais = <&i2s0_8ch_p0>;
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		power-supply = <&vcc12v_dcin>;
+		pwms = <&pwm2 0 25000 0>;
+		enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bl_en>;
+		status = "okay";
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	leds: leds {
+		status = "okay";
+		compatible = "gpio-leds";
+
+		led: led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	vcc12v_dcin: vcc12v-dcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_lcd: vcc3v3-lcd-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd";
+		enable-active-high;
+		gpio = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&lcdpwr_en>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v85_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <850000>;
+		regulator-max-microvolt = <850000>;
+		vin-supply = <&vdd_0v85_s0>;
+	};
+
+	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd1v8_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	avdd0v75_pcie30: avdd0v75-pcie30-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v75_pcie30";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <750000>;
+		regulator-max-microvolt = <750000>;
+		vin-supply = <&avdd_0v75_s0>;
+	};
+
+	pcie30_avdd1v8: avdd1v8-pcie30-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd1v8";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host1_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_otg: vcc5v0-otg-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_otg";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&typec5v_pwren>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_mipidphy0: vcc-mipi-dphy0-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_mipidphy0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_sys>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&cam_en>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy1_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	status = "okay";
+};
+
+&sdmmc {
+	max-frequency = <150000000>;
+	no-sdio;
+	no-mmc;
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&u2phy3_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&gmac0 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-rxid";
+	pinctrl-0 = <&gmac0_miim
+		     &gmac0_tx_bus2
+		     &gmac0_rx_bus2
+		     &gmac0_rgmii_clk
+		     &gmac0_rgmii_bus>;
+	pinctrl-names = "default";
+	rx_delay = <0x00>;
+	tx_delay = <0x43>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c6 {
+	status = "okay";
+	hym8563: rtc at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hym8563_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PD4 IRQ_TYPE_LEVEL_LOW>;
+		wakeup-source;
+	};
+};
+
+&i2c7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c7m0_xfer>;
+	status = "okay";
+
+	es8316: audio-codec at 11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		#sound-dai-cells = <0>;
+
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
+		};
+	};
+};
+
+&i2s0_8ch {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
+		};
+	};
+};
+
+&mdio0 {
+	rgmii_phy: ethernet-phy at 1 {
+		/* YT8531C/H */
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&yt8531_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pcie30phy {
+	status = "okay";
+};
+
+//ethernet
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rtl8111_isolate>;
+	status = "okay";
+};
+
+//wifi
+&pcie2x1l1 {
+	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie_clkreq &pcie_wake &pcie_rst &wifi_pwron &bt_pwron>;
+	status = "okay";
+};
+
+&sata1 {
+	status = "okay";
+};
+
+//ssd
+&pcie3x4 {
+	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	status = "okay";
+};
+
+//express
+&pcie3x2 {
+	reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	status = "okay";
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&spi2 {
+	status = "okay";
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	num-cs = <1>;
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		spi-max-frequency = <1000000>;
+		reg = <0x0>;
+
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_2v0_pldo_s3>;
+		vcc14-supply = <&vcc_2v0_pldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_lit_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_log_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_vdenc_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vdd2_ddr_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_2v0_pldo_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vddq_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "avcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "avdd_1v2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vcc_3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vccio_sd_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "pldo6_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_ddr_pll_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "avdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_0v85_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&uart2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart2m0_xfer>;
+};
+
+&pinctrl {
+	hym8563 {
+		hym8563_int: hym8563-int {
+			rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	rtl8111 {
+		rtl8111_isolate: rtl8111-isolate {
+			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	rtl8211f {
+		yt8531_rst: yt8531-rst {
+			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		vcc5v0_host1_en: vcc5v0-host1-en {
+			rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb-typec {
+		typec5v_pwren: typec5v-pwren {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	hdmi {
+		hdmirx_det: hdmirx-det {
+			rockchip,pins = <2 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	wifi {
+		pcie_rst: pcie-rst {
+			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+		pcie_clkreq: pcie-clkreq {
+			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+		pcie_wake: pcie-wake {
+			rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+		wifi_pwron: wifi-pwron {
+			rockchip,pins = <3 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+		bt_pwron: bt-pwron {
+			rockchip,pins = <3 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	lcd {
+		lcdpwr_en: lcdpwr-en {
+			rockchip,pins = <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+		bl_en: bl-en {
+			rockchip,pins = <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	cam {
+		cam_en: cam-en {
+			rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+	};
+};
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sat Dec  9 02:39:26 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 9 Dec 2023 11:39:26 +0100
Subject: [PATCH v6 2/2] ARM: dts: aspeed: Harma: Add Facebook Harma
 (AST2600) BMC
In-Reply-To: <20231206155316.4181813-3-peteryin.openbmc@gmail.com>
References: <20231206155316.4181813-1-peteryin.openbmc@gmail.com>
 <20231206155316.4181813-3-peteryin.openbmc@gmail.com>
Message-ID: <390187fb-4ab4-49e6-b382-7be1fa117f01@linaro.org>

On 06/12/2023 16:53, Peter Yin wrote:
> Add linux device tree entry related to
> Harma specific devices connected to BMC SoC.
> 
> Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
> ---

...

> +&mac3 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_rmii4_default>;
> +	no-hw-checksum;
> +	use-ncsi;
> +	ncsi-ctrl,start-redo-probe;
> +	ncsi-ctrl,no-channel-monitor;
> +	mlx,multi-host;

There is no such property. Please stop copying downstream code into
upstream.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sat Dec  9 02:44:09 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat,  9 Dec 2023 11:44:09 +0100
Subject: [PATCH 1/4] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
Message-ID: <20231209104412.12916-1-krzysztof.kozlowski@linaro.org>

"mlx,multi-host" is using incorrect vendor prefix and is not documented.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts
index 7a53f54833a0..9a6757dd203f 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts
@@ -66,7 +66,7 @@ &mac3 {
 	pinctrl-0 = <&pinctrl_rmii4_default>;
 	no-hw-checksum;
 	use-ncsi;
-	mlx,multi-host;
+	mellanox,multi-host;
 	ncsi-ctrl,start-redo-probe;
 	ncsi-ctrl,no-channel-monitor;
 	ncsi-package = <1>;
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sat Dec  9 02:44:10 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat,  9 Dec 2023 11:44:10 +0100
Subject: [PATCH 2/4] ARM: dts: aspeed: minerva-cmc: correct Mellanox multi-host property
In-Reply-To: <20231209104412.12916-1-krzysztof.kozlowski@linaro.org>
References: <20231209104412.12916-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231209104412.12916-2-krzysztof.kozlowski@linaro.org>

"mlx,multi-host" is using incorrect vendor prefix and is not documented.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva-cmc.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva-cmc.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva-cmc.dts
index f04ef9063520..29f042a47e96 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva-cmc.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva-cmc.dts
@@ -51,7 +51,7 @@ &mac3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_rmii4_default>;
 	use-ncsi;
-	mlx,multi-host;
+	mellanox,multi-host;
 };
 
 &fmc {
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sat Dec  9 02:44:11 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat,  9 Dec 2023 11:44:11 +0100
Subject: [PATCH 3/4] ARM: dts: aspeed: yosemite4: correct Mellanox multi-host property
In-Reply-To: <20231209104412.12916-1-krzysztof.kozlowski@linaro.org>
References: <20231209104412.12916-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231209104412.12916-3-krzysztof.kozlowski@linaro.org>

"mlx,multi-host" is using incorrect vendor prefix and is not documented.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 64075cc41d92..1bd555a6c3ba 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -88,7 +88,7 @@ &mac2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_rmii3_default>;
 	use-ncsi;
-	mlx,multi-host;
+	mellanox,multi-host;
 };
 
 &mac3 {
@@ -96,7 +96,7 @@ &mac3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_rmii4_default>;
 	use-ncsi;
-	mlx,multi-host;
+	mellanox,multi-host;
 };
 
 &fmc {
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sat Dec  9 02:44:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat,  9 Dec 2023 11:44:12 +0100
Subject: [PATCH 4/4] ARM: dts: aspeed: yosemitev2: correct Mellanox multi-host property
In-Reply-To: <20231209104412.12916-1-krzysztof.kozlowski@linaro.org>
References: <20231209104412.12916-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231209104412.12916-4-krzysztof.kozlowski@linaro.org>

"mlx,multi-host" is using incorrect vendor prefix and is not documented.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts
index 6bf2ff85a40e..5143f85fbd70 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts
@@ -95,7 +95,7 @@ &mac0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_rmii1_default>;
 	use-ncsi;
-	mlx,multi-host;
+	mellanox,multi-host;
 };
 
 &adc {
-- 
2.34.1



From bigunclemax at gmail.com  Sat Dec  9 02:44:34 2023
From: bigunclemax at gmail.com (Maksim Kiselev)
Date: Sat, 9 Dec 2023 13:44:34 +0300
Subject: [PATCH v3 5/6] thermal: sun8i: add support for H616 THS
 controller
In-Reply-To: <20231128005849.19044-6-andre.przywara@arm.com>
References: <20231128005849.19044-6-andre.przywara@arm.com>
Message-ID: <a14fb458-caf0-4a4a-b76b-c2503b0840d2@gmail.com>

Hi Martin, Andre.

May I inquire? Why do we need a separate sun50i_h616_ths_calibrate() 
function? Why can't we just extend an existing sun50i_h6_ths_calibrate()?

At my glance the calculations in both functions are the same. We just 
need to handle a special case for the 4th sensor.

Best regards,
Maksim



From conor at kernel.org  Sat Dec  9 02:57:01 2023
From: conor at kernel.org (Conor Dooley)
Date: Sat, 9 Dec 2023 10:57:01 +0000
Subject: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-in-suspend property
In-Reply-To: <ZXOoy8mFdhUQsZAu@google.com>
References: <20231207111300.80581-1-eichest@gmail.com>
 <20231207111300.80581-2-eichest@gmail.com>
 <CACRpkdbSs-vebvchxx-Tg+O5CUF5M3vZf-iytuW=ZECnHb2anA@mail.gmail.com>
 <ZXOoy8mFdhUQsZAu@google.com>
Message-ID: <20231209-sizzle-monthly-6e4f3c966b0f@spud>

On Fri, Dec 08, 2023 at 11:37:47PM +0000, Dmitry Torokhov wrote:
> Hi Linus, Krzysztof,
> 
> On Fri, Dec 08, 2023 at 01:54:21PM +0100, Linus Walleij wrote:
> > On Thu, Dec 7, 2023 at 12:13?PM Stefan Eichenberger <eichest at gmail.com> wrote:
> > 
> > > From: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> > >
> > > Add a new property to indicate that the device should be powered off in
> > > suspend mode.
> > >
> > > Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> > (...)
> > > +  atmel,poweroff-in-suspend:
> > > +    description: |
> > > +      When this property is set, all supplies are turned off when the system is
> > > +      going to suspend.
> > > +    type: boolean
> >    wakeup-source:
> >      type: boolean
> > 
> > As Krzysztof says it seems you are describing an operating system feature.
> 
> It appears to be an OS feature, but I would argue that it is also a
> property of a board. It is tempting to say that if DTS defines supplies
> for the controller we should use them to power off the controller in
> suspend, otherwise we should use the deep sleep functionality of the
> controller. But a mere presence of regulators does not indicate if they
> can actually be powered off in suspend (i.e. if controllers shares power
> rails with another device that can be a wakeup source), so we need to
> have additional hints on how OS should behave on a given device.
> 
> On top of that we have regulator framework supplying dummy regulators...

Simply rephrasing the property might be sufficient? The current one
sounds making policy decisions with the "should be". Reframing the
commit message and property description etc in terms of what aspect of
the hardware the ability to turn off all supplies in suspend comes from
would make it more acceptable. Pretty much answering the question "why
can't we try and turn off all supplies on all systems with this device"
should get things rolling.

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231209/c7bc0d1c/attachment.sig>

From lkp at intel.com  Sat Dec  9 03:35:40 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 9 Dec 2023 19:35:40 +0800
Subject: [PATCH 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231208202108.7468-2-kamal.dasu@broadcom.com>
References: <20231208202108.7468-2-kamal.dasu@broadcom.com>
Message-ID: <202312091905.UGzltx8A-lkp@intel.com>

Hi Kamal,

kernel test robot noticed the following build warnings:

[auto build test WARNING on robh/for-next]
[also build test WARNING on soc/for-next linus/master v6.7-rc4 next-20231208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Kamal-Dasu/mmc-add-new-sdhci-reset-sequence-for-brcm-74165b0/20231209-042222
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/20231208202108.7468-2-kamal.dasu%40broadcom.com
patch subject: [PATCH 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
config: nios2-randconfig-r133-20231209 (https://download.01.org/0day-ci/archive/20231209/202312091905.UGzltx8A-lkp at intel.com/config)
compiler: nios2-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231209/202312091905.UGzltx8A-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312091905.UGzltx8A-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/mmc/host/sdhci-brcmstb.c:237:17: sparse: sparse: incorrect type in initializer (different modifiers) @@     expected struct sdhci_ops *ops @@     got struct sdhci_ops const * @@
   drivers/mmc/host/sdhci-brcmstb.c:237:17: sparse:     expected struct sdhci_ops *ops
   drivers/mmc/host/sdhci-brcmstb.c:237:17: sparse:     got struct sdhci_ops const *

vim +237 drivers/mmc/host/sdhci-brcmstb.c

   233	
   234	static const struct brcmstb_match_priv match_priv_74165b0 = {
   235		.flags = BRCMSTB_MATCH_FLAGS_HAS_CLOCK_GATE,
   236		.hs400es = sdhci_brcmstb_hs400es,
 > 237		.ops = &sdhci_brcmstb_ops_74165b0,
   238	};
   239	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From krzysztof.kozlowski at linaro.org  Sat Dec  9 04:44:01 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat,  9 Dec 2023 13:44:01 +0100
Subject: [PATCH] arm64: dts: amlogic: drop redundant status=okay
Message-ID: <20231209124401.93814-1-krzysztof.kozlowski@linaro.org>

New device nodes are enabled by default, so no need for status=okay.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

Tested by comparing decompiled DTBs.
---
 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts         | 5 -----
 arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts      | 1 -
 arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts     | 1 -
 arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts      | 1 -
 arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts   | 1 -
 arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi    | 1 -
 arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts     | 1 -
 arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts        | 1 -
 arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi   | 1 -
 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 1 -
 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts    | 1 -
 arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts     | 1 -
 arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts       | 1 -
 13 files changed, 17 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index df16eead2c80..c8905663bc75 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -66,7 +66,6 @@ linein: audio-codec-0 {
 		VDDA-supply = <&vcc_3v3>;
 		VDDP-supply = <&vcc_3v3>;
 		VDDD-supply = <&vcc_3v3>;
-		status = "okay";
 		sound-name-prefix = "Linein";
 	};
 
@@ -75,14 +74,12 @@ lineout: audio-codec-1 {
 		compatible = "everest,es7154";
 		VDD-supply = <&vcc_3v3>;
 		PVDD-supply = <&vcc_5v>;
-		status = "okay";
 		sound-name-prefix = "Lineout";
 	};
 
 	spdif_dit: audio-codec-2 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
@@ -91,14 +88,12 @@ dmics: audio-codec-3 {
 		compatible = "dmic-codec";
 		num-channels = <7>;
 		wakeup-delay-ms = <50>;
-		status = "okay";
 		sound-name-prefix = "MIC";
 	};
 
 	spdif_dir: audio-codec-4 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dir";
-		status = "okay";
 		sound-name-prefix = "DIR";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
index 0ad0c2b7dfef..4c4550dd4711 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
@@ -45,7 +45,6 @@ dmics: audio-codec-1 {
 		compatible = "dmic-codec";
 		num-channels = <2>;
 		wakeup-delay-ms = <50>;
-		status = "okay";
 		sound-name-prefix = "MIC";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
index 4969a76460fa..9b55982b6a6b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
@@ -22,7 +22,6 @@ aliases {
 	spdif_dit: audio-codec-1 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
index 8fc2e143cb54..0da386cabe1a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
@@ -22,7 +22,6 @@ aliases {
 	spdif_dit: audio-codec-1 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
index ce548b373296..6396f190d703 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
@@ -17,7 +17,6 @@ / {
 	spdif_dit: audio-codec-1 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 18f7b730289e..e59c3c92b1e7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -26,7 +26,6 @@ dio2133: analog-amplifier {
 	spdif_dit: audio-codec-0 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
index e238f1f10124..f28452b9f00f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
@@ -18,7 +18,6 @@ / {
 	spdif_dit: audio-codec-0 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
index 292c718ee19c..591455c50e88 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
@@ -18,7 +18,6 @@ / {
 	spdif_dit: audio-codec-0 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index e8303089bff6..74df32534231 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -21,7 +21,6 @@ chosen {
 	spdif_dit: audio-codec-0 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
index e1b74b174915..376760d86766 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
@@ -17,7 +17,6 @@ / {
 	spdif_dit: audio-codec-0 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 7d525bdb0e06..ad2dd4ad0a31 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -28,7 +28,6 @@ chosen {
 	spdif_dit: audio-codec-0 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts
index 50d49aec41bd..d05dde8da5c5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts
@@ -37,7 +37,6 @@ memory at 0 {
 	spdif_dit: audio-codec-0 {
 		#sound-dai-cells = <0>;
 		compatible = "linux,spdif-dit";
-		status = "okay";
 		sound-name-prefix = "DIT";
 	};
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
index 095579c55f18..109932068dbe 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
@@ -32,7 +32,6 @@ dmics: audio-codec-1 {
 		compatible = "dmic-codec";
 		num-channels = <2>;
 		wakeup-delay-ms = <50>;
-		status = "okay";
 		sound-name-prefix = "MIC";
 	};
 
-- 
2.34.1



From claudiu.beznea at tuxon.dev  Sat Dec  9 04:50:24 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Sat, 9 Dec 2023 14:50:24 +0200
Subject: [PATCH v2] drivers: soc: atmel: Adjust defines to follow
 aphabetical order
In-Reply-To: <20231208194532.579893-1-Ryan.Wanner@microchip.com>
References: <20231208194532.579893-1-Ryan.Wanner@microchip.com>
Message-ID: <de0ddb41-8d78-45eb-bcb7-6d318bf154fd@tuxon.dev>

Hi, Ryan,

On 08.12.2023 21:45, Ryan.Wanner at microchip.com wrote:
> From: Ryan Wanner <Ryan.Wanner at microchip.com>
> 
> Move the defines so that they are in aphabetical order based on SOC.

s/aphabetical/alphabetical but maybe alphanumerical a better term.

Could you please explain what level of alphabetical sort you wanted to
achieve? I see SAM9X60/SAMA7G5 b/w AT91SAM9X5_CIDR_MATCH and
AT91SAM9M11_EXID_MATCH or, e.g., AT91SAM9G35_EXID_MATCH after
AT91SAM9M10_EXID_MATCH.

> 
> Signed-off-by: Ryan Wanner <Ryan.Wanner at microchip.com>
> ---
> Changes from v1 -> v2:
> - Remove defines that are not yet in v6.7.
> 
>  drivers/soc/atmel/soc.h | 38 +++++++++++++++++++-------------------
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/soc/atmel/soc.h b/drivers/soc/atmel/soc.h
> index 7a9f47ce85fb..1f2af6f74160 100644
> --- a/drivers/soc/atmel/soc.h
> +++ b/drivers/soc/atmel/soc.h
> @@ -39,10 +39,10 @@ at91_soc_init(const struct at91_soc *socs);
>  #define AT91SAM9261_CIDR_MATCH		0x019703a0
>  #define AT91SAM9263_CIDR_MATCH		0x019607a0
>  #define AT91SAM9G20_CIDR_MATCH		0x019905a0
> -#define AT91SAM9RL64_CIDR_MATCH		0x019b03a0
>  #define AT91SAM9G45_CIDR_MATCH		0x019b05a0
> -#define AT91SAM9X5_CIDR_MATCH		0x019a05a0
>  #define AT91SAM9N12_CIDR_MATCH		0x019a07a0
> +#define AT91SAM9RL64_CIDR_MATCH		0x019b03a0
> +#define AT91SAM9X5_CIDR_MATCH		0x019a05a0
>  #define SAM9X60_CIDR_MATCH		0x019b35a0
>  #define SAMA7G5_CIDR_MATCH		0x00162100
>  
> @@ -61,23 +61,15 @@ at91_soc_init(const struct at91_soc *socs);
>  #define AT91SAM9N12_EXID_MATCH		0x00000006
>  #define AT91SAM9CN11_EXID_MATCH		0x00000009
>  
> +#define AT91SAM9XE128_CIDR_MATCH	0x329973a0
> +#define AT91SAM9XE256_CIDR_MATCH	0x329a93a0
> +#define AT91SAM9XE512_CIDR_MATCH	0x329aa3a0
> +
>  #define SAM9X60_EXID_MATCH		0x00000000
>  #define SAM9X60_D5M_EXID_MATCH		0x00000001
>  #define SAM9X60_D1G_EXID_MATCH		0x00000010
>  #define SAM9X60_D6K_EXID_MATCH		0x00000011
>  
> -#define SAMA7G51_EXID_MATCH		0x3
> -#define SAMA7G52_EXID_MATCH		0x2
> -#define SAMA7G53_EXID_MATCH		0x1
> -#define SAMA7G54_EXID_MATCH		0x0
> -#define SAMA7G54_D1G_EXID_MATCH		0x00000018
> -#define SAMA7G54_D2G_EXID_MATCH		0x00000020
> -#define SAMA7G54_D4G_EXID_MATCH		0x00000028
> -
> -#define AT91SAM9XE128_CIDR_MATCH	0x329973a0
> -#define AT91SAM9XE256_CIDR_MATCH	0x329a93a0
> -#define AT91SAM9XE512_CIDR_MATCH	0x329aa3a0
> -
>  #define SAMA5D2_CIDR_MATCH		0x0a5c08c0
>  #define SAMA5D21CU_EXID_MATCH		0x0000005a
>  #define SAMA5D225C_D1M_EXID_MATCH	0x00000053
> @@ -113,6 +105,14 @@ at91_soc_init(const struct at91_soc *socs);
>  #define SAMA5D43_EXID_MATCH		0x00000003
>  #define SAMA5D44_EXID_MATCH		0x00000004
>  
> +#define SAMA7G51_EXID_MATCH		0x3
> +#define SAMA7G52_EXID_MATCH		0x2
> +#define SAMA7G53_EXID_MATCH		0x1
> +#define SAMA7G54_EXID_MATCH		0x0
> +#define SAMA7G54_D1G_EXID_MATCH		0x00000018
> +#define SAMA7G54_D2G_EXID_MATCH		0x00000020
> +#define SAMA7G54_D4G_EXID_MATCH		0x00000028
> +
>  #define SAME70Q21_CIDR_MATCH		0x21020e00
>  #define SAME70Q21_EXID_MATCH		0x00000002
>  #define SAME70Q20_CIDR_MATCH		0x21020c00
> @@ -127,6 +127,11 @@ at91_soc_init(const struct at91_soc *socs);
>  #define SAMS70Q19_CIDR_MATCH		0x211d0a00
>  #define SAMS70Q19_EXID_MATCH		0x00000002
>  
> +#define SAMV70Q20_CIDR_MATCH		0x21320c00
> +#define SAMV70Q20_EXID_MATCH		0x00000002
> +#define SAMV70Q19_CIDR_MATCH		0x213d0a00
> +#define SAMV70Q19_EXID_MATCH		0x00000002
> +
>  #define SAMV71Q21_CIDR_MATCH		0x21220e00
>  #define SAMV71Q21_EXID_MATCH		0x00000002
>  #define SAMV71Q20_CIDR_MATCH		0x21220c00
> @@ -134,9 +139,4 @@ at91_soc_init(const struct at91_soc *socs);
>  #define SAMV71Q19_CIDR_MATCH		0x212d0a00
>  #define SAMV71Q19_EXID_MATCH		0x00000002
>  
> -#define SAMV70Q20_CIDR_MATCH		0x21320c00
> -#define SAMV70Q20_EXID_MATCH		0x00000002
> -#define SAMV70Q19_CIDR_MATCH		0x213d0a00
> -#define SAMV70Q19_EXID_MATCH		0x00000002
> -
>  #endif /* __AT91_SOC_H */


From claudiu.beznea at tuxon.dev  Sat Dec  9 04:56:04 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Sat, 9 Dec 2023 14:56:04 +0200
Subject: [PATCH] ARM: dts: microchip: sama5d27_wlsom1_ek: Remove
 mmc-ddr-3_3v property from sdmmc0 node
In-Reply-To: <20231204072537.2991-1-mihai.sain@microchip.com>
References: <20231204072537.2991-1-mihai.sain@microchip.com>
Message-ID: <80cd8878-da98-4093-9fb5-0b702466a17c@tuxon.dev>



On 04.12.2023 09:25, Mihai Sain wrote:
> On board the sdmmc0 interface is wired to a SD Card socket.
> According with mmc-controller bindings, the mmc-ddr-3_3v property
> is used for eMMC devices to enable high-speed DDR mode (3.3V I/O).
> Remove the mmc-ddr-3_3v property from sdmmc0 node.
> 
> Signed-off-by: Mihai Sain <mihai.sain at microchip.com>

Applied to at91-dt, thanks!

> ---
>  arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
> index e055b9e2fe34..15239834d886 100644
> --- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
> +++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
> @@ -197,7 +197,6 @@ qspi1_flash: flash at 0 {
>  
>  &sdmmc0 {
>  	bus-width = <4>;
> -	mmc-ddr-3_3v;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_sdmmc0_default>;
>  	status = "okay";


From andi.shyti at kernel.org  Sat Dec  9 05:01:40 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Sat, 9 Dec 2023 14:01:40 +0100
Subject: [PATCH v1] i2c: cadence: Add system suspend and resume PM support
In-Reply-To: <20231209030955.1156905-1-jisheng.teoh@starfivetech.com>
References: <20231209030955.1156905-1-jisheng.teoh@starfivetech.com>
Message-ID: <20231209130140.m2ym5yy5rv3pwtzn@zenone.zhora.eu>

Hi Ji Sheng,

[...]

> +static int __maybe_unused cdns_i2c_resume(struct device *dev)
> +{
> +	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
> +	int err;
> +
> +	err = cdns_i2c_runtime_resume(dev);
> +	if (err)
> +		return err;
> +
> +	if (pm_runtime_status_suspended(dev)) {
> +		cdns_i2c_runtime_suspend(dev);
> +		if (err)
> +			return err;

have you forgotten to assign 'err'?

Andi

> +	}


From jisheng.teoh at starfivetech.com  Sat Dec  9 05:07:06 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Sat, 9 Dec 2023 21:07:06 +0800
Subject: [PATCH v1] i2c: cadence: Add system suspend and resume PM support
In-Reply-To: <20231209130140.m2ym5yy5rv3pwtzn@zenone.zhora.eu>
References: <20231209130140.m2ym5yy5rv3pwtzn@zenone.zhora.eu>
Message-ID: <20231209130706.1906176-1-jisheng.teoh@starfivetech.com>

On Sat, 9 Dec 2023 14:01:40 +0100
Andi Shyti <andi.shyti at kernel.org> wrote:

> Hi Ji Sheng,
> 
> [...]
> 
> > +static int __maybe_unused cdns_i2c_resume(struct device *dev)
> > +{
> > +	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
> > +	int err;
> > +
> > +	err = cdns_i2c_runtime_resume(dev);
> > +	if (err)
> > +		return err;
> > +
> > +	if (pm_runtime_status_suspended(dev)) {
> > +		cdns_i2c_runtime_suspend(dev);
> > +		if (err)
> > +			return err;  
> 
> have you forgotten to assign 'err'?
> 
> Andi
> 
> > +	}  

My bad, I will fix it in v2. Thanks Andi.


From broonie at kernel.org  Sat Dec  9 05:09:45 2023
From: broonie at kernel.org (Mark Brown)
Date: Sat, 9 Dec 2023 13:09:45 +0000
Subject: [PATCH v7 24/39] arm64/signal: Set up and restore the GCS
 context for signal handlers
In-Reply-To: <8734wcgj79.fsf@linaro.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-24-201c483bd775@kernel.org>
 <8734wcgj79.fsf@linaro.org>
Message-ID: <ZXRnGbYI+uq7m9sA@finisterre.sirena.org.uk>

On Sat, Dec 09, 2023 at 12:15:22AM -0300, Thiago Jung Bauermann wrote:
> Mark Brown <broonie at kernel.org> writes:

> > +	/* The cap must have the low bits set to a token value */
> > +	if (GCS_CAP_TOKEN(val) != 0)
> > +		return false;

> I found the comment above a little confusing, since the if condition
> actually checks that low bits aren't set at all. Perhaps reword to
> something like "The token value of a signal cap must be 0"?

Right, that's bitrot from the previous token format.

> I'm still not proficient enough in GCS to know how exactly this could be
> abused (e.g., somehow writing the desired return location right above
> one of these inactive caps and arranging for GCSPR to point to the cap
> before returning from a signal) but to be safe or paranoid, perhaps zero
> the location of the cap before returning?

Right, ideally we'd be doing a compare and exchange here to substitute
in a zero.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231209/5054f50f/attachment-0001.sig>

From wenst at chromium.org  Sat Dec  9 05:13:59 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Sat, 9 Dec 2023 22:13:59 +0900
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231207143814.GD15521@pendragon.ideasonboard.com>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com>
Message-ID: <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>

On Thu, Dec 7, 2023 at 11:38?PM Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>
> On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > Hi Simon,
> > >
> > > Thank you for the patch.
> > >
> > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > containing the built kernel and associated devicetree files.
> > > > Compression defaults to gzip which gives a good balance of size and
> > > > performance.
> > > >
> > > > The files compress from about 86MB to 24MB using this approach.
> > > >
> > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > and Linuxboot. It permits automatic selection of the correct
> > > > devicetree, matching the compatible string of the running board with
> > > > the closest compatible string in the FIT. There is no need for
> > > > filenames or other workarounds.
> > > >
> > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > FIT_COMPRESSION to select a different algorithm.
> > > >
> > > > The FIT can be examined using 'dumpimage -l'.
> > > >
> > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > requires compression utilities for the algorithm being used. Supported
> > > > compression options are the same as the Image.xxx files. For now there
> > > > is no way to change the compression other than by editing the rule for
> > > > $(obj)/image.fit
> > > >
> > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > this here, since it must be built separately from the Linux build.
> > >
> > > FIT images are very useful, so I think this is a very welcome addition
> > > to the kernel build system. It can get tricky though: given the
> > > versatile nature of FIT images, there can't be any
> > > one-size-fits-them-all solution to build them, and striking the right
> > > balance between what makes sense for the kernel and the features that
> > > users may request will probably lead to bikeshedding. As we all love
> > > bikeshedding, I thought I would start selfishly, with a personal use
> > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > to delay merging this series.
> > >
> > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > extending the supported command line arguments. It would perhaps be more
> > > difficult to integrate in the kernel build system though. This leads me
> > > to a second question: would you consider merging extensions to this
> > > script if they are not used by the kernel build system, but meant for
> > > users who manually invoke the script ? More generally, is the script
> >
> > We'd also be interested in some customization, though in a different way.
> > We imagine having a rule file that says X compatible string should map
> > to A base DTB, plus B and C DTBO for the configuration section. The base
> > DTB would carry all common elements of some device, while the DTBOs
> > carry all the possible second source components, like different display
> > panels or MIPI cameras for instance. This could drastically reduce the
> > size of FIT images in ChromeOS by deduplicating all the common stuff.
>
> Do you envision the "mapping" compatible string mapping to a config
> section in the FIT image, that would bundle the base DTB and the DTBOs ?

That's exactly the idea. The mapping compatible string could be untied
from the base board's compatible string if needed (which we probably do).

So something like:

config {
    config-1 {
        compatible = "google,krane-sku0";
        fdt = "krane-baseboard", "krane-sku0-overlay";
    };
};

With "krane-sku0-overlay" being an overlay that holds the differences
between the SKUs, in this case the display panel and MIPI camera (not
upstreamed) that applies to SKU0 in particular.

Sorry for not giving a more concrete idea.


ChenYu

> > > meant to be used stand-alone as well, in which case its command line
> > > arguments need to remain backward-compatible, or do you see it as being
> > > internal to the kernel ?
> >
> > [...]
> >
> > ChenYu
>
> --
> Regards,
>
> Laurent Pinchart


From jisheng.teoh at starfivetech.com  Sat Dec  9 05:15:16 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Sat, 9 Dec 2023 21:15:16 +0800
Subject: [PATCH v2] i2c: cadence: Add system suspend and resume PM support
Message-ID: <20231209131516.1916550-1-jisheng.teoh@starfivetech.com>

Enable device system suspend and resume PM support, and mark the device
state as suspended during system suspend to reject any data transfer.

Signed-off-by: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
---
Changes since v1:
- Add missing err assignment in cdns_i2c_resume().
---
 drivers/i2c/busses/i2c-cadence.c | 33 ++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index de3f58b60dce..4bb7d6756947 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -1176,6 +1176,18 @@ static int __maybe_unused cdns_i2c_runtime_suspend(struct device *dev)
 	return 0;
 }
 
+static int __maybe_unused cdns_i2c_suspend(struct device *dev)
+{
+	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
+
+	i2c_mark_adapter_suspended(&xi2c->adap);
+
+	if (!pm_runtime_status_suspended(dev))
+		return cdns_i2c_runtime_suspend(dev);
+
+	return 0;
+}
+
 /**
  * cdns_i2c_init -  Controller initialisation
  * @id:		Device private data structure
@@ -1219,7 +1231,28 @@ static int __maybe_unused cdns_i2c_runtime_resume(struct device *dev)
 	return 0;
 }
 
+static int __maybe_unused cdns_i2c_resume(struct device *dev)
+{
+	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
+	int err;
+
+	err = cdns_i2c_runtime_resume(dev);
+	if (err)
+		return err;
+
+	if (pm_runtime_status_suspended(dev)) {
+		err = cdns_i2c_runtime_suspend(dev);
+		if (err)
+			return err;
+	}
+
+	i2c_mark_adapter_resumed(&xi2c->adap);
+
+	return 0;
+}
+
 static const struct dev_pm_ops cdns_i2c_dev_pm_ops = {
+	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(cdns_i2c_suspend, cdns_i2c_resume)
 	SET_RUNTIME_PM_OPS(cdns_i2c_runtime_suspend,
 			   cdns_i2c_runtime_resume, NULL)
 };
-- 
2.25.1



From qiwuchen55 at gmail.com  Sat Dec  9 05:20:38 2023
From: qiwuchen55 at gmail.com (chenqiwu)
Date: Sat, 9 Dec 2023 21:20:38 +0800
Subject: [PATCH v2] arm64: Add USER_STACKTRACE support
In-Reply-To: <ZWX9wPMPLUlMeDc3@FVFF77S0Q05N.cambridge.arm.com>
References: <20231125072739.3151-1-qiwu.chen@transsion.com>
 <ZWX9wPMPLUlMeDc3@FVFF77S0Q05N.cambridge.arm.com>
Message-ID: <20231209132038.GA9628@rlk>

On Tue, Nov 28, 2023 at 02:48:32PM +0000, Mark Rutland wrote:
> On Fri, Nov 24, 2023 at 11:27:39PM -0800, qiwuchen55 at gmail.com wrote:
> > From: chenqiwu <qiwu.chen at transsion.com>
> > 
> > Use the perf_callchain_user() code as blueprint to implement
> > arch_stack_walk_user() which add ftrace userstacktrace support
> > on arm64.
> > With this patch, tracer can get userstacktrace by below callchain:
> > ftrace_trace_userstack ->
> > 	stack_trace_save_user ->
> > 		aasrch_stack_walk_user
> > An example test case is as shown below:
> >  # cd /sys/kernel/debug/tracing
> >  # echo 1 > options/userstacktrace
> >  # echo 1 > options/sym-userobj
> >  # echo 1 > events/sched/sched_process_fork/enable
> >  # cat trace
> >   ......
> >   bash-418     [000] .....   121.820661: sched_process_fork: comm=bash pid=418 child_comm=bash child_pid=441
> >   bash-418     [000] .....   121.821340: <user stack trace>
> >  => /lib/aarch64-linux-gnu/libc-2.32.so[+0xa76d8]
> >  => /bin/bash[+0x5f354]
> >  => /bin/bash[+0x47fe8]
> >  => /bin/bash[+0x493f8]
> >  => /bin/bash[+0x4aec4]
> >  => /bin/bash[+0x4c31c]
> >  => /bin/bash[+0x339b0]
> >  => /bin/bash[+0x322f8]
> > 
> > changes in v2:
> >     - Remove useless arch_dump_user_stacktrace().
> >     - Rework arch_stack_walk_user() implementation.
> >     - Modify the commit message.
> > Tested-by: chenqiwu <qiwu.chen at transsion.com>
> > Signed-off-by: chenqiwu <qiwu.chen at transsion.com>
> > ---
> >  arch/arm64/Kconfig             |   1 +
> >  arch/arm64/kernel/stacktrace.c | 120 +++++++++++++++++++++++++++++++++
> >  2 files changed, 121 insertions(+)
> 
> Thanks for this, it looks much better than v1.
> However, as I mentioned on v1, we want to have one copy of this code. 
> 
> Rather than just copying the logic from perf_callchain.c, please also update 
> perf_callchain_user() to use arch_stack_walk_user() and delete the redundant code.
> 
> Thanks,
> Mark.
>
Hi Mark,
Thanks for your professional advice, I make an improvement in patch v3.
Please help review this again:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20231129160119.60829-1-qiwu.chen at transsion.com/
Thanks
Qiwu


From u.kleine-koenig at pengutronix.de  Sat Dec  9 05:56:09 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Sat, 9 Dec 2023 14:56:09 +0100
Subject: [PATCH 0/7] pcmcia: Convert to platform remove callback
 returning void
In-Reply-To: <ZXNsLJfqs9DLHb1Q@shine.dominikbrodowski.net>
References: <cover.1702051073.git.u.kleine-koenig@pengutronix.de>
 <ZXNsLJfqs9DLHb1Q@shine.dominikbrodowski.net>
Message-ID: <20231209135609.c2vfba7age6xcrvp@pengutronix.de>

Hello Dominik,

On Fri, Dec 08, 2023 at 08:19:08PM +0100, Dominik Brodowski wrote:
> Am Fri, Dec 08, 2023 at 05:08:05PM +0100 schrieb Uwe Kleine-K?nig:
> > Hello,
> > 
> > this series changes all platform drivers in drivers/pcmcia to use the
> > .remove_new() callback. See commit 5c5a7680e67b ("platform: Provide a
> > remove callback that returns no value") for an extended explanation and
> > the eventual goal.
> > 
> > All conversations are trivial, because all .remove() callbacks returned
> > zero unconditionally already.
> > 
> > There are no interdependencies between these patches, so they could be
> > picked up individually. However I'd expect them to go in all together.
> > It's unclrear to me though, who will pick them up. Dominik? Greg?
> 
> Both options are fine with me. In the latter case:
> 
> 	Acked-by: Dominik Brodowski <linux at dominikbrodowski.net>

Then I suggest you to take them. I only suggested Greg as a fallback
because I was unsure how active you are given the PCMCIA entry in
MAINTAINERS has status "Odd Fixes".

Best regards and a calm pre-Christmas period,
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231209/e53cfb1f/attachment.sig>

From u.kleine-koenig at pengutronix.de  Sat Dec  9 05:57:42 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Sat, 9 Dec 2023 14:57:42 +0100
Subject: [PATCH v6 1/4] pwm: rename pwm_apply_state() to
 pwm_apply_might_sleep()
In-Reply-To: <37090c1d8d8f42f1e12fa84942027d995189a99e.1701248996.git.sean@mess.org>
References: <cover.1701248996.git.sean@mess.org>
 <37090c1d8d8f42f1e12fa84942027d995189a99e.1701248996.git.sean@mess.org>
Message-ID: <20231209135742.3ieusuq3h3xlvjfn@pengutronix.de>

On Wed, Nov 29, 2023 at 09:13:34AM +0000, Sean Young wrote:
> In order to introduce a pwm api which can be used from atomic context,
> we will need two functions for applying pwm changes:
> 
> 	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
> 	int pwm_apply_atomic(struct pwm *, struct pwm_state *);
> 
> This commit just deals with renaming pwm_apply_state(), a following
> commit will introduce the pwm_apply_atomic() function.
> 
> Acked-by: Hans de Goede <hdegoede at redhat.com>
> Acked-by: Jani Nikula <jani.nikula at intel.com>
> Acked-by: Lee Jones <lee at kernel.org>
> Signed-off-by: Sean Young <sean at mess.org>

Not a in-detail-review, but I just noticed again, that we have

	K:      pwm_(config|apply_state|ops)

in MAINTAINERS. That one needs adaption, too.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231209/d3a8b916/attachment-0001.sig>

From krzysztof.kozlowski at linaro.org  Sat Dec  9 06:00:09 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 9 Dec 2023 15:00:09 +0100
Subject: [PATCH 2/5] dt-bindings: arm: rockchip: Add Cool Pi 4B
In-Reply-To: <20231209103748.1568462-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
 <20231209103748.1568462-1-andyshrk@163.com>
Message-ID: <bd62fe7b-3d66-4ade-9aaf-37af449b08c2@linaro.org>

On 09/12/2023 11:37, Andy Yan wrote:
> Add Cool Pi 4B, a SBC powered by RK3588S
> 
> Signed-off-by: Andy Yan <andyshrk at 163.com>
> ---
> 
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 5deb66a5c7d9..5de9f3090be1 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -95,6 +95,11 @@ properties:
>            - const: chipspark,rayeager-px2
>            - const: rockchip,rk3066a
>  
> +      - description: Cool Pi 4 Model B
> +        items:
> +          - const: CoolPi 4 Model B

That's not a correct compatible.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sat Dec  9 06:00:31 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 9 Dec 2023 15:00:31 +0100
Subject: [PATCH 1/5] dt-bindings: vendor-prefixes: Add Cool Pi
In-Reply-To: <20231209103707.1568381-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
 <20231209103707.1568381-1-andyshrk@163.com>
Message-ID: <da62df23-797c-40d6-8cb8-1c99855a3a81@linaro.org>

On 09/12/2023 11:37, Andy Yan wrote:
> Add vendor prefix for Cool Pi(https://cool-pi.com/)
> 
> Signed-off-by: Andy Yan <andyshrk at 163.com>
> 
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


---

This is an automated instruction, just in case, because many review tags
are being ignored. If you know the process, you can skip it (please do
not feel offended by me posting it here - no bad intentions intended).
If you do not know the process, here is a short explanation:

Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.

https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577

Best regards,
Krzysztof



From heiko at sntech.de  Sat Dec  9 06:00:38 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sat, 09 Dec 2023 15:00:38 +0100
Subject: [PATCH 2/5] dt-bindings: arm: rockchip: Add Cool Pi 4B
In-Reply-To: <20231209103748.1568462-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
 <20231209103748.1568462-1-andyshrk@163.com>
Message-ID: <2263987.atdPhlSkOF@diego>

Am Samstag, 9. Dezember 2023, 11:37:48 CET schrieb Andy Yan:
> Add Cool Pi 4B, a SBC powered by RK3588S
> 
> Signed-off-by: Andy Yan <andyshrk at 163.com>
> ---
> 
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 5deb66a5c7d9..5de9f3090be1 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -95,6 +95,11 @@ properties:
>            - const: chipspark,rayeager-px2
>            - const: rockchip,rk3066a
>  
> +      - description: Cool Pi 4 Model B
> +        items:
> +          - const: CoolPi 4 Model B

- const: coolpi,pi-4b

at least according to https://cool-pi.com/category/6/pi-4b
this seems to be the model name

> +          - const: rockchip,rk3588s
> +
>        - description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
>          items:
>            - const: edgeble,neural-compute-module-2-io   # Edgeble Neural Compute Module 2 IO Board
> 






From heiko at sntech.de  Sat Dec  9 06:01:51 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sat, 09 Dec 2023 15:01:51 +0100
Subject: [PATCH 4/5] dt-bindings: arm: rockchip: Add Cool Pi CM5 EVB
In-Reply-To: <20231209103815.1568614-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
 <20231209103815.1568614-1-andyshrk@163.com>
Message-ID: <2595712.Icojqenx9y@diego>

Am Samstag, 9. Dezember 2023, 11:38:15 CET schrieb Andy Yan:
> Add Cool Pi CM5 EVB, a board powered by RK3588
> 
> Signed-off-by: Andy Yan <andyshrk at 163.com>
> ---
> 
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 5de9f3090be1..24dc6dfb8285 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -95,6 +95,11 @@ properties:
>            - const: chipspark,rayeager-px2
>            - const: rockchip,rk3066a
>  
> +      - description: Cool Pi Compute Module 5(CM5) EVB
> +        items:
> +          - const: CoolPi CM5 EVB

similar
- const: coolpi,pi-cm5

from
https://cool-pi.com/category/11/pi-cm5


> +          - const: rockchip,rk3588
> +
>        - description: Cool Pi 4 Model B
>          items:
>            - const: CoolPi 4 Model B
> 






From krzysztof.kozlowski at linaro.org  Sat Dec  9 06:03:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 9 Dec 2023 15:03:07 +0100
Subject: [PATCH 3/5] arm64: dts: rockchip: Add support for rk3588s based
 board CoolPi 4B
In-Reply-To: <20231209103802.1568552-1-andyshrk@163.com>
References: <20231209103622.1568289-1-andyshrk@163.com>
 <20231209103802.1568552-1-andyshrk@163.com>
Message-ID: <a019de0c-4f88-4016-b08c-9f4049f2b8d0@linaro.org>

On 09/12/2023 11:38, Andy Yan wrote:
> CoolPi 4B is a rk3588s based SBC.
> Specification:
> - Rockchip RK3588S
> - LPDDR4 2/4/8/16 GB
> - TF scard slot


> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/soc/rockchip,vop2.h>
> +#include "rk3588s.dtsi"
> +
> +/ {
> +	model = "RK3588S CoolPi 4B";
> +	compatible = "CoolPi 4 Model B", "rockchip,rk3588s";

That's not a real compatible.

> +
> +	aliases {
> +		mmc0 = &sdhci;
> +		mmc1 = &sdio;
> +		mmc2 = &sdmmc;
> +		serial2 = &uart2;
> +	};
> +
> +	analog-sound {
> +		compatible = "audio-graph-card";
> +		label = "rk3588-es8316";
> +
> +		widgets = "Microphone", "Mic Jack",
> +			  "Headphone", "Headphones";
> +
> +		routing = "MIC2", "Mic Jack",
> +			  "Headphones", "HPOL",
> +			  "Headphones", "HPOR";
> +
> +		dais = <&i2s0_8ch_p0>;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial2:1500000n8";
> +	};
> +
> +	leds: leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl- = <&gpio_leds>;
> +		status = "okay";

Drop

> +
> +		led0: led-green {
> +			color = <LED_COLOR_ID_GREEN>;
> +			function = LED_FUNCTION_STATUS;
> +			gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_HIGH>;
> +			linux,default-trigger = "heartbeat";
> +		};
> +
> +		led1: led-red {
> +			color = <LED_COLOR_ID_RED>;
> +			function = LED_FUNCTION_WLAN;
> +			gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> +			linux,default-trigger = "phy0tx";
> +			default-state = "off";
> +		};
> +	};

...

> +
> +&i2c2 {
> +	status = "okay";
> +
> +	vdd_npu_s0: regulator at 42 {
> +		compatible = "rockchip,rk8602";
> +		reg = <0x42>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_npu_s0";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <950000>;
> +		regulator-ramp-delay = <2300>;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +

Stray blank line

> +};
> +
> +&i2s0_8ch {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2s0_lrck
> +		     &i2s0_mclk
> +		     &i2s0_sclk
> +		     &i2s0_sdi0
> +		     &i2s0_sdo0>;
> +	status = "okay";
> +
> +	i2s0_8ch_p0: port {
> +		i2s0_8ch_p0_0: endpoint {
> +			dai-format = "i2s";
> +			mclk-fs = <256>;
> +			remote-endpoint = <&es8316_p0_0>;
> +		};
> +	};
> +};
> +

...

> +
> +&hdmi0 {
> +	enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
> +	pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd &hdmim0_tx0_scl &hdmim0_tx0_sda>;
> +	status = "okay";
> +};
> +
> +&i2c6 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c6m3_xfer>;
> +	status = "okay";
> +
> +	hym8563: hym8563 at 51 {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation


> +		compatible = "haoyu,hym8563";
> +		reg = <0x51>;
> +		#clock-cells = <0>;
> +		clock-frequency = <32768>;
> +		clock-output-names = "hym8563";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&hym8563_int>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
> +		status = "okay";
> +	};
> +

Stray blank line

> +};



Best regards,
Krzysztof



From u.kleine-koenig at pengutronix.de  Sat Dec  9 06:05:12 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Sat, 9 Dec 2023 15:05:12 +0100
Subject: [PATCH 0/7] pcmcia: Convert to platform remove callback
 returning void
In-Reply-To: <2023120930-possum-ignore-e8df@gregkh>
References: <cover.1702051073.git.u.kleine-koenig@pengutronix.de>
 <ZXNsLJfqs9DLHb1Q@shine.dominikbrodowski.net>
 <2023120930-possum-ignore-e8df@gregkh>
Message-ID: <20231209140512.b62vkdufmvdxzghg@pengutronix.de>

Hello,

On Sat, Dec 09, 2023 at 10:28:36AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 08, 2023 at 08:19:08PM +0100, Dominik Brodowski wrote:
> > Both options are fine with me. In the latter case:
> > 
> > 	Acked-by: Dominik Brodowski <linux at dominikbrodowski.net>
> 
> I can take these, thanks!

I missed Greg's reply when I just suggested that Dominik should take
these. Either way is fine for me.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231209/ae6693b4/attachment.sig>

From frank-w at public-files.de  Sat Dec  9 06:56:15 2023
From: frank-w at public-files.de (Frank Wunderlich)
Date: Sat, 9 Dec 2023 15:56:15 +0100
Subject: Aw: [PATCH v2 4/5] arm64: dts: mt7986: add dtbs with applied
 overlays for bpi-r3
In-Reply-To: <20231025170832.78727-5-linux@fw-web.de>
References: <20231025170832.78727-1-linux@fw-web.de>
 <20231025170832.78727-5-linux@fw-web.de>
Message-ID: <trinity-a61f3152-8b44-4efb-9176-cc00a9449e63-1702133775512@3c-app-gmx-bs23>

Hi

Parts 1-3 are applied here, but how to proceed with this? to add further devicetrees like
for mt7988 we have to fix the "broken" dt-overlays first.

i want to keep to build the dtbo to allow dynamic apply in bootloader, but they should be checked in
compiletime too and full dtb should be created for users not wanting to handle overlays.

regards Frank


> Gesendet: Mittwoch, 25. Oktober 2023 um 18:08 Uhr
> Von: "Frank Wunderlich" <linux at fw-web.de>

> Build devicetree binaries for testing overlays and providing users
> full dtb without using overlays.
>
> Suggested-by: Rob Herring <robh+dt at kernel.org>
> Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
> ---
> https://lore.kernel.org/all/CAL_JsqK_3xxD0DFwipXO85P=q=EYjUdjE1_8g1MKtvw3vVzx5A at mail.gmail.com/
> https://lore.kernel.org/all/CAL_JsqJSi=kJSix=f3787ULZnaCy_Y26Phdhy5y9fat_vkDuUw at mail.gmail.com/
>
> v2:
> make full dtbs multiline for better readability
> ---
>  arch/arm64/boot/dts/mediatek/Makefile | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index c99c3372a4b5..24eeba0703ce 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -8,11 +8,33 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
> +
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc.dtbo
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nand.dtbo
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nor.dtbo
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd.dtbo
> +mt7986a-bananapi-bpi-r3-emmc-nand-dtbs := \
> +	mt7986a-bananapi-bpi-r3.dtb \
> +	mt7986a-bananapi-bpi-r3-emmc.dtbo \
> +	mt7986a-bananapi-bpi-r3-nand.dtbo
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nand.dtb
> +mt7986a-bananapi-bpi-r3-emmc-nor-dtbs := \
> +	mt7986a-bananapi-bpi-r3.dtb \
> +	mt7986a-bananapi-bpi-r3-emmc.dtbo \
> +	mt7986a-bananapi-bpi-r3-nor.dtbo
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nor.dtb
> +mt7986a-bananapi-bpi-r3-sd-nand-dtbs := \
> +	mt7986a-bananapi-bpi-r3.dtb \
> +	mt7986a-bananapi-bpi-r3-sd.dtbo \
> +	mt7986a-bananapi-bpi-r3-nand.dtbo
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nand.dtb
> +mt7986a-bananapi-bpi-r3-sd-nor-dtbs := \
> +	mt7986a-bananapi-bpi-r3.dtb \
> +	mt7986a-bananapi-bpi-r3-sd.dtbo \
> +	mt7986a-bananapi-bpi-r3-nor.dtbo
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nor.dtb
> +
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-rfb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986b-rfb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8167-pumpkin.dtb



From laurent.pinchart at ideasonboard.com  Sat Dec  9 07:29:46 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Sat, 9 Dec 2023 17:29:46 +0200
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com>
 <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com>
 <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
Message-ID: <20231209152946.GC13421@pendragon.ideasonboard.com>

On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> On Thu, Dec 7, 2023 at 11:38?PM Laurent Pinchart
> <laurent.pinchart at ideasonboard.com> wrote:
> >
> > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > Hi Simon,
> > > >
> > > > Thank you for the patch.
> > > >
> > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > containing the built kernel and associated devicetree files.
> > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > performance.
> > > > >
> > > > > The files compress from about 86MB to 24MB using this approach.
> > > > >
> > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > devicetree, matching the compatible string of the running board with
> > > > > the closest compatible string in the FIT. There is no need for
> > > > > filenames or other workarounds.
> > > > >
> > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > FIT_COMPRESSION to select a different algorithm.
> > > > >
> > > > > The FIT can be examined using 'dumpimage -l'.
> > > > >
> > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > requires compression utilities for the algorithm being used. Supported
> > > > > compression options are the same as the Image.xxx files. For now there
> > > > > is no way to change the compression other than by editing the rule for
> > > > > $(obj)/image.fit
> > > > >
> > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > this here, since it must be built separately from the Linux build.
> > > >
> > > > FIT images are very useful, so I think this is a very welcome addition
> > > > to the kernel build system. It can get tricky though: given the
> > > > versatile nature of FIT images, there can't be any
> > > > one-size-fits-them-all solution to build them, and striking the right
> > > > balance between what makes sense for the kernel and the features that
> > > > users may request will probably lead to bikeshedding. As we all love
> > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > to delay merging this series.
> > > >
> > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > extending the supported command line arguments. It would perhaps be more
> > > > difficult to integrate in the kernel build system though. This leads me
> > > > to a second question: would you consider merging extensions to this
> > > > script if they are not used by the kernel build system, but meant for
> > > > users who manually invoke the script ? More generally, is the script
> > >
> > > We'd also be interested in some customization, though in a different way.
> > > We imagine having a rule file that says X compatible string should map
> > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > DTB would carry all common elements of some device, while the DTBOs
> > > carry all the possible second source components, like different display
> > > panels or MIPI cameras for instance. This could drastically reduce the
> > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> >
> > Do you envision the "mapping" compatible string mapping to a config
> > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> 
> That's exactly the idea. The mapping compatible string could be untied
> from the base board's compatible string if needed (which we probably do).
> 
> So something like:
> 
> config {
>     config-1 {
>         compatible = "google,krane-sku0";
>         fdt = "krane-baseboard", "krane-sku0-overlay";
>     };
> };
> 
> With "krane-sku0-overlay" being an overlay that holds the differences
> between the SKUs, in this case the display panel and MIPI camera (not
> upstreamed) that applies to SKU0 in particular.

The kernel DT makefiles already contain information on what overlays to
apply to what base boards, in order to test the overlays and produce
"full" DTBs. Maybe that information could be leveraged to create the
configurations in the FIT image ?

> Sorry for not giving a more concrete idea.
> 
> > > > meant to be used stand-alone as well, in which case its command line
> > > > arguments need to remain backward-compatible, or do you see it as being
> > > > internal to the kernel ?
> > >
> > > [...]

-- 
Regards,

Laurent Pinchart


From ohtvd at chem.uni-sofia.bg  Wed Dec  6 04:56:11 2023
From: ohtvd at chem.uni-sofia.bg (Kristine Wellenstein)
Date: 06 Dec 2023 07:56:11 -0500
Subject: [RE]: RE:
Message-ID: <20231206075611.DB45F8B9BF9F7DD0@chem.uni-sofia.bg>

Gr??e,

Mein Name ist Kristine Wellenstein. Ich schreibe Ihnen, um Ihnen eine spannende Gesch?ftsm?glichkeit vorzustellen, von der ich glaube, dass sie f?r uns beide von Vorteil sein k?nnte.

Ich arbeite in einem bekannten Pharmaunternehmen in Asien und wir haben k?rzlich ein neues Produkt/eine neue Dienstleistung entwickelt, die neue M?glichkeiten er?ffnet.

Ich w?rde gerne eine Gesch?ftsvereinbarung vorschlagen, um diese M?glichkeit detaillierter zu besprechen. Ich bin zuversichtlich, dass diese Gelegenheit f?r uns beide von Vorteil w?re, wenn wir gut miteinander auskommen.

Ich freue mich auf die Gelegenheit, mit Ihnen zusammenzuarbeiten.

P.S. Sollten Sie nach unserem Gespr?ch kein Interesse an diesem Angebot haben, steht Ihnen ein Widerruf frei.

Ich erwarte eine positive Reaktion.

Gr??e

Kristine Wellenstein


From geert at linux-m68k.org  Sat Dec  9 08:31:03 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Sat, 9 Dec 2023 17:31:03 +0100
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231209152946.GC13421@pendragon.ideasonboard.com>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com> <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
 <20231209152946.GC13421@pendragon.ideasonboard.com>
Message-ID: <CAMuHMdVMZs6mnwWBgFwktO=8o=QzROv60cfZe085MhD6HxQjpQ@mail.gmail.com>

Hi Laurent,

On Sat, Dec 9, 2023 at 4:29?PM Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > On Thu, Dec 7, 2023 at 11:38?PM Laurent Pinchart
> > <laurent.pinchart at ideasonboard.com> wrote:
> > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > containing the built kernel and associated devicetree files.
> > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > performance.
> > > > > >
> > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > >
> > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > devicetree, matching the compatible string of the running board with
> > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > filenames or other workarounds.
> > > > > >
> > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > >
> > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > >
> > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > is no way to change the compression other than by editing the rule for
> > > > > > $(obj)/image.fit
> > > > > >
> > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > this here, since it must be built separately from the Linux build.
> > > > >
> > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > to the kernel build system. It can get tricky though: given the
> > > > > versatile nature of FIT images, there can't be any
> > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > balance between what makes sense for the kernel and the features that
> > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > to delay merging this series.
> > > > >
> > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > extending the supported command line arguments. It would perhaps be more
> > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > to a second question: would you consider merging extensions to this
> > > > > script if they are not used by the kernel build system, but meant for
> > > > > users who manually invoke the script ? More generally, is the script
> > > >
> > > > We'd also be interested in some customization, though in a different way.
> > > > We imagine having a rule file that says X compatible string should map
> > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > DTB would carry all common elements of some device, while the DTBOs
> > > > carry all the possible second source components, like different display
> > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > >
> > > Do you envision the "mapping" compatible string mapping to a config
> > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> >
> > That's exactly the idea. The mapping compatible string could be untied
> > from the base board's compatible string if needed (which we probably do).
> >
> > So something like:
> >
> > config {
> >     config-1 {
> >         compatible = "google,krane-sku0";
> >         fdt = "krane-baseboard", "krane-sku0-overlay";
> >     };
> > };
> >
> > With "krane-sku0-overlay" being an overlay that holds the differences
> > between the SKUs, in this case the display panel and MIPI camera (not
> > upstreamed) that applies to SKU0 in particular.
>
> The kernel DT makefiles already contain information on what overlays to
> apply to what base boards, in order to test the overlays and produce
> "full" DTBs. Maybe that information could be leveraged to create the
> configurations in the FIT image ?

Although the "full" DTBs created may only be a subset of all possible
combinations (I believe Rob just started with creating one "full" DTB
for each overlay, cfr. the additions I made in commit a09c3e105a208580
("arm64: dts: renesas: Apply overlays to base dtbs")), that could
definitely be a start.

Now, since the kernel build system already creates "full" DTBs, does
that mean that all of the base DTBs, overlays, and "full" DTBs will
end up in the FIT image?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From kamal.dasu at broadcom.com  Sat Dec  9 08:58:15 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Sat,  9 Dec 2023 11:58:15 -0500
Subject: [V3, 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
Message-ID: <20231209165816.39044-1-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

With newer sdio controller core used for 74165b0 we need to update
the compatibility with "brcm,bcm74165b0-sdhci".

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
---
 .../devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml         | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
index c028039bc477..ea97b8c5a283 100644
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
+++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
@@ -20,11 +20,9 @@ properties:
           - const: brcm,sdhci-brcmstb
       - items:
           - enum:
+              - brcm,bcm74165b0-sdhci
               - brcm,bcm7445-sdhci
-          - const: brcm,sdhci-brcmstb
-      - items:
-          - enum:
-              - brcm,bcm7425-sdhci
+	      - brcm,bcm7425-sdhci
           - const: brcm,sdhci-brcmstb
 
   reg:
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231209/7e2720d3/attachment.p7s>

From kamal.dasu at broadcom.com  Sat Dec  9 08:58:16 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Sat,  9 Dec 2023 11:58:16 -0500
Subject: [V3, 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231209165816.39044-1-kamal.dasu@broadcom.com>
References: <20231209165816.39044-1-kamal.dasu@broadcom.com>
Message-ID: <20231209165816.39044-2-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

74165b0 shall use a new sdio controller core version which
requires a different reset sequence. For core reset we use
sdhci_reset. For CMD and/or DATA reset added a new function
to also enable SDCHI clocks SDHCI_CLOCK_CARD_EN
SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
SDHCI_RESET_DATA fields.

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312091608.0VbkRxlh-lkp at intel.com/
Closes:
https://lore.kernel.org/oe-kbuild-all/202312091905.UGzltx8A-lkp at intel.com/``````````````
---
 drivers/mmc/host/sdhci-brcmstb.c | 69 +++++++++++++++++++++++++++++---
 1 file changed, 64 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index c23251bb95f3..d4bd5b3c0fa4 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -44,8 +44,13 @@ struct brcmstb_match_priv {
 
 static inline void enable_clock_gating(struct sdhci_host *host)
 {
+	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
 	u32 reg;
 
+	if (!(priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK))
+		return;
+
 	reg = sdhci_readl(host, SDHCI_VENDOR);
 	reg |= SDHCI_VENDOR_GATE_SDCLK_EN;
 	sdhci_writel(host, reg, SDHCI_VENDOR);
@@ -53,14 +58,54 @@ static inline void enable_clock_gating(struct sdhci_host *host)
 
 static void brcmstb_reset(struct sdhci_host *host, u8 mask)
 {
-	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
-
 	sdhci_and_cqhci_reset(host, mask);
 
 	/* Reset will clear this, so re-enable it */
-	if (priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK)
-		enable_clock_gating(host);
+	enable_clock_gating(host);
+}
+
+static void brcmstb_sdhci_reset_cmd_data(struct sdhci_host *host, u8 mask)
+{
+	ktime_t timeout;
+	u32 reg;
+	u32 new_mask = (mask &  (SDHCI_RESET_CMD | SDHCI_RESET_DATA)) << 24;
+
+	new_mask |= SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN;
+	reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
+	sdhci_writel(host, reg | new_mask, SDHCI_CLOCK_CONTROL);
+
+	/* Wait max 10 ms */
+	timeout = ktime_add_ms(ktime_get(), 10);
+
+	/* hw clears the bit when it's done */
+	while (1) {
+		bool timedout = ktime_after(ktime_get(), timeout);
+
+		if (!(sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask))
+			break;
+		if (timedout) {
+			pr_err("%s: Reset 0x%x never completed.\n",
+				mmc_hostname(host->mmc), (int)mask);
+			sdhci_err_stats_inc(host, CTRL_TIMEOUT);
+			sdhci_dumpregs(host);
+			return;
+		}
+		udelay(10);
+	}
+}
+
+static void brcmstb_reset_74165b0(struct sdhci_host *host, u8 mask)
+{
+	/* take care of RESET_ALL as usual */
+	if (mask & SDHCI_RESET_ALL)
+		sdhci_and_cqhci_reset(host, SDHCI_RESET_ALL);
+
+	/* cmd and/or data treated differently on this core */
+	if (mask & (SDHCI_RESET_CMD | SDHCI_RESET_DATA))
+		brcmstb_sdhci_reset_cmd_data(host, mask);
+
+	/* Reset will clear this, so re-enable it */
+	enable_clock_gating(host);
 }
 
 static void sdhci_brcmstb_hs400es(struct mmc_host *mmc, struct mmc_ios *ios)
@@ -162,6 +207,13 @@ static struct sdhci_ops sdhci_brcmstb_ops_7216 = {
 	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
 };
 
+static struct sdhci_ops sdhci_brcmstb_ops_74165b0 = {
+	.set_clock = sdhci_brcmstb_set_clock,
+	.set_bus_width = sdhci_set_bus_width,
+	.reset = brcmstb_reset_74165b0,
+	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
+};
+
 static struct brcmstb_match_priv match_priv_7425 = {
 	.flags = BRCMSTB_MATCH_FLAGS_NO_64BIT |
 	BRCMSTB_MATCH_FLAGS_BROKEN_TIMEOUT,
@@ -179,10 +231,17 @@ static const struct brcmstb_match_priv match_priv_7216 = {
 	.ops = &sdhci_brcmstb_ops_7216,
 };
 
+static struct brcmstb_match_priv match_priv_74165b0 = {
+	.flags = BRCMSTB_MATCH_FLAGS_HAS_CLOCK_GATE,
+	.hs400es = sdhci_brcmstb_hs400es,
+	.ops = &sdhci_brcmstb_ops_74165b0,
+};
+
 static const struct of_device_id __maybe_unused sdhci_brcm_of_match[] = {
 	{ .compatible = "brcm,bcm7425-sdhci", .data = &match_priv_7425 },
 	{ .compatible = "brcm,bcm7445-sdhci", .data = &match_priv_7445 },
 	{ .compatible = "brcm,bcm7216-sdhci", .data = &match_priv_7216 },
+	{ .compatible = "brcm,bcm74165b0-sdhci", .data = &match_priv_74165b0 },
 	{},
 };
 
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231209/2f962964/attachment.p7s>

From horms at kernel.org  Sat Dec  9 09:02:41 2023
From: horms at kernel.org (Simon Horman)
Date: Sat, 9 Dec 2023 17:02:41 +0000
Subject: [RFC PATCH net-next v3 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <20231201163704.1306431-2-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
 <20231201163704.1306431-2-maxime.chevallier@bootlin.com>
Message-ID: <20231209170241.GA5817@kernel.org>

On Fri, Dec 01, 2023 at 05:36:51PM +0100, Maxime Chevallier wrote:
> Link topologies containing multiple network PHYs attached to the same
> net_device can be found when using a PHY as a media converter for use
> with an SFP connector, on which an SFP transceiver containing a PHY can
> be used.
> 
> With the current model, the transceiver's PHY can't be used for
> operations such as cable testing, timestamping, macsec offload, etc.
> 
> The reason being that most of the logic for these configuration, coming
> from either ethtool netlink or ioctls tend to use netdev->phydev, which
> in multi-phy systems will reference the PHY closest to the MAC.
> 
> Introduce a numbering scheme allowing to enumerate PHY devices that
> belong to any netdev, which can in turn allow userspace to take more
> precise decisions with regard to each PHY's configuration.
> 
> The numbering is maintained per-netdev, in a phy_device_list.
> The numbering works similarly to a netdevice's ifindex, with
> identifiers that are only recycled once INT_MAX has been reached.
> 
> This prevents races that could occur between PHY listing and SFP
> transceiver removal/insertion.
> 
> The identifiers are assigned at phy_attach time, as the numbering
> depends on the netdevice the phy is attached to.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>

Hi Maxime,

some minor feedback from my side.

...

> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index f65e85c91fc1..3cf7774df57e 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for Linux PHY drivers
>  
>  libphy-y			:= phy.o phy-c45.o phy-core.o phy_device.o \
> -				   linkmode.o
> +				   linkmode.o phy_link_topology.o
>  mdio-bus-y			+= mdio_bus.o mdio_device.o
>  
>  ifdef CONFIG_MDIO_DEVICE
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c

...

> @@ -265,6 +266,14 @@ static void phy_mdio_device_remove(struct mdio_device *mdiodev)
>  
>  static struct phy_driver genphy_driver;
>  
> +static struct phy_link_topology *phy_get_link_topology(struct phy_device *phydev)
> +{
> +	if (phydev->attached_dev)
> +		return &phydev->attached_dev->link_topo;
> +
> +	return NULL;
> +}
> +

This function is declared static but is unused, which causes
allmodconfig W=1 builds to fail. Perhaps it could be introduced
in a latter patch where it is used?

...

> diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c

...

> +void phy_link_topo_init(struct phy_link_topology *topo)
> +{
> +	xa_init_flags(&topo->phys, XA_FLAGS_ALLOC1);
> +	topo->next_phy_index = 1;
> +}

...

> diff --git a/include/linux/phy_link_topology.h b/include/linux/phy_link_topology.h

...

> +#else
> +static struct phy_device *phy_link_topo_get_phy(struct phy_link_topology *topo,
> +						u32 phyindex)
> +{
> +	return NULL;
> +}
> +
> +static int phy_link_topo_add_phy(struct phy_link_topology *topo,
> +				 struct phy_device *phy,
> +				 enum phy_upstream upt, void *upstream)
> +{
> +	return 0;
> +}
> +
> +static void phy_link_topo_del_phy(struct phy_link_topology *topo,
> +				  struct phy_device *phy)
> +{
> +}
> +#endif

nit: functions in .h should be declared static inline

...

> diff --git a/net/core/dev.c b/net/core/dev.c

...

> @@ -10832,6 +10833,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
>  #ifdef CONFIG_NET_SCHED
>  	hash_init(dev->qdisc_hash);
>  #endif
> +	phy_link_topo_init(&dev->link_topo);
> +

I don't think this can work unless PHYLIB is compiled as a built-in.

>  	dev->priv_flags = IFF_XMIT_DST_RELEASE | IFF_XMIT_DST_RELEASE_PERM;
>  	setup(dev);
>  
> -- 
> 2.42.0
> 


From krzysztof.kozlowski at linaro.org  Sat Dec  9 09:03:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 9 Dec 2023 18:03:32 +0100
Subject: [V3, 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231209165816.39044-2-kamal.dasu@broadcom.com>
References: <20231209165816.39044-1-kamal.dasu@broadcom.com>
 <20231209165816.39044-2-kamal.dasu@broadcom.com>
Message-ID: <70ee9d1e-50f9-44d0-ae32-d443cee3af1c@linaro.org>

On 09/12/2023 17:58, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> 74165b0 shall use a new sdio controller core version which
> requires a different reset sequence. For core reset we use
> sdhci_reset. For CMD and/or DATA reset added a new function
> to also enable SDCHI clocks SDHCI_CLOCK_CARD_EN
> SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
> SDHCI_RESET_DATA fields.
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312091608.0VbkRxlh-lkp at intel.com/
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202312091905.UGzltx8A-lkp at intel.com/``````````````

Except malformed `````, drop all three tags.

Please test your patch on local setup. Usually many LPK reports move the
patch down the queue. :(

Best regards,
Krzysztof



From horms at kernel.org  Sat Dec  9 09:04:57 2023
From: horms at kernel.org (Simon Horman)
Date: Sat, 9 Dec 2023 17:04:57 +0000
Subject: [RFC PATCH net-next v3 07/13] net: ethtool: Introduce a command
 to list PHYs on an interface
In-Reply-To: <20231201163704.1306431-8-maxime.chevallier@bootlin.com>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
 <20231201163704.1306431-8-maxime.chevallier@bootlin.com>
Message-ID: <20231209170457.GB5817@kernel.org>

On Fri, Dec 01, 2023 at 05:36:57PM +0100, Maxime Chevallier wrote:
> As we have the ability to track the PHYs connected to a net_device
> through the link_topology, we can expose this list to userspace. This
> allows userspace to use these identifiers for phy-specific commands and
> take the decision of which PHY to target by knowing the link topology.
> 
> Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list
> devices on only one interface.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>

...

> diff --git a/net/ethtool/phy.c b/net/ethtool/phy.c

...

> +static int ethnl_phy_dump_one_dev(struct sk_buff *skb, struct net_device *dev,
> +				  struct netlink_callback *cb)
> +{
> +	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
> +	struct phy_req_info *pri = ctx->phy_req_info;
> +	struct phy_device_node *pdn;
> +	unsigned long index = 1;
> +	void *ehdr;
> +	int ret;
> +
> +	pri->base.dev = dev;
> +
> +	xa_for_each(&dev->link_topo.phys, index, pdn) {
> +		ehdr = ethnl_dump_put(skb, cb,
> +				      ETHTOOL_MSG_PHY_GET_REPLY);
> +		if (!ehdr) {
> +			ret = -EMSGSIZE;
> +			break;
> +		}
> +
> +		ret = ethnl_fill_reply_header(skb, dev,
> +					      ETHTOOL_A_PHY_HEADER);
> +		if (ret < 0) {
> +			genlmsg_cancel(skb, ehdr);
> +			break;
> +		}
> +
> +		memcpy(&pri->pdn, pdn, sizeof(*pdn));
> +		ret = ethnl_phy_fill_reply(&pri->base, skb);
> +
> +		genlmsg_end(skb, ehdr);
> +	}
> +
> +	return ret;

Hi Maxime,

I am unsure if this can happen (or if I flagged this before)
but if the loop runs zero times then ret is uninitialised here.

Flagged by Smatch

> +}

...


From krzk at kernel.org  Sat Dec  9 09:05:35 2023
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sat, 9 Dec 2023 18:05:35 +0100
Subject: [V3, 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for
 74165b0
In-Reply-To: <20231209165816.39044-1-kamal.dasu@broadcom.com>
References: <20231209165816.39044-1-kamal.dasu@broadcom.com>
Message-ID: <b1896664-652f-4a4c-b765-b3ef9fd0feac@kernel.org>

On 09/12/2023 17:58, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> With newer sdio controller core used for 74165b0 we need to update
> the compatibility with "brcm,bcm74165b0-sdhci".
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> ---

This wasn't tested. Using community reviewers instead of automated tools
for testing is a huge waste of our scarce resources. This makes me sad.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sat Dec  9 09:06:14 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 9 Dec 2023 18:06:14 +0100
Subject: [V3, 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for
 74165b0
In-Reply-To: <20231209165816.39044-1-kamal.dasu@broadcom.com>
References: <20231209165816.39044-1-kamal.dasu@broadcom.com>
Message-ID: <162c94cd-ee95-43c5-a2d1-46f9b35b1a87@linaro.org>

On 09/12/2023 17:58, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> With newer sdio controller core used for 74165b0 we need to update
> the compatibility with "brcm,bcm74165b0-sdhci".

Please use standard email subjects, so with the PATCH keyword in the
title. `git format-patch` helps here to create proper versioned patches.
Another useful tool is b4. Skipping the PATCH keyword makes filtering of
emails more difficult thus making the review process less convenient.

Your v2 was already made this error. I expected v3 will be correct.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sat Dec  9 09:16:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat,  9 Dec 2023 18:16:12 +0100
Subject: [PATCH] arm64: dts: juno: align thermal zone names with bindings
Message-ID: <20231209171612.250868-1-krzysztof.kozlowski@linaro.org>

Thermal bindings require thermal zone node names to match
certain patterns:

  juno.dtb: thermal-zones: 'big-cluster', 'gpu0', 'gpu1', 'little-cluster', 'pmic', 'soc'
    do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+'

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 12 ++++++------
 arch/arm64/boot/dts/arm/juno-scmi.dtsi | 12 ++++++------
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 8b4d280b1e7e..b897f5542c0a 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -747,7 +747,7 @@ scpi_sensors0: sensors {
 	};
 
 	thermal-zones {
-		pmic {
+		pmic-thermal {
 			polling-delay = <1000>;
 			polling-delay-passive = <100>;
 			thermal-sensors = <&scpi_sensors0 0>;
@@ -760,7 +760,7 @@ pmic_crit0: trip0 {
 			};
 		};
 
-		soc {
+		soc-thermal {
 			polling-delay = <1000>;
 			polling-delay-passive = <100>;
 			thermal-sensors = <&scpi_sensors0 3>;
@@ -773,28 +773,28 @@ soc_crit0: trip0 {
 			};
 		};
 
-		big_cluster_thermal_zone: big-cluster {
+		big_cluster_thermal_zone: big-cluster-thermal {
 			polling-delay = <1000>;
 			polling-delay-passive = <100>;
 			thermal-sensors = <&scpi_sensors0 21>;
 			status = "disabled";
 		};
 
-		little_cluster_thermal_zone: little-cluster {
+		little_cluster_thermal_zone: little-cluster-thermal {
 			polling-delay = <1000>;
 			polling-delay-passive = <100>;
 			thermal-sensors = <&scpi_sensors0 22>;
 			status = "disabled";
 		};
 
-		gpu0_thermal_zone: gpu0 {
+		gpu0_thermal_zone: gpu0-thermal {
 			polling-delay = <1000>;
 			polling-delay-passive = <100>;
 			thermal-sensors = <&scpi_sensors0 23>;
 			status = "disabled";
 		};
 
-		gpu1_thermal_zone: gpu1 {
+		gpu1_thermal_zone: gpu1-thermal {
 			polling-delay = <1000>;
 			polling-delay-passive = <100>;
 			thermal-sensors = <&scpi_sensors0 24>;
diff --git a/arch/arm64/boot/dts/arm/juno-scmi.dtsi b/arch/arm64/boot/dts/arm/juno-scmi.dtsi
index ec85cd2c733c..31929e2377d8 100644
--- a/arch/arm64/boot/dts/arm/juno-scmi.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-scmi.dtsi
@@ -76,27 +76,27 @@ scmi_sensors0: protocol at 15 {
 	};
 
 	thermal-zones {
-		pmic {
+		pmic-thermal {
 			thermal-sensors = <&scmi_sensors0 0>;
 		};
 
-		soc {
+		soc-thermal {
 			thermal-sensors = <&scmi_sensors0 3>;
 		};
 
-		big-cluster {
+		big-cluster-thermal {
 			thermal-sensors = <&scmi_sensors0 21>;
 		};
 
-		little-cluster {
+		little-cluster-thermal {
 			thermal-sensors = <&scmi_sensors0 22>;
 		};
 
-		gpu0 {
+		gpu0-thermal {
 			thermal-sensors = <&scmi_sensors0 23>;
 		};
 
-		gpu1 {
+		gpu1-thermal {
 			thermal-sensors = <&scmi_sensors0 24>;
 		};
 	};
-- 
2.34.1



From david at ixit.cz  Sat Dec  9 09:15:40 2023
From: david at ixit.cz (David Heidelberg)
Date: Sat,  9 Dec 2023 18:15:40 +0100
Subject: [PATCH v4 2/3] arm64: dts: rockchip: make dts use gpio-fan matrix instead of array
In-Reply-To: <20231209171653.85468-1-david@ixit.cz>
References: <20231209171653.85468-1-david@ixit.cz>
Message-ID: <20231209171653.85468-2-david@ixit.cz>

No functional changes.

Adjust to comply with dt-schema requirements
and make possible to validate values.

Acked-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: David Heidelberg <david at ixit.cz>
---
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi  | 2 +-
 arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index e6ac292ce645..69dd3568b84e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -44,7 +44,7 @@ dc_12v: dc-12v {
 	fan0: gpio-fan {
 		#cooling-cells = <2>;
 		compatible = "gpio-fan";
-		gpio-fan,speed-map = <0 0 3000 1>;
+		gpio-fan,speed-map = <0 0>, <3000 1>;
 		gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>;
 		status = "okay";
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
index 854d02b46e6f..59843a7a199c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
@@ -31,8 +31,9 @@ gmac1_clkin: external-gmac1-clock {
 	fan: gpio_fan {
 		compatible = "gpio-fan";
 		gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
-		gpio-fan,speed-map = <0    0
-				      4500 1>;
+		gpio-fan,speed-map =
+				<   0 0>,
+				<4500 1>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&fan_en_h>;
 		#cooling-cells = <2>;
-- 
2.42.0



From robh at kernel.org  Sat Dec  9 10:14:09 2023
From: robh at kernel.org (Rob Herring)
Date: Sat, 09 Dec 2023 12:14:09 -0600
Subject: [V3, 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support
 for 74165b0
In-Reply-To: <20231209165816.39044-1-kamal.dasu@broadcom.com>
References: <20231209165816.39044-1-kamal.dasu@broadcom.com>
Message-ID: <170214564970.1553144.16154651415666446700.robh@kernel.org>


On Sat, 09 Dec 2023 11:58:15 -0500, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> With newer sdio controller core used for 74165b0 we need to update
> the compatibility with "brcm,bcm74165b0-sdhci".
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> ---
>  .../devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml         | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml:25:1: [error] syntax error: found character '\t' that cannot start any token (syntax)

dtschema/dtc warnings/errors:
make[2]: *** Deleting file 'Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.example.dts'
Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml:25:1: found a tab character that violates indentation
make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.example.dts] Error 1
make[2]: *** Waiting for unfinished jobs....
./Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml:25:1: found a tab character that violates indentation
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml: ignoring, error parsing file
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: dt_binding_check] Error 2
make: *** [Makefile:234: __sub-make] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231209165816.39044-1-kamal.dasu at broadcom.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From andi.shyti at kernel.org  Sat Dec  9 12:28:10 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Sat, 9 Dec 2023 21:28:10 +0100
Subject: [PATCH v3 1/2] i2c: aspeed: Handle the coalesced stop conditions
 with the start conditions.
In-Reply-To: <20231208033142.1673232-2-quan@os.amperecomputing.com>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
 <20231208033142.1673232-2-quan@os.amperecomputing.com>
Message-ID: <20231209202810.r7kkz2hlaonyibha@zenone.zhora.eu>

Hi Quan,

On Fri, Dec 08, 2023 at 10:31:41AM +0700, Quan Nguyen wrote:
> Some masters may drive the transfers with low enough latency between
> the nak/stop phase of the current command and the start/address phase
> of the following command that the interrupts are coalesced by the
> time we process them.
> Handle the stop conditions before processing SLAVE_MATCH to fix the
> complaints that sometimes occur below.
> 
> "aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
> 0x00000086, but was 0x00000084"
> 
> Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>

Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Thanks,
Andi


From andi.shyti at kernel.org  Sat Dec  9 12:44:55 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Sat, 9 Dec 2023 21:44:55 +0100
Subject: [PATCH v3 2/2] i2c: aspeed: Acknowledge Tx done with and without
 ACK irq late
In-Reply-To: <20231208033142.1673232-3-quan@os.amperecomputing.com>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
 <20231208033142.1673232-3-quan@os.amperecomputing.com>
Message-ID: <20231209204455.jxize3muvx7hhpos@zenone.zhora.eu>

Hi Quan,

[...]

> -	/* Ack all interrupts except for Rx done */
> -	writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
> -	       bus->base + ASPEED_I2C_INTR_STS_REG);
> +
> +	/*
> +	 * Early acking of INTR_RX_DONE and INTR_TX_[ACK|NAK] would indicate HW to
> +	 * start receiving or sending new data, and this may cause a race condition
> +	 * as the irq handler has not yet handled these irqs but is being acked.
> +	 * Let's ack them late at the end of the irq handler when those are truly processed.
> +	 */
> +	irq_ack_last = ASPEED_I2CD_INTR_RX_DONE | ASPEED_I2CD_INTR_TX_ACK | ASPEED_I2CD_INTR_TX_NAK;
> +	writel(irq_received & ~irq_ack_last, bus->base + ASPEED_I2C_INTR_STS_REG);

I like Andrews suggestion of having irq_ack_last as a define that
is already negated, instead of negating it in the writel, which
makes it a bit difficult to read.

Besides, ack_last, as a name is not very meaningful, I'd rather
call it irq_ack_rx_tx (or something similar).

But I'm not going to block it for this, up to you if you want to
send a new version.

Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Thanks,
Andi


From andi.shyti at kernel.org  Sat Dec  9 12:57:44 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Sat, 9 Dec 2023 21:57:44 +0100
Subject: [PATCH v2] i2c: cadence: Add system suspend and resume PM support
In-Reply-To: <20231209131516.1916550-1-jisheng.teoh@starfivetech.com>
References: <20231209131516.1916550-1-jisheng.teoh@starfivetech.com>
Message-ID: <20231209205744.ehmthjvn7nuslvhd@zenone.zhora.eu>

Hi Ji Sheng,

On Sat, Dec 09, 2023 at 09:15:16PM +0800, Ji Sheng Teoh wrote:
> Enable device system suspend and resume PM support, and mark the device
> state as suspended during system suspend to reject any data transfer.
> 
> Signed-off-by: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
> ---
> Changes since v1:
> - Add missing err assignment in cdns_i2c_resume().

thanks for the quick version update. However, while it's nice to
see such prompt proactivity, we also need to allow more time for
others to review your change.

Next time, please give it a bit more time before sending out
version 2. :-)

> ---
>  drivers/i2c/busses/i2c-cadence.c | 33 ++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
> index de3f58b60dce..4bb7d6756947 100644
> --- a/drivers/i2c/busses/i2c-cadence.c
> +++ b/drivers/i2c/busses/i2c-cadence.c
> @@ -1176,6 +1176,18 @@ static int __maybe_unused cdns_i2c_runtime_suspend(struct device *dev)
>  	return 0;
>  }
>  
> +static int __maybe_unused cdns_i2c_suspend(struct device *dev)
> +{
> +	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
> +
> +	i2c_mark_adapter_suspended(&xi2c->adap);
> +
> +	if (!pm_runtime_status_suspended(dev))
> +		return cdns_i2c_runtime_suspend(dev);
> +
> +	return 0;
> +}
> +
>  /**
>   * cdns_i2c_init -  Controller initialisation
>   * @id:		Device private data structure
> @@ -1219,7 +1231,28 @@ static int __maybe_unused cdns_i2c_runtime_resume(struct device *dev)
>  	return 0;
>  }
>  
> +static int __maybe_unused cdns_i2c_resume(struct device *dev)
> +{

I am not really understanding what you are trying to do here:

> +	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
> +	int err;
> +
> +	err = cdns_i2c_runtime_resume(dev);

First you try to resume...

> +	if (err)
> +		return err;
> +
> +	if (pm_runtime_status_suspended(dev)) {

... then you check if you are suspended ...

> +		err = cdns_i2c_runtime_suspend(dev);

... and suspend again? Shouldn't this be _resume()?

Thanks,
Andi

> +		if (err)
> +			return err;
> +	}
> +
> +	i2c_mark_adapter_resumed(&xi2c->adap);
> +
> +	return 0;
> +}
> +
>  static const struct dev_pm_ops cdns_i2c_dev_pm_ops = {
> +	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(cdns_i2c_suspend, cdns_i2c_resume)
>  	SET_RUNTIME_PM_OPS(cdns_i2c_runtime_suspend,
>  			   cdns_i2c_runtime_resume, NULL)
>  };
> -- 
> 2.25.1
> 


From daniel at makrotopia.org  Sat Dec  9 13:55:41 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 9 Dec 2023 21:55:41 +0000
Subject: [PATCH v4 1/4] dt-bindings: clock: mediatek: add MT7988 clock IDs
Message-ID: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add MT7988 clock dt-bindings for topckgen, apmixedsys, infracfg,
ethernet and xfipll subsystem clocks.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
v4: no changes
v3: no changes
v2: fix indentation

 .../dt-bindings/clock/mediatek,mt7988-clk.h   | 280 ++++++++++++++++++
 1 file changed, 280 insertions(+)
 create mode 100644 include/dt-bindings/clock/mediatek,mt7988-clk.h

diff --git a/include/dt-bindings/clock/mediatek,mt7988-clk.h b/include/dt-bindings/clock/mediatek,mt7988-clk.h
new file mode 100644
index 0000000000000..63376e40f14d2
--- /dev/null
+++ b/include/dt-bindings/clock/mediatek,mt7988-clk.h
@@ -0,0 +1,280 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#ifndef _DT_BINDINGS_CLK_MT7988_H
+#define _DT_BINDINGS_CLK_MT7988_H
+
+/* APMIXEDSYS */
+
+#define CLK_APMIXED_NETSYSPLL			0
+#define CLK_APMIXED_MPLL			1
+#define CLK_APMIXED_MMPLL			2
+#define CLK_APMIXED_APLL2			3
+#define CLK_APMIXED_NET1PLL			4
+#define CLK_APMIXED_NET2PLL			5
+#define CLK_APMIXED_WEDMCUPLL			6
+#define CLK_APMIXED_SGMPLL			7
+#define CLK_APMIXED_ARM_B			8
+#define CLK_APMIXED_CCIPLL2_B			9
+#define CLK_APMIXED_USXGMIIPLL			10
+#define CLK_APMIXED_MSDCPLL			11
+
+/* TOPCKGEN */
+
+#define CLK_TOP_XTAL				0
+#define CLK_TOP_XTAL_D2				1
+#define CLK_TOP_RTC_32K				2
+#define CLK_TOP_RTC_32P7K			3
+#define CLK_TOP_MPLL_D2				4
+#define CLK_TOP_MPLL_D3_D2			5
+#define CLK_TOP_MPLL_D4				6
+#define CLK_TOP_MPLL_D8				7
+#define CLK_TOP_MPLL_D8_D2			8
+#define CLK_TOP_MMPLL_D2			9
+#define CLK_TOP_MMPLL_D3_D5			10
+#define CLK_TOP_MMPLL_D4			11
+#define CLK_TOP_MMPLL_D6_D2			12
+#define CLK_TOP_MMPLL_D8			13
+#define CLK_TOP_APLL2_D4			14
+#define CLK_TOP_NET1PLL_D4			15
+#define CLK_TOP_NET1PLL_D5			16
+#define CLK_TOP_NET1PLL_D5_D2			17
+#define CLK_TOP_NET1PLL_D5_D4			18
+#define CLK_TOP_NET1PLL_D8			19
+#define CLK_TOP_NET1PLL_D8_D2			20
+#define CLK_TOP_NET1PLL_D8_D4			21
+#define CLK_TOP_NET1PLL_D8_D8			22
+#define CLK_TOP_NET1PLL_D8_D16			23
+#define CLK_TOP_NET2PLL_D2			24
+#define CLK_TOP_NET2PLL_D4			25
+#define CLK_TOP_NET2PLL_D4_D4			26
+#define CLK_TOP_NET2PLL_D4_D8			27
+#define CLK_TOP_NET2PLL_D6			28
+#define CLK_TOP_NET2PLL_D8			29
+#define CLK_TOP_NETSYS_SEL			30
+#define CLK_TOP_NETSYS_500M_SEL			31
+#define CLK_TOP_NETSYS_2X_SEL			32
+#define CLK_TOP_NETSYS_GSW_SEL			33
+#define CLK_TOP_ETH_GMII_SEL			34
+#define CLK_TOP_NETSYS_MCU_SEL			35
+#define CLK_TOP_NETSYS_PAO_2X_SEL		36
+#define CLK_TOP_EIP197_SEL			37
+#define CLK_TOP_AXI_INFRA_SEL			38
+#define CLK_TOP_UART_SEL			39
+#define CLK_TOP_EMMC_250M_SEL			40
+#define CLK_TOP_EMMC_400M_SEL			41
+#define CLK_TOP_SPI_SEL				42
+#define CLK_TOP_SPIM_MST_SEL			43
+#define CLK_TOP_NFI1X_SEL			44
+#define CLK_TOP_SPINFI_SEL			45
+#define CLK_TOP_PWM_SEL				46
+#define CLK_TOP_I2C_SEL				47
+#define CLK_TOP_PCIE_MBIST_250M_SEL		48
+#define CLK_TOP_PEXTP_TL_SEL			49
+#define CLK_TOP_PEXTP_TL_P1_SEL			50
+#define CLK_TOP_PEXTP_TL_P2_SEL			51
+#define CLK_TOP_PEXTP_TL_P3_SEL			52
+#define CLK_TOP_USB_SYS_SEL			53
+#define CLK_TOP_USB_SYS_P1_SEL			54
+#define CLK_TOP_USB_XHCI_SEL			55
+#define CLK_TOP_USB_XHCI_P1_SEL			56
+#define CLK_TOP_USB_FRMCNT_SEL			57
+#define CLK_TOP_USB_FRMCNT_P1_SEL		58
+#define CLK_TOP_AUD_SEL				59
+#define CLK_TOP_A1SYS_SEL			60
+#define CLK_TOP_AUD_L_SEL			61
+#define CLK_TOP_A_TUNER_SEL			62
+#define CLK_TOP_SSPXTP_SEL			63
+#define CLK_TOP_USB_PHY_SEL			64
+#define CLK_TOP_USXGMII_SBUS_0_SEL		65
+#define CLK_TOP_USXGMII_SBUS_1_SEL		66
+#define CLK_TOP_SGM_0_SEL			67
+#define CLK_TOP_SGM_SBUS_0_SEL			68
+#define CLK_TOP_SGM_1_SEL			69
+#define CLK_TOP_SGM_SBUS_1_SEL			70
+#define CLK_TOP_XFI_PHY_0_XTAL_SEL		71
+#define CLK_TOP_XFI_PHY_1_XTAL_SEL		72
+#define CLK_TOP_SYSAXI_SEL			73
+#define CLK_TOP_SYSAPB_SEL			74
+#define CLK_TOP_ETH_REFCK_50M_SEL		75
+#define CLK_TOP_ETH_SYS_200M_SEL		76
+#define CLK_TOP_ETH_SYS_SEL			77
+#define CLK_TOP_ETH_XGMII_SEL			78
+#define CLK_TOP_BUS_TOPS_SEL			79
+#define CLK_TOP_NPU_TOPS_SEL			80
+#define CLK_TOP_DRAMC_SEL			81
+#define CLK_TOP_DRAMC_MD32_SEL			82
+#define CLK_TOP_INFRA_F26M_SEL			83
+#define CLK_TOP_PEXTP_P0_SEL			84
+#define CLK_TOP_PEXTP_P1_SEL			85
+#define CLK_TOP_PEXTP_P2_SEL			86
+#define CLK_TOP_PEXTP_P3_SEL			87
+#define CLK_TOP_DA_XTP_GLB_P0_SEL		88
+#define CLK_TOP_DA_XTP_GLB_P1_SEL		89
+#define CLK_TOP_DA_XTP_GLB_P2_SEL		90
+#define CLK_TOP_DA_XTP_GLB_P3_SEL		91
+#define CLK_TOP_CKM_SEL				92
+#define CLK_TOP_DA_SEL				93
+#define CLK_TOP_PEXTP_SEL			94
+#define CLK_TOP_TOPS_P2_26M_SEL			95
+#define CLK_TOP_MCUSYS_BACKUP_625M_SEL		96
+#define CLK_TOP_NETSYS_SYNC_250M_SEL		97
+#define CLK_TOP_MACSEC_SEL			98
+#define CLK_TOP_NETSYS_TOPS_400M_SEL		99
+#define CLK_TOP_NETSYS_PPEFB_250M_SEL		100
+#define CLK_TOP_NETSYS_WARP_SEL			101
+#define CLK_TOP_ETH_MII_SEL			102
+#define CLK_TOP_NPU_SEL				103
+#define CLK_TOP_AUD_I2S_M			104
+
+/* MCUSYS */
+
+#define CLK_MCU_BUS_DIV_SEL			0
+#define CLK_MCU_ARM_DIV_SEL			1
+
+/* INFRACFG_AO */
+
+#define CLK_INFRA_MUX_UART0_SEL			0
+#define CLK_INFRA_MUX_UART1_SEL			1
+#define CLK_INFRA_MUX_UART2_SEL			2
+#define CLK_INFRA_MUX_SPI0_SEL			3
+#define CLK_INFRA_MUX_SPI1_SEL			4
+#define CLK_INFRA_MUX_SPI2_SEL			5
+#define CLK_INFRA_PWM_SEL			6
+#define CLK_INFRA_PWM_CK1_SEL			7
+#define CLK_INFRA_PWM_CK2_SEL			8
+#define CLK_INFRA_PWM_CK3_SEL			9
+#define CLK_INFRA_PWM_CK4_SEL			10
+#define CLK_INFRA_PWM_CK5_SEL			11
+#define CLK_INFRA_PWM_CK6_SEL			12
+#define CLK_INFRA_PWM_CK7_SEL			13
+#define CLK_INFRA_PWM_CK8_SEL			14
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL	15
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL	16
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL	17
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL	18
+
+/* INFRACFG */
+
+#define CLK_INFRA_PCIE_PERI_26M_CK_P0		19
+#define CLK_INFRA_PCIE_PERI_26M_CK_P1		20
+#define CLK_INFRA_PCIE_PERI_26M_CK_P2		21
+#define CLK_INFRA_PCIE_PERI_26M_CK_P3		22
+#define CLK_INFRA_66M_GPT_BCK			23
+#define CLK_INFRA_66M_PWM_HCK			24
+#define CLK_INFRA_66M_PWM_BCK			25
+#define CLK_INFRA_66M_PWM_CK1			26
+#define CLK_INFRA_66M_PWM_CK2			27
+#define CLK_INFRA_66M_PWM_CK3			28
+#define CLK_INFRA_66M_PWM_CK4			29
+#define CLK_INFRA_66M_PWM_CK5			30
+#define CLK_INFRA_66M_PWM_CK6			31
+#define CLK_INFRA_66M_PWM_CK7			32
+#define CLK_INFRA_66M_PWM_CK8			33
+#define CLK_INFRA_133M_CQDMA_BCK		34
+#define CLK_INFRA_66M_AUD_SLV_BCK		35
+#define CLK_INFRA_AUD_26M			36
+#define CLK_INFRA_AUD_L				37
+#define CLK_INFRA_AUD_AUD			38
+#define CLK_INFRA_AUD_EG2			39
+#define CLK_INFRA_DRAMC_F26M			40
+#define CLK_INFRA_133M_DBG_ACKM			41
+#define CLK_INFRA_66M_AP_DMA_BCK		42
+#define CLK_INFRA_66M_SEJ_BCK			43
+#define CLK_INFRA_PRE_CK_SEJ_F13M		44
+#define CLK_INFRA_26M_THERM_SYSTEM		45
+#define CLK_INFRA_I2C_BCK			46
+#define CLK_INFRA_52M_UART0_CK			47
+#define CLK_INFRA_52M_UART1_CK			48
+#define CLK_INFRA_52M_UART2_CK			49
+#define CLK_INFRA_NFI				50
+#define CLK_INFRA_SPINFI			51
+#define CLK_INFRA_66M_NFI_HCK			52
+#define CLK_INFRA_104M_SPI0			53
+#define CLK_INFRA_104M_SPI1			54
+#define CLK_INFRA_104M_SPI2_BCK			55
+#define CLK_INFRA_66M_SPI0_HCK			56
+#define CLK_INFRA_66M_SPI1_HCK			57
+#define CLK_INFRA_66M_SPI2_HCK			58
+#define CLK_INFRA_66M_FLASHIF_AXI		59
+#define CLK_INFRA_RTC				60
+#define CLK_INFRA_26M_ADC_BCK			61
+#define CLK_INFRA_RC_ADC			62
+#define CLK_INFRA_MSDC400			63
+#define CLK_INFRA_MSDC2_HCK			64
+#define CLK_INFRA_133M_MSDC_0_HCK		65
+#define CLK_INFRA_66M_MSDC_0_HCK		66
+#define CLK_INFRA_133M_CPUM_BCK			67
+#define CLK_INFRA_BIST2FPC			68
+#define CLK_INFRA_I2C_X16W_MCK_CK_P1		69
+#define CLK_INFRA_I2C_X16W_PCK_CK_P1		70
+#define CLK_INFRA_133M_USB_HCK			71
+#define CLK_INFRA_133M_USB_HCK_CK_P1		72
+#define CLK_INFRA_66M_USB_HCK			73
+#define CLK_INFRA_66M_USB_HCK_CK_P1		74
+#define CLK_INFRA_USB_SYS			75
+#define CLK_INFRA_USB_SYS_CK_P1			76
+#define CLK_INFRA_USB_REF			77
+#define CLK_INFRA_USB_CK_P1			78
+#define CLK_INFRA_USB_FRMCNT			79
+#define CLK_INFRA_USB_FRMCNT_CK_P1		80
+#define CLK_INFRA_USB_PIPE			81
+#define CLK_INFRA_USB_PIPE_CK_P1		82
+#define CLK_INFRA_USB_UTMI			83
+#define CLK_INFRA_USB_UTMI_CK_P1		84
+#define CLK_INFRA_USB_XHCI			85
+#define CLK_INFRA_USB_XHCI_CK_P1		86
+#define CLK_INFRA_PCIE_GFMUX_TL_P0		87
+#define CLK_INFRA_PCIE_GFMUX_TL_P1		88
+#define CLK_INFRA_PCIE_GFMUX_TL_P2		89
+#define CLK_INFRA_PCIE_GFMUX_TL_P3		90
+#define CLK_INFRA_PCIE_PIPE_P0			91
+#define CLK_INFRA_PCIE_PIPE_P1			92
+#define CLK_INFRA_PCIE_PIPE_P2			93
+#define CLK_INFRA_PCIE_PIPE_P3			94
+#define CLK_INFRA_133M_PCIE_CK_P0		95
+#define CLK_INFRA_133M_PCIE_CK_P1		96
+#define CLK_INFRA_133M_PCIE_CK_P2		97
+#define CLK_INFRA_133M_PCIE_CK_P3		98
+
+/* ETHDMA */
+
+#define CLK_ETHDMA_XGP1_EN			0
+#define CLK_ETHDMA_XGP2_EN			1
+#define CLK_ETHDMA_XGP3_EN			2
+#define CLK_ETHDMA_FE_EN			3
+#define CLK_ETHDMA_GP2_EN			4
+#define CLK_ETHDMA_GP1_EN			5
+#define CLK_ETHDMA_GP3_EN			6
+#define CLK_ETHDMA_ESW_EN			7
+#define CLK_ETHDMA_CRYPT0_EN			8
+#define CLK_ETHDMA_NR_CLK			9
+
+/* SGMIISYS_0 */
+
+#define CLK_SGM0_TX_EN				0
+#define CLK_SGM0_RX_EN				1
+#define CLK_SGMII0_NR_CLK			2
+
+/* SGMIISYS_1 */
+
+#define CLK_SGM1_TX_EN				0
+#define CLK_SGM1_RX_EN				1
+#define CLK_SGMII1_NR_CLK			2
+
+/* ETHWARP */
+
+#define CLK_ETHWARP_WOCPU2_EN			0
+#define CLK_ETHWARP_WOCPU1_EN			1
+#define CLK_ETHWARP_WOCPU0_EN			2
+#define CLK_ETHWARP_NR_CLK			3
+
+/* XFIPLL */
+#define CLK_XFIPLL_PLL				0
+#define CLK_XFIPLL_PLL_EN			1
+
+#endif /* _DT_BINDINGS_CLK_MT7988_H */
-- 
2.43.0


From daniel at makrotopia.org  Sat Dec  9 13:55:58 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 9 Dec 2023 21:55:58 +0000
Subject: [PATCH v4 2/4] dt-bindings: clock: mediatek: add clock controllers
 of MT7988
In-Reply-To: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
References: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
Message-ID: <93025cdb7c31bf413fb2be5a071340073a0679d1.1702158423.git.daniel@makrotopia.org>

Add various clock controllers found in the MT7988 SoC to existing
bindings (if applicable) and add files for the new ethwarp, mcusys
and xfi-pll clock controllers not previously present in any SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v4:
 * add subnodes for controllers acting as MFD

v3:
 * move clock bindings to clock folder
 * drop ti,syscon-reset from bindings and example
 * merge mcusys with topckgen bindings

v2:
 * dropped unused labels
 * add 'type: object' declaration for reset-controller found in new
   ethwarp controller and represented as ti,syscon-reset
 * rebase on top of
   "dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema"

 .../arm/mediatek/mediatek,infracfg.yaml       |  1 +
 .../bindings/clock/mediatek,apmixedsys.yaml   |  1 +
 .../bindings/clock/mediatek,ethsys.yaml       |  1 +
 .../clock/mediatek,mt7988-ethwarp.yaml        | 66 +++++++++++++++++++
 .../clock/mediatek,mt7988-xfi-pll.yaml        | 48 ++++++++++++++
 .../bindings/clock/mediatek,topckgen.yaml     |  2 +
 .../bindings/net/pcs/mediatek,sgmiisys.yaml   | 61 ++++++++++++++---
 7 files changed, 171 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
index ea98043c6ba3d..230b5188a88db 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
@@ -30,6 +30,7 @@ properties:
               - mediatek,mt7629-infracfg
               - mediatek,mt7981-infracfg
               - mediatek,mt7986-infracfg
+              - mediatek,mt7988-infracfg
               - mediatek,mt8135-infracfg
               - mediatek,mt8167-infracfg
               - mediatek,mt8173-infracfg
diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
index 372c1d744bc27..685535846cbb7 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
@@ -22,6 +22,7 @@ properties:
           - mediatek,mt7622-apmixedsys
           - mediatek,mt7981-apmixedsys
           - mediatek,mt7986-apmixedsys
+          - mediatek,mt7988-apmixedsys
           - mediatek,mt8135-apmixedsys
           - mediatek,mt8173-apmixedsys
           - mediatek,mt8516-apmixedsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
index 94d42c8647777..f9cddacc2eae1 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
@@ -22,6 +22,7 @@ properties:
               - mediatek,mt7629-ethsys
               - mediatek,mt7981-ethsys
               - mediatek,mt7986-ethsys
+              - mediatek,mt7988-ethsys
           - const: syscon
       - items:
           - const: mediatek,mt7623-ethsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
new file mode 100644
index 0000000000000..e126f3fe0856c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7988-ethwarp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 ethwarp Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The Mediatek MT7988 ethwarp controller provides clocks and resets for the
+  Ethernet related subsystems found the MT7988 SoC.
+  The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
+
+properties:
+  compatible:
+    items:
+      - const: mediatek,mt7988-ethwarp
+      - const: syscon
+      - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+  reset-controller:
+    type: object
+    properties:
+      compatible:
+        const: ti,syscon-reset
+
+    # TODO: Convert to DT schema
+    additionalProperties: true
+
+required:
+  - compatible
+  - reg
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/reset/ti-syscon.h>
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        clock-controller at 15031000 {
+            compatible = "mediatek,mt7988-ethwarp", "syscon", "simple-mfd";
+            reg = <0 0x15031000 0 0x1000>;
+            #clock-cells = <1>;
+
+            reset-controller {
+                compatible = "ti,syscon-reset";
+                #reset-cells = <1>;
+                ti,reset-bits = <
+                  0x8 9 0x8 9 0 0 (ASSERT_SET | DEASSERT_CLEAR | STATUS_NONE)
+                >;
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
new file mode 100644
index 0000000000000..fe5e3a70299fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7988-xfi-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 XFI PLL Clock Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The MediaTek XFI PLL controller provides the 156.25MHz clock for the
+  Ethernet SerDes PHY from the 40MHz top_xtal clock.
+
+properties:
+  compatible:
+    const: mediatek,mt7988-xfi-pll
+
+  reg:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - resets
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+        clock-controller at 11f40000 {
+            compatible = "mediatek,mt7988-xfi-pll";
+            reg = <0 0x11f40000 0 0x1000>;
+            resets = <&watchdog 16>;
+            #clock-cells = <1>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
index 6d087ded7437a..bdf3b55bd56fd 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
@@ -37,6 +37,8 @@ properties:
               - mediatek,mt7629-topckgen
               - mediatek,mt7981-topckgen
               - mediatek,mt7986-topckgen
+              - mediatek,mt7988-mcusys
+              - mediatek,mt7988-topckgen
               - mediatek,mt8167-topckgen
               - mediatek,mt8183-topckgen
           - const: syscon
diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
index 66a95191bd776..f5f1fd97c50eb 100644
--- a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
+++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
@@ -15,15 +15,22 @@ description:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - mediatek,mt7622-sgmiisys
-          - mediatek,mt7629-sgmiisys
-          - mediatek,mt7981-sgmiisys_0
-          - mediatek,mt7981-sgmiisys_1
-          - mediatek,mt7986-sgmiisys_0
-          - mediatek,mt7986-sgmiisys_1
-      - const: syscon
+    oneOf:
+      - items:
+          - enum:
+              - mediatek,mt7622-sgmiisys
+              - mediatek,mt7629-sgmiisys
+              - mediatek,mt7981-sgmiisys_0
+              - mediatek,mt7981-sgmiisys_1
+              - mediatek,mt7986-sgmiisys_0
+              - mediatek,mt7986-sgmiisys_1
+          - const: syscon
+      - items:
+          - enum:
+              - mediatek,mt7988-sgmiisys_0
+              - mediatek,mt7988-sgmiisys_1
+          - const: simple-mfd
+          - const: syscon
 
   reg:
     maxItems: 1
@@ -35,11 +42,47 @@ properties:
     description: Invert polarity of the SGMII data lanes
     type: boolean
 
+  pcs:
+    type: object
+    description: HSGMII PCS logic
+    properties:
+      compatible:
+        const: mediatek,mt7988-sgmii
+
+      clocks:
+        maxItems: 3
+        minItems: 3
+
+      clock-names:
+        items:
+          - const: sgmii_sel
+          - const: sgmii_tx
+          - const: sgmii_rx
+
+    required:
+      - compatible
+      - clocks
+      - clock-names
+
+    additionalProperties: false
+
 required:
   - compatible
   - reg
   - '#clock-cells'
 
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - mediatek,mt7988-sgmiisys_0
+          - mediatek,mt7988-sgmiisys_1
+
+then:
+  required:
+    - pcs
+
 additionalProperties: false
 
 examples:
-- 
2.43.0


From daniel at makrotopia.org  Sat Dec  9 13:56:09 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 9 Dec 2023 21:56:09 +0000
Subject: [PATCH v4 3/4] clk: mediatek: Add pcw_chg_shift control
In-Reply-To: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
References: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
Message-ID: <28c8ccd234ba311591b6db0de131fde36d3ec409.1702158423.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Introduce pcw_chg_shfit control to replace hardcoded PCW_CHG_MASK macro.
This will needed for clocks on the MT7988 SoC.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v4: always set .pcw_chg_shift if .pcw_chg_reg is used instead of
    having an if-expression in mtk_pll_set_rate_regs().
v3: use git --from ...
v2: no changes

 drivers/clk/mediatek/clk-mt6779.c            | 1 +
 drivers/clk/mediatek/clk-mt8183-apmixedsys.c | 1 +
 drivers/clk/mediatek/clk-mt8188-apmixedsys.c | 1 +
 drivers/clk/mediatek/clk-mt8192-apmixedsys.c | 1 +
 drivers/clk/mediatek/clk-mt8195-apmixedsys.c | 1 +
 drivers/clk/mediatek/clk-mt8365-apmixedsys.c | 1 +
 drivers/clk/mediatek/clk-pll.c               | 3 +--
 drivers/clk/mediatek/clk-pll.h               | 2 ++
 8 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt6779.c b/drivers/clk/mediatek/clk-mt6779.c
index ffedb1fe3c672..e66461f341dd3 100644
--- a/drivers/clk/mediatek/clk-mt6779.c
+++ b/drivers/clk/mediatek/clk-mt6779.c
@@ -1166,6 +1166,7 @@ static const struct mtk_gate apmixed_clks[] = {
 		.pcw_reg = _pcw_reg,					\
 		.pcw_shift = _pcw_shift,				\
 		.pcw_chg_reg = _pcw_chg_reg,				\
+		.pcw_chg_shift = PCW_CHG_SHIFT,				\
 		.div_table = _div_table,				\
 	}
 
diff --git a/drivers/clk/mediatek/clk-mt8183-apmixedsys.c b/drivers/clk/mediatek/clk-mt8183-apmixedsys.c
index 2b261c0e2b61d..184e0cd1dde29 100644
--- a/drivers/clk/mediatek/clk-mt8183-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8183-apmixedsys.c
@@ -75,6 +75,7 @@ static const struct mtk_gate apmixed_clks[] = {
 		.pcw_reg = _pcw_reg,					\
 		.pcw_shift = _pcw_shift,				\
 		.pcw_chg_reg = _pcw_chg_reg,				\
+		.pcw_chg_shift = PCW_CHG_SHIFT,				\
 		.div_table = _div_table,				\
 	}
 
diff --git a/drivers/clk/mediatek/clk-mt8188-apmixedsys.c b/drivers/clk/mediatek/clk-mt8188-apmixedsys.c
index 41ab4d6896a49..87c5dfa3d1ac4 100644
--- a/drivers/clk/mediatek/clk-mt8188-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8188-apmixedsys.c
@@ -53,6 +53,7 @@ static const struct mtk_gate apmixed_clks[] = {
 		.pcw_reg = _pcw_reg,					\
 		.pcw_shift = _pcw_shift,				\
 		.pcw_chg_reg = _pcw_chg_reg,				\
+		.pcw_chg_shift = PCW_CHG_SHIFT,				\
 		.en_reg = _en_reg,					\
 		.pll_en_bit = _pll_en_bit,				\
 	}
diff --git a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
index 3590932acc63a..67bf5ef3f0033 100644
--- a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
@@ -56,6 +56,7 @@ static const struct mtk_gate apmixed_clks[] = {
 		.pcw_reg = _pcw_reg,					\
 		.pcw_shift = _pcw_shift,				\
 		.pcw_chg_reg = _pcw_chg_reg,				\
+		.pcw_chg_shift = PCW_CHG_SHIFT,				\
 		.en_reg = _en_reg,					\
 		.pll_en_bit = _pll_en_bit,				\
 	}
diff --git a/drivers/clk/mediatek/clk-mt8195-apmixedsys.c b/drivers/clk/mediatek/clk-mt8195-apmixedsys.c
index 44a4c85a67ef5..ccd6bac7cb1fc 100644
--- a/drivers/clk/mediatek/clk-mt8195-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8195-apmixedsys.c
@@ -54,6 +54,7 @@ static const struct mtk_gate apmixed_clks[] = {
 		.pcw_reg = _pcw_reg,					\
 		.pcw_shift = _pcw_shift,				\
 		.pcw_chg_reg = _pcw_chg_reg,				\
+		.pcw_chg_shift = PCW_CHG_SHIFT,				\
 		.en_reg = _en_reg,					\
 		.pll_en_bit = _pll_en_bit,				\
 	}
diff --git a/drivers/clk/mediatek/clk-mt8365-apmixedsys.c b/drivers/clk/mediatek/clk-mt8365-apmixedsys.c
index 9b0bc5daeac06..daddca6db44e7 100644
--- a/drivers/clk/mediatek/clk-mt8365-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8365-apmixedsys.c
@@ -39,6 +39,7 @@
 		.pcw_reg = _pcw_reg,					\
 		.pcw_shift = _pcw_shift,				\
 		.pcw_chg_reg = _pcw_chg_reg,				\
+		.pcw_chg_shift = PCW_CHG_SHIFT,				\
 		.div_table = _div_table,				\
 	}
 
diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index 513ab6b1b3229..139b01ab8d140 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -23,7 +23,6 @@
 #define CON0_BASE_EN		BIT(0)
 #define CON0_PWR_ON		BIT(0)
 #define CON0_ISO_EN		BIT(1)
-#define PCW_CHG_MASK		BIT(31)
 
 #define AUDPLL_TUNER_EN		BIT(31)
 
@@ -114,7 +113,7 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll, u32 pcw,
 			pll->data->pcw_shift);
 	val |= pcw << pll->data->pcw_shift;
 	writel(val, pll->pcw_addr);
-	chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
+	chg = readl(pll->pcw_chg_addr) | BIT(pll->data->pcw_chg_shift);
 	writel(chg, pll->pcw_chg_addr);
 	if (pll->tuner_addr)
 		writel(val + 1, pll->tuner_addr);
diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
index f17278ff15d78..84bd8df13e2e5 100644
--- a/drivers/clk/mediatek/clk-pll.h
+++ b/drivers/clk/mediatek/clk-pll.h
@@ -22,6 +22,7 @@ struct mtk_pll_div_table {
 #define HAVE_RST_BAR	BIT(0)
 #define PLL_AO		BIT(1)
 #define POSTDIV_MASK	GENMASK(2, 0)
+#define PCW_CHG_SHIFT	31
 
 struct mtk_pll_data {
 	int id;
@@ -48,6 +49,7 @@ struct mtk_pll_data {
 	const char *parent_name;
 	u32 en_reg;
 	u8 pll_en_bit; /* Assume 0, indicates BIT(0) by default */
+	u8 pcw_chg_shift;
 };
 
 /*
-- 
2.43.0


From daniel at makrotopia.org  Sat Dec  9 13:56:20 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 9 Dec 2023 21:56:20 +0000
Subject: [PATCH v4 4/4] clk: mediatek: add drivers for MT7988 SoC
In-Reply-To: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
References: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
Message-ID: <879b5bbcb165aa3f059a41218142b27e5f64597f.1702158423.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add APMIXED, ETH, INFRACFG and TOPCKGEN clock drivers which are
typical MediaTek designs.

Also add driver for XFIPLL clock generating the 156.25MHz clock for
the XFI SerDes. It needs an undocumented software workaround and has
an unknown internal design.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v4:
 * make use of existing GATE_MTK_FLAGS macro
 * reformat to max. 100 columns
 * cosmetics

v3: use git --from ...
v2: no changes


 drivers/clk/mediatek/Kconfig               |   9 +
 drivers/clk/mediatek/Makefile              |   5 +
 drivers/clk/mediatek/clk-mt7988-apmixed.c  | 102 +++++++
 drivers/clk/mediatek/clk-mt7988-eth.c      | 133 +++++++++
 drivers/clk/mediatek/clk-mt7988-infracfg.c | 274 +++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-topckgen.c | 325 +++++++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-xfipll.c   |  78 +++++
 7 files changed, 926 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt7988-apmixed.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-eth.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-infracfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-topckgen.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-xfipll.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 48b42d11111cd..70a005e7e1b18 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -423,6 +423,15 @@ config COMMON_CLK_MT7986_ETHSYS
 	  This driver adds support for clocks for Ethernet and SGMII
 	  required on MediaTek MT7986 SoC.
 
+config COMMON_CLK_MT7988
+	tristate "Clock driver for MediaTek MT7988"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	select COMMON_CLK_MEDIATEK
+	default ARCH_MEDIATEK
+	help
+	  This driver supports MediaTek MT7988 basic clocks and clocks
+	  required for various periperals found on this SoC.
+
 config COMMON_CLK_MT8135
 	tristate "Clock driver for MediaTek MT8135"
 	depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index dbeaa5b41177d..eeccfa039896f 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -62,6 +62,11 @@ obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-apmixed.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-topckgen.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-infracfg.o
 obj-$(CONFIG_COMMON_CLK_MT7986_ETHSYS) += clk-mt7986-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-apmixed.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-topckgen.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-infracfg.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-xfipll.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135-apmixedsys.o clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8167) += clk-mt8167-apmixedsys.o clk-mt8167.o
 obj-$(CONFIG_COMMON_CLK_MT8167_AUDSYS) += clk-mt8167-aud.o
diff --git a/drivers/clk/mediatek/clk-mt7988-apmixed.c b/drivers/clk/mediatek/clk-mt7988-apmixed.c
new file mode 100644
index 0000000000000..02eb6354b01a8
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-apmixed.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include "clk-pll.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+#define MT7988_PLL_FMAX (2500UL * MHZ)
+#define MT7988_PCW_CHG_SHIFT 2
+
+#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _rst_bar_mask, _pcwbits, _pd_reg,      \
+	    _pd_shift, _tuner_reg, _tuner_en_reg, _tuner_en_bit, _pcw_reg, _pcw_shift,           \
+	    _pcw_chg_reg)                                                                        \
+	{                                                                                        \
+		.id = _id, .name = _name, .reg = _reg, .pwr_reg = _pwr_reg, .en_mask = _en_mask, \
+		.flags = _flags, .rst_bar_mask = BIT(_rst_bar_mask), .fmax = MT7988_PLL_FMAX,    \
+		.pcwbits = _pcwbits, .pd_reg = _pd_reg, .pd_shift = _pd_shift,                   \
+		.tuner_reg = _tuner_reg, .tuner_en_reg = _tuner_en_reg,                          \
+		.tuner_en_bit = _tuner_en_bit, .pcw_reg = _pcw_reg, .pcw_shift = _pcw_shift,     \
+		.pcw_chg_reg = _pcw_chg_reg, .pcw_chg_shift = MT7988_PCW_CHG_SHIFT,              \
+		.parent_name = "clkxtal",                                                        \
+	}
+
+static const struct mtk_pll_data plls[] = {
+	PLL(CLK_APMIXED_NETSYSPLL, "netsyspll", 0x0104, 0x0110, 0x00000001, 0, 0, 32, 0x0104, 4, 0,
+	    0, 0, 0x0108, 0, 0x0104),
+	PLL(CLK_APMIXED_MPLL, "mpll", 0x0114, 0x0120, 0xff000001, HAVE_RST_BAR, 23, 32, 0x0114, 4,
+	    0, 0, 0, 0x0118, 0, 0x0114),
+	PLL(CLK_APMIXED_MMPLL, "mmpll", 0x0124, 0x0130, 0xff000001, HAVE_RST_BAR, 23, 32, 0x0124, 4,
+	    0, 0, 0, 0x0128, 0, 0x0124),
+	PLL(CLK_APMIXED_APLL2, "apll2", 0x0134, 0x0140, 0x00000001, 0, 0, 32, 0x0134, 4, 0x0704,
+	    0x0700, 1, 0x0138, 0, 0x0134),
+	PLL(CLK_APMIXED_NET1PLL, "net1pll", 0x0144, 0x0150, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0144, 4, 0, 0, 0, 0x0148, 0, 0x0144),
+	PLL(CLK_APMIXED_NET2PLL, "net2pll", 0x0154, 0x0160, 0xff000001, (HAVE_RST_BAR | PLL_AO), 23,
+	    32, 0x0154, 4, 0, 0, 0, 0x0158, 0, 0x0154),
+	PLL(CLK_APMIXED_WEDMCUPLL, "wedmcupll", 0x0164, 0x0170, 0x00000001, 0, 0, 32, 0x0164, 4, 0,
+	    0, 0, 0x0168, 0, 0x0164),
+	PLL(CLK_APMIXED_SGMPLL, "sgmpll", 0x0174, 0x0180, 0x00000001, 0, 0, 32, 0x0174, 4, 0, 0, 0,
+	    0x0178, 0, 0x0174),
+	PLL(CLK_APMIXED_ARM_B, "arm_b", 0x0204, 0x0210, 0xff000001, (HAVE_RST_BAR | PLL_AO), 23, 32,
+	    0x0204, 4, 0, 0, 0, 0x0208, 0, 0x0204),
+	PLL(CLK_APMIXED_CCIPLL2_B, "ccipll2_b", 0x0214, 0x0220, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0214, 4, 0, 0, 0, 0x0218, 0, 0x0214),
+	PLL(CLK_APMIXED_USXGMIIPLL, "usxgmiipll", 0x0304, 0x0310, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0304, 4, 0, 0, 0, 0x0308, 0, 0x0304),
+	PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x0314, 0x0320, 0x00000001, 0, 0, 32, 0x0314, 4, 0, 0,
+	    0, 0x0318, 0, 0x0314),
+};
+
+static const struct of_device_id of_match_clk_mt7988_apmixed[] = {
+	{ .compatible = "mediatek,mt7988-apmixedsys" },
+	{ /* sentinel */ }
+};
+
+static int clk_mt7988_apmixed_probe(struct platform_device *pdev)
+{
+	struct clk_hw_onecell_data *clk_data;
+	struct device_node *node = pdev->dev.of_node;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(ARRAY_SIZE(plls));
+	if (!clk_data)
+		return -ENOMEM;
+
+	r = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	if (r)
+		goto free_apmixed_data;
+
+	r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
+	if (r)
+		goto unregister_plls;
+
+	return r;
+
+unregister_plls:
+	mtk_clk_unregister_plls(plls, ARRAY_SIZE(plls), clk_data);
+free_apmixed_data:
+	mtk_free_clk_data(clk_data);
+	return r;
+}
+
+static struct platform_driver clk_mt7988_apmixed_drv = {
+	.probe = clk_mt7988_apmixed_probe,
+	.driver = {
+		.name = "clk-mt7988-apmixed",
+		.of_match_table = of_match_clk_mt7988_apmixed,
+	},
+};
+builtin_platform_driver(clk_mt7988_apmixed_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-eth.c b/drivers/clk/mediatek/clk-mt7988-eth.c
new file mode 100644
index 0000000000000..49bfaba2827a3
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-eth.c
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static const struct mtk_gate_regs ethdma_cg_regs = {
+	.set_ofs = 0x30,
+	.clr_ofs = 0x30,
+	.sta_ofs = 0x30,
+};
+
+#define GATE_ETHDMA(_id, _name, _parent, _shift)                                           \
+	{                                                                                  \
+		.id = _id, .name = _name, .parent_name = _parent, .regs = &ethdma_cg_regs, \
+		.shift = _shift, .ops = &mtk_clk_gate_ops_no_setclr_inv,                   \
+	}
+
+static const struct mtk_gate ethdma_clks[] = {
+	GATE_ETHDMA(CLK_ETHDMA_XGP1_EN, "ethdma_xgp1_en", "top_xtal", 0),
+	GATE_ETHDMA(CLK_ETHDMA_XGP2_EN, "ethdma_xgp2_en", "top_xtal", 1),
+	GATE_ETHDMA(CLK_ETHDMA_XGP3_EN, "ethdma_xgp3_en", "top_xtal", 2),
+	GATE_ETHDMA(CLK_ETHDMA_FE_EN, "ethdma_fe_en", "netsys_2x_sel", 6),
+	GATE_ETHDMA(CLK_ETHDMA_GP2_EN, "ethdma_gp2_en", "top_xtal", 7),
+	GATE_ETHDMA(CLK_ETHDMA_GP1_EN, "ethdma_gp1_en", "top_xtal", 8),
+	GATE_ETHDMA(CLK_ETHDMA_GP3_EN, "ethdma_gp3_en", "top_xtal", 10),
+	GATE_ETHDMA(CLK_ETHDMA_ESW_EN, "ethdma_esw_en", "netsys_gsw_sel", 16),
+	GATE_ETHDMA(CLK_ETHDMA_CRYPT0_EN, "ethdma_crypt0_en", "eip197_sel", 29),
+};
+
+static const struct mtk_clk_desc ethdma_desc = {
+	.clks = ethdma_clks,
+	.num_clks = ARRAY_SIZE(ethdma_clks),
+};
+
+static const struct mtk_gate_regs sgmii0_cg_regs = {
+	.set_ofs = 0xe4,
+	.clr_ofs = 0xe4,
+	.sta_ofs = 0xe4,
+};
+
+#define GATE_SGMII0(_id, _name, _parent, _shift)                                           \
+	{                                                                                  \
+		.id = _id, .name = _name, .parent_name = _parent, .regs = &sgmii0_cg_regs, \
+		.shift = _shift, .ops = &mtk_clk_gate_ops_no_setclr_inv,                   \
+	}
+
+static const struct mtk_gate sgmii0_clks[] = {
+	GATE_SGMII0(CLK_SGM0_TX_EN, "sgm0_tx_en", "top_xtal", 2),
+	GATE_SGMII0(CLK_SGM0_RX_EN, "sgm0_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii0_desc = {
+	.clks = sgmii0_clks,
+	.num_clks = ARRAY_SIZE(sgmii0_clks),
+};
+
+static const struct mtk_gate_regs sgmii1_cg_regs = {
+	.set_ofs = 0xe4,
+	.clr_ofs = 0xe4,
+	.sta_ofs = 0xe4,
+};
+
+#define GATE_SGMII1(_id, _name, _parent, _shift)                                           \
+	{                                                                                  \
+		.id = _id, .name = _name, .parent_name = _parent, .regs = &sgmii1_cg_regs, \
+		.shift = _shift, .ops = &mtk_clk_gate_ops_no_setclr_inv,                   \
+	}
+
+static const struct mtk_gate sgmii1_clks[] = {
+	GATE_SGMII1(CLK_SGM1_TX_EN, "sgm1_tx_en", "top_xtal", 2),
+	GATE_SGMII1(CLK_SGM1_RX_EN, "sgm1_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii1_desc = {
+	.clks = sgmii1_clks,
+	.num_clks = ARRAY_SIZE(sgmii1_clks),
+};
+
+static const struct mtk_gate_regs ethwarp_cg_regs = {
+	.set_ofs = 0x14,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x14,
+};
+
+#define GATE_ETHWARP(_id, _name, _parent, _shift)                                           \
+	{                                                                                   \
+		.id = _id, .name = _name, .parent_name = _parent, .regs = &ethwarp_cg_regs, \
+		.shift = _shift, .ops = &mtk_clk_gate_ops_no_setclr_inv,                    \
+	}
+
+static const struct mtk_gate ethwarp_clks[] = {
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU2_EN, "ethwarp_wocpu2_en", "netsys_mcu_sel", 13),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU1_EN, "ethwarp_wocpu1_en", "netsys_mcu_sel", 14),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU0_EN, "ethwarp_wocpu0_en", "netsys_mcu_sel", 15),
+};
+
+static const struct mtk_clk_desc ethwarp_desc = {
+	.clks = ethwarp_clks,
+	.num_clks = ARRAY_SIZE(ethwarp_clks),
+};
+
+static const struct of_device_id of_match_clk_mt7988_eth[] = {
+	{ .compatible = "mediatek,mt7988-ethsys", .data = &ethdma_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys_0", .data = &sgmii0_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys_1", .data = &sgmii1_desc },
+	{ .compatible = "mediatek,mt7988-ethwarp", .data = &ethwarp_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_eth);
+
+static struct platform_driver clk_mt7988_eth_drv = {
+	.driver = {
+		.name = "clk-mt7988-eth",
+		.of_match_table = of_match_clk_mt7988_eth,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_eth_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 Ethernet clocks driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-infracfg.c b/drivers/clk/mediatek/clk-mt7988-infracfg.c
new file mode 100644
index 0000000000000..b7b4f7626d3d6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-infracfg.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const char *const infra_mux_uart0_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_uart1_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_uart2_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_spi0_parents[] __initconst = { "i2c_sel", "spi_sel" };
+
+static const char *const infra_mux_spi1_parents[] __initconst = { "i2c_sel", "spim_mst_sel" };
+
+static const char *const infra_pwm_bck_parents[] __initconst = { "top_rtc_32p7k",
+								 "csw_infra_f26m_sel", "sysaxi_sel",
+								 "pwm_sel" };
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p0_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p1_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p1_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p2_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p2_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p3_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p3_sel"
+};
+
+static const struct mtk_mux infra_muxes[] = {
+	/* MODULE_CLK_SEL_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART0_SEL, "infra_mux_uart0_sel",
+			     infra_mux_uart0_parents, 0x0018, 0x0010, 0x0014, 0, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART1_SEL, "infra_mux_uart1_sel",
+			     infra_mux_uart1_parents, 0x0018, 0x0010, 0x0014, 1, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART2_SEL, "infra_mux_uart2_sel",
+			     infra_mux_uart2_parents, 0x0018, 0x0010, 0x0014, 2, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI0_SEL, "infra_mux_spi0_sel", infra_mux_spi0_parents,
+			     0x0018, 0x0010, 0x0014, 4, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI1_SEL, "infra_mux_spi1_sel", infra_mux_spi1_parents,
+			     0x0018, 0x0010, 0x0014, 5, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI2_SEL, "infra_mux_spi2_sel", infra_mux_spi0_parents,
+			     0x0018, 0x0010, 0x0014, 6, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_SEL, "infra_pwm_sel", infra_pwm_bck_parents, 0x0018,
+			     0x0010, 0x0014, 14, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK1_SEL, "infra_pwm_ck1_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 16, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK2_SEL, "infra_pwm_ck2_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 18, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK3_SEL, "infra_pwm_ck3_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 20, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK4_SEL, "infra_pwm_ck4_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 22, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK5_SEL, "infra_pwm_ck5_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 24, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK6_SEL, "infra_pwm_ck6_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 26, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK7_SEL, "infra_pwm_ck7_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 28, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK8_SEL, "infra_pwm_ck8_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 30, 2, -1, -1, -1),
+	/* MODULE_CLK_SEL_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL, "infra_pcie_gfmux_tl_o_p0_sel",
+			     infra_pcie_gfmux_tl_ck_o_p0_parents, 0x0028, 0x0020, 0x0024, 0, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL, "infra_pcie_gfmux_tl_o_p1_sel",
+			     infra_pcie_gfmux_tl_ck_o_p1_parents, 0x0028, 0x0020, 0x0024, 2, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL, "infra_pcie_gfmux_tl_o_p2_sel",
+			     infra_pcie_gfmux_tl_ck_o_p2_parents, 0x0028, 0x0020, 0x0024, 4, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL, "infra_pcie_gfmux_tl_o_p3_sel",
+			     infra_pcie_gfmux_tl_ck_o_p3_parents, 0x0028, 0x0020, 0x0024, 6, 2, -1,
+			     -1, -1),
+};
+
+static const struct mtk_gate_regs infra0_cg_regs = {
+	.set_ofs = 0x10,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x18,
+};
+
+static const struct mtk_gate_regs infra1_cg_regs = {
+	.set_ofs = 0x40,
+	.clr_ofs = 0x44,
+	.sta_ofs = 0x48,
+};
+
+static const struct mtk_gate_regs infra2_cg_regs = {
+	.set_ofs = 0x50,
+	.clr_ofs = 0x54,
+	.sta_ofs = 0x58,
+};
+
+static const struct mtk_gate_regs infra3_cg_regs = {
+	.set_ofs = 0x60,
+	.clr_ofs = 0x64,
+	.sta_ofs = 0x68,
+};
+
+#define GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra0_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra1_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra2_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra3_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA0(_id, _name, _parent, _shift) GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA1(_id, _name, _parent, _shift) GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA2(_id, _name, _parent, _shift) GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA3(_id, _name, _parent, _shift) GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, 0)
+
+static const struct mtk_gate infra_clks[] = {
+	/* INFRA0 */
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P0, "infra_pcie_peri_ck_26m_ck_p0",
+		    "csw_infra_f26m_sel", 7),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P1, "infra_pcie_peri_ck_26m_ck_p1",
+		    "csw_infra_f26m_sel", 8),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P2, "infra_pcie_peri_ck_26m_ck_p2",
+		    "csw_infra_f26m_sel", 9),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P3, "infra_pcie_peri_ck_26m_ck_p3",
+		    "csw_infra_f26m_sel", 10),
+	/* INFRA1 */
+	GATE_INFRA1(CLK_INFRA_66M_GPT_BCK, "infra_hf_66m_gpt_bck", "sysaxi_sel", 0),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_HCK, "infra_hf_66m_pwm_hck", "sysaxi_sel", 1),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_BCK, "infra_hf_66m_pwm_bck", "infra_pwm_sel", 2),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK1, "infra_hf_66m_pwm_ck1", "infra_pwm_ck1_sel", 3),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK2, "infra_hf_66m_pwm_ck2", "infra_pwm_ck2_sel", 4),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK3, "infra_hf_66m_pwm_ck3", "infra_pwm_ck3_sel", 5),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK4, "infra_hf_66m_pwm_ck4", "infra_pwm_ck4_sel", 6),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK5, "infra_hf_66m_pwm_ck5", "infra_pwm_ck5_sel", 7),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK6, "infra_hf_66m_pwm_ck6", "infra_pwm_ck6_sel", 8),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK7, "infra_hf_66m_pwm_ck7", "infra_pwm_ck7_sel", 9),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK8, "infra_hf_66m_pwm_ck8", "infra_pwm_ck8_sel", 10),
+	GATE_INFRA1(CLK_INFRA_133M_CQDMA_BCK, "infra_hf_133m_cqdma_bck", "sysaxi_sel", 12),
+	GATE_INFRA1(CLK_INFRA_66M_AUD_SLV_BCK, "infra_66m_aud_slv_bck", "sysaxi_sel", 13),
+	GATE_INFRA1(CLK_INFRA_AUD_26M, "infra_f_faud_26m", "csw_infra_f26m_sel", 14),
+	GATE_INFRA1(CLK_INFRA_AUD_L, "infra_f_faud_l", "aud_l_sel", 15),
+	GATE_INFRA1(CLK_INFRA_AUD_AUD, "infra_f_aud_aud", "a1sys_sel", 16),
+	GATE_INFRA1(CLK_INFRA_AUD_EG2, "infra_f_faud_eg2", "a_tuner_sel", 18),
+	GATE_INFRA1_FLAGS(CLK_INFRA_DRAMC_F26M, "infra_dramc_f26m", "csw_infra_f26m_sel", 19,
+			  CLK_IS_CRITICAL),
+	/* JTAG */
+	GATE_INFRA1_FLAGS(CLK_INFRA_133M_DBG_ACKM, "infra_hf_133m_dbg_ackm", "sysaxi_sel", 20,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA1(CLK_INFRA_66M_AP_DMA_BCK, "infra_66m_ap_dma_bck", "sysaxi_sel", 21),
+	GATE_INFRA1(CLK_INFRA_66M_SEJ_BCK, "infra_hf_66m_sej_bck", "sysaxi_sel", 29),
+	GATE_INFRA1(CLK_INFRA_PRE_CK_SEJ_F13M, "infra_pre_ck_sej_f13m", "csw_infra_f26m_sel", 30),
+	/* INFRA2 */
+	GATE_INFRA2(CLK_INFRA_26M_THERM_SYSTEM, "infra_hf_26m_therm_system", "csw_infra_f26m_sel",
+		    0),
+	GATE_INFRA2(CLK_INFRA_I2C_BCK, "infra_i2c_bck", "i2c_sel", 1),
+	GATE_INFRA2(CLK_INFRA_52M_UART0_CK, "infra_f_52m_uart0", "infra_mux_uart0_sel", 3),
+	GATE_INFRA2(CLK_INFRA_52M_UART1_CK, "infra_f_52m_uart1", "infra_mux_uart1_sel", 4),
+	GATE_INFRA2(CLK_INFRA_52M_UART2_CK, "infra_f_52m_uart2", "infra_mux_uart2_sel", 5),
+	GATE_INFRA2(CLK_INFRA_NFI, "infra_f_fnfi", "nfi1x_sel", 9),
+	GATE_INFRA2(CLK_INFRA_SPINFI, "infra_f_fspinfi", "spinfi_sel", 10),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_NFI_HCK, "infra_hf_66m_nfi_hck", "sysaxi_sel", 11,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2_FLAGS(CLK_INFRA_104M_SPI0, "infra_hf_104m_spi0", "infra_mux_spi0_sel", 12,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_104M_SPI1, "infra_hf_104m_spi1", "infra_mux_spi1_sel", 13),
+	GATE_INFRA2(CLK_INFRA_104M_SPI2_BCK, "infra_hf_104m_spi2_bck", "infra_mux_spi2_sel", 14),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_SPI0_HCK, "infra_hf_66m_spi0_hck", "sysaxi_sel", 15,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_66M_SPI1_HCK, "infra_hf_66m_spi1_hck", "sysaxi_sel", 16),
+	GATE_INFRA2(CLK_INFRA_66M_SPI2_HCK, "infra_hf_66m_spi2_hck", "sysaxi_sel", 17),
+	GATE_INFRA2(CLK_INFRA_66M_FLASHIF_AXI, "infra_hf_66m_flashif_axi", "sysaxi_sel", 18),
+	GATE_INFRA2_FLAGS(CLK_INFRA_RTC, "infra_f_frtc", "top_rtc_32k", 19, CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_26M_ADC_BCK, "infra_f_26m_adc_bck", "csw_infra_f26m_sel", 20),
+	GATE_INFRA2(CLK_INFRA_RC_ADC, "infra_f_frc_adc", "infra_f_26m_adc_bck", 21),
+	GATE_INFRA2(CLK_INFRA_MSDC400, "infra_f_fmsdc400", "emmc_400m_sel", 22),
+	GATE_INFRA2(CLK_INFRA_MSDC2_HCK, "infra_f_fmsdc2_hck", "emmc_250m_sel", 23),
+	GATE_INFRA2(CLK_INFRA_133M_MSDC_0_HCK, "infra_hf_133m_msdc_0_hck", "sysaxi_sel", 24),
+	GATE_INFRA2(CLK_INFRA_66M_MSDC_0_HCK, "infra_66m_msdc_0_hck", "sysaxi_sel", 25),
+	GATE_INFRA2(CLK_INFRA_133M_CPUM_BCK, "infra_hf_133m_cpum_bck", "sysaxi_sel", 26),
+	GATE_INFRA2(CLK_INFRA_BIST2FPC, "infra_hf_fbist2fpc", "nfi1x_sel", 27),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_MCK_CK_P1, "infra_hf_i2c_x16w_mck_ck_p1", "sysaxi_sel", 29),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_PCK_CK_P1, "infra_hf_i2c_x16w_pck_ck_p1", "sysaxi_sel", 31),
+	/* INFRA3 */
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK, "infra_133m_usb_hck", "sysaxi_sel", 0),
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK_CK_P1, "infra_133m_usb_hck_ck_p1", "sysaxi_sel", 1),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK, "infra_66m_usb_hck", "sysaxi_sel", 2),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK_CK_P1, "infra_66m_usb_hck_ck_p1", "sysaxi_sel", 3),
+	GATE_INFRA3(CLK_INFRA_USB_SYS, "infra_usb_sys", "usb_sys_sel", 4),
+	GATE_INFRA3(CLK_INFRA_USB_SYS_CK_P1, "infra_usb_sys_ck_p1", "usb_sys_p1_sel", 5),
+	GATE_INFRA3(CLK_INFRA_USB_REF, "infra_usb_ref", "top_xtal", 6),
+	GATE_INFRA3(CLK_INFRA_USB_CK_P1, "infra_usb_ck_p1", "top_xtal", 7),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT, "infra_usb_frmcnt", "usb_frmcnt_sel", 8,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT_CK_P1, "infra_usb_frmcnt_ck_p1", "usb_frmcnt_p1_sel",
+			  9, CLK_IS_CRITICAL),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE, "infra_usb_pipe", "sspxtp_sel", 10),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE_CK_P1, "infra_usb_pipe_ck_p1", "usb_phy_sel", 11),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI, "infra_usb_utmi", "top_xtal", 12),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI_CK_P1, "infra_usb_utmi_ck_p1", "top_xtal", 13),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI, "infra_usb_xhci", "usb_xhci_sel", 14),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI_CK_P1, "infra_usb_xhci_ck_p1", "usb_xhci_p1_sel", 15),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P0, "infra_pcie_gfmux_tl_ck_p0",
+		    "infra_pcie_gfmux_tl_o_p0_sel", 20),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P1, "infra_pcie_gfmux_tl_ck_p1",
+		    "infra_pcie_gfmux_tl_o_p1_sel", 21),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P2, "infra_pcie_gfmux_tl_ck_p2",
+		    "infra_pcie_gfmux_tl_o_p2_sel", 22),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P3, "infra_pcie_gfmux_tl_ck_p3",
+		    "infra_pcie_gfmux_tl_o_p3_sel", 23),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P0, "infra_pcie_pipe_ck_p0", "top_xtal", 24),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P1, "infra_pcie_pipe_ck_p1", "top_xtal", 25),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P2, "infra_pcie_pipe_ck_p2", "top_xtal", 26),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P3, "infra_pcie_pipe_ck_p3", "top_xtal", 27),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P0, "infra_133m_pcie_ck_p0", "sysaxi_sel", 28),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P1, "infra_133m_pcie_ck_p1", "sysaxi_sel", 29),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P2, "infra_133m_pcie_ck_p2", "sysaxi_sel", 30),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P3, "infra_133m_pcie_ck_p3", "sysaxi_sel", 31),
+};
+
+static const struct mtk_clk_desc infra_desc = {
+	.clks = infra_clks,
+	.num_clks = ARRAY_SIZE(infra_clks),
+	.mux_clks = infra_muxes,
+	.num_mux_clks = ARRAY_SIZE(infra_muxes),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const struct of_device_id of_match_clk_mt7988_infracfg[] = {
+	{ .compatible = "mediatek,mt7988-infracfg", .data = &infra_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_infracfg);
+
+static struct platform_driver clk_mt7988_infracfg_drv = {
+	.driver = {
+		.name = "clk-mt7988-infracfg",
+		.of_match_table = of_match_clk_mt7988_infracfg,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_infracfg_drv);
diff --git a/drivers/clk/mediatek/clk-mt7988-topckgen.c b/drivers/clk/mediatek/clk-mt7988-topckgen.c
new file mode 100644
index 0000000000000..760f8e0d2f26a
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-topckgen.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+	FIXED_CLK(CLK_TOP_XTAL, "top_xtal", "clkxtal", 40000000),
+};
+
+static const struct mtk_fixed_factor top_divs[] = {
+	FACTOR(CLK_TOP_XTAL_D2, "top_xtal_d2", "top_xtal", 1, 2),
+	FACTOR(CLK_TOP_RTC_32K, "top_rtc_32k", "top_xtal", 1, 1250),
+	FACTOR(CLK_TOP_RTC_32P7K, "top_rtc_32p7k", "top_xtal", 1, 1220),
+	FACTOR(CLK_TOP_MPLL_D2, "mpll_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D3_D2, "mpll_d3_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D4, "mpll_d4", "mpll", 1, 4),
+	FACTOR(CLK_TOP_MPLL_D8, "mpll_d8", "mpll", 1, 8),
+	FACTOR(CLK_TOP_MPLL_D8_D2, "mpll_d8_d2", "mpll", 1, 16),
+	FACTOR(CLK_TOP_MMPLL_D2, "mmpll_d2", "mmpll", 1, 2),
+	FACTOR(CLK_TOP_MMPLL_D3_D5, "mmpll_d3_d5", "mmpll", 1, 15),
+	FACTOR(CLK_TOP_MMPLL_D4, "mmpll_d4", "mmpll", 1, 4),
+	FACTOR(CLK_TOP_MMPLL_D6_D2, "mmpll_d6_d2", "mmpll", 1, 12),
+	FACTOR(CLK_TOP_MMPLL_D8, "mmpll_d8", "mmpll", 1, 8),
+	FACTOR(CLK_TOP_APLL2_D4, "apll2_d4", "apll2", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D4, "net1pll_d4", "net1pll", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D5, "net1pll_d5", "net1pll", 1, 5),
+	FACTOR(CLK_TOP_NET1PLL_D5_D2, "net1pll_d5_d2", "net1pll", 1, 10),
+	FACTOR(CLK_TOP_NET1PLL_D5_D4, "net1pll_d5_d4", "net1pll", 1, 20),
+	FACTOR(CLK_TOP_NET1PLL_D8, "net1pll_d8", "net1pll", 1, 8),
+	FACTOR(CLK_TOP_NET1PLL_D8_D2, "net1pll_d8_d2", "net1pll", 1, 16),
+	FACTOR(CLK_TOP_NET1PLL_D8_D4, "net1pll_d8_d4", "net1pll", 1, 32),
+	FACTOR(CLK_TOP_NET1PLL_D8_D8, "net1pll_d8_d8", "net1pll", 1, 64),
+	FACTOR(CLK_TOP_NET1PLL_D8_D16, "net1pll_d8_d16", "net1pll", 1, 128),
+	FACTOR(CLK_TOP_NET2PLL_D2, "net2pll_d2", "net2pll", 1, 2),
+	FACTOR(CLK_TOP_NET2PLL_D4, "net2pll_d4", "net2pll", 1, 4),
+	FACTOR(CLK_TOP_NET2PLL_D4_D4, "net2pll_d4_d4", "net2pll", 1, 16),
+	FACTOR(CLK_TOP_NET2PLL_D4_D8, "net2pll_d4_d8", "net2pll", 1, 32),
+	FACTOR(CLK_TOP_NET2PLL_D6, "net2pll_d6", "net2pll", 1, 6),
+	FACTOR(CLK_TOP_NET2PLL_D8, "net2pll_d8", "net2pll", 1, 8),
+};
+
+static const char *const netsys_parents[] = { "top_xtal", "net2pll_d2", "mmpll_d2" };
+static const char *const netsys_500m_parents[] = { "top_xtal", "net1pll_d5", "net1pll_d5_d2" };
+static const char *const netsys_2x_parents[] = { "top_xtal", "net2pll", "mmpll" };
+static const char *const netsys_gsw_parents[] = { "top_xtal", "net1pll_d4", "net1pll_d5" };
+static const char *const eth_gmii_parents[] = { "top_xtal", "net1pll_d5_d4" };
+static const char *const netsys_mcu_parents[] = { "top_xtal",	"net2pll",    "mmpll",
+						  "net1pll_d4", "net1pll_d5", "mpll" };
+static const char *const eip197_parents[] = { "top_xtal", "netsyspll",	"net2pll",
+					      "mmpll",	  "net1pll_d4", "net1pll_d5" };
+static const char *const axi_infra_parents[] = { "top_xtal", "net1pll_d8_d2" };
+static const char *const uart_parents[] = { "top_xtal", "mpll_d8", "mpll_d8_d2" };
+static const char *const emmc_250m_parents[] = { "top_xtal", "net1pll_d5_d2", "mmpll_d4" };
+static const char *const emmc_400m_parents[] = { "top_xtal", "msdcpll",	 "mmpll_d2",
+						 "mpll_d2",  "mmpll_d4", "net1pll_d8_d2" };
+static const char *const spi_parents[] = { "top_xtal",	    "mpll_d2",	    "mmpll_d4",
+					   "net1pll_d8_d2", "net2pll_d6",   "net1pll_d5_d4",
+					   "mpll_d4",	    "net1pll_d8_d4" };
+static const char *const nfi1x_parents[] = { "top_xtal", "mmpll_d4", "net1pll_d8_d2", "net2pll_d6",
+					     "mpll_d4",	 "mmpll_d8", "net1pll_d8_d4", "mpll_d8" };
+static const char *const spinfi_parents[] = { "top_xtal_d2", "top_xtal", "net1pll_d5_d4",
+					      "mpll_d4",     "mmpll_d8", "net1pll_d8_d4",
+					      "mmpll_d6_d2", "mpll_d8" };
+static const char *const pwm_parents[] = { "top_xtal", "net1pll_d8_d2", "net1pll_d5_d4",
+					   "mpll_d4",  "mpll_d8_d2",	"top_rtc_32k" };
+static const char *const i2c_parents[] = { "top_xtal", "net1pll_d5_d4", "mpll_d4",
+					   "net1pll_d8_d4" };
+static const char *const pcie_mbist_250m_parents[] = { "top_xtal", "net1pll_d5_d2" };
+static const char *const pextp_tl_ck_parents[] = { "top_xtal", "net2pll_d6", "mmpll_d8",
+						   "mpll_d8_d2", "top_rtc_32k" };
+static const char *const usb_frmcnt_parents[] = { "top_xtal", "mmpll_d3_d5" };
+static const char *const aud_parents[] = { "top_xtal", "apll2" };
+static const char *const a1sys_parents[] = { "top_xtal", "apll2_d4" };
+static const char *const aud_l_parents[] = { "top_xtal", "apll2", "mpll_d8_d2" };
+static const char *const sspxtp_parents[] = { "top_xtal_d2", "mpll_d8_d2" };
+static const char *const usxgmii_sbus_0_parents[] = { "top_xtal", "net1pll_d8_d4" };
+static const char *const sgm_0_parents[] = { "top_xtal", "sgmpll" };
+static const char *const sysapb_parents[] = { "top_xtal", "mpll_d3_d2" };
+static const char *const eth_refck_50m_parents[] = { "top_xtal", "net2pll_d4_d4" };
+static const char *const eth_sys_200m_parents[] = { "top_xtal", "net2pll_d4" };
+static const char *const eth_xgmii_parents[] = { "top_xtal_d2", "net1pll_d8_d8", "net1pll_d8_d16" };
+static const char *const bus_tops_parents[] = { "top_xtal", "net1pll_d5", "net2pll_d2" };
+static const char *const npu_tops_parents[] = { "top_xtal", "net2pll" };
+static const char *const dramc_md32_parents[] = { "top_xtal", "mpll_d2", "wedmcupll" };
+static const char *const da_xtp_glb_p0_parents[] = { "top_xtal", "net2pll_d8" };
+static const char *const mcusys_backup_625m_parents[] = { "top_xtal", "net1pll_d4" };
+static const char *const macsec_parents[] = { "top_xtal", "sgmpll", "net1pll_d8" };
+static const char *const netsys_tops_400m_parents[] = { "top_xtal", "net2pll_d2" };
+static const char *const eth_mii_parents[] = { "top_xtal_d2", "net2pll_d4_d8" };
+
+static const struct mtk_mux top_muxes[] = {
+	/* CLK_CFG_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SEL, "netsys_sel", netsys_parents, 0x000, 0x004, 0x008,
+			     0, 2, 7, 0x1c0, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_500M_SEL, "netsys_500m_sel", netsys_500m_parents, 0x000,
+			     0x004, 0x008, 8, 2, 15, 0x1C0, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_2X_SEL, "netsys_2x_sel", netsys_2x_parents, 0x000,
+			     0x004, 0x008, 16, 2, 23, 0x1C0, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_GSW_SEL, "netsys_gsw_sel", netsys_gsw_parents, 0x000,
+			     0x004, 0x008, 24, 2, 31, 0x1C0, 3),
+	/* CLK_CFG_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_GMII_SEL, "eth_gmii_sel", eth_gmii_parents, 0x010, 0x014,
+			     0x018, 0, 1, 7, 0x1C0, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_MCU_SEL, "netsys_mcu_sel", netsys_mcu_parents, 0x010,
+			     0x014, 0x018, 8, 3, 15, 0x1C0, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PAO_2X_SEL, "netsys_pao_2x_sel", netsys_mcu_parents,
+			     0x010, 0x014, 0x018, 16, 3, 23, 0x1C0, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EIP197_SEL, "eip197_sel", eip197_parents, 0x010, 0x014, 0x018,
+			     24, 3, 31, 0x1c0, 7),
+	/* CLK_CFG_2 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_AXI_INFRA_SEL, "axi_infra_sel", axi_infra_parents, 0x020,
+				   0x024, 0x028, 0, 1, 7, 0x1C0, 8, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_UART_SEL, "uart_sel", uart_parents, 0x020, 0x024, 0x028, 8, 2,
+			     15, 0x1c0, 9),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_250M_SEL, "emmc_250m_sel", emmc_250m_parents, 0x020,
+			     0x024, 0x028, 16, 2, 23, 0x1C0, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_400M_SEL, "emmc_400m_sel", emmc_400m_parents, 0x020,
+			     0x024, 0x028, 24, 3, 31, 0x1C0, 11),
+	/* CLK_CFG_3 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPI_SEL, "spi_sel", spi_parents, 0x030, 0x034, 0x038, 0, 3, 7,
+			     0x1c0, 12),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPIM_MST_SEL, "spim_mst_sel", spi_parents, 0x030, 0x034, 0x038,
+			     8, 3, 15, 0x1c0, 13),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NFI1X_SEL, "nfi1x_sel", nfi1x_parents, 0x030, 0x034, 0x038, 16,
+			     3, 23, 0x1c0, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPINFI_SEL, "spinfi_sel", spinfi_parents, 0x030, 0x034, 0x038,
+			     24, 3, 31, 0x1c0, 15),
+	/* CLK_CFG_4 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PWM_SEL, "pwm_sel", pwm_parents, 0x040, 0x044, 0x048, 0, 3, 7,
+			     0x1c0, 16),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_I2C_SEL, "i2c_sel", i2c_parents, 0x040, 0x044, 0x048, 8, 2, 15,
+			     0x1c0, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PCIE_MBIST_250M_SEL, "pcie_mbist_250m_sel",
+			     pcie_mbist_250m_parents, 0x040, 0x044, 0x048, 16, 1, 23, 0x1C0, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_SEL, "pextp_tl_sel", pextp_tl_ck_parents, 0x040,
+			     0x044, 0x048, 24, 3, 31, 0x1C0, 19),
+	/* CLK_CFG_5 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P1_SEL, "pextp_tl_p1_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 0, 3, 7, 0x1C0, 20),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P2_SEL, "pextp_tl_p2_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 8, 3, 15, 0x1C0, 21),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P3_SEL, "pextp_tl_p3_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 16, 3, 23, 0x1C0, 22),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_SEL, "usb_sys_sel", eth_gmii_parents, 0x050, 0x054,
+			     0x058, 24, 1, 31, 0x1C0, 23),
+	/* CLK_CFG_6 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_P1_SEL, "usb_sys_p1_sel", eth_gmii_parents, 0x060,
+			     0x064, 0x068, 0, 1, 7, 0x1C0, 24),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_SEL, "usb_xhci_sel", eth_gmii_parents, 0x060, 0x064,
+			     0x068, 8, 1, 15, 0x1C0, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_P1_SEL, "usb_xhci_p1_sel", eth_gmii_parents, 0x060,
+			     0x064, 0x068, 16, 1, 23, 0x1C0, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_SEL, "usb_frmcnt_sel", usb_frmcnt_parents, 0x060,
+			     0x064, 0x068, 24, 1, 31, 0x1C0, 27),
+	/* CLK_CFG_7 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_P1_SEL, "usb_frmcnt_p1_sel", usb_frmcnt_parents,
+			     0x070, 0x074, 0x078, 0, 1, 7, 0x1C0, 28),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_SEL, "aud_sel", aud_parents, 0x070, 0x074, 0x078, 8, 1, 15,
+			     0x1c0, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A1SYS_SEL, "a1sys_sel", a1sys_parents, 0x070, 0x074, 0x078, 16,
+			     1, 23, 0x1c0, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_L_SEL, "aud_l_sel", aud_l_parents, 0x070, 0x074, 0x078, 24,
+			     2, 31, 0x1c4, 0),
+	/* CLK_CFG_8 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A_TUNER_SEL, "a_tuner_sel", a1sys_parents, 0x080, 0x084, 0x088,
+			     0, 1, 7, 0x1c4, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SSPXTP_SEL, "sspxtp_sel", sspxtp_parents, 0x080, 0x084, 0x088,
+			     8, 1, 15, 0x1c4, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_PHY_SEL, "usb_phy_sel", sspxtp_parents, 0x080, 0x084,
+			     0x088, 16, 1, 23, 0x1c4, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_0_SEL, "usxgmii_sbus_0_sel",
+			     usxgmii_sbus_0_parents, 0x080, 0x084, 0x088, 24, 1, 31, 0x1C4, 4),
+	/* CLK_CFG_9 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_1_SEL, "usxgmii_sbus_1_sel",
+			     usxgmii_sbus_0_parents, 0x090, 0x094, 0x098, 0, 1, 7, 0x1C4, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_0_SEL, "sgm_0_sel", sgm_0_parents, 0x090, 0x094, 0x098, 8,
+			     1, 15, 0x1c4, 6),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_0_SEL, "sgm_sbus_0_sel", usxgmii_sbus_0_parents,
+				   0x090, 0x094, 0x098, 16, 1, 23, 0x1C4, 7, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_1_SEL, "sgm_1_sel", sgm_0_parents, 0x090, 0x094, 0x098, 24,
+			     1, 31, 0x1c4, 8),
+	/* CLK_CFG_10 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_1_SEL, "sgm_sbus_1_sel", usxgmii_sbus_0_parents,
+				   0x0a0, 0x0a4, 0x0a8, 0, 1, 7, 0x1C4, 9, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_0_XTAL_SEL, "xfi_phy_0_xtal_sel", sspxtp_parents,
+			     0x0a0, 0x0a4, 0x0a8, 8, 1, 15, 0x1C4, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_1_XTAL_SEL, "xfi_phy_1_xtal_sel", sspxtp_parents,
+			     0x0a0, 0x0a4, 0x0a8, 16, 1, 23, 0x1C4, 11),
+	/* CLK_CFG_11 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAXI_SEL, "sysaxi_sel", axi_infra_parents, 0x0a0,
+				   0x0a4, 0x0a8, 24, 1, 31, 0x1C4, 12, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAPB_SEL, "sysapb_sel", sysapb_parents, 0x0b0, 0x0b4,
+				   0x0b8, 0, 1, 7, 0x1c4, 13, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_REFCK_50M_SEL, "eth_refck_50m_sel", eth_refck_50m_parents,
+			     0x0b0, 0x0b4, 0x0b8, 8, 1, 15, 0x1C4, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_200M_SEL, "eth_sys_200m_sel", eth_sys_200m_parents,
+			     0x0b0, 0x0b4, 0x0b8, 16, 1, 23, 0x1C4, 15),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_SEL, "eth_sys_sel", pcie_mbist_250m_parents, 0x0b0,
+			     0x0b4, 0x0b8, 24, 1, 31, 0x1C4, 16),
+	/* CLK_CFG_12 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_XGMII_SEL, "eth_xgmii_sel", eth_xgmii_parents, 0x0c0,
+			     0x0c4, 0x0c8, 0, 2, 7, 0x1C4, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_BUS_TOPS_SEL, "bus_tops_sel", bus_tops_parents, 0x0c0, 0x0c4,
+			     0x0c8, 8, 2, 15, 0x1C4, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_TOPS_SEL, "npu_tops_sel", npu_tops_parents, 0x0c0, 0x0c4,
+			     0x0c8, 16, 1, 23, 0x1C4, 19),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_SEL, "dramc_sel", sspxtp_parents, 0x0c0, 0x0c4,
+				   0x0c8, 24, 1, 31, 0x1C4, 20, CLK_IS_CRITICAL),
+	/* CLK_CFG_13 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_MD32_SEL, "dramc_md32_sel", dramc_md32_parents,
+				   0x0d0, 0x0d4, 0x0d8, 0, 2, 7, 0x1C4, 21, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_INFRA_F26M_SEL, "csw_infra_f26m_sel", sspxtp_parents,
+				   0x0d0, 0x0d4, 0x0d8, 8, 1, 15, 0x1C4, 22, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P0_SEL, "pextp_p0_sel", sspxtp_parents, 0x0d0, 0x0d4,
+			     0x0d8, 16, 1, 23, 0x1C4, 23),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P1_SEL, "pextp_p1_sel", sspxtp_parents, 0x0d0, 0x0d4,
+			     0x0d8, 24, 1, 31, 0x1C4, 24),
+	/* CLK_CFG_14 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P2_SEL, "pextp_p2_sel", sspxtp_parents, 0x0e0, 0x0e4,
+			     0x0e8, 0, 1, 7, 0x1C4, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P3_SEL, "pextp_p3_sel", sspxtp_parents, 0x0e0, 0x0e4,
+			     0x0e8, 8, 1, 15, 0x1C4, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P0_SEL, "da_xtp_glb_p0_sel", da_xtp_glb_p0_parents,
+			     0x0e0, 0x0e4, 0x0e8, 16, 1, 23, 0x1C4, 27),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P1_SEL, "da_xtp_glb_p1_sel", da_xtp_glb_p0_parents,
+			     0x0e0, 0x0e4, 0x0e8, 24, 1, 31, 0x1C4, 28),
+	/* CLK_CFG_15 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P2_SEL, "da_xtp_glb_p2_sel", da_xtp_glb_p0_parents,
+			     0x0f0, 0x0f4, 0x0f8, 0, 1, 7, 0x1C4, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P3_SEL, "da_xtp_glb_p3_sel", da_xtp_glb_p0_parents,
+			     0x0f0, 0x0f4, 0x0f8, 8, 1, 15, 0x1C4, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_CKM_SEL, "ckm_sel", sspxtp_parents, 0x0F0, 0x0f4, 0x0f8, 16, 1,
+			     23, 0x1c8, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_SEL, "da_sel", sspxtp_parents, 0x0f0, 0x0f4, 0x0f8, 24, 1,
+			     31, 0x1C8, 1),
+	/* CLK_CFG_16 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_SEL, "pextp_sel", sspxtp_parents, 0x0100, 0x104, 0x108,
+			     0, 1, 7, 0x1c8, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_TOPS_P2_26M_SEL, "tops_p2_26m_sel", sspxtp_parents, 0x0100,
+			     0x104, 0x108, 8, 1, 15, 0x1C8, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MCUSYS_BACKUP_625M_SEL, "mcusys_backup_625m_sel",
+			     mcusys_backup_625m_parents, 0x0100, 0x104, 0x108, 16, 1, 23, 0x1C8, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SYNC_250M_SEL, "netsys_sync_250m_sel",
+			     pcie_mbist_250m_parents, 0x0100, 0x104, 0x108, 24, 1, 31, 0x1c8, 5),
+	/* CLK_CFG_17 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MACSEC_SEL, "macsec_sel", macsec_parents, 0x0110, 0x114, 0x118,
+			     0, 2, 7, 0x1c8, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_TOPS_400M_SEL, "netsys_tops_400m_sel",
+			     netsys_tops_400m_parents, 0x0110, 0x114, 0x118, 8, 1, 15, 0x1c8, 7),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PPEFB_250M_SEL, "netsys_ppefb_250m_sel",
+			     pcie_mbist_250m_parents, 0x0110, 0x114, 0x118, 16, 1, 23, 0x1c8, 8),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_WARP_SEL, "netsys_warp_sel", netsys_parents, 0x0110,
+			     0x114, 0x118, 24, 2, 31, 0x1C8, 9),
+	/* CLK_CFG_18 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_MII_SEL, "eth_mii_sel", eth_mii_parents, 0x0120, 0x124,
+			     0x128, 0, 1, 7, 0x1c8, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_SEL, "ck_npu_sel", netsys_2x_parents, 0x0120, 0x124, 0x128,
+			     8, 2, 15, 0x1c8, 11),
+};
+
+static const struct mtk_composite top_aud_divs[] = {
+	DIV_GATE(CLK_TOP_AUD_I2S_M, "aud_i2s_m", "aud_sel", 0x0420, 0, 0x0420, 8, 8),
+};
+
+static const struct mtk_clk_desc topck_desc = {
+	.fixed_clks = top_fixed_clks,
+	.num_fixed_clks = ARRAY_SIZE(top_fixed_clks),
+	.factor_clks = top_divs,
+	.num_factor_clks = ARRAY_SIZE(top_divs),
+	.mux_clks = top_muxes,
+	.num_mux_clks = ARRAY_SIZE(top_muxes),
+	.composite_clks = top_aud_divs,
+	.num_composite_clks = ARRAY_SIZE(top_aud_divs),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const char *const mcu_bus_div_parents[] = { "top_xtal", "ccipll2_b", "net1pll_d4" };
+
+static const char *const mcu_arm_div_parents[] = { "top_xtal", "arm_b", "net1pll_d4" };
+
+static struct mtk_composite mcu_muxes[] = {
+	/* bus_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_BUS_DIV_SEL, "mcu_bus_div_sel", mcu_bus_div_parents, 0x7C0, 9, 2, -1,
+		       CLK_IS_CRITICAL),
+	/* mp2_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_ARM_DIV_SEL, "mcu_arm_div_sel", mcu_arm_div_parents, 0x7A8, 9, 2, -1,
+		       CLK_IS_CRITICAL),
+};
+
+static const struct mtk_clk_desc mcusys_desc = {
+	.composite_clks = mcu_muxes,
+	.num_composite_clks = ARRAY_SIZE(mcu_muxes),
+};
+
+static const struct of_device_id of_match_clk_mt7988_topckgen[] = {
+	{ .compatible = "mediatek,mt7988-topckgen", .data = &topck_desc },
+	{ .compatible = "mediatek,mt7988-mcusys", .data = &mcusys_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_topckgen);
+
+static struct platform_driver clk_mt7988_topckgen_drv = {
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+	.driver = {
+		.name = "clk-mt7988-topckgen",
+		.of_match_table = of_match_clk_mt7988_topckgen,
+	},
+};
+module_platform_driver(clk_mt7988_topckgen_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-xfipll.c b/drivers/clk/mediatek/clk-mt7988-xfipll.c
new file mode 100644
index 0000000000000..1404d1f17fc8b
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-xfipll.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+/* Register to control USXGMII XFI PLL analog */
+#define XFI_PLL_ANA_GLB8		0x108
+#define RG_XFI_PLL_ANA_SWWA		0x02283248
+
+static const struct mtk_gate_regs xfipll_cg_regs = {
+	.set_ofs = 0x8,
+	.clr_ofs = 0x8,
+	.sta_ofs = 0x8,
+};
+
+#define GATE_XFIPLL(_id, _name, _parent, _shift)                                           \
+	{                                                                                  \
+		.id = _id, .name = _name, .parent_name = _parent, .regs = &xfipll_cg_regs, \
+		.shift = _shift, .ops = &mtk_clk_gate_ops_no_setclr_inv,                   \
+	}
+
+static const struct mtk_fixed_factor xfipll_divs[] = {
+	FACTOR(CLK_XFIPLL_PLL, "xfipll_pll", "top_xtal", 125, 32),
+};
+
+static const struct mtk_gate xfipll_clks[] = {
+	GATE_XFIPLL(CLK_XFIPLL_PLL_EN, "xfipll_pll_en", "xfipll_pll", 31),
+};
+
+static const struct mtk_clk_desc xfipll_desc = {
+	.clks = xfipll_clks,
+	.num_clks = ARRAY_SIZE(xfipll_clks),
+	.factor_clks = xfipll_divs,
+	.num_factor_clks = ARRAY_SIZE(xfipll_divs),
+};
+
+static int clk_mt7988_xfipll_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	void __iomem *base = of_iomap(node, 0);
+
+	if (!base)
+		return -ENOMEM;
+
+	/* Apply software workaround for USXGMII PLL TCL issue */
+	writel(RG_XFI_PLL_ANA_SWWA, base + XFI_PLL_ANA_GLB8);
+	iounmap(base);
+
+	return mtk_clk_simple_probe(pdev);
+};
+
+static const struct of_device_id of_match_clk_mt7988_xfipll[] = {
+	{ .compatible = "mediatek,mt7988-xfi-pll", .data = &xfipll_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_xfipll);
+
+static struct platform_driver clk_mt7988_xfipll_drv = {
+	.driver = {
+		.name = "clk-mt7988-xfipll",
+		.of_match_table = of_match_clk_mt7988_xfipll,
+	},
+	.probe = clk_mt7988_xfipll_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_xfipll_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 XFI PLL clock driver");
+MODULE_LICENSE("GPL");
-- 
2.43.0


From linus.walleij at linaro.org  Sat Dec  9 14:01:27 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 09 Dec 2023 23:01:27 +0100
Subject: [PATCH] ASoC: wm1250-ev1: Fix uninitialized ret
Message-ID: <20231209-descriptors-sound-wlf-v1-1-5b885ce43ae1@linaro.org>

The GPIO descriptor conversion patch left an unitialized ret behind
by mistake, fix it by getting rid of the variable altogether.

Fixes: 10a366f36e2a ("ASoC: wm1250-ev1: Convert to GPIO descriptors")
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312090953.DiUo3mue-lkp at intel.com/
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 sound/soc/codecs/wm1250-ev1.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/codecs/wm1250-ev1.c b/sound/soc/codecs/wm1250-ev1.c
index a2a8b2a4b19b..9fa6df48799b 100644
--- a/sound/soc/codecs/wm1250-ev1.c
+++ b/sound/soc/codecs/wm1250-ev1.c
@@ -129,7 +129,6 @@ static int wm1250_ev1_pdata(struct i2c_client *i2c)
 {
 	struct wm1250_ev1_pdata *pdata = dev_get_platdata(&i2c->dev);
 	struct wm1250_priv *wm1250;
-	int ret;
 
 	if (!pdata)
 		return 0;
@@ -165,7 +164,7 @@ static int wm1250_ev1_pdata(struct i2c_client *i2c)
 
 	dev_set_drvdata(&i2c->dev, wm1250);
 
-	return ret;
+	return 0;
 }
 
 static int wm1250_ev1_probe(struct i2c_client *i2c)

---
base-commit: e0fa2154a7f46ca49105025d118261d34f7dfa7e
change-id: 20231205-descriptors-sound-wlf-e6caec3cc642

Best regards,
-- 
Linus Walleij <linus.walleij at linaro.org>



From peter.griffin at linaro.org  Sat Dec  9 14:04:01 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat, 9 Dec 2023 22:04:01 +0000
Subject: [PATCH v5 19/20] arm64: dts: exynos: google: Add initial
 Oriole/pixel 6 board support
In-Reply-To: <CAPLW+4mOmQM+Hy-kUKn9onU25-ycgj4CWfAK+-vZVH+yw=FhtQ@mail.gmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-20-peter.griffin@linaro.org> <CAPLW+4mOmQM+Hy-kUKn9onU25-ycgj4CWfAK+-vZVH+yw=FhtQ@mail.gmail.com>
Message-ID: <CADrjBPqWimgbPUZoW1cTs0grL2Kv3rpNMhz=z-c+MUx6h6mTAQ@mail.gmail.com>

Hi Sam,

On Sat, 2 Dec 2023 at 02:28, Sam Protsenko <semen.protsenko at linaro.org> wrote:
>
> On Fri, Dec 1, 2023 at 10:11?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > Add initial board support for the Pixel 6 phone code named Oriole. This
> > has been tested with a minimal busybox initramfs and boots to a shell.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  arch/arm64/boot/dts/exynos/Makefile           |   2 +
> >  arch/arm64/boot/dts/exynos/google/Makefile    |   4 +
> >  .../boot/dts/exynos/google/gs101-oriole.dts   | 105 ++++++++++++++++++
> >  3 files changed, 111 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
> >  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> >
> > diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
> > index 6e4ba69268e5..44c24a8ad9e1 100644
> > --- a/arch/arm64/boot/dts/exynos/Makefile
> > +++ b/arch/arm64/boot/dts/exynos/Makefile
> > @@ -1,4 +1,6 @@
> >  # SPDX-License-Identifier: GPL-2.0
> > +subdir-y += google
> > +
> >  dtb-$(CONFIG_ARCH_EXYNOS) += \
> >         exynos5433-tm2.dtb              \
> >         exynos5433-tm2e.dtb             \
> > diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
> > new file mode 100644
> > index 000000000000..0a6d5e1fe4ee
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/google/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +dtb-$(CONFIG_ARCH_EXYNOS) += \
> > +       gs101-oriole.dtb \
> > diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> > new file mode 100644
> > index 000000000000..6abd00fa337e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> > @@ -0,0 +1,105 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Oriole Device Tree
> > + *
> > + * Copyright 2021-2023 Google,LLC
>
> Space after comma. Maybe also make this line consistent for all added
> files. Checking existing files, it's usually spelled "Copyright (C)
> <years>, Google LLC."

I've made it match the other files I've added in v6 (by removing the
,). There seems to be a lot of variation upstream as to whether a . is
used at the end or not so I've left that as it was.
>
> Btw, I forgot to mention in my review for PATCH #18: please double
> check the commit message, there are some issues with punctuation
> there.

Ok, I will check it.

>
> > + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/input/input.h>
> > +#include "gs101-pinctrl.h"
> > +#include "gs101.dtsi"
> > +
> > +/ {
> > +       model = "Oriole";
> > +       compatible = "google,gs101-oriole", "google,gs101";
> > +
> > +       aliases {
> > +               serial0 = &serial_0;
> > +       };
> > +
> > +       chosen {
> > +               /* Bootloader expects bootargs specified otherwise it crashes */
>
> Just wanted to say: I think you are doing a great job with this
> platform, and I can only imagine how hard it can be when you can't
> actually tinker with the bootloader source code. But I do appreciate
> that you was able to minimize stuff like earlycon, ect, etc :) And
> this one actually LGTM.
>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

Thanks, much appreciated!

regards,

Peter.


From thiago.bauermann at linaro.org  Sat Dec  9 14:28:21 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Sat, 09 Dec 2023 19:28:21 -0300
Subject: [PATCH v7 25/39] arm64/signal: Expose GCS state in signal frames
In-Reply-To: <20231122-arm64-gcs-v7-25-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-25-201c483bd775@kernel.org>
Message-ID: <87sf4bf1tm.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

> +static int preserve_gcs_context(struct gcs_context __user *ctx)
> +{
> +	int err = 0;
> +	u64 gcspr;
> +
> +	/*
> +	 * We will add a cap token to the frame, include it in the
> +	 * GCSPR_EL0 we report to support stack switching via
> +	 * sigreturn.
> +	 */
> +	gcs_preserve_current_state();
> +	gcspr = current->thread.gcspr_el0;
> +	if (task_gcs_el0_enabled(current))
> +		gcspr -= 8;
> +
> +	__put_user_error(GCS_MAGIC, &ctx->head.magic, err);
> +	__put_user_error(sizeof(*ctx), &ctx->head.size, err);
> +	__put_user_error(gcspr, &ctx->gcspr, err);
> +	__put_user_error(current->thread.gcs_el0_mode,
> +			 &ctx->features_enabled, err);

Other preserve_<foo>_context() functions zero the reserved fields in
ctx. I suggest doing the same here. It helps with backward
compatibility.

> +
> +	return err;
> +}


-- 
Thiago


From u.kleine-koenig at pengutronix.de  Sat Dec  9 15:00:46 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 10 Dec 2023 00:00:46 +0100
Subject: [PATCH 1/2] pwm: lpc18xx-sct: Don't modify the cached period of other PWM outputs
In-Reply-To: <cover.1702162780.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702162780.git.u.kleine-koenig@pengutronix.de>
Message-ID: <8adc3d93457eed7ee8a516210ec01e918f0bd8ec.1702162780.git.u.kleine-koenig@pengutronix.de>

Even though the hardware only supports a single period for all PWM
outputs, modifying the other (disabled) outputs's period is strange and
wrong. Only the pwm core is supposed to update these values.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-lpc18xx-sct.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
index b3d4a955aa31..fe891fa71a1d 100644
--- a/drivers/pwm/pwm-lpc18xx-sct.c
+++ b/drivers/pwm/pwm-lpc18xx-sct.c
@@ -194,7 +194,7 @@ static int lpc18xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 			      int duty_ns, int period_ns)
 {
 	struct lpc18xx_pwm_chip *lpc18xx_pwm = to_lpc18xx_pwm_chip(chip);
-	int requested_events, i;
+	int requested_events;
 
 	if (period_ns < lpc18xx_pwm->min_period_ns ||
 	    period_ns > lpc18xx_pwm->max_period_ns) {
@@ -223,8 +223,6 @@ static int lpc18xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	if ((requested_events <= 2 && lpc18xx_pwm->period_ns != period_ns) ||
 	    !lpc18xx_pwm->period_ns) {
 		lpc18xx_pwm->period_ns = period_ns;
-		for (i = 0; i < chip->npwm; i++)
-			pwm_set_period(&chip->pwms[i], period_ns);
 		lpc18xx_pwm_config_period(chip, period_ns);
 	}
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Sat Dec  9 15:00:45 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 10 Dec 2023 00:00:45 +0100
Subject: [PATCH 0/2] pwm: Drop two strange API functions
Message-ID: <cover.1702162780.git.u.kleine-koenig@pengutronix.de>

Hello,

while working on another change I noticed these two functions, found
them strange and no valid user. So this patch series drops them.

Best regards
Uwe

Uwe Kleine-K?nig (2):
  pwm: lpc18xx-sct: Don't modify the cached period of other PWM outputs
  pwm: Drop two unused API functions

 drivers/pwm/pwm-lpc18xx-sct.c |  4 +---
 include/linux/pwm.h           | 12 ------------
 2 files changed, 1 insertion(+), 15 deletions(-)

base-commit: bc63de6e6ba0b16652c5fb4b9c9916b9e7ca1f23
-- 
2.42.0



From colin.i.king at gmail.com  Sat Dec  9 15:12:40 2023
From: colin.i.king at gmail.com (Colin Ian King)
Date: Sat,  9 Dec 2023 23:12:40 +0000
Subject: [PATCH][next] iommu/apple-dart: Fix spelling mistake "grups" -> "groups"
Message-ID: <20231209231240.4056082-1-colin.i.king@gmail.com>

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

Signed-off-by: Colin Ian King <colin.i.king at gmail.com>
---
 drivers/iommu/apple-dart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c
index 7438e9c82ba9..497a516747bd 100644
--- a/drivers/iommu/apple-dart.c
+++ b/drivers/iommu/apple-dart.c
@@ -911,7 +911,7 @@ static struct iommu_group *apple_dart_device_group(struct device *dev)
 
 		ret = apple_dart_merge_master_cfg(group_master_cfg, cfg);
 		if (ret) {
-			dev_err(dev, "Failed to merge DART IOMMU grups.\n");
+			dev_err(dev, "Failed to merge DART IOMMU groups.\n");
 			iommu_group_put(group);
 			res = ERR_PTR(ret);
 			goto out;
-- 
2.39.2



From peter.griffin at linaro.org  Sat Dec  9 15:30:46 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:46 +0000
Subject: [PATCH v6 00/20]  Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board
Message-ID: <20231209233106.147416-1-peter.griffin@linaro.org>

Hi folks,

This series adds initial SoC support for the GS101 SoC and also initial board
support for Pixel 6 phone (Oriole).

Thankyou to everyone who has reviewed and tested the previous series. Your
time and effort doing so is much appreciated!

V6 incorporates the review feedback received so far, and is rebased onto
linux-next as per Krzysztof request to incorporate all his dt-binding changes
for exynos.

I'm really hoping V6 will be the last series, and we can get this series merged
this week so it will make it into v6.8 Linux release.

The main difference in v6 apart from the various nits and cosmetic changes is
I have dropped support for exynos selectable analog/digital filters. I will look
to progress that again after this initial series has been merged. I've also done
more clock name mangling as per Sam's request to shorten the clock names, and
fixed up various issues with clock parenting.

As this series spans multiple subsytems the expectation is that Krzysztof
will apply the whole series through the Samsung SoC tree. If the relevant
subsystem maintainers can give a acked-by or reviewed-by on the relevant
patches that would be most appreciated!

The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
(raven) phones. Currently DT is added for the gs101 SoC and Oriole.
As you can see from the patches the SoC is based on a Samsung Exynos SoC,
and therefore lots of the low level Exynos drivers and bindings can be
re-used.

The support added in this series consists of:
* cpus
* pinctrl
* CCF implementation of cmu_top, cmu_misc & cmu_apm
* watchdog
* USI uart
* gpio

This is enough to boot through to a busybox initramfs and shell using an
upstream kernel though :) More platform support will be added over the
following weeks and months.

For further information on how to build and flash the upstream kernel on your
Pixel 6, with a prebuilt busybox initramfs please refer to the script and
README.md here:

https://git.codelinaro.org/linaro/googlelt/pixelscripts

Note: Booting without a dtbo works with some versions of the bootloader
but crashes on others. Later versions aren't necessarily better. You can
get the bootloader version with `fastboot getvar version-bootloader`
Known good bootloader versions are: -
- slider-1.3-11000330
- slider-1.2-9152140
Known to crash without dtbo
- slider-1.3-10780582

kind regards,

Peter.

lore v5: https://lore.kernel.org/all/20231201160925.3136868-1-peter.griffin at linaro.org/T/
lore v4: https://lore.kernel.org/linux-arm-kernel/20231120212037.911774-1-peter.griffin at linaro.org/T/
pw   v3: https://patchwork.kernel.org/project/linux-samsung-soc/cover/20231011184823.443959-1-peter.griffin at linaro.org/
lore v2: https://lore.kernel.org/all/20231010224928.2296997-1-peter.griffin at linaro.org/
lore v1: https://lore.kernel.org/linux-arm-kernel/20231005155618.700312-1-peter.griffin at linaro.org/

Changes since v5:
 - Collect up Reviewed-by and Tested-by tags
 - clk-gs101: reorder cmu_top parents in register offset order (Peter)
 - clk-gs101: Review cmu_top and cmu_misc parents, fix a few typos
 - clk-gs101: Add more name mangling to shorten DT and Linux clock name strings (Sam)
 - pinctrl: samsung: Drop support for digital/analog selectable filters (Peter)
 - Fixup cmu_top yaml example and some nitpicks (Sam)
 - Fixup some spelling nitpicks in google.yaml (Sam)
 - samsung,pinctrl-wakeup-interrupt: drop second not required google,gs101-wakeup-eint compatible (Krzysztof)
 - exynos-usi.yaml: add google,gs101-usi to previous enum (Krzysztof)
 - s3c2410_wdt: move comment, double whitespace, add BIT macro (Sam)

Changes since v4:
 - clk-gs101: order cmu_top by register address, fix incorrect mux widths,
   add missing mux/div/gates (Andre)
 - google,gs101.h: add missing space in comment (Andre)
 - ckl-gs101:google,gs101.h add all remaining gates for cmu_misc and cmu_apm
 - update pmu dt labels (Krzysztof)
 - Remove uart16 rts/tx gpio definitions (Krzysztof)
 - Fixup various dts cosmetic nits (using consts, alignments,
   names) (Sam/Krzysztof)
 - Add more specific compatibles for arm cpu's and pmu (Sam)
 - Use address-cells 1 and ranges property for SoC addresses (Sam)
 - Encapsulate uart node in USI node (Sam)
 - Remove earlycon from bootargs
 - s3c2410_wdt: Reword QUIRK_HAS_DBGACK_BIT docs and add comment (Guenter)
 - s3c2410_wdt: Reorder DBGACK_MASK functionality first, gs101
   SoC second (Sam/Krzysztof)
 
Changes since v3:
 - Add reviewed-by and tested-by tags
 - google,gs101-clock.yaml: move Required to before Allof,
   enum for cmu*top/misc (Krzysztof)
 - samsung-wdt.yaml: stick to 80chars (Sam)
 - google.yaml - remove new line
 - samsung,pinctrl-wakeup-interrupt: sort alphabetically (RobH)
 - gs101-oriole.dts: update gpio-keys pinctrl-0 phandle for keys (Stephen)
 - samsung,exynos-sysreg.yaml - Alphabetical order (RobH)
 - pinctrl-exynos: update/move comments, slight cosmetic changes (Sam)
 - samsung_tty.c: update to generic drv_data name/macro (Arnd)
 - samsung_uart.yaml: make samsung,uart-fifosize required for gs101-uart (Arnd)
 - pinctrl-exynos: Remove eint irqs from alive pin controller node (Peter/Rob)
 - Fixup kernel test robot unused const variable warnings
 - clk-gs101: Update to mout_cmu_eh_bus to CLK_CON_MUX_MUX_CLKCMU_EH_BUS
   (Chanwoo)
 - clk-gs101: Update g3aa gout/dout/mout names to g3aa_g3aa for
   consistency (Chanwoo)
 - Remove .eint_gpio_init() cb on alive, alive_far, gsacore & gsactrl
   banks (Sam)
 - s3c2410_wdt: Drop windowed watchdog mode for now (Peter)
 - s3c2410_wdt: Separate gs101 SoC support from dbgack feature (Sam)
 - Move dts to arch/arm64/boot/dts/exynos/google directory (Krzysztof)

Changes since v2:
 - Fixup pinctrl at 174d0000: interrupts: [..] is too long DTC warning (Tudor)
 - Add missing windowed watchdog code (Guenter)
 - Fixup UART YAML bindings error (Krzysztof)
 - gs101.dtsi add missing serial_0 alias (me)
 - samsung_tty.c: fixup gs101_serial_drv_data so fifosize is obtained from DT
 
Changes since v1:
 - Remove irq/gs101.h and replace macros with irq numbers globally
 - exynos-pmu - keep alphabetical order
 - add cmu_apm to clock bindings documentation
 - sysreg bindings - remove superfluous `google,gs101-sysreg`
 - watchdog bindings - Alphanumerical order, update gs201 comment
 - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
 - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
 - samsung,pinctrl- add google,gs101-wakeup-eint compatible
 - clk-pll: fixup typos
 - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
 - clk-gs101: fix alphabetical order
 - clk-gs101: cmu_apm: fixup typo and missing empty entry
 - clk-gs101: cmu_misc: remove clocks that were being registerred twice
 - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON
   bitfield
 - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins
   as well
 - pinctrl: gs101: rename bank_type_6/7 structs to be more specific,
   split from filter
 - watchdog: s3c2410_wdt: remove dev_info prints
 - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node
   name, blank lines add SoC node, split dts and dtsi into separate patches,
   remove 'DVT' suffix
 - gs101-oriole.dtso: Remove overlay until board_id is documented properly
 - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
 - gpio-keys: update linux,code to use input-event-code macros
 - add dedicated gs101-uart compatible

Peter Griffin (19):
  dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
  dt-bindings: clock: Add Google gs101 clock management unit bindings
  dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
    compatibles to GS101
  dt-bindings: watchdog: Document Google gs101 watchdog bindings
  dt-bindings: arm: google: Add bindings for Google ARM platforms
  dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
  dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
  dt-bindings: serial: samsung: Add google-gs101-uart compatible
  dt-bindings: serial: samsung: Make samsung,uart-fifosize a required
    property
  clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
  clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm support
  pinctrl: samsung: Add gs101 SoC pinctrl configuration
  watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bit
  watchdog: s3c2410_wdt: Update QUIRK macros to use BIT macro
  watchdog: s3c2410_wdt: Add support for Google gs101 SoC
  tty: serial: samsung: Add gs101 compatible and common
    fifoszdt_serial_drv_data
  arm64: dts: exynos: google: Add initial Google gs101 SoC support
  arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
  MAINTAINERS: add entry for Google Tensor SoC

Tudor Ambarus (1):
  dt-bindings: soc: samsung: usi: add google,gs101-usi compatible

 .../devicetree/bindings/arm/google.yaml       |   53 +
 .../bindings/clock/google,gs101-clock.yaml    |  106 +
 .../samsung,pinctrl-wakeup-interrupt.yaml     |    1 +
 .../bindings/pinctrl/samsung,pinctrl.yaml     |    1 +
 .../bindings/serial/samsung_uart.yaml         |   11 +
 .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
 .../bindings/soc/samsung/exynos-usi.yaml      |    1 +
 .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
 .../bindings/watchdog/samsung-wdt.yaml        |    8 +-
 MAINTAINERS                                   |   10 +
 arch/arm64/boot/dts/exynos/Makefile           |    2 +
 arch/arm64/boot/dts/exynos/google/Makefile    |    4 +
 .../boot/dts/exynos/google/gs101-oriole.dts   |  105 +
 .../boot/dts/exynos/google/gs101-pinctrl.dtsi | 1249 ++++++++
 .../boot/dts/exynos/google/gs101-pinctrl.h    |   33 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  476 ++++
 drivers/clk/samsung/Makefile                  |    1 +
 drivers/clk/samsung/clk-gs101.c               | 2512 +++++++++++++++++
 drivers/clk/samsung/clk-pll.c                 |    6 +
 drivers/clk/samsung/clk-pll.h                 |    3 +
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  140 +
 drivers/pinctrl/samsung/pinctrl-exynos.c      |    2 +
 drivers/pinctrl/samsung/pinctrl-samsung.c     |    2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |    1 +
 drivers/tty/serial/samsung_tty.c              |   16 +
 drivers/watchdog/s3c2410_wdt.c                |   87 +-
 include/dt-bindings/clock/google,gs101.h      |  392 +++
 27 files changed, 5215 insertions(+), 15 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi
 create mode 100644 drivers/clk/samsung/clk-gs101.c
 create mode 100644 include/dt-bindings/clock/google,gs101.h

-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:47 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:47 +0000
Subject: [PATCH v6 01/20] dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-2-peter.griffin@linaro.org>

Add gs101-pmu compatible to the bindings documentation.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index 28e2cb50d85e..ce1bba980961 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -15,6 +15,7 @@ select:
     compatible:
       contains:
         enum:
+          - google,gs101-pmu
           - samsung,exynos3250-pmu
           - samsung,exynos4210-pmu
           - samsung,exynos4212-pmu
@@ -35,6 +36,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - google,gs101-pmu
               - samsung,exynos3250-pmu
               - samsung,exynos4210-pmu
               - samsung,exynos4212-pmu
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:48 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:48 +0000
Subject: [PATCH v6 02/20] dt-bindings: clock: Add Google gs101 clock management unit bindings
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-3-peter.griffin@linaro.org>

Provide dt-schema documentation for Google gs101 SoC clock controller.
Currently this adds support for cmu_top, cmu_misc and cmu_apm.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../bindings/clock/google,gs101-clock.yaml    | 106 +++++
 include/dt-bindings/clock/google,gs101.h      | 392 ++++++++++++++++++
 2 files changed, 498 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 include/dt-bindings/clock/google,gs101.h

diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
new file mode 100644
index 000000000000..3eebc03a309b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/google,gs101-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google GS101 SoC clock controller
+
+maintainers:
+  - Peter Griffin <peter.griffin at linaro.org>
+
+description: |
+  Google GS101 clock controller is comprised of several CMU units, generating
+  clocks for different domains. Those CMU units are modeled as separate device
+  tree nodes, and might depend on each other. The root clock in that clock tree
+  is OSCCLK (24.576 MHz). That external clock must be defined as a fixed-rate
+  clock in dts.
+
+  CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
+  dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP.
+
+  Each clock is assigned an identifier and client nodes can use this identifier
+  to specify the clock which they consume. All clocks available for usage
+  in clock consumer nodes are defined as preprocessor macros in
+  'dt-bindings/clock/gs101.h' header.
+
+properties:
+  compatible:
+    enum:
+      - google,gs101-cmu-top
+      - google,gs101-cmu-apm
+      - google,gs101-cmu-misc
+
+  clocks:
+    minItems: 1
+    maxItems: 2
+
+  clock-names:
+    minItems: 1
+    maxItems: 2
+
+  "#clock-cells":
+    const: 1
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - "#clock-cells"
+  - clocks
+  - clock-names
+  - reg
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - google,gs101-cmu-top
+              - google,gs101-cmu-apm
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+
+        clock-names:
+          items:
+            - const: oscclk
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-misc
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: Misc bus clock (from CMU_TOP)
+            - description: Misc sss clock (from CMU_TOP)
+
+        clock-names:
+          items:
+            - const: dout_cmu_misc_bus
+            - const: dout_cmu_misc_sss
+
+additionalProperties: false
+
+examples:
+  # Clock controller node for CMU_TOP
+  - |
+    #include <dt-bindings/clock/google,gs101.h>
+
+    cmu_top: clock-controller at 1e080000 {
+        compatible = "google,gs101-cmu-top";
+        reg = <0x1e080000 0x8000>;
+        #clock-cells = <1>;
+        clocks = <&ext_24_5m>;
+        clock-names = "oscclk";
+    };
+
+...
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
new file mode 100644
index 000000000000..5d2c2d907a7b
--- /dev/null
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -0,0 +1,392 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2023 Linaro Ltd.
+ * Author: Peter Griffin <peter.griffin at linaro.org>
+ *
+ * Device Tree binding constants for Google gs101 clock controller.
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
+#define _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
+
+/* CMU_TOP PLL */
+#define CLK_FOUT_SHARED0_PLL		1
+#define CLK_FOUT_SHARED1_PLL		2
+#define CLK_FOUT_SHARED2_PLL		3
+#define CLK_FOUT_SHARED3_PLL		4
+#define CLK_FOUT_SPARE_PLL		5
+
+/* CMU_TOP MUX */
+#define CLK_MOUT_PLL_SHARED0		6
+#define CLK_MOUT_PLL_SHARED1		7
+#define CLK_MOUT_PLL_SHARED2		8
+#define CLK_MOUT_PLL_SHARED3		9
+#define CLK_MOUT_PLL_SPARE		10
+#define CLK_MOUT_CMU_BO_BUS		11
+#define CLK_MOUT_CMU_BUS0_BUS		12
+#define CLK_MOUT_CMU_BUS1_BUS		13
+#define CLK_MOUT_CMU_BUS2_BUS		14
+#define CLK_MOUT_CMU_CIS_CLK0		15
+#define CLK_MOUT_CMU_CIS_CLK1		16
+#define CLK_MOUT_CMU_CIS_CLK2		17
+#define CLK_MOUT_CMU_CIS_CLK3		18
+#define CLK_MOUT_CMU_CIS_CLK4		19
+#define CLK_MOUT_CMU_CIS_CLK5		20
+#define CLK_MOUT_CMU_CIS_CLK6		21
+#define CLK_MOUT_CMU_CIS_CLK7		22
+#define CLK_MOUT_CMU_CMU_BOOST		23
+#define CLK_MOUT_CMU_BOOST_OPTION1	24
+#define CLK_MOUT_CMU_CORE_BUS		25
+#define CLK_MOUT_CMU_CPUCL0_DBG		26
+#define CLK_MOUT_CMU_CPUCL0_SWITCH	27
+#define CLK_MOUT_CMU_CPUCL1_SWITCH	28
+#define CLK_MOUT_CMU_CPUCL2_SWITCH	29
+#define CLK_MOUT_CMU_CSIS_BUS		30
+#define CLK_MOUT_CMU_DISP_BUS		31
+#define CLK_MOUT_CMU_DNS_BUS		32
+#define CLK_MOUT_CMU_DPU_BUS		33
+#define CLK_MOUT_CMU_EH_BUS		34
+#define CLK_MOUT_CMU_G2D_G2D		35
+#define CLK_MOUT_CMU_G2D_MSCL		36
+#define CLK_MOUT_CMU_G3AA_G3AA		37
+#define CLK_MOUT_CMU_G3D_BUSD		38
+#define CLK_MOUT_CMU_G3D_GLB		39
+#define CLK_MOUT_CMU_G3D_SWITCH		40
+#define CLK_MOUT_CMU_GDC_GDC0		41
+#define CLK_MOUT_CMU_GDC_GDC1		42
+#define CLK_MOUT_CMU_GDC_SCSC		43
+#define CLK_MOUT_CMU_HPM		44
+#define CLK_MOUT_CMU_HSI0_BUS		45
+#define CLK_MOUT_CMU_HSI0_DPGTC		46
+#define CLK_MOUT_CMU_HSI0_USB31DRD	47
+#define CLK_MOUT_CMU_HSI0_USBDPDGB	48
+#define CLK_MOUT_CMU_HSI1_BUS		49
+#define CLK_MOUT_CMU_HSI1_PCIE		50
+#define CLK_MOUT_CMU_HSI2_BUS		51
+#define CLK_MOUT_CMU_HSI2_MMC_CARD	52
+#define CLK_MOUT_CMU_HSI2_PCIE		53
+#define CLK_MOUT_CMU_HSI2_UFS_EMBD	54
+#define CLK_MOUT_CMU_IPP_BUS		55
+#define CLK_MOUT_CMU_ITP_BUS		56
+#define CLK_MOUT_CMU_MCSC_ITSC		57
+#define CLK_MOUT_CMU_MCSC_MCSC		58
+#define CLK_MOUT_CMU_MFC_MFC		59
+#define CLK_MOUT_CMU_MIF_BUSP		60
+#define CLK_MOUT_CMU_MIF_SWITCH		61
+#define CLK_MOUT_CMU_MISC_BUS		62
+#define CLK_MOUT_CMU_MISC_SSS		63
+#define CLK_MOUT_CMU_PDP_BUS		64
+#define CLK_MOUT_CMU_PDP_VRA		65
+#define CLK_MOUT_CMU_PERIC0_BUS		66
+#define CLK_MOUT_CMU_PERIC0_IP		67
+#define CLK_MOUT_CMU_PERIC1_BUS		68
+#define CLK_MOUT_CMU_PERIC1_IP		69
+#define CLK_MOUT_CMU_TNR_BUS		70
+#define CLK_MOUT_CMU_TOP_BOOST_OPTION1	71
+#define CLK_MOUT_CMU_TOP_CMUREF		72
+#define CLK_MOUT_CMU_TPU_BUS		73
+#define CLK_MOUT_CMU_TPU_TPU		74
+#define CLK_MOUT_CMU_TPU_TPUCTL		75
+#define CLK_MOUT_CMU_TPU_UART		76
+#define CLK_MOUT_CMU_CMUREF		77
+
+/* CMU_TOP Dividers */
+#define CLK_DOUT_CMU_BO_BUS		78
+#define CLK_DOUT_CMU_BUS0_BUS		79
+#define CLK_DOUT_CMU_BUS1_BUS		80
+#define CLK_DOUT_CMU_BUS2_BUS		81
+#define CLK_DOUT_CMU_CIS_CLK0		82
+#define CLK_DOUT_CMU_CIS_CLK1		83
+#define CLK_DOUT_CMU_CIS_CLK2		84
+#define CLK_DOUT_CMU_CIS_CLK3		85
+#define CLK_DOUT_CMU_CIS_CLK4		86
+#define CLK_DOUT_CMU_CIS_CLK5		87
+#define CLK_DOUT_CMU_CIS_CLK6		88
+#define CLK_DOUT_CMU_CIS_CLK7		89
+#define CLK_DOUT_CMU_CORE_BUS		90
+#define CLK_DOUT_CMU_CPUCL0_DBG		91
+#define CLK_DOUT_CMU_CPUCL0_SWITCH	92
+#define CLK_DOUT_CMU_CPUCL1_SWITCH	93
+#define CLK_DOUT_CMU_CPUCL2_SWITCH	94
+#define CLK_DOUT_CMU_CSIS_BUS		95
+#define CLK_DOUT_CMU_DISP_BUS		96
+#define CLK_DOUT_CMU_DNS_BUS		97
+#define CLK_DOUT_CMU_DPU_BUS		98
+#define CLK_DOUT_CMU_EH_BUS		99
+#define CLK_DOUT_CMU_G2D_G2D		100
+#define CLK_DOUT_CMU_G2D_MSCL		101
+#define CLK_DOUT_CMU_G3AA_G3AA		102
+#define CLK_DOUT_CMU_G3D_BUSD		103
+#define CLK_DOUT_CMU_G3D_GLB		104
+#define CLK_DOUT_CMU_G3D_SWITCH		105
+#define CLK_DOUT_CMU_GDC_GDC0		106
+#define CLK_DOUT_CMU_GDC_GDC1		107
+#define CLK_DOUT_CMU_GDC_SCSC		108
+#define CLK_DOUT_CMU_CMU_HPM		109
+#define CLK_DOUT_CMU_HSI0_BUS		110
+#define CLK_DOUT_CMU_HSI0_DPGTC		111
+#define CLK_DOUT_CMU_HSI0_USB31DRD	112
+#define CLK_DOUT_CMU_HSI0_USBDPDBG	113
+#define CLK_DOUT_CMU_HSI1_BUS		114
+#define CLK_DOUT_CMU_HSI1_PCIE		115
+#define CLK_DOUT_CMU_HSI2_BUS		116
+#define CLK_DOUT_CMU_HSI2_MMC_CARD	117
+#define CLK_DOUT_CMU_HSI2_PCIE		118
+#define CLK_DOUT_CMU_HSI2_UFS_EMBD	119
+#define CLK_DOUT_CMU_IPP_BUS		120
+#define CLK_DOUT_CMU_ITP_BUS		121
+#define CLK_DOUT_CMU_MCSC_ITSC		122
+#define CLK_DOUT_CMU_MCSC_MCSC		123
+#define CLK_DOUT_CMU_MFC_MFC		124
+#define CLK_DOUT_CMU_MIF_BUSP		125
+#define CLK_DOUT_CMU_MISC_BUS		126
+#define CLK_DOUT_CMU_MISC_SSS		127
+#define CLK_DOUT_CMU_OTP		128
+#define CLK_DOUT_CMU_PDP_BUS		129
+#define CLK_DOUT_CMU_PDP_VRA		130
+#define CLK_DOUT_CMU_PERIC0_BUS		131
+#define CLK_DOUT_CMU_PERIC0_IP		132
+#define CLK_DOUT_CMU_PERIC1_BUS		133
+#define CLK_DOUT_CMU_PERIC1_IP		134
+#define CLK_DOUT_CMU_TNR_BUS		135
+#define CLK_DOUT_CMU_TPU_BUS		136
+#define CLK_DOUT_CMU_TPU_TPU		137
+#define CLK_DOUT_CMU_TPU_TPUCTL		138
+#define CLK_DOUT_CMU_TPU_UART		139
+#define CLK_DOUT_CMU_CMU_BOOST		140
+#define CLK_DOUT_CMU_CMU_CMUREF		141
+#define CLK_DOUT_CMU_SHARED0_DIV2	142
+#define CLK_DOUT_CMU_SHARED0_DIV3	143
+#define CLK_DOUT_CMU_SHARED0_DIV4	144
+#define CLK_DOUT_CMU_SHARED0_DIV5	145
+#define CLK_DOUT_CMU_SHARED1_DIV2	146
+#define CLK_DOUT_CMU_SHARED1_DIV3	147
+#define CLK_DOUT_CMU_SHARED1_DIV4	148
+#define CLK_DOUT_CMU_SHARED2_DIV2	149
+#define CLK_DOUT_CMU_SHARED3_DIV2	150
+
+/* CMU_TOP Gates */
+#define CLK_GOUT_BUS0_BOOST		151
+#define CLK_GOUT_BUS1_BOOST		152
+#define CLK_GOUT_BUS2_BOOST		153
+#define CLK_GOUT_CORE_BOOST		154
+#define CLK_GOUT_CPUCL0_BOOST		155
+#define CLK_GOUT_CPUCL1_BOOST		156
+#define CLK_GOUT_CPUCL2_BOOST		157
+#define CLK_GOUT_MIF_BOOST		158
+#define CLK_GOUT_MIF_SWITCH		159
+#define CLK_GOUT_BO_BUS			160
+#define CLK_GOUT_BUS0_BUS		161
+#define CLK_GOUT_BUS1_BUS		162
+#define CLK_GOUT_BUS2_BUS		163
+#define CLK_GOUT_CIS_CLK0		164
+#define CLK_GOUT_CIS_CLK1		165
+#define CLK_GOUT_CIS_CLK2		167
+#define CLK_GOUT_CIS_CLK3		168
+#define CLK_GOUT_CIS_CLK4		169
+#define CLK_GOUT_CIS_CLK5		170
+#define CLK_GOUT_CIS_CLK6		171
+#define CLK_GOUT_CIS_CLK7		172
+#define CLK_GOUT_CMU_BOOST		173
+#define CLK_GOUT_CORE_BUS		174
+#define CLK_GOUT_CPUCL0_DBG		175
+#define CLK_GOUT_CPUCL0_SWITCH		176
+#define CLK_GOUT_CPUCL1_SWITCH		177
+#define CLK_GOUT_CPUCL2_SWITCH		178
+#define CLK_GOUT_CSIS_BUS		179
+#define CLK_GOUT_DISP_BUS		180
+#define CLK_GOUT_DNS_BUS		181
+#define CLK_GOUT_DPU_BUS		182
+#define CLK_GOUT_EH_BUS			183
+#define CLK_GOUT_G2D_G2D		184
+#define CLK_GOUT_G2D_MSCL		185
+#define CLK_GOUT_G3AA_G3AA		186
+#define CLK_GOUT_G3D_BUSD		187
+#define CLK_GOUT_G3D_GLB		188
+#define CLK_GOUT_G3D_SWITCH		189
+#define CLK_GOUT_GDC_GDC0		190
+#define CLK_GOUT_GDC_GDC1		191
+#define CLK_GOUT_GDC_SCSC		192
+#define CLK_GOUT_CMU_HPM		193
+#define CLK_GOUT_HSI0_BUS		194
+#define CLK_GOUT_HSI0_DPGTC		195
+#define CLK_GOUT_HSI0_USB31DRD		196
+#define CLK_GOUT_HSI0_USBDPDGB		197
+#define CLK_GOUT_HSI1_BUS		198
+#define CLK_GOUT_HSI1_PCIE		199
+#define CLK_GOUT_HSI2_BUS		200
+#define CLK_GOUT_HSI2_MMC_CARD		201
+#define CLK_GOUT_HSI2_PCIE		202
+#define CLK_GOUT_HSI2_UFS_EMBD		203
+#define CLK_GOUT_IPP_BUS		204
+#define CLK_GOUT_ITP_BUS		205
+#define CLK_GOUT_MCSC_ITSC		206
+#define CLK_GOUT_MCSC_MCSC		207
+#define CLK_GOUT_MFC_MFC		208
+#define CLK_GOUT_MIF_BUSP		209
+#define CLK_GOUT_MISC_BUS		210
+#define CLK_GOUT_MISC_SSS		211
+#define CLK_GOUT_PDP_BUS		212
+#define CLK_GOUT_PDP_VRA		213
+#define CLK_GOUT_G3AA			214
+#define CLK_GOUT_PERIC0_BUS		215
+#define CLK_GOUT_PERIC0_IP		216
+#define CLK_GOUT_PERIC1_BUS		217
+#define CLK_GOUT_PERIC1_IP		218
+#define CLK_GOUT_TNR_BUS		219
+#define CLK_GOUT_TOP_CMUREF		220
+#define CLK_GOUT_TPU_BUS		221
+#define CLK_GOUT_TPU_TPU		222
+#define CLK_GOUT_TPU_TPUCTL		223
+#define CLK_GOUT_TPU_UART		224
+
+/* CMU_APM */
+#define CLK_MOUT_APM_FUNC				1
+#define CLK_MOUT_APM_FUNCSRC				2
+#define CLK_DOUT_APM_BOOST				3
+#define CLK_DOUT_APM_USI0_UART				4
+#define CLK_DOUT_APM_USI0_USI				5
+#define CLK_DOUT_APM_USI1_UART				6
+#define CLK_GOUT_APM_APM_CMU_APM_PCLK			7
+#define CLK_GOUT_BUS0_BOOST_OPTION1			8
+#define CLK_GOUT_CMU_BOOST_OPTION1			9
+#define CLK_GOUT_CORE_BOOST_OPTION1			10
+#define CLK_GOUT_APM_FUNC				11
+#define CLK_GOUT_APM_APBIF_GPIO_ALIVE_PCLK		12
+#define CLK_GOUT_APM_APBIF_GPIO_FAR_ALIVE_PCLK		13
+#define CLK_GOUT_APM_APBIF_PMU_ALIVE_PCLK		14
+#define CLK_GOUT_APM_APBIF_RTC_PCLK			15
+#define CLK_GOUT_APM_APBIF_TRTC_PCLK			16
+#define CLK_GOUT_APM_APM_USI0_UART_IPCLK		17
+#define CLK_GOUT_APM_APM_USI0_UART_PCLK			18
+#define CLK_GOUT_APM_APM_USI0_USI_IPCLK			19
+#define CLK_GOUT_APM_APM_USI0_USI_PCLK			20
+#define CLK_GOUT_APM_APM_USI1_UART_IPCLK		21
+#define CLK_GOUT_APM_APM_USI1_UART_PCLK			22
+#define CLK_GOUT_APM_D_TZPC_APM_PCLK			23
+#define CLK_GOUT_APM_GPC_APM_PCLK			24
+#define CLK_GOUT_APM_GREBEINTEGRATION_HCLK		25
+#define CLK_GOUT_APM_INTMEM_ACLK			26
+#define CLK_GOUT_APM_INTMEM_PCLK			27
+#define CLK_GOUT_APM_LHM_AXI_G_SWD_I_CLK		28
+#define CLK_GOUT_APM_LHM_AXI_P_AOCAPM_I_CLK		29
+#define CLK_GOUT_APM_LHM_AXI_P_APM_I_CLK		30
+#define CLK_GOUT_APM_LHS_AXI_D_APM_I_CLK		31
+#define CLK_GOUT_APM_LHS_AXI_G_DBGCORE_I_CLK		32
+#define CLK_GOUT_APM_LHS_AXI_G_SCAN2DRAM_I_CLK		33
+#define CLK_GOUT_APM_MAILBOX_APM_AOC_PCLK		34
+#define CLK_GOUT_APM_MAILBOX_APM_AP_PCLK		35
+#define CLK_GOUT_APM_MAILBOX_APM_GSA_PCLK		36
+#define CLK_GOUT_APM_MAILBOX_APM_SWD_PCLK		37
+#define CLK_GOUT_APM_MAILBOX_APM_TPU_PCLK		38
+#define CLK_GOUT_APM_MAILBOX_AP_AOC_PCLK		39
+#define CLK_GOUT_APM_MAILBOX_AP_DBGCORE_PCLK		40
+#define CLK_GOUT_APM_PMU_INTR_GEN_PCLK			41
+#define CLK_GOUT_APM_ROM_CRC32_HOST_ACLK		42
+#define CLK_GOUT_APM_ROM_CRC32_HOST_PCLK		43
+#define CLK_GOUT_APM_CLK_APM_BUS_CLK			44
+#define CLK_GOUT_APM_CLK_APM_USI0_UART_CLK		45
+#define CLK_GOUT_APM_CLK_APM_USI0_USI_CLK		46
+#define CLK_GOUT_APM_CLK_APM_USI1_UART_CLK		47
+#define CLK_GOUT_APM_SPEEDY_APM_PCLK			48
+#define CLK_GOUT_APM_SPEEDY_SUB_APM_PCLK		49
+#define CLK_GOUT_APM_SSMT_D_APM_ACLK			50
+#define CLK_GOUT_APM_SSMT_D_APM_PCLK			51
+#define CLK_GOUT_APM_SSMT_G_DBGCORE_ACLK		52
+#define CLK_GOUT_APM_SSMT_G_DBGCORE_PCLK		53
+#define CLK_GOUT_APM_SS_DBGCORE_SS_DBGCORE_HCLK		54
+#define CLK_GOUT_APM_SYSMMU_D_APM_CLK_S2		55
+#define CLK_GOUT_APM_SYSREG_APM_PCLK			56
+#define CLK_GOUT_APM_UASC_APM_ACLK			57
+#define CLK_GOUT_APM_UASC_APM_PCLK			58
+#define CLK_GOUT_APM_UASC_DBGCORE_ACLK			59
+#define CLK_GOUT_APM_UASC_DBGCORE_PCLK			60
+#define CLK_GOUT_APM_UASC_G_SWD_ACLK			61
+#define CLK_GOUT_APM_UASC_G_SWD_PCLK			62
+#define CLK_GOUT_APM_UASC_P_AOCAPM_ACLK			63
+#define CLK_GOUT_APM_UASC_P_AOCAPM_PCLK			64
+#define CLK_GOUT_APM_UASC_P_APM_ACLK			65
+#define CLK_GOUT_APM_UASC_P_APM_PCLK			66
+#define CLK_GOUT_APM_WDT_APM_PCLK			67
+#define CLK_GOUT_APM_XIU_DP_APM_ACLK			68
+#define CLK_APM_PLL_DIV2_APM				69
+#define CLK_APM_PLL_DIV4_APM				70
+#define CLK_APM_PLL_DIV16_APM				71
+
+/* CMU_MISC */
+#define CLK_MOUT_MISC_BUS_USER				1
+#define CLK_MOUT_MISC_SSS_USER				2
+#define CLK_MOUT_MISC_GIC				3
+#define CLK_DOUT_MISC_BUSP				4
+#define CLK_DOUT_MISC_GIC				5
+#define CLK_GOUT_MISC_MISC_CMU_MISC_PCLK		6
+#define CLK_GOUT_MISC_OTP_CON_BIRA_I_OSCCLK		7
+#define CLK_GOUT_MISC_OTP_CON_BISR_I_OSCCLK		8
+#define CLK_GOUT_MISC_OTP_CON_TOP_I_OSCCLK		9
+#define CLK_GOUT_MISC_CLK_MISC_OSCCLK_CLK		10
+#define CLK_GOUT_MISC_ADM_AHB_SSS_HCLKM			11
+#define CLK_GOUT_MISC_AD_APB_DIT_PCLKM			12
+#define CLK_GOUT_MISC_AD_APB_PUF_PCLKM			13
+#define CLK_GOUT_MISC_DIT_ICLKL2A			14
+#define CLK_GOUT_MISC_D_TZPC_MISC_PCLK			15
+#define CLK_GOUT_MISC_GIC_GICCLK			16
+#define CLK_GOUT_MISC_GPC_MISC_PCLK			17
+#define CLK_GOUT_MISC_LHM_AST_ICC_CPUGIC_I_CLK		18
+#define CLK_GOUT_MISC_LHM_AXI_D_SSS_I_CLK		19
+#define CLK_GOUT_MISC_LHM_AXI_P_GIC_I_CLK		20
+#define CLK_GOUT_MISC_LHM_AXI_P_MISC_I_CLK		21
+#define CLK_GOUT_MISC_LHS_ACEL_D_MISC_I_CLK		22
+#define CLK_GOUT_MISC_LHS_AST_IRI_GICCPU_I_CLK		23
+#define CLK_GOUT_MISC_LHS_AXI_D_SSS_I_CLK		24
+#define CLK_GOUT_MISC_MCT_PCLK				25
+#define CLK_GOUT_MISC_OTP_CON_BIRA_PCLK			26
+#define CLK_GOUT_MISC_OTP_CON_BISR_PCLK			27
+#define CLK_GOUT_MISC_OTP_CON_TOP_PCLK			28
+#define CLK_GOUT_MISC_PDMA_ACLK				29
+#define CLK_GOUT_MISC_PPMU_DMA_ACLK			30
+#define CLK_GOUT_MISC_PPMU_MISC_ACLK			31
+#define CLK_GOUT_MISC_PPMU_MISC_PCLK			32
+#define CLK_GOUT_MISC_PUF_I_CLK				33
+#define CLK_GOUT_MISC_QE_DIT_ACLK			34
+#define CLK_GOUT_MISC_QE_DIT_PCLK			35
+#define CLK_GOUT_MISC_QE_PDMA_ACLK			36
+#define CLK_GOUT_MISC_QE_PDMA_PCLK			37
+#define CLK_GOUT_MISC_QE_PPMU_DMA_ACLK			38
+#define CLK_GOUT_MISC_QE_PPMU_DMA_PCLK			39
+#define CLK_GOUT_MISC_QE_RTIC_ACLK			40
+#define CLK_GOUT_MISC_QE_RTIC_PCLK			41
+#define CLK_GOUT_MISC_QE_SPDMA_ACLK			42
+#define CLK_GOUT_MISC_QE_SPDMA_PCLK			43
+#define CLK_GOUT_MISC_QE_SSS_ACLK			44
+#define CLK_GOUT_MISC_QE_SSS_PCLK			45
+#define CLK_GOUT_MISC_CLK_MISC_BUSD_CLK			46
+#define CLK_GOUT_MISC_CLK_MISC_BUSP_CLK			47
+#define CLK_GOUT_MISC_CLK_MISC_GIC_CLK			48
+#define CLK_GOUT_MISC_CLK_MISC_SSS_CLK			49
+#define CLK_GOUT_MISC_RTIC_I_ACLK			50
+#define CLK_GOUT_MISC_RTIC_I_PCLK			51
+#define CLK_GOUT_MISC_SPDMA_ACLK			52
+#define CLK_GOUT_MISC_SSMT_DIT_ACLK			53
+#define CLK_GOUT_MISC_SSMT_DIT_PCLK			54
+#define CLK_GOUT_MISC_SSMT_PDMA_ACLK			55
+#define CLK_GOUT_MISC_SSMT_PDMA_PCLK			56
+#define CLK_GOUT_MISC_SSMT_PPMU_DMA_ACLK		57
+#define CLK_GOUT_MISC_SSMT_PPMU_DMA_PCLK		58
+#define CLK_GOUT_MISC_SSMT_RTIC_ACLK			59
+#define CLK_GOUT_MISC_SSMT_RTIC_PCLK			60
+#define CLK_GOUT_MISC_SSMT_SPDMA_ACLK			61
+#define CLK_GOUT_MISC_SSMT_SPDMA_PCLK			62
+#define CLK_GOUT_MISC_SSMT_SSS_ACLK			63
+#define CLK_GOUT_MISC_SSMT_SSS_PCLK			64
+#define CLK_GOUT_MISC_SSS_I_ACLK			65
+#define CLK_GOUT_MISC_SSS_I_PCLK			66
+#define CLK_GOUT_MISC_SYSMMU_MISC_CLK_S2		67
+#define CLK_GOUT_MISC_SYSMMU_SSS_CLK_S1			68
+#define CLK_GOUT_MISC_SYSREG_MISC_PCLK			69
+#define CLK_GOUT_MISC_TMU_SUB_PCLK			70
+#define CLK_GOUT_MISC_TMU_TOP_PCLK			71
+#define CLK_GOUT_MISC_WDT_CLUSTER0_PCLK			72
+#define CLK_GOUT_MISC_WDT_CLUSTER1_PCLK			73
+#define CLK_GOUT_MISC_XIU_D_MISC_ACLK			74
+
+#endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:49 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:49 +0000
Subject: [PATCH v6 03/20] dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-4-peter.griffin@linaro.org>

GS101 has three different SYSREG controllers, add dedicated
compatibles for them to the documentation.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../bindings/soc/samsung/samsung,exynos-sysreg.yaml         | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
index 2de4301a467d..127f4ffde76a 100644
--- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
@@ -22,6 +22,12 @@ properties:
               - tesla,fsd-fsys1-sysreg
               - tesla,fsd-peric-sysreg
           - const: syscon
+      - items:
+          - enum:
+              - google,gs101-apm-sysreg
+              - google,gs101-peric0-sysreg
+              - google,gs101-peric1-sysreg
+          - const: syscon
       - items:
           - enum:
               - samsung,exynos5433-cam0-sysreg
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:51 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:51 +0000
Subject: [PATCH v6 05/20] dt-bindings: arm: google: Add bindings for Google ARM platforms
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-6-peter.griffin@linaro.org>

This introduces bindings and dt-schema for the Google tensor SoCs.
Currently just gs101 and pixel 6 are supported.

Reviewed-by: Rob Herring <robh at kernel.org>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../devicetree/bindings/arm/google.yaml       | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml

diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
new file mode 100644
index 000000000000..e20b5c9b16bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/google.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Tensor platforms
+
+maintainers:
+  - Peter Griffin <peter.griffin at linaro.org>
+
+description: |
+  ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
+  devices.
+
+  Currently upstream this is devices using "gs101" SoC which is found in Pixel
+  6, Pixel 6 Pro and Pixel 6a.
+
+  Google have a few different names for the SoC:
+  - Marketing name ("Tensor")
+  - Codename ("Whitechapel")
+  - SoC ID ("gs101")
+  - Die ID ("S5P9845")
+
+  Likewise there are a couple of names for the actual device
+  - Marketing name ("Pixel 6")
+  - Codename ("Oriole")
+
+  Devicetrees should use the lowercased SoC ID and lowercased board codename,
+  e.g. gs101 and gs101-oriole.
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Google Pixel 6 / Oriole
+        items:
+          - enum:
+              - google,gs101-oriole
+          - const: google,gs101
+
+  # Bootloader requires empty ect node to be present
+  ect:
+    type: object
+    additionalProperties: false
+
+required:
+  - ect
+
+additionalProperties: true
+
+...
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:50 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:50 +0000
Subject: [PATCH v6 04/20] dt-bindings: watchdog: Document Google gs101 watchdog bindings
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-5-peter.griffin@linaro.org>

Add the "google,gs101-wdt" compatible to the dt-schema documentation.

gs101 SoC has two CPU clusters and each cluster has its own dedicated
watchdog timer (similar to exynos850 and exynosautov9 SoCs).

These WDT instances are controlled using different bits in PMU
registers.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../devicetree/bindings/watchdog/samsung-wdt.yaml         | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
index 8fb6656ba0c2..57468c2c5ece 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -17,6 +17,7 @@ description: |+
 properties:
   compatible:
     enum:
+      - google,gs101-wdt                      # for Google gs101
       - samsung,s3c2410-wdt                   # for S3C2410
       - samsung,s3c6410-wdt                   # for S3C6410, S5PV210 and Exynos4
       - samsung,exynos5250-wdt                # for Exynos5250
@@ -42,13 +43,14 @@ properties:
   samsung,cluster-index:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
-      Index of CPU cluster on which watchdog is running (in case of Exynos850)
+      Index of CPU cluster on which watchdog is running (in case of Exynos850
+      or Google gs101).
 
   samsung,syscon-phandle:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
       Phandle to the PMU system controller node (in case of Exynos5250,
-      Exynos5420, Exynos7 and Exynos850).
+      Exynos5420, Exynos7, Exynos850 and gs101).
 
 required:
   - compatible
@@ -64,6 +66,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - google,gs101-wdt
               - samsung,exynos5250-wdt
               - samsung,exynos5420-wdt
               - samsung,exynos7-wdt
@@ -77,6 +80,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - google,gs101-wdt
               - samsung,exynos850-wdt
               - samsung,exynosautov9-wdt
     then:
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:53 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:53 +0000
Subject: [PATCH v6 07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-8-peter.griffin@linaro.org>

gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
where more than one pin controller can do external wake-up interrupt.
So add a dedicated compatible for it.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml       | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
index 2bafa867aea2..4c0e25754c6b 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
@@ -44,6 +44,7 @@ properties:
           - const: samsung,exynos7-wakeup-eint
       - items:
           - enum:
+              - google,gs101-wakeup-eint
               - samsung,exynosautov9-wakeup-eint
               - samsung,exynosautov920-wakeup-eint
           - const: samsung,exynos850-wakeup-eint
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:52 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:52 +0000
Subject: [PATCH v6 06/20] dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-7-peter.griffin@linaro.org>

Add the "google,gs101-pinctrl" compatible to the dt-schema bindings
documentation.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 9f04a0c76403..118549c25976 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -35,6 +35,7 @@ properties:
 
   compatible:
     enum:
+      - google,gs101-pinctrl
       - samsung,s3c2412-pinctrl
       - samsung,s3c2416-pinctrl
       - samsung,s3c2440-pinctrl
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:54 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:54 +0000
Subject: [PATCH v6 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-9-peter.griffin@linaro.org>

Add dedicated google-gs101-uart compatible to the dt-schema for
representing uart of the Google Tensor gs101 SoC.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/serial/samsung_uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index e32c1b462836..ccc3626779d9 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -21,6 +21,7 @@ properties:
       - enum:
           - apple,s5l-uart
           - axis,artpec8-uart
+          - google,gs101-uart
           - samsung,s3c6400-uart
           - samsung,s5pv210-uart
           - samsung,exynos4210-uart
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:55 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:55 +0000
Subject: [PATCH v6 09/20] dt-bindings: serial: samsung: Make samsung,uart-fifosize a required property
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-10-peter.griffin@linaro.org>

Specifying samsung,uart-fifosize in both DT and driver static data is error
prone and relies on driver probe order and dt aliases to be correct.

Additionally on many Exynos platforms these are (USI) universal serial
interfaces which can be uart, spi or i2c, so it can change per board.

For google,gs101-uart make samsung,uart-fifosize a required property.
For this platform fifosize now *only* comes from DT.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../devicetree/bindings/serial/samsung_uart.yaml       | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index ccc3626779d9..65d5d361e8f4 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -133,6 +133,16 @@ allOf:
             - const: uart
             - const: clk_uart_baud0
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - google,gs101-uart
+    then:
+      required:
+        - samsung,uart-fifosize
+
 unevaluatedProperties: false
 
 examples:
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:56 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:56 +0000
Subject: [PATCH v6 10/20] dt-bindings: soc: samsung: usi: add google,gs101-usi compatible
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-11-peter.griffin@linaro.org>

From: Tudor Ambarus <tudor.ambarus at linaro.org>

Add google,gs101-usi dedicated compatible for representing USI of Google
GS101 SoC.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
index 61be1f2ddbe7..8b478d6cdc30 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
@@ -25,6 +25,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - google,gs101-usi
               - samsung,exynosautov9-usi
               - samsung,exynosautov920-usi
           - const: samsung,exynos850-usi
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:57 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:57 +0000
Subject: [PATCH v6 11/20] clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-12-peter.griffin@linaro.org>

These plls are found in the Tensor gs101 SoC found in the Pixel 6.

pll0516x: Integer PLL with high frequency
pll0517x: Integer PLL with middle frequency
pll0518x: Integer PLL with low frequency

PLL0516x
FOUT = (MDIV * 2 * FIN)/PDIV * 2^SDIV)

PLL0517x and PLL0518x
FOUT = (MDIV * FIN)/PDIV*2^SDIV)

The PLLs are similar enough to pll_0822x that the same code can handle
both. The main difference is the change in the fout formula for the
high frequency 0516 pll.

Locktime for 516,517 & 518 is 150 the same as the pll_0822x lock factor.
MDIV, SDIV PDIV masks and bit shifts are also the same as 0822x.

When defining the PLL the "con" parameter should be set to CON3
register, like this

PLL(pll_0517x, CLK_FOUT_SHARED0_PLL, "fout_shared0_pll", "oscclk",
    PLL_LOCKTIME_PLL_SHARED0, PLL_CON3_PLL_SHARED0,
    NULL),

Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
Tested-by: Will McVicker <willmcvicker at google.com>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/clk/samsung/clk-pll.c | 6 ++++++
 drivers/clk/samsung/clk-pll.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 74934c6182ce..4bbdf5e91650 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -443,6 +443,9 @@ static unsigned long samsung_pll0822x_recalc_rate(struct clk_hw *hw,
 	sdiv = (pll_con3 >> PLL0822X_SDIV_SHIFT) & PLL0822X_SDIV_MASK;
 
 	fvco *= mdiv;
+	if (pll->type == pll_0516x)
+		fvco *= 2;
+
 	do_div(fvco, (pdiv << sdiv));
 
 	return (unsigned long)fvco;
@@ -1316,6 +1319,9 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 	case pll_1417x:
 	case pll_0818x:
 	case pll_0822x:
+	case pll_0516x:
+	case pll_0517x:
+	case pll_0518x:
 		pll->enable_offs = PLL0822X_ENABLE_SHIFT;
 		pll->lock_offs = PLL0822X_LOCK_STAT_SHIFT;
 		if (!pll->rate_table)
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index 0725d485c6ee..ffd3d52c0dec 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -38,6 +38,9 @@ enum samsung_pll_type {
 	pll_0822x,
 	pll_0831x,
 	pll_142xx,
+	pll_0516x,
+	pll_0517x,
+	pll_0518x,
 };
 
 #define PLL_RATE(_fin, _m, _p, _s, _k, _ks) \
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:30:59 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:30:59 +0000
Subject: [PATCH v6 13/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-14-peter.griffin@linaro.org>

Add support for the pin-controller found on the gs101 SoC used in
Pixel 6 phones.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 140 ++++++++++++++++++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
 4 files changed, 145 insertions(+)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index cb965cf93705..8d08b29a21f6 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -796,3 +796,143 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
 	.ctrl		= fsd_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
 };
+
+/* pin banks of gs101 pin-controller (ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_alive[] = {
+	EXYNOS850_PIN_BANK_EINTW(8, 0x0, "gpa0", 0x00),
+	EXYNOS850_PIN_BANK_EINTW(7, 0x20, "gpa1", 0x04),
+	EXYNOS850_PIN_BANK_EINTW(5, 0x40, "gpa2", 0x08),
+	EXYNOS850_PIN_BANK_EINTW(4, 0x60, "gpa3", 0x0c),
+	EXYNOS850_PIN_BANK_EINTW(4, 0x80, "gpa4", 0x10),
+	EXYNOS850_PIN_BANK_EINTW(7, 0xa0, "gpa5", 0x14),
+	EXYNOS850_PIN_BANK_EINTW(8, 0xc0, "gpa9", 0x18),
+	EXYNOS850_PIN_BANK_EINTW(2, 0xe0, "gpa10", 0x1c),
+};
+
+/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_far_alive[] = {
+	EXYNOS850_PIN_BANK_EINTW(8, 0x0, "gpa6", 0x00),
+	EXYNOS850_PIN_BANK_EINTW(4, 0x20, "gpa7", 0x04),
+	EXYNOS850_PIN_BANK_EINTW(8, 0x40, "gpa8", 0x08),
+	EXYNOS850_PIN_BANK_EINTW(2, 0x60, "gpa11", 0x0c),
+};
+
+/* pin banks of gs101 pin-controller (GSACORE) */
+static const struct samsung_pin_bank_data gs101_pin_gsacore[] = {
+	EXYNOS850_PIN_BANK_EINTG(2, 0x0, "gps0", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(8, 0x20, "gps1", 0x04),
+	EXYNOS850_PIN_BANK_EINTG(3, 0x40, "gps2", 0x08),
+};
+
+/* pin banks of gs101 pin-controller (GSACTRL) */
+static const struct samsung_pin_bank_data gs101_pin_gsactrl[] = {
+	EXYNOS850_PIN_BANK_EINTW(6, 0x0, "gps3", 0x00),
+};
+
+/* pin banks of gs101 pin-controller (PERIC0) */
+static const struct samsung_pin_bank_data gs101_pin_peric0[] = {
+	EXYNOS850_PIN_BANK_EINTG(5, 0x0, "gpp0", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x20, "gpp1", 0x04),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x40, "gpp2", 0x08),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x60, "gpp3", 0x0c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x80, "gpp4", 0x10),
+	EXYNOS850_PIN_BANK_EINTG(2, 0xa0, "gpp5", 0x14),
+	EXYNOS850_PIN_BANK_EINTG(4, 0xc0, "gpp6", 0x18),
+	EXYNOS850_PIN_BANK_EINTG(2, 0xe0, "gpp7", 0x1c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x100, "gpp8", 0x20),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x120, "gpp9", 0x24),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x140, "gpp10", 0x28),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x160, "gpp11", 0x2c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x180, "gpp12", 0x30),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x1a0, "gpp13", 0x34),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x1c0, "gpp14", 0x38),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x1e0, "gpp15", 0x3c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x200, "gpp16", 0x40),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x220, "gpp17", 0x44),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x240, "gpp18", 0x48),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x260, "gpp19", 0x4c),
+};
+
+/* pin banks of gs101 pin-controller (PERIC1) */
+static const struct samsung_pin_bank_data gs101_pin_peric1[] = {
+	EXYNOS850_PIN_BANK_EINTG(8, 0x0, "gpp20", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x20, "gpp21", 0x04),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x40, "gpp22", 0x08),
+	EXYNOS850_PIN_BANK_EINTG(8, 0x60, "gpp23", 0x0c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x80, "gpp24", 0x10),
+	EXYNOS850_PIN_BANK_EINTG(4, 0xa0, "gpp25", 0x14),
+	EXYNOS850_PIN_BANK_EINTG(5, 0xc0, "gpp26", 0x18),
+	EXYNOS850_PIN_BANK_EINTG(4, 0xe0, "gpp27", 0x1c),
+};
+
+/* pin banks of gs101 pin-controller (HSI1) */
+static const struct samsung_pin_bank_data gs101_pin_hsi1[] = {
+	EXYNOS850_PIN_BANK_EINTG(6, 0x0, "gph0", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(7, 0x20, "gph1", 0x04),
+};
+
+/* pin banks of gs101 pin-controller (HSI2) */
+static const struct samsung_pin_bank_data gs101_pin_hsi2[] = {
+	EXYNOS850_PIN_BANK_EINTG(6, 0x0, "gph2", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x20, "gph3", 0x04),
+	EXYNOS850_PIN_BANK_EINTG(6, 0x40, "gph4", 0x08),
+};
+
+static const struct samsung_pin_ctrl gs101_pin_ctrl[] __initconst = {
+	{
+		/* pin banks of gs101 pin-controller (ALIVE) */
+		.pin_banks	= gs101_pin_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_alive),
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+		.pin_banks	= gs101_pin_far_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_far_alive),
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (GSACORE) */
+		.pin_banks	= gs101_pin_gsacore,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsacore),
+	}, {
+		/* pin banks of gs101 pin-controller (GSACTRL) */
+		.pin_banks	= gs101_pin_gsactrl,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsactrl),
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC0) */
+		.pin_banks	= gs101_pin_peric0,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric0),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC1) */
+		.pin_banks	= gs101_pin_peric1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume	= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI1) */
+		.pin_banks	= gs101_pin_hsi1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI2) */
+		.pin_banks	= gs101_pin_hsi2,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi2),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	},
+};
+
+const struct samsung_pinctrl_of_match_data gs101_of_data __initconst = {
+	.ctrl		= gs101_pin_ctrl,
+	.num_ctrl	= ARRAY_SIZE(gs101_pin_ctrl),
+};
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 6b58ec84e34b..3834bf953178 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -468,6 +468,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
 			.data = &exynos7_wkup_irq_chip },
 	{ .compatible = "samsung,exynosautov9-wakeup-eint",
 			.data = &exynos7_wkup_irq_chip },
+	{ .compatible = "google,gs101-wakeup-eint",
+			.data = &exynos7_wkup_irq_chip },
 	{ }
 };
 
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 79babbb39ced..b8d549fe38cb 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1321,6 +1321,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 		.data = &exynosautov9_of_data },
 	{ .compatible = "tesla,fsd-pinctrl",
 		.data = &fsd_of_data },
+	{ .compatible = "google,gs101-pinctrl",
+		.data = &gs101_of_data },
 #endif
 #ifdef CONFIG_PINCTRL_S3C64XX
 	{ .compatible = "samsung,s3c64xx-pinctrl",
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 9b3db50adef3..0b459651bc4a 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -351,6 +351,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
 extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
 extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
 extern const struct samsung_pinctrl_of_match_data fsd_of_data;
+extern const struct samsung_pinctrl_of_match_data gs101_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2416_of_data;
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:31:00 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:31:00 +0000
Subject: [PATCH v6 14/20] watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bit
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-15-peter.griffin@linaro.org>

The WDT uses the CPU core signal DBGACK to determine whether the SoC
is running in debug mode or not. If the DBGACK signal is asserted and
DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
(disabled).

Presence of the DBGACK_MASK bit is determined by adding a new
QUIRK_HAS_DBGACK_BIT quirk. Also update to use BIT macro to avoid
checkpatch --strict warnings.

Tested-by: Will McVicker <willmcvicker at google.com>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 0b4bd883ff28..7ecb762a371d 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -9,6 +9,7 @@
  *     (c) Copyright 1996 Alan Cox <alan at lxorguk.ukuu.org.uk>
  */
 
+#include <linux/bits.h>
 #include <linux/module.h>
 #include <linux/moduleparam.h>
 #include <linux/types.h>
@@ -34,9 +35,10 @@
 
 #define S3C2410_WTCNT_MAXCNT	0xffff
 
-#define S3C2410_WTCON_RSTEN	(1 << 0)
-#define S3C2410_WTCON_INTEN	(1 << 2)
-#define S3C2410_WTCON_ENABLE	(1 << 5)
+#define S3C2410_WTCON_RSTEN		BIT(0)
+#define S3C2410_WTCON_INTEN		BIT(2)
+#define S3C2410_WTCON_ENABLE		BIT(5)
+#define S3C2410_WTCON_DBGACK_MASK	BIT(16)
 
 #define S3C2410_WTCON_DIV16	(0 << 3)
 #define S3C2410_WTCON_DIV32	(1 << 3)
@@ -100,12 +102,17 @@
  * %QUIRK_HAS_PMU_CNT_EN: PMU block has some register (e.g. CLUSTERx_NONCPU_OUT)
  * with "watchdog counter enable" bit. That bit should be set to make watchdog
  * counter running.
+ *
+ * %QUIRK_HAS_DBGACK_BIT: WTCON register has DBGACK_MASK bit. Setting the
+ * DBGACK_MASK bit disables the watchdog outputs when the SoC is in debug mode.
+ * Debug mode is determined by the DBGACK CPU signal.
  */
 #define QUIRK_HAS_WTCLRINT_REG			(1 << 0)
 #define QUIRK_HAS_PMU_MASK_RESET		(1 << 1)
 #define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
 #define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
 #define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
+#define QUIRK_HAS_DBGACK_BIT			BIT(5)
 
 /* These quirks require that we have a PMU register map */
 #define QUIRKS_HAVE_PMUREG \
@@ -375,6 +382,19 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
 	return 0;
 }
 
+/* Disable watchdog outputs if CPU is in debug mode */
+static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt)
+{
+	unsigned long wtcon;
+
+	if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
+		return;
+
+	wtcon = readl(wdt->reg_base + S3C2410_WTCON);
+	wtcon |= S3C2410_WTCON_DBGACK_MASK;
+	writel(wtcon, wdt->reg_base + S3C2410_WTCON);
+}
+
 static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
 {
 	struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
@@ -700,6 +720,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
 	wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
 	wdt->wdt_device.parent = dev;
 
+	s3c2410wdt_mask_dbgack(wdt);
+
 	/*
 	 * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
 	 * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:31:01 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:31:01 +0000
Subject: [PATCH v6 15/20] watchdog: s3c2410_wdt: Update QUIRK macros to use BIT macro
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-16-peter.griffin@linaro.org>

Update the remaining QUIRK macros to use the BIT macro.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7ecb762a371d..b7a03668f743 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -107,11 +107,11 @@
  * DBGACK_MASK bit disables the watchdog outputs when the SoC is in debug mode.
  * Debug mode is determined by the DBGACK CPU signal.
  */
-#define QUIRK_HAS_WTCLRINT_REG			(1 << 0)
-#define QUIRK_HAS_PMU_MASK_RESET		(1 << 1)
-#define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
-#define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
-#define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
+#define QUIRK_HAS_WTCLRINT_REG			BIT(0)
+#define QUIRK_HAS_PMU_MASK_RESET		BIT(1)
+#define QUIRK_HAS_PMU_RST_STAT			BIT(2)
+#define QUIRK_HAS_PMU_AUTO_DISABLE		BIT(3)
+#define QUIRK_HAS_PMU_CNT_EN			BIT(4)
 #define QUIRK_HAS_DBGACK_BIT			BIT(5)
 
 /* These quirks require that we have a PMU register map */
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:31:02 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:31:02 +0000
Subject: [PATCH v6 16/20] watchdog: s3c2410_wdt: Add support for Google gs101 SoC
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-17-peter.griffin@linaro.org>

This patch adds the compatibles and drvdata for the Google
gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.

Similar to Exynos850 it has two watchdog instances, one for
each cluster and has some control bits in PMU registers.

gs101 also has the dbgack_mask bit in wtcon register, so
we also enable QUIRK_HAS_DBGACK_BIT.

Tested-by: Will McVicker <willmcvicker at google.com>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 49 ++++++++++++++++++++++++++++++----
 1 file changed, 44 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index b7a03668f743..ae4457a39c77 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -69,6 +69,13 @@
 #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
 #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
 
+#define GS_CLUSTER0_NONCPU_OUT			0x1220
+#define GS_CLUSTER1_NONCPU_OUT			0x1420
+#define GS_CLUSTER0_NONCPU_INT_EN		0x1244
+#define GS_CLUSTER1_NONCPU_INT_EN		0x1444
+#define GS_CLUSTER2_NONCPU_INT_EN		0x1644
+#define GS_RST_STAT_REG_OFFSET			0x3B44
+
 /**
  * DOC: Quirk flags for different Samsung watchdog IP-cores
  *
@@ -270,6 +277,32 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
 		  QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
 };
 
+static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
+	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 0,
+	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
+	.cnt_en_bit = 8,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET |
+		  QUIRK_HAS_PMU_CNT_EN | QUIRK_HAS_WTCLRINT_REG |
+		  QUIRK_HAS_DBGACK_BIT,
+};
+
+static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
+	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 1,
+	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
+	.cnt_en_bit = 7,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET |
+		  QUIRK_HAS_PMU_CNT_EN | QUIRK_HAS_WTCLRINT_REG |
+		  QUIRK_HAS_DBGACK_BIT,
+};
+
 static const struct of_device_id s3c2410_wdt_match[] = {
 	{ .compatible = "samsung,s3c2410-wdt",
 	  .data = &drv_data_s3c2410 },
@@ -285,6 +318,8 @@ static const struct of_device_id s3c2410_wdt_match[] = {
 	  .data = &drv_data_exynos850_cl0 },
 	{ .compatible = "samsung,exynosautov9-wdt",
 	  .data = &drv_data_exynosautov9_cl0 },
+	{ .compatible = "google,gs101-wdt",
+	  .data = &drv_data_gs101_cl0 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
@@ -605,9 +640,10 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 	}
 
 #ifdef CONFIG_OF
-	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
+	/* Choose Exynos9 SoC family driver data w.r.t. cluster index */
 	if (variant == &drv_data_exynos850_cl0 ||
-	    variant == &drv_data_exynosautov9_cl0) {
+	    variant == &drv_data_exynosautov9_cl0 ||
+	    variant == &drv_data_gs101_cl0) {
 		u32 index;
 		int err;
 
@@ -620,9 +656,12 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 		case 0:
 			break;
 		case 1:
-			variant = (variant == &drv_data_exynos850_cl0) ?
-				&drv_data_exynos850_cl1 :
-				&drv_data_exynosautov9_cl1;
+			if (variant == &drv_data_exynos850_cl0)
+				variant = &drv_data_exynos850_cl1;
+			else if (variant == &drv_data_exynosautov9_cl0)
+				variant = &drv_data_exynosautov9_cl1;
+			else if (variant == &drv_data_gs101_cl0)
+				variant = &drv_data_gs101_cl1;
 			break;
 		default:
 			return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:31:03 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:31:03 +0000
Subject: [PATCH v6 17/20] tty: serial: samsung: Add gs101 compatible and common fifoszdt_serial_drv_data
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-18-peter.griffin@linaro.org>

Add serial driver data for Google Tensor gs101 SoC and a common
fifoszdt_serial_drv_data that can be used by platforms that specify the
samsung,uart-fifosize DT property.

A corresponding dt-bindings patch updates the yaml to ensure
samsung,uart-fifosize is a required property.

Tested-by: Will McVicker <willmcvicker at google.com>
Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Reviewed-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/tty/serial/samsung_tty.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 1b0c2b467a30..71d17d804fda 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2490,14 +2490,25 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
 	.fifosize = { 256, 64, 64, 64 },
 };
 
+/*
+ * Common drv_data struct for platforms that specify samsung,uart-fifosize in
+ * device tree.
+ */
+static const struct s3c24xx_serial_drv_data exynos_fifoszdt_serial_drv_data = {
+	EXYNOS_COMMON_SERIAL_DRV_DATA(),
+	.fifosize = { 0 },
+};
+
 #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
 #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
 #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
+#define EXYNOS_FIFOSZDT_DRV_DATA (&exynos_fifoszdt_serial_drv_data)
 
 #else
 #define EXYNOS4210_SERIAL_DRV_DATA NULL
 #define EXYNOS5433_SERIAL_DRV_DATA NULL
 #define EXYNOS850_SERIAL_DRV_DATA NULL
+#define EXYNOS_FIFOSZDT_DRV_DATA NULL
 #endif
 
 #ifdef CONFIG_ARCH_APPLE
@@ -2581,6 +2592,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
 	}, {
 		.name		= "artpec8-uart",
 		.driver_data	= (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
+	}, {
+		.name		= "gs101-uart",
+		.driver_data	= (kernel_ulong_t)EXYNOS_FIFOSZDT_DRV_DATA,
 	},
 	{ },
 };
@@ -2602,6 +2616,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
 		.data = EXYNOS850_SERIAL_DRV_DATA },
 	{ .compatible = "axis,artpec8-uart",
 		.data = ARTPEC8_SERIAL_DRV_DATA },
+	{ .compatible = "google,gs101-uart",
+		.data = EXYNOS_FIFOSZDT_DRV_DATA },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:31:06 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:31:06 +0000
Subject: [PATCH v6 20/20] MAINTAINERS: add entry for Google Tensor SoC
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-21-peter.griffin@linaro.org>

Add maintainers entry for the Google tensor SoC based
platforms.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36f6e76170e6..a3bd682c9e32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9032,6 +9032,16 @@ S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
 F:	drivers/firmware/google/
 
+GOOGLE TENSOR SoC SUPPORT
+M:	Peter Griffin <peter.griffin at linaro.org>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L:	linux-samsung-soc at vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+F:	arch/arm64/boot/dts/exynos/google/
+F:	drivers/clk/samsung/clk-gs101.c
+F:	include/dt-bindings/clock/google,clk-gs101.h
+
 GPD POCKET FAN DRIVER
 M:	Hans de Goede <hdegoede at redhat.com>
 L:	platform-driver-x86 at vger.kernel.org
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:31:05 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:31:05 +0000
Subject: [PATCH v6 19/20] arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-20-peter.griffin@linaro.org>

Add initial board support for the Pixel 6 phone code named Oriole. This
has been tested with a minimal busybox initramfs and boots to a shell.

Tested-by: Will McVicker <willmcvicker at google.com>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 arch/arm64/boot/dts/exynos/Makefile           |   2 +
 arch/arm64/boot/dts/exynos/google/Makefile    |   4 +
 .../boot/dts/exynos/google/gs101-oriole.dts   | 105 ++++++++++++++++++
 3 files changed, 111 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts

diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
index 6e4ba69268e5..44c24a8ad9e1 100644
--- a/arch/arm64/boot/dts/exynos/Makefile
+++ b/arch/arm64/boot/dts/exynos/Makefile
@@ -1,4 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
+subdir-y += google
+
 dtb-$(CONFIG_ARCH_EXYNOS) += \
 	exynos5433-tm2.dtb		\
 	exynos5433-tm2e.dtb		\
diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
new file mode 100644
index 000000000000..0a6d5e1fe4ee
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+dtb-$(CONFIG_ARCH_EXYNOS) += \
+	gs101-oriole.dtb \
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
new file mode 100644
index 000000000000..ce087ee1fd4d
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Oriole Device Tree
+ *
+ * Copyright 2021-2023 Google LLC
+ * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "gs101-pinctrl.h"
+#include "gs101.dtsi"
+
+/ {
+	model = "Oriole";
+	compatible = "google,gs101-oriole", "google,gs101";
+
+	aliases {
+		serial0 = &serial_0;
+	};
+
+	chosen {
+		/* Bootloader expects bootargs specified otherwise it crashes */
+		bootargs = "";
+		stdout-path = &serial_0;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&key_voldown>, <&key_volup>, <&key_power>;
+
+		button-vol-down {
+			label = "KEY_VOLUMEDOWN";
+			linux,code = <KEY_VOLUMEDOWN>;
+			gpios = <&gpa7 3 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-vol-up {
+			label = "KEY_VOLUMEUP";
+			linux,code = <KEY_VOLUMEUP>;
+			gpios = <&gpa8 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-power {
+			label = "KEY_POWER";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpa10 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+	};
+};
+
+&ext_24_5m {
+	clock-frequency = <24576000>;
+};
+
+&ext_200m {
+	clock-frequency = <200000000>;
+};
+
+&pinctrl_far_alive {
+	key_voldown: key-voldown-pins {
+		samsung,pins = "gpa7-3";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	key_volup: key-volup-pins {
+		samsung,pins = "gpa8-1";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_gpio_alive {
+	key_power: key-power-pins {
+		samsung,pins = "gpa10-1";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&serial_0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_bus>;
+};
+
+&usi_uart {
+	status = "okay";
+	samsung,clkreq-on; /* needed for UART mode */
+};
+
+&watchdog_cl0 {
+	timeout-sec = <30>;
+	status = "okay";
+};
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Sat Dec  9 15:31:04 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Sat,  9 Dec 2023 23:31:04 +0000
Subject: [PATCH v6 18/20] arm64: dts: exynos: google: Add initial Google gs101 SoC support
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <20231209233106.147416-19-peter.griffin@linaro.org>

Google gs101 SoC is a ARMv8 mobile SoC found in the Pixel 6
(oriole), Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
phones.

It features:
* 4xA55 Little cluster
* 2xA76 Mid cluster
* 2xX1 Big cluster

This commit adds the basic device tree for gs101 (SoC).
Further platform support will be added over time.

Tested-by: Will McVicker <willmcvicker at google.com>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../boot/dts/exynos/google/gs101-pinctrl.dtsi | 1249 +++++++++++++++++
 .../boot/dts/exynos/google/gs101-pinctrl.h    |   33 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  476 +++++++
 3 files changed, 1758 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi

diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
new file mode 100644
index 000000000000..e6a9776d4d62
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
@@ -0,0 +1,1249 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright 2019-2023 Google LLC
+ * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
+ */
+
+#include "gs101-pinctrl.h"
+
+&pinctrl_gpio_alive {
+	gpa0: gpa0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa1: gpa1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa2: gpa2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa3: gpa3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa4: gpa4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa5: gpa5-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa9: gpa9-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa10: gpa10-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	uart15_bus: uart15-bus-pins {
+		samsung,pins = "gpa2-3", "gpa2-4";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	uart16_bus: uart16-bus-pins {
+		samsung,pins = "gpa3-0", "gpa3-1", "gpa3-2", "gpa3-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	uart17_bus: uart17-bus-pins {
+		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2", "gpa4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi15_bus: spi15-bus-pins {
+		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi15_cs: spi15-cs-pins {
+		samsung,pins = "gpa4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_far_alive {
+	gpa6: gpa6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa7: gpa7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa8: gpa8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa11: gpa11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+};
+
+&pinctrl_gsacore {
+	gps0: gps0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps1: gps1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps2: gps2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_gsactrl {
+	gps3: gps3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_hsi1 {
+	gph0: gph0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph1: gph1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	pcie0_clkreq: pcie0-clkreq-pins{
+		samsung,pins = "gph0-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
+	};
+
+	pcie0_perst: pcie0-perst-pins {
+		samsung,pins = "gph0-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+	};
+};
+
+&pinctrl_hsi2 {
+	gph2: gph2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph3: gph3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph4: gph4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	sd2_clk: sd2-clk-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_cmd: sd2-cmd-pins {
+		samsung,pins = "gph4-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus1: sd2-bus-width1-pins {
+		samsung,pins = "gph4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus4: sd2-bus-width4-pins {
+		samsung,pins = "gph4-3", "gph4-4", "gph4-5";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_1x: sd2-clk-fast-slew-rate-1x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_2x: sd2-clk-fast-slew-rate-2x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_3x: sd2-clk-fast-slew-rate-3x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_4x: sd2-clk-fast-slew-rate-4x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+	};
+
+	ufs_rst_n: ufs-rst-n-pins {
+		samsung,pins = "gph3-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	ufs_refclk_out: ufs-refclk-out-pins {
+		samsung,pins = "gph3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	pcie1_clkreq: pcie1-clkreq-pins {
+		samsung,pins = "gph2-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
+	};
+
+	pcie1_perst: pcie1-perst-pins {
+		samsung,pins = "gph2-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+	};
+};
+
+&pinctrl_peric0 {
+	gpp0: gpp0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp1: gpp1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp2: gpp2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp3: gpp3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp4: gpp4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp5: gpp5-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp6: gpp6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp7: gpp7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp8: gpp8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp9: gpp9-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp10: gpp10-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp11: gpp11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp12: gpp12-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp13: gpp13-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp14: gpp14-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp15: gpp15-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp16: gpp16-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp17: gpp17-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp18: gpp18-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp19: gpp19-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	/* USI_PERIC0_UART_DBG */
+	uart0_bus: uart0-bus-pins {
+		samsung,pins = "gpp1-2", "gpp1-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	disp_te_pri_on: disp-te-pri-on-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+	};
+
+	disp_te_pri_off: disp-te-pri-off-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
+	};
+
+	disp_te_sec_on: disp-te-sec-on-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+	};
+
+	disp_te_sec_off: disp-te-sec-off-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
+	};
+
+	sensor_mclk1_out: sensor-mclk1-out-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk1_fn: sensor-mclk1-fn-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_out: sensor-mclk2-out-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_fn: sensor-mclk2-fn-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_out: sensor-mclk3-out-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_fn: sensor-mclk3-fn-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_out: sensor-mclk4-out-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_fn: sensor-mclk4-fn-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_out: sensor-mclk5-out-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_fn: sensor-mclk5-fn-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_out: sensor-mclk6-out-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_fn: sensor-mclk6-fn-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_out: sensor-mclk7-out-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_fn: sensor-mclk7-fn-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_out: sensor-mclk8-out-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_fn: sensor-mclk8-fn-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	hsi2c14_bus: hsi2c14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart14_bus_single: uart14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1",
+			       "gpp18-2", "gpp18-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi14_bus: spi14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1", "gpp18-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs: spi14-cs-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs_func: spi14-cs-func-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c8_bus: hsi2c8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-pud-pdn = <GS101_PIN_PDN_OUT0>;
+	};
+
+	uart8_bus_single: uart8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2",
+			       "gpp16-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi8_bus: spi8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs: spi8-cs-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs_func: spi8-cs-func-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c7_bus: hsi2c7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart7_bus_single: uart7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1",
+			       "gpp14-2", "gpp14-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi7_bus: spi7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1", "gpp14-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs: spi7-cs-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs_func: spi7-cs-func-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c6_bus: hsi2c6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart6_bus_single: uart6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1",
+			       "gpp12-2", "gpp12-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi6_bus: spi6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1", "gpp12-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs: spi6-cs-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs_func: spi6-cs-func-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c5_bus: hsi2c5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart5_bus_single: uart5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1",
+			       "gpp10-2", "gpp10-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi5_bus: spi5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1", "gpp10-2";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi5_cs_func: spi5-cs-func-pins {
+		samsung,pins = "gpp10-3";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	hsi2c4_bus: hsi2c4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart4_bus_single: uart4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1",
+			       "gpp8-2", "gpp8-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi4_bus: spi4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1", "gpp8-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs: spi4-cs-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs_func: spi4-cs-func-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c3_bus: hsi2c3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart3_bus_single: uart3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1",
+			       "gpp6-2", "gpp6-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi3_bus: spi3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1", "gpp6-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs: spi3-cs-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs_func: spi3-cs-func-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c2_bus: hsi2c2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart2_bus_single: uart2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1",
+			       "gpp4-2", "gpp4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi2_bus: spi2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1", "gpp4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs: spi2-cs-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs_func: spi2-cs-func-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c1_bus: hsi2c1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart1_bus_single: uart1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1",
+			       "gpp2-2", "gpp2-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi1_bus: spi1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1", "gpp2-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs: spi1-cs-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs_func: spi1-cs-func-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_peric1 {
+	gpp20: gpp20-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp21: gpp21-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp22: gpp22-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp23: gpp23-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp24: gpp24-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp25: gpp25-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp26: gpp26-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp27: gpp27-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	hsi2c13_bus: hsi2c13-bus-pins  {
+		samsung,pins = "gpp25-0", "gpp25-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart13_bus_single: uart13-bus-pins {
+		samsung,pins = "gpp25-0", "gpp25-1",
+			       "gpp25-2", "gpp25-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi13_bus: spi13-bus-pins {
+		samsung,pins = "gpp25-0", "gpp25-1", "gpp25-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs: spi13-cs-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs_func: spi13-cs-func-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c12_bus: hsi2c12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart12_bus_single: uart12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5",
+			       "gpp23-6", "gpp23-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi12_bus: spi12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5", "gpp23-6";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs2: spi14-cs2-pins {
+		samsung,pins = "gpp23-6";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs: spi12-cs-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs_func: spi12-cs-func-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c11_bus: hsi2c11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart11_bus_single: uart11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1",
+			       "gpp23-2", "gpp23-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi11_bus: spi11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1", "gpp23-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs: spi11-cs-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs_func: spi11-cs-func-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c10_bus: hsi2c10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart10_bus_single: uart10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1",
+			       "gpp21-2", "gpp21-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi10_bus: spi10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1", "gpp21-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs: spi10-cs-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs_func: spi10-cs-func-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c9_bus: hsi2c9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart9_bus_single: uart9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5",
+			       "gpp20-6", "gpp20-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi9_bus: spi9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5", "gpp20-6";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs: spi9-cs-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs_func: spi9-cs-func-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c0_bus: hsi2c0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart0_bus_single: uart0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1",
+			       "gpp20-2", "gpp20-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi0_bus: spi0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1", "gpp20-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs: spi0-cs-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs_func: spi0-cs-func-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
new file mode 100644
index 000000000000..68b7bc47c91b
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Pinctrl binding constants for GS101
+ *
+ * Copyright 2020-2023 Google LLC
+ */
+
+#ifndef __DT_BINDINGS_PINCTRL_GS101_H__
+#define __DT_BINDINGS_PINCTRL_GS101_H__
+
+#define GS101_PIN_PULL_NONE		0
+#define GS101_PIN_PULL_DOWN		1
+#define GS101_PIN_PULL_UP		3
+
+/* Pin function in power down mode */
+#define GS101_PIN_PDN_OUT0		0
+#define GS101_PIN_PDN_OUT1		1
+#define GS101_PIN_PDN_INPUT		2
+#define GS101_PIN_PDN_PREV		3
+
+/* GS101 drive strengths */
+#define GS101_PIN_DRV_2_5_MA		0
+#define GS101_PIN_DRV_5_MA		1
+#define GS101_PIN_DRV_7_5_MA		2
+#define GS101_PIN_DRV_10_MA		3
+
+#define GS101_PIN_FUNC_INPUT		0
+#define GS101_PIN_FUNC_OUTPUT		1
+#define GS101_PIN_FUNC_2		2
+#define GS101_PIN_FUNC_3		3
+#define GS101_PIN_FUNC_EINT		0xf
+
+#endif /* __DT_BINDINGS_PINCTRL_GS101_H__ */
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
new file mode 100644
index 000000000000..60e112d25246
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -0,0 +1,476 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC
+ *
+ * Copyright 2019-2023 Google LLC
+ * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
+ */
+
+#include <dt-bindings/clock/google,gs101.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/samsung,exynos-usi.h>
+
+/ {
+	compatible = "google,gs101";
+	#address-cells = <2>;
+	#size-cells = <1>;
+
+	interrupt-parent = <&gic>;
+
+	aliases {
+		pinctrl0 = &pinctrl_gpio_alive;
+		pinctrl1 = &pinctrl_far_alive;
+		pinctrl2 = &pinctrl_gsacore;
+		pinctrl3 = &pinctrl_gsactrl;
+		pinctrl4 = &pinctrl_peric0;
+		pinctrl5 = &pinctrl_peric1;
+		pinctrl6 = &pinctrl_hsi1;
+		pinctrl7 = &pinctrl_hsi2;
+	};
+
+	pmu-0 {
+		compatible = "arm,cortex-a55-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
+	};
+
+	pmu-1 {
+		compatible = "arm,cortex-a76-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
+	};
+
+	pmu-2 {
+		compatible = "arm,cortex-x1-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster2>;
+	};
+
+	pmu-3 {
+		compatible = "arm,dsu-pmu";
+		interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH 0>;
+		cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
+		       <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
+	};
+
+	/* TODO replace with CCF clock */
+	dummy_clk: oscillator {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <12345>;
+		clock-output-names = "pclk";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+				core1 {
+					cpu = <&cpu1>;
+				};
+				core2 {
+					cpu = <&cpu2>;
+				};
+				core3 {
+					cpu = <&cpu3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu4>;
+				};
+				core1 {
+					cpu = <&cpu5>;
+				};
+			};
+
+			cluster2 {
+				core0 {
+					cpu = <&cpu6>;
+				};
+				core1 {
+					cpu = <&cpu7>;
+				};
+			};
+		};
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0000>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu1: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0100>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu2: cpu at 200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0200>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu3: cpu at 300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0300>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu4: cpu at 400 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a76";
+			reg = <0x0400>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu5: cpu at 500 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a76";
+			reg = <0x0500>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu6: cpu at 600 {
+			device_type = "cpu";
+			compatible = "arm,cortex-x1";
+			reg = <0x0600>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		cpu7: cpu at 700 {
+			device_type = "cpu";
+			compatible = "arm,cortex-x1";
+			reg = <0x0700>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		idle-states {
+			entry-method = "psci";
+
+			ANANKE_CPU_SLEEP: cpu-ananke-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <70>;
+				exit-latency-us = <160>;
+				min-residency-us = <2000>;
+			};
+
+			ENYO_CPU_SLEEP: cpu-enyo-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <150>;
+				exit-latency-us = <190>;
+				min-residency-us = <2500>;
+			};
+
+			HERA_CPU_SLEEP: cpu-hera-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <235>;
+				exit-latency-us = <220>;
+				min-residency-us = <3500>;
+			};
+		};
+	};
+
+	/* ect node is required to be present by bootloader */
+	ect {
+	};
+
+	ext_24_5m: clock-1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-output-names = "oscclk";
+	};
+
+	ext_200m: clock-2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-output-names = "ext-200m";
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges;
+
+		gsa_reserved_protected: gsa at 90200000 {
+			reg = <0x0 0x90200000 0x400000>;
+			no-map;
+		};
+
+		tpu_fw_reserved: tpu-fw at 93000000 {
+			reg = <0x0 0x93000000 0x1000000>;
+			no-map;
+		};
+
+		aoc_reserve: aoc at 94000000 {
+			reg = <0x0 0x94000000 0x03000000>;
+			no-map;
+		};
+
+		abl_reserved: abl at f8800000 {
+			reg = <0x0 0xf8800000 0x02000000>;
+			no-map;
+		};
+
+		dss_log_reserved: dss-log-reserved at fd3f0000 {
+			reg = <0x0 0xfd3f0000 0x0000e000>;
+			no-map;
+		};
+
+		debug_kinfo_reserved: debug-kinfo-reserved at fd3fe000 {
+			reg = <0x0 0xfd3fe000 0x00001000>;
+			no-map;
+		};
+
+		bldr_log_reserved: bldr-log-reserved at fd800000 {
+			reg = <0x0 0xfd800000 0x00100000>;
+			no-map;
+		};
+
+		bldr_log_hist_reserved: bldr-log-hist-reserved at fd900000 {
+			reg = <0x0 0xfd900000 0x00002000>;
+			no-map;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts =
+		   <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+		   <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+		   <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+		   <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>;
+		clock-frequency = <24576000>;
+	};
+
+	soc: soc at 0 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0x0 0x40000000>;
+
+		cmu_misc: clock-controller at 10010000 {
+			compatible = "google,gs101-cmu-misc";
+			reg = <0x10010000 0x8000>;
+			#clock-cells = <1>;
+			clocks =  <&cmu_top CLK_DOUT_CMU_MISC_BUS>,
+				  <&cmu_top CLK_DOUT_CMU_MISC_SSS>;
+			clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
+		};
+
+		watchdog_cl0: watchdog at 10060000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x10060000 0x100>;
+			interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks =
+			  <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0_PCLK>,
+			  <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <0>;
+			status = "disabled";
+		};
+
+		watchdog_cl1: watchdog at 10070000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x10070000 0x100>;
+			interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks =
+			  <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1_PCLK>,
+			  <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <1>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller at 10400000 {
+			compatible = "arm,gic-v3";
+			#interrupt-cells = <4>;
+			interrupt-controller;
+			reg = <0x10400000 0x10000>, /* GICD */
+			      <0x10440000 0x100000>;/* GICR * 8 */
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+
+			ppi-partitions {
+				ppi_cluster0: interrupt-partition-0 {
+					affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
+				};
+
+				ppi_cluster1: interrupt-partition-1 {
+					affinity = <&cpu4 &cpu5>;
+				};
+
+				ppi_cluster2: interrupt-partition-2 {
+					affinity = <&cpu6 &cpu7>;
+				};
+			};
+		};
+
+		sysreg_peric0: syscon at 10820000 {
+			compatible = "google,gs101-peric0-sysreg", "syscon";
+			reg = <0x10820000 0x10000>;
+		};
+
+		pinctrl_peric0: pinctrl at 10840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x10840000 0x00001000>;
+			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		usi_uart: usi at 10a000c0 {
+			compatible = "google,gs101-usi",
+				     "samsung,exynos850-usi";
+			reg = <0x10a000c0 0x20>;
+			samsung,sysreg = <&sysreg_peric0 0x1020>;
+			samsung,mode = <USI_V2_UART>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+			clocks = <&dummy_clk>, <&dummy_clk>;
+			clock-names = "pclk", "ipclk";
+			status = "disabled";
+
+			serial_0: serial at 10a00000 {
+				compatible = "google,gs101-uart";
+				reg = <0x10a00000 0xc0>;
+				reg-io-width = <4>;
+				samsung,uart-fifosize = <256>;
+				interrupts = <GIC_SPI 634
+					      IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
+				clock-names = "uart", "clk_uart_baud0";
+				status = "disabled";
+			};
+		};
+
+		sysreg_peric1: syscon at 10c20000 {
+			compatible = "google,gs101-peric1-sysreg", "syscon";
+			reg = <0x10c20000 0x10000>;
+		};
+
+		pinctrl_peric1: pinctrl at 10c40000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x10c40000 0x00001000>;
+			interrupts = <GIC_SPI 644 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		pinctrl_hsi1: pinctrl at 11840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x11840000 0x00001000>;
+			interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		pinctrl_hsi2: pinctrl at 14440000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x14440000 0x00001000>;
+			interrupts = <GIC_SPI 503 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		cmu_apm: clock-controller at 17400000 {
+			compatible = "google,gs101-cmu-apm";
+			reg = <0x17400000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+
+		sysreg_apm: syscon at 174204e0 {
+			compatible = "google,gs101-apm-sysreg", "syscon";
+			reg = <0x174204e0 0x1000>;
+		};
+
+		pmu_system_controller: system-controller at 17460000 {
+			compatible = "google,gs101-pmu", "syscon";
+			reg = <0x17460000 0x10000>;
+		};
+
+		pinctrl_gpio_alive: pinctrl at 174d0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x174d0000 0x00001000>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint",
+					     "samsung,exynos850-wakeup-eint",
+					     "samsung,exynos7-wakeup-eint";
+			};
+		};
+
+		pinctrl_far_alive: pinctrl at 174e0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x174e0000 0x00001000>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint",
+					     "samsung,exynos850-wakeup-eint",
+					     "samsung,exynos7-wakeup-eint";
+			};
+		};
+
+		pinctrl_gsactrl: pinctrl at 17940000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x17940000 0x00001000>;
+		};
+
+		pinctrl_gsacore: pinctrl at 17a80000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x17a80000 0x00001000>;
+		};
+
+		cmu_top: clock-controller at 1e080000 {
+			compatible = "google,gs101-cmu-top";
+			reg = <0x1e080000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+	};
+};
+
+#include "gs101-pinctrl.dtsi"
-- 
2.43.0.472.g3155946c3a-goog



From thiago.bauermann at linaro.org  Sat Dec  9 15:49:02 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Sat, 09 Dec 2023 20:49:02 -0300
Subject: [PATCH v7 26/39] arm64/ptrace: Expose GCS via ptrace and core
 files
In-Reply-To: <20231122-arm64-gcs-v7-26-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-26-201c483bd775@kernel.org>
Message-ID: <877clney35.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

> Provide a new register type NT_ARM_GCS reporting the current GCS mode
> and pointer for EL0.  Due to the interactions with allocation and
> deallocation of Guarded Control Stacks we do not permit any changes to
> the GCS mode via ptrace, only GCSPR_EL0 may be changed.

The code allows disabling GCS. Is that unintended?

> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  arch/arm64/include/uapi/asm/ptrace.h |  8 +++++
>  arch/arm64/kernel/ptrace.c           | 59 ++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/elf.h             |  1 +
>  3 files changed, 68 insertions(+)
>
> diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
> index 7fa2f7036aa7..0f39ba4f3efd 100644
> --- a/arch/arm64/include/uapi/asm/ptrace.h
> +++ b/arch/arm64/include/uapi/asm/ptrace.h
> @@ -324,6 +324,14 @@ struct user_za_header {
>  #define ZA_PT_SIZE(vq)						\
>  	(ZA_PT_ZA_OFFSET + ZA_PT_ZA_SIZE(vq))
>  
> +/* GCS state (NT_ARM_GCS) */
> +
> +struct user_gcs {
> +	__u64 features_enabled;
> +	__u64 features_locked;
> +	__u64 gcspr_el0;
> +};

If there's a reserved field in sigframe's gcs_context, isn't it worth it
to have a reserved field here as well?

> +
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* _UAPI__ASM_PTRACE_H */
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 20d7ef82de90..f15b8e33561e 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -33,6 +33,7 @@
>  #include <asm/cpufeature.h>
>  #include <asm/debug-monitors.h>
>  #include <asm/fpsimd.h>
> +#include <asm/gcs.h>
>  #include <asm/mte.h>
>  #include <asm/pointer_auth.h>
>  #include <asm/stacktrace.h>
> @@ -1409,6 +1410,51 @@ static int tagged_addr_ctrl_set(struct task_struct *target, const struct
>  }
>  #endif
>  
> +#ifdef CONFIG_ARM64_GCS
> +static int gcs_get(struct task_struct *target,
> +		   const struct user_regset *regset,
> +		   struct membuf to)
> +{
> +	struct user_gcs user_gcs;
> +
> +	if (target == current)
> +		gcs_preserve_current_state();
> +
> +	user_gcs.features_enabled = target->thread.gcs_el0_mode;
> +	user_gcs.features_locked = target->thread.gcs_el0_locked;
> +	user_gcs.gcspr_el0 = target->thread.gcspr_el0;
> +
> +	return membuf_write(&to, &user_gcs, sizeof(user_gcs));
> +}
> +
> +static int gcs_set(struct task_struct *target, const struct
> +		   user_regset *regset, unsigned int pos,
> +		   unsigned int count, const void *kbuf, const
> +		   void __user *ubuf)
> +{
> +	int ret;
> +	struct user_gcs user_gcs;
> +
> +	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &user_gcs, 0, -1);
> +	if (ret)
> +		return ret;
> +
> +	if (user_gcs.features_enabled & ~PR_SHADOW_STACK_SUPPORTED_STATUS_MASK)
> +		return -EINVAL;
> +
> +	/* Do not allow enable via ptrace */
> +	if ((user_gcs.features_enabled & PR_SHADOW_STACK_ENABLE) &&
> +	    !!(target->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE))

There should be only one '!' above.

Though contrary to the patch description, this code allows disabling
GCS. Shouldn't we require that

  (user_gcs.features_enabled & PR_SHADOW_STACK_ENABLE) ==
    (target->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE)

? That would ensure that the GCS mode can't be changed.

> +		return -EBUSY;
> +
> +	target->thread.gcs_el0_mode = user_gcs.features_enabled;
> +	target->thread.gcs_el0_locked = user_gcs.features_locked;
> +	target->thread.gcspr_el0 = user_gcs.gcspr_el0;
> +
> +	return 0;
> +}
> +#endif

-- 
Thiago


From luzmaximilian at gmail.com  Sat Dec  9 17:18:33 2023
From: luzmaximilian at gmail.com (Maximilian Luz)
Date: Sun, 10 Dec 2023 02:18:33 +0100
Subject: [PATCH v6 01/13] firmware: qcom: qseecom: fix memory leaks in
 error paths
In-Reply-To: <20231127141600.20929-2-brgl@bgdev.pl>
References: <20231127141600.20929-1-brgl@bgdev.pl>
 <20231127141600.20929-2-brgl@bgdev.pl>
Message-ID: <b9e70eae-dad5-4775-8def-596344cf3c8b@gmail.com>

On 11/27/23 15:15, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> 
> Fix instances of returning error codes directly instead of jumping to
> the relevant labels where memory allocated for the SCM calls would be
> freed.
> 
> Fixes: 759e7a2b62eb ("firmware: Add support for Qualcomm UEFI Secure Application")
> Reported-by: kernel test robot <lkp at intel.com>
> Reported-by: Dan Carpenter <error27 at gmail.com>
> Closes: https://lore.kernel.org/r/202311270828.k4HGcjiL-lkp at intel.com/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>

Thanks!

Reviewed-by: Maximilian Luz <luzmaximilian at gmail.com>

> ---
>   .../firmware/qcom/qcom_qseecom_uefisecapp.c   | 20 ++++++++++++-------
>   1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c b/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c
> index a33acdaf7b78..32188f098ef3 100644
> --- a/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c
> +++ b/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c
> @@ -325,8 +325,10 @@ static efi_status_t qsee_uefi_get_variable(struct qcuefi_client *qcuefi, const e
>   	req_data->length = req_size;
>   
>   	status = ucs2_strscpy(((void *)req_data) + req_data->name_offset, name, name_length);
> -	if (status < 0)
> -		return EFI_INVALID_PARAMETER;
> +	if (status < 0) {
> +		efi_status = EFI_INVALID_PARAMETER;
> +		goto out_free;
> +	}
>   
>   	memcpy(((void *)req_data) + req_data->guid_offset, guid, req_data->guid_size);
>   
> @@ -471,8 +473,10 @@ static efi_status_t qsee_uefi_set_variable(struct qcuefi_client *qcuefi, const e
>   	req_data->length = req_size;
>   
>   	status = ucs2_strscpy(((void *)req_data) + req_data->name_offset, name, name_length);
> -	if (status < 0)
> -		return EFI_INVALID_PARAMETER;
> +	if (status < 0) {
> +		efi_status = EFI_INVALID_PARAMETER;
> +		goto out_free;
> +	}
>   
>   	memcpy(((void *)req_data) + req_data->guid_offset, guid, req_data->guid_size);
>   
> @@ -563,8 +567,10 @@ static efi_status_t qsee_uefi_get_next_variable(struct qcuefi_client *qcuefi,
>   	memcpy(((void *)req_data) + req_data->guid_offset, guid, req_data->guid_size);
>   	status = ucs2_strscpy(((void *)req_data) + req_data->name_offset, name,
>   			      *name_size / sizeof(*name));
> -	if (status < 0)
> -		return EFI_INVALID_PARAMETER;
> +	if (status < 0) {
> +		efi_status = EFI_INVALID_PARAMETER;
> +		goto out_free;
> +	}
>   
>   	status = qcom_qseecom_app_send(qcuefi->client, req_data, req_size, rsp_data, rsp_size);
>   	if (status) {
> @@ -635,7 +641,7 @@ static efi_status_t qsee_uefi_get_next_variable(struct qcuefi_client *qcuefi,
>   		 * have already been validated above, causing this function to
>   		 * bail with EFI_BUFFER_TOO_SMALL.
>   		 */
> -		return EFI_DEVICE_ERROR;
> +		efi_status = EFI_DEVICE_ERROR;
>   	}
>   
>   out_free:


From dmitry.torokhov at gmail.com  Sat Dec  9 19:59:26 2023
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Sat, 9 Dec 2023 19:59:26 -0800
Subject: [PATCH v6 1/4] pwm: rename pwm_apply_state() to
 pwm_apply_might_sleep()
In-Reply-To: <37090c1d8d8f42f1e12fa84942027d995189a99e.1701248996.git.sean@mess.org>
References: <cover.1701248996.git.sean@mess.org>
 <37090c1d8d8f42f1e12fa84942027d995189a99e.1701248996.git.sean@mess.org>
Message-ID: <ZXU3nsNoQxXKUF4F@google.com>

On Wed, Nov 29, 2023 at 09:13:34AM +0000, Sean Young wrote:
>  drivers/input/misc/da7280.c                   |  4 +--
>  drivers/input/misc/pwm-beeper.c               |  4 +--
>  drivers/input/misc/pwm-vibra.c                |  8 +++---

Acked-by: Dmitry Torokhov <dmitry.torokhov at gmail.com> # for input

Thanks.

-- 
Dmitry


From lkp at intel.com  Sat Dec  9 20:18:36 2023
From: lkp at intel.com (kernel test robot)
Date: Sun, 10 Dec 2023 12:18:36 +0800
Subject: [V3, 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for
 74165b0
In-Reply-To: <20231209165816.39044-1-kamal.dasu@broadcom.com>
References: <20231209165816.39044-1-kamal.dasu@broadcom.com>
Message-ID: <202312101146.IK4Nrw1S-lkp@intel.com>

Hi Kamal,

kernel test robot noticed the following build warnings:

[auto build test WARNING on robh/for-next]
[also build test WARNING on soc/for-next linus/master v6.7-rc4 next-20231208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Kamal-Dasu/mmc-add-new-sdhci-reset-sequence-for-brcm-74165b0/20231210-010145
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/20231209165816.39044-1-kamal.dasu%40broadcom.com
patch subject: [V3, 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231210/202312101146.IK4Nrw1S-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312101146.IK4Nrw1S-lkp at intel.com/

dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml:25:1: [error] syntax error: found character '\t' that cannot start any token (syntax)
--
>> Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml:25:1: found a tab character that violates indentation
   Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml: properties:honeywell,pmin-pascal: '$ref' should not be valid under {'const': '$ref'}
   	hint: Standard unit suffix properties don't need a type $ref
   	from schema $id: http://devicetree.org/meta-schemas/core.yaml#
   Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml: properties:honeywell,pmax-pascal: '$ref' should not be valid under {'const': '$ref'}
   	hint: Standard unit suffix properties don't need a type $ref
   	from schema $id: http://devicetree.org/meta-schemas/core.yaml#
--
>> Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml: ignoring, error parsing file

vim +25 Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml

50c4ef6b8ab7d1 Florian Fainelli    2021-12-07   8  
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07   9  maintainers:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  10    - Al Cooper <alcooperx at gmail.com>
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  11    - Florian Fainelli <f.fainelli at gmail.com>
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  12  
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  13  properties:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  14    compatible:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  15      oneOf:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  16        - items:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  17            - enum:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  18                - brcm,bcm7216-sdhci
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  19            - const: brcm,bcm7445-sdhci
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  20            - const: brcm,sdhci-brcmstb
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  21        - items:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  22            - enum:
48e24385c58e80 Kamal Dasu          2023-12-09  23                - brcm,bcm74165b0-sdhci
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  24                - brcm,bcm7445-sdhci
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07 @25  	      - brcm,bcm7425-sdhci
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  26            - const: brcm,sdhci-brcmstb
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  27  
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  28    reg:
b16ebda6d00361 Krzysztof Kozlowski 2022-04-28  29      maxItems: 2
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  30  
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  31    reg-names:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  32      items:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  33        - const: host
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  34        - const: cfg
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  35  
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  36    interrupts:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  37      maxItems: 1
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  38  
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  39    clocks:
2f8690ef64128b Kamal Dasu          2022-05-20  40      minItems: 1
2f8690ef64128b Kamal Dasu          2022-05-20  41      items:
2f8690ef64128b Kamal Dasu          2022-05-20  42        - description: handle to core clock for the sdhci controller
2f8690ef64128b Kamal Dasu          2022-05-20  43        - description: handle to improved 150Mhz clock for sdhci controller (Optional clock)
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  44  
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  45    clock-names:
2f8690ef64128b Kamal Dasu          2022-05-20  46      minItems: 1
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  47      items:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  48        - const: sw_sdio
2f8690ef64128b Kamal Dasu          2022-05-20  49        - const: sdio_freq # Optional clock
2f8690ef64128b Kamal Dasu          2022-05-20  50  
2f8690ef64128b Kamal Dasu          2022-05-20  51    clock-frequency:
2f8690ef64128b Kamal Dasu          2022-05-20  52      description:
2f8690ef64128b Kamal Dasu          2022-05-20  53        Maximum operating frequency of sdio_freq sdhci controller clock
2f8690ef64128b Kamal Dasu          2022-05-20  54      $ref: /schemas/types.yaml#/definitions/uint32
2f8690ef64128b Kamal Dasu          2022-05-20  55      minimum: 100000000
2f8690ef64128b Kamal Dasu          2022-05-20  56      maximum: 150000000
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  57  
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  58    sdhci,auto-cmd12:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  59      type: boolean
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  60      description: Specifies that controller should use auto CMD12
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  61  
2f8690ef64128b Kamal Dasu          2022-05-20  62  allOf:
2f8690ef64128b Kamal Dasu          2022-05-20  63    - $ref: mmc-controller.yaml#
2f8690ef64128b Kamal Dasu          2022-05-20  64    - if:
2f8690ef64128b Kamal Dasu          2022-05-20  65        properties:
2f8690ef64128b Kamal Dasu          2022-05-20  66          clock-names:
2f8690ef64128b Kamal Dasu          2022-05-20  67            contains:
2f8690ef64128b Kamal Dasu          2022-05-20  68              const: sdio_freq
2f8690ef64128b Kamal Dasu          2022-05-20  69  
2f8690ef64128b Kamal Dasu          2022-05-20  70      then:
2f8690ef64128b Kamal Dasu          2022-05-20  71        required:
2f8690ef64128b Kamal Dasu          2022-05-20  72          - clock-frequency
2f8690ef64128b Kamal Dasu          2022-05-20  73  
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  74  required:
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  75    - compatible
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  76    - reg
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  77    - interrupts
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  78    - clocks
2f8690ef64128b Kamal Dasu          2022-05-20  79    - clock-names
50c4ef6b8ab7d1 Florian Fainelli    2021-12-07  80  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xu.yang_2 at nxp.com  Sat Dec  9 20:27:16 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Sun, 10 Dec 2023 04:27:16 +0000
Subject: [EXT] Re: [PATCH v2 1/4] dt-bindings: perf: fsl-imx-ddr: Add
 i.MX95 compatible
In-Reply-To: <20231208-depress-smuggler-f3069487a067@spud>
References: <20231208085402.2106904-1-xu.yang_2@nxp.com>
 <20231208-depress-smuggler-f3069487a067@spud>
Message-ID: <DB7PR04MB51468DB108F3003AF52CDDDA8C88A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Conor,

> On Fri, Dec 08, 2023 at 04:53:59PM +0800, Xu Yang wrote:
> > i.MX95 has a DDR pmu. This will add a compatible for it.
> 
> On v1 we had a discussion because the commit message wasn't clear about
> whether or not the device was compatible with existing ones. For some
> reason, the v2 patch _removes_ information from the commit message
> rather than tries to explain.
> This [1] message of yours, that I didn't get a chance to reply to before
> you sent this new version, seems to say that there should be an
> imx93-ddr-pmu fallback.

Thanks for your comments. 

Just read my previous comment in [1] and found I made a mistake.
Now I'll try to clarify it here.

Imx95 and imx93 have different AXI filter configuration. I need a 
compatible for imx95 since the driver cannot differentiate them. 

Then I need to consider below two options:
1. compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu"
2. compatible = "fsl,imx95-ddr-pmu"

Both of them work correctly on imx95. When I make changes in
driver for imx95, imx93 is not affected.

For basic functions, imx95 is compatible with imx93. I select the 2rd
form for simplicity. If the first form is optimal, I can change it in next
version.

Thanks,
Xu Yang

> 
> Cheers,
> Conor.
> 
> 1 -
> https://lore.kernel.org/all/DB7PR04MB514668A8B172CD1A2187BC408C84A at DB7PR04MB5146.eurprd04.prod.outlook.com/
> 
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> >
> > ---
> > Changes in v2:
> >  - no changes
> > ---
> >  Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml b/Documentation/devicetree/bindings/perf/fsl-imx-
> ddr.yaml
> > index e9fad4b3de68..1bc7bf1c8368 100644
> > --- a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
> > +++ b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
> > @@ -20,6 +20,7 @@ properties:
> >            - fsl,imx8mn-ddr-pmu
> >            - fsl,imx8mp-ddr-pmu
> >            - fsl,imx93-ddr-pmu
> > +          - fsl,imx95-ddr-pmu
> >        - items:
> >            - enum:
> >                - fsl,imx8mm-ddr-pmu
> > --
> > 2.34.1
> >


From jisheng.teoh at starfivetech.com  Sat Dec  9 21:20:17 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Sun, 10 Dec 2023 13:20:17 +0800
Subject: [PATCH v2] i2c: cadence: Add system suspend and resume PM support
In-Reply-To: <20231209205744.ehmthjvn7nuslvhd@zenone.zhora.eu>
References: <20231209205744.ehmthjvn7nuslvhd@zenone.zhora.eu>
Message-ID: <20231210052018.2063-1-jisheng.teoh@starfivetech.com>

On Sat, 9 Dec 2023 21:57:44 +0100
Andi Shyti <andi.shyti at kernel.org> wrote:

> Hi Ji Sheng,
>
> On Sat, Dec 09, 2023 at 09:15:16PM +0800, Ji Sheng Teoh wrote:
> > Enable device system suspend and resume PM support, and mark the
> > device state as suspended during system suspend to reject any data
> > transfer.
> >
> > Signed-off-by: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
> > ---
> > Changes since v1:
> > - Add missing err assignment in cdns_i2c_resume().
>
> thanks for the quick version update. However, while it's nice to
> see such prompt proactivity, we also need to allow more time for
> others to review your change.
>
> Next time, please give it a bit more time before sending out
> version 2. :-)
>

Thanks, will take note of that. 

> > ---
> >  drivers/i2c/busses/i2c-cadence.c | 33
> > ++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
> >
> > diff --git a/drivers/i2c/busses/i2c-cadence.c
> > b/drivers/i2c/busses/i2c-cadence.c index de3f58b60dce..4bb7d6756947
> > 100644 --- a/drivers/i2c/busses/i2c-cadence.c
> > +++ b/drivers/i2c/busses/i2c-cadence.c
> > @@ -1176,6 +1176,18 @@ static int __maybe_unused
> > cdns_i2c_runtime_suspend(struct device *dev) return 0;
> >  }
> >
> > +static int __maybe_unused cdns_i2c_suspend(struct device *dev)
> > +{
> > +	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
> > +
> > +	i2c_mark_adapter_suspended(&xi2c->adap);
> > +
> > +	if (!pm_runtime_status_suspended(dev))
> > +		return cdns_i2c_runtime_suspend(dev);
> > +
> > +	return 0;
> > +}
> > +
> >  /**
> >   * cdns_i2c_init -  Controller initialisation
> >   * @id:		Device private data structure
> > @@ -1219,7 +1231,28 @@ static int __maybe_unused
> > cdns_i2c_runtime_resume(struct device *dev) return 0;
> >  }
> >
> > +static int __maybe_unused cdns_i2c_resume(struct device *dev)
> > +{
>
> I am not really understanding what you are trying to do here:
>
> > +	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
> > +	int err;
> > +
> > +	err = cdns_i2c_runtime_resume(dev);
>
> First you try to resume...
>
> > +	if (err)
> > +		return err;
> > +
> > +	if (pm_runtime_status_suspended(dev)) {
>
> ... then you check if you are suspended ...

This serves as a check and balance to ensure that when the system
resumes with device in runtime suspend state, we disable the clock
enabled in earlier cdns_i2c_runtime_resume() to ensure a balanced clock
reference count for subsequent runtime resume transition.
Similar implementation can be found in this commit:
https://github.com/torvalds/linux/commit/44c99904cf61f945d02ac9976ab10dd5ccaea393

>
> > +		err = cdns_i2c_runtime_suspend(dev);
>
> ... and suspend again? Shouldn't this be _resume()?
>
> Thanks,
[O> Andi
>
> > +		if (err)
> > +			return err;
> > +	}
> > +
> > +	i2c_mark_adapter_resumed(&xi2c->adap);
> > +
> > +	return 0;
> > +}
> > +
> >  static const struct dev_pm_ops cdns_i2c_dev_pm_ops = {
> > +	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(cdns_i2c_suspend,
> > cdns_i2c_resume) SET_RUNTIME_PM_OPS(cdns_i2c_runtime_suspend,
> >  			   cdns_i2c_runtime_resume, NULL)
> >  };
> > --
> > 2.25.1
> >


From siyanteng at loongson.cn  Sat Dec  9 22:48:45 2023
From: siyanteng at loongson.cn (Yanteng Si)
Date: Sun, 10 Dec 2023 14:48:45 +0800
Subject: [RFT PATCH 1/2] stmmac: dwmac-loongson: drop useless check for
 compatible fallback
In-Reply-To: <20230616-activity-shed-be3c13e5ac71@spud>
References: <20230616103127.285608-1-krzysztof.kozlowski@linaro.org>
 <20230616-activity-shed-be3c13e5ac71@spud>
Message-ID: <93b41b72-a6ac-4d7f-95f0-ba42399729fc@loongson.cn>


? 2023/6/17 02:52, Conor Dooley ??:
> On Fri, Jun 16, 2023 at 12:31:26PM +0200, Krzysztof Kozlowski wrote:
>> Device binds to proper PCI ID (LOONGSON, 0x7a03), already listed in DTS,
>> so checking for some other compatible does not make sense.  It cannot be
>> bound to unsupported platform.
>>
>> Drop useless, incorrect (space in between) and undocumented compatible.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Might be worth noting that dropping it is required to allow the
> new loongarch dts stuff to be functional with a sane set of compatibles.
>
> Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
Thank you Krzysztof for your work. when I am
adding more devices support to stmmac, I found that your
two patches seemed to be forgotten.
Thomas, Jiaxun. Can the two patches get an Acked-by?
My stmmac patch thread:
<https://lore.kernel.org/loongarch/cover.1699533745.git 
.siyanteng at loongson.cn/T/#md3108d29a5efe71b27f4c5ccf5d0217571bf6586>
Thanks,
Yanteng

>
> Cheers,
> Conor.



From lkp at intel.com  Sat Dec  9 23:18:30 2023
From: lkp at intel.com (kernel test robot)
Date: Sun, 10 Dec 2023 15:18:30 +0800
Subject: [PATCH 3/5] arm64: dts: rockchip: Add support for rk3588s based
 board CoolPi 4B
In-Reply-To: <20231209103802.1568552-1-andyshrk@163.com>
References: <20231209103802.1568552-1-andyshrk@163.com>
Message-ID: <202312101526.ApwoImlf-lkp@intel.com>

Hi Andy,

kernel test robot noticed the following build errors:

[auto build test ERROR on rockchip/for-next]
[also build test ERROR on robh/for-next linus/master v6.7-rc4 next-20231208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Andy-Yan/dt-bindings-vendor-prefixes-Add-Cool-Pi/20231209-184214
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next
patch link:    https://lore.kernel.org/r/20231209103802.1568552-1-andyshrk%40163.com
patch subject: [PATCH 3/5] arm64: dts: rockchip: Add support for rk3588s based board CoolPi 4B
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20231210/202312101526.ApwoImlf-lkp at intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231210/202312101526.ApwoImlf-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312101526.ApwoImlf-lkp at intel.com/

All errors (new ones prefixed by >>):

>> Error: arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts:696.1-7 Label or path hdmi0 not found
   FATAL ERROR: Syntax error parsing input tree

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From andyshrk at 163.com  Sun Dec 10 00:03:13 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 10 Dec 2023 16:03:13 +0800
Subject: [PATCH v2 0/5] Add 2 rk3588 based boards from Cool Pi
Message-ID: <20231210080313.1667013-1-andyshrk@163.com>


This series add support for rk3588s based SBC Cool Pi 4B
and rk3588 based board Cool Pi CM5 EVB

Changes in v2:
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b" for
  Cool Pi 4B
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"
  for Cool Pi CM5 EVB
- drop ununnecessary property status = "okay" for gpio-led
- drop ununnecessary blank line
- change node name to rtc for hym8563

Andy Yan (5):
  dt-bindings: vendor-prefixes: Add Cool Pi
  dt-bindings: arm: rockchip: Add Cool Pi 4B
  arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B
  dt-bindings: arm: rockchip: Add Cool Pi CM5 EVB
  arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5
    EVB

 .../devicetree/bindings/arm/rockchip.yaml     |  10 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/rockchip/Makefile         |   2 +
 .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 887 ++++++++++++++++++
 .../boot/dts/rockchip/rk3588s-coolpi-4b.dts   | 840 +++++++++++++++++
 5 files changed, 1741 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts

-- 
2.34.1



From andyshrk at 163.com  Sun Dec 10 00:03:45 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 10 Dec 2023 16:03:45 +0800
Subject: [PATCH v2 1/5] dt-bindings: vendor-prefixes: Add Cool Pi
In-Reply-To: <20231210080313.1667013-1-andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
Message-ID: <20231210080345.1667161-1-andyshrk@163.com>

Add vendor prefix for Cool Pi(https://cool-pi.com/)

Signed-off-by: Andy Yan <andyshrk at 163.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

(no changes since v1)

 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c8..ddbba46fcbad 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -294,6 +294,8 @@ patternProperties:
     description: CompuLab Ltd.
   "^congatec,.*":
     description: congatec GmbH
+  "^coolpi,.*":
+    description: cool-pi.com
   "^coreriver,.*":
     description: CORERIVER Semiconductor Co.,Ltd.
   "^corpro,.*":
-- 
2.34.1



From andyshrk at 163.com  Sun Dec 10 00:04:11 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 10 Dec 2023 16:04:11 +0800
Subject: [PATCH v2 2/5] dt-bindings: arm: rockchip: Add Cool Pi 4B
In-Reply-To: <20231210080313.1667013-1-andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
Message-ID: <20231210080411.1667229-1-andyshrk@163.com>

Add Cool Pi 4B, a SBC powered by RK3588S

Signed-off-by: Andy Yan <andyshrk at 163.com>

---

Changes in v2:
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b"

 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5deb66a5c7d9..11d03035f3db 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -95,6 +95,11 @@ properties:
           - const: chipspark,rayeager-px2
           - const: rockchip,rk3066a
 
+      - description: Cool Pi 4 Model B
+        items:
+          - const: coolpi,pi-4b
+          - const: rockchip,rk3588s
+
       - description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
         items:
           - const: edgeble,neural-compute-module-2-io   # Edgeble Neural Compute Module 2 IO Board
-- 
2.34.1



From andyshrk at 163.com  Sun Dec 10 00:05:47 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 10 Dec 2023 16:05:47 +0800
Subject: [PATCH v2 3/5] arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B
In-Reply-To: <20231210080313.1667013-1-andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
Message-ID: <20231210080547.1667421-1-andyshrk@163.com>

CoolPi 4B is a rk3588s based SBC.
Specification:
- Rockchip RK3588S
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- Gigabit ethernet drived by PCIE with RTL8111HS
- HDMI Type D out
- Mini DP out
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- WIFI/BT module AIC8800
- 40 pin header

Signed-off-by: Andy Yan <andyshrk at 163.com>

---

Changes in v2:
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b"
- drop ununnecessary property status = "okay" for gpio-led
- drop ununnecessary blank line
- drop hdmi dt node to avoid compile error
- change node name to rtc for hym8563

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3588s-coolpi-4b.dts   | 840 ++++++++++++++++++
 2 files changed, 841 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 41276ca535de..e59682691eb0 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -109,6 +109,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-orangepi-5-plus.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-quartzpro64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-turing-rk1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-coolpi-4b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
new file mode 100644
index 000000000000..7c7575544eae
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
@@ -0,0 +1,840 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ * https://cool-pi.com/topic/130/coolpi-4b-product-spec-introduction
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3588s.dtsi"
+
+/ {
+	model = "RK3588S CoolPi 4 Model B";
+	compatible = "coolpi,pi-4b", "rockchip,rk3588s";
+
+	aliases {
+		mmc0 = &sdhci;
+		mmc1 = &sdio;
+		mmc2 = &sdmmc;
+		serial2 = &uart2;
+	};
+
+	analog-sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
+
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+
+		dais = <&i2s0_8ch_p0>;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl- = <&gpio_leds>;
+
+		led0: led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led1: led-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_WLAN;
+			gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "phy0tx";
+			default-state = "off";
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&hym8563>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_h>;
+		/*
+		 * On the module itself this is one of these (depending
+		 * on the actual card populated):
+		 * - SDIO_RESET_L_WL_REG_ON
+		 * - PDN (power down when low)
+		 */
+		post-power-on-delay-ms = <200>;
+		reset-gpios = <&gpio0 RK_PC7 GPIO_ACTIVE_LOW>;
+	};
+
+	vcc12v_dcin: vcc12v-dcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usbdcin: vcc5v0-usbdcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usbdcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usbdcin>;
+	};
+
+	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v85_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <850000>;
+		regulator-max-microvolt = <850000>;
+		vin-supply = <&vdd_0v85_s0>;
+	};
+
+	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd1v8_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	vcc3v3_mipi: vcc3v3-mipi-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_mipi";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_otg: vcc5v0-otg-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_otg";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_u3host_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2s0_8ch {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
+		};
+	};
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	status = "okay";
+};
+
+&sdio {
+	max-frequency = <150000000>;
+	no-sd;
+	no-mmc;
+	bus-width = <4>;
+	disable-wp;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdiom1_pins>,<&wifi_poweren_gpio>;
+	status = "okay";
+};
+
+&sdmmc {
+	max-frequency = <150000000>;
+	no-sdio;
+	no-mmc;
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	num-cs = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	status = "okay";
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		reg = <0x0>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		spi-max-frequency = <1000000>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-name = "vdd_gpu_s0";
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-name = "vdd_cpu_lit_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-name = "vdd_log_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-name = "vdd_vdenc_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-name = "vdd_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-name = "vdd2_ddr_s3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-name = "vdd_2v0_pldo_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-name = "vcc_3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-name = "vddq_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-name = "vcc_1v8_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-name = "avcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-name = "vcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-name = "avdd_1v2_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-name = "vcc_3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-name = "vccio_sd_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-name = "pldo6_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-name = "vdd_0v75_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-name = "vdd_ddr_pll_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-name = "avdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-name = "vdd_0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-name = "vdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&u2phy3_host {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&i2c6 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c6m3_xfer>;
+	status = "okay";
+
+	hym8563: rtc at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hym8563_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+		status = "okay";
+	};
+};
+
+&i2c7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c7m0_xfer>;
+	status = "okay";
+
+	es8316: audio-codec at 11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		#sound-dai-cells = <0>;
+
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
+		};
+	};
+
+};
+
+&pcie2x1l1 {
+	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+	status = "disabled";
+};
+
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	rockchip,skip-scan-in-resume;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rtl8111_isolate>;
+	status = "okay";
+};
+
+&pwm2 {
+	pinctrl-0 = <&pwm2m1_pins>;
+	status = "okay";
+};
+
+&pwm11 {
+	pinctrl-0 = <&pwm11m1_pins>;
+	status = "disabled";
+};
+
+&pwm13 {
+	status = "okay";
+	pinctrl-names = "active";
+	pinctrl-0 = <&pwm13m2_pins>;
+};
+
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+//bt
+&uart9 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn>;
+};
+
+&pinctrl {
+	hym8563 {
+		hym8563_int: hym8563-int {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	rtl8111 {
+		rtl8111_isolate: rtl8111-isolate {
+			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	led {
+		gpio_leds: gpio-leds {
+			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>,
+					<0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	usb {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins = <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>,
+					<4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		vcc5v0_u3host_en: vcc5v0-u3host-en {
+			rockchip,pins = <3 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sdio-pwrseq {
+		wifi_enable_h: wifi-enable-h {
+			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	wireless-bluetooth {
+		uart9_gpios: uart9-gpios {
+			rockchip,pins = <3 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_reset_gpio: bt-reset-gpio {
+			rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_gpio: bt-wake-gpio {
+			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_host_irq: bt-wake-host-irq {
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	wireless-wlan {
+		wifi_host_wake_irq: wifi-host-wake-irq {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		wifi_poweren_gpio: wifi-poweren-gpio {
+			rockchip,pins = <1 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
-- 
2.34.1



From andyshrk at 163.com  Sun Dec 10 00:06:07 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 10 Dec 2023 16:06:07 +0800
Subject: [PATCH v2 4/5] dt-bindings: arm: rockchip: Add Cool Pi CM5 EVB
In-Reply-To: <20231210080313.1667013-1-andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
Message-ID: <20231210080607.1667517-1-andyshrk@163.com>

Add Cool Pi CM5 EVB, a board powered by RK3588

Signed-off-by: Andy Yan <andyshrk at 163.com>

---

Changes in v2:
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"

 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 11d03035f3db..4da83bbd642a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -95,6 +95,11 @@ properties:
           - const: chipspark,rayeager-px2
           - const: rockchip,rk3066a
 
+      - description: Cool Pi Compute Module 5(CM5) EVB
+        items:
+          - const: coolpi,pi-cm5-evb
+          - const: rockchip,rk3588
+
       - description: Cool Pi 4 Model B
         items:
           - const: coolpi,pi-4b
-- 
2.34.1



From andyshrk at 163.com  Sun Dec 10 00:06:29 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 10 Dec 2023 16:06:29 +0800
Subject: [PATCH v2 5/5] arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5 EVB
In-Reply-To: <20231210080313.1667013-1-andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
Message-ID: <20231210080629.1667589-1-andyshrk@163.com>

Cool Pi CM5 EVB is a board based on rk3588.

Specification:
- Rockchip RK3588
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- Gigabit ethernet x 1 with PHY YT8531
- Gigabit ethernet x 1 drived by PCIE with YT6801S
- HDMI Type A out x 2
- HDMI Type D in x 1
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- PCIE M.2 E Key for Wireless connection
- PCIE M.2 M Key for NVME connection
- 40 pin header

Signed-off-by: Andy Yan <andyshrk at 163.com>

---

Changes in v2:
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 887 ++++++++++++++++++
 2 files changed, 888 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index e59682691eb0..9be8e4830158 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-odroid-m1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-radxa-e25.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-roc-pc.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-coolpi-cm5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6b-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
new file mode 100644
index 000000000000..367a7d25d7cf
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
@@ -0,0 +1,887 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3588.dtsi"
+
+/ {
+	model = "RK3588 CoolPi CM5 EVB";
+	compatible = "coolpi,pi-cm5-evb", "rockchip,rk3588";
+
+	aliases {
+		mmc0 = &sdhci;
+		mmc1 = &sdio;
+		mmc2 = &sdmmc;
+		serial2 = &uart2;
+	};
+
+	analog-sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
+
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+
+		dais = <&i2s0_8ch_p0>;
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		power-supply = <&vcc12v_dcin>;
+		pwms = <&pwm2 0 25000 0>;
+		enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bl_en>;
+		status = "okay";
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	leds: leds {
+		status = "okay";
+		compatible = "gpio-leds";
+
+		led: led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	vcc12v_dcin: vcc12v-dcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_lcd: vcc3v3-lcd-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd";
+		enable-active-high;
+		gpio = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&lcdpwr_en>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v85_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <850000>;
+		regulator-max-microvolt = <850000>;
+		vin-supply = <&vdd_0v85_s0>;
+	};
+
+	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd1v8_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	avdd0v75_pcie30: avdd0v75-pcie30-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v75_pcie30";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <750000>;
+		regulator-max-microvolt = <750000>;
+		vin-supply = <&avdd_0v75_s0>;
+	};
+
+	pcie30_avdd1v8: avdd1v8-pcie30-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd1v8";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host1_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_otg: vcc5v0-otg-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_otg";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&typec5v_pwren>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_mipidphy0: vcc-mipi-dphy0-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_mipidphy0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_sys>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&cam_en>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy1_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	status = "okay";
+};
+
+&sdmmc {
+	max-frequency = <150000000>;
+	no-sdio;
+	no-mmc;
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&u2phy3_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&gmac0 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-rxid";
+	pinctrl-0 = <&gmac0_miim
+		     &gmac0_tx_bus2
+		     &gmac0_rx_bus2
+		     &gmac0_rgmii_clk
+		     &gmac0_rgmii_bus>;
+	pinctrl-names = "default";
+	rx_delay = <0x00>;
+	tx_delay = <0x43>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c6 {
+	status = "okay";
+
+	hym8563: rtc at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hym8563_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PD4 IRQ_TYPE_LEVEL_LOW>;
+		wakeup-source;
+	};
+};
+
+&i2c7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c7m0_xfer>;
+	status = "okay";
+
+	es8316: audio-codec at 11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		#sound-dai-cells = <0>;
+
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
+		};
+	};
+};
+
+&i2s0_8ch {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
+		};
+	};
+};
+
+&mdio0 {
+	rgmii_phy: ethernet-phy at 1 {
+		/* YT8531C/H */
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&yt8531_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pcie30phy {
+	status = "okay";
+};
+
+//ethernet
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rtl8111_isolate>;
+	status = "okay";
+};
+
+//wifi
+&pcie2x1l1 {
+	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie_clkreq &pcie_wake &pcie_rst &wifi_pwron &bt_pwron>;
+	status = "okay";
+};
+
+&sata1 {
+	status = "okay";
+};
+
+//ssd
+&pcie3x4 {
+	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	status = "okay";
+};
+
+//express
+&pcie3x2 {
+	reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	status = "okay";
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&spi2 {
+	status = "okay";
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	num-cs = <1>;
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		spi-max-frequency = <1000000>;
+		reg = <0x0>;
+
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_2v0_pldo_s3>;
+		vcc14-supply = <&vcc_2v0_pldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_lit_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_log_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_vdenc_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vdd2_ddr_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_2v0_pldo_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vddq_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "avcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "avdd_1v2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vcc_3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vccio_sd_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "pldo6_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_ddr_pll_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "avdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_0v85_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&uart2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart2m0_xfer>;
+};
+
+&pinctrl {
+	hym8563 {
+		hym8563_int: hym8563-int {
+			rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	rtl8111 {
+		rtl8111_isolate: rtl8111-isolate {
+			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	rtl8211f {
+		yt8531_rst: yt8531-rst {
+			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		vcc5v0_host1_en: vcc5v0-host1-en {
+			rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb-typec {
+		typec5v_pwren: typec5v-pwren {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	hdmi {
+		hdmirx_det: hdmirx-det {
+			rockchip,pins = <2 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	wifi {
+		pcie_rst: pcie-rst {
+			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+		pcie_clkreq: pcie-clkreq {
+			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+		pcie_wake: pcie-wake {
+			rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+		wifi_pwron: wifi-pwron {
+			rockchip,pins = <3 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+		bt_pwron: bt-pwron {
+			rockchip,pins = <3 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	lcd {
+		lcdpwr_en: lcdpwr-en {
+			rockchip,pins = <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+		bl_en: bl-en {
+			rockchip,pins = <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	cam {
+		cam_en: cam-en {
+			rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+	};
+};
-- 
2.34.1



From i.pear at outlook.com  Sun Dec 10 00:07:42 2023
From: i.pear at outlook.com (Tianyi Liu)
Date: Sun, 10 Dec 2023 16:07:42 +0800
Subject: [PATCH v3 0/5] perf: KVM: Enable callchains for guests
Message-ID: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>

This series of patches enables callchains for guests (used by `perf kvm`),
which holds the top spot on the perf wiki TODO list [1]. This allows users
to perform guest OS callchain or performance analysis from external
using PMU events. This is also useful for guests like unikernels that
lack performance event subsystems.

The event processing flow is as follows (shown as backtrace):
@0 kvm_arch_vcpu_get_unwind_info / kvm_arch_vcpu_read_virt (per arch impl)
@1 kvm_guest_get_unwind_info / kvm_guest_read_virt
   <callback function pointers in `struct perf_guest_info_callbacks`>
@2 perf_guest_get_unwind_info / perf_guest_read_virt
@3 perf_callchain_guest
@4 get_perf_callchain
@5 perf_callchain

Between @0 and @1 is the interface between KVM and the arch-specific
impl, while between @1 and @2 is the interface between Perf and KVM.
The 1st patch implements @0. The 2nd patch extends interfaces between @1
and @2, while the 3rd patch implements @1. The 4th patch implements @3
and modifies @4 @5. The last patch is for userspace tools.

Since arm64 hasn't provided some foundational infrastructure (interface
for reading from a virtual address of guest), the arm64 implementation
is stubbed for now because it's a bit complex, and will be implemented
later.

For safety, guests are designed to be read-only in this feature,
and we will never inject page faults into the guests, ensuring that the
guests are not interfered by profiling. In extremely rare cases, if the
guest is modifying the page table, there is a possibility of reading
incorrect data. Additionally, if certain programs running in the guest OS
do not support frame pointers, it may also result in some erroneous data.
These erroneous data will eventually appear as `[unknown]` entries in the
report. It is sufficient as long as most of the records are correct for
profiling.

Regarding the necessity of implementing in the kernel:
Indeed, we could implement this in userspace and access the guest vm
through the KVM APIs, to interrupt the guest and perform unwinding.
However, this approach will introduce higher latency, and the overhead of
syscalls could limit the sampling frequency. Moreover, it appears that
user space can only interrupt the VCPU at a certain frequency, without
fully leveraging the richness of the PMU's performance events. On the
other hand, if we incorporate the logic into kernel, `perf kvm` can bind
to various PMU events and achieve faster performance in PMU interrupts.

Tested with both Linux and unikernels as guests, the `perf script` command
could correctly show the callchains.
FlameGraphs could also be generated with this series of patches and [2].

[1] https://perf.wiki.kernel.org/index.php/Todo
[2] https://github.com/brendangregg/FlameGraph

v1:
https://lore.kernel.org/kvm/SYYP282MB108686A73C0F896D90D246569DE5A at SYYP282MB1086.AUSP282.PROD.OUTLOOK.COM/

Changes since v1:
Post the complete implementation, also updated some code based on
Sean's feedback.

v2:
https://lore.kernel.org/kvm/SY4P282MB1084ECBCC1B176153B9E2A009DCFA at SY4P282MB1084.AUSP282.PROD.OUTLOOK.COM/

Changes since v2:
Refactored interface, packaged the info required by unwinding into
a struct; Resolved some type mismatches; Provided more explanations
based on the feedback from v2; more tests were performed.

Tianyi Liu (5):
  KVM: Add arch specific interfaces for sampling guest callchains
  perf kvm: Introduce guest interfaces for sampling callchains
  KVM: implement new perf callback interfaces
  perf kvm: Support sampling guest callchains
  perf tools: Support PERF_CONTEXT_GUEST_* flags

 MAINTAINERS                         |  1 +
 arch/arm64/kvm/arm.c                | 12 ++++++
 arch/x86/events/core.c              | 63 ++++++++++++++++++++++++-----
 arch/x86/kvm/x86.c                  | 24 +++++++++++
 include/linux/kvm_host.h            |  5 +++
 include/linux/perf_event.h          | 20 ++++++++-
 include/linux/perf_kvm.h            | 18 +++++++++
 kernel/bpf/stackmap.c               |  8 ++--
 kernel/events/callchain.c           | 27 ++++++++++++-
 kernel/events/core.c                | 17 +++++++-
 tools/perf/builtin-timechart.c      |  6 +++
 tools/perf/util/data-convert-json.c |  6 +++
 tools/perf/util/machine.c           |  6 +++
 virt/kvm/kvm_main.c                 | 22 ++++++++++
 14 files changed, 218 insertions(+), 17 deletions(-)
 create mode 100644 include/linux/perf_kvm.h


base-commit: 33cc938e65a98f1d29d0a18403dbbee050dcad9a
-- 
2.34.1



From i.pear at outlook.com  Sun Dec 10 00:12:18 2023
From: i.pear at outlook.com (Tianyi Liu)
Date: Sun, 10 Dec 2023 16:12:18 +0800
Subject: [PATCH v3 1/5] KVM: Add arch specific interfaces for sampling guest callchains
In-Reply-To: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
References: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
Message-ID: <SYBPR01MB6870FDFBB88F879C735198F39D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>

This patch adds two architecture specific interfaces used by `perf kvm`:

- kvm_arch_vcpu_get_unwind_info: Return required data for unwinding
  at once; including ip address, frame pointer, whether the guest vCPU
  is running in 32 or 64 bits, and possibly the base addresses of
  the segments.

- kvm_arch_vcpu_read_virt: Read data from a virtual address of the
  guest vm.

`perf_kvm.h` has been added to the `include/linux/` directory to store
the interface structures between the perf events subsystem and the KVM
subsystem.

Since arm64 hasn't provided some foundational infrastructure, stub the
arm64 implementation for now because it's a bit complex.

The above interfaces require architecture support for
`CONFIG_GUEST_PERF_EVENTS`, which is only implemented by x86 and arm64
currently. For more architectures, they need to implement these interfaces
when enabling `CONFIG_GUEST_PERF_EVENTS`.

In terms of safety, guests are designed to be read-only in this feature,
and we will never inject page faults into the guests, ensuring that the
guests are not interfered by profiling. In extremely rare cases, if the
guest is modifying the page table, there is a possibility of reading
incorrect data. Additionally, if certain programs running in the guest OS
do not support frame pointers, it may also result in some erroneous data.
These erroneous data will eventually appear as `[unknown]` entries in the
report. It is sufficient as long as most of the records are correct for
profiling.

Signed-off-by: Tianyi Liu <i.pear at outlook.com>
---
 MAINTAINERS              |  1 +
 arch/arm64/kvm/arm.c     | 12 ++++++++++++
 arch/x86/kvm/x86.c       | 24 ++++++++++++++++++++++++
 include/linux/kvm_host.h |  5 +++++
 include/linux/perf_kvm.h | 18 ++++++++++++++++++
 5 files changed, 60 insertions(+)
 create mode 100644 include/linux/perf_kvm.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 788be9ab5b73..5ee36b4a9701 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16976,6 +16976,7 @@ F:	arch/*/kernel/*/perf_event*.c
 F:	arch/*/kernel/perf_callchain.c
 F:	arch/*/kernel/perf_event*.c
 F:	include/linux/perf_event.h
+F:	include/linux/perf_kvm.h
 F:	include/uapi/linux/perf_event.h
 F:	kernel/events/*
 F:	tools/lib/perf/
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index e5f75f1f1085..5ae74b5c263a 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -574,6 +574,18 @@ unsigned long kvm_arch_vcpu_get_ip(struct kvm_vcpu *vcpu)
 {
 	return *vcpu_pc(vcpu);
 }
+
+bool kvm_arch_vcpu_get_unwind_info(struct kvm_vcpu *vcpu, struct perf_kvm_guest_unwind_info *info)
+{
+	/* TODO: implement */
+	return false;
+}
+
+bool kvm_arch_vcpu_read_virt(struct kvm_vcpu *vcpu, gva_t addr, void *dest, unsigned int length)
+{
+	/* TODO: implement */
+	return false;
+}
 #endif
 
 static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2c924075f6f1..9341cd80f665 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -13039,6 +13039,30 @@ unsigned long kvm_arch_vcpu_get_ip(struct kvm_vcpu *vcpu)
 	return kvm_rip_read(vcpu);
 }
 
+bool kvm_arch_vcpu_get_unwind_info(struct kvm_vcpu *vcpu, struct perf_kvm_guest_unwind_info *info)
+{
+	info->ip_pointer = kvm_rip_read(vcpu);
+	info->frame_pointer = kvm_register_read_raw(vcpu, VCPU_REGS_RBP);
+
+	info->is_guest_64bit = is_64_bit_mode(vcpu);
+	if (info->is_guest_64bit) {
+		info->segment_cs_base = 0;
+		info->segment_ss_base = 0;
+	} else {
+		info->segment_cs_base = get_segment_base(vcpu, VCPU_SREG_CS);
+		info->segment_ss_base = get_segment_base(vcpu, VCPU_SREG_SS);
+	}
+	return true;
+}
+
+bool kvm_arch_vcpu_read_virt(struct kvm_vcpu *vcpu, gva_t addr, void *dest, unsigned int length)
+{
+	struct x86_exception e;
+
+	/* Return true on success */
+	return kvm_read_guest_virt(vcpu, addr, dest, length, &e) == X86EMUL_CONTINUE;
+}
+
 int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
 {
 	return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 4944136efaa2..6f5ff4209b0c 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -41,6 +41,7 @@
 #include <linux/kvm_para.h>
 
 #include <linux/kvm_types.h>
+#include <linux/perf_kvm.h>
 
 #include <asm/kvm_host.h>
 #include <linux/kvm_dirty_ring.h>
@@ -1595,6 +1596,10 @@ static inline bool kvm_arch_intc_initialized(struct kvm *kvm)
 
 #ifdef CONFIG_GUEST_PERF_EVENTS
 unsigned long kvm_arch_vcpu_get_ip(struct kvm_vcpu *vcpu);
+bool kvm_arch_vcpu_get_unwind_info(struct kvm_vcpu *vcpu,
+				   struct perf_kvm_guest_unwind_info *info);
+bool kvm_arch_vcpu_read_virt(struct kvm_vcpu *vcpu, gva_t addr, void *dest,
+			     unsigned int length);
 
 void kvm_register_perf_callbacks(unsigned int (*pt_intr_handler)(void));
 void kvm_unregister_perf_callbacks(void);
diff --git a/include/linux/perf_kvm.h b/include/linux/perf_kvm.h
new file mode 100644
index 000000000000..e77eeebddabb
--- /dev/null
+++ b/include/linux/perf_kvm.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_PERF_KVM_H
+#define _LINUX_PERF_KVM_H
+
+/*
+ * Structures as interface between Perf Event and KVM subsystem.
+ * Add more members for new architectures if necessary.
+ */
+
+struct perf_kvm_guest_unwind_info {
+	unsigned long ip_pointer;
+	unsigned long frame_pointer;
+	bool is_guest_64bit;
+	unsigned long segment_cs_base;
+	unsigned long segment_ss_base;
+};
+
+#endif /* _LINUX_PERF_KVM_H */
-- 
2.34.1



From i.pear at outlook.com  Sun Dec 10 00:14:52 2023
From: i.pear at outlook.com (Tianyi Liu)
Date: Sun, 10 Dec 2023 16:14:52 +0800
Subject: [PATCH v3 2/5] perf kvm: Introduce guest interfaces for sampling callchains
In-Reply-To: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
References: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
Message-ID: <SYBPR01MB68706FAC3D66758BB4951F5D9D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>

This patch introduces two callback interfaces used between perf and KVM:

- get_unwind_info: Return required data for unwinding at once; including
  ip address, frame pointer, whether the guest vCPU is running in 32 or 64
  bits, and possibly the base addresses of the segments.

- read_virt: Read data from a virtual address of the guest vm, used for
  reading the stack frames from the guest.

Signed-off-by: Tianyi Liu <i.pear at outlook.com>
---
 include/linux/perf_event.h | 17 +++++++++++++++++
 kernel/events/core.c       | 10 ++++++++++
 2 files changed, 27 insertions(+)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 5547ba68e6e4..dacc1623dcaa 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -17,6 +17,8 @@
 #include <uapi/linux/perf_event.h>
 #include <uapi/linux/bpf_perf_event.h>
 
+#include <linux/perf_kvm.h>
+
 /*
  * Kernel-internal data types and definitions:
  */
@@ -32,6 +34,9 @@
 struct perf_guest_info_callbacks {
 	unsigned int			(*state)(void);
 	unsigned long			(*get_ip)(void);
+	bool				(*get_unwind_info)(struct perf_kvm_guest_unwind_info *info);
+	bool				(*read_virt)(unsigned long addr, void *dest,
+						     unsigned int len);
 	unsigned int			(*handle_intel_pt_intr)(void);
 };
 
@@ -1500,6 +1505,8 @@ extern struct perf_guest_info_callbacks __rcu *perf_guest_cbs;
 
 DECLARE_STATIC_CALL(__perf_guest_state, *perf_guest_cbs->state);
 DECLARE_STATIC_CALL(__perf_guest_get_ip, *perf_guest_cbs->get_ip);
+DECLARE_STATIC_CALL(__perf_guest_get_unwind_info, *perf_guest_cbs->get_unwind_info);
+DECLARE_STATIC_CALL(__perf_guest_read_virt, *perf_guest_cbs->read_virt);
 DECLARE_STATIC_CALL(__perf_guest_handle_intel_pt_intr, *perf_guest_cbs->handle_intel_pt_intr);
 
 static inline unsigned int perf_guest_state(void)
@@ -1510,6 +1517,14 @@ static inline unsigned long perf_guest_get_ip(void)
 {
 	return static_call(__perf_guest_get_ip)();
 }
+static inline bool perf_guest_get_unwind_info(struct perf_kvm_guest_unwind_info *info)
+{
+	return static_call(__perf_guest_get_unwind_info)(info);
+}
+static inline bool perf_guest_read_virt(unsigned long addr, void *dest, unsigned int length)
+{
+	return static_call(__perf_guest_read_virt)(addr, dest, length);
+}
 static inline unsigned int perf_guest_handle_intel_pt_intr(void)
 {
 	return static_call(__perf_guest_handle_intel_pt_intr)();
@@ -1519,6 +1534,8 @@ extern void perf_unregister_guest_info_callbacks(struct perf_guest_info_callback
 #else
 static inline unsigned int perf_guest_state(void)		 { return 0; }
 static inline unsigned long perf_guest_get_ip(void)		 { return 0; }
+static inline bool perf_guest_get_unwind_info(struct perf_kvm_guest_unwind_info *) { return 0; }
+static inline bool perf_guest_read_virt(unsigned long, void*, unsigned int)	   { return 0; }
 static inline unsigned int perf_guest_handle_intel_pt_intr(void) { return 0; }
 #endif /* CONFIG_GUEST_PERF_EVENTS */
 
diff --git a/kernel/events/core.c b/kernel/events/core.c
index b704d83a28b2..4c5e35006217 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6807,6 +6807,8 @@ struct perf_guest_info_callbacks __rcu *perf_guest_cbs;
 
 DEFINE_STATIC_CALL_RET0(__perf_guest_state, *perf_guest_cbs->state);
 DEFINE_STATIC_CALL_RET0(__perf_guest_get_ip, *perf_guest_cbs->get_ip);
+DEFINE_STATIC_CALL_RET0(__perf_guest_get_unwind_info, *perf_guest_cbs->get_unwind_info);
+DEFINE_STATIC_CALL_RET0(__perf_guest_read_virt, *perf_guest_cbs->read_virt);
 DEFINE_STATIC_CALL_RET0(__perf_guest_handle_intel_pt_intr, *perf_guest_cbs->handle_intel_pt_intr);
 
 void perf_register_guest_info_callbacks(struct perf_guest_info_callbacks *cbs)
@@ -6818,6 +6820,12 @@ void perf_register_guest_info_callbacks(struct perf_guest_info_callbacks *cbs)
 	static_call_update(__perf_guest_state, cbs->state);
 	static_call_update(__perf_guest_get_ip, cbs->get_ip);
 
+	if (cbs->get_unwind_info)
+		static_call_update(__perf_guest_get_unwind_info, cbs->get_unwind_info);
+
+	if (cbs->read_virt)
+		static_call_update(__perf_guest_read_virt, cbs->read_virt);
+
 	/* Implementing ->handle_intel_pt_intr is optional. */
 	if (cbs->handle_intel_pt_intr)
 		static_call_update(__perf_guest_handle_intel_pt_intr,
@@ -6833,6 +6841,8 @@ void perf_unregister_guest_info_callbacks(struct perf_guest_info_callbacks *cbs)
 	rcu_assign_pointer(perf_guest_cbs, NULL);
 	static_call_update(__perf_guest_state, (void *)&__static_call_return0);
 	static_call_update(__perf_guest_get_ip, (void *)&__static_call_return0);
+	static_call_update(__perf_guest_get_unwind_info, (void *)&__static_call_return0);
+	static_call_update(__perf_guest_read_virt, (void *)&__static_call_return0);
 	static_call_update(__perf_guest_handle_intel_pt_intr,
 			   (void *)&__static_call_return0);
 	synchronize_rcu();
-- 
2.34.1



From i.pear at outlook.com  Sun Dec 10 00:15:24 2023
From: i.pear at outlook.com (Tianyi Liu)
Date: Sun, 10 Dec 2023 16:15:24 +0800
Subject: [PATCH v3 3/5] KVM: implement new perf callback interfaces
In-Reply-To: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
References: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
Message-ID: <SYBPR01MB68709E1FE3A5056577AAA82F9D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>

This patch provides two KVM implementations for the following two new perf
interfaces, just redirecting them to the arch-specific implementations:

- get_unwind_info
- read_virt

Signed-off-by: Tianyi Liu <i.pear at outlook.com>
---
 virt/kvm/kvm_main.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 486800a7024b..c47b6c0f8e94 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -6032,9 +6032,31 @@ static unsigned long kvm_guest_get_ip(void)
 	return kvm_arch_vcpu_get_ip(vcpu);
 }
 
+static bool kvm_guest_get_unwind_info(struct perf_kvm_guest_unwind_info *info)
+{
+	struct kvm_vcpu *vcpu = kvm_get_running_vcpu();
+
+	if (WARN_ON_ONCE(!kvm_arch_pmi_in_guest(vcpu)))
+		return false;
+
+	return kvm_arch_vcpu_get_unwind_info(vcpu, info);
+}
+
+static bool kvm_guest_read_virt(unsigned long addr, void *dest, unsigned int length)
+{
+	struct kvm_vcpu *vcpu = kvm_get_running_vcpu();
+
+	if (WARN_ON_ONCE(!kvm_arch_pmi_in_guest(vcpu)))
+		return false;
+
+	return kvm_arch_vcpu_read_virt(vcpu, addr, dest, length);
+}
+
 static struct perf_guest_info_callbacks kvm_guest_cbs = {
 	.state			= kvm_guest_state,
 	.get_ip			= kvm_guest_get_ip,
+	.get_unwind_info	= kvm_guest_get_unwind_info,
+	.read_virt		= kvm_guest_read_virt,
 	.handle_intel_pt_intr	= NULL,
 };
 
-- 
2.34.1



From i.pear at outlook.com  Sun Dec 10 00:15:48 2023
From: i.pear at outlook.com (Tianyi Liu)
Date: Sun, 10 Dec 2023 16:15:48 +0800
Subject: [PATCH v3 4/5] perf kvm: Support sampling guest callchains
In-Reply-To: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
References: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
Message-ID: <SYBPR01MB687083237B0E5C03B63EDAB99D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>

This patch provides support for sampling guests' callchains.

The signature of `get_perf_callchain` has been modified to explicitly
specify whether it needs to sample the host or guest callchain. Based on
the context, `get_perf_callchain` will distribute each sampling request
to one of `perf_callchain_user`, `perf_callchain_kernel`,
or `perf_callchain_guest`.

The reason for separately implementing `perf_callchain_user` and
`perf_callchain_kernel` is that the kernel may utilize special unwinders
like `ORC`. However, for the guest, we only support stackframe-based
unwinding, so the implementation is generic and only needs to be
separately implemented for 32-bit and 64-bit.

Signed-off-by: Tianyi Liu <i.pear at outlook.com>
---
 arch/x86/events/core.c     | 63 ++++++++++++++++++++++++++++++++------
 include/linux/perf_event.h |  3 +-
 kernel/bpf/stackmap.c      |  8 ++---
 kernel/events/callchain.c  | 27 +++++++++++++++-
 kernel/events/core.c       |  7 ++++-
 5 files changed, 91 insertions(+), 17 deletions(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 40ad1425ffa2..4ff412225217 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2758,11 +2758,6 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re
 	struct unwind_state state;
 	unsigned long addr;
 
-	if (perf_guest_state()) {
-		/* TODO: We don't support guest os callchain now */
-		return;
-	}
-
 	if (perf_callchain_store(entry, regs->ip))
 		return;
 
@@ -2778,6 +2773,59 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re
 	}
 }
 
+static inline void
+perf_callchain_guest32(struct perf_callchain_entry_ctx *entry,
+		       const struct perf_kvm_guest_unwind_info *unwind_info)
+{
+	unsigned long ss_base, cs_base;
+	struct stack_frame_ia32 frame;
+	const struct stack_frame_ia32 *fp;
+
+	cs_base = unwind_info->segment_cs_base;
+	ss_base = unwind_info->segment_ss_base;
+
+	fp = (void *)(ss_base + unwind_info->frame_pointer);
+	while (fp && entry->nr < entry->max_stack) {
+		if (!perf_guest_read_virt((unsigned long)&fp->next_frame,
+					  &frame.next_frame, sizeof(frame.next_frame)))
+			break;
+		if (!perf_guest_read_virt((unsigned long)&fp->return_address,
+					  &frame.return_address, sizeof(frame.return_address)))
+			break;
+		perf_callchain_store(entry, cs_base + frame.return_address);
+		fp = (void *)(ss_base + frame.next_frame);
+	}
+}
+
+void
+perf_callchain_guest(struct perf_callchain_entry_ctx *entry)
+{
+	struct stack_frame frame;
+	const struct stack_frame *fp;
+	struct perf_kvm_guest_unwind_info unwind_info;
+
+	if (!perf_guest_get_unwind_info(&unwind_info))
+		return;
+
+	perf_callchain_store(entry, unwind_info.ip_pointer);
+
+	if (unwind_info.is_guest_64bit) {
+		fp = (void *)unwind_info.frame_pointer;
+		while (fp && entry->nr < entry->max_stack) {
+			if (!perf_guest_read_virt((unsigned long)&fp->next_frame,
+				&frame.next_frame, sizeof(frame.next_frame)))
+				break;
+			if (!perf_guest_read_virt((unsigned long)&fp->return_address,
+				&frame.return_address, sizeof(frame.return_address)))
+				break;
+			perf_callchain_store(entry, frame.return_address);
+			fp = (void *)frame.next_frame;
+		}
+	} else {
+		perf_callchain_guest32(entry, &unwind_info);
+	}
+}
+
 static inline int
 valid_user_frame(const void __user *fp, unsigned long size)
 {
@@ -2861,11 +2909,6 @@ perf_callchain_user(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs
 	struct stack_frame frame;
 	const struct stack_frame __user *fp;
 
-	if (perf_guest_state()) {
-		/* TODO: We don't support guest os callchain now */
-		return;
-	}
-
 	/*
 	 * We don't know what to do with VM86 stacks.. ignore them for now.
 	 */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index dacc1623dcaa..483578672868 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1552,9 +1552,10 @@ DECLARE_PER_CPU(struct perf_callchain_entry, perf_callchain_entry);
 
 extern void perf_callchain_user(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs);
 extern void perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs);
+extern void perf_callchain_guest(struct perf_callchain_entry_ctx *entry);
 extern struct perf_callchain_entry *
 get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
-		   u32 max_stack, bool crosstask, bool add_mark);
+		   bool host, bool guest, u32 max_stack, bool crosstask, bool add_mark);
 extern int get_callchain_buffers(int max_stack);
 extern void put_callchain_buffers(void);
 extern struct perf_callchain_entry *get_callchain_entry(int *rctx);
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index d6b277482085..5ca41ca08d8a 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -294,8 +294,8 @@ BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
 	if (max_depth > sysctl_perf_event_max_stack)
 		max_depth = sysctl_perf_event_max_stack;
 
-	trace = get_perf_callchain(regs, 0, kernel, user, max_depth,
-				   false, false);
+	trace = get_perf_callchain(regs, 0, kernel, user, true, false,
+				   max_depth, false, false);
 
 	if (unlikely(!trace))
 		/* couldn't fetch the stack trace */
@@ -420,8 +420,8 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
 	else if (kernel && task)
 		trace = get_callchain_entry_for_task(task, max_depth);
 	else
-		trace = get_perf_callchain(regs, 0, kernel, user, max_depth,
-					   false, false);
+		trace = get_perf_callchain(regs, 0, kernel, user, true, false,
+					   max_depth, false, false);
 	if (unlikely(!trace))
 		goto err_fault;
 
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index 1273be84392c..7e80729e95d0 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -45,6 +45,10 @@ __weak void perf_callchain_user(struct perf_callchain_entry_ctx *entry,
 {
 }
 
+__weak void perf_callchain_guest(struct perf_callchain_entry_ctx *entry)
+{
+}
+
 static void release_callchain_buffers_rcu(struct rcu_head *head)
 {
 	struct callchain_cpus_entries *entries;
@@ -178,11 +182,12 @@ put_callchain_entry(int rctx)
 
 struct perf_callchain_entry *
 get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
-		   u32 max_stack, bool crosstask, bool add_mark)
+		   bool host, bool guest, u32 max_stack, bool crosstask, bool add_mark)
 {
 	struct perf_callchain_entry *entry;
 	struct perf_callchain_entry_ctx ctx;
 	int rctx;
+	unsigned int guest_state;
 
 	entry = get_callchain_entry(&rctx);
 	if (!entry)
@@ -194,6 +199,26 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
 	ctx.contexts       = 0;
 	ctx.contexts_maxed = false;
 
+	guest_state = perf_guest_state();
+	if (guest_state) {
+		if (!guest)
+			goto exit_put;
+		if (user && (guest_state & PERF_GUEST_USER)) {
+			if (add_mark)
+				perf_callchain_store_context(&ctx, PERF_CONTEXT_GUEST_USER);
+			perf_callchain_guest(&ctx);
+		}
+		if (kernel && !(guest_state & PERF_GUEST_USER)) {
+			if (add_mark)
+				perf_callchain_store_context(&ctx, PERF_CONTEXT_GUEST_KERNEL);
+			perf_callchain_guest(&ctx);
+		}
+		goto exit_put;
+	}
+
+	if (unlikely(!host))
+		goto exit_put;
+
 	if (kernel && !user_mode(regs)) {
 		if (add_mark)
 			perf_callchain_store_context(&ctx, PERF_CONTEXT_KERNEL);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4c5e35006217..3dea3fe840e6 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7607,6 +7607,8 @@ perf_callchain(struct perf_event *event, struct pt_regs *regs)
 {
 	bool kernel = !event->attr.exclude_callchain_kernel;
 	bool user   = !event->attr.exclude_callchain_user;
+	bool host   = !event->attr.exclude_host;
+	bool guest  = !event->attr.exclude_guest;
 	/* Disallow cross-task user callchains. */
 	bool crosstask = event->ctx->task && event->ctx->task != current;
 	const u32 max_stack = event->attr.sample_max_stack;
@@ -7615,7 +7617,10 @@ perf_callchain(struct perf_event *event, struct pt_regs *regs)
 	if (!kernel && !user)
 		return &__empty_callchain;
 
-	callchain = get_perf_callchain(regs, 0, kernel, user,
+	if (!host && !guest)
+		return &__empty_callchain;
+
+	callchain = get_perf_callchain(regs, 0, kernel, user, host, guest,
 				       max_stack, crosstask, true);
 	return callchain ?: &__empty_callchain;
 }
-- 
2.34.1



From i.pear at outlook.com  Sun Dec 10 00:16:14 2023
From: i.pear at outlook.com (Tianyi Liu)
Date: Sun, 10 Dec 2023 16:16:14 +0800
Subject: [PATCH v3 5/5] perf tools: Support PERF_CONTEXT_GUEST_* flags
In-Reply-To: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
References: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
Message-ID: <SYBPR01MB68703FCDA8424EC486BB208E9D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>

The `perf` util currently has an incomplete implementation for the
following event flags. Events with these flags will be dropped
or be identified as unknown types:

`PERF_CONTEXT_GUEST_KERNEL`
`PERF_CONTEXT_GUEST_USER`

This patch makes `perf script`, `perf timechart` and `perf data` to
correctly identify these flags.

Signed-off-by: Tianyi Liu <i.pear at outlook.com>
---
 tools/perf/builtin-timechart.c      | 6 ++++++
 tools/perf/util/data-convert-json.c | 6 ++++++
 tools/perf/util/machine.c           | 6 ++++++
 3 files changed, 18 insertions(+)

diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 19d4542ea18a..6a368b6a323e 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -536,6 +536,12 @@ static const char *cat_backtrace(union perf_event *event,
 			case PERF_CONTEXT_USER:
 				cpumode = PERF_RECORD_MISC_USER;
 				break;
+			case PERF_CONTEXT_GUEST_KERNEL:
+				cpumode = PERF_RECORD_MISC_GUEST_KERNEL;
+				break;
+			case PERF_CONTEXT_GUEST_USER:
+				cpumode = PERF_RECORD_MISC_GUEST_USER;
+				break;
 			default:
 				pr_debug("invalid callchain context: "
 					 "%"PRId64"\n", (s64) ip);
diff --git a/tools/perf/util/data-convert-json.c b/tools/perf/util/data-convert-json.c
index 5bb3c2ba95ca..62686f78d973 100644
--- a/tools/perf/util/data-convert-json.c
+++ b/tools/perf/util/data-convert-json.c
@@ -205,6 +205,12 @@ static int process_sample_event(struct perf_tool *tool,
 				case PERF_CONTEXT_USER:
 					cpumode = PERF_RECORD_MISC_USER;
 					break;
+				case PERF_CONTEXT_GUEST_KERNEL:
+					cpumode = PERF_RECORD_MISC_GUEST_KERNEL;
+					break;
+				case PERF_CONTEXT_GUEST_USER:
+					cpumode = PERF_RECORD_MISC_GUEST_USER;
+					break;
 				default:
 					pr_debug("invalid callchain context: %"
 							PRId64 "\n", (s64) ip);
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 90c750150b19..28eac11d0f61 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2343,6 +2343,12 @@ static int add_callchain_ip(struct thread *thread,
 			case PERF_CONTEXT_USER:
 				*cpumode = PERF_RECORD_MISC_USER;
 				break;
+			case PERF_CONTEXT_GUEST_KERNEL:
+				*cpumode = PERF_RECORD_MISC_GUEST_KERNEL;
+				break;
+			case PERF_CONTEXT_GUEST_USER:
+				*cpumode = PERF_RECORD_MISC_GUEST_USER;
+				break;
 			default:
 				pr_debug("invalid callchain context: "
 					 "%"PRId64"\n", (s64) ip);
-- 
2.34.1



From Chunfeng.Yun at mediatek.com  Sun Dec 10 01:09:45 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Sun, 10 Dec 2023 09:09:45 +0000
Subject: [PATCH 1/2] dt-bindings: phy: mediatek: tphy: add a property for
 force-mode switch
In-Reply-To: <50e56220-8068-4e2e-a586-9d0474963085@linaro.org>
References: <20231125012303.760-1-chunfeng.yun@mediatek.com>
	 <e34c2746-8e93-48b8-9c96-690242fbf6e9@linaro.org>
	 <239def9b-437b-9211-7844-af4332651df0@mediatek.com>
	 <0dc24d82-e09d-45bc-98ae-1dfb6318cb96@linaro.org>
	 <74957a9cc4663815e200d222483541a1eec43bbe.camel@mediatek.com>
	 <50e56220-8068-4e2e-a586-9d0474963085@linaro.org>
Message-ID: <853a37c17a84a50866345481f4fd48ba82aa2b27.camel@mediatek.com>

On Thu, 2023-11-30 at 09:03 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 30/11/2023 02:51, Chunfeng Yun (???) wrote:
> >>> 3. How about we revise the description as follows for more
> >> precisely?
> >>>
> >>> mediatek,force-mode:
> >>>    description:
> >>>      The force mode is used to manually switch the shared PHY
> mode
> >>>      between USB and PCIe. When force-mode is set, the USB 3.0
> mode
> >>>      will be selected. This is typically required for older SoCs
> >>>      that do not automatically manage PHY mode switching.
> >>>      For newer SoCs that support it, it is preferable to use the
> >>>      "mediatek,syscon-type" property instead.
> >>>    type: boolean
> >>
> >> Again, what is force-mode? 
> > Our DE describe this behavior as force-mode, as you see, the driver
> 
> What is "DE"?
Hardware designer

> 
> > power down controller and reset pipe to set the mode directly we
> want,
> 
> So force-mode is driver behavior?
hardware supported, need software to set some registers

> 
> > but usually the phy controller switch to the mode automatically
> > according to the external signal, e.g. trapping pin, efuse etc.
> > 
> >> It looks like you wrote bindings for the
> >> driver behavior. Bindings describe hardware, not how the driver
> >> should
> >> behave. The property might be reasonable, but you must describe
> here
> >> hardware characteristics/issue/etc.
> 
> You must address this, in such case.
OK, I'll modify the description

Thanks

> 
> 
> 
> Best regards,
> Krzysztof
> 

From biju.das.jz at bp.renesas.com  Sun Dec 10 01:49:54 2023
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Sun, 10 Dec 2023 09:49:54 +0000
Subject: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
In-Reply-To: <CAMuHMdXHpE079eLAJjcdsbz6=Y6hux267AhqJow6HESCaf7EXQ@mail.gmail.com>
References: <20231201110840.37408-1-biju.das.jz@bp.renesas.com>
 <20231201110840.37408-7-biju.das.jz@bp.renesas.com>
 <CAMuHMdWh3fTzQP5+mGF3u8LACg-5tQDZcyExvgREpxKd6iee4Q@mail.gmail.com>
 <TYCPR01MB112696C301D750A915F2661688681A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <CAMuHMdXHpE079eLAJjcdsbz6=Y6hux267AhqJow6HESCaf7EXQ@mail.gmail.com>
Message-ID: <TYCPR01MB112693C2B72B6AA28766FF8EA8688A@TYCPR01MB11269.jpnprd01.prod.outlook.com>

Hi Geert Uytterhoeven,

Thanks for the feedback.

> -----Original Message-----
> From: Geert Uytterhoeven <geert at linux-m68k.org>
> Sent: Friday, December 1, 2023 3:42 PM
> Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
> 
> Hi Biju,
> 
> On Fri, Dec 1, 2023 at 4:02?PM Biju Das <biju.das.jz at bp.renesas.com>
> wrote:
> > > From: Geert Uytterhoeven <geert at linux-m68k.org> On Fri, Dec 1, 2023
> > > at 12:09?PM Biju Das <biju.das.jz at bp.renesas.com>
> > > wrote:
> > > > Enable the config for the Renesas DA9062 PMIC and RTC, as it is
> > > > populated on RZ/G2UL SMARC EVK.
> > > >
> > > > Signed-off-by: Biju Das <biju.das.jz at bp.renesas.com>
> > >
> > > Thanks for your patch!
> > >
> > > LGTM, but I would have expected (at least)
> > >
> > >     CONFIG_INPUT_DA9063_ONKEY=m
> > >
> > > too, cfr. my comments on patch 5/6.
> >
> > I have tested this, but I get "da9063-onkey da9062-onkey: error -ENXIO:
> IRQ ONKEY not found"
> > So, I won't be able to test onkey events. So plaaning to disable this
> node.
> 
> Indeed, currently drivers/input/misc/da9063_onkey.c requires an interrupt
> to function.  I wonder if it can be made to work using a timer and pure
> polling...

Yes, that is possible by either adding a debugfs to enable polling for testing.

Or 

a device tree property for adding poll delay, so that one can have polling support to test onkey driver.

Basically, on a production system we should avoid polling as it unnecessarily wakeup the system.

Please share your thoughts on this.

Cheers,
Biju



From krzysztof.kozlowski at linaro.org  Sun Dec 10 03:10:58 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 12:10:58 +0100
Subject: [PATCH v2 2/5] dt-bindings: arm: rockchip: Add Cool Pi 4B
In-Reply-To: <20231210080411.1667229-1-andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
 <20231210080411.1667229-1-andyshrk@163.com>
Message-ID: <e8e3843f-310b-4135-abcf-d5ad2306ad4b@linaro.org>

On 10/12/2023 09:04, Andy Yan wrote:
> Add Cool Pi 4B, a SBC powered by RK3588S
> 
> Signed-off-by: Andy Yan <andyshrk at 163.com>
> 
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 03:11:33 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 12:11:33 +0100
Subject: [PATCH v2 4/5] dt-bindings: arm: rockchip: Add Cool Pi CM5 EVB
In-Reply-To: <20231210080607.1667517-1-andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
 <20231210080607.1667517-1-andyshrk@163.com>
Message-ID: <6eb1541b-430b-41cf-b297-ebb3d47f5278@linaro.org>

On 10/12/2023 09:06, Andy Yan wrote:
> Add Cool Pi CM5 EVB, a board powered by RK3588
> 
> Signed-off-by: Andy Yan <andyshrk at 163.com>
> 
> ---
> 
> Changes in v2:
> - change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"
> 
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 11d03035f3db..4da83bbd642a 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -95,6 +95,11 @@ properties:
>            - const: chipspark,rayeager-px2
>            - const: rockchip,rk3066a
>  
> +      - description: Cool Pi Compute Module 5(CM5) EVB
> +        items:
> +          - const: coolpi,pi-cm5-evb

If it is module you are maybe missing here module DTSI and compatible.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 03:12:15 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 12:12:15 +0100
Subject: [PATCH v2 5/5] arm64: dts: rockchip: Add support for rk3588 based
 board Cool Pi CM5 EVB
In-Reply-To: <20231210080629.1667589-1-andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
 <20231210080629.1667589-1-andyshrk@163.com>
Message-ID: <2b58450a-1bde-424b-ab69-a3834914522c@linaro.org>

On 10/12/2023 09:06, Andy Yan wrote:
> Cool Pi CM5 EVB is a board based on rk3588.
> 
> Specification:
> - Rockchip RK3588
> - LPDDR4 2/4/8/16 GB
> - TF scard slot
> - eMMC 8/32/64/128 GB module
> - Gigabit ethernet x 1 with PHY YT8531
> - Gigabit ethernet x 1 drived by PCIE with YT6801S
> - HDMI Type A out x 2
> - HDMI Type D in x 1
> - USB 2.0 Host x 2
> - USB 3.0 OTG x 1
> - USB 3.0 Host x 1
> - PCIE M.2 E Key for Wireless connection
> - PCIE M.2 M Key for NVME connection
> - 40 pin header


> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		power-supply = <&vcc12v_dcin>;
> +		pwms = <&pwm2 0 25000 0>;
> +		enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bl_en>;
> +		status = "okay";

This is a friendly reminder during the review process.

It seems my or other reviewer's previous comments were not fully
addressed. Maybe the feedback got lost between the quotes, maybe you
just forgot to apply it. Please go back to the previous discussion and
either implement all requested changes or keep discussing them.

Thank you.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 03:13:26 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 12:13:26 +0100
Subject: [PATCH v2 3/5] arm64: dts: rockchip: Add support for rk3588s
 based board Cool Pi 4B
In-Reply-To: <20231210080547.1667421-1-andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
 <20231210080547.1667421-1-andyshrk@163.com>
Message-ID: <32b6437f-0e56-439d-8ebb-465e5230b18f@linaro.org>

On 10/12/2023 09:05, Andy Yan wrote:
> CoolPi 4B is a rk3588s based SBC.
> Specification:
> - Rockchip RK3588S
> - LPDDR4 2/4/8/16 GB
> - TF scard slot

...

> +&i2c6 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c6m3_xfer>;
> +	status = "okay";
> +
> +	hym8563: rtc at 51 {
> +		compatible = "haoyu,hym8563";
> +		reg = <0x51>;
> +		#clock-cells = <0>;
> +		clock-frequency = <32768>;
> +		clock-output-names = "hym8563";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&hym8563_int>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
> +		status = "okay";

My comments about redundant statues applies to all places, not only to
one specific place...

Best regards,
Krzysztof



From andi.shyti at kernel.org  Sun Dec 10 03:54:12 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Sun, 10 Dec 2023 12:54:12 +0100
Subject: [PATCH v2] i2c: cadence: Add system suspend and resume PM support
In-Reply-To: <20231210052018.2063-1-jisheng.teoh@starfivetech.com>
References: <20231209205744.ehmthjvn7nuslvhd@zenone.zhora.eu>
 <20231210052018.2063-1-jisheng.teoh@starfivetech.com>
Message-ID: <20231210115412.hztjrubacnmenbvz@zenone.zhora.eu>

Hi Ji Sheng,

[...]

> > > +static int __maybe_unused cdns_i2c_resume(struct device *dev)
> > > +{
> >
> > I am not really understanding what you are trying to do here:
> >
> > > +	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
> > > +	int err;
> > > +
> > > +	err = cdns_i2c_runtime_resume(dev);
> >
> > First you try to resume...
> >
> > > +	if (err)
> > > +		return err;
> > > +
> > > +	if (pm_runtime_status_suspended(dev)) {
> >
> > ... then you check if you are suspended ...
> 
> This serves as a check and balance to ensure that when the system
> resumes with device in runtime suspend state, we disable the clock
> enabled in earlier cdns_i2c_runtime_resume() to ensure a balanced clock
> reference count for subsequent runtime resume transition.
> Similar implementation can be found in this commit:
> https://github.com/torvalds/linux/commit/44c99904cf61f945d02ac9976ab10dd5ccaea393

OK, this is done purely for clock balancing, but then, I still
don't understand the case. I expect the clock counter to be
unbalanced when you suspend (because is moving towards '0').

While, if you check if the clock is unbalanced when resuming, it
means that the clock had a negative counter (which is impossible
because the clock counter is unsigned).

If there is any unbalancing at this stage, then I recommend you
to check what has happened previously.

... Or is there anything I am missing?

Thanks,
Andi

> > > +		err = cdns_i2c_runtime_suspend(dev);
> >
> > ... and suspend again? Shouldn't this be _resume()?
> >
> > Thanks,
> [O> Andi
> >
> > > +		if (err)
> > > +			return err;
> > > +	}
> > > +
> > > +	i2c_mark_adapter_resumed(&xi2c->adap);
> > > +
> > > +	return 0;
> > > +}


From maz at kernel.org  Sun Dec 10 04:16:32 2023
From: maz at kernel.org (Marc Zyngier)
Date: Sun, 10 Dec 2023 12:16:32 +0000
Subject: [PATCH v3 1/5] KVM: Add arch specific interfaces for sampling guest callchains
In-Reply-To: <SYBPR01MB6870FDFBB88F879C735198F39D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
References: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
	<SYBPR01MB6870FDFBB88F879C735198F39D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
Message-ID: <865y16b6cf.wl-maz@kernel.org>

On Sun, 10 Dec 2023 08:12:18 +0000,
Tianyi Liu <i.pear at outlook.com> wrote:
> 
> This patch adds two architecture specific interfaces used by `perf kvm`:
> 
> - kvm_arch_vcpu_get_unwind_info: Return required data for unwinding
>   at once; including ip address, frame pointer, whether the guest vCPU
>   is running in 32 or 64 bits, and possibly the base addresses of
>   the segments.
> 
> - kvm_arch_vcpu_read_virt: Read data from a virtual address of the
>   guest vm.
> 
> `perf_kvm.h` has been added to the `include/linux/` directory to store
> the interface structures between the perf events subsystem and the KVM
> subsystem.
> 
> Since arm64 hasn't provided some foundational infrastructure, stub the
> arm64 implementation for now because it's a bit complex.

It's not complex. It is *unsafe*. Do you see the difference?

> 
> The above interfaces require architecture support for
> `CONFIG_GUEST_PERF_EVENTS`, which is only implemented by x86 and arm64
> currently. For more architectures, they need to implement these interfaces
> when enabling `CONFIG_GUEST_PERF_EVENTS`.
> 
> In terms of safety, guests are designed to be read-only in this feature,
> and we will never inject page faults into the guests, ensuring that the
> guests are not interfered by profiling. In extremely rare cases, if the
> guest is modifying the page table, there is a possibility of reading
> incorrect data. Additionally, if certain programs running in the guest OS
> do not support frame pointers, it may also result in some erroneous data.
> These erroneous data will eventually appear as `[unknown]` entries in the
> report. It is sufficient as long as most of the records are correct for
> profiling.
> 
> Signed-off-by: Tianyi Liu <i.pear at outlook.com>
> ---
>  MAINTAINERS              |  1 +
>  arch/arm64/kvm/arm.c     | 12 ++++++++++++
>  arch/x86/kvm/x86.c       | 24 ++++++++++++++++++++++++
>  include/linux/kvm_host.h |  5 +++++
>  include/linux/perf_kvm.h | 18 ++++++++++++++++++
>  5 files changed, 60 insertions(+)
>  create mode 100644 include/linux/perf_kvm.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 788be9ab5b73..5ee36b4a9701 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16976,6 +16976,7 @@ F:	arch/*/kernel/*/perf_event*.c
>  F:	arch/*/kernel/perf_callchain.c
>  F:	arch/*/kernel/perf_event*.c
>  F:	include/linux/perf_event.h
> +F:	include/linux/perf_kvm.h
>  F:	include/uapi/linux/perf_event.h
>  F:	kernel/events/*
>  F:	tools/lib/perf/
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index e5f75f1f1085..5ae74b5c263a 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -574,6 +574,18 @@ unsigned long kvm_arch_vcpu_get_ip(struct kvm_vcpu *vcpu)
>  {
>  	return *vcpu_pc(vcpu);
>  }
> +
> +bool kvm_arch_vcpu_get_unwind_info(struct kvm_vcpu *vcpu, struct perf_kvm_guest_unwind_info *info)
> +{
> +	/* TODO: implement */
> +	return false;
> +}
> +
> +bool kvm_arch_vcpu_read_virt(struct kvm_vcpu *vcpu, gva_t addr, void *dest, unsigned int length)
> +{
> +	/* TODO: implement */
> +	return false;
> +}

I don't do it very often, but the only thing I can say about this is
*NAK*.

You have decided to ignore the previous review comments, which is your
prerogative. However, I absolutely refuse to add half baked and
*dangerous* stuff to the arm64's version of KVM.

If you can convince the x86 folks that they absolutely want this, fine
by me. But this need to be a buy-in interface, not something that is
required for each and every architecture to have stubs, wrongly
suggesting that extra work is needed.

For arm64, the way to go is to have this in userspace. Which is both
easy to implement and safe. And until we have such a userspace
implementation as a baseline, I will not consider a kernel
version.

	M.

-- 
Without deviation from the norm, progress is not possible.


From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:00:42 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:00:42 +0100
Subject: [PATCH v3 3/4] pinctrl: samsung: support ExynosAuto GPIO
 structure
In-Reply-To: <20231208074527.50840-4-jaewon02.kim@samsung.com>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
 <CGME20231208075020epcas2p260c65fa8d33e0cd97806f065bb8a044d@epcas2p2.samsung.com>
 <20231208074527.50840-4-jaewon02.kim@samsung.com>
Message-ID: <421ede4c-7a96-47e0-9b82-0eb350b59c33@linaro.org>

On 08/12/2023 08:45, Jaewon Kim wrote:
> New ExynosAuto series GPIO have a different register structure.
> In the existing Exynos series, EINT control register enumerated after
> a specific offset (e.g EXYNOS_GPIO_ECON_OFFSET, EXYNOS_GPIO_EMASK_OFFSET).
> However, from ExynosAutov920 SoC, the register that controls EINT belongs
> to each GPIO bank, and each GPIO bank has 0x1000 align.
> 
> This is a structure to protect the GPIO bank using S2MPU in VM environment,
> and will only be applied in ExynosAuto series SoCs.
> 
> -------------------------------------------------
> | original		| ExynosAutov920	|
> |-----------------------------------------------|
> | 0x0	GPIO_CON	| 0x0	GPIO_CON	|
> | 0x4	GPIO_DAT	| 0x4	GPIO_DAT	|
> | 0x8	GPIO_PUD	| 0x8	GPIO_PUD	|
> | 0xc	GPIO_DRV	| 0xc	GPIO_DRV	|
> | 0x10	GPIO_CONPDN	| 0x10	GPIO_CONPDN	|
> | 0x14	GPIO_PUDPDN	| 0x14	GPIO_PUDPDN	|
> | 0x700	EINT_CON	| 0x18	EINT_CON	|
> | 0x800	EINT_FLTCON	| 0x1c	EINT_FLTCON0	|
> | 0x900	EINT_MASK	| 0x20	EINT_FLTCON1	|
> | 0xa00	EINT_PEND	| 0x24	EINT_MASK	|
> |			| 0x28	EINT_PEND	|
> -------------------------------------------------
> 
> Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
> ---
>  drivers/pinctrl/samsung/pinctrl-exynos.c  | 81 +++++++++++++++++++++--
>  drivers/pinctrl/samsung/pinctrl-exynos.h  |  1 +
>  drivers/pinctrl/samsung/pinctrl-samsung.c |  3 +
>  drivers/pinctrl/samsung/pinctrl-samsung.h | 12 ++++
>  4 files changed, 90 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index 6b58ec84e34b..f798f64b1122 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -56,6 +56,9 @@ static void exynos_irq_mask(struct irq_data *irqd)
>  	unsigned int mask;
>  	unsigned long flags;
>  
> +	if (bank->eint_mask_offset)
> +		reg_mask = bank->pctl_offset + bank->eint_mask_offset;

Drop the initialization of reg_mask so:

else:
reg_mask = ...


> +
>  	raw_spin_lock_irqsave(&bank->slock, flags);
>  
>  	mask = readl(bank->eint_base + reg_mask);
> @@ -72,6 +75,9 @@ static void exynos_irq_ack(struct irq_data *irqd)
>  	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
>  	unsigned long reg_pend = our_chip->eint_pend + bank->eint_offset;
>  
> +	if (bank->eint_pend_offset)
> +		reg_pend = bank->pctl_offset + bank->eint_pend_offset;
> +
>  	writel(1 << irqd->hwirq, bank->eint_base + reg_pend);
>  }
>  
> @@ -95,6 +101,9 @@ static void exynos_irq_unmask(struct irq_data *irqd)
>  	if (irqd_get_trigger_type(irqd) & IRQ_TYPE_LEVEL_MASK)
>  		exynos_irq_ack(irqd);
>  

Ditto

> +	if (bank->eint_mask_offset)
> +		reg_mask = bank->pctl_offset + bank->eint_mask_offset;
> +
>  	raw_spin_lock_irqsave(&bank->slock, flags);
>  
>  	mask = readl(bank->eint_base + reg_mask);
> @@ -139,6 +148,9 @@ static int exynos_irq_set_type(struct irq_data *irqd, unsigned int type)
>  	else
>  		irq_set_handler_locked(irqd, handle_level_irq);
>  


Ditto

> +	if (bank->eint_con_offset)
> +		reg_con = bank->pctl_offset + bank->eint_con_offset;
> +
>  	con = readl(bank->eint_base + reg_con);
>  	con &= ~(EXYNOS_EINT_CON_MASK << shift);
>  	con |= trig_type << shift;
> @@ -221,6 +233,18 @@ static const struct exynos_irq_chip exynos_gpio_irq_chip __initconst = {
>  	/* eint_wake_mask_value not used */
>  };
>  
> +static const struct exynos_irq_chip exynosauto_gpio_irq_chip __initconst = {

No related to this patch.

> +	.chip = {
> +		.name = "exynosauto_gpio_irq_chip",
> +		.irq_unmask = exynos_irq_unmask,
> +		.irq_mask = exynos_irq_mask,
> +		.irq_ack = exynos_irq_ack,
> +		.irq_set_type = exynos_irq_set_type,
> +		.irq_request_resources = exynos_irq_request_resources,
> +		.irq_release_resources = exynos_irq_release_resources,
> +	},
> +};
> +
>  static int exynos_eint_irq_map(struct irq_domain *h, unsigned int virq,
>  					irq_hw_number_t hw)
>  {
> @@ -247,7 +271,10 @@ static irqreturn_t exynos_eint_gpio_irq(int irq, void *data)
>  	unsigned int svc, group, pin;
>  	int ret;
>  
> -	svc = readl(bank->eint_base + EXYNOS_SVC_OFFSET);
> +	if (bank->eint_con_offset)
> +		svc = readl(bank->eint_base + EXYNOSAUTO_SVC_OFFSET);

This belongs to the second patch. The point of this patch is only to
customize the offsets. There should be nothing autov920 here.


> +	else
> +		svc = readl(bank->eint_base + EXYNOS_SVC_OFFSET);
>  	group = EXYNOS_SVC_GROUP(svc);
>  	pin = svc & EXYNOS_SVC_NUM_MASK;
>  
> @@ -297,8 +324,12 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
>  		if (bank->eint_type != EINT_TYPE_GPIO)
>  			continue;
>  
> -		bank->irq_chip = devm_kmemdup(dev, &exynos_gpio_irq_chip,
> -					   sizeof(*bank->irq_chip), GFP_KERNEL);
> +		if (bank->eint_con_offset)
> +			bank->irq_chip = devm_kmemdup(dev, &exynosauto_gpio_irq_chip,
> +						      sizeof(*bank->irq_chip), GFP_KERNEL);
> +		else
> +			bank->irq_chip = devm_kmemdup(dev, &exynos_gpio_irq_chip,
> +						      sizeof(*bank->irq_chip), GFP_KERNEL);
>  		if (!bank->irq_chip) {
>  			ret = -ENOMEM;
>  			goto err_domains;
> @@ -655,6 +686,19 @@ static void exynos_pinctrl_suspend_bank(
>  	pr_debug("%s: save    mask %#010x\n", bank->name, save->eint_mask);
>  }
>  
> +static void exynosauto_pinctrl_suspend_bank(struct samsung_pinctrl_drv_data *drvdata,
> +					    struct samsung_pin_bank *bank)
> +{
> +	struct exynos_eint_gpio_save *save = bank->soc_priv;
> +	void __iomem *regs = bank->eint_base;
> +
> +	save->eint_con = readl(regs + bank->pctl_offset + bank->eint_con_offset);
> +	save->eint_mask = readl(regs + bank->pctl_offset + bank->eint_mask_offset);
> +
> +	pr_debug("%s: save     con %#010x\n", bank->name, save->eint_con);
> +	pr_debug("%s: save    mask %#010x\n", bank->name, save->eint_mask);
> +}
> +
>  void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
>  {
>  	struct samsung_pin_bank *bank = drvdata->pin_banks;
> @@ -662,8 +706,12 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
>  	int i;
>  
>  	for (i = 0; i < drvdata->nr_banks; ++i, ++bank) {
> -		if (bank->eint_type == EINT_TYPE_GPIO)
> -			exynos_pinctrl_suspend_bank(drvdata, bank);
> +		if (bank->eint_type == EINT_TYPE_GPIO) {
> +			if (bank->eint_con_offset)
> +				exynosauto_pinctrl_suspend_bank(drvdata, bank);
> +			else
> +				exynos_pinctrl_suspend_bank(drvdata, bank);
> +		}
>  		else if (bank->eint_type == EINT_TYPE_WKUP) {
>  			if (!irq_chip) {
>  				irq_chip = bank->irq_chip;
> @@ -704,14 +752,33 @@ static void exynos_pinctrl_resume_bank(
>  						+ bank->eint_offset);
>  }
>  
> +static void exynosauto_pinctrl_resume_bank(struct samsung_pinctrl_drv_data *drvdata,
> +					   struct samsung_pin_bank *bank)
> +{
> +	struct exynos_eint_gpio_save *save = bank->soc_priv;
> +	void __iomem *regs = bank->eint_base;
> +
> +	pr_debug("%s:     con %#010x => %#010x\n", bank->name,
> +		 readl(regs + bank->pctl_offset + bank->eint_con_offset), save->eint_con);
> +	pr_debug("%s:    mask %#010x => %#010x\n", bank->name,
> +		 readl(regs + bank->pctl_offset + bank->eint_mask_offset), save->eint_mask);
> +
> +	writel(save->eint_con, regs + bank->pctl_offset + bank->eint_con_offset);
> +	writel(save->eint_mask, regs + bank->pctl_offset + bank->eint_mask_offset);
> +}
> +
>  void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
>  {
>  	struct samsung_pin_bank *bank = drvdata->pin_banks;
>  	int i;
>  
>  	for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
> -		if (bank->eint_type == EINT_TYPE_GPIO)
> -			exynos_pinctrl_resume_bank(drvdata, bank);
> +		if (bank->eint_type == EINT_TYPE_GPIO) {
> +			if (bank->eint_con_offset)
> +				exynosauto_pinctrl_resume_bank(drvdata, bank);
> +			else
> +				exynos_pinctrl_resume_bank(drvdata, bank);
> +		}
>  }
>  
>  static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
> index 3ac52c2cf998..5049c170e958 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
> @@ -31,6 +31,7 @@
>  #define EXYNOS7_WKUP_EMASK_OFFSET	0x900
>  #define EXYNOS7_WKUP_EPEND_OFFSET	0xA00
>  #define EXYNOS_SVC_OFFSET		0xB08
> +#define EXYNOSAUTO_SVC_OFFSET		0xF008

As well not related to this patch.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:23:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:23:12 +0100
Subject: [PATCH v3 3/4] pinctrl: samsung: support ExynosAuto GPIO
 structure
In-Reply-To: <20231208074527.50840-4-jaewon02.kim@samsung.com>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
 <CGME20231208075020epcas2p260c65fa8d33e0cd97806f065bb8a044d@epcas2p2.samsung.com>
 <20231208074527.50840-4-jaewon02.kim@samsung.com>
Message-ID: <9d496fb5-25b4-4f1a-9652-4c54cf2d59a1@linaro.org>

On 08/12/2023 08:45, Jaewon Kim wrote:
> New ExynosAuto series GPIO have a different register structure.
> In the existing Exynos series, EINT control register enumerated after

Missing verb... or enumerated is past tense? I just don't get entire
sentence.

> a specific offset (e.g EXYNOS_GPIO_ECON_OFFSET, EXYNOS_GPIO_EMASK_OFFSET).
> However, from ExynosAutov920 SoC, the register that controls EINT belongs
> to each GPIO bank, and each GPIO bank has 0x1000 align.
> 
> This is a structure to protect the GPIO bank using S2MPU in VM environment,
> and will only be applied in ExynosAuto series SoCs.
> 
> -------------------------------------------------
> | original		| ExynosAutov920	|
> |-----------------------------------------------|
> | 0x0	GPIO_CON	| 0x0	GPIO_CON	|
> | 0x4	GPIO_DAT	| 0x4	GPIO_DAT	|
> | 0x8	GPIO_PUD	| 0x8	GPIO_PUD	|
> | 0xc	GPIO_DRV	| 0xc	GPIO_DRV	|
> | 0x10	GPIO_CONPDN	| 0x10	GPIO_CONPDN	|
> | 0x14	GPIO_PUDPDN	| 0x14	GPIO_PUDPDN	|
> | 0x700	EINT_CON	| 0x18	EINT_CON	|

This suggests there is EINT_CON per bank in old and new register layout.
I don't think it's true, so probably this could look like:

| ---                           | 0x18	EINT_CON (per_bank) |
| ---                           | 0x18	EINT_FLTCON0 (per_bank) |
| ---                           | 0x18	EINT_FLTCON1 (per_bank) |
| ---                           | 0x18	EINT_MASK (per_bank) |
| 0x700	EINT_CON (global)       | 0x18	EINT_CON	|

etc..

Also, please use spaces for alignment in the table.



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:23:56 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:23:56 +0100
Subject: [PATCH v3 4/4] pinctrl: samsung: add exynosautov920 pinctrl
In-Reply-To: <20231208074527.50840-5-jaewon02.kim@samsung.com>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
 <CGME20231208075020epcas2p414c85e03d18327665eeff54082314b56@epcas2p4.samsung.com>
 <20231208074527.50840-5-jaewon02.kim@samsung.com>
Message-ID: <a695f62f-5d08-49d6-a0b9-9f023ad7f586@linaro.org>

On 08/12/2023 08:45, Jaewon Kim wrote:
> Add pinctrl data for ExynosAutov920 SoC.
> 
> Pinctrl data for ExynosAutoV920 SoC.
>  - GPA0,GPA1 (10): External wake up interrupt
>  - GPQ0 (2): SPMI (PMIC I/F)
>  - GPB0,GPB1,GPB2,GPB3,GPB4,GPB5,GPB6 (47): I2S Audio
>  - GPH0,GPH1,GPH2,GPH3,GPH4,GPH5,GPH6,GPH8 (49): PCIE, UFS, Ethernet
>  - GPG0,GPG1,GPG2,GPG3,GPG4,GPG5 (29): General purpose
>  - GPP0,GPP1,GPP2,GPP3,GPP4,GPP5,GPP6,GPP7,GPP8,GPP9,GPP10 (77): USI
> 
> Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
> ---

...


>  /**
>   * struct exynos_weint_data: irq specific data for all the wakeup interrupts
>   * generated by the external wakeup interrupt controller.
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 362e99566919..800a2f0a026a 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -1324,6 +1324,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
>  		.data = &exynosautov9_of_data },
>  	{ .compatible = "tesla,fsd-pinctrl",
>  		.data = &fsd_of_data },
> +	{ .compatible = "samsung,exynosautov920-pinctrl",
> +		.data = &exynosautov920_of_data },

Please put it after autov9.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:39:15 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:39:15 +0100
Subject: [PATCH] dt-bindings: pinctrl: samsung: correct ExynosAutov920 wake-up compatibles
Message-ID: <20231210133915.42112-1-krzysztof.kozlowski@linaro.org>

ExynosAutov920 SoC wake-up pin controller has different register layout
than Exynos7, thus it should not be marked as compatible.  Neither DTS
nor Linux driver was merged yet, so the change does not impact ABI.

Cc: Jaewon Kim <jaewon02.kim at samsung.com>
Fixes: 904140fa4553 ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

Fix for my for-next branch.
---
 .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml     | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
index 2bafa867aea2..f64da7f58faa 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
@@ -36,6 +36,7 @@ properties:
           - samsung,s5pv210-wakeup-eint
           - samsung,exynos4210-wakeup-eint
           - samsung,exynos7-wakeup-eint
+          - samsung,exynosautov920-wakeup-eint
       - items:
           - enum:
               - samsung,exynos5433-wakeup-eint
@@ -45,7 +46,6 @@ properties:
       - items:
           - enum:
               - samsung,exynosautov9-wakeup-eint
-              - samsung,exynosautov920-wakeup-eint
           - const: samsung,exynos850-wakeup-eint
           - const: samsung,exynos7-wakeup-eint
 
@@ -112,6 +112,7 @@ allOf:
           contains:
             enum:
               - samsung,exynos850-wakeup-eint
+              - samsung,exynosautov920-wakeup-eint
     then:
       properties:
         interrupts: false
-- 
2.34.1



From conor at kernel.org  Sun Dec 10 05:39:12 2023
From: conor at kernel.org (Conor Dooley)
Date: Sun, 10 Dec 2023 13:39:12 +0000
Subject: [EXT] Re: [PATCH v2 1/4] dt-bindings: perf: fsl-imx-ddr: Add
 i.MX95 compatible
In-Reply-To: <DB7PR04MB51468DB108F3003AF52CDDDA8C88A@DB7PR04MB5146.eurprd04.prod.outlook.com>
References: <20231208085402.2106904-1-xu.yang_2@nxp.com>
 <20231208-depress-smuggler-f3069487a067@spud>
 <DB7PR04MB51468DB108F3003AF52CDDDA8C88A@DB7PR04MB5146.eurprd04.prod.outlook.com>
Message-ID: <20231210-scrap-backdrop-8bae1acc07fd@spud>

On Sun, Dec 10, 2023 at 04:27:16AM +0000, Xu Yang wrote:
> Hi Conor,
> 
> > On Fri, Dec 08, 2023 at 04:53:59PM +0800, Xu Yang wrote:
> > > i.MX95 has a DDR pmu. This will add a compatible for it.
> > 
> > On v1 we had a discussion because the commit message wasn't clear about
> > whether or not the device was compatible with existing ones. For some
> > reason, the v2 patch _removes_ information from the commit message
> > rather than tries to explain.
> > This [1] message of yours, that I didn't get a chance to reply to before
> > you sent this new version, seems to say that there should be an
> > imx93-ddr-pmu fallback.
> 
> Thanks for your comments. 
> 
> Just read my previous comment in [1] and found I made a mistake.
> Now I'll try to clarify it here.
> 
> Imx95 and imx93 have different AXI filter configuration. I need a 
> compatible for imx95 since the driver cannot differentiate them. 
> 
> Then I need to consider below two options:
> 1. compatible = "fsl,imx95-ddr-pmu", "fsl,imx93-ddr-pmu"
> 2. compatible = "fsl,imx95-ddr-pmu"
> 
> Both of them work correctly on imx95. When I make changes in
> driver for imx95, imx93 is not affected.
> 
> For basic functions, imx95 is compatible with imx93. I select the 2rd
> form for simplicity. If the first form is optimal, I can change it in next
> version.

The first form is preferred, yes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231210/bfc911a0/attachment.sig>

From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:44:20 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:44:20 +0100
Subject: [PATCH v6 02/20] dt-bindings: clock: Add Google gs101 clock
 management unit bindings
In-Reply-To: <20231209233106.147416-3-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-3-peter.griffin@linaro.org>
Message-ID: <eb3bfbbf-ce33-4281-9039-3e2ead40b1f2@linaro.org>

On 10/12/2023 00:30, Peter Griffin wrote:
> Provide dt-schema documentation for Google gs101 SoC clock controller.
> Currently this adds support for cmu_top, cmu_misc and cmu_apm.
> 
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  .../bindings/clock/google,gs101-clock.yaml    | 106 +++++
>  include/dt-bindings/clock/google,gs101.h      | 392 ++++++++++++++++++
>  2 files changed, 498 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>  create mode 100644 include/dt-bindings/clock/google,gs101.h

Wearing DT hat:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:48:34 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:48:34 +0100
Subject: [PATCH] dt-bindings: samsung: exynos-sysreg: combine exynosautov920 with other enum
Message-ID: <20231210134834.43943-1-krzysztof.kozlowski@linaro.org>

No need to create a new enum every time we bring-up new SoC.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/soc/samsung/samsung,exynos-sysreg.yaml        | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
index 2de4301a467d..b00f25482fec 100644
--- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
@@ -17,6 +17,8 @@ properties:
               - samsung,exynos3-sysreg
               - samsung,exynos4-sysreg
               - samsung,exynos5-sysreg
+              - samsung,exynosautov920-peric0-sysreg
+              - samsung,exynosautov920-peric1-sysreg
               - tesla,fsd-cam-sysreg
               - tesla,fsd-fsys0-sysreg
               - tesla,fsd-fsys1-sysreg
@@ -50,11 +52,6 @@ properties:
               - samsung,exynosautov9-peric1-sysreg
           - const: samsung,exynosautov9-sysreg
           - const: syscon
-      - items:
-          - enum:
-              - samsung,exynosautov920-peric0-sysreg
-              - samsung,exynosautov920-peric1-sysreg
-          - const: syscon
 
   reg:
     maxItems: 1
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:49:26 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:49:26 +0100
Subject: [PATCH v6 03/20] dt-bindings: soc: google: exynos-sysreg: add
 dedicated SYSREG compatibles to GS101
In-Reply-To: <20231209233106.147416-4-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-4-peter.griffin@linaro.org>
Message-ID: <c2244932-cb2f-423a-bbe6-9ab2b08b9d63@linaro.org>

On 10/12/2023 00:30, Peter Griffin wrote:
> GS101 has three different SYSREG controllers, add dedicated
> compatibles for them to the documentation.
> 
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  .../bindings/soc/samsung/samsung,exynos-sysreg.yaml         | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> index 2de4301a467d..127f4ffde76a 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> @@ -22,6 +22,12 @@ properties:
>                - tesla,fsd-fsys1-sysreg
>                - tesla,fsd-peric-sysreg
>            - const: syscon
> +      - items:
> +          - enum:
> +              - google,gs101-apm-sysreg
> +              - google,gs101-peric0-sysreg
> +              - google,gs101-peric1-sysreg

This should be part of the first enum. No need for new list for every
new SoC. I'll fix it while applying.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:52:46 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:52:46 +0100
Subject: [PATCH v6 05/20] dt-bindings: arm: google: Add bindings for
 Google ARM platforms
In-Reply-To: <20231209233106.147416-6-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-6-peter.griffin@linaro.org>
Message-ID: <2dd2f920-a0a5-4f69-b7e6-c09c3f83eae6@linaro.org>

On 10/12/2023 00:30, Peter Griffin wrote:
> +  Likewise there are a couple of names for the actual device
> +  - Marketing name ("Pixel 6")
> +  - Codename ("Oriole")
> +
> +  Devicetrees should use the lowercased SoC ID and lowercased board codename,
> +  e.g. gs101 and gs101-oriole.
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +      - description: Google Pixel 6 / Oriole
> +        items:
> +          - enum:
> +              - google,gs101-oriole
> +          - const: google,gs101
> +
> +  # Bootloader requires empty ect node to be present
> +  ect:
> +    type: object
> +    additionalProperties: false

This is a major change, thus Rob's review should be dropped with short
explanation.

No new properties post-review.

Rob,

Please re-review the "ect" part. I suggested it to Peter to solve the
bootloader requirements.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:55:55 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:55:55 +0100
Subject: [PATCH v6 13/20] pinctrl: samsung: Add gs101 SoC pinctrl
 configuration
In-Reply-To: <20231209233106.147416-14-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-14-peter.griffin@linaro.org>
Message-ID: <46c9c8b4-942d-4f6f-a6cc-00158314d5e5@linaro.org>

On 10/12/2023 00:30, Peter Griffin wrote:
> Add support for the pin-controller found on the gs101 SoC used in
> Pixel 6 phones.
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---


> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index 6b58ec84e34b..3834bf953178 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -468,6 +468,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
>  			.data = &exynos7_wkup_irq_chip },
>  	{ .compatible = "samsung,exynosautov9-wakeup-eint",
>  			.data = &exynos7_wkup_irq_chip },
> +	{ .compatible = "google,gs101-wakeup-eint",
> +			.data = &exynos7_wkup_irq_chip },

You don't need it.

>  	{ }
>  };
>  
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 79babbb39ced..b8d549fe38cb 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -1321,6 +1321,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
>  		.data = &exynosautov9_of_data },
>  	{ .compatible = "tesla,fsd-pinctrl",
>  		.data = &fsd_of_data },
> +	{ .compatible = "google,gs101-pinctrl",
> +		.data = &gs101_of_data },

Place it somewhere alphabetically. Probably before tesla.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:57:42 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:57:42 +0100
Subject: (subset) [PATCH v6 06/20] dt-bindings: pinctrl: samsung: add
 google,gs101-pinctrl compatible
In-Reply-To: <20231209233106.147416-7-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-7-peter.griffin@linaro.org>
Message-ID: <170221666275.44902.3863677775174337941.b4-ty@linaro.org>


On Sat, 09 Dec 2023 23:30:52 +0000, Peter Griffin wrote:
> Add the "google,gs101-pinctrl" compatible to the dt-schema bindings
> documentation.
> 
> 

Applied, thanks!

[06/20] dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
        https://git.kernel.org/pinctrl/samsung/c/4a2006d0c338c95352bf9f06e5b3cb8afa0bc885

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Sun Dec 10 05:57:45 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 14:57:45 +0100
Subject: (subset) [PATCH v6 07/20] dt-bindings: pinctrl: samsung: add
 gs101-wakeup-eint compatible
In-Reply-To: <20231209233106.147416-8-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-8-peter.griffin@linaro.org>
Message-ID: <170221666553.44902.5488217525830070811.b4-ty@linaro.org>


On Sat, 09 Dec 2023 23:30:53 +0000, Peter Griffin wrote:
> gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
> where more than one pin controller can do external wake-up interrupt.
> So add a dedicated compatible for it.
> 
> 

Applied, thanks!

[07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
        https://git.kernel.org/pinctrl/samsung/c/abc73e50b394f248aa8e7ecdfbd4dfa52f8e8355

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Sun Dec 10 06:01:42 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 15:01:42 +0100
Subject: (subset) [PATCH v6 01/20] dt-bindings: soc: samsung:
 exynos-pmu: Add gs101 compatible
In-Reply-To: <20231209233106.147416-2-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-2-peter.griffin@linaro.org>
Message-ID: <170221690211.46013.5711996168125251211.b4-ty@linaro.org>


On Sat, 09 Dec 2023 23:30:47 +0000, Peter Griffin wrote:
> Add gs101-pmu compatible to the bindings documentation.
> 
> 

Applied, thanks!

[01/20] dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
        https://git.kernel.org/krzk/linux/c/fdd78ff04ccc96f628c2f93e0d48ab0a74bf34ef

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Sun Dec 10 06:01:45 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 15:01:45 +0100
Subject: (subset) [PATCH v6 02/20] dt-bindings: clock: Add Google gs101
 clock management unit bindings
In-Reply-To: <20231209233106.147416-3-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-3-peter.griffin@linaro.org>
Message-ID: <170221690550.46013.13677086533521441233.b4-ty@linaro.org>


On Sat, 09 Dec 2023 23:30:48 +0000, Peter Griffin wrote:
> Provide dt-schema documentation for Google gs101 SoC clock controller.
> Currently this adds support for cmu_top, cmu_misc and cmu_apm.
> 
> 

Applied, thanks!

[02/20] dt-bindings: clock: Add Google gs101 clock management unit bindings
        https://git.kernel.org/krzk/linux/c/0a910f1606384a5886a045e36b1fc80a7fa6706b

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Sun Dec 10 06:01:48 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 15:01:48 +0100
Subject: (subset) [PATCH v6 03/20] dt-bindings: soc: google:
 exynos-sysreg: add dedicated SYSREG compatibles to GS101
In-Reply-To: <20231209233106.147416-4-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-4-peter.griffin@linaro.org>
Message-ID: <170221690857.46013.17338443649836417871.b4-ty@linaro.org>


On Sat, 09 Dec 2023 23:30:49 +0000, Peter Griffin wrote:
> GS101 has three different SYSREG controllers, add dedicated
> compatibles for them to the documentation.
> 
> 

Applied, thanks!

[03/20] dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101
        https://git.kernel.org/krzk/linux/c/d9232785858eafde8553932f96fb7e25c2191ed2

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From broonie at kernel.org  Sun Dec 10 06:22:56 2023
From: broonie at kernel.org (Mark Brown)
Date: Sun, 10 Dec 2023 14:22:56 +0000
Subject: [PATCH v7 26/39] arm64/ptrace: Expose GCS via ptrace and core
 files
In-Reply-To: <877clney35.fsf@linaro.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-26-201c483bd775@kernel.org>
 <877clney35.fsf@linaro.org>
Message-ID: <ZXXJwNdKC/y6bRYn@finisterre.sirena.org.uk>

On Sat, Dec 09, 2023 at 08:49:02PM -0300, Thiago Jung Bauermann wrote:
> Mark Brown <broonie at kernel.org> writes:

> > Provide a new register type NT_ARM_GCS reporting the current GCS mode
> > and pointer for EL0.  Due to the interactions with allocation and
> > deallocation of Guarded Control Stacks we do not permit any changes to
> > the GCS mode via ptrace, only GCSPR_EL0 may be changed.

> The code allows disabling GCS. Is that unintended?

No, it's intentional - ptrace has a lot of control over the process,
there's not a huge point trying to protect against it doing a disable.
The reason we prevent enabling is the allocation of a GCS along with
enable, the complexity of doing that on a remote process seemed
unjustified.  If clone3() ends up allowing manual allocation and
placement that'll likely be revised.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231210/b7408076/attachment.sig>

From krzysztof.kozlowski at linaro.org  Sun Dec 10 06:23:51 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 15:23:51 +0100
Subject: [PATCH v6 04/20] dt-bindings: watchdog: Document Google gs101
 watchdog bindings
In-Reply-To: <20231209233106.147416-5-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-5-peter.griffin@linaro.org>
Message-ID: <e70d516d-db24-4d79-bbd8-bb5b497a4391@linaro.org>

On 10/12/2023 00:30, Peter Griffin wrote:
> Add the "google,gs101-wdt" compatible to the dt-schema documentation.
> 
> gs101 SoC has two CPU clusters and each cluster has its own dedicated
> watchdog timer (similar to exynos850 and exynosautov9 SoCs).
> 
> These WDT instances are controlled using different bits in PMU
> registers.
> 
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  .../devicetree/bindings/watchdog/samsung-wdt.yaml         | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
> index 8fb6656ba0c2..57468c2c5ece 100644
> --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
> @@ -17,6 +17,7 @@ description: |+
>  properties:
>    compatible:
>      enum:
> +      - google,gs101-wdt                      # for Google gs101

I think you did not rebase on linux-next. The hunk differs.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 06:24:43 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 15:24:43 +0100
Subject: [PATCH v6 14/20] watchdog: s3c2410_wdt: Add support for WTCON
 register DBGACK_MASK bit
In-Reply-To: <20231209233106.147416-15-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-15-peter.griffin@linaro.org>
Message-ID: <9ffd229e-cf1b-4508-ba74-d5a000c54582@linaro.org>

On 10/12/2023 00:31, Peter Griffin wrote:
> The WDT uses the CPU core signal DBGACK to determine whether the SoC
> is running in debug mode or not. If the DBGACK signal is asserted and
> DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
> (disabled).
> 
> Presence of the DBGACK_MASK bit is determined by adding a new
> QUIRK_HAS_DBGACK_BIT quirk. Also update to use BIT macro to avoid
> checkpatch --strict warnings.
> 
> Tested-by: Will McVicker <willmcvicker at google.com>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Guenter, Wim,

The watchdog patches are kind of independent, except that bindings has
conflicting re-organization which I took via my Samsung SoC tree. If it
is fine with you, please provide acks or review and I will take the
watchdog changes.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 06:26:40 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 15:26:40 +0100
Subject: [PATCH v6 16/20] watchdog: s3c2410_wdt: Add support for Google
 gs101 SoC
In-Reply-To: <20231209233106.147416-17-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-17-peter.griffin@linaro.org>
Message-ID: <25533a7f-326f-48d1-a8a6-e5798bdca4b4@linaro.org>

On 10/12/2023 00:31, Peter Griffin wrote:
> This patch adds the compatibles and drvdata for the Google
> gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.
> 
> Similar to Exynos850 it has two watchdog instances, one for
> each cluster and has some control bits in PMU registers.
> 


> +
>  static const struct of_device_id s3c2410_wdt_match[] = {
>  	{ .compatible = "samsung,s3c2410-wdt",
>  	  .data = &drv_data_s3c2410 },
> @@ -285,6 +318,8 @@ static const struct of_device_id s3c2410_wdt_match[] = {
>  	  .data = &drv_data_exynos850_cl0 },
>  	{ .compatible = "samsung,exynosautov9-wdt",
>  	  .data = &drv_data_exynosautov9_cl0 },
> +	{ .compatible = "google,gs101-wdt",
> +	  .data = &drv_data_gs101_cl0 },

Keep some alphabetical order by compatible, so this should be probably
the first entry in the table.

Same for s3c2410_wdt_variant structures.

>  	{},


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 06:38:38 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 15:38:38 +0100
Subject: [PATCH v6 18/20] arm64: dts: exynos: google: Add initial Google
 gs101 SoC support
In-Reply-To: <20231209233106.147416-19-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-19-peter.griffin@linaro.org>
Message-ID: <8400d76b-2a04-4d60-ad6c-954dca07562f@linaro.org>

On 10/12/2023 00:31, Peter Griffin wrote:
> Google gs101 SoC is a ARMv8 mobile SoC found in the Pixel 6
> (oriole), Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
> phones.
> 
> It features:
> * 4xA55 Little cluster
> * 2xA76 Mid cluster
> * 2xX1 Big cluster
> 

...

> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> new file mode 100644
> index 000000000000..68b7bc47c91b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Pinctrl binding constants for GS101
> + *
> + * Copyright 2020-2023 Google LLC
> + */
> +
> +#ifndef __DT_BINDINGS_PINCTRL_GS101_H__
> +#define __DT_BINDINGS_PINCTRL_GS101_H__

Header guards don't really match location.

> +
> +#define GS101_PIN_PULL_NONE		0
> +#define GS101_PIN_PULL_DOWN		1
> +#define GS101_PIN_PULL_UP		3
> +
> +/* Pin function in power down mode */
> +#define GS101_PIN_PDN_OUT0		0
> +#define GS101_PIN_PDN_OUT1		1
> +#define GS101_PIN_PDN_INPUT		2
> +#define GS101_PIN_PDN_PREV		3
> +
> +/* GS101 drive strengths */
> +#define GS101_PIN_DRV_2_5_MA		0
> +#define GS101_PIN_DRV_5_MA		1
> +#define GS101_PIN_DRV_7_5_MA		2
> +#define GS101_PIN_DRV_10_MA		3
> +
> +#define GS101_PIN_FUNC_INPUT		0
> +#define GS101_PIN_FUNC_OUTPUT		1
> +#define GS101_PIN_FUNC_2		2
> +#define GS101_PIN_FUNC_3		3
> +#define GS101_PIN_FUNC_EINT		0xf
> +
> +#endif /* __DT_BINDINGS_PINCTRL_GS101_H__ */
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> new file mode 100644
> index 000000000000..60e112d25246
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -0,0 +1,476 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * GS101 SoC
> + *
> + * Copyright 2019-2023 Google LLC
> + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> + */
> +
> +#include <dt-bindings/clock/google,gs101.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/soc/samsung,exynos-usi.h>
> +
> +/ {
> +	compatible = "google,gs101";
> +	#address-cells = <2>;
> +	#size-cells = <1>;
> +
> +	interrupt-parent = <&gic>;
> +
> +	aliases {
> +		pinctrl0 = &pinctrl_gpio_alive;
> +		pinctrl1 = &pinctrl_far_alive;
> +		pinctrl2 = &pinctrl_gsacore;
> +		pinctrl3 = &pinctrl_gsactrl;
> +		pinctrl4 = &pinctrl_peric0;
> +		pinctrl5 = &pinctrl_peric1;
> +		pinctrl6 = &pinctrl_hsi1;
> +		pinctrl7 = &pinctrl_hsi2;
> +	};
> +
> +	pmu-0 {
> +		compatible = "arm,cortex-a55-pmu";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
> +	};
> +
> +	pmu-1 {
> +		compatible = "arm,cortex-a76-pmu";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
> +	};
> +
> +	pmu-2 {
> +		compatible = "arm,cortex-x1-pmu";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster2>;
> +	};
> +
> +	pmu-3 {
> +		compatible = "arm,dsu-pmu";
> +		interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH 0>;
> +		cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
> +		       <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
> +	};

Keep alphabetical order of top-level nodes. pmu should be before psci

> +
> +	/* TODO replace with CCF clock */
> +	dummy_clk: oscillator {

clock-3

> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <12345>;
> +		clock-output-names = "pclk";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu-map {
> +			cluster0 {
> +				core0 {
> +					cpu = <&cpu0>;
> +				};
> +				core1 {
> +					cpu = <&cpu1>;
> +				};
> +				core2 {
> +					cpu = <&cpu2>;
> +				};
> +				core3 {
> +					cpu = <&cpu3>;
> +				};
> +			};
> +
> +			cluster1 {
> +				core0 {
> +					cpu = <&cpu4>;
> +				};
> +				core1 {
> +					cpu = <&cpu5>;
> +				};
> +			};
> +
> +			cluster2 {
> +				core0 {
> +					cpu = <&cpu6>;
> +				};
> +				core1 {
> +					cpu = <&cpu7>;
> +				};
> +			};
> +		};

...

> +
> +	/* ect node is required to be present by bootloader */
> +	ect {
> +	};

alphabetical order

> +
> +	ext_24_5m: clock-1 {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-output-names = "oscclk";
> +	};
> +
> +	ext_200m: clock-2 {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-output-names = "ext-200m";
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-1.0";
> +		method = "smc";
> +	};
> +
> +	reserved_memory: reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		gsa_reserved_protected: gsa at 90200000 {
> +			reg = <0x0 0x90200000 0x400000>;
> +			no-map;
> +		};
> +
> +		tpu_fw_reserved: tpu-fw at 93000000 {
> +			reg = <0x0 0x93000000 0x1000000>;
> +			no-map;
> +		};
> +
> +		aoc_reserve: aoc at 94000000 {
> +			reg = <0x0 0x94000000 0x03000000>;
> +			no-map;
> +		};
> +
> +		abl_reserved: abl at f8800000 {
> +			reg = <0x0 0xf8800000 0x02000000>;
> +			no-map;
> +		};
> +
> +		dss_log_reserved: dss-log-reserved at fd3f0000 {
> +			reg = <0x0 0xfd3f0000 0x0000e000>;
> +			no-map;
> +		};
> +
> +		debug_kinfo_reserved: debug-kinfo-reserved at fd3fe000 {
> +			reg = <0x0 0xfd3fe000 0x00001000>;
> +			no-map;
> +		};
> +
> +		bldr_log_reserved: bldr-log-reserved at fd800000 {
> +			reg = <0x0 0xfd800000 0x00100000>;
> +			no-map;
> +		};
> +
> +		bldr_log_hist_reserved: bldr-log-hist-reserved at fd900000 {
> +			reg = <0x0 0xfd900000 0x00002000>;
> +			no-map;
> +		};
> +	};
> +
> +	timer {

alphabetical order, so this goes to the end

> +		compatible = "arm,armv8-timer";
> +		interrupts =
> +		   <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> +		   <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> +		   <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> +		   <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>;
> +		clock-frequency = <24576000>;

I don't remember if you already got Marc's wrath, so just in case: are
you sure it is needed?

Anyway, this is board specific, not SoC.

> +	};
> +
> +	soc: soc at 0 {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges = <0x0 0x0 0x0 0x40000000>;
> +
> +		cmu_misc: clock-controller at 10010000 {
> +			compatible = "google,gs101-cmu-misc";
> +			reg = <0x10010000 0x8000>;
> +			#clock-cells = <1>;
> +			clocks =  <&cmu_top CLK_DOUT_CMU_MISC_BUS>,

One space after =

> +				  <&cmu_top CLK_DOUT_CMU_MISC_SSS>;
> +			clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
> +		};
> +
> +		watchdog_cl0: watchdog at 10060000 {
> +			compatible = "google,gs101-wdt";
> +			reg = <0x10060000 0x100>;
> +			interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH 0>;
> +			clocks =
> +			  <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0_PCLK>,

Join lines (clocks = <foo bar>). Same in other places.

> +			  <&ext_24_5m>;
> +			clock-names = "watchdog", "watchdog_src";
> +			samsung,syscon-phandle = <&pmu_system_controller>;
> +			samsung,cluster-index = <0>;
> +			status = "disabled";
> +		};
> +
> +		watchdog_cl1: watchdog at 10070000 {
> +			compatible = "google,gs101-wdt";
> +			reg = <0x10070000 0x100>;
> +			interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH 0>;
> +			clocks =
> +			  <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1_PCLK>,
> +			  <&ext_24_5m>;
> +			clock-names = "watchdog", "watchdog_src";
> +			samsung,syscon-phandle = <&pmu_system_controller>;
> +			samsung,cluster-index = <1>;
> +			status = "disabled";
> +		};
> +
> +		gic: interrupt-controller at 10400000 {
> +			compatible = "arm,gic-v3";
> +			#interrupt-cells = <4>;
> +			interrupt-controller;
> +			reg = <0x10400000 0x10000>, /* GICD */
> +			      <0x10440000 0x100000>;/* GICR * 8 */
> +			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
> +
> +			ppi-partitions {
> +				ppi_cluster0: interrupt-partition-0 {
> +					affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
> +				};
> +
> +				ppi_cluster1: interrupt-partition-1 {
> +					affinity = <&cpu4 &cpu5>;
> +				};
> +
> +				ppi_cluster2: interrupt-partition-2 {
> +					affinity = <&cpu6 &cpu7>;
> +				};
> +			};
> +		};
> +
> +		sysreg_peric0: syscon at 10820000 {
> +			compatible = "google,gs101-peric0-sysreg", "syscon";
> +			reg = <0x10820000 0x10000>;
> +		};
> +
> +		pinctrl_peric0: pinctrl at 10840000 {
> +			compatible = "google,gs101-pinctrl";
> +			reg = <0x10840000 0x00001000>;
> +			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> +		};
> +
> +		usi_uart: usi at 10a000c0 {
> +			compatible = "google,gs101-usi",
> +				     "samsung,exynos850-usi";
> +			reg = <0x10a000c0 0x20>;
> +			samsung,sysreg = <&sysreg_peric0 0x1020>;
> +			samsung,mode = <USI_V2_UART>;

vendor properties go to the end, after standard properties, before status.

https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst?h=dt/next&id=0d3a771610d0e155c9aa305f142f84dda5030fae#n122

> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			ranges;
> +			clocks = <&dummy_clk>, <&dummy_clk>;
> +			clock-names = "pclk", "ipclk";
> +			status = "disabled";
> +
> +			serial_0: serial at 10a00000 {
> +				compatible = "google,gs101-uart";
> +				reg = <0x10a00000 0xc0>;
> +				reg-io-width = <4>;
> +				samsung,uart-fifosize = <256>;

Ditto

> +				interrupts = <GIC_SPI 634
> +					      IRQ_TYPE_LEVEL_HIGH 0>;
> +				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
> +				clock-names = "uart", "clk_uart_baud0";
> +				status = "disabled";
> +			};
> +		};


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 06:38:47 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 15:38:47 +0100
Subject: [PATCH v6 00/20] Add minimal Tensor/GS101 SoC support and
 Oriole/Pixel6 board
In-Reply-To: <20231209233106.147416-1-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
Message-ID: <654def19-ff10-4e9c-a830-e3bab7a153bd@linaro.org>

On 10/12/2023 00:30, Peter Griffin wrote:
> Hi folks,
> 
> This series adds initial SoC support for the GS101 SoC and also initial board
> support for Pixel 6 phone (Oriole).
> 

I started applying few reviewed bindings. We are getting close to end of
merging time for SoC.

Top-level arm/google.yaml needs ack or re-review from Rob.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 06:39:45 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 10 Dec 2023 15:39:45 +0100
Subject: [PATCH v6 19/20] arm64: dts: exynos: google: Add initial
 Oriole/pixel 6 board support
In-Reply-To: <20231209233106.147416-20-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-20-peter.griffin@linaro.org>
Message-ID: <03603f37-ec3d-456c-95a4-e543d1df4801@linaro.org>

On 10/12/2023 00:31, Peter Griffin wrote:
> Add initial board support for the Pixel 6 phone code named Oriole. This
> has been tested with a minimal busybox initramfs and boots to a shell.
> 
> Tested-by: Will McVicker <willmcvicker at google.com>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  arch/arm64/boot/dts/exynos/Makefile           |   2 +

...

> +&serial_0 {
> +	status = "okay";

Keep status the last

> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_bus>;
> +};
> +
> +&usi_uart {
> +	status = "okay";

Keep status the last

> +	samsung,clkreq-on; /* needed for UART mode */
> +};
> +
> +&watchdog_cl0 {
> +	timeout-sec = <30>;
> +	status = "okay";
> +};

Best regards,
Krzysztof



From jisheng.teoh at starfivetech.com  Sun Dec 10 08:21:19 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Mon, 11 Dec 2023 00:21:19 +0800
Subject: [PATCH v2] i2c: cadence: Add system suspend and resume PM support
In-Reply-To: <20231210115412.hztjrubacnmenbvz@zenone.zhora.eu>
References: <20231210115412.hztjrubacnmenbvz@zenone.zhora.eu>
Message-ID: <20231210162119.364-1-jisheng.teoh@starfivetech.com>

On Sun, 10 Dec 2023 12:54:12 +0100
Andi Shyti <andi.shyti at kernel.org> wrote:

> Hi Ji Sheng,
> 
> [...]
> 
> > > > +static int __maybe_unused cdns_i2c_resume(struct device *dev)
> > > > +{  
> > >
> > > I am not really understanding what you are trying to do here:
> > >  
> > > > +	struct cdns_i2c *xi2c = dev_get_drvdata(dev);
> > > > +	int err;
> > > > +
> > > > +	err = cdns_i2c_runtime_resume(dev);  
> > >
> > > First you try to resume...
> > >  
> > > > +	if (err)
> > > > +		return err;
> > > > +
> > > > +	if (pm_runtime_status_suspended(dev)) {  
> > >
> > > ... then you check if you are suspended ...  
> > 
> > This serves as a check and balance to ensure that when the system
> > resumes with device in runtime suspend state, we disable the clock
> > enabled in earlier cdns_i2c_runtime_resume() to ensure a balanced
> > clock reference count for subsequent runtime resume transition.
> > Similar implementation can be found in this commit:
> > https://github.com/torvalds/linux/commit/44c99904cf61f945d02ac9976ab10dd5ccaea393
> >  
> 
> OK, this is done purely for clock balancing, but then, I still
> don't understand the case. I expect the clock counter to be
> unbalanced when you suspend (because is moving towards '0').
> 
> While, if you check if the clock is unbalanced when resuming, it
> means that the clock had a negative counter (which is impossible
> because the clock counter is unsigned).
> 
> If there is any unbalancing at this stage, then I recommend you
> to check what has happened previously.
> 
> ... Or is there anything I am missing?
> 
> Thanks,
> Andi

You are right, the clock counter will move towards 0 during system
suspend.
Conversely during system resume, the clock counter is incremented to 1
early on in cdns_i2c_runtime_resume(). So the clock counter is not
negative to start with. 
At this point of time, clock counter is 1. If the device is in runtime
suspend, we decrement the clock counter back to 0, so the subsequent
runtime resume could increment it back to 1. In a sense, balancing the
clock counter.
Please help correct me if I've got it wrong.

> 
> > > > +		err = cdns_i2c_runtime_suspend(dev);  
> > >
> > > ... and suspend again? Shouldn't this be _resume()?
> > >
> > > Thanks,
> > > Andi
> > >  
> > > > +		if (err)
> > > > +			return err;
> > > > +	}
> > > > +
> > > > +	i2c_mark_adapter_resumed(&xi2c->adap);
> > > > +
> > > > +	return 0;
> > > > +}  




From visitorckw at gmail.com  Sun Dec 10 09:19:07 2023
From: visitorckw at gmail.com (Kuan-Wei Chiu)
Date: Mon, 11 Dec 2023 01:19:07 +0800
Subject: [PATCH] clk: imx: scu: Fix memory leak in __imx_clk_gpr_scu()
Message-ID: <20231210171907.3410922-1-visitorckw@gmail.com>

In cases where imx_clk_is_resource_owned() returns false, the code path
does not handle the failure gracefully, potentially leading to a memory
leak. This fix ensures proper cleanup by freeing the allocated memory
for 'clk_node' before returning.

Signed-off-by: Kuan-Wei Chiu <visitorckw at gmail.com>
---
 drivers/clk/imx/clk-scu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c
index be89180dd19c..e48a904c0013 100644
--- a/drivers/clk/imx/clk-scu.c
+++ b/drivers/clk/imx/clk-scu.c
@@ -886,8 +886,10 @@ struct clk_hw *__imx_clk_gpr_scu(const char *name, const char * const *parent_na
 		return ERR_PTR(-EINVAL);
 	}
 
-	if (!imx_clk_is_resource_owned(rsrc_id))
+	if (!imx_clk_is_resource_owned(rsrc_id)) {
+		kfree(clk_node);
 		return NULL;
+	}
 
 	clk = kzalloc(sizeof(*clk), GFP_KERNEL);
 	if (!clk) {
-- 
2.25.1



From aford173 at gmail.com  Sun Dec 10 09:35:11 2023
From: aford173 at gmail.com (Adam Ford)
Date: Sun, 10 Dec 2023 11:35:11 -0600
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <20230920205736.GB7723@pendragon.ideasonboard.com>
References: <20230920171009.3193296-1-l.stach@pengutronix.de>
 <20230920171009.3193296-2-l.stach@pengutronix.de> <20230920205736.GB7723@pendragon.ideasonboard.com>
Message-ID: <CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>

On Wed, Sep 20, 2023 at 3:57?PM Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>
> Hi Lucas,
>
> Thank you for the patch.
>
> On Wed, Sep 20, 2023 at 07:10:09PM +0200, Lucas Stach wrote:
> > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> > full timing generator and can switch between different video sources. On
> > the i.MX8MP however the only supported source is the LCDIF. The block
> > just needs to be powered up and told about the polarity of the video
> > sync signals to act in bypass mode.
> >
> > Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
> > Reviewed-by: Luca Ceresoli <luca.ceresoli at bootlin.com> (v2)
> > Tested-by: Marek Vasut <marex at denx.de> (v1)
> > Tested-by: Luca Ceresoli <luca.ceresoli at bootlin.com> (v2)
> > Tested-by: Richard Leitner <richard.leitner at skidata.com> (v2)
> > Tested-by: Frieder Schrempf <frieder.schrempf at kontron.de> (v2)
> > ---
> >  drivers/gpu/drm/bridge/imx/Kconfig           |   7 +
> >  drivers/gpu/drm/bridge/imx/Makefile          |   1 +
> >  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 206 +++++++++++++++++++
> >  3 files changed, 214 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> >
> > diff --git a/drivers/gpu/drm/bridge/imx/Kconfig b/drivers/gpu/drm/bridge/imx/Kconfig
> > index 9fae28db6aa7..3a4e663d922a 100644
> > --- a/drivers/gpu/drm/bridge/imx/Kconfig
> > +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> > @@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
> >  config DRM_IMX_LDB_HELPER
> >       tristate
> >
> > +config DRM_IMX8MP_HDMI_PVI
> > +     tristate "Freescale i.MX8MP HDMI PVI bridge support"
> > +     depends on OF
> > +     help
> > +       Choose this to enable support for the internal HDMI TX Parallel
> > +       Video Interface found on the Freescale i.MX8MP SoC.
> > +
> >  config DRM_IMX8QM_LDB
> >       tristate "Freescale i.MX8QM LVDS display bridge"
> >       depends on OF
> > diff --git a/drivers/gpu/drm/bridge/imx/Makefile b/drivers/gpu/drm/bridge/imx/Makefile
> > index 8e2ebf3399a1..be9b4f9adb50 100644
> > --- a/drivers/gpu/drm/bridge/imx/Makefile
> > +++ b/drivers/gpu/drm/bridge/imx/Makefile
> > @@ -1,4 +1,5 @@
> >  obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
> > +obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
> >  obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
> >  obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
> >  obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> > diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > new file mode 100644
> > index 000000000000..5ccd70c98187
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > @@ -0,0 +1,206 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +/*
> > + * Copyright (C) 2022 Pengutronix, Lucas Stach <kernel at pengutronix.de>
> > + */
> > +
> > +#include <drm/drm_atomic_helper.h>
> > +#include <drm/drm_bridge.h>
> > +#include <drm/drm_crtc.h>
> > +#include <linux/bitfield.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of_graph.h>
> > +#include <linux/pm_runtime.h>
> > +
> > +#define HTX_PVI_CTRL                 0x0
> > +#define  PVI_CTRL_OP_VSYNC_POL               BIT(18)
> > +#define  PVI_CTRL_OP_HSYNC_POL               BIT(17)
> > +#define  PVI_CTRL_OP_DE_POL          BIT(16)
> > +#define  PVI_CTRL_INP_VSYNC_POL              BIT(14)
> > +#define  PVI_CTRL_INP_HSYNC_POL              BIT(13)
> > +#define  PVI_CTRL_INP_DE_POL         BIT(12)
> > +#define  PVI_CTRL_MODE_MASK          GENMASK(2, 1)
> > +#define  PVI_CTRL_MODE_LCDIF         2
> > +#define  PVI_CTRL_EN                 BIT(0)
> > +
> > +struct imx8mp_hdmi_pvi {
> > +     struct drm_bridge       bridge;
> > +     struct device           *dev;
> > +     struct drm_bridge       *next_bridge;
> > +     void __iomem            *regs;
> > +};
> > +
> > +static inline struct imx8mp_hdmi_pvi *
> > +to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
> > +{
> > +     return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
> > +}
> > +
> > +static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
> > +                                      enum drm_bridge_attach_flags flags)
> > +{
> > +     struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> > +
> > +     return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
> > +                              bridge, flags);
> > +}
> > +
> > +static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
> > +                                       struct drm_bridge_state *bridge_state)
> > +{
> > +     struct drm_atomic_state *state = bridge_state->base.state;
> > +     struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> > +     struct drm_connector_state *conn_state;
> > +     const struct drm_display_mode *mode;
> > +     struct drm_crtc_state *crtc_state;
> > +     struct drm_connector *connector;
> > +     u32 bus_flags, val;
> > +
> > +     connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
> > +     conn_state = drm_atomic_get_new_connector_state(state, connector);
> > +     crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
> > +
> > +     if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
> > +             return;
> > +
> > +     mode = &crtc_state->adjusted_mode;
> > +
> > +     val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
> > +
> > +     if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > +             val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
> > +
> > +     if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > +             val |= PVI_CTRL_OP_HSYNC_POL | PVI_CTRL_INP_HSYNC_POL;
> > +
> > +     if (pvi->next_bridge->timings)
> > +             bus_flags = pvi->next_bridge->timings->input_bus_flags;
> > +     else if (bridge_state)
> > +             bus_flags = bridge_state->input_bus_cfg.flags;
> > +
> > +     if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
> > +             val |= PVI_CTRL_OP_DE_POL | PVI_CTRL_INP_DE_POL;
> > +
> > +     writel(val, pvi->regs + HTX_PVI_CTRL);
> > +}
> > +
> > +static void imx8mp_hdmi_pvi_bridge_disable(struct drm_bridge *bridge,
> > +                                        struct drm_bridge_state *bridge_state)
> > +{
> > +     struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> > +
> > +     writel(0x0, pvi->regs + HTX_PVI_CTRL);
> > +
> > +     pm_runtime_put(pvi->dev);
> > +}
> > +
> > +static u32 *
> > +imx8mp_hdmi_pvi_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
> > +                                       struct drm_bridge_state *bridge_state,
> > +                                       struct drm_crtc_state *crtc_state,
> > +                                       struct drm_connector_state *conn_state,
> > +                                       u32 output_fmt,
> > +                                       unsigned int *num_input_fmts)
> > +{
> > +     struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> > +     struct drm_bridge *next_bridge = pvi->next_bridge;
> > +     struct drm_bridge_state *next_state;
> > +
> > +     if (!next_bridge->funcs->atomic_get_input_bus_fmts)
> > +             return 0;
> > +
> > +     next_state = drm_atomic_get_new_bridge_state(crtc_state->state,
> > +                                                  next_bridge);
> > +
> > +     return next_bridge->funcs->atomic_get_input_bus_fmts(next_bridge,
> > +                                                          next_state,
> > +                                                          crtc_state,
> > +                                                          conn_state,
> > +                                                          output_fmt,
> > +                                                          num_input_fmts);
> > +}
> > +
> > +static const struct drm_bridge_funcs imx_hdmi_pvi_bridge_funcs = {
> > +     .attach         = imx8mp_hdmi_pvi_bridge_attach,
> > +     .atomic_enable  = imx8mp_hdmi_pvi_bridge_enable,
> > +     .atomic_disable = imx8mp_hdmi_pvi_bridge_disable,
> > +     .atomic_get_input_bus_fmts = imx8mp_hdmi_pvi_bridge_get_input_bus_fmts,
> > +     .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> > +     .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> > +     .atomic_reset = drm_atomic_helper_bridge_reset,
> > +};
> > +
> > +static int imx8mp_hdmi_pvi_probe(struct platform_device *pdev)
> > +{
> > +     struct device_node *remote;
> > +     struct imx8mp_hdmi_pvi *pvi;
> > +
> > +     pvi = devm_kzalloc(&pdev->dev, sizeof(*pvi), GFP_KERNEL);
> > +     if (!pvi)
> > +             return -ENOMEM;
> > +
> > +     platform_set_drvdata(pdev, pvi);
> > +     pvi->dev = &pdev->dev;
> > +
> > +     pvi->regs = devm_platform_ioremap_resource(pdev, 0);
> > +     if (IS_ERR(pvi->regs))
> > +             return PTR_ERR(pvi->regs);
> > +
> > +     /* Get the next bridge in the pipeline. */
> > +     remote = of_graph_get_remote_node(pdev->dev.of_node, 1, -1);
> > +     if (!remote)
> > +             return -EINVAL;
> > +
> > +     pvi->next_bridge = of_drm_find_bridge(remote);
> > +     of_node_put(remote);
> > +
> > +     if (!pvi->next_bridge)
> > +             return dev_err_probe(&pdev->dev, -EPROBE_DEFER,
> > +                                  "could not find next bridge\n");
> > +
> > +     /* Register the bridge. */
> > +     pvi->bridge.funcs = &imx_hdmi_pvi_bridge_funcs;
> > +     pvi->bridge.of_node = pdev->dev.of_node;
> > +     pvi->bridge.timings = pvi->next_bridge->timings;
> > +
> > +     drm_bridge_add(&pvi->bridge);
> > +
> > +     pm_runtime_enable(&pdev->dev);
>
> I would move this just before drm_bridge_add(). In theory, as soon as
> the bridge is added, it could get used, so it's a good practice to
> initialize everything before adding it.
>
> > +
> > +     return 0;
> > +}
> > +
> > +static int imx8mp_hdmi_pvi_remove(struct platform_device *pdev)
> > +{
> > +     struct imx8mp_hdmi_pvi *pvi = platform_get_drvdata(pdev);
> > +
> > +     pm_runtime_disable(&pdev->dev);
> > +
> > +     drm_bridge_remove(&pvi->bridge);
>
> And here you could flip the two as well for consistency.
>
> With these minor changes,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

Lucas,

It's been a few months since there has been any action.  If you want,
I can help apply the suggestions that Laurent has and re-submit with
both of our names if you want.  It would be nice to get this
integrated.

adam
>
> > +
> > +     return 0;
> > +}
> > +
> > +static const struct of_device_id imx8mp_hdmi_pvi_match[] = {
> > +     {
> > +             .compatible = "fsl,imx8mp-hdmi-pvi",
> > +     }, {
> > +             /* sentinel */
> > +     }
> > +};
> > +MODULE_DEVICE_TABLE(of, imx8mp_hdmi_pvi_match);
> > +
> > +static struct platform_driver imx8mp_hdmi_pvi_driver = {
> > +     .probe  = imx8mp_hdmi_pvi_probe,
> > +     .remove = imx8mp_hdmi_pvi_remove,
> > +     .driver         = {
> > +             .name = "imx-hdmi-pvi",
> > +             .of_match_table = imx8mp_hdmi_pvi_match,
> > +     },
> > +};
> > +module_platform_driver(imx8mp_hdmi_pvi_driver);
> > +
> > +MODULE_DESCRIPTION("i.MX8MP HDMI TX Parallel Video Interface bridge driver");
> > +MODULE_LICENSE("GPL");
>
> --
> Regards,
>
> Laurent Pinchart


From christophe.jaillet at wanadoo.fr  Sun Dec 10 09:48:18 2023
From: christophe.jaillet at wanadoo.fr (Christophe JAILLET)
Date: Sun, 10 Dec 2023 18:48:18 +0100
Subject: [PATCH] drivers/perf: Remove usage of the deprecated ida_simple_xx() API
Message-ID: <85b0b73a1b2f743dd5db15d4765c7685100de27f.1702230488.git.christophe.jaillet@wanadoo.fr>

ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().

This is less verbose.

Signed-off-by: Christophe JAILLET <christophe.jaillet at wanadoo.fr>
---
 drivers/perf/fsl_imx9_ddr_perf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/perf/fsl_imx9_ddr_perf.c b/drivers/perf/fsl_imx9_ddr_perf.c
index 5cf770a1bc31..9685645bfe04 100644
--- a/drivers/perf/fsl_imx9_ddr_perf.c
+++ b/drivers/perf/fsl_imx9_ddr_perf.c
@@ -617,7 +617,7 @@ static int ddr_perf_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, pmu);
 
-	pmu->id = ida_simple_get(&ddr_ida, 0, 0, GFP_KERNEL);
+	pmu->id = ida_alloc(&ddr_ida, GFP_KERNEL);
 	name = devm_kasprintf(&pdev->dev, GFP_KERNEL, DDR_PERF_DEV_NAME "%d", pmu->id);
 	if (!name) {
 		ret = -ENOMEM;
@@ -674,7 +674,7 @@ static int ddr_perf_probe(struct platform_device *pdev)
 	cpuhp_remove_multi_state(pmu->cpuhp_state);
 cpuhp_state_err:
 format_string_err:
-	ida_simple_remove(&ddr_ida, pmu->id);
+	ida_free(&ddr_ida, pmu->id);
 	dev_warn(&pdev->dev, "i.MX9 DDR Perf PMU failed (%d), disabled\n", ret);
 	return ret;
 }
@@ -688,7 +688,7 @@ static int ddr_perf_remove(struct platform_device *pdev)
 
 	perf_pmu_unregister(&pmu->pmu);
 
-	ida_simple_remove(&ddr_ida, pmu->id);
+	ida_free(&ddr_ida, pmu->id);
 
 	return 0;
 }
-- 
2.34.1



From robdclark at gmail.com  Sun Dec 10 10:06:53 2023
From: robdclark at gmail.com (Rob Clark)
Date: Sun, 10 Dec 2023 10:06:53 -0800
Subject: [PATCH v2] iommu/arm-smmu-qcom: Add missing GMU entry to match table
Message-ID: <20231210180655.75542-1-robdclark@gmail.com>

From: Rob Clark <robdclark at chromium.org>

In some cases the firmware expects cbndx 1 to be assigned to the GMU,
so we also want the default domain for the GMU to be an identy domain.
This way it does not get a context bank assigned.  Without this, both
of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
allocating and configuring a context bank.  So GMU ends up attached to
both cbndx 1 and later cbndx 2.  This arrangement seemingly confounds
and surprises the firmware if the GPU later triggers a translation
fault, resulting (on sc8280xp / lenovo x13s, at least) in the SMMU
getting wedged and the GPU stuck without memory access.

Cc: stable at vger.kernel.org
Signed-off-by: Rob Clark <robdclark at chromium.org>
---

I didn't add a fixes tag because really this issue has been there
all along, but either didn't matter with other firmware or we didn't 
notice the problem.

 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 549ae4dba3a6..d326fa230b96 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -243,6 +243,7 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 
 static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
 	{ .compatible = "qcom,adreno" },
+	{ .compatible = "qcom,adreno-gmu" },
 	{ .compatible = "qcom,mdp4" },
 	{ .compatible = "qcom,mdss" },
 	{ .compatible = "qcom,sc7180-mdss" },
-- 
2.43.0



From broonie at kernel.org  Sun Dec 10 13:10:56 2023
From: broonie at kernel.org (Mark Brown)
Date: Sun, 10 Dec 2023 21:10:56 +0000
Subject: [PATCH] ASoC: wm1250-ev1: Fix uninitialized ret
In-Reply-To: <20231209-descriptors-sound-wlf-v1-1-5b885ce43ae1@linaro.org>
References: <20231209-descriptors-sound-wlf-v1-1-5b885ce43ae1@linaro.org>
Message-ID: <170224265642.2977176.17197693476298409878.b4-ty@kernel.org>

On Sat, 09 Dec 2023 23:01:27 +0100, Linus Walleij wrote:
> The GPIO descriptor conversion patch left an unitialized ret behind
> by mistake, fix it by getting rid of the variable altogether.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: wm1250-ev1: Fix uninitialized ret
      commit: 5012f9d8acd411bc86229d75c0bb9517f84a60ec

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From sfr at canb.auug.org.au  Sun Dec 10 14:02:59 2023
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Mon, 11 Dec 2023 09:02:59 +1100
Subject: linux-next: Signed-off-by missing for commit in the mvebu tree
Message-ID: <20231211090259.35d1ade6@canb.auug.org.au>

Hi all,

Commits

  8b3ebdf4f061 ("ARM: dts: marvell: make dts use gpio-fan matrix instead of array")
  c431744e514e ("ARM64: dts: Add special compatibles for the Turris Mox")
  818a1801d196 ("ARM64: dts: marvell: Fix some common switch mistakes")
  5c0b28f30f65 ("ARM: dts: marvell: Fix some common switch mistakes")
  e10957e4973c ("MAINTAINERS: add Marvell MBus driver to Marvell EBU SoCs support")

are missing a Signed-off-by from their committer.

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/0f0ef634/attachment.sig>

From u.kleine-koenig at pengutronix.de  Sun Dec 10 14:12:18 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 10 Dec 2023 23:12:18 +0100
Subject: [PATCH 03/12] hwrng: exynos - Convert to platform remove callback returning void
In-Reply-To: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>
Message-ID: <817e91f7bb257745c0fb483037b83c1a6ba14e75.1702245873.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/char/hw_random/exynos-trng.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
index 30207b7ac5f4..0ed5d22fe667 100644
--- a/drivers/char/hw_random/exynos-trng.c
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -173,7 +173,7 @@ static int exynos_trng_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int exynos_trng_remove(struct platform_device *pdev)
+static void exynos_trng_remove(struct platform_device *pdev)
 {
 	struct exynos_trng_dev *trng =  platform_get_drvdata(pdev);
 
@@ -181,8 +181,6 @@ static int exynos_trng_remove(struct platform_device *pdev)
 
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
-
-	return 0;
 }
 
 static int exynos_trng_suspend(struct device *dev)
@@ -223,7 +221,7 @@ static struct platform_driver exynos_trng_driver = {
 		.of_match_table = exynos_trng_dt_match,
 	},
 	.probe = exynos_trng_probe,
-	.remove = exynos_trng_remove,
+	.remove_new = exynos_trng_remove,
 };
 
 module_platform_driver(exynos_trng_driver);
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Sun Dec 10 14:12:16 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 10 Dec 2023 23:12:16 +0100
Subject: [PATCH 01/12] hwrng: atmel - Convert to platform remove callback returning void
In-Reply-To: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>
Message-ID: <89f6eebfa85b31c635b774e613f19b84b32f3e1f.1702245873.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/char/hw_random/atmel-rng.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
index a37367ebcbac..e9157255f851 100644
--- a/drivers/char/hw_random/atmel-rng.c
+++ b/drivers/char/hw_random/atmel-rng.c
@@ -161,15 +161,13 @@ static int atmel_trng_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int atmel_trng_remove(struct platform_device *pdev)
+static void atmel_trng_remove(struct platform_device *pdev)
 {
 	struct atmel_trng *trng = platform_get_drvdata(pdev);
 
 	atmel_trng_cleanup(trng);
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
-
-	return 0;
 }
 
 static int __maybe_unused atmel_trng_runtime_suspend(struct device *dev)
@@ -218,7 +216,7 @@ MODULE_DEVICE_TABLE(of, atmel_trng_dt_ids);
 
 static struct platform_driver atmel_trng_driver = {
 	.probe		= atmel_trng_probe,
-	.remove		= atmel_trng_remove,
+	.remove_new	= atmel_trng_remove,
 	.driver		= {
 		.name	= "atmel-trng",
 		.pm	= pm_ptr(&atmel_trng_pm_ops),
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Sun Dec 10 14:12:15 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 10 Dec 2023 23:12:15 +0100
Subject: [PATCH 00/12] hwrng: Convert to platform remove callback returning 
Message-ID: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>

Hello,

this series converts all hwrng platform drivers to use .remove_new.
See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for details and the eventual goal.

All driver conversions are trivial as all their remove callbacks return
0 (as good drivers should do).

All patches are pairwise independant. These patches should go in via the
usual hwrng tree. It's merge window material.

Best regards
Uwe

Uwe Kleine-K?nig (12):
  hwrng: atmel - Convert to platform remove callback returning void
  hwrng: cctrng - Convert to platform remove callback returning void
  hwrng: exynos - Convert to platform remove callback returning void
  hwrng: ingenic - Convert to platform remove callback returning void
  hwrng: ks-sa - Convert to platform remove callback returning void
  hwrng: mxc - Convert to platform remove callback returning void
  hwrng: n2 - Convert to platform remove callback returning void
  hwrng: npcm - Convert to platform remove callback returning void
  hwrng: omap - Convert to platform remove callback returning void
  hwrng: stm32 - Convert to platform remove callback returning void
  hwrng: timeriomem - Convert to platform remove callback returning void
  hwrng: xgene - Convert to platform remove callback returning void

 drivers/char/hw_random/atmel-rng.c      | 6 ++----
 drivers/char/hw_random/cctrng.c         | 6 ++----
 drivers/char/hw_random/exynos-trng.c    | 6 ++----
 drivers/char/hw_random/ingenic-rng.c    | 6 ++----
 drivers/char/hw_random/ks-sa-rng.c      | 6 ++----
 drivers/char/hw_random/mxc-rnga.c       | 6 ++----
 drivers/char/hw_random/n2-drv.c         | 6 ++----
 drivers/char/hw_random/npcm-rng.c       | 6 ++----
 drivers/char/hw_random/omap-rng.c       | 6 ++----
 drivers/char/hw_random/stm32-rng.c      | 6 ++----
 drivers/char/hw_random/timeriomem-rng.c | 6 ++----
 drivers/char/hw_random/xgene-rng.c      | 6 ++----
 12 files changed, 24 insertions(+), 48 deletions(-)


base-commit: bc63de6e6ba0b16652c5fb4b9c9916b9e7ca1f23
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Sun Dec 10 14:12:25 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 10 Dec 2023 23:12:25 +0100
Subject: [PATCH 10/12] hwrng: stm32 - Convert to platform remove callback returning void
In-Reply-To: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>
Message-ID: <855e8e89de0c0e2a82e181b883275754f8c16a38.1702245873.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/char/hw_random/stm32-rng.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
index 41e1dbea5d2e..98c92b914cfd 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -362,11 +362,9 @@ static int stm32_rng_init(struct hwrng *rng)
 	return 0;
 }
 
-static int stm32_rng_remove(struct platform_device *ofdev)
+static void stm32_rng_remove(struct platform_device *ofdev)
 {
 	pm_runtime_disable(&ofdev->dev);
-
-	return 0;
 }
 
 static int __maybe_unused stm32_rng_runtime_suspend(struct device *dev)
@@ -557,7 +555,7 @@ static struct platform_driver stm32_rng_driver = {
 		.of_match_table = stm32_rng_match,
 	},
 	.probe = stm32_rng_probe,
-	.remove = stm32_rng_remove,
+	.remove_new = stm32_rng_remove,
 };
 
 module_platform_driver(stm32_rng_driver);
-- 
2.42.0



From jmattson at google.com  Sun Dec 10 14:52:59 2023
From: jmattson at google.com (Jim Mattson)
Date: Sun, 10 Dec 2023 14:52:59 -0800
Subject: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()
In-Reply-To: <ZXHw7tykubfG04Um@google.com>
References: <20220921003201.1441511-11-seanjc@google.com> <20231207010302.2240506-1-jmattson@google.com>
 <ZXHw7tykubfG04Um@google.com>
Message-ID: <CALMp9eTT97oDmQT7pxeOMLQbt-371aMtC2Kev+-kWXVRDVrjeg@mail.gmail.com>

On Thu, Dec 7, 2023 at 8:21?AM Sean Christopherson <seanjc at google.com> wrote:
> Doh.  We got the less obvious cases and missed the obvious one.
>
> Ugh, and we also missed a related mess in kvm_guest_apic_has_interrupt().  That
> thing should really be folded into vmx_has_nested_events().
>
> Good gravy.  And vmx_interrupt_blocked() does the wrong thing because that
> specifically checks if L1 interrupts are blocked.
>
> Compile tested only, and definitely needs to be chunked into multiple patches,
> but I think something like this mess?

The proposed patch does not fix the problem. In fact, it messes things
up so much that I don't get any test results back.

Google has an internal K-U-T test that demonstrates the problem. I
will post it soon.


From semen.protsenko at linaro.org  Sun Dec 10 15:34:16 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Sun, 10 Dec 2023 17:34:16 -0600
Subject: [PATCH v6 09/20] dt-bindings: serial: samsung: Make
 samsung,uart-fifosize a required property
In-Reply-To: <20231209233106.147416-10-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org> <20231209233106.147416-10-peter.griffin@linaro.org>
Message-ID: <CAPLW+4mztK2HEKh5S--tdi0p8i5sYOHHBoTFnfH=9X+vMXxOuQ@mail.gmail.com>

On Sat, Dec 9, 2023 at 5:31?PM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Specifying samsung,uart-fifosize in both DT and driver static data is error
> prone and relies on driver probe order and dt aliases to be correct.
>
> Additionally on many Exynos platforms these are (USI) universal serial
> interfaces which can be uart, spi or i2c, so it can change per board.
>
> For google,gs101-uart make samsung,uart-fifosize a required property.
> For this platform fifosize now *only* comes from DT.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  .../devicetree/bindings/serial/samsung_uart.yaml       | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index ccc3626779d9..65d5d361e8f4 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -133,6 +133,16 @@ allOf:
>              - const: uart
>              - const: clk_uart_baud0
>
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - google,gs101-uart
> +    then:
> +      required:
> +        - samsung,uart-fifosize
> +
>  unevaluatedProperties: false
>
>  examples:
> --
> 2.43.0.472.g3155946c3a-goog
>


From semen.protsenko at linaro.org  Sun Dec 10 15:34:31 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Sun, 10 Dec 2023 17:34:31 -0600
Subject: [PATCH v6 10/20] dt-bindings: soc: samsung: usi: add
 google,gs101-usi compatible
In-Reply-To: <20231209233106.147416-11-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org> <20231209233106.147416-11-peter.griffin@linaro.org>
Message-ID: <CAPLW+4k=k9-TTB4YOyT7NyzfNORNLDJMtHBwfLtdZV52CMgxXQ@mail.gmail.com>

On Sat, Dec 9, 2023 at 5:31?PM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
>
> Add google,gs101-usi dedicated compatible for representing USI of Google
> GS101 SoC.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> index 61be1f2ddbe7..8b478d6cdc30 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> @@ -25,6 +25,7 @@ properties:
>      oneOf:
>        - items:
>            - enum:
> +              - google,gs101-usi
>                - samsung,exynosautov9-usi
>                - samsung,exynosautov920-usi
>            - const: samsung,exynos850-usi
> --
> 2.43.0.472.g3155946c3a-goog
>


From semen.protsenko at linaro.org  Sun Dec 10 15:36:24 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Sun, 10 Dec 2023 17:36:24 -0600
Subject: [PATCH v6 12/20] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <20231209233106.147416-13-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org> <20231209233106.147416-13-peter.griffin@linaro.org>
Message-ID: <CAPLW+4nuYHbLuLX=HGsDz6WYtZV3P7yBEmhCXbLW2M+dF1asow@mail.gmail.com>

On Sat, Dec 9, 2023 at 5:31?PM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> cmu_top is the top level clock management unit which contains PLLs, muxes,
> dividers and gates that feed the other clock management units.
>
> cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> APM module.
>
> Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> Tested-by: Will McVicker <willmcvicker at google.com>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

[snip]


From semen.protsenko at linaro.org  Sun Dec 10 15:37:25 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Sun, 10 Dec 2023 17:37:25 -0600
Subject: [PATCH v6 15/20] watchdog: s3c2410_wdt: Update QUIRK macros to
 use BIT macro
In-Reply-To: <20231209233106.147416-16-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org> <20231209233106.147416-16-peter.griffin@linaro.org>
Message-ID: <CAPLW+4nUT8Nf9zC6UrAMJ_OpLNqe7JWxKy7xp1+_+emNgG4qkA@mail.gmail.com>

On Sat, Dec 9, 2023 at 5:31?PM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Update the remaining QUIRK macros to use the BIT macro.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  drivers/watchdog/s3c2410_wdt.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> index 7ecb762a371d..b7a03668f743 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -107,11 +107,11 @@
>   * DBGACK_MASK bit disables the watchdog outputs when the SoC is in debug mode.
>   * Debug mode is determined by the DBGACK CPU signal.
>   */
> -#define QUIRK_HAS_WTCLRINT_REG                 (1 << 0)
> -#define QUIRK_HAS_PMU_MASK_RESET               (1 << 1)
> -#define QUIRK_HAS_PMU_RST_STAT                 (1 << 2)
> -#define QUIRK_HAS_PMU_AUTO_DISABLE             (1 << 3)
> -#define QUIRK_HAS_PMU_CNT_EN                   (1 << 4)
> +#define QUIRK_HAS_WTCLRINT_REG                 BIT(0)
> +#define QUIRK_HAS_PMU_MASK_RESET               BIT(1)
> +#define QUIRK_HAS_PMU_RST_STAT                 BIT(2)
> +#define QUIRK_HAS_PMU_AUTO_DISABLE             BIT(3)
> +#define QUIRK_HAS_PMU_CNT_EN                   BIT(4)
>  #define QUIRK_HAS_DBGACK_BIT                   BIT(5)
>
>  /* These quirks require that we have a PMU register map */
> --
> 2.43.0.472.g3155946c3a-goog
>


From semen.protsenko at linaro.org  Sun Dec 10 15:39:39 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Sun, 10 Dec 2023 17:39:39 -0600
Subject: [PATCH] dt-bindings: samsung: exynos-sysreg: combine
 exynosautov920 with other enum
In-Reply-To: <20231210134834.43943-1-krzysztof.kozlowski@linaro.org>
References: <20231210134834.43943-1-krzysztof.kozlowski@linaro.org>
Message-ID: <CAPLW+4nKzYLTPpTAba9X3YmeGwY_avpZoPr=Lw8Uy7ktSkH4_w@mail.gmail.com>

On Sun, Dec 10, 2023 at 7:48?AM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> No need to create a new enum every time we bring-up new SoC.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  .../bindings/soc/samsung/samsung,exynos-sysreg.yaml        | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> index 2de4301a467d..b00f25482fec 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> @@ -17,6 +17,8 @@ properties:
>                - samsung,exynos3-sysreg
>                - samsung,exynos4-sysreg
>                - samsung,exynos5-sysreg
> +              - samsung,exynosautov920-peric0-sysreg
> +              - samsung,exynosautov920-peric1-sysreg
>                - tesla,fsd-cam-sysreg
>                - tesla,fsd-fsys0-sysreg
>                - tesla,fsd-fsys1-sysreg
> @@ -50,11 +52,6 @@ properties:
>                - samsung,exynosautov9-peric1-sysreg
>            - const: samsung,exynosautov9-sysreg
>            - const: syscon
> -      - items:
> -          - enum:
> -              - samsung,exynosautov920-peric0-sysreg
> -              - samsung,exynosautov920-peric1-sysreg
> -          - const: syscon
>
>    reg:
>      maxItems: 1
> --
> 2.34.1
>
>


From semen.protsenko at linaro.org  Sun Dec 10 15:44:08 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Sun, 10 Dec 2023 17:44:08 -0600
Subject: [PATCH v6 13/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <46c9c8b4-942d-4f6f-a6cc-00158314d5e5@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-14-peter.griffin@linaro.org> <46c9c8b4-942d-4f6f-a6cc-00158314d5e5@linaro.org>
Message-ID: <CAPLW+4k3omxnWoDhB9UCgv6botjNxKAn804jNfrHseaZsnMJ3A@mail.gmail.com>

On Sun, Dec 10, 2023 at 7:55?AM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 10/12/2023 00:30, Peter Griffin wrote:
> > Add support for the pin-controller found on the gs101 SoC used in
> > Pixel 6 phones.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
>
>
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > index 6b58ec84e34b..3834bf953178 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > @@ -468,6 +468,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
> >                       .data = &exynos7_wkup_irq_chip },
> >       { .compatible = "samsung,exynosautov9-wakeup-eint",
> >                       .data = &exynos7_wkup_irq_chip },
> > +     { .compatible = "google,gs101-wakeup-eint",
> > +                     .data = &exynos7_wkup_irq_chip },
>
> You don't need it.
>
> >       { }
> >  };
> >
> > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > index 79babbb39ced..b8d549fe38cb 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > @@ -1321,6 +1321,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
> >               .data = &exynosautov9_of_data },
> >       { .compatible = "tesla,fsd-pinctrl",
> >               .data = &fsd_of_data },
> > +     { .compatible = "google,gs101-pinctrl",
> > +             .data = &gs101_of_data },
>
> Place it somewhere alphabetically. Probably before tesla.
>

Assuming Krzysztof's comments are fixed, you can also add:

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>
> Best regards,
> Krzysztof
>


From semen.protsenko at linaro.org  Sun Dec 10 15:47:49 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Sun, 10 Dec 2023 17:47:49 -0600
Subject: [PATCH v6 18/20] arm64: dts: exynos: google: Add initial Google
 gs101 SoC support
In-Reply-To: <8400d76b-2a04-4d60-ad6c-954dca07562f@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-19-peter.griffin@linaro.org> <8400d76b-2a04-4d60-ad6c-954dca07562f@linaro.org>
Message-ID: <CAPLW+4=b5SoX8ngPhzjtf9bE+7bJcV+gS_0ocD=mKAX6Z8B1Qg@mail.gmail.com>

On Sun, Dec 10, 2023 at 8:38?AM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 10/12/2023 00:31, Peter Griffin wrote:
> > Google gs101 SoC is a ARMv8 mobile SoC found in the Pixel 6
> > (oriole), Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
> > phones.
> >
> > It features:
> > * 4xA55 Little cluster
> > * 2xA76 Mid cluster
> > * 2xX1 Big cluster
> >
>
> ...
>
> > diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> > new file mode 100644
> > index 000000000000..68b7bc47c91b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> > @@ -0,0 +1,33 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Pinctrl binding constants for GS101
> > + *
> > + * Copyright 2020-2023 Google LLC
> > + */
> > +
> > +#ifndef __DT_BINDINGS_PINCTRL_GS101_H__
> > +#define __DT_BINDINGS_PINCTRL_GS101_H__
>
> Header guards don't really match location.
>
> > +
> > +#define GS101_PIN_PULL_NONE          0
> > +#define GS101_PIN_PULL_DOWN          1
> > +#define GS101_PIN_PULL_UP            3
> > +
> > +/* Pin function in power down mode */
> > +#define GS101_PIN_PDN_OUT0           0
> > +#define GS101_PIN_PDN_OUT1           1
> > +#define GS101_PIN_PDN_INPUT          2
> > +#define GS101_PIN_PDN_PREV           3
> > +
> > +/* GS101 drive strengths */
> > +#define GS101_PIN_DRV_2_5_MA         0
> > +#define GS101_PIN_DRV_5_MA           1
> > +#define GS101_PIN_DRV_7_5_MA         2
> > +#define GS101_PIN_DRV_10_MA          3
> > +
> > +#define GS101_PIN_FUNC_INPUT         0
> > +#define GS101_PIN_FUNC_OUTPUT                1
> > +#define GS101_PIN_FUNC_2             2
> > +#define GS101_PIN_FUNC_3             3
> > +#define GS101_PIN_FUNC_EINT          0xf
> > +
> > +#endif /* __DT_BINDINGS_PINCTRL_GS101_H__ */
> > diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> > new file mode 100644
> > index 000000000000..60e112d25246
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> > @@ -0,0 +1,476 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * GS101 SoC
> > + *
> > + * Copyright 2019-2023 Google LLC
> > + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> > + */
> > +
> > +#include <dt-bindings/clock/google,gs101.h>
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/soc/samsung,exynos-usi.h>
> > +
> > +/ {
> > +     compatible = "google,gs101";
> > +     #address-cells = <2>;
> > +     #size-cells = <1>;
> > +
> > +     interrupt-parent = <&gic>;
> > +
> > +     aliases {
> > +             pinctrl0 = &pinctrl_gpio_alive;
> > +             pinctrl1 = &pinctrl_far_alive;
> > +             pinctrl2 = &pinctrl_gsacore;
> > +             pinctrl3 = &pinctrl_gsactrl;
> > +             pinctrl4 = &pinctrl_peric0;
> > +             pinctrl5 = &pinctrl_peric1;
> > +             pinctrl6 = &pinctrl_hsi1;
> > +             pinctrl7 = &pinctrl_hsi2;
> > +     };
> > +
> > +     pmu-0 {
> > +             compatible = "arm,cortex-a55-pmu";
> > +             interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
> > +     };
> > +
> > +     pmu-1 {
> > +             compatible = "arm,cortex-a76-pmu";
> > +             interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
> > +     };
> > +
> > +     pmu-2 {
> > +             compatible = "arm,cortex-x1-pmu";
> > +             interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster2>;
> > +     };
> > +
> > +     pmu-3 {
> > +             compatible = "arm,dsu-pmu";
> > +             interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH 0>;
> > +             cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
> > +                    <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
> > +     };
>
> Keep alphabetical order of top-level nodes. pmu should be before psci
>
> > +
> > +     /* TODO replace with CCF clock */
> > +     dummy_clk: oscillator {
>
> clock-3
>
> > +             compatible = "fixed-clock";
> > +             #clock-cells = <0>;
> > +             clock-frequency = <12345>;
> > +             clock-output-names = "pclk";
> > +     };
> > +
> > +     cpus {
> > +             #address-cells = <1>;
> > +             #size-cells = <0>;
> > +
> > +             cpu-map {
> > +                     cluster0 {
> > +                             core0 {
> > +                                     cpu = <&cpu0>;
> > +                             };
> > +                             core1 {
> > +                                     cpu = <&cpu1>;
> > +                             };
> > +                             core2 {
> > +                                     cpu = <&cpu2>;
> > +                             };
> > +                             core3 {
> > +                                     cpu = <&cpu3>;
> > +                             };
> > +                     };
> > +
> > +                     cluster1 {
> > +                             core0 {
> > +                                     cpu = <&cpu4>;
> > +                             };
> > +                             core1 {
> > +                                     cpu = <&cpu5>;
> > +                             };
> > +                     };
> > +
> > +                     cluster2 {
> > +                             core0 {
> > +                                     cpu = <&cpu6>;
> > +                             };
> > +                             core1 {
> > +                                     cpu = <&cpu7>;
> > +                             };
> > +                     };
> > +             };
>
> ...
>
> > +
> > +     /* ect node is required to be present by bootloader */
> > +     ect {
> > +     };
>
> alphabetical order
>
> > +
> > +     ext_24_5m: clock-1 {
> > +             compatible = "fixed-clock";
> > +             #clock-cells = <0>;
> > +             clock-output-names = "oscclk";
> > +     };
> > +
> > +     ext_200m: clock-2 {
> > +             compatible = "fixed-clock";
> > +             #clock-cells = <0>;
> > +             clock-output-names = "ext-200m";
> > +     };
> > +
> > +     psci {
> > +             compatible = "arm,psci-1.0";
> > +             method = "smc";
> > +     };
> > +
> > +     reserved_memory: reserved-memory {
> > +             #address-cells = <2>;
> > +             #size-cells = <1>;
> > +             ranges;
> > +
> > +             gsa_reserved_protected: gsa at 90200000 {
> > +                     reg = <0x0 0x90200000 0x400000>;
> > +                     no-map;
> > +             };
> > +
> > +             tpu_fw_reserved: tpu-fw at 93000000 {
> > +                     reg = <0x0 0x93000000 0x1000000>;
> > +                     no-map;
> > +             };
> > +
> > +             aoc_reserve: aoc at 94000000 {
> > +                     reg = <0x0 0x94000000 0x03000000>;
> > +                     no-map;
> > +             };
> > +
> > +             abl_reserved: abl at f8800000 {
> > +                     reg = <0x0 0xf8800000 0x02000000>;
> > +                     no-map;
> > +             };
> > +
> > +             dss_log_reserved: dss-log-reserved at fd3f0000 {
> > +                     reg = <0x0 0xfd3f0000 0x0000e000>;
> > +                     no-map;
> > +             };
> > +
> > +             debug_kinfo_reserved: debug-kinfo-reserved at fd3fe000 {
> > +                     reg = <0x0 0xfd3fe000 0x00001000>;
> > +                     no-map;
> > +             };
> > +
> > +             bldr_log_reserved: bldr-log-reserved at fd800000 {
> > +                     reg = <0x0 0xfd800000 0x00100000>;
> > +                     no-map;
> > +             };
> > +
> > +             bldr_log_hist_reserved: bldr-log-hist-reserved at fd900000 {
> > +                     reg = <0x0 0xfd900000 0x00002000>;
> > +                     no-map;
> > +             };
> > +     };
> > +
> > +     timer {
>
> alphabetical order, so this goes to the end
>
> > +             compatible = "arm,armv8-timer";
> > +             interrupts =
> > +                <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> > +                <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> > +                <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> > +                <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>;
> > +             clock-frequency = <24576000>;
>
> I don't remember if you already got Marc's wrath, so just in case: are
> you sure it is needed?
>
> Anyway, this is board specific, not SoC.
>
> > +     };
> > +
> > +     soc: soc at 0 {
> > +             compatible = "simple-bus";
> > +             #address-cells = <1>;
> > +             #size-cells = <1>;
> > +             ranges = <0x0 0x0 0x0 0x40000000>;
> > +
> > +             cmu_misc: clock-controller at 10010000 {
> > +                     compatible = "google,gs101-cmu-misc";
> > +                     reg = <0x10010000 0x8000>;
> > +                     #clock-cells = <1>;
> > +                     clocks =  <&cmu_top CLK_DOUT_CMU_MISC_BUS>,
>
> One space after =
>
> > +                               <&cmu_top CLK_DOUT_CMU_MISC_SSS>;
> > +                     clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
> > +             };
> > +
> > +             watchdog_cl0: watchdog at 10060000 {
> > +                     compatible = "google,gs101-wdt";
> > +                     reg = <0x10060000 0x100>;
> > +                     interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH 0>;
> > +                     clocks =
> > +                       <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0_PCLK>,
>
> Join lines (clocks = <foo bar>). Same in other places.
>
> > +                       <&ext_24_5m>;
> > +                     clock-names = "watchdog", "watchdog_src";
> > +                     samsung,syscon-phandle = <&pmu_system_controller>;
> > +                     samsung,cluster-index = <0>;
> > +                     status = "disabled";
> > +             };
> > +
> > +             watchdog_cl1: watchdog at 10070000 {
> > +                     compatible = "google,gs101-wdt";
> > +                     reg = <0x10070000 0x100>;
> > +                     interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH 0>;
> > +                     clocks =
> > +                       <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1_PCLK>,
> > +                       <&ext_24_5m>;
> > +                     clock-names = "watchdog", "watchdog_src";
> > +                     samsung,syscon-phandle = <&pmu_system_controller>;
> > +                     samsung,cluster-index = <1>;
> > +                     status = "disabled";
> > +             };
> > +
> > +             gic: interrupt-controller at 10400000 {
> > +                     compatible = "arm,gic-v3";
> > +                     #interrupt-cells = <4>;
> > +                     interrupt-controller;
> > +                     reg = <0x10400000 0x10000>, /* GICD */
> > +                           <0x10440000 0x100000>;/* GICR * 8 */
> > +                     interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
> > +
> > +                     ppi-partitions {
> > +                             ppi_cluster0: interrupt-partition-0 {
> > +                                     affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
> > +                             };
> > +
> > +                             ppi_cluster1: interrupt-partition-1 {
> > +                                     affinity = <&cpu4 &cpu5>;
> > +                             };
> > +
> > +                             ppi_cluster2: interrupt-partition-2 {
> > +                                     affinity = <&cpu6 &cpu7>;
> > +                             };
> > +                     };
> > +             };
> > +
> > +             sysreg_peric0: syscon at 10820000 {
> > +                     compatible = "google,gs101-peric0-sysreg", "syscon";
> > +                     reg = <0x10820000 0x10000>;
> > +             };
> > +
> > +             pinctrl_peric0: pinctrl at 10840000 {
> > +                     compatible = "google,gs101-pinctrl";
> > +                     reg = <0x10840000 0x00001000>;
> > +                     interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> > +             };
> > +
> > +             usi_uart: usi at 10a000c0 {
> > +                     compatible = "google,gs101-usi",
> > +                                  "samsung,exynos850-usi";
> > +                     reg = <0x10a000c0 0x20>;
> > +                     samsung,sysreg = <&sysreg_peric0 0x1020>;
> > +                     samsung,mode = <USI_V2_UART>;
>
> vendor properties go to the end, after standard properties, before status.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst?h=dt/next&id=0d3a771610d0e155c9aa305f142f84dda5030fae#n122
>
> > +                     #address-cells = <1>;
> > +                     #size-cells = <1>;
> > +                     ranges;
> > +                     clocks = <&dummy_clk>, <&dummy_clk>;
> > +                     clock-names = "pclk", "ipclk";
> > +                     status = "disabled";
> > +
> > +                     serial_0: serial at 10a00000 {
> > +                             compatible = "google,gs101-uart";
> > +                             reg = <0x10a00000 0xc0>;
> > +                             reg-io-width = <4>;
> > +                             samsung,uart-fifosize = <256>;
>
> Ditto
>

Assuming Krzysztof's comments are fixed, feel free to add:

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

> > +                             interrupts = <GIC_SPI 634
> > +                                           IRQ_TYPE_LEVEL_HIGH 0>;
> > +                             clocks = <&dummy_clk 0>, <&dummy_clk 0>;
> > +                             clock-names = "uart", "clk_uart_baud0";
> > +                             status = "disabled";
> > +                     };
> > +             };
>
>
> Best regards,
> Krzysztof
>


From andre.przywara at arm.com  Sun Dec 10 16:05:28 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 11 Dec 2023 00:05:28 +0000
Subject: [PATCH v3 5/6] thermal: sun8i: add support for H616 THS
 controller
In-Reply-To: <a14fb458-caf0-4a4a-b76b-c2503b0840d2@gmail.com>
References: <20231128005849.19044-6-andre.przywara@arm.com>
	<a14fb458-caf0-4a4a-b76b-c2503b0840d2@gmail.com>
Message-ID: <20231211000528.57cb646c@minigeek.lan>

On Sat, 9 Dec 2023 13:44:34 +0300
Maksim Kiselev <bigunclemax at gmail.com> wrote:

Hi Maksim,

> Hi Martin, Andre.
> 
> May I inquire? Why do we need a separate sun50i_h616_ths_calibrate() 
> function? Why can't we just extend an existing sun50i_h6_ths_calibrate()?
> 
> At my glance the calculations in both functions are the same. We just 
> need to handle a special case for the 4th sensor.

You seem to be right, they are indeed the same, just written slightly
differently. Do you already have any patches that unify that?
I don't know if Martin or I find time to do it this week, but we could
also optimise this later.

Cheers,
Andre


From yuji2.ishikawa at toshiba.co.jp  Sun Dec 10 16:35:16 2023
From: yuji2.ishikawa at toshiba.co.jp (yuji2.ishikawa at toshiba.co.jp)
Date: Mon, 11 Dec 2023 00:35:16 +0000
Subject: [PATCH v9 3/5] media: platform: visconti: add V4L2 vendor
 specific control handlers
In-Reply-To: <TYAPR01MB62019C91FAC70080B967D34792BDA@TYAPR01MB6201.jpnprd01.prod.outlook.com>
References: <20231012071329.2542003-1-yuji2.ishikawa@toshiba.co.jp>
 <20231012071329.2542003-4-yuji2.ishikawa@toshiba.co.jp>
 <6095bd3d-2580-44e2-b622-3ad31e12787f@xs4all.nl>
 <a84ce942-e6df-414e-8d0c-e7d3ef3e62f6@xs4all.nl>
 <20231114095331.GA13826@pendragon.ideasonboard.com>
 <TYAPR01MB62019C91FAC70080B967D34792BDA@TYAPR01MB6201.jpnprd01.prod.outlook.com>
Message-ID: <TYAPR01MB62016F3B9393205068AAE65A928FA@TYAPR01MB6201.jpnprd01.prod.outlook.com>

Hello Laurent,

> -----Original Message-----
> From: ishikawa yuji(?? ?? ?????????????)
> Sent: Monday, November 27, 2023 9:47 AM
> To: Laurent Pinchart <laurent.pinchart at ideasonboard.com>; Hans Verkuil
> <hverkuil at xs4all.nl>
> Cc: Mauro Carvalho Chehab <mchehab at kernel.org>; Rob Herring
> <robh+dt at kernel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt at linaro.org>; Conor Dooley <conor+dt at kernel.org>;
> iwamatsu nobuhiro(?? ?? ?????????????)
> <nobuhiro1.iwamatsu at toshiba.co.jp>; linux-media at vger.kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: RE: [PATCH v9 3/5] media: platform: visconti: add V4L2 vendor
> specific control handlers
> 
> Hello Laurent,
> 
> Thank you for your comment.
> 
> > -----Original Message-----
> > From: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > Sent: Tuesday, November 14, 2023 6:54 PM
> > To: Hans Verkuil <hverkuil at xs4all.nl>
> > Cc: ishikawa yuji(?? ?? ?????????????)
> > <yuji2.ishikawa at toshiba.co.jp>; Mauro Carvalho Chehab
> > <mchehab at kernel.org>; Rob Herring <robh+dt at kernel.org>; Krzysztof
> > Kozlowski <krzysztof.kozlowski+dt at linaro.org>; Conor Dooley
> > <conor+dt at kernel.org>; iwamatsu nobuhiro(?? ?? ??????????
> > ???) <nobuhiro1.iwamatsu at toshiba.co.jp>;
> linux-media at vger.kernel.org;
> > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > linux-kernel at vger.kernel.org
> > Subject: Re: [PATCH v9 3/5] media: platform: visconti: add V4L2 vendor
> > specific control handlers
> >
> > On Tue, Nov 14, 2023 at 10:10:50AM +0100, Hans Verkuil wrote:
> > > On 14/11/2023 10:02, Hans Verkuil wrote:
> > > > On 12/10/2023 09:13, Yuji Ishikawa wrote:
> > > >> Add support to Image Signal Processors of Visconti's Video Input
> > Interface.
> > > >> This patch adds vendor specific compound controls to configure
> > > >> the image signal processor.
> > > >>
> > > >> Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
> > > >> ---
> > > >> Changelog v2:
> > > >> - Resend v1 because a patch exceeds size limit.
> > > >>
> > > >> Changelog v3:
> > > >> - Adapted to media control framework
> > > >> - Introduced ISP subdevice, capture device
> > > >> - Remove private IOCTLs and add vendor specific V4L2 controls
> > > >> - Change function name avoiding camelcase and uppercase letters
> > > >>
> > > >> Changelog v4:
> > > >> - Split patches because the v3 patch exceeds size limit
> > > >> - Stop using ID number to identify driver instance:
> > > >>   - Use dynamically allocated structure to hold HW specific context,
> > > >>     instead of static one.
> > > >>   - Call HW layer functions with the context structure instead of
> > > >> ID number
> > > >>
> > > >> Changelog v5:
> > > >> - no change
> > > >>
> > > >> Changelog v6:
> > > >> - remove unused macros
> > > >> - removed hwd_ and HWD_ prefix
> > > >> - update source code documentation
> > > >> - Suggestion from Hans Verkuil
> > > >>   - pointer to userland memory is removed from uAPI arguments
> > > >>     - style of structure is now "nested" instead of "chained by pointer";
> > > >>   - use div64_u64 for 64bit division
> > > >>   - vendor specific controls support TRY_EXT_CTRLS
> > > >>   - add READ_ONLY flag to GET_CALIBRATION_STATUS control and
> > similar ones
> > > >>   - human friendry control names for vendor specific controls
> > > >>   - add initial value to each vendor specific control
> > > >>   - GET_LAST_CAPTURE_STATUS control is updated asyncnously
> from
> > workqueue
> > > >>   - remove EXECUTE_ON_WRITE flag of vendor specific control
> > > >>   - uAPI: return value of GET_CALIBRATION_STATUS follows common
> > rules of error codes
> > > >>   - applied v4l2-compliance
> > > >> - Suggestion from Sakari Ailus
> > > >>   - use div64_u64 for 64bit division
> > > >>   - update copyright's year
> > > >>   - remove redandunt cast
> > > >>   - use bool instead of HWD_VIIF_ENABLE/DISABLE
> > > >>   - simplify comparison to 0
> > > >>   - simplify statements with trigram operator
> > > >>   - remove redundant local variables
> > > >>   - use general integer types instead of u32/s32
> > > >> - Suggestion from Laurent Pinchart
> > > >>   - moved VIIF driver to driver/platform/toshiba/visconti
> > > >>   - change register access: struct-style to macro-style
> > > >>   - remove unused type definitions
> > > >>   - define enums instead of successive macro constants
> > > >>   - remove redundant parenthesis of macro constant
> > > >>   - embed struct hwd_res into struct viif_device
> > > >>   - use xxx_dma instead of xxx_paddr for variable names of IOVA
> > > >>   - literal value: just 0 instead of 0x0
> > > >>   - use literal 1 or 0 instead of HWD_VIIF_ENABLE, DISABLE for
> > > >> register
> > access
> > > >>   - use true or false instead of HWD_VIIF_ENABLE, DISABLE for
> > > >> function
> > calls
> > > >>   - uAPI: return value of GET_CALIBRATION_STATUS follows common
> > > >> rules of error codes
> > > >>
> > > >> Changelog v7:
> > > >> - remove unused variables
> > > >> - split long statements which have multiple logical-OR and
> > > >> trigram operators
> > > >>
> > > >> Changelog v8:
> > > >> - define constant V4L2_CTRL_TYPE_VISCONTI_ISP for datatype
> > > >>   of Visconti specific controls
> > > >> - Suggestion from Hans Verkuil
> > > >>   - remove pr_info()
> > > >>   - use pm_runtime_get_if_in_use() to get power status
> > > >>
> > > >> Changelog v9:
> > > >> - fix warning for cast between ptr and dma_addr_t
> > > >>
> > > >>  .../media/platform/toshiba/visconti/Makefile  |    2 +-
> > > >>  .../media/platform/toshiba/visconti/viif.c    |   10 +-
> > > >>  .../platform/toshiba/visconti/viif_controls.c | 3395
> > +++++++++++++++++
> > > >>  .../platform/toshiba/visconti/viif_controls.h |   18 +
> > > >>  .../platform/toshiba/visconti/viif_isp.c      |   15 +-
> > > >>  drivers/media/v4l2-core/v4l2-ctrls-core.c     |    7 +-
> > > >>  include/uapi/linux/videodev2.h                |    2 +
> > > >>  7 files changed, 3431 insertions(+), 18 deletions(-)  create
> > > >> mode
> > > >> 100644 drivers/media/platform/toshiba/visconti/viif_controls.c
> > > >>  create mode 100644
> > > >> drivers/media/platform/toshiba/visconti/viif_controls.h
> > > >>
> > > >
> > > > <snip>
> > > >
> > > > These core changes below should be in a separate patch, not mixed
> > > > in with the driver.
> > > >
> > > >> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c
> > > >> b/drivers/media/v4l2-core/v4l2-ctrls-core.c
> > > >> index a662fb60f73f..0c4df9fffbe0 100644
> > > >> --- a/drivers/media/v4l2-core/v4l2-ctrls-core.c
> > > >> +++ b/drivers/media/v4l2-core/v4l2-ctrls-core.c
> > > >> @@ -367,7 +367,9 @@ void v4l2_ctrl_type_op_log(const struct
> > > >> v4l2_ctrl
> > *ctrl)
> > > >>  	case V4L2_CTRL_TYPE_AV1_FILM_GRAIN:
> > > >>  		pr_cont("AV1_FILM_GRAIN");
> > > >>  		break;
> > > >> -
> > > >> +	case V4L2_CTRL_TYPE_VISCONTI_ISP:
> > > >> +		pr_cont("VISCONTI_ISP");
> > > >> +		break;
> > > >>  	default:
> > > >>  		pr_cont("unknown type %d", ctrl->type);
> > > >>  		break;
> > > >> @@ -1163,6 +1165,9 @@ static int std_validate_compound(const
> > > >> struct
> > v4l2_ctrl *ctrl, u32 idx,
> > > >>  	case V4L2_CTRL_TYPE_AV1_FILM_GRAIN:
> > > >>  		return validate_av1_film_grain(p);
> > > >>
> > > >> +	case V4L2_CTRL_TYPE_VISCONTI_ISP:
> > > >> +		break;
> > > >> +
> > > >>  	case V4L2_CTRL_TYPE_AREA:
> > > >>  		area = p;
> > > >>  		if (!area->width || !area->height) diff --git
> > > >> a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > > >> index c3d4e490ce7c..bbc3cd3efa65 100644
> > > >> --- a/include/uapi/linux/videodev2.h
> > > >> +++ b/include/uapi/linux/videodev2.h
> > > >> @@ -1915,6 +1915,8 @@ enum v4l2_ctrl_type {
> > > >>  	V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY = 0x281,
> > > >>  	V4L2_CTRL_TYPE_AV1_FRAME	    = 0x282,
> > > >>  	V4L2_CTRL_TYPE_AV1_FILM_GRAIN	    = 0x283,
> > > >> +
> > > >> +	V4L2_CTRL_TYPE_VISCONTI_ISP = 0x290,
> > > >
> > > > I see you are using the same V4L2_CTRL_TYPE_VISCONTI_ISP for all
> > > > the compound controls. But that's not allowed: the V4L2_CTRL_TYPE_
> > > > defines determine the control type, so each struct used by a
> > > > control needs
> > its own type.
> > >
> > > Actually, you don't want to add such a type at all. This is all
> > > driver specific, so support like this belongs in the driver.
> > >
> > > A good example of that is
> > V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP in
> > > drivers/media/platform/nxp/dw100/dw100.c: there all the handling is
> > > done in the driver, and it adds init/validate/log/equal ops as well.
> >
> > Actually, I think a better option is to use parameters buffers instead
> > of controls, like other ISP driver do.
> >
> 
> I'll quickly make an experimental impl of parameters buffers of the VIIF driver
> and check if it works well.
> I'm still not for sure passing parameter via parameters buffers satisfies the
> timing constraint of the HW.

I made an experimental implementation of parameters buffers based on the RKISP1 driver.
The experimental driver seems working well, but there's a concern.

Due to HW spec, there is a minium 2-frame delay before the enqueued parameters are
reflected in the resulting image, while most ISPs should reflect it with a minium 1-frame delay.

Our in-house AE/AG middleware will be affected by increased latency.
Does libcamera have specific requirements for control latency?, 
or it can handle the problem by properly using parameter interface and statistics interface?

=====

The Visconti5's ISP captures register values automatically at VSync, 
not manually triggered by register operations (as most ISPs do).
The extra 1 frame occurs as shown below.

[Visconti5 ISP requires 2 frames to reflect]
0: user application issues ioctl(QBUF) of new parameters
1: VSYNC ISR pops parameters and sets them to ISP registers
2: ISP captures register values at VSYNC. ISP reflects.

[Most ISPs require 1 frame to reflect]
0: user application issues ioctl(QBUF) of new parameters
1: VSYNC ISR pops parameters, sets them to ISP registers and notify the change. ISP reflects.

> > > > I also noticed looking through include/uapi/linux/visconti_viif.h
> > > > that some of the struct have holes. I really want to avoid holes
> > > > in structs used by controls, it is bad practice.
> > > >
> > > > The pahole utility is very useful for testing this. It is also
> > > > highly recommended to check for both 32 and 64 bit compilation:
> > > > the struct layout must be the same, otherwise you would run into
> > > > problems if a 32 bit application is used with a 64 bit kernel.
> > > >
> > > > Finally, Laurent and/or Sakari will also take a look at this
> > > > driver, for some reason this driver has been mostly reviewed by
> > > > me, but I am not really the expert on ISPs.
> > > >
> > > >>  };
> > > >>
> > > >>  /*  Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
> 
> 
> Regards,
> Yuji

Regards,
Yuji

From quic_obabatun at quicinc.com  Sun Dec 10 16:42:04 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 10 Dec 2023 16:42:04 -0800
Subject: [RFC PATCH v2 0/6] Dynamic allocation of reserved_mem array.
In-Reply-To: <20231206213543.GB3345785-robh@kernel.org>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
 <20231206213543.GB3345785-robh@kernel.org>
Message-ID: <958182a4-0b42-4e3c-8f14-317cb6a8ac48@quicinc.com>


On 12/6/2023 1:35 PM, Rob Herring wrote:
> On Mon, Dec 04, 2023 at 10:54:03AM -0800, Oreoluwa Babatunde wrote:
>> The reserved_mem array is used to store the data of the different
>> reserved memory regions specified in the DT of a device.
>> The array stores information such as the name, node, starting address,
>> and size of a reserved memory region.
>>
>> The array is currently statically allocated with a size of
>> MAX_RESERVED_REGIONS(64). This means that any system that specifies a
>> number of reserved memory regions greater than MAX_RESERVED_REGIONS(64)
>> will not have enough space to store the information for all the regions.
>>
>> Therefore, this series extends the use of a static array for
>> reserved_mem, and introduces a dynamically allocated array using
>> memblock_alloc() based on the number of reserved memory regions
>> specified in the DT.
>>
>> Memory gotten from memblock_alloc() is only writable after paging_init()
>> is called, but the reserved memory regions need to be reserved before
>> then so that the system does not create page table mappings for them.
>>
>> Reserved memory regions can be divided into 2 groups.
>> i) Statically-placed reserved memory regions
>> i.e. regions defined in the DT using the @reg property.
>> ii) Dynamically-placed reserved memory regions.
>> i.e. regions specified in the DT using the @alloc_ranges
>>     and @size properties.
>>
>> It is possible to call memblock_reserve() and memblock_mark_nomap() on
>> the statically-placed reserved memory regions and not need to save them
>> to the array until after paging_init(), but this is not possible for the
>> dynamically-placed reserved memory because the starting address of these
>> regions need to be stored somewhere after they are allocated.
>>
>> Therefore, this series achieves the allocation and population of the
>> reserved_mem array in two steps:
>>
>> 1. Before paging_init()
>>    Before paging_init() is called, iterate through the reserved_mem
>>    nodes in the DT and do the following:
>>    - Allocate memory for dynamically-placed reserved memory regions and
>>      store their starting address in the static allocated reserved_mem
>>      array.
>>    - Call memblock_reserve() and memblock_mark_nomap() on all the
>>      reserved memory regions as needed.
>>    - Count the total number of reserved_mem nodes in the DT.
>>
>> 2. After paging_init()
>>    After paging_init() is called:
>>    - Allocate new memory for the reserved_mem array based on the number
>>      of reserved memory nodes in the DT.
>>    - Transfer all the information that was stored in the static array
>>      into the new array.
>>    - Store the rest of the reserved_mem regions in the new array.
>>      i.e. the statically-placed regions.
>>
>> The static array is no longer needed after this point, but there is
>> currently no obvious way to free the memory. Therefore, the size of the
>> initial static array is now defined using a config option.
> A config option is not going to work here.
>
>> Because the array is used only before paging_init() to store the
>> dynamically-placed reserved memory regions, the required size can vary
>> from device to device. Therefore, scaling it can help get some memory
>> savings.
>>
>> A possible solution to freeing the memory for the static array will be
>> to mark it as __initdata. This will automatically free the memory once
>> the init process is done running.
>> The reason why this is not pursued in this series is because of
>> the possibility of a use-after-free.
>> If the dynamic allocation of the reserved_mem array fails, then future
>> accesses of the reserved_mem array will still be referencing the static
>> array. When the init process ends and the memory is freed up, any
>> further attempts to use the reserved_mem array will result in a
>> use-after-free.
> If memory allocation for the reserved_mem array fails so early in boot, 
> you've got much bigger problems. Use __initdata, and just WARN if 
> allocation fails and continue on (so hopefully the console is brought 
> up and someone can see the WARN).
>
> Rob

Thanks for pointing that out! I'll move forward with implementing the use
of __initdata to delete the static array.

Regards,
Oreoluwa



From quic_obabatun at quicinc.com  Sun Dec 10 16:51:56 2023
From: quic_obabatun at quicinc.com (Oreoluwa Babatunde)
Date: Sun, 10 Dec 2023 16:51:56 -0800
Subject: [RFC PATCH v2 2/6] of: reserved_mem: Swicth call to
 unflatten_device_tree() to after paging_init()
In-Reply-To: <20231206213110.GA3345785-robh@kernel.org>
References: <20231204185409.19615-1-quic_obabatun@quicinc.com>
 <20231204185409.19615-3-quic_obabatun@quicinc.com>
 <20231206213110.GA3345785-robh@kernel.org>
Message-ID: <2db0f02f-b15d-4767-8b7e-9051a46707d0@quicinc.com>


On 12/6/2023 1:31 PM, Rob Herring wrote:
> On Mon, Dec 04, 2023 at 10:54:05AM -0800, Oreoluwa Babatunde wrote:
>> Switch call to unflatten_device_tree() to after paging_init() on other
>> archs to follow new order in which the reserved_mem regions are
>> processed.
> You did this so that you could allocate memory for the reserved regions. 
> But unflatten_device_tree() can already do allocations using memblock. 
> So the same thing should work for you.
>
> I suspect that moving this will break any arch that called an of_* API 
> between the original call and the new call location.
>
> Rob
Hi Rob,

Thank you for your feedback. You are correct, I see that
unflatten_device_tree() is allocating memory from memblock and writing
to it before paging_init() is called on these other architectures.

This series will still require fdt_init_reserved_mem() to be called
after paging_init() on architectures such as arm64 which require
paging_init() to run before memblock allocated memory is writable.

In light of this, there seems to be no non-architecture-specific
universal calling point to stick in fdt_init_reserved_mem() that works
for all architectures.? Therefore, I propose taking out the call to
fdt_init_reserved_mem() from the unflatten_device_tree() function and
placing it in the setup_arch() function for each architecture.
(similar to the way it was in v1 of this series).

Doing this will allow us to place? fdt_init_reserved_mem() after
paging_init() on architectures that require paging_init() to be called
before memblock allocated memory is writable, and place it before
paging_init() on architectures that does not require paging_init() to be
called before writing to memblock allocated memory.

fdt_init_reserved_mem() can also be called after unflatten_device_tree()
on all architectures to ensure we get the speed benefits of using the
unflattened device tree APIs for the final pass.

Regards,
Oreoluwa


From daniel at makrotopia.org  Sun Dec 10 17:33:14 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Mon, 11 Dec 2023 01:33:14 +0000
Subject: [PATCH] ASoC: mediatek: mt7986: silence error in case of
 -EPROBE_DEFER
Message-ID: <98491ec78ab671f5a14fce42d10f9745ebddb112.1702258360.git.daniel@makrotopia.org>

If probe is defered no error should be printed. Mute it.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 sound/soc/mediatek/mt7986/mt7986-wm8960.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/soc/mediatek/mt7986/mt7986-wm8960.c b/sound/soc/mediatek/mt7986/mt7986-wm8960.c
index c1390b3734101..24a4b943030d7 100644
--- a/sound/soc/mediatek/mt7986/mt7986-wm8960.c
+++ b/sound/soc/mediatek/mt7986/mt7986-wm8960.c
@@ -144,7 +144,9 @@ static int mt7986_wm8960_machine_probe(struct platform_device *pdev)
 
 	ret = devm_snd_soc_register_card(&pdev->dev, card);
 	if (ret) {
-		dev_err(&pdev->dev, "%s snd_soc_register_card fail: %d\n", __func__, ret);
+		if (ret != -EPROBE_DEFER)
+			dev_err(&pdev->dev, "%s snd_soc_register_card fail: %d\n", __func__, ret);
+
 		goto err_of_node_put;
 	}
 
-- 
2.43.0



From jaewon02.kim at samsung.com  Sun Dec 10 18:18:40 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Mon, 11 Dec 2023 11:18:40 +0900
Subject: [PATCH] dt-bindings: pinctrl: samsung: correct ExynosAutov920
 wake-up compatibles
In-Reply-To: <20231210133915.42112-1-krzysztof.kozlowski@linaro.org>
References: <CGME20231210133927epcas2p3e2633ad371b03d5ab19f9b44118fcb58@epcas2p3.samsung.com>
	<20231210133915.42112-1-krzysztof.kozlowski@linaro.org>
Message-ID: <c63bd0b3-ecb2-d4c6-2147-43f19c1dcfee@samsung.com>


On 23. 12. 10. 22:39, Krzysztof Kozlowski wrote:
> ExynosAutov920 SoC wake-up pin controller has different register layout
> than Exynos7, thus it should not be marked as compatible.  Neither DTS
> nor Linux driver was merged yet, so the change does not impact ABI.
>
> Cc: Jaewon Kim <jaewon02.kim at samsung.com>
> Fixes: 904140fa4553 ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>
>

It is reasonable.

I will also fix this in v4 patch.


Reviewed-by:Jaewon Kim <jaewon02.kim at samsung.com>


Thanks,
Jaewon Kim



From jaewon02.kim at samsung.com  Sun Dec 10 18:26:33 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Mon, 11 Dec 2023 11:26:33 +0900
Subject: [PATCH] dt-bindings: samsung: exynos-sysreg: combine
 exynosautov920 with other enum
In-Reply-To: <20231210134834.43943-1-krzysztof.kozlowski@linaro.org>
References: <CGME20231210134852epcas2p4166a413502a742b6f558d7b55bd36ae6@epcas2p4.samsung.com>
	<20231210134834.43943-1-krzysztof.kozlowski@linaro.org>
Message-ID: <df677a28-284f-4f80-afa7-9bf71bc8ce2e@samsung.com>


On 23. 12. 10. 22:48, Krzysztof Kozlowski wrote:
> No need to create a new enum every time we bring-up new SoC.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---

Reviewed-by: Jaewon Kim <jaewon02.kim at samsung.com>


>   .../bindings/soc/samsung/samsung,exynos-sysreg.yaml        | 7 ++-----
>   1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> index 2de4301a467d..b00f25482fec 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> @@ -17,6 +17,8 @@ properties:
>                 - samsung,exynos3-sysreg
>                 - samsung,exynos4-sysreg
>                 - samsung,exynos5-sysreg
> +              - samsung,exynosautov920-peric0-sysreg
> +              - samsung,exynosautov920-peric1-sysreg
>                 - tesla,fsd-cam-sysreg
>                 - tesla,fsd-fsys0-sysreg
>                 - tesla,fsd-fsys1-sysreg
> @@ -50,11 +52,6 @@ properties:
>                 - samsung,exynosautov9-peric1-sysreg
>             - const: samsung,exynosautov9-sysreg
>             - const: syscon
> -      - items:
> -          - enum:
> -              - samsung,exynosautov920-peric0-sysreg
> -              - samsung,exynosautov920-peric1-sysreg
> -          - const: syscon
>   
>     reg:
>       maxItems: 1


From jaewon02.kim at samsung.com  Sun Dec 10 18:38:58 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Mon, 11 Dec 2023 11:38:58 +0900
Subject: [PATCH v3 3/4] pinctrl: samsung: support ExynosAuto GPIO
 structure
In-Reply-To: <421ede4c-7a96-47e0-9b82-0eb350b59c33@linaro.org>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
	<CGME20231208075020epcas2p260c65fa8d33e0cd97806f065bb8a044d@epcas2p2.samsung.com>
	<20231208074527.50840-4-jaewon02.kim@samsung.com>
	<421ede4c-7a96-47e0-9b82-0eb350b59c33@linaro.org>
Message-ID: <7800ae2d-cc19-ce7c-7b3b-54016903d8ec@samsung.com>

Hello Krzysztof,

Thanks to review.


On 23. 12. 10. 22:00, Krzysztof Kozlowski wrote:
> On 08/12/2023 08:45, Jaewon Kim wrote:
>> New ExynosAuto series GPIO have a different register structure.
>> In the existing Exynos series, EINT control register enumerated after
>> a specific offset (e.g EXYNOS_GPIO_ECON_OFFSET, EXYNOS_GPIO_EMASK_OFFSET).
>> However, from ExynosAutov920 SoC, the register that controls EINT belongs
>> to each GPIO bank, and each GPIO bank has 0x1000 align.
>>
>> This is a structure to protect the GPIO bank using S2MPU in VM environment,
>> and will only be applied in ExynosAuto series SoCs.
>>
>> -------------------------------------------------
>> | original		| ExynosAutov920	|
>> |-----------------------------------------------|
>> | 0x0	GPIO_CON	| 0x0	GPIO_CON	|
>> | 0x4	GPIO_DAT	| 0x4	GPIO_DAT	|
>> | 0x8	GPIO_PUD	| 0x8	GPIO_PUD	|
>> | 0xc	GPIO_DRV	| 0xc	GPIO_DRV	|
>> | 0x10	GPIO_CONPDN	| 0x10	GPIO_CONPDN	|
>> | 0x14	GPIO_PUDPDN	| 0x14	GPIO_PUDPDN	|
>> | 0x700	EINT_CON	| 0x18	EINT_CON	|
>> | 0x800	EINT_FLTCON	| 0x1c	EINT_FLTCON0	|
>> | 0x900	EINT_MASK	| 0x20	EINT_FLTCON1	|
>> | 0xa00	EINT_PEND	| 0x24	EINT_MASK	|
>> |			| 0x28	EINT_PEND	|
>> -------------------------------------------------
>>
>> Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
>> ---
>>   drivers/pinctrl/samsung/pinctrl-exynos.c  | 81 +++++++++++++++++++++--
>>   drivers/pinctrl/samsung/pinctrl-exynos.h  |  1 +
>>   drivers/pinctrl/samsung/pinctrl-samsung.c |  3 +
>>   drivers/pinctrl/samsung/pinctrl-samsung.h | 12 ++++
>>   4 files changed, 90 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> index 6b58ec84e34b..f798f64b1122 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> @@ -56,6 +56,9 @@ static void exynos_irq_mask(struct irq_data *irqd)
>>   	unsigned int mask;
>>   	unsigned long flags;
>>   
>> +	if (bank->eint_mask_offset)
>> +		reg_mask = bank->pctl_offset + bank->eint_mask_offset;
> Drop the initialization of reg_mask so:
>
> else:
> reg_mask = ...

Okay, I will fix it in v4.


>
>> +
>>   	raw_spin_lock_irqsave(&bank->slock, flags);
>>   
>>   	mask = readl(bank->eint_base + reg_mask);
>> @@ -72,6 +75,9 @@ static void exynos_irq_ack(struct irq_data *irqd)
>>   	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
>>   	unsigned long reg_pend = our_chip->eint_pend + bank->eint_offset;
>>   
>> +	if (bank->eint_pend_offset)
>> +		reg_pend = bank->pctl_offset + bank->eint_pend_offset;
>> +
>>   	writel(1 << irqd->hwirq, bank->eint_base + reg_pend);
>>   }
>>   
>> @@ -95,6 +101,9 @@ static void exynos_irq_unmask(struct irq_data *irqd)
>>   	if (irqd_get_trigger_type(irqd) & IRQ_TYPE_LEVEL_MASK)
>>   		exynos_irq_ack(irqd);
>>   
> Ditto
I will fix it also.
>
>> +	if (bank->eint_mask_offset)
>> +		reg_mask = bank->pctl_offset + bank->eint_mask_offset;
>> +
>>   	raw_spin_lock_irqsave(&bank->slock, flags);
>>   
>>   	mask = readl(bank->eint_base + reg_mask);
>> @@ -139,6 +148,9 @@ static int exynos_irq_set_type(struct irq_data *irqd, unsigned int type)
>>   	else
>>   		irq_set_handler_locked(irqd, handle_level_irq);
>>   
>
> Ditto
I will fix it also.
>
>> +	if (bank->eint_con_offset)
>> +		reg_con = bank->pctl_offset + bank->eint_con_offset;
>> +
>>   	con = readl(bank->eint_base + reg_con);
>>   	con &= ~(EXYNOS_EINT_CON_MASK << shift);
>>   	con |= trig_type << shift;
>> @@ -221,6 +233,18 @@ static const struct exynos_irq_chip exynos_gpio_irq_chip __initconst = {
>>   	/* eint_wake_mask_value not used */
>>   };
>>   
>> +static const struct exynos_irq_chip exynosauto_gpio_irq_chip __initconst = {
> No related to this patch.
>
>> +	.chip = {
>> +		.name = "exynosauto_gpio_irq_chip",
>> +		.irq_unmask = exynos_irq_unmask,
>> +		.irq_mask = exynos_irq_mask,
>> +		.irq_ack = exynos_irq_ack,
>> +		.irq_set_type = exynos_irq_set_type,
>> +		.irq_request_resources = exynos_irq_request_resources,
>> +		.irq_release_resources = exynos_irq_release_resources,
>> +	},
>> +};
>> +
>>   static int exynos_eint_irq_map(struct irq_domain *h, unsigned int virq,
>>   					irq_hw_number_t hw)
>>   {
>> @@ -247,7 +271,10 @@ static irqreturn_t exynos_eint_gpio_irq(int irq, void *data)
>>   	unsigned int svc, group, pin;
>>   	int ret;
>>   
>> -	svc = readl(bank->eint_base + EXYNOS_SVC_OFFSET);
>> +	if (bank->eint_con_offset)
>> +		svc = readl(bank->eint_base + EXYNOSAUTO_SVC_OFFSET);
> This belongs to the second patch. The point of this patch is only to
> customize the offsets. There should be nothing autov920 here.

Okay, I will put the irq-related changes in the v920 patch.


>
>
>> +	else
>> +		svc = readl(bank->eint_base + EXYNOS_SVC_OFFSET);
>>   	group = EXYNOS_SVC_GROUP(svc);
>>   	pin = svc & EXYNOS_SVC_NUM_MASK;
>>   
>> @@ -297,8 +324,12 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
>>   		if (bank->eint_type != EINT_TYPE_GPIO)
>>   			continue;
>>   
>> -		bank->irq_chip = devm_kmemdup(dev, &exynos_gpio_irq_chip,
>> -					   sizeof(*bank->irq_chip), GFP_KERNEL);
>> +		if (bank->eint_con_offset)
>> +			bank->irq_chip = devm_kmemdup(dev, &exynosauto_gpio_irq_chip,
>> +						      sizeof(*bank->irq_chip), GFP_KERNEL);
>> +		else
>> +			bank->irq_chip = devm_kmemdup(dev, &exynos_gpio_irq_chip,
>> +						      sizeof(*bank->irq_chip), GFP_KERNEL);
>>   		if (!bank->irq_chip) {
>>   			ret = -ENOMEM;
>>   			goto err_domains;
>> @@ -655,6 +686,19 @@ static void exynos_pinctrl_suspend_bank(
>>   	pr_debug("%s: save    mask %#010x\n", bank->name, save->eint_mask);
>>   }
>>   
>> +static void exynosauto_pinctrl_suspend_bank(struct samsung_pinctrl_drv_data *drvdata,
>> +					    struct samsung_pin_bank *bank)
>> +{
>> +	struct exynos_eint_gpio_save *save = bank->soc_priv;
>> +	void __iomem *regs = bank->eint_base;
>> +
>> +	save->eint_con = readl(regs + bank->pctl_offset + bank->eint_con_offset);
>> +	save->eint_mask = readl(regs + bank->pctl_offset + bank->eint_mask_offset);
>> +
>> +	pr_debug("%s: save     con %#010x\n", bank->name, save->eint_con);
>> +	pr_debug("%s: save    mask %#010x\n", bank->name, save->eint_mask);
>> +}
>> +
>>   void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
>>   {
>>   	struct samsung_pin_bank *bank = drvdata->pin_banks;
>> @@ -662,8 +706,12 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
>>   	int i;
>>   
>>   	for (i = 0; i < drvdata->nr_banks; ++i, ++bank) {
>> -		if (bank->eint_type == EINT_TYPE_GPIO)
>> -			exynos_pinctrl_suspend_bank(drvdata, bank);
>> +		if (bank->eint_type == EINT_TYPE_GPIO) {
>> +			if (bank->eint_con_offset)
>> +				exynosauto_pinctrl_suspend_bank(drvdata, bank);
>> +			else
>> +				exynos_pinctrl_suspend_bank(drvdata, bank);
>> +		}
>>   		else if (bank->eint_type == EINT_TYPE_WKUP) {
>>   			if (!irq_chip) {
>>   				irq_chip = bank->irq_chip;
>> @@ -704,14 +752,33 @@ static void exynos_pinctrl_resume_bank(
>>   						+ bank->eint_offset);
>>   }
>>   
>> +static void exynosauto_pinctrl_resume_bank(struct samsung_pinctrl_drv_data *drvdata,
>> +					   struct samsung_pin_bank *bank)
>> +{
>> +	struct exynos_eint_gpio_save *save = bank->soc_priv;
>> +	void __iomem *regs = bank->eint_base;
>> +
>> +	pr_debug("%s:     con %#010x => %#010x\n", bank->name,
>> +		 readl(regs + bank->pctl_offset + bank->eint_con_offset), save->eint_con);
>> +	pr_debug("%s:    mask %#010x => %#010x\n", bank->name,
>> +		 readl(regs + bank->pctl_offset + bank->eint_mask_offset), save->eint_mask);
>> +
>> +	writel(save->eint_con, regs + bank->pctl_offset + bank->eint_con_offset);
>> +	writel(save->eint_mask, regs + bank->pctl_offset + bank->eint_mask_offset);
>> +}
>> +
>>   void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
>>   {
>>   	struct samsung_pin_bank *bank = drvdata->pin_banks;
>>   	int i;
>>   
>>   	for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
>> -		if (bank->eint_type == EINT_TYPE_GPIO)
>> -			exynos_pinctrl_resume_bank(drvdata, bank);
>> +		if (bank->eint_type == EINT_TYPE_GPIO) {
>> +			if (bank->eint_con_offset)
>> +				exynosauto_pinctrl_resume_bank(drvdata, bank);
>> +			else
>> +				exynos_pinctrl_resume_bank(drvdata, bank);
>> +		}
>>   }
>>   
>>   static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
>> index 3ac52c2cf998..5049c170e958 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
>> @@ -31,6 +31,7 @@
>>   #define EXYNOS7_WKUP_EMASK_OFFSET	0x900
>>   #define EXYNOS7_WKUP_EPEND_OFFSET	0xA00
>>   #define EXYNOS_SVC_OFFSET		0xB08
>> +#define EXYNOSAUTO_SVC_OFFSET		0xF008
> As well not related to this patch.
>
> Best regards,
> Krzysztof
>
>

Thanks

Jaewon Kim



From jaewon02.kim at samsung.com  Sun Dec 10 18:44:21 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Mon, 11 Dec 2023 11:44:21 +0900
Subject: [PATCH v3 3/4] pinctrl: samsung: support ExynosAuto GPIO
 structure
In-Reply-To: <9d496fb5-25b4-4f1a-9652-4c54cf2d59a1@linaro.org>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
	<CGME20231208075020epcas2p260c65fa8d33e0cd97806f065bb8a044d@epcas2p2.samsung.com>
	<20231208074527.50840-4-jaewon02.kim@samsung.com>
	<9d496fb5-25b4-4f1a-9652-4c54cf2d59a1@linaro.org>
Message-ID: <04a874f4-df4b-2a9d-ea02-bbb63095d199@samsung.com>


On 23. 12. 10. 22:23, Krzysztof Kozlowski wrote:
> On 08/12/2023 08:45, Jaewon Kim wrote:
>> New ExynosAuto series GPIO have a different register structure.
>> In the existing Exynos series, EINT control register enumerated after
> Missing verb... or enumerated is past tense? I just don't get entire
> sentence.

Sorry, I will add 'is' like below.

In the existing Exynos series, the EINT control register is enumerated 
after a specific offset.


>
>> a specific offset (e.g EXYNOS_GPIO_ECON_OFFSET, EXYNOS_GPIO_EMASK_OFFSET).
>> However, from ExynosAutov920 SoC, the register that controls EINT belongs
>> to each GPIO bank, and each GPIO bank has 0x1000 align.
>>
>> This is a structure to protect the GPIO bank using S2MPU in VM environment,
>> and will only be applied in ExynosAuto series SoCs.
>>
>> -------------------------------------------------
>> | original		| ExynosAutov920	|
>> |-----------------------------------------------|
>> | 0x0	GPIO_CON	| 0x0	GPIO_CON	|
>> | 0x4	GPIO_DAT	| 0x4	GPIO_DAT	|
>> | 0x8	GPIO_PUD	| 0x8	GPIO_PUD	|
>> | 0xc	GPIO_DRV	| 0xc	GPIO_DRV	|
>> | 0x10	GPIO_CONPDN	| 0x10	GPIO_CONPDN	|
>> | 0x14	GPIO_PUDPDN	| 0x14	GPIO_PUDPDN	|
>> | 0x700	EINT_CON	| 0x18	EINT_CON	|
> This suggests there is EINT_CON per bank in old and new register layout.
> I don't think it's true, so probably this could look like:
>
> | ---                           | 0x18	EINT_CON (per_bank) |
> | ---                           | 0x18	EINT_FLTCON0 (per_bank) |
> | ---                           | 0x18	EINT_FLTCON1 (per_bank) |
> | ---                           | 0x18	EINT_MASK (per_bank) |
> | 0x700	EINT_CON (global)       | 0x18	EINT_CON	|
>
> etc..
>
> Also, please use spaces for alignment in the table.
>
Thanks you for your review.

I will add (global), (per_bank) for clearer expression.

And, I will use space instead of tab in v4.

>
> Best regards,
> Krzysztof
>
>


From jaewon02.kim at samsung.com  Sun Dec 10 18:45:25 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Mon, 11 Dec 2023 11:45:25 +0900
Subject: [PATCH v3 4/4] pinctrl: samsung: add exynosautov920 pinctrl
In-Reply-To: <a695f62f-5d08-49d6-a0b9-9f023ad7f586@linaro.org>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
	<CGME20231208075020epcas2p414c85e03d18327665eeff54082314b56@epcas2p4.samsung.com>
	<20231208074527.50840-5-jaewon02.kim@samsung.com>
	<a695f62f-5d08-49d6-a0b9-9f023ad7f586@linaro.org>
Message-ID: <5e5df314-e64c-4181-b9b8-0674b36898d1@samsung.com>

Hello Krzysztof,

Thanks for your review.


On 23. 12. 10. 22:23, Krzysztof Kozlowski wrote:
> On 08/12/2023 08:45, Jaewon Kim wrote:
>> Add pinctrl data for ExynosAutov920 SoC.
>>
>> Pinctrl data for ExynosAutoV920 SoC.
>>   - GPA0,GPA1 (10): External wake up interrupt
>>   - GPQ0 (2): SPMI (PMIC I/F)
>>   - GPB0,GPB1,GPB2,GPB3,GPB4,GPB5,GPB6 (47): I2S Audio
>>   - GPH0,GPH1,GPH2,GPH3,GPH4,GPH5,GPH6,GPH8 (49): PCIE, UFS, Ethernet
>>   - GPG0,GPG1,GPG2,GPG3,GPG4,GPG5 (29): General purpose
>>   - GPP0,GPP1,GPP2,GPP3,GPP4,GPP5,GPP6,GPP7,GPP8,GPP9,GPP10 (77): USI
>>
>> Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
>> ---
> ...
>
>
>>   /**
>>    * struct exynos_weint_data: irq specific data for all the wakeup interrupts
>>    * generated by the external wakeup interrupt controller.
>> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
>> index 362e99566919..800a2f0a026a 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
>> @@ -1324,6 +1324,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
>>   		.data = &exynosautov9_of_data },
>>   	{ .compatible = "tesla,fsd-pinctrl",
>>   		.data = &fsd_of_data },
>> +	{ .compatible = "samsung,exynosautov920-pinctrl",
>> +		.data = &exynosautov920_of_data },
> Please put it after autov9.

Okay, I will change the order.

>
> Best regards,
> Krzysztof
>
>
>

Thanks

Jaewon Kim



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:31 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:31 +0800
Subject: [PATCH v2 00/14] Add i2c-mux and eeprom devices for Meta Yosemite 4
Message-ID: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>

Changelog:
  - v2
    - Revise mx31790 fan tach config
    - Add mctp config for NIC
    - Support mux to cpld
    - Revise gpio name
  - v1
    - Add gpio and eeprom behind i2c-mux
    - Remove redundant idle-state setting for i2c-mux
    - Enable adc 15, wdt2,spi gpio for yosemite4 use
    - Revise quad mode to dual mode to avoid WP pin influnece the SPI
    - Revise power sensor adm1281 for yosemite4 schematic change
    - Add gpio pca9506 I/O expander for yosemite4 use
    - remove space for adm1272 compatible
    - enable interrupt setting for pca9555
    - add eeprom for yosemite4 medusa board/BSM use
    - remove temperature sensor for yosemite4 schematic change
    - add power sensor for power module reading
    - Revise adc128d818 adc mode for yosemite4 schematic change
    - Revise ina233 for yosemite4 schematic change
    - Remove idle state setting for yosemite4 NIC connection
    - Initialize bmc gpio state

Delphine CC Chiu (14):
  ARM: dts: aspeed: yosemite4: Revise i2c-mux devices
  ARM: dts: aspeed: yosemite4: Enable adc15
  ARM: dts: aspeed: yosemite4: Enable spi-gpio setting
  ARM: dts: aspeed: yosemite4: Enable watchdog2
  ARM: dts: aspeed: yosemite4: Revise quad mode to dual mode
  ARM: dts: aspeed: yosemite4: Revise power sensor adm1281 for schematic
    change
  ARM: dts: aspeed: yosemite4: Add gpio pca9506
  ARM: dts: aspeed: yosemite4: Revise i2c11 and i2c12 schematic change
  ARM: dts: aspeed: yosemite4: Revise i2c14 and i2c15 schematic change
  ARM: dts: aspeed: yosemite4: Initialize bmc gpio state
  ARM: dts: aspeed: yosemite4: Revise mx31790 fan tach config
  ARM: dts: aspeed: yosemite4: add mctp config for NIC
  ARM: dts: aspeed: yosemite4: support mux to cpld
  ARM: dts: aspeed: yosemite4: Revise gpio name

 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 1215 +++++++++++++++--
 1 file changed, 1091 insertions(+), 124 deletions(-)

-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:33 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:33 +0800
Subject: [PATCH v2 02/14] ARM: dts: aspeed: yosemite4: Enable adc15
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-3-Delphine_CC_Chiu@wiwynn.com>

Enable Yosemite 4 adc15 config

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index a5b4585e81e6..c32736fbaf70 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -51,7 +51,7 @@ iio-hwmon {
 		compatible = "iio-hwmon";
 		io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
 				<&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
-				<&adc1 0>, <&adc1 1>;
+				<&adc1 0>, <&adc1 1>, <&adc1 7>;
 	};
 };
 
@@ -920,10 +920,10 @@ &pinctrl_adc4_default &pinctrl_adc5_default
 &adc1 {
 	ref_voltage = <2500>;
 	status = "okay";
-	pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc9_default>;
+	pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc9_default
+	    &pinctrl_adc15_default>;
 };
 
-
 &ehci0 {
 	status = "okay";
 };
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:32 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:32 +0800
Subject: [PATCH v2 01/14] ARM: dts: aspeed: yosemite4: Revise i2c-mux devices
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-2-Delphine_CC_Chiu@wiwynn.com>

Revise Yosemite 4 devicetree for devices behind i2c-mux
- Add gpio and eeprom behind i2c-mux
- Remove redundant idle-state setting for i2c-mux

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 381 ++++++++++++++++--
 1 file changed, 347 insertions(+), 34 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 64075cc41d92..a5b4585e81e6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -17,6 +17,25 @@ aliases {
 		serial6 = &uart7;
 		serial7 = &uart8;
 		serial8 = &uart9;
+
+		i2c16 = &imux16;
+		i2c17 = &imux17;
+		i2c18 = &imux18;
+		i2c19 = &imux19;
+		i2c20 = &imux20;
+		i2c21 = &imux21;
+		i2c22 = &imux22;
+		i2c23 = &imux23;
+		i2c24 = &imux24;
+		i2c25 = &imux25;
+		i2c26 = &imux26;
+		i2c27 = &imux27;
+		i2c28 = &imux28;
+		i2c29 = &imux29;
+		i2c30 = &imux30;
+		i2c31 = &imux31;
+		i2c32 = &imux32;
+		i2c33 = &imux33;
 	};
 
 	chosen {
@@ -259,9 +278,109 @@ &i2c8 {
 	bus-frequency = <400000>;
 	i2c-mux at 70 {
 		compatible = "nxp,pca9544";
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
 		reg = <0x70>;
+
+		imux16: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux17: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux18: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux19: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
 	};
 };
 
@@ -270,15 +389,174 @@ &i2c9 {
 	bus-frequency = <400000>;
 	i2c-mux at 71 {
 		compatible = "nxp,pca9544";
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
 		reg = <0x71>;
+
+		imux20: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux21: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux22: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux23: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
 	};
 };
 
 &i2c10 {
 	status = "okay";
 	bus-frequency = <400000>;
+	i2c-mux at 74 {
+		compatible = "nxp,pca9544";
+		i2c-mux-idle-disconnect;
+		reg = <0x74>;
+
+		imux28: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			gpio at 20 {
+				compatible = "nxp,pca9506";
+				reg = <0x20>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio at 21 {
+				compatible = "nxp,pca9506";
+				reg = <0x21>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio at 22 {
+				compatible = "nxp,pca9506";
+				reg = <0x22>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio at 23 {
+				compatible = "nxp,pca9506";
+				reg = <0x23>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio at 24 {
+				compatible = "nxp,pca9506";
+				reg = <0x24>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				gpio-line-names =
+				"","","","",
+				"NIC0_MAIN_PWR_EN","NIC1_MAIN_PWR_EN",
+				"NIC2_MAIN_PWR_EN","NIC3_MAIN_PWR_EN",
+				"","","","","","","","",
+				"","","","","","","","",
+				"","","","","","","","";
+			};
+		};
+
+		imux29: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
 };
 
 &i2c11 {
@@ -433,16 +711,14 @@ eeprom at 51 {
 		reg = <0x51>;
 	};
 
-	i2c-mux at 71 {
-		compatible = "nxp,pca9846";
+	i2c-mux at 74 {
+		compatible = "nxp,pca9546";
 		#address-cells = <1>;
 		#size-cells = <0>;
-
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
-		reg = <0x71>;
+		reg = <0x74>;
 
-		i2c at 0 {
+		imux30: i2c at 0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
@@ -450,26 +726,26 @@ i2c at 0 {
 			adc at 1f {
 				compatible = "ti,adc128d818";
 				reg = <0x1f>;
-				ti,mode = /bits/ 8 <2>;
+				ti,mode = /bits/ 8 <1>;
 			};
 
 			pwm at 20{
-				compatible = "max31790";
+				compatible = "maxim,max31790";
+				pwm-as-tach = <4 5>;
 				reg = <0x20>;
-				#address-cells = <1>;
-				#size-cells = <0>;
 			};
 
 			gpio at 22{
 				compatible = "ti,tca6424";
 				reg = <0x22>;
+				gpio-controller;
+				#gpio-cells = <2>;
 			};
 
-			pwm at 23{
-				compatible = "max31790";
-				reg = <0x23>;
-				#address-cells = <1>;
-				#size-cells = <0>;
+			pwm at 2f{
+				compatible = "maxim,max31790";
+				pwm-as-tach = <4 5>;
+				reg = <0x2f>;
 			};
 
 			adc at 33 {
@@ -492,34 +768,34 @@ gpio at 61 {
 			};
 		};
 
-		i2c at 1 {
+		imux31: i2c at 1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
-			reg = <0>;
+			reg = <1>;
 
 			adc at 1f {
 				compatible = "ti,adc128d818";
 				reg = <0x1f>;
-				ti,mode = /bits/ 8 <2>;
+				ti,mode = /bits/ 8 <1>;
 			};
 
 			pwm at 20{
-				compatible = "max31790";
+				compatible = "maxim,max31790";
+				pwm-as-tach = <4 5>;
 				reg = <0x20>;
-				#address-cells = <1>;
-				#size-cells = <0>;
 			};
 
 			gpio at 22{
 				compatible = "ti,tca6424";
 				reg = <0x22>;
+				gpio-controller;
+				#gpio-cells = <2>;
 			};
 
-			pwm at 23{
-				compatible = "max31790";
-				reg = <0x23>;
-				#address-cells = <1>;
-				#size-cells = <0>;
+			pwm at 2f{
+				compatible = "maxim,max31790";
+				pwm-as-tach = <4 5>;
+				reg = <0x2f>;
 			};
 
 			adc at 33 {
@@ -547,12 +823,10 @@ i2c-mux at 73 {
 		compatible = "nxp,pca9544";
 		#address-cells = <1>;
 		#size-cells = <0>;
-
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
 		reg = <0x73>;
 
-		i2c at 0 {
+		imux32: i2c at 0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
@@ -563,10 +837,10 @@ adc at 35 {
 			};
 		};
 
-		i2c at 1 {
+		imux33: i2c at 1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
-			reg = <0>;
+			reg = <1>;
 
 			adc at 35 {
 				compatible = "maxim,max11617";
@@ -589,9 +863,48 @@ mctp at 10 {
 
 	i2c-mux at 72 {
 		compatible = "nxp,pca9544";
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
 		reg = <0x72>;
+
+		imux24: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			temperature-sensor at 1f {
+				compatible = "ti,tmp421";
+				reg = <0x1f>;
+			};
+		};
+
+		imux25: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			temperature-sensor at 1f {
+				compatible = "ti,tmp421";
+				reg = <0x1f>;
+			};
+		};
+
+		imux26: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+			temperature-sensor at 1f {
+				compatible = "ti,tmp421";
+				reg = <0x1f>;
+			};
+		};
+
+		imux27: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+			temperature-sensor at 1f {
+				compatible = "ti,tmp421";
+				reg = <0x1f>;
+			};
+		};
 	};
 };
 
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:34 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:34 +0800
Subject: [PATCH v2 03/14] ARM: dts: aspeed: yosemite4: Enable spi-gpio setting
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-4-Delphine_CC_Chiu@wiwynn.com>

enable spi-gpio setting for spi flash

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts   | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index c32736fbaf70..0449a7e36ff6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -53,6 +53,24 @@ iio-hwmon {
 				<&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
 				<&adc1 0>, <&adc1 1>, <&adc1 7>;
 	};
+
+	spi_gpio: spi-gpio {
+		compatible = "spi-gpio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio-sck = <&gpio0 ASPEED_GPIO(X, 3) GPIO_ACTIVE_HIGH>;
+		gpio-mosi = <&gpio0 ASPEED_GPIO(X, 4) GPIO_ACTIVE_HIGH>;
+		gpio-miso = <&gpio0 ASPEED_GPIO(X, 5) GPIO_ACTIVE_HIGH>;
+		num-chipselects = <1>;
+		cs-gpios = <&gpio0 ASPEED_GPIO(X, 0) GPIO_ACTIVE_LOW>;
+
+		tpmdev at 0 {
+			compatible = "tcg,tpm_tis-spi";
+			spi-max-frequency = <33000000>;
+			reg = <0>;
+		};
+	};
 };
 
 &uart1 {
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:35 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:35 +0800
Subject: [PATCH v2 04/14] ARM: dts: aspeed: yosemite4: Enable watchdog2
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-5-Delphine_CC_Chiu@wiwynn.com>

enable watchdog2 setting

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 0449a7e36ff6..0e9095c83a59 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -120,6 +120,13 @@ &wdt1 {
 	aspeed,ext-pulse-duration = <256>;
 };
 
+&wdt2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdtrst2_default>;
+	aspeed,reset-type = "system";
+};
+
 &mac2 {
 	status = "okay";
 	pinctrl-names = "default";
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:37 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:37 +0800
Subject: [PATCH v2 06/14] ARM: dts: aspeed: yosemite4: Revise power sensor adm1281 for schematic change
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-7-Delphine_CC_Chiu@wiwynn.com>

Revise power sensor adm1281 for yosemite4 schematic change

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 24 ++++++++++++-------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 7fe80ad271aa..7f0134fcee57 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -176,8 +176,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -193,8 +194,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -210,8 +212,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -227,8 +230,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -244,8 +248,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -261,8 +266,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -278,8 +284,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -295,8 +302,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:36 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:36 +0800
Subject: [PATCH v2 05/14] ARM: dts: aspeed: yosemite4: Revise quad mode to dual mode
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-6-Delphine_CC_Chiu@wiwynn.com>

Revise quad mode to dual mode to avoid WP pin influnece the SPI

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 0e9095c83a59..7fe80ad271aa 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -149,15 +149,17 @@ flash at 0 {
 		status = "okay";
 		m25p,fast-read;
 		label = "bmc";
-		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
 		spi-max-frequency = <50000000>;
-#include "openbmc-flash-layout-64.dtsi"
+#include "openbmc-flash-layout-128.dtsi"
 	};
 	flash at 1 {
 		status = "okay";
 		m25p,fast-read;
 		label = "bmc2";
-		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
 		spi-max-frequency = <50000000>;
 	};
 };
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:38 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:38 +0800
Subject: [PATCH v2 07/14] ARM: dts: aspeed: yosemite4: Add gpio pca9506
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-8-Delphine_CC_Chiu@wiwynn.com>

Add gpio pca9506 I/O expander for yv4 use

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 251 ++++++++++++++++++
 1 file changed, 251 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 7f0134fcee57..da413325ce30 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -175,6 +175,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -193,6 +221,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -211,6 +267,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -229,6 +313,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -247,6 +359,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -265,6 +405,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -283,6 +451,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -301,6 +497,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -683,6 +907,33 @@ rtc at 6f {
 &i2c13 {
 	status = "okay";
 	bus-frequency = <400000>;
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
 
 &i2c14 {
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:39 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:39 +0800
Subject: [PATCH v2 08/14] ARM: dts: aspeed: yosemite4: Revise i2c11 and i2c12 schematic change
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-9-Delphine_CC_Chiu@wiwynn.com>

Revise i2c11 and i2c12 schematic change:
- remove space for adm1272 compatible
- enable interrupt setting for pca9555
- add eeprom for yosemite4 medusa board/BSM use
- remove temperature sensor for yosemite4 schematic change
- add power sensor for power module reading

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 118 ++++++++++++++----
 1 file changed, 93 insertions(+), 25 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index da413325ce30..ccb5ecd8d9a6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -821,41 +821,94 @@ imux29: i2c at 1 {
 &i2c11 {
 	status = "okay";
 	power-sensor at 10 {
-		compatible = "adi, adm1272";
+		compatible = "adi,adm1272";
 		reg = <0x10>;
 	};
 
 	power-sensor at 12 {
-		compatible = "adi, adm1272";
+		compatible = "adi,adm1272";
 		reg = <0x12>;
 	};
 
-	gpio at 20 {
+	gpio_ext1: pca9555 at 20 {
 		compatible = "nxp,pca9555";
-		reg = <0x20>;
+		pinctrl-names = "default";
 		gpio-controller;
 		#gpio-cells = <2>;
-	};
-
-	gpio at 21 {
+		reg = <0x20>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+		"P48V_OCP_GPIO1","P48V_OCP_GPIO2",
+		"P48V_OCP_GPIO3","FAN_BOARD_0_REVISION_0_R",
+		"FAN_BOARD_0_REVISION_1_R","FAN_BOARD_1_REVISION_0_R",
+		"FAN_BOARD_1_REVISION_1_R","RST_MUX_R_N",
+		"RST_LED_CONTROL_FAN_BOARD_0_N","RST_LED_CONTROL_FAN_BOARD_1_N",
+		"RST_IOEXP_FAN_BOARD_0_N","RST_IOEXP_FAN_BOARD_1_N",
+		"PWRGD_LOAD_SWITCH_FAN_BOARD_0_R","PWRGD_LOAD_SWITCH_FAN_BOARD_1_R",
+		"","";
+	};
+
+	gpio_ext2: pca9555 at 21 {
 		compatible = "nxp,pca9555";
-		reg = <0x21>;
+		pinctrl-names = "default";
 		gpio-controller;
 		#gpio-cells = <2>;
-	};
-
-	gpio at 22 {
+		reg = <0x21>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+		"DELTA_MODULE_TYPE","VSENSE_ERR_VDROP_R",
+		"EN_P48V_AUX_0","EN_P48V_AUX_1",
+		"MEDUSA_BOARD_REV_0","MEDUSA_BOARD_REV_1",
+		"MEDUSA_BOARD_REV_2","MEDUSA_BOARD_TYPE",
+		"HSC_OCP_SLOT_ODD_GPIO1","HSC_OCP_SLOT_ODD_GPIO2",
+		"HSC_OCP_SLOT_ODD_GPIO3","HSC_OCP_SLOT_EVEN_GPIO1",
+		"HSC_OCP_SLOT_EVEN_GPIO2","HSC_OCP_SLOT_EVEN_GPIO3",
+		"ADC_TYPE_0_R","ADC_TYPE_1_R";
+	};
+
+	gpio_ext3: pca9555 at 22 {
 		compatible = "nxp,pca9555";
-		reg = <0x22>;
+		pinctrl-names = "default";
 		gpio-controller;
 		#gpio-cells = <2>;
-	};
-
-	gpio at 23 {
+		reg = <0x22>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+		"CARD_TYPE_SLOT1","CARD_TYPE_SLOT2",
+		"CARD_TYPE_SLOT3","CARD_TYPE_SLOT4",
+		"CARD_TYPE_SLOT5","CARD_TYPE_SLOT6",
+		"CARD_TYPE_SLOT7","CARD_TYPE_SLOT8",
+		"OC_P48V_HSC_0_N","FLT_P48V_HSC_0_N",
+		"PWRGD_P12V_AUX_1","OC_P48V_HSC_1_N",
+		"FLT_P48V_HSC_1_N","PWRGD_P12V_AUX_1",
+		"MEDUSA_ADC_EFUSE_TYPE_R","P12V_HSC_TYPE";
+	};
+
+	gpio_ext4: pca9555 at 23 {
 		compatible = "nxp,pca9555";
-		reg = <0x23>;
+		pinctrl-names = "default";
 		gpio-controller;
 		#gpio-cells = <2>;
+		reg = <0x23>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+		"HSC1_ALERT1_R_N","HSC2_ALERT1_R_N",
+		"HSC3_ALERT1_R_N","HSC4_ALERT1_R_N",
+		"HSC5_ALERT1_R_N","HSC6_ALERT1_R_N",
+		"HSC7_ALERT1_R_N","HSC8_ALERT1_R_N",
+		"HSC1_ALERT2_R_N","HSC2_ALERT2_R_N",
+		"HSC3_ALERT2_R_N","HSC4_ALERT2_R_N",
+		"HSC5_ALERT2_R_N","HSC6_ALERT2_R_N",
+		"HSC7_ALERT2_R_N","HSC8_ALERT2_R_N";
+	};
+
+	power-sensor at 40 {
+			compatible = "mps,mp5023";
+			reg = <0x40>;
 	};
 
 	temperature-sensor at 48 {
@@ -868,19 +921,29 @@ temperature-sensor at 49 {
 		reg = <0x49>;
 	};
 
-	temperature-sensor at 4a {
-		compatible = "ti,tmp75";
-		reg = <0x4a>;
+	eeprom at 54 {
+		compatible = "atmel,24c128";
+		reg = <0x54>;
 	};
 
-	temperature-sensor at 4b {
-		compatible = "ti,tmp75";
-		reg = <0x4b>;
+	power-sensor at 62 {
+		compatible = "pmbus";
+		reg = <0x62>;
 	};
 
-	eeprom at 54 {
-		compatible = "atmel,24c256";
-		reg = <0x54>;
+	power-sensor at 64 {
+		compatible = "pmbus";
+		reg = <0x64>;
+	};
+
+	power-sensor at 65 {
+		compatible = "pmbus";
+		reg = <0x65>;
+	};
+
+	power-sensor at 68 {
+		compatible = "pmbus";
+		reg = <0x68>;
 	};
 };
 
@@ -898,6 +961,11 @@ eeprom at 50 {
 		reg = <0x50>;
 	};
 
+	eeprom at 54 {
+		compatible = "atmel,24c64";
+		reg = <0x54>;
+	};
+
 	rtc at 6f {
 		compatible = "nuvoton,nct3018y";
 		reg = <0x6f>;
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:40 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:40 +0800
Subject: [PATCH v2 09/14] ARM: dts: aspeed: yosemite4: Revise i2c14 and i2c15 schematic change
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-10-Delphine_CC_Chiu@wiwynn.com>

Revise i2c14 and i2c15 schematic change:
- Revise adc128d818 adc mode for yosemite4 schematic change
- Revise ina233 for yosemite4 schematic change
- Remove idle state setting for yosemite4 NIC connection

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 31 ++++++++++++-------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index ccb5ecd8d9a6..ed2b1200603d 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1010,44 +1010,54 @@ &i2c14 {
 	adc at 1d {
 		compatible = "ti,adc128d818";
 		reg = <0x1d>;
-		ti,mode = /bits/ 8 <2>;
+		ti,mode = /bits/ 8 <1>;
 	};
 
-	adc at 35 {
+	adc at 36 {
 		compatible = "ti,adc128d818";
-		reg = <0x35>;
-		ti,mode = /bits/ 8 <2>;
+		reg = <0x36>;
+		ti,mode = /bits/ 8 <1>;
 	};
 
 	adc at 37 {
 		compatible = "ti,adc128d818";
 		reg = <0x37>;
-		ti,mode = /bits/ 8 <2>;
+		ti,mode = /bits/ 8 <1>;
 	};
 
 	power-sensor at 40 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x40>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	power-sensor at 41 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x41>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	power-sensor at 42 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x42>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	power-sensor at 43 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x43>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	power-sensor at 44 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x44>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	temperature-sensor at 4e {
@@ -1217,7 +1227,6 @@ mctp at 10 {
 
 	i2c-mux at 72 {
 		compatible = "nxp,pca9544";
-		i2c-mux-idle-disconnect;
 		reg = <0x72>;
 
 		imux24: i2c at 0 {
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:42 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:42 +0800
Subject: [PATCH v2 11/14] ARM: dts: aspeed: yosemite4: Revise mx31790 fan tach config
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-12-Delphine_CC_Chiu@wiwynn.com>

Revise fan tach config for max31790 driver change

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 48 +++++++++++++++++--
 1 file changed, 44 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index eb3687bfd632..073f27f1e35f 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1095,8 +1095,18 @@ adc at 1f {
 
 			pwm at 20{
 				compatible = "maxim,max31790";
-				pwm-as-tach = <4 5>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x20>;
+				channel at 4 {
+					reg = <4>;
+					sensor-type = "TACH";
+				};
+
+				channel at 5 {
+					reg = <5>;
+					sensor-type = "TACH";
+				};
 			};
 
 			gpio at 22{
@@ -1108,8 +1118,18 @@ gpio at 22{
 
 			pwm at 2f{
 				compatible = "maxim,max31790";
-				pwm-as-tach = <4 5>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x2f>;
+				channel at 4 {
+					reg = <4>;
+					sensor-type = "TACH";
+				};
+
+				channel at 5 {
+					reg = <5>;
+					sensor-type = "TACH";
+				};
 			};
 
 			adc at 33 {
@@ -1145,8 +1165,18 @@ adc at 1f {
 
 			pwm at 20{
 				compatible = "maxim,max31790";
-				pwm-as-tach = <4 5>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x20>;
+				channel at 4 {
+					reg = <4>;
+					sensor-type = "TACH";
+				};
+
+				channel at 5 {
+					reg = <5>;
+					sensor-type = "TACH";
+				};
 			};
 
 			gpio at 22{
@@ -1158,8 +1188,18 @@ gpio at 22{
 
 			pwm at 2f{
 				compatible = "maxim,max31790";
-				pwm-as-tach = <4 5>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x2f>;
+				channel at 4 {
+					reg = <4>;
+					sensor-type = "TACH";
+				};
+
+				channel at 5 {
+					reg = <5>;
+					sensor-type = "TACH";
+				};
 			};
 
 			adc at 33 {
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:44 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:44 +0800
Subject: [PATCH v2 13/14] ARM: dts: aspeed: yosemite4: support mux to cpld
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-14-Delphine_CC_Chiu@wiwynn.com>

Mux pca9544 to cpld was added on EVT HW schematic design,
so add dts setting for devices behind mux pca9544 to cpld

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 64 ++++++++++++++-----
 1 file changed, 49 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index c8e3a85b7a11..fdc33bffd467 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -36,6 +36,10 @@ aliases {
 		i2c31 = &imux31;
 		i2c32 = &imux32;
 		i2c33 = &imux33;
+		i2c34 = &imux34;
+		i2c35 = &imux35;
+		i2c36 = &imux36;
+		i2c37 = &imux37;
 	};
 
 	chosen {
@@ -951,24 +955,54 @@ &i2c12 {
 	status = "okay";
 	bus-frequency = <400000>;
 
-	temperature-sensor at 48 {
-		compatible = "ti,tmp75";
-		reg = <0x48>;
-	};
+	i2c-mux at 70 {
+		compatible = "nxp,pca9544";
+		i2c-mux-idle-disconnect;
+		reg = <0x70>;
 
-	eeprom at 50 {
-		compatible = "atmel,24c128";
-		reg = <0x50>;
-	};
+		imux34: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
 
-	eeprom at 54 {
-		compatible = "atmel,24c64";
-		reg = <0x54>;
-	};
+			temperature-sensor at 48 {
+				compatible = "ti,tmp75";
+				reg = <0x48>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
 
-	rtc at 6f {
-		compatible = "nuvoton,nct3018y";
-		reg = <0x6f>;
+			eeprom at 54 {
+				compatible = "atmel,24c64";
+				reg = <0x54>;
+			};
+
+			rtc at 6f {
+				compatible = "nuvoton,nct3018y";
+				reg = <0x6f>;
+			};
+		};
+
+		imux35: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+
+		imux36: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+
+		imux37: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
 	};
 };
 
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:43 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:43 +0800
Subject: [PATCH v2 12/14] ARM: dts: aspeed: yosemite4: add mctp config for NIC
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-13-Delphine_CC_Chiu@wiwynn.com>

add mctp config for NIC

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 073f27f1e35f..c8e3a85b7a11 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1273,40 +1273,64 @@ imux24: i2c at 0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
+			mctp-controller;
 			temperature-sensor at 1f {
 				compatible = "ti,tmp421";
 				reg = <0x1f>;
 			};
+
+			emc1403 at 3c {
+				compatible = "smsc,emc1403";
+				reg = <0x3c>;
+			};
 		};
 
 		imux25: i2c at 1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <1>;
+			mctp-controller;
 			temperature-sensor at 1f {
 				compatible = "ti,tmp421";
 				reg = <0x1f>;
 			};
+
+			emc1403 at 3c {
+				compatible = "smsc,emc1403";
+				reg = <0x3c>;
+			};
 		};
 
 		imux26: i2c at 2 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <2>;
+			mctp-controller;
 			temperature-sensor at 1f {
 				compatible = "ti,tmp421";
 				reg = <0x1f>;
 			};
+
+			emc1403 at 3c {
+				compatible = "smsc,emc1403";
+				reg = <0x3c>;
+			};
 		};
 
 		imux27: i2c at 3 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <3>;
+			mctp-controller;
 			temperature-sensor at 1f {
 				compatible = "ti,tmp421";
 				reg = <0x1f>;
 			};
+
+			emc1403 at 3c {
+				compatible = "smsc,emc1403";
+				reg = <0x3c>;
+			};
 		};
 	};
 };
-- 
2.25.1



From chunfeng.yun at mediatek.com  Sun Dec 10 18:56:24 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Mon, 11 Dec 2023 10:56:24 +0800
Subject: [PATCH v2 2/2] phy: mediatek: tphy: add support force phy mode switch
In-Reply-To: <20231211025624.28991-1-chunfeng.yun@mediatek.com>
References: <20231211025624.28991-1-chunfeng.yun@mediatek.com>
Message-ID: <20231211025624.28991-2-chunfeng.yun@mediatek.com>

this is used to be compatible with old SoCs, such as mt8195, which shares
t-phy between usb3 and pcie controller, usually, it's default mode is pcie
rc mode, and could use force mode to switch into usb3 mode, because pericfg
layer doesn't provide mode switch, also no efuse or jumper can be used;
Currently, only support switch from default pcie mode to usb3;
Note: don't use this way on new SoCs, use pericfg layer's mode switch
instead (by perperty "mediatek,syscon-type").

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: modify commit message
---
 drivers/phy/mediatek/phy-mtk-tphy.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c b/drivers/phy/mediatek/phy-mtk-tphy.c
index 05eab9014132..a4746f6cb8a1 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -185,6 +185,10 @@
 #define P3D_RG_CDR_BIR_LTD1		GENMASK(28, 24)
 #define P3D_RG_CDR_BIR_LTD0		GENMASK(12, 8)
 
+#define U3P_U3_PHYD_TOP1		0x100
+#define P3D_RG_PHY_MODE			GENMASK(2, 1)
+#define P3D_RG_FORCE_PHY_MODE		BIT(0)
+
 #define U3P_U3_PHYD_RXDET1		0x128
 #define P3D_RG_RXDET_STB2_SET		GENMASK(17, 9)
 
@@ -327,6 +331,7 @@ struct mtk_phy_instance {
 	int discth;
 	int pre_emphasis;
 	bool bc12_en;
+	bool type_force_mode;
 };
 
 struct mtk_tphy {
@@ -768,6 +773,23 @@ static void u3_phy_instance_init(struct mtk_tphy *tphy,
 	void __iomem *phya = u3_banks->phya;
 	void __iomem *phyd = u3_banks->phyd;
 
+	if (instance->type_force_mode) {
+		/* force phy as usb mode, default is pcie rc mode */
+		mtk_phy_update_field(phyd + U3P_U3_PHYD_TOP1, P3D_RG_PHY_MODE, 1);
+		mtk_phy_set_bits(phyd + U3P_U3_PHYD_TOP1, P3D_RG_FORCE_PHY_MODE);
+		/* power down phy by ip and pipe reset */
+		mtk_phy_set_bits(u3_banks->chip + U3P_U3_CHIP_GPIO_CTLD,
+				 P3C_FORCE_IP_SW_RST | P3C_MCU_BUS_CK_GATE_EN);
+		mtk_phy_set_bits(u3_banks->chip + U3P_U3_CHIP_GPIO_CTLE,
+				 P3C_RG_SWRST_U3_PHYD | P3C_RG_SWRST_U3_PHYD_FORCE_EN);
+		udelay(10);
+		/* power on phy again */
+		mtk_phy_clear_bits(u3_banks->chip + U3P_U3_CHIP_GPIO_CTLD,
+				   P3C_FORCE_IP_SW_RST | P3C_MCU_BUS_CK_GATE_EN);
+		mtk_phy_clear_bits(u3_banks->chip + U3P_U3_CHIP_GPIO_CTLE,
+				   P3C_RG_SWRST_U3_PHYD | P3C_RG_SWRST_U3_PHYD_FORCE_EN);
+	}
+
 	/* gating PCIe Analog XTAL clock */
 	mtk_phy_set_bits(u3_banks->spllc + U3P_SPLLC_XTALCTL3,
 			 XC3_RG_U3_XTAL_RX_PWD | XC3_RG_U3_FRC_XTAL_RX_PWD);
@@ -1120,6 +1142,9 @@ static void phy_parse_property(struct mtk_tphy *tphy,
 {
 	struct device *dev = &instance->phy->dev;
 
+	if (instance->type == PHY_TYPE_USB3)
+		instance->type_force_mode = device_property_read_bool(dev, "mediatek,force-mode");
+
 	if (instance->type != PHY_TYPE_USB2)
 		return;
 
-- 
2.18.0



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:41 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:41 +0800
Subject: [PATCH v2 10/14] ARM: dts: aspeed: yosemite4: Initialize bmc gpio state
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-11-Delphine_CC_Chiu@wiwynn.com>

Initialize bmc gpio state

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 195 ++++++++++++++++++
 1 file changed, 195 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index ed2b1200603d..eb3687bfd632 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1271,6 +1271,7 @@ temperature-sensor at 1f {
 	};
 };
 
+
 &adc0 {
 	ref_voltage = <2500>;
 	status = "okay";
@@ -1298,3 +1299,197 @@ &ehci1 {
 &uhci {
 	status = "okay";
 };
+
+&sgpiom0 {
+	status = "okay";
+	ngpios = <128>;
+	bus-frequency = <48000>;
+};
+
+&gpio0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpiu2_default &pinctrl_gpiu3_default
+		     &pinctrl_gpiu4_default &pinctrl_gpiu5_default
+		     &pinctrl_gpiu6_default>;
+	gpio-line-names =
+	/*A0-A7*/       "","","","","","","","",
+	/*B0-B7*/       "FLT_HSC_SERVER_SLOT8_N","AC_ON_OFF_BTN_CPLD_SLOT5_N",
+			"PWRGD_SLOT1_STBY","PWRGD_SLOT2_STBY",
+			"PWRGD_SLOT3_STBY","PWRGD_SLOT4_STBY","","",
+	/*C0-C7*/       "PRSNT_NIC3_N","","","","FM_NIC0_WAKE_N",
+			"FM_NIC1_WAKE_N","","RST_PCIE_SLOT2_N",
+	/*D0-D7*/       "","","","","","","","",
+	/*E0-E7*/       "PRSNT_NIC1_N","PRSNT_NIC2_N","","RST_PCIE_SLOT1_N",
+			"","","","",
+	/*F0-F7*/       "FM_RESBTN_SLOT1_BMC_N","FM_RESBTN_SLOT2_BMC_N",
+			"FM_RESBTN_SLOT3_BMC_N","FM_RESBTN_SLOT4_BMC_N",
+			"PRSNT_SB_SLOT1_N","PRSNT_SB_SLOT2_N",
+			"PRSNT_SB_SLOT3_N","PRSNT_SB_SLOT4_N",
+	/*G0-G7*/       "","","","","","","","",
+	/*H0-H7*/       "","","","","","","","",
+	/*I0-I7*/       "","","","","","ALT_MEDUSA_ADC_N",
+			"ALT_SMB_BMC_CPLD2_N",
+			"INT_SPIDER_ADC_R_N",
+	/*J0-J7*/       "","","","","","","","",
+	/*K0-K7*/       "","","","","","","","",
+	/*L0-L7*/       "","","","","","","ALT_MEDUSA_P12V_EFUSE_N","",
+	/*M0-M7*/       "EN_NIC0_POWER_BMC_R","EN_NIC1_POWER_BMC_R",
+			"INT_MEDUSA_IOEXP_TEMP_N","FLT_P12V_NIC0_N",
+			"INT_SMB_BMC_SLOT1_4_BMC_N",
+			"AC_ON_OFF_BTN_CPLD_SLOT6_N","","",
+	/*N0-N7*/       "FLT_HSC_SERVER_SLOT1_N","FLT_HSC_SERVER_SLOT2_N",
+			"FLT_HSC_SERVER_SLOT3_N","FLT_HSC_SERVER_SLOT4_N",
+			"FM_BMC_READY_R2","FLT_P12V_STBY_BMC_N","","",
+	/*O0-O7*/       "AC_ON_OFF_BTN_CPLD_SLOT8_N","RST_SMB_NIC1_R_N",
+			"RST_SMB_NIC2_R_N","RST_SMB_NIC3_R_N",
+			"FLT_P3V3_NIC2_N","FLT_P3V3_NIC3_N",
+			"","",
+	/*P0-P7*/       "ALT_SMB_BMC_CPLD1_N","'BTN_BMC_R2_N",
+			"EN_P3V_BAT_SCALED_R","PWRGD_P5V_USB_BMC",
+			"FM_BMC_RTCRST_R","RST_USB_HUB_R_N",
+			"FLAG_P5V_USB_BMC_N","",
+	/*Q0-Q7*/       "AC_ON_OFF_BTN_CPLD_SLOT1_N","AC_ON_OFF_BTN_CPLD_SLOT2_N",
+			"AC_ON_OFF_BTN_CPLD_SLOT3_N","AC_ON_OFF_BTN_CPLD_SLOT4_N",
+			"PRSNT_SB_SLOT5_N","PRSNT_SB_SLOT6_N",
+			"PRSNT_SB_SLOT7_N","PRSNT_SB_SLOT8_N",
+	/*R0-R7*/       "AC_ON_OFF_BTN_CPLD_SLOT7_N","INT_SMB_BMC_SLOT5_8_BMC_N",
+			"FM_PWRBRK_NIC_BMC_R2","RST_PCIE_SLOT4_N",
+			"RST_PCIE_SLOT5_N","RST_PCIE_SLOT6_N",
+			"RST_PCIE_SLOT7_N","RST_PCIE_SLOT8_N",
+	/*S0-S7*/       "FM_NIC2_WAKE_N","FM_NIC3_WAKE_N",
+			"EN_NIC3_POWER_BMC_R","SEL_BMC_JTAG_MUX_R",
+			"","ALT_P12V_AUX_N","FAST_PROCHOT_N",
+			"SPI_WP_DISABLE_STATUS_R_N",
+	/*T0-T7*/       "","","","","","","","",
+	/*U0-U7*/       "","","FLT_P3V3_NIC1_N","FLT_P12V_NIC1_N",
+			"FLT_P12V_NIC2_N","FLT_P12V_NIC3_N",
+			"FLT_P3V3_NIC0_N","",
+	/*V0-V7*/       "FM_RESBTN_SLOT5_BMC_N","FM_RESBTN_SLOT6_BMC_N",
+			"FM_RESBTN_SLOT7_BMC_N","FM_RESBTN_SLOT8_BMC_N",
+			"","","","",
+	/*W0-W7*/       "PRSNT_TPM_BMC_N","PRSNT_OCP_DEBUG_BMC_N","ALT_TEMP_BMC_N","ALT_RTC_BMC_N",
+			"","","","",
+	/*X0-X7*/       "","LT_HSC_SERVER_SLOT6_N","FLT_HSC_SERVER_SLOT7_N","","","",
+			"PWRGD_SLOT5_STBY","PWRGD_SLOT6_STBY",
+	/*Y0-Y7*/       "","","SPI_LOCK_REQ_BMC_N","PWRGD_SLOT7_STBY",
+			"","","EN_NIC2_POWER_BMC_R","",
+	/*Z0-Z7*/       "EN_P5V_USB_CPLD_R","'FLT_HSC_SERVER_SLOT5_N",
+			"PWRGD_SLOT8_STBY","","","","","";
+
+	pin_gpio_b4 {
+		gpios = <ASPEED_GPIO(B, 4) GPIO_ACTIVE_HIGH>;
+		input;
+	};
+	pin_gpio_b5 {
+		gpios = <ASPEED_GPIO(B, 5) GPIO_ACTIVE_HIGH>;
+		input;
+	};
+	pin_gpio_f0 {
+		gpios = <ASPEED_GPIO(F, 0) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f1 {
+		gpios = <ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f2 {
+		gpios = <ASPEED_GPIO(F, 2) GPIO_ACTIVE_LOW>;
+		input;
+		};
+	pin_gpio_f3 {
+		gpios = <ASPEED_GPIO(F, 3) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f4 {
+		gpios = <ASPEED_GPIO(F, 4) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f5 {
+		gpios = <ASPEED_GPIO(F, 5) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f6 {
+		gpios = <ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f7 {
+		gpios = <ASPEED_GPIO(F, 7) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_l6 {
+		gpios = <ASPEED_GPIO(L, 6) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_l7 {
+		gpios = <ASPEED_GPIO(L, 7) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_s0 {
+		gpios = <ASPEED_GPIO(S, 0) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_s1 {
+		gpios = <ASPEED_GPIO(S, 1) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_v0 {
+		gpios = <ASPEED_GPIO(V, 0) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_v1 {
+		gpios = <ASPEED_GPIO(V, 1) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_v2 {
+		gpios = <ASPEED_GPIO(V, 2) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_v3 {
+		gpios = <ASPEED_GPIO(V, 3) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w0 {
+		gpios = <ASPEED_GPIO(W, 0) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w1 {
+		gpios = <ASPEED_GPIO(W, 1) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w2 {
+		gpios = <ASPEED_GPIO(W, 2) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w3 {
+		gpios = <ASPEED_GPIO(W, 3) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w4 {
+		gpios = <ASPEED_GPIO(W, 4) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w5 {
+		gpios = <ASPEED_GPIO(W, 5) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w6 {
+		gpios = <ASPEED_GPIO(W, 6) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w7 {
+		gpios = <ASPEED_GPIO(W, 7) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_z3 {
+		gpios = <ASPEED_GPIO(Z, 3) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_z4 {
+		gpios = <ASPEED_GPIO(Z, 4) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_z5 {
+		gpios = <ASPEED_GPIO(Z, 5) GPIO_ACTIVE_LOW>;
+		input;
+	};
+};
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 18:49:45 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 10:49:45 +0800
Subject: [PATCH v2 14/14] ARM: dts: aspeed: yosemite4: Revise gpio name
In-Reply-To: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211024947.3990898-15-Delphine_CC_Chiu@wiwynn.com>

Revise gpio name for EVT schematic changes

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../dts/aspeed/aspeed-bmc-facebook-yosemite4.dts   | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index fdc33bffd467..8c0ee53c8bee 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1414,7 +1414,7 @@ &pinctrl_gpiu4_default &pinctrl_gpiu5_default
 	/*B0-B7*/       "FLT_HSC_SERVER_SLOT8_N","AC_ON_OFF_BTN_CPLD_SLOT5_N",
 			"PWRGD_SLOT1_STBY","PWRGD_SLOT2_STBY",
 			"PWRGD_SLOT3_STBY","PWRGD_SLOT4_STBY","","",
-	/*C0-C7*/       "PRSNT_NIC3_N","","","","FM_NIC0_WAKE_N",
+	/*C0-C7*/       "","","","","FM_NIC0_WAKE_N",
 			"FM_NIC1_WAKE_N","","RST_PCIE_SLOT2_N",
 	/*D0-D7*/       "","","","","","","","",
 	/*E0-E7*/       "PRSNT_NIC1_N","PRSNT_NIC2_N","","RST_PCIE_SLOT1_N",
@@ -1432,16 +1432,15 @@ &pinctrl_gpiu4_default &pinctrl_gpiu5_default
 	/*K0-K7*/       "","","","","","","","",
 	/*L0-L7*/       "","","","","","","ALT_MEDUSA_P12V_EFUSE_N","",
 	/*M0-M7*/       "EN_NIC0_POWER_BMC_R","EN_NIC1_POWER_BMC_R",
-			"INT_MEDUSA_IOEXP_TEMP_N","FLT_P12V_NIC0_N",
+			"INT_MEDUSA_IOEXP_TEMP_N","PRSNT_NIC3_N",
 			"INT_SMB_BMC_SLOT1_4_BMC_N",
 			"AC_ON_OFF_BTN_CPLD_SLOT6_N","","",
 	/*N0-N7*/       "FLT_HSC_SERVER_SLOT1_N","FLT_HSC_SERVER_SLOT2_N",
 			"FLT_HSC_SERVER_SLOT3_N","FLT_HSC_SERVER_SLOT4_N",
-			"FM_BMC_READY_R2","FLT_P12V_STBY_BMC_N","","",
+			"FM_BMC_READY_R2","RST_SMB_NIC0_R_N","","",
 	/*O0-O7*/       "AC_ON_OFF_BTN_CPLD_SLOT8_N","RST_SMB_NIC1_R_N",
 			"RST_SMB_NIC2_R_N","RST_SMB_NIC3_R_N",
-			"FLT_P3V3_NIC2_N","FLT_P3V3_NIC3_N",
-			"","",
+			"","","","",
 	/*P0-P7*/       "ALT_SMB_BMC_CPLD1_N","'BTN_BMC_R2_N",
 			"EN_P3V_BAT_SCALED_R","PWRGD_P5V_USB_BMC",
 			"FM_BMC_RTCRST_R","RST_USB_HUB_R_N",
@@ -1459,9 +1458,8 @@ &pinctrl_gpiu4_default &pinctrl_gpiu5_default
 			"","ALT_P12V_AUX_N","FAST_PROCHOT_N",
 			"SPI_WP_DISABLE_STATUS_R_N",
 	/*T0-T7*/       "","","","","","","","",
-	/*U0-U7*/       "","","FLT_P3V3_NIC1_N","FLT_P12V_NIC1_N",
-			"FLT_P12V_NIC2_N","FLT_P12V_NIC3_N",
-			"FLT_P3V3_NIC0_N","",
+	/*U0-U7*/       "","","RST_PCIE_SLOT3_N","",
+			"","PRSNT_NIC0_N","",""
 	/*V0-V7*/       "FM_RESBTN_SLOT5_BMC_N","FM_RESBTN_SLOT6_BMC_N",
 			"FM_RESBTN_SLOT7_BMC_N","FM_RESBTN_SLOT8_BMC_N",
 			"","","","",
-- 
2.25.1



From chunfeng.yun at mediatek.com  Sun Dec 10 18:56:23 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Mon, 11 Dec 2023 10:56:23 +0800
Subject: [PATCH v2 1/2] dt-bindings: phy: mediatek: tphy: add a property for force-mode switch
Message-ID: <20231211025624.28991-1-chunfeng.yun@mediatek.com>

Due to some old SoCs with shared t-phy between usb3 and pcie only support
force-mode switch, and shared and non-shared t-phy may exist at the same
time on a SoC, can't use compatible to distinguish between shared and
non-shared t-phy, add a property to supported it.
Currently, only support switch from default pcie mode to usb3 mode.
But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: modify commit message, and property description 
---
 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
index 2bb91542e984..acba0720125d 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
@@ -235,6 +235,15 @@ patternProperties:
           Specify the flag to enable BC1.2 if support it
         type: boolean
 
+      mediatek,force-mode:
+        description:
+          The force mode is used to manually switch the shared phy mode between
+          USB3 and PCIe, when USB3 phy type is selected by the consumer, and
+          force-mode is set, will cause phy's power and pipe toggled and force
+          phy as USB3 mode which switched from default PCIe mode. But perfer to
+          use the property "mediatek,syscon-type" for newer SoCs that support it.
+        type: boolean
+
       mediatek,syscon-type:
         $ref: /schemas/types.yaml#/definitions/phandle-array
         maxItems: 1
-- 
2.18.0



From tudor.ambarus at linaro.org  Sun Dec 10 19:33:06 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Mon, 11 Dec 2023 03:33:06 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
Message-ID: <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>



On 12/8/23 17:05, Mahapatra, Amit Kumar wrote:
> Hello Tudor,

Hi!

> 
>> -----Original Message-----
>> From: Tudor Ambarus <tudor.ambarus at linaro.org>
>> Sent: Wednesday, December 6, 2023 8:00 PM
>> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
>> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
>> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
>> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
>> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
>> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
>> michael at walle.cc; linux-mtd at lists.infradead.org;
>> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
>> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
>> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
>> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
>> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
>> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
>> in spi-nor
>>
>> Hi, Amit,
>>
>> On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
>>> Each flash that is connected in stacked mode should have a separate
>>> parameter structure. So, the flash parameter member(*params) of the
>>> spi_nor structure is changed to an array (*params[2]). The array is
>>> used to store the parameters of each flash connected in stacked
>> configuration.
>>>
>>> The current implementation assumes that a maximum of two flashes are
>>> connected in stacked mode and both the flashes are of same make but
>>> can differ in sizes. So, except the sizes all other flash parameters
>>> of both the flashes are identical.
>>
>> Do you plan to add support for different flashes in stacked mode? If not,
> 
> No, according to the current implementation, in stacked mode, both flashes 
> must be of the same make.
> 
>> wouldn't it be simpler to have just an array of flash sizes instead of
>> duplicating the entire params struct?
> 
> Yes, that is accurate. In alignment with our current stacked support use case we 
> can have an array of flash sizes instead.
> The primary purpose of having an array of params struct was to facilitate 
> potential future extensions, allowing the addition of stacked support for 
> different flashes
> 

right. Don't do this change yet, let's decide on the overall
architecture first.

>>
>>>
>>> SPI-NOR is not aware of the chip_select values, for any incoming
>>> request SPI-NOR will decide the flash index with the help of
>>> individual flash size and the configuration type (single/stacked).
>>> SPI-NOR will pass on the flash index information to the SPI core & SPI
>>> driver by setting the appropriate bit in
>>> nor->spimem->spi->cs_index_mask. For example, if nth bit of
>>> nor->spimem->spi->cs_index_mask is set then the driver would
>>> assert/de-assert spi->chip_slect[n].
>>>
>>> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at amd.com>
>>> ---
>>>  drivers/mtd/spi-nor/core.c  | 272 +++++++++++++++++++++++++++++-------
>>>  drivers/mtd/spi-nor/core.h  |   4 +
>>>  include/linux/mtd/spi-nor.h |  15 +-
>>>  3 files changed, 240 insertions(+), 51 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>>> index 93ae69b7ff83..e990be7c7eb6 100644
>>> --- a/drivers/mtd/spi-nor/core.c
>>> +++ b/drivers/mtd/spi-nor/core.c
>>
>> cut
>>
>>> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct
>>> spi_nor *nor)  static int spi_nor_late_init_params(struct spi_nor
>>> *nor)  {
>>>  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
>> 0);
>>> -	int ret;
>>> +	struct device_node *np = spi_nor_get_flash_node(nor);
>>> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
>>> +	u32 idx = 0;
>>> +	int rc, ret;
>>>
>>>  	if (nor->manufacturer && nor->manufacturer->fixups &&
>>>  	    nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
>>> static int spi_nor_late_init_params(struct spi_nor *nor)
>>>  	if (params->n_banks > 1)
>>>  		params->bank_size = div64_u64(params->size, params-
>>> n_banks);
>>>
>>> +	nor->num_flash = 0;
>>> +
>>> +	/*
>>> +	 * The flashes that are connected in stacked mode should be of same
>> make.
>>> +	 * Except the flash size all other properties are identical for all the
>>> +	 * flashes connected in stacked mode.
>>> +	 * The flashes that are connected in parallel mode should be identical.
>>> +	 */
>>> +	while (idx < SNOR_FLASH_CNT_MAX) {
>>> +		rc = of_property_read_u64_index(np, "stacked-memories",
>> idx,
>>> +&flash_size[idx]);
>>
>> This is a little late in my opinion, as we don't have any sanity check on the
>> flashes that are stacked on top of the first. We shall at least read and compare
>> the ID for all.
> 
> Alright, I will incorporate a sanity check for reading and comparing the 
> ID of the stacked flash. Subsequently, I believe this stacked logic 
> should be relocated to spi_nor_get_flash_info() where we identify the 
> first flash. Please share your thoughts on this. Additionally, do you 

I'm wondering whether we can add a layer on top of the flash type to
handle the stacked/parallel modes. This way everything will become flash
type independent. Would it be possible to stack 2 SPI NANDs? How about a
SPI NOR and a SPI NAND?

Is the datasheet of the controller public?

> anticipate that SPI-NOR should throw an error if the second or any 
> subsequent flash within the stacked connection is different? Or would you 
> prefer it to print a warning and operate in single mode (i.e., only the 
> first flash)?

Both options are fine, but I haven't yet decided on the overall
architecture.

Cheers,
ta


From quic_kathirav at quicinc.com  Sun Dec 10 19:37:24 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 09:07:24 +0530
Subject: [PATCH v3 2/8] clk: qcom: ipq5332: enable few nssnoc clocks in
 driver probe
In-Reply-To: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
Message-ID: <20231211-ipq5332-nsscc-v3-2-ad13bef9b137@quicinc.com>

gcc_snoc_nssnoc_clk, gcc_snoc_nssnoc_1_clk, gcc_nssnoc_nsscc_clk are
enabled by default and it's RCG is properly configured by bootloader.

Some of the NSS clocks needs these clocks to be enabled. To avoid
these clocks being disabled by clock framework, drop these entries
from the clock table and enable it in the driver probe itself.

Acked-by: Konrad Dybcio <konrad.dybcio at linaro.org>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
---
 drivers/clk/qcom/gcc-ipq5332.c | 70 ++++++++----------------------------------
 1 file changed, 12 insertions(+), 58 deletions(-)

diff --git a/drivers/clk/qcom/gcc-ipq5332.c b/drivers/clk/qcom/gcc-ipq5332.c
index 66d5399798fe..38a570b68813 100644
--- a/drivers/clk/qcom/gcc-ipq5332.c
+++ b/drivers/clk/qcom/gcc-ipq5332.c
@@ -1672,24 +1672,6 @@ static struct clk_branch gcc_nssnoc_atb_clk = {
 	},
 };
 
-static struct clk_branch gcc_nssnoc_nsscc_clk = {
-	.halt_reg = 0x17030,
-	.halt_check = BRANCH_HALT,
-	.clkr = {
-		.enable_reg = 0x17030,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "gcc_nssnoc_nsscc_clk",
-			.parent_hws = (const struct clk_hw*[]) {
-				&gcc_pcnoc_bfdcd_clk_src.clkr.hw,
-			},
-			.num_parents = 1,
-			.flags = CLK_SET_RATE_PARENT,
-			.ops = &clk_branch2_ops,
-		},
-	},
-};
-
 static struct clk_branch gcc_nssnoc_qosgen_ref_clk = {
 	.halt_reg = 0x1701c,
 	.halt_check = BRANCH_HALT,
@@ -2585,42 +2567,6 @@ static struct clk_branch gcc_snoc_lpass_cfg_clk = {
 	},
 };
 
-static struct clk_branch gcc_snoc_nssnoc_1_clk = {
-	.halt_reg = 0x17090,
-	.halt_check = BRANCH_HALT,
-	.clkr = {
-		.enable_reg = 0x17090,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "gcc_snoc_nssnoc_1_clk",
-			.parent_hws = (const struct clk_hw*[]) {
-				&gcc_system_noc_bfdcd_clk_src.clkr.hw,
-			},
-			.num_parents = 1,
-			.flags = CLK_SET_RATE_PARENT,
-			.ops = &clk_branch2_ops,
-		},
-	},
-};
-
-static struct clk_branch gcc_snoc_nssnoc_clk = {
-	.halt_reg = 0x17084,
-	.halt_check = BRANCH_HALT,
-	.clkr = {
-		.enable_reg = 0x17084,
-		.enable_mask = BIT(0),
-		.hw.init = &(const struct clk_init_data) {
-			.name = "gcc_snoc_nssnoc_clk",
-			.parent_hws = (const struct clk_hw*[]) {
-				&gcc_system_noc_bfdcd_clk_src.clkr.hw,
-			},
-			.num_parents = 1,
-			.flags = CLK_SET_RATE_PARENT,
-			.ops = &clk_branch2_ops,
-		},
-	},
-};
-
 static struct clk_branch gcc_snoc_pcie3_1lane_1_m_clk = {
 	.halt_reg = 0x2e050,
 	.halt_check = BRANCH_HALT,
@@ -3330,7 +3276,6 @@ static struct clk_regmap *gcc_ipq5332_clocks[] = {
 	[GCC_NSSCC_CLK] = &gcc_nsscc_clk.clkr,
 	[GCC_NSSCFG_CLK] = &gcc_nsscfg_clk.clkr,
 	[GCC_NSSNOC_ATB_CLK] = &gcc_nssnoc_atb_clk.clkr,
-	[GCC_NSSNOC_NSSCC_CLK] = &gcc_nssnoc_nsscc_clk.clkr,
 	[GCC_NSSNOC_QOSGEN_REF_CLK] = &gcc_nssnoc_qosgen_ref_clk.clkr,
 	[GCC_NSSNOC_SNOC_1_CLK] = &gcc_nssnoc_snoc_1_clk.clkr,
 	[GCC_NSSNOC_SNOC_CLK] = &gcc_nssnoc_snoc_clk.clkr,
@@ -3398,8 +3343,6 @@ static struct clk_regmap *gcc_ipq5332_clocks[] = {
 	[GCC_SDCC1_APPS_CLK_SRC] = &gcc_sdcc1_apps_clk_src.clkr,
 	[GCC_SLEEP_CLK_SRC] = &gcc_sleep_clk_src.clkr,
 	[GCC_SNOC_LPASS_CFG_CLK] = &gcc_snoc_lpass_cfg_clk.clkr,
-	[GCC_SNOC_NSSNOC_1_CLK] = &gcc_snoc_nssnoc_1_clk.clkr,
-	[GCC_SNOC_NSSNOC_CLK] = &gcc_snoc_nssnoc_clk.clkr,
 	[GCC_SNOC_PCIE3_1LANE_1_M_CLK] = &gcc_snoc_pcie3_1lane_1_m_clk.clkr,
 	[GCC_SNOC_PCIE3_1LANE_1_S_CLK] = &gcc_snoc_pcie3_1lane_1_s_clk.clkr,
 	[GCC_SNOC_PCIE3_1LANE_M_CLK] = &gcc_snoc_pcie3_1lane_m_clk.clkr,
@@ -3660,7 +3603,18 @@ static const struct qcom_cc_desc gcc_ipq5332_desc = {
 
 static int gcc_ipq5332_probe(struct platform_device *pdev)
 {
-	return qcom_cc_probe(pdev, &gcc_ipq5332_desc);
+	struct regmap *regmap;
+
+	regmap = qcom_cc_map(pdev, &gcc_ipq5332_desc);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	/* Keep the critical clocks always-On */
+	regmap_update_bits(regmap, 0x17030, BIT(0), BIT(0)); /* gcc_nssnoc_nsscc_clk */
+	regmap_update_bits(regmap, 0x17084, BIT(0), BIT(0)); /* gcc_snoc_nssnoc_clk */
+	regmap_update_bits(regmap, 0x17090, BIT(0), BIT(0)); /* gcc_snoc_nssnoc_1_clk */
+
+	return qcom_cc_really_probe(pdev, &gcc_ipq5332_desc, regmap);
 }
 
 static const struct of_device_id gcc_ipq5332_match_table[] = {

-- 
2.34.1



From quic_kathirav at quicinc.com  Sun Dec 10 19:37:22 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 09:07:22 +0530
Subject: [PATCH v3 0/8] Add NSS clock controller support for Qualcomm
 IPQ5332
Message-ID: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>

Add bindings, driver and devicetree node for networking sub system clock
controller on IPQ5332. Some of the nssnoc clocks present in GCC driver is
enabled by default and its RCG is configured by bootloaders, so enable
those clocks in driver probe.

The NSS clock controller driver depends on the below patchset which adds
support for multiple configurations for same frequency.
https://lore.kernel.org/linux-arm-msm/20231124151847.1915-1-ansuelsmth at gmail.com/

Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
---
Changes in v3:
- Collected the tags
- Dropped the dt-binding patch 3/9
- Cleaned up the header file inclusion and updated the module
  description in the driver
- Used the decimal number instead of hex in the NSSCC node
- Link to v2: https://lore.kernel.org/r/20231121-ipq5332-nsscc-v2-0-a7ff61beab72 at quicinc.com

Changes in v2:
- Change logs are in respective patches
- Link to v1: https://lore.kernel.org/r/20231030-ipq5332-nsscc-v1-0-6162a2c65f0a at quicinc.com

---
Kathiravan Thirumoorthy (8):
      clk: qcom: ipq5332: add const qualifier to the clk_init_data structure
      clk: qcom: ipq5332: enable few nssnoc clocks in driver probe
      dt-bindings: clock: ipq5332: add definition for GPLL0_OUT_AUX clock
      clk: qcom: ipq5332: add gpll0_out_aux clock
      dt-bindings: clock: add Qualcomm IPQ5332 NSSCC clock and reset definitions
      clk: qcom: add NSS clock Controller driver for Qualcomm IPQ5332
      arm64: dts: qcom: ipq5332: add support for the NSSCC
      arm64: defconfig: build NSS Clock Controller driver for Qualcomm IPQ5332

 .../bindings/clock/qcom,ipq5332-nsscc.yaml         |   60 ++
 arch/arm64/boot/dts/qcom/ipq5332.dtsi              |   28 +
 arch/arm64/configs/defconfig                       |    1 +
 drivers/clk/qcom/Kconfig                           |    7 +
 drivers/clk/qcom/Makefile                          |    1 +
 drivers/clk/qcom/gcc-ipq5332.c                     |  122 +--
 drivers/clk/qcom/nsscc-ipq5332.c                   | 1031 ++++++++++++++++++++
 include/dt-bindings/clock/qcom,ipq5332-gcc.h       |    1 +
 include/dt-bindings/clock/qcom,ipq5332-nsscc.h     |   86 ++
 9 files changed, 1260 insertions(+), 77 deletions(-)
---
base-commit: bc63de6e6ba0b16652c5fb4b9c9916b9e7ca1f23
change-id: 20231030-ipq5332-nsscc-aeac9e153045

Best regards,
-- 
Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>



From quic_kathirav at quicinc.com  Sun Dec 10 19:37:23 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 09:07:23 +0530
Subject: [PATCH v3 1/8] clk: qcom: ipq5332: add const qualifier to the
 clk_init_data structure
In-Reply-To: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
Message-ID: <20231211-ipq5332-nsscc-v3-1-ad13bef9b137@quicinc.com>

There are few places where clk_init_data structure doesn't carry the const
qualifier. Let's add the same.

Acked-by: Konrad Dybcio <konrad.dybcio at linaro.org>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
---
 drivers/clk/qcom/gcc-ipq5332.c | 38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/clk/qcom/gcc-ipq5332.c b/drivers/clk/qcom/gcc-ipq5332.c
index f98591148a97..66d5399798fe 100644
--- a/drivers/clk/qcom/gcc-ipq5332.c
+++ b/drivers/clk/qcom/gcc-ipq5332.c
@@ -65,7 +65,7 @@ static struct clk_alpha_pll gpll0_main = {
 static struct clk_fixed_factor gpll0_div2 = {
 	.mult = 1,
 	.div = 2,
-	.hw.init = &(struct clk_init_data) {
+	.hw.init = &(const struct clk_init_data) {
 		.name = "gpll0_div2",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gpll0_main.clkr.hw },
@@ -78,7 +78,7 @@ static struct clk_alpha_pll_postdiv gpll0 = {
 	.offset = 0x20000,
 	.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_STROMER_PLUS],
 	.width = 4,
-	.clkr.hw.init = &(struct clk_init_data) {
+	.clkr.hw.init = &(const struct clk_init_data) {
 		.name = "gpll0",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gpll0_main.clkr.hw },
@@ -106,7 +106,7 @@ static struct clk_alpha_pll_postdiv gpll2 = {
 	.offset = 0x21000,
 	.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_STROMER_PLUS],
 	.width = 4,
-	.clkr.hw.init = &(struct clk_init_data) {
+	.clkr.hw.init = &(const struct clk_init_data) {
 		.name = "gpll2_main",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gpll2_main.clkr.hw },
@@ -145,7 +145,7 @@ static struct clk_alpha_pll_postdiv gpll4 = {
 	.offset = 0x22000,
 	.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_STROMER_PLUS],
 	.width = 4,
-	.clkr.hw.init = &(struct clk_init_data) {
+	.clkr.hw.init = &(const struct clk_init_data) {
 		.name = "gpll4",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gpll4_main.clkr.hw },
@@ -572,7 +572,7 @@ static struct clk_branch gcc_pcie3x1_0_rchg_clk = {
 	.clkr = {
 		.enable_reg = 0x2907c,
 		.enable_mask = BIT(1),
-		.hw.init = &(struct clk_init_data) {
+		.hw.init = &(const struct clk_init_data) {
 			.name = "gcc_pcie3x1_0_rchg_clk",
 			.parent_hws = (const struct clk_hw *[]) {
 					&gcc_pcie3x1_0_rchg_clk_src.clkr.hw },
@@ -615,7 +615,7 @@ static struct clk_branch gcc_pcie3x1_1_rchg_clk = {
 	.clkr = {
 		.enable_reg = 0x2a078,
 		.enable_mask = BIT(1),
-		.hw.init = &(struct clk_init_data) {
+		.hw.init = &(const struct clk_init_data) {
 			.name = "gcc_pcie3x1_1_rchg_clk",
 			.parent_hws = (const struct clk_hw *[]) {
 					&gcc_pcie3x1_1_rchg_clk_src.clkr.hw },
@@ -678,7 +678,7 @@ static struct clk_branch gcc_pcie3x2_rchg_clk = {
 	.clkr = {
 		.enable_reg = 0x28078,
 		.enable_mask = BIT(1),
-		.hw.init = &(struct clk_init_data) {
+		.hw.init = &(const struct clk_init_data) {
 			.name = "gcc_pcie3x2_rchg_clk",
 			.parent_hws = (const struct clk_hw *[]) {
 					&gcc_pcie3x2_rchg_clk_src.clkr.hw },
@@ -711,7 +711,7 @@ static struct clk_rcg2 gcc_pcie_aux_clk_src = {
 static struct clk_regmap_phy_mux gcc_pcie3x2_pipe_clk_src = {
 	.reg = 0x28064,
 	.clkr = {
-		.hw.init = &(struct clk_init_data) {
+		.hw.init = &(const struct clk_init_data) {
 			.name = "gcc_pcie3x2_pipe_clk_src",
 			.parent_data = &(const struct clk_parent_data) {
 				.index = DT_PCIE_2LANE_PHY_PIPE_CLK,
@@ -725,7 +725,7 @@ static struct clk_regmap_phy_mux gcc_pcie3x2_pipe_clk_src = {
 static struct clk_regmap_phy_mux gcc_pcie3x1_0_pipe_clk_src = {
 	.reg = 0x29064,
 	.clkr = {
-		.hw.init = &(struct clk_init_data) {
+		.hw.init = &(const struct clk_init_data) {
 			.name = "gcc_pcie3x1_0_pipe_clk_src",
 			.parent_data = &(const struct clk_parent_data) {
 				.index = DT_USB_PCIE_WRAPPER_PIPE_CLK,
@@ -739,7 +739,7 @@ static struct clk_regmap_phy_mux gcc_pcie3x1_0_pipe_clk_src = {
 static struct clk_regmap_phy_mux gcc_pcie3x1_1_pipe_clk_src = {
 	.reg = 0x2a064,
 	.clkr = {
-		.hw.init = &(struct clk_init_data) {
+		.hw.init = &(const struct clk_init_data) {
 			.name = "gcc_pcie3x1_1_pipe_clk_src",
 			.parent_data = &(const struct clk_parent_data) {
 				.index = DT_PCIE_2LANE_PHY_PIPE_CLK_X1,
@@ -826,7 +826,7 @@ static struct clk_rcg2 gcc_qdss_tsctr_clk_src = {
 static struct clk_fixed_factor gcc_qdss_tsctr_div2_clk_src = {
 	.mult = 1,
 	.div = 2,
-	.hw.init = &(struct clk_init_data) {
+	.hw.init = &(const struct clk_init_data) {
 		.name = "gcc_qdss_tsctr_div2_clk_src",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gcc_qdss_tsctr_clk_src.clkr.hw },
@@ -839,7 +839,7 @@ static struct clk_fixed_factor gcc_qdss_tsctr_div2_clk_src = {
 static struct clk_fixed_factor gcc_qdss_tsctr_div3_clk_src = {
 	.mult = 1,
 	.div = 3,
-	.hw.init = &(struct clk_init_data) {
+	.hw.init = &(const struct clk_init_data) {
 		.name = "gcc_qdss_tsctr_div3_clk_src",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gcc_qdss_tsctr_clk_src.clkr.hw },
@@ -851,7 +851,7 @@ static struct clk_fixed_factor gcc_qdss_tsctr_div3_clk_src = {
 static struct clk_fixed_factor gcc_qdss_tsctr_div4_clk_src = {
 	.mult = 1,
 	.div = 4,
-	.hw.init = &(struct clk_init_data) {
+	.hw.init = &(const struct clk_init_data) {
 		.name = "gcc_qdss_tsctr_div4_clk_src",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gcc_qdss_tsctr_clk_src.clkr.hw },
@@ -863,7 +863,7 @@ static struct clk_fixed_factor gcc_qdss_tsctr_div4_clk_src = {
 static struct clk_fixed_factor gcc_qdss_tsctr_div8_clk_src = {
 	.mult = 1,
 	.div = 8,
-	.hw.init = &(struct clk_init_data) {
+	.hw.init = &(const struct clk_init_data) {
 		.name = "gcc_qdss_tsctr_div8_clk_src",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gcc_qdss_tsctr_clk_src.clkr.hw },
@@ -875,7 +875,7 @@ static struct clk_fixed_factor gcc_qdss_tsctr_div8_clk_src = {
 static struct clk_fixed_factor gcc_qdss_tsctr_div16_clk_src = {
 	.mult = 1,
 	.div = 16,
-	.hw.init = &(struct clk_init_data) {
+	.hw.init = &(const struct clk_init_data) {
 		.name = "gcc_qdss_tsctr_div16_clk_src",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gcc_qdss_tsctr_clk_src.clkr.hw },
@@ -976,7 +976,7 @@ static struct clk_rcg2 gcc_system_noc_bfdcd_clk_src = {
 static struct clk_fixed_factor gcc_system_noc_bfdcd_div2_clk_src = {
 	.mult = 1,
 	.div = 2,
-	.hw.init = &(struct clk_init_data) {
+	.hw.init = &(const struct clk_init_data) {
 		.name = "gcc_system_noc_bfdcd_div2_clk_src",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gcc_system_noc_bfdcd_clk_src.clkr.hw },
@@ -1069,7 +1069,7 @@ static struct clk_rcg2 gcc_usb0_mock_utmi_clk_src = {
 static struct clk_regmap_phy_mux gcc_usb0_pipe_clk_src = {
 	.reg = 0x2c074,
 	.clkr = {
-		.hw.init = &(struct clk_init_data) {
+		.hw.init = &(const struct clk_init_data) {
 			.name = "gcc_usb0_pipe_clk_src",
 			.parent_data = &(const struct clk_parent_data) {
 				.index = DT_USB_PCIE_WRAPPER_PIPE_CLK,
@@ -1111,7 +1111,7 @@ static struct clk_rcg2 gcc_xo_clk_src = {
 static struct clk_fixed_factor gcc_xo_div4_clk_src = {
 	.mult = 1,
 	.div = 4,
-	.hw.init = &(struct clk_init_data) {
+	.hw.init = &(const struct clk_init_data) {
 		.name = "gcc_xo_div4_clk_src",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gcc_xo_clk_src.clkr.hw },
@@ -2431,7 +2431,7 @@ static struct clk_branch gcc_qdss_etr_usb_clk = {
 static struct clk_fixed_factor gcc_eud_at_div_clk_src = {
 	.mult = 1,
 	.div = 6,
-	.hw.init = &(struct clk_init_data) {
+	.hw.init = &(const struct clk_init_data) {
 		.name = "gcc_eud_at_div_clk_src",
 		.parent_hws = (const struct clk_hw *[]) {
 				&gcc_qdss_at_clk_src.clkr.hw },

-- 
2.34.1



From quic_kathirav at quicinc.com  Sun Dec 10 19:37:25 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 09:07:25 +0530
Subject: [PATCH v3 3/8] dt-bindings: clock: ipq5332: add definition for
 GPLL0_OUT_AUX clock
In-Reply-To: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
Message-ID: <20231211-ipq5332-nsscc-v3-3-ad13bef9b137@quicinc.com>

Add the definition for GPLL0_OUT_AUX clock.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
---
 include/dt-bindings/clock/qcom,ipq5332-gcc.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/qcom,ipq5332-gcc.h b/include/dt-bindings/clock/qcom,ipq5332-gcc.h
index 8a405a0a96d0..24486eb47ed8 100644
--- a/include/dt-bindings/clock/qcom,ipq5332-gcc.h
+++ b/include/dt-bindings/clock/qcom,ipq5332-gcc.h
@@ -179,6 +179,7 @@
 #define GCC_PCIE3X1_0_PIPE_CLK_SRC			170
 #define GCC_PCIE3X1_1_PIPE_CLK_SRC			171
 #define GCC_USB0_PIPE_CLK_SRC				172
+#define GPLL0_OUT_AUX					173
 
 #define GCC_ADSS_BCR					0
 #define GCC_ADSS_PWM_CLK_ARES				1

-- 
2.34.1



From quic_kathirav at quicinc.com  Sun Dec 10 19:37:26 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 09:07:26 +0530
Subject: [PATCH v3 4/8] clk: qcom: ipq5332: add gpll0_out_aux clock
In-Reply-To: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
Message-ID: <20231211-ipq5332-nsscc-v3-4-ad13bef9b137@quicinc.com>

Add support for gpll0_out_aux clock which acts as the parent for
certain networking subsystem (NSS) clocks.

Acked-by: Konrad Dybcio <konrad.dybcio at linaro.org>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
---
 drivers/clk/qcom/gcc-ipq5332.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/clk/qcom/gcc-ipq5332.c b/drivers/clk/qcom/gcc-ipq5332.c
index 38a570b68813..9a5f0c98f734 100644
--- a/drivers/clk/qcom/gcc-ipq5332.c
+++ b/drivers/clk/qcom/gcc-ipq5332.c
@@ -87,6 +87,19 @@ static struct clk_alpha_pll_postdiv gpll0 = {
 	},
 };
 
+static struct clk_alpha_pll_postdiv gpll0_out_aux = {
+	.offset = 0x20000,
+	.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_STROMER_PLUS],
+	.width = 4,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "gpll0_out_aux",
+		.parent_hws = (const struct clk_hw *[]) {
+				&gpll0_main.clkr.hw },
+		.num_parents = 1,
+		.ops = &clk_alpha_pll_postdiv_ro_ops,
+	},
+};
+
 static struct clk_alpha_pll gpll2_main = {
 	.offset = 0x21000,
 	.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_STROMER_PLUS],
@@ -3393,6 +3406,7 @@ static struct clk_regmap *gcc_ipq5332_clocks[] = {
 	[GCC_PCIE3X1_0_PIPE_CLK_SRC] = &gcc_pcie3x1_0_pipe_clk_src.clkr,
 	[GCC_PCIE3X1_1_PIPE_CLK_SRC] = &gcc_pcie3x1_1_pipe_clk_src.clkr,
 	[GCC_USB0_PIPE_CLK_SRC] = &gcc_usb0_pipe_clk_src.clkr,
+	[GPLL0_OUT_AUX] = &gpll0_out_aux.clkr,
 };
 
 static const struct qcom_reset_map gcc_ipq5332_resets[] = {

-- 
2.34.1



From quic_kathirav at quicinc.com  Sun Dec 10 19:37:27 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 09:07:27 +0530
Subject: [PATCH v3 5/8] dt-bindings: clock: add Qualcomm IPQ5332 NSSCC
 clock and reset definitions
In-Reply-To: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
Message-ID: <20231211-ipq5332-nsscc-v3-5-ad13bef9b137@quicinc.com>

Add NSSCC clock and reset definitions for Qualcomm IPQ5332.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
---
 .../bindings/clock/qcom,ipq5332-nsscc.yaml         | 60 +++++++++++++++
 include/dt-bindings/clock/qcom,ipq5332-nsscc.h     | 86 ++++++++++++++++++++++
 2 files changed, 146 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5332-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5332-nsscc.yaml
new file mode 100644
index 000000000000..59f8d1e99229
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq5332-nsscc.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,ipq5332-nsscc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Networking Sub System Clock & Reset Controller on IPQ5332
+
+maintainers:
+  - Bjorn Andersson <andersson at kernel.org>
+
+description: |
+  Qualcomm networking sub system clock control module provides the clocks,
+  resets and power domains on IPQ5332
+
+  See also::
+    include/dt-bindings/clock/qcom,ipq5332-nsscc.h
+
+allOf:
+  - $ref: qcom,gcc.yaml#
+
+properties:
+  compatible:
+    const: qcom,ipq5332-nsscc
+
+  clocks:
+    items:
+      - description: Common PLL nss clock 200M source
+      - description: Common PLL nss clock 300M source
+      - description: GCC GPLL0 out aux clock source
+      - description: Uniphy0 NSS Rx clock source
+      - description: Uniphy0 NSS Tx clock source
+      - description: Uniphy1 NSS Rx clock source
+      - description: Uniphy1 NSS Tx clock source
+      - description: Board XO source
+
+required:
+  - compatible
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    clock-controller at 39b00000 {
+      compatible = "qcom,ipq5332-nsscc";
+      reg = <0x39b00000 0x80000>;
+      clocks = <&bias_pll_cc_clk>,
+               <&bias_pll_nss_noc_clk>,
+               <&gcc_gpll0_out_aux>,
+               <&uniphy 0>,
+               <&uniphy 1>,
+               <&uniphy 2>,
+               <&uniphy 3>,
+               <&xo_board_clk>;
+      #clock-cells = <1>;
+      #reset-cells = <1>;
+      #power-domain-cells = <1>;
+    };
+...
diff --git a/include/dt-bindings/clock/qcom,ipq5332-nsscc.h b/include/dt-bindings/clock/qcom,ipq5332-nsscc.h
new file mode 100644
index 000000000000..c077cde7f57d
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,ipq5332-nsscc.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2022-2023, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_NSS_CC_IPQ5332_H
+#define _DT_BINDINGS_CLK_QCOM_NSS_CC_IPQ5332_H
+
+/* NSS_CC clocks */
+#define NSS_CC_CE_APB_CLK					0
+#define NSS_CC_CE_AXI_CLK					1
+#define NSS_CC_CE_CLK_SRC					2
+#define NSS_CC_CFG_CLK_SRC					3
+#define NSS_CC_DEBUG_CLK					4
+#define NSS_CC_EIP_BFDCD_CLK_SRC				5
+#define NSS_CC_EIP_CLK						6
+#define NSS_CC_NSS_CSR_CLK					7
+#define NSS_CC_NSSNOC_CE_APB_CLK				8
+#define NSS_CC_NSSNOC_CE_AXI_CLK				9
+#define NSS_CC_NSSNOC_EIP_CLK					10
+#define NSS_CC_NSSNOC_NSS_CSR_CLK				11
+#define NSS_CC_NSSNOC_PPE_CFG_CLK				12
+#define NSS_CC_NSSNOC_PPE_CLK					13
+#define NSS_CC_PORT1_MAC_CLK					14
+#define NSS_CC_PORT1_RX_CLK					15
+#define NSS_CC_PORT1_RX_CLK_SRC					16
+#define NSS_CC_PORT1_RX_DIV_CLK_SRC				17
+#define NSS_CC_PORT1_TX_CLK					18
+#define NSS_CC_PORT1_TX_CLK_SRC					19
+#define NSS_CC_PORT1_TX_DIV_CLK_SRC				20
+#define NSS_CC_PORT2_MAC_CLK					21
+#define NSS_CC_PORT2_RX_CLK					22
+#define NSS_CC_PORT2_RX_CLK_SRC					23
+#define NSS_CC_PORT2_RX_DIV_CLK_SRC				24
+#define NSS_CC_PORT2_TX_CLK					25
+#define NSS_CC_PORT2_TX_CLK_SRC					26
+#define NSS_CC_PORT2_TX_DIV_CLK_SRC				27
+#define NSS_CC_PPE_CLK_SRC					28
+#define NSS_CC_PPE_EDMA_CFG_CLK					29
+#define NSS_CC_PPE_EDMA_CLK					30
+#define NSS_CC_PPE_SWITCH_BTQ_CLK				31
+#define NSS_CC_PPE_SWITCH_CFG_CLK				32
+#define NSS_CC_PPE_SWITCH_CLK					33
+#define NSS_CC_PPE_SWITCH_IPE_CLK				34
+#define NSS_CC_UNIPHY_PORT1_RX_CLK				35
+#define NSS_CC_UNIPHY_PORT1_TX_CLK				36
+#define NSS_CC_UNIPHY_PORT2_RX_CLK				37
+#define NSS_CC_UNIPHY_PORT2_TX_CLK				38
+#define NSS_CC_XGMAC0_PTP_REF_CLK				39
+#define NSS_CC_XGMAC0_PTP_REF_DIV_CLK_SRC			40
+#define NSS_CC_XGMAC1_PTP_REF_CLK				41
+#define NSS_CC_XGMAC1_PTP_REF_DIV_CLK_SRC			42
+
+#define NSS_CC_CE_APB_CLK_ARES					0
+#define NSS_CC_CE_AXI_CLK_ARES					1
+#define NSS_CC_DEBUG_CLK_ARES					2
+#define NSS_CC_EIP_CLK_ARES					3
+#define NSS_CC_NSS_CSR_CLK_ARES					4
+#define NSS_CC_NSSNOC_CE_APB_CLK_ARES				5
+#define NSS_CC_NSSNOC_CE_AXI_CLK_ARES				6
+#define NSS_CC_NSSNOC_EIP_CLK_ARES				7
+#define NSS_CC_NSSNOC_NSS_CSR_CLK_ARES				8
+#define NSS_CC_NSSNOC_PPE_CLK_ARES				9
+#define NSS_CC_NSSNOC_PPE_CFG_CLK_ARES				10
+#define NSS_CC_PORT1_MAC_CLK_ARES				11
+#define NSS_CC_PORT1_RX_CLK_ARES				12
+#define NSS_CC_PORT1_TX_CLK_ARES				13
+#define NSS_CC_PORT2_MAC_CLK_ARES				14
+#define NSS_CC_PORT2_RX_CLK_ARES				15
+#define NSS_CC_PORT2_TX_CLK_ARES				16
+#define NSS_CC_PPE_BCR						17
+#define NSS_CC_PPE_EDMA_CLK_ARES				18
+#define NSS_CC_PPE_EDMA_CFG_CLK_ARES				19
+#define NSS_CC_PPE_SWITCH_BTQ_CLK_ARES				20
+#define NSS_CC_PPE_SWITCH_CLK_ARES				21
+#define NSS_CC_PPE_SWITCH_CFG_CLK_ARES				22
+#define NSS_CC_PPE_SWITCH_IPE_CLK_ARES				23
+#define NSS_CC_UNIPHY_PORT1_RX_CLK_ARES				24
+#define NSS_CC_UNIPHY_PORT1_TX_CLK_ARES				25
+#define NSS_CC_UNIPHY_PORT2_RX_CLK_ARES				26
+#define NSS_CC_UNIPHY_PORT2_TX_CLK_ARES				27
+#define NSS_CC_XGMAC0_PTP_REF_CLK_ARES				28
+#define NSS_CC_XGMAC1_PTP_REF_CLK_ARES				29
+
+#endif

-- 
2.34.1



From quic_kathirav at quicinc.com  Sun Dec 10 19:37:29 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 09:07:29 +0530
Subject: [PATCH v3 7/8] arm64: dts: qcom: ipq5332: add support for the
 NSSCC
In-Reply-To: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
Message-ID: <20231211-ipq5332-nsscc-v3-7-ad13bef9b137@quicinc.com>

Describe the NSS clock controller node and it's relevant external
clocks.

Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
---
 arch/arm64/boot/dts/qcom/ipq5332.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
index 42e2e48b2bc3..a1504f6c40c1 100644
--- a/arch/arm64/boot/dts/qcom/ipq5332.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
@@ -15,6 +15,18 @@ / {
 	#size-cells = <2>;
 
 	clocks {
+		cmn_pll_nss_200m_clk: cmn-pll-nss-200m-clk {
+			compatible = "fixed-clock";
+			clock-frequency = <200000000>;
+			#clock-cells = <0>;
+		};
+
+		cmn_pll_nss_300m_clk: cmn-pll-nss-300m-clk {
+			compatible = "fixed-clock";
+			clock-frequency = <300000000>;
+			#clock-cells = <0>;
+		};
+
 		sleep_clk: sleep-clk {
 			compatible = "fixed-clock";
 			#clock-cells = <0>;
@@ -473,6 +485,22 @@ frame at b128000 {
 				status = "disabled";
 			};
 		};
+
+		nsscc: clock-controller at 39b00000{
+			compatible = "qcom,ipq5332-nsscc";
+			reg = <0x39b00000 0x80000>;
+			clocks = <&cmn_pll_nss_200m_clk>,
+				 <&cmn_pll_nss_300m_clk>,
+				 <&gcc GPLL0_OUT_AUX>,
+				 <0>,
+				 <0>,
+				 <0>,
+				 <0>,
+				 <&xo_board>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+			#power-domain-cells = <1>;
+		};
 	};
 
 	timer {

-- 
2.34.1



From quic_kathirav at quicinc.com  Sun Dec 10 19:37:28 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 09:07:28 +0530
Subject: [PATCH v3 6/8] clk: qcom: add NSS clock Controller driver for
 Qualcomm IPQ5332
In-Reply-To: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
Message-ID: <20231211-ipq5332-nsscc-v3-6-ad13bef9b137@quicinc.com>

Add Networking Sub System Clock Controller(NSSCC) driver for Qualcomm
IPQ5332 based devices.

Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
---
 drivers/clk/qcom/Kconfig         |    7 +
 drivers/clk/qcom/Makefile        |    1 +
 drivers/clk/qcom/nsscc-ipq5332.c | 1031 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 1039 insertions(+)

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index dbc3950c5960..caea43e96f7d 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -162,6 +162,13 @@ config IPQ_GCC_5332
 	  Say Y if you want to use peripheral devices such as UART, SPI,
 	  i2c, USB, SD/eMMC, etc.
 
+config IPQ_NSSCC_5332
+	tristate "IPQ5332 NSS Clock Controller"
+	depends on ARM64 || COMPILE_TEST
+	depends on IPQ_GCC_5332
+	help
+	  Support for NSS clock controller on ipq5332 devices.
+
 config IPQ_GCC_6018
 	tristate "IPQ6018 Global Clock Controller"
 	help
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 17edd73f9839..3aab744ecc99 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_IPQ_GCC_806X) += gcc-ipq806x.o
 obj-$(CONFIG_IPQ_GCC_8074) += gcc-ipq8074.o
 obj-$(CONFIG_IPQ_GCC_9574) += gcc-ipq9574.o
 obj-$(CONFIG_IPQ_LCC_806X) += lcc-ipq806x.o
+obj-$(CONFIG_IPQ_NSSCC_5332) += nsscc-ipq5332.o
 obj-$(CONFIG_MDM_GCC_9607) += gcc-mdm9607.o
 obj-$(CONFIG_MDM_GCC_9615) += gcc-mdm9615.o
 obj-$(CONFIG_MSM_GCC_8660) += gcc-msm8660.o
diff --git a/drivers/clk/qcom/nsscc-ipq5332.c b/drivers/clk/qcom/nsscc-ipq5332.c
new file mode 100644
index 000000000000..c4a73447b1fa
--- /dev/null
+++ b/drivers/clk/qcom/nsscc-ipq5332.c
@@ -0,0 +1,1031 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2022-2023, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/clock/qcom,ipq5332-nsscc.h>
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-regmap-mux.h"
+#include "common.h"
+#include "reset.h"
+
+enum {
+	DT_CMN_PLL_NSS_CLK_200M,
+	DT_CMN_PLL_NSS_CLK_300M,
+	DT_GCC_GPLL0_OUT_AUX,
+	DT_UNIPHY0_NSS_TX_CLK,
+	DT_UNIPHY0_NSS_RX_CLK,
+	DT_UNIPHY1_NSS_TX_CLK,
+	DT_UNIPHY1_NSS_RX_CLK,
+	DT_XO,
+};
+
+enum {
+	P_CMN_PLL_NSS_CLK_200M,
+	P_CMN_PLL_NSS_CLK_300M,
+	P_GCC_GPLL0_OUT_AUX,
+	P_UNIPHY0_NSS_TX_CLK,
+	P_UNIPHY0_NSS_RX_CLK,
+	P_UNIPHY1_NSS_TX_CLK,
+	P_UNIPHY1_NSS_RX_CLK,
+	P_XO,
+};
+
+static const struct parent_map nss_cc_parent_map_0[] = {
+	{ P_XO, 0 },
+	{ P_GCC_GPLL0_OUT_AUX, 2 },
+	{ P_CMN_PLL_NSS_CLK_300M, 5 },
+	{ P_CMN_PLL_NSS_CLK_200M, 6 },
+};
+
+static const struct clk_parent_data nss_cc_parent_data_0[] = {
+	{ .index = DT_XO },
+	{ .index = DT_GCC_GPLL0_OUT_AUX },
+	{ .index = DT_CMN_PLL_NSS_CLK_300M },
+	{ .index = DT_CMN_PLL_NSS_CLK_200M },
+};
+
+static const struct parent_map nss_cc_parent_map_1[] = {
+	{ P_XO, 0 },
+	{ P_GCC_GPLL0_OUT_AUX, 2 },
+	{ P_UNIPHY0_NSS_RX_CLK, 3 },
+	{ P_UNIPHY0_NSS_TX_CLK, 4 },
+	{ P_CMN_PLL_NSS_CLK_300M, 5 },
+	{ P_CMN_PLL_NSS_CLK_200M, 6 },
+};
+
+static const struct clk_parent_data nss_cc_parent_data_1[] = {
+	{ .index = DT_XO },
+	{ .index = DT_GCC_GPLL0_OUT_AUX },
+	{ .index = DT_UNIPHY0_NSS_RX_CLK },
+	{ .index = DT_UNIPHY0_NSS_TX_CLK },
+	{ .index = DT_CMN_PLL_NSS_CLK_300M },
+	{ .index = DT_CMN_PLL_NSS_CLK_200M },
+};
+
+static const struct parent_map nss_cc_parent_map_2[] = {
+	{ P_XO, 0 },
+	{ P_GCC_GPLL0_OUT_AUX, 2 },
+	{ P_UNIPHY1_NSS_RX_CLK, 3 },
+	{ P_UNIPHY1_NSS_TX_CLK, 4 },
+	{ P_CMN_PLL_NSS_CLK_300M, 5 },
+	{ P_CMN_PLL_NSS_CLK_200M, 6 },
+};
+
+static const struct clk_parent_data nss_cc_parent_data_2[] = {
+	{ .index = DT_XO },
+	{ .index = DT_GCC_GPLL0_OUT_AUX },
+	{ .index = DT_UNIPHY1_NSS_RX_CLK },
+	{ .index = DT_UNIPHY1_NSS_TX_CLK },
+	{ .index = DT_CMN_PLL_NSS_CLK_300M },
+	{ .index = DT_CMN_PLL_NSS_CLK_200M },
+};
+
+static const struct freq_tbl ftbl_nss_cc_ce_clk_src[] = {
+	F(24000000, P_XO, 1, 0, 0),
+	F(200000000, P_CMN_PLL_NSS_CLK_200M, 1, 0, 0),
+	{ }
+};
+
+static struct clk_rcg2 nss_cc_ce_clk_src = {
+	.cmd_rcgr = 0x518,
+	.mnd_width = 0,
+	.hid_width = 5,
+	.parent_map = nss_cc_parent_map_0,
+	.freq_tbl = ftbl_nss_cc_ce_clk_src,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_ce_clk_src",
+		.parent_data = nss_cc_parent_data_0,
+		.num_parents = ARRAY_SIZE(nss_cc_parent_data_0),
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_rcg2_ops,
+	},
+};
+
+static const struct freq_tbl ftbl_nss_cc_cfg_clk_src[] = {
+	F(100000000, P_GCC_GPLL0_OUT_AUX, 8, 0, 0),
+	{ }
+};
+
+static struct clk_rcg2 nss_cc_cfg_clk_src = {
+	.cmd_rcgr = 0x5e0,
+	.mnd_width = 0,
+	.hid_width = 5,
+	.parent_map = nss_cc_parent_map_0,
+	.freq_tbl = ftbl_nss_cc_cfg_clk_src,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_cfg_clk_src",
+		.parent_data = nss_cc_parent_data_0,
+		.num_parents = ARRAY_SIZE(nss_cc_parent_data_0),
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_rcg2_ops,
+	},
+};
+
+static const struct freq_tbl ftbl_nss_cc_eip_bfdcd_clk_src[] = {
+	F(300000000, P_CMN_PLL_NSS_CLK_300M, 1, 0, 0),
+	{ }
+};
+
+static struct clk_rcg2 nss_cc_eip_bfdcd_clk_src = {
+	.cmd_rcgr = 0x57c,
+	.mnd_width = 0,
+	.hid_width = 5,
+	.parent_map = nss_cc_parent_map_0,
+	.freq_tbl = ftbl_nss_cc_eip_bfdcd_clk_src,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_eip_bfdcd_clk_src",
+		.parent_data = nss_cc_parent_data_0,
+		.num_parents = ARRAY_SIZE(nss_cc_parent_data_0),
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_rcg2_ops,
+	},
+};
+
+static const struct freq_conf ftbl_nss_cc_port1_rx_clk_src_25[] = {
+	C(P_UNIPHY0_NSS_RX_CLK, 12.5, 0, 0),
+	C(P_UNIPHY0_NSS_RX_CLK, 5, 0, 0),
+};
+
+static const struct freq_conf ftbl_nss_cc_port1_rx_clk_src_125[] = {
+	C(P_UNIPHY0_NSS_RX_CLK, 2.5, 0, 0),
+	C(P_UNIPHY0_NSS_RX_CLK, 1, 0, 0),
+};
+
+static const struct freq_multi_tbl ftbl_nss_cc_port1_rx_clk_src[] = {
+	FMS(24000000, P_XO, 1, 0, 0),
+	FM(25000000, ftbl_nss_cc_port1_rx_clk_src_25),
+	FMS(78125000, P_UNIPHY0_NSS_RX_CLK, 4, 0, 0),
+	FM(125000000, ftbl_nss_cc_port1_rx_clk_src_125),
+	FMS(156250000, P_UNIPHY0_NSS_RX_CLK, 2, 0, 0),
+	FMS(312500000, P_UNIPHY0_NSS_RX_CLK, 1, 0, 0),
+	{ }
+};
+
+static struct clk_rcg2 nss_cc_port1_rx_clk_src = {
+	.cmd_rcgr = 0x450,
+	.mnd_width = 0,
+	.hid_width = 5,
+	.parent_map = nss_cc_parent_map_1,
+	.freq_multi_tbl = ftbl_nss_cc_port1_rx_clk_src,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_port1_rx_clk_src",
+		.parent_data = nss_cc_parent_data_1,
+		.num_parents = ARRAY_SIZE(nss_cc_parent_data_1),
+		.ops = &clk_rcg2_fm_ops,
+	},
+};
+
+static const struct freq_conf ftbl_nss_cc_port1_tx_clk_src_25[] = {
+	C(P_UNIPHY0_NSS_TX_CLK, 12.5, 0, 0),
+	C(P_UNIPHY0_NSS_TX_CLK, 5, 0, 0),
+};
+
+static const struct freq_conf ftbl_nss_cc_port1_tx_clk_src_125[] = {
+	C(P_UNIPHY0_NSS_TX_CLK, 2.5, 0, 0),
+	C(P_UNIPHY0_NSS_TX_CLK, 1, 0, 0),
+};
+
+static const struct freq_multi_tbl ftbl_nss_cc_port1_tx_clk_src[] = {
+	FMS(24000000, P_XO, 1, 0, 0),
+	FM(25000000, ftbl_nss_cc_port1_tx_clk_src_25),
+	FMS(78125000, P_UNIPHY0_NSS_TX_CLK, 4, 0, 0),
+	FM(125000000, ftbl_nss_cc_port1_tx_clk_src_125),
+	FMS(156250000, P_UNIPHY0_NSS_TX_CLK, 2, 0, 0),
+	FMS(312500000, P_UNIPHY0_NSS_TX_CLK, 1, 0, 0),
+	{ }
+};
+
+static struct clk_rcg2 nss_cc_port1_tx_clk_src = {
+	.cmd_rcgr = 0x45c,
+	.mnd_width = 0,
+	.hid_width = 5,
+	.parent_map = nss_cc_parent_map_1,
+	.freq_multi_tbl = ftbl_nss_cc_port1_tx_clk_src,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_port1_tx_clk_src",
+		.parent_data = nss_cc_parent_data_1,
+		.num_parents = ARRAY_SIZE(nss_cc_parent_data_1),
+		.ops = &clk_rcg2_fm_ops,
+	},
+};
+
+static const struct freq_conf ftbl_nss_cc_port2_rx_clk_src_25[] = {
+	C(P_UNIPHY1_NSS_RX_CLK, 12.5, 0, 0),
+	C(P_UNIPHY1_NSS_RX_CLK, 5, 0, 0),
+};
+
+static const struct freq_conf ftbl_nss_cc_port2_rx_clk_src_125[] = {
+	C(P_UNIPHY1_NSS_RX_CLK, 2.5, 0, 0),
+	C(P_UNIPHY1_NSS_RX_CLK, 1, 0, 0),
+};
+
+static const struct freq_multi_tbl ftbl_nss_cc_port2_rx_clk_src[] = {
+	FMS(24000000, P_XO, 1, 0, 0),
+	FM(25000000, ftbl_nss_cc_port2_rx_clk_src_25),
+	FMS(78125000, P_UNIPHY1_NSS_RX_CLK, 4, 0, 0),
+	FM(125000000, ftbl_nss_cc_port2_rx_clk_src_125),
+	FMS(156250000, P_UNIPHY1_NSS_RX_CLK, 2, 0, 0),
+	FMS(312500000, P_UNIPHY1_NSS_RX_CLK, 1, 0, 0),
+	{ }
+};
+
+static struct clk_rcg2 nss_cc_port2_rx_clk_src = {
+	.cmd_rcgr = 0x468,
+	.mnd_width = 0,
+	.hid_width = 5,
+	.parent_map = nss_cc_parent_map_2,
+	.freq_multi_tbl = ftbl_nss_cc_port2_rx_clk_src,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_port2_rx_clk_src",
+		.parent_data = nss_cc_parent_data_2,
+		.num_parents = ARRAY_SIZE(nss_cc_parent_data_2),
+		.ops = &clk_rcg2_fm_ops,
+	},
+};
+
+static const struct freq_conf ftbl_nss_cc_port2_tx_clk_src_25[] = {
+	C(P_UNIPHY1_NSS_TX_CLK, 12.5, 0, 0),
+	C(P_UNIPHY1_NSS_TX_CLK, 5, 0, 0),
+};
+
+static const struct freq_conf ftbl_nss_cc_port2_tx_clk_src_125[] = {
+	C(P_UNIPHY1_NSS_TX_CLK, 2.5, 0, 0),
+	C(P_UNIPHY1_NSS_TX_CLK, 1, 0, 0),
+};
+
+static const struct freq_multi_tbl ftbl_nss_cc_port2_tx_clk_src[] = {
+	FMS(24000000, P_XO, 1, 0, 0),
+	FM(25000000, ftbl_nss_cc_port2_tx_clk_src_25),
+	FMS(78125000, P_UNIPHY1_NSS_TX_CLK, 4, 0, 0),
+	FM(125000000, ftbl_nss_cc_port2_tx_clk_src_125),
+	FMS(156250000, P_UNIPHY1_NSS_TX_CLK, 2, 0, 0),
+	FMS(312500000, P_UNIPHY1_NSS_TX_CLK, 1, 0, 0),
+	{ }
+};
+
+static struct clk_rcg2 nss_cc_port2_tx_clk_src = {
+	.cmd_rcgr = 0x474,
+	.mnd_width = 0,
+	.hid_width = 5,
+	.parent_map = nss_cc_parent_map_2,
+	.freq_multi_tbl = ftbl_nss_cc_port2_tx_clk_src,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_port2_tx_clk_src",
+		.parent_data = nss_cc_parent_data_2,
+		.num_parents = ARRAY_SIZE(nss_cc_parent_data_2),
+		.ops = &clk_rcg2_fm_ops,
+	},
+};
+
+static struct clk_rcg2 nss_cc_ppe_clk_src = {
+	.cmd_rcgr = 0x3e8,
+	.mnd_width = 0,
+	.hid_width = 5,
+	.parent_map = nss_cc_parent_map_0,
+	.freq_tbl = ftbl_nss_cc_ce_clk_src,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_ppe_clk_src",
+		.parent_data = nss_cc_parent_data_0,
+		.num_parents = ARRAY_SIZE(nss_cc_parent_data_0),
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_rcg2_ops,
+	},
+};
+
+static struct clk_regmap_div nss_cc_port1_rx_div_clk_src = {
+	.reg = 0x458,
+	.shift = 0,
+	.width = 4,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_port1_rx_div_clk_src",
+		.parent_hws = (const struct clk_hw*[]) {
+			&nss_cc_port1_rx_clk_src.clkr.hw,
+		},
+		.num_parents = 1,
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_regmap_div_ops,
+	},
+};
+
+static struct clk_regmap_div nss_cc_port1_tx_div_clk_src = {
+	.reg = 0x464,
+	.shift = 0,
+	.width = 4,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_port1_tx_div_clk_src",
+		.parent_hws = (const struct clk_hw*[]) {
+			&nss_cc_port1_tx_clk_src.clkr.hw,
+		},
+		.num_parents = 1,
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_regmap_div_ops,
+	},
+};
+
+static struct clk_regmap_div nss_cc_port2_rx_div_clk_src = {
+	.reg = 0x470,
+	.shift = 0,
+	.width = 4,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_port2_rx_div_clk_src",
+		.parent_hws = (const struct clk_hw*[]) {
+			&nss_cc_port2_rx_clk_src.clkr.hw,
+		},
+		.num_parents = 1,
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_regmap_div_ops,
+	},
+};
+
+static struct clk_regmap_div nss_cc_port2_tx_div_clk_src = {
+	.reg = 0x47c,
+	.shift = 0,
+	.width = 4,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_port2_tx_div_clk_src",
+		.parent_hws = (const struct clk_hw*[]) {
+			&nss_cc_port2_tx_clk_src.clkr.hw,
+		},
+		.num_parents = 1,
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_regmap_div_ops,
+	},
+};
+
+static struct clk_regmap_div nss_cc_xgmac0_ptp_ref_div_clk_src = {
+	.reg = 0x3f0,
+	.shift = 0,
+	.width = 4,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_xgmac0_ptp_ref_div_clk_src",
+		.parent_hws = (const struct clk_hw*[]) {
+			&nss_cc_ppe_clk_src.clkr.hw,
+		},
+		.num_parents = 1,
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_regmap_div_ro_ops,
+	},
+};
+
+static struct clk_regmap_div nss_cc_xgmac1_ptp_ref_div_clk_src = {
+	.reg = 0x3f4,
+	.shift = 0,
+	.width = 4,
+	.clkr.hw.init = &(const struct clk_init_data) {
+		.name = "nss_cc_xgmac1_ptp_ref_div_clk_src",
+		.parent_hws = (const struct clk_hw*[]) {
+			&nss_cc_ppe_clk_src.clkr.hw,
+		},
+		.num_parents = 1,
+		.flags = CLK_SET_RATE_PARENT,
+		.ops = &clk_regmap_div_ro_ops,
+	},
+};
+
+static struct clk_branch nss_cc_ce_apb_clk = {
+	.halt_reg = 0x520,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x520,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_ce_apb_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ce_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_ce_axi_clk = {
+	.halt_reg = 0x524,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x524,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_ce_axi_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ce_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_debug_clk = {
+	.halt_reg = 0x644,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x644,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_debug_clk",
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_eip_clk = {
+	.halt_reg = 0x590,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x590,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_eip_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_eip_bfdcd_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_nss_csr_clk = {
+	.halt_reg = 0x5e8,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x5e8,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_nss_csr_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_cfg_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_nssnoc_ce_apb_clk = {
+	.halt_reg = 0x52c,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x52c,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_nssnoc_ce_apb_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ce_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_nssnoc_ce_axi_clk = {
+	.halt_reg = 0x530,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x530,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_nssnoc_ce_axi_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ce_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_nssnoc_eip_clk = {
+	.halt_reg = 0x598,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x598,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_nssnoc_eip_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_eip_bfdcd_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_nssnoc_nss_csr_clk = {
+	.halt_reg = 0x5ec,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x5ec,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_nssnoc_nss_csr_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_cfg_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_nssnoc_ppe_cfg_clk = {
+	.halt_reg = 0x424,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x424,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_nssnoc_ppe_cfg_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_nssnoc_ppe_clk = {
+	.halt_reg = 0x420,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x420,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_nssnoc_ppe_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_port1_mac_clk = {
+	.halt_reg = 0x428,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x428,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_port1_mac_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_port1_rx_clk = {
+	.halt_reg = 0x480,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x480,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_port1_rx_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_port1_rx_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_port1_tx_clk = {
+	.halt_reg = 0x488,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x488,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_port1_tx_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_port1_tx_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_port2_mac_clk = {
+	.halt_reg = 0x430,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x430,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_port2_mac_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_port2_rx_clk = {
+	.halt_reg = 0x490,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x490,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_port2_rx_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_port2_rx_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_port2_tx_clk = {
+	.halt_reg = 0x498,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x498,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_port2_tx_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_port2_tx_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_ppe_edma_cfg_clk = {
+	.halt_reg = 0x41c,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x41c,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_ppe_edma_cfg_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_ppe_edma_clk = {
+	.halt_reg = 0x414,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x414,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_ppe_edma_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_ppe_switch_btq_clk = {
+	.halt_reg = 0x400,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x400,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_ppe_switch_btq_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_ppe_switch_cfg_clk = {
+	.halt_reg = 0x410,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x410,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_ppe_switch_cfg_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_ppe_switch_clk = {
+	.halt_reg = 0x408,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x408,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_ppe_switch_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_ppe_switch_ipe_clk = {
+	.halt_reg = 0x3f8,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x3f8,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_ppe_switch_ipe_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_ppe_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_uniphy_port1_rx_clk = {
+	.halt_reg = 0x4b4,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x4b4,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_uniphy_port1_rx_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_port1_rx_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_uniphy_port1_tx_clk = {
+	.halt_reg = 0x4b8,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x4b8,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_uniphy_port1_tx_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_port1_tx_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_uniphy_port2_rx_clk = {
+	.halt_reg = 0x4bc,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x4bc,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_uniphy_port2_rx_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_port2_rx_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_uniphy_port2_tx_clk = {
+	.halt_reg = 0x4c0,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x4c0,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_uniphy_port2_tx_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_port2_tx_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_xgmac0_ptp_ref_clk = {
+	.halt_reg = 0x438,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x438,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_xgmac0_ptp_ref_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_xgmac0_ptp_ref_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_branch nss_cc_xgmac1_ptp_ref_clk = {
+	.halt_reg = 0x43c,
+	.halt_check = BRANCH_HALT,
+	.clkr = {
+		.enable_reg = 0x43c,
+		.enable_mask = BIT(0),
+		.hw.init = &(const struct clk_init_data) {
+			.name = "nss_cc_xgmac1_ptp_ref_clk",
+			.parent_hws = (const struct clk_hw*[]) {
+				&nss_cc_xgmac1_ptp_ref_div_clk_src.clkr.hw,
+			},
+			.num_parents = 1,
+			.flags = CLK_SET_RATE_PARENT,
+			.ops = &clk_branch2_ops,
+		},
+	},
+};
+
+static struct clk_regmap *nss_cc_ipq5332_clocks[] = {
+	[NSS_CC_CE_APB_CLK] = &nss_cc_ce_apb_clk.clkr,
+	[NSS_CC_CE_AXI_CLK] = &nss_cc_ce_axi_clk.clkr,
+	[NSS_CC_CE_CLK_SRC] = &nss_cc_ce_clk_src.clkr,
+	[NSS_CC_CFG_CLK_SRC] = &nss_cc_cfg_clk_src.clkr,
+	[NSS_CC_DEBUG_CLK] = &nss_cc_debug_clk.clkr,
+	[NSS_CC_EIP_BFDCD_CLK_SRC] = &nss_cc_eip_bfdcd_clk_src.clkr,
+	[NSS_CC_EIP_CLK] = &nss_cc_eip_clk.clkr,
+	[NSS_CC_NSS_CSR_CLK] = &nss_cc_nss_csr_clk.clkr,
+	[NSS_CC_NSSNOC_CE_APB_CLK] = &nss_cc_nssnoc_ce_apb_clk.clkr,
+	[NSS_CC_NSSNOC_CE_AXI_CLK] = &nss_cc_nssnoc_ce_axi_clk.clkr,
+	[NSS_CC_NSSNOC_EIP_CLK] = &nss_cc_nssnoc_eip_clk.clkr,
+	[NSS_CC_NSSNOC_NSS_CSR_CLK] = &nss_cc_nssnoc_nss_csr_clk.clkr,
+	[NSS_CC_NSSNOC_PPE_CFG_CLK] = &nss_cc_nssnoc_ppe_cfg_clk.clkr,
+	[NSS_CC_NSSNOC_PPE_CLK] = &nss_cc_nssnoc_ppe_clk.clkr,
+	[NSS_CC_PORT1_MAC_CLK] = &nss_cc_port1_mac_clk.clkr,
+	[NSS_CC_PORT1_RX_CLK] = &nss_cc_port1_rx_clk.clkr,
+	[NSS_CC_PORT1_RX_CLK_SRC] = &nss_cc_port1_rx_clk_src.clkr,
+	[NSS_CC_PORT1_RX_DIV_CLK_SRC] = &nss_cc_port1_rx_div_clk_src.clkr,
+	[NSS_CC_PORT1_TX_CLK] = &nss_cc_port1_tx_clk.clkr,
+	[NSS_CC_PORT1_TX_CLK_SRC] = &nss_cc_port1_tx_clk_src.clkr,
+	[NSS_CC_PORT1_TX_DIV_CLK_SRC] = &nss_cc_port1_tx_div_clk_src.clkr,
+	[NSS_CC_PORT2_MAC_CLK] = &nss_cc_port2_mac_clk.clkr,
+	[NSS_CC_PORT2_RX_CLK] = &nss_cc_port2_rx_clk.clkr,
+	[NSS_CC_PORT2_RX_CLK_SRC] = &nss_cc_port2_rx_clk_src.clkr,
+	[NSS_CC_PORT2_RX_DIV_CLK_SRC] = &nss_cc_port2_rx_div_clk_src.clkr,
+	[NSS_CC_PORT2_TX_CLK] = &nss_cc_port2_tx_clk.clkr,
+	[NSS_CC_PORT2_TX_CLK_SRC] = &nss_cc_port2_tx_clk_src.clkr,
+	[NSS_CC_PORT2_TX_DIV_CLK_SRC] = &nss_cc_port2_tx_div_clk_src.clkr,
+	[NSS_CC_PPE_CLK_SRC] = &nss_cc_ppe_clk_src.clkr,
+	[NSS_CC_PPE_EDMA_CFG_CLK] = &nss_cc_ppe_edma_cfg_clk.clkr,
+	[NSS_CC_PPE_EDMA_CLK] = &nss_cc_ppe_edma_clk.clkr,
+	[NSS_CC_PPE_SWITCH_BTQ_CLK] = &nss_cc_ppe_switch_btq_clk.clkr,
+	[NSS_CC_PPE_SWITCH_CFG_CLK] = &nss_cc_ppe_switch_cfg_clk.clkr,
+	[NSS_CC_PPE_SWITCH_CLK] = &nss_cc_ppe_switch_clk.clkr,
+	[NSS_CC_PPE_SWITCH_IPE_CLK] = &nss_cc_ppe_switch_ipe_clk.clkr,
+	[NSS_CC_UNIPHY_PORT1_RX_CLK] = &nss_cc_uniphy_port1_rx_clk.clkr,
+	[NSS_CC_UNIPHY_PORT1_TX_CLK] = &nss_cc_uniphy_port1_tx_clk.clkr,
+	[NSS_CC_UNIPHY_PORT2_RX_CLK] = &nss_cc_uniphy_port2_rx_clk.clkr,
+	[NSS_CC_UNIPHY_PORT2_TX_CLK] = &nss_cc_uniphy_port2_tx_clk.clkr,
+	[NSS_CC_XGMAC0_PTP_REF_CLK] = &nss_cc_xgmac0_ptp_ref_clk.clkr,
+	[NSS_CC_XGMAC0_PTP_REF_DIV_CLK_SRC] = &nss_cc_xgmac0_ptp_ref_div_clk_src.clkr,
+	[NSS_CC_XGMAC1_PTP_REF_CLK] = &nss_cc_xgmac1_ptp_ref_clk.clkr,
+	[NSS_CC_XGMAC1_PTP_REF_DIV_CLK_SRC] = &nss_cc_xgmac1_ptp_ref_div_clk_src.clkr,
+};
+
+static const struct qcom_reset_map nss_cc_ipq5332_resets[] = {
+	[NSS_CC_CE_APB_CLK_ARES] = { 0x520, 2 },
+	[NSS_CC_CE_AXI_CLK_ARES] = { 0x524, 2 },
+	[NSS_CC_DEBUG_CLK_ARES] = { 0x644, 2 },
+	[NSS_CC_EIP_CLK_ARES] = { 0x590, 2 },
+	[NSS_CC_NSS_CSR_CLK_ARES] = { 0x5e8, 2 },
+	[NSS_CC_NSSNOC_CE_APB_CLK_ARES] = { 0x52c, 2 },
+	[NSS_CC_NSSNOC_CE_AXI_CLK_ARES] = { 0x530, 2 },
+	[NSS_CC_NSSNOC_EIP_CLK_ARES] = { 0x598, 2 },
+	[NSS_CC_NSSNOC_NSS_CSR_CLK_ARES] = { 0x5ec, 2 },
+	[NSS_CC_NSSNOC_PPE_CLK_ARES] = { 0x420, 2 },
+	[NSS_CC_NSSNOC_PPE_CFG_CLK_ARES] = { 0x424, 2 },
+	[NSS_CC_PORT1_MAC_CLK_ARES] = { 0x428, 2 },
+	[NSS_CC_PORT1_RX_CLK_ARES] = { 0x480, 2 },
+	[NSS_CC_PORT1_TX_CLK_ARES] = { 0x488, 2 },
+	[NSS_CC_PORT2_MAC_CLK_ARES] = { 0x430, 2 },
+	[NSS_CC_PORT2_RX_CLK_ARES] = { 0x490, 2 },
+	[NSS_CC_PORT2_TX_CLK_ARES] = { 0x498, 2 },
+	[NSS_CC_PPE_BCR] = { 0x3e4 },
+	[NSS_CC_PPE_EDMA_CLK_ARES] = { 0x414, 2 },
+	[NSS_CC_PPE_EDMA_CFG_CLK_ARES] = { 0x41c, 2 },
+	[NSS_CC_PPE_SWITCH_BTQ_CLK_ARES] = { 0x400, 2 },
+	[NSS_CC_PPE_SWITCH_CLK_ARES] = { 0x408, 2 },
+	[NSS_CC_PPE_SWITCH_CFG_CLK_ARES] = { 0x410, 2 },
+	[NSS_CC_PPE_SWITCH_IPE_CLK_ARES] = { 0x3f8, 2 },
+	[NSS_CC_UNIPHY_PORT1_RX_CLK_ARES] = { 0x4b4, 2 },
+	[NSS_CC_UNIPHY_PORT1_TX_CLK_ARES] = { 0x4b8, 2 },
+	[NSS_CC_UNIPHY_PORT2_RX_CLK_ARES] = { 0x4bc, 2 },
+	[NSS_CC_UNIPHY_PORT2_TX_CLK_ARES] = { 0x4c0, 2 },
+	[NSS_CC_XGMAC0_PTP_REF_CLK_ARES] = { 0x438, 2 },
+	[NSS_CC_XGMAC1_PTP_REF_CLK_ARES] = { 0x43c, 2 },
+};
+
+static const struct regmap_config nss_cc_ipq5332_regmap_config = {
+	.reg_bits = 32,
+	.reg_stride = 4,
+	.val_bits = 32,
+	.max_register = 0x800,
+	.fast_io = true,
+};
+
+static const struct qcom_cc_desc nss_cc_ipq5332_desc = {
+	.config = &nss_cc_ipq5332_regmap_config,
+	.clks = nss_cc_ipq5332_clocks,
+	.num_clks = ARRAY_SIZE(nss_cc_ipq5332_clocks),
+	.resets = nss_cc_ipq5332_resets,
+	.num_resets = ARRAY_SIZE(nss_cc_ipq5332_resets),
+};
+
+static const struct of_device_id nss_cc_ipq5332_match_table[] = {
+	{ .compatible = "qcom,ipq5332-nsscc" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, nss_cc_ipq5332_match_table);
+
+static int nss_cc_ipq5332_probe(struct platform_device *pdev)
+{
+	return qcom_cc_probe(pdev, &nss_cc_ipq5332_desc);
+}
+
+static struct platform_driver nss_cc_ipq5332_driver = {
+	.probe = nss_cc_ipq5332_probe,
+	.driver = {
+		.name = "qcom,ipq5332-nsscc",
+		.of_match_table = nss_cc_ipq5332_match_table,
+	},
+};
+module_platform_driver(nss_cc_ipq5332_driver);
+
+MODULE_DESCRIPTION("QTI NSSCC IPQ5332 Driver");
+MODULE_LICENSE("GPL");

-- 
2.34.1



From quic_kathirav at quicinc.com  Sun Dec 10 19:37:30 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 09:07:30 +0530
Subject: [PATCH v3 8/8] arm64: defconfig: build NSS Clock Controller driver
 for Qualcomm IPQ5332
In-Reply-To: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
Message-ID: <20231211-ipq5332-nsscc-v3-8-ad13bef9b137@quicinc.com>

NSSCC driver is needed to enable the ethernet interfaces and not
necessary for the bootup of the SoC, hence build it as a module.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index be89fa9e6468..a12182cc8cc9 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1229,6 +1229,7 @@ CONFIG_QCOM_CLK_SMD_RPM=y
 CONFIG_QCOM_CLK_RPMH=y
 CONFIG_IPQ_APSS_6018=y
 CONFIG_IPQ_GCC_5332=y
+CONFIG_IPQ_NSSCC_5332=m
 CONFIG_IPQ_APSS_5018=y
 CONFIG_IPQ_GCC_5018=y
 CONFIG_IPQ_GCC_6018=y

-- 
2.34.1



From tudor.ambarus at linaro.org  Sun Dec 10 19:44:18 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Mon, 11 Dec 2023 03:44:18 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <BN7PR12MB2802C8279CA95FA08F8DDCF2DC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <9f577482-30d9-4e1d-9469-812d323b18c6@linaro.org>
 <BN7PR12MB2802C8279CA95FA08F8DDCF2DC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
Message-ID: <2cadfffa-00bf-4e6a-bfce-9cc654b042a1@linaro.org>



On 12/8/23 17:06, Mahapatra, Amit Kumar wrote:
> Hello Tudor,

Hi!

> 
>> -----Original Message-----
>> From: Tudor Ambarus <tudor.ambarus at linaro.org>
>> Sent: Wednesday, December 6, 2023 8:14 PM
>> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
>> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
>> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
>> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
>> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
>> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
>> michael at walle.cc; linux-mtd at lists.infradead.org;
>> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
>> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
>> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
>> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
>> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
>> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
>> in spi-nor
>>
>>
>>
>> On 12/6/23 14:30, Tudor Ambarus wrote:
>>> Hi, Amit,
>>>
>>> On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
>>>> Each flash that is connected in stacked mode should have a separate
>>>> parameter structure. So, the flash parameter member(*params) of the
>>>> spi_nor structure is changed to an array (*params[2]). The array is
>>>> used to store the parameters of each flash connected in stacked
>> configuration.
>>>>
>>>> The current implementation assumes that a maximum of two flashes are
>>>> connected in stacked mode and both the flashes are of same make but
>>>> can differ in sizes. So, except the sizes all other flash parameters
>>>> of both the flashes are identical.
>>>
>>> Do you plan to add support for different flashes in stacked mode? If
>>> not, wouldn't it be simpler to have just an array of flash sizes
>>> instead of duplicating the entire params struct?
>>>
>>>>
>>>> SPI-NOR is not aware of the chip_select values, for any incoming
>>>> request SPI-NOR will decide the flash index with the help of
>>>> individual flash size and the configuration type (single/stacked).
>>>> SPI-NOR will pass on the flash index information to the SPI core &
>>>> SPI driver by setting the appropriate bit in
>>>> nor->spimem->spi->cs_index_mask. For example, if nth bit of
>>>> nor->spimem->spi->cs_index_mask is set then the driver would
>>>> assert/de-assert spi->chip_slect[n].
>>>>
>>>> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
>> mahapatra at amd.com>
>>>> ---
>>>>  drivers/mtd/spi-nor/core.c  | 272 +++++++++++++++++++++++++++++-------
>>>>  drivers/mtd/spi-nor/core.h  |   4 +
>>>>  include/linux/mtd/spi-nor.h |  15 +-
>>>>  3 files changed, 240 insertions(+), 51 deletions(-)
>>>>
>>>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>>>> index 93ae69b7ff83..e990be7c7eb6 100644
>>>> --- a/drivers/mtd/spi-nor/core.c
>>>> +++ b/drivers/mtd/spi-nor/core.c
>>>
>>> cut
>>>
>>>> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct
>>>> spi_nor *nor)  static int spi_nor_late_init_params(struct spi_nor
>>>> *nor)  {
>>>>  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
>> 0);
>>>> -	int ret;
>>>> +	struct device_node *np = spi_nor_get_flash_node(nor);
>>>> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
>>>> +	u32 idx = 0;
>>>> +	int rc, ret;
>>>>
>>>>  	if (nor->manufacturer && nor->manufacturer->fixups &&
>>>>  	    nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
>>>> static int spi_nor_late_init_params(struct spi_nor *nor)
>>>>  	if (params->n_banks > 1)
>>>>  		params->bank_size = div64_u64(params->size, params-
>>> n_banks);
>>>>
>>>> +	nor->num_flash = 0;
>>>> +
>>>> +	/*
>>>> +	 * The flashes that are connected in stacked mode should be of same
>> make.
>>>> +	 * Except the flash size all other properties are identical for all the
>>>> +	 * flashes connected in stacked mode.
>>>> +	 * The flashes that are connected in parallel mode should be identical.
>>>> +	 */
>>>> +	while (idx < SNOR_FLASH_CNT_MAX) {
>>>> +		rc = of_property_read_u64_index(np, "stacked-memories",
>> idx,
>>>> +&flash_size[idx]);
>>
>> also, it's not clear to me why you read this property multiple times.
>> Have you sent a device tree patch somewhere? It will help me understand
>> what you're trying to achieve.
> 
> Miquel submitted the device tree patch; here is the series.
> https://lore.kernel.org/all/20220126112608.955728-1-miquel.raynal at bootlin.com/
> 

oh, yes, I remember seeing this on the ml, but I couldn't allocate time
to review it. Looking at:
https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal at bootlin.com/

Flash size is not necessary for SPI NORs, as it can be discovered via
SFDP. And spi-max-frequency should have been specified for all flashes,
as I expect it can differ. At least so that the controller chooses the
minimum frequency from all the max (if it can't operate the stacks at
different frequencies).

Cheers,
ta


From quan at os.amperecomputing.com  Sun Dec 10 20:06:12 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Mon, 11 Dec 2023 11:06:12 +0700
Subject: [PATCH v3 2/2] i2c: aspeed: Acknowledge Tx done with and without
 ACK irq late
In-Reply-To: <dc36d61aedd2b2389eb366b27436f19d934fc93b.camel@codeconstruct.com.au>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
 <20231208033142.1673232-3-quan@os.amperecomputing.com>
 <dc36d61aedd2b2389eb366b27436f19d934fc93b.camel@codeconstruct.com.au>
Message-ID: <79d8377f-b443-47cd-831c-4f27a4f59572@os.amperecomputing.com>



On 08/12/2023 11:00, Andrew Jeffery wrote:
> On Fri, 2023-12-08 at 10:31 +0700, Quan Nguyen wrote:
>> Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
>> interrupt handler") acknowledges most interrupts early before the slave
>> irq handler is executed, except for the "Receive Done Interrupt status"
>> which is acknowledged late in the interrupt.
>> However, it has been observed that the early acknowledgment of "Transmit
>> Done Interrupt Status" (with ACK or NACK) often causes the interrupt to
>> be raised in READ REQUEST state, that shows the
>> "Unexpected ACK on read request." complaint messages.
>>
>> Assuming that the "Transmit Done" interrupt should only be acknowledged
>> once it is truly processed, this commit fixes that issue by acknowledging
>> interrupts for both ACK and NACK cases late in the interrupt handler.
>>
>> Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
>> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
>> ---
>> v3:
>>    + Fix the unconditinal write when ack the irqs               [Andrew]
>>    + Refactor the code to enhance code readability                [Quan]
>>    + Fix grammar in commit message                                [Quan]
>>
>> v2:
>>    + Split to separate series                                     [Joel]
>>    + Added the Fixes line                                         [Joel]
>>    + Fixed multiline comment                                      [Joel]
>>    + Refactor irq clearing code                          [Joel, Guenter]
>>    + Revised commit message                                       [Joel]
>>    + Revised commit message                                       [Quan]
>>    + About a note to remind why the readl() should immediately follow the
>> writel() to fix the race condition when clearing irq status from commit
>> c926c87b8e36 ("i2c: aspeed: Avoid i2c interrupt status clear race
>> condition"), I think it looks straight forward in this patch and decided
>> not to add that note.                                            [Joel]
>>
>> v1:
>>    + First introduced in
>> https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/
>> ---
>>   drivers/i2c/busses/i2c-aspeed.c | 21 +++++++++++++--------
>>   1 file changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
>> index 1c2a4f4c4e1b..967a26dd4ffa 100644
>> --- a/drivers/i2c/busses/i2c-aspeed.c
>> +++ b/drivers/i2c/busses/i2c-aspeed.c
>> @@ -617,13 +617,19 @@ static u32 aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
>>   static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
>>   {
>>   	struct aspeed_i2c_bus *bus = dev_id;
>> -	u32 irq_received, irq_remaining, irq_handled;
>> +	u32 irq_received, irq_remaining, irq_handled, irq_ack_last;
> 
> `irq_ack_last` might be better as a macro, but you're probably saved by
> the optimiser anyway. If there's another reason to do a v4 or others
> are unhappy with it then consider fixing it, otherwise:
> 
> Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>
> 

I'll send out the v4 to use the defined macro instead as below:

Thanks Andi, for the suggestion on the macro name.

diff --git a/drivers/i2c/busses/i2c-aspeed.c 
b/drivers/i2c/busses/i2c-aspeed.c
index 5511fd46a65e..0f67218cf04a 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -93,6 +93,10 @@
  		 ASPEED_I2CD_INTR_RX_DONE | \
  		 ASPEED_I2CD_INTR_TX_NAK |  \
  		 ASPEED_I2CD_INTR_TX_ACK)
+#define ASPEED_I2CD_INTR_ACK_RX_TX	    \
+		(ASPEED_I2CD_INTR_RX_DONE | \
+		 ASPEED_I2CD_INTR_TX_ACK |  \
+		 ASPEED_I2CD_INTR_TX_NAK)

Thanks for the review,
- Quan


From quan at os.amperecomputing.com  Sun Dec 10 20:06:27 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Mon, 11 Dec 2023 11:06:27 +0700
Subject: [PATCH v3 2/2] i2c: aspeed: Acknowledge Tx done with and without
 ACK irq late
In-Reply-To: <20231208033142.1673232-3-quan@os.amperecomputing.com>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
 <20231208033142.1673232-3-quan@os.amperecomputing.com>
Message-ID: <c868594e-834f-462d-ade0-94c6b133cfbd@os.amperecomputing.com>



On 08/12/2023 10:31, Quan Nguyen wrote:
> Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
> interrupt handler") acknowledges most interrupts early before the slave
> irq handler is executed, except for the "Receive Done Interrupt status"
> which is acknowledged late in the interrupt.
> However, it has been observed that the early acknowledgment of "Transmit
> Done Interrupt Status" (with ACK or NACK) often causes the interrupt to
> be raised in READ REQUEST state, that shows the
> "Unexpected ACK on read request." complaint messages.
> 
> Assuming that the "Transmit Done" interrupt should only be acknowledged
> once it is truly processed, this commit fixes that issue by acknowledging
> interrupts for both ACK and NACK cases late in the interrupt handler.
> 
> Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> ---
> v3:
>    + Fix the unconditinal write when ack the irqs               [Andrew]
>    + Refactor the code to enhance code readability                [Quan]
>    + Fix grammar in commit message                                [Quan]
> 
> v2:
>    + Split to separate series                                     [Joel]
>    + Added the Fixes line                                         [Joel]
>    + Fixed multiline comment                                      [Joel]
>    + Refactor irq clearing code                          [Joel, Guenter]
>    + Revised commit message                                       [Joel]
>    + Revised commit message                                       [Quan]
>    + About a note to remind why the readl() should immediately follow the
> writel() to fix the race condition when clearing irq status from commit
> c926c87b8e36 ("i2c: aspeed: Avoid i2c interrupt status clear race
> condition"), I think it looks straight forward in this patch and decided
> not to add that note.                                            [Joel]
> 
> v1:
>    + First introduced in
> https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/
> ---
>   drivers/i2c/busses/i2c-aspeed.c | 21 +++++++++++++--------
>   1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index 1c2a4f4c4e1b..967a26dd4ffa 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -617,13 +617,19 @@ static u32 aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
>   static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
>   {
>   	struct aspeed_i2c_bus *bus = dev_id;
> -	u32 irq_received, irq_remaining, irq_handled;
> +	u32 irq_received, irq_remaining, irq_handled, irq_ack_last;
>   
>   	spin_lock(&bus->lock);
>   	irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
> -	/* Ack all interrupts except for Rx done */
> -	writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
> -	       bus->base + ASPEED_I2C_INTR_STS_REG);
> +
> +	/*
> +	 * Early acking of INTR_RX_DONE and INTR_TX_[ACK|NAK] would indicate HW to
> +	 * start receiving or sending new data, and this may cause a race condition
> +	 * as the irq handler has not yet handled these irqs but is being acked.
> +	 * Let's ack them late at the end of the irq handler when those are truly processed.
> +	 */
> +	irq_ack_last = ASPEED_I2CD_INTR_RX_DONE | ASPEED_I2CD_INTR_TX_ACK | ASPEED_I2CD_INTR_TX_NAK;
> +	writel(irq_received & ~irq_ack_last, bus->base + ASPEED_I2C_INTR_STS_REG);

As there will be v4, I'd like to improve this line of code a bit.

During debug, there are significant number of times when the 
irq_received has the value of 0x00000004 (INTR_RX_DONE) or 0x00000001 
(INTR_TX_ACK). This makes the "irq_received & ~irq_ack_last" turn out to 
be 0.

AFAIK, it does not make sense to keep repeatedly writing the 0 to the HW 
then try to re-read it with readl() every time. I'd like to change this 
HW access conditionally to avoid those unnecessary access.

The change would looks like below:

diff --git a/drivers/i2c/busses/i2c-aspeed.c 
b/drivers/i2c/busses/i2c-aspeed.c
index 5511fd46a65e..0f67218cf04a 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -93,6 +93,10 @@
  		 ASPEED_I2CD_INTR_RX_DONE | \
  		 ASPEED_I2CD_INTR_TX_NAK |  \
  		 ASPEED_I2CD_INTR_TX_ACK)
+#define ASPEED_I2CD_INTR_ACK_RX_TX         \
+		(ASPEED_I2CD_INTR_RX_DONE | \
+		 ASPEED_I2CD_INTR_TX_ACK |  \
+		 ASPEED_I2CD_INTR_TX_NAK)

  /* 0x14 : I2CD Command/Status Register   */
  #define ASPEED_I2CD_SCL_LINE_STS			BIT(18)
@@ -622,10 +626,19 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, 
void *dev_id)

  	spin_lock(&bus->lock);
  	irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
-	/* Ack all interrupts except for Rx done */
-	writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
-	       bus->base + ASPEED_I2C_INTR_STS_REG);
-	readl(bus->base + ASPEED_I2C_INTR_STS_REG);
+
+	/*
+	 * Early acking of INTR_RX_DONE and INTR_TX_[ACK|NAK] would
+        ...
+	 */
+	if (irq_received & ~ASPEED_I2CD_INTR_ACK_RX_TX) {
+		writel(irq_received & ~ASPEED_I2CD_INTR_ACK_RX_TX,
+		       bus->base + ASPEED_I2C_INTR_STS_REG);
+		readl(bus->base + ASPEED_I2C_INTR_STS_REG);
+	}
+
  	irq_received &= ASPEED_I2CD_INTR_RECV_MASK;
  	irq_remaining = irq_received;

Thanks,
- Quan


From quan at os.amperecomputing.com  Sun Dec 10 20:06:45 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Mon, 11 Dec 2023 11:06:45 +0700
Subject: [PATCH v3 2/2] i2c: aspeed: Acknowledge Tx done with and without
 ACK irq late
In-Reply-To: <20231209204455.jxize3muvx7hhpos@zenone.zhora.eu>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
 <20231208033142.1673232-3-quan@os.amperecomputing.com>
 <20231209204455.jxize3muvx7hhpos@zenone.zhora.eu>
Message-ID: <8822a211-678f-49e5-8e6b-50b46dfc61b3@os.amperecomputing.com>



On 10/12/2023 03:44, Andi Shyti wrote:
> Hi Quan,
> 
> [...]
> 
>> -	/* Ack all interrupts except for Rx done */
>> -	writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
>> -	       bus->base + ASPEED_I2C_INTR_STS_REG);
>> +
>> +	/*
>> +	 * Early acking of INTR_RX_DONE and INTR_TX_[ACK|NAK] would indicate HW to
>> +	 * start receiving or sending new data, and this may cause a race condition
>> +	 * as the irq handler has not yet handled these irqs but is being acked.
>> +	 * Let's ack them late at the end of the irq handler when those are truly processed.
>> +	 */
>> +	irq_ack_last = ASPEED_I2CD_INTR_RX_DONE | ASPEED_I2CD_INTR_TX_ACK | ASPEED_I2CD_INTR_TX_NAK;
>> +	writel(irq_received & ~irq_ack_last, bus->base + ASPEED_I2C_INTR_STS_REG);
> 
> I like Andrews suggestion of having irq_ack_last as a define that
> is already negated, instead of negating it in the writel, which
> makes it a bit difficult to read.
> 

Yes, but the it still need to negate again when do the write to late ack 
them later in the end of irq handler. So I'll keep the define as below 
in my v4:

+#define ASPEED_I2CD_INTR_ACK_RX_TX	    \
+		(ASPEED_I2CD_INTR_RX_DONE | \
+		 ASPEED_I2CD_INTR_TX_ACK |  \
+		 ASPEED_I2CD_INTR_TX_NAK)

The early ack will look like this:

+		writel(irq_received & ~ASPEED_I2CD_INTR_ACK_RX_TX,
+		       bus->base + ASPEED_I2C_INTR_STS_REG);
+		readl(bus->base + ASPEED_I2C_INTR_STS_REG);

And the late ack:

-	/* Ack Rx done */
-	if (irq_received & ASPEED_I2CD_INTR_RX_DONE) {
-		writel(ASPEED_I2CD_INTR_RX_DONE,
+	if (irq_received & ASPEED_I2CD_INTR_ACK_RX_TX) {
+		writel(irq_received & ASPEED_I2CD_INTR_ACK_RX_TX,
  		       bus->base + ASPEED_I2C_INTR_STS_REG);
  		readl(bus->base + ASPEED_I2C_INTR_STS_REG);
  	}

> Besides, ack_last, as a name is not very meaningful, I'd rather
> call it irq_ack_rx_tx (or something similar).
> 
> But I'm not going to block it for this, up to you if you want to
> send a new version.
> 
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
> 

Thanks, Andi for the comments.

I will send out v4 to address those.

- Quan


From fshao at chromium.org  Sun Dec 10 20:07:27 2023
From: fshao at chromium.org (Fei Shao)
Date: Mon, 11 Dec 2023 12:07:27 +0800
Subject: [PATCH] ASoC: mediatek: mt7986: silence error in case of -EPROBE_DEFER
In-Reply-To: <98491ec78ab671f5a14fce42d10f9745ebddb112.1702258360.git.daniel@makrotopia.org>
References: <98491ec78ab671f5a14fce42d10f9745ebddb112.1702258360.git.daniel@makrotopia.org>
Message-ID: <CAC=S1nh6twyqoSgeEXDsW=+FZRUxMN=Pkrw45KFq-z5XaGpFtw@mail.gmail.com>

Hi Daniel,

On Mon, Dec 11, 2023 at 9:33?AM Daniel Golle <daniel at makrotopia.org> wrote:
>
> If probe is defered no error should be printed. Mute it.
>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  sound/soc/mediatek/mt7986/mt7986-wm8960.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/mediatek/mt7986/mt7986-wm8960.c b/sound/soc/mediatek/mt7986/mt7986-wm8960.c
> index c1390b3734101..24a4b943030d7 100644
> --- a/sound/soc/mediatek/mt7986/mt7986-wm8960.c
> +++ b/sound/soc/mediatek/mt7986/mt7986-wm8960.c
> @@ -144,7 +144,9 @@ static int mt7986_wm8960_machine_probe(struct platform_device *pdev)
>
>         ret = devm_snd_soc_register_card(&pdev->dev, card);
>         if (ret) {
> -               dev_err(&pdev->dev, "%s snd_soc_register_card fail: %d\n", __func__, ret);
> +               if (ret != -EPROBE_DEFER)
> +                       dev_err(&pdev->dev, "%s snd_soc_register_card fail: %d\n", __func__, ret);
> +
Please consider using dev_err_probe() instead.

Regards,
Fei

>                 goto err_of_node_put;
>         }

>
> --
> 2.43.0
>
>


From quan at os.amperecomputing.com  Sun Dec 10 20:08:52 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Mon, 11 Dec 2023 11:08:52 +0700
Subject: [PATCH v3 1/2] i2c: aspeed: Handle the coalesced stop conditions
 with the start conditions.
In-Reply-To: <79ce9162faeb113ecb13efeb58d95f8a71e1a060.camel@codeconstruct.com.au>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
 <20231208033142.1673232-2-quan@os.amperecomputing.com>
 <79ce9162faeb113ecb13efeb58d95f8a71e1a060.camel@codeconstruct.com.au>
Message-ID: <43c99449-8a4b-4db5-8b1e-bc7ae920db76@os.amperecomputing.com>



On 08/12/2023 10:56, Andrew Jeffery wrote:
> On Fri, 2023-12-08 at 10:31 +0700, Quan Nguyen wrote:
>> Some masters may drive the transfers with low enough latency between
>> the nak/stop phase of the current command and the start/address phase
>> of the following command that the interrupts are coalesced by the
>> time we process them.
>> Handle the stop conditions before processing SLAVE_MATCH to fix the
>> complaints that sometimes occur below.
>>
>> "aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
>> 0x00000086, but was 0x00000084"
>>
>> Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
>> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
>> ---
>> v3:
>>    + Change to handle the coalesced stop condition with the start
>> conditions                                                            [Andrew]
>>    + Revised commit message                                              [Quan]
>>
>> v2:
>>    + Split to separate series                                            [Joel]
>>    + Added the Fixes line                                                [Joel]
>>    + Revised commit message                                              [Quan]
>>
>> v1:
>>    + First introduced in
>> https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/
>> ---
>>   drivers/i2c/busses/i2c-aspeed.c | 47 ++++++++++++++++++++++-----------
>>   1 file changed, 31 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
>> index 28e2a5fc4528..1c2a4f4c4e1b 100644
>> --- a/drivers/i2c/busses/i2c-aspeed.c
>> +++ b/drivers/i2c/busses/i2c-aspeed.c
>> @@ -249,18 +249,45 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
>>   	if (!slave)
>>   		return 0;
>>   
>> -	command = readl(bus->base + ASPEED_I2C_CMD_REG);
>> +	/*
>> +	 * Handle stop conditions early, prior to SLAVE_MATCH. Some masters may drive
>> +	 * transfers with low enough latency between the nak/stop phase of the current
>> +	 * command and the start/address phase of the following command that the
>> +	 * interrupts are coalesced by the time we process them.
>> +	 */
>> +	if (irq_status & ASPEED_I2CD_INTR_NORMAL_STOP) {
>> +		irq_handled |= ASPEED_I2CD_INTR_NORMAL_STOP;
>> +		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
>> +	}
>>   
>> -	/* Slave was requested, restart state machine. */
>> +	if (irq_status & ASPEED_I2CD_INTR_TX_NAK &&
>> +	    bus->slave_state == ASPEED_I2C_SLAVE_READ_PROCESSED) {
>> +		irq_handled |= ASPEED_I2CD_INTR_TX_NAK;
>> +		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
>> +	}
>> +
>> +	/* Propagate any stop conditions to the slave implementation. */
>> +	if (bus->slave_state == ASPEED_I2C_SLAVE_STOP) {
>> +		i2c_slave_event(slave, I2C_SLAVE_STOP, &value);
>> +		bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
>> +	}
>> +	/*
> 
> If there's a reason to do a v4 then an extra empty line above the
> comment would be nice. But let's not get hung up on that if everyone
> else is happy.
> 
> Thanks for the fixes!
> 
> Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>
> 

Thanks Andrew,

I'll add your Reviewed-by in my v4 with that extra empty lime before the 
comment.

Thanks for the review
- Quan


From quan at os.amperecomputing.com  Sun Dec 10 20:09:08 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Mon, 11 Dec 2023 11:09:08 +0700
Subject: [PATCH v3 1/2] i2c: aspeed: Handle the coalesced stop conditions
 with the start conditions.
In-Reply-To: <20231209202810.r7kkz2hlaonyibha@zenone.zhora.eu>
References: <20231208033142.1673232-1-quan@os.amperecomputing.com>
 <20231208033142.1673232-2-quan@os.amperecomputing.com>
 <20231209202810.r7kkz2hlaonyibha@zenone.zhora.eu>
Message-ID: <ffcacd0f-85a3-4c9f-9d0d-50425fec4775@os.amperecomputing.com>



On 10/12/2023 03:28, Andi Shyti wrote:
> Hi Quan,
> 
> On Fri, Dec 08, 2023 at 10:31:41AM +0700, Quan Nguyen wrote:
>> Some masters may drive the transfers with low enough latency between
>> the nak/stop phase of the current command and the start/address phase
>> of the following command that the interrupts are coalesced by the
>> time we process them.
>> Handle the stop conditions before processing SLAVE_MATCH to fix the
>> complaints that sometimes occur below.
>>
>> "aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
>> 0x00000086, but was 0x00000084"
>>
>> Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
>> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> 
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
> 

Thanks Andi,
I'll add your Reviewed-by in v4

Thanks,
- Quan


From me at kylehuey.com  Sun Dec 10 20:55:41 2023
From: me at kylehuey.com (Kyle Huey)
Date: Sun, 10 Dec 2023 20:55:41 -0800
Subject: [PATCH v3 2/4] perf/bpf: Remove unneeded uses_default_overflow_handler.
In-Reply-To: <20231211045543.31741-1-khuey@kylehuey.com>
References: <20231211045543.31741-1-khuey@kylehuey.com>
Message-ID: <20231211045543.31741-3-khuey@kylehuey.com>

Now that struct perf_event's orig_overflow_handler is gone, there's no need
for the functions and macros to support looking past overflow_handler to
orig_overflow_handler.

This patch is solely a refactoring and results in no behavior change.

Signed-off-by: Kyle Huey <khuey at kylehuey.com>
---
 arch/arm/kernel/hw_breakpoint.c   |  8 ++++----
 arch/arm64/kernel/hw_breakpoint.c |  4 ++--
 include/linux/perf_event.h        | 16 ++--------------
 3 files changed, 8 insertions(+), 20 deletions(-)

diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index dc0fb7a81371..054e9199f30d 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -626,7 +626,7 @@ int hw_breakpoint_arch_parse(struct perf_event *bp,
 	hw->address &= ~alignment_mask;
 	hw->ctrl.len <<= offset;
 
-	if (uses_default_overflow_handler(bp)) {
+	if (is_default_overflow_handler(bp)) {
 		/*
 		 * Mismatch breakpoints are required for single-stepping
 		 * breakpoints.
@@ -798,7 +798,7 @@ static void watchpoint_handler(unsigned long addr, unsigned int fsr,
 		 * Otherwise, insert a temporary mismatch breakpoint so that
 		 * we can single-step over the watchpoint trigger.
 		 */
-		if (!uses_default_overflow_handler(wp))
+		if (!is_default_overflow_handler(wp))
 			continue;
 step:
 		enable_single_step(wp, instruction_pointer(regs));
@@ -811,7 +811,7 @@ static void watchpoint_handler(unsigned long addr, unsigned int fsr,
 		info->trigger = addr;
 		pr_debug("watchpoint fired: address = 0x%x\n", info->trigger);
 		perf_bp_event(wp, regs);
-		if (uses_default_overflow_handler(wp))
+		if (is_default_overflow_handler(wp))
 			enable_single_step(wp, instruction_pointer(regs));
 	}
 
@@ -886,7 +886,7 @@ static void breakpoint_handler(unsigned long unknown, struct pt_regs *regs)
 			info->trigger = addr;
 			pr_debug("breakpoint fired: address = 0x%x\n", addr);
 			perf_bp_event(bp, regs);
-			if (uses_default_overflow_handler(bp))
+			if (is_default_overflow_handler(bp))
 				enable_single_step(bp, addr);
 			goto unlock;
 		}
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 35225632d70a..db2a1861bb97 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -654,7 +654,7 @@ static int breakpoint_handler(unsigned long unused, unsigned long esr,
 		perf_bp_event(bp, regs);
 
 		/* Do we need to handle the stepping? */
-		if (uses_default_overflow_handler(bp))
+		if (is_default_overflow_handler(bp))
 			step = 1;
 unlock:
 		rcu_read_unlock();
@@ -733,7 +733,7 @@ static u64 get_distance_from_watchpoint(unsigned long addr, u64 val,
 static int watchpoint_report(struct perf_event *wp, unsigned long addr,
 			     struct pt_regs *regs)
 {
-	int step = uses_default_overflow_handler(wp);
+	int step = is_default_overflow_handler(wp);
 	struct arch_hw_breakpoint *info = counter_arch_bp(wp);
 
 	info->trigger = addr;
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 312b9f31442c..7fef6299151b 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1321,8 +1321,9 @@ extern int perf_event_output(struct perf_event *event,
 			     struct pt_regs *regs);
 
 static inline bool
-__is_default_overflow_handler(perf_overflow_handler_t overflow_handler)
+is_default_overflow_handler(struct perf_event *event)
 {
+	perf_overflow_handler_t overflow_handler = event->overflow_handler;
 	if (likely(overflow_handler == perf_event_output_forward))
 		return true;
 	if (unlikely(overflow_handler == perf_event_output_backward))
@@ -1330,19 +1331,6 @@ __is_default_overflow_handler(perf_overflow_handler_t overflow_handler)
 	return false;
 }
 
-#define is_default_overflow_handler(event) \
-	__is_default_overflow_handler((event)->overflow_handler)
-
-#ifdef CONFIG_BPF_SYSCALL
-static inline bool uses_default_overflow_handler(struct perf_event *event)
-{
-	return is_default_overflow_handler(event);
-}
-#else
-#define uses_default_overflow_handler(event) \
-	is_default_overflow_handler(event)
-#endif
-
 extern void
 perf_event_header__init_id(struct perf_event_header *header,
 			   struct perf_sample_data *data,
-- 
2.34.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:15 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:15 +0800
Subject: [PATCH v3 00/14] Add i2c-mux and eeprom devices for Meta Yosemite 4
Message-ID: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>

Changelog:
  - v3
    - Correct patch for revising gpio name
  - v2
    - Revise mx31790 fan tach config
    - Add mctp config for NIC
    - Support mux to cpld
    - Revise gpio name
  - v1
    - Add gpio and eeprom behind i2c-mux
    - Remove redundant idle-state setting for i2c-mux
    - Enable adc 15, wdt2,spi gpio for yosemite4 use
    - Revise quad mode to dual mode to avoid WP pin influnece the SPI
    - Revise power sensor adm1281 for yosemite4 schematic change
    - Add gpio pca9506 I/O expander for yosemite4 use
    - remove space for adm1272 compatible
    - enable interrupt setting for pca9555
    - add eeprom for yosemite4 medusa board/BSM use
    - remove temperature sensor for yosemite4 schematic change
    - add power sensor for power module reading
    - Revise adc128d818 adc mode for yosemite4 schematic change
    - Revise ina233 for yosemite4 schematic change
    - Remove idle state setting for yosemite4 NIC connection
    - Initialize bmc gpio state
    - Revise mx31790 fan tach config
    - Add mctp config for NIC
    - Support mux to cpld
    - Revise gpio name

Delphine CC Chiu (14):
  ARM: dts: aspeed: yosemite4: Revise i2c-mux devices
  ARM: dts: aspeed: yosemite4: Enable adc15
  ARM: dts: aspeed: yosemite4: Enable spi-gpio setting
  ARM: dts: aspeed: yosemite4: Enable watchdog2
  ARM: dts: aspeed: yosemite4: Revise quad mode to dual mode
  ARM: dts: aspeed: yosemite4: Revise power sensor adm1281 for schematic
    change
  ARM: dts: aspeed: yosemite4: Add gpio pca9506
  ARM: dts: aspeed: yosemite4: Revise i2c11 and i2c12 schematic change
  ARM: dts: aspeed: yosemite4: Revise i2c14 and i2c15 schematic change
  ARM: dts: aspeed: yosemite4: Initialize bmc gpio state
  ARM: dts: aspeed: yosemite4: Revise mx31790 fan tach config
  ARM: dts: aspeed: yosemite4: add mctp config for NIC
  ARM: dts: aspeed: yosemite4: support mux to cpld
  ARM: dts: aspeed: yosemite4: Revise gpio name

 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 1215 +++++++++++++++--
 1 file changed, 1091 insertions(+), 124 deletions(-)

-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:16 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:16 +0800
Subject: [PATCH v3 01/14] ARM: dts: aspeed: yosemite4: Revise i2c-mux devices
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-2-Delphine_CC_Chiu@wiwynn.com>

Revise Yosemite 4 devicetree for devices behind i2c-mux
- Add gpio and eeprom behind i2c-mux
- Remove redundant idle-state setting for i2c-mux

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 381 ++++++++++++++++--
 1 file changed, 347 insertions(+), 34 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 64075cc41d92..a5b4585e81e6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -17,6 +17,25 @@ aliases {
 		serial6 = &uart7;
 		serial7 = &uart8;
 		serial8 = &uart9;
+
+		i2c16 = &imux16;
+		i2c17 = &imux17;
+		i2c18 = &imux18;
+		i2c19 = &imux19;
+		i2c20 = &imux20;
+		i2c21 = &imux21;
+		i2c22 = &imux22;
+		i2c23 = &imux23;
+		i2c24 = &imux24;
+		i2c25 = &imux25;
+		i2c26 = &imux26;
+		i2c27 = &imux27;
+		i2c28 = &imux28;
+		i2c29 = &imux29;
+		i2c30 = &imux30;
+		i2c31 = &imux31;
+		i2c32 = &imux32;
+		i2c33 = &imux33;
 	};
 
 	chosen {
@@ -259,9 +278,109 @@ &i2c8 {
 	bus-frequency = <400000>;
 	i2c-mux at 70 {
 		compatible = "nxp,pca9544";
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
 		reg = <0x70>;
+
+		imux16: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux17: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux18: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux19: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
 	};
 };
 
@@ -270,15 +389,174 @@ &i2c9 {
 	bus-frequency = <400000>;
 	i2c-mux at 71 {
 		compatible = "nxp,pca9544";
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
 		reg = <0x71>;
+
+		imux20: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux21: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux22: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
+
+		imux23: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+
+			gpio at 49 {
+				compatible = "nxp,pca9537";
+				reg = <0x49>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
+
+			eeprom at 51 {
+				compatible = "atmel,24c128";
+				reg = <0x51>;
+			};
+
+			eeprom at 54 {
+				compatible = "atmel,24c128";
+				reg = <0x54>;
+			};
+		};
 	};
 };
 
 &i2c10 {
 	status = "okay";
 	bus-frequency = <400000>;
+	i2c-mux at 74 {
+		compatible = "nxp,pca9544";
+		i2c-mux-idle-disconnect;
+		reg = <0x74>;
+
+		imux28: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			gpio at 20 {
+				compatible = "nxp,pca9506";
+				reg = <0x20>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio at 21 {
+				compatible = "nxp,pca9506";
+				reg = <0x21>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio at 22 {
+				compatible = "nxp,pca9506";
+				reg = <0x22>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio at 23 {
+				compatible = "nxp,pca9506";
+				reg = <0x23>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio at 24 {
+				compatible = "nxp,pca9506";
+				reg = <0x24>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				gpio-line-names =
+				"","","","",
+				"NIC0_MAIN_PWR_EN","NIC1_MAIN_PWR_EN",
+				"NIC2_MAIN_PWR_EN","NIC3_MAIN_PWR_EN",
+				"","","","","","","","",
+				"","","","","","","","",
+				"","","","","","","","";
+			};
+		};
+
+		imux29: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
 };
 
 &i2c11 {
@@ -433,16 +711,14 @@ eeprom at 51 {
 		reg = <0x51>;
 	};
 
-	i2c-mux at 71 {
-		compatible = "nxp,pca9846";
+	i2c-mux at 74 {
+		compatible = "nxp,pca9546";
 		#address-cells = <1>;
 		#size-cells = <0>;
-
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
-		reg = <0x71>;
+		reg = <0x74>;
 
-		i2c at 0 {
+		imux30: i2c at 0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
@@ -450,26 +726,26 @@ i2c at 0 {
 			adc at 1f {
 				compatible = "ti,adc128d818";
 				reg = <0x1f>;
-				ti,mode = /bits/ 8 <2>;
+				ti,mode = /bits/ 8 <1>;
 			};
 
 			pwm at 20{
-				compatible = "max31790";
+				compatible = "maxim,max31790";
+				pwm-as-tach = <4 5>;
 				reg = <0x20>;
-				#address-cells = <1>;
-				#size-cells = <0>;
 			};
 
 			gpio at 22{
 				compatible = "ti,tca6424";
 				reg = <0x22>;
+				gpio-controller;
+				#gpio-cells = <2>;
 			};
 
-			pwm at 23{
-				compatible = "max31790";
-				reg = <0x23>;
-				#address-cells = <1>;
-				#size-cells = <0>;
+			pwm at 2f{
+				compatible = "maxim,max31790";
+				pwm-as-tach = <4 5>;
+				reg = <0x2f>;
 			};
 
 			adc at 33 {
@@ -492,34 +768,34 @@ gpio at 61 {
 			};
 		};
 
-		i2c at 1 {
+		imux31: i2c at 1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
-			reg = <0>;
+			reg = <1>;
 
 			adc at 1f {
 				compatible = "ti,adc128d818";
 				reg = <0x1f>;
-				ti,mode = /bits/ 8 <2>;
+				ti,mode = /bits/ 8 <1>;
 			};
 
 			pwm at 20{
-				compatible = "max31790";
+				compatible = "maxim,max31790";
+				pwm-as-tach = <4 5>;
 				reg = <0x20>;
-				#address-cells = <1>;
-				#size-cells = <0>;
 			};
 
 			gpio at 22{
 				compatible = "ti,tca6424";
 				reg = <0x22>;
+				gpio-controller;
+				#gpio-cells = <2>;
 			};
 
-			pwm at 23{
-				compatible = "max31790";
-				reg = <0x23>;
-				#address-cells = <1>;
-				#size-cells = <0>;
+			pwm at 2f{
+				compatible = "maxim,max31790";
+				pwm-as-tach = <4 5>;
+				reg = <0x2f>;
 			};
 
 			adc at 33 {
@@ -547,12 +823,10 @@ i2c-mux at 73 {
 		compatible = "nxp,pca9544";
 		#address-cells = <1>;
 		#size-cells = <0>;
-
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
 		reg = <0x73>;
 
-		i2c at 0 {
+		imux32: i2c at 0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
@@ -563,10 +837,10 @@ adc at 35 {
 			};
 		};
 
-		i2c at 1 {
+		imux33: i2c at 1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
-			reg = <0>;
+			reg = <1>;
 
 			adc at 35 {
 				compatible = "maxim,max11617";
@@ -589,9 +863,48 @@ mctp at 10 {
 
 	i2c-mux at 72 {
 		compatible = "nxp,pca9544";
-		idle-state = <0>;
 		i2c-mux-idle-disconnect;
 		reg = <0x72>;
+
+		imux24: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			temperature-sensor at 1f {
+				compatible = "ti,tmp421";
+				reg = <0x1f>;
+			};
+		};
+
+		imux25: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			temperature-sensor at 1f {
+				compatible = "ti,tmp421";
+				reg = <0x1f>;
+			};
+		};
+
+		imux26: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+			temperature-sensor at 1f {
+				compatible = "ti,tmp421";
+				reg = <0x1f>;
+			};
+		};
+
+		imux27: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+			temperature-sensor at 1f {
+				compatible = "ti,tmp421";
+				reg = <0x1f>;
+			};
+		};
 	};
 };
 
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:17 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:17 +0800
Subject: [PATCH v3 02/14] ARM: dts: aspeed: yosemite4: Enable adc15
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-3-Delphine_CC_Chiu@wiwynn.com>

Enable Yosemite 4 adc15 config

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index a5b4585e81e6..c32736fbaf70 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -51,7 +51,7 @@ iio-hwmon {
 		compatible = "iio-hwmon";
 		io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
 				<&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
-				<&adc1 0>, <&adc1 1>;
+				<&adc1 0>, <&adc1 1>, <&adc1 7>;
 	};
 };
 
@@ -920,10 +920,10 @@ &pinctrl_adc4_default &pinctrl_adc5_default
 &adc1 {
 	ref_voltage = <2500>;
 	status = "okay";
-	pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc9_default>;
+	pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc9_default
+	    &pinctrl_adc15_default>;
 };
 
-
 &ehci0 {
 	status = "okay";
 };
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:18 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:18 +0800
Subject: [PATCH v3 03/14] ARM: dts: aspeed: yosemite4: Enable spi-gpio setting
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-4-Delphine_CC_Chiu@wiwynn.com>

enable spi-gpio setting for spi flash

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts   | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index c32736fbaf70..0449a7e36ff6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -53,6 +53,24 @@ iio-hwmon {
 				<&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
 				<&adc1 0>, <&adc1 1>, <&adc1 7>;
 	};
+
+	spi_gpio: spi-gpio {
+		compatible = "spi-gpio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio-sck = <&gpio0 ASPEED_GPIO(X, 3) GPIO_ACTIVE_HIGH>;
+		gpio-mosi = <&gpio0 ASPEED_GPIO(X, 4) GPIO_ACTIVE_HIGH>;
+		gpio-miso = <&gpio0 ASPEED_GPIO(X, 5) GPIO_ACTIVE_HIGH>;
+		num-chipselects = <1>;
+		cs-gpios = <&gpio0 ASPEED_GPIO(X, 0) GPIO_ACTIVE_LOW>;
+
+		tpmdev at 0 {
+			compatible = "tcg,tpm_tis-spi";
+			spi-max-frequency = <33000000>;
+			reg = <0>;
+		};
+	};
 };
 
 &uart1 {
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:19 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:19 +0800
Subject: [PATCH v3 04/14] ARM: dts: aspeed: yosemite4: Enable watchdog2
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-5-Delphine_CC_Chiu@wiwynn.com>

enable watchdog2 setting

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 0449a7e36ff6..0e9095c83a59 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -120,6 +120,13 @@ &wdt1 {
 	aspeed,ext-pulse-duration = <256>;
 };
 
+&wdt2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdtrst2_default>;
+	aspeed,reset-type = "system";
+};
+
 &mac2 {
 	status = "okay";
 	pinctrl-names = "default";
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:20 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:20 +0800
Subject: [PATCH v3 05/14] ARM: dts: aspeed: yosemite4: Revise quad mode to dual mode
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-6-Delphine_CC_Chiu@wiwynn.com>

Revise quad mode to dual mode to avoid WP pin influnece the SPI

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 0e9095c83a59..7fe80ad271aa 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -149,15 +149,17 @@ flash at 0 {
 		status = "okay";
 		m25p,fast-read;
 		label = "bmc";
-		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
 		spi-max-frequency = <50000000>;
-#include "openbmc-flash-layout-64.dtsi"
+#include "openbmc-flash-layout-128.dtsi"
 	};
 	flash at 1 {
 		status = "okay";
 		m25p,fast-read;
 		label = "bmc2";
-		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
 		spi-max-frequency = <50000000>;
 	};
 };
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:21 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:21 +0800
Subject: [PATCH v3 06/14] ARM: dts: aspeed: yosemite4: Revise power sensor adm1281 for schematic change
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-7-Delphine_CC_Chiu@wiwynn.com>

Revise power sensor adm1281 for yosemite4 schematic change

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 24 ++++++++++++-------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 7fe80ad271aa..7f0134fcee57 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -176,8 +176,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -193,8 +194,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -210,8 +212,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -227,8 +230,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -244,8 +248,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -261,8 +266,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -278,8 +284,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
@@ -295,8 +302,9 @@ mctp at 10 {
 	};
 
 	power-sensor at 40 {
-		compatible = "adi,adm1278";
+		compatible = "adi,adm1281";
 		reg = <0x40>;
+		shunt-resistor-micro-ohms = <500>;
 	};
 };
 
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:22 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:22 +0800
Subject: [PATCH v3 07/14] ARM: dts: aspeed: yosemite4: Add gpio pca9506
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-8-Delphine_CC_Chiu@wiwynn.com>

Add gpio pca9506 I/O expander for yv4 use

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 251 ++++++++++++++++++
 1 file changed, 251 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 7f0134fcee57..da413325ce30 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -175,6 +175,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -193,6 +221,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -211,6 +267,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -229,6 +313,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -247,6 +359,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -265,6 +405,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -283,6 +451,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -301,6 +497,34 @@ mctp at 10 {
 		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
 	};
 
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
 	power-sensor at 40 {
 		compatible = "adi,adm1281";
 		reg = <0x40>;
@@ -683,6 +907,33 @@ rtc at 6f {
 &i2c13 {
 	status = "okay";
 	bus-frequency = <400000>;
+	gpio at 20 {
+		compatible = "nxp,pca9506";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 21 {
+		compatible = "nxp,pca9506";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 22 {
+		compatible = "nxp,pca9506";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	gpio at 23 {
+		compatible = "nxp,pca9506";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
 
 &i2c14 {
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:23 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:23 +0800
Subject: [PATCH v3 08/14] ARM: dts: aspeed: yosemite4: Revise i2c11 and i2c12 schematic change
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-9-Delphine_CC_Chiu@wiwynn.com>

Revise i2c11 and i2c12 schematic change:
- remove space for adm1272 compatible
- enable interrupt setting for pca9555
- add eeprom for yosemite4 medusa board/BSM use
- remove temperature sensor for yosemite4 schematic change
- add power sensor for power module reading

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 118 ++++++++++++++----
 1 file changed, 93 insertions(+), 25 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index da413325ce30..ccb5ecd8d9a6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -821,41 +821,94 @@ imux29: i2c at 1 {
 &i2c11 {
 	status = "okay";
 	power-sensor at 10 {
-		compatible = "adi, adm1272";
+		compatible = "adi,adm1272";
 		reg = <0x10>;
 	};
 
 	power-sensor at 12 {
-		compatible = "adi, adm1272";
+		compatible = "adi,adm1272";
 		reg = <0x12>;
 	};
 
-	gpio at 20 {
+	gpio_ext1: pca9555 at 20 {
 		compatible = "nxp,pca9555";
-		reg = <0x20>;
+		pinctrl-names = "default";
 		gpio-controller;
 		#gpio-cells = <2>;
-	};
-
-	gpio at 21 {
+		reg = <0x20>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+		"P48V_OCP_GPIO1","P48V_OCP_GPIO2",
+		"P48V_OCP_GPIO3","FAN_BOARD_0_REVISION_0_R",
+		"FAN_BOARD_0_REVISION_1_R","FAN_BOARD_1_REVISION_0_R",
+		"FAN_BOARD_1_REVISION_1_R","RST_MUX_R_N",
+		"RST_LED_CONTROL_FAN_BOARD_0_N","RST_LED_CONTROL_FAN_BOARD_1_N",
+		"RST_IOEXP_FAN_BOARD_0_N","RST_IOEXP_FAN_BOARD_1_N",
+		"PWRGD_LOAD_SWITCH_FAN_BOARD_0_R","PWRGD_LOAD_SWITCH_FAN_BOARD_1_R",
+		"","";
+	};
+
+	gpio_ext2: pca9555 at 21 {
 		compatible = "nxp,pca9555";
-		reg = <0x21>;
+		pinctrl-names = "default";
 		gpio-controller;
 		#gpio-cells = <2>;
-	};
-
-	gpio at 22 {
+		reg = <0x21>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+		"DELTA_MODULE_TYPE","VSENSE_ERR_VDROP_R",
+		"EN_P48V_AUX_0","EN_P48V_AUX_1",
+		"MEDUSA_BOARD_REV_0","MEDUSA_BOARD_REV_1",
+		"MEDUSA_BOARD_REV_2","MEDUSA_BOARD_TYPE",
+		"HSC_OCP_SLOT_ODD_GPIO1","HSC_OCP_SLOT_ODD_GPIO2",
+		"HSC_OCP_SLOT_ODD_GPIO3","HSC_OCP_SLOT_EVEN_GPIO1",
+		"HSC_OCP_SLOT_EVEN_GPIO2","HSC_OCP_SLOT_EVEN_GPIO3",
+		"ADC_TYPE_0_R","ADC_TYPE_1_R";
+	};
+
+	gpio_ext3: pca9555 at 22 {
 		compatible = "nxp,pca9555";
-		reg = <0x22>;
+		pinctrl-names = "default";
 		gpio-controller;
 		#gpio-cells = <2>;
-	};
-
-	gpio at 23 {
+		reg = <0x22>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+		"CARD_TYPE_SLOT1","CARD_TYPE_SLOT2",
+		"CARD_TYPE_SLOT3","CARD_TYPE_SLOT4",
+		"CARD_TYPE_SLOT5","CARD_TYPE_SLOT6",
+		"CARD_TYPE_SLOT7","CARD_TYPE_SLOT8",
+		"OC_P48V_HSC_0_N","FLT_P48V_HSC_0_N",
+		"PWRGD_P12V_AUX_1","OC_P48V_HSC_1_N",
+		"FLT_P48V_HSC_1_N","PWRGD_P12V_AUX_1",
+		"MEDUSA_ADC_EFUSE_TYPE_R","P12V_HSC_TYPE";
+	};
+
+	gpio_ext4: pca9555 at 23 {
 		compatible = "nxp,pca9555";
-		reg = <0x23>;
+		pinctrl-names = "default";
 		gpio-controller;
 		#gpio-cells = <2>;
+		reg = <0x23>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names =
+		"HSC1_ALERT1_R_N","HSC2_ALERT1_R_N",
+		"HSC3_ALERT1_R_N","HSC4_ALERT1_R_N",
+		"HSC5_ALERT1_R_N","HSC6_ALERT1_R_N",
+		"HSC7_ALERT1_R_N","HSC8_ALERT1_R_N",
+		"HSC1_ALERT2_R_N","HSC2_ALERT2_R_N",
+		"HSC3_ALERT2_R_N","HSC4_ALERT2_R_N",
+		"HSC5_ALERT2_R_N","HSC6_ALERT2_R_N",
+		"HSC7_ALERT2_R_N","HSC8_ALERT2_R_N";
+	};
+
+	power-sensor at 40 {
+			compatible = "mps,mp5023";
+			reg = <0x40>;
 	};
 
 	temperature-sensor at 48 {
@@ -868,19 +921,29 @@ temperature-sensor at 49 {
 		reg = <0x49>;
 	};
 
-	temperature-sensor at 4a {
-		compatible = "ti,tmp75";
-		reg = <0x4a>;
+	eeprom at 54 {
+		compatible = "atmel,24c128";
+		reg = <0x54>;
 	};
 
-	temperature-sensor at 4b {
-		compatible = "ti,tmp75";
-		reg = <0x4b>;
+	power-sensor at 62 {
+		compatible = "pmbus";
+		reg = <0x62>;
 	};
 
-	eeprom at 54 {
-		compatible = "atmel,24c256";
-		reg = <0x54>;
+	power-sensor at 64 {
+		compatible = "pmbus";
+		reg = <0x64>;
+	};
+
+	power-sensor at 65 {
+		compatible = "pmbus";
+		reg = <0x65>;
+	};
+
+	power-sensor at 68 {
+		compatible = "pmbus";
+		reg = <0x68>;
 	};
 };
 
@@ -898,6 +961,11 @@ eeprom at 50 {
 		reg = <0x50>;
 	};
 
+	eeprom at 54 {
+		compatible = "atmel,24c64";
+		reg = <0x54>;
+	};
+
 	rtc at 6f {
 		compatible = "nuvoton,nct3018y";
 		reg = <0x6f>;
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:24 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:24 +0800
Subject: [PATCH v3 09/14] ARM: dts: aspeed: yosemite4: Revise i2c14 and i2c15 schematic change
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-10-Delphine_CC_Chiu@wiwynn.com>

Revise i2c14 and i2c15 schematic change:
- Revise adc128d818 adc mode for yosemite4 schematic change
- Revise ina233 for yosemite4 schematic change
- Remove idle state setting for yosemite4 NIC connection

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 31 ++++++++++++-------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index ccb5ecd8d9a6..ed2b1200603d 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1010,44 +1010,54 @@ &i2c14 {
 	adc at 1d {
 		compatible = "ti,adc128d818";
 		reg = <0x1d>;
-		ti,mode = /bits/ 8 <2>;
+		ti,mode = /bits/ 8 <1>;
 	};
 
-	adc at 35 {
+	adc at 36 {
 		compatible = "ti,adc128d818";
-		reg = <0x35>;
-		ti,mode = /bits/ 8 <2>;
+		reg = <0x36>;
+		ti,mode = /bits/ 8 <1>;
 	};
 
 	adc at 37 {
 		compatible = "ti,adc128d818";
 		reg = <0x37>;
-		ti,mode = /bits/ 8 <2>;
+		ti,mode = /bits/ 8 <1>;
 	};
 
 	power-sensor at 40 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x40>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	power-sensor at 41 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x41>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	power-sensor at 42 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x42>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	power-sensor at 43 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x43>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	power-sensor at 44 {
-		compatible = "ti,ina230";
+		compatible = "ti,ina233";
 		reg = <0x44>;
+		resistor-calibration = /bits/ 16 <0x0a00>;
+		current-lsb= /bits/ 16 <0x0001>;
 	};
 
 	temperature-sensor at 4e {
@@ -1217,7 +1227,6 @@ mctp at 10 {
 
 	i2c-mux at 72 {
 		compatible = "nxp,pca9544";
-		i2c-mux-idle-disconnect;
 		reg = <0x72>;
 
 		imux24: i2c at 0 {
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:26 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:26 +0800
Subject: [PATCH v3 11/14] ARM: dts: aspeed: yosemite4: Revise mx31790 fan tach config
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-12-Delphine_CC_Chiu@wiwynn.com>

Revise fan tach config for max31790 driver change

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 48 +++++++++++++++++--
 1 file changed, 44 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index eb3687bfd632..073f27f1e35f 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1095,8 +1095,18 @@ adc at 1f {
 
 			pwm at 20{
 				compatible = "maxim,max31790";
-				pwm-as-tach = <4 5>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x20>;
+				channel at 4 {
+					reg = <4>;
+					sensor-type = "TACH";
+				};
+
+				channel at 5 {
+					reg = <5>;
+					sensor-type = "TACH";
+				};
 			};
 
 			gpio at 22{
@@ -1108,8 +1118,18 @@ gpio at 22{
 
 			pwm at 2f{
 				compatible = "maxim,max31790";
-				pwm-as-tach = <4 5>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x2f>;
+				channel at 4 {
+					reg = <4>;
+					sensor-type = "TACH";
+				};
+
+				channel at 5 {
+					reg = <5>;
+					sensor-type = "TACH";
+				};
 			};
 
 			adc at 33 {
@@ -1145,8 +1165,18 @@ adc at 1f {
 
 			pwm at 20{
 				compatible = "maxim,max31790";
-				pwm-as-tach = <4 5>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x20>;
+				channel at 4 {
+					reg = <4>;
+					sensor-type = "TACH";
+				};
+
+				channel at 5 {
+					reg = <5>;
+					sensor-type = "TACH";
+				};
 			};
 
 			gpio at 22{
@@ -1158,8 +1188,18 @@ gpio at 22{
 
 			pwm at 2f{
 				compatible = "maxim,max31790";
-				pwm-as-tach = <4 5>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x2f>;
+				channel at 4 {
+					reg = <4>;
+					sensor-type = "TACH";
+				};
+
+				channel at 5 {
+					reg = <5>;
+					sensor-type = "TACH";
+				};
 			};
 
 			adc at 33 {
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:27 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:27 +0800
Subject: [PATCH v3 12/14] ARM: dts: aspeed: yosemite4: add mctp config for NIC
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-13-Delphine_CC_Chiu@wiwynn.com>

add mctp config for NIC

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 073f27f1e35f..c8e3a85b7a11 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1273,40 +1273,64 @@ imux24: i2c at 0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
+			mctp-controller;
 			temperature-sensor at 1f {
 				compatible = "ti,tmp421";
 				reg = <0x1f>;
 			};
+
+			emc1403 at 3c {
+				compatible = "smsc,emc1403";
+				reg = <0x3c>;
+			};
 		};
 
 		imux25: i2c at 1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <1>;
+			mctp-controller;
 			temperature-sensor at 1f {
 				compatible = "ti,tmp421";
 				reg = <0x1f>;
 			};
+
+			emc1403 at 3c {
+				compatible = "smsc,emc1403";
+				reg = <0x3c>;
+			};
 		};
 
 		imux26: i2c at 2 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <2>;
+			mctp-controller;
 			temperature-sensor at 1f {
 				compatible = "ti,tmp421";
 				reg = <0x1f>;
 			};
+
+			emc1403 at 3c {
+				compatible = "smsc,emc1403";
+				reg = <0x3c>;
+			};
 		};
 
 		imux27: i2c at 3 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <3>;
+			mctp-controller;
 			temperature-sensor at 1f {
 				compatible = "ti,tmp421";
 				reg = <0x1f>;
 			};
+
+			emc1403 at 3c {
+				compatible = "smsc,emc1403";
+				reg = <0x3c>;
+			};
 		};
 	};
 };
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:28 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:28 +0800
Subject: [PATCH v3 13/14] ARM: dts: aspeed: yosemite4: support mux to cpld
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-14-Delphine_CC_Chiu@wiwynn.com>

Mux pca9544 to cpld was added on EVT HW schematic design,
so add dts setting for devices behind mux pca9544 to cpld

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 64 ++++++++++++++-----
 1 file changed, 49 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index c8e3a85b7a11..fdc33bffd467 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -36,6 +36,10 @@ aliases {
 		i2c31 = &imux31;
 		i2c32 = &imux32;
 		i2c33 = &imux33;
+		i2c34 = &imux34;
+		i2c35 = &imux35;
+		i2c36 = &imux36;
+		i2c37 = &imux37;
 	};
 
 	chosen {
@@ -951,24 +955,54 @@ &i2c12 {
 	status = "okay";
 	bus-frequency = <400000>;
 
-	temperature-sensor at 48 {
-		compatible = "ti,tmp75";
-		reg = <0x48>;
-	};
+	i2c-mux at 70 {
+		compatible = "nxp,pca9544";
+		i2c-mux-idle-disconnect;
+		reg = <0x70>;
 
-	eeprom at 50 {
-		compatible = "atmel,24c128";
-		reg = <0x50>;
-	};
+		imux34: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
 
-	eeprom at 54 {
-		compatible = "atmel,24c64";
-		reg = <0x54>;
-	};
+			temperature-sensor at 48 {
+				compatible = "ti,tmp75";
+				reg = <0x48>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c128";
+				reg = <0x50>;
+			};
 
-	rtc at 6f {
-		compatible = "nuvoton,nct3018y";
-		reg = <0x6f>;
+			eeprom at 54 {
+				compatible = "atmel,24c64";
+				reg = <0x54>;
+			};
+
+			rtc at 6f {
+				compatible = "nuvoton,nct3018y";
+				reg = <0x6f>;
+			};
+		};
+
+		imux35: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+
+		imux36: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+
+		imux37: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
 	};
 };
 
-- 
2.25.1



From anshuman.khandual at arm.com  Sun Dec 10 22:00:08 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 11 Dec 2023 11:30:08 +0530
Subject: [PATCH V15 5/8] KVM: arm64: nvhe: Disable branch generation in
 nVHE guests
In-Reply-To: <86ttoybbp4.wl-maz@kernel.org>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
 <20231201053906.1261704-6-anshuman.khandual@arm.com>
 <86ttoybbp4.wl-maz@kernel.org>
Message-ID: <e48f5cdc-2711-4a03-a074-da87d84b3caf@arm.com>

On 12/4/23 14:12, Marc Zyngier wrote:
> On Fri, 01 Dec 2023 05:39:03 +0000,
> Anshuman Khandual <anshuman.khandual at arm.com> wrote:
>>
>> Disable the BRBE before we enter the guest, saving the status and enable it
>> back once we get out of the guest. This is just to avoid capturing records
>> in the guest kernel/userspace, which would be confusing the samples.
> 
> Why does it have to be limited to non-VHE? What protects host EL0
> records from guest's EL0 execution when the host is VHE?

In a scenario when running the host in VHE mode
 
- The host might have enabled branch records for host EL0 through BRBCR_EL2.E0HBRE
  indirectly via accessing BRBCR_EL1.E0BRE

- But after the guest switches in on the cpu - BRBCR_EL2.E0HBRE will still remain
  set and enable branch records in guest EL0 as well because BRBCR_EL1.E0BRE will
  not have any effect when EL2 is implemented and HCR_EL2.TGE == 1. The guest EL0
  execution branch records will find their way into branch records being captured
  for host EL0

You are right. The host EL0 branch records too need to be protected from guest EL0
execution. A similar BRBCR_EL1 save/restore mechanism is needed for VHE as well ?

> 
>>
>> Cc: Marc Zyngier <maz at kernel.org>
>> Cc: Oliver Upton <oliver.upton at linux.dev>
>> Cc: James Morse <james.morse at arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will at kernel.org>
>> Cc: kvmarm at lists.linux.dev
>> Cc: linux-arm-kernel at lists.infradead.org
>> CC: linux-kernel at vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>> Changes in V15:
>>
>> - Dropped runtime BRBE enable for setting DEBUG_STATE_SAVE_BRBE
>> - Dropped BRBFCR_EL1 from __debug_save_brbe()/__debug_restore_brbe()
>> - Always save the live SYS_BRBCR_EL1 in host context and then check if
>>   BRBE was enabled before resetting SYS_BRBCR_EL1 for the host
>>
>>  arch/arm64/include/asm/kvm_host.h  |  4 ++++
>>  arch/arm64/kvm/debug.c             |  5 +++++
>>  arch/arm64/kvm/hyp/nvhe/debug-sr.c | 33 ++++++++++++++++++++++++++++++
>>  3 files changed, 42 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 68421c74283a..1faa0430d8dd 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -449,6 +449,8 @@ enum vcpu_sysreg {
>>  	CNTHV_CVAL_EL2,
>>  	PMSCR_EL1,	/* Statistical profiling extension */
>>  	TRFCR_EL1,	/* Self-hosted trace filters */
>> +	BRBCR_EL1,	/* Branch Record Buffer Control Register */
>> +	BRBFCR_EL1,	/* Branch Record Buffer Function Control Register */
> 
> Whose state is this? If this is limited to the host, it has no purpose
> in this enum. Once you add guest support, then it will make sense.

yes, this is limited to host but if not here, where this register (BRBCR_EL1)
should be stored during guest context switch ? This place holder is used for
that purpose via ctxt_sys_reg(host_ctxt, BRBCR_EL1).

> 
>>
>>  	NR_SYS_REGS	/* Nothing after this line! */
>>  };
>> @@ -753,6 +755,8 @@ struct kvm_vcpu_arch {
>>  #define VCPU_HYP_CONTEXT	__vcpu_single_flag(iflags, BIT(7))
>>  /* Save trace filter controls */
>>  #define DEBUG_STATE_SAVE_TRFCR	__vcpu_single_flag(iflags, BIT(8))
>> +/* Save BRBE context if active  */
>> +#define DEBUG_STATE_SAVE_BRBE	__vcpu_single_flag(iflags, BIT(9))
>>  
>>  /* SVE enabled for host EL0 */
>>  #define HOST_SVE_ENABLED	__vcpu_single_flag(sflags, BIT(0))
>> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
>> index 2ab41b954512..fa46a70a9503 100644
>> --- a/arch/arm64/kvm/debug.c
>> +++ b/arch/arm64/kvm/debug.c
>> @@ -354,6 +354,10 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
>>  		    !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P))
>>  			vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>>  	}
>> +
>> +	/* Check if we have BRBE implemented and available at the host */
>> +	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_BRBE_SHIFT))
>> +		vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_BRBE);
>>  }
>>  
>>  void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
>> @@ -361,6 +365,7 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
>>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_SPE);
>>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
>> +	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_BRBE);
>>  }
>>  
>>  void kvm_etm_set_guest_trfcr(u64 trfcr_guest)
>> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
>> index 6174f710948e..1994fc48b57c 100644
>> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
>> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
>> @@ -93,6 +93,33 @@ static void __debug_restore_trace(struct kvm_cpu_context *host_ctxt,
>>  		write_sysreg_s(ctxt_sys_reg(host_ctxt, TRFCR_EL1), SYS_TRFCR_EL1);
>>  }
>>  
>> +static void __debug_save_brbe(struct kvm_cpu_context *host_ctxt)
>> +{
>> +	ctxt_sys_reg(host_ctxt, BRBCR_EL1) = read_sysreg_s(SYS_BRBCR_EL1);
>> +
>> +	/* Check if the BRBE is enabled */
>> +	if (!(ctxt_sys_reg(host_ctxt, BRBCR_EL1) & (BRBCR_ELx_E0BRE | BRBCR_ELx_ExBRE)))
>> +		return;
> 
> Why save BRBCR_EL1 if there is nothing enabled? It isn't like it can
> change behind your back, can it?

James mentioned that always setting the host value with real BRBCR_EL1 is preferred.

https://lore.kernel.org/linux-arm-kernel/1a94cccd-d871-1824-9fad-a8f7b99bb02a at arm.com/
 
> 
>> +
>> +	/*
>> +	 * Prohibit branch record generation while we are in guest.
>> +	 * Since access to BRBCR_EL1 is trapped, the guest can't
>> +	 * modify the filtering set by the host.
>> +	 */
>> +	write_sysreg_s(0, SYS_BRBCR_EL1);
>> +	isb();
> 
> What is the point of this ISB? We're at EL2, and this only affects
> EL1.

Makes sense, will drop this isb().

> 
>> +}
>> +
>> +static void __debug_restore_brbe(struct kvm_cpu_context *host_ctxt)
>> +{
>> +	if (!ctxt_sys_reg(host_ctxt, BRBCR_EL1))
>> +		return;
> 
> So on one side you're using a flag, and on the other you're using the
> *value*. You need some consistency.

Both DEBUG_STATE_SAVE_BRBE flag and BRBCR_EL1 value is checked on both save
and restore side.

__debug_save_host_buffers_nvhe()
	vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_BRBE)
		__debug_save_brbe(host_ctxt)
			Save BRBE but reset if BRBE is running

__debug_restore_host_buffers_nvhe()
	vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_BRBE)
		__debug_restore_brbe(host_ctxt)
			Restore when saved BRBCR_EL1 is positive

> 
>> +
>> +	/* Restore BRBE controls */
>> +	write_sysreg_s(ctxt_sys_reg(host_ctxt, BRBCR_EL1), SYS_BRBCR_EL1);
>> +	isb();
> 
> Same question.
> 
>> +}
>> +
>>  void __debug_save_host_buffers_nvhe(struct kvm_cpu_context *host_ctxt,
>>  				    struct kvm_cpu_context *guest_ctxt)
>>  {
>> @@ -102,6 +129,10 @@ void __debug_save_host_buffers_nvhe(struct kvm_cpu_context *host_ctxt,
>>  
>>  	if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_TRFCR))
>>  		__debug_save_trace(host_ctxt, guest_ctxt);
>> +
>> +	/* Disable BRBE branch records */
>> +	if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_BRBE))
>> +		__debug_save_brbe(host_ctxt);
>>  }
>>  
>>  void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
>> @@ -116,6 +147,8 @@ void __debug_restore_host_buffers_nvhe(struct kvm_cpu_context *host_ctxt,
>>  		__debug_restore_spe(host_ctxt);
>>  	if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_TRFCR))
>>  		__debug_restore_trace(host_ctxt, guest_ctxt);
>> +	if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_BRBE))
>> +		__debug_restore_brbe(host_ctxt);
>>  }
>>  
>>  void __debug_switch_to_host(struct kvm_vcpu *vcpu)
> 
> The lifetime of this flag seems bogus, specially when there is nothing
> to do, which will always be the arch-majority of the executions.

Not sure if I follow your point, could you please be more specific here ?

DEBUG_STATE_SAVE_BRBE follows all existing register state context save/restore
mechanism such as DEBUG_STATE_SAVE_SPE and DEBUG_STATE_SAVE_TRFCR. How is this
any different or problematic ?


From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:29 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:29 +0800
Subject: [PATCH v3 14/14] ARM: dts: aspeed: yosemite4: Revise gpio name
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-15-Delphine_CC_Chiu@wiwynn.com>

Revise gpio name for EVT schematic changes

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
Changelog:
  - v3
    - Correct patch for revising gpio name
  - v2
    - Add patch for revising gpio name
---
 .../dts/aspeed/aspeed-bmc-facebook-yosemite4.dts   | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index fdc33bffd467..8b258b128cfe 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1414,7 +1414,7 @@ &pinctrl_gpiu4_default &pinctrl_gpiu5_default
 	/*B0-B7*/       "FLT_HSC_SERVER_SLOT8_N","AC_ON_OFF_BTN_CPLD_SLOT5_N",
 			"PWRGD_SLOT1_STBY","PWRGD_SLOT2_STBY",
 			"PWRGD_SLOT3_STBY","PWRGD_SLOT4_STBY","","",
-	/*C0-C7*/       "PRSNT_NIC3_N","","","","FM_NIC0_WAKE_N",
+	/*C0-C7*/       "","","","","FM_NIC0_WAKE_N",
 			"FM_NIC1_WAKE_N","","RST_PCIE_SLOT2_N",
 	/*D0-D7*/       "","","","","","","","",
 	/*E0-E7*/       "PRSNT_NIC1_N","PRSNT_NIC2_N","","RST_PCIE_SLOT1_N",
@@ -1432,16 +1432,15 @@ &pinctrl_gpiu4_default &pinctrl_gpiu5_default
 	/*K0-K7*/       "","","","","","","","",
 	/*L0-L7*/       "","","","","","","ALT_MEDUSA_P12V_EFUSE_N","",
 	/*M0-M7*/       "EN_NIC0_POWER_BMC_R","EN_NIC1_POWER_BMC_R",
-			"INT_MEDUSA_IOEXP_TEMP_N","FLT_P12V_NIC0_N",
+			"INT_MEDUSA_IOEXP_TEMP_N","PRSNT_NIC3_N",
 			"INT_SMB_BMC_SLOT1_4_BMC_N",
 			"AC_ON_OFF_BTN_CPLD_SLOT6_N","","",
 	/*N0-N7*/       "FLT_HSC_SERVER_SLOT1_N","FLT_HSC_SERVER_SLOT2_N",
 			"FLT_HSC_SERVER_SLOT3_N","FLT_HSC_SERVER_SLOT4_N",
-			"FM_BMC_READY_R2","FLT_P12V_STBY_BMC_N","","",
+			"FM_BMC_READY_R2","RST_SMB_NIC0_R_N","","",
 	/*O0-O7*/       "AC_ON_OFF_BTN_CPLD_SLOT8_N","RST_SMB_NIC1_R_N",
 			"RST_SMB_NIC2_R_N","RST_SMB_NIC3_R_N",
-			"FLT_P3V3_NIC2_N","FLT_P3V3_NIC3_N",
-			"","",
+			"","","","",
 	/*P0-P7*/       "ALT_SMB_BMC_CPLD1_N","'BTN_BMC_R2_N",
 			"EN_P3V_BAT_SCALED_R","PWRGD_P5V_USB_BMC",
 			"FM_BMC_RTCRST_R","RST_USB_HUB_R_N",
@@ -1459,9 +1458,8 @@ &pinctrl_gpiu4_default &pinctrl_gpiu5_default
 			"","ALT_P12V_AUX_N","FAST_PROCHOT_N",
 			"SPI_WP_DISABLE_STATUS_R_N",
 	/*T0-T7*/       "","","","","","","","",
-	/*U0-U7*/       "","","FLT_P3V3_NIC1_N","FLT_P12V_NIC1_N",
-			"FLT_P12V_NIC2_N","FLT_P12V_NIC3_N",
-			"FLT_P3V3_NIC0_N","",
+	/*U0-U7*/       "","","RST_PCIE_SLOT3_N","",
+			"","PRSNT_NIC0_N","","",
 	/*V0-V7*/       "FM_RESBTN_SLOT5_BMC_N","FM_RESBTN_SLOT6_BMC_N",
 			"FM_RESBTN_SLOT7_BMC_N","FM_RESBTN_SLOT8_BMC_N",
 			"","","","",
-- 
2.25.1



From Delphine_CC_Chiu at wiwynn.com  Sun Dec 10 21:47:25 2023
From: Delphine_CC_Chiu at wiwynn.com (Delphine CC Chiu)
Date: Mon, 11 Dec 2023 13:47:25 +0800
Subject: [PATCH v3 10/14] ARM: dts: aspeed: yosemite4: Initialize bmc gpio state
In-Reply-To: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <20231211054730.208588-11-Delphine_CC_Chiu@wiwynn.com>

Initialize bmc gpio state

Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 195 ++++++++++++++++++
 1 file changed, 195 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index ed2b1200603d..eb3687bfd632 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -1271,6 +1271,7 @@ temperature-sensor at 1f {
 	};
 };
 
+
 &adc0 {
 	ref_voltage = <2500>;
 	status = "okay";
@@ -1298,3 +1299,197 @@ &ehci1 {
 &uhci {
 	status = "okay";
 };
+
+&sgpiom0 {
+	status = "okay";
+	ngpios = <128>;
+	bus-frequency = <48000>;
+};
+
+&gpio0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpiu2_default &pinctrl_gpiu3_default
+		     &pinctrl_gpiu4_default &pinctrl_gpiu5_default
+		     &pinctrl_gpiu6_default>;
+	gpio-line-names =
+	/*A0-A7*/       "","","","","","","","",
+	/*B0-B7*/       "FLT_HSC_SERVER_SLOT8_N","AC_ON_OFF_BTN_CPLD_SLOT5_N",
+			"PWRGD_SLOT1_STBY","PWRGD_SLOT2_STBY",
+			"PWRGD_SLOT3_STBY","PWRGD_SLOT4_STBY","","",
+	/*C0-C7*/       "PRSNT_NIC3_N","","","","FM_NIC0_WAKE_N",
+			"FM_NIC1_WAKE_N","","RST_PCIE_SLOT2_N",
+	/*D0-D7*/       "","","","","","","","",
+	/*E0-E7*/       "PRSNT_NIC1_N","PRSNT_NIC2_N","","RST_PCIE_SLOT1_N",
+			"","","","",
+	/*F0-F7*/       "FM_RESBTN_SLOT1_BMC_N","FM_RESBTN_SLOT2_BMC_N",
+			"FM_RESBTN_SLOT3_BMC_N","FM_RESBTN_SLOT4_BMC_N",
+			"PRSNT_SB_SLOT1_N","PRSNT_SB_SLOT2_N",
+			"PRSNT_SB_SLOT3_N","PRSNT_SB_SLOT4_N",
+	/*G0-G7*/       "","","","","","","","",
+	/*H0-H7*/       "","","","","","","","",
+	/*I0-I7*/       "","","","","","ALT_MEDUSA_ADC_N",
+			"ALT_SMB_BMC_CPLD2_N",
+			"INT_SPIDER_ADC_R_N",
+	/*J0-J7*/       "","","","","","","","",
+	/*K0-K7*/       "","","","","","","","",
+	/*L0-L7*/       "","","","","","","ALT_MEDUSA_P12V_EFUSE_N","",
+	/*M0-M7*/       "EN_NIC0_POWER_BMC_R","EN_NIC1_POWER_BMC_R",
+			"INT_MEDUSA_IOEXP_TEMP_N","FLT_P12V_NIC0_N",
+			"INT_SMB_BMC_SLOT1_4_BMC_N",
+			"AC_ON_OFF_BTN_CPLD_SLOT6_N","","",
+	/*N0-N7*/       "FLT_HSC_SERVER_SLOT1_N","FLT_HSC_SERVER_SLOT2_N",
+			"FLT_HSC_SERVER_SLOT3_N","FLT_HSC_SERVER_SLOT4_N",
+			"FM_BMC_READY_R2","FLT_P12V_STBY_BMC_N","","",
+	/*O0-O7*/       "AC_ON_OFF_BTN_CPLD_SLOT8_N","RST_SMB_NIC1_R_N",
+			"RST_SMB_NIC2_R_N","RST_SMB_NIC3_R_N",
+			"FLT_P3V3_NIC2_N","FLT_P3V3_NIC3_N",
+			"","",
+	/*P0-P7*/       "ALT_SMB_BMC_CPLD1_N","'BTN_BMC_R2_N",
+			"EN_P3V_BAT_SCALED_R","PWRGD_P5V_USB_BMC",
+			"FM_BMC_RTCRST_R","RST_USB_HUB_R_N",
+			"FLAG_P5V_USB_BMC_N","",
+	/*Q0-Q7*/       "AC_ON_OFF_BTN_CPLD_SLOT1_N","AC_ON_OFF_BTN_CPLD_SLOT2_N",
+			"AC_ON_OFF_BTN_CPLD_SLOT3_N","AC_ON_OFF_BTN_CPLD_SLOT4_N",
+			"PRSNT_SB_SLOT5_N","PRSNT_SB_SLOT6_N",
+			"PRSNT_SB_SLOT7_N","PRSNT_SB_SLOT8_N",
+	/*R0-R7*/       "AC_ON_OFF_BTN_CPLD_SLOT7_N","INT_SMB_BMC_SLOT5_8_BMC_N",
+			"FM_PWRBRK_NIC_BMC_R2","RST_PCIE_SLOT4_N",
+			"RST_PCIE_SLOT5_N","RST_PCIE_SLOT6_N",
+			"RST_PCIE_SLOT7_N","RST_PCIE_SLOT8_N",
+	/*S0-S7*/       "FM_NIC2_WAKE_N","FM_NIC3_WAKE_N",
+			"EN_NIC3_POWER_BMC_R","SEL_BMC_JTAG_MUX_R",
+			"","ALT_P12V_AUX_N","FAST_PROCHOT_N",
+			"SPI_WP_DISABLE_STATUS_R_N",
+	/*T0-T7*/       "","","","","","","","",
+	/*U0-U7*/       "","","FLT_P3V3_NIC1_N","FLT_P12V_NIC1_N",
+			"FLT_P12V_NIC2_N","FLT_P12V_NIC3_N",
+			"FLT_P3V3_NIC0_N","",
+	/*V0-V7*/       "FM_RESBTN_SLOT5_BMC_N","FM_RESBTN_SLOT6_BMC_N",
+			"FM_RESBTN_SLOT7_BMC_N","FM_RESBTN_SLOT8_BMC_N",
+			"","","","",
+	/*W0-W7*/       "PRSNT_TPM_BMC_N","PRSNT_OCP_DEBUG_BMC_N","ALT_TEMP_BMC_N","ALT_RTC_BMC_N",
+			"","","","",
+	/*X0-X7*/       "","LT_HSC_SERVER_SLOT6_N","FLT_HSC_SERVER_SLOT7_N","","","",
+			"PWRGD_SLOT5_STBY","PWRGD_SLOT6_STBY",
+	/*Y0-Y7*/       "","","SPI_LOCK_REQ_BMC_N","PWRGD_SLOT7_STBY",
+			"","","EN_NIC2_POWER_BMC_R","",
+	/*Z0-Z7*/       "EN_P5V_USB_CPLD_R","'FLT_HSC_SERVER_SLOT5_N",
+			"PWRGD_SLOT8_STBY","","","","","";
+
+	pin_gpio_b4 {
+		gpios = <ASPEED_GPIO(B, 4) GPIO_ACTIVE_HIGH>;
+		input;
+	};
+	pin_gpio_b5 {
+		gpios = <ASPEED_GPIO(B, 5) GPIO_ACTIVE_HIGH>;
+		input;
+	};
+	pin_gpio_f0 {
+		gpios = <ASPEED_GPIO(F, 0) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f1 {
+		gpios = <ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f2 {
+		gpios = <ASPEED_GPIO(F, 2) GPIO_ACTIVE_LOW>;
+		input;
+		};
+	pin_gpio_f3 {
+		gpios = <ASPEED_GPIO(F, 3) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f4 {
+		gpios = <ASPEED_GPIO(F, 4) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f5 {
+		gpios = <ASPEED_GPIO(F, 5) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f6 {
+		gpios = <ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_f7 {
+		gpios = <ASPEED_GPIO(F, 7) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_l6 {
+		gpios = <ASPEED_GPIO(L, 6) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_l7 {
+		gpios = <ASPEED_GPIO(L, 7) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_s0 {
+		gpios = <ASPEED_GPIO(S, 0) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_s1 {
+		gpios = <ASPEED_GPIO(S, 1) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_v0 {
+		gpios = <ASPEED_GPIO(V, 0) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_v1 {
+		gpios = <ASPEED_GPIO(V, 1) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_v2 {
+		gpios = <ASPEED_GPIO(V, 2) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_v3 {
+		gpios = <ASPEED_GPIO(V, 3) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w0 {
+		gpios = <ASPEED_GPIO(W, 0) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w1 {
+		gpios = <ASPEED_GPIO(W, 1) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w2 {
+		gpios = <ASPEED_GPIO(W, 2) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w3 {
+		gpios = <ASPEED_GPIO(W, 3) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w4 {
+		gpios = <ASPEED_GPIO(W, 4) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w5 {
+		gpios = <ASPEED_GPIO(W, 5) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w6 {
+		gpios = <ASPEED_GPIO(W, 6) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_w7 {
+		gpios = <ASPEED_GPIO(W, 7) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_z3 {
+		gpios = <ASPEED_GPIO(Z, 3) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_z4 {
+		gpios = <ASPEED_GPIO(Z, 4) GPIO_ACTIVE_LOW>;
+		input;
+	};
+	pin_gpio_z5 {
+		gpios = <ASPEED_GPIO(Z, 5) GPIO_ACTIVE_LOW>;
+		input;
+	};
+};
-- 
2.25.1



From 21cnbao at gmail.com  Sun Dec 10 22:04:55 2023
From: 21cnbao at gmail.com (Barry Song)
Date: Mon, 11 Dec 2023 19:04:55 +1300
Subject: [PATCH v2] arm64: mm: swap: support THP_SWAP on hardware with MTE
Message-ID: <20231211060455.101067-1-v-songbaohua@oppo.com>

Commit d0637c505f8a1 ("arm64: enable THP_SWAP for arm64") brings up
THP_SWAP on ARM64, but it doesn't enable THP_SWP on hardware with
MTE as the MTE code works with the assumption tags save/restore is
always handling a folio with only one page.

The limitation should be removed as more and more ARM64 SoCs have
this feature. Co-existence of MTE and THP_SWAP becomes more and
more important.

This patch makes MTE tags saving support large folios, then we don't
need to split large folios into base pages for swapping out on ARM64
SoCs with MTE any more.

arch_prepare_to_swap() should take folio rather than page as parameter
because we support THP swap-out as a whole. It saves tags for all
pages in a large folio.

As now we are restoring tags based-on folio, in arch_swap_restore(),
we may increase some extra loops and early-exitings while refaulting
a large folio which is still in swapcache in do_swap_page(). In case
a large folio has nr pages, do_swap_page() will only set the PTE of
the particular page which is causing the page fault.
Thus do_swap_page() runs nr times, and each time, arch_swap_restore()
will loop nr times for those subpages in the folio. So right now the
algorithmic complexity becomes O(nr^2).

Once we support mapping large folios in do_swap_page(), extra loops
and early-exitings will decrease while not being completely removed
as a large folio might get partially tagged in corner cases such as,
1. a large folio in swapcache can be partially unmapped, thus, MTE
tags for the unmapped pages will be invalidated;
2. users might use mprotect() to set MTEs on a part of a large folio.

arch_thp_swp_supported() is dropped since ARM64 MTE was the only one
who needed it.

Reviewed-by: Steven Price <steven.price at arm.com>
Signed-off-by: Barry Song <v-songbaohua at oppo.com>
---
 -v2:
  let arch_swap_restore() still use folio as the parameter with respect
  to the comments of Matthew and David;
 -v1:
  collected reviewed-by from Steven;
  refine commit log;
  https://lore.kernel.org/linux-mm/20231208073401.70153-1-v-songbaohua at oppo.com/
 -rfc v3:
   https://lore.kernel.org/linux-mm/20231114014313.67232-1-v-songbaohua at oppo.com/
 -rfc v2:
   https://lore.kernel.org/lkml/20231104093423.170054-1-v-songbaohua at oppo.com/
 -rfc v1:
   https://lore.kernel.org/lkml/20231102223643.7733-1-v-songbaohua at oppo.com/

 arch/arm64/include/asm/pgtable.h | 21 +++-------------
 arch/arm64/mm/mteswap.c          | 42 ++++++++++++++++++++++++++++++++
 include/linux/huge_mm.h          | 12 ---------
 include/linux/pgtable.h          |  2 +-
 mm/page_io.c                     |  2 +-
 mm/swap_slots.c                  |  2 +-
 6 files changed, 49 insertions(+), 32 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b19a8aee684c..d8f523dc41e7 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -45,12 +45,6 @@
 	__flush_tlb_range(vma, addr, end, PUD_SIZE, false, 1)
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
-static inline bool arch_thp_swp_supported(void)
-{
-	return !system_supports_mte();
-}
-#define arch_thp_swp_supported arch_thp_swp_supported
-
 /*
  * Outside of a few very special situations (e.g. hibernation), we always
  * use broadcast TLB invalidation instructions, therefore a spurious page
@@ -1036,12 +1030,8 @@ static inline pmd_t pmdp_establish(struct vm_area_struct *vma,
 #ifdef CONFIG_ARM64_MTE
 
 #define __HAVE_ARCH_PREPARE_TO_SWAP
-static inline int arch_prepare_to_swap(struct page *page)
-{
-	if (system_supports_mte())
-		return mte_save_tags(page);
-	return 0;
-}
+#define arch_prepare_to_swap arch_prepare_to_swap
+extern int arch_prepare_to_swap(struct folio *folio);
 
 #define __HAVE_ARCH_SWAP_INVALIDATE
 static inline void arch_swap_invalidate_page(int type, pgoff_t offset)
@@ -1057,11 +1047,8 @@ static inline void arch_swap_invalidate_area(int type)
 }
 
 #define __HAVE_ARCH_SWAP_RESTORE
-static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
-{
-	if (system_supports_mte())
-		mte_restore_tags(entry, &folio->page);
-}
+#define arch_swap_restore arch_swap_restore
+extern void arch_swap_restore(swp_entry_t entry, struct folio *folio);
 
 #endif /* CONFIG_ARM64_MTE */
 
diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
index a31833e3ddc5..b9ca1b35902f 100644
--- a/arch/arm64/mm/mteswap.c
+++ b/arch/arm64/mm/mteswap.c
@@ -68,6 +68,13 @@ void mte_invalidate_tags(int type, pgoff_t offset)
 	mte_free_tag_storage(tags);
 }
 
+static inline void __mte_invalidate_tags(struct page *page)
+{
+	swp_entry_t entry = page_swap_entry(page);
+
+	mte_invalidate_tags(swp_type(entry), swp_offset(entry));
+}
+
 void mte_invalidate_tags_area(int type)
 {
 	swp_entry_t entry = swp_entry(type, 0);
@@ -83,3 +90,38 @@ void mte_invalidate_tags_area(int type)
 	}
 	xa_unlock(&mte_pages);
 }
+
+int arch_prepare_to_swap(struct folio *folio)
+{
+	int err;
+	long i;
+
+	if (system_supports_mte()) {
+		long nr = folio_nr_pages(folio);
+
+		for (i = 0; i < nr; i++) {
+			err = mte_save_tags(folio_page(folio, i));
+			if (err)
+				goto out;
+		}
+	}
+	return 0;
+
+out:
+	while (i--)
+		__mte_invalidate_tags(folio_page(folio, i));
+	return err;
+}
+
+void arch_swap_restore(swp_entry_t entry, struct folio *folio)
+{
+	if (system_supports_mte()) {
+		long i, nr = folio_nr_pages(folio);
+
+		entry.val -= swp_offset(entry) & (nr - 1);
+		for (i = 0; i < nr; i++) {
+			mte_restore_tags(entry, folio_page(folio, i));
+			entry.val++;
+		}
+	}
+}
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index fa0350b0812a..f83fb8d5241e 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -400,16 +400,4 @@ static inline int split_folio(struct folio *folio)
 	return split_folio_to_list(folio, NULL);
 }
 
-/*
- * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to
- * limitations in the implementation like arm64 MTE can override this to
- * false
- */
-#ifndef arch_thp_swp_supported
-static inline bool arch_thp_swp_supported(void)
-{
-	return true;
-}
-#endif
-
 #endif /* _LINUX_HUGE_MM_H */
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index af7639c3b0a3..33ab4ddd91dd 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -897,7 +897,7 @@ static inline int arch_unmap_one(struct mm_struct *mm,
  * prototypes must be defined in the arch-specific asm/pgtable.h file.
  */
 #ifndef __HAVE_ARCH_PREPARE_TO_SWAP
-static inline int arch_prepare_to_swap(struct page *page)
+static inline int arch_prepare_to_swap(struct folio *folio)
 {
 	return 0;
 }
diff --git a/mm/page_io.c b/mm/page_io.c
index cb559ae324c6..0fd832474c1d 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -189,7 +189,7 @@ int swap_writepage(struct page *page, struct writeback_control *wbc)
 	 * Arch code may have to preserve more data than just the page
 	 * contents, e.g. memory tags.
 	 */
-	ret = arch_prepare_to_swap(&folio->page);
+	ret = arch_prepare_to_swap(folio);
 	if (ret) {
 		folio_mark_dirty(folio);
 		folio_unlock(folio);
diff --git a/mm/swap_slots.c b/mm/swap_slots.c
index 0bec1f705f8e..2325adbb1f19 100644
--- a/mm/swap_slots.c
+++ b/mm/swap_slots.c
@@ -307,7 +307,7 @@ swp_entry_t folio_alloc_swap(struct folio *folio)
 	entry.val = 0;
 
 	if (folio_test_large(folio)) {
-		if (IS_ENABLED(CONFIG_THP_SWAP) && arch_thp_swp_supported())
+		if (IS_ENABLED(CONFIG_THP_SWAP))
 			get_swap_pages(1, &entry, folio_nr_pages(folio));
 		goto out;
 	}
-- 
2.34.1



From 0x1207 at gmail.com  Sun Dec 10 22:08:28 2023
From: 0x1207 at gmail.com (Furong Xu)
Date: Mon, 11 Dec 2023 14:08:28 +0800
Subject: [PATCH net-next v1] net: stmmac: mmc: Support more counters for XGMAC Core
Message-ID: <20231211060828.1629247-1-0x1207@gmail.com>

Complete all counters on XGMAC Core.
These can be useful for debugging.

Signed-off-by: Furong Xu <0x1207 at gmail.com>
---
 drivers/net/ethernet/stmicro/stmmac/mmc.h     |  14 +++
 .../net/ethernet/stmicro/stmmac/mmc_core.c    | 117 +++++++++++++++++-
 .../ethernet/stmicro/stmmac/stmmac_ethtool.c  |  10 ++
 3 files changed, 140 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc.h b/drivers/net/ethernet/stmicro/stmmac/mmc.h
index a0c05925883e..14c9d2637dfe 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc.h
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc.h
@@ -52,6 +52,8 @@ struct stmmac_counters {
 	unsigned int mmc_tx_excessdef;
 	unsigned int mmc_tx_pause_frame;
 	unsigned int mmc_tx_vlan_frame_g;
+	unsigned int mmc_tx_lpi_usec;
+	unsigned int mmc_tx_lpi_tran;
 
 	/* MMC RX counter registers */
 	unsigned int mmc_rx_framecount_gb;
@@ -78,9 +80,16 @@ struct stmmac_counters {
 	unsigned int mmc_rx_fifo_overflow;
 	unsigned int mmc_rx_vlan_frames_gb;
 	unsigned int mmc_rx_watchdog_error;
+	unsigned int mmc_rx_lpi_usec;
+	unsigned int mmc_rx_lpi_tran;
+	unsigned int mmc_rx_discard_frames_gb;
+	unsigned int mmc_rx_discard_octets_gb;
+	unsigned int mmc_rx_align_err_frames;
+
 	/* IPC */
 	unsigned int mmc_rx_ipc_intr_mask;
 	unsigned int mmc_rx_ipc_intr;
+
 	/* IPv4 */
 	unsigned int mmc_rx_ipv4_gd;
 	unsigned int mmc_rx_ipv4_hderr;
@@ -118,9 +127,14 @@ struct stmmac_counters {
 	unsigned int mmc_rx_icmp_gd_octets;
 	unsigned int mmc_rx_icmp_err_octets;
 
+	/* Stream-Gate Filter */
+	unsigned int mmc_sgf_pass_fragment_cntr;
+	unsigned int mmc_sgf_fail_fragment_cntr;
+
 	/* FPE */
 	unsigned int mmc_tx_fpe_fragment_cntr;
 	unsigned int mmc_tx_hold_req_cntr;
+	unsigned int mmc_tx_gate_overrun_cntr;
 	unsigned int mmc_rx_packet_assembly_err_cntr;
 	unsigned int mmc_rx_packet_smd_err_cntr;
 	unsigned int mmc_rx_packet_assembly_ok_cntr;
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index 6a7c1d325c46..8597c6abae8d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
@@ -177,9 +177,12 @@
 #define MMC_XGMAC_RX_DISCARD_OCT_GB	0x1b4
 #define MMC_XGMAC_RX_ALIGN_ERR_PKT	0x1bc
 
+#define MMC_XGMAC_SGF_PASS_PKT		0x1f0
+#define MMC_XGMAC_SGF_FAIL_PKT		0x1f4
 #define MMC_XGMAC_TX_FPE_INTR_MASK	0x204
 #define MMC_XGMAC_TX_FPE_FRAG		0x208
 #define MMC_XGMAC_TX_HOLD_REQ		0x20c
+#define MMC_XGMAC_TX_GATE_OVERRUN	0x210
 #define MMC_XGMAC_RX_FPE_INTR_MASK	0x224
 #define MMC_XGMAC_RX_PKT_ASSEMBLY_ERR	0x228
 #define MMC_XGMAC_RX_PKT_SMD_ERR	0x22c
@@ -187,6 +190,40 @@
 #define MMC_XGMAC_RX_FPE_FRAG		0x234
 #define MMC_XGMAC_RX_IPC_INTR_MASK	0x25c
 
+#define MMC_XGMAC_RX_IPV4_GD		0x264
+#define MMC_XGMAC_RX_IPV4_HDERR		0x26c
+#define MMC_XGMAC_RX_IPV4_NOPAY		0x274
+#define MMC_XGMAC_RX_IPV4_FRAG		0x27c
+#define MMC_XGMAC_RX_IPV4_UDSBL		0x284
+
+#define MMC_XGMAC_RX_IPV6_GD		0x28c
+#define MMC_XGMAC_RX_IPV6_HDERR		0x294
+#define MMC_XGMAC_RX_IPV6_NOPAY		0x29c
+
+#define MMC_XGMAC_RX_UDP_GD		0x2a4
+#define MMC_XGMAC_RX_UDP_ERR		0x2ac
+#define MMC_XGMAC_RX_TCP_GD		0x2b4
+#define MMC_XGMAC_RX_TCP_ERR		0x2bc
+#define MMC_XGMAC_RX_ICMP_GD		0x2c4
+#define MMC_XGMAC_RX_ICMP_ERR		0x2cc
+
+#define MMC_XGMAC_RX_IPV4_GD_OCTETS	0x2d4
+#define MMC_XGMAC_RX_IPV4_HDERR_OCTETS	0x2dc
+#define MMC_XGMAC_RX_IPV4_NOPAY_OCTETS	0x2e4
+#define MMC_XGMAC_RX_IPV4_FRAG_OCTETS	0x2ec
+#define MMC_XGMAC_RX_IPV4_UDSBL_OCTETS	0x2f4
+
+#define MMC_XGMAC_RX_IPV6_GD_OCTETS	0x2fc
+#define MMC_XGMAC_RX_IPV6_HDERR_OCTETS	0x304
+#define MMC_XGMAC_RX_IPV6_NOPAY_OCTETS	0x30c
+
+#define MMC_XGMAC_RX_UDP_GD_OCTETS	0x314
+#define MMC_XGMAC_RX_UDP_ERR_OCTETS	0x31c
+#define MMC_XGMAC_RX_TCP_GD_OCTETS	0x324
+#define MMC_XGMAC_RX_TCP_ERR_OCTETS	0x32c
+#define MMC_XGMAC_RX_ICMP_GD_OCTETS	0x334
+#define MMC_XGMAC_RX_ICMP_ERR_OCTETS	0x33c
+
 static void dwmac_mmc_ctrl(void __iomem *mmcaddr, unsigned int mode)
 {
 	u32 value = readl(mmcaddr + MMC_CNTRL);
@@ -414,6 +451,8 @@ static void dwxgmac_mmc_read(void __iomem *mmcaddr, struct stmmac_counters *mmc)
 			     &mmc->mmc_tx_pause_frame);
 	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_TX_VLAN_PKT_G,
 			     &mmc->mmc_tx_vlan_frame_g);
+	mmc->mmc_tx_lpi_usec += readl(mmcaddr + MMC_XGMAC_TX_LPI_USEC);
+	mmc->mmc_tx_lpi_tran += readl(mmcaddr + MMC_XGMAC_TX_LPI_TRAN);
 
 	/* MMC RX counter registers */
 	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_PKT_GB,
@@ -459,9 +498,23 @@ static void dwxgmac_mmc_read(void __iomem *mmcaddr, struct stmmac_counters *mmc)
 	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_VLAN_PKT_GB,
 			     &mmc->mmc_rx_vlan_frames_gb);
 	mmc->mmc_rx_watchdog_error += readl(mmcaddr + MMC_XGMAC_RX_WATCHDOG_ERR);
-
+	mmc->mmc_rx_lpi_usec += readl(mmcaddr + MMC_XGMAC_RX_LPI_USEC);
+	mmc->mmc_rx_lpi_tran += readl(mmcaddr + MMC_XGMAC_RX_LPI_TRAN);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_DISCARD_PKT_GB,
+			     &mmc->mmc_rx_discard_frames_gb);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_DISCARD_OCT_GB,
+			     &mmc->mmc_rx_discard_octets_gb);
+	mmc->mmc_rx_align_err_frames +=
+		readl(mmcaddr + MMC_XGMAC_RX_ALIGN_ERR_PKT);
+
+	mmc->mmc_sgf_pass_fragment_cntr +=
+		readl(mmcaddr + MMC_XGMAC_SGF_PASS_PKT);
+	mmc->mmc_sgf_fail_fragment_cntr +=
+		readl(mmcaddr + MMC_XGMAC_SGF_FAIL_PKT);
 	mmc->mmc_tx_fpe_fragment_cntr += readl(mmcaddr + MMC_XGMAC_TX_FPE_FRAG);
 	mmc->mmc_tx_hold_req_cntr += readl(mmcaddr + MMC_XGMAC_TX_HOLD_REQ);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_TX_GATE_OVERRUN,
+			     &mmc->mmc_tx_gate_overrun_cntr);
 	mmc->mmc_rx_packet_assembly_err_cntr +=
 		readl(mmcaddr + MMC_XGMAC_RX_PKT_ASSEMBLY_ERR);
 	mmc->mmc_rx_packet_smd_err_cntr +=
@@ -470,6 +523,68 @@ static void dwxgmac_mmc_read(void __iomem *mmcaddr, struct stmmac_counters *mmc)
 		readl(mmcaddr + MMC_XGMAC_RX_PKT_ASSEMBLY_OK);
 	mmc->mmc_rx_fpe_fragment_cntr +=
 		readl(mmcaddr + MMC_XGMAC_RX_FPE_FRAG);
+
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_GD,
+			     &mmc->mmc_rx_ipv4_gd);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_HDERR,
+			     &mmc->mmc_rx_ipv4_hderr);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_NOPAY,
+			     &mmc->mmc_rx_ipv4_nopay);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_FRAG,
+			     &mmc->mmc_rx_ipv4_frag);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_UDSBL,
+			     &mmc->mmc_rx_ipv4_udsbl);
+
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV6_GD,
+			     &mmc->mmc_rx_ipv6_gd);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV6_HDERR,
+			     &mmc->mmc_rx_ipv6_hderr);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV6_NOPAY,
+			     &mmc->mmc_rx_ipv6_nopay);
+
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_UDP_GD,
+			     &mmc->mmc_rx_udp_gd);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_UDP_ERR,
+			     &mmc->mmc_rx_udp_err);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_TCP_GD,
+			     &mmc->mmc_rx_tcp_gd);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_TCP_ERR,
+			     &mmc->mmc_rx_tcp_err);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_ICMP_GD,
+			     &mmc->mmc_rx_icmp_gd);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_ICMP_ERR,
+			     &mmc->mmc_rx_icmp_err);
+
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_GD_OCTETS,
+			     &mmc->mmc_rx_ipv4_gd_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_HDERR_OCTETS,
+			     &mmc->mmc_rx_ipv4_hderr_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_NOPAY_OCTETS,
+			     &mmc->mmc_rx_ipv4_nopay_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_FRAG_OCTETS,
+			     &mmc->mmc_rx_ipv4_frag_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV4_UDSBL_OCTETS,
+			     &mmc->mmc_rx_ipv4_udsbl_octets);
+
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV6_GD_OCTETS,
+			     &mmc->mmc_rx_ipv6_gd_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV6_HDERR_OCTETS,
+			     &mmc->mmc_rx_ipv6_hderr_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_IPV6_NOPAY_OCTETS,
+			     &mmc->mmc_rx_ipv6_nopay_octets);
+
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_UDP_GD_OCTETS,
+			     &mmc->mmc_rx_udp_gd_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_UDP_ERR_OCTETS,
+			     &mmc->mmc_rx_udp_err_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_TCP_GD_OCTETS,
+			     &mmc->mmc_rx_tcp_gd_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_TCP_ERR_OCTETS,
+			     &mmc->mmc_rx_tcp_err_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_ICMP_GD_OCTETS,
+			     &mmc->mmc_rx_icmp_gd_octets);
+	dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_ICMP_ERR_OCTETS,
+			     &mmc->mmc_rx_icmp_err_octets);
 }
 
 const struct stmmac_mmc_ops dwxgmac_mmc_ops = {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index f628411ae4ae..b9b80e0fceeb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -212,6 +212,8 @@ static const struct stmmac_stats stmmac_mmc[] = {
 	STMMAC_MMC_STAT(mmc_tx_excessdef),
 	STMMAC_MMC_STAT(mmc_tx_pause_frame),
 	STMMAC_MMC_STAT(mmc_tx_vlan_frame_g),
+	STMMAC_MMC_STAT(mmc_tx_lpi_usec),
+	STMMAC_MMC_STAT(mmc_tx_lpi_tran),
 	STMMAC_MMC_STAT(mmc_rx_framecount_gb),
 	STMMAC_MMC_STAT(mmc_rx_octetcount_gb),
 	STMMAC_MMC_STAT(mmc_rx_octetcount_g),
@@ -236,6 +238,11 @@ static const struct stmmac_stats stmmac_mmc[] = {
 	STMMAC_MMC_STAT(mmc_rx_fifo_overflow),
 	STMMAC_MMC_STAT(mmc_rx_vlan_frames_gb),
 	STMMAC_MMC_STAT(mmc_rx_watchdog_error),
+	STMMAC_MMC_STAT(mmc_rx_lpi_usec),
+	STMMAC_MMC_STAT(mmc_rx_lpi_tran),
+	STMMAC_MMC_STAT(mmc_rx_discard_frames_gb),
+	STMMAC_MMC_STAT(mmc_rx_discard_octets_gb),
+	STMMAC_MMC_STAT(mmc_rx_align_err_frames),
 	STMMAC_MMC_STAT(mmc_rx_ipc_intr_mask),
 	STMMAC_MMC_STAT(mmc_rx_ipc_intr),
 	STMMAC_MMC_STAT(mmc_rx_ipv4_gd),
@@ -266,8 +273,11 @@ static const struct stmmac_stats stmmac_mmc[] = {
 	STMMAC_MMC_STAT(mmc_rx_tcp_err_octets),
 	STMMAC_MMC_STAT(mmc_rx_icmp_gd_octets),
 	STMMAC_MMC_STAT(mmc_rx_icmp_err_octets),
+	STMMAC_MMC_STAT(mmc_sgf_pass_fragment_cntr),
+	STMMAC_MMC_STAT(mmc_sgf_fail_fragment_cntr),
 	STMMAC_MMC_STAT(mmc_tx_fpe_fragment_cntr),
 	STMMAC_MMC_STAT(mmc_tx_hold_req_cntr),
+	STMMAC_MMC_STAT(mmc_tx_gate_overrun_cntr),
 	STMMAC_MMC_STAT(mmc_rx_packet_assembly_err_cntr),
 	STMMAC_MMC_STAT(mmc_rx_packet_smd_err_cntr),
 	STMMAC_MMC_STAT(mmc_rx_packet_assembly_ok_cntr),
-- 
2.34.1



From Jianheng.Zhang at synopsys.com  Sun Dec 10 22:13:21 2023
From: Jianheng.Zhang at synopsys.com (Jianheng Zhang)
Date: Mon, 11 Dec 2023 06:13:21 +0000
Subject: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking support
Message-ID: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>

Adds the HW specific support for Frame Preemption handshaking on XGMAC3+
cores.

Signed-off-by: Jianheng Zhang <Jianheng.Zhang at synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h     |  6 ++
 .../net/ethernet/stmicro/stmmac/dwxgmac2_core.c    | 65 ++++++++++++++++++----
 2 files changed, 60 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 207ff17..306d15b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -194,6 +194,12 @@
 #define XGMAC_MDIO_DATA			0x00000204
 #define XGMAC_MDIO_C22P			0x00000220
 #define XGMAC_FPE_CTRL_STS		0x00000280
+#define XGMAC_TRSP			BIT(19)
+#define XGMAC_TVER			BIT(18)
+#define XGMAC_RRSP			BIT(17)
+#define XGMAC_RVER			BIT(16)
+#define XGMAC_SRSP			BIT(2)
+#define XGMAC_SVER			BIT(1)
 #define XGMAC_EFPE			BIT(0)
 #define XGMAC_ADDRx_HIGH(x)		(0x00000300 + (x) * 0x8)
 #define XGMAC_ADDR_MAX			32
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index eb48211..091d932 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -1439,22 +1439,63 @@ static void dwxgmac3_fpe_configure(void __iomem *ioaddr, struct stmmac_fpe_cfg *
 {
 	u32 value;
 
-	if (!enable) {
-		value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
+	if (enable) {
+		cfg->fpe_csr = XGMAC_EFPE;
+		value = readl(ioaddr + XGMAC_RXQ_CTRL1);
+		value &= ~XGMAC_RQ;
+		value |= (num_rxq - 1) << XGMAC_RQ_SHIFT;
+		writel(value, ioaddr + XGMAC_RXQ_CTRL1);
+	} else {
+		cfg->fpe_csr = 0;
+	}
+	writel(cfg->fpe_csr, ioaddr + XGMAC_FPE_CTRL_STS);
+}
 
-		value &= ~XGMAC_EFPE;
+static int dwxgmac3_fpe_irq_status(void __iomem *ioaddr, struct net_device *dev)
+{
+	u32 value;
+	int status;
 
-		writel(value, ioaddr + XGMAC_FPE_CTRL_STS);
-		return;
+	status = FPE_EVENT_UNKNOWN;
+
+	/* Reads from the XGMAC_FPE_CTRL_STS register should only be performed
+	 * here, since the status flags of MAC_FPE_CTRL_STS are "clear on read"
+	 */
+	value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
+
+	if (value & XGMAC_TRSP) {
+		status |= FPE_EVENT_TRSP;
+		netdev_info(dev, "FPE: Respond mPacket is transmitted\n");
 	}
 
-	value = readl(ioaddr + XGMAC_RXQ_CTRL1);
-	value &= ~XGMAC_RQ;
-	value |= (num_rxq - 1) << XGMAC_RQ_SHIFT;
-	writel(value, ioaddr + XGMAC_RXQ_CTRL1);
+	if (value & XGMAC_TVER) {
+		status |= FPE_EVENT_TVER;
+		netdev_info(dev, "FPE: Verify mPacket is transmitted\n");
+	}
+
+	if (value & XGMAC_RRSP) {
+		status |= FPE_EVENT_RRSP;
+		netdev_info(dev, "FPE: Respond mPacket is received\n");
+	}
+
+	if (value & XGMAC_RVER) {
+		status |= FPE_EVENT_RVER;
+		netdev_info(dev, "FPE: Verify mPacket is received\n");
+	}
+
+	return status;
+}
+
+static void dwxgmac3_fpe_send_mpacket(void __iomem *ioaddr, struct stmmac_fpe_cfg *cfg,
+				      enum stmmac_mpacket_type type)
+{
+	u32 value = cfg->fpe_csr;
+
+	if (type == MPACKET_VERIFY)
+		value |= XGMAC_SVER;
+	else if (type == MPACKET_RESPONSE)
+		value |= XGMAC_SRSP;
 
-	value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
-	value |= XGMAC_EFPE;
 	writel(value, ioaddr + XGMAC_FPE_CTRL_STS);
 }
 
@@ -1503,6 +1544,8 @@ static void dwxgmac3_fpe_configure(void __iomem *ioaddr, struct stmmac_fpe_cfg *
 	.config_l4_filter = dwxgmac2_config_l4_filter,
 	.set_arp_offload = dwxgmac2_set_arp_offload,
 	.fpe_configure = dwxgmac3_fpe_configure,
+	.fpe_send_mpacket = dwxgmac3_fpe_send_mpacket,
+	.fpe_irq_status = dwxgmac3_fpe_irq_status,
 };
 
 static void dwxlgmac2_rx_queue_enable(struct mac_device_info *hw, u8 mode,
-- 
1.8.3.1



From anshuman.khandual at arm.com  Sun Dec 10 22:34:05 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 11 Dec 2023 12:04:05 +0530
Subject: [PATCH V15 2/8] KVM: arm64: Prevent guest accesses into BRBE
 system registers/instructions
In-Reply-To: <86v89ebcn2.wl-maz@kernel.org>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
 <20231201053906.1261704-3-anshuman.khandual@arm.com>
 <86v89ebcn2.wl-maz@kernel.org>
Message-ID: <3ba53c71-114a-4ac9-b590-7332e97b6fc4@arm.com>



On 12/4/23 13:52, Marc Zyngier wrote:
> On Fri, 01 Dec 2023 05:39:00 +0000,
> Anshuman Khandual <anshuman.khandual at arm.com> wrote:
>> Currently BRBE feature is not supported in a guest environment. This hides
>> BRBE feature availability via masking ID_AA64DFR0_EL1.BRBE field. This also
>> blocks guest accesses into BRBE system registers and instructions as if the
>> underlying hardware never implemented FEAT_BRBE feature.
>>
>> Cc: Marc Zyngier <maz at kernel.org>
>> Cc: Oliver Upton <oliver.upton at linux.dev>
>> Cc: James Morse <james.morse at arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will at kernel.org>
>> Cc: kvmarm at lists.linux.dev
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>>  arch/arm64/kvm/sys_regs.c | 130 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 130 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 4735e1b37fb3..42701065b3cd 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -1583,6 +1583,9 @@ static u64 read_sanitised_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
>>  	/* Hide SPE from guests */
>>  	val &= ~ID_AA64DFR0_EL1_PMSVer_MASK;
>>  
>> +	/* Hide BRBE from guests */
>> +	val &= ~ID_AA64DFR0_EL1_BRBE_MASK;
>> +
>>  	return val;
>>  }
>>  
>> @@ -2042,6 +2045,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>  	{ SYS_DESC(SYS_DC_CISW), access_dcsw },
>>  	{ SYS_DESC(SYS_DC_CIGSW), access_dcgsw },
>>  	{ SYS_DESC(SYS_DC_CIGDSW), access_dcgsw },
>> +	{ SYS_DESC(OP_BRB_IALL), undef_access },
>> +	{ SYS_DESC(OP_BRB_INJ), undef_access },
>>  
>>  	DBG_BCR_BVR_WCR_WVR_EL1(0),
>>  	DBG_BCR_BVR_WCR_WVR_EL1(1),
>> @@ -2072,6 +2077,131 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>  	{ SYS_DESC(SYS_DBGCLAIMCLR_EL1), trap_raz_wi },
>>  	{ SYS_DESC(SYS_DBGAUTHSTATUS_EL1), trap_dbgauthstatus_el1 },
>>  
>> +	/*
>> +	 * BRBE branch record sysreg address space is interleaved between
>> +	 * corresponding BRBINF<N>_EL1, BRBSRC<N>_EL1, and BRBTGT<N>_EL1.
>> +	 */
>> +	{ SYS_DESC(SYS_BRBINF0_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBSRC0_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBTGT0_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBINF16_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBSRC16_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBTGT16_EL1), undef_access },
> Surely we can do better than this wall of text. Please look at what we
> do for the debug registers, and adopt a similar pattern. This should
> result in one line per group of 3 registers.

Sure, will these replace via the following macro.

+#define BRB_INF_SRC_TGT_EL1(n)                                 \
+       { SYS_DESC(SYS_BRBINF##n##_EL1), undef_access },        \
+       { SYS_DESC(SYS_BRBSRC##n##_EL1), undef_access },        \
+       { SYS_DESC(SYS_BRBTGT##n##_EL1), undef_access }         \
....
+       BRB_INF_SRC_TGT_EL1(0),
+       BRB_INF_SRC_TGT_EL1(16),
+       BRB_INF_SRC_TGT_EL1(1),
+       BRB_INF_SRC_TGT_EL1(17),
+       BRB_INF_SRC_TGT_EL1(2),
+       BRB_INF_SRC_TGT_EL1(18),
+       BRB_INF_SRC_TGT_EL1(3),
+       BRB_INF_SRC_TGT_EL1(19),
....


From amit.kumar-mahapatra at amd.com  Sun Dec 10 22:56:06 2023
From: amit.kumar-mahapatra at amd.com (Mahapatra, Amit Kumar)
Date: Mon, 11 Dec 2023 06:56:06 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
Message-ID: <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>



> -----Original Message-----
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> Sent: Monday, December 11, 2023 9:03 AM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> michael at walle.cc; linux-mtd at lists.infradead.org;
> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
> in spi-nor
> 
> 
> 
> On 12/8/23 17:05, Mahapatra, Amit Kumar wrote:
> > Hello Tudor,
> 
> Hi!

Hello Tudor,

> 
> >
> >> -----Original Message-----
> >> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> >> Sent: Wednesday, December 6, 2023 8:00 PM
> >> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> >> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> >> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> >> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> >> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> >> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> >> michael at walle.cc; linux-mtd at lists.infradead.org;
> >> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> >> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>;
> >> linux- arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> >> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> >> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> >> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories
> >> support in spi-nor
> >>
> >> Hi, Amit,
> >>
> >> On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
> >>> Each flash that is connected in stacked mode should have a separate
> >>> parameter structure. So, the flash parameter member(*params) of the
> >>> spi_nor structure is changed to an array (*params[2]). The array is
> >>> used to store the parameters of each flash connected in stacked
> >> configuration.
> >>>
> >>> The current implementation assumes that a maximum of two flashes are
> >>> connected in stacked mode and both the flashes are of same make but
> >>> can differ in sizes. So, except the sizes all other flash parameters
> >>> of both the flashes are identical.
> >>
> >> Do you plan to add support for different flashes in stacked mode? If
> >> not,
> >
> > No, according to the current implementation, in stacked mode, both
> > flashes must be of the same make.
> >
> >> wouldn't it be simpler to have just an array of flash sizes instead
> >> of duplicating the entire params struct?
> >
> > Yes, that is accurate. In alignment with our current stacked support
> > use case we can have an array of flash sizes instead.
> > The primary purpose of having an array of params struct was to
> > facilitate potential future extensions, allowing the addition of
> > stacked support for different flashes
> >
> 
> right. Don't do this change yet, let's decide on the overall architecture first.

Sure.
> 
> >>
> >>>
> >>> SPI-NOR is not aware of the chip_select values, for any incoming
> >>> request SPI-NOR will decide the flash index with the help of
> >>> individual flash size and the configuration type (single/stacked).
> >>> SPI-NOR will pass on the flash index information to the SPI core &
> >>> SPI driver by setting the appropriate bit in
> >>> nor->spimem->spi->cs_index_mask. For example, if nth bit of
> >>> nor->spimem->spi->cs_index_mask is set then the driver would
> >>> assert/de-assert spi->chip_slect[n].
> >>>
> >>> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
> mahapatra at amd.com>
> >>> ---
> >>>  drivers/mtd/spi-nor/core.c  | 272 +++++++++++++++++++++++++++++-----
> --
> >>>  drivers/mtd/spi-nor/core.h  |   4 +
> >>>  include/linux/mtd/spi-nor.h |  15 +-
> >>>  3 files changed, 240 insertions(+), 51 deletions(-)
> >>>
> >>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> >>> index 93ae69b7ff83..e990be7c7eb6 100644
> >>> --- a/drivers/mtd/spi-nor/core.c
> >>> +++ b/drivers/mtd/spi-nor/core.c
> >>
> >> cut
> >>
> >>> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct
> >>> spi_nor *nor)  static int spi_nor_late_init_params(struct spi_nor
> >>> *nor)  {
> >>>  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
> >> 0);
> >>> -	int ret;
> >>> +	struct device_node *np = spi_nor_get_flash_node(nor);
> >>> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
> >>> +	u32 idx = 0;
> >>> +	int rc, ret;
> >>>
> >>>  	if (nor->manufacturer && nor->manufacturer->fixups &&
> >>>  	    nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
> >>> static int spi_nor_late_init_params(struct spi_nor *nor)
> >>>  	if (params->n_banks > 1)
> >>>  		params->bank_size = div64_u64(params->size, params-
> n_banks);
> >>>
> >>> +	nor->num_flash = 0;
> >>> +
> >>> +	/*
> >>> +	 * The flashes that are connected in stacked mode should be of
> >>> +same
> >> make.
> >>> +	 * Except the flash size all other properties are identical for all the
> >>> +	 * flashes connected in stacked mode.
> >>> +	 * The flashes that are connected in parallel mode should be identical.
> >>> +	 */
> >>> +	while (idx < SNOR_FLASH_CNT_MAX) {
> >>> +		rc = of_property_read_u64_index(np, "stacked-memories",
> >> idx,
> >>> +&flash_size[idx]);
> >>
> >> This is a little late in my opinion, as we don't have any sanity
> >> check on the flashes that are stacked on top of the first. We shall
> >> at least read and compare the ID for all.
> >
> > Alright, I will incorporate a sanity check for reading and comparing
> > the ID of the stacked flash. Subsequently, I believe this stacked
> > logic should be relocated to spi_nor_get_flash_info() where we
> > identify the first flash. Please share your thoughts on this.
> > Additionally, do you
> 
> I'm wondering whether we can add a layer on top of the flash type to handle

When you mention "on top," are you referring to incorporating it into 
the MTD layer? Initially, Miquel had submitted this patch to address 
stacked/parallel handling in the MTD layer.
https://lore.kernel.org/linux-mtd/20200114191052.0a16d116 at xps13/t/
However, the Device Tree bindings were initially not accepted. 
Following a series of discussions, the below bindings were 
eventually merged.
https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal at bootlin.com/

> the stacked/parallel modes. This way everything will become flash type
> independent. Would it be possible to stack 2 SPI NANDs? How about a SPI
> NOR and a SPI NAND?
> 
> Is the datasheet of the controller public?

Yes, https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Controller

> 
> > anticipate that SPI-NOR should throw an error if the second or any
> > subsequent flash within the stacked connection is different? Or would
> > you prefer it to print a warning and operate in single mode (i.e.,
> > only the first flash)?
> 
> Both options are fine, but I haven't yet decided on the overall architecture.

Ok.

Regards,
Amit
> 
> Cheers,
> ta

From mihai.sain at microchip.com  Sun Dec 10 23:03:45 2023
From: mihai.sain at microchip.com (Mihai Sain)
Date: Mon, 11 Dec 2023 09:03:45 +0200
Subject: [PATCH] ARM: dts: microchip: sama5d27_som1_ek: Remove mmc-ddr-3_3v property from sdmmc0 node
Message-ID: <20231211070345.2792-1-mihai.sain@microchip.com>

On board the sdmmc0 interface is wired to a SD Card socket.
According with mmc-controller bindings, the mmc-ddr-3_3v property
is used for eMMC devices to enable high-speed DDR mode (3.3V I/O).
Remove the mmc-ddr-3_3v property from sdmmc0 node.

Signed-off-by: Mihai Sain <mihai.sain at microchip.com>
---
 arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts
index d0a6dbd377df..f3ffb8f01d8a 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts
@@ -54,7 +54,6 @@ usb2: ehci at 500000 {
 
 		sdmmc0: sdio-host at a0000000 {
 			bus-width = <8>;
-			mmc-ddr-3_3v;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_sdmmc0_default>;
 			status = "okay";
-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Sun Dec 10 23:28:51 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 08:28:51 +0100
Subject: [PATCH] dt-bindings: pinctrl: samsung: correct ExynosAutov920
 wake-up compatibles
In-Reply-To: <c63bd0b3-ecb2-d4c6-2147-43f19c1dcfee@samsung.com>
References: <CGME20231210133927epcas2p3e2633ad371b03d5ab19f9b44118fcb58@epcas2p3.samsung.com>
 <20231210133915.42112-1-krzysztof.kozlowski@linaro.org>
 <c63bd0b3-ecb2-d4c6-2147-43f19c1dcfee@samsung.com>
Message-ID: <7a4d3873-d9df-4ecd-9b3c-c57a9209dc97@linaro.org>

On 11/12/2023 03:18, Jaewon Kim wrote:
> 
> On 23. 12. 10. 22:39, Krzysztof Kozlowski wrote:
>> ExynosAutov920 SoC wake-up pin controller has different register layout
>> than Exynos7, thus it should not be marked as compatible.  Neither DTS
>> nor Linux driver was merged yet, so the change does not impact ABI.
>>
>> Cc: Jaewon Kim <jaewon02.kim at samsung.com>
>> Fixes: 904140fa4553 ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers")
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>>
>>
> 
> It is reasonable.
> 
> I will also fix this in v4 patch.
> 
> 
> Reviewed-by:Jaewon Kim <jaewon02.kim at samsung.com>

This is based on your patchset, because autov920 is not compatible there
with the others.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 23:34:36 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 08:34:36 +0100
Subject: [PATCH] dt-bindings: pinctrl: samsung: correct ExynosAutov920
 wake-up compatibles
In-Reply-To: <c63bd0b3-ecb2-d4c6-2147-43f19c1dcfee@samsung.com>
References: <CGME20231210133927epcas2p3e2633ad371b03d5ab19f9b44118fcb58@epcas2p3.samsung.com>
 <20231210133915.42112-1-krzysztof.kozlowski@linaro.org>
 <c63bd0b3-ecb2-d4c6-2147-43f19c1dcfee@samsung.com>
Message-ID: <a441ca43-8631-4a6a-b828-6d744fce5aee@linaro.org>

On 11/12/2023 03:18, Jaewon Kim wrote:
> 
> On 23. 12. 10. 22:39, Krzysztof Kozlowski wrote:
>> ExynosAutov920 SoC wake-up pin controller has different register layout
>> than Exynos7, thus it should not be marked as compatible.  Neither DTS
>> nor Linux driver was merged yet, so the change does not impact ABI.
>>
>> Cc: Jaewon Kim <jaewon02.kim at samsung.com>
>> Fixes: 904140fa4553 ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers")
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>>
>>
> 
> It is reasonable.
> 
> I will also fix this in v4 patch.
> 
> 
> Reviewed-by:Jaewon Kim <jaewon02.kim at samsung.com>

Please send correct tags so I won't need to manually fix them. Otherwise
they get ignored by b4.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 10 23:36:22 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 08:36:22 +0100
Subject: [PATCH] dt-bindings: pinctrl: samsung: correct ExynosAutov920
 wake-up compatibles
In-Reply-To: <20231210133915.42112-1-krzysztof.kozlowski@linaro.org>
References: <20231210133915.42112-1-krzysztof.kozlowski@linaro.org>
Message-ID: <170228018218.6375.7978493220422861783.b4-ty@linaro.org>


On Sun, 10 Dec 2023 14:39:15 +0100, Krzysztof Kozlowski wrote:
> ExynosAutov920 SoC wake-up pin controller has different register layout
> than Exynos7, thus it should not be marked as compatible.  Neither DTS
> nor Linux driver was merged yet, so the change does not impact ABI.
> 
> 

Applied, thanks!

[1/1] dt-bindings: pinctrl: samsung: correct ExynosAutov920 wake-up compatibles
      https://git.kernel.org/pinctrl/samsung/c/e1564d6f93496bcea3a6b2110eb54cc08f2aca72

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From anshuman.khandual at arm.com  Sun Dec 10 23:39:08 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 11 Dec 2023 13:09:08 +0530
Subject: [PATCH V3 08/10] coresight: tmc: Move ACPI support from AMBA
 driver to platform driver
In-Reply-To: <22cfb197-b8bd-46c5-f3cb-ea04b95c0792@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
 <20231208053939.42901-9-anshuman.khandual@arm.com>
 <22cfb197-b8bd-46c5-f3cb-ea04b95c0792@arm.com>
Message-ID: <5c9371bd-9f29-408f-9419-df2209e55f7e@arm.com>



On 12/8/23 21:01, James Clark wrote:
> 
> On 08/12/2023 05:39, Anshuman Khandual wrote:
>> Add support for the tmc devices in the platform driver, which can then be
>> used on ACPI based platforms. This change would now allow runtime power
>> management for ACPI based systems. The driver would try to enable the APB
>> clock if available.
>>
>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Cc: Mike Leach <mike.leach at linaro.org>
>> Cc: James Clark <james.clark at arm.com>
>> Cc: linux-acpi at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: coresight at lists.linaro.org
>> Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
>> Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>> Changes in V3:
>>
>> - Added commnets for 'drvdata->pclk'
>> - Used coresight_init_driver()/coresight_remove_driver() helpers instead
>> - Dropped pm_runtime_put() from __tmc_probe()
>> - Added pm_runtime_put() on success path in tmc_probe()
>> - Added pm_runtime_put() on success/error paths in tmc_platform_probe()
>> - Check for drvdata instead of drvdata->pclk in suspend and resume paths
>>
>>  drivers/acpi/arm64/amba.c                     |   2 -
>>  .../hwtracing/coresight/coresight-tmc-core.c  | 137 ++++++++++++++++--
>>  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
>>  3 files changed, 124 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
>> index 6d24a8f7914b..d3c1defa7bc8 100644
>> --- a/drivers/acpi/arm64/amba.c
>> +++ b/drivers/acpi/arm64/amba.c
>> @@ -22,10 +22,8 @@
>>  static const struct acpi_device_id amba_id_list[] = {
>>  	{"ARMH0061", 0}, /* PL061 GPIO Device */
>>  	{"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
>> -	{"ARMHC501", 0}, /* ARM CoreSight ETR */
>>  	{"ARMHC502", 0}, /* ARM CoreSight STM */
>>  	{"ARMHC503", 0}, /* ARM CoreSight Debug */
>> -	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
>>  	{"", 0},
>>  };
>>  
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
>> index ad61d02f5f75..8482830d73ef 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
>> @@ -23,6 +23,8 @@
>>  #include <linux/of.h>
>>  #include <linux/coresight.h>
>>  #include <linux/amba/bus.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/acpi.h>
>>  
>>  #include "coresight-priv.h"
>>  #include "coresight-tmc.h"
>> @@ -437,24 +439,17 @@ static u32 tmc_etr_get_max_burst_size(struct device *dev)
>>  	return burst_size;
>>  }
>>  
>> -static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
>> +static int __tmc_probe(struct device *dev, struct resource *res, void *dev_caps)
> I don't think the dev_caps argument is used anymore since the v3 changes.

Sure, will drop the argument.


From alexander.stein at ew.tq-group.com  Sun Dec 10 23:42:01 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 11 Dec 2023 08:42:01 +0100
Subject: [PATCH 3/3] arm64: dts: imx8mp-tqma8mpql-mba8mpxl: Fix USB connector description
In-Reply-To: <20231207185543.2699697-3-festevam@gmail.com>
References: <20231207185543.2699697-1-festevam@gmail.com> <20231207185543.2699697-3-festevam@gmail.com>
Message-ID: <2710885.mvXUDI8C0e@steina-w>

Hi Fabio,

Am Donnerstag, 7. Dezember 2023, 19:55:43 CET schrieb Fabio Estevam:
> From: Fabio Estevam <festevam at denx.de>
> 
> The USB connector should not be placed under the dwc3 node.
> 
> Move the USB connector out of the SoC level and use port to describe
> the connection to the dwc3 controller.
> 
> This fixes the following dt-schema warning:
> 
> imx8mp-tqma8mpql-mba8mpxl.dtb: usb at 38100000: Unevaluated properties are not
> allowed ('connector' was unexpected) from schema $id:
> http://devicetree.org/schemas/usb/snps,dwc3.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Reviewed-by: Alexander Stein <alexander.stein at ew.tq-group.com>
Tested-by: Alexander Stein <alexander.stein at ew.tq-group.com>

Thanks
Alexander

> ---
>  .../freescale/imx8mp-tqma8mpql-mba8mpxl.dts   | 26 ++++++++++++++-----
>  1 file changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
> b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts index
> 4b161564a284..505b70cb2bd7 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
> @@ -55,6 +55,21 @@ clk_xtal25: clk-xtal25 {
>  		clock-frequency = <25000000>;
>  	};
> 
> +	connector {
> +		compatible = "gpio-usb-b-connector", "usb-b-connector";
> +		type = "micro";
> +		label = "X29";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_usbcon0>;
> +		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
> +
> +		port {
> +			usb_dr_connector: endpoint {
> +				remote-endpoint = <&usb3_dwc>;
> +			};
> +		};
> +	};
> +
>  	fan0: pwm-fan {
>  		compatible = "pwm-fan";
>  		pinctrl-names = "default";
> @@ -625,13 +640,10 @@ &usb_dwc3_0 {
>  	role-switch-default-mode = "peripheral";
>  	status = "okay";
> 
> -	connector {
> -		compatible = "gpio-usb-b-connector", "usb-b-connector";
> -		type = "micro";
> -		label = "X29";
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&pinctrl_usbcon0>;
> -		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
> +	port {
> +		usb3_dwc: endpoint {
> +			remote-endpoint = <&usb_dr_connector>;
> +		};
>  	};
>  };


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From krzysztof.kozlowski at linaro.org  Sun Dec 10 23:42:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 08:42:08 +0100
Subject: (subset) [PATCH v3 1/4] arm64: dts: exynos: add initial
 support for exynosautov920 SoC
In-Reply-To: <20231208074527.50840-2-jaewon02.kim@samsung.com>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
 <CGME20231208075020epcas2p25f18d225f91f185085078461b290cb19@epcas2p2.samsung.com>
 <20231208074527.50840-2-jaewon02.kim@samsung.com>
Message-ID: <170228052808.12030.1188300498236704832.b4-ty@linaro.org>


On Fri, 08 Dec 2023 16:45:24 +0900, Jaewon Kim wrote:
> Samsung ExynosAutov920 is ARMv8-based automotive-oriented SoC.
> It has AE(Automotive Enhanced) IPs for safety.
>  * Cortex-A78AE 10-cores
>  * GIC-600AE
> 
> This is minimal support for ExynosAutov920 SoC.
>  * Enumerate all pinctrl nodes
>  * Enable Chip-Id
>  * Serial0 for console
>  * PWM
> 
> [...]

Applied, thanks!

[1/4] arm64: dts: exynos: add initial support for exynosautov920 SoC
      https://git.kernel.org/krzk/linux/c/c96dab1993d247b7b05ba2fdef8f185cbbd5454e

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Sun Dec 10 23:42:10 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 08:42:10 +0100
Subject: (subset) [PATCH v3 2/4] arm64: dts: exynos: add minimal
 support for exynosautov920 sadk board
In-Reply-To: <20231208074527.50840-3-jaewon02.kim@samsung.com>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
 <CGME20231208075020epcas2p30e46ea65e921664930b337510461892f@epcas2p3.samsung.com>
 <20231208074527.50840-3-jaewon02.kim@samsung.com>
Message-ID: <170228053058.12030.17311728279876504581.b4-ty@linaro.org>


On Fri, 08 Dec 2023 16:45:25 +0900, Jaewon Kim wrote:
> ExynosAutov920 SADK is ExynosAutov920 SoC based SADK(Samsung Automotive
> Development Kit) board. It has 16GB(8GB + 8GB) LPDDR5 RAM and 256GB
> (128GB + 128GB) UFS.
> 
> This is minimal support board device-tree.
>  * Serial console
>  * GPIO Key
>  * PWM FAN
> 
> [...]

Applied, thanks!

[2/4] arm64: dts: exynos: add minimal support for exynosautov920 sadk board
      https://git.kernel.org/krzk/linux/c/57de428eaca2b9af1a35df96c7adcad4b5ea79f9

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Sun Dec 10 23:42:13 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 08:42:13 +0100
Subject: [PATCH] dt-bindings: samsung: exynos-sysreg: combine
 exynosautov920 with other enum
In-Reply-To: <20231210134834.43943-1-krzysztof.kozlowski@linaro.org>
References: <20231210134834.43943-1-krzysztof.kozlowski@linaro.org>
Message-ID: <170228053300.12030.5356013143015298752.b4-ty@linaro.org>


On Sun, 10 Dec 2023 14:48:34 +0100, Krzysztof Kozlowski wrote:
> No need to create a new enum every time we bring-up new SoC.
> 
> 

Applied, thanks!

[1/1] dt-bindings: samsung: exynos-sysreg: combine exynosautov920 with other enum
      https://git.kernel.org/krzk/linux/c/e4f027756dff6a4e2abc640f276f91219559a3c9

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Sun Dec 10 23:43:45 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 08:43:45 +0100
Subject: (subset) [PATCH v3 1/4] arm64: dts: exynos: add initial support
 for exynosautov920 SoC
In-Reply-To: <170228052808.12030.1188300498236704832.b4-ty@linaro.org>
References: <20231208074527.50840-1-jaewon02.kim@samsung.com>
 <CGME20231208075020epcas2p25f18d225f91f185085078461b290cb19@epcas2p2.samsung.com>
 <20231208074527.50840-2-jaewon02.kim@samsung.com>
 <170228052808.12030.1188300498236704832.b4-ty@linaro.org>
Message-ID: <2789e0d3-1770-45b8-be7d-384a758c10b7@linaro.org>

On 11/12/2023 08:42, Krzysztof Kozlowski wrote:
> 
> On Fri, 08 Dec 2023 16:45:24 +0900, Jaewon Kim wrote:
>> Samsung ExynosAutov920 is ARMv8-based automotive-oriented SoC.
>> It has AE(Automotive Enhanced) IPs for safety.
>>  * Cortex-A78AE 10-cores
>>  * GIC-600AE
>>
>> This is minimal support for ExynosAutov920 SoC.
>>  * Enumerate all pinctrl nodes
>>  * Enable Chip-Id
>>  * Serial0 for console
>>  * PWM
>>
>> [...]
> 
> Applied, thanks!
> 
> [1/4] arm64: dts: exynos: add initial support for exynosautov920 SoC
>       https://git.kernel.org/krzk/linux/c/c96dab1993d247b7b05ba2fdef8f185cbbd5454e

With changes:

Re-order nodes to match coding style: UFS reset pins,
gpg/gpp in peric0 and peric1, all nodes in the soc at 0;
drop fallback compatibles from wakeup-interrupt-controller

Best regards,
Krzysztof



From andyshrk at 163.com  Sun Dec 10 23:46:55 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 11 Dec 2023 15:46:55 +0800 (CST)
Subject: [PATCH v2 4/5] dt-bindings: arm: rockchip: Add Cool Pi CM5
 EVB
In-Reply-To: <6eb1541b-430b-41cf-b297-ebb3d47f5278@linaro.org>
References: <20231210080313.1667013-1-andyshrk@163.com>
 <20231210080607.1667517-1-andyshrk@163.com>
 <6eb1541b-430b-41cf-b297-ebb3d47f5278@linaro.org>
Message-ID: <6d8b8a8b.3c0e.18c57d7e1b4.Coremail.andyshrk@163.com>


Hi Krzysztof?

At 2023-12-10 19:11:33, "Krzysztof Kozlowski" <krzysztof.kozlowski at linaro.org> wrote:
>On 10/12/2023 09:06, Andy Yan wrote:
>> Add Cool Pi CM5 EVB, a board powered by RK3588
>> 
>> Signed-off-by: Andy Yan <andyshrk at 163.com>
>> 
>> ---
>> 
>> Changes in v2:
>> - change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"
>> 
>>  Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
>>  1 file changed, 5 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
>> index 11d03035f3db..4da83bbd642a 100644
>> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
>> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
>> @@ -95,6 +95,11 @@ properties:
>>            - const: chipspark,rayeager-px2
>>            - const: rockchip,rk3066a
>>  
>> +      - description: Cool Pi Compute Module 5(CM5) EVB
>> +        items:
>> +          - const: coolpi,pi-cm5-evb
>
>If it is module you are maybe missing here module DTSI and compatible.
>

Yes? it is a core board?CM5? + mother board = CM5 EVB?this is
the  variant I current have? I want to keep the dts as it is now?I will
convert it to a dtsi when I get another variant for this core board?CM5?.

>Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>
>Best regards,
>Krzysztof
>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

From andyshrk at 163.com  Sun Dec 10 23:48:46 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 11 Dec 2023 15:48:46 +0800 (CST)
Subject: [PATCH v2 3/5] arm64: dts: rockchip: Add support for rk3588s
 based board Cool Pi 4B
In-Reply-To: <32b6437f-0e56-439d-8ebb-465e5230b18f@linaro.org>
References: <20231210080313.1667013-1-andyshrk@163.com>
 <20231210080547.1667421-1-andyshrk@163.com>
 <32b6437f-0e56-439d-8ebb-465e5230b18f@linaro.org>
Message-ID: <21f982a7.3c52.18c57d99625.Coremail.andyshrk@163.com>


Hi Krzysztof?

At 2023-12-10 19:13:26, "Krzysztof Kozlowski" <krzysztof.kozlowski at linaro.org> wrote:
>On 10/12/2023 09:05, Andy Yan wrote:
>> CoolPi 4B is a rk3588s based SBC.
>> Specification:
>> - Rockchip RK3588S
>> - LPDDR4 2/4/8/16 GB
>> - TF scard slot
>
>...
>
>> +&i2c6 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&i2c6m3_xfer>;
>> +	status = "okay";
>> +
>> +	hym8563: rtc at 51 {
>> +		compatible = "haoyu,hym8563";
>> +		reg = <0x51>;
>> +		#clock-cells = <0>;
>> +		clock-frequency = <32768>;
>> +		clock-output-names = "hym8563";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&hym8563_int>;
>> +		interrupt-parent = <&gpio0>;
>> +		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
>> +		status = "okay";
>
>My comments about redundant statues applies to all places, not only to
>one specific place...

Sorry for that? I will fix in V3

>
>Best regards,
>Krzysztof
>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

From anshuman.khandual at arm.com  Sun Dec 10 23:51:40 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Mon, 11 Dec 2023 13:21:40 +0530
Subject: [PATCH V3 04/10] coresight: replicator: Move ACPI support from
 AMBA driver to platform driver
In-Reply-To: <20231208053939.42901-5-anshuman.khandual@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
 <20231208053939.42901-5-anshuman.khandual@arm.com>
Message-ID: <862afccb-e9c5-4fcb-abdf-45a5eb9aa6d8@arm.com>



On 12/8/23 11:09, Anshuman Khandual wrote:
> Add support for the dynamic replicator device in the platform driver, which
> can then be used on ACPI based platforms. This change would now allow
> runtime power management for repliacator devices on ACPI based systems.
> 
> The driver would try to enable the APB clock if available. Also, rename the
> code to reflect the fact that it now handles both static and dynamic
> replicators.
> 
> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Cc: Mike Leach <mike.leach at linaro.org>
> Cc: James Clark <james.clark at arm.com>
> Cc: linux-acpi at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: coresight at lists.linaro.org
> Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
> Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
> Changes in V3:
> 
> - Added commnets for 'drvdata->pclk'
> - Used coresight_init_driver()/coresight_remove_driver() helpers instead
> - Dropped pm_runtime_put() from replicator_probe()
> - Added pm_runtime_put() on success path in dynamic_replicator_probe()
> - Added pm_runtime_put() on success/error paths in
>   replicator_platform_probe()
> 
>  drivers/acpi/arm64/amba.c                     |  1 -
>  .../coresight/coresight-replicator.c          | 81 ++++++++++---------
>  2 files changed, 42 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
> index 171b5c2c7edd..270f4e3819a2 100644
> --- a/drivers/acpi/arm64/amba.c
> +++ b/drivers/acpi/arm64/amba.c
> @@ -27,7 +27,6 @@ static const struct acpi_device_id amba_id_list[] = {
>  	{"ARMHC503", 0}, /* ARM CoreSight Debug */
>  	{"ARMHC979", 0}, /* ARM CoreSight TPIU */
>  	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
> -	{"ARMHC98D", 0}, /* ARM CoreSight Dynamic Replicator */
>  	{"ARMHC9CA", 0}, /* ARM CoreSight CATU */
>  	{"ARMHC9FF", 0}, /* ARM CoreSight Dynamic Funnel */
>  	{"", 0},
> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
> index b6be73034996..125b256cb8db 100644
> --- a/drivers/hwtracing/coresight/coresight-replicator.c
> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
> @@ -31,6 +31,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>   * @base:	memory mapped base address for this component. Also indicates
>   *		whether this one is programmable or not.
>   * @atclk:	optional clock for the core parts of the replicator.
> + * @pclk:	APB clock if present, otherwise NULL
>   * @csdev:	component vitals needed by the framework
>   * @spinlock:	serialize enable/disable operations.
>   * @check_idfilter_val: check if the context is lost upon clock removal.
> @@ -38,6 +39,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>  struct replicator_drvdata {
>  	void __iomem		*base;
>  	struct clk		*atclk;
> +	struct clk		*pclk;
>  	struct coresight_device	*csdev;
>  	spinlock_t		spinlock;
>  	bool			check_idfilter_val;
> @@ -243,6 +245,10 @@ static int replicator_probe(struct device *dev, struct resource *res)
>  			return ret;
>  	}
>  
> +	drvdata->pclk = coresight_get_enable_apb_pclk(dev);
> +	if (IS_ERR(drvdata->pclk))
> +		return -ENODEV;
> +
>  	/*
>  	 * Map the device base for dynamic-replicator, which has been
>  	 * validated by AMBA core
> @@ -285,7 +291,6 @@ static int replicator_probe(struct device *dev, struct resource *res)
>  	}
>  
>  	replicator_reset(drvdata);
> -	pm_runtime_put(dev);
>  
>  out_disable_clk:
>  	if (ret && !IS_ERR_OR_NULL(drvdata->atclk))
> @@ -301,29 +306,31 @@ static int replicator_remove(struct device *dev)
>  	return 0;
>  }
>  
> -static int static_replicator_probe(struct platform_device *pdev)
> +static int replicator_platform_probe(struct platform_device *pdev)
>  {
> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	int ret;
>  
>  	pm_runtime_get_noresume(&pdev->dev);
>  	pm_runtime_set_active(&pdev->dev);
>  	pm_runtime_enable(&pdev->dev);
>  
> -	/* Static replicators do not have programming base */
> -	ret = replicator_probe(&pdev->dev, NULL);
> -
> -	if (ret) {
> -		pm_runtime_put_noidle(&pdev->dev);
> -		pm_runtime_disable(&pdev->dev);
> -	}
> +	ret = replicator_probe(&pdev->dev, res);
> +	pm_runtime_put(&pdev->dev);

I believe pm_runtime_disable() would still be needed on the error path. Otherwise
pm_runtime_enable() will remain unbalanced on this error path when the replicator
module could not be loaded.

--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -317,6 +317,8 @@ static int replicator_platform_probe(struct platform_device *pdev)
 
        ret = replicator_probe(&pdev->dev, res);
        pm_runtime_put(&pdev->dev);
+       if (ret)
+               pm_runtime_disable(&pdev->dev);
 
        return ret;
 }

Similar constructs in this error path are also required in all other drivers (except
cpu debug) as well.


From krzysztof.kozlowski at linaro.org  Mon Dec 11 00:02:21 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 09:02:21 +0100
Subject: [PATCH v2 1/2] dt-bindings: phy: mediatek: tphy: add a property
 for force-mode switch
In-Reply-To: <20231211025624.28991-1-chunfeng.yun@mediatek.com>
References: <20231211025624.28991-1-chunfeng.yun@mediatek.com>
Message-ID: <48764dba-5033-4dd6-9125-03dd9a178054@linaro.org>

On 11/12/2023 03:56, Chunfeng Yun wrote:
> Due to some old SoCs with shared t-phy between usb3 and pcie only support
> force-mode switch, and shared and non-shared t-phy may exist at the same
> time on a SoC, can't use compatible to distinguish between shared and
> non-shared t-phy, add a property to supported it.
> Currently, only support switch from default pcie mode to usb3 mode.
> But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 11 00:04:02 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 09:04:02 +0100
Subject: [PATCH v2 08/14] ARM: dts: aspeed: yosemite4: Revise i2c11 and
 i2c12 schematic change
In-Reply-To: <20231211024947.3990898-9-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
 <20231211024947.3990898-9-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <1f59a4f5-7082-4a36-806e-2fff4d1e5d7d@linaro.org>

On 11/12/2023 03:49, Delphine CC Chiu wrote:
> Revise i2c11 and i2c12 schematic change:
> - remove space for adm1272 compatible
> - enable interrupt setting for pca9555
> - add eeprom for yosemite4 medusa board/BSM use
> - remove temperature sensor for yosemite4 schematic change
> - add power sensor for power module reading

You should split your patch into several, per one logical change.


> 
> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
> ---
>  .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 118 ++++++++++++++----
>  1 file changed, 93 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> index da413325ce30..ccb5ecd8d9a6 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> @@ -821,41 +821,94 @@ imux29: i2c at 1 {
>  &i2c11 {
>  	status = "okay";
>  	power-sensor at 10 {
> -		compatible = "adi, adm1272";
> +		compatible = "adi,adm1272";
>  		reg = <0x10>;
>  	};
>  
>  	power-sensor at 12 {
> -		compatible = "adi, adm1272";
> +		compatible = "adi,adm1272";
>  		reg = <0x12>;
>  	};
>  
> -	gpio at 20 {
> +	gpio_ext1: pca9555 at 20 {

That's not a correct change. You replace good code with bad.

>  		compatible = "nxp,pca9555";
> -		reg = <0x20>;
> +		pinctrl-names = "default";
>  		gpio-controller;
>  		#gpio-cells = <2>;
> -	};
> -
> -	gpio at 21 {
> +		reg = <0x20>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
> +		gpio-line-names =
> +		"P48V_OCP_GPIO1","P48V_OCP_GPIO2",
> +		"P48V_OCP_GPIO3","FAN_BOARD_0_REVISION_0_R",
> +		"FAN_BOARD_0_REVISION_1_R","FAN_BOARD_1_REVISION_0_R",
> +		"FAN_BOARD_1_REVISION_1_R","RST_MUX_R_N",
> +		"RST_LED_CONTROL_FAN_BOARD_0_N","RST_LED_CONTROL_FAN_BOARD_1_N",
> +		"RST_IOEXP_FAN_BOARD_0_N","RST_IOEXP_FAN_BOARD_1_N",
> +		"PWRGD_LOAD_SWITCH_FAN_BOARD_0_R","PWRGD_LOAD_SWITCH_FAN_BOARD_1_R",
> +		"","";
> +	};
> +
> +	gpio_ext2: pca9555 at 21 {

Nope

>  		compatible = "nxp,pca9555";
> -		reg = <0x21>;
> +		pinctrl-names = "default";
>  		gpio-controller;
>  		#gpio-cells = <2>;
> -	};
> -
> -	gpio at 22 {
> +		reg = <0x21>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
> +		gpio-line-names =
> +		"DELTA_MODULE_TYPE","VSENSE_ERR_VDROP_R",
> +		"EN_P48V_AUX_0","EN_P48V_AUX_1",
> +		"MEDUSA_BOARD_REV_0","MEDUSA_BOARD_REV_1",
> +		"MEDUSA_BOARD_REV_2","MEDUSA_BOARD_TYPE",
> +		"HSC_OCP_SLOT_ODD_GPIO1","HSC_OCP_SLOT_ODD_GPIO2",
> +		"HSC_OCP_SLOT_ODD_GPIO3","HSC_OCP_SLOT_EVEN_GPIO1",
> +		"HSC_OCP_SLOT_EVEN_GPIO2","HSC_OCP_SLOT_EVEN_GPIO3",
> +		"ADC_TYPE_0_R","ADC_TYPE_1_R";
> +	};
> +
> +	gpio_ext3: pca9555 at 22 {

Nope

>  		compatible = "nxp,pca9555";
> -		reg = <0x22>;
> +		pinctrl-names = "default";
>  		gpio-controller;
>  		#gpio-cells = <2>;
> -	};
> -
> -	gpio at 23 {
> +		reg = <0x22>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
> +		gpio-line-names =
> +		"CARD_TYPE_SLOT1","CARD_TYPE_SLOT2",
> +		"CARD_TYPE_SLOT3","CARD_TYPE_SLOT4",
> +		"CARD_TYPE_SLOT5","CARD_TYPE_SLOT6",
> +		"CARD_TYPE_SLOT7","CARD_TYPE_SLOT8",
> +		"OC_P48V_HSC_0_N","FLT_P48V_HSC_0_N",
> +		"PWRGD_P12V_AUX_1","OC_P48V_HSC_1_N",
> +		"FLT_P48V_HSC_1_N","PWRGD_P12V_AUX_1",
> +		"MEDUSA_ADC_EFUSE_TYPE_R","P12V_HSC_TYPE";
> +	};
> +
> +	gpio_ext4: pca9555 at 23 {

Nope



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 11 00:05:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 09:05:07 +0100
Subject: [PATCH v2 10/14] ARM: dts: aspeed: yosemite4: Initialize bmc gpio
 state
In-Reply-To: <20231211024947.3990898-11-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
 <20231211024947.3990898-11-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <2339a35d-270f-4a55-a2fe-191dec44aa5b@linaro.org>

On 11/12/2023 03:49, Delphine CC Chiu wrote:
> Initialize bmc gpio state
> 
> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
> ---
>  .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 195 ++++++++++++++++++
>  1 file changed, 195 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> index ed2b1200603d..eb3687bfd632 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> @@ -1271,6 +1271,7 @@ temperature-sensor at 1f {
>  	};
>  };
>  
> +

Drop

>  &adc0 {
>  	ref_voltage = <2500>;
>  	status = "okay";
> @@ -1298,3 +1299,197 @@ &ehci1 {
>  &uhci {
>  	status = "okay";
>  };
> +
> +&sgpiom0 {
> +	status = "okay";
> +	ngpios = <128>;
> +	bus-frequency = <48000>;
> +};
> +
> +&gpio0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_gpiu2_default &pinctrl_gpiu3_default
> +		     &pinctrl_gpiu4_default &pinctrl_gpiu5_default
> +		     &pinctrl_gpiu6_default>;
> +	gpio-line-names =
> +	/*A0-A7*/       "","","","","","","","",
> +	/*B0-B7*/       "FLT_HSC_SERVER_SLOT8_N","AC_ON_OFF_BTN_CPLD_SLOT5_N",
> +			"PWRGD_SLOT1_STBY","PWRGD_SLOT2_STBY",
> +			"PWRGD_SLOT3_STBY","PWRGD_SLOT4_STBY","","",
> +	/*C0-C7*/       "PRSNT_NIC3_N","","","","FM_NIC0_WAKE_N",
> +			"FM_NIC1_WAKE_N","","RST_PCIE_SLOT2_N",
> +	/*D0-D7*/       "","","","","","","","",
> +	/*E0-E7*/       "PRSNT_NIC1_N","PRSNT_NIC2_N","","RST_PCIE_SLOT1_N",
> +			"","","","",
> +	/*F0-F7*/       "FM_RESBTN_SLOT1_BMC_N","FM_RESBTN_SLOT2_BMC_N",
> +			"FM_RESBTN_SLOT3_BMC_N","FM_RESBTN_SLOT4_BMC_N",
> +			"PRSNT_SB_SLOT1_N","PRSNT_SB_SLOT2_N",
> +			"PRSNT_SB_SLOT3_N","PRSNT_SB_SLOT4_N",
> +	/*G0-G7*/       "","","","","","","","",
> +	/*H0-H7*/       "","","","","","","","",
> +	/*I0-I7*/       "","","","","","ALT_MEDUSA_ADC_N",
> +			"ALT_SMB_BMC_CPLD2_N",
> +			"INT_SPIDER_ADC_R_N",
> +	/*J0-J7*/       "","","","","","","","",
> +	/*K0-K7*/       "","","","","","","","",
> +	/*L0-L7*/       "","","","","","","ALT_MEDUSA_P12V_EFUSE_N","",
> +	/*M0-M7*/       "EN_NIC0_POWER_BMC_R","EN_NIC1_POWER_BMC_R",
> +			"INT_MEDUSA_IOEXP_TEMP_N","FLT_P12V_NIC0_N",
> +			"INT_SMB_BMC_SLOT1_4_BMC_N",
> +			"AC_ON_OFF_BTN_CPLD_SLOT6_N","","",
> +	/*N0-N7*/       "FLT_HSC_SERVER_SLOT1_N","FLT_HSC_SERVER_SLOT2_N",
> +			"FLT_HSC_SERVER_SLOT3_N","FLT_HSC_SERVER_SLOT4_N",
> +			"FM_BMC_READY_R2","FLT_P12V_STBY_BMC_N","","",
> +	/*O0-O7*/       "AC_ON_OFF_BTN_CPLD_SLOT8_N","RST_SMB_NIC1_R_N",
> +			"RST_SMB_NIC2_R_N","RST_SMB_NIC3_R_N",
> +			"FLT_P3V3_NIC2_N","FLT_P3V3_NIC3_N",
> +			"","",
> +	/*P0-P7*/       "ALT_SMB_BMC_CPLD1_N","'BTN_BMC_R2_N",
> +			"EN_P3V_BAT_SCALED_R","PWRGD_P5V_USB_BMC",
> +			"FM_BMC_RTCRST_R","RST_USB_HUB_R_N",
> +			"FLAG_P5V_USB_BMC_N","",
> +	/*Q0-Q7*/       "AC_ON_OFF_BTN_CPLD_SLOT1_N","AC_ON_OFF_BTN_CPLD_SLOT2_N",
> +			"AC_ON_OFF_BTN_CPLD_SLOT3_N","AC_ON_OFF_BTN_CPLD_SLOT4_N",
> +			"PRSNT_SB_SLOT5_N","PRSNT_SB_SLOT6_N",
> +			"PRSNT_SB_SLOT7_N","PRSNT_SB_SLOT8_N",
> +	/*R0-R7*/       "AC_ON_OFF_BTN_CPLD_SLOT7_N","INT_SMB_BMC_SLOT5_8_BMC_N",
> +			"FM_PWRBRK_NIC_BMC_R2","RST_PCIE_SLOT4_N",
> +			"RST_PCIE_SLOT5_N","RST_PCIE_SLOT6_N",
> +			"RST_PCIE_SLOT7_N","RST_PCIE_SLOT8_N",
> +	/*S0-S7*/       "FM_NIC2_WAKE_N","FM_NIC3_WAKE_N",
> +			"EN_NIC3_POWER_BMC_R","SEL_BMC_JTAG_MUX_R",
> +			"","ALT_P12V_AUX_N","FAST_PROCHOT_N",
> +			"SPI_WP_DISABLE_STATUS_R_N",
> +	/*T0-T7*/       "","","","","","","","",
> +	/*U0-U7*/       "","","FLT_P3V3_NIC1_N","FLT_P12V_NIC1_N",
> +			"FLT_P12V_NIC2_N","FLT_P12V_NIC3_N",
> +			"FLT_P3V3_NIC0_N","",
> +	/*V0-V7*/       "FM_RESBTN_SLOT5_BMC_N","FM_RESBTN_SLOT6_BMC_N",
> +			"FM_RESBTN_SLOT7_BMC_N","FM_RESBTN_SLOT8_BMC_N",
> +			"","","","",
> +	/*W0-W7*/       "PRSNT_TPM_BMC_N","PRSNT_OCP_DEBUG_BMC_N","ALT_TEMP_BMC_N","ALT_RTC_BMC_N",
> +			"","","","",
> +	/*X0-X7*/       "","LT_HSC_SERVER_SLOT6_N","FLT_HSC_SERVER_SLOT7_N","","","",
> +			"PWRGD_SLOT5_STBY","PWRGD_SLOT6_STBY",
> +	/*Y0-Y7*/       "","","SPI_LOCK_REQ_BMC_N","PWRGD_SLOT7_STBY",
> +			"","","EN_NIC2_POWER_BMC_R","",
> +	/*Z0-Z7*/       "EN_P5V_USB_CPLD_R","'FLT_HSC_SERVER_SLOT5_N",
> +			"PWRGD_SLOT8_STBY","","","","","";
> +
> +	pin_gpio_b4 {

No underscores in node names.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 11 00:05:43 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 09:05:43 +0100
Subject: [PATCH v2 12/14] ARM: dts: aspeed: yosemite4: add mctp config for
 NIC
In-Reply-To: <20231211024947.3990898-13-Delphine_CC_Chiu@wiwynn.com>
References: <20231211024947.3990898-1-Delphine_CC_Chiu@wiwynn.com>
 <20231211024947.3990898-13-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <415438f8-04fe-4e30-a643-ca13278987a0@linaro.org>

On 11/12/2023 03:49, Delphine CC Chiu wrote:
> add mctp config for NIC
> 
> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
> ---
>  .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 24 +++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> index 073f27f1e35f..c8e3a85b7a11 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> @@ -1273,40 +1273,64 @@ imux24: i2c at 0 {
>  			#address-cells = <1>;
>  			#size-cells = <0>;
>  			reg = <0>;
> +			mctp-controller;
>  			temperature-sensor at 1f {
>  				compatible = "ti,tmp421";
>  				reg = <0x1f>;
>  			};
> +
> +			emc1403 at 3c {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation


> +				compatible = "smsc,emc1403";
> +				reg = <0x3c>;
> +			};
>  		};
>  
>  		imux25: i2c at 1 {
>  			#address-cells = <1>;
>  			#size-cells = <0>;
>  			reg = <1>;
> +			mctp-controller;
>  			temperature-sensor at 1f {
>  				compatible = "ti,tmp421";
>  				reg = <0x1f>;
>  			};
> +
> +			emc1403 at 3c {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation



In other places as well.

Best regards,
Krzysztof



From geert at linux-m68k.org  Mon Dec 11 00:20:15 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 11 Dec 2023 09:20:15 +0100
Subject: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
In-Reply-To: <TYCPR01MB112693C2B72B6AA28766FF8EA8688A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
References: <20231201110840.37408-1-biju.das.jz@bp.renesas.com>
 <20231201110840.37408-7-biju.das.jz@bp.renesas.com> <CAMuHMdWh3fTzQP5+mGF3u8LACg-5tQDZcyExvgREpxKd6iee4Q@mail.gmail.com>
 <TYCPR01MB112696C301D750A915F2661688681A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <CAMuHMdXHpE079eLAJjcdsbz6=Y6hux267AhqJow6HESCaf7EXQ@mail.gmail.com> <TYCPR01MB112693C2B72B6AA28766FF8EA8688A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
Message-ID: <CAMuHMdU2pdAYbXdyfpysPR0k7fjh31KrD9Xk05EHWeayzVDz5g@mail.gmail.com>

Hi Biju,

On Sun, Dec 10, 2023 at 10:50?AM Biju Das <biju.das.jz at bp.renesas.com> wrote:
> > -----Original Message-----
> > From: Geert Uytterhoeven <geert at linux-m68k.org>
> > Sent: Friday, December 1, 2023 3:42 PM
> > Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
> >
> > On Fri, Dec 1, 2023 at 4:02?PM Biju Das <biju.das.jz at bp.renesas.com>
> > wrote:
> > > > From: Geert Uytterhoeven <geert at linux-m68k.org> On Fri, Dec 1, 2023
> > > > at 12:09?PM Biju Das <biju.das.jz at bp.renesas.com>
> > > > wrote:
> > > > > Enable the config for the Renesas DA9062 PMIC and RTC, as it is
> > > > > populated on RZ/G2UL SMARC EVK.
> > > > >
> > > > > Signed-off-by: Biju Das <biju.das.jz at bp.renesas.com>
> > > >
> > > > Thanks for your patch!
> > > >
> > > > LGTM, but I would have expected (at least)
> > > >
> > > >     CONFIG_INPUT_DA9063_ONKEY=m
> > > >
> > > > too, cfr. my comments on patch 5/6.
> > >
> > > I have tested this, but I get "da9063-onkey da9062-onkey: error -ENXIO:
> > IRQ ONKEY not found"
> > > So, I won't be able to test onkey events. So plaaning to disable this
> > node.
> >
> > Indeed, currently drivers/input/misc/da9063_onkey.c requires an interrupt
> > to function.  I wonder if it can be made to work using a timer and pure
> > polling...
>
> Yes, that is possible by either adding a debugfs to enable polling for testing.
>
> Or
>
> a device tree property for adding poll delay, so that one can have polling support to test onkey driver.

I would go for the latter, cfr. poll-interval in
Documentation/devicetree/bindings/input/gpio-keys.yaml.

> Basically, on a production system we should avoid polling as it unnecessarily wakeup the system.

Wouldn't polling (by Linux) only happen when the system is already
awake?  I think the DA9063 itself handles the onkey when the system
is asleep.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From jaewon02.kim at samsung.com  Mon Dec 11 00:24:37 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Mon, 11 Dec 2023 17:24:37 +0900
Subject: [PATCH] dt-bindings: pinctrl: samsung: correct ExynosAutov920
 wake-up compatibles
In-Reply-To: <a441ca43-8631-4a6a-b828-6d744fce5aee@linaro.org>
References: <CGME20231210133927epcas2p3e2633ad371b03d5ab19f9b44118fcb58@epcas2p3.samsung.com>
	<20231210133915.42112-1-krzysztof.kozlowski@linaro.org>
	<c63bd0b3-ecb2-d4c6-2147-43f19c1dcfee@samsung.com>
	<a441ca43-8631-4a6a-b828-6d744fce5aee@linaro.org>
Message-ID: <4bc0bd93-130d-1293-eca6-46cf9ba85cd9@samsung.com>


On 23. 12. 11. 16:34, Krzysztof Kozlowski wrote:
> On 11/12/2023 03:18, Jaewon Kim wrote:
>> On 23. 12. 10. 22:39, Krzysztof Kozlowski wrote:
>>> ExynosAutov920 SoC wake-up pin controller has different register layout
>>> than Exynos7, thus it should not be marked as compatible.  Neither DTS
>>> nor Linux driver was merged yet, so the change does not impact ABI.
>>>
>>> Cc: Jaewon Kim <jaewon02.kim at samsung.com>
>>> Fixes: 904140fa4553 ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers")
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>>>
>>>
>> It is reasonable.
>>
>> I will also fix this in v4 patch.
>>
>>
>> Reviewed-by:Jaewon Kim <jaewon02.kim at samsung.com>
> Please send correct tags so I won't need to manually fix them. Otherwise
> they get ignored by b4.

Thanks Krzysztof

I miss space. I will check it again next time.

>
> Best regards,
> Krzysztof
>
>
>

Thanks

Jaewon Kim



From sean at mess.org  Mon Dec 11 00:24:54 2023
From: sean at mess.org (Sean Young)
Date: Mon, 11 Dec 2023 08:24:54 +0000
Subject: [PATCH v7 3/4] pwm: bcm2835: Allow PWM driver to be used in atomic context
In-Reply-To: <cover.1702282806.git.sean@mess.org>
References: <cover.1702282806.git.sean@mess.org>
Message-ID: <69e50d0df1dbb08122cd54af442063c0618fd4ee.1702282807.git.sean@mess.org>

clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
rate changes using clk_rate_exclusive_get().

Signed-off-by: Sean Young <sean at mess.org>
Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
---
 drivers/pwm/pwm-bcm2835.c | 31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index ab30667f4f951..309d52ec43bbe 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -28,6 +28,7 @@ struct bcm2835_pwm {
 	struct device *dev;
 	void __iomem *base;
 	struct clk *clk;
+	unsigned long rate;
 };
 
 static inline struct bcm2835_pwm *to_bcm2835_pwm(struct pwm_chip *chip)
@@ -63,17 +64,11 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 {
 
 	struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
-	unsigned long rate = clk_get_rate(pc->clk);
 	unsigned long long period_cycles;
 	u64 max_period;
 
 	u32 val;
 
-	if (!rate) {
-		dev_err(pc->dev, "failed to get clock rate\n");
-		return -EINVAL;
-	}
-
 	/*
 	 * period_cycles must be a 32 bit value, so period * rate / NSEC_PER_SEC
 	 * must be <= U32_MAX. As U32_MAX * NSEC_PER_SEC < U64_MAX the
@@ -88,13 +83,13 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * <=> period < ((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate
 	 * <=> period <= ceil((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate) - 1
 	 */
-	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, rate) - 1;
+	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, pc->rate) - 1;
 
 	if (state->period > max_period)
 		return -EINVAL;
 
 	/* set period */
-	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * rate, NSEC_PER_SEC);
+	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * pc->rate, NSEC_PER_SEC);
 
 	/* don't accept a period that is too small */
 	if (period_cycles < PERIOD_MIN)
@@ -103,7 +98,7 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	writel(period_cycles, pc->base + PERIOD(pwm->hwpwm));
 
 	/* set duty cycle */
-	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * rate, NSEC_PER_SEC);
+	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * pc->rate, NSEC_PER_SEC);
 	writel(val, pc->base + DUTY(pwm->hwpwm));
 
 	/* set polarity */
@@ -151,16 +146,31 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
 				     "clock not found\n");
 
+	ret = clk_rate_exclusive_get(pc->clk);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret,
+				     "fail to get exclusive rate\n");
+
+	pc->rate = clk_get_rate(pc->clk);
+	if (!pc->rate) {
+		clk_rate_exclusive_put(pc->clk);
+		return dev_err_probe(&pdev->dev, -EINVAL,
+				     "failed to get clock rate\n");
+	}
+
 	pc->chip.dev = &pdev->dev;
 	pc->chip.ops = &bcm2835_pwm_ops;
+	pc->chip.atomic = true;
 	pc->chip.npwm = 2;
 
 	platform_set_drvdata(pdev, pc);
 
 	ret = devm_pwmchip_add(&pdev->dev, &pc->chip);
-	if (ret < 0)
+	if (ret < 0) {
+		clk_rate_exclusive_put(pc->clk);
 		return dev_err_probe(&pdev->dev, ret,
 				     "failed to add pwmchip\n");
+	}
 
 	return 0;
 }
@@ -169,6 +179,7 @@ static int bcm2835_pwm_suspend(struct device *dev)
 {
 	struct bcm2835_pwm *pc = dev_get_drvdata(dev);
 
+	clk_rate_exclusive_put(pc->clk);
 	clk_disable_unprepare(pc->clk);
 
 	return 0;
-- 
2.43.0



From sean at mess.org  Mon Dec 11 00:24:52 2023
From: sean at mess.org (Sean Young)
Date: Mon, 11 Dec 2023 08:24:52 +0000
Subject: [PATCH v7 1/4] pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
In-Reply-To: <cover.1702282806.git.sean@mess.org>
References: <cover.1702282806.git.sean@mess.org>
Message-ID: <f2762a5abc13be9ec05a45927bbd84e9da5bb41c.1702282807.git.sean@mess.org>

In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:

	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
	int pwm_apply_atomic(struct pwm *, struct pwm_state *);

This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.

Acked-by: Dmitry Torokhov <dmitry.torokhov at gmail.com> # for input
Acked-by: Hans de Goede <hdegoede at redhat.com>
Acked-by: Jani Nikula <jani.nikula at intel.com>
Acked-by: Lee Jones <lee at kernel.org>
Signed-off-by: Sean Young <sean at mess.org>
---
 Documentation/driver-api/pwm.rst              |  8 +++---
 MAINTAINERS                                   |  2 +-
 .../gpu/drm/i915/display/intel_backlight.c    |  6 ++--
 drivers/gpu/drm/solomon/ssd130x.c             |  2 +-
 drivers/hwmon/pwm-fan.c                       |  8 +++---
 drivers/input/misc/da7280.c                   |  4 +--
 drivers/input/misc/pwm-beeper.c               |  4 +--
 drivers/input/misc/pwm-vibra.c                |  8 +++---
 drivers/leds/leds-pwm.c                       |  2 +-
 drivers/leds/rgb/leds-pwm-multicolor.c        |  4 +--
 drivers/media/rc/pwm-ir-tx.c                  |  4 +--
 drivers/platform/x86/lenovo-yogabook.c        |  2 +-
 drivers/pwm/core.c                            | 18 ++++++------
 drivers/pwm/pwm-twl-led.c                     |  2 +-
 drivers/pwm/pwm-vt8500.c                      |  2 +-
 drivers/pwm/sysfs.c                           | 10 +++----
 drivers/regulator/pwm-regulator.c             |  4 +--
 drivers/video/backlight/lm3630a_bl.c          |  2 +-
 drivers/video/backlight/lp855x_bl.c           |  2 +-
 drivers/video/backlight/pwm_bl.c              | 12 ++++----
 drivers/video/fbdev/ssd1307fb.c               |  2 +-
 include/linux/pwm.h                           | 28 +++++++++----------
 22 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index bb264490a87a1..f1d8197c8c430 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -41,7 +41,7 @@ the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also exist.
 
 After being requested, a PWM has to be configured using::
 
-	int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
+	int pwm_apply_might_sleep(struct pwm_device *pwm, struct pwm_state *state);
 
 This API controls both the PWM period/duty_cycle config and the
 enable/disable state.
@@ -57,13 +57,13 @@ If supported by the driver, the signal can be optimized, for example to improve
 EMI by phase shifting the individual channels of a chip.
 
 The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
-around pwm_apply_state() and should not be used if the user wants to change
+around pwm_apply_might_sleep() and should not be used if the user wants to change
 several parameter at once. For example, if you see pwm_config() and
 pwm_{enable,disable}() calls in the same function, this probably means you
-should switch to pwm_apply_state().
+should switch to pwm_apply_might_sleep().
 
 The PWM user API also allows one to query the PWM state that was passed to the
-last invocation of pwm_apply_state() using pwm_get_state(). Note this is
+last invocation of pwm_apply_might_sleep() using pwm_get_state(). Note this is
 different to what the driver has actually implemented if the request cannot be
 satisfied exactly with the hardware in use. There is currently no way for
 consumers to get the actually implemented settings.
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d96db7e1a9e4..c2a9e0b5594e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17585,7 +17585,7 @@ F:	drivers/video/backlight/pwm_bl.c
 F:	include/dt-bindings/pwm/
 F:	include/linux/pwm.h
 F:	include/linux/pwm_backlight.h
-K:	pwm_(config|apply_state|ops)
+K:	pwm_(config|apply_might_sleep|ops)
 
 PXA GPIO DRIVER
 M:	Robert Jarzmik <robert.jarzmik at free.fr>
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c b/drivers/gpu/drm/i915/display/intel_backlight.c
index 2e8f17c045222..ff9b9918b0a13 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -274,7 +274,7 @@ static void ext_pwm_set_backlight(const struct drm_connector_state *conn_state,
 	struct intel_panel *panel = &to_intel_connector(conn_state->connector)->panel;
 
 	pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 static void
@@ -427,7 +427,7 @@ static void ext_pwm_disable_backlight(const struct drm_connector_state *old_conn
 	intel_backlight_set_pwm_level(old_conn_state, level);
 
 	panel->backlight.pwm_state.enabled = false;
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 void intel_backlight_disable(const struct drm_connector_state *old_conn_state)
@@ -749,7 +749,7 @@ static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
 
 	pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
 	panel->backlight.pwm_state.enabled = true;
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 static void __intel_backlight_enable(const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c
index e0174f82e3537..cce043a4a1dcd 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -319,7 +319,7 @@ static int ssd130x_pwm_enable(struct ssd130x_device *ssd130x)
 
 	pwm_init_state(ssd130x->pwm, &pwmstate);
 	pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
-	pwm_apply_state(ssd130x->pwm, &pwmstate);
+	pwm_apply_might_sleep(ssd130x->pwm, &pwmstate);
 
 	/* Enable the PWM */
 	pwm_enable(ssd130x->pwm);
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 6e4516c2ab894..b67bc9e833c01 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -151,7 +151,7 @@ static int pwm_fan_power_on(struct pwm_fan_ctx *ctx)
 	}
 
 	state->enabled = true;
-	ret = pwm_apply_state(ctx->pwm, state);
+	ret = pwm_apply_might_sleep(ctx->pwm, state);
 	if (ret) {
 		dev_err(ctx->dev, "failed to enable PWM\n");
 		goto disable_regulator;
@@ -181,7 +181,7 @@ static int pwm_fan_power_off(struct pwm_fan_ctx *ctx)
 
 	state->enabled = false;
 	state->duty_cycle = 0;
-	ret = pwm_apply_state(ctx->pwm, state);
+	ret = pwm_apply_might_sleep(ctx->pwm, state);
 	if (ret) {
 		dev_err(ctx->dev, "failed to disable PWM\n");
 		return ret;
@@ -207,7 +207,7 @@ static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
 
 		period = state->period;
 		state->duty_cycle = DIV_ROUND_UP(pwm * (period - 1), MAX_PWM);
-		ret = pwm_apply_state(ctx->pwm, state);
+		ret = pwm_apply_might_sleep(ctx->pwm, state);
 		if (ret)
 			return ret;
 		ret = pwm_fan_power_on(ctx);
@@ -278,7 +278,7 @@ static int pwm_fan_update_enable(struct pwm_fan_ctx *ctx, long val)
 						    state,
 						    &enable_regulator);
 
-			pwm_apply_state(ctx->pwm, state);
+			pwm_apply_might_sleep(ctx->pwm, state);
 			pwm_fan_switch_power(ctx, enable_regulator);
 			pwm_fan_update_state(ctx, 0);
 		}
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
index ce82548916bbc..c1fa75c0f970a 100644
--- a/drivers/input/misc/da7280.c
+++ b/drivers/input/misc/da7280.c
@@ -352,7 +352,7 @@ static int da7280_haptic_set_pwm(struct da7280_haptic *haptics, bool enabled)
 		state.duty_cycle = period_mag_multi;
 	}
 
-	error = pwm_apply_state(haptics->pwm_dev, &state);
+	error = pwm_apply_might_sleep(haptics->pwm_dev, &state);
 	if (error)
 		dev_err(haptics->dev, "Failed to apply pwm state: %d\n", error);
 
@@ -1175,7 +1175,7 @@ static int da7280_probe(struct i2c_client *client)
 		/* Sync up PWM state and ensure it is off. */
 		pwm_init_state(haptics->pwm_dev, &state);
 		state.enabled = false;
-		error = pwm_apply_state(haptics->pwm_dev, &state);
+		error = pwm_apply_might_sleep(haptics->pwm_dev, &state);
 		if (error) {
 			dev_err(dev, "Failed to apply PWM state: %d\n", error);
 			return error;
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 1e731d8397c6f..5b9aedf4362f4 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -39,7 +39,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
 	state.period = period;
 	pwm_set_relative_duty_cycle(&state, 50, 100);
 
-	error = pwm_apply_state(beeper->pwm, &state);
+	error = pwm_apply_might_sleep(beeper->pwm, &state);
 	if (error)
 		return error;
 
@@ -138,7 +138,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
 	/* Sync up PWM state and ensure it is off. */
 	pwm_init_state(beeper->pwm, &state);
 	state.enabled = false;
-	error = pwm_apply_state(beeper->pwm, &state);
+	error = pwm_apply_might_sleep(beeper->pwm, &state);
 	if (error) {
 		dev_err(dev, "failed to apply initial PWM state: %d\n",
 			error);
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index acac79c488aa1..3e5ed685ed8f5 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -56,7 +56,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 	pwm_set_relative_duty_cycle(&state, vibrator->level, 0xffff);
 	state.enabled = true;
 
-	err = pwm_apply_state(vibrator->pwm, &state);
+	err = pwm_apply_might_sleep(vibrator->pwm, &state);
 	if (err) {
 		dev_err(pdev, "failed to apply pwm state: %d\n", err);
 		return err;
@@ -67,7 +67,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 		state.duty_cycle = vibrator->direction_duty_cycle;
 		state.enabled = true;
 
-		err = pwm_apply_state(vibrator->pwm_dir, &state);
+		err = pwm_apply_might_sleep(vibrator->pwm_dir, &state);
 		if (err) {
 			dev_err(pdev, "failed to apply dir-pwm state: %d\n", err);
 			pwm_disable(vibrator->pwm);
@@ -160,7 +160,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
 	/* Sync up PWM state and ensure it is off. */
 	pwm_init_state(vibrator->pwm, &state);
 	state.enabled = false;
-	err = pwm_apply_state(vibrator->pwm, &state);
+	err = pwm_apply_might_sleep(vibrator->pwm, &state);
 	if (err) {
 		dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 			err);
@@ -174,7 +174,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
 		/* Sync up PWM state and ensure it is off. */
 		pwm_init_state(vibrator->pwm_dir, &state);
 		state.enabled = false;
-		err = pwm_apply_state(vibrator->pwm_dir, &state);
+		err = pwm_apply_might_sleep(vibrator->pwm_dir, &state);
 		if (err) {
 			dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 				err);
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 2b3bf1353b707..4e3936a39d0ed 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -54,7 +54,7 @@ static int led_pwm_set(struct led_classdev *led_cdev,
 
 	led_dat->pwmstate.duty_cycle = duty;
 	led_dat->pwmstate.enabled = true;
-	return pwm_apply_state(led_dat->pwm, &led_dat->pwmstate);
+	return pwm_apply_might_sleep(led_dat->pwm, &led_dat->pwmstate);
 }
 
 __attribute__((nonnull))
diff --git a/drivers/leds/rgb/leds-pwm-multicolor.c b/drivers/leds/rgb/leds-pwm-multicolor.c
index 46cd062b8b24c..e1a81e0109e8a 100644
--- a/drivers/leds/rgb/leds-pwm-multicolor.c
+++ b/drivers/leds/rgb/leds-pwm-multicolor.c
@@ -51,8 +51,8 @@ static int led_pwm_mc_set(struct led_classdev *cdev,
 
 		priv->leds[i].state.duty_cycle = duty;
 		priv->leds[i].state.enabled = duty > 0;
-		ret = pwm_apply_state(priv->leds[i].pwm,
-				      &priv->leds[i].state);
+		ret = pwm_apply_might_sleep(priv->leds[i].pwm,
+					    &priv->leds[i].state);
 		if (ret)
 			break;
 	}
diff --git a/drivers/media/rc/pwm-ir-tx.c b/drivers/media/rc/pwm-ir-tx.c
index c5f37c03af9c9..cf51e27609759 100644
--- a/drivers/media/rc/pwm-ir-tx.c
+++ b/drivers/media/rc/pwm-ir-tx.c
@@ -68,7 +68,7 @@ static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
 
 	for (i = 0; i < count; i++) {
 		state.enabled = !(i % 2);
-		pwm_apply_state(pwm, &state);
+		pwm_apply_might_sleep(pwm, &state);
 
 		edge = ktime_add_us(edge, txbuf[i]);
 		delta = ktime_us_delta(edge, ktime_get());
@@ -77,7 +77,7 @@ static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
 	}
 
 	state.enabled = false;
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 
 	return count;
 }
diff --git a/drivers/platform/x86/lenovo-yogabook.c b/drivers/platform/x86/lenovo-yogabook.c
index b8d0239192cbf..fd62bf746ebde 100644
--- a/drivers/platform/x86/lenovo-yogabook.c
+++ b/drivers/platform/x86/lenovo-yogabook.c
@@ -435,7 +435,7 @@ static int yogabook_pdev_set_kbd_backlight(struct yogabook_data *data, u8 level)
 		.enabled = level,
 	};
 
-	pwm_apply_state(data->kbd_bl_pwm, &state);
+	pwm_apply_might_sleep(data->kbd_bl_pwm, &state);
 	gpiod_set_value(data->kbd_bl_led_enable, level ? 1 : 0);
 	return 0;
 }
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f60b715abe62b..c2d78136625d5 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -326,8 +326,8 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
 }
 EXPORT_SYMBOL_GPL(pwm_request_from_chip);
 
-static void pwm_apply_state_debug(struct pwm_device *pwm,
-				  const struct pwm_state *state)
+static void pwm_apply_debug(struct pwm_device *pwm,
+			    const struct pwm_state *state)
 {
 	struct pwm_state *last = &pwm->last;
 	struct pwm_chip *chip = pwm->chip;
@@ -433,11 +433,11 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
 }
 
 /**
- * pwm_apply_state() - atomically apply a new state to a PWM device
+ * pwm_apply_might_sleep() - atomically apply a new state to a PWM device
  * @pwm: PWM device
  * @state: new state to apply
  */
-int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
+int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state)
 {
 	struct pwm_chip *chip;
 	int err;
@@ -445,7 +445,7 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	/*
 	 * Some lowlevel driver's implementations of .apply() make use of
 	 * mutexes, also with some drivers only returning when the new
-	 * configuration is active calling pwm_apply_state() from atomic context
+	 * configuration is active calling pwm_apply_might_sleep() from atomic context
 	 * is a bad idea. So make it explicit that calling this function might
 	 * sleep.
 	 */
@@ -475,11 +475,11 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	 * only do this after pwm->state was applied as some
 	 * implementations of .get_state depend on this
 	 */
-	pwm_apply_state_debug(pwm, state);
+	pwm_apply_debug(pwm, state);
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(pwm_apply_state);
+EXPORT_SYMBOL_GPL(pwm_apply_might_sleep);
 
 /**
  * pwm_capture() - capture and report a PWM signal
@@ -537,7 +537,7 @@ int pwm_adjust_config(struct pwm_device *pwm)
 		state.period = pargs.period;
 		state.polarity = pargs.polarity;
 
-		return pwm_apply_state(pwm, &state);
+		return pwm_apply_might_sleep(pwm, &state);
 	}
 
 	/*
@@ -560,7 +560,7 @@ int pwm_adjust_config(struct pwm_device *pwm)
 		state.duty_cycle = state.period - state.duty_cycle;
 	}
 
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 EXPORT_SYMBOL_GPL(pwm_adjust_config);
 
diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
index 8a870d0db3c69..c670ccb816536 100644
--- a/drivers/pwm/pwm-twl-led.c
+++ b/drivers/pwm/pwm-twl-led.c
@@ -172,7 +172,7 @@ static int twl4030_pwmled_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * We cannot skip calling ->config even if state->period ==
 	 * pwm->state.period && state->duty_cycle == pwm->state.duty_cycle
 	 * because we might have exited early in the last call to
-	 * pwm_apply_state because of !state->enabled and so the two values in
+	 * pwm_apply_might_sleep because of !state->enabled and so the two values in
 	 * pwm->state might not be configured in hardware.
 	 */
 	ret = twl4030_pwmled_config(chip, pwm,
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index bdea60389487e..7bfeacee05d0f 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -206,7 +206,7 @@ static int vt8500_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * We cannot skip calling ->config even if state->period ==
 	 * pwm->state.period && state->duty_cycle == pwm->state.duty_cycle
 	 * because we might have exited early in the last call to
-	 * pwm_apply_state because of !state->enabled and so the two values in
+	 * pwm_apply_might_sleep because of !state->enabled and so the two values in
 	 * pwm->state might not be configured in hardware.
 	 */
 	err = vt8500_pwm_config(chip, pwm, state->duty_cycle, state->period);
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 4edb994fa2e12..1698609d91c8a 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -62,7 +62,7 @@ static ssize_t period_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.period = val;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -97,7 +97,7 @@ static ssize_t duty_cycle_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.duty_cycle = val;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -144,7 +144,7 @@ static ssize_t enable_store(struct device *child,
 		goto unlock;
 	}
 
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 
 unlock:
 	mutex_unlock(&export->lock);
@@ -194,7 +194,7 @@ static ssize_t polarity_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.polarity = polarity;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -401,7 +401,7 @@ static int pwm_class_apply_state(struct pwm_export *export,
 				 struct pwm_device *pwm,
 				 struct pwm_state *state)
 {
-	int ret = pwm_apply_state(pwm, state);
+	int ret = pwm_apply_might_sleep(pwm, state);
 
 	/* release lock taken in pwm_class_get_state */
 	mutex_unlock(&export->lock);
diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
index 2aff6db748e2c..698c420e0869b 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -90,7 +90,7 @@ static int pwm_regulator_set_voltage_sel(struct regulator_dev *rdev,
 	pwm_set_relative_duty_cycle(&pstate,
 			drvdata->duty_cycle_table[selector].dutycycle, 100);
 
-	ret = pwm_apply_state(drvdata->pwm, &pstate);
+	ret = pwm_apply_might_sleep(drvdata->pwm, &pstate);
 	if (ret) {
 		dev_err(&rdev->dev, "Failed to configure PWM: %d\n", ret);
 		return ret;
@@ -216,7 +216,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
 
 	pwm_set_relative_duty_cycle(&pstate, dutycycle, duty_unit);
 
-	ret = pwm_apply_state(drvdata->pwm, &pstate);
+	ret = pwm_apply_might_sleep(drvdata->pwm, &pstate);
 	if (ret) {
 		dev_err(&rdev->dev, "Failed to configure PWM: %d\n", ret);
 		return ret;
diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
index 8fcb62be597b8..a3412c936ca28 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -180,7 +180,7 @@ static int lm3630a_pwm_ctrl(struct lm3630a_chip *pchip, int br, int br_max)
 
 	pchip->pwmd_state.enabled = pchip->pwmd_state.duty_cycle ? true : false;
 
-	return pwm_apply_state(pchip->pwmd, &pchip->pwmd_state);
+	return pwm_apply_might_sleep(pchip->pwmd, &pchip->pwmd_state);
 }
 
 /* update and get brightness */
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
index da1f124db69c0..7075bfab59c4d 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -234,7 +234,7 @@ static int lp855x_pwm_ctrl(struct lp855x *lp, int br, int max_br)
 	state.duty_cycle = div_u64(br * state.period, max_br);
 	state.enabled = state.duty_cycle;
 
-	return pwm_apply_state(lp->pwm, &state);
+	return pwm_apply_might_sleep(lp->pwm, &state);
 }
 
 static int lp855x_bl_update_status(struct backlight_device *bl)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 289bd9ce4d36d..35c716e9043c3 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -103,7 +103,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		pwm_get_state(pb->pwm, &state);
 		state.duty_cycle = compute_duty_cycle(pb, brightness, &state);
 		state.enabled = true;
-		pwm_apply_state(pb->pwm, &state);
+		pwm_apply_might_sleep(pb->pwm, &state);
 
 		pwm_backlight_power_on(pb);
 	} else {
@@ -120,7 +120,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		 * inactive output.
 		 */
 		state.enabled = !pb->power_supply && !pb->enable_gpio;
-		pwm_apply_state(pb->pwm, &state);
+		pwm_apply_might_sleep(pb->pwm, &state);
 	}
 
 	if (pb->notify_after)
@@ -528,7 +528,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 	if (!state.period && (data->pwm_period_ns > 0))
 		state.period = data->pwm_period_ns;
 
-	ret = pwm_apply_state(pb->pwm, &state);
+	ret = pwm_apply_might_sleep(pb->pwm, &state);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 			ret);
@@ -633,7 +633,7 @@ static void pwm_backlight_remove(struct platform_device *pdev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 
 	if (pb->exit)
 		pb->exit(&pdev->dev);
@@ -649,7 +649,7 @@ static void pwm_backlight_shutdown(struct platform_device *pdev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -673,7 +673,7 @@ static int pwm_backlight_suspend(struct device *dev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 
 	if (pb->notify_after)
 		pb->notify_after(pb->dev, 0);
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 5ae48e36fccb4..1a4f90ea7d5a8 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -347,7 +347,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
 
 		pwm_init_state(par->pwm, &pwmstate);
 		pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
-		pwm_apply_state(par->pwm, &pwmstate);
+		pwm_apply_might_sleep(par->pwm, &pwmstate);
 
 		/* Enable the PWM */
 		pwm_enable(par->pwm);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index f87655c06c825..b64b8a82415c4 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -92,8 +92,8 @@ struct pwm_device {
  * @state: state to fill with the current PWM state
  *
  * The returned PWM state represents the state that was applied by a previous call to
- * pwm_apply_state(). Drivers may have to slightly tweak that state before programming it to
- * hardware. If pwm_apply_state() was never called, this returns either the current hardware
+ * pwm_apply_might_sleep(). Drivers may have to slightly tweak that state before programming it to
+ * hardware. If pwm_apply_might_sleep() was never called, this returns either the current hardware
  * state (if supported) or the default settings.
  */
 static inline void pwm_get_state(const struct pwm_device *pwm,
@@ -157,20 +157,20 @@ static inline void pwm_get_args(const struct pwm_device *pwm,
 }
 
 /**
- * pwm_init_state() - prepare a new state to be applied with pwm_apply_state()
+ * pwm_init_state() - prepare a new state to be applied with pwm_apply_might_sleep()
  * @pwm: PWM device
  * @state: state to fill with the prepared PWM state
  *
  * This functions prepares a state that can later be tweaked and applied
- * to the PWM device with pwm_apply_state(). This is a convenient function
+ * to the PWM device with pwm_apply_might_sleep(). This is a convenient function
  * that first retrieves the current PWM state and the replaces the period
  * and polarity fields with the reference values defined in pwm->args.
  * Once the function returns, you can adjust the ->enabled and ->duty_cycle
- * fields according to your needs before calling pwm_apply_state().
+ * fields according to your needs before calling pwm_apply_might_sleep().
  *
  * ->duty_cycle is initially set to zero to avoid cases where the current
  * ->duty_cycle value exceed the pwm_args->period one, which would trigger
- * an error if the user calls pwm_apply_state() without adjusting ->duty_cycle
+ * an error if the user calls pwm_apply_might_sleep() without adjusting ->duty_cycle
  * first.
  */
 static inline void pwm_init_state(const struct pwm_device *pwm,
@@ -226,7 +226,7 @@ pwm_get_relative_duty_cycle(const struct pwm_state *state, unsigned int scale)
  *
  * pwm_init_state(pwm, &state);
  * pwm_set_relative_duty_cycle(&state, 50, 100);
- * pwm_apply_state(pwm, &state);
+ * pwm_apply_might_sleep(pwm, &state);
  *
  * This functions returns -EINVAL if @duty_cycle and/or @scale are
  * inconsistent (@scale == 0 or @duty_cycle > @scale).
@@ -304,7 +304,7 @@ struct pwm_chip {
 
 #if IS_ENABLED(CONFIG_PWM)
 /* PWM user APIs */
-int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state);
+int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state);
 int pwm_adjust_config(struct pwm_device *pwm);
 
 /**
@@ -332,7 +332,7 @@ static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
 
 	state.duty_cycle = duty_ns;
 	state.period = period_ns;
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 
 /**
@@ -353,7 +353,7 @@ static inline int pwm_enable(struct pwm_device *pwm)
 		return 0;
 
 	state.enabled = true;
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 
 /**
@@ -372,7 +372,7 @@ static inline void pwm_disable(struct pwm_device *pwm)
 		return;
 
 	state.enabled = false;
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 }
 
 /* PWM provider APIs */
@@ -403,8 +403,8 @@ struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
 				       struct fwnode_handle *fwnode,
 				       const char *con_id);
 #else
-static inline int pwm_apply_state(struct pwm_device *pwm,
-				  const struct pwm_state *state)
+static inline int pwm_apply_might_sleep(struct pwm_device *pwm,
+					const struct pwm_state *state)
 {
 	might_sleep();
 	return -ENOTSUPP;
@@ -521,7 +521,7 @@ static inline void pwm_apply_args(struct pwm_device *pwm)
 	state.period = pwm->args.period;
 	state.usage_power = false;
 
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 }
 
 struct pwm_lookup {
-- 
2.43.0



From sean at mess.org  Mon Dec 11 00:30:10 2023
From: sean at mess.org (Sean Young)
Date: Mon, 11 Dec 2023 08:30:10 +0000
Subject: [PATCH v6 1/4] pwm: rename pwm_apply_state() to
 pwm_apply_might_sleep()
In-Reply-To: <20231209135742.3ieusuq3h3xlvjfn@pengutronix.de>
References: <cover.1701248996.git.sean@mess.org>
 <37090c1d8d8f42f1e12fa84942027d995189a99e.1701248996.git.sean@mess.org>
 <20231209135742.3ieusuq3h3xlvjfn@pengutronix.de>
Message-ID: <ZXbIknpNVxb5Mh2B@gofer.mess.org>

On Sat, Dec 09, 2023 at 02:57:42PM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Nov 29, 2023 at 09:13:34AM +0000, Sean Young wrote:
> > In order to introduce a pwm api which can be used from atomic context,
> > we will need two functions for applying pwm changes:
> > 
> > 	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
> > 	int pwm_apply_atomic(struct pwm *, struct pwm_state *);
> > 
> > This commit just deals with renaming pwm_apply_state(), a following
> > commit will introduce the pwm_apply_atomic() function.
> > 
> > Acked-by: Hans de Goede <hdegoede at redhat.com>
> > Acked-by: Jani Nikula <jani.nikula at intel.com>
> > Acked-by: Lee Jones <lee at kernel.org>
> > Signed-off-by: Sean Young <sean at mess.org>
> 
> Not a in-detail-review, but I just noticed again, that we have
> 
> 	K:      pwm_(config|apply_state|ops)
> 
> in MAINTAINERS. That one needs adaption, too.

Fixed in v7.

Thanks,

Sean


From biju.das.jz at bp.renesas.com  Mon Dec 11 00:32:32 2023
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Mon, 11 Dec 2023 08:32:32 +0000
Subject: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
In-Reply-To: <CAMuHMdU2pdAYbXdyfpysPR0k7fjh31KrD9Xk05EHWeayzVDz5g@mail.gmail.com>
References: <20231201110840.37408-1-biju.das.jz@bp.renesas.com>
 <20231201110840.37408-7-biju.das.jz@bp.renesas.com>
 <CAMuHMdWh3fTzQP5+mGF3u8LACg-5tQDZcyExvgREpxKd6iee4Q@mail.gmail.com>
 <TYCPR01MB112696C301D750A915F2661688681A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <CAMuHMdXHpE079eLAJjcdsbz6=Y6hux267AhqJow6HESCaf7EXQ@mail.gmail.com>
 <TYCPR01MB112693C2B72B6AA28766FF8EA8688A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <CAMuHMdU2pdAYbXdyfpysPR0k7fjh31KrD9Xk05EHWeayzVDz5g@mail.gmail.com>
Message-ID: <TYCPR01MB1126926DCFDB193E669C9CF8C868FA@TYCPR01MB11269.jpnprd01.prod.outlook.com>

Hi Geert,

> -----Original Message-----
> From: Geert Uytterhoeven <geert at linux-m68k.org>
> Sent: Monday, December 11, 2023 8:20 AM
> Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
> 
> Hi Biju,
> 
> On Sun, Dec 10, 2023 at 10:50?AM Biju Das <biju.das.jz at bp.renesas.com>
> wrote:
> > > -----Original Message-----
> > > From: Geert Uytterhoeven <geert at linux-m68k.org>
> > > Sent: Friday, December 1, 2023 3:42 PM
> > > Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062
> > > defconfig
> > >
> > > On Fri, Dec 1, 2023 at 4:02?PM Biju Das <biju.das.jz at bp.renesas.com>
> > > wrote:
> > > > > From: Geert Uytterhoeven <geert at linux-m68k.org> On Fri, Dec 1,
> > > > > 2023 at 12:09?PM Biju Das <biju.das.jz at bp.renesas.com>
> > > > > wrote:
> > > > > > Enable the config for the Renesas DA9062 PMIC and RTC, as it
> > > > > > is populated on RZ/G2UL SMARC EVK.
> > > > > >
> > > > > > Signed-off-by: Biju Das <biju.das.jz at bp.renesas.com>
> > > > >
> > > > > Thanks for your patch!
> > > > >
> > > > > LGTM, but I would have expected (at least)
> > > > >
> > > > >     CONFIG_INPUT_DA9063_ONKEY=m
> > > > >
> > > > > too, cfr. my comments on patch 5/6.
> > > >
> > > > I have tested this, but I get "da9063-onkey da9062-onkey: error -
> ENXIO:
> > > IRQ ONKEY not found"
> > > > So, I won't be able to test onkey events. So plaaning to disable
> > > > this
> > > node.
> > >
> > > Indeed, currently drivers/input/misc/da9063_onkey.c requires an
> > > interrupt to function.  I wonder if it can be made to work using a
> > > timer and pure polling...
> >
> > Yes, that is possible by either adding a debugfs to enable polling for
> testing.
> >
> > Or
> >
> > a device tree property for adding poll delay, so that one can have
> polling support to test onkey driver.
> 
> I would go for the latter, cfr. poll-interval in
> Documentation/devicetree/bindings/input/gpio-keys.yaml.
> 
> > Basically, on a production system we should avoid polling as it
> unnecessarily wakeup the system.
> 
> Wouldn't polling (by Linux) only happen when the system is already awake?

IIUC, That is an overhead. If there is no load, system goes to suspend mode and
the timer for the polling (SCAN keys) will wakeup the system and same 
process repeats. If we have a PMIC IRQ, this won't happen.

> I think the DA9063 itself handles the onkey when the system is asleep.

I will ask HW person to wire IRQ on PMIC, so that I can check the behaviour.

Cheers,
Biju




From lukas.varga at venturelinkage.com  Mon Dec 11 00:36:27 2023
From: lukas.varga at venturelinkage.com (Lukas Varga)
Date: Mon, 11 Dec 2023 08:36:27 GMT
Subject: =?UTF-8?Q?Popt=C3=A1vka?=
Message-ID: <20231211084500-0.1.25.5dqg.0.4k358jmnoe@venturelinkage.com>

Dobr? r?no,

Dovolil jsem si V?s kontaktovat, proto?e m?m z?jem ov??it mo?nost nav?z?n? spolupr?ce.

Podporujeme firmy p?i z?sk?v?n? nov?ch obchodn?ch z?kazn?k?.

M??eme si promluvit a poskytnout podrobnosti?

V p??pad? z?jmu V?s bude kontaktovat n?? anglicky mluv?c? z?stupce.


Pozdravy
Lukas Varga


From quic_snehshah at quicinc.com  Mon Dec 11 00:40:54 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Mon, 11 Dec 2023 14:10:54 +0530
Subject: [PATCH net v3] net: stmmac: update Rx clk divider for 10M SGMII
In-Reply-To: <5luxwdjyzkg5o6w27mqixggr65ebosnn53vaqrbtsclfudet4v@kse23pgyj7ld>
References: <20231208062502.13124-1-quic_snehshah@quicinc.com>
 <5luxwdjyzkg5o6w27mqixggr65ebosnn53vaqrbtsclfudet4v@kse23pgyj7ld>
Message-ID: <9d8250a9-8e00-4233-8bd9-9e49bd15fac5@quicinc.com>



On 12/9/2023 9:54 AM, Bjorn Andersson wrote:
> On Fri, Dec 08, 2023 at 11:55:02AM +0530, Sneh Shah wrote:
>> SGMII 10MBPS mode needs RX clock divider to avoid drops in Rx.
>> Update configure SGMII function with rx clk divider programming.
> 
> Are you trying saying that the RX clock is completely wrong in 10MBps
> mode? Or is the RX clock good, but without some division of some other
> clock signal you loose some packets now and then?

Without the divider, Rx clock is completely wrong. All the packets will dropped.  
> 
> Please write your commit message such that it describe the actual
> problem you're having. This will help others to know if this fix is
> applicable to some issue they are seeing on their hardware, now and in
> the future.
> 
Rx clock divider is must for 10M SGMII to work for my hardware. Hence, It was mentioned that SGMII needs Rx clock divider for 10MBPS to work.
Will update the commit message to emphasize on how rx clock is completely wrong without this.
>>
>> Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
>> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
>> ---
>> v3 changelog:
>> - Added comment to explain why MAC needs to be reconfigured for SGMII
>> v2 changelog:
>> - Use FIELD_PREP to prepare bifield values in place of GENMASK
>> - Add fixes tag
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>> index d3bf42d0fceb..ab2245995bc6 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>> @@ -34,6 +34,7 @@
>>  #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
>>  #define RGMII_CONFIG_PROG_SWAP			BIT(1)
>>  #define RGMII_CONFIG_DDR_MODE			BIT(0)
>> +#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)
> 
> This new bitfield overlaps with existing fields, is it the same
> register? Did the fields move? Is it applicable to all versions?
> 
It is same register but bitfield is moved for new SGMII based HW version. Not applicable to older version. few bitfields of older HW version's RGMII register are repurposed in the new hw version for SGMII config.

> What will existing writes to RGMII_IO_MACRO_CONFIG do to this new
> layout? What will the new write do to hardware with the existing field
> layout?
> 
we have two functions to configure MAC IOMACRO interface.
1. ethqos_configure_sgmii( this used this new bifield) 2. ethqos_configure_rgmii ( this used old layout)
Old HW version uses ethqos_configure_rgmii only. New HW version used ethqos_configure_sgmii only.

Old HW version is not going to use this new layout. New HW version is not going to use old layout configuration.

>>  
>>  /* SDCC_HC_REG_DLL_CONFIG fields */
>>  #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
>> @@ -598,6 +599,9 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>>  	return 0;
>>  }
>>  
>> +/* On interface toggle MAC registetrs gets reset.
>> + * Configure MAC block for SGMII on ethernet phy link up
>> + */
>>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>>  {
>>  	int val;
>> @@ -617,6 +621,9 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>>  	case SPEED_10:
>>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
>> +		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
>> +			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR, 0x31),
> 
> Is this just a magic constant, or does 0x31 of some convenient unit?
> Could we give it name/define?
> 
It is just a constant based on programming guide of HW.  Will add a #define for it.
> Regards,
> Bjorn
> 
>> +			      RGMII_IO_MACRO_CONFIG);
>>  		break;
>>  	}
>>  
>> -- 
>> 2.17.1
>>
>>


From geert at linux-m68k.org  Mon Dec 11 00:52:38 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 11 Dec 2023 09:52:38 +0100
Subject: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
In-Reply-To: <TYCPR01MB1126926DCFDB193E669C9CF8C868FA@TYCPR01MB11269.jpnprd01.prod.outlook.com>
References: <20231201110840.37408-1-biju.das.jz@bp.renesas.com>
 <20231201110840.37408-7-biju.das.jz@bp.renesas.com> <CAMuHMdWh3fTzQP5+mGF3u8LACg-5tQDZcyExvgREpxKd6iee4Q@mail.gmail.com>
 <TYCPR01MB112696C301D750A915F2661688681A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <CAMuHMdXHpE079eLAJjcdsbz6=Y6hux267AhqJow6HESCaf7EXQ@mail.gmail.com>
 <TYCPR01MB112693C2B72B6AA28766FF8EA8688A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <CAMuHMdU2pdAYbXdyfpysPR0k7fjh31KrD9Xk05EHWeayzVDz5g@mail.gmail.com> <TYCPR01MB1126926DCFDB193E669C9CF8C868FA@TYCPR01MB11269.jpnprd01.prod.outlook.com>
Message-ID: <CAMuHMdUswKrzqgumyoJ3RYWEAUR9WOBzc12dVcCB1s79E-AMRw@mail.gmail.com>

Hi Biju,

On Mon, Dec 11, 2023 at 9:32?AM Biju Das <biju.das.jz at bp.renesas.com> wrote:
> > -----Original Message-----
> > From: Geert Uytterhoeven <geert at linux-m68k.org>
> > Sent: Monday, December 11, 2023 8:20 AM
> > Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
> >
> > On Sun, Dec 10, 2023 at 10:50?AM Biju Das <biju.das.jz at bp.renesas.com>
> > wrote:
> > > > -----Original Message-----
> > > > From: Geert Uytterhoeven <geert at linux-m68k.org>
> > > > Sent: Friday, December 1, 2023 3:42 PM
> > > > Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062
> > > > defconfig
> > > >
> > > > On Fri, Dec 1, 2023 at 4:02?PM Biju Das <biju.das.jz at bp.renesas.com>
> > > > wrote:
> > > > > > From: Geert Uytterhoeven <geert at linux-m68k.org> On Fri, Dec 1,
> > > > > > 2023 at 12:09?PM Biju Das <biju.das.jz at bp.renesas.com>
> > > > > > wrote:
> > > > > > > Enable the config for the Renesas DA9062 PMIC and RTC, as it
> > > > > > > is populated on RZ/G2UL SMARC EVK.
> > > > > > >
> > > > > > > Signed-off-by: Biju Das <biju.das.jz at bp.renesas.com>
> > > > > >
> > > > > > Thanks for your patch!
> > > > > >
> > > > > > LGTM, but I would have expected (at least)
> > > > > >
> > > > > >     CONFIG_INPUT_DA9063_ONKEY=m
> > > > > >
> > > > > > too, cfr. my comments on patch 5/6.
> > > > >
> > > > > I have tested this, but I get "da9063-onkey da9062-onkey: error -
> > ENXIO:
> > > > IRQ ONKEY not found"
> > > > > So, I won't be able to test onkey events. So plaaning to disable
> > > > > this
> > > > node.
> > > >
> > > > Indeed, currently drivers/input/misc/da9063_onkey.c requires an
> > > > interrupt to function.  I wonder if it can be made to work using a
> > > > timer and pure polling...
> > >
> > > Yes, that is possible by either adding a debugfs to enable polling for
> > testing.
> > >
> > > Or
> > >
> > > a device tree property for adding poll delay, so that one can have
> > polling support to test onkey driver.
> >
> > I would go for the latter, cfr. poll-interval in
> > Documentation/devicetree/bindings/input/gpio-keys.yaml.
> >
> > > Basically, on a production system we should avoid polling as it
> > unnecessarily wakeup the system.
> >
> > Wouldn't polling (by Linux) only happen when the system is already awake?
>
> IIUC, That is an overhead. If there is no load, system goes to suspend mode and
> the timer for the polling (SCAN keys) will wakeup the system and same
> process repeats. If we have a PMIC IRQ, this won't happen.

Ah, you mean idle. Yes, that does incur a (small) overhead (I guess
there are other timers running, too).
I don't think any timer runs when the system is suspended.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From jianjun.wang at mediatek.com  Mon Dec 11 00:52:55 2023
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Mon, 11 Dec 2023 16:52:55 +0800
Subject: [PATCH v2 2/3] PCI: mediatek-gen3: Do not break probe flow when MSI init fails
In-Reply-To: <20231211085256.31292-1-jianjun.wang@mediatek.com>
References: <20231211085256.31292-1-jianjun.wang@mediatek.com>
Message-ID: <20231211085256.31292-3-jianjun.wang@mediatek.com>

Since INTx can still work, the driver probe flow should not be broken by
MSI initialization failures. Additionally, moving the MSI initialization
code into a single function enhances readability.

Fixes: 1bdafba538be ("PCI: mediatek-gen3: Add MSI support")
Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
---
 drivers/pci/controller/pcie-mediatek-gen3.c | 68 ++++++++++-----------
 1 file changed, 33 insertions(+), 35 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index c1ae3d19ec9a..c6a6876d233a 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -649,59 +649,51 @@ static const struct irq_domain_ops intx_domain_ops = {
 	.map = mtk_pcie_intx_map,
 };
 
-static int mtk_pcie_init_irq_domains(struct mtk_gen3_pcie *pcie)
+static int mtk_pcie_init_msi(struct mtk_gen3_pcie *pcie)
 {
 	struct device *dev = pcie->dev;
-	struct device_node *intc_node, *node = dev->of_node;
-	int ret;
-
-	raw_spin_lock_init(&pcie->irq_lock);
-
-	/* Setup INTx */
-	intc_node = of_get_child_by_name(node, "interrupt-controller");
-	if (!intc_node) {
-		dev_err(dev, "missing interrupt-controller node\n");
-		return -ENODEV;
-	}
-
-	pcie->intx_domain = irq_domain_add_linear(intc_node, PCI_NUM_INTX,
-						  &intx_domain_ops, pcie);
-	if (!pcie->intx_domain) {
-		dev_err(dev, "failed to create INTx IRQ domain\n");
-		ret = -ENODEV;
-		goto out_put_node;
-	}
+	struct device_node *node = dev->of_node;
 
-	/* Setup MSI */
 	mutex_init(&pcie->lock);
 
 	pcie->msi_bottom_domain = irq_domain_add_linear(node, PCIE_MSI_IRQS_NUM,
 				  &mtk_msi_bottom_domain_ops, pcie);
 	if (!pcie->msi_bottom_domain) {
 		dev_err(dev, "failed to create MSI bottom domain\n");
-		ret = -ENODEV;
-		goto err_msi_bottom_domain;
+		return -ENODEV;
 	}
 
-	pcie->msi_domain = pci_msi_create_irq_domain(dev->fwnode,
-						     &mtk_msi_domain_info,
+	pcie->msi_domain = pci_msi_create_irq_domain(dev->fwnode, &mtk_msi_domain_info,
 						     pcie->msi_bottom_domain);
 	if (!pcie->msi_domain) {
 		dev_err(dev, "failed to create MSI domain\n");
-		ret = -ENODEV;
-		goto err_msi_domain;
+		irq_domain_remove(pcie->msi_bottom_domain);
+		return -ENODEV;
 	}
 
-	of_node_put(intc_node);
 	return 0;
+}
 
-err_msi_domain:
-	irq_domain_remove(pcie->msi_bottom_domain);
-err_msi_bottom_domain:
-	irq_domain_remove(pcie->intx_domain);
-out_put_node:
+static int mtk_pcie_init_intx(struct mtk_gen3_pcie *pcie)
+{
+	struct device *dev = pcie->dev;
+	struct device_node *intc_node, *node = dev->of_node;
+
+	intc_node = of_get_child_by_name(node, "interrupt-controller");
+	if (!intc_node) {
+		dev_err(dev, "missing interrupt-controller node\n");
+		return -ENODEV;
+	}
+
+	pcie->intx_domain = irq_domain_add_linear(intc_node, PCI_NUM_INTX,
+						  &intx_domain_ops, pcie);
 	of_node_put(intc_node);
-	return ret;
+	if (!pcie->intx_domain) {
+		dev_err(dev, "failed to create INTx IRQ domain\n");
+		return -ENODEV;
+	}
+
+	return 0;
 }
 
 static void mtk_pcie_irq_teardown(struct mtk_gen3_pcie *pcie)
@@ -774,10 +766,16 @@ static int mtk_pcie_setup_irq(struct mtk_gen3_pcie *pcie)
 	struct platform_device *pdev = to_platform_device(dev);
 	int err;
 
-	err = mtk_pcie_init_irq_domains(pcie);
+	raw_spin_lock_init(&pcie->irq_lock);
+
+	err = mtk_pcie_init_intx(pcie);
 	if (err)
 		return err;
 
+	err = mtk_pcie_init_msi(pcie);
+	if (err)
+		dev_warn(dev, "no MSI supported, only INTx available\n");
+
 	pcie->irq = platform_get_irq(pdev, 0);
 	if (pcie->irq < 0)
 		return pcie->irq;
-- 
2.18.0



From jianjun.wang at mediatek.com  Mon Dec 11 00:52:53 2023
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Mon, 11 Dec 2023 16:52:53 +0800
Subject: [PATCH v2 0/3] PCI: mediatek: Allocate MSI address with dmam_alloc_coherent()
Message-ID: <20231211085256.31292-1-jianjun.wang@mediatek.com>

These series of patches change the allocation of MSI address on MediaTek
platform, which uses dmam_alloc_coherent() to allocate the MSI address.

Changes in v2:
1. Add a separate patch for pcie-mediatek-gen3.c to prevent break the
   probe flow when MSI init fails.
2. Change the location of allocate the MSI address to prevent break the
   probe flow.

Jianjun Wang (3):
  PCI: mediatek: Allocate MSI address with dmam_alloc_coherent()
  PCI: mediatek-gen3: Do not break probe flow when MSI init fails
  PCI: mediatek-gen3: Allocate MSI address with dmam_alloc_coherent()

 drivers/pci/controller/pcie-mediatek-gen3.c | 126 +++++++++++---------
 drivers/pci/controller/pcie-mediatek.c      |  24 ++--
 2 files changed, 83 insertions(+), 67 deletions(-)

-- 
2.18.0



From jianjun.wang at mediatek.com  Mon Dec 11 00:52:56 2023
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Mon, 11 Dec 2023 16:52:56 +0800
Subject: [PATCH v2 3/3] PCI: mediatek-gen3: Allocate MSI address with dmam_alloc_coherent()
In-Reply-To: <20231211085256.31292-1-jianjun.wang@mediatek.com>
References: <20231211085256.31292-1-jianjun.wang@mediatek.com>
Message-ID: <20231211085256.31292-4-jianjun.wang@mediatek.com>

Use dmam_alloc_coherent() to allocate the MSI address, instead of using
static physical address.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
---
 drivers/pci/controller/pcie-mediatek-gen3.c | 72 ++++++++++++---------
 1 file changed, 41 insertions(+), 31 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index c6a6876d233a..7cfd7ef9ad95 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -120,7 +120,6 @@ struct mtk_msi_set {
  * struct mtk_gen3_pcie - PCIe port information
  * @dev: pointer to PCIe device
  * @base: IO mapped register base
- * @reg_base: physical register base
  * @mac_reset: MAC reset control
  * @phy_reset: PHY reset control
  * @phy: PHY controller block
@@ -139,7 +138,6 @@ struct mtk_msi_set {
 struct mtk_gen3_pcie {
 	struct device *dev;
 	void __iomem *base;
-	phys_addr_t reg_base;
 	struct reset_control *mac_reset;
 	struct reset_control *phy_reset;
 	struct phy *phy;
@@ -309,24 +307,8 @@ static int mtk_pcie_set_trans_table(struct mtk_gen3_pcie *pcie,
 
 static void mtk_pcie_enable_msi(struct mtk_gen3_pcie *pcie)
 {
-	int i;
 	u32 val;
 
-	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
-		struct mtk_msi_set *msi_set = &pcie->msi_sets[i];
-
-		msi_set->base = pcie->base + PCIE_MSI_SET_BASE_REG +
-				i * PCIE_MSI_SET_OFFSET;
-		msi_set->msg_addr = pcie->reg_base + PCIE_MSI_SET_BASE_REG +
-				    i * PCIE_MSI_SET_OFFSET;
-
-		/* Configure the MSI capture address */
-		writel_relaxed(lower_32_bits(msi_set->msg_addr), msi_set->base);
-		writel_relaxed(upper_32_bits(msi_set->msg_addr),
-			       pcie->base + PCIE_MSI_SET_ADDR_HI_BASE +
-			       i * PCIE_MSI_SET_ADDR_HI_OFFSET);
-	}
-
 	val = readl_relaxed(pcie->base + PCIE_MSI_SET_ENABLE_REG);
 	val |= PCIE_MSI_SET_ENABLE;
 	writel_relaxed(val, pcie->base + PCIE_MSI_SET_ENABLE_REG);
@@ -653,6 +635,29 @@ static int mtk_pcie_init_msi(struct mtk_gen3_pcie *pcie)
 {
 	struct device *dev = pcie->dev;
 	struct device_node *node = dev->of_node;
+	struct mtk_msi_set *msi_set;
+	void *msg_vaddr[PCIE_MSI_SET_NUM];
+	int i, j, ret = -ENODEV;
+
+	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
+		msi_set = &pcie->msi_sets[i];
+
+		msi_set->base = pcie->base + PCIE_MSI_SET_BASE_REG +
+				i * PCIE_MSI_SET_OFFSET;
+
+		msg_vaddr[i] = dmam_alloc_coherent(dev, sizeof(dma_addr_t),
+							 &msi_set->msg_addr, GFP_KERNEL);
+		if (!msg_vaddr[i]) {
+			dev_err(dev, "failed to alloc and map MSI address for set %d\n", i);
+			ret = -ENOMEM;
+			goto err_alloc_addr;
+		}
+
+		/* Configure the MSI capture address */
+		writel_relaxed(lower_32_bits(msi_set->msg_addr), msi_set->base);
+		writel_relaxed(upper_32_bits(msi_set->msg_addr), pcie->base +
+			       PCIE_MSI_SET_ADDR_HI_BASE + i * PCIE_MSI_SET_ADDR_HI_OFFSET);
+	}
 
 	mutex_init(&pcie->lock);
 
@@ -660,18 +665,24 @@ static int mtk_pcie_init_msi(struct mtk_gen3_pcie *pcie)
 				  &mtk_msi_bottom_domain_ops, pcie);
 	if (!pcie->msi_bottom_domain) {
 		dev_err(dev, "failed to create MSI bottom domain\n");
-		return -ENODEV;
+		goto err_alloc_addr;
 	}
 
 	pcie->msi_domain = pci_msi_create_irq_domain(dev->fwnode, &mtk_msi_domain_info,
 						     pcie->msi_bottom_domain);
-	if (!pcie->msi_domain) {
-		dev_err(dev, "failed to create MSI domain\n");
-		irq_domain_remove(pcie->msi_bottom_domain);
-		return -ENODEV;
+	if (pcie->msi_domain)
+		return 0;
+
+	dev_err(dev, "failed to create MSI domain\n");
+	irq_domain_remove(pcie->msi_bottom_domain);
+
+err_alloc_addr:
+	for (j = 0; j < i; j++) {
+		msi_set = &pcie->msi_sets[j];
+		dmam_free_coherent(dev, sizeof(dma_addr_t), msg_vaddr[j], msi_set->msg_addr);
 	}
 
-	return 0;
+	return ret;
 }
 
 static int mtk_pcie_init_intx(struct mtk_gen3_pcie *pcie)
@@ -789,20 +800,14 @@ static int mtk_pcie_parse_port(struct mtk_gen3_pcie *pcie)
 {
 	struct device *dev = pcie->dev;
 	struct platform_device *pdev = to_platform_device(dev);
-	struct resource *regs;
 	int ret;
 
-	regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pcie-mac");
-	if (!regs)
-		return -EINVAL;
-	pcie->base = devm_ioremap_resource(dev, regs);
+	pcie->base = devm_platform_ioremap_resource_byname(pdev, "pcie-mac");
 	if (IS_ERR(pcie->base)) {
 		dev_err(dev, "failed to map register base\n");
 		return PTR_ERR(pcie->base);
 	}
 
-	pcie->reg_base = regs->start;
-
 	pcie->phy_reset = devm_reset_control_get_optional_exclusive(dev, "phy");
 	if (IS_ERR(pcie->phy_reset)) {
 		ret = PTR_ERR(pcie->phy_reset);
@@ -1013,6 +1018,11 @@ static void mtk_pcie_irq_restore(struct mtk_gen3_pcie *pcie)
 	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
 		struct mtk_msi_set *msi_set = &pcie->msi_sets[i];
 
+		/* Configure the MSI capture address */
+		writel_relaxed(lower_32_bits(msi_set->msg_addr), msi_set->base);
+		writel_relaxed(upper_32_bits(msi_set->msg_addr), pcie->base +
+			       PCIE_MSI_SET_ADDR_HI_BASE + i * PCIE_MSI_SET_ADDR_HI_OFFSET);
+
 		writel_relaxed(msi_set->saved_irq_state,
 			       msi_set->base + PCIE_MSI_SET_ENABLE_OFFSET);
 	}
-- 
2.18.0



From jianjun.wang at mediatek.com  Mon Dec 11 00:52:54 2023
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Mon, 11 Dec 2023 16:52:54 +0800
Subject: [PATCH v2 1/3] PCI: mediatek: Allocate MSI address with dmam_alloc_coherent()
In-Reply-To: <20231211085256.31292-1-jianjun.wang@mediatek.com>
References: <20231211085256.31292-1-jianjun.wang@mediatek.com>
Message-ID: <20231211085256.31292-2-jianjun.wang@mediatek.com>

Use dmam_alloc_coherent() to allocate the MSI address, instead of using
virt_to_phys().

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
---
 drivers/pci/controller/pcie-mediatek.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 66a8f73296fc..2fb9e44369f8 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -178,6 +178,7 @@ struct mtk_pcie_soc {
  * @phy: pointer to PHY control block
  * @slot: port slot
  * @irq: GIC irq
+ * @msg_addr: MSI message address
  * @irq_domain: legacy INTx IRQ domain
  * @inner_domain: inner IRQ domain
  * @msi_domain: MSI IRQ domain
@@ -198,6 +199,7 @@ struct mtk_pcie_port {
 	struct phy *phy;
 	u32 slot;
 	int irq;
+	dma_addr_t msg_addr;
 	struct irq_domain *irq_domain;
 	struct irq_domain *inner_domain;
 	struct irq_domain *msi_domain;
@@ -394,12 +396,10 @@ static struct pci_ops mtk_pcie_ops_v2 = {
 static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
 {
 	struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
-	phys_addr_t addr;
 
 	/* MT2712/MT7622 only support 32-bit MSI addresses */
-	addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
 	msg->address_hi = 0;
-	msg->address_lo = lower_32_bits(addr);
+	msg->address_lo = lower_32_bits(port->msg_addr);
 
 	msg->data = data->hwirq;
 
@@ -494,6 +494,14 @@ static struct msi_domain_info mtk_msi_domain_info = {
 static int mtk_pcie_allocate_msi_domains(struct mtk_pcie_port *port)
 {
 	struct fwnode_handle *fwnode = of_node_to_fwnode(port->pcie->dev->of_node);
+	void *msi_vaddr;
+
+	msi_vaddr = dmam_alloc_coherent(port->pcie->dev, sizeof(dma_addr_t), &port->msg_addr,
+					GFP_KERNEL);
+	if (!msi_vaddr) {
+		dev_err(port->pcie->dev, "failed to alloc and map MSI address\n");
+		return -ENOMEM;
+	}
 
 	mutex_init(&port->lock);
 
@@ -501,6 +509,7 @@ static int mtk_pcie_allocate_msi_domains(struct mtk_pcie_port *port)
 						      &msi_domain_ops, port);
 	if (!port->inner_domain) {
 		dev_err(port->pcie->dev, "failed to create IRQ domain\n");
+		dmam_free_coherent(port->pcie->dev, sizeof(dma_addr_t), msi_vaddr, port->msg_addr);
 		return -ENOMEM;
 	}
 
@@ -508,6 +517,7 @@ static int mtk_pcie_allocate_msi_domains(struct mtk_pcie_port *port)
 						     port->inner_domain);
 	if (!port->msi_domain) {
 		dev_err(port->pcie->dev, "failed to create MSI domain\n");
+		dmam_free_coherent(port->pcie->dev, sizeof(dma_addr_t), msi_vaddr, port->msg_addr);
 		irq_domain_remove(port->inner_domain);
 		return -ENOMEM;
 	}
@@ -518,10 +528,8 @@ static int mtk_pcie_allocate_msi_domains(struct mtk_pcie_port *port)
 static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
 {
 	u32 val;
-	phys_addr_t msg_addr;
 
-	msg_addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
-	val = lower_32_bits(msg_addr);
+	val = lower_32_bits(port->msg_addr);
 	writel(val, port->base + PCIE_IMSI_ADDR);
 
 	val = readl(port->base + PCIE_INT_MASK);
@@ -588,7 +596,7 @@ static int mtk_pcie_init_irq_domain(struct mtk_pcie_port *port,
 	if (IS_ENABLED(CONFIG_PCI_MSI)) {
 		ret = mtk_pcie_allocate_msi_domains(port);
 		if (ret)
-			return ret;
+			dev_warn(dev, "no MSI supported, only INTx available\n");
 	}
 
 	return 0;
@@ -732,7 +740,7 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
 	val &= ~INTX_MASK;
 	writel(val, port->base + PCIE_INT_MASK);
 
-	if (IS_ENABLED(CONFIG_PCI_MSI))
+	if (IS_ENABLED(CONFIG_PCI_MSI) && port->msi_domain)
 		mtk_pcie_enable_msi(port);
 
 	/* Set AHB to PCIe translation windows */
-- 
2.18.0



From nicolas.ferre at microchip.com  Mon Dec 11 00:57:39 2023
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Mon, 11 Dec 2023 09:57:39 +0100
Subject: [PATCH 01/12] hwrng: atmel - Convert to platform remove callback
 returning void
In-Reply-To: <89f6eebfa85b31c635b774e613f19b84b32f3e1f.1702245873.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>
 <89f6eebfa85b31c635b774e613f19b84b32f3e1f.1702245873.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e2360a12-7c1d-4eb6-80a3-8ca48f63f281@microchip.com>

On 10/12/2023 at 23:12, Uwe Kleine-K?nig wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> 
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>

> ---
>   drivers/char/hw_random/atmel-rng.c | 6 ++----
>   1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
> index a37367ebcbac..e9157255f851 100644
> --- a/drivers/char/hw_random/atmel-rng.c
> +++ b/drivers/char/hw_random/atmel-rng.c
> @@ -161,15 +161,13 @@ static int atmel_trng_probe(struct platform_device *pdev)
>          return ret;
>   }
> 
> -static int atmel_trng_remove(struct platform_device *pdev)
> +static void atmel_trng_remove(struct platform_device *pdev)
>   {
>          struct atmel_trng *trng = platform_get_drvdata(pdev);
> 
>          atmel_trng_cleanup(trng);
>          pm_runtime_disable(&pdev->dev);
>          pm_runtime_set_suspended(&pdev->dev);
> -
> -       return 0;
>   }
> 
>   static int __maybe_unused atmel_trng_runtime_suspend(struct device *dev)
> @@ -218,7 +216,7 @@ MODULE_DEVICE_TABLE(of, atmel_trng_dt_ids);
> 
>   static struct platform_driver atmel_trng_driver = {
>          .probe          = atmel_trng_probe,
> -       .remove         = atmel_trng_remove,
> +       .remove_new     = atmel_trng_remove,
>          .driver         = {
>                  .name   = "atmel-trng",
>                  .pm     = pm_ptr(&atmel_trng_pm_ops),
> --
> 2.42.0
> 



From mripard at redhat.com  Mon Dec 11 00:57:01 2023
From: mripard at redhat.com (Maxime Ripard)
Date: Mon, 11 Dec 2023 09:57:01 +0100
Subject: [PATCH v13 0/5] PCI: add 4x lane support for pci-j721e
 controllers
In-Reply-To: <20231128054402.2155183-1-s-vadapalli@ti.com>
References: <20231128054402.2155183-1-s-vadapalli@ti.com>
Message-ID: <isttx4vp7warwowlz46oo7y2zex7xuizfvovfse3yb4ww72e6u@nuev2jbkhnhw>

Hi Bjorn, Krzysztof, Lorenzo, Rob,

On Tue, Nov 28, 2023 at 11:13:57AM +0530, Siddharth Vadapalli wrote:
> This series adds support to the pci-j721e PCIe controller for up to 4x Lane
> configuration supported by TI's J784S4 SoC. Bindings are also added for
> the num-lanes property which shall be used by the driver. The compatible
> for J784S4 SoC is added.
> 
> This series is based on linux-next tagged next-20231128.

These patches have been floating around for a long time (v12 was almost
identical and was submitted back in April, without any review back then
already [1]), and it looks like reviewers are happy with it.

Could you merge them to get them in 6.8?

Thanks!
Maxime

1: https://lore.kernel.org/lkml/20230401112633.2406604-1-a-verma1 at ti.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/2672865f/attachment.sig>

From tabba at google.com  Mon Dec 11 00:59:09 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 11 Dec 2023 08:59:09 +0000
Subject: [PATCH 05/13] arm64/sysreg: Add definition for ID_AA64PFR2_EL1
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-5-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org> <20231209-b4-arm64-sysreg-additions-v1-5-45284e538474@kernel.org>
Message-ID: <CA+EHjTyLSf6KEs==Bb2htdyydw4Kz0GDhJkgVkLZ_4f62-6+Hg@mail.gmail.com>

Hi Mark,

Thanks for putting this patch series together.

On Sat, Dec 9, 2023 at 1:03?AM Mark Brown <broonie at kernel.org> wrote:
>
> DDI0601 2023-09 defines a new system register ID_AA64PFR2_EL1 which
> enumerates FPMR and some new MTE features. Add a definition of this
> register.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>

Reviewed-by: Fuad Tabba <tabba at google.com>

Cheers,
/fuad

> ---
>  arch/arm64/tools/sysreg | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index c2dbbaa22620..c48a3b8d00ad 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -1002,6 +1002,27 @@ UnsignedEnum     3:0     BT
>  EndEnum
>  EndSysreg
>
> +Sysreg ID_AA64PFR2_EL1 3       0       0       4       2
> +Res0   63:36
> +UnsignedEnum   35:32   FPMR
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
> +Res0   31:12
> +UnsignedEnum   11:8    MTEFAR
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
> +UnsignedEnum   7:4     MTESTOREONLY
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
> +UnsignedEnum   3:0     MTEPERM
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
> +EndSysreg
> +
>  Sysreg ID_AA64ZFR0_EL1 3       0       0       4       4
>  Res0   63:60
>  UnsignedEnum   59:56   F64MM
>
> --
> 2.39.2
>


From s-vadapalli at ti.com  Mon Dec 11 01:00:21 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 11 Dec 2023 14:30:21 +0530
Subject: [PATCH 0/4] Add APIs to request TX/RX DMA channels by ID
In-Reply-To: <a4ca48fb-2e87-494a-bc71-8970d7f8c6a0@ti.com>
References: <20231114083906.3143548-1-s-vadapalli@ti.com>
 <9d465de4-3930-4856-9d8e-7deb567a628f@gmail.com>
 <c693efec-ab67-44bb-8871-a40dc408f278@ti.com>
 <ed1d0221-d0ee-4a7d-8955-d5973027d113@gmail.com>
 <a4ca48fb-2e87-494a-bc71-8970d7f8c6a0@ti.com>
Message-ID: <08e04ee2-b6e7-4da6-87f4-6d111dc25286@ti.com>

If there are no concerns, may I post the v2 of this series, rebasing it on the
latest linux-next tree with minor code cleanup and reordering of the patches?

On 04/12/23 13:51, Siddharth Vadapalli wrote:
> Hello P?ter,
> 
> On 22/11/23 20:52, P?ter Ujfalusi wrote:
>> Hi Siddharth,
>>
>> On 17/11/2023 07:55, Siddharth Vadapalli wrote:
>>>> I would really like to follow a standard binding since what will happen
>>>> if the firmware will start to provision channels/flows for DMAengine
>>>> users? It is not that simple to hack that around.
>>>
>>> Please consider the following use-case for which the APIs are being added by
>>> this series. I apologize for not explaining the idea behind the APIs in more
>>> detail earlier.
>>>
>>> Firmware running on a remote core is in control of a peripheral (CPSW Ethernet
>>> Switch for example) and shares the peripheral across software running on
>>> different cores. The control path between the Firmware and the Clients on
>>> various cores is via RPMsg, while the data path used by the Clients is the DMA
>>> Channels. In the example where Clients send data to the shared peripheral over
>>> DMA, the Clients send RPMsg based requests to the Firmware to obtain the
>>> allocated thead IDs. Firmware allocates the thread IDs by making a request to
>>> TISCI Resource Manager followed by sharing the thread IDs to the Clients.
>>>
>>> In such use cases, the Linux Client is probed by RPMsg endpoint discovery over
>>> the RPMsg bus. Therefore, there is no device-tree corresponding to the Client
>>> device. The Client knows the DMA Channel IDs as well as the RX Flow details from
>>> the Firmware. Knowing these details, the Client can request the configuration of
>>> the TX and RX Channels/Flows by using the DMA APIs which this series adds.
>>
>> I see, so the CPSW will be probed in a similar way as USB peripherals
>> for example? The CPSW does not have a DT entry at all? Is this correct?
> 
> I apologize for the delayed response. Yes, the CPSW instance which shall be in
> control of Firmware running on the remote core will not have a DT entry. The
> Linux Client driver shall be probed when the Firmware announces its endpoint
> over the RPMsg bus, which the Client driver shall register with the RPMsg framework.
> 
>>
>>> Please let me know in case of any suggestions for an implementation which shall
>>> address the above use-case.
>>
>> How does the driver knows how to request a DMA resource from the remote
>> core? How that scales with different SoCs and even with changes in the
>> firmware?
> 
> After getting probed, the Client driver communicates with Firmware via RPMsg,
> requesting details of the allocated resources including the TX Channels and RX
> Flows. Knowing these parameters, the Client driver can use the newly added DMA
> APIs to request TX Channel and RX Flows by IDs. The only dependency here is that
> the Client driver needs to know which DMA instance to request these resources
> from. That information is hard coded in the driver's data in the form of the
> compatible used for the DMA instance, thereby allowing the Client driver to get
> a reference to the DMA controller node using the of_find_compatible_node() API.
> 
> Since all the resource allocation information comes from Firmware, the
> device-specific details will be hard coded in the Firmware while the Client
> driver can be used across all K3 SoCs which have the same DMA APIs.
> 
>>
>> You are right, this is in a grey area. The DMA channel as it is
>> controlled by the remote processor, it lends a thread to clients on
>> other cores (like Linux) via RPMsg.
>> Well, it is similar to how non DT is working in a way.
>>
>> This CPSW type is not yet supported mainline, right?
> 
> Yes, it is not yet supported in mainline. This series is a dependency for
> upstreaming the Client driver.
> 

-- 
Regards,
Siddharth.


From biju.das.jz at bp.renesas.com  Mon Dec 11 01:00:57 2023
From: biju.das.jz at bp.renesas.com (Biju Das)
Date: Mon, 11 Dec 2023 09:00:57 +0000
Subject: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
In-Reply-To: <CAMuHMdUswKrzqgumyoJ3RYWEAUR9WOBzc12dVcCB1s79E-AMRw@mail.gmail.com>
References: <20231201110840.37408-1-biju.das.jz@bp.renesas.com>
 <20231201110840.37408-7-biju.das.jz@bp.renesas.com>
 <CAMuHMdWh3fTzQP5+mGF3u8LACg-5tQDZcyExvgREpxKd6iee4Q@mail.gmail.com>
 <TYCPR01MB112696C301D750A915F2661688681A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <CAMuHMdXHpE079eLAJjcdsbz6=Y6hux267AhqJow6HESCaf7EXQ@mail.gmail.com>
 <TYCPR01MB112693C2B72B6AA28766FF8EA8688A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <CAMuHMdU2pdAYbXdyfpysPR0k7fjh31KrD9Xk05EHWeayzVDz5g@mail.gmail.com>
 <TYCPR01MB1126926DCFDB193E669C9CF8C868FA@TYCPR01MB11269.jpnprd01.prod.outlook.com>
 <CAMuHMdUswKrzqgumyoJ3RYWEAUR9WOBzc12dVcCB1s79E-AMRw@mail.gmail.com>
Message-ID: <TYCPR01MB11269FF61142A63ED67F32647868FA@TYCPR01MB11269.jpnprd01.prod.outlook.com>

Hi Geert,

> -----Original Message-----
> From: Geert Uytterhoeven <geert at linux-m68k.org>
> Sent: Monday, December 11, 2023 8:53 AM
> Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig
> 
> Hi Biju,
> 
> On Mon, Dec 11, 2023 at 9:32?AM Biju Das <biju.das.jz at bp.renesas.com>
> wrote:
> > > -----Original Message-----
> > > From: Geert Uytterhoeven <geert at linux-m68k.org>
> > > Sent: Monday, December 11, 2023 8:20 AM
> > > Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062
> > > defconfig
> > >
> > > On Sun, Dec 10, 2023 at 10:50?AM Biju Das
> > > <biju.das.jz at bp.renesas.com>
> > > wrote:
> > > > > -----Original Message-----
> > > > > From: Geert Uytterhoeven <geert at linux-m68k.org>
> > > > > Sent: Friday, December 1, 2023 3:42 PM
> > > > > Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062
> > > > > defconfig
> > > > >
> > > > > On Fri, Dec 1, 2023 at 4:02?PM Biju Das
> > > > > <biju.das.jz at bp.renesas.com>
> > > > > wrote:
> > > > > > > From: Geert Uytterhoeven <geert at linux-m68k.org> On Fri, Dec
> > > > > > > 1,
> > > > > > > 2023 at 12:09?PM Biju Das <biju.das.jz at bp.renesas.com>
> > > > > > > wrote:
> > > > > > > > Enable the config for the Renesas DA9062 PMIC and RTC, as
> > > > > > > > it is populated on RZ/G2UL SMARC EVK.
> > > > > > > >
> > > > > > > > Signed-off-by: Biju Das <biju.das.jz at bp.renesas.com>
> > > > > > >
> > > > > > > Thanks for your patch!
> > > > > > >
> > > > > > > LGTM, but I would have expected (at least)
> > > > > > >
> > > > > > >     CONFIG_INPUT_DA9063_ONKEY=m
> > > > > > >
> > > > > > > too, cfr. my comments on patch 5/6.
> > > > > >
> > > > > > I have tested this, but I get "da9063-onkey da9062-onkey:
> > > > > > error -
> > > ENXIO:
> > > > > IRQ ONKEY not found"
> > > > > > So, I won't be able to test onkey events. So plaaning to
> > > > > > disable this
> > > > > node.
> > > > >
> > > > > Indeed, currently drivers/input/misc/da9063_onkey.c requires an
> > > > > interrupt to function.  I wonder if it can be made to work using
> > > > > a timer and pure polling...
> > > >
> > > > Yes, that is possible by either adding a debugfs to enable polling
> > > > for
> > > testing.
> > > >
> > > > Or
> > > >
> > > > a device tree property for adding poll delay, so that one can have
> > > polling support to test onkey driver.
> > >
> > > I would go for the latter, cfr. poll-interval in
> > > Documentation/devicetree/bindings/input/gpio-keys.yaml.
> > >
> > > > Basically, on a production system we should avoid polling as it
> > > unnecessarily wakeup the system.
> > >
> > > Wouldn't polling (by Linux) only happen when the system is already
> awake?
> >
> > IIUC, That is an overhead. If there is no load, system goes to suspend
> > mode and the timer for the polling (SCAN keys) will wakeup the system
> > and same process repeats. If we have a PMIC IRQ, this won't happen.
> 
> Ah, you mean idle. Yes, that does incur a (small) overhead (I guess there
> are other timers running, too).

Yes.

> I don't think any timer runs when the system is suspended.

I guess, If we are controlling PM through CPU idle states, this will have an effect.
We schedule timers for poll intervals from onkey driver, when it expires it will wakeup the system
and again based on idle state, it enters into some retention state and goes on.


Cheers,
BIju



From chentao at kylinos.cn  Mon Dec 11 01:03:47 2023
From: chentao at kylinos.cn (Kunwu Chan)
Date: Mon, 11 Dec 2023 17:03:47 +0800
Subject: [PATCH] drivers/perf: Fix some null pointer dereference issues in thunderx2_pmu.c
Message-ID: <20231211090347.265240-1-chentao@kylinos.cn>

devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.

Fixes: 69c32972d593 ("drivers/perf: Add Cavium ThunderX2 SoC UNCORE PMU driver")
Cc: Kunwu Chan <kunwu.chan at hotmail.com>
Signed-off-by: Kunwu Chan <chentao at kylinos.cn>
---
 drivers/perf/thunderx2_pmu.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
index 1edb9c03704f..07edb174a0d7 100644
--- a/drivers/perf/thunderx2_pmu.c
+++ b/drivers/perf/thunderx2_pmu.c
@@ -742,6 +742,8 @@ static int tx2_uncore_pmu_register(
 
 	tx2_pmu->pmu.name = devm_kasprintf(dev, GFP_KERNEL,
 			"%s", name);
+	if (!tx2_pmu->pmu.name)
+		return -ENOMEM;
 
 	return perf_pmu_register(&tx2_pmu->pmu, tx2_pmu->pmu.name, -1);
 }
@@ -881,6 +883,11 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
 		return NULL;
 	}
 
+	if (!tx2_pmu->name) {
+		dev_err(dev, "PMU type %d: Fail to allocate memory\n", type);
+		devm_kfree(dev, tx2_pmu);
+		return NULL;
+	}
 	return tx2_pmu;
 }
 
-- 
2.39.2



From tabba at google.com  Mon Dec 11 01:07:25 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 11 Dec 2023 09:07:25 +0000
Subject: [PATCH 06/13] arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion for
 DDI0601 2023-09
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-6-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org> <20231209-b4-arm64-sysreg-additions-v1-6-45284e538474@kernel.org>
Message-ID: <CA+EHjTzdKS+ardXUofO+U1vnsOC3QjiJUBuKCHWw6z6zKdVGSA@mail.gmail.com>

Hi Mark,

On Sat, Dec 9, 2023 at 1:03?AM Mark Brown <broonie at kernel.org> wrote:
>
> DDI0601 2023-09 defines some new fields in previously RES0 space in
> ID_AA64ISAR2_EL1, together with one new enum value. Update the system
> register definition to reflect this.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>

> ---
>  arch/arm64/tools/sysreg | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index c48a3b8d00ad..3f382f8d0f4a 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -1365,7 +1365,14 @@ EndEnum
>  EndSysreg
>
>  Sysreg ID_AA64ISAR2_EL1        3       0       0       6       2
> -Res0   63:56
> +UnsignedEnum   63:60   ATS1A
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
> +UnsignedEnum   59:56   LUT
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
>  UnsignedEnum   55:52   CSSC
>         0b0000  NI
>         0b0001  IMP
> @@ -1374,7 +1381,19 @@ UnsignedEnum     51:48   RPRFM
>         0b0000  NI
>         0b0001  IMP
>  EndEnum
> -Res0   47:32
> +Res0   47:44
> +UnsignedEnum   43:40   PRFMSLC
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
> +UnsignedEnum   39:36   SYSINSTR_128
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
> +UnsignedEnum   35:32   SYSREG_128
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
>  UnsignedEnum   31:28   CLRBHB
>         0b0000  NI
>         0b0001  IMP
> @@ -1398,6 +1417,7 @@ UnsignedEnum      15:12   APA3
>         0b0011  PAuth2
>         0b0100  FPAC
>         0b0101  FPACCOMBINE
> +       0b0110  PAUTH_LR

Nit: PAuth and PAuth2 only have the PA as uppercase in this file,
which matches the spec. Should PAuth_LR be the same?

Otherwise,
Reviewed-by: Fuad Tabba <tabba at google.com>

Cheers,
/fuad


>  EndEnum
>  UnsignedEnum   11:8    GPA3
>         0b0000  NI
>
> --
> 2.39.2
>


From neil.armstrong at linaro.org  Mon Dec 11 01:08:44 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 11 Dec 2023 10:08:44 +0100
Subject: [PATCH] arm64: dts: amlogic: drop redundant status=okay
In-Reply-To: <20231209124401.93814-1-krzysztof.kozlowski@linaro.org>
References: <20231209124401.93814-1-krzysztof.kozlowski@linaro.org>
Message-ID: <c336d071-34a9-4635-bcde-3861c7f11bd6@linaro.org>

On 09/12/2023 13:44, Krzysztof Kozlowski wrote:
> New device nodes are enabled by default, so no need for status=okay.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> ---
> 
> Tested by comparing decompiled DTBs.
> ---
>   arch/arm64/boot/dts/amlogic/meson-axg-s400.dts         | 5 -----
>   arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts      | 1 -
>   arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts     | 1 -
>   arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts      | 1 -
>   arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts   | 1 -
>   arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi    | 1 -
>   arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts     | 1 -
>   arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts        | 1 -
>   arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi   | 1 -
>   arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 1 -
>   arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts    | 1 -
>   arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts     | 1 -
>   arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts       | 1 -
>   13 files changed, 17 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index df16eead2c80..c8905663bc75 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -66,7 +66,6 @@ linein: audio-codec-0 {
>   		VDDA-supply = <&vcc_3v3>;
>   		VDDP-supply = <&vcc_3v3>;
>   		VDDD-supply = <&vcc_3v3>;
> -		status = "okay";
>   		sound-name-prefix = "Linein";
>   	};
>   
> @@ -75,14 +74,12 @@ lineout: audio-codec-1 {
>   		compatible = "everest,es7154";
>   		VDD-supply = <&vcc_3v3>;
>   		PVDD-supply = <&vcc_5v>;
> -		status = "okay";
>   		sound-name-prefix = "Lineout";
>   	};
>   
>   	spdif_dit: audio-codec-2 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> @@ -91,14 +88,12 @@ dmics: audio-codec-3 {
>   		compatible = "dmic-codec";
>   		num-channels = <7>;
>   		wakeup-delay-ms = <50>;
> -		status = "okay";
>   		sound-name-prefix = "MIC";
>   	};
>   
>   	spdif_dir: audio-codec-4 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dir";
> -		status = "okay";
>   		sound-name-prefix = "DIR";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> index 0ad0c2b7dfef..4c4550dd4711 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
> @@ -45,7 +45,6 @@ dmics: audio-codec-1 {
>   		compatible = "dmic-codec";
>   		num-channels = <2>;
>   		wakeup-delay-ms = <50>;
> -		status = "okay";
>   		sound-name-prefix = "MIC";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
> index 4969a76460fa..9b55982b6a6b 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
> @@ -22,7 +22,6 @@ aliases {
>   	spdif_dit: audio-codec-1 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
> index 8fc2e143cb54..0da386cabe1a 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
> @@ -22,7 +22,6 @@ aliases {
>   	spdif_dit: audio-codec-1 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
> index ce548b373296..6396f190d703 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
> @@ -17,7 +17,6 @@ / {
>   	spdif_dit: audio-codec-1 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> index 18f7b730289e..e59c3c92b1e7 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> @@ -26,7 +26,6 @@ dio2133: analog-amplifier {
>   	spdif_dit: audio-codec-0 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
> index e238f1f10124..f28452b9f00f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
> @@ -18,7 +18,6 @@ / {
>   	spdif_dit: audio-codec-0 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
> index 292c718ee19c..591455c50e88 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
> @@ -18,7 +18,6 @@ / {
>   	spdif_dit: audio-codec-0 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> index e8303089bff6..74df32534231 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
> @@ -21,7 +21,6 @@ chosen {
>   	spdif_dit: audio-codec-0 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
> index e1b74b174915..376760d86766 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
> @@ -17,7 +17,6 @@ / {
>   	spdif_dit: audio-codec-0 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> index 7d525bdb0e06..ad2dd4ad0a31 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -28,7 +28,6 @@ chosen {
>   	spdif_dit: audio-codec-0 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts
> index 50d49aec41bd..d05dde8da5c5 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts
> @@ -37,7 +37,6 @@ memory at 0 {
>   	spdif_dit: audio-codec-0 {
>   		#sound-dai-cells = <0>;
>   		compatible = "linux,spdif-dit";
> -		status = "okay";
>   		sound-name-prefix = "DIT";
>   	};
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
> index 095579c55f18..109932068dbe 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
> @@ -32,7 +32,6 @@ dmics: audio-codec-1 {
>   		compatible = "dmic-codec";
>   		num-channels = <2>;
>   		wakeup-delay-ms = <50>;
> -		status = "okay";
>   		sound-name-prefix = "MIC";
>   	};
>   

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>


From neil.armstrong at linaro.org  Mon Dec 11 01:10:23 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 11 Dec 2023 10:10:23 +0100
Subject: [PATCH 2/2] arm64: dts: amlogic: minor whitespace cleanup around
 '='
In-Reply-To: <4150bf8e-a48d-4d16-902f-a95f6489c6f5@linaro.org>
References: <20231124094739.58163-1-krzysztof.kozlowski@linaro.org>
 <20231124094739.58163-2-krzysztof.kozlowski@linaro.org>
 <4150bf8e-a48d-4d16-902f-a95f6489c6f5@linaro.org>
Message-ID: <449d675f-e98c-4924-ab81-14a139081a97@linaro.org>

Hi,

On 24/11/2023 10:49, Krzysztof Kozlowski wrote:
> On 24/11/2023 10:47, Krzysztof Kozlowski wrote:
>> The DTS code coding style expects exactly one space before and after '='
>> sign.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>> ---
> 
> Please ignore, that's duplicated of my previous send.

I don't see a previous send, so I'm confused.
I can apply this patch if you're ok.

Thanks,
Neil

> 
> Best regards,
> Krzysztof
> 



From manikanta.guntupalli at amd.com  Mon Dec 11 01:11:56 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Mon, 11 Dec 2023 14:41:56 +0530
Subject: [PATCH V4 0/3] Add rs485 support to uartps driver
Message-ID: <20231211091159.58564-1-manikanta.guntupalli@amd.com>

Add optional gpio property to uartps node to support rs485.
Add rs485 support to uartps driver.
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.
Add support for RTS, delay_rts_before_send and delay_rts_after_send in RS485 mode.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.
Move cdns_uart_tx_empty function to avoid prototype statement.
Remove assignment of struct serial_rs485 to port->rs485 as
serial core performs that.
Switch to native RTS in non GPIO case.
Handle rs485 during stop tx.
Remove explicit calls to configure gpio direction and value,
as devm_gpiod_get_optional performs that by using GPIOD_OUT_LOW argument.
Update implementation to support configuration of GPIO/RTS value
based on user configuration of SER_RS485_RTS_ON_SEND and
SER_RS485_RTS_AFTER_SEND. Move implementation to start_tx from handle_tx.

Changes for V4:
Update rts-gpios description.
Create separate patch for cdns_uart_tx_empty relocation.
Call cdns_rs485_rx_setup() before uart_add_one_port() in probe.
Update gpio descriptor name to gpiod_rts.
Instead of cdns_rs485_config_gpio_rts_high() and
cdns_rs485_config_gpio_rts_low() functions for RTS/GPIO value
configuration implement cdns_rts_gpio_enable().
Disable auto rts and call cdns_uart_stop_tx() from cdns_rs485_config.
Use timer instead of mdelay for delay_rts_before_send and delay_rts_after_send.
Update cdns_uart_set_mctrl to support GPIO/RTS.

Manikanta Guntupalli (3):
  dt-bindings: Add optional gpio property to uartps node to support
    rs485
  tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485
  tty: serial: uartps: Add rs485 support to uartps driver

 .../devicetree/bindings/serial/cdns,uart.yaml |   5 +
 drivers/tty/serial/xilinx_uartps.c            | 244 ++++++++++++++++--
 2 files changed, 225 insertions(+), 24 deletions(-)

-- 
2.25.1



From manikanta.guntupalli at amd.com  Mon Dec 11 01:11:57 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Mon, 11 Dec 2023 14:41:57 +0530
Subject: [PATCH V4 1/3] dt-bindings: Add optional gpio property to uartps node to support rs485
In-Reply-To: <20231211091159.58564-1-manikanta.guntupalli@amd.com>
References: <20231211091159.58564-1-manikanta.guntupalli@amd.com>
Message-ID: <20231211091159.58564-2-manikanta.guntupalli@amd.com>

Add optional gpio property to uartps node and reference to rs485.yaml

On Xilinx/AMD Kria SOM KD240 board rs485 connects via TI ISOW1432
Transceiver device, where one GPIO is used for driving DE/RE signals.
With rs485 half duplex configuration, DE and RE are shorted to each other,
and at a time, any node acts as either a driver or a receiver.

Here,
DE - Driver enable. If pin is floating, driver is disabled.
RE - Receiver enable. If pin is floating, receiver buffer is disabled.

For more deatils, please find below link which contains Transceiver
device(ISOW1432) datasheet
https://www.ti.com/lit/ds/symlink/isow1432.pdf?ts=1682607122706&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FISOW1432%252Fpart-details%252FISOW1432DFMR%253FkeyMatch%253DISOW1432DFMR%2526tisearch%253Dsearch-everything%2526usecase%253DOPN

rts-gpios is optional property, because it is not required
for uart console node.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.

Changes for V4:
Update rts-gpios description.
---
 Documentation/devicetree/bindings/serial/cdns,uart.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
index e35ad1109efc..d5dd4e92d1fb 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
@@ -46,6 +46,10 @@ properties:
   power-domains:
     maxItems: 1
 
+  rts-gpios:
+    description: Optional GPIO to control transmit/receive.
+    maxItems: 1
+
 required:
   - compatible
   - reg
@@ -55,6 +59,7 @@ required:
 
 allOf:
   - $ref: serial.yaml#
+  - $ref: rs485.yaml#
   - if:
       properties:
         compatible:
-- 
2.25.1



From manikanta.guntupalli at amd.com  Mon Dec 11 01:11:58 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Mon, 11 Dec 2023 14:41:58 +0530
Subject: [PATCH V4 2/3] tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485
In-Reply-To: <20231211091159.58564-1-manikanta.guntupalli@amd.com>
References: <20231211091159.58564-1-manikanta.guntupalli@amd.com>
Message-ID: <20231211091159.58564-3-manikanta.guntupalli@amd.com>

Relocate cdns_uart_tx_empty function to avoid prototype statement in
rs485 changes.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes since V4:
This patch introduced in V4.
---
 drivers/tty/serial/xilinx_uartps.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 66a45a634158..f7fc2de8778d 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -305,6 +305,21 @@ static void cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus)
 	tty_flip_buffer_push(&port->state->port);
 }
 
+/**
+ * cdns_uart_tx_empty -  Check whether TX is empty
+ * @port: Handle to the uart port structure
+ *
+ * Return: TIOCSER_TEMT on success, 0 otherwise
+ */
+static unsigned int cdns_uart_tx_empty(struct uart_port *port)
+{
+	unsigned int status;
+
+	status = readl(port->membase + CDNS_UART_SR);
+	status &= (CDNS_UART_SR_TXEMPTY | CDNS_UART_SR_TACTIVE);
+	return (status == CDNS_UART_SR_TXEMPTY) ? TIOCSER_TEMT : 0;
+}
+
 /**
  * cdns_uart_handle_tx - Handle the bytes to be Txed.
  * @dev_id: Id of the UART port
@@ -626,21 +641,6 @@ static void cdns_uart_stop_rx(struct uart_port *port)
 	writel(regval, port->membase + CDNS_UART_CR);
 }
 
-/**
- * cdns_uart_tx_empty -  Check whether TX is empty
- * @port: Handle to the uart port structure
- *
- * Return: TIOCSER_TEMT on success, 0 otherwise
- */
-static unsigned int cdns_uart_tx_empty(struct uart_port *port)
-{
-	unsigned int status;
-
-	status = readl(port->membase + CDNS_UART_SR) &
-		       (CDNS_UART_SR_TXEMPTY | CDNS_UART_SR_TACTIVE);
-	return (status == CDNS_UART_SR_TXEMPTY) ? TIOCSER_TEMT : 0;
-}
-
 /**
  * cdns_uart_break_ctl - Based on the input ctl we have to start or stop
  *			transmitting char breaks
-- 
2.25.1



From manikanta.guntupalli at amd.com  Mon Dec 11 01:11:59 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Mon, 11 Dec 2023 14:41:59 +0530
Subject: [PATCH V4 3/3] tty: serial: uartps: Add rs485 support to uartps driver
In-Reply-To: <20231211091159.58564-1-manikanta.guntupalli@amd.com>
References: <20231211091159.58564-1-manikanta.guntupalli@amd.com>
Message-ID: <20231211091159.58564-4-manikanta.guntupalli@amd.com>

Add rs485 support to uartps driver. Use either rts-gpios or RTS
to control RS485 phy as driver or a receiver.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.
Add support for RTS, delay_rts_before_send and delay_rts_after_send in RS485 mode.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.
Move cdns_uart_tx_empty function to avoid prototype statement.
Remove assignment of struct serial_rs485 to port->rs485 as
serial core performs that.
Switch to native RTS in non GPIO case.
Handle rs485 during stop tx.
Remove explicit calls to configure gpio direction and value,
as devm_gpiod_get_optional performs that by using GPIOD_OUT_LOW argument.
Update implementation to support configuration of GPIO/RTS value
based on user configuration of SER_RS485_RTS_ON_SEND and
SER_RS485_RTS_AFTER_SEND. Move implementation to start_tx from handle_tx.

Changes for V4:
Create separate patch for cdns_uart_tx_empty relocation.
Call cdns_rs485_rx_setup() before uart_add_one_port() in probe.
Update gpio descriptor name to gpiod_rts.
Instead of cdns_rs485_config_gpio_rts_high() and
cdns_rs485_config_gpio_rts_low() functions for RTS/GPIO value
configuration implement cdns_rts_gpio_enable().
Disable auto rts and call cdns_uart_stop_tx() from cdns_rs485_config.
Use timer instead of mdelay for delay_rts_before_send and delay_rts_after_send.
Update cdns_uart_set_mctrl to support GPIO/RTS.
---
 drivers/tty/serial/xilinx_uartps.c | 214 +++++++++++++++++++++++++++--
 1 file changed, 205 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index f7fc2de8778d..e7f2c43fabd3 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -22,7 +22,9 @@
 #include <linux/of.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
-#include <linux/iopoll.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/delay.h>
 
 #define CDNS_UART_TTY_NAME	"ttyPS"
 #define CDNS_UART_NAME		"xuartps"
@@ -193,6 +195,10 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255");
  * @clk_rate_change_nb:	Notifier block for clock changes
  * @quirks:		Flags for RXBS support.
  * @cts_override:	Modem control state override
+ * @gpiod_rts:		Pointer to the gpio descriptor
+ * @rs485_tx_started:	RS485 tx state
+ * @timer:		Timer for tx and rx
+ * @stop_tx_timer:	Timer for stop tx
  */
 struct cdns_uart {
 	struct uart_port	*port;
@@ -203,10 +209,22 @@ struct cdns_uart {
 	struct notifier_block	clk_rate_change_nb;
 	u32			quirks;
 	bool cts_override;
+	struct gpio_desc	*gpiod_rts;
+	bool			rs485_tx_started;
+	struct timer_list	timer;
+	struct timer_list	stop_tx_timer;
 };
 struct cdns_platform_data {
 	u32 quirks;
 };
+
+struct serial_rs485 cdns_rs485_supported = {
+	.flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND |
+		 SER_RS485_RTS_AFTER_SEND,
+	.delay_rts_before_send = 1,
+	.delay_rts_after_send = 1,
+};
+
 #define to_cdns_uart(_nb) container_of(_nb, struct cdns_uart, \
 		clk_rate_change_nb)
 
@@ -305,6 +323,55 @@ static void cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus)
 	tty_flip_buffer_push(&port->state->port);
 }
 
+/**
+ * cdns_rts_gpio_enable - Configure RTS/GPIO to high/low
+ * @cdns_uart: Handle to the cdns_uart
+ * @enable: Value to be set to RTS/GPIO
+ */
+static void cdns_rts_gpio_enable(struct cdns_uart *cdns_uart, bool enable)
+{
+	u32 val;
+
+	if (cdns_uart->gpiod_rts) {
+		gpiod_set_value(cdns_uart->gpiod_rts, enable);
+	} else {
+		val = readl(cdns_uart->port->membase + CDNS_UART_MODEMCR);
+		if (enable)
+			val &= ~CDNS_UART_MODEMCR_RTS;
+		else
+			val |= CDNS_UART_MODEMCR_RTS;
+		writel(val, cdns_uart->port->membase + CDNS_UART_MODEMCR);
+	}
+}
+
+/**
+ * cdns_rs485_tx_setup - Tx setup specific to rs485
+ * @cdns_uart: Handle to the cdns_uart
+ */
+static void cdns_rs485_tx_setup(struct cdns_uart *cdns_uart)
+{
+	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_ON_SEND)
+		cdns_rts_gpio_enable(cdns_uart, 1);
+	else
+		cdns_rts_gpio_enable(cdns_uart, 0);
+
+	cdns_uart->rs485_tx_started = true;
+}
+
+/**
+ * cdns_rs485_rx_setup - Rx setup specific to rs485
+ * @cdns_uart: Handle to the cdns_uart
+ */
+static void cdns_rs485_rx_setup(struct cdns_uart *cdns_uart)
+{
+	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_AFTER_SEND)
+		cdns_rts_gpio_enable(cdns_uart, 1);
+	else
+		cdns_rts_gpio_enable(cdns_uart, 0);
+
+	cdns_uart->rs485_tx_started = false;
+}
+
 /**
  * cdns_uart_tx_empty -  Check whether TX is empty
  * @port: Handle to the uart port structure
@@ -579,6 +646,42 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
 }
 #endif
 
+/**
+ * cdns_rs485_rx_callback - Timer rx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_rx_callback(struct timer_list *t)
+{
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
+
+	/*
+	 * Default Rx should be setup, because Rx signaling path
+	 * need to enable to receive data.
+	 */
+	cdns_rs485_rx_setup(cdns_uart);
+}
+
+/**
+ * cdns_rs485_tx_callback - Timer tx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_tx_callback(struct timer_list *t)
+{
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
+
+	cdns_uart_handle_tx(cdns_uart->port);
+
+	/* Enable the TX Empty interrupt */
+	writel(CDNS_UART_IXR_TXEMPTY, cdns_uart->port->membase + CDNS_UART_IER);
+
+	if (uart_circ_empty(&cdns_uart->port->state->xmit) ||
+	    uart_tx_stopped(cdns_uart->port)) {
+		timer_setup(&cdns_uart->timer, cdns_rs485_rx_callback, 0);
+		mod_timer(&cdns_uart->timer, jiffies +
+			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
+	}
+}
+
 /**
  * cdns_uart_start_tx -  Start transmitting bytes
  * @port: Handle to the uart port structure
@@ -586,6 +689,7 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
 static void cdns_uart_start_tx(struct uart_port *port)
 {
 	unsigned int status;
+	struct cdns_uart *cdns_uart = port->private_data;
 
 	if (uart_tx_stopped(port))
 		return;
@@ -604,10 +708,40 @@ static void cdns_uart_start_tx(struct uart_port *port)
 
 	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_ISR);
 
-	cdns_uart_handle_tx(port);
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		if (!cdns_uart->rs485_tx_started) {
+			timer_setup(&cdns_uart->timer,
+				    cdns_rs485_tx_callback, 0);
+			cdns_rs485_tx_setup(cdns_uart);
+			mod_timer(&cdns_uart->timer, jiffies +
+				  msecs_to_jiffies(port->rs485.delay_rts_before_send));
+		} else {
+			if (!timer_pending(&cdns_uart->timer))
+				mod_timer(&cdns_uart->timer, jiffies);
+		}
+	} else {
+		cdns_uart_handle_tx(port);
 
-	/* Enable the TX Empty interrupt */
-	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
+		/* Enable the TX Empty interrupt */
+		writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
+	}
+}
+
+/**
+ * cdns_rs485_stop_tx_callback - Timer stop tx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_stop_tx_callback(struct timer_list *t)
+{
+	unsigned int regval;
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, stop_tx_timer);
+
+	cdns_rs485_rx_setup(cdns_uart);
+
+	regval = readl(cdns_uart->port->membase + CDNS_UART_CR);
+	regval |= CDNS_UART_CR_TX_DIS;
+	/* Disable the transmitter */
+	writel(regval, cdns_uart->port->membase + CDNS_UART_CR);
 }
 
 /**
@@ -617,11 +751,19 @@ static void cdns_uart_start_tx(struct uart_port *port)
 static void cdns_uart_stop_tx(struct uart_port *port)
 {
 	unsigned int regval;
+	struct cdns_uart *cdns_uart = port->private_data;
 
-	regval = readl(port->membase + CDNS_UART_CR);
-	regval |= CDNS_UART_CR_TX_DIS;
-	/* Disable the transmitter */
-	writel(regval, port->membase + CDNS_UART_CR);
+	if ((cdns_uart->port->rs485.flags & SER_RS485_ENABLED) &&
+	    !timer_pending(&cdns_uart->stop_tx_timer) &&
+	    cdns_uart->rs485_tx_started) {
+		mod_timer(&cdns_uart->stop_tx_timer, jiffies +
+			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
+	} else {
+		regval = readl(port->membase + CDNS_UART_CR);
+		regval |= CDNS_UART_CR_TX_DIS;
+		/* Disable the transmitter */
+		writel(regval, port->membase + CDNS_UART_CR);
+	}
 }
 
 /**
@@ -829,6 +971,12 @@ static int cdns_uart_startup(struct uart_port *port)
 		(CDNS_UART_CR_TXRST | CDNS_UART_CR_RXRST))
 		cpu_relax();
 
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		timer_setup(&cdns_uart->stop_tx_timer,
+			    cdns_rs485_stop_tx_callback, 0);
+		cdns_rs485_rx_setup(cdns_uart);
+	}
+
 	/*
 	 * Clear the RX disable bit and then set the RX enable bit to enable
 	 * the receiver.
@@ -888,6 +1036,7 @@ static void cdns_uart_shutdown(struct uart_port *port)
 {
 	int status;
 	unsigned long flags;
+	struct cdns_uart *cdns_uart = port->private_data;
 
 	uart_port_lock_irqsave(port, &flags);
 
@@ -903,6 +1052,11 @@ static void cdns_uart_shutdown(struct uart_port *port)
 	uart_port_unlock_irqrestore(port, flags);
 
 	free_irq(port->irq, port);
+
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		del_timer_sync(&cdns_uart->timer);
+		del_timer_sync(&cdns_uart->stop_tx_timer);
+	}
 }
 
 /**
@@ -1032,7 +1186,7 @@ static void cdns_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
 	mode_reg &= ~CDNS_UART_MR_CHMODE_MASK;
 
 	if (mctrl & TIOCM_RTS)
-		val |= CDNS_UART_MODEMCR_RTS;
+		cdns_rts_gpio_enable(cdns_uart_data, 1);
 	if (mctrl & TIOCM_DTR)
 		val |= CDNS_UART_MODEMCR_DTR;
 	if (mctrl & TIOCM_LOOP)
@@ -1455,6 +1609,31 @@ MODULE_DEVICE_TABLE(of, cdns_uart_of_match);
 /* Temporary variable for storing number of instances */
 static int instances;
 
+/**
+ * cdns_rs485_config - Called when an application calls TIOCSRS485 ioctl.
+ * @port: Pointer to the uart_port structure
+ * @termios: Pointer to the ktermios structure
+ * @rs485: Pointer to the serial_rs485 structure
+ *
+ * Return: 0
+ */
+static int cdns_rs485_config(struct uart_port *port, struct ktermios *termios,
+			     struct serial_rs485 *rs485)
+{
+	u32 val;
+
+	if (rs485->flags & SER_RS485_ENABLED) {
+		dev_dbg(port->dev, "Setting UART to RS485\n");
+		/* Make sure auto RTS is disabled */
+		val = readl(port->membase + CDNS_UART_MODEMCR);
+		val &= ~CDNS_UART_MODEMCR_FCM;
+		writel(val, port->membase + CDNS_UART_MODEMCR);
+		/* Disable transmitter and make Rx setup*/
+		cdns_uart_stop_tx(port);
+	}
+	return 0;
+}
+
 /**
  * cdns_uart_probe - Platform driver probe
  * @pdev: Pointer to the platform device structure
@@ -1597,9 +1776,23 @@ static int cdns_uart_probe(struct platform_device *pdev)
 	port->private_data = cdns_uart_data;
 	port->read_status_mask = CDNS_UART_IXR_TXEMPTY | CDNS_UART_IXR_RXTRIG |
 			CDNS_UART_IXR_OVERRUN | CDNS_UART_IXR_TOUT;
+	port->rs485_config = cdns_rs485_config;
+	port->rs485_supported = cdns_rs485_supported;
 	cdns_uart_data->port = port;
 	platform_set_drvdata(pdev, port);
 
+	rc = uart_get_rs485_mode(port);
+	if (rc)
+		goto err_out_clk_notifier;
+
+	cdns_uart_data->gpiod_rts = devm_gpiod_get_optional(&pdev->dev, "rts",
+							    GPIOD_OUT_LOW);
+	if (IS_ERR(cdns_uart_data->gpiod_rts)) {
+		rc = PTR_ERR(cdns_uart_data->gpiod_rts);
+		dev_err(port->dev, "xuartps: devm_gpiod_get_optional failed\n");
+		goto err_out_clk_notifier;
+	}
+
 	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_set_autosuspend_delay(&pdev->dev, UART_AUTOSUSPEND_TIMEOUT);
 	pm_runtime_set_active(&pdev->dev);
@@ -1618,6 +1811,8 @@ static int cdns_uart_probe(struct platform_device *pdev)
 		console_port = port;
 	}
 #endif
+	if (cdns_uart_data->port->rs485.flags & SER_RS485_ENABLED)
+		cdns_rs485_rx_setup(cdns_uart_data);
 
 	rc = uart_add_one_port(&cdns_uart_uart_driver, port);
 	if (rc) {
@@ -1646,6 +1841,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
+err_out_clk_notifier:
 #ifdef CONFIG_COMMON_CLK
 	clk_notifier_unregister(cdns_uart_data->uartclk,
 			&cdns_uart_data->clk_rate_change_nb);
-- 
2.25.1



From sherry.sun at nxp.com  Mon Dec 11 01:14:21 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Mon, 11 Dec 2023 09:14:21 +0000
Subject: [PATCH 2/4] dt-bindings: imx6q-pcie: Add host-wake-gpio property
In-Reply-To: <83ca3d88cdaa7bc6e6bd3c4e88518b155a6b0f05.camel@pengutronix.de>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
	 <20231208091355.1417292-3-sherry.sun@nxp.com>
 <83ca3d88cdaa7bc6e6bd3c4e88518b155a6b0f05.camel@pengutronix.de>
Message-ID: <AS8PR04MB8404D7A5FE8A93E5D0FA3D2F928FA@AS8PR04MB8404.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Lucas Stach <l.stach at pengutronix.de>
> Sent: 2023?12?8? 18:00
> To: Sherry Sun <sherry.sun at nxp.com>; Hongxing Zhu
> <hongxing.zhu at nxp.com>; lpieralisi at kernel.org; kw at linux.com;
> robh at kernel.org; bhelgaas at google.com; krzysztof.kozlowski+dt at linaro.org;
> conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de;
> kernel at pengutronix.de; festevam at gmail.com
> Cc: dl-linux-imx <linux-imx at nxp.com>; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH 2/4] dt-bindings: imx6q-pcie: Add host-wake-gpio
> property
> 
> Hi Sherry,
> 
> Am Freitag, dem 08.12.2023 um 17:13 +0800 schrieb Sherry Sun:
> > Add host-wake-gpio property that can be used to wakeup the host
> > processor.
> >
> > Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
> > Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
> > ---
> >  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > index 81bbb8728f0f..944f0f961809 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > @@ -72,6 +72,10 @@ properties:
> >        L=operation state) (optional required).
> >      type: boolean
> >
> > +  host-wake-gpio:
> 
> There is only one wake signal in PCIe and it has a defined direction, so there
> is no point in specifying that it is a host wakeup. Also GPIO handles without a
> traling 's' are deprecated. So this should be
> 
> wake-gpios

Hi Lucas, thanks for the comment, will change it in V2.

> 
> > +    description: Should specify the GPIO for controlling the PCI bus device
> > +      wake signal, used to wakeup the host processor. Default to active-low.
> 
> The description is wrong. For the RC complex case (which is the binding you
> are modifying here) the controller does not control the wake signal, but
> instead uses it as a input. The description should reflect that.
> 
> The default is also quite useless, as your implementation does not allow to
> change it. Please translate the GPIO active flags from the DT to the proper
> IRQ flags and drop this default here. The DT should simply carry the proper
> polarity.
> 

Will improve the description in V2, thanks.

Best Regards
Sherry

From tabba at google.com  Mon Dec 11 01:14:36 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 11 Dec 2023 09:14:36 +0000
Subject: [PATCH 07/13] arm64/sysreg: Add definition for ID_AA64ISAR3_EL1
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-7-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org> <20231209-b4-arm64-sysreg-additions-v1-7-45284e538474@kernel.org>
Message-ID: <CA+EHjTw8wkdCG69=b4s328RdWPdujOpRt1VCW7TTyUys6dDffg@mail.gmail.com>

Hi Mark,


On Sat, Dec 9, 2023 at 1:03?AM Mark Brown <broonie at kernel.org> wrote:
>
> DDI0601 2023-09 adds a new system register ID_AA64ISAR3_EL1 enumerating
> new floating point and TLB invalidation features. Add a defintion for it.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>

Reviewed-by: Fuad Tabba <tabba at google.com>

Cheers,
/fuad

> ---
>  arch/arm64/tools/sysreg | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 3f382f8d0f4a..d1bb6ebcd959 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -1433,6 +1433,23 @@ UnsignedEnum     3:0     WFxT
>  EndEnum
>  EndSysreg
>
> +Sysreg ID_AA64ISAR3_EL1        3       0       0       6       3
> +Res0   63:12
> +UnsignedEnum   11:8    TLBIW
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
> +UnsignedEnum   7:4     FAMINMAX
> +       0b0000  NI
> +       0b0001  IMP
> +EndEnum
> +UnsignedEnum   3:0     CPA
> +       0b0000  NI
> +       0b0001  IMP
> +       0b0010  CPA2
> +EndEnum
> +EndSysreg
> +


>  Sysreg ID_AA64MMFR0_EL1        3       0       0       7       0
>  UnsignedEnum   63:60   ECV
>         0b0000  NI
>
> --
> 2.39.2
>


From neil.armstrong at linaro.org  Mon Dec 11 01:16:16 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 11 Dec 2023 10:16:16 +0100
Subject: (subset) [PATCH v5 00/10] Add displays support for
 bsh-smm-s2/pro boards
In-Reply-To: <20231207141723.108004-1-dario.binacchi@amarulasolutions.com>
References: <20231207141723.108004-1-dario.binacchi@amarulasolutions.com>
Message-ID: <170228617622.2409693.12899768447819855539.b4-ty@linaro.org>

Hi,

On Thu, 07 Dec 2023 15:16:29 +0100, Dario Binacchi wrote:
> The series adds drivers for the displays used by bsh-smm-s2/pro boards.
> This required applying some patches to the samsung-dsim driver and the
> drm_bridge.c module.
> 
> Changes in v5:
> - Replace a 'return ret' with a 'goto fail' in the r63353_panel_activate()
> - Add 'Reviewed-by' tag of Krzysztof Kozlowski
> 
> [...]

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)

[06/10] drm/panel: Add Synaptics R63353 panel driver
        https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2e87bad7cd339882cf26b7101a1c87dab71962c9
[07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
        https://cgit.freedesktop.org/drm/drm-misc/commit/?id=549240c98e50207244bc1ac182622b8daba89a89
[08/10] drm/panel: Add Ilitek ILI9805 panel driver
        https://cgit.freedesktop.org/drm/drm-misc/commit/?id=edbf1d506ebe8c0857c406bd5d5b81d46ffd8437
[09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
        https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b1fcb7ee3707290466b2cc4956325fb91f09f13b

-- 
Neil



From tabba at google.com  Mon Dec 11 01:17:02 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 11 Dec 2023 09:17:02 +0000
Subject: [PATCH 09/13] arm64/sysreg: Update ID_AA64SMFR0_EL1 definition
 for DDI0601 2023-09
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-9-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org> <20231209-b4-arm64-sysreg-additions-v1-9-45284e538474@kernel.org>
Message-ID: <CA+EHjTwQUd66umh-w=fTtHsf-iUAUKk4HbtO-27RdZ6HRP=UEQ@mail.gmail.com>

Hi Mark,

On Sat, Dec 9, 2023 at 1:03?AM Mark Brown <broonie at kernel.org> wrote:
>
> The 2023-09 release of DDI0601 defines a number of new feature enumeration
> fields in ID_AA64SMFR0_EL1. Add these fields.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>

Reviewed-by: Fuad Tabba <tabba at google.com>

Cheers,
/fuad

> ---
>  arch/arm64/tools/sysreg | 30 +++++++++++++++++++++++++++---
>  1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 68236cf1abda..839f7cca53e0 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -1079,7 +1079,11 @@ UnsignedEnum     63      FA64
>         0b0     NI
>         0b1     IMP
>  EndEnum
> -Res0   62:60
> +Res0   62:61
> +UnsignedEnum   60      LUTv2
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
>  UnsignedEnum   59:56   SMEver
>         0b0000  SME
>         0b0001  SME2
> @@ -1107,7 +1111,14 @@ UnsignedEnum     42      F16F16
>         0b0     NI
>         0b1     IMP
>  EndEnum
> -Res0   41:40
> +UnsignedEnum   41      F8F16
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +UnsignedEnum   40      F8F32
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
>  UnsignedEnum   39:36   I8I32
>         0b0000  NI
>         0b1111  IMP
> @@ -1128,7 +1139,20 @@ UnsignedEnum     32      F32F32
>         0b0     NI
>         0b1     IMP
>  EndEnum
> -Res0   31:0
> +Res0   31
> +UnsignedEnum   30      SF8FMA
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +UnsignedEnum   29      SF8DP4
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +UnsignedEnum   28      SF8DP2
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +Res0   27:0
>  EndSysreg
>
>  Sysreg ID_AA64FPFR0_EL1        3       0       0       4       7
>
> --
> 2.39.2
>


From peter.griffin at linaro.org  Mon Dec 11 01:17:53 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 09:17:53 +0000
Subject: [PATCH v6 03/20] dt-bindings: soc: google: exynos-sysreg: add
 dedicated SYSREG compatibles to GS101
In-Reply-To: <c2244932-cb2f-423a-bbe6-9ab2b08b9d63@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-4-peter.griffin@linaro.org> <c2244932-cb2f-423a-bbe6-9ab2b08b9d63@linaro.org>
Message-ID: <CADrjBPpd5mT6SZyPEgxFGy18pr5Gypcwv7aoG4R978d__Pk3LA@mail.gmail.com>

Hi Krzysztof,

On Sun, 10 Dec 2023 at 13:49, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 10/12/2023 00:30, Peter Griffin wrote:
> > GS101 has three different SYSREG controllers, add dedicated
> > compatibles for them to the documentation.
> >
> > Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  .../bindings/soc/samsung/samsung,exynos-sysreg.yaml         | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> > index 2de4301a467d..127f4ffde76a 100644
> > --- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> > +++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
> > @@ -22,6 +22,12 @@ properties:
> >                - tesla,fsd-fsys1-sysreg
> >                - tesla,fsd-peric-sysreg
> >            - const: syscon
> > +      - items:
> > +          - enum:
> > +              - google,gs101-apm-sysreg
> > +              - google,gs101-peric0-sysreg
> > +              - google,gs101-peric1-sysreg
>
> This should be part of the first enum. No need for new list for every
> new SoC. I'll fix it while applying.

Noted, thanks!

Peter


From jiaxun.yang at flygoat.com  Mon Dec 11 01:17:54 2023
From: jiaxun.yang at flygoat.com (Jiaxun Yang)
Date: Mon, 11 Dec 2023 09:17:54 +0000
Subject: [RFT PATCH 1/2] stmmac: dwmac-loongson: drop useless check for compatible
 fallback
In-Reply-To: <93b41b72-a6ac-4d7f-95f0-ba42399729fc@loongson.cn>
References: <20230616103127.285608-1-krzysztof.kozlowski@linaro.org>
 <20230616-activity-shed-be3c13e5ac71@spud>
 <93b41b72-a6ac-4d7f-95f0-ba42399729fc@loongson.cn>
Message-ID: <9bdcd491-5ee5-48b3-844c-d6c0092bfc73@app.fastmail.com>



?2023?12?10???? ??6:48?Yanteng Si???
> ? 2023/6/17 02:52, Conor Dooley ??:
>> On Fri, Jun 16, 2023 at 12:31:26PM +0200, Krzysztof Kozlowski wrote:
>>> Device binds to proper PCI ID (LOONGSON, 0x7a03), already listed in DTS,
>>> so checking for some other compatible does not make sense.  It cannot be
>>> bound to unsupported platform.
>>>
>>> Drop useless, incorrect (space in between) and undocumented compatible.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>> Might be worth noting that dropping it is required to allow the
>> new loongarch dts stuff to be functional with a sane set of compatibles.
>>
>> Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
> Thank you Krzysztof for your work. when I am
> adding more devices support to stmmac, I found that your
> two patches seemed to be forgotten.
> Thomas, Jiaxun. Can the two patches get an Acked-by?
> My stmmac patch thread:
> <https://lore.kernel.org/loongarch/cover.1699533745.git 
> .siyanteng at loongson.cn/T/#md3108d29a5efe71b27f4c5ccf5d0217571bf6586>

Acked-by: Jiaxun Yang <jiaxun.yang at flygoat.com>

Better to resend without RFC :-)

Thanks

> Thanks,
> Yanteng
>
>>
>> Cheers,
>> Conor.

-- 
- Jiaxun


From tabba at google.com  Mon Dec 11 01:18:23 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 11 Dec 2023 09:18:23 +0000
Subject: [PATCH 08/13] arm64/sysreg: Add definition for ID_AA64FPFR0_EL1
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-8-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org> <20231209-b4-arm64-sysreg-additions-v1-8-45284e538474@kernel.org>
Message-ID: <CA+EHjTxhXgYs-Z0-2y7c1bdvr+LpT8-nb67DEP+yCJEL5gaPOg@mail.gmail.com>

Hi Mark,


On Sat, Dec 9, 2023 at 1:03?AM Mark Brown <broonie at kernel.org> wrote:
>
> DDI0601 2023-09 defines a new feature register ID_AA64FPFR0_EL1 which
> enumerates a number of FP8 related features. Add a definition for it.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---

Reviewed-by: Fuad Tabba <tabba at google.com>

Cheers,
/fuad

>  arch/arm64/tools/sysreg | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index d1bb6ebcd959..68236cf1abda 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -1131,6 +1131,35 @@ EndEnum
>  Res0   31:0
>  EndSysreg
>
> +Sysreg ID_AA64FPFR0_EL1        3       0       0       4       7
> +Res0   63:32
> +UnsignedEnum   31      F8CVT
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +UnsignedEnum   30      F8FMA
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +UnsignedEnum   29      F8DP4
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +UnsignedEnum   28      F8DP2
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +Res0   27:2
> +UnsignedEnum   1       F8E4M3
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +UnsignedEnum   0       F8E5M2
> +       0b0     NI
> +       0b1     IMP
> +EndEnum
> +EndSysreg
> +
>  Sysreg ID_AA64DFR0_EL1 3       0       0       5       0
>  Enum   63:60   HPMN0
>         0b0000  UNPREDICTABLE
>
> --
> 2.39.2
>


From tabba at google.com  Mon Dec 11 01:19:53 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 11 Dec 2023 09:19:53 +0000
Subject: [PATCH 10/13] arm64/sysreg: Update SCTLR_EL1 for DDI0601 2023-09
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-10-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org> <20231209-b4-arm64-sysreg-additions-v1-10-45284e538474@kernel.org>
Message-ID: <CA+EHjTzJNvH5gF7U-An+Tq6ySMnUUABuUFTz0qxTe-hqu6xZhw@mail.gmail.com>

Hi Mark,


On Sat, Dec 9, 2023 at 1:03?AM Mark Brown <broonie at kernel.org> wrote:
>
> DDI0601 2023-09 defines some new fields in SCTLR_EL1 controlling new MTE
> and floating point features. Update our sysreg definition to reflect these.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---

Reviewed-by: Fuad Tabba <tabba at google.com>

Cheers,
/fuad

>  arch/arm64/tools/sysreg | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 839f7cca53e0..4137179e7570 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -1791,7 +1791,8 @@ Field     63      TIDCP
>  Field  62      SPINTMASK
>  Field  61      NMI
>  Field  60      EnTP2
> -Res0   59:58
> +Field  59      TCSO
> +Field  58      TCSO0
>  Field  57      EPAN
>  Field  56      EnALS
>  Field  55      EnAS0
> @@ -1820,7 +1821,7 @@ EndEnum
>  Field  37      ITFSB
>  Field  36      BT1
>  Field  35      BT0
> -Res0   34
> +Field  34      EnFPM
>  Field  33      MSCEn
>  Field  32      CMOW
>  Field  31      EnIA
>
> --
> 2.39.2
>


From peter.griffin at linaro.org  Mon Dec 11 01:24:22 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 09:24:22 +0000
Subject: [PATCH v6 04/20] dt-bindings: watchdog: Document Google gs101
 watchdog bindings
In-Reply-To: <e70d516d-db24-4d79-bbd8-bb5b497a4391@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-5-peter.griffin@linaro.org> <e70d516d-db24-4d79-bbd8-bb5b497a4391@linaro.org>
Message-ID: <CADrjBPrhO42-7TY0iNuRcyWj_YUwpNMWROY_6waLoVtmp7uwrg@mail.gmail.com>

Hi Krzysztof,

On Sun, 10 Dec 2023 at 14:23, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 10/12/2023 00:30, Peter Griffin wrote:
> > Add the "google,gs101-wdt" compatible to the dt-schema documentation.
> >
> > gs101 SoC has two CPU clusters and each cluster has its own dedicated
> > watchdog timer (similar to exynos850 and exynosautov9 SoCs).
> >
> > These WDT instances are controlled using different bits in PMU
> > registers.
> >
> > Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  .../devicetree/bindings/watchdog/samsung-wdt.yaml         | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
> > index 8fb6656ba0c2..57468c2c5ece 100644
> > --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
> > +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
> > @@ -17,6 +17,7 @@ description: |+
> >  properties:
> >    compatible:
> >      enum:
> > +      - google,gs101-wdt                      # for Google gs101
>
> I think you did not rebase on linux-next. The hunk differs.

It was re-based off 'next-20231130'. I will re-base off the current
day's linux-next for v7.

Thanks,

Peter.


From tabba at google.com  Mon Dec 11 01:26:01 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 11 Dec 2023 09:26:01 +0000
Subject: [PATCH 11/13] arm64/sysreg: Update HCRX_EL2 definition for
 DDI0601 2023-09
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-11-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org> <20231209-b4-arm64-sysreg-additions-v1-11-45284e538474@kernel.org>
Message-ID: <CA+EHjTyscwpSeRytJu_OX+pS4+BMXorhoOSvTuNsUM2kR=VkCQ@mail.gmail.com>

Hi Mark,

On Sat, Dec 9, 2023 at 1:03?AM Mark Brown <broonie at kernel.org> wrote:
>
> DDI0601 2023-09 defines new fields in HCRX_EL2 controlling access to new
> system registers, update our definition of HCRX_EL2 to reflect this.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---

This is not an issue with this patch per se, but all FGT registers
prefix bits that trap on 0 with an n, e.g., HFGxTR_EL2:
nAMAIR2_EL1...nACCDATA_EL1, but not HCRX_EL2. I think that most
HCRX_EL2 bits trap on 0, except for TALLINT. It shouldn't be done in
this patch, but I'm wondering if it's worth the hassle to rename the
bits, or if there's too much existing code and in-flight patches that
it's more trouble than it's worth.

That said,
Reviewed-by: Fuad Tabba <tabba at google.com>

Cheers,
/fuad

>  arch/arm64/tools/sysreg | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 4137179e7570..1acec8f5c37d 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -2458,7 +2458,9 @@ Fields    ZCR_ELx
>  EndSysreg
>
>  Sysreg HCRX_EL2        3       4       1       2       2
> -Res0   63:23
> +Res0   63:25
> +Field  24      PACMEn
> +Field  23      EnFPM
>  Field  22      GCSEn
>  Field  21      EnIDCP128
>  Field  20      EnSDERR
>
> --
> 2.39.2
>


From tabba at google.com  Mon Dec 11 01:28:15 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 11 Dec 2023 09:28:15 +0000
Subject: [PATCH 12/13] arm64/sysreg: Add definition for FPMR
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-12-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org> <20231209-b4-arm64-sysreg-additions-v1-12-45284e538474@kernel.org>
Message-ID: <CA+EHjTxcY8wT-ztms2+SwJ-zywk08TjuKXLJiyk_9mO9y_y8Pg@mail.gmail.com>

Hi Mark,

On Sat, Dec 9, 2023 at 1:03?AM Mark Brown <broonie at kernel.org> wrote:
>
> DDI0601 2023-09 defines a new sysrem register FPMR (Floating Point Mode
> Register) which configures the new FP8 features. Add a definition of this
> register.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---

Reviewed-by: Fuad Tabba <tabba at google.com>

Cheers,
/fuad

>  arch/arm64/tools/sysreg | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 1acec8f5c37d..1c6d1c904750 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -2139,6 +2139,29 @@ Field    1       ZA
>  Field  0       SM
>  EndSysreg
>
> +Sysreg FPMR    3       3       4       4       2
> +Res0   63:38
> +Field  37:32   LSCALE2
> +Field  31:24   NSCALE
> +Res0   23
> +Field  22:16   LSCALE
> +Field  15      OSC
> +Field  14      OSM
> +Res0   13:9
> +UnsignedEnum   8:6     F8D
> +       0b000   E5M2
> +       0b001   E4M3
> +EndEnum
> +UnsignedEnum   5:3     F8S2
> +       0b000   E5M2
> +       0b001   E4M3
> +EndEnum
> +UnsignedEnum   2:0     F8S1
> +       0b000   E5M2
> +       0b001   E4M3
> +EndEnum
> +EndSysreg
> +
>  SysregFields   HFGxTR_EL2
>  Field  63      nAMAIR2_EL1
>  Field  62      nMAIR2_EL1
>
> --
> 2.39.2
>


From tudor.ambarus at linaro.org  Mon Dec 11 01:35:21 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Mon, 11 Dec 2023 09:35:21 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
Message-ID: <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>



On 12/11/23 06:56, Mahapatra, Amit Kumar wrote:
> 
> 
>> -----Original Message-----
>> From: Tudor Ambarus <tudor.ambarus at linaro.org>
>> Sent: Monday, December 11, 2023 9:03 AM
>> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
>> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
>> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
>> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
>> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
>> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
>> michael at walle.cc; linux-mtd at lists.infradead.org;
>> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
>> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
>> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
>> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
>> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
>> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
>> in spi-nor
>>
>>
>>
>> On 12/8/23 17:05, Mahapatra, Amit Kumar wrote:
>>> Hello Tudor,
>>
>> Hi!
> 
> Hello Tudor,
> 

Hi!

>>
>>>
>>>> -----Original Message-----
>>>> From: Tudor Ambarus <tudor.ambarus at linaro.org>
>>>> Sent: Wednesday, December 6, 2023 8:00 PM
>>>> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
>>>> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
>>>> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
>>>> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
>>>> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
>>>> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
>>>> michael at walle.cc; linux-mtd at lists.infradead.org;
>>>> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
>>>> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>;
>>>> linux- arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
>>>> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
>>>> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
>>>> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories
>>>> support in spi-nor
>>>>
>>>> Hi, Amit,
>>>>
>>>> On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
>>>>> Each flash that is connected in stacked mode should have a separate
>>>>> parameter structure. So, the flash parameter member(*params) of the
>>>>> spi_nor structure is changed to an array (*params[2]). The array is
>>>>> used to store the parameters of each flash connected in stacked
>>>> configuration.
>>>>>
>>>>> The current implementation assumes that a maximum of two flashes are
>>>>> connected in stacked mode and both the flashes are of same make but
>>>>> can differ in sizes. So, except the sizes all other flash parameters
>>>>> of both the flashes are identical.
>>>>
>>>> Do you plan to add support for different flashes in stacked mode? If
>>>> not,
>>>
>>> No, according to the current implementation, in stacked mode, both
>>> flashes must be of the same make.
>>>
>>>> wouldn't it be simpler to have just an array of flash sizes instead
>>>> of duplicating the entire params struct?
>>>
>>> Yes, that is accurate. In alignment with our current stacked support
>>> use case we can have an array of flash sizes instead.
>>> The primary purpose of having an array of params struct was to
>>> facilitate potential future extensions, allowing the addition of
>>> stacked support for different flashes
>>>
>>
>> right. Don't do this change yet, let's decide on the overall architecture first.
> 
> Sure.
>>
>>>>
>>>>>
>>>>> SPI-NOR is not aware of the chip_select values, for any incoming
>>>>> request SPI-NOR will decide the flash index with the help of
>>>>> individual flash size and the configuration type (single/stacked).
>>>>> SPI-NOR will pass on the flash index information to the SPI core &
>>>>> SPI driver by setting the appropriate bit in
>>>>> nor->spimem->spi->cs_index_mask. For example, if nth bit of
>>>>> nor->spimem->spi->cs_index_mask is set then the driver would
>>>>> assert/de-assert spi->chip_slect[n].
>>>>>
>>>>> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
>> mahapatra at amd.com>
>>>>> ---
>>>>>  drivers/mtd/spi-nor/core.c  | 272 +++++++++++++++++++++++++++++-----
>> --
>>>>>  drivers/mtd/spi-nor/core.h  |   4 +
>>>>>  include/linux/mtd/spi-nor.h |  15 +-
>>>>>  3 files changed, 240 insertions(+), 51 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>>>>> index 93ae69b7ff83..e990be7c7eb6 100644
>>>>> --- a/drivers/mtd/spi-nor/core.c
>>>>> +++ b/drivers/mtd/spi-nor/core.c
>>>>
>>>> cut
>>>>
>>>>> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct
>>>>> spi_nor *nor)  static int spi_nor_late_init_params(struct spi_nor
>>>>> *nor)  {
>>>>>  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
>>>> 0);
>>>>> -	int ret;
>>>>> +	struct device_node *np = spi_nor_get_flash_node(nor);
>>>>> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
>>>>> +	u32 idx = 0;
>>>>> +	int rc, ret;
>>>>>
>>>>>  	if (nor->manufacturer && nor->manufacturer->fixups &&
>>>>>  	    nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
>>>>> static int spi_nor_late_init_params(struct spi_nor *nor)
>>>>>  	if (params->n_banks > 1)
>>>>>  		params->bank_size = div64_u64(params->size, params-
>> n_banks);
>>>>>
>>>>> +	nor->num_flash = 0;
>>>>> +
>>>>> +	/*
>>>>> +	 * The flashes that are connected in stacked mode should be of
>>>>> +same
>>>> make.
>>>>> +	 * Except the flash size all other properties are identical for all the
>>>>> +	 * flashes connected in stacked mode.
>>>>> +	 * The flashes that are connected in parallel mode should be identical.
>>>>> +	 */
>>>>> +	while (idx < SNOR_FLASH_CNT_MAX) {
>>>>> +		rc = of_property_read_u64_index(np, "stacked-memories",
>>>> idx,
>>>>> +&flash_size[idx]);
>>>>
>>>> This is a little late in my opinion, as we don't have any sanity
>>>> check on the flashes that are stacked on top of the first. We shall
>>>> at least read and compare the ID for all.
>>>
>>> Alright, I will incorporate a sanity check for reading and comparing
>>> the ID of the stacked flash. Subsequently, I believe this stacked
>>> logic should be relocated to spi_nor_get_flash_info() where we
>>> identify the first flash. Please share your thoughts on this.
>>> Additionally, do you
>>
>> I'm wondering whether we can add a layer on top of the flash type to handle
> 
> When you mention "on top," are you referring to incorporating it into 
> the MTD layer? Initially, Miquel had submitted this patch to address 

I mean something above SPI MEM flashes, be it NOR, NANDs or whatever.
Instead of treating the stacked flashes as a monolithic device and treat
in SPI NOR some array of flashes, to have a layer above which probes the
SPI MEM flash driver for each stacked flash. In your case SPI NOR would
be probed twice, as you use 2 SPI NOR flashes.

> stacked/parallel handling in the MTD layer.
> https://lore.kernel.org/linux-mtd/20200114191052.0a16d116 at xps13/t/
> However, the Device Tree bindings were initially not accepted. 

Okay, thanks for the pointer. I'll take a look.

> Following a series of discussions, the below bindings were 
> eventually merged.
> https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal at bootlin.com/

I saw, thanks.

> 
>> the stacked/parallel modes. This way everything will become flash type
>> independent. Would it be possible to stack 2 SPI NANDs? How about a SPI
>> NOR and a SPI NAND?
>>
>> Is the datasheet of the controller public?
> 
> Yes, https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Controller
> 

Wonderful, I'll take a look. I see two clocks there. Does this mean that
the stacked flashes can be operated at different frequencies? Do you
know if we can combine a SPI NOR with a SPI NAND in stacked configuration?

I need to study this a bit. I'll try to involve Michael and Pratyush too.

Cheers,
ta


From tabba at google.com  Mon Dec 11 01:38:11 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 11 Dec 2023 09:38:11 +0000
Subject: [PATCH 13/13] arm64/sysreg: Add new system registers for GCS
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-13-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org> <20231209-b4-arm64-sysreg-additions-v1-13-45284e538474@kernel.org>
Message-ID: <CA+EHjTwcGzWHsLGeOyF-8dWhn5TXBeAq68YA3Cs57jgs8H-dvA@mail.gmail.com>

Hi Mark,

On Sat, Dec 9, 2023 at 1:04?AM Mark Brown <broonie at kernel.org> wrote:
>
> FEAT_GCS introduces a number of new system registers. Add the registers
> available up to EL2 to sysreg as per DDI0601 2022-12.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  arch/arm64/tools/sysreg | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 1c6d1c904750..b2007963523e 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -1903,6 +1903,41 @@ Sysreg   SMCR_EL1        3       0       1       2       6
>  Fields SMCR_ELx
>  EndSysreg
>
> +SysregFields   GCSCR_ELx
> +Res0   63:10
> +Field  9       STREn
> +Field  8       PUSHMEn

This is related to my comment for patch 11/13 on HCRX_EL2, now we have
a case where the n is in the spec itself, rather than a prefix. Not
sure if it would be good to add an n as a prefix as well to these,
since they do trap at 0, or if you should just forget my comment on
patch 11 :)

Reviewed-by: Fuad Tabba <tabba at google.com>

Cheers,
/fuad



> +Res0   7
> +Field  6       EXLOCKEN
> +Field  5       RVCHKEN
> +Res0   4:1
> +Field  0       PCRSEL
> +EndSysregFields
> +
> +Sysreg GCSCR_EL1       3       0       2       5       0
> +Fields GCSCR_ELx
> +EndSysreg
> +
> +SysregFields   GCSPR_ELx
> +Field  63:3    PTR
> +Res0   2:0
> +EndSysregFields
> +
> +Sysreg GCSPR_EL1       3       0       2       5       1
> +Fields GCSPR_ELx
> +EndSysreg
> +
> +Sysreg GCSCRE0_EL1     3       0       2       5       2
> +Res0   63:11
> +Field  10      nTR
> +Field  9       STREn
> +Field  8       PUSHMEn
> +Res0   7:6
> +Field  5       RVCHKEN
> +Res0   4:1
> +Field  0       PCRSEL
> +EndSysreg
> +
>  Sysreg ALLINT  3       0       4       3       0
>  Res0   63:14
>  Field  13      ALLINT
> @@ -2133,6 +2168,10 @@ Field    4       DZP
>  Field  3:0     BS
>  EndSysreg
>
> +Sysreg GCSPR_EL0       3       3       2       5       1
> +Fields GCSPR_ELx
> +EndSysreg
> +
>  Sysreg SVCR    3       3       4       2       2
>  Res0   63:2
>  Field  1       ZA
> @@ -2531,6 +2570,14 @@ Sysreg   SMCR_EL2        3       4       1       2       6
>  Fields SMCR_ELx
>  EndSysreg
>
> +Sysreg GCSCR_EL2       3       4       2       5       0
> +Fields GCSCR_ELx
> +EndSysreg
> +
> +Sysreg GCSPR_EL2       3       4       2       5       1
> +Fields GCSPR_ELx
> +EndSysreg
> +
>  Sysreg DACR32_EL2      3       4       3       0       0
>  Res0   63:32
>  Field  31:30   D15
> @@ -2590,6 +2637,14 @@ Sysreg   SMCR_EL12       3       5       1       2       6
>  Fields SMCR_ELx
>  EndSysreg
>
> +Sysreg GCSCR_EL12      3       5       2       5       0
> +Fields GCSCR_ELx
> +EndSysreg
> +
> +Sysreg GCSPR_EL12      3       5       2       5       1
> +Fields GCSPR_ELx
> +EndSysreg
> +
>  Sysreg FAR_EL12        3       5       6       0       0
>  Field  63:0    ADDR
>  EndSysreg
>
> --
> 2.39.2
>


From angelogioacchino.delregno at collabora.com  Mon Dec 11 01:48:54 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 11 Dec 2023 10:48:54 +0100
Subject: [PATCH] ASoC: mediatek: mt7986: silence error in case of
 -EPROBE_DEFER
In-Reply-To: <98491ec78ab671f5a14fce42d10f9745ebddb112.1702258360.git.daniel@makrotopia.org>
References: <98491ec78ab671f5a14fce42d10f9745ebddb112.1702258360.git.daniel@makrotopia.org>
Message-ID: <1db19550-99c2-4094-95d9-9db1c384519f@collabora.com>

Il 11/12/23 02:33, Daniel Golle ha scritto:
> If probe is defered no error should be printed. Mute it.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>   sound/soc/mediatek/mt7986/mt7986-wm8960.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/soc/mediatek/mt7986/mt7986-wm8960.c b/sound/soc/mediatek/mt7986/mt7986-wm8960.c
> index c1390b3734101..24a4b943030d7 100644
> --- a/sound/soc/mediatek/mt7986/mt7986-wm8960.c
> +++ b/sound/soc/mediatek/mt7986/mt7986-wm8960.c
> @@ -144,7 +144,9 @@ static int mt7986_wm8960_machine_probe(struct platform_device *pdev)
>   
>   	ret = devm_snd_soc_register_card(&pdev->dev, card);
>   	if (ret) {
> -		dev_err(&pdev->dev, "%s snd_soc_register_card fail: %d\n", __func__, ret);
> +		if (ret != -EPROBE_DEFER)
> +			dev_err(&pdev->dev, "%s snd_soc_register_card fail: %d\n", __func__, ret);

This is *exactly* what dev_err_probe() does! :-)

dev_err_probe(&pdev->dev, ret, "%s snd_soc_register_card fail: %d\n", __func__);

Regards,
Angelo




From andyshrk at 163.com  Mon Dec 11 01:49:58 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 11 Dec 2023 17:49:58 +0800 (CST)
Subject: [PATCH v2 5/5] arm64: dts: rockchip: Add support for rk3588
 based board Cool Pi CM5 EVB
In-Reply-To: <2b58450a-1bde-424b-ab69-a3834914522c@linaro.org>
References: <20231210080313.1667013-1-andyshrk@163.com>
 <20231210080629.1667589-1-andyshrk@163.com>
 <2b58450a-1bde-424b-ab69-a3834914522c@linaro.org>
Message-ID: <14ab4c8c.4fa1.18c58488bf2.Coremail.andyshrk@163.com>


Hi Krzysztof?

At 2023-12-10 19:12:15, "Krzysztof Kozlowski" <krzysztof.kozlowski at linaro.org> wrote:
>On 10/12/2023 09:06, Andy Yan wrote:
>> Cool Pi CM5 EVB is a board based on rk3588.
>> 
>> Specification:
>> - Rockchip RK3588
>> - LPDDR4 2/4/8/16 GB
>> - TF scard slot
>> - eMMC 8/32/64/128 GB module
>> - Gigabit ethernet x 1 with PHY YT8531
>> - Gigabit ethernet x 1 drived by PCIE with YT6801S
>> - HDMI Type A out x 2
>> - HDMI Type D in x 1
>> - USB 2.0 Host x 2
>> - USB 3.0 OTG x 1
>> - USB 3.0 Host x 1
>> - PCIE M.2 E Key for Wireless connection
>> - PCIE M.2 M Key for NVME connection
>> - 40 pin header
>
>
>> +
>> +	backlight: backlight {
>> +		compatible = "pwm-backlight";
>> +		power-supply = <&vcc12v_dcin>;
>> +		pwms = <&pwm2 0 25000 0>;
>> +		enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&bl_en>;
>> +		status = "okay";
>
>This is a friendly reminder during the review process.
>
>It seems my or other reviewer's previous comments were not fully
>addressed. Maybe the feedback got lost between the quotes, maybe you
>just forgot to apply it. Please go back to the previous discussion and
>either implement all requested changes or keep discussing them.

Yes? it seems that the comments were lost? I didn't get any comments about PATCH 5 in my V1.
Anyway, I will check this patch again, and fix the issue I find by myself.
>
>Thank you.
>
>Best regards,
>Krzysztof
>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

From quic_mnaresh at quicinc.com  Mon Dec 11 01:56:16 2023
From: quic_mnaresh at quicinc.com (Naresh Maramaina)
Date: Mon, 11 Dec 2023 15:26:16 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231206152646.GH12802@thinkpad>
References: <20231204143101.64163-1-quic_mnaresh@quicinc.com>
 <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <20231206152646.GH12802@thinkpad>
Message-ID: <9330ff38-5285-43d8-bf90-3441762fdb9c@quicinc.com>


On 12/6/2023 8:56 PM, Manivannan Sadhasivam wrote:
> On Mon, Dec 04, 2023 at 08:00:59PM +0530, Maramaina Naresh wrote:
>> Register ufs driver to CPU latency PM QoS framework can improves
>> ufs device random io performance.
>>
>> PM QoS initialization will insert new QoS request into the CPU
>> latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
>> value.
>>
>> UFS driver will vote for performance mode on scale up and power
>> save mode for scale down.
>>
>> If clock scaling feature is not enabled then voting will be based
>> on clock on or off condition.
>>
>> tiotest benchmark tool io performance results on sm8550 platform:
>>
>> 1. Without PM QoS support
>> 	Type (Speed in)    | Average of 18 iterations
>> 	Random Write(IPOS) | 41065.13
>> 	Random Read(IPOS)  | 37101.3
>>
>> 2. With PM QoS support
>> 	Type (Speed in)    | Average of 18 iterations
>> 	Random Write(IPOS) | 46784.9
>> 	Random Read(IPOS)  | 42943.4
>> (Improvement % with PM QoS = ~15%).
>>
>> Co-developed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
>> Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
>> Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall at quicinc.com>
>> Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
>> ---
>>   drivers/ufs/core/ufshcd-priv.h |  8 +++++
>>   drivers/ufs/core/ufshcd.c      | 62 ++++++++++++++++++++++++++++++++++
>>   include/ufs/ufshcd.h           | 16 +++++++++
>>   3 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/ufs/core/ufshcd-priv.h b/drivers/ufs/core/ufshcd-priv.h
>> index f42d99ce5bf1..536805f6c4e1 100644
>> --- a/drivers/ufs/core/ufshcd-priv.h
>> +++ b/drivers/ufs/core/ufshcd-priv.h
>> @@ -241,6 +241,14 @@ static inline void ufshcd_vops_config_scaling_param(struct ufs_hba *hba,
>>   		hba->vops->config_scaling_param(hba, p, data);
>>   }
>>   
>> +static inline u32 ufshcd_vops_config_qos_vote(struct ufs_hba *hba)
>> +{
>> +	if (hba->vops && hba->vops->config_qos_vote)
>> +		return hba->vops->config_qos_vote(hba);
> 
> Please remove this callback as Bart noted.
> 

Sure Mani, will takecare of this comment.

>> +
>> +	return UFSHCD_QOS_DEFAULT_VOTE;
>> +}
>> +
>>   static inline void ufshcd_vops_reinit_notify(struct ufs_hba *hba)
>>   {
>>   	if (hba->vops && hba->vops->reinit_notify)
>> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
>> index ae9936fc6ffb..13370febd2b5 100644
>> --- a/drivers/ufs/core/ufshcd.c
>> +++ b/drivers/ufs/core/ufshcd.c
>> @@ -1001,6 +1001,20 @@ static bool ufshcd_is_unipro_pa_params_tuning_req(struct ufs_hba *hba)
>>   	return ufshcd_get_local_unipro_ver(hba) < UFS_UNIPRO_VER_1_6;
>>   }
>>   
>> +/**
>> + * ufshcd_pm_qos_perf - vote for PM QoS performance or power save mode
> 
> ufshcd_pm_qos_update() - Update PM QoS request
> 

Sure Mani, will takecare of this comment.

>> + * @hba: per adapter instance
>> + * @on: If True, vote for perf PM QoS mode otherwise power save mode
>> + */
>> +static void ufshcd_pm_qos_perf(struct ufs_hba *hba, bool on)
>> +{
>> +	if (!hba->pm_qos_init)
>> +		return;
>> +
>> +	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? hba->qos_vote
>> +							: PM_QOS_DEFAULT_VALUE);
>> +}
>> +
>>   /**
>>    * ufshcd_set_clk_freq - set UFS controller clock frequencies
>>    * @hba: per adapter instance
>> @@ -1153,6 +1167,10 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, unsigned long freq,
>>   	trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
>>   			(scale_up ? "up" : "down"),
>>   			ktime_to_us(ktime_sub(ktime_get(), start)), ret);
>> +
>> +	if (!ret)
>> +		ufshcd_pm_qos_perf(hba, scale_up);
> 
> Can't you just move this before trace_ufshcd_profile_clk_scaling()? This also
> avoids checking for !ret.
> 

In this case, we need to use goto out; inside if condition of 
ufshcd_vops_clk_scale_notify.

we can enable ufshcd_pm_qos_perf only when ufshcd_vops_clk_scale_notify 
is successful.

Will add goto out; in next patch set.


>> +
>>   	return ret;
>>   }
>>   
>> @@ -9204,6 +9222,8 @@ static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
>>   	if (ret)
>>   		return ret;
>>   
>> +	if (!ufshcd_is_clkscaling_supported(hba))
>> +		ufshcd_pm_qos_perf(hba, on);
>>   out:
>>   	if (ret) {
>>   		list_for_each_entry(clki, head, list) {
>> @@ -9296,6 +9316,45 @@ static int ufshcd_init_clocks(struct ufs_hba *hba)
>>   	return ret;
>>   }
>>   
>> +/**
>> + * ufshcd_pm_qos_init - initialize PM QoS instance
> 
> "Initialize PM QoS request"
> 

Sure Mani, will takecare of this comment.

>> + * @hba: per adapter instance
>> + */
>> +static void ufshcd_pm_qos_init(struct ufs_hba *hba)
>> +{
>> +	if (!(hba->caps & UFSHCD_CAP_PM_QOS))
>> +		return;
>> +
>> +	/*
>> +	 * called to configure PM QoS vote value for UFS host,
>> +	 * expecting qos vote return value from caller else
>> +	 * default vote value will be return.
>> +	 */
>> +	hba->qos_vote = ufshcd_vops_config_qos_vote(hba);
> 
> No need of this variable too if you get rid of the callback.
> 
>> +	cpu_latency_qos_add_request(&hba->pm_qos_req,
>> +					PM_QOS_DEFAULT_VALUE);
>> +
>> +	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
>> +		hba->pm_qos_init = true;
> 
> Why do you need this flag?

this flag ensure UFS qos request got added into the list.

> 
>> +
>> +	dev_dbg(hba->dev, "%s: QoS %s, qos_vote: %u\n", __func__,
>> +		hba->pm_qos_init ? "initialized" : "uninitialized",
>> +		hba->qos_vote);
>> +}
>> +
>> +/**
>> + * ufshcd_pm_qos_exit - remove instance from PM QoS
>> + * @hba: per adapter instance
>> + */
>> +static void ufshcd_pm_qos_exit(struct ufs_hba *hba)
>> +{
>> +	if (!hba->pm_qos_init)
>> +		return;
>> +
>> +	cpu_latency_qos_remove_request(&hba->pm_qos_req);
>> +	hba->pm_qos_init = false;
>> +}
>> +
> 
> [...]
> 
>>   /**
>>    * struct ufs_hba - per adapter private structure
>>    * @mmio_base: UFSHCI base register address
>> @@ -912,6 +923,8 @@ enum ufshcd_mcq_opr {
>>    * @mcq_base: Multi circular queue registers base address
>>    * @uhq: array of supported hardware queues
>>    * @dev_cmd_queue: Queue for issuing device management commands
>> + * @pm_qos_req: PM QoS request handle
>> + * @pm_qos_init: flag to check if pm qos init completed
>>    */
>>   struct ufs_hba {
>>   	void __iomem *mmio_base;
>> @@ -1076,6 +1089,9 @@ struct ufs_hba {
>>   	struct ufs_hw_queue *uhq;
>>   	struct ufs_hw_queue *dev_cmd_queue;
>>   	struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
>> +	struct pm_qos_request pm_qos_req;
>> +	bool pm_qos_init;
>> +	u32 qos_vote;
> 
> Order doesn't match Kdoc.
>

qos_vote variable will be remove as per latest comment.

> - Mani
> 

Thanks,
Naresh.


From angelogioacchino.delregno at collabora.com  Mon Dec 11 01:57:00 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 11 Dec 2023 10:57:00 +0100
Subject: [PATCH v4 4/4] clk: mediatek: add drivers for MT7988 SoC
In-Reply-To: <879b5bbcb165aa3f059a41218142b27e5f64597f.1702158423.git.daniel@makrotopia.org>
References: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
 <879b5bbcb165aa3f059a41218142b27e5f64597f.1702158423.git.daniel@makrotopia.org>
Message-ID: <060c8068-0f9b-40b4-89ed-3b968e4b0071@collabora.com>

Il 09/12/23 22:56, Daniel Golle ha scritto:
> From: Sam Shih <sam.shih at mediatek.com>
> 
> Add APMIXED, ETH, INFRACFG and TOPCKGEN clock drivers which are
> typical MediaTek designs.
> 
> Also add driver for XFIPLL clock generating the 156.25MHz clock for
> the XFI SerDes. It needs an undocumented software workaround and has
> an unknown internal design.
> 
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
> v4:
>   * make use of existing GATE_MTK_FLAGS macro
>   * reformat to max. 100 columns
>   * cosmetics
> 
> v3: use git --from ...
> v2: no changes
> 
> 
>   drivers/clk/mediatek/Kconfig               |   9 +
>   drivers/clk/mediatek/Makefile              |   5 +
>   drivers/clk/mediatek/clk-mt7988-apmixed.c  | 102 +++++++
>   drivers/clk/mediatek/clk-mt7988-eth.c      | 133 +++++++++
>   drivers/clk/mediatek/clk-mt7988-infracfg.c | 274 +++++++++++++++++
>   drivers/clk/mediatek/clk-mt7988-topckgen.c | 325 +++++++++++++++++++++
>   drivers/clk/mediatek/clk-mt7988-xfipll.c   |  78 +++++
>   7 files changed, 926 insertions(+)
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-apmixed.c
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-eth.c
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-infracfg.c
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-topckgen.c
>   create mode 100644 drivers/clk/mediatek/clk-mt7988-xfipll.c
> 
> diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> index 48b42d11111cd..70a005e7e1b18 100644
> --- a/drivers/clk/mediatek/Kconfig
> +++ b/drivers/clk/mediatek/Kconfig
> @@ -423,6 +423,15 @@ config COMMON_CLK_MT7986_ETHSYS
>   	  This driver adds support for clocks for Ethernet and SGMII
>   	  required on MediaTek MT7986 SoC.
>   
> +config COMMON_CLK_MT7988
> +	tristate "Clock driver for MediaTek MT7988"
> +	depends on ARCH_MEDIATEK || COMPILE_TEST
> +	select COMMON_CLK_MEDIATEK
> +	default ARCH_MEDIATEK
> +	help
> +	  This driver supports MediaTek MT7988 basic clocks and clocks
> +	  required for various periperals found on this SoC.
> +
>   config COMMON_CLK_MT8135
>   	tristate "Clock driver for MediaTek MT8135"
>   	depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index dbeaa5b41177d..eeccfa039896f 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -62,6 +62,11 @@ obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-apmixed.o
>   obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-topckgen.o
>   obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-infracfg.o
>   obj-$(CONFIG_COMMON_CLK_MT7986_ETHSYS) += clk-mt7986-eth.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-apmixed.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-topckgen.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-infracfg.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-eth.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-xfipll.o
>   obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135-apmixedsys.o clk-mt8135.o
>   obj-$(CONFIG_COMMON_CLK_MT8167) += clk-mt8167-apmixedsys.o clk-mt8167.o
>   obj-$(CONFIG_COMMON_CLK_MT8167_AUDSYS) += clk-mt8167-aud.o
> diff --git a/drivers/clk/mediatek/clk-mt7988-apmixed.c b/drivers/clk/mediatek/clk-mt7988-apmixed.c
> new file mode 100644
> index 0000000000000..02eb6354b01a8
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt7988-apmixed.c
> @@ -0,0 +1,102 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2023 MediaTek Inc.
> + * Author: Sam Shih <sam.shih at mediatek.com>
> + * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include "clk-mtk.h"
> +#include "clk-gate.h"
> +#include "clk-mux.h"
> +#include "clk-pll.h"
> +#include <dt-bindings/clock/mediatek,mt7988-clk.h>
> +
> +#define MT7988_PLL_FMAX (2500UL * MHZ)
> +#define MT7988_PCW_CHG_SHIFT 2
> +
> +#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _rst_bar_mask, _pcwbits, _pd_reg,      \
> +	    _pd_shift, _tuner_reg, _tuner_en_reg, _tuner_en_bit, _pcw_reg, _pcw_shift,           \
> +	    _pcw_chg_reg)                                                                        \
> +	{                                                                                        \
> +		.id = _id, .name = _name, .reg = _reg, .pwr_reg = _pwr_reg, .en_mask = _en_mask, \
> +		.flags = _flags, .rst_bar_mask = BIT(_rst_bar_mask), .fmax = MT7988_PLL_FMAX,    \
> +		.pcwbits = _pcwbits, .pd_reg = _pd_reg, .pd_shift = _pd_shift,                   \
> +		.tuner_reg = _tuner_reg, .tuner_en_reg = _tuner_en_reg,                          \
> +		.tuner_en_bit = _tuner_en_bit, .pcw_reg = _pcw_reg, .pcw_shift = _pcw_shift,     \
> +		.pcw_chg_reg = _pcw_chg_reg, .pcw_chg_shift = MT7988_PCW_CHG_SHIFT,              \
> +		.parent_name = "clkxtal",                                                        \
> +	}

I think that there was a bit of misunderstanding here: I said 100cols, and that's
fine, but I wanted you to do that with everything but the macros, following what
was done in all the other MediaTek clock drivers.

Can you please change the macros again?

Also, there's some discrepancy in the usage of tabulations vs spaces, please fix.

#define PLL(....)*TAB*\

....

	{										\
		.id = _id,							\
		.name = _name,							\
		.reg = _reg,							\
		.pwr_reg = _pwr_reg,						\
		.en_mask = _en_mask,						\
		...etc etc etc...						\
}

Thanks,
Angelo


From angelogioacchino.delregno at collabora.com  Mon Dec 11 01:58:26 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 11 Dec 2023 10:58:26 +0100
Subject: [PATCH v4 1/4] dt-bindings: clock: mediatek: add MT7988 clock IDs
In-Reply-To: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
References: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
Message-ID: <0695179a-6dea-4a68-9a2a-195d3a4ffa10@collabora.com>

Il 09/12/23 22:55, Daniel Golle ha scritto:
> From: Sam Shih <sam.shih at mediatek.com>
> 
> Add MT7988 clock dt-bindings for topckgen, apmixedsys, infracfg,
> ethernet and xfipll subsystem clocks.
> 
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From krzysztof.kozlowski at linaro.org  Mon Dec 11 01:58:59 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 10:58:59 +0100
Subject: [PATCH v2 5/5] arm64: dts: rockchip: Add support for rk3588 based
 board Cool Pi CM5 EVB
In-Reply-To: <14ab4c8c.4fa1.18c58488bf2.Coremail.andyshrk@163.com>
References: <20231210080313.1667013-1-andyshrk@163.com>
 <20231210080629.1667589-1-andyshrk@163.com>
 <2b58450a-1bde-424b-ab69-a3834914522c@linaro.org>
 <14ab4c8c.4fa1.18c58488bf2.Coremail.andyshrk@163.com>
Message-ID: <f61a9382-a2b9-44a8-a33e-4c4f8d6cae50@linaro.org>

On 11/12/2023 10:49, Andy Yan wrote:
>>> +
>>> +	backlight: backlight {
>>> +		compatible = "pwm-backlight";
>>> +		power-supply = <&vcc12v_dcin>;
>>> +		pwms = <&pwm2 0 25000 0>;
>>> +		enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
>>> +		pinctrl-names = "default";
>>> +		pinctrl-0 = <&bl_en>;
>>> +		status = "okay";
>>
>> This is a friendly reminder during the review process.
>>
>> It seems my or other reviewer's previous comments were not fully
>> addressed. Maybe the feedback got lost between the quotes, maybe you
>> just forgot to apply it. Please go back to the previous discussion and
>> either implement all requested changes or keep discussing them.
> 
> Yes? it seems that the comments were lost? I didn't get any comments about PATCH 5 in my V1.
> Anyway, I will check this patch again, and fix the issue I find by myself.

I don't have to repeat the same comment for every same thing to fix.
It's your task to fix all occurrences of the same issue.

Best regards,
Krzysztof



From angelogioacchino.delregno at collabora.com  Mon Dec 11 01:59:54 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 11 Dec 2023 10:59:54 +0100
Subject: [PATCH v4 2/4] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <93025cdb7c31bf413fb2be5a071340073a0679d1.1702158423.git.daniel@makrotopia.org>
References: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
 <93025cdb7c31bf413fb2be5a071340073a0679d1.1702158423.git.daniel@makrotopia.org>
Message-ID: <874b8a8b-7fe1-4547-828e-948ed25b7be3@collabora.com>

Il 09/12/23 22:55, Daniel Golle ha scritto:
> Add various clock controllers found in the MT7988 SoC to existing
> bindings (if applicable) and add files for the new ethwarp, mcusys
> and xfi-pll clock controllers not previously present in any SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
> v4:
>   * add subnodes for controllers acting as MFD
> 
> v3:
>   * move clock bindings to clock folder
>   * drop ti,syscon-reset from bindings and example
>   * merge mcusys with topckgen bindings
> 
> v2:
>   * dropped unused labels
>   * add 'type: object' declaration for reset-controller found in new
>     ethwarp controller and represented as ti,syscon-reset
>   * rebase on top of
>     "dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema"
> 
>   .../arm/mediatek/mediatek,infracfg.yaml       |  1 +
>   .../bindings/clock/mediatek,apmixedsys.yaml   |  1 +
>   .../bindings/clock/mediatek,ethsys.yaml       |  1 +
>   .../clock/mediatek,mt7988-ethwarp.yaml        | 66 +++++++++++++++++++
>   .../clock/mediatek,mt7988-xfi-pll.yaml        | 48 ++++++++++++++
>   .../bindings/clock/mediatek,topckgen.yaml     |  2 +
>   .../bindings/net/pcs/mediatek,sgmiisys.yaml   | 61 ++++++++++++++---
>   7 files changed, 171 insertions(+), 9 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
>   create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
> 

..snip..

> diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
> new file mode 100644
> index 0000000000000..e126f3fe0856c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/mediatek,mt7988-ethwarp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT7988 ethwarp Controller
> +
> +maintainers:
> +  - Daniel Golle <daniel at makrotopia.org>
> +
> +description:
> +  The Mediatek MT7988 ethwarp controller provides clocks and resets for the
> +  Ethernet related subsystems found the MT7988 SoC.
> +  The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: mediatek,mt7988-ethwarp
> +      - const: syscon
> +      - const: simple-mfd
> +
> +  reg:
> +    maxItems: 1
> +
> +  '#clock-cells':
> +    const: 1
> +
> +  reset-controller:
> +    type: object
> +    properties:
> +      compatible:
> +        const: ti,syscon-reset
> +
> +    # TODO: Convert to DT schema
> +    additionalProperties: true
> +
> +required:
> +  - compatible
> +  - reg
> +  - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/reset/ti-syscon.h>
> +    soc {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        clock-controller at 15031000 {
> +            compatible = "mediatek,mt7988-ethwarp", "syscon", "simple-mfd";
> +            reg = <0 0x15031000 0 0x1000>;
> +            #clock-cells = <1>;
> +
> +            reset-controller {
> +                compatible = "ti,syscon-reset";

NACK! This is not the right way to do it. Please do *not* use ti,syscon-reset.

Declare your resets in the relevant clock controller driver, like was done with
all (or the vast majority of) the other MediaTek clock drivers.

This means that you don't need simple-mfd here (and probably syscon as well).

Regards,
Angelo




From fancer.lancer at gmail.com  Mon Dec 11 02:00:18 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Mon, 11 Dec 2023 13:00:18 +0300
Subject: [PATCH net v3] net: stmmac: update Rx clk divider for 10M SGMII
In-Reply-To: <20231208062502.13124-1-quic_snehshah@quicinc.com>
References: <20231208062502.13124-1-quic_snehshah@quicinc.com>
Message-ID: <3bwuo4lpo5h75wbscsgi2jtn5ex45vx5fvezocwjbetnbwriyr@ltdd5axuri6e>

On Fri, Dec 08, 2023 at 11:55:02AM +0530, Sneh Shah wrote:
> SGMII 10MBPS mode needs RX clock divider to avoid drops in Rx.
> Update configure SGMII function with rx clk divider programming.

One more time:

> [PATCH v3] net: stmmac: update Rx clk divider for 10M SGMII

It would be better to add "dwmac-qcom-ethqos" prefix to the subject
since the patch concerns the Qualcomm Eth MAC only. This time don't
forget to do that on v4.

-Serge(y)

> 
> Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> ---
> v3 changelog:
> - Added comment to explain why MAC needs to be reconfigured for SGMII
> v2 changelog:
> - Use FIELD_PREP to prepare bifield values in place of GENMASK
> - Add fixes tag
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index d3bf42d0fceb..ab2245995bc6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -34,6 +34,7 @@
>  #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
>  #define RGMII_CONFIG_PROG_SWAP			BIT(1)
>  #define RGMII_CONFIG_DDR_MODE			BIT(0)
> +#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)
>  
>  /* SDCC_HC_REG_DLL_CONFIG fields */
>  #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
> @@ -598,6 +599,9 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>  	return 0;
>  }
>  
> +/* On interface toggle MAC registetrs gets reset.
> + * Configure MAC block for SGMII on ethernet phy link up
> + */
>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  {
>  	int val;
> @@ -617,6 +621,9 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  	case SPEED_10:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> +		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
> +			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR, 0x31),
> +			      RGMII_IO_MACRO_CONFIG);
>  		break;
>  	}
>  
> -- 
> 2.17.1
> 
> 


From quic_pkondeti at quicinc.com  Mon Dec 11 02:00:02 2023
From: quic_pkondeti at quicinc.com (Pavan Kondeti)
Date: Mon, 11 Dec 2023 15:30:02 +0530
Subject: [PATCH V2 1/3] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231207112101.GK2932@thinkpad>
References: <20231204143101.64163-2-quic_mnaresh@quicinc.com>
 <590ade27-b4da-49be-933b-e9959aa0cd4c@acm.org>
 <692cd503-5b14-4be6-831d-d8e9c282a95e@quicinc.com>
 <5e7c5c75-cb5f-4afe-9d57-b0cab01a6f26@acm.org>
 <b9373252-710c-4a54-95cc-046314796960@quicinc.com>
 <20231206153242.GI12802@thinkpad>
 <effb603e-ca7a-4f24-9783-4d62790165ae@acm.org>
 <20231207094357.GI2932@thinkpad>
 <286b6f8a-c634-19ed-cf53-276cfe05d03f@quicinc.com>
 <20231207112101.GK2932@thinkpad>
Message-ID: <eb0b15c5-a7e0-4144-b5f8-a8e1818b1d9f@quicinc.com>

On Thu, Dec 07, 2023 at 04:51:01PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Dec 07, 2023 at 03:56:43PM +0530, Nitin Rawat wrote:
> > 
> > 
> > On 12/7/2023 3:13 PM, Manivannan Sadhasivam wrote:
> > > On Wed, Dec 06, 2023 at 03:02:04PM -1000, Bart Van Assche wrote:
> > > > On 12/6/23 05:32, Manivannan Sadhasivam wrote:
> > > > > On Wed, Dec 06, 2023 at 07:32:54PM +0530, Naresh Maramaina wrote:
> > > > > > On 12/5/2023 10:41 PM, Bart Van Assche wrote:
> > > > > > > On 12/4/23 21:58, Naresh Maramaina wrote:
> > > > > > > > On 12/5/2023 12:30 AM, Bart Van Assche wrote:
> > > > > > > > > On 12/4/23 06:30, Maramaina Naresh wrote:
> > > > > > > > > > +??? /* This capability allows the host controller driver to
> > > > > > > > > > use the PM QoS
> > > > > > > > > > +???? * feature.
> > > > > > > > > > +???? */
> > > > > > > > > > +??? UFSHCD_CAP_PM_QOS??????????????? = 1 << 13,
> > > > > > > > > >   ? };
> > > > > > > > > 
> > > > > > > > > Why does it depend on the host driver whether or not PM QoS is
> > > > > > > > > enabled? Why isn't it enabled unconditionally?
> > > > > > > > 
> > > > > > > > For some platform vendors power KPI might be more important than
> > > > > > > > random io KPI. Hence this flag is disabled by default and can be
> > > > > > > > enabled based on platform requirement.
> > > > > > > 
> > > > > > > How about leaving this flag out unless if a host vendor asks explicitly
> > > > > > > for this flag?
> > > > > > 
> > > > > > IMHO, instead of completely removing this flag, how about having
> > > > > > flag like "UFSHCD_CAP_DISABLE_PM_QOS" which will make PMQOS enable
> > > > > > by default and if some host vendor wants to disable it explicitly,
> > > > > > they can enable that flag.
> > > > > > Please let me know your opinion.
> > > > 
> > > > That would result in a flag that is tested but that is never set by
> > > > upstream code. I'm not sure that's acceptable.
> > > > 
> > > 
> > > Agree. The flag shouldn't be introduced if there are no users.
> > > 
> > > > > If a vendor wants to disable this feature, then the driver has to be modified.
> > > > > That won't be very convenient. So either this has to be configured through sysfs
> > > > > or Kconfig if flexibility matters.
> > > > 
> > > > Kconfig sounds worse to me because changing any Kconfig flag requires a
> > > > modification of the Android GKI kernel.
> > > > 
> > > 
> > > Hmm, ok. Then I think we can have a sysfs hook to toggle the enable switch.
> > 
> > Hi Bart, Mani
> > 
> > How about keeping this feature enabled by default and having a module
> > parameter to disable pmqos feature if required ?
> > 
> 
> Module params not encouraged these days unless there are no other feasible
> options available.

Yeah, one of the problem with module param is that we can't have
different settings for two two UFS controllers. Anyways, this setting
need not be a module param, there is nothing special about this setting
that is tied to module loading (driver probe) time, AFAICT.

Thanks,
Pavan


From jianjun.wang at mediatek.com  Mon Dec 11 01:49:23 2023
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Mon, 11 Dec 2023 17:49:23 +0800
Subject: [PATCH v4] PCI: mediatek: Clear interrupt status before dispatching handler
Message-ID: <20231211094923.31967-1-jianjun.wang@mediatek.com>

From: qizhong cheng <qizhong.cheng at mediatek.com>

We found a failure when used iperf tool for wifi performance testing,
there are some MSIs received while clearing the interrupt status,
these MSIs cannot be serviced.

The interrupt status can be cleared even the MSI status still remaining,
as an edge-triggered interrupts, its interrupt status should be cleared
before dispatching to the handler of device.

Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622")
Signed-off-by: qizhong cheng <qizhong.cheng at mediatek.com>
Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Cc: stable at vger.kernel.org
---
v4:
 - Found that this patch has not been merged, resending it as v4.

v3:
 - Add Fix tag.

v2:
 - Update the subject line.
 - Improve the commit log and code comments.
---
 drivers/pci/controller/pcie-mediatek.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 66a8f73296fc..3fb7f08de061 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -617,12 +617,17 @@ static void mtk_pcie_intr_handler(struct irq_desc *desc)
 		if (status & MSI_STATUS){
 			unsigned long imsi_status;
 
+			/*
+			 * The interrupt status can be cleared even the MSI
+			 * status still remaining, hence as an edge-triggered
+			 * interrupts, its interrupt status should be cleared
+			 * before dispatching handler.
+			 */
+			writel(MSI_STATUS, port->base + PCIE_INT_STATUS);
 			while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
 				for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM)
 					generic_handle_domain_irq(port->inner_domain, bit);
 			}
-			/* Clear MSI interrupt status */
-			writel(MSI_STATUS, port->base + PCIE_INT_STATUS);
 		}
 	}
 
-- 
2.18.0



From danishanwar at ti.com  Mon Dec 11 02:00:54 2023
From: danishanwar at ti.com (MD Danish Anwar)
Date: Mon, 11 Dec 2023 15:30:54 +0530
Subject: [PATCH 3/3] arm64: dts: ti: k3-am642-evm: add overlay for icssg1
 2nd port
In-Reply-To: <afec7eaa-9ef5-447f-9619-9721937fe805@ti.com>
References: <20231207081917.340167-1-danishanwar@ti.com>
 <20231207081917.340167-4-danishanwar@ti.com>
 <fe6499b3-fbda-4e2d-9b5e-92cc60d3a79c@lunn.ch>
 <afec7eaa-9ef5-447f-9619-9721937fe805@ti.com>
Message-ID: <9f63b81d-1826-411f-b310-e726e5eb5cb3@ti.com>

Hi Andrew,

On 08/12/23 12:58 pm, Anwar, Md Danish wrote:
> On 12/8/2023 3:10 AM, Andrew Lunn wrote:
>>> +	mdio-mux-2 {
>>> +		compatible = "mdio-mux-multiplexer";
>>> +		mux-controls = <&mdio_mux>;
>>> +		mdio-parent-bus = <&icssg1_mdio>;
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +
>>> +		mdio at 0 {
>>> +			reg = <0x0>;
>>> +			#address-cells = <1>;
>>> +			#size-cells = <0>;
>>> +
>>> +			icssg1_phy2: ethernet-phy at 3 {
>>> +				reg = <3>;
>>> +				tx-internal-delay-ps = <250>;
>>> +				rx-internal-delay-ps = <2000>;
>>> +			};
>>> +		};
>>
>> That looks odd. A mux generally has > 1 mdio bus. Otherwise its not
>> really a mux.
>>
> 
> We are disabling node `mdio-mux-1` which has the `cpsw3g_mdio` bus and
> then adding a new node `mdio-mux-2` which has the `icssg1_mdio` bus. The
> mux can actually have two different mdio buses. The patch actually
> disables the mux1 node and creates a new node for icssg1_mdio bus so
> that cpsw3g mdio bus is disabled properly.
> 
> We can modify the existing `mdio-mux-1` as well (added the code below)
> instead of disabling mux1 and creating mux2 node.
> 
> &mdio_mux_1 {
> 	mdio-parent-bus = <&icssg1_mdio>;
> 	#address-cells = <1>;
> 	#size-cells = <0>;
> 
> 	mdio at 0 {
> 		reg = <0x0>;
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		icssg1_phy2: ethernet-phy at 3 {
> 			reg = <3>;
> 			tx-internal-delay-ps = <250>;
> 			rx-internal-delay-ps = <2000>;
> 		};
> 	};
> };
> 
> Let me know what do you think. Is the approach in the patch correct or
> should I modify existing mux node only?
> 

Can you please let me know which approach should I follow here?

>> And this mux hardware exists all the time right? So it should be in
>> the .dtsi file.
>>
> 
> Agreed. But the mdio-mux-1 node was added in k3-am642-evm.dts by the
> commit 985204ecae1c37d55372874ff9146231d28fccc6. I did the same with
> mdio-mux-2 node.
> 
>> 	Andrew
> 

-- 
Thanks and Regards,
Danish


From krzysztof.kozlowski at linaro.org  Mon Dec 11 02:03:10 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 11:03:10 +0100
Subject: [PATCH V4 1/3] dt-bindings: Add optional gpio property to uartps
 node to support rs485
In-Reply-To: <20231211091159.58564-2-manikanta.guntupalli@amd.com>
References: <20231211091159.58564-1-manikanta.guntupalli@amd.com>
 <20231211091159.58564-2-manikanta.guntupalli@amd.com>
Message-ID: <100af9d8-e62d-4488-8138-fd2004454d11@linaro.org>

On 11/12/2023 10:11, Manikanta Guntupalli wrote:
> Add optional gpio property to uartps node and reference to rs485.yaml

...

diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
> index e35ad1109efc..d5dd4e92d1fb 100644
> --- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
> @@ -46,6 +46,10 @@ properties:
>    power-domains:
>      maxItems: 1
>  
> +  rts-gpios:
> +    description: Optional GPIO to control transmit/receive.
> +    maxItems: 1

Why do you exactly need it here? It's already allowed, isn't it?


Best regards,
Krzysztof



From andre.draszik at linaro.org  Mon Dec 11 02:04:29 2023
From: andre.draszik at linaro.org (=?ISO-8859-1?Q?Andr=E9?= Draszik)
Date: Mon, 11 Dec 2023 10:04:29 +0000
Subject: [PATCH v6 12/20] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <20231209233106.147416-13-peter.griffin@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
	 <20231209233106.147416-13-peter.griffin@linaro.org>
Message-ID: <0c8532d2bcb6ad5a583e8f716cc88cd5cbae1356.camel@linaro.org>

On Sat, 2023-12-09 at 23:30 +0000, Peter Griffin wrote:
> cmu_top is the top level clock management unit which contains PLLs, muxes,
> dividers and gates that feed the other clock management units.
> 
> cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> APM module.
> 
> Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> Tested-by: Will McVicker <willmcvicker at google.com>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Reviewed-by: Andr? Draszik <andre.draszik at linaro.org>

Cheers,
Andr?



From johan at kernel.org  Mon Dec 11 02:11:29 2023
From: johan at kernel.org (Johan Hovold)
Date: Mon, 11 Dec 2023 11:11:29 +0100
Subject: [PATCH v2] iommu/arm-smmu-qcom: Add missing GMU entry to match
 table
In-Reply-To: <20231210180655.75542-1-robdclark@gmail.com>
References: <20231210180655.75542-1-robdclark@gmail.com>
Message-ID: <ZXbgUeuf0-dYBOYV@hovoldconsulting.com>

On Sun, Dec 10, 2023 at 10:06:53AM -0800, Rob Clark wrote:
> From: Rob Clark <robdclark at chromium.org>
> 
> In some cases the firmware expects cbndx 1 to be assigned to the GMU,
> so we also want the default domain for the GMU to be an identy domain.
> This way it does not get a context bank assigned.  Without this, both
> of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
> allocating and configuring a context bank.  So GMU ends up attached to
> both cbndx 1 and later cbndx 2.  This arrangement seemingly confounds
> and surprises the firmware if the GPU later triggers a translation
> fault, resulting (on sc8280xp / lenovo x13s, at least) in the SMMU
> getting wedged and the GPU stuck without memory access.
> 
> Cc: stable at vger.kernel.org
> Signed-off-by: Rob Clark <robdclark at chromium.org>

Tested-by: Johan Hovold <johan+linaro at kernel.org>


From james.clark at arm.com  Mon Dec 11 02:12:35 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 10:12:35 +0000
Subject: [PATCH V3 04/10] coresight: replicator: Move ACPI support from
 AMBA driver to platform driver
In-Reply-To: <862afccb-e9c5-4fcb-abdf-45a5eb9aa6d8@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
 <20231208053939.42901-5-anshuman.khandual@arm.com>
 <862afccb-e9c5-4fcb-abdf-45a5eb9aa6d8@arm.com>
Message-ID: <6c3d9c5c-8185-bcdf-2897-0db13c00a843@arm.com>



On 11/12/2023 07:51, Anshuman Khandual wrote:
> 
> 
> On 12/8/23 11:09, Anshuman Khandual wrote:
>> Add support for the dynamic replicator device in the platform driver, which
>> can then be used on ACPI based platforms. This change would now allow
>> runtime power management for repliacator devices on ACPI based systems.
>>
>> The driver would try to enable the APB clock if available. Also, rename the
>> code to reflect the fact that it now handles both static and dynamic
>> replicators.
>>
>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Cc: Mike Leach <mike.leach at linaro.org>
>> Cc: James Clark <james.clark at arm.com>
>> Cc: linux-acpi at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: coresight at lists.linaro.org
>> Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
>> Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>> Changes in V3:
>>
>> - Added commnets for 'drvdata->pclk'
>> - Used coresight_init_driver()/coresight_remove_driver() helpers instead
>> - Dropped pm_runtime_put() from replicator_probe()
>> - Added pm_runtime_put() on success path in dynamic_replicator_probe()
>> - Added pm_runtime_put() on success/error paths in
>>   replicator_platform_probe()
>>
>>  drivers/acpi/arm64/amba.c                     |  1 -
>>  .../coresight/coresight-replicator.c          | 81 ++++++++++---------
>>  2 files changed, 42 insertions(+), 40 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
>> index 171b5c2c7edd..270f4e3819a2 100644
>> --- a/drivers/acpi/arm64/amba.c
>> +++ b/drivers/acpi/arm64/amba.c
>> @@ -27,7 +27,6 @@ static const struct acpi_device_id amba_id_list[] = {
>>  	{"ARMHC503", 0}, /* ARM CoreSight Debug */
>>  	{"ARMHC979", 0}, /* ARM CoreSight TPIU */
>>  	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
>> -	{"ARMHC98D", 0}, /* ARM CoreSight Dynamic Replicator */
>>  	{"ARMHC9CA", 0}, /* ARM CoreSight CATU */
>>  	{"ARMHC9FF", 0}, /* ARM CoreSight Dynamic Funnel */
>>  	{"", 0},
>> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
>> index b6be73034996..125b256cb8db 100644
>> --- a/drivers/hwtracing/coresight/coresight-replicator.c
>> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
>> @@ -31,6 +31,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>>   * @base:	memory mapped base address for this component. Also indicates
>>   *		whether this one is programmable or not.
>>   * @atclk:	optional clock for the core parts of the replicator.
>> + * @pclk:	APB clock if present, otherwise NULL
>>   * @csdev:	component vitals needed by the framework
>>   * @spinlock:	serialize enable/disable operations.
>>   * @check_idfilter_val: check if the context is lost upon clock removal.
>> @@ -38,6 +39,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>>  struct replicator_drvdata {
>>  	void __iomem		*base;
>>  	struct clk		*atclk;
>> +	struct clk		*pclk;
>>  	struct coresight_device	*csdev;
>>  	spinlock_t		spinlock;
>>  	bool			check_idfilter_val;
>> @@ -243,6 +245,10 @@ static int replicator_probe(struct device *dev, struct resource *res)
>>  			return ret;
>>  	}
>>  
>> +	drvdata->pclk = coresight_get_enable_apb_pclk(dev);
>> +	if (IS_ERR(drvdata->pclk))
>> +		return -ENODEV;
>> +
>>  	/*
>>  	 * Map the device base for dynamic-replicator, which has been
>>  	 * validated by AMBA core
>> @@ -285,7 +291,6 @@ static int replicator_probe(struct device *dev, struct resource *res)
>>  	}
>>  
>>  	replicator_reset(drvdata);
>> -	pm_runtime_put(dev);
>>  
>>  out_disable_clk:
>>  	if (ret && !IS_ERR_OR_NULL(drvdata->atclk))
>> @@ -301,29 +306,31 @@ static int replicator_remove(struct device *dev)
>>  	return 0;
>>  }
>>  
>> -static int static_replicator_probe(struct platform_device *pdev)
>> +static int replicator_platform_probe(struct platform_device *pdev)
>>  {
>> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>  	int ret;
>>  
>>  	pm_runtime_get_noresume(&pdev->dev);
>>  	pm_runtime_set_active(&pdev->dev);
>>  	pm_runtime_enable(&pdev->dev);
>>  
>> -	/* Static replicators do not have programming base */
>> -	ret = replicator_probe(&pdev->dev, NULL);
>> -
>> -	if (ret) {
>> -		pm_runtime_put_noidle(&pdev->dev);
>> -		pm_runtime_disable(&pdev->dev);
>> -	}
>> +	ret = replicator_probe(&pdev->dev, res);
>> +	pm_runtime_put(&pdev->dev);
> 
> I believe pm_runtime_disable() would still be needed on the error path. Otherwise
> pm_runtime_enable() will remain unbalanced on this error path when the replicator
> module could not be loaded.
> 
> --- a/drivers/hwtracing/coresight/coresight-replicator.c
> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
> @@ -317,6 +317,8 @@ static int replicator_platform_probe(struct platform_device *pdev)
>  
>         ret = replicator_probe(&pdev->dev, res);
>         pm_runtime_put(&pdev->dev);
> +       if (ret)
> +               pm_runtime_disable(&pdev->dev);
>  
>         return ret;
>  }
> 
> Similar constructs in this error path are also required in all other drivers (except
> cpu debug) as well.

Would that not need to be done as a fixes commit first with more detail
about the issue if that's true? Maybe simulate the error and paste any
error logs. For example etm4 already has this:

  	pm_runtime_get_noresume(&pdev->dev);
	pm_runtime_set_active(&pdev->dev);
	pm_runtime_enable(&pdev->dev);

	ret = etm4_probe(&pdev->dev);

	pm_runtime_put(&pdev->dev);

I'm wondering if the disable is already covered by the platform code if
the probe fails so no change is required?

	if (drv->probe) {
		ret = drv->probe(dev);
		if (ret)
			dev_pm_domain_detach(_dev, true);
	}


From sherry.sun at nxp.com  Mon Dec 11 02:18:11 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Mon, 11 Dec 2023 10:18:11 +0000
Subject: [PATCH 1/4] PCI: imx6: Add pci host wakeup support on imx
 platforms.
In-Reply-To: <0cd40cf388e70b101b3857220fd7a74cf75cfa81.camel@pengutronix.de>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
	 <20231208091355.1417292-2-sherry.sun@nxp.com>
 <0cd40cf388e70b101b3857220fd7a74cf75cfa81.camel@pengutronix.de>
Message-ID: <AS8PR04MB8404B2D7CBC562AA0ED2BFD4928FA@AS8PR04MB8404.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Lucas Stach <l.stach at pengutronix.de>
> Sent: 2023?12?8? 18:16
> To: Sherry Sun <sherry.sun at nxp.com>; Hongxing Zhu
> <hongxing.zhu at nxp.com>; lpieralisi at kernel.org; kw at linux.com;
> robh at kernel.org; bhelgaas at google.com; krzysztof.kozlowski+dt at linaro.org;
> conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de;
> kernel at pengutronix.de; festevam at gmail.com
> Cc: dl-linux-imx <linux-imx at nxp.com>; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH 1/4] PCI: imx6: Add pci host wakeup support on imx
> platforms.
> 
> Am Freitag, dem 08.12.2023 um 17:13 +0800 schrieb Sherry Sun:
> > Add pci host wakeup feature for imx platforms.
> > Example of configuring the corresponding dts property under the PCI
> > node:
> > host-wake-gpio = <&gpio5 21 GPIO_ACTIVE_LOW>;
> >
> > Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
> > Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
> > ---
> >  drivers/pci/controller/dwc/pci-imx6.c | 69
> > +++++++++++++++++++++++++++
> >  1 file changed, 69 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 74703362aeec..050c9140f4a3 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -72,6 +72,7 @@ struct imx6_pcie_drvdata {  struct imx6_pcie {
> >  	struct dw_pcie		*pci;
> >  	int			reset_gpio;
> > +	int			host_wake_irq;
> >  	bool			gpio_active_high;
> >  	bool			link_is_up;
> >  	struct clk		*pcie_bus;
> > @@ -1237,11 +1238,46 @@ static int imx6_pcie_resume_noirq(struct
> device *dev)
> >  	return 0;
> >  }
> >
> > +static int imx6_pcie_suspend(struct device *dev) {
> > +	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> > +
> > +	if (imx6_pcie->host_wake_irq >= 0)
> > +		enable_irq_wake(imx6_pcie->host_wake_irq);
> > +
> > +	return 0;
> > +}
> > +
> > +static int imx6_pcie_resume(struct device *dev) {
> > +	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
> > +
> > +	if (imx6_pcie->host_wake_irq >= 0)
> > +		disable_irq_wake(imx6_pcie->host_wake_irq);
> > +
> > +	return 0;
> > +}
> > +
> >  static const struct dev_pm_ops imx6_pcie_pm_ops = {
> >  	NOIRQ_SYSTEM_SLEEP_PM_OPS(imx6_pcie_suspend_noirq,
> >  				  imx6_pcie_resume_noirq)
> > +	SYSTEM_SLEEP_PM_OPS(imx6_pcie_suspend, imx6_pcie_resume)
> >  };
> >
> > +irqreturn_t host_wake_irq_handler(int irq, void *priv) {
> > +	struct imx6_pcie *imx6_pcie = priv;
> > +	struct device *dev = imx6_pcie->pci->dev;
> > +
> > +	dev_dbg(dev, "%s: host wakeup by pcie", __func__);
> > +
> Not sure how much value this debug print carries. If you want to keep it,
> drop the __func__. There is no other place in this driver handling the wakeup,
> so the function name in the print is pure noise.

Ok, will remove the debug print info here.

> 
> > +	/* Notify PM core we are wakeup source */
> > +	pm_wakeup_event(dev, 0);
> > +	pm_system_wakeup();
> > +
> > +	return IRQ_HANDLED;
> > +}
> > +
> >  static int imx6_pcie_probe(struct platform_device *pdev)  {
> >  	struct device *dev = &pdev->dev;
> > @@ -1250,6 +1286,7 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  	struct device_node *np;
> >  	struct resource *dbi_base;
> >  	struct device_node *node = dev->of_node;
> > +	struct gpio_desc *host_wake_gpio;
> >  	int ret;
> >  	u16 val;
> >
> > @@ -1457,6 +1494,32 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> >  			val |= PCI_MSI_FLAGS_ENABLE;
> >  			dw_pcie_writew_dbi(pci, offset + PCI_MSI_FLAGS,
> val);
> >  		}
> > +
> > +		/* host wakeup support */
> > +		imx6_pcie->host_wake_irq = -1;
> > +		host_wake_gpio = devm_gpiod_get_optional(dev, "host-
> wake", GPIOD_IN);
> > +		if (IS_ERR(host_wake_gpio))
> > +			return PTR_ERR(host_wake_gpio);
> > +
> > +		if (host_wake_gpio != NULL) {
> > +			imx6_pcie->host_wake_irq =
> gpiod_to_irq(host_wake_gpio);
> > +			ret = devm_request_threaded_irq(dev, imx6_pcie-
> >host_wake_irq, NULL,
> > +
> 	host_wake_irq_handler,
> > +							IRQF_ONESHOT |
> IRQF_TRIGGER_FALLING,
> > +							"host_wake",
> imx6_pcie);
> > +			if (ret) {
> > +				dev_err(dev, "Failed to request
> host_wake_irq %d (%d)\n",
> > +					imx6_pcie->host_wake_irq, ret);
> > +				imx6_pcie->host_wake_irq = -1;
> 
> What's the point of resetting host_wake_irq to -1 in those error paths?
> Nobody is going to access this member anymore after the error. Just drop
> this.
> 
> You could simplify all those error paths to if (err)
>     return dev_err_probe(...);

Sounds reasonable, I will remove the host_wake_irq resetting here and use dev_err_probe() instead, thanks!

Best Regards
Sherry

From quan at os.amperecomputing.com  Mon Dec 11 02:22:15 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Mon, 11 Dec 2023 17:22:15 +0700
Subject: [PATCH v4 0/2] i2c: aspeed: Late ack Tx done irqs and handle coalesced start with stop conditions
Message-ID: <20231211102217.2436294-1-quan@os.amperecomputing.com>

This series consists of two patches to handle the below issues observed
when testing with slave mode:
  + The coalesced stop condition with the start conditions
  + Early ack'ed of Tx done (ACK and NAK) causing "Unexpected Ack on
  read request".

This series was verified with ast2500 and ast2600.

The prior discussion could be found at:
https://lore.kernel.org/all/20231208033142.1673232-1-quan at os.amperecomputing.com/

v4:
  + Switch to use define macro instead of variable             [Andrew]
  + Make the early ack conditionally to avoid unnecessary
writel()/readl()                                                 [Quan]
  + Add an extra empty line before the comment in patch 1      [Andrew]

v3:
  + Fix the unconditional write when ack the irqs              [Andrew]
  + Handle the coalesced stop condition with the
start conditions                                               [Andrew]
  + Refactor the code to enhance code readability                [Quan]
  + Revised commit message                                       [Quan]

v2:
  + Split these patches to separate series                       [Joel]
  + Added the Fixes lines                                        [Joel]
  + Fixed multiline comment                                      [Joel]
  + Refactor irq clearing code                          [Joel, Guenter]
  + Revised commit message                                 [Joel, Quan]

v1:
  + These patches are first introduced from this disscusstion
https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/

Quan Nguyen (2):
  i2c: aspeed: Handle the coalesced stop conditions with the start
    conditions.
  i2c: aspeed: Acknowledge Tx done with and without ACK irq late

 drivers/i2c/busses/i2c-aspeed.c | 75 +++++++++++++++++++++++----------
 1 file changed, 52 insertions(+), 23 deletions(-)

-- 
2.35.1



From quan at os.amperecomputing.com  Mon Dec 11 02:22:16 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Mon, 11 Dec 2023 17:22:16 +0700
Subject: [PATCH v4 1/2] i2c: aspeed: Handle the coalesced stop conditions with the start conditions.
In-Reply-To: <20231211102217.2436294-1-quan@os.amperecomputing.com>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
Message-ID: <20231211102217.2436294-2-quan@os.amperecomputing.com>

Some masters may drive the transfers with low enough latency between
the nak/stop phase of the current command and the start/address phase
of the following command that the interrupts are coalesced by the
time we process them.
Handle the stop conditions before processing SLAVE_MATCH to fix the
complaints that sometimes occur below.

"aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
0x00000086, but was 0x00000084"

Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>
Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
---
v4:
  + Add an extra empty line before the comment                        [Andrew]

Note: I'd like to keep adding Reviewed-by Andrew and Andi for this patch
eventhough there is an extra empty line added before the comment as mentioned
above. Thanks for the review.

v3:
  + Change to handle the coalesced stop condition with the start
conditions                                                            [Andrew]
  + Revised commit message                                              [Quan]

v2:
  + Split to separate series                                            [Joel]
  + Added the Fixes line                                                [Joel]
  + Revised commit message                                              [Quan]

v1:
  + First introduced in
https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/
---
 drivers/i2c/busses/i2c-aspeed.c | 48 ++++++++++++++++++++++-----------
 1 file changed, 32 insertions(+), 16 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index 28e2a5fc4528..5511fd46a65e 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -249,18 +249,46 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 	if (!slave)
 		return 0;
 
-	command = readl(bus->base + ASPEED_I2C_CMD_REG);
+	/*
+	 * Handle stop conditions early, prior to SLAVE_MATCH. Some masters may drive
+	 * transfers with low enough latency between the nak/stop phase of the current
+	 * command and the start/address phase of the following command that the
+	 * interrupts are coalesced by the time we process them.
+	 */
+	if (irq_status & ASPEED_I2CD_INTR_NORMAL_STOP) {
+		irq_handled |= ASPEED_I2CD_INTR_NORMAL_STOP;
+		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
+	}
+
+	if (irq_status & ASPEED_I2CD_INTR_TX_NAK &&
+	    bus->slave_state == ASPEED_I2C_SLAVE_READ_PROCESSED) {
+		irq_handled |= ASPEED_I2CD_INTR_TX_NAK;
+		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
+	}
+
+	/* Propagate any stop conditions to the slave implementation. */
+	if (bus->slave_state == ASPEED_I2C_SLAVE_STOP) {
+		i2c_slave_event(slave, I2C_SLAVE_STOP, &value);
+		bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
+	}
 
-	/* Slave was requested, restart state machine. */
+	/*
+	 * Now that we've dealt with any potentially coalesced stop conditions,
+	 * address any start conditions.
+	 */
 	if (irq_status & ASPEED_I2CD_INTR_SLAVE_MATCH) {
 		irq_handled |= ASPEED_I2CD_INTR_SLAVE_MATCH;
 		bus->slave_state = ASPEED_I2C_SLAVE_START;
 	}
 
-	/* Slave is not currently active, irq was for someone else. */
+	/*
+	 * If the slave has been stopped and not started then slave interrupt
+	 * handling is complete.
+	 */
 	if (bus->slave_state == ASPEED_I2C_SLAVE_INACTIVE)
 		return irq_handled;
 
+	command = readl(bus->base + ASPEED_I2C_CMD_REG);
 	dev_dbg(bus->dev, "slave irq status 0x%08x, cmd 0x%08x\n",
 		irq_status, command);
 
@@ -279,17 +307,6 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 		irq_handled |= ASPEED_I2CD_INTR_RX_DONE;
 	}
 
-	/* Slave was asked to stop. */
-	if (irq_status & ASPEED_I2CD_INTR_NORMAL_STOP) {
-		irq_handled |= ASPEED_I2CD_INTR_NORMAL_STOP;
-		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
-	}
-	if (irq_status & ASPEED_I2CD_INTR_TX_NAK &&
-	    bus->slave_state == ASPEED_I2C_SLAVE_READ_PROCESSED) {
-		irq_handled |= ASPEED_I2CD_INTR_TX_NAK;
-		bus->slave_state = ASPEED_I2C_SLAVE_STOP;
-	}
-
 	switch (bus->slave_state) {
 	case ASPEED_I2C_SLAVE_READ_REQUESTED:
 		if (unlikely(irq_status & ASPEED_I2CD_INTR_TX_ACK))
@@ -324,8 +341,7 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
 		i2c_slave_event(slave, I2C_SLAVE_WRITE_RECEIVED, &value);
 		break;
 	case ASPEED_I2C_SLAVE_STOP:
-		i2c_slave_event(slave, I2C_SLAVE_STOP, &value);
-		bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
+		/* Stop event handling is done early. Unreachable. */
 		break;
 	case ASPEED_I2C_SLAVE_START:
 		/* Slave was just started. Waiting for the next event. */;
-- 
2.35.1



From quan at os.amperecomputing.com  Mon Dec 11 02:22:17 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Mon, 11 Dec 2023 17:22:17 +0700
Subject: [PATCH v4 2/2] i2c: aspeed: Acknowledge Tx done with and without ACK irq late
In-Reply-To: <20231211102217.2436294-1-quan@os.amperecomputing.com>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
Message-ID: <20231211102217.2436294-3-quan@os.amperecomputing.com>

Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
interrupt handler") acknowledges most interrupts early before the slave
irq handler is executed, except for the "Receive Done Interrupt status"
which is acknowledged late in the interrupt.
However, it has been observed that the early acknowledgment of "Transmit
Done Interrupt Status" (with ACK or NACK) often causes the interrupt to
be raised in READ REQUEST state, that shows the
"Unexpected ACK on read request." complaint messages.

Assuming that the "Transmit Done" interrupt should only be acknowledged
once it is truly processed, this commit fixes that issue by acknowledging
interrupts for both ACK and NACK cases late in the interrupt handler.

Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
---
v4:
  + Switch to use define macro instead of variable             [Andrew]
  + Make the early ack conditionally to avoid unnecessary
writel()/readl()                                                 [Quan]

v3:
  + Fix the unconditinal write when ack the irqs               [Andrew]
  + Refactor the code to enhance code readability                [Quan]
  + Fix grammar in commit message                                [Quan]

v2:
  + Split to separate series                                     [Joel]
  + Added the Fixes line                                         [Joel]
  + Fixed multiline comment                                      [Joel]
  + Refactor irq clearing code                          [Joel, Guenter]
  + Revised commit message                                       [Joel]
  + Revised commit message                                       [Quan]
  + About a note to remind why the readl() should immediately follow the
writel() to fix the race condition when clearing irq status from commit
c926c87b8e36 ("i2c: aspeed: Avoid i2c interrupt status clear race
condition"), I think it looks straight forward in this patch and decided
not to add that note.                                            [Joel]

v1:
  + First introduced in
https://lore.kernel.org/all/20210519074934.20712-1-quan at os.amperecomputing.com/
---
 drivers/i2c/busses/i2c-aspeed.c | 27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index 5511fd46a65e..0f67218cf04a 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -93,6 +93,10 @@
 		 ASPEED_I2CD_INTR_RX_DONE |				       \
 		 ASPEED_I2CD_INTR_TX_NAK |				       \
 		 ASPEED_I2CD_INTR_TX_ACK)
+#define ASPEED_I2CD_INTR_ACK_RX_TX					       \
+		(ASPEED_I2CD_INTR_RX_DONE |				       \
+		 ASPEED_I2CD_INTR_TX_ACK |				       \
+		 ASPEED_I2CD_INTR_TX_NAK)
 
 /* 0x14 : I2CD Command/Status Register   */
 #define ASPEED_I2CD_SCL_LINE_STS			BIT(18)
@@ -622,10 +626,19 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
 
 	spin_lock(&bus->lock);
 	irq_received = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
-	/* Ack all interrupts except for Rx done */
-	writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
-	       bus->base + ASPEED_I2C_INTR_STS_REG);
-	readl(bus->base + ASPEED_I2C_INTR_STS_REG);
+
+	/*
+	 * Early acking of INTR_RX_DONE and INTR_TX_[ACK|NAK] would indicate HW to
+	 * start receiving or sending new data, and this may cause a race condition
+	 * as the irq handler has not yet handled these irqs but is being acked.
+	 * Let's ack them late at the end of the irq handler when those are truly processed.
+	 */
+	if (irq_received & ~ASPEED_I2CD_INTR_ACK_RX_TX) {
+		writel(irq_received & ~ASPEED_I2CD_INTR_ACK_RX_TX,
+		       bus->base + ASPEED_I2C_INTR_STS_REG);
+		readl(bus->base + ASPEED_I2C_INTR_STS_REG);
+	}
+
 	irq_received &= ASPEED_I2CD_INTR_RECV_MASK;
 	irq_remaining = irq_received;
 
@@ -668,12 +681,12 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
 			"irq handled != irq. expected 0x%08x, but was 0x%08x\n",
 			irq_received, irq_handled);
 
-	/* Ack Rx done */
-	if (irq_received & ASPEED_I2CD_INTR_RX_DONE) {
-		writel(ASPEED_I2CD_INTR_RX_DONE,
+	if (irq_received & ASPEED_I2CD_INTR_ACK_RX_TX) {
+		writel(irq_received & ASPEED_I2CD_INTR_ACK_RX_TX,
 		       bus->base + ASPEED_I2C_INTR_STS_REG);
 		readl(bus->base + ASPEED_I2C_INTR_STS_REG);
 	}
+
 	spin_unlock(&bus->lock);
 	return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
 }
-- 
2.35.1



From peter.griffin at linaro.org  Mon Dec 11 02:22:51 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 10:22:51 +0000
Subject: [PATCH v6 14/20] watchdog: s3c2410_wdt: Add support for WTCON
 register DBGACK_MASK bit
In-Reply-To: <9ffd229e-cf1b-4508-ba74-d5a000c54582@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-15-peter.griffin@linaro.org> <9ffd229e-cf1b-4508-ba74-d5a000c54582@linaro.org>
Message-ID: <CADrjBPrWQ9EUDDqZ6Nxr-z93rzZf0sJVVFVZk58s1ErmkUJpMw@mail.gmail.com>

Hi folks,

On Sun, 10 Dec 2023 at 14:24, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 10/12/2023 00:31, Peter Griffin wrote:
> > The WDT uses the CPU core signal DBGACK to determine whether the SoC
> > is running in debug mode or not. If the DBGACK signal is asserted and
> > DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
> > (disabled).
> >
> > Presence of the DBGACK_MASK bit is determined by adding a new
> > QUIRK_HAS_DBGACK_BIT quirk. Also update to use BIT macro to avoid
> > checkpatch --strict warnings.
> >
> > Tested-by: Will McVicker <willmcvicker at google.com>
> > Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
>
> Guenter, Wim,
>
> The watchdog patches are kind of independent, except that bindings has
> conflicting re-organization which I took via my Samsung SoC tree. If it
> is fine with you, please provide acks or review and I will take the
> watchdog changes.
>

Just to add, without the Watchdog gs101 changes the system will reset
after ~60 seconds, as the bootloader is left running by the
bootloader. So it would be nice to get patches in as well if possible.

regards,

Peter.


From peter.griffin at linaro.org  Mon Dec 11 02:26:39 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 10:26:39 +0000
Subject: [PATCH v6 16/20] watchdog: s3c2410_wdt: Add support for Google
 gs101 SoC
In-Reply-To: <25533a7f-326f-48d1-a8a6-e5798bdca4b4@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-17-peter.griffin@linaro.org> <25533a7f-326f-48d1-a8a6-e5798bdca4b4@linaro.org>
Message-ID: <CADrjBPrg51Fkkme71yLeFc06ROgAjcchXGoX7Uxrmin-+yBayQ@mail.gmail.com>

Hi Krzysztof,

Thanks for the review.

On Sun, 10 Dec 2023 at 14:26, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 10/12/2023 00:31, Peter Griffin wrote:
> > This patch adds the compatibles and drvdata for the Google
> > gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.
> >
> > Similar to Exynos850 it has two watchdog instances, one for
> > each cluster and has some control bits in PMU registers.
> >
>
>
> > +
> >  static const struct of_device_id s3c2410_wdt_match[] = {
> >       { .compatible = "samsung,s3c2410-wdt",
> >         .data = &drv_data_s3c2410 },
> > @@ -285,6 +318,8 @@ static const struct of_device_id s3c2410_wdt_match[] = {
> >         .data = &drv_data_exynos850_cl0 },
> >       { .compatible = "samsung,exynosautov9-wdt",
> >         .data = &drv_data_exynosautov9_cl0 },
> > +     { .compatible = "google,gs101-wdt",
> > +       .data = &drv_data_gs101_cl0 },
>
> Keep some alphabetical order by compatible, so this should be probably
> the first entry in the table.
>
> Same for s3c2410_wdt_variant structures.

Will fix in v7.

Thanks,

Peter


From liviu.dudau at arm.com  Mon Dec 11 02:27:06 2023
From: liviu.dudau at arm.com (Liviu Dudau)
Date: Mon, 11 Dec 2023 10:27:06 +0000
Subject: [PATCH] arm64: dts: juno: align thermal zone names with bindings
In-Reply-To: <20231209171612.250868-1-krzysztof.kozlowski@linaro.org>
References: <20231209171612.250868-1-krzysztof.kozlowski@linaro.org>
Message-ID: <ZXbj-jRJcpzam0wG@e110455-lin.cambridge.arm.com>

On Sat, Dec 09, 2023 at 06:16:12PM +0100, Krzysztof Kozlowski wrote:
> Thermal bindings require thermal zone node names to match
> certain patterns:
> 
>   juno.dtb: thermal-zones: 'big-cluster', 'gpu0', 'gpu1', 'little-cluster', 'pmic', 'soc'
>     do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Acked-by: Liviu Dudau <liviu.dudau at arm.com>

Thanks for fixing this!

Best regards,
Liviu

> ---
>  arch/arm64/boot/dts/arm/juno-base.dtsi | 12 ++++++------
>  arch/arm64/boot/dts/arm/juno-scmi.dtsi | 12 ++++++------
>  2 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index 8b4d280b1e7e..b897f5542c0a 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -747,7 +747,7 @@ scpi_sensors0: sensors {
>  	};
>  
>  	thermal-zones {
> -		pmic {
> +		pmic-thermal {
>  			polling-delay = <1000>;
>  			polling-delay-passive = <100>;
>  			thermal-sensors = <&scpi_sensors0 0>;
> @@ -760,7 +760,7 @@ pmic_crit0: trip0 {
>  			};
>  		};
>  
> -		soc {
> +		soc-thermal {
>  			polling-delay = <1000>;
>  			polling-delay-passive = <100>;
>  			thermal-sensors = <&scpi_sensors0 3>;
> @@ -773,28 +773,28 @@ soc_crit0: trip0 {
>  			};
>  		};
>  
> -		big_cluster_thermal_zone: big-cluster {
> +		big_cluster_thermal_zone: big-cluster-thermal {
>  			polling-delay = <1000>;
>  			polling-delay-passive = <100>;
>  			thermal-sensors = <&scpi_sensors0 21>;
>  			status = "disabled";
>  		};
>  
> -		little_cluster_thermal_zone: little-cluster {
> +		little_cluster_thermal_zone: little-cluster-thermal {
>  			polling-delay = <1000>;
>  			polling-delay-passive = <100>;
>  			thermal-sensors = <&scpi_sensors0 22>;
>  			status = "disabled";
>  		};
>  
> -		gpu0_thermal_zone: gpu0 {
> +		gpu0_thermal_zone: gpu0-thermal {
>  			polling-delay = <1000>;
>  			polling-delay-passive = <100>;
>  			thermal-sensors = <&scpi_sensors0 23>;
>  			status = "disabled";
>  		};
>  
> -		gpu1_thermal_zone: gpu1 {
> +		gpu1_thermal_zone: gpu1-thermal {
>  			polling-delay = <1000>;
>  			polling-delay-passive = <100>;
>  			thermal-sensors = <&scpi_sensors0 24>;
> diff --git a/arch/arm64/boot/dts/arm/juno-scmi.dtsi b/arch/arm64/boot/dts/arm/juno-scmi.dtsi
> index ec85cd2c733c..31929e2377d8 100644
> --- a/arch/arm64/boot/dts/arm/juno-scmi.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-scmi.dtsi
> @@ -76,27 +76,27 @@ scmi_sensors0: protocol at 15 {
>  	};
>  
>  	thermal-zones {
> -		pmic {
> +		pmic-thermal {
>  			thermal-sensors = <&scmi_sensors0 0>;
>  		};
>  
> -		soc {
> +		soc-thermal {
>  			thermal-sensors = <&scmi_sensors0 3>;
>  		};
>  
> -		big-cluster {
> +		big-cluster-thermal {
>  			thermal-sensors = <&scmi_sensors0 21>;
>  		};
>  
> -		little-cluster {
> +		little-cluster-thermal {
>  			thermal-sensors = <&scmi_sensors0 22>;
>  		};
>  
> -		gpu0 {
> +		gpu0-thermal {
>  			thermal-sensors = <&scmi_sensors0 23>;
>  		};
>  
> -		gpu1 {
> +		gpu1-thermal {
>  			thermal-sensors = <&scmi_sensors0 24>;
>  		};
>  	};
> -- 
> 2.34.1
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?


From konrad.dybcio at linaro.org  Mon Dec 11 02:32:51 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Mon, 11 Dec 2023 11:32:51 +0100
Subject: [PATCH v3 7/8] arm64: dts: qcom: ipq5332: add support for the
 NSSCC
In-Reply-To: <20231211-ipq5332-nsscc-v3-7-ad13bef9b137@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
 <20231211-ipq5332-nsscc-v3-7-ad13bef9b137@quicinc.com>
Message-ID: <c4034715-53a5-468e-914a-3f19d0618c42@linaro.org>

On 11.12.2023 04:37, Kathiravan Thirumoorthy wrote:
> Describe the NSS clock controller node and it's relevant external
> clocks.
> 
> Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/ipq5332.dtsi | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
> index 42e2e48b2bc3..a1504f6c40c1 100644
> --- a/arch/arm64/boot/dts/qcom/ipq5332.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
> @@ -15,6 +15,18 @@ / {
>  	#size-cells = <2>;
>  
>  	clocks {
> +		cmn_pll_nss_200m_clk: cmn-pll-nss-200m-clk {
> +			compatible = "fixed-clock";
> +			clock-frequency = <200000000>;
> +			#clock-cells = <0>;
> +		};
> +
> +		cmn_pll_nss_300m_clk: cmn-pll-nss-300m-clk {
> +			compatible = "fixed-clock";
> +			clock-frequency = <300000000>;
> +			#clock-cells = <0>;
> +		};
> +
>  		sleep_clk: sleep-clk {
>  			compatible = "fixed-clock";
>  			#clock-cells = <0>;
> @@ -473,6 +485,22 @@ frame at b128000 {
>  				status = "disabled";
>  			};
>  		};
> +
> +		nsscc: clock-controller at 39b00000{
Missing space between the opening curly brace

> +			compatible = "qcom,ipq5332-nsscc";
> +			reg = <0x39b00000 0x80000>;
the regmap_config in the clk driver has .max_register = 0x800, is this
correct?


Konrad


From krzysztof.kozlowski at linaro.org  Mon Dec 11 02:38:41 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 11 Dec 2023 11:38:41 +0100
Subject: [PATCH 2/2] arm64: dts: amlogic: minor whitespace cleanup around
 '='
In-Reply-To: <449d675f-e98c-4924-ab81-14a139081a97@linaro.org>
References: <20231124094739.58163-1-krzysztof.kozlowski@linaro.org>
 <20231124094739.58163-2-krzysztof.kozlowski@linaro.org>
 <4150bf8e-a48d-4d16-902f-a95f6489c6f5@linaro.org>
 <449d675f-e98c-4924-ab81-14a139081a97@linaro.org>
Message-ID: <e4a163c0-5f4f-4c0e-a597-1ee06a84f3cc@linaro.org>

On 11/12/2023 10:10, Neil Armstrong wrote:
> Hi,
> 
> On 24/11/2023 10:49, Krzysztof Kozlowski wrote:
>> On 24/11/2023 10:47, Krzysztof Kozlowski wrote:
>>> The DTS code coding style expects exactly one space before and after '='
>>> sign.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>>> ---
>>
>> Please ignore, that's duplicated of my previous send.
> 
> I don't see a previous send, so I'm confused.
> I can apply this patch if you're ok.

This was the original submission, which you applied (Thank you):
https://lore.kernel.org/all/20231124094700.58071-1-krzysztof.kozlowski at linaro.org/

Both patches here can be ignored (applied through different series).

Best regards,
Krzysztof



From hverkuil-cisco at xs4all.nl  Mon Dec 11 02:45:43 2023
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Mon, 11 Dec 2023 11:45:43 +0100
Subject: [PATCH v3,02/21] v4l2: handle secure memory flags in queue setup
In-Reply-To: <20231206081538.17056-3-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
 <20231206081538.17056-3-yunfei.dong@mediatek.com>
Message-ID: <797a2cbd-ab84-47ec-99b0-23c392f343e1@xs4all.nl>

Hi Yunfei, Jeffrey,

Some comments below:

On 06/12/2023 09:15, Yunfei Dong wrote:
> From: Jeffrey Kardatzke <jkardatzke at google.com>
> 
> Validates the secure memory flags when setting up a queue and ensures
> the queue has the proper capability.
> 
> Signed-off-by: Jeffrey Kardatzke <jkardatzke at google.com>
> Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
> ---
>  .../media/common/videobuf2/videobuf2-core.c   | 23 +++++++++++++
>  .../media/common/videobuf2/videobuf2-v4l2.c   | 34 +++++++++++++------
>  2 files changed, 46 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
> index 8c1df829745b..09dc030484be 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -813,6 +813,15 @@ static bool verify_coherency_flags(struct vb2_queue *q, bool non_coherent_mem)
>  	return true;
>  }
>  
> +static bool verify_secure_mem_flags(struct vb2_queue *q, bool secure_mem)
> +{
> +	if (secure_mem != q->secure_mem) {
> +		dprintk(q, 1, "secure memory model mismatch\n");
> +		return false;
> +	}
> +	return true;
> +}
> +
>  int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
>  		     unsigned int flags, unsigned int *count)
>  {
> @@ -820,6 +829,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
>  	unsigned int q_num_bufs = vb2_get_num_buffers(q);
>  	unsigned plane_sizes[VB2_MAX_PLANES] = { };
>  	bool non_coherent_mem = flags & V4L2_MEMORY_FLAG_NON_COHERENT;
> +	bool secure_mem = flags & V4L2_MEMORY_FLAG_SECURE;
>  	unsigned int i;
>  	int ret = 0;
>  
> @@ -836,6 +846,8 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
>  	if (*count == 0 || q_num_bufs != 0 ||
>  	    (q->memory != VB2_MEMORY_UNKNOWN && q->memory != memory) ||
>  	    !verify_coherency_flags(q, non_coherent_mem)) {
> +		bool no_previous_buffers = !q->num_buffers;
> +
>  		/*
>  		 * We already have buffers allocated, so first check if they
>  		 * are not in use and can be freed.
> @@ -854,6 +866,12 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
>  		__vb2_queue_free(q, q_num_bufs);
>  		mutex_unlock(&q->mmap_lock);
>  
> +		/*
> +		 * Do not allow switching secure buffer mode.
> +		 */
> +		if (!no_previous_buffers && !verify_secure_mem_flags(q, secure_mem))
> +			return -EINVAL;
> +

Why is this needed? Here VIDIOC_REQBUFS is called either to just delete
all existing buffers (count == 0), or to delete all existing buffers and
allocate new buffers (count > 0).

Since in both cases all existing buffers are deleted, you are free to choose
whatever new secure mode you want.

>  		/*
>  		 * In case of REQBUFS(0) return immediately without calling
>  		 * driver's queue_setup() callback and allocating resources.
> @@ -882,6 +900,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
>  	if (ret)
>  		return ret;
>  	set_queue_coherency(q, non_coherent_mem);
> +	q->secure_mem = secure_mem;
>  
>  	/*
>  	 * Ask the driver how many buffers and planes per buffer it requires.
> @@ -986,6 +1005,7 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
>  	unsigned plane_sizes[VB2_MAX_PLANES] = { };
>  	bool non_coherent_mem = flags & V4L2_MEMORY_FLAG_NON_COHERENT;
>  	unsigned int q_num_bufs = vb2_get_num_buffers(q);
> +	bool secure_mem = flags & V4L2_MEMORY_FLAG_SECURE;
>  	bool no_previous_buffers = !q_num_bufs;
>  	int ret = 0;
>  
> @@ -1015,6 +1035,7 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
>  			return ret;
>  		q->waiting_for_buffers = !q->is_output;
>  		set_queue_coherency(q, non_coherent_mem);
> +		q->secure_mem = secure_mem;
>  	} else {
>  		if (q->memory != memory) {
>  			dprintk(q, 1, "memory model mismatch\n");
> @@ -1022,6 +1043,8 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
>  		}
>  		if (!verify_coherency_flags(q, non_coherent_mem))
>  			return -EINVAL;
> +		if (!verify_secure_mem_flags(q, secure_mem))
> +			return -EINVAL;
>  	}
>  
>  	num_buffers = min(*count, q->max_num_buffers - q_num_bufs);
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 54d572c3b515..0a530830276c 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -686,22 +686,30 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
>  		*caps |= V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS;
>  	if (q->supports_requests)
>  		*caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
> +	if (q->allow_secure_mem && q->io_modes & VB2_DMABUF)
> +		*caps |= V4L2_BUF_CAP_SUPPORTS_SECURE_MEM;
>  }
>  
> -static void validate_memory_flags(struct vb2_queue *q,
> +static bool validate_memory_flags(struct vb2_queue *q,
>  				  int memory,
>  				  u32 *flags)
>  {
> +	if (*flags & V4L2_MEMORY_FLAG_SECURE &&
> +	    (!q->allow_secure_mem || memory != V4L2_MEMORY_DMABUF)) {
> +		return false;
> +	}
> +

This check belongs to videobuf2-core.c and the check should be done
in vb2_core_reqbufs and vb2_core_create_bufs.

So just leave this function as a void.

>  	if (!q->allow_cache_hints || memory != V4L2_MEMORY_MMAP) {
>  		/*
> -		 * This needs to clear V4L2_MEMORY_FLAG_NON_COHERENT only,
> -		 * but in order to avoid bugs we zero out all bits.
> +		 * This needs to clear V4L2_MEMORY_FLAG_NON_COHERENT only.

Just drop this as well since it adds no useful information anymore.

>  		 */
> -		*flags = 0;
> -	} else {
> -		/* Clear all unknown flags. */
> -		*flags &= V4L2_MEMORY_FLAG_NON_COHERENT;
> +		*flags &= ~V4L2_MEMORY_FLAG_NON_COHERENT;
>  	}
> +
> +	/* Clear all unknown flags. */
> +	*flags &= V4L2_MEMORY_FLAG_NON_COHERENT | V4L2_MEMORY_FLAG_SECURE;

This is still needed here.

> +
> +	return true;
>  }
>  

So the following changes from here...

>  int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
> @@ -710,7 +718,8 @@ int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
>  	u32 flags = req->flags;
>  
>  	fill_buf_caps(q, &req->capabilities);
> -	validate_memory_flags(q, req->memory, &flags);
> +	if (!validate_memory_flags(q, req->memory, &flags))
> +		return -EINVAL;
>  	req->flags = flags;
>  	return ret ? ret : vb2_core_reqbufs(q, req->memory,
>  					    req->flags, &req->count);
> @@ -752,7 +761,8 @@ int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create)
>  	unsigned i;
>  
>  	fill_buf_caps(q, &create->capabilities);
> -	validate_memory_flags(q, create->memory, &create->flags);
> +	if (!validate_memory_flags(q, create->memory, &create->flags))
> +		return -EINVAL;
>  	create->index = vb2_get_num_buffers(q);
>  	create->max_num_buffers = q->max_num_buffers;
>  	create->capabilities |= V4L2_BUF_CAP_SUPPORTS_MAX_NUM_BUFFERS;
> @@ -1007,7 +1017,8 @@ int vb2_ioctl_reqbufs(struct file *file, void *priv,
>  	u32 flags = p->flags;
>  
>  	fill_buf_caps(vdev->queue, &p->capabilities);
> -	validate_memory_flags(vdev->queue, p->memory, &flags);
> +	if (!validate_memory_flags(vdev->queue, p->memory, &flags))
> +		return -EINVAL;
>  	p->flags = flags;
>  	if (res)
>  		return res;
> @@ -1031,7 +1042,8 @@ int vb2_ioctl_create_bufs(struct file *file, void *priv,
>  
>  	p->index = vdev->queue->num_buffers;
>  	fill_buf_caps(vdev->queue, &p->capabilities);
> -	validate_memory_flags(vdev->queue, p->memory, &p->flags);
> +	if (!validate_memory_flags(vdev->queue, p->memory, &p->flags))
> +		return -EINVAL;
>  	/*
>  	 * If count == 0, then just check if memory and type are valid.
>  	 * Any -EBUSY result from vb2_verify_memory_type can be mapped to 0.

...to the end should all be dropped since the vb2 core will do the checks.

Regards,

	Hans


From vincent.guittot at linaro.org  Mon Dec 11 02:48:49 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 11 Dec 2023 11:48:49 +0100
Subject: [PATCH v7 1/7] topology: Add a new arch_scale_freq_reference
In-Reply-To: <20231211104855.558096-1-vincent.guittot@linaro.org>
References: <20231211104855.558096-1-vincent.guittot@linaro.org>
Message-ID: <20231211104855.558096-2-vincent.guittot@linaro.org>

Create a new method to get a unique and fixed max frequency. Currently
cpuinfo.max_freq or the highest (or last) state of performance domain are
used as the max frequency when computing the frequency for a level of
utilization but:
- cpuinfo_max_freq can change at runtime. boost is one example of
  such change.
- cpuinfo.max_freq and last item of the PD can be different leading to
  different results between cpufreq and energy model.

We need to save the reference frequency that has been used when computing
the CPUs capacity and use this fixed and coherent value to convert between
frequency and CPU's capacity.

In fact, we already save the frequency that has been used when computing
the capacity of each CPU. We extend the precision to save kHz instead of
MHz currently and we modify the type to be aligned with other variables
used when converting frequency to capacity and the other way.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>
Tested-by: Lukasz Luba <lukasz.luba at arm.com>
Acked-by: Sudeep Holla <sudeep.holla at arm.com>
---
 arch/arm/include/asm/topology.h   |  1 +
 arch/arm64/include/asm/topology.h |  1 +
 arch/riscv/include/asm/topology.h |  1 +
 drivers/base/arch_topology.c      | 29 ++++++++++++++---------------
 include/linux/arch_topology.h     |  7 +++++++
 include/linux/sched/topology.h    |  8 ++++++++
 6 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index c7d2510e5a78..853c4f81ba4a 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -13,6 +13,7 @@
 #define arch_set_freq_scale topology_set_freq_scale
 #define arch_scale_freq_capacity topology_get_freq_scale
 #define arch_scale_freq_invariant topology_scale_freq_invariant
+#define arch_scale_freq_ref topology_get_freq_ref
 #endif
 
 /* Replace task scheduler's default cpu-invariant accounting */
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 9fab663dd2de..a323b109b9c4 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -23,6 +23,7 @@ void update_freq_counters_refs(void);
 #define arch_set_freq_scale topology_set_freq_scale
 #define arch_scale_freq_capacity topology_get_freq_scale
 #define arch_scale_freq_invariant topology_scale_freq_invariant
+#define arch_scale_freq_ref topology_get_freq_ref
 
 #ifdef CONFIG_ACPI_CPPC_LIB
 #define arch_init_invariance_cppc topology_init_cpu_capacity_cppc
diff --git a/arch/riscv/include/asm/topology.h b/arch/riscv/include/asm/topology.h
index e316ab3b77f3..61183688bdd5 100644
--- a/arch/riscv/include/asm/topology.h
+++ b/arch/riscv/include/asm/topology.h
@@ -9,6 +9,7 @@
 #define arch_set_freq_scale		topology_set_freq_scale
 #define arch_scale_freq_capacity	topology_get_freq_scale
 #define arch_scale_freq_invariant	topology_scale_freq_invariant
+#define arch_scale_freq_ref		topology_get_freq_ref
 
 /* Replace task scheduler's default cpu-invariant accounting */
 #define arch_scale_cpu_capacity	topology_get_cpu_scale
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index b741b5ba82bd..e8d1cdf1f761 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -19,6 +19,7 @@
 #include <linux/init.h>
 #include <linux/rcupdate.h>
 #include <linux/sched.h>
+#include <linux/units.h>
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/thermal_pressure.h>
@@ -26,7 +27,8 @@
 static DEFINE_PER_CPU(struct scale_freq_data __rcu *, sft_data);
 static struct cpumask scale_freq_counters_mask;
 static bool scale_freq_invariant;
-static DEFINE_PER_CPU(u32, freq_factor) = 1;
+DEFINE_PER_CPU(unsigned long, capacity_freq_ref) = 1;
+EXPORT_PER_CPU_SYMBOL_GPL(capacity_freq_ref);
 
 static bool supports_scale_freq_counters(const struct cpumask *cpus)
 {
@@ -170,9 +172,9 @@ DEFINE_PER_CPU(unsigned long, thermal_pressure);
  * operating on stale data when hot-plug is used for some CPUs. The
  * @capped_freq reflects the currently allowed max CPUs frequency due to
  * thermal capping. It might be also a boost frequency value, which is bigger
- * than the internal 'freq_factor' max frequency. In such case the pressure
- * value should simply be removed, since this is an indication that there is
- * no thermal throttling. The @capped_freq must be provided in kHz.
+ * than the internal 'capacity_freq_ref' max frequency. In such case the
+ * pressure value should simply be removed, since this is an indication that
+ * there is no thermal throttling. The @capped_freq must be provided in kHz.
  */
 void topology_update_thermal_pressure(const struct cpumask *cpus,
 				      unsigned long capped_freq)
@@ -183,10 +185,7 @@ void topology_update_thermal_pressure(const struct cpumask *cpus,
 
 	cpu = cpumask_first(cpus);
 	max_capacity = arch_scale_cpu_capacity(cpu);
-	max_freq = per_cpu(freq_factor, cpu);
-
-	/* Convert to MHz scale which is used in 'freq_factor' */
-	capped_freq /= 1000;
+	max_freq = arch_scale_freq_ref(cpu);
 
 	/*
 	 * Handle properly the boost frequencies, which should simply clean
@@ -279,13 +278,13 @@ void topology_normalize_cpu_scale(void)
 
 	capacity_scale = 1;
 	for_each_possible_cpu(cpu) {
-		capacity = raw_capacity[cpu] * per_cpu(freq_factor, cpu);
+		capacity = raw_capacity[cpu] * per_cpu(capacity_freq_ref, cpu);
 		capacity_scale = max(capacity, capacity_scale);
 	}
 
 	pr_debug("cpu_capacity: capacity_scale=%llu\n", capacity_scale);
 	for_each_possible_cpu(cpu) {
-		capacity = raw_capacity[cpu] * per_cpu(freq_factor, cpu);
+		capacity = raw_capacity[cpu] * per_cpu(capacity_freq_ref, cpu);
 		capacity = div64_u64(capacity << SCHED_CAPACITY_SHIFT,
 			capacity_scale);
 		topology_set_cpu_scale(cpu, capacity);
@@ -321,15 +320,15 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
 			cpu_node, raw_capacity[cpu]);
 
 		/*
-		 * Update freq_factor for calculating early boot cpu capacities.
+		 * Update capacity_freq_ref for calculating early boot cpu capacities.
 		 * For non-clk CPU DVFS mechanism, there's no way to get the
 		 * frequency value now, assuming they are running at the same
-		 * frequency (by keeping the initial freq_factor value).
+		 * frequency (by keeping the initial capacity_freq_ref value).
 		 */
 		cpu_clk = of_clk_get(cpu_node, 0);
 		if (!PTR_ERR_OR_ZERO(cpu_clk)) {
-			per_cpu(freq_factor, cpu) =
-				clk_get_rate(cpu_clk) / 1000;
+			per_cpu(capacity_freq_ref, cpu) =
+				clk_get_rate(cpu_clk) / HZ_PER_KHZ;
 			clk_put(cpu_clk);
 		}
 	} else {
@@ -411,7 +410,7 @@ init_cpu_capacity_callback(struct notifier_block *nb,
 	cpumask_andnot(cpus_to_visit, cpus_to_visit, policy->related_cpus);
 
 	for_each_cpu(cpu, policy->related_cpus)
-		per_cpu(freq_factor, cpu) = policy->cpuinfo.max_freq / 1000;
+		per_cpu(capacity_freq_ref, cpu) = policy->cpuinfo.max_freq;
 
 	if (cpumask_empty(cpus_to_visit)) {
 		topology_normalize_cpu_scale();
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index a07b510e7dc5..32c24ff4f2a8 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -27,6 +27,13 @@ static inline unsigned long topology_get_cpu_scale(int cpu)
 
 void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity);
 
+DECLARE_PER_CPU(unsigned long, capacity_freq_ref);
+
+static inline unsigned long topology_get_freq_ref(int cpu)
+{
+	return per_cpu(capacity_freq_ref, cpu);
+}
+
 DECLARE_PER_CPU(unsigned long, arch_freq_scale);
 
 static inline unsigned long topology_get_freq_scale(int cpu)
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index de545ba85218..a6e04b4a21d7 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -279,6 +279,14 @@ void arch_update_thermal_pressure(const struct cpumask *cpus,
 { }
 #endif
 
+#ifndef arch_scale_freq_ref
+static __always_inline
+unsigned int arch_scale_freq_ref(int cpu)
+{
+	return 0;
+}
+#endif
+
 static inline int task_node(const struct task_struct *p)
 {
 	return cpu_to_node(task_cpu(p));
-- 
2.34.1



From vincent.guittot at linaro.org  Mon Dec 11 02:48:48 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 11 Dec 2023 11:48:48 +0100
Subject: [PATCH v7 0/7] consolidate and cleanup CPU capacity
Message-ID: <20231211104855.558096-1-vincent.guittot@linaro.org>

This is the 1st part of consolidating how the max compute capacity is
used in the scheduler and how we calculate the frequency for a level of
utilization.

Fix some unconsistancy when computing frequency for an utilization. There
can be a mismatch between energy model and schedutil.

Next step will be to make a difference between the original
max compute capacity of a CPU and what is currently available when
there is a capping applying forever (i.e. seconds or more).

Changes since v6:
- Rebase on tip/sched/core and fix a conflict
- Add tags

Changes since v5:
- Remove useless return in freq_inv_set_max_ratio()
- Add tags

Changes since v4:
- Capitalize the verb in subject
- Remove usless parentheses in cppc_get_dmi_max_khz()
- Use freq_ref pattern everywhere
- Fix MHz / kHz units conversion for cppc_cpufreq
- Move default definition of arch_scale_freq_ref() in
  include/linux/sched/topology.h beside arch_scale_cpu_capacity
  which faces similar default declaration behavior. This location covers
  all cases with arch and CONFIG_* which was not the case with previous
  attempts.

Changes since v3:
- Split patch 5 cpufreq/cppc
- Fix topology_init_cpu_capacity_cppc() 
- Fix init if AMU ratio
- Added some tags

Changes since v2:
- Remove the 1st patch which has been queued in tip
- Rework how to initialize the reference frequency for cppc_cpufreq and
  change topology_init_cpu_capacity_cppc() to also set capacity_ref_freq
- Add a RFC to convert AMU to use arch_scale_freq_ref and move the config
  of the AMU ratio to be done when intializing cpu capacity and
  capacity_ref_freq
- Added some tags

Changes since v1:
- Fix typos
- Added changes in cpufreq to use arch_scale_freq_ref() when calling
  arch_set_freq_scale (patch 3).
- arch_scale_freq_ref() is always defined and returns 0 (as proposed
  by Ionela) when not defined by the arch. This simplifies the code with
  the addition of patch 3.
- Simplify Energy Model which always uses arch_scale_freq_ref(). The
  latter returns 0 when not defined by arch instead of last item of the 
  perf domain. This is not a problem because the function is only defined
  for compilation purpose in this case and we don't care about the
  returned value. (patch 5)
- Added changes in cppc cpufreq to set capacity_ref_freq (patch 6)
- Added reviewed tag for patch 1 which got a minor change but not for
  others as I did some changes which could make previous reviewed tag
  no more relevant.

Vincent Guittot (7):
  topology: Add a new arch_scale_freq_reference
  cpufreq: Use the fixed and coherent frequency for scaling capacity
  cpufreq/schedutil: Use a fixed reference frequency
  energy_model: Use a fixed reference frequency
  cpufreq/cppc: Move and rename cppc_cpufreq_{perf_to_khz|khz_to_perf}
  cpufreq/cppc: Set the frequency used for computing the capacity
  arm64/amu: Use capacity_ref_freq to set AMU ratio

 arch/arm/include/asm/topology.h   |   1 +
 arch/arm64/include/asm/topology.h |   1 +
 arch/arm64/kernel/topology.c      |  26 +++---
 arch/riscv/include/asm/topology.h |   1 +
 drivers/acpi/cppc_acpi.c          | 104 ++++++++++++++++++++++
 drivers/base/arch_topology.c      |  56 ++++++++----
 drivers/cpufreq/cppc_cpufreq.c    | 139 ++++--------------------------
 drivers/cpufreq/cpufreq.c         |   4 +-
 include/acpi/cppc_acpi.h          |   2 +
 include/linux/arch_topology.h     |   8 ++
 include/linux/cpufreq.h           |   1 +
 include/linux/energy_model.h      |   6 +-
 include/linux/sched/topology.h    |   8 ++
 kernel/sched/cpufreq_schedutil.c  |  26 +++++-
 14 files changed, 224 insertions(+), 159 deletions(-)

-- 
2.34.1



From vincent.guittot at linaro.org  Mon Dec 11 02:48:52 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 11 Dec 2023 11:48:52 +0100
Subject: [PATCH v7 4/7] energy_model: Use a fixed reference frequency
In-Reply-To: <20231211104855.558096-1-vincent.guittot@linaro.org>
References: <20231211104855.558096-1-vincent.guittot@linaro.org>
Message-ID: <20231211104855.558096-5-vincent.guittot@linaro.org>

The last item of a performance domain is not always the performance point
that has been used to compute CPU's capacity. This can lead to different
target frequency compared with other part of the system like schedutil and
would result in wrong energy estimation.

A new arch_scale_freq_ref() is available to return a fixed and coherent
frequency reference that can be used when computing the CPU's frequency
for an level of utilization. Use this function to get this reference
frequency.

Energy model is never used without defining arch_scale_freq_ref() but
can be compiled. Define a default arch_scale_freq_ref() returning 0
in such case.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>
Tested-by: Lukasz Luba <lukasz.luba at arm.com>
---
 include/linux/energy_model.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index adec808b371a..88d91e087471 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -224,7 +224,7 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
 				unsigned long max_util, unsigned long sum_util,
 				unsigned long allowed_cpu_cap)
 {
-	unsigned long freq, scale_cpu;
+	unsigned long freq, ref_freq, scale_cpu;
 	struct em_perf_state *ps;
 	int cpu;
 
@@ -241,10 +241,10 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
 	 */
 	cpu = cpumask_first(to_cpumask(pd->cpus));
 	scale_cpu = arch_scale_cpu_capacity(cpu);
-	ps = &pd->table[pd->nr_perf_states - 1];
+	ref_freq = arch_scale_freq_ref(cpu);
 
 	max_util = min(max_util, allowed_cpu_cap);
-	freq = map_util_freq(max_util, ps->frequency, scale_cpu);
+	freq = map_util_freq(max_util, ref_freq, scale_cpu);
 
 	/*
 	 * Find the lowest performance state of the Energy Model above the
-- 
2.34.1



From vincent.guittot at linaro.org  Mon Dec 11 02:48:55 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 11 Dec 2023 11:48:55 +0100
Subject: [PATCH v7 7/7] arm64/amu: Use capacity_ref_freq to set AMU ratio
In-Reply-To: <20231211104855.558096-1-vincent.guittot@linaro.org>
References: <20231211104855.558096-1-vincent.guittot@linaro.org>
Message-ID: <20231211104855.558096-8-vincent.guittot@linaro.org>

Use the new capacity_ref_freq to set the ratio that is used by AMU for
computing the arch_scale_freq_capacity().
This helps to keep everything aligned using the same reference for
computing CPUs capacity.

The default value of the ratio (stored in per_cpu(arch_max_freq_scale))
ensures that arch_scale_freq_capacity() returns max capacity until it is
set to its correct value with the cpu capacity and capacity_ref_freq.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Acked-by: Sudeep Holla <sudeep.holla at arm.com>
Acked-by: Will Deacon <will at kernel.org>
---
 arch/arm64/kernel/topology.c  | 26 +++++++++++++-------------
 drivers/base/arch_topology.c  | 12 +++++++++++-
 include/linux/arch_topology.h |  1 +
 3 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 817d788cd866..1a2c72f3e7f8 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -82,7 +82,12 @@ int __init parse_acpi_topology(void)
 #undef pr_fmt
 #define pr_fmt(fmt) "AMU: " fmt
 
-static DEFINE_PER_CPU_READ_MOSTLY(unsigned long, arch_max_freq_scale);
+/*
+ * Ensure that amu_scale_freq_tick() will return SCHED_CAPACITY_SCALE until
+ * the CPU capacity and its associated frequency have been correctly
+ * initialized.
+ */
+static DEFINE_PER_CPU_READ_MOSTLY(unsigned long, arch_max_freq_scale) =  1UL << (2 * SCHED_CAPACITY_SHIFT);
 static DEFINE_PER_CPU(u64, arch_const_cycles_prev);
 static DEFINE_PER_CPU(u64, arch_core_cycles_prev);
 static cpumask_var_t amu_fie_cpus;
@@ -112,14 +117,14 @@ static inline bool freq_counters_valid(int cpu)
 	return true;
 }
 
-static int freq_inv_set_max_ratio(int cpu, u64 max_rate, u64 ref_rate)
+void freq_inv_set_max_ratio(int cpu, u64 max_rate)
 {
-	u64 ratio;
+	u64 ratio, ref_rate = arch_timer_get_rate();
 
 	if (unlikely(!max_rate || !ref_rate)) {
-		pr_debug("CPU%d: invalid maximum or reference frequency.\n",
+		WARN_ONCE(1, "CPU%d: invalid maximum or reference frequency.\n",
 			 cpu);
-		return -EINVAL;
+		return;
 	}
 
 	/*
@@ -139,12 +144,10 @@ static int freq_inv_set_max_ratio(int cpu, u64 max_rate, u64 ref_rate)
 	ratio = div64_u64(ratio, max_rate);
 	if (!ratio) {
 		WARN_ONCE(1, "Reference frequency too low.\n");
-		return -EINVAL;
+		return;
 	}
 
-	per_cpu(arch_max_freq_scale, cpu) = (unsigned long)ratio;
-
-	return 0;
+	WRITE_ONCE(per_cpu(arch_max_freq_scale, cpu), (unsigned long)ratio);
 }
 
 static void amu_scale_freq_tick(void)
@@ -195,10 +198,7 @@ static void amu_fie_setup(const struct cpumask *cpus)
 		return;
 
 	for_each_cpu(cpu, cpus) {
-		if (!freq_counters_valid(cpu) ||
-		    freq_inv_set_max_ratio(cpu,
-					   cpufreq_get_hw_max_freq(cpu) * 1000ULL,
-					   arch_timer_get_rate()))
+		if (!freq_counters_valid(cpu))
 			return;
 	}
 
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 0a2e43728286..0906114963ff 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -344,6 +344,10 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
 	return !ret;
 }
 
+void __weak freq_inv_set_max_ratio(int cpu, u64 max_rate)
+{
+}
+
 #ifdef CONFIG_ACPI_CPPC_LIB
 #include <acpi/cppc_acpi.h>
 
@@ -381,6 +385,9 @@ void topology_init_cpu_capacity_cppc(void)
 	}
 
 	for_each_possible_cpu(cpu) {
+		freq_inv_set_max_ratio(cpu,
+				       per_cpu(capacity_freq_ref, cpu) * HZ_PER_KHZ);
+
 		capacity = raw_capacity[cpu];
 		capacity = div64_u64(capacity << SCHED_CAPACITY_SHIFT,
 				     capacity_scale);
@@ -422,8 +429,11 @@ init_cpu_capacity_callback(struct notifier_block *nb,
 
 	cpumask_andnot(cpus_to_visit, cpus_to_visit, policy->related_cpus);
 
-	for_each_cpu(cpu, policy->related_cpus)
+	for_each_cpu(cpu, policy->related_cpus) {
 		per_cpu(capacity_freq_ref, cpu) = policy->cpuinfo.max_freq;
+		freq_inv_set_max_ratio(cpu,
+				       per_cpu(capacity_freq_ref, cpu) * HZ_PER_KHZ);
+	}
 
 	if (cpumask_empty(cpus_to_visit)) {
 		topology_normalize_cpu_scale();
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index 32c24ff4f2a8..a63d61ca55af 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -99,6 +99,7 @@ void update_siblings_masks(unsigned int cpu);
 void remove_cpu_topology(unsigned int cpuid);
 void reset_cpu_topology(void);
 int parse_acpi_topology(void);
+void freq_inv_set_max_ratio(int cpu, u64 max_rate);
 #endif
 
 #endif /* _LINUX_ARCH_TOPOLOGY_H_ */
-- 
2.34.1



From vincent.guittot at linaro.org  Mon Dec 11 02:48:54 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 11 Dec 2023 11:48:54 +0100
Subject: [PATCH v7 6/7] cpufreq/cppc: Set the frequency used for computing the capacity
In-Reply-To: <20231211104855.558096-1-vincent.guittot@linaro.org>
References: <20231211104855.558096-1-vincent.guittot@linaro.org>
Message-ID: <20231211104855.558096-7-vincent.guittot@linaro.org>

Save the frequency associated to the performance that has been used when
initializing the capacity of CPUs.
Also, cppc cpufreq driver can register an artificial energy model. In such
case, it needs the frequency for this compute capacity.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Acked-by: Sudeep Holla <sudeep.holla at arm.com>
Tested-by: Pierre Gondois <pierre.gondois at arm.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
---
 drivers/base/arch_topology.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index e8d1cdf1f761..0a2e43728286 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -349,6 +349,7 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
 
 void topology_init_cpu_capacity_cppc(void)
 {
+	u64 capacity, capacity_scale = 0;
 	struct cppc_perf_caps perf_caps;
 	int cpu;
 
@@ -365,6 +366,10 @@ void topology_init_cpu_capacity_cppc(void)
 		    (perf_caps.highest_perf >= perf_caps.nominal_perf) &&
 		    (perf_caps.highest_perf >= perf_caps.lowest_perf)) {
 			raw_capacity[cpu] = perf_caps.highest_perf;
+			capacity_scale = max_t(u64, capacity_scale, raw_capacity[cpu]);
+
+			per_cpu(capacity_freq_ref, cpu) = cppc_perf_to_khz(&perf_caps, raw_capacity[cpu]);
+
 			pr_debug("cpu_capacity: CPU%d cpu_capacity=%u (raw).\n",
 				 cpu, raw_capacity[cpu]);
 			continue;
@@ -375,7 +380,15 @@ void topology_init_cpu_capacity_cppc(void)
 		goto exit;
 	}
 
-	topology_normalize_cpu_scale();
+	for_each_possible_cpu(cpu) {
+		capacity = raw_capacity[cpu];
+		capacity = div64_u64(capacity << SCHED_CAPACITY_SHIFT,
+				     capacity_scale);
+		topology_set_cpu_scale(cpu, capacity);
+		pr_debug("cpu_capacity: CPU%d cpu_capacity=%lu\n",
+			cpu, topology_get_cpu_scale(cpu));
+	}
+
 	schedule_work(&update_topology_flags_work);
 	pr_debug("cpu_capacity: cpu_capacity initialization done\n");
 
-- 
2.34.1



From vincent.guittot at linaro.org  Mon Dec 11 02:48:50 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 11 Dec 2023 11:48:50 +0100
Subject: [PATCH v7 2/7] cpufreq: Use the fixed and coherent frequency for scaling capacity
In-Reply-To: <20231211104855.558096-1-vincent.guittot@linaro.org>
References: <20231211104855.558096-1-vincent.guittot@linaro.org>
Message-ID: <20231211104855.558096-3-vincent.guittot@linaro.org>

cpuinfo.max_freq can change at runtime because of boost as an example. This
implies that the value could be different from the frequency that has been
used to compute the capacity of a CPU.

The new arch_scale_freq_ref() returns a fixed and coherent frequency
that can be used to compute the capacity for a given frequency.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>
Tested-by: Lukasz Luba <lukasz.luba at arm.com>
Acked-by: Rafael J. Wysocki <rafael at kernel.org>
---
 drivers/cpufreq/cpufreq.c | 4 ++--
 include/linux/cpufreq.h   | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 934d35f570b7..44db4f59c4cc 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -454,7 +454,7 @@ void cpufreq_freq_transition_end(struct cpufreq_policy *policy,
 
 	arch_set_freq_scale(policy->related_cpus,
 			    policy->cur,
-			    policy->cpuinfo.max_freq);
+			    arch_scale_freq_ref(policy->cpu));
 
 	spin_lock(&policy->transition_lock);
 	policy->transition_ongoing = false;
@@ -2174,7 +2174,7 @@ unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
 
 	policy->cur = freq;
 	arch_set_freq_scale(policy->related_cpus, freq,
-			    policy->cpuinfo.max_freq);
+			    arch_scale_freq_ref(policy->cpu));
 	cpufreq_stats_record_transition(policy, freq);
 
 	if (trace_cpu_frequency_enabled()) {
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 1c5ca92a0555..afda5f24d3dd 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -1203,6 +1203,7 @@ void arch_set_freq_scale(const struct cpumask *cpus,
 {
 }
 #endif
+
 /* the following are really really optional */
 extern struct freq_attr cpufreq_freq_attr_scaling_available_freqs;
 extern struct freq_attr cpufreq_freq_attr_scaling_boost_freqs;
-- 
2.34.1



From vincent.guittot at linaro.org  Mon Dec 11 02:48:51 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 11 Dec 2023 11:48:51 +0100
Subject: [PATCH v7 3/7] cpufreq/schedutil: Use a fixed reference frequency
In-Reply-To: <20231211104855.558096-1-vincent.guittot@linaro.org>
References: <20231211104855.558096-1-vincent.guittot@linaro.org>
Message-ID: <20231211104855.558096-4-vincent.guittot@linaro.org>

cpuinfo.max_freq can change at runtime because of boost as an example. This
implies that the value could be different than the one that has been
used when computing the capacity of a CPU.

The new arch_scale_freq_ref() returns a fixed and coherent reference
frequency that can be used when computing a frequency based on utilization.

Use this arch_scale_freq_ref() when available and fallback to
policy otherwise.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>
Tested-by: Lukasz Luba <lukasz.luba at arm.com>
Acked-by: Rafael J. Wysocki <rafael at kernel.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann at arm.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
---
 kernel/sched/cpufreq_schedutil.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 4ee8ad70be99..95c3c097083e 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -114,6 +114,28 @@ static void sugov_deferred_update(struct sugov_policy *sg_policy)
 	}
 }
 
+/**
+ * get_capacity_ref_freq - get the reference frequency that has been used to
+ * correlate frequency and compute capacity for a given cpufreq policy. We use
+ * the CPU managing it for the arch_scale_freq_ref() call in the function.
+ * @policy: the cpufreq policy of the CPU in question.
+ *
+ * Return: the reference CPU frequency to compute a capacity.
+ */
+static __always_inline
+unsigned long get_capacity_ref_freq(struct cpufreq_policy *policy)
+{
+	unsigned int freq = arch_scale_freq_ref(policy->cpu);
+
+	if (freq)
+		return freq;
+
+	if (arch_scale_freq_invariant())
+		return policy->cpuinfo.max_freq;
+
+	return policy->cur;
+}
+
 /**
  * get_next_freq - Compute a new frequency for a given cpufreq policy.
  * @sg_policy: schedutil policy object to compute the new frequency for.
@@ -140,9 +162,9 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
 				  unsigned long util, unsigned long max)
 {
 	struct cpufreq_policy *policy = sg_policy->policy;
-	unsigned int freq = arch_scale_freq_invariant() ?
-				policy->cpuinfo.max_freq : policy->cur;
+	unsigned int freq;
 
+	freq = get_capacity_ref_freq(policy);
 	freq = map_util_freq(util, freq, max);
 
 	if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
-- 
2.34.1



From vincent.guittot at linaro.org  Mon Dec 11 02:48:53 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 11 Dec 2023 11:48:53 +0100
Subject: [PATCH v7 5/7] cpufreq/cppc: Move and rename cppc_cpufreq_{perf_to_khz|khz_to_perf}
In-Reply-To: <20231211104855.558096-1-vincent.guittot@linaro.org>
References: <20231211104855.558096-1-vincent.guittot@linaro.org>
Message-ID: <20231211104855.558096-6-vincent.guittot@linaro.org>

Move and rename cppc_cpufreq_perf_to_khz and cppc_cpufreq_khz_to_perf to
use them outside cppc_cpufreq in topology_init_cpu_capacity_cppc().

Modify the interface to use struct cppc_perf_caps *caps instead of
struct cppc_cpudata *cpu_data as we only use the fields of cppc_perf_caps.

cppc_cpufreq was converting the lowest and nominal freq from MHz to kHz
before using them. We move this conversion inside cppc_perf_to_khz and
cppc_khz_to_perf to make them generic and usable outside cppc_cpufreq.

No functional change

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Acked-by: Rafael J. Wysocki <rafael at kernel.org>
Tested-by: Pierre Gondois <pierre.gondois at arm.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
---
 drivers/acpi/cppc_acpi.c       | 104 ++++++++++++++++++++++++
 drivers/cpufreq/cppc_cpufreq.c | 139 ++++-----------------------------
 include/acpi/cppc_acpi.h       |   2 +
 3 files changed, 123 insertions(+), 122 deletions(-)

diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 7ff269a78c20..d155a86a8614 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -39,6 +39,9 @@
 #include <linux/rwsem.h>
 #include <linux/wait.h>
 #include <linux/topology.h>
+#include <linux/dmi.h>
+#include <linux/units.h>
+#include <asm/unaligned.h>
 
 #include <acpi/cppc_acpi.h>
 
@@ -1760,3 +1763,104 @@ unsigned int cppc_get_transition_latency(int cpu_num)
 	return latency_ns;
 }
 EXPORT_SYMBOL_GPL(cppc_get_transition_latency);
+
+/* Minimum struct length needed for the DMI processor entry we want */
+#define DMI_ENTRY_PROCESSOR_MIN_LENGTH	48
+
+/* Offset in the DMI processor structure for the max frequency */
+#define DMI_PROCESSOR_MAX_SPEED		0x14
+
+/* Callback function used to retrieve the max frequency from DMI */
+static void cppc_find_dmi_mhz(const struct dmi_header *dm, void *private)
+{
+	const u8 *dmi_data = (const u8 *)dm;
+	u16 *mhz = (u16 *)private;
+
+	if (dm->type == DMI_ENTRY_PROCESSOR &&
+	    dm->length >= DMI_ENTRY_PROCESSOR_MIN_LENGTH) {
+		u16 val = (u16)get_unaligned((const u16 *)
+				(dmi_data + DMI_PROCESSOR_MAX_SPEED));
+		*mhz = val > *mhz ? val : *mhz;
+	}
+}
+
+/* Look up the max frequency in DMI */
+static u64 cppc_get_dmi_max_khz(void)
+{
+	u16 mhz = 0;
+
+	dmi_walk(cppc_find_dmi_mhz, &mhz);
+
+	/*
+	 * Real stupid fallback value, just in case there is no
+	 * actual value set.
+	 */
+	mhz = mhz ? mhz : 1;
+
+	return KHZ_PER_MHZ * mhz;
+}
+
+/*
+ * If CPPC lowest_freq and nominal_freq registers are exposed then we can
+ * use them to convert perf to freq and vice versa. The conversion is
+ * extrapolated as an affine function passing by the 2 points:
+ *  - (Low perf, Low freq)
+ *  - (Nominal perf, Nominal freq)
+ */
+unsigned int cppc_perf_to_khz(struct cppc_perf_caps *caps, unsigned int perf)
+{
+	s64 retval, offset = 0;
+	static u64 max_khz;
+	u64 mul, div;
+
+	if (caps->lowest_freq && caps->nominal_freq) {
+		mul = caps->nominal_freq - caps->lowest_freq;
+		mul *= KHZ_PER_MHZ;
+		div = caps->nominal_perf - caps->lowest_perf;
+		offset = caps->nominal_freq * KHZ_PER_MHZ -
+			 div64_u64(caps->nominal_perf * mul, div);
+	} else {
+		if (!max_khz)
+			max_khz = cppc_get_dmi_max_khz();
+		mul = max_khz;
+		div = caps->highest_perf;
+	}
+
+	retval = offset + div64_u64(perf * mul, div);
+	if (retval >= 0)
+		return retval;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cppc_perf_to_khz);
+
+unsigned int cppc_khz_to_perf(struct cppc_perf_caps *caps, unsigned int freq)
+{
+	s64 retval, offset = 0;
+	static u64 max_khz;
+	u64  mul, div;
+
+	if (caps->lowest_freq && caps->nominal_freq) {
+		mul = caps->nominal_perf - caps->lowest_perf;
+		div = caps->nominal_freq - caps->lowest_freq;
+		/*
+		 * We don't need to convert to kHz for computing offset and can
+		 * directly use nominal_freq and lowest_freq as the div64_u64
+		 * will remove the frequency unit.
+		 */
+		offset = caps->nominal_perf -
+			 div64_u64(caps->nominal_freq * mul, div);
+		/* But we need it for computing the perf level. */
+		div *= KHZ_PER_MHZ;
+	} else {
+		if (!max_khz)
+			max_khz = cppc_get_dmi_max_khz();
+		mul = caps->highest_perf;
+		div = max_khz;
+	}
+
+	retval = offset + div64_u64(freq * mul, div);
+	if (retval >= 0)
+		return retval;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cppc_khz_to_perf);
diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index fe08ca419b3d..64420d9cfd1e 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -16,7 +16,6 @@
 #include <linux/delay.h>
 #include <linux/cpu.h>
 #include <linux/cpufreq.h>
-#include <linux/dmi.h>
 #include <linux/irq_work.h>
 #include <linux/kthread.h>
 #include <linux/time.h>
@@ -27,12 +26,6 @@
 
 #include <acpi/cppc_acpi.h>
 
-/* Minimum struct length needed for the DMI processor entry we want */
-#define DMI_ENTRY_PROCESSOR_MIN_LENGTH	48
-
-/* Offset in the DMI processor structure for the max frequency */
-#define DMI_PROCESSOR_MAX_SPEED		0x14
-
 /*
  * This list contains information parsed from per CPU ACPI _CPC and _PSD
  * structures: e.g. the highest and lowest supported performance, capabilities,
@@ -291,97 +284,9 @@ static inline void cppc_freq_invariance_exit(void)
 }
 #endif /* CONFIG_ACPI_CPPC_CPUFREQ_FIE */
 
-/* Callback function used to retrieve the max frequency from DMI */
-static void cppc_find_dmi_mhz(const struct dmi_header *dm, void *private)
-{
-	const u8 *dmi_data = (const u8 *)dm;
-	u16 *mhz = (u16 *)private;
-
-	if (dm->type == DMI_ENTRY_PROCESSOR &&
-	    dm->length >= DMI_ENTRY_PROCESSOR_MIN_LENGTH) {
-		u16 val = (u16)get_unaligned((const u16 *)
-				(dmi_data + DMI_PROCESSOR_MAX_SPEED));
-		*mhz = val > *mhz ? val : *mhz;
-	}
-}
-
-/* Look up the max frequency in DMI */
-static u64 cppc_get_dmi_max_khz(void)
-{
-	u16 mhz = 0;
-
-	dmi_walk(cppc_find_dmi_mhz, &mhz);
-
-	/*
-	 * Real stupid fallback value, just in case there is no
-	 * actual value set.
-	 */
-	mhz = mhz ? mhz : 1;
-
-	return (1000 * mhz);
-}
-
-/*
- * If CPPC lowest_freq and nominal_freq registers are exposed then we can
- * use them to convert perf to freq and vice versa. The conversion is
- * extrapolated as an affine function passing by the 2 points:
- *  - (Low perf, Low freq)
- *  - (Nominal perf, Nominal perf)
- */
-static unsigned int cppc_cpufreq_perf_to_khz(struct cppc_cpudata *cpu_data,
-					     unsigned int perf)
-{
-	struct cppc_perf_caps *caps = &cpu_data->perf_caps;
-	s64 retval, offset = 0;
-	static u64 max_khz;
-	u64 mul, div;
-
-	if (caps->lowest_freq && caps->nominal_freq) {
-		mul = caps->nominal_freq - caps->lowest_freq;
-		div = caps->nominal_perf - caps->lowest_perf;
-		offset = caps->nominal_freq - div64_u64(caps->nominal_perf * mul, div);
-	} else {
-		if (!max_khz)
-			max_khz = cppc_get_dmi_max_khz();
-		mul = max_khz;
-		div = caps->highest_perf;
-	}
-
-	retval = offset + div64_u64(perf * mul, div);
-	if (retval >= 0)
-		return retval;
-	return 0;
-}
-
-static unsigned int cppc_cpufreq_khz_to_perf(struct cppc_cpudata *cpu_data,
-					     unsigned int freq)
-{
-	struct cppc_perf_caps *caps = &cpu_data->perf_caps;
-	s64 retval, offset = 0;
-	static u64 max_khz;
-	u64  mul, div;
-
-	if (caps->lowest_freq && caps->nominal_freq) {
-		mul = caps->nominal_perf - caps->lowest_perf;
-		div = caps->nominal_freq - caps->lowest_freq;
-		offset = caps->nominal_perf - div64_u64(caps->nominal_freq * mul, div);
-	} else {
-		if (!max_khz)
-			max_khz = cppc_get_dmi_max_khz();
-		mul = caps->highest_perf;
-		div = max_khz;
-	}
-
-	retval = offset + div64_u64(freq * mul, div);
-	if (retval >= 0)
-		return retval;
-	return 0;
-}
-
 static int cppc_cpufreq_set_target(struct cpufreq_policy *policy,
 				   unsigned int target_freq,
 				   unsigned int relation)
-
 {
 	struct cppc_cpudata *cpu_data = policy->driver_data;
 	unsigned int cpu = policy->cpu;
@@ -389,7 +294,7 @@ static int cppc_cpufreq_set_target(struct cpufreq_policy *policy,
 	u32 desired_perf;
 	int ret = 0;
 
-	desired_perf = cppc_cpufreq_khz_to_perf(cpu_data, target_freq);
+	desired_perf = cppc_khz_to_perf(&cpu_data->perf_caps, target_freq);
 	/* Return if it is exactly the same perf */
 	if (desired_perf == cpu_data->perf_ctrls.desired_perf)
 		return ret;
@@ -417,7 +322,7 @@ static unsigned int cppc_cpufreq_fast_switch(struct cpufreq_policy *policy,
 	u32 desired_perf;
 	int ret;
 
-	desired_perf = cppc_cpufreq_khz_to_perf(cpu_data, target_freq);
+	desired_perf = cppc_khz_to_perf(&cpu_data->perf_caps, target_freq);
 	cpu_data->perf_ctrls.desired_perf = desired_perf;
 	ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
 
@@ -530,7 +435,7 @@ static int cppc_get_cpu_power(struct device *cpu_dev,
 	min_step = min_cap / CPPC_EM_CAP_STEP;
 	max_step = max_cap / CPPC_EM_CAP_STEP;
 
-	perf_prev = cppc_cpufreq_khz_to_perf(cpu_data, *KHz);
+	perf_prev = cppc_khz_to_perf(perf_caps, *KHz);
 	step = perf_prev / perf_step;
 
 	if (step > max_step)
@@ -550,8 +455,8 @@ static int cppc_get_cpu_power(struct device *cpu_dev,
 			perf = step * perf_step;
 	}
 
-	*KHz = cppc_cpufreq_perf_to_khz(cpu_data, perf);
-	perf_check = cppc_cpufreq_khz_to_perf(cpu_data, *KHz);
+	*KHz = cppc_perf_to_khz(perf_caps, perf);
+	perf_check = cppc_khz_to_perf(perf_caps, *KHz);
 	step_check = perf_check / perf_step;
 
 	/*
@@ -561,8 +466,8 @@ static int cppc_get_cpu_power(struct device *cpu_dev,
 	 */
 	while ((*KHz == prev_freq) || (step_check != step)) {
 		perf++;
-		*KHz = cppc_cpufreq_perf_to_khz(cpu_data, perf);
-		perf_check = cppc_cpufreq_khz_to_perf(cpu_data, *KHz);
+		*KHz = cppc_perf_to_khz(perf_caps, perf);
+		perf_check = cppc_khz_to_perf(perf_caps, *KHz);
 		step_check = perf_check / perf_step;
 	}
 
@@ -591,7 +496,7 @@ static int cppc_get_cpu_cost(struct device *cpu_dev, unsigned long KHz,
 	perf_caps = &cpu_data->perf_caps;
 	max_cap = arch_scale_cpu_capacity(cpu_dev->id);
 
-	perf_prev = cppc_cpufreq_khz_to_perf(cpu_data, KHz);
+	perf_prev = cppc_khz_to_perf(perf_caps, KHz);
 	perf_step = CPPC_EM_CAP_STEP * perf_caps->highest_perf / max_cap;
 	step = perf_prev / perf_step;
 
@@ -679,10 +584,6 @@ static struct cppc_cpudata *cppc_cpufreq_get_cpu_data(unsigned int cpu)
 		goto free_mask;
 	}
 
-	/* Convert the lowest and nominal freq from MHz to KHz */
-	cpu_data->perf_caps.lowest_freq *= 1000;
-	cpu_data->perf_caps.nominal_freq *= 1000;
-
 	list_add(&cpu_data->node, &cpu_data_list);
 
 	return cpu_data;
@@ -724,20 +625,16 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	 * Set min to lowest nonlinear perf to avoid any efficiency penalty (see
 	 * Section 8.4.7.1.1.5 of ACPI 6.1 spec)
 	 */
-	policy->min = cppc_cpufreq_perf_to_khz(cpu_data,
-					       caps->lowest_nonlinear_perf);
-	policy->max = cppc_cpufreq_perf_to_khz(cpu_data,
-					       caps->nominal_perf);
+	policy->min = cppc_perf_to_khz(caps, caps->lowest_nonlinear_perf);
+	policy->max = cppc_perf_to_khz(caps, caps->nominal_perf);
 
 	/*
 	 * Set cpuinfo.min_freq to Lowest to make the full range of performance
 	 * available if userspace wants to use any perf between lowest & lowest
 	 * nonlinear perf
 	 */
-	policy->cpuinfo.min_freq = cppc_cpufreq_perf_to_khz(cpu_data,
-							    caps->lowest_perf);
-	policy->cpuinfo.max_freq = cppc_cpufreq_perf_to_khz(cpu_data,
-							    caps->nominal_perf);
+	policy->cpuinfo.min_freq = cppc_perf_to_khz(caps, caps->lowest_perf);
+	policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->nominal_perf);
 
 	policy->transition_delay_us = cppc_cpufreq_get_transition_delay_us(cpu);
 	policy->shared_type = cpu_data->shared_type;
@@ -773,7 +670,7 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 		boost_supported = true;
 
 	/* Set policy->cur to max now. The governors will adjust later. */
-	policy->cur = cppc_cpufreq_perf_to_khz(cpu_data, caps->highest_perf);
+	policy->cur = cppc_perf_to_khz(caps, caps->highest_perf);
 	cpu_data->perf_ctrls.desired_perf =  caps->highest_perf;
 
 	ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
@@ -863,7 +760,7 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int cpu)
 	delivered_perf = cppc_perf_from_fbctrs(cpu_data, &fb_ctrs_t0,
 					       &fb_ctrs_t1);
 
-	return cppc_cpufreq_perf_to_khz(cpu_data, delivered_perf);
+	return cppc_perf_to_khz(&cpu_data->perf_caps, delivered_perf);
 }
 
 static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
@@ -878,11 +775,9 @@ static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
 	}
 
 	if (state)
-		policy->max = cppc_cpufreq_perf_to_khz(cpu_data,
-						       caps->highest_perf);
+		policy->max = cppc_perf_to_khz(caps, caps->highest_perf);
 	else
-		policy->max = cppc_cpufreq_perf_to_khz(cpu_data,
-						       caps->nominal_perf);
+		policy->max = cppc_perf_to_khz(caps, caps->nominal_perf);
 	policy->cpuinfo.max_freq = policy->max;
 
 	ret = freq_qos_update_request(policy->max_freq_req, policy->max);
@@ -937,7 +832,7 @@ static unsigned int hisi_cppc_cpufreq_get_rate(unsigned int cpu)
 	if (ret < 0)
 		return -EIO;
 
-	return cppc_cpufreq_perf_to_khz(cpu_data, desired_perf);
+	return cppc_perf_to_khz(&cpu_data->perf_caps, desired_perf);
 }
 
 static void cppc_check_hisi_workaround(void)
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index 6126c977ece0..3a0995f8bce8 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -144,6 +144,8 @@ extern int cppc_set_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls);
 extern int cppc_set_enable(int cpu, bool enable);
 extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
 extern bool cppc_perf_ctrs_in_pcc(void);
+extern unsigned int cppc_perf_to_khz(struct cppc_perf_caps *caps, unsigned int perf);
+extern unsigned int cppc_khz_to_perf(struct cppc_perf_caps *caps, unsigned int freq);
 extern bool acpi_cpc_valid(void);
 extern bool cppc_allow_fast_switch(void);
 extern int acpi_get_psd_map(unsigned int cpu, struct cppc_cpudata *cpu_data);
-- 
2.34.1



From andyshrk at 163.com  Mon Dec 11 02:49:15 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 11 Dec 2023 18:49:15 +0800
Subject: [PATCH v3 0/5] Add 2 rk3588 based boards from Cool Pi
Message-ID: <20231211104915.1779476-1-andyshrk@163.com>


This series add support for rk3588s based SBC Cool Pi 4B
and rk3588 based board Cool Pi CM5 EVB

Changes in v3:
- drop ununnecessary property status = "okay" for rtc
- drop ununnecessary property status = "okay" for backlight
- reorder some nodes alphabetical
- drop ununnecessary blank line

Changes in v2:
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b"
- drop ununnecessary property status = "okay" for gpio-led
- drop ununnecessary blank line
- change node name to rtc for hym8563
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"

Andy Yan (5):
  dt-bindings: vendor-prefixes: Add Cool Pi
  dt-bindings: arm: rockchip: Add Cool Pi 4B
  arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B
  dt-bindings: arm: rockchip: Add Cool Pi CM5 EVB
  arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5
    EVB

 .../devicetree/bindings/arm/rockchip.yaml     |  10 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/rockchip/Makefile         |   2 +
 .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 879 ++++++++++++++++++
 .../boot/dts/rockchip/rk3588s-coolpi-4b.dts   | 823 ++++++++++++++++
 5 files changed, 1716 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts

-- 
2.34.1



From andyshrk at 163.com  Mon Dec 11 02:49:37 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 11 Dec 2023 18:49:37 +0800
Subject: [PATCH v3 1/5] dt-bindings: vendor-prefixes: Add Cool Pi
In-Reply-To: <20231211104915.1779476-1-andyshrk@163.com>
References: <20231211104915.1779476-1-andyshrk@163.com>
Message-ID: <20231211104937.1779595-1-andyshrk@163.com>

Add vendor prefix for Cool Pi(https://cool-pi.com/)

Signed-off-by: Andy Yan <andyshrk at 163.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

(no changes since v1)

 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c8..ddbba46fcbad 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -294,6 +294,8 @@ patternProperties:
     description: CompuLab Ltd.
   "^congatec,.*":
     description: congatec GmbH
+  "^coolpi,.*":
+    description: cool-pi.com
   "^coreriver,.*":
     description: CORERIVER Semiconductor Co.,Ltd.
   "^corpro,.*":
-- 
2.34.1



From andyshrk at 163.com  Mon Dec 11 02:49:50 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 11 Dec 2023 18:49:50 +0800
Subject: [PATCH v3 2/5] dt-bindings: arm: rockchip: Add Cool Pi 4B
In-Reply-To: <20231211104915.1779476-1-andyshrk@163.com>
References: <20231211104915.1779476-1-andyshrk@163.com>
Message-ID: <20231211104950.1779656-1-andyshrk@163.com>

Add Cool Pi 4B, a SBC powered by RK3588S

Signed-off-by: Andy Yan <andyshrk at 163.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

(no changes since v2)

Changes in v2:
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b"

 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5deb66a5c7d9..11d03035f3db 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -95,6 +95,11 @@ properties:
           - const: chipspark,rayeager-px2
           - const: rockchip,rk3066a
 
+      - description: Cool Pi 4 Model B
+        items:
+          - const: coolpi,pi-4b
+          - const: rockchip,rk3588s
+
       - description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
         items:
           - const: edgeble,neural-compute-module-2-io   # Edgeble Neural Compute Module 2 IO Board
-- 
2.34.1



From andyshrk at 163.com  Mon Dec 11 02:50:09 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 11 Dec 2023 18:50:09 +0800
Subject: [PATCH v3 3/5] arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B
In-Reply-To: <20231211104915.1779476-1-andyshrk@163.com>
References: <20231211104915.1779476-1-andyshrk@163.com>
Message-ID: <20231211105009.1779718-1-andyshrk@163.com>

CoolPi 4B is a rk3588s based SBC.
Specification:
- Rockchip RK3588S
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- Gigabit ethernet drived by PCIE with RTL8111HS
- HDMI Type D out
- Mini DP out
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- WIFI/BT module AIC8800
- 40 pin header

Signed-off-by: Andy Yan <andyshrk at 163.com>

arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B

---

Changes in v3:
- drop ununnecessary property status = "okay" for rtc
- reorder some nodes alphabetical
- remove disabled node

Changes in v2:
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b"
- drop ununnecessary property status = "okay" for gpio-led
- drop ununnecessary blank line
- change node name to rtc for hym8563

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3588s-coolpi-4b.dts   | 823 ++++++++++++++++++
 2 files changed, 824 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 41276ca535de..e59682691eb0 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -109,6 +109,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-orangepi-5-plus.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-quartzpro64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-turing-rk1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-coolpi-4b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
new file mode 100644
index 000000000000..50b3caae0151
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
@@ -0,0 +1,823 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ * https://cool-pi.com/topic/130/coolpi-4b-product-spec-introduction
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3588s.dtsi"
+
+/ {
+	model = "RK3588S CoolPi 4 Model B";
+	compatible = "coolpi,pi-4b", "rockchip,rk3588s";
+
+	aliases {
+		mmc0 = &sdhci;
+		mmc1 = &sdio;
+		mmc2 = &sdmmc;
+		serial2 = &uart2;
+	};
+
+	analog-sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
+
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+
+		dais = <&i2s0_8ch_p0>;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl- = <&gpio_leds>;
+
+		led0: led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led1: led-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_WLAN;
+			gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "phy0tx";
+			default-state = "off";
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&hym8563>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_h>;
+		/*
+		 * On the module itself this is one of these (depending
+		 * on the actual card populated):
+		 * - SDIO_RESET_L_WL_REG_ON
+		 * - PDN (power down when low)
+		 */
+		post-power-on-delay-ms = <200>;
+		reset-gpios = <&gpio0 RK_PC7 GPIO_ACTIVE_LOW>;
+	};
+
+	vcc12v_dcin: vcc12v-dcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usbdcin: vcc5v0-usbdcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usbdcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usbdcin>;
+	};
+
+	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v85_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <850000>;
+		regulator-max-microvolt = <850000>;
+		vin-supply = <&vdd_0v85_s0>;
+	};
+
+	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd1v8_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	vcc3v3_mipi: vcc3v3-mipi-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_mipi";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_otg: vcc5v0-otg-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_otg";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_u3host_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&i2c0 {
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c6 {
+	pinctrl-0 = <&i2c6m3_xfer>;
+	status = "okay";
+
+	hym8563: rtc at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hym8563_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+&i2c7 {
+	pinctrl-0 = <&i2c7m0_xfer>;
+	status = "okay";
+
+	es8316: audio-codec at 11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		#sound-dai-cells = <0>;
+
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
+		};
+	};
+};
+
+&i2s0_8ch {
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
+		};
+	};
+};
+
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rtl8111_isolate>;
+	status = "okay";
+};
+
+&pinctrl {
+	hym8563 {
+		hym8563_int: hym8563-int {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	led {
+		gpio_leds: gpio-leds {
+			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>,
+					<0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	rtl8111 {
+		rtl8111_isolate: rtl8111-isolate {
+			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sdio-pwrseq {
+		wifi_enable_h: wifi-enable-h {
+			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins = <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>,
+					<4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		vcc5v0_u3host_en: vcc5v0-u3host-en {
+			rockchip,pins = <3 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wireless-bluetooth {
+		uart9_gpios: uart9-gpios {
+			rockchip,pins = <3 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_reset_gpio: bt-reset-gpio {
+			rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_gpio: bt-wake-gpio {
+			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_host_irq: bt-wake-host-irq {
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	wireless-wlan {
+		wifi_host_wake_irq: wifi-host-wake-irq {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		wifi_poweren_gpio: wifi-poweren-gpio {
+			rockchip,pins = <1 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
+
+&pwm2 {
+	pinctrl-0 = <&pwm2m1_pins>;
+	status = "okay";
+};
+
+&pwm13 {
+	pinctrl-names = "active";
+	pinctrl-0 = <&pwm13m2_pins>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	status = "okay";
+};
+
+&sdio {
+	max-frequency = <150000000>;
+	no-sd;
+	no-mmc;
+	bus-width = <4>;
+	disable-wp;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdiom1_pins>,<&wifi_poweren_gpio>;
+	status = "okay";
+};
+
+&sdmmc {
+	max-frequency = <150000000>;
+	no-sdio;
+	no-mmc;
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	num-cs = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	status = "okay";
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		reg = <0x0>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		spi-max-frequency = <1000000>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-name = "vdd_gpu_s0";
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-name = "vdd_cpu_lit_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-name = "vdd_log_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-name = "vdd_vdenc_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-name = "vdd_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-name = "vdd2_ddr_s3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-name = "vdd_2v0_pldo_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-name = "vcc_3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-name = "vddq_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-name = "vcc_1v8_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-name = "avcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-name = "vcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-name = "avdd_1v2_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-name = "vcc_3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-name = "vccio_sd_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-name = "pldo6_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-name = "vdd_0v75_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-name = "vdd_ddr_pll_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-name = "avdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-name = "vdd_0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-name = "vdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&u2phy3_host {
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+/* bt */
+&uart9 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn>;
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
-- 
2.34.1



From andyshrk at 163.com  Mon Dec 11 02:50:23 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 11 Dec 2023 18:50:23 +0800
Subject: [PATCH v3 4/5] dt-bindings: arm: rockchip: Add Cool Pi CM5 EVB
In-Reply-To: <20231211104915.1779476-1-andyshrk@163.com>
References: <20231211104915.1779476-1-andyshrk@163.com>
Message-ID: <20231211105023.1779786-1-andyshrk@163.com>

Add Cool Pi CM5 EVB, a board powered by RK3588

Signed-off-by: Andy Yan <andyshrk at 163.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

(no changes since v2)

Changes in v2:
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"

 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 11d03035f3db..4da83bbd642a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -95,6 +95,11 @@ properties:
           - const: chipspark,rayeager-px2
           - const: rockchip,rk3066a
 
+      - description: Cool Pi Compute Module 5(CM5) EVB
+        items:
+          - const: coolpi,pi-cm5-evb
+          - const: rockchip,rk3588
+
       - description: Cool Pi 4 Model B
         items:
           - const: coolpi,pi-4b
-- 
2.34.1



From andyshrk at 163.com  Mon Dec 11 02:50:43 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 11 Dec 2023 18:50:43 +0800
Subject: [PATCH v3 5/5] arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5 EVB
In-Reply-To: <20231211104915.1779476-1-andyshrk@163.com>
References: <20231211104915.1779476-1-andyshrk@163.com>
Message-ID: <20231211105043.1779852-1-andyshrk@163.com>

Cool Pi CM5 EVB is a board based on rk3588.

Specification:
- Rockchip RK3588
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- Gigabit ethernet x 1 with PHY YT8531
- Gigabit ethernet x 1 drived by PCIE with YT6801S
- HDMI Type A out x 2
- HDMI Type D in x 1
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- PCIE M.2 E Key for Wireless connection
- PCIE M.2 M Key for NVME connection
- 40 pin header

Signed-off-by: Andy Yan <andyshrk at 163.com>

---

Changes in v3:
- drop ununnecessary property status = "okay" for backlight
- reorder some nodes alphabetical
- drop ununnecessary blank line

Changes in v2:
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 879 ++++++++++++++++++
 2 files changed, 880 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index e59682691eb0..9be8e4830158 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-odroid-m1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-radxa-e25.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-roc-pc.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-coolpi-cm5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6b-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
new file mode 100644
index 000000000000..ccf17185dc10
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
@@ -0,0 +1,879 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3588.dtsi"
+
+/ {
+	model = "RK3588 CoolPi CM5 EVB";
+	compatible = "coolpi,pi-cm5-evb", "rockchip,rk3588";
+
+	aliases {
+		mmc0 = &sdhci;
+		mmc1 = &sdio;
+		mmc2 = &sdmmc;
+		serial2 = &uart2;
+	};
+
+	analog-sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
+
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+
+		dais = <&i2s0_8ch_p0>;
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		power-supply = <&vcc12v_dcin>;
+		pwms = <&pwm2 0 25000 0>;
+		enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bl_en>;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+
+		led: led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	vcc12v_dcin: vcc12v-dcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_lcd: vcc3v3-lcd-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd";
+		enable-active-high;
+		gpio = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&lcdpwr_en>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v85_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <850000>;
+		regulator-max-microvolt = <850000>;
+		vin-supply = <&vdd_0v85_s0>;
+	};
+
+	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd1v8_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	avdd0v75_pcie30: avdd0v75-pcie30-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v75_pcie30";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <750000>;
+		regulator-max-microvolt = <750000>;
+		vin-supply = <&avdd_0v75_s0>;
+	};
+
+	pcie30_avdd1v8: avdd1v8-pcie30-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd1v8";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host1_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_otg: vcc5v0-otg-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_otg";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&typec5v_pwren>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_mipidphy0: vcc-mipi-dphy0-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_mipidphy0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_sys>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&cam_en>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy1_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&gmac0 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-rxid";
+	pinctrl-0 = <&gmac0_miim
+		     &gmac0_tx_bus2
+		     &gmac0_rx_bus2
+		     &gmac0_rgmii_clk
+		     &gmac0_rgmii_bus>;
+	pinctrl-names = "default";
+	rx_delay = <0x00>;
+	tx_delay = <0x43>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c6 {
+	status = "okay";
+
+	hym8563: rtc at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hym8563_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PD4 IRQ_TYPE_LEVEL_LOW>;
+		wakeup-source;
+	};
+};
+
+&i2c7 {
+	pinctrl-0 = <&i2c7m0_xfer>;
+	status = "okay";
+
+	es8316: audio-codec at 11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		#sound-dai-cells = <0>;
+
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
+		};
+	};
+};
+
+&i2s0_8ch {
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
+		};
+	};
+};
+
+&mdio0 {
+	rgmii_phy: ethernet-phy at 1 {
+		/* YT8531C/H */
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&yt8531_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
+	};
+};
+
+/* M.2 E-Key */
+&pcie2x1l1 {
+	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie_clkreq &pcie_wake &pcie_rst &wifi_pwron &bt_pwron>;
+	status = "okay";
+};
+
+/* ethernet */
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rtl8111_isolate>;
+	status = "okay";
+};
+
+&pcie30phy {
+	status = "okay";
+};
+
+&pcie3x2 {
+	reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	status = "okay";
+};
+
+/* M.2 M-Kye ssd */
+&pcie3x4 {
+	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	status = "okay";
+};
+
+&pinctrl {
+	cam {
+		cam_en: cam-en {
+			rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+	};
+
+	hym8563 {
+		hym8563_int: hym8563-int {
+			rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	lcd {
+		lcdpwr_en: lcdpwr-en {
+			rockchip,pins = <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		bl_en: bl-en {
+			rockchip,pins = <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	rtl8111 {
+		rtl8111_isolate: rtl8111-isolate {
+			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	rtl8211f {
+		yt8531_rst: yt8531-rst {
+			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		vcc5v0_host1_en: vcc5v0-host1-en {
+			rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb-typec {
+		typec5v_pwren: typec5v-pwren {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	wifi {
+		bt_pwron: bt-pwron {
+			rockchip,pins = <3 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		pcie_clkreq: pcie-clkreq {
+			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		pcie_rst: pcie-rst {
+			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		wifi_pwron: wifi-pwron {
+			rockchip,pins = <3 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		pcie_wake: pcie-wake {
+			rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&sata1 {
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	status = "okay";
+};
+
+&sdmmc {
+	max-frequency = <150000000>;
+	no-sdio;
+	no-mmc;
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	status = "okay";
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	num-cs = <1>;
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		spi-max-frequency = <1000000>;
+		reg = <0x0>;
+
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_2v0_pldo_s3>;
+		vcc14-supply = <&vcc_2v0_pldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_lit_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_log_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_vdenc_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vdd2_ddr_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_2v0_pldo_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vddq_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "avcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "avdd_1v2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vcc_3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vccio_sd_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "pldo6_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_ddr_pll_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "avdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_0v85_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&u2phy3_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
-- 
2.34.1



From sherry.sun at nxp.com  Mon Dec 11 02:52:16 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Mon, 11 Dec 2023 10:52:16 +0000
Subject: [PATCH 2/4] dt-bindings: imx6q-pcie: Add host-wake-gpio property
In-Reply-To: <20231208205545.GA2675840-robh@kernel.org>
References: <20231208091355.1417292-1-sherry.sun@nxp.com>
 <20231208091355.1417292-3-sherry.sun@nxp.com>
 <83ca3d88cdaa7bc6e6bd3c4e88518b155a6b0f05.camel@pengutronix.de>
 <20231208205545.GA2675840-robh@kernel.org>
Message-ID: <AS8PR04MB8404E5D80CE9E09D835A92AB928FA@AS8PR04MB8404.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Rob Herring <robh at kernel.org>
> Sent: 2023?12?9? 4:56
> To: Lucas Stach <l.stach at pengutronix.de>
> Cc: Sherry Sun <sherry.sun at nxp.com>; Hongxing Zhu
> <hongxing.zhu at nxp.com>; lpieralisi at kernel.org; kw at linux.com;
> bhelgaas at google.com; krzysztof.kozlowski+dt at linaro.org;
> conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de;
> kernel at pengutronix.de; festevam at gmail.com; dl-linux-imx <linux-
> imx at nxp.com>; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH 2/4] dt-bindings: imx6q-pcie: Add host-wake-gpio
> property
> 
> On Fri, Dec 08, 2023 at 11:00:19AM +0100, Lucas Stach wrote:
> > Hi Sherry,
> >
> > Am Freitag, dem 08.12.2023 um 17:13 +0800 schrieb Sherry Sun:
> > > Add host-wake-gpio property that can be used to wakeup the host
> > > processor.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
> > > Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
> > > ---
> > >  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > index 81bbb8728f0f..944f0f961809 100644
> > > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > @@ -72,6 +72,10 @@ properties:
> > >        L=operation state) (optional required).
> > >      type: boolean
> > >
> > > +  host-wake-gpio:
> >
> > There is only one wake signal in PCIe and it has a defined direction,
> > so there is no point in specifying that it is a host wakeup. Also GPIO
> > handles without a traling 's' are deprecated. So this should be
> >
> > wake-gpios
> 
> Any standard PCI slot signals need to be documented in common PCI schema.
> And they should start going into root port nodes rather than the host bridge
> node because it's the root ports that correspond to slots rather than the host
> bridge. We've just taken shortcuts because many host bridges only have 1
> root port.
> 
> Note that I'm in the middle of splitting pci-bus.yaml into host bridge, PCI-PCI
> bridge (and RP), and common device schemas.
> 

Hi Rob, thanks for your comment, I am new to PCIe, can you please provide more details on which common PCI schema the WAKE# property should be added in (maybe snps,dw-pcie.yaml or something else)?

Best Regards
Sherry



From hverkuil-cisco at xs4all.nl  Mon Dec 11 02:58:36 2023
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Mon, 11 Dec 2023 11:58:36 +0100
Subject: [PATCH v3,03/21] v4l2: verify secure dmabufs are used in secure
 queue
In-Reply-To: <20231206081538.17056-4-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
 <20231206081538.17056-4-yunfei.dong@mediatek.com>
Message-ID: <705ce6b0-e945-404c-8014-38881a01fbca@xs4all.nl>

On 06/12/2023 09:15, Yunfei Dong wrote:
> From: Jeffrey Kardatzke <jkardatzke at google.com>
> 
> Verfies in the dmabuf implementations that if the secure memory flag is

Verfies -> Verifies

> set for a queue that the dmabuf submitted to the queue is unmappable.
> 
> Signed-off-by: Jeffrey Kardatzke <jkardatzke at google.com>
> Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
> ---
>  drivers/media/common/videobuf2/videobuf2-dma-contig.c | 6 ++++++
>  drivers/media/common/videobuf2/videobuf2-dma-sg.c     | 6 ++++++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 3d4fd4ef5310..ad58ef8dc231 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -710,6 +710,12 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
>  		return -EINVAL;
>  	}
>  
> +	/* verify the dmabuf is secure if we are in secure mode */
> +	if (buf->vb->vb2_queue->secure_mem && sg_page(sgt->sgl)) {

This needs a bit more explanation. I guess that for secure memory
sg_page returns NULL?

> +		pr_err("secure queue requires secure dma_buf");
> +		return -EINVAL;
> +	}
> +
>  	/* checking if dmabuf is big enough to store contiguous chunk */
>  	contig_size = vb2_dc_get_contiguous_size(sgt);
>  	if (contig_size < buf->size) {
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index 28f3fdfe23a2..55428c73c380 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -564,6 +564,12 @@ static int vb2_dma_sg_map_dmabuf(void *mem_priv)
>  		return -EINVAL;
>  	}
>  
> +	/* verify the dmabuf is secure if we are in secure mode */
> +	if (buf->vb->vb2_queue->secure_mem && !sg_dma_secure(sgt->sgl)) {

I can't find the sg_dma_secure function. I suspect this patch series
depends on another series?

> +		pr_err("secure queue requires secure dma_buf");
> +		return -EINVAL;
> +	}
> +
>  	buf->dma_sgt = sgt;
>  	buf->vaddr = NULL;
>  

Regards,

	Hans


From thierry.reding at gmail.com  Mon Dec 11 03:01:33 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 11 Dec 2023 12:01:33 +0100
Subject: [PATCH] pwm: meson: Simplify using dev_err_probe()
In-Reply-To: <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
Message-ID: <ZXbsDRslZNKCeJF9@orome.fritz.box>

On Fri, Dec 08, 2023 at 08:06:20PM +0100, Uwe Kleine-K?nig wrote:
> Hello Thierry,
> 
> On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> > This is a lot of churn for very little gain.
> 
> We seem to have different conceptions of churn. Each hunk here is an
> improvement for both SLOC count and usefulness of the generated error
> message.
> 
> 	failed to register somename: -5
> 
> is worse than
> 
> 	error EIO: failed to register somename
> 
> , isn't it?

That's entirely subjective. I think the first version is just fine. I,
and I suspect most developers will, know what to do with either of those
error messages.

> > None of these functions are ever going to return -EPROBE_DEFER. And
> > yes, I know that function's doc says that it is "deemed acceptable to
> > use" elsewhere. However, the existing error messages are just fine, no
> > need to churn just for the sake of it.
> 
> We had this disagreement already before. Yes dev_err_probe() is useful
> for three reasons and this driver only benefits from two of these.
> That's IMHO still one reason more than needed to justify such a change.

I disagree. There are certainly cases where dev_err_probe() can be a
significant improvement, but there are others where the improvement is
very minor (if there's any at all) and in my opinion the churn isn't
justified. Otherwise we'll just forever keep rewriting the same code
over and over again because somebody comes up with yet another variant
of mostly the same code.

> And if you think that a function should only be used if all advantages
> are useful for the caller, let us reconsider if we really need capture
> support in the pwm framework as only two of the 68 drivers make use of
> it.

That's a ridiculous argument and you know it. You are comparing apples
to oranges.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/5093e68e/attachment.sig>

From hverkuil-cisco at xs4all.nl  Mon Dec 11 03:05:27 2023
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Mon, 11 Dec 2023 12:05:27 +0100
Subject: [PATCH v3,04/21] v4l: add documentation for secure memory flag
In-Reply-To: <20231206081538.17056-5-yunfei.dong@mediatek.com>
References: <20231206081538.17056-1-yunfei.dong@mediatek.com>
 <20231206081538.17056-5-yunfei.dong@mediatek.com>
Message-ID: <ce2110bf-a16a-45ae-979b-7e41be2896cd@xs4all.nl>

On 06/12/2023 09:15, Yunfei Dong wrote:
> From: Jeffrey Kardatzke <jkardatzke at google.com>
> 
> Adds documentation for V4L2_MEMORY_FLAG_SECURE.
> 
> Signed-off-by: Jeffrey Kardatzke <jkardatzke at google.com>
> Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
> ---
>  Documentation/userspace-api/media/v4l/buffer.rst | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst
> index 52bbee81c080..a5a7d1c72d53 100644
> --- a/Documentation/userspace-api/media/v4l/buffer.rst
> +++ b/Documentation/userspace-api/media/v4l/buffer.rst
> @@ -696,7 +696,7 @@ enum v4l2_memory
>  
>  .. _memory-flags:
>  
> -Memory Consistency Flags
> +Memory Flags
>  ------------------------
>  
>  .. raw:: latex
> @@ -728,6 +728,12 @@ Memory Consistency Flags
>  	only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the
>  	queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
>  	<V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability.
> +    * .. _`V4L2-MEMORY-FLAG-SECURE`:
> +
> +      - ``V4L2_MEMORY_FLAG_SECURE``
> +      - 0x00000002
> +      - DMA bufs passed into the queue will be validated to ensure they were
> +	allocated from a secure dma-heap.

Hmm, that needs a bit more work. How about:

- The queued buffers are expected to be in secure memory. If not, an error will be
  returned. This flag can only be used with ``V4L2_MEMORY_DMABUF``. Typically
  secure buffers are allocated using a secure dma-heap. This flag can only be
  specified if the ``V4L2_BUF_CAP_SUPPORTS_SECURE_MEM`` is set.

In addition, the title of this table is currently "Memory Consistency Flags": that
should be renamed to "Memory Flags".

Regards,

	Hans

>  
>  .. raw:: latex
>  



From maxime.chevallier at bootlin.com  Mon Dec 11 03:06:23 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Mon, 11 Dec 2023 12:06:23 +0100
Subject: [RFC PATCH net-next v3 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <20231209170241.GA5817@kernel.org>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
	<20231201163704.1306431-2-maxime.chevallier@bootlin.com>
	<20231209170241.GA5817@kernel.org>
Message-ID: <20231211120623.03b1ced4@device.home>

Hi Simon,

On Sat, 9 Dec 2023 17:02:41 +0000
Simon Horman <horms at kernel.org> wrote:

> On Fri, Dec 01, 2023 at 05:36:51PM +0100, Maxime Chevallier wrote:
> > Link topologies containing multiple network PHYs attached to the same
> > net_device can be found when using a PHY as a media converter for use
> > with an SFP connector, on which an SFP transceiver containing a PHY can
> > be used.
> > 
> > With the current model, the transceiver's PHY can't be used for
> > operations such as cable testing, timestamping, macsec offload, etc.
> > 
> > The reason being that most of the logic for these configuration, coming
> > from either ethtool netlink or ioctls tend to use netdev->phydev, which
> > in multi-phy systems will reference the PHY closest to the MAC.
> > 
> > Introduce a numbering scheme allowing to enumerate PHY devices that
> > belong to any netdev, which can in turn allow userspace to take more
> > precise decisions with regard to each PHY's configuration.
> > 
> > The numbering is maintained per-netdev, in a phy_device_list.
> > The numbering works similarly to a netdevice's ifindex, with
> > identifiers that are only recycled once INT_MAX has been reached.
> > 
> > This prevents races that could occur between PHY listing and SFP
> > transceiver removal/insertion.
> > 
> > The identifiers are assigned at phy_attach time, as the numbering
> > depends on the netdevice the phy is attached to.
> > 
> > Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>  
> 
> Hi Maxime,
> 
> some minor feedback from my side.
> 
> ...
> 
> > diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> > index f65e85c91fc1..3cf7774df57e 100644
> > --- a/drivers/net/phy/Makefile
> > +++ b/drivers/net/phy/Makefile
> > @@ -2,7 +2,7 @@
> >  # Makefile for Linux PHY drivers
> >  
> >  libphy-y			:= phy.o phy-c45.o phy-core.o phy_device.o \
> > -				   linkmode.o
> > +				   linkmode.o phy_link_topology.o
> >  mdio-bus-y			+= mdio_bus.o mdio_device.o
> >  
> >  ifdef CONFIG_MDIO_DEVICE
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c  
> 
> ...
> 
> > @@ -265,6 +266,14 @@ static void phy_mdio_device_remove(struct mdio_device *mdiodev)
> >  
> >  static struct phy_driver genphy_driver;
> >  
> > +static struct phy_link_topology *phy_get_link_topology(struct phy_device *phydev)
> > +{
> > +	if (phydev->attached_dev)
> > +		return &phydev->attached_dev->link_topo;
> > +
> > +	return NULL;
> > +}
> > +  
> 
> This function is declared static but is unused, which causes
> allmodconfig W=1 builds to fail. Perhaps it could be introduced
> in a latter patch where it is used?

Ah true, thanks for spotting this !

> ...
> 
> > diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c  
> 
> ...
> 
> > +void phy_link_topo_init(struct phy_link_topology *topo)
> > +{
> > +	xa_init_flags(&topo->phys, XA_FLAGS_ALLOC1);
> > +	topo->next_phy_index = 1;
> > +}  
> 
> ...
> 
> > diff --git a/include/linux/phy_link_topology.h b/include/linux/phy_link_topology.h  
> 
> ...
> 
> > +#else
> > +static struct phy_device *phy_link_topo_get_phy(struct phy_link_topology *topo,
> > +						u32 phyindex)
> > +{
> > +	return NULL;
> > +}
> > +
> > +static int phy_link_topo_add_phy(struct phy_link_topology *topo,
> > +				 struct phy_device *phy,
> > +				 enum phy_upstream upt, void *upstream)
> > +{
> > +	return 0;
> > +}
> > +
> > +static void phy_link_topo_del_phy(struct phy_link_topology *topo,
> > +				  struct phy_device *phy)
> > +{
> > +}
> > +#endif  
> 
> nit: functions in .h should be declared static inline

Will do in next version

> ...
> 
> > diff --git a/net/core/dev.c b/net/core/dev.c  
> 
> ...
> 
> > @@ -10832,6 +10833,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
> >  #ifdef CONFIG_NET_SCHED
> >  	hash_init(dev->qdisc_hash);
> >  #endif
> > +	phy_link_topo_init(&dev->link_topo);
> > +  
> 
> I don't think this can work unless PHYLIB is compiled as a built-in.

Inded, I need to better clarify and document the dependency with
PHYLIB.

Thanks a lot for the review,

Maxime


From maxime.chevallier at bootlin.com  Mon Dec 11 03:07:48 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Mon, 11 Dec 2023 12:07:48 +0100
Subject: [RFC PATCH net-next v3 07/13] net: ethtool: Introduce a command
 to list PHYs on an interface
In-Reply-To: <20231209170457.GB5817@kernel.org>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
	<20231201163704.1306431-8-maxime.chevallier@bootlin.com>
	<20231209170457.GB5817@kernel.org>
Message-ID: <20231211120748.0eeb15cc@device.home>

Hi Simon,

On Sat, 9 Dec 2023 17:04:57 +0000
Simon Horman <horms at kernel.org> wrote:

> On Fri, Dec 01, 2023 at 05:36:57PM +0100, Maxime Chevallier wrote:
> > As we have the ability to track the PHYs connected to a net_device
> > through the link_topology, we can expose this list to userspace. This
> > allows userspace to use these identifiers for phy-specific commands and
> > take the decision of which PHY to target by knowing the link topology.
> > 
> > Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list
> > devices on only one interface.
> > 
> > Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>  
> 
> ...
> 
> > diff --git a/net/ethtool/phy.c b/net/ethtool/phy.c  
> 
> ...
> 
> > +static int ethnl_phy_dump_one_dev(struct sk_buff *skb, struct net_device *dev,
> > +				  struct netlink_callback *cb)
> > +{
> > +	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
> > +	struct phy_req_info *pri = ctx->phy_req_info;
> > +	struct phy_device_node *pdn;
> > +	unsigned long index = 1;
> > +	void *ehdr;
> > +	int ret;
> > +
> > +	pri->base.dev = dev;
> > +
> > +	xa_for_each(&dev->link_topo.phys, index, pdn) {
> > +		ehdr = ethnl_dump_put(skb, cb,
> > +				      ETHTOOL_MSG_PHY_GET_REPLY);
> > +		if (!ehdr) {
> > +			ret = -EMSGSIZE;
> > +			break;
> > +		}
> > +
> > +		ret = ethnl_fill_reply_header(skb, dev,
> > +					      ETHTOOL_A_PHY_HEADER);
> > +		if (ret < 0) {
> > +			genlmsg_cancel(skb, ehdr);
> > +			break;
> > +		}
> > +
> > +		memcpy(&pri->pdn, pdn, sizeof(*pdn));
> > +		ret = ethnl_phy_fill_reply(&pri->base, skb);
> > +
> > +		genlmsg_end(skb, ehdr);
> > +	}
> > +
> > +	return ret;  
> 
> Hi Maxime,
> 
> I am unsure if this can happen (or if I flagged this before)
> but if the loop runs zero times then ret is uninitialised here.
> 
> Flagged by Smatch

Ah true, let me also fix that in the next revision.

Thanks for the review,

Maxime



From neil.armstrong at linaro.org  Mon Dec 11 03:08:17 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 11 Dec 2023 12:08:17 +0100
Subject: [PATCH] arm64: dts: amlogic: drop redundant status=okay
In-Reply-To: <20231209124401.93814-1-krzysztof.kozlowski@linaro.org>
References: <20231209124401.93814-1-krzysztof.kozlowski@linaro.org>
Message-ID: <170229289706.2547617.2484626300480503159.b4-ty@linaro.org>

Hi,

On Sat, 09 Dec 2023 13:44:01 +0100, Krzysztof Kozlowski wrote:
> New device nodes are enabled by default, so no need for status=okay.
> 
> 

Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.8/arm64-dt)

[1/1] arm64: dts: amlogic: drop redundant status=okay
      https://git.kernel.org/amlogic/c/e3c58a44ea7daef26c8c53c93489888ac983f327

These changes has been applied on the intermediate git tree [1].

The v6.8/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.

In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].

The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.

If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

-- 
Neil



From neil.armstrong at linaro.org  Mon Dec 11 03:08:33 2023
From: neil.armstrong at linaro.org (neil.armstrong at linaro.org)
Date: Mon, 11 Dec 2023 12:08:33 +0100
Subject: [PATCH 2/2] arm64: dts: amlogic: minor whitespace cleanup around
 '='
In-Reply-To: <e4a163c0-5f4f-4c0e-a597-1ee06a84f3cc@linaro.org>
References: <20231124094739.58163-1-krzysztof.kozlowski@linaro.org>
 <20231124094739.58163-2-krzysztof.kozlowski@linaro.org>
 <4150bf8e-a48d-4d16-902f-a95f6489c6f5@linaro.org>
 <449d675f-e98c-4924-ab81-14a139081a97@linaro.org>
 <e4a163c0-5f4f-4c0e-a597-1ee06a84f3cc@linaro.org>
Message-ID: <5c85ff3c-3576-4415-a8f1-07d786201dc7@linaro.org>

On 11/12/2023 11:38, Krzysztof Kozlowski wrote:
> On 11/12/2023 10:10, Neil Armstrong wrote:
>> Hi,
>>
>> On 24/11/2023 10:49, Krzysztof Kozlowski wrote:
>>> On 24/11/2023 10:47, Krzysztof Kozlowski wrote:
>>>> The DTS code coding style expects exactly one space before and after '='
>>>> sign.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
>>>> ---
>>>
>>> Please ignore, that's duplicated of my previous send.
>>
>> I don't see a previous send, so I'm confused.
>> I can apply this patch if you're ok.
> 
> This was the original submission, which you applied (Thank you):
> https://lore.kernel.org/all/20231124094700.58071-1-krzysztof.kozlowski at linaro.org/
> 
> Both patches here can be ignored (applied through different series).

Ah ok, right!

> 
> Best regards,
> Krzysztof
> 



From fancer.lancer at gmail.com  Mon Dec 11 03:14:00 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Mon, 11 Dec 2023 14:14:00 +0300
Subject: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
References: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
Message-ID: <zx7tfojtnzuhcpglkeiwg6ep265xpcb5lmz6fgjjugc2tue6qe@cmuqtneujsvb>

Hi Jianheng, Jakub

On Mon, Dec 11, 2023 at 06:13:21AM +0000, Jianheng Zhang wrote:
> Adds the HW specific support for Frame Preemption handshaking on XGMAC3+
> cores.

Thanks for the patch. No objection about the change:
Reviewed-by: Serge Semin <fancer.lancer at gmail.com>

The only note is that the DW XGMAC v3.x and DW QoS Eth v5.x FPE
implementations are now identical (see the attached diff). What about
factoring out the common parts to a separate file - stmmac_fpe.c
(perhaps together with the handshaking algo from the stmmac_main.c)
and send it out as an additional patch on top of this one? A similar
thing has been recently done for EST:
https://lore.kernel.org/netdev/20231201055252.1302-1-rohan.g.thomas at intel.com/
Although in this case AFAICS the implementation is simpler and the
only difference is in the CSR offset and the frame preemption residue
queue ID setting. All of that can be easily solved in the same way as
it was done for EST (see the link above).

Jakub, what do you think?

-Serge(y)

> 
> Signed-off-by: Jianheng Zhang <Jianheng.Zhang at synopsys.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h     |  6 ++
>  .../net/ethernet/stmicro/stmmac/dwxgmac2_core.c    | 65 ++++++++++++++++++----
>  2 files changed, 60 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> index 207ff17..306d15b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> @@ -194,6 +194,12 @@
>  #define XGMAC_MDIO_DATA			0x00000204
>  #define XGMAC_MDIO_C22P			0x00000220
>  #define XGMAC_FPE_CTRL_STS		0x00000280
> +#define XGMAC_TRSP			BIT(19)
> +#define XGMAC_TVER			BIT(18)
> +#define XGMAC_RRSP			BIT(17)
> +#define XGMAC_RVER			BIT(16)
> +#define XGMAC_SRSP			BIT(2)
> +#define XGMAC_SVER			BIT(1)
>  #define XGMAC_EFPE			BIT(0)
>  #define XGMAC_ADDRx_HIGH(x)		(0x00000300 + (x) * 0x8)
>  #define XGMAC_ADDR_MAX			32
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> index eb48211..091d932 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> @@ -1439,22 +1439,63 @@ static void dwxgmac3_fpe_configure(void __iomem *ioaddr, struct stmmac_fpe_cfg *
>  {
>  	u32 value;
>  
> -	if (!enable) {
> -		value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
> +	if (enable) {
> +		cfg->fpe_csr = XGMAC_EFPE;
> +		value = readl(ioaddr + XGMAC_RXQ_CTRL1);
> +		value &= ~XGMAC_RQ;
> +		value |= (num_rxq - 1) << XGMAC_RQ_SHIFT;
> +		writel(value, ioaddr + XGMAC_RXQ_CTRL1);
> +	} else {
> +		cfg->fpe_csr = 0;
> +	}
> +	writel(cfg->fpe_csr, ioaddr + XGMAC_FPE_CTRL_STS);
> +}
>  
> -		value &= ~XGMAC_EFPE;
> +static int dwxgmac3_fpe_irq_status(void __iomem *ioaddr, struct net_device *dev)
> +{
> +	u32 value;
> +	int status;
>  
> -		writel(value, ioaddr + XGMAC_FPE_CTRL_STS);
> -		return;
> +	status = FPE_EVENT_UNKNOWN;
> +
> +	/* Reads from the XGMAC_FPE_CTRL_STS register should only be performed
> +	 * here, since the status flags of MAC_FPE_CTRL_STS are "clear on read"
> +	 */
> +	value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
> +
> +	if (value & XGMAC_TRSP) {
> +		status |= FPE_EVENT_TRSP;
> +		netdev_info(dev, "FPE: Respond mPacket is transmitted\n");
>  	}
>  
> -	value = readl(ioaddr + XGMAC_RXQ_CTRL1);
> -	value &= ~XGMAC_RQ;
> -	value |= (num_rxq - 1) << XGMAC_RQ_SHIFT;
> -	writel(value, ioaddr + XGMAC_RXQ_CTRL1);
> +	if (value & XGMAC_TVER) {
> +		status |= FPE_EVENT_TVER;
> +		netdev_info(dev, "FPE: Verify mPacket is transmitted\n");
> +	}
> +
> +	if (value & XGMAC_RRSP) {
> +		status |= FPE_EVENT_RRSP;
> +		netdev_info(dev, "FPE: Respond mPacket is received\n");
> +	}
> +
> +	if (value & XGMAC_RVER) {
> +		status |= FPE_EVENT_RVER;
> +		netdev_info(dev, "FPE: Verify mPacket is received\n");
> +	}
> +
> +	return status;
> +}
> +
> +static void dwxgmac3_fpe_send_mpacket(void __iomem *ioaddr, struct stmmac_fpe_cfg *cfg,
> +				      enum stmmac_mpacket_type type)
> +{
> +	u32 value = cfg->fpe_csr;
> +
> +	if (type == MPACKET_VERIFY)
> +		value |= XGMAC_SVER;
> +	else if (type == MPACKET_RESPONSE)
> +		value |= XGMAC_SRSP;
>  
> -	value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
> -	value |= XGMAC_EFPE;
>  	writel(value, ioaddr + XGMAC_FPE_CTRL_STS);
>  }
>  
> @@ -1503,6 +1544,8 @@ static void dwxgmac3_fpe_configure(void __iomem *ioaddr, struct stmmac_fpe_cfg *
>  	.config_l4_filter = dwxgmac2_config_l4_filter,
>  	.set_arp_offload = dwxgmac2_set_arp_offload,
>  	.fpe_configure = dwxgmac3_fpe_configure,
> +	.fpe_send_mpacket = dwxgmac3_fpe_send_mpacket,
> +	.fpe_irq_status = dwxgmac3_fpe_irq_status,
>  };
>  
>  static void dwxlgmac2_rx_queue_enable(struct mac_device_info *hw, u8 mode,
> -- 
> 1.8.3.1
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stmmac_fpe.diff
Type: text/x-patch
Size: 3544 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/0b18285a/attachment-0001.bin>

From s-vadapalli at ti.com  Mon Dec 11 03:16:41 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 11 Dec 2023 16:46:41 +0530
Subject: [PATCH v2 1/2] arm64: dts: ti: k3-j721e-evm: Add overlay for
 PCIE0 Endpoint Mode
In-Reply-To: <c50f5dc2-8ab8-4213-a809-fcd4cd18589d@ti.com>
References: <20231115085204.3578616-1-s-vadapalli@ti.com>
 <20231115085204.3578616-2-s-vadapalli@ti.com>
 <c50f5dc2-8ab8-4213-a809-fcd4cd18589d@ti.com>
Message-ID: <750c2b6b-8f24-4b86-996f-6f50cf46d81b@ti.com>

Hello Andrew,

On 05/12/23 21:43, Andrew Davis wrote:
> On 11/15/23 2:52 AM, Siddharth Vadapalli wrote:
>> Add overlay to enable the PCIE0 instance of PCIe on J721E-EVM in
>> Endpoint mode of operation.
>>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
>> ---
>> ? arch/arm64/boot/dts/ti/Makefile?????????????? |? 3 ++
>> ? .../boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso??? | 53 +++++++++++++++++++
>> ? 2 files changed, 56 insertions(+)
>> ? create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
>>
>> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
>> index 77a347f9f47d..5620db44d4dc 100644
>> --- a/arch/arm64/boot/dts/ti/Makefile
>> +++ b/arch/arm64/boot/dts/ti/Makefile
>> @@ -66,6 +66,8 @@ dtb-$(CONFIG_ARCH_K3) += k3-j7200-evm.dtb
>> ? k3-j721e-evm-dtbs := k3-j721e-common-proc-board.dtb
>> k3-j721e-evm-quad-port-eth-exp.dtbo
>> ? dtb-$(CONFIG_ARCH_K3) += k3-j721e-beagleboneai64.dtb
>> ? dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm.dtb
>> +k3-j721e-evm-pcie0-ep-dtbs := k3-j721e-evm.dtb k3-j721e-evm-pcie0-ep.dtbo
>> +dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie0-ep.dtb
> 
> Do you really need to produce this pre-combined DTB file? If you would rather
> just the overlay produced which could be applied at load-time (I prefer this),
> then you should do as Jai has done[0]. Add just the overlay, and test its
> application using a dummy target.

Thank you for pointing it out. I will implement your suggestion and post the v3
series.

-- 
Regards,
Siddharth.


From thierry.reding at gmail.com  Mon Dec 11 03:33:04 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 11 Dec 2023 12:33:04 +0100
Subject: [PATCH v4 000/115] pwm: Fix lifetime issues for pwm_chips
In-Reply-To: <20231208185033.e6ty2cajcfle6dgk@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
 <ZXM4CdJxg-XrYhkn@orome.fritz.box>
 <20231208185033.e6ty2cajcfle6dgk@pengutronix.de>
Message-ID: <ZXbzcFTnDTKoZAta@orome.fritz.box>

On Fri, Dec 08, 2023 at 07:50:33PM +0100, Uwe Kleine-K?nig wrote:
> Hello Thierry,
> 
> On Fri, Dec 08, 2023 at 04:41:39PM +0100, Thierry Reding wrote:
> > On Wed, Dec 06, 2023 at 12:43:14PM +0100, Uwe Kleine-K?nig wrote:
> > > This series is based on Thierry's for-next.
> > > 
> > > It starts with some cleanups that were all sent out separately already:
> > > 
> > >  - "pwm: Reduce number of pointer dereferences in pwm_device_request()"
> > >    https://lore.kernel.org/linux-pwm/20231130072105.966848-1-u.kleine-koenig at pengutronix.de
> > >  - "pwm: crc: Use consistent variable naming for driver data"
> > >    https://lore.kernel.org/linux-pwm/20231130074133.969806-1-u.kleine-koenig at pengutronix.de
> > >  - Two leds/qcom-lpg patches
> > >    https://lore.kernel.org/linux-leds/20231126095230.683204-1-u.kleine-koenig at pengutronix.de
> > >    Lee already claimed to have taken the series already, but it's not yet in
> > >    next.
> > >  - "leds: qcom-lpg: Introduce a wrapper for getting driver data from a pwm chip"
> > >    https://lore.kernel.org/linux-leds/20231124215208.616551-3-u.kleine-koenig at pengutronix.de
> > > 
> > > In the following patches I changed:
> > > 
> > >  - "pwm: cros-ec: Change prototype of helper to prepare further changes" +
> > >    This was simplified in response to feedback by Tzung-Bi Shih
> > >  - Make pwmchip_priv() static (and don't export it), let drivers use a new
> > >    pwmchip_get_drvdata() instead.
> > >  - For drm/ti-sn65dsi86.c and leds/qcom-lpg make use of
> > >    pwmchip_set_drvdata() which makes the conversion to
> > >    devm_pwmchip_alloc() much prettier.
> > >  - Some cleanups here and there
> > >  - Add review tags received in v3
> > >    I kept all tags even though the pwmchip_alloc() patches changed
> > >    slightly. Most of the time that's only
> > >    s/pwmchip_priv/pwmchip_get_drvdata/ though. Still, if you object,
> > >    just tell me. (This affects Paul Cercueil on patch #68, Conor Dooley
> > >    on patch #76 and Greg for patch #109.)
> > > 
> > > I kept the pwmchip_alloc() + pwmchip_register() approach despite Bart
> > > not liking it. To balance that out I don't like Bart's alternative
> > > approach. There are no technically relevant differences between the two
> > > approaches and no benchmarks that show either of the two to be better
> > > than the other. Conceptually the design ideas around pwmchip_alloc() +
> > > pwmchip_register() are used in several other subsystems, so it's a
> > > proven way to do things.
> > 
> > [Trimming the recipients, keeping only Bart and the mailing lists.]
> > 
> > I do think there are technically relevant differences. For one, the
> > better we isolate the internal data structure, the easier this becomes
> > to manage. I'm attaching a patch that I've prototyped which should
> > basically get us to somewhere around patch 110 of this series but with
> > something like 1/8th of the changes. It doesn't need every driver to
> > change and (mostly) decouples driver code from the core code.
> 
> You don't need to touch all drivers because you didn't change struct
> pwm_chip::dev yet. (If you really want, you don't need to change that,
> but then you have some duplication as chip->dev holds the same value as
> priv->dev.parent in the end.)

I don't think that's a problem. These are for two logically separate
things, after all. Duplication can also sometimes be useful to simplify
things. There are plently of cases where we use local variables for the
same reason.

> > Now, I know that you think this is all bad because it's not a single
> > allocation, but I much prefer the end result because it's got the driver
> > and internals much more cleanly separated. Going forward I think it
> > would be easier to apply all the ref-counting on top of that because we
> > only need to keep the PWM framework-internal data structure alive after
> > a PWM chip has gone away.
> 
> Nearly all drivers need driver private data. Isn't it a nice service by
> the pwm core to make handling this private data easier for the lowlevel
> drivers?

That's only true if you think pwmchip_alloc() makes it easier. I happen
to think that it doesn't. On the contrary, I think having drivers pass
in a PWM chip descriptor that can be embedded in driver-private data is
much easier.

> > From 72ea79887d96850f9ccc832ce52b907ca276c940 Mon Sep 17 00:00:00 2001
> > From: Thierry Reding <thierry.reding at gmail.com>
> > Date: Tue, 28 Nov 2023 15:42:39 +0100
> > Subject: [PATCH] pwm: Isolate internal data into a separate structure
> > 
> > In order to prepare for proper reference counting of PWM chips and PWM
> > devices, move the internal data from the public PWM chip to a private
> > PWM chip structure. This ensures that the data that the subsystem core
> > may need to reference later on can stick around beyond the lifetime of
> > the driver-private data.
> > 
> > Signed-off-by: Thierry Reding <thierry.reding at gmail.com>
> > ---
> >  drivers/pwm/core.c            | 185 +++++++++++++++++++++-------------
> >  drivers/pwm/internal.h        |  38 +++++++
> >  drivers/pwm/pwm-atmel-hlcdc.c |   8 +-
> >  drivers/pwm/pwm-fsl-ftm.c     |   6 +-
> >  drivers/pwm/pwm-lpc18xx-sct.c |   4 +-
> >  drivers/pwm/pwm-lpss.c        |  14 +--
> >  drivers/pwm/pwm-pca9685.c     |   6 +-
> >  drivers/pwm/pwm-samsung.c     |   6 +-
> >  drivers/pwm/pwm-sifive.c      |   4 +-
> >  drivers/pwm/pwm-stm32-lp.c    |   6 +-
> >  drivers/pwm/pwm-stm32.c       |   6 +-
> >  drivers/pwm/pwm-tiecap.c      |   6 +-
> >  drivers/pwm/pwm-tiehrpwm.c    |   6 +-
> >  drivers/pwm/sysfs.c           |  48 ++++-----
> >  include/linux/pwm.h           |  26 +----
> >  15 files changed, 228 insertions(+), 141 deletions(-)
> >  create mode 100644 drivers/pwm/internal.h
> > 
> > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> > index f60b715abe62..54d57dec6dce 100644
> > --- a/drivers/pwm/core.c
> > +++ b/drivers/pwm/core.c
> > @@ -24,17 +24,19 @@
> >  #define CREATE_TRACE_POINTS
> >  #include <trace/events/pwm.h>
> >  
> > +#include "internal.h"
> > +
> >  static DEFINE_MUTEX(pwm_lookup_lock);
> >  static LIST_HEAD(pwm_lookup_list);
> >  
> > -/* protects access to pwmchip_idr */
> > +/* protects access to pwm_chips */
> >  static DEFINE_MUTEX(pwm_lock);
> >  
> > -static DEFINE_IDR(pwmchip_idr);
> > +static DEFINE_IDR(pwm_chips);
> 
> That's an unrelated change.

Yeah, it should probably go into the patch that changes the list to an
IDR. There's really no reason why this needed to change in the first
place.

> 
> >  static struct pwm_chip *pwmchip_find_by_name(const char *name)
> >  {
> > -	struct pwm_chip *chip;
> > +	struct pwm_chip_private *priv;
> >  	unsigned long id, tmp;
> >  
> >  	if (!name)
> > @@ -42,12 +44,12 @@ static struct pwm_chip *pwmchip_find_by_name(const char *name)
> >  
> >  	mutex_lock(&pwm_lock);
> >  
> > -	idr_for_each_entry_ul(&pwmchip_idr, chip, tmp, id) {
> > -		const char *chip_name = dev_name(chip->dev);
> > +	idr_for_each_entry_ul(&pwm_chips, priv, tmp, id) {
> > +		const char *chip_name = dev_name(priv->chip->dev);
> 
> two pointer dereferences instead of one before.
> 
> >  		if (chip_name && strcmp(chip_name, name) == 0) {
> >  			mutex_unlock(&pwm_lock);
> > -			return chip;
> > +			return priv->chip;
> 
> one pointer reference instead of none before.
> 
> >  		}
> >  	}
> >  
> > @@ -58,23 +60,24 @@ static struct pwm_chip *pwmchip_find_by_name(const char *name)
> >  
> >  static int pwm_device_request(struct pwm_device *pwm, const char *label)
> >  {
> > +	struct pwm_chip *chip = pwm->priv->chip;
> 
> With my approach getting the chip of a struct pwm_device is only one
> pointer dereference away. You need two.

None of the functions here are called very often, so even if this isn't
optimized away it would hardly matter.

> >  	int err;
> >  
> >  	if (test_bit(PWMF_REQUESTED, &pwm->flags))
> >  		return -EBUSY;
> >  
> > -	if (!try_module_get(pwm->chip->owner))
> > +	if (!try_module_get(pwm->priv->owner))
> >  		return -ENODEV;
> >  
> > -	if (pwm->chip->ops->request) {
> > -		err = pwm->chip->ops->request(pwm->chip, pwm);
> > +	if (chip->ops->request) {
> > +		err = chip->ops->request(chip, pwm);
> 
> You seem to have reimplemented half of
> https://lore.kernel.org/linux-pwm/20231130072105.966848-1-u.kleine-koenig at pengutronix.de
> here.

I started prototyping this before you sent out that patch.

> >  		if (err) {
> > -			module_put(pwm->chip->owner);
> > +			module_put(pwm->priv->owner);
> >  			return err;
> >  		}
> >  	}
> >  
> > -	if (pwm->chip->ops->get_state) {
> > +	if (chip->ops->get_state) {
> >  		/*
> >  		 * Zero-initialize state because most drivers are unaware of
> >  		 * .usage_power. The other members of state are supposed to be
> > @@ -84,7 +87,7 @@ static int pwm_device_request(struct pwm_device *pwm, const char *label)
> >  		 */
> >  		struct pwm_state state = { 0, };
> >  
> > -		err = pwm->chip->ops->get_state(pwm->chip, pwm, &state);
> > +		err = chip->ops->get_state(chip, pwm, &state);
> >  		trace_pwm_get(pwm, &state, err);
> >  
> >  		if (!err)
> > @@ -196,6 +199,64 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
> >  	return true;
> >  }
> >  
> > +static struct pwm_chip_private *pwmchip_alloc(struct pwm_chip *chip,
> > +					      struct module *owner)
> > +{
> > +	struct pwm_chip_private *priv;
> > +	struct pwm_device *pwm;
> > +	unsigned int i;
> > +	int err;
> > +
> > +	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> > +	if (!priv)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	priv->pwms = kcalloc(chip->npwm, sizeof(*pwm), GFP_KERNEL);
> > +	if (!priv->pwms) {
> > +		err = -ENOMEM;
> > +		goto free;
> > +	}
> 
> Oh, so you don't use one additional allocation but two.

This could easily be folded into one, but we already determined that we
both have different opinions about whether this matters a lot or not.

> 
> > +	priv->owner = owner;
> > +	priv->chip = chip;
> > +
> > +	for (i = 0; i < chip->npwm; i++) {
> > +		struct pwm_device *pwm = &priv->pwms[i];
> > +
> > +		pwm->priv = priv;
> > +		pwm->hwpwm = i;
> > +	}
> > +
> > +	mutex_lock(&pwm_lock);
> > +
> > +	err = idr_alloc(&pwm_chips, priv, 0, 0, GFP_KERNEL);
> > +	if (err < 0) {
> > +		mutex_unlock(&pwm_lock);
> > +		goto free;
> > +	}
> > +
> > +	mutex_unlock(&pwm_lock);
> > +
> > +	priv->id = err;
> > +
> > +	return priv;
> > +
> > +free:
> > +	kfree(priv->pwms);
> > +	kfree(priv);
> > +	return ERR_PTR(err);
> > +}
> > +
> > +static void pwmchip_free(struct pwm_chip_private *priv)
> > +{
> > +	mutex_lock(&pwm_lock);
> > +	idr_remove(&pwm_chips, priv->id);
> > +	mutex_unlock(&pwm_lock);
> > +
> > +	kfree(priv->pwms);
> > +	kfree(priv);
> > +}
> > +
> >  /**
> >   * __pwmchip_add() - register a new PWM chip
> >   * @chip: the PWM chip to add
> > @@ -208,8 +269,7 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
> >   */
> >  int __pwmchip_add(struct pwm_chip *chip, struct module *owner)
> >  {
> > -	unsigned int i;
> > -	int ret;
> > +	struct pwm_chip_private *priv;
> >  
> >  	if (!chip || !chip->dev || !chip->ops || !chip->npwm)
> >  		return -EINVAL;
> > @@ -217,36 +277,16 @@ int __pwmchip_add(struct pwm_chip *chip, struct module *owner)
> >  	if (!pwm_ops_check(chip))
> >  		return -EINVAL;
> >  
> > -	chip->owner = owner;
> > -
> > -	chip->pwms = kcalloc(chip->npwm, sizeof(*chip->pwms), GFP_KERNEL);
> > -	if (!chip->pwms)
> > +	priv = pwmchip_alloc(chip, owner);
> > +	if (!priv)
> >  		return -ENOMEM;
> >  
> > -	mutex_lock(&pwm_lock);
> > -
> > -	ret = idr_alloc(&pwmchip_idr, chip, 0, 0, GFP_KERNEL);
> > -	if (ret < 0) {
> > -		mutex_unlock(&pwm_lock);
> > -		kfree(chip->pwms);
> > -		return ret;
> > -	}
> > -
> > -	chip->id = ret;
> > -
> > -	for (i = 0; i < chip->npwm; i++) {
> > -		struct pwm_device *pwm = &chip->pwms[i];
> > -
> > -		pwm->chip = chip;
> > -		pwm->hwpwm = i;
> > -	}
> > -
> > -	mutex_unlock(&pwm_lock);
> > +	chip->priv = priv;
> >  
> >  	if (IS_ENABLED(CONFIG_OF))
> >  		of_pwmchip_add(chip);
> >  
> > -	pwmchip_sysfs_export(chip);
> > +	pwmchip_sysfs_export(priv);
> >  
> >  	return 0;
> >  }
> > @@ -260,18 +300,14 @@ EXPORT_SYMBOL_GPL(__pwmchip_add);
> >   */
> >  void pwmchip_remove(struct pwm_chip *chip)
> >  {
> > -	pwmchip_sysfs_unexport(chip);
> > -
> > -	if (IS_ENABLED(CONFIG_OF))
> > -		of_pwmchip_remove(chip);
> > -
> >  	mutex_lock(&pwm_lock);
> >  
> > -	idr_remove(&pwmchip_idr, chip->id);
> > +	pwmchip_sysfs_unexport(chip->priv);
> >  
> > -	mutex_unlock(&pwm_lock);
> > +	if (IS_ENABLED(CONFIG_OF))
> > +		of_pwmchip_remove(chip);
> >  
> > -	kfree(chip->pwms);
> > +	pwmchip_free(chip->priv);
> >  }
> >  EXPORT_SYMBOL_GPL(pwmchip_remove);
> >  
> > @@ -315,7 +351,7 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
> >  		return ERR_PTR(-EINVAL);
> >  
> >  	mutex_lock(&pwm_lock);
> > -	pwm = &chip->pwms[index];
> > +	pwm = &chip->priv->pwms[index];
> 
> two pointer dereferences instead of one before.
> 
> >  	err = pwm_device_request(pwm, label);
> >  	if (err < 0)
> > @@ -329,9 +365,9 @@ EXPORT_SYMBOL_GPL(pwm_request_from_chip);
> >  static void pwm_apply_state_debug(struct pwm_device *pwm,
> >  				  const struct pwm_state *state)
> >  {
> > -	struct pwm_state *last = &pwm->last;
> > -	struct pwm_chip *chip = pwm->chip;
> > +	struct pwm_chip *chip = pwm->priv->chip;
> >  	struct pwm_state s1 = { 0 }, s2 = { 0 };
> > +	struct pwm_state *last = &pwm->last;
> >  	int err;
> >  
> >  	if (!IS_ENABLED(CONFIG_PWM_DEBUG))
> > @@ -439,7 +475,6 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
> >   */
> >  int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
> >  {
> > -	struct pwm_chip *chip;
> >  	int err;
> >  
> >  	/*
> > @@ -455,8 +490,6 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
> >  	    state->duty_cycle > state->period)
> >  		return -EINVAL;
> >  
> > -	chip = pwm->chip;
> > -
> >  	if (state->period == pwm->state.period &&
> >  	    state->duty_cycle == pwm->state.duty_cycle &&
> >  	    state->polarity == pwm->state.polarity &&
> > @@ -464,7 +497,7 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
> >  	    state->usage_power == pwm->state.usage_power)
> >  		return 0;
> >  
> > -	err = chip->ops->apply(chip, pwm, state);
> > +	err = pwm->priv->chip->ops->apply(pwm->priv->chip, pwm, state);
> 
> four pointer dereferences instead of two before.
> 
> >  	trace_pwm_apply(pwm, state, err);
> >  	if (err)
> >  		return err;
> > @@ -492,16 +525,19 @@ EXPORT_SYMBOL_GPL(pwm_apply_state);
> >  int pwm_capture(struct pwm_device *pwm, struct pwm_capture *result,
> >  		unsigned long timeout)
> >  {
> > +	struct pwm_chip *chip;
> >  	int err;
> >  
> > -	if (!pwm || !pwm->chip->ops)
> > +	if (!pwm)
> >  		return -EINVAL;
> >  
> > -	if (!pwm->chip->ops->capture)
> > +	chip = pwm->priv->chip;
> 
> One pointer deference more than before (assuming sensible compilation).
> 
> > +	if (!chip || !chip->ops || !chip->ops->capture)
> >  		return -ENOSYS;
> 
> Changing the return code for !chip->ops isn't intended, is it?

It's a quick prototype, I didn't pay particular attention to keeping all
error codes exactly as they were before.

> > diff --git a/drivers/pwm/internal.h b/drivers/pwm/internal.h
> > new file mode 100644
> > index 000000000000..44fffd3b6744
> > --- /dev/null
> > +++ b/drivers/pwm/internal.h
> > @@ -0,0 +1,38 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#ifndef PWM_INTERNAL_H
> > +#define PWM_INTERNAL_H
> > +
> > +#include <linux/list.h>
> 
> This is unused?

Yes, can be dropped now. This was prototyped prior to the IDR rework and
I forgot to drop this after rebasing it on top.

> > +struct pwm_chip;
> > +struct pwm_device;
> > +
> > +/**
> > + * struct pwm_chip_private - subsystem-private PWM chip data
> > + * @chip: driver-private PWM chip data
> > + * @owner: module providing the chip
> > + * @pwms: array of PWM devices allocated by the framework
> > + * @base: number of first PWM controlled by this chip
> > + */
> > +struct pwm_chip_private {
> > +	struct pwm_chip *chip;
> > +	struct module *owner;
> > +	struct pwm_device *pwms;
> > +	unsigned int id;
> > +};
> 
> With my approach the struct pwm_chip * pointer isn't needed because it's
> all in one structure. So you have two structures where I only have one
> and your two are bigger in sum than my single one (not counting memory
> management overhead and alignment).

The split is on purpose and has the benefit of clearly separating the
PWM internal data structures from the driver accessible ones. So in my
book this is an advantage.

> > +#ifdef CONFIG_PWM_SYSFS
> > +void pwmchip_sysfs_export(struct pwm_chip_private *priv);
> > +void pwmchip_sysfs_unexport(struct pwm_chip_private *priv);
> > +#else
> > +static inline void pwmchip_sysfs_export(struct pwm_chip_private *priv)
> > +{
> > +}
> > +
> > +static inline void pwmchip_sysfs_unexport(struct pwm_chip_private *priv)
> > +{
> > +}
> > +#endif /* CONFIG_PWM_SYSFS */
> > +
> > +#endif /* PWM_INTERNAL_H */
> > diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
> > index 3f2c5031a3ba..6bbbfaa582c1 100644
> > --- a/drivers/pwm/pwm-atmel-hlcdc.c
> > +++ b/drivers/pwm/pwm-atmel-hlcdc.c
> > @@ -15,6 +15,8 @@
> >  #include <linux/pwm.h>
> >  #include <linux/regmap.h>
> >  
> > +#include "internal.h"
> > +
> >  #define ATMEL_HLCDC_PWMCVAL_MASK	GENMASK(15, 8)
> >  #define ATMEL_HLCDC_PWMCVAL(x)		(((x) << 8) & ATMEL_HLCDC_PWMCVAL_MASK)
> >  #define ATMEL_HLCDC_PWMPOL		BIT(4)
> > @@ -185,7 +187,7 @@ static int atmel_hlcdc_pwm_suspend(struct device *dev)
> >  	struct atmel_hlcdc_pwm *atmel = dev_get_drvdata(dev);
> >  
> >  	/* Keep the periph clock enabled if the PWM is still running. */
> > -	if (pwm_is_enabled(&atmel->chip.pwms[0]))
> > +	if (pwm_is_enabled(&atmel->chip.priv->pwms[0]))
> 
> Didn't work so well to hide the internals of pwm_chip_private from the
> drivers?
> 
> >  		clk_disable_unprepare(atmel->hlcdc->periph_clk);
> >  
> >  	return 0;
> >  
> 
> [... a few more drivers where hiding the internals failed ...]

Yes, and you'll recall that these are for exactly the cases where in the
past you have argued that the core should take a more active role in
making sure that PWMs get properly disabled. These should be temporary
and once this logic is all moved into the core these should disappear.

> 
> > diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> > index 4edb994fa2e1..653df20afe1c 100644
> > --- a/drivers/pwm/sysfs.c
> > +++ b/drivers/pwm/sysfs.c
> > @@ -14,6 +14,8 @@
> >  #include <linux/kdev_t.h>
> >  #include <linux/pwm.h>
> >  
> > +#include "internal.h"
> > +
> >  struct pwm_export {
> >  	struct device child;
> >  	struct pwm_device *pwm;
> > @@ -311,7 +313,7 @@ static ssize_t export_store(struct device *parent,
> >  			    struct device_attribute *attr,
> >  			    const char *buf, size_t len)
> >  {
> > -	struct pwm_chip *chip = dev_get_drvdata(parent);
> > +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
> >  	struct pwm_device *pwm;
> >  	unsigned int hwpwm;
> >  	int ret;
> > @@ -320,10 +322,10 @@ static ssize_t export_store(struct device *parent,
> >  	if (ret < 0)
> >  		return ret;
> >  
> > -	if (hwpwm >= chip->npwm)
> > +	if (hwpwm >= priv->chip->npwm)
> 
> One more pointer dereference than before. You could trade that for some
> data duplication by copying npwm to struct pwmchip_priv for the case
> when you need .npwm but the chip is already gone.

When the chip is gone, none of these functions should be doing anything
other than returning an error. None of that is implemented in this yet.
This is merely a preparatory patch.

> 
> >  		return -ENODEV;
> >  
> > -	pwm = pwm_request_from_chip(chip, hwpwm, "sysfs");
> > +	pwm = pwm_request_from_chip(priv->chip, hwpwm, "sysfs");
> >  	if (IS_ERR(pwm))
> >  		return PTR_ERR(pwm);
> >  
> > @@ -339,7 +341,7 @@ static ssize_t unexport_store(struct device *parent,
> >  			      struct device_attribute *attr,
> >  			      const char *buf, size_t len)
> >  {
> > -	struct pwm_chip *chip = dev_get_drvdata(parent);
> > +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
> >  	unsigned int hwpwm;
> >  	int ret;
> >  
> > @@ -347,10 +349,10 @@ static ssize_t unexport_store(struct device *parent,
> >  	if (ret < 0)
> >  		return ret;
> >  
> > -	if (hwpwm >= chip->npwm)
> > +	if (hwpwm >= priv->chip->npwm)
> 
> One more pointer dereference than before.
> 
> >  		return -ENODEV;
> >  
> > -	ret = pwm_unexport_child(parent, &chip->pwms[hwpwm]);
> > +	ret = pwm_unexport_child(parent, &priv->pwms[hwpwm]);
> >  
> >  	return ret ? : len;
> >  }
> > @@ -359,9 +361,9 @@ static DEVICE_ATTR_WO(unexport);
> >  static ssize_t npwm_show(struct device *parent, struct device_attribute *attr,
> >  			 char *buf)
> >  {
> > -	const struct pwm_chip *chip = dev_get_drvdata(parent);
> > +	const struct pwm_chip_private *priv = dev_get_drvdata(parent);
> >  
> > -	return sysfs_emit(buf, "%u\n", chip->npwm);
> > +	return sysfs_emit(buf, "%u\n", priv->chip->npwm);
> >  }
> >  static DEVICE_ATTR_RO(npwm);
> >  
> > @@ -411,12 +413,12 @@ static int pwm_class_apply_state(struct pwm_export *export,
> >  
> >  static int pwm_class_resume_npwm(struct device *parent, unsigned int npwm)
> >  {
> > -	struct pwm_chip *chip = dev_get_drvdata(parent);
> > +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
> >  	unsigned int i;
> >  	int ret = 0;
> >  
> >  	for (i = 0; i < npwm; i++) {
> > -		struct pwm_device *pwm = &chip->pwms[i];
> > +		struct pwm_device *pwm = &priv->pwms[i];
> >  		struct pwm_state state;
> >  		struct pwm_export *export;
> >  
> > @@ -442,12 +444,12 @@ static int pwm_class_resume_npwm(struct device *parent, unsigned int npwm)
> >  
> >  static int pwm_class_suspend(struct device *parent)
> >  {
> > -	struct pwm_chip *chip = dev_get_drvdata(parent);
> > +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
> >  	unsigned int i;
> >  	int ret = 0;
> >  
> > -	for (i = 0; i < chip->npwm; i++) {
> > -		struct pwm_device *pwm = &chip->pwms[i];
> > +	for (i = 0; i < priv->chip->npwm; i++) {
> > +		struct pwm_device *pwm = &priv->pwms[i];
> >  		struct pwm_state state;
> >  		struct pwm_export *export;
> >  
> > @@ -483,9 +485,9 @@ static int pwm_class_suspend(struct device *parent)
> >  
> >  static int pwm_class_resume(struct device *parent)
> >  {
> > -	struct pwm_chip *chip = dev_get_drvdata(parent);
> > +	struct pwm_chip_private *priv = dev_get_drvdata(parent);
> >  
> > -	return pwm_class_resume_npwm(parent, chip->npwm);
> > +	return pwm_class_resume_npwm(parent, priv->chip->npwm);
> 
> One more pointer dereference than before.
> 
> >  }
> >  
> >  static DEFINE_SIMPLE_DEV_PM_OPS(pwm_class_pm_ops, pwm_class_suspend, pwm_class_resume);
> > @@ -501,7 +503,7 @@ static int pwmchip_sysfs_match(struct device *parent, const void *data)
> >  	return dev_get_drvdata(parent) == data;
> >  }
> >  
> > -void pwmchip_sysfs_export(struct pwm_chip *chip)
> > +void pwmchip_sysfs_export(struct pwm_chip_private *priv)
> >  {
> >  	struct device *parent;
> >  
> > @@ -509,26 +511,26 @@ void pwmchip_sysfs_export(struct pwm_chip *chip)
> >  	 * If device_create() fails the pwm_chip is still usable by
> >  	 * the kernel it's just not exported.
> >  	 */
> > -	parent = device_create(&pwm_class, chip->dev, MKDEV(0, 0), chip,
> > -			       "pwmchip%d", chip->id);
> > +	parent = device_create(&pwm_class, priv->chip->dev, MKDEV(0, 0), priv,
> > +			       "pwmchip%d", priv->id);
> >  	if (IS_ERR(parent)) {
> > -		dev_warn(chip->dev,
> > +		dev_warn(priv->chip->dev,
> 
> One more pointer dereference than before.
> 
> >  			 "device_create failed for pwm_chip sysfs export\n");
> >  	}
> >  }
> 
> The TL;DR; is essentially what I already wrote in my last reply to Bart
> in the v3 thread[1]:
> 
>  - My approach needs more changes to the individual drivers (which I
>    don't consider a relevant disadvantage given that the resulting code
>    is better);
>  - My approach works with less pointer dereferences which IMHO also
>    simplifies understanding the code as all relevant data is in a single
>    place.
>  - My approach has a weaker separation between the core and the lowlevel
>    drivers. That's ok in my book given that this doesn't complicate the
>    lowlevel drivers and that hiding details considerably better doesn't
>    work anyhow (see the drivers that need internal.h in your patch).
> 
> For me the single allocation issue is only an added bonus. The relevant
> advantage of my approach is that the code is easier and (probably) more
> efficient.

I happen to disagree. I think adding pwmchip_alloc() makes things much
more complicated for low level drivers.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/61861d34/attachment-0001.sig>

From peter.griffin at linaro.org  Mon Dec 11 03:35:39 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 11:35:39 +0000
Subject: [PATCH v6 13/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <46c9c8b4-942d-4f6f-a6cc-00158314d5e5@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-14-peter.griffin@linaro.org> <46c9c8b4-942d-4f6f-a6cc-00158314d5e5@linaro.org>
Message-ID: <CADrjBPr6k-j=swq8zJfOjaYQW7hvWCTXj2ZZQT6V+QUtjEYOcg@mail.gmail.com>

Hi Krzysztof,

Thanks for the review.

On Sun, 10 Dec 2023 at 13:56, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 10/12/2023 00:30, Peter Griffin wrote:
> > Add support for the pin-controller found on the gs101 SoC used in
> > Pixel 6 phones.
> >
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
>
>
> > diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > index 6b58ec84e34b..3834bf953178 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> > @@ -468,6 +468,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
> >                       .data = &exynos7_wkup_irq_chip },
> >       { .compatible = "samsung,exynosautov9-wakeup-eint",
> >                       .data = &exynos7_wkup_irq_chip },
> > +     { .compatible = "google,gs101-wakeup-eint",
> > +                     .data = &exynos7_wkup_irq_chip },
>
> You don't need it.

OK will drop

>
> >       { }
> >  };
> >
> > diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > index 79babbb39ced..b8d549fe38cb 100644
> > --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> > +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > @@ -1321,6 +1321,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
> >               .data = &exynosautov9_of_data },
> >       { .compatible = "tesla,fsd-pinctrl",
> >               .data = &fsd_of_data },
> > +     { .compatible = "google,gs101-pinctrl",
> > +             .data = &gs101_of_data },
>
> Place it somewhere alphabetically. Probably before tesla.

Will fix. FYI I was intending to put it at the top ('g' before 's')
that also matches the ordering everywhere else e.g. in the YAML docs
etc.

regards,

Peter


From will at kernel.org  Mon Dec 11 03:39:39 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 11:39:39 +0000
Subject: [PATCH v2 1/3] arm64: Avoid enabling KPTI unnecessarily
In-Reply-To: <ZWX1fHAaiaxLoX8O@FVFF77S0Q05N.cambridge.arm.com>
References: <20231127120049.2258650-5-ardb@google.com>
 <20231127120049.2258650-6-ardb@google.com>
 <20231127154818.GA8453@willie-the-truck>
 <CAMj1kXFpN8NsS6a9XmBOQ+JybpJtbBb87gyvD5f7Ng4cFs7Sxg@mail.gmail.com>
 <20231127163103.GA8627@willie-the-truck>
 <20231127164127.GB8627@willie-the-truck>
 <ZWTWob3EuIAl_V_B@FVFF77S0Q05N>
 <20231128110339.GA9717@willie-the-truck>
 <ZWX1fHAaiaxLoX8O@FVFF77S0Q05N.cambridge.arm.com>
Message-ID: <20231211113939.GA24899@willie-the-truck>

On Tue, Nov 28, 2023 at 02:13:16PM +0000, Mark Rutland wrote:
> On Tue, Nov 28, 2023 at 11:03:40AM +0000, Will Deacon wrote:
> > On Mon, Nov 27, 2023 at 05:49:21PM +0000, Mark Rutland wrote:
> > > In addition to that intent, these functions are executed precisely once during
> > > boot, so using cpus_have_cap() avoids the space for the alt_instr and the cost
> > > of the patching of the site for a single check. I was also hoping to get rid of
> > > most of the feature check helpers now that they're largely trivial wrappers
> > > around alternative_has_cap(), which'd make it clearer which callsites care
> > > about the alterntive-ness and clear up the inconsistent naming.
> > 
> > We can always remove the helpers when you get round to it, but ideally
> > many of these things would BUG() if they're called too early, much like
> > e.g. cpus_have_final_cap(). Inlining the alternative is going to make that
> > more difficult.
> 
> That's fair.
> 
> My major goal is that it's clear where we're using an altnernative and where
> we're not; if the thinking is the vast majority *should* be alternatives, I can
> annotate the non-alternative cases to make that clear.
> 
> > > If you want these cases moves back to alternatives-based feature check helpers,
> > > I can go do that.
> > 
> > I was thinking of something like the diff below to start with.
> 
> Sure; as-is that breaks the hyp offset patching, and we'll need ensure we still
> call hyp_mode_check() before apply_alternatives_all(). In hyp_mode_check() we
> call kvm_compute_layout(), which generates the 'va_mask', 'tag_val', and
> 'tag_lsb' values which are used by the kvm_update_va_mask() patching callback
> (for kern_hyp_va() and __kern_hyp_va()).
> 
> I think that can be moved before enable_cpu_capabilities() ratehr than needing
> to be between enable_cpu_capabilities() and apply_alternatives_all(), but I'll
> need to go digging to make certain.
> 
> Do you want this as a cleanup for v6.7-rc*, or as something to queue for
> v6.8-rc1?

Sorry, I keep forgetting to reply to this after we spoke in-person. If
you're able to spin something in the next day or so, I can pick it up for
the next merge window. In the meantime, I'll grab Ard's changes so this can
go on top.

Cheers,

Will


From jaewon02.kim at samsung.com  Mon Dec 11 03:41:43 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Mon, 11 Dec 2023 20:41:43 +0900
Subject: [PATCH v4 0/2] Introduce ExynosAutov920 SoC and SADK board
References: <CGME20231211114215epcas2p226d66c6dd01a4414559272c648c3d464@epcas2p2.samsung.com>
Message-ID: <20231211114145.106255-1-jaewon02.kim@samsung.com>

ExynosAutov920[1] is ARMv8-based automotive-oriented SoC.
This SoC is the next generation of exynosautov9 and AE(Automotive Enhanced)
IPs are used for safety.

This patchset is the minimal set for ExynosAutov920 SoC and SADK board.
Currently, ramdisk console is available and Clock, UFS, and USI will be
added after this patchset.

[1] : https://semiconductor.samsung.com/processor/automotive-processor/exynos-auto-v920

---
Changes in v4:
 - Modify the comment for clear understanding
 - svc-related changes moved to exynosautov920 support patch
 - device-tree file merged in v3

Changes in v3:
 - Split pinctrl driver change patch and v920 support patch
 - Remove 'combine' variable and use offset variable
 - Fix coding style warning in checkpatch with --strict option
 - Fix CHECK_DTBS=y waring with W=1 option
 - dt-binding document merged in v2

Changes in v2:
 - Rebase to git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
             branch : for-v6.8/samsung-bindings-compatibles
 - Specific exynosautov920 compatible
 - Add dt-binding patch for pmu, chipid


Jaewon Kim (2):
  pinctrl: samsung: support ExynosAuto GPIO structure
  pinctrl: samsung: add exynosautov920 pinctrl

 .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 140 ++++++++++++++++++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |  95 ++++++++++--
 drivers/pinctrl/samsung/pinctrl-exynos.h      |  25 ++++
 drivers/pinctrl/samsung/pinctrl-samsung.c     |   5 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |  13 ++
 5 files changed, 269 insertions(+), 9 deletions(-)

-- 
2.43.0



From jaewon02.kim at samsung.com  Mon Dec 11 03:41:45 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Mon, 11 Dec 2023 20:41:45 +0900
Subject: [PATCH v4 2/2] pinctrl: samsung: add exynosautov920 pinctrl
In-Reply-To: <20231211114145.106255-1-jaewon02.kim@samsung.com>
References: <20231211114145.106255-1-jaewon02.kim@samsung.com>
	<CGME20231211114216epcas2p300bbf4c592d495991c6cc2d96e0b1f85@epcas2p3.samsung.com>
Message-ID: <20231211114145.106255-3-jaewon02.kim@samsung.com>

Add pinctrl data for ExynosAutov920 SoC.
It has a newly applied pinctrl register layer for ExynosAuto series.

Pinctrl data for ExynosAutoV920 SoC.
 - GPA0,GPA1 (10): External wake up interrupt
 - GPQ0 (2): SPMI (PMIC I/F)
 - GPB0,GPB1,GPB2,GPB3,GPB4,GPB5,GPB6 (47): I2S Audio
 - GPH0,GPH1,GPH2,GPH3,GPH4,GPH5,GPH6,GPH8 (49): PCIE, UFS, Ethernet
 - GPG0,GPG1,GPG2,GPG3,GPG4,GPG5 (29): General purpose
 - GPP0,GPP1,GPP2,GPP3,GPP4,GPP5,GPP6,GPP7,GPP8,GPP9,GPP10 (77): USI

Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
---
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 140 ++++++++++++++++++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |  23 ++-
 drivers/pinctrl/samsung/pinctrl-exynos.h      |  25 ++++
 drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
 5 files changed, 190 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index cb965cf93705..a998c296dd05 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -796,3 +796,143 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
 	.ctrl		= fsd_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
 };
+
+/* pin banks of exynosautov920 pin-controller 0 (ALIVE) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks0[] = {
+	EXYNOSV920_PIN_BANK_EINTW(8, 0x0000, "gpa0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTW(2, 0x1000, "gpa1", 0x18, 0x20, 0x24),
+	EXYNOS850_PIN_BANK_EINTN(2, 0x2000, "gpq0"),
+};
+
+/* pin banks of exynosautov920 pin-controller 1 (AUD) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks1[] = {
+	EXYNOSV920_PIN_BANK_EINTG(7, 0x0000, "gpb0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(6, 0x1000, "gpb1", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x2000, "gpb2", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x3000, "gpb3", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x4000, "gpb4", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x5000, "gpb5", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x6000, "gpb6", 0x18, 0x24, 0x28),
+};
+
+/* pin banks of exynosautov920 pin-controller 2 (HSI0) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks2[] = {
+	EXYNOSV920_PIN_BANK_EINTG(6, 0x0000, "gph0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(2, 0x1000, "gph1", 0x18, 0x20, 0x24),
+};
+
+/* pin banks of exynosautov920 pin-controller 3 (HSI1) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks3[] = {
+	EXYNOSV920_PIN_BANK_EINTG(7, 0x000, "gph8", 0x18, 0x24, 0x28),
+};
+
+/* pin banks of exynosautov920 pin-controller 4 (HSI2) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks4[] = {
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x0000, "gph3", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(7, 0x1000, "gph4", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x2000, "gph5", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(7, 0x3000, "gph6", 0x18, 0x24, 0x28),
+};
+
+/* pin banks of exynosautov920 pin-controller 5 (HSI2UFS) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks5[] = {
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x000, "gph2", 0x18, 0x20, 0x24),
+};
+
+/* pin banks of exynosautov920 pin-controller 6 (PERIC0) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks6[] = {
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x0000, "gpp0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x1000, "gpp1", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x2000, "gpp2", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x3000, "gpg0", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x4000, "gpp3", 0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x5000, "gpp4", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x6000, "gpg2", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x7000, "gpg5", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(3, 0x8000, "gpg3", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x9000, "gpg4", 0x18, 0x24, 0x28),
+};
+
+/* pin banks of exynosautov920 pin-controller 7 (PERIC1) */
+static const struct samsung_pin_bank_data exynosautov920_pin_banks7[] = {
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x0000, "gpp5",  0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(5, 0x1000, "gpp6",  0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x2000, "gpp10", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x3000, "gpp7",  0x18, 0x24, 0x28),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x4000, "gpp8",  0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x5000, "gpp11", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x6000, "gpp9",  0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(4, 0x7000, "gpp12", 0x18, 0x20, 0x24),
+	EXYNOSV920_PIN_BANK_EINTG(8, 0x8000, "gpg1",  0x18, 0x24, 0x28),
+};
+
+static const struct samsung_retention_data exynosautov920_retention_data __initconst = {
+	.regs	 = NULL,
+	.nr_regs = 0,
+	.value	 = 0,
+	.refcnt	 = &exynos_shared_retention_refcnt,
+	.init	 = exynos_retention_init,
+};
+
+static const struct samsung_pin_ctrl exynosautov920_pin_ctrl[] = {
+	{
+		/* pin-controller instance 0 ALIVE data */
+		.pin_banks	= exynosautov920_pin_banks0,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks0),
+		.eint_wkup_init	= exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+		.retention_data	= &exynosautov920_retention_data,
+	}, {
+		/* pin-controller instance 1 AUD data */
+		.pin_banks	= exynosautov920_pin_banks1,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks1),
+	}, {
+		/* pin-controller instance 2 HSI0 data */
+		.pin_banks	= exynosautov920_pin_banks2,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks2),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 3 HSI1 data */
+		.pin_banks	= exynosautov920_pin_banks3,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks3),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 4 HSI2 data */
+		.pin_banks	= exynosautov920_pin_banks4,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks4),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 5 HSI2UFS data */
+		.pin_banks	= exynosautov920_pin_banks5,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks5),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 6 PERIC0 data */
+		.pin_banks	= exynosautov920_pin_banks6,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks6),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin-controller instance 7 PERIC1 data */
+		.pin_banks	= exynosautov920_pin_banks7,
+		.nr_banks	= ARRAY_SIZE(exynosautov920_pin_banks7),
+		.eint_gpio_init	= exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	},
+};
+
+const struct samsung_pinctrl_of_match_data exynosautov920_of_data __initconst = {
+	.ctrl		= exynosautov920_pin_ctrl,
+	.num_ctrl	= ARRAY_SIZE(exynosautov920_pin_ctrl),
+};
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 77f747e629f7..934426d61a6f 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -267,7 +267,10 @@ static irqreturn_t exynos_eint_gpio_irq(int irq, void *data)
 	unsigned int svc, group, pin;
 	int ret;
 
-	svc = readl(bank->eint_base + EXYNOS_SVC_OFFSET);
+	if (bank->eint_con_offset)
+		svc = readl(bank->eint_base + EXYNOSAUTO_SVC_OFFSET);
+	else
+		svc = readl(bank->eint_base + EXYNOS_SVC_OFFSET);
 	group = EXYNOS_SVC_GROUP(svc);
 	pin = svc & EXYNOS_SVC_NUM_MASK;
 
@@ -476,6 +479,22 @@ static const struct exynos_irq_chip exynos7_wkup_irq_chip __initconst = {
 	.set_eint_wakeup_mask = exynos_pinctrl_set_eint_wakeup_mask,
 };
 
+static const struct exynos_irq_chip exynosautov920_wkup_irq_chip __initconst = {
+	.chip = {
+		.name = "exynosautov920_wkup_irq_chip",
+		.irq_unmask = exynos_irq_unmask,
+		.irq_mask = exynos_irq_mask,
+		.irq_ack = exynos_irq_ack,
+		.irq_set_type = exynos_irq_set_type,
+		.irq_set_wake = exynos_wkup_irq_set_wake,
+		.irq_request_resources = exynos_irq_request_resources,
+		.irq_release_resources = exynos_irq_release_resources,
+	},
+	.eint_wake_mask_value = &eint_wake_mask_value,
+	.eint_wake_mask_reg = EXYNOS5433_EINT_WAKEUP_MASK,
+	.set_eint_wakeup_mask = exynos_pinctrl_set_eint_wakeup_mask,
+};
+
 /* list of external wakeup controllers supported */
 static const struct of_device_id exynos_wkup_irq_ids[] = {
 	{ .compatible = "samsung,s5pv210-wakeup-eint",
@@ -488,6 +507,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
 			.data = &exynos7_wkup_irq_chip },
 	{ .compatible = "samsung,exynosautov9-wakeup-eint",
 			.data = &exynos7_wkup_irq_chip },
+	{ .compatible = "samsung,exynosautov920-wakeup-eint",
+			.data = &exynosautov920_wkup_irq_chip },
 	{ }
 };
 
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index 3ac52c2cf998..305cb1d31de4 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -31,6 +31,7 @@
 #define EXYNOS7_WKUP_EMASK_OFFSET	0x900
 #define EXYNOS7_WKUP_EPEND_OFFSET	0xA00
 #define EXYNOS_SVC_OFFSET		0xB08
+#define EXYNOSAUTO_SVC_OFFSET		0xF008
 
 /* helpers to access interrupt service register */
 #define EXYNOS_SVC_GROUP_SHIFT		3
@@ -140,6 +141,30 @@
 		.name		= id				\
 	}
 
+#define EXYNOSV920_PIN_BANK_EINTG(pins, reg, id, con_offs, mask_offs, pend_offs)	\
+	{							\
+		.type			= &exynos850_bank_type_off,	\
+		.pctl_offset		= reg,				\
+		.nr_pins		= pins,				\
+		.eint_type		= EINT_TYPE_GPIO,		\
+		.eint_con_offset	= con_offs,			\
+		.eint_mask_offset	= mask_offs,			\
+		.eint_pend_offset	= pend_offs,			\
+		.name			= id				\
+	}
+
+#define EXYNOSV920_PIN_BANK_EINTW(pins, reg, id, con_offs, mask_offs, pend_offs)	\
+	{							\
+		.type			= &exynos850_bank_type_alive,	\
+		.pctl_offset		= reg,				\
+		.nr_pins		= pins,				\
+		.eint_type		= EINT_TYPE_WKUP,		\
+		.eint_con_offset	= con_offs,			\
+		.eint_mask_offset	= mask_offs,			\
+		.eint_pend_offset	= pend_offs,			\
+		.name			= id				\
+	}
+
 /**
  * struct exynos_weint_data: irq specific data for all the wakeup interrupts
  * generated by the external wakeup interrupt controller.
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 362e99566919..47fb72fad8eb 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1322,6 +1322,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 		.data = &exynos850_of_data },
 	{ .compatible = "samsung,exynosautov9-pinctrl",
 		.data = &exynosautov9_of_data },
+	{ .compatible = "samsung,exynosautov920-pinctrl",
+		.data = &exynosautov920_of_data },
 	{ .compatible = "tesla,fsd-pinctrl",
 		.data = &fsd_of_data },
 #endif
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 789358bcd9c5..987086fa0d1d 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -362,6 +362,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7_of_data;
 extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
 extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
 extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
+extern const struct samsung_pinctrl_of_match_data exynosautov920_of_data;
 extern const struct samsung_pinctrl_of_match_data fsd_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
-- 
2.43.0



From jaewon02.kim at samsung.com  Mon Dec 11 03:41:44 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Mon, 11 Dec 2023 20:41:44 +0900
Subject: [PATCH v4 1/2] pinctrl: samsung: support ExynosAuto GPIO structure
In-Reply-To: <20231211114145.106255-1-jaewon02.kim@samsung.com>
References: <20231211114145.106255-1-jaewon02.kim@samsung.com>
	<CGME20231211114215epcas2p21c9a1c2157cd1650f5ec12487eddb576@epcas2p2.samsung.com>
Message-ID: <20231211114145.106255-2-jaewon02.kim@samsung.com>

New ExynosAuto series GPIO have a different register structure.
In the existing Exynos series, EINT control register is enumerated after
a specific offset (e.g EXYNOS_GPIO_ECON_OFFSET, EXYNOS_GPIO_EMASK_OFFSET).
However, from ExynosAutov920 SoC, the register that controls EINT belongs
to each GPIO bank, and each GPIO bank has 0x1000 align.

This is a structure to protect the GPIO bank using S2MPU in VM environment,
and will only be applied in ExynosAuto series SoCs.

--------------------------------------------------------------
| Original Exynos            | ExynosAuto                    |
|------------------------------------------------------------|
| 0x0   GPIO_CON             | 0x0   GPIO_CON                |
| 0x4   GPIO_DAT             | 0x4   GPIO_DAT                |
| 0x8   GPIO_PUD             | 0x8   GPIO_PUD                |
| 0xc   GPIO_DRV             | 0xc   GPIO_DRV                |
| 0x10  GPIO_CONPDN          | 0x10  GPIO_CONPDN             |
| 0x14  GPIO_PUDPDN          | 0x14  GPIO_PUDPDN             |
|----------------------------| 0x18  EINT_CON (per_bank)     |
| ...                        | 0x1c  EINT_FLTCON0 (per_bank) |
| ...                        | 0x20  EINT_FLTCON1 (per_bank) |
| ...                        | 0x24  EINT_MASK (per_bank)    |
| ...                        | 0x28  EINT_PEND (per_bank)    |
|----------------------------|-------------------------------|
| 0x700 EINT_CON (global)    | ...                           |
| 0x800 EINT_FLTCON (global) | ...                           |
| 0x900 EINT_MASK (global)   | ...                           |
| 0xa00 EINT_FEND (global)   | ...                           |
--------------------------------------------------------------

Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 72 ++++++++++++++++++++---
 drivers/pinctrl/samsung/pinctrl-samsung.c |  3 +
 drivers/pinctrl/samsung/pinctrl-samsung.h | 12 ++++
 3 files changed, 79 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 6b58ec84e34b..77f747e629f7 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -52,10 +52,15 @@ static void exynos_irq_mask(struct irq_data *irqd)
 	struct irq_chip *chip = irq_data_get_irq_chip(irqd);
 	struct exynos_irq_chip *our_chip = to_exynos_irq_chip(chip);
 	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
-	unsigned long reg_mask = our_chip->eint_mask + bank->eint_offset;
+	unsigned long reg_mask;
 	unsigned int mask;
 	unsigned long flags;
 
+	if (bank->eint_mask_offset)
+		reg_mask = bank->pctl_offset + bank->eint_mask_offset;
+	else
+		reg_mask = our_chip->eint_mask + bank->eint_offset;
+
 	raw_spin_lock_irqsave(&bank->slock, flags);
 
 	mask = readl(bank->eint_base + reg_mask);
@@ -70,7 +75,12 @@ static void exynos_irq_ack(struct irq_data *irqd)
 	struct irq_chip *chip = irq_data_get_irq_chip(irqd);
 	struct exynos_irq_chip *our_chip = to_exynos_irq_chip(chip);
 	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
-	unsigned long reg_pend = our_chip->eint_pend + bank->eint_offset;
+	unsigned long reg_pend;
+
+	if (bank->eint_pend_offset)
+		reg_pend = bank->pctl_offset + bank->eint_pend_offset;
+	else
+		reg_pend = our_chip->eint_pend + bank->eint_offset;
 
 	writel(1 << irqd->hwirq, bank->eint_base + reg_pend);
 }
@@ -80,7 +90,7 @@ static void exynos_irq_unmask(struct irq_data *irqd)
 	struct irq_chip *chip = irq_data_get_irq_chip(irqd);
 	struct exynos_irq_chip *our_chip = to_exynos_irq_chip(chip);
 	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
-	unsigned long reg_mask = our_chip->eint_mask + bank->eint_offset;
+	unsigned long reg_mask;
 	unsigned int mask;
 	unsigned long flags;
 
@@ -95,6 +105,11 @@ static void exynos_irq_unmask(struct irq_data *irqd)
 	if (irqd_get_trigger_type(irqd) & IRQ_TYPE_LEVEL_MASK)
 		exynos_irq_ack(irqd);
 
+	if (bank->eint_mask_offset)
+		reg_mask = bank->pctl_offset + bank->eint_mask_offset;
+	else
+		reg_mask = our_chip->eint_mask + bank->eint_offset;
+
 	raw_spin_lock_irqsave(&bank->slock, flags);
 
 	mask = readl(bank->eint_base + reg_mask);
@@ -111,7 +126,7 @@ static int exynos_irq_set_type(struct irq_data *irqd, unsigned int type)
 	struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
 	unsigned int shift = EXYNOS_EINT_CON_LEN * irqd->hwirq;
 	unsigned int con, trig_type;
-	unsigned long reg_con = our_chip->eint_con + bank->eint_offset;
+	unsigned long reg_con;
 
 	switch (type) {
 	case IRQ_TYPE_EDGE_RISING:
@@ -139,6 +154,11 @@ static int exynos_irq_set_type(struct irq_data *irqd, unsigned int type)
 	else
 		irq_set_handler_locked(irqd, handle_level_irq);
 
+	if (bank->eint_con_offset)
+		reg_con = bank->pctl_offset + bank->eint_con_offset;
+	else
+		reg_con = our_chip->eint_con + bank->eint_offset;
+
 	con = readl(bank->eint_base + reg_con);
 	con &= ~(EXYNOS_EINT_CON_MASK << shift);
 	con |= trig_type << shift;
@@ -655,6 +675,19 @@ static void exynos_pinctrl_suspend_bank(
 	pr_debug("%s: save    mask %#010x\n", bank->name, save->eint_mask);
 }
 
+static void exynosauto_pinctrl_suspend_bank(struct samsung_pinctrl_drv_data *drvdata,
+					    struct samsung_pin_bank *bank)
+{
+	struct exynos_eint_gpio_save *save = bank->soc_priv;
+	void __iomem *regs = bank->eint_base;
+
+	save->eint_con = readl(regs + bank->pctl_offset + bank->eint_con_offset);
+	save->eint_mask = readl(regs + bank->pctl_offset + bank->eint_mask_offset);
+
+	pr_debug("%s: save     con %#010x\n", bank->name, save->eint_con);
+	pr_debug("%s: save    mask %#010x\n", bank->name, save->eint_mask);
+}
+
 void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
@@ -662,8 +695,12 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 	int i;
 
 	for (i = 0; i < drvdata->nr_banks; ++i, ++bank) {
-		if (bank->eint_type == EINT_TYPE_GPIO)
-			exynos_pinctrl_suspend_bank(drvdata, bank);
+		if (bank->eint_type == EINT_TYPE_GPIO) {
+			if (bank->eint_con_offset)
+				exynosauto_pinctrl_suspend_bank(drvdata, bank);
+			else
+				exynos_pinctrl_suspend_bank(drvdata, bank);
+		}
 		else if (bank->eint_type == EINT_TYPE_WKUP) {
 			if (!irq_chip) {
 				irq_chip = bank->irq_chip;
@@ -704,14 +741,33 @@ static void exynos_pinctrl_resume_bank(
 						+ bank->eint_offset);
 }
 
+static void exynosauto_pinctrl_resume_bank(struct samsung_pinctrl_drv_data *drvdata,
+					   struct samsung_pin_bank *bank)
+{
+	struct exynos_eint_gpio_save *save = bank->soc_priv;
+	void __iomem *regs = bank->eint_base;
+
+	pr_debug("%s:     con %#010x => %#010x\n", bank->name,
+		 readl(regs + bank->pctl_offset + bank->eint_con_offset), save->eint_con);
+	pr_debug("%s:    mask %#010x => %#010x\n", bank->name,
+		 readl(regs + bank->pctl_offset + bank->eint_mask_offset), save->eint_mask);
+
+	writel(save->eint_con, regs + bank->pctl_offset + bank->eint_con_offset);
+	writel(save->eint_mask, regs + bank->pctl_offset + bank->eint_mask_offset);
+}
+
 void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
 	int i;
 
 	for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
-		if (bank->eint_type == EINT_TYPE_GPIO)
-			exynos_pinctrl_resume_bank(drvdata, bank);
+		if (bank->eint_type == EINT_TYPE_GPIO) {
+			if (bank->eint_con_offset)
+				exynosauto_pinctrl_resume_bank(drvdata, bank);
+			else
+				exynos_pinctrl_resume_bank(drvdata, bank);
+		}
 }
 
 static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 79babbb39ced..362e99566919 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1106,6 +1106,9 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
 		bank->eint_type = bdata->eint_type;
 		bank->eint_mask = bdata->eint_mask;
 		bank->eint_offset = bdata->eint_offset;
+		bank->eint_con_offset = bdata->eint_con_offset;
+		bank->eint_mask_offset = bdata->eint_mask_offset;
+		bank->eint_pend_offset = bdata->eint_pend_offset;
 		bank->name = bdata->name;
 
 		raw_spin_lock_init(&bank->slock);
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 9b3db50adef3..789358bcd9c5 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -122,6 +122,9 @@ struct samsung_pin_bank_type {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @eint_con_offset: ExynosAuto SoC-specific EINT control register offset of bank.
+ * @eint_mask_offset: ExynosAuto SoC-specific EINT mask register offset of bank.
+ * @eint_pend_offset: ExynosAuto SoC-specific EINT pend register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  */
 struct samsung_pin_bank_data {
@@ -133,6 +136,9 @@ struct samsung_pin_bank_data {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	u32		eint_con_offset;
+	u32		eint_mask_offset;
+	u32		eint_pend_offset;
 	const char	*name;
 };
 
@@ -147,6 +153,9 @@ struct samsung_pin_bank_data {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @eint_con_offset: ExynosAuto SoC-specific EINT register or interrupt offset of bank.
+ * @eint_mask_offset: ExynosAuto SoC-specific EINT mask register offset of bank.
+ * @eint_pend_offset: ExynosAuto SoC-specific EINT pend register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  * @id: id of the bank, propagated to the pin range.
  * @pin_base: starting pin number of the bank.
@@ -170,6 +179,9 @@ struct samsung_pin_bank {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	u32		eint_con_offset;
+	u32		eint_mask_offset;
+	u32		eint_pend_offset;
 	const char	*name;
 	u32		id;
 
-- 
2.43.0



From will at kernel.org  Mon Dec 11 03:46:42 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 11:46:42 +0000
Subject: [PATCH 7/7] cpuidle/poll_state: replace cpu_relax with
 smp_cond_load_relaxed
In-Reply-To: <1700488898-12431-8-git-send-email-mihai.carabas@oracle.com>
References: <1700488898-12431-1-git-send-email-mihai.carabas@oracle.com>
 <1700488898-12431-8-git-send-email-mihai.carabas@oracle.com>
Message-ID: <20231211114642.GB24899@willie-the-truck>

On Mon, Nov 20, 2023 at 04:01:38PM +0200, Mihai Carabas wrote:
> cpu_relax on ARM64 does a simple "yield". Thus we replace it with
> smp_cond_load_relaxed which basically does a "wfe".
> 
> Suggested-by: Peter Zijlstra <peterz at infradead.org>
> Signed-off-by: Mihai Carabas <mihai.carabas at oracle.com>
> ---
>  drivers/cpuidle/poll_state.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpuidle/poll_state.c b/drivers/cpuidle/poll_state.c
> index 9b6d90a72601..440cd713e39a 100644
> --- a/drivers/cpuidle/poll_state.c
> +++ b/drivers/cpuidle/poll_state.c
> @@ -26,12 +26,16 @@ static int __cpuidle poll_idle(struct cpuidle_device *dev,
>  
>  		limit = cpuidle_poll_time(drv, dev);
>  
> -		while (!need_resched()) {
> -			cpu_relax();
> -			if (loop_count++ < POLL_IDLE_RELAX_COUNT)
> -				continue;
> -
> +		for (;;) {
>  			loop_count = 0;
> +
> +			smp_cond_load_relaxed(&current_thread_info()->flags,
> +					      (VAL & _TIF_NEED_RESCHED) ||
> +					      (loop_count++ >= POLL_IDLE_RELAX_COUNT));
> +
> +			if (loop_count < POLL_IDLE_RELAX_COUNT)
> +				break;
> +
>  			if (local_clock_noinstr() - time_start > limit) {
>  				dev->poll_time_limit = true;
>  				break;

Doesn't this make ARCH_HAS_CPU_RELAX a complete misnomer?

Will


From ryan.roberts at arm.com  Mon Dec 11 03:51:12 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 11 Dec 2023 11:51:12 +0000
Subject: [PATCH v9 00/10] Multi-size THP for anonymous memory
In-Reply-To: <20231207140502.e7dff5d1cfb195b1644b61a5@linux-foundation.org>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207140502.e7dff5d1cfb195b1644b61a5@linux-foundation.org>
Message-ID: <6cc1332d-6ad2-4642-84d1-6a2fcf70d534@arm.com>

On 07/12/2023 22:05, Andrew Morton wrote:
> On Thu,  7 Dec 2023 16:12:01 +0000 Ryan Roberts <ryan.roberts at arm.com> wrote:
> 
>> Hi All,
>>
>> This is v9 (and hopefully the last) of a series to implement multi-size THP
>> (mTHP) for anonymous memory (previously called "small-sized THP" and "large
>> anonymous folios").
> 
> A general point on the [0/N] intro.  Bear in mind that this is
> (intended to be) for ever.  Five years hence, people won't be
> interested in knowing which version the patchset was, in seeing what
> changed from the previous iteration, etc.  This is all important and
> useful info, of course.  But it's best suited for being below the
> "^---$" separator.
> 
> Also, those five-years-from-now people won't want to have to go click
> on some link to find the performance testing results and suchlike. 
> It's better to paste such important info right into their faces.

Sorry about this, Andrew - you've given me feedback on this before, and I've
been trying to improve this. I'm obviously not there yet. Will fix for next time.



From s-vadapalli at ti.com  Mon Dec 11 03:55:33 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 11 Dec 2023 17:25:33 +0530
Subject: [PATCH v3 0/2] Add PCIe Endpoint overlays for J721E and J721S2
Message-ID: <20231211115535.1264353-1-s-vadapalli@ti.com>

Hello,

This series adds device-tree overlays for enabling PCIe in Endpoint mode
of operation on J721E-EVM and J721S2-EVM.

NOTE: This series is based on linux-next tagged next-20231211.

v2:
https://lore.kernel.org/r/20231115085204.3578616-1-s-vadapalli at ti.com/
Changes since v2:
- Rebased series on linux-next tagged next-20231211.
- Collected Reviewed-by tag from:
  Ravi Gunasekaran <r-gunasekaran at ti.com>
- Updated Makefile based on Andrew's suggestion to build the DTBs
  corresponding to the overlays only with an OF_ALL_DTBS build config
  since the generated DTBs are not required except to ensure that the
  overlays apply on the base DTB.
  Reference:
  https://lore.kernel.org/r/20231128-csi_dts-v3-9-0bb11cfa9d43 at ti.com

v1:
https://lore.kernel.org/r/20231020113222.3161829-1-s-vadapalli at ti.com/
Changes since v1:
- Rebased series on linux-next tagged next-20231114.

Regards,
Siddharth.

Siddharth Vadapalli (2):
  arm64: dts: ti: k3-j721e-evm: Add overlay for PCIE0 Endpoint Mode
  arm64: dts: ti: k3-j721s2-evm: Add overlay for PCIE1 Endpoint Mode

 arch/arm64/boot/dts/ti/Makefile               | 10 +++-
 .../boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso    | 53 +++++++++++++++++++
 .../boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso   | 53 +++++++++++++++++++
 3 files changed, 115 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
 create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso

-- 
2.34.1



From s-vadapalli at ti.com  Mon Dec 11 03:55:34 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 11 Dec 2023 17:25:34 +0530
Subject: [PATCH v3 1/2] arm64: dts: ti: k3-j721e-evm: Add overlay for PCIE0 Endpoint Mode
In-Reply-To: <20231211115535.1264353-1-s-vadapalli@ti.com>
References: <20231211115535.1264353-1-s-vadapalli@ti.com>
Message-ID: <20231211115535.1264353-2-s-vadapalli@ti.com>

Add overlay to enable the PCIE0 instance of PCIe on J721E-EVM in
Endpoint mode of operation.

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
Reviewed-by: Ravi Gunasekaran <r-gunasekaran at ti.com>
---
 arch/arm64/boot/dts/ti/Makefile               |  6 ++-
 .../boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso    | 53 +++++++++++++++++++
 2 files changed, 58 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 1ac47876bc99..c6606b7678a3 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -67,6 +67,7 @@ k3-j721e-evm-dtbs := k3-j721e-common-proc-board.dtb k3-j721e-evm-quad-port-eth-e
 dtb-$(CONFIG_ARCH_K3) += k3-j721e-beagleboneai64.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-gesi-exp-board.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie0-ep.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-j721e-sk.dtb
 
 # Boards with J721s2 SoC
@@ -103,6 +104,8 @@ k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
 	k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
 k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
 	k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
+k3-j721e-evm-pcie0-ep-dtbs := k3-j721e-common-proc-board.dtb \
+	k3-j721e-evm-pcie0-ep.dtbo
 dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
 	k3-am625-beagleplay-csi2-tevi-ov5640.dtb \
 	k3-am625-sk-csi2-imx219.dtb \
@@ -113,7 +116,8 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
 	k3-am62a7-sk-csi2-imx219.dtb \
 	k3-am62a7-sk-csi2-ov5640.dtb \
 	k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb \
-	k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
+	k3-am642-tqma64xxl-mbax4xxl-wlan.dtb \
+	k3-j721e-evm-pcie0-ep.dtb
 
 # Enable support for device-tree overlays
 DTC_FLAGS_k3-am625-beagleplay += -@
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso b/arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
new file mode 100644
index 000000000000..0c82a13b65a4
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * DT Overlay for enabling PCIE0 instance in Endpoint Configuration with the
+ * J7 common processor board.
+ *
+ * J7 Common Processor Board Product Link: https://www.ti.com/tool/J721EXCPXEVM
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+#include "k3-pinctrl.h"
+
+/*
+ * Since Root Complex and Endpoint modes are mutually exclusive
+ * disable Root Complex mode.
+ */
+&pcie0_rc {
+	status = "disabled";
+};
+
+&cbass_main {
+	#address-cells = <2>;
+	#size-cells = <2>;
+	interrupt-parent = <&gic500>;
+
+	pcie0_ep: pcie-ep at 2900000 {
+		compatible = "ti,j721e-pcie-ep";
+		reg = <0x00 0x02900000 0x00 0x1000>,
+		      <0x00 0x02907000 0x00 0x400>,
+		      <0x00 0x0d000000 0x00 0x00800000>,
+		      <0x00 0x10000000 0x00 0x08000000>;
+		reg-names = "intd_cfg", "user_cfg", "reg", "mem";
+		interrupt-names = "link_state";
+		interrupts = <GIC_SPI 318 IRQ_TYPE_EDGE_RISING>;
+		ti,syscon-pcie-ctrl = <&scm_conf 0x4070>;
+		max-link-speed = <3>;
+		num-lanes = <1>;
+		power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
+		clocks = <&k3_clks 239 1>;
+		clock-names = "fck";
+		max-functions = /bits/ 8 <6>;
+		max-virtual-functions = /bits/ 8 <4 4 4 4 0 0>;
+		dma-coherent;
+		phys = <&serdes0_pcie_link>;
+		phy-names = "pcie-phy";
+	};
+};
-- 
2.34.1



From s-vadapalli at ti.com  Mon Dec 11 03:55:35 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 11 Dec 2023 17:25:35 +0530
Subject: [PATCH v3 2/2] arm64: dts: ti: k3-j721s2-evm: Add overlay for PCIE1 Endpoint Mode
In-Reply-To: <20231211115535.1264353-1-s-vadapalli@ti.com>
References: <20231211115535.1264353-1-s-vadapalli@ti.com>
Message-ID: <20231211115535.1264353-3-s-vadapalli@ti.com>

Add overlay to enable the PCIE1 instance of PCIe on J721S2-EVM in
Endpoint mode of operation.

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
Reviewed-by: Ravi Gunasekaran <r-gunasekaran at ti.com>
---
 arch/arm64/boot/dts/ti/Makefile               |  6 ++-
 .../boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso   | 53 +++++++++++++++++++
 2 files changed, 58 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index c6606b7678a3..52c1dc910308 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -76,6 +76,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
 k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
 
 # Boards with J784s4 SoC
 dtb-$(CONFIG_ARCH_K3) += k3-am69-sk.dtb
@@ -106,6 +107,8 @@ k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
 	k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
 k3-j721e-evm-pcie0-ep-dtbs := k3-j721e-common-proc-board.dtb \
 	k3-j721e-evm-pcie0-ep.dtbo
+k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
+	k3-j721s2-evm-pcie1-ep.dtbo
 dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
 	k3-am625-beagleplay-csi2-tevi-ov5640.dtb \
 	k3-am625-sk-csi2-imx219.dtb \
@@ -117,7 +120,8 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
 	k3-am62a7-sk-csi2-ov5640.dtb \
 	k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb \
 	k3-am642-tqma64xxl-mbax4xxl-wlan.dtb \
-	k3-j721e-evm-pcie0-ep.dtb
+	k3-j721e-evm-pcie0-ep.dtb \
+	k3-j721s2-evm-pcie1-ep.dtb
 
 # Enable support for device-tree overlays
 DTC_FLAGS_k3-am625-beagleplay += -@
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso b/arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso
new file mode 100644
index 000000000000..43568eb67d93
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * DT Overlay for enabling PCIE1 instance in Endpoint Configuration with the
+ * J7 common processor board.
+ *
+ * J7 Common Processor Board Product Link: https://www.ti.com/tool/J721EXCPXEVM
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+#include "k3-pinctrl.h"
+
+/*
+ * Since Root Complex and Endpoint modes are mutually exclusive
+ * disable Root Complex mode.
+ */
+&pcie1_rc {
+	status = "disabled";
+};
+
+&cbass_main {
+	#address-cells = <2>;
+	#size-cells = <2>;
+	interrupt-parent = <&gic500>;
+
+	pcie1_ep: pcie-ep at 2910000 {
+		compatible = "ti,j7200-pcie-ep", "ti,j721e-pcie-ep";
+		reg = <0x00 0x02910000 0x00 0x1000>,
+		      <0x00 0x02917000 0x00 0x400>,
+		      <0x00 0x0d800000 0x00 0x00800000>,
+		      <0x00 0x18000000 0x00 0x08000000>;
+		reg-names = "intd_cfg", "user_cfg", "reg", "mem";
+		interrupt-names = "link_state";
+		interrupts = <GIC_SPI 330 IRQ_TYPE_EDGE_RISING>;
+		ti,syscon-pcie-ctrl = <&scm_conf 0x074>;
+		max-link-speed = <3>;
+		num-lanes = <1>;
+		power-domains = <&k3_pds 276 TI_SCI_PD_EXCLUSIVE>;
+		clocks = <&k3_clks 276 41>;
+		clock-names = "fck";
+		max-functions = /bits/ 8 <6>;
+		max-virtual-functions = /bits/ 8 <4 4 4 4 0 0>;
+		dma-coherent;
+		phys = <&serdes0_pcie_link>;
+		phy-names = "pcie-phy";
+	};
+};
-- 
2.34.1



From s-vadapalli at ti.com  Mon Dec 11 04:02:27 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 11 Dec 2023 17:32:27 +0530
Subject: [PATCH v2 1/2] arm64: dts: ti: k3-j721e-evm: Add overlay for
 PCIE0 Endpoint Mode
In-Reply-To: <750c2b6b-8f24-4b86-996f-6f50cf46d81b@ti.com>
References: <20231115085204.3578616-1-s-vadapalli@ti.com>
 <20231115085204.3578616-2-s-vadapalli@ti.com>
 <c50f5dc2-8ab8-4213-a809-fcd4cd18589d@ti.com>
 <750c2b6b-8f24-4b86-996f-6f50cf46d81b@ti.com>
Message-ID: <4c033e0c-a453-4d30-814a-fda401ae82db@ti.com>



On 11/12/23 16:46, Siddharth Vadapalli wrote:
> Hello Andrew,
> 
> On 05/12/23 21:43, Andrew Davis wrote:
>> On 11/15/23 2:52 AM, Siddharth Vadapalli wrote:
>>> Add overlay to enable the PCIE0 instance of PCIe on J721E-EVM in
>>> Endpoint mode of operation.
>>>
>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
>>> ---
>>> ? arch/arm64/boot/dts/ti/Makefile?????????????? |? 3 ++
>>> ? .../boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso??? | 53 +++++++++++++++++++
>>> ? 2 files changed, 56 insertions(+)
>>> ? create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
>>> index 77a347f9f47d..5620db44d4dc 100644
>>> --- a/arch/arm64/boot/dts/ti/Makefile
>>> +++ b/arch/arm64/boot/dts/ti/Makefile
>>> @@ -66,6 +66,8 @@ dtb-$(CONFIG_ARCH_K3) += k3-j7200-evm.dtb
>>> ? k3-j721e-evm-dtbs := k3-j721e-common-proc-board.dtb
>>> k3-j721e-evm-quad-port-eth-exp.dtbo
>>> ? dtb-$(CONFIG_ARCH_K3) += k3-j721e-beagleboneai64.dtb
>>> ? dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm.dtb
>>> +k3-j721e-evm-pcie0-ep-dtbs := k3-j721e-evm.dtb k3-j721e-evm-pcie0-ep.dtbo
>>> +dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie0-ep.dtb
>>
>> Do you really need to produce this pre-combined DTB file? If you would rather
>> just the overlay produced which could be applied at load-time (I prefer this),
>> then you should do as Jai has done[0]. Add just the overlay, and test its
>> application using a dummy target.
> 
> Thank you for pointing it out. I will implement your suggestion and post the v3
> series.

I have posted the v3 series at:
https://lore.kernel.org/r/20231211115535.1264353-1-s-vadapalli at ti.com/

> 

-- 
Regards,
Siddharth.


From peter.griffin at linaro.org  Mon Dec 11 04:17:25 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 12:17:25 +0000
Subject: [PATCH v6 18/20] arm64: dts: exynos: google: Add initial Google
 gs101 SoC support
In-Reply-To: <8400d76b-2a04-4d60-ad6c-954dca07562f@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-19-peter.griffin@linaro.org> <8400d76b-2a04-4d60-ad6c-954dca07562f@linaro.org>
Message-ID: <CADrjBPotdY3guj_ZAx4pWqkkM_SDZCGRgRwJVJxM_x5BxcKSjA@mail.gmail.com>

Hi Krzysztof,

Thanks for the review.

On Sun, 10 Dec 2023 at 14:38, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 10/12/2023 00:31, Peter Griffin wrote:
> > Google gs101 SoC is a ARMv8 mobile SoC found in the Pixel 6
> > (oriole), Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
> > phones.
> >
> > It features:
> > * 4xA55 Little cluster
> > * 2xA76 Mid cluster
> > * 2xX1 Big cluster
> >
>
> ...
>
> > diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> > new file mode 100644
> > index 000000000000..68b7bc47c91b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
> > @@ -0,0 +1,33 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Pinctrl binding constants for GS101
> > + *
> > + * Copyright 2020-2023 Google LLC
> > + */
> > +
> > +#ifndef __DT_BINDINGS_PINCTRL_GS101_H__
> > +#define __DT_BINDINGS_PINCTRL_GS101_H__
>
> Header guards don't really match location.

Will fix.

>
> > +
> > +#define GS101_PIN_PULL_NONE          0
> > +#define GS101_PIN_PULL_DOWN          1
> > +#define GS101_PIN_PULL_UP            3
> > +
> > +/* Pin function in power down mode */
> > +#define GS101_PIN_PDN_OUT0           0
> > +#define GS101_PIN_PDN_OUT1           1
> > +#define GS101_PIN_PDN_INPUT          2
> > +#define GS101_PIN_PDN_PREV           3
> > +
> > +/* GS101 drive strengths */
> > +#define GS101_PIN_DRV_2_5_MA         0
> > +#define GS101_PIN_DRV_5_MA           1
> > +#define GS101_PIN_DRV_7_5_MA         2
> > +#define GS101_PIN_DRV_10_MA          3
> > +
> > +#define GS101_PIN_FUNC_INPUT         0
> > +#define GS101_PIN_FUNC_OUTPUT                1
> > +#define GS101_PIN_FUNC_2             2
> > +#define GS101_PIN_FUNC_3             3
> > +#define GS101_PIN_FUNC_EINT          0xf
> > +
> > +#endif /* __DT_BINDINGS_PINCTRL_GS101_H__ */
> > diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> > new file mode 100644
> > index 000000000000..60e112d25246
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> > @@ -0,0 +1,476 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * GS101 SoC
> > + *
> > + * Copyright 2019-2023 Google LLC
> > + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
> > + */
> > +
> > +#include <dt-bindings/clock/google,gs101.h>
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/soc/samsung,exynos-usi.h>
> > +
> > +/ {
> > +     compatible = "google,gs101";
> > +     #address-cells = <2>;
> > +     #size-cells = <1>;
> > +
> > +     interrupt-parent = <&gic>;
> > +
> > +     aliases {
> > +             pinctrl0 = &pinctrl_gpio_alive;
> > +             pinctrl1 = &pinctrl_far_alive;
> > +             pinctrl2 = &pinctrl_gsacore;
> > +             pinctrl3 = &pinctrl_gsactrl;
> > +             pinctrl4 = &pinctrl_peric0;
> > +             pinctrl5 = &pinctrl_peric1;
> > +             pinctrl6 = &pinctrl_hsi1;
> > +             pinctrl7 = &pinctrl_hsi2;
> > +     };
> > +
> > +     pmu-0 {
> > +             compatible = "arm,cortex-a55-pmu";
> > +             interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
> > +     };
> > +
> > +     pmu-1 {
> > +             compatible = "arm,cortex-a76-pmu";
> > +             interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
> > +     };
> > +
> > +     pmu-2 {
> > +             compatible = "arm,cortex-x1-pmu";
> > +             interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster2>;
> > +     };
> > +
> > +     pmu-3 {
> > +             compatible = "arm,dsu-pmu";
> > +             interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH 0>;
> > +             cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
> > +                    <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
> > +     };
>
> Keep alphabetical order of top-level nodes. pmu should be before psci

Will fix

>
> > +
> > +     /* TODO replace with CCF clock */
> > +     dummy_clk: oscillator {
>
> clock-3

Will fix

>
> > +             compatible = "fixed-clock";
> > +             #clock-cells = <0>;
> > +             clock-frequency = <12345>;
> > +             clock-output-names = "pclk";
> > +     };
> > +
> > +     cpus {
> > +             #address-cells = <1>;
> > +             #size-cells = <0>;
> > +
> > +             cpu-map {
> > +                     cluster0 {
> > +                             core0 {
> > +                                     cpu = <&cpu0>;
> > +                             };
> > +                             core1 {
> > +                                     cpu = <&cpu1>;
> > +                             };
> > +                             core2 {
> > +                                     cpu = <&cpu2>;
> > +                             };
> > +                             core3 {
> > +                                     cpu = <&cpu3>;
> > +                             };
> > +                     };
> > +
> > +                     cluster1 {
> > +                             core0 {
> > +                                     cpu = <&cpu4>;
> > +                             };
> > +                             core1 {
> > +                                     cpu = <&cpu5>;
> > +                             };
> > +                     };
> > +
> > +                     cluster2 {
> > +                             core0 {
> > +                                     cpu = <&cpu6>;
> > +                             };
> > +                             core1 {
> > +                                     cpu = <&cpu7>;
> > +                             };
> > +                     };
> > +             };
>
> ...
>
> > +
> > +     /* ect node is required to be present by bootloader */
> > +     ect {
> > +     };
>
> alphabetical order

Will fix

>
> > +
> > +     ext_24_5m: clock-1 {
> > +             compatible = "fixed-clock";
> > +             #clock-cells = <0>;
> > +             clock-output-names = "oscclk";
> > +     };
> > +
> > +     ext_200m: clock-2 {
> > +             compatible = "fixed-clock";
> > +             #clock-cells = <0>;
> > +             clock-output-names = "ext-200m";
> > +     };
> > +
> > +     psci {
> > +             compatible = "arm,psci-1.0";
> > +             method = "smc";
> > +     };
> > +
> > +     reserved_memory: reserved-memory {
> > +             #address-cells = <2>;
> > +             #size-cells = <1>;
> > +             ranges;
> > +
> > +             gsa_reserved_protected: gsa at 90200000 {
> > +                     reg = <0x0 0x90200000 0x400000>;
> > +                     no-map;
> > +             };
> > +
> > +             tpu_fw_reserved: tpu-fw at 93000000 {
> > +                     reg = <0x0 0x93000000 0x1000000>;
> > +                     no-map;
> > +             };
> > +
> > +             aoc_reserve: aoc at 94000000 {
> > +                     reg = <0x0 0x94000000 0x03000000>;
> > +                     no-map;
> > +             };
> > +
> > +             abl_reserved: abl at f8800000 {
> > +                     reg = <0x0 0xf8800000 0x02000000>;
> > +                     no-map;
> > +             };
> > +
> > +             dss_log_reserved: dss-log-reserved at fd3f0000 {
> > +                     reg = <0x0 0xfd3f0000 0x0000e000>;
> > +                     no-map;
> > +             };
> > +
> > +             debug_kinfo_reserved: debug-kinfo-reserved at fd3fe000 {
> > +                     reg = <0x0 0xfd3fe000 0x00001000>;
> > +                     no-map;
> > +             };
> > +
> > +             bldr_log_reserved: bldr-log-reserved at fd800000 {
> > +                     reg = <0x0 0xfd800000 0x00100000>;
> > +                     no-map;
> > +             };
> > +
> > +             bldr_log_hist_reserved: bldr-log-hist-reserved at fd900000 {
> > +                     reg = <0x0 0xfd900000 0x00002000>;
> > +                     no-map;
> > +             };
> > +     };
> > +
> > +     timer {
>
> alphabetical order, so this goes to the end

Will fix

>
> > +             compatible = "arm,armv8-timer";
> > +             interrupts =
> > +                <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> > +                <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> > +                <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> > +                <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>;
> > +             clock-frequency = <24576000>;
>
> I don't remember if you already got Marc's wrath, so just in case: are
> you sure it is needed?
>
> Anyway, this is board specific, not SoC.

Will double check and if required move to the board file.

>
> > +     };
> > +
> > +     soc: soc at 0 {
> > +             compatible = "simple-bus";
> > +             #address-cells = <1>;
> > +             #size-cells = <1>;
> > +             ranges = <0x0 0x0 0x0 0x40000000>;
> > +
> > +             cmu_misc: clock-controller at 10010000 {
> > +                     compatible = "google,gs101-cmu-misc";
> > +                     reg = <0x10010000 0x8000>;
> > +                     #clock-cells = <1>;
> > +                     clocks =  <&cmu_top CLK_DOUT_CMU_MISC_BUS>,
>
> One space after =

Will fix.

>
> > +                               <&cmu_top CLK_DOUT_CMU_MISC_SSS>;
> > +                     clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
> > +             };
> > +
> > +             watchdog_cl0: watchdog at 10060000 {
> > +                     compatible = "google,gs101-wdt";
> > +                     reg = <0x10060000 0x100>;
> > +                     interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH 0>;
> > +                     clocks =
> > +                       <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0_PCLK>,
>
> Join lines (clocks = <foo bar>). Same in other places.

Will fix.

>
> > +                       <&ext_24_5m>;
> > +                     clock-names = "watchdog", "watchdog_src";
> > +                     samsung,syscon-phandle = <&pmu_system_controller>;
> > +                     samsung,cluster-index = <0>;
> > +                     status = "disabled";
> > +             };
> > +
> > +             watchdog_cl1: watchdog at 10070000 {
> > +                     compatible = "google,gs101-wdt";
> > +                     reg = <0x10070000 0x100>;
> > +                     interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH 0>;
> > +                     clocks =
> > +                       <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1_PCLK>,
> > +                       <&ext_24_5m>;
> > +                     clock-names = "watchdog", "watchdog_src";
> > +                     samsung,syscon-phandle = <&pmu_system_controller>;
> > +                     samsung,cluster-index = <1>;
> > +                     status = "disabled";
> > +             };
> > +
> > +             gic: interrupt-controller at 10400000 {
> > +                     compatible = "arm,gic-v3";
> > +                     #interrupt-cells = <4>;
> > +                     interrupt-controller;
> > +                     reg = <0x10400000 0x10000>, /* GICD */
> > +                           <0x10440000 0x100000>;/* GICR * 8 */
> > +                     interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
> > +
> > +                     ppi-partitions {
> > +                             ppi_cluster0: interrupt-partition-0 {
> > +                                     affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
> > +                             };
> > +
> > +                             ppi_cluster1: interrupt-partition-1 {
> > +                                     affinity = <&cpu4 &cpu5>;
> > +                             };
> > +
> > +                             ppi_cluster2: interrupt-partition-2 {
> > +                                     affinity = <&cpu6 &cpu7>;
> > +                             };
> > +                     };
> > +             };
> > +
> > +             sysreg_peric0: syscon at 10820000 {
> > +                     compatible = "google,gs101-peric0-sysreg", "syscon";
> > +                     reg = <0x10820000 0x10000>;
> > +             };
> > +
> > +             pinctrl_peric0: pinctrl at 10840000 {
> > +                     compatible = "google,gs101-pinctrl";
> > +                     reg = <0x10840000 0x00001000>;
> > +                     interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> > +             };
> > +
> > +             usi_uart: usi at 10a000c0 {
> > +                     compatible = "google,gs101-usi",
> > +                                  "samsung,exynos850-usi";
> > +                     reg = <0x10a000c0 0x20>;
> > +                     samsung,sysreg = <&sysreg_peric0 0x1020>;
> > +                     samsung,mode = <USI_V2_UART>;
>
> vendor properties go to the end, after standard properties, before status.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst?h=dt/next&id=0d3a771610d0e155c9aa305f142f84dda5030fae#n122

Will fix, and thanks for the pointer to the documentation about this.
Much appreciated.

>
> > +                     #address-cells = <1>;
> > +                     #size-cells = <1>;
> > +                     ranges;
> > +                     clocks = <&dummy_clk>, <&dummy_clk>;
> > +                     clock-names = "pclk", "ipclk";
> > +                     status = "disabled";
> > +
> > +                     serial_0: serial at 10a00000 {
> > +                             compatible = "google,gs101-uart";
> > +                             reg = <0x10a00000 0xc0>;
> > +                             reg-io-width = <4>;
> > +                             samsung,uart-fifosize = <256>;
>
> Ditto

Will fix.

>
> > +                             interrupts = <GIC_SPI 634
> > +                                           IRQ_TYPE_LEVEL_HIGH 0>;
> > +                             clocks = <&dummy_clk 0>, <&dummy_clk 0>;
> > +                             clock-names = "uart", "clk_uart_baud0";
> > +                             status = "disabled";
> > +                     };
> > +             };
>
>
regards,

Peter


From u.kleine-koenig at pengutronix.de  Mon Dec 11 04:18:07 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 11 Dec 2023 13:18:07 +0100
Subject: [PATCH v4 000/115] pwm: Fix lifetime issues for pwm_chips
In-Reply-To: <ZXbzcFTnDTKoZAta@orome.fritz.box>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
 <ZXM4CdJxg-XrYhkn@orome.fritz.box>
 <20231208185033.e6ty2cajcfle6dgk@pengutronix.de>
 <ZXbzcFTnDTKoZAta@orome.fritz.box>
Message-ID: <20231211121807.zzlgf3alcoo6lrw7@pengutronix.de>

Hello Thierry,

On Mon, Dec 11, 2023 at 12:33:04PM +0100, Thierry Reding wrote:
> On Fri, Dec 08, 2023 at 07:50:33PM +0100, Uwe Kleine-K?nig wrote:
> > The TL;DR; is essentially what I already wrote in my last reply to Bart
> > in the v3 thread[1]:
> > 
> >  - My approach needs more changes to the individual drivers (which I
> >    don't consider a relevant disadvantage given that the resulting code
> >    is better);
> >  - My approach works with less pointer dereferences which IMHO also
> >    simplifies understanding the code as all relevant data is in a single
> >    place.
> >  - My approach has a weaker separation between the core and the lowlevel
> >    drivers. That's ok in my book given that this doesn't complicate the
> >    lowlevel drivers and that hiding details considerably better doesn't
> >    work anyhow (see the drivers that need internal.h in your patch).
> > 
> > For me the single allocation issue is only an added bonus. The relevant
> > advantage of my approach is that the code is easier and (probably) more
> > efficient.
> 
> I happen to disagree. I think adding pwmchip_alloc() makes things much
> more complicated for low level drivers.

Looking at e.g.
https://lore.kernel.org/linux-pwm/2dda818b8bbbe8ba4b9df5ab54f960ff4a4f1ab5.1701860672.git.u.kleine-koenig at pengutronix.de/
I wonder where you see "much more complication". OK, there are two
pointers now for chip and private data, but I'd call that at most a
"mild" complication[1] which is more than balanced out by the
simplifications in the remaining parts of that patch.

Best regards
Uwe

[1] I'm not sure I'd refuse someone suggesting the following patch on
    top of today's next:

	diff --git a/drivers/pwm/pwm-microchip-core.c b/drivers/pwm/pwm-microchip-core.c
	index c0c53968f3e9..d32e65914599 100644
	--- a/drivers/pwm/pwm-microchip-core.c
	+++ b/drivers/pwm/pwm-microchip-core.c
	@@ -448,12 +448,14 @@ MODULE_DEVICE_TABLE(of, mchp_core_of_match);
	 static int mchp_core_pwm_probe(struct platform_device *pdev)
	 {
		struct mchp_core_pwm_chip *mchp_core_pwm;
	+	struct pwm_chip *chip;
		struct resource *regs;
		int ret;
	 
		mchp_core_pwm = devm_kzalloc(&pdev->dev, sizeof(*mchp_core_pwm), GFP_KERNEL);
		if (!mchp_core_pwm)
			return -ENOMEM;
	+	chip = &mchp_core_pwm->chip;
	 
		mchp_core_pwm->base = devm_platform_get_and_ioremap_resource(pdev, 0, &regs);
		if (IS_ERR(mchp_core_pwm->base))
	@@ -470,9 +472,9 @@ static int mchp_core_pwm_probe(struct platform_device *pdev)
	 
		mutex_init(&mchp_core_pwm->lock);
	 
	-	mchp_core_pwm->chip.dev = &pdev->dev;
	-	mchp_core_pwm->chip.ops = &mchp_core_pwm_ops;
	-	mchp_core_pwm->chip.npwm = 16;
	+	chip->dev = &pdev->dev;
	+	chip->ops = &mchp_core_pwm_ops;
	+	chip->npwm = 16;
	 
		mchp_core_pwm->channel_enabled = readb_relaxed(mchp_core_pwm->base + MCHPCOREPWM_EN(0));
		mchp_core_pwm->channel_enabled |=
	@@ -485,7 +487,7 @@ static int mchp_core_pwm_probe(struct platform_device *pdev)
		writel_relaxed(1U, mchp_core_pwm->base + MCHPCOREPWM_SYNC_UPD);
		mchp_core_pwm->update_timestamp = ktime_get();
	 
	-	ret = devm_pwmchip_add(&pdev->dev, &mchp_core_pwm->chip);
	+	ret = devm_pwmchip_add(&pdev->dev, chip);
		if (ret)
			return dev_err_probe(&pdev->dev, ret, "Failed to add pwmchip\n");
 
    With that applied before the above mentioned patch there is no
    complication at all in my eyes.


-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/dac7004b/attachment.sig>

From mpe at ellerman.id.au  Mon Dec 11 04:23:35 2023
From: mpe at ellerman.id.au (Michael Ellerman)
Date: Mon, 11 Dec 2023 23:23:35 +1100
Subject: [RFC PATCH 10/12] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-11-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-11-samuel.holland@sifive.com>
Message-ID: <87h6kpdj20.fsf@mail.lhotse>

Hi Samuel,

Thanks for trying to clean all this up.

One problem below.

Samuel Holland <samuel.holland at sifive.com> writes:
> Now that all previously-supported architectures select
> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
> of the existing list of architectures. It can also take advantage of the
> common kernel-mode FPU API and method of adjusting CFLAGS.
>
> Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
...
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
> index 4ae4720535a5..b64f917174ca 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
> @@ -87,20 +78,9 @@ void dc_fpu_begin(const char *function_name, const int line)
>  	WARN_ON_ONCE(!in_task());
>  	preempt_disable();
>  	depth = __this_cpu_inc_return(fpu_recursion_depth);
> -
>  	if (depth == 1) {
> -#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
> +		BUG_ON(!kernel_fpu_available());
>  		kernel_fpu_begin();
> -#elif defined(CONFIG_PPC64)
> -		if (cpu_has_feature(CPU_FTR_VSX_COMP))
> -			enable_kernel_vsx();
> -		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
> -			enable_kernel_altivec();
 
Note altivec.

> -		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
> -			enable_kernel_fp();
> -#elif defined(CONFIG_ARM64)
> -		kernel_neon_begin();
> -#endif
>  	}
>  
>  	TRACE_DCN_FPU(true, function_name, line, depth);
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> index ea7d60f9a9b4..5aad0f572ba3 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> @@ -25,40 +25,8 @@
>  # It provides the general basic services required by other DAL
>  # subcomponents.
>  
> -ifdef CONFIG_X86
> -dml_ccflags-$(CONFIG_CC_IS_GCC) := -mhard-float
> -dml_ccflags := $(dml_ccflags-y) -msse
> -endif
> -
> -ifdef CONFIG_PPC64
> -dml_ccflags := -mhard-float -maltivec
> -endif

And altivec is enabled in the flags there.

That doesn't match your implementation for powerpc in patch 7, which
only deals with float.

I suspect the AMD driver actually doesn't need altivec enabled, but I
don't know that for sure. It compiles without it, but I don't have a GPU
to actually test. I've added Timothy on Cc who added the support for
powerpc to the driver originally, hopefully he has a test system.

Anyway if that's true that it doesn't need altivec we should probably do
a lead-up patch that drops altivec from the AMD driver explicitly, eg.
as below.

cheers


diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
index 4ae4720535a5..0de16796466b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
@@ -92,11 +92,7 @@ void dc_fpu_begin(const char *function_name, const int line)
 #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 		kernel_fpu_begin();
 #elif defined(CONFIG_PPC64)
-		if (cpu_has_feature(CPU_FTR_VSX_COMP))
-			enable_kernel_vsx();
-		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
-			enable_kernel_altivec();
-		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
+		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
 			enable_kernel_fp();
 #elif defined(CONFIG_ARM64)
 		kernel_neon_begin();
@@ -125,11 +121,7 @@ void dc_fpu_end(const char *function_name, const int line)
 #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 		kernel_fpu_end();
 #elif defined(CONFIG_PPC64)
-		if (cpu_has_feature(CPU_FTR_VSX_COMP))
-			disable_kernel_vsx();
-		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
-			disable_kernel_altivec();
-		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
+		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
 			disable_kernel_fp();
 #elif defined(CONFIG_ARM64)
 		kernel_neon_end();
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 6042a5a6a44f..554c39024a40 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -31,7 +31,7 @@ dml_ccflags := $(dml_ccflags-y) -msse
 endif
 
 ifdef CONFIG_PPC64
-dml_ccflags := -mhard-float -maltivec
+dml_ccflags := -mhard-float
 endif
 
 ifdef CONFIG_ARM64
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index acff3449b8d7..7b51364084b5 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -30,7 +30,7 @@ dml2_ccflags := $(dml2_ccflags-y) -msse
 endif
 
 ifdef CONFIG_PPC64
-dml2_ccflags := -mhard-float -maltivec
+dml2_ccflags := -mhard-float
 endif
 
 ifdef CONFIG_ARM64


From will at kernel.org  Mon Dec 11 04:24:16 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 12:24:16 +0000
Subject: [PATCH v3 02/13] arm64: cpufeatures: Correctly handle signed
 values
In-Reply-To: <20231127114559.990314-3-maz@kernel.org>
References: <20231127114559.990314-1-maz@kernel.org>
 <20231127114559.990314-3-maz@kernel.org>
Message-ID: <20231211122416.GA25277@willie-the-truck>

On Mon, Nov 27, 2023 at 11:45:48AM +0000, Marc Zyngier wrote:
> Although we've had signed values for some features such as PMUv3
> and FP, the code that handles the comparaison with some limit
> has a couple of annoying issues:
> 
> - the min_field_value is always unsigned, meaning that we cannot
>   easily compare it with a negative value
> 
> - it is not possible to have a range of values, let alone a range
>   of negative values
> 
> Fix this by:
> 
> - adding an upper limit to the comparison, defaulting to all bits
>   being set to the maximum positive value
> 
> - ensuring that the signess of the min and max values are taken into
>   account
> 
> A ARM64_CPUID_FIELDS_NEG() macro is provided for signed features, but
> nothing is using it yet.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm64/include/asm/cpufeature.h |  1 +
>  arch/arm64/kernel/cpufeature.c      | 65 +++++++++++++++++++++++++----
>  2 files changed, 57 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index f6d416fe49b0..5f3f62efebd5 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -363,6 +363,7 @@ struct arm64_cpu_capabilities {
>  			u8 field_pos;
>  			u8 field_width;
>  			u8 min_field_value;
> +			u8 max_field_value;
>  			u8 hwcap_type;
>  			bool sign;
>  			unsigned long hwcap;
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 646591c67e7a..bc8787f28ffd 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -140,12 +140,42 @@ void dump_cpu_features(void)
>  	pr_emerg("0x%*pb\n", ARM64_NCAPS, &system_cpucaps);
>  }
>  
> +#define __ARM64_MAX_POSITIVE(reg, field)				\
> +		((reg##_##field##_SIGNED ?				\
> +		  BIT(reg##_##field##_WIDTH - 1) :			\
> +		  BIT(reg##_##field##_WIDTH)) - 1)
> +
> +#define __ARM64_MIN_NEGATIVE(reg, field)  BIT(reg##_##field##_WIDTH - 1)

I'm struggling to grok these two macros. For example, let's say I have a
4-bit signed field. In that case, the maximum positive value is 7 (0b0111)
and the minimum negative value is -8 (0b1000), but the macros above appear
to give 0b1000 for both.

Will


From heiko at sntech.de  Mon Dec 11 04:27:36 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 11 Dec 2023 13:27:36 +0100
Subject: [PATCH v3 4/5] dt-bindings: arm: rockchip: Add Cool Pi CM5 EVB
In-Reply-To: <20231211105023.1779786-1-andyshrk@163.com>
References: <20231211104915.1779476-1-andyshrk@163.com>
 <20231211105023.1779786-1-andyshrk@163.com>
Message-ID: <3203387.BEx9A2HvPv@diego>

Hi Andy,

Am Montag, 11. Dezember 2023, 11:50:23 CET schrieb Andy Yan:
> Add Cool Pi CM5 EVB, a board powered by RK3588
> 
> Signed-off-by: Andy Yan <andyshrk at 163.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

I just realized your mention of this being a som + baseboard combination
in the previous version.

In that case the compatible really should reflect that.

      - description: Cool Pi Compute Module 5(CM5) EVB
        items:
          - const: coolpi,pi-cm5-evb
          - const: coolpi,pi-cm5
          - const: rockchip,rk3588

Similar to how all the other som + baseboard combinations do it
(Edgeble neural modules, engicam px30, Thebroma-SoMs).


Thanks
Heiko

> ---
> 
> (no changes since v2)
> 
> Changes in v2:
> - change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"
> 
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 11d03035f3db..4da83bbd642a 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -95,6 +95,11 @@ properties:
>            - const: chipspark,rayeager-px2
>            - const: rockchip,rk3066a
>  
> +      - description: Cool Pi Compute Module 5(CM5) EVB
> +        items:
> +          - const: coolpi,pi-cm5-evb
> +          - const: rockchip,rk3588
> +
>        - description: Cool Pi 4 Model B
>          items:
>            - const: coolpi,pi-4b
> 






From heiko at sntech.de  Mon Dec 11 04:33:00 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 11 Dec 2023 13:33:00 +0100
Subject: [PATCH v3 5/5] arm64: dts: rockchip: Add support for rk3588 based board
 Cool Pi CM5 EVB
In-Reply-To: <20231211105043.1779852-1-andyshrk@163.com>
References: <20231211104915.1779476-1-andyshrk@163.com>
 <20231211105043.1779852-1-andyshrk@163.com>
Message-ID: <2215635.TLkxdtWsSY@diego>

Am Montag, 11. Dezember 2023, 11:50:43 CET schrieb Andy Yan:
> Cool Pi CM5 EVB is a board based on rk3588.
> 
> Specification:
> - Rockchip RK3588
> - LPDDR4 2/4/8/16 GB
> - TF scard slot
> - eMMC 8/32/64/128 GB module
> - Gigabit ethernet x 1 with PHY YT8531
> - Gigabit ethernet x 1 drived by PCIE with YT6801S
> - HDMI Type A out x 2
> - HDMI Type D in x 1
> - USB 2.0 Host x 2
> - USB 3.0 OTG x 1
> - USB 3.0 Host x 1
> - PCIE M.2 E Key for Wireless connection
> - PCIE M.2 M Key for NVME connection
> - 40 pin header
> 
> Signed-off-by: Andy Yan <andyshrk at 163.com>

In the overall scheme of things I would really like to see the correct
split between SoM dtsi and baseboard dts, like the other SoMs do.

You said you wanted to wait for an actual second baseboard to come along
before doing this and I guess for "yet another som" we can try going that
route.

But please state this explicitly in the commit message that this is a
baseboard+som combination, so the next one working here should do
that split.

An update is needed anyway, cause the compatible thing mentioned in 
the binding.


Thanks
Heiko

> ---
> 
> Changes in v3:
> - drop ununnecessary property status = "okay" for backlight
> - reorder some nodes alphabetical
> - drop ununnecessary blank line
> 
> Changes in v2:
> - change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"
> 
>  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>  .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 879 ++++++++++++++++++
>  2 files changed, 880 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
> 
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index e59682691eb0..9be8e4830158 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-odroid-m1.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-radxa-e25.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-roc-pc.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-coolpi-cm5-evb.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-io.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6b-io.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-evb1-v10.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
> new file mode 100644
> index 000000000000..ccf17185dc10
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
> @@ -0,0 +1,879 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/pwm/pwm.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include "rk3588.dtsi"
> +
> +/ {
> +	model = "RK3588 CoolPi CM5 EVB";
> +	compatible = "coolpi,pi-cm5-evb", "rockchip,rk3588";
> +
> +	aliases {
> +		mmc0 = &sdhci;
> +		mmc1 = &sdio;
> +		mmc2 = &sdmmc;
> +		serial2 = &uart2;
> +	};
> +
> +	analog-sound {
> +		compatible = "audio-graph-card";
> +		label = "rk3588-es8316";
> +
> +		widgets = "Microphone", "Mic Jack",
> +			  "Headphone", "Headphones";
> +
> +		routing = "MIC2", "Mic Jack",
> +			  "Headphones", "HPOL",
> +			  "Headphones", "HPOR";
> +
> +		dais = <&i2s0_8ch_p0>;
> +	};
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		power-supply = <&vcc12v_dcin>;
> +		pwms = <&pwm2 0 25000 0>;
> +		enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bl_en>;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial2:1500000n8";
> +	};
> +
> +	leds: leds {
> +		compatible = "gpio-leds";
> +
> +		led: led-green {
> +			color = <LED_COLOR_ID_GREEN>;
> +			function = LED_FUNCTION_STATUS;
> +			gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
> +			linux,default-trigger = "heartbeat";
> +		};
> +	};
> +
> +	vcc12v_dcin: vcc12v-dcin-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc12v_dcin";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <12000000>;
> +		regulator-max-microvolt = <12000000>;
> +	};
> +
> +	vcc5v0_sys: vcc5v0-sys-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc5v0_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc12v_dcin>;
> +	};
> +
> +	vcc3v3_sys: vcc3v3-sys-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc3v3_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc12v_dcin>;
> +	};
> +
> +	vcc3v3_lcd: vcc3v3-lcd-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc3v3_lcd";
> +		enable-active-high;
> +		gpio = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&lcdpwr_en>;
> +		vin-supply = <&vcc3v3_sys>;
> +	};
> +
> +	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "avdd0v85_pcie20";
> +		regulator-boot-on;
> +		regulator-always-on;
> +		regulator-min-microvolt = <850000>;
> +		regulator-max-microvolt = <850000>;
> +		vin-supply = <&vdd_0v85_s0>;
> +	};
> +
> +	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "avdd1v8_pcie20";
> +		regulator-boot-on;
> +		regulator-always-on;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		vin-supply = <&avcc_1v8_s0>;
> +	};
> +
> +	avdd0v75_pcie30: avdd0v75-pcie30-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "avdd0v75_pcie30";
> +		regulator-boot-on;
> +		regulator-always-on;
> +		regulator-min-microvolt = <750000>;
> +		regulator-max-microvolt = <750000>;
> +		vin-supply = <&avdd_0v75_s0>;
> +	};
> +
> +	pcie30_avdd1v8: avdd1v8-pcie30-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pcie30_avdd1v8";
> +		regulator-boot-on;
> +		regulator-always-on;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		vin-supply = <&avcc_1v8_s0>;
> +	};
> +
> +	vcc5v0_host: vcc5v0-host-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc5v0_host";
> +		regulator-boot-on;
> +		regulator-always-on;
> +		enable-active-high;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		gpio = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_host1_en>;
> +		vin-supply = <&vcc5v0_sys>;
> +	};
> +
> +	vcc5v0_otg: vcc5v0-otg-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc5v0_otg";
> +		regulator-boot-on;
> +		regulator-always-on;
> +		enable-active-high;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&typec5v_pwren>;
> +		vin-supply = <&vcc5v0_sys>;
> +	};
> +
> +	vcc_mipidphy0: vcc-mipi-dphy0-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_mipidphy0";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-boot-on;
> +		regulator-always-on;
> +		enable-active-high;
> +		gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&vcc5v0_sys>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&cam_en>;
> +	};
> +};
> +
> +&combphy0_ps {
> +	status = "okay";
> +};
> +
> +&combphy1_ps {
> +	status = "okay";
> +};
> +
> +&combphy2_psu {
> +	status = "okay";
> +};
> +
> +&cpu_b0 {
> +	cpu-supply = <&vdd_cpu_big0_s0>;
> +};
> +
> +&cpu_b1 {
> +	cpu-supply = <&vdd_cpu_big0_s0>;
> +};
> +
> +&cpu_b2 {
> +	cpu-supply = <&vdd_cpu_big1_s0>;
> +};
> +
> +&cpu_b3 {
> +	cpu-supply = <&vdd_cpu_big1_s0>;
> +};
> +
> +&cpu_l0 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l1 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l2 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l3 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&gmac0 {
> +	clock_in_out = "output";
> +	phy-handle = <&rgmii_phy>;
> +	phy-mode = "rgmii-rxid";
> +	pinctrl-0 = <&gmac0_miim
> +		     &gmac0_tx_bus2
> +		     &gmac0_rx_bus2
> +		     &gmac0_rgmii_clk
> +		     &gmac0_rgmii_bus>;
> +	pinctrl-names = "default";
> +	rx_delay = <0x00>;
> +	tx_delay = <0x43>;
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	pinctrl-0 = <&i2c0m2_xfer>;
> +	status = "okay";
> +
> +	vdd_cpu_big0_s0: regulator at 42 {
> +		compatible = "rockchip,rk8602";
> +		reg = <0x42>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu_big0_s0";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <1050000>;
> +		regulator-ramp-delay = <2300>;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vdd_cpu_big1_s0: regulator at 43 {
> +		compatible = "rockchip,rk8603", "rockchip,rk8602";
> +		reg = <0x43>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu_big1_s0";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <1050000>;
> +		regulator-ramp-delay = <2300>;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&i2c2 {
> +	status = "okay";
> +
> +	vdd_npu_s0: regulator at 42 {
> +		compatible = "rockchip,rk8602";
> +		reg = <0x42>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_npu_s0";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <950000>;
> +		regulator-ramp-delay = <2300>;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&i2c6 {
> +	status = "okay";
> +
> +	hym8563: rtc at 51 {
> +		compatible = "haoyu,hym8563";
> +		reg = <0x51>;
> +		#clock-cells = <0>;
> +		clock-frequency = <32768>;
> +		clock-output-names = "hym8563";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&hym8563_int>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PD4 IRQ_TYPE_LEVEL_LOW>;
> +		wakeup-source;
> +	};
> +};
> +
> +&i2c7 {
> +	pinctrl-0 = <&i2c7m0_xfer>;
> +	status = "okay";
> +
> +	es8316: audio-codec at 11 {
> +		compatible = "everest,es8316";
> +		reg = <0x11>;
> +		clocks = <&cru I2S0_8CH_MCLKOUT>;
> +		clock-names = "mclk";
> +		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
> +		assigned-clock-rates = <12288000>;
> +		#sound-dai-cells = <0>;
> +
> +		port {
> +			es8316_p0_0: endpoint {
> +				remote-endpoint = <&i2s0_8ch_p0_0>;
> +			};
> +		};
> +	};
> +};
> +
> +&i2s0_8ch {
> +	pinctrl-0 = <&i2s0_lrck
> +		     &i2s0_mclk
> +		     &i2s0_sclk
> +		     &i2s0_sdi0
> +		     &i2s0_sdo0>;
> +	status = "okay";
> +
> +	i2s0_8ch_p0: port {
> +		i2s0_8ch_p0_0: endpoint {
> +			dai-format = "i2s";
> +			mclk-fs = <256>;
> +			remote-endpoint = <&es8316_p0_0>;
> +		};
> +	};
> +};
> +
> +&mdio0 {
> +	rgmii_phy: ethernet-phy at 1 {
> +		/* YT8531C/H */
> +		compatible = "ethernet-phy-ieee802.3-c22";
> +		reg = <0x1>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&yt8531_rst>;
> +		reset-assert-us = <20000>;
> +		reset-deassert-us = <100000>;
> +		reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
> +	};
> +};
> +
> +/* M.2 E-Key */
> +&pcie2x1l1 {
> +	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc3v3_sys>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pcie_clkreq &pcie_wake &pcie_rst &wifi_pwron &bt_pwron>;
> +	status = "okay";
> +};
> +
> +/* ethernet */
> +&pcie2x1l2 {
> +	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc3v3_sys>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&rtl8111_isolate>;
> +	status = "okay";
> +};
> +
> +&pcie30phy {
> +	status = "okay";
> +};
> +
> +&pcie3x2 {
> +	reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc3v3_sys>;
> +	status = "okay";
> +};
> +
> +/* M.2 M-Kye ssd */
> +&pcie3x4 {
> +	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc3v3_sys>;
> +	status = "okay";
> +};
> +
> +&pinctrl {
> +	cam {
> +		cam_en: cam-en {
> +			rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_output_high>;
> +		};
> +	};
> +
> +	hym8563 {
> +		hym8563_int: hym8563-int {
> +			rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	lcd {
> +		lcdpwr_en: lcdpwr-en {
> +			rockchip,pins = <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
> +		};
> +
> +		bl_en: bl-en {
> +			rockchip,pins = <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	rtl8111 {
> +		rtl8111_isolate: rtl8111-isolate {
> +			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	rtl8211f {
> +		yt8531_rst: yt8531-rst {
> +			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	usb {
> +		vcc5v0_host1_en: vcc5v0-host1-en {
> +			rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	usb-typec {
> +		typec5v_pwren: typec5v-pwren {
> +			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	wifi {
> +		bt_pwron: bt-pwron {
> +			rockchip,pins = <3 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +
> +		pcie_clkreq: pcie-clkreq {
> +			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +
> +		pcie_rst: pcie-rst {
> +			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +
> +		wifi_pwron: wifi-pwron {
> +			rockchip,pins = <3 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +
> +		pcie_wake: pcie-wake {
> +			rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +};
> +
> +&pwm2 {
> +	status = "okay";
> +};
> +
> +&saradc {
> +	vref-supply = <&vcc_1v8_s0>;
> +	status = "okay";
> +};
> +
> +&sata1 {
> +	status = "okay";
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	no-sdio;
> +	no-sd;
> +	non-removable;
> +	max-frequency = <200000000>;
> +	mmc-hs400-1_8v;
> +	mmc-hs400-enhanced-strobe;
> +	status = "okay";
> +};
> +
> +&sdmmc {
> +	max-frequency = <150000000>;
> +	no-sdio;
> +	no-mmc;
> +	bus-width = <4>;
> +	cap-mmc-highspeed;
> +	cap-sd-highspeed;
> +	disable-wp;
> +	sd-uhs-sdr104;
> +	vqmmc-supply = <&vccio_sd_s0>;
> +	status = "okay";
> +};
> +
> +&spi2 {
> +	status = "okay";
> +	assigned-clocks = <&cru CLK_SPI2>;
> +	assigned-clock-rates = <200000000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
> +	num-cs = <1>;
> +
> +	pmic at 0 {
> +		compatible = "rockchip,rk806";
> +		spi-max-frequency = <1000000>;
> +		reg = <0x0>;
> +
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
> +			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
> +
> +		vcc1-supply = <&vcc5v0_sys>;
> +		vcc2-supply = <&vcc5v0_sys>;
> +		vcc3-supply = <&vcc5v0_sys>;
> +		vcc4-supply = <&vcc5v0_sys>;
> +		vcc5-supply = <&vcc5v0_sys>;
> +		vcc6-supply = <&vcc5v0_sys>;
> +		vcc7-supply = <&vcc5v0_sys>;
> +		vcc8-supply = <&vcc5v0_sys>;
> +		vcc9-supply = <&vcc5v0_sys>;
> +		vcc10-supply = <&vcc5v0_sys>;
> +		vcc11-supply = <&vcc_2v0_pldo_s3>;
> +		vcc12-supply = <&vcc5v0_sys>;
> +		vcc13-supply = <&vcc_2v0_pldo_s3>;
> +		vcc14-supply = <&vcc_2v0_pldo_s3>;
> +		vcca-supply = <&vcc5v0_sys>;
> +
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +		rk806_dvs1_null: dvs1-null-pins {
> +			pins = "gpio_pwrctrl2";
> +			function = "pin_fun0";
> +		};
> +
> +		rk806_dvs2_null: dvs2-null-pins {
> +			pins = "gpio_pwrctrl2";
> +			function = "pin_fun0";
> +		};
> +
> +		rk806_dvs3_null: dvs3-null-pins {
> +			pins = "gpio_pwrctrl3";
> +			function = "pin_fun0";
> +		};
> +
> +		regulators {
> +			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
> +				regulator-boot-on;
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_gpu_s0";
> +				regulator-enable-ramp-delay = <400>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_cpu_lit_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_log_s0: dcdc-reg3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <675000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_log_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <750000>;
> +				};
> +			};
> +
> +			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_vdenc_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_ddr_s0: dcdc-reg5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <675000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_ddr_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <850000>;
> +				};
> +			};
> +
> +			vdd2_ddr_s3: dcdc-reg6 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-name = "vdd2_ddr_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc_2v0_pldo_s3: dcdc-reg7 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <2000000>;
> +				regulator-max-microvolt = <2000000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_2v0_pldo_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <2000000>;
> +				};
> +			};
> +
> +			vcc_3v3_s3: dcdc-reg8 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vcc_3v3_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3300000>;
> +				};
> +			};
> +
> +			vddq_ddr_s0: dcdc-reg9 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-name = "vddq_ddr_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8_s3: dcdc-reg10 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc_1v8_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			avcc_1v8_s0: pldo-reg1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "avcc_1v8_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8_s0: pldo-reg2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc_1v8_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			avdd_1v2_s0: pldo-reg3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1200000>;
> +				regulator-max-microvolt = <1200000>;
> +				regulator-name = "avdd_1v2_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_3v3_s0: pldo-reg4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vcc_3v3_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vccio_sd_s0: pldo-reg5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vccio_sd_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			pldo6_s3: pldo-reg6 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "pldo6_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vdd_0v75_s3: nldo-reg1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-name = "vdd_0v75_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <750000>;
> +				};
> +			};
> +
> +			vdd_ddr_pll_s0: nldo-reg2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-name = "vdd_ddr_pll_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <850000>;
> +				};
> +			};
> +
> +			avdd_0v75_s0: nldo-reg3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-name = "avdd_0v75_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_0v85_s0: nldo-reg4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-name = "vdd_0v85_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_0v75_s0: nldo-reg5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-name = "vdd_0v75_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&tsadc {
> +	status = "okay";
> +};
> +
> +&u2phy2 {
> +	status = "okay";
> +};
> +
> +&u2phy3 {
> +	status = "okay";
> +};
> +
> +&u2phy2_host {
> +	phy-supply = <&vcc5v0_host>;
> +	status = "okay";
> +};
> +
> +&u2phy3_host {
> +	phy-supply = <&vcc5v0_host>;
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	pinctrl-0 = <&uart2m0_xfer>;
> +	status = "okay";
> +};
> +
> +&usb_host0_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host0_ohci {
> +	status = "okay";
> +};
> +
> +&usb_host1_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host1_ohci {
> +	status = "okay";
> +};
> 






From will at kernel.org  Mon Dec 11 04:42:38 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 12:42:38 +0000
Subject: [PATCH v3 06/13] arm64: cpufeature: Detect E2H0 not being
 implemented
In-Reply-To: <20231127114559.990314-7-maz@kernel.org>
References: <20231127114559.990314-1-maz@kernel.org>
 <20231127114559.990314-7-maz@kernel.org>
Message-ID: <20231211124238.GB25277@willie-the-truck>

On Mon, Nov 27, 2023 at 11:45:52AM +0000, Marc Zyngier wrote:
> FEAT_E2H0 is a new feature that indicates whether or not HCR_EL2.E2H
> can be set to 0. Amusingly, this feature is set to 0 when implemented,
> and otherwise negative.
> 
> Add a new capability and detection infrastructure to detect the
> absence of FEAT_E2H0.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm64/kernel/cpufeature.c | 7 +++++++
>  arch/arm64/tools/cpucaps       | 1 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 4a72fb26daec..6ef9811f7bb7 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -2786,6 +2786,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.matches = has_cpuid_feature,
>  		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP)
>  	},
> +	{
> +		.desc = "FEAT_E2H0 not implemented",
> +		.capability = ARM64_HCR_E2H_RES1,
> +		.type = ARM64_CPUCAP_SYSTEM_FEATURE,

Is ARM64_CPUCAP_SYSTEM_FEATURE the right thing to use here? For example,
if the boot CPUs have this feature but a late CPU doesn't, then I think
we should be ok as long as we're using VHE, but I don't think the above
takes that into account.

Maybe we shouldn't be adding new capabilities for this at all, and instead
just look at the sanitised register value when we need to?

Will


From peter.griffin at linaro.org  Mon Dec 11 04:45:16 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 12:45:16 +0000
Subject: [PATCH v6 19/20] arm64: dts: exynos: google: Add initial
 Oriole/pixel 6 board support
In-Reply-To: <03603f37-ec3d-456c-95a4-e543d1df4801@linaro.org>
References: <20231209233106.147416-1-peter.griffin@linaro.org>
 <20231209233106.147416-20-peter.griffin@linaro.org> <03603f37-ec3d-456c-95a4-e543d1df4801@linaro.org>
Message-ID: <CADrjBPr7tqdec6z_NL0EEm+G3WTUkjj_dE2Lpm+f=4hdg5BA5Q@mail.gmail.com>

Hi Krzysztof,

On Sun, 10 Dec 2023 at 14:39, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 10/12/2023 00:31, Peter Griffin wrote:
> > Add initial board support for the Pixel 6 phone code named Oriole. This
> > has been tested with a minimal busybox initramfs and boots to a shell.
> >
> > Tested-by: Will McVicker <willmcvicker at google.com>
> > Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  arch/arm64/boot/dts/exynos/Makefile           |   2 +
>
> ...
>
> > +&serial_0 {
> > +     status = "okay";
>
> Keep status the last

Will fix

>
> > +     pinctrl-names = "default";
> > +     pinctrl-0 = <&uart0_bus>;
> > +};
> > +
> > +&usi_uart {
> > +     status = "okay";
>
> Keep status the last

Will fix

regards,

Peter


From namcao at linutronix.de  Mon Dec 11 04:49:13 2023
From: namcao at linutronix.de (Nam Cao)
Date: Mon, 11 Dec 2023 13:49:13 +0100
Subject: [PATCH 0/2] spi: pl022: clean up some unused variables
Message-ID: <cover.1702298527.git.namcao@linutronix.de>

The driver was refactored in 9b2ef250b31d ("spi: spl022: switch to use
default spi_transfer_one_message()"), and some variables are now unused
because of that. Clean them up.

Nam Cao (2):
  spi: pl022: delete unused cur_gpiod in struct pl022
  spi: pl022: delete unused next_msg_cs_active in struct pl022

 drivers/spi/spi-pl022.c | 9 ---------
 1 file changed, 9 deletions(-)

-- 
2.39.2



From namcao at linutronix.de  Mon Dec 11 04:49:14 2023
From: namcao at linutronix.de (Nam Cao)
Date: Mon, 11 Dec 2023 13:49:14 +0100
Subject: [PATCH 1/2] spi: pl022: delete unused cur_gpiod in struct pl022
In-Reply-To: <cover.1702298527.git.namcao@linutronix.de>
References: <cover.1702298527.git.namcao@linutronix.de>
Message-ID: <7618c9d714aa1c16c7cb06f9d1fb1c074d1d9c65.1702298527.git.namcao@linutronix.de>

The member cur_gpiod of struct pl022 is not used anywhere. Delete it.

Signed-off-by: Nam Cao <namcao at linutronix.de>
---
 drivers/spi/spi-pl022.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 1e3bd6f3303a..fd21e83cc3a4 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -361,7 +361,6 @@ struct vendor_data {
  * @dummypage: a dummy page used for driving data on the bus with DMA
  * @dma_running: indicates whether DMA is in operation
  * @cur_cs: current chip select index
- * @cur_gpiod: current chip select GPIO descriptor
  */
 struct pl022 {
 	struct amba_device		*adev;
@@ -393,7 +392,6 @@ struct pl022 {
 	bool				dma_running;
 #endif
 	int cur_cs;
-	struct gpio_desc *cur_gpiod;
 };
 
 /**
@@ -1344,8 +1342,6 @@ static int pl022_transfer_one(struct spi_controller *host, struct spi_device *sp
 	/* Setup the SPI using the per chip configuration */
 	pl022->cur_chip = spi_get_ctldata(spi);
 	pl022->cur_cs = spi_get_chipselect(spi, 0);
-	/* This is always available but may be set to -ENOENT */
-	pl022->cur_gpiod = spi_get_csgpiod(spi, 0);
 
 	restore_state(pl022);
 	flush(pl022);
-- 
2.39.2



From namcao at linutronix.de  Mon Dec 11 04:49:15 2023
From: namcao at linutronix.de (Nam Cao)
Date: Mon, 11 Dec 2023 13:49:15 +0100
Subject: [PATCH 2/2] spi: pl022: delete unused next_msg_cs_active in struct pl022
In-Reply-To: <cover.1702298527.git.namcao@linutronix.de>
References: <cover.1702298527.git.namcao@linutronix.de>
Message-ID: <424fec01a75f6a881edcce189ac68b3408b62f29.1702298527.git.namcao@linutronix.de>

The member next_msg_cs_active of struct pl022 is not used anywhere.
Delete it.

Signed-off-by: Nam Cao <namcao at linutronix.de>
---
 drivers/spi/spi-pl022.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index fd21e83cc3a4..3baf45da01cd 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -341,10 +341,6 @@ struct vendor_data {
  * @cur_msg: Pointer to current spi_message being processed
  * @cur_transfer: Pointer to current spi_transfer
  * @cur_chip: pointer to current clients chip(assigned from controller_state)
- * @next_msg_cs_active: the next message in the queue has been examined
- *  and it was found that it uses the same chip select as the previous
- *  message, so we left it active after the previous transfer, and it's
- *  active already.
  * @tx: current position in TX buffer to be read
  * @tx_end: end position in TX buffer to be read
  * @rx: current position in RX buffer to be written
@@ -372,7 +368,6 @@ struct pl022 {
 	struct pl022_ssp_controller	*host_info;
 	struct spi_transfer		*cur_transfer;
 	struct chip_data		*cur_chip;
-	bool				next_msg_cs_active;
 	void				*tx;
 	void				*tx_end;
 	void				*rx;
-- 
2.39.2



From gregkh at linuxfoundation.org  Mon Dec 11 04:57:44 2023
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Mon, 11 Dec 2023 13:57:44 +0100
Subject: Patch "perf metrics: Avoid segv if default metricgroup isn't set" has been added to the 6.6-stable tree
Message-ID: <2023121144-gravitate-escalate-00b5@gregkh>


This is a note to let you know that I've just added the patch titled

    perf metrics: Avoid segv if default metricgroup isn't set

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     perf-metrics-avoid-segv-if-default-metricgroup-isn-t-set.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable at vger.kernel.org> know about it.


>From e2b005d6ec0e738df584190e21d2c7ada37266a0 Mon Sep 17 00:00:00 2001
From: Ian Rogers <irogers at google.com>
Date: Mon, 4 Dec 2023 10:23:29 -0800
Subject: perf metrics: Avoid segv if default metricgroup isn't set

From: Ian Rogers <irogers at google.com>

commit e2b005d6ec0e738df584190e21d2c7ada37266a0 upstream.

A metric is default by having "Default" within its groups. The default
metricgroup name needn't be set and this can result in segv in
default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
that assume it has a value when there is a Default metric group. To
avoid the segv initialize the value to "".

Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
Signed-off-by: Ian Rogers <irogers at google.com>
Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
Cc: James Clark <james.clark at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Leo Yan <leo.yan at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Kajol Jain <kjain at linux.ibm.com>
Cc: Kan Liang <kan.liang at linux.intel.com>
Cc: John Garry <john.g.garry at oracle.com>
Cc: stable at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Link: https://lore.kernel.org/r/20231204182330.654255-1-irogers at google.com
Signed-off-by: Namhyung Kim <namhyung at kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 tools/perf/util/metricgroup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 0484736d9fe4..ca3e0404f187 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -225,7 +225,7 @@ static struct metric *metric__new(const struct pmu_metric *pm,
 
 	m->pmu = pm->pmu ?: "cpu";
 	m->metric_name = pm->metric_name;
-	m->default_metricgroup_name = pm->default_metricgroup_name;
+	m->default_metricgroup_name = pm->default_metricgroup_name ?: "";
 	m->modifier = NULL;
 	if (modifier) {
 		m->modifier = strdup(modifier);
-- 
2.43.0



Patches currently in stable-queue which might be from irogers at google.com are

queue-6.6/perf-vendor-events-arm64-ampereone-add-missing-defau.patch
queue-6.6/perf-metrics-avoid-segv-if-default-metricgroup-isn-t-set.patch
queue-6.6/perf-list-fix-json-segfault-by-setting-the-used-skip_duplicate_pmus-callback.patch


From umang.jain at ideasonboard.com  Mon Dec 11 04:59:43 2023
From: umang.jain at ideasonboard.com (Umang Jain)
Date: Mon, 11 Dec 2023 18:29:43 +0530
Subject: [PATCH v4 1/7] media: dt-bindings: media: imx335: Add supply bindings
In-Reply-To: <20231211125950.108092-1-umang.jain@ideasonboard.com>
References: <20231211125950.108092-1-umang.jain@ideasonboard.com>
Message-ID: <20231211125950.108092-2-umang.jain@ideasonboard.com>

From: Kieran Bingham <kieran.bingham at ideasonboard.com>

Add the bindings for the supply references used on the IMX335.

Reviewed-by: Umang Jain <umang.jain at ideasonboard.com>
Reviewed-by: Marco Felsch <m.felsch at pengutronix.de>
Signed-off-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
 .../devicetree/bindings/media/i2c/sony,imx335.yaml  | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
index a167dcdb3a32..106c36ee966d 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
@@ -32,6 +32,15 @@ properties:
     description: Clock frequency from 6 to 27 MHz, 37.125MHz, 74.25MHz
     maxItems: 1
 
+  avdd-supply:
+    description: Analog power supply (2.9V)
+
+  ovdd-supply:
+    description: Interface power supply (1.8V)
+
+  dvdd-supply:
+    description: Digital power supply (1.2V)
+
   reset-gpios:
     description: Reference to the GPIO connected to the XCLR pin, if any.
     maxItems: 1
@@ -79,6 +88,10 @@ examples:
             assigned-clock-parents = <&imx335_clk_parent>;
             assigned-clock-rates = <24000000>;
 
+            avdd-supply = <&camera_vdda_2v9>;
+            ovdd-supply = <&camera_vddo_1v8>;
+            dvdd-supply = <&camera_vddd_1v2>;
+
             port {
                 imx335: endpoint {
                     remote-endpoint = <&cam>;
-- 
2.41.0



From ajaygargnsit at gmail.com  Mon Dec 11 05:06:26 2023
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 11 Dec 2023 18:36:26 +0530
Subject: Query on a rare simultaneous processing of interrupts from GIC/NVIC
Message-ID: <CAHP4M8WQdQfjxa-oqGTEF-kfF3j8En6V5fi7gyNbGegwFqfpCQ@mail.gmail.com>

Hi everyone.

Let's say the following code is shared by multiple ISRs :

   spin_lock_irqsave
   <critical section>
   spin_lock_irqrestore



Also, following sequencing happens :

*
Low-priority interrupt comes in, and GIC/NVIC causes it jump to ISR.

*
Low-priority interrupt starts executing "spin_lock_irqsave".

*
Before preemption and interrupts could be disabled (by the executing
low-priority interrupt). high-priority interrupt comes in.
Since a higher priority interrupt has come in, the GIC/NVIC causes it
to start executing the "spin_lock_irqsave" statement.

*
Through the low-priority interrupt executing, "spin_lock_irqsave" has completed.
Preemption and interrupts are disabled, and low-priority interrupt
grabs the spin lock.

*
High-priority interrupt spins on the spin-lock.



Is the above sequencing possible?

In other words, although the first interrupt did its best to disable
all preemption and interrupts before it could enter the critical
section, yet above sequencing *will* cause the high-priority interrupt
to spin?


Many thanks in advance for your time for help !


Thanks and Regards,
Ajay


From heiko at sntech.de  Mon Dec 11 05:08:51 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 11 Dec 2023 14:08:51 +0100
Subject: [PATCH] dt-bindings: iommu: rockchip: Add Rockchip RK3588
In-Reply-To: <20231209015038.1457967-1-andyshrk@163.com>
References: <20231209015038.1457967-1-andyshrk@163.com>
Message-ID: <5370401.0VBMTVartN@diego>

Hi Andy,

Am Samstag, 9. Dezember 2023, 02:50:38 CET schrieb Andy Yan:
> From: Andy Yan <andy.yan at rock-chips.com>
> 
> Add a Rockchip RK3588 compatible
> 
> I split it from the vop2 patch series as suggested by Heiko[0]

correct, but something with the addresses did go wrong

# scripts/get_maintainer.pl -f Documentation/devicetree/bindings/iommu/
lists among the other people especially:

Joerg Roedel <joro at 8bytes.org> (maintainer:IOMMU SUBSYSTEM)
Will Deacon <will at kernel.org> (maintainer:IOMMU SUBSYSTEM)

as the maintainers for the iommu subsystem and I don't see them
in the recipient list.


Heiko



> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> [0]https://patchwork.kernel.org/project/dri-devel/patch/20231207080235.652719-1-andyshrk at 163.com/
> 
> ---
> 
>  .../devicetree/bindings/iommu/rockchip,iommu.yaml     | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> index ba9124f721f1..621dde0e45d8 100644
> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> @@ -19,9 +19,14 @@ description: |+
>  
>  properties:
>    compatible:
> -    enum:
> -      - rockchip,iommu
> -      - rockchip,rk3568-iommu
> +    oneOf:
> +      - enum:
> +          - rockchip,iommu
> +          - rockchip,rk3568-iommu
> +      - items:
> +          - enum:
> +              - rockchip,rk3588-iommu
> +          - const: rockchip,rk3568-iommu
>  
>    reg:
>      items:
> 






From will at kernel.org  Mon Dec 11 05:11:31 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 13:11:31 +0000
Subject: [PATCH] arm64: Make icache detection a cpu capability
In-Reply-To: <20231205133148.2011836-1-maz@kernel.org>
References: <20231205133148.2011836-1-maz@kernel.org>
Message-ID: <20231211131131.GA25681@willie-the-truck>

On Tue, Dec 05, 2023 at 01:31:48PM +0000, Marc Zyngier wrote:
> Now that we only have two icache policies, we are in a good position
> to make the whole detection business more robust.
> 
> Let's replace __icache_flags by a single capability (ICACHE_PIPT),
> and use this if all CPUs are indeed PIPT. It means we can rely on
> existing logic to mandate that a VIPT CPU coming up late will be
> denied booting, which is the safe thing to do.

Why do we want to prevent that? We currently allow it and I'm not seeing
what goes wrong.

Will


From will at kernel.org  Mon Dec 11 05:16:12 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 13:16:12 +0000
Subject: [PATCH v4 0/4] Support SMT control on arm64
In-Reply-To: <20231121092602.47792-1-yangyicong@huawei.com>
References: <20231121092602.47792-1-yangyicong@huawei.com>
Message-ID: <20231211131612.GB25681@willie-the-truck>

On Tue, Nov 21, 2023 at 05:25:58PM +0800, Yicong Yang wrote:
> From: Yicong Yang <yangyicong at hisilicon.com>
> 
> The core CPU control framework supports runtime SMT control which
> is not yet supported on arm64. Besides the general vulnerabilities
> concerns we want this runtime control on our arm64 server for:
> 
> - better single CPU performance in some cases
> - saving overall power consumption
> 
> This patchset implements it in the following aspects:
> 
> - implements the basic support in arch_topology driver
> - support retrieve SMT thread number on OF based system
> - support retrieve SMT thread number on ACPI based system
> - select HOTPLUG_SMT for arm64
> 
> Tests has been done on our real ACPI based arm64 server and on
> ACPI/OF based QEMU VMs.
> 
> The patchset is based on v6.7-rc1.
> 
> Change since v3:
> - Fix some build and kconfig error reported by kernel test robot <lkp at intel.com>
> Link: https://lore.kernel.org/linux-arm-kernel/20231114040110.54590-1-yangyicong at huawei.com/
> 
> Change since v2:
> - Detect SMT thread number at topology build from ACPI/DT, avoid looping CPUs
> - Split patches into ACPI/OF/arch_topology path and enable the kconfig for arm64
> Link: https://lore.kernel.org/linux-arm-kernel/20231010115335.13862-1-yangyicong at huawei.com/
> 
> Yicong Yang (4):
>   arch_topology: Support basic SMT control for the driver
>   arch_topology: Support SMT control for OF based system

Looking at the first two patches you have here, they are incredibly trivial
and feel like they'd be better off implemented as the default behaviour in
the core code so that architectures with additional constraints (e.g. x86)
can override that.

Will


From joro at 8bytes.org  Mon Dec 11 05:20:52 2023
From: joro at 8bytes.org (Joerg Roedel)
Date: Mon, 11 Dec 2023 14:20:52 +0100
Subject: [PATCH 1/3] iommu/msm-iommu: don't limit the driver too much
In-Reply-To: <6397268c-7990-42f6-9453-44fdc638d5c9@arm.com>
References: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>
 <20231207125500.3322229-2-dmitry.baryshkov@linaro.org>
 <6397268c-7990-42f6-9453-44fdc638d5c9@arm.com>
Message-ID: <ZXcMtNrJLb9_W-lH@8bytes.org>

On Thu, Dec 07, 2023 at 01:06:09PM +0000, Robin Murphy wrote:
> On 07/12/2023 12:54 pm, Dmitry Baryshkov wrote:
> > In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
> > driver just to those machines. Allow it to be built for any 32-bit
> > Qualcomm platform (ARCH_QCOM).
> 
> Acked-by: Robin Murphy <robin.murphy at arm.com>
> 
> Unless Joerg disagrees, I think it should be fine if you want to take this
> via the SoC tree.

No objections:

Acked-by: Joerg Roedel <jroedel at suse.de>



From will at kernel.org  Mon Dec 11 05:20:55 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 13:20:55 +0000
Subject: [PATCH 12/21] arm64: setup: Switch over to GENERIC_CPU_DEVICES
 using arch_register_cpu()
In-Reply-To: <E1r5R3b-00Csza-Ku@rmk-PC.armlinux.org.uk>
References: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk>
 <E1r5R3b-00Csza-Ku@rmk-PC.armlinux.org.uk>
Message-ID: <20231211132054.GC25681@willie-the-truck>

On Tue, Nov 21, 2023 at 01:44:51PM +0000, Russell King wrote:
> From: James Morse <james.morse at arm.com>
> 
> To allow ACPI's _STA value to hide CPUs that are present, but not
> available to online right now due to VMM or firmware policy, the
> register_cpu() call needs to be made by the ACPI machinery when ACPI
> is in use. This allows it to hide CPUs that are unavailable from sysfs.
> 
> Switching to GENERIC_CPU_DEVICES is an intermediate step to allow all
> five ACPI architectures to be modified at once.
> 
> Switch over to GENERIC_CPU_DEVICES, and provide an arch_register_cpu()
> that populates the hotpluggable flag. arch_register_cpu() is also the
> interface the ACPI machinery expects.
> 
> The struct cpu in struct cpuinfo_arm64 is never used directly, remove
> it to use the one GENERIC_CPU_DEVICES provides.
> 
> This changes the CPUs visible in sysfs from possible to present, but
> on arm64 smp_prepare_cpus() ensures these are the same.
> 
> This patch also has the effect of moving the registration of CPUs from
> subsys to driver core initialisation, prior to any initcalls running.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Reviewed-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> Reviewed-by: Shaoqin Huang <shahuang at redhat.com>
> Reviewed-by: Gavin Shan <gshan at redhat.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> ---
> Changes since RFC v2:
>  * Add note about initialisation order change.
> ---
>  arch/arm64/Kconfig           |  1 +
>  arch/arm64/include/asm/cpu.h |  1 -
>  arch/arm64/kernel/setup.c    | 13 ++++---------
>  3 files changed, 5 insertions(+), 10 deletions(-)

Acked-by: Will Deacon <will at kernel.org>

Will


From quic_mojha at quicinc.com  Mon Dec 11 05:20:42 2023
From: quic_mojha at quicinc.com (Mukesh Ojha)
Date: Mon, 11 Dec 2023 18:50:42 +0530
Subject: [Patch v6 03/12] docs: qcom: Add qualcomm minidump guide
In-Reply-To: <b50fd14e-7798-4b1e-aff3-9409e67300b3@linaro.org>
References: <1700864395-1479-1-git-send-email-quic_mojha@quicinc.com>
 <1700864395-1479-4-git-send-email-quic_mojha@quicinc.com>
 <b50fd14e-7798-4b1e-aff3-9409e67300b3@linaro.org>
Message-ID: <c91bec51-5ca5-26c5-c41d-55461477b623@quicinc.com>

Thanks you very much Bryan for giving so much time of yours in reviewing 
minidump DOC and I apologize for coming so late for your reply.

I will definetely apply your suggestion in next series.

Please find my reply inline for your queries.

On 11/28/2023 6:45 PM, Bryan O'Donoghue wrote:
> On 24/11/2023 22:19, Mukesh Ojha wrote:
>> Add the qualcomm minidump guide for the users which tries to cover
>> the dependency, API use and the way to test and collect minidump
>> on Qualcomm supported SoCs.
>>
>> Signed-off-by: Mukesh Ojha <quic_mojha at quicinc.com>
>> ---
>> ? Documentation/admin-guide/index.rst???????? |?? 1 +
>> ? Documentation/admin-guide/qcom_minidump.rst | 272 
>> ++++++++++++++++++++++++++++
>> ? 2 files changed, 273 insertions(+)
>> ? create mode 100644 Documentation/admin-guide/qcom_minidump.rst
> 
> General nit-pick on sequencing of your patches. Its good practice (tm) 
> to put your documentation first in your series.
> 
>> diff --git a/Documentation/admin-guide/index.rst 
>> b/Documentation/admin-guide/index.rst
>> index 43ea35613dfc..251d070486c2 100644
>> --- a/Documentation/admin-guide/index.rst
>> +++ b/Documentation/admin-guide/index.rst
>> @@ -120,6 +120,7 @@ configure specific aspects of kernel behavior to 
>> your liking.
>> ???? perf-security
>> ???? pm/index
>> ???? pnp
>> +?? qcom_minidump
>> ???? rapidio
>> ???? ras
>> ???? rtc
>> diff --git a/Documentation/admin-guide/qcom_minidump.rst 
>> b/Documentation/admin-guide/qcom_minidump.rst
>> new file mode 100644
>> index 000000000000..b492f2b79639
>> --- /dev/null
>> +++ b/Documentation/admin-guide/qcom_minidump.rst
>> @@ -0,0 +1,272 @@
>> +Qualcomm minidump feature
>> +=========================
>> +
>> +Introduction
>> +------------
>> +
>> +Minidump is a best effort mechanism to collect useful and predefined
>> +data for first level of debugging on end user devices running on
>> +Qualcomm SoCs. 
> 
> What does "first-level debugging" mean here ? You use the term 
> "post-mortem" later, stick with one term for consistency throughout your 
> document.

First level debugging meant was to mean the amount of data captured is
limited and may be sufficient to root cause an issue and you may need
entire ramdump to debug the issue.

> 
> Suggest:
> 
> "Minidump is a best-effort mechanism to collect useful predefined data 
> for post-mortem debugging on a Qualcomm System on Chips (SoCs)."
> 
> Generally better to stick with "Qualcomm SoC" and "Minidump" once you 
> establish the terms upfront and early in your text - instead of 
> reverting to "device" and "it".
> 
> It is built on the premise that System on Chip (SoC)
>> +or subsystem part of SoC crashes, due to a range of hardware and
>> +software bugs.
> Instead of saying "It" say "Minidump"

Sure, will try to be consistent in term usage.

> 
> Hence, the ability to collect accurate data is only
>> +a best-effort. The data collected could be invalid or corrupted, data
>> +collection itself could fail, and so on.
> 
> "and so on" is a redundancy, drop.
> 
> 
> Suggest:
> Minidump is built on the premise that a hardware or software component 
> on the SoC has encountered an unexpected fault. This means that the data 
> collected by minidump cannot be assumed to be correct or even present.
> 
>> +
>> +Qualcomm devices in engineering mode provides a mechanism for generating
>> +full system RAM dumps for post-mortem debugging. 
> 
> Stick with the established naming convention
> 
> "Qualcomm SoCs in engineering mode provide a mechanism for generating 
> full system RAM dumps for this post-mortem debugging"
> 
> But in some cases it's
>> +however not feasible to capture the entire content of RAM. The minidump
>> +mechanism provides the means for selected region should be included in
>> +the ramdump.
> 
> Dont' start a sentence with "But"

Sure.

> 
> You're also not being clear what you mean by "the entire content of RAM" 
> since you obviously can't capture a full snap-shot of DRAM and store in 
> DRAM.
> 
> Better to say IMO
> 
> "Minidump captures specific pre-defined regions of RAM and stores those 
> regions in a reserved Minidump specific buffer."
> 
> "The region of RAM used to store Minidump data shall be referred to as 
> SMEM throughout this document." [1]

ok

> 
>> +::
>> +
>> +?? +-----------------------------------------------+
>> +?? |?? DDR?????????????????????? +-------------+?? |
> 
> Instead of saying "DDR" just mark this as RAM or Memory.
> Its a terrible nit-pick from me but DDR = "Double Data Rate Synchronous 
> Dynamic Random-Access Memory" but that's irrelevant to this 
> specification. We could be living in a gigantic SRAM for argument sake.

Sure.

> 
>> +?? |???????????????????????????? |????? SS0-ToC|?? |
>> +?? | +----------------+???? +----------------+ |?? |
>> +?? | |Shared memory?? |???? |???????? SS1-ToC| |?? |
>> +?? | |(SMEM)????????? |???? |??????????????? | |?? |
>> +?? | |??????????????? | +-->|--------+?????? | |?? |
>> +?? | |G-ToC?????????? | |?? | SS-ToC? \????? | |?? |
>> +?? | |+-------------+ | |?? | +-----------+? | |?? |
>> +?? | ||-------------| | |?? | |-----------|? | |?? |
>> +?? | || SS0-ToC???? | | | +-|<|SS1 region1|? | |?? |
>> +?? | ||-------------| | | | | |-----------|? | |?? |
>> +?? | || SS1-ToC???? |-|>+ | | |SS1 region2|? | |?? |
>> +?? | ||-------------| |?? | | |-----------|? | |?? |
>> +?? | || SS2-ToC???? | |?? | | |? ...????? |? | |?? |
>> +?? | ||-------------| |?? | | |-----------|? | |?? |
>> +?? | ||? ...??????? | |?? |-|<|SS1 regionN|? | |?? |
>> +?? | ||-------------| |?? | | |-----------|? | |?? |
>> +?? | || SSn-ToC???? | |?? | | +-----------+? | |?? |
>> +?? | |+-------------+ |?? | |??????????????? | |?? |
>> +?? | |??????????????? |?? | |----------------| |?? |
>> +?? | |??????????????? |?? +>|? regionN?????? | |?? |
>> +?? | |??????????????? |?? | |----------------| |?? |
>> +?? | +----------------+?? | |??????????????? | |?? |
>> +?? |????????????????????? | |----------------| |?? |
>> +?? |????????????????????? +>|? region1?????? | |?? |
>> +?? |??????????????????????? |----------------| |?? |
>> +?? |??????????????????????? |??????????????? | |?? |
>> +?? |??????????????????????? |----------------|-+?? |
>> +?? |??????????????????????? |? region5?????? |???? |
>> +?? |??????????????????????? |----------------|???? |
>> +?? |??????????????????????? |??????????????? |???? |
>> +?? |? Region information??? +----------------+???? |
>> +?? | +---------------+???????????????????????????? |
>> +?? | |region name??? |???????????????????????????? |
>> +?? | |---------------|???????????????????????????? |
>> +?? | |region address |???????????????????????????? |
>> +?? | |---------------|???????????????????????????? |
>> +?? | |region size??? |???????????????????????????? |
>> +?? | +---------------+???????????????????????????? |
>> +?? +-----------------------------------------------+
>> +?????? G-ToC: Global table of contents
>> +?????? SS-ToC: Subsystem table of contents
>> +?????? SS0-SSn: Subsystem numbered from 0 to n
> 
> You need to be more consistent here
> 
> SSX-ToC -> SSX-SSn
> 
> Where X is an integer from 0 upwards and similarly n is a integer from 0 
> upwards.
> 
> This name SSX-SSn is not especially descriptive, I'm not sure if this is 
> a name you are choosing here ? If so then let me suggest a new name like 
> "Subsystem Memory Segment" SSX-MSn

looks good.

> 
> ->
> 
>  ?????? G-ToC: Global table of contents
>  ?????? SSX-ToC: Subsystem X table of contents.
>  ??????????????? X is an integer in the range of 0 to ?
>  ??????????????? Is there an upper limit ?

Older Soc had the limit of 10 but the newer SoC firmware this limit has 
increased.

This reminds me of creating a patch to make the no of subsystem 
configurable through CONFIG_*.

   #define MAX_NUM_OF_SS           10

"drivers/remoteproc/qcom_common.c"


>  ??????????????? Presumably this is an 8, 16, 32 or 64 bit integer
>  ??????????????? Please define either the size of the integer or the
>  ??????????????? valid range of values 0..128, 0..256
>  ?????? SSX-MSn: Subsystem numbered from 0 to n
>  ??????????????? Same comment for the 'n' here.

Thanks again..

> 
>> +
>> +It depends on SoC where the underlying firmware is keeping the
>> +minidump global table taking care of subsystem ToC part for
>> +minidump like for above diagram, it is for shared memory sitting
>> +in DDR and it is shared among various master however it is possible
> 
>> +that this could be implemented via memory mapped regions but the
>> +general idea should remain same. Here, various subsystem could be
>> +DSP's like ADSP/CDSP/MODEM etc, along with Application processor
>> +(APSS) where Linux runs. 
> 
> 
> DSP minidump gets collected when DSP's goes
>> +for recovery followed by a crash. The minidump part of code for
>> +that resides in ``qcom_rproc_minidump.c``.
> 
> This paragraph is difficult to parse.
> 
> What you are describing here is a linked list, I think you should have a 
> paragraph describing how the memory structure works
> 
> ->
> 
> "Minidump determines which areas of DRAM to capture via a Minidump 
> defined linked-list structure.
> 
> At the top level a Global Table of Contents (GTOC) enumerates a variable 
> number of SubSystem Table Of Contents (SSTOC) structures.
> 
> Each SSTOC contains a list of SubSystem Memory Segements which are named 
> according to the containing SSTOC hence (SSX-MSn) where "X" denotes the 
> SystemSystem index of the containing SSX-ToC and "n" denotes an 
> individual Memory Segment within the SystemSystem. Hence SS0-MS0 belongs 
> to SS0-ToC whereas SS1-MS0 belongs to SS1-ToC."

Thanks for this.

> 
> Then I think you can describe how the crash dump colleciton works and 
> which agents of the system - DSP ? is responsible for collecting the 
> crashdump
> 
> ->
> 
> "The Application Processor SubSystem (APSS) runs the Linux kernel and is 
> therefore not responsible for assembling Minidump data. One of the other 
> system agents in the SoC will be responsible for capturing the Minidump 
> data during system reset.
> 
> Typically one of the SoC Digital Signal Processors (DSP) will be used 
> for this purpose.
> 
> During reset the DSP will walk the GTOC, SSX-ToCs and SSX-MSns 
> populating the Minidump RAM area with the indicated memory"
> 
>> +
>> +
>> +SMEM as backend
> 
> 
>> +----------------
>> +
>> +In this document, SMEM will be used as the backend implementation
>> +of minidump.
> 
> [1] As per the above link, you need to introduce the term SMEM earlier.
> 
> It's fine to expand on its meaning later but, do please define it once 
> upfront before you use it in your awesome ASCII art.

Sure.

> 
>> +The core of minidump feature is part of Qualcomm's boot firmware code.
>> +It initializes shared memory (SMEM), which is a part of DDR and
>> +allocates a small section of it to minidump table, i.e. also called
>> +global table of contents (G-ToC). Each subsystem (APSS, ADSP, ...) has
>> +its own table of segments to be included in the minidump, all
>> +references from a descriptor in SMEM (G-ToC). Each segment/region has
>> +some details like name, physical address and its size etc. and it
>> +could be anywhere scattered in the DDR.
> 
> ->
> 
> "The SoC's bootloader must reserve an area of RAM as SMEM prior to 
> handing over control to the run-time operating system. The bootloader is 
> responsible to place the GTOC at the starting address of SMEM."
> 
> If you want to give more technical details of size, physical address - 
> then explicitly define those in the section above which talks about the 
> linked-list structure.
> 
> Please try to avoid use of "etc" or "and so on" since it assumes the 
> reader already knows how the system works and can fill in the blanks 
> but, what you are doing here is educating a Minidump novice in how 
> things work.

ok.

> 
>> +
>> +Qualcomm APSS Minidump kernel driver concept
>> +--------------------------------------------
>> +
>> +Qualcomm APSS minidump kernel driver adds the capability to add Linux
> 
> So why "Minidump" and then "minidump" choose one.
> 
>> +region to be dumped as part of RAM dump collection.
> 
> 
> OK so this really is the "meat" of the system. The bootloader/firmware 
> populates the GTOC.
> 
> The Q this document should probably answer is how the kernel driver 
> knows how/where to place its data.
> 
> Assumed to be parsing the DTB.
> 
>  ?At the moment,
>> +shared memory driver creates platform device for minidump driver and
>> +give a means to APSS minidump to initialize itself on probe.
> 
> "At the moment" is another drop.
> 
> Just make a clear statement
> 
> "The minidump platform driver populates the APSS porition of the GTOC"
> 
> more interesting to me is - are there defined numbers, identifiers for 
> the APSS ? or do we just add new entries to the GTOC ?
> 
> ie. is there a reserved index or "type" in the GTOC that identifies 
> where the APSS needs to insert itself ?

Correct.

APSS has similar index i.e, 0 similar to minidump index for other 
remoteprocs mentioned belowin GTOC.

https://elixir.bootlin.com/linux/v6.7-rc5/source/drivers/remoteproc/qcom_q6v5_pas.c#L1113

https://elixir.bootlin.com/linux/v6.7-rc5/source/drivers/remoteproc/qcom_q6v5_pas.c#L1133

https://elixir.bootlin.com/linux/v6.7-rc5/source/drivers/remoteproc/qcom_q6v5_pas.c#L1153

qcom_smem_get(QCOM_SMEM_HOST_ANY, SBL_MINIDUMP_SMEM_ID, &size);

Above API is the key, And given SMEM ID it gives the object detail 
present in shared memory and whether it is Minidump global table 
structure object address in case of minidump or SoC info object
in case of socinfo related information (drivers/soc/qcom/socinfo.c).

> 
>> +This driver provides ``qcom_minidump_region_register`` and
>> +``qcom_minidump_region_unregister`` API's to register and unregister
>> +APSS minidump region. 
> 
> Why does it do that ? Is it not the case that the driver knows where the 
> APSS data goes ?

If you mean why does it provide
qcom_minidump_region_register/qcom_minidump_region_unregister

E.g., it is for the linux clients to upfront register their buffer or 
object which they want to see to check once there is crash from their 
driver and same is true other linux clients.

In the current state of the driver it does not export these symbols
and only captures ramoops frontends data like console, dmesg, ftrace, 
pmesg but there is plan to do that when one of the upstream client
driver interested in capturing something from their driver they have
to use this API to register it with APSS minidump table.

> 
> It also supports registration for the clients
>> +who came before minidump driver was initialized. It maintains pending
>> +list of clients who came before minidump and once minidump is 
>> initialized
>> +it registers them in one go.
> 
> Don't start sentences with "It" -> "The driver" or "Minidump"
> 
> As I read this though, the Minidump driver in Linux isn't just 
> registering / managing the APSS side of things but also "doing stuff" 
> for other clients ?
> 
> How does the Linux driver know what to register ?

Again, I am reiterating what i said above, it is upto the client driver 
interests what they want to check from their driver once they see a 
crash from there driver, it could be some buffer content or structure
object or anything.

Minidump is kind of blind what are you capturing is not known to itself.

> 
>> +
>> +To simplify post-mortem debugging, driver creates and maintain an ELF
> 
> the driver creates and maintains
> 
>> +header as first region that gets updated each time a new region gets
>> +registered.
> 
> as the first region
> 
> So - who is registering these regions ? Linux kernel drivers ? aDSP / 
> cDSP ?

For APSS(linux), driver register it through the call made to
qcom_minidump_region_{register|unregister} by the linux clients.
Here, it provide flexiblity to dynamically register the regions.

For ADSP/CDSP/MODEM, they will have their own way which is mostly
statically decided what addresses range they want to capture on
their crash.

> 
> If I write a new driver for Venus or GPU can I define my own region(s) 
> to be captured ?

I am not an expert of Venus/GPU but AFAIK, currently their firmware side 
don't use minidump but you can still use APSS minidump to register
required their host regions from GPU/VENUS linux drivers once APSS 
minidump driver exports register/unregister API.

> 
> Presumably. Please give more detail on this.
> 
>> +
>> +The solution supports extracting the RAM dump/minidump produced either
>> +over USB or stored to an attached storage device.
> 
> What provides that functionality ? The bootloader ?

Yes, the bootloader.

> 
> How do you trigger / capture that dump from the bootloader ?

This is explained how to set minidump and once set any region of SOC
crash will collect minidump and if not set by default entire ddr
dump is collected.

> 
> No need to go into super-detail but give some idea.
> 
>> +
>> +Dependency of minidump kernel driver
>> +------------------------------------
>> +
>> +It is to note that whole of minidump depends on Qualcomm boot firmware
>> +whether it supports minidump or not. 
> 
> You can drop this - you've already stated the bootloader/firmware must 
> setup the initial table so, you're not providing additional information 
> with this statement.
> 
>> So, if the minidump SMEM ID is
> 
> Try not to start sentences with "So"
> 
> SMEM ID ? This is your first time using this term - please relate it 
> back to your ASCII diagram and the description you give with that text.
> 
>> +present in shared memory, it indicates that minidump is supported from
>> +boot firmware and it is possible to dump Linux (APSS) region as part
>> +of minidump collection.
> 
> If _which_ SMEM ID ?
> 
> It seems to me as if we are missing some important information here - 
> what are the list of SMEM IDs ?
> 
> Are these IDs serial and incrementing across SoC versions or SoC specific ?


I have described above in my explanation probably it should make sense 
now, will also try to add it in the doc.

> 
> You need to define that data.
> 
>> +How a kernel client driver can register region with minidump
>> +------------------------------------------------------------
> 
> Answering yes to my earlier question. A driver I write can make use of 
> the API you are providing here.
> 
> Great. Please give some indication of that earlier, even if its a 
> reference to this description you give here "See X.Y later in this 
> document"
> 
>> +
>> +Client driver can use ``qcom_minidump_region_register`` API's to 
>> register
>> +and ``qcom_minidump_region_unregister`` to unregister their region from
>> +minidump driver.
>> +
>> +Client needs to fill their region by filling ``qcom_minidump_region``
>> +structure object which consists of the region name, region's virtual
>> +and physical address and its size.
> 
> Nit pick. You need a definite article here "A client driver" etc.
> 
>> +
>> +Below, is one sample client driver snippet which tries to allocate a
>> +region from kernel heap of certain size and it writes a certain known
>> +pattern.
> 
> Good
> 
>  ?(that can help in verification after collection that we got
>> +the exact pattern, what we wrote) and registers it with minidump.
> 
> Not necessary to define this. We are all smart here and by now the 
> intent of the mechanism is defined..
> 
>> +
>> + .. code-block:: c
>> +
>> +? #include <soc/qcom/qcom_minidump.h>
>> +? [...]
>> +
>> +
>> +? [... inside a function ...]
>> +? struct qcom_minidump_region region;
>> +
>> +? [...]
>> +
>> +? client_mem_region = kzalloc(region_size, GFP_KERNEL);
>> +? if (!client_mem_region)
>> +??? return -ENOMEM;
>> +
>> +? [... Just write a pattern ...]
>> +? memset(client_mem_region, 0xAB, region_size);
>> +
>> +? [... Fill up the region object ...]
>> +? strlcpy(region.name, "REGION_A", sizeof(region.name));
>> +? region.virt_addr = client_mem_region;
>> +? region.phys_addr = virt_to_phys(client_mem_region);
>> +? region.size = region_size;
>> +
>> +? ret = qcom_minidump_region_register(&region);
>> +? if (ret < 0) {
>> +??? pr_err("failed to add region in minidump: err: %d\n", ret);
>> +??? return ret;
>> +? }
>> +
>> +? [...]
>> +
>> +
>> +Test
>> +----
> 
> Testing
> 
>> +
>> +Existing Qualcomm devices already supports entire RAM dump (also called
>> +full dump) by writing appropriate value to Qualcomm's top control and
>> +status register (tcsr) in ``driver/firmware/qcom_scm.c`` .
> 
> "Existing Qualcomm SoCs already support dumping the entire RAM to the 
> SMEM area/segment/whatever"
> 
> This is 100% counter-intuitive since SMEM lives in RAM, correct ?
> 
> Full dump means what, a full dump of the APSS RAM ? What happens if SMEM 
> cannot accommodate the full APSS RAM dump ?

Sorry, I never said full dump is captured in SMEM, the only difference 
of minidump with full dump is, no region registration is required so no
need of SMEM(where the meta data is there right ?) and entire ddr dump 
is collected by firmware/bootloader and it sent to to host connected 
machine via USB through Sahara protocol.

> 
>> +
>> +SCM device Tree bindings required to support download mode
>> +For example (sm8450) ::
>> +
>> +??? / {
>> +
>> +??? [...]
>> +
>> +??????? firmware {
>> +??????????? scm: scm {
>> +??????????????? compatible = "qcom,scm-sm8450", "qcom,scm";
>> +??????????????? [... tcsr register ... ]
>> +??????????????? qcom,dload-mode = <&tcsr 0x13000>;
>> +
>> +??????????????? [...]
>> +??????????? };
>> +??????? };
>> +
>> +??? [...]
>> +
>> +??????? soc: soc at 0 {
>> +
>> +??????????? [...]
>> +
>> +??????????? tcsr: syscon at 1fc0000 {
>> +??????????????? compatible = "qcom,sm8450-tcsr", "syscon";
>> +??????????????? reg = <0x0 0x1fc0000 0x0 0x30000>;
>> +??????????? };
>> +
>> +??????????? [...]
>> +??????? };
>> +??? [...]
>> +
>> +??? };
>> +
>> +User of minidump can pass ``qcom_scm.download_mode="mini"`` to kernel
>> +commandline to set the current download mode to minidump.
> 
> "A kernel command line parameter is provided 
> ``qcom_scm.download_mode="mini"`` to facilitate ... but you aren't 
> telling us what "minidump" captures "the current download" ? do you mean 
> the current state ?

Minidump is a SoC solution and not specific to linux(APSS) so even if
there is no APSS linux driver to capture linux specific regions,
firmware like ADSP/CDSP/MODEM or Trustzone or boot loader still 
registers their own regions that get captured and you will get them on 
crash. If there is no registration from anywhere it will not dump
anything.

> 
> Does the system continue to boot up if you pass 
> qcom_scm.download_mode="mini ? will additional registrations to 
> SMEM/Minidump work ?

yes, it will continue to boot, this parameter just convert the
capture mode from full dump (entire ddr dump ) to minidump (smem)
registered region dump.

Yes, additional registration of linux region to SMEM will work.

> 
> What happens to the minidump data if there is a _subsequent_ real 
> crashdump ?

By passing qcom_scm.download_mode="mini" we are converting crash dump
mode from full(complete ddr) to minidump.
> 
> Overwritten ?
> 
> Also what happens if SMEM runs out of space ? Say I boot with 
> ``qcom_scm.download_mode="mini"`` and then the system crashes - SMEM has 
> a limit right ?
> 
> So the minidump gets overwritten ?

I think, is this after your confusion full dump also gets written to
SMEM ?

if this crashes before qcom_scm.download_mode="mini" mode was set then
full ramdump gets collected which is default gets set from the firmware
however, it is also possible to set minidump by default from the
firmware, but let's no go into that detail.

> 
>> +Similarly, ``"full"`` is passed to set the download mode to full dump
>> +where entire RAM dump will be collected while setting it ``"full,mini"``
>> +will collect minidump along with fulldump.
> 
> Still not super-clear what the difference between mini and full is here.

It should be clear by now.

> 
>> +
>> +Writing to sysfs node can also be used to set the mode to minidump::
>> +
>> +??? echo "mini" > /sys/module/qcom_scm/parameter/download_mode
>> +
>> +Once the download mode is set, any kind of crash will make the device 
>> collect
>> +respective dump as per set download mode.
> 
> Nice.
> 
>> +
>> +Dump collection
>> +---------------
>> +::
>> +
>> +??? +-----------+
>> +??? |?????????? |
>> +??? |?????????? |???????? +------+
>> +??? |?????????? |???????? |????? |
>> +??? |?????????? |???????? +--+---+ Product(Qualcomm SoC)
>> +??? +-----------+???????????? |
>> +??? |+++++++++++|<------------+
>> +??? |+++++++++++|??? usb cable
>> +??? +-----------+
>> +??????????? x86_64 PC
>> +
>> +The solution supports a product running with Qualcomm SoC (where 
>> minidump)
>> +is supported from the firmware) connected to x86_64 host PC running PCAT
>> +tool.
> 
> It supports downloading the minidump produced from product to the
>> +host PC over USB or to save the minidump to the product attached storage
>> +device(UFS/eMMC/SD Card) into minidump dedicated partition.
> 
> It would be a good idea to reference this section earlier.

Ok.

Thanks again, for going into such minute detail and asking these questions.

I really appriciate the interest.

-Mukesh

> 
>> +
>> +By default, dumps are downloaded via USB to the attached x86_64 PC 
>> running
>> +PCAT (Qualcomm tool) software. Upon download, we will see a set of 
>> binary
>> +blobs starting with name ``md_*`` in PCAT configured directory in x86_64
>> +machine, so for above example from the client it will be 
>> ``md_REGION_A.BIN``.
>> +This binary blob depends on region content to determine whether it needs
>> +external parser support to get the content of the region, so for simple
>> +plain ASCII text we don't need any parsing and the content can be seen
>> +just opening the binary file.
>> +
>> +To collect the dump to attached storage type, one needs to write 
>> appropriate
>> +value to IMEM register, in that case dumps are collected in rawdump
>> +partition on the product device itself.
>> +
>> +One needs to read the entire rawdump partition and pull out content to
>> +save it onto the attached x86_64 machine over USB. Later, this rawdump
>> +can be passed to another tool (``dexter.exe`` [Qualcomm tool]) which
>> +converts this into the similar binary blobs which we have got it when
>> +download type was set to USB, i.e. a set of registered regions as blobs
>> +and their name starts with ``md_*``.
>> +
>> +Replacing the ``dexter.exe`` with some open source tool can be added 
>> as future
>> +scope of this document.
> 
> ---
> bod


From will at kernel.org  Mon Dec 11 05:21:27 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 13:21:27 +0000
Subject: [PATCH 13/21] arm64: convert to arch_cpu_is_hotpluggable()
In-Reply-To: <E1r5R3g-00Cszg-PP@rmk-PC.armlinux.org.uk>
References: <ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk>
 <E1r5R3g-00Cszg-PP@rmk-PC.armlinux.org.uk>
Message-ID: <20231211132127.GD25681@willie-the-truck>

On Tue, Nov 21, 2023 at 01:44:56PM +0000, Russell King (Oracle) wrote:
> Convert arm64 to use the arch_cpu_is_hotpluggable() helper rather than
> arch_register_cpu().
> 
> Reviewed-by: Shaoqin Huang <shahuang at redhat.com>
> Reviewed-by: Gavin Shan <gshan at redhat.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> ---
>  arch/arm64/kernel/setup.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 165bd2c0dd5a..42c690bb2d60 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -402,13 +402,9 @@ static inline bool cpu_can_disable(unsigned int cpu)
>  	return false;
>  }
>  
> -int arch_register_cpu(int num)
> +bool arch_cpu_is_hotpluggable(int num)
>  {
> -	struct cpu *cpu = &per_cpu(cpu_devices, num);
> -
> -	cpu->hotpluggable = cpu_can_disable(num);
> -
> -	return register_cpu(cpu, num);
> +	return cpu_can_disable(num);
>  }
>  
>  static void dump_kernel_offset(void)

Acked-by: Will Deacon <will at kernel.org>

Will


From vaishnav.a at ti.com  Mon Dec 11 05:26:00 2023
From: vaishnav.a at ti.com (Vaishnav Achath)
Date: Mon, 11 Dec 2023 18:56:00 +0530
Subject: [PATCH] soc: ti: k3-socinfo: Add JTAG ID for J722S
Message-ID: <20231211132600.25289-1-vaishnav.a@ti.com>

Add JTAG ID info for the J722S SoC family to enable SoC detection.

More details about this SoC can be found in the TRM:
	https://www.ti.com/lit/zip/sprujb3

Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
---

Bootlog with changes:
https://gist.github.com/vaishnavachath/23d859925277df9ccd628190e7c23371

 drivers/soc/ti/k3-socinfo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
index 7517a9c8c8fa..59101bf7cf23 100644
--- a/drivers/soc/ti/k3-socinfo.c
+++ b/drivers/soc/ti/k3-socinfo.c
@@ -42,6 +42,7 @@
 #define JTAG_ID_PARTNO_J784S4		0xBB80
 #define JTAG_ID_PARTNO_AM62AX		0xBB8D
 #define JTAG_ID_PARTNO_AM62PX		0xBB9D
+#define JTAG_ID_PARTNO_J722S		0xBBA0
 
 static const struct k3_soc_id {
 	unsigned int id;
@@ -56,6 +57,7 @@ static const struct k3_soc_id {
 	{ JTAG_ID_PARTNO_J784S4, "J784S4" },
 	{ JTAG_ID_PARTNO_AM62AX, "AM62AX" },
 	{ JTAG_ID_PARTNO_AM62PX, "AM62PX" },
+	{ JTAG_ID_PARTNO_J722S, "J722S" },
 };
 
 static const char * const j721e_rev_string_map[] = {
-- 
2.17.1



From will at kernel.org  Mon Dec 11 05:27:57 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 13:27:57 +0000
Subject: [PATCH 3/7] ACPI/IORT: Handle memory address size limits as
 limits
In-Reply-To: <2ae6199a9cf035c1defd42e48675b827f41cdc95.1701268753.git.robin.murphy@arm.com>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <2ae6199a9cf035c1defd42e48675b827f41cdc95.1701268753.git.robin.murphy@arm.com>
Message-ID: <20231211132757.GE25681@willie-the-truck>

On Wed, Nov 29, 2023 at 05:43:00PM +0000, Robin Murphy wrote:
> Return the Root Complex/Named Component memory address size limit as an
> inclusive limit value, rather than an exclusive size.  This saves us
> having to special-case 64-bit overflow, and simplifies our caller too.
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/acpi/arm64/dma.c  |  9 +++------
>  drivers/acpi/arm64/iort.c | 18 ++++++++----------
>  include/linux/acpi_iort.h |  4 ++--
>  3 files changed, 13 insertions(+), 18 deletions(-)

[...]

> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 6496ff5a6ba2..eb64d8e17dd1 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1367,7 +1367,7 @@ int iort_iommu_configure_id(struct device *dev, const u32 *input_id)
>  { return -ENODEV; }
>  #endif
>  
> -static int nc_dma_get_range(struct device *dev, u64 *size)
> +static int nc_dma_get_range(struct device *dev, u64 *limit)
>  {
>  	struct acpi_iort_node *node;
>  	struct acpi_iort_named_component *ncomp;
> @@ -1384,13 +1384,12 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
>  		return -EINVAL;
>  	}
>  
> -	*size = ncomp->memory_address_limit >= 64 ? U64_MAX :
> -			1ULL<<ncomp->memory_address_limit;
> +	*limit = (1ULL << ncomp->memory_address_limit) - 1;

The old code handled 'ncomp->memory_address_limit >= 64' -- why is it safe
to drop that? You mention it in the cover letter, so clearly I'm missing
something!

>  
>  	return 0;
>  }
>  
> -static int rc_dma_get_range(struct device *dev, u64 *size)
> +static int rc_dma_get_range(struct device *dev, u64 *limit)
>  {
>  	struct acpi_iort_node *node;
>  	struct acpi_iort_root_complex *rc;
> @@ -1408,8 +1407,7 @@ static int rc_dma_get_range(struct device *dev, u64 *size)
>  		return -EINVAL;
>  	}
>  
> -	*size = rc->memory_address_limit >= 64 ? U64_MAX :
> -			1ULL<<rc->memory_address_limit;
> +	*limit = (1ULL << rc->memory_address_limit) - 1;

Same thing here.

Will


From quic_kathirav at quicinc.com  Mon Dec 11 05:28:03 2023
From: quic_kathirav at quicinc.com (Kathiravan Thirumoorthy)
Date: Mon, 11 Dec 2023 18:58:03 +0530
Subject: [PATCH v3 7/8] arm64: dts: qcom: ipq5332: add support for the
 NSSCC
In-Reply-To: <c4034715-53a5-468e-914a-3f19d0618c42@linaro.org>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
 <20231211-ipq5332-nsscc-v3-7-ad13bef9b137@quicinc.com>
 <c4034715-53a5-468e-914a-3f19d0618c42@linaro.org>
Message-ID: <8cc2a8ec-632e-4e3b-b13b-d1523a61c136@quicinc.com>



On 12/11/2023 4:02 PM, Konrad Dybcio wrote:
> On 11.12.2023 04:37, Kathiravan Thirumoorthy wrote:
>> Describe the NSS clock controller node and it's relevant external
>> clocks.
>>
>> Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
>> ---
>>   arch/arm64/boot/dts/qcom/ipq5332.dtsi | 28 ++++++++++++++++++++++++++++
>>   1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
>> index 42e2e48b2bc3..a1504f6c40c1 100644
>> --- a/arch/arm64/boot/dts/qcom/ipq5332.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
>> @@ -15,6 +15,18 @@ / {
>>   	#size-cells = <2>;
>>   
>>   	clocks {
>> +		cmn_pll_nss_200m_clk: cmn-pll-nss-200m-clk {
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <200000000>;
>> +			#clock-cells = <0>;
>> +		};
>> +
>> +		cmn_pll_nss_300m_clk: cmn-pll-nss-300m-clk {
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <300000000>;
>> +			#clock-cells = <0>;
>> +		};
>> +
>>   		sleep_clk: sleep-clk {
>>   			compatible = "fixed-clock";
>>   			#clock-cells = <0>;
>> @@ -473,6 +485,22 @@ frame at b128000 {
>>   				status = "disabled";
>>   			};
>>   		};
>> +
>> +		nsscc: clock-controller at 39b00000{
> Missing space between the opening curly brace

My bad :( will fix it in next spin.

> 
>> +			compatible = "qcom,ipq5332-nsscc";
>> +			reg = <0x39b00000 0x80000>;
> the regmap_config in the clk driver has .max_register = 0x800, is this
> correct?

As per the memory map, 512KB is the size of this block. However the last 
register in that region is at the offset 0x800. Shall I update the 
max_register also to 512KB to keep it consistency?


> 
> 
> Konrad


From amit.kumar-mahapatra at amd.com  Mon Dec 11 05:37:10 2023
From: amit.kumar-mahapatra at amd.com (Mahapatra, Amit Kumar)
Date: Mon, 11 Dec 2023 13:37:10 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
Message-ID: <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>



> -----Original Message-----
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> Sent: Monday, December 11, 2023 3:05 PM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> michael at walle.cc; linux-mtd at lists.infradead.org;
> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
> in spi-nor
> 
> 
> 
> On 12/11/23 06:56, Mahapatra, Amit Kumar wrote:
> >
> >
> >> -----Original Message-----
> >> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> >> Sent: Monday, December 11, 2023 9:03 AM
> >> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> >> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> >> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> >> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> >> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> >> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> >> michael at walle.cc; linux-mtd at lists.infradead.org;
> >> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> >> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>;
> >> linux- arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> >> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> >> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> >> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories
> >> support in spi-nor
> >>
> >>
> >>
> >> On 12/8/23 17:05, Mahapatra, Amit Kumar wrote:
> >>> Hello Tudor,
> >>
> >> Hi!
> >
> > Hello Tudor,
> >
> 
> Hi!

Hello Tudor,
> 
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> >>>> Sent: Wednesday, December 6, 2023 8:00 PM
> >>>> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> >>>> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> >>>> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> >>>> lee at kernel.org; james.schulman at cirrus.com;
> david.rhodes at cirrus.com;
> >>>> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> >>>> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> >>>> michael at walle.cc; linux-mtd at lists.infradead.org;
> >>>> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> >>>> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>;
> >>>> linux- arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> >>>> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git
> >>>> (AMD-
> >>>> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> >>>> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories
> >>>> support in spi-nor
> >>>>
> >>>> Hi, Amit,
> >>>>
> >>>> On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
> >>>>> Each flash that is connected in stacked mode should have a
> >>>>> separate parameter structure. So, the flash parameter
> >>>>> member(*params) of the spi_nor structure is changed to an array
> >>>>> (*params[2]). The array is used to store the parameters of each
> >>>>> flash connected in stacked
> >>>> configuration.
> >>>>>
> >>>>> The current implementation assumes that a maximum of two flashes
> >>>>> are connected in stacked mode and both the flashes are of same
> >>>>> make but can differ in sizes. So, except the sizes all other flash
> >>>>> parameters of both the flashes are identical.
> >>>>
> >>>> Do you plan to add support for different flashes in stacked mode?
> >>>> If not,
> >>>
> >>> No, according to the current implementation, in stacked mode, both
> >>> flashes must be of the same make.
> >>>
> >>>> wouldn't it be simpler to have just an array of flash sizes instead
> >>>> of duplicating the entire params struct?
> >>>
> >>> Yes, that is accurate. In alignment with our current stacked support
> >>> use case we can have an array of flash sizes instead.
> >>> The primary purpose of having an array of params struct was to
> >>> facilitate potential future extensions, allowing the addition of
> >>> stacked support for different flashes
> >>>
> >>
> >> right. Don't do this change yet, let's decide on the overall architecture first.
> >
> > Sure.
> >>
> >>>>
> >>>>>
> >>>>> SPI-NOR is not aware of the chip_select values, for any incoming
> >>>>> request SPI-NOR will decide the flash index with the help of
> >>>>> individual flash size and the configuration type (single/stacked).
> >>>>> SPI-NOR will pass on the flash index information to the SPI core &
> >>>>> SPI driver by setting the appropriate bit in
> >>>>> nor->spimem->spi->cs_index_mask. For example, if nth bit of
> >>>>> nor->spimem->spi->cs_index_mask is set then the driver would
> >>>>> assert/de-assert spi->chip_slect[n].
> >>>>>
> >>>>> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
> >> mahapatra at amd.com>
> >>>>> ---
> >>>>>  drivers/mtd/spi-nor/core.c  | 272
> >>>>> +++++++++++++++++++++++++++++-----
> >> --
> >>>>>  drivers/mtd/spi-nor/core.h  |   4 +
> >>>>>  include/linux/mtd/spi-nor.h |  15 +-
> >>>>>  3 files changed, 240 insertions(+), 51 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/mtd/spi-nor/core.c
> >>>>> b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6
> >>>>> 100644
> >>>>> --- a/drivers/mtd/spi-nor/core.c
> >>>>> +++ b/drivers/mtd/spi-nor/core.c
> >>>>
> >>>> cut
> >>>>
> >>>>> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct
> >>>>> spi_nor *nor)  static int spi_nor_late_init_params(struct spi_nor
> >>>>> *nor)  {
> >>>>>  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
> >>>> 0);
> >>>>> -	int ret;
> >>>>> +	struct device_node *np = spi_nor_get_flash_node(nor);
> >>>>> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
> >>>>> +	u32 idx = 0;
> >>>>> +	int rc, ret;
> >>>>>
> >>>>>  	if (nor->manufacturer && nor->manufacturer->fixups &&
> >>>>>  	    nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44
> >>>>> @@ static int spi_nor_late_init_params(struct spi_nor *nor)
> >>>>>  	if (params->n_banks > 1)
> >>>>>  		params->bank_size = div64_u64(params->size, params-
> >> n_banks);
> >>>>>
> >>>>> +	nor->num_flash = 0;
> >>>>> +
> >>>>> +	/*
> >>>>> +	 * The flashes that are connected in stacked mode should be
> of
> >>>>> +same
> >>>> make.
> >>>>> +	 * Except the flash size all other properties are identical for all
> the
> >>>>> +	 * flashes connected in stacked mode.
> >>>>> +	 * The flashes that are connected in parallel mode should be
> identical.
> >>>>> +	 */
> >>>>> +	while (idx < SNOR_FLASH_CNT_MAX) {
> >>>>> +		rc = of_property_read_u64_index(np, "stacked-
> memories",
> >>>> idx,
> >>>>> +&flash_size[idx]);
> >>>>
> >>>> This is a little late in my opinion, as we don't have any sanity
> >>>> check on the flashes that are stacked on top of the first. We shall
> >>>> at least read and compare the ID for all.
> >>>
> >>> Alright, I will incorporate a sanity check for reading and comparing
> >>> the ID of the stacked flash. Subsequently, I believe this stacked
> >>> logic should be relocated to spi_nor_get_flash_info() where we
> >>> identify the first flash. Please share your thoughts on this.
> >>> Additionally, do you
> >>
> >> I'm wondering whether we can add a layer on top of the flash type to
> >> handle
> >
> > When you mention "on top," are you referring to incorporating it into
> > the MTD layer? Initially, Miquel had submitted this patch to address
> 
> I mean something above SPI MEM flashes, be it NOR, NANDs or whatever.
> Instead of treating the stacked flashes as a monolithic device and treat in SPI
> NOR some array of flashes, to have a layer above which probes the SPI MEM
> flash driver for each stacked flash. In your case SPI NOR would be probed
> twice, as you use 2 SPI NOR flashes.
> 
> > stacked/parallel handling in the MTD layer.
> > https://lore.kernel.org/linux-mtd/20200114191052.0a16d116 at xps13/t/
> > However, the Device Tree bindings were initially not accepted.
> 
> Okay, thanks for the pointer. I'll take a look.
> 
> > Following a series of discussions, the below bindings were eventually
> > merged.
> > https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal at boot
> > lin.com/
> 
> I saw, thanks.
> 
> >
> >> the stacked/parallel modes. This way everything will become flash
> >> type independent. Would it be possible to stack 2 SPI NANDs? How
> >> about a SPI NOR and a SPI NAND?
> >>
> >> Is the datasheet of the controller public?
> >
> > Yes,
> > https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Control
> > ler
> >
> 
> Wonderful, I'll take a look. I see two clocks there. Does this mean that the
> stacked flashes can be operated at different frequencies? Do you know if we

In stacked configuration, both flashes utilize a common clock (single 
clock line). In a parallel setup, the flashes share the same clock but 
have distinct clock lines. Please refer the diagrams in the sections 
below for reference.
https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Interface-Diagrams
> can combine a SPI NOR with a SPI NAND in stacked configuration?

No, Xilinx/AMD QSPI controllers doesn't support this configuration.

Regards,
Amit
> 
> I need to study this a bit. I'll try to involve Michael and Pratyush too.
> 
> Cheers,
> ta

From olteanv at gmail.com  Mon Dec 11 05:40:08 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Mon, 11 Dec 2023 15:40:08 +0200
Subject: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
 <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
References: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
 <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
Message-ID: <20231211134008.lbtm6pjtufkhtvfj@skbuf>

Hi Jianheng,

On Mon, Dec 11, 2023 at 06:13:21AM +0000, Jianheng Zhang wrote:
> Adds the HW specific support for Frame Preemption handshaking on XGMAC3+
> cores.
> 
> Signed-off-by: Jianheng Zhang <Jianheng.Zhang at synopsys.com>
> ---

It's nice to see contributions from Synopsys!

Have you seen the (relatively newly introduced) common framework for
Frame Preemption and the MAC Merge layer?
https://docs.kernel.org/networking/ethtool-netlink.html#mm-get
https://man7.org/linux/man-pages/man8/ethtool.8.html
https://man7.org/linux/man-pages/man8/tc-mqprio.8.html # "fp" option
https://man7.org/linux/man-pages/man8/tc-taprio.8.html # "fp" option

I think it would be valuable if the stmmac driver would also use it, so
it could support openlldp and pass the selftest at
https://github.com/torvalds/linux/blob/master/tools/testing/selftests/net/forwarding/ethtool_mm.sh


From sashal at kernel.org  Mon Dec 11 05:50:06 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:50:06 -0500
Subject: [PATCH AUTOSEL 6.6 05/47] arm64: dts: rockchip: fix rk356x pcie msg interrupt name
In-Reply-To: <20231211135147.380223-1-sashal@kernel.org>
References: <20231211135147.380223-1-sashal@kernel.org>
Message-ID: <20231211135147.380223-5-sashal@kernel.org>

From: Heiko Stuebner <heiko at sntech.de>

[ Upstream commit 3cee9c635f27d1003d46f624d816f3455698b625 ]

The expected name by the binding at this position is "msg" and the SoC's
manual also calls the interrupt in question "msg", so fix the rk356x dtsi
to use the correct name.

Reviewed-by: Sebastian Reichel <sebastian.reichel at collabora.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Link: https://lore.kernel.org/r/20231114153834.934978-1-heiko at sntech.de
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index abee88911982d..b7e2b475f0707 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -970,7 +970,7 @@ pcie2x1: pcie at fe260000 {
 			     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-names = "sys", "pmc", "msi", "legacy", "err";
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
 		bus-range = <0x0 0xf>;
 		clocks = <&cru ACLK_PCIE20_MST>, <&cru ACLK_PCIE20_SLV>,
 			 <&cru ACLK_PCIE20_DBI>, <&cru PCLK_PCIE20>,
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:50:15 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:50:15 -0500
Subject: [PATCH AUTOSEL 6.6 14/47] ASoC: SOF: mediatek: mt8186: Add Google Steelix topology compatible
In-Reply-To: <20231211135147.380223-1-sashal@kernel.org>
References: <20231211135147.380223-1-sashal@kernel.org>
Message-ID: <20231211135147.380223-14-sashal@kernel.org>

From: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>

[ Upstream commit 505c83212da5bfca95109421b8f5d9f8c6cdfef2 ]

Add the machine compatible and topology filename for the Google Steelix
MT8186 Chromebook to load the correct SOF topology file.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Link: https://lore.kernel.org/r/20231123084454.20471-1-angelogioacchino.delregno at collabora.com
Signed-off-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 sound/soc/sof/mediatek/mt8186/mt8186.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/sof/mediatek/mt8186/mt8186.c b/sound/soc/sof/mediatek/mt8186/mt8186.c
index f587edf9e0a70..35f5c2cfb6e45 100644
--- a/sound/soc/sof/mediatek/mt8186/mt8186.c
+++ b/sound/soc/sof/mediatek/mt8186/mt8186.c
@@ -599,6 +599,9 @@ static struct snd_sof_dsp_ops sof_mt8186_ops = {
 
 static struct snd_sof_of_mach sof_mt8186_machs[] = {
 	{
+		.compatible = "google,steelix",
+		.sof_tplg_filename = "sof-mt8186-google-steelix.tplg"
+	}, {
 		.compatible = "mediatek,mt8186",
 		.sof_tplg_filename = "sof-mt8186.tplg",
 	},
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:50:36 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:50:36 -0500
Subject: [PATCH AUTOSEL 6.6 35/47] arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru
In-Reply-To: <20231211135147.380223-1-sashal@kernel.org>
References: <20231211135147.380223-1-sashal@kernel.org>
Message-ID: <20231211135147.380223-35-sashal@kernel.org>

From: Rob Herring <robh at kernel.org>

[ Upstream commit c13c823a78b77ea0e5f1f73112d910e259911101 ]

The rk3399-gru PCI node addresses are wrong.

In rk3399-gru-scarlet, the bus number in the address should be 0. This is
because bus number assignment is dynamic and not known up front. For FDT,
the bus number is simply ignored.

In rk3399-gru-chromebook, the addresses are simply invalid. The first
"reg" entry must be the configuration space for the device. The entry
should be all 0s except for device/slot and function numbers. The existing
64-bit memory space (0x83000000) entries are not valid because they must
have the BAR address in the lower byte of the first cell.

Warnings for these are enabled by adding the missing 'device_type = "pci"'
for the root port node.

Signed-off-by: Rob Herring <robh at kernel.org>
Link: https://lore.kernel.org/r/20231130191830.2424361-1-robh at kernel.org
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi  | 3 +--
 arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts | 4 ++--
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi             | 1 +
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
index 5c1929d41cc0b..cacbad35cfc85 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -509,8 +509,7 @@ wacky_spi_audio: spi2 at 0 {
 &pci_rootport {
 	mvl_wifi: wifi at 0,0 {
 		compatible = "pci1b4b,2b42";
-		reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
-		       0x83010000 0x0 0x00100000 0x0 0x00100000>;
+		reg = <0x0000 0x0 0x0 0x0 0x0>;
 		interrupt-parent = <&gpio0>;
 		interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts
index 853e88455e750..9e4b12ed62cbe 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts
@@ -34,8 +34,8 @@ &mipi_panel {
 &pci_rootport {
 	wifi at 0,0 {
 		compatible = "qcom,ath10k";
-		reg = <0x00010000 0x0 0x00000000 0x0 0x00000000>,
-		      <0x03010010 0x0 0x00000000 0x0 0x00200000>;
+		reg = <0x00000000 0x0 0x00000000 0x0 0x00000000>,
+		      <0x03000010 0x0 0x00000000 0x0 0x00200000>;
 		qcom,ath10k-calibration-variant = "GO_DUMO";
 	};
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index c9bf1d5c3a426..789fd0dcc88ba 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -489,6 +489,7 @@ pci_rootport: pcie at 0,0 {
 		#address-cells = <3>;
 		#size-cells = <2>;
 		ranges;
+		device_type = "pci";
 	};
 };
 
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:50:42 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:50:42 -0500
Subject: [PATCH AUTOSEL 6.6 41/47] drm/exynos: fix a potential error pointer dereference
In-Reply-To: <20231211135147.380223-1-sashal@kernel.org>
References: <20231211135147.380223-1-sashal@kernel.org>
Message-ID: <20231211135147.380223-41-sashal@kernel.org>

From: Xiang Yang <xiangyang3 at huawei.com>

[ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]

Smatch reports the warning below:
drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
error: 'crtc' dereferencing possible ERR_PTR()

The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
which can not be used directly. Fix this by checking the return value
before using it.

Signed-off-by: Xiang Yang <xiangyang3 at huawei.com>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f3aaa4ea3e682..dd9903eab563e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1861,6 +1861,8 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
 		return ret;
 
 	crtc = exynos_drm_crtc_get_by_type(drm_dev, EXYNOS_DISPLAY_TYPE_HDMI);
+	if (IS_ERR(crtc))
+		return PTR_ERR(crtc);
 	crtc->pipe_clk = &hdata->phy_clk;
 
 	ret = hdmi_create_connector(encoder);
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:50:43 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:50:43 -0500
Subject: [PATCH AUTOSEL 6.6 42/47] drm/exynos: fix a wrong error checking
In-Reply-To: <20231211135147.380223-1-sashal@kernel.org>
References: <20231211135147.380223-1-sashal@kernel.org>
Message-ID: <20231211135147.380223-42-sashal@kernel.org>

From: Inki Dae <inki.dae at samsung.com>

[ Upstream commit 8d1b7809684c688005706125b804e1f9792d2b1b ]

Fix a wrong error checking in exynos_drm_dma.c module.

In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
and iommu_get_domain_for_dev() functions are expected to return NULL as
an error.

However, the error checking is performed using the statement
if(IS_ERR(mapping)), which doesn't provide a suitable error value.
So check if 'mapping' is NULL, and if it is, return -ENODEV.

This issue[1] was reported by Dan.

Changelog v1:
- fix build warning.

[1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf at moroto.mountain/

Reported-by : Dan Carpenter <dan.carpenter at linaro.org>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c b/drivers/gpu/drm/exynos/exynos_drm_dma.c
index a971590b81323..e2c7373f20c6b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
@@ -107,18 +107,16 @@ int exynos_drm_register_dma(struct drm_device *drm, struct device *dev,
 		return 0;
 
 	if (!priv->mapping) {
-		void *mapping;
+		void *mapping = NULL;
 
 		if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))
 			mapping = arm_iommu_create_mapping(&platform_bus_type,
 				EXYNOS_DEV_ADDR_START, EXYNOS_DEV_ADDR_SIZE);
 		else if (IS_ENABLED(CONFIG_IOMMU_DMA))
 			mapping = iommu_get_domain_for_dev(priv->dma_dev);
-		else
-			mapping = ERR_PTR(-ENODEV);
 
-		if (IS_ERR(mapping))
-			return PTR_ERR(mapping);
+		if (!mapping)
+			return -ENODEV;
 		priv->mapping = mapping;
 	}
 
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:53:48 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:53:48 -0500
Subject: [PATCH AUTOSEL 6.1 04/29] arm64: dts: rockchip: fix rk356x pcie msg interrupt name
In-Reply-To: <20231211135457.381397-1-sashal@kernel.org>
References: <20231211135457.381397-1-sashal@kernel.org>
Message-ID: <20231211135457.381397-4-sashal@kernel.org>

From: Heiko Stuebner <heiko at sntech.de>

[ Upstream commit 3cee9c635f27d1003d46f624d816f3455698b625 ]

The expected name by the binding at this position is "msg" and the SoC's
manual also calls the interrupt in question "msg", so fix the rk356x dtsi
to use the correct name.

Reviewed-by: Sebastian Reichel <sebastian.reichel at collabora.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Link: https://lore.kernel.org/r/20231114153834.934978-1-heiko at sntech.de
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 234b5bbda1204..f4d6dbbbddcd4 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -958,7 +958,7 @@ pcie2x1: pcie at fe260000 {
 			     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-names = "sys", "pmc", "msi", "legacy", "err";
+		interrupt-names = "sys", "pmc", "msg", "legacy", "err";
 		bus-range = <0x0 0xf>;
 		clocks = <&cru ACLK_PCIE20_MST>, <&cru ACLK_PCIE20_SLV>,
 			 <&cru ACLK_PCIE20_DBI>, <&cru PCLK_PCIE20>,
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:53:55 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:53:55 -0500
Subject: [PATCH AUTOSEL 6.1 11/29] ASoC: SOF: mediatek: mt8186: Add Google Steelix topology compatible
In-Reply-To: <20231211135457.381397-1-sashal@kernel.org>
References: <20231211135457.381397-1-sashal@kernel.org>
Message-ID: <20231211135457.381397-11-sashal@kernel.org>

From: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>

[ Upstream commit 505c83212da5bfca95109421b8f5d9f8c6cdfef2 ]

Add the machine compatible and topology filename for the Google Steelix
MT8186 Chromebook to load the correct SOF topology file.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Link: https://lore.kernel.org/r/20231123084454.20471-1-angelogioacchino.delregno at collabora.com
Signed-off-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 sound/soc/sof/mediatek/mt8186/mt8186.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/sof/mediatek/mt8186/mt8186.c b/sound/soc/sof/mediatek/mt8186/mt8186.c
index 181189e00e020..76ce90e1f1030 100644
--- a/sound/soc/sof/mediatek/mt8186/mt8186.c
+++ b/sound/soc/sof/mediatek/mt8186/mt8186.c
@@ -596,6 +596,9 @@ static struct snd_sof_dsp_ops sof_mt8186_ops = {
 
 static struct snd_sof_of_mach sof_mt8186_machs[] = {
 	{
+		.compatible = "google,steelix",
+		.sof_tplg_filename = "sof-mt8186-google-steelix.tplg"
+	}, {
 		.compatible = "mediatek,mt8186",
 		.sof_tplg_filename = "sof-mt8186.tplg",
 	},
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:54:05 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:54:05 -0500
Subject: [PATCH AUTOSEL 6.1 21/29] arm64: dts: rockchip: Fix PCI node addresses on rk3399-gru
In-Reply-To: <20231211135457.381397-1-sashal@kernel.org>
References: <20231211135457.381397-1-sashal@kernel.org>
Message-ID: <20231211135457.381397-21-sashal@kernel.org>

From: Rob Herring <robh at kernel.org>

[ Upstream commit c13c823a78b77ea0e5f1f73112d910e259911101 ]

The rk3399-gru PCI node addresses are wrong.

In rk3399-gru-scarlet, the bus number in the address should be 0. This is
because bus number assignment is dynamic and not known up front. For FDT,
the bus number is simply ignored.

In rk3399-gru-chromebook, the addresses are simply invalid. The first
"reg" entry must be the configuration space for the device. The entry
should be all 0s except for device/slot and function numbers. The existing
64-bit memory space (0x83000000) entries are not valid because they must
have the BAR address in the lower byte of the first cell.

Warnings for these are enabled by adding the missing 'device_type = "pci"'
for the root port node.

Signed-off-by: Rob Herring <robh at kernel.org>
Link: https://lore.kernel.org/r/20231130191830.2424361-1-robh at kernel.org
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi  | 3 +--
 arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts | 4 ++--
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi             | 1 +
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
index ee6095baba4d3..7d9b8064ad2ec 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -510,8 +510,7 @@ wacky_spi_audio: spi2 at 0 {
 &pci_rootport {
 	mvl_wifi: wifi at 0,0 {
 		compatible = "pci1b4b,2b42";
-		reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
-		       0x83010000 0x0 0x00100000 0x0 0x00100000>;
+		reg = <0x0000 0x0 0x0 0x0 0x0>;
 		interrupt-parent = <&gpio0>;
 		interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts
index 853e88455e750..9e4b12ed62cbe 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dts
@@ -34,8 +34,8 @@ &mipi_panel {
 &pci_rootport {
 	wifi at 0,0 {
 		compatible = "qcom,ath10k";
-		reg = <0x00010000 0x0 0x00000000 0x0 0x00000000>,
-		      <0x03010010 0x0 0x00000000 0x0 0x00200000>;
+		reg = <0x00000000 0x0 0x00000000 0x0 0x00000000>,
+		      <0x03000010 0x0 0x00000000 0x0 0x00200000>;
 		qcom,ath10k-calibration-variant = "GO_DUMO";
 	};
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 23bfba86daabe..7ba25315dd9ab 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -489,6 +489,7 @@ pci_rootport: pcie at 0,0 {
 		#address-cells = <3>;
 		#size-cells = <2>;
 		ranges;
+		device_type = "pci";
 	};
 };
 
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:54:10 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:54:10 -0500
Subject: [PATCH AUTOSEL 6.1 26/29] drm/exynos: fix a potential error pointer dereference
In-Reply-To: <20231211135457.381397-1-sashal@kernel.org>
References: <20231211135457.381397-1-sashal@kernel.org>
Message-ID: <20231211135457.381397-26-sashal@kernel.org>

From: Xiang Yang <xiangyang3 at huawei.com>

[ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]

Smatch reports the warning below:
drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
error: 'crtc' dereferencing possible ERR_PTR()

The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
which can not be used directly. Fix this by checking the return value
before using it.

Signed-off-by: Xiang Yang <xiangyang3 at huawei.com>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index b7c11bdce2c89..1a7194a653ae5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1861,6 +1861,8 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
 		return ret;
 
 	crtc = exynos_drm_crtc_get_by_type(drm_dev, EXYNOS_DISPLAY_TYPE_HDMI);
+	if (IS_ERR(crtc))
+		return PTR_ERR(crtc);
 	crtc->pipe_clk = &hdata->phy_clk;
 
 	ret = hdmi_create_connector(encoder);
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:54:11 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:54:11 -0500
Subject: [PATCH AUTOSEL 6.1 27/29] drm/exynos: fix a wrong error checking
In-Reply-To: <20231211135457.381397-1-sashal@kernel.org>
References: <20231211135457.381397-1-sashal@kernel.org>
Message-ID: <20231211135457.381397-27-sashal@kernel.org>

From: Inki Dae <inki.dae at samsung.com>

[ Upstream commit 8d1b7809684c688005706125b804e1f9792d2b1b ]

Fix a wrong error checking in exynos_drm_dma.c module.

In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
and iommu_get_domain_for_dev() functions are expected to return NULL as
an error.

However, the error checking is performed using the statement
if(IS_ERR(mapping)), which doesn't provide a suitable error value.
So check if 'mapping' is NULL, and if it is, return -ENODEV.

This issue[1] was reported by Dan.

Changelog v1:
- fix build warning.

[1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf at moroto.mountain/

Reported-by : Dan Carpenter <dan.carpenter at linaro.org>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c b/drivers/gpu/drm/exynos/exynos_drm_dma.c
index a971590b81323..e2c7373f20c6b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
@@ -107,18 +107,16 @@ int exynos_drm_register_dma(struct drm_device *drm, struct device *dev,
 		return 0;
 
 	if (!priv->mapping) {
-		void *mapping;
+		void *mapping = NULL;
 
 		if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))
 			mapping = arm_iommu_create_mapping(&platform_bus_type,
 				EXYNOS_DEV_ADDR_START, EXYNOS_DEV_ADDR_SIZE);
 		else if (IS_ENABLED(CONFIG_IOMMU_DMA))
 			mapping = iommu_get_domain_for_dev(priv->dma_dev);
-		else
-			mapping = ERR_PTR(-ENODEV);
 
-		if (IS_ERR(mapping))
-			return PTR_ERR(mapping);
+		if (!mapping)
+			return -ENODEV;
 		priv->mapping = mapping;
 	}
 
-- 
2.42.0



From mark.rutland at arm.com  Mon Dec 11 05:57:44 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 11 Dec 2023 13:57:44 +0000
Subject: [PATCH v6 04/41] arm64: mm: Move PCI I/O emulation region above
 the vmemmap region
In-Reply-To: <20231129111555.3594833-47-ardb@google.com>
References: <20231129111555.3594833-43-ardb@google.com>
 <20231129111555.3594833-47-ardb@google.com>
Message-ID: <ZXcVWFMr6eUWtEec@FVFF77S0Q05N.cambridge.arm.com>

Hi Ard,

On Wed, Nov 29, 2023 at 12:16:00PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> 
> Move the PCI I/O region above the vmemmap region in the kernel's VA
> space. This will permit us to reclaim the lower part of the vmemmap
> region for vmalloc/vmap allocations when running a 52-bit VA capable
> build on a 48-bit VA capable system.
> 
> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> ---
>  arch/arm64/include/asm/memory.h | 4 ++--
>  arch/arm64/mm/ptdump.c          | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b8d726f951ae..99caeff78e1a 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -49,8 +49,8 @@
>  #define MODULES_VSIZE		(SZ_2G)
>  #define VMEMMAP_START		(-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
>  #define VMEMMAP_END		(VMEMMAP_START + VMEMMAP_SIZE)
> -#define PCI_IO_END		(VMEMMAP_START - SZ_8M)
> -#define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
> +#define PCI_IO_START		(VMEMMAP_END + SZ_8M)
> +#define PCI_IO_END		(PCI_IO_START + PCI_IO_SIZE)
>  #define FIXADDR_TOP		(VMEMMAP_START - SZ_32M)

This looks simple, but it does have a subtle dependency on VMEMMAP_SIZE being
sufficiently smaller than the negative offset we choose for VMEMMAP_START, and
it took mw a while to convince myself that we always ensure that today. I could
well imagine that we try to reduce that in future (given for most
configurations we're reserving around double the space we actually need), and
it would be nice if we could avoid that going wrong.

We need to make sure that PCI_IO_START and PCI_IO_END fall between VMEMMAP_END
and the last page of the VA space (due to ERR_PTR). Could we add some comment
and/or assertions to that effect?

Mark.

>  
>  #if VA_BITS > 48
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index e305b6593c4e..d1df56d44f8a 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -47,10 +47,10 @@ static struct addr_marker address_markers[] = {
>  	{ VMALLOC_END,			"vmalloc() end" },
>  	{ FIXADDR_TOT_START,		"Fixmap start" },
>  	{ FIXADDR_TOP,			"Fixmap end" },
> -	{ PCI_IO_START,			"PCI I/O start" },
> -	{ PCI_IO_END,			"PCI I/O end" },
>  	{ VMEMMAP_START,		"vmemmap start" },
>  	{ VMEMMAP_START + VMEMMAP_SIZE,	"vmemmap end" },
> +	{ PCI_IO_START,			"PCI I/O start" },
> +	{ PCI_IO_END,			"PCI I/O end" },
>  	{ -1,				NULL },
>  };
>  
> -- 
> 2.43.0.rc1.413.gea7ed67945-goog
> 


From angelogioacchino.delregno at collabora.com  Mon Dec 11 05:59:46 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 11 Dec 2023 14:59:46 +0100
Subject: [PATCH v4 3/4] clk: mediatek: Add pcw_chg_shift control
In-Reply-To: <28c8ccd234ba311591b6db0de131fde36d3ec409.1702158423.git.daniel@makrotopia.org>
References: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
 <28c8ccd234ba311591b6db0de131fde36d3ec409.1702158423.git.daniel@makrotopia.org>
Message-ID: <4fce268c-4ef1-4361-b524-4c9bf9b60370@collabora.com>

Il 09/12/23 22:56, Daniel Golle ha scritto:
> From: Sam Shih <sam.shih at mediatek.com>
> 
> Introduce pcw_chg_shfit control to replace hardcoded PCW_CHG_MASK macro.
> This will needed for clocks on the MT7988 SoC.
> 
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
> v4: always set .pcw_chg_shift if .pcw_chg_reg is used instead of
>      having an if-expression in mtk_pll_set_rate_regs().
> v3: use git --from ...
> v2: no changes
> 
>   drivers/clk/mediatek/clk-mt6779.c            | 1 +
>   drivers/clk/mediatek/clk-mt8183-apmixedsys.c | 1 +
>   drivers/clk/mediatek/clk-mt8188-apmixedsys.c | 1 +
>   drivers/clk/mediatek/clk-mt8192-apmixedsys.c | 1 +
>   drivers/clk/mediatek/clk-mt8195-apmixedsys.c | 1 +
>   drivers/clk/mediatek/clk-mt8365-apmixedsys.c | 1 +
>   drivers/clk/mediatek/clk-pll.c               | 3 +--
>   drivers/clk/mediatek/clk-pll.h               | 2 ++
>   8 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mt6779.c b/drivers/clk/mediatek/clk-mt6779.c
> index ffedb1fe3c672..e66461f341dd3 100644
> --- a/drivers/clk/mediatek/clk-mt6779.c
> +++ b/drivers/clk/mediatek/clk-mt6779.c
> @@ -1166,6 +1166,7 @@ static const struct mtk_gate apmixed_clks[] = {
>   		.pcw_reg = _pcw_reg,					\
>   		.pcw_shift = _pcw_shift,				\
>   		.pcw_chg_reg = _pcw_chg_reg,				\
> +		.pcw_chg_shift = PCW_CHG_SHIFT,				\
>   		.div_table = _div_table,				\
>   	}
>   
> diff --git a/drivers/clk/mediatek/clk-mt8183-apmixedsys.c b/drivers/clk/mediatek/clk-mt8183-apmixedsys.c
> index 2b261c0e2b61d..184e0cd1dde29 100644
> --- a/drivers/clk/mediatek/clk-mt8183-apmixedsys.c
> +++ b/drivers/clk/mediatek/clk-mt8183-apmixedsys.c
> @@ -75,6 +75,7 @@ static const struct mtk_gate apmixed_clks[] = {
>   		.pcw_reg = _pcw_reg,					\
>   		.pcw_shift = _pcw_shift,				\
>   		.pcw_chg_reg = _pcw_chg_reg,				\
> +		.pcw_chg_shift = PCW_CHG_SHIFT,				\
>   		.div_table = _div_table,				\
>   	}
>   
> diff --git a/drivers/clk/mediatek/clk-mt8188-apmixedsys.c b/drivers/clk/mediatek/clk-mt8188-apmixedsys.c
> index 41ab4d6896a49..87c5dfa3d1ac4 100644
> --- a/drivers/clk/mediatek/clk-mt8188-apmixedsys.c
> +++ b/drivers/clk/mediatek/clk-mt8188-apmixedsys.c
> @@ -53,6 +53,7 @@ static const struct mtk_gate apmixed_clks[] = {
>   		.pcw_reg = _pcw_reg,					\
>   		.pcw_shift = _pcw_shift,				\
>   		.pcw_chg_reg = _pcw_chg_reg,				\
> +		.pcw_chg_shift = PCW_CHG_SHIFT,				\
>   		.en_reg = _en_reg,					\
>   		.pll_en_bit = _pll_en_bit,				\
>   	}
> diff --git a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
> index 3590932acc63a..67bf5ef3f0033 100644
> --- a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
> +++ b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
> @@ -56,6 +56,7 @@ static const struct mtk_gate apmixed_clks[] = {
>   		.pcw_reg = _pcw_reg,					\
>   		.pcw_shift = _pcw_shift,				\
>   		.pcw_chg_reg = _pcw_chg_reg,				\
> +		.pcw_chg_shift = PCW_CHG_SHIFT,				\
>   		.en_reg = _en_reg,					\
>   		.pll_en_bit = _pll_en_bit,				\
>   	}
> diff --git a/drivers/clk/mediatek/clk-mt8195-apmixedsys.c b/drivers/clk/mediatek/clk-mt8195-apmixedsys.c
> index 44a4c85a67ef5..ccd6bac7cb1fc 100644
> --- a/drivers/clk/mediatek/clk-mt8195-apmixedsys.c
> +++ b/drivers/clk/mediatek/clk-mt8195-apmixedsys.c
> @@ -54,6 +54,7 @@ static const struct mtk_gate apmixed_clks[] = {
>   		.pcw_reg = _pcw_reg,					\
>   		.pcw_shift = _pcw_shift,				\
>   		.pcw_chg_reg = _pcw_chg_reg,				\
> +		.pcw_chg_shift = PCW_CHG_SHIFT,				\
>   		.en_reg = _en_reg,					\
>   		.pll_en_bit = _pll_en_bit,				\
>   	}
> diff --git a/drivers/clk/mediatek/clk-mt8365-apmixedsys.c b/drivers/clk/mediatek/clk-mt8365-apmixedsys.c
> index 9b0bc5daeac06..daddca6db44e7 100644
> --- a/drivers/clk/mediatek/clk-mt8365-apmixedsys.c
> +++ b/drivers/clk/mediatek/clk-mt8365-apmixedsys.c
> @@ -39,6 +39,7 @@
>   		.pcw_reg = _pcw_reg,					\
>   		.pcw_shift = _pcw_shift,				\
>   		.pcw_chg_reg = _pcw_chg_reg,				\
> +		.pcw_chg_shift = PCW_CHG_SHIFT,				\
>   		.div_table = _div_table,				\
>   	}
>   
> diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
> index 513ab6b1b3229..139b01ab8d140 100644
> --- a/drivers/clk/mediatek/clk-pll.c
> +++ b/drivers/clk/mediatek/clk-pll.c
> @@ -23,7 +23,6 @@
>   #define CON0_BASE_EN		BIT(0)
>   #define CON0_PWR_ON		BIT(0)
>   #define CON0_ISO_EN		BIT(1)
> -#define PCW_CHG_MASK		BIT(31)
>   
>   #define AUDPLL_TUNER_EN		BIT(31)
>   
> @@ -114,7 +113,7 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll, u32 pcw,
>   			pll->data->pcw_shift);
>   	val |= pcw << pll->data->pcw_shift;
>   	writel(val, pll->pcw_addr);
> -	chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
> +	chg = readl(pll->pcw_chg_addr) | BIT(pll->data->pcw_chg_shift);
>   	writel(chg, pll->pcw_chg_addr);
>   	if (pll->tuner_addr)
>   		writel(val + 1, pll->tuner_addr);
> diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
> index f17278ff15d78..84bd8df13e2e5 100644
> --- a/drivers/clk/mediatek/clk-pll.h
> +++ b/drivers/clk/mediatek/clk-pll.h
> @@ -22,6 +22,7 @@ struct mtk_pll_div_table {
>   #define HAVE_RST_BAR	BIT(0)
>   #define PLL_AO		BIT(1)
>   #define POSTDIV_MASK	GENMASK(2, 0)
> +#define PCW_CHG_SHIFT	31
>   
>   struct mtk_pll_data {
>   	int id;
> @@ -48,6 +49,7 @@ struct mtk_pll_data {
>   	const char *parent_name;
>   	u32 en_reg;
>   	u8 pll_en_bit; /* Assume 0, indicates BIT(0) by default */
> +	u8 pcw_chg_shift;

Ok this is better - please call this "pcw_chg_bit" (same for the definition).

Also, since it is impossible for PCW_CHG to be 0, please add a sanity check at
the beginning of function mtk_clk_register_pll_ops(), like so:

if (!data->pcw_chg_bit) {
	pr_warn("Invalid PCW_CHG bit for pll %s", data->name);
	return ERR_PTR(-EINVAL);
}

...like that, we're fully covered for eventual mistakes during porting (etc).

Cheers,
Angelo


From sashal at kernel.org  Mon Dec 11 05:57:51 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:57:51 -0500
Subject: [PATCH AUTOSEL 5.15 17/19] drm/exynos: fix a potential error pointer dereference
In-Reply-To: <20231211135908.385694-1-sashal@kernel.org>
References: <20231211135908.385694-1-sashal@kernel.org>
Message-ID: <20231211135908.385694-17-sashal@kernel.org>

From: Xiang Yang <xiangyang3 at huawei.com>

[ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]

Smatch reports the warning below:
drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
error: 'crtc' dereferencing possible ERR_PTR()

The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
which can not be used directly. Fix this by checking the return value
before using it.

Signed-off-by: Xiang Yang <xiangyang3 at huawei.com>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 7655142a4651c..42b6b001405a5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1861,6 +1861,8 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
 		return ret;
 
 	crtc = exynos_drm_crtc_get_by_type(drm_dev, EXYNOS_DISPLAY_TYPE_HDMI);
+	if (IS_ERR(crtc))
+		return PTR_ERR(crtc);
 	crtc->pipe_clk = &hdata->phy_clk;
 
 	ret = hdmi_create_connector(encoder);
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 05:57:52 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 08:57:52 -0500
Subject: [PATCH AUTOSEL 5.15 18/19] drm/exynos: fix a wrong error checking
In-Reply-To: <20231211135908.385694-1-sashal@kernel.org>
References: <20231211135908.385694-1-sashal@kernel.org>
Message-ID: <20231211135908.385694-18-sashal@kernel.org>

From: Inki Dae <inki.dae at samsung.com>

[ Upstream commit 8d1b7809684c688005706125b804e1f9792d2b1b ]

Fix a wrong error checking in exynos_drm_dma.c module.

In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
and iommu_get_domain_for_dev() functions are expected to return NULL as
an error.

However, the error checking is performed using the statement
if(IS_ERR(mapping)), which doesn't provide a suitable error value.
So check if 'mapping' is NULL, and if it is, return -ENODEV.

This issue[1] was reported by Dan.

Changelog v1:
- fix build warning.

[1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf at moroto.mountain/

Reported-by : Dan Carpenter <dan.carpenter at linaro.org>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c b/drivers/gpu/drm/exynos/exynos_drm_dma.c
index bf33c3084cb41..6b4d6da3b1f4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
@@ -108,18 +108,16 @@ int exynos_drm_register_dma(struct drm_device *drm, struct device *dev,
 		return 0;
 
 	if (!priv->mapping) {
-		void *mapping;
+		void *mapping = NULL;
 
 		if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))
 			mapping = arm_iommu_create_mapping(&platform_bus_type,
 				EXYNOS_DEV_ADDR_START, EXYNOS_DEV_ADDR_SIZE);
 		else if (IS_ENABLED(CONFIG_IOMMU_DMA))
 			mapping = iommu_get_domain_for_dev(priv->dma_dev);
-		else
-			mapping = ERR_PTR(-ENODEV);
 
-		if (IS_ERR(mapping))
-			return PTR_ERR(mapping);
+		if (!mapping)
+			return -ENODEV;
 		priv->mapping = mapping;
 	}
 
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 06:00:39 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 09:00:39 -0500
Subject: [PATCH AUTOSEL 5.10 15/16] drm/exynos: fix a potential error pointer dereference
In-Reply-To: <20231211140116.391986-1-sashal@kernel.org>
References: <20231211140116.391986-1-sashal@kernel.org>
Message-ID: <20231211140116.391986-15-sashal@kernel.org>

From: Xiang Yang <xiangyang3 at huawei.com>

[ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]

Smatch reports the warning below:
drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
error: 'crtc' dereferencing possible ERR_PTR()

The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
which can not be used directly. Fix this by checking the return value
before using it.

Signed-off-by: Xiang Yang <xiangyang3 at huawei.com>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index dc01c188c0e09..981bffacda243 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1849,6 +1849,8 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
 		return ret;
 
 	crtc = exynos_drm_crtc_get_by_type(drm_dev, EXYNOS_DISPLAY_TYPE_HDMI);
+	if (IS_ERR(crtc))
+		return PTR_ERR(crtc);
 	crtc->pipe_clk = &hdata->phy_clk;
 
 	ret = hdmi_create_connector(encoder);
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 06:00:40 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 09:00:40 -0500
Subject: [PATCH AUTOSEL 5.10 16/16] drm/exynos: fix a wrong error checking
In-Reply-To: <20231211140116.391986-1-sashal@kernel.org>
References: <20231211140116.391986-1-sashal@kernel.org>
Message-ID: <20231211140116.391986-16-sashal@kernel.org>

From: Inki Dae <inki.dae at samsung.com>

[ Upstream commit 8d1b7809684c688005706125b804e1f9792d2b1b ]

Fix a wrong error checking in exynos_drm_dma.c module.

In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
and iommu_get_domain_for_dev() functions are expected to return NULL as
an error.

However, the error checking is performed using the statement
if(IS_ERR(mapping)), which doesn't provide a suitable error value.
So check if 'mapping' is NULL, and if it is, return -ENODEV.

This issue[1] was reported by Dan.

Changelog v1:
- fix build warning.

[1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf at moroto.mountain/

Reported-by : Dan Carpenter <dan.carpenter at linaro.org>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c b/drivers/gpu/drm/exynos/exynos_drm_dma.c
index bf33c3084cb41..6b4d6da3b1f4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
@@ -108,18 +108,16 @@ int exynos_drm_register_dma(struct drm_device *drm, struct device *dev,
 		return 0;
 
 	if (!priv->mapping) {
-		void *mapping;
+		void *mapping = NULL;
 
 		if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))
 			mapping = arm_iommu_create_mapping(&platform_bus_type,
 				EXYNOS_DEV_ADDR_START, EXYNOS_DEV_ADDR_SIZE);
 		else if (IS_ENABLED(CONFIG_IOMMU_DMA))
 			mapping = iommu_get_domain_for_dev(priv->dma_dev);
-		else
-			mapping = ERR_PTR(-ENODEV);
 
-		if (IS_ERR(mapping))
-			return PTR_ERR(mapping);
+		if (!mapping)
+			return -ENODEV;
 		priv->mapping = mapping;
 	}
 
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 06:02:05 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 09:02:05 -0500
Subject: [PATCH AUTOSEL 5.4 12/12] drm/exynos: fix a wrong error checking
In-Reply-To: <20231211140219.392379-1-sashal@kernel.org>
References: <20231211140219.392379-1-sashal@kernel.org>
Message-ID: <20231211140219.392379-12-sashal@kernel.org>

From: Inki Dae <inki.dae at samsung.com>

[ Upstream commit 8d1b7809684c688005706125b804e1f9792d2b1b ]

Fix a wrong error checking in exynos_drm_dma.c module.

In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
and iommu_get_domain_for_dev() functions are expected to return NULL as
an error.

However, the error checking is performed using the statement
if(IS_ERR(mapping)), which doesn't provide a suitable error value.
So check if 'mapping' is NULL, and if it is, return -ENODEV.

This issue[1] was reported by Dan.

Changelog v1:
- fix build warning.

[1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf at moroto.mountain/

Reported-by : Dan Carpenter <dan.carpenter at linaro.org>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c b/drivers/gpu/drm/exynos/exynos_drm_dma.c
index a3c9d8b9e1a18..e07d31b9a921a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
@@ -133,18 +133,16 @@ int exynos_drm_register_dma(struct drm_device *drm, struct device *dev,
 		return 0;
 
 	if (!priv->mapping) {
-		void *mapping;
+		void *mapping = NULL;
 
 		if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))
 			mapping = arm_iommu_create_mapping(&platform_bus_type,
 				EXYNOS_DEV_ADDR_START, EXYNOS_DEV_ADDR_SIZE);
 		else if (IS_ENABLED(CONFIG_IOMMU_DMA))
 			mapping = iommu_get_domain_for_dev(priv->dma_dev);
-		else
-			mapping = ERR_PTR(-ENODEV);
 
-		if (IS_ERR(mapping))
-			return PTR_ERR(mapping);
+		if (!mapping)
+			return -ENODEV;
 		priv->mapping = mapping;
 	}
 
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 06:02:04 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 09:02:04 -0500
Subject: [PATCH AUTOSEL 5.4 11/12] drm/exynos: fix a potential error pointer dereference
In-Reply-To: <20231211140219.392379-1-sashal@kernel.org>
References: <20231211140219.392379-1-sashal@kernel.org>
Message-ID: <20231211140219.392379-11-sashal@kernel.org>

From: Xiang Yang <xiangyang3 at huawei.com>

[ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]

Smatch reports the warning below:
drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
error: 'crtc' dereferencing possible ERR_PTR()

The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
which can not be used directly. Fix this by checking the return value
before using it.

Signed-off-by: Xiang Yang <xiangyang3 at huawei.com>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 0073a2b3b80a2..93b2af4936d0e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1850,6 +1850,8 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
 		return ret;
 
 	crtc = exynos_drm_crtc_get_by_type(drm_dev, EXYNOS_DISPLAY_TYPE_HDMI);
+	if (IS_ERR(crtc))
+		return PTR_ERR(crtc);
 	crtc->pipe_clk = &hdata->phy_clk;
 
 	ret = hdmi_create_connector(encoder);
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 06:02:50 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 09:02:50 -0500
Subject: [PATCH AUTOSEL 4.19 7/7] drm/exynos: fix a potential error pointer dereference
In-Reply-To: <20231211140254.392656-1-sashal@kernel.org>
References: <20231211140254.392656-1-sashal@kernel.org>
Message-ID: <20231211140254.392656-7-sashal@kernel.org>

From: Xiang Yang <xiangyang3 at huawei.com>

[ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]

Smatch reports the warning below:
drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
error: 'crtc' dereferencing possible ERR_PTR()

The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
which can not be used directly. Fix this by checking the return value
before using it.

Signed-off-by: Xiang Yang <xiangyang3 at huawei.com>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2092a650df7d5..551a97e45d973 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1840,6 +1840,8 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
 		return ret;
 
 	crtc = exynos_drm_crtc_get_by_type(drm_dev, EXYNOS_DISPLAY_TYPE_HDMI);
+	if (IS_ERR(crtc))
+		return PTR_ERR(crtc);
 	crtc->pipe_clk = &hdata->phy_clk;
 
 	ret = hdmi_create_connector(encoder);
-- 
2.42.0



From sashal at kernel.org  Mon Dec 11 06:03:10 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 11 Dec 2023 09:03:10 -0500
Subject: [PATCH AUTOSEL 4.14 5/5] drm/exynos: fix a potential error pointer dereference
In-Reply-To: <20231211140311.392827-1-sashal@kernel.org>
References: <20231211140311.392827-1-sashal@kernel.org>
Message-ID: <20231211140311.392827-5-sashal@kernel.org>

From: Xiang Yang <xiangyang3 at huawei.com>

[ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]

Smatch reports the warning below:
drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
error: 'crtc' dereferencing possible ERR_PTR()

The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
which can not be used directly. Fix this by checking the return value
before using it.

Signed-off-by: Xiang Yang <xiangyang3 at huawei.com>
Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 0109ff40b1db2..3d79a7af8c862 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1722,6 +1722,8 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
 		return ret;
 
 	crtc = exynos_drm_crtc_get_by_type(drm_dev, EXYNOS_DISPLAY_TYPE_HDMI);
+	if (IS_ERR(crtc))
+		return PTR_ERR(crtc);
 	crtc->pipe_clk = &hdata->phy_clk;
 
 	ret = hdmi_create_connector(encoder);
-- 
2.42.0



From andrew at lunn.ch  Mon Dec 11 06:09:09 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 11 Dec 2023 15:09:09 +0100
Subject: [RFC PATCH net-next v3 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <20231211120623.03b1ced4@device.home>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
 <20231201163704.1306431-2-maxime.chevallier@bootlin.com>
 <20231209170241.GA5817@kernel.org>
 <20231211120623.03b1ced4@device.home>
Message-ID: <67557c83-4318-4557-ac96-858053b5f89b@lunn.ch>

> > > @@ -10832,6 +10833,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
> > >  #ifdef CONFIG_NET_SCHED
> > >  	hash_init(dev->qdisc_hash);
> > >  #endif
> > > +	phy_link_topo_init(&dev->link_topo);
> > > +  
> > 
> > I don't think this can work unless PHYLIB is compiled as a built-in.
> 
> Inded, I need to better clarify and document the dependency with
> PHYLIB.

It is getting harder and harder to make the phylib core a module :-(

How much work does phy_link_topo_init() do? Could it be an inline
function? Are there other dependencies?

Also look at ethtool_phy_ops and e.g. how plca_get_cfg_prepare_data()
uses it.

	Andrew


From ardb at kernel.org  Mon Dec 11 06:10:00 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Mon, 11 Dec 2023 15:10:00 +0100
Subject: [PATCH v6 04/41] arm64: mm: Move PCI I/O emulation region above
 the vmemmap region
In-Reply-To: <ZXcVWFMr6eUWtEec@FVFF77S0Q05N.cambridge.arm.com>
References: <20231129111555.3594833-43-ardb@google.com> <20231129111555.3594833-47-ardb@google.com>
 <ZXcVWFMr6eUWtEec@FVFF77S0Q05N.cambridge.arm.com>
Message-ID: <CAMj1kXE0oVrEvPgLKfXW73fcES92SVxevj=pdiKaG1t6fE0pRA@mail.gmail.com>

On Mon, 11 Dec 2023 at 14:57, Mark Rutland <mark.rutland at arm.com> wrote:
>
> Hi Ard,
>
> On Wed, Nov 29, 2023 at 12:16:00PM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb at kernel.org>
> >
> > Move the PCI I/O region above the vmemmap region in the kernel's VA
> > space. This will permit us to reclaim the lower part of the vmemmap
> > region for vmalloc/vmap allocations when running a 52-bit VA capable
> > build on a 48-bit VA capable system.
> >
> > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > ---
> >  arch/arm64/include/asm/memory.h | 4 ++--
> >  arch/arm64/mm/ptdump.c          | 4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index b8d726f951ae..99caeff78e1a 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -49,8 +49,8 @@
> >  #define MODULES_VSIZE                (SZ_2G)
> >  #define VMEMMAP_START                (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
> >  #define VMEMMAP_END          (VMEMMAP_START + VMEMMAP_SIZE)
> > -#define PCI_IO_END           (VMEMMAP_START - SZ_8M)
> > -#define PCI_IO_START         (PCI_IO_END - PCI_IO_SIZE)
> > +#define PCI_IO_START         (VMEMMAP_END + SZ_8M)
> > +#define PCI_IO_END           (PCI_IO_START + PCI_IO_SIZE)
> >  #define FIXADDR_TOP          (VMEMMAP_START - SZ_32M)
>
> This looks simple, but it does have a subtle dependency on VMEMMAP_SIZE being
> sufficiently smaller than the negative offset we choose for VMEMMAP_START, and
> it took mw a while to convince myself that we always ensure that today. I could
> well imagine that we try to reduce that in future (given for most
> configurations we're reserving around double the space we actually need), and
> it would be nice if we could avoid that going wrong.
>

Yes, we are relying on the fact that the upper region is not covered
by struct pages, so there is guaranteed to be an unused region at the
very top.

One of the constants in the equation that describes the size of this
unused region is the size of a struct page, and so I agree this needs
a couple of static asserts to ensure we don't get inadvertent
overlaps.


> We need to make sure that PCI_IO_START and PCI_IO_END fall between VMEMMAP_END
> and the last page of the VA space (due to ERR_PTR). Could we add some comment
> and/or assertions to that effect?
>
> Mark.
>
> >
> >  #if VA_BITS > 48
> > diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> > index e305b6593c4e..d1df56d44f8a 100644
> > --- a/arch/arm64/mm/ptdump.c
> > +++ b/arch/arm64/mm/ptdump.c
> > @@ -47,10 +47,10 @@ static struct addr_marker address_markers[] = {
> >       { VMALLOC_END,                  "vmalloc() end" },
> >       { FIXADDR_TOT_START,            "Fixmap start" },
> >       { FIXADDR_TOP,                  "Fixmap end" },
> > -     { PCI_IO_START,                 "PCI I/O start" },
> > -     { PCI_IO_END,                   "PCI I/O end" },
> >       { VMEMMAP_START,                "vmemmap start" },
> >       { VMEMMAP_START + VMEMMAP_SIZE, "vmemmap end" },
> > +     { PCI_IO_START,                 "PCI I/O start" },
> > +     { PCI_IO_END,                   "PCI I/O end" },
> >       { -1,                           NULL },
> >  };
> >
> > --
> > 2.43.0.rc1.413.gea7ed67945-goog
> >


From joro at 8bytes.org  Mon Dec 11 06:14:07 2023
From: joro at 8bytes.org (Joerg Roedel)
Date: Mon, 11 Dec 2023 15:14:07 +0100
Subject: [PATCH 0/7] Convert SMMU to domain_alloc_paging()
In-Reply-To: <20231130004905.GA1395649@nvidia.com>
References: <0-v1-cf5846854f51+6db3f-smmu_newapi_jgg@nvidia.com>
 <20231130004905.GA1395649@nvidia.com>
Message-ID: <ZXcZL19OLbctV_W-@8bytes.org>

On Wed, Nov 29, 2023 at 08:49:05PM -0400, Jason Gunthorpe wrote:
> This is still pending, it doesn't need rebasing on v6.7
> 
> The DART patches were merges so all the dependencies are in v6.7 now.

This is mostly ARM-SMMU, so I leave it to Will and Robin to
decide/pick-up.

Regards,

	Joerg


From mark.rutland at arm.com  Mon Dec 11 06:15:33 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 11 Dec 2023 14:15:33 +0000
Subject: [PATCH v6 06/41] arm64: ptdump: Allow all region boundaries to
 be defined at boot time
In-Reply-To: <20231129111555.3594833-49-ardb@google.com>
References: <20231129111555.3594833-43-ardb@google.com>
 <20231129111555.3594833-49-ardb@google.com>
Message-ID: <ZXcZhfx6lLhNuMrL@FVFF77S0Q05N.cambridge.arm.com>

On Wed, Nov 29, 2023 at 12:16:02PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> 
> Rework the way the address_markers array is populated so that we can
> tolerate values that are not compile time constants generally, rather
> than keeping track manually of the array indexes in question, and poking
> new values into them manually. This will be needed for VMALLOC_END,
> which will cease to be a compile time constant after a subsequent patch.
> 
> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> ---
>  arch/arm64/mm/ptdump.c | 54 ++++++++------------
>  1 file changed, 22 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index 3958b008f908..bfc307890344 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -26,34 +26,6 @@
>  #include <asm/ptdump.h>
>  
>  
> -enum address_markers_idx {
> -	PAGE_OFFSET_NR = 0,
> -	PAGE_END_NR,
> -#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
> -	KASAN_START_NR,
> -#endif
> -};
> -
> -static struct addr_marker address_markers[] = {
> -	{ PAGE_OFFSET,			"Linear Mapping start" },
> -	{ 0 /* PAGE_END */,		"Linear Mapping end" },
> -#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
> -	{ 0 /* KASAN_SHADOW_START */,	"Kasan shadow start" },
> -	{ KASAN_SHADOW_END,		"Kasan shadow end" },
> -#endif
> -	{ MODULES_VADDR,		"Modules start" },
> -	{ MODULES_END,			"Modules end" },
> -	{ VMALLOC_START,		"vmalloc() area" },
> -	{ VMALLOC_END,			"vmalloc() end" },
> -	{ VMEMMAP_START,		"vmemmap start" },
> -	{ VMEMMAP_START + VMEMMAP_SIZE,	"vmemmap end" },
> -	{ PCI_IO_START,			"PCI I/O start" },
> -	{ PCI_IO_END,			"PCI I/O end" },
> -	{ FIXADDR_TOT_START,		"Fixmap start" },
> -	{ FIXADDR_TOP,			"Fixmap end" },
> -	{ -1,				NULL },
> -};
> -
>  #define pt_dump_seq_printf(m, fmt, args...)	\
>  ({						\
>  	if (m)					\
> @@ -339,9 +311,8 @@ static void __init ptdump_initialize(void)
>  				pg_level[i].mask |= pg_level[i].bits[j].mask;
>  }
>  
> -static struct ptdump_info kernel_ptdump_info = {
> +static struct ptdump_info kernel_ptdump_info __ro_after_init = {
>  	.mm		= &init_mm,
> -	.markers	= address_markers,
>  	.base_addr	= PAGE_OFFSET,
>  };
>  
> @@ -375,10 +346,29 @@ void ptdump_check_wx(void)
>  
>  static int __init ptdump_init(void)
>  {
> -	address_markers[PAGE_END_NR].start_address = PAGE_END;
> +	struct addr_marker m[] = {
> +		{ PAGE_OFFSET,			"Linear Mapping start" },
> +		{ PAGE_END,			"Linear Mapping end" },
>  #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
> -	address_markers[KASAN_START_NR].start_address = KASAN_SHADOW_START;
> +		{ KASAN_SHADOW_START,		"Kasan shadow start" },
> +		{ KASAN_SHADOW_END,		"Kasan shadow end" },
>  #endif
> +		{ MODULES_VADDR,		"Modules start" },
> +		{ MODULES_END,			"Modules end" },
> +		{ VMALLOC_START,		"vmalloc() area" },
> +		{ VMALLOC_END,			"vmalloc() end" },
> +		{ VMEMMAP_START,		"vmemmap start" },
> +		{ VMEMMAP_START + VMEMMAP_SIZE,	"vmemmap end" },
> +		{ PCI_IO_START,			"PCI I/O start" },
> +		{ PCI_IO_END,			"PCI I/O end" },
> +		{ FIXADDR_TOT_START,		"Fixmap start" },
> +		{ FIXADDR_TOP,			"Fixmap end" },
> +		{ -1,				NULL },
> +	};
> +	static struct addr_marker address_markers[ARRAY_SIZE(m)] __ro_after_init;
> +
> +	kernel_ptdump_info.markers = memcpy(address_markers, m, sizeof(m));

That is a neat trick.

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> +
>  	ptdump_initialize();
>  	ptdump_debugfs_register(&kernel_ptdump_info, "kernel_page_tables");
>  	return 0;
> -- 
> 2.43.0.rc1.413.gea7ed67945-goog
> 


From thierry.reding at gmail.com  Mon Dec 11 06:17:28 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 11 Dec 2023 15:17:28 +0100
Subject: [PATCH v6 3/4] pwm: bcm2835: allow pwm driver to be used in
 atomic context
In-Reply-To: <20231208172040.mgw7aicmwlw6yjyb@pengutronix.de>
References: <cover.1701248996.git.sean@mess.org>
 <179dc1ce85702a8b64b43c0e0df656b0c5e3ce30.1701248996.git.sean@mess.org>
 <ZXNC3JYy7CTfYsyC@orome.fritz.box>
 <ZXNL5upeUPc4gC1R@gofer.mess.org>
 <20231208172040.mgw7aicmwlw6yjyb@pengutronix.de>
Message-ID: <ZXcZ-D2Bc58ydsIn@orome.fritz.box>

On Fri, Dec 08, 2023 at 06:20:40PM +0100, Uwe Kleine-K?nig wrote:
> On Fri, Dec 08, 2023 at 05:01:26PM +0000, Sean Young wrote:
> > On Fri, Dec 08, 2023 at 05:22:52PM +0100, Thierry Reding wrote:
> > > On Wed, Nov 29, 2023 at 09:13:36AM +0000, Sean Young wrote:
> > > > clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
> > > > rate changes using clk_rate_exclusive_get().
> > > > 
> > > > Signed-off-by: Sean Young <sean at mess.org>
> > > > ---
> > > >  drivers/pwm/pwm-bcm2835.c | 31 +++++++++++++++++++++----------
> > > >  1 file changed, 21 insertions(+), 10 deletions(-)
> > > 
> > > s/pwm/PWM/ in the subject. Although, I guess you could just drop the
> > > "PWM" altogether because the subject prefix implies that this is for
> > > PWM.
> > 
> > $ git log --no-merges --oneline drivers/pwm/ | sed -r 's/^\w* ([^:]+): .*/\1/' | sort | uniq -c
> >    1197 pwm
> >       1 PWM
> >   ...
> > 
> > The vast majority of the commits use pwm: as a prefix, only one uses PWM:. 
> > In fact if you look across the tree almost everywhere lower case is used
> > for the prefix.
> 
> Thierry doesn't want you to change the subject prefix, but only the
> second "pwm" to make it read:
> 
> 	pwm: bcm2835: allow PWM driver to be used in atomic context
> 
> While I understand Thierry here, I'm fine with a lowercase pwm here,
> too. In my book a PWM in all uppercase is the type of hardware and pwm
> in all lowercase is the framework's name. If you use "PWM driver" or
> "pwm driver" then doesn't matter much.

I'm not fine with a lowercase "pwm" in what is clearly text. Text should
be grammatically correct and PWM being an abbreviation it should be all
caps. The framework name is also PWM, not pwm. We use the lowercase pwm
as prefix because it represents the directory where the subsystem lives
and we usually don't use capitalization in file and directory names.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/d11b39ed/attachment.sig>

From u.kleine-koenig at pengutronix.de  Mon Dec 11 06:19:00 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 11 Dec 2023 15:19:00 +0100
Subject: [PATCH] pwm: meson: Simplify using dev_err_probe()
In-Reply-To: <ZXbsDRslZNKCeJF9@orome.fritz.box>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
 <ZXbsDRslZNKCeJF9@orome.fritz.box>
Message-ID: <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>

Hello,

On Mon, Dec 11, 2023 at 12:01:33PM +0100, Thierry Reding wrote:
> On Fri, Dec 08, 2023 at 08:06:20PM +0100, Uwe Kleine-K?nig wrote:
> > On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> > > This is a lot of churn for very little gain.
> > 
> > We seem to have different conceptions of churn. Each hunk here is an
> > improvement for both SLOC count and usefulness of the generated error
> > message.
> > 
> > 	failed to register somename: -5
> > 
> > is worse than
> > 
> > 	error EIO: failed to register somename
> > 
> > , isn't it?
> 
> That's entirely subjective.

It's not. You and me both know that -5 is EIO. But there are quite a few
people who don't. And for other error codes I'm not that fluent. (Do you
know -2 and -19?) Also some constants are architecture specific, so e.g.
-11 is -35 on alpha.

> I think the first version is just fine. I,
> and I suspect most developers will, know what to do with either of those
> error messages.

Error messages aren't only for (kernel) developers. If you don't know
that the kernel uses negative error numbers as return codes, the
translation of -5 to EIO is even further away than opening
/usr/include/errno.h.
 
> > > None of these functions are ever going to return -EPROBE_DEFER. And
> > > yes, I know that function's doc says that it is "deemed acceptable to
> > > use" elsewhere. However, the existing error messages are just fine, no
> > > need to churn just for the sake of it.
> > 
> > We had this disagreement already before. Yes dev_err_probe() is useful
> > for three reasons and this driver only benefits from two of these.
> > That's IMHO still one reason more than needed to justify such a change.
> 
> I disagree. There are certainly cases where dev_err_probe() can be a
> significant improvement, but there are others where the improvement is
> very minor (if there's any at all) and in my opinion the churn isn't
> justified.

What is churn for you? Many changes? Big changes? For me churn is only a
big amount of changes where a considerable part cancels out if it was
squashed together. For you this concept seems to be broader.

> Otherwise we'll just forever keep rewriting the same code
> over and over again because somebody comes up with yet another variant
> of mostly the same code.

If there is an improvement in each adaption that's fine for me.
 
> > And if you think that a function should only be used if all advantages
> > are useful for the caller, let us reconsider if we really need capture
> > support in the pwm framework as only two of the 68 drivers make use of
> > it.
> 
> That's a ridiculous argument and you know it. You are comparing apples
> to oranges.

I would have been surprised if it had convinced you, but I honestly
think there is a (admittedly small) point.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/d1de5081/attachment.sig>

From alexandru.elisei at arm.com  Mon Dec 11 06:21:36 2023
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Mon, 11 Dec 2023 14:21:36 +0000
Subject: [PATCH RFC v2 15/27] arm64: mte: Check that tag storage blocks
 are in the same zone
In-Reply-To: <20231208052739.GB1359878@tiffany>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <CGME20231119165900epcas2p3efd0f3ac19b7bcf7883e8d3945e63326@epcas2p3.samsung.com>
 <20231119165721.9849-16-alexandru.elisei@arm.com>
 <20231129085744.GB2988384@tiffany>
 <ZWh5S9BoO5bG5nQM@raptor>
 <20231208052739.GB1359878@tiffany>
Message-ID: <ZXca8B6a3HPRrdNP@raptor>

Hi,

On Fri, Dec 08, 2023 at 02:27:39PM +0900, Hyesoo Yu wrote:
> Hi~
> 
> On Thu, Nov 30, 2023 at 12:00:11PM +0000, Alexandru Elisei wrote:
> > Hi,
> > 
> > On Wed, Nov 29, 2023 at 05:57:44PM +0900, Hyesoo Yu wrote:
> > > On Sun, Nov 19, 2023 at 04:57:09PM +0000, Alexandru Elisei wrote:
> > > > alloc_contig_range() requires that the requested pages are in the same
> > > > zone. Check that this is indeed the case before initializing the tag
> > > > storage blocks.
> > > > 
> > > > Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
> > > > ---
> > > >  arch/arm64/kernel/mte_tag_storage.c | 33 +++++++++++++++++++++++++++++
> > > >  1 file changed, 33 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/kernel/mte_tag_storage.c b/arch/arm64/kernel/mte_tag_storage.c
> > > > index 8b9bedf7575d..fd63430d4dc0 100644
> > > > --- a/arch/arm64/kernel/mte_tag_storage.c
> > > > +++ b/arch/arm64/kernel/mte_tag_storage.c
> > > > @@ -265,6 +265,35 @@ void __init mte_tag_storage_init(void)
> > > >  	}
> > > >  }
> > > >  
> > > > +/* alloc_contig_range() requires all pages to be in the same zone. */
> > > > +static int __init mte_tag_storage_check_zone(void)
> > > > +{
> > > > +	struct range *tag_range;
> > > > +	struct zone *zone;
> > > > +	unsigned long pfn;
> > > > +	u32 block_size;
> > > > +	int i, j;
> > > > +
> > > > +	for (i = 0; i < num_tag_regions; i++) {
> > > > +		block_size = tag_regions[i].block_size;
> > > > +		if (block_size == 1)
> > > > +			continue;
> > > > +
> > > > +		tag_range = &tag_regions[i].tag_range;
> > > > +		for (pfn = tag_range->start; pfn <= tag_range->end; pfn += block_size) {
> > > > +			zone = page_zone(pfn_to_page(pfn));
> > > 
> > > Hello.
> > > 
> > > Since the blocks within the tag_range must all be in the same zone, can we move the "page_zone"
> > > out of the loop ?
> > `
> > Hmm.. why do you say that the pages in a tag_range must be in the same
> > zone? I am not very familiar with how the memory management code puts pages
> > into zones, but I would imagine that pages in a tag range straddling the
> > 4GB limit (so, let's say, from 3GB to 5GB) will end up in both ZONE_DMA and
> > ZONE_NORMAL.
> > 
> > Thanks,
> > Alex
> > 
> 
> Oh, I see that reserve_tag_storage only calls alloc_contig_rnage in units of block_size,
> I thought it could be called for the entire range the page needed at once.
> (Maybe it could be a bit faster ? It doesn't seem like unnecessary drain and
> other operation are repeated.)

Yes, that might be useful to do. Worth keeping in mind is that:

- a number of block size pages at the start and end of the range might
  already be reserved for other tagged pages, so the actual range that is
  being reserved might end up being smaller that what we are expecting.

- the most common allocation order is smaller or equal to
  PAGE_ALLOC_COSTLY_ORDER, which is 3, which means that the most common
  case is that reserve_tag_storage reserves only one tag storage block.

I will definitely keep this optimization in mind, but I would prefer to get
the series into a more stable shape before looking at performance
optimizations.

> 
> If we use the cma code when activating the tag storage, it will be error if the
> entire area of tag region is not in the same zone, so there should be a constraint
> that it must be in the same zone when defining the tag region on device tree.

I don't think that's the best approach, because the device tree describes
the hardware, which does not change, and this is a software limitation
(i.e, CMA doesn't work if a CMA region spans different zones), which might
get fixed in a future version of Linux.

In my opinion, the simplest solution would be to check that all tag storage
regions have been activated successfully by CMA before enabling tag
storage. Another alternative would be to split the tag storage region into
several CMA regions at a zone boundary, and add it as distinct CMA regions.

Thanks,
Alex

> 
> Thanks,
> Regards.
> 
> > > 
> > > Thanks,
> > > Regards.
> > > 
> > > > +			for (j = 1; j < block_size; j++) {
> > > > +				if (page_zone(pfn_to_page(pfn + j)) != zone) {
> > > > +					pr_err("Tag storage block pages in different zones");
> > > > +					return -EINVAL;
> > > > +				}
> > > > +			}
> > > > +		}
> > > > +	}
> > > > +
> > > > +	 return 0;
> > > > +}
> > > > +
> > > >  static int __init mte_tag_storage_activate_regions(void)
> > > >  {
> > > >  	phys_addr_t dram_start, dram_end;
> > > > @@ -321,6 +350,10 @@ static int __init mte_tag_storage_activate_regions(void)
> > > >  		goto out_disabled;
> > > >  	}
> > > >  
> > > > +	ret = mte_tag_storage_check_zone();
> > > > +	if (ret)
> > > > +		goto out_disabled;
> > > > +
> > > >  	for (i = 0; i < num_tag_regions; i++) {
> > > >  		tag_range = &tag_regions[i].tag_range;
> > > >  		for (pfn = tag_range->start; pfn <= tag_range->end; pfn += pageblock_nr_pages)
> > > > -- 
> > > > 2.42.1
> > > > 
> > > > 
> > 
> > 
> > 




From mark.rutland at arm.com  Mon Dec 11 06:21:51 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 11 Dec 2023 14:21:51 +0000
Subject: [PATCH v6 04/41] arm64: mm: Move PCI I/O emulation region above
 the vmemmap region
In-Reply-To: <CAMj1kXE0oVrEvPgLKfXW73fcES92SVxevj=pdiKaG1t6fE0pRA@mail.gmail.com>
References: <20231129111555.3594833-43-ardb@google.com>
 <20231129111555.3594833-47-ardb@google.com>
 <ZXcVWFMr6eUWtEec@FVFF77S0Q05N.cambridge.arm.com>
 <CAMj1kXE0oVrEvPgLKfXW73fcES92SVxevj=pdiKaG1t6fE0pRA@mail.gmail.com>
Message-ID: <ZXca_2vf7HuDIZsK@FVFF77S0Q05N.cambridge.arm.com>

On Mon, Dec 11, 2023 at 03:10:00PM +0100, Ard Biesheuvel wrote:
> On Mon, 11 Dec 2023 at 14:57, Mark Rutland <mark.rutland at arm.com> wrote:
> >
> > Hi Ard,
> >
> > On Wed, Nov 29, 2023 at 12:16:00PM +0100, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel <ardb at kernel.org>
> > >
> > > Move the PCI I/O region above the vmemmap region in the kernel's VA
> > > space. This will permit us to reclaim the lower part of the vmemmap
> > > region for vmalloc/vmap allocations when running a 52-bit VA capable
> > > build on a 48-bit VA capable system.
> > >
> > > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > > ---
> > >  arch/arm64/include/asm/memory.h | 4 ++--
> > >  arch/arm64/mm/ptdump.c          | 4 ++--
> > >  2 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > index b8d726f951ae..99caeff78e1a 100644
> > > --- a/arch/arm64/include/asm/memory.h
> > > +++ b/arch/arm64/include/asm/memory.h
> > > @@ -49,8 +49,8 @@
> > >  #define MODULES_VSIZE                (SZ_2G)
> > >  #define VMEMMAP_START                (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
> > >  #define VMEMMAP_END          (VMEMMAP_START + VMEMMAP_SIZE)
> > > -#define PCI_IO_END           (VMEMMAP_START - SZ_8M)
> > > -#define PCI_IO_START         (PCI_IO_END - PCI_IO_SIZE)
> > > +#define PCI_IO_START         (VMEMMAP_END + SZ_8M)
> > > +#define PCI_IO_END           (PCI_IO_START + PCI_IO_SIZE)
> > >  #define FIXADDR_TOP          (VMEMMAP_START - SZ_32M)
> >
> > This looks simple, but it does have a subtle dependency on VMEMMAP_SIZE being
> > sufficiently smaller than the negative offset we choose for VMEMMAP_START, and
> > it took mw a while to convince myself that we always ensure that today. I could
> > well imagine that we try to reduce that in future (given for most
> > configurations we're reserving around double the space we actually need), and
> > it would be nice if we could avoid that going wrong.
> >
> 
> Yes, we are relying on the fact that the upper region is not covered
> by struct pages, so there is guaranteed to be an unused region at the
> very top.

Yep; exactly. My fear is that in future someone realises that:

	(-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))

... is actually reserving ~2x the space it needs for *most* configurations (since for 
most configurations we only need the VMEMMAP to account for (VA_BITS-1) bits of
linear map). If they try to shrink the VMEMMAP region in for those cases, it's
liable to overlap subsequent regions and/or to wrap those past the end of the
VA space.

> One of the constants in the equation that describes the size of this
> unused region is the size of a struct page, and so I agree this needs
> a couple of static asserts to ensure we don't get inadvertent
> overlaps.

That'd be great, thanks!

Mark.


From jgg at nvidia.com  Mon Dec 11 06:22:14 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Mon, 11 Dec 2023 10:22:14 -0400
Subject: [PATCH 0/7] Convert SMMU to domain_alloc_paging()
In-Reply-To: <ZXcZL19OLbctV_W-@8bytes.org>
References: <0-v1-cf5846854f51+6db3f-smmu_newapi_jgg@nvidia.com>
 <20231130004905.GA1395649@nvidia.com>
 <ZXcZL19OLbctV_W-@8bytes.org>
Message-ID: <20231211142214.GG2944114@nvidia.com>

On Mon, Dec 11, 2023 at 03:14:07PM +0100, Joerg Roedel wrote:
> On Wed, Nov 29, 2023 at 08:49:05PM -0400, Jason Gunthorpe wrote:
> > This is still pending, it doesn't need rebasing on v6.7
> > 
> > The DART patches were merges so all the dependencies are in v6.7 now.
> 
> This is mostly ARM-SMMU, so I leave it to Will and Robin to
> decide/pick-up.

Let's have it in this kernel please.

There was a v2 two months ago that got no further comments:

https://lore.kernel.org/all/0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg at nvidia.com/

Jason


From mark.rutland at arm.com  Mon Dec 11 06:23:05 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 11 Dec 2023 14:23:05 +0000
Subject: [PATCH v6 05/41] arm64: mm: Move fixmap region above vmemmap
 region
In-Reply-To: <20231129111555.3594833-48-ardb@google.com>
References: <20231129111555.3594833-43-ardb@google.com>
 <20231129111555.3594833-48-ardb@google.com>
Message-ID: <ZXcbSdYf9C-hBHrJ@FVFF77S0Q05N.cambridge.arm.com>

On Wed, Nov 29, 2023 at 12:16:01PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> 
> Move the fixmap region above the vmemmap region, so that the start of
> the vmemmap delineates the end of the region available for vmalloc and
> vmap allocations and the randomized placement of the kernel and modules.
> 
> In a subsequent patch, we will take advantage of this to reclaim most of
> the vmemmap area when running a 52-bit VA capable build with 52-bit
> virtual addressing disabled at runtime.
> 
> Note that the existing guard region of 256 MiB covers the fixmap and PCI
> I/O regions as well, so we can reduce it 8 MiB, which is what we use in
> other places too.
> 
> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>

As with the prior patch, this looks simple enough, but it'd be good if we could
do something to assert that we don't overlap this region with others.

Mark.

> ---
>  arch/arm64/include/asm/memory.h  | 2 +-
>  arch/arm64/include/asm/pgtable.h | 2 +-
>  arch/arm64/mm/ptdump.c           | 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 99caeff78e1a..2745bed8ae5b 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -51,7 +51,7 @@
>  #define VMEMMAP_END		(VMEMMAP_START + VMEMMAP_SIZE)
>  #define PCI_IO_START		(VMEMMAP_END + SZ_8M)
>  #define PCI_IO_END		(PCI_IO_START + PCI_IO_SIZE)
> -#define FIXADDR_TOP		(VMEMMAP_START - SZ_32M)
> +#define FIXADDR_TOP		(-UL(SZ_8M))
>  
>  #if VA_BITS > 48
>  #define VA_BITS_MIN		(48)
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index b19a8aee684c..8d30e2787b1f 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -22,7 +22,7 @@
>   *	and fixed mappings
>   */
>  #define VMALLOC_START		(MODULES_END)
> -#define VMALLOC_END		(VMEMMAP_START - SZ_256M)
> +#define VMALLOC_END		(VMEMMAP_START - SZ_8M)
>  
>  #define vmemmap			((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
>  
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index d1df56d44f8a..3958b008f908 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -45,12 +45,12 @@ static struct addr_marker address_markers[] = {
>  	{ MODULES_END,			"Modules end" },
>  	{ VMALLOC_START,		"vmalloc() area" },
>  	{ VMALLOC_END,			"vmalloc() end" },
> -	{ FIXADDR_TOT_START,		"Fixmap start" },
> -	{ FIXADDR_TOP,			"Fixmap end" },
>  	{ VMEMMAP_START,		"vmemmap start" },
>  	{ VMEMMAP_START + VMEMMAP_SIZE,	"vmemmap end" },
>  	{ PCI_IO_START,			"PCI I/O start" },
>  	{ PCI_IO_END,			"PCI I/O end" },
> +	{ FIXADDR_TOT_START,		"Fixmap start" },
> +	{ FIXADDR_TOP,			"Fixmap end" },
>  	{ -1,				NULL },
>  };
>  
> -- 
> 2.43.0.rc1.413.gea7ed67945-goog
> 


From u.kleine-koenig at pengutronix.de  Mon Dec 11 06:30:59 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 11 Dec 2023 15:30:59 +0100
Subject: [PATCH v7 1/4] pwm: Rename pwm_apply_state() to
 pwm_apply_might_sleep()
In-Reply-To: <f2762a5abc13be9ec05a45927bbd84e9da5bb41c.1702282807.git.sean@mess.org>
References: <cover.1702282806.git.sean@mess.org>
 <f2762a5abc13be9ec05a45927bbd84e9da5bb41c.1702282807.git.sean@mess.org>
Message-ID: <20231211143059.dggelgdwjnntx7kf@pengutronix.de>

On Mon, Dec 11, 2023 at 08:24:52AM +0000, Sean Young wrote:
> In order to introduce a pwm api which can be used from atomic context,
> we will need two functions for applying pwm changes:
> 
> 	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
> 	int pwm_apply_atomic(struct pwm *, struct pwm_state *);
> 
> This commit just deals with renaming pwm_apply_state(), a following
> commit will introduce the pwm_apply_atomic() function.
> 
> Acked-by: Dmitry Torokhov <dmitry.torokhov at gmail.com> # for input
> Acked-by: Hans de Goede <hdegoede at redhat.com>
> Acked-by: Jani Nikula <jani.nikula at intel.com>
> Acked-by: Lee Jones <lee at kernel.org>
> Signed-off-by: Sean Young <sean at mess.org>

Acked-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/2d73a38f/attachment.sig>

From mark.rutland at arm.com  Mon Dec 11 06:35:11 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 11 Dec 2023 14:35:11 +0000
Subject: [PATCH v6 08/41] arm64: vmemmap: Avoid base2 order of struct
 page size to dimension region
In-Reply-To: <20231129111555.3594833-51-ardb@google.com>
References: <20231129111555.3594833-43-ardb@google.com>
 <20231129111555.3594833-51-ardb@google.com>
Message-ID: <ZXceH7WLEy2w_t2K@FVFF77S0Q05N.cambridge.arm.com>

On Wed, Nov 29, 2023 at 12:16:04PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> 
> The placement and size of the vmemmap region in the kernel virtual
> address space is currently derived from the base2 order of the size of a
> struct page. This makes for nicely aligned constants with lots of
> leading 0xf and trailing 0x0 digits, but given that the actual struct
> pages are indexed as an ordinary array, this resulting region is
> severely overdimensioned when the size of a struct page is just over a
> power of 2.
> 
> This doesn't matter today, but once we enable 52-bit virtual addressing
> for 4k pages configurations, the vmemmap region may take up almost half
> of the upper VA region with the current struct page upper bound at 64
> bytes. And once we enable KMSAN or other features that push the size of
> a struct page over 64 bytes, we will run out of VMALLOC space entirely.
> 
> So instead, let's derive the region size from the actual size of a
> struct page, and place the entire region 1 GB from the top of the VA
> space, where it still doesn't share any lower level translation table
> entries with the fixmap.
> 
> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>

This is nice, and largely addresses the fear I mentioned on the earlier patches
move the PCI_IO_* and FIXMAP_* regions. I'd still like to ensure that we have
assertions that those don't overlap with the VMEMMAP region, but assuming those
get added to the earlier patches, this looks good as-is:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> ---
>  arch/arm64/include/asm/memory.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 2745bed8ae5b..b49575a92afc 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -30,8 +30,8 @@
>   * keep a constant PAGE_OFFSET and "fallback" to using the higher end
>   * of the VMEMMAP where 52-bit support is not available in hardware.
>   */
> -#define VMEMMAP_SHIFT	(PAGE_SHIFT - STRUCT_PAGE_MAX_SHIFT)
> -#define VMEMMAP_SIZE	((_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) >> VMEMMAP_SHIFT)
> +#define VMEMMAP_RANGE	(_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET)
> +#define VMEMMAP_SIZE	((VMEMMAP_RANGE >> PAGE_SHIFT) * sizeof(struct page))
>  
>  /*
>   * PAGE_OFFSET - the virtual address of the start of the linear map, at the
> @@ -47,8 +47,8 @@
>  #define MODULES_END		(MODULES_VADDR + MODULES_VSIZE)
>  #define MODULES_VADDR		(_PAGE_END(VA_BITS_MIN))
>  #define MODULES_VSIZE		(SZ_2G)
> -#define VMEMMAP_START		(-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
> -#define VMEMMAP_END		(VMEMMAP_START + VMEMMAP_SIZE)
> +#define VMEMMAP_START		(VMEMMAP_END - VMEMMAP_SIZE)
> +#define VMEMMAP_END		(-UL(SZ_1G))
>  #define PCI_IO_START		(VMEMMAP_END + SZ_8M)
>  #define PCI_IO_END		(PCI_IO_START + PCI_IO_SIZE)
>  #define FIXADDR_TOP		(-UL(SZ_8M))
> -- 
> 2.43.0.rc1.413.gea7ed67945-goog
> 


From joro at 8bytes.org  Mon Dec 11 06:42:34 2023
From: joro at 8bytes.org (Joerg Roedel)
Date: Mon, 11 Dec 2023 15:42:34 +0100
Subject: [PATCH][next] iommu/apple-dart: Fix spelling mistake "grups" ->
 "groups"
In-Reply-To: <20231209231240.4056082-1-colin.i.king@gmail.com>
References: <20231209231240.4056082-1-colin.i.king@gmail.com>
Message-ID: <ZXcf2nB9enlctvTF@8bytes.org>

On Sat, Dec 09, 2023 at 11:12:40PM +0000, Colin Ian King wrote:
> There is a spelling mistake in a dev_err message. Fix it.
> 
> Signed-off-by: Colin Ian King <colin.i.king at gmail.com>
> ---
>  drivers/iommu/apple-dart.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.



From chunkuang.hu at kernel.org  Mon Dec 11 06:44:05 2023
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Mon, 11 Dec 2023 22:44:05 +0800
Subject: [PATCH 1/1] drm/mediatek: Fix access violation in mtk_drm_crtc_dma_dev_get
In-Reply-To: <20231110012914.14884-2-stuart.lee@mediatek.com>
References: <20231110012914.14884-1-stuart.lee@mediatek.com> <20231110012914.14884-2-stuart.lee@mediatek.com>
Message-ID: <CAAOTY__NgTPDedbuRQLZSS-0AC2rTW7Jfbm-e42sTU+-czzvew@mail.gmail.com>

Hi, Stuart:

Stuart Lee <stuart.lee at mediatek.com> ? 2023?11?10? ?? ??9:29???
>
> Add error handling to check NULL input in
> mtk_drm_crtc_dma_dev_get function.
>
> While display path is not configured correctly, none of crtc is
> established. So the caller of mtk_drm_crtc_dma_dev_get may pass
> input parameter *crtc as NULL, Which may cause coredump when
> we try to get the container of NULL pointer.

Applied to mediatek-drm-fixes [1], thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes

Regards,
Chun-Kuang.

>
> Fixes: cb1d6bcca542 ("drm/mediatek: Add dma dev get function")
> Signed-off-by: Stuart Lee <stuart.lee at mediatek.com>
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index c277b9fae950..047c9a31d306 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -921,7 +921,14 @@ static int mtk_drm_crtc_init_comp_planes(struct drm_device *drm_dev,
>
>  struct device *mtk_drm_crtc_dma_dev_get(struct drm_crtc *crtc)
>  {
> -       struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> +       struct mtk_drm_crtc *mtk_crtc = NULL;
> +
> +       if (!crtc)
> +               return NULL;
> +
> +       mtk_crtc = to_mtk_crtc(crtc);
> +       if (!mtk_crtc)
> +               return NULL;
>
>         return mtk_crtc->dma_dev;
>  }
> --
> 2.18.0
>


From alexandru.elisei at arm.com  Mon Dec 11 06:45:00 2023
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Mon, 11 Dec 2023 14:45:00 +0000
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <20231208050340.GA1359878@tiffany>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <CGME20231119165840epcas2p2c99f1dd358f716c103c16f47cc23bf2a@epcas2p2.samsung.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com>
 <20231129084424.GA2988384@tiffany>
 <ZWxxJipc2STxHHKn@raptor>
 <20231208050340.GA1359878@tiffany>
Message-ID: <ZXcgbJsFRotjOgUw@raptor>

Hi,

On Fri, Dec 08, 2023 at 02:03:44PM +0900, Hyesoo Yu wrote:
> Hi, 
> 
> I'm sorry for the late response, I was on vacation.
> 
> On Sun, Dec 03, 2023 at 12:14:30PM +0000, Alexandru Elisei wrote:
> > Hi,
> > 
> > On Wed, Nov 29, 2023 at 05:44:24PM +0900, Hyesoo Yu wrote:
> > > Hello.
> > > 
> > > On Sun, Nov 19, 2023 at 04:57:05PM +0000, Alexandru Elisei wrote:
> > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > regions from the DTB. This memory is marked as reserved for now.
> > > > 
> > > > The DTB node for the tag storage region is defined as:
> > > > 
> > > >         tags0: tag-storage at 8f8000000 {
> > > >                 compatible = "arm,mte-tag-storage";
> > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > >                 block-size = <0x1000>;
> > > >                 memory = <&memory0>;	// Associated tagged memory node
> > > >         };
> > > >
> > > 
> > > How about using compatible = "shared-dma-pool" like below ?
> > > 
> > > &reserved_memory {
> > > 	tags0: tag0 at 8f8000000 {
> > > 		compatible = "arm,mte-tag-storage";
> > >         	reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > 	};
> > > }
> > > 
> > > tag-storage {
> > >         compatible = "arm,mte-tag-storage";
> > > 	memory-region = <&tag>;
> > >         memory = <&memory0>;
> > > 	block-size = <0x1000>;
> > > }
> > > 
> > > And then, the activation of CMA would be performed in the CMA code.
> > > We just can get the region information from memory-region and allocate it directly
> > > like alloc_contig_range, take_page_off_buddy. It seems like we can remove a lots of code.
> >
> 
> Sorry, that example was my mistake. Actually I wanted to write like this. 
> 
> &reserved_memory {
> 	tags0: tag0 at 8f8000000 {
> 		compatible = "shared-dma-pool";
>         	reg = <0x08 0xf8000000 0x00 0x4000000>;
> 		reusable;
> 	};
> }
> 
> tag-storage {
>         compatible = "arm,mte-tag-storage";
>  	memory-region = <&tag>;
>         memory = <&memory0>;
> 	block-size = <0x1000>;
> }

I prototyped your suggestion with this change to the device tree:

            reserved-memory {
                    #address-cells = <0x02>;
                    #size-cells = <0x02>;
                    ranges;

                    tags0: tag-storage at 8f8000000 {
                            compatible = "arm,mte-tag-storage";
                            reg = <0x08 0xf8000000 0x00 0x4000000>;
                            block-size = <0x1000>;
                            memory = <&memory0>;
                            reusable;
                    };
            };

Would you mind explaining what we are gaining by using reserved mem?

Struct reserved_mem only has the base and size of the tag storage region,
and initialization for reserved mem happens before the DTB is unflattened.
When I prototyped using reserved mem, I still had to write the code to
parse the memory node address and size. This code was the same as the code
needed to parse the tag storage region address and size, so having that
information in struct reserved_mem does not reduce the size of the code by
a meaningful amount.

> 
> 
> > Played with reserved_mem a bit. I don't think that's the correct path
> > forward.
> > 
> > The location of the tag storage is a hardware property, independent of how
> > Linux is configured.
> > 
> > early_init_fdt_scan_reserved_mem() is called from arm64_memblock_init(),
> > **after** the kernel enforces an upper address for various reasons. One of
> > the reasons can be that it's been compiled with 39 bits VA.
> > 
> 
> I'm not sure about this part. What is the upper address enforced by the kernel ?
> Where can I check the code ? Do you means that memblock_end_of_DRAM() ?  

I am referring to arch/arm64/mm/init.c:: arm64_memblock_init(). The
function initializes reserved mem (in early_init_fdt_scan_reserved_mem())
**after**removing memory from memblock that the kernel cannot address.

> 
> > After early_init_fdt_scan_reserved_mem() returns, the kernel sets the
> > maximum address, stored in the variable "high_memory".
> >
> > What can happen is that tag storage is present at an address above the
> > maximum addressable by the kernel, and the CMA code will trigger an
> > unrecovrable page fault.
> > 
> > I was able to trigger this with the dts change:
> > 
> > diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> > index 60472d65a355..201359d014e4 100644
> > --- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> > +++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> > @@ -183,6 +183,13 @@ vram: vram at 18000000 {
> >                         reg = <0x00000000 0x18000000 0 0x00800000>;
> >                         no-map;
> >                 };
> > +
> > +
> > +               linux,cma {
> > +                       compatible = "shared-dma-pool";
> > +                       reg = <0x100 0x0 0x00 0x4000000>;
> > +                       reusable;
> > +               };
> >         };
> > 
> >         gic: interrupt-controller at 2f000000 {
> > 
> > And the error I got:
> > 
> > [    0.000000] Reserved memory: created CMA memory pool at 0x0000010000000000, size 64 MiB
> > [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> > [    0.000000] OF: reserved mem: 0x0000010000000000..0x0000010003ffffff (65536 KiB) map reusable linux,cma
> > [..]
> > [    0.793193] WARNING: CPU: 0 PID: 1 at mm/cma.c:111 cma_init_reserved_areas+0xa8/0x378
> > [..]
> > [    0.806945] Unable to handle kernel paging request at virtual address 00000001fe000000
> > [    0.807277] Mem abort info:
> > [    0.807277]   ESR = 0x0000000096000005
> > [    0.807693]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [    0.808110]   SET = 0, FnV = 0
> > [    0.808443]   EA = 0, S1PTW = 0
> > [    0.808526]   FSC = 0x05: level 1 translation fault
> > [    0.808943] Data abort info:
> > [    0.808943]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
> > [    0.809360]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> > [    0.809776]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > [    0.810221] [00000001fe000000] user address but active_mm is swapper
> > [..]
> > [    0.820887] Call trace:
> > [    0.821027]  cma_init_reserved_areas+0xc4/0x378
> > [    0.821443]  do_one_initcall+0x7c/0x1c0
> > [    0.821860]  kernel_init_freeable+0x1bc/0x284
> > [    0.822277]  kernel_init+0x24/0x1dc
> > [    0.822693]  ret_from_fork+0x10/0x20
> > [    0.823554] Code: 9127a29a cb813321 d37ae421 8b030020 (f8636822)
> > [    0.823554] ---[ end trace 0000000000000000 ]---
> > [    0.824360] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> > [    0.824443] SMP: stopping secondary CPUs
> > [    0.825193] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> > 
> > Should reserved mem check if the reserved memory is actually addressable by
> > the kernel if it's not "no-map"? Should cma fail gracefully if
> > !pfn_valid(base_pfn)? Shold early_init_fdt_scan_reserved_mem() be moved
> > because arm64_bootmem_init()? I don't have the answer to any of those. And
> > I got a kernel panic because the kernel cannot address that memory (39 bits
> > VA). I don't know what would happen if the upper limit is reduced for
> > another reason.
> > 
> 
> My answer may not be accurate because I don't understand what this upper limit is.
> Is this a problem caused by the tag storage area not being included in the memory node ?

This problem is caused by the kernel cannot using virtual addresses in the
linear map (where VA == PA) to access the tag storage region.

> 
> The reason for not including it in the memory node is to enable static mte when dmte
> initilization fails, right ? I think I missed that. I thought the tag storage is included
> in the memory node and registered as cma.
> 
> > What I think should happen:
> > 
> > 1. Add the tag storage memory before any limits are enforced by
> > arm64_bootmem_init().
> >
> > 2. Call cma_declare_contiguous_nid() after arm64_bootmem_init(), because
> > the function will check the memory limit.
> > 
> > 3. Have an arch initcall that checks that the CMA regions corresponding to
> > the tag storage have been activated successfully (cma_init_reserved_areas()
> > is a core initcall). If not, then don't enable tag storage.
> > 
> > How does that sound to you?
> > 
> > Thanks,
> > Alex
> > 
> 
> I think this is a good way to utilize the cma code !

Cool, thanks!

Alex

> 
> Thanks,
> Regards.
> 
> > > > +	ret = tag_storage_of_flat_read_u32(node, "block-size", &block_size_bytes);
> > > > +	if (ret || block_size_bytes == 0) {
> > > > +		pr_err("Invalid or missing 'block-size' property");
> > > > +		return -EINVAL;
> > > > +	}
> > > > +	region->block_size = get_block_size_pages(block_size_bytes);
> > > > +	if (range_len(tag_range) % region->block_size != 0) {
> > > > +		pr_err("Tag storage region size 0x%llx is not a multiple of block size %u",
> > > > +		       PFN_PHYS(range_len(tag_range)), region->block_size);
> > > > +		return -EINVAL;
> > > > +	}
> > > > +
> > > 
> > > I was confused about the variable "block_size", The block size declared in the device tree is
> > > in bytes, but the actual block size used is in pages. I think the term "block_size" can cause
> > > confusion as it might be interpreted as bytes. If possible, I suggest changing the term "block_size"
> > > to something more readable, such as "block_nr_pages" (This is just a example!)
> > > 
> > > Thanks,
> > > Regards.
> >>
> 
> What do you think about this ?
> 
> Thanks,
> Regards.
> 
> > > > +	ret = tag_storage_of_flat_read_u32(mem_node, "numa-node-id", &nid);
> > > > +	if (ret)
> > > > +		nid = numa_node_id();
> > > > +
> > > > +	ret = memblock_add_node(PFN_PHYS(tag_range->start), PFN_PHYS(range_len(tag_range)),
> > > > +				nid, MEMBLOCK_NONE);
> > > > +	if (ret) {
> > > > +		pr_err("Error adding tag memblock (%d)", ret);
> > > > +		return ret;
> > > > +	}
> > > > +	memblock_reserve(PFN_PHYS(tag_range->start), PFN_PHYS(range_len(tag_range)));
> > > > +
> > > > +	pr_info("Found tag storage region 0x%llx-0x%llx, block size %u pages",
> > > > +		PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->end), region->block_size);
> > > > +
> > > > +	num_tag_regions++;
> > > > +
> > > > +	return 0;
> > > > +}
> > > > +
> > > > +void __init mte_tag_storage_init(void)
> > > > +{
> > > > +	struct range *tag_range;
> > > > +	int i, ret;
> > > > +
> > > > +	ret = of_scan_flat_dt(fdt_init_tag_storage, NULL);
> > > > +	if (ret) {
> > > > +		for (i = 0; i < num_tag_regions; i++) {
> > > > +			tag_range = &tag_regions[i].tag_range;
> > > > +			memblock_remove(PFN_PHYS(tag_range->start), PFN_PHYS(range_len(tag_range)));
> > > > +		}
> > > > +		num_tag_regions = 0;
> > > > +		pr_info("MTE tag storage region management disabled");
> > > > +	}
> > > > +}
> > > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > > index 417a8a86b2db..1b77138c1aa5 100644
> > > > --- a/arch/arm64/kernel/setup.c
> > > > +++ b/arch/arm64/kernel/setup.c
> > > > @@ -42,6 +42,7 @@
> > > >  #include <asm/cpufeature.h>
> > > >  #include <asm/cpu_ops.h>
> > > >  #include <asm/kasan.h>
> > > > +#include <asm/mte_tag_storage.h>
> > > >  #include <asm/numa.h>
> > > >  #include <asm/scs.h>
> > > >  #include <asm/sections.h>
> > > > @@ -342,6 +343,12 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
> > > >  			   FW_BUG "Booted with MMU enabled!");
> > > >  	}
> > > >  
> > > > +	/*
> > > > +	 * Must be called before memory limits are enforced by
> > > > +	 * arm64_memblock_init().
> > > > +	 */
> > > > +	mte_tag_storage_init();
> > > > +
> > > >  	arm64_memblock_init();
> > > >  
> > > >  	paging_init();
> > > > -- 
> > > > 2.42.1
> > > > 
> > > > 
> > 
> > 
> > 




From Ryan.Wanner at microchip.com  Mon Dec 11 06:47:44 2023
From: Ryan.Wanner at microchip.com (Ryan.Wanner at microchip.com)
Date: Mon, 11 Dec 2023 14:47:44 +0000
Subject: [PATCH v2] drivers: soc: atmel: Adjust defines to follow
 aphabetical order
In-Reply-To: <de0ddb41-8d78-45eb-bcb7-6d318bf154fd@tuxon.dev>
References: <20231208194532.579893-1-Ryan.Wanner@microchip.com>
 <de0ddb41-8d78-45eb-bcb7-6d318bf154fd@tuxon.dev>
Message-ID: <31d470f8-9f82-4c09-a6f9-dac528fda3bf@microchip.com>

On 12/9/23 05:50, claudiu beznea wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi, Ryan,
> 
> On 08.12.2023 21:45, Ryan.Wanner at microchip.com wrote:
>> From: Ryan Wanner <Ryan.Wanner at microchip.com>
>>
>> Move the defines so that they are in aphabetical order based on SOC.
> 
> s/aphabetical/alphabetical but maybe alphanumerical a better term.
> 
> Could you please explain what level of alphabetical sort you wanted to
> achieve? I see SAM9X60/SAMA7G5 b/w AT91SAM9X5_CIDR_MATCH and
> AT91SAM9M11_EXID_MATCH or, e.g., AT91SAM9G35_EXID_MATCH after
> AT91SAM9M10_EXID_MATCH.

I wanted to make the CIDR match in alphanumeric, for the EXID I wanted
to keep them alphanumeric but keeping them in the original SOC grouping.
> 
>>
>> Signed-off-by: Ryan Wanner <Ryan.Wanner at microchip.com>
>> ---
>> Changes from v1 -> v2:
>> - Remove defines that are not yet in v6.7.
>>
>>  drivers/soc/atmel/soc.h | 38 +++++++++++++++++++-------------------
>>  1 file changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/soc/atmel/soc.h b/drivers/soc/atmel/soc.h
>> index 7a9f47ce85fb..1f2af6f74160 100644
>> --- a/drivers/soc/atmel/soc.h
>> +++ b/drivers/soc/atmel/soc.h
>> @@ -39,10 +39,10 @@ at91_soc_init(const struct at91_soc *socs);
>>  #define AT91SAM9261_CIDR_MATCH               0x019703a0
>>  #define AT91SAM9263_CIDR_MATCH               0x019607a0
>>  #define AT91SAM9G20_CIDR_MATCH               0x019905a0
>> -#define AT91SAM9RL64_CIDR_MATCH              0x019b03a0
>>  #define AT91SAM9G45_CIDR_MATCH               0x019b05a0
>> -#define AT91SAM9X5_CIDR_MATCH                0x019a05a0
>>  #define AT91SAM9N12_CIDR_MATCH               0x019a07a0
>> +#define AT91SAM9RL64_CIDR_MATCH              0x019b03a0
>> +#define AT91SAM9X5_CIDR_MATCH                0x019a05a0
>>  #define SAM9X60_CIDR_MATCH           0x019b35a0
>>  #define SAMA7G5_CIDR_MATCH           0x00162100
>>
>> @@ -61,23 +61,15 @@ at91_soc_init(const struct at91_soc *socs);
>>  #define AT91SAM9N12_EXID_MATCH               0x00000006
>>  #define AT91SAM9CN11_EXID_MATCH              0x00000009
>>
>> +#define AT91SAM9XE128_CIDR_MATCH     0x329973a0
>> +#define AT91SAM9XE256_CIDR_MATCH     0x329a93a0
>> +#define AT91SAM9XE512_CIDR_MATCH     0x329aa3a0
>> +
>>  #define SAM9X60_EXID_MATCH           0x00000000
>>  #define SAM9X60_D5M_EXID_MATCH               0x00000001
>>  #define SAM9X60_D1G_EXID_MATCH               0x00000010
>>  #define SAM9X60_D6K_EXID_MATCH               0x00000011
>>
>> -#define SAMA7G51_EXID_MATCH          0x3
>> -#define SAMA7G52_EXID_MATCH          0x2
>> -#define SAMA7G53_EXID_MATCH          0x1
>> -#define SAMA7G54_EXID_MATCH          0x0
>> -#define SAMA7G54_D1G_EXID_MATCH              0x00000018
>> -#define SAMA7G54_D2G_EXID_MATCH              0x00000020
>> -#define SAMA7G54_D4G_EXID_MATCH              0x00000028
>> -
>> -#define AT91SAM9XE128_CIDR_MATCH     0x329973a0
>> -#define AT91SAM9XE256_CIDR_MATCH     0x329a93a0
>> -#define AT91SAM9XE512_CIDR_MATCH     0x329aa3a0
>> -
>>  #define SAMA5D2_CIDR_MATCH           0x0a5c08c0
>>  #define SAMA5D21CU_EXID_MATCH                0x0000005a
>>  #define SAMA5D225C_D1M_EXID_MATCH    0x00000053
>> @@ -113,6 +105,14 @@ at91_soc_init(const struct at91_soc *socs);
>>  #define SAMA5D43_EXID_MATCH          0x00000003
>>  #define SAMA5D44_EXID_MATCH          0x00000004
>>
>> +#define SAMA7G51_EXID_MATCH          0x3
>> +#define SAMA7G52_EXID_MATCH          0x2
>> +#define SAMA7G53_EXID_MATCH          0x1
>> +#define SAMA7G54_EXID_MATCH          0x0
>> +#define SAMA7G54_D1G_EXID_MATCH              0x00000018
>> +#define SAMA7G54_D2G_EXID_MATCH              0x00000020
>> +#define SAMA7G54_D4G_EXID_MATCH              0x00000028
>> +
>>  #define SAME70Q21_CIDR_MATCH         0x21020e00
>>  #define SAME70Q21_EXID_MATCH         0x00000002
>>  #define SAME70Q20_CIDR_MATCH         0x21020c00
>> @@ -127,6 +127,11 @@ at91_soc_init(const struct at91_soc *socs);
>>  #define SAMS70Q19_CIDR_MATCH         0x211d0a00
>>  #define SAMS70Q19_EXID_MATCH         0x00000002
>>
>> +#define SAMV70Q20_CIDR_MATCH         0x21320c00
>> +#define SAMV70Q20_EXID_MATCH         0x00000002
>> +#define SAMV70Q19_CIDR_MATCH         0x213d0a00
>> +#define SAMV70Q19_EXID_MATCH         0x00000002
>> +
>>  #define SAMV71Q21_CIDR_MATCH         0x21220e00
>>  #define SAMV71Q21_EXID_MATCH         0x00000002
>>  #define SAMV71Q20_CIDR_MATCH         0x21220c00
>> @@ -134,9 +139,4 @@ at91_soc_init(const struct at91_soc *socs);
>>  #define SAMV71Q19_CIDR_MATCH         0x212d0a00
>>  #define SAMV71Q19_EXID_MATCH         0x00000002
>>
>> -#define SAMV70Q20_CIDR_MATCH         0x21320c00
>> -#define SAMV70Q20_EXID_MATCH         0x00000002
>> -#define SAMV70Q19_CIDR_MATCH         0x213d0a00
>> -#define SAMV70Q19_EXID_MATCH         0x00000002
>> -
>>  #endif /* __AT91_SOC_H */


From robin.murphy at arm.com  Mon Dec 11 07:01:27 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 11 Dec 2023 15:01:27 +0000
Subject: [PATCH 3/7] ACPI/IORT: Handle memory address size limits as
 limits
In-Reply-To: <20231211132757.GE25681@willie-the-truck>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <2ae6199a9cf035c1defd42e48675b827f41cdc95.1701268753.git.robin.murphy@arm.com>
 <20231211132757.GE25681@willie-the-truck>
Message-ID: <91b22090-485f-49c9-a536-849fd7f92f8e@arm.com>

On 2023-12-11 1:27 pm, Will Deacon wrote:
> On Wed, Nov 29, 2023 at 05:43:00PM +0000, Robin Murphy wrote:
>> Return the Root Complex/Named Component memory address size limit as an
>> inclusive limit value, rather than an exclusive size.  This saves us
>> having to special-case 64-bit overflow, and simplifies our caller too.
>>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> ---
>>   drivers/acpi/arm64/dma.c  |  9 +++------
>>   drivers/acpi/arm64/iort.c | 18 ++++++++----------
>>   include/linux/acpi_iort.h |  4 ++--
>>   3 files changed, 13 insertions(+), 18 deletions(-)
> 
> [...]
> 
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index 6496ff5a6ba2..eb64d8e17dd1 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -1367,7 +1367,7 @@ int iort_iommu_configure_id(struct device *dev, const u32 *input_id)
>>   { return -ENODEV; }
>>   #endif
>>   
>> -static int nc_dma_get_range(struct device *dev, u64 *size)
>> +static int nc_dma_get_range(struct device *dev, u64 *limit)
>>   {
>>   	struct acpi_iort_node *node;
>>   	struct acpi_iort_named_component *ncomp;
>> @@ -1384,13 +1384,12 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
>>   		return -EINVAL;
>>   	}
>>   
>> -	*size = ncomp->memory_address_limit >= 64 ? U64_MAX :
>> -			1ULL<<ncomp->memory_address_limit;
>> +	*limit = (1ULL << ncomp->memory_address_limit) - 1;
> 
> The old code handled 'ncomp->memory_address_limit >= 64' -- why is it safe
> to drop that? You mention it in the cover letter, so clearly I'm missing
> something!

Because an unsigned shift by 64 or more generates 0 (modulo 2^64), thus 
subtracting 1 results in the correct all-bits-set value for an inclusive 
64-bit limit.

Thanks,
Robin.

>>   
>>   	return 0;
>>   }
>>   
>> -static int rc_dma_get_range(struct device *dev, u64 *size)
>> +static int rc_dma_get_range(struct device *dev, u64 *limit)
>>   {
>>   	struct acpi_iort_node *node;
>>   	struct acpi_iort_root_complex *rc;
>> @@ -1408,8 +1407,7 @@ static int rc_dma_get_range(struct device *dev, u64 *size)
>>   		return -EINVAL;
>>   	}
>>   
>> -	*size = rc->memory_address_limit >= 64 ? U64_MAX :
>> -			1ULL<<rc->memory_address_limit;
>> +	*limit = (1ULL << rc->memory_address_limit) - 1;
> 
> Same thing here.
> 
> Will


From miquel.raynal at bootlin.com  Mon Dec 11 07:07:03 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Mon, 11 Dec 2023 16:07:03 +0100
Subject: [PATCH 1/2] mtd: rawnand: rockchip: Rename a structure
Message-ID: <20231211150704.109138-1-miquel.raynal@bootlin.com>

Robots are unhappy with the ecc_cnt_status structure because the kernel
doc says it should be called rk_ecc_cnt_status. In general, it is
considered a better practice to prefix all symbols in a file with the
same prexif, and thus it seems more relevant to rename the structure
rather than changing the kernel doc header.

Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312102130.geZ4dqyN-lkp at intel.com/
Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
 drivers/mtd/nand/raw/rockchip-nand-controller.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c b/drivers/mtd/nand/raw/rockchip-nand-controller.c
index 596cf9a78274..ab1a9e8687e0 100644
--- a/drivers/mtd/nand/raw/rockchip-nand-controller.c
+++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c
@@ -98,7 +98,7 @@ enum nfc_type {
  * @high: ECC count high bit index at register.
  * @high_mask: mask bit
  */
-struct ecc_cnt_status {
+struct rk_ecc_cnt_status {
 	u8 err_flag_bit;
 	u8 low;
 	u8 low_mask;
@@ -144,8 +144,8 @@ struct nfc_cfg {
 	u32 int_st_off;
 	u32 oob0_off;
 	u32 oob1_off;
-	struct ecc_cnt_status ecc0;
-	struct ecc_cnt_status ecc1;
+	struct rk_ecc_cnt_status ecc0;
+	struct rk_ecc_cnt_status ecc1;
 };
 
 struct rk_nfc_nand_chip {
-- 
2.34.1



From miquel.raynal at bootlin.com  Mon Dec 11 07:07:04 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Mon, 11 Dec 2023 16:07:04 +0100
Subject: [PATCH 2/2] mtd: rawnand: rockchip: Add missing title to a kernel doc comment
In-Reply-To: <20231211150704.109138-1-miquel.raynal@bootlin.com>
References: <20231211150704.109138-1-miquel.raynal@bootlin.com>
Message-ID: <20231211150704.109138-2-miquel.raynal@bootlin.com>

All fields of the nfc_cfg structure are documented but the name, which
leads to a W=1 warning. Add a title.

Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
 drivers/mtd/nand/raw/rockchip-nand-controller.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c b/drivers/mtd/nand/raw/rockchip-nand-controller.c
index ab1a9e8687e0..7baaef69d70a 100644
--- a/drivers/mtd/nand/raw/rockchip-nand-controller.c
+++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c
@@ -108,6 +108,7 @@ struct rk_ecc_cnt_status {
 };
 
 /**
+ * struct nfc_cfg: Rockchip NAND controller configuration
  * @type: NFC version
  * @ecc_strengths: ECC strengths
  * @ecc_cfgs: ECC config values
-- 
2.34.1



From thierry.reding at gmail.com  Mon Dec 11 07:24:35 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 11 Dec 2023 16:24:35 +0100
Subject: [PATCH] pwm: meson: Simplify using dev_err_probe()
In-Reply-To: <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
 <ZXbsDRslZNKCeJF9@orome.fritz.box>
 <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>
Message-ID: <ZXcpswXxb1oQldp5@orome.fritz.box>

On Mon, Dec 11, 2023 at 03:19:00PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Mon, Dec 11, 2023 at 12:01:33PM +0100, Thierry Reding wrote:
> > On Fri, Dec 08, 2023 at 08:06:20PM +0100, Uwe Kleine-K?nig wrote:
> > > On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> > > > This is a lot of churn for very little gain.
> > > 
> > > We seem to have different conceptions of churn. Each hunk here is an
> > > improvement for both SLOC count and usefulness of the generated error
> > > message.
> > > 
> > > 	failed to register somename: -5
> > > 
> > > is worse than
> > > 
> > > 	error EIO: failed to register somename
> > > 
> > > , isn't it?
> > 
> > That's entirely subjective.
> 
> It's not. You and me both know that -5 is EIO. But there are quite a few
> people who don't.

So it is, in fact, subjective.

>                   And for other error codes I'm not that fluent. (Do you
> know -2 and -19?) Also some constants are architecture specific, so e.g.
> -11 is -35 on alpha.

I didn't know about -11 and -35 on Alpha. Looks like %pe would handle
those properly, so yeah, I suppose one could count that as a benefit.
Not sure if we have PWM drivers that run on Alpha, and Meson in
particular probably doesn't.

> > I think the first version is just fine. I,
> > and I suspect most developers will, know what to do with either of those
> > error messages.
> 
> Error messages aren't only for (kernel) developers. If you don't know
> that the kernel uses negative error numbers as return codes, the
> translation of -5 to EIO is even further away than opening
> /usr/include/errno.h.

Actually, kernel developers are exactly who these error messages are
for. Regular users that don't know how to decipher the error codes are
typically not going to know what to do about the error anyway, so they
are likely just going to copy/paste into some forum or bug tracker.

> > > > None of these functions are ever going to return -EPROBE_DEFER. And
> > > > yes, I know that function's doc says that it is "deemed acceptable to
> > > > use" elsewhere. However, the existing error messages are just fine, no
> > > > need to churn just for the sake of it.
> > > 
> > > We had this disagreement already before. Yes dev_err_probe() is useful
> > > for three reasons and this driver only benefits from two of these.
> > > That's IMHO still one reason more than needed to justify such a change.
> > 
> > I disagree. There are certainly cases where dev_err_probe() can be a
> > significant improvement, but there are others where the improvement is
> > very minor (if there's any at all) and in my opinion the churn isn't
> > justified.
> 
> What is churn for you? Many changes? Big changes? For me churn is only a
> big amount of changes where a considerable part cancels out if it was
> squashed together. For you this concept seems to be broader.

Churn for me is really any kind of change and it's not bad per se. What
I don't like are changes that are basically done just for the sake of
changing something. I don't have any strict rules for this, so I apply
common sense. If you want to rewrite an error message because it
contains typos or bad grammar, or is generally hard to understand,
that's what I'd consider fine and an improvement.

But this patch exchanges one format of the error message by another. It
doesn't change the error message or the information content in any way,
but instead just rearranges where the error is printed.

On top of it not adding any benefit, this might cause somebody to get
confused because some error message that they were looking out for is
now different. They may have to adjust a script or something.

You also mentioned that you saw the opportunity to do this while
reviewing Jerome's patches and looking at those patches, Jerome will now
have to solve a couple of conflicts when rebasing. They should
admittedly be fairly minor, but if Jerome wasn't experienced this might
be really annoying. Again, if this was a significant improvement I'm
sure this would be easily acceptable, but if it's just for format's sake
I'm not so sure it is.

> > Otherwise we'll just forever keep rewriting the same code
> > over and over again because somebody comes up with yet another variant
> > of mostly the same code.
> 
> If there is an improvement in each adaption that's fine for me.

I can't speak for other maintainers, but I get very annoyed every time
somebody introduces some new helper and then I get to deal with 60 or so
patches just because there's a new thing that ultimately doesn't really
change or improve anything.

It's easier to apply 60 patches today that it was perhaps a few years
ago, but it also entails a bunch of things like reviewing the code
because sometimes even trivial conversions are faulty, the nrunning test
builds and pushing changes.

It all adds up in the end and keeps me from doing other things. Again,
if this all has some sort of benefit it makes sense to put in the time,
but if it's just for the sake of shuffling around parts of error
messages it just makes me grumpy.

Unfortunately, with all of that said I probably have no other choice but
to apply this patch because if I don't, then I know somebody else will
send the very same patch at some point...

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/d49cc4f5/attachment.sig>

From will at kernel.org  Mon Dec 11 07:30:24 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 15:30:24 +0000
Subject: [PATCH 3/7] ACPI/IORT: Handle memory address size limits as
 limits
In-Reply-To: <91b22090-485f-49c9-a536-849fd7f92f8e@arm.com>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <2ae6199a9cf035c1defd42e48675b827f41cdc95.1701268753.git.robin.murphy@arm.com>
 <20231211132757.GE25681@willie-the-truck>
 <91b22090-485f-49c9-a536-849fd7f92f8e@arm.com>
Message-ID: <20231211153023.GA26048@willie-the-truck>

On Mon, Dec 11, 2023 at 03:01:27PM +0000, Robin Murphy wrote:
> On 2023-12-11 1:27 pm, Will Deacon wrote:
> > On Wed, Nov 29, 2023 at 05:43:00PM +0000, Robin Murphy wrote:
> > > Return the Root Complex/Named Component memory address size limit as an
> > > inclusive limit value, rather than an exclusive size.  This saves us
> > > having to special-case 64-bit overflow, and simplifies our caller too.
> > > 
> > > Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> > > ---
> > >   drivers/acpi/arm64/dma.c  |  9 +++------
> > >   drivers/acpi/arm64/iort.c | 18 ++++++++----------
> > >   include/linux/acpi_iort.h |  4 ++--
> > >   3 files changed, 13 insertions(+), 18 deletions(-)
> > 
> > [...]
> > 
> > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > > index 6496ff5a6ba2..eb64d8e17dd1 100644
> > > --- a/drivers/acpi/arm64/iort.c
> > > +++ b/drivers/acpi/arm64/iort.c
> > > @@ -1367,7 +1367,7 @@ int iort_iommu_configure_id(struct device *dev, const u32 *input_id)
> > >   { return -ENODEV; }
> > >   #endif
> > > -static int nc_dma_get_range(struct device *dev, u64 *size)
> > > +static int nc_dma_get_range(struct device *dev, u64 *limit)
> > >   {
> > >   	struct acpi_iort_node *node;
> > >   	struct acpi_iort_named_component *ncomp;
> > > @@ -1384,13 +1384,12 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
> > >   		return -EINVAL;
> > >   	}
> > > -	*size = ncomp->memory_address_limit >= 64 ? U64_MAX :
> > > -			1ULL<<ncomp->memory_address_limit;
> > > +	*limit = (1ULL << ncomp->memory_address_limit) - 1;
> > 
> > The old code handled 'ncomp->memory_address_limit >= 64' -- why is it safe
> > to drop that? You mention it in the cover letter, so clearly I'm missing
> > something!
> 
> Because an unsigned shift by 64 or more generates 0 (modulo 2^64), thus
> subtracting 1 results in the correct all-bits-set value for an inclusive
> 64-bit limit.

Oh, I'd have thought you'd have gotten one of those "left shift count >=
width of type" warnings if you did that.

Will


From mark.rutland at arm.com  Mon Dec 11 07:37:20 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 11 Dec 2023 15:37:20 +0000
Subject: [PATCH 3/7] ACPI/IORT: Handle memory address size limits as
 limits
In-Reply-To: <91b22090-485f-49c9-a536-849fd7f92f8e@arm.com>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <2ae6199a9cf035c1defd42e48675b827f41cdc95.1701268753.git.robin.murphy@arm.com>
 <20231211132757.GE25681@willie-the-truck>
 <91b22090-485f-49c9-a536-849fd7f92f8e@arm.com>
Message-ID: <ZXcssPaaDtqADKp6@FVFF77S0Q05N.cambridge.arm.com>

On Mon, Dec 11, 2023 at 03:01:27PM +0000, Robin Murphy wrote:
> On 2023-12-11 1:27 pm, Will Deacon wrote:
> > On Wed, Nov 29, 2023 at 05:43:00PM +0000, Robin Murphy wrote:
> > > Return the Root Complex/Named Component memory address size limit as an
> > > inclusive limit value, rather than an exclusive size.  This saves us
> > > having to special-case 64-bit overflow, and simplifies our caller too.
> > > 
> > > Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> > > ---
> > >   drivers/acpi/arm64/dma.c  |  9 +++------
> > >   drivers/acpi/arm64/iort.c | 18 ++++++++----------
> > >   include/linux/acpi_iort.h |  4 ++--
> > >   3 files changed, 13 insertions(+), 18 deletions(-)
> > 
> > [...]
> > 
> > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > > index 6496ff5a6ba2..eb64d8e17dd1 100644
> > > --- a/drivers/acpi/arm64/iort.c
> > > +++ b/drivers/acpi/arm64/iort.c
> > > @@ -1367,7 +1367,7 @@ int iort_iommu_configure_id(struct device *dev, const u32 *input_id)
> > >   { return -ENODEV; }
> > >   #endif
> > > -static int nc_dma_get_range(struct device *dev, u64 *size)
> > > +static int nc_dma_get_range(struct device *dev, u64 *limit)
> > >   {
> > >   	struct acpi_iort_node *node;
> > >   	struct acpi_iort_named_component *ncomp;
> > > @@ -1384,13 +1384,12 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
> > >   		return -EINVAL;
> > >   	}
> > > -	*size = ncomp->memory_address_limit >= 64 ? U64_MAX :
> > > -			1ULL<<ncomp->memory_address_limit;
> > > +	*limit = (1ULL << ncomp->memory_address_limit) - 1;
> > 
> > The old code handled 'ncomp->memory_address_limit >= 64' -- why is it safe
> > to drop that? You mention it in the cover letter, so clearly I'm missing
> > something!
> 
> Because an unsigned shift by 64 or more generates 0 (modulo 2^64), 

I'm pretty sure that regardless of whether a type is signed, shifting more than
the type's width is undefined behaviour. That causes GCC to scream at compile
time:

|   CC      arch/arm64/kernel/setup.o
| arch/arm64/kernel/setup.c: In function 'shift_test':
| arch/arm64/kernel/setup.c:295:20: warning: left shift count >= width of type [-Wshift-count-overflow]
|   295 |         return 1UL << 64;
|       |                    ^~

... and a UBSAN splat:

| ================================================================================
| UBSAN: shift-out-of-bounds in arch/arm64/kernel/setup.c:295:13
| shift exponent 64 is too large for 64-bit type 'long unsigned int'
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.7.0-rc1-00005-g06034455cb74-dirty #3
| Call trace:
|  dump_backtrace+0x90/0xe8
|  show_stack+0x18/0x24
|  dump_stack_lvl+0x48/0x60
|  dump_stack+0x18/0x24
|  __ubsan_handle_shift_out_of_bounds+0x114/0x244
|  shift_test+0x24/0x34
|  setup_arch+0x238/0x68c
|  start_kernel+0x70/0x610
|  __primary_switched+0xbc/0xc4
| ================================================================================

Mark.

> thus
> subtracting 1 results in the correct all-bits-set value for an inclusive
> 64-bit limit.
> 
> Thanks,
> Robin.
> 
> > >   	return 0;
> > >   }
> > > -static int rc_dma_get_range(struct device *dev, u64 *size)
> > > +static int rc_dma_get_range(struct device *dev, u64 *limit)
> > >   {
> > >   	struct acpi_iort_node *node;
> > >   	struct acpi_iort_root_complex *rc;
> > > @@ -1408,8 +1407,7 @@ static int rc_dma_get_range(struct device *dev, u64 *size)
> > >   		return -EINVAL;
> > >   	}
> > > -	*size = rc->memory_address_limit >= 64 ? U64_MAX :
> > > -			1ULL<<rc->memory_address_limit;
> > > +	*limit = (1ULL << rc->memory_address_limit) - 1;
> > 
> > Same thing here.
> > 
> > Will


From robin.murphy at arm.com  Mon Dec 11 07:37:55 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 11 Dec 2023 15:37:55 +0000
Subject: [PATCH 3/7] ACPI/IORT: Handle memory address size limits as
 limits
In-Reply-To: <20231211153023.GA26048@willie-the-truck>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <2ae6199a9cf035c1defd42e48675b827f41cdc95.1701268753.git.robin.murphy@arm.com>
 <20231211132757.GE25681@willie-the-truck>
 <91b22090-485f-49c9-a536-849fd7f92f8e@arm.com>
 <20231211153023.GA26048@willie-the-truck>
Message-ID: <5dbd5717-1107-4a21-b166-995630499607@arm.com>

On 2023-12-11 3:30 pm, Will Deacon wrote:
> On Mon, Dec 11, 2023 at 03:01:27PM +0000, Robin Murphy wrote:
>> On 2023-12-11 1:27 pm, Will Deacon wrote:
>>> On Wed, Nov 29, 2023 at 05:43:00PM +0000, Robin Murphy wrote:
>>>> Return the Root Complex/Named Component memory address size limit as an
>>>> inclusive limit value, rather than an exclusive size.  This saves us
>>>> having to special-case 64-bit overflow, and simplifies our caller too.
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>>> ---
>>>>    drivers/acpi/arm64/dma.c  |  9 +++------
>>>>    drivers/acpi/arm64/iort.c | 18 ++++++++----------
>>>>    include/linux/acpi_iort.h |  4 ++--
>>>>    3 files changed, 13 insertions(+), 18 deletions(-)
>>>
>>> [...]
>>>
>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>>> index 6496ff5a6ba2..eb64d8e17dd1 100644
>>>> --- a/drivers/acpi/arm64/iort.c
>>>> +++ b/drivers/acpi/arm64/iort.c
>>>> @@ -1367,7 +1367,7 @@ int iort_iommu_configure_id(struct device *dev, const u32 *input_id)
>>>>    { return -ENODEV; }
>>>>    #endif
>>>> -static int nc_dma_get_range(struct device *dev, u64 *size)
>>>> +static int nc_dma_get_range(struct device *dev, u64 *limit)
>>>>    {
>>>>    	struct acpi_iort_node *node;
>>>>    	struct acpi_iort_named_component *ncomp;
>>>> @@ -1384,13 +1384,12 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
>>>>    		return -EINVAL;
>>>>    	}
>>>> -	*size = ncomp->memory_address_limit >= 64 ? U64_MAX :
>>>> -			1ULL<<ncomp->memory_address_limit;
>>>> +	*limit = (1ULL << ncomp->memory_address_limit) - 1;
>>>
>>> The old code handled 'ncomp->memory_address_limit >= 64' -- why is it safe
>>> to drop that? You mention it in the cover letter, so clearly I'm missing
>>> something!
>>
>> Because an unsigned shift by 64 or more generates 0 (modulo 2^64), thus
>> subtracting 1 results in the correct all-bits-set value for an inclusive
>> 64-bit limit.
> 
> Oh, I'd have thought you'd have gotten one of those "left shift count >=
> width of type" warnings if you did that.

Compilers might give such a warning if it was a constant shift whose 
size was visible at compile time, but even then only because compilers 
seem to have a vendetta against us relying on the well-defined 
behaviours of unsigned integer overflow (it's only *signed* shifts which 
are UB if the result is unrepresentable).

Cheers,
Robin.


From mark.rutland at arm.com  Mon Dec 11 07:39:56 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 11 Dec 2023 15:39:56 +0000
Subject: [PATCH 3/7] ACPI/IORT: Handle memory address size limits as
 limits
In-Reply-To: <20231211153023.GA26048@willie-the-truck>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <2ae6199a9cf035c1defd42e48675b827f41cdc95.1701268753.git.robin.murphy@arm.com>
 <20231211132757.GE25681@willie-the-truck>
 <91b22090-485f-49c9-a536-849fd7f92f8e@arm.com>
 <20231211153023.GA26048@willie-the-truck>
Message-ID: <ZXctTJ-q9e1FPBhH@FVFF77S0Q05N.cambridge.arm.com>

On Mon, Dec 11, 2023 at 03:30:24PM +0000, Will Deacon wrote:
> On Mon, Dec 11, 2023 at 03:01:27PM +0000, Robin Murphy wrote:
> > On 2023-12-11 1:27 pm, Will Deacon wrote:
> > > On Wed, Nov 29, 2023 at 05:43:00PM +0000, Robin Murphy wrote:
> > > > Return the Root Complex/Named Component memory address size limit as an
> > > > inclusive limit value, rather than an exclusive size.  This saves us
> > > > having to special-case 64-bit overflow, and simplifies our caller too.
> > > > 
> > > > Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> > > > ---
> > > >   drivers/acpi/arm64/dma.c  |  9 +++------
> > > >   drivers/acpi/arm64/iort.c | 18 ++++++++----------
> > > >   include/linux/acpi_iort.h |  4 ++--
> > > >   3 files changed, 13 insertions(+), 18 deletions(-)
> > > 
> > > [...]
> > > 
> > > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > > > index 6496ff5a6ba2..eb64d8e17dd1 100644
> > > > --- a/drivers/acpi/arm64/iort.c
> > > > +++ b/drivers/acpi/arm64/iort.c
> > > > @@ -1367,7 +1367,7 @@ int iort_iommu_configure_id(struct device *dev, const u32 *input_id)
> > > >   { return -ENODEV; }
> > > >   #endif
> > > > -static int nc_dma_get_range(struct device *dev, u64 *size)
> > > > +static int nc_dma_get_range(struct device *dev, u64 *limit)
> > > >   {
> > > >   	struct acpi_iort_node *node;
> > > >   	struct acpi_iort_named_component *ncomp;
> > > > @@ -1384,13 +1384,12 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
> > > >   		return -EINVAL;
> > > >   	}
> > > > -	*size = ncomp->memory_address_limit >= 64 ? U64_MAX :
> > > > -			1ULL<<ncomp->memory_address_limit;
> > > > +	*limit = (1ULL << ncomp->memory_address_limit) - 1;
> > > 
> > > The old code handled 'ncomp->memory_address_limit >= 64' -- why is it safe
> > > to drop that? You mention it in the cover letter, so clearly I'm missing
> > > something!
> > 
> > Because an unsigned shift by 64 or more generates 0 (modulo 2^64), thus
> > subtracting 1 results in the correct all-bits-set value for an inclusive
> > 64-bit limit.
> 
> Oh, I'd have thought you'd have gotten one of those "left shift count >=
> width of type" warnings if you did that.

I think you'll get a UBSAN splat, but here the compiler doesn't know what
'ncomp->memory_address_limit' will be and so doesn't produce a compile-time
warning.

Regardless, it's undefined behaviour.

Mark.


From will at kernel.org  Mon Dec 11 07:40:16 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 15:40:16 +0000
Subject: [PATCH 0/7] Convert SMMU to domain_alloc_paging()
In-Reply-To: <ZXcZL19OLbctV_W-@8bytes.org>
References: <0-v1-cf5846854f51+6db3f-smmu_newapi_jgg@nvidia.com>
 <20231130004905.GA1395649@nvidia.com>
 <ZXcZL19OLbctV_W-@8bytes.org>
Message-ID: <20231211154016.GB26048@willie-the-truck>

On Mon, Dec 11, 2023 at 03:14:07PM +0100, Joerg Roedel wrote:
> On Wed, Nov 29, 2023 at 08:49:05PM -0400, Jason Gunthorpe wrote:
> > This is still pending, it doesn't need rebasing on v6.7
> > 
> > The DART patches were merges so all the dependencies are in v6.7 now.
> 
> This is mostly ARM-SMMU, so I leave it to Will and Robin to
> decide/pick-up.

Cheers, Joerg. It's on my list of stuff to look at.

Will


From suzuki.poulose at arm.com  Mon Dec 11 07:42:41 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 11 Dec 2023 15:42:41 +0000
Subject: [PATCH V2] coresight: tmc: Make etr buffer mode user configurable
 from sysfs
In-Reply-To: <25f46f87-2090-46ca-9ef7-1310b4360801@os.amperecomputing.com>
References: <20230818082112.554638-1-anshuman.khandual@arm.com>
 <bedcf27e-b273-075f-3d7b-eb99b07e7c91@arm.com>
 <b2cf0173-c404-d7d6-9eb8-054e160ca4e5@os.amperecomputing.com>
 <ffa90e80-c249-42d5-26f1-dc022d91e5a9@os.amperecomputing.com>
 <391951c3-7da9-3965-acf8-f3b31f822879@os.amperecomputing.com>
 <1b2a035c-489e-ace9-f851-c1ec157ff9fa@arm.com>
 <cc1b1082-2bcb-9d76-afc7-0e12edd694f0@os.amperecomputing.com>
 <f9fddb60-6976-6d99-fcc2-8011d2fadeb7@arm.com>
 <134faf1d-d662-0e26-d9db-c98645ef6243@arm.com>
 <e7b4dce7-7197-0976-c302-a81444b712aa@os.amperecomputing.com>
 <25f46f87-2090-46ca-9ef7-1310b4360801@os.amperecomputing.com>
Message-ID: <80c5681e-6f54-421c-aa18-eedd4d464d64@arm.com>

Hi Steve

On 04/12/2023 21:41, Steve Clevenger wrote:
> 
> Hi Suzuki,
> 
> On 9/7/2023 2:31 PM, Steve Clevenger wrote:
>>
>> Hi Suzuki,
>>
>> On 9/1/2023 5:22 AM, Suzuki K Poulose wrote:
>>> Hi Steve
>>>
>>> On 30/08/2023 17:04, Suzuki K Poulose wrote:
>>>> Cc: Sudeep
>>>>
>>>> Hi Steve
>>>>
>>>> On 28/08/2023 17:35, Steve Clevenger wrote:
>>>>>
>>>>> Hi Suzuki,
>>>>>
>>>>> On 8/27/2023 2:35 PM, Suzuki K Poulose wrote:
>>>>>> Hi Steve
>>>>>>
>>>>>> On 26/08/2023 01:14, Steve Clevenger wrote:
>>>>>>>
>>>>>>> Unfortunately, I tested with the original patch not [PATCH V2]. I've
>>>>>>> remedied this. My results below:
>>>>>>>
>>>>>>> [root at sut01sys-b212 linux]# cat
>>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_modes_available
>>>>>>> auto flat catu
>>>>>>> [root at sut01sys-b212 linux]# cat
>>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_mode_preferred
>>>>>>> auto
>>>>>>> [root at sut01sys-b212 linux]# echo "catu" >
>>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_mode_preferred
>>>>>>> [root at sut01sys-b212 linux]# cat
>>>>>>> /sys/devices/system/cpu/cpu123/ARMHC501\:23/tmc_etr35/buf_mode_preferred
>>>>>>> catu
>>>>>>>
>>>>>>> As with the V1 patch, auto defaults to catu.
>>>>>>>
>>>>>>> I expected to see tmc-sg (former default) as an available mode, but do
>>>>>>> not. As I recall, the buffer mode defaulted to ETR scatter-gather
>>>>>>> prior
>>>>>>> to this patch. Must this capability now be explicitly advertised? I've
>>>>>>> seen this done as "arm,scatter-gather" in device trees, but not
>>>>>>> used by
>>>>>>> Ampere. Perhaps someone can enlighten me.
>>>>>>
>>>>>> Yes, you must add that property to the TMC-ETR node (for both DT and
>>>>>> ACPI). In the past, almost all of the TMC-ETRs (except Juno board)
>>>>>> locked up the system while using the SG mode (due to the interconnect
>>>>>> issues, something to do with the transaction). Thus, we decided to
>>>>>> add a property explicitly enabling this for a given platform.
>>>>>>
>>>>>> When you mentioned, it was using TMC-ETR SG mode, how did you verify
>>>>>> this ? Please be aware that the table allocation code etc are shared
>>>>>> by both TMC-SG and CATU.
>>>>>>
>>>>>
>>>>> You might recall how this started. I had no way to test the CATU due to
>>>>> the order the ETR modes defaulted (Flat, ETR-SG, CATU). For test
>>>>> purposes, I programmatically swapped the ETR-SG/CATU order and could
>>>>> then verify CATU operation by the driver calling into CATU code. This
>>>>
>>>> So, were you using the DT based boot for the above runs ?
>>>>
>>>>> suggests Flat mode was bypassed, and the driver defaulted to ETR-SG
>>>>> prior to this hack. This didn't offer the user any control, hence my
>>>>> feature request. Note that most of the early Ampere self-hosted trace
>>>>> collection used ETR-SG. Now I can't select it.
>>>>
>>>>
>>>>>
>>>>> How is this property described in the ACPI? The "ACPI for CoreSight? 1.1
>>>>> Platform Design Document" (DEN0067) doesn't describe this.
>>>>
>>>> This is not specified in the ACPI platform design document. I can get
>>>> it fixed. Ideally we need a property describing that the scatter-gather
>>>> mode is safe to use.
>>>
>>> Looks like this is not straight forward copying of DT property. We are
>>> investigating this on our side and will get back to you.
> 
> I noticed this work is queued for 6.7 (coresight-next-6.7). Do you have
> an update to the ACPI platform design document Ampere can use to base an
> update so the scatter-gather mode can be used?

I have chased this with the specification team, and we should have
something published soon. Apologies for the delay.

Suzuki

> 
> Thanks,
> Steve
> 
>>>
>>
>> The intent behind my request was to have a way to SysFS configure the
>> (available) ETR mode. Unless there's a change to the ACPI, the CATU is
>> the only SG option for Ampere in the near term.
>>
>> Thanks,
>> Steve
>>
>>
>>> Suzuki
>>>
>>>
>>>>
>>>> DT uses "arm,scatter-gather" property [0] and this is what we now expect
>>>> in the ACPI based systems too.
>>>>
>>>> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml#:~:text=71-,72,-73
>>>>
>>>> Does it sound fine ?
>>>>
>>>> Suzuki
>>>>
>>>>>
>>>>> Thanks,
>>>>> Steve
>>>>>
>>>>>
>>>>>> Kind regards
>>>>>> Suzuki
>>>>>>
>>>>>>>
>>>>>>> Steve C.
>>>>>>>
>>>>>>> On 8/23/2023 4:10 PM, Steve Clevenger wrote:
>>>>>>>>
>>>>>>>> Here's some quick feedback. My system shows two modes available; auto
>>>>>>>> catu
>>>>>>>>
>>>>>>>> etr_buf_mode_current is writable. I expected to see tmc-sg (former
>>>>>>>> default) listed in etr_buf_modes_available but it doesn't show up.
>>>>>>>>
>>>>>>>> Note that both the auto and catu etr_buf_mode_current settings
>>>>>>>> default
>>>>>>>> to catu. My understanding is auto should revert to the default
>>>>>>>> behavior.
>>>>>>>> On my system the default was tmc-sg.
>>>>>>>>
>>>>>>>> More later.
>>>>>>>>
>>>>>>>> [root at sut01sys-b212 kernel]# cat
>>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_modes_available
>>>>>>>>
>>>>>>>> auto catu
>>>>>>>> [root at sut01sys-b212 kernel]# cat
>>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_mode_current
>>>>>>>> catu
>>>>>>>> [root at sut01sys-b212 kernel]# echo "catu" >
>>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_mode_current
>>>>>>>> [root at sut01sys-b212 kernel]# cat
>>>>>>>> /sys/devices/system/cpu/cpu20/ARMHC501\:60/tmc_etr96/etr_buf_mode_current
>>>>>>>> catu
>>>>>>>>
>>>>>>>> Steve C.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/21/2023 12:40 PM, Steve Clevenger wrote:
>>>>>>>>>
>>>>>>>>> Hi Suzuki,
>>>>>>>>>
>>>>>>>>> I may be able to test it this week. You've already pointed me at the
>>>>>>>>> patch thread(s). The main holdup is I need to merge the 6.6 pending
>>>>>>>>> platform work in order to use the Ampere ACPI. I couldn't get these
>>>>>>>>> patches to apply directly to 6.4 last I tried.
>>>>>>>>>
>>>>>>>>> Steve C.
>>>>>>>>>
>>>>>>>>> On 8/18/2023 2:39 AM, Suzuki K Poulose wrote:
>>>>>>>>>> Cc: Steve
>>>>>>>>>>
>>>>>>>>>> Steve,
>>>>>>>>>>
>>>>>>>>>> Are you able to test this with CATU ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 18/08/2023 09:21, Anshuman Khandual wrote:
>>>>>>>>>>> Currently TMC-ETR automatically selects the buffer mode from all
>>>>>>>>>>> available
>>>>>>>>>>> methods in the following sequentially fallback manner - also in
>>>>>>>>>>> that
>>>>>>>>>>> order.
>>>>>>>>>>>
>>>>>>>>>>> 1. FLAT mode with or without IOMMU
>>>>>>>>>>> 2. TMC-ETR-SG (scatter gather) mode when available
>>>>>>>>>>> 3. CATU mode when available
>>>>>>>>>>>
>>>>>>>>>>> But this order might not be ideal for all situations. For
>>>>>>>>>>> example if
>>>>>>>>>>> there
>>>>>>>>>>> is a CATU connected to ETR, it may be better to use TMC-ETR
>>>>>>>>>>> scatter
>>>>>>>>>>> gather
>>>>>>>>>>> method, rather than CATU. But hard coding such order changes will
>>>>>>>>>>> prevent
>>>>>>>>>>> us from testing or using a particular mode. This change provides
>>>>>>>>>>> following
>>>>>>>>>>> new sysfs tunables for the user to control TMC-ETR buffer mode
>>>>>>>>>>> explicitly,
>>>>>>>>>>> if required. This adds following new sysfs files for buffer mode
>>>>>>>>>>> selection
>>>>>>>>>>> purpose explicitly in the user space.
>>>>>>>>>>>
>>>>>>>>>>> /sys/bus/coresight/devices/tmc_etr<N>/buf_modes_available
>>>>>>>>>>> /sys/bus/coresight/devices/tmc_etr<N>/buf_mode_preferred
>>>>>>>>>>>
>>>>>>>>>>> $ cat buf_modes_available
>>>>>>>>>>> auto flat tmc-sg catu??? ------------------> Supported TMC-ETR
>>>>>>>>>>> buffer
>>>>>>>>>>> modes
>>>>>>>>>>>
>>>>>>>>>>> $ echo catu > buf_mode_preferred?? -------> Explicit buffer mode
>>>>>>>>>>> request
>>>>>>>>>>>
>>>>>>>>>>> But explicit user request has to be within supported ETR buffer
>>>>>>>>>>> modes
>>>>>>>>>>> only.
>>>>>>>>>>> These sysfs interface files are exclussive to ETR, and hence these
>>>>>>>>>>> are
>>>>>>>>>>> not
>>>>>>>>>>> available for other TMC devices such as ETB or ETF etc.
>>>>>>>>>>>
>>>>>>>>>>> A new auto' mode (i.e ETR_MODE_AUTO) has been added to help
>>>>>>>>>>> fallback
>>>>>>>>>>> to the
>>>>>>>>>>> existing default behaviour, when user provided preferred buffer
>>>>>>>>>>> mode
>>>>>>>>>>> fails.
>>>>>>>>>>> ETR_MODE_FLAT and ETR_MODE_AUTO are always available as preferred
>>>>>>>>>>> modes.
>>>>>>>>>>>
>>>>>>>>>>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>>>>>>>>>>> Cc: Mike Leach <mike.leach at linaro.org>
>>>>>>>>>>> Cc: James Clark <james.clark at arm.com>
>>>>>>>>>>> Cc: Leo Yan <leo.yan at linaro.org>
>>>>>>>>>>> Cc: Alexander Shishkin <alexander.shishkin at linux.intel.com>
>>>>>>>>>>> Cc: coresight at lists.linaro.org
>>>>>>>>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>>>>>>>>> Cc: linux-kernel at vger.kernel.org
>>>>>>>>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>>>>>>>>>> ---
>>>>>>>>>>> This applies on v6.5-rc6
>>>>>>>>>>>
>>>>>>>>>>> Changes in V2:
>>>>>>>>>>>
>>>>>>>>>>> - Renamed sysfs file etr_buf_modes_available as
>>>>>>>>>>> buf_modes_available
>>>>>>>>>>> - Renamed sysfs file buf_mode_current as buf_mode_preferred
>>>>>>>>>>> - Renamed etr_supports_flat_mode() as etr_can_use_flat_mode()
>>>>>>>>>>> - Renamed coresight_tmc_groups[] as coresight_etf_groups[]
>>>>>>>>>>> - Reused coresight_tmc_group[] for trigger_cntr and buffer_size
>>>>>>>>>>> - Fallback trying ETR_MODE_AUTO when user preferred mode fails
>>>>>>>>>>> - Moved ETR sysfs details into coresight-tmc-etr.c
>>>>>>>>>>> - Dropped etr_can_use_flat_mode() check while offering
>>>>>>>>>>> ETR_MODE_FLAT
>>>>>>>>>>> in sysfs
>>>>>>>>>>> - Moved struct etr_buf_hw inside coresight-tmc-etr.c
>>>>>>>>>>> - Moved get_etr_buf_hw() and etr_can_use_flat_mode() inside
>>>>>>>>>>> coresight-tmc-etr.c
>>>>>>>>>>> - Updated month in
>>>>>>>>>>> Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
>>>>>>>>>>>
>>>>>>>>>>> Changes in V1:
>>>>>>>>>>>
>>>>>>>>>>> https://lore.kernel.org/all/20230728084837.276551-1-anshuman.khandual at arm.com/
>>>>>>>>>>>
>>>>>>>>>>>  ??? .../testing/sysfs-bus-coresight-devices-tmc?? |? 16 +++
>>>>>>>>>>>  ??? .../hwtracing/coresight/coresight-tmc-core.c? |? 15 ++-
>>>>>>>>>>>  ??? .../hwtracing/coresight/coresight-tmc-etr.c?? | 111
>>>>>>>>>>> ++++++++++++++++--
>>>>>>>>>>>  ??? drivers/hwtracing/coresight/coresight-tmc.h?? |?? 3 +
>>>>>>>>>>>  ??? 4 files changed, 131 insertions(+), 14 deletions(-)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Looks good to me.
>>>>>>>>>>
>>>>>>>>>> Suzuki
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>



From hch at infradead.org  Mon Dec 11 08:02:42 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:02:42 -0800
Subject: [RFC PATCH 01/12] arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-2-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-2-samuel.holland@sifive.com>
Message-ID: <ZXcyolSnTj1sts33@infradead.org>

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at infradead.org  Mon Dec 11 08:04:05 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:04:05 -0800
Subject: [RFC PATCH 02/12] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-3-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-3-samuel.holland@sifive.com>
Message-ID: <ZXcy9YUWrC586RX+@infradead.org>

> --- /dev/null
> +++ b/arch/arm/include/asm/fpu.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * linux/arch/arm/include/asm/fpu.h

Please don't add the file name to top of the file comments.  It serves
no purpose and easily gets out of date.

Except for that:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at infradead.org  Mon Dec 11 08:04:29 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:04:29 -0800
Subject: [RFC PATCH 03/12] ARM: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
In-Reply-To: <20231208055501.2916202-4-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-4-samuel.holland@sifive.com>
Message-ID: <ZXczDXH6KZWwcWLQ@infradead.org>

On Thu, Dec 07, 2023 at 09:54:33PM -0800, Samuel Holland wrote:
> Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
> tree, use it instead of duplicating the flags here.

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at infradead.org  Mon Dec 11 08:05:12 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:05:12 -0800
Subject: [RFC PATCH 04/12] arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-5-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-5-samuel.holland@sifive.com>
Message-ID: <ZXczOCP8GR4xrkUD@infradead.org>

> + * linux/arch/arm64/include/asm/fpu.h

Same comment as for arm here.  Except for that:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at infradead.org  Mon Dec 11 08:07:19 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:07:19 -0800
Subject: [RFC PATCH 05/12] lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
In-Reply-To: <20231208055501.2916202-6-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-6-samuel.holland@sifive.com>
Message-ID: <ZXczty+Y6dTDL4Xi@infradead.org>

> +CFLAGS_REMOVE_neon1.o += $(CC_FLAGS_NO_FPU)
> +CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
> +CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
> +CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)

Btw, do we even really need the extra variables for compiler flags
to remove?  Don't gcc/clang options work so that if you add a
no-prefixed version of the option later it transparently gets removed?

Except for that:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at infradead.org  Mon Dec 11 08:07:44 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:07:44 -0800
Subject: [RFC PATCH 06/12] LoongArch: Implement
 ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-7-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-7-samuel.holland@sifive.com>
Message-ID: <ZXcz0NVitD1pQJ5V@infradead.org>

On Thu, Dec 07, 2023 at 09:54:36PM -0800, Samuel Holland wrote:
> LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
> asm/fpu.h, so it only needs to add kernel_fpu_available() and export
> the CFLAGS adjustments.

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at infradead.org  Mon Dec 11 08:08:28 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:08:28 -0800
Subject: [RFC PATCH 07/12] powerpc: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-8-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-8-samuel.holland@sifive.com>
Message-ID: <ZXcz/Bi6xP1CYK60@infradead.org>

On Thu, Dec 07, 2023 at 09:54:37PM -0800, Samuel Holland wrote:
> PowerPC provides an equivalent to the common kernel-mode FPU API, but in
> a different header and using different function names. The PowerPC API
> also requires a non-preemptible context. Add a wrapper header, and
> export the CFLAGS adjustments.

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at infradead.org  Mon Dec 11 08:08:59 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:08:59 -0800
Subject: [RFC PATCH 08/12] x86: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-9-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-9-samuel.holland@sifive.com>
Message-ID: <ZXc0GwtgeO3PL1K9@infradead.org>

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at infradead.org  Mon Dec 11 08:11:24 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:11:24 -0800
Subject: [RFC PATCH 09/12] riscv: Add support for kernel-mode FPU
In-Reply-To: <20231208055501.2916202-10-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-10-samuel.holland@sifive.com>
Message-ID: <ZXc0rAdi7Vo8nbS8@infradead.org>

> +#ifdef __riscv_f
> +
> +#define kernel_fpu_begin() \
> +	static_assert(false, "floating-point code must use a separate translation unit")
> +#define kernel_fpu_end() kernel_fpu_begin()
> +
> +#else
> +
> +void kernel_fpu_begin(void);
> +void kernel_fpu_end(void);
> +
> +#endif

I'll assume this is related to trick that places code in a separate
translation unit, but I fail to understand it.  Can you add a comment
explaining it?



From robin.murphy at arm.com  Mon Dec 11 08:13:38 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 11 Dec 2023 16:13:38 +0000
Subject: [PATCH 3/7] ACPI/IORT: Handle memory address size limits as
 limits
In-Reply-To: <ZXctTJ-q9e1FPBhH@FVFF77S0Q05N.cambridge.arm.com>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <2ae6199a9cf035c1defd42e48675b827f41cdc95.1701268753.git.robin.murphy@arm.com>
 <20231211132757.GE25681@willie-the-truck>
 <91b22090-485f-49c9-a536-849fd7f92f8e@arm.com>
 <20231211153023.GA26048@willie-the-truck>
 <ZXctTJ-q9e1FPBhH@FVFF77S0Q05N.cambridge.arm.com>
Message-ID: <ae904525-66e7-4702-925d-0d42481cd354@arm.com>

On 2023-12-11 3:39 pm, Mark Rutland wrote:
> On Mon, Dec 11, 2023 at 03:30:24PM +0000, Will Deacon wrote:
>> On Mon, Dec 11, 2023 at 03:01:27PM +0000, Robin Murphy wrote:
>>> On 2023-12-11 1:27 pm, Will Deacon wrote:
>>>> On Wed, Nov 29, 2023 at 05:43:00PM +0000, Robin Murphy wrote:
>>>>> Return the Root Complex/Named Component memory address size limit as an
>>>>> inclusive limit value, rather than an exclusive size.  This saves us
>>>>> having to special-case 64-bit overflow, and simplifies our caller too.
>>>>>
>>>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>>>> ---
>>>>>    drivers/acpi/arm64/dma.c  |  9 +++------
>>>>>    drivers/acpi/arm64/iort.c | 18 ++++++++----------
>>>>>    include/linux/acpi_iort.h |  4 ++--
>>>>>    3 files changed, 13 insertions(+), 18 deletions(-)
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>>>> index 6496ff5a6ba2..eb64d8e17dd1 100644
>>>>> --- a/drivers/acpi/arm64/iort.c
>>>>> +++ b/drivers/acpi/arm64/iort.c
>>>>> @@ -1367,7 +1367,7 @@ int iort_iommu_configure_id(struct device *dev, const u32 *input_id)
>>>>>    { return -ENODEV; }
>>>>>    #endif
>>>>> -static int nc_dma_get_range(struct device *dev, u64 *size)
>>>>> +static int nc_dma_get_range(struct device *dev, u64 *limit)
>>>>>    {
>>>>>    	struct acpi_iort_node *node;
>>>>>    	struct acpi_iort_named_component *ncomp;
>>>>> @@ -1384,13 +1384,12 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
>>>>>    		return -EINVAL;
>>>>>    	}
>>>>> -	*size = ncomp->memory_address_limit >= 64 ? U64_MAX :
>>>>> -			1ULL<<ncomp->memory_address_limit;
>>>>> +	*limit = (1ULL << ncomp->memory_address_limit) - 1;
>>>>
>>>> The old code handled 'ncomp->memory_address_limit >= 64' -- why is it safe
>>>> to drop that? You mention it in the cover letter, so clearly I'm missing
>>>> something!
>>>
>>> Because an unsigned shift by 64 or more generates 0 (modulo 2^64), thus
>>> subtracting 1 results in the correct all-bits-set value for an inclusive
>>> 64-bit limit.
>>
>> Oh, I'd have thought you'd have gotten one of those "left shift count >=
>> width of type" warnings if you did that.
> 
> I think you'll get a UBSAN splat, but here the compiler doesn't know what
> 'ncomp->memory_address_limit' will be and so doesn't produce a compile-time
> warning.
> 
> Regardless, it's undefined behaviour.

Urgh, you're right... I double-checked 6.5.7.4 in the standard but 
managed to miss 6.5.7.3. So yeah, even though "4 << 62" or "2 << 63" are 
well-defined here, "1  << 64" isn't, dang. Thanks, funky old ISAs which 
did weird things for crazy large shifts and have no relevance to this 
code :(

Cheers,
Robin.


From james.clark at arm.com  Mon Dec 11 08:13:12 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:12 +0000
Subject: [PATCH v7 00/11] arm64: perf: Add support for event counting threshold
Message-ID: <20231211161331.1277825-1-james.clark@arm.com>

Changes since v6:

  * Remove inlines from arm_pmuv3.c
  * Use format attribute mechanism from SPE
  * Re-arrange attributes so that threshold comes last and can
    potentially be extended
  * Emit an error if the max threshold is exceeded rather than clamping
  * Convert all register fields to GENMASK

Changes since v5:
  * Restructure the docs and add some more explanations
  * PMMIR.WIDTH -> PMMIR.THWIDTH in one comment
  * Don't write EVTYPER.TC if TH is 0. Doesn't have any functional
    effect but it might be a bit easier to understand the code.
  * Expand the format field #define names

Changes since v4:

  * Rebase onto v6.7-rc1, it no longer depends on kvmarm/next
  * Remove change that moved ARMV8_PMU_EVTYPE_MASK to the asm files.
    This actually depended on those files being included in a certain
    order with arm_pmuv3.h to avoid circular includes. Now the
    definition is done programmatically in arm_pmuv3.c instead.

Changes since v3:

  * Drop #include changes to KVM source files because since
    commit bc512d6a9b92 ("KVM: arm64: Make PMEVTYPER<n>_EL0.NSH RES0 if
    EL2 isn't advertised"), KVM doesn't use ARMV8_PMU_EVTYPE_MASK
    anymore

Changes since v2:

  * Split threshold_control attribute into two, threshold_compare and
    threshold_count so that it's easier to use
  * Add some notes to the first commit message and the cover letter
    about the behavior in KVM
  * Update the docs commit with regards to the split attribute
 
Changes since v1:

  * Fix build on aarch32 by disabling FEAT_PMUv3_TH and splitting event
    type mask between the platforms
  * Change armv8pmu_write_evtype() to take unsigned long instead of u64
    so it isn't unnecessarily wide on aarch32
  * Add UL suffix to aarch64 event type mask definition

----

FEAT_PMUv3_TH (Armv8.8) is a new feature that allows conditional
counting of PMU events depending on how much the event increments on
a single cycle. Two new config fields for perf_event_open have been
added, and a PMU cap file for reading the max_threshold. See the second
commit message and the docs in the last commit for more details.

The feature is not currently supported on KVM guests, and PMMIR is set
to read as zero, so it's not advertised as available. But it can be
added at a later time. Writes to PMEVTYPER.TC and TH from guests are
already RES0.

The change has been validated on the Arm FVP model:

  # Zero values, works as expected (as before).
  $ perf stat -e dtlb_walk/threshold=0,threshold_compare=0/ -- true

    5962      dtlb_walk/threshold=0,threshold_compare=0/

  # Threshold >= 255 causes count to be 0 because dtlb_walk doesn't
  # increase by more than 1 per cycle.
  $ perf stat -e dtlb_walk/threshold=255,threshold_compare=2/ -- true

    0      dtlb_walk/threshold=255,threshold_compare=2/
  
  # Keeping comparison as >= but lowering the threshold to 1 makes the
  # count return.
  $ perf stat -e dtlb_walk/threshold=1,threshold_compare=2/ -- true

    6329      dtlb_walk/threshold=1,threshold_compare=2/

James Clark (11):
  arm: perf: Remove inlines from arm_pmuv3.c
  arm: perf/kvm: Use GENMASK for ARMV8_PMU_PMCR_N
  arm: perf: Use GENMASK for PMMIR fields
  arm: perf: Convert remaining fields to use GENMASK
  arm64: perf: Include threshold control fields in PMEVTYPER mask
  arm: pmu: Share user ABI format mechanism with SPE
  perf/arm_dmc620: Remove duplicate format attribute #defines
  KVM: selftests: aarch64: Update tools copy of arm_pmuv3.h
  arm: pmu: Move error message and -EOPNOTSUPP to individual PMUs
  arm64: perf: Add support for event counting threshold
  Documentation: arm64: Document the PMU event counting threshold
    feature

 Documentation/arch/arm64/perf.rst             |  72 +++++++
 arch/arm/kernel/perf_event_v7.c               |   6 +-
 arch/arm64/kvm/pmu-emul.c                     |   8 +-
 arch/arm64/kvm/sys_regs.c                     |   4 +-
 drivers/perf/apple_m1_cpu_pmu.c               |   6 +-
 drivers/perf/arm_dmc620_pmu.c                 |  22 +--
 drivers/perf/arm_pmu.c                        |  11 +-
 drivers/perf/arm_pmuv3.c                      | 175 ++++++++++++++----
 drivers/perf/arm_spe_pmu.c                    |  22 ---
 include/linux/perf/arm_pmu.h                  |  22 +++
 include/linux/perf/arm_pmuv3.h                |  34 ++--
 tools/include/perf/arm_pmuv3.h                |  43 +++--
 .../kvm/aarch64/vpmu_counter_access.c         |   5 +-
 13 files changed, 296 insertions(+), 134 deletions(-)

-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:14 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:14 +0000
Subject: [PATCH v7 02/11] arm: perf/kvm: Use GENMASK for ARMV8_PMU_PMCR_N
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-3-james.clark@arm.com>

This is so that FIELD_GET and FIELD_PREP can be used and that the fields
are in a consistent format to arm64/tools/sysreg

Signed-off-by: James Clark <james.clark at arm.com>
---
 arch/arm64/kvm/pmu-emul.c      | 8 +++-----
 arch/arm64/kvm/sys_regs.c      | 4 ++--
 drivers/perf/arm_pmuv3.c       | 4 ++--
 include/linux/perf/arm_pmuv3.h | 3 +--
 4 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index fe99b3dab6ce..3d9467ff73bc 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -267,9 +267,8 @@ void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu)
 
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
-	u64 val = kvm_vcpu_read_pmcr(vcpu) >> ARMV8_PMU_PMCR_N_SHIFT;
+	u64 val = FIELD_GET(ARMV8_PMU_PMCR_N, kvm_vcpu_read_pmcr(vcpu));
 
-	val &= ARMV8_PMU_PMCR_N_MASK;
 	if (val == 0)
 		return BIT(ARMV8_PMU_CYCLE_IDX);
 	else
@@ -1136,8 +1135,7 @@ u8 kvm_arm_pmu_get_pmuver_limit(void)
  */
 u64 kvm_vcpu_read_pmcr(struct kvm_vcpu *vcpu)
 {
-	u64 pmcr = __vcpu_sys_reg(vcpu, PMCR_EL0) &
-			~(ARMV8_PMU_PMCR_N_MASK << ARMV8_PMU_PMCR_N_SHIFT);
+	u64 pmcr = __vcpu_sys_reg(vcpu, PMCR_EL0);
 
-	return pmcr | ((u64)vcpu->kvm->arch.pmcr_n << ARMV8_PMU_PMCR_N_SHIFT);
+	return u64_replace_bits(pmcr, vcpu->kvm->arch.pmcr_n, ARMV8_PMU_PMCR_N);
 }
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4735e1b37fb3..ff45d688bd7d 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -877,7 +877,7 @@ static bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
 	u64 pmcr, val;
 
 	pmcr = kvm_vcpu_read_pmcr(vcpu);
-	val = (pmcr >> ARMV8_PMU_PMCR_N_SHIFT) & ARMV8_PMU_PMCR_N_MASK;
+	val = FIELD_GET(ARMV8_PMU_PMCR_N, pmcr);
 	if (idx >= val && idx != ARMV8_PMU_CYCLE_IDX) {
 		kvm_inject_undefined(vcpu);
 		return false;
@@ -1143,7 +1143,7 @@ static int get_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r,
 static int set_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r,
 		    u64 val)
 {
-	u8 new_n = (val >> ARMV8_PMU_PMCR_N_SHIFT) & ARMV8_PMU_PMCR_N_MASK;
+	u8 new_n = FIELD_GET(ARMV8_PMU_PMCR_N, val);
 	struct kvm *kvm = vcpu->kvm;
 
 	mutex_lock(&kvm->arch.config_lock);
diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 9184a75435e2..e424de5dd44f 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -15,6 +15,7 @@
 #include <clocksource/arm_arch_timer.h>
 
 #include <linux/acpi.h>
+#include <linux/bitfield.h>
 #include <linux/clocksource.h>
 #include <linux/of.h>
 #include <linux/perf/arm_pmu.h>
@@ -1107,8 +1108,7 @@ static void __armv8pmu_probe_pmu(void *info)
 	probe->present = true;
 
 	/* Read the nb of CNTx counters supported from PMNC */
-	cpu_pmu->num_events = (armv8pmu_pmcr_read() >> ARMV8_PMU_PMCR_N_SHIFT)
-		& ARMV8_PMU_PMCR_N_MASK;
+	cpu_pmu->num_events = FIELD_GET(ARMV8_PMU_PMCR_N, armv8pmu_pmcr_read());
 
 	/* Add the CPU cycles counter */
 	cpu_pmu->num_events += 1;
diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
index 9c226adf938a..ed62bd75cec7 100644
--- a/include/linux/perf/arm_pmuv3.h
+++ b/include/linux/perf/arm_pmuv3.h
@@ -215,8 +215,7 @@
 #define ARMV8_PMU_PMCR_DP	(1 << 5) /* Disable CCNT if non-invasive debug*/
 #define ARMV8_PMU_PMCR_LC	(1 << 6) /* Overflow on 64 bit cycle counter */
 #define ARMV8_PMU_PMCR_LP	(1 << 7) /* Long event counter enable */
-#define ARMV8_PMU_PMCR_N_SHIFT	11  /* Number of counters supported */
-#define ARMV8_PMU_PMCR_N_MASK	0x1f
+#define ARMV8_PMU_PMCR_N	GENMASK(15, 11) /* Number of counters supported */
 #define ARMV8_PMU_PMCR_MASK	0xff    /* Mask for writable bits */
 
 /*
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:13 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:13 +0000
Subject: [PATCH v7 01/11] arm: perf: Remove inlines from arm_pmuv3.c
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-2-james.clark@arm.com>

These are all static and in one compilation unit so the inline has no
effect on the binary. Except if FTRACE is enabled, then 3 functions
which were already not inlined now get the nops added which allows them
to be traced.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/perf/arm_pmuv3.c | 46 ++++++++++++++++++++--------------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 6ca7be05229c..9184a75435e2 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -300,12 +300,12 @@ PMU_FORMAT_ATTR(rdpmc, "config1:1");
 
 static int sysctl_perf_user_access __read_mostly;
 
-static inline bool armv8pmu_event_is_64bit(struct perf_event *event)
+static bool armv8pmu_event_is_64bit(struct perf_event *event)
 {
 	return event->attr.config1 & 0x1;
 }
 
-static inline bool armv8pmu_event_want_user_access(struct perf_event *event)
+static bool armv8pmu_event_want_user_access(struct perf_event *event)
 {
 	return event->attr.config1 & 0x2;
 }
@@ -397,7 +397,7 @@ static bool armv8pmu_has_long_event(struct arm_pmu *cpu_pmu)
 	return (IS_ENABLED(CONFIG_ARM64) && is_pmuv3p5(cpu_pmu->pmuver));
 }
 
-static inline bool armv8pmu_event_has_user_read(struct perf_event *event)
+static bool armv8pmu_event_has_user_read(struct perf_event *event)
 {
 	return event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT;
 }
@@ -407,7 +407,7 @@ static inline bool armv8pmu_event_has_user_read(struct perf_event *event)
  * except when we have allocated the 64bit cycle counter (for CPU
  * cycles event) or when user space counter access is enabled.
  */
-static inline bool armv8pmu_event_is_chained(struct perf_event *event)
+static bool armv8pmu_event_is_chained(struct perf_event *event)
 {
 	int idx = event->hw.idx;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
@@ -428,36 +428,36 @@ static inline bool armv8pmu_event_is_chained(struct perf_event *event)
 #define	ARMV8_IDX_TO_COUNTER(x)	\
 	(((x) - ARMV8_IDX_COUNTER0) & ARMV8_PMU_COUNTER_MASK)
 
-static inline u64 armv8pmu_pmcr_read(void)
+static u64 armv8pmu_pmcr_read(void)
 {
 	return read_pmcr();
 }
 
-static inline void armv8pmu_pmcr_write(u64 val)
+static void armv8pmu_pmcr_write(u64 val)
 {
 	val &= ARMV8_PMU_PMCR_MASK;
 	isb();
 	write_pmcr(val);
 }
 
-static inline int armv8pmu_has_overflowed(u32 pmovsr)
+static int armv8pmu_has_overflowed(u32 pmovsr)
 {
 	return pmovsr & ARMV8_PMU_OVERFLOWED_MASK;
 }
 
-static inline int armv8pmu_counter_has_overflowed(u32 pmnc, int idx)
+static int armv8pmu_counter_has_overflowed(u32 pmnc, int idx)
 {
 	return pmnc & BIT(ARMV8_IDX_TO_COUNTER(idx));
 }
 
-static inline u64 armv8pmu_read_evcntr(int idx)
+static u64 armv8pmu_read_evcntr(int idx)
 {
 	u32 counter = ARMV8_IDX_TO_COUNTER(idx);
 
 	return read_pmevcntrn(counter);
 }
 
-static inline u64 armv8pmu_read_hw_counter(struct perf_event *event)
+static u64 armv8pmu_read_hw_counter(struct perf_event *event)
 {
 	int idx = event->hw.idx;
 	u64 val = armv8pmu_read_evcntr(idx);
@@ -519,14 +519,14 @@ static u64 armv8pmu_read_counter(struct perf_event *event)
 	return  armv8pmu_unbias_long_counter(event, value);
 }
 
-static inline void armv8pmu_write_evcntr(int idx, u64 value)
+static void armv8pmu_write_evcntr(int idx, u64 value)
 {
 	u32 counter = ARMV8_IDX_TO_COUNTER(idx);
 
 	write_pmevcntrn(counter, value);
 }
 
-static inline void armv8pmu_write_hw_counter(struct perf_event *event,
+static void armv8pmu_write_hw_counter(struct perf_event *event,
 					     u64 value)
 {
 	int idx = event->hw.idx;
@@ -552,7 +552,7 @@ static void armv8pmu_write_counter(struct perf_event *event, u64 value)
 		armv8pmu_write_hw_counter(event, value);
 }
 
-static inline void armv8pmu_write_evtype(int idx, u32 val)
+static void armv8pmu_write_evtype(int idx, u32 val)
 {
 	u32 counter = ARMV8_IDX_TO_COUNTER(idx);
 
@@ -560,7 +560,7 @@ static inline void armv8pmu_write_evtype(int idx, u32 val)
 	write_pmevtypern(counter, val);
 }
 
-static inline void armv8pmu_write_event_type(struct perf_event *event)
+static void armv8pmu_write_event_type(struct perf_event *event)
 {
 	struct hw_perf_event *hwc = &event->hw;
 	int idx = hwc->idx;
@@ -594,7 +594,7 @@ static u32 armv8pmu_event_cnten_mask(struct perf_event *event)
 	return mask;
 }
 
-static inline void armv8pmu_enable_counter(u32 mask)
+static void armv8pmu_enable_counter(u32 mask)
 {
 	/*
 	 * Make sure event configuration register writes are visible before we
@@ -604,7 +604,7 @@ static inline void armv8pmu_enable_counter(u32 mask)
 	write_pmcntenset(mask);
 }
 
-static inline void armv8pmu_enable_event_counter(struct perf_event *event)
+static void armv8pmu_enable_event_counter(struct perf_event *event)
 {
 	struct perf_event_attr *attr = &event->attr;
 	u32 mask = armv8pmu_event_cnten_mask(event);
@@ -616,7 +616,7 @@ static inline void armv8pmu_enable_event_counter(struct perf_event *event)
 		armv8pmu_enable_counter(mask);
 }
 
-static inline void armv8pmu_disable_counter(u32 mask)
+static void armv8pmu_disable_counter(u32 mask)
 {
 	write_pmcntenclr(mask);
 	/*
@@ -626,7 +626,7 @@ static inline void armv8pmu_disable_counter(u32 mask)
 	isb();
 }
 
-static inline void armv8pmu_disable_event_counter(struct perf_event *event)
+static void armv8pmu_disable_event_counter(struct perf_event *event)
 {
 	struct perf_event_attr *attr = &event->attr;
 	u32 mask = armv8pmu_event_cnten_mask(event);
@@ -638,18 +638,18 @@ static inline void armv8pmu_disable_event_counter(struct perf_event *event)
 		armv8pmu_disable_counter(mask);
 }
 
-static inline void armv8pmu_enable_intens(u32 mask)
+static void armv8pmu_enable_intens(u32 mask)
 {
 	write_pmintenset(mask);
 }
 
-static inline void armv8pmu_enable_event_irq(struct perf_event *event)
+static void armv8pmu_enable_event_irq(struct perf_event *event)
 {
 	u32 counter = ARMV8_IDX_TO_COUNTER(event->hw.idx);
 	armv8pmu_enable_intens(BIT(counter));
 }
 
-static inline void armv8pmu_disable_intens(u32 mask)
+static void armv8pmu_disable_intens(u32 mask)
 {
 	write_pmintenclr(mask);
 	isb();
@@ -658,13 +658,13 @@ static inline void armv8pmu_disable_intens(u32 mask)
 	isb();
 }
 
-static inline void armv8pmu_disable_event_irq(struct perf_event *event)
+static void armv8pmu_disable_event_irq(struct perf_event *event)
 {
 	u32 counter = ARMV8_IDX_TO_COUNTER(event->hw.idx);
 	armv8pmu_disable_intens(BIT(counter));
 }
 
-static inline u32 armv8pmu_getreset_flags(void)
+static u32 armv8pmu_getreset_flags(void)
 {
 	u32 value;
 
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:15 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:15 +0000
Subject: [PATCH v7 03/11] arm: perf: Use GENMASK for PMMIR fields
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-4-james.clark@arm.com>

This is so that FIELD_GET and FIELD_PREP can be used and that the fields
are in a consistent format to arm64/tools/sysreg

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/perf/arm_pmuv3.c       | 8 +++-----
 include/linux/perf/arm_pmuv3.h | 9 +++------
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index e424de5dd44f..7b2c1d03464a 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -328,7 +328,7 @@ static ssize_t slots_show(struct device *dev, struct device_attribute *attr,
 {
 	struct pmu *pmu = dev_get_drvdata(dev);
 	struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
-	u32 slots = cpu_pmu->reg_pmmir & ARMV8_PMU_SLOTS_MASK;
+	u32 slots = FIELD_GET(ARMV8_PMU_SLOTS, cpu_pmu->reg_pmmir);
 
 	return sysfs_emit(page, "0x%08x\n", slots);
 }
@@ -340,8 +340,7 @@ static ssize_t bus_slots_show(struct device *dev, struct device_attribute *attr,
 {
 	struct pmu *pmu = dev_get_drvdata(dev);
 	struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
-	u32 bus_slots = (cpu_pmu->reg_pmmir >> ARMV8_PMU_BUS_SLOTS_SHIFT)
-			& ARMV8_PMU_BUS_SLOTS_MASK;
+	u32 bus_slots = FIELD_GET(ARMV8_PMU_BUS_SLOTS, cpu_pmu->reg_pmmir);
 
 	return sysfs_emit(page, "0x%08x\n", bus_slots);
 }
@@ -353,8 +352,7 @@ static ssize_t bus_width_show(struct device *dev, struct device_attribute *attr,
 {
 	struct pmu *pmu = dev_get_drvdata(dev);
 	struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
-	u32 bus_width = (cpu_pmu->reg_pmmir >> ARMV8_PMU_BUS_WIDTH_SHIFT)
-			& ARMV8_PMU_BUS_WIDTH_MASK;
+	u32 bus_width = FIELD_GET(ARMV8_PMU_BUS_WIDTH, cpu_pmu->reg_pmmir);
 	u32 val = 0;
 
 	/* Encoded as Log2(number of bytes), plus one */
diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
index ed62bd75cec7..1bc7678c10d4 100644
--- a/include/linux/perf/arm_pmuv3.h
+++ b/include/linux/perf/arm_pmuv3.h
@@ -250,12 +250,9 @@
 #define ARMV8_PMU_USERENR_ER	(1 << 3) /* Event counter can be read at EL0 */
 
 /* PMMIR_EL1.SLOTS mask */
-#define ARMV8_PMU_SLOTS_MASK	0xff
-
-#define ARMV8_PMU_BUS_SLOTS_SHIFT 8
-#define ARMV8_PMU_BUS_SLOTS_MASK 0xff
-#define ARMV8_PMU_BUS_WIDTH_SHIFT 16
-#define ARMV8_PMU_BUS_WIDTH_MASK 0xf
+#define ARMV8_PMU_SLOTS		GENMASK(7, 0)
+#define ARMV8_PMU_BUS_SLOTS	GENMASK(15, 8)
+#define ARMV8_PMU_BUS_WIDTH	GENMASK(19, 16)
 
 /*
  * This code is really good
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:16 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:16 +0000
Subject: [PATCH v7 04/11] arm: perf: Convert remaining fields to use GENMASK
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-5-james.clark@arm.com>

Convert the remaining fields to use either GENMASK or be built from
other fields. These all already started at bit 0 so don't need a code
change for the lack of _SHIFT.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/perf/arm_pmuv3.c       |  2 +-
 include/linux/perf/arm_pmuv3.h | 18 +++++++++++++-----
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 7b2c1d03464a..fbdf3cab8e66 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -671,7 +671,7 @@ static u32 armv8pmu_getreset_flags(void)
 	value = read_pmovsclr();
 
 	/* Write to clear flags */
-	value &= ARMV8_PMU_OVSR_MASK;
+	value &= ARMV8_PMU_OVERFLOWED_MASK;
 	write_pmovsclr(value);
 
 	return value;
diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
index 1bc7678c10d4..daa63542242d 100644
--- a/include/linux/perf/arm_pmuv3.h
+++ b/include/linux/perf/arm_pmuv3.h
@@ -216,19 +216,25 @@
 #define ARMV8_PMU_PMCR_LC	(1 << 6) /* Overflow on 64 bit cycle counter */
 #define ARMV8_PMU_PMCR_LP	(1 << 7) /* Long event counter enable */
 #define ARMV8_PMU_PMCR_N	GENMASK(15, 11) /* Number of counters supported */
-#define ARMV8_PMU_PMCR_MASK	0xff    /* Mask for writable bits */
+/* Mask for writable bits */
+#define ARMV8_PMU_PMCR_MASK	(ARMV8_PMU_PMCR_E | ARMV8_PMU_PMCR_P | \
+				 ARMV8_PMU_PMCR_C | ARMV8_PMU_PMCR_D | \
+				 ARMV8_PMU_PMCR_X | ARMV8_PMU_PMCR_DP | \
+				 ARMV8_PMU_PMCR_LC | ARMV8_PMU_PMCR_LP)
 
 /*
  * PMOVSR: counters overflow flag status reg
  */
-#define ARMV8_PMU_OVSR_MASK		0xffffffff	/* Mask for writable bits */
-#define ARMV8_PMU_OVERFLOWED_MASK	ARMV8_PMU_OVSR_MASK
+#define ARMV8_PMU_OVSR_P		GENMASK(30, 0)
+#define ARMV8_PMU_OVSR_C		BIT(31)
+/* Mask for writable bits is both P and C fields */
+#define ARMV8_PMU_OVERFLOWED_MASK	(ARMV8_PMU_OVSR_P | ARMV8_PMU_OVSR_C)
 
 /*
  * PMXEVTYPER: Event selection reg
  */
 #define ARMV8_PMU_EVTYPE_MASK	0xc800ffff	/* Mask for writable bits */
-#define ARMV8_PMU_EVTYPE_EVENT	0xffff		/* Mask for EVENT bits */
+#define ARMV8_PMU_EVTYPE_EVENT	GENMASK(15, 0)	/* Mask for EVENT bits */
 
 /*
  * Event filters for PMUv3
@@ -243,11 +249,13 @@
 /*
  * PMUSERENR: user enable reg
  */
-#define ARMV8_PMU_USERENR_MASK	0xf		/* Mask for writable bits */
 #define ARMV8_PMU_USERENR_EN	(1 << 0) /* PMU regs can be accessed at EL0 */
 #define ARMV8_PMU_USERENR_SW	(1 << 1) /* PMSWINC can be written at EL0 */
 #define ARMV8_PMU_USERENR_CR	(1 << 2) /* Cycle counter can be read at EL0 */
 #define ARMV8_PMU_USERENR_ER	(1 << 3) /* Event counter can be read at EL0 */
+/* Mask for writable bits */
+#define ARMV8_PMU_USERENR_MASK	(ARMV8_PMU_USERENR_EN | ARMV8_PMU_USERENR_SW | \
+				 ARMV8_PMU_USERENR_CR | ARMV8_PMU_USERENR_ER)
 
 /* PMMIR_EL1.SLOTS mask */
 #define ARMV8_PMU_SLOTS		GENMASK(7, 0)
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:17 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:17 +0000
Subject: [PATCH v7 05/11] arm64: perf: Include threshold control fields in PMEVTYPER mask
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-6-james.clark@arm.com>

FEAT_PMUv3_TH (Armv8.8) adds two new fields to PMEVTYPER, so include
them in the mask. These aren't writable on 32 bit kernels as they are in
the high part of the register, so only include them for arm64.

It would be difficult to do this statically in the asm header files for
each platform without resulting in circular includes or #ifdefs inline
in the code. For that reason the ARMV8_PMU_EVTYPE_MASK definition has
been removed and the mask is constructed programmatically.

Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>
Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/perf/arm_pmuv3.c       | 9 ++++++++-
 include/linux/perf/arm_pmuv3.h | 3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index fbdf3cab8e66..16ef8448afc0 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -554,8 +554,15 @@ static void armv8pmu_write_counter(struct perf_event *event, u64 value)
 static void armv8pmu_write_evtype(int idx, u32 val)
 {
 	u32 counter = ARMV8_IDX_TO_COUNTER(idx);
+	unsigned long mask = ARMV8_PMU_EVTYPE_EVENT |
+			     ARMV8_PMU_INCLUDE_EL2 |
+			     ARMV8_PMU_EXCLUDE_EL0 |
+			     ARMV8_PMU_EXCLUDE_EL1;
 
-	val &= ARMV8_PMU_EVTYPE_MASK;
+	if (IS_ENABLED(CONFIG_ARM64))
+		mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
+
+	val &= mask;
 	write_pmevtypern(counter, val);
 }
 
diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
index daa63542242d..91957b3468e9 100644
--- a/include/linux/perf/arm_pmuv3.h
+++ b/include/linux/perf/arm_pmuv3.h
@@ -233,8 +233,9 @@
 /*
  * PMXEVTYPER: Event selection reg
  */
-#define ARMV8_PMU_EVTYPE_MASK	0xc800ffff	/* Mask for writable bits */
 #define ARMV8_PMU_EVTYPE_EVENT	GENMASK(15, 0)	/* Mask for EVENT bits */
+#define ARMV8_PMU_EVTYPE_TH	GENMASK(43, 32)
+#define ARMV8_PMU_EVTYPE_TC	GENMASK(63, 61)
 
 /*
  * Event filters for PMUv3
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:18 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:18 +0000
Subject: [PATCH v7 06/11] arm: pmu: Share user ABI format mechanism with SPE
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-7-james.clark@arm.com>

This mechanism makes it much easier to define and read new attributes
so move it to the arm_pmu.h header so that it can be shared. At the same
time update the existing format attributes to use it.

GENMASK has to be changed to GENMASK_ULL because the config fields are
64 bits even on arm32 where this will also be used now.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/perf/arm_pmuv3.c     | 21 ++++++++++++++++-----
 drivers/perf/arm_spe_pmu.c   | 22 ----------------------
 include/linux/perf/arm_pmu.h | 22 ++++++++++++++++++++++
 3 files changed, 38 insertions(+), 27 deletions(-)

diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 16ef8448afc0..84b15c0892d9 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -295,20 +295,31 @@ static const struct attribute_group armv8_pmuv3_events_attr_group = {
 	.is_visible = armv8pmu_event_attr_is_visible,
 };
 
-PMU_FORMAT_ATTR(event, "config:0-15");
-PMU_FORMAT_ATTR(long, "config1:0");
-PMU_FORMAT_ATTR(rdpmc, "config1:1");
+/* User ABI */
+#define ATTR_CFG_FLD_event_CFG		config
+#define ATTR_CFG_FLD_event_LO		0
+#define ATTR_CFG_FLD_event_HI		15
+#define ATTR_CFG_FLD_long_CFG		config1
+#define ATTR_CFG_FLD_long_LO		0
+#define ATTR_CFG_FLD_long_HI		0
+#define ATTR_CFG_FLD_rdpmc_CFG		config1
+#define ATTR_CFG_FLD_rdpmc_LO		1
+#define ATTR_CFG_FLD_rdpmc_HI		1
+
+GEN_PMU_FORMAT_ATTR(event);
+GEN_PMU_FORMAT_ATTR(long);
+GEN_PMU_FORMAT_ATTR(rdpmc);
 
 static int sysctl_perf_user_access __read_mostly;
 
 static bool armv8pmu_event_is_64bit(struct perf_event *event)
 {
-	return event->attr.config1 & 0x1;
+	return ATTR_CFG_GET_FLD(&event->attr, long);
 }
 
 static bool armv8pmu_event_want_user_access(struct perf_event *event)
 {
-	return event->attr.config1 & 0x2;
+	return ATTR_CFG_GET_FLD(&event->attr, rdpmc);
 }
 
 static struct attribute *armv8_pmuv3_format_attrs[] = {
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index d2b0cbf0e0c4..b622d75d8c9e 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -206,28 +206,6 @@ static const struct attribute_group arm_spe_pmu_cap_group = {
 #define ATTR_CFG_FLD_inv_event_filter_LO	0
 #define ATTR_CFG_FLD_inv_event_filter_HI	63
 
-/* Why does everything I do descend into this? */
-#define __GEN_PMU_FORMAT_ATTR(cfg, lo, hi)				\
-	(lo) == (hi) ? #cfg ":" #lo "\n" : #cfg ":" #lo "-" #hi
-
-#define _GEN_PMU_FORMAT_ATTR(cfg, lo, hi)				\
-	__GEN_PMU_FORMAT_ATTR(cfg, lo, hi)
-
-#define GEN_PMU_FORMAT_ATTR(name)					\
-	PMU_FORMAT_ATTR(name,						\
-	_GEN_PMU_FORMAT_ATTR(ATTR_CFG_FLD_##name##_CFG,			\
-			     ATTR_CFG_FLD_##name##_LO,			\
-			     ATTR_CFG_FLD_##name##_HI))
-
-#define _ATTR_CFG_GET_FLD(attr, cfg, lo, hi)				\
-	((((attr)->cfg) >> lo) & GENMASK(hi - lo, 0))
-
-#define ATTR_CFG_GET_FLD(attr, name)					\
-	_ATTR_CFG_GET_FLD(attr,						\
-			  ATTR_CFG_FLD_##name##_CFG,			\
-			  ATTR_CFG_FLD_##name##_LO,			\
-			  ATTR_CFG_FLD_##name##_HI)
-
 GEN_PMU_FORMAT_ATTR(ts_enable);
 GEN_PMU_FORMAT_ATTR(pa_enable);
 GEN_PMU_FORMAT_ATTR(pct_enable);
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 143fbc10ecfe..337f01674b38 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -189,4 +189,26 @@ void armpmu_free_irq(int irq, int cpu);
 #define ARMV8_SPE_PDEV_NAME "arm,spe-v1"
 #define ARMV8_TRBE_PDEV_NAME "arm,trbe"
 
+/* Why does everything I do descend into this? */
+#define __GEN_PMU_FORMAT_ATTR(cfg, lo, hi)				\
+	(lo) == (hi) ? #cfg ":" #lo "\n" : #cfg ":" #lo "-" #hi
+
+#define _GEN_PMU_FORMAT_ATTR(cfg, lo, hi)				\
+	__GEN_PMU_FORMAT_ATTR(cfg, lo, hi)
+
+#define GEN_PMU_FORMAT_ATTR(name)					\
+	PMU_FORMAT_ATTR(name,						\
+	_GEN_PMU_FORMAT_ATTR(ATTR_CFG_FLD_##name##_CFG,			\
+			     ATTR_CFG_FLD_##name##_LO,			\
+			     ATTR_CFG_FLD_##name##_HI))
+
+#define _ATTR_CFG_GET_FLD(attr, cfg, lo, hi)				\
+	((((attr)->cfg) >> lo) & GENMASK_ULL(hi - lo, 0))
+
+#define ATTR_CFG_GET_FLD(attr, name)					\
+	_ATTR_CFG_GET_FLD(attr,						\
+			  ATTR_CFG_FLD_##name##_CFG,			\
+			  ATTR_CFG_FLD_##name##_LO,			\
+			  ATTR_CFG_FLD_##name##_HI)
+
 #endif /* __ARM_PMU_H__ */
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:19 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:19 +0000
Subject: [PATCH v7 07/11] perf/arm_dmc620: Remove duplicate format attribute #defines
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-8-james.clark@arm.com>

These were copied from the SPE driver, but now they're in the arm_pmu.h
header so delete them and use the header instead.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/perf/arm_dmc620_pmu.c | 22 +---------------------
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/drivers/perf/arm_dmc620_pmu.c b/drivers/perf/arm_dmc620_pmu.c
index 30cea6859574..9de9dc8db8db 100644
--- a/drivers/perf/arm_dmc620_pmu.c
+++ b/drivers/perf/arm_dmc620_pmu.c
@@ -23,6 +23,7 @@
 #include <linux/module.h>
 #include <linux/mutex.h>
 #include <linux/perf_event.h>
+#include <linux/perf/arm_pmu.h>
 #include <linux/platform_device.h>
 #include <linux/printk.h>
 #include <linux/rculist.h>
@@ -189,27 +190,6 @@ static const struct attribute_group dmc620_pmu_events_attr_group = {
 #define ATTR_CFG_FLD_clkdiv2_LO		9
 #define ATTR_CFG_FLD_clkdiv2_HI		9
 
-#define __GEN_PMU_FORMAT_ATTR(cfg, lo, hi)			\
-	(lo) == (hi) ? #cfg ":" #lo "\n" : #cfg ":" #lo "-" #hi
-
-#define _GEN_PMU_FORMAT_ATTR(cfg, lo, hi)			\
-	__GEN_PMU_FORMAT_ATTR(cfg, lo, hi)
-
-#define GEN_PMU_FORMAT_ATTR(name)				\
-	PMU_FORMAT_ATTR(name,					\
-	_GEN_PMU_FORMAT_ATTR(ATTR_CFG_FLD_##name##_CFG,		\
-			     ATTR_CFG_FLD_##name##_LO,		\
-			     ATTR_CFG_FLD_##name##_HI))
-
-#define _ATTR_CFG_GET_FLD(attr, cfg, lo, hi)			\
-	((((attr)->cfg) >> lo) & GENMASK_ULL(hi - lo, 0))
-
-#define ATTR_CFG_GET_FLD(attr, name)				\
-	_ATTR_CFG_GET_FLD(attr,					\
-			  ATTR_CFG_FLD_##name##_CFG,		\
-			  ATTR_CFG_FLD_##name##_LO,		\
-			  ATTR_CFG_FLD_##name##_HI)
-
 GEN_PMU_FORMAT_ATTR(mask);
 GEN_PMU_FORMAT_ATTR(match);
 GEN_PMU_FORMAT_ATTR(invert);
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:20 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:20 +0000
Subject: [PATCH v7 08/11] KVM: selftests: aarch64: Update tools copy of arm_pmuv3.h
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-9-james.clark@arm.com>

Now that ARMV8_PMU_PMCR_N is made with GENMASK, update usages to treat
it as a pre-shifted mask.

Signed-off-by: James Clark <james.clark at arm.com>
---
 tools/include/perf/arm_pmuv3.h                | 43 +++++++++++--------
 .../kvm/aarch64/vpmu_counter_access.c         |  5 +--
 2 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/tools/include/perf/arm_pmuv3.h b/tools/include/perf/arm_pmuv3.h
index e822d49fb5b8..1e397d55384e 100644
--- a/tools/include/perf/arm_pmuv3.h
+++ b/tools/include/perf/arm_pmuv3.h
@@ -218,45 +218,54 @@
 #define ARMV8_PMU_PMCR_DP	(1 << 5) /* Disable CCNT if non-invasive debug*/
 #define ARMV8_PMU_PMCR_LC	(1 << 6) /* Overflow on 64 bit cycle counter */
 #define ARMV8_PMU_PMCR_LP	(1 << 7) /* Long event counter enable */
-#define ARMV8_PMU_PMCR_N_SHIFT	11  /* Number of counters supported */
-#define ARMV8_PMU_PMCR_N_MASK	0x1f
-#define ARMV8_PMU_PMCR_MASK	0xff    /* Mask for writable bits */
+#define ARMV8_PMU_PMCR_N	GENMASK(15, 11) /* Number of counters supported */
+/* Mask for writable bits */
+#define ARMV8_PMU_PMCR_MASK	(ARMV8_PMU_PMCR_E | ARMV8_PMU_PMCR_P | \
+				 ARMV8_PMU_PMCR_C | ARMV8_PMU_PMCR_D | \
+				 ARMV8_PMU_PMCR_X | ARMV8_PMU_PMCR_DP | \
+				 ARMV8_PMU_PMCR_LC | ARMV8_PMU_PMCR_LP)
 
 /*
  * PMOVSR: counters overflow flag status reg
  */
-#define ARMV8_PMU_OVSR_MASK		0xffffffff	/* Mask for writable bits */
-#define ARMV8_PMU_OVERFLOWED_MASK	ARMV8_PMU_OVSR_MASK
+#define ARMV8_PMU_OVSR_P		GENMASK(30, 0)
+#define ARMV8_PMU_OVSR_C		BIT(31)
+/* Mask for writable bits is both P and C fields */
+#define ARMV8_PMU_OVERFLOWED_MASK	(ARMV8_PMU_OVSR_P | ARMV8_PMU_OVSR_C)
 
 /*
  * PMXEVTYPER: Event selection reg
  */
-#define ARMV8_PMU_EVTYPE_MASK	0xc800ffff	/* Mask for writable bits */
-#define ARMV8_PMU_EVTYPE_EVENT	0xffff		/* Mask for EVENT bits */
+#define ARMV8_PMU_EVTYPE_EVENT	GENMASK(15, 0)	/* Mask for EVENT bits */
+#define ARMV8_PMU_EVTYPE_TH	GENMASK(43, 32)
+#define ARMV8_PMU_EVTYPE_TC	GENMASK(63, 61)
 
 /*
  * Event filters for PMUv3
  */
-#define ARMV8_PMU_EXCLUDE_EL1	(1U << 31)
-#define ARMV8_PMU_EXCLUDE_EL0	(1U << 30)
-#define ARMV8_PMU_INCLUDE_EL2	(1U << 27)
+#define ARMV8_PMU_EXCLUDE_EL1		(1U << 31)
+#define ARMV8_PMU_EXCLUDE_EL0		(1U << 30)
+#define ARMV8_PMU_EXCLUDE_NS_EL1	(1U << 29)
+#define ARMV8_PMU_EXCLUDE_NS_EL0	(1U << 28)
+#define ARMV8_PMU_INCLUDE_EL2		(1U << 27)
+#define ARMV8_PMU_EXCLUDE_EL3		(1U << 26)
 
 /*
  * PMUSERENR: user enable reg
  */
-#define ARMV8_PMU_USERENR_MASK	0xf		/* Mask for writable bits */
 #define ARMV8_PMU_USERENR_EN	(1 << 0) /* PMU regs can be accessed at EL0 */
 #define ARMV8_PMU_USERENR_SW	(1 << 1) /* PMSWINC can be written at EL0 */
 #define ARMV8_PMU_USERENR_CR	(1 << 2) /* Cycle counter can be read at EL0 */
 #define ARMV8_PMU_USERENR_ER	(1 << 3) /* Event counter can be read at EL0 */
+/* Mask for writable bits */
+#define ARMV8_PMU_USERENR_MASK	(ARMV8_PMU_USERENR_EN | ARMV8_PMU_USERENR_SW | \
+				 ARMV8_PMU_USERENR_CR | ARMV8_PMU_USERENR_ER)
 
 /* PMMIR_EL1.SLOTS mask */
-#define ARMV8_PMU_SLOTS_MASK	0xff
-
-#define ARMV8_PMU_BUS_SLOTS_SHIFT 8
-#define ARMV8_PMU_BUS_SLOTS_MASK 0xff
-#define ARMV8_PMU_BUS_WIDTH_SHIFT 16
-#define ARMV8_PMU_BUS_WIDTH_MASK 0xf
+#define ARMV8_PMU_SLOTS		GENMASK(7, 0)
+#define ARMV8_PMU_BUS_SLOTS	GENMASK(15, 8)
+#define ARMV8_PMU_BUS_WIDTH	GENMASK(19, 16)
+#define ARMV8_PMU_THWIDTH	GENMASK(23, 20)
 
 /*
  * This code is really good
diff --git a/tools/testing/selftests/kvm/aarch64/vpmu_counter_access.c b/tools/testing/selftests/kvm/aarch64/vpmu_counter_access.c
index 5ea78986e665..9d51b5691349 100644
--- a/tools/testing/selftests/kvm/aarch64/vpmu_counter_access.c
+++ b/tools/testing/selftests/kvm/aarch64/vpmu_counter_access.c
@@ -42,13 +42,12 @@ struct pmreg_sets {
 
 static uint64_t get_pmcr_n(uint64_t pmcr)
 {
-	return (pmcr >> ARMV8_PMU_PMCR_N_SHIFT) & ARMV8_PMU_PMCR_N_MASK;
+	return FIELD_GET(ARMV8_PMU_PMCR_N, pmcr);
 }
 
 static void set_pmcr_n(uint64_t *pmcr, uint64_t pmcr_n)
 {
-	*pmcr = *pmcr & ~(ARMV8_PMU_PMCR_N_MASK << ARMV8_PMU_PMCR_N_SHIFT);
-	*pmcr |= (pmcr_n << ARMV8_PMU_PMCR_N_SHIFT);
+	u64p_replace_bits((__u64 *) pmcr, pmcr_n, ARMV8_PMU_PMCR_N);
 }
 
 static uint64_t get_counters_mask(uint64_t n)
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:21 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:21 +0000
Subject: [PATCH v7 09/11] arm: pmu: Move error message and -EOPNOTSUPP to individual PMUs
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-10-james.clark@arm.com>

-EPERM or -EINVAL always get converted to -EOPNOTSUPP, so replace them.
This will allow __hw_perf_event_init() to return a different code or not
print that particular message for a different error in the next commit.

Signed-off-by: James Clark <james.clark at arm.com>
---
 arch/arm/kernel/perf_event_v7.c |  6 ++++--
 drivers/perf/apple_m1_cpu_pmu.c |  6 ++++--
 drivers/perf/arm_pmu.c          | 11 +++++------
 drivers/perf/arm_pmuv3.c        |  6 ++++--
 4 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index eb2190477da1..4e115076d323 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -1072,8 +1072,10 @@ static int armv7pmu_set_event_filter(struct hw_perf_event *event,
 {
 	unsigned long config_base = 0;
 
-	if (attr->exclude_idle)
-		return -EPERM;
+	if (attr->exclude_idle) {
+		pr_debug("ARM performance counters do not support mode exclusion\n");
+		return -EOPNOTSUPP;
+	}
 	if (attr->exclude_user)
 		config_base |= ARMV7_EXCLUDE_USER;
 	if (attr->exclude_kernel)
diff --git a/drivers/perf/apple_m1_cpu_pmu.c b/drivers/perf/apple_m1_cpu_pmu.c
index cd2de44b61b9..f322e5ca1114 100644
--- a/drivers/perf/apple_m1_cpu_pmu.c
+++ b/drivers/perf/apple_m1_cpu_pmu.c
@@ -524,8 +524,10 @@ static int m1_pmu_set_event_filter(struct hw_perf_event *event,
 {
 	unsigned long config_base = 0;
 
-	if (!attr->exclude_guest)
-		return -EINVAL;
+	if (!attr->exclude_guest) {
+		pr_debug("ARM performance counters do not support mode exclusion\n");
+		return -EOPNOTSUPP;
+	}
 	if (!attr->exclude_kernel)
 		config_base |= M1_PMU_CFG_COUNT_KERNEL;
 	if (!attr->exclude_user)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index d712a19e47ac..2ce65b440e85 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -445,7 +445,7 @@ __hw_perf_event_init(struct perf_event *event)
 {
 	struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	int mapping;
+	int mapping, ret;
 
 	hwc->flags = 0;
 	mapping = armpmu->map_event(event);
@@ -470,11 +470,10 @@ __hw_perf_event_init(struct perf_event *event)
 	/*
 	 * Check whether we need to exclude the counter from certain modes.
 	 */
-	if (armpmu->set_event_filter &&
-	    armpmu->set_event_filter(hwc, &event->attr)) {
-		pr_debug("ARM performance counters do not support "
-			 "mode exclusion\n");
-		return -EOPNOTSUPP;
+	if (armpmu->set_event_filter) {
+		ret = armpmu->set_event_filter(hwc, &event->attr);
+		if (ret)
+			return ret;
 	}
 
 	/*
diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 84b15c0892d9..d33378a198cc 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -932,8 +932,10 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 {
 	unsigned long config_base = 0;
 
-	if (attr->exclude_idle)
-		return -EPERM;
+	if (attr->exclude_idle) {
+		pr_debug("ARM performance counters do not support mode exclusion\n");
+		return -EOPNOTSUPP;
+	}
 
 	/*
 	 * If we're running in hyp mode, then we *are* the hypervisor.
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:22 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:22 +0000
Subject: [PATCH v7 10/11] arm64: perf: Add support for event counting threshold
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-11-james.clark@arm.com>

FEAT_PMUv3_TH (Armv8.8) permits a PMU counter to increment only on
events whose count meets a specified threshold condition. For example if
PMEVTYPERn.TC (Threshold Control) is set to 0b101 (Greater than or
equal, count), and the threshold is set to 2, then the PMU counter will
now only increment by 1 when an event would have previously incremented
the PMU counter by 2 or more on a single processor cycle.

Three new Perf event config fields, 'threshold', 'threshold_compare' and
'threshold_count' have been added to control the feature.
threshold_compare maps to the upper two bits of PMEVTYPERn.TC and
threshold_count maps to the first bit of TC. These separate attributes
have been picked rather than enumerating all the possible combinations
of the TC field as in the Arm ARM. The attributes would be used on a
Perf command line like this:

  $ perf stat -e stall_slot/threshold=2,threshold_compare=2/

A new capability for reading out the maximum supported threshold value
has also been added:

  $ cat /sys/bus/event_source/devices/armv8_pmuv3/caps/threshold_max

  0x000000ff

If a threshold higher than threshold_max is provided, then an error is
generated. If FEAT_PMUv3_TH isn't implemented or a 32 bit kernel is
running, then threshold_max reads zero, and attempting to set a
threshold value will also result in an error.

The threshold is per PMU counter, and there are potentially different
threshold_max values per PMU type on heterogeneous systems.

Bits higher than 32 now need to be written into PMEVTYPER, so
armv8pmu_write_evtype() has to be updated to take an unsigned long value
rather than u32 which gives the correct behavior on both aarch32 and 64.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/perf/arm_pmuv3.c       | 79 +++++++++++++++++++++++++++++++++-
 include/linux/perf/arm_pmuv3.h |  1 +
 2 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index d33378a198cc..0bd6565eb401 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -305,10 +305,22 @@ static const struct attribute_group armv8_pmuv3_events_attr_group = {
 #define ATTR_CFG_FLD_rdpmc_CFG		config1
 #define ATTR_CFG_FLD_rdpmc_LO		1
 #define ATTR_CFG_FLD_rdpmc_HI		1
+#define ATTR_CFG_FLD_threshold_count_CFG	config1 /* PMEVTYPER.TC[0] */
+#define ATTR_CFG_FLD_threshold_count_LO		2
+#define ATTR_CFG_FLD_threshold_count_HI		2
+#define ATTR_CFG_FLD_threshold_compare_CFG	config1 /* PMEVTYPER.TC[2:1] */
+#define ATTR_CFG_FLD_threshold_compare_LO	3
+#define ATTR_CFG_FLD_threshold_compare_HI	4
+#define ATTR_CFG_FLD_threshold_CFG		config1 /* PMEVTYPER.TH */
+#define ATTR_CFG_FLD_threshold_LO		5
+#define ATTR_CFG_FLD_threshold_HI		16
 
 GEN_PMU_FORMAT_ATTR(event);
 GEN_PMU_FORMAT_ATTR(long);
 GEN_PMU_FORMAT_ATTR(rdpmc);
+GEN_PMU_FORMAT_ATTR(threshold_count);
+GEN_PMU_FORMAT_ATTR(threshold_compare);
+GEN_PMU_FORMAT_ATTR(threshold);
 
 static int sysctl_perf_user_access __read_mostly;
 
@@ -322,10 +334,27 @@ static bool armv8pmu_event_want_user_access(struct perf_event *event)
 	return ATTR_CFG_GET_FLD(&event->attr, rdpmc);
 }
 
+static u8 armv8pmu_event_threshold_control(struct perf_event_attr *attr)
+{
+	u8 th_compare = ATTR_CFG_GET_FLD(attr, threshold_compare);
+	u8 th_count = ATTR_CFG_GET_FLD(attr, threshold_count);
+
+	/*
+	 * The count bit is always the bottom bit of the full control field, and
+	 * the comparison is the upper two bits, but it's not explicitly
+	 * labelled in the Arm ARM. For the Perf interface we split it into two
+	 * fields, so reconstruct it here.
+	 */
+	return (th_compare << 1) | th_count;
+}
+
 static struct attribute *armv8_pmuv3_format_attrs[] = {
 	&format_attr_event.attr,
 	&format_attr_long.attr,
 	&format_attr_rdpmc.attr,
+	&format_attr_threshold.attr,
+	&format_attr_threshold_compare.attr,
+	&format_attr_threshold_count.attr,
 	NULL,
 };
 
@@ -375,10 +404,38 @@ static ssize_t bus_width_show(struct device *dev, struct device_attribute *attr,
 
 static DEVICE_ATTR_RO(bus_width);
 
+static u32 threshold_max(struct arm_pmu *cpu_pmu)
+{
+	/*
+	 * PMMIR.THWIDTH is readable and non-zero on aarch32, but it would be
+	 * impossible to write the threshold in the upper 32 bits of PMEVTYPER.
+	 */
+	if (IS_ENABLED(CONFIG_ARM))
+		return 0;
+
+	/*
+	 * The largest value that can be written to PMEVTYPER<n>_EL0.TH is
+	 * (2 ^ PMMIR.THWIDTH) - 1.
+	 */
+	return (1 << FIELD_GET(ARMV8_PMU_THWIDTH, cpu_pmu->reg_pmmir)) - 1;
+}
+
+static ssize_t threshold_max_show(struct device *dev,
+				  struct device_attribute *attr, char *page)
+{
+	struct pmu *pmu = dev_get_drvdata(dev);
+	struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
+
+	return sysfs_emit(page, "0x%08x\n", threshold_max(cpu_pmu));
+}
+
+static DEVICE_ATTR_RO(threshold_max);
+
 static struct attribute *armv8_pmuv3_caps_attrs[] = {
 	&dev_attr_slots.attr,
 	&dev_attr_bus_slots.attr,
 	&dev_attr_bus_width.attr,
+	&dev_attr_threshold_max.attr,
 	NULL,
 };
 
@@ -562,7 +619,7 @@ static void armv8pmu_write_counter(struct perf_event *event, u64 value)
 		armv8pmu_write_hw_counter(event, value);
 }
 
-static void armv8pmu_write_evtype(int idx, u32 val)
+static void armv8pmu_write_evtype(int idx, unsigned long val)
 {
 	u32 counter = ARMV8_IDX_TO_COUNTER(idx);
 	unsigned long mask = ARMV8_PMU_EVTYPE_EVENT |
@@ -931,6 +988,10 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 				     struct perf_event_attr *attr)
 {
 	unsigned long config_base = 0;
+	struct perf_event *perf_event = container_of(attr, struct perf_event,
+						     attr);
+	struct arm_pmu *cpu_pmu = to_arm_pmu(perf_event->pmu);
+	u32 th;
 
 	if (attr->exclude_idle) {
 		pr_debug("ARM performance counters do not support mode exclusion\n");
@@ -964,6 +1025,22 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 	if (attr->exclude_user)
 		config_base |= ARMV8_PMU_EXCLUDE_EL0;
 
+	/*
+	 * If FEAT_PMUv3_TH isn't implemented, then THWIDTH (threshold_max) will
+	 * be 0 and will also trigger this check, preventing it from being used.
+	 */
+	th = ATTR_CFG_GET_FLD(attr, threshold);
+	if (th > threshold_max(cpu_pmu)) {
+		pr_debug("PMU event threshold exceeds max value\n");
+		return -EINVAL;
+	}
+
+	if (IS_ENABLED(CONFIG_ARM64) && th) {
+		config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TH, th);
+		config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TC,
+					  armv8pmu_event_threshold_control(attr));
+	}
+
 	/*
 	 * Install the filter into config_base as this is used to
 	 * construct the event type.
diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
index 91957b3468e9..0f4d62ef3a9a 100644
--- a/include/linux/perf/arm_pmuv3.h
+++ b/include/linux/perf/arm_pmuv3.h
@@ -262,6 +262,7 @@
 #define ARMV8_PMU_SLOTS		GENMASK(7, 0)
 #define ARMV8_PMU_BUS_SLOTS	GENMASK(15, 8)
 #define ARMV8_PMU_BUS_WIDTH	GENMASK(19, 16)
+#define ARMV8_PMU_THWIDTH	GENMASK(23, 20)
 
 /*
  * This code is really good
-- 
2.34.1



From james.clark at arm.com  Mon Dec 11 08:13:23 2023
From: james.clark at arm.com (James Clark)
Date: Mon, 11 Dec 2023 16:13:23 +0000
Subject: [PATCH v7 11/11] Documentation: arm64: Document the PMU event counting threshold feature
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <20231211161331.1277825-12-james.clark@arm.com>

Add documentation for the new Perf event open parameters and
the threshold_max capability file.

Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Acked-by: Namhyung Kim <namhyung at kernel.org>
Signed-off-by: James Clark <james.clark at arm.com>
---
 Documentation/arch/arm64/perf.rst | 72 +++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/Documentation/arch/arm64/perf.rst b/Documentation/arch/arm64/perf.rst
index 1f87b57c2332..997fd716b82f 100644
--- a/Documentation/arch/arm64/perf.rst
+++ b/Documentation/arch/arm64/perf.rst
@@ -164,3 +164,75 @@ and should be used to mask the upper bits as needed.
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/arm64/tests/user-events.c
 .. _tools/lib/perf/tests/test-evsel.c:
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/perf/tests/test-evsel.c
+
+Event Counting Threshold
+==========================================
+
+Overview
+--------
+
+FEAT_PMUv3_TH (Armv8.8) permits a PMU counter to increment only on
+events whose count meets a specified threshold condition. For example if
+threshold_compare is set to 2 ('Greater than or equal'), and the
+threshold is set to 2, then the PMU counter will now only increment by
+when an event would have previously incremented the PMU counter by 2 or
+more on a single processor cycle.
+
+To increment by 1 after passing the threshold condition instead of the
+number of events on that cycle, add the 'threshold_count' option to the
+commandline.
+
+How-to
+------
+
+These are the parameters for controlling the feature:
+
+.. list-table::
+   :header-rows: 1
+
+   * - Parameter
+     - Description
+   * - threshold
+     - Value to threshold the event by. A value of 0 means that
+       thresholding is disabled and the other parameters have no effect.
+   * - threshold_compare
+     - | Comparison function to use, with the following values supported:
+       |
+       | 0: Not-equal
+       | 1: Equals
+       | 2: Greater-than-or-equal
+       | 3: Less-than
+   * - threshold_count
+     - If this is set, count by 1 after passing the threshold condition
+       instead of the value of the event on this cycle.
+
+The threshold, threshold_compare and threshold_count values can be
+provided per event, for example:
+
+.. code-block:: sh
+
+  perf stat -e stall_slot/threshold=2,threshold_compare=2/ \
+            -e dtlb_walk/threshold=10,threshold_compare=3,threshold_count/
+
+In this example the stall_slot event will count by 2 or more on every
+cycle where 2 or more stalls happen. And dtlb_walk will count by 1 on
+every cycle where the number of dtlb walks were less than 10.
+
+The maximum supported threshold value can be read from the caps of each
+PMU, for example:
+
+.. code-block:: sh
+
+  cat /sys/bus/event_source/devices/armv8_pmuv3/caps/threshold_max
+
+  0x000000ff
+
+If a value higher than this is given, then opening the event will result
+in an error. The highest possible maximum is 4095, as the config field
+for threshold is limited to 12 bits, and the Perf tool will refuse to
+parse higher values.
+
+If the PMU doesn't support FEAT_PMUv3_TH, then threshold_max will read
+0, and attempting to set a threshold value will also result in an error.
+threshold_max will also read as 0 on aarch32 guests, even if the host
+is running on hardware with the feature.
-- 
2.34.1



From hch at infradead.org  Mon Dec 11 08:18:35 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:18:35 -0800
Subject: [RFC PATCH 11/12] selftests/fpu: Move FP code to a separate
 translation unit
In-Reply-To: <20231208055501.2916202-12-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-12-samuel.holland@sifive.com>
Message-ID: <ZXc2W1Rl+S/UWAK3@infradead.org>

>  obj-$(CONFIG_TEST_FPU) += test_fpu.o
> -CFLAGS_test_fpu.o += $(FPU_CFLAGS)
> +test_fpu-y := test_fpu_glue.o test_fpu_impl.o
> +CFLAGS_test_fpu_impl.o += $(FPU_CFLAGS)

Btw, I really wonder if having a

modname-fpu += foo.o

syntax in kbuild wouldn't be preferable to this.  Of coure that requires
someone who understands kbuild inside out.

> +int test_fpu(void);

This needs to go into a header.

And I think I underatand your way to enforce the use of a separate
compilation unit in the riscv patch now.

Can we just make that generic, e.g. have a <linux/fpu.h> that wraps
<asm/fpu.h> that does the guard based on a
-D_LINUX_FPU_COMPILATION_UNIT=1 on the command line so that all the
code becomes fully portable?  Any legacy arch specific fpu users not
using <linux/fpu.h> would not be affected by it, although it would be
great to eventually migrate them to the common scheme.



From hch at infradead.org  Mon Dec 11 08:19:02 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 08:19:02 -0800
Subject: [RFC PATCH 12/12] selftests/fpu: Allow building on other
 architectures
In-Reply-To: <20231208055501.2916202-13-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-13-samuel.holland@sifive.com>
Message-ID: <ZXc2diNGXH8vaEZ8@infradead.org>

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From peter.griffin at linaro.org  Mon Dec 11 08:23:16 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:16 +0000
Subject: [PATCH v7 01/16] dt-bindings: watchdog: Document Google gs101 watchdog bindings
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-2-peter.griffin@linaro.org>

Add the "google,gs101-wdt" compatible to the dt-schema documentation.

gs101 SoC has two CPU clusters and each cluster has its own dedicated
watchdog timer (similar to exynos850 and exynosautov9 SoCs).

These WDT instances are controlled using different bits in PMU
registers.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../devicetree/bindings/watchdog/samsung-wdt.yaml         | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
index ea2d206b05ab..77a5ddd0426e 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -18,6 +18,7 @@ properties:
   compatible:
     oneOf:
       - enum:
+          - google,gs101-wdt                      # for Google gs101
           - samsung,s3c2410-wdt                   # for S3C2410
           - samsung,s3c6410-wdt                   # for S3C6410, S5PV210 and Exynos4
           - samsung,exynos5250-wdt                # for Exynos5250
@@ -47,13 +48,14 @@ properties:
   samsung,cluster-index:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
-      Index of CPU cluster on which watchdog is running (in case of Exynos850)
+      Index of CPU cluster on which watchdog is running (in case of Exynos850
+      or Google gs101).
 
   samsung,syscon-phandle:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
       Phandle to the PMU system controller node (in case of Exynos5250,
-      Exynos5420, Exynos7 and Exynos850).
+      Exynos5420, Exynos7, Exynos850 and gs101).
 
 required:
   - compatible
@@ -69,6 +71,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - google,gs101-wdt
               - samsung,exynos5250-wdt
               - samsung,exynos5420-wdt
               - samsung,exynos7-wdt
@@ -82,6 +85,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - google,gs101-wdt
               - samsung,exynos850-wdt
               - samsung,exynosautov9-wdt
     then:
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:15 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:15 +0000
Subject: [PATCH v7 00/16] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board
Message-ID: <20231211162331.435900-1-peter.griffin@linaro.org>

Hi folks,

This series adds initial SoC support for the GS101 SoC and also initial board
support for Pixel 6 phone (Oriole).

Thankyou to everyone who has reviewed and tested the previous series. Your
time and effort doing so is much appreciated! If any relevant subsystem
maintainers can send a acked-by that would be much appreciated. In particular

@RobH: Please can you re-review google.yaml as a ect node was added since you
gave your previous reviewed-by

@Guenter/Wim: If you're happy, can you send an acked-by for Watchdog changes?

V7 incorporates the review feedback received so far, and is rebased onto
linux-next as per Krzysztof request to incorporate all his dt-binding changes
for exynos. I'm really hoping V7 will be the last series, and we can get this
series merged this week so it will make it into v6.8 Linux release.

v7 fixes up various cosmetic nits in device tree and drivers regarding
alphabetical ordering. See below for more verbose details. There is one
additional patch to fixup some incorrect numbering and spelling typo
in the google,gs101.h. Also the patches which have already been applied
have been dropped from the series.

As this series spans multiple subsytems the expectation is that Krzysztof
will apply the whole series through the Samsung SoC tree. If the relevant
subsystem maintainers can give a acked-by or reviewed-by on the relevant
patches that would be most appreciated!

The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
(raven) phones. Currently DT is added for the gs101 SoC and Oriole.
As you can see from the patches the SoC is based on a Samsung Exynos SoC,
and therefore lots of the low level Exynos drivers and bindings can be
re-used.

The support added in this series consists of:
* cpus
* pinctrl
* CCF implementation of cmu_top, cmu_misc & cmu_apm
* watchdog
* USI uart
* gpio

This is enough to boot through to a busybox initramfs and shell using an
upstream kernel though :) More platform support will be added over the
following weeks and months.

For further information on how to build and flash the upstream kernel on your
Pixel 6, with a prebuilt busybox initramfs please refer to the script and
README.md here:

https://git.codelinaro.org/linaro/googlelt/pixelscripts

Note: Booting without a dtbo works with some versions of the bootloader
but crashes on others. Later versions aren't necessarily better. You can
get the bootloader version with `fastboot getvar version-bootloader`
Known good bootloader versions are: -
- slider-1.3-11000330
- slider-1.2-9152140
Known to crash without dtbo
- slider-1.3-10780582

kind regards,

Peter.

lore v6: https://lore.kernel.org/all/25533a7f-326f-48d1-a8a6-e5798bdca4b4 at linaro.org/T/
lore v5: https://lore.kernel.org/all/20231201160925.3136868-1-peter.griffin at linaro.org/T/
lore v4: https://lore.kernel.org/linux-arm-kernel/20231120212037.911774-1-peter.griffin at linaro.org/T/
pw   v3: https://patchwork.kernel.org/project/linux-samsung-soc/cover/20231011184823.443959-1-peter.griffin at linaro.org/
lore v2: https://lore.kernel.org/all/20231010224928.2296997-1-peter.griffin at linaro.org/
lore v1: https://lore.kernel.org/linux-arm-kernel/20231005155618.700312-1-peter.griffin at linaro.org/

Changes since v6:
 - Collect up Reviewed-by tags
 - s3c2410_wdt: alphabetical ordering of compatible (Krzysztof)
 - pinctrl-samsung: alphabetical ordering of compatible (Krzysztof)
 - gs101.dtsi: alphabetical node ordering, vendor properties end of node (Krzysztof)
 - Header guard doesn't match location (Krzysztof)
 - Fix incorrect numbering and spelling typo in google,gs101 and clk-gs101 (Andre)

Changes since v5:
 - Collect up Reviewed-by and Tested-by tags
 - clk-gs101: reorder cmu_top parents in register offset order (Peter)
 - clk-gs101: Review cmu_top and cmu_misc parents, fix a few typos
 - clk-gs101: Add more name mangling to shorten DT and Linux clock name strings (Sam)
 - pinctrl: samsung: Drop support for digital/analog selectable filters (Peter)
 - Fixup cmu_top yaml example and some nitpicks (Sam)
 - Fixup some spelling nitpicks in google.yaml (Sam)
 - samsung,pinctrl-wakeup-interrupt: drop second not required google,gs101-wakeup-eint compatible (Krzysztof)
 - exynos-usi.yaml: add google,gs101-usi to previous enum (Krzysztof)
 - s3c2410_wdt: move comment, double whitespace, add BIT macro (Sam)

Changes since v4:
 - clk-gs101: order cmu_top by register address, fix incorrect mux widths,
   add missing mux/div/gates (Andre)
 - google,gs101.h: add missing space in comment (Andre)
 - ckl-gs101:google,gs101.h add all remaining gates for cmu_misc and cmu_apm
 - update pmu dt labels (Krzysztof)
 - Remove uart16 rts/tx gpio definitions (Krzysztof)
 - Fixup various dts cosmetic nits (using consts, alignments,
   names) (Sam/Krzysztof)
 - Add more specific compatibles for arm cpu's and pmu (Sam)
 - Use address-cells 1 and ranges property for SoC addresses (Sam)
 - Encapsulate uart node in USI node (Sam)
 - Remove earlycon from bootargs
 - s3c2410_wdt: Reword QUIRK_HAS_DBGACK_BIT docs and add comment (Guenter)
 - s3c2410_wdt: Reorder DBGACK_MASK functionality first, gs101
   SoC second (Sam/Krzysztof)
 
Changes since v3:
 - Add reviewed-by and tested-by tags
 - google,gs101-clock.yaml: move Required to before Allof,
   enum for cmu*top/misc (Krzysztof)
 - samsung-wdt.yaml: stick to 80chars (Sam)
 - google.yaml - remove new line
 - samsung,pinctrl-wakeup-interrupt: sort alphabetically (RobH)
 - gs101-oriole.dts: update gpio-keys pinctrl-0 phandle for keys (Stephen)
 - samsung,exynos-sysreg.yaml - Alphabetical order (RobH)
 - pinctrl-exynos: update/move comments, slight cosmetic changes (Sam)
 - samsung_tty.c: update to generic drv_data name/macro (Arnd)
 - samsung_uart.yaml: make samsung,uart-fifosize required for gs101-uart (Arnd)
 - pinctrl-exynos: Remove eint irqs from alive pin controller node (Peter/Rob)
 - Fixup kernel test robot unused const variable warnings
 - clk-gs101: Update to mout_cmu_eh_bus to CLK_CON_MUX_MUX_CLKCMU_EH_BUS
   (Chanwoo)
 - clk-gs101: Update g3aa gout/dout/mout names to g3aa_g3aa for
   consistency (Chanwoo)
 - Remove .eint_gpio_init() cb on alive, alive_far, gsacore & gsactrl
   banks (Sam)
 - s3c2410_wdt: Drop windowed watchdog mode for now (Peter)
 - s3c2410_wdt: Separate gs101 SoC support from dbgack feature (Sam)
 - Move dts to arch/arm64/boot/dts/exynos/google directory (Krzysztof)

Changes since v2:
 - Fixup pinctrl at 174d0000: interrupts: [..] is too long DTC warning (Tudor)
 - Add missing windowed watchdog code (Guenter)
 - Fixup UART YAML bindings error (Krzysztof)
 - gs101.dtsi add missing serial_0 alias (me)
 - samsung_tty.c: fixup gs101_serial_drv_data so fifosize is obtained from DT
 
Changes since v1:
 - Remove irq/gs101.h and replace macros with irq numbers globally
 - exynos-pmu - keep alphabetical order
 - add cmu_apm to clock bindings documentation
 - sysreg bindings - remove superfluous `google,gs101-sysreg`
 - watchdog bindings - Alphanumerical order, update gs201 comment
 - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
 - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
 - samsung,pinctrl- add google,gs101-wakeup-eint compatible
 - clk-pll: fixup typos
 - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
 - clk-gs101: fix alphabetical order
 - clk-gs101: cmu_apm: fixup typo and missing empty entry
 - clk-gs101: cmu_misc: remove clocks that were being registerred twice
 - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON
   bitfield
 - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins
   as well
 - pinctrl: gs101: rename bank_type_6/7 structs to be more specific,
   split from filter
 - watchdog: s3c2410_wdt: remove dev_info prints
 - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node
   name, blank lines add SoC node, split dts and dtsi into separate patches,
   remove 'DVT' suffix
 - gs101-oriole.dtso: Remove overlay until board_id is documented properly
 - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
 - gpio-keys: update linux,code to use input-event-code macros
 - add dedicated gs101-uart compatible

Peter Griffin (15):
  dt-bindings: watchdog: Document Google gs101 watchdog bindings
  dt-bindings: arm: google: Add bindings for Google ARM platforms
  dt-bindings: serial: samsung: Add google-gs101-uart compatible
  dt-bindings: serial: samsung: Make samsung,uart-fifosize a required
    property
  dt-bindings: clock: google,gs101: fix incorrect numbering and DGB
    suffix
  clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
  clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm support
  pinctrl: samsung: Add gs101 SoC pinctrl configuration
  watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bit
  watchdog: s3c2410_wdt: Update QUIRK macros to use BIT macro
  watchdog: s3c2410_wdt: Add support for Google gs101 SoC
  tty: serial: samsung: Add gs101 compatible and common
    fifoszdt_serial_drv_data
  arm64: dts: exynos: google: Add initial Google gs101 SoC support
  arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
  MAINTAINERS: add entry for Google Tensor SoC

Tudor Ambarus (1):
  dt-bindings: soc: samsung: usi: add google,gs101-usi compatible

 .../devicetree/bindings/arm/google.yaml       |   53 +
 .../bindings/serial/samsung_uart.yaml         |   11 +
 .../bindings/soc/samsung/exynos-usi.yaml      |    1 +
 .../bindings/watchdog/samsung-wdt.yaml        |    8 +-
 MAINTAINERS                                   |   10 +
 arch/arm64/boot/dts/exynos/Makefile           |    2 +
 arch/arm64/boot/dts/exynos/google/Makefile    |    4 +
 .../boot/dts/exynos/google/gs101-oriole.dts   |  105 +
 .../boot/dts/exynos/google/gs101-pinctrl.dtsi | 1249 ++++++++
 .../boot/dts/exynos/google/gs101-pinctrl.h    |   33 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  473 ++++
 drivers/clk/samsung/Makefile                  |    1 +
 drivers/clk/samsung/clk-gs101.c               | 2512 +++++++++++++++++
 drivers/clk/samsung/clk-pll.c                 |    6 +
 drivers/clk/samsung/clk-pll.h                 |    3 +
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  140 +
 drivers/pinctrl/samsung/pinctrl-samsung.c     |    2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |    1 +
 drivers/tty/serial/samsung_tty.c              |   16 +
 drivers/watchdog/s3c2410_wdt.c                |   87 +-
 include/dt-bindings/clock/google,gs101.h      |  118 +-
 21 files changed, 4761 insertions(+), 74 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
 create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi
 create mode 100644 drivers/clk/samsung/clk-gs101.c

-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:17 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:17 +0000
Subject: [PATCH v7 02/16] dt-bindings: arm: google: Add bindings for Google ARM platforms
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-3-peter.griffin@linaro.org>

This introduces bindings and dt-schema for the Google Tensor SoCs.
Currently just gs101 and pixel 6 are supported.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
@RobH I removed your 'Reviewed-by: Rob Herring <robh at kernel.org>' tag
as since you reviewed this I added the empty ect node. Can you please
do the review again?

x# Please enter the commit message for your changes. Lines starting
---
 .../devicetree/bindings/arm/google.yaml       | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml

diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
new file mode 100644
index 000000000000..e20b5c9b16bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/google.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Tensor platforms
+
+maintainers:
+  - Peter Griffin <peter.griffin at linaro.org>
+
+description: |
+  ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
+  devices.
+
+  Currently upstream this is devices using "gs101" SoC which is found in Pixel
+  6, Pixel 6 Pro and Pixel 6a.
+
+  Google have a few different names for the SoC:
+  - Marketing name ("Tensor")
+  - Codename ("Whitechapel")
+  - SoC ID ("gs101")
+  - Die ID ("S5P9845")
+
+  Likewise there are a couple of names for the actual device
+  - Marketing name ("Pixel 6")
+  - Codename ("Oriole")
+
+  Devicetrees should use the lowercased SoC ID and lowercased board codename,
+  e.g. gs101 and gs101-oriole.
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Google Pixel 6 / Oriole
+        items:
+          - enum:
+              - google,gs101-oriole
+          - const: google,gs101
+
+  # Bootloader requires empty ect node to be present
+  ect:
+    type: object
+    additionalProperties: false
+
+required:
+  - ect
+
+additionalProperties: true
+
+...
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:19 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:19 +0000
Subject: [PATCH v7 04/16] dt-bindings: serial: samsung: Make samsung,uart-fifosize a required property
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-5-peter.griffin@linaro.org>

Specifying samsung,uart-fifosize in both DT and driver static data is error
prone and relies on driver probe order and dt aliases to be correct.

Additionally on many Exynos platforms these are (USI) universal serial
interfaces which can be uart, spi or i2c, so it can change per board.

For google,gs101-uart make samsung,uart-fifosize a required property.
For this platform fifosize now *only* comes from DT.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../devicetree/bindings/serial/samsung_uart.yaml       | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index 6af274d2f185..133259ed3a34 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -134,6 +134,16 @@ allOf:
             - const: uart
             - const: clk_uart_baud0
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - google,gs101-uart
+    then:
+      required:
+        - samsung,uart-fifosize
+
 unevaluatedProperties: false
 
 examples:
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:20 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:20 +0000
Subject: [PATCH v7 05/16] dt-bindings: soc: samsung: usi: add google,gs101-usi compatible
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-6-peter.griffin@linaro.org>

From: Tudor Ambarus <tudor.ambarus at linaro.org>

Add google,gs101-usi dedicated compatible for representing USI of Google
GS101 SoC.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
index 61be1f2ddbe7..8b478d6cdc30 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
@@ -25,6 +25,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - google,gs101-usi
               - samsung,exynosautov9-usi
               - samsung,exynosautov920-usi
           - const: samsung,exynos850-usi
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:22 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:22 +0000
Subject: [PATCH v7 07/16] clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-8-peter.griffin@linaro.org>

These plls are found in the Tensor gs101 SoC found in the Pixel 6.

pll0516x: Integer PLL with high frequency
pll0517x: Integer PLL with middle frequency
pll0518x: Integer PLL with low frequency

PLL0516x
FOUT = (MDIV * 2 * FIN)/PDIV * 2^SDIV)

PLL0517x and PLL0518x
FOUT = (MDIV * FIN)/PDIV*2^SDIV)

The PLLs are similar enough to pll_0822x that the same code can handle
both. The main difference is the change in the fout formula for the
high frequency 0516 pll.

Locktime for 516,517 & 518 is 150 the same as the pll_0822x lock factor.
MDIV, SDIV PDIV masks and bit shifts are also the same as 0822x.

When defining the PLL the "con" parameter should be set to CON3
register, like this

PLL(pll_0517x, CLK_FOUT_SHARED0_PLL, "fout_shared0_pll", "oscclk",
    PLL_LOCKTIME_PLL_SHARED0, PLL_CON3_PLL_SHARED0,
    NULL),

Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
Tested-by: Will McVicker <willmcvicker at google.com>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/clk/samsung/clk-pll.c | 6 ++++++
 drivers/clk/samsung/clk-pll.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 74934c6182ce..4bbdf5e91650 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -443,6 +443,9 @@ static unsigned long samsung_pll0822x_recalc_rate(struct clk_hw *hw,
 	sdiv = (pll_con3 >> PLL0822X_SDIV_SHIFT) & PLL0822X_SDIV_MASK;
 
 	fvco *= mdiv;
+	if (pll->type == pll_0516x)
+		fvco *= 2;
+
 	do_div(fvco, (pdiv << sdiv));
 
 	return (unsigned long)fvco;
@@ -1316,6 +1319,9 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 	case pll_1417x:
 	case pll_0818x:
 	case pll_0822x:
+	case pll_0516x:
+	case pll_0517x:
+	case pll_0518x:
 		pll->enable_offs = PLL0822X_ENABLE_SHIFT;
 		pll->lock_offs = PLL0822X_LOCK_STAT_SHIFT;
 		if (!pll->rate_table)
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index 0725d485c6ee..ffd3d52c0dec 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -38,6 +38,9 @@ enum samsung_pll_type {
 	pll_0822x,
 	pll_0831x,
 	pll_142xx,
+	pll_0516x,
+	pll_0517x,
+	pll_0518x,
 };
 
 #define PLL_RATE(_fin, _m, _p, _s, _k, _ks) \
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:24 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:24 +0000
Subject: [PATCH v7 09/16] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-10-peter.griffin@linaro.org>

Add support for the pin-controller found on the gs101 SoC used in
Pixel 6 phones.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 140 ++++++++++++++++++
 drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
 3 files changed, 143 insertions(+)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index cb965cf93705..8d08b29a21f6 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -796,3 +796,143 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
 	.ctrl		= fsd_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
 };
+
+/* pin banks of gs101 pin-controller (ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_alive[] = {
+	EXYNOS850_PIN_BANK_EINTW(8, 0x0, "gpa0", 0x00),
+	EXYNOS850_PIN_BANK_EINTW(7, 0x20, "gpa1", 0x04),
+	EXYNOS850_PIN_BANK_EINTW(5, 0x40, "gpa2", 0x08),
+	EXYNOS850_PIN_BANK_EINTW(4, 0x60, "gpa3", 0x0c),
+	EXYNOS850_PIN_BANK_EINTW(4, 0x80, "gpa4", 0x10),
+	EXYNOS850_PIN_BANK_EINTW(7, 0xa0, "gpa5", 0x14),
+	EXYNOS850_PIN_BANK_EINTW(8, 0xc0, "gpa9", 0x18),
+	EXYNOS850_PIN_BANK_EINTW(2, 0xe0, "gpa10", 0x1c),
+};
+
+/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_far_alive[] = {
+	EXYNOS850_PIN_BANK_EINTW(8, 0x0, "gpa6", 0x00),
+	EXYNOS850_PIN_BANK_EINTW(4, 0x20, "gpa7", 0x04),
+	EXYNOS850_PIN_BANK_EINTW(8, 0x40, "gpa8", 0x08),
+	EXYNOS850_PIN_BANK_EINTW(2, 0x60, "gpa11", 0x0c),
+};
+
+/* pin banks of gs101 pin-controller (GSACORE) */
+static const struct samsung_pin_bank_data gs101_pin_gsacore[] = {
+	EXYNOS850_PIN_BANK_EINTG(2, 0x0, "gps0", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(8, 0x20, "gps1", 0x04),
+	EXYNOS850_PIN_BANK_EINTG(3, 0x40, "gps2", 0x08),
+};
+
+/* pin banks of gs101 pin-controller (GSACTRL) */
+static const struct samsung_pin_bank_data gs101_pin_gsactrl[] = {
+	EXYNOS850_PIN_BANK_EINTW(6, 0x0, "gps3", 0x00),
+};
+
+/* pin banks of gs101 pin-controller (PERIC0) */
+static const struct samsung_pin_bank_data gs101_pin_peric0[] = {
+	EXYNOS850_PIN_BANK_EINTG(5, 0x0, "gpp0", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x20, "gpp1", 0x04),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x40, "gpp2", 0x08),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x60, "gpp3", 0x0c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x80, "gpp4", 0x10),
+	EXYNOS850_PIN_BANK_EINTG(2, 0xa0, "gpp5", 0x14),
+	EXYNOS850_PIN_BANK_EINTG(4, 0xc0, "gpp6", 0x18),
+	EXYNOS850_PIN_BANK_EINTG(2, 0xe0, "gpp7", 0x1c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x100, "gpp8", 0x20),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x120, "gpp9", 0x24),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x140, "gpp10", 0x28),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x160, "gpp11", 0x2c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x180, "gpp12", 0x30),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x1a0, "gpp13", 0x34),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x1c0, "gpp14", 0x38),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x1e0, "gpp15", 0x3c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x200, "gpp16", 0x40),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x220, "gpp17", 0x44),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x240, "gpp18", 0x48),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x260, "gpp19", 0x4c),
+};
+
+/* pin banks of gs101 pin-controller (PERIC1) */
+static const struct samsung_pin_bank_data gs101_pin_peric1[] = {
+	EXYNOS850_PIN_BANK_EINTG(8, 0x0, "gpp20", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x20, "gpp21", 0x04),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x40, "gpp22", 0x08),
+	EXYNOS850_PIN_BANK_EINTG(8, 0x60, "gpp23", 0x0c),
+	EXYNOS850_PIN_BANK_EINTG(4, 0x80, "gpp24", 0x10),
+	EXYNOS850_PIN_BANK_EINTG(4, 0xa0, "gpp25", 0x14),
+	EXYNOS850_PIN_BANK_EINTG(5, 0xc0, "gpp26", 0x18),
+	EXYNOS850_PIN_BANK_EINTG(4, 0xe0, "gpp27", 0x1c),
+};
+
+/* pin banks of gs101 pin-controller (HSI1) */
+static const struct samsung_pin_bank_data gs101_pin_hsi1[] = {
+	EXYNOS850_PIN_BANK_EINTG(6, 0x0, "gph0", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(7, 0x20, "gph1", 0x04),
+};
+
+/* pin banks of gs101 pin-controller (HSI2) */
+static const struct samsung_pin_bank_data gs101_pin_hsi2[] = {
+	EXYNOS850_PIN_BANK_EINTG(6, 0x0, "gph2", 0x00),
+	EXYNOS850_PIN_BANK_EINTG(2, 0x20, "gph3", 0x04),
+	EXYNOS850_PIN_BANK_EINTG(6, 0x40, "gph4", 0x08),
+};
+
+static const struct samsung_pin_ctrl gs101_pin_ctrl[] __initconst = {
+	{
+		/* pin banks of gs101 pin-controller (ALIVE) */
+		.pin_banks	= gs101_pin_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_alive),
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+		.pin_banks	= gs101_pin_far_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_far_alive),
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (GSACORE) */
+		.pin_banks	= gs101_pin_gsacore,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsacore),
+	}, {
+		/* pin banks of gs101 pin-controller (GSACTRL) */
+		.pin_banks	= gs101_pin_gsactrl,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsactrl),
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC0) */
+		.pin_banks	= gs101_pin_peric0,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric0),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC1) */
+		.pin_banks	= gs101_pin_peric1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume	= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI1) */
+		.pin_banks	= gs101_pin_hsi1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI2) */
+		.pin_banks	= gs101_pin_hsi2,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi2),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	},
+};
+
+const struct samsung_pinctrl_of_match_data gs101_of_data __initconst = {
+	.ctrl		= gs101_pin_ctrl,
+	.num_ctrl	= ARRAY_SIZE(gs101_pin_ctrl),
+};
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 79babbb39ced..5ad92600320e 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1309,6 +1309,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 		.data = &s5pv210_of_data },
 #endif
 #ifdef CONFIG_PINCTRL_EXYNOS_ARM64
+	{ .compatible = "google,gs101-pinctrl",
+		.data = &gs101_of_data },
 	{ .compatible = "samsung,exynos5433-pinctrl",
 		.data = &exynos5433_of_data },
 	{ .compatible = "samsung,exynos7-pinctrl",
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 9b3db50adef3..0b459651bc4a 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -351,6 +351,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
 extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
 extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
 extern const struct samsung_pinctrl_of_match_data fsd_of_data;
+extern const struct samsung_pinctrl_of_match_data gs101_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2416_of_data;
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:21 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:21 +0000
Subject: [PATCH v7 06/16] dt-bindings: clock: google,gs101: fix incorrect numbering and DGB suffix
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-7-peter.griffin@linaro.org>

166 was skipped by mistake and two clocks:
* CLK_MOUT_CMU_HSI0_USBDPDGB
* CLK_GOUT_HSI0_USBDPDGB

Have an incorrect DGB ending instead of DBG.

This is an ABI break, but as the patch was only applied yesterday this
header has never been in an actual release so it seems better to fix
this early than ignore it.

Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 include/dt-bindings/clock/google,gs101.h | 118 +++++++++++------------
 1 file changed, 59 insertions(+), 59 deletions(-)

diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
index 5d2c2d907a7b..9761c0b24e66 100644
--- a/include/dt-bindings/clock/google,gs101.h
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -59,7 +59,7 @@
 #define CLK_MOUT_CMU_HSI0_BUS		45
 #define CLK_MOUT_CMU_HSI0_DPGTC		46
 #define CLK_MOUT_CMU_HSI0_USB31DRD	47
-#define CLK_MOUT_CMU_HSI0_USBDPDGB	48
+#define CLK_MOUT_CMU_HSI0_USBDPDBG	48
 #define CLK_MOUT_CMU_HSI1_BUS		49
 #define CLK_MOUT_CMU_HSI1_PCIE		50
 #define CLK_MOUT_CMU_HSI2_BUS		51
@@ -181,64 +181,64 @@
 #define CLK_GOUT_BUS2_BUS		163
 #define CLK_GOUT_CIS_CLK0		164
 #define CLK_GOUT_CIS_CLK1		165
-#define CLK_GOUT_CIS_CLK2		167
-#define CLK_GOUT_CIS_CLK3		168
-#define CLK_GOUT_CIS_CLK4		169
-#define CLK_GOUT_CIS_CLK5		170
-#define CLK_GOUT_CIS_CLK6		171
-#define CLK_GOUT_CIS_CLK7		172
-#define CLK_GOUT_CMU_BOOST		173
-#define CLK_GOUT_CORE_BUS		174
-#define CLK_GOUT_CPUCL0_DBG		175
-#define CLK_GOUT_CPUCL0_SWITCH		176
-#define CLK_GOUT_CPUCL1_SWITCH		177
-#define CLK_GOUT_CPUCL2_SWITCH		178
-#define CLK_GOUT_CSIS_BUS		179
-#define CLK_GOUT_DISP_BUS		180
-#define CLK_GOUT_DNS_BUS		181
-#define CLK_GOUT_DPU_BUS		182
-#define CLK_GOUT_EH_BUS			183
-#define CLK_GOUT_G2D_G2D		184
-#define CLK_GOUT_G2D_MSCL		185
-#define CLK_GOUT_G3AA_G3AA		186
-#define CLK_GOUT_G3D_BUSD		187
-#define CLK_GOUT_G3D_GLB		188
-#define CLK_GOUT_G3D_SWITCH		189
-#define CLK_GOUT_GDC_GDC0		190
-#define CLK_GOUT_GDC_GDC1		191
-#define CLK_GOUT_GDC_SCSC		192
-#define CLK_GOUT_CMU_HPM		193
-#define CLK_GOUT_HSI0_BUS		194
-#define CLK_GOUT_HSI0_DPGTC		195
-#define CLK_GOUT_HSI0_USB31DRD		196
-#define CLK_GOUT_HSI0_USBDPDGB		197
-#define CLK_GOUT_HSI1_BUS		198
-#define CLK_GOUT_HSI1_PCIE		199
-#define CLK_GOUT_HSI2_BUS		200
-#define CLK_GOUT_HSI2_MMC_CARD		201
-#define CLK_GOUT_HSI2_PCIE		202
-#define CLK_GOUT_HSI2_UFS_EMBD		203
-#define CLK_GOUT_IPP_BUS		204
-#define CLK_GOUT_ITP_BUS		205
-#define CLK_GOUT_MCSC_ITSC		206
-#define CLK_GOUT_MCSC_MCSC		207
-#define CLK_GOUT_MFC_MFC		208
-#define CLK_GOUT_MIF_BUSP		209
-#define CLK_GOUT_MISC_BUS		210
-#define CLK_GOUT_MISC_SSS		211
-#define CLK_GOUT_PDP_BUS		212
-#define CLK_GOUT_PDP_VRA		213
-#define CLK_GOUT_G3AA			214
-#define CLK_GOUT_PERIC0_BUS		215
-#define CLK_GOUT_PERIC0_IP		216
-#define CLK_GOUT_PERIC1_BUS		217
-#define CLK_GOUT_PERIC1_IP		218
-#define CLK_GOUT_TNR_BUS		219
-#define CLK_GOUT_TOP_CMUREF		220
-#define CLK_GOUT_TPU_BUS		221
-#define CLK_GOUT_TPU_TPU		222
-#define CLK_GOUT_TPU_TPUCTL		223
-#define CLK_GOUT_TPU_UART		224
+#define CLK_GOUT_CIS_CLK2		166
+#define CLK_GOUT_CIS_CLK3		167
+#define CLK_GOUT_CIS_CLK4		168
+#define CLK_GOUT_CIS_CLK5		169
+#define CLK_GOUT_CIS_CLK6		170
+#define CLK_GOUT_CIS_CLK7		171
+#define CLK_GOUT_CMU_BOOST		172
+#define CLK_GOUT_CORE_BUS		173
+#define CLK_GOUT_CPUCL0_DBG		174
+#define CLK_GOUT_CPUCL0_SWITCH		175
+#define CLK_GOUT_CPUCL1_SWITCH		176
+#define CLK_GOUT_CPUCL2_SWITCH		177
+#define CLK_GOUT_CSIS_BUS		178
+#define CLK_GOUT_DISP_BUS		179
+#define CLK_GOUT_DNS_BUS		180
+#define CLK_GOUT_DPU_BUS		181
+#define CLK_GOUT_EH_BUS			182
+#define CLK_GOUT_G2D_G2D		183
+#define CLK_GOUT_G2D_MSCL		184
+#define CLK_GOUT_G3AA_G3AA		185
+#define CLK_GOUT_G3D_BUSD		186
+#define CLK_GOUT_G3D_GLB		187
+#define CLK_GOUT_G3D_SWITCH		188
+#define CLK_GOUT_GDC_GDC0		189
+#define CLK_GOUT_GDC_GDC1		190
+#define CLK_GOUT_GDC_SCSC		191
+#define CLK_GOUT_CMU_HPM		192
+#define CLK_GOUT_HSI0_BUS		193
+#define CLK_GOUT_HSI0_DPGTC		194
+#define CLK_GOUT_HSI0_USB31DRD		195
+#define CLK_GOUT_HSI0_USBDPDBG		196
+#define CLK_GOUT_HSI1_BUS		197
+#define CLK_GOUT_HSI1_PCIE		198
+#define CLK_GOUT_HSI2_BUS		199
+#define CLK_GOUT_HSI2_MMC_CARD		200
+#define CLK_GOUT_HSI2_PCIE		201
+#define CLK_GOUT_HSI2_UFS_EMBD		202
+#define CLK_GOUT_IPP_BUS		203
+#define CLK_GOUT_ITP_BUS		204
+#define CLK_GOUT_MCSC_ITSC		205
+#define CLK_GOUT_MCSC_MCSC		206
+#define CLK_GOUT_MFC_MFC		207
+#define CLK_GOUT_MIF_BUSP		208
+#define CLK_GOUT_MISC_BUS		209
+#define CLK_GOUT_MISC_SSS		210
+#define CLK_GOUT_PDP_BUS		211
+#define CLK_GOUT_PDP_VRA		212
+#define CLK_GOUT_G3AA			213
+#define CLK_GOUT_PERIC0_BUS		214
+#define CLK_GOUT_PERIC0_IP		215
+#define CLK_GOUT_PERIC1_BUS		216
+#define CLK_GOUT_PERIC1_IP		217
+#define CLK_GOUT_TNR_BUS		218
+#define CLK_GOUT_TOP_CMUREF		219
+#define CLK_GOUT_TPU_BUS		220
+#define CLK_GOUT_TPU_TPU		221
+#define CLK_GOUT_TPU_TPUCTL		222
+#define CLK_GOUT_TPU_UART		223
 
 /* CMU_APM */
 #define CLK_MOUT_APM_FUNC				1
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:18 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:18 +0000
Subject: [PATCH v7 03/16] dt-bindings: serial: samsung: Add google-gs101-uart compatible
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-4-peter.griffin@linaro.org>

Add dedicated google-gs101-uart compatible to the dt-schema for
representing uart of the Google Tensor gs101 SoC.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 Documentation/devicetree/bindings/serial/samsung_uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index 4b6fc82c2edf..6af274d2f185 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -21,6 +21,7 @@ properties:
       - enum:
           - apple,s5l-uart
           - axis,artpec8-uart
+          - google,gs101-uart
           - samsung,s3c6400-uart
           - samsung,s5pv210-uart
           - samsung,exynos4210-uart
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:25 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:25 +0000
Subject: [PATCH v7 10/16] watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bit
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-11-peter.griffin@linaro.org>

The WDT uses the CPU core signal DBGACK to determine whether the SoC
is running in debug mode or not. If the DBGACK signal is asserted and
DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
(disabled).

Presence of the DBGACK_MASK bit is determined by adding a new
QUIRK_HAS_DBGACK_BIT quirk. Also update to use BIT macro to avoid
checkpatch --strict warnings.

Tested-by: Will McVicker <willmcvicker at google.com>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 0b4bd883ff28..7ecb762a371d 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -9,6 +9,7 @@
  *     (c) Copyright 1996 Alan Cox <alan at lxorguk.ukuu.org.uk>
  */
 
+#include <linux/bits.h>
 #include <linux/module.h>
 #include <linux/moduleparam.h>
 #include <linux/types.h>
@@ -34,9 +35,10 @@
 
 #define S3C2410_WTCNT_MAXCNT	0xffff
 
-#define S3C2410_WTCON_RSTEN	(1 << 0)
-#define S3C2410_WTCON_INTEN	(1 << 2)
-#define S3C2410_WTCON_ENABLE	(1 << 5)
+#define S3C2410_WTCON_RSTEN		BIT(0)
+#define S3C2410_WTCON_INTEN		BIT(2)
+#define S3C2410_WTCON_ENABLE		BIT(5)
+#define S3C2410_WTCON_DBGACK_MASK	BIT(16)
 
 #define S3C2410_WTCON_DIV16	(0 << 3)
 #define S3C2410_WTCON_DIV32	(1 << 3)
@@ -100,12 +102,17 @@
  * %QUIRK_HAS_PMU_CNT_EN: PMU block has some register (e.g. CLUSTERx_NONCPU_OUT)
  * with "watchdog counter enable" bit. That bit should be set to make watchdog
  * counter running.
+ *
+ * %QUIRK_HAS_DBGACK_BIT: WTCON register has DBGACK_MASK bit. Setting the
+ * DBGACK_MASK bit disables the watchdog outputs when the SoC is in debug mode.
+ * Debug mode is determined by the DBGACK CPU signal.
  */
 #define QUIRK_HAS_WTCLRINT_REG			(1 << 0)
 #define QUIRK_HAS_PMU_MASK_RESET		(1 << 1)
 #define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
 #define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
 #define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
+#define QUIRK_HAS_DBGACK_BIT			BIT(5)
 
 /* These quirks require that we have a PMU register map */
 #define QUIRKS_HAVE_PMUREG \
@@ -375,6 +382,19 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
 	return 0;
 }
 
+/* Disable watchdog outputs if CPU is in debug mode */
+static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt)
+{
+	unsigned long wtcon;
+
+	if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
+		return;
+
+	wtcon = readl(wdt->reg_base + S3C2410_WTCON);
+	wtcon |= S3C2410_WTCON_DBGACK_MASK;
+	writel(wtcon, wdt->reg_base + S3C2410_WTCON);
+}
+
 static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
 {
 	struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
@@ -700,6 +720,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
 	wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
 	wdt->wdt_device.parent = dev;
 
+	s3c2410wdt_mask_dbgack(wdt);
+
 	/*
 	 * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
 	 * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:28 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:28 +0000
Subject: [PATCH v7 13/16] tty: serial: samsung: Add gs101 compatible and common fifoszdt_serial_drv_data
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-14-peter.griffin@linaro.org>

Add serial driver data for Google Tensor gs101 SoC and a common
fifoszdt_serial_drv_data that can be used by platforms that specify the
samsung,uart-fifosize DT property.

A corresponding dt-bindings patch updates the yaml to ensure
samsung,uart-fifosize is a required property.

Tested-by: Will McVicker <willmcvicker at google.com>
Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Reviewed-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/tty/serial/samsung_tty.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 1b0c2b467a30..71d17d804fda 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2490,14 +2490,25 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
 	.fifosize = { 256, 64, 64, 64 },
 };
 
+/*
+ * Common drv_data struct for platforms that specify samsung,uart-fifosize in
+ * device tree.
+ */
+static const struct s3c24xx_serial_drv_data exynos_fifoszdt_serial_drv_data = {
+	EXYNOS_COMMON_SERIAL_DRV_DATA(),
+	.fifosize = { 0 },
+};
+
 #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
 #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
 #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
+#define EXYNOS_FIFOSZDT_DRV_DATA (&exynos_fifoszdt_serial_drv_data)
 
 #else
 #define EXYNOS4210_SERIAL_DRV_DATA NULL
 #define EXYNOS5433_SERIAL_DRV_DATA NULL
 #define EXYNOS850_SERIAL_DRV_DATA NULL
+#define EXYNOS_FIFOSZDT_DRV_DATA NULL
 #endif
 
 #ifdef CONFIG_ARCH_APPLE
@@ -2581,6 +2592,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
 	}, {
 		.name		= "artpec8-uart",
 		.driver_data	= (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
+	}, {
+		.name		= "gs101-uart",
+		.driver_data	= (kernel_ulong_t)EXYNOS_FIFOSZDT_DRV_DATA,
 	},
 	{ },
 };
@@ -2602,6 +2616,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
 		.data = EXYNOS850_SERIAL_DRV_DATA },
 	{ .compatible = "axis,artpec8-uart",
 		.data = ARTPEC8_SERIAL_DRV_DATA },
+	{ .compatible = "google,gs101-uart",
+		.data = EXYNOS_FIFOSZDT_DRV_DATA },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:30 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:30 +0000
Subject: [PATCH v7 15/16] arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-16-peter.griffin@linaro.org>

Add initial board support for the Pixel 6 phone code named Oriole. This
has been tested with a minimal busybox initramfs and boots to a shell.

Tested-by: Will McVicker <willmcvicker at google.com>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 arch/arm64/boot/dts/exynos/Makefile           |   2 +
 arch/arm64/boot/dts/exynos/google/Makefile    |   4 +
 .../boot/dts/exynos/google/gs101-oriole.dts   | 105 ++++++++++++++++++
 3 files changed, 111 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts

diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
index 6e4ba69268e5..44c24a8ad9e1 100644
--- a/arch/arm64/boot/dts/exynos/Makefile
+++ b/arch/arm64/boot/dts/exynos/Makefile
@@ -1,4 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
+subdir-y += google
+
 dtb-$(CONFIG_ARCH_EXYNOS) += \
 	exynos5433-tm2.dtb		\
 	exynos5433-tm2e.dtb		\
diff --git a/arch/arm64/boot/dts/exynos/google/Makefile b/arch/arm64/boot/dts/exynos/google/Makefile
new file mode 100644
index 000000000000..0a6d5e1fe4ee
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+dtb-$(CONFIG_ARCH_EXYNOS) += \
+	gs101-oriole.dtb \
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
new file mode 100644
index 000000000000..4a71f752200d
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Oriole Device Tree
+ *
+ * Copyright 2021-2023 Google LLC
+ * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "gs101-pinctrl.h"
+#include "gs101.dtsi"
+
+/ {
+	model = "Oriole";
+	compatible = "google,gs101-oriole", "google,gs101";
+
+	aliases {
+		serial0 = &serial_0;
+	};
+
+	chosen {
+		/* Bootloader expects bootargs specified otherwise it crashes */
+		bootargs = "";
+		stdout-path = &serial_0;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&key_voldown>, <&key_volup>, <&key_power>;
+
+		button-vol-down {
+			label = "KEY_VOLUMEDOWN";
+			linux,code = <KEY_VOLUMEDOWN>;
+			gpios = <&gpa7 3 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-vol-up {
+			label = "KEY_VOLUMEUP";
+			linux,code = <KEY_VOLUMEUP>;
+			gpios = <&gpa8 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-power {
+			label = "KEY_POWER";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpa10 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+	};
+};
+
+&ext_24_5m {
+	clock-frequency = <24576000>;
+};
+
+&ext_200m {
+	clock-frequency = <200000000>;
+};
+
+&pinctrl_far_alive {
+	key_voldown: key-voldown-pins {
+		samsung,pins = "gpa7-3";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	key_volup: key-volup-pins {
+		samsung,pins = "gpa8-1";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_gpio_alive {
+	key_power: key-power-pins {
+		samsung,pins = "gpa10-1";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&serial_0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_bus>;
+	status = "okay";
+};
+
+&usi_uart {
+	samsung,clkreq-on; /* needed for UART mode */
+	status = "okay";
+};
+
+&watchdog_cl0 {
+	timeout-sec = <30>;
+	status = "okay";
+};
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:27 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:27 +0000
Subject: [PATCH v7 12/16] watchdog: s3c2410_wdt: Add support for Google gs101 SoC
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-13-peter.griffin@linaro.org>

This patch adds the compatibles and drvdata for the Google
gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.

Similar to Exynos850 it has two watchdog instances, one for
each cluster and has some control bits in PMU registers.

gs101 also has the dbgack_mask bit in wtcon register, so
we also enable QUIRK_HAS_DBGACK_BIT.

Tested-by: Will McVicker <willmcvicker at google.com>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 49 ++++++++++++++++++++++++++++++----
 1 file changed, 44 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index b7a03668f743..c3046610ab5d 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -69,6 +69,13 @@
 #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
 #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
 
+#define GS_CLUSTER0_NONCPU_OUT			0x1220
+#define GS_CLUSTER1_NONCPU_OUT			0x1420
+#define GS_CLUSTER0_NONCPU_INT_EN		0x1244
+#define GS_CLUSTER1_NONCPU_INT_EN		0x1444
+#define GS_CLUSTER2_NONCPU_INT_EN		0x1644
+#define GS_RST_STAT_REG_OFFSET			0x3B44
+
 /**
  * DOC: Quirk flags for different Samsung watchdog IP-cores
  *
@@ -270,7 +277,35 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
 		  QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
 };
 
+static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
+	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 0,
+	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
+	.cnt_en_bit = 8,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET |
+		  QUIRK_HAS_PMU_CNT_EN | QUIRK_HAS_WTCLRINT_REG |
+		  QUIRK_HAS_DBGACK_BIT,
+};
+
+static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
+	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 1,
+	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
+	.cnt_en_bit = 7,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET |
+		  QUIRK_HAS_PMU_CNT_EN | QUIRK_HAS_WTCLRINT_REG |
+		  QUIRK_HAS_DBGACK_BIT,
+};
+
 static const struct of_device_id s3c2410_wdt_match[] = {
+	{ .compatible = "google,gs101-wdt",
+	  .data = &drv_data_gs101_cl0 },
 	{ .compatible = "samsung,s3c2410-wdt",
 	  .data = &drv_data_s3c2410 },
 	{ .compatible = "samsung,s3c6410-wdt",
@@ -605,9 +640,10 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 	}
 
 #ifdef CONFIG_OF
-	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
+	/* Choose Exynos9 SoC family driver data w.r.t. cluster index */
 	if (variant == &drv_data_exynos850_cl0 ||
-	    variant == &drv_data_exynosautov9_cl0) {
+	    variant == &drv_data_exynosautov9_cl0 ||
+	    variant == &drv_data_gs101_cl0) {
 		u32 index;
 		int err;
 
@@ -620,9 +656,12 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 		case 0:
 			break;
 		case 1:
-			variant = (variant == &drv_data_exynos850_cl0) ?
-				&drv_data_exynos850_cl1 :
-				&drv_data_exynosautov9_cl1;
+			if (variant == &drv_data_exynos850_cl0)
+				variant = &drv_data_exynos850_cl1;
+			else if (variant == &drv_data_exynosautov9_cl0)
+				variant = &drv_data_exynosautov9_cl1;
+			else if (variant == &drv_data_gs101_cl0)
+				variant = &drv_data_gs101_cl1;
 			break;
 		default:
 			return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:26 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:26 +0000
Subject: [PATCH v7 11/16] watchdog: s3c2410_wdt: Update QUIRK macros to use BIT macro
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-12-peter.griffin@linaro.org>

Update the remaining QUIRK macros to use the BIT macro.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7ecb762a371d..b7a03668f743 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -107,11 +107,11 @@
  * DBGACK_MASK bit disables the watchdog outputs when the SoC is in debug mode.
  * Debug mode is determined by the DBGACK CPU signal.
  */
-#define QUIRK_HAS_WTCLRINT_REG			(1 << 0)
-#define QUIRK_HAS_PMU_MASK_RESET		(1 << 1)
-#define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
-#define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
-#define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
+#define QUIRK_HAS_WTCLRINT_REG			BIT(0)
+#define QUIRK_HAS_PMU_MASK_RESET		BIT(1)
+#define QUIRK_HAS_PMU_RST_STAT			BIT(2)
+#define QUIRK_HAS_PMU_AUTO_DISABLE		BIT(3)
+#define QUIRK_HAS_PMU_CNT_EN			BIT(4)
 #define QUIRK_HAS_DBGACK_BIT			BIT(5)
 
 /* These quirks require that we have a PMU register map */
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:31 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:31 +0000
Subject: [PATCH v7 16/16] MAINTAINERS: add entry for Google Tensor SoC
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-17-peter.griffin@linaro.org>

Add maintainers entry for the Google tensor SoC based
platforms.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 98f7dd0499f1..b731d6b9876a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8990,6 +8990,16 @@ S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
 F:	drivers/firmware/google/
 
+GOOGLE TENSOR SoC SUPPORT
+M:	Peter Griffin <peter.griffin at linaro.org>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L:	linux-samsung-soc at vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+F:	arch/arm64/boot/dts/exynos/google/
+F:	drivers/clk/samsung/clk-gs101.c
+F:	include/dt-bindings/clock/google,clk-gs101.h
+
 GPD POCKET FAN DRIVER
 M:	Hans de Goede <hdegoede at redhat.com>
 L:	platform-driver-x86 at vger.kernel.org
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Mon Dec 11 08:23:29 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 16:23:29 +0000
Subject: [PATCH v7 14/16] arm64: dts: exynos: google: Add initial Google gs101 SoC support
In-Reply-To: <20231211162331.435900-1-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
Message-ID: <20231211162331.435900-15-peter.griffin@linaro.org>

Google gs101 SoC is a ARMv8 mobile SoC found in the Pixel 6
(oriole), Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
phones.

It features:
* 4xA55 Little cluster
* 2xA76 Mid cluster
* 2xX1 Big cluster

This commit adds the basic device tree for gs101 (SoC).
Further platform support will be added over time.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Tested-by: Will McVicker <willmcvicker at google.com>
Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../boot/dts/exynos/google/gs101-pinctrl.dtsi | 1249 +++++++++++++++++
 .../boot/dts/exynos/google/gs101-pinctrl.h    |   33 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  473 +++++++
 3 files changed, 1755 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi

diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
new file mode 100644
index 000000000000..e6a9776d4d62
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
@@ -0,0 +1,1249 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright 2019-2023 Google LLC
+ * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
+ */
+
+#include "gs101-pinctrl.h"
+
+&pinctrl_gpio_alive {
+	gpa0: gpa0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa1: gpa1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa2: gpa2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa3: gpa3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa4: gpa4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa5: gpa5-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa9: gpa9-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa10: gpa10-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	uart15_bus: uart15-bus-pins {
+		samsung,pins = "gpa2-3", "gpa2-4";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	uart16_bus: uart16-bus-pins {
+		samsung,pins = "gpa3-0", "gpa3-1", "gpa3-2", "gpa3-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	uart17_bus: uart17-bus-pins {
+		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2", "gpa4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi15_bus: spi15-bus-pins {
+		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi15_cs: spi15-cs-pins {
+		samsung,pins = "gpa4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_far_alive {
+	gpa6: gpa6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa7: gpa7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa8: gpa8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+
+	gpa11: gpa11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH 0>;
+	};
+};
+
+&pinctrl_gsacore {
+	gps0: gps0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps1: gps1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps2: gps2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_gsactrl {
+	gps3: gps3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+&pinctrl_hsi1 {
+	gph0: gph0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph1: gph1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	pcie0_clkreq: pcie0-clkreq-pins{
+		samsung,pins = "gph0-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
+	};
+
+	pcie0_perst: pcie0-perst-pins {
+		samsung,pins = "gph0-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+	};
+};
+
+&pinctrl_hsi2 {
+	gph2: gph2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph3: gph3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph4: gph4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	sd2_clk: sd2-clk-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_cmd: sd2-cmd-pins {
+		samsung,pins = "gph4-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus1: sd2-bus-width1-pins {
+		samsung,pins = "gph4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus4: sd2-bus-width4-pins {
+		samsung,pins = "gph4-3", "gph4-4", "gph4-5";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_1x: sd2-clk-fast-slew-rate-1x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_2x: sd2-clk-fast-slew-rate-2x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_3x: sd2-clk-fast-slew-rate-3x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_4x: sd2-clk-fast-slew-rate-4x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+	};
+
+	ufs_rst_n: ufs-rst-n-pins {
+		samsung,pins = "gph3-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	ufs_refclk_out: ufs-refclk-out-pins {
+		samsung,pins = "gph3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	pcie1_clkreq: pcie1-clkreq-pins {
+		samsung,pins = "gph2-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_UP>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_UP>;
+	};
+
+	pcie1_perst: pcie1-perst-pins {
+		samsung,pins = "gph2-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+	};
+};
+
+&pinctrl_peric0 {
+	gpp0: gpp0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp1: gpp1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp2: gpp2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp3: gpp3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp4: gpp4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp5: gpp5-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp6: gpp6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp7: gpp7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp8: gpp8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp9: gpp9-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp10: gpp10-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp11: gpp11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp12: gpp12-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp13: gpp13-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp14: gpp14-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp15: gpp15-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp16: gpp16-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp17: gpp17-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp18: gpp18-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp19: gpp19-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	/* USI_PERIC0_UART_DBG */
+	uart0_bus: uart0-bus-pins {
+		samsung,pins = "gpp1-2", "gpp1-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	disp_te_pri_on: disp-te-pri-on-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+	};
+
+	disp_te_pri_off: disp-te-pri-off-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
+	};
+
+	disp_te_sec_on: disp-te-sec-on-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
+	};
+
+	disp_te_sec_off: disp-te-sec-off-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <GS101_PIN_FUNC_INPUT>;
+	};
+
+	sensor_mclk1_out: sensor-mclk1-out-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk1_fn: sensor-mclk1-fn-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_out: sensor-mclk2-out-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_fn: sensor-mclk2-fn-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_out: sensor-mclk3-out-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_fn: sensor-mclk3-fn-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_out: sensor-mclk4-out-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_fn: sensor-mclk4-fn-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_out: sensor-mclk5-out-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_fn: sensor-mclk5-fn-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_out: sensor-mclk6-out-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_fn: sensor-mclk6-fn-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_out: sensor-mclk7-out-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_fn: sensor-mclk7-fn-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_out: sensor-mclk8-out-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_fn: sensor-mclk8-fn-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	hsi2c14_bus: hsi2c14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart14_bus_single: uart14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1",
+			       "gpp18-2", "gpp18-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi14_bus: spi14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1", "gpp18-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs: spi14-cs-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs_func: spi14-cs-func-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c8_bus: hsi2c8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-pud-pdn = <GS101_PIN_PDN_OUT0>;
+	};
+
+	uart8_bus_single: uart8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2",
+			       "gpp16-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi8_bus: spi8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs: spi8-cs-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs_func: spi8-cs-func-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c7_bus: hsi2c7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart7_bus_single: uart7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1",
+			       "gpp14-2", "gpp14-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi7_bus: spi7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1", "gpp14-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs: spi7-cs-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs_func: spi7-cs-func-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c6_bus: hsi2c6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart6_bus_single: uart6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1",
+			       "gpp12-2", "gpp12-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi6_bus: spi6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1", "gpp12-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs: spi6-cs-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs_func: spi6-cs-func-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c5_bus: hsi2c5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart5_bus_single: uart5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1",
+			       "gpp10-2", "gpp10-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi5_bus: spi5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1", "gpp10-2";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi5_cs_func: spi5-cs-func-pins {
+		samsung,pins = "gpp10-3";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	hsi2c4_bus: hsi2c4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart4_bus_single: uart4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1",
+			       "gpp8-2", "gpp8-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi4_bus: spi4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1", "gpp8-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs: spi4-cs-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs_func: spi4-cs-func-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c3_bus: hsi2c3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart3_bus_single: uart3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1",
+			       "gpp6-2", "gpp6-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi3_bus: spi3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1", "gpp6-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs: spi3-cs-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs_func: spi3-cs-func-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c2_bus: hsi2c2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart2_bus_single: uart2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1",
+			       "gpp4-2", "gpp4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi2_bus: spi2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1", "gpp4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs: spi2-cs-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs_func: spi2-cs-func-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c1_bus: hsi2c1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart1_bus_single: uart1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1",
+			       "gpp2-2", "gpp2-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi1_bus: spi1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1", "gpp2-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs: spi1-cs-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs_func: spi1-cs-func-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_peric1 {
+	gpp20: gpp20-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp21: gpp21-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp22: gpp22-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp23: gpp23-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp24: gpp24-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp25: gpp25-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp26: gpp26-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp27: gpp27-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	hsi2c13_bus: hsi2c13-bus-pins  {
+		samsung,pins = "gpp25-0", "gpp25-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart13_bus_single: uart13-bus-pins {
+		samsung,pins = "gpp25-0", "gpp25-1",
+			       "gpp25-2", "gpp25-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi13_bus: spi13-bus-pins {
+		samsung,pins = "gpp25-0", "gpp25-1", "gpp25-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs: spi13-cs-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs_func: spi13-cs-func-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c12_bus: hsi2c12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart12_bus_single: uart12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5",
+			       "gpp23-6", "gpp23-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi12_bus: spi12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5", "gpp23-6";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs2: spi14-cs2-pins {
+		samsung,pins = "gpp23-6";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs: spi12-cs-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs_func: spi12-cs-func-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c11_bus: hsi2c11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart11_bus_single: uart11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1",
+			       "gpp23-2", "gpp23-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi11_bus: spi11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1", "gpp23-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs: spi11-cs-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs_func: spi11-cs-func-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c10_bus: hsi2c10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart10_bus_single: uart10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1",
+			       "gpp21-2", "gpp21-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi10_bus: spi10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1", "gpp21-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs: spi10-cs-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs_func: spi10-cs-func-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c9_bus: hsi2c9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart9_bus_single: uart9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5",
+			       "gpp20-6", "gpp20-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi9_bus: spi9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5", "gpp20-6";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs: spi9-cs-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs_func: spi9-cs-func-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c0_bus: hsi2c0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart0_bus_single: uart0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1",
+			       "gpp20-2", "gpp20-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi0_bus: spi0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1", "gpp20-2";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs: spi0-cs-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs_func: spi0-cs-func-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
new file mode 100644
index 000000000000..b7d276b1e25a
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Pinctrl binding constants for GS101
+ *
+ * Copyright 2020-2023 Google LLC
+ */
+
+#ifndef __DTS_ARM64_SAMSUNG_EXYNOS_GOOGLE_PINCTRL_GS101_H__
+#define __DTS_ARM64_SAMSUNG_EXYNOS_GOOGLE_PINCTRL_GS101_H__
+
+#define GS101_PIN_PULL_NONE		0
+#define GS101_PIN_PULL_DOWN		1
+#define GS101_PIN_PULL_UP		3
+
+/* Pin function in power down mode */
+#define GS101_PIN_PDN_OUT0		0
+#define GS101_PIN_PDN_OUT1		1
+#define GS101_PIN_PDN_INPUT		2
+#define GS101_PIN_PDN_PREV		3
+
+/* GS101 drive strengths */
+#define GS101_PIN_DRV_2_5_MA		0
+#define GS101_PIN_DRV_5_MA		1
+#define GS101_PIN_DRV_7_5_MA		2
+#define GS101_PIN_DRV_10_MA		3
+
+#define GS101_PIN_FUNC_INPUT		0
+#define GS101_PIN_FUNC_OUTPUT		1
+#define GS101_PIN_FUNC_2		2
+#define GS101_PIN_FUNC_3		3
+#define GS101_PIN_FUNC_EINT		0xf
+
+#endif /* __DTS_ARM64_SAMSUNG_EXYNOS_GOOGLE_PINCTRL_GS101_H__ */
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
new file mode 100644
index 000000000000..9747cb3fa03a
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -0,0 +1,473 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC
+ *
+ * Copyright 2019-2023 Google LLC
+ * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>
+ */
+
+#include <dt-bindings/clock/google,gs101.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/samsung,exynos-usi.h>
+
+/ {
+	compatible = "google,gs101";
+	#address-cells = <2>;
+	#size-cells = <1>;
+
+	interrupt-parent = <&gic>;
+
+	aliases {
+		pinctrl0 = &pinctrl_gpio_alive;
+		pinctrl1 = &pinctrl_far_alive;
+		pinctrl2 = &pinctrl_gsacore;
+		pinctrl3 = &pinctrl_gsactrl;
+		pinctrl4 = &pinctrl_peric0;
+		pinctrl5 = &pinctrl_peric1;
+		pinctrl6 = &pinctrl_hsi1;
+		pinctrl7 = &pinctrl_hsi2;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+				core1 {
+					cpu = <&cpu1>;
+				};
+				core2 {
+					cpu = <&cpu2>;
+				};
+				core3 {
+					cpu = <&cpu3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu4>;
+				};
+				core1 {
+					cpu = <&cpu5>;
+				};
+			};
+
+			cluster2 {
+				core0 {
+					cpu = <&cpu6>;
+				};
+				core1 {
+					cpu = <&cpu7>;
+				};
+			};
+		};
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0000>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu1: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0100>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu2: cpu at 200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0200>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu3: cpu at 300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0300>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu4: cpu at 400 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a76";
+			reg = <0x0400>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu5: cpu at 500 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a76";
+			reg = <0x0500>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu6: cpu at 600 {
+			device_type = "cpu";
+			compatible = "arm,cortex-x1";
+			reg = <0x0600>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		cpu7: cpu at 700 {
+			device_type = "cpu";
+			compatible = "arm,cortex-x1";
+			reg = <0x0700>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		idle-states {
+			entry-method = "psci";
+
+			ANANKE_CPU_SLEEP: cpu-ananke-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <70>;
+				exit-latency-us = <160>;
+				min-residency-us = <2000>;
+			};
+
+			ENYO_CPU_SLEEP: cpu-enyo-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <150>;
+				exit-latency-us = <190>;
+				min-residency-us = <2500>;
+			};
+
+			HERA_CPU_SLEEP: cpu-hera-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <235>;
+				exit-latency-us = <220>;
+				min-residency-us = <3500>;
+			};
+		};
+	};
+
+	/* TODO replace with CCF clock */
+	dummy_clk: clock-3 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <12345>;
+		clock-output-names = "pclk";
+	};
+
+	/* ect node is required to be present by bootloader */
+	ect {
+	};
+
+	ext_24_5m: clock-1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-output-names = "oscclk";
+	};
+
+	ext_200m: clock-2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-output-names = "ext-200m";
+	};
+
+	pmu-0 {
+		compatible = "arm,cortex-a55-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
+	};
+
+	pmu-1 {
+		compatible = "arm,cortex-a76-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
+	};
+
+	pmu-2 {
+		compatible = "arm,cortex-x1-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH &ppi_cluster2>;
+	};
+
+	pmu-3 {
+		compatible = "arm,dsu-pmu";
+		interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH 0>;
+		cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
+		       <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges;
+
+		gsa_reserved_protected: gsa at 90200000 {
+			reg = <0x0 0x90200000 0x400000>;
+			no-map;
+		};
+
+		tpu_fw_reserved: tpu-fw at 93000000 {
+			reg = <0x0 0x93000000 0x1000000>;
+			no-map;
+		};
+
+		aoc_reserve: aoc at 94000000 {
+			reg = <0x0 0x94000000 0x03000000>;
+			no-map;
+		};
+
+		abl_reserved: abl at f8800000 {
+			reg = <0x0 0xf8800000 0x02000000>;
+			no-map;
+		};
+
+		dss_log_reserved: dss-log-reserved at fd3f0000 {
+			reg = <0x0 0xfd3f0000 0x0000e000>;
+			no-map;
+		};
+
+		debug_kinfo_reserved: debug-kinfo-reserved at fd3fe000 {
+			reg = <0x0 0xfd3fe000 0x00001000>;
+			no-map;
+		};
+
+		bldr_log_reserved: bldr-log-reserved at fd800000 {
+			reg = <0x0 0xfd800000 0x00100000>;
+			no-map;
+		};
+
+		bldr_log_hist_reserved: bldr-log-hist-reserved at fd900000 {
+			reg = <0x0 0xfd900000 0x00002000>;
+			no-map;
+		};
+	};
+
+	soc: soc at 0 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0x0 0x40000000>;
+
+		cmu_misc: clock-controller at 10010000 {
+			compatible = "google,gs101-cmu-misc";
+			reg = <0x10010000 0x8000>;
+			#clock-cells = <1>;
+			clocks = <&cmu_top CLK_DOUT_CMU_MISC_BUS>,
+				 <&cmu_top CLK_DOUT_CMU_MISC_SSS>;
+			clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
+		};
+
+		watchdog_cl0: watchdog at 10060000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x10060000 0x100>;
+			interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks = <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0_PCLK>,
+				 <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <0>;
+			status = "disabled";
+		};
+
+		watchdog_cl1: watchdog at 10070000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x10070000 0x100>;
+			interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks = <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1_PCLK>,
+				 <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <1>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller at 10400000 {
+			compatible = "arm,gic-v3";
+			#interrupt-cells = <4>;
+			interrupt-controller;
+			reg = <0x10400000 0x10000>, /* GICD */
+			      <0x10440000 0x100000>;/* GICR * 8 */
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+
+			ppi-partitions {
+				ppi_cluster0: interrupt-partition-0 {
+					affinity = <&cpu0 &cpu1 &cpu2 &cpu3>;
+				};
+
+				ppi_cluster1: interrupt-partition-1 {
+					affinity = <&cpu4 &cpu5>;
+				};
+
+				ppi_cluster2: interrupt-partition-2 {
+					affinity = <&cpu6 &cpu7>;
+				};
+			};
+		};
+
+		sysreg_peric0: syscon at 10820000 {
+			compatible = "google,gs101-peric0-sysreg", "syscon";
+			reg = <0x10820000 0x10000>;
+		};
+
+		pinctrl_peric0: pinctrl at 10840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x10840000 0x00001000>;
+			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		usi_uart: usi at 10a000c0 {
+			compatible = "google,gs101-usi",
+				     "samsung,exynos850-usi";
+			reg = <0x10a000c0 0x20>;
+			ranges;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&dummy_clk>, <&dummy_clk>;
+			clock-names = "pclk", "ipclk";
+			samsung,sysreg = <&sysreg_peric0 0x1020>;
+			samsung,mode = <USI_V2_UART>;
+			status = "disabled";
+
+			serial_0: serial at 10a00000 {
+				compatible = "google,gs101-uart";
+				reg = <0x10a00000 0xc0>;
+				reg-io-width = <4>;
+				interrupts = <GIC_SPI 634
+					      IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
+				clock-names = "uart", "clk_uart_baud0";
+				samsung,uart-fifosize = <256>;
+				status = "disabled";
+			};
+		};
+
+		sysreg_peric1: syscon at 10c20000 {
+			compatible = "google,gs101-peric1-sysreg", "syscon";
+			reg = <0x10c20000 0x10000>;
+		};
+
+		pinctrl_peric1: pinctrl at 10c40000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x10c40000 0x00001000>;
+			interrupts = <GIC_SPI 644 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		pinctrl_hsi1: pinctrl at 11840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x11840000 0x00001000>;
+			interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		pinctrl_hsi2: pinctrl at 14440000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x14440000 0x00001000>;
+			interrupts = <GIC_SPI 503 IRQ_TYPE_LEVEL_HIGH 0>;
+		};
+
+		cmu_apm: clock-controller at 17400000 {
+			compatible = "google,gs101-cmu-apm";
+			reg = <0x17400000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+
+		sysreg_apm: syscon at 174204e0 {
+			compatible = "google,gs101-apm-sysreg", "syscon";
+			reg = <0x174204e0 0x1000>;
+		};
+
+		pmu_system_controller: system-controller at 17460000 {
+			compatible = "google,gs101-pmu", "syscon";
+			reg = <0x17460000 0x10000>;
+		};
+
+		pinctrl_gpio_alive: pinctrl at 174d0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x174d0000 0x00001000>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint",
+					     "samsung,exynos850-wakeup-eint",
+					     "samsung,exynos7-wakeup-eint";
+			};
+		};
+
+		pinctrl_far_alive: pinctrl at 174e0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x174e0000 0x00001000>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint",
+					     "samsung,exynos850-wakeup-eint",
+					     "samsung,exynos7-wakeup-eint";
+			};
+		};
+
+		pinctrl_gsactrl: pinctrl at 17940000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x17940000 0x00001000>;
+		};
+
+		pinctrl_gsacore: pinctrl at 17a80000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x17a80000 0x00001000>;
+		};
+
+		cmu_top: clock-controller at 1e080000 {
+			compatible = "google,gs101-cmu-top";
+			reg = <0x1e080000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts =
+		   <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+		   <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+		   <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+		   <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>;
+	};
+};
+
+#include "gs101-pinctrl.dtsi"
-- 
2.43.0.472.g3155946c3a-goog



From andre.draszik at linaro.org  Mon Dec 11 08:36:15 2023
From: andre.draszik at linaro.org (=?ISO-8859-1?Q?Andr=E9?= Draszik)
Date: Mon, 11 Dec 2023 16:36:15 +0000
Subject: [PATCH v7 06/16] dt-bindings: clock: google,gs101: fix
 incorrect numbering and DGB suffix
In-Reply-To: <20231211162331.435900-7-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
	 <20231211162331.435900-7-peter.griffin@linaro.org>
Message-ID: <f3299aaf9392aaedf8cca1c4756605b11c59b98f.camel@linaro.org>

On Mon, 2023-12-11 at 16:23 +0000, Peter Griffin wrote:
> 166 was skipped by mistake and two clocks:
> * CLK_MOUT_CMU_HSI0_USBDPDGB
> * CLK_GOUT_HSI0_USBDPDGB
> 
> Have an incorrect DGB ending instead of DBG.
> 
> This is an ABI break, but as the patch was only applied yesterday this
> header has never been in an actual release so it seems better to fix
> this early than ignore it.
> 
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Reviewed-by: Andr? Draszik <andre.draszik at linaro.org>



From francesco at dolcini.it  Mon Dec 11 08:40:17 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Mon, 11 Dec 2023 17:40:17 +0100
Subject: [PATCH v2 0/3] Bluetooth: fix recv_buf() return value
Message-ID: <20231211164020.173253-1-francesco@dolcini.it>

From: Francesco Dolcini <francesco.dolcini at toradex.com>

Serdev recv_buf() callback is supposed to return the amount of bytes consumed, therefore an int in between 0 and count.

Do not return negative number in case of issue, just print an error and return count. This fixes a WARN in ttyport_receive_buf().

In addition to that a small cleanup patch is added on btnxpuart to remove a useless assignment.

v2:
 - improved commit messages

Francesco Dolcini (3):
  Bluetooth: btnxpuart: fix recv_buf() return value
  Bluetooth: btmtkuart: fix recv_buf() return value
  Bluetooth: btnxpuart: remove useless assignment

 drivers/bluetooth/btmtkuart.c | 11 +++--------
 drivers/bluetooth/btnxpuart.c |  8 +++-----
 2 files changed, 6 insertions(+), 13 deletions(-)

-- 
2.25.1



From francesco at dolcini.it  Mon Dec 11 08:40:19 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Mon, 11 Dec 2023 17:40:19 +0100
Subject: [PATCH v2 2/3] Bluetooth: btmtkuart: fix recv_buf() return value
In-Reply-To: <20231211164020.173253-1-francesco@dolcini.it>
References: <20231211164020.173253-1-francesco@dolcini.it>
Message-ID: <20231211164020.173253-3-francesco@dolcini.it>

From: Francesco Dolcini <francesco.dolcini at toradex.com>

Serdev recv_buf() callback is supposed to return the amount of bytes
consumed, therefore an int in between 0 and count.

Do not return negative number in case of issue, just print an error and
return count. This fixes a WARN in ttyport_receive_buf().

Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
 drivers/bluetooth/btmtkuart.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
index 935feab815d9..203a000a84e3 100644
--- a/drivers/bluetooth/btmtkuart.c
+++ b/drivers/bluetooth/btmtkuart.c
@@ -336,7 +336,7 @@ mtk_stp_split(struct btmtkuart_dev *bdev, const unsigned char *data, int count,
 	return data;
 }
 
-static int btmtkuart_recv(struct hci_dev *hdev, const u8 *data, size_t count)
+static void btmtkuart_recv(struct hci_dev *hdev, const u8 *data, size_t count)
 {
 	struct btmtkuart_dev *bdev = hci_get_drvdata(hdev);
 	const unsigned char *p_left = data, *p_h4;
@@ -375,25 +375,20 @@ static int btmtkuart_recv(struct hci_dev *hdev, const u8 *data, size_t count)
 			bt_dev_err(bdev->hdev,
 				   "Frame reassembly failed (%d)", err);
 			bdev->rx_skb = NULL;
-			return err;
+			return;
 		}
 
 		sz_left -= sz_h4;
 		p_left += sz_h4;
 	}
-
-	return 0;
 }
 
 static int btmtkuart_receive_buf(struct serdev_device *serdev, const u8 *data,
 				 size_t count)
 {
 	struct btmtkuart_dev *bdev = serdev_device_get_drvdata(serdev);
-	int err;
 
-	err = btmtkuart_recv(bdev->hdev, data, count);
-	if (err < 0)
-		return err;
+	btmtkuart_recv(bdev->hdev, data, count);
 
 	bdev->hdev->stat.byte_rx += count;
 
-- 
2.25.1



From robh+dt at kernel.org  Mon Dec 11 08:42:49 2023
From: robh+dt at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 10:42:49 -0600
Subject: [PATCH v7 08/16] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <20231211162331.435900-9-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-9-peter.griffin@linaro.org>
Message-ID: <CAL_JsqJ_NUajmQs8ZYiE2GpvNxBwtkLRE2jvWDU3hKtztt92Ug@mail.gmail.com>

On Mon, Dec 11, 2023 at 10:24?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> cmu_top is the top level clock management unit which contains PLLs, muxes,
> dividers and gates that feed the other clock management units.
>
> cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> APM module.
>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Reviewed-by: Andr? Draszik <andre.draszik at linaro.org>
> Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> Tested-by: Will McVicker <willmcvicker at google.com>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  drivers/clk/samsung/Makefile    |    1 +
>  drivers/clk/samsung/clk-gs101.c | 2512 +++++++++++++++++++++++++++++++
>  2 files changed, 2513 insertions(+)
>  create mode 100644 drivers/clk/samsung/clk-gs101.c
>
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index ebbeacabe88f..3056944a5a54 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK) += clk-exynos7.o
>  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynos7885.o
>  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynos850.o
>  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynosautov9.o
> +obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-gs101.o
>  obj-$(CONFIG_S3C64XX_COMMON_CLK)       += clk-s3c64xx.o
>  obj-$(CONFIG_S5PV210_COMMON_CLK)       += clk-s5pv210.o clk-s5pv210-audss.o
>  obj-$(CONFIG_TESLA_FSD_COMMON_CLK)     += clk-fsd.o
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> new file mode 100644
> index 000000000000..05361fce3c6f
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -0,0 +1,2512 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + * Author: Peter Griffin <peter.griffin at linaro.org>
> + *
> + * Common Clock Framework support for GS101.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>

You probably don't need this header. Please check.

> +#include <linux/platform_device.h>


From u.kleine-koenig at pengutronix.de  Mon Dec 11 08:44:45 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 11 Dec 2023 17:44:45 +0100
Subject: [PATCH] pwm: meson: Simplify using dev_err_probe()
In-Reply-To: <ZXcpswXxb1oQldp5@orome.fritz.box>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
 <ZXbsDRslZNKCeJF9@orome.fritz.box>
 <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>
 <ZXcpswXxb1oQldp5@orome.fritz.box>
Message-ID: <20231211164445.cklnwuc3jni7wvji@pengutronix.de>

Hello Thierry,

On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> On Mon, Dec 11, 2023 at 03:19:00PM +0100, Uwe Kleine-K?nig wrote:
> > On Mon, Dec 11, 2023 at 12:01:33PM +0100, Thierry Reding wrote:
> > > On Fri, Dec 08, 2023 at 08:06:20PM +0100, Uwe Kleine-K?nig wrote:
> > > > On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> > > > > This is a lot of churn for very little gain.
> > > > 
> > > > We seem to have different conceptions of churn. Each hunk here is an
> > > > improvement for both SLOC count and usefulness of the generated error
> > > > message.
> > > > 
> > > > 	failed to register somename: -5
> > > > 
> > > > is worse than
> > > > 
> > > > 	error EIO: failed to register somename
> > > > 
> > > > , isn't it?
> > > 
> > > That's entirely subjective.
> > 
> > It's not. You and me both know that -5 is EIO. But there are quite a few
> > people who don't.
> 
> So it is, in fact, subjective.

For some individuals it's an improvement and for others it doesn't make
things worse. So in sum it's an objective improvement.
 
> >                   And for other error codes I'm not that fluent. (Do you
> > know -2 and -19?) Also some constants are architecture specific, so e.g.
> > -11 is -35 on alpha.
> 
> I didn't know about -11 and -35 on Alpha. Looks like %pe would handle
> those properly, so yeah, I suppose one could count that as a benefit.
> Not sure if we have PWM drivers that run on Alpha, and Meson in
> particular probably doesn't.

So using a symbolic error number (e.g. by using dev_err_probe) makes it
unnecessary to think about which arch the given driver runs on and if
the returned values might differ by architecture. One less problem to
think about, that's an advantage.

Also the next person to write a driver on alpha (or another platform
where the error codes differ from those on x86) will probably pick an
existing driver as a template. So the meson driver being robust to run
on alpha is a good thing.

> > > I think the first version is just fine. I,
> > > and I suspect most developers will, know what to do with either of those
> > > error messages.
> > 
> > Error messages aren't only for (kernel) developers. If you don't know
> > that the kernel uses negative error numbers as return codes, the
> > translation of -5 to EIO is even further away than opening
> > /usr/include/errno.h.
> 
> Actually, kernel developers are exactly who these error messages are
> for. Regular users that don't know how to decipher the error codes are
> typically not going to know what to do about the error anyway, so they
> are likely just going to copy/paste into some forum or bug tracker.

That seems to be a very cocky POV to me. But that explains a lot.
The kernel community has a very l33t reputation, lowering the bar for
newbies is a nice move IMHO.

Also EIO in a forum or bug tracker is more relevantly better, because
there are more readers that then all individually have to interpret the
-5 and know/research it's -EIO.

> > > > > None of these functions are ever going to return -EPROBE_DEFER. And
> > > > > yes, I know that function's doc says that it is "deemed acceptable to
> > > > > use" elsewhere. However, the existing error messages are just fine, no
> > > > > need to churn just for the sake of it.
> > > > 
> > > > We had this disagreement already before. Yes dev_err_probe() is useful
> > > > for three reasons and this driver only benefits from two of these.
> > > > That's IMHO still one reason more than needed to justify such a change.
> > > 
> > > I disagree. There are certainly cases where dev_err_probe() can be a
> > > significant improvement, but there are others where the improvement is
> > > very minor (if there's any at all) and in my opinion the churn isn't
> > > justified.
> > 
> > What is churn for you? Many changes? Big changes? For me churn is only a
> > big amount of changes where a considerable part cancels out if it was
> > squashed together. For you this concept seems to be broader.
> 
> Churn for me is really any kind of change and it's not bad per se. What
> I don't like are changes that are basically done just for the sake of
> changing something.

That's not my motivation.

> I don't have any strict rules for this, so I apply
> common sense. If you want to rewrite an error message because it
> contains typos or bad grammar, or is generally hard to understand,
> that's what I'd consider fine and an improvement.

I'd count "-5" as "generally hard to understand".
 
> But this patch exchanges one format of the error message by another. It
> doesn't change the error message or the information content in any way,
> but instead just rearranges where the error is printed.
> 
> On top of it not adding any benefit, this might cause somebody to get
> confused because some error message that they were looking out for is
> now different. They may have to adjust a script or something.

Yeah sure, xkcd#1172.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/86075565/attachment-0001.sig>

From peteryin.openbmc at gmail.com  Mon Dec 11 08:26:53 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Tue, 12 Dec 2023 00:26:53 +0800
Subject: [PATCH v7 0/2] Add Meta(Facebook) Harma BMC(AST2600)
Message-ID: <20231211162656.2564267-1-peteryin.openbmc@gmail.com>

Summary:
Add linux device tree entry related to Meta(Facebook) Harma
specific devices connected to BMC(AST2600) SoC.

v6:https://lore.kernel.org/all/20231206155316.4181813-3-peteryin.openbmc at gmail.com/
v5:https://lore.kernel.org/all/20231204081029.2272626-3-peteryin.openbmc at gmail.com/
v4:https://lore.kernel.org/all/20231204054131.1845775-3-peter.yin at quantatw.com/
v3:https://lore.kernel.org/all/20231123050415.3441429-3-peteryin.openbmc at gmail.com/
v2:https://lore.kernel.org/all/cdbc75b9-3be1-4017-9bee-c8f161b6843c at linaro.org/
v1:https://lore.kernel.org/all/20231024082404.735843-3-peteryin.openbmc at gmail.com/

Change log

v6 -> v7
  - Remove mac3 and vuart unsue property.
  - Rename the GPIO line name to match OpenBMC naming style.

v5 -> v6
  - Add Retimer eeprom
  - Add Power Led
  - Add GPIO/SGPIO Line Name

v4 -> v5
  - Rename document and file from minerva-harma to harma. 
  - remove Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
v3 -> v4
  - Add SGPIO line name.

v2 -> v3:
  - Fixed led schema.
  - Fixed i2c mux schema.
  - Add BMC_READY and SGPIO_READY.

v1 -> v2:
  - Add Power sensors.
  - Modify ehci number.
  - Add Led.
  - Modify SGPIO line-name.
v1:
  - Create minerva harma dts file.

Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
Peter Yin (2):
  dt-bindings: arm: aspeed: add Meta Harma board
  ARM: dts: aspeed: Harma: Add Meta Harma (AST2600) BMC

 .../bindings/arm/aspeed/aspeed.yaml           |   1 +
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-facebook-harma.dts  | 585 ++++++++++++++++++
 3 files changed, 587 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts

-- 
2.25.1



From peteryin.openbmc at gmail.com  Mon Dec 11 08:26:55 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Tue, 12 Dec 2023 00:26:55 +0800
Subject: [PATCH v7 2/2] ARM: dts: aspeed: Harma: Add Meta Harma (AST2600) BMC
In-Reply-To: <20231211162656.2564267-1-peteryin.openbmc@gmail.com>
References: <20231211162656.2564267-1-peteryin.openbmc@gmail.com>
Message-ID: <20231211162656.2564267-3-peteryin.openbmc@gmail.com>

Add linux device tree entry related to
the Meta(Facebook) computer-node system use an AT2600 BMC.
This node is named "Harma".

Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-facebook-harma.dts  | 585 ++++++++++++++++++
 2 files changed, 586 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts

diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 23cbc7203a8e..92ba3208d2a2 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -19,6 +19,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-facebook-fuji.dtb \
 	aspeed-bmc-facebook-galaxy100.dtb \
 	aspeed-bmc-facebook-greatlakes.dtb \
+	aspeed-bmc-facebook-harma.dtb \
 	aspeed-bmc-facebook-minipack.dtb \
 	aspeed-bmc-facebook-tiogapass.dtb \
 	aspeed-bmc-facebook-wedge40.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
new file mode 100644
index 000000000000..7db3f9eb0016
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
@@ -0,0 +1,585 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2023 Facebook Inc.
+
+/dts-v1/;
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/i2c/i2c.h>
+
+/ {
+	model = "Facebook Harma";
+	compatible = "facebook,harma-bmc", "aspeed,ast2600";
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart6;
+		serial2 = &uart2;
+		serial4 = &uart5;
+
+		i2c20 = &imux20;
+		i2c21 = &imux21;
+		i2c22 = &imux22;
+		i2c23 = &imux23;
+		i2c24 = &imux24;
+		i2c25 = &imux25;
+		i2c26 = &imux26;
+		i2c27 = &imux27;
+		i2c28 = &imux28;
+		i2c29 = &imux29;
+		i2c30 = &imux30;
+		i2c31 = &imux31;
+	};
+
+	chosen {
+		stdout-path = &uart5;
+	};
+
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+
+	iio-hwmon {
+		compatible = "iio-hwmon";
+		io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+			      <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+			      <&adc1 2>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			label = "bmc_heartbeat_amber";
+			gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led-1 {
+			label = "fp_id_amber";
+			default-state = "off";
+			gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-2 {
+			label = "power_blue";
+			default-state = "off";
+			gpios = <&gpio0 124 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+// HOST BIOS Debug
+&uart1 {
+	status = "okay";
+};
+
+// SOL Host Console
+&uart2 {
+	status = "okay";
+	pinctrl-0 = <>;
+};
+
+// SOL BMC Console
+&uart4 {
+	status = "okay";
+	pinctrl-0 = <>;
+};
+
+// BMC Debug Console
+&uart5 {
+	status = "okay";
+};
+
+// MTIA
+&uart6 {
+	status = "okay";
+};
+
+&uart_routing {
+	status = "okay";
+};
+
+&vuart1 {
+	status = "okay";
+};
+
+&wdt1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdtrst1_default>;
+	aspeed,reset-type = "soc";
+	aspeed,external-signal;
+	aspeed,ext-push-pull;
+	aspeed,ext-active-high;
+	aspeed,ext-pulse-duration = <256>;
+};
+
+&mac3 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rmii4_default>;
+	use-ncsi;
+	mlx,multi-host;
+};
+
+&rtc {
+	status = "okay";
+};
+
+&fmc {
+	status = "okay";
+
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "bmc";
+		spi-max-frequency = <50000000>;
+#include "openbmc-flash-layout-128.dtsi"
+	};
+
+	flash at 1 {
+		status = "okay";
+		m25p,fast-read;
+		label = "alt-bmc";
+		spi-max-frequency = <50000000>;
+	};
+};
+
+// BIOS Flash
+&spi2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spi2_default>;
+
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "pnor";
+		spi-max-frequency = <12000000>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
+	};
+};
+
+&kcs2 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca8>;
+};
+
+&kcs3 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca2>;
+};
+
+&i2c0 {
+	status = "okay";
+
+	max31790 at 30{
+		compatible = "max31790";
+		reg = <0x30>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
+
+&i2c1 {
+	status = "okay";
+
+	tmp75 at 4b {
+		compatible = "ti,tmp75";
+		reg = <0x4b>;
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	max31790 at 30{
+		compatible = "max31790";
+		reg = <0x30>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
+
+&i2c3 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9543";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux20: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			//Retimer Flash
+			eeprom at 50 {
+				compatible = "atmel,24c2048";
+				reg = <0x50>;
+				pagesize = <128>;
+			};
+		};
+		imux21: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
+};
+
+&i2c4 {
+	status = "okay";
+	// PDB FRU
+	eeprom at 52 {
+		compatible = "atmel,24c64";
+		reg = <0x52>;
+	};
+
+	delta_brick at 69 {
+		compatible = "pmbus";
+		reg = <0x69>;
+	};
+};
+
+&i2c5 {
+	status = "okay";
+};
+
+&i2c6 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9543";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux22: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux23: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+	};
+};
+
+&i2c7 {
+	status = "okay";
+};
+
+&i2c8 {
+	status = "okay";
+};
+
+&i2c9 {
+	status = "okay";
+
+	gpio at 30 {
+		compatible = "nxp,pca9555";
+		reg = <0x30>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+	gpio at 31 {
+		compatible = "nxp,pca9555";
+		reg = <0x31>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	i2c-mux at 71 {
+		compatible = "nxp,pca9546";
+		reg = <0x71>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux24: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux25: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+		imux26: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+		imux27: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+	};
+	// PTTV FRU
+	eeprom at 52 {
+		compatible = "atmel,24c64";
+		reg = <0x52>;
+	};
+};
+
+&i2c11 {
+	status = "okay";
+};
+
+&i2c12 {
+	status = "okay";
+};
+
+&i2c13 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9545";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		imux28: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+		imux29: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			//MB FRU
+			eeprom at 54 {
+				compatible = "atmel,24c64";
+				reg = <0x54>;
+			};
+		};
+		imux30: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+		imux31: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+	};
+};
+
+// To Debug card
+&i2c14 {
+	status = "okay";
+	multi-master;
+
+	ipmb at 10 {
+		compatible = "ipmb-dev";
+		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+		i2c-protocol;
+	};
+};
+
+&i2c15 {
+	status = "okay";
+
+	// SCM FRU
+	eeprom at 50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+	};
+
+	// BSM FRU
+	eeprom at 56 {
+		compatible = "atmel,24c64";
+		reg = <0x56>;
+	};
+};
+
+&adc0 {
+	aspeed,int-vref-microvolt = <2500000>;
+	status = "okay";
+	pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+		&pinctrl_adc2_default &pinctrl_adc3_default
+		&pinctrl_adc4_default &pinctrl_adc5_default
+		&pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+	aspeed,int-vref-microvolt = <2500000>;
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc10_default>;
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-names = "default";
+	gpio-line-names =
+	/*A0-A7*/	"","","","","","","","",
+	/*B0-B7*/	"","","","",
+			"bmc-spi-mux-select-0","led-identify","","",
+	/*C0-C7*/	"","","","","","","","",
+	/*D0-D7*/	"","","sol-uart-select","","","","","",
+	/*E0-E7*/	"","","","","","","","",
+	/*F0-F7*/	"","","","","","","","",
+	/*G0-G7*/	"","","","","","","","",
+	/*H0-H7*/	"","","","","","","","",
+	/*I0-I7*/	"","","","","","","","",
+	/*J0-J7*/	"","","","","","","","",
+	/*K0-K7*/	"","","","","","","","",
+	/*L0-L7*/	"","","","","","","","",
+	/*M0-M7*/	"","","","","","","","",
+	/*N0-N7*/	"led-postcode-0","led-postcode-1",
+			"led-postcode-2","led-postcode-3",
+			"led-postcode-4","led-postcode-5",
+			"led-postcode-6","led-postcode-7",
+	/*O0-O7*/	"","","","","","","","",
+	/*P0-P7*/	"power-button","power-host-control",
+			"reset-button","","led-power","","","",
+	/*Q0-Q7*/	"","","","","","","","",
+	/*R0-R7*/	"","","","","","","","",
+	/*S0-S7*/	"","","","","","","","",
+	/*T0-T7*/	"","","","","","","","",
+	/*U0-U7*/	"","","","","","","led-identify-gate","",
+	/*V0-V7*/	"","","","",
+			"rtc-battery-voltage-read-enable","","","",
+	/*W0-W7*/	"","","","","","","","",
+	/*X0-X7*/	"","","","","","","","",
+	/*Y0-Y7*/	"","","","","","","","",
+	/*Z0-Z7*/	"","","","","","","","";
+};
+
+&sgpiom0 {
+	status = "okay";
+	max-ngpios = <128>;
+	ngpios = <128>;
+	bus-frequency = <2000000>;
+	gpio-line-names =
+	/*in - out - in - out */
+	/*A0-A3 line 0-7*/
+	"presence-scm-cable","power-config-disable-e1s-0",
+	"","",
+	"","power-config-disable-e1s-1",
+	"","",
+	/*A4-A7 line 8-15*/
+	"","power-config-asic-module-enable",
+	"","power-config-asic-power-good",
+	"","power-config-pdb-power-good",
+	"presence-cpu","smi-control-n",
+	/*B0-B3 line 16-23*/
+	"","nmi-control-n",
+	"","nmi-control-sync-flood-n",
+	"","",
+	"","",
+	/*B4-B7 line 24-31*/
+	"","FM_CPU_SP5R1",
+	"reset-cause-rsmrst","FM_CPU_SP5R2",
+	"","FM_CPU_SP5R3",
+	"","FM_CPU_SP5R4",
+	/*C0-C3 line 32-39*/
+	"","FM_CPU0_SA0",
+	"","FM_CPU0_SA1",
+	"","rt-cpu0-p0-enable",
+	"","rt-cpu0-p1-enable",
+	/*C4-C7 line 40-47*/
+	"","smb-rt-rom-p0-select",
+	"","smb-rt-rom-p1-select",
+	"","i3c-cpu-mux0-oe-n",
+	"","i3c-cpu-mux0-select",
+	/*D0-D3 line 48-55*/
+	"","i3c-cpu-mux1-oe-n",
+	"","i3c-cpu-mux1-select",
+	"","reset-control-bmc",
+	"","reset-control-cpu0-p0-mux",
+	/*D4-D7 line 56-63*/
+	"","reset-control-cpu0-p1-mux",
+	"","reset-control-e1s-mux",
+	"power-host-good","reset-control-mb-mux",
+	"","reset-control-smb-e1s",
+	/*E0-E3 line 64-71*/
+	"","reset-control-smb-e1s",
+	"host-ready-n","reset-control-srst",
+	"presence-e1s-0","reset-control-usb-hub",
+	"","reset-control",
+	/*E4-E7 line 72-79*/
+	"presence-e1s-1","reset-control-cpu-kbrst",
+	"","reset-control-platrst",
+	"","bmc-jtag-mux-select-0",
+	"","bmc-jtag-mux-select-1",
+	/*F0-F3 line 80-87*/
+	"","bmc-jtag-select",
+	"","bmc-ready-n",
+	"","bmc-ready-sgpio",
+	"","rt-cpu0-p0-force-enable",
+	/*F4-F7 line 88-95*/
+	"presence-asic-modules-0","rt-cpu0-p1-force-enable",
+	"presence-asic-modules-1","bios-debug-msg-disable",
+	"","uart-control-buffer-select",
+	"","ac-control-n",
+	/*G0-G3 line 96-103*/
+	"FM_CPU_CORETYPE2","",
+	"FM_CPU_CORETYPE1","",
+	"FM_CPU_CORETYPE0","",
+	"FM_BOARD_REV_ID5","",
+	/*G4-G7 line 104-111*/
+	"FM_BOARD_REV_ID4","",
+	"FM_BOARD_REV_ID3","",
+	"FM_BOARD_REV_ID2","",
+	"FM_BOARD_REV_ID1","",
+	/*H0-H3 line 112-119*/
+	"FM_BOARD_REV_ID0","",
+	"","","","","","",
+	/*H4-H7 line 120-127*/
+	"","",
+	"reset-control-pcie-expansion-3","",
+	"reset-control-pcie-expansion-2","",
+	"reset-control-pcie-expansion-1","",
+	/*I0-I3 line 128-135*/
+	"reset-control-pcie-expansion-0","",
+	"FM_EXP_SLOT_ID1","",
+	"FM_EXP_SLOT_ID0","",
+	"","",
+	/*I4-I7 line 136-143*/
+	"","","","","","","","",
+	/*J0-J3 line 144-151*/
+	"","","","","","","","",
+	/*J4-J7 line 152-159*/
+	"SLOT_ID_BCB_0","",
+	"SLOT_ID_BCB_1","",
+	"SLOT_ID_BCB_2","",
+	"SLOT_ID_BCB_3","",
+	/*K0-K3 line 160-167*/
+	"","","","","","","","",
+	/*K4-K7 line 168-175*/
+	"","","","","","","","",
+	/*L0-L3 line 176-183*/
+	"","","","","","","","",
+	/*L4-L7 line 184-191*/
+	"","","","","","","","",
+	/*M0-M3 line 192-199*/
+	"","","","","","","","",
+	/*M4-M7 line 200-207*/
+	"","","","","","","","",
+	/*N0-N3 line 208-215*/
+	"","","","","","","","",
+	/*N4-N7 line 216-223*/
+	"","","","","","","","",
+	/*O0-O3 line 224-231*/
+	"","","","","","","","",
+	/*O4-O7 line 232-239*/
+	"","","","","","","","",
+	/*P0-P3 line 240-247*/
+	"","","","","","","","",
+	/*P4-P7 line 248-255*/
+	"","","","","","","","";
+};
-- 
2.25.1



From jgg at ziepe.ca  Mon Dec 11 07:36:33 2023
From: jgg at ziepe.ca (Jason Gunthorpe)
Date: Mon, 11 Dec 2023 11:36:33 -0400
Subject: [PATCH 3/7] ACPI/IORT: Handle memory address size limits as
 limits
In-Reply-To: <20231211153023.GA26048@willie-the-truck>
References: <cover.1701268753.git.robin.murphy@arm.com>
 <2ae6199a9cf035c1defd42e48675b827f41cdc95.1701268753.git.robin.murphy@arm.com>
 <20231211132757.GE25681@willie-the-truck>
 <91b22090-485f-49c9-a536-849fd7f92f8e@arm.com>
 <20231211153023.GA26048@willie-the-truck>
Message-ID: <20231211153633.GD1489931@ziepe.ca>

On Mon, Dec 11, 2023 at 03:30:24PM +0000, Will Deacon wrote:
> On Mon, Dec 11, 2023 at 03:01:27PM +0000, Robin Murphy wrote:
> > On 2023-12-11 1:27 pm, Will Deacon wrote:
> > > On Wed, Nov 29, 2023 at 05:43:00PM +0000, Robin Murphy wrote:
> > > > Return the Root Complex/Named Component memory address size limit as an
> > > > inclusive limit value, rather than an exclusive size.  This saves us
> > > > having to special-case 64-bit overflow, and simplifies our caller too.
> > > > 
> > > > Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> > > > ---
> > > >   drivers/acpi/arm64/dma.c  |  9 +++------
> > > >   drivers/acpi/arm64/iort.c | 18 ++++++++----------
> > > >   include/linux/acpi_iort.h |  4 ++--
> > > >   3 files changed, 13 insertions(+), 18 deletions(-)
> > > 
> > > [...]
> > > 
> > > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > > > index 6496ff5a6ba2..eb64d8e17dd1 100644
> > > > --- a/drivers/acpi/arm64/iort.c
> > > > +++ b/drivers/acpi/arm64/iort.c
> > > > @@ -1367,7 +1367,7 @@ int iort_iommu_configure_id(struct device *dev, const u32 *input_id)
> > > >   { return -ENODEV; }
> > > >   #endif
> > > > -static int nc_dma_get_range(struct device *dev, u64 *size)
> > > > +static int nc_dma_get_range(struct device *dev, u64 *limit)
> > > >   {
> > > >   	struct acpi_iort_node *node;
> > > >   	struct acpi_iort_named_component *ncomp;
> > > > @@ -1384,13 +1384,12 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
> > > >   		return -EINVAL;
> > > >   	}
> > > > -	*size = ncomp->memory_address_limit >= 64 ? U64_MAX :
> > > > -			1ULL<<ncomp->memory_address_limit;
> > > > +	*limit = (1ULL << ncomp->memory_address_limit) - 1;
> > > 
> > > The old code handled 'ncomp->memory_address_limit >= 64' -- why is it safe
> > > to drop that? You mention it in the cover letter, so clearly I'm missing
> > > something!
> > 
> > Because an unsigned shift by 64 or more generates 0 (modulo 2^64), thus
> > subtracting 1 results in the correct all-bits-set value for an inclusive
> > 64-bit limit.
> 
> Oh, I'd have thought you'd have gotten one of those "left shift count >=
> width of type" warnings if you did that.

Yes, UBSAN generates warnings for these cases. I'm not sure if it is
actually undefined C behavior or just "suspicious", but such is what
it is..

Jason


From samuel.holland at sifive.com  Mon Dec 11 08:12:27 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Mon, 11 Dec 2023 10:12:27 -0600
Subject: [RFC PATCH 05/12] lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
In-Reply-To: <ZXczty+Y6dTDL4Xi@infradead.org>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-6-samuel.holland@sifive.com>
 <ZXczty+Y6dTDL4Xi@infradead.org>
Message-ID: <7c40dfe8-f245-413f-a424-bde52ce21b6a@sifive.com>

On 2023-12-11 10:07 AM, Christoph Hellwig wrote:
>> +CFLAGS_REMOVE_neon1.o += $(CC_FLAGS_NO_FPU)
>> +CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
>> +CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
>> +CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
> 
> Btw, do we even really need the extra variables for compiler flags
> to remove?  Don't gcc/clang options work so that if you add a
> no-prefixed version of the option later it transparently gets removed?

Unfortunately, not all of the relevant options can be no-prefixed:

$ cat float.c 
int main(void) { volatile float f = 123.456; return f / 10; }
$ aarch64-linux-musl-gcc float.c 
$ aarch64-linux-musl-gcc -mgeneral-regs-only float.c 
float.c: In function 'main':
float.c:1:33: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
    1 | int main(void) { volatile float f = 123.456; return f / 10; }
      |                                 ^
float.c:1:55: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
    1 | int main(void) { volatile float f = 123.456; return f / 10; }
      |                                                     ~~^~~~
float.c:1:55: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
float.c:1:55: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
float.c:1:55: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
float.c:1:55: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
float.c:1:55: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
float.c:1:55: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
float.c:1:55: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
float.c:1:55: error: '-mgeneral-regs-only' is incompatible with the use of floating-point types
$ aarch64-linux-musl-gcc -mgeneral-regs-only -mno-general-regs-only float.c 
aarch64-linux-musl-gcc: error: unrecognized command-line option '-mno-general-regs-only'; did you mean '-mgeneral-regs-only'?
$ 



From samuel.holland at sifive.com  Mon Dec 11 08:16:14 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Mon, 11 Dec 2023 10:16:14 -0600
Subject: [RFC PATCH 09/12] riscv: Add support for kernel-mode FPU
In-Reply-To: <ZXc0rAdi7Vo8nbS8@infradead.org>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-10-samuel.holland@sifive.com>
 <ZXc0rAdi7Vo8nbS8@infradead.org>
Message-ID: <3f28c1f7-f29c-461f-a90e-58d8e0996cc0@sifive.com>

On 2023-12-11 10:11 AM, Christoph Hellwig wrote:
>> +#ifdef __riscv_f
>> +
>> +#define kernel_fpu_begin() \
>> +	static_assert(false, "floating-point code must use a separate translation unit")
>> +#define kernel_fpu_end() kernel_fpu_begin()
>> +
>> +#else
>> +
>> +void kernel_fpu_begin(void);
>> +void kernel_fpu_end(void);
>> +
>> +#endif
> 
> I'll assume this is related to trick that places code in a separate
> translation unit, but I fail to understand it.  Can you add a comment
> explaining it?

Yes, I can add a comment. Here, __riscv_f refers to RISC-V's F extension for
single-precision floating point, which is enabled by CC_FLAGS_FPU.



From peteryin.openbmc at gmail.com  Mon Dec 11 08:26:54 2023
From: peteryin.openbmc at gmail.com (Peter Yin)
Date: Tue, 12 Dec 2023 00:26:54 +0800
Subject: [PATCH v7 1/2] dt-bindings: arm: aspeed: add Meta Harma board
In-Reply-To: <20231211162656.2564267-1-peteryin.openbmc@gmail.com>
References: <20231211162656.2564267-1-peteryin.openbmc@gmail.com>
Message-ID: <20231211162656.2564267-2-peteryin.openbmc@gmail.com>

Document the new compatibles used on Meta Harma.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>
---
 Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index e17b3d66d6e5..fac3cda3f487 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -79,6 +79,7 @@ properties:
               - facebook,elbert-bmc
               - facebook,fuji-bmc
               - facebook,greatlakes-bmc
+              - facebook,harma-bmc
               - facebook,yosemite4-bmc
               - ibm,everest-bmc
               - ibm,rainier-bmc
-- 
2.25.1



From festevam at gmail.com  Mon Dec 11 09:24:35 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 11 Dec 2023 14:24:35 -0300
Subject: [PATCH] arm64: dts: imx8dxl-ss-conn: Move clk_dummy out of USB node
Message-ID: <20231211172435.503962-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The clk_dummy is not part of the usbotg2 block, so move it
to the root node to fix the following dt-schema warning:

imx8dxl-evk.dtb: usb at 5b0e0000: Unevaluated properties are not allowed ('clock-dummy' was unexpected)
	from schema $id: http://devicetree.org/schemas/usb/ci-hdrc-usb2.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi b/arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi
index 6e2d97c2fdf1..6d13e4fafb76 100644
--- a/arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi
@@ -13,6 +13,13 @@ conn_enet0_root_clk: clock-conn-enet0-root {
 		clock-frequency = <250000000>;
 		clock-output-names = "conn_enet0_root_clk";
 	};
+
+	clk_dummy: clock-dummy {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <0>;
+		clock-output-names = "clk_dummy";
+	};
 };
 
 &conn_subsys {
@@ -53,13 +60,6 @@ usbotg2: usb at 5b0e0000 {
 		rx-burst-size-dword = <0x10>;
 		power-domains = <&pd IMX_SC_R_USB_1>;
 		status = "disabled";
-
-		clk_dummy: clock-dummy {
-			compatible = "fixed-clock";
-			#clock-cells = <0>;
-			clock-frequency = <0>;
-			clock-output-names = "clk_dummy";
-		};
 	};
 
 	usbmisc2: usbmisc at 5b0e0200 {
-- 
2.34.1



From fancer.lancer at gmail.com  Mon Dec 11 09:27:46 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Mon, 11 Dec 2023 20:27:46 +0300
Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <h5ucipgjtsesrz3jyul5xohu4pqom56v6ayx7aonnfesret3ht@wmblmndj6zir>
References: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>
 <jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz@ntepnnzzelta>
 <hxds75erxqcfkufxnfbyo2up4b4jeicmi3f5xr6qlb3yf7fe76@4byeq62jhu4o>
 <hgz3pt625kggix6kzincohw7kr2okcumrwfkmjgiauw2yvhrzt@ekeygo4b7k3b>
 <h5ucipgjtsesrz3jyul5xohu4pqom56v6ayx7aonnfesret3ht@wmblmndj6zir>
Message-ID: <hpqssnt7odmuuyhsljuqovmwatdjz4s6kix6abq7lrvyciawy5@5ypscmmivnmh>

On Fri, Dec 08, 2023 at 10:50:29AM -0600, Andrew Halaney wrote:
> On Fri, Dec 08, 2023 at 06:07:06PM +0300, Serge Semin wrote:
> > On Thu, Dec 07, 2023 at 05:07:24PM -0600, Andrew Halaney wrote:
> > > On Fri, Dec 08, 2023 at 01:16:12AM +0300, Serge Semin wrote:
> > > > On Thu, Dec 07, 2023 at 03:12:40PM -0600, Andrew Halaney wrote:
> > > > > The stmmac_dt_phy() function, which parses the devicetree node of the
> > > > > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > > > > fixed-link means in relation to the MAC's MDIO bus. This results in
> > > > > a MDIO bus being created in situations it need not be.
> > > > > 
> > > > > Currently a MDIO bus is created if the description is either:
> > > > > 
> > > > >     1. Not fixed-link
> > > > >     2. fixed-link but contains a MDIO bus as well
> > > > > 
> > > > > The "1" case above isn't always accurate. If there's a phy-handle,
> > > > > it could be referencing a phy on another MDIO controller's bus[1]. In
> > > > > this case currently the MAC will make a MDIO bus and scan it all
> > > > > anyways unnecessarily.
> > > > > 
> > > > > There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> > > > > be created and scanned for a phy. This case can also be inferred from
> > > > > the platform description by not having a phy-handle && not being
> > > > > fixed-link. This hits case "1" in the current driver's logic.
> > > > > 
> > > > > Let's improve the logic to create a MDIO bus if either:
> > > > > 
> > > > 
> > > > >     - Devicetree contains a MDIO bus
> > > > >     - !fixed-link && !phy-handle (legacy handling)
> > > > 
> > > > If what you suggest here is a free from regressions semantics change
> > > > (really hope it is) I will be with both my hands for it. This will
> > > > solve the problem we have with one of our device which doesn't have
> > > > SMA interface (hardware designers decided to save ~4K gates of the
> > > > chip area) but has a PHY externally attached to the DW XGMAC<->XPCS
> > > > interface. PHY is accessible via a GPIO-based MDIO bus. BTW having no
> > > > SMA interface available on a DW *MAC device but creating the MDIO-bus
> > > > on top of the non-existent SMA CSRs anyway causes having _32_ dummy
> > > > PHYs created with zero IDs.
> > > 
> > 
> > > I hope it is regression free! I have tested both the [1] and [2] cases
> > > (I hacked up the devicetree for [1] to make it look like [2]) without
> > > any issue.
> > > 
> > 
> > I doubt you could have tested it on all the possible hardware the
> > STMMAC driver supports. The problem is that the DT-bindings thing is a
> > kind of contract which can't be changed that easily. It's like ABI but
> > for the hardware description so the kernel would bootup correctly on
> > the platforms with the old DT blobs. But if the change isn't that
> > critical, if the device-tree sources in the kernel fit to the updated
> > semantics, if the networking subsystem maintainers aren't against it
> > and I guess with the Rob, Krzysztof or Conor blessing (at least it
> > won't hurt to add them to the Cc-list together with the devicetree
> > mailing-list), then it will likely be accepted.
> 

> To be clear, I don't think we're violating the dt-binding ABI contract
> here. My intention is that all the existing use cases continue to work,
> and this just improves one use case. I did a write up
> over on v2 about the use cases I see and the current logic vs what
> changes with this patch series:
> 
>     https://lore.kernel.org/netdev/plvbqgi2bwlv5quvpiwplq7cxx6m5rl3ghnfhuxfx4bpuhyihl at zmydwrtwdeg6/
> 
> Please comment if you think I have broken some backwards
> compatibility.

To shortly sum up so I didn't miss something. Current semantics of the
MDIO-bus registration is:
if !fixed-link || mdio_node_present
    create MDIO-bus
and the semantics of the PHY auto-probe (legacy) is:
if !(fixed-link || mdio_node_present || phy_node_present)
    auto-probe PHY

You are changing the MDIO-bus creation semantics to:
if !(fixed-link || phy_node_present) || mdio_node_present
    create MDIO-bus
with no change in the PHY auto-probe semantics:
if !(fixed-link || mdio_node_present || phy_node_present)
    auto-probe PHY

So the change is that if a PHY-handle is specified the MDIO-bus won't
be created with the rest conditions being the same.

The only concern I had was the so called legacy case and a possibility
to have MDIO-bus with other than PHY devices. Based on the pseudo-code
above the former case won't be affected since having PHY-node
specified didn't triggered MDIO-bus auto-probe even before your
change. The later case concerns for instance the DW XPCS devices which
on some platforms could be found on the DW MAC MDIO bus with not
having PHY living on that bus. But DW XPCS auto-probing currently is
only supported by the non-OF platforms (it's Intel). Thus your change
is supposed to be safe here too.

So to speak AFAICS from the STMMAC MDIO OF stuff your solution isn't
supposed to cause regressions and break the current DTs backward
compatibility indeed.

Regarding the ideal implementation. What could be much better is to
implement the next semantics:
if SMA-capability-detected &&
   (!mdio_node_present || (mdio_node_present && mdio_node_enabled))
    create MDIO-bus
and preserve the PHY auto-probe semantics for backwards compatibility.
Regarding the SMA-capability flag, it has been presented since DW GMAC
v3.50, so since very much early DW MAC releases. But even for the
early devices I think it could be auto-detected by checking the SMA
CSRs writability. At least DW XGMAC AFAICS has the command CSR not
writable if SMA is unavailable.

But I guess it's a matter of another patch.

> If I _could_ break compatibility, I'd make everyone
> describe their busses entirely... but as you said that's against the
> spirit of dt-bindings and would upset a lot of people. That's why I've
> left the "!fixed-link && !phy-handle (legacy handling) logic :)
> 
> > 
> > > Sorry, I don't have any docs for stmmac hardware so this might be
> > > answered in there (or just common net knowledge that I can't find
> > > online)... what's SMA stand for? I assume it's the MDIO interface.
> > 
> > Right. Synopsys names the MDIO-bus interface as Station Management
> > Agent MDIO module.
> > 
> > > 
> > > I agree though, if you have a phy-handle and no mdio node in your
> > > devicetree this patch series should bail out without registering a bus
> > > in stmmac_mdio_register().
> > 
> > On the other hand why would the MDIO-bus needed in such case? If the
> > phy-handle property is specified with no MDIO-bus DT-subnode, then it
> > will point out to a PHY residing an external bus. The only case I can
> > imagine though is that the DW XPCS device could be still auto-detected
> > on the internal SMA-MDIO-bus. But the only driver which currently has
> > XPCS auto-detection activated is the Intel glue layer (see
> > dwmac-intel.c and has_xpcs flag), but it doesn't use DT interface
> > since it handles a PCIe-based device.  So this case is out of
> > brackets.
> 
> Agreed, I think making the bus is not needed in the driver as is in that
> case.
> 

> I'd like to think (but am not sure) that when a devicetree based DW XPCS
> description comes around it will allow you to describe it exactly
> instead of doing auto-detection (i.e. something like phy-handle), but I
> am not very familiar with PCS and friends in the stack so that may be a
> crude extension from my knowledge of MDIO.

Right, there is a generic property for that - "pcs-handle". Last week
I submitted a series which makes it supported on the STMMAC and XPCS
drivers.

-Serge(y)

> 
> Thanks,
> Andrew
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > Below upstream devicetree snippets can be found that explain some of
> > > > > the cases above more concretely.
> > > 
> > > <snip>
> > > 
> > > > > -	if (mdio) {
> > > > > -		plat->mdio_bus_data =
> > > > > -			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
> > > > > -				     GFP_KERNEL);
> > > > 
> > > > > +	/* Legacy devicetrees allowed for no MDIO bus description and expect
> > > > > +	 * the bus to be scanned for devices. If there's no phy or fixed-link
> > > > > +	 * described assume this is the case since there must be something
> > > > > +	 * connected to the MAC.
> > > > > +	 */
> > > > > +	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
> > > > > +	if (legacy_mdio)
> > > > > +		dev_info(dev, "Deprecated MDIO bus assumption used\n");
> > > > > +
> > > > > +	if (plat->mdio_node || legacy_mdio) {
> > > > > +		plat->mdio_bus_data = devm_kzalloc(dev,
> > > > 
> > > > Special thanks for adding the comment above this code. It will really
> > > > save time of figuring out why MDIO-bus needs to be created anyway.
> > > > 
> > > > > +						   sizeof(struct stmmac_mdio_bus_data),
> > > > 
> > > > Should v4 is required I would suggest to change this to
> > > > sizeof(*plat->mdio_bus_data).
> > > > 
> > > > Anyway feel free to add:
> > > > Reviewed-by: Serge Semin <fancer.lancer at gmail.com>
> > > > 
> > > > -Serge(y)
> > > 
> > 
> > > Sure I will spin v4 to pick that up, thanks for catching it. I'll also
> > > improve the motivation in the commit message a hair more per Andrew
> > > Lunn's request over here on v2 (and will hold off a little bit just to
> > > make sure reviews come in before a respin):
> > > 
> > >     https://lore.kernel.org/netdev/e64b14c3-4b80-4120-8cc4-9baa40cdcb75 at lunn.ch/
> > 
> > Ok. Thanks.
> > 
> > -Serge(y)
> > 
> > > 
> > > Thanks,
> > > Andrew
> > > 
> > 
> 


From conor at kernel.org  Mon Dec 11 09:27:54 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 11 Dec 2023 17:27:54 +0000
Subject: [PATCH v8 2/3] dt-bindings: arm64: add Marvell COM Express boards
In-Reply-To: <20231211171739.4090179-3-enachman@marvell.com>
References: <20231211171739.4090179-1-enachman@marvell.com>
 <20231211171739.4090179-3-enachman@marvell.com>
Message-ID: <20231211-scolding-celestial-db4d71f45674@spud>

On Mon, Dec 11, 2023 at 07:17:38PM +0200, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> Add dt bindings for:
> CN9130 COM Express CPU module
> CN9131 COM Express CPU module
> AC5X RD COM Express Type 7 carrier board.
> AC5X RD COM Express board with a CN9131 COM Express Type 7 CPU module.
> 
> Signed-off-by: Elad Nachman <enachman at marvell.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> ---
>  .../bindings/arm/marvell/armada-7k-8k.yaml    | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> index 52d78521e412..16d2e132d3d1 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> @@ -60,4 +60,26 @@ properties:
>            - const: marvell,armada-ap807-quad
>            - const: marvell,armada-ap807
>  
> +      - description:
> +          Alleycat5X (98DX35xx) Reference Design as COM Express Carrier plus
> +          Armada CN9130 COM Express CPU module
> +        items:
> +          - const: marvell,cn9130-ac5x-carrier
> +          - const: marvell,rd-ac5x-carrier
> +          - const: marvell,cn9130-cpu-module
> +          - const: marvell,cn9130
> +          - const: marvell,armada-ap807-quad
> +          - const: marvell,armada-ap807
> +
> +      - description:
> +          Alleycat5X (98DX35xx) Reference Design as COM Express Carrier plus
> +          Armada CN9131 COM Express CPU module
> +        items:
> +          - const: marvell,cn9131-ac5x-carrier
> +          - const: marvell,rd-ac5x-carrier
> +          - const: marvell,cn9131-cpu-module
> +          - const: marvell,cn9131
> +          - const: marvell,armada-ap807-quad
> +          - const: marvell,armada-ap807
> +
>  additionalProperties: true
> -- 
> 2.25.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231211/5579caff/attachment.sig>

From robh at kernel.org  Mon Dec 11 09:29:40 2023
From: robh at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 11:29:40 -0600
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <20231119165721.9849-12-alexandru.elisei@arm.com>
References: <20231119165721.9849-1-alexandru.elisei@arm.com> <20231119165721.9849-12-alexandru.elisei@arm.com>
Message-ID: <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>

On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
<alexandru.elisei at arm.com> wrote:
>
> Allow the kernel to get the size and location of the MTE tag storage
> regions from the DTB. This memory is marked as reserved for now.
>
> The DTB node for the tag storage region is defined as:
>
>         tags0: tag-storage at 8f8000000 {
>                 compatible = "arm,mte-tag-storage";
>                 reg = <0x08 0xf8000000 0x00 0x4000000>;
>                 block-size = <0x1000>;
>                 memory = <&memory0>;    // Associated tagged memory node
>         };

I skimmed thru the discussion some. If this memory range is within
main RAM, then it definitely belongs in /reserved-memory.

You need a binding for this too.

> The tag storage region represents the largest contiguous memory region that
> holds all the tags for the associated contiguous memory region which can be
> tagged. For example, for a 32GB contiguous tagged memory the corresponding
> tag storage region is 1GB of contiguous memory, not two adjacent 512M of
> tag storage memory.
>
> "block-size" represents the minimum multiple of 4K of tag storage where all
> the tags stored in the block correspond to a contiguous memory region. This
> is needed for platforms where the memory controller interleaves tag writes
> to memory. For example, if the memory controller interleaves tag writes for
> 256KB of contiguous memory across 8K of tag storage (2-way interleave),
> then the correct value for "block-size" is 0x2000. This value is a hardware
> property, independent of the selected kernel page size.
>
> Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
> ---
>  arch/arm64/Kconfig                       |  12 ++
>  arch/arm64/include/asm/mte_tag_storage.h |  15 ++
>  arch/arm64/kernel/Makefile               |   1 +
>  arch/arm64/kernel/mte_tag_storage.c      | 256 +++++++++++++++++++++++
>  arch/arm64/kernel/setup.c                |   7 +
>  5 files changed, 291 insertions(+)
>  create mode 100644 arch/arm64/include/asm/mte_tag_storage.h
>  create mode 100644 arch/arm64/kernel/mte_tag_storage.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7b071a00425d..fe8276fdc7a8 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2062,6 +2062,18 @@ config ARM64_MTE
>
>           Documentation/arch/arm64/memory-tagging-extension.rst.
>
> +if ARM64_MTE
> +config ARM64_MTE_TAG_STORAGE
> +       bool "Dynamic MTE tag storage management"
> +       help
> +         Adds support for dynamic management of the memory used by the hardware
> +         for storing MTE tags. This memory, unlike normal memory, cannot be
> +         tagged. When it is used to store tags for another memory location it
> +         cannot be used for any type of allocation.
> +
> +         If unsure, say N
> +endif # ARM64_MTE
> +
>  endmenu # "ARMv8.5 architectural features"
>
>  menu "ARMv8.7 architectural features"
> diff --git a/arch/arm64/include/asm/mte_tag_storage.h b/arch/arm64/include/asm/mte_tag_storage.h
> new file mode 100644
> index 000000000000..8f86c4f9a7c3
> --- /dev/null
> +++ b/arch/arm64/include/asm/mte_tag_storage.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2023 ARM Ltd.
> + */
> +#ifndef __ASM_MTE_TAG_STORAGE_H
> +#define __ASM_MTE_TAG_STORAGE_H
> +
> +#ifdef CONFIG_ARM64_MTE_TAG_STORAGE
> +void mte_tag_storage_init(void);
> +#else
> +static inline void mte_tag_storage_init(void)
> +{
> +}
> +#endif /* CONFIG_ARM64_MTE_TAG_STORAGE */
> +#endif /* __ASM_MTE_TAG_STORAGE_H  */
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index d95b3d6b471a..5f031bf9f8f1 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -70,6 +70,7 @@ obj-$(CONFIG_CRASH_CORE)              += crash_core.o
>  obj-$(CONFIG_ARM_SDE_INTERFACE)                += sdei.o
>  obj-$(CONFIG_ARM64_PTR_AUTH)           += pointer_auth.o
>  obj-$(CONFIG_ARM64_MTE)                        += mte.o
> +obj-$(CONFIG_ARM64_MTE_TAG_STORAGE)    += mte_tag_storage.o
>  obj-y                                  += vdso-wrap.o
>  obj-$(CONFIG_COMPAT_VDSO)              += vdso32-wrap.o
>  obj-$(CONFIG_UNWIND_PATCH_PAC_INTO_SCS)        += patch-scs.o
> diff --git a/arch/arm64/kernel/mte_tag_storage.c b/arch/arm64/kernel/mte_tag_storage.c
> new file mode 100644
> index 000000000000..fa6267ef8392
> --- /dev/null
> +++ b/arch/arm64/kernel/mte_tag_storage.c
> @@ -0,0 +1,256 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Support for dynamic tag storage.
> + *
> + * Copyright (C) 2023 ARM Ltd.
> + */
> +
> +#include <linux/memblock.h>
> +#include <linux/mm.h>
> +#include <linux/of_device.h>

You probably don't need this header. If you depend on what it
implicitly includes, then that will now break in linux-next.

> +#include <linux/of_fdt.h>
> +#include <linux/range.h>
> +#include <linux/string.h>
> +#include <linux/xarray.h>
> +
> +#include <asm/mte_tag_storage.h>
> +
> +struct tag_region {
> +       struct range mem_range; /* Memory associated with the tag storage, in PFNs. */
> +       struct range tag_range; /* Tag storage memory, in PFNs. */
> +       u32 block_size;         /* Tag block size, in pages. */
> +};
> +
> +#define MAX_TAG_REGIONS        32
> +
> +static struct tag_region tag_regions[MAX_TAG_REGIONS];
> +static int num_tag_regions;
> +
> +static int __init tag_storage_of_flat_get_range(unsigned long node, const __be32 *reg,
> +                                               int reg_len, struct range *range)
> +{
> +       int addr_cells = dt_root_addr_cells;
> +       int size_cells = dt_root_size_cells;
> +       u64 size;
> +
> +       if (reg_len / 4 > addr_cells + size_cells)
> +               return -EINVAL;
> +
> +       range->start = PHYS_PFN(of_read_number(reg, addr_cells));
> +       size = PHYS_PFN(of_read_number(reg + addr_cells, size_cells));
> +       if (size == 0) {
> +               pr_err("Invalid node");
> +               return -EINVAL;
> +       }
> +       range->end = range->start + size - 1;

We have a function to read (and translate which you forgot) addresses.
Add what's missing rather than open code your own.

> +
> +       return 0;
> +}
> +
> +static int __init tag_storage_of_flat_get_tag_range(unsigned long node,
> +                                                   struct range *tag_range)
> +{
> +       const __be32 *reg;
> +       int reg_len;
> +
> +       reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> +       if (reg == NULL) {
> +               pr_err("Invalid metadata node");
> +               return -EINVAL;
> +       }
> +
> +       return tag_storage_of_flat_get_range(node, reg, reg_len, tag_range);
> +}
> +
> +static int __init tag_storage_of_flat_get_memory_range(unsigned long node, struct range *mem)
> +{
> +       const __be32 *reg;
> +       int reg_len;
> +
> +       reg = of_get_flat_dt_prop(node, "linux,usable-memory", &reg_len);
> +       if (reg == NULL)
> +               reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> +
> +       if (reg == NULL) {
> +               pr_err("Invalid memory node");
> +               return -EINVAL;
> +       }
> +
> +       return tag_storage_of_flat_get_range(node, reg, reg_len, mem);
> +}
> +
> +struct find_memory_node_arg {
> +       unsigned long node;
> +       u32 phandle;
> +};
> +
> +static int __init fdt_find_memory_node(unsigned long node, const char *uname,
> +                                      int depth, void *data)
> +{
> +       const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> +       struct find_memory_node_arg *arg = data;
> +
> +       if (depth != 1 || !type || strcmp(type, "memory") != 0)
> +               return 0;
> +
> +       if (of_get_flat_dt_phandle(node) == arg->phandle) {
> +               arg->node = node;
> +               return 1;
> +       }
> +
> +       return 0;
> +}
> +
> +static int __init tag_storage_get_memory_node(unsigned long tag_node, unsigned long *mem_node)
> +{
> +       struct find_memory_node_arg arg = { 0 };
> +       const __be32 *memory_prop;
> +       u32 mem_phandle;
> +       int ret, reg_len;
> +
> +       memory_prop = of_get_flat_dt_prop(tag_node, "memory", &reg_len);
> +       if (!memory_prop) {
> +               pr_err("Missing 'memory' property in the tag storage node");
> +               return -EINVAL;
> +       }
> +
> +       mem_phandle = be32_to_cpup(memory_prop);
> +       arg.phandle = mem_phandle;
> +
> +       ret = of_scan_flat_dt(fdt_find_memory_node, &arg);

Do not use of_scan_flat_dt. It is a relic predating libfdt which can
get a node by phandle directly.

> +       if (ret != 1) {
> +               pr_err("Associated memory node not found");
> +               return -EINVAL;
> +       }
> +
> +       *mem_node = arg.node;
> +
> +       return 0;
> +}
> +
> +static int __init tag_storage_of_flat_read_u32(unsigned long node, const char *propname,
> +                                              u32 *retval)

If you are going to make a generic function, make it for everyone.

> +{
> +       const __be32 *reg;
> +
> +       reg = of_get_flat_dt_prop(node, propname, NULL);
> +       if (!reg)
> +               return -EINVAL;
> +
> +       *retval = be32_to_cpup(reg);
> +       return 0;
> +}
> +
> +static u32 __init get_block_size_pages(u32 block_size_bytes)
> +{
> +       u32 a = PAGE_SIZE;
> +       u32 b = block_size_bytes;
> +       u32 r;
> +
> +       /* Find greatest common divisor using the Euclidian algorithm. */
> +       do {
> +               r = a % b;
> +               a = b;
> +               b = r;
> +       } while (b != 0);
> +
> +       return PHYS_PFN(PAGE_SIZE * block_size_bytes / a);
> +}
> +
> +static int __init fdt_init_tag_storage(unsigned long node, const char *uname,
> +                                      int depth, void *data)
> +{
> +       struct tag_region *region;
> +       unsigned long mem_node;
> +       struct range *mem_range;
> +       struct range *tag_range;
> +       u32 block_size_bytes;
> +       u32 nid = 0;
> +       int ret;
> +
> +       if (depth != 1 || !strstr(uname, "tag-storage"))
> +               return 0;
> +
> +       if (!of_flat_dt_is_compatible(node, "arm,mte-tag-storage"))
> +               return 0;
> +
> +       if (num_tag_regions == MAX_TAG_REGIONS) {
> +               pr_err("Maximum number of tag storage regions exceeded");
> +               return -EINVAL;
> +       }
> +
> +       region = &tag_regions[num_tag_regions];
> +       mem_range = &region->mem_range;
> +       tag_range = &region->tag_range;
> +
> +       ret = tag_storage_of_flat_get_tag_range(node, tag_range);
> +       if (ret) {
> +               pr_err("Invalid tag storage node");
> +               return ret;
> +       }
> +
> +       ret = tag_storage_get_memory_node(node, &mem_node);
> +       if (ret)
> +               return ret;
> +
> +       ret = tag_storage_of_flat_get_memory_range(mem_node, mem_range);
> +       if (ret) {
> +               pr_err("Invalid address for associated data memory node");
> +               return ret;
> +       }
> +
> +       /* The tag region must exactly match the corresponding memory. */
> +       if (range_len(tag_range) * 32 != range_len(mem_range)) {
> +               pr_err("Tag storage region 0x%llx-0x%llx does not cover the memory region 0x%llx-0x%llx",
> +                      PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->end),
> +                      PFN_PHYS(mem_range->start), PFN_PHYS(mem_range->end));
> +               return -EINVAL;
> +       }
> +
> +       ret = tag_storage_of_flat_read_u32(node, "block-size", &block_size_bytes);
> +       if (ret || block_size_bytes == 0) {
> +               pr_err("Invalid or missing 'block-size' property");
> +               return -EINVAL;
> +       }
> +       region->block_size = get_block_size_pages(block_size_bytes);
> +       if (range_len(tag_range) % region->block_size != 0) {
> +               pr_err("Tag storage region size 0x%llx is not a multiple of block size %u",
> +                      PFN_PHYS(range_len(tag_range)), region->block_size);
> +               return -EINVAL;
> +       }
> +
> +       ret = tag_storage_of_flat_read_u32(mem_node, "numa-node-id", &nid);

I was going to say we already have a way to associate memory nodes
other nodes using "numa-node-id", so the "memory" phandle property is
somewhat redundant. Maybe the tag node should have a numa-node-id.
With that, it looks like you don't even need to access the /memory
node. Avoiding that would be good for 2 reasons. It avoids parsing
memory nodes twice and it's not the kernel's job to validate the DT.
Really, if you want memory info, you should use memblock to get it
because all the special cases of memory layout are handled. For
example you can have memory nodes with multiple 'reg' entries or
multiple memory nodes or both, and then some of those could be
contiguous.

Rob


From robh+dt at kernel.org  Mon Dec 11 09:36:41 2023
From: robh+dt at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 11:36:41 -0600
Subject: [PATCH v4 4/4] clk: mediatek: add drivers for MT7988 SoC
In-Reply-To: <879b5bbcb165aa3f059a41218142b27e5f64597f.1702158423.git.daniel@makrotopia.org>
References: <097e82b0d66570763d64be1715517d8b032fcf95.1702158423.git.daniel@makrotopia.org>
 <879b5bbcb165aa3f059a41218142b27e5f64597f.1702158423.git.daniel@makrotopia.org>
Message-ID: <CAL_JsqJVY3-UneaoUNt6aGa2kU_3EVAwxJfY_mYZPyp=L=Bjtw@mail.gmail.com>

On Sat, Dec 9, 2023 at 3:56?PM Daniel Golle <daniel at makrotopia.org> wrote:
>
> From: Sam Shih <sam.shih at mediatek.com>
>
> Add APMIXED, ETH, INFRACFG and TOPCKGEN clock drivers which are
> typical MediaTek designs.
>
> Also add driver for XFIPLL clock generating the 156.25MHz clock for
> the XFI SerDes. It needs an undocumented software workaround and has
> an unknown internal design.
>
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
> v4:
>  * make use of existing GATE_MTK_FLAGS macro
>  * reformat to max. 100 columns
>  * cosmetics
>
> v3: use git --from ...
> v2: no changes
>
>
>  drivers/clk/mediatek/Kconfig               |   9 +
>  drivers/clk/mediatek/Makefile              |   5 +
>  drivers/clk/mediatek/clk-mt7988-apmixed.c  | 102 +++++++
>  drivers/clk/mediatek/clk-mt7988-eth.c      | 133 +++++++++
>  drivers/clk/mediatek/clk-mt7988-infracfg.c | 274 +++++++++++++++++
>  drivers/clk/mediatek/clk-mt7988-topckgen.c | 325 +++++++++++++++++++++
>  drivers/clk/mediatek/clk-mt7988-xfipll.c   |  78 +++++
>  7 files changed, 926 insertions(+)
>  create mode 100644 drivers/clk/mediatek/clk-mt7988-apmixed.c
>  create mode 100644 drivers/clk/mediatek/clk-mt7988-eth.c
>  create mode 100644 drivers/clk/mediatek/clk-mt7988-infracfg.c
>  create mode 100644 drivers/clk/mediatek/clk-mt7988-topckgen.c
>  create mode 100644 drivers/clk/mediatek/clk-mt7988-xfipll.c
>
> diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> index 48b42d11111cd..70a005e7e1b18 100644
> --- a/drivers/clk/mediatek/Kconfig
> +++ b/drivers/clk/mediatek/Kconfig
> @@ -423,6 +423,15 @@ config COMMON_CLK_MT7986_ETHSYS
>           This driver adds support for clocks for Ethernet and SGMII
>           required on MediaTek MT7986 SoC.
>
> +config COMMON_CLK_MT7988
> +       tristate "Clock driver for MediaTek MT7988"
> +       depends on ARCH_MEDIATEK || COMPILE_TEST
> +       select COMMON_CLK_MEDIATEK
> +       default ARCH_MEDIATEK
> +       help
> +         This driver supports MediaTek MT7988 basic clocks and clocks
> +         required for various periperals found on this SoC.
> +
>  config COMMON_CLK_MT8135
>         tristate "Clock driver for MediaTek MT8135"
>         depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index dbeaa5b41177d..eeccfa039896f 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -62,6 +62,11 @@ obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-apmixed.o
>  obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-topckgen.o
>  obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-infracfg.o
>  obj-$(CONFIG_COMMON_CLK_MT7986_ETHSYS) += clk-mt7986-eth.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-apmixed.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-topckgen.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-infracfg.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-eth.o
> +obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-xfipll.o
>  obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135-apmixedsys.o clk-mt8135.o
>  obj-$(CONFIG_COMMON_CLK_MT8167) += clk-mt8167-apmixedsys.o clk-mt8167.o
>  obj-$(CONFIG_COMMON_CLK_MT8167_AUDSYS) += clk-mt8167-aud.o
> diff --git a/drivers/clk/mediatek/clk-mt7988-apmixed.c b/drivers/clk/mediatek/clk-mt7988-apmixed.c
> new file mode 100644
> index 0000000000000..02eb6354b01a8
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt7988-apmixed.c
> @@ -0,0 +1,102 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2023 MediaTek Inc.
> + * Author: Sam Shih <sam.shih at mediatek.com>
> + * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>

> +#include <linux/of_address.h>
> +#include <linux/of_device.h>

You probably don't need these 2 headers and the implicit includes
of_device.h makes are dropped now in linux-next. Please check what you
actually need and make them explicit.

Rob


From robh+dt at kernel.org  Mon Dec 11 09:37:46 2023
From: robh+dt at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 11:37:46 -0600
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <20230920171009.3193296-2-l.stach@pengutronix.de>
References: <20230920171009.3193296-1-l.stach@pengutronix.de> <20230920171009.3193296-2-l.stach@pengutronix.de>
Message-ID: <CAL_JsqJmyeFNpRt9bkjzXJ+w3WED4eLokmzdfP4fR=9dZGr1QA@mail.gmail.com>

On Wed, Sep 20, 2023 at 12:10?PM Lucas Stach <l.stach at pengutronix.de> wrote:
>
> This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> full timing generator and can switch between different video sources. On
> the i.MX8MP however the only supported source is the LCDIF. The block
> just needs to be powered up and told about the polarity of the video
> sync signals to act in bypass mode.
>
> Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
> Reviewed-by: Luca Ceresoli <luca.ceresoli at bootlin.com> (v2)
> Tested-by: Marek Vasut <marex at denx.de> (v1)
> Tested-by: Luca Ceresoli <luca.ceresoli at bootlin.com> (v2)
> Tested-by: Richard Leitner <richard.leitner at skidata.com> (v2)
> Tested-by: Frieder Schrempf <frieder.schrempf at kontron.de> (v2)
> ---
>  drivers/gpu/drm/bridge/imx/Kconfig           |   7 +
>  drivers/gpu/drm/bridge/imx/Makefile          |   1 +
>  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 206 +++++++++++++++++++
>  3 files changed, 214 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig b/drivers/gpu/drm/bridge/imx/Kconfig
> index 9fae28db6aa7..3a4e663d922a 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
>  config DRM_IMX_LDB_HELPER
>         tristate
>
> +config DRM_IMX8MP_HDMI_PVI
> +       tristate "Freescale i.MX8MP HDMI PVI bridge support"
> +       depends on OF
> +       help
> +         Choose this to enable support for the internal HDMI TX Parallel
> +         Video Interface found on the Freescale i.MX8MP SoC.
> +
>  config DRM_IMX8QM_LDB
>         tristate "Freescale i.MX8QM LVDS display bridge"
>         depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile b/drivers/gpu/drm/bridge/imx/Makefile
> index 8e2ebf3399a1..be9b4f9adb50 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
> +obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
>  obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
>  obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
>  obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> new file mode 100644
> index 000000000000..5ccd70c98187
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> @@ -0,0 +1,206 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright (C) 2022 Pengutronix, Lucas Stach <kernel at pengutronix.de>
> + */
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_crtc.h>
> +#include <linux/bitfield.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>

You probably don't need this header and the implicit includes it makes
are dropped now in linux-next. Please check what you actually need and
make them explicit.

Rob


From robh+dt at kernel.org  Mon Dec 11 09:54:25 2023
From: robh+dt at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 11:54:25 -0600
Subject: [PATCH v4 1/2] perf: starfive: Add StarLink PMU support
In-Reply-To: <20231116162330.1144983-2-jisheng.teoh@starfivetech.com>
References: <20231116162330.1144983-1-jisheng.teoh@starfivetech.com> <20231116162330.1144983-2-jisheng.teoh@starfivetech.com>
Message-ID: <CAL_Jsq+AMbwR64YwtugJ=WC-No0eBUejf3v4YbSB8h7x+uf3wA@mail.gmail.com>

On Thu, Nov 16, 2023 at 10:24?AM Ji Sheng Teoh
<jisheng.teoh at starfivetech.com> wrote:
>
> This patch adds support for StarFive's StarLink PMU (Performance
> Monitor Unit). StarLink PMU integrates one or more CPU cores with
> a shared L3 memory system. The PMU supports overflow interrupt,
> up to 16 programmable 64bit event counters, and an independent
> 64bit cycle counter. StarLink PMU is accessed via MMIO.
>
> Example Perf stat output:
> [root at user]# perf stat -a -e /starfive_starlink_pmu/cycles/ \
>         -e /starfive_starlink_pmu/read_miss/ \
>         -e /starfive_starlink_pmu/read_hit/ \
>         -e /starfive_starlink_pmu/release_request/  \
>         -e /starfive_starlink_pmu/write_hit/ \
>         -e /starfive_starlink_pmu/write_miss/ \
>         -e /starfive_starlink_pmu/write_request/ \
>         -e /starfive_starlink_pmu/writeback/ \
>         -e /starfive_starlink_pmu/read_request/ \
>         -- openssl speed rsa2048
> Doing 2048 bits private rsa's for 10s: 5 2048 bits private RSA's in
> 2.84s
> Doing 2048 bits public rsa's for 10s: 169 2048 bits public RSA's in
> 2.42s
> version: 3.0.11
> built on: Tue Sep 19 13:02:31 2023 UTC
> options: bn(64,64)
> CPUINFO: N/A
>                   sign    verify    sign/s verify/s
> rsa 2048 bits 0.568000s 0.014320s      1.8     69.8
> /////////
>  Performance counter stats for 'system wide':
>
>          649991998      starfive_starlink_pmu/cycles/
>            1009690      starfive_starlink_pmu/read_miss/
>            1079750      starfive_starlink_pmu/read_hit/
>            2089405      starfive_starlink_pmu/release_request/
>                129      starfive_starlink_pmu/write_hit/
>                 70      starfive_starlink_pmu/write_miss/
>                194      starfive_starlink_pmu/write_request/
>             150080      starfive_starlink_pmu/writeback/
>            2089423      starfive_starlink_pmu/read_request/
>
>       27.062755678 seconds time elapsed
>
> Signed-off-by: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
> ---
>  drivers/perf/Kconfig                 |   9 +
>  drivers/perf/Makefile                |   1 +
>  drivers/perf/starfive_starlink_pmu.c | 654 +++++++++++++++++++++++++++
>  include/linux/cpuhotplug.h           |   1 +
>  4 files changed, 665 insertions(+)
>  create mode 100644 drivers/perf/starfive_starlink_pmu.c
>
> diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
> index 273d67ecf6d2..41278742ef88 100644
> --- a/drivers/perf/Kconfig
> +++ b/drivers/perf/Kconfig
> @@ -86,6 +86,15 @@ config RISCV_PMU_SBI
>           full perf feature support i.e. counter overflow, privilege mode
>           filtering, counter configuration.
>
> +config STARFIVE_STARLINK_PMU
> +       depends on ARCH_STARFIVE
> +       bool "StarFive StarLink PMU"
> +       help
> +          Provide support for StarLink Performance Monitor Unit.
> +          StarLink Performance Monitor Unit integrates one or more cores with
> +          an L3 memory system. The L3 cache events are added into perf event
> +          subsystem, allowing monitoring of various L3 cache perf events.
> +
>  config ARM_PMU_ACPI
>         depends on ARM_PMU && ACPI
>         def_bool y
> diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
> index 16b3ec4db916..e2153aee1e04 100644
> --- a/drivers/perf/Makefile
> +++ b/drivers/perf/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
>  obj-$(CONFIG_RISCV_PMU) += riscv_pmu.o
>  obj-$(CONFIG_RISCV_PMU_LEGACY) += riscv_pmu_legacy.o
>  obj-$(CONFIG_RISCV_PMU_SBI) += riscv_pmu_sbi.o
> +obj-$(CONFIG_STARFIVE_STARLINK_PMU) += starfive_starlink_pmu.o
>  obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
>  obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
>  obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
> diff --git a/drivers/perf/starfive_starlink_pmu.c b/drivers/perf/starfive_starlink_pmu.c
> new file mode 100644
> index 000000000000..272896ab1ade
> --- /dev/null
> +++ b/drivers/perf/starfive_starlink_pmu.c
> @@ -0,0 +1,654 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * StarFive's StarLink PMU driver
> + *
> + * Copyright (C) 2023 StarFive Technology Co., Ltd.
> + *
> + * Author: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
> + *
> + */
> +
> +#define STARLINK_PMU_PDEV_NAME "starfive_starlink_pmu"
> +#define pr_fmt(fmt)    STARLINK_PMU_PDEV_NAME ": " fmt
> +
> +#include <linux/bitmap.h>
> +#include <linux/cpu_pm.h>
> +#include <linux/io.h>
> +#include <linux/irq.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>

You probably don't need this header and the implicit includes it makes
are dropped now in linux-next. Please check what you actually need and
make them explicit.

Rob


From jgg at nvidia.com  Mon Dec 11 10:03:24 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Mon, 11 Dec 2023 14:03:24 -0400
Subject: [PATCH v3 00/19] Update SMMUv3 to the modern iommu API (part 1/3)
In-Reply-To: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <20231211180324.GA3012960@nvidia.com>

On Tue, Dec 05, 2023 at 03:14:32PM -0400, Jason Gunthorpe wrote:
> All parts are on github:
> 
>  https://github.com/jgunthorpe/linux/commits/smmuv3_newapi
> 
> v3:
>  - Use some local variables in arm_smmu_get_step_for_sid() for clarity
>  - White space and spelling changes
>  - Commit message updates
>  - Keep master->domain_head initialized to avoid a list_del corruption
> v2: https://lore.kernel.org/r/0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg at nvidia.com
>  - Rebased on v6.7-rc1
>  - Improve the comment for arm_smmu_write_entry_step()
>  - Fix the botched memcmp
>  - Document the spec justification for the SHCFG exclusion in used
>  - Include STRTAB_STE_1_SHCFG for STRTAB_STE_0_CFG_S2_TRANS in used
>  - WARN_ON for unknown STEs in used
>  - Fix error unwind in arm_smmu_attach_dev()
>  - Whitespace, spelling, and checkpatch related items
> v1: https://lore.kernel.org/r/0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg at nvidia.com

This hasn't changed significantly in the last three months, so I feel
done now. I think Eric may still have a formal Tested-by for his
Fujitsu system to record the run he did.

Will, we are waiting for you to say something so we can shift review
and testing focus to part 2, ideally in January. Many people are
waiting for this.

Thanks,
Jason


From kan.liang at linux.intel.com  Mon Dec 11 10:09:34 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Mon, 11 Dec 2023 13:09:34 -0500
Subject: [PATCH V2 2/5] perf mem: Clean up perf_mem_events__ptr()
In-Reply-To: <20231209043135.GA2116834@leoy-yangtze.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-3-kan.liang@linux.intel.com>
 <20231209043135.GA2116834@leoy-yangtze.lan>
Message-ID: <2a3caf68-3a84-4963-aa61-3063d12c4c2a@linux.intel.com>



On 2023-12-08 11:31 p.m., Leo Yan wrote:
> On Thu, Dec 07, 2023 at 11:23:35AM -0800, kan.liang at linux.intel.com wrote:
>> From: Kan Liang <kan.liang at linux.intel.com>
>>
>> The mem_events can be retrieved from the struct perf_pmu now. An ARCH
>> specific perf_mem_events__ptr() is not required anymore. Remove all of
>> them.
>>
>> The Intel hybrid has multiple mem-events-supported PMUs. But they share
>> the same mem_events. Other ARCHs only support one mem-events-supported
>> PMU. In the configuration, it's good enough to only configure the
>> mem_events for one PMU. Add perf_mem_events_find_pmu() which returns the
>> first mem-events-supported PMU.
>>
>> In the perf_mem_events__init(), the perf_pmus__scan() is not required
>> anymore. It avoids checking the sysfs for every PMU on the system.
>>
>> Make the perf_mem_events__record_args() more generic. Remove the
>> perf_mem_events__print_unsupport_hybrid().
>>
>> Since pmu is added as a new parameter, rename perf_mem_events__ptr() to
>> perf_pmu__mem_events_ptr(). Several other functions also do a similar
>> rename.
>>
>> Reviewed-by: Ian Rogers <irogers at google.com>
>> Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
>> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
>> ---
>>  tools/perf/arch/arm64/util/mem-events.c |  10 +--
>>  tools/perf/arch/x86/util/mem-events.c   |  18 ++---
>>  tools/perf/builtin-c2c.c                |  28 +++++--
>>  tools/perf/builtin-mem.c                |  28 +++++--
>>  tools/perf/util/mem-events.c            | 103 ++++++++++++------------
>>  tools/perf/util/mem-events.h            |   9 ++-
>>  6 files changed, 104 insertions(+), 92 deletions(-)
>>
>> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
>> index aaa4804922b4..2602e8688727 100644
>> --- a/tools/perf/arch/arm64/util/mem-events.c
>> +++ b/tools/perf/arch/arm64/util/mem-events.c
>> @@ -12,17 +12,9 @@ struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
>>  
>>  static char mem_ev_name[100];
>>  
>> -struct perf_mem_event *perf_mem_events__ptr(int i)
>> -{
>> -	if (i >= PERF_MEM_EVENTS__MAX)
>> -		return NULL;
>> -
>> -	return &perf_mem_events_arm[i];
>> -}
>> -
>>  const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
>>  {
>> -	struct perf_mem_event *e = perf_mem_events__ptr(i);
>> +	struct perf_mem_event *e = &perf_mem_events_arm[i];
>>  
>>  	if (i >= PERF_MEM_EVENTS__MAX)
>>  		return NULL;
> 
> Nitpick: it's good to check if 'i' is a valid value and then access the
> array with a valid index.
> 
>         if (i >= PERF_MEM_EVENTS__MAX)
>                 return NULL;
> 
>         e = &perf_mem_events_arm[i];
> 
>> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
>> index 2b81d229982c..5fb41d50118d 100644
>> --- a/tools/perf/arch/x86/util/mem-events.c
>> +++ b/tools/perf/arch/x86/util/mem-events.c
>> @@ -28,17 +28,6 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
>>  	E("mem-ldst",	"ibs_op//",	"ibs_op"),
>>  };
>>  
>> -struct perf_mem_event *perf_mem_events__ptr(int i)
>> -{
>> -	if (i >= PERF_MEM_EVENTS__MAX)
>> -		return NULL;
>> -
>> -	if (x86__is_amd_cpu())
>> -		return &perf_mem_events_amd[i];
>> -
>> -	return &perf_mem_events_intel[i];
>> -}
>> -
>>  bool is_mem_loads_aux_event(struct evsel *leader)
>>  {
>>  	struct perf_pmu *pmu = perf_pmus__find("cpu");
>> @@ -54,7 +43,12 @@ bool is_mem_loads_aux_event(struct evsel *leader)
>>  
>>  const char *perf_mem_events__name(int i, const char *pmu_name)
>>  {
>> -	struct perf_mem_event *e = perf_mem_events__ptr(i);
>> +	struct perf_mem_event *e;
> 
> A nitpick as well:
> 
> Given perf's mem/c2c, callers will almostly invoke a valid index via the
> argument 'i', but I still think here is a best place to return NULL
> pointer for an invalid index rather than returning a wild pointer.
> 
> Thus I suggest to apply checking for x86 and other archs:
> 
>         if (i >= PERF_MEM_EVENTS__MAX)
>                 return NULL;
> 
>> +
>> +	if (x86__is_amd_cpu())
>> +		e = &perf_mem_events_amd[i];
>> +	else
>> +		e = &perf_mem_events_intel[i];
>>  
>>  	if (!e)
>>  		return NULL;
> 
> [...]
> 
>>  int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
>>  				 char **rec_tmp, int *tmp_nr)
>>  {
>>  	const char *mnt = sysfs__mount();
>> +	struct perf_pmu *pmu = NULL;
>>  	int i = *argv_nr, k = 0;
>>  	struct perf_mem_event *e;
>>  
>> -	for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
>> -		e = perf_mem_events__ptr(j);
>> -		if (!e->record)
>> -			continue;
>>  
>> -		if (perf_pmus__num_mem_pmus() == 1) {
>> -			if (!e->supported) {
>> -				pr_err("failed: event '%s' not supported\n",
>> -				       perf_mem_events__name(j, NULL));
>> -				return -1;
>> -			}
>> +	while ((pmu = perf_pmus__scan_mem(pmu)) != NULL) {
>> +		for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
>> +			e = perf_pmu__mem_events_ptr(pmu, j);
>>  
>> -			rec_argv[i++] = "-e";
>> -			rec_argv[i++] = perf_mem_events__name(j, NULL);
>> -		} else {
>> -			struct perf_pmu *pmu = NULL;
>> +			if (!e->record)
>> +				continue;
>>  
>>  			if (!e->supported) {
>> -				perf_mem_events__print_unsupport_hybrid(e, j);
>> +				pr_err("failed: event '%s' not supported\n",
>> +					perf_mem_events__name(j, pmu->name));
>>  				return -1;
>>  			}
>>  
>> -			while ((pmu = perf_pmus__scan(pmu)) != NULL) {
>> +			if (perf_pmus__num_mem_pmus() == 1) {
>> +				rec_argv[i++] = "-e";
>> +				rec_argv[i++] = perf_mem_events__name(j, NULL);
>> +			} else {
>>  				const char *s = perf_mem_events__name(j, pmu->name);
>>  
>>  				if (!perf_mem_event__supported(mnt, pmu, e))
> 
> I think we can improve a bit for this part.
> 
> Current implementation uses perf_pmus__num_mem_pmus() to decide if
> system has only one memory PMU or multiple PMUs, and multiple PMUs
> the tool iterates all memory PMUs to synthesize event options.
> 
> In this patch, it has changed to iterate all memory PMUs, no matter the
> system has only one memory PMU or multiple PMUs. Thus, I don't see the
> point for the condition checking for "perf_pmus__num_mem_pmus() == 1".
> We can consolidate into the unified code like:

Yep, I think it's doable. Also, it seems we can further clean up the
perf_pmus__num_mem_pmus(), which is a __weak function now.

It seems we just need to change the perf_mem_events_find_pmu() a little
bit and let it give both the first mem_events_pmu and the number of
mem_pmus.
> 
>         char *copy;
>         const char *s = perf_pmu__mem_events_name(j, pmu);
> 
>         if (!s)
>                 continue;
> 
>         if (!perf_pmu__mem_events_supported(mnt, pmu, e))
>                 continue;
> 
>         copy = strdup(s);
>         if (!copy)
>                 return -1;
> 
>         rec_argv[i++] = "-e";
>         rec_argv[i++] = copy;
>         rec_tmp[k++] = copy;

Not sure what's the rec_tmp for. It seems no one use it.
I will try if it can be removed.

Thanks,
Kan

> 
> Thanks,
> Leo


From will at kernel.org  Mon Dec 11 10:15:30 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 18:15:30 +0000
Subject: [PATCH v3 00/19] Update SMMUv3 to the modern iommu API (part 1/3)
In-Reply-To: <20231211180324.GA3012960@nvidia.com>
References: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
 <20231211180324.GA3012960@nvidia.com>
Message-ID: <20231211181529.GA26462@willie-the-truck>

On Mon, Dec 11, 2023 at 02:03:24PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 05, 2023 at 03:14:32PM -0400, Jason Gunthorpe wrote:
> > All parts are on github:
> > 
> >  https://github.com/jgunthorpe/linux/commits/smmuv3_newapi
> > 
> > v3:
> >  - Use some local variables in arm_smmu_get_step_for_sid() for clarity
> >  - White space and spelling changes
> >  - Commit message updates
> >  - Keep master->domain_head initialized to avoid a list_del corruption
> > v2: https://lore.kernel.org/r/0-v2-de8b10590bf5+400-smmuv3_newapi_p1_jgg at nvidia.com
> >  - Rebased on v6.7-rc1
> >  - Improve the comment for arm_smmu_write_entry_step()
> >  - Fix the botched memcmp
> >  - Document the spec justification for the SHCFG exclusion in used
> >  - Include STRTAB_STE_1_SHCFG for STRTAB_STE_0_CFG_S2_TRANS in used
> >  - WARN_ON for unknown STEs in used
> >  - Fix error unwind in arm_smmu_attach_dev()
> >  - Whitespace, spelling, and checkpatch related items
> > v1: https://lore.kernel.org/r/0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg at nvidia.com
> 
> This hasn't changed significantly in the last three months, so I feel
> done now. I think Eric may still have a formal Tested-by for his
> Fujitsu system to record the run he did.
> 
> Will, we are waiting for you to say something so we can shift review
> and testing focus to part 2, ideally in January. Many people are
> waiting for this.

I'm sorry that you're waiting for me, but I'm snowed under with other
changes and the arm64 tree is my priority at the moment. This series _is_ on
my list and I appreciate that you've got some review, however the fact that
you seem to be lacking any comments from the usual SMMU folks such as Robin
and Jean-Philippe does make me worry about this series to the point that I'm
not prepared just to pick it up without a thorough look.

It sucks, but I don't know what else to tell you.

Will


From catalin.marinas at arm.com  Mon Dec 11 10:18:17 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 11 Dec 2023 18:18:17 +0000
Subject: [PATCH v3 12/25] arm64: handle PKEY/POE faults
In-Reply-To: <20231124163510.1835740-13-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-13-joey.gouly@arm.com>
Message-ID: <ZXdSaRIJGWrtXin-@arm.com>

On Fri, Nov 24, 2023 at 04:34:57PM +0000, Joey Gouly wrote:
> @@ -497,6 +498,23 @@ static void do_bad_area(unsigned long far, unsigned long esr,
>  #define VM_FAULT_BADMAP		((__force vm_fault_t)0x010000)
>  #define VM_FAULT_BADACCESS	((__force vm_fault_t)0x020000)
>  
> +static bool fault_from_pkey(unsigned long esr, struct vm_area_struct *vma,
> +			unsigned int mm_flags)
> +{
> +	unsigned long iss2 = ESR_ELx_ISS2(esr);
> +
> +	if (!arch_pkeys_enabled())
> +		return false;
> +
> +	if (iss2 & ESR_ELx_Overlay)
> +		return true;
> +
> +	return !arch_vma_access_permitted(vma,
> +			mm_flags & FAULT_FLAG_WRITE,
> +			mm_flags & FAULT_FLAG_INSTRUCTION,
> +			mm_flags & FAULT_FLAG_REMOTE);
> +}

Do we actually need this additional arch_vma_access_permitted() check?
The ESR should tell us if it was a POE fault. Permission overlay faults
have priority over the base permission faults, so we'd not need to fall
back to this additional checks. Well, see below, we could do something
slightly smarter here.

I can see x86 and powerpc have similar checks (though at a different
point under the mmap lock) but I'm not familiar with their exception
model, exception priorities.

> +
>  static vm_fault_t __do_page_fault(struct mm_struct *mm,
>  				  struct vm_area_struct *vma, unsigned long addr,
>  				  unsigned int mm_flags, unsigned long vm_flags,
> @@ -688,9 +706,29 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
>  		 * Something tried to access memory that isn't in our memory
>  		 * map.
>  		 */
> -		arm64_force_sig_fault(SIGSEGV,
> -				      fault == VM_FAULT_BADACCESS ? SEGV_ACCERR : SEGV_MAPERR,
> -				      far, inf->name);
> +		int fault_kind;
> +		/*
> +		 * The pkey value that we return to userspace can be different
> +		 * from the pkey that caused the fault.
> +		 *
> +		 * 1. T1   : mprotect_key(foo, PAGE_SIZE, pkey=4);
> +		 * 2. T1   : set AMR to deny access to pkey=4, touches, page
> +		 * 3. T1   : faults...
> +		 * 4.    T2: mprotect_key(foo, PAGE_SIZE, pkey=5);
> +		 * 5. T1   : enters fault handler, takes mmap_lock, etc...
> +		 * 6. T1   : reaches here, sees vma_pkey(vma)=5, when we really
> +		 *	     faulted on a pte with its pkey=4.
> +		 */
> +		int pkey = vma_pkey(vma);

Other than the vma_pkey() race, I'm more worried about the vma
completely disappearing, e.g. munmap() in another thread. We end up
dereferencing a free pointer here. We need to do this under the mmap
lock.

Since we need to do this check under the mmap lock, we could add an
additional check to see if the pkey fault we got was a racy and just
restart the instruction if it no longer faults according to
por_el0_allows_pkey(). However, the code below is too late in the fault
handling to be able to do much other than SIGSEGV.

> +
> +		if (fault_from_pkey(esr, vma, mm_flags))
> +			fault_kind = SEGV_PKUERR;
> +		else
> +			fault_kind = fault == VM_FAULT_BADACCESS ? SEGV_ACCERR : SEGV_MAPERR;
> +
> +		arm64_force_sig_fault_pkey(SIGSEGV,
> +				      fault_kind,
> +				      far, inf->name, pkey);
>  	}
>  
>  	return 0;

-- 
Catalin


From catalin.marinas at arm.com  Mon Dec 11 10:22:30 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 11 Dec 2023 18:22:30 +0000
Subject: [PATCH v3 13/25] arm64: stop using generic mm_hooks.h
In-Reply-To: <20231124163510.1835740-14-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-14-joey.gouly@arm.com>
Message-ID: <ZXdTZvw0pOEShcLQ@arm.com>

On Fri, Nov 24, 2023 at 04:34:58PM +0000, Joey Gouly wrote:
> These functions will be extended to support pkeys.
> 
> Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>

Nit: can you squash it into patch 14 introducing those functions? Less
patches to carry.


From robh at kernel.org  Mon Dec 11 10:26:36 2023
From: robh at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 12:26:36 -0600
Subject: [PATCH v5 09/20] dt-bindings: serial: samsung: Make
 samsung,uart-fifosize required property
In-Reply-To: <59b949a0-5aeb-4f01-8789-cb305513b626@app.fastmail.com>
References: <20231201160925.3136868-1-peter.griffin@linaro.org>
 <20231201160925.3136868-10-peter.griffin@linaro.org>
 <59b949a0-5aeb-4f01-8789-cb305513b626@app.fastmail.com>
Message-ID: <20231211182636.GA2657319-robh@kernel.org>

On Fri, Dec 01, 2023 at 05:39:33PM +0100, Arnd Bergmann wrote:
> On Fri, Dec 1, 2023, at 17:09, Peter Griffin wrote:
> > 
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - google,gs101-uart
> > +    then:
> > +      required:
> > +        - samsung,uart-fifosize
> > +
> 
> Is there a way to reverse the list and make the property
> required for anything that is not explicitly enumerated?

if:
  properties:
    compatible:
      not: 
        contains:
          enum:
            - optional-compatibles


Either way is fine with me. Anything new has to add their compatible 
anyways, so not a big deal to adjust it here, too.

Rob


From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:32 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:32 +0100
Subject: [PATCH v7 01/13] dt-bindings: document generic access controllers
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-2-gatien.chevallier@foss.st.com>

From: Oleksii Moisieiev <Oleksii_Moisieiev at epam.com>

Introducing of the generic access controllers bindings for the
access controller provider and consumer devices. Those bindings are
intended to allow a better handling of accesses to resources in a
hardware architecture supporting several compartments.

This patch is based on [1]. It is integrated in this patchset as it
provides a use-case for it.

Diffs with [1]:
	- Rename feature-domain* properties to access-control* to narrow
	  down the scope of the binding
	- YAML errors and typos corrected.
	- Example updated
	- Some rephrasing in the binding description

[1]: https://lore.kernel.org/lkml/0c0a82bb-18ae-d057-562b

Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev at epam.com>
Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
	- Renamed access-controller to access-controllers
	- Example updated
	- Removal of access-control-provider property

Changes in V5:
	- Diffs with [1]
	- Discarded the [IGNORE] tag as the patch is now part of the
	  patchset

 .../access-controllers.yaml                   | 84 +++++++++++++++++++
 1 file changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/access-controllers/access-controllers.yaml

diff --git a/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
new file mode 100644
index 000000000000..99e2865f0e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/access-controllers/access-controllers.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Domain Access Controllers
+
+maintainers:
+  - Oleksii Moisieiev <oleksii_moisieiev at epam.com>
+
+description: |+
+  Common access controllers properties
+
+  Access controllers are in charge of stating which of the hardware blocks under
+  their responsibility (their domain) can be accesssed by which compartment. A
+  compartment can be a cluster of CPUs (or coprocessors), a range of addresses
+  or a group of hardware blocks. An access controller's domain is the set of
+  resources covered by the access controller.
+
+  This device tree binding can be used to bind devices to their access
+  controller provided by access-controllers property. In this case, the device
+  is a consumer and the access controller is the provider.
+
+  An access controller can be represented by any node in the device tree and
+  can provide one or more configuration parameters, needed to control parameters
+  of the consumer device. A consumer node can refer to the provider by phandle
+  and a set of phandle arguments, specified by '#access-controller-cells'
+  property in the access controller node.
+
+  Access controllers are typically used to set/read the permissions of a
+  hardware block and grant access to it. Any of which depends on the access
+  controller. The capabilities of each access controller are defined by the
+  binding of the access controller device.
+
+  Each node can be a consumer for the several access controllers.
+
+# always select the core schema
+select: true
+
+properties:
+  "#access-controller-cells":
+    description:
+      Number of cells in an access-controllers specifier;
+      Can be any value as specified by device tree binding documentation
+      of a particular provider. The node is an access controller.
+
+  access-controller-names:
+    $ref: /schemas/types.yaml#/definitions/string-array
+    description:
+      A list of access-controllers names, sorted in the same order as
+      access-controllers entries. Consumer drivers will use
+      access-controller-names to match with existing access-controllers entries.
+
+  access-controllers:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description:
+      A list of access controller specifiers, as defined by the
+      bindings of the access-controllers provider.
+
+additionalProperties: true
+
+examples:
+  - |
+    clock_controller: access-controllers at 50000 {
+        reg = <0x50000 0x400>;
+        #access-controller-cells = <2>;
+    };
+
+    bus_controller: bus at 60000 {
+        reg = <0x60000 0x10000>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+        #access-controller-cells = <3>;
+
+        uart4: serial at 60100 {
+            reg = <0x60100 0x400>;
+            clocks = <&clk_serial>;
+            access-controllers = <&clock_controller 1 2>,
+                                 <&bus_controller 1 3 5>;
+            access-controller-names = "clock", "bus";
+        };
+    };
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:33 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:33 +0100
Subject: [PATCH v7 02/13] dt-bindings: treewide: add access-controllers description
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-3-gatien.chevallier@foss.st.com>

access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).

Description of this property is added to all peripheral binding files of
the peripheral under the STM32 firewall controller. It allows an accurate
representation of the hardware, where various peripherals are connected
to a firewall bus. The firewall can then check the peripheral accesses
before allowing its device to probe.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
	- Minor changes in commit message
	- Renamed access-controller to access-controllers

Changes in V5:
	- Discarded review tags as the content has changed
	- Renamed feature-domains to access-controller

Changes in V4:
	- Added Jonathan's tag for IIO

Changes in V2:
	- Add missing "feature-domains" property declaration
	  in bosch,m_can.yaml and st,stm32-cryp.yaml files

 Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml   | 4 ++++
 Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml   | 4 ++++
 Documentation/devicetree/bindings/dma/st,stm32-dma.yaml       | 4 ++++
 Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml    | 4 ++++
 Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml       | 4 ++++
 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml   | 4 ++++
 .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml       | 4 ++++
 Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml   | 4 ++++
 Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml | 4 ++++
 Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml    | 4 ++++
 .../bindings/memory-controllers/st,stm32-fmc2-ebi.yaml        | 4 ++++
 Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml   | 4 ++++
 Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml    | 4 ++++
 Documentation/devicetree/bindings/mmc/arm,pl18x.yaml          | 4 ++++
 Documentation/devicetree/bindings/net/can/bosch,m_can.yaml    | 4 ++++
 Documentation/devicetree/bindings/net/stm32-dwmac.yaml        | 4 ++++
 Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml  | 4 ++++
 .../devicetree/bindings/regulator/st,stm32-vrefbuf.yaml       | 4 ++++
 Documentation/devicetree/bindings/rng/st,stm32-rng.yaml       | 4 ++++
 Documentation/devicetree/bindings/serial/st,stm32-uart.yaml   | 4 ++++
 Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml     | 4 ++++
 Documentation/devicetree/bindings/sound/st,stm32-sai.yaml     | 4 ++++
 Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml | 4 ++++
 Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml      | 4 ++++
 Documentation/devicetree/bindings/spi/st,stm32-spi.yaml       | 4 ++++
 Documentation/devicetree/bindings/usb/dwc2.yaml               | 4 ++++
 26 files changed, 104 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
index 0ddeb8a9a7a0..27354658d054 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
@@ -46,6 +46,10 @@ properties:
   power-domains:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
index ac480765cde0..822318414095 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
@@ -51,6 +51,10 @@ properties:
   power-domains:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
index 329847ef096a..ff935a0068ec 100644
--- a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
@@ -82,6 +82,10 @@ properties:
     description: if defined, it indicates that the controller
       supports memory-to-memory transfer
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
index e722fbcd8a5f..ddf82bf1e71a 100644
--- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
+++ b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
@@ -28,6 +28,10 @@ properties:
   resets:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
index 94b75d9f66cd..39fad8f7df44 100644
--- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
@@ -99,6 +99,10 @@ properties:
 
   wakeup-source: true
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
index 995cbf8cefc6..ec34c48d4878 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
@@ -93,6 +93,10 @@ properties:
   '#size-cells':
     const: 0
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 allOf:
   - if:
       properties:
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
index 1970503389aa..c1b1324fa132 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
@@ -59,6 +59,10 @@ properties:
       If not, SPI CLKOUT frequency will not be accurate.
     maximum: 20000000
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
index 04045b932bd2..b15de4eb209c 100644
--- a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
@@ -45,6 +45,10 @@ properties:
   '#size-cells':
     const: 0
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 additionalProperties: false
 
 required:
diff --git a/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
index 2314a9a14650..1d930d9e10fd 100644
--- a/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
+++ b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
@@ -29,6 +29,10 @@ properties:
       - const: cec
       - const: hdmi-cec
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index 6b3e413cedb2..34147127192f 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -36,6 +36,10 @@ properties:
   resets:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
   port:
     $ref: /schemas/graph.yaml#/$defs/port-base
     unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
index 14f1833d37c9..deef455bfd21 100644
--- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
@@ -45,6 +45,10 @@ properties:
       Reflects the memory layout with four integer values per bank. Format:
       <bank-number> 0 <address of the bank> <size>
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 patternProperties:
   "^.*@[0-4],[a-f0-9]+$":
     additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
index 27329c5dc38e..d41308856408 100644
--- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
@@ -44,6 +44,10 @@ properties:
 
   wakeup-source: true
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
   pwm:
     type: object
     additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
index f84e09a5743b..b0e438ff4950 100644
--- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
@@ -67,6 +67,10 @@ properties:
   "#size-cells":
     const: 0
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
   pwm:
     type: object
     additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
index 2459a55ed540..5644927be810 100644
--- a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
+++ b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
@@ -79,6 +79,10 @@ properties:
           - const: rx
           - const: tx
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
   power-domains: true
 
   resets:
diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
index f9ffb963d6b1..c4887522e8fe 100644
--- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
+++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
@@ -118,6 +118,10 @@ properties:
   phys:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index fc8c96b08d7d..f2714b5b6cf4 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -93,6 +93,10 @@ properties:
       select RCC clock instead of ETH_REF_CLK.
     type: boolean
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - clocks
diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
index 24a3dbde223b..ceea122ae1a6 100644
--- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
@@ -55,6 +55,10 @@ properties:
     description: number of clock cells for ck_usbo_48m consumer
     const: 0
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 # Required child nodes:
 
 patternProperties:
diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml
index 05f4ad2c7d3a..6ceaffb45dc9 100644
--- a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml
+++ b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml
@@ -30,6 +30,10 @@ properties:
   vdda-supply:
     description: phandle to the vdda input analog voltage.
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
index 717f6b321f88..340d01d481d1 100644
--- a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
@@ -37,6 +37,10 @@ properties:
     description: If set, the RNG configuration in RNG_CR, RNG_HTCR and
                   RNG_NSCR will be locked.
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
index 1df8ffe95fc6..1de03af4ead1 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -70,6 +70,10 @@ properties:
     enum: [1, 2, 4, 8, 12, 14, 16]
     default: 8
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 allOf:
   - $ref: rs485.yaml#
   - $ref: serial.yaml#
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
index b9111d375b93..8978f6bd63e5 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
@@ -65,6 +65,10 @@ properties:
     $ref: audio-graph-port.yaml#
     unevaluatedProperties: false
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - "#sound-dai-cells"
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
index 59df8a832310..b46a4778807d 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
@@ -48,6 +48,10 @@ properties:
   clock-names:
     maxItems: 3
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml
index bc48151b9adb..3dedc81ec12f 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml
@@ -50,6 +50,10 @@ properties:
   resets:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - "#sound-dai-cells"
diff --git a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
index 8bba965a9ae6..3f1a27efff80 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
@@ -46,6 +46,10 @@ properties:
       - const: tx
       - const: rx
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
index ae0f082bd377..0b303bf5c02c 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
@@ -50,6 +50,10 @@ properties:
       - const: rx
       - const: tx
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml
index 0a5c98ea711d..88c077673c8b 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
@@ -172,6 +172,10 @@ properties:
 
   tpl-support: true
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 dependencies:
   port: [ usb-role-switch ]
   role-switch-default-mode: [ usb-role-switch ]
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:34 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:34 +0100
Subject: [PATCH v7 03/13] dt-bindings: bus: document RIFSC
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-4-gatien.chevallier@foss.st.com>

Document RIFSC (RIF security controller). RIFSC is a firewall controller
composed of different kinds of hardware resources.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
	- Renamed access-controller to access-controllers
	- Removal of access-control-provider property
	- Removal of access-controller and access-controller-names
	  declaration in the patternProperties field. Add
	  additionalProperties: true in this field.

Changes in V5:
	- Renamed feature-domain* to access-control*

Changes in V2:
	- Corrected errors highlighted by Rob's robot
	- No longer define the maxItems for the "feature-domains"
	  property
	- Fix example (node name, status)
	- Declare "feature-domain-names" as an optional
	  property for child nodes
	- Fix description of "feature-domains" property

 .../bindings/bus/st,stm32mp25-rifsc.yaml      | 96 +++++++++++++++++++
 1 file changed, 96 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml

diff --git a/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
new file mode 100644
index 000000000000..95aa7f04c739
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/st,stm32mp25-rifsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Resource isolation framework security controller
+
+maintainers:
+  - Gatien Chevallier <gatien.chevallier at foss.st.com>
+
+description: |
+  Resource isolation framework (RIF) is a comprehensive set of hardware blocks
+  designed to enforce and manage isolation of STM32 hardware resources like
+  memory and peripherals.
+
+  The RIFSC (RIF security controller) is composed of three sets of registers,
+  each managing a specific set of hardware resources:
+    - RISC registers associated with RISUP logic (resource isolation device unit
+      for peripherals), assign all non-RIF aware peripherals to zero, one or
+      any security domains (secure, privilege, compartment).
+    - RIMC registers: associated with RIMU logic (resource isolation master
+      unit), assign all non RIF-aware bus master to one security domain by
+      setting secure, privileged and compartment information on the system bus.
+      Alternatively, the RISUP logic controlling the device port access to a
+      peripheral can assign target bus attributes to this peripheral master port
+      (supported attribute: CID).
+    - RISC registers associated with RISAL logic (resource isolation device unit
+      for address space - Lite version), assign address space subregions to one
+      security domains (secure, privilege, compartment).
+
+properties:
+  compatible:
+    contains:
+      const: st,stm32mp25-rifsc
+
+  reg:
+    maxItems: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 1
+
+  ranges: true
+
+  "#access-controller-cells":
+    const: 1
+    description:
+      Contains the firewall ID associated to the peripheral.
+
+patternProperties:
+  "^.*@[0-9a-f]+$":
+    description: Peripherals
+    type: object
+
+    additionalProperties: true
+
+    required:
+      - access-controllers
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+  - "#access-controller-cells"
+  - ranges
+
+additionalProperties: false
+
+examples:
+  - |
+    // In this example, the usart2 device refers to rifsc as its domain
+    // controller.
+    // Access rights are verified before creating devices.
+
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    rifsc: bus at 42080000 {
+        compatible = "st,stm32mp25-rifsc";
+        reg = <0x42080000 0x1000>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        #access-controller-cells = <1>;
+        ranges;
+
+        usart2: serial at 400e0000 {
+              compatible = "st,stm32h7-uart";
+              reg = <0x400e0000 0x400>;
+              interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+              clocks = <&ck_flexgen_08>;
+              access-controllers = <&rifsc 32>;
+        };
+    };
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:31 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:31 +0100
Subject: [PATCH v7 00/13] Introduce STM32 Firewall framework
Message-ID: <20231211183044.808204-1-gatien.chevallier@foss.st.com>

Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x
platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers
register to the framework to offer firewall services such as access
granting.

This series of patches is a new approach on the previous STM32 system
bus, history is available here:
https://lore.kernel.org/lkml/20230127164040.1047583/

The need for such framework arises from the fact that there are now
multiple hardware firewalls implemented across multiple products.
Drivers are shared between different products, using the same code.
When it comes to firewalls, the purpose mostly stays the same: Protect
hardware resources. But the implementation differs, and there are
multiple types of firewalls: peripheral, memory, ... 

Some hardware firewall controllers such as the RIFSC implemented on
STM32MP2x platforms may require to take ownership of a resource before
being able to use it, hence the requirement for firewall services to
take/release the ownership of such resources.

On the other hand, hardware firewall configurations are becoming
more and more complex. These mecanisms prevent platform crashes
or other firewall-related incoveniences by denying access to some
resources.

The stm32 firewall framework offers an API that is defined in
firewall controllers drivers to best fit the specificity of each
firewall.

For every peripherals protected by either the ETZPC or the RIFSC, the
firewall framework checks the firewall controlelr registers to see if
the peripheral's access is granted to the Linux kernel. If not, the
peripheral is configured as secure, the node is marked populated,
so that the driver is not probed for that device.

The firewall framework relies on the access-controller device tree
binding. It is used by peripherals to reference a domain access
controller. In this case a firewall controller. The bus uses the ID
referenced by the access-controller property to know where to look
in the firewall to get the security configuration for the peripheral.
This allows a device tree description rather than a hardcoded peripheral
table in the bus driver.

The STM32 ETZPC device is responsible for filtering accesses based on
security level, or co-processor isolation for any resource connected
to it.

The RIFSC is responsible for filtering accesses based on Compartment
ID / security level / privilege level for any resource connected to
it.

STM32MP13/15/25 SoC device tree files are updated in this series to
implement this mecanism.

Changes in V7:
	- Separate indentation changes from access-controllers changes
	  in the device tree file commits
	- Select OF_DYNAMIC when STM32_FIREWALL is set in order to use
	  of_detach_node() in the firewall framework
	- Handle previously non-present RNG and HASH nodes in the
	  STM32MP13 device tree file

Changes in V6:
	- Rename access-controller to access-controllers
	- Remove access-controller-provider
	- Update device trees and other bindings accordingly
	- Rework ETZPC/RIFSC bindings to define what access-controllers
	  cells contain inside #access-controller-cells
	- Some other minor fixes

Changes in V5:
	- Integrate and rework the "feature-domains" binding patch in
	  this patchset. The binding is renamed to "access-controller"
	- Rename every feature-domain* reference to access-control*
	  ones
	- Correct loop bug and missing select STM32_FIREWALL in 32-bit
	  platform Kconfig
	

Changes in V4:
	- Fix typo in commit message and YAML check errors in
	  "dt-bindings: Document common device controller bindings"
	  Note: This patch should be ignored as stated in the cover
	  letter. I've done this to avoid errors on this series of
	  patch
	- Correct code syntax/style issues reported by Simon Horman
	- Added Jonathan's tag for IIO on the treewide patch

Changes in V3:

	Change incorrect ordering for bindings commits leading
	to an error while running
	"make DT_CHECKER_FLAGS=-m dt_binding_check"

Changes in V2:

	generic:
		- Add fw_devlink dependency for "feature-domains"
		  property.

	bindings:
		- Corrected YAMLS errors highlighted by Rob's robot
		- Firewall controllers YAMLs no longer define the
		  maxItems for the "feature-domains" property
		- Renamed st,stm32-rifsc.yaml to
		  st,stm32mp25-rifsc.yaml
		- Fix examples in YAML files
		- Change feature-domains maxItems to 2 in firewall
		  consumer files as there should not be more than
		  2 entries for now
		- Declare "feature-domain-names" as an optional
		  property for firewall controllers child nodes.
		- Add missing "feature-domains" property declaration
		  in bosch,m_can.yaml and st,stm32-cryp.yaml files

	firewall framework:
		- Support multiple entries for "feature-domains"
		  property
		- Better handle the device-tree parsing using
		  phandle+args APIs
		- Remove "resource firewall" type
		- Add a field for the name of the firewall entry
		- Fix licenses
	
	RIFSC:
		- Add controller name
		- Driver is now a module_platform_driver
		- Fix license

	ETZPC:
		- Add controller name
		- Driver is now a module_platform_driver
		- Fix license

	Device trees:
		- Fix rifsc node name
		- Move the "ranges" property under the
		  "feature-domains" one

Gatien Chevallier (12):
  dt-bindings: treewide: add access-controllers description
  dt-bindings: bus: document RIFSC
  dt-bindings: bus: document ETZPC
  firewall: introduce stm32_firewall framework
  of: property: fw_devlink: Add support for "access-controller"
  bus: rifsc: introduce RIFSC firewall controller driver
  arm64: dts: st: add RIFSC as an access controller for STM32MP25x
    boards
  bus: etzpc: introduce ETZPC firewall controller driver
  ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
  ARM: dts: stm32: put ETZPC as an access controller for STM32MP15x
    boards
  ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards
  ARM: dts: stm32: put ETZPC as an access controller for STM32MP13x
    boards

Oleksii Moisieiev (1):
  dt-bindings: document generic access controllers

 .../access-controllers.yaml                   |   84 +
 .../bindings/bus/st,stm32-etzpc.yaml          |   87 +
 .../bindings/bus/st,stm32mp25-rifsc.yaml      |   96 +
 .../bindings/crypto/st,stm32-cryp.yaml        |    4 +
 .../bindings/crypto/st,stm32-hash.yaml        |    4 +
 .../devicetree/bindings/dma/st,stm32-dma.yaml |    4 +
 .../bindings/dma/st,stm32-dmamux.yaml         |    4 +
 .../devicetree/bindings/i2c/st,stm32-i2c.yaml |    4 +
 .../bindings/iio/adc/st,stm32-adc.yaml        |    4 +
 .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml  |    4 +
 .../bindings/iio/dac/st,stm32-dac.yaml        |    4 +
 .../bindings/media/cec/st,stm32-cec.yaml      |    4 +
 .../bindings/media/st,stm32-dcmi.yaml         |    4 +
 .../memory-controllers/st,stm32-fmc2-ebi.yaml |    4 +
 .../bindings/mfd/st,stm32-lptimer.yaml        |    4 +
 .../bindings/mfd/st,stm32-timers.yaml         |    4 +
 .../devicetree/bindings/mmc/arm,pl18x.yaml    |    4 +
 .../bindings/net/can/bosch,m_can.yaml         |    4 +
 .../devicetree/bindings/net/stm32-dwmac.yaml  |    4 +
 .../bindings/phy/phy-stm32-usbphyc.yaml       |    4 +
 .../bindings/regulator/st,stm32-vrefbuf.yaml  |    4 +
 .../devicetree/bindings/rng/st,stm32-rng.yaml |    4 +
 .../bindings/serial/st,stm32-uart.yaml        |    4 +
 .../bindings/sound/st,stm32-i2s.yaml          |    4 +
 .../bindings/sound/st,stm32-sai.yaml          |    4 +
 .../bindings/sound/st,stm32-spdifrx.yaml      |    4 +
 .../bindings/spi/st,stm32-qspi.yaml           |    4 +
 .../devicetree/bindings/spi/st,stm32-spi.yaml |    4 +
 .../devicetree/bindings/usb/dwc2.yaml         |    4 +
 MAINTAINERS                                   |    7 +
 arch/arm/boot/dts/st/stm32mp131.dtsi          | 1063 ++++---
 arch/arm/boot/dts/st/stm32mp133.dtsi          |   51 +-
 arch/arm/boot/dts/st/stm32mp13xc.dtsi         |   19 +-
 arch/arm/boot/dts/st/stm32mp13xf.dtsi         |   19 +-
 arch/arm/boot/dts/st/stm32mp151.dtsi          | 2756 +++++++++--------
 arch/arm/boot/dts/st/stm32mp153.dtsi          |   52 +-
 arch/arm/boot/dts/st/stm32mp15xc.dtsi         |   19 +-
 arch/arm/mach-stm32/Kconfig                   |    1 +
 arch/arm64/Kconfig.platforms                  |    1 +
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |    6 +-
 drivers/bus/Kconfig                           |   10 +
 drivers/bus/Makefile                          |    1 +
 drivers/bus/stm32_etzpc.c                     |  141 +
 drivers/bus/stm32_firewall.c                  |  294 ++
 drivers/bus/stm32_firewall.h                  |   83 +
 drivers/bus/stm32_rifsc.c                     |  252 ++
 drivers/of/property.c                         |    2 +
 include/linux/bus/stm32_firewall_device.h     |  141 +
 48 files changed, 3351 insertions(+), 1938 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
 create mode 100644 Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
 create mode 100644 Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
 create mode 100644 drivers/bus/stm32_etzpc.c
 create mode 100644 drivers/bus/stm32_firewall.c
 create mode 100644 drivers/bus/stm32_firewall.h
 create mode 100644 drivers/bus/stm32_rifsc.c
 create mode 100644 include/linux/bus/stm32_firewall_device.h

-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:37 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:37 +0100
Subject: [PATCH v7 06/13] of: property: fw_devlink: Add support for "access-controller"
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-7-gatien.chevallier@foss.st.com>

Allows tracking dependencies between devices and their access
controller.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
    	- Renamed access-controller to access-controllers

Changes in V5:
	- Rename feature-domain* to access-control*

Patch not present in V1

 drivers/of/property.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index afdaefbd03f6..7f737eac91b2 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1268,6 +1268,7 @@ DEFINE_SIMPLE_PROP(leds, "leds", NULL)
 DEFINE_SIMPLE_PROP(backlight, "backlight", NULL)
 DEFINE_SIMPLE_PROP(panel, "panel", NULL)
 DEFINE_SIMPLE_PROP(msi_parent, "msi-parent", "#msi-cells")
+DEFINE_SIMPLE_PROP(access_controllers, "access-controllers", "#access-controller-cells")
 DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
 DEFINE_SUFFIX_PROP(gpio, "-gpio", "#gpio-cells")
 
@@ -1363,6 +1364,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
 	{ .parse_prop = parse_regulators, },
 	{ .parse_prop = parse_gpio, },
 	{ .parse_prop = parse_gpios, },
+	{ .parse_prop = parse_access_controllers, },
 	{}
 };
 
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:36 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:36 +0100
Subject: [PATCH v7 05/13] firewall: introduce stm32_firewall framework
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-6-gatien.chevallier@foss.st.com>

Introduce a STM32 firewall framework that offers to firewall consumers
different firewall services such as the ability to check their access
rights against their firewall controller(s).

The STM32 firewall framework offers a generic API for STM32 firewall
controllers that is defined in their drivers to best fit the
specificity of each firewall.

There are various types of firewalls:
-Peripheral firewalls that filter accesses to peripherals
-Memory firewalls that filter accesses to memories or memory regions
-No type for undefined type of firewall

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---
Changes in V7:
	- Select OF_DYNAMIC when STM32_FIREWALL is set in order to use
	  of_detach_node() in the firewall framework. Since the
	  simple-bus pre-probe creates devices for all subnodes. This
	  function is needed to detach particular nodes so that there's
	  no match

Changes in V6:
	- Renamed access-controller to access-controllers

Changes in V5:
	- Rename feature-domain* to access-control*
	- Fix index out of range in stm32_firewall_get_firewall()
	- Add mising "select STM32_FIREWALL" in config ARCH_STM32 in
	  arch/arm/mach-stm32/Kconfig

Changes in V4:
	- Fix documentation syntax
	- Put node in case of error in stm32_firewall_populate_bus()
	- Check firewall controller presence before using it in
	  stm32_firewall_controller_register()

Changes in V2:
	- Support multiple entries for "feature-domains"
	  property. Change stm32_firewall_get_firewall()
	  to do so.
	- Better handle the device-tree parsing using
	  phandle+args APIs and phandle iterator.
	- Remove "resource firewall" type
	- Rephrase STM32_FIREWALL description in the bus
	  Kconfig and remove useless default value
	- Add missing EXPORT_SYMBOL_GPL
	- Remove useless stm32_firewall_get_id() API
	- Add a field for the name of the firewall entry
	  in the stm32_firewall_controller structure
	- Minor fixes on some traces level (err -> debug)
	- Fix licenses to GPL-2.0-only
	- Fix stm32_firewall_get_firewall() description
	- Rephrase some sentences to better emphasize this
	  is STM32-specific
	- Switch to list_for_each_entry() in
	  stm32_firewall_controller_unregister() as we only
	  expect one firewall controller instance per device.
	  The loop just breaks when found
	- Do not register the firewall controller if it is
	  already registered to the framework

 MAINTAINERS                               |   5 +
 arch/arm/mach-stm32/Kconfig               |   1 +
 arch/arm64/Kconfig.platforms              |   1 +
 drivers/bus/Kconfig                       |  10 +
 drivers/bus/Makefile                      |   1 +
 drivers/bus/stm32_firewall.c              | 294 ++++++++++++++++++++++
 drivers/bus/stm32_firewall.h              |  83 ++++++
 include/linux/bus/stm32_firewall_device.h | 141 +++++++++++
 8 files changed, 536 insertions(+)
 create mode 100644 drivers/bus/stm32_firewall.c
 create mode 100644 drivers/bus/stm32_firewall.h
 create mode 100644 include/linux/bus/stm32_firewall_device.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e2c6187a3ac8..774c7e1601d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20430,6 +20430,11 @@ T:	git git://linuxtv.org/media_tree.git
 F:	Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml
 F:	drivers/media/i2c/st-mipid02.c
 
+ST STM32 FIREWALL
+M:	Gatien Chevallier <gatien.chevallier at foss.st.com>
+S:	Maintained
+F:	drivers/bus/stm32_firewall.c
+
 ST STM32 I2C/SMBUS DRIVER
 M:	Pierre-Yves MORDRET <pierre-yves.mordret at foss.st.com>
 M:	Alain Volmat <alain.volmat at foss.st.com>
diff --git a/arch/arm/mach-stm32/Kconfig b/arch/arm/mach-stm32/Kconfig
index 98145031586f..ae21a9f78f9c 100644
--- a/arch/arm/mach-stm32/Kconfig
+++ b/arch/arm/mach-stm32/Kconfig
@@ -12,6 +12,7 @@ menuconfig ARCH_STM32
 	select PINCTRL
 	select RESET_CONTROLLER
 	select STM32_EXTI
+	select STM32_FIREWALL
 	help
 	  Support for STMicroelectronics STM32 processors.
 
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 24335565bad5..13ed0a483617 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -305,6 +305,7 @@ config ARCH_STM32
 	select ARM_SMC_MBOX
 	select ARM_SCMI_PROTOCOL
 	select COMMON_CLK_SCMI
+	select STM32_FIREWALL
 	help
 	  This enables support for ARMv8 based STMicroelectronics
 	  STM32 family, including:
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index e6742998f372..5d825085562d 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -163,6 +163,16 @@ config QCOM_SSC_BLOCK_BUS
 	  i2c/spi/uart controllers, a hexagon core, and a clock controller
 	  which provides clocks for the above.
 
+config STM32_FIREWALL
+	bool "STM32 Firewall framework"
+	depends on ARCH_STM32 || COMPILE_TEST
+	select OF_DYNAMIC
+	help
+	  Say y to enable STM32 firewall framework and its services. Firewall
+	  controllers will be able to register to the framework. Access for
+	  hardware resources linked to a firewall controller can be requested
+	  through this STM32 framework.
+
 config SUN50I_DE2_BUS
 	bool "Allwinner A64 DE2 Bus Driver"
 	  default ARM64
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index d90eed189a65..fc0511450ec2 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_OMAP_INTERCONNECT)	+= omap_l3_smx.o omap_l3_noc.o
 obj-$(CONFIG_OMAP_OCP2SCP)	+= omap-ocp2scp.o
 obj-$(CONFIG_QCOM_EBI2)		+= qcom-ebi2.o
 obj-$(CONFIG_QCOM_SSC_BLOCK_BUS)	+= qcom-ssc-block-bus.o
+obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o
 obj-$(CONFIG_SUN50I_DE2_BUS)	+= sun50i-de2.o
 obj-$(CONFIG_SUNXI_RSB)		+= sunxi-rsb.o
 obj-$(CONFIG_OF)		+= simple-pm-bus.o
diff --git a/drivers/bus/stm32_firewall.c b/drivers/bus/stm32_firewall.c
new file mode 100644
index 000000000000..decb79449047
--- /dev/null
+++ b/drivers/bus/stm32_firewall.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/bus/stm32_firewall_device.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/slab.h>
+
+#include "stm32_firewall.h"
+
+/* Corresponds to STM32_FIREWALL_MAX_EXTRA_ARGS + firewall ID */
+#define STM32_FIREWALL_MAX_ARGS		(STM32_FIREWALL_MAX_EXTRA_ARGS + 1)
+
+static LIST_HEAD(firewall_controller_list);
+static DEFINE_MUTEX(firewall_controller_list_lock);
+
+/* Firewall device API */
+
+int stm32_firewall_get_firewall(struct device_node *np, struct stm32_firewall *firewall,
+				unsigned int nb_firewall)
+{
+	struct stm32_firewall_controller *ctrl;
+	struct of_phandle_iterator it;
+	unsigned int i, j = 0;
+	int err;
+
+	if (!firewall || !nb_firewall)
+		return -EINVAL;
+
+	/* Parse property with phandle parsed out */
+	of_for_each_phandle(&it, err, np, "access-controllers", "#access-controller-cells", 0) {
+		struct of_phandle_args provider_args;
+		struct device_node *provider = it.node;
+		const char *fw_entry;
+		bool match = false;
+
+		if (err) {
+			pr_err("Unable to get access-controllers property for node %s\n, err: %d",
+			       np->full_name, err);
+			of_node_put(provider);
+			return err;
+		}
+
+		if (j > nb_firewall) {
+			pr_err("Too many firewall controllers");
+			of_node_put(provider);
+			return -EINVAL;
+		}
+
+		provider_args.args_count = of_phandle_iterator_args(&it, provider_args.args,
+								    STM32_FIREWALL_MAX_ARGS);
+
+		/* Check if the parsed phandle corresponds to a registered firewall controller */
+		mutex_lock(&firewall_controller_list_lock);
+		list_for_each_entry(ctrl, &firewall_controller_list, entry) {
+			if (ctrl->dev->of_node->phandle == it.phandle) {
+				match = true;
+				firewall[j].firewall_ctrl = ctrl;
+				break;
+			}
+		}
+		mutex_unlock(&firewall_controller_list_lock);
+
+		if (!match) {
+			firewall[j].firewall_ctrl = NULL;
+			pr_err("No firewall controller registered for %s\n", np->full_name);
+			of_node_put(provider);
+			return -ENODEV;
+		}
+
+		err = of_property_read_string_index(np, "access-controller-names", j, &fw_entry);
+		if (err == 0)
+			firewall[j].entry = fw_entry;
+
+		/* Handle the case when there are no arguments given along with the phandle */
+		if (provider_args.args_count < 0 ||
+		    provider_args.args_count > STM32_FIREWALL_MAX_ARGS) {
+			of_node_put(provider);
+			return -EINVAL;
+		} else if (provider_args.args_count == 0) {
+			firewall[j].extra_args_size = 0;
+			firewall[j].firewall_id = U32_MAX;
+			j++;
+			continue;
+		}
+
+		/* The firewall ID is always the first argument */
+		firewall[j].firewall_id = provider_args.args[0];
+
+		/* Extra args start at the second argument */
+		for (i = 0; i < provider_args.args_count - 1; i++)
+			firewall[j].extra_args[i] = provider_args.args[i + 1];
+
+		/* Remove the firewall ID arg that is not an extra argument */
+		firewall[j].extra_args_size = provider_args.args_count - 1;
+
+		j++;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_get_firewall);
+
+int stm32_firewall_grant_access(struct stm32_firewall *firewall)
+{
+	struct stm32_firewall_controller *firewall_controller;
+
+	if (!firewall || firewall->firewall_id == U32_MAX)
+		return -EINVAL;
+
+	firewall_controller = firewall->firewall_ctrl;
+
+	if (!firewall_controller)
+		return -ENODEV;
+
+	return firewall_controller->grant_access(firewall_controller, firewall->firewall_id);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_grant_access);
+
+int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
+{
+	struct stm32_firewall_controller *firewall_controller;
+
+	if (!firewall || subsystem_id == U32_MAX || firewall->firewall_id == U32_MAX)
+		return -EINVAL;
+
+	firewall_controller = firewall->firewall_ctrl;
+
+	if (!firewall_controller)
+		return -ENODEV;
+
+	return firewall_controller->grant_access(firewall_controller, subsystem_id);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_grant_access_by_id);
+
+void stm32_firewall_release_access(struct stm32_firewall *firewall)
+{
+	struct stm32_firewall_controller *firewall_controller;
+
+	if (!firewall || firewall->firewall_id == U32_MAX) {
+		pr_debug("Incorrect arguments when releasing a firewall access\n");
+		return;
+	}
+
+	firewall_controller = firewall->firewall_ctrl;
+
+	if (!firewall_controller) {
+		pr_debug("No firewall controller to release\n");
+		return;
+	}
+
+	firewall_controller->release_access(firewall_controller, firewall->firewall_id);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_release_access);
+
+void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
+{
+	struct stm32_firewall_controller *firewall_controller;
+
+	if (!firewall || subsystem_id == U32_MAX || firewall->firewall_id == U32_MAX) {
+		pr_debug("Incorrect arguments when releasing a firewall access");
+		return;
+	}
+
+	firewall_controller = firewall->firewall_ctrl;
+
+	if (!firewall_controller) {
+		pr_debug("No firewall controller to release");
+		return;
+	}
+
+	firewall_controller->release_access(firewall_controller, subsystem_id);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_release_access_by_id);
+
+/* Firewall controller API */
+
+int stm32_firewall_controller_register(struct stm32_firewall_controller *firewall_controller)
+{
+	struct stm32_firewall_controller *ctrl;
+
+	if (!firewall_controller)
+		return -ENODEV;
+
+	pr_info("Registering %s firewall controller\n", firewall_controller->name);
+
+	mutex_lock(&firewall_controller_list_lock);
+	list_for_each_entry(ctrl, &firewall_controller_list, entry) {
+		if (ctrl == firewall_controller) {
+			pr_debug("%s firewall controller already registered\n",
+				 firewall_controller->name);
+			mutex_unlock(&firewall_controller_list_lock);
+			return 0;
+		}
+	}
+	list_add_tail(&firewall_controller->entry, &firewall_controller_list);
+	mutex_unlock(&firewall_controller_list_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_controller_register);
+
+void stm32_firewall_controller_unregister(struct stm32_firewall_controller *firewall_controller)
+{
+	struct stm32_firewall_controller *ctrl;
+	bool controller_removed = false;
+
+	if (!firewall_controller) {
+		pr_debug("Null reference while unregistering firewall controller\n");
+		return;
+	}
+
+	mutex_lock(&firewall_controller_list_lock);
+	list_for_each_entry(ctrl, &firewall_controller_list, entry) {
+		if (ctrl == firewall_controller) {
+			controller_removed = true;
+			list_del_init(&ctrl->entry);
+			break;
+		}
+	}
+	mutex_unlock(&firewall_controller_list_lock);
+
+	if (!controller_removed)
+		pr_debug("There was no firewall controller named %s to unregister\n",
+			 firewall_controller->name);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_controller_unregister);
+
+int stm32_firewall_populate_bus(struct stm32_firewall_controller *firewall_controller)
+{
+	struct stm32_firewall *firewalls;
+	struct device_node *child;
+	struct device *parent;
+	unsigned int i;
+	int len;
+	int err;
+
+	parent = firewall_controller->dev;
+
+	dev_dbg(parent, "Populating %s system bus\n", dev_name(firewall_controller->dev));
+
+	for_each_available_child_of_node(dev_of_node(parent), child) {
+		/* The access-controllers property is mandatory for firewall bus devices */
+		len = of_count_phandle_with_args(child, "access-controllers",
+						 "#access-controller-cells");
+		if (len <= 0) {
+			of_node_put(child);
+			return -EINVAL;
+		}
+
+		firewalls = kcalloc(len, sizeof(*firewalls), GFP_KERNEL);
+		if (!firewalls) {
+			of_node_put(child);
+			return -ENOMEM;
+		}
+
+		err = stm32_firewall_get_firewall(child, firewalls, (unsigned int)len);
+		if (err) {
+			kfree(firewalls);
+			of_node_put(child);
+			return err;
+		}
+
+		for (i = 0; i < len; i++) {
+			if (firewall_controller->grant_access(firewall_controller,
+							      firewalls[i].firewall_id)) {
+				/*
+				 * Peripheral access not allowed or not defined.
+				 * Mark the node as populated so platform bus won't probe it
+				 */
+				of_detach_node(child);
+				dev_err(parent, "%s: Device driver will not be probed\n",
+					child->full_name);
+			}
+		}
+
+		kfree(firewalls);
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_populate_bus);
diff --git a/drivers/bus/stm32_firewall.h b/drivers/bus/stm32_firewall.h
new file mode 100644
index 000000000000..e5fac85fe346
--- /dev/null
+++ b/drivers/bus/stm32_firewall.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef _STM32_FIREWALL_H
+#define _STM32_FIREWALL_H
+
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+/**
+ * STM32_PERIPHERAL_FIREWALL:		This type of firewall protects peripherals
+ * STM32_MEMORY_FIREWALL:		This type of firewall protects memories/subsets of memory
+ *					zones
+ * STM32_NOTYPE_FIREWALL:		Undefined firewall type
+ */
+
+#define STM32_PERIPHERAL_FIREWALL	BIT(1)
+#define STM32_MEMORY_FIREWALL		BIT(2)
+#define STM32_NOTYPE_FIREWALL		BIT(3)
+
+/**
+ * struct stm32_firewall_controller - Information on firewall controller supplying services
+ *
+ * @name:			Name of the firewall controller
+ * @dev:			Device reference of the firewall controller
+ * @mmio:			Base address of the firewall controller
+ * @entry:			List entry of the firewall controller list
+ * @type:			Type of firewall
+ * @max_entries:		Number of entries covered by the firewall
+ * @grant_access:		Callback used to grant access for a device access against a
+ *				firewall controller
+ * @release_access:		Callback used to release resources taken by a device when access was
+ *				granted
+ * @grant_memory_range_access:	Callback used to grant access for a device to a given memory region
+ */
+struct stm32_firewall_controller {
+	const char *name;
+	struct device *dev;
+	void __iomem *mmio;
+	struct list_head entry;
+	unsigned int type;
+	unsigned int max_entries;
+
+	int (*grant_access)(struct stm32_firewall_controller *ctrl, u32 id);
+	void (*release_access)(struct stm32_firewall_controller *ctrl, u32 id);
+	int (*grant_memory_range_access)(struct stm32_firewall_controller *ctrl, phys_addr_t paddr,
+					 size_t size);
+};
+
+/**
+ * stm32_firewall_controller_register - Register a firewall controller to the STM32 firewall
+ *					framework
+ * @firewall_controller:	Firewall controller to register
+ *
+ * Returns 0 in case of success or -ENODEV if no controller was given.
+ */
+int stm32_firewall_controller_register(struct stm32_firewall_controller *firewall_controller);
+
+/**
+ * stm32_firewall_controller_unregister - Unregister a firewall controller from the STM32
+ *					  firewall framework
+ * @firewall_controller:	Firewall controller to unregister
+ */
+void stm32_firewall_controller_unregister(struct stm32_firewall_controller *firewall_controller);
+
+/**
+ * stm32_firewall_populate_bus - Populate device tree nodes that have a correct firewall
+ *				 configuration. This is used at boot-time only, as a sanity check
+ *				 between device tree and firewalls hardware configurations to
+ *				 prevent a kernel crash when a device driver is not granted access
+ *
+ * @firewall_controller:	Firewall controller which nodes will be populated or not
+ *
+ * Returns 0 in case of success or appropriate errno code if error occurred.
+ */
+int stm32_firewall_populate_bus(struct stm32_firewall_controller *firewall_controller);
+
+#endif /* _STM32_FIREWALL_H */
diff --git a/include/linux/bus/stm32_firewall_device.h b/include/linux/bus/stm32_firewall_device.h
new file mode 100644
index 000000000000..bbbee0b24ea8
--- /dev/null
+++ b/include/linux/bus/stm32_firewall_device.h
@@ -0,0 +1,141 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef STM32_FIREWALL_DEVICE_H
+#define STM32_FIREWALL_DEVICE_H
+
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+#define STM32_FIREWALL_MAX_EXTRA_ARGS		5
+
+/* Opaque reference to stm32_firewall_controller */
+struct stm32_firewall_controller;
+
+/**
+ * struct stm32_firewall - Information on a device's firewall. Each device can have more than one
+ *			   firewall.
+ *
+ * @firewall_ctrl:		Pointer referencing a firewall controller of the device. It is
+ *				opaque so a device cannot manipulate the controller's ops or access
+ *				the controller's data
+ * @extra_args:			Extra arguments that are implementation dependent
+ * @entry:			Name of the firewall entry
+ * @extra_args_size:		Number of extra arguments
+ * @firewall_id:		Firewall ID associated the device for this firewall controller
+ */
+struct stm32_firewall {
+	struct stm32_firewall_controller *firewall_ctrl;
+	u32 extra_args[STM32_FIREWALL_MAX_EXTRA_ARGS];
+	const char *entry;
+	size_t extra_args_size;
+	u32 firewall_id;
+};
+
+#if IS_ENABLED(CONFIG_STM32_FIREWALL)
+/**
+ * stm32_firewall_get_firewall - Get the firewall(s) associated to given device.
+ *				 The firewall controller reference is always the first argument
+ *				 of each of the access-controller property entries.
+ *				 The firewall ID is always the second argument of each of the
+ *				 access-controller  property entries.
+ *				 If there's no argument linked to the phandle, then the firewall ID
+ *				 field is set to U32_MAX, which is an invalid ID.
+ *
+ * @np:				Device node to parse
+ * @firewall:			Array of firewall references
+ * @nb_firewall:		Number of firewall references to get. Must be at least 1.
+ *
+ * Returns 0 on success, -ENODEV if there's no match with a firewall controller or appropriate errno
+ * code if error occurred.
+ */
+int stm32_firewall_get_firewall(struct device_node *np, struct stm32_firewall *firewall,
+				unsigned int nb_firewall);
+
+/**
+ * stm32_firewall_grant_access - Request firewall access rights and grant access.
+ *
+ * @firewall:			Firewall reference containing the ID to check against its firewall
+ *				controller
+ *
+ * Returns 0 if access is granted, -EACCES if access is denied, -ENODEV if firewall is null or
+ * appropriate errno code if error occurred
+ */
+int stm32_firewall_grant_access(struct stm32_firewall *firewall);
+
+/**
+ * stm32_firewall_release_access - Release access granted from a call to
+ *				   stm32_firewall_grant_access().
+ *
+ * @firewall:			Firewall reference containing the ID to check against its firewall
+ *				controller
+ */
+void stm32_firewall_release_access(struct stm32_firewall *firewall);
+
+/**
+ * stm32_firewall_grant_access_by_id - Request firewall access rights of a given device
+ *				       based on a specific firewall ID
+ *
+ * Warnings:
+ * There is no way to ensure that the given ID will correspond to the firewall referenced in the
+ * device node if the ID did not come from stm32_firewall_get_firewall(). In that case, this
+ * function must be used with caution.
+ * This function should be used for subsystem resources that do not have the same firewall ID
+ * as their parent.
+ * U32_MAX is an invalid ID.
+ *
+ * @firewall:			Firewall reference containing the firewall controller
+ * @subsystem_id:		Firewall ID of the subsystem resource
+ *
+ * Returns 0 if access is granted, -EACCES if access is denied, -ENODEV if firewall is null or
+ * appropriate errno code if error occurred
+ */
+int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id);
+
+/**
+ * stm32_firewall_release_access_by_id - Release access granted from a call to
+ *					 stm32_firewall_grant_access_by_id().
+ *
+ * Warnings:
+ * There is no way to ensure that the given ID will correspond to the firewall referenced in the
+ * device node if the ID did not come from stm32_firewall_get_firewall(). In that case, this
+ * function must be used with caution.
+ * This function should be used for subsystem resources that do not have the same firewall ID
+ * as their parent.
+ * U32_MAX is an invalid ID.
+ *
+ * @firewall:			Firewall reference containing the firewall controller
+ * @subsystem_id:		Firewall ID of the subsystem resource
+ */
+void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id);
+
+#else /* CONFIG_STM32_FIREWALL */
+
+int stm32_firewall_get_firewall(struct device_node *np, struct stm32_firewall *firewall)
+{
+	return -ENODEV;
+}
+
+int stm32_firewall_grant_access(struct stm32_firewall *firewall)
+{
+	return -ENODEV;
+}
+
+void stm32_firewall_release_access(struct stm32_firewall *firewall)
+{
+}
+
+int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
+{
+	return -ENODEV;
+}
+
+void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
+{
+}
+
+#endif /* CONFIG_STM32_FIREWALL */
+#endif /* STM32_FIREWALL_DEVICE_H */
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:38 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:38 +0100
Subject: [PATCH v7 07/13] bus: rifsc: introduce RIFSC firewall controller driver
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-8-gatien.chevallier@foss.st.com>

RIFSC is a peripheral firewall controller that filter accesses based on
Arm TrustZone secure state, Arm CPU privilege execution level and
Compartment IDentification of the STM32 SoC subsystems.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V4:
	- Fix incorrect use of __set_bit() in
	- stm32_rif_acquire_semaphore()

Changes in V2:
	- Add controller name
	- Driver is now a module_platform_driver
	- Use error code returned by stm32_firewall_populate_bus()
	- Fix license

 MAINTAINERS               |   1 +
 drivers/bus/Makefile      |   2 +-
 drivers/bus/stm32_rifsc.c | 252 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 254 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bus/stm32_rifsc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 774c7e1601d8..a1152438b52d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20434,6 +20434,7 @@ ST STM32 FIREWALL
 M:	Gatien Chevallier <gatien.chevallier at foss.st.com>
 S:	Maintained
 F:	drivers/bus/stm32_firewall.c
+F:	drivers/bus/stm32_rifsc.c
 
 ST STM32 I2C/SMBUS DRIVER
 M:	Pierre-Yves MORDRET <pierre-yves.mordret at foss.st.com>
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index fc0511450ec2..e50d18e1d141 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_OMAP_INTERCONNECT)	+= omap_l3_smx.o omap_l3_noc.o
 obj-$(CONFIG_OMAP_OCP2SCP)	+= omap-ocp2scp.o
 obj-$(CONFIG_QCOM_EBI2)		+= qcom-ebi2.o
 obj-$(CONFIG_QCOM_SSC_BLOCK_BUS)	+= qcom-ssc-block-bus.o
-obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o
+obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o stm32_rifsc.o
 obj-$(CONFIG_SUN50I_DE2_BUS)	+= sun50i-de2.o
 obj-$(CONFIG_SUNXI_RSB)		+= sunxi-rsb.o
 obj-$(CONFIG_OF)		+= simple-pm-bus.o
diff --git a/drivers/bus/stm32_rifsc.c b/drivers/bus/stm32_rifsc.c
new file mode 100644
index 000000000000..4cf1b60014b7
--- /dev/null
+++ b/drivers/bus/stm32_rifsc.c
@@ -0,0 +1,252 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+#include "stm32_firewall.h"
+
+/*
+ * RIFSC offset register
+ */
+#define RIFSC_RISC_SECCFGR0		0x10
+#define RIFSC_RISC_PRIVCFGR0		0x30
+#define RIFSC_RISC_PER0_CIDCFGR		0x100
+#define RIFSC_RISC_PER0_SEMCR		0x104
+#define RIFSC_RISC_HWCFGR2		0xFEC
+
+/*
+ * SEMCR register
+ */
+#define SEMCR_MUTEX			BIT(0)
+
+/*
+ * HWCFGR2 register
+ */
+#define HWCFGR2_CONF1_MASK		GENMASK(15, 0)
+#define HWCFGR2_CONF2_MASK		GENMASK(23, 16)
+#define HWCFGR2_CONF3_MASK		GENMASK(31, 24)
+
+/*
+ * RIFSC miscellaneous
+ */
+#define RIFSC_RISC_CFEN_MASK		BIT(0)
+#define RIFSC_RISC_SEM_EN_MASK		BIT(1)
+#define RIFSC_RISC_SCID_MASK		GENMASK(6, 4)
+#define RIFSC_RISC_SEML_SHIFT		16
+#define RIFSC_RISC_SEMWL_MASK		GENMASK(23, 16)
+#define RIFSC_RISC_PER_ID_MASK		GENMASK(31, 24)
+
+#define RIFSC_RISC_PERx_CID_MASK	(RIFSC_RISC_CFEN_MASK | \
+					 RIFSC_RISC_SEM_EN_MASK | \
+					 RIFSC_RISC_SCID_MASK | \
+					 RIFSC_RISC_SEMWL_MASK)
+
+#define IDS_PER_RISC_SEC_PRIV_REGS	32
+
+/* RIF miscellaneous */
+/*
+ * CIDCFGR register fields
+ */
+#define CIDCFGR_CFEN			BIT(0)
+#define CIDCFGR_SEMEN			BIT(1)
+#define CIDCFGR_SEMWL(x)		BIT(RIFSC_RISC_SEML_SHIFT + (x))
+
+#define SEMWL_SHIFT			16
+
+/* Compartiment IDs */
+#define RIF_CID0			0x0
+#define RIF_CID1			0x1
+
+static bool stm32_rifsc_is_semaphore_available(void __iomem *addr)
+{
+	return !(readl(addr) & SEMCR_MUTEX);
+}
+
+static int stm32_rif_acquire_semaphore(struct stm32_firewall_controller *stm32_firewall_controller,
+				       int id)
+{
+	void __iomem *addr = stm32_firewall_controller->mmio + RIFSC_RISC_PER0_SEMCR + 0x8 * id;
+
+	writel(SEMCR_MUTEX, addr);
+
+	/* Check that CID1 has the semaphore */
+	if (stm32_rifsc_is_semaphore_available(addr) ||
+	    FIELD_GET(RIFSC_RISC_SCID_MASK, readl(addr)) != RIF_CID1)
+		return -EACCES;
+
+	return 0;
+}
+
+static void stm32_rif_release_semaphore(struct stm32_firewall_controller *stm32_firewall_controller,
+					int id)
+{
+	void __iomem *addr = stm32_firewall_controller->mmio + RIFSC_RISC_PER0_SEMCR + 0x8 * id;
+
+	if (stm32_rifsc_is_semaphore_available(addr))
+		return;
+
+	writel(SEMCR_MUTEX, addr);
+
+	/* Ok if another compartment takes the semaphore before the check */
+	WARN_ON(!stm32_rifsc_is_semaphore_available(addr) &&
+		FIELD_GET(RIFSC_RISC_SCID_MASK, readl(addr)) == RIF_CID1);
+}
+
+static int stm32_rifsc_grant_access(struct stm32_firewall_controller *ctrl, u32 firewall_id)
+{
+	struct stm32_firewall_controller *rifsc_controller = ctrl;
+	u32 reg_offset, reg_id, sec_reg_value, cid_reg_value;
+	int rc;
+
+	if (firewall_id >= rifsc_controller->max_entries) {
+		dev_err(rifsc_controller->dev, "Invalid sys bus ID %u", firewall_id);
+		return -EINVAL;
+	}
+
+	/*
+	 * RIFSC_RISC_PRIVCFGRx and RIFSC_RISC_SECCFGRx both handle configuration access for
+	 * 32 peripherals. On the other hand, there is one _RIFSC_RISC_PERx_CIDCFGR register
+	 * per peripheral
+	 */
+	reg_id = firewall_id / IDS_PER_RISC_SEC_PRIV_REGS;
+	reg_offset = firewall_id % IDS_PER_RISC_SEC_PRIV_REGS;
+	sec_reg_value = readl(rifsc_controller->mmio + RIFSC_RISC_SECCFGR0 + 0x4 * reg_id);
+	cid_reg_value = readl(rifsc_controller->mmio + RIFSC_RISC_PER0_CIDCFGR + 0x8 * firewall_id);
+
+	/* First check conditions for semaphore mode, which doesn't take into account static CID. */
+	if ((cid_reg_value & CIDCFGR_SEMEN) && (cid_reg_value & CIDCFGR_CFEN)) {
+		if (cid_reg_value & BIT(RIF_CID1 + SEMWL_SHIFT)) {
+			/* Static CID is irrelevant if semaphore mode */
+			goto skip_cid_check;
+		} else {
+			dev_dbg(rifsc_controller->dev,
+				"Invalid bus semaphore configuration: index %d\n", firewall_id);
+			return -EACCES;
+		}
+	}
+
+	/*
+	 * Skip CID check if CID filtering isn't enabled or filtering is enabled on CID0, which
+	 * corresponds to whatever CID.
+	 */
+	if (!(cid_reg_value & CIDCFGR_CFEN) ||
+	    FIELD_GET(RIFSC_RISC_SCID_MASK, cid_reg_value) == RIF_CID0)
+		goto skip_cid_check;
+
+	/* Coherency check with the CID configuration */
+	if (FIELD_GET(RIFSC_RISC_SCID_MASK, cid_reg_value) != RIF_CID1) {
+		dev_dbg(rifsc_controller->dev, "Invalid CID configuration for peripheral: %d\n",
+			firewall_id);
+		return -EACCES;
+	}
+
+skip_cid_check:
+	/* Check security configuration */
+	if (sec_reg_value & BIT(reg_offset)) {
+		dev_dbg(rifsc_controller->dev,
+			"Invalid security configuration for peripheral: %d\n", firewall_id);
+		return -EACCES;
+	}
+
+	/*
+	 * If the peripheral is in semaphore mode, take the semaphore so that
+	 * the CID1 has the ownership.
+	 */
+	if ((cid_reg_value & CIDCFGR_SEMEN) && (cid_reg_value & CIDCFGR_CFEN)) {
+		rc = stm32_rif_acquire_semaphore(rifsc_controller, firewall_id);
+		if (rc) {
+			dev_err(rifsc_controller->dev,
+				"Couldn't acquire semaphore for peripheral: %d\n", firewall_id);
+			return rc;
+		}
+	}
+
+	return 0;
+}
+
+static void stm32_rifsc_release_access(struct stm32_firewall_controller *ctrl, u32 firewall_id)
+{
+	stm32_rif_release_semaphore(ctrl, firewall_id);
+}
+
+static int stm32_rifsc_probe(struct platform_device *pdev)
+{
+	struct stm32_firewall_controller *rifsc_controller;
+	struct device_node *np = pdev->dev.of_node;
+	u32 nb_risup, nb_rimu, nb_risal;
+	struct resource *res;
+	void __iomem *mmio;
+	int rc;
+
+	rifsc_controller = devm_kzalloc(&pdev->dev, sizeof(*rifsc_controller), GFP_KERNEL);
+	if (!rifsc_controller)
+		return -ENOMEM;
+
+	mmio = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(mmio))
+		return PTR_ERR(mmio);
+
+	rifsc_controller->dev = &pdev->dev;
+	rifsc_controller->mmio = mmio;
+	rifsc_controller->name = dev_driver_string(rifsc_controller->dev);
+	rifsc_controller->type = STM32_PERIPHERAL_FIREWALL | STM32_MEMORY_FIREWALL;
+	rifsc_controller->grant_access = stm32_rifsc_grant_access;
+	rifsc_controller->release_access = stm32_rifsc_release_access;
+
+	/* Get number of RIFSC entries*/
+	nb_risup = readl(rifsc_controller->mmio + RIFSC_RISC_HWCFGR2) & HWCFGR2_CONF1_MASK;
+	nb_rimu = readl(rifsc_controller->mmio + RIFSC_RISC_HWCFGR2) & HWCFGR2_CONF2_MASK;
+	nb_risal = readl(rifsc_controller->mmio + RIFSC_RISC_HWCFGR2) & HWCFGR2_CONF3_MASK;
+	rifsc_controller->max_entries = nb_risup + nb_rimu + nb_risal;
+
+	platform_set_drvdata(pdev, rifsc_controller);
+
+	rc = stm32_firewall_controller_register(rifsc_controller);
+	if (rc) {
+		dev_err(rifsc_controller->dev, "Couldn't register as a firewall controller: %d",
+			rc);
+		return rc;
+	}
+
+	rc = stm32_firewall_populate_bus(rifsc_controller);
+	if (rc) {
+		dev_err(rifsc_controller->dev, "Couldn't populate RIFSC bus: %d",
+			rc);
+		return rc;
+	}
+
+	/* Populate all allowed nodes */
+	return of_platform_populate(np, NULL, NULL, &pdev->dev);
+}
+
+static const struct of_device_id stm32_rifsc_of_match[] = {
+	{ .compatible = "st,stm32mp25-rifsc" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, stm32_rifsc_of_match);
+
+static struct platform_driver stm32_rifsc_driver = {
+	.probe  = stm32_rifsc_probe,
+	.driver = {
+		.name = "stm32-rifsc",
+		.of_match_table = stm32_rifsc_of_match,
+	},
+};
+module_platform_driver(stm32_rifsc_driver);
+
+MODULE_AUTHOR("Gatien Chevallier <gatien.chevallier at foss.st.com>");
+MODULE_DESCRIPTION("STMicroelectronics RIFSC driver");
+MODULE_LICENSE("GPL");
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:35 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:35 +0100
Subject: [PATCH v7 04/13] dt-bindings: bus: document ETZPC
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-5-gatien.chevallier@foss.st.com>

Document ETZPC (Extended TrustZone protection controller). ETZPC is a
firewall controller.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
    	- Renamed access-controller to access-controllers
    	- Removal of access-control-provider property
    	- Removal of access-controller and access-controller-names
    	  declaration in the patternProperties field. Add
    	  additionalProperties: true in this field.

Changes in V5:
	- Renamed feature-domain* to access-control*

Changes in V2:
	- Corrected errors highlighted by Rob's robot
	- No longer define the maxItems for the "feature-domains"
	  property
	- Fix example (node name, status)
	- Declare "feature-domain-names" as an optional
	  property for child nodes
	- Fix description of "feature-domains" property
	- Reordered the properties so it matches ETZPC
	- Add missing "feature-domain-controller" property

 .../bindings/bus/st,stm32-etzpc.yaml          | 87 +++++++++++++++++++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml

diff --git a/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
new file mode 100644
index 000000000000..9ca0ad39bc19
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/st,stm32-etzpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Extended TrustZone protection controller
+
+description: |
+  The ETZPC configures TrustZone security in a SoC having bus masters and
+  devices with programmable-security attributes (securable resources).
+
+maintainers:
+  - Gatien Chevallier <gatien.chevallier at foss.st.com>
+
+properties:
+  compatible:
+    contains:
+      const: st,stm32-etzpc
+
+  reg:
+    maxItems: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 1
+
+  ranges: true
+
+  "#access-controller-cells":
+    const: 1
+    description:
+      Contains the firewall ID associated to the peripheral.
+
+patternProperties:
+  "^.*@[0-9a-f]+$":
+    description: Peripherals
+    type: object
+
+    additionalProperties: true
+
+    required:
+      - access-controllers
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+  - "#access-controller-cells"
+  - ranges
+
+additionalProperties: false
+
+examples:
+  - |
+    // In this example, the usart2 device refers to rifsc as its access
+    // controller.
+    // Access rights are verified before creating devices.
+
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/stm32mp13-clks.h>
+    #include <dt-bindings/reset/stm32mp13-resets.h>
+
+    etzpc: bus at 5c007000 {
+        compatible = "st,stm32-etzpc";
+        reg = <0x5c007000 0x400>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        #access-controller-cells = <1>;
+        ranges;
+
+        usart2: serial at 4c001000 {
+            compatible = "st,stm32h7-uart";
+            reg = <0x4c001000 0x400>;
+            interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
+            clocks = <&rcc USART2_K>;
+            resets = <&rcc USART2_R>;
+            wakeup-source;
+            dmas = <&dmamux1 43 0x400 0x5>,
+                    <&dmamux1 44 0x400 0x1>;
+            dma-names = "rx", "tx";
+            access-controllers = <&etzpc 17>;
+        };
+    };
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:40 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:40 +0100
Subject: [PATCH v7 09/13] bus: etzpc: introduce ETZPC firewall controller driver
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-10-gatien.chevallier@foss.st.com>

ETZPC is a peripheral and memory firewall controller that filter accesses
based on Arm TrustZone secure state and Arm CPU privilege execution level.
It handles MCU isolation as well.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V2:
	- Add controller name
	- Driver is now a module_platform_driver
	- Use error code returned by stm32_firewall_populate_bus()
	- Fix license

 MAINTAINERS               |   1 +
 drivers/bus/Makefile      |   2 +-
 drivers/bus/stm32_etzpc.c | 141 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 143 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bus/stm32_etzpc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a1152438b52d..b83b471c8b73 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20433,6 +20433,7 @@ F:	drivers/media/i2c/st-mipid02.c
 ST STM32 FIREWALL
 M:	Gatien Chevallier <gatien.chevallier at foss.st.com>
 S:	Maintained
+F:	drivers/bus/stm32_etzpc.c
 F:	drivers/bus/stm32_firewall.c
 F:	drivers/bus/stm32_rifsc.c
 
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index e50d18e1d141..cddd4984d6af 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_OMAP_INTERCONNECT)	+= omap_l3_smx.o omap_l3_noc.o
 obj-$(CONFIG_OMAP_OCP2SCP)	+= omap-ocp2scp.o
 obj-$(CONFIG_QCOM_EBI2)		+= qcom-ebi2.o
 obj-$(CONFIG_QCOM_SSC_BLOCK_BUS)	+= qcom-ssc-block-bus.o
-obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o stm32_rifsc.o
+obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o stm32_rifsc.o stm32_etzpc.o
 obj-$(CONFIG_SUN50I_DE2_BUS)	+= sun50i-de2.o
 obj-$(CONFIG_SUNXI_RSB)		+= sunxi-rsb.o
 obj-$(CONFIG_OF)		+= simple-pm-bus.o
diff --git a/drivers/bus/stm32_etzpc.c b/drivers/bus/stm32_etzpc.c
new file mode 100644
index 000000000000..7fc0f16960be
--- /dev/null
+++ b/drivers/bus/stm32_etzpc.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+#include "stm32_firewall.h"
+
+/*
+ * ETZPC registers
+ */
+#define ETZPC_DECPROT			0x10
+#define ETZPC_HWCFGR			0x3F0
+
+/*
+ * HWCFGR register
+ */
+#define ETZPC_HWCFGR_NUM_TZMA		GENMASK(7, 0)
+#define ETZPC_HWCFGR_NUM_PER_SEC	GENMASK(15, 8)
+#define ETZPC_HWCFGR_NUM_AHB_SEC	GENMASK(23, 16)
+#define ETZPC_HWCFGR_CHUNKS1N4		GENMASK(31, 24)
+
+/*
+ * ETZPC miscellaneous
+ */
+#define ETZPC_PROT_MASK			GENMASK(1, 0)
+#define ETZPC_PROT_A7NS			0x3
+#define ETZPC_DECPROT_SHIFT		1
+
+#define IDS_PER_DECPROT_REGS		16
+
+static int stm32_etzpc_grant_access(struct stm32_firewall_controller *ctrl, u32 firewall_id)
+{
+	u32 offset, reg_offset, sec_val;
+
+	if (firewall_id >= ctrl->max_entries) {
+		dev_err(ctrl->dev, "Invalid sys bus ID %u", firewall_id);
+		return -EINVAL;
+	}
+
+	/* Check access configuration, 16 peripherals per register */
+	reg_offset = ETZPC_DECPROT + 0x4 * (firewall_id / IDS_PER_DECPROT_REGS);
+	offset = (firewall_id % IDS_PER_DECPROT_REGS) << ETZPC_DECPROT_SHIFT;
+
+	/* Verify peripheral is non-secure and attributed to cortex A7 */
+	sec_val = (readl(ctrl->mmio + reg_offset) >> offset) & ETZPC_PROT_MASK;
+	if (sec_val != ETZPC_PROT_A7NS) {
+		dev_dbg(ctrl->dev, "Invalid bus configuration: reg_offset %#x, value %d\n",
+			reg_offset, sec_val);
+		return -EACCES;
+	}
+
+	return 0;
+}
+
+static void stm32_etzpc_release_access(struct stm32_firewall_controller *ctrl __maybe_unused,
+				       u32 firewall_id __maybe_unused)
+{
+}
+
+static int stm32_etzpc_probe(struct platform_device *pdev)
+{
+	struct stm32_firewall_controller *etzpc_controller;
+	struct device_node *np = pdev->dev.of_node;
+	u32 nb_per, nb_master;
+	struct resource *res;
+	void __iomem *mmio;
+	int rc;
+
+	etzpc_controller = devm_kzalloc(&pdev->dev, sizeof(*etzpc_controller), GFP_KERNEL);
+	if (!etzpc_controller)
+		return -ENOMEM;
+
+	mmio = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(mmio))
+		return PTR_ERR(mmio);
+
+	etzpc_controller->dev = &pdev->dev;
+	etzpc_controller->mmio = mmio;
+	etzpc_controller->name = dev_driver_string(etzpc_controller->dev);
+	etzpc_controller->type = STM32_PERIPHERAL_FIREWALL | STM32_MEMORY_FIREWALL;
+	etzpc_controller->grant_access = stm32_etzpc_grant_access;
+	etzpc_controller->release_access = stm32_etzpc_release_access;
+
+	/* Get number of etzpc entries*/
+	nb_per = FIELD_GET(ETZPC_HWCFGR_NUM_PER_SEC,
+			   readl(etzpc_controller->mmio + ETZPC_HWCFGR));
+	nb_master = FIELD_GET(ETZPC_HWCFGR_NUM_AHB_SEC,
+			      readl(etzpc_controller->mmio + ETZPC_HWCFGR));
+	etzpc_controller->max_entries = nb_per + nb_master;
+
+	platform_set_drvdata(pdev, etzpc_controller);
+
+	rc = stm32_firewall_controller_register(etzpc_controller);
+	if (rc) {
+		dev_err(etzpc_controller->dev, "Couldn't register as a firewall controller: %d",
+			rc);
+		return rc;
+	}
+
+	rc = stm32_firewall_populate_bus(etzpc_controller);
+	if (rc) {
+		dev_err(etzpc_controller->dev, "Couldn't populate ETZPC bus: %d",
+			rc);
+		return rc;
+	}
+
+	/* Populate all allowed nodes */
+	return of_platform_populate(np, NULL, NULL, &pdev->dev);
+}
+
+static const struct of_device_id stm32_etzpc_of_match[] = {
+	{ .compatible = "st,stm32-etzpc" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, stm32_etzpc_of_match);
+
+static struct platform_driver stm32_etzpc_driver = {
+	.probe  = stm32_etzpc_probe,
+	.driver = {
+		.name = "stm32-etzpc",
+		.of_match_table = stm32_etzpc_of_match,
+	},
+};
+module_platform_driver(stm32_etzpc_driver);
+
+MODULE_AUTHOR("Gatien Chevallier <gatien.chevallier at foss.st.com>");
+MODULE_DESCRIPTION("STMicroelectronics ETZPC driver");
+MODULE_LICENSE("GPL");
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:39 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:39 +0100
Subject: [PATCH v7 08/13] arm64: dts: st: add RIFSC as an access controller for STM32MP25x boards
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-9-gatien.chevallier@foss.st.com>

RIFSC is a firewall controller. Change its compatible so that it matches
the documentation and reference RIFSC as an access-control-provider.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V7:
    	- Added access-controllers property to sdmmc1

Changes in V6:
    	- Renamed access-controller to access-controllers
    	- Removal of access-control-provider property

Changes in V5:
    	- Renamed feature-domain* to access-control*

Changes in V2:
	- Fix rifsc node name
	- Move the "ranges" property under the
	  "feature-domains" one

 arch/arm64/boot/dts/st/stm32mp251.dtsi | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 124403f5f1f4..b36539f8ec69 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -111,11 +111,12 @@ soc at 0 {
 		interrupt-parent = <&intc>;
 		ranges = <0x0 0x0 0x0 0x80000000>;
 
-		rifsc: rifsc-bus at 42080000 {
-			compatible = "simple-bus";
+		rifsc: bus at 42080000 {
+			compatible = "st,stm32mp25-rifsc";
 			reg = <0x42080000 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+			#access-controller-cells = <1>;
 			ranges;
 
 			usart2: serial at 400e0000 {
@@ -123,6 +124,7 @@ usart2: serial at 400e0000 {
 				reg = <0x400e0000 0x400>;
 				interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&ck_flexgen_08>;
+				access-controllers = <&rifsc 32>;
 				status = "disabled";
 			};
 
@@ -136,6 +138,7 @@ sdmmc1: mmc at 48220000 {
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
 				max-frequency = <120000000>;
+				access-controllers = <&rifsc 76>;
 				status = "disabled";
 			};
 		};
-- 
2.25.1




From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:42 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:42 +0100
Subject: [PATCH v7 11/13] ARM: dts: stm32: put ETZPC as an access controller for STM32MP15x boards
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-12-gatien.chevallier@foss.st.com>

Reference ETZPC as an access-control-provider.

For more information on which peripheral is securable or supports MCU
isolation, please read the STM32MP13 reference manual

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Patch not present in V6

 arch/arm/boot/dts/st/stm32mp151.dtsi  | 64 +++++++++++++++++++++++++++
 arch/arm/boot/dts/st/stm32mp153.dtsi  |  2 +
 arch/arm/boot/dts/st/stm32mp15xc.dtsi |  1 +
 3 files changed, 67 insertions(+)

diff --git a/arch/arm/boot/dts/st/stm32mp151.dtsi b/arch/arm/boot/dts/st/stm32mp151.dtsi
index 78c0d6ccdb09..e66970cd8745 100644
--- a/arch/arm/boot/dts/st/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp151.dtsi
@@ -334,6 +334,7 @@ etzpc: bus at 5c007000 {
 			reg = <0x5c007000 0x400>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+			#access-controller-cells = <1>;
 			ranges;
 
 			timers2: timer at 40000000 {
@@ -351,6 +352,7 @@ timers2: timer at 40000000 {
 				       <&dmamux1 21 0x400 0x1>,
 				       <&dmamux1 22 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4", "up";
+				access-controllers = <&etzpc 16>;
 				status = "disabled";
 
 				pwm {
@@ -387,6 +389,7 @@ timers3: timer at 40001000 {
 				       <&dmamux1 27 0x400 0x1>,
 				       <&dmamux1 28 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+				access-controllers = <&etzpc 17>;
 				status = "disabled";
 
 				pwm {
@@ -421,6 +424,7 @@ timers4: timer at 40002000 {
 				       <&dmamux1 31 0x400 0x1>,
 				       <&dmamux1 32 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4";
+				access-controllers = <&etzpc 18>;
 				status = "disabled";
 
 				pwm {
@@ -457,6 +461,7 @@ timers5: timer at 40003000 {
 				       <&dmamux1 59 0x400 0x1>,
 				       <&dmamux1 60 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+				access-controllers = <&etzpc 19>;
 				status = "disabled";
 
 				pwm {
@@ -488,6 +493,7 @@ timers6: timer at 40004000 {
 				clock-names = "int";
 				dmas = <&dmamux1 69 0x400 0x1>;
 				dma-names = "up";
+				access-controllers = <&etzpc 20>;
 				status = "disabled";
 
 				timer at 5 {
@@ -508,6 +514,7 @@ timers7: timer at 40005000 {
 				clock-names = "int";
 				dmas = <&dmamux1 70 0x400 0x1>;
 				dma-names = "up";
+				access-controllers = <&etzpc 21>;
 				status = "disabled";
 
 				timer at 6 {
@@ -526,6 +533,7 @@ timers12: timer at 40006000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM12_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 22>;
 				status = "disabled";
 
 				pwm {
@@ -550,6 +558,7 @@ timers13: timer at 40007000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM13_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 23>;
 				status = "disabled";
 
 				pwm {
@@ -574,6 +583,7 @@ timers14: timer at 40008000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM14_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 24>;
 				status = "disabled";
 
 				pwm {
@@ -598,6 +608,7 @@ lptimer1: timer at 40009000 {
 				clocks = <&rcc LPTIM1_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 25>;
 				status = "disabled";
 
 				pwm {
@@ -626,6 +637,7 @@ i2s2: audio-controller at 4000b000 {
 				dmas = <&dmamux1 39 0x400 0x01>,
 				       <&dmamux1 40 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 27>;
 				status = "disabled";
 			};
 
@@ -640,6 +652,7 @@ spi2: spi at 4000b000 {
 				dmas = <&dmamux1 39 0x400 0x05>,
 				       <&dmamux1 40 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 27>;
 				status = "disabled";
 			};
 
@@ -651,6 +664,7 @@ i2s3: audio-controller at 4000c000 {
 				dmas = <&dmamux1 61 0x400 0x01>,
 				       <&dmamux1 62 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 28>;
 				status = "disabled";
 			};
 
@@ -665,6 +679,7 @@ spi3: spi at 4000c000 {
 				dmas = <&dmamux1 61 0x400 0x05>,
 				       <&dmamux1 62 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 28>;
 				status = "disabled";
 			};
 
@@ -678,6 +693,7 @@ spdifrx: audio-controller at 4000d000 {
 				dmas = <&dmamux1 93 0x400 0x01>,
 				       <&dmamux1 94 0x400 0x01>;
 				dma-names = "rx", "rx-ctrl";
+				access-controllers = <&etzpc 29>;
 				status = "disabled";
 			};
 
@@ -690,6 +706,7 @@ usart2: serial at 4000e000 {
 				dmas = <&dmamux1 43 0x400 0x15>,
 				       <&dmamux1 44 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 30>;
 				status = "disabled";
 			};
 
@@ -702,6 +719,7 @@ usart3: serial at 4000f000 {
 				dmas = <&dmamux1 45 0x400 0x15>,
 				       <&dmamux1 46 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 31>;
 				status = "disabled";
 			};
 
@@ -714,6 +732,7 @@ uart4: serial at 40010000 {
 				dmas = <&dmamux1 63 0x400 0x15>,
 				       <&dmamux1 64 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 32>;
 				status = "disabled";
 			};
 
@@ -726,6 +745,7 @@ uart5: serial at 40011000 {
 				dmas = <&dmamux1 65 0x400 0x15>,
 				       <&dmamux1 66 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 33>;
 				status = "disabled";
 			};
 
@@ -742,6 +762,7 @@ i2c1: i2c at 40012000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x1>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 34>;
 				status = "disabled";
 			};
 
@@ -758,6 +779,7 @@ i2c2: i2c at 40013000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x2>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 35>;
 				status = "disabled";
 			};
 
@@ -774,6 +796,7 @@ i2c3: i2c at 40014000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x4>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 36>;
 				status = "disabled";
 			};
 
@@ -790,6 +813,7 @@ i2c5: i2c at 40015000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x10>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 37>;
 				status = "disabled";
 			};
 
@@ -799,6 +823,7 @@ cec: cec at 40016000 {
 				interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&rcc CEC_K>, <&rcc CEC>;
 				clock-names = "cec", "hdmi-cec";
+				access-controllers = <&etzpc 38>;
 				status = "disabled";
 			};
 
@@ -809,6 +834,7 @@ dac: dac at 40017000 {
 				clock-names = "pclk";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 39>;
 				status = "disabled";
 
 				dac1: dac at 1 {
@@ -835,6 +861,7 @@ uart7: serial at 40018000 {
 				dmas = <&dmamux1 79 0x400 0x15>,
 				       <&dmamux1 80 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 40>;
 				status = "disabled";
 			};
 
@@ -847,6 +874,7 @@ uart8: serial at 40019000 {
 				dmas = <&dmamux1 81 0x400 0x15>,
 				       <&dmamux1 82 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 41>;
 				status = "disabled";
 			};
 
@@ -871,6 +899,7 @@ timers1: timer at 44000000 {
 				       <&dmamux1 17 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4",
 					    "up", "trig", "com";
+				access-controllers = <&etzpc 48>;
 				status = "disabled";
 
 				pwm {
@@ -912,6 +941,7 @@ timers8: timer at 44001000 {
 				       <&dmamux1 53 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4",
 					    "up", "trig", "com";
+				access-controllers = <&etzpc 49>;
 				status = "disabled";
 
 				pwm {
@@ -941,6 +971,7 @@ usart6: serial at 44003000 {
 				dmas = <&dmamux1 71 0x400 0x15>,
 				<&dmamux1 72 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 51>;
 				status = "disabled";
 			};
 
@@ -952,6 +983,7 @@ i2s1: audio-controller at 44004000 {
 				dmas = <&dmamux1 37 0x400 0x01>,
 				<&dmamux1 38 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 52>;
 				status = "disabled";
 			};
 
@@ -966,6 +998,7 @@ spi1: spi at 44004000 {
 				dmas = <&dmamux1 37 0x400 0x05>,
 				<&dmamux1 38 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 52>;
 				status = "disabled";
 			};
 
@@ -980,6 +1013,7 @@ spi4: spi at 44005000 {
 				dmas = <&dmamux1 83 0x400 0x05>,
 				<&dmamux1 84 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 53>;
 				status = "disabled";
 			};
 
@@ -997,6 +1031,7 @@ timers15: timer at 44006000 {
 				       <&dmamux1 107 0x400 0x1>,
 				       <&dmamux1 108 0x400 0x1>;
 				dma-names = "ch1", "up", "trig", "com";
+				access-controllers = <&etzpc 54>;
 				status = "disabled";
 
 				pwm {
@@ -1024,6 +1059,7 @@ timers16: timer at 44007000 {
 				dmas = <&dmamux1 109 0x400 0x1>,
 				<&dmamux1 110 0x400 0x1>;
 				dma-names = "ch1", "up";
+				access-controllers = <&etzpc 55>;
 				status = "disabled";
 
 				pwm {
@@ -1050,6 +1086,7 @@ timers17: timer at 44008000 {
 				dmas = <&dmamux1 111 0x400 0x1>,
 				<&dmamux1 112 0x400 0x1>;
 				dma-names = "ch1", "up";
+				access-controllers = <&etzpc 56>;
 				status = "disabled";
 
 				pwm {
@@ -1076,6 +1113,7 @@ spi5: spi at 44009000 {
 				dmas = <&dmamux1 85 0x400 0x05>,
 				<&dmamux1 86 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 57>;
 				status = "disabled";
 			};
 
@@ -1087,6 +1125,7 @@ sai1: sai at 4400a000 {
 				reg = <0x4400a000 0x4>, <0x4400a3f0 0x10>;
 				interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
 				resets = <&rcc SAI1_R>;
+				access-controllers = <&etzpc 58>;
 				status = "disabled";
 
 				sai1a: audio-controller at 4400a004 {
@@ -1119,6 +1158,7 @@ sai2: sai at 4400b000 {
 				reg = <0x4400b000 0x4>, <0x4400b3f0 0x10>;
 				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 				resets = <&rcc SAI2_R>;
+				access-controllers = <&etzpc 59>;
 				status = "disabled";
 
 				sai2a: audio-controller at 4400b004 {
@@ -1150,6 +1190,7 @@ sai3: sai at 4400c000 {
 				reg = <0x4400c000 0x4>, <0x4400c3f0 0x10>;
 				interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
 				resets = <&rcc SAI3_R>;
+				access-controllers = <&etzpc 60>;
 				status = "disabled";
 
 				sai3a: audio-controller at 4400c004 {
@@ -1180,6 +1221,7 @@ dfsdm: dfsdm at 4400d000 {
 				clock-names = "dfsdm";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 61>;
 				status = "disabled";
 
 				dfsdm0: filter at 0 {
@@ -1259,6 +1301,7 @@ dma1: dma-controller at 48000000 {
 				#dma-cells = <4>;
 				st,mem2mem;
 				dma-requests = <8>;
+				access-controllers = <&etzpc 88>;
 			};
 
 			dma2: dma-controller at 48001000 {
@@ -1277,6 +1320,7 @@ dma2: dma-controller at 48001000 {
 				#dma-cells = <4>;
 				st,mem2mem;
 				dma-requests = <8>;
+				access-controllers = <&etzpc 89>;
 			};
 
 			dmamux1: dma-router at 48002000 {
@@ -1288,6 +1332,7 @@ dmamux1: dma-router at 48002000 {
 				dma-channels = <16>;
 				clocks = <&rcc DMAMUX>;
 				resets = <&rcc DMAMUX_R>;
+				access-controllers = <&etzpc 90>;
 			};
 
 			adc: adc at 48003000 {
@@ -1302,6 +1347,7 @@ adc: adc at 48003000 {
 				#interrupt-cells = <1>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 72>;
 				status = "disabled";
 
 				adc1: adc at 0 {
@@ -1352,6 +1398,7 @@ sdmmc3: mmc at 48004000 {
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
 				max-frequency = <120000000>;
+				access-controllers = <&etzpc 86>;
 				status = "disabled";
 			};
 
@@ -1369,6 +1416,7 @@ usbotg_hs: usb-otg at 49000000 {
 				dr_mode = "otg";
 				otg-rev = <0x200>;
 				usb33d-supply = <&usb33>;
+				access-controllers = <&etzpc 85>;
 				status = "disabled";
 			};
 
@@ -1381,6 +1429,7 @@ dcmi: dcmi at 4c006000 {
 				clock-names = "mclk";
 				dmas = <&dmamux1 75 0x400 0x01>;
 				dma-names = "tx";
+				access-controllers = <&etzpc 70>;
 				status = "disabled";
 			};
 
@@ -1393,6 +1442,7 @@ lptimer2: timer at 50021000 {
 				clocks = <&rcc LPTIM2_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 64>;
 				status = "disabled";
 
 				pwm {
@@ -1422,6 +1472,7 @@ lptimer3: timer at 50022000 {
 				clocks = <&rcc LPTIM3_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 65>;
 				status = "disabled";
 
 				pwm {
@@ -1444,6 +1495,7 @@ lptimer4: timer at 50023000 {
 				clocks = <&rcc LPTIM4_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 66>;
 				status = "disabled";
 
 				pwm {
@@ -1460,6 +1512,7 @@ lptimer5: timer at 50024000 {
 				clocks = <&rcc LPTIM5_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 67>;
 				status = "disabled";
 
 				pwm {
@@ -1475,6 +1528,7 @@ vrefbuf: vrefbuf at 50025000 {
 				regulator-min-microvolt = <1500000>;
 				regulator-max-microvolt = <2500000>;
 				clocks = <&rcc VREF>;
+				access-controllers = <&etzpc 69>;
 				status = "disabled";
 			};
 
@@ -1486,6 +1540,7 @@ sai4: sai at 50027000 {
 				reg = <0x50027000 0x4>, <0x500273f0 0x10>;
 				interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
 				resets = <&rcc SAI4_R>;
+				access-controllers = <&etzpc 68>;
 				status = "disabled";
 
 				sai4a: audio-controller at 50027004 {
@@ -1518,6 +1573,7 @@ hash1: hash at 54002000 {
 				dmas = <&mdma1 31 0x2 0x1000A02 0x0 0x0>;
 				dma-names = "in";
 				dma-maxburst = <2>;
+				access-controllers = <&etzpc 8>;
 				status = "disabled";
 			};
 
@@ -1526,6 +1582,7 @@ rng1: rng at 54003000 {
 				reg = <0x54003000 0x400>;
 				clocks = <&rcc RNG1_K>;
 				resets = <&rcc RNG1_R>;
+				access-controllers = <&etzpc 7>;
 				status = "okay";
 			};
 
@@ -1536,6 +1593,7 @@ fmc: memory-controller at 58002000 {
 				reg = <0x58002000 0x1000>;
 				clocks = <&rcc FMC_K>;
 				resets = <&rcc FMC_R>;
+				access-controllers = <&etzpc 91>;
 				status = "disabled";
 
 				ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
@@ -1575,6 +1633,7 @@ qspi: spi at 58003000 {
 				resets = <&rcc QSPI_R>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 92>;
 				status = "disabled";
 			};
 
@@ -1602,6 +1661,7 @@ ethernet0: ethernet at 5800a000 {
 				snps,en-tx-lpi-clockgating;
 				snps,axi-config = <&stmmac_axi_config_0>;
 				snps,tso;
+				access-controllers = <&etzpc 94>;
 				status = "disabled";
 
 				stmmac_axi_config_0: stmmac-axi-config {
@@ -1617,6 +1677,7 @@ usart1: serial at 5c000000 {
 				interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&rcc USART1_K>;
 				wakeup-source;
+				access-controllers = <&etzpc 3>;
 				status = "disabled";
 			};
 
@@ -1630,6 +1691,7 @@ spi6: spi at 5c001000 {
 				resets = <&rcc SPI6_R>;
 				dmas = <&mdma1 34 0x0 0x40008 0x0 0x0>,
 				       <&mdma1 35 0x0 0x40002 0x0 0x0>;
+				access-controllers = <&etzpc 4>;
 				dma-names = "rx", "tx";
 				status = "disabled";
 			};
@@ -1647,6 +1709,7 @@ i2c4: i2c at 5c002000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x8>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 5>;
 				status = "disabled";
 			};
 
@@ -1663,6 +1726,7 @@ i2c6: i2c at 5c009000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x20>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 12>;
 				status = "disabled";
 			};
 		};
diff --git a/arch/arm/boot/dts/st/stm32mp153.dtsi b/arch/arm/boot/dts/st/stm32mp153.dtsi
index 36e17ea0b179..4640dafb1598 100644
--- a/arch/arm/boot/dts/st/stm32mp153.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp153.dtsi
@@ -41,6 +41,7 @@ m_can1: can at 4400e000 {
 		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
 		clock-names = "hclk", "cclk";
 		bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+		access-controllers = <&etzpc 62>;
 		status = "disabled";
 	};
 
@@ -54,6 +55,7 @@ m_can2: can at 4400f000 {
 		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
 		clock-names = "hclk", "cclk";
 		bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
+		access-controllers = <&etzpc 62>;
 		status = "disabled";
 	};
 };
diff --git a/arch/arm/boot/dts/st/stm32mp15xc.dtsi b/arch/arm/boot/dts/st/stm32mp15xc.dtsi
index d36c3457451a..97465717f932 100644
--- a/arch/arm/boot/dts/st/stm32mp15xc.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xc.dtsi
@@ -11,6 +11,7 @@ cryp1: cryp at 54001000 {
 		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&rcc CRYP1>;
 		resets = <&rcc CRYP1_R>;
+		access-controllers = <&etzpc 9>;
 		status = "disabled";
 	};
 };
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:41 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:41 +0100
Subject: [PATCH v7 10/13] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-11-gatien.chevallier@foss.st.com>

ETZPC is a firewall controller. Put all peripherals filtered by the
ETZPC as ETZPC subnodes and keep the "simple-bus" compatible for
backward compatibility.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V7:
    	- Keep simple-bus compatible
    	- Remove access-controllers reference in this patch

Changes in V6:
    	- Renamed access-controller to access-controllers
    	- Removal of access-control-provider property

Changes in V5:
    	- Renamed feature-domain* to access-control*

 arch/arm/boot/dts/st/stm32mp151.dtsi  | 2676 +++++++++++++------------
 arch/arm/boot/dts/st/stm32mp153.dtsi  |   50 +-
 arch/arm/boot/dts/st/stm32mp15xc.dtsi |   18 +-
 3 files changed, 1375 insertions(+), 1369 deletions(-)

diff --git a/arch/arm/boot/dts/st/stm32mp151.dtsi b/arch/arm/boot/dts/st/stm32mp151.dtsi
index 61508917521c..78c0d6ccdb09 100644
--- a/arch/arm/boot/dts/st/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp151.dtsi
@@ -122,1543 +122,1551 @@ soc {
 		interrupt-parent = <&intc>;
 		ranges;
 
-		timers2: timer at 40000000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40000000 0x400>;
-			interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM2_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 18 0x400 0x1>,
-			       <&dmamux1 19 0x400 0x1>,
-			       <&dmamux1 20 0x400 0x1>,
-			       <&dmamux1 21 0x400 0x1>,
-			       <&dmamux1 22 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4", "up";
+		ipcc: mailbox at 4c001000 {
+			compatible = "st,stm32mp1-ipcc";
+			#mbox-cells = <1>;
+			reg = <0x4c001000 0x400>;
+			st,proc-id = <0>;
+			interrupts-extended =
+				<&exti 61 1>,
+				<&intc GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "rx", "tx";
+			clocks = <&rcc IPCC>;
+			wakeup-source;
 			status = "disabled";
+		};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 1 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <1>;
-				status = "disabled";
-			};
-
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
-			};
+		rcc: rcc at 50000000 {
+			compatible = "st,stm32mp1-rcc", "syscon";
+			reg = <0x50000000 0x1000>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
 		};
 
-		timers3: timer at 40001000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40001000 0x400>;
-			interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM3_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 23 0x400 0x1>,
-			       <&dmamux1 24 0x400 0x1>,
-			       <&dmamux1 25 0x400 0x1>,
-			       <&dmamux1 26 0x400 0x1>,
-			       <&dmamux1 27 0x400 0x1>,
-			       <&dmamux1 28 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
-			status = "disabled";
+		pwr_regulators: pwr at 50001000 {
+			compatible = "st,stm32mp1,pwr-reg";
+			reg = <0x50001000 0x10>;
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
+			reg11: reg11 {
+				regulator-name = "reg11";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
 			};
 
-			timer at 2 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <2>;
-				status = "disabled";
+			reg18: reg18 {
+				regulator-name = "reg18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
 			};
 
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
+			usb33: usb33 {
+				regulator-name = "usb33";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
 			};
 		};
 
-		timers4: timer at 40002000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40002000 0x400>;
-			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM4_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 29 0x400 0x1>,
-			       <&dmamux1 30 0x400 0x1>,
-			       <&dmamux1 31 0x400 0x1>,
-			       <&dmamux1 32 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
+		pwr_mcu: pwr_mcu at 50001014 {
+			compatible = "st,stm32mp151-pwr-mcu", "syscon";
+			reg = <0x50001014 0x4>;
+		};
 
-			timer at 3 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <3>;
-				status = "disabled";
-			};
+		exti: interrupt-controller at 5000d000 {
+			compatible = "st,stm32mp1-exti", "syscon";
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			reg = <0x5000d000 0x400>;
+		};
 
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
-			};
+		syscfg: syscon at 50020000 {
+			compatible = "st,stm32mp157-syscfg", "syscon";
+			reg = <0x50020000 0x400>;
+			clocks = <&rcc SYSCFG>;
 		};
 
-		timers5: timer at 40003000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40003000 0x400>;
-			interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM5_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 55 0x400 0x1>,
-			       <&dmamux1 56 0x400 0x1>,
-			       <&dmamux1 57 0x400 0x1>,
-			       <&dmamux1 58 0x400 0x1>,
-			       <&dmamux1 59 0x400 0x1>,
-			       <&dmamux1 60 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+		dts: thermal at 50028000 {
+			compatible = "st,stm32-thermal";
+			reg = <0x50028000 0x100>;
+			interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc TMPSENS>;
+			clock-names = "pclk";
+			#thermal-sensor-cells = <0>;
 			status = "disabled";
+		};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 4 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <4>;
-				status = "disabled";
-			};
-
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
-			};
+		mdma1: dma-controller at 58000000 {
+			compatible = "st,stm32h7-mdma";
+			reg = <0x58000000 0x1000>;
+			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc MDMA>;
+			resets = <&rcc MDMA_R>;
+			#dma-cells = <5>;
+			dma-channels = <32>;
+			dma-requests = <48>;
 		};
 
-		timers6: timer at 40004000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40004000 0x400>;
-			interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM6_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 69 0x400 0x1>;
-			dma-names = "up";
+		sdmmc1: mmc at 58005000 {
+			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+			arm,primecell-periphid = <0x00253180>;
+			reg = <0x58005000 0x1000>;
+			interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc SDMMC1_K>;
+			clock-names = "apb_pclk";
+			resets = <&rcc SDMMC1_R>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			max-frequency = <120000000>;
 			status = "disabled";
-
-			timer at 5 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <5>;
-				status = "disabled";
-			};
 		};
 
-		timers7: timer at 40005000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40005000 0x400>;
-			interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM7_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 70 0x400 0x1>;
-			dma-names = "up";
+		sdmmc2: mmc at 58007000 {
+			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+			arm,primecell-periphid = <0x00253180>;
+			reg = <0x58007000 0x1000>;
+			interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc SDMMC2_K>;
+			clock-names = "apb_pclk";
+			resets = <&rcc SDMMC2_R>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			max-frequency = <120000000>;
 			status = "disabled";
-
-			timer at 6 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <6>;
-				status = "disabled";
-			};
 		};
 
-		timers12: timer at 40006000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40006000 0x400>;
-			interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM12_K>;
-			clock-names = "int";
+		crc1: crc at 58009000 {
+			compatible = "st,stm32f7-crc";
+			reg = <0x58009000 0x400>;
+			clocks = <&rcc CRC1>;
 			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 11 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <11>;
-				status = "disabled";
-			};
 		};
 
-		timers13: timer at 40007000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40007000 0x400>;
-			interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM13_K>;
-			clock-names = "int";
+		usbh_ohci: usb at 5800c000 {
+			compatible = "generic-ohci";
+			reg = <0x5800c000 0x1000>;
+			clocks = <&usbphyc>, <&rcc USBH>;
+			resets = <&rcc USBH_R>;
+			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 12 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <12>;
-				status = "disabled";
-			};
 		};
 
-		timers14: timer at 40008000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40008000 0x400>;
-			interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM14_K>;
-			clock-names = "int";
+		usbh_ehci: usb at 5800d000 {
+			compatible = "generic-ehci";
+			reg = <0x5800d000 0x1000>;
+			clocks = <&usbphyc>, <&rcc USBH>;
+			resets = <&rcc USBH_R>;
+			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+			companion = <&usbh_ohci>;
 			status = "disabled";
+		};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
+		ltdc: display-controller at 5a001000 {
+			compatible = "st,stm32-ltdc";
+			reg = <0x5a001000 0x400>;
+			interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc LTDC_PX>;
+			clock-names = "lcd";
+			resets = <&rcc LTDC_R>;
+			status = "disabled";
+		};
 
-			timer at 13 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <13>;
-				status = "disabled";
-			};
+		iwdg2: watchdog at 5a002000 {
+			compatible = "st,stm32mp1-iwdg";
+			reg = <0x5a002000 0x400>;
+			clocks = <&rcc IWDG2>, <&rcc CK_LSI>;
+			clock-names = "pclk", "lsi";
+			status = "disabled";
 		};
 
-		lptimer1: timer at 40009000 {
+		usbphyc: usbphyc at 5a006000 {
 			#address-cells = <1>;
 			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x40009000 0x400>;
-			interrupts-extended = <&exti 47 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM1_K>;
-			clock-names = "mux";
-			wakeup-source;
+			#clock-cells = <0>;
+			compatible = "st,stm32mp1-usbphyc";
+			reg = <0x5a006000 0x1000>;
+			clocks = <&rcc USBPHY_K>;
+			resets = <&rcc USBPHY_R>;
+			vdda1v1-supply = <&reg11>;
+			vdda1v8-supply = <&reg18>;
 			status = "disabled";
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			trigger at 0 {
-				compatible = "st,stm32-lptimer-trigger";
+			usbphyc_port0: usb-phy at 0 {
+				#phy-cells = <0>;
 				reg = <0>;
-				status = "disabled";
 			};
 
-			counter {
-				compatible = "st,stm32-lptimer-counter";
-				status = "disabled";
+			usbphyc_port1: usb-phy at 1 {
+				#phy-cells = <1>;
+				reg = <1>;
 			};
 		};
 
-		spi2: spi at 4000b000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x4000b000 0x400>;
-			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI2_K>;
-			resets = <&rcc SPI2_R>;
-			dmas = <&dmamux1 39 0x400 0x05>,
-			       <&dmamux1 40 0x400 0x05>;
-			dma-names = "rx", "tx";
+		rtc: rtc at 5c004000 {
+			compatible = "st,stm32mp1-rtc";
+			reg = <0x5c004000 0x400>;
+			clocks = <&rcc RTCAPB>, <&rcc RTC>;
+			clock-names = "pclk", "rtc_ck";
+			interrupts-extended = <&exti 19 IRQ_TYPE_LEVEL_HIGH>;
 			status = "disabled";
 		};
 
-		i2s2: audio-controller at 4000b000 {
-			compatible = "st,stm32h7-i2s";
-			#sound-dai-cells = <0>;
-			reg = <0x4000b000 0x400>;
-			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 39 0x400 0x01>,
-			       <&dmamux1 40 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
+		bsec: efuse at 5c005000 {
+			compatible = "st,stm32mp15-bsec";
+			reg = <0x5c005000 0x400>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			part_number_otp: part-number-otp at 4 {
+				reg = <0x4 0x1>;
+			};
+			vrefint: vrefin-cal at 52 {
+				reg = <0x52 0x2>;
+			};
+			ts_cal1: calib at 5c {
+				reg = <0x5c 0x2>;
+			};
+			ts_cal2: calib at 5e {
+				reg = <0x5e 0x2>;
+			};
 		};
 
-		spi3: spi at 4000c000 {
+		etzpc: bus at 5c007000 {
+			compatible = "st,stm32-etzpc";
+			reg = <0x5c007000 0x400>;
 			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x4000c000 0x400>;
-			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI3_K>;
-			resets = <&rcc SPI3_R>;
-			dmas = <&dmamux1 61 0x400 0x05>,
-			       <&dmamux1 62 0x400 0x05>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			#size-cells = <1>;
+			ranges;
 
-		i2s3: audio-controller at 4000c000 {
-			compatible = "st,stm32h7-i2s";
-			#sound-dai-cells = <0>;
-			reg = <0x4000c000 0x400>;
-			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 61 0x400 0x01>,
-			       <&dmamux1 62 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			timers2: timer at 40000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40000000 0x400>;
+				interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM2_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 18 0x400 0x1>,
+				       <&dmamux1 19 0x400 0x1>,
+				       <&dmamux1 20 0x400 0x1>,
+				       <&dmamux1 21 0x400 0x1>,
+				       <&dmamux1 22 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		spdifrx: audio-controller at 4000d000 {
-			compatible = "st,stm32h7-spdifrx";
-			#sound-dai-cells = <0>;
-			reg = <0x4000d000 0x400>;
-			clocks = <&rcc SPDIF_K>;
-			clock-names = "kclk";
-			interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 93 0x400 0x01>,
-			       <&dmamux1 94 0x400 0x01>;
-			dma-names = "rx", "rx-ctrl";
-			status = "disabled";
-		};
+				timer at 1 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <1>;
+					status = "disabled";
+				};
 
-		usart2: serial at 4000e000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x4000e000 0x400>;
-			interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART2_K>;
-			wakeup-source;
-			dmas = <&dmamux1 43 0x400 0x15>,
-			       <&dmamux1 44 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
 
-		usart3: serial at 4000f000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x4000f000 0x400>;
-			interrupts-extended = <&exti 28 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART3_K>;
-			wakeup-source;
-			dmas = <&dmamux1 45 0x400 0x15>,
-			       <&dmamux1 46 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			timers3: timer at 40001000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40001000 0x400>;
+				interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM3_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 23 0x400 0x1>,
+				       <&dmamux1 24 0x400 0x1>,
+				       <&dmamux1 25 0x400 0x1>,
+				       <&dmamux1 26 0x400 0x1>,
+				       <&dmamux1 27 0x400 0x1>,
+				       <&dmamux1 28 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		uart4: serial at 40010000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x40010000 0x400>;
-			interrupts-extended = <&exti 30 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc UART4_K>;
-			wakeup-source;
-			dmas = <&dmamux1 63 0x400 0x15>,
-			       <&dmamux1 64 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+				timer at 2 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <2>;
+					status = "disabled";
+				};
 
-		uart5: serial at 40011000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x40011000 0x400>;
-			interrupts-extended = <&exti 31 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc UART5_K>;
-			wakeup-source;
-			dmas = <&dmamux1 65 0x400 0x15>,
-			       <&dmamux1 66 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
 
-		i2c1: i2c at 40012000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x40012000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C1_K>;
-			resets = <&rcc I2C1_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x1>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
+			timers4: timer at 40002000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40002000 0x400>;
+				interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM4_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 29 0x400 0x1>,
+				       <&dmamux1 30 0x400 0x1>,
+				       <&dmamux1 31 0x400 0x1>,
+				       <&dmamux1 32 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		i2c2: i2c at 40013000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x40013000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C2_K>;
-			resets = <&rcc I2C2_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x2>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
+				timer at 3 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <3>;
+					status = "disabled";
+				};
 
-		i2c3: i2c at 40014000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x40014000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C3_K>;
-			resets = <&rcc I2C3_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x4>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
 
-		i2c5: i2c at 40015000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x40015000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C5_K>;
-			resets = <&rcc I2C5_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x10>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
+			timers5: timer at 40003000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40003000 0x400>;
+				interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM5_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 55 0x400 0x1>,
+				       <&dmamux1 56 0x400 0x1>,
+				       <&dmamux1 57 0x400 0x1>,
+				       <&dmamux1 58 0x400 0x1>,
+				       <&dmamux1 59 0x400 0x1>,
+				       <&dmamux1 60 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		cec: cec at 40016000 {
-			compatible = "st,stm32-cec";
-			reg = <0x40016000 0x400>;
-			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CEC_K>, <&rcc CEC>;
-			clock-names = "cec", "hdmi-cec";
-			status = "disabled";
-		};
+				timer at 4 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <4>;
+					status = "disabled";
+				};
 
-		dac: dac at 40017000 {
-			compatible = "st,stm32h7-dac-core";
-			reg = <0x40017000 0x400>;
-			clocks = <&rcc DAC12>;
-			clock-names = "pclk";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
 
-			dac1: dac at 1 {
-				compatible = "st,stm32-dac";
-				#io-channel-cells = <1>;
-				reg = <1>;
-				status = "disabled";
+			timers6: timer at 40004000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40004000 0x400>;
+				interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM6_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 69 0x400 0x1>;
+				dma-names = "up";
+				status = "disabled";
+
+				timer at 5 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <5>;
+					status = "disabled";
+				};
 			};
 
-			dac2: dac at 2 {
-				compatible = "st,stm32-dac";
-				#io-channel-cells = <1>;
-				reg = <2>;
-				status = "disabled";
+			timers7: timer at 40005000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40005000 0x400>;
+				interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM7_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 70 0x400 0x1>;
+				dma-names = "up";
+				status = "disabled";
+
+				timer at 6 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <6>;
+					status = "disabled";
+				};
 			};
-		};
 
-		uart7: serial at 40018000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x40018000 0x400>;
-			interrupts-extended = <&exti 32 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc UART7_K>;
-			wakeup-source;
-			dmas = <&dmamux1 79 0x400 0x15>,
-			       <&dmamux1 80 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			timers12: timer at 40006000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40006000 0x400>;
+				interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM12_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		uart8: serial at 40019000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x40019000 0x400>;
-			interrupts-extended = <&exti 33 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc UART8_K>;
-			wakeup-source;
-			dmas = <&dmamux1 81 0x400 0x15>,
-			       <&dmamux1 82 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+				timer at 11 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <11>;
+					status = "disabled";
+				};
+			};
 
-		timers1: timer at 44000000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44000000 0x400>;
-			interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "brk", "up", "trg-com", "cc";
-			clocks = <&rcc TIM1_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 11 0x400 0x1>,
-			       <&dmamux1 12 0x400 0x1>,
-			       <&dmamux1 13 0x400 0x1>,
-			       <&dmamux1 14 0x400 0x1>,
-			       <&dmamux1 15 0x400 0x1>,
-			       <&dmamux1 16 0x400 0x1>,
-			       <&dmamux1 17 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4",
-				    "up", "trig", "com";
-			status = "disabled";
+			timers13: timer at 40007000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40007000 0x400>;
+				interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM13_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
+				timer at 12 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <12>;
+					status = "disabled";
+				};
 			};
 
-			timer at 0 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <0>;
-				status = "disabled";
-			};
+			timers14: timer at 40008000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40008000 0x400>;
+				interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM14_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
+				timer at 13 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <13>;
+					status = "disabled";
+				};
 			};
-		};
 
-		timers8: timer at 44001000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44001000 0x400>;
-			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "brk", "up", "trg-com", "cc";
-			clocks = <&rcc TIM8_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 47 0x400 0x1>,
-			       <&dmamux1 48 0x400 0x1>,
-			       <&dmamux1 49 0x400 0x1>,
-			       <&dmamux1 50 0x400 0x1>,
-			       <&dmamux1 51 0x400 0x1>,
-			       <&dmamux1 52 0x400 0x1>,
-			       <&dmamux1 53 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4",
-				    "up", "trig", "com";
-			status = "disabled";
+			lptimer1: timer at 40009000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x40009000 0x400>;
+				interrupts-extended = <&exti 47 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM1_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
+				trigger at 0 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <0>;
+					status = "disabled";
+				};
+
+				counter {
+					compatible = "st,stm32-lptimer-counter";
+					status = "disabled";
+				};
 			};
 
-			timer at 7 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <7>;
+			i2s2: audio-controller at 4000b000 {
+				compatible = "st,stm32h7-i2s";
+				#sound-dai-cells = <0>;
+				reg = <0x4000b000 0x400>;
+				interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 39 0x400 0x01>,
+				       <&dmamux1 40 0x400 0x01>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			counter {
-				compatible = "st,stm32-timer-counter";
+			spi2: spi at 4000b000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x4000b000 0x400>;
+				interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI2_K>;
+				resets = <&rcc SPI2_R>;
+				dmas = <&dmamux1 39 0x400 0x05>,
+				       <&dmamux1 40 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
-
-		usart6: serial at 44003000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x44003000 0x400>;
-			interrupts-extended = <&exti 29 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART6_K>;
-			wakeup-source;
-			dmas = <&dmamux1 71 0x400 0x15>,
-			       <&dmamux1 72 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		spi1: spi at 44004000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x44004000 0x400>;
-			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI1_K>;
-			resets = <&rcc SPI1_R>;
-			dmas = <&dmamux1 37 0x400 0x05>,
-			       <&dmamux1 38 0x400 0x05>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		i2s1: audio-controller at 44004000 {
-			compatible = "st,stm32h7-i2s";
-			#sound-dai-cells = <0>;
-			reg = <0x44004000 0x400>;
-			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 37 0x400 0x01>,
-			       <&dmamux1 38 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
 
-		spi4: spi at 44005000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x44005000 0x400>;
-			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI4_K>;
-			resets = <&rcc SPI4_R>;
-			dmas = <&dmamux1 83 0x400 0x05>,
-			       <&dmamux1 84 0x400 0x05>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		timers15: timer at 44006000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44006000 0x400>;
-			interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM15_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 105 0x400 0x1>,
-			       <&dmamux1 106 0x400 0x1>,
-			       <&dmamux1 107 0x400 0x1>,
-			       <&dmamux1 108 0x400 0x1>;
-			dma-names = "ch1", "up", "trig", "com";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
+			i2s3: audio-controller at 4000c000 {
+				compatible = "st,stm32h7-i2s";
+				#sound-dai-cells = <0>;
+				reg = <0x4000c000 0x400>;
+				interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 61 0x400 0x01>,
+				       <&dmamux1 62 0x400 0x01>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			timer at 14 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <14>;
+			spi3: spi at 4000c000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x4000c000 0x400>;
+				interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI3_K>;
+				resets = <&rcc SPI3_R>;
+				dmas = <&dmamux1 61 0x400 0x05>,
+				       <&dmamux1 62 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
-
-		timers16: timer at 44007000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44007000 0x400>;
-			interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM16_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 109 0x400 0x1>,
-			       <&dmamux1 110 0x400 0x1>;
-			dma-names = "ch1", "up";
-			status = "disabled";
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
+			spdifrx: audio-controller at 4000d000 {
+				compatible = "st,stm32h7-spdifrx";
+				#sound-dai-cells = <0>;
+				reg = <0x4000d000 0x400>;
+				clocks = <&rcc SPDIF_K>;
+				clock-names = "kclk";
+				interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 93 0x400 0x01>,
+				       <&dmamux1 94 0x400 0x01>;
+				dma-names = "rx", "rx-ctrl";
+				status = "disabled";
+			};
+
+			usart2: serial at 4000e000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x4000e000 0x400>;
+				interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART2_K>;
+				wakeup-source;
+				dmas = <&dmamux1 43 0x400 0x15>,
+				       <&dmamux1 44 0x400 0x11>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			usart3: serial at 4000f000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x4000f000 0x400>;
+				interrupts-extended = <&exti 28 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART3_K>;
+				wakeup-source;
+				dmas = <&dmamux1 45 0x400 0x15>,
+				       <&dmamux1 46 0x400 0x11>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			uart4: serial at 40010000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x40010000 0x400>;
+				interrupts-extended = <&exti 30 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc UART4_K>;
+				wakeup-source;
+				dmas = <&dmamux1 63 0x400 0x15>,
+				       <&dmamux1 64 0x400 0x11>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			uart5: serial at 40011000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x40011000 0x400>;
+				interrupts-extended = <&exti 31 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc UART5_K>;
+				wakeup-source;
+				dmas = <&dmamux1 65 0x400 0x15>,
+				       <&dmamux1 66 0x400 0x11>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			i2c1: i2c at 40012000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x40012000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C1_K>;
+				resets = <&rcc I2C1_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x1>;
+				wakeup-source;
+				i2c-analog-filter;
 				status = "disabled";
 			};
-			timer at 15 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <15>;
+
+			i2c2: i2c at 40013000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x40013000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C2_K>;
+				resets = <&rcc I2C2_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x2>;
+				wakeup-source;
+				i2c-analog-filter;
 				status = "disabled";
 			};
-		};
 
-		timers17: timer at 44008000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44008000 0x400>;
-			interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM17_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 111 0x400 0x1>,
-			       <&dmamux1 112 0x400 0x1>;
-			dma-names = "ch1", "up";
-			status = "disabled";
+			i2c3: i2c at 40014000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x40014000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C3_K>;
+				resets = <&rcc I2C3_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x4>;
+				wakeup-source;
+				i2c-analog-filter;
+				status = "disabled";
+			};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
+			i2c5: i2c at 40015000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x40015000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C5_K>;
+				resets = <&rcc I2C5_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x10>;
+				wakeup-source;
+				i2c-analog-filter;
 				status = "disabled";
 			};
 
-			timer at 16 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <16>;
+			cec: cec at 40016000 {
+				compatible = "st,stm32-cec";
+				reg = <0x40016000 0x400>;
+				interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CEC_K>, <&rcc CEC>;
+				clock-names = "cec", "hdmi-cec";
 				status = "disabled";
 			};
-		};
 
-		spi5: spi at 44009000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x44009000 0x400>;
-			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI5_K>;
-			resets = <&rcc SPI5_R>;
-			dmas = <&dmamux1 85 0x400 0x05>,
-			       <&dmamux1 86 0x400 0x05>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			dac: dac at 40017000 {
+				compatible = "st,stm32h7-dac-core";
+				reg = <0x40017000 0x400>;
+				clocks = <&rcc DAC12>;
+				clock-names = "pclk";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
 
-		sai1: sai at 4400a000 {
-			compatible = "st,stm32h7-sai";
-			#address-cells = <1>;
-			#size-cells = <1>;
-			ranges = <0 0x4400a000 0x400>;
-			reg = <0x4400a000 0x4>, <0x4400a3f0 0x10>;
-			interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc SAI1_R>;
-			status = "disabled";
+				dac1: dac at 1 {
+					compatible = "st,stm32-dac";
+					#io-channel-cells = <1>;
+					reg = <1>;
+					status = "disabled";
+				};
 
-			sai1a: audio-controller at 4400a004 {
-				#sound-dai-cells = <0>;
+				dac2: dac at 2 {
+					compatible = "st,stm32-dac";
+					#io-channel-cells = <1>;
+					reg = <2>;
+					status = "disabled";
+				};
+			};
 
-				compatible = "st,stm32-sai-sub-a";
-				reg = <0x4 0x20>;
-				clocks = <&rcc SAI1_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 87 0x400 0x01>;
+			uart7: serial at 40018000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x40018000 0x400>;
+				interrupts-extended = <&exti 32 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc UART7_K>;
+				wakeup-source;
+				dmas = <&dmamux1 79 0x400 0x15>,
+				       <&dmamux1 80 0x400 0x11>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			sai1b: audio-controller at 4400a024 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-b";
-				reg = <0x24 0x20>;
-				clocks = <&rcc SAI1_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 88 0x400 0x01>;
+			uart8: serial at 40019000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x40019000 0x400>;
+				interrupts-extended = <&exti 33 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc UART8_K>;
+				wakeup-source;
+				dmas = <&dmamux1 81 0x400 0x15>,
+				       <&dmamux1 82 0x400 0x11>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
 
-		sai2: sai at 4400b000 {
-			compatible = "st,stm32h7-sai";
-			#address-cells = <1>;
-			#size-cells = <1>;
-			ranges = <0 0x4400b000 0x400>;
-			reg = <0x4400b000 0x4>, <0x4400b3f0 0x10>;
-			interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc SAI2_R>;
-			status = "disabled";
+			timers1: timer at 44000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44000000 0x400>;
+				interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "brk", "up", "trg-com", "cc";
+				clocks = <&rcc TIM1_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 11 0x400 0x1>,
+				       <&dmamux1 12 0x400 0x1>,
+				       <&dmamux1 13 0x400 0x1>,
+				       <&dmamux1 14 0x400 0x1>,
+				       <&dmamux1 15 0x400 0x1>,
+				       <&dmamux1 16 0x400 0x1>,
+				       <&dmamux1 17 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4",
+					    "up", "trig", "com";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			sai2a: audio-controller at 4400b004 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-a";
-				reg = <0x4 0x20>;
-				clocks = <&rcc SAI2_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 89 0x400 0x01>;
-				status = "disabled";
-			};
+				timer at 0 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <0>;
+					status = "disabled";
+				};
 
-			sai2b: audio-controller at 4400b024 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-b";
-				reg = <0x24 0x20>;
-				clocks = <&rcc SAI2_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 90 0x400 0x01>;
-				status = "disabled";
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
 			};
-		};
 
-		sai3: sai at 4400c000 {
-			compatible = "st,stm32h7-sai";
-			#address-cells = <1>;
-			#size-cells = <1>;
-			ranges = <0 0x4400c000 0x400>;
-			reg = <0x4400c000 0x4>, <0x4400c3f0 0x10>;
-			interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc SAI3_R>;
-			status = "disabled";
+			timers8: timer at 44001000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44001000 0x400>;
+				interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "brk", "up", "trg-com", "cc";
+				clocks = <&rcc TIM8_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 47 0x400 0x1>,
+				       <&dmamux1 48 0x400 0x1>,
+				       <&dmamux1 49 0x400 0x1>,
+				       <&dmamux1 50 0x400 0x1>,
+				       <&dmamux1 51 0x400 0x1>,
+				       <&dmamux1 52 0x400 0x1>,
+				       <&dmamux1 53 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4",
+					    "up", "trig", "com";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			sai3a: audio-controller at 4400c004 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-a";
-				reg = <0x04 0x20>;
-				clocks = <&rcc SAI3_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 113 0x400 0x01>;
+				timer at 7 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <7>;
+					status = "disabled";
+				};
+
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
+
+			usart6: serial at 44003000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x44003000 0x400>;
+				interrupts-extended = <&exti 29 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART6_K>;
+				wakeup-source;
+				dmas = <&dmamux1 71 0x400 0x15>,
+				<&dmamux1 72 0x400 0x11>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			sai3b: audio-controller at 4400c024 {
+			i2s1: audio-controller at 44004000 {
+				compatible = "st,stm32h7-i2s";
 				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-b";
-				reg = <0x24 0x20>;
-				clocks = <&rcc SAI3_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 114 0x400 0x01>;
+				reg = <0x44004000 0x400>;
+				interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 37 0x400 0x01>,
+				<&dmamux1 38 0x400 0x01>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
-
-		dfsdm: dfsdm at 4400d000 {
-			compatible = "st,stm32mp1-dfsdm";
-			reg = <0x4400d000 0x800>;
-			clocks = <&rcc DFSDM_K>;
-			clock-names = "dfsdm";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
 
-			dfsdm0: filter at 0 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <0>;
-				interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 101 0x400 0x01>;
-				dma-names = "rx";
+			spi1: spi at 44004000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x44004000 0x400>;
+				interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI1_K>;
+				resets = <&rcc SPI1_R>;
+				dmas = <&dmamux1 37 0x400 0x05>,
+				<&dmamux1 38 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			dfsdm1: filter at 1 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <1>;
-				interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 102 0x400 0x01>;
-				dma-names = "rx";
+			spi4: spi at 44005000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x44005000 0x400>;
+				interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI4_K>;
+				resets = <&rcc SPI4_R>;
+				dmas = <&dmamux1 83 0x400 0x05>,
+				<&dmamux1 84 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			dfsdm2: filter at 2 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <2>;
-				interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 103 0x400 0x01>;
-				dma-names = "rx";
-				status = "disabled";
+			timers15: timer at 44006000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44006000 0x400>;
+				interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM15_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 105 0x400 0x1>,
+				       <&dmamux1 106 0x400 0x1>,
+				       <&dmamux1 107 0x400 0x1>,
+				       <&dmamux1 108 0x400 0x1>;
+				dma-names = "ch1", "up", "trig", "com";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 14 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <14>;
+					status = "disabled";
+				};
 			};
 
-			dfsdm3: filter at 3 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <3>;
-				interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 104 0x400 0x01>;
-				dma-names = "rx";
-				status = "disabled";
+			timers16: timer at 44007000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44007000 0x400>;
+				interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM16_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 109 0x400 0x1>,
+				<&dmamux1 110 0x400 0x1>;
+				dma-names = "ch1", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+				timer at 15 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <15>;
+					status = "disabled";
+				};
 			};
 
-			dfsdm4: filter at 4 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <4>;
-				interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 91 0x400 0x01>;
-				dma-names = "rx";
-				status = "disabled";
+			timers17: timer at 44008000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44008000 0x400>;
+				interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM17_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 111 0x400 0x1>,
+				<&dmamux1 112 0x400 0x1>;
+				dma-names = "ch1", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 16 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <16>;
+					status = "disabled";
+				};
 			};
 
-			dfsdm5: filter at 5 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <5>;
-				interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 92 0x400 0x01>;
-				dma-names = "rx";
+			spi5: spi at 44009000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x44009000 0x400>;
+				interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI5_K>;
+				resets = <&rcc SPI5_R>;
+				dmas = <&dmamux1 85 0x400 0x05>,
+				<&dmamux1 86 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
 
-		dma1: dma-controller at 48000000 {
-			compatible = "st,stm32-dma";
-			reg = <0x48000000 0x400>;
-			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc DMA1>;
-			resets = <&rcc DMA1_R>;
-			#dma-cells = <4>;
-			st,mem2mem;
-			dma-requests = <8>;
-		};
+			sai1: sai at 4400a000 {
+				compatible = "st,stm32h7-sai";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x4400a000 0x400>;
+				reg = <0x4400a000 0x4>, <0x4400a3f0 0x10>;
+				interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc SAI1_R>;
+				status = "disabled";
+
+				sai1a: audio-controller at 4400a004 {
+					#sound-dai-cells = <0>;
+
+					compatible = "st,stm32-sai-sub-a";
+					reg = <0x4 0x20>;
+					clocks = <&rcc SAI1_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 87 0x400 0x01>;
+					status = "disabled";
+				};
 
-		dma2: dma-controller at 48001000 {
-			compatible = "st,stm32-dma";
-			reg = <0x48001000 0x400>;
-			interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc DMA2>;
-			resets = <&rcc DMA2_R>;
-			#dma-cells = <4>;
-			st,mem2mem;
-			dma-requests = <8>;
-		};
+				sai1b: audio-controller at 4400a024 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-b";
+					reg = <0x24 0x20>;
+					clocks = <&rcc SAI1_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 88 0x400 0x01>;
+					status = "disabled";
+				};
+			};
 
-		dmamux1: dma-router at 48002000 {
-			compatible = "st,stm32h7-dmamux";
-			reg = <0x48002000 0x40>;
-			#dma-cells = <3>;
-			dma-requests = <128>;
-			dma-masters = <&dma1 &dma2>;
-			dma-channels = <16>;
-			clocks = <&rcc DMAMUX>;
-			resets = <&rcc DMAMUX_R>;
-		};
+			sai2: sai at 4400b000 {
+				compatible = "st,stm32h7-sai";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x4400b000 0x400>;
+				reg = <0x4400b000 0x4>, <0x4400b3f0 0x10>;
+				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc SAI2_R>;
+				status = "disabled";
+
+				sai2a: audio-controller at 4400b004 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-a";
+					reg = <0x4 0x20>;
+					clocks = <&rcc SAI2_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 89 0x400 0x01>;
+					status = "disabled";
+				};
 
-		adc: adc at 48003000 {
-			compatible = "st,stm32mp1-adc-core";
-			reg = <0x48003000 0x400>;
-			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc ADC12>, <&rcc ADC12_K>;
-			clock-names = "bus", "adc";
-			interrupt-controller;
-			st,syscfg = <&syscfg>;
-			#interrupt-cells = <1>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
+				sai2b: audio-controller at 4400b024 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-b";
+					reg = <0x24 0x20>;
+					clocks = <&rcc SAI2_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 90 0x400 0x01>;
+					status = "disabled";
+				};
+			};
 
-			adc1: adc at 0 {
-				compatible = "st,stm32mp1-adc";
-				#io-channel-cells = <1>;
+			sai3: sai at 4400c000 {
+				compatible = "st,stm32h7-sai";
 				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x0>;
-				interrupt-parent = <&adc>;
-				interrupts = <0>;
-				dmas = <&dmamux1 9 0x400 0x01>;
-				dma-names = "rx";
-				status = "disabled";
+				#size-cells = <1>;
+				ranges = <0 0x4400c000 0x400>;
+				reg = <0x4400c000 0x4>, <0x4400c3f0 0x10>;
+				interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc SAI3_R>;
+				status = "disabled";
+
+				sai3a: audio-controller at 4400c004 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-a";
+					reg = <0x04 0x20>;
+					clocks = <&rcc SAI3_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 113 0x400 0x01>;
+					status = "disabled";
+				};
+
+				sai3b: audio-controller at 4400c024 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-b";
+					reg = <0x24 0x20>;
+					clocks = <&rcc SAI3_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 114 0x400 0x01>;
+					status = "disabled";
+				};
 			};
 
-			adc2: adc at 100 {
-				compatible = "st,stm32mp1-adc";
-				#io-channel-cells = <1>;
+			dfsdm: dfsdm at 4400d000 {
+				compatible = "st,stm32mp1-dfsdm";
+				reg = <0x4400d000 0x800>;
+				clocks = <&rcc DFSDM_K>;
+				clock-names = "dfsdm";
 				#address-cells = <1>;
 				#size-cells = <0>;
-				reg = <0x100>;
-				interrupt-parent = <&adc>;
-				interrupts = <1>;
-				dmas = <&dmamux1 10 0x400 0x01>;
-				dma-names = "rx";
-				nvmem-cells = <&vrefint>;
-				nvmem-cell-names = "vrefint";
-				status = "disabled";
-				channel at 13 {
-					reg = <13>;
-					label = "vrefint";
+				status = "disabled";
+
+				dfsdm0: filter at 0 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <0>;
+					interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 101 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
 				};
-				channel at 14 {
-					reg = <14>;
-					label = "vddcore";
+
+				dfsdm1: filter at 1 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <1>;
+					interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 102 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
 				};
-			};
-		};
 
-		sdmmc3: mmc at 48004000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x00253180>;
-			reg = <0x48004000 0x400>;
-			interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC3_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC3_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <120000000>;
-			status = "disabled";
-		};
+				dfsdm2: filter at 2 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <2>;
+					interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 103 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 
-		usbotg_hs: usb-otg at 49000000 {
-			compatible = "st,stm32mp15-hsotg", "snps,dwc2";
-			reg = <0x49000000 0x10000>;
-			clocks = <&rcc USBO_K>, <&usbphyc>;
-			clock-names = "otg", "utmi";
-			resets = <&rcc USBO_R>;
-			reset-names = "dwc2";
-			interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
-			g-rx-fifo-size = <512>;
-			g-np-tx-fifo-size = <32>;
-			g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
-			dr_mode = "otg";
-			otg-rev = <0x200>;
-			usb33d-supply = <&usb33>;
-			status = "disabled";
-		};
-
-		ipcc: mailbox at 4c001000 {
-			compatible = "st,stm32mp1-ipcc";
-			#mbox-cells = <1>;
-			reg = <0x4c001000 0x400>;
-			st,proc-id = <0>;
-			interrupts-extended =
-				<&exti 61 1>,
-				<&intc GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "rx", "tx";
-			clocks = <&rcc IPCC>;
-			wakeup-source;
-			status = "disabled";
-		};
-
-		dcmi: dcmi at 4c006000 {
-			compatible = "st,stm32-dcmi";
-			reg = <0x4c006000 0x400>;
-			interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc CAMITF_R>;
-			clocks = <&rcc DCMI>;
-			clock-names = "mclk";
-			dmas = <&dmamux1 75 0x400 0x01>;
-			dma-names = "tx";
-			status = "disabled";
-		};
-
-		rcc: rcc at 50000000 {
-			compatible = "st,stm32mp1-rcc", "syscon";
-			reg = <0x50000000 0x1000>;
-			#clock-cells = <1>;
-			#reset-cells = <1>;
-		};
-
-		pwr_regulators: pwr at 50001000 {
-			compatible = "st,stm32mp1,pwr-reg";
-			reg = <0x50001000 0x10>;
-
-			reg11: reg11 {
-				regulator-name = "reg11";
-				regulator-min-microvolt = <1100000>;
-				regulator-max-microvolt = <1100000>;
-			};
+				dfsdm3: filter at 3 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <3>;
+					interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 104 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 
-			reg18: reg18 {
-				regulator-name = "reg18";
-				regulator-min-microvolt = <1800000>;
-				regulator-max-microvolt = <1800000>;
-			};
+				dfsdm4: filter at 4 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <4>;
+					interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 91 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 
-			usb33: usb33 {
-				regulator-name = "usb33";
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
+				dfsdm5: filter at 5 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <5>;
+					interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 92 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 			};
-		};
-
-		pwr_mcu: pwr_mcu at 50001014 {
-			compatible = "st,stm32mp151-pwr-mcu", "syscon";
-			reg = <0x50001014 0x4>;
-		};
-
-		exti: interrupt-controller at 5000d000 {
-			compatible = "st,stm32mp1-exti", "syscon";
-			interrupt-controller;
-			#interrupt-cells = <2>;
-			reg = <0x5000d000 0x400>;
-		};
 
-		syscfg: syscon at 50020000 {
-			compatible = "st,stm32mp157-syscfg", "syscon";
-			reg = <0x50020000 0x400>;
-			clocks = <&rcc SYSCFG>;
-		};
+			dma1: dma-controller at 48000000 {
+				compatible = "st,stm32-dma";
+				reg = <0x48000000 0x400>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc DMA1>;
+				resets = <&rcc DMA1_R>;
+				#dma-cells = <4>;
+				st,mem2mem;
+				dma-requests = <8>;
+			};
+
+			dma2: dma-controller at 48001000 {
+				compatible = "st,stm32-dma";
+				reg = <0x48001000 0x400>;
+				interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc DMA2>;
+				resets = <&rcc DMA2_R>;
+				#dma-cells = <4>;
+				st,mem2mem;
+				dma-requests = <8>;
+			};
+
+			dmamux1: dma-router at 48002000 {
+				compatible = "st,stm32h7-dmamux";
+				reg = <0x48002000 0x40>;
+				#dma-cells = <3>;
+				dma-requests = <128>;
+				dma-masters = <&dma1 &dma2>;
+				dma-channels = <16>;
+				clocks = <&rcc DMAMUX>;
+				resets = <&rcc DMAMUX_R>;
+			};
+
+			adc: adc at 48003000 {
+				compatible = "st,stm32mp1-adc-core";
+				reg = <0x48003000 0x400>;
+				interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc ADC12>, <&rcc ADC12_K>;
+				clock-names = "bus", "adc";
+				interrupt-controller;
+				st,syscfg = <&syscfg>;
+				#interrupt-cells = <1>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
 
-		lptimer2: timer at 50021000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x50021000 0x400>;
-			interrupts-extended = <&exti 48 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM2_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
+				adc1: adc at 0 {
+					compatible = "st,stm32mp1-adc";
+					#io-channel-cells = <1>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x0>;
+					interrupt-parent = <&adc>;
+					interrupts = <0>;
+					dmas = <&dmamux1 9 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
+				adc2: adc at 100 {
+					compatible = "st,stm32mp1-adc";
+					#io-channel-cells = <1>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x100>;
+					interrupt-parent = <&adc>;
+					interrupts = <1>;
+					dmas = <&dmamux1 10 0x400 0x01>;
+					dma-names = "rx";
+					nvmem-cells = <&vrefint>;
+					nvmem-cell-names = "vrefint";
+					status = "disabled";
+					channel at 13 {
+						reg = <13>;
+						label = "vrefint";
+					};
+					channel at 14 {
+						reg = <14>;
+						label = "vddcore";
+					};
+				};
 			};
 
-			trigger at 1 {
-				compatible = "st,stm32-lptimer-trigger";
-				reg = <1>;
+			sdmmc3: mmc at 48004000 {
+				compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+				arm,primecell-periphid = <0x00253180>;
+				reg = <0x48004000 0x400>;
+				interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SDMMC3_K>;
+				clock-names = "apb_pclk";
+				resets = <&rcc SDMMC3_R>;
+				cap-sd-highspeed;
+				cap-mmc-highspeed;
+				max-frequency = <120000000>;
 				status = "disabled";
 			};
 
-			counter {
-				compatible = "st,stm32-lptimer-counter";
+			usbotg_hs: usb-otg at 49000000 {
+				compatible = "st,stm32mp15-hsotg", "snps,dwc2";
+				reg = <0x49000000 0x10000>;
+				clocks = <&rcc USBO_K>, <&usbphyc>;
+				clock-names = "otg", "utmi";
+				resets = <&rcc USBO_R>;
+				reset-names = "dwc2";
+				interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+				g-rx-fifo-size = <512>;
+				g-np-tx-fifo-size = <32>;
+				g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
+				dr_mode = "otg";
+				otg-rev = <0x200>;
+				usb33d-supply = <&usb33>;
 				status = "disabled";
 			};
-		};
-
-		lptimer3: timer at 50022000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x50022000 0x400>;
-			interrupts-extended = <&exti 50 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM3_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
+			dcmi: dcmi at 4c006000 {
+				compatible = "st,stm32-dcmi";
+				reg = <0x4c006000 0x400>;
+				interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc CAMITF_R>;
+				clocks = <&rcc DCMI>;
+				clock-names = "mclk";
+				dmas = <&dmamux1 75 0x400 0x01>;
+				dma-names = "tx";
 				status = "disabled";
 			};
 
-			trigger at 2 {
-				compatible = "st,stm32-lptimer-trigger";
-				reg = <2>;
-				status = "disabled";
-			};
-		};
+			lptimer2: timer at 50021000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x50021000 0x400>;
+				interrupts-extended = <&exti 48 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM2_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		lptimer4: timer at 50023000 {
-			compatible = "st,stm32-lptimer";
-			reg = <0x50023000 0x400>;
-			interrupts-extended = <&exti 52 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM4_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
+				trigger at 1 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <1>;
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
+				counter {
+					compatible = "st,stm32-lptimer-counter";
+					status = "disabled";
+				};
 			};
-		};
 
-		lptimer5: timer at 50024000 {
-			compatible = "st,stm32-lptimer";
-			reg = <0x50024000 0x400>;
-			interrupts-extended = <&exti 53 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM5_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
+			lptimer3: timer at 50022000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x50022000 0x400>;
+				interrupts-extended = <&exti 50 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM3_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
+				trigger at 2 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <2>;
+					status = "disabled";
+				};
 			};
-		};
 
-		vrefbuf: vrefbuf at 50025000 {
-			compatible = "st,stm32-vrefbuf";
-			reg = <0x50025000 0x8>;
-			regulator-min-microvolt = <1500000>;
-			regulator-max-microvolt = <2500000>;
-			clocks = <&rcc VREF>;
-			status = "disabled";
-		};
+			lptimer4: timer at 50023000 {
+				compatible = "st,stm32-lptimer";
+				reg = <0x50023000 0x400>;
+				interrupts-extended = <&exti 52 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM4_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
 
-		sai4: sai at 50027000 {
-			compatible = "st,stm32h7-sai";
-			#address-cells = <1>;
-			#size-cells = <1>;
-			ranges = <0 0x50027000 0x400>;
-			reg = <0x50027000 0x4>, <0x500273f0 0x10>;
-			interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc SAI4_R>;
-			status = "disabled";
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+			};
 
-			sai4a: audio-controller at 50027004 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-a";
-				reg = <0x04 0x20>;
-				clocks = <&rcc SAI4_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 99 0x400 0x01>;
+			lptimer5: timer at 50024000 {
+				compatible = "st,stm32-lptimer";
+				reg = <0x50024000 0x400>;
+				interrupts-extended = <&exti 53 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM5_K>;
+				clock-names = "mux";
+				wakeup-source;
 				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 			};
 
-			sai4b: audio-controller at 50027024 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-b";
-				reg = <0x24 0x20>;
-				clocks = <&rcc SAI4_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 100 0x400 0x01>;
+			vrefbuf: vrefbuf at 50025000 {
+				compatible = "st,stm32-vrefbuf";
+				reg = <0x50025000 0x8>;
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <2500000>;
+				clocks = <&rcc VREF>;
 				status = "disabled";
 			};
-		};
 
-		dts: thermal at 50028000 {
-			compatible = "st,stm32-thermal";
-			reg = <0x50028000 0x100>;
-			interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc TMPSENS>;
-			clock-names = "pclk";
-			#thermal-sensor-cells = <0>;
-			status = "disabled";
-		};
-
-		hash1: hash at 54002000 {
-			compatible = "st,stm32f756-hash";
-			reg = <0x54002000 0x400>;
-			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc HASH1>;
-			resets = <&rcc HASH1_R>;
-			dmas = <&mdma1 31 0x2 0x1000A02 0x0 0x0>;
-			dma-names = "in";
-			dma-maxburst = <2>;
-			status = "disabled";
-		};
-
-		rng1: rng at 54003000 {
-			compatible = "st,stm32-rng";
-			reg = <0x54003000 0x400>;
-			clocks = <&rcc RNG1_K>;
-			resets = <&rcc RNG1_R>;
-			status = "disabled";
-		};
-
-		mdma1: dma-controller at 58000000 {
-			compatible = "st,stm32h7-mdma";
-			reg = <0x58000000 0x1000>;
-			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc MDMA>;
-			resets = <&rcc MDMA_R>;
-			#dma-cells = <5>;
-			dma-channels = <32>;
-			dma-requests = <48>;
-		};
+			sai4: sai at 50027000 {
+				compatible = "st,stm32h7-sai";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x50027000 0x400>;
+				reg = <0x50027000 0x4>, <0x500273f0 0x10>;
+				interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc SAI4_R>;
+				status = "disabled";
+
+				sai4a: audio-controller at 50027004 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-a";
+					reg = <0x04 0x20>;
+					clocks = <&rcc SAI4_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 99 0x400 0x01>;
+					status = "disabled";
+				};
 
-		fmc: memory-controller at 58002000 {
-			#address-cells = <2>;
-			#size-cells = <1>;
-			compatible = "st,stm32mp1-fmc2-ebi";
-			reg = <0x58002000 0x1000>;
-			clocks = <&rcc FMC_K>;
-			resets = <&rcc FMC_R>;
-			status = "disabled";
+				sai4b: audio-controller at 50027024 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-b";
+					reg = <0x24 0x20>;
+					clocks = <&rcc SAI4_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 100 0x400 0x01>;
+					status = "disabled";
+				};
+			};
 
-			ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
-				 <1 0 0x64000000 0x04000000>, /* EBI CS 2 */
-				 <2 0 0x68000000 0x04000000>, /* EBI CS 3 */
-				 <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */
-				 <4 0 0x80000000 0x10000000>; /* NAND */
+			hash1: hash at 54002000 {
+				compatible = "st,stm32f756-hash";
+				reg = <0x54002000 0x400>;
+				interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc HASH1>;
+				resets = <&rcc HASH1_R>;
+				dmas = <&mdma1 31 0x2 0x1000A02 0x0 0x0>;
+				dma-names = "in";
+				dma-maxburst = <2>;
+				status = "disabled";
+			};
+
+			rng1: rng at 54003000 {
+				compatible = "st,stm32-rng";
+				reg = <0x54003000 0x400>;
+				clocks = <&rcc RNG1_K>;
+				resets = <&rcc RNG1_R>;
+				status = "okay";
+			};
+
+			fmc: memory-controller at 58002000 {
+				#address-cells = <2>;
+				#size-cells = <1>;
+				compatible = "st,stm32mp1-fmc2-ebi";
+				reg = <0x58002000 0x1000>;
+				clocks = <&rcc FMC_K>;
+				resets = <&rcc FMC_R>;
+				status = "disabled";
+
+				ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
+					 <1 0 0x64000000 0x04000000>, /* EBI CS 2 */
+					 <2 0 0x68000000 0x04000000>, /* EBI CS 3 */
+					 <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */
+					 <4 0 0x80000000 0x10000000>; /* NAND */
+
+				nand-controller at 4,0 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					compatible = "st,stm32mp1-fmc2-nfc";
+					reg = <4 0x00000000 0x1000>,
+					      <4 0x08010000 0x1000>,
+					      <4 0x08020000 0x1000>,
+					      <4 0x01000000 0x1000>,
+					      <4 0x09010000 0x1000>,
+					      <4 0x09020000 0x1000>;
+					interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
+					       <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
+					       <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
+					dma-names = "tx", "rx", "ecc";
+					status = "disabled";
+				};
+			};
 
-			nand-controller at 4,0 {
+			qspi: spi at 58003000 {
+				compatible = "st,stm32f469-qspi";
+				reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
+				reg-names = "qspi", "qspi_mm";
+				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&mdma1 22 0x2 0x10100002 0x0 0x0>,
+				       <&mdma1 22 0x2 0x10100008 0x0 0x0>;
+				dma-names = "tx", "rx";
+				clocks = <&rcc QSPI_K>;
+				resets = <&rcc QSPI_R>;
 				#address-cells = <1>;
 				#size-cells = <0>;
-				compatible = "st,stm32mp1-fmc2-nfc";
-				reg = <4 0x00000000 0x1000>,
-				      <4 0x08010000 0x1000>,
-				      <4 0x08020000 0x1000>,
-				      <4 0x01000000 0x1000>,
-				      <4 0x09010000 0x1000>,
-				      <4 0x09020000 0x1000>;
-				interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
-				       <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
-				       <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
-				dma-names = "tx", "rx", "ecc";
 				status = "disabled";
 			};
-		};
-
-		qspi: spi at 58003000 {
-			compatible = "st,stm32f469-qspi";
-			reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
-			reg-names = "qspi", "qspi_mm";
-			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&mdma1 22 0x2 0x10100002 0x0 0x0>,
-			       <&mdma1 22 0x2 0x10100008 0x0 0x0>;
-			dma-names = "tx", "rx";
-			clocks = <&rcc QSPI_K>;
-			resets = <&rcc QSPI_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		sdmmc1: mmc at 58005000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x00253180>;
-			reg = <0x58005000 0x1000>;
-			interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC1_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC1_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <120000000>;
-			status = "disabled";
-		};
 
-		sdmmc2: mmc at 58007000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x00253180>;
-			reg = <0x58007000 0x1000>;
-			interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC2_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC2_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <120000000>;
-			status = "disabled";
-		};
-
-		crc1: crc at 58009000 {
-			compatible = "st,stm32f7-crc";
-			reg = <0x58009000 0x400>;
-			clocks = <&rcc CRC1>;
-			status = "disabled";
-		};
-
-		ethernet0: ethernet at 5800a000 {
-			compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a";
-			reg = <0x5800a000 0x2000>;
-			reg-names = "stmmaceth";
-			interrupts-extended = <&intc GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "macirq";
-			clock-names = "stmmaceth",
-				      "mac-clk-tx",
-				      "mac-clk-rx",
-				      "eth-ck",
-				      "ptp_ref",
-				      "ethstp";
-			clocks = <&rcc ETHMAC>,
-				 <&rcc ETHTX>,
-				 <&rcc ETHRX>,
-				 <&rcc ETHCK_K>,
-				 <&rcc ETHPTP_K>,
-				 <&rcc ETHSTP>;
-			st,syscon = <&syscfg 0x4>;
-			snps,mixed-burst;
-			snps,pbl = <2>;
-			snps,en-tx-lpi-clockgating;
-			snps,axi-config = <&stmmac_axi_config_0>;
-			snps,tso;
-			status = "disabled";
-
-			stmmac_axi_config_0: stmmac-axi-config {
-				snps,wr_osr_lmt = <0x7>;
-				snps,rd_osr_lmt = <0x7>;
-				snps,blen = <0 0 0 0 16 8 4>;
+			ethernet0: ethernet at 5800a000 {
+				compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a";
+				reg = <0x5800a000 0x2000>;
+				reg-names = "stmmaceth";
+				interrupts-extended = <&intc GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "macirq";
+				clock-names = "stmmaceth",
+					      "mac-clk-tx",
+					      "mac-clk-rx",
+					      "eth-ck",
+					      "ptp_ref",
+					      "ethstp";
+				clocks = <&rcc ETHMAC>,
+					 <&rcc ETHTX>,
+					 <&rcc ETHRX>,
+					 <&rcc ETHCK_K>,
+					 <&rcc ETHPTP_K>,
+					 <&rcc ETHSTP>;
+				st,syscon = <&syscfg 0x4>;
+				snps,mixed-burst;
+				snps,pbl = <2>;
+				snps,en-tx-lpi-clockgating;
+				snps,axi-config = <&stmmac_axi_config_0>;
+				snps,tso;
+				status = "disabled";
+
+				stmmac_axi_config_0: stmmac-axi-config {
+					snps,wr_osr_lmt = <0x7>;
+					snps,rd_osr_lmt = <0x7>;
+					snps,blen = <0 0 0 0 16 8 4>;
+				};
 			};
-		};
-
-		usbh_ohci: usb at 5800c000 {
-			compatible = "generic-ohci";
-			reg = <0x5800c000 0x1000>;
-			clocks = <&usbphyc>, <&rcc USBH>;
-			resets = <&rcc USBH_R>;
-			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-		};
-
-		usbh_ehci: usb at 5800d000 {
-			compatible = "generic-ehci";
-			reg = <0x5800d000 0x1000>;
-			clocks = <&usbphyc>, <&rcc USBH>;
-			resets = <&rcc USBH_R>;
-			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
-			companion = <&usbh_ohci>;
-			status = "disabled";
-		};
-
-		ltdc: display-controller at 5a001000 {
-			compatible = "st,stm32-ltdc";
-			reg = <0x5a001000 0x400>;
-			interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LTDC_PX>;
-			clock-names = "lcd";
-			resets = <&rcc LTDC_R>;
-			status = "disabled";
-		};
-
-		iwdg2: watchdog at 5a002000 {
-			compatible = "st,stm32mp1-iwdg";
-			reg = <0x5a002000 0x400>;
-			clocks = <&rcc IWDG2>, <&rcc CK_LSI>;
-			clock-names = "pclk", "lsi";
-			status = "disabled";
-		};
-
-		usbphyc: usbphyc at 5a006000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			#clock-cells = <0>;
-			compatible = "st,stm32mp1-usbphyc";
-			reg = <0x5a006000 0x1000>;
-			clocks = <&rcc USBPHY_K>;
-			resets = <&rcc USBPHY_R>;
-			vdda1v1-supply = <&reg11>;
-			vdda1v8-supply = <&reg18>;
-			status = "disabled";
 
-			usbphyc_port0: usb-phy at 0 {
-				#phy-cells = <0>;
-				reg = <0>;
+			usart1: serial at 5c000000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x5c000000 0x400>;
+				interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART1_K>;
+				wakeup-source;
+				status = "disabled";
 			};
 
-			usbphyc_port1: usb-phy at 1 {
-				#phy-cells = <1>;
-				reg = <1>;
+			spi6: spi at 5c001000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x5c001000 0x400>;
+				interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI6_K>;
+				resets = <&rcc SPI6_R>;
+				dmas = <&mdma1 34 0x0 0x40008 0x0 0x0>,
+				       <&mdma1 35 0x0 0x40002 0x0 0x0>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			i2c4: i2c at 5c002000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x5c002000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C4_K>;
+				resets = <&rcc I2C4_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x8>;
+				wakeup-source;
+				i2c-analog-filter;
+				status = "disabled";
 			};
-		};
 
-		usart1: serial at 5c000000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x5c000000 0x400>;
-			interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART1_K>;
-			wakeup-source;
-			status = "disabled";
-		};
-
-		spi6: spi at 5c001000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x5c001000 0x400>;
-			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI6_K>;
-			resets = <&rcc SPI6_R>;
-			dmas = <&mdma1 34 0x0 0x40008 0x0 0x0>,
-			       <&mdma1 35 0x0 0x40002 0x0 0x0>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		i2c4: i2c at 5c002000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x5c002000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C4_K>;
-			resets = <&rcc I2C4_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x8>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
-		rtc: rtc at 5c004000 {
-			compatible = "st,stm32mp1-rtc";
-			reg = <0x5c004000 0x400>;
-			clocks = <&rcc RTCAPB>, <&rcc RTC>;
-			clock-names = "pclk", "rtc_ck";
-			interrupts-extended = <&exti 19 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-		};
-
-		bsec: efuse at 5c005000 {
-			compatible = "st,stm32mp15-bsec";
-			reg = <0x5c005000 0x400>;
-			#address-cells = <1>;
-			#size-cells = <1>;
-			part_number_otp: part-number-otp at 4 {
-				reg = <0x4 0x1>;
-			};
-			vrefint: vrefin-cal at 52 {
-				reg = <0x52 0x2>;
-			};
-			ts_cal1: calib at 5c {
-				reg = <0x5c 0x2>;
-			};
-			ts_cal2: calib at 5e {
-				reg = <0x5e 0x2>;
+			i2c6: i2c at 5c009000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x5c009000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C6_K>;
+				resets = <&rcc I2C6_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x20>;
+				wakeup-source;
+				i2c-analog-filter;
+				status = "disabled";
 			};
 		};
 
-		i2c6: i2c at 5c009000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x5c009000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C6_K>;
-			resets = <&rcc I2C6_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x20>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
 		tamp: tamp at 5c00a000 {
 			compatible = "st,stm32-tamp", "syscon", "simple-mfd";
 			reg = <0x5c00a000 0x400>;
diff --git a/arch/arm/boot/dts/st/stm32mp153.dtsi b/arch/arm/boot/dts/st/stm32mp153.dtsi
index 486084e0b80b..36e17ea0b179 100644
--- a/arch/arm/boot/dts/st/stm32mp153.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp153.dtsi
@@ -28,32 +28,32 @@ timer {
 			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
 			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
 	};
+};
 
-	soc {
-		m_can1: can at 4400e000 {
-			compatible = "bosch,m_can";
-			reg = <0x4400e000 0x400>, <0x44011000 0x1400>;
-			reg-names = "m_can", "message_ram";
-			interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "int0", "int1";
-			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
-			clock-names = "hclk", "cclk";
-			bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
-			status = "disabled";
-		};
+&etzpc {
+	m_can1: can at 4400e000 {
+		compatible = "bosch,m_can";
+		reg = <0x4400e000 0x400>, <0x44011000 0x1400>;
+		reg-names = "m_can", "message_ram";
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "int0", "int1";
+		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+		clock-names = "hclk", "cclk";
+		bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+		status = "disabled";
+	};
 
-		m_can2: can at 4400f000 {
-			compatible = "bosch,m_can";
-			reg = <0x4400f000 0x400>, <0x44011000 0x2800>;
-			reg-names = "m_can", "message_ram";
-			interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "int0", "int1";
-			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
-			clock-names = "hclk", "cclk";
-			bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
-			status = "disabled";
-		};
+	m_can2: can at 4400f000 {
+		compatible = "bosch,m_can";
+		reg = <0x4400f000 0x400>, <0x44011000 0x2800>;
+		reg-names = "m_can", "message_ram";
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "int0", "int1";
+		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+		clock-names = "hclk", "cclk";
+		bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
+		status = "disabled";
 	};
 };
diff --git a/arch/arm/boot/dts/st/stm32mp15xc.dtsi b/arch/arm/boot/dts/st/stm32mp15xc.dtsi
index b06a55a2fa18..d36c3457451a 100644
--- a/arch/arm/boot/dts/st/stm32mp15xc.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xc.dtsi
@@ -4,15 +4,13 @@
  * Author: Alexandre Torgue <alexandre.torgue at st.com> for STMicroelectronics.
  */
 
-/ {
-	soc {
-		cryp1: cryp at 54001000 {
-			compatible = "st,stm32mp1-cryp";
-			reg = <0x54001000 0x400>;
-			interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CRYP1>;
-			resets = <&rcc CRYP1_R>;
-			status = "disabled";
-		};
+&etzpc {
+	cryp1: cryp at 54001000 {
+		compatible = "st,stm32mp1-cryp";
+		reg = <0x54001000 0x400>;
+		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&rcc CRYP1>;
+		resets = <&rcc CRYP1_R>;
+		status = "disabled";
 	};
 };
-- 
2.35.3



From gregkh at linuxfoundation.org  Mon Dec 11 10:21:30 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 11 Dec 2023 19:21:30 +0100
Subject: [PATCH 6.6 197/244] perf vendor events arm64: AmpereOne: Add missing DefaultMetricgroupName fields
In-Reply-To: <20231211182045.784881756@linuxfoundation.org>
References: <20231211182045.784881756@linuxfoundation.org>
Message-ID: <20231211182054.781810722@linuxfoundation.org>

6.6-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Ilkka Koskinen <ilkka at os.amperecomputing.com>

[ Upstream commit 90fe70d4e23cb57253d2668a171d5695c332deb7 ]

AmpereOne metrics were missing DefaultMetricgroupName from metrics with
"Default" in group name resulting perf to segfault. Add the missing
field to address the issue.

Fixes: 59faeaf80d02 ("perf vendor events arm64: Fix for AmpereOne metrics")
Signed-off-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
Reviewed-by: Ian Rogers <irogers at google.com>
Cc: James Clark <james.clark at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Leo Yan <leo.yan at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: John Garry <john.g.garry at oracle.com>
Cc: linux-arm-kernel at lists.infradead.org
Link: https://lore.kernel.org/r/20231201021550.1109196-2-ilkka at os.amperecomputing.com
Signed-off-by: Namhyung Kim <namhyung at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json
index e2848a9d48487..afcdad58ef89c 100644
--- a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json
+++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/metrics.json
@@ -231,6 +231,7 @@
         "MetricName": "slots_lost_misspeculation_fraction",
         "MetricExpr": "100 * ((OP_SPEC - OP_RETIRED) / (CPU_CYCLES * #slots))",
         "BriefDescription": "Fraction of slots lost due to misspeculation",
+        "DefaultMetricgroupName": "TopdownL1",
         "MetricGroup": "Default;TopdownL1",
         "ScaleUnit": "1percent of slots"
     },
@@ -238,6 +239,7 @@
         "MetricName": "retired_fraction",
         "MetricExpr": "100 * (OP_RETIRED / (CPU_CYCLES * #slots))",
         "BriefDescription": "Fraction of slots retiring, useful work",
+        "DefaultMetricgroupName": "TopdownL1",
         "MetricGroup": "Default;TopdownL1",
 	"ScaleUnit": "1percent of slots"
     },
-- 
2.42.0





From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:44 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:44 +0100
Subject: [PATCH v7 13/13] ARM: dts: stm32: put ETZPC as an access controller for STM32MP13x boards
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-14-gatien.chevallier@foss.st.com>

Reference ETZPC as an access-control-provider.

For more information on which peripheral is securable or supports MCU
isolation, please read the STM32MP13 reference manual

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Patch not present in V6

 arch/arm/boot/dts/st/stm32mp131.dtsi  | 26 ++++++++++++++++++++++++++
 arch/arm/boot/dts/st/stm32mp133.dtsi  |  1 +
 arch/arm/boot/dts/st/stm32mp13xc.dtsi |  1 +
 arch/arm/boot/dts/st/stm32mp13xf.dtsi |  1 +
 4 files changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
index 6ba8e3fd43b0..74ceece168ce 100644
--- a/arch/arm/boot/dts/st/stm32mp131.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
@@ -883,6 +883,7 @@ etzpc: bus at 5c007000 {
 			reg = <0x5c007000 0x400>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+			#access-controller-cells = <1>;
 			ranges;
 
 			adc_2: adc at 48004000 {
@@ -895,6 +896,7 @@ adc_2: adc at 48004000 {
 				#interrupt-cells = <1>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 33>;
 				status = "disabled";
 
 				adc2: adc at 0 {
@@ -942,6 +944,7 @@ usbotg_hs: usb at 49000000 {
 				dr_mode = "otg";
 				otg-rev = <0x200>;
 				usb33d-supply = <&scmi_usb33>;
+				access-controllers = <&etzpc 34>;
 				status = "disabled";
 			};
 
@@ -955,6 +958,7 @@ usart1: serial at 4c000000 {
 				dmas = <&dmamux1 41 0x400 0x5>,
 				<&dmamux1 42 0x400 0x1>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 16>;
 				status = "disabled";
 			};
 
@@ -968,6 +972,7 @@ usart2: serial at 4c001000 {
 				dmas = <&dmamux1 43 0x400 0x5>,
 				<&dmamux1 44 0x400 0x1>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 17>;
 				status = "disabled";
 			};
 
@@ -979,6 +984,7 @@ i2s4: audio-controller at 4c002000 {
 				dmas = <&dmamux1 83 0x400 0x01>,
 				<&dmamux1 84 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 13>;
 				status = "disabled";
 			};
 
@@ -993,6 +999,7 @@ spi4: spi at 4c002000 {
 				dmas = <&dmamux1 83 0x400 0x01>,
 				       <&dmamux1 84 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 18>;
 				status = "disabled";
 			};
 
@@ -1007,6 +1014,7 @@ spi5: spi at 4c003000 {
 				dmas = <&dmamux1 85 0x400 0x01>,
 				       <&dmamux1 86 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 19>;
 				status = "disabled";
 			};
 
@@ -1025,6 +1033,7 @@ i2c3: i2c at 4c004000 {
 				dma-names = "rx", "tx";
 				st,syscfg-fmp = <&syscfg 0x4 0x4>;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 20>;
 				status = "disabled";
 			};
 
@@ -1043,6 +1052,7 @@ i2c4: i2c at 4c005000 {
 				dma-names = "rx", "tx";
 				st,syscfg-fmp = <&syscfg 0x4 0x8>;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 21>;
 				status = "disabled";
 			};
 
@@ -1061,6 +1071,7 @@ i2c5: i2c at 4c006000 {
 				dma-names = "rx", "tx";
 				st,syscfg-fmp = <&syscfg 0x4 0x10>;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 22>;
 				status = "disabled";
 			};
 
@@ -1073,6 +1084,7 @@ timers12: timer at 4c007000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM12_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 23>;
 				status = "disabled";
 
 				pwm {
@@ -1097,6 +1109,7 @@ timers13: timer at 4c008000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM13_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 24>;
 				status = "disabled";
 
 				pwm {
@@ -1121,6 +1134,7 @@ timers14: timer at 4c009000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM14_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 25>;
 				status = "disabled";
 
 				pwm {
@@ -1150,6 +1164,7 @@ timers15: timer at 4c00a000 {
 				<&dmamux1 107 0x400 0x1>,
 				<&dmamux1 108 0x400 0x1>;
 				dma-names = "ch1", "up", "trig", "com";
+				access-controllers = <&etzpc 26>;
 				status = "disabled";
 
 				pwm {
@@ -1177,6 +1192,7 @@ timers16: timer at 4c00b000 {
 				dmas = <&dmamux1 109 0x400 0x1>,
 				<&dmamux1 110 0x400 0x1>;
 				dma-names = "ch1", "up";
+				access-controllers = <&etzpc 27>;
 				status = "disabled";
 
 				pwm {
@@ -1204,6 +1220,7 @@ timers17: timer at 4c00c000 {
 				dmas = <&dmamux1 111 0x400 0x1>,
 				       <&dmamux1 112 0x400 0x1>;
 				dma-names = "ch1", "up";
+				access-controllers = <&etzpc 28>;
 				status = "disabled";
 
 				pwm {
@@ -1228,6 +1245,7 @@ lptimer2: timer at 50021000 {
 				clocks = <&rcc LPTIM2_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 1>;
 				status = "disabled";
 
 				pwm {
@@ -1262,6 +1280,7 @@ lptimer3: timer at 50022000 {
 				clocks = <&rcc LPTIM3_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 2>;
 				status = "disabled";
 
 				pwm {
@@ -1290,6 +1309,7 @@ hash: hash at 54003000 {
 				resets = <&rcc HASH1_R>;
 				dmas = <&mdma 30 0x2 0x1000a02 0x0 0x0>;
 				dma-names = "in";
+				access-controllers = <&etzpc 41>;
 			};
 
 			rng: rng at 54004000 {
@@ -1297,6 +1317,7 @@ rng: rng at 54004000 {
 				reg = <0x54004000 0x400>;
 				clocks = <&rcc RNG1_K>;
 				resets = <&rcc RNG1_R>;
+				access-controllers = <&etzpc 40>;
 			};
 
 			fmc: memory-controller at 58002000 {
@@ -1311,6 +1332,7 @@ fmc: memory-controller at 58002000 {
 				#size-cells = <1>;
 				clocks = <&rcc FMC_K>;
 				resets = <&rcc FMC_R>;
+				access-controllers = <&etzpc 54>;
 				status = "disabled";
 
 				nand-controller at 4,0 {
@@ -1344,6 +1366,7 @@ qspi: spi at 58003000 {
 				dma-names = "tx", "rx";
 				clocks = <&rcc QSPI_K>;
 				resets = <&rcc QSPI_R>;
+				access-controllers = <&etzpc 55>;
 				status = "disabled";
 			};
 
@@ -1358,6 +1381,7 @@ sdmmc1: mmc at 58005000 {
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
 				max-frequency = <130000000>;
+				access-controllers = <&etzpc 50>;
 				status = "disabled";
 			};
 
@@ -1372,6 +1396,7 @@ sdmmc2: mmc at 58007000 {
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
 				max-frequency = <130000000>;
+				access-controllers = <&etzpc 51>;
 				status = "disabled";
 			};
 
@@ -1385,6 +1410,7 @@ usbphyc: usbphyc at 5a006000 {
 				resets = <&rcc USBPHY_R>;
 				vdda1v1-supply = <&scmi_reg11>;
 				vdda1v8-supply = <&scmi_reg18>;
+				access-controllers = <&etzpc 5>;
 				status = "disabled";
 
 				usbphyc_port0: usb-phy at 0 {
diff --git a/arch/arm/boot/dts/st/stm32mp133.dtsi b/arch/arm/boot/dts/st/stm32mp133.dtsi
index c4d3a520c14b..3e394c8e58b9 100644
--- a/arch/arm/boot/dts/st/stm32mp133.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp133.dtsi
@@ -47,6 +47,7 @@ adc_1: adc at 48003000 {
 		#interrupt-cells = <1>;
 		#address-cells = <1>;
 		#size-cells = <0>;
+		access-controllers = <&etzpc 32>;
 		status = "disabled";
 
 		adc1: adc at 0 {
diff --git a/arch/arm/boot/dts/st/stm32mp13xc.dtsi b/arch/arm/boot/dts/st/stm32mp13xc.dtsi
index b9fb071a1471..a8bd5fe6536c 100644
--- a/arch/arm/boot/dts/st/stm32mp13xc.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp13xc.dtsi
@@ -11,6 +11,7 @@ cryp: crypto at 54002000 {
 		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&rcc CRYP1>;
 		resets = <&rcc CRYP1_R>;
+		access-controllers = <&etzpc 42>;
 		status = "disabled";
 	};
 };
diff --git a/arch/arm/boot/dts/st/stm32mp13xf.dtsi b/arch/arm/boot/dts/st/stm32mp13xf.dtsi
index b9fb071a1471..a8bd5fe6536c 100644
--- a/arch/arm/boot/dts/st/stm32mp13xf.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp13xf.dtsi
@@ -11,6 +11,7 @@ cryp: crypto at 54002000 {
 		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&rcc CRYP1>;
 		resets = <&rcc CRYP1_R>;
+		access-controllers = <&etzpc 42>;
 		status = "disabled";
 	};
 };
-- 
2.35.3



From gatien.chevallier at foss.st.com  Mon Dec 11 10:30:43 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Mon, 11 Dec 2023 19:30:43 +0100
Subject: [PATCH v7 12/13] ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <20231211183044.808204-13-gatien.chevallier@foss.st.com>

ETZPC is a firewall controller. Put all peripherals filtered by the
ETZPC as ETZPC subnodes and keep the "simple-bus" compatible for
backward compatibility.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V7:
    	- Keep simple-bus compatible
    	- Remove access-controllers reference in this patch

Changes in V6:
    	- Renamed access-controller to access-controllers
    	- Removal of access-control-provider property

Changes in V5:
    	- Renamed feature-domain* to access-control*

 arch/arm/boot/dts/st/stm32mp131.dtsi  | 1037 +++++++++++++------------
 arch/arm/boot/dts/st/stm32mp133.dtsi  |   50 +-
 arch/arm/boot/dts/st/stm32mp13xc.dtsi |   18 +-
 arch/arm/boot/dts/st/stm32mp13xf.dtsi |   18 +-
 4 files changed, 564 insertions(+), 559 deletions(-)

diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
index b04d24c939c3..6ba8e3fd43b0 100644
--- a/arch/arm/boot/dts/st/stm32mp131.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
@@ -745,340 +745,6 @@ dmamux1: dma-router at 48002000 {
 			dma-channels = <16>;
 		};
 
-		adc_2: adc at 48004000 {
-			compatible = "st,stm32mp13-adc-core";
-			reg = <0x48004000 0x400>;
-			interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc ADC2>, <&rcc ADC2_K>;
-			clock-names = "bus", "adc";
-			interrupt-controller;
-			#interrupt-cells = <1>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-
-			adc2: adc at 0 {
-				compatible = "st,stm32mp13-adc";
-				#io-channel-cells = <1>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x0>;
-				interrupt-parent = <&adc_2>;
-				interrupts = <0>;
-				dmas = <&dmamux1 10 0x400 0x80000001>;
-				dma-names = "rx";
-				status = "disabled";
-
-				channel at 13 {
-					reg = <13>;
-					label = "vrefint";
-				};
-				channel at 14 {
-					reg = <14>;
-					label = "vddcore";
-				};
-				channel at 16 {
-					reg = <16>;
-					label = "vddcpu";
-				};
-				channel at 17 {
-					reg = <17>;
-					label = "vddq_ddr";
-				};
-			};
-		};
-
-		usbotg_hs: usb at 49000000 {
-			compatible = "st,stm32mp15-hsotg", "snps,dwc2";
-			reg = <0x49000000 0x40000>;
-			clocks = <&rcc USBO_K>;
-			clock-names = "otg";
-			resets = <&rcc USBO_R>;
-			reset-names = "dwc2";
-			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
-			g-rx-fifo-size = <512>;
-			g-np-tx-fifo-size = <32>;
-			g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
-			dr_mode = "otg";
-			otg-rev = <0x200>;
-			usb33d-supply = <&scmi_usb33>;
-			status = "disabled";
-		};
-
-		usart1: serial at 4c000000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x4c000000 0x400>;
-			interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART1_K>;
-			resets = <&rcc USART1_R>;
-			wakeup-source;
-			dmas = <&dmamux1 41 0x400 0x5>,
-			       <&dmamux1 42 0x400 0x1>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		usart2: serial at 4c001000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x4c001000 0x400>;
-			interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART2_K>;
-			resets = <&rcc USART2_R>;
-			wakeup-source;
-			dmas = <&dmamux1 43 0x400 0x5>,
-			       <&dmamux1 44 0x400 0x1>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		i2s4: audio-controller at 4c002000 {
-			compatible = "st,stm32h7-i2s";
-			reg = <0x4c002000 0x400>;
-			#sound-dai-cells = <0>;
-			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 83 0x400 0x01>,
-			       <&dmamux1 84 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		spi4: spi at 4c002000 {
-			compatible = "st,stm32h7-spi";
-			reg = <0x4c002000 0x400>;
-			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI4_K>;
-			resets = <&rcc SPI4_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 83 0x400 0x01>,
-			       <&dmamux1 84 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		spi5: spi at 4c003000 {
-			compatible = "st,stm32h7-spi";
-			reg = <0x4c003000 0x400>;
-			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI5_K>;
-			resets = <&rcc SPI5_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 85 0x400 0x01>,
-			       <&dmamux1 86 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		i2c3: i2c at 4c004000 {
-			compatible = "st,stm32mp13-i2c";
-			reg = <0x4c004000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C3_K>;
-			resets = <&rcc I2C3_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 73 0x400 0x1>,
-			       <&dmamux1 74 0x400 0x1>;
-			dma-names = "rx", "tx";
-			st,syscfg-fmp = <&syscfg 0x4 0x4>;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
-		i2c4: i2c at 4c005000 {
-			compatible = "st,stm32mp13-i2c";
-			reg = <0x4c005000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C4_K>;
-			resets = <&rcc I2C4_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 75 0x400 0x1>,
-			       <&dmamux1 76 0x400 0x1>;
-			dma-names = "rx", "tx";
-			st,syscfg-fmp = <&syscfg 0x4 0x8>;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
-		i2c5: i2c at 4c006000 {
-			compatible = "st,stm32mp13-i2c";
-			reg = <0x4c006000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C5_K>;
-			resets = <&rcc I2C5_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 115 0x400 0x1>,
-			       <&dmamux1 116 0x400 0x1>;
-			dma-names = "rx", "tx";
-			st,syscfg-fmp = <&syscfg 0x4 0x10>;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
-		timers12: timer at 4c007000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c007000 0x400>;
-			interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM12_K>;
-			clock-names = "int";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 11 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <11>;
-				status = "disabled";
-			};
-		};
-
-		timers13: timer at 4c008000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c008000 0x400>;
-			interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM13_K>;
-			clock-names = "int";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 12 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <12>;
-				status = "disabled";
-			};
-		};
-
-		timers14: timer at 4c009000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c009000 0x400>;
-			interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM14_K>;
-			clock-names = "int";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 13 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <13>;
-				status = "disabled";
-			};
-		};
-
-		timers15: timer at 4c00a000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c00a000 0x400>;
-			interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM15_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 105 0x400 0x1>,
-			       <&dmamux1 106 0x400 0x1>,
-			       <&dmamux1 107 0x400 0x1>,
-			       <&dmamux1 108 0x400 0x1>;
-			dma-names = "ch1", "up", "trig", "com";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 14 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <14>;
-				status = "disabled";
-			};
-		};
-
-		timers16: timer at 4c00b000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c00b000 0x400>;
-			interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM16_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 109 0x400 0x1>,
-			       <&dmamux1 110 0x400 0x1>;
-			dma-names = "ch1", "up";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 15 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <15>;
-				status = "disabled";
-			};
-		};
-
-		timers17: timer at 4c00c000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c00c000 0x400>;
-			interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM17_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 111 0x400 0x1>,
-			       <&dmamux1 112 0x400 0x1>;
-			dma-names = "ch1", "up";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 16 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <16>;
-				status = "disabled";
-			};
-		};
-
 		rcc: rcc at 50000000 {
 			compatible = "st,stm32mp13-rcc", "syscon";
 			reg = <0x50000000 0x1000>;
@@ -1105,69 +771,6 @@ syscfg: syscon at 50020000 {
 			clocks = <&rcc SYSCFG>;
 		};
 
-		lptimer2: timer at 50021000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x50021000 0x400>;
-			interrupts-extended = <&exti 48 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM2_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			trigger at 1 {
-				compatible = "st,stm32-lptimer-trigger";
-				reg = <1>;
-				status = "disabled";
-			};
-
-			counter {
-				compatible = "st,stm32-lptimer-counter";
-				status = "disabled";
-			};
-
-			timer {
-				compatible = "st,stm32-lptimer-timer";
-				status = "disabled";
-			};
-		};
-
-		lptimer3: timer at 50022000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x50022000 0x400>;
-			interrupts-extended = <&exti 50 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM3_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			trigger at 2 {
-				compatible = "st,stm32-lptimer-trigger";
-				reg = <2>;
-				status = "disabled";
-			};
-
-			timer {
-				compatible = "st,stm32-lptimer-timer";
-				status = "disabled";
-			};
-		};
-
 		lptimer4: timer at 50023000 {
 			compatible = "st,stm32-lptimer";
 			reg = <0x50023000 0x400>;
@@ -1210,25 +813,6 @@ timer {
 			};
 		};
 
-		hash: hash at 54003000 {
-			compatible = "st,stm32mp13-hash";
-			reg = <0x54003000 0x400>;
-			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc HASH1>;
-			resets = <&rcc HASH1_R>;
-			dmas = <&mdma 30 0x2 0x1000a02 0x0 0x0>;
-			dma-names = "in";
-			status = "disabled";
-		};
-
-		rng: rng at 54004000 {
-			compatible = "st,stm32mp13-rng";
-			reg = <0x54004000 0x400>;
-			clocks = <&rcc RNG1_K>;
-			resets = <&rcc RNG1_R>;
-			status = "disabled";
-		};
-
 		mdma: dma-controller at 58000000 {
 			compatible = "st,stm32h7-mdma";
 			reg = <0x58000000 0x1000>;
@@ -1239,82 +823,6 @@ mdma: dma-controller at 58000000 {
 			dma-requests = <48>;
 		};
 
-		fmc: memory-controller at 58002000 {
-			compatible = "st,stm32mp1-fmc2-ebi";
-			reg = <0x58002000 0x1000>;
-			ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
-				 <1 0 0x64000000 0x04000000>, /* EBI CS 2 */
-				 <2 0 0x68000000 0x04000000>, /* EBI CS 3 */
-				 <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */
-				 <4 0 0x80000000 0x10000000>; /* NAND */
-			#address-cells = <2>;
-			#size-cells = <1>;
-			clocks = <&rcc FMC_K>;
-			resets = <&rcc FMC_R>;
-			status = "disabled";
-
-			nand-controller at 4,0 {
-				compatible = "st,stm32mp1-fmc2-nfc";
-				reg = <4 0x00000000 0x1000>,
-				      <4 0x08010000 0x1000>,
-				      <4 0x08020000 0x1000>,
-				      <4 0x01000000 0x1000>,
-				      <4 0x09010000 0x1000>,
-				      <4 0x09020000 0x1000>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&mdma 24 0x2 0x12000a02 0x0 0x0>,
-				       <&mdma 24 0x2 0x12000a08 0x0 0x0>,
-				       <&mdma 25 0x2 0x12000a0a 0x0 0x0>;
-				dma-names = "tx", "rx", "ecc";
-				status = "disabled";
-			};
-		};
-
-		qspi: spi at 58003000 {
-			compatible = "st,stm32f469-qspi";
-			reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
-			reg-names = "qspi", "qspi_mm";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&mdma 26 0x2 0x10100002 0x0 0x0>,
-			       <&mdma 26 0x2 0x10100008 0x0 0x0>;
-			dma-names = "tx", "rx";
-			clocks = <&rcc QSPI_K>;
-			resets = <&rcc QSPI_R>;
-			status = "disabled";
-		};
-
-		sdmmc1: mmc at 58005000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x20253180>;
-			reg = <0x58005000 0x1000>, <0x58006000 0x1000>;
-			interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC1_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC1_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <130000000>;
-			status = "disabled";
-		};
-
-		sdmmc2: mmc at 58007000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x20253180>;
-			reg = <0x58007000 0x1000>, <0x58008000 0x1000>;
-			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC2_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC2_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <130000000>;
-			status = "disabled";
-		};
-
 		usbh_ohci: usb at 5800c000 {
 			compatible = "generic-ohci";
 			reg = <0x5800c000 0x1000>;
@@ -1342,29 +850,6 @@ iwdg2: watchdog at 5a002000 {
 			status = "disabled";
 		};
 
-		usbphyc: usbphyc at 5a006000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			#clock-cells = <0>;
-			compatible = "st,stm32mp1-usbphyc";
-			reg = <0x5a006000 0x1000>;
-			clocks = <&rcc USBPHY_K>;
-			resets = <&rcc USBPHY_R>;
-			vdda1v1-supply = <&scmi_reg11>;
-			vdda1v8-supply = <&scmi_reg18>;
-			status = "disabled";
-
-			usbphyc_port0: usb-phy at 0 {
-				#phy-cells = <0>;
-				reg = <0>;
-			};
-
-			usbphyc_port1: usb-phy at 1 {
-				#phy-cells = <1>;
-				reg = <1>;
-			};
-		};
-
 		rtc: rtc at 5c004000 {
 			compatible = "st,stm32mp1-rtc";
 			reg = <0x5c004000 0x400>;
@@ -1393,6 +878,527 @@ ts_cal2: calib at 5e {
 			};
 		};
 
+		etzpc: bus at 5c007000 {
+			compatible = "st,stm32-etzpc", "simple-bus";
+			reg = <0x5c007000 0x400>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			adc_2: adc at 48004000 {
+				compatible = "st,stm32mp13-adc-core";
+				reg = <0x48004000 0x400>;
+				interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc ADC2>, <&rcc ADC2_K>;
+				clock-names = "bus", "adc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+
+				adc2: adc at 0 {
+					compatible = "st,stm32mp13-adc";
+					#io-channel-cells = <1>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x0>;
+					interrupt-parent = <&adc_2>;
+					interrupts = <0>;
+					dmas = <&dmamux1 10 0x400 0x80000001>;
+					dma-names = "rx";
+					status = "disabled";
+
+					channel at 13 {
+						reg = <13>;
+						label = "vrefint";
+					};
+					channel at 14 {
+						reg = <14>;
+						label = "vddcore";
+					};
+					channel at 16 {
+						reg = <16>;
+						label = "vddcpu";
+					};
+					channel at 17 {
+						reg = <17>;
+						label = "vddq_ddr";
+					};
+				};
+			};
+
+			usbotg_hs: usb at 49000000 {
+				compatible = "st,stm32mp15-hsotg", "snps,dwc2";
+				reg = <0x49000000 0x40000>;
+				clocks = <&rcc USBO_K>;
+				clock-names = "otg";
+				resets = <&rcc USBO_R>;
+				reset-names = "dwc2";
+				interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+				g-rx-fifo-size = <512>;
+				g-np-tx-fifo-size = <32>;
+				g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
+				dr_mode = "otg";
+				otg-rev = <0x200>;
+				usb33d-supply = <&scmi_usb33>;
+				status = "disabled";
+			};
+
+			usart1: serial at 4c000000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x4c000000 0x400>;
+				interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART1_K>;
+				resets = <&rcc USART1_R>;
+				wakeup-source;
+				dmas = <&dmamux1 41 0x400 0x5>,
+				<&dmamux1 42 0x400 0x1>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			usart2: serial at 4c001000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x4c001000 0x400>;
+				interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART2_K>;
+				resets = <&rcc USART2_R>;
+				wakeup-source;
+				dmas = <&dmamux1 43 0x400 0x5>,
+				<&dmamux1 44 0x400 0x1>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			i2s4: audio-controller at 4c002000 {
+				compatible = "st,stm32h7-i2s";
+				reg = <0x4c002000 0x400>;
+				#sound-dai-cells = <0>;
+				interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 83 0x400 0x01>,
+				<&dmamux1 84 0x400 0x01>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			spi4: spi at 4c002000 {
+				compatible = "st,stm32h7-spi";
+				reg = <0x4c002000 0x400>;
+				interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI4_K>;
+				resets = <&rcc SPI4_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 83 0x400 0x01>,
+				       <&dmamux1 84 0x400 0x01>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			spi5: spi at 4c003000 {
+				compatible = "st,stm32h7-spi";
+				reg = <0x4c003000 0x400>;
+				interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI5_K>;
+				resets = <&rcc SPI5_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 85 0x400 0x01>,
+				       <&dmamux1 86 0x400 0x01>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			i2c3: i2c at 4c004000 {
+				compatible = "st,stm32mp13-i2c";
+				reg = <0x4c004000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C3_K>;
+				resets = <&rcc I2C3_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 73 0x400 0x1>,
+				       <&dmamux1 74 0x400 0x1>;
+				dma-names = "rx", "tx";
+				st,syscfg-fmp = <&syscfg 0x4 0x4>;
+				i2c-analog-filter;
+				status = "disabled";
+			};
+
+			i2c4: i2c at 4c005000 {
+				compatible = "st,stm32mp13-i2c";
+				reg = <0x4c005000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C4_K>;
+				resets = <&rcc I2C4_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 75 0x400 0x1>,
+				       <&dmamux1 76 0x400 0x1>;
+				dma-names = "rx", "tx";
+				st,syscfg-fmp = <&syscfg 0x4 0x8>;
+				i2c-analog-filter;
+				status = "disabled";
+			};
+
+			i2c5: i2c at 4c006000 {
+				compatible = "st,stm32mp13-i2c";
+				reg = <0x4c006000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C5_K>;
+				resets = <&rcc I2C5_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 115 0x400 0x1>,
+				       <&dmamux1 116 0x400 0x1>;
+				dma-names = "rx", "tx";
+				st,syscfg-fmp = <&syscfg 0x4 0x10>;
+				i2c-analog-filter;
+				status = "disabled";
+			};
+
+			timers12: timer at 4c007000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c007000 0x400>;
+				interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM12_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 11 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <11>;
+					status = "disabled";
+				};
+			};
+
+			timers13: timer at 4c008000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c008000 0x400>;
+				interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM13_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 12 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <12>;
+					status = "disabled";
+				};
+			};
+
+			timers14: timer at 4c009000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c009000 0x400>;
+				interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM14_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 13 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <13>;
+					status = "disabled";
+				};
+			};
+
+			timers15: timer at 4c00a000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c00a000 0x400>;
+				interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM15_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 105 0x400 0x1>,
+				<&dmamux1 106 0x400 0x1>,
+				<&dmamux1 107 0x400 0x1>,
+				<&dmamux1 108 0x400 0x1>;
+				dma-names = "ch1", "up", "trig", "com";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 14 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <14>;
+					status = "disabled";
+				};
+			};
+
+			timers16: timer at 4c00b000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c00b000 0x400>;
+				interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM16_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 109 0x400 0x1>,
+				<&dmamux1 110 0x400 0x1>;
+				dma-names = "ch1", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 15 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <15>;
+					status = "disabled";
+				};
+			};
+
+			timers17: timer at 4c00c000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c00c000 0x400>;
+				interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM17_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 111 0x400 0x1>,
+				       <&dmamux1 112 0x400 0x1>;
+				dma-names = "ch1", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 16 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <16>;
+					status = "disabled";
+				};
+			};
+
+			lptimer2: timer at 50021000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x50021000 0x400>;
+				interrupts-extended = <&exti 48 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM2_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				trigger at 1 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <1>;
+					status = "disabled";
+				};
+
+				counter {
+					compatible = "st,stm32-lptimer-counter";
+					status = "disabled";
+				};
+
+				timer {
+					compatible = "st,stm32-lptimer-timer";
+					status = "disabled";
+				};
+			};
+
+			lptimer3: timer at 50022000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x50022000 0x400>;
+				interrupts-extended = <&exti 50 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM3_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				trigger at 2 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <2>;
+					status = "disabled";
+				};
+
+				timer {
+					compatible = "st,stm32-lptimer-timer";
+					status = "disabled";
+				};
+			};
+
+			hash: hash at 54003000 {
+				compatible = "st,stm32mp13-hash";
+				reg = <0x54003000 0x400>;
+				interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc HASH1>;
+				resets = <&rcc HASH1_R>;
+				dmas = <&mdma 30 0x2 0x1000a02 0x0 0x0>;
+				dma-names = "in";
+			};
+
+			rng: rng at 54004000 {
+				compatible = "st,stm32mp13-rng";
+				reg = <0x54004000 0x400>;
+				clocks = <&rcc RNG1_K>;
+				resets = <&rcc RNG1_R>;
+			};
+
+			fmc: memory-controller at 58002000 {
+				compatible = "st,stm32mp1-fmc2-ebi";
+				reg = <0x58002000 0x1000>;
+				ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
+					 <1 0 0x64000000 0x04000000>, /* EBI CS 2 */
+					 <2 0 0x68000000 0x04000000>, /* EBI CS 3 */
+					 <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */
+					 <4 0 0x80000000 0x10000000>; /* NAND */
+				#address-cells = <2>;
+				#size-cells = <1>;
+				clocks = <&rcc FMC_K>;
+				resets = <&rcc FMC_R>;
+				status = "disabled";
+
+				nand-controller at 4,0 {
+					compatible = "st,stm32mp1-fmc2-nfc";
+					reg = <4 0x00000000 0x1000>,
+					      <4 0x08010000 0x1000>,
+					      <4 0x08020000 0x1000>,
+					      <4 0x01000000 0x1000>,
+					      <4 0x09010000 0x1000>,
+					      <4 0x09020000 0x1000>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&mdma 24 0x2 0x12000a02 0x0 0x0>,
+					       <&mdma 24 0x2 0x12000a08 0x0 0x0>,
+					       <&mdma 25 0x2 0x12000a0a 0x0 0x0>;
+					dma-names = "tx", "rx", "ecc";
+					status = "disabled";
+				};
+			};
+
+			qspi: spi at 58003000 {
+				compatible = "st,stm32f469-qspi";
+				reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
+				reg-names = "qspi", "qspi_mm";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&mdma 26 0x2 0x10100002 0x0 0x0>,
+				       <&mdma 26 0x2 0x10100008 0x0 0x0>;
+				dma-names = "tx", "rx";
+				clocks = <&rcc QSPI_K>;
+				resets = <&rcc QSPI_R>;
+				status = "disabled";
+			};
+
+			sdmmc1: mmc at 58005000 {
+				compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+				arm,primecell-periphid = <0x20253180>;
+				reg = <0x58005000 0x1000>, <0x58006000 0x1000>;
+				interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SDMMC1_K>;
+				clock-names = "apb_pclk";
+				resets = <&rcc SDMMC1_R>;
+				cap-sd-highspeed;
+				cap-mmc-highspeed;
+				max-frequency = <130000000>;
+				status = "disabled";
+			};
+
+			sdmmc2: mmc at 58007000 {
+				compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+				arm,primecell-periphid = <0x20253180>;
+				reg = <0x58007000 0x1000>, <0x58008000 0x1000>;
+				interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SDMMC2_K>;
+				clock-names = "apb_pclk";
+				resets = <&rcc SDMMC2_R>;
+				cap-sd-highspeed;
+				cap-mmc-highspeed;
+				max-frequency = <130000000>;
+				status = "disabled";
+			};
+
+			usbphyc: usbphyc at 5a006000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				#clock-cells = <0>;
+				compatible = "st,stm32mp1-usbphyc";
+				reg = <0x5a006000 0x1000>;
+				clocks = <&rcc USBPHY_K>;
+				resets = <&rcc USBPHY_R>;
+				vdda1v1-supply = <&scmi_reg11>;
+				vdda1v8-supply = <&scmi_reg18>;
+				status = "disabled";
+
+				usbphyc_port0: usb-phy at 0 {
+					#phy-cells = <0>;
+					reg = <0>;
+				};
+
+				usbphyc_port1: usb-phy at 1 {
+					#phy-cells = <1>;
+					reg = <1>;
+				};
+			};
+		};
+
 		/*
 		 * Break node order to solve dependency probe issue between
 		 * pinctrl and exti.
@@ -1404,6 +1410,7 @@ pinctrl: pinctrl at 50002000 {
 			ranges = <0 0x50002000 0x8400>;
 			interrupt-parent = <&exti>;
 			st,syscfg = <&exti 0x60 0xff>;
+			pins-are-numbered;
 
 			gpioa: gpio at 50002000 {
 				gpio-controller;
diff --git a/arch/arm/boot/dts/st/stm32mp133.dtsi b/arch/arm/boot/dts/st/stm32mp133.dtsi
index df451c3c2a26..c4d3a520c14b 100644
--- a/arch/arm/boot/dts/st/stm32mp133.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp133.dtsi
@@ -33,35 +33,37 @@ m_can2: can at 4400f000 {
 			bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
 			status = "disabled";
 		};
+	};
+};
 
-		adc_1: adc at 48003000 {
-			compatible = "st,stm32mp13-adc-core";
-			reg = <0x48003000 0x400>;
-			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc ADC1>, <&rcc ADC1_K>;
-			clock-names = "bus", "adc";
-			interrupt-controller;
-			#interrupt-cells = <1>;
+&etzpc {
+	adc_1: adc at 48003000 {
+		compatible = "st,stm32mp13-adc-core";
+		reg = <0x48003000 0x400>;
+		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&rcc ADC1>, <&rcc ADC1_K>;
+		clock-names = "bus", "adc";
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+
+		adc1: adc at 0 {
+			compatible = "st,stm32mp13-adc";
+			#io-channel-cells = <1>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+			reg = <0x0>;
+			interrupt-parent = <&adc_1>;
+			interrupts = <0>;
+			dmas = <&dmamux1 9 0x400 0x80000001>;
+			dma-names = "rx";
 			status = "disabled";
 
-			adc1: adc at 0 {
-				compatible = "st,stm32mp13-adc";
-				#io-channel-cells = <1>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x0>;
-				interrupt-parent = <&adc_1>;
-				interrupts = <0>;
-				dmas = <&dmamux1 9 0x400 0x80000001>;
-				dma-names = "rx";
-				status = "disabled";
-
-				channel at 18 {
-					reg = <18>;
-					label = "vrefint";
-				};
+			channel at 18 {
+				reg = <18>;
+				label = "vrefint";
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/st/stm32mp13xc.dtsi b/arch/arm/boot/dts/st/stm32mp13xc.dtsi
index 4d00e7592882..b9fb071a1471 100644
--- a/arch/arm/boot/dts/st/stm32mp13xc.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp13xc.dtsi
@@ -4,15 +4,13 @@
  * Author: Alexandre Torgue <alexandre.torgue at foss.st.com> for STMicroelectronics.
  */
 
-/ {
-	soc {
-		cryp: crypto at 54002000 {
-			compatible = "st,stm32mp1-cryp";
-			reg = <0x54002000 0x400>;
-			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CRYP1>;
-			resets = <&rcc CRYP1_R>;
-			status = "disabled";
-		};
+&etzpc {
+	cryp: crypto at 54002000 {
+		compatible = "st,stm32mp1-cryp";
+		reg = <0x54002000 0x400>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&rcc CRYP1>;
+		resets = <&rcc CRYP1_R>;
+		status = "disabled";
 	};
 };
diff --git a/arch/arm/boot/dts/st/stm32mp13xf.dtsi b/arch/arm/boot/dts/st/stm32mp13xf.dtsi
index 4d00e7592882..b9fb071a1471 100644
--- a/arch/arm/boot/dts/st/stm32mp13xf.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp13xf.dtsi
@@ -4,15 +4,13 @@
  * Author: Alexandre Torgue <alexandre.torgue at foss.st.com> for STMicroelectronics.
  */
 
-/ {
-	soc {
-		cryp: crypto at 54002000 {
-			compatible = "st,stm32mp1-cryp";
-			reg = <0x54002000 0x400>;
-			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CRYP1>;
-			resets = <&rcc CRYP1_R>;
-			status = "disabled";
-		};
+&etzpc {
+	cryp: crypto at 54002000 {
+		compatible = "st,stm32mp1-cryp";
+		reg = <0x54002000 0x400>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&rcc CRYP1>;
+		resets = <&rcc CRYP1_R>;
+		status = "disabled";
 	};
 };
-- 
2.35.3



From gregkh at linuxfoundation.org  Mon Dec 11 10:22:07 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 11 Dec 2023 19:22:07 +0100
Subject: [PATCH 6.6 234/244] perf metrics: Avoid segv if default metricgroup isnt set
In-Reply-To: <20231211182045.784881756@linuxfoundation.org>
References: <20231211182045.784881756@linuxfoundation.org>
Message-ID: <20231211182056.532304701@linuxfoundation.org>

6.6-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Ian Rogers <irogers at google.com>

commit e2b005d6ec0e738df584190e21d2c7ada37266a0 upstream.

A metric is default by having "Default" within its groups. The default
metricgroup name needn't be set and this can result in segv in
default_metricgroup_cmp and perf_stat__print_shadow_stats_metricgroup
that assume it has a value when there is a Default metric group. To
avoid the segv initialize the value to "".

Fixes: 1c0e47956a8e ("perf metrics: Sort the Default metricgroup")
Signed-off-by: Ian Rogers <irogers at google.com>
Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
Cc: James Clark <james.clark at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Leo Yan <leo.yan at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Kajol Jain <kjain at linux.ibm.com>
Cc: Kan Liang <kan.liang at linux.intel.com>
Cc: John Garry <john.g.garry at oracle.com>
Cc: stable at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Link: https://lore.kernel.org/r/20231204182330.654255-1-irogers at google.com
Signed-off-by: Namhyung Kim <namhyung at kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 tools/perf/util/metricgroup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 0484736d9fe4..ca3e0404f187 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -225,7 +225,7 @@ static struct metric *metric__new(const struct pmu_metric *pm,
 
 	m->pmu = pm->pmu ?: "cpu";
 	m->metric_name = pm->metric_name;
-	m->default_metricgroup_name = pm->default_metricgroup_name;
+	m->default_metricgroup_name = pm->default_metricgroup_name ?: "";
 	m->modifier = NULL;
 	if (modifier) {
 		m->modifier = strdup(modifier);
-- 
2.43.0





From kan.liang at linux.intel.com  Mon Dec 11 10:39:36 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Mon, 11 Dec 2023 13:39:36 -0500
Subject: [PATCH V2 3/5] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <20231209054809.GB2116834@leoy-yangtze.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-4-kan.liang@linux.intel.com>
 <20231209054809.GB2116834@leoy-yangtze.lan>
Message-ID: <3b67c2de-741d-4d5e-8c8f-87b8b9e08825@linux.intel.com>



On 2023-12-09 12:48 a.m., Leo Yan wrote:
> On Thu, Dec 07, 2023 at 11:23:36AM -0800, kan.liang at linux.intel.com wrote:
>> From: Kan Liang <kan.liang at linux.intel.com>
>>
>> Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
>> one.
> 
> Now memory event naming is arch dependent, this is because every arch
> has different memory PMU names, and it appends specific configurations
> (e.g. aarch64 appends 'ts_enable=1,...,min_latency=%u', and x86_64
> appends 'ldlat=%u', etc).  This is not friendly for extension, e.g. it's
> impossible for users to specify any extra attributes for memory events.
> 
> This patch tries to consolidate in a central place for generating memory
> event names, its approach is to add more flags to meet special usage
> cases, which means the code gets more complex (and more difficult for
> later's maintenance).
> 
> I think we need to distinguish the event naming into two levels: in
> util/mem-events.c, we can consider it as a common layer, and we maintain
> common options in it, e.g. 'latency', 'all-user', 'all-kernel',
> 'timestamp', 'physical_address', etc.  In every arch's mem-events.c
> file, it converts the common options to arch specific configurations.
> 
> In the end, this can avoid to add more and more flags into the
> structure perf_mem_event.

The purpose of this cleanup patch set is to remove the unnecessary
__weak functions, and try to make the code more generic.
The two flags has already covered all the current usage.
For now, it's good enough.

I agree that if there are more flags, it should not be a perfect
solution. But we don't have the third flag right now. Could we clean up
it later e.g., when introducing the third flag?

I just don't want to make the patch bigger and bigger. Also, I don't
think we usually implement something just for future possibilities.


> 
> Anyway, I also have a question for this patch itself, please see below
> inline comment.
> 
> [...]
> 
>> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
>> index 2602e8688727..eb2ef84f0fc8 100644
>> --- a/tools/perf/arch/arm64/util/mem-events.c
>> +++ b/tools/perf/arch/arm64/util/mem-events.c
>> @@ -2,28 +2,10 @@
>>  #include "map_symbol.h"
>>  #include "mem-events.h"
>>  
>> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
>>  
>>  struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
>> -	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
>> -	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
>> -	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
>> +	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0",	true,	0),
>> +	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0",	false,	0),
>> +	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0",	true,	0),
> 
> Arm SPE is AUX event, should set '1' to the field '.aux_event'.

It actually means whether an extra event is required with a mem_loads
event.  I guess for ARM the answer is no.

> 
> I am a bit suspect if we really need the field '.aux_event', the
> '.aux_event' field is only used for generating event string.

No, it stores the event encoding for the extra event.
ARM doesn't need it, so it's 0.

> 
> So in the below function perf_pmu__mem_events_name(), I prefer to call
> an arch specific function, e.g. arch_memory_event_name(event_id, cfg),
> the parameter 'event_id' passes memory event ID for load, store, and
> load-store, and the parameter 'cfg' which is a pointer to the common
> memory options (as mentioned above for latency, all-user or all-kernel
> mode, timestamp tracing, etc).

If I understand correctly, I think we try to avoid the __weak function
for the perf tool. If there will be more parameters later, a mask may be
used for the parameters. But, again, I think it should be an improvement
for later.

Thanks,
Kan
> 
> In the end, the common layer just passes the common options to low
> level arch's layer and get a event string for recording.
> 
> Thanks,
> Leo


From kan.liang at linux.intel.com  Mon Dec 11 10:44:54 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Mon, 11 Dec 2023 13:44:54 -0500
Subject: [PATCH V2 4/5] perf mem: Clean up perf_mem_event__supported()
In-Reply-To: <20231209061723.GC2116834@leoy-yangtze.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-5-kan.liang@linux.intel.com>
 <20231209061723.GC2116834@leoy-yangtze.lan>
Message-ID: <2865c1b4-a003-44df-a734-1e1c90bfa14d@linux.intel.com>



On 2023-12-09 1:17 a.m., Leo Yan wrote:
> On Thu, Dec 07, 2023 at 11:23:37AM -0800, kan.liang at linux.intel.com wrote:
>> From: Kan Liang <kan.liang at linux.intel.com>
>>
>> For some ARCHs, e.g., ARM and AMD, to get the availability of the
>> mem-events, perf checks the existence of a specific PMU. For the other
>> ARCHs, e.g., Intel and Power, perf has to check the existence of some
>> specific events.
>>
>> The current perf only iterates the mem-events-supported PMUs. It's not
>> required to check the existence of a specific PMU anymore.
> 
> With this change, both Arm and AMD archs have no chance to detect if the
> hardware (or the device driver) is supported and the tool will always
> take the memory events are exited on the system, right?

Currently, the Arm and AMD only check the specific PMU. If the PMU is
detected, the memory events are supported. The patch set doesn't change
it. It just moves the check to perf_pmu__arch_init(). When the specific
PMU is initialized, the mem_events is assigned. You don't need to do
runtime sysfs check. It should be an improvement for ARM and AMD.

Thanks,
Kan

> 
> Thanks,
> Leo
> 


From kan.liang at linux.intel.com  Mon Dec 11 10:45:24 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Mon, 11 Dec 2023 13:45:24 -0500
Subject: [PATCH V2 5/5] perf mem: Clean up is_mem_loads_aux_event()
In-Reply-To: <20231209062709.GD2116834@leoy-yangtze.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-6-kan.liang@linux.intel.com>
 <20231209062709.GD2116834@leoy-yangtze.lan>
Message-ID: <ab399f36-bef6-4ff7-92b9-95ed873ce822@linux.intel.com>



On 2023-12-09 1:27 a.m., Leo Yan wrote:
> On Thu, Dec 07, 2023 at 11:23:38AM -0800, kan.liang at linux.intel.com wrote:
>> From: Kan Liang <kan.liang at linux.intel.com>
>>
>> The aux_event can be retrieved from the perf_pmu now. Implement a
>> generic support.
>>
>> Reviewed-by: Ian Rogers <irogers at google.com>
>> Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
>> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
>> ---
>>  tools/perf/arch/x86/util/mem-events.c | 23 ++++-------------------
>>  tools/perf/util/mem-events.c          | 14 ++++++++++++--
>>  2 files changed, 16 insertions(+), 21 deletions(-)
>>
>> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
>> index b776d849fc64..62df03e91c7e 100644
>> --- a/tools/perf/arch/x86/util/mem-events.c
>> +++ b/tools/perf/arch/x86/util/mem-events.c
>> @@ -1,11 +1,9 @@
>>  // SPDX-License-Identifier: GPL-2.0
>> -#include "util/pmu.h"
>> -#include "util/pmus.h"
>> -#include "util/env.h"
>> -#include "map_symbol.h"
>> -#include "mem-events.h"
>>  #include "linux/string.h"
>> -#include "env.h"
>> +#include "util/map_symbol.h"
>> +#include "util/mem-events.h"
>> +#include "mem-events.h"
>> +
>>  
>>  #define MEM_LOADS_AUX		0x8203
>>  
>> @@ -28,16 +26,3 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
>>  	E(NULL,		NULL,		NULL,	false,	0),
>>  	E("mem-ldst",	"%s//",		NULL,	false,	0),
>>  };
>> -
>> -bool is_mem_loads_aux_event(struct evsel *leader)
>> -{
>> -	struct perf_pmu *pmu = perf_pmus__find("cpu");
>> -
>> -	if (!pmu)
>> -		pmu = perf_pmus__find("cpu_core");
>> -
>> -	if (pmu && !perf_pmu__have_event(pmu, "mem-loads-aux"))
>> -		return false;
>> -
>> -	return leader->core.attr.config == MEM_LOADS_AUX;
>> -}
>> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
>> index 0d174f161034..d418320e52e3 100644
>> --- a/tools/perf/util/mem-events.c
>> +++ b/tools/perf/util/mem-events.c
>> @@ -103,9 +103,19 @@ static const char *perf_pmu__mem_events_name(int i, struct perf_pmu *pmu)
>>  	return NULL;
>>  }
>>  
>> -__weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
>> +bool is_mem_loads_aux_event(struct evsel *leader)
>>  {
>> -	return false;
>> +	struct perf_pmu *pmu = leader->pmu;
>> +	struct perf_mem_event *e;
>> +
>> +	if (!pmu || !pmu->mem_events)
>> +		return false;
>> +
>> +	e = &pmu->mem_events[PERF_MEM_EVENTS__LOAD];
>> +	if (!e->aux_event)
>> +		return false;
>> +
>> +	return leader->core.attr.config == e->aux_event;
>>  }
> 
> I am wandering if we need to set the field 'aux_event' for Arm SPE.
> 
> So a quesiton maybe is not relevant with this patch actually, we can
> see is_mem_loads_aux_event() is invoked in the file util/record.c:
> 
>   static struct evsel *evsel__read_sampler(struct evsel *evsel, struct evlist *evlist)
>   {
>           struct evsel *leader = evsel__leader(evsel);
> 
>           if (evsel__is_aux_event(leader) || arch_topdown_sample_read(leader) ||
>               is_mem_loads_aux_event(leader)) {
>               ...
>           }
>   
>           return leader;
>   }
> 
> Has evsel__is_aux_event() covered the memory load aux event?  If it's,
> then is_mem_loads_aux_event() is not needed anymore.

They are two different things. The evsel__is_aux_event() should means an
event requires AUX area, like intel_pt.

While the aux event for the mem_loads event is an extra event which has
to be scheduled together with the mem_loads event when sampling. It's
only available for some Intel platforms, e.g., SPR.

Thanks,
Kan
> 
> Thanks,
> Leo


From gatien.chevallier at foss.st.com  Mon Dec 11 10:48:02 2023
From: gatien.chevallier at foss.st.com (Gatien CHEVALLIER)
Date: Mon, 11 Dec 2023 19:48:02 +0100
Subject: [PATCH v7 00/13] Introduce STM32 Firewall framework
In-Reply-To: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
References: <20231211183044.808204-1-gatien.chevallier@foss.st.com>
Message-ID: <719399bd-273d-40b5-b512-59a2e09ddbf8@foss.st.com>

Hi,

I messed up when squashing.

I did not restore the ETZPC/RIFSC "simple-bus" compatible for stm32mp15
and stm32mp25 SoC device trees.

I apologize for this inconvenience and will resend the patchset with
this compatible correctly restored.

Best regards,
Gatien

On 12/11/23 19:30, Gatien Chevallier wrote:
> Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x
> platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers
> register to the framework to offer firewall services such as access
> granting.
> 
> This series of patches is a new approach on the previous STM32 system
> bus, history is available here:
> https://lore.kernel.org/lkml/20230127164040.1047583/
> 
> The need for such framework arises from the fact that there are now
> multiple hardware firewalls implemented across multiple products.
> Drivers are shared between different products, using the same code.
> When it comes to firewalls, the purpose mostly stays the same: Protect
> hardware resources. But the implementation differs, and there are
> multiple types of firewalls: peripheral, memory, ...
> 
> Some hardware firewall controllers such as the RIFSC implemented on
> STM32MP2x platforms may require to take ownership of a resource before
> being able to use it, hence the requirement for firewall services to
> take/release the ownership of such resources.
> 
> On the other hand, hardware firewall configurations are becoming
> more and more complex. These mecanisms prevent platform crashes
> or other firewall-related incoveniences by denying access to some
> resources.
> 
> The stm32 firewall framework offers an API that is defined in
> firewall controllers drivers to best fit the specificity of each
> firewall.
> 
> For every peripherals protected by either the ETZPC or the RIFSC, the
> firewall framework checks the firewall controlelr registers to see if
> the peripheral's access is granted to the Linux kernel. If not, the
> peripheral is configured as secure, the node is marked populated,
> so that the driver is not probed for that device.
> 
> The firewall framework relies on the access-controller device tree
> binding. It is used by peripherals to reference a domain access
> controller. In this case a firewall controller. The bus uses the ID
> referenced by the access-controller property to know where to look
> in the firewall to get the security configuration for the peripheral.
> This allows a device tree description rather than a hardcoded peripheral
> table in the bus driver.
> 
> The STM32 ETZPC device is responsible for filtering accesses based on
> security level, or co-processor isolation for any resource connected
> to it.
> 
> The RIFSC is responsible for filtering accesses based on Compartment
> ID / security level / privilege level for any resource connected to
> it.
> 
> STM32MP13/15/25 SoC device tree files are updated in this series to
> implement this mecanism.
> 
> Changes in V7:
> 	- Separate indentation changes from access-controllers changes
> 	  in the device tree file commits
> 	- Select OF_DYNAMIC when STM32_FIREWALL is set in order to use
> 	  of_detach_node() in the firewall framework
> 	- Handle previously non-present RNG and HASH nodes in the
> 	  STM32MP13 device tree file
> 
> Changes in V6:
> 	- Rename access-controller to access-controllers
> 	- Remove access-controller-provider
> 	- Update device trees and other bindings accordingly
> 	- Rework ETZPC/RIFSC bindings to define what access-controllers
> 	  cells contain inside #access-controller-cells
> 	- Some other minor fixes
> 
> Changes in V5:
> 	- Integrate and rework the "feature-domains" binding patch in
> 	  this patchset. The binding is renamed to "access-controller"
> 	- Rename every feature-domain* reference to access-control*
> 	  ones
> 	- Correct loop bug and missing select STM32_FIREWALL in 32-bit
> 	  platform Kconfig
> 	
> 
> Changes in V4:
> 	- Fix typo in commit message and YAML check errors in
> 	  "dt-bindings: Document common device controller bindings"
> 	  Note: This patch should be ignored as stated in the cover
> 	  letter. I've done this to avoid errors on this series of
> 	  patch
> 	- Correct code syntax/style issues reported by Simon Horman
> 	- Added Jonathan's tag for IIO on the treewide patch
> 
> Changes in V3:
> 
> 	Change incorrect ordering for bindings commits leading
> 	to an error while running
> 	"make DT_CHECKER_FLAGS=-m dt_binding_check"
> 
> Changes in V2:
> 
> 	generic:
> 		- Add fw_devlink dependency for "feature-domains"
> 		  property.
> 
> 	bindings:
> 		- Corrected YAMLS errors highlighted by Rob's robot
> 		- Firewall controllers YAMLs no longer define the
> 		  maxItems for the "feature-domains" property
> 		- Renamed st,stm32-rifsc.yaml to
> 		  st,stm32mp25-rifsc.yaml
> 		- Fix examples in YAML files
> 		- Change feature-domains maxItems to 2 in firewall
> 		  consumer files as there should not be more than
> 		  2 entries for now
> 		- Declare "feature-domain-names" as an optional
> 		  property for firewall controllers child nodes.
> 		- Add missing "feature-domains" property declaration
> 		  in bosch,m_can.yaml and st,stm32-cryp.yaml files
> 
> 	firewall framework:
> 		- Support multiple entries for "feature-domains"
> 		  property
> 		- Better handle the device-tree parsing using
> 		  phandle+args APIs
> 		- Remove "resource firewall" type
> 		- Add a field for the name of the firewall entry
> 		- Fix licenses
> 	
> 	RIFSC:
> 		- Add controller name
> 		- Driver is now a module_platform_driver
> 		- Fix license
> 
> 	ETZPC:
> 		- Add controller name
> 		- Driver is now a module_platform_driver
> 		- Fix license
> 
> 	Device trees:
> 		- Fix rifsc node name
> 		- Move the "ranges" property under the
> 		  "feature-domains" one
> 
> Gatien Chevallier (12):
>    dt-bindings: treewide: add access-controllers description
>    dt-bindings: bus: document RIFSC
>    dt-bindings: bus: document ETZPC
>    firewall: introduce stm32_firewall framework
>    of: property: fw_devlink: Add support for "access-controller"
>    bus: rifsc: introduce RIFSC firewall controller driver
>    arm64: dts: st: add RIFSC as an access controller for STM32MP25x
>      boards
>    bus: etzpc: introduce ETZPC firewall controller driver
>    ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
>    ARM: dts: stm32: put ETZPC as an access controller for STM32MP15x
>      boards
>    ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards
>    ARM: dts: stm32: put ETZPC as an access controller for STM32MP13x
>      boards
> 
> Oleksii Moisieiev (1):
>    dt-bindings: document generic access controllers
> 
>   .../access-controllers.yaml                   |   84 +
>   .../bindings/bus/st,stm32-etzpc.yaml          |   87 +
>   .../bindings/bus/st,stm32mp25-rifsc.yaml      |   96 +
>   .../bindings/crypto/st,stm32-cryp.yaml        |    4 +
>   .../bindings/crypto/st,stm32-hash.yaml        |    4 +
>   .../devicetree/bindings/dma/st,stm32-dma.yaml |    4 +
>   .../bindings/dma/st,stm32-dmamux.yaml         |    4 +
>   .../devicetree/bindings/i2c/st,stm32-i2c.yaml |    4 +
>   .../bindings/iio/adc/st,stm32-adc.yaml        |    4 +
>   .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml  |    4 +
>   .../bindings/iio/dac/st,stm32-dac.yaml        |    4 +
>   .../bindings/media/cec/st,stm32-cec.yaml      |    4 +
>   .../bindings/media/st,stm32-dcmi.yaml         |    4 +
>   .../memory-controllers/st,stm32-fmc2-ebi.yaml |    4 +
>   .../bindings/mfd/st,stm32-lptimer.yaml        |    4 +
>   .../bindings/mfd/st,stm32-timers.yaml         |    4 +
>   .../devicetree/bindings/mmc/arm,pl18x.yaml    |    4 +
>   .../bindings/net/can/bosch,m_can.yaml         |    4 +
>   .../devicetree/bindings/net/stm32-dwmac.yaml  |    4 +
>   .../bindings/phy/phy-stm32-usbphyc.yaml       |    4 +
>   .../bindings/regulator/st,stm32-vrefbuf.yaml  |    4 +
>   .../devicetree/bindings/rng/st,stm32-rng.yaml |    4 +
>   .../bindings/serial/st,stm32-uart.yaml        |    4 +
>   .../bindings/sound/st,stm32-i2s.yaml          |    4 +
>   .../bindings/sound/st,stm32-sai.yaml          |    4 +
>   .../bindings/sound/st,stm32-spdifrx.yaml      |    4 +
>   .../bindings/spi/st,stm32-qspi.yaml           |    4 +
>   .../devicetree/bindings/spi/st,stm32-spi.yaml |    4 +
>   .../devicetree/bindings/usb/dwc2.yaml         |    4 +
>   MAINTAINERS                                   |    7 +
>   arch/arm/boot/dts/st/stm32mp131.dtsi          | 1063 ++++---
>   arch/arm/boot/dts/st/stm32mp133.dtsi          |   51 +-
>   arch/arm/boot/dts/st/stm32mp13xc.dtsi         |   19 +-
>   arch/arm/boot/dts/st/stm32mp13xf.dtsi         |   19 +-
>   arch/arm/boot/dts/st/stm32mp151.dtsi          | 2756 +++++++++--------
>   arch/arm/boot/dts/st/stm32mp153.dtsi          |   52 +-
>   arch/arm/boot/dts/st/stm32mp15xc.dtsi         |   19 +-
>   arch/arm/mach-stm32/Kconfig                   |    1 +
>   arch/arm64/Kconfig.platforms                  |    1 +
>   arch/arm64/boot/dts/st/stm32mp251.dtsi        |    6 +-
>   drivers/bus/Kconfig                           |   10 +
>   drivers/bus/Makefile                          |    1 +
>   drivers/bus/stm32_etzpc.c                     |  141 +
>   drivers/bus/stm32_firewall.c                  |  294 ++
>   drivers/bus/stm32_firewall.h                  |   83 +
>   drivers/bus/stm32_rifsc.c                     |  252 ++
>   drivers/of/property.c                         |    2 +
>   include/linux/bus/stm32_firewall_device.h     |  141 +
>   48 files changed, 3351 insertions(+), 1938 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
>   create mode 100644 Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
>   create mode 100644 Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
>   create mode 100644 drivers/bus/stm32_etzpc.c
>   create mode 100644 drivers/bus/stm32_firewall.c
>   create mode 100644 drivers/bus/stm32_firewall.h
>   create mode 100644 drivers/bus/stm32_rifsc.c
>   create mode 100644 include/linux/bus/stm32_firewall_device.h
> 


From catalin.marinas at arm.com  Mon Dec 11 10:49:37 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 11 Dec 2023 18:49:37 +0000
Subject: [PATCH v3 14/25] arm64: implement PKEYS support
In-Reply-To: <20231124163510.1835740-15-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-15-joey.gouly@arm.com>
Message-ID: <ZXdZwRcc0BaEq-Uv@arm.com>

On Fri, Nov 24, 2023 at 04:34:59PM +0000, Joey Gouly wrote:
> @@ -211,11 +212,24 @@ init_new_context(struct task_struct *tsk, struct mm_struct *mm)
>  {
>  	atomic64_set(&mm->context.id, 0);
>  	refcount_set(&mm->context.pinned, 0);
> +
> +	// pkey 0 is the default, so always reserve it.
> +	mm->context.pkey_allocation_map = 0x1;

Nit: use /* */ style comments.

> @@ -151,7 +170,9 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
>   * PTE_VALID bit set.
>   */
>  #define pte_access_permitted(pte, write) \
> -	(((pte_val(pte) & (PTE_VALID | PTE_USER)) == (PTE_VALID | PTE_USER)) && (!(write) || pte_write(pte)))
> +	(((pte_val(pte) & (PTE_VALID | PTE_USER)) == (PTE_VALID | PTE_USER)) && \
> +	 (!(write) || pte_write(pte)) && \
> +	 por_el0_allows_pkey(FIELD_GET(PTE_PO_IDX_MASK, pte_val(pte)), write, false))

Do not change pte_access_permitted(), just let it handle the base
permissions. This check is about the mm tables, not some current POR_EL0
setting of the thread.

As an example, with this change Linux may decide not to clear the MTE
tags just because the current POR_EL0 says no-access. The thread
subsequently changes POR_EL0 and it can read the stale tags.

I haven't checked what x86 and powerpc do here. There may be some
implications on GUP but I'd rather ignore POE for this case.

>  #define pmd_access_permitted(pmd, write) \
>  	(pte_access_permitted(pmd_pte(pmd), (write)))
>  #define pud_access_permitted(pud, write) \
> diff --git a/arch/arm64/include/asm/pkeys.h b/arch/arm64/include/asm/pkeys.h
> index 5761fb48fd53..a80c654da93d 100644
> --- a/arch/arm64/include/asm/pkeys.h
> +++ b/arch/arm64/include/asm/pkeys.h
[...]
>  static inline int execute_only_pkey(struct mm_struct *mm)
>  {
> +	// Execute-only mappings are handled by EPAN/FEAT_PAN3.
> +	WARN_ON_ONCE(!cpus_have_final_cap(ARM64_HAS_EPAN));
> +
>  	return -1;
>  }

Why the WARN_ON_ONCE() here? It will trigger if the user asks for
PROT_EXEC and I can't see any subsequent patch that changes the core
code not to call it. I think we need some arch_has_execute_only_pkey()
to avoid going on this path. Our arch would support exec-only with any
pkey.

> @@ -1490,6 +1491,38 @@ void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr, pte
>  #ifdef CONFIG_ARCH_HAS_PKEYS
>  int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, unsigned long init_val)
>  {
> -	return -ENOSPC;
> +	u64 new_por = POE_RXW;
> +	u64 old_por;
> +	u64 pkey_shift;
> +
> +	if (!arch_pkeys_enabled())
> +		return -ENOSPC;
> +
> +	/*
> +	 * This code should only be called with valid 'pkey'
> +	 * values originating from in-kernel users.  Complain
> +	 * if a bad value is observed.
> +	 */
> +	if (WARN_ON_ONCE(pkey >= arch_max_pkey()))
> +		return -EINVAL;
> +
> +	/* Set the bits we need in POR:  */
> +	if (init_val & PKEY_DISABLE_ACCESS)
> +		new_por = POE_X;

Does PKEY_DISABLE_ACCESS mean allow execute? Or does x86 not have a way
to disable execution?

> +	else if (init_val & PKEY_DISABLE_WRITE)
> +		new_por = POE_RX;
> +
> +	/* Shift the bits in to the correct place in POR for pkey: */
> +	pkey_shift = pkey * POR_BITS_PER_PKEY;
> +	new_por <<= pkey_shift;
> +
> +	/* Get old POR and mask off any old bits in place: */
> +	old_por = read_sysreg_s(SYS_POR_EL0);
> +	old_por &= ~(POE_MASK << pkey_shift);
> +
> +	/* Write old part along with new part: */
> +	write_sysreg_s(old_por | new_por, SYS_POR_EL0);
> +
> +	return 0;
>  }
>  #endif

-- 
Catalin


From catalin.marinas at arm.com  Mon Dec 11 10:53:13 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 11 Dec 2023 18:53:13 +0000
Subject: [PATCH v3 15/25] arm64: add POE signal support
In-Reply-To: <20231124163510.1835740-16-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-16-joey.gouly@arm.com>
Message-ID: <ZXdamak1wDyUdwSG@arm.com>

+ Szabolcs for libc ack (and keeping the full patch quoted below)

You should cc Szabolcs when reposting, we need his ack on the UAPI
changes.

On Fri, Nov 24, 2023 at 04:35:00PM +0000, Joey Gouly wrote:
> Add PKEY support to signals, by saving and restoring POR_EL0 from the stackframe.
> 
> Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Reviewed-by: Mark Brown <broonie at kernel.org>
> ---
>  arch/arm64/include/uapi/asm/sigcontext.h |  7 ++++
>  arch/arm64/kernel/signal.c               | 51 ++++++++++++++++++++++++
>  2 files changed, 58 insertions(+)
> 
> diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
> index f23c1dc3f002..cef85eeaf541 100644
> --- a/arch/arm64/include/uapi/asm/sigcontext.h
> +++ b/arch/arm64/include/uapi/asm/sigcontext.h
> @@ -98,6 +98,13 @@ struct esr_context {
>  	__u64 esr;
>  };
>  
> +#define POE_MAGIC	0x504f4530
> +
> +struct poe_context {
> +	struct _aarch64_ctx head;
> +	__u64 por_el0;
> +};
> +
>  /*
>   * extra_context: describes extra space in the signal frame for
>   * additional structures that don't fit in sigcontext.__reserved[].
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 0e8beb3349ea..379f364005bf 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -62,6 +62,7 @@ struct rt_sigframe_user_layout {
>  	unsigned long zt_offset;
>  	unsigned long extra_offset;
>  	unsigned long end_offset;
> +	unsigned long poe_offset;
>  };
>  
>  #define BASE_SIGFRAME_SIZE round_up(sizeof(struct rt_sigframe), 16)
> @@ -182,6 +183,8 @@ struct user_ctxs {
>  	u32 za_size;
>  	struct zt_context __user *zt;
>  	u32 zt_size;
> +	struct poe_context __user *poe;
> +	u32 poe_size;
>  };
>  
>  static int preserve_fpsimd_context(struct fpsimd_context __user *ctx)
> @@ -227,6 +230,20 @@ static int restore_fpsimd_context(struct user_ctxs *user)
>  	return err ? -EFAULT : 0;
>  }
>  
> +static int restore_poe_context(struct user_ctxs *user)
> +{
> +	u64 por_el0;
> +	int err = 0;
> +
> +	if (user->poe_size != sizeof(*user->poe))
> +		return -EINVAL;
> +
> +	__get_user_error(por_el0, &(user->poe->por_el0), err);
> +	if (!err)
> +		write_sysreg_s(por_el0, SYS_POR_EL0);
> +
> +	return err;
> +}
>  
>  #ifdef CONFIG_ARM64_SVE
>  
> @@ -590,6 +607,7 @@ static int parse_user_sigframe(struct user_ctxs *user,
>  	user->tpidr2 = NULL;
>  	user->za = NULL;
>  	user->zt = NULL;
> +	user->poe = NULL;
>  
>  	if (!IS_ALIGNED((unsigned long)base, 16))
>  		goto invalid;
> @@ -640,6 +658,17 @@ static int parse_user_sigframe(struct user_ctxs *user,
>  			/* ignore */
>  			break;
>  
> +		case POE_MAGIC:
> +			if (!system_supports_poe())
> +				goto invalid;
> +
> +			if (user->poe)
> +				goto invalid;
> +
> +			user->poe = (struct poe_context __user *)head;
> +			user->poe_size = size;
> +			break;
> +
>  		case SVE_MAGIC:
>  			if (!system_supports_sve() && !system_supports_sme())
>  				goto invalid;
> @@ -812,6 +841,9 @@ static int restore_sigframe(struct pt_regs *regs,
>  	if (err == 0 && system_supports_sme2() && user.zt)
>  		err = restore_zt_context(&user);
>  
> +	if (err == 0 && system_supports_poe() && user.poe)
> +		err = restore_poe_context(&user);
> +
>  	return err;
>  }
>  
> @@ -928,6 +960,13 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
>  		}
>  	}
>  
> +	if (system_supports_poe()) {
> +		err = sigframe_alloc(user, &user->poe_offset,
> +				     sizeof(struct poe_context));
> +		if (err)
> +			return err;
> +	}
> +
>  	return sigframe_alloc_end(user);
>  }
>  
> @@ -968,6 +1007,15 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
>  		__put_user_error(current->thread.fault_code, &esr_ctx->esr, err);
>  	}
>  
> +	if (system_supports_poe() && err == 0 && user->poe_offset) {
> +		struct poe_context __user *poe_ctx =
> +			apply_user_offset(user, user->poe_offset);
> +
> +		__put_user_error(POE_MAGIC, &poe_ctx->head.magic, err);
> +		__put_user_error(sizeof(*poe_ctx), &poe_ctx->head.size, err);
> +		__put_user_error(read_sysreg_s(SYS_POR_EL0), &poe_ctx->por_el0, err);
> +	}
> +
>  	/* Scalable Vector Extension state (including streaming), if present */
>  	if ((system_supports_sve() || system_supports_sme()) &&
>  	    err == 0 && user->sve_offset) {
> @@ -1119,6 +1167,9 @@ static void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
>  		sme_smstop();
>  	}
>  
> +	if (system_supports_poe())
> +		write_sysreg_s(POR_EL0_INIT, SYS_POR_EL0);
> +
>  	if (ka->sa.sa_flags & SA_RESTORER)
>  		sigtramp = ka->sa.sa_restorer;
>  	else
> -- 
> 2.25.1


From catalin.marinas at arm.com  Mon Dec 11 10:53:38 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 11 Dec 2023 18:53:38 +0000
Subject: [PATCH v3 16/25] arm64: enable PKEY support for CPUs with S1POE
In-Reply-To: <20231124163510.1835740-17-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-17-joey.gouly@arm.com>
Message-ID: <ZXdash8T8sngpbDa@arm.com>

On Fri, Nov 24, 2023 at 04:35:01PM +0000, Joey Gouly wrote:
> Now that PKEYs support has been implemented, enable it for CPUs that
> support S1POE.
> 
> Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From catalin.marinas at arm.com  Mon Dec 11 10:57:12 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 11 Dec 2023 18:57:12 +0000
Subject: [PATCH v3 17/25] arm64: enable POE and PIE to coexist
In-Reply-To: <20231124163510.1835740-18-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-18-joey.gouly@arm.com>
Message-ID: <ZXdbiEXUUXXX7n8Q@arm.com>

On Fri, Nov 24, 2023 at 04:35:02PM +0000, Joey Gouly wrote:
> Set the EL0/userspace indirection encodings to be the overlay enabled
> variants of the permissions.
> 
> Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> ---
>  arch/arm64/include/asm/pgtable-prot.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index e9624f6326dd..3007208e04aa 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -137,10 +137,10 @@ extern bool arm64_use_ng_mappings;
>  
>  #define PIE_E0	( \
>  	PIRx_ELx_PERM(pte_pi_index(_PAGE_EXECONLY),      PIE_X_O) | \
> -	PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY_EXEC), PIE_RX)  | \
> -	PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED_EXEC),   PIE_RWX) | \
> -	PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY),      PIE_R)   | \
> -	PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED),        PIE_RW))
> +	PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY_EXEC), PIE_RX_O)  | \
> +	PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED_EXEC),   PIE_RWX_O) | \
> +	PIRx_ELx_PERM(pte_pi_index(_PAGE_READONLY),      PIE_R_O)   | \
> +	PIRx_ELx_PERM(pte_pi_index(_PAGE_SHARED),        PIE_RW_O))
>  
>  #define PIE_E1	( \
>  	PIRx_ELx_PERM(pte_pi_index(_PAGE_EXECONLY),      PIE_NONE_O) | \

Don't we need to do this for PIE_E1? Or we consider the futex
(LDXR/STXR) accesses not checked by POE? That's fine by me if we go this
route but we should document it. The alternative is to enable overlay
variants in PIE_E1 but we need to reserve a POE key for the kernel to
use.

-- 
Catalin


From catalin.marinas at arm.com  Mon Dec 11 10:58:16 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 11 Dec 2023 18:58:16 +0000
Subject: [PATCH v3 18/25] arm64/ptrace: add support for FEAT_POE
In-Reply-To: <20231124163510.1835740-19-joey.gouly@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-19-joey.gouly@arm.com>
Message-ID: <ZXdbyB-fk65nOL3l@arm.com>

On Fri, Nov 24, 2023 at 04:35:03PM +0000, Joey Gouly wrote:
> Add a regset for POE containing POR_EL0.
> 
> Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>


From kan.liang at linux.intel.com  Mon Dec 11 11:01:37 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Mon, 11 Dec 2023 14:01:37 -0500
Subject: [PATCH V2 1/5] perf mem: Add mem_events into the supported
 perf_pmu
In-Reply-To: <20231209063440.GE2116834@leoy-yangtze.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-2-kan.liang@linux.intel.com>
 <20231208102922.GB769184@leoy-huanghe.lan>
 <98863f44-4a35-4910-8db0-dbbf0474f6ae@linux.intel.com>
 <20231209063440.GE2116834@leoy-yangtze.lan>
Message-ID: <ee9db34a-2b3d-46b3-ba36-22a22b080d70@linux.intel.com>



On 2023-12-09 1:34 a.m., Leo Yan wrote:
> Hi Kan,
> 
> On Fri, Dec 08, 2023 at 01:14:28PM -0500, Liang, Kan wrote:
> 
> [...]
> 
>>> Now I cannot access a machine for testing Arm SPE, but I will play
>>> a bit for this patch set to ensure it can pass compilation.  After
>>> that, I will seek Arm maintainers/reviewers help for the test.
>>
>> Thanks. I guess I will hold the v3 until the test is done in case there
>> are other issues found in ARM.
> 
> I will hold on a bit for the test until this patch set addresses the
> concern for the breakage issues on Arm64. Please check my review in
> other replies.

The reviews in the other replies don't look like break any current usage
on Arm64. I think the breakage issue is what you described in this
patch, right?

If we move the check of "arm_spe_0" to arch/arm/util/pmu.c, it seems we
have to move the perf_mem_events_arm[] into arch/arm/util/mem-events.c
as well. Is it OK?

I'm not familiar with ARM and have no idea how those events are
organized under arm64 and arm. Could you please send a fix for the
building failure on aarch64? I will fold it into the V3.

Thanks,
Kan
> 
> Thanks,
> Leo
> 


From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:57:55 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:57:55 +0200
Subject: [PATCH v5 02/13] pinctrl: mediatek: Use C99 initializers in PINCTRL_PIN_GROUP()
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-3-andriy.shevchenko@linux.intel.com>

For the better flexibility use C99 initializers in PINCTRL_PIN_GROUP().

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/mediatek/pinctrl-moore.h | 12 ++++++------
 drivers/pinctrl/mediatek/pinctrl-paris.h | 12 ++++++------
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.h b/drivers/pinctrl/mediatek/pinctrl-moore.h
index e1b4b82b9d3d..36ee0021cf7e 100644
--- a/drivers/pinctrl/mediatek/pinctrl-moore.h
+++ b/drivers/pinctrl/mediatek/pinctrl-moore.h
@@ -37,12 +37,12 @@
 		.funcs = NULL,				\
 	}
 
-#define PINCTRL_PIN_GROUP(name, id)			\
-	{						\
-		name,					\
-		id##_pins,				\
-		ARRAY_SIZE(id##_pins),			\
-		id##_funcs,				\
+#define PINCTRL_PIN_GROUP(_name_, id)							\
+	{										\
+		.name = _name_,								\
+		.pins = id##_pins,							\
+		.num_pins = ARRAY_SIZE(id##_pins),					\
+		.data = id##_funcs,							\
 	}
 
 int mtk_moore_pinctrl_probe(struct platform_device *pdev,
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.h b/drivers/pinctrl/mediatek/pinctrl-paris.h
index 8762ac599329..5c4e5b74e43e 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.h
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.h
@@ -49,12 +49,12 @@
 			__VA_ARGS__, { } },				\
 	}
 
-#define PINCTRL_PIN_GROUP(name, id)			\
-	{						\
-		name,					\
-		id##_pins,				\
-		ARRAY_SIZE(id##_pins),			\
-		id##_funcs,				\
+#define PINCTRL_PIN_GROUP(_name_, id)							\
+	{										\
+		.name = _name_,								\
+		.pins = id##_pins,							\
+		.num_pins = ARRAY_SIZE(id##_pins),					\
+		.data = id##_funcs,							\
 	}
 
 int mtk_paris_pinctrl_probe(struct platform_device *pdev);
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:57:54 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:57:54 +0200
Subject: [PATCH v5 01/13] pinctrl: core: Add a convenient define PINCTRL_GROUP_DESC()
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-2-andriy.shevchenko@linux.intel.com>

Add PINCTRL_GROUP_DESC() macro for inline use.

Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/core.c | 5 +----
 drivers/pinctrl/core.h | 9 +++++++++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 6380e1fa6509..75f2689c3bad 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -658,10 +658,7 @@ int pinctrl_generic_add_group(struct pinctrl_dev *pctldev, const char *name,
 	if (!group)
 		return -ENOMEM;
 
-	group->name = name;
-	group->pins = pins;
-	group->num_pins = num_pins;
-	group->data = data;
+	*group = PINCTRL_GROUP_DESC(name, pins, num_pins, data);
 
 	error = radix_tree_insert(&pctldev->pin_group_tree, selector, group);
 	if (error)
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index 8ef4b536bca5..bf971e6a7846 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -208,6 +208,15 @@ struct group_desc {
 	void *data;
 };
 
+/* Convenience macro to define a generic pin group descriptor */
+#define PINCTRL_GROUP_DESC(_name, _pins, _num_pins, _data)	\
+(struct group_desc) {						\
+	.name = _name,						\
+	.pins = _pins,						\
+	.num_pins = _num_pins,					\
+	.data = _data,						\
+}
+
 int pinctrl_generic_get_group_count(struct pinctrl_dev *pctldev);
 
 const char *pinctrl_generic_get_group_name(struct pinctrl_dev *pctldev,
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:57:57 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:57:57 +0200
Subject: [PATCH v5 04/13] pinctrl: core: Embed struct pingroup into struct group_desc
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-5-andriy.shevchenko@linux.intel.com>

struct group_desc is a particular version of the struct pingroup
with associated opaque data. Start switching pin control core and
drivers to use it explicitly.

Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/core.c | 15 ++++++++++++---
 drivers/pinctrl/core.h |  5 +++++
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 75f2689c3bad..48cc5571dea6 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -557,7 +557,10 @@ const char *pinctrl_generic_get_group_name(struct pinctrl_dev *pctldev,
 	if (!group)
 		return NULL;
 
-	return group->name;
+	if (group->name)
+		return group->name;
+
+	return group->grp.name;
 }
 EXPORT_SYMBOL_GPL(pinctrl_generic_get_group_name);
 
@@ -583,8 +586,14 @@ int pinctrl_generic_get_group_pins(struct pinctrl_dev *pctldev,
 		return -EINVAL;
 	}
 
-	*pins = group->pins;
-	*num_pins = group->num_pins;
+	if (group->pins) {
+		*pins = group->pins;
+		*num_pins = group->num_pins;
+		return 0;
+	}
+
+	*pins = group->grp.pins;
+	*num_pins = group->grp.npins;
 
 	return 0;
 }
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index bf971e6a7846..a3b75ec7b54b 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -194,14 +194,18 @@ struct pinctrl_maps {
 
 #ifdef CONFIG_GENERIC_PINCTRL_GROUPS
 
+#include <linux/pinctrl/pinctrl.h>
+
 /**
  * struct group_desc - generic pin group descriptor
+ * @grp: generic data of the pin group (name and pins)
  * @name: name of the pin group
  * @pins: array of pins that belong to the group
  * @num_pins: number of pins in the group
  * @data: pin controller driver specific data
  */
 struct group_desc {
+	struct pingroup grp;
 	const char *name;
 	const unsigned int *pins;
 	int num_pins;
@@ -211,6 +215,7 @@ struct group_desc {
 /* Convenience macro to define a generic pin group descriptor */
 #define PINCTRL_GROUP_DESC(_name, _pins, _num_pins, _data)	\
 (struct group_desc) {						\
+	.grp = PINCTRL_PINGROUP(_name, _pins, _num_pins),	\
 	.name = _name,						\
 	.pins = _pins,						\
 	.num_pins = _num_pins,					\
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:57:56 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:57:56 +0200
Subject: [PATCH v5 03/13] pinctrl: ingenic: Use C99 initializers in PINCTRL_PIN_GROUP()
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-4-andriy.shevchenko@linux.intel.com>

For the better flexibility use C99 initializers in PINCTRL_PIN_GROUP().

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/pinctrl-ingenic.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-ingenic.c b/drivers/pinctrl/pinctrl-ingenic.c
index ee718f6e2556..f5661dcdedf5 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -82,16 +82,21 @@
 #define PINS_PER_GPIO_CHIP			32
 #define JZ4730_PINS_PER_PAIRED_REG	16
 
-#define INGENIC_PIN_GROUP_FUNCS(name, id, funcs)		\
-	{						\
-		name,					\
-		id##_pins,				\
-		ARRAY_SIZE(id##_pins),			\
-		funcs,					\
+#define INGENIC_PIN_GROUP_FUNCS(_name_, id, funcs)					\
+	{										\
+		.name = _name_,								\
+		.pins = id##_pins,							\
+		.num_pins = ARRAY_SIZE(id##_pins),					\
+		.data = funcs,								\
 	}
 
-#define INGENIC_PIN_GROUP(name, id, func)		\
-	INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
+#define INGENIC_PIN_GROUP(_name_, id, func)						\
+	{										\
+		.name = _name_,								\
+		.pins = id##_pins,							\
+		.num_pins = ARRAY_SIZE(id##_pins),					\
+		.data = (void *)func,							\
+	}
 
 enum jz_version {
 	ID_JZ4730,
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:57:53 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:57:53 +0200
Subject: [PATCH v5 00/13] pinctrl: Convert struct group_desc to use struct pingroup
Message-ID: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>

The struct group_desc has a lot of duplication with struct pingroup.
Deduplicate that by embeddind the latter in the former and convert
users.

NB. The function_desc is in plan to follow the similar deduplication.

This time test-compiled with old GCC 8 for arm64, besides GCC 13 and
LLVM 16 for x86_64.

In v5:
- dropped applied patches
- elaborated the need of the conversion (Fabio)
- reworked to avoid build errors on old GCC (Marek, Krzysztof, Geert)

v4: https://lore.kernel.org/r/20231129161459.1002323-1-andriy.shevchenko at linux.intel.com

In v4:
- made pins also unsigned in struct group_desc (Geert)
- made local pins variable unsigned in renesas drivers (Geert)
- collected more tags (Paul, Geert)

v3: https://lore.kernel.org/r/20231128200155.438722-1-andriy.shevchenko at linux.intel.com

In v3:
- fixed reported bug in equilibrium code (LKP)                                                                   - collected tags (Emil, Florian, Paul)

v2: https://lore.kernel.org/r/20231123193355.3400852-1-andriy.shevchenko at linux.intel.com

In v2:
- added a few patches to fix multiple compile-time errors (LKP)
- added tag (Jonathan)

v1: https://lore.kernel.org/r/20231122164040.2262742-1-andriy.shevchenko at linux.intel.com

Andy Shevchenko (13):
  pinctrl: core: Add a convenient define PINCTRL_GROUP_DESC()
  pinctrl: mediatek: Use C99 initializers in PINCTRL_PIN_GROUP()
  pinctrl: ingenic: Use C99 initializers in PINCTRL_PIN_GROUP()
  pinctrl: core: Embed struct pingroup into struct group_desc
  pinctrl: bcm: Convert to use grp member
  pinctrl: equilibrium: Convert to use grp member
  pinctrl: imx: Convert to use grp member
  pinctrl: ingenic: Convert to use grp member
  pinctrl: keembay: Convert to use grp member
  pinctrl: mediatek: Convert to use grp member
  pinctrl: renesas: Convert to use grp member
  pinctrl: starfive: Convert to use grp member
  pinctrl: core: Remove unused members from struct group_desc

 drivers/pinctrl/bcm/pinctrl-ns.c              |  4 +--
 drivers/pinctrl/core.c                        | 11 +++---
 drivers/pinctrl/core.h                        | 17 +++++----
 drivers/pinctrl/freescale/pinctrl-imx.c       | 31 ++++++++--------
 drivers/pinctrl/mediatek/pinctrl-moore.c      | 13 ++++---
 drivers/pinctrl/mediatek/pinctrl-moore.h      | 10 +++---
 drivers/pinctrl/mediatek/pinctrl-paris.h      | 10 +++---
 drivers/pinctrl/pinctrl-equilibrium.c         |  4 +--
 drivers/pinctrl/pinctrl-ingenic.c             | 35 ++++++++++---------
 drivers/pinctrl/pinctrl-keembay.c             |  2 +-
 drivers/pinctrl/renesas/pinctrl-rza1.c        |  2 +-
 drivers/pinctrl/renesas/pinctrl-rza2.c        | 10 +++---
 drivers/pinctrl/renesas/pinctrl-rzg2l.c       |  4 +--
 drivers/pinctrl/renesas/pinctrl-rzv2m.c       |  4 +--
 .../starfive/pinctrl-starfive-jh7100.c        |  8 ++---
 .../starfive/pinctrl-starfive-jh7110.c        |  8 ++---
 16 files changed, 84 insertions(+), 89 deletions(-)

-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:58:00 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:58:00 +0200
Subject: [PATCH v5 07/13] pinctrl: imx: Convert to use grp member
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-8-andriy.shevchenko@linux.intel.com>

Convert drivers to use grp member embedded in struct group_desc,
because other members will be removed to avoid duplication and
desynchronisation of the generic pin group description.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/freescale/pinctrl-imx.c | 31 +++++++++++--------------
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c b/drivers/pinctrl/freescale/pinctrl-imx.c
index 28164b04b1be..2d3d80921c0d 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -42,7 +42,7 @@ static inline const struct group_desc *imx_pinctrl_find_group_by_name(
 
 	for (i = 0; i < pctldev->num_groups; i++) {
 		grp = pinctrl_generic_get_group(pctldev, i);
-		if (grp && !strcmp(grp->name, name))
+		if (grp && !strcmp(grp->grp.name, name))
 			break;
 	}
 
@@ -79,9 +79,9 @@ static int imx_dt_node_to_map(struct pinctrl_dev *pctldev,
 	}
 
 	if (info->flags & IMX_USE_SCU) {
-		map_num += grp->num_pins;
+		map_num += grp->grp.npins;
 	} else {
-		for (i = 0; i < grp->num_pins; i++) {
+		for (i = 0; i < grp->grp.npins; i++) {
 			pin = &((struct imx_pin *)(grp->data))[i];
 			if (!(pin->conf.mmio.config & IMX_NO_PAD_CTL))
 				map_num++;
@@ -109,7 +109,7 @@ static int imx_dt_node_to_map(struct pinctrl_dev *pctldev,
 
 	/* create config map */
 	new_map++;
-	for (i = j = 0; i < grp->num_pins; i++) {
+	for (i = j = 0; i < grp->grp.npins; i++) {
 		pin = &((struct imx_pin *)(grp->data))[i];
 
 		/*
@@ -263,10 +263,10 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev, unsigned selector,
 	if (!func)
 		return -EINVAL;
 
-	npins = grp->num_pins;
+	npins = grp->grp.npins;
 
 	dev_dbg(ipctl->dev, "enable function %s group %s\n",
-		func->name, grp->name);
+		func->name, grp->grp.name);
 
 	for (i = 0; i < npins; i++) {
 		/*
@@ -423,7 +423,7 @@ static void imx_pinconf_group_dbg_show(struct pinctrl_dev *pctldev,
 	if (!grp)
 		return;
 
-	for (i = 0; i < grp->num_pins; i++) {
+	for (i = 0; i < grp->grp.npins; i++) {
 		struct imx_pin *pin = &((struct imx_pin *)(grp->data))[i];
 
 		name = pin_get_name(pctldev, pin->pin);
@@ -526,7 +526,7 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
 		pin_size = FSL_PIN_SIZE;
 
 	/* Initialise group */
-	grp->name = np->name;
+	grp->grp.name = np->name;
 
 	/*
 	 * the binding format is fsl,pins = <PIN_FUNC_ID CONFIG ...>,
@@ -554,19 +554,17 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
 		return -EINVAL;
 	}
 
-	grp->num_pins = size / pin_size;
-	grp->data = devm_kcalloc(ipctl->dev,
-				 grp->num_pins, sizeof(struct imx_pin),
-				 GFP_KERNEL);
+	grp->grp.npins = size / pin_size;
+	grp->data = devm_kcalloc(ipctl->dev, grp->grp.npins, sizeof(*pin), GFP_KERNEL);
 	if (!grp->data)
 		return -ENOMEM;
 
-	pins = devm_kcalloc(ipctl->dev, grp->num_pins, sizeof(*pins), GFP_KERNEL);
+	pins = devm_kcalloc(ipctl->dev, grp->grp.npins, sizeof(*pins), GFP_KERNEL);
 	if (!pins)
 		return -ENOMEM;
-	grp->pins = pins;
+	grp->grp.pins = pins;
 
-	for (i = 0; i < grp->num_pins; i++) {
+	for (i = 0; i < grp->grp.npins; i++) {
 		pin = &((struct imx_pin *)(grp->data))[i];
 		if (info->flags & IMX_USE_SCU)
 			info->imx_pinctrl_parse_pin(ipctl, &pins[i], pin, &list);
@@ -613,8 +611,7 @@ static int imx_pinctrl_parse_functions(struct device_node *np,
 
 	i = 0;
 	for_each_child_of_node(np, child) {
-		grp = devm_kzalloc(ipctl->dev, sizeof(struct group_desc),
-				   GFP_KERNEL);
+		grp = devm_kzalloc(ipctl->dev, sizeof(*grp), GFP_KERNEL);
 		if (!grp) {
 			of_node_put(child);
 			return -ENOMEM;
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:58:01 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:58:01 +0200
Subject: [PATCH v5 08/13] pinctrl: ingenic: Convert to use grp member
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-9-andriy.shevchenko@linux.intel.com>

Convert drivers to use grp member embedded in struct group_desc,
because other members will be removed to avoid duplication and
desynchronisation of the generic pin group description.

Acked-by: Paul Cercueil <paul at crapouillou.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/pinctrl-ingenic.c | 26 +++++++++++---------------
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-ingenic.c b/drivers/pinctrl/pinctrl-ingenic.c
index f5661dcdedf5..bc6358a686fc 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -84,17 +84,13 @@
 
 #define INGENIC_PIN_GROUP_FUNCS(_name_, id, funcs)					\
 	{										\
-		.name = _name_,								\
-		.pins = id##_pins,							\
-		.num_pins = ARRAY_SIZE(id##_pins),					\
+		.grp = PINCTRL_PINGROUP(_name_, id##_pins, ARRAY_SIZE(id##_pins)),	\
 		.data = funcs,								\
 	}
 
 #define INGENIC_PIN_GROUP(_name_, id, func)						\
 	{										\
-		.name = _name_,								\
-		.pins = id##_pins,							\
-		.num_pins = ARRAY_SIZE(id##_pins),					\
+		.grp = PINCTRL_PINGROUP(_name_, id##_pins, ARRAY_SIZE(id##_pins)),	\
 		.data = (void *)func,							\
 	}
 
@@ -3766,17 +3762,17 @@ static int ingenic_pinmux_set_mux(struct pinctrl_dev *pctldev,
 		return -EINVAL;
 
 	dev_dbg(pctldev->dev, "enable function %s group %s\n",
-		func->name, grp->name);
+		func->name, grp->grp.name);
 
 	mode = (uintptr_t)grp->data;
 	if (mode <= 3) {
-		for (i = 0; i < grp->num_pins; i++)
-			ingenic_pinmux_set_pin_fn(jzpc, grp->pins[i], mode);
+		for (i = 0; i < grp->grp.npins; i++)
+			ingenic_pinmux_set_pin_fn(jzpc, grp->grp.pins[i], mode);
 	} else {
 		pin_modes = grp->data;
 
-		for (i = 0; i < grp->num_pins; i++)
-			ingenic_pinmux_set_pin_fn(jzpc, grp->pins[i], pin_modes[i]);
+		for (i = 0; i < grp->grp.npins; i++)
+			ingenic_pinmux_set_pin_fn(jzpc, grp->grp.pins[i], pin_modes[i]);
 	}
 
 	return 0;
@@ -4303,12 +4299,12 @@ static int __init ingenic_pinctrl_probe(struct platform_device *pdev)
 
 	for (i = 0; i < chip_info->num_groups; i++) {
 		const struct group_desc *group = &chip_info->groups[i];
+		const struct pingroup *grp = &group->grp;
 
-		err = pinctrl_generic_add_group(jzpc->pctl, group->name,
-				group->pins, group->num_pins, group->data);
+		err = pinctrl_generic_add_group(jzpc->pctl, grp->name, grp->pins, grp->npins,
+						group->data);
 		if (err < 0) {
-			dev_err(dev, "Failed to register group %s\n",
-					group->name);
+			dev_err(dev, "Failed to register group %s\n", grp->name);
 			return err;
 		}
 	}
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:57:59 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:57:59 +0200
Subject: [PATCH v5 06/13] pinctrl: equilibrium: Convert to use grp member
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-7-andriy.shevchenko@linux.intel.com>

Convert drivers to use grp member embedded in struct group_desc,
because other members will be removed to avoid duplication and
desynchronisation of the generic pin group description.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/pinctrl-equilibrium.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-equilibrium.c b/drivers/pinctrl/pinctrl-equilibrium.c
index 4ebae516d1b1..6e1be38865c3 100644
--- a/drivers/pinctrl/pinctrl-equilibrium.c
+++ b/drivers/pinctrl/pinctrl-equilibrium.c
@@ -331,8 +331,8 @@ static int eqbr_pinmux_set_mux(struct pinctrl_dev *pctldev,
 		return -EINVAL;
 
 	pinmux = grp->data;
-	for (i = 0; i < grp->num_pins; i++)
-		eqbr_set_pin_mux(pctl, pinmux[i], grp->pins[i]);
+	for (i = 0; i < grp->grp.npins; i++)
+		eqbr_set_pin_mux(pctl, pinmux[i], grp->grp.pins[i]);
 
 	return 0;
 }
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:58:02 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:58:02 +0200
Subject: [PATCH v5 09/13] pinctrl: keembay: Convert to use grp member
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-10-andriy.shevchenko@linux.intel.com>

Convert drivers to use grp member embedded in struct group_desc,
because other members will be removed to avoid duplication and
desynchronisation of the generic pin group description.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/pinctrl-keembay.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-keembay.c b/drivers/pinctrl/pinctrl-keembay.c
index 87d328853ae4..b1349ee22799 100644
--- a/drivers/pinctrl/pinctrl-keembay.c
+++ b/drivers/pinctrl/pinctrl-keembay.c
@@ -945,7 +945,7 @@ static int keembay_set_mux(struct pinctrl_dev *pctldev, unsigned int fun_sel,
 		return -EINVAL;
 
 	/* Change modes for pins in the selected group */
-	pin = *grp->pins;
+	pin = *grp->grp.pins;
 	pin_mode = *(u8 *)(func->data);
 
 	val = keembay_read_reg(kpc->base1 + KEEMBAY_GPIO_MODE, pin);
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:57:58 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:57:58 +0200
Subject: [PATCH v5 05/13] pinctrl: bcm: Convert to use grp member
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-6-andriy.shevchenko@linux.intel.com>

Convert drivers to use grp member embedded in struct group_desc,
because other members will be removed to avoid duplication and
desynchronisation of the generic pin group description.

Tested-by: Florian Fainelli <florian.fainelli at broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/bcm/pinctrl-ns.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-ns.c b/drivers/pinctrl/bcm/pinctrl-ns.c
index d099a7f25f64..6bb2b461950b 100644
--- a/drivers/pinctrl/bcm/pinctrl-ns.c
+++ b/drivers/pinctrl/bcm/pinctrl-ns.c
@@ -171,8 +171,8 @@ static int ns_pinctrl_set_mux(struct pinctrl_dev *pctrl_dev,
 	if (!group)
 		return -EINVAL;
 
-	for (i = 0; i < group->num_pins; i++)
-		unset |= BIT(group->pins[i]);
+	for (i = 0; i < group->grp.npins; i++)
+		unset |= BIT(group->grp.pins[i]);
 
 	tmp = readl(ns_pinctrl->base);
 	tmp &= ~unset;
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:58:05 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:58:05 +0200
Subject: [PATCH v5 12/13] pinctrl: starfive: Convert to use grp member
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-13-andriy.shevchenko@linux.intel.com>

Convert drivers to use grp member embedded in struct group_desc,
because other members will be removed to avoid duplication and
desynchronisation of the generic pin group description.

Reviewed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c | 8 ++++----
 drivers/pinctrl/starfive/pinctrl-starfive-jh7110.c | 8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c b/drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c
index b29b0ab9892b..6df7a310c7ed 100644
--- a/drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c
+++ b/drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c
@@ -654,7 +654,7 @@ static int starfive_set_mux(struct pinctrl_dev *pctldev,
 		return -EINVAL;
 
 	pinmux = group->data;
-	for (i = 0; i < group->num_pins; i++) {
+	for (i = 0; i < group->grp.npins; i++) {
 		u32 v = pinmux[i];
 		unsigned int gpio = starfive_pinmux_to_gpio(v);
 		u32 dout = starfive_pinmux_to_dout(v);
@@ -797,7 +797,7 @@ static int starfive_pinconf_group_get(struct pinctrl_dev *pctldev,
 	if (!group)
 		return -EINVAL;
 
-	return starfive_pinconf_get(pctldev, group->pins[0], config);
+	return starfive_pinconf_get(pctldev, group->grp.pins[0], config);
 }
 
 static int starfive_pinconf_group_set(struct pinctrl_dev *pctldev,
@@ -876,8 +876,8 @@ static int starfive_pinconf_group_set(struct pinctrl_dev *pctldev,
 		}
 	}
 
-	for (i = 0; i < group->num_pins; i++)
-		starfive_padctl_rmw(sfp, group->pins[i], mask, value);
+	for (i = 0; i < group->grp.npins; i++)
+		starfive_padctl_rmw(sfp, group->grp.pins[i], mask, value);
 
 	return 0;
 }
diff --git a/drivers/pinctrl/starfive/pinctrl-starfive-jh7110.c b/drivers/pinctrl/starfive/pinctrl-starfive-jh7110.c
index 6de11a405734..9609eb1ecc3d 100644
--- a/drivers/pinctrl/starfive/pinctrl-starfive-jh7110.c
+++ b/drivers/pinctrl/starfive/pinctrl-starfive-jh7110.c
@@ -307,7 +307,7 @@ static int jh7110_set_mux(struct pinctrl_dev *pctldev,
 		return -EINVAL;
 
 	pinmux = group->data;
-	for (i = 0; i < group->num_pins; i++) {
+	for (i = 0; i < group->grp.npins; i++) {
 		u32 v = pinmux[i];
 
 		if (info->jh7110_set_one_pin_mux)
@@ -437,7 +437,7 @@ static int jh7110_pinconf_group_get(struct pinctrl_dev *pctldev,
 	if (!group)
 		return -EINVAL;
 
-	return jh7110_pinconf_get(pctldev, group->pins[0], config);
+	return jh7110_pinconf_get(pctldev, group->grp.pins[0], config);
 }
 
 static int jh7110_pinconf_group_set(struct pinctrl_dev *pctldev,
@@ -508,8 +508,8 @@ static int jh7110_pinconf_group_set(struct pinctrl_dev *pctldev,
 		}
 	}
 
-	for (i = 0; i < group->num_pins; i++)
-		jh7110_padcfg_rmw(sfp, group->pins[i], mask, value);
+	for (i = 0; i < group->grp.npins; i++)
+		jh7110_padcfg_rmw(sfp, group->grp.pins[i], mask, value);
 
 	return 0;
 }
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:58:03 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:58:03 +0200
Subject: [PATCH v5 10/13] pinctrl: mediatek: Convert to use grp member
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-11-andriy.shevchenko@linux.intel.com>

Convert drivers to use grp member embedded in struct group_desc,
because other members will be removed to avoid duplication and
desynchronisation of the generic pin group description.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/mediatek/pinctrl-moore.c | 13 ++++++-------
 drivers/pinctrl/mediatek/pinctrl-moore.h |  4 +---
 drivers/pinctrl/mediatek/pinctrl-paris.h |  4 +---
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.c b/drivers/pinctrl/mediatek/pinctrl-moore.c
index c3d59eddd994..d972584c0519 100644
--- a/drivers/pinctrl/mediatek/pinctrl-moore.c
+++ b/drivers/pinctrl/mediatek/pinctrl-moore.c
@@ -56,12 +56,12 @@ static int mtk_pinmux_set_mux(struct pinctrl_dev *pctldev,
 		return -EINVAL;
 
 	dev_dbg(pctldev->dev, "enable function %s group %s\n",
-		func->name, grp->name);
+		func->name, grp->grp.name);
 
-	for (i = 0; i < grp->num_pins; i++) {
+	for (i = 0; i < grp->grp.npins; i++) {
 		const struct mtk_pin_desc *desc;
 		int *pin_modes = grp->data;
-		int pin = grp->pins[i];
+		int pin = grp->grp.pins[i];
 
 		desc = (const struct mtk_pin_desc *)&hw->soc->pins[pin];
 		if (!desc->name)
@@ -602,13 +602,12 @@ static int mtk_build_groups(struct mtk_pinctrl *hw)
 
 	for (i = 0; i < hw->soc->ngrps; i++) {
 		const struct group_desc *group = hw->soc->grps + i;
+		const struct pingroup *grp = &group->grp;
 
-		err = pinctrl_generic_add_group(hw->pctrl, group->name,
-						group->pins, group->num_pins,
+		err = pinctrl_generic_add_group(hw->pctrl, grp->name, grp->pins, grp->npins,
 						group->data);
 		if (err < 0) {
-			dev_err(hw->dev, "Failed to register group %s\n",
-				group->name);
+			dev_err(hw->dev, "Failed to register group %s\n", grp->name);
 			return err;
 		}
 	}
diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.h b/drivers/pinctrl/mediatek/pinctrl-moore.h
index 36ee0021cf7e..e0313e7a1fe0 100644
--- a/drivers/pinctrl/mediatek/pinctrl-moore.h
+++ b/drivers/pinctrl/mediatek/pinctrl-moore.h
@@ -39,9 +39,7 @@
 
 #define PINCTRL_PIN_GROUP(_name_, id)							\
 	{										\
-		.name = _name_,								\
-		.pins = id##_pins,							\
-		.num_pins = ARRAY_SIZE(id##_pins),					\
+		.grp = PINCTRL_PINGROUP(_name_, id##_pins, ARRAY_SIZE(id##_pins)),	\
 		.data = id##_funcs,							\
 	}
 
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.h b/drivers/pinctrl/mediatek/pinctrl-paris.h
index 5c4e5b74e43e..948ce126aa0c 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.h
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.h
@@ -51,9 +51,7 @@
 
 #define PINCTRL_PIN_GROUP(_name_, id)							\
 	{										\
-		.name = _name_,								\
-		.pins = id##_pins,							\
-		.num_pins = ARRAY_SIZE(id##_pins),					\
+		.grp = PINCTRL_PINGROUP(_name_,id##_pins, ARRAY_SIZE(id##_pins)),	\
 		.data = id##_funcs,							\
 	}
 
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:58:06 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:58:06 +0200
Subject: [PATCH v5 13/13] pinctrl: core: Remove unused members from struct group_desc
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-14-andriy.shevchenko@linux.intel.com>

All drivers are converted to use embedded struct pingroup.
Remove unused members from struct group_desc.

Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/core.c | 9 ---------
 drivers/pinctrl/core.h | 9 ---------
 2 files changed, 18 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 48cc5571dea6..ee56856cb80c 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -557,9 +557,6 @@ const char *pinctrl_generic_get_group_name(struct pinctrl_dev *pctldev,
 	if (!group)
 		return NULL;
 
-	if (group->name)
-		return group->name;
-
 	return group->grp.name;
 }
 EXPORT_SYMBOL_GPL(pinctrl_generic_get_group_name);
@@ -586,12 +583,6 @@ int pinctrl_generic_get_group_pins(struct pinctrl_dev *pctldev,
 		return -EINVAL;
 	}
 
-	if (group->pins) {
-		*pins = group->pins;
-		*num_pins = group->num_pins;
-		return 0;
-	}
-
 	*pins = group->grp.pins;
 	*num_pins = group->grp.npins;
 
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index a3b75ec7b54b..837fd5bd903d 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -199,16 +199,10 @@ struct pinctrl_maps {
 /**
  * struct group_desc - generic pin group descriptor
  * @grp: generic data of the pin group (name and pins)
- * @name: name of the pin group
- * @pins: array of pins that belong to the group
- * @num_pins: number of pins in the group
  * @data: pin controller driver specific data
  */
 struct group_desc {
 	struct pingroup grp;
-	const char *name;
-	const unsigned int *pins;
-	int num_pins;
 	void *data;
 };
 
@@ -216,9 +210,6 @@ struct group_desc {
 #define PINCTRL_GROUP_DESC(_name, _pins, _num_pins, _data)	\
 (struct group_desc) {						\
 	.grp = PINCTRL_PINGROUP(_name, _pins, _num_pins),	\
-	.name = _name,						\
-	.pins = _pins,						\
-	.num_pins = _num_pins,					\
 	.data = _data,						\
 }
 
-- 
2.43.0.rc1.1.gbec44491f096



From andriy.shevchenko at linux.intel.com  Mon Dec 11 10:58:04 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 11 Dec 2023 20:58:04 +0200
Subject: [PATCH v5 11/13] pinctrl: renesas: Convert to use grp member
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20231211190321.307330-12-andriy.shevchenko@linux.intel.com>

Convert drivers to use grp member embedded in struct group_desc,
because other members will be removed to avoid duplication and
desynchronisation of the generic pin group description.

Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/renesas/pinctrl-rza1.c  |  2 +-
 drivers/pinctrl/renesas/pinctrl-rza2.c  | 10 +++++-----
 drivers/pinctrl/renesas/pinctrl-rzg2l.c |  4 ++--
 drivers/pinctrl/renesas/pinctrl-rzv2m.c |  4 ++--
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/renesas/pinctrl-rza1.c b/drivers/pinctrl/renesas/pinctrl-rza1.c
index ab334de89b69..b03f22c54ca8 100644
--- a/drivers/pinctrl/renesas/pinctrl-rza1.c
+++ b/drivers/pinctrl/renesas/pinctrl-rza1.c
@@ -1131,7 +1131,7 @@ static int rza1_set_mux(struct pinctrl_dev *pctldev, unsigned int selector,
 		return -EINVAL;
 
 	mux_confs = (struct rza1_mux_conf *)func->data;
-	for (i = 0; i < grp->num_pins; ++i) {
+	for (i = 0; i < grp->grp.npins; ++i) {
 		int ret;
 
 		ret = rza1_pin_mux_single(rza1_pctl, &mux_confs[i]);
diff --git a/drivers/pinctrl/renesas/pinctrl-rza2.c b/drivers/pinctrl/renesas/pinctrl-rza2.c
index 990b96d45967..af689d7c117f 100644
--- a/drivers/pinctrl/renesas/pinctrl-rza2.c
+++ b/drivers/pinctrl/renesas/pinctrl-rza2.c
@@ -447,15 +447,15 @@ static int rza2_set_mux(struct pinctrl_dev *pctldev, unsigned int selector,
 
 	psel_val = func->data;
 
-	for (i = 0; i < grp->num_pins; ++i) {
+	for (i = 0; i < grp->grp.npins; ++i) {
 		dev_dbg(priv->dev, "Setting P%c_%d to PSEL=%d\n",
-			port_names[RZA2_PIN_ID_TO_PORT(grp->pins[i])],
-			RZA2_PIN_ID_TO_PIN(grp->pins[i]),
+			port_names[RZA2_PIN_ID_TO_PORT(grp->grp.pins[i])],
+			RZA2_PIN_ID_TO_PIN(grp->grp.pins[i]),
 			psel_val[i]);
 		rza2_set_pin_function(
 			priv->base,
-			RZA2_PIN_ID_TO_PORT(grp->pins[i]),
-			RZA2_PIN_ID_TO_PIN(grp->pins[i]),
+			RZA2_PIN_ID_TO_PORT(grp->grp.pins[i]),
+			RZA2_PIN_ID_TO_PIN(grp->grp.pins[i]),
 			psel_val[i]);
 	}
 
diff --git a/drivers/pinctrl/renesas/pinctrl-rzg2l.c b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
index 68fcc2a4efbc..f01aa51b00c4 100644
--- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
+++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
@@ -283,9 +283,9 @@ static int rzg2l_pinctrl_set_mux(struct pinctrl_dev *pctldev,
 		return -EINVAL;
 
 	psel_val = func->data;
-	pins = group->pins;
+	pins = group->grp.pins;
 
-	for (i = 0; i < group->num_pins; i++) {
+	for (i = 0; i < group->grp.npins; i++) {
 		unsigned int *pin_data = pctrl->desc.pins[pins[i]].drv_data;
 		u32 off = RZG2L_PIN_CFG_TO_PORT_OFFSET(*pin_data);
 		u32 pin = RZG2L_PIN_ID_TO_PIN(pins[i]);
diff --git a/drivers/pinctrl/renesas/pinctrl-rzv2m.c b/drivers/pinctrl/renesas/pinctrl-rzv2m.c
index eb304fab1796..0767a5ac23e0 100644
--- a/drivers/pinctrl/renesas/pinctrl-rzv2m.c
+++ b/drivers/pinctrl/renesas/pinctrl-rzv2m.c
@@ -175,9 +175,9 @@ static int rzv2m_pinctrl_set_mux(struct pinctrl_dev *pctldev,
 		return -EINVAL;
 
 	psel_val = func->data;
-	pins = group->pins;
+	pins = group->grp.pins;
 
-	for (i = 0; i < group->num_pins; i++) {
+	for (i = 0; i < group->grp.npins; i++) {
 		dev_dbg(pctrl->dev, "port:%u pin: %u PSEL:%u\n",
 			RZV2M_PIN_ID_TO_PORT(pins[i]), RZV2M_PIN_ID_TO_PIN(pins[i]),
 			psel_val[i]);
-- 
2.43.0.rc1.1.gbec44491f096



From ajaygargnsit at gmail.com  Mon Dec 11 11:14:03 2023
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Tue, 12 Dec 2023 00:44:03 +0530
Subject: Query on a rare simultaneous processing of interrupts from GIC/NVIC
In-Reply-To: <CAHP4M8WQdQfjxa-oqGTEF-kfF3j8En6V5fi7gyNbGegwFqfpCQ@mail.gmail.com>
References: <CAHP4M8WQdQfjxa-oqGTEF-kfF3j8En6V5fi7gyNbGegwFqfpCQ@mail.gmail.com>
Message-ID: <CAHP4M8U8rUaFFRkQ2wYmT3JgKJ+g7h9nKLiqSYNdrBGLF1ckNw@mail.gmail.com>

Have had some discussion at the following link and following comments :
linux kernel - Query on a rare simultaneous processing of interrupts
from GIC/NVIC - Stack Overflow

Really wish to understand if interrupts can in fact be queued at the
software side, if the sequencing mentioned occurs.

On Mon, Dec 11, 2023 at 6:36?PM Ajay Garg <ajaygargnsit at gmail.com> wrote:
>
> Hi everyone.
>
> Let's say the following code is shared by multiple ISRs :
>
>    spin_lock_irqsave
>    <critical section>
>    spin_lock_irqrestore
>
>
>
> Also, following sequencing happens :
>
> *
> Low-priority interrupt comes in, and GIC/NVIC causes it jump to ISR.
>
> *
> Low-priority interrupt starts executing "spin_lock_irqsave".
>
> *
> Before preemption and interrupts could be disabled (by the executing
> low-priority interrupt). high-priority interrupt comes in.
> Since a higher priority interrupt has come in, the GIC/NVIC causes it
> to start executing the "spin_lock_irqsave" statement.
>
> *
> Through the low-priority interrupt executing, "spin_lock_irqsave" has completed.
> Preemption and interrupts are disabled, and low-priority interrupt
> grabs the spin lock.
>
> *
> High-priority interrupt spins on the spin-lock.
>
>
>
> Is the above sequencing possible?
>
> In other words, although the first interrupt did its best to disable
> all preemption and interrupts before it could enter the critical
> section, yet above sequencing *will* cause the high-priority interrupt
> to spin?
>
>
> Many thanks in advance for your time for help !
>
>
> Thanks and Regards,
> Ajay


From andrew at lunn.ch  Mon Dec 11 11:14:52 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 11 Dec 2023 20:14:52 +0100
Subject: [PATCH v8 1/3] MAINTAINERS: add ac5 to list of maintained
 Marvell dts files
In-Reply-To: <20231211171739.4090179-2-enachman@marvell.com>
References: <20231211171739.4090179-1-enachman@marvell.com>
 <20231211171739.4090179-2-enachman@marvell.com>
Message-ID: <2920ed0b-dda0-4a57-8097-52fd532d9f63@lunn.ch>

On Mon, Dec 11, 2023 at 07:17:37PM +0200, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> Add ac5 dts files to the list of maintained Marvell Armada dts files
> by defining the entry as covering the entire marvell arm64 directory
> 
> Signed-off-by: Elad Nachman <enachman at marvell.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From andrew at lunn.ch  Mon Dec 11 11:15:18 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 11 Dec 2023 20:15:18 +0100
Subject: [PATCH v8 2/3] dt-bindings: arm64: add Marvell COM Express boards
In-Reply-To: <20231211171739.4090179-3-enachman@marvell.com>
References: <20231211171739.4090179-1-enachman@marvell.com>
 <20231211171739.4090179-3-enachman@marvell.com>
Message-ID: <f28ea54c-84a5-4796-9ce9-19c147696c7f@lunn.ch>

On Mon, Dec 11, 2023 at 07:17:38PM +0200, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> Add dt bindings for:
> CN9130 COM Express CPU module
> CN9131 COM Express CPU module
> AC5X RD COM Express Type 7 carrier board.
> AC5X RD COM Express board with a CN9131 COM Express Type 7 CPU module.
> 
> Signed-off-by: Elad Nachman <enachman at marvell.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From andrew at lunn.ch  Mon Dec 11 11:16:20 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 11 Dec 2023 20:16:20 +0100
Subject: [PATCH v8 3/3] arm64: dts: cn913x: add device trees for COM
 Express boards
In-Reply-To: <20231211171739.4090179-4-enachman@marvell.com>
References: <20231211171739.4090179-1-enachman@marvell.com>
 <20231211171739.4090179-4-enachman@marvell.com>
Message-ID: <9f565a9c-18b1-4e83-905d-27b6585fa800@lunn.ch>

On Mon, Dec 11, 2023 at 07:17:39PM +0200, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> Add support for CN9130 and CN9131 COM Express Type 7 CPU
> module boards by Marvell.
> Define these COM Express CPU modules as dtsi and
> provide a dtsi file for a carrier board (Marvell AC5X RD
> COM Express type 7 carrier board).
> This Carrier board only utilizes the PCIe link, hence no
> special device / driver support is provided by this dtsi file.
> Finally, provide a dts file for the com express carrier and
> CPU module combination.
> 
> These COM Express boards differ from the existing CN913x DB
> boards by the type of ethernet connection (RGMII),
> the type of voltage regulators (not i2c expander based)
> and the USB phy (not UTMI based).
> Note - PHY + RGMII connector is OOB on CPU module.
> CN9131 COM Express board is basically CN9130 COM Express board
> with an additional CP115 I/O co-processor, which in this case
> provides an additional USB host controller on the board.
> 
> Signed-off-by: Elad Nachman <enachman at marvell.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From robin.murphy at arm.com  Mon Dec 11 11:27:28 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 11 Dec 2023 19:27:28 +0000
Subject: [PATCH] perf/arm-cmn: Fail DTC counter allocation correctly
Message-ID: <ed589c0d8e4130dc68b8ad1625226d28bdc185d4.1702322847.git.robin.murphy@arm.com>

Calling arm_cmn_event_clear() before all DTC indices are allocated is
wrong, and can lead to arm_cmn_event_add() erroneously clearing live
counters from full DTCs where allocation fails. Since the DTC counters
are only updated by arm_cmn_init_counter() after all DTC and DTM
allocations succeed, nothing actually needs cleaning up in this case
anyway, and it should just return directly as it did before.

Fixes: 7633ec2c262f ("perf/arm-cmn: Rework DTC counters (again)")
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/perf/arm-cmn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index 86d970e74129..c584165b13ba 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -1816,7 +1816,7 @@ static int arm_cmn_event_add(struct perf_event *event, int flags)
 			idx = 0;
 			while (cmn->dtc[j].counters[idx])
 				if (++idx == CMN_DT_NUM_COUNTERS)
-					goto free_dtms;
+					return -ENOSPC;
 		}
 		hw->dtc_idx[j] = idx;
 	}
-- 
2.39.2.101.g768bb238c484.dirty



From irogers at google.com  Mon Dec 11 11:31:02 2023
From: irogers at google.com (Ian Rogers)
Date: Mon, 11 Dec 2023 11:31:02 -0800
Subject: [PATCH v1 00/14] Clean up libperf cpumap's empty function
In-Reply-To: <20231129060211.1890454-1-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
Message-ID: <CAP-5=fV=zGDU3N093gFVosnmxLtO9n=hb4vfoZtPn3E3HfLvfw@mail.gmail.com>

On Tue, Nov 28, 2023 at 10:02?PM Ian Rogers <irogers at google.com> wrote:
>
> Rename and clean up the use of libperf CPU map functions particularly
> focussing on perf_cpu_map__empty that may return true for maps
> containing CPUs but also with an "any CPU"/dummy value.
>
> perf_cpu_map__nr is also troubling in that iterating an empty CPU map
> will yield the "any CPU"/dummy value. Reduce the appearance of some
> calls to this by using the perf_cpu_map__for_each_cpu macro.
>
> Ian Rogers (14):
>   libperf cpumap: Rename perf_cpu_map__dummy_new
>   libperf cpumap: Rename and prefer sysfs for perf_cpu_map__default_new
>   libperf cpumap: Rename perf_cpu_map__empty
>   libperf cpumap: Replace usage of perf_cpu_map__new(NULL)
>   libperf cpumap: Add for_each_cpu that skips the "any CPU" case
>   libperf cpumap: Add any, empty and min helpers
>   perf arm-spe/cs-etm: Directly iterate CPU maps
>   perf intel-pt/intel-bts: Switch perf_cpu_map__has_any_cpu_or_is_empty
>     use
>   perf cpumap: Clean up use of perf_cpu_map__has_any_cpu_or_is_empty
>   perf top: Avoid repeated function calls
>   perf arm64 header: Remove unnecessary CPU map get and put
>   perf stat: Remove duplicate cpus_map_matched function
>   perf cpumap: Use perf_cpu_map__for_each_cpu when possible
>   libperf cpumap: Document perf_cpu_map__nr's behavior

Ping. Thanks,
Ian

>  .../perf/Documentation/examples/sampling.c    |  2 +-
>  .../perf/Documentation/libperf-sampling.txt   |  2 +-
>  tools/lib/perf/Documentation/libperf.txt      |  4 +-
>  tools/lib/perf/cpumap.c                       | 92 +++++++++++++------
>  tools/lib/perf/evlist.c                       |  6 +-
>  tools/lib/perf/evsel.c                        |  2 +-
>  tools/lib/perf/include/perf/cpumap.h          | 56 ++++++++++-
>  tools/lib/perf/libperf.map                    | 10 +-
>  tools/lib/perf/tests/test-cpumap.c            |  4 +-
>  tools/lib/perf/tests/test-evlist.c            |  6 +-
>  tools/lib/perf/tests/test-evsel.c             |  2 +-
>  tools/perf/arch/arm/util/cs-etm.c             | 83 +++++++----------
>  tools/perf/arch/arm64/util/arm-spe.c          |  4 +-
>  tools/perf/arch/arm64/util/header.c           | 15 +--
>  tools/perf/arch/x86/util/intel-bts.c          |  4 +-
>  tools/perf/arch/x86/util/intel-pt.c           | 10 +-
>  tools/perf/bench/epoll-ctl.c                  |  2 +-
>  tools/perf/bench/epoll-wait.c                 |  2 +-
>  tools/perf/bench/futex-hash.c                 |  2 +-
>  tools/perf/bench/futex-lock-pi.c              |  2 +-
>  tools/perf/bench/futex-requeue.c              |  2 +-
>  tools/perf/bench/futex-wake-parallel.c        |  2 +-
>  tools/perf/bench/futex-wake.c                 |  2 +-
>  tools/perf/builtin-c2c.c                      |  6 +-
>  tools/perf/builtin-ftrace.c                   |  2 +-
>  tools/perf/builtin-record.c                   |  4 +-
>  tools/perf/builtin-stat.c                     | 31 +------
>  tools/perf/tests/bitmap.c                     | 13 +--
>  tools/perf/tests/code-reading.c               |  2 +-
>  tools/perf/tests/cpumap.c                     |  2 +-
>  tools/perf/tests/keep-tracking.c              |  2 +-
>  tools/perf/tests/mmap-basic.c                 |  2 +-
>  tools/perf/tests/openat-syscall-all-cpus.c    |  2 +-
>  tools/perf/tests/perf-time-to-tsc.c           |  2 +-
>  tools/perf/tests/sw-clock.c                   |  2 +-
>  tools/perf/tests/switch-tracking.c            |  2 +-
>  tools/perf/tests/task-exit.c                  |  2 +-
>  tools/perf/tests/topology.c                   | 48 +++++-----
>  tools/perf/util/auxtrace.c                    |  4 +-
>  tools/perf/util/bpf_counter.c                 |  2 +-
>  tools/perf/util/bpf_kwork.c                   | 16 ++--
>  tools/perf/util/bpf_kwork_top.c               | 12 +--
>  tools/perf/util/cpumap.c                      | 14 ++-
>  tools/perf/util/cputopo.c                     |  2 +-
>  tools/perf/util/evlist.c                      |  4 +-
>  tools/perf/util/evsel.c                       |  2 +-
>  tools/perf/util/perf_api_probe.c              |  4 +-
>  tools/perf/util/record.c                      |  4 +-
>  .../scripting-engines/trace-event-python.c    | 12 ++-
>  tools/perf/util/session.c                     |  5 +-
>  tools/perf/util/stat.c                        |  2 +-
>  tools/perf/util/svghelper.c                   | 20 ++--
>  tools/perf/util/top.c                         |  9 +-
>  53 files changed, 296 insertions(+), 254 deletions(-)
>
> --
> 2.43.0.rc1.413.gea7ed67945-goog
>


From peter.griffin at linaro.org  Mon Dec 11 11:46:06 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Mon, 11 Dec 2023 19:46:06 +0000
Subject: [PATCH v7 08/16] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <CAL_JsqJ_NUajmQs8ZYiE2GpvNxBwtkLRE2jvWDU3hKtztt92Ug@mail.gmail.com>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-9-peter.griffin@linaro.org> <CAL_JsqJ_NUajmQs8ZYiE2GpvNxBwtkLRE2jvWDU3hKtztt92Ug@mail.gmail.com>
Message-ID: <CADrjBPrkso2cM8zKq-WU8WC3P3A9YoS6nqX-f6XvSNS-EofK9g@mail.gmail.com>

Hi Rob,

Thanks for your review.

On Mon, 11 Dec 2023 at 16:43, Rob Herring <robh+dt at kernel.org> wrote:
>
> On Mon, Dec 11, 2023 at 10:24?AM Peter Griffin <peter.griffin at linaro.org> wrote:
> >
> > cmu_top is the top level clock management unit which contains PLLs, muxes,
> > dividers and gates that feed the other clock management units.
> >
> > cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> > APM module.
> >
> > Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> > Reviewed-by: Andr? Draszik <andre.draszik at linaro.org>
> > Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> > Tested-by: Will McVicker <willmcvicker at google.com>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> >  drivers/clk/samsung/Makefile    |    1 +
> >  drivers/clk/samsung/clk-gs101.c | 2512 +++++++++++++++++++++++++++++++
> >  2 files changed, 2513 insertions(+)
> >  create mode 100644 drivers/clk/samsung/clk-gs101.c
> >
> > diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> > index ebbeacabe88f..3056944a5a54 100644
> > --- a/drivers/clk/samsung/Makefile
> > +++ b/drivers/clk/samsung/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK) += clk-exynos7.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynos7885.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynos850.o
> >  obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-exynosautov9.o
> > +obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)  += clk-gs101.o
> >  obj-$(CONFIG_S3C64XX_COMMON_CLK)       += clk-s3c64xx.o
> >  obj-$(CONFIG_S5PV210_COMMON_CLK)       += clk-s5pv210.o clk-s5pv210-audss.o
> >  obj-$(CONFIG_TESLA_FSD_COMMON_CLK)     += clk-fsd.o
> > diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> > new file mode 100644
> > index 000000000000..05361fce3c6f
> > --- /dev/null
> > +++ b/drivers/clk/samsung/clk-gs101.c
> > @@ -0,0 +1,2512 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2023 Linaro Ltd.
> > + * Author: Peter Griffin <peter.griffin at linaro.org>
> > + *
> > + * Common Clock Framework support for GS101.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
>
> You probably don't need this header. Please check.
>
> > +#include <linux/platform_device.h>

You are correct, this header isn't required. If a new series is
required I will remove it.

Whilst you're here I'd like to draw your attention to [PATCH 2/16]
where I've removed your reviewed-by tag in v7 because I added the ect
node documentation in google.yaml. The empty ect node is required to
be present by the bootloader or the device will boot loop. Can you
re-review that patch?

The alternative is to remove the empty ect node, and the binding
documentation for it and add your Reviewed-by tag back again. But then
an upstream kernel won't boot 'out the box' on a pixel 6 which seems
less than ideal default behaviour.

regards,

Peter.


From ahalaney at redhat.com  Mon Dec 11 11:48:47 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Mon, 11 Dec 2023 13:48:47 -0600
Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <hpqssnt7odmuuyhsljuqovmwatdjz4s6kix6abq7lrvyciawy5@5ypscmmivnmh>
References: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>
 <jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz@ntepnnzzelta>
 <hxds75erxqcfkufxnfbyo2up4b4jeicmi3f5xr6qlb3yf7fe76@4byeq62jhu4o>
 <hgz3pt625kggix6kzincohw7kr2okcumrwfkmjgiauw2yvhrzt@ekeygo4b7k3b>
 <h5ucipgjtsesrz3jyul5xohu4pqom56v6ayx7aonnfesret3ht@wmblmndj6zir>
 <hpqssnt7odmuuyhsljuqovmwatdjz4s6kix6abq7lrvyciawy5@5ypscmmivnmh>
Message-ID: <slq3uvpe424lxksgc2ho4q5apon6yqyvmq3ubpmx3z5ln5yhqf@klnkglqb6o6r>

On Mon, Dec 11, 2023 at 08:27:46PM +0300, Serge Semin wrote:
> On Fri, Dec 08, 2023 at 10:50:29AM -0600, Andrew Halaney wrote:
> > On Fri, Dec 08, 2023 at 06:07:06PM +0300, Serge Semin wrote:
> > > On Thu, Dec 07, 2023 at 05:07:24PM -0600, Andrew Halaney wrote:
> > > > On Fri, Dec 08, 2023 at 01:16:12AM +0300, Serge Semin wrote:
> > > > > On Thu, Dec 07, 2023 at 03:12:40PM -0600, Andrew Halaney wrote:
> > > > > > The stmmac_dt_phy() function, which parses the devicetree node of the
> > > > > > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > > > > > fixed-link means in relation to the MAC's MDIO bus. This results in
> > > > > > a MDIO bus being created in situations it need not be.
> > > > > > 
> > > > > > Currently a MDIO bus is created if the description is either:
> > > > > > 
> > > > > >     1. Not fixed-link
> > > > > >     2. fixed-link but contains a MDIO bus as well
> > > > > > 
> > > > > > The "1" case above isn't always accurate. If there's a phy-handle,
> > > > > > it could be referencing a phy on another MDIO controller's bus[1]. In
> > > > > > this case currently the MAC will make a MDIO bus and scan it all
> > > > > > anyways unnecessarily.
> > > > > > 
> > > > > > There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> > > > > > be created and scanned for a phy. This case can also be inferred from
> > > > > > the platform description by not having a phy-handle && not being
> > > > > > fixed-link. This hits case "1" in the current driver's logic.
> > > > > > 
> > > > > > Let's improve the logic to create a MDIO bus if either:
> > > > > > 
> > > > > 
> > > > > >     - Devicetree contains a MDIO bus
> > > > > >     - !fixed-link && !phy-handle (legacy handling)
> > > > > 
> > > > > If what you suggest here is a free from regressions semantics change
> > > > > (really hope it is) I will be with both my hands for it. This will
> > > > > solve the problem we have with one of our device which doesn't have
> > > > > SMA interface (hardware designers decided to save ~4K gates of the
> > > > > chip area) but has a PHY externally attached to the DW XGMAC<->XPCS
> > > > > interface. PHY is accessible via a GPIO-based MDIO bus. BTW having no
> > > > > SMA interface available on a DW *MAC device but creating the MDIO-bus
> > > > > on top of the non-existent SMA CSRs anyway causes having _32_ dummy
> > > > > PHYs created with zero IDs.
> > > > 
> > > 
> > > > I hope it is regression free! I have tested both the [1] and [2] cases
> > > > (I hacked up the devicetree for [1] to make it look like [2]) without
> > > > any issue.
> > > > 
> > > 
> > > I doubt you could have tested it on all the possible hardware the
> > > STMMAC driver supports. The problem is that the DT-bindings thing is a
> > > kind of contract which can't be changed that easily. It's like ABI but
> > > for the hardware description so the kernel would bootup correctly on
> > > the platforms with the old DT blobs. But if the change isn't that
> > > critical, if the device-tree sources in the kernel fit to the updated
> > > semantics, if the networking subsystem maintainers aren't against it
> > > and I guess with the Rob, Krzysztof or Conor blessing (at least it
> > > won't hurt to add them to the Cc-list together with the devicetree
> > > mailing-list), then it will likely be accepted.
> > 
> 
> > To be clear, I don't think we're violating the dt-binding ABI contract
> > here. My intention is that all the existing use cases continue to work,
> > and this just improves one use case. I did a write up
> > over on v2 about the use cases I see and the current logic vs what
> > changes with this patch series:
> > 
> >     https://lore.kernel.org/netdev/plvbqgi2bwlv5quvpiwplq7cxx6m5rl3ghnfhuxfx4bpuhyihl at zmydwrtwdeg6/
> > 
> > Please comment if you think I have broken some backwards
> > compatibility.
> 
> To shortly sum up so I didn't miss something. Current semantics of the
> MDIO-bus registration is:
> if !fixed-link || mdio_node_present
>     create MDIO-bus
> and the semantics of the PHY auto-probe (legacy) is:
> if !(fixed-link || mdio_node_present || phy_node_present)
>     auto-probe PHY

I think phy_node_present doesn't belong in the current view of the
semantics for PHY auto-probe (legacy). This devicetree would trigger a
PHY auto-probe/scan on ethernet0's MAC's MDIO bus:

	random-mdio-bus {
		rgmii_phy: phy at 0 {
		};
	};

	ethernet0 {
		phy-handle = <&rgmii_phy>;
	};

The assumption I make in this patch is that nothing useful could be on
ethernet0's MDIO bus, it certainly at least is not the phy the MAC uses.

> 
> You are changing the MDIO-bus creation semantics to:
> if !(fixed-link || phy_node_present) || mdio_node_present
>     create MDIO-bus
> with no change in the PHY auto-probe semantics:
> if !(fixed-link || mdio_node_present || phy_node_present)
>     auto-probe PHY

Unfortunately as I highlighted above this logic (while accurate to the
patch under review) is a change from the prior logic for the "auto-probe
PHY" case.

> 
> So the change is that if a PHY-handle is specified the MDIO-bus won't
> be created with the rest conditions being the same.
> 
> The only concern I had was the so called legacy case and a possibility
> to have MDIO-bus with other than PHY devices. Based on the pseudo-code
> above the former case won't be affected since having PHY-node
> specified didn't triggered MDIO-bus auto-probe even before your
> change. The later case concerns for instance the DW XPCS devices which

As I've realized in your response here, there is the possibility that
something is on the MDIO bus in the ethernet0 exmpale bus above, and would
probe, in the before handling. So I guess this isn't totally backwards
compatible. Gah, thanks for highlighting.

I'm not sure in practice if anyone out there is really relying on that
or not. I can get away with the "no auto-probe/scan of bus" optimization I
really desire by describing my MDIO bus as disabled in the devicetree
(need to send patches to do that in the dts and handle it gracefully in
stmmac). I'm wondering if I should keep forth with this patch as is, or
if I should keep the same logic but clean it up a bit as is done in the
current patch... I guess probably the latter.

> on some platforms could be found on the DW MAC MDIO bus with not
> having PHY living on that bus. But DW XPCS auto-probing currently is
> only supported by the non-OF platforms (it's Intel). Thus your change
> is supposed to be safe here too.
> 
> So to speak AFAICS from the STMMAC MDIO OF stuff your solution isn't
> supposed to cause regressions and break the current DTs backward
> compatibility indeed.
> 
> Regarding the ideal implementation. What could be much better is to
> implement the next semantics:
> if SMA-capability-detected &&
>    (!mdio_node_present || (mdio_node_present && mdio_node_enabled))
>     create MDIO-bus
> and preserve the PHY auto-probe semantics for backwards compatibility.
> Regarding the SMA-capability flag, it has been presented since DW GMAC
> v3.50, so since very much early DW MAC releases. But even for the
> early devices I think it could be auto-detected by checking the SMA
> CSRs writability. At least DW XGMAC AFAICS has the command CSR not
> writable if SMA is unavailable.
> 
> But I guess it's a matter of another patch.
> 

I like that logic for what it is worth, although would be unsure of
verifying the SMA-capability-detected part of it. But I wouldn't mind
seeing that patch :)



From rafael at kernel.org  Mon Dec 11 11:52:37 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 11 Dec 2023 20:52:37 +0100
Subject: [PATCH v7 0/7] consolidate and cleanup CPU capacity
In-Reply-To: <20231211104855.558096-1-vincent.guittot@linaro.org>
References: <20231211104855.558096-1-vincent.guittot@linaro.org>
Message-ID: <CAJZ5v0i37gGqt=oGC4BxJ4hT5pxhAdL7dPxGf7w3D8THqwAOwQ@mail.gmail.com>

On Mon, Dec 11, 2023 at 11:49?AM Vincent Guittot
<vincent.guittot at linaro.org> wrote:
>
> This is the 1st part of consolidating how the max compute capacity is
> used in the scheduler and how we calculate the frequency for a level of
> utilization.
>
> Fix some unconsistancy when computing frequency for an utilization. There
> can be a mismatch between energy model and schedutil.
>
> Next step will be to make a difference between the original
> max compute capacity of a CPU and what is currently available when
> there is a capping applying forever (i.e. seconds or more).
>
> Changes since v6:
> - Rebase on tip/sched/core and fix a conflict
> - Add tags
>
> Changes since v5:
> - Remove useless return in freq_inv_set_max_ratio()
> - Add tags
>
> Changes since v4:
> - Capitalize the verb in subject
> - Remove usless parentheses in cppc_get_dmi_max_khz()
> - Use freq_ref pattern everywhere
> - Fix MHz / kHz units conversion for cppc_cpufreq
> - Move default definition of arch_scale_freq_ref() in
>   include/linux/sched/topology.h beside arch_scale_cpu_capacity
>   which faces similar default declaration behavior. This location covers
>   all cases with arch and CONFIG_* which was not the case with previous
>   attempts.
>
> Changes since v3:
> - Split patch 5 cpufreq/cppc
> - Fix topology_init_cpu_capacity_cppc()
> - Fix init if AMU ratio
> - Added some tags
>
> Changes since v2:
> - Remove the 1st patch which has been queued in tip
> - Rework how to initialize the reference frequency for cppc_cpufreq and
>   change topology_init_cpu_capacity_cppc() to also set capacity_ref_freq
> - Add a RFC to convert AMU to use arch_scale_freq_ref and move the config
>   of the AMU ratio to be done when intializing cpu capacity and
>   capacity_ref_freq
> - Added some tags
>
> Changes since v1:
> - Fix typos
> - Added changes in cpufreq to use arch_scale_freq_ref() when calling
>   arch_set_freq_scale (patch 3).
> - arch_scale_freq_ref() is always defined and returns 0 (as proposed
>   by Ionela) when not defined by the arch. This simplifies the code with
>   the addition of patch 3.
> - Simplify Energy Model which always uses arch_scale_freq_ref(). The
>   latter returns 0 when not defined by arch instead of last item of the
>   perf domain. This is not a problem because the function is only defined
>   for compilation purpose in this case and we don't care about the
>   returned value. (patch 5)
> - Added changes in cppc cpufreq to set capacity_ref_freq (patch 6)
> - Added reviewed tag for patch 1 which got a minor change but not for
>   others as I did some changes which could make previous reviewed tag
>   no more relevant.
>
> Vincent Guittot (7):
>   topology: Add a new arch_scale_freq_reference
>   cpufreq: Use the fixed and coherent frequency for scaling capacity
>   cpufreq/schedutil: Use a fixed reference frequency
>   energy_model: Use a fixed reference frequency
>   cpufreq/cppc: Move and rename cppc_cpufreq_{perf_to_khz|khz_to_perf}
>   cpufreq/cppc: Set the frequency used for computing the capacity
>   arm64/amu: Use capacity_ref_freq to set AMU ratio

This series touches multiple places, but mostly schedutil, cpufreq and
the EM, so please let me know if you want me to pick it up.


From andrew at lunn.ch  Mon Dec 11 12:03:36 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 11 Dec 2023 21:03:36 +0100
Subject: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
References: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
Message-ID: <d202770a-3a3a-4ee2-b0de-b86e2f3e83ce@lunn.ch>

On Mon, Dec 11, 2023 at 06:13:21AM +0000, Jianheng Zhang wrote:
> Adds the HW specific support for Frame Preemption handshaking on XGMAC3+
> cores.
> 
> Signed-off-by: Jianheng Zhang <Jianheng.Zhang at synopsys.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h     |  6 ++
>  .../net/ethernet/stmicro/stmmac/dwxgmac2_core.c    | 65 ++++++++++++++++++----
>  2 files changed, 60 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> index 207ff17..306d15b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> @@ -194,6 +194,12 @@
>  #define XGMAC_MDIO_DATA			0x00000204
>  #define XGMAC_MDIO_C22P			0x00000220
>  #define XGMAC_FPE_CTRL_STS		0x00000280
> +#define XGMAC_TRSP			BIT(19)
> +#define XGMAC_TVER			BIT(18)
> +#define XGMAC_RRSP			BIT(17)
> +#define XGMAC_RVER			BIT(16)
> +#define XGMAC_SRSP			BIT(2)
> +#define XGMAC_SVER			BIT(1)
>  #define XGMAC_EFPE			BIT(0)
>  #define XGMAC_ADDRx_HIGH(x)		(0x00000300 + (x) * 0x8)
>  #define XGMAC_ADDR_MAX			32
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> index eb48211..091d932 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> @@ -1439,22 +1439,63 @@ static void dwxgmac3_fpe_configure(void __iomem *ioaddr, struct stmmac_fpe_cfg *
>  {
>  	u32 value;
>  
> -	if (!enable) {
> -		value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
> +	if (enable) {
> +		cfg->fpe_csr = XGMAC_EFPE;
> +		value = readl(ioaddr + XGMAC_RXQ_CTRL1);
> +		value &= ~XGMAC_RQ;
> +		value |= (num_rxq - 1) << XGMAC_RQ_SHIFT;
> +		writel(value, ioaddr + XGMAC_RXQ_CTRL1);
> +	} else {
> +		cfg->fpe_csr = 0;
> +	}
> +	writel(cfg->fpe_csr, ioaddr + XGMAC_FPE_CTRL_STS);
> +}
>  
> -		value &= ~XGMAC_EFPE;
> +static int dwxgmac3_fpe_irq_status(void __iomem *ioaddr, struct net_device *dev)
> +{
> +	u32 value;
> +	int status;
>  
> -		writel(value, ioaddr + XGMAC_FPE_CTRL_STS);
> -		return;
> +	status = FPE_EVENT_UNKNOWN;
> +
> +	/* Reads from the XGMAC_FPE_CTRL_STS register should only be performed
> +	 * here, since the status flags of MAC_FPE_CTRL_STS are "clear on read"
> +	 */
> +	value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
> +
> +	if (value & XGMAC_TRSP) {
> +		status |= FPE_EVENT_TRSP;
> +		netdev_info(dev, "FPE: Respond mPacket is transmitted\n");

netdev_info()?  Is this going to spam the logs? Should it be netdev_dbg()

	Andrew


From lkp at intel.com  Mon Dec 11 12:16:42 2023
From: lkp at intel.com (kernel test robot)
Date: Tue, 12 Dec 2023 04:16:42 +0800
Subject: [PATCH net-next v3 5/8] net: qualcomm: ipqess: add bridge
 offloading features to the IPQESS driver
In-Reply-To: <20231114105600.1012056-6-romain.gantois@bootlin.com>
References: <20231114105600.1012056-6-romain.gantois@bootlin.com>
Message-ID: <202312120428.xmRLjyHQ-lkp@intel.com>

Hi Romain,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Romain-Gantois/dt-bindings-net-Introduce-the-Qualcomm-IPQESS-Ethernet-switch/20231114-185953
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231114105600.1012056-6-romain.gantois%40bootlin.com
patch subject: [PATCH net-next v3 5/8] net: qualcomm: ipqess: add bridge offloading features to the IPQESS driver
config: arc-randconfig-r112-20231116 (https://download.01.org/0day-ci/archive/20231212/202312120428.xmRLjyHQ-lkp at intel.com/config)
compiler: arc-elf-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231212/202312120428.xmRLjyHQ-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312120428.xmRLjyHQ-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/net/dsa/qca/qca8k-8xxx.c:1982:5: sparse: sparse: symbol 'qca8k_dsa_port_fdb_dump' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:1988:6: sparse: sparse: symbol 'qca8k_dsa_port_stp_state_set' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:1995:6: sparse: sparse: symbol 'qca8k_dsa_port_fast_age' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2000:5: sparse: sparse: symbol 'qca8k_dsa_set_ageing_time' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2005:5: sparse: sparse: symbol 'qca8k_dsa_port_vlan_filtering' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2012:5: sparse: sparse: symbol 'qca8k_dsa_vlan_add' was not declared. Should it be static?

vim +/qca8k_dsa_port_fdb_dump +1982 drivers/net/dsa/qca/qca8k-8xxx.c

  1981	
> 1982	int qca8k_dsa_port_fdb_dump(struct dsa_switch *ds, int port,
  1983				    dsa_fdb_dump_cb_t *cb, void *data)
  1984	{
  1985		return qca8k_port_fdb_dump(ds->priv, port, cb, data);
  1986	}
  1987	
> 1988	void qca8k_dsa_port_stp_state_set(struct dsa_switch *ds, int port,
  1989					  u8 state)
  1990	{
  1991		qca8k_port_stp_state_set(ds->priv, port, state,
  1992					 dsa_to_port(ds, port)->learning, true);
  1993	}
  1994	
> 1995	void qca8k_dsa_port_fast_age(struct dsa_switch *ds, int port)
  1996	{
  1997		qca8k_port_fast_age(ds->priv, port);
  1998	}
  1999	
> 2000	int qca8k_dsa_set_ageing_time(struct dsa_switch *ds, unsigned int msecs)
  2001	{
  2002		return qca8k_set_ageing_time(ds->priv, msecs);
  2003	}
  2004	
> 2005	int qca8k_dsa_port_vlan_filtering(struct dsa_switch *ds, int port,
  2006					  bool vlan_filtering,
  2007					  struct netlink_ext_ack *extack)
  2008	{
  2009		return qca8k_port_vlan_filtering(ds->priv, port, vlan_filtering);
  2010	}
  2011	
> 2012	int qca8k_dsa_vlan_add(struct dsa_switch *ds, int port,
  2013			       const struct switchdev_obj_port_vlan *vlan,
  2014			       struct netlink_ext_ack *extack)
  2015	{
  2016		return qca8k_port_vlan_add(ds->priv, port, vlan, extack);
  2017	}
  2018	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From will at kernel.org  Mon Dec 11 12:27:26 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 20:27:26 +0000
Subject: [PATCH v2 0/3] arm64 kpti fixes
In-Reply-To: <20231127120049.2258650-5-ardb@google.com>
References: <20231127120049.2258650-5-ardb@google.com>
Message-ID: <170229483940.39524.16557720852602395346.b4-ty@kernel.org>

On Mon, 27 Nov 2023 13:00:50 +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> 
> A couple of fixes and tweaks for KPTI - the first patch is a true
> regression in v6.7, the others are minor tweaks.
> 
> v2:
> - add two more tweaks
> - use correct method to test system cap before alternatives have been
>   applied
> - move check into kpti_install_ng_mappings()
> 
> [...]

Applied last two to arm64 (for-next/cpufeature), thanks!

[2/3] arm64: mm: Only map KPTI trampoline if it is going to be used
      https://git.kernel.org/arm64/c/8885c7398fe5
[3/3] arm64: Kconfig: drop KAISER reference from KPTI option description
      https://git.kernel.org/arm64/c/7540f70df98f

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Mon Dec 11 12:27:27 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 20:27:27 +0000
Subject: [PATCH v4 0/4] arm64: Run kernel mode NEON with preemption enabled
In-Reply-To: <20231208113218.3001940-6-ardb@google.com>
References: <20231208113218.3001940-6-ardb@google.com>
Message-ID: <170231871028.1857077.10318072500676133330.b4-ty@kernel.org>

Hey Ard,

On Fri, 8 Dec 2023 12:32:19 +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> 
> Currently, kernel mode NEON (SIMD) support is implemented in a way that
> requires preemption to be disabled while the SIMD registers are live.
> The reason for this is that those registers are not in the set that is
> preserved/restored on exception entry/exit and context switch, as this
> would impact performance generally, even for workloads where kernel mode
> SIMD is not the bottleneck.
> 
> [...]

I applied the first three patches to for-next/fpsimd:

[1/4] arm64: fpsimd: Drop unneeded 'busy' flag
      https://git.kernel.org/arm64/c/e109130b0e5e
[2/4] arm64: fpsimd: Preserve/restore kernel mode NEON at context switch
      https://git.kernel.org/arm64/c/1e3a3de1ff6c
[3/4] arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD
      https://git.kernel.org/arm64/c/035262623959

It would be nice to have an Ack from Herbert on the last one so that
he's aware of the possible conflicts.

The other thing I tangentially wondered about is what happens now if code
calls uaccess routines (e.g. get_user()) within a kernel_neon_{begin,end}
section? I think previously the fact that preemption had to be disabled
would've caused the might_fault() to explode, but now I suppose the BUG_ON()
in kernel_neon_begin() will save us. Is that right?

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Mon Dec 11 12:27:28 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 20:27:28 +0000
Subject: [PATCH 00/13] arm64/sysreg: System register updates from the 2023-09 XML release
In-Reply-To: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
Message-ID: <170232143745.1863680.1175789910135449342.b4-ty@kernel.org>

On Sat, 09 Dec 2023 01:02:46 +0000, broonie at kernel.org wrote:
> A number of serieses on the list have updates updates and additions to
> the system registers, and as a result of the work being done on KVM
> (especially nested virtualisation) there are overlaps and duplication of
> work between people unaware of other pending serieses.  This series
> collects together all the work that's been done on updating the system
> register definitions that don't have pending review issues which I'm
> aware of with the aim of at least making it easier to find things.
> 
> [...]

Applied to arm64 (for-next/sysregs), thanks!

[01/13] arm64/sysreg: Update HFGITR_EL2 definiton to DDI0601 2023-09
        https://git.kernel.org/arm64/c/256f442895ed
[02/13] arm64/sysreg: Add definition for HAFGRTR_EL2
        https://git.kernel.org/arm64/c/41bb68fbd016
[03/13] arm64/sysreg: add system register POR_EL{0,1}
        https://git.kernel.org/arm64/c/c0c5a8ea96b8
[04/13] arm64/sysreg: update CPACR_EL1 register
        https://git.kernel.org/arm64/c/35768b23d830
[05/13] arm64/sysreg: Add definition for ID_AA64PFR2_EL1
        https://git.kernel.org/arm64/c/9fb5dc53a117
[06/13] arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion for DDI0601 2023-09
        https://git.kernel.org/arm64/c/6e3dcfd13975
[07/13] arm64/sysreg: Add definition for ID_AA64ISAR3_EL1
        https://git.kernel.org/arm64/c/b5aefb668701
[08/13] arm64/sysreg: Add definition for ID_AA64FPFR0_EL1
        https://git.kernel.org/arm64/c/9e4f409b07df
[09/13] arm64/sysreg: Update ID_AA64SMFR0_EL1 definition for DDI0601 2023-09
        https://git.kernel.org/arm64/c/8afe582d7700
[10/13] arm64/sysreg: Update SCTLR_EL1 for DDI0601 2023-09
        https://git.kernel.org/arm64/c/a6052284a9f9
[11/13] arm64/sysreg: Update HCRX_EL2 definition for DDI0601 2023-09
        https://git.kernel.org/arm64/c/126cb3a60d35
[12/13] arm64/sysreg: Add definition for FPMR
        https://git.kernel.org/arm64/c/e3a649ecf8b9
[13/13] arm64/sysreg: Add new system registers for GCS
        https://git.kernel.org/arm64/c/e94e06d8a796

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Mon Dec 11 12:27:29 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 20:27:29 +0000
Subject: [PATCH] kselftest/arm64: Improve output for skipped TPIDR2 ABI test
In-Reply-To: <20231124-kselftest-arm64-tpidr2-skip-v1-1-e05d0ccef101@kernel.org>
References: <20231124-kselftest-arm64-tpidr2-skip-v1-1-e05d0ccef101@kernel.org>
Message-ID: <170229604354.42938.7367909798766410585.b4-ty@kernel.org>

On Fri, 24 Nov 2023 15:22:21 +0000, Mark Brown wrote:
> When TPIDR2 is not supported the tpidr2 ABI test prints the same message
> for each skipped test:
> 
>   ok 1 skipped, TPIDR2 not supported
> 
> which isn't ideal for test automation software since it tracks kselftest
> results based on the string used to describe the test. This is also not
> standard KTAP output, the expected format is:
> 
> [...]

Applied to arm64 (for-next/selftests), thanks!

[1/1] kselftest/arm64: Improve output for skipped TPIDR2 ABI test
      https://git.kernel.org/arm64/c/33c1a7785a41

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Mon Dec 11 12:27:30 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 20:27:30 +0000
Subject: [PATCH] kselftest/arm64: Log SVCR when the SME tests barf
In-Reply-To: <20231205-arm64-kselftest-log-svcr-v1-1-b77abd9ee7f3@kernel.org>
References: <20231205-arm64-kselftest-log-svcr-v1-1-b77abd9ee7f3@kernel.org>
Message-ID: <170229612040.43237.5946498917108951815.b4-ty@kernel.org>

On Tue, 05 Dec 2023 14:24:44 +0000, Mark Brown wrote:
> On failure we log the actual and expected value of the register we detect
> a mismatch in. For SME one obvious potential source of corruption would be
> if we had corrupted SVCR since changes in streaming mode will reset the
> register values, log the value to aid in understanding issues.
> 
> 

Applied to arm64 (for-next/selftests), thanks!

[1/1] kselftest/arm64: Log SVCR when the SME tests barf
      https://git.kernel.org/arm64/c/48f7ab21f731

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Mon Dec 11 12:27:31 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 20:27:31 +0000
Subject: [PATCH 0/2] arm64: stacktrace: add kunwind_stack_walk()
In-Reply-To: <20231124110511.2795958-1-mark.rutland@arm.com>
References: <20231124110511.2795958-1-mark.rutland@arm.com>
Message-ID: <170229497612.40028.9898330903180638130.b4-ty@kernel.org>

On Fri, 24 Nov 2023 11:05:09 +0000, Mark Rutland wrote:
> Currently arm64 uses the generic arch_stack_walk() interface for all
> stack walking code. This only passes a PC value and cookie to the unwind
> callback, whereas we'd like to pass some additional information in some
> cases. For example, the BPF exception unwinder wants the FP, for
> reliable stacktrace we'll want to perform additional checks on other
> portions of unwind state, and we'd like to expand the information
> printed by dump_backtrace() to include provenance and reliability
> information.
> 
> [...]

Applied to arm64 (for-next/stacktrace), thanks!

[1/2] arm64: stacktrace: factor out kernel unwind state
      https://git.kernel.org/arm64/c/1beef60e7d6b
[2/2] arm64: stacktrace: factor out kunwind_stack_walk()
      https://git.kernel.org/arm64/c/1aba06e7b2b4

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Mon Dec 11 12:27:32 2023
From: will at kernel.org (Will Deacon)
Date: Mon, 11 Dec 2023 20:27:32 +0000
Subject: [PATCH] arm64: Delete the zero_za macro
In-Reply-To: <20231205160140.1438-1-yuzenghui@huawei.com>
References: <20231205160140.1438-1-yuzenghui@huawei.com>
Message-ID: <170230068713.139476.766825737476261782.b4-ty@kernel.org>

On Wed, 6 Dec 2023 00:01:40 +0800, Zenghui Yu wrote:
> zero_za was introduced in commit ca8a4ebcff44 ("arm64/sme: Manually encode
> SME instructions") but doesn't appear to have any in kernel user. Drop it.
> 
> 

Applied to arm64 (for-next/misc), thanks!

[1/1] arm64: Delete the zero_za macro
      https://git.kernel.org/arm64/c/86d1921c9d5a

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From rafael at kernel.org  Mon Dec 11 12:44:07 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 11 Dec 2023 21:44:07 +0100
Subject: [PATCH] PM: domains: Drop the unused pm_genpd_opp_to_performance_state()
In-Reply-To: <20231127151931.47055-1-ulf.hansson@linaro.org>
References: <20231127151931.47055-1-ulf.hansson@linaro.org>
Message-ID: <CAJZ5v0jXRNDV7AhZPkrDvMtrk6cYeMJ+HuUs0kJ=kjbQ-YiyVA@mail.gmail.com>

On Mon, Nov 27, 2023 at 4:19?PM Ulf Hansson <ulf.hansson at linaro.org> wrote:
>
> Since commit 7c41cdcd3bbe ("OPP: Simplify the over-designed pstate <->
> level dance"), there is no longer any users of the
> pm_genpd_opp_to_performance_state() API. Let's therefore drop it and its
> corresponding ->opp_to_performance_state() callback, which also no longer
> has any users.
>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>

I can take this in principle, but I'm wondering if you'd prefer to
apply patches modifying domain.c yourself?  They are definitely
related to the pmdomain tree.

> ---
>  drivers/base/power/domain.c | 32 --------------------------------
>  include/linux/pm_domain.h   | 12 ------------
>  2 files changed, 44 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index da1777e39eaa..cf65b5a9783c 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -3042,38 +3042,6 @@ int of_genpd_parse_idle_states(struct device_node *dn,
>  }
>  EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
>
> -/**
> - * pm_genpd_opp_to_performance_state - Gets performance state of the genpd from its OPP node.
> - *
> - * @genpd_dev: Genpd's device for which the performance-state needs to be found.
> - * @opp: struct dev_pm_opp of the OPP for which we need to find performance
> - *     state.
> - *
> - * Returns performance state encoded in the OPP of the genpd. This calls
> - * platform specific genpd->opp_to_performance_state() callback to translate
> - * power domain OPP to performance state.
> - *
> - * Returns performance state on success and 0 on failure.
> - */
> -unsigned int pm_genpd_opp_to_performance_state(struct device *genpd_dev,
> -                                              struct dev_pm_opp *opp)
> -{
> -       struct generic_pm_domain *genpd = NULL;
> -       int state;
> -
> -       genpd = container_of(genpd_dev, struct generic_pm_domain, dev);
> -
> -       if (unlikely(!genpd->opp_to_performance_state))
> -               return 0;
> -
> -       genpd_lock(genpd);
> -       state = genpd->opp_to_performance_state(genpd, opp);
> -       genpd_unlock(genpd);
> -
> -       return state;
> -}
> -EXPORT_SYMBOL_GPL(pm_genpd_opp_to_performance_state);
> -
>  static int __init genpd_bus_init(void)
>  {
>         return bus_register(&genpd_bus_type);
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 34663d0d5c55..b97c5e9820f9 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -118,7 +118,6 @@ struct genpd_power_state {
>  };
>
>  struct genpd_lock_ops;
> -struct dev_pm_opp;
>  struct opp_table;
>
>  struct generic_pm_domain {
> @@ -146,8 +145,6 @@ struct generic_pm_domain {
>         int (*power_on)(struct generic_pm_domain *domain);
>         struct raw_notifier_head power_notifiers; /* Power on/off notifiers */
>         struct opp_table *opp_table;    /* OPP table of the genpd */
> -       unsigned int (*opp_to_performance_state)(struct generic_pm_domain *genpd,
> -                                                struct dev_pm_opp *opp);
>         int (*set_performance_state)(struct generic_pm_domain *genpd,
>                                      unsigned int state);
>         struct gpd_dev_ops dev_ops;
> @@ -348,8 +345,6 @@ int of_genpd_remove_subdomain(struct of_phandle_args *parent_spec,
>  struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
>  int of_genpd_parse_idle_states(struct device_node *dn,
>                                struct genpd_power_state **states, int *n);
> -unsigned int pm_genpd_opp_to_performance_state(struct device *genpd_dev,
> -                                              struct dev_pm_opp *opp);
>
>  int genpd_dev_pm_attach(struct device *dev);
>  struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> @@ -395,13 +390,6 @@ static inline int of_genpd_parse_idle_states(struct device_node *dn,
>         return -ENODEV;
>  }
>
> -static inline unsigned int
> -pm_genpd_opp_to_performance_state(struct device *genpd_dev,
> -                                 struct dev_pm_opp *opp)
> -{
> -       return 0;
> -}
> -
>  static inline int genpd_dev_pm_attach(struct device *dev)
>  {
>         return 0;
> --
> 2.34.1
>


From rafael at kernel.org  Mon Dec 11 12:52:31 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 11 Dec 2023 21:52:31 +0100
Subject: [PATCH] cpuidle: idle exit_latency overflow
In-Reply-To: <20231116132619.69500-1-bo.ye@mediatek.com>
References: <20231116132619.69500-1-bo.ye@mediatek.com>
Message-ID: <CAJZ5v0hP6VRKmBy9gSPkg82w+g7wwQBVGs6gHDW9BJnr-qrBnw@mail.gmail.com>

On Thu, Nov 16, 2023 at 2:26?PM Bo Ye <bo.ye at mediatek.com> wrote:
>
> From: mtk24676 <C.Cheng at mediatek.com>
>
> In detail:
> In kernel-6.1, in the __cpuidle_driver_init function in
> driver/cpuidle/driver.c, there is a line of code that causes
> an overflow. The line is s->exit_latency_ns = s->exit_latency
> * NSEC_PER_USEC. The overflow occurs because the product of an
> int type and a constant exceeds the range of the int type.

In general, but does it actually occur in that code?  IOW, is there
any system for which the exit latency of an idle state is so large
that it will trigger the overflow, for example?

> In C language, when you perform a multiplication operation, if
> both operands are of int type, the multiplication operation is
> performed on the int type, and then the result is converted to
> the target type.

Right, that's how C works.

> This means that if the product of int type
> multiplication exceeds the range that int type can represent,
> an overflow will occur even if you store the result in a
> variable of int64_t type.

True.  However, does this really happen in the particular case at hand?

If not, it would be better to say something like "For a multiplication
of two int values, it is better to use mul_u32_u32() that prevents
overflows from occurring."

> Signed-off-by: mtk24676 <C.Cheng at mediatek.com>
> Signed-off-by: bo.ye <bo.ye at mediatek.com>
> ---
>
> diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> index d9cda7f..631ca16 100644
> --- a/drivers/cpuidle/driver.c
> +++ b/drivers/cpuidle/driver.c
> @@ -187,7 +187,7 @@
>                         s->target_residency = div_u64(s->target_residency_ns, NSEC_PER_USEC);
>
>                 if (s->exit_latency > 0)
> -                       s->exit_latency_ns = s->exit_latency * NSEC_PER_USEC;
> +                       s->exit_latency_ns = (u64)s->exit_latency * NSEC_PER_USEC;

mul_u32_u32()/?

>                 else if (s->exit_latency_ns < 0)
>                         s->exit_latency_ns =  0;
>                 else


From linus.walleij at linaro.org  Mon Dec 11 13:02:21 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 11 Dec 2023 22:02:21 +0100
Subject: [PATCH v7 09/16] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <20231211162331.435900-10-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-10-peter.griffin@linaro.org>
Message-ID: <CACRpkda8LJS+9dPQFqQLFDbj=gvJ9rKSu=ECczDB4QUv+FZgnw@mail.gmail.com>

On Mon, Dec 11, 2023 at 5:24?PM Peter Griffin <peter.griffin at linaro.org> wrote:

> Add support for the pin-controller found on the gs101 SoC used in
> Pixel 6 phones.
>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Looks good to me.
Acked-by: Linus Walleij <linus.walleij at linaro.org>

I expect Krzysztof to merge this when he feels it is ready and
send to me by pull request.

Yours,
Linus Walleij


From ahalaney at redhat.com  Mon Dec 11 13:31:17 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Mon, 11 Dec 2023 15:31:17 -0600
Subject: [PATCH net] net: stmmac: Handle disabled MDIO busses from
 devicetree
Message-ID: <20231211-b4-stmmac-handle-mdio-enodev-v1-1-73c20c44f8d6@redhat.com>

Many hardware configurations have the MDIO bus disabled, and are instead
using some other MDIO bus to talk to the MAC's phy.

of_mdiobus_register() returns -ENODEV in this case. Let's handle it
gracefully instead of failing to probe the MAC.

Fixes: 47dd7a540b8a (net: add support for STMicroelectronics Ethernet controllers.")
Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index fa9e7e7040b9..a39be15d41a8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -591,7 +591,13 @@ int stmmac_mdio_register(struct net_device *ndev)
 	new_bus->parent = priv->device;
 
 	err = of_mdiobus_register(new_bus, mdio_node);
-	if (err != 0) {
+	if (err) {
+		if (err == -ENODEV) {
+			/* The bus is disabled in the devicetree, that's ok */
+			mdiobus_free(new_bus);
+			return 0;
+		}
+
 		dev_err_probe(dev, err, "Cannot register the MDIO bus\n");
 		goto bus_register_fail;
 	}

---
base-commit: bbd220ce4e29ed55ab079007cff0b550895258eb
change-id: 20231211-b4-stmmac-handle-mdio-enodev-82168de68c6a

Best regards,
-- 
Andrew Halaney <ahalaney at redhat.com>



From festevam at gmail.com  Mon Dec 11 13:40:54 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 11 Dec 2023 18:40:54 -0300
Subject: [PATCH] arm64: dts: imx8qxp-mek: Move port under USB connector
Message-ID: <20231211214054.570295-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per nxp,ptn5110.yaml, 'port' should be placed under 'connector'.

Do as requested to fix the following dt-schema warning:

imx8qxp-mek.dtb: tcpc at 50: connector:ports: 'port at 0' is a required property
	from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
imx8qxp-mek.dtb: tcpc at 50: connector: Unevaluated properties are not allowed ('ports' was unexpected)
	from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 6c3d8715bc11..096f9501fa32 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -152,12 +152,6 @@ ptn5110: tcpc at 50 {
 		interrupt-parent = <&lsio_gpio1>;
 		interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
 
-		port {
-			typec_dr_sw: endpoint {
-				remote-endpoint = <&usb3_drd_sw>;
-			};
-		};
-
 		usb_con1: connector {
 			compatible = "usb-c-connector";
 			label = "USB-C";
@@ -169,6 +163,13 @@ ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
 
+				port at 0 {
+					reg = <0>;
+					typec_dr_sw: endpoint {
+						remote-endpoint = <&usb3_drd_sw>;
+					};
+				};
+
 				port at 1 {
 					reg = <1>;
 					typec_con_ss: endpoint {
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:29 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:29 -0500
Subject: [PATCH v3 00/13] PCI: imx6: Clean up and add imx95 pci support
Message-ID: <20231211215842.134823-1-Frank.Li@nxp.com>

first 6 patches use drvdata: flags to simplify some switch-case code.
Improve maintaince and easy to read code.

Then add imx95 basic pci host function.

follow two patch do endpoint code clean up.
Then add imx95 basic endpont function.

Compared with v2, added EP function support and some fixes,  please change
notes at each patches.

Frank Li (12):
  PCI: imx6: Simplify clock handling by using HAS_CLK_* bitmask
  PCI: imx6: Simplify phy handling by using by using
    IMX6_PCIE_FLAG_HAS_PHY
  PCI: imx6: Simplify reset handling by using by using
    *_FLAG_HAS_*_RESET
  PCI: imx6: Using "linux,pci-domain" as slot ID
  PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
  PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
  PCI: imx6: Simplify switch-case logic by involve init_phy callback
  PCI: imx6: Add iMX95 PCIe support
  PCI: imx6: Clean up get addr_space code
  PCI: imx6: Add epc_features in imx6_pcie_drvdata
  dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
  PCI: imx6: Add iMX95 Endpoint (EP) function support

Richard Zhu (1):
  dt-bindings: imx6q-pcie: Add imx95 pcie compatible string

 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       |  20 +
 .../bindings/pci/fsl,imx6q-pcie.yaml          |  18 +
 drivers/pci/controller/dwc/pci-imx6.c         | 578 +++++++++++-------
 3 files changed, 393 insertions(+), 223 deletions(-)

-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:30 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:30 -0500
Subject: [PATCH v3 01/13] PCI: imx6: Simplify clock handling by using HAS_CLK_* bitmask
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-2-Frank.Li@nxp.com>

Refactors the clock handling logic in the imx6 PCI driver by adding
HAS_CLK_* bitmask define for drvdata::flags . Simplifies the code and makes
it more maintainable, as future additions of SOC support will only require
straightforward changes. The drvdata::flags and a bitmask ensures a cleaner
and more scalable switch-case structure for handling clocks.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 84 +++++++++++++--------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 74703362aeec7..8a9b527934f80 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -60,6 +60,10 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
+#define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
+#define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
+
+#define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
@@ -550,19 +554,23 @@ static int imx6_pcie_attach_pd(struct device *dev)
 
 static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	struct dw_pcie *pci = imx6_pcie->pci;
-	struct device *dev = pci->dev;
 	unsigned int offset;
 	int ret = 0;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
 		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_axi clock\n");
-			break;
-		}
+		if (ret)
+			return ret;
+	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
+		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
+		if (ret)
+			return ret;
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
 		break;
@@ -589,12 +597,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_aux clock\n");
-			break;
-		}
-
 		offset = imx6_pcie_grp_offset(imx6_pcie);
 		/*
 		 * Set the over ride low and enabled
@@ -614,10 +616,13 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI))
 		clk_disable_unprepare(imx6_pcie->pcie_inbound_axi);
-		break;
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX))
+		clk_disable_unprepare(imx6_pcie->pcie_aux);
+
+	switch (imx6_pcie->drvdata->variant) {
 	case IMX6QP:
 	case IMX6Q:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
@@ -631,14 +636,6 @@ static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		clk_disable_unprepare(imx6_pcie->pcie_aux);
-		break;
 	default:
 		break;
 	}
@@ -1316,21 +1313,21 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
 				     "pcie clock source missing or invalid\n");
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
-							   "pcie_inbound_axi");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
+		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev, "pcie_inbound_axi");
 		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
-					     "pcie_inbound_axi clock missing or invalid\n");
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
+			dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
+				      "pcie_inbound_axi clock missing or invalid\n");
+	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
 		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
 		if (IS_ERR(imx6_pcie->pcie_aux))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
 					     "pcie_aux clock source missing or invalid\n");
-		fallthrough;
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
 			imx6_pcie->controller_id = 1;
@@ -1353,10 +1350,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	case IMX8MM_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
 		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
 									 "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
@@ -1482,7 +1475,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.variant = IMX6SX,
 		.flags = IMX6_PCIE_FLAG_IMX6_PHY |
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
-			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 	},
 	[IMX6QP] = {
@@ -1500,30 +1494,36 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:31 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:31 -0500
Subject: [PATCH v3 02/13] PCI: imx6: Simplify phy handling by using by using IMX6_PCIE_FLAG_HAS_PHY
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-3-Frank.Li@nxp.com>

Refactors the phy handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_PHY bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling phy.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3:
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 8a9b527934f80..bcf52aa86462e 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -62,6 +62,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 #define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
 #define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
+#define IMX6_PCIE_FLAG_HAS_PHY			BIT(5)
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
@@ -1327,6 +1328,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "pcie_aux clock source missing or invalid\n");
 	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY)) {
+		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+		if (IS_ERR(imx6_pcie->phy))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
+					     "failed to get pcie phy\n");
+	}
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
@@ -1356,11 +1364,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
 
-		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
-		if (IS_ERR(imx6_pcie->phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
-					     "failed to get pcie phy\n");
-
 		break;
 	default:
 		break;
@@ -1500,24 +1503,28 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
+			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
-		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:32 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:32 -0500
Subject: [PATCH v3 03/13] PCI: imx6: Simplify reset handling by using by using *_FLAG_HAS_*_RESET
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-4-Frank.Li@nxp.com>

Refactors the reset handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling reset.

Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v2 to v3:
    - add Philipp's Reviewed-by tag
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.
    
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.

 drivers/pci/controller/dwc/pci-imx6.c | 111 ++++++++++----------------
 1 file changed, 42 insertions(+), 69 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index bcf52aa86462e..509d459bdc5a1 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -63,6 +63,8 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
 #define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(5)
+#define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(6)
+#define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(7)
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
@@ -696,18 +698,10 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 {
+	reset_control_assert(imx6_pcie->pciephy_reset);
+	reset_control_assert(imx6_pcie->apps_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_assert(imx6_pcie->pciephy_reset);
-		fallthrough;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
-		break;
 	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
@@ -728,6 +722,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
 		break;
+	default:
+		break;
 	}
 
 	/* Some boards don't have PCIe reset GPIO. */
@@ -741,14 +737,10 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
 
+	reset_control_deassert(imx6_pcie->pciephy_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-		break;
 	case IMX7D:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
 		 * Corrector" and other mysterious undocumented things.
@@ -780,11 +772,7 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 
 		usleep_range(200, 500);
 		break;
-	case IMX6Q:		/* Nothing to do */
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
+	default:
 		break;
 	}
 
@@ -831,16 +819,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2,
 				   IMX6Q_GPR12_PCIE_CTL_2);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_deassert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_deassert(imx6_pcie->apps_reset);
 }
 
 static void imx6_pcie_ltssm_disable(struct device *dev)
@@ -854,16 +837,11 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_assert(imx6_pcie->apps_reset);
 }
 
 static int imx6_pcie_start_link(struct dw_pcie *pci)
@@ -1335,36 +1313,24 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "failed to get pcie phy\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-
-		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
-									    "pciephy");
-		if (IS_ERR(imx6_pcie->pciephy_reset)) {
-			dev_err(dev, "Failed to get PCIEPHY reset control\n");
-			return PTR_ERR(imx6_pcie->pciephy_reset);
-		}
-
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
-		if (IS_ERR(imx6_pcie->apps_reset)) {
-			dev_err(dev, "Failed to get PCIE APPS reset control\n");
-			return PTR_ERR(imx6_pcie->apps_reset);
-		}
-		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET)) {
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev, "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
+	}
 
-		break;
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET)) {
+		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev, "pciephy");
+		if (IS_ERR(imx6_pcie->pciephy_reset))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pciephy_reset),
+					     "Failed to get PCIEPHY reset control\n");
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX7D:
+		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
+			imx6_pcie->controller_id = 1;
 	default:
 		break;
 	}
@@ -1492,32 +1458,39 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
-		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
 			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
 			 IMX6_PCIE_FLAG_HAS_CLK_AUX |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 	},
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:33 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:33 -0500
Subject: [PATCH v3 04/13] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-5-Frank.Li@nxp.com>

Avoid use get slot id by compared with register physical address. If there
are more than 2 slots, compared logic will become complex.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v2 to v3
    - none
    Change from v1 to v2
    - fix of_get_pci_domain_nr return value check logic

 drivers/pci/controller/dwc/pci-imx6.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 509d459bdc5a1..548034151ee1a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -33,6 +33,7 @@
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
+#include "../../pci.h"
 #include "pcie-designware.h"
 
 #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
@@ -1327,6 +1328,12 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "Failed to get PCIEPHY reset control\n");
 	}
 
+	/* Using linux,pci-domain as PCI slot id */
+	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
+	/* If there are not "linux,pci-domain" in dts file, means only 1 controller */
+	if (imx6_pcie->controller_id < 0)
+		imx6_pcie->controller_id = 0;
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:34 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:34 -0500
Subject: [PATCH v3 05/13] PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-6-Frank.Li@nxp.com>

Add drvdata::ltssm_off and drvdata::ltssm_mask to simple
imx6_pcie_ltssm_enable(disable)() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 37 ++++++++++++---------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 548034151ee1a..5bfb780e441fd 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,8 @@ struct imx6_pcie_drvdata {
 	u32 flags;
 	int dbi_length;
 	const char *gpr;
+	const u32 ltssm_off;
+	const u32 ltssm_mask;
 };
 
 struct imx6_pcie {
@@ -811,18 +813,11 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_ltssm_enable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2,
-				   IMX6Q_GPR12_PCIE_CTL_2);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off, drvdata->ltssm_mask,
+				   drvdata->ltssm_mask);
 
 	reset_control_deassert(imx6_pcie->apps_reset);
 }
@@ -830,17 +825,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 static void imx6_pcie_ltssm_disable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2, 0);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off,
+				   drvdata->ltssm_mask, 0);
 
 	reset_control_assert(imx6_pcie->apps_reset);
 }
@@ -1446,6 +1435,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1454,6 +1445,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
 			 IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1462,6 +1455,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:39 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:39 -0500
Subject: [PATCH v3 10/13] PCI: imx6: Clean up get addr_space code
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-11-Frank.Li@nxp.com>

The common dw_pcie_ep_init() already do the same thing. Needn't platform
driver do it again.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches

 drivers/pci/controller/dwc/pci-imx6.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 99022efe27334..eb4e954e3a167 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1116,7 +1116,6 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 	int ret;
 	unsigned int pcie_dbi2_offset;
 	struct dw_pcie_ep *ep;
-	struct resource *res;
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct dw_pcie_rp *pp = &pci->pp;
 	struct device *dev = pci->dev;
@@ -1135,14 +1134,8 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 		pcie_dbi2_offset = SZ_4K;
 		break;
 	}
-	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
-	if (!res)
-		return -EINVAL;
 
-	ep->phys_base = res->start;
-	ep->addr_size = resource_size(res);
-	ep->page_size = SZ_64K;
+	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:40 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:40 -0500
Subject: [PATCH v3 11/13] PCI: imx6: Add epc_features in imx6_pcie_drvdata
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-12-Frank.Li@nxp.com>

The i.MX EP exhibits variations in epc_features among different EP
configurations. This introduces the addition of epc_features in
imx6_pcie_drvdata to accommodate these differences. It's important to note
that there are no functional changes in this commit; instead, it lays the
groundwork for supporting i.MX95 EP functions.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patch at v3

 drivers/pci/controller/dwc/pci-imx6.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index eb4e954e3a167..8fe66d3e947a6 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -104,6 +104,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	const struct pci_epc_features *epc_features;
 	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
@@ -1101,7 +1102,10 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
-	return &imx8m_pcie_epc_features;
+	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pci);
+
+	return imx6_pcie->drvdata->epc_features;
 }
 
 static const struct dw_pcie_ep_ops pcie_ep_ops = {
@@ -1588,6 +1592,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
@@ -1598,6 +1603,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
@@ -1606,6 +1612,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:42 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:42 -0500
Subject: [PATCH v3 13/13] PCI: imx6: Add iMX95 Endpoint (EP) function support
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-14-Frank.Li@nxp.com>

Add iMX95 EP function support and add 64bit address support. Internal bus
bridge for PCI support 64bit dma address in iMX95. So set call
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)).

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches at v3

 drivers/pci/controller/dwc/pci-imx6.c | 44 +++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 8fe66d3e947a6..31df682432e24 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -76,6 +76,7 @@ enum imx6_pcie_variants {
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
+	IMX95_EP,
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
@@ -87,6 +88,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(6)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(7)
 #define IMX6_PCIE_FLAG_HAS_SERDES		BIT(8)
+#define IMX6_PCIE_FLAG_SUPPORT_64BIT		BIT(9)
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
@@ -630,6 +632,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 		break;
 	case IMX7D:
 	case IMX95:
+	case IMX95_EP:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -1099,6 +1102,23 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 	.align = SZ_64K,
 };
 
+/*
+ * BAR#	| Default BAR enable	| Default BAR Type	| Default BAR Size	| BAR Sizing Scheme
+ * ================================================================================================
+ * BAR0	| Enable		| 64-bit		| 1 MB			| Programmable Size
+ * BAR1	| Disable		| 32-bit		| 64 KB			| Fixed Size
+ *	| (BAR0 is 64-bit)	| if BAR0 is 32-bit	|			| As Bar0 is 64bit
+ * BAR2	| Enable		| 32-bit		| 1 MB			| Programmable Size
+ * BAR3	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ * BAR4	| Enable		| 32-bit		| 1M			| Programmable Size
+ * BAR5	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ */
+static const struct pci_epc_features imx95_pcie_epc_features = {
+	.msi_capable = false,
+	.bar_fixed_size[1] = SZ_64K,
+	.align = SZ_64K,
+};
+
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
@@ -1141,6 +1161,14 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 
 	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
+	/*
+	 * db2 information should fetch from dtb file. dw_pcie_ep_init() can get dbi_base2 from
+	 * "dbi2" if pci->dbi_base2 is NULL. All code related pcie_dbi2_offset should be removed
+	 * after all dts added "dbi2" reg.
+	 */
+	if (imx6_pcie->drvdata->variant == IMX95_EP)
+		pci->dbi_base2 = NULL;
+
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
 		dev_err(dev, "failed to initialize endpoint\n");
@@ -1417,6 +1445,9 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "unable to find iomuxc registers\n");
 	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_SUPPORT_64BIT))
+		dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+
 	/* Grab PCIe PHY Tx Settings */
 	if (of_property_read_u32(node, "fsl,tx-deemph-gen1",
 				 &imx6_pcie->tx_deemph_gen1))
@@ -1614,6 +1645,18 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.epc_features = &imx8m_pcie_epc_features,
 	},
+	[IMX95_EP] = {
+		.variant = IMX95_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX | IMX6_PCIE_FLAG_HAS_SERDES |
+			 IMX6_PCIE_FLAG_SUPPORT_64BIT,
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+		.epc_features = &imx95_pcie_epc_features,
+		.mode = DW_PCIE_EP_TYPE,
+	},
 };
 
 static const struct of_device_id imx6_pcie_of_match[] = {
@@ -1628,6 +1671,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
+	{ .compatible = "fsl,imx95-pcie-ep", .data = &drvdata[IMX95_EP], },
 	{},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:35 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:35 -0500
Subject: [PATCH v3 06/13] PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-7-Frank.Li@nxp.com>

Add drvdata::mode_off and drvdata::mode_mask to simple
imx6_pcie_configure_type() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v2 to v3
    - none
    Change from v1 to v2
    - use ffs() to fixe build error.

 drivers/pci/controller/dwc/pci-imx6.c | 60 ++++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 5bfb780e441fd..1fac6129eeb5f 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -69,6 +69,7 @@ enum imx6_pcie_variants {
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
+#define IMX6_PCIE_MAX_INSTANCES			2
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -77,6 +78,8 @@ struct imx6_pcie_drvdata {
 	const char *gpr;
 	const u32 ltssm_off;
 	const u32 ltssm_mask;
+	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
+	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
 };
 
 struct imx6_pcie {
@@ -177,32 +180,25 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
-	unsigned int mask, val, mode;
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
+	unsigned int mask, val, mode, id;
 
-	if (imx6_pcie->drvdata->mode == DW_PCIE_EP_TYPE)
+	if (drvdata->mode == DW_PCIE_EP_TYPE)
 		mode = PCI_EXP_TYPE_ENDPOINT;
 	else
 		mode = PCI_EXP_TYPE_ROOT_PORT;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		if (imx6_pcie->controller_id == 1) {
-			mask = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
-					  mode);
-		} else {
-			mask = IMX6Q_GPR12_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		}
-		break;
-	default:
-		mask = IMX6Q_GPR12_DEVICE_TYPE;
-		val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		break;
-	}
+	id = imx6_pcie->controller_id;
+
+	/* If mode_mask[id] is zero, means each controller have its individual gpr */
+	if (!drvdata->mode_mask[id])
+		id = 0;
+
+	mask = drvdata->mode_mask[id];
+	/* FIELD_PREP mask have been constant */
+	val = mode << (ffs(mask) - 1);
 
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, mask, val);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->mode_off[id], mask, val);
 }
 
 static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
@@ -1437,6 +1433,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1447,6 +1445,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1457,6 +1457,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1464,6 +1466,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET |
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1471,6 +1475,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET |
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1479,6 +1487,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY |
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
@@ -1487,6 +1497,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY |
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
@@ -1495,6 +1507,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
@@ -1502,12 +1518,16 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:36 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:36 -0500
Subject: [PATCH v3 07/13] PCI: imx6: Simplify switch-case logic by involve init_phy callback
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-8-Frank.Li@nxp.com>

Add drvdata::init_phy() callback function, so difference SOC choose
difference callback function to simple switch-case logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 135 ++++++++++++++------------
 1 file changed, 71 insertions(+), 64 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 1fac6129eeb5f..4e55b629d4efb 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -70,6 +70,9 @@ enum imx6_pcie_variants {
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
 #define IMX6_PCIE_MAX_INSTANCES			2
+
+struct imx6_pcie;
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -80,6 +83,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
 struct imx6_pcie {
@@ -326,76 +330,69 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
 	return 0;
 }
 
-static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+static int imx8mq_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		/*
-		 * The PHY initialization had been done in the PHY
-		 * driver, break here directly.
-		 */
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		/*
-		 * TODO: Currently this code assumes external
-		 * oscillator is being used
-		 */
+	/*
+	 * TODO: Currently this code assumes external
+	 * oscillator is being used
+	 */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   imx6_pcie_grp_offset(imx6_pcie),
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD,
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD);
+	/*
+	 * Regarding the datasheet, the PCIE_VPH is suggested
+	 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
+	 * VREG_BYPASS should be cleared to zero.
+	 */
+	if (imx6_pcie->vph && regulator_get_voltage(imx6_pcie->vph) > 3000000)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr,
 				   imx6_pcie_grp_offset(imx6_pcie),
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD,
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD);
-		/*
-		 * Regarding the datasheet, the PCIE_VPH is suggested
-		 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
-		 * VREG_BYPASS should be cleared to zero.
-		 */
-		if (imx6_pcie->vph &&
-		    regulator_get_voltage(imx6_pcie->vph) > 3000000)
-			regmap_update_bits(imx6_pcie->iomuxc_gpr,
-					   imx6_pcie_grp_offset(imx6_pcie),
-					   IMX8MQ_GPR_PCIE_VREG_BYPASS,
-					   0);
-		break;
-	case IMX7D:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX8MQ_GPR_PCIE_VREG_BYPASS,
+				   0);
+
+	return 0;
+}
+
+static int imx7d_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	return	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
-		break;
-	case IMX6SX:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6SX_GPR12_PCIE_RX_EQ_MASK,
-				   IMX6SX_GPR12_PCIE_RX_EQ_2);
-		fallthrough;
-	default:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+}
+
+static int imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 
-		/* configure constant input signal to the pcie ctrl and phy */
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
-
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN1,
-				   imx6_pcie->tx_deemph_gen1 << 0);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
-				   imx6_pcie->tx_deemph_gen2_3p5db << 6);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
-				   imx6_pcie->tx_deemph_gen2_6db << 12);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_FULL,
-				   imx6_pcie->tx_swing_full << 18);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_LOW,
-				   imx6_pcie->tx_swing_low << 25);
-		break;
-	}
+	/* configure constant input signal to the pcie ctrl and phy */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN1,
+			   imx6_pcie->tx_deemph_gen1 << 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
+			   imx6_pcie->tx_deemph_gen2_3p5db << 6);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
+			   imx6_pcie->tx_deemph_gen2_6db << 12);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_FULL,
+			   imx6_pcie->tx_swing_full << 18);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_LOW,
+			   imx6_pcie->tx_swing_low << 25);
+	return 0;
+}
 
-	imx6_pcie_configure_type(imx6_pcie);
+static int imx6sx_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6SX_GPR12_PCIE_RX_EQ_MASK, IMX6SX_GPR12_PCIE_RX_EQ_2);
+
+	return imx6_pcie_init_phy(imx6_pcie);
 }
 
 static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
@@ -939,7 +936,11 @@ static int imx6_pcie_host_init(struct dw_pcie_rp *pp)
 	}
 
 	imx6_pcie_assert_core_reset(imx6_pcie);
-	imx6_pcie_init_phy(imx6_pcie);
+
+	if (imx6_pcie->drvdata->init_phy)
+		imx6_pcie->drvdata->init_phy(imx6_pcie);
+
+	imx6_pcie_configure_type(imx6_pcie);
 
 	ret = imx6_pcie_clk_enable(imx6_pcie);
 	if (ret) {
@@ -1435,6 +1436,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1447,6 +1449,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6sx_pcie_init_phy,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1459,6 +1462,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1468,6 +1472,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx7d_pcie_init_phy,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1479,6 +1484,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1511,6 +1517,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:37 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:37 -0500
Subject: [PATCH v3 08/13] dt-bindings: imx6q-pcie: Add imx95 pcie compatible string
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-9-Frank.Li@nxp.com>

From: Richard Zhu <hongxing.zhu at nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
Add "atu" and "serdes" to reg-names.

Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
---

Notes:
    Change from v2 to v3
    - Remove krzy's ACK tag
    - Add condition check for imx95, which required more reg-names then old
    platform, so need Krzy review again,
    
    Change from v1 to v2
    - add Krzy's ACK tag

 .../bindings/pci/fsl,imx6q-pcie.yaml           | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 81bbb8728f0f9..b8fcf8258f031 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -29,6 +29,7 @@ properties:
       - fsl,imx8mq-pcie
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
+      - fsl,imx95-pcie
 
   reg:
     items:
@@ -90,6 +91,22 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie
+    then:
+      properties:
+        reg:
+          minItems: 4
+        reg-names:
+          items:
+            - const: dbi
+            - const: serdes
+            - const: atu
+            - const: config
+
   - if:
       properties:
         compatible:
@@ -111,6 +128,7 @@ allOf:
         compatible:
           enum:
             - fsl,imx8mq-pcie
+            - fsl,imx95-pcie
     then:
       properties:
         clocks:
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:38 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:38 -0500
Subject: [PATCH v3 09/13] PCI: imx6: Add iMX95 PCIe support
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-10-Frank.Li@nxp.com>

Add iMX95 PCIe basic root complex function support.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 89 +++++++++++++++++++++++++--
 1 file changed, 84 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 4e55b629d4efb..99022efe27334 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -43,6 +43,25 @@
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
 #define IMX8MQ_PCIE2_BASE_ADDR			0x33c00000
 
+#define IMX95_PCIE_PHY_GEN_CTRL			0x0
+#define IMX95_PCIE_REF_USE_PAD			BIT(17)
+
+#define IMX95_PCIE_PHY_MPLLA_CTRL		0x10
+#define IMX95_PCIE_PHY_MPLL_STATE		BIT(30)
+
+#define IMX95_PCIE_SS_RW_REG_0			0xf0
+#define IMX95_PCIE_REF_CLKEN			BIT(23)
+#define IMX95_PCIE_PHY_CR_PARA_SEL		BIT(9)
+
+#define IMX95_PE0_GEN_CTRL_1			0x1050
+#define IMX95_PCIE_DEVICE_TYPE			GENMASK(3, 0)
+
+#define IMX95_PE0_GEN_CTRL_3			0x1058
+#define IMX95_PCIE_LTSSM_EN			BIT(0)
+
+#define IMX95_PE0_PM_STS			0x1064
+#define IMX95_PCIE_PM_LINKST_IN_L2		BIT(14)
+
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -53,6 +72,7 @@ enum imx6_pcie_variants {
 	IMX8MQ,
 	IMX8MM,
 	IMX8MP,
+	IMX95,
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
@@ -66,6 +86,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(5)
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(6)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(7)
+#define IMX6_PCIE_FLAG_HAS_SERDES		BIT(8)
 
 #define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
 
@@ -182,6 +203,24 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
+static int imx95_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			IMX95_PCIE_SS_RW_REG_0,
+			IMX95_PCIE_PHY_CR_PARA_SEL,
+			IMX95_PCIE_PHY_CR_PARA_SEL);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_PHY_GEN_CTRL,
+			   IMX95_PCIE_REF_USE_PAD, 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_SS_RW_REG_0,
+			   IMX95_PCIE_REF_CLKEN,
+			   IMX95_PCIE_REF_CLKEN);
+
+	return 0;
+}
+
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
 	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
@@ -589,6 +628,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
 		break;
 	case IMX7D:
+	case IMX95:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -732,10 +772,19 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 {
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
+	u32 val;
 
 	reset_control_deassert(imx6_pcie->pciephy_reset);
 
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX95:
+		/* Polling the MPLL_STATE */
+		if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+					IMX95_PCIE_PHY_MPLLA_CTRL, val,
+					val & IMX95_PCIE_PHY_MPLL_STATE,
+					10, 10000))
+			dev_err(dev, "PCIe PLL lock timeout\n");
+		break;
 	case IMX7D:
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
@@ -1343,12 +1392,32 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(imx6_pcie->turnoff_reset);
 	}
 
+	if (imx6_pcie->drvdata->gpr) {
 	/* Grab GPR config register range */
-	imx6_pcie->iomuxc_gpr =
-		 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
-	if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
-		dev_err(dev, "unable to find iomuxc registers\n");
-		return PTR_ERR(imx6_pcie->iomuxc_gpr);
+		imx6_pcie->iomuxc_gpr =
+			 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
+	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_SERDES)) {
+		void __iomem *off = devm_platform_ioremap_resource_byname(pdev, "serdes");
+
+		if (IS_ERR(off))
+			return dev_err_probe(dev, PTR_ERR(off),
+					     "unable to find serdes registers\n");
+
+		static struct regmap_config regmap_config = {
+			.reg_bits = 32,
+			.val_bits = 32,
+			.reg_stride = 4,
+		};
+
+		imx6_pcie->iomuxc_gpr = devm_regmap_init_mmio(dev, off, &regmap_config);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
 	}
 
 	/* Grab PCIe PHY Tx Settings */
@@ -1506,6 +1575,15 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
+	[IMX95] = {
+		.variant = IMX95,
+		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX | IMX6_PCIE_FLAG_HAS_SERDES,
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX |
@@ -1546,6 +1624,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
 	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{ .compatible = "fsl,imx8mp-pcie", .data = &drvdata[IMX8MP], },
+	{ .compatible = "fsl,imx95-pcie", .data = &drvdata[IMX95], },
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
-- 
2.34.1



From Frank.Li at nxp.com  Mon Dec 11 13:58:41 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 16:58:41 -0500
Subject: [PATCH v3 12/13] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
In-Reply-To: <20231211215842.134823-1-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
Message-ID: <20231211215842.134823-13-Frank.Li@nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
Add reg-name: "atu", "dbi2", "dma" and "serdes".

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches at v3

 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
index ee155ed5f1811..36d8f117fdfb3 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
@@ -22,6 +22,7 @@ properties:
       - fsl,imx8mm-pcie-ep
       - fsl,imx8mq-pcie-ep
       - fsl,imx8mp-pcie-ep
+      - fsl,imx95-pcie-ep
 
   reg:
     minItems: 2
@@ -62,11 +63,30 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie-ep
+    then:
+      properties:
+        reg:
+          minItems: 6
+        reg-names:
+          items:
+            - const: dbi
+            - const: atu
+            - const: dbi2
+            - const: serdes
+            - const: dma
+            - const: addr_space
+
   - if:
       properties:
         compatible:
           enum:
             - fsl,imx8mq-pcie-ep
+            - fsl,imx95-pcie-ep
     then:
       properties:
         clocks:
-- 
2.34.1



From Frank.li at nxp.com  Mon Dec 11 14:06:42 2023
From: Frank.li at nxp.com (Frank Li)
Date: Mon, 11 Dec 2023 17:06:42 -0500
Subject: [PATCH v6 4/4] PCI: layerscape: Add suspend/resume for ls1043a
In-Reply-To: <20231204160829.2498703-5-Frank.Li@nxp.com>
References: <20231204160829.2498703-1-Frank.Li@nxp.com>
 <20231204160829.2498703-5-Frank.Li@nxp.com>
Message-ID: <ZXeH8nF4KoC0gKg2@lizhi-Precision-Tower-5810>

On Mon, Dec 04, 2023 at 11:08:29AM -0500, Frank Li wrote:
> Add suspend/resume support for Layerscape LS1043a.
> 
> In the suspend path, PME_Turn_Off message is sent to the endpoint to
> transition the link to L2/L3_Ready state. In this SoC, there is no way to
> check if the controller has received the PME_To_Ack from the endpoint or
> not. So to be on the safer side, the driver just waits for
> PCIE_PME_TO_L2_TIMEOUT_US before asserting the SoC specific PMXMTTURNOFF
> bit to complete the PME_Turn_Off handshake. Then the link would enter L2/L3
> state depending on the VAUX supply.
> 
> In the resume path, the link is brought back from L2 to L0 by doing a
> software reset.
> 
> Acked-by: Roy Zang <Roy.Zang at nxp.com>
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
> Signed-off-by: Frank Li <Frank.Li at nxp.com>

@Lorenzo:

   Could you please pick up these patches? Mani already reviewed and only
impact layerscape platform.

Frank

> ---
> 
> Notes:
>     Chagne from v5 to v6
>     - none
>     Change from v4 to v5
>     - update commit message
>     - use comments
>     /* Reset the PEX wrapper to bring the link out of L2 */
>     
>     Change from v3 to v4
>     - Call scfg_pcie_send_turnoff_msg() shared with ls1021a
>     - update commit message
>     
>     Change from v2 to v3
>     - Remove ls_pcie_lut_readl(writel) function
>     
>     Change from v1 to v2
>     - Update subject 'a' to 'A'
> 
>  drivers/pci/controller/dwc/pci-layerscape.c | 63 ++++++++++++++++++++-
>  1 file changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> index f3dfb70066fb7..7cdada200de7e 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -41,6 +41,15 @@
>  #define SCFG_PEXSFTRSTCR	0x190
>  #define PEXSR(idx)		BIT(idx)
>  
> +/* LS1043A PEX PME control register */
> +#define SCFG_PEXPMECR		0x144
> +#define PEXPME(idx)		BIT(31 - (idx) * 4)
> +
> +/* LS1043A PEX LUT debug register */
> +#define LS_PCIE_LDBG	0x7fc
> +#define LDBG_SR		BIT(30)
> +#define LDBG_WE		BIT(31)
> +
>  #define PCIE_IATU_NUM		6
>  
>  struct ls_pcie_drvdata {
> @@ -224,6 +233,45 @@ static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
>  	return scfg_pcie_exit_from_l2(pcie->scfg, SCFG_PEXSFTRSTCR, PEXSR(pcie->index));
>  }
>  
> +static void ls1043a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct ls_pcie *pcie = to_ls_pcie(pci);
> +
> +	scfg_pcie_send_turnoff_msg(pcie->scfg, SCFG_PEXPMECR, PEXPME(pcie->index));
> +}
> +
> +static int ls1043a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct ls_pcie *pcie = to_ls_pcie(pci);
> +	u32 val;
> +
> +	/*
> +	 * Reset the PEX wrapper to bring the link out of L2.
> +	 * LDBG_WE: allows the user to have write access to the PEXDBG[SR] for both setting and
> +	 *	    clearing the soft reset on the PEX module.
> +	 * LDBG_SR: When SR is set to 1, the PEX module enters soft reset.
> +	 */
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
> +	val |= LDBG_WE;
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
> +
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
> +	val |= LDBG_SR;
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
> +
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
> +	val &= ~LDBG_SR;
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
> +
> +	val = ls_pcie_pf_lut_readl(pcie, LS_PCIE_LDBG);
> +	val &= ~LDBG_WE;
> +	ls_pcie_pf_lut_writel(pcie, LS_PCIE_LDBG, val);
> +
> +	return 0;
> +}
> +
>  static const struct dw_pcie_host_ops ls_pcie_host_ops = {
>  	.host_init = ls_pcie_host_init,
>  	.pme_turn_off = ls_pcie_send_turnoff_msg,
> @@ -241,6 +289,19 @@ static const struct ls_pcie_drvdata ls1021a_drvdata = {
>  	.exit_from_l2 = ls1021a_pcie_exit_from_l2,
>  };
>  
> +static const struct dw_pcie_host_ops ls1043a_pcie_host_ops = {
> +	.host_init = ls_pcie_host_init,
> +	.pme_turn_off = ls1043a_pcie_send_turnoff_msg,
> +};
> +
> +static const struct ls_pcie_drvdata ls1043a_drvdata = {
> +	.pf_lut_off = 0x10000,
> +	.pm_support = true,
> +	.scfg_support = true,
> +	.ops = &ls1043a_pcie_host_ops,
> +	.exit_from_l2 = ls1043a_pcie_exit_from_l2,
> +};
> +
>  static const struct ls_pcie_drvdata layerscape_drvdata = {
>  	.pf_lut_off = 0xc0000,
>  	.pm_support = true,
> @@ -252,7 +313,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
>  	{ .compatible = "fsl,ls1012a-pcie", .data = &layerscape_drvdata },
>  	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021a_drvdata },
>  	{ .compatible = "fsl,ls1028a-pcie", .data = &layerscape_drvdata },
> -	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1021a_drvdata },
> +	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043a_drvdata },
>  	{ .compatible = "fsl,ls1046a-pcie", .data = &layerscape_drvdata },
>  	{ .compatible = "fsl,ls2080a-pcie", .data = &layerscape_drvdata },
>  	{ .compatible = "fsl,ls2085a-pcie", .data = &layerscape_drvdata },
> -- 
> 2.34.1
> 


From quic_johmoo at quicinc.com  Mon Dec 11 14:30:17 2023
From: quic_johmoo at quicinc.com (John Moon)
Date: Mon, 11 Dec 2023 14:30:17 -0800
Subject: [PATCH v6 1/3] check-uapi: Introduce check-uapi.sh
In-Reply-To: <CAK7LNATWk8psXZvsHXNwxNt9=sUi3J0qOA-P4ceOKqBuS1_VJQ@mail.gmail.com>
References: <20231027193016.27516-1-quic_johmoo@quicinc.com>
 <20231027193016.27516-2-quic_johmoo@quicinc.com>
 <CAK7LNATWk8psXZvsHXNwxNt9=sUi3J0qOA-P4ceOKqBuS1_VJQ@mail.gmail.com>
Message-ID: <1889fb67-97fe-4f09-9f29-6563ddfe0603@quicinc.com>

On 11/14/2023 2:10 AM, Masahiro Yamada wrote:
> On Sat, Oct 28, 2023 at 4:31?AM John Moon <quic_johmoo at quicinc.com> wrote:
>>
>> While the kernel community has been good at maintaining backwards
>> compatibility with kernel UAPIs, it would be helpful to have a tool
>> to check if a commit introduces changes that break backwards
>> compatibility.
>>
>> To that end, introduce check-uapi.sh: a simple shell script that
>> checks for changes to UAPI headers using libabigail.
>>
>> libabigail is "a framework which aims at helping developers and
>> software distributors to spot some ABI-related issues like interface
>> incompatibility in ELF shared libraries by performing a static
>> analysis of the ELF binaries at hand."
>>
>> The script uses one of libabigail's tools, "abidiff", to compile the
>> changed header before and after the commit to detect any changes.
>>
>> abidiff "compares the ABI of two shared libraries in ELF format. It
>> emits a meaningful report describing the differences between the two
>> ABIs."
>>
>> The script also includes the ability to check the compatibility of
>> all UAPI headers across commits. This allows developers to inspect
>> the stability of the UAPIs over time.
>>
>> Signed-off-by: John Moon <quic_johmoo at quicinc.com>
>> ---
>>      - Add abidiff suppressions to filter out common things like enum
>>        variants named .*_MAX being changed and expansion into padding
>>        fields.
>>      - Bump minimum abidiff version to 2.4 to accomodate new
>>        suppressions.
>>      - Add option (-i) to suppress ambiguous breaking changes.
>>      - Remove printing of full file diffs when ABI breakage is found
>>        as this was too noisy.
>>      - Wait for all files to be checked before printing results as
>>        printing from parallel threads was garbling output.
>>      - Suppress all output when -q is passed.
>>      - Avoid messing up user's git tree by using "git archive" instead
>>        of checking out references.
> 
> 
> 
> The code looks almost good to me.
> 
> (I left some more comments below, but they are minor).
> 
>

Thanks - ACKing your comments. I'll send a v7 shortly which addresses them.

> 
> Greg,
> Could you check the output from the tool?
> Is it OK with you?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>
>>   scripts/check-uapi.sh | 585 ++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 585 insertions(+)
>>   create mode 100755 scripts/check-uapi.sh
>>
>> diff --git a/scripts/check-uapi.sh b/scripts/check-uapi.sh
>> new file mode 100755
>> index 000000000000..bcb03c8dae60
>> --- /dev/null
>> +++ b/scripts/check-uapi.sh
>> @@ -0,0 +1,585 @@
>> +#!/bin/bash
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +# Script to check commits for UAPI backwards compatibility
>> +
>> +set -o errexit
>> +set -o pipefail
>> +
>> +print_usage() {
>> +       name=$(basename "$0")
>> +       cat << EOF
>> +$name - check for UAPI header stability across Git commits
>> +
>> +By default, the script will check to make sure the latest commit (or current
>> +dirty changes) did not introduce ABI changes when compared to HEAD^1. You can
>> +check against additional commit ranges with the -b and -p options.
>> +
>> +The script will not check UAPI headers for architectures other than the one
>> +defined in ARCH.
>> +
>> +Usage: $name [-b BASE_REF] [-p PAST_REF] [-j N] [-l ERROR_LOG] [-i] [-q] [-v]
>> +
>> +Options:
>> +    -b BASE_REF    Base git reference to use for comparison. If unspecified or empty,
>> +                   will use any dirty changes in tree to UAPI files. If there are no
>> +                   dirty changes, HEAD will be used.
>> +    -p PAST_REF    Compare BASE_REF to PAST_REF (e.g. -p v6.1). If unspecified or empty,
>> +                   will use BASE_REF^1. Must be an ancestor of BASE_REF. Only headers
>> +                   that exist on PAST_REF will be checked for compatibility.
>> +    -j JOBS        Number of checks to run in parallel (default: number of CPU cores).
>> +    -l ERROR_LOG   Write error log to file (default: no error log is generated).
>> +    -i             Ignore ambiguous changes that may or may not break UAPI compatibility.
>> +    -q             Quiet operation.
>> +    -v             Verbose operation (print more information about each header being checked).
>> +
>> +Environmental args:
>> +    ABIDIFF  Custom path to abidiff binary
>> +    CC       C compiler (default is "gcc")
>> +    ARCH     Target architecture of C compiler (default is host arch)
> 
> 
> 
> ARCH is not the arch of C compiler.
> It is the arch for the UAPI check.
> 
> It is better to reword it.
> 
> 
> 
> 
> 
> 
>> +
>> +Exit codes:
>> +    $SUCCESS) Success
>> +    $FAIL_ABI) ABI difference detected
>> +    $FAIL_PREREQ) Prerequisite not met
>> +EOF
>> +}
>> +
>> +readonly SUCCESS=0
>> +readonly FAIL_ABI=1
>> +readonly FAIL_PREREQ=2
>> +
>> +# Print to stderr
>> +eprintf() {
>> +       # shellcheck disable=SC2059
>> +       printf "$@" >&2
>> +}
>> +
>> +# Expand an array with a specific character (similar to Python string.join())
>> +join() {
>> +       local IFS="$1"
>> +       shift
>> +       printf "%s" "$*"
>> +}
>> +
>> +# Create abidiff suppressions
>> +gen_suppressions() {
>> +       # Common enum variant names which we don't want to worry about
>> +       # being shifted when new variants are added.
>> +       local -a enum_regex=(
>> +               ".*_AFTER_LAST$"
>> +               ".*_CNT$"
>> +               ".*_COUNT$"
>> +               ".*_END$"
>> +               ".*_LAST$"
>> +               ".*_MASK$"
>> +               ".*_MAX$"
>> +               ".*_MAX_BIT$"
>> +               ".*_MAX_BPF_ATTACH_TYPE$"
>> +               ".*_MAX_ID$"
>> +               ".*_MAX_SHIFT$"
>> +               ".*_NBITS$"
>> +               ".*_NETDEV_NUMHOOKS$"
>> +               ".*_NFT_META_IIFTYPE$"
>> +               ".*_NL80211_ATTR$"
>> +               ".*_NLDEV_NUM_OPS$"
>> +               ".*_NUM$"
>> +               ".*_NUM_ELEMS$"
>> +               ".*_NUM_IRQS$"
>> +               ".*_SIZE$"
>> +               ".*_TLSMAX$"
>> +               "^MAX_.*"
>> +               "^NUM_.*"
>> +       )
>> +
>> +       # Common padding field names which can be expanded into
>> +       # without worrying about users.
>> +       local -a padding_regex=(
>> +               ".*end$"
>> +               ".*pad$"
>> +               ".*pad[0-9]?$"
>> +               ".*pad_[0-9]?$"
>> +               ".*padding$"
>> +               ".*padding[0-9]?$"
>> +               ".*padding_[0-9]?$"
>> +               ".*res$"
>> +               ".*resv$"
>> +               ".*resv[0-9]?$"
>> +               ".*resv_[0-9]?$"
>> +               ".*reserved$"
>> +               ".*reserved[0-9]?$"
>> +               ".*reserved_[0-9]?$"
>> +               ".*rsvd[0-9]?$"
>> +               ".*unused$"
>> +       )
>> +
>> +       cat << EOF
>> +[suppress_type]
>> +  type_kind = enum
>> +  changed_enumerators_regexp = $(join , "${enum_regex[@]}")
>> +EOF
>> +
>> +       for p in "${padding_regex[@]}"; do
>> +               cat << EOF
>> +[suppress_type]
>> +  type_kind = struct
>> +  has_data_member_inserted_at = offset_of_first_data_member_regexp(${p})
>> +EOF
>> +       done
>> +
>> +if [ "$IGNORE_AMBIGUOUS_CHANGES" = "true" ]; then
>> +       cat << EOF
>> +[suppress_type]
>> +  type_kind = struct
>> +  has_data_member_inserted_at = end
>> +  has_size_change = yes
>> +EOF
>> +fi
>> +}
>> +
>> +# Check if git tree is dirty
>> +tree_is_dirty() {
>> +       ! git diff --quiet
>> +}
>> +
>> +# Get list of files installed in $ref
>> +get_file_list() {
>> +       local -r ref="$1"
>> +       local -r tree="$(get_header_tree "$ref")"
>> +
>> +       # Print all installed headers, filtering out ones that can't be compiled
>> +       find "$tree" -type f -name '*.h' -printf '%P\n' | grep -v -f "$INCOMPAT_LIST"
>> +}
>> +
>> +# Add to the list of incompatible headers
>> +add_to_incompat_list() {
>> +       local -r ref="$1"
>> +
>> +       # Start with the usr/include/Makefile to get a list of the headers
>> +       # that don't compile using this method.
>> +       if [ ! -f usr/include/Makefile ]; then
>> +               eprintf "error - no usr/include/Makefile present at %s\n" "$ref"
>> +               eprintf "Note: usr/include/Makefile was added in the v5.3 kernel release\n"
>> +               exit "$FAIL_PREREQ"
>> +       fi
>> +       {
>> +               # shellcheck disable=SC2016
>> +               printf 'all: ; @echo $(no-header-test)\n'
>> +               cat usr/include/Makefile
>> +       } | SRCARCH="$ARCH" make --always-make -f - | tr " " "\n" \
>> +         | grep -v "asm-generic" >> "$INCOMPAT_LIST"
>> +
>> +       # The makefile also skips all asm-generic files, but prints "asm-generic/%"
>> +       # which won't work for our grep match. Instead, print something grep will match.
>> +       printf "asm-generic/.*\.h\n" >> "$INCOMPAT_LIST"
>> +
>> +       sort -u -o "$INCOMPAT_LIST" "$INCOMPAT_LIST"
>> +       sed -i -e '/^$/d' "$INCOMPAT_LIST"
> 
> 
> 
> Maybe, you can move these two lines to the
> end of install_headers().
> 
> The reason for the duplication is because
> run_make_headers_install() is executed twice.
> 
> You do not need to sort INCOMPAT_LIST
> in the first run of run_make_headers_install().
> 
> 
> 
> 
> 
>> +}
>> +
>> +# Compile the simple test app
>> +do_compile() {
>> +       local -r inc_dir="$1"
>> +       local -r header="$2"
>> +       local -r out="$3"
>> +       printf "int main(void) { return 0; }\n" | \
>> +               "$CC" -c \
>> +                 -o "$out" \
>> +                 -x c \
>> +                 -O0 \
>> +                 -std=c90 \
>> +                 -fno-eliminate-unused-debug-types \
>> +                 -g \
>> +                 "-I${inc_dir}" \
>> +                 -include "$header" \
>> +                 -
>> +}
>> +
>> +# Run make headers_install
>> +run_make_headers_install() {
>> +       local -r install_dir="$1"
> 
> 
> 
> You can call get_header_tree() here,
> and pass "$ref" to this function.
> 
> 
> 
> 
> 
>> +       make -j "$MAX_THREADS" ARCH="$ARCH" INSTALL_HDR_PATH="$install_dir" \
>> +               headers_install > /dev/null
>> +}
>> +
>> +# Install headers for both git refs
>> +install_headers() {
>> +       local -r base_ref="$1"
>> +       local -r past_ref="$2"
>> +
>> +       for ref in "$base_ref" "$past_ref"; do
>> +               printf "Installing user-facing UAPI headers from %s... " "${ref:-dirty tree}"
>> +               if [ -n "$ref" ]; then
>> +                       git archive --format=tar --prefix="${ref}-archive/" "$ref" \
>> +                               | (cd "$TMP_DIR" && tar xf -)
>> +                       (
>> +                               cd "${TMP_DIR}/${ref}-archive"
>> +                               run_make_headers_install "${TMP_DIR}/${ref}/usr"
>> +                               add_to_incompat_list "$ref" "$INCOMPAT_LIST"
>> +                       )
>> +               else
>> +                       run_make_headers_install "${TMP_DIR}/${ref}/usr"
>> +                       add_to_incompat_list "$ref" "$INCOMPAT_LIST"
> 
> 
> 
> If we drop the dirty tree support, we can make the code simpler.
> 
> $ref would never become empty, and we would always be able to run
> "make headers_install" in the /tmp directory.
> 
> ("make headers_install" in the working tree would create intermediate
> build artifacts in usr/include/)
> 
> That is my personal opinion.
> 
> 
> If you insist on the dirty tree support,
> I will leave it to you.
> 
> 

Dirty tree support is something Greg requested on v1, so I figure we 
should keep it.

> 
> 
> 
> 
> 
>> +               fi
>> +               printf "OK\n"
>> +       done
>> +}
>> +
>> +# Print the path to the headers_install tree for a given ref
>> +get_header_tree() {
>> +       local -r ref="$1"
>> +       printf "%s" "${TMP_DIR}/${ref}/usr"
>> +}
>> +
>> +# Check file list for UAPI compatibility
>> +check_uapi_files() {
>> +       local -r base_ref="$1"
>> +       local -r past_ref="$2"
>> +       local -r abi_error_log="$3"
>> +
>> +       local passed=0;
>> +       local failed=0;
>> +       local -a threads=()
>> +       set -o errexit
>> +
>> +       printf "Checking changes to UAPI headers between %s and %s...\n" "$past_ref" "${base_ref:-dirty tree}"
>> +       # Loop over all UAPI headers that were installed by $past_ref (if they only exist on $base_ref,
>> +       # there's no way they're broken and no way to compare anyway)
>> +       while read -r file; do
>> +               if [ "${#threads[@]}" -ge "$MAX_THREADS" ]; then
>> +                       if wait "${threads[0]}"; then
>> +                               passed=$((passed + 1))
>> +                       else
>> +                               failed=$((failed + 1))
>> +                       fi
>> +                       threads=("${threads[@]:1}")
>> +               fi
>> +
>> +               check_individual_file "$base_ref" "$past_ref" "$file" &
>> +               threads+=("$!")
>> +       done < <(get_file_list "$past_ref")
>> +
>> +       for t in "${threads[@]}"; do
>> +               if wait "$t"; then
>> +                       passed=$((passed + 1))
>> +               else
>> +                       failed=$((failed + 1))
>> +               fi
>> +       done
>> +
>> +       if [ -n "$abi_error_log" ]; then
>> +               printf 'Generated by "%s %s" from git ref %s\n\n' \
>> +                       "$0" "$*" "$(git rev-parse HEAD)" > "$abi_error_log"
>> +       fi
>> +
>> +       while read -r error_file; do
>> +               {
>> +                       cat "$error_file"
>> +                       printf "\n\n"
>> +               } | tee -a "${abi_error_log:-/dev/null}" >&2
>> +       done < <(find "$TMP_DIR" -type f -name '*.error')
> 
> 
> 
> Does this produce this deterministic result?
> 
> 
> Maybe, adding '| sort' after the 'find' command
> will produce the sorted report?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> +
>> +       total="$((passed + failed))"
>> +       if [ "$failed" -gt 0 ]; then
>> +               eprintf "error - %d/%d UAPI headers compatible with %s appear _not_ to be backwards compatible\n" \
>> +                       "$failed" "$total" "$ARCH"
>> +               if [ -n "$abi_error_log" ]; then
>> +                       eprintf "Failure summary saved to %s\n" "$abi_error_log"
>> +               fi
>> +       else
>> +               printf "All %d UAPI headers compatible with %s appear to be backwards compatible\n" \
>> +                       "$total" "$ARCH"
>> +       fi
>> +
>> +       return "$failed"
>> +}
>> +
>> +# Check an individual file for UAPI compatibility
>> +check_individual_file() {
>> +       local -r base_ref="$1"
>> +       local -r past_ref="$2"
>> +       local -r file="$3"
>> +
>> +       local -r base_header="$(get_header_tree "$base_ref")/${file}"
>> +       local -r past_header="$(get_header_tree "$past_ref")/${file}"
>> +
>> +       local base_ref_short="${base_ref:-dirty tree}"
>> +       if [ "${#base_ref_short}" -ge 40 ]; then
>> +               base_ref_short="$(git rev-parse --short "$base_ref_short")"
> 
> 
> 
> I believe this is intended to keep the log short, but
> I think we can simply use the ref name passed by the user.
> If ${ref} is crazily long, it is a user's fault.
> 
> 
> 
> 
> 
> 
> 
>> +       fi
>> +
>> +       local past_ref_short="$past_ref"
>> +       if [ "${#past_ref_short}" -ge 40 ]; then
>> +               past_ref_short="$(git rev-parse --short "$past_ref_short")"
>> +       fi
>> +
>> +       if [ ! -f "$base_header" ]; then
>> +               mkdir -p "$(dirname "$base_header")"
>> +               printf "==== UAPI header %s was removed between %s and %s ====" \
>> +                       "$file" "$past_ref_short" "$base_ref_short" \
>> +                               > "${base_header}.error"
>> +               return 1
>> +       fi
>> +
>> +       compare_abi "$file" "$base_header" "$past_header" "$base_ref" "$past_ref" \
>> +               "$base_ref_short" "$past_ref_short"
>> +}
>> +
>> +# Perform the A/B compilation and compare output ABI
>> +compare_abi() {
>> +       local -r file="$1"
>> +       local -r base_header="$2"
>> +       local -r past_header="$3"
>> +       local -r base_ref="$4"
>> +       local -r past_ref="$5"
>> +       local -r base_ref_short="$6"
>> +       local -r past_ref_short="$7"
>> +       local -r log="${TMP_DIR}/log/${file}.log"
>> +
>> +       mkdir -p "$(dirname "$log")"
>> +
>> +       if ! do_compile "$(get_header_tree "$base_ref")/include" "$base_header" "${base_header}.bin" 2> "$log"; then
>> +               {
>> +                       warn_str=$(printf "==== Could not compile version of UAPI header %s at %s ====\n" \
>> +                               "$file" "$base_ref_short")
>> +                       printf "%s\n" "$warn_str"
>> +                       cat "$log"
>> +                       printf -- "=%.0s" $(seq 0 ${#warn_str})
>> +               } > "${base_header}.error"
>> +               return 1
>> +       fi
>> +
>> +       if ! do_compile "$(get_header_tree "$past_ref")/include" "$past_header" "${past_header}.bin" 2> "$log"; then
>> +               {
>> +                       warn_str=$(printf "==== Could not compile version of UAPI header %s at %s ====\n" \
>> +                               "$file" "$past_ref_short")
>> +                       printf "%s\n" "$warn_str"
>> +                       cat "$log"
>> +                       printf -- "=%.0s" $(seq 0 ${#warn_str})
>> +               } > "${base_header}.error"
> 
> 
> 
> You used  >"${base_header}.error" instead of
>> "${past_header}.error" here.
> 
> I guess it is intentional.
> 
> 
> 
> But, I think you can put *.error files
> under the ${TMP_DIR}/log/ directory if you save the log
> from base_ref and past_ref into the same log file.
> 
> 
> For example,
> 
> 
>     local -r error_log="${TMP_DIR}/log/${file}.error"
> 
> 
> Then,
> 
>      {
>            ...
> 
>      } > "${error_log}"
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> +               return 1
>> +       fi
>> +
>> +       local ret=0
>> +       "$ABIDIFF" --non-reachable-types \
>> +               --suppressions "$SUPPRESSIONS" \
>> +               "${past_header}.bin" "${base_header}.bin" > "$log" || ret="$?"
>> +       if [ "$ret" -eq 0 ]; then
>> +               if [ "$VERBOSE" = "true" ]; then
>> +                       printf "No ABI differences detected in %s from %s -> %s\n" \
>> +                               "$file" "$past_ref_short" "$base_ref_short"
>> +               fi
>> +       else
>> +               # Bits in abidiff's return code can be used to determine the type of error
>> +               if [ $((ret & 0x2)) -gt 0 ]; then
>> +                       eprintf "error - abidiff did not run properly\n"
>> +                       exit 1
>> +               fi
>> +
>> +               if [ "$IGNORE_AMBIGUOUS_CHANGES" = "true" ] && [ "$ret" -eq 4 ]; then
>> +                       return 0
>> +               fi
>> +
>> +               # If the only changes were additions (not modifications to existing APIs), then
>> +               # there's no problem. Ignore these diffs.
>> +               if grep "Unreachable types summary" "$log" | grep -q "0 removed" &&
>> +                  grep "Unreachable types summary" "$log" | grep -q "0 changed"; then
>> +                       return 0
>> +               fi
>> +
>> +               {
>> +                       warn_str=$(printf "==== ABI differences detected in %s from %s -> %s ====" \
>> +                               "$file" "$past_ref_short" "$base_ref_short")
>> +                       printf "%s\n" "$warn_str"
>> +                       sed  -e '/summary:/d' -e '/changed type/d' -e '/^$/d' -e 's/^/  /g' "$log"
>> +                       printf -- "=%.0s" $(seq 0 ${#warn_str})
>> +                       if cmp "$past_header" "$base_header" > /dev/null 2>&1; then
>> +                               printf "\n%s did not change between %s and %s...\n" "$file" "$past_ref" "${base_ref:-dirty tree}"
>> +                               printf "It's possible a change to one of the headers it includes caused this error:\n"
>> +                               grep '^#include' "$base_header"
>> +                               printf "\n"
>> +                       fi
>> +               } > "${base_header}.error"
>> +
>> +               return 1
>> +       fi
>> +}
>> +
>> +# Check that a minimum software version number is satisfied
>> +min_version_is_satisfied() {
>> +       local -r min_version="$1"
>> +       local -r version_installed="$2"
>> +
>> +       printf "%s\n%s\n" "$min_version" "$version_installed" \
>> +               | sort -Vc > /dev/null 2>&1
>> +}
>> +
>> +# Make sure we have the tools we need and the arguments make sense
>> +check_deps() {
>> +       ABIDIFF="${ABIDIFF:-abidiff}"
>> +       CC="${CC:-gcc}"
>> +       ARCH="${ARCH:-$(uname -m)}"
>> +       if [ "$ARCH" = "x86_64" ]; then
>> +               ARCH="x86"
>> +       fi
>> +
>> +       local -r abidiff_min_version="2.4"
>> +       local -r libdw_min_version_if_clang="0.171"
>> +
>> +       if ! command -v "$ABIDIFF" > /dev/null 2>&1; then
>> +               eprintf "error - abidiff not found!\n"
>> +               eprintf "Please install abigail-tools version %s or greater\n" "$abidiff_min_version"
>> +               eprintf "See: https://sourceware.org/libabigail/manual/libabigail-overview.html\n"
>> +               return 1
>> +       fi
>> +
>> +       local -r abidiff_version="$("$ABIDIFF" --version | cut -d ' ' -f 2)"
>> +       if ! min_version_is_satisfied "$abidiff_min_version" "$abidiff_version"; then
>> +               eprintf "error - abidiff version too old: %s\n" "$abidiff_version"
>> +               eprintf "Please install abigail-tools version %s or greater\n" "$abidiff_min_version"
>> +               eprintf "See: https://sourceware.org/libabigail/manual/libabigail-overview.html\n"
>> +               return 1
>> +       fi
>> +
>> +       if ! command -v "$CC" > /dev/null 2>&1; then
>> +               eprintf 'error - %s not found\n' "$CC"
>> +               return 1
>> +       fi
>> +
>> +       if "$CC" --version | grep -q clang; then
>> +               local -r libdw_version="$(ldconfig -v 2>/dev/null | grep -v SKIPPED | grep -m 1 -o 'libdw-[0-9]\+.[0-9]\+' | cut -c 7-)"
>> +               if ! min_version_is_satisfied "$libdw_min_version_if_clang" "$libdw_version"; then
>> +                       eprintf "error - libdw version too old for use with clang: %s\n" "$libdw_version"
>> +                       eprintf "Please install libdw from elfutils version %s or greater\n" "$libdw_min_version_if_clang"
>> +                       eprintf "See: https://sourceware.org/elfutils/\n"
>> +                       return 1
>> +               fi
>> +       fi
>> +
>> +       if [ ! -d "arch/${ARCH}" ]; then
>> +               eprintf 'error - ARCH "%s" is not a subdirectory under arch/\n' "$ARCH"
>> +               eprintf "Please set ARCH to one of:\n%s\n" "$(find arch -maxdepth 1 -mindepth 1 -type d -printf '%f ' | fmt)"
>> +               return 1
>> +       fi
>> +
>> +       if ! git rev-parse --is-inside-work-tree > /dev/null 2>&1; then
>> +               eprintf "error - this script requires the kernel tree to be initialized with Git\n"
>> +               return 1
>> +       fi
>> +
>> +       if ! git rev-parse --verify "$past_ref" > /dev/null 2>&1; then
>> +               printf 'error - invalid git reference "%s"\n' "$past_ref"
>> +               return 1
>> +       fi
>> +
>> +       if [ -n "$base_ref" ]; then
>> +               if ! git merge-base --is-ancestor "$past_ref" "$base_ref" > /dev/null 2>&1; then
>> +                       printf 'error - "%s" is not an ancestor of base ref "%s"\n' "$past_ref" "$base_ref"
>> +                       return 1
>> +               fi
>> +               if [ "$(git rev-parse "$base_ref")" = "$(git rev-parse "$past_ref")" ]; then
>> +                       printf 'error - "%s" and "%s" are the same reference\n' "$past_ref" "$base_ref"
>> +                       return 1
>> +               fi
>> +       fi
>> +}
>> +
>> +run() {
>> +       local base_ref="$1"
>> +       local past_ref="$2"
>> +       local abi_error_log="$3"
>> +       shift 3
>> +
>> +       if [ -z "$KERNEL_SRC" ]; then
>> +               KERNEL_SRC="$(realpath "$(dirname "$0")"/..)"
>> +       fi
>> +
>> +       cd "$KERNEL_SRC"
>> +
>> +       if [ -z "$base_ref" ] && ! tree_is_dirty; then
>> +               base_ref=HEAD
>> +       fi
>> +
>> +       if [ -z "$past_ref" ]; then
>> +               if [ -n "$base_ref" ]; then
>> +                       past_ref="${base_ref}^1"
>> +               else
>> +                       past_ref=HEAD
>> +               fi
>> +       fi
>> +
>> +       if ! check_deps; then
>> +               exit "$FAIL_PREREQ"
>> +       fi
>> +
>> +       TMP_DIR=$(mktemp -d)
>> +       readonly TMP_DIR
>> +       trap 'rm -rf "$TMP_DIR"' EXIT
>> +
>> +       readonly INCOMPAT_LIST="${TMP_DIR}/incompat_list.txt"
>> +       touch "$INCOMPAT_LIST"
>> +
>> +       readonly SUPPRESSIONS="${TMP_DIR}/suppressions.txt"
>> +       gen_suppressions > "$SUPPRESSIONS"
>> +
>> +       # Run make install_headers for both refs
>> +       install_headers "$base_ref" "$past_ref"
>> +
>> +       # Check for any differences in the installed header trees
>> +       if diff -r -q "$(get_header_tree "$base_ref")" "$(get_header_tree "$past_ref")" > /dev/null 2>&1; then
>> +               printf "No changes to UAPI headers were applied between %s and %s\n" "$past_ref" "${base_ref:-dirty tree}"
>> +               exit "$SUCCESS"
>> +       fi
>> +
>> +       if ! check_uapi_files "$base_ref" "$past_ref" "$abi_error_log"; then
>> +               exit "$FAIL_ABI"
>> +       fi
>> +}
>> +
>> +main() {
>> +       MAX_THREADS=$(nproc)
>> +       VERBOSE="false"
>> +       IGNORE_AMBIGUOUS_CHANGES="false"
>> +       quiet="false"
>> +       local base_ref=""
>> +       while getopts "hb:p:j:l:iqv" opt; do
>> +               case $opt in
>> +               h)
>> +                       print_usage
>> +                       exit "$SUCCESS"
>> +                       ;;
>> +               b)
>> +                       base_ref="$OPTARG"
>> +                       ;;
>> +               p)
>> +                       past_ref="$OPTARG"
>> +                       ;;
>> +               j)
>> +                       MAX_THREADS="$OPTARG"
>> +                       ;;
>> +               l)
>> +                       abi_error_log="$OPTARG"
>> +                       ;;
>> +               i)
>> +                       IGNORE_AMBIGUOUS_CHANGES="true"
>> +                       ;;
>> +               q)
>> +                       quiet="true"
>> +                       VERBOSE="false"
>> +                       ;;
>> +               v)
>> +                       VERBOSE="true"
>> +                       quiet="false"
>> +                       ;;
>> +               *)
>> +                       exit "$FAIL_PREREQ"
>> +               esac
>> +       done
>> +
>> +       if [ "$quiet" = "true" ]; then
>> +               exec > /dev/null 2>&1
>> +       fi
>> +
>> +       run "$base_ref" "$past_ref" "$abi_error_log" "$@"
>> +}
>> +
>> +main "$@"
>> --
>> 2.17.1
>>
> 
> 
> --
> Best Regards
> 
> Masahiro Yamada


From semen.protsenko at linaro.org  Mon Dec 11 14:38:11 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Mon, 11 Dec 2023 16:38:11 -0600
Subject: [PATCH v7 06/16] dt-bindings: clock: google,gs101: fix incorrect
 numbering and DGB suffix
In-Reply-To: <20231211162331.435900-7-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-7-peter.griffin@linaro.org>
Message-ID: <CAPLW+4=ZCyyQpzt-QRVeLeORdir99e311WxoY+q1DP9GzU7s4A@mail.gmail.com>

On Mon, Dec 11, 2023 at 10:24?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> 166 was skipped by mistake and two clocks:
> * CLK_MOUT_CMU_HSI0_USBDPDGB
> * CLK_GOUT_HSI0_USBDPDGB
>
> Have an incorrect DGB ending instead of DBG.
>
> This is an ABI break, but as the patch was only applied yesterday this
> header has never been in an actual release so it seems better to fix
> this early than ignore it.
>
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  include/dt-bindings/clock/google,gs101.h | 118 +++++++++++------------
>  1 file changed, 59 insertions(+), 59 deletions(-)
>
> diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
> index 5d2c2d907a7b..9761c0b24e66 100644
> --- a/include/dt-bindings/clock/google,gs101.h
> +++ b/include/dt-bindings/clock/google,gs101.h
> @@ -59,7 +59,7 @@
>  #define CLK_MOUT_CMU_HSI0_BUS          45
>  #define CLK_MOUT_CMU_HSI0_DPGTC                46
>  #define CLK_MOUT_CMU_HSI0_USB31DRD     47
> -#define CLK_MOUT_CMU_HSI0_USBDPDGB     48
> +#define CLK_MOUT_CMU_HSI0_USBDPDBG     48
>  #define CLK_MOUT_CMU_HSI1_BUS          49
>  #define CLK_MOUT_CMU_HSI1_PCIE         50
>  #define CLK_MOUT_CMU_HSI2_BUS          51
> @@ -181,64 +181,64 @@
>  #define CLK_GOUT_BUS2_BUS              163
>  #define CLK_GOUT_CIS_CLK0              164
>  #define CLK_GOUT_CIS_CLK1              165
> -#define CLK_GOUT_CIS_CLK2              167
> -#define CLK_GOUT_CIS_CLK3              168
> -#define CLK_GOUT_CIS_CLK4              169
> -#define CLK_GOUT_CIS_CLK5              170
> -#define CLK_GOUT_CIS_CLK6              171
> -#define CLK_GOUT_CIS_CLK7              172
> -#define CLK_GOUT_CMU_BOOST             173
> -#define CLK_GOUT_CORE_BUS              174
> -#define CLK_GOUT_CPUCL0_DBG            175
> -#define CLK_GOUT_CPUCL0_SWITCH         176
> -#define CLK_GOUT_CPUCL1_SWITCH         177
> -#define CLK_GOUT_CPUCL2_SWITCH         178
> -#define CLK_GOUT_CSIS_BUS              179
> -#define CLK_GOUT_DISP_BUS              180
> -#define CLK_GOUT_DNS_BUS               181
> -#define CLK_GOUT_DPU_BUS               182
> -#define CLK_GOUT_EH_BUS                        183
> -#define CLK_GOUT_G2D_G2D               184
> -#define CLK_GOUT_G2D_MSCL              185
> -#define CLK_GOUT_G3AA_G3AA             186
> -#define CLK_GOUT_G3D_BUSD              187
> -#define CLK_GOUT_G3D_GLB               188
> -#define CLK_GOUT_G3D_SWITCH            189
> -#define CLK_GOUT_GDC_GDC0              190
> -#define CLK_GOUT_GDC_GDC1              191
> -#define CLK_GOUT_GDC_SCSC              192
> -#define CLK_GOUT_CMU_HPM               193
> -#define CLK_GOUT_HSI0_BUS              194
> -#define CLK_GOUT_HSI0_DPGTC            195
> -#define CLK_GOUT_HSI0_USB31DRD         196
> -#define CLK_GOUT_HSI0_USBDPDGB         197
> -#define CLK_GOUT_HSI1_BUS              198
> -#define CLK_GOUT_HSI1_PCIE             199
> -#define CLK_GOUT_HSI2_BUS              200
> -#define CLK_GOUT_HSI2_MMC_CARD         201
> -#define CLK_GOUT_HSI2_PCIE             202
> -#define CLK_GOUT_HSI2_UFS_EMBD         203
> -#define CLK_GOUT_IPP_BUS               204
> -#define CLK_GOUT_ITP_BUS               205
> -#define CLK_GOUT_MCSC_ITSC             206
> -#define CLK_GOUT_MCSC_MCSC             207
> -#define CLK_GOUT_MFC_MFC               208
> -#define CLK_GOUT_MIF_BUSP              209
> -#define CLK_GOUT_MISC_BUS              210
> -#define CLK_GOUT_MISC_SSS              211
> -#define CLK_GOUT_PDP_BUS               212
> -#define CLK_GOUT_PDP_VRA               213
> -#define CLK_GOUT_G3AA                  214
> -#define CLK_GOUT_PERIC0_BUS            215
> -#define CLK_GOUT_PERIC0_IP             216
> -#define CLK_GOUT_PERIC1_BUS            217
> -#define CLK_GOUT_PERIC1_IP             218
> -#define CLK_GOUT_TNR_BUS               219
> -#define CLK_GOUT_TOP_CMUREF            220
> -#define CLK_GOUT_TPU_BUS               221
> -#define CLK_GOUT_TPU_TPU               222
> -#define CLK_GOUT_TPU_TPUCTL            223
> -#define CLK_GOUT_TPU_UART              224
> +#define CLK_GOUT_CIS_CLK2              166
> +#define CLK_GOUT_CIS_CLK3              167
> +#define CLK_GOUT_CIS_CLK4              168
> +#define CLK_GOUT_CIS_CLK5              169
> +#define CLK_GOUT_CIS_CLK6              170
> +#define CLK_GOUT_CIS_CLK7              171
> +#define CLK_GOUT_CMU_BOOST             172
> +#define CLK_GOUT_CORE_BUS              173
> +#define CLK_GOUT_CPUCL0_DBG            174
> +#define CLK_GOUT_CPUCL0_SWITCH         175
> +#define CLK_GOUT_CPUCL1_SWITCH         176
> +#define CLK_GOUT_CPUCL2_SWITCH         177
> +#define CLK_GOUT_CSIS_BUS              178
> +#define CLK_GOUT_DISP_BUS              179
> +#define CLK_GOUT_DNS_BUS               180
> +#define CLK_GOUT_DPU_BUS               181
> +#define CLK_GOUT_EH_BUS                        182
> +#define CLK_GOUT_G2D_G2D               183
> +#define CLK_GOUT_G2D_MSCL              184
> +#define CLK_GOUT_G3AA_G3AA             185
> +#define CLK_GOUT_G3D_BUSD              186
> +#define CLK_GOUT_G3D_GLB               187
> +#define CLK_GOUT_G3D_SWITCH            188
> +#define CLK_GOUT_GDC_GDC0              189
> +#define CLK_GOUT_GDC_GDC1              190
> +#define CLK_GOUT_GDC_SCSC              191
> +#define CLK_GOUT_CMU_HPM               192
> +#define CLK_GOUT_HSI0_BUS              193
> +#define CLK_GOUT_HSI0_DPGTC            194
> +#define CLK_GOUT_HSI0_USB31DRD         195
> +#define CLK_GOUT_HSI0_USBDPDBG         196
> +#define CLK_GOUT_HSI1_BUS              197
> +#define CLK_GOUT_HSI1_PCIE             198
> +#define CLK_GOUT_HSI2_BUS              199
> +#define CLK_GOUT_HSI2_MMC_CARD         200
> +#define CLK_GOUT_HSI2_PCIE             201
> +#define CLK_GOUT_HSI2_UFS_EMBD         202
> +#define CLK_GOUT_IPP_BUS               203
> +#define CLK_GOUT_ITP_BUS               204
> +#define CLK_GOUT_MCSC_ITSC             205
> +#define CLK_GOUT_MCSC_MCSC             206
> +#define CLK_GOUT_MFC_MFC               207
> +#define CLK_GOUT_MIF_BUSP              208
> +#define CLK_GOUT_MISC_BUS              209
> +#define CLK_GOUT_MISC_SSS              210
> +#define CLK_GOUT_PDP_BUS               211
> +#define CLK_GOUT_PDP_VRA               212
> +#define CLK_GOUT_G3AA                  213
> +#define CLK_GOUT_PERIC0_BUS            214
> +#define CLK_GOUT_PERIC0_IP             215
> +#define CLK_GOUT_PERIC1_BUS            216
> +#define CLK_GOUT_PERIC1_IP             217
> +#define CLK_GOUT_TNR_BUS               218
> +#define CLK_GOUT_TOP_CMUREF            219
> +#define CLK_GOUT_TPU_BUS               220
> +#define CLK_GOUT_TPU_TPU               221
> +#define CLK_GOUT_TPU_TPUCTL            222
> +#define CLK_GOUT_TPU_UART              223
>
>  /* CMU_APM */
>  #define CLK_MOUT_APM_FUNC                              1
> --
> 2.43.0.472.g3155946c3a-goog
>


From lech.perczak at gmail.com  Mon Dec 11 14:41:35 2023
From: lech.perczak at gmail.com (Lech Perczak)
Date: Mon, 11 Dec 2023 23:41:35 +0100
Subject: [PATCH] ARM: dts: nxp: imx7d-pico: add cpu-supply nodes
In-Reply-To: <20231206013247.GY236001@dragon>
References: <20231117232352.101713-1-lech.perczak@gmail.com>
 <20231206013247.GY236001@dragon>
Message-ID: <5b285fdd-9d69-400c-978f-234665fca73e@gmail.com>

W dniu 2023-12-06 o?02:32, Shawn Guo pisze:
> On Sat, Nov 18, 2023 at 12:23:52AM +0100, Lech Perczak wrote:
>> The PICO-IMX7D SoM has the usual power supply configuration using
>> output sw1a of PF3000 PMIC, which was defined in downstream derivative
>> of linux-imx (see link) in the sources for "Android Things" devkit.
>> It is required to support CPU frequency scaling.
>>
>> Map the respective "cpu-supply" nodes of each core to sw1a of the PMIC.
>>
>> Enabling them causes cpufreq-dt, and imx-thermal drivers to probe
>> successfully, and CPU frequency scaling to function.
>>
>> Link: https://android.googlesource.com/platform/hardware/bsp/kernel/nxp/imx-v4.1/+/o-iot-preview-5/arch/arm/boot/dts/imx7d-pico.dtsi#849
>>
>> Cc: Fabio Estevam <festevam at gmail.com>
>> Cc: Shawn Guo <shawnguo at kernel.org>
>> Cc: Sascha Hauer <s.hauer at pengutronix.de>
>>
>> Signed-off-by: Lech Perczak <lech.perczak at gmail.com>
> Applied, thanks!

Hi Shawn,

Do you think this could be backported to stable later?
OpenWrt and Debian could then pick this change up - I have a pull 
request open in OpenWrt backporting this.

-- 
Pozdrawiam/With kind regards,
Lech Perczak



From seanjc at google.com  Mon Dec 11 14:57:00 2023
From: seanjc at google.com (Sean Christopherson)
Date: Mon, 11 Dec 2023 14:57:00 -0800
Subject: [PATCH v3 1/5] KVM: Add arch specific interfaces for sampling
 guest callchains
In-Reply-To: <865y16b6cf.wl-maz@kernel.org>
References: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
 <SYBPR01MB6870FDFBB88F879C735198F39D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
 <865y16b6cf.wl-maz@kernel.org>
Message-ID: <ZXeTvCLURmwzpDkP@google.com>

On Sun, Dec 10, 2023, Marc Zyngier wrote:
> On Sun, 10 Dec 2023 08:12:18 +0000, Tianyi Liu <i.pear at outlook.com> wrote:
> > +bool kvm_arch_vcpu_read_virt(struct kvm_vcpu *vcpu, gva_t addr, void *dest, unsigned int length)
> > +{
> > +	/* TODO: implement */
> > +	return false;
> > +}
> 
> I don't do it very often, but the only thing I can say about this is
> *NAK*.
> 
> You have decided to ignore the previous review comments, which is your
> prerogative. However, I absolutely refuse to add half baked and
> *dangerous* stuff to the arm64's version of KVM.
> 
> If you can convince the x86 folks that they absolutely want this, fine
> by me. But this need to be a buy-in interface, not something that is
> required for each and every architecture to have stubs, wrongly
> suggesting that extra work is needed.
> 
> For arm64, the way to go is to have this in userspace. Which is both
> easy to implement and safe. And until we have such a userspace
> implementation as a baseline, I will not consider a kernel
> version.

I too want more justification of why this needs to be handled in the kernel[*].
The usefulness of this is dubious for many modern setups/workloads, and outright
undesirable for some, e.g. many (most?) cloud providers want to make it all but
impossible to access customer data.

[*] https://lore.kernel.org/all/ZSlNsn-f1j2bB8pW at FVFF77S0Q05N.cambridge.arm.com


From robin.murphy at arm.com  Mon Dec 11 14:58:58 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 11 Dec 2023 22:58:58 +0000
Subject: [PATCH v2] iommu/arm-smmu-qcom: Add missing GMU entry to match
 table
In-Reply-To: <20231210180655.75542-1-robdclark@gmail.com>
References: <20231210180655.75542-1-robdclark@gmail.com>
Message-ID: <86d3ee06-7c8d-4f60-bcba-80b772ec0faf@arm.com>

On 2023-12-10 6:06 pm, Rob Clark wrote:
> From: Rob Clark <robdclark at chromium.org>
> 
> In some cases the firmware expects cbndx 1 to be assigned to the GMU,
> so we also want the default domain for the GMU to be an identy domain.
> This way it does not get a context bank assigned.  Without this, both
> of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
> allocating and configuring a context bank.  So GMU ends up attached to
> both cbndx 1 and later cbndx 2.  This arrangement seemingly confounds
> and surprises the firmware if the GPU later triggers a translation
> fault, resulting (on sc8280xp / lenovo x13s, at least) in the SMMU
> getting wedged and the GPU stuck without memory access.

Reviewed-by: Robin Murphy <robin.murphy at arm.com>

> Cc: stable at vger.kernel.org
> Signed-off-by: Rob Clark <robdclark at chromium.org>
> ---
> 
> I didn't add a fixes tag because really this issue has been there
> all along, but either didn't matter with other firmware or we didn't
> notice the problem.
> 
>   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index 549ae4dba3a6..d326fa230b96 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -243,6 +243,7 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
>   
>   static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
>   	{ .compatible = "qcom,adreno" },
> +	{ .compatible = "qcom,adreno-gmu" },
>   	{ .compatible = "qcom,mdp4" },
>   	{ .compatible = "qcom,mdss" },
>   	{ .compatible = "qcom,sc7180-mdss" },


From kuba at kernel.org  Mon Dec 11 14:59:44 2023
From: kuba at kernel.org (Jakub Kicinski)
Date: Mon, 11 Dec 2023 14:59:44 -0800
Subject: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <zx7tfojtnzuhcpglkeiwg6ep265xpcb5lmz6fgjjugc2tue6qe@cmuqtneujsvb>
References: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
	<zx7tfojtnzuhcpglkeiwg6ep265xpcb5lmz6fgjjugc2tue6qe@cmuqtneujsvb>
Message-ID: <20231211145944.0be51404@kernel.org>

On Mon, 11 Dec 2023 14:14:00 +0300 Serge Semin wrote:
> Although in this case AFAICS the implementation is simpler and the
> only difference is in the CSR offset and the frame preemption residue
> queue ID setting. All of that can be easily solved in the same way as
> it was done for EST (see the link above).
> 
> Jakub, what do you think?

Yup, less code duplication would be great. Highest prio, tho, is to
focus on Vladimir's comment around this driver seemingly implementing
FPE but not using the common ethtool APIs to configure it, yet :(


From andrew at codeconstruct.com.au  Mon Dec 11 15:03:17 2023
From: andrew at codeconstruct.com.au (Andrew Jeffery)
Date: Tue, 12 Dec 2023 09:33:17 +1030
Subject: [PATCH v4 2/2] i2c: aspeed: Acknowledge Tx done with and
 without ACK irq late
In-Reply-To: <20231211102217.2436294-3-quan@os.amperecomputing.com>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
	 <20231211102217.2436294-3-quan@os.amperecomputing.com>
Message-ID: <2eab42cde34723a195e7a0287db08b25f8388a3b.camel@codeconstruct.com.au>

On Mon, 2023-12-11 at 17:22 +0700, Quan Nguyen wrote:
> Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
> interrupt handler") acknowledges most interrupts early before the slave
> irq handler is executed, except for the "Receive Done Interrupt status"
> which is acknowledged late in the interrupt.
> However, it has been observed that the early acknowledgment of "Transmit
> Done Interrupt Status" (with ACK or NACK) often causes the interrupt to
> be raised in READ REQUEST state, that shows the
> "Unexpected ACK on read request." complaint messages.
> 
> Assuming that the "Transmit Done" interrupt should only be acknowledged
> once it is truly processed, this commit fixes that issue by acknowledging
> interrupts for both ACK and NACK cases late in the interrupt handler.
> 
> Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>

Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>

Thanks Quan!


From linus.walleij at linaro.org  Mon Dec 11 15:39:25 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 12 Dec 2023 00:39:25 +0100
Subject: [PATCH] ARM: dts: ste: minor whitespace cleanup around '='
Message-ID: <20231212-ux500-dts-v1-1-5a31b6742d85@linaro.org>

From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

The DTS code coding style expects exactly one space before and after '='
sign.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
SoC maintainers: this single patch is all changes I have for v6.8,
please apply it directly for DTS changes.
---
 arch/arm/boot/dts/st/ste-dbx5x0.dtsi                  | 18 +++++++++---------
 arch/arm/boot/dts/st/ste-hrefprev60.dtsi              |  2 +-
 arch/arm/boot/dts/st/ste-hrefv60plus.dtsi             |  2 +-
 arch/arm/boot/dts/st/ste-nomadik-stn8815.dtsi         |  8 ++++----
 arch/arm/boot/dts/st/ste-snowball.dts                 |  2 +-
 arch/arm/boot/dts/st/ste-ux500-samsung-codina-tmo.dts |  2 +-
 arch/arm/boot/dts/st/ste-ux500-samsung-codina.dts     |  2 +-
 arch/arm/boot/dts/st/ste-ux500-samsung-gavini.dts     |  2 +-
 arch/arm/boot/dts/st/ste-ux500-samsung-janice.dts     |  2 +-
 arch/arm/boot/dts/st/ste-ux500-samsung-kyle.dts       |  2 +-
 10 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/st/ste-dbx5x0.dtsi b/arch/arm/boot/dts/st/ste-dbx5x0.dtsi
index d5d88771ef97..0f87abeddc33 100644
--- a/arch/arm/boot/dts/st/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/st/ste-dbx5x0.dtsi
@@ -425,7 +425,7 @@ rtc at 80154000 {
 		gpio0: gpio at 8012e000 {
 			compatible = "stericsson,db8500-gpio",
 				"st,nomadik-gpio";
-			reg =  <0x8012e000 0x80>;
+			reg = <0x8012e000 0x80>;
 			interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -440,7 +440,7 @@ gpio0: gpio at 8012e000 {
 		gpio1: gpio at 8012e080 {
 			compatible = "stericsson,db8500-gpio",
 				"st,nomadik-gpio";
-			reg =  <0x8012e080 0x80>;
+			reg = <0x8012e080 0x80>;
 			interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -455,7 +455,7 @@ gpio1: gpio at 8012e080 {
 		gpio2: gpio at 8000e000 {
 			compatible = "stericsson,db8500-gpio",
 				"st,nomadik-gpio";
-			reg =  <0x8000e000 0x80>;
+			reg = <0x8000e000 0x80>;
 			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -470,7 +470,7 @@ gpio2: gpio at 8000e000 {
 		gpio3: gpio at 8000e080 {
 			compatible = "stericsson,db8500-gpio",
 				"st,nomadik-gpio";
-			reg =  <0x8000e080 0x80>;
+			reg = <0x8000e080 0x80>;
 			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -485,7 +485,7 @@ gpio3: gpio at 8000e080 {
 		gpio4: gpio at 8000e100 {
 			compatible = "stericsson,db8500-gpio",
 				"st,nomadik-gpio";
-			reg =  <0x8000e100 0x80>;
+			reg = <0x8000e100 0x80>;
 			interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -500,7 +500,7 @@ gpio4: gpio at 8000e100 {
 		gpio5: gpio at 8000e180 {
 			compatible = "stericsson,db8500-gpio",
 				"st,nomadik-gpio";
-			reg =  <0x8000e180 0x80>;
+			reg = <0x8000e180 0x80>;
 			interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -515,7 +515,7 @@ gpio5: gpio at 8000e180 {
 		gpio6: gpio at 8011e000 {
 			compatible = "stericsson,db8500-gpio",
 				"st,nomadik-gpio";
-			reg =  <0x8011e000 0x80>;
+			reg = <0x8011e000 0x80>;
 			interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -530,7 +530,7 @@ gpio6: gpio at 8011e000 {
 		gpio7: gpio at 8011e080 {
 			compatible = "stericsson,db8500-gpio",
 				"st,nomadik-gpio";
-			reg =  <0x8011e080 0x80>;
+			reg = <0x8011e080 0x80>;
 			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -545,7 +545,7 @@ gpio7: gpio at 8011e080 {
 		gpio8: gpio at a03fe000 {
 			compatible = "stericsson,db8500-gpio",
 				"st,nomadik-gpio";
-			reg =  <0xa03fe000 0x80>;
+			reg = <0xa03fe000 0x80>;
 			interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
diff --git a/arch/arm/boot/dts/st/ste-hrefprev60.dtsi b/arch/arm/boot/dts/st/ste-hrefprev60.dtsi
index 9859ee91a15e..c87fd27b4434 100644
--- a/arch/arm/boot/dts/st/ste-hrefprev60.dtsi
+++ b/arch/arm/boot/dts/st/ste-hrefprev60.dtsi
@@ -62,7 +62,7 @@ spi at 80002000 {
 
 		// External Micro SD slot
 		mmc at 80126000 {
-			cd-gpios  = <&tc3589x_gpio 3 GPIO_ACTIVE_HIGH>;
+			cd-gpios = <&tc3589x_gpio 3 GPIO_ACTIVE_HIGH>;
 		};
 
 		pinctrl {
diff --git a/arch/arm/boot/dts/st/ste-hrefv60plus.dtsi b/arch/arm/boot/dts/st/ste-hrefv60plus.dtsi
index e66fa59c2de6..f87f4150ea68 100644
--- a/arch/arm/boot/dts/st/ste-hrefv60plus.dtsi
+++ b/arch/arm/boot/dts/st/ste-hrefv60plus.dtsi
@@ -191,7 +191,7 @@ gpio at 8011e080 {
 
 		// External Micro SD slot
 		mmc at 80126000 {
-			cd-gpios  = <&gpio2 31 GPIO_ACTIVE_HIGH>; // 95
+			cd-gpios = <&gpio2 31 GPIO_ACTIVE_HIGH>; // 95
 		};
 
 		pinctrl {
diff --git a/arch/arm/boot/dts/st/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/st/ste-nomadik-stn8815.dtsi
index 6816eef39d45..4d37c5fb553c 100644
--- a/arch/arm/boot/dts/st/ste-nomadik-stn8815.dtsi
+++ b/arch/arm/boot/dts/st/ste-nomadik-stn8815.dtsi
@@ -52,7 +52,7 @@ mtu1: mtu at 101e3000 {
 
 	gpio0: gpio at 101e4000 {
 		compatible = "st,nomadik-gpio";
-		reg =  <0x101e4000 0x80>;
+		reg = <0x101e4000 0x80>;
 		interrupt-parent = <&vica>;
 		interrupts = <6>;
 		interrupt-controller;
@@ -66,7 +66,7 @@ gpio0: gpio at 101e4000 {
 
 	gpio1: gpio at 101e5000 {
 		compatible = "st,nomadik-gpio";
-		reg =  <0x101e5000 0x80>;
+		reg = <0x101e5000 0x80>;
 		interrupt-parent = <&vica>;
 		interrupts = <7>;
 		interrupt-controller;
@@ -80,7 +80,7 @@ gpio1: gpio at 101e5000 {
 
 	gpio2: gpio at 101e6000 {
 		compatible = "st,nomadik-gpio";
-		reg =  <0x101e6000 0x80>;
+		reg = <0x101e6000 0x80>;
 		interrupt-parent = <&vica>;
 		interrupts = <8>;
 		interrupt-controller;
@@ -94,7 +94,7 @@ gpio2: gpio at 101e6000 {
 
 	gpio3: gpio at 101e7000 {
 		compatible = "st,nomadik-gpio";
-		reg =  <0x101e7000 0x80>;
+		reg = <0x101e7000 0x80>;
 		ngpio = <28>;
 		interrupt-parent = <&vica>;
 		interrupts = <9>;
diff --git a/arch/arm/boot/dts/st/ste-snowball.dts b/arch/arm/boot/dts/st/ste-snowball.dts
index 27c2ec51e732..1322abfc7acf 100644
--- a/arch/arm/boot/dts/st/ste-snowball.dts
+++ b/arch/arm/boot/dts/st/ste-snowball.dts
@@ -266,7 +266,7 @@ mmc at 80126000 {
 			pinctrl-1 = <&mc0_a_1_sleep>;
 
 			/* GPIO218 MMC_CD */
-			cd-gpios  = <&gpio6 26 GPIO_ACTIVE_LOW>;
+			cd-gpios = <&gpio6 26 GPIO_ACTIVE_LOW>;
 
 			status = "okay";
 		};
diff --git a/arch/arm/boot/dts/st/ste-ux500-samsung-codina-tmo.dts b/arch/arm/boot/dts/st/ste-ux500-samsung-codina-tmo.dts
index 463942ae755e..c623cc35c5ea 100644
--- a/arch/arm/boot/dts/st/ste-ux500-samsung-codina-tmo.dts
+++ b/arch/arm/boot/dts/st/ste-ux500-samsung-codina-tmo.dts
@@ -310,7 +310,7 @@ mmc at 80126000 {
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&mc0_a_2_default>;
 			pinctrl-1 = <&mc0_a_2_sleep>;
-			cd-gpios  = <&gpio6 25 GPIO_ACTIVE_LOW>; // GPIO217
+			cd-gpios = <&gpio6 25 GPIO_ACTIVE_LOW>; // GPIO217
 			status = "okay";
 		};
 
diff --git a/arch/arm/boot/dts/st/ste-ux500-samsung-codina.dts b/arch/arm/boot/dts/st/ste-ux500-samsung-codina.dts
index c1ae0e23fe45..2355ca6e9ad6 100644
--- a/arch/arm/boot/dts/st/ste-ux500-samsung-codina.dts
+++ b/arch/arm/boot/dts/st/ste-ux500-samsung-codina.dts
@@ -402,7 +402,7 @@ mmc at 80126000 {
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&mc0_a_2_default>;
 			pinctrl-1 = <&mc0_a_2_sleep>;
-			cd-gpios  = <&gpio6 25 GPIO_ACTIVE_LOW>; // GPIO217
+			cd-gpios = <&gpio6 25 GPIO_ACTIVE_LOW>; // GPIO217
 			status = "okay";
 		};
 
diff --git a/arch/arm/boot/dts/st/ste-ux500-samsung-gavini.dts b/arch/arm/boot/dts/st/ste-ux500-samsung-gavini.dts
index b21e40da3dfd..ad9a20ccaaeb 100644
--- a/arch/arm/boot/dts/st/ste-ux500-samsung-gavini.dts
+++ b/arch/arm/boot/dts/st/ste-ux500-samsung-gavini.dts
@@ -362,7 +362,7 @@ mmc at 80126000 {
 			pinctrl-0 = <&mc0_a_2_default>;
 			pinctrl-1 = <&mc0_a_2_sleep>;
 			/* "flash detect" actually card detect */
-			cd-gpios  = <&gpio6 25 GPIO_ACTIVE_LOW>;
+			cd-gpios = <&gpio6 25 GPIO_ACTIVE_LOW>;
 			status = "okay";
 		};
 
diff --git a/arch/arm/boot/dts/st/ste-ux500-samsung-janice.dts b/arch/arm/boot/dts/st/ste-ux500-samsung-janice.dts
index 6e586e875565..229f7c32103c 100644
--- a/arch/arm/boot/dts/st/ste-ux500-samsung-janice.dts
+++ b/arch/arm/boot/dts/st/ste-ux500-samsung-janice.dts
@@ -412,7 +412,7 @@ mmc at 80126000 {
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&mc0_a_2_default>;
 			pinctrl-1 = <&mc0_a_2_sleep>;
-			cd-gpios  = <&gpio6 25 GPIO_ACTIVE_LOW>; // GPIO217
+			cd-gpios = <&gpio6 25 GPIO_ACTIVE_LOW>; // GPIO217
 			status = "okay";
 		};
 
diff --git a/arch/arm/boot/dts/st/ste-ux500-samsung-kyle.dts b/arch/arm/boot/dts/st/ste-ux500-samsung-kyle.dts
index ba4421080b2a..cdb147dcc1db 100644
--- a/arch/arm/boot/dts/st/ste-ux500-samsung-kyle.dts
+++ b/arch/arm/boot/dts/st/ste-ux500-samsung-kyle.dts
@@ -238,7 +238,7 @@ mmc at 80126000 {
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&mc0_a_1_default>;
 			pinctrl-1 = <&mc0_a_1_sleep>;
-			cd-gpios  = <&gpio6 25 GPIO_ACTIVE_LOW>; // GPIO217
+			cd-gpios = <&gpio6 25 GPIO_ACTIVE_LOW>; // GPIO217
 			status = "okay";
 		};
 

---
base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86
change-id: 20231212-ux500-dts-c5da6ca42a6d

Best regards,
-- 
Linus Walleij <linus.walleij at linaro.org>



From linus.walleij at linaro.org  Mon Dec 11 15:48:33 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 12 Dec 2023 00:48:33 +0100
Subject: [PATCH v5 00/13] pinctrl: Convert struct group_desc to use struct pingroup
In-Reply-To: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
Message-ID: <CACRpkdbbDAph2gUyvPCPD0s6LtjekK8zVBPLMg1ESB_1SMow_A@mail.gmail.com>

On Mon, Dec 11, 2023 at 8:03?PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:

> The struct group_desc has a lot of duplication with struct pingroup.
> Deduplicate that by embeddind the latter in the former and convert
> users.
>
> NB. The function_desc is in plan to follow the similar deduplication.
>
> This time test-compiled with old GCC 8 for arm64, besides GCC 13 and
> LLVM 16 for x86_64.

Applied to my pin control devel branch for v6.8.

Yours,
Linus Walleij


From cw00.choi at samsung.com  Mon Dec 11 15:57:09 2023
From: cw00.choi at samsung.com (Chanwoo Choi)
Date: Tue, 12 Dec 2023 08:57:09 +0900
Subject: [PATCH v7 06/16] dt-bindings: clock: google,gs101: fix
 incorrect numbering and DGB suffix
In-Reply-To: <20231211162331.435900-7-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
	<CGME20231211162506epcas1p290e6adbb82f27ebade65376f298f7fd3@epcas1p2.samsung.com>
	<20231211162331.435900-7-peter.griffin@linaro.org>
Message-ID: <0ecc01da2c8d$c129e490$437dadb0$@samsung.com>



> -----Original Message-----
> From: Peter Griffin <peter.griffin at linaro.org>
> Sent: Tuesday, December 12, 2023 1:23 AM
> To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> will at kernel.org; arnd at arndb.de; olof at lixom.net;
gregkh at linuxfoundation.org;
> jirislaby at kernel.org; cw00.choi at samsung.com; alim.akhtar at samsung.com
> Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
> andre.draszik at linaro.org; semen.protsenko at linaro.org;
saravanak at google.com;
> willmcvicker at google.com; soc at kernel.org; devicetree at vger.kernel.org;
linux-
> arm-kernel at lists.infradead.org; linux-samsung-soc at vger.kernel.org; linux-
> clk at vger.kernel.org; linux-gpio at vger.kernel.org; linux-
> watchdog at vger.kernel.org; kernel-team at android.com; linux-
> serial at vger.kernel.org
> Subject: [PATCH v7 06/16] dt-bindings: clock: google,gs101: fix incorrect
> numbering and DGB suffix
> 
> 166 was skipped by mistake and two clocks:
> * CLK_MOUT_CMU_HSI0_USBDPDGB
> * CLK_GOUT_HSI0_USBDPDGB
> 
> Have an incorrect DGB ending instead of DBG.
> 
> This is an ABI break, but as the patch was only applied yesterday this
header
> has never been in an actual release so it seems better to fix this early
than
> ignore it.
> 
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock
management
> unit bindings")
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  include/dt-bindings/clock/google,gs101.h | 118 +++++++++++------------
>  1 file changed, 59 insertions(+), 59 deletions(-)
> 

(snip)

Reviewed-by: Chanwoo Choi <cw00.choi at samsung.com>

Best Regards,
Chanwoo Choi




From peng.fan at nxp.com  Mon Dec 11 16:40:24 2023
From: peng.fan at nxp.com (Peng Fan)
Date: Tue, 12 Dec 2023 00:40:24 +0000
Subject: [PATCH] clk: imx: scu: Fix memory leak in __imx_clk_gpr_scu()
In-Reply-To: <20231210171907.3410922-1-visitorckw@gmail.com>
References: <20231210171907.3410922-1-visitorckw@gmail.com>
Message-ID: <DU0PR04MB9417FB5A373326F954EB7CC3888EA@DU0PR04MB9417.eurprd04.prod.outlook.com>

> Subject: [PATCH] clk: imx: scu: Fix memory leak in __imx_clk_gpr_scu()
> 
> In cases where imx_clk_is_resource_owned() returns false, the code path does
> not handle the failure gracefully, potentially leading to a memory leak. This
> fix ensures proper cleanup by freeing the allocated memory for 'clk_node'
> before returning.
> 
> Signed-off-by: Kuan-Wei Chiu <visitorckw at gmail.com>

Reviewed-by: Peng Fan <peng.fan at nxp.com>


From andyshrk at 163.com  Mon Dec 11 16:57:10 2023
From: andyshrk at 163.com (Andy Yan)
Date: Tue, 12 Dec 2023 08:57:10 +0800
Subject: [PATCH v2] dt-bindings: iommu: rockchip: Add Rockchip RK3588
Message-ID: <20231212005710.1837066-1-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>

Add a Rockchip RK3588 compatible

I split it from the vop2 patch series as suggested by Heiko[0]

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

[0]https://patchwork.kernel.org/project/dri-devel/patch/20231207080235.652719-1-andyshrk at 163.com/

---

Changes in v2:
- Add maintainers for the iommu subsystem to cc list

 .../devicetree/bindings/iommu/rockchip,iommu.yaml     | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
index ba9124f721f1..621dde0e45d8 100644
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
@@ -19,9 +19,14 @@ description: |+
 
 properties:
   compatible:
-    enum:
-      - rockchip,iommu
-      - rockchip,rk3568-iommu
+    oneOf:
+      - enum:
+          - rockchip,iommu
+          - rockchip,rk3568-iommu
+      - items:
+          - enum:
+              - rockchip,rk3588-iommu
+          - const: rockchip,rk3568-iommu
 
   reg:
     items:
-- 
2.34.1



From andre.przywara at arm.com  Mon Dec 11 17:08:56 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 12 Dec 2023 01:08:56 +0000
Subject: [PATCH 0/3] arm64: dts: allwinner: Add Transpeed 8K618-T TV box
Message-ID: <20231212010859.11571-1-andre.przywara@arm.com>

The Transpeed 8K618-T is one example of various cheap Chinese TV boxes
using the Allwinner H618 SoC. It comes with up to 4GB DRAM and up to
128GB eMMC flash, plus the usual HDMI, 100Mbit Ethernet, WiFi/BT and
dual USB ports, not to forget the mandatory microSD card slot.
More details: https://linux-sunxi.org/Transpeed_8K618-T

Ethernet relies on the yet unsupported integrated PHY, and the HDMI
output is similarly not yet supported, but patches exist that await
polishing for mainline submission.
Meanwhile USB and eMMC plus SD card work, so you can hook up an USB
Ethernet or WiFi adapter to get things going.

This series is the usual trilogy of DT support patches: adding the vendor
name in patch 1, the board compatible name in patch 2, and the actual
.dts file in patch 3.

Please have a look!

Thanks,
Andre

Andre Przywara (3):
  dt-bindings: vendor-prefixes: add Transpeed
  dt-bindings: arm: sunxi: document Transpeed 8K618-T board name
  arm64: dts: allwinner: h618: add Transpeed 8K618-T TV box

 .../devicetree/bindings/arm/sunxi.yaml        |   5 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../sun50i-h618-transpeed-8k618-t.dts         | 164 ++++++++++++++++++
 4 files changed, 172 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts

-- 
2.35.8



From andre.przywara at arm.com  Mon Dec 11 17:08:57 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 12 Dec 2023 01:08:57 +0000
Subject: [PATCH 1/3] dt-bindings: vendor-prefixes: add Transpeed
In-Reply-To: <20231212010859.11571-1-andre.przywara@arm.com>
References: <20231212010859.11571-1-andre.przywara@arm.com>
Message-ID: <20231212010859.11571-2-andre.przywara@arm.com>

This is a name used by some Chinese TV boxes, add it to the bindings.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c84..d9dd3f929cdcf 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1438,6 +1438,8 @@ patternProperties:
     description: Traverse Technologies Australia Pty Ltd
   "^tronfy,.*":
     description: Tronfy
+  "^transpeed,.*":
+    description: Transpeed
   "^tronsmart,.*":
     description: Tronsmart
   "^truly,.*":
-- 
2.35.8



From andre.przywara at arm.com  Mon Dec 11 17:08:58 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 12 Dec 2023 01:08:58 +0000
Subject: [PATCH 2/3] dt-bindings: arm: sunxi: document Transpeed 8K618-T board name
In-Reply-To: <20231212010859.11571-1-andre.przywara@arm.com>
References: <20231212010859.11571-1-andre.przywara@arm.com>
Message-ID: <20231212010859.11571-3-andre.przywara@arm.com>

The Transpeed 8K618-T TV box is a Chinese Android TV box, using the
Allwinner H618 SoC.

Add the board/SoC compatible string pair to the list of known boards.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 11c5ce941dd7e..5e91110cc9eb8 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -868,6 +868,11 @@ properties:
           - const: topwise,a721
           - const: allwinner,sun4i-a10
 
+      - description: Transpeed 8K618-T
+        items:
+          - const: transpeed,8k618-t
+          - const: allwinner,sun50i-h618
+
       - description: Utoo P66
         items:
           - const: utoo,p66
-- 
2.35.8



From andre.przywara at arm.com  Mon Dec 11 17:08:59 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 12 Dec 2023 01:08:59 +0000
Subject: [PATCH 3/3] arm64: dts: allwinner: h618: add Transpeed 8K618-T TV box
In-Reply-To: <20231212010859.11571-1-andre.przywara@arm.com>
References: <20231212010859.11571-1-andre.przywara@arm.com>
Message-ID: <20231212010859.11571-4-andre.przywara@arm.com>

This is a Chinese TV box, probably very similar if not identical to
various other cheap TV boxes with the same specs:
      - Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache)
      - 2 or 4GiB DDR3L DRAM
      - 32, 64, or 128 GiB eMMC flash
      - AXP313a PMIC
      - 100 Mbit/s Ethernet (using yet unsupported internal PHY)
      - HDMI port
      - 2 * USB 2.0 ports
      - microSD card slot
      - 3.5mm A/V port
      - 7-segment display
      - 5V barrel plug power supply

The PCB provides holes for soldering a UART header or cable, this is
connected to the debug UART0. UART1 is used for the Bluetooth chip,
although this isn't working yet.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../sun50i-h618-transpeed-8k618-t.dts         | 164 ++++++++++++++++++
 2 files changed, 165 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 3aca6787a1679..91d505b385de5 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -43,3 +43,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero3.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-transpeed-8k618-t.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
new file mode 100644
index 0000000000000..fd7ea7bcde2c1
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2023 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Transpeed 8K618-T";
+	compatible = "transpeed,8k618-t", "allwinner,sun50i-h618";
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	reg_vcc5v: vcc5v {
+		/* board wide 5V supply directly from the DC input */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-5v";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	reg_vcc3v3: vcc3v3 {
+		/* discrete 3.3V regulator */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&ir {
+	status = "okay";
+};
+
+&mmc0 {
+	vmmc-supply = <&reg_dldo1>;
+	cd-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>;	/* PI16 */
+	bus-width = <4>;
+	status = "okay";
+};
+
+&mmc2 {
+	vmmc-supply = <&reg_dldo1>;
+	vqmmc-supply = <&reg_aldo1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	mmc-ddr-1_8v;
+	mmc-hs200-1_8v;
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&r_i2c {
+	status = "okay";
+
+	axp313: pmic at 36 {
+		compatible = "x-powers,axp313a";
+		reg = <0x36>;
+		#interrupt-cells = <1>;
+		interrupt-controller;
+
+		vin1-supply = <&reg_vcc5v>;
+		vin2-supply = <&reg_vcc5v>;
+		vin3-supply = <&reg_vcc5v>;
+
+		regulators {
+			/* Supplies VCC-PLL, so needs to be always on. */
+			reg_aldo1: aldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8";
+			};
+
+			/* Supplies VCC-IO, so needs to be always on. */
+			reg_dldo1: dldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc3v3";
+			};
+
+			reg_dcdc1: dcdc1 {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <990000>;
+				regulator-name = "vdd-gpu-sys";
+			};
+
+			reg_dcdc2: dcdc2 {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-cpu";
+			};
+
+			reg_dcdc3: dcdc3 {
+				regulator-always-on;
+				regulator-min-microvolt = <1360000>;
+				regulator-max-microvolt = <1360000>;
+				regulator-name = "vdd-dram";
+			};
+		};
+	};
+};
+
+&pio {
+	vcc-pc-supply = <&reg_aldo1>;
+	vcc-pg-supply = <&reg_dldo1>;
+	vcc-ph-supply = <&reg_dldo1>;
+	vcc-pi-supply = <&reg_dldo1>;
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_ph_pins>;
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&usbotg {
+	dr_mode = "host";	/* USB A type receptable */
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+};
-- 
2.35.8



From jisheng.teoh at starfivetech.com  Mon Dec 11 17:55:38 2023
From: jisheng.teoh at starfivetech.com (Ji Sheng Teoh)
Date: Tue, 12 Dec 2023 09:55:38 +0800
Subject: [PATCH v4 1/2] perf: starfive: Add StarLink PMU support
In-Reply-To: <CAL_Jsq+AMbwR64YwtugJ=WC-No0eBUejf3v4YbSB8h7x+uf3wA@mail.gmail.com>
References: <CAL_Jsq+AMbwR64YwtugJ=WC-No0eBUejf3v4YbSB8h7x+uf3wA@mail.gmail.com>
Message-ID: <20231212015538.2310705-1-jisheng.teoh@starfivetech.com>

On Mon, 11 Dec 2023 11:54:25 -0600
Rob Herring <robh+dt at kernel.org> wrote:

> On Thu, Nov 16, 2023 at 10:24?AM Ji Sheng Teoh
> <jisheng.teoh at starfivetech.com> wrote:
> >
> > This patch adds support for StarFive's StarLink PMU (Performance
> > Monitor Unit). StarLink PMU integrates one or more CPU cores with
> > a shared L3 memory system. The PMU supports overflow interrupt,
> > up to 16 programmable 64bit event counters, and an independent
> > 64bit cycle counter. StarLink PMU is accessed via MMIO.
> >
> > Example Perf stat output:
> > [root at user]# perf stat -a -e /starfive_starlink_pmu/cycles/ \
> >         -e /starfive_starlink_pmu/read_miss/ \
> >         -e /starfive_starlink_pmu/read_hit/ \
> >         -e /starfive_starlink_pmu/release_request/  \
> >         -e /starfive_starlink_pmu/write_hit/ \
> >         -e /starfive_starlink_pmu/write_miss/ \
> >         -e /starfive_starlink_pmu/write_request/ \
> >         -e /starfive_starlink_pmu/writeback/ \
> >         -e /starfive_starlink_pmu/read_request/ \
> >         -- openssl speed rsa2048
> > Doing 2048 bits private rsa's for 10s: 5 2048 bits private RSA's in
> > 2.84s
> > Doing 2048 bits public rsa's for 10s: 169 2048 bits public RSA's in
> > 2.42s
> > version: 3.0.11
> > built on: Tue Sep 19 13:02:31 2023 UTC
> > options: bn(64,64)
> > CPUINFO: N/A
> >                   sign    verify    sign/s verify/s
> > rsa 2048 bits 0.568000s 0.014320s      1.8     69.8
> > /////////
> >  Performance counter stats for 'system wide':
> >
> >          649991998      starfive_starlink_pmu/cycles/
> >            1009690      starfive_starlink_pmu/read_miss/
> >            1079750      starfive_starlink_pmu/read_hit/
> >            2089405      starfive_starlink_pmu/release_request/
> >                129      starfive_starlink_pmu/write_hit/
> >                 70      starfive_starlink_pmu/write_miss/
> >                194      starfive_starlink_pmu/write_request/
> >             150080      starfive_starlink_pmu/writeback/
> >            2089423      starfive_starlink_pmu/read_request/
> >
> >       27.062755678 seconds time elapsed
> >
> > Signed-off-by: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
> > ---
> >  drivers/perf/Kconfig                 |   9 +
> >  drivers/perf/Makefile                |   1 +
> >  drivers/perf/starfive_starlink_pmu.c | 654
> > +++++++++++++++++++++++++++ include/linux/cpuhotplug.h           |
> >  1 + 4 files changed, 665 insertions(+)
> >  create mode 100644 drivers/perf/starfive_starlink_pmu.c
> >
> > diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
> > index 273d67ecf6d2..41278742ef88 100644
> > --- a/drivers/perf/Kconfig
> > +++ b/drivers/perf/Kconfig
> > @@ -86,6 +86,15 @@ config RISCV_PMU_SBI
> >           full perf feature support i.e. counter overflow,
> > privilege mode filtering, counter configuration.
> >
> > +config STARFIVE_STARLINK_PMU
> > +       depends on ARCH_STARFIVE
> > +       bool "StarFive StarLink PMU"
> > +       help
> > +          Provide support for StarLink Performance Monitor Unit.
> > +          StarLink Performance Monitor Unit integrates one or more
> > cores with
> > +          an L3 memory system. The L3 cache events are added into
> > perf event
> > +          subsystem, allowing monitoring of various L3 cache perf
> > events. +
> >  config ARM_PMU_ACPI
> >         depends on ARM_PMU && ACPI
> >         def_bool y
> > diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
> > index 16b3ec4db916..e2153aee1e04 100644
> > --- a/drivers/perf/Makefile
> > +++ b/drivers/perf/Makefile
> > @@ -15,6 +15,7 @@ obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
> >  obj-$(CONFIG_RISCV_PMU) += riscv_pmu.o
> >  obj-$(CONFIG_RISCV_PMU_LEGACY) += riscv_pmu_legacy.o
> >  obj-$(CONFIG_RISCV_PMU_SBI) += riscv_pmu_sbi.o
> > +obj-$(CONFIG_STARFIVE_STARLINK_PMU) += starfive_starlink_pmu.o
> >  obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
> >  obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
> >  obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
> > diff --git a/drivers/perf/starfive_starlink_pmu.c
> > b/drivers/perf/starfive_starlink_pmu.c new file mode 100644
> > index 000000000000..272896ab1ade
> > --- /dev/null
> > +++ b/drivers/perf/starfive_starlink_pmu.c
> > @@ -0,0 +1,654 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * StarFive's StarLink PMU driver
> > + *
> > + * Copyright (C) 2023 StarFive Technology Co., Ltd.
> > + *
> > + * Author: Ji Sheng Teoh <jisheng.teoh at starfivetech.com>
> > + *
> > + */
> > +
> > +#define STARLINK_PMU_PDEV_NAME "starfive_starlink_pmu"
> > +#define pr_fmt(fmt)    STARLINK_PMU_PDEV_NAME ": " fmt
> > +
> > +#include <linux/bitmap.h>
> > +#include <linux/cpu_pm.h>
> > +#include <linux/io.h>
> > +#include <linux/irq.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>  
> 
> You probably don't need this header and the implicit includes it makes
> are dropped now in linux-next. Please check what you actually need and
> make them explicit.
> 
> Rob

Thanks Rob, this has changed to '#include <linux/mod_devicetable.h>' in
v5 submitted recently.
https://lore.kernel.org/lkml/20231207142940.1794032-1-jisheng.teoh at starfivetech.com/T/#Z2e.:..:20231207142940.1794032-2-jisheng.teoh::40starfivetech.com:1drivers:perf:starfive_starlink_pmu.c



From quic_johmoo at quicinc.com  Mon Dec 11 18:02:56 2023
From: quic_johmoo at quicinc.com (John Moon)
Date: Mon, 11 Dec 2023 18:02:56 -0800
Subject: [PATCH v7 0/3]  Validating UAPI backwards compatibility
Message-ID: <20231212020259.2451253-1-quic_johmoo@quicinc.com>

The kernel community has rigorously enforced a policy of backwards
compatibility in its userspace interfaces for a long time. This has
allowed user applications to enjoy stability across kernel upgrades
without recompiling. Our goal is to add tooling and documentation to
help kernel developers maintain this stability.

In terms of tooling, I've attached a couple of shell scripts we've been
internally to validate backwards compatibility of our UAPI headers.

The check-uapi.sh script uses libabigail's[1] tool abidiff[2] to compare a
modified header's ABI before and after a patch is applied. If an existing
UAPI is modified in a way that's not backwards compatibile, the script
exits non-zero. We use this script in our continuous integration system
to block changes that fail the check.

It generates output like this when a backwards incompatible change is
made to a UAPI header:

ABI differences detected in include/uapi/linux/bpf.h from HEAD~1 -> HEAD
    [C] 'struct bpf_insn' changed:
      type size hasn't changed
      2 data member changes:
        '__u8 dst_reg' offset changed from 8 to 12 (in bits) (by +4 bits)
        '__u8 src_reg' offset changed from 12 to 8 (in bits) (by -4 bits)

The check-module-params.sh script is quite a bit simpler. It basically
greps for module_param.* calls and compares their arguments before/after
a change is applied.

We wanted to share these scripts with the community and hopefully also
receive general feedback when it comes to tooling/policy surrounding
UAPI stability.

Since v6 of this patch, I also presented a talk at LPC[4] on this topic
in case anyone would like to review that. I've CC'd a few attendees who
participated in discussion during the presentation.

Previous discussion on v6 of this patch can be found here[5].

[1] https://sourceware.org/libabigail/manual/libabigail-overview.html
[2] https://sourceware.org/libabigail/manual/abidiff.html
[3] http://mirrors.kernel.org/sourceware/libabigail/libabigail-2.4.tar.xz
[4] https://www.youtube.com/watch?v=4ijcLgvmcek
[5] https://lore.kernel.org/all/20231027193016.27516-1-quic_johmoo at quicinc.com/T/#t

P.S. While at Qualcomm, Jordan Crouse <jorcrous at amazon.com> authored the
original version of the UAPI checker script. Thanks Jordan!

John Moon (3):
  check-uapi: Introduce check-uapi.sh
  docs: dev-tools: Add UAPI checker documentation
  check-module-params: Introduce check-module-params.sh

 Documentation/dev-tools/checkuapi.rst | 477 +++++++++++++++++++++
 Documentation/dev-tools/index.rst     |   1 +
 scripts/check-module-params.sh        | 371 +++++++++++++++++
 scripts/check-uapi.sh                 | 573 ++++++++++++++++++++++++++
 4 files changed, 1422 insertions(+)
 create mode 100644 Documentation/dev-tools/checkuapi.rst
 create mode 100755 scripts/check-module-params.sh
 create mode 100755 scripts/check-uapi.sh


base-commit: a39b6ac3781d46ba18193c9dbb2110f31e9bffe9
--
2.34.1



From quic_johmoo at quicinc.com  Mon Dec 11 18:02:59 2023
From: quic_johmoo at quicinc.com (John Moon)
Date: Mon, 11 Dec 2023 18:02:59 -0800
Subject: [PATCH v7 3/3] check-module-params: Introduce check-module-params.sh
In-Reply-To: <20231212020259.2451253-1-quic_johmoo@quicinc.com>
References: <20231212020259.2451253-1-quic_johmoo@quicinc.com>
Message-ID: <20231212020259.2451253-4-quic_johmoo@quicinc.com>

One part of maintaining backwards compatibility with older
userspace programs is avoiding changes to module parameters.

To that end, add a script (check-module-params.sh) which
performs a simple check of module parameter changes across
git references.

For example, if this module parameter:

module_param(max_nullfunc_tries, int, 0644);

...restricted its mode parameter:

module_param(max_nullfunc_tries, int, 0600);

The script would flag the change:

Module parameter "max_nullfunc_tries" in net/mac80211/mlme.c changed!
  Original args: int,0644
       New args: int,0600

Signed-off-by: John Moon <quic_johmoo at quicinc.com>
---
    - Added ability to filter out equivalent permission changes
      (e.g. S_IRUGO -> 0444 is now considered compatible).
    - Added flag to avoid filtering out equivalent permission changes
      in case user doesn't have/want a host compiler.
    - Added flag to skip flagging module param removals as this may
      be too noisy in some cases.
    - Fixed typos in log naming.

 scripts/check-module-params.sh | 371 +++++++++++++++++++++++++++++++++
 1 file changed, 371 insertions(+)
 create mode 100755 scripts/check-module-params.sh

diff --git a/scripts/check-module-params.sh b/scripts/check-module-params.sh
new file mode 100755
index 000000000000..990b271a8dbf
--- /dev/null
+++ b/scripts/check-module-params.sh
@@ -0,0 +1,371 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-only
+# Script to check commits for UAPI backwards compatibility
+
+set -o errexit
+set -o pipefail
+
+print_usage() {
+	name=$(basename "$0")
+	cat << EOF
+$name - check for module parameter stability across git commits.
+
+By default, the script will check to make sure the latest commit (or current
+dirty changes) did not introduce changes when compared to HEAD^1. You can
+check against additional commit ranges with the -b and -p options.
+
+Usage: $name [-b BASE_REF] [-p PAST_REF] [-j N] [-l ERROR_LOG] [-P] [-R] [-q]
+
+Options:
+    -b BASE_REF    Base git reference to use for comparison. If unspecified or empty,
+                   will use any dirty changes in tree. If there are no dirty changes,
+                   HEAD will be used.
+    -p PAST_REF    Compare BASE_REF to PAST_REF (e.g. -p v6.1). If unspecified or empty,
+                   will use BASE_REF^1. Must be an ancestor of BASE_REF. Only headers
+                   that exist on PAST_REF will be checked for compatibility.
+    -j JOBS        Number of checks to run in parallel (default: number of CPU cores).
+    -l ERROR_LOG   Write error log to file (default: no error log is generated).
+    -P             Flag all changes to permissions (even if they're compatible). This
+                   option negates the need for a host C compiler.
+    -R             Skip flagging parameter removals.
+    -q             Quiet operation (suppress stdout, still print stderr).
+
+Environmental args:
+    HOSTCC   C compiler for permission conversion to octal (default is "gcc")
+
+Exit codes:
+    $SUCCESS) Success
+    $FAILURE) Module param differences detected
+EOF
+}
+
+readonly SUCCESS=0
+readonly FAILURE=1
+
+# Print to stderr
+eprintf() {
+	# shellcheck disable=SC2059
+	printf "$@" >&2
+}
+
+# Check if git tree is dirty
+tree_is_dirty() {
+	! git diff --quiet
+}
+
+file_module_params_unmodified() {
+	local file="$1"
+	local base_ref="$2"
+	local past_ref="$3"
+	local base_params_file="${TMP_DIR}/${file}.base"
+	local past_params_file="${TMP_DIR}/${file}.past"
+	local error_log="${TMP_DIR}/${file}.error"
+
+	local -r awk_cmd='/^ *module_param.*\(/,/.*\);/'
+
+	mkdir -p "$(dirname "$error_log")"
+	git show "${past_ref}:${file}" 2> /dev/null \
+		| awk "$awk_cmd" > "$past_params_file" || true
+
+	if [ -z "$base_ref" ]; then
+		awk "$awk_cmd" "${KERNEL_SRC}/${file}" \
+			> "$base_params_file" 2> /dev/null || true
+	else
+		git show "${base_ref}:${file}" 2> /dev/null \
+			| awk "$awk_cmd" > "$base_params_file" || true
+	fi
+
+	# Ignore files that don't exist at the past ref or don't have module params
+	if [ ! -s "$past_params_file" ]; then
+		return 255 # Special return code for "no-op"
+	fi
+
+	# Process the param data to come up with an associative array of param names to param data
+	# For example:
+	#   module_param_call(foo, set_result, get_result, NULL, 0600);
+	#
+	# is processed into:
+	#   pre_change_params[foo]="set_result,get_result,NULL,0600"
+	local -A pre_change_params
+	local param_name
+	local param_params
+
+	while read -r mod_param_args; do
+		param_name="$(echo "$mod_param_args" | cut -d ',' -f 1)"
+		param_params="$(echo "$mod_param_args" | cut -d ',' -f 2-)"
+
+		pre_change_params[$param_name]=$param_params
+	done < <(tr -d '\t\n ' < "$past_params_file" | tr ';' '\n' | perl -lne '/\((.*)\)/ && print $1')
+
+	local -A post_change_params
+	while read -r mod_param_args; do
+		param_name="$(echo "$mod_param_args" | cut -d ',' -f 1)"
+		param_params="$(echo "$mod_param_args" | cut -d ',' -f 2-)"
+
+		post_change_params[$param_name]=$param_params
+	done < <(tr -d '\t\n ' < "$base_params_file" | tr ';' '\n' | perl -lne '/\((.*)\)/ && print $1')
+
+	#for param in "${!pre_change_params[@]}"; do
+	#	echo "$param: ${pre_change_params[${param}]}"
+	#done
+
+	# Flag any module param changes that:
+	#  - Remove/rename a parameter
+	#  - Change the arguments of the parameter
+	local incompat_param_changes=0
+	local pre
+	local post
+	for param_name in "${!pre_change_params[@]}"; do
+		pre="${pre_change_params[$param_name]}"
+		if [ ! "${post_change_params[$param_name]+set}" ]; then
+			if [ "$SKIP_PARAM_REMOVALS" = "true" ]; then
+				continue
+			fi
+			{
+				printf "Module parameter \"%s\" in %s removed!\n" "$param_name" "$file"
+				printf "  Original args: %s\n" "$pre"
+			} > "$error_log"
+			incompat_param_changes=$((incompat_param_changes + 1))
+			continue
+		fi
+
+		post="${post_change_params[$param_name]}"
+		if [ "$pre" != "$post" ]; then
+			if [ "$SKIP_SAFE_PERM_CHANGES" = "true" ] && perm_change_is_safe "$pre" "$post"; then
+				continue
+			fi
+			{
+				printf "Module parameter \"%s\" in %s changed!\n" "$param_name" "$file"
+				printf "  Original args: %s\n" "$pre"
+				printf "       New args: %s\n" "$post"
+			} > "$error_log"
+			incompat_param_changes=$((incompat_param_changes + 1))
+			continue
+		fi
+	done
+
+	if [ "$incompat_param_changes" -gt 0 ]; then
+		return 1
+	fi
+}
+
+perm_change_is_safe() {
+	local -r pre="$1"
+	local -r post="$2"
+
+	# Assume that the permission arg is always the last one.
+	pre_perm_arg=$(echo "$pre" | grep -o '[^,]*$')
+	post_perm_arg=$(echo "$post" | grep -o '[^,]*$')
+
+	# If the non-permission arguments are different, then
+	# don't even bother checking the permission arg.
+	if [ "${pre/,${pre_perm_arg}/}" != "${post/,${post_perm_arg}/}" ]; then
+		return 1
+	fi
+
+	# Convert both to octal representation to compare
+	pre_perm_arg_octal=$(get_octal_val "$pre_perm_arg")
+	post_perm_arg_octal=$(get_octal_val "$post_perm_arg")
+
+	if [ "$pre_perm_arg_octal" = "$post_perm_arg_octal" ]; then
+		return 0
+	else
+		return 1
+	fi
+}
+
+get_octal_val() {
+	local -r input="$1"
+
+	# Save needing to recompile for input we've seen before
+	local -r input_hash="$(echo "$input" | md5sum | cut -d ' ' -f 1)"
+
+	local -r prog="${TMP_DIR}/get_octal_val_${input_hash}"
+	local -r stat="include/linux/stat.h"
+
+	if [ ! -x "$prog" ]; then
+		cat << EOF > "${prog}.c"
+#include <stdio.h>
+#include <sys/stat.h>
+
+$(grep '#define *S_IRWXUGO' "$stat")
+$(grep '#define *S_IALLUGO' "$stat")
+$(grep '#define *S_IRUGO' "$stat")
+$(grep '#define *S_IWUGO' "$stat")
+$(grep '#define *S_IXUGO' "$stat")
+
+int main(void) { printf("%04o\\n", $input); };
+EOF
+		"${HOSTCC:-gcc}" -o "$prog" "${prog}.c"
+	fi
+
+	"$prog"
+}
+run() {
+	local base_ref="$1"
+	local past_ref="$2"
+	local param_error_log="$3"
+
+	diff_args=("$past_ref")
+	if [ -n "$base_ref" ]; then
+		diff_args+=("$base_ref")
+	fi
+
+	local -a threads=()
+	local passed=0
+	local failed=0
+	printf "Checking files between %s and %s for module parameter compatibility...\n" \
+		"$past_ref" "$base_ref"
+	while read -r modified_file; do
+		if [ "${#threads[@]}" -ge "$MAX_THREADS" ]; then
+			wait "${threads[0]}" && ret="$?" || ret="$?"
+			if [ "$ret" -eq 0 ]; then
+				passed=$((passed + 1))
+			elif [ "$ret" -eq 1 ]; then
+				failed=$((failed + 1))
+			fi
+			threads=("${threads[@]:1}")
+		fi
+
+		file_module_params_unmodified "$modified_file" "$base_ref" "$past_ref" &
+		threads+=("$!")
+	done < <(git diff --diff-filter=MCD --name-only "${diff_args[@]}" -- '*.c' '*.h')
+
+	for t in "${threads[@]}"; do
+		wait "$t" && ret="$?" || ret="$?"
+		if [ "$ret" -eq 0 ]; then
+			passed=$((passed + 1))
+		elif [ "$ret" -eq 1 ]; then
+			failed=$((failed + 1))
+		fi
+	done
+
+	total=$((passed + failed))
+	if [ "$total" -eq 0 ]; then
+		printf "No files with module parameters modified between %s and %s\n" \
+			"$past_ref" "${base_ref:-dirty tree}"
+		exit "$SUCCESS"
+	fi
+
+	if [ -n "$param_error_log" ]; then
+		printf 'Generated by "%s %s" from git ref %s\n\n' \
+			"$0" "$*" "$(git rev-parse HEAD)" > "$param_error_log"
+	fi
+
+	while read -r error_file; do
+		{
+			cat "$error_file"
+			printf "\n\n"
+		} | tee -a "${param_error_log:-/dev/null}" >&2
+	done < <(find "$TMP_DIR" -type f -name '*.error' | sort)
+
+	if [ "$failed" -gt 0 ]; then
+		eprintf "error - %d/%d files with modules parameters appear _not_ to be backwards compatible\n" \
+			"$failed" "$total"
+		if [ -n "$param_error_log" ]; then
+			eprintf "Failure summary saved to %s\n" "$param_error_log"
+		fi
+	else
+		printf "All %d files with module_parameters checked appear to be backwards compatible\n" \
+			"$total"
+	fi
+
+	exit "$failed"
+}
+
+# Make sure the git refs we have make sense
+check_refs() {
+	if ! git rev-parse --is-inside-work-tree > /dev/null 2>&1; then
+		eprintf "error - this script requires the kernel tree to be initialized with Git\n"
+		return 1
+	fi
+
+	if ! git rev-parse --verify "$past_ref" > /dev/null 2>&1; then
+		printf 'error - invalid git reference "%s"\n' "$past_ref"
+		return 1
+	fi
+
+	if [ -n "$base_ref" ]; then
+		if ! git merge-base --is-ancestor "$past_ref" "$base_ref" > /dev/null 2>&1; then
+			printf 'error - "%s" is not an ancestor of base ref "%s"\n' "$past_ref" "$base_ref"
+			return 1
+		fi
+		if [ "$(git rev-parse "$base_ref")" = "$(git rev-parse "$past_ref")" ]; then
+			printf 'error - "%s" and "%s" are the same reference\n' "$past_ref" "$base_ref"
+			return 1
+		fi
+	fi
+}
+
+main() {
+	MAX_THREADS=$(nproc)
+	SKIP_SAFE_PERM_CHANGES="true"
+	SKIP_PARAM_REMOVALS="false"
+	quiet="false"
+	local base_ref=""
+	while getopts "hb:p:j:l:PRq" opt; do
+		case $opt in
+		h)
+			print_usage
+			exit "$SUCCESS"
+			;;
+		b)
+			base_ref="$OPTARG"
+			;;
+		p)
+			past_ref="$OPTARG"
+			;;
+		j)
+			MAX_THREADS="$OPTARG"
+			;;
+		l)
+			param_error_log="$OPTARG"
+			;;
+		P)
+			SKIP_SAFE_PERM_CHANGES="false"
+			;;
+		R)
+			SKIP_PARAM_REMOVALS="true"
+			;;
+		q)
+			quiet="true"
+			;;
+		*)
+			exit "$FAILURE"
+		esac
+	done
+
+	if [ "$quiet" = "true" ]; then
+		exec > /dev/null 2>&1
+	fi
+
+	if [ -z "$KERNEL_SRC" ]; then
+		KERNEL_SRC="$(realpath "$(dirname "$0")"/..)"
+	fi
+
+	cd "$KERNEL_SRC"
+
+	if [ -z "$base_ref" ] && ! tree_is_dirty; then
+		base_ref=HEAD
+	fi
+
+	if [ -z "$past_ref" ]; then
+		if [ -n "$base_ref" ]; then
+			past_ref="${base_ref}^1"
+		else
+			past_ref=HEAD
+		fi
+	fi
+
+	if ! check_refs; then
+		exit "$FAILURE"
+	fi
+
+	TMP_DIR=$(mktemp -d)
+	readonly TMP_DIR
+	trap 'rm -rf "$TMP_DIR"' EXIT
+
+	run "$base_ref" "$past_ref" "$param_error_log"
+}
+
+main "$@"
--
2.34.1



From quic_johmoo at quicinc.com  Mon Dec 11 18:02:57 2023
From: quic_johmoo at quicinc.com (John Moon)
Date: Mon, 11 Dec 2023 18:02:57 -0800
Subject: [PATCH v7 1/3] check-uapi: Introduce check-uapi.sh
In-Reply-To: <20231212020259.2451253-1-quic_johmoo@quicinc.com>
References: <20231212020259.2451253-1-quic_johmoo@quicinc.com>
Message-ID: <20231212020259.2451253-2-quic_johmoo@quicinc.com>

While the kernel community has been good at maintaining backwards
compatibility with kernel UAPIs, it would be helpful to have a tool
to check if a commit introduces changes that break backwards
compatibility.

To that end, introduce check-uapi.sh: a simple shell script that
checks for changes to UAPI headers using libabigail.

libabigail is "a framework which aims at helping developers and
software distributors to spot some ABI-related issues like interface
incompatibility in ELF shared libraries by performing a static
analysis of the ELF binaries at hand."

The script uses one of libabigail's tools, "abidiff", to compile the
changed header before and after the commit to detect any changes.

abidiff "compares the ABI of two shared libraries in ELF format. It
emits a meaningful report describing the differences between the two
ABIs."

The script also includes the ability to check the compatibility of
all UAPI headers across commits. This allows developers to inspect
the stability of the UAPIs over time.

Signed-off-by: John Moon <quic_johmoo at quicinc.com>
---
    - Applied minor code style suggestions from v6 review.

 scripts/check-uapi.sh | 573 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 573 insertions(+)
 create mode 100755 scripts/check-uapi.sh

diff --git a/scripts/check-uapi.sh b/scripts/check-uapi.sh
new file mode 100755
index 000000000000..876cb0543b7e
--- /dev/null
+++ b/scripts/check-uapi.sh
@@ -0,0 +1,573 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-only
+# Script to check commits for UAPI backwards compatibility
+
+set -o errexit
+set -o pipefail
+
+print_usage() {
+	name=$(basename "$0")
+	cat << EOF
+$name - check for UAPI header stability across Git commits
+
+By default, the script will check to make sure the latest commit (or current
+dirty changes) did not introduce ABI changes when compared to HEAD^1. You can
+check against additional commit ranges with the -b and -p options.
+
+The script will not check UAPI headers for architectures other than the one
+defined in ARCH.
+
+Usage: $name [-b BASE_REF] [-p PAST_REF] [-j N] [-l ERROR_LOG] [-i] [-q] [-v]
+
+Options:
+    -b BASE_REF    Base git reference to use for comparison. If unspecified or empty,
+                   will use any dirty changes in tree to UAPI files. If there are no
+                   dirty changes, HEAD will be used.
+    -p PAST_REF    Compare BASE_REF to PAST_REF (e.g. -p v6.1). If unspecified or empty,
+                   will use BASE_REF^1. Must be an ancestor of BASE_REF. Only headers
+                   that exist on PAST_REF will be checked for compatibility.
+    -j JOBS        Number of checks to run in parallel (default: number of CPU cores).
+    -l ERROR_LOG   Write error log to file (default: no error log is generated).
+    -i             Ignore ambiguous changes that may or may not break UAPI compatibility.
+    -q             Quiet operation.
+    -v             Verbose operation (print more information about each header being checked).
+
+Environmental args:
+    ABIDIFF  Custom path to abidiff binary
+    CC       C compiler (default is "gcc")
+    ARCH     Target architecture for the UAPI check (default is host arch)
+
+Exit codes:
+    $SUCCESS) Success
+    $FAIL_ABI) ABI difference detected
+    $FAIL_PREREQ) Prerequisite not met
+EOF
+}
+
+readonly SUCCESS=0
+readonly FAIL_ABI=1
+readonly FAIL_PREREQ=2
+
+# Print to stderr
+eprintf() {
+	# shellcheck disable=SC2059
+	printf "$@" >&2
+}
+
+# Expand an array with a specific character (similar to Python string.join())
+join() {
+	local IFS="$1"
+	shift
+	printf "%s" "$*"
+}
+
+# Create abidiff suppressions
+gen_suppressions() {
+	# Common enum variant names which we don't want to worry about
+	# being shifted when new variants are added.
+	local -a enum_regex=(
+		".*_AFTER_LAST$"
+		".*_CNT$"
+		".*_COUNT$"
+		".*_END$"
+		".*_LAST$"
+		".*_MASK$"
+		".*_MAX$"
+		".*_MAX_BIT$"
+		".*_MAX_BPF_ATTACH_TYPE$"
+		".*_MAX_ID$"
+		".*_MAX_SHIFT$"
+		".*_NBITS$"
+		".*_NETDEV_NUMHOOKS$"
+		".*_NFT_META_IIFTYPE$"
+		".*_NL80211_ATTR$"
+		".*_NLDEV_NUM_OPS$"
+		".*_NUM$"
+		".*_NUM_ELEMS$"
+		".*_NUM_IRQS$"
+		".*_SIZE$"
+		".*_TLSMAX$"
+		"^MAX_.*"
+		"^NUM_.*"
+	)
+
+	# Common padding field names which can be expanded into
+	# without worrying about users.
+	local -a padding_regex=(
+		".*end$"
+		".*pad$"
+		".*pad[0-9]?$"
+		".*pad_[0-9]?$"
+		".*padding$"
+		".*padding[0-9]?$"
+		".*padding_[0-9]?$"
+		".*res$"
+		".*resv$"
+		".*resv[0-9]?$"
+		".*resv_[0-9]?$"
+		".*reserved$"
+		".*reserved[0-9]?$"
+		".*reserved_[0-9]?$"
+		".*rsvd[0-9]?$"
+		".*unused$"
+	)
+
+	cat << EOF
+[suppress_type]
+  type_kind = enum
+  changed_enumerators_regexp = $(join , "${enum_regex[@]}")
+EOF
+
+	for p in "${padding_regex[@]}"; do
+		cat << EOF
+[suppress_type]
+  type_kind = struct
+  has_data_member_inserted_at = offset_of_first_data_member_regexp(${p})
+EOF
+	done
+
+if [ "$IGNORE_AMBIGUOUS_CHANGES" = "true" ]; then
+	cat << EOF
+[suppress_type]
+  type_kind = struct
+  has_data_member_inserted_at = end
+  has_size_change = yes
+EOF
+fi
+}
+
+# Check if git tree is dirty
+tree_is_dirty() {
+	! git diff --quiet
+}
+
+# Get list of files installed in $ref
+get_file_list() {
+	local -r ref="$1"
+	local -r tree="$(get_header_tree "$ref")"
+
+	# Print all installed headers, filtering out ones that can't be compiled
+	find "$tree" -type f -name '*.h' -printf '%P\n' | grep -v -f "$INCOMPAT_LIST"
+}
+
+# Add to the list of incompatible headers
+add_to_incompat_list() {
+	local -r ref="$1"
+
+	# Start with the usr/include/Makefile to get a list of the headers
+	# that don't compile using this method.
+	if [ ! -f usr/include/Makefile ]; then
+		eprintf "error - no usr/include/Makefile present at %s\n" "$ref"
+		eprintf "Note: usr/include/Makefile was added in the v5.3 kernel release\n"
+		exit "$FAIL_PREREQ"
+	fi
+	{
+		# shellcheck disable=SC2016
+		printf 'all: ; @echo $(no-header-test)\n'
+		cat usr/include/Makefile
+	} | SRCARCH="$ARCH" make --always-make -f - | tr " " "\n" \
+	  | grep -v "asm-generic" >> "$INCOMPAT_LIST"
+
+	# The makefile also skips all asm-generic files, but prints "asm-generic/%"
+	# which won't work for our grep match. Instead, print something grep will match.
+	printf "asm-generic/.*\.h\n" >> "$INCOMPAT_LIST"
+}
+
+# Compile the simple test app
+do_compile() {
+	local -r inc_dir="$1"
+	local -r header="$2"
+	local -r out="$3"
+	printf "int main(void) { return 0; }\n" | \
+		"$CC" -c \
+		  -o "$out" \
+		  -x c \
+		  -O0 \
+		  -std=c90 \
+		  -fno-eliminate-unused-debug-types \
+		  -g \
+		  "-I${inc_dir}" \
+		  -include "$header" \
+		  -
+}
+
+# Run make headers_install
+run_make_headers_install() {
+	local -r ref="$1"
+        local -r install_dir="$(get_header_tree "$ref")"
+	make -j "$MAX_THREADS" ARCH="$ARCH" INSTALL_HDR_PATH="$install_dir" \
+		headers_install > /dev/null
+}
+
+# Install headers for both git refs
+install_headers() {
+	local -r base_ref="$1"
+	local -r past_ref="$2"
+
+	for ref in "$base_ref" "$past_ref"; do
+		printf "Installing user-facing UAPI headers from %s... " "${ref:-dirty tree}"
+		if [ -n "$ref" ]; then
+			git archive --format=tar --prefix="${ref}-archive/" "$ref" \
+				| (cd "$TMP_DIR" && tar xf -)
+			(
+				cd "${TMP_DIR}/${ref}-archive"
+				run_make_headers_install "$ref"
+				add_to_incompat_list "$ref" "$INCOMPAT_LIST"
+			)
+		else
+			run_make_headers_install "$ref"
+			add_to_incompat_list "$ref" "$INCOMPAT_LIST"
+		fi
+		printf "OK\n"
+	done
+	sort -u -o "$INCOMPAT_LIST" "$INCOMPAT_LIST"
+	sed -i -e '/^$/d' "$INCOMPAT_LIST"
+}
+
+# Print the path to the headers_install tree for a given ref
+get_header_tree() {
+	local -r ref="$1"
+	printf "%s" "${TMP_DIR}/${ref}/usr"
+}
+
+# Check file list for UAPI compatibility
+check_uapi_files() {
+	local -r base_ref="$1"
+	local -r past_ref="$2"
+	local -r abi_error_log="$3"
+
+	local passed=0;
+	local failed=0;
+	local -a threads=()
+	set -o errexit
+
+	printf "Checking changes to UAPI headers between %s and %s...\n" "$past_ref" "${base_ref:-dirty tree}"
+	# Loop over all UAPI headers that were installed by $past_ref (if they only exist on $base_ref,
+	# there's no way they're broken and no way to compare anyway)
+	while read -r file; do
+		if [ "${#threads[@]}" -ge "$MAX_THREADS" ]; then
+			if wait "${threads[0]}"; then
+				passed=$((passed + 1))
+			else
+				failed=$((failed + 1))
+			fi
+			threads=("${threads[@]:1}")
+		fi
+
+		check_individual_file "$base_ref" "$past_ref" "$file" &
+		threads+=("$!")
+	done < <(get_file_list "$past_ref")
+
+	for t in "${threads[@]}"; do
+		if wait "$t"; then
+			passed=$((passed + 1))
+		else
+			failed=$((failed + 1))
+		fi
+	done
+
+	if [ -n "$abi_error_log" ]; then
+		printf 'Generated by "%s %s" from git ref %s\n\n' \
+			"$0" "$*" "$(git rev-parse HEAD)" > "$abi_error_log"
+	fi
+
+	while read -r error_file; do
+		{
+			cat "$error_file"
+			printf "\n\n"
+		} | tee -a "${abi_error_log:-/dev/null}" >&2
+	done < <(find "$TMP_DIR" -type f -name '*.error' | sort)
+
+	total="$((passed + failed))"
+	if [ "$failed" -gt 0 ]; then
+		eprintf "error - %d/%d UAPI headers compatible with %s appear _not_ to be backwards compatible\n" \
+			"$failed" "$total" "$ARCH"
+		if [ -n "$abi_error_log" ]; then
+			eprintf "Failure summary saved to %s\n" "$abi_error_log"
+		fi
+	else
+		printf "All %d UAPI headers compatible with %s appear to be backwards compatible\n" \
+			"$total" "$ARCH"
+	fi
+
+	return "$failed"
+}
+
+# Check an individual file for UAPI compatibility
+check_individual_file() {
+	local -r base_ref="$1"
+	local -r past_ref="$2"
+	local -r file="$3"
+
+	local -r base_header="$(get_header_tree "$base_ref")/${file}"
+	local -r past_header="$(get_header_tree "$past_ref")/${file}"
+
+	if [ ! -f "$base_header" ]; then
+		mkdir -p "$(dirname "$base_header")"
+		printf "==== UAPI header %s was removed between %s and %s ====" \
+			"$file" "$past_ref" "$base_ref" \
+				> "${base_header}.error"
+		return 1
+	fi
+
+	compare_abi "$file" "$base_header" "$past_header" "$base_ref" "$past_ref"
+}
+
+# Perform the A/B compilation and compare output ABI
+compare_abi() {
+	local -r file="$1"
+	local -r base_header="$2"
+	local -r past_header="$3"
+	local -r base_ref="$4"
+	local -r past_ref="$5"
+	local -r log="${TMP_DIR}/log/${file}.log"
+	local -r error_log="${TMP_DIR}/log/${file}.error"
+
+	mkdir -p "$(dirname "$log")"
+
+	if ! do_compile "$(get_header_tree "$base_ref")/include" "$base_header" "${base_header}.bin" 2> "$log"; then
+		{
+			warn_str=$(printf "==== Could not compile version of UAPI header %s at %s ====\n" \
+				"$file" "$base_ref")
+			printf "%s\n" "$warn_str"
+			cat "$log"
+			printf -- "=%.0s" $(seq 0 ${#warn_str})
+		} > "$error_log"
+		return 1
+	fi
+
+	if ! do_compile "$(get_header_tree "$past_ref")/include" "$past_header" "${past_header}.bin" 2> "$log"; then
+		{
+			warn_str=$(printf "==== Could not compile version of UAPI header %s at %s ====\n" \
+				"$file" "$past_ref")
+			printf "%s\n" "$warn_str"
+			cat "$log"
+			printf -- "=%.0s" $(seq 0 ${#warn_str})
+		} > "$error_log"
+		return 1
+	fi
+
+	local ret=0
+	"$ABIDIFF" --non-reachable-types \
+		--suppressions "$SUPPRESSIONS" \
+		"${past_header}.bin" "${base_header}.bin" > "$log" || ret="$?"
+	if [ "$ret" -eq 0 ]; then
+		if [ "$VERBOSE" = "true" ]; then
+			printf "No ABI differences detected in %s from %s -> %s\n" \
+				"$file" "$past_ref" "$base_ref"
+		fi
+	else
+		# Bits in abidiff's return code can be used to determine the type of error
+		if [ $((ret & 0x2)) -gt 0 ]; then
+			eprintf "error - abidiff did not run properly\n"
+			exit 1
+		fi
+
+		if [ "$IGNORE_AMBIGUOUS_CHANGES" = "true" ] && [ "$ret" -eq 4 ]; then
+			return 0
+		fi
+
+		# If the only changes were additions (not modifications to existing APIs), then
+		# there's no problem. Ignore these diffs.
+		if grep "Unreachable types summary" "$log" | grep -q "0 removed" &&
+		   grep "Unreachable types summary" "$log" | grep -q "0 changed"; then
+			return 0
+		fi
+
+		{
+			warn_str=$(printf "==== ABI differences detected in %s from %s -> %s ====" \
+				"$file" "$past_ref" "$base_ref")
+			printf "%s\n" "$warn_str"
+			sed  -e '/summary:/d' -e '/changed type/d' -e '/^$/d' -e 's/^/  /g' "$log"
+			printf -- "=%.0s" $(seq 0 ${#warn_str})
+			if cmp "$past_header" "$base_header" > /dev/null 2>&1; then
+				printf "\n%s did not change between %s and %s...\n" "$file" "$past_ref" "${base_ref:-dirty tree}"
+				printf "It's possible a change to one of the headers it includes caused this error:\n"
+				grep '^#include' "$base_header"
+				printf "\n"
+			fi
+		} > "$error_log"
+
+		return 1
+	fi
+}
+
+# Check that a minimum software version number is satisfied
+min_version_is_satisfied() {
+	local -r min_version="$1"
+	local -r version_installed="$2"
+
+	printf "%s\n%s\n" "$min_version" "$version_installed" \
+		| sort -Vc > /dev/null 2>&1
+}
+
+# Make sure we have the tools we need and the arguments make sense
+check_deps() {
+	ABIDIFF="${ABIDIFF:-abidiff}"
+	CC="${CC:-gcc}"
+	ARCH="${ARCH:-$(uname -m)}"
+	if [ "$ARCH" = "x86_64" ]; then
+		ARCH="x86"
+	fi
+
+	local -r abidiff_min_version="2.4"
+	local -r libdw_min_version_if_clang="0.171"
+
+	if ! command -v "$ABIDIFF" > /dev/null 2>&1; then
+		eprintf "error - abidiff not found!\n"
+		eprintf "Please install abigail-tools version %s or greater\n" "$abidiff_min_version"
+		eprintf "See: https://sourceware.org/libabigail/manual/libabigail-overview.html\n"
+		return 1
+	fi
+
+	local -r abidiff_version="$("$ABIDIFF" --version | cut -d ' ' -f 2)"
+	if ! min_version_is_satisfied "$abidiff_min_version" "$abidiff_version"; then
+		eprintf "error - abidiff version too old: %s\n" "$abidiff_version"
+		eprintf "Please install abigail-tools version %s or greater\n" "$abidiff_min_version"
+		eprintf "See: https://sourceware.org/libabigail/manual/libabigail-overview.html\n"
+		return 1
+	fi
+
+	if ! command -v "$CC" > /dev/null 2>&1; then
+		eprintf 'error - %s not found\n' "$CC"
+		return 1
+	fi
+
+	if "$CC" --version | grep -q clang; then
+		local -r libdw_version="$(ldconfig -v 2>/dev/null | grep -v SKIPPED | grep -m 1 -o 'libdw-[0-9]\+.[0-9]\+' | cut -c 7-)"
+		if ! min_version_is_satisfied "$libdw_min_version_if_clang" "$libdw_version"; then
+			eprintf "error - libdw version too old for use with clang: %s\n" "$libdw_version"
+			eprintf "Please install libdw from elfutils version %s or greater\n" "$libdw_min_version_if_clang"
+			eprintf "See: https://sourceware.org/elfutils/\n"
+			return 1
+		fi
+	fi
+
+	if [ ! -d "arch/${ARCH}" ]; then
+		eprintf 'error - ARCH "%s" is not a subdirectory under arch/\n' "$ARCH"
+		eprintf "Please set ARCH to one of:\n%s\n" "$(find arch -maxdepth 1 -mindepth 1 -type d -printf '%f ' | fmt)"
+		return 1
+	fi
+
+	if ! git rev-parse --is-inside-work-tree > /dev/null 2>&1; then
+		eprintf "error - this script requires the kernel tree to be initialized with Git\n"
+		return 1
+	fi
+
+	if ! git rev-parse --verify "$past_ref" > /dev/null 2>&1; then
+		printf 'error - invalid git reference "%s"\n' "$past_ref"
+		return 1
+	fi
+
+	if [ -n "$base_ref" ]; then
+		if ! git merge-base --is-ancestor "$past_ref" "$base_ref" > /dev/null 2>&1; then
+			printf 'error - "%s" is not an ancestor of base ref "%s"\n' "$past_ref" "$base_ref"
+			return 1
+		fi
+		if [ "$(git rev-parse "$base_ref")" = "$(git rev-parse "$past_ref")" ]; then
+			printf 'error - "%s" and "%s" are the same reference\n' "$past_ref" "$base_ref"
+			return 1
+		fi
+	fi
+}
+
+run() {
+	local base_ref="$1"
+	local past_ref="$2"
+	local abi_error_log="$3"
+	shift 3
+
+	if [ -z "$KERNEL_SRC" ]; then
+		KERNEL_SRC="$(realpath "$(dirname "$0")"/..)"
+	fi
+
+	cd "$KERNEL_SRC"
+
+	if [ -z "$base_ref" ] && ! tree_is_dirty; then
+		base_ref=HEAD
+	fi
+
+	if [ -z "$past_ref" ]; then
+		if [ -n "$base_ref" ]; then
+			past_ref="${base_ref}^1"
+		else
+			past_ref=HEAD
+		fi
+	fi
+
+	if ! check_deps; then
+		exit "$FAIL_PREREQ"
+	fi
+
+	TMP_DIR=$(mktemp -d)
+	readonly TMP_DIR
+	trap 'rm -rf "$TMP_DIR"' EXIT
+
+	readonly INCOMPAT_LIST="${TMP_DIR}/incompat_list.txt"
+	touch "$INCOMPAT_LIST"
+
+	readonly SUPPRESSIONS="${TMP_DIR}/suppressions.txt"
+	gen_suppressions > "$SUPPRESSIONS"
+
+	# Run make install_headers for both refs
+	install_headers "$base_ref" "$past_ref"
+
+	# Check for any differences in the installed header trees
+	if diff -r -q "$(get_header_tree "$base_ref")" "$(get_header_tree "$past_ref")" > /dev/null 2>&1; then
+		printf "No changes to UAPI headers were applied between %s and %s\n" "$past_ref" "${base_ref:-dirty tree}"
+		exit "$SUCCESS"
+	fi
+
+	if ! check_uapi_files "$base_ref" "$past_ref" "$abi_error_log"; then
+		exit "$FAIL_ABI"
+	fi
+}
+
+main() {
+	MAX_THREADS=$(nproc)
+	VERBOSE="false"
+	IGNORE_AMBIGUOUS_CHANGES="false"
+	quiet="false"
+	local base_ref=""
+	while getopts "hb:p:j:l:iqv" opt; do
+		case $opt in
+		h)
+			print_usage
+			exit "$SUCCESS"
+			;;
+		b)
+			base_ref="$OPTARG"
+			;;
+		p)
+			past_ref="$OPTARG"
+			;;
+		j)
+			MAX_THREADS="$OPTARG"
+			;;
+		l)
+			abi_error_log="$OPTARG"
+			;;
+		i)
+			IGNORE_AMBIGUOUS_CHANGES="true"
+			;;
+		q)
+			quiet="true"
+			VERBOSE="false"
+			;;
+		v)
+			VERBOSE="true"
+			quiet="false"
+			;;
+		*)
+			exit "$FAIL_PREREQ"
+		esac
+	done
+
+	if [ "$quiet" = "true" ]; then
+		exec > /dev/null 2>&1
+	fi
+
+	run "$base_ref" "$past_ref" "$abi_error_log" "$@"
+}
+
+main "$@"
--
2.34.1



From quic_johmoo at quicinc.com  Mon Dec 11 18:02:58 2023
From: quic_johmoo at quicinc.com (John Moon)
Date: Mon, 11 Dec 2023 18:02:58 -0800
Subject: [PATCH v7 2/3] docs: dev-tools: Add UAPI checker documentation
In-Reply-To: <20231212020259.2451253-1-quic_johmoo@quicinc.com>
References: <20231212020259.2451253-1-quic_johmoo@quicinc.com>
Message-ID: <20231212020259.2451253-3-quic_johmoo@quicinc.com>

Add detailed documentation for scripts/check-uapi.sh.

Signed-off-by: John Moon <quic_johmoo at quicinc.com>
---
 Documentation/dev-tools/checkuapi.rst | 477 ++++++++++++++++++++++++++
 Documentation/dev-tools/index.rst     |   1 +
 2 files changed, 478 insertions(+)
 create mode 100644 Documentation/dev-tools/checkuapi.rst

diff --git a/Documentation/dev-tools/checkuapi.rst b/Documentation/dev-tools/checkuapi.rst
new file mode 100644
index 000000000000..9072f21b50b0
--- /dev/null
+++ b/Documentation/dev-tools/checkuapi.rst
@@ -0,0 +1,477 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+============
+UAPI Checker
+============
+
+The UAPI checker (``scripts/check-uapi.sh``) is a shell script which
+checks UAPI header files for userspace backwards-compatibility across
+the git tree.
+
+Options
+=======
+
+This section will describe the options with which ``check-uapi.sh``
+can be run.
+
+Usage::
+
+    check-uapi.sh [-b BASE_REF] [-p PAST_REF] [-j N] [-l ERROR_LOG] [-i] [-q] [-v]
+
+Available options::
+
+    -b BASE_REF    Base git reference to use for comparison. If unspecified or empty,
+                   will use any dirty changes in tree to UAPI files. If there are no
+                   dirty changes, HEAD will be used.
+    -p PAST_REF    Compare BASE_REF to PAST_REF (e.g. -p v6.1). If unspecified or empty,
+                   will use BASE_REF^1. Must be an ancestor of BASE_REF. Only headers
+                   that exist on PAST_REF will be checked for compatibility.
+    -j JOBS        Number of checks to run in parallel (default: number of CPU cores).
+    -l ERROR_LOG   Write error log to file (default: no error log is generated).
+    -i             Ignore ambiguous changes that may or may not break UAPI compatibility.
+    -q             Quiet operation.
+    -v             Verbose operation (print more information about each header being checked).
+
+Environmental args::
+
+    ABIDIFF  Custom path to abidiff binary
+    CC       C compiler (default is "gcc")
+    ARCH     Target architecture of C compiler (default is host arch)
+
+Exit codes::
+
+    0) Success
+    1) ABI difference detected
+    2) Prerequisite not met
+
+Examples
+========
+
+Basic Usage
+-----------
+
+First, let's try making a change to a UAPI header file that obviously
+won't break userspace::
+
+    cat << 'EOF' | patch -l -p1
+    --- a/include/uapi/linux/acct.h
+    +++ b/include/uapi/linux/acct.h
+    @@ -21,7 +21,9 @@
+     #include <asm/param.h>
+     #include <asm/byteorder.h>
+
+    -/*
+    +#define FOO
+    +
+    +/*
+      *  comp_t is a 16-bit "floating" point number with a 3-bit base 8
+      *  exponent and a 13-bit fraction.
+      *  comp2_t is 24-bit with 5-bit base 2 exponent and 20 bit fraction
+    diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
+    EOF
+
+Now, let's use the script to validate::
+
+    % ./scripts/check-uapi.sh
+    Installing user-facing UAPI headers from dirty tree... OK
+    Installing user-facing UAPI headers from HEAD... OK
+    Checking changes to UAPI headers between HEAD and dirty tree...
+    All 912 UAPI headers compatible with x86 appear to be backwards compatible
+
+Let's add another change that *might* break userspace::
+
+    cat << 'EOF' | patch -l -p1
+    --- a/include/uapi/linux/bpf.h
+    +++ b/include/uapi/linux/bpf.h
+    @@ -74,7 +74,7 @@ struct bpf_insn {
+            __u8    dst_reg:4;      /* dest register */
+            __u8    src_reg:4;      /* source register */
+            __s16   off;            /* signed offset */
+    -       __s32   imm;            /* signed immediate constant */
+    +       __u32   imm;            /* unsigned immediate constant */
+     };
+
+     /* Key of an a BPF_MAP_TYPE_LPM_TRIE entry */
+    EOF
+
+The script will catch this::
+
+    % ./scripts/check-uapi.sh
+    Installing user-facing UAPI headers from dirty tree... OK
+    Installing user-facing UAPI headers from HEAD... OK
+    Checking changes to UAPI headers between HEAD and dirty tree...
+    ==== ABI differences detected in include/linux/bpf.h from HEAD -> dirty tree ====
+        [C] 'struct bpf_insn' changed:
+          type size hasn't changed
+          1 data member change:
+            type of '__s32 imm' changed:
+              typedef name changed from __s32 to __u32 at int-ll64.h:27:1
+              underlying type 'int' changed:
+                type name changed from 'int' to 'unsigned int'
+                type size hasn't changed
+    ==================================================================================
+
+    error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+In this case, the script is reporting the type change because it could
+break a userspace program that passes in a negative number. Now, let's
+say you know that no userspace program could possibly be using a negative
+value in ``imm``, so changing to an unsigned type there shouldn't hurt
+anything. You can pass the ``-i`` flag to the script to ignore changes
+in which the userspace backwards compatibility is ambiguous::
+
+    % ./scripts/check-uapi.sh -i
+    Installing user-facing UAPI headers from dirty tree... OK
+    Installing user-facing UAPI headers from HEAD... OK
+    Checking changes to UAPI headers between HEAD and dirty tree...
+    All 912 UAPI headers compatible with x86 appear to be backwards compatible
+
+Now, let's make a similar change that *will* break userspace::
+
+    cat << 'EOF' | patch -l -p1
+    --- a/include/uapi/linux/bpf.h
+    +++ b/include/uapi/linux/bpf.h
+    @@ -71,8 +71,8 @@ enum {
+
+     struct bpf_insn {
+            __u8    code;           /* opcode */
+    -       __u8    dst_reg:4;      /* dest register */
+            __u8    src_reg:4;      /* source register */
+    +       __u8    dst_reg:4;      /* dest register */
+            __s16   off;            /* signed offset */
+            __s32   imm;            /* signed immediate constant */
+     };
+    EOF
+
+Since we're re-ordering an existing struct member, there's no ambiguity,
+and the script will report the breakage even if you pass ``-i``::
+
+    % ./scripts/check-uapi.sh -i
+    Installing user-facing UAPI headers from dirty tree... OK
+    Installing user-facing UAPI headers from HEAD... OK
+    Checking changes to UAPI headers between HEAD and dirty tree...
+    ==== ABI differences detected in include/linux/bpf.h from HEAD -> dirty tree ====
+        [C] 'struct bpf_insn' changed:
+          type size hasn't changed
+          2 data member changes:
+            '__u8 dst_reg' offset changed from 8 to 12 (in bits) (by +4 bits)
+            '__u8 src_reg' offset changed from 12 to 8 (in bits) (by -4 bits)
+    ==================================================================================
+
+    error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+Let's commit the breaking change, then commit the innocuous change::
+
+    % git commit -m 'Breaking UAPI change' include/uapi/linux/bpf.h
+    [detached HEAD f758e574663a] Breaking UAPI change
+     1 file changed, 1 insertion(+), 1 deletion(-)
+    % git commit -m 'Innocuous UAPI change' include/uapi/linux/acct.h
+    [detached HEAD 2e87df769081] Innocuous UAPI change
+     1 file changed, 3 insertions(+), 1 deletion(-)
+
+Now, let's run the script again with no arguments::
+
+    % ./scripts/check-uapi.sh
+    Installing user-facing UAPI headers from HEAD... OK
+    Installing user-facing UAPI headers from HEAD^1... OK
+    Checking changes to UAPI headers between HEAD^1 and HEAD...
+    All 912 UAPI headers compatible with x86 appear to be backwards compatible
+
+It doesn't catch any breaking change because, by default, it only
+compares ``HEAD`` to ``HEAD^1``. The breaking change was committed on
+``HEAD~2``. If we wanted the search scope to go back further, we'd have to
+use the ``-p`` option to pass a different past reference. In this case,
+let's pass ``-p HEAD~2`` to the script so it checks UAPI changes between
+``HEAD~2`` and ``HEAD``::
+
+    % ./scripts/check-uapi.sh -p HEAD~2
+    Installing user-facing UAPI headers from HEAD... OK
+    Installing user-facing UAPI headers from HEAD~2... OK
+    Checking changes to UAPI headers between HEAD~2 and HEAD...
+    ==== ABI differences detected in include/linux/bpf.h from HEAD~2 -> HEAD ====
+        [C] 'struct bpf_insn' changed:
+          type size hasn't changed
+          2 data member changes:
+            '__u8 dst_reg' offset changed from 8 to 12 (in bits) (by +4 bits)
+            '__u8 src_reg' offset changed from 12 to 8 (in bits) (by -4 bits)
+    ==============================================================================
+
+    error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+Alternatively, we could have also run with ``-b HEAD~``. This would set the
+base reference to ``HEAD~`` so then the script would compare it to ``HEAD~^1``.
+
+Architecture-specific Headers
+-----------------------------
+
+Consider this change::
+
+    cat << 'EOF' | patch -l -p1
+    --- a/arch/arm64/include/uapi/asm/sigcontext.h
+    +++ b/arch/arm64/include/uapi/asm/sigcontext.h
+    @@ -70,6 +70,7 @@ struct sigcontext {
+     struct _aarch64_ctx {
+            __u32 magic;
+            __u32 size;
+    +       __u32 new_var;
+     };
+
+     #define FPSIMD_MAGIC   0x46508001
+    EOF
+
+This is a change to an arm64-specific UAPI header file. In this example, I'm
+running the script from an x86 machine with an x86 compiler, so, by default,
+the script only checks x86-compatible UAPI header files::
+
+    % ./scripts/check-uapi.sh
+    Installing user-facing UAPI headers from dirty tree... OK
+    Installing user-facing UAPI headers from HEAD... OK
+    No changes to UAPI headers were applied between HEAD and dirty tree
+
+With an x86 compiler, we can't check header files in ``arch/arm64``, so the
+script doesn't even try.
+
+If we want to check the header file, we'll have to use an arm64 compiler and
+set ``ARCH`` accordingly::
+
+    % CC=aarch64-linux-gnu-gcc ARCH=arm64 ./scripts/check-uapi.sh
+    Installing user-facing UAPI headers from dirty tree... OK
+    Installing user-facing UAPI headers from HEAD... OK
+    Checking changes to UAPI headers between HEAD and dirty tree...
+    ==== ABI differences detected in include/asm/sigcontext.h from HEAD -> dirty tree ====
+        [C] 'struct _aarch64_ctx' changed:
+          type size changed from 64 to 96 (in bits)
+          1 data member insertion:
+            '__u32 new_var', at offset 64 (in bits) at sigcontext.h:73:1
+        -- snip --
+        [C] 'struct zt_context' changed:
+          type size changed from 128 to 160 (in bits)
+          2 data member changes (1 filtered):
+            '__u16 nregs' offset changed from 64 to 96 (in bits) (by +32 bits)
+            '__u16 __reserved[3]' offset changed from 80 to 112 (in bits) (by +32 bits)
+    =======================================================================================
+
+    error - 1/884 UAPI headers compatible with arm64 appear _not_ to be backwards compatible
+
+We can see with ``ARCH`` and ``CC`` set properly for the file, the ABI
+change is reported properly. Also notice that the total number of UAPI
+header files checked by the script changes. This is because the number
+of headers installed for arm64 platforms is different than x86.
+
+Cross-Dependency Breakages
+--------------------------
+
+Consider this change::
+
+    cat << 'EOF' | patch -l -p1
+    --- a/include/uapi/linux/types.h
+    +++ b/include/uapi/linux/types.h
+    @@ -52,7 +52,7 @@ typedef __u32 __bitwise __wsum;
+     #define __aligned_be64 __be64 __attribute__((aligned(8)))
+     #define __aligned_le64 __le64 __attribute__((aligned(8)))
+
+    -typedef unsigned __bitwise __poll_t;
+    +typedef unsigned short __bitwise __poll_t;
+
+     #endif /*  __ASSEMBLY__ */
+     #endif /* _UAPI_LINUX_TYPES_H */
+    EOF
+
+Here, we're changing a ``typedef`` in ``types.h``. This doesn't break
+a UAPI in ``types.h``, but other UAPIs in the tree may break due to
+this change::
+
+    % ./scripts/check-uapi.sh
+    Installing user-facing UAPI headers from dirty tree... OK
+    Installing user-facing UAPI headers from HEAD... OK
+    Checking changes to UAPI headers between HEAD and dirty tree...
+    ==== ABI differences detected in include/linux/eventpoll.h from HEAD -> dirty tree ====
+        [C] 'struct epoll_event' changed:
+          type size changed from 96 to 80 (in bits)
+          2 data member changes:
+            type of '__poll_t events' changed:
+              underlying type 'unsigned int' changed:
+                type name changed from 'unsigned int' to 'unsigned short int'
+                type size changed from 32 to 16 (in bits)
+            '__u64 data' offset changed from 32 to 16 (in bits) (by -16 bits)
+    ========================================================================================
+    include/linux/eventpoll.h did not change between HEAD and dirty tree...
+    It's possible a change to one of the headers it includes caused this error:
+    #include <linux/fcntl.h>
+    #include <linux/types.h>
+
+Note that the script noticed the failing header file did not change,
+so it assumes one of its includes must have caused the breakage. Indeed,
+we can see ``linux/types.h`` is used from ``eventpoll.h``.
+
+UAPI Header Removals
+--------------------
+
+Consider this change::
+
+    cat << 'EOF' | patch -l -p1
+    diff --git a/include/uapi/asm-generic/Kbuild b/include/uapi/asm-generic/Kbuild
+    index ebb180aac74e..a9c88b0a8b3b 100644
+    --- a/include/uapi/asm-generic/Kbuild
+    +++ b/include/uapi/asm-generic/Kbuild
+    @@ -31,6 +31,6 @@ mandatory-y += stat.h
+     mandatory-y += statfs.h
+     mandatory-y += swab.h
+     mandatory-y += termbits.h
+    -mandatory-y += termios.h
+    +#mandatory-y += termios.h
+     mandatory-y += types.h
+     mandatory-y += unistd.h
+    EOF
+
+This script removes a UAPI header file from the install list. Let's run
+the script::
+
+    % ./scripts/check-uapi.sh
+    Installing user-facing UAPI headers from dirty tree... OK
+    Installing user-facing UAPI headers from HEAD... OK
+    Checking changes to UAPI headers between HEAD and dirty tree...
+    ==== UAPI header include/asm/termios.h was removed between HEAD and dirty tree ====
+
+    error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+Removing a UAPI header is considered a breaking change, and the script
+will flag it as such.
+
+Checking Historic UAPI Compatibility
+------------------------------------
+
+You can use the ``-b`` and ``-p`` options to examine different chunks of your
+git tree. For example, to check all changed UAPI header files between tags
+v6.0 and v6.1, you'd run::
+
+    % ./scripts/check-uapi.sh -b v6.1 -p v6.0
+    Installing user-facing UAPI headers from v6.1... OK
+    Installing user-facing UAPI headers from v6.0... OK
+    Checking changes to UAPI headers between v6.0 and v6.1...
+
+    --- snip ---
+    error - 37/907 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+Note: Before v5.3, a header file needed by the script is not present,
+so the script is unable to check changes before then.
+
+You'll notice that the script detected many UAPI changes that are not
+backwards compatible. Knowing that kernel UAPIs are supposed to be stable
+forever, this is an alarming result. This brings us to the next section:
+caveats.
+
+Caveats
+=======
+
+The UAPI checker makes no assumptions about the author's intention, so some
+types of changes may be flagged even though they intentionally break UAPI.
+
+Removals For Refactoring or Deprecation
+---------------------------------------
+
+Sometimes drivers for very old hardware are removed, such as in this example::
+
+    % ./scripts/check-uapi.sh -b ba47652ba655
+    Installing user-facing UAPI headers from ba47652ba655... OK
+    Installing user-facing UAPI headers from ba47652ba655^1... OK
+    Checking changes to UAPI headers between ba47652ba655^1 and ba47652ba655...
+    ==== UAPI header include/linux/meye.h was removed between ba47652ba655^1 and ba47652ba655 ====
+
+    error - 1/910 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+The script will always flag removals (even if they're intentional).
+
+Struct Expansions
+-----------------
+
+Depending on how a structure is handled in kernelspace, a change which
+expands a struct could be non-breaking.
+
+If a struct is used as the argument to an ioctl, then the kernel driver
+must be able to handle ioctl commands of any size. Beyond that, you need
+to be careful when copying data from the user. Say, for example, that
+``struct foo`` is changed like this::
+
+    struct foo {
+        __u64 a; /* added in version 1 */
+    +   __u32 b; /* added in version 2 */
+    +   __u32 c; /* added in version 2 */
+    }
+
+By default, the script will flag this kind of change for further review::
+
+    [C] 'struct foo' changed:
+      type size changed from 64 to 128 (in bits)
+      2 data member insertions:
+        '__u32 b', at offset 64 (in bits)
+        '__u32 c', at offset 96 (in bits)
+
+However, it is possible that this change was made safely.
+
+If a userspace program was built with version 1, it will think
+``sizeof(struct foo)`` is 8. That size will be encoded in the
+ioctl value that gets sent to the kernel. If the kernel is built
+with version 2, it will think the ``sizeof(struct foo)`` is 16.
+
+The kernel can use the ``_IOC_SIZE`` macro to get the size encoded
+in the ioctl code that the user passed in and then use
+``copy_struct_from_user()`` to safely copy the value::
+
+    int handle_ioctl(unsigned long cmd, unsigned long arg)
+    {
+        switch _IOC_NR(cmd) {
+        0x01: {
+            struct foo my_cmd;  /* size 16 in the kernel */
+
+            ret = copy_struct_from_user(&my_cmd, arg, sizeof(struct foo), _IOC_SIZE(cmd));
+            ...
+
+``copy_struct_from_user`` will zero the struct in the kernel and then copy
+only the bytes passed in from the user (leaving new members zeroized).
+If the user passed in a larger struct, the extra members are ignored.
+
+If you know this situation is accounted for in the kernel code, you can
+pass ``-i`` to the script, and struct expansions like this will be ignored.
+
+Flex Array Migration
+--------------------
+
+While the script handles expansion into an existing flex array, it does
+still flag initial migration to flex arrays from 1-element fake flex
+arrays. For example::
+
+    struct foo {
+          __u32 x;
+    -     __u32 flex[1]; /* fake flex */
+    +     __u32 flex[];  /* real flex */
+    };
+
+This change would be flagged by the script::
+
+    [C] 'struct foo' changed:
+      type size changed from 64 to 32 (in bits)
+      1 data member change:
+        type of '__u32 flex[1]' changed:
+          type name changed from '__u32[1]' to '__u32[]'
+          array type size changed from 32 to 'unknown'
+          array type subrange 1 changed length from 1 to 'unknown'
+
+At this time, there's no way to filter these types of changes, so be
+aware of this possible false positive.
+
+Summary
+-------
+
+While many types of false positives are filtered out by the script,
+it's possible there are some cases where the script flags a change
+which does not break UAPI. It's also possible a change which *does*
+break userspace would not be flagged by this script. While the script
+has been run on much of the kernel history, there could still be corner
+cases that are not accounted for.
+
+The intention is for this script to be used as a quick check for
+maintainers or automated tooling, not as the end-all authority on
+patch compatibility. It's best to remember: use your best judgment
+(and ideally a unit test in userspace) to make sure your UAPI changes
+are backwards-compatible!
diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst
index 6b0663075dc0..0876f5a2cf55 100644
--- a/Documentation/dev-tools/index.rst
+++ b/Documentation/dev-tools/index.rst
@@ -34,6 +34,7 @@ Documentation/dev-tools/testing-overview.rst
    kselftest
    kunit/index
    ktap
+   checkuapi
 
 
 .. only::  subproject and html
-- 
2.34.1



From ilkka at os.amperecomputing.com  Mon Dec 11 18:21:34 2023
From: ilkka at os.amperecomputing.com (Ilkka Koskinen)
Date: Mon, 11 Dec 2023 18:21:34 -0800 (PST)
Subject: [PATCH] perf/arm-cmn: Fail DTC counter allocation correctly
In-Reply-To: <ed589c0d8e4130dc68b8ad1625226d28bdc185d4.1702322847.git.robin.murphy@arm.com>
References: <ed589c0d8e4130dc68b8ad1625226d28bdc185d4.1702322847.git.robin.murphy@arm.com>
Message-ID: <bf20c32f-6426-f4ba-3bcc-41aadd89968@os.amperecomputing.com>


On Mon, 11 Dec 2023, Robin Murphy wrote:
> Calling arm_cmn_event_clear() before all DTC indices are allocated is
> wrong, and can lead to arm_cmn_event_add() erroneously clearing live
> counters from full DTCs where allocation fails. Since the DTC counters
> are only updated by arm_cmn_init_counter() after all DTC and DTM
> allocations succeed, nothing actually needs cleaning up in this case
> anyway, and it should just return directly as it did before.
>
> Fixes: 7633ec2c262f ("perf/arm-cmn: Rework DTC counters (again)")
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>

That's a good catch.

     Reviewed-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>

Cheers, Ilkka

> ---
> drivers/perf/arm-cmn.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> index 86d970e74129..c584165b13ba 100644
> --- a/drivers/perf/arm-cmn.c
> +++ b/drivers/perf/arm-cmn.c
> @@ -1816,7 +1816,7 @@ static int arm_cmn_event_add(struct perf_event *event, int flags)
> 			idx = 0;
> 			while (cmn->dtc[j].counters[idx])
> 				if (++idx == CMN_DT_NUM_COUNTERS)
> -					goto free_dtms;
> +					return -ENOSPC;
> 		}
> 		hw->dtc_idx[j] = idx;
> 	}
> -- 
> 2.39.2.101.g768bb238c484.dirty
>
>


From yury.norov at gmail.com  Mon Dec 11 18:27:23 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Mon, 11 Dec 2023 18:27:23 -0800
Subject: [PATCH v3 09/35] drivers/perf: optimize ali_drw_get_counter_idx() by using find_and_set_bit()
In-Reply-To: <20231212022749.625238-1-yury.norov@gmail.com>
References: <20231212022749.625238-1-yury.norov@gmail.com>
Message-ID: <20231212022749.625238-10-yury.norov@gmail.com>

The function searches used_mask for a set bit in a for-loop bit by bit.
Simplify it by using atomic find_and_set_bit().

Signed-off-by: Yury Norov <yury.norov at gmail.com>
Acked-by: Will Deacon <will at kernel.org>
---
 drivers/perf/alibaba_uncore_drw_pmu.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_uncore_drw_pmu.c
index 19d459a36be5..2a3b7701d568 100644
--- a/drivers/perf/alibaba_uncore_drw_pmu.c
+++ b/drivers/perf/alibaba_uncore_drw_pmu.c
@@ -274,15 +274,9 @@ static const struct attribute_group *ali_drw_pmu_attr_groups[] = {
 static int ali_drw_get_counter_idx(struct perf_event *event)
 {
 	struct ali_drw_pmu *drw_pmu = to_ali_drw_pmu(event->pmu);
-	int idx;
+	int idx = find_and_set_bit(drw_pmu->used_mask, ALI_DRW_PMU_COMMON_MAX_COUNTERS);
 
-	for (idx = 0; idx < ALI_DRW_PMU_COMMON_MAX_COUNTERS; ++idx) {
-		if (!test_and_set_bit(idx, drw_pmu->used_mask))
-			return idx;
-	}
-
-	/* The counters are all in use. */
-	return -EBUSY;
+	return idx < ALI_DRW_PMU_COMMON_MAX_COUNTERS ? idx : -EBUSY;
 }
 
 static u64 ali_drw_pmu_read_counter(struct perf_event *event)
-- 
2.40.1



From yury.norov at gmail.com  Mon Dec 11 18:27:22 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Mon, 11 Dec 2023 18:27:22 -0800
Subject: [PATCH v3 08/35] perf/arm: use atomic find_bit() API
In-Reply-To: <20231212022749.625238-1-yury.norov@gmail.com>
References: <20231212022749.625238-1-yury.norov@gmail.com>
Message-ID: <20231212022749.625238-9-yury.norov@gmail.com>

Simplify subsystem by use atomic find_bit() or atomic API where
applicable.

CC: Will Deacon <will at kernel.org>
Signed-off-by: Yury Norov <yury.norov at gmail.com>
---
 drivers/perf/arm-cci.c        | 24 ++++++------------------
 drivers/perf/arm-ccn.c        | 10 ++--------
 drivers/perf/arm_dmc620_pmu.c |  9 ++-------
 drivers/perf/arm_pmuv3.c      |  8 ++------
 4 files changed, 12 insertions(+), 39 deletions(-)

diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
index 61de861eaf91..cb15b4cee5f7 100644
--- a/drivers/perf/arm-cci.c
+++ b/drivers/perf/arm-cci.c
@@ -320,12 +320,9 @@ static int cci400_get_event_idx(struct cci_pmu *cci_pmu,
 		return CCI400_PMU_CYCLE_CNTR_IDX;
 	}
 
-	for (idx = CCI400_PMU_CNTR0_IDX; idx <= CCI_PMU_CNTR_LAST(cci_pmu); ++idx)
-		if (!test_and_set_bit(idx, hw->used_mask))
-			return idx;
-
-	/* No counters available */
-	return -EAGAIN;
+	idx = find_and_set_next_bit(hw->used_mask, CCI_PMU_CNTR_LAST(cci_pmu) + 1,
+							CCI400_PMU_CNTR0_IDX);
+	return idx < CCI_PMU_CNTR_LAST(cci_pmu) + 1 ? idx : -EAGAIN;
 }
 
 static int cci400_validate_hw_event(struct cci_pmu *cci_pmu, unsigned long hw_event)
@@ -802,13 +799,8 @@ static int pmu_get_event_idx(struct cci_pmu_hw_events *hw, struct perf_event *ev
 	if (cci_pmu->model->get_event_idx)
 		return cci_pmu->model->get_event_idx(cci_pmu, hw, cci_event);
 
-	/* Generic code to find an unused idx from the mask */
-	for (idx = 0; idx <= CCI_PMU_CNTR_LAST(cci_pmu); idx++)
-		if (!test_and_set_bit(idx, hw->used_mask))
-			return idx;
-
-	/* No counters available */
-	return -EAGAIN;
+	idx = find_and_set_bit(hw->used_mask, CCI_PMU_CNTR_LAST(cci_pmu) + 1);
+	return idx < CCI_PMU_CNTR_LAST(cci_pmu) + 1 ? idx : -EAGAIN;
 }
 
 static int pmu_map_event(struct perf_event *event)
@@ -861,12 +853,8 @@ static void pmu_free_irq(struct cci_pmu *cci_pmu)
 {
 	int i;
 
-	for (i = 0; i < cci_pmu->nr_irqs; i++) {
-		if (!test_and_clear_bit(i, &cci_pmu->active_irqs))
-			continue;
-
+	for_each_test_and_clear_bit(i, &cci_pmu->active_irqs, cci_pmu->nr_irqs)
 		free_irq(cci_pmu->irqs[i], cci_pmu);
-	}
 }
 
 static u32 pmu_read_counter(struct perf_event *event)
diff --git a/drivers/perf/arm-ccn.c b/drivers/perf/arm-ccn.c
index 728d13d8e98a..d657701b1f23 100644
--- a/drivers/perf/arm-ccn.c
+++ b/drivers/perf/arm-ccn.c
@@ -589,15 +589,9 @@ static const struct attribute_group *arm_ccn_pmu_attr_groups[] = {
 
 static int arm_ccn_pmu_alloc_bit(unsigned long *bitmap, unsigned long size)
 {
-	int bit;
-
-	do {
-		bit = find_first_zero_bit(bitmap, size);
-		if (bit >= size)
-			return -EAGAIN;
-	} while (test_and_set_bit(bit, bitmap));
+	int bit = find_and_set_bit(bitmap, size);
 
-	return bit;
+	return bit < size ? bit : -EAGAIN;
 }
 
 /* All RN-I and RN-D nodes have identical PMUs */
diff --git a/drivers/perf/arm_dmc620_pmu.c b/drivers/perf/arm_dmc620_pmu.c
index 30cea6859574..e41c84dabc3e 100644
--- a/drivers/perf/arm_dmc620_pmu.c
+++ b/drivers/perf/arm_dmc620_pmu.c
@@ -303,13 +303,8 @@ static int dmc620_get_event_idx(struct perf_event *event)
 		end_idx = DMC620_PMU_MAX_COUNTERS;
 	}
 
-	for (idx = start_idx; idx < end_idx; ++idx) {
-		if (!test_and_set_bit(idx, dmc620_pmu->used_mask))
-			return idx;
-	}
-
-	/* The counters are all in use. */
-	return -EAGAIN;
+	idx = find_and_set_next_bit(dmc620_pmu->used_mask, end_idx, start_idx);
+	return idx < end_idx ? idx : -EAGAIN;
 }
 
 static inline
diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 6ca7be05229c..f046ad9e71f1 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -825,13 +825,9 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
 static int armv8pmu_get_single_idx(struct pmu_hw_events *cpuc,
 				    struct arm_pmu *cpu_pmu)
 {
-	int idx;
+	int idx = find_and_set_next_bit(cpuc->used_mask, cpu_pmu->num_events, ARMV8_IDX_COUNTER0);
 
-	for (idx = ARMV8_IDX_COUNTER0; idx < cpu_pmu->num_events; idx++) {
-		if (!test_and_set_bit(idx, cpuc->used_mask))
-			return idx;
-	}
-	return -EAGAIN;
+	return idx < cpu_pmu->num_events ? idx : -EAGAIN;
 }
 
 static int armv8pmu_get_chain_idx(struct pmu_hw_events *cpuc,
-- 
2.40.1



From yury.norov at gmail.com  Mon Dec 11 18:27:33 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Mon, 11 Dec 2023 18:27:33 -0800
Subject: [PATCH v3 19/35] iommu: optimize subsystem by using atomic find_bit() API
In-Reply-To: <20231212022749.625238-1-yury.norov@gmail.com>
References: <20231212022749.625238-1-yury.norov@gmail.com>
Message-ID: <20231212022749.625238-20-yury.norov@gmail.com>

Simplify  __arm_smmu_alloc_bitmap() and msm_iommu_alloc_ctx() by using
a dedicated API, and make them nice one-liner wrappers.

While here, refactor msm_iommu_attach_dev() and msm_iommu_alloc_ctx()
so that error codes don't mismatch.

Signed-off-by: Yury Norov <yury.norov at gmail.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu.h | 10 ++--------
 drivers/iommu/msm_iommu.c             | 18 ++++--------------
 2 files changed, 6 insertions(+), 22 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 703fd5817ec1..004a4704ebf1 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -453,15 +453,9 @@ struct arm_smmu_impl {
 
 static inline int __arm_smmu_alloc_bitmap(unsigned long *map, int start, int end)
 {
-	int idx;
+	int idx = find_and_set_next_bit(map, end, start);
 
-	do {
-		idx = find_next_zero_bit(map, end, start);
-		if (idx == end)
-			return -ENOSPC;
-	} while (test_and_set_bit(idx, map));
-
-	return idx;
+	return idx < end ? idx : -ENOSPC;
 }
 
 static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index f86af9815d6f..67124f4228b1 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -185,17 +185,9 @@ static const struct iommu_flush_ops msm_iommu_flush_ops = {
 	.tlb_add_page = __flush_iotlb_page,
 };
 
-static int msm_iommu_alloc_ctx(unsigned long *map, int start, int end)
+static int msm_iommu_alloc_ctx(struct msm_iommu_dev *iommu)
 {
-	int idx;
-
-	do {
-		idx = find_next_zero_bit(map, end, start);
-		if (idx == end)
-			return -ENOSPC;
-	} while (test_and_set_bit(idx, map));
-
-	return idx;
+	return find_and_set_bit(iommu->context_map, iommu->ncb);
 }
 
 static void msm_iommu_free_ctx(unsigned long *map, int idx)
@@ -418,10 +410,8 @@ static int msm_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
 					ret = -EEXIST;
 					goto fail;
 				}
-				master->num =
-					msm_iommu_alloc_ctx(iommu->context_map,
-							    0, iommu->ncb);
-				if (IS_ERR_VALUE(master->num)) {
+				master->num = msm_iommu_alloc_ctx(iommu);
+				if (master->num >= iommu->ncb) {
 					ret = -ENODEV;
 					goto fail;
 				}
-- 
2.40.1



From joel at jms.id.au  Mon Dec 11 18:29:01 2023
From: joel at jms.id.au (Joel Stanley)
Date: Tue, 12 Dec 2023 12:59:01 +1030
Subject: [PATCH v7 2/2] ARM: dts: aspeed: Harma: Add Meta Harma (AST2600) BMC
In-Reply-To: <20231211162656.2564267-3-peteryin.openbmc@gmail.com>
References: <20231211162656.2564267-1-peteryin.openbmc@gmail.com> <20231211162656.2564267-3-peteryin.openbmc@gmail.com>
Message-ID: <CACPK8XePx+PvDKzPMjPRn_g9z8yrtAmLvP8Qbepm1AVjuCbaKw@mail.gmail.com>

On Tue, 12 Dec 2023 at 02:59, Peter Yin <peteryin.openbmc at gmail.com> wrote:
>
> Add linux device tree entry related to
> the Meta(Facebook) computer-node system use an AT2600 BMC.
> This node is named "Harma".
>
> Signed-off-by: Peter Yin <peteryin.openbmc at gmail.com>

Looks good, thanks for your work. This will be submitted for the 6.8
merge window.

Reviewed-by: Joel Stanley <joel at jms.id.au>


> ---

For next time: Please describe what you've changed between this
version and the previous version just here, below the ---. This helps
reviewers understand what has changed, and why it's changed, from the
previous version.

>  arch/arm/boot/dts/aspeed/Makefile             |   1 +
>  .../dts/aspeed/aspeed-bmc-facebook-harma.dts  | 585 ++++++++++++++++++
>  2 files changed, 586 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
>
> diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
> index 23cbc7203a8e..92ba3208d2a2 100644
> --- a/arch/arm/boot/dts/aspeed/Makefile
> +++ b/arch/arm/boot/dts/aspeed/Makefile
> @@ -19,6 +19,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>         aspeed-bmc-facebook-fuji.dtb \
>         aspeed-bmc-facebook-galaxy100.dtb \
>         aspeed-bmc-facebook-greatlakes.dtb \
> +       aspeed-bmc-facebook-harma.dtb \
>         aspeed-bmc-facebook-minipack.dtb \
>         aspeed-bmc-facebook-tiogapass.dtb \
>         aspeed-bmc-facebook-wedge40.dtb \
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
> new file mode 100644
> index 000000000000..7db3f9eb0016
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
> @@ -0,0 +1,585 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +// Copyright 2023 Facebook Inc.
> +
> +/dts-v1/;
> +#include "aspeed-g6.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +#include <dt-bindings/i2c/i2c.h>
> +
> +/ {
> +       model = "Facebook Harma";
> +       compatible = "facebook,harma-bmc", "aspeed,ast2600";
> +
> +       aliases {
> +               serial0 = &uart1;
> +               serial1 = &uart6;
> +               serial2 = &uart2;
> +               serial4 = &uart5;
> +
> +               i2c20 = &imux20;
> +               i2c21 = &imux21;
> +               i2c22 = &imux22;
> +               i2c23 = &imux23;
> +               i2c24 = &imux24;
> +               i2c25 = &imux25;
> +               i2c26 = &imux26;
> +               i2c27 = &imux27;
> +               i2c28 = &imux28;
> +               i2c29 = &imux29;
> +               i2c30 = &imux30;
> +               i2c31 = &imux31;
> +       };
> +
> +       chosen {
> +               stdout-path = &uart5;
> +       };
> +
> +       memory at 80000000 {
> +               device_type = "memory";
> +               reg = <0x80000000 0x80000000>;
> +       };
> +
> +       iio-hwmon {
> +               compatible = "iio-hwmon";
> +               io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
> +                             <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
> +                             <&adc1 2>;
> +       };
> +
> +       leds {
> +               compatible = "gpio-leds";
> +
> +               led-0 {
> +                       label = "bmc_heartbeat_amber";
> +                       gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>;
> +                       linux,default-trigger = "heartbeat";
> +               };
> +
> +               led-1 {
> +                       label = "fp_id_amber";
> +                       default-state = "off";
> +                       gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
> +               };
> +
> +               led-2 {
> +                       label = "power_blue";
> +                       default-state = "off";
> +                       gpios = <&gpio0 124 GPIO_ACTIVE_HIGH>;
> +               };
> +       };
> +};
> +
> +// HOST BIOS Debug
> +&uart1 {
> +       status = "okay";
> +};
> +
> +// SOL Host Console
> +&uart2 {
> +       status = "okay";
> +       pinctrl-0 = <>;
> +};
> +
> +// SOL BMC Console
> +&uart4 {
> +       status = "okay";
> +       pinctrl-0 = <>;
> +};
> +
> +// BMC Debug Console
> +&uart5 {
> +       status = "okay";
> +};
> +
> +// MTIA
> +&uart6 {
> +       status = "okay";
> +};
> +
> +&uart_routing {
> +       status = "okay";
> +};
> +
> +&vuart1 {
> +       status = "okay";
> +};
> +
> +&wdt1 {
> +       status = "okay";
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_wdtrst1_default>;
> +       aspeed,reset-type = "soc";
> +       aspeed,external-signal;
> +       aspeed,ext-push-pull;
> +       aspeed,ext-active-high;
> +       aspeed,ext-pulse-duration = <256>;
> +};
> +
> +&mac3 {
> +       status = "okay";
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_rmii4_default>;
> +       use-ncsi;
> +       mlx,multi-host;
> +};
> +
> +&rtc {
> +       status = "okay";
> +};
> +
> +&fmc {
> +       status = "okay";
> +
> +       flash at 0 {
> +               status = "okay";
> +               m25p,fast-read;
> +               label = "bmc";
> +               spi-max-frequency = <50000000>;
> +#include "openbmc-flash-layout-128.dtsi"
> +       };
> +
> +       flash at 1 {
> +               status = "okay";
> +               m25p,fast-read;
> +               label = "alt-bmc";
> +               spi-max-frequency = <50000000>;
> +       };
> +};
> +
> +// BIOS Flash
> +&spi2 {
> +       status = "okay";
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_spi2_default>;
> +
> +       flash at 0 {
> +               status = "okay";
> +               m25p,fast-read;
> +               label = "pnor";
> +               spi-max-frequency = <12000000>;
> +               spi-tx-bus-width = <2>;
> +               spi-rx-bus-width = <2>;
> +       };
> +};
> +
> +&kcs2 {
> +       status = "okay";
> +       aspeed,lpc-io-reg = <0xca8>;
> +};
> +
> +&kcs3 {
> +       status = "okay";
> +       aspeed,lpc-io-reg = <0xca2>;
> +};
> +
> +&i2c0 {
> +       status = "okay";
> +
> +       max31790 at 30{
> +               compatible = "max31790";
> +               reg = <0x30>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +       };
> +};
> +
> +&i2c1 {
> +       status = "okay";
> +
> +       tmp75 at 4b {
> +               compatible = "ti,tmp75";
> +               reg = <0x4b>;
> +       };
> +};
> +
> +&i2c2 {
> +       status = "okay";
> +
> +       max31790 at 30{
> +               compatible = "max31790";
> +               reg = <0x30>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +       };
> +};
> +
> +&i2c3 {
> +       status = "okay";
> +
> +       i2c-mux at 70 {
> +               compatible = "nxp,pca9543";
> +               reg = <0x70>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               imux20: i2c at 0 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <0>;
> +                       //Retimer Flash
> +                       eeprom at 50 {
> +                               compatible = "atmel,24c2048";
> +                               reg = <0x50>;
> +                               pagesize = <128>;
> +                       };
> +               };
> +               imux21: i2c at 1 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <1>;
> +               };
> +       };
> +};
> +
> +&i2c4 {
> +       status = "okay";
> +       // PDB FRU
> +       eeprom at 52 {
> +               compatible = "atmel,24c64";
> +               reg = <0x52>;
> +       };
> +
> +       delta_brick at 69 {
> +               compatible = "pmbus";
> +               reg = <0x69>;
> +       };
> +};
> +
> +&i2c5 {
> +       status = "okay";
> +};
> +
> +&i2c6 {
> +       status = "okay";
> +
> +       i2c-mux at 70 {
> +               compatible = "nxp,pca9543";
> +               reg = <0x70>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               imux22: i2c at 0 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <0>;
> +               };
> +               imux23: i2c at 1 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <1>;
> +               };
> +       };
> +};
> +
> +&i2c7 {
> +       status = "okay";
> +};
> +
> +&i2c8 {
> +       status = "okay";
> +};
> +
> +&i2c9 {
> +       status = "okay";
> +
> +       gpio at 30 {
> +               compatible = "nxp,pca9555";
> +               reg = <0x30>;
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +       };
> +       gpio at 31 {
> +               compatible = "nxp,pca9555";
> +               reg = <0x31>;
> +               gpio-controller;
> +               #gpio-cells = <2>;
> +       };
> +
> +       i2c-mux at 71 {
> +               compatible = "nxp,pca9546";
> +               reg = <0x71>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               imux24: i2c at 0 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <0>;
> +               };
> +               imux25: i2c at 1 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <1>;
> +               };
> +               imux26: i2c at 2 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <2>;
> +               };
> +               imux27: i2c at 3 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <3>;
> +               };
> +       };
> +       // PTTV FRU
> +       eeprom at 52 {
> +               compatible = "atmel,24c64";
> +               reg = <0x52>;
> +       };
> +};
> +
> +&i2c11 {
> +       status = "okay";
> +};
> +
> +&i2c12 {
> +       status = "okay";
> +};
> +
> +&i2c13 {
> +       status = "okay";
> +
> +       i2c-mux at 70 {
> +               compatible = "nxp,pca9545";
> +               reg = <0x70>;
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               imux28: i2c at 0 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <0>;
> +               };
> +               imux29: i2c at 1 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <1>;
> +                       //MB FRU
> +                       eeprom at 54 {
> +                               compatible = "atmel,24c64";
> +                               reg = <0x54>;
> +                       };
> +               };
> +               imux30: i2c at 2 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <2>;
> +               };
> +               imux31: i2c at 3 {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +                       reg = <3>;
> +               };
> +       };
> +};
> +
> +// To Debug card
> +&i2c14 {
> +       status = "okay";
> +       multi-master;
> +
> +       ipmb at 10 {
> +               compatible = "ipmb-dev";
> +               reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
> +               i2c-protocol;
> +       };
> +};
> +
> +&i2c15 {
> +       status = "okay";
> +
> +       // SCM FRU
> +       eeprom at 50 {
> +               compatible = "atmel,24c64";
> +               reg = <0x50>;
> +       };
> +
> +       // BSM FRU
> +       eeprom at 56 {
> +               compatible = "atmel,24c64";
> +               reg = <0x56>;
> +       };
> +};
> +
> +&adc0 {
> +       aspeed,int-vref-microvolt = <2500000>;
> +       status = "okay";
> +       pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
> +               &pinctrl_adc2_default &pinctrl_adc3_default
> +               &pinctrl_adc4_default &pinctrl_adc5_default
> +               &pinctrl_adc6_default &pinctrl_adc7_default>;
> +};
> +
> +&adc1 {
> +       aspeed,int-vref-microvolt = <2500000>;
> +       status = "okay";
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_adc10_default>;
> +};
> +
> +&ehci0 {
> +       status = "okay";
> +};
> +
> +&gpio0 {
> +       pinctrl-names = "default";
> +       gpio-line-names =
> +       /*A0-A7*/       "","","","","","","","",
> +       /*B0-B7*/       "","","","",
> +                       "bmc-spi-mux-select-0","led-identify","","",
> +       /*C0-C7*/       "","","","","","","","",
> +       /*D0-D7*/       "","","sol-uart-select","","","","","",
> +       /*E0-E7*/       "","","","","","","","",
> +       /*F0-F7*/       "","","","","","","","",
> +       /*G0-G7*/       "","","","","","","","",
> +       /*H0-H7*/       "","","","","","","","",
> +       /*I0-I7*/       "","","","","","","","",
> +       /*J0-J7*/       "","","","","","","","",
> +       /*K0-K7*/       "","","","","","","","",
> +       /*L0-L7*/       "","","","","","","","",
> +       /*M0-M7*/       "","","","","","","","",
> +       /*N0-N7*/       "led-postcode-0","led-postcode-1",
> +                       "led-postcode-2","led-postcode-3",
> +                       "led-postcode-4","led-postcode-5",
> +                       "led-postcode-6","led-postcode-7",
> +       /*O0-O7*/       "","","","","","","","",
> +       /*P0-P7*/       "power-button","power-host-control",
> +                       "reset-button","","led-power","","","",
> +       /*Q0-Q7*/       "","","","","","","","",
> +       /*R0-R7*/       "","","","","","","","",
> +       /*S0-S7*/       "","","","","","","","",
> +       /*T0-T7*/       "","","","","","","","",
> +       /*U0-U7*/       "","","","","","","led-identify-gate","",
> +       /*V0-V7*/       "","","","",
> +                       "rtc-battery-voltage-read-enable","","","",
> +       /*W0-W7*/       "","","","","","","","",
> +       /*X0-X7*/       "","","","","","","","",
> +       /*Y0-Y7*/       "","","","","","","","",
> +       /*Z0-Z7*/       "","","","","","","","";
> +};
> +
> +&sgpiom0 {
> +       status = "okay";
> +       max-ngpios = <128>;
> +       ngpios = <128>;
> +       bus-frequency = <2000000>;
> +       gpio-line-names =
> +       /*in - out - in - out */
> +       /*A0-A3 line 0-7*/
> +       "presence-scm-cable","power-config-disable-e1s-0",
> +       "","",
> +       "","power-config-disable-e1s-1",
> +       "","",
> +       /*A4-A7 line 8-15*/
> +       "","power-config-asic-module-enable",
> +       "","power-config-asic-power-good",
> +       "","power-config-pdb-power-good",
> +       "presence-cpu","smi-control-n",
> +       /*B0-B3 line 16-23*/
> +       "","nmi-control-n",
> +       "","nmi-control-sync-flood-n",
> +       "","",
> +       "","",
> +       /*B4-B7 line 24-31*/
> +       "","FM_CPU_SP5R1",
> +       "reset-cause-rsmrst","FM_CPU_SP5R2",
> +       "","FM_CPU_SP5R3",
> +       "","FM_CPU_SP5R4",
> +       /*C0-C3 line 32-39*/
> +       "","FM_CPU0_SA0",
> +       "","FM_CPU0_SA1",
> +       "","rt-cpu0-p0-enable",
> +       "","rt-cpu0-p1-enable",
> +       /*C4-C7 line 40-47*/
> +       "","smb-rt-rom-p0-select",
> +       "","smb-rt-rom-p1-select",
> +       "","i3c-cpu-mux0-oe-n",
> +       "","i3c-cpu-mux0-select",
> +       /*D0-D3 line 48-55*/
> +       "","i3c-cpu-mux1-oe-n",
> +       "","i3c-cpu-mux1-select",
> +       "","reset-control-bmc",
> +       "","reset-control-cpu0-p0-mux",
> +       /*D4-D7 line 56-63*/
> +       "","reset-control-cpu0-p1-mux",
> +       "","reset-control-e1s-mux",
> +       "power-host-good","reset-control-mb-mux",
> +       "","reset-control-smb-e1s",
> +       /*E0-E3 line 64-71*/
> +       "","reset-control-smb-e1s",
> +       "host-ready-n","reset-control-srst",
> +       "presence-e1s-0","reset-control-usb-hub",
> +       "","reset-control",
> +       /*E4-E7 line 72-79*/
> +       "presence-e1s-1","reset-control-cpu-kbrst",
> +       "","reset-control-platrst",
> +       "","bmc-jtag-mux-select-0",
> +       "","bmc-jtag-mux-select-1",
> +       /*F0-F3 line 80-87*/
> +       "","bmc-jtag-select",
> +       "","bmc-ready-n",
> +       "","bmc-ready-sgpio",
> +       "","rt-cpu0-p0-force-enable",
> +       /*F4-F7 line 88-95*/
> +       "presence-asic-modules-0","rt-cpu0-p1-force-enable",
> +       "presence-asic-modules-1","bios-debug-msg-disable",
> +       "","uart-control-buffer-select",
> +       "","ac-control-n",
> +       /*G0-G3 line 96-103*/
> +       "FM_CPU_CORETYPE2","",
> +       "FM_CPU_CORETYPE1","",
> +       "FM_CPU_CORETYPE0","",
> +       "FM_BOARD_REV_ID5","",
> +       /*G4-G7 line 104-111*/
> +       "FM_BOARD_REV_ID4","",
> +       "FM_BOARD_REV_ID3","",
> +       "FM_BOARD_REV_ID2","",
> +       "FM_BOARD_REV_ID1","",
> +       /*H0-H3 line 112-119*/
> +       "FM_BOARD_REV_ID0","",
> +       "","","","","","",
> +       /*H4-H7 line 120-127*/
> +       "","",
> +       "reset-control-pcie-expansion-3","",
> +       "reset-control-pcie-expansion-2","",
> +       "reset-control-pcie-expansion-1","",
> +       /*I0-I3 line 128-135*/
> +       "reset-control-pcie-expansion-0","",
> +       "FM_EXP_SLOT_ID1","",
> +       "FM_EXP_SLOT_ID0","",
> +       "","",
> +       /*I4-I7 line 136-143*/
> +       "","","","","","","","",
> +       /*J0-J3 line 144-151*/
> +       "","","","","","","","",
> +       /*J4-J7 line 152-159*/
> +       "SLOT_ID_BCB_0","",
> +       "SLOT_ID_BCB_1","",
> +       "SLOT_ID_BCB_2","",
> +       "SLOT_ID_BCB_3","",
> +       /*K0-K3 line 160-167*/
> +       "","","","","","","","",
> +       /*K4-K7 line 168-175*/
> +       "","","","","","","","",
> +       /*L0-L3 line 176-183*/
> +       "","","","","","","","",
> +       /*L4-L7 line 184-191*/
> +       "","","","","","","","",
> +       /*M0-M3 line 192-199*/
> +       "","","","","","","","",
> +       /*M4-M7 line 200-207*/
> +       "","","","","","","","",
> +       /*N0-N3 line 208-215*/
> +       "","","","","","","","",
> +       /*N4-N7 line 216-223*/
> +       "","","","","","","","",
> +       /*O0-O3 line 224-231*/
> +       "","","","","","","","",
> +       /*O4-O7 line 232-239*/
> +       "","","","","","","","",
> +       /*P0-P3 line 240-247*/
> +       "","","","","","","","",
> +       /*P4-P7 line 248-255*/
> +       "","","","","","","","";
> +};
> --
> 2.25.1
>


From joel at jms.id.au  Mon Dec 11 18:39:56 2023
From: joel at jms.id.au (Joel Stanley)
Date: Tue, 12 Dec 2023 13:09:56 +1030
Subject: [PATCH v4 0/2] i2c: aspeed: Late ack Tx done irqs and handle
 coalesced start with stop conditions
In-Reply-To: <20231211102217.2436294-1-quan@os.amperecomputing.com>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
Message-ID: <CACPK8Xc6-M9fsx3AUPobzvG6sjCrr8Sj5B3Q4Onp5wGvMm_BrA@mail.gmail.com>

On Mon, 11 Dec 2023 at 20:52, Quan Nguyen <quan at os.amperecomputing.com> wrote:
>
> This series consists of two patches to handle the below issues observed
> when testing with slave mode:
>   + The coalesced stop condition with the start conditions
>   + Early ack'ed of Tx done (ACK and NAK) causing "Unexpected Ack on
>   read request".

Looks good. I've reached out to a few people who use slave mode to ask
for review and testing on hardware. As long as they don't come back
with issues, we should get this merged and backported to stable.

Reviewed-by: Joel Stanley <joel at jms.id.au>

Cheers,

Joel


From yong.wu at mediatek.com  Mon Dec 11 18:46:02 2023
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 12 Dec 2023 10:46:02 +0800
Subject: [PATCH v3 2/7] dma-buf: heaps: Initialize a secure heap
In-Reply-To: <20231212024607.3681-1-yong.wu@mediatek.com>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
Message-ID: <20231212024607.3681-3-yong.wu@mediatek.com>

Initialize a secure heap. Currently just add a null heap, Prepare for
the later patches.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/dma-buf/heaps/Kconfig       |  6 +++
 drivers/dma-buf/heaps/Makefile      |  1 +
 drivers/dma-buf/heaps/secure_heap.c | 67 +++++++++++++++++++++++++++++
 drivers/dma-buf/heaps/secure_heap.h | 22 ++++++++++
 4 files changed, 96 insertions(+)
 create mode 100644 drivers/dma-buf/heaps/secure_heap.c
 create mode 100644 drivers/dma-buf/heaps/secure_heap.h

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..3a9943e94200 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -12,3 +12,9 @@ config DMABUF_HEAPS_CMA
 	  Choose this option to enable dma-buf CMA heap. This heap is backed
 	  by the Contiguous Memory Allocator (CMA). If your system has these
 	  regions, you should say Y here.
+
+config DMABUF_HEAPS_SECURE
+	bool "DMA-BUF Secure Heap"
+	depends on DMABUF_HEAPS
+	help
+	  Choose this option to enable dma-buf secure heap. If in doubt, say N.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 974467791032..b1ad9d1f2fbe 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DMABUF_HEAPS_SECURE)	+= secure_heap.o
 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)	+= system_heap.o
 obj-$(CONFIG_DMABUF_HEAPS_CMA)		+= cma_heap.o
diff --git a/drivers/dma-buf/heaps/secure_heap.c b/drivers/dma-buf/heaps/secure_heap.c
new file mode 100644
index 000000000000..e087da5638aa
--- /dev/null
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF secure heap exporter
+ *
+ * Copyright (C) 2023 MediaTek Inc.
+ */
+
+#include <linux/dma-buf.h>
+#include <linux/dma-heap.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+
+#include "secure_heap.h"
+
+static struct dma_buf *
+secure_heap_allocate(struct dma_heap *heap, unsigned long size,
+		     unsigned long fd_flags, unsigned long heap_flags)
+{
+	struct secure_buffer *sec_buf;
+	DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+	struct dma_buf *dmabuf;
+	int ret;
+
+	sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
+	if (!sec_buf)
+		return ERR_PTR(-ENOMEM);
+
+	sec_buf->size = ALIGN(size, PAGE_SIZE);
+	sec_buf->heap = heap;
+
+	exp_info.exp_name = dma_heap_get_name(heap);
+	exp_info.size = sec_buf->size;
+	exp_info.flags = fd_flags;
+	exp_info.priv = sec_buf;
+
+	dmabuf = dma_buf_export(&exp_info);
+	if (IS_ERR(dmabuf)) {
+		ret = PTR_ERR(dmabuf);
+		goto err_free_buf;
+	}
+
+	return dmabuf;
+
+err_free_buf:
+	kfree(sec_buf);
+	return ERR_PTR(ret);
+}
+
+static const struct dma_heap_ops sec_heap_ops = {
+	.allocate = secure_heap_allocate,
+};
+
+int secure_heap_add(struct secure_heap *sec_heap)
+{
+	struct dma_heap_export_info exp_info;
+	struct dma_heap *heap;
+
+	exp_info.name = sec_heap->name;
+	exp_info.ops = &sec_heap_ops;
+	exp_info.priv = (void *)sec_heap;
+
+	heap = dma_heap_add(&exp_info);
+	if (IS_ERR(heap))
+		return PTR_ERR(heap);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(secure_heap_add);
diff --git a/drivers/dma-buf/heaps/secure_heap.h b/drivers/dma-buf/heaps/secure_heap.h
new file mode 100644
index 000000000000..50733dc6d4db
--- /dev/null
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Secure heap Header.
+ *
+ * Copyright (C) 2023 MediaTek, Inc.
+ */
+
+#ifndef _DMABUF_SECURE_HEAP_H_
+#define _DMABUF_SECURE_HEAP_H_
+
+struct secure_buffer {
+	struct dma_heap		*heap;
+	size_t			size;
+};
+
+struct secure_heap {
+	const char		*name;
+};
+
+int secure_heap_add(struct secure_heap *sec_heap);
+
+#endif
-- 
2.25.1



From yong.wu at mediatek.com  Mon Dec 11 18:46:03 2023
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 12 Dec 2023 10:46:03 +0800
Subject: [PATCH v3 3/7] dma-buf: heaps: secure_heap: Add private heap ops
In-Reply-To: <20231212024607.3681-1-yong.wu@mediatek.com>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
Message-ID: <20231212024607.3681-4-yong.wu@mediatek.com>

Add "struct secure_heap_ops". For the secure memory, totally there are
two steps:
a) memory_alloc: Allocate the buffer in kernel;
b) secure_the_memory: Secure/Proect that buffer.
The memory_alloc is mandatory while secure_the_memory is optinal since
it may be part of memory_alloc.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/dma-buf/heaps/secure_heap.c | 39 ++++++++++++++++++++++++++++-
 drivers/dma-buf/heaps/secure_heap.h | 11 ++++++++
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/heaps/secure_heap.c b/drivers/dma-buf/heaps/secure_heap.c
index e087da5638aa..925cf8e1c7ce 100644
--- a/drivers/dma-buf/heaps/secure_heap.c
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -12,10 +12,42 @@
 
 #include "secure_heap.h"
 
+static int secure_heap_memory_allocate(struct secure_heap *sec_heap, struct secure_buffer *sec_buf)
+{
+	const struct secure_heap_ops *ops = sec_heap->ops;
+	int ret;
+
+	ret = ops->memory_alloc(sec_heap, sec_buf);
+	if (ret)
+		return ret;
+
+	if (ops->secure_the_memory) {
+		ret = ops->secure_the_memory(sec_heap, sec_buf);
+		if (ret)
+			goto sec_memory_free;
+	}
+	return 0;
+
+sec_memory_free:
+	ops->memory_free(sec_heap, sec_buf);
+	return ret;
+}
+
+static void secure_heap_memory_free(struct secure_heap *sec_heap, struct secure_buffer *sec_buf)
+{
+	const struct secure_heap_ops *ops = sec_heap->ops;
+
+	if (ops->unsecure_the_memory)
+		ops->unsecure_the_memory(sec_heap, sec_buf);
+
+	ops->memory_free(sec_heap, sec_buf);
+}
+
 static struct dma_buf *
 secure_heap_allocate(struct dma_heap *heap, unsigned long size,
 		     unsigned long fd_flags, unsigned long heap_flags)
 {
+	struct secure_heap *sec_heap = dma_heap_get_drvdata(heap);
 	struct secure_buffer *sec_buf;
 	DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
 	struct dma_buf *dmabuf;
@@ -28,6 +60,9 @@ secure_heap_allocate(struct dma_heap *heap, unsigned long size,
 	sec_buf->size = ALIGN(size, PAGE_SIZE);
 	sec_buf->heap = heap;
 
+	ret = secure_heap_memory_allocate(sec_heap, sec_buf);
+	if (ret)
+		goto err_free_buf;
 	exp_info.exp_name = dma_heap_get_name(heap);
 	exp_info.size = sec_buf->size;
 	exp_info.flags = fd_flags;
@@ -36,11 +71,13 @@ secure_heap_allocate(struct dma_heap *heap, unsigned long size,
 	dmabuf = dma_buf_export(&exp_info);
 	if (IS_ERR(dmabuf)) {
 		ret = PTR_ERR(dmabuf);
-		goto err_free_buf;
+		goto err_free_sec_mem;
 	}
 
 	return dmabuf;
 
+err_free_sec_mem:
+	secure_heap_memory_free(sec_heap, sec_buf);
 err_free_buf:
 	kfree(sec_buf);
 	return ERR_PTR(ret);
diff --git a/drivers/dma-buf/heaps/secure_heap.h b/drivers/dma-buf/heaps/secure_heap.h
index 50733dc6d4db..ec5349cd28d0 100644
--- a/drivers/dma-buf/heaps/secure_heap.h
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -15,6 +15,17 @@ struct secure_buffer {
 
 struct secure_heap {
 	const char		*name;
+
+	const struct secure_heap_ops *ops;
+};
+
+struct secure_heap_ops {
+	int	(*memory_alloc)(struct secure_heap *sec_heap, struct secure_buffer *sec_buf);
+	void	(*memory_free)(struct secure_heap *sec_heap, struct secure_buffer *sec_buf);
+
+	/* Protect/unprotect the memory */
+	int	(*secure_the_memory)(struct secure_heap *sec_heap, struct secure_buffer *sec_buf);
+	void	(*unsecure_the_memory)(struct secure_heap *sec_heap, struct secure_buffer *sec_buf);
 };
 
 int secure_heap_add(struct secure_heap *sec_heap);
-- 
2.25.1



From yong.wu at mediatek.com  Mon Dec 11 18:46:01 2023
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 12 Dec 2023 10:46:01 +0800
Subject: [PATCH v3 1/7] dt-bindings: reserved-memory: Add mediatek,dynamic-secure-region
In-Reply-To: <20231212024607.3681-1-yong.wu@mediatek.com>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
Message-ID: <20231212024607.3681-2-yong.wu@mediatek.com>

Add a binding for describing the dynamic secure reserved memory range. The
memory range also will be defined in the TEE firmware. It means the TEE
will be configured with the same address/size that is being set in this
DT node. Regarding to the detail TEE command, Please search
MTK_TZCMD_SECMEM_ZALLOC and MTK_TZCMD_SECMEM_FREE.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 .../mediatek,dynamic-secure-region.yaml       | 43 +++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml

diff --git a/Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml b/Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml
new file mode 100644
index 000000000000..4a735aeafc62
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/mediatek,dynamic-secure-region.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Dynamic Reserved Region
+
+description:
+  A memory region that can dynamically transition as a whole between
+  secure and non-secure states. This memory will be protected by OP-TEE
+  when allocations are active and unprotected otherwise.
+
+maintainers:
+  - Yong Wu <yong.wu at mediatek.com>
+
+allOf:
+  - $ref: reserved-memory.yaml
+
+properties:
+  compatible:
+    const: mediatek,dynamic-secure-region
+
+required:
+  - compatible
+  - reg
+  - reusable
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    reserved-memory {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+
+        reserved-memory at 80000000 {
+            compatible = "mediatek,dynamic-secure-region";
+            reg = <0x80000000 0x18000000>;
+            reusable;
+        };
+    };
-- 
2.25.1



From yong.wu at mediatek.com  Mon Dec 11 18:46:04 2023
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 12 Dec 2023 10:46:04 +0800
Subject: [PATCH v3 4/7] dma-buf: heaps: secure_heap: Add dma_ops
In-Reply-To: <20231212024607.3681-1-yong.wu@mediatek.com>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
Message-ID: <20231212024607.3681-5-yong.wu@mediatek.com>

Add the dma_ops for this secure heap. For secure buffer, cache_ops/mmap
are not allowed, thus return EPERM for them.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/dma-buf/heaps/secure_heap.c | 103 ++++++++++++++++++++++++++++
 1 file changed, 103 insertions(+)

diff --git a/drivers/dma-buf/heaps/secure_heap.c b/drivers/dma-buf/heaps/secure_heap.c
index 925cf8e1c7ce..7cb4db3e55c2 100644
--- a/drivers/dma-buf/heaps/secure_heap.c
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -12,6 +12,10 @@
 
 #include "secure_heap.h"
 
+struct secure_heap_attachment {
+	struct sg_table			*table;
+};
+
 static int secure_heap_memory_allocate(struct secure_heap *sec_heap, struct secure_buffer *sec_buf)
 {
 	const struct secure_heap_ops *ops = sec_heap->ops;
@@ -43,6 +47,104 @@ static void secure_heap_memory_free(struct secure_heap *sec_heap, struct secure_
 	ops->memory_free(sec_heap, sec_buf);
 }
 
+static int secure_heap_attach(struct dma_buf *dmabuf, struct dma_buf_attachment *attachment)
+{
+	struct secure_buffer *sec_buf = dmabuf->priv;
+	struct secure_heap_attachment *a;
+	struct sg_table *table;
+	int ret;
+
+	a = kzalloc(sizeof(*a), GFP_KERNEL);
+	if (!a)
+		return -ENOMEM;
+
+	table = kzalloc(sizeof(*table), GFP_KERNEL);
+	if (!table) {
+		ret = -ENOMEM;
+		goto err_free_attach;
+	}
+
+	ret = sg_alloc_table(table, 1, GFP_KERNEL);
+	if (ret)
+		goto err_free_sgt;
+	sg_set_page(table->sgl, NULL, sec_buf->size, 0);
+
+	a->table = table;
+	attachment->priv = a;
+
+	return 0;
+
+err_free_sgt:
+	kfree(table);
+err_free_attach:
+	kfree(a);
+	return ret;
+}
+
+static void secure_heap_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attachment)
+{
+	struct secure_heap_attachment *a = attachment->priv;
+
+	sg_free_table(a->table);
+	kfree(a->table);
+	kfree(a);
+}
+
+static struct sg_table *
+secure_heap_map_dma_buf(struct dma_buf_attachment *attachment, enum dma_data_direction direction)
+{
+	struct secure_heap_attachment *a = attachment->priv;
+	struct sg_table *table = a->table;
+
+	return table;
+}
+
+static void
+secure_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, struct sg_table *table,
+			  enum dma_data_direction direction)
+{
+	struct secure_heap_attachment *a = attachment->priv;
+
+	WARN_ON(a->table != table);
+}
+
+static int
+secure_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, enum dma_data_direction direction)
+{
+	return -EPERM;
+}
+
+static int
+secure_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf, enum dma_data_direction direction)
+{
+	return -EPERM;
+}
+
+static int secure_heap_dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+	return -EPERM;
+}
+
+static void secure_heap_free(struct dma_buf *dmabuf)
+{
+	struct secure_buffer *sec_buf = dmabuf->priv;
+	struct secure_heap *sec_heap = dma_heap_get_drvdata(sec_buf->heap);
+
+	secure_heap_memory_free(sec_heap, sec_buf);
+	kfree(sec_buf);
+}
+
+static const struct dma_buf_ops sec_heap_buf_ops = {
+	.attach		= secure_heap_attach,
+	.detach		= secure_heap_detach,
+	.map_dma_buf	= secure_heap_map_dma_buf,
+	.unmap_dma_buf	= secure_heap_unmap_dma_buf,
+	.begin_cpu_access = secure_heap_dma_buf_begin_cpu_access,
+	.end_cpu_access	= secure_heap_dma_buf_end_cpu_access,
+	.mmap		= secure_heap_dma_buf_mmap,
+	.release	= secure_heap_free,
+};
+
 static struct dma_buf *
 secure_heap_allocate(struct dma_heap *heap, unsigned long size,
 		     unsigned long fd_flags, unsigned long heap_flags)
@@ -64,6 +166,7 @@ secure_heap_allocate(struct dma_heap *heap, unsigned long size,
 	if (ret)
 		goto err_free_buf;
 	exp_info.exp_name = dma_heap_get_name(heap);
+	exp_info.ops = &sec_heap_buf_ops;
 	exp_info.size = sec_buf->size;
 	exp_info.flags = fd_flags;
 	exp_info.priv = sec_buf;
-- 
2.25.1



From yong.wu at mediatek.com  Mon Dec 11 18:46:06 2023
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 12 Dec 2023 10:46:06 +0800
Subject: [PATCH v3 6/7] dma-buf: heaps: secure_heap_mtk: Add tee memory service call
In-Reply-To: <20231212024607.3681-1-yong.wu@mediatek.com>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
Message-ID: <20231212024607.3681-7-yong.wu@mediatek.com>

Add TEE service call for MediaTek heap. We have a limited number of
hardware entries to protect memory, therefore we cannot protect memory
arbitrarily, then our secure memory management is actually inside OPTEE.
The kernel just tells the TEE what size I want and the TEE will return a
"secure address". The secure_address is a reference to a secure buffer
within TEE. We put it in the sg_dma_address, please see the comment in
code.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/dma-buf/heaps/secure_heap.c     | 16 +++++
 drivers/dma-buf/heaps/secure_heap.h     |  2 +
 drivers/dma-buf/heaps/secure_heap_mtk.c | 92 +++++++++++++++++++++++++
 3 files changed, 110 insertions(+)

diff --git a/drivers/dma-buf/heaps/secure_heap.c b/drivers/dma-buf/heaps/secure_heap.c
index ca4b433fb3f1..e2b8b97ad4dc 100644
--- a/drivers/dma-buf/heaps/secure_heap.c
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -94,8 +94,22 @@ static struct sg_table *
 secure_heap_map_dma_buf(struct dma_buf_attachment *attachment, enum dma_data_direction direction)
 {
 	struct secure_heap_attachment *a = attachment->priv;
+	struct dma_buf *dmabuf = attachment->dmabuf;
+	struct secure_buffer *sec_buf = dmabuf->priv;
 	struct sg_table *table = a->table;
 
+	/*
+	 * Technically dma_address refers to the address used by HW, But for secure buffer
+	 * we don't know its dma_address in kernel, Instead, we only know its "secure handle".
+	 * Thus use this property to save the "secure handle", and the user will use it to
+	 * obtain the real address in secure world.
+	 *
+	 * Note: CONFIG_DMA_API_DEBUG requires it to be aligned with PAGE_SIZE.
+	 */
+	if (sec_buf->secure_address) {
+		sg_dma_address(table->sgl) = sec_buf->secure_address;
+		sg_dma_len(table->sgl) = sec_buf->size;
+	}
 	return table;
 }
 
@@ -106,6 +120,8 @@ secure_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, struct sg_table
 	struct secure_heap_attachment *a = attachment->priv;
 
 	WARN_ON(a->table != table);
+	sg_dma_address(table->sgl) = 0;
+	sg_dma_len(table->sgl) = 0;
 }
 
 static int
diff --git a/drivers/dma-buf/heaps/secure_heap.h b/drivers/dma-buf/heaps/secure_heap.h
index 1ce9c431d989..374fd276bdd7 100644
--- a/drivers/dma-buf/heaps/secure_heap.h
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -11,6 +11,8 @@
 struct secure_buffer {
 	struct dma_heap		*heap;
 	size_t			size;
+
+	u64			secure_address; /* A reference to the buffer in the secure world */
 };
 
 struct secure_heap {
diff --git a/drivers/dma-buf/heaps/secure_heap_mtk.c b/drivers/dma-buf/heaps/secure_heap_mtk.c
index c7e609dd7bd3..2c6aaeaf469f 100644
--- a/drivers/dma-buf/heaps/secure_heap_mtk.c
+++ b/drivers/dma-buf/heaps/secure_heap_mtk.c
@@ -25,6 +25,27 @@ enum mtk_secure_mem_type {
 	MTK_SECURE_MEMORY_TYPE_CM_TZ	= 1,
 };
 
+enum mtk_secure_buffer_tee_cmd {
+	/*
+	 * Allocate the zeroed secure memory from TEE.
+	 *
+	 * [in]  value[0].a: The buffer size.
+	 *       value[0].b: alignment.
+	 * [in]  value[1].a: enum mtk_secure_mem_type.
+	 * [out] value[3].a: The secure handle.
+	 */
+	MTK_TZCMD_SECMEM_ZALLOC	= 0x10000, /* MTK TEE Command ID Base */
+
+	/*
+	 * Free secure memory.
+	 *
+	 * [in]  value[0].a: The secure handle of this buffer, It's value[3].a of
+	 *                   MTK_TZCMD_SECMEM_ZALLOC.
+	 * [out] value[1].a: return value, 0 means successful, otherwise fail.
+	 */
+	MTK_TZCMD_SECMEM_FREE	= 0x10001,
+};
+
 struct mtk_secure_heap_data {
 	struct tee_context	*tee_ctx;
 	u32			tee_session;
@@ -74,6 +95,73 @@ static int mtk_tee_session_init(struct mtk_secure_heap_data *data)
 	return ret;
 }
 
+static int
+mtk_tee_service_call(struct tee_context *tee_ctx, u32 session,
+		     unsigned int command, struct tee_param *params)
+{
+	struct tee_ioctl_invoke_arg arg = {0};
+	int ret;
+
+	arg.num_params = TEE_PARAM_NUM;
+	arg.session = session;
+	arg.func = command;
+
+	ret = tee_client_invoke_func(tee_ctx, &arg, params);
+	if (ret < 0 || arg.ret) {
+		pr_err("%s: cmd %d ret %d:%x.\n", __func__, command, ret, arg.ret);
+		ret = -EOPNOTSUPP;
+	}
+	return ret;
+}
+
+static int mtk_tee_secure_memory(struct secure_heap *sec_heap, struct secure_buffer *sec_buf)
+{
+	struct mtk_secure_heap_data *data = sec_heap->priv_data;
+	struct tee_param params[TEE_PARAM_NUM] = {0};
+	int ret;
+
+	params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+	params[0].u.value.a = sec_buf->size;
+	params[0].u.value.b = PAGE_SIZE;
+	params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+	params[1].u.value.a = data->mem_type;
+	params[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+	params[3].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
+	ret = mtk_tee_service_call(data->tee_ctx, data->tee_session,
+				   MTK_TZCMD_SECMEM_ZALLOC, params);
+	if (ret)
+		return -ENOMEM;
+
+	sec_buf->secure_address = params[3].u.value.a;
+	return 0;
+}
+
+static void mtk_tee_unsecure_memory(struct secure_heap *sec_heap, struct secure_buffer *sec_buf)
+{
+	struct mtk_secure_heap_data *data = sec_heap->priv_data;
+	struct tee_param params[TEE_PARAM_NUM] = {0};
+
+	params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+	params[0].u.value.a = sec_buf->secure_address;
+	params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
+
+	mtk_tee_service_call(data->tee_ctx, data->tee_session,
+			     MTK_TZCMD_SECMEM_FREE, params);
+	if (params[1].u.value.a)
+		pr_err("%s, unsecure buffer(0x%llx) fail(%lld) from TEE.\n",
+		       sec_heap->name, sec_buf->secure_address, params[1].u.value.a);
+}
+
+static int mtk_secure_memory_allocate(struct secure_heap *sec_heap, struct secure_buffer *sec_buf)
+{
+	/* The memory allocating is within the TEE. */
+	return 0;
+}
+
+static void mtk_secure_memory_free(struct secure_heap *sec_heap, struct secure_buffer *sec_buf)
+{
+}
+
 static int mtk_secure_heap_init(struct secure_heap *sec_heap)
 {
 	struct mtk_secure_heap_data *data = sec_heap->priv_data;
@@ -85,6 +173,10 @@ static int mtk_secure_heap_init(struct secure_heap *sec_heap)
 
 static const struct secure_heap_ops mtk_sec_mem_ops = {
 	.heap_init		= mtk_secure_heap_init,
+	.memory_alloc		= mtk_secure_memory_allocate,
+	.memory_free		= mtk_secure_memory_free,
+	.secure_the_memory	= mtk_tee_secure_memory,
+	.unsecure_the_memory	= mtk_tee_unsecure_memory,
 };
 
 static struct mtk_secure_heap_data mtk_sec_heap_data = {
-- 
2.25.1



From yong.wu at mediatek.com  Mon Dec 11 18:46:05 2023
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 12 Dec 2023 10:46:05 +0800
Subject: [PATCH v3 5/7] dma-buf: heaps: secure_heap: Add MediaTek secure heap and heap_init
In-Reply-To: <20231212024607.3681-1-yong.wu@mediatek.com>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
Message-ID: <20231212024607.3681-6-yong.wu@mediatek.com>

Add a Mediatek secure heap which uses TEE service call to protect
buffer. Currently this secure heap is NULL, Prepare for the later patch.
Mainly there are two changes:
a) Add a heap_init ops since TEE probe late than secure heap, thus
   initialize the heap when we require the buffer the first time.
b) Add a priv_data for each heap, like the special data used by MTK
   (such as "TEE session") can be placed in priv_data.

Currently our heap depends on CMA which could only be bool, thus
depend on "TEE=y".

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/dma-buf/heaps/Kconfig           |   7 ++
 drivers/dma-buf/heaps/Makefile          |   1 +
 drivers/dma-buf/heaps/secure_heap.c     |  11 +++
 drivers/dma-buf/heaps/secure_heap.h     |   4 +
 drivers/dma-buf/heaps/secure_heap_mtk.c | 114 ++++++++++++++++++++++++
 5 files changed, 137 insertions(+)
 create mode 100644 drivers/dma-buf/heaps/secure_heap_mtk.c

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 3a9943e94200..12962189878e 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -18,3 +18,10 @@ config DMABUF_HEAPS_SECURE
 	depends on DMABUF_HEAPS
 	help
 	  Choose this option to enable dma-buf secure heap. If in doubt, say N.
+
+config DMABUF_HEAPS_SECURE_MTK
+	bool "MediaTek DMA-BUF Secure Heap"
+	depends on DMABUF_HEAPS_SECURE && TEE=y
+	help
+	  Enable secure dma-buf heaps for MediaTek platform. This heap is backed by
+	  TEE client interfaces. If in doubt, say N.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index b1ad9d1f2fbe..9751dea345df 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DMABUF_HEAPS_SECURE)	+= secure_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_SECURE_MTK)	+= secure_heap_mtk.o
 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)	+= system_heap.o
 obj-$(CONFIG_DMABUF_HEAPS_CMA)		+= cma_heap.o
diff --git a/drivers/dma-buf/heaps/secure_heap.c b/drivers/dma-buf/heaps/secure_heap.c
index 7cb4db3e55c2..ca4b433fb3f1 100644
--- a/drivers/dma-buf/heaps/secure_heap.c
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -150,11 +150,22 @@ secure_heap_allocate(struct dma_heap *heap, unsigned long size,
 		     unsigned long fd_flags, unsigned long heap_flags)
 {
 	struct secure_heap *sec_heap = dma_heap_get_drvdata(heap);
+	const struct secure_heap_ops *ops = sec_heap->ops;
 	struct secure_buffer *sec_buf;
 	DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
 	struct dma_buf *dmabuf;
 	int ret;
 
+	/*
+	 * In some implements, TEE is required to protect buffer. However TEE probe
+	 * may be late, Thus heap_init is performed when the first buffer is requested.
+	 */
+	if (ops->heap_init) {
+		ret = ops->heap_init(sec_heap);
+		if (ret)
+			return ERR_PTR(ret);
+	}
+
 	sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
 	if (!sec_buf)
 		return ERR_PTR(-ENOMEM);
diff --git a/drivers/dma-buf/heaps/secure_heap.h b/drivers/dma-buf/heaps/secure_heap.h
index ec5349cd28d0..1ce9c431d989 100644
--- a/drivers/dma-buf/heaps/secure_heap.h
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -17,9 +17,13 @@ struct secure_heap {
 	const char		*name;
 
 	const struct secure_heap_ops *ops;
+
+	void			*priv_data;
 };
 
 struct secure_heap_ops {
+	int	(*heap_init)(struct secure_heap *sec_heap);
+
 	int	(*memory_alloc)(struct secure_heap *sec_heap, struct secure_buffer *sec_buf);
 	void	(*memory_free)(struct secure_heap *sec_heap, struct secure_buffer *sec_buf);
 
diff --git a/drivers/dma-buf/heaps/secure_heap_mtk.c b/drivers/dma-buf/heaps/secure_heap_mtk.c
new file mode 100644
index 000000000000..c7e609dd7bd3
--- /dev/null
+++ b/drivers/dma-buf/heaps/secure_heap_mtk.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF MediaTek secure heap exporter
+ *
+ * Copyright (C) 2023 MediaTek Inc.
+ */
+#include <linux/dma-buf.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/tee_drv.h>
+#include <linux/uuid.h>
+
+#include "secure_heap.h"
+
+#define TZ_TA_MEM_UUID_MTK		"4477588a-8476-11e2-ad15-e41f1390d676"
+
+#define TEE_PARAM_NUM			4
+
+enum mtk_secure_mem_type {
+	/*
+	 * MediaTek static chunk memory carved out for TrustZone. The memory
+	 * management is inside the TEE.
+	 */
+	MTK_SECURE_MEMORY_TYPE_CM_TZ	= 1,
+};
+
+struct mtk_secure_heap_data {
+	struct tee_context	*tee_ctx;
+	u32			tee_session;
+
+	const enum mtk_secure_mem_type mem_type;
+
+};
+
+static int mtk_tee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
+{
+	return ver->impl_id == TEE_IMPL_ID_OPTEE;
+}
+
+static int mtk_tee_session_init(struct mtk_secure_heap_data *data)
+{
+	struct tee_param t_param[TEE_PARAM_NUM] = {0};
+	struct tee_ioctl_open_session_arg arg = {0};
+	uuid_t ta_mem_uuid;
+	int ret;
+
+	data->tee_ctx = tee_client_open_context(NULL, mtk_tee_ctx_match, NULL, NULL);
+	if (IS_ERR(data->tee_ctx)) {
+		pr_err_once("%s: open context failed, ret=%ld\n", __func__,
+			    PTR_ERR(data->tee_ctx));
+		return -ENODEV;
+	}
+
+	arg.num_params = TEE_PARAM_NUM;
+	arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
+	ret = uuid_parse(TZ_TA_MEM_UUID_MTK, &ta_mem_uuid);
+	if (ret)
+		goto close_context;
+	memcpy(&arg.uuid, &ta_mem_uuid.b, sizeof(ta_mem_uuid));
+
+	ret = tee_client_open_session(data->tee_ctx, &arg, t_param);
+	if (ret < 0 || arg.ret) {
+		pr_err_once("%s: open session failed, ret=%d:%d\n",
+			    __func__, ret, arg.ret);
+		ret = -EINVAL;
+		goto close_context;
+	}
+	data->tee_session = arg.session;
+	return 0;
+
+close_context:
+	tee_client_close_context(data->tee_ctx);
+	return ret;
+}
+
+static int mtk_secure_heap_init(struct secure_heap *sec_heap)
+{
+	struct mtk_secure_heap_data *data = sec_heap->priv_data;
+
+	if (!data->tee_ctx)
+		return mtk_tee_session_init(data);
+	return 0;
+}
+
+static const struct secure_heap_ops mtk_sec_mem_ops = {
+	.heap_init		= mtk_secure_heap_init,
+};
+
+static struct mtk_secure_heap_data mtk_sec_heap_data = {
+	.mem_type = MTK_SECURE_MEMORY_TYPE_CM_TZ,
+};
+
+static struct secure_heap mtk_secure_heaps[] = {
+	{
+		.name		= "secure_mtk_cm",
+		.ops		= &mtk_sec_mem_ops,
+		.priv_data	= &mtk_sec_heap_data,
+	},
+};
+
+static int mtk_sec_heap_init(void)
+{
+	struct secure_heap *sec_heap = mtk_secure_heaps;
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(mtk_secure_heaps); i++, sec_heap++)
+		secure_heap_add(sec_heap);
+	return 0;
+}
+
+module_init(mtk_sec_heap_init);
+MODULE_DESCRIPTION("MediaTek Secure Heap Driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1



From yong.wu at mediatek.com  Mon Dec 11 18:46:07 2023
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 12 Dec 2023 10:46:07 +0800
Subject: [PATCH v3 7/7] dma_buf: heaps: secure_heap_mtk: Add a new CMA heap
In-Reply-To: <20231212024607.3681-1-yong.wu@mediatek.com>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
Message-ID: <20231212024607.3681-8-yong.wu@mediatek.com>

Create a new MediaTek CMA heap from the CMA reserved buffer.

In this heap, When the first allocating buffer, use cma_alloc to prepare
whole the CMA range, then send its range to TEE to protect and manage.
For the later allocating, we just adds the cma_used_size.

When SVP done, cma_release will release the buffer, then kernel may
reuse it.

For the "CMA" secure heap, "struct cma *cma" is a common property, not just
for MediaTek, so put it into "struct secure_heap" instead of our private
data.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/dma-buf/heaps/Kconfig           |   2 +-
 drivers/dma-buf/heaps/secure_heap.h     |   4 +
 drivers/dma-buf/heaps/secure_heap_mtk.c | 119 +++++++++++++++++++++++-
 3 files changed, 122 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 12962189878e..f117d91a0a9d 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -21,7 +21,7 @@ config DMABUF_HEAPS_SECURE
 
 config DMABUF_HEAPS_SECURE_MTK
 	bool "MediaTek DMA-BUF Secure Heap"
-	depends on DMABUF_HEAPS_SECURE && TEE=y
+	depends on DMABUF_HEAPS_SECURE && DMA_CMA && TEE=y
 	help
 	  Enable secure dma-buf heaps for MediaTek platform. This heap is backed by
 	  TEE client interfaces. If in doubt, say N.
diff --git a/drivers/dma-buf/heaps/secure_heap.h b/drivers/dma-buf/heaps/secure_heap.h
index 374fd276bdd7..9f80edcd3e1f 100644
--- a/drivers/dma-buf/heaps/secure_heap.h
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -20,6 +20,10 @@ struct secure_heap {
 
 	const struct secure_heap_ops *ops;
 
+	struct cma		*cma;
+	unsigned long		cma_paddr;
+	unsigned long		cma_size;
+
 	void			*priv_data;
 };
 
diff --git a/drivers/dma-buf/heaps/secure_heap_mtk.c b/drivers/dma-buf/heaps/secure_heap_mtk.c
index 2c6aaeaf469f..58148120f4ed 100644
--- a/drivers/dma-buf/heaps/secure_heap_mtk.c
+++ b/drivers/dma-buf/heaps/secure_heap_mtk.c
@@ -4,9 +4,11 @@
  *
  * Copyright (C) 2023 MediaTek Inc.
  */
+#include <linux/cma.h>
 #include <linux/dma-buf.h>
 #include <linux/err.h>
 #include <linux/module.h>
+#include <linux/of_reserved_mem.h>
 #include <linux/slab.h>
 #include <linux/tee_drv.h>
 #include <linux/uuid.h>
@@ -23,6 +25,13 @@ enum mtk_secure_mem_type {
 	 * management is inside the TEE.
 	 */
 	MTK_SECURE_MEMORY_TYPE_CM_TZ	= 1,
+	/*
+	 * MediaTek dynamic chunk memory carved out from CMA.
+	 * In normal case, the CMA could be used in kernel; When SVP start, we will
+	 * allocate whole this CMA and pass whole the CMA PA and size into TEE to
+	 * protect it, then the detail memory management also is inside the TEE.
+	 */
+	MTK_SECURE_MEMORY_TYPE_CM_CMA	= 2,
 };
 
 enum mtk_secure_buffer_tee_cmd {
@@ -32,6 +41,8 @@ enum mtk_secure_buffer_tee_cmd {
 	 * [in]  value[0].a: The buffer size.
 	 *       value[0].b: alignment.
 	 * [in]  value[1].a: enum mtk_secure_mem_type.
+	 * [in]  value[2].a: pa base in cma case.
+	 *       value[2].b: The buffer size in cma case.
 	 * [out] value[3].a: The secure handle.
 	 */
 	MTK_TZCMD_SECMEM_ZALLOC	= 0x10000, /* MTK TEE Command ID Base */
@@ -52,6 +63,9 @@ struct mtk_secure_heap_data {
 
 	const enum mtk_secure_mem_type mem_type;
 
+	struct page		*cma_page;
+	unsigned long		cma_used_size;
+	struct mutex		lock; /* lock for cma_used_size */
 };
 
 static int mtk_tee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
@@ -126,6 +140,10 @@ static int mtk_tee_secure_memory(struct secure_heap *sec_heap, struct secure_buf
 	params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
 	params[1].u.value.a = data->mem_type;
 	params[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+	if (sec_heap->cma && data->mem_type == MTK_SECURE_MEMORY_TYPE_CM_CMA) {
+		params[2].u.value.a = sec_heap->cma_paddr;
+		params[2].u.value.b = sec_heap->cma_size;
+	}
 	params[3].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
 	ret = mtk_tee_service_call(data->tee_ctx, data->tee_session,
 				   MTK_TZCMD_SECMEM_ZALLOC, params);
@@ -162,6 +180,48 @@ static void mtk_secure_memory_free(struct secure_heap *sec_heap, struct secure_b
 {
 }
 
+static int mtk_secure_memory_cma_allocate(struct secure_heap *sec_heap,
+					  struct secure_buffer *sec_buf)
+{
+	struct mtk_secure_heap_data *data = sec_heap->priv_data;
+	int ret = 0;
+	/*
+	 * Allocate CMA only when allocating buffer for the first time, and just
+	 * increase cma_used_size at the other time, Actually the memory
+	 * allocating is within the TEE.
+	 */
+	mutex_lock(&data->lock);
+	if (!data->cma_used_size) {
+		data->cma_page = cma_alloc(sec_heap->cma, sec_heap->cma_size >> PAGE_SHIFT,
+					   get_order(PAGE_SIZE), false);
+		if (!data->cma_page) {
+			ret = -ENOMEM;
+			goto out_unlock;
+		}
+	} else if (data->cma_used_size + sec_buf->size > sec_heap->cma_size) {
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+	data->cma_used_size += sec_buf->size;
+
+out_unlock:
+	mutex_unlock(&data->lock);
+	return ret;
+}
+
+static void mtk_secure_memory_cma_free(struct secure_heap *sec_heap,
+				       struct secure_buffer *sec_buf)
+{
+	struct mtk_secure_heap_data *data = sec_heap->priv_data;
+
+	mutex_lock(&data->lock);
+	data->cma_used_size -= sec_buf->size;
+	if (!data->cma_used_size)
+		cma_release(sec_heap->cma, data->cma_page,
+			    sec_heap->cma_size >> PAGE_SHIFT);
+	mutex_unlock(&data->lock);
+}
+
 static int mtk_secure_heap_init(struct secure_heap *sec_heap)
 {
 	struct mtk_secure_heap_data *data = sec_heap->priv_data;
@@ -183,21 +243,76 @@ static struct mtk_secure_heap_data mtk_sec_heap_data = {
 	.mem_type = MTK_SECURE_MEMORY_TYPE_CM_TZ,
 };
 
+static const struct secure_heap_ops mtk_sec_mem_ops_cma = {
+	.heap_init		= mtk_secure_heap_init,
+	.memory_alloc		= mtk_secure_memory_cma_allocate,
+	.memory_free		= mtk_secure_memory_cma_free,
+	.secure_the_memory	= mtk_tee_secure_memory,
+	.unsecure_the_memory	= mtk_tee_unsecure_memory,
+};
+
+static struct mtk_secure_heap_data mtk_sec_heap_data_cma = {
+	.mem_type = MTK_SECURE_MEMORY_TYPE_CM_CMA,
+};
+
 static struct secure_heap mtk_secure_heaps[] = {
 	{
 		.name		= "secure_mtk_cm",
 		.ops		= &mtk_sec_mem_ops,
 		.priv_data	= &mtk_sec_heap_data,
 	},
+	{
+		.name		= "secure_mtk_cma",
+		.ops		= &mtk_sec_mem_ops_cma,
+		.priv_data	= &mtk_sec_heap_data_cma,
+	},
 };
 
+static int __init mtk_secure_cma_init(struct reserved_mem *rmem)
+{
+	struct mtk_secure_heap_data *data;
+	struct secure_heap *sec_heap = mtk_secure_heaps, *sec_heap_cma = NULL;
+	struct cma *sec_cma;
+	int ret, i;
+
+	for (i = 0; i < ARRAY_SIZE(mtk_secure_heaps); i++, sec_heap++) {
+		data = sec_heap->priv_data;
+		if (data->mem_type == MTK_SECURE_MEMORY_TYPE_CM_CMA) {
+			sec_heap_cma = sec_heap;
+			break;
+		}
+	}
+	if (!sec_heap_cma)
+		return -EINVAL;
+
+	ret = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name,
+				    &sec_cma);
+	if (ret) {
+		pr_err("%s: %s set up CMA fail\n", __func__, rmem->name);
+		return ret;
+	}
+
+	sec_heap_cma->cma = sec_cma;
+	sec_heap_cma->cma_paddr = rmem->base;
+	sec_heap_cma->cma_size = rmem->size;
+	return 0;
+}
+
+RESERVEDMEM_OF_DECLARE(secure_cma, "mediatek,dynamic-secure-region", mtk_secure_cma_init);
+
 static int mtk_sec_heap_init(void)
 {
 	struct secure_heap *sec_heap = mtk_secure_heaps;
+	struct mtk_secure_heap_data *data;
 	unsigned int i;
 
-	for (i = 0; i < ARRAY_SIZE(mtk_secure_heaps); i++, sec_heap++)
-		secure_heap_add(sec_heap);
+	for (i = 0; i < ARRAY_SIZE(mtk_secure_heaps); i++, sec_heap++) {
+		data = sec_heap->priv_data;
+		if (data->mem_type == MTK_SECURE_MEMORY_TYPE_CM_CMA && !sec_heap->cma)
+			continue;
+		if (!secure_heap_add(sec_heap))
+			mutex_init(&data->lock);
+	}
 	return 0;
 }
 
-- 
2.25.1



From yong.wu at mediatek.com  Mon Dec 11 18:46:00 2023
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 12 Dec 2023 10:46:00 +0800
Subject: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
Message-ID: <20231212024607.3681-1-yong.wu@mediatek.com>

This patchset is for secure video playback and enables other potential
uses in the future. The 'secure dma-heap' will be used to allocate dma_buf
objects that reference memory in the secure world that is inaccessible/
unmappable by the non-secure (i.e.kernel/userspace) world.  That memory
will be used by the secure world to store secure information (i.e.
decrypted media content). The dma_bufs allocated from the kernel will be
passed to V4L2 for video decoding (as input and output). They will also be
used by the drm system for rendering of the content.

This patchset adds two secure heaps and they will be used v4l2[1] and drm[2].
1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path).
   The buffer is reserved for the secure world after bootup and it is used
   for vcodec's ES/working buffer;
2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is
   dynamically reserved for the secure world and will be got when we start
   playing secure videos, Once the security video playing is complete, the
   CMA will be released. This heap is used for the vcodec's frame buffer.

[1] https://lore.kernel.org/linux-mediatek/20231206081538.17056-1-yunfei.dong at mediatek.com/
[2] https://lore.kernel.org/linux-mediatek/20231023044549.21412-1-jason-jh.lin at mediatek.com/

Change note:
v3: Base on v6.7-rc1.
    1) Separate the secure heap into a common file(secure_heap.c) and a mtk special file
       (secure_heap_mtk.c), and put all tee related code into our special file.
    2) About dt-binding,
       a) Add "mediatek," prefix since this is Mediatek TEE firmware definition.
       b) Mute dt-binding check waring.
    3) Remove the normal CMA heap which is a draft for qcom.

v2: https://lore.kernel.org/linux-mediatek/20231111111559.8218-1-yong.wu at mediatek.com/
    1) Move John's patches into the vcodec patchset since they use the new
       dma heap interface directly.
       https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.dong at mediatek.com/
    2) Reword the dt-binding description.
    3) Rename the heap name from mtk_svp to secure_mtk_cm.
       This means the current vcodec/DRM upstream code doesn't match this.
    4) Add a normal CMA heap. currently it should be a draft version.
    5) Regarding the UUID, I still use hard code, but put it in a private
    data which allow the others could set their own UUID. What's more, UUID
    is necessary for the session with TEE. If we don't have it, we can't
    communicate with the TEE, including the get_uuid interface, which tries
    to make uuid more generic, not working. If there is other way to make
    UUID more general, please free to tell me.
    
v1: https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu at mediatek.com/
    Base on v6.6-rc1.

Yong Wu (7):
  dt-bindings: reserved-memory: Add mediatek,dynamic-secure-region
  dma-buf: heaps: Initialize a secure heap
  dma-buf: heaps: secure_heap: Add private heap ops
  dma-buf: heaps: secure_heap: Add dma_ops
  dma-buf: heaps: secure_heap: Add MediaTek secure heap and heap_init
  dma-buf: heaps: secure_heap_mtk: Add tee memory service call
  dma_buf: heaps: secure_heap_mtk: Add a new CMA heap

 .../mediatek,dynamic-secure-region.yaml       |  43 +++
 drivers/dma-buf/heaps/Kconfig                 |  13 +
 drivers/dma-buf/heaps/Makefile                |   2 +
 drivers/dma-buf/heaps/secure_heap.c           | 234 +++++++++++++
 drivers/dma-buf/heaps/secure_heap.h           |  43 +++
 drivers/dma-buf/heaps/secure_heap_mtk.c       | 321 ++++++++++++++++++
 6 files changed, 656 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml
 create mode 100644 drivers/dma-buf/heaps/secure_heap.c
 create mode 100644 drivers/dma-buf/heaps/secure_heap.h
 create mode 100644 drivers/dma-buf/heaps/secure_heap_mtk.c

-- 
2.18.0




From daniel at makrotopia.org  Mon Dec 11 19:18:37 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:18:37 +0000
Subject: [PATCH v5 2/5] dt-bindings: reset: mediatek: add MT7988 ethwarp
 reset IDs
In-Reply-To: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
Message-ID: <a60f5b5ed58626f3dbac1eab8a5845c3ce9bd17c.1702350213.git.daniel@makrotopia.org>

Add reset ID for ethwarp subsystem allowing to reset the built-in
Ethernet switch of the MediaTek MT7988 SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v5: add this patch to replace use of ti,syscon-reset in v1~v4

 include/dt-bindings/reset/mediatek,mt7988-resets.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 include/dt-bindings/reset/mediatek,mt7988-resets.h

diff --git a/include/dt-bindings/reset/mediatek,mt7988-resets.h b/include/dt-bindings/reset/mediatek,mt7988-resets.h
new file mode 100644
index 0000000000000..4933019713672
--- /dev/null
+++ b/include/dt-bindings/reset/mediatek,mt7988-resets.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ * Author: Daniel Golle <daniel at makrotopia.org>
+ */
+
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT7988
+#define _DT_BINDINGS_RESET_CONTROLLER_MT7988
+
+/* ETHWARP resets */
+#define MT7988_ETHWARP_RST_SWITCH		0
+
+#endif  /* _DT_BINDINGS_RESET_CONTROLLER_MT7988 */
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:18:15 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:18:15 +0000
Subject: [PATCH v5 1/5] dt-bindings: clock: mediatek: add MT7988 clock IDs
Message-ID: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add MT7988 clock dt-bindings for topckgen, apmixedsys, infracfg,
ethernet and xfipll subsystem clocks.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
v5: no changes
v4: no changes
v3: no changes
v2: fix indentation

 .../dt-bindings/clock/mediatek,mt7988-clk.h   | 280 ++++++++++++++++++
 1 file changed, 280 insertions(+)
 create mode 100644 include/dt-bindings/clock/mediatek,mt7988-clk.h

diff --git a/include/dt-bindings/clock/mediatek,mt7988-clk.h b/include/dt-bindings/clock/mediatek,mt7988-clk.h
new file mode 100644
index 0000000000000..63376e40f14d2
--- /dev/null
+++ b/include/dt-bindings/clock/mediatek,mt7988-clk.h
@@ -0,0 +1,280 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#ifndef _DT_BINDINGS_CLK_MT7988_H
+#define _DT_BINDINGS_CLK_MT7988_H
+
+/* APMIXEDSYS */
+
+#define CLK_APMIXED_NETSYSPLL			0
+#define CLK_APMIXED_MPLL			1
+#define CLK_APMIXED_MMPLL			2
+#define CLK_APMIXED_APLL2			3
+#define CLK_APMIXED_NET1PLL			4
+#define CLK_APMIXED_NET2PLL			5
+#define CLK_APMIXED_WEDMCUPLL			6
+#define CLK_APMIXED_SGMPLL			7
+#define CLK_APMIXED_ARM_B			8
+#define CLK_APMIXED_CCIPLL2_B			9
+#define CLK_APMIXED_USXGMIIPLL			10
+#define CLK_APMIXED_MSDCPLL			11
+
+/* TOPCKGEN */
+
+#define CLK_TOP_XTAL				0
+#define CLK_TOP_XTAL_D2				1
+#define CLK_TOP_RTC_32K				2
+#define CLK_TOP_RTC_32P7K			3
+#define CLK_TOP_MPLL_D2				4
+#define CLK_TOP_MPLL_D3_D2			5
+#define CLK_TOP_MPLL_D4				6
+#define CLK_TOP_MPLL_D8				7
+#define CLK_TOP_MPLL_D8_D2			8
+#define CLK_TOP_MMPLL_D2			9
+#define CLK_TOP_MMPLL_D3_D5			10
+#define CLK_TOP_MMPLL_D4			11
+#define CLK_TOP_MMPLL_D6_D2			12
+#define CLK_TOP_MMPLL_D8			13
+#define CLK_TOP_APLL2_D4			14
+#define CLK_TOP_NET1PLL_D4			15
+#define CLK_TOP_NET1PLL_D5			16
+#define CLK_TOP_NET1PLL_D5_D2			17
+#define CLK_TOP_NET1PLL_D5_D4			18
+#define CLK_TOP_NET1PLL_D8			19
+#define CLK_TOP_NET1PLL_D8_D2			20
+#define CLK_TOP_NET1PLL_D8_D4			21
+#define CLK_TOP_NET1PLL_D8_D8			22
+#define CLK_TOP_NET1PLL_D8_D16			23
+#define CLK_TOP_NET2PLL_D2			24
+#define CLK_TOP_NET2PLL_D4			25
+#define CLK_TOP_NET2PLL_D4_D4			26
+#define CLK_TOP_NET2PLL_D4_D8			27
+#define CLK_TOP_NET2PLL_D6			28
+#define CLK_TOP_NET2PLL_D8			29
+#define CLK_TOP_NETSYS_SEL			30
+#define CLK_TOP_NETSYS_500M_SEL			31
+#define CLK_TOP_NETSYS_2X_SEL			32
+#define CLK_TOP_NETSYS_GSW_SEL			33
+#define CLK_TOP_ETH_GMII_SEL			34
+#define CLK_TOP_NETSYS_MCU_SEL			35
+#define CLK_TOP_NETSYS_PAO_2X_SEL		36
+#define CLK_TOP_EIP197_SEL			37
+#define CLK_TOP_AXI_INFRA_SEL			38
+#define CLK_TOP_UART_SEL			39
+#define CLK_TOP_EMMC_250M_SEL			40
+#define CLK_TOP_EMMC_400M_SEL			41
+#define CLK_TOP_SPI_SEL				42
+#define CLK_TOP_SPIM_MST_SEL			43
+#define CLK_TOP_NFI1X_SEL			44
+#define CLK_TOP_SPINFI_SEL			45
+#define CLK_TOP_PWM_SEL				46
+#define CLK_TOP_I2C_SEL				47
+#define CLK_TOP_PCIE_MBIST_250M_SEL		48
+#define CLK_TOP_PEXTP_TL_SEL			49
+#define CLK_TOP_PEXTP_TL_P1_SEL			50
+#define CLK_TOP_PEXTP_TL_P2_SEL			51
+#define CLK_TOP_PEXTP_TL_P3_SEL			52
+#define CLK_TOP_USB_SYS_SEL			53
+#define CLK_TOP_USB_SYS_P1_SEL			54
+#define CLK_TOP_USB_XHCI_SEL			55
+#define CLK_TOP_USB_XHCI_P1_SEL			56
+#define CLK_TOP_USB_FRMCNT_SEL			57
+#define CLK_TOP_USB_FRMCNT_P1_SEL		58
+#define CLK_TOP_AUD_SEL				59
+#define CLK_TOP_A1SYS_SEL			60
+#define CLK_TOP_AUD_L_SEL			61
+#define CLK_TOP_A_TUNER_SEL			62
+#define CLK_TOP_SSPXTP_SEL			63
+#define CLK_TOP_USB_PHY_SEL			64
+#define CLK_TOP_USXGMII_SBUS_0_SEL		65
+#define CLK_TOP_USXGMII_SBUS_1_SEL		66
+#define CLK_TOP_SGM_0_SEL			67
+#define CLK_TOP_SGM_SBUS_0_SEL			68
+#define CLK_TOP_SGM_1_SEL			69
+#define CLK_TOP_SGM_SBUS_1_SEL			70
+#define CLK_TOP_XFI_PHY_0_XTAL_SEL		71
+#define CLK_TOP_XFI_PHY_1_XTAL_SEL		72
+#define CLK_TOP_SYSAXI_SEL			73
+#define CLK_TOP_SYSAPB_SEL			74
+#define CLK_TOP_ETH_REFCK_50M_SEL		75
+#define CLK_TOP_ETH_SYS_200M_SEL		76
+#define CLK_TOP_ETH_SYS_SEL			77
+#define CLK_TOP_ETH_XGMII_SEL			78
+#define CLK_TOP_BUS_TOPS_SEL			79
+#define CLK_TOP_NPU_TOPS_SEL			80
+#define CLK_TOP_DRAMC_SEL			81
+#define CLK_TOP_DRAMC_MD32_SEL			82
+#define CLK_TOP_INFRA_F26M_SEL			83
+#define CLK_TOP_PEXTP_P0_SEL			84
+#define CLK_TOP_PEXTP_P1_SEL			85
+#define CLK_TOP_PEXTP_P2_SEL			86
+#define CLK_TOP_PEXTP_P3_SEL			87
+#define CLK_TOP_DA_XTP_GLB_P0_SEL		88
+#define CLK_TOP_DA_XTP_GLB_P1_SEL		89
+#define CLK_TOP_DA_XTP_GLB_P2_SEL		90
+#define CLK_TOP_DA_XTP_GLB_P3_SEL		91
+#define CLK_TOP_CKM_SEL				92
+#define CLK_TOP_DA_SEL				93
+#define CLK_TOP_PEXTP_SEL			94
+#define CLK_TOP_TOPS_P2_26M_SEL			95
+#define CLK_TOP_MCUSYS_BACKUP_625M_SEL		96
+#define CLK_TOP_NETSYS_SYNC_250M_SEL		97
+#define CLK_TOP_MACSEC_SEL			98
+#define CLK_TOP_NETSYS_TOPS_400M_SEL		99
+#define CLK_TOP_NETSYS_PPEFB_250M_SEL		100
+#define CLK_TOP_NETSYS_WARP_SEL			101
+#define CLK_TOP_ETH_MII_SEL			102
+#define CLK_TOP_NPU_SEL				103
+#define CLK_TOP_AUD_I2S_M			104
+
+/* MCUSYS */
+
+#define CLK_MCU_BUS_DIV_SEL			0
+#define CLK_MCU_ARM_DIV_SEL			1
+
+/* INFRACFG_AO */
+
+#define CLK_INFRA_MUX_UART0_SEL			0
+#define CLK_INFRA_MUX_UART1_SEL			1
+#define CLK_INFRA_MUX_UART2_SEL			2
+#define CLK_INFRA_MUX_SPI0_SEL			3
+#define CLK_INFRA_MUX_SPI1_SEL			4
+#define CLK_INFRA_MUX_SPI2_SEL			5
+#define CLK_INFRA_PWM_SEL			6
+#define CLK_INFRA_PWM_CK1_SEL			7
+#define CLK_INFRA_PWM_CK2_SEL			8
+#define CLK_INFRA_PWM_CK3_SEL			9
+#define CLK_INFRA_PWM_CK4_SEL			10
+#define CLK_INFRA_PWM_CK5_SEL			11
+#define CLK_INFRA_PWM_CK6_SEL			12
+#define CLK_INFRA_PWM_CK7_SEL			13
+#define CLK_INFRA_PWM_CK8_SEL			14
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL	15
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL	16
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL	17
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL	18
+
+/* INFRACFG */
+
+#define CLK_INFRA_PCIE_PERI_26M_CK_P0		19
+#define CLK_INFRA_PCIE_PERI_26M_CK_P1		20
+#define CLK_INFRA_PCIE_PERI_26M_CK_P2		21
+#define CLK_INFRA_PCIE_PERI_26M_CK_P3		22
+#define CLK_INFRA_66M_GPT_BCK			23
+#define CLK_INFRA_66M_PWM_HCK			24
+#define CLK_INFRA_66M_PWM_BCK			25
+#define CLK_INFRA_66M_PWM_CK1			26
+#define CLK_INFRA_66M_PWM_CK2			27
+#define CLK_INFRA_66M_PWM_CK3			28
+#define CLK_INFRA_66M_PWM_CK4			29
+#define CLK_INFRA_66M_PWM_CK5			30
+#define CLK_INFRA_66M_PWM_CK6			31
+#define CLK_INFRA_66M_PWM_CK7			32
+#define CLK_INFRA_66M_PWM_CK8			33
+#define CLK_INFRA_133M_CQDMA_BCK		34
+#define CLK_INFRA_66M_AUD_SLV_BCK		35
+#define CLK_INFRA_AUD_26M			36
+#define CLK_INFRA_AUD_L				37
+#define CLK_INFRA_AUD_AUD			38
+#define CLK_INFRA_AUD_EG2			39
+#define CLK_INFRA_DRAMC_F26M			40
+#define CLK_INFRA_133M_DBG_ACKM			41
+#define CLK_INFRA_66M_AP_DMA_BCK		42
+#define CLK_INFRA_66M_SEJ_BCK			43
+#define CLK_INFRA_PRE_CK_SEJ_F13M		44
+#define CLK_INFRA_26M_THERM_SYSTEM		45
+#define CLK_INFRA_I2C_BCK			46
+#define CLK_INFRA_52M_UART0_CK			47
+#define CLK_INFRA_52M_UART1_CK			48
+#define CLK_INFRA_52M_UART2_CK			49
+#define CLK_INFRA_NFI				50
+#define CLK_INFRA_SPINFI			51
+#define CLK_INFRA_66M_NFI_HCK			52
+#define CLK_INFRA_104M_SPI0			53
+#define CLK_INFRA_104M_SPI1			54
+#define CLK_INFRA_104M_SPI2_BCK			55
+#define CLK_INFRA_66M_SPI0_HCK			56
+#define CLK_INFRA_66M_SPI1_HCK			57
+#define CLK_INFRA_66M_SPI2_HCK			58
+#define CLK_INFRA_66M_FLASHIF_AXI		59
+#define CLK_INFRA_RTC				60
+#define CLK_INFRA_26M_ADC_BCK			61
+#define CLK_INFRA_RC_ADC			62
+#define CLK_INFRA_MSDC400			63
+#define CLK_INFRA_MSDC2_HCK			64
+#define CLK_INFRA_133M_MSDC_0_HCK		65
+#define CLK_INFRA_66M_MSDC_0_HCK		66
+#define CLK_INFRA_133M_CPUM_BCK			67
+#define CLK_INFRA_BIST2FPC			68
+#define CLK_INFRA_I2C_X16W_MCK_CK_P1		69
+#define CLK_INFRA_I2C_X16W_PCK_CK_P1		70
+#define CLK_INFRA_133M_USB_HCK			71
+#define CLK_INFRA_133M_USB_HCK_CK_P1		72
+#define CLK_INFRA_66M_USB_HCK			73
+#define CLK_INFRA_66M_USB_HCK_CK_P1		74
+#define CLK_INFRA_USB_SYS			75
+#define CLK_INFRA_USB_SYS_CK_P1			76
+#define CLK_INFRA_USB_REF			77
+#define CLK_INFRA_USB_CK_P1			78
+#define CLK_INFRA_USB_FRMCNT			79
+#define CLK_INFRA_USB_FRMCNT_CK_P1		80
+#define CLK_INFRA_USB_PIPE			81
+#define CLK_INFRA_USB_PIPE_CK_P1		82
+#define CLK_INFRA_USB_UTMI			83
+#define CLK_INFRA_USB_UTMI_CK_P1		84
+#define CLK_INFRA_USB_XHCI			85
+#define CLK_INFRA_USB_XHCI_CK_P1		86
+#define CLK_INFRA_PCIE_GFMUX_TL_P0		87
+#define CLK_INFRA_PCIE_GFMUX_TL_P1		88
+#define CLK_INFRA_PCIE_GFMUX_TL_P2		89
+#define CLK_INFRA_PCIE_GFMUX_TL_P3		90
+#define CLK_INFRA_PCIE_PIPE_P0			91
+#define CLK_INFRA_PCIE_PIPE_P1			92
+#define CLK_INFRA_PCIE_PIPE_P2			93
+#define CLK_INFRA_PCIE_PIPE_P3			94
+#define CLK_INFRA_133M_PCIE_CK_P0		95
+#define CLK_INFRA_133M_PCIE_CK_P1		96
+#define CLK_INFRA_133M_PCIE_CK_P2		97
+#define CLK_INFRA_133M_PCIE_CK_P3		98
+
+/* ETHDMA */
+
+#define CLK_ETHDMA_XGP1_EN			0
+#define CLK_ETHDMA_XGP2_EN			1
+#define CLK_ETHDMA_XGP3_EN			2
+#define CLK_ETHDMA_FE_EN			3
+#define CLK_ETHDMA_GP2_EN			4
+#define CLK_ETHDMA_GP1_EN			5
+#define CLK_ETHDMA_GP3_EN			6
+#define CLK_ETHDMA_ESW_EN			7
+#define CLK_ETHDMA_CRYPT0_EN			8
+#define CLK_ETHDMA_NR_CLK			9
+
+/* SGMIISYS_0 */
+
+#define CLK_SGM0_TX_EN				0
+#define CLK_SGM0_RX_EN				1
+#define CLK_SGMII0_NR_CLK			2
+
+/* SGMIISYS_1 */
+
+#define CLK_SGM1_TX_EN				0
+#define CLK_SGM1_RX_EN				1
+#define CLK_SGMII1_NR_CLK			2
+
+/* ETHWARP */
+
+#define CLK_ETHWARP_WOCPU2_EN			0
+#define CLK_ETHWARP_WOCPU1_EN			1
+#define CLK_ETHWARP_WOCPU0_EN			2
+#define CLK_ETHWARP_NR_CLK			3
+
+/* XFIPLL */
+#define CLK_XFIPLL_PLL				0
+#define CLK_XFIPLL_PLL_EN			1
+
+#endif /* _DT_BINDINGS_CLK_MT7988_H */
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:18:47 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:18:47 +0000
Subject: [PATCH v5 3/5] dt-bindings: clock: mediatek: add clock controllers
 of MT7988
In-Reply-To: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
Message-ID: <ce9b1e777090724794cf9f0c52bcd8618385fd06.1702350213.git.daniel@makrotopia.org>

Add various clock controllers found in the MT7988 SoC to existing
bindings (if applicable) and add files for the new ethwarp, mcusys
and xfi-pll clock controllers not previously present in any SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v5:
 * drop use of ti,syscon-reset and hence also syscon and simple-mfd
   compatibles from mt7988-ethwarp clock controller which now got the
   clock controller provide the reset(s).

v4:
 * add subnodes for controllers acting as MFD

v3:
 * move clock bindings to clock folder
 * drop ti,syscon-reset from bindings and example
 * merge mcusys with topckgen bindings

v2:
 * dropped unused labels
 * add 'type: object' declaration for reset-controller found in new
   ethwarp controller and represented as ti,syscon-reset
 * rebase on top of
   "dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema"

 .../arm/mediatek/mediatek,infracfg.yaml       |  1 +
 .../bindings/clock/mediatek,apmixedsys.yaml   |  1 +
 .../bindings/clock/mediatek,ethsys.yaml       |  1 +
 .../clock/mediatek,mt7988-ethwarp.yaml        | 52 ++++++++++++++++
 .../clock/mediatek,mt7988-xfi-pll.yaml        | 48 +++++++++++++++
 .../bindings/clock/mediatek,topckgen.yaml     |  2 +
 .../bindings/net/pcs/mediatek,sgmiisys.yaml   | 61 ++++++++++++++++---
 7 files changed, 157 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
index ea98043c6ba3d..230b5188a88db 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
@@ -30,6 +30,7 @@ properties:
               - mediatek,mt7629-infracfg
               - mediatek,mt7981-infracfg
               - mediatek,mt7986-infracfg
+              - mediatek,mt7988-infracfg
               - mediatek,mt8135-infracfg
               - mediatek,mt8167-infracfg
               - mediatek,mt8173-infracfg
diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
index 372c1d744bc27..685535846cbb7 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
@@ -22,6 +22,7 @@ properties:
           - mediatek,mt7622-apmixedsys
           - mediatek,mt7981-apmixedsys
           - mediatek,mt7986-apmixedsys
+          - mediatek,mt7988-apmixedsys
           - mediatek,mt8135-apmixedsys
           - mediatek,mt8173-apmixedsys
           - mediatek,mt8516-apmixedsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
index 94d42c8647777..f9cddacc2eae1 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
@@ -22,6 +22,7 @@ properties:
               - mediatek,mt7629-ethsys
               - mediatek,mt7981-ethsys
               - mediatek,mt7986-ethsys
+              - mediatek,mt7988-ethsys
           - const: syscon
       - items:
           - const: mediatek,mt7623-ethsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
new file mode 100644
index 0000000000000..b7f3b42438662
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-ethwarp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 ethwarp Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The Mediatek MT7988 ethwarp controller provides clocks and resets for the
+  Ethernet related subsystems found the MT7988 SoC.
+  The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
+
+properties:
+  compatible:
+    items:
+      - const: mediatek,mt7988-ethwarp
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+  '#reset-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - '#clock-cells'
+  - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/reset/ti-syscon.h>
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        clock-controller at 15031000 {
+            compatible = "mediatek,mt7988-ethwarp";
+            reg = <0 0x15031000 0 0x1000>;
+            #clock-cells = <1>;
+            #reset-cells = <1>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
new file mode 100644
index 0000000000000..fe5e3a70299fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-xfi-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 XFI PLL Clock Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The MediaTek XFI PLL controller provides the 156.25MHz clock for the
+  Ethernet SerDes PHY from the 40MHz top_xtal clock.
+
+properties:
+  compatible:
+    const: mediatek,mt7988-xfi-pll
+
+  reg:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - resets
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+        clock-controller at 11f40000 {
+            compatible = "mediatek,mt7988-xfi-pll";
+            reg = <0 0x11f40000 0 0x1000>;
+            resets = <&watchdog 16>;
+            #clock-cells = <1>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
index 6d087ded7437a..bdf3b55bd56fd 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
@@ -37,6 +37,8 @@ properties:
               - mediatek,mt7629-topckgen
               - mediatek,mt7981-topckgen
               - mediatek,mt7986-topckgen
+              - mediatek,mt7988-mcusys
+              - mediatek,mt7988-topckgen
               - mediatek,mt8167-topckgen
               - mediatek,mt8183-topckgen
           - const: syscon
diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
index 66a95191bd776..f5f1fd97c50eb 100644
--- a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
+++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
@@ -15,15 +15,22 @@ description:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - mediatek,mt7622-sgmiisys
-          - mediatek,mt7629-sgmiisys
-          - mediatek,mt7981-sgmiisys_0
-          - mediatek,mt7981-sgmiisys_1
-          - mediatek,mt7986-sgmiisys_0
-          - mediatek,mt7986-sgmiisys_1
-      - const: syscon
+    oneOf:
+      - items:
+          - enum:
+              - mediatek,mt7622-sgmiisys
+              - mediatek,mt7629-sgmiisys
+              - mediatek,mt7981-sgmiisys_0
+              - mediatek,mt7981-sgmiisys_1
+              - mediatek,mt7986-sgmiisys_0
+              - mediatek,mt7986-sgmiisys_1
+          - const: syscon
+      - items:
+          - enum:
+              - mediatek,mt7988-sgmiisys_0
+              - mediatek,mt7988-sgmiisys_1
+          - const: simple-mfd
+          - const: syscon
 
   reg:
     maxItems: 1
@@ -35,11 +42,47 @@ properties:
     description: Invert polarity of the SGMII data lanes
     type: boolean
 
+  pcs:
+    type: object
+    description: HSGMII PCS logic
+    properties:
+      compatible:
+        const: mediatek,mt7988-sgmii
+
+      clocks:
+        maxItems: 3
+        minItems: 3
+
+      clock-names:
+        items:
+          - const: sgmii_sel
+          - const: sgmii_tx
+          - const: sgmii_rx
+
+    required:
+      - compatible
+      - clocks
+      - clock-names
+
+    additionalProperties: false
+
 required:
   - compatible
   - reg
   - '#clock-cells'
 
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - mediatek,mt7988-sgmiisys_0
+          - mediatek,mt7988-sgmiisys_1
+
+then:
+  required:
+    - pcs
+
 additionalProperties: false
 
 examples:
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:19:34 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:19:34 +0000
Subject: [PATCH v5 4/5] clk: mediatek: add pcw_chg_bit control for PLLs of
 MT7988
In-Reply-To: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
Message-ID: <a43ad2a0131ea35988dd490ab235d16d4119bc3a.1702350213.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Introduce pcw_chg_bit member to struct mtk_pll_data and use it instead
of the previously hardcoded PCW_CHG_MASK macro if set.
This will needed for clocks on the MT7988 SoC.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v5: rename to .pcw_chg_bit, use ? operator instead of changing every
    single existing driver. The approach in v4 doesn't work as
    if .pcw_chg_reg is unset/0, pll->pcw_chg_addr will default to
    pll->base_addr + REG_CON1. Hence setting .pcw_chg_bit would be
    required for *all* drivers instead of just those setting
    .pcs_chf_reg. And that seems like an excessive change which can
    easily be avoided by using the ? operator to set the default
    at runtime (and we can easily cope with that overhead).
v4: always set .pcw_chg_shift if .pcw_chg_reg is used instead of
    having an if-expression in mtk_pll_set_rate_regs().
v3: use git --from ...
v2: no changes

 drivers/clk/mediatek/clk-pll.c | 5 +++--
 drivers/clk/mediatek/clk-pll.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index 513ab6b1b3229..ce453e1718e53 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -23,7 +23,7 @@
 #define CON0_BASE_EN		BIT(0)
 #define CON0_PWR_ON		BIT(0)
 #define CON0_ISO_EN		BIT(1)
-#define PCW_CHG_MASK		BIT(31)
+#define PCW_CHG_BIT		31
 
 #define AUDPLL_TUNER_EN		BIT(31)
 
@@ -114,7 +114,8 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll, u32 pcw,
 			pll->data->pcw_shift);
 	val |= pcw << pll->data->pcw_shift;
 	writel(val, pll->pcw_addr);
-	chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
+	chg = readl(pll->pcw_chg_addr) |
+	      BIT(pll->data->pcw_chg_bit ? : PCW_CHG_BIT);
 	writel(chg, pll->pcw_chg_addr);
 	if (pll->tuner_addr)
 		writel(val + 1, pll->tuner_addr);
diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
index f17278ff15d78..285c8db958b39 100644
--- a/drivers/clk/mediatek/clk-pll.h
+++ b/drivers/clk/mediatek/clk-pll.h
@@ -48,6 +48,7 @@ struct mtk_pll_data {
 	const char *parent_name;
 	u32 en_reg;
 	u8 pll_en_bit; /* Assume 0, indicates BIT(0) by default */
+	u8 pcw_chg_bit;
 };
 
 /*
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:19:45 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:19:45 +0000
Subject: [PATCH v5 5/5] clk: mediatek: add drivers for MT7988 SoC
In-Reply-To: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
Message-ID: <14b00d8c9d1fcfdf8cd6b9b02e5a19566d970e6b.1702350213.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add APMIXED, ETH, INFRACFG and TOPCKGEN clock drivers which are
typical MediaTek designs.

Also add driver for XFIPLL clock generating the 156.25MHz clock for
the XFI SerDes. It needs an undocumented software workaround and has
an unknown internal design.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
v5:
 * more nicely format macro defintions
 * register reset controller for ethwarp clock controller
 * drop redundant GATE_SGMII1 which is indentical to GATE_SGMII0
   in favor of single GATE_SGMII macro

v4:
 * make use of existing GATE_MTK_FLAGS macro
 * reformat to max. 100 columns
 * cosmetics

v3: use git --from ...
v2: no changes

 drivers/clk/mediatek/Kconfig               |   9 +
 drivers/clk/mediatek/Makefile              |   5 +
 drivers/clk/mediatek/clk-mt7988-apmixed.c  | 114 ++++++++
 drivers/clk/mediatek/clk-mt7988-eth.c      | 150 ++++++++++
 drivers/clk/mediatek/clk-mt7988-infracfg.c | 274 +++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-topckgen.c | 325 +++++++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-xfipll.c   |  82 ++++++
 7 files changed, 959 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt7988-apmixed.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-eth.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-infracfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-topckgen.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-xfipll.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 48b42d11111cd..70a005e7e1b18 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -423,6 +423,15 @@ config COMMON_CLK_MT7986_ETHSYS
 	  This driver adds support for clocks for Ethernet and SGMII
 	  required on MediaTek MT7986 SoC.
 
+config COMMON_CLK_MT7988
+	tristate "Clock driver for MediaTek MT7988"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	select COMMON_CLK_MEDIATEK
+	default ARCH_MEDIATEK
+	help
+	  This driver supports MediaTek MT7988 basic clocks and clocks
+	  required for various periperals found on this SoC.
+
 config COMMON_CLK_MT8135
 	tristate "Clock driver for MediaTek MT8135"
 	depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index dbeaa5b41177d..eeccfa039896f 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -62,6 +62,11 @@ obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-apmixed.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-topckgen.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-infracfg.o
 obj-$(CONFIG_COMMON_CLK_MT7986_ETHSYS) += clk-mt7986-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-apmixed.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-topckgen.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-infracfg.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-xfipll.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135-apmixedsys.o clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8167) += clk-mt8167-apmixedsys.o clk-mt8167.o
 obj-$(CONFIG_COMMON_CLK_MT8167_AUDSYS) += clk-mt8167-aud.o
diff --git a/drivers/clk/mediatek/clk-mt7988-apmixed.c b/drivers/clk/mediatek/clk-mt7988-apmixed.c
new file mode 100644
index 0000000000000..baf9564351a33
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-apmixed.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include "clk-pll.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+#define MT7988_PLL_FMAX (2500UL * MHZ)
+#define MT7988_PCW_CHG_BIT 2
+
+#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _rst_bar_mask, _pcwbits, _pd_reg,	\
+	    _pd_shift, _tuner_reg, _tuner_en_reg, _tuner_en_bit, _pcw_reg, _pcw_shift,		\
+	    _pcw_chg_reg)									\
+	{											\
+		.id = _id,									\
+		.name = _name,									\
+		.reg = _reg,									\
+		.pwr_reg = _pwr_reg,								\
+		.en_mask = _en_mask,								\
+		.flags = _flags,								\
+		.rst_bar_mask = BIT(_rst_bar_mask),						\
+		.fmax = MT7988_PLL_FMAX,							\
+		.pcwbits = _pcwbits,								\
+		.pd_reg = _pd_reg,								\
+		.pd_shift = _pd_shift,								\
+		.tuner_reg = _tuner_reg,							\
+		.tuner_en_reg = _tuner_en_reg,							\
+		.tuner_en_bit = _tuner_en_bit,							\
+		.pcw_reg = _pcw_reg,								\
+		.pcw_shift = _pcw_shift,							\
+		.pcw_chg_reg = _pcw_chg_reg,							\
+		.pcw_chg_bit = MT7988_PCW_CHG_BIT,						\
+		.parent_name = "clkxtal",							\
+	}
+
+static const struct mtk_pll_data plls[] = {
+	PLL(CLK_APMIXED_NETSYSPLL, "netsyspll", 0x0104, 0x0110, 0x00000001, 0, 0, 32, 0x0104, 4, 0,
+	    0, 0, 0x0108, 0, 0x0104),
+	PLL(CLK_APMIXED_MPLL, "mpll", 0x0114, 0x0120, 0xff000001, HAVE_RST_BAR, 23, 32, 0x0114, 4,
+	    0, 0, 0, 0x0118, 0, 0x0114),
+	PLL(CLK_APMIXED_MMPLL, "mmpll", 0x0124, 0x0130, 0xff000001, HAVE_RST_BAR, 23, 32, 0x0124, 4,
+	    0, 0, 0, 0x0128, 0, 0x0124),
+	PLL(CLK_APMIXED_APLL2, "apll2", 0x0134, 0x0140, 0x00000001, 0, 0, 32, 0x0134, 4, 0x0704,
+	    0x0700, 1, 0x0138, 0, 0x0134),
+	PLL(CLK_APMIXED_NET1PLL, "net1pll", 0x0144, 0x0150, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0144, 4, 0, 0, 0, 0x0148, 0, 0x0144),
+	PLL(CLK_APMIXED_NET2PLL, "net2pll", 0x0154, 0x0160, 0xff000001, (HAVE_RST_BAR | PLL_AO), 23,
+	    32, 0x0154, 4, 0, 0, 0, 0x0158, 0, 0x0154),
+	PLL(CLK_APMIXED_WEDMCUPLL, "wedmcupll", 0x0164, 0x0170, 0x00000001, 0, 0, 32, 0x0164, 4, 0,
+	    0, 0, 0x0168, 0, 0x0164),
+	PLL(CLK_APMIXED_SGMPLL, "sgmpll", 0x0174, 0x0180, 0x00000001, 0, 0, 32, 0x0174, 4, 0, 0, 0,
+	    0x0178, 0, 0x0174),
+	PLL(CLK_APMIXED_ARM_B, "arm_b", 0x0204, 0x0210, 0xff000001, (HAVE_RST_BAR | PLL_AO), 23, 32,
+	    0x0204, 4, 0, 0, 0, 0x0208, 0, 0x0204),
+	PLL(CLK_APMIXED_CCIPLL2_B, "ccipll2_b", 0x0214, 0x0220, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0214, 4, 0, 0, 0, 0x0218, 0, 0x0214),
+	PLL(CLK_APMIXED_USXGMIIPLL, "usxgmiipll", 0x0304, 0x0310, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0304, 4, 0, 0, 0, 0x0308, 0, 0x0304),
+	PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x0314, 0x0320, 0x00000001, 0, 0, 32, 0x0314, 4, 0, 0,
+	    0, 0x0318, 0, 0x0314),
+};
+
+static const struct of_device_id of_match_clk_mt7988_apmixed[] = {
+	{ .compatible = "mediatek,mt7988-apmixedsys" },
+	{ /* sentinel */ }
+};
+
+static int clk_mt7988_apmixed_probe(struct platform_device *pdev)
+{
+	struct clk_hw_onecell_data *clk_data;
+	struct device_node *node = pdev->dev.of_node;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(ARRAY_SIZE(plls));
+	if (!clk_data)
+		return -ENOMEM;
+
+	r = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	if (r)
+		goto free_apmixed_data;
+
+	r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
+	if (r)
+		goto unregister_plls;
+
+	return r;
+
+unregister_plls:
+	mtk_clk_unregister_plls(plls, ARRAY_SIZE(plls), clk_data);
+free_apmixed_data:
+	mtk_free_clk_data(clk_data);
+	return r;
+}
+
+static struct platform_driver clk_mt7988_apmixed_drv = {
+	.probe = clk_mt7988_apmixed_probe,
+	.driver = {
+		.name = "clk-mt7988-apmixed",
+		.of_match_table = of_match_clk_mt7988_apmixed,
+	},
+};
+builtin_platform_driver(clk_mt7988_apmixed_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-eth.c b/drivers/clk/mediatek/clk-mt7988-eth.c
new file mode 100644
index 0000000000000..c4dab54c60aa1
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-eth.c
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "reset.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+#include <dt-bindings/reset/mediatek,mt7988-resets.h>
+
+static const struct mtk_gate_regs ethdma_cg_regs = {
+	.set_ofs = 0x30,
+	.clr_ofs = 0x30,
+	.sta_ofs = 0x30,
+};
+
+#define GATE_ETHDMA(_id, _name, _parent, _shift)		\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &ethdma_cg_regs,			\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_gate ethdma_clks[] = {
+	GATE_ETHDMA(CLK_ETHDMA_XGP1_EN, "ethdma_xgp1_en", "top_xtal", 0),
+	GATE_ETHDMA(CLK_ETHDMA_XGP2_EN, "ethdma_xgp2_en", "top_xtal", 1),
+	GATE_ETHDMA(CLK_ETHDMA_XGP3_EN, "ethdma_xgp3_en", "top_xtal", 2),
+	GATE_ETHDMA(CLK_ETHDMA_FE_EN, "ethdma_fe_en", "netsys_2x_sel", 6),
+	GATE_ETHDMA(CLK_ETHDMA_GP2_EN, "ethdma_gp2_en", "top_xtal", 7),
+	GATE_ETHDMA(CLK_ETHDMA_GP1_EN, "ethdma_gp1_en", "top_xtal", 8),
+	GATE_ETHDMA(CLK_ETHDMA_GP3_EN, "ethdma_gp3_en", "top_xtal", 10),
+	GATE_ETHDMA(CLK_ETHDMA_ESW_EN, "ethdma_esw_en", "netsys_gsw_sel", 16),
+	GATE_ETHDMA(CLK_ETHDMA_CRYPT0_EN, "ethdma_crypt0_en", "eip197_sel", 29),
+};
+
+static const struct mtk_clk_desc ethdma_desc = {
+	.clks = ethdma_clks,
+	.num_clks = ARRAY_SIZE(ethdma_clks),
+};
+
+static const struct mtk_gate_regs sgmii_cg_regs = {
+	.set_ofs = 0xe4,
+	.clr_ofs = 0xe4,
+	.sta_ofs = 0xe4,
+};
+
+#define GATE_SGMII(_id, _name, _parent, _shift)			\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &sgmii_cg_regs,				\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_gate sgmii0_clks[] = {
+	GATE_SGMII(CLK_SGM0_TX_EN, "sgm0_tx_en", "top_xtal", 2),
+	GATE_SGMII(CLK_SGM0_RX_EN, "sgm0_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii0_desc = {
+	.clks = sgmii0_clks,
+	.num_clks = ARRAY_SIZE(sgmii0_clks),
+};
+
+static const struct mtk_gate sgmii1_clks[] = {
+	GATE_SGMII(CLK_SGM1_TX_EN, "sgm1_tx_en", "top_xtal", 2),
+	GATE_SGMII(CLK_SGM1_RX_EN, "sgm1_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii1_desc = {
+	.clks = sgmii1_clks,
+	.num_clks = ARRAY_SIZE(sgmii1_clks),
+};
+
+static const struct mtk_gate_regs ethwarp_cg_regs = {
+	.set_ofs = 0x14,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x14,
+};
+
+#define GATE_ETHWARP(_id, _name, _parent, _shift)		\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &ethwarp_cg_regs,			\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_gate ethwarp_clks[] = {
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU2_EN, "ethwarp_wocpu2_en", "netsys_mcu_sel", 13),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU1_EN, "ethwarp_wocpu1_en", "netsys_mcu_sel", 14),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU0_EN, "ethwarp_wocpu0_en", "netsys_mcu_sel", 15),
+};
+
+static u16 ethwarp_rst_ofs[] = { 0x8 };
+
+static u16 ethwarp_idx_map[] = {
+	[MT7988_ETHWARP_RST_SWITCH] = 9,
+};
+
+static const struct mtk_clk_rst_desc ethwarp_rst_desc = {
+	.version = MTK_RST_SIMPLE,
+	.rst_bank_ofs = ethwarp_rst_ofs,
+	.rst_bank_nr = ARRAY_SIZE(ethwarp_rst_ofs),
+	.rst_idx_map = ethwarp_idx_map,
+	.rst_idx_map_nr = ARRAY_SIZE(ethwarp_idx_map),
+};
+
+static const struct mtk_clk_desc ethwarp_desc = {
+	.clks = ethwarp_clks,
+	.num_clks = ARRAY_SIZE(ethwarp_clks),
+	.rst_desc = &ethwarp_rst_desc,
+};
+
+static const struct of_device_id of_match_clk_mt7988_eth[] = {
+	{ .compatible = "mediatek,mt7988-ethsys", .data = &ethdma_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys_0", .data = &sgmii0_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys_1", .data = &sgmii1_desc },
+	{ .compatible = "mediatek,mt7988-ethwarp", .data = &ethwarp_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_eth);
+
+static struct platform_driver clk_mt7988_eth_drv = {
+	.driver = {
+		.name = "clk-mt7988-eth",
+		.of_match_table = of_match_clk_mt7988_eth,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_eth_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 Ethernet clocks driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-infracfg.c b/drivers/clk/mediatek/clk-mt7988-infracfg.c
new file mode 100644
index 0000000000000..b7b4f7626d3d6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-infracfg.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const char *const infra_mux_uart0_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_uart1_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_uart2_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_spi0_parents[] __initconst = { "i2c_sel", "spi_sel" };
+
+static const char *const infra_mux_spi1_parents[] __initconst = { "i2c_sel", "spim_mst_sel" };
+
+static const char *const infra_pwm_bck_parents[] __initconst = { "top_rtc_32p7k",
+								 "csw_infra_f26m_sel", "sysaxi_sel",
+								 "pwm_sel" };
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p0_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p1_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p1_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p2_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p2_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p3_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p3_sel"
+};
+
+static const struct mtk_mux infra_muxes[] = {
+	/* MODULE_CLK_SEL_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART0_SEL, "infra_mux_uart0_sel",
+			     infra_mux_uart0_parents, 0x0018, 0x0010, 0x0014, 0, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART1_SEL, "infra_mux_uart1_sel",
+			     infra_mux_uart1_parents, 0x0018, 0x0010, 0x0014, 1, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART2_SEL, "infra_mux_uart2_sel",
+			     infra_mux_uart2_parents, 0x0018, 0x0010, 0x0014, 2, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI0_SEL, "infra_mux_spi0_sel", infra_mux_spi0_parents,
+			     0x0018, 0x0010, 0x0014, 4, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI1_SEL, "infra_mux_spi1_sel", infra_mux_spi1_parents,
+			     0x0018, 0x0010, 0x0014, 5, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI2_SEL, "infra_mux_spi2_sel", infra_mux_spi0_parents,
+			     0x0018, 0x0010, 0x0014, 6, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_SEL, "infra_pwm_sel", infra_pwm_bck_parents, 0x0018,
+			     0x0010, 0x0014, 14, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK1_SEL, "infra_pwm_ck1_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 16, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK2_SEL, "infra_pwm_ck2_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 18, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK3_SEL, "infra_pwm_ck3_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 20, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK4_SEL, "infra_pwm_ck4_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 22, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK5_SEL, "infra_pwm_ck5_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 24, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK6_SEL, "infra_pwm_ck6_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 26, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK7_SEL, "infra_pwm_ck7_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 28, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK8_SEL, "infra_pwm_ck8_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 30, 2, -1, -1, -1),
+	/* MODULE_CLK_SEL_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL, "infra_pcie_gfmux_tl_o_p0_sel",
+			     infra_pcie_gfmux_tl_ck_o_p0_parents, 0x0028, 0x0020, 0x0024, 0, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL, "infra_pcie_gfmux_tl_o_p1_sel",
+			     infra_pcie_gfmux_tl_ck_o_p1_parents, 0x0028, 0x0020, 0x0024, 2, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL, "infra_pcie_gfmux_tl_o_p2_sel",
+			     infra_pcie_gfmux_tl_ck_o_p2_parents, 0x0028, 0x0020, 0x0024, 4, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL, "infra_pcie_gfmux_tl_o_p3_sel",
+			     infra_pcie_gfmux_tl_ck_o_p3_parents, 0x0028, 0x0020, 0x0024, 6, 2, -1,
+			     -1, -1),
+};
+
+static const struct mtk_gate_regs infra0_cg_regs = {
+	.set_ofs = 0x10,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x18,
+};
+
+static const struct mtk_gate_regs infra1_cg_regs = {
+	.set_ofs = 0x40,
+	.clr_ofs = 0x44,
+	.sta_ofs = 0x48,
+};
+
+static const struct mtk_gate_regs infra2_cg_regs = {
+	.set_ofs = 0x50,
+	.clr_ofs = 0x54,
+	.sta_ofs = 0x58,
+};
+
+static const struct mtk_gate_regs infra3_cg_regs = {
+	.set_ofs = 0x60,
+	.clr_ofs = 0x64,
+	.sta_ofs = 0x68,
+};
+
+#define GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra0_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra1_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra2_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra3_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA0(_id, _name, _parent, _shift) GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA1(_id, _name, _parent, _shift) GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA2(_id, _name, _parent, _shift) GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA3(_id, _name, _parent, _shift) GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, 0)
+
+static const struct mtk_gate infra_clks[] = {
+	/* INFRA0 */
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P0, "infra_pcie_peri_ck_26m_ck_p0",
+		    "csw_infra_f26m_sel", 7),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P1, "infra_pcie_peri_ck_26m_ck_p1",
+		    "csw_infra_f26m_sel", 8),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P2, "infra_pcie_peri_ck_26m_ck_p2",
+		    "csw_infra_f26m_sel", 9),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P3, "infra_pcie_peri_ck_26m_ck_p3",
+		    "csw_infra_f26m_sel", 10),
+	/* INFRA1 */
+	GATE_INFRA1(CLK_INFRA_66M_GPT_BCK, "infra_hf_66m_gpt_bck", "sysaxi_sel", 0),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_HCK, "infra_hf_66m_pwm_hck", "sysaxi_sel", 1),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_BCK, "infra_hf_66m_pwm_bck", "infra_pwm_sel", 2),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK1, "infra_hf_66m_pwm_ck1", "infra_pwm_ck1_sel", 3),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK2, "infra_hf_66m_pwm_ck2", "infra_pwm_ck2_sel", 4),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK3, "infra_hf_66m_pwm_ck3", "infra_pwm_ck3_sel", 5),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK4, "infra_hf_66m_pwm_ck4", "infra_pwm_ck4_sel", 6),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK5, "infra_hf_66m_pwm_ck5", "infra_pwm_ck5_sel", 7),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK6, "infra_hf_66m_pwm_ck6", "infra_pwm_ck6_sel", 8),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK7, "infra_hf_66m_pwm_ck7", "infra_pwm_ck7_sel", 9),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK8, "infra_hf_66m_pwm_ck8", "infra_pwm_ck8_sel", 10),
+	GATE_INFRA1(CLK_INFRA_133M_CQDMA_BCK, "infra_hf_133m_cqdma_bck", "sysaxi_sel", 12),
+	GATE_INFRA1(CLK_INFRA_66M_AUD_SLV_BCK, "infra_66m_aud_slv_bck", "sysaxi_sel", 13),
+	GATE_INFRA1(CLK_INFRA_AUD_26M, "infra_f_faud_26m", "csw_infra_f26m_sel", 14),
+	GATE_INFRA1(CLK_INFRA_AUD_L, "infra_f_faud_l", "aud_l_sel", 15),
+	GATE_INFRA1(CLK_INFRA_AUD_AUD, "infra_f_aud_aud", "a1sys_sel", 16),
+	GATE_INFRA1(CLK_INFRA_AUD_EG2, "infra_f_faud_eg2", "a_tuner_sel", 18),
+	GATE_INFRA1_FLAGS(CLK_INFRA_DRAMC_F26M, "infra_dramc_f26m", "csw_infra_f26m_sel", 19,
+			  CLK_IS_CRITICAL),
+	/* JTAG */
+	GATE_INFRA1_FLAGS(CLK_INFRA_133M_DBG_ACKM, "infra_hf_133m_dbg_ackm", "sysaxi_sel", 20,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA1(CLK_INFRA_66M_AP_DMA_BCK, "infra_66m_ap_dma_bck", "sysaxi_sel", 21),
+	GATE_INFRA1(CLK_INFRA_66M_SEJ_BCK, "infra_hf_66m_sej_bck", "sysaxi_sel", 29),
+	GATE_INFRA1(CLK_INFRA_PRE_CK_SEJ_F13M, "infra_pre_ck_sej_f13m", "csw_infra_f26m_sel", 30),
+	/* INFRA2 */
+	GATE_INFRA2(CLK_INFRA_26M_THERM_SYSTEM, "infra_hf_26m_therm_system", "csw_infra_f26m_sel",
+		    0),
+	GATE_INFRA2(CLK_INFRA_I2C_BCK, "infra_i2c_bck", "i2c_sel", 1),
+	GATE_INFRA2(CLK_INFRA_52M_UART0_CK, "infra_f_52m_uart0", "infra_mux_uart0_sel", 3),
+	GATE_INFRA2(CLK_INFRA_52M_UART1_CK, "infra_f_52m_uart1", "infra_mux_uart1_sel", 4),
+	GATE_INFRA2(CLK_INFRA_52M_UART2_CK, "infra_f_52m_uart2", "infra_mux_uart2_sel", 5),
+	GATE_INFRA2(CLK_INFRA_NFI, "infra_f_fnfi", "nfi1x_sel", 9),
+	GATE_INFRA2(CLK_INFRA_SPINFI, "infra_f_fspinfi", "spinfi_sel", 10),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_NFI_HCK, "infra_hf_66m_nfi_hck", "sysaxi_sel", 11,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2_FLAGS(CLK_INFRA_104M_SPI0, "infra_hf_104m_spi0", "infra_mux_spi0_sel", 12,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_104M_SPI1, "infra_hf_104m_spi1", "infra_mux_spi1_sel", 13),
+	GATE_INFRA2(CLK_INFRA_104M_SPI2_BCK, "infra_hf_104m_spi2_bck", "infra_mux_spi2_sel", 14),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_SPI0_HCK, "infra_hf_66m_spi0_hck", "sysaxi_sel", 15,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_66M_SPI1_HCK, "infra_hf_66m_spi1_hck", "sysaxi_sel", 16),
+	GATE_INFRA2(CLK_INFRA_66M_SPI2_HCK, "infra_hf_66m_spi2_hck", "sysaxi_sel", 17),
+	GATE_INFRA2(CLK_INFRA_66M_FLASHIF_AXI, "infra_hf_66m_flashif_axi", "sysaxi_sel", 18),
+	GATE_INFRA2_FLAGS(CLK_INFRA_RTC, "infra_f_frtc", "top_rtc_32k", 19, CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_26M_ADC_BCK, "infra_f_26m_adc_bck", "csw_infra_f26m_sel", 20),
+	GATE_INFRA2(CLK_INFRA_RC_ADC, "infra_f_frc_adc", "infra_f_26m_adc_bck", 21),
+	GATE_INFRA2(CLK_INFRA_MSDC400, "infra_f_fmsdc400", "emmc_400m_sel", 22),
+	GATE_INFRA2(CLK_INFRA_MSDC2_HCK, "infra_f_fmsdc2_hck", "emmc_250m_sel", 23),
+	GATE_INFRA2(CLK_INFRA_133M_MSDC_0_HCK, "infra_hf_133m_msdc_0_hck", "sysaxi_sel", 24),
+	GATE_INFRA2(CLK_INFRA_66M_MSDC_0_HCK, "infra_66m_msdc_0_hck", "sysaxi_sel", 25),
+	GATE_INFRA2(CLK_INFRA_133M_CPUM_BCK, "infra_hf_133m_cpum_bck", "sysaxi_sel", 26),
+	GATE_INFRA2(CLK_INFRA_BIST2FPC, "infra_hf_fbist2fpc", "nfi1x_sel", 27),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_MCK_CK_P1, "infra_hf_i2c_x16w_mck_ck_p1", "sysaxi_sel", 29),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_PCK_CK_P1, "infra_hf_i2c_x16w_pck_ck_p1", "sysaxi_sel", 31),
+	/* INFRA3 */
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK, "infra_133m_usb_hck", "sysaxi_sel", 0),
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK_CK_P1, "infra_133m_usb_hck_ck_p1", "sysaxi_sel", 1),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK, "infra_66m_usb_hck", "sysaxi_sel", 2),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK_CK_P1, "infra_66m_usb_hck_ck_p1", "sysaxi_sel", 3),
+	GATE_INFRA3(CLK_INFRA_USB_SYS, "infra_usb_sys", "usb_sys_sel", 4),
+	GATE_INFRA3(CLK_INFRA_USB_SYS_CK_P1, "infra_usb_sys_ck_p1", "usb_sys_p1_sel", 5),
+	GATE_INFRA3(CLK_INFRA_USB_REF, "infra_usb_ref", "top_xtal", 6),
+	GATE_INFRA3(CLK_INFRA_USB_CK_P1, "infra_usb_ck_p1", "top_xtal", 7),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT, "infra_usb_frmcnt", "usb_frmcnt_sel", 8,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT_CK_P1, "infra_usb_frmcnt_ck_p1", "usb_frmcnt_p1_sel",
+			  9, CLK_IS_CRITICAL),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE, "infra_usb_pipe", "sspxtp_sel", 10),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE_CK_P1, "infra_usb_pipe_ck_p1", "usb_phy_sel", 11),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI, "infra_usb_utmi", "top_xtal", 12),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI_CK_P1, "infra_usb_utmi_ck_p1", "top_xtal", 13),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI, "infra_usb_xhci", "usb_xhci_sel", 14),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI_CK_P1, "infra_usb_xhci_ck_p1", "usb_xhci_p1_sel", 15),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P0, "infra_pcie_gfmux_tl_ck_p0",
+		    "infra_pcie_gfmux_tl_o_p0_sel", 20),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P1, "infra_pcie_gfmux_tl_ck_p1",
+		    "infra_pcie_gfmux_tl_o_p1_sel", 21),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P2, "infra_pcie_gfmux_tl_ck_p2",
+		    "infra_pcie_gfmux_tl_o_p2_sel", 22),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P3, "infra_pcie_gfmux_tl_ck_p3",
+		    "infra_pcie_gfmux_tl_o_p3_sel", 23),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P0, "infra_pcie_pipe_ck_p0", "top_xtal", 24),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P1, "infra_pcie_pipe_ck_p1", "top_xtal", 25),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P2, "infra_pcie_pipe_ck_p2", "top_xtal", 26),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P3, "infra_pcie_pipe_ck_p3", "top_xtal", 27),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P0, "infra_133m_pcie_ck_p0", "sysaxi_sel", 28),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P1, "infra_133m_pcie_ck_p1", "sysaxi_sel", 29),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P2, "infra_133m_pcie_ck_p2", "sysaxi_sel", 30),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P3, "infra_133m_pcie_ck_p3", "sysaxi_sel", 31),
+};
+
+static const struct mtk_clk_desc infra_desc = {
+	.clks = infra_clks,
+	.num_clks = ARRAY_SIZE(infra_clks),
+	.mux_clks = infra_muxes,
+	.num_mux_clks = ARRAY_SIZE(infra_muxes),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const struct of_device_id of_match_clk_mt7988_infracfg[] = {
+	{ .compatible = "mediatek,mt7988-infracfg", .data = &infra_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_infracfg);
+
+static struct platform_driver clk_mt7988_infracfg_drv = {
+	.driver = {
+		.name = "clk-mt7988-infracfg",
+		.of_match_table = of_match_clk_mt7988_infracfg,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_infracfg_drv);
diff --git a/drivers/clk/mediatek/clk-mt7988-topckgen.c b/drivers/clk/mediatek/clk-mt7988-topckgen.c
new file mode 100644
index 0000000000000..760f8e0d2f26a
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-topckgen.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+	FIXED_CLK(CLK_TOP_XTAL, "top_xtal", "clkxtal", 40000000),
+};
+
+static const struct mtk_fixed_factor top_divs[] = {
+	FACTOR(CLK_TOP_XTAL_D2, "top_xtal_d2", "top_xtal", 1, 2),
+	FACTOR(CLK_TOP_RTC_32K, "top_rtc_32k", "top_xtal", 1, 1250),
+	FACTOR(CLK_TOP_RTC_32P7K, "top_rtc_32p7k", "top_xtal", 1, 1220),
+	FACTOR(CLK_TOP_MPLL_D2, "mpll_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D3_D2, "mpll_d3_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D4, "mpll_d4", "mpll", 1, 4),
+	FACTOR(CLK_TOP_MPLL_D8, "mpll_d8", "mpll", 1, 8),
+	FACTOR(CLK_TOP_MPLL_D8_D2, "mpll_d8_d2", "mpll", 1, 16),
+	FACTOR(CLK_TOP_MMPLL_D2, "mmpll_d2", "mmpll", 1, 2),
+	FACTOR(CLK_TOP_MMPLL_D3_D5, "mmpll_d3_d5", "mmpll", 1, 15),
+	FACTOR(CLK_TOP_MMPLL_D4, "mmpll_d4", "mmpll", 1, 4),
+	FACTOR(CLK_TOP_MMPLL_D6_D2, "mmpll_d6_d2", "mmpll", 1, 12),
+	FACTOR(CLK_TOP_MMPLL_D8, "mmpll_d8", "mmpll", 1, 8),
+	FACTOR(CLK_TOP_APLL2_D4, "apll2_d4", "apll2", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D4, "net1pll_d4", "net1pll", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D5, "net1pll_d5", "net1pll", 1, 5),
+	FACTOR(CLK_TOP_NET1PLL_D5_D2, "net1pll_d5_d2", "net1pll", 1, 10),
+	FACTOR(CLK_TOP_NET1PLL_D5_D4, "net1pll_d5_d4", "net1pll", 1, 20),
+	FACTOR(CLK_TOP_NET1PLL_D8, "net1pll_d8", "net1pll", 1, 8),
+	FACTOR(CLK_TOP_NET1PLL_D8_D2, "net1pll_d8_d2", "net1pll", 1, 16),
+	FACTOR(CLK_TOP_NET1PLL_D8_D4, "net1pll_d8_d4", "net1pll", 1, 32),
+	FACTOR(CLK_TOP_NET1PLL_D8_D8, "net1pll_d8_d8", "net1pll", 1, 64),
+	FACTOR(CLK_TOP_NET1PLL_D8_D16, "net1pll_d8_d16", "net1pll", 1, 128),
+	FACTOR(CLK_TOP_NET2PLL_D2, "net2pll_d2", "net2pll", 1, 2),
+	FACTOR(CLK_TOP_NET2PLL_D4, "net2pll_d4", "net2pll", 1, 4),
+	FACTOR(CLK_TOP_NET2PLL_D4_D4, "net2pll_d4_d4", "net2pll", 1, 16),
+	FACTOR(CLK_TOP_NET2PLL_D4_D8, "net2pll_d4_d8", "net2pll", 1, 32),
+	FACTOR(CLK_TOP_NET2PLL_D6, "net2pll_d6", "net2pll", 1, 6),
+	FACTOR(CLK_TOP_NET2PLL_D8, "net2pll_d8", "net2pll", 1, 8),
+};
+
+static const char *const netsys_parents[] = { "top_xtal", "net2pll_d2", "mmpll_d2" };
+static const char *const netsys_500m_parents[] = { "top_xtal", "net1pll_d5", "net1pll_d5_d2" };
+static const char *const netsys_2x_parents[] = { "top_xtal", "net2pll", "mmpll" };
+static const char *const netsys_gsw_parents[] = { "top_xtal", "net1pll_d4", "net1pll_d5" };
+static const char *const eth_gmii_parents[] = { "top_xtal", "net1pll_d5_d4" };
+static const char *const netsys_mcu_parents[] = { "top_xtal",	"net2pll",    "mmpll",
+						  "net1pll_d4", "net1pll_d5", "mpll" };
+static const char *const eip197_parents[] = { "top_xtal", "netsyspll",	"net2pll",
+					      "mmpll",	  "net1pll_d4", "net1pll_d5" };
+static const char *const axi_infra_parents[] = { "top_xtal", "net1pll_d8_d2" };
+static const char *const uart_parents[] = { "top_xtal", "mpll_d8", "mpll_d8_d2" };
+static const char *const emmc_250m_parents[] = { "top_xtal", "net1pll_d5_d2", "mmpll_d4" };
+static const char *const emmc_400m_parents[] = { "top_xtal", "msdcpll",	 "mmpll_d2",
+						 "mpll_d2",  "mmpll_d4", "net1pll_d8_d2" };
+static const char *const spi_parents[] = { "top_xtal",	    "mpll_d2",	    "mmpll_d4",
+					   "net1pll_d8_d2", "net2pll_d6",   "net1pll_d5_d4",
+					   "mpll_d4",	    "net1pll_d8_d4" };
+static const char *const nfi1x_parents[] = { "top_xtal", "mmpll_d4", "net1pll_d8_d2", "net2pll_d6",
+					     "mpll_d4",	 "mmpll_d8", "net1pll_d8_d4", "mpll_d8" };
+static const char *const spinfi_parents[] = { "top_xtal_d2", "top_xtal", "net1pll_d5_d4",
+					      "mpll_d4",     "mmpll_d8", "net1pll_d8_d4",
+					      "mmpll_d6_d2", "mpll_d8" };
+static const char *const pwm_parents[] = { "top_xtal", "net1pll_d8_d2", "net1pll_d5_d4",
+					   "mpll_d4",  "mpll_d8_d2",	"top_rtc_32k" };
+static const char *const i2c_parents[] = { "top_xtal", "net1pll_d5_d4", "mpll_d4",
+					   "net1pll_d8_d4" };
+static const char *const pcie_mbist_250m_parents[] = { "top_xtal", "net1pll_d5_d2" };
+static const char *const pextp_tl_ck_parents[] = { "top_xtal", "net2pll_d6", "mmpll_d8",
+						   "mpll_d8_d2", "top_rtc_32k" };
+static const char *const usb_frmcnt_parents[] = { "top_xtal", "mmpll_d3_d5" };
+static const char *const aud_parents[] = { "top_xtal", "apll2" };
+static const char *const a1sys_parents[] = { "top_xtal", "apll2_d4" };
+static const char *const aud_l_parents[] = { "top_xtal", "apll2", "mpll_d8_d2" };
+static const char *const sspxtp_parents[] = { "top_xtal_d2", "mpll_d8_d2" };
+static const char *const usxgmii_sbus_0_parents[] = { "top_xtal", "net1pll_d8_d4" };
+static const char *const sgm_0_parents[] = { "top_xtal", "sgmpll" };
+static const char *const sysapb_parents[] = { "top_xtal", "mpll_d3_d2" };
+static const char *const eth_refck_50m_parents[] = { "top_xtal", "net2pll_d4_d4" };
+static const char *const eth_sys_200m_parents[] = { "top_xtal", "net2pll_d4" };
+static const char *const eth_xgmii_parents[] = { "top_xtal_d2", "net1pll_d8_d8", "net1pll_d8_d16" };
+static const char *const bus_tops_parents[] = { "top_xtal", "net1pll_d5", "net2pll_d2" };
+static const char *const npu_tops_parents[] = { "top_xtal", "net2pll" };
+static const char *const dramc_md32_parents[] = { "top_xtal", "mpll_d2", "wedmcupll" };
+static const char *const da_xtp_glb_p0_parents[] = { "top_xtal", "net2pll_d8" };
+static const char *const mcusys_backup_625m_parents[] = { "top_xtal", "net1pll_d4" };
+static const char *const macsec_parents[] = { "top_xtal", "sgmpll", "net1pll_d8" };
+static const char *const netsys_tops_400m_parents[] = { "top_xtal", "net2pll_d2" };
+static const char *const eth_mii_parents[] = { "top_xtal_d2", "net2pll_d4_d8" };
+
+static const struct mtk_mux top_muxes[] = {
+	/* CLK_CFG_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SEL, "netsys_sel", netsys_parents, 0x000, 0x004, 0x008,
+			     0, 2, 7, 0x1c0, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_500M_SEL, "netsys_500m_sel", netsys_500m_parents, 0x000,
+			     0x004, 0x008, 8, 2, 15, 0x1C0, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_2X_SEL, "netsys_2x_sel", netsys_2x_parents, 0x000,
+			     0x004, 0x008, 16, 2, 23, 0x1C0, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_GSW_SEL, "netsys_gsw_sel", netsys_gsw_parents, 0x000,
+			     0x004, 0x008, 24, 2, 31, 0x1C0, 3),
+	/* CLK_CFG_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_GMII_SEL, "eth_gmii_sel", eth_gmii_parents, 0x010, 0x014,
+			     0x018, 0, 1, 7, 0x1C0, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_MCU_SEL, "netsys_mcu_sel", netsys_mcu_parents, 0x010,
+			     0x014, 0x018, 8, 3, 15, 0x1C0, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PAO_2X_SEL, "netsys_pao_2x_sel", netsys_mcu_parents,
+			     0x010, 0x014, 0x018, 16, 3, 23, 0x1C0, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EIP197_SEL, "eip197_sel", eip197_parents, 0x010, 0x014, 0x018,
+			     24, 3, 31, 0x1c0, 7),
+	/* CLK_CFG_2 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_AXI_INFRA_SEL, "axi_infra_sel", axi_infra_parents, 0x020,
+				   0x024, 0x028, 0, 1, 7, 0x1C0, 8, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_UART_SEL, "uart_sel", uart_parents, 0x020, 0x024, 0x028, 8, 2,
+			     15, 0x1c0, 9),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_250M_SEL, "emmc_250m_sel", emmc_250m_parents, 0x020,
+			     0x024, 0x028, 16, 2, 23, 0x1C0, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_400M_SEL, "emmc_400m_sel", emmc_400m_parents, 0x020,
+			     0x024, 0x028, 24, 3, 31, 0x1C0, 11),
+	/* CLK_CFG_3 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPI_SEL, "spi_sel", spi_parents, 0x030, 0x034, 0x038, 0, 3, 7,
+			     0x1c0, 12),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPIM_MST_SEL, "spim_mst_sel", spi_parents, 0x030, 0x034, 0x038,
+			     8, 3, 15, 0x1c0, 13),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NFI1X_SEL, "nfi1x_sel", nfi1x_parents, 0x030, 0x034, 0x038, 16,
+			     3, 23, 0x1c0, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPINFI_SEL, "spinfi_sel", spinfi_parents, 0x030, 0x034, 0x038,
+			     24, 3, 31, 0x1c0, 15),
+	/* CLK_CFG_4 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PWM_SEL, "pwm_sel", pwm_parents, 0x040, 0x044, 0x048, 0, 3, 7,
+			     0x1c0, 16),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_I2C_SEL, "i2c_sel", i2c_parents, 0x040, 0x044, 0x048, 8, 2, 15,
+			     0x1c0, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PCIE_MBIST_250M_SEL, "pcie_mbist_250m_sel",
+			     pcie_mbist_250m_parents, 0x040, 0x044, 0x048, 16, 1, 23, 0x1C0, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_SEL, "pextp_tl_sel", pextp_tl_ck_parents, 0x040,
+			     0x044, 0x048, 24, 3, 31, 0x1C0, 19),
+	/* CLK_CFG_5 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P1_SEL, "pextp_tl_p1_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 0, 3, 7, 0x1C0, 20),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P2_SEL, "pextp_tl_p2_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 8, 3, 15, 0x1C0, 21),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P3_SEL, "pextp_tl_p3_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 16, 3, 23, 0x1C0, 22),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_SEL, "usb_sys_sel", eth_gmii_parents, 0x050, 0x054,
+			     0x058, 24, 1, 31, 0x1C0, 23),
+	/* CLK_CFG_6 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_P1_SEL, "usb_sys_p1_sel", eth_gmii_parents, 0x060,
+			     0x064, 0x068, 0, 1, 7, 0x1C0, 24),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_SEL, "usb_xhci_sel", eth_gmii_parents, 0x060, 0x064,
+			     0x068, 8, 1, 15, 0x1C0, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_P1_SEL, "usb_xhci_p1_sel", eth_gmii_parents, 0x060,
+			     0x064, 0x068, 16, 1, 23, 0x1C0, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_SEL, "usb_frmcnt_sel", usb_frmcnt_parents, 0x060,
+			     0x064, 0x068, 24, 1, 31, 0x1C0, 27),
+	/* CLK_CFG_7 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_P1_SEL, "usb_frmcnt_p1_sel", usb_frmcnt_parents,
+			     0x070, 0x074, 0x078, 0, 1, 7, 0x1C0, 28),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_SEL, "aud_sel", aud_parents, 0x070, 0x074, 0x078, 8, 1, 15,
+			     0x1c0, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A1SYS_SEL, "a1sys_sel", a1sys_parents, 0x070, 0x074, 0x078, 16,
+			     1, 23, 0x1c0, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_L_SEL, "aud_l_sel", aud_l_parents, 0x070, 0x074, 0x078, 24,
+			     2, 31, 0x1c4, 0),
+	/* CLK_CFG_8 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A_TUNER_SEL, "a_tuner_sel", a1sys_parents, 0x080, 0x084, 0x088,
+			     0, 1, 7, 0x1c4, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SSPXTP_SEL, "sspxtp_sel", sspxtp_parents, 0x080, 0x084, 0x088,
+			     8, 1, 15, 0x1c4, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_PHY_SEL, "usb_phy_sel", sspxtp_parents, 0x080, 0x084,
+			     0x088, 16, 1, 23, 0x1c4, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_0_SEL, "usxgmii_sbus_0_sel",
+			     usxgmii_sbus_0_parents, 0x080, 0x084, 0x088, 24, 1, 31, 0x1C4, 4),
+	/* CLK_CFG_9 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_1_SEL, "usxgmii_sbus_1_sel",
+			     usxgmii_sbus_0_parents, 0x090, 0x094, 0x098, 0, 1, 7, 0x1C4, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_0_SEL, "sgm_0_sel", sgm_0_parents, 0x090, 0x094, 0x098, 8,
+			     1, 15, 0x1c4, 6),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_0_SEL, "sgm_sbus_0_sel", usxgmii_sbus_0_parents,
+				   0x090, 0x094, 0x098, 16, 1, 23, 0x1C4, 7, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_1_SEL, "sgm_1_sel", sgm_0_parents, 0x090, 0x094, 0x098, 24,
+			     1, 31, 0x1c4, 8),
+	/* CLK_CFG_10 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_1_SEL, "sgm_sbus_1_sel", usxgmii_sbus_0_parents,
+				   0x0a0, 0x0a4, 0x0a8, 0, 1, 7, 0x1C4, 9, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_0_XTAL_SEL, "xfi_phy_0_xtal_sel", sspxtp_parents,
+			     0x0a0, 0x0a4, 0x0a8, 8, 1, 15, 0x1C4, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_1_XTAL_SEL, "xfi_phy_1_xtal_sel", sspxtp_parents,
+			     0x0a0, 0x0a4, 0x0a8, 16, 1, 23, 0x1C4, 11),
+	/* CLK_CFG_11 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAXI_SEL, "sysaxi_sel", axi_infra_parents, 0x0a0,
+				   0x0a4, 0x0a8, 24, 1, 31, 0x1C4, 12, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAPB_SEL, "sysapb_sel", sysapb_parents, 0x0b0, 0x0b4,
+				   0x0b8, 0, 1, 7, 0x1c4, 13, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_REFCK_50M_SEL, "eth_refck_50m_sel", eth_refck_50m_parents,
+			     0x0b0, 0x0b4, 0x0b8, 8, 1, 15, 0x1C4, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_200M_SEL, "eth_sys_200m_sel", eth_sys_200m_parents,
+			     0x0b0, 0x0b4, 0x0b8, 16, 1, 23, 0x1C4, 15),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_SEL, "eth_sys_sel", pcie_mbist_250m_parents, 0x0b0,
+			     0x0b4, 0x0b8, 24, 1, 31, 0x1C4, 16),
+	/* CLK_CFG_12 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_XGMII_SEL, "eth_xgmii_sel", eth_xgmii_parents, 0x0c0,
+			     0x0c4, 0x0c8, 0, 2, 7, 0x1C4, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_BUS_TOPS_SEL, "bus_tops_sel", bus_tops_parents, 0x0c0, 0x0c4,
+			     0x0c8, 8, 2, 15, 0x1C4, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_TOPS_SEL, "npu_tops_sel", npu_tops_parents, 0x0c0, 0x0c4,
+			     0x0c8, 16, 1, 23, 0x1C4, 19),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_SEL, "dramc_sel", sspxtp_parents, 0x0c0, 0x0c4,
+				   0x0c8, 24, 1, 31, 0x1C4, 20, CLK_IS_CRITICAL),
+	/* CLK_CFG_13 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_MD32_SEL, "dramc_md32_sel", dramc_md32_parents,
+				   0x0d0, 0x0d4, 0x0d8, 0, 2, 7, 0x1C4, 21, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_INFRA_F26M_SEL, "csw_infra_f26m_sel", sspxtp_parents,
+				   0x0d0, 0x0d4, 0x0d8, 8, 1, 15, 0x1C4, 22, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P0_SEL, "pextp_p0_sel", sspxtp_parents, 0x0d0, 0x0d4,
+			     0x0d8, 16, 1, 23, 0x1C4, 23),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P1_SEL, "pextp_p1_sel", sspxtp_parents, 0x0d0, 0x0d4,
+			     0x0d8, 24, 1, 31, 0x1C4, 24),
+	/* CLK_CFG_14 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P2_SEL, "pextp_p2_sel", sspxtp_parents, 0x0e0, 0x0e4,
+			     0x0e8, 0, 1, 7, 0x1C4, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P3_SEL, "pextp_p3_sel", sspxtp_parents, 0x0e0, 0x0e4,
+			     0x0e8, 8, 1, 15, 0x1C4, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P0_SEL, "da_xtp_glb_p0_sel", da_xtp_glb_p0_parents,
+			     0x0e0, 0x0e4, 0x0e8, 16, 1, 23, 0x1C4, 27),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P1_SEL, "da_xtp_glb_p1_sel", da_xtp_glb_p0_parents,
+			     0x0e0, 0x0e4, 0x0e8, 24, 1, 31, 0x1C4, 28),
+	/* CLK_CFG_15 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P2_SEL, "da_xtp_glb_p2_sel", da_xtp_glb_p0_parents,
+			     0x0f0, 0x0f4, 0x0f8, 0, 1, 7, 0x1C4, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P3_SEL, "da_xtp_glb_p3_sel", da_xtp_glb_p0_parents,
+			     0x0f0, 0x0f4, 0x0f8, 8, 1, 15, 0x1C4, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_CKM_SEL, "ckm_sel", sspxtp_parents, 0x0F0, 0x0f4, 0x0f8, 16, 1,
+			     23, 0x1c8, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_SEL, "da_sel", sspxtp_parents, 0x0f0, 0x0f4, 0x0f8, 24, 1,
+			     31, 0x1C8, 1),
+	/* CLK_CFG_16 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_SEL, "pextp_sel", sspxtp_parents, 0x0100, 0x104, 0x108,
+			     0, 1, 7, 0x1c8, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_TOPS_P2_26M_SEL, "tops_p2_26m_sel", sspxtp_parents, 0x0100,
+			     0x104, 0x108, 8, 1, 15, 0x1C8, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MCUSYS_BACKUP_625M_SEL, "mcusys_backup_625m_sel",
+			     mcusys_backup_625m_parents, 0x0100, 0x104, 0x108, 16, 1, 23, 0x1C8, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SYNC_250M_SEL, "netsys_sync_250m_sel",
+			     pcie_mbist_250m_parents, 0x0100, 0x104, 0x108, 24, 1, 31, 0x1c8, 5),
+	/* CLK_CFG_17 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MACSEC_SEL, "macsec_sel", macsec_parents, 0x0110, 0x114, 0x118,
+			     0, 2, 7, 0x1c8, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_TOPS_400M_SEL, "netsys_tops_400m_sel",
+			     netsys_tops_400m_parents, 0x0110, 0x114, 0x118, 8, 1, 15, 0x1c8, 7),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PPEFB_250M_SEL, "netsys_ppefb_250m_sel",
+			     pcie_mbist_250m_parents, 0x0110, 0x114, 0x118, 16, 1, 23, 0x1c8, 8),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_WARP_SEL, "netsys_warp_sel", netsys_parents, 0x0110,
+			     0x114, 0x118, 24, 2, 31, 0x1C8, 9),
+	/* CLK_CFG_18 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_MII_SEL, "eth_mii_sel", eth_mii_parents, 0x0120, 0x124,
+			     0x128, 0, 1, 7, 0x1c8, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_SEL, "ck_npu_sel", netsys_2x_parents, 0x0120, 0x124, 0x128,
+			     8, 2, 15, 0x1c8, 11),
+};
+
+static const struct mtk_composite top_aud_divs[] = {
+	DIV_GATE(CLK_TOP_AUD_I2S_M, "aud_i2s_m", "aud_sel", 0x0420, 0, 0x0420, 8, 8),
+};
+
+static const struct mtk_clk_desc topck_desc = {
+	.fixed_clks = top_fixed_clks,
+	.num_fixed_clks = ARRAY_SIZE(top_fixed_clks),
+	.factor_clks = top_divs,
+	.num_factor_clks = ARRAY_SIZE(top_divs),
+	.mux_clks = top_muxes,
+	.num_mux_clks = ARRAY_SIZE(top_muxes),
+	.composite_clks = top_aud_divs,
+	.num_composite_clks = ARRAY_SIZE(top_aud_divs),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const char *const mcu_bus_div_parents[] = { "top_xtal", "ccipll2_b", "net1pll_d4" };
+
+static const char *const mcu_arm_div_parents[] = { "top_xtal", "arm_b", "net1pll_d4" };
+
+static struct mtk_composite mcu_muxes[] = {
+	/* bus_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_BUS_DIV_SEL, "mcu_bus_div_sel", mcu_bus_div_parents, 0x7C0, 9, 2, -1,
+		       CLK_IS_CRITICAL),
+	/* mp2_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_ARM_DIV_SEL, "mcu_arm_div_sel", mcu_arm_div_parents, 0x7A8, 9, 2, -1,
+		       CLK_IS_CRITICAL),
+};
+
+static const struct mtk_clk_desc mcusys_desc = {
+	.composite_clks = mcu_muxes,
+	.num_composite_clks = ARRAY_SIZE(mcu_muxes),
+};
+
+static const struct of_device_id of_match_clk_mt7988_topckgen[] = {
+	{ .compatible = "mediatek,mt7988-topckgen", .data = &topck_desc },
+	{ .compatible = "mediatek,mt7988-mcusys", .data = &mcusys_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_topckgen);
+
+static struct platform_driver clk_mt7988_topckgen_drv = {
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+	.driver = {
+		.name = "clk-mt7988-topckgen",
+		.of_match_table = of_match_clk_mt7988_topckgen,
+	},
+};
+module_platform_driver(clk_mt7988_topckgen_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-xfipll.c b/drivers/clk/mediatek/clk-mt7988-xfipll.c
new file mode 100644
index 0000000000000..9b9ca5471158b
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-xfipll.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+/* Register to control USXGMII XFI PLL analog */
+#define XFI_PLL_ANA_GLB8		0x108
+#define RG_XFI_PLL_ANA_SWWA		0x02283248
+
+static const struct mtk_gate_regs xfipll_cg_regs = {
+	.set_ofs = 0x8,
+	.clr_ofs = 0x8,
+	.sta_ofs = 0x8,
+};
+
+#define GATE_XFIPLL(_id, _name, _parent, _shift)		\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &xfipll_cg_regs,			\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_fixed_factor xfipll_divs[] = {
+	FACTOR(CLK_XFIPLL_PLL, "xfipll_pll", "top_xtal", 125, 32),
+};
+
+static const struct mtk_gate xfipll_clks[] = {
+	GATE_XFIPLL(CLK_XFIPLL_PLL_EN, "xfipll_pll_en", "xfipll_pll", 31),
+};
+
+static const struct mtk_clk_desc xfipll_desc = {
+	.clks = xfipll_clks,
+	.num_clks = ARRAY_SIZE(xfipll_clks),
+	.factor_clks = xfipll_divs,
+	.num_factor_clks = ARRAY_SIZE(xfipll_divs),
+};
+
+static int clk_mt7988_xfipll_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	void __iomem *base = of_iomap(node, 0);
+
+	if (!base)
+		return -ENOMEM;
+
+	/* Apply software workaround for USXGMII PLL TCL issue */
+	writel(RG_XFI_PLL_ANA_SWWA, base + XFI_PLL_ANA_GLB8);
+	iounmap(base);
+
+	return mtk_clk_simple_probe(pdev);
+};
+
+static const struct of_device_id of_match_clk_mt7988_xfipll[] = {
+	{ .compatible = "mediatek,mt7988-xfi-pll", .data = &xfipll_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_xfipll);
+
+static struct platform_driver clk_mt7988_xfipll_drv = {
+	.driver = {
+		.name = "clk-mt7988-xfipll",
+		.of_match_table = of_match_clk_mt7988_xfipll,
+	},
+	.probe = clk_mt7988_xfipll_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_xfipll_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 XFI PLL clock driver");
+MODULE_LICENSE("GPL");
-- 
2.43.0


From yang.guang5 at zte.com.cn  Mon Dec 11 19:20:34 2023
From: yang.guang5 at zte.com.cn (yang.guang5 at zte.com.cn)
Date: Tue, 12 Dec 2023 11:20:34 +0800 (CST)
Subject: =?UTF-8?B?W1BBVENIIGxpbnV4LW5leHRdIEFSTS9kbWEtbWFwcGluZzogcmVwbGFjZSBremFsbG9jKCkgYW5kIHZ6YWxsb2MoKSB3aXRoIGt2emFsbG9jKCk=?=
Message-ID: <202312121120348064534@zte.com.cn>

From: Yang Guang <yang.guang5 at zte.com.cn>
using kvzalloc() simplifies the code by avoiding the 
use of different memory allocation functions for different 
situations, making the code more uniform and readable.

Signed-off-by: Chen Haonan <chen.haonan2 at zte.com.cn>
---
 arch/arm/mm/dma-mapping.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 5409225b4abc..d688eac6dbc1 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -859,10 +859,7 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size,
 	int i = 0;
 	int order_idx = 0;

-	if (array_size <= PAGE_SIZE)
-		pages = kzalloc(array_size, GFP_KERNEL);
-	else
-		pages = vzalloc(array_size);
+	pages = kvzalloc(array_size, GFP_KERNEL);
 	if (!pages)
 		return NULL;

-- 
2.25.1


From tudor.ambarus at linaro.org  Mon Dec 11 19:40:21 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Tue, 12 Dec 2023 03:40:21 +0000
Subject: [PATCH 1/2] mtd: rawnand: rockchip: Rename a structure
In-Reply-To: <20231211150704.109138-1-miquel.raynal@bootlin.com>
References: <20231211150704.109138-1-miquel.raynal@bootlin.com>
Message-ID: <611d17e0-c965-4218-9152-5bd93f92ed45@linaro.org>



On 12/11/23 15:07, Miquel Raynal wrote:
> Robots are unhappy with the ecc_cnt_status structure because the kernel
> doc says it should be called rk_ecc_cnt_status. In general, it is
> considered a better practice to prefix all symbols in a file with the
> same prexif, and thus it seems more relevant to rename the structure
> rather than changing the kernel doc header.
> 
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312102130.geZ4dqyN-lkp at intel.com/
> Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
> Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>

Reviewed-by Tudor Ambarus <tudor.ambarus at linaro.org>

> ---
>  drivers/mtd/nand/raw/rockchip-nand-controller.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c b/drivers/mtd/nand/raw/rockchip-nand-controller.c
> index 596cf9a78274..ab1a9e8687e0 100644
> --- a/drivers/mtd/nand/raw/rockchip-nand-controller.c
> +++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c
> @@ -98,7 +98,7 @@ enum nfc_type {
>   * @high: ECC count high bit index at register.
>   * @high_mask: mask bit
>   */
> -struct ecc_cnt_status {
> +struct rk_ecc_cnt_status {
>  	u8 err_flag_bit;
>  	u8 low;
>  	u8 low_mask;
> @@ -144,8 +144,8 @@ struct nfc_cfg {
>  	u32 int_st_off;
>  	u32 oob0_off;
>  	u32 oob1_off;
> -	struct ecc_cnt_status ecc0;
> -	struct ecc_cnt_status ecc1;
> +	struct rk_ecc_cnt_status ecc0;
> +	struct rk_ecc_cnt_status ecc1;
>  };
>  
>  struct rk_nfc_nand_chip {


From tudor.ambarus at linaro.org  Mon Dec 11 19:41:48 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Tue, 12 Dec 2023 03:41:48 +0000
Subject: [PATCH 2/2] mtd: rawnand: rockchip: Add missing title to a kernel
 doc comment
In-Reply-To: <20231211150704.109138-2-miquel.raynal@bootlin.com>
References: <20231211150704.109138-1-miquel.raynal@bootlin.com>
 <20231211150704.109138-2-miquel.raynal@bootlin.com>
Message-ID: <fe0a16e9-a1f9-424e-a06d-f717f65e0fd7@linaro.org>



On 12/11/23 15:07, Miquel Raynal wrote:
> All fields of the nfc_cfg structure are documented but the name, which
> leads to a W=1 warning. Add a title.
> 
> Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
> Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>

Reviewed-by Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  drivers/mtd/nand/raw/rockchip-nand-controller.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c b/drivers/mtd/nand/raw/rockchip-nand-controller.c
> index ab1a9e8687e0..7baaef69d70a 100644
> --- a/drivers/mtd/nand/raw/rockchip-nand-controller.c
> +++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c
> @@ -108,6 +108,7 @@ struct rk_ecc_cnt_status {
>  };
>  
>  /**
> + * struct nfc_cfg: Rockchip NAND controller configuration
>   * @type: NFC version
>   * @ecc_strengths: ECC strengths
>   * @ecc_cfgs: ECC config values


From daniel at makrotopia.org  Mon Dec 11 19:45:42 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:45:42 +0000
Subject: [RFC PATCH net-next v3 0/8] Add support for 10G Ethernet SerDes on
 MT7988
Message-ID: <cover.1702352117.git.daniel@makrotopia.org>

This series aims to add support for GMAC2 and GMAC3 of the MediaTek MT7988 SoC.
While the vendor SDK stuffs all this into their Ethernet driver, I've tried to
seperate things into a PHY driver, a PCS driver as well as changes to the
existing Ethernet and LynxI PCS driver.

 +--------------+   +----------------+   +------------------+
 |              +---|  USXGMII PCS   |---+                  |
 | Ethernet MAC |   +----------------+   | PEXTP SerDes PHY |
 |              +---|   SGMII PCS    |---+                  |
 +--------------+   +----------------+   +------------------+

Alltogether this allows using GMAC2 and GMAC3 with all possible interface modes,
including in-band-status if needed.

Note that this series depends on series "dt-bindings: clock: mediatek:
add MT7988 clock IDs"[1] as well as "dt-bindings: watchdog:
mediatek,mtk-wdt: add MT7988 watchdog and toprgu"[2] being merged
before.

[1]: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=809031
[2]: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=802588

Changes since RFC v2:
 - use clk_bulk_* when ever feasible
 - rework Ethernet <-> PCS driver link, use device_link
 
Changes since RFC v1:
 - drop patch inhibiting SGMII AN in 2500Base-X mode
 - make pcs-mtk-lynxi a proper platform driver
 - ... hence allowing to remove all the wrappers from the usxgmii driver
 - attach PEXTP to MAC instead of to USXGMII PCS

Daniel Golle (8):
  dt-bindings: phy: mediatek,xfi-pextp: add new bindings
  phy: add driver for MediaTek pextp 10GE SerDes PHY
  net: pcs: pcs-mtk-lynxi: add platform driver for MT7988
  dt-bindings: net: pcs: add bindings for MediaTek USXGMII PCS
  net: pcs: add driver for MediaTek USXGMII PCS
  dt-bindings: net: mediatek: remove wrongly added clocks and SerDes
  dt-bindings: net: mediatek,net: fix and complete mt7988-eth binding
  net: ethernet: mtk_eth_soc: add paths and SerDes modes for MT7988

 .../devicetree/bindings/net/mediatek,net.yaml | 180 +++++--
 .../bindings/net/pcs/mediatek,usxgmii.yaml    |  60 +++
 .../bindings/phy/mediatek,xfi-pextp.yaml      |  80 +++
 MAINTAINERS                                   |   3 +
 drivers/net/ethernet/mediatek/mtk_eth_path.c  | 122 ++++-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 291 +++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h   | 107 +++-
 drivers/net/pcs/Kconfig                       |  11 +
 drivers/net/pcs/Makefile                      |   1 +
 drivers/net/pcs/pcs-mtk-lynxi.c               | 226 ++++++++-
 drivers/net/pcs/pcs-mtk-usxgmii.c             | 456 ++++++++++++++++++
 drivers/phy/mediatek/Kconfig                  |  11 +
 drivers/phy/mediatek/Makefile                 |   1 +
 drivers/phy/mediatek/phy-mtk-pextp.c          | 361 ++++++++++++++
 include/linux/pcs/pcs-mtk-lynxi.h             |  11 +
 include/linux/pcs/pcs-mtk-usxgmii.h           |  27 ++
 16 files changed, 1859 insertions(+), 89 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
 create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml
 create mode 100644 drivers/net/pcs/pcs-mtk-usxgmii.c
 create mode 100644 drivers/phy/mediatek/phy-mtk-pextp.c
 create mode 100644 include/linux/pcs/pcs-mtk-usxgmii.h

-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:46:26 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:46:26 +0000
Subject: [RFC PATCH net-next v3 1/8] dt-bindings: phy: mediatek,xfi-pextp:
 add new bindings
In-Reply-To: <cover.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
Message-ID: <b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel@makrotopia.org>

Add bindings for the MediaTek PEXTP Ethernet SerDes PHY found in the
MediaTek MT7988 SoC which can operate at various interfaces modes:

 * USXGMII
 * 10GBase-R
 * 5GBase-R
 * 2500Base-X
 * 1000Base-X
 * Cisco SGMII (MAC side)

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 .../bindings/phy/mediatek,xfi-pextp.yaml      | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml

diff --git a/Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml b/Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml
new file mode 100644
index 0000000000000..58c93368141e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,xfi-pextp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek XFI PEXTP SerDes PHY
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The MediaTek XFI PEXTP SerDes PHY provides the physical SerDes lanes
+  used by the MediaTek USXGMII PCS.
+
+properties:
+  $nodename:
+    pattern: "^phy@[0-9a-f]+$"
+
+  compatible:
+    const: mediatek,mt7988-xfi-pextp
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: XFI PHY clock
+      - description: XFI register clock
+
+  clock-names:
+    items:
+      - const: "xfipll"
+      - const: "topxtal"
+
+  resets:
+    items:
+      - description: PEXTP reset
+
+  mediatek,usxgmii-performance-errata:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      USXGMII0 on MT7988 suffers from a performance problem in 10GBase-R
+      mode which needs a work-around in the driver. The work-around is
+      enabled using this flag.
+
+  "#phy-cells":
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mediatek,mt7988-clk.h>
+    #include <dt-bindings/reset/mediatek,mt7988-resets.h>
+    soc {
+      #address-cells = <2>;
+      #size-cells = <2>;
+
+      phy at 11f20000 {
+        compatible = "mediatek,mt7988-xfi-pextp";
+        reg = <0 0x11f20000 0 0x10000>;
+        clocks = <&xfi_pll CLK_XFIPLL_PLL_EN>,
+                 <&topckgen CLK_TOP_XFI_PHY_0_XTAL_SEL>;
+        clock-names = "xfipll", "topxtal";
+        resets = <&watchdog MT7988_TOPRGU_XFI_PEXTP0_GRST>;
+        mediatek,usxgmii-performance-errata;
+        #phy-cells = <0>;
+      };
+    };
+
+...
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:46:52 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:46:52 +0000
Subject: [RFC PATCH net-next v3 2/8] phy: add driver for MediaTek pextp 10GE
 SerDes PHY
In-Reply-To: <cover.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
Message-ID: <a58dae1cce1b49093b0ae05159c784a9ec02f058.1702352117.git.daniel@makrotopia.org>

Add driver for MediaTek's pextp 10 Gigabit/s Ethernet SerDes PHY which
can be found in the MT7988 SoC.

The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
PHY_INTERFACE_MODE_* corresponding to the supported modes:

 * USXGMII
 * 10GBase-R
 * 5GBase-R
 * 2500Base-X
 * 1000Base-X
 * Cisco SGMII (MAC side)

In order to work-around a performance issue present on the first of
two PEXTP present in MT7988 special tuning is applied which can be
selected by adding the mediatek,usxgmii-performance-errata property to
the device tree node.

There is no documentation what-so-ever for the pextp registers and
this driver is based on a GPL licensed implementation found in
MediaTek's SDK.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 MAINTAINERS                          |   1 +
 drivers/phy/mediatek/Kconfig         |  11 +
 drivers/phy/mediatek/Makefile        |   1 +
 drivers/phy/mediatek/phy-mtk-pextp.c | 361 +++++++++++++++++++++++++++
 4 files changed, 374 insertions(+)
 create mode 100644 drivers/phy/mediatek/phy-mtk-pextp.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 98f7dd0499f17..b2772cfe2a704 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13510,6 +13510,7 @@ L:	netdev at vger.kernel.org
 S:	Maintained
 F:	drivers/net/phy/mediatek-ge-soc.c
 F:	drivers/net/phy/mediatek-ge.c
+F:	drivers/phy/mediatek/phy-mtk-pextp.c
 
 MEDIATEK I2C CONTROLLER DRIVER
 M:	Qii Wang <qii.wang at mediatek.com>
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index 3125ecb5d119f..a7749a6d96541 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -13,6 +13,17 @@ config PHY_MTK_PCIE
 	  callback for PCIe GEN3 port, it supports software efuse
 	  initialization.
 
+config PHY_MTK_PEXTP
+	tristate "MediaTek PEXTP Driver"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	depends on OF && OF_ADDRESS
+	depends on HAS_IOMEM
+	select GENERIC_PHY
+	help
+	  Say 'Y' here to add support for MediaTek pextp PHY driver.
+	  The driver provides access to the Ethernet SerDes PHY supporting
+	  various 1GE, 2.5GE, 5GE and 10GE modes.
+
 config PHY_MTK_TPHY
 	tristate "MediaTek T-PHY Driver"
 	depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index c9a50395533eb..ca60c7b9b02ac 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PHY_MTK_PCIE)		+= phy-mtk-pcie.o
 obj-$(CONFIG_PHY_MTK_TPHY)		+= phy-mtk-tphy.o
 obj-$(CONFIG_PHY_MTK_UFS)		+= phy-mtk-ufs.o
 obj-$(CONFIG_PHY_MTK_XSPHY)		+= phy-mtk-xsphy.o
+obj-$(CONFIG_PHY_MTK_PEXTP)		+= phy-mtk-pextp.o
 
 phy-mtk-hdmi-drv-y			:= phy-mtk-hdmi.o
 phy-mtk-hdmi-drv-y			+= phy-mtk-hdmi-mt2701.o
diff --git a/drivers/phy/mediatek/phy-mtk-pextp.c b/drivers/phy/mediatek/phy-mtk-pextp.c
new file mode 100644
index 0000000000000..3ec48cf129105
--- /dev/null
+++ b/drivers/phy/mediatek/phy-mtk-pextp.c
@@ -0,0 +1,361 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* MediaTek 10GE SerDes PHY driver
+ *
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ * based on mtk_usxgmii.c found in MediaTek's SDK released under GPL-2.0
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Henry Yen <henry.yen at mediatek.com>
+ */
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/netdevice.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/reset.h>
+#include <linux/phy.h>
+#include <linux/phy/phy.h>
+
+#define MTK_PEXTP_NUM_CLOCKS	2
+
+struct mtk_pextp_phy {
+	void __iomem		*base;
+	struct device		*dev;
+	struct reset_control	*reset;
+	struct clk_bulk_data	clocks[MTK_PEXTP_NUM_CLOCKS];
+	bool			da_war;
+};
+
+static bool mtk_interface_mode_is_xgmii(phy_interface_t interface)
+{
+	switch (interface) {
+	case PHY_INTERFACE_MODE_INTERNAL:
+	case PHY_INTERFACE_MODE_USXGMII:
+	case PHY_INTERFACE_MODE_10GBASER:
+	case PHY_INTERFACE_MODE_5GBASER:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static void mtk_pextp_setup(struct mtk_pextp_phy *pextp, phy_interface_t interface)
+{
+	bool is_10g = (interface == PHY_INTERFACE_MODE_10GBASER ||
+		       interface == PHY_INTERFACE_MODE_USXGMII);
+	bool is_2p5g = (interface == PHY_INTERFACE_MODE_2500BASEX);
+	bool is_5g = (interface == PHY_INTERFACE_MODE_5GBASER);
+
+	dev_dbg(pextp->dev, "setting up for mode %s\n", phy_modes(interface));
+
+	/* Setup operation mode */
+	if (is_10g)
+		iowrite32(0x00c9071c, pextp->base + 0x9024);
+	else
+		iowrite32(0x00d9071c, pextp->base + 0x9024);
+
+	if (is_5g)
+		iowrite32(0xaaa5a5aa, pextp->base + 0x2020);
+	else
+		iowrite32(0xaa8585aa, pextp->base + 0x2020);
+
+	if (is_2p5g || is_5g || is_10g) {
+		iowrite32(0x0c020707, pextp->base + 0x2030);
+		iowrite32(0x0e050f0f, pextp->base + 0x2034);
+		iowrite32(0x00140032, pextp->base + 0x2040);
+	} else {
+		iowrite32(0x0c020207, pextp->base + 0x2030);
+		iowrite32(0x0e05050f, pextp->base + 0x2034);
+		iowrite32(0x00200032, pextp->base + 0x2040);
+	}
+
+	if (is_2p5g || is_10g)
+		iowrite32(0x00c014aa, pextp->base + 0x50f0);
+	else if (is_5g)
+		iowrite32(0x00c018aa, pextp->base + 0x50f0);
+	else
+		iowrite32(0x00c014ba, pextp->base + 0x50f0);
+
+	if (is_5g) {
+		iowrite32(0x3777812b, pextp->base + 0x50e0);
+		iowrite32(0x005c9cff, pextp->base + 0x506c);
+		iowrite32(0x9dfafafa, pextp->base + 0x5070);
+		iowrite32(0x273f3f3f, pextp->base + 0x5074);
+		iowrite32(0xa8883868, pextp->base + 0x5078);
+		iowrite32(0x14661466, pextp->base + 0x507c);
+	} else {
+		iowrite32(0x3777c12b, pextp->base + 0x50e0);
+		iowrite32(0x005f9cff, pextp->base + 0x506c);
+		iowrite32(0x9d9dfafa, pextp->base + 0x5070);
+		iowrite32(0x27273f3f, pextp->base + 0x5074);
+		iowrite32(0xa7883c68, pextp->base + 0x5078);
+		iowrite32(0x11661166, pextp->base + 0x507c);
+	}
+
+	if (is_2p5g || is_10g) {
+		iowrite32(0x0e000aaf, pextp->base + 0x5080);
+		iowrite32(0x08080d0d, pextp->base + 0x5084);
+		iowrite32(0x02030909, pextp->base + 0x5088);
+	} else if (is_5g) {
+		iowrite32(0x0e001abf, pextp->base + 0x5080);
+		iowrite32(0x080b0d0d, pextp->base + 0x5084);
+		iowrite32(0x02050909, pextp->base + 0x5088);
+	} else {
+		iowrite32(0x0e000eaf, pextp->base + 0x5080);
+		iowrite32(0x08080e0d, pextp->base + 0x5084);
+		iowrite32(0x02030b09, pextp->base + 0x5088);
+	}
+
+	if (is_5g) {
+		iowrite32(0x0c000000, pextp->base + 0x50e4);
+		iowrite32(0x04000000, pextp->base + 0x50e8);
+	} else {
+		iowrite32(0x0c0c0000, pextp->base + 0x50e4);
+		iowrite32(0x04040000, pextp->base + 0x50e8);
+	}
+
+	if (is_2p5g || mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x0f0f0c06, pextp->base + 0x50eC);
+	else
+		iowrite32(0x0f0f0606, pextp->base + 0x50eC);
+
+	if (is_5g) {
+		iowrite32(0x50808c8c, pextp->base + 0x50a8);
+		iowrite32(0x18000000, pextp->base + 0x6004);
+	} else {
+		iowrite32(0x506e8c8c, pextp->base + 0x50a8);
+		iowrite32(0x18190000, pextp->base + 0x6004);
+	}
+
+	if (is_10g)
+		iowrite32(0x01423342, pextp->base + 0x00f8);
+	else if (is_5g)
+		iowrite32(0x00a132a1, pextp->base + 0x00f8);
+	else if (is_2p5g)
+		iowrite32(0x009c329c, pextp->base + 0x00f8);
+	else
+		iowrite32(0x00fa32fa, pextp->base + 0x00f8);
+
+	/* Force SGDT_OUT off and select PCS */
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x80201f20, pextp->base + 0x00f4);
+	else
+		iowrite32(0x80201f21, pextp->base + 0x00f4);
+
+	/* Force GLB_CKDET_OUT */
+	iowrite32(0x00050c00, pextp->base + 0x0030);
+
+	/* Force AEQ on */
+	iowrite32(0x02002800, pextp->base + 0x0070);
+	ndelay(1020);
+
+	/* Setup DA default value */
+	iowrite32(0x00000020, pextp->base + 0x30b0);
+	iowrite32(0x00008a01, pextp->base + 0x3028);
+	iowrite32(0x0000a884, pextp->base + 0x302c);
+	iowrite32(0x00083002, pextp->base + 0x3024);
+	if (mtk_interface_mode_is_xgmii(interface)) {
+		iowrite32(0x00022220, pextp->base + 0x3010);
+		iowrite32(0x0f020a01, pextp->base + 0x5064);
+		iowrite32(0x06100600, pextp->base + 0x50b4);
+		if (interface == PHY_INTERFACE_MODE_USXGMII)
+			iowrite32(0x40704000, pextp->base + 0x3048);
+		else
+			iowrite32(0x47684100, pextp->base + 0x3048);
+	} else {
+		iowrite32(0x00011110, pextp->base + 0x3010);
+		iowrite32(0x40704000, pextp->base + 0x3048);
+	}
+
+	if (!mtk_interface_mode_is_xgmii(interface) && !is_2p5g)
+		iowrite32(0x0000c000, pextp->base + 0x3064);
+
+	if (interface != PHY_INTERFACE_MODE_10GBASER) {
+		iowrite32(0xa8000000, pextp->base + 0x3050);
+		iowrite32(0x000000aa, pextp->base + 0x3054);
+	} else {
+		iowrite32(0x00000000, pextp->base + 0x3050);
+		iowrite32(0x00000000, pextp->base + 0x3054);
+	}
+
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x00000f00, pextp->base + 0x306c);
+	else if (is_2p5g)
+		iowrite32(0x22000f00, pextp->base + 0x306c);
+	else
+		iowrite32(0x20200f00, pextp->base + 0x306c);
+
+	if (interface == PHY_INTERFACE_MODE_10GBASER && pextp->da_war)
+		iowrite32(0x0007b400, pextp->base + 0xa008);
+
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x00040000, pextp->base + 0xa060);
+	else
+		iowrite32(0x00050000, pextp->base + 0xa060);
+
+	if (is_10g)
+		iowrite32(0x00000001, pextp->base + 0x90d0);
+	else if (is_5g)
+		iowrite32(0x00000003, pextp->base + 0x90d0);
+	else if (is_2p5g)
+		iowrite32(0x00000005, pextp->base + 0x90d0);
+	else
+		iowrite32(0x00000007, pextp->base + 0x90d0);
+
+	/* Release reset */
+	iowrite32(0x0200e800, pextp->base + 0x0070);
+	usleep_range(150, 500);
+
+	/* Switch to P0 */
+	iowrite32(0x0200c111, pextp->base + 0x0070);
+	ndelay(1020);
+	iowrite32(0x0200c101, pextp->base + 0x0070);
+	usleep_range(15, 50);
+
+	if (mtk_interface_mode_is_xgmii(interface)) {
+		/* Switch to Gen3 */
+		iowrite32(0x0202c111, pextp->base + 0x0070);
+	} else {
+		/* Switch to Gen2 */
+		iowrite32(0x0201c111, pextp->base + 0x0070);
+	}
+	ndelay(1020);
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x0202c101, pextp->base + 0x0070);
+	else
+		iowrite32(0x0201c101, pextp->base + 0x0070);
+	usleep_range(100, 500);
+	iowrite32(0x00000030, pextp->base + 0x30b0);
+	if (mtk_interface_mode_is_xgmii(interface))
+		iowrite32(0x80201f00, pextp->base + 0x00f4);
+	else
+		iowrite32(0x80201f01, pextp->base + 0x00f4);
+
+	iowrite32(0x30000000, pextp->base + 0x3040);
+	usleep_range(400, 1000);
+}
+
+static int mtk_pextp_set_mode(struct phy *phy, enum phy_mode mode, int submode)
+{
+	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
+
+	if (mode != PHY_MODE_ETHERNET)
+		return -EINVAL;
+
+	switch (submode) {
+	case PHY_INTERFACE_MODE_1000BASEX:
+	case PHY_INTERFACE_MODE_2500BASEX:
+	case PHY_INTERFACE_MODE_SGMII:
+	case PHY_INTERFACE_MODE_5GBASER:
+	case PHY_INTERFACE_MODE_10GBASER:
+	case PHY_INTERFACE_MODE_USXGMII:
+		mtk_pextp_setup(pextp, submode);
+		return 0;
+	default:
+		return -EINVAL;
+	}
+}
+
+static int mtk_pextp_reset(struct phy *phy)
+{
+	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
+
+	reset_control_assert(pextp->reset);
+	usleep_range(100, 500);
+	reset_control_deassert(pextp->reset);
+	usleep_range(1, 10);
+
+	return 0;
+}
+
+static int mtk_pextp_power_on(struct phy *phy)
+{
+	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
+
+	return clk_bulk_prepare_enable(MTK_PEXTP_NUM_CLOCKS, pextp->clocks);
+}
+
+static int mtk_pextp_power_off(struct phy *phy)
+{
+	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
+
+	clk_bulk_disable_unprepare(MTK_PEXTP_NUM_CLOCKS, pextp->clocks);
+
+	return 0;
+}
+
+static const struct phy_ops mtk_pextp_ops = {
+	.power_on	= mtk_pextp_power_on,
+	.power_off	= mtk_pextp_power_off,
+	.set_mode	= mtk_pextp_set_mode,
+	.reset		= mtk_pextp_reset,
+	.owner		= THIS_MODULE,
+};
+
+static int mtk_pextp_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct phy_provider *phy_provider;
+	struct mtk_pextp_phy *pextp;
+	struct phy *phy;
+
+	if (!np)
+		return -ENODEV;
+
+	pextp = devm_kzalloc(&pdev->dev, sizeof(*pextp), GFP_KERNEL);
+	if (!pextp)
+		return -ENOMEM;
+
+	pextp->base = devm_of_iomap(&pdev->dev, np, 0, NULL);
+	if (!pextp->base)
+		return -EIO;
+
+	pextp->dev = &pdev->dev;
+
+	pextp->clocks[0].id = "topxtal";
+	pextp->clocks[0].clk = devm_clk_get(&pdev->dev, pextp->clocks[0].id);
+	if (IS_ERR(pextp->clocks[0].clk))
+		return PTR_ERR(pextp->clocks[0].clk);
+
+	pextp->clocks[1].id = "xfipll";
+	pextp->clocks[1].clk = devm_clk_get(&pdev->dev, pextp->clocks[1].id);
+	if (IS_ERR(pextp->clocks[1].clk))
+		return PTR_ERR(pextp->clocks[1].clk);
+
+	pextp->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+	if (IS_ERR(pextp->reset))
+		return PTR_ERR(pextp->reset);
+
+	pextp->da_war = of_property_read_bool(np, "mediatek,usxgmii-performance-errata");
+
+	phy = devm_phy_create(&pdev->dev, NULL, &mtk_pextp_ops);
+	if (IS_ERR(phy))
+		return PTR_ERR(phy);
+
+	phy_set_drvdata(phy, pextp);
+
+	phy_provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
+
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id mtk_pextp_match[] = {
+	{ .compatible = "mediatek,mt7988-xfi-pextp", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, mtk_pextp_match);
+
+static struct platform_driver mtk_pextp_driver = {
+	.probe = mtk_pextp_probe,
+	.driver = {
+		.name = "mtk-pextp",
+		.of_match_table = mtk_pextp_match,
+	},
+};
+module_platform_driver(mtk_pextp_driver);
+
+MODULE_DESCRIPTION("MediaTek pextp SerDes PHY driver");
+MODULE_AUTHOR("Daniel Golle <daniel at makrotopia.org>");
+MODULE_LICENSE("GPL");
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:47:18 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:47:18 +0000
Subject: [RFC PATCH net-next v3 3/8] net: pcs: pcs-mtk-lynxi: add platform
 driver for MT7988
In-Reply-To: <cover.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
Message-ID: <8aa905080bdb6760875d62cb3b2b41258837f80e.1702352117.git.daniel@makrotopia.org>

Introduce a proper platform MFD driver for the LynxI (H)SGMII PCS which
is going to initially be used for the MT7988 SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 drivers/net/pcs/pcs-mtk-lynxi.c   | 226 ++++++++++++++++++++++++++++--
 include/linux/pcs/pcs-mtk-lynxi.h |  11 ++
 2 files changed, 226 insertions(+), 11 deletions(-)

diff --git a/drivers/net/pcs/pcs-mtk-lynxi.c b/drivers/net/pcs/pcs-mtk-lynxi.c
index 8501dd365279b..e06dd7db66144 100644
--- a/drivers/net/pcs/pcs-mtk-lynxi.c
+++ b/drivers/net/pcs/pcs-mtk-lynxi.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright (c) 2018-2019 MediaTek Inc.
-/* A library for MediaTek SGMII circuit
+/* A library and platform driver for the MediaTek LynxI SGMII circuit
  *
  * Author: Sean Wang <sean.wang at mediatek.com>
  * Author: Alexander Couzens <lynxis at fe80.eu>
@@ -8,11 +8,17 @@
  *
  */
 
+#include <linux/clk.h>
 #include <linux/mdio.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mutex.h>
 #include <linux/of.h>
+#include <linux/of_platform.h>
 #include <linux/pcs/pcs-mtk-lynxi.h>
 #include <linux/phylink.h>
+#include <linux/platform_device.h>
 #include <linux/regmap.h>
+#include <linux/reset.h>
 
 /* SGMII subsystem config registers */
 /* BMCR (low 16) BMSR (high 16) */
@@ -65,6 +71,8 @@
 #define SGMII_PN_SWAP_MASK		GENMASK(1, 0)
 #define SGMII_PN_SWAP_TX_RX		(BIT(0) | BIT(1))
 
+#define MTK_NETSYS_V3_AMA_RGC3		0x128
+
 /* struct mtk_pcs_lynxi -  This structure holds each sgmii regmap andassociated
  *                         data
  * @regmap:                The register map pointing at the range used to setup
@@ -74,15 +82,29 @@
  * @interface:             Currently configured interface mode
  * @pcs:                   Phylink PCS structure
  * @flags:                 Flags indicating hardware properties
+ * @rstc:                  Reset controller
+ * @sgmii_sel:             SGMII Register Clock
+ * @sgmii_rx:              SGMII RX Clock
+ * @sgmii_tx:              SGMII TX Clock
+ * @node:                  List node
  */
 struct mtk_pcs_lynxi {
 	struct regmap		*regmap;
+	struct device		*dev;
 	u32			ana_rgc3;
 	phy_interface_t		interface;
 	struct			phylink_pcs pcs;
 	u32			flags;
+	struct reset_control	*rstc;
+	struct clk		*sgmii_sel;
+	struct clk		*sgmii_rx;
+	struct clk		*sgmii_tx;
+	struct list_head	node;
 };
 
+static LIST_HEAD(mtk_pcs_lynxi_instances);
+static DEFINE_MUTEX(instance_mutex);
+
 static struct mtk_pcs_lynxi *pcs_to_mtk_pcs_lynxi(struct phylink_pcs *pcs)
 {
 	return container_of(pcs, struct mtk_pcs_lynxi, pcs);
@@ -102,6 +124,17 @@ static void mtk_pcs_lynxi_get_state(struct phylink_pcs *pcs,
 					 FIELD_GET(SGMII_LPA, adv));
 }
 
+static void mtk_sgmii_reset(struct mtk_pcs_lynxi *mpcs)
+{
+	if (!mpcs->rstc)
+		return;
+
+	reset_control_assert(mpcs->rstc);
+	udelay(100);
+	reset_control_deassert(mpcs->rstc);
+	mdelay(1);
+}
+
 static int mtk_pcs_lynxi_config(struct phylink_pcs *pcs, unsigned int neg_mode,
 				phy_interface_t interface,
 				const unsigned long *advertising,
@@ -147,6 +180,7 @@ static int mtk_pcs_lynxi_config(struct phylink_pcs *pcs, unsigned int neg_mode,
 				SGMII_PHYA_PWD);
 
 		/* Reset SGMII PCS state */
+		mtk_sgmii_reset(mpcs);
 		regmap_set_bits(mpcs->regmap, SGMSYS_RESERVED_0,
 				SGMII_SW_RESET);
 
@@ -233,10 +267,29 @@ static void mtk_pcs_lynxi_link_up(struct phylink_pcs *pcs,
 	}
 }
 
+static int mtk_pcs_lynxi_enable(struct phylink_pcs *pcs)
+{
+	struct mtk_pcs_lynxi *mpcs = pcs_to_mtk_pcs_lynxi(pcs);
+
+	if (mpcs->sgmii_tx && mpcs->sgmii_rx) {
+		clk_prepare_enable(mpcs->sgmii_rx);
+		clk_prepare_enable(mpcs->sgmii_tx);
+	}
+
+	return 0;
+}
+
 static void mtk_pcs_lynxi_disable(struct phylink_pcs *pcs)
 {
 	struct mtk_pcs_lynxi *mpcs = pcs_to_mtk_pcs_lynxi(pcs);
 
+	regmap_set_bits(mpcs->regmap, SGMSYS_QPHY_PWR_STATE_CTRL, SGMII_PHYA_PWD);
+
+	if (mpcs->sgmii_tx && mpcs->sgmii_rx) {
+		clk_disable_unprepare(mpcs->sgmii_tx);
+		clk_disable_unprepare(mpcs->sgmii_rx);
+	}
+
 	mpcs->interface = PHY_INTERFACE_MODE_NA;
 }
 
@@ -246,11 +299,12 @@ static const struct phylink_pcs_ops mtk_pcs_lynxi_ops = {
 	.pcs_an_restart = mtk_pcs_lynxi_restart_an,
 	.pcs_link_up = mtk_pcs_lynxi_link_up,
 	.pcs_disable = mtk_pcs_lynxi_disable,
+	.pcs_enable = mtk_pcs_lynxi_enable,
 };
 
-struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
-					 struct regmap *regmap, u32 ana_rgc3,
-					 u32 flags)
+static struct phylink_pcs *mtk_pcs_lynxi_init(struct device *dev, struct regmap *regmap,
+					      u32 ana_rgc3, u32 flags,
+					      struct mtk_pcs_lynxi *prealloc)
 {
 	struct mtk_pcs_lynxi *mpcs;
 	u32 id, ver;
@@ -258,29 +312,33 @@ struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
 
 	ret = regmap_read(regmap, SGMSYS_PCS_DEVICE_ID, &id);
 	if (ret < 0)
-		return NULL;
+		return ERR_PTR(ret);
 
 	if (id != SGMII_LYNXI_DEV_ID) {
 		dev_err(dev, "unknown PCS device id %08x\n", id);
-		return NULL;
+		return ERR_PTR(-ENODEV);
 	}
 
 	ret = regmap_read(regmap, SGMSYS_PCS_SCRATCH, &ver);
 	if (ret < 0)
-		return NULL;
+		return ERR_PTR(ret);
 
 	ver = FIELD_GET(SGMII_DEV_VERSION, ver);
 	if (ver != 0x1) {
 		dev_err(dev, "unknown PCS device version %04x\n", ver);
-		return NULL;
+		return ERR_PTR(-ENODEV);
 	}
 
 	dev_dbg(dev, "MediaTek LynxI SGMII PCS (id 0x%08x, ver 0x%04x)\n", id,
 		ver);
 
-	mpcs = kzalloc(sizeof(*mpcs), GFP_KERNEL);
-	if (!mpcs)
-		return NULL;
+	if (prealloc) {
+		mpcs = prealloc;
+	} else {
+		mpcs = kzalloc(sizeof(*mpcs), GFP_KERNEL);
+		if (!mpcs)
+			return ERR_PTR(-ENOMEM);
+	};
 
 	mpcs->ana_rgc3 = ana_rgc3;
 	mpcs->regmap = regmap;
@@ -291,6 +349,13 @@ struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
 	mpcs->interface = PHY_INTERFACE_MODE_NA;
 
 	return &mpcs->pcs;
+};
+
+struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
+					 struct regmap *regmap, u32 ana_rgc3,
+					 u32 flags)
+{
+	return mtk_pcs_lynxi_init(dev, regmap, ana_rgc3, flags, NULL);
 }
 EXPORT_SYMBOL(mtk_pcs_lynxi_create);
 
@@ -303,4 +368,143 @@ void mtk_pcs_lynxi_destroy(struct phylink_pcs *pcs)
 }
 EXPORT_SYMBOL(mtk_pcs_lynxi_destroy);
 
+static int mtk_pcs_lynxi_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct mtk_pcs_lynxi *mpcs;
+	struct phylink_pcs *pcs;
+	struct regmap *regmap;
+	u32 flags = 0;
+
+	mpcs = devm_kzalloc(dev, sizeof(*mpcs), GFP_KERNEL);
+	if (!mpcs)
+		return -ENOMEM;
+
+	mpcs->dev = dev;
+	regmap = syscon_node_to_regmap(np->parent);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	if (of_property_read_bool(np->parent, "mediatek,pnswap"))
+		flags |= MTK_SGMII_FLAG_PN_SWAP;
+
+	mpcs->rstc = of_reset_control_get_shared(np->parent, NULL);
+	if (IS_ERR(mpcs->rstc))
+		return PTR_ERR(mpcs->rstc);
+
+	reset_control_deassert(mpcs->rstc);
+	mpcs->sgmii_sel = devm_clk_get_enabled(dev, "sgmii_sel");
+	if (IS_ERR(mpcs->sgmii_sel))
+		return PTR_ERR(mpcs->sgmii_sel);
+
+	mpcs->sgmii_rx = devm_clk_get(dev, "sgmii_rx");
+	if (IS_ERR(mpcs->sgmii_rx))
+		return PTR_ERR(mpcs->sgmii_rx);
+
+	mpcs->sgmii_tx = devm_clk_get(dev, "sgmii_tx");
+	if (IS_ERR(mpcs->sgmii_tx))
+		return PTR_ERR(mpcs->sgmii_tx);
+
+	pcs = mtk_pcs_lynxi_init(dev, regmap, (uintptr_t)of_device_get_match_data(dev),
+				 flags, mpcs);
+	if (IS_ERR(pcs))
+		return PTR_ERR(pcs);
+
+	regmap_set_bits(mpcs->regmap, SGMSYS_QPHY_PWR_STATE_CTRL, SGMII_PHYA_PWD);
+
+	platform_set_drvdata(pdev, mpcs);
+
+	mutex_lock(&instance_mutex);
+	list_add_tail(&mpcs->node, &mtk_pcs_lynxi_instances);
+	mutex_unlock(&instance_mutex);
+
+	return 0;
+}
+
+static int mtk_pcs_lynxi_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_pcs_lynxi *cur, *tmp;
+
+	mutex_lock(&instance_mutex);
+	list_for_each_entry_safe(cur, tmp, &mtk_pcs_lynxi_instances, node)
+		if (cur->dev == dev) {
+			list_del(&cur->node);
+			kfree(cur);
+			break;
+		}
+	mutex_unlock(&instance_mutex);
+
+	return 0;
+}
+
+static const struct of_device_id mtk_pcs_lynxi_of_match[] = {
+	{ .compatible = "mediatek,mt7988-sgmii", .data = (void *)MTK_NETSYS_V3_AMA_RGC3 },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mtk_pcs_lynxi_of_match);
+
+struct phylink_pcs *mtk_pcs_lynxi_get(struct device *dev, struct device_node *np)
+{
+	struct platform_device *pdev;
+	struct mtk_pcs_lynxi *mpcs;
+
+	if (!np)
+		return NULL;
+
+	if (!of_device_is_available(np))
+		return ERR_PTR(-ENODEV);
+
+	if (!of_match_node(mtk_pcs_lynxi_of_match, np))
+		return ERR_PTR(-EINVAL);
+
+	pdev = of_find_device_by_node(np);
+	if (!pdev || !platform_get_drvdata(pdev)) {
+		if (pdev)
+			put_device(&pdev->dev);
+		return ERR_PTR(-EPROBE_DEFER);
+	}
+
+	mpcs = platform_get_drvdata(pdev);
+	device_link_add(dev, mpcs->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
+
+	return &mpcs->pcs;
+}
+EXPORT_SYMBOL(mtk_pcs_lynxi_get);
+
+void mtk_pcs_lynxi_put(struct phylink_pcs *pcs)
+{
+	struct mtk_pcs_lynxi *cur, *mpcs = NULL;
+
+	if (!pcs)
+		return;
+
+	mutex_lock(&instance_mutex);
+	list_for_each_entry(cur, &mtk_pcs_lynxi_instances, node)
+		if (pcs == &cur->pcs) {
+			mpcs = cur;
+			break;
+		}
+	mutex_unlock(&instance_mutex);
+
+	if (WARN_ON(!mpcs))
+		return;
+
+	put_device(mpcs->dev);
+}
+EXPORT_SYMBOL(mtk_pcs_lynxi_put);
+
+static struct platform_driver mtk_pcs_lynxi_driver = {
+	.driver = {
+		.name = "mtk-pcs-lynxi",
+		.of_match_table = mtk_pcs_lynxi_of_match,
+	},
+	.probe = mtk_pcs_lynxi_probe,
+	.remove = mtk_pcs_lynxi_remove,
+};
+module_platform_driver(mtk_pcs_lynxi_driver);
+
+MODULE_AUTHOR("Daniel Golle <daniel at makrotopia.org>");
+MODULE_DESCRIPTION("MediaTek LynxI HSGMII PCS");
 MODULE_LICENSE("GPL");
diff --git a/include/linux/pcs/pcs-mtk-lynxi.h b/include/linux/pcs/pcs-mtk-lynxi.h
index be3b4ab32f4a7..2d44e951229c7 100644
--- a/include/linux/pcs/pcs-mtk-lynxi.h
+++ b/include/linux/pcs/pcs-mtk-lynxi.h
@@ -10,4 +10,15 @@ struct phylink_pcs *mtk_pcs_lynxi_create(struct device *dev,
 					 struct regmap *regmap,
 					 u32 ana_rgc3, u32 flags);
 void mtk_pcs_lynxi_destroy(struct phylink_pcs *pcs);
+
+#if IS_ENABLED(CONFIG_PCS_MTK_LYNXI)
+struct phylink_pcs *mtk_pcs_lynxi_get(struct device *dev, struct device_node *np);
+void mtk_pcs_lynxi_put(struct phylink_pcs *pcs);
+#else
+static inline struct phylink_pcs *mtk_pcs_lynxi_get(struct device *dev, struct device_node *np)
+{
+	return NULL;
+}
+static inline void mtk_pcs_lynxi_put(struct phylink_pcs *pcs) { }
+#endif /* IS_ENABLED(CONFIG_PCS_MTK_LYNXI) */
 #endif
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:47:31 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:47:31 +0000
Subject: [RFC PATCH net-next v3 4/8] dt-bindings: net: pcs: add bindings for
 MediaTek USXGMII PCS
In-Reply-To: <cover.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
Message-ID: <510af8550385da947e2e2516629c4fbed7fc0f64.1702352117.git.daniel@makrotopia.org>

MediaTek's USXGMII can be found in the MT7988 SoC. We need to access
it in order to configure and monitor the Ethernet SerDes link in
USXGMII, 10GBase-R and 5GBase-R mode. By including a wrapped
legacy 1000Base-X/2500Base-X/Cisco SGMII LynxI PCS as well, those
interface modes are also available.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 .../bindings/net/pcs/mediatek,usxgmii.yaml    | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml

diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
new file mode 100644
index 0000000000000..0cdaa3545edb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pcs/mediatek,usxgmii.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek USXGMII PCS
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The MediaTek USXGMII PCS provides physical link control and status
+  for USXGMII, 10GBase-R and 5GBase-R links on the SerDes interfaces
+  provided by the PEXTP PHY.
+  In order to also support legacy 2500Base-X, 1000Base-X and Cisco
+  SGMII an existing mediatek,*-sgmiisys LynxI PCS is wrapped to
+  provide those interfaces modes on the same SerDes interfaces shared
+  with the USXGMII PCS.
+
+properties:
+  $nodename:
+    pattern: "^pcs@[0-9a-f]+$"
+
+  compatible:
+    const: mediatek,mt7988-usxgmiisys
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: USXGMII top-level clock
+
+  resets:
+    items:
+      - description: XFI reset
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mediatek,mt7988-clk.h>
+    #define MT7988_TOPRGU_XFI0_GRST 12
+    soc {
+      #address-cells = <2>;
+      #size-cells = <2>;
+        usxgmiisys0: pcs at 10080000 {
+          compatible = "mediatek,mt7988-usxgmiisys";
+          reg = <0 0x10080000 0 0x1000>;
+          clocks = <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>;
+          resets = <&watchdog MT7988_TOPRGU_XFI0_GRST>;
+        };
+    };
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:47:47 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:47:47 +0000
Subject: [RFC PATCH net-next v3 5/8] net: pcs: add driver for MediaTek
 USXGMII PCS
In-Reply-To: <cover.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
Message-ID: <07845ec900ba41ff992875dce12c622277592c32.1702352117.git.daniel@makrotopia.org>

Add driver for USXGMII PCS found in the MediaTek MT7988 SoC and supporting
USXGMII, 10GBase-R and 5GBase-R interface modes.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 MAINTAINERS                         |   2 +
 drivers/net/pcs/Kconfig             |  11 +
 drivers/net/pcs/Makefile            |   1 +
 drivers/net/pcs/pcs-mtk-usxgmii.c   | 456 ++++++++++++++++++++++++++++
 include/linux/pcs/pcs-mtk-usxgmii.h |  27 ++
 5 files changed, 497 insertions(+)
 create mode 100644 drivers/net/pcs/pcs-mtk-usxgmii.c
 create mode 100644 include/linux/pcs/pcs-mtk-usxgmii.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b2772cfe2a704..bf798f3b2c0c9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13500,7 +13500,9 @@ M:	Daniel Golle <daniel at makrotopia.org>
 L:	netdev at vger.kernel.org
 S:	Maintained
 F:	drivers/net/pcs/pcs-mtk-lynxi.c
+F:	drivers/net/pcs/pcs-mtk-usxgmii.c
 F:	include/linux/pcs/pcs-mtk-lynxi.h
+F:	include/linux/pcs/pcs-mtk-usxgmii.h
 
 MEDIATEK ETHERNET PHY DRIVERS
 M:	Daniel Golle <daniel at makrotopia.org>
diff --git a/drivers/net/pcs/Kconfig b/drivers/net/pcs/Kconfig
index 87cf308fc6d8b..55a6865bdaba3 100644
--- a/drivers/net/pcs/Kconfig
+++ b/drivers/net/pcs/Kconfig
@@ -25,6 +25,17 @@ config PCS_MTK_LYNXI
 	  This module provides helpers to phylink for managing the LynxI PCS
 	  which is part of MediaTek's SoC and Ethernet switch ICs.
 
+config PCS_MTK_USXGMII
+	tristate "MediaTek USXGMII PCS"
+	select PCS_MTK_LYNXI
+	select PHY_MTK_PEXTP
+	select PHYLINK
+	help
+	  This module provides a driver for MediaTek's USXGMII PCS supporting
+	  10GBase-R, 5GBase-R and USXGMII interface modes.
+	  1000Base-X, 2500Base-X and Cisco SGMII are supported on the same
+	  differential pairs via an embedded LynxI PHY.
+
 config PCS_RZN1_MIIC
 	tristate "Renesas RZ/N1 MII converter"
 	depends on OF && (ARCH_RZN1 || COMPILE_TEST)
diff --git a/drivers/net/pcs/Makefile b/drivers/net/pcs/Makefile
index fb1694192ae63..cc355152ca1ca 100644
--- a/drivers/net/pcs/Makefile
+++ b/drivers/net/pcs/Makefile
@@ -6,4 +6,5 @@ pcs_xpcs-$(CONFIG_PCS_XPCS)	:= pcs-xpcs.o pcs-xpcs-nxp.o pcs-xpcs-wx.o
 obj-$(CONFIG_PCS_XPCS)		+= pcs_xpcs.o
 obj-$(CONFIG_PCS_LYNX)		+= pcs-lynx.o
 obj-$(CONFIG_PCS_MTK_LYNXI)	+= pcs-mtk-lynxi.o
+obj-$(CONFIG_PCS_MTK_USXGMII)	+= pcs-mtk-usxgmii.o
 obj-$(CONFIG_PCS_RZN1_MIIC)	+= pcs-rzn1-miic.o
diff --git a/drivers/net/pcs/pcs-mtk-usxgmii.c b/drivers/net/pcs/pcs-mtk-usxgmii.c
new file mode 100644
index 0000000000000..190bc51739a40
--- /dev/null
+++ b/drivers/net/pcs/pcs-mtk-usxgmii.c
@@ -0,0 +1,456 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Henry Yen <henry.yen at mediatek.com>
+ *         Daniel Golle <daniel at makrotopia.org>
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mdio.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/reset.h>
+#include <linux/pcs/pcs-mtk-usxgmii.h>
+#include <linux/platform_device.h>
+
+/* USXGMII subsystem config registers */
+/* Register to control speed */
+#define RG_PHY_TOP_SPEED_CTRL1			0x80c
+#define USXGMII_RATE_UPDATE_MODE		BIT(31)
+#define USXGMII_MAC_CK_GATED			BIT(29)
+#define USXGMII_IF_FORCE_EN			BIT(28)
+#define USXGMII_RATE_ADAPT_MODE			GENMASK(10, 8)
+#define USXGMII_RATE_ADAPT_MODE_X1		0
+#define USXGMII_RATE_ADAPT_MODE_X2		1
+#define USXGMII_RATE_ADAPT_MODE_X4		2
+#define USXGMII_RATE_ADAPT_MODE_X10		3
+#define USXGMII_RATE_ADAPT_MODE_X100		4
+#define USXGMII_RATE_ADAPT_MODE_X5		5
+#define USXGMII_RATE_ADAPT_MODE_X50		6
+#define USXGMII_XFI_RX_MODE			GENMASK(6, 4)
+#define USXGMII_XFI_TX_MODE			GENMASK(2, 0)
+#define USXGMII_XFI_MODE_10G			0
+#define USXGMII_XFI_MODE_5G			1
+#define USXGMII_XFI_MODE_2P5G			3
+
+/* Register to control PCS AN */
+#define RG_PCS_AN_CTRL0				0x810
+#define USXGMII_AN_RESTART			BIT(31)
+#define USXGMII_AN_SYNC_CNT			GENMASK(30, 11)
+#define USXGMII_AN_ENABLE			BIT(0)
+
+#define RG_PCS_AN_CTRL2				0x818
+#define USXGMII_LINK_TIMER_IDLE_DETECT		GENMASK(29, 20)
+#define USXGMII_LINK_TIMER_COMP_ACK_DETECT	GENMASK(19, 10)
+#define USXGMII_LINK_TIMER_AN_RESTART		GENMASK(9, 0)
+
+/* Register to read PCS AN status */
+#define RG_PCS_AN_STS0				0x81c
+#define USXGMII_LPA				GENMASK(15, 0)
+#define USXGMII_LPA_LATCH			BIT(31)
+
+/* Register to read PCS link status */
+#define RG_PCS_RX_STATUS0			0x904
+#define RG_PCS_RX_STATUS_UPDATE			BIT(16)
+#define RG_PCS_RX_LINK_STATUS			BIT(2)
+
+/* struct mtk_usxgmii_pcs - This structure holds each usxgmii PCS
+ * @pcs:		Phylink PCS structure
+ * @dev:		Pointer to device structure
+ * @base:		IO memory to access PCS hardware
+ * @clk:		Pointer to USXGMII clk
+ * @reset:		Pointer to USXGMII reset control
+ * @interface:		Currently selected interface mode
+ * @neg_mode:		Currently used phylink neg_mode
+ * @node:		List node
+ */
+struct mtk_usxgmii_pcs {
+	struct phylink_pcs		pcs;
+	struct device			*dev;
+	void __iomem			*base;
+	struct clk			*clk;
+	struct reset_control		*reset;
+	phy_interface_t			interface;
+	unsigned int			neg_mode;
+	struct list_head		node;
+};
+
+static LIST_HEAD(mtk_usxgmii_pcs_instances);
+static DEFINE_MUTEX(instance_mutex);
+
+static u32 mtk_r32(struct mtk_usxgmii_pcs *mpcs, unsigned int reg)
+{
+	return ioread32(mpcs->base + reg);
+}
+
+static void mtk_m32(struct mtk_usxgmii_pcs *mpcs, unsigned int reg, u32 mask, u32 set)
+{
+	u32 val;
+
+	val = ioread32(mpcs->base + reg);
+	val &= ~mask;
+	val |= set;
+	iowrite32(val, mpcs->base + reg);
+}
+
+static struct mtk_usxgmii_pcs *pcs_to_mtk_usxgmii_pcs(struct phylink_pcs *pcs)
+{
+	return container_of(pcs, struct mtk_usxgmii_pcs, pcs);
+}
+
+static void mtk_usxgmii_reset(struct mtk_usxgmii_pcs *mpcs)
+{
+	reset_control_assert(mpcs->reset);
+	udelay(100);
+	reset_control_deassert(mpcs->reset);
+
+	mdelay(10);
+}
+
+static int mtk_usxgmii_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
+				  phy_interface_t interface,
+				  const unsigned long *advertising,
+				  bool permit_pause_to_mac)
+{
+	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
+	unsigned int an_ctrl = 0, link_timer = 0, xfi_mode = 0, adapt_mode = 0;
+	bool mode_changed = false;
+
+	if (interface == PHY_INTERFACE_MODE_USXGMII) {
+		an_ctrl = FIELD_PREP(USXGMII_AN_SYNC_CNT, 0x1FF) | USXGMII_AN_ENABLE;
+		link_timer = FIELD_PREP(USXGMII_LINK_TIMER_IDLE_DETECT, 0x7B) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_COMP_ACK_DETECT, 0x7B) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_AN_RESTART, 0x7B);
+		xfi_mode = FIELD_PREP(USXGMII_XFI_RX_MODE, USXGMII_XFI_MODE_10G) |
+			   FIELD_PREP(USXGMII_XFI_TX_MODE, USXGMII_XFI_MODE_10G);
+	} else if (interface == PHY_INTERFACE_MODE_10GBASER) {
+		an_ctrl = FIELD_PREP(USXGMII_AN_SYNC_CNT, 0x1FF);
+		link_timer = FIELD_PREP(USXGMII_LINK_TIMER_IDLE_DETECT, 0x7B) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_COMP_ACK_DETECT, 0x7B) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_AN_RESTART, 0x7B);
+		xfi_mode = FIELD_PREP(USXGMII_XFI_RX_MODE, USXGMII_XFI_MODE_10G) |
+			   FIELD_PREP(USXGMII_XFI_TX_MODE, USXGMII_XFI_MODE_10G);
+		adapt_mode = USXGMII_RATE_UPDATE_MODE;
+	} else if (interface == PHY_INTERFACE_MODE_5GBASER) {
+		an_ctrl = FIELD_PREP(USXGMII_AN_SYNC_CNT, 0xFF);
+		link_timer = FIELD_PREP(USXGMII_LINK_TIMER_IDLE_DETECT, 0x3D) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_COMP_ACK_DETECT, 0x3D) |
+			     FIELD_PREP(USXGMII_LINK_TIMER_AN_RESTART, 0x3D);
+		xfi_mode = FIELD_PREP(USXGMII_XFI_RX_MODE, USXGMII_XFI_MODE_5G) |
+			   FIELD_PREP(USXGMII_XFI_TX_MODE, USXGMII_XFI_MODE_5G);
+		adapt_mode = USXGMII_RATE_UPDATE_MODE;
+	} else {
+		return -EINVAL;
+	}
+
+	adapt_mode |= FIELD_PREP(USXGMII_RATE_ADAPT_MODE, USXGMII_RATE_ADAPT_MODE_X1);
+
+	if (mpcs->interface != interface) {
+		mpcs->interface = interface;
+		mode_changed = true;
+	}
+
+	mtk_usxgmii_reset(mpcs);
+
+	/* Setup USXGMII AN ctrl */
+	mtk_m32(mpcs, RG_PCS_AN_CTRL0,
+		USXGMII_AN_SYNC_CNT | USXGMII_AN_ENABLE,
+		an_ctrl);
+
+	mtk_m32(mpcs, RG_PCS_AN_CTRL2,
+		USXGMII_LINK_TIMER_IDLE_DETECT |
+		USXGMII_LINK_TIMER_COMP_ACK_DETECT |
+		USXGMII_LINK_TIMER_AN_RESTART,
+		link_timer);
+
+	mpcs->neg_mode = neg_mode;
+
+	/* Gated MAC CK */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
+		USXGMII_MAC_CK_GATED, USXGMII_MAC_CK_GATED);
+
+	/* Enable interface force mode */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
+		USXGMII_IF_FORCE_EN, USXGMII_IF_FORCE_EN);
+
+	/* Setup USXGMII adapt mode */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
+		USXGMII_RATE_UPDATE_MODE | USXGMII_RATE_ADAPT_MODE,
+		adapt_mode);
+
+	/* Setup USXGMII speed */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1,
+		USXGMII_XFI_RX_MODE | USXGMII_XFI_TX_MODE,
+		xfi_mode);
+
+	usleep_range(1, 10);
+
+	/* Un-gated MAC CK */
+	mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1, USXGMII_MAC_CK_GATED, 0);
+
+	usleep_range(1, 10);
+
+	/* Disable interface force mode for the AN mode */
+	if (an_ctrl & USXGMII_AN_ENABLE)
+		mtk_m32(mpcs, RG_PHY_TOP_SPEED_CTRL1, USXGMII_IF_FORCE_EN, 0);
+
+	return mode_changed;
+}
+
+static void mtk_usxgmii_pcs_get_fixed_speed(struct mtk_usxgmii_pcs *mpcs,
+					    struct phylink_link_state *state)
+{
+	u32 val = mtk_r32(mpcs, RG_PHY_TOP_SPEED_CTRL1);
+	int speed;
+
+	/* Calculate speed from interface speed and rate adapt mode */
+	switch (FIELD_GET(USXGMII_XFI_RX_MODE, val)) {
+	case USXGMII_XFI_MODE_10G:
+		speed = 10000;
+		break;
+	case USXGMII_XFI_MODE_5G:
+		speed = 5000;
+		break;
+	case USXGMII_XFI_MODE_2P5G:
+		speed = 2500;
+		break;
+	default:
+		state->speed = SPEED_UNKNOWN;
+		return;
+	}
+
+	switch (FIELD_GET(USXGMII_RATE_ADAPT_MODE, val)) {
+	case USXGMII_RATE_ADAPT_MODE_X100:
+		speed /= 100;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X50:
+		speed /= 50;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X10:
+		speed /= 10;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X5:
+		speed /= 5;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X4:
+		speed /= 4;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X2:
+		speed /= 2;
+		break;
+	case USXGMII_RATE_ADAPT_MODE_X1:
+		break;
+	default:
+		state->speed = SPEED_UNKNOWN;
+		return;
+	}
+
+	state->speed = speed;
+	state->duplex = DUPLEX_FULL;
+}
+
+static void mtk_usxgmii_pcs_get_an_state(struct mtk_usxgmii_pcs *mpcs,
+					 struct phylink_link_state *state)
+{
+	u16 lpa;
+
+	/* Refresh LPA by toggling LPA_LATCH */
+	mtk_m32(mpcs, RG_PCS_AN_STS0, USXGMII_LPA_LATCH, USXGMII_LPA_LATCH);
+	ndelay(1020);
+	mtk_m32(mpcs, RG_PCS_AN_STS0, USXGMII_LPA_LATCH, 0);
+	ndelay(1020);
+	lpa = FIELD_GET(USXGMII_LPA, mtk_r32(mpcs, RG_PCS_AN_STS0));
+
+	phylink_decode_usxgmii_word(state, lpa);
+}
+
+static void mtk_usxgmii_pcs_get_state(struct phylink_pcs *pcs,
+				      struct phylink_link_state *state)
+{
+	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
+
+	/* Refresh USXGMII link status by toggling RG_PCS_AN_STATUS_UPDATE */
+	mtk_m32(mpcs, RG_PCS_RX_STATUS0, RG_PCS_RX_STATUS_UPDATE,
+		RG_PCS_RX_STATUS_UPDATE);
+	ndelay(1020);
+	mtk_m32(mpcs, RG_PCS_RX_STATUS0, RG_PCS_RX_STATUS_UPDATE, 0);
+	ndelay(1020);
+
+	/* Read USXGMII link status */
+	state->link = FIELD_GET(RG_PCS_RX_LINK_STATUS,
+				mtk_r32(mpcs, RG_PCS_RX_STATUS0));
+
+	/* Continuously repeat re-configuration sequence until link comes up */
+	if (!state->link) {
+		mtk_usxgmii_pcs_config(pcs, mpcs->neg_mode,
+				       state->interface, NULL, false);
+		return;
+	}
+
+	if (FIELD_GET(USXGMII_AN_ENABLE, mtk_r32(mpcs, RG_PCS_AN_CTRL0)))
+		mtk_usxgmii_pcs_get_an_state(mpcs, state);
+	else
+		mtk_usxgmii_pcs_get_fixed_speed(mpcs, state);
+}
+
+static void mtk_usxgmii_pcs_restart_an(struct phylink_pcs *pcs)
+{
+	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
+
+	mtk_m32(mpcs, RG_PCS_AN_CTRL0, USXGMII_AN_RESTART, USXGMII_AN_RESTART);
+}
+
+static void mtk_usxgmii_pcs_link_up(struct phylink_pcs *pcs, unsigned int neg_mode,
+				    phy_interface_t interface,
+				    int speed, int duplex)
+{
+	/* Reconfiguring USXGMII to ensure the quality of the RX signal
+	 * after the line side link up.
+	 */
+	mtk_usxgmii_pcs_config(pcs, neg_mode, interface, NULL, false);
+}
+
+static void mtk_usxgmii_pcs_disable(struct phylink_pcs *pcs)
+{
+	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
+
+	mpcs->interface = PHY_INTERFACE_MODE_NA;
+	mpcs->neg_mode = -1;
+}
+
+static const struct phylink_pcs_ops mtk_usxgmii_pcs_ops = {
+	.pcs_config = mtk_usxgmii_pcs_config,
+	.pcs_get_state = mtk_usxgmii_pcs_get_state,
+	.pcs_an_restart = mtk_usxgmii_pcs_restart_an,
+	.pcs_link_up = mtk_usxgmii_pcs_link_up,
+	.pcs_disable = mtk_usxgmii_pcs_disable,
+};
+
+static int mtk_usxgmii_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_usxgmii_pcs *mpcs;
+
+	mpcs = devm_kzalloc(dev, sizeof(*mpcs), GFP_KERNEL);
+	if (!mpcs)
+		return -ENOMEM;
+
+	mpcs->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(mpcs->base))
+		return PTR_ERR(mpcs->base);
+
+	mpcs->dev = dev;
+	mpcs->pcs.ops = &mtk_usxgmii_pcs_ops;
+	mpcs->pcs.poll = true;
+	mpcs->pcs.neg_mode = true;
+	mpcs->interface = PHY_INTERFACE_MODE_NA;
+	mpcs->neg_mode = -1;
+
+	mpcs->clk = devm_clk_get_enabled(mpcs->dev, NULL);
+	if (IS_ERR(mpcs->clk))
+		return PTR_ERR(mpcs->clk);
+
+	mpcs->reset = devm_reset_control_get_shared(dev, NULL);
+	if (IS_ERR(mpcs->reset))
+		return PTR_ERR(mpcs->reset);
+
+	reset_control_deassert(mpcs->reset);
+
+	platform_set_drvdata(pdev, mpcs);
+
+	mutex_lock(&instance_mutex);
+	list_add_tail(&mpcs->node, &mtk_usxgmii_pcs_instances);
+	mutex_unlock(&instance_mutex);
+
+	return 0;
+}
+
+static int mtk_usxgmii_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_usxgmii_pcs *cur, *tmp;
+
+	mutex_lock(&instance_mutex);
+	list_for_each_entry_safe(cur, tmp, &mtk_usxgmii_pcs_instances, node)
+		if (cur->dev == dev) {
+			list_del(&cur->node);
+			break;
+		}
+	mutex_unlock(&instance_mutex);
+
+	return 0;
+}
+
+static const struct of_device_id mtk_usxgmii_of_mtable[] = {
+	{ .compatible = "mediatek,mt7988-usxgmiisys" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mtk_usxgmii_of_mtable);
+
+struct phylink_pcs *mtk_usxgmii_pcs_get(struct device *dev, struct device_node *np)
+{
+	struct platform_device *pdev;
+	struct mtk_usxgmii_pcs *mpcs;
+
+	if (!np)
+		return NULL;
+
+	if (!of_device_is_available(np))
+		return ERR_PTR(-ENODEV);
+
+	if (!of_match_node(mtk_usxgmii_of_mtable, np))
+		return ERR_PTR(-EINVAL);
+
+	pdev = of_find_device_by_node(np);
+	if (!pdev || !platform_get_drvdata(pdev)) {
+		if (pdev)
+			put_device(&pdev->dev);
+		return ERR_PTR(-EPROBE_DEFER);
+	}
+
+	mpcs = platform_get_drvdata(pdev);
+	device_link_add(dev, mpcs->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
+
+	return &mpcs->pcs;
+}
+EXPORT_SYMBOL(mtk_usxgmii_pcs_get);
+
+void mtk_usxgmii_pcs_put(struct phylink_pcs *pcs)
+{
+	struct mtk_usxgmii_pcs *cur, *mpcs = NULL;
+
+	if (!pcs)
+		return;
+
+	mutex_lock(&instance_mutex);
+	list_for_each_entry(cur, &mtk_usxgmii_pcs_instances, node)
+		if (pcs == &cur->pcs) {
+			mpcs = cur;
+			break;
+		}
+	mutex_unlock(&instance_mutex);
+
+	if (WARN_ON(!mpcs))
+		return;
+
+	put_device(mpcs->dev);
+}
+EXPORT_SYMBOL(mtk_usxgmii_pcs_put);
+
+static struct platform_driver mtk_usxgmii_driver = {
+	.driver = {
+		.name			= "mtk_usxgmii",
+		.suppress_bind_attrs	= true,
+		.of_match_table		= mtk_usxgmii_of_mtable,
+	},
+	.probe = mtk_usxgmii_probe,
+	.remove = mtk_usxgmii_remove,
+};
+module_platform_driver(mtk_usxgmii_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek USXGMII PCS driver");
+MODULE_AUTHOR("Daniel Golle <daniel at makrotopia.org>");
diff --git a/include/linux/pcs/pcs-mtk-usxgmii.h b/include/linux/pcs/pcs-mtk-usxgmii.h
new file mode 100644
index 0000000000000..ef936d9c5f116
--- /dev/null
+++ b/include/linux/pcs/pcs-mtk-usxgmii.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_PCS_MTK_USXGMII_H
+#define __LINUX_PCS_MTK_USXGMII_H
+
+#include <linux/phylink.h>
+
+/**
+ * mtk_usxgmii_select_pcs() - Get MediaTek PCS instance
+ * @np:		Pointer to device node indentifying a MediaTek USXGMII PCS
+ * @mode:	Ethernet PHY interface mode
+ *
+ * Return PCS identified by a device node and the PHY interface mode in use
+ *
+ * Return:	Pointer to phylink PCS instance of NULL
+ */
+#if IS_ENABLED(CONFIG_PCS_MTK_USXGMII)
+struct phylink_pcs *mtk_usxgmii_pcs_get(struct device *dev, struct device_node *np);
+void mtk_usxgmii_pcs_put(struct phylink_pcs *pcs);
+#else
+static inline struct phylink_pcs *mtk_usxgmii_pcs_get(struct device *dev, struct device_node *np)
+{
+	return NULL;
+}
+static inline void mtk_usxgmii_pcs_put(struct phylink_pcs *pcs) { }
+#endif /* IS_ENABLED(CONFIG_PCS_MTK_USXGMII) */
+
+#endif /* __LINUX_PCS_MTK_USXGMII_H */
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:48:10 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:48:10 +0000
Subject: [RFC PATCH net-next v3 6/8] dt-bindings: net: mediatek: remove
 wrongly added clocks and SerDes
In-Reply-To: <cover.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
Message-ID: <5859da6629b8b6c100eca4062dd193105bf829ba.1702352117.git.daniel@makrotopia.org>

Several clocks as well as both sgmiisys phandles were added by mistake
to the Ethernet bindings for MT7988.

This happened because the vendor driver which served as a reference
uses a high number of syscon phandles to access various parts of the
SoC which wasn't acceptable upstream. Hence several parts which have
never previously been supported (such SerDes PHY and USXGMII PCS) have
been moved to separate drivers which also result in a much more sane
device tree.

Quickly align the bindings with the upcoming reality of the drivers
actually adding full support for this SoC.

Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 .../devicetree/bindings/net/mediatek,net.yaml | 32 ++++---------------
 1 file changed, 7 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
index e74502a0afe86..030d106bc7d3f 100644
--- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
@@ -337,32 +337,23 @@ allOf:
           minItems: 4
 
         clocks:
-          minItems: 34
-          maxItems: 34
+          minItems: 24
+          maxItems: 24
 
         clock-names:
           items:
-            - const: crypto
+            - const: xgp1
+            - const: xgp2
+            - const: xgp3
             - const: fe
             - const: gp2
             - const: gp1
             - const: gp3
+            - const: esw
+            - const: crypto
             - const: ethwarp_wocpu2
             - const: ethwarp_wocpu1
             - const: ethwarp_wocpu0
-            - const: esw
-            - const: netsys0
-            - const: netsys1
-            - const: sgmii_tx250m
-            - const: sgmii_rx250m
-            - const: sgmii2_tx250m
-            - const: sgmii2_rx250m
-            - const: top_usxgmii0_sel
-            - const: top_usxgmii1_sel
-            - const: top_sgm0_sel
-            - const: top_sgm1_sel
-            - const: top_xfi_phy0_xtal_sel
-            - const: top_xfi_phy1_xtal_sel
             - const: top_eth_gmii_sel
             - const: top_eth_refck_50m_sel
             - const: top_eth_sys_200m_sel
@@ -375,15 +366,6 @@ allOf:
             - const: top_netsys_sync_250m_sel
             - const: top_netsys_ppefb_250m_sel
             - const: top_netsys_warp_sel
-            - const: wocpu1
-            - const: wocpu0
-            - const: xgp1
-            - const: xgp2
-            - const: xgp3
-
-        mediatek,sgmiisys:
-          minItems: 2
-          maxItems: 2
 
 patternProperties:
   "^mac@[0-1]$":
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:51:01 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:51:01 +0000
Subject: [RFC PATCH net-next v3 7/8] dt-bindings: net: mediatek,net: fix and
 complete mt7988-eth binding
In-Reply-To: <cover.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
Message-ID: <ac6a7277fc534f610386bc51b2ff87beade03be8.1702352117.git.daniel@makrotopia.org>

Complete support for MT7988 which comes with 3 MACs, SRAM for DMA
descriptors and uses a dedicated PCS for the SerDes units.

Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 .../devicetree/bindings/net/mediatek,net.yaml | 148 +++++++++++++++++-
 1 file changed, 146 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
index 030d106bc7d3f..ca0667c51c1c2 100644
--- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
@@ -28,7 +28,10 @@ properties:
       - ralink,rt5350-eth
 
   reg:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: Base of registers used to program the ethernet controller
+      - description: SRAM region used for DMA descriptors
 
   clocks: true
   clock-names: true
@@ -115,6 +118,9 @@ allOf:
               - mediatek,mt7623-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           maxItems: 3
 
@@ -149,6 +155,9 @@ allOf:
               - mediatek,mt7621-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           maxItems: 1
 
@@ -174,6 +183,9 @@ allOf:
             const: mediatek,mt7622-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           maxItems: 3
 
@@ -215,6 +227,9 @@ allOf:
             const: mediatek,mt7629-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           maxItems: 3
 
@@ -257,6 +272,9 @@ allOf:
             const: mediatek,mt7981-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           minItems: 4
 
@@ -295,6 +313,9 @@ allOf:
             const: mediatek,mt7986-eth
     then:
       properties:
+        reg:
+          maxItems: 1
+
         interrupts:
           minItems: 4
 
@@ -333,8 +354,12 @@ allOf:
             const: mediatek,mt7988-eth
     then:
       properties:
+        reg:
+          minItems: 2
+
         interrupts:
           minItems: 4
+          maxItems: 4
 
         clocks:
           minItems: 24
@@ -368,7 +393,7 @@ allOf:
             - const: top_netsys_warp_sel
 
 patternProperties:
-  "^mac@[0-1]$":
+  "^mac@[0-2]$":
     type: object
     unevaluatedProperties: false
     allOf:
@@ -382,6 +407,9 @@ patternProperties:
       reg:
         maxItems: 1
 
+      phys:
+        maxItems: 1
+
     required:
       - reg
       - compatible
@@ -559,3 +587,118 @@ examples:
         };
       };
     };
+
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+    soc {
+      #address-cells = <2>;
+      #size-cells = <2>;
+
+      ethernet at 15100000 {
+        compatible = "mediatek,mt7988-eth";
+        reg = <0 0x15100000 0 0x80000>, <0 0x15400000 0 0x380000>;
+        interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
+
+        clocks = <&ethsys CLK_ETHDMA_XGP1_EN>,
+                 <&ethsys CLK_ETHDMA_XGP2_EN>,
+                 <&ethsys CLK_ETHDMA_XGP3_EN>,
+                 <&ethsys CLK_ETHDMA_FE_EN>,
+                 <&ethsys CLK_ETHDMA_GP2_EN>,
+                 <&ethsys CLK_ETHDMA_GP1_EN>,
+                 <&ethsys CLK_ETHDMA_GP3_EN>,
+                 <&ethsys CLK_ETHDMA_ESW_EN>,
+                 <&ethsys CLK_ETHDMA_CRYPT0_EN>,
+                 <&ethwarp CLK_ETHWARP_WOCPU2_EN>,
+                 <&ethwarp CLK_ETHWARP_WOCPU1_EN>,
+                 <&ethwarp CLK_ETHWARP_WOCPU0_EN>,
+                 <&topckgen CLK_TOP_ETH_GMII_SEL>,
+                 <&topckgen CLK_TOP_ETH_REFCK_50M_SEL>,
+                 <&topckgen CLK_TOP_ETH_SYS_200M_SEL>,
+                 <&topckgen CLK_TOP_ETH_SYS_SEL>,
+                 <&topckgen CLK_TOP_ETH_XGMII_SEL>,
+                 <&topckgen CLK_TOP_ETH_MII_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_500M_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_PAO_2X_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_SYNC_250M_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_PPEFB_250M_SEL>,
+                 <&topckgen CLK_TOP_NETSYS_WARP_SEL>;
+
+        clock-names = "xgp1", "xgp2", "xgp3", "fe", "gp2", "gp1",
+                      "gp3", "esw", "crypto",
+                      "ethwarp_wocpu2", "ethwarp_wocpu1",
+                      "ethwarp_wocpu0", "top_eth_gmii_sel",
+                      "top_eth_refck_50m_sel", "top_eth_sys_200m_sel",
+                      "top_eth_sys_sel", "top_eth_xgmii_sel",
+                      "top_eth_mii_sel", "top_netsys_sel",
+                      "top_netsys_500m_sel", "top_netsys_pao_2x_sel",
+                      "top_netsys_sync_250m_sel",
+                      "top_netsys_ppefb_250m_sel",
+                      "top_netsys_warp_sel";
+        assigned-clocks = <&topckgen CLK_TOP_NETSYS_2X_SEL>,
+                          <&topckgen CLK_TOP_NETSYS_GSW_SEL>,
+                          <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>,
+                          <&topckgen CLK_TOP_USXGMII_SBUS_1_SEL>,
+                          <&topckgen CLK_TOP_SGM_0_SEL>,
+                          <&topckgen CLK_TOP_SGM_1_SEL>;
+        assigned-clock-parents = <&apmixedsys CLK_APMIXED_NET2PLL>,
+                                 <&topckgen CLK_TOP_NET1PLL_D4>,
+                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
+                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
+                                 <&apmixedsys CLK_APMIXED_SGMPLL>,
+                                 <&apmixedsys CLK_APMIXED_SGMPLL>;
+        mediatek,ethsys = <&ethsys>;
+        mediatek,infracfg = <&topmisc>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        mac at 0 {
+          compatible = "mediatek,eth-mac";
+          reg = <0>;
+          phy-mode = "internal"; /* CPU port of built-in 1GE switch */
+
+          fixed-link {
+            speed = <10000>;
+            full-duplex;
+            pause;
+          };
+        };
+
+        mac at 1 {
+          compatible = "mediatek,eth-mac";
+          reg = <1>;
+          phy-handle = <&int_2p5g_phy>;
+        };
+
+        mac at 2 {
+          compatible = "mediatek,eth-mac";
+          reg = <2>;
+          pcs-handle = <&usxgmiisys0>, <&sgmii0>;
+          phys = <&pextp0>;
+        };
+
+        mdio_bus: mdio-bus {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          /* external PHY */
+          phy0: ethernet-phy at 0 {
+            reg = <0>;
+            compatible = "ethernet-phy-ieee802.3-c45";
+          };
+
+          /* internal 2.5G PHY */
+          int_2p5g_phy: ethernet-phy at 15 {
+            reg = <15>;
+            compatible = "ethernet-phy-ieee802.3-c45";
+            phy-mode = "internal";
+          };
+        };
+      };
+    };
-- 
2.43.0


From daniel at makrotopia.org  Mon Dec 11 19:51:14 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 03:51:14 +0000
Subject: [RFC PATCH net-next v3 8/8] net: ethernet: mtk_eth_soc: add paths
 and SerDes modes for MT7988
In-Reply-To: <cover.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
Message-ID: <f8a62fcccacfd1f94d4ef84a104095d352bf252c.1702352117.git.daniel@makrotopia.org>

MT7988 comes with a built-in 2.5G PHY as well as SerDes lanes to
connect external PHYs or transceivers in USXGMII, 10GBase-R, 5GBase-R,
2500Base-X, 1000Base-X and Cisco SGMII interface modes.

Implement support for configuring for the new paths to SerDes interfaces
and the internal 2.5G PHY.

Add USXGMII PCS driver for 10GBase-R, 5GBase-R and USXGMII mode, and
setup the new PHYA on MT7988 to access the also still existing old
LynxI PCS for 1000Base-X, 2500Base-X and Cisco SGMII PCS interface
modes.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
---
 drivers/net/ethernet/mediatek/mtk_eth_path.c | 122 +++++++-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c  | 291 +++++++++++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h  | 107 ++++++-
 3 files changed, 469 insertions(+), 51 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_path.c b/drivers/net/ethernet/mediatek/mtk_eth_path.c
index 7c27a19c4d8f4..3f4f4cfe6a233 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_path.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_path.c
@@ -31,10 +31,20 @@ static const char *mtk_eth_path_name(u64 path)
 		return "gmac2_rgmii";
 	case MTK_ETH_PATH_GMAC2_SGMII:
 		return "gmac2_sgmii";
+	case MTK_ETH_PATH_GMAC2_2P5GPHY:
+		return "gmac2_2p5gphy";
 	case MTK_ETH_PATH_GMAC2_GEPHY:
 		return "gmac2_gephy";
+	case MTK_ETH_PATH_GMAC3_SGMII:
+		return "gmac3_sgmii";
 	case MTK_ETH_PATH_GDM1_ESW:
 		return "gdm1_esw";
+	case MTK_ETH_PATH_GMAC1_USXGMII:
+		return "gmac1_usxgmii";
+	case MTK_ETH_PATH_GMAC2_USXGMII:
+		return "gmac2_usxgmii";
+	case MTK_ETH_PATH_GMAC3_USXGMII:
+		return "gmac3_usxgmii";
 	default:
 		return "unknown path";
 	}
@@ -127,6 +137,27 @@ static int set_mux_u3_gmac2_to_qphy(struct mtk_eth *eth, u64 path)
 	return 0;
 }
 
+static int set_mux_gmac2_to_2p5gphy(struct mtk_eth *eth, u64 path)
+{
+	int ret;
+
+	if (path == MTK_ETH_PATH_GMAC2_2P5GPHY) {
+		ret = regmap_clear_bits(eth->ethsys, ETHSYS_SYSCFG0, SYSCFG0_SGMII_GMAC2_V2);
+		if (ret)
+			return ret;
+
+		/* Setup mux to 2p5g PHY */
+		ret = regmap_clear_bits(eth->infra, TOP_MISC_NETSYS_PCS_MUX, MUX_G2_USXGMII_SEL);
+		if (ret)
+			return ret;
+
+		dev_dbg(eth->dev, "path %s in %s updated\n",
+			mtk_eth_path_name(path), __func__);
+	}
+
+	return 0;
+}
+
 static int set_mux_gmac1_gmac2_to_sgmii_rgmii(struct mtk_eth *eth, u64 path)
 {
 	unsigned int val = 0;
@@ -165,7 +196,48 @@ static int set_mux_gmac1_gmac2_to_sgmii_rgmii(struct mtk_eth *eth, u64 path)
 	return 0;
 }
 
-static int set_mux_gmac12_to_gephy_sgmii(struct mtk_eth *eth, u64 path)
+static int set_mux_gmac123_to_usxgmii(struct mtk_eth *eth, u64 path)
+{
+	unsigned int val = 0;
+	bool updated = true;
+	int mac_id = 0;
+
+	/* Disable SYSCFG1 SGMII */
+	regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
+
+	switch (path) {
+	case MTK_ETH_PATH_GMAC1_USXGMII:
+		val &= ~(u32)SYSCFG0_SGMII_GMAC1_V2;
+		mac_id = MTK_GMAC1_ID;
+		break;
+	case MTK_ETH_PATH_GMAC2_USXGMII:
+		val &= ~(u32)SYSCFG0_SGMII_GMAC2_V2;
+		mac_id = MTK_GMAC2_ID;
+		break;
+	case MTK_ETH_PATH_GMAC3_USXGMII:
+		val &= ~(u32)SYSCFG0_SGMII_GMAC3_V2;
+		mac_id = MTK_GMAC3_ID;
+		break;
+	default:
+		updated = false;
+	};
+
+	if (updated) {
+		regmap_update_bits(eth->ethsys, ETHSYS_SYSCFG0,
+				   SYSCFG0_SGMII_MASK, val);
+
+		if (mac_id == MTK_GMAC2_ID)
+			regmap_set_bits(eth->infra, TOP_MISC_NETSYS_PCS_MUX,
+					MUX_G2_USXGMII_SEL);
+	}
+
+	dev_dbg(eth->dev, "path %s in %s updated = %d\n",
+		mtk_eth_path_name(path), __func__, updated);
+
+	return 0;
+}
+
+static int set_mux_gmac123_to_gephy_sgmii(struct mtk_eth *eth, u64 path)
 {
 	unsigned int val = 0;
 	bool updated = true;
@@ -182,6 +254,9 @@ static int set_mux_gmac12_to_gephy_sgmii(struct mtk_eth *eth, u64 path)
 	case MTK_ETH_PATH_GMAC2_SGMII:
 		val |= SYSCFG0_SGMII_GMAC2_V2;
 		break;
+	case MTK_ETH_PATH_GMAC3_SGMII:
+		val |= SYSCFG0_SGMII_GMAC3_V2;
+		break;
 	default:
 		updated = false;
 	}
@@ -209,6 +284,10 @@ static const struct mtk_eth_muxc mtk_eth_muxc[] = {
 		.name = "mux_u3_gmac2_to_qphy",
 		.cap_bit = MTK_ETH_MUX_U3_GMAC2_TO_QPHY,
 		.set_path = set_mux_u3_gmac2_to_qphy,
+	}, {
+		.name = "mux_gmac2_to_2p5gphy",
+		.cap_bit = MTK_ETH_MUX_GMAC2_TO_2P5GPHY,
+		.set_path = set_mux_gmac2_to_2p5gphy,
 	}, {
 		.name = "mux_gmac1_gmac2_to_sgmii_rgmii",
 		.cap_bit = MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII,
@@ -216,7 +295,15 @@ static const struct mtk_eth_muxc mtk_eth_muxc[] = {
 	}, {
 		.name = "mux_gmac12_to_gephy_sgmii",
 		.cap_bit = MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII,
-		.set_path = set_mux_gmac12_to_gephy_sgmii,
+		.set_path = set_mux_gmac123_to_gephy_sgmii,
+	}, {
+		.name = "mux_gmac123_to_gephy_sgmii",
+		.cap_bit = MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII,
+		.set_path = set_mux_gmac123_to_gephy_sgmii,
+	}, {
+		.name = "mux_gmac123_to_usxgmii",
+		.cap_bit = MTK_ETH_MUX_GMAC123_TO_USXGMII,
+		.set_path = set_mux_gmac123_to_usxgmii,
 	},
 };
 
@@ -249,12 +336,39 @@ static int mtk_eth_mux_setup(struct mtk_eth *eth, u64 path)
 	return err;
 }
 
+int mtk_gmac_usxgmii_path_setup(struct mtk_eth *eth, int mac_id)
+{
+	u64 path;
+
+	path = (mac_id == MTK_GMAC1_ID) ?  MTK_ETH_PATH_GMAC1_USXGMII :
+	       (mac_id == MTK_GMAC2_ID) ?  MTK_ETH_PATH_GMAC2_USXGMII :
+					   MTK_ETH_PATH_GMAC3_USXGMII;
+
+	/* Setup proper MUXes along the path */
+	return mtk_eth_mux_setup(eth, path);
+}
+
 int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id)
 {
 	u64 path;
 
-	path = (mac_id == 0) ?  MTK_ETH_PATH_GMAC1_SGMII :
-				MTK_ETH_PATH_GMAC2_SGMII;
+	path = (mac_id == MTK_GMAC1_ID) ? MTK_ETH_PATH_GMAC1_SGMII :
+	       (mac_id == MTK_GMAC2_ID) ? MTK_ETH_PATH_GMAC2_SGMII :
+					  MTK_ETH_PATH_GMAC3_SGMII;
+
+	/* Setup proper MUXes along the path */
+	return mtk_eth_mux_setup(eth, path);
+}
+
+int mtk_gmac_2p5gphy_path_setup(struct mtk_eth *eth, int mac_id)
+{
+	u64 path = 0;
+
+	if (mac_id == MTK_GMAC2_ID)
+		path = MTK_ETH_PATH_GMAC2_2P5GPHY;
+
+	if (!path)
+		return -EINVAL;
 
 	/* Setup proper MUXes along the path */
 	return mtk_eth_mux_setup(eth, path);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index a6e91573f8dae..da0ec44268c8e 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -22,6 +22,8 @@
 #include <linux/pinctrl/devinfo.h>
 #include <linux/phylink.h>
 #include <linux/pcs/pcs-mtk-lynxi.h>
+#include <linux/pcs/pcs-mtk-usxgmii.h>
+#include <linux/phy/phy.h>
 #include <linux/jhash.h>
 #include <linux/bitfield.h>
 #include <net/dsa.h>
@@ -260,12 +262,8 @@ static const char * const mtk_clks_source_name[] = {
 	"ethwarp_wocpu2",
 	"ethwarp_wocpu1",
 	"ethwarp_wocpu0",
-	"top_usxgmii0_sel",
-	"top_usxgmii1_sel",
 	"top_sgm0_sel",
 	"top_sgm1_sel",
-	"top_xfi_phy0_xtal_sel",
-	"top_xfi_phy1_xtal_sel",
 	"top_eth_gmii_sel",
 	"top_eth_refck_50m_sel",
 	"top_eth_sys_200m_sel",
@@ -508,6 +506,30 @@ static void mtk_setup_bridge_switch(struct mtk_eth *eth)
 		MTK_GSW_CFG);
 }
 
+static bool mtk_check_gmac23_idle(struct mtk_mac *mac)
+{
+	u32 mac_fsm, gdm_fsm;
+
+	mac_fsm = mtk_r32(mac->hw, MTK_MAC_FSM(mac->id));
+
+	switch (mac->id) {
+	case MTK_GMAC2_ID:
+		gdm_fsm = mtk_r32(mac->hw, MTK_FE_GDM2_FSM);
+		break;
+	case MTK_GMAC3_ID:
+		gdm_fsm = mtk_r32(mac->hw, MTK_FE_GDM3_FSM);
+		break;
+	default:
+		return true;
+	};
+
+	if ((mac_fsm & 0xFFFF0000) == 0x01010000 &&
+	    (gdm_fsm & 0xFFFF0000) == 0x00000000)
+		return true;
+
+	return false;
+}
+
 static struct phylink_pcs *mtk_mac_select_pcs(struct phylink_config *config,
 					      phy_interface_t interface)
 {
@@ -516,6 +538,21 @@ static struct phylink_pcs *mtk_mac_select_pcs(struct phylink_config *config,
 	struct mtk_eth *eth = mac->hw;
 	unsigned int sid;
 
+	if (mtk_is_netsys_v3_or_greater(eth)) {
+		switch (interface) {
+		case PHY_INTERFACE_MODE_1000BASEX:
+		case PHY_INTERFACE_MODE_2500BASEX:
+		case PHY_INTERFACE_MODE_SGMII:
+			return mac->sgmii_pcs;
+		case PHY_INTERFACE_MODE_5GBASER:
+		case PHY_INTERFACE_MODE_10GBASER:
+		case PHY_INTERFACE_MODE_USXGMII:
+			return mac->usxgmii_pcs;
+		default:
+			return NULL;
+		}
+	}
+
 	if (interface == PHY_INTERFACE_MODE_SGMII ||
 	    phy_interface_mode_is_8023z(interface)) {
 		sid = (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_SGMII)) ?
@@ -567,7 +604,22 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
 					goto init_err;
 			}
 			break;
+		case PHY_INTERFACE_MODE_USXGMII:
+		case PHY_INTERFACE_MODE_10GBASER:
+		case PHY_INTERFACE_MODE_5GBASER:
+			if (MTK_HAS_CAPS(eth->soc->caps, MTK_USXGMII)) {
+				err = mtk_gmac_usxgmii_path_setup(eth, mac->id);
+				if (err)
+					goto init_err;
+			}
+			break;
 		case PHY_INTERFACE_MODE_INTERNAL:
+			if (mac->id == MTK_GMAC2_ID &&
+			    MTK_HAS_CAPS(eth->soc->caps, MTK_2P5GPHY)) {
+				err = mtk_gmac_2p5gphy_path_setup(eth, mac->id);
+				if (err)
+					goto init_err;
+			}
 			break;
 		default:
 			goto err_phy;
@@ -614,8 +666,6 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
 		val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
 		val |= SYSCFG0_GE_MODE(ge_mode, mac->id);
 		regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
-
-		mac->interface = state->interface;
 	}
 
 	/* SGMII */
@@ -632,21 +682,40 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
 
 		/* Save the syscfg0 value for mac_finish */
 		mac->syscfg0 = val;
-	} else if (phylink_autoneg_inband(mode)) {
+	} else if (state->interface != PHY_INTERFACE_MODE_USXGMII &&
+		   state->interface != PHY_INTERFACE_MODE_10GBASER &&
+		   state->interface != PHY_INTERFACE_MODE_5GBASER &&
+		   phylink_autoneg_inband(mode)) {
 		dev_err(eth->dev,
-			"In-band mode not supported in non SGMII mode!\n");
+			"In-band mode not supported in non-SerDes modes!\n");
 		return;
 	}
 
 	/* Setup gmac */
-	if (mtk_is_netsys_v3_or_greater(eth) &&
-	    mac->interface == PHY_INTERFACE_MODE_INTERNAL) {
-		mtk_w32(mac->hw, MTK_GDMA_XGDM_SEL, MTK_GDMA_EG_CTRL(mac->id));
-		mtk_w32(mac->hw, MAC_MCR_FORCE_LINK_DOWN, MTK_MAC_MCR(mac->id));
+	if (mtk_is_netsys_v3_or_greater(eth)) {
+		if (mtk_interface_mode_is_xgmii(state->interface)) {
+			mtk_w32(mac->hw, MTK_GDMA_XGDM_SEL, MTK_GDMA_EG_CTRL(mac->id));
+			mtk_w32(mac->hw, MAC_MCR_FORCE_LINK_DOWN, MTK_MAC_MCR(mac->id));
 
-		mtk_setup_bridge_switch(eth);
+			if (mac->id == MTK_GMAC1_ID)
+				mtk_setup_bridge_switch(eth);
+		} else {
+			mtk_w32(eth, 0, MTK_GDMA_EG_CTRL(mac->id));
+
+			/* FIXME: In current hardware design, we have to reset FE
+			 * when swtiching XGDM to GDM. Therefore, here trigger an SER
+			 * to let GDM go back to the initial state.
+			 */
+			if ((mtk_interface_mode_is_xgmii(mac->interface) ||
+			     mac->interface == PHY_INTERFACE_MODE_NA) &&
+			    !mtk_check_gmac23_idle(mac) &&
+			    !test_bit(MTK_RESETTING, &eth->state))
+				schedule_work(&eth->pending_work);
+		}
 	}
 
+	mac->interface = state->interface;
+
 	return;
 
 err_phy:
@@ -659,6 +728,18 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
 		mac->id, phy_modes(state->interface), err);
 }
 
+static int mtk_mac_prepare(struct phylink_config *config, unsigned int mode,
+			   phy_interface_t interface)
+{
+	struct mtk_mac *mac = container_of(config, struct mtk_mac,
+					   phylink_config);
+
+	if (mac->pextp && mac->interface != interface)
+		phy_reset(mac->pextp);
+
+	return 0;
+}
+
 static int mtk_mac_finish(struct phylink_config *config, unsigned int mode,
 			  phy_interface_t interface)
 {
@@ -667,6 +748,10 @@ static int mtk_mac_finish(struct phylink_config *config, unsigned int mode,
 	struct mtk_eth *eth = mac->hw;
 	u32 mcr_cur, mcr_new;
 
+	/* Setup PMA/PMD */
+	if (mac->pextp)
+		phy_set_mode_ext(mac->pextp, PHY_MODE_ETHERNET, interface);
+
 	/* Enable SGMII */
 	if (interface == PHY_INTERFACE_MODE_SGMII ||
 	    phy_interface_mode_is_8023z(interface))
@@ -692,10 +777,13 @@ static void mtk_mac_link_down(struct phylink_config *config, unsigned int mode,
 {
 	struct mtk_mac *mac = container_of(config, struct mtk_mac,
 					   phylink_config);
-	u32 mcr = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
 
-	mcr &= ~(MAC_MCR_TX_EN | MAC_MCR_RX_EN);
-	mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
+	if (!mtk_interface_mode_is_xgmii(interface)) {
+		mtk_m32(mac->hw, MAC_MCR_TX_EN | MAC_MCR_RX_EN, 0, MTK_MAC_MCR(mac->id));
+		mtk_m32(mac->hw, MTK_XGMAC_FORCE_LINK(mac->id), 0, MTK_XGMAC_STS(mac->id));
+	} else if (mac->id != MTK_GMAC1_ID) {
+		mtk_m32(mac->hw, XMAC_MCR_TRX_DISABLE, XMAC_MCR_TRX_DISABLE, MTK_XMAC_MCR(mac->id));
+	}
 }
 
 static void mtk_set_queue_speed(struct mtk_eth *eth, unsigned int idx,
@@ -767,13 +855,11 @@ static void mtk_set_queue_speed(struct mtk_eth *eth, unsigned int idx,
 	mtk_w32(eth, val, soc->reg_map->qdma.qtx_sch + ofs);
 }
 
-static void mtk_mac_link_up(struct phylink_config *config,
-			    struct phy_device *phy,
-			    unsigned int mode, phy_interface_t interface,
-			    int speed, int duplex, bool tx_pause, bool rx_pause)
+static void mtk_gdm_mac_link_up(struct mtk_mac *mac,
+				struct phy_device *phy,
+				unsigned int mode, phy_interface_t interface,
+				int speed, int duplex, bool tx_pause, bool rx_pause)
 {
-	struct mtk_mac *mac = container_of(config, struct mtk_mac,
-					   phylink_config);
 	u32 mcr;
 
 	mcr = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
@@ -807,9 +893,63 @@ static void mtk_mac_link_up(struct phylink_config *config,
 	mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
 }
 
+static void mtk_xgdm_mac_link_up(struct mtk_mac *mac,
+				 struct phy_device *phy,
+				 unsigned int mode, phy_interface_t interface,
+				 int speed, int duplex, bool tx_pause, bool rx_pause)
+{
+	u32 mcr, force_link = 0;
+
+	if (mac->id == MTK_GMAC1_ID)
+		return;
+
+	/* Eliminate the interference(before link-up) caused by PHY noise */
+	mtk_m32(mac->hw, XMAC_LOGIC_RST, 0, MTK_XMAC_LOGIC_RST(mac->id));
+	mdelay(20);
+	mtk_m32(mac->hw, XMAC_GLB_CNTCLR, XMAC_GLB_CNTCLR, MTK_XMAC_CNT_CTRL(mac->id));
+
+	if (mac->interface == PHY_INTERFACE_MODE_INTERNAL || mac->id == MTK_GMAC3_ID)
+		force_link = MTK_XGMAC_FORCE_LINK(mac->id);
+
+	mtk_m32(mac->hw, MTK_XGMAC_FORCE_LINK(mac->id), force_link, MTK_XGMAC_STS(mac->id));
+
+	mcr = mtk_r32(mac->hw, MTK_XMAC_MCR(mac->id));
+	mcr &= ~(XMAC_MCR_FORCE_TX_FC | XMAC_MCR_FORCE_RX_FC | XMAC_MCR_TRX_DISABLE);
+	/* Configure pause modes -
+	 * phylink will avoid these for half duplex
+	 */
+	if (tx_pause)
+		mcr |= XMAC_MCR_FORCE_TX_FC;
+	if (rx_pause)
+		mcr |= XMAC_MCR_FORCE_RX_FC;
+
+	mtk_w32(mac->hw, mcr, MTK_XMAC_MCR(mac->id));
+}
+
+static void mtk_mac_link_up(struct phylink_config *config,
+			    struct phy_device *phy,
+			    unsigned int mode, phy_interface_t interface,
+			    int speed, int duplex, bool tx_pause, bool rx_pause)
+{
+	struct mtk_mac *mac = container_of(config, struct mtk_mac,
+					   phylink_config);
+
+	if (mtk_interface_mode_is_xgmii(interface))
+		mtk_xgdm_mac_link_up(mac, phy, mode, interface, speed, duplex,
+				     tx_pause, rx_pause);
+	else
+		mtk_gdm_mac_link_up(mac, phy, mode, interface, speed, duplex,
+				    tx_pause, rx_pause);
+
+	/* Repeat pextp setup to tune link */
+	if (mac->pextp)
+		phy_set_mode_ext(mac->pextp, PHY_MODE_ETHERNET, interface);
+}
+
 static const struct phylink_mac_ops mtk_phylink_ops = {
 	.mac_select_pcs = mtk_mac_select_pcs,
 	.mac_config = mtk_mac_config,
+	.mac_prepare = mtk_mac_prepare,
 	.mac_finish = mtk_mac_finish,
 	.mac_link_down = mtk_mac_link_down,
 	.mac_link_up = mtk_mac_link_up,
@@ -3359,6 +3499,9 @@ static int mtk_open(struct net_device *dev)
 	struct mtk_eth *eth = mac->hw;
 	int i, err;
 
+	if (mac->pextp)
+		phy_power_on(mac->pextp);
+
 	err = phylink_of_phy_connect(mac->phylink, mac->of_node, 0);
 	if (err) {
 		netdev_err(dev, "%s: could not attach PHY: %d\n", __func__,
@@ -3488,6 +3631,9 @@ static int mtk_stop(struct net_device *dev)
 	for (i = 0; i < ARRAY_SIZE(eth->ppe); i++)
 		mtk_ppe_stop(eth->ppe[i]);
 
+	if (mac->pextp)
+		phy_power_off(mac->pextp);
+
 	return 0;
 }
 
@@ -4485,6 +4631,7 @@ static const struct net_device_ops mtk_netdev_ops = {
 static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 {
 	const __be32 *_id = of_get_property(np, "reg", NULL);
+	struct device_node *pcs_np;
 	phy_interface_t phy_mode;
 	struct phylink *phylink;
 	struct mtk_mac *mac;
@@ -4521,16 +4668,41 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 	mac->id = id;
 	mac->hw = eth;
 	mac->of_node = np;
+	pcs_np = of_parse_phandle(mac->of_node, "pcs-handle", 0);
+	if (pcs_np) {
+		mac->sgmii_pcs = mtk_pcs_lynxi_get(eth->dev, pcs_np);
+		if (IS_ERR(mac->sgmii_pcs)) {
+			if (PTR_ERR(mac->sgmii_pcs) == -EPROBE_DEFER)
+				return -EPROBE_DEFER;
+
+			dev_err(eth->dev, "cannot select SGMII PCS, error %ld\n",
+				PTR_ERR(mac->sgmii_pcs));
+			return PTR_ERR(mac->sgmii_pcs);
+		}
+	}
 
-	err = of_get_ethdev_address(mac->of_node, eth->netdev[id]);
-	if (err == -EPROBE_DEFER)
-		return err;
+	pcs_np = of_parse_phandle(mac->of_node, "pcs-handle", 1);
+	if (pcs_np) {
+		mac->usxgmii_pcs = mtk_usxgmii_pcs_get(eth->dev, pcs_np);
+		if (IS_ERR(mac->usxgmii_pcs)) {
+			if (PTR_ERR(mac->usxgmii_pcs) == -EPROBE_DEFER)
+				return -EPROBE_DEFER;
 
-	if (err) {
-		/* If the mac address is invalid, use random mac address */
-		eth_hw_addr_random(eth->netdev[id]);
-		dev_err(eth->dev, "generated random MAC address %pM\n",
-			eth->netdev[id]->dev_addr);
+			dev_err(eth->dev, "cannot select USXGMII PCS, error %ld\n",
+				PTR_ERR(mac->usxgmii_pcs));
+			return PTR_ERR(mac->usxgmii_pcs);
+		}
+	}
+
+	if (mtk_is_netsys_v3_or_greater(eth) && (mac->sgmii_pcs || mac->usxgmii_pcs)) {
+		mac->pextp = devm_of_phy_get(eth->dev, mac->of_node, NULL);
+		if (IS_ERR(mac->pextp)) {
+			if (PTR_ERR(mac->pextp) != -EPROBE_DEFER)
+				dev_err(eth->dev, "cannot get PHY, error %ld\n",
+					PTR_ERR(mac->pextp));
+
+			return PTR_ERR(mac->pextp);
+		}
 	}
 
 	memset(mac->hwlro_ip, 0, sizeof(mac->hwlro_ip));
@@ -4613,8 +4785,21 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 		phy_interface_zero(mac->phylink_config.supported_interfaces);
 		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
 			  mac->phylink_config.supported_interfaces);
+	} else if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_USXGMII)) {
+		mac->phylink_config.mac_capabilities |= MAC_5000FD | MAC_10000FD;
+		__set_bit(PHY_INTERFACE_MODE_5GBASER,
+			  mac->phylink_config.supported_interfaces);
+		__set_bit(PHY_INTERFACE_MODE_10GBASER,
+			  mac->phylink_config.supported_interfaces);
+		__set_bit(PHY_INTERFACE_MODE_USXGMII,
+			  mac->phylink_config.supported_interfaces);
 	}
 
+	if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_2P5GPHY) &&
+	    id == MTK_GMAC2_ID)
+		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
+			  mac->phylink_config.supported_interfaces);
+
 	phylink = phylink_create(&mac->phylink_config,
 				 of_fwnode_handle(mac->of_node),
 				 phy_mode, &mtk_phylink_ops);
@@ -4665,6 +4850,26 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 	return err;
 }
 
+static int mtk_mac_assign_address(struct mtk_eth *eth, int i, bool test_defer_only)
+{
+	int err = of_get_ethdev_address(eth->mac[i]->of_node, eth->netdev[i]);
+
+	if (err == -EPROBE_DEFER)
+		return err;
+
+	if (test_defer_only)
+		return 0;
+
+	if (err) {
+		/* If the mac address is invalid, use random mac address */
+		eth_hw_addr_random(eth->netdev[i]);
+		dev_err(eth->dev, "generated random MAC address %pM\n",
+			eth->netdev[i]);
+	}
+
+	return 0;
+}
+
 void mtk_eth_set_dma_device(struct mtk_eth *eth, struct device *dma_dev)
 {
 	struct net_device *dev, *tmp;
@@ -4808,7 +5013,8 @@ static int mtk_probe(struct platform_device *pdev)
 			regmap_write(cci, 0, 3);
 	}
 
-	if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII)) {
+	if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII) &&
+	    !mtk_is_netsys_v3_or_greater(eth)) {
 		err = mtk_sgmii_init(eth);
 
 		if (err)
@@ -4919,6 +5125,24 @@ static int mtk_probe(struct platform_device *pdev)
 		}
 	}
 
+	for (i = 0; i < MTK_MAX_DEVS; i++) {
+		if (!eth->netdev[i])
+			continue;
+
+		err = mtk_mac_assign_address(eth, i, true);
+		if (err)
+			goto err_deinit_hw;
+	}
+
+	for (i = 0; i < MTK_MAX_DEVS; i++) {
+		if (!eth->netdev[i])
+			continue;
+
+		err = mtk_mac_assign_address(eth, i, false);
+		if (err)
+			goto err_deinit_hw;
+	}
+
 	if (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_INT)) {
 		err = devm_request_irq(eth->dev, eth->irq[0],
 				       mtk_handle_irq, 0,
@@ -5019,6 +5243,11 @@ static void mtk_remove(struct platform_device *pdev)
 		mtk_stop(eth->netdev[i]);
 		mac = netdev_priv(eth->netdev[i]);
 		phylink_disconnect_phy(mac->phylink);
+		if (mac->sgmii_pcs)
+			mtk_pcs_lynxi_put(mac->sgmii_pcs);
+
+		if (mac->usxgmii_pcs)
+			mtk_usxgmii_pcs_put(mac->usxgmii_pcs);
 	}
 
 	mtk_wed_exit();
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 9ae3b8a71d0e6..8424ac6cb725b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -15,6 +15,7 @@
 #include <linux/u64_stats_sync.h>
 #include <linux/refcount.h>
 #include <linux/phylink.h>
+#include <linux/reset.h>
 #include <linux/rhashtable.h>
 #include <linux/dim.h>
 #include <linux/bitfield.h>
@@ -503,6 +504,21 @@
 #define INTF_MODE_RGMII_1000    (TRGMII_MODE | TRGMII_CENTRAL_ALIGNED)
 #define INTF_MODE_RGMII_10_100  0
 
+/* XFI Mac control registers */
+#define MTK_XMAC_BASE(x)	(0x12000 + (((x) - 1) * 0x1000))
+#define MTK_XMAC_MCR(x)		(MTK_XMAC_BASE(x))
+#define XMAC_MCR_TRX_DISABLE	0xf
+#define XMAC_MCR_FORCE_TX_FC	BIT(5)
+#define XMAC_MCR_FORCE_RX_FC	BIT(4)
+
+/* XFI Mac logic reset registers */
+#define MTK_XMAC_LOGIC_RST(x)	(MTK_XMAC_BASE(x) + 0x10)
+#define XMAC_LOGIC_RST		BIT(0)
+
+/* XFI Mac count global control */
+#define MTK_XMAC_CNT_CTRL(x)	(MTK_XMAC_BASE(x) + 0x100)
+#define XMAC_GLB_CNTCLR		BIT(0)
+
 /* GPIO port control registers for GMAC 2*/
 #define GPIO_OD33_CTRL8		0x4c0
 #define GPIO_BIAS_CTRL		0xed0
@@ -528,6 +544,7 @@
 #define SYSCFG0_SGMII_GMAC2    ((3 << 8) & SYSCFG0_SGMII_MASK)
 #define SYSCFG0_SGMII_GMAC1_V2 BIT(9)
 #define SYSCFG0_SGMII_GMAC2_V2 BIT(8)
+#define SYSCFG0_SGMII_GMAC3_V2 BIT(7)
 
 
 /* ethernet subsystem clock register */
@@ -566,6 +583,11 @@
 #define GEPHY_MAC_SEL          BIT(1)
 
 /* Top misc registers */
+#define TOP_MISC_NETSYS_PCS_MUX	0x84
+#define NETSYS_PCS_MUX_MASK	GENMASK(1, 0)
+#define	MUX_G2_USXGMII_SEL	BIT(1)
+#define MUX_HSGMII1_G1_SEL	BIT(0)
+
 #define USB_PHY_SWITCH_REG	0x218
 #define QPHY_SEL_MASK		GENMASK(1, 0)
 #define SGMII_QPHY_SEL		0x2
@@ -590,6 +612,8 @@
 #define MT7628_SDM_RBCNT	(MT7628_SDM_OFFSET + 0x10c)
 #define MT7628_SDM_CS_ERR	(MT7628_SDM_OFFSET + 0x110)
 
+/* Debug Purpose Register */
+#define MTK_PSE_FQFC_CFG	0x100
 #define MTK_FE_CDM1_FSM		0x220
 #define MTK_FE_CDM2_FSM		0x224
 #define MTK_FE_CDM3_FSM		0x238
@@ -598,6 +622,11 @@
 #define MTK_FE_CDM6_FSM		0x328
 #define MTK_FE_GDM1_FSM		0x228
 #define MTK_FE_GDM2_FSM		0x22C
+#define MTK_FE_GDM3_FSM		0x23C
+#define MTK_FE_PSE_FREE		0x240
+#define MTK_FE_DROP_FQ		0x244
+#define MTK_FE_DROP_FC		0x248
+#define MTK_FE_DROP_PPE		0x24C
 
 #define MTK_MAC_FSM(x)		(0x1010C + ((x) * 0x100))
 
@@ -722,12 +751,8 @@ enum mtk_clks_map {
 	MTK_CLK_ETHWARP_WOCPU2,
 	MTK_CLK_ETHWARP_WOCPU1,
 	MTK_CLK_ETHWARP_WOCPU0,
-	MTK_CLK_TOP_USXGMII_SBUS_0_SEL,
-	MTK_CLK_TOP_USXGMII_SBUS_1_SEL,
 	MTK_CLK_TOP_SGM_0_SEL,
 	MTK_CLK_TOP_SGM_1_SEL,
-	MTK_CLK_TOP_XFI_PHY_0_XTAL_SEL,
-	MTK_CLK_TOP_XFI_PHY_1_XTAL_SEL,
 	MTK_CLK_TOP_ETH_GMII_SEL,
 	MTK_CLK_TOP_ETH_REFCK_50M_SEL,
 	MTK_CLK_TOP_ETH_SYS_200M_SEL,
@@ -798,19 +823,9 @@ enum mtk_clks_map {
 				 BIT_ULL(MTK_CLK_GP3) | BIT_ULL(MTK_CLK_XGP1) | \
 				 BIT_ULL(MTK_CLK_XGP2) | BIT_ULL(MTK_CLK_XGP3) | \
 				 BIT_ULL(MTK_CLK_CRYPTO) | \
-				 BIT_ULL(MTK_CLK_SGMII_TX_250M) | \
-				 BIT_ULL(MTK_CLK_SGMII_RX_250M) | \
-				 BIT_ULL(MTK_CLK_SGMII2_TX_250M) | \
-				 BIT_ULL(MTK_CLK_SGMII2_RX_250M) | \
 				 BIT_ULL(MTK_CLK_ETHWARP_WOCPU2) | \
 				 BIT_ULL(MTK_CLK_ETHWARP_WOCPU1) | \
 				 BIT_ULL(MTK_CLK_ETHWARP_WOCPU0) | \
-				 BIT_ULL(MTK_CLK_TOP_USXGMII_SBUS_0_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_USXGMII_SBUS_1_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_SGM_0_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_SGM_1_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_XFI_PHY_0_XTAL_SEL) | \
-				 BIT_ULL(MTK_CLK_TOP_XFI_PHY_1_XTAL_SEL) | \
 				 BIT_ULL(MTK_CLK_TOP_ETH_GMII_SEL) | \
 				 BIT_ULL(MTK_CLK_TOP_ETH_REFCK_50M_SEL) | \
 				 BIT_ULL(MTK_CLK_TOP_ETH_SYS_200M_SEL) | \
@@ -944,6 +959,8 @@ enum mkt_eth_capabilities {
 	MTK_RGMII_BIT = 0,
 	MTK_TRGMII_BIT,
 	MTK_SGMII_BIT,
+	MTK_USXGMII_BIT,
+	MTK_2P5GPHY_BIT,
 	MTK_ESW_BIT,
 	MTK_GEPHY_BIT,
 	MTK_MUX_BIT,
@@ -964,8 +981,11 @@ enum mkt_eth_capabilities {
 	MTK_ETH_MUX_GDM1_TO_GMAC1_ESW_BIT,
 	MTK_ETH_MUX_GMAC2_GMAC0_TO_GEPHY_BIT,
 	MTK_ETH_MUX_U3_GMAC2_TO_QPHY_BIT,
+	MTK_ETH_MUX_GMAC2_TO_2P5GPHY_BIT,
 	MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII_BIT,
 	MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII_BIT,
+	MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII_BIT,
+	MTK_ETH_MUX_GMAC123_TO_USXGMII_BIT,
 
 	/* PATH BITS */
 	MTK_ETH_PATH_GMAC1_RGMII_BIT,
@@ -973,14 +993,21 @@ enum mkt_eth_capabilities {
 	MTK_ETH_PATH_GMAC1_SGMII_BIT,
 	MTK_ETH_PATH_GMAC2_RGMII_BIT,
 	MTK_ETH_PATH_GMAC2_SGMII_BIT,
+	MTK_ETH_PATH_GMAC2_2P5GPHY_BIT,
 	MTK_ETH_PATH_GMAC2_GEPHY_BIT,
+	MTK_ETH_PATH_GMAC3_SGMII_BIT,
 	MTK_ETH_PATH_GDM1_ESW_BIT,
+	MTK_ETH_PATH_GMAC1_USXGMII_BIT,
+	MTK_ETH_PATH_GMAC2_USXGMII_BIT,
+	MTK_ETH_PATH_GMAC3_USXGMII_BIT,
 };
 
 /* Supported hardware group on SoCs */
 #define MTK_RGMII		BIT_ULL(MTK_RGMII_BIT)
 #define MTK_TRGMII		BIT_ULL(MTK_TRGMII_BIT)
 #define MTK_SGMII		BIT_ULL(MTK_SGMII_BIT)
+#define MTK_USXGMII		BIT_ULL(MTK_USXGMII_BIT)
+#define MTK_2P5GPHY		BIT_ULL(MTK_2P5GPHY_BIT)
 #define MTK_ESW			BIT_ULL(MTK_ESW_BIT)
 #define MTK_GEPHY		BIT_ULL(MTK_GEPHY_BIT)
 #define MTK_MUX			BIT_ULL(MTK_MUX_BIT)
@@ -1003,10 +1030,16 @@ enum mkt_eth_capabilities {
 	BIT_ULL(MTK_ETH_MUX_GMAC2_GMAC0_TO_GEPHY_BIT)
 #define MTK_ETH_MUX_U3_GMAC2_TO_QPHY		\
 	BIT_ULL(MTK_ETH_MUX_U3_GMAC2_TO_QPHY_BIT)
+#define MTK_ETH_MUX_GMAC2_TO_2P5GPHY		\
+	BIT_ULL(MTK_ETH_MUX_GMAC2_TO_2P5GPHY_BIT)
 #define MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII	\
 	BIT_ULL(MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII_BIT)
 #define MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII	\
 	BIT_ULL(MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII_BIT)
+#define MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII	\
+	BIT_ULL(MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII_BIT)
+#define MTK_ETH_MUX_GMAC123_TO_USXGMII	\
+	BIT_ULL(MTK_ETH_MUX_GMAC123_TO_USXGMII_BIT)
 
 /* Supported path present on SoCs */
 #define MTK_ETH_PATH_GMAC1_RGMII	BIT_ULL(MTK_ETH_PATH_GMAC1_RGMII_BIT)
@@ -1014,8 +1047,13 @@ enum mkt_eth_capabilities {
 #define MTK_ETH_PATH_GMAC1_SGMII	BIT_ULL(MTK_ETH_PATH_GMAC1_SGMII_BIT)
 #define MTK_ETH_PATH_GMAC2_RGMII	BIT_ULL(MTK_ETH_PATH_GMAC2_RGMII_BIT)
 #define MTK_ETH_PATH_GMAC2_SGMII	BIT_ULL(MTK_ETH_PATH_GMAC2_SGMII_BIT)
+#define MTK_ETH_PATH_GMAC2_2P5GPHY	BIT_ULL(MTK_ETH_PATH_GMAC2_2P5GPHY_BIT)
 #define MTK_ETH_PATH_GMAC2_GEPHY	BIT_ULL(MTK_ETH_PATH_GMAC2_GEPHY_BIT)
+#define MTK_ETH_PATH_GMAC3_SGMII	BIT_ULL(MTK_ETH_PATH_GMAC3_SGMII_BIT)
 #define MTK_ETH_PATH_GDM1_ESW		BIT_ULL(MTK_ETH_PATH_GDM1_ESW_BIT)
+#define MTK_ETH_PATH_GMAC1_USXGMII	BIT_ULL(MTK_ETH_PATH_GMAC1_USXGMII_BIT)
+#define MTK_ETH_PATH_GMAC2_USXGMII	BIT_ULL(MTK_ETH_PATH_GMAC2_USXGMII_BIT)
+#define MTK_ETH_PATH_GMAC3_USXGMII	BIT_ULL(MTK_ETH_PATH_GMAC3_USXGMII_BIT)
 
 #define MTK_GMAC1_RGMII		(MTK_ETH_PATH_GMAC1_RGMII | MTK_RGMII)
 #define MTK_GMAC1_TRGMII	(MTK_ETH_PATH_GMAC1_TRGMII | MTK_TRGMII)
@@ -1023,7 +1061,12 @@ enum mkt_eth_capabilities {
 #define MTK_GMAC2_RGMII		(MTK_ETH_PATH_GMAC2_RGMII | MTK_RGMII)
 #define MTK_GMAC2_SGMII		(MTK_ETH_PATH_GMAC2_SGMII | MTK_SGMII)
 #define MTK_GMAC2_GEPHY		(MTK_ETH_PATH_GMAC2_GEPHY | MTK_GEPHY)
+#define MTK_GMAC2_2P5GPHY	(MTK_ETH_PATH_GMAC2_2P5GPHY | MTK_2P5GPHY)
+#define MTK_GMAC3_SGMII		(MTK_ETH_PATH_GMAC3_SGMII | MTK_SGMII)
 #define MTK_GDM1_ESW		(MTK_ETH_PATH_GDM1_ESW | MTK_ESW)
+#define MTK_GMAC1_USXGMII	(MTK_ETH_PATH_GMAC1_USXGMII | MTK_USXGMII)
+#define MTK_GMAC2_USXGMII	(MTK_ETH_PATH_GMAC2_USXGMII | MTK_USXGMII)
+#define MTK_GMAC3_USXGMII	(MTK_ETH_PATH_GMAC3_USXGMII | MTK_USXGMII)
 
 /* MUXes present on SoCs */
 /* 0: GDM1 -> GMAC1, 1: GDM1 -> ESW */
@@ -1042,10 +1085,20 @@ enum mkt_eth_capabilities {
 	(MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII | MTK_MUX | \
 	MTK_SHARED_SGMII)
 
+/* 2: GMAC2 -> XGMII */
+#define MTK_MUX_GMAC2_TO_2P5GPHY      \
+	(MTK_ETH_MUX_GMAC2_TO_2P5GPHY | MTK_MUX | MTK_INFRA)
+
 /* 0: GMACx -> GEPHY, 1: GMACx -> SGMII where x is 1 or 2 */
 #define MTK_MUX_GMAC12_TO_GEPHY_SGMII   \
 	(MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII | MTK_MUX)
 
+#define MTK_MUX_GMAC123_TO_GEPHY_SGMII   \
+	(MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII | MTK_MUX)
+
+#define MTK_MUX_GMAC123_TO_USXGMII   \
+	(MTK_ETH_MUX_GMAC123_TO_USXGMII | MTK_MUX | MTK_INFRA)
+
 #define MTK_HAS_CAPS(caps, _x)		(((caps) & (_x)) == (_x))
 
 #define MT7621_CAPS  (MTK_GMAC1_RGMII | MTK_GMAC1_TRGMII | \
@@ -1077,8 +1130,12 @@ enum mkt_eth_capabilities {
 		      MTK_MUX_GMAC12_TO_GEPHY_SGMII | MTK_QDMA | \
 		      MTK_RSTCTRL_PPE1 | MTK_SRAM)
 
-#define MT7988_CAPS  (MTK_36BIT_DMA | MTK_GDM1_ESW | MTK_QDMA | \
-		      MTK_RSTCTRL_PPE1 | MTK_RSTCTRL_PPE2 | MTK_SRAM)
+#define MT7988_CAPS  (MTK_36BIT_DMA | MTK_GDM1_ESW | MTK_GMAC1_SGMII | \
+		      MTK_GMAC2_2P5GPHY | MTK_GMAC2_SGMII | MTK_GMAC2_USXGMII | \
+		      MTK_GMAC3_SGMII | MTK_GMAC3_USXGMII | \
+		      MTK_MUX_GMAC123_TO_GEPHY_SGMII | \
+		      MTK_MUX_GMAC123_TO_USXGMII | MTK_MUX_GMAC2_TO_2P5GPHY | \
+		      MTK_QDMA | MTK_RSTCTRL_PPE1 | MTK_RSTCTRL_PPE2 | MTK_SRAM)
 
 struct mtk_tx_dma_desc_info {
 	dma_addr_t	addr;
@@ -1315,6 +1372,9 @@ struct mtk_mac {
 	struct device_node		*of_node;
 	struct phylink			*phylink;
 	struct phylink_config		phylink_config;
+	struct phylink_pcs		*sgmii_pcs;
+	struct phylink_pcs		*usxgmii_pcs;
+	struct phy			*pextp;
 	struct mtk_eth			*hw;
 	struct mtk_hw_stats		*hw_stats;
 	__be32				hwlro_ip[MTK_MAX_LRO_IP_CNT];
@@ -1421,6 +1481,19 @@ static inline u32 mtk_get_ib2_multicast_mask(struct mtk_eth *eth)
 	return MTK_FOE_IB2_MULTICAST;
 }
 
+static inline bool mtk_interface_mode_is_xgmii(phy_interface_t interface)
+{
+	switch (interface) {
+	case PHY_INTERFACE_MODE_INTERNAL:
+	case PHY_INTERFACE_MODE_USXGMII:
+	case PHY_INTERFACE_MODE_10GBASER:
+	case PHY_INTERFACE_MODE_5GBASER:
+		return true;
+	default:
+		return false;
+	}
+}
+
 /* read the hardware status register */
 void mtk_stats_update_mac(struct mtk_mac *mac);
 
@@ -1429,8 +1502,10 @@ u32 mtk_r32(struct mtk_eth *eth, unsigned reg);
 u32 mtk_m32(struct mtk_eth *eth, u32 mask, u32 set, unsigned int reg);
 
 int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id);
+int mtk_gmac_2p5gphy_path_setup(struct mtk_eth *eth, int mac_id);
 int mtk_gmac_gephy_path_setup(struct mtk_eth *eth, int mac_id);
 int mtk_gmac_rgmii_path_setup(struct mtk_eth *eth, int mac_id);
+int mtk_gmac_usxgmii_path_setup(struct mtk_eth *eth, int mac_id);
 
 int mtk_eth_offload_init(struct mtk_eth *eth);
 int mtk_eth_setup_tc(struct net_device *dev, enum tc_setup_type type,
-- 
2.43.0


From andrew at codeconstruct.com.au  Mon Dec 11 21:02:09 2023
From: andrew at codeconstruct.com.au (Andrew Jeffery)
Date: Tue, 12 Dec 2023 15:32:09 +1030
Subject: [PATCH v4 0/2] i2c: aspeed: Late ack Tx done irqs and handle
 coalesced start with stop conditions
In-Reply-To: <CACPK8Xc6-M9fsx3AUPobzvG6sjCrr8Sj5B3Q4Onp5wGvMm_BrA@mail.gmail.com>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
	 <CACPK8Xc6-M9fsx3AUPobzvG6sjCrr8Sj5B3Q4Onp5wGvMm_BrA@mail.gmail.com>
Message-ID: <c11d2365e67299dcc5ff7319a1856dbaa985d61e.camel@codeconstruct.com.au>

On Tue, 2023-12-12 at 13:09 +1030, Joel Stanley wrote:
> On Mon, 11 Dec 2023 at 20:52, Quan Nguyen <quan at os.amperecomputing.com> wrote:
> > 
> > This series consists of two patches to handle the below issues observed
> > when testing with slave mode:
> >   + The coalesced stop condition with the start conditions
> >   + Early ack'ed of Tx done (ACK and NAK) causing "Unexpected Ack on
> >   read request".
> 
> Looks good. I've reached out to a few people who use slave mode to ask
> for review and testing on hardware. As long as they don't come back
> with issues, we should get this merged and backported to stable.
> 
> Reviewed-by: Joel Stanley <joel at jms.id.au>

I've dropped a build with the patches onto an AST2600 EVB and lightly
exercised the affected paths using NVMe-MI over MCTP to a Micron 7450.

Tested-by: Andrew Jeffery <andrew at codeconstruct.com.au>

Andrew



From bretjoseph at gmail.com  Mon Dec 11 21:04:51 2023
From: bretjoseph at gmail.com (Bret Joseph)
Date: Tue, 12 Dec 2023 07:04:51 +0200
Subject: [PATCH v3 3/3] regulator: mt6358: Add output voltage fine tuning
 to variable LDOs
In-Reply-To: <CAKpemQLyieDP1r11v1WJ+-SXeseUiPKsCK6SBf-FSCOxGkEWHw@mail.gmail.com>
References: <CAKpemQKo2gigO44amj=eFUXgUnUeSmiOoTbS8GdXMx3O07N1vg@mail.gmail.com>
 <CAGXv+5E4TXrPmhb++r3vMGA4WoPc=covi7_=zgLLcOhGt9UBgg@mail.gmail.com>
 <CAKpemQJDf9RqeOStB4Rm5hzuQdzYF6JEbuz00Cr-a80cWZKR6w@mail.gmail.com>
 <CAGXv+5HuxOtFfdWdocspTcDRytCK+0Ny+c_aFLJyHCUbYTboJQ@mail.gmail.com> <CAKpemQLyieDP1r11v1WJ+-SXeseUiPKsCK6SBf-FSCOxGkEWHw@mail.gmail.com>
Message-ID: <CAKpemQJkFxDnqob4NpqYc7iTWNiaoVUJ+rFvw+nRv0mYvoNJcg@mail.gmail.com>

For the LDO regulators that were not probing, I changed the pickable
regmap to just a regmap function.
In static int mt6358_get_buck_voltage_sel(struct regulator_dev *rdev){}

For LDO1
        ret = (regval & info->da_vsel_mask) >> (ffs(info->da_vsel_mask) - 1);
returns
[    3.470672] shift exponent -1 is negative
[    3.470910] CPU: 7 PID: 63 Comm: kworker/u16:2 Not tainted 6.7.0-rc5 #3
[    3.471278] Hardware name: MT6769H (DT)
[    3.471521] Workqueue: events_unbound async_run_entry_fn

fixed by adding
        .da_vsel_shift = 8

--- linux-6.7.0-rc5/drivers/regulator/mt6358-regulator.c 2023-12-12
05:32:19.703310500 +0200
+++ linux/drivers/regulator/mt6358-regulator.c 2023-12-12
06:25:06.855132318 +0200
@@ -27,6 +27,7 @@
  u32 qi;
  u32 da_vsel_reg;
  u32 da_vsel_mask;
+ u32 da_vsel_shift;
  u32 modeset_reg;
  u32 modeset_mask;
 };
@@ -108,6 +109,7 @@
  }, \
  .da_vsel_reg = _da_vsel_reg, \
  .da_vsel_mask = _da_vsel_mask, \
+ .da_vsel_shift = 8, \
  .status_reg = MT6358_LDO_##vreg##_DBG1, \
  .qi = BIT(0), \
 }
@@ -209,6 +211,7 @@
  }, \
  .da_vsel_reg = _da_vsel_reg, \
  .da_vsel_mask = _da_vsel_mask, \
+ .da_vsel_shift = 8, \
  .status_reg = MT6358_LDO_##vreg##_DBG1, \
  .qi = BIT(0), \
 }
@@ -381,7 +384,7 @@
  return ret;
  }

- ret = (regval & info->da_vsel_mask) >> (ffs(info->da_vsel_mask) - 1);
+ ret = (regval >> info->da_vsel_shift) & info->da_vsel_mask;

  return ret;
 }
@@ -478,8 +481,8 @@
 static const struct regulator_ops mt6358_volt_table_ops = {
  .list_voltage = regulator_list_voltage_pickable_linear_range,
  .map_voltage = regulator_map_voltage_pickable_linear_range,
- .set_voltage_sel = regulator_set_voltage_sel_pickable_regmap,
- .get_voltage_sel = regulator_get_voltage_sel_pickable_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
  .set_voltage_time_sel = regulator_set_voltage_time_sel,
  .enable = regulator_enable_regmap,
  .disable = regulator_disable_regmap,


From bot at kernelci.org  Mon Dec 11 21:34:49 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Mon, 11 Dec 2023 21:34:49 -0800 (PST)
Subject: arm64/for-kernelci build: 1 build: 0 failed,
 1 passed (v6.7-rc5-48-g0128e0962959d)
Message-ID: <6577f0f9.a70a0220.26d54.5849@mx.google.com>

arm64/for-kernelci build: 1 build: 0 failed, 1 passed (v6.7-rc5-48-g0128e0962959d)

Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v6.7-rc5-48-g0128e0962959d/

Tree: arm64
Branch: for-kernelci
Git Describe: v6.7-rc5-48-g0128e0962959d
Git Commit: 0128e0962959d1ee896076d8eec31757ca38cd42
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Built: 1 unique architecture

================================================================================

Detailed per-defconfig build reports:

--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) ? PASS, 0 errors, 0 warnings, 0 section mismatches

---
For more info write to <info at kernelci.org>


From daeinki at gmail.com  Mon Dec 11 21:38:47 2023
From: daeinki at gmail.com (Inki Dae)
Date: Tue, 12 Dec 2023 14:38:47 +0900
Subject: [PATCH v3 08/16] drm/exynos: Convert to platform remove callback
 returning void
In-Reply-To: <20231207080338.kcjx7uixxjw2axtc@pengutronix.de>
References: <20231102165640.3307820-18-u.kleine-koenig@pengutronix.de>
 <20231102165640.3307820-26-u.kleine-koenig@pengutronix.de>
 <CAAQKjZOnVSaO6QHpSo_i=WgTaawTq0UFtzwTw8kQ5iHN4qiAtQ@mail.gmail.com>
 <20231108075454.3aivzrbvtr4en22e@pengutronix.de> <CGME20231128165521epcas1p4993f7d2fab0723130a4612d810d254f8@epcas1p4.samsung.com>
 <20231128165505.wm4xs4ktycswthkt@pengutronix.de> <048901da28b6$5be8e700$13bab500$@samsung.com>
 <20231207080338.kcjx7uixxjw2axtc@pengutronix.de>
Message-ID: <CAAQKjZPxatiZG+HJeXW9UYFiSOuGD0EgvWKiOrYCuhk27x2AwQ@mail.gmail.com>

Hello Uwe Kleine-K?nig,

2023? 12? 7? (?) ?? 5:03, Uwe Kleine-K?nig
<u.kleine-koenig at pengutronix.de>?? ??:
>
> Hello Inki,
>
> On Thu, Dec 07, 2023 at 11:37:44AM +0900, ???/Tizen Platform Lab(SR)/???? wrote:
> > Hello Uwe Kleine-K?nig,
> >
> > > -----Original Message-----
> > > From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> > > Sent: Wednesday, November 29, 2023 1:55 AM
> > > To: Inki Dae <daeinki at gmail.com>
> > > Cc: linux-samsung-soc at vger.kernel.org; Daniel Vetter <daniel at ffwll.ch>;
> > > Jingoo Han <jingoohan1 at gmail.com>; Seung-Woo Kim <sw0312.kim at samsung.com>;
> > > Kyungmin Park <kyungmin.park at samsung.com>; DRI mailing list <dri-
> > > devel at lists.freedesktop.org>; Krzysztof Kozlowski
> > > <krzysztof.kozlowski at linaro.org>; kernel at pengutronix.de; Alim Akhtar
> > > <alim.akhtar at samsung.com>; David Airlie <airlied at gmail.com>; linux-arm-
> > > kernel at lists.infradead.org
> > > Subject: Re: [PATCH v3 08/16] drm/exynos: Convert to platform remove
> > > callback returning void
> > >
> > > Hello Inki,
> > >
> > > On Wed, Nov 08, 2023 at 08:54:54AM +0100, Uwe Kleine-K?nig wrote:
> > > > Hello Inki,
> > > >
> > > > On Wed, Nov 08, 2023 at 01:16:18PM +0900, Inki Dae wrote:
> > > > > Sorry for late. There was a merge conflict so I fixed it manually and
> > > > > merged. And seems your patch description is duplicated so dropped
> > > > > duplicated one.
> > > >
> > > > Ah. I have a template that generates one patch per driver. I guess this
> > > > is the result of using squash instead of fixup while putting all exynos
> > > > changes into a single patch.
> > >
> > > This patch didn't make it into next yet even though it's included in
> > > your exynos-drm-next branch at
> > > https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git.
> > >
> > > Is this on purpose?
> >
> > drm-exynos tree is not included in the next tree. It was previously
> > included, but it has been removed. drm-exynos tree is merged into the
> > mainline through the drm-next tree, but when the drm-next is
> > synchronized to the next tree, a conflict occurred between the
> > exynos-drm tree and the drm-next tree. Therefore, I had requested that
> > drm-exynos tree be removed from the next. Perhaps I was inexperienced
> > in managing the git tree at that time. :)
>
> That sounds more like a reason to have your tree in next. One of the
> core motivations of next is to find inter-tree conflicts early. If such
> a conflict occurs and you only notice it when it's time to send your PR
> to drm-next (or even later) the pressure to fix the problem is higher.
>
> Also for patch contributors it's nice to have a "complete" next, their
> tests are more expressive then.
>
> So I want to encourage you to readd your tree to next.

Thanks for your feedback. Requested to Stephen Rothwell. :)

Thanks,
Inki Dae

>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | https://www.pengutronix.de/ |


From robh at kernel.org  Mon Dec 11 21:43:35 2023
From: robh at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 23:43:35 -0600
Subject: [RFC PATCH net-next v3 1/8] dt-bindings: phy:
 mediatek,xfi-pextp: add new bindings
In-Reply-To: <b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel@makrotopia.org>
Message-ID: <170235981390.39579.3867728590010297335.robh@kernel.org>


On Tue, 12 Dec 2023 03:46:26 +0000, Daniel Golle wrote:
> Add bindings for the MediaTek PEXTP Ethernet SerDes PHY found in the
> MediaTek MT7988 SoC which can operate at various interfaces modes:
> 
>  * USXGMII
>  * 10GBase-R
>  * 5GBase-R
>  * 2500Base-X
>  * 1000Base-X
>  * Cisco SGMII (MAC side)
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../bindings/phy/mediatek,xfi-pextp.yaml      | 80 +++++++++++++++++++
>  1 file changed, 80 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml:33:16: [error] string value is redundantly quoted with any quotes (quoted-strings)
./Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.yaml:34:16: [error] string value is redundantly quoted with any quotes (quoted-strings)

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.example.dts:18:18: fatal error: dt-bindings/clock/mediatek,mt7988-clk.h: No such file or directory
   18 |         #include <dt-bindings/clock/mediatek,mt7988-clk.h>
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/phy/mediatek,xfi-pextp.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: dt_binding_check] Error 2
make: *** [Makefile:234: __sub-make] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel at makrotopia.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From robh at kernel.org  Mon Dec 11 21:43:35 2023
From: robh at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 23:43:35 -0600
Subject: [RFC PATCH net-next v3 7/8] dt-bindings: net: mediatek,net:
 fix and complete mt7988-eth binding
In-Reply-To: <ac6a7277fc534f610386bc51b2ff87beade03be8.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <ac6a7277fc534f610386bc51b2ff87beade03be8.1702352117.git.daniel@makrotopia.org>
Message-ID: <170235981567.39712.1104850530934071903.robh@kernel.org>


On Tue, 12 Dec 2023 03:51:01 +0000, Daniel Golle wrote:
> Complete support for MT7988 which comes with 3 MACs, SRAM for DMA
> descriptors and uses a dedicated PCS for the SerDes units.
> 
> Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../devicetree/bindings/net/mediatek,net.yaml | 148 +++++++++++++++++-
>  1 file changed, 146 insertions(+), 2 deletions(-)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/net/mediatek,net.example.dts:231:18: fatal error: dt-bindings/clock/mediatek,mt7988-clk.h: No such file or directory
  231 |         #include <dt-bindings/clock/mediatek,mt7988-clk.h>
make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/net/mediatek,net.example.dtb] Error 1

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/ac6a7277fc534f610386bc51b2ff87beade03be8.1702352117.git.daniel at makrotopia.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From robh at kernel.org  Mon Dec 11 21:43:35 2023
From: robh at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 23:43:35 -0600
Subject: [RFC PATCH net-next v3 6/8] dt-bindings: net: mediatek: remove
 wrongly added clocks and SerDes
In-Reply-To: <5859da6629b8b6c100eca4062dd193105bf829ba.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <5859da6629b8b6c100eca4062dd193105bf829ba.1702352117.git.daniel@makrotopia.org>
Message-ID: <170235981509.39662.6730294984307830032.robh@kernel.org>


On Tue, 12 Dec 2023 03:48:10 +0000, Daniel Golle wrote:
> Several clocks as well as both sgmiisys phandles were added by mistake
> to the Ethernet bindings for MT7988.
> 
> This happened because the vendor driver which served as a reference
> uses a high number of syscon phandles to access various parts of the
> SoC which wasn't acceptable upstream. Hence several parts which have
> never previously been supported (such SerDes PHY and USXGMII PCS) have
> been moved to separate drivers which also result in a much more sane
> device tree.
> 
> Quickly align the bindings with the upcoming reality of the drivers
> actually adding full support for this SoC.
> 
> Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../devicetree/bindings/net/mediatek,net.yaml | 32 ++++---------------
>  1 file changed, 7 insertions(+), 25 deletions(-)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.example.dts:18:18: fatal error: dt-bindings/clock/mediatek,mt7988-clk.h: No such file or directory
make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.example.dtb] Error 1

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/5859da6629b8b6c100eca4062dd193105bf829ba.1702352117.git.daniel at makrotopia.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From robh at kernel.org  Mon Dec 11 21:43:35 2023
From: robh at kernel.org (Rob Herring)
Date: Mon, 11 Dec 2023 23:43:35 -0600
Subject: [RFC PATCH net-next v3 4/8] dt-bindings: net: pcs: add
 bindings for MediaTek USXGMII PCS
In-Reply-To: <510af8550385da947e2e2516629c4fbed7fc0f64.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <510af8550385da947e2e2516629c4fbed7fc0f64.1702352117.git.daniel@makrotopia.org>
Message-ID: <170235981451.39631.18161764579046630601.robh@kernel.org>


On Tue, 12 Dec 2023 03:47:31 +0000, Daniel Golle wrote:
> MediaTek's USXGMII can be found in the MT7988 SoC. We need to access
> it in order to configure and monitor the Ethernet SerDes link in
> USXGMII, 10GBase-R and 5GBase-R mode. By including a wrapped
> legacy 1000Base-X/2500Base-X/Cisco SGMII LynxI PCS as well, those
> interface modes are also available.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../bindings/net/pcs/mediatek,usxgmii.yaml    | 60 +++++++++++++++++++
>  1 file changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:


doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/510af8550385da947e2e2516629c4fbed7fc0f64.1702352117.git.daniel at makrotopia.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From bot at kernelci.org  Mon Dec 11 22:18:02 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Mon, 11 Dec 2023 22:18:02 -0800 (PST)
Subject: arm64/for-kernelci baseline: 33 runs,
 3 regressions (v6.7-rc5-48-g0128e0962959d)
Message-ID: <6577fb1a.630a0220.756f1.4b5f@mx.google.com>

arm64/for-kernelci baseline: 33 runs, 3 regressions (v6.7-rc5-48-g0128e0962959d)

Regressions Summary
-------------------

platform           | arch  | lab          | compiler | defconfig | regressions
-------------------+-------+--------------+----------+-----------+------------
k3-am625-sk        | arm64 | lab-baylibre | gcc-10   | defconfig | 1          
kontron-pitx-imx8m | arm64 | lab-kontron  | gcc-10   | defconfig | 2          

  Details:  https://kernelci.org/test/job/arm64/branch/for-kernelci/kernel/v6.7-rc5-48-g0128e0962959d/plan/baseline/

  Test:     baseline
  Tree:     arm64
  Branch:   for-kernelci
  Describe: v6.7-rc5-48-g0128e0962959d
  URL:      https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
  SHA:      0128e0962959d1ee896076d8eec31757ca38cd42 


Test Regressions
---------------- 


platform           | arch  | lab          | compiler | defconfig | regressions
-------------------+-------+--------------+----------+-----------+------------
k3-am625-sk        | arm64 | lab-baylibre | gcc-10   | defconfig | 1          

  Details:     https://kernelci.org/test/plan/id/6577f1f1c26255b87be134d8

  Results:     0 PASS, 1 FAIL, 0 SKIP
  Full config: defconfig
  Compiler:    gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
  Plain log:   https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc5-48-g0128e0962959d/arm64/defconfig/gcc-10/lab-baylibre/baseline-k3-am625-sk.txt
  HTML log:    https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc5-48-g0128e0962959d/arm64/defconfig/gcc-10/lab-baylibre/baseline-k3-am625-sk.html
  Rootfs:      http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230623.0/arm64/rootfs.cpio.gz 


  * baseline.login: https://kernelci.org/test/case/id/6577f1f1c26255b87be134d9
        new failure (last pass: v6.7-rc4-20-gd46efae31672) 
 


platform           | arch  | lab          | compiler | defconfig | regressions
-------------------+-------+--------------+----------+-----------+------------
kontron-pitx-imx8m | arm64 | lab-kontron  | gcc-10   | defconfig | 2          

  Details:     https://kernelci.org/test/plan/id/6577f0daab53a2b740e13499

  Results:     51 PASS, 2 FAIL, 0 SKIP
  Full config: defconfig
  Compiler:    gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
  Plain log:   https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc5-48-g0128e0962959d/arm64/defconfig/gcc-10/lab-kontron/baseline-kontron-pitx-imx8m.txt
  HTML log:    https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc5-48-g0128e0962959d/arm64/defconfig/gcc-10/lab-kontron/baseline-kontron-pitx-imx8m.html
  Rootfs:      http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230623.0/arm64/rootfs.cpio.gz 


  * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/6577f0daab53a2b740e1349c
        new failure (last pass: v6.7-rc4-20-gd46efae31672)

    2023-12-12T05:33:52.019836  / # #
    2023-12-12T05:33:52.122112  export SHELL=/bin/sh
    2023-12-12T05:33:52.122849  #
    2023-12-12T05:33:52.224182  / # export SHELL=/bin/sh. /lava-404573/environment
    2023-12-12T05:33:52.224925  
    2023-12-12T05:33:52.326339  / # . /lava-404573/environment/lava-404573/bin/lava-test-runner /lava-404573/1
    2023-12-12T05:33:52.327521  
    2023-12-12T05:33:52.347254  / # /lava-404573/bin/lava-test-runner /lava-404573/1
    2023-12-12T05:33:52.389140  + export 'TESTRUN_ID=1_bootrr'
    2023-12-12T05:33:52.397075  + cd /lava-404573/1/tests/1_bootrr 
    ... (9 line(s) more)  

  * baseline.bootrr.dwc3-usb1-probed: https://kernelci.org/test/case/id/6577f0daab53a2b740e134ac
        new failure (last pass: v6.7-rc4-20-gd46efae31672)

    2023-12-12T05:33:54.782165  /lava-404573/1/../bin/lava-test-case
    2023-12-12T05:33:54.782594  <8>[   18.164553] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=dwc3-usb1-probed RESULT=fail>   
  


From hch at infradead.org  Mon Dec 11 23:11:06 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 23:11:06 -0800
Subject: [RFC PATCH 05/12] lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
In-Reply-To: <7c40dfe8-f245-413f-a424-bde52ce21b6a@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-6-samuel.holland@sifive.com>
 <ZXczty+Y6dTDL4Xi@infradead.org>
 <7c40dfe8-f245-413f-a424-bde52ce21b6a@sifive.com>
Message-ID: <ZXgHisDUsJMw7z3N@infradead.org>

On Mon, Dec 11, 2023 at 10:12:27AM -0600, Samuel Holland wrote:
> On 2023-12-11 10:07 AM, Christoph Hellwig wrote:
> 
> Unfortunately, not all of the relevant options can be no-prefixed:

Ok.  That is another good argument for having the obj-fpu += syntax
I proposed.  You might need help from the kbuild maintainers from that
as trying to understand the kbuild magic isn't something I'd expect
from a normal contributor (including myself..).



From hch at infradead.org  Mon Dec 11 23:12:42 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 23:12:42 -0800
Subject: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
In-Reply-To: <6d4cecd5-9083-4d68-a7e2-266dae9e3952@sifive.com>
References: <20231122030621.3759313-1-samuel.holland@sifive.com>
 <20231122030621.3759313-4-samuel.holland@sifive.com>
 <ZV2+f/yu3C6xTVqn@infradead.org>
 <6d4cecd5-9083-4d68-a7e2-266dae9e3952@sifive.com>
Message-ID: <ZXgH6un2uLdjQ48X@infradead.org>

On Thu, Dec 07, 2023 at 10:49:53PM -0600, Samuel Holland wrote:
> Actually tracking all possibly-FPU-tainted functions and their call sites is
> probably possible, but a much larger task.

I think objtool should be able to do that reasonably easily, it already
does it for checking section where userspace address access is enabled
or not, which is very similar.


From Jianheng.Zhang at synopsys.com  Mon Dec 11 23:22:24 2023
From: Jianheng.Zhang at synopsys.com (Jianheng Zhang)
Date: Tue, 12 Dec 2023 07:22:24 +0000
Subject: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <d202770a-3a3a-4ee2-b0de-b86e2f3e83ce@lunn.ch>
References: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
 <d202770a-3a3a-4ee2-b0de-b86e2f3e83ce@lunn.ch>
Message-ID: <CY5PR12MB6372C8770900AFF821325400BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com>

Hi Andrew,  

> > +static int dwxgmac3_fpe_irq_status(void __iomem *ioaddr, struct net_device *dev)
> > +{
> > +	u32 value;
> > +	int status;
> >
> > -		writel(value, ioaddr + XGMAC_FPE_CTRL_STS);
> > -		return;
> > +	status = FPE_EVENT_UNKNOWN;
> > +
> > +	/* Reads from the XGMAC_FPE_CTRL_STS register should only be performed
> > +	 * here, since the status flags of MAC_FPE_CTRL_STS are "clear on read"
> > +	 */
> > +	value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
> > +
> > +	if (value & XGMAC_TRSP) {
> > +		status |= FPE_EVENT_TRSP;
> > +		netdev_info(dev, "FPE: Respond mPacket is transmitted\n");
> 
> netdev_info()?  Is this going to spam the logs? Should it be netdev_dbg()

Yes, netdev_dbg() should be better, let me fix it in the next patch.

Jianheng
> 
> 	Andrew


From lihuisong at huawei.com  Mon Dec 11 23:26:17 2023
From: lihuisong at huawei.com (Huisong Li)
Date: Tue, 12 Dec 2023 15:26:17 +0800
Subject: [PATCH] cpufreq: CPPC: Resolve the large frequency discrepancy from cpuinfo_cur_freq
Message-ID: <20231212072617.14756-1-lihuisong@huawei.com>

Many developers found that the cpu current frequency is greater than
the maximum frequency of the platform, please see [1], [2] and [3].

In the scenarios with high memory access pressure, the patch [1] has
proved the significant latency of cpc_read() which is used to obtain
delivered and reference performance counter cause an absurd frequency.
The sampling interval for this counters is very critical and is expected
to be equal. However, the different latency of cpc_read() has a direct
impact on their sampling interval.

This patch adds a interface, cpc_read_arch_counters_on_cpu, to read
delivered and reference performance counter together. According to my
test[4], the discrepancy of cpu current frequency in the scenarios with
high memory access pressure is lower than 0.2% by stress-ng application.

[1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4 at huawei.com/
[2] https://lore.kernel.org/all/20230328193846.8757-1-yang at os.amperecomputing.com/
[3] https://lore.kernel.org/all/20230418113459.12860-7-sumitg at nvidia.com/

[4] My local test:
The testing platform enable SMT and include 128 logical CPU in total,
and CPU base frequency is 2.7GHz. Reading "cpuinfo_cur_freq" for each
physical core on platform during the high memory access pressure from
stress-ng, and the output is as follows:
  0: 2699133     2: 2699942     4: 2698189     6: 2704347
  8: 2704009    10: 2696277    12: 2702016    14: 2701388
 16: 2700358    18: 2696741    20: 2700091    22: 2700122
 24: 2701713    26: 2702025    28: 2699816    30: 2700121
 32: 2700000    34: 2699788    36: 2698884    38: 2699109
 40: 2704494    42: 2698350    44: 2699997    46: 2701023
 48: 2703448    50: 2699501    52: 2700000    54: 2699999
 56: 2702645    58: 2696923    60: 2697718    62: 2700547
 64: 2700313    66: 2700000    68: 2699904    70: 2699259
 72: 2699511    74: 2700644    76: 2702201    78: 2700000
 80: 2700776    82: 2700364    84: 2702674    86: 2700255
 88: 2699886    90: 2700359    92: 2699662    94: 2696188
 96: 2705454    98: 2699260   100: 2701097   102: 2699630
104: 2700463   106: 2698408   108: 2697766   110: 2701181
112: 2699166   114: 2701804   116: 2701907   118: 2701973
120: 2699584   122: 2700474   124: 2700768   126: 2701963

Signed-off-by: Huisong Li <lihuisong at huawei.com>
---
 arch/arm64/kernel/topology.c | 43 ++++++++++++++++++++++++++++++++++--
 drivers/acpi/cppc_acpi.c     | 22 +++++++++++++++---
 include/acpi/cppc_acpi.h     |  5 +++++
 3 files changed, 65 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7d37e458e2f5..c3122154d738 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -299,6 +299,11 @@ core_initcall(init_amu_fie);
 #ifdef CONFIG_ACPI_CPPC_LIB
 #include <acpi/cppc_acpi.h>
 
+struct amu_counters {
+	u64 corecnt;
+	u64 constcnt;
+};
+
 static void cpu_read_corecnt(void *val)
 {
 	/*
@@ -322,8 +327,27 @@ static void cpu_read_constcnt(void *val)
 		      0UL : read_constcnt();
 }
 
+static void cpu_read_amu_counters(void *data)
+{
+	struct amu_counters *cnt = (struct amu_counters *)data;
+
+	/*
+	 * The running time of the this_cpu_has_cap() might have a couple of
+	 * microseconds and is significantly increased to tens of microseconds.
+	 * But AMU core and constant counter need to be read togeter without any
+	 * time interval to reduce the calculation discrepancy using this counters.
+	 */
+	if (this_cpu_has_cap(ARM64_WORKAROUND_2457168)) {
+		cnt->corecnt = read_corecnt();
+		cnt->constcnt = 0;
+	} else {
+		cnt->corecnt = read_corecnt();
+		cnt->constcnt = read_constcnt();
+	}
+}
+
 static inline
-int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
+int counters_read_on_cpu(int cpu, smp_call_func_t func, void *data)
 {
 	/*
 	 * Abort call on counterless CPU or when interrupts are
@@ -335,7 +359,7 @@ int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
 	if (WARN_ON_ONCE(irqs_disabled()))
 		return -EPERM;
 
-	smp_call_function_single(cpu, func, val, 1);
+	smp_call_function_single(cpu, func, data, 1);
 
 	return 0;
 }
@@ -364,6 +388,21 @@ bool cpc_ffh_supported(void)
 	return true;
 }
 
+int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference)
+{
+	struct amu_counters cnts = {0};
+	int ret;
+
+	ret = counters_read_on_cpu(cpu, cpu_read_amu_counters, &cnts);
+	if (ret)
+		return ret;
+
+	*delivered = cnts.corecnt;
+	*reference = cnts.constcnt;
+
+	return 0;
+}
+
 int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64 *val)
 {
 	int ret = -EOPNOTSUPP;
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 7ff269a78c20..f303fabd7cfe 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -1299,6 +1299,11 @@ bool cppc_perf_ctrs_in_pcc(void)
 }
 EXPORT_SYMBOL_GPL(cppc_perf_ctrs_in_pcc);
 
+int __weak cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference)
+{
+	return 0;
+}
+
 /**
  * cppc_get_perf_ctrs - Read a CPU's performance feedback counters.
  * @cpunum: CPU from which to read counters.
@@ -1313,7 +1318,8 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
 		*ref_perf_reg, *ctr_wrap_reg;
 	int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpunum);
 	struct cppc_pcc_data *pcc_ss_data = NULL;
-	u64 delivered, reference, ref_perf, ctr_wrap_time;
+	u64 delivered = 0, reference = 0;
+	u64 ref_perf, ctr_wrap_time;
 	int ret = 0, regs_in_pcc = 0;
 
 	if (!cpc_desc) {
@@ -1350,8 +1356,18 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
 		}
 	}
 
-	cpc_read(cpunum, delivered_reg, &delivered);
-	cpc_read(cpunum, reference_reg, &reference);
+	if (cpc_ffh_supported()) {
+		ret = cpc_read_arch_counters_on_cpu(cpunum, &delivered, &reference);
+		if (ret) {
+			pr_debug("read arch counters failed, ret=%d.\n", ret);
+			ret = 0;
+		}
+	}
+	if (!delivered || !reference) {
+		cpc_read(cpunum, delivered_reg, &delivered);
+		cpc_read(cpunum, reference_reg, &reference);
+	}
+
 	cpc_read(cpunum, ref_perf_reg, &ref_perf);
 
 	/*
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index 6126c977ece0..07d4fd82d499 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -152,6 +152,7 @@ extern bool cpc_ffh_supported(void);
 extern bool cpc_supported_by_cpu(void);
 extern int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val);
 extern int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val);
+extern int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference);
 extern int cppc_get_epp_perf(int cpunum, u64 *epp_perf);
 extern int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable);
 extern int cppc_get_auto_sel_caps(int cpunum, struct cppc_perf_caps *perf_caps);
@@ -209,6 +210,10 @@ static inline int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val)
 {
 	return -ENOTSUPP;
 }
+static inline int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference)
+{
+	return -EOPNOTSUPP;
+}
 static inline int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable)
 {
 	return -ENOTSUPP;
-- 
2.33.0



From Jianheng.Zhang at synopsys.com  Mon Dec 11 23:30:25 2023
From: Jianheng.Zhang at synopsys.com (Jianheng Zhang)
Date: Tue, 12 Dec 2023 07:30:25 +0000
Subject: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <20231211134008.lbtm6pjtufkhtvfj@skbuf>
References: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
 <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
 <20231211134008.lbtm6pjtufkhtvfj@skbuf>
Message-ID: <CY5PR12MB63726B47863B27B04CD01073BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com>

Hi Vladimir,

> -----Original Message-----
> From: Vladimir Oltean <olteanv at gmail.com>
> Sent: Monday, December 11, 2023 9:40 PM
> To: Jianheng Zhang <jianheng at synopsys.com>
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>; Jose Abreu <joabreu at synopsys.com>; David S.
> Miller <davem at davemloft.net>; Eric Dumazet <edumazet at google.com>; Jakub Kicinski
> <kuba at kernel.org>; Paolo Abeni <pabeni at redhat.com>; Maxime Coquelin
> <mcoquelin.stm32 at gmail.com>; open list:STMMAC ETHERNET DRIVER <netdev at vger.kernel.org>;
> moderated list:ARM/STM32 ARCHITECTURE <linux-stm32 at st-md-mailman.stormreply.com>;
> moderated list:ARM/STM32 ARCHITECTURE <linux-arm-kernel at lists.infradead.org>; open list
> <linux-kernel at vger.kernel.org>; James Li <lijames at synopsys.com>; Martin McKenny
> <mmckenny at synopsys.com>
> Subject: Re: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking support
> 
> Hi Jianheng,
> 
> On Mon, Dec 11, 2023 at 06:13:21AM +0000, Jianheng Zhang wrote:
> > Adds the HW specific support for Frame Preemption handshaking on XGMAC3+
> > cores.
> >
> > Signed-off-by: Jianheng Zhang <Jianheng.Zhang at synopsys.com>
> > ---
> 
> It's nice to see contributions from Synopsys!
> 
> Have you seen the (relatively newly introduced) common framework for
> Frame Preemption and the MAC Merge layer?
> https://urldefense.com/v3/__https://docs.kernel.org/networking/ethtool-netlink.html*mm-get__;Iw!!A
> 4F2R9G_pg!Z461fiVMBqXVlpgdD8t9ey1qGp6_hZg9jNlY__TljPgVHZcYbqtzqQhbI9IpjDoHBoOCX14vZOf2J
> hZgsW_fnQ$
> https://urldefense.com/v3/__https://man7.org/linux/man-pages/man8/ethtool.8.html__;!!A4F2R9G_pg
> !Z461fiVMBqXVlpgdD8t9ey1qGp6_hZg9jNlY__TljPgVHZcYbqtzqQhbI9IpjDoHBoOCX14vZOf2JhbkJXuqTA$
> https://urldefense.com/v3/__https://man7.org/linux/man-pages/man8/tc-mqprio.8.html__;!!A4F2R9G_
> pg!Z461fiVMBqXVlpgdD8t9ey1qGp6_hZg9jNlY__TljPgVHZcYbqtzqQhbI9IpjDoHBoOCX14vZOf2JhbEBQbq
> ZQ$  # "fp" option
> https://urldefense.com/v3/__https://man7.org/linux/man-pages/man8/tc-taprio.8.html__;!!A4F2R9G_p
> g!Z461fiVMBqXVlpgdD8t9ey1qGp6_hZg9jNlY__TljPgVHZcYbqtzqQhbI9IpjDoHBoOCX14vZOf2JhbOMeXO
> UQ$  # "fp" option
> 
> I think it would be valuable if the stmmac driver would also use it, so
> it could support openlldp and pass the selftest at
> https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/master/tools/testing/selftests/net/f
> orwarding/ethtool_mm.sh__;!!A4F2R9G_pg!Z461fiVMBqXVlpgdD8t9ey1qGp6_hZg9jNlY__TljPgVHZcYb
> qtzqQhbI9IpjDoHBoOCX14vZOf2JhasMiyt2w$

Thanks for mentioning the common framework for Frame Preemption and the MAC 
Merge layer. I think it is essential to let the stmmac driver support it next.
And it is also needed to avoid the code duplication mentioned by Serge.

Jianheng


From anshuman.khandual at arm.com  Mon Dec 11 23:31:26 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Tue, 12 Dec 2023 13:01:26 +0530
Subject: [PATCH V3 04/10] coresight: replicator: Move ACPI support from
 AMBA driver to platform driver
In-Reply-To: <6c3d9c5c-8185-bcdf-2897-0db13c00a843@arm.com>
References: <20231208053939.42901-1-anshuman.khandual@arm.com>
 <20231208053939.42901-5-anshuman.khandual@arm.com>
 <862afccb-e9c5-4fcb-abdf-45a5eb9aa6d8@arm.com>
 <6c3d9c5c-8185-bcdf-2897-0db13c00a843@arm.com>
Message-ID: <ffdd8a78-6cb2-4cfa-856b-6045b3084790@arm.com>



On 12/11/23 15:42, James Clark wrote:
> 
> 
> On 11/12/2023 07:51, Anshuman Khandual wrote:
>>
>>
>> On 12/8/23 11:09, Anshuman Khandual wrote:
>>> Add support for the dynamic replicator device in the platform driver, which
>>> can then be used on ACPI based platforms. This change would now allow
>>> runtime power management for repliacator devices on ACPI based systems.
>>>
>>> The driver would try to enable the APB clock if available. Also, rename the
>>> code to reflect the fact that it now handles both static and dynamic
>>> replicators.
>>>
>>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>>> Cc: Mike Leach <mike.leach at linaro.org>
>>> Cc: James Clark <james.clark at arm.com>
>>> Cc: linux-acpi at vger.kernel.org
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: linux-kernel at vger.kernel.org
>>> Cc: coresight at lists.linaro.org
>>> Tested-by: Sudeep Holla <sudeep.holla at arm.com> # Boot and driver probe only
>>> Acked-by: Sudeep Holla <sudeep.holla at arm.com> # For ACPI related changes
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>> ---
>>> Changes in V3:
>>>
>>> - Added commnets for 'drvdata->pclk'
>>> - Used coresight_init_driver()/coresight_remove_driver() helpers instead
>>> - Dropped pm_runtime_put() from replicator_probe()
>>> - Added pm_runtime_put() on success path in dynamic_replicator_probe()
>>> - Added pm_runtime_put() on success/error paths in
>>>   replicator_platform_probe()
>>>
>>>  drivers/acpi/arm64/amba.c                     |  1 -
>>>  .../coresight/coresight-replicator.c          | 81 ++++++++++---------
>>>  2 files changed, 42 insertions(+), 40 deletions(-)
>>>
>>> diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
>>> index 171b5c2c7edd..270f4e3819a2 100644
>>> --- a/drivers/acpi/arm64/amba.c
>>> +++ b/drivers/acpi/arm64/amba.c
>>> @@ -27,7 +27,6 @@ static const struct acpi_device_id amba_id_list[] = {
>>>  	{"ARMHC503", 0}, /* ARM CoreSight Debug */
>>>  	{"ARMHC979", 0}, /* ARM CoreSight TPIU */
>>>  	{"ARMHC97C", 0}, /* ARM CoreSight SoC-400 TMC, SoC-600 ETF/ETB */
>>> -	{"ARMHC98D", 0}, /* ARM CoreSight Dynamic Replicator */
>>>  	{"ARMHC9CA", 0}, /* ARM CoreSight CATU */
>>>  	{"ARMHC9FF", 0}, /* ARM CoreSight Dynamic Funnel */
>>>  	{"", 0},
>>> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
>>> index b6be73034996..125b256cb8db 100644
>>> --- a/drivers/hwtracing/coresight/coresight-replicator.c
>>> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
>>> @@ -31,6 +31,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>>>   * @base:	memory mapped base address for this component. Also indicates
>>>   *		whether this one is programmable or not.
>>>   * @atclk:	optional clock for the core parts of the replicator.
>>> + * @pclk:	APB clock if present, otherwise NULL
>>>   * @csdev:	component vitals needed by the framework
>>>   * @spinlock:	serialize enable/disable operations.
>>>   * @check_idfilter_val: check if the context is lost upon clock removal.
>>> @@ -38,6 +39,7 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
>>>  struct replicator_drvdata {
>>>  	void __iomem		*base;
>>>  	struct clk		*atclk;
>>> +	struct clk		*pclk;
>>>  	struct coresight_device	*csdev;
>>>  	spinlock_t		spinlock;
>>>  	bool			check_idfilter_val;
>>> @@ -243,6 +245,10 @@ static int replicator_probe(struct device *dev, struct resource *res)
>>>  			return ret;
>>>  	}
>>>  
>>> +	drvdata->pclk = coresight_get_enable_apb_pclk(dev);
>>> +	if (IS_ERR(drvdata->pclk))
>>> +		return -ENODEV;
>>> +
>>>  	/*
>>>  	 * Map the device base for dynamic-replicator, which has been
>>>  	 * validated by AMBA core
>>> @@ -285,7 +291,6 @@ static int replicator_probe(struct device *dev, struct resource *res)
>>>  	}
>>>  
>>>  	replicator_reset(drvdata);
>>> -	pm_runtime_put(dev);
>>>  
>>>  out_disable_clk:
>>>  	if (ret && !IS_ERR_OR_NULL(drvdata->atclk))
>>> @@ -301,29 +306,31 @@ static int replicator_remove(struct device *dev)
>>>  	return 0;
>>>  }
>>>  
>>> -static int static_replicator_probe(struct platform_device *pdev)
>>> +static int replicator_platform_probe(struct platform_device *pdev)
>>>  {
>>> +	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>  	int ret;
>>>  
>>>  	pm_runtime_get_noresume(&pdev->dev);
>>>  	pm_runtime_set_active(&pdev->dev);
>>>  	pm_runtime_enable(&pdev->dev);
>>>  
>>> -	/* Static replicators do not have programming base */
>>> -	ret = replicator_probe(&pdev->dev, NULL);
>>> -
>>> -	if (ret) {
>>> -		pm_runtime_put_noidle(&pdev->dev);
>>> -		pm_runtime_disable(&pdev->dev);
>>> -	}
>>> +	ret = replicator_probe(&pdev->dev, res);
>>> +	pm_runtime_put(&pdev->dev);
>>
>> I believe pm_runtime_disable() would still be needed on the error path. Otherwise
>> pm_runtime_enable() will remain unbalanced on this error path when the replicator
>> module could not be loaded.
>>
>> --- a/drivers/hwtracing/coresight/coresight-replicator.c
>> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
>> @@ -317,6 +317,8 @@ static int replicator_platform_probe(struct platform_device *pdev)
>>  
>>         ret = replicator_probe(&pdev->dev, res);
>>         pm_runtime_put(&pdev->dev);
>> +       if (ret)
>> +               pm_runtime_disable(&pdev->dev);
>>  
>>         return ret;
>>  }
>>
>> Similar constructs in this error path are also required in all other drivers (except
>> cpu debug) as well.
> 
> Would that not need to be done as a fixes commit first with more detail
> about the issue if that's true? Maybe simulate the error and paste any
> error logs. For example etm4 already has this:

There are existing inconsistencies e.g between etm4 and replicator regarding
whether pm_runtime_disable() is called or not. So the idea here was to get
all remaining devices in line with replicator and debug devices method.

I don't have continuous access to an ACPI based coresight platform, creating
some challenges - although still trying to get access to such a system. But
wondering - it might be possible to simulate these success and error paths,
without having real ACPI based coresight platform devices.

> 
>   	pm_runtime_get_noresume(&pdev->dev);
> 	pm_runtime_set_active(&pdev->dev);
> 	pm_runtime_enable(&pdev->dev);
> 
> 	ret = etm4_probe(&pdev->dev);
> 
> 	pm_runtime_put(&pdev->dev);
> 
> I'm wondering if the disable is already covered by the platform code if
> the probe fails so no change is required?

AFAICT pm_runtime_enable()/pm_runtime_disable() goes in a pair for them to
remain balanced, there is a increasing/decreasing counter to ensure such a
balance is established and so without a corresponding pm_runtime_disable()
above etm4 path looks problematic. I guess this might just need fixing, as
a pre-requisite.

> 
> 	if (drv->probe) {
> 		ret = drv->probe(dev);
> 		if (ret)
> 			dev_pm_domain_detach(_dev, true);
> 	}


From hch at infradead.org  Mon Dec 11 23:41:25 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 11 Dec 2023 23:41:25 -0800
Subject: [PATCH v7 3/3] check-module-params: Introduce
 check-module-params.sh
In-Reply-To: <20231212020259.2451253-4-quic_johmoo@quicinc.com>
References: <20231212020259.2451253-1-quic_johmoo@quicinc.com>
 <20231212020259.2451253-4-quic_johmoo@quicinc.com>
Message-ID: <ZXgOpRzNYGtiE35T@infradead.org>

On Mon, Dec 11, 2023 at 06:02:59PM -0800, John Moon wrote:
> One part of maintaining backwards compatibility with older
> userspace programs is avoiding changes to module parameters.

Really?  I don't think module parameters are a UAPI in the traditional
sense.  Now if you break a heavily used one you got to fix it, but
applying strict stability guarantees on module options which are not
availble to normal users or even normal programs doesn't make a whole
lot of sense.



From oliver.upton at linux.dev  Mon Dec 11 23:45:36 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Tue, 12 Dec 2023 07:45:36 +0000
Subject: [PATCH 0/5] KVM: arm64: vgic fixes for 6.7
In-Reply-To: <20231207151201.3028710-1-maz@kernel.org>
References: <20231207151201.3028710-1-maz@kernel.org>
Message-ID: <170236713184.438197.11882636144565219983.b4-ty@linux.dev>

On Thu, 7 Dec 2023 15:11:56 +0000, Marc Zyngier wrote:
> It appears that under some cirumstances, the lifetime of a vcpu
> doesn't correctly align with that of the structure describing the
> redistributor associated with that vcpu. That's not great.
> 
> Fixing it is, unfortunately, not as trivial as it appears as the
> required locking gets in the way.
> 
> [...]

Applied to kvmarm/fixes, thanks!

[1/5] KVM: arm64: vgic: Simplify kvm_vgic_destroy()
      https://git.kernel.org/kvmarm/kvmarm/c/01ad29d224ff
[2/5] KVM: arm64: vgic: Add a non-locking primitive for kvm_vgic_vcpu_destroy()
      https://git.kernel.org/kvmarm/kvmarm/c/d26b9cb33c2d
[3/5] KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy
      https://git.kernel.org/kvmarm/kvmarm/c/02e3858f08fa
[4/5] KVM: arm64: vgic: Ensure that slots_lock is held in vgic_register_all_redist_iodevs()
      https://git.kernel.org/kvmarm/kvmarm/c/6bef365e310a
[5/5] KVM: Convert comment into an assertion in kvm_io_bus_register_dev()
      https://git.kernel.org/kvmarm/kvmarm/c/b1a39a718db4

--
Best,
Oliver


From dsimic at manjaro.org  Mon Dec 11 23:53:51 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 08:53:51 +0100
Subject: [PATCH 4/4] arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for PX30
In-Reply-To: <cover.1702366958.git.dsimic@manjaro.org>
References: <cover.1702366958.git.dsimic@manjaro.org>
Message-ID: <0d9da8959b4f567622676c34b5feb74c49489554.1702366958.git.dsimic@manjaro.org>

Not all supported boards actually use the PX30's built-in (G)MAC, while the
SoC TRM and the datasheet don't define some standard numbering in this case.
Thus, remove the ethernet0 alias from the PX30 SoC dtsi file, and add the same
alias back to the appropriate board dts(i) files.

This is quite similar to the already performed migration of the mmcX aliases
from the Rockchip SoC dtsi files to the board dts(i) files.

Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi | 1 +
 arch/arm64/boot/dts/rockchip/px30-evb.dts             | 1 +
 arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts | 1 +
 arch/arm64/boot/dts/rockchip/px30.dtsi                | 1 -
 4 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi b/arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi
index 3429e124d95a..5b4e22385165 100644
--- a/arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi
@@ -7,6 +7,7 @@
 
 / {
 	aliases {
+		ethernet0 = &gmac;
 		mmc1 = &sdmmc;
 		mmc2 = &sdio;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/px30-evb.dts b/arch/arm64/boot/dts/rockchip/px30-evb.dts
index c1bbd555f5f5..0a90a88fc664 100644
--- a/arch/arm64/boot/dts/rockchip/px30-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/px30-evb.dts
@@ -14,6 +14,7 @@ / {
 	compatible = "rockchip,px30-evb", "rockchip,px30";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdmmc;
 		mmc1 = &sdio;
 		mmc2 = &emmc;
diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts
index 7d4c5324c61b..16798eb77077 100644
--- a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts
+++ b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts
@@ -13,6 +13,7 @@ / {
 	compatible = "tsd,px30-ringneck-haikou", "rockchip,px30";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc2 = &sdmmc;
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 42ce78beb413..d0905515399b 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -20,7 +20,6 @@ / {
 	#size-cells = <2>;
 
 	aliases {
-		ethernet0 = &gmac;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;


From dsimic at manjaro.org  Mon Dec 11 23:53:47 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 08:53:47 +0100
Subject: [PATCH 0/4] Remove ethernetX aliases from the SoC dtsi for RK3399, RK3368, RK3328 and PX30
Message-ID: <cover.1702366958.git.dsimic@manjaro.org>

Unlike for the I2C buses, GPIO lines and UARTs, the Rockchip SoC TRMs and
datasheets define no numbering for the built-in GMAC(s) or MAC(s), if there
are more than one found in the particular Rockchip SoC.

Moreover, not all boards or devices based on these SoCs actually use the
built-in GMAC(s) or MAC(s).  Thus, let's remove the ethernetX aliases from
the SoC dtsi files and add them back to the appropriate board and device
dts(i) files.  See also [1] for the initial discussion.

This is quite similar to the already performed migration of the mmcX aliases
from the Rockchip SoC dtsi files to the board dts(i) files.

The correctness of the patches in this series was verified by comparing the
contents of the compiled dtb files before and after applying the patches.
All of the affected dtb files checked out fine.

[1] https://lore.kernel.org/linux-rockchip/5119280.687JKscXgg at diego/T/#u

Dragan Simic (4):
  arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for
    RK3399
  arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for
    RK3368
  arm64: dts: rockchip: Remove ethernetX aliases from the SoC dtsi for
    RK3328
  arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for
    PX30

 arch/arm64/boot/dts/rockchip/px30-engicam-common.dtsi       | 1 +
 arch/arm64/boot/dts/rockchip/px30-evb.dts                   | 1 +
 arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts       | 1 +
 arch/arm64/boot/dts/rockchip/px30.dtsi                      | 1 -
 arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts             | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-a1.dts                  | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-evb.dts                 | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts          | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts    | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts              | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts           | 2 ++
 arch/arm64/boot/dts/rockchip/rk3328-rock64.dts              | 1 +
 arch/arm64/boot/dts/rockchip/rk3328.dtsi                    | 2 --
 arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi                | 1 +
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts             | 1 +
 arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi               | 1 +
 arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts      | 1 +
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts                 | 1 +
 arch/arm64/boot/dts/rockchip/rk3368.dtsi                    | 1 -
 arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts           | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts                 | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-ficus.dts               | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts             | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts          | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts       | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts      | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts           | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi            | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts            | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi               | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi             | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts        | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi          | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi          | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi           | 1 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi                    | 1 -
 arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi       | 1 +
 38 files changed, 44 insertions(+), 5 deletions(-)



From dsimic at manjaro.org  Mon Dec 11 23:53:50 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 08:53:50 +0100
Subject: [PATCH 3/4] arm64: dts: rockchip: Remove ethernetX aliases from the SoC dtsi for RK3328
In-Reply-To: <cover.1702366958.git.dsimic@manjaro.org>
References: <cover.1702366958.git.dsimic@manjaro.org>
Message-ID: <0c14f2e354d32f5d45c718ce16643553ca72f6a5.1702366958.git.dsimic@manjaro.org>

Not all supported boards actually use the RK3328's built-in GMACs, while the
SoC TRM and the datasheet don't define some standard numbering in this case.
Thus, remove the ethernet0 and ethernet1 aliases from the RK3328 SoC dtsi file,
and add the same alias back to the appropriate board dts(i) files.

These changes also touch one RK3318-based board dts, because it actually
depends on the RK3328 SoC dtsi and enables one of the GMACs.

This is quite similar to the already performed migration of the mmcX aliases
from the Rockchip SoC dtsi files to the board dts(i) files.

Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts          | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-a1.dts               | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-evb.dts              | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts       | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts           | 1 +
 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts        | 2 ++
 arch/arm64/boot/dts/rockchip/rk3328-rock64.dts           | 1 +
 arch/arm64/boot/dts/rockchip/rk3328.dtsi                 | 2 --
 9 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts b/arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts
index 1deef53a4c94..c7b1862fca6a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts
@@ -9,6 +9,7 @@ / {
 	compatible = "zkmagic,a95x-z2", "rockchip,rk3318";
 
 	aliases {
+		ethernet0 = &gmac2phy;
 		mmc0 = &sdmmc;
 		mmc1 = &sdio;
 		mmc2 = &emmc;
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-a1.dts b/arch/arm64/boot/dts/rockchip/rk3328-a1.dts
index 40bf808642b9..824183e515da 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-a1.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-a1.dts
@@ -9,6 +9,7 @@ / {
 	compatible = "azw,beelink-a1", "rockchip,rk3328";
 
 	aliases {
+		ethernet0 = &gmac2io;
 		mmc0 = &sdmmc;
 		mmc1 = &emmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index ff6b466e0e07..1eef5504445f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -11,6 +11,7 @@ / {
 	compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
 
 	aliases {
+		ethernet0 = &gmac2phy;
 		mmc0 = &sdmmc;
 		mmc1 = &sdio;
 		mmc2 = &emmc;
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
index 1445b879ac7a..a4399da7d8b1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
@@ -14,6 +14,7 @@ / {
 	compatible = "friendlyarm,nanopi-r2s", "rockchip,rk3328";
 
 	aliases {
+		ethernet0 = &gmac2io;
 		ethernet1 = &rtl8153;
 		mmc0 = &sdmmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts
index dc83d74045a3..f20662929c77 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus.dts
@@ -15,6 +15,7 @@ / {
 	compatible = "xunlong,orangepi-r1-plus", "rockchip,rk3328";
 
 	aliases {
+		ethernet0 = &gmac2io;
 		ethernet1 = &rtl8153;
 		mmc0 = &sdmmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 5d5d9574088c..414897a57e75 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -11,6 +11,7 @@ / {
 	compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
 
 	aliases {
+		ethernet0 = &gmac2io;
 		mmc0 = &sdmmc;
 		mmc1 = &emmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
index 018a3a5075c7..07f00af19aaf 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -21,6 +21,8 @@ / {
 	compatible = "radxa,rockpi-e", "rockchip,rk3328";
 
 	aliases {
+		ethernet0 = &gmac2io;
+		ethernet1 = &gmac2phy;
 		mmc0 = &sdmmc;
 		mmc1 = &emmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 0a27fa5271f5..229fe9da9c2d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -11,6 +11,7 @@ / {
 	compatible = "pine64,rock64", "rockchip,rk3328";
 
 	aliases {
+		ethernet0 = &gmac2io;
 		mmc0 = &sdmmc;
 		mmc1 = &emmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index cc8209795c3e..41433d3340ce 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -27,8 +27,6 @@ aliases {
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
 		i2c3 = &i2c3;
-		ethernet0 = &gmac2io;
-		ethernet1 = &gmac2phy;
 	};
 
 	cpus {


From dsimic at manjaro.org  Mon Dec 11 23:53:49 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 08:53:49 +0100
Subject: [PATCH 2/4] arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for RK3368
In-Reply-To: <cover.1702366958.git.dsimic@manjaro.org>
References: <cover.1702366958.git.dsimic@manjaro.org>
Message-ID: <77115184d633190c917d868f883070e100d93dbc.1702366958.git.dsimic@manjaro.org>

Not all supported boards actually use the RK3368's built-in GMAC, while the
SoC TRM and the datasheet don't define some standard numbering in this case.
Thus, remove the ethernet0 alias from the RK3368 SoC dtsi file, and add the
same alias back to the appropriate board dts(i) files.

This is quite similar to the already performed migration of the mmcX aliases
from the Rockchip SoC dtsi files to the board dts(i) files.

Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi           | 1 +
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts        | 1 +
 arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi          | 1 +
 arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts | 1 +
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts            | 1 +
 arch/arm64/boot/dts/rockchip/rk3368.dtsi               | 1 -
 6 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
index e47d1398aeca..b48b98c13705 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
@@ -9,6 +9,7 @@
 
 / {
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &emmc;
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
index be06e6e64d18..029b8e22e709 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -12,6 +12,7 @@ / {
 	compatible = "geekbuying,geekbox", "rockchip,rk3368";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &emmc;
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi b/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
index 5753e57fd716..8ac8acf4082d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi
@@ -8,6 +8,7 @@
 
 / {
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &emmc;
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
index 81d1064fdb21..dcee2e28916f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
@@ -12,6 +12,7 @@ / {
 	compatible = "tronsmart,orion-r68-meta", "rockchip,rk3368";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdmmc;
 		mmc1 = &emmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
index 5589f3db6b36..b16b7ca02379 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
@@ -12,6 +12,7 @@ / {
 	compatible = "rockchip,r88", "rockchip,rk3368";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdio0;
 		mmc1 = &emmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index a4c5aaf1f457..7b8c416aa890 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -19,7 +19,6 @@ / {
 	#size-cells = <2>;
 
 	aliases {
-		ethernet0 = &gmac;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;


From dsimic at manjaro.org  Mon Dec 11 23:53:48 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 08:53:48 +0100
Subject: [PATCH 1/4] arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for RK3399
In-Reply-To: <cover.1702366958.git.dsimic@manjaro.org>
References: <cover.1702366958.git.dsimic@manjaro.org>
Message-ID: <20879826c01fb9ead71c339866846ea794669802.1702366958.git.dsimic@manjaro.org>

Not all supported boards actually use the RK3399's built-in GMAC, while the
SoC TRM and the datasheet don't define some standard numbering in this case.
Thus, remove the ethernet0 alias from the RK3399 SoC dtsi file, and add the
same alias back to the appropriate board dts(i) files.

This is quite similar to the already performed migration of the mmcX aliases
from the Rockchip SoC dtsi files to the board dts(i) files.

Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts           | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts                 | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-ficus.dts               | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts             | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts          | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts       | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts      | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts           | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi            | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts            | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi               | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi             | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts        | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi          | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi          | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi           | 1 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi                    | 1 -
 arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi       | 1 +
 19 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts b/arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts
index 6464ef4d113d..173da81fc231 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts
@@ -15,6 +15,7 @@ / {
 	compatible = "openailab,eaidk-610", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdio0;
 		mmc1 = &sdmmc;
 		mmc2 = &sdhci;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index 3d1e126b553f..55eca7a50a1f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -12,6 +12,7 @@ / {
 	compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdhci;
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
index 1ce85a5816e4..30e4879f322c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
@@ -13,6 +13,10 @@ / {
 	model = "96boards RK3399 Ficus";
 	compatible = "vamrs,ficus", "rockchip,rk3399";
 
+	aliases {
+		ethernet0 = &gmac;
+	};
+
 	chosen {
 		stdout-path = "serial2:1500000n8";
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index c5db64f3e124..260415d99aeb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -16,6 +16,7 @@ / {
 	compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdio0;
 		mmc1 = &sdmmc;
 		mmc2 = &sdhci;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
index 7af27e8216f1..4a6ab6c2e24c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
@@ -11,6 +11,7 @@ / {
 	compatible = "hugsun,x99", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdio0;
 		mmc1 = &sdmmc;
 		mmc2 = &sdhci;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts
index 8302e51def52..99ac4ed0f13f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dts
@@ -10,6 +10,10 @@
 / {
 	model = "Khadas Edge-Captain";
 	compatible = "khadas,edge-captain", "rockchip,rk3399";
+
+	aliases {
+		ethernet0 = &gmac;
+	};
 };
 
 &gmac {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts
index f5dcb99dc349..e12e7b4d64ca 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dts
@@ -10,6 +10,10 @@
 / {
 	model = "Khadas Edge-V";
 	compatible = "khadas,edge-v", "rockchip,rk3399";
+
+	aliases {
+		ethernet0 = &gmac;
+	};
 };
 
 &gmac {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
index 1eb287a3f8c0..9e3aec4440bd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
@@ -19,6 +19,7 @@ / {
 	compatible = "kobol,helios64", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdmmc;
 		mmc1 = &sdhci;
 		spi1 = &spi1;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
index a21ac319f809..cb69e2145fa9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
@@ -15,6 +15,7 @@ / {
 	compatible = "leez,p710", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdio0;
 		mmc1 = &sdmmc;
 		mmc2 = &sdhci;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 7c5f441a2219..b7f1e47978a6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -18,6 +18,7 @@
 
 / {
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdio0;
 		mmc1 = &sdmmc;
 		mmc2 = &sdhci;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
index dba4d03bfc2b..e7551449e718 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
@@ -17,6 +17,7 @@ / {
 	compatible = "rockchip,rk3399-orangepi", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdio0;
 		mmc1 = &sdmmc;
 		mmc2 = &sdhci;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 20e3f41efe97..574a775ca880 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -9,6 +9,7 @@
 
 / {
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdhci;
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
index c32913df93c3..ca7a446b6568 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
@@ -14,6 +14,7 @@ / {
 	compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdmmc;
 		mmc1 = &sdhci;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
index 8bfd5f88d1ef..7baf9d1b22fd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-4c-plus.dts
@@ -15,6 +15,7 @@ / {
 	compatible = "radxa,rock-4c-plus", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
index f2279aa6ca9e..281a12180703 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
@@ -12,6 +12,7 @@
 
 / {
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
index bca2b50e0a93..f30b82a10ca3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
@@ -11,6 +11,7 @@
 
 / {
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdio0;
 		mmc1 = &sdmmc;
 		mmc2 = &sdhci;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index e6ac292ce645..26c41f1e9adb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -12,6 +12,7 @@ / {
 	compatible = "rockchip,rk3399-sapphire", "rockchip,rk3399";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdmmc;
 		mmc1 = &sdhci;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index da0dfb237f85..cf653246d5b7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -19,7 +19,6 @@ / {
 	#size-cells = <2>;
 
 	aliases {
-		ethernet0 = &gmac;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi b/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi
index 8b8992a8e9c0..8823c924dc1d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi
@@ -13,6 +13,7 @@ / {
 	compatible = "vamrs,rk3399pro-vmarc-som", "rockchip,rk3399pro";
 
 	aliases {
+		ethernet0 = &gmac;
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 	};


From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:50 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:50 +0800
Subject: [PATCH 01/11] ARM: dts: aspeed: minerva: Revise the name of DTS
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-2-yangchen.openbmc@gmail.com>

The project Minerva which is the platform used by Meta has two boards: the
Chassis Management Module (Minerva) and the Motherboard (Harma), so change
the DTS name to minerva here for CMM use.

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 arch/arm/boot/dts/aspeed/Makefile                               | 2 +-
 ...facebook-minerva-cmc.dts => aspeed-bmc-facebook-minerva.dts} | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename arch/arm/boot/dts/aspeed/{aspeed-bmc-facebook-minerva-cmc.dts => aspeed-bmc-facebook-minerva.dts} (99%)

diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index d3ac20e316d0..b1da302dbcd6 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -19,7 +19,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-facebook-fuji.dtb \
 	aspeed-bmc-facebook-galaxy100.dtb \
 	aspeed-bmc-facebook-greatlakes.dtb \
-	aspeed-bmc-facebook-minerva-cmc.dtb \
+	aspeed-bmc-facebook-minerva.dtb \
 	aspeed-bmc-facebook-minipack.dtb \
 	aspeed-bmc-facebook-tiogapass.dtb \
 	aspeed-bmc-facebook-wedge40.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva-cmc.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
similarity index 99%
rename from arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva-cmc.dts
rename to arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index f04ef9063520..c755fb3258a4 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva-cmc.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -7,7 +7,7 @@
 #include <dt-bindings/i2c/i2c.h>
 
 / {
-	model = "Facebook Minerva CMC";
+	model = "Facebook Minerva CMM";
 	compatible = "facebook,minerva-cmc", "aspeed,ast2600";
 
 	aliases {
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:49 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:49 +0800
Subject: [PATCH 00/11] Modify DTS of META Minerva CMM BMC(AST2600)
Message-ID: <20231212075200.983536-1-yangchen.openbmc@gmail.com>

This series modifies the DTS of the Minerva CMM which is the board on the
META platform that uses the ASPEED SoC(AST2600).

Changelog:
- v1:
    - Rename the name of the DTS from aspeed-bmc-facebook-minerva-cmc.dts
      to aspeed-bmc-facebook-minerva.dts.
    - Revise the setting of the mac3.
    - Change the sgpio use from sgpiom1 to sgpiom0.
    - Enable power monitor device (INA230 and LTC2945) on the i2c bus 0.
    - Add one temperature sensor on the i2c bus 1.
    - Correct the address of the eeprom on the i2c bus 1.
    - Add bus labels and aliases for the Fan Controller Board connect to
      the i2c-mux on the i2c bus 2.
    - Add led of the fan for the fan fault.
    - Name the gpio and the sgpio.

Yang Chen (11):
  ARM: dts: aspeed: minerva: Revise the name of DTS
  ARM: dts: aspeed: minerva: Modify mac3 setting
  ARM: dts: aspeed: minerva: Change sgpio use
  ARM: dts: aspeed: minerva: Enable power monitor device
  ARM: dts: aspeed: minerva: Add temperature sensor
  ARM: dts: aspeed: minerva: correct the address of eeprom
  ARM: dts: aspeed: minerva: add bus labels and aliases
  ARM: dts: aspeed: minerva: add fan rpm controller
  ARM: dts: aspeed: minerva: Add led-fan-fault gpio
  ARM: dts: aspeed: minerva: add gpio line name
  ARM: dts: aspeed: minerva: add sgpio line name

 arch/arm/boot/dts/aspeed/Makefile             |   2 +-
 .../aspeed-bmc-facebook-minerva-cmc.dts       | 265 ---------
 .../aspeed/aspeed-bmc-facebook-minerva.dts    | 543 ++++++++++++++++++
 3 files changed, 544 insertions(+), 266 deletions(-)
 delete mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva-cmc.dts
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts

-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:51 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:51 +0800
Subject: [PATCH 02/11] ARM: dts: aspeed: minerva: Modify mac3 setting
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-3-yangchen.openbmc@gmail.com>

Remove the unuse setting and fix the link to 100 M

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index c755fb3258a4..9979dba1ef0e 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -48,10 +48,13 @@ &wdt1 {
 
 &mac3 {
 	status = "okay";
+	phy-mode = "rmii";
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_rmii4_default>;
-	use-ncsi;
-	mlx,multi-host;
+	fixed-link {
+		speed = <100>;
+		full-duplex;
+	};
 };
 
 &fmc {
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:52 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:52 +0800
Subject: [PATCH 03/11] ARM: dts: aspeed: minerva: Change sgpio use
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-4-yangchen.openbmc@gmail.com>

Correct the sgpio use from sgpiom1 to sgpiom0

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index 9979dba1ef0e..ad77057f921c 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -78,7 +78,7 @@ &rtc {
 	status = "okay";
 };
 
-&sgpiom1 {
+&sgpiom0 {
 	status = "okay";
 	ngpios = <128>;
 	bus-frequency = <2000000>;
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:53 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:53 +0800
Subject: [PATCH 04/11] ARM: dts: aspeed: minerva: Enable power monitor device
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-5-yangchen.openbmc@gmail.com>

Enable power monitor device ina230 and ltc2945 on the i2c bus 0

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 .../aspeed/aspeed-bmc-facebook-minerva.dts    | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index ad77057f921c..ee9691647e4a 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -86,6 +86,28 @@ &sgpiom0 {
 
 &i2c0 {
 	status = "okay";
+
+	power-monitor at 40 {
+		compatible = "ti,ina230";
+		reg = <0x40>;
+		shunt-resistor = <1000>;
+	};
+
+	power-monitor at 41 {
+		compatible = "ti,ina230";
+		reg = <0x41>;
+		shunt-resistor = <1000>;
+	};
+
+	power-monitor at 67 {
+		compatible = "adi,ltc2945";
+		reg = <0x67>;
+	};
+
+	power-monitor at 68 {
+		compatible = "adi,ltc2945";
+		reg = <0x68>;
+	};
 };
 
 &i2c1 {
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:54 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:54 +0800
Subject: [PATCH 05/11] ARM: dts: aspeed: minerva: Add temperature sensor
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-6-yangchen.openbmc@gmail.com>

Add one temperature sensor on i2c bus 1

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index ee9691647e4a..783d4d5a8f3d 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -115,7 +115,12 @@ &i2c1 {
 
 	temperature-sensor at 4b {
 		compatible = "ti,tmp75";
-		reg = <0x4B>;
+		reg = <0x4b>;
+	};
+
+	temperature-sensor at 48 {
+		compatible = "ti,tmp75";
+		reg = <0x48>;
 	};
 
 	eeprom at 51 {
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:55 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:55 +0800
Subject: [PATCH 06/11] ARM: dts: aspeed: minerva: correct the address of eeprom
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-7-yangchen.openbmc@gmail.com>

Correct the address from 0x51 to 0x54 of eeprom on the i2c bus 1

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index 783d4d5a8f3d..f2a48033ac5c 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -123,9 +123,9 @@ temperature-sensor at 48 {
 		reg = <0x48>;
 	};
 
-	eeprom at 51 {
+	eeprom at 54 {
 		compatible = "atmel,24c128";
-		reg = <0x51>;
+		reg = <0x54>;
 	};
 };
 
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:56 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:56 +0800
Subject: [PATCH 07/11] ARM: dts: aspeed: minerva: add bus labels and aliases
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-8-yangchen.openbmc@gmail.com>

Add bus labels and aliases for the fan control board.

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 .../aspeed/aspeed-bmc-facebook-minerva.dts    | 22 ++++++++++++++-----
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index f2a48033ac5c..f4cb5ef72310 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -12,6 +12,16 @@ / {
 
 	aliases {
 		serial5 = &uart5;
+		/*
+		 * PCA9548 (2-0077) provides 8 channels connecting to
+		 * 6 pcs of FCB (Fan Controller Board).
+		 */
+		i2c16 = &imux16;
+		i2c17 = &imux17;
+		i2c18 = &imux18;
+		i2c19 = &imux19;
+		i2c20 = &imux20;
+		i2c21 = &imux21;
 	};
 
 	chosen {
@@ -139,7 +149,7 @@ i2c-mux at 77 {
 		#size-cells = <0>;
 		i2c-mux-idle-disconnect;
 
-		i2c at 0 {
+		imux16: i2c at 0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
@@ -150,7 +160,7 @@ eeprom at 50 {
 			};
 		};
 
-		i2c at 1 {
+		imux17: i2c at 1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <1>;
@@ -161,7 +171,7 @@ eeprom at 50 {
 			};
 		};
 
-		i2c at 2 {
+		imux18: i2c at 2 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <2>;
@@ -172,7 +182,7 @@ eeprom at 50 {
 			};
 		};
 
-		i2c at 3 {
+		imux19: i2c at 3 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <3>;
@@ -183,7 +193,7 @@ eeprom at 50 {
 			};
 		};
 
-		i2c at 4 {
+		imux20: i2c at 4 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <4>;
@@ -194,7 +204,7 @@ eeprom at 50 {
 			};
 		};
 
-		i2c at 5 {
+		imux21: i2c at 5 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <5>;
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:57 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:57 +0800
Subject: [PATCH 08/11] ARM: dts: aspeed: minerva: add fan rpm controller
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-9-yangchen.openbmc@gmail.com>

Add fan rpm controller max31790 on all bus of FCB.

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 .../aspeed/aspeed-bmc-facebook-minerva.dts    | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index f4cb5ef72310..c7445c819baf 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -158,6 +158,13 @@ eeprom at 50 {
 				compatible = "atmel,24c128";
 				reg = <0x50>;
 			};
+
+			pwm at 5e{
+				compatible = "max31790";
+				reg = <0x5e>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
 		};
 
 		imux17: i2c at 1 {
@@ -169,6 +176,13 @@ eeprom at 50 {
 				compatible = "atmel,24c128";
 				reg = <0x50>;
 			};
+
+			pwm at 5e{
+				compatible = "max31790";
+				reg = <0x5e>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
 		};
 
 		imux18: i2c at 2 {
@@ -180,6 +194,13 @@ eeprom at 50 {
 				compatible = "atmel,24c128";
 				reg = <0x50>;
 			};
+
+			pwm at 5e{
+				compatible = "max31790";
+				reg = <0x5e>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
 		};
 
 		imux19: i2c at 3 {
@@ -191,6 +212,13 @@ eeprom at 50 {
 				compatible = "atmel,24c128";
 				reg = <0x50>;
 			};
+
+			pwm at 5e{
+				compatible = "max31790";
+				reg = <0x5e>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
 		};
 
 		imux20: i2c at 4 {
@@ -202,6 +230,13 @@ eeprom at 50 {
 				compatible = "atmel,24c128";
 				reg = <0x50>;
 			};
+
+			pwm at 5e{
+				compatible = "max31790";
+				reg = <0x5e>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
 		};
 
 		imux21: i2c at 5 {
@@ -213,6 +248,13 @@ eeprom at 50 {
 				compatible = "atmel,24c128";
 				reg = <0x50>;
 			};
+
+			pwm at 5e{
+				compatible = "max31790";
+				reg = <0x5e>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
 		};
 	};
 };
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:58 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:58 +0800
Subject: [PATCH 09/11] ARM: dts: aspeed: minerva: Add led-fan-fault gpio
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-10-yangchen.openbmc@gmail.com>

Add led-fan-fault gpio pin on the PCA9555 on the i2c bus 0.

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 .../dts/aspeed/aspeed-bmc-facebook-minerva.dts  | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index c7445c819baf..090fe2f6b1d8 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -39,6 +39,16 @@ iio-hwmon {
 			<&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
 			<&adc1 2>;
 	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-fan-fault {
+			label = "led-fan-fault";
+			gpios = <&leds_gpio 9 GPIO_ACTIVE_HIGH>;
+			default-state = "off";
+		};
+	};
 };
 
 &uart6 {
@@ -118,6 +128,13 @@ power-monitor at 68 {
 		compatible = "adi,ltc2945";
 		reg = <0x68>;
 	};
+
+	leds_gpio: gpio at 19 {
+		compatible = "nxp,pca9555";
+		reg = <0x19>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
 
 &i2c1 {
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:51:59 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:51:59 +0800
Subject: [PATCH 10/11] ARM: dts: aspeed: minerva: add gpio line name
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-11-yangchen.openbmc@gmail.com>

Add the GPIO line name that the project's function can use by the
meaningful name.

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 .../aspeed/aspeed-bmc-facebook-minerva.dts    | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index 090fe2f6b1d8..31197183cc59 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -362,3 +362,33 @@ &ehci1 {
 &uhci {
 	status = "okay";
 };
+
+&gpio0 {
+	gpio-line-names =
+	/*A0-A7*/	"","","","","","","","",
+	/*B0-B7*/	"","","","","","","","",
+	/*C0-C7*/	"","","","","BLADE_UART_SEL2","","","",
+	/*D0-D7*/	"","","","","","","","",
+	/*E0-E7*/	"","","","","","","","",
+	/*F0-F7*/	"","","","","","","","",
+	/*G0-G7*/	"","","","","","","","",
+	/*H0-H7*/	"","","","","","","","",
+	/*I0-I7*/	"","","","","","","","",
+	/*J0-J7*/	"","","","","","","","",
+	/*K0-K7*/	"","","","","","","","",
+	/*L0-L7*/	"","","","","BLADE_UART_SEL0","","","",
+	/*M0-M7*/	"","","","","","BLADE_UART_SEL1","","",
+	/*N0-N7*/	"","","","","","","","",
+	/*O0-O7*/	"","","","","","","","",
+	/*P0-P7*/	"","","","","","","","",
+	/*Q0-Q7*/	"","","","","","","","",
+	/*R0-R7*/	"","","","","","","","",
+	/*S0-S7*/	"","","","","","","","",
+	/*T0-T7*/	"","","","","","","","",
+	/*U0-U7*/	"","","","","","","","",
+	/*V0-V7*/	"","","","","BAT_DETECT","","","",
+	/*W0-W7*/	"","","","","","","","",
+	/*X0-X7*/	"","","BLADE_UART_SEL3","","","","","",
+	/*Y0-Y7*/	"","","","","","","","",
+	/*Z0-Z7*/	"","","","","","","","";
+};
-- 
2.34.1



From yangchen.openbmc at gmail.com  Mon Dec 11 23:52:00 2023
From: yangchen.openbmc at gmail.com (Yang Chen)
Date: Tue, 12 Dec 2023 15:52:00 +0800
Subject: [PATCH 11/11] ARM: dts: aspeed: minerva: add sgpio line name
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <20231212075200.983536-12-yangchen.openbmc@gmail.com>

Add the SGPIO line name that the project's function can use by the
meaningful name.

Signed-off-by: Yang Chen <yangchen.openbmc at gmail.com>
---
 .../aspeed/aspeed-bmc-facebook-minerva.dts    | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
index 31197183cc59..942e53d5c714 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minerva.dts
@@ -392,3 +392,152 @@ &gpio0 {
 	/*Y0-Y7*/	"","","","","","","","",
 	/*Z0-Z7*/	"","","","","","","","";
 };
+
+&sgpiom0 {
+	gpio-line-names =
+	/*"input pin","output pin"*/
+	/*A0 - A7*/
+	"PRSNT_MTIA_BLADE0_N","PWREN_MTIA_BLADE0_EN",
+	"PRSNT_MTIA_BLADE1_N","PWREN_MTIA_BLADE1_EN",
+	"PRSNT_MTIA_BLADE2_N","PWREN_MTIA_BLADE2_EN",
+	"PRSNT_MTIA_BLADE3_N","PWREN_MTIA_BLADE3_EN",
+	"PRSNT_MTIA_BLADE4_N","PWREN_MTIA_BLADE4_EN",
+	"PRSNT_MTIA_BLADE5_N","PWREN_MTIA_BLADE5_EN",
+	"PRSNT_MTIA_BLADE6_N","PWREN_MTIA_BLADE6_EN",
+	"PRSNT_MTIA_BLADE7_N","PWREN_MTIA_BLADE7_EN",
+	/*B0 - B7*/
+	"PRSNT_MTIA_BLADE8_N","PWREN_MTIA_BLADE8_EN",
+	"PRSNT_MTIA_BLADE9_N","PWREN_MTIA_BLADE9_EN",
+	"PRSNT_MTIA_BLADE10_N","PWREN_MTIA_BLADE10_EN",
+	"PRSNT_MTIA_BLADE11_N","PWREN_MTIA_BLADE11_EN",
+	"PRSNT_MTIA_BLADE12_N","PWREN_MTIA_BLADE12_EN",
+	"PRSNT_MTIA_BLADE13_N","PWREN_MTIA_BLADE13_EN",
+	"PRSNT_MTIA_BLADE14_N","PWREN_MTIA_BLADE14_EN",
+	"PRSNT_MTIA_BLADE15_N","PWREN_MTIA_BLADE15_EN",
+	/*C0 - C7*/
+	"PRSNT_NW_BLADE0_N","PWREN_NW_BLADE0_EN",
+	"PRSNT_NW_BLADE1_N","PWREN_NW_BLADE1_EN",
+	"PRSNT_NW_BLADE2_N","PWREN_NW_BLADE2_EN",
+	"PRSNT_NW_BLADE3_N","PWREN_NW_BLADE3_EN",
+	"PRSNT_NW_BLADE4_N","PWREN_NW_BLADE4_EN",
+	"PRSNT_NW_BLADE5_N","PWREN_NW_BLADE5_EN",
+	"PRSNT_FCB_TOP_0_N","PWREN_MTIA_BLADE0_HSC_EN",
+	"PRSNT_FCB_TOP_1_N","PWREN_MTIA_BLADE1_HSC_EN",
+	/*D0 - D7*/
+	"PRSNT_FCB_MIDDLE_0_N","PWREN_MTIA_BLADE2_HSC_EN",
+	"PRSNT_FCB_MIDDLE_1_N","PWREN_MTIA_BLADE3_HSC_EN",
+	"PRSNT_FCB_BOTTOM_0_N","PWREN_MTIA_BLADE4_HSC_EN",
+	"PRSNT_FCB_BOTTOM_1_N","PWREN_MTIA_BLADE5_HSC_EN",
+	"PWRGD_MTIA_BLADE0_PWROK_L_BUF","PWREN_MTIA_BLADE6_HSC_EN",
+	"PWRGD_MTIA_BLADE1_PWROK_L_BUF","PWREN_MTIA_BLADE7_HSC_EN",
+	"PWRGD_MTIA_BLADE2_PWROK_L_BUF","PWREN_MTIA_BLADE8_HSC_EN",
+	"PWRGD_MTIA_BLADE3_PWROK_L_BUF","PWREN_MTIA_BLADE9_HSC_EN",
+	/*E0 - E7*/
+	"PWRGD_MTIA_BLADE4_PWROK_L_BUF","PWREN_MTIA_BLADE10_HSC_EN",
+	"PWRGD_MTIA_BLADE5_PWROK_L_BUF","PWREN_MTIA_BLADE11_HSC_EN",
+	"PWRGD_MTIA_BLADE6_PWROK_L_BUF","PWREN_MTIA_BLADE12_HSC_EN",
+	"PWRGD_MTIA_BLADE7_PWROK_L_BUF","PWREN_MTIA_BLADE13_HSC_EN",
+	"PWRGD_MTIA_BLADE8_PWROK_L_BUF","PWREN_MTIA_BLADE14_HSC_EN",
+	"PWRGD_MTIA_BLADE9_PWROK_L_BUF","PWREN_MTIA_BLADE15_HSC_EN",
+	"PWRGD_MTIA_BLADE10_PWROK_L_BUF","PWREN_NW_BLADE0_HSC_EN",
+	"PWRGD_MTIA_BLADE11_PWROK_L_BUF","PWREN_NW_BLADE1_HSC_EN",
+	/*F0 - F7*/
+	"PWRGD_MTIA_BLADE12_PWROK_L_BUF","PWREN_NW_BLADE2_HSC_EN",
+	"PWRGD_MTIA_BLADE13_PWROK_L_BUF","PWREN_NW_BLADE3_HSC_EN",
+	"PWRGD_MTIA_BLADE14_PWROK_L_BUF","PWREN_NW_BLADE4_HSC_EN",
+	"PWRGD_MTIA_BLADE15_PWROK_L_BUF","PWREN_NW_BLADE5_HSC_EN",
+	"PWRGD_NW_BLADE0_PWROK_L_BUF","PWREN_FCB_TOP_L_EN",
+	"PWRGD_NW_BLADE1_PWROK_L_BUF","PWREN_FCB_TOP_R_EN",
+	"PWRGD_NW_BLADE2_PWROK_L_BUF","PWREN_FCB_MIDDLE_L_EN",
+	"PWRGD_NW_BLADE3_PWROK_L_BUF","PWREN_FCB_MIDDLE_R_EN",
+	/*G0 - G7*/
+	"PWRGD_NW_BLADE4_PWROK_L_BUF","PWREN_FCB_BOTTOM_L_EN",
+	"PWRGD_NW_BLADE5_PWROK_L_BUF","PWREN_FCB_BOTTOM_R_EN",
+	"PWRGD_FCB_TOP_0_PWROK_L_BUF","FM_CMM_AC_CYCLE_N",
+	"PWRGD_FCB_TOP_1_PWROK_L_BUF","MGMT_SFP_TX_DIS",
+	"PWRGD_FCB_MIDDLE_0_PWROK_L_BUF","",
+	"PWRGD_FCB_MIDDLE_1_PWROK_L_BUF","RST_I2CRST_MTIA_BLADE0_1_N",
+	"PWRGD_FCB_BOTTOM_0_PWROK_L_BUF","RST_I2CRST_MTIA_BLADE2_3_N",
+	"PWRGD_FCB_BOTTOM_1_PWROK_L_BUF","RST_I2CRST_MTIA_BLADE4_5_N",
+	/*H0 - H7*/
+	"LEAK_DETECT_MTIA_BLADE0_N_BUF","RST_I2CRST_MTIA_BLADE6_7_N",
+	"LEAK_DETECT_MTIA_BLADE1_N_BUF","RST_I2CRST_MTIA_BLADE8_9_N",
+	"LEAK_DETECT_MTIA_BLADE2_N_BUF","RST_I2CRST_MTIA_BLADE10_11_N",
+	"LEAK_DETECT_MTIA_BLADE3_N_BUF","RST_I2CRST_MTIA_BLADE12_13_N",
+	"LEAK_DETECT_MTIA_BLADE4_N_BUF","RST_I2CRST_MTIA_BLADE14_15_N",
+	"LEAK_DETECT_MTIA_BLADE5_N_BUF","RST_I2CRST_NW_BLADE0_1_2_N",
+	"LEAK_DETECT_MTIA_BLADE6_N_BUF","RST_I2CRST_NW_BLADE3_4_5_N",
+	"LEAK_DETECT_MTIA_BLADE7_N_BUF","RST_I2CRST_FCB_N",
+	/*I0 - I7*/
+	"LEAK_DETECT_MTIA_BLADE8_N_BUF","RST_I2CRST_FCB_B_L_N",
+	"LEAK_DETECT_MTIA_BLADE9_N_BUF","RST_I2CRST_FCB_B_R_N",
+	"LEAK_DETECT_MTIA_BLADE10_N_BUF","RST_I2CRST_FCB_M_L_N",
+	"LEAK_DETECT_MTIA_BLADE11_N_BUF","RST_I2CRST_FCB_M_R_N",
+	"LEAK_DETECT_MTIA_BLADE12_N_BUF","RST_I2CRST_FCB_T_L_N",
+	"LEAK_DETECT_MTIA_BLADE13_N_BUF","RST_I2CRST_FCB_T_R_N",
+	"LEAK_DETECT_MTIA_BLADE14_N_BUF","BMC_READY",
+	"LEAK_DETECT_MTIA_BLADE15_N_BUF","wFM_88E6393X_BIN_UPDATE_EN_N",
+	/*J0 - J7*/
+	"LEAK_DETECT_NW_BLADE0_N_BUF","WATER_VALVE_CLOSED_N",
+	"LEAK_DETECT_NW_BLADE1_N_BUF","",
+	"LEAK_DETECT_NW_BLADE2_N_BUF","",
+	"LEAK_DETECT_NW_BLADE3_N_BUF","",
+	"LEAK_DETECT_NW_BLADE4_N_BUF","",
+	"LEAK_DETECT_NW_BLADE5_N_BUF","",
+	"MTIA_BLADE0_STATUS_LED","",
+	"MTIA_BLADE1_STATUS_LED","",
+	/*K0 - K7*/
+	"MTIA_BLADE2_STATUS_LED","",
+	"MTIA_BLADE3_STATUS_LED","",
+	"MTIA_BLADE4_STATUS_LED","",
+	"MTIA_BLADE5_STATUS_LED","",
+	"MTIA_BLADE6_STATUS_LED","",
+	"MTIA_BLADE7_STATUS_LED","",
+	"MTIA_BLADE8_STATUS_LED","",
+	"MTIA_BLADE9_STATUS_LED","",
+	/*L0 - L7*/
+	"MTIA_BLADE10_STATUS_LED","",
+	"MTIA_BLADE11_STATUS_LED","",
+	"MTIA_BLADE12_STATUS_LED","",
+	"MTIA_BLADE13_STATUS_LED","",
+	"MTIA_BLADE14_STATUS_LED","",
+	"MTIA_BLADE15_STATUS_LED","",
+	"NW_BLADE0_STATUS_LED","",
+	"NW_BLADE1_STATUS_LED","",
+	/*M0 - M7*/
+	"NW_BLADE2_STATUS_LED","",
+	"NW_BLADE3_STATUS_LED","",
+	"NW_BLADE4_STATUS_LED","",
+	"NW_BLADE5_STATUS_LED","",
+	"RPU_READY","",
+	"IT_GEAR_RPU_LINK_N","",
+	"IT_GEAR_LEAK","",
+	"WATER_VALVE_CLOSED_N","",
+	/*N0 - N7*/
+	"VALVE_STS0","",
+	"VALVE_STS1","",
+	"VALVE_STS2","",
+	"VALVE_STS3","",
+	"CR_TOGGLE_BOOT_BUF_N","",
+	"CMM_LC_RDY_LED_N","",
+	"CMM_LC_UNRDY_LED_N","",
+	"CMM_CABLE_CARTRIDGE_PRSNT_BOT_N","",
+	/*O0 - O7*/
+	"CMM_CABLE_CARTRIDGE_PRSNT_TOP_N","",
+	"BOT_BCB_CABLE_PRSNT_N","",
+	"TOP_BCB_CABLE_PRSNT_N","",
+	"CHASSIS0_LEAK_Q_N","",
+	"CHASSIS1_LEAK_Q_N","",
+	"LEAK0_DETECT","",
+	"LEAK1_DETECT","",
+	"MGMT_SFP_PRSNT_N","",
+	/*P0 - P7*/
+	"MGMT_SFP_TX_FAULT","",
+	"MGMT_SFP_RX_LOS","",
+	"","",
+	"","",
+	"","",
+	"","",
+	"","",
+	"","";
+};
-- 
2.34.1



From dsimic at manjaro.org  Tue Dec 12 00:01:39 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 09:01:39 +0100
Subject: [PATCH 1/2] arm64: dts: rockchip: Add ethernet0 alias to the dts for RK3566 boards
In-Reply-To: <cover.1702368023.git.dsimic@manjaro.org>
References: <cover.1702368023.git.dsimic@manjaro.org>
Message-ID: <d2a272e0ae0fff0adfab8bb0238243b11d348799.1702368023.git.dsimic@manjaro.org>

Add ethernet0 alias to the board dts files for a few supported RK3566 boards
that had it missing.  Also, remove the ethernet0 alias from one RK3566 SoM
dtsi file, which doesn't enable the GMAC, and add the ethernet0 alias back to
the dependent board dts files, which actually enable the GMAC.

Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3566-radxa-cm3-io.dts     | 1 +
 arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts           | 1 +
 arch/arm64/boot/dts/rockchip/rk3566-soquartz-blade.dts   | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3566-soquartz-cm4.dts     | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3566-soquartz-model-a.dts | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi        | 1 -
 6 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3566-radxa-cm3-io.dts b/arch/arm64/boot/dts/rockchip/rk3566-radxa-cm3-io.dts
index 1b1c67d5b1ef..3ae24e39450a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-radxa-cm3-io.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-radxa-cm3-io.dts
@@ -14,6 +14,7 @@ / {
 	compatible = "radxa,cm3-io", "radxa,cm3", "rockchip,rk3566";
 
 	aliases {
+		ethernet0 = &gmac1;
 		mmc1 = &sdmmc0;
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
index 938092fce186..63eea27293fe 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
@@ -12,6 +12,7 @@ / {
 	compatible = "firefly,rk3566-roc-pc", "rockchip,rk3566";
 
 	aliases {
+		ethernet0 = &gmac1;
 		mmc0 = &sdmmc0;
 		mmc1 = &sdhci;
 		mmc2 = &sdmmc1;
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-soquartz-blade.dts b/arch/arm64/boot/dts/rockchip/rk3566-soquartz-blade.dts
index 4e49bebf548b..fdbf1c783242 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-soquartz-blade.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-soquartz-blade.dts
@@ -13,6 +13,10 @@ / {
 	model = "PINE64 RK3566 SOQuartz on Blade carrier board";
 	compatible = "pine64,soquartz-blade", "pine64,soquartz", "rockchip,rk3566";
 
+	aliases {
+		ethernet0 = &gmac1;
+	};
+
 	/* labeled VCC3V0_SD in schematic to not conflict with PMIC regulator */
 	vcc3v0_sd: vcc3v0-sd-regulator {
 		compatible = "regulator-fixed";
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-soquartz-cm4.dts b/arch/arm64/boot/dts/rockchip/rk3566-soquartz-cm4.dts
index cddf6cd2fecb..6ed3fa4aee34 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-soquartz-cm4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-soquartz-cm4.dts
@@ -8,6 +8,10 @@ / {
 	model = "Pine64 RK3566 SoQuartz with CM4-IO Carrier Board";
 	compatible = "pine64,soquartz-cm4io", "pine64,soquartz", "rockchip,rk3566";
 
+	aliases {
+		ethernet0 = &gmac1;
+	};
+
 	/* labeled +12v in schematic */
 	vcc12v_dcin: vcc12v-dcin-regulator {
 		compatible = "regulator-fixed";
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-soquartz-model-a.dts b/arch/arm64/boot/dts/rockchip/rk3566-soquartz-model-a.dts
index 2208dbfb7f0a..f2095dfa4eaf 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-soquartz-model-a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-soquartz-model-a.dts
@@ -8,6 +8,10 @@ / {
 	model = "PINE64 RK3566 SOQuartz on Model A carrier board";
 	compatible = "pine64,soquartz-model-a", "pine64,soquartz", "rockchip,rk3566";
 
+	aliases {
+		ethernet0 = &gmac1;
+	};
+
 	/* labeled DCIN_12V in schematic */
 	vcc12v_dcin: vcc12v-dcin-regulator {
 		compatible = "regulator-fixed";
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
index 63bae36b8f7e..bfb7b952f4c5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
@@ -12,7 +12,6 @@ / {
 	compatible = "pine64,soquartz", "rockchip,rk3566";
 
 	aliases {
-		ethernet0 = &gmac1;
 		mmc0 = &sdmmc0;
 		mmc1 = &sdhci;
 		mmc2 = &sdmmc1;


From dsimic at manjaro.org  Tue Dec 12 00:01:40 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 09:01:40 +0100
Subject: [PATCH 2/2] arm64: dts: rockchip: Add ethernet0 alias to the dts for RK3588(S) boards
In-Reply-To: <cover.1702368023.git.dsimic@manjaro.org>
References: <cover.1702368023.git.dsimic@manjaro.org>
Message-ID: <9af2026bf8a5538aff627381289cb06f2fab4263.1702368023.git.dsimic@manjaro.org>

Add ethernet0 alias to the board dts files for a few supported RK3588 and
RK3588S boards that had it missing.

Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts    | 1 +
 arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 1 +
 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts | 1 +
 arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts    | 1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
index b9d789d57862..3cd748ee84c6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
@@ -16,6 +16,7 @@ / {
 	compatible = "rockchip,rk3588-evb1-v10", "rockchip,rk3588";
 
 	aliases {
+		ethernet0 = &gmac0;
 		mmc0 = &sdhci;
 		serial2 = &uart2;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
index 5c59f9571dce..467622a8c008 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
@@ -17,6 +17,7 @@ / {
 	compatible = "pine64,quartzpro64", "rockchip,rk3588";
 
 	aliases {
+		ethernet0 = &gmac0;
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 		serial2 = &uart2;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index e3a839a12dc6..36269100d2ee 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -13,6 +13,7 @@ / {
 	compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
 
 	aliases {
+		ethernet0 = &gmac1;
 		mmc0 = &sdmmc;
 		serial2 = &uart2;
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
index 8347adcbd003..abd6934ab3b7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
@@ -12,6 +12,7 @@ / {
 	compatible = "radxa,rock-5a", "rockchip,rk3588s";
 
 	aliases {
+		ethernet0 = &gmac1;
 		mmc0 = &sdhci;
 		mmc1 = &sdmmc;
 		serial2 = &uart2;


From dsimic at manjaro.org  Tue Dec 12 00:01:38 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 09:01:38 +0100
Subject: [PATCH 0/2] arm64: dts: rockchip: Add ethernet0 aliases to the dts files for RK3566 and RK3588(S) boards
Message-ID: <cover.1702368023.git.dsimic@manjaro.org>

To complete the process started with the migration of the ethernet0 aliases
from the SoC dtsi files to the board/device dts(i) files, started in [1],
let's add ethernet0 aliases to the board dts files that had it missing.
See also [2] for a related discussion.

At the same time, let's remove the ethernet0 alias from one SoM dtsi file,
which doesn't enable the GMAC, and add the same alias back to the dependent
board dts files, which actually enable the GMAC.

All these patches result in a rather clean situation when it comes to the
Rockchip arm64 device-tree aliases.

[1] https://lore.kernel.org/linux-rockchip/cover.1702366958.git.dsimic at manjaro.org/T/#u
[2] https://lore.kernel.org/linux-rockchip/5119280.687JKscXgg at diego/T/#u

Dragan Simic (2):
  arm64: dts: rockchip: Add ethernet0 alias to the dts for RK3566 boards
  arm64: dts: rockchip: Add ethernet0 alias to the dts for RK3588(S)
    boards

 arch/arm64/boot/dts/rockchip/rk3566-radxa-cm3-io.dts     | 1 +
 arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts           | 1 +
 arch/arm64/boot/dts/rockchip/rk3566-soquartz-blade.dts   | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3566-soquartz-cm4.dts     | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3566-soquartz-model-a.dts | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi        | 1 -
 arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts         | 1 +
 arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts      | 1 +
 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts      | 1 +
 arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts         | 1 +
 10 files changed, 18 insertions(+), 1 deletion(-)



From dsimic at manjaro.org  Tue Dec 12 00:04:55 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 09:04:55 +0100
Subject: [PATCH v2 4/9] ARM: dts: rockchip: rv1126: Add i2c2 nodes
In-Reply-To: <6efa5eb17d795da024357a12dfb11ac1@manjaro.org>
References: <20231122122232.952696-1-tim@feathertop.org>
 <4234862.3Lj2Plt8kZ@diego> <8fec049c0b72727086c707dfd9de6dda@manjaro.org>
 <5119280.687JKscXgg@diego> <6efa5eb17d795da024357a12dfb11ac1@manjaro.org>
Message-ID: <316304f17b7e2641658d0efc867c0603@manjaro.org>

On 2023-11-27 14:07, Dragan Simic wrote:
> On 2023-11-27 12:10, Heiko St?bner wrote:
>> Am Montag, 27. November 2023, 11:55:21 CET schrieb Dragan Simic:
>>> On 2023-11-27 11:50, Heiko St?bner wrote:
>>>> Am Montag, 27. November 2023, 11:43:05 CET schrieb Dragan Simic:
>>>>> Please note there's already an Ethernet alias defined in 
>>>>> rk3399.dtsi,
>>>>> even despite not all RK3399-based devices using the GMAC, for 
>>>>> example
>>>>> the Pinebook Pro.  Perhaps that's something to be fixed as well.
>>>> 
>>>> possibly :-)
>>>> 
>>>> I guess for starters we shouldn't introduce new instances for it.
>>> 
>>> Totally agreed.
>>> 
>>> > All the newer SoCs already have their ethernet alias in the board dts
>>> > (rk356x, rk3568) which came after we also moved the mmc aliases.
>>> 
>>> The base rk3399.dtsi file and the RK3399-based board/device dts(i) 
>>> files
>>> are fine when it comes to the mmc aliases.  I can move forward and 
>>> clean
>>> up the Ethernet alias as well, if you agree?
>> 
>> Yep, we moved mmc aliases a while ago.
>> 
>> So moving the ethernet sounds like the right way forward. So if you 
>> have
>> the time for it, then I'd be quite happy to take patches for that 
>> change.
> 
> Great, thanks.  I'll prepare the patches in the next couple of days,
> and send them over.

I apologize for the delay, I finally got around to implementing and 
verifying these patches for the RK3399, RK3368, RK3328 and PX30 SoC 
dts(i) files. [1]  The way I verified them was to compare the compiled 
dtb files before and after applying the patches.

Also, I went ahead and implemented the patches that add ethernet aliases 
to the RK356x and RK3588 dts board files. [2]  With these patches in 
place, together with the other patches that have already been accepted, 
we should have a rather clean situation when it comes to the Rockchip 
arm64 DT aliases.

[1] 
https://lore.kernel.org/linux-rockchip/cover.1702366958.git.dsimic at manjaro.org/T/#u
[2] 
https://lore.kernel.org/linux-rockchip/cover.1702368023.git.dsimic at manjaro.org/T/#u


From ardb at kernel.org  Tue Dec 12 00:16:13 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Tue, 12 Dec 2023 09:16:13 +0100
Subject: [PATCH v4 0/4] arm64: Run kernel mode NEON with preemption enabled
In-Reply-To: <170231871028.1857077.10318072500676133330.b4-ty@kernel.org>
References: <20231208113218.3001940-6-ardb@google.com> <170231871028.1857077.10318072500676133330.b4-ty@kernel.org>
Message-ID: <CAMj1kXE=2H_Jqyuv_gDp6QS2g2Vzdgf=fngp=ZXEUBXKOYWnbQ@mail.gmail.com>

On Mon, 11 Dec 2023 at 21:27, Will Deacon <will at kernel.org> wrote:
>
> Hey Ard,
>
> On Fri, 8 Dec 2023 12:32:19 +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb at kernel.org>
> >
> > Currently, kernel mode NEON (SIMD) support is implemented in a way that
> > requires preemption to be disabled while the SIMD registers are live.
> > The reason for this is that those registers are not in the set that is
> > preserved/restored on exception entry/exit and context switch, as this
> > would impact performance generally, even for workloads where kernel mode
> > SIMD is not the bottleneck.
> >
> > [...]
>
> I applied the first three patches to for-next/fpsimd:
>

Thanks

> [1/4] arm64: fpsimd: Drop unneeded 'busy' flag
>       https://git.kernel.org/arm64/c/e109130b0e5e
> [2/4] arm64: fpsimd: Preserve/restore kernel mode NEON at context switch
>       https://git.kernel.org/arm64/c/1e3a3de1ff6c

I spotted a typo in the commit log of this patch:

TIF_USING_KMODE_FPSIMD -> TIF_KERNEL_FPSTATE


> [3/4] arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD
>       https://git.kernel.org/arm64/c/035262623959
>
> It would be nice to have an Ack from Herbert on the last one so that
> he's aware of the possible conflicts.
>
> The other thing I tangentially wondered about is what happens now if code
> calls uaccess routines (e.g. get_user()) within a kernel_neon_{begin,end}
> section? I think previously the fact that preemption had to be disabled
> would've caused the might_fault() to explode, but now I suppose the BUG_ON()
> in kernel_neon_begin() will save us. Is that right?
>

Not sure what you mean by 'save us'. Is there anything fundamentally
wrong with doing user access from a kernel mode NEON region if
preemption remains enabled?

The BUG_ON() will only catch uses from hardirq/NMI context, or cases
where FP/SIMD is not implemented/enabled in the first place so it will
not trigger on a user access.


From devnull+nikita.shubin.maquefel.me at kernel.org  Tue Dec 12 00:20:18 2023
From: devnull+nikita.shubin.maquefel.me at kernel.org (Nikita Shubin via B4 Relay)
Date: Tue, 12 Dec 2023 11:20:18 +0300
Subject: [PATCH v6 01/40] ARM: ep93xx: Add terminator to gpiod_lookup_table
In-Reply-To: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
Message-ID: <20231212-ep93xx-v6-1-c307b8ac9aa8@maquefel.me>

From: Nikita Shubin <nikita.shubin at maquefel.me>

Without the terminator, if a con_id is passed to gpio_find() that
does not exist in the lookup table the function will not stop looping
correctly, and eventually cause an oops.

Signed-off-by: Nikita Shubin <nikita.shubin at maquefel.me>
---
 arch/arm/mach-ep93xx/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 71b113976420..8b1ec60a9a46 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -339,6 +339,7 @@ static struct gpiod_lookup_table ep93xx_i2c_gpiod_table = {
 				GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
 		GPIO_LOOKUP_IDX("G", 0, NULL, 1,
 				GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+		{ }
 	},
 };
 

-- 
2.41.0



From devnull+nikita.shubin.maquefel.me at kernel.org  Tue Dec 12 00:20:19 2023
From: devnull+nikita.shubin.maquefel.me at kernel.org (Nikita Shubin via B4 Relay)
Date: Tue, 12 Dec 2023 11:20:19 +0300
Subject: [PATCH v6 02/40] gpio: ep93xx: split device in multiple
In-Reply-To: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
Message-ID: <20231212-ep93xx-v6-2-c307b8ac9aa8@maquefel.me>

From: Nikita Shubin <nikita.shubin at maquefel.me>

Prepare ep93xx SOC gpio to convert into device tree driver:
- dropped banks and legacy defines
- split AB IRQ and make it shared

We are relying on IRQ number information A, B ports have single shared
IRQ, while F port have dedicated IRQ for each line.

Also we had to split single ep93xx platform_device into multiple, one
for each port, without this we can't do a full working transition from
legacy platform code into device tree capable. All GPIO_LOOKUP were
change to match new chip namings.

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
Reviewed-by: Andy Shevchenko <andy at kernel.org>
Signed-off-by: Nikita Shubin <nikita.shubin at maquefel.me>
---
 arch/arm/mach-ep93xx/core.c          | 121 ++++++++++++--
 arch/arm/mach-ep93xx/edb93xx.c       |   2 +-
 arch/arm/mach-ep93xx/ts72xx.c        |   4 +-
 arch/arm/mach-ep93xx/vision_ep9307.c |  10 +-
 drivers/gpio/gpio-ep93xx.c           | 311 +++++++++++++----------------------
 5 files changed, 228 insertions(+), 220 deletions(-)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 8b1ec60a9a46..03bce5e9d1f1 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -35,6 +35,7 @@
 #include <linux/reboot.h>
 #include <linux/usb/ohci_pdriver.h>
 #include <linux/random.h>
+#include <linux/ioport.h>
 
 #include "hardware.h"
 #include <linux/platform_data/video-ep93xx.h>
@@ -139,9 +140,80 @@ EXPORT_SYMBOL_GPL(ep93xx_chip_revision);
 /*************************************************************************
  * EP93xx GPIO
  *************************************************************************/
-static struct resource ep93xx_gpio_resource[] = {
-	DEFINE_RES_MEM(EP93XX_GPIO_PHYS_BASE, 0xcc),
+/* port A */
+static struct resource ep93xx_a_gpio_resources[] = {
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE,        0x04, "data"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x10, 0x04, "dir"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x90, 0x1c, "intr"),
 	DEFINE_RES_IRQ(IRQ_EP93XX_GPIO_AB),
+};
+
+static struct platform_device ep93xx_a_gpio = {
+	.name           = "gpio-ep93xx",
+	.id             = 0,
+	.num_resources = ARRAY_SIZE(ep93xx_a_gpio_resources),
+	.resource = ep93xx_a_gpio_resources,
+};
+
+/* port B */
+static struct resource ep93xx_b_gpio_resources[] = {
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x04, 0x04, "data"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x14, 0x04, "dir"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0xac, 0x1c, "intr"),
+	DEFINE_RES_IRQ(IRQ_EP93XX_GPIO_AB),
+};
+
+static struct platform_device ep93xx_b_gpio = {
+	.name           = "gpio-ep93xx",
+	.id             = 1,
+	.num_resources = ARRAY_SIZE(ep93xx_b_gpio_resources),
+	.resource = ep93xx_b_gpio_resources,
+};
+
+/* port C */
+static struct resource ep93xx_c_gpio_resources[] = {
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x08, 0x04, "data"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x18, 0x04, "dir"),
+};
+
+static struct platform_device ep93xx_c_gpio = {
+	.name           = "gpio-ep93xx",
+	.id             = 2,
+	.num_resources = ARRAY_SIZE(ep93xx_c_gpio_resources),
+	.resource = ep93xx_c_gpio_resources,
+};
+
+/* port D */
+static struct resource ep93xx_d_gpio_resources[] = {
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x0c, 0x04, "data"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x1c, 0x04, "dir"),
+};
+
+static struct platform_device ep93xx_d_gpio = {
+	.name           = "gpio-ep93xx",
+	.id             = 3,
+	.num_resources = ARRAY_SIZE(ep93xx_d_gpio_resources),
+	.resource = ep93xx_d_gpio_resources,
+};
+
+/* port E */
+static struct resource ep93xx_e_gpio_resources[] = {
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x20, 0x04, "data"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x24, 0x04, "dir"),
+};
+
+static struct platform_device ep93xx_e_gpio = {
+	.name           = "gpio-ep93xx",
+	.id             = 4,
+	.num_resources = ARRAY_SIZE(ep93xx_e_gpio_resources),
+	.resource = ep93xx_e_gpio_resources,
+};
+
+/* port F */
+static struct resource ep93xx_f_gpio_resources[] = {
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x30, 0x04, "data"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x34, 0x04, "dir"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x4c, 0x1c, "intr"),
 	DEFINE_RES_IRQ(IRQ_EP93XX_GPIO0MUX),
 	DEFINE_RES_IRQ(IRQ_EP93XX_GPIO1MUX),
 	DEFINE_RES_IRQ(IRQ_EP93XX_GPIO2MUX),
@@ -152,11 +224,34 @@ static struct resource ep93xx_gpio_resource[] = {
 	DEFINE_RES_IRQ(IRQ_EP93XX_GPIO7MUX),
 };
 
-static struct platform_device ep93xx_gpio_device = {
-	.name		= "gpio-ep93xx",
-	.id		= -1,
-	.num_resources	= ARRAY_SIZE(ep93xx_gpio_resource),
-	.resource	= ep93xx_gpio_resource,
+static struct platform_device ep93xx_f_gpio = {
+	.name           = "gpio-ep93xx",
+	.id             = 5,
+	.num_resources = ARRAY_SIZE(ep93xx_f_gpio_resources),
+	.resource = ep93xx_f_gpio_resources,
+};
+
+/* port G */
+static struct resource ep93xx_g_gpio_resources[] = {
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x38, 0x04, "data"),
+	DEFINE_RES_MEM_NAMED(EP93XX_GPIO_PHYS_BASE + 0x3c, 0x04, "dir"),
+};
+
+static struct platform_device ep93xx_g_gpio = {
+	.name           = "gpio-ep93xx",
+	.id             = 6,
+	.num_resources = ARRAY_SIZE(ep93xx_g_gpio_resources),
+	.resource = ep93xx_g_gpio_resources,
+};
+
+static struct platform_device *ep93xx_gpio_device[] __initdata = {
+	&ep93xx_a_gpio,
+	&ep93xx_b_gpio,
+	&ep93xx_c_gpio,
+	&ep93xx_d_gpio,
+	&ep93xx_e_gpio,
+	&ep93xx_f_gpio,
+	&ep93xx_g_gpio,
 };
 
 /*************************************************************************
@@ -335,9 +430,9 @@ static struct gpiod_lookup_table ep93xx_i2c_gpiod_table = {
 	.dev_id		= "i2c-gpio.0",
 	.table		= {
 		/* Use local offsets on gpiochip/port "G" */
-		GPIO_LOOKUP_IDX("G", 1, NULL, 0,
+		GPIO_LOOKUP_IDX("gpio-ep93xx.6", 1, NULL, 0,
 				GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
-		GPIO_LOOKUP_IDX("G", 0, NULL, 1,
+		GPIO_LOOKUP_IDX("gpio-ep93xx.6", 0, NULL, 1,
 				GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
 		{ }
 	},
@@ -441,8 +536,8 @@ static struct gpiod_lookup_table ep93xx_leds_gpio_table = {
 	.dev_id = "leds-gpio",
 	.table = {
 		/* Use local offsets on gpiochip/port "E" */
-		GPIO_LOOKUP_IDX("E", 0, NULL, 0, GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP_IDX("E", 1,	NULL, 1, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP_IDX("gpio-ep93xx.4", 0, NULL, 0, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP_IDX("gpio-ep93xx.4", 1, NULL, 1, GPIO_ACTIVE_HIGH),
 		{ }
 	},
 };
@@ -975,6 +1070,7 @@ static struct device __init *ep93xx_init_soc(void)
 struct device __init *ep93xx_init_devices(void)
 {
 	struct device *parent;
+	unsigned int i;
 
 	/* Disallow access to MaverickCrunch initially */
 	ep93xx_devcfg_clear_bits(EP93XX_SYSCON_DEVCFG_CPENA);
@@ -989,7 +1085,8 @@ struct device __init *ep93xx_init_devices(void)
 	parent = ep93xx_init_soc();
 
 	/* Get the GPIO working early, other devices need it */
-	platform_device_register(&ep93xx_gpio_device);
+	for (i = 0; i < ARRAY_SIZE(ep93xx_gpio_device); i++)
+		platform_device_register(ep93xx_gpio_device[i]);
 
 	amba_device_register(&uart1_device, &iomem_resource);
 	amba_device_register(&uart2_device, &iomem_resource);
diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
index 4b90899a66e9..c1e880946f72 100644
--- a/arch/arm/mach-ep93xx/edb93xx.c
+++ b/arch/arm/mach-ep93xx/edb93xx.c
@@ -105,7 +105,7 @@ static struct spi_board_info edb93xx_spi_board_info[] __initdata = {
 static struct gpiod_lookup_table edb93xx_spi_cs_gpio_table = {
 	.dev_id = "spi0",
 	.table = {
-		GPIO_LOOKUP("A", 6, "cs", GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP("gpio-ep93xx.0", 6, "cs", GPIO_ACTIVE_LOW),
 		{ },
 	},
 };
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index d3de7283ecb3..0bbdf587c685 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -268,7 +268,7 @@ static struct spi_board_info bk3_spi_board_info[] __initdata = {
 static struct gpiod_lookup_table bk3_spi_cs_gpio_table = {
 	.dev_id = "spi0",
 	.table = {
-		GPIO_LOOKUP("F", 3, "cs", GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP("gpio-ep93xx.5", 3, "cs", GPIO_ACTIVE_LOW),
 		{ },
 	},
 };
@@ -318,7 +318,7 @@ static struct gpiod_lookup_table ts72xx_spi_cs_gpio_table = {
 	.dev_id = "spi0",
 	.table = {
 		/* DIO_17 */
-		GPIO_LOOKUP("F", 2, "cs", GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP("gpio-ep93xx.5", 2, "cs", GPIO_ACTIVE_LOW),
 		{ },
 	},
 };
diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c b/arch/arm/mach-ep93xx/vision_ep9307.c
index 30d9cf3791eb..020223b0be2b 100644
--- a/arch/arm/mach-ep93xx/vision_ep9307.c
+++ b/arch/arm/mach-ep93xx/vision_ep9307.c
@@ -206,9 +206,9 @@ static struct gpiod_lookup_table vision_spi_mmc_gpio_table = {
 	.dev_id = "mmc_spi.2", /* "mmc_spi @ CS2 */
 	.table = {
 		/* Card detect */
-		GPIO_LOOKUP_IDX("B", 7, NULL, 0, GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP_IDX("gpio-ep93xx.1", 7, NULL, 0, GPIO_ACTIVE_LOW),
 		/* Write protect */
-		GPIO_LOOKUP_IDX("F", 0, NULL, 1, GPIO_ACTIVE_HIGH),
+		GPIO_LOOKUP_IDX("gpio-ep93xx.5", 0, NULL, 1, GPIO_ACTIVE_HIGH),
 		{ },
 	},
 };
@@ -244,9 +244,9 @@ static struct spi_board_info vision_spi_board_info[] __initdata = {
 static struct gpiod_lookup_table vision_spi_cs_gpio_table = {
 	.dev_id = "spi0",
 	.table = {
-		GPIO_LOOKUP_IDX("A", 6, "cs", 0, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("A", 7, "cs", 1, GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP_IDX("G", 2, "cs", 2, GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP_IDX("gpio-ep93xx.0", 6, "cs", 0, GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP_IDX("gpio-ep93xx.0", 7, "cs", 1, GPIO_ACTIVE_LOW),
+		GPIO_LOOKUP_IDX("gpio-ep93xx.6", 2, "cs", 2, GPIO_ACTIVE_LOW),
 		{ },
 	},
 };
diff --git a/drivers/gpio/gpio-ep93xx.c b/drivers/gpio/gpio-ep93xx.c
index 6cedf46efec6..a55f635585f4 100644
--- a/drivers/gpio/gpio-ep93xx.c
+++ b/drivers/gpio/gpio-ep93xx.c
@@ -18,30 +18,10 @@
 #include <linux/gpio/driver.h>
 #include <linux/bitops.h>
 #include <linux/seq_file.h>
-
-#define EP93XX_GPIO_F_INT_STATUS 0x5c
-#define EP93XX_GPIO_A_INT_STATUS 0xa0
-#define EP93XX_GPIO_B_INT_STATUS 0xbc
-
-/* Maximum value for gpio line identifiers */
-#define EP93XX_GPIO_LINE_MAX 63
-
-/* Number of GPIO chips in EP93XX */
-#define EP93XX_GPIO_CHIP_NUM 8
-
-/* Maximum value for irq capable line identifiers */
-#define EP93XX_GPIO_LINE_MAX_IRQ 23
-
-#define EP93XX_GPIO_A_IRQ_BASE 64
-#define EP93XX_GPIO_B_IRQ_BASE 72
-/*
- * Static mapping of GPIO bank F IRQS:
- * F0..F7 (16..24) to irq 80..87.
- */
-#define EP93XX_GPIO_F_IRQ_BASE 80
+#include <linux/interrupt.h>
 
 struct ep93xx_gpio_irq_chip {
-	u8 irq_offset;
+	void __iomem *base;
 	u8 int_unmasked;
 	u8 int_enabled;
 	u8 int_type1;
@@ -50,15 +30,11 @@ struct ep93xx_gpio_irq_chip {
 };
 
 struct ep93xx_gpio_chip {
+	void __iomem			*base;
 	struct gpio_chip		gc;
 	struct ep93xx_gpio_irq_chip	*eic;
 };
 
-struct ep93xx_gpio {
-	void __iomem		*base;
-	struct ep93xx_gpio_chip	gc[EP93XX_GPIO_CHIP_NUM];
-};
-
 #define to_ep93xx_gpio_chip(x) container_of(x, struct ep93xx_gpio_chip, gc)
 
 static struct ep93xx_gpio_irq_chip *to_ep93xx_gpio_irq_chip(struct gpio_chip *gc)
@@ -79,25 +55,23 @@ static struct ep93xx_gpio_irq_chip *to_ep93xx_gpio_irq_chip(struct gpio_chip *gc
 #define EP93XX_INT_RAW_STATUS_OFFSET	0x14
 #define EP93XX_INT_DEBOUNCE_OFFSET	0x18
 
-static void ep93xx_gpio_update_int_params(struct ep93xx_gpio *epg,
-					  struct ep93xx_gpio_irq_chip *eic)
+static void ep93xx_gpio_update_int_params(struct ep93xx_gpio_irq_chip *eic)
 {
-	writeb_relaxed(0, epg->base + eic->irq_offset + EP93XX_INT_EN_OFFSET);
+	writeb_relaxed(0, eic->base + EP93XX_INT_EN_OFFSET);
 
 	writeb_relaxed(eic->int_type2,
-		       epg->base + eic->irq_offset + EP93XX_INT_TYPE2_OFFSET);
+		       eic->base + EP93XX_INT_TYPE2_OFFSET);
 
 	writeb_relaxed(eic->int_type1,
-		       epg->base + eic->irq_offset + EP93XX_INT_TYPE1_OFFSET);
+		       eic->base + EP93XX_INT_TYPE1_OFFSET);
 
 	writeb_relaxed(eic->int_unmasked & eic->int_enabled,
-		       epg->base + eic->irq_offset + EP93XX_INT_EN_OFFSET);
+		       eic->base + EP93XX_INT_EN_OFFSET);
 }
 
 static void ep93xx_gpio_int_debounce(struct gpio_chip *gc,
 				     unsigned int offset, bool enable)
 {
-	struct ep93xx_gpio *epg = gpiochip_get_data(gc);
 	struct ep93xx_gpio_irq_chip *eic = to_ep93xx_gpio_irq_chip(gc);
 	int port_mask = BIT(offset);
 
@@ -106,53 +80,43 @@ static void ep93xx_gpio_int_debounce(struct gpio_chip *gc,
 	else
 		eic->int_debounce &= ~port_mask;
 
-	writeb(eic->int_debounce,
-	       epg->base + eic->irq_offset + EP93XX_INT_DEBOUNCE_OFFSET);
+	writeb(eic->int_debounce, eic->base + EP93XX_INT_DEBOUNCE_OFFSET);
 }
 
-static void ep93xx_gpio_ab_irq_handler(struct irq_desc *desc)
+static u32 ep93xx_gpio_ab_irq_handler(struct gpio_chip *gc)
 {
-	struct gpio_chip *gc = irq_desc_get_handler_data(desc);
-	struct ep93xx_gpio *epg = gpiochip_get_data(gc);
-	struct irq_chip *irqchip = irq_desc_get_chip(desc);
+	struct ep93xx_gpio_irq_chip *eic = to_ep93xx_gpio_irq_chip(gc);
 	unsigned long stat;
 	int offset;
 
-	chained_irq_enter(irqchip, desc);
-
-	/*
-	 * Dispatch the IRQs to the irqdomain of each A and B
-	 * gpiochip irqdomains depending on what has fired.
-	 * The tricky part is that the IRQ line is shared
-	 * between bank A and B and each has their own gpiochip.
-	 */
-	stat = readb(epg->base + EP93XX_GPIO_A_INT_STATUS);
+	stat = readb(eic->base + EP93XX_INT_STATUS_OFFSET);
 	for_each_set_bit(offset, &stat, 8)
-		generic_handle_domain_irq(epg->gc[0].gc.irq.domain,
-					  offset);
+		generic_handle_domain_irq(gc->irq.domain, offset);
 
-	stat = readb(epg->base + EP93XX_GPIO_B_INT_STATUS);
-	for_each_set_bit(offset, &stat, 8)
-		generic_handle_domain_irq(epg->gc[1].gc.irq.domain,
-					  offset);
+	return stat;
+}
 
-	chained_irq_exit(irqchip, desc);
+static irqreturn_t ep93xx_ab_irq_handler(int irq, void *dev_id)
+{
+	return IRQ_RETVAL(ep93xx_gpio_ab_irq_handler(dev_id));
 }
 
 static void ep93xx_gpio_f_irq_handler(struct irq_desc *desc)
 {
-	/*
-	 * map discontiguous hw irq range to continuous sw irq range:
-	 *
-	 *  IRQ_EP93XX_GPIO{0..7}MUX -> EP93XX_GPIO_LINE_F{0..7}
-	 */
 	struct irq_chip *irqchip = irq_desc_get_chip(desc);
-	unsigned int irq = irq_desc_get_irq(desc);
-	int port_f_idx = (irq & 7) ^ 4; /* {20..23,48..51} -> {0..7} */
-	int gpio_irq = EP93XX_GPIO_F_IRQ_BASE + port_f_idx;
+	struct gpio_chip *gc = irq_desc_get_handler_data(desc);
+	struct gpio_irq_chip *gic = &gc->irq;
+	unsigned int parent = irq_desc_get_irq(desc);
+	unsigned int i;
 
 	chained_irq_enter(irqchip, desc);
-	generic_handle_irq(gpio_irq);
+	for (i = 0; i < gic->num_parents; i++)
+		if (gic->parents[i] == parent)
+			break;
+
+	if (i < gic->num_parents)
+		generic_handle_domain_irq(gc->irq.domain, i);
+
 	chained_irq_exit(irqchip, desc);
 }
 
@@ -160,31 +124,29 @@ static void ep93xx_gpio_irq_ack(struct irq_data *d)
 {
 	struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
 	struct ep93xx_gpio_irq_chip *eic = to_ep93xx_gpio_irq_chip(gc);
-	struct ep93xx_gpio *epg = gpiochip_get_data(gc);
-	int port_mask = BIT(d->irq & 7);
+	int port_mask = BIT(irqd_to_hwirq(d));
 
 	if (irqd_get_trigger_type(d) == IRQ_TYPE_EDGE_BOTH) {
 		eic->int_type2 ^= port_mask; /* switch edge direction */
-		ep93xx_gpio_update_int_params(epg, eic);
+		ep93xx_gpio_update_int_params(eic);
 	}
 
-	writeb(port_mask, epg->base + eic->irq_offset + EP93XX_INT_EOI_OFFSET);
+	writeb(port_mask, eic->base + EP93XX_INT_EOI_OFFSET);
 }
 
 static void ep93xx_gpio_irq_mask_ack(struct irq_data *d)
 {
 	struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
 	struct ep93xx_gpio_irq_chip *eic = to_ep93xx_gpio_irq_chip(gc);
-	struct ep93xx_gpio *epg = gpiochip_get_data(gc);
-	int port_mask = BIT(d->irq & 7);
+	int port_mask = BIT(irqd_to_hwirq(d));
 
 	if (irqd_get_trigger_type(d) == IRQ_TYPE_EDGE_BOTH)
 		eic->int_type2 ^= port_mask; /* switch edge direction */
 
 	eic->int_unmasked &= ~port_mask;
-	ep93xx_gpio_update_int_params(epg, eic);
+	ep93xx_gpio_update_int_params(eic);
 
-	writeb(port_mask, epg->base + eic->irq_offset + EP93XX_INT_EOI_OFFSET);
+	writeb(port_mask, eic->base + EP93XX_INT_EOI_OFFSET);
 	gpiochip_disable_irq(gc, irqd_to_hwirq(d));
 }
 
@@ -192,10 +154,9 @@ static void ep93xx_gpio_irq_mask(struct irq_data *d)
 {
 	struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
 	struct ep93xx_gpio_irq_chip *eic = to_ep93xx_gpio_irq_chip(gc);
-	struct ep93xx_gpio *epg = gpiochip_get_data(gc);
 
-	eic->int_unmasked &= ~BIT(d->irq & 7);
-	ep93xx_gpio_update_int_params(epg, eic);
+	eic->int_unmasked &= ~BIT(irqd_to_hwirq(d));
+	ep93xx_gpio_update_int_params(eic);
 	gpiochip_disable_irq(gc, irqd_to_hwirq(d));
 }
 
@@ -203,11 +164,10 @@ static void ep93xx_gpio_irq_unmask(struct irq_data *d)
 {
 	struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
 	struct ep93xx_gpio_irq_chip *eic = to_ep93xx_gpio_irq_chip(gc);
-	struct ep93xx_gpio *epg = gpiochip_get_data(gc);
 
 	gpiochip_enable_irq(gc, irqd_to_hwirq(d));
-	eic->int_unmasked |= BIT(d->irq & 7);
-	ep93xx_gpio_update_int_params(epg, eic);
+	eic->int_unmasked |= BIT(irqd_to_hwirq(d));
+	ep93xx_gpio_update_int_params(eic);
 }
 
 /*
@@ -219,8 +179,7 @@ static int ep93xx_gpio_irq_type(struct irq_data *d, unsigned int type)
 {
 	struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
 	struct ep93xx_gpio_irq_chip *eic = to_ep93xx_gpio_irq_chip(gc);
-	struct ep93xx_gpio *epg = gpiochip_get_data(gc);
-	int offset = d->irq & 7;
+	irq_hw_number_t offset = irqd_to_hwirq(d);
 	int port_mask = BIT(offset);
 	irq_flow_handler_t handler;
 
@@ -264,51 +223,11 @@ static int ep93xx_gpio_irq_type(struct irq_data *d, unsigned int type)
 
 	eic->int_enabled |= port_mask;
 
-	ep93xx_gpio_update_int_params(epg, eic);
+	ep93xx_gpio_update_int_params(eic);
 
 	return 0;
 }
 
-/*************************************************************************
- * gpiolib interface for EP93xx on-chip GPIOs
- *************************************************************************/
-struct ep93xx_gpio_bank {
-	const char	*label;
-	int		data;
-	int		dir;
-	int		irq;
-	int		base;
-	bool		has_irq;
-	bool		has_hierarchical_irq;
-	unsigned int	irq_base;
-};
-
-#define EP93XX_GPIO_BANK(_label, _data, _dir, _irq, _base, _has_irq, _has_hier, _irq_base) \
-	{							\
-		.label		= _label,			\
-		.data		= _data,			\
-		.dir		= _dir,				\
-		.irq		= _irq,				\
-		.base		= _base,			\
-		.has_irq	= _has_irq,			\
-		.has_hierarchical_irq = _has_hier,		\
-		.irq_base	= _irq_base,			\
-	}
-
-static struct ep93xx_gpio_bank ep93xx_gpio_banks[] = {
-	/* Bank A has 8 IRQs */
-	EP93XX_GPIO_BANK("A", 0x00, 0x10, 0x90, 0, true, false, EP93XX_GPIO_A_IRQ_BASE),
-	/* Bank B has 8 IRQs */
-	EP93XX_GPIO_BANK("B", 0x04, 0x14, 0xac, 8, true, false, EP93XX_GPIO_B_IRQ_BASE),
-	EP93XX_GPIO_BANK("C", 0x08, 0x18, 0x00, 40, false, false, 0),
-	EP93XX_GPIO_BANK("D", 0x0c, 0x1c, 0x00, 24, false, false, 0),
-	EP93XX_GPIO_BANK("E", 0x20, 0x24, 0x00, 32, false, false, 0),
-	/* Bank F has 8 IRQs */
-	EP93XX_GPIO_BANK("F", 0x30, 0x34, 0x4c, 16, false, true, EP93XX_GPIO_F_IRQ_BASE),
-	EP93XX_GPIO_BANK("G", 0x38, 0x3c, 0x00, 48, false, false, 0),
-	EP93XX_GPIO_BANK("H", 0x40, 0x44, 0x00, 56, false, false, 0),
-};
-
 static int ep93xx_gpio_set_config(struct gpio_chip *gc, unsigned offset,
 				  unsigned long config)
 {
@@ -342,110 +261,102 @@ static const struct irq_chip gpio_eic_irq_chip = {
 	GPIOCHIP_IRQ_RESOURCE_HELPERS,
 };
 
-static int ep93xx_gpio_add_bank(struct ep93xx_gpio_chip *egc,
-				struct platform_device *pdev,
-				struct ep93xx_gpio *epg,
-				struct ep93xx_gpio_bank *bank)
+static int ep93xx_setup_irqs(struct platform_device *pdev,
+			     struct ep93xx_gpio_chip *egc)
 {
-	void __iomem *data = epg->base + bank->data;
-	void __iomem *dir = epg->base + bank->dir;
 	struct gpio_chip *gc = &egc->gc;
 	struct device *dev = &pdev->dev;
-	struct gpio_irq_chip *girq;
-	int err;
+	struct gpio_irq_chip *girq = &gc->irq;
+	int ret, irq, i;
+	void __iomem *intr;
 
-	err = bgpio_init(gc, dev, 1, data, NULL, NULL, dir, NULL, 0);
-	if (err)
-		return err;
+	intr = devm_platform_ioremap_resource_byname(pdev, "intr");
+	if (IS_ERR(intr))
+		return PTR_ERR(intr);
 
-	gc->label = bank->label;
-	gc->base = bank->base;
+	gc->set_config = ep93xx_gpio_set_config;
+	egc->eic = devm_kzalloc(dev, sizeof(*egc->eic), GFP_KERNEL);
+	if (!egc->eic)
+		return -ENOMEM;
 
-	girq = &gc->irq;
-	if (bank->has_irq || bank->has_hierarchical_irq) {
-		gc->set_config = ep93xx_gpio_set_config;
-		egc->eic = devm_kcalloc(dev, 1,
-					sizeof(*egc->eic),
-					GFP_KERNEL);
-		if (!egc->eic)
-			return -ENOMEM;
-		egc->eic->irq_offset = bank->irq;
-		gpio_irq_chip_set_chip(girq, &gpio_eic_irq_chip);
-	}
+	egc->eic->base = intr;
+	gpio_irq_chip_set_chip(girq, &gpio_eic_irq_chip);
+	girq->num_parents = platform_irq_count(pdev);
+	if (girq->num_parents == 0)
+		return -EINVAL;
 
-	if (bank->has_irq) {
-		int ab_parent_irq = platform_get_irq(pdev, 0);
+	girq->parents = devm_kcalloc(dev, girq->num_parents,
+				   sizeof(*girq->parents),
+				   GFP_KERNEL);
+	if (!girq->parents)
+		return -ENOMEM;
 
-		girq->parent_handler = ep93xx_gpio_ab_irq_handler;
-		girq->num_parents = 1;
-		girq->parents = devm_kcalloc(dev, girq->num_parents,
-					     sizeof(*girq->parents),
-					     GFP_KERNEL);
-		if (!girq->parents)
-			return -ENOMEM;
-		girq->default_type = IRQ_TYPE_NONE;
-		girq->handler = handle_level_irq;
-		girq->parents[0] = ab_parent_irq;
-		girq->first = bank->irq_base;
-	}
+	if (girq->num_parents == 1) { /* A/B irqchips */
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0)
+			return irq;
 
-	/* Only bank F has especially funky IRQ handling */
-	if (bank->has_hierarchical_irq) {
-		int gpio_irq;
-		int i;
+		ret = devm_request_irq(dev, irq, ep93xx_ab_irq_handler,
+				       IRQF_SHARED, gc->label, gc);
+		if (ret)
+			return dev_err_probe(dev, ret, "requesting IRQ: %d\n", irq);
 
-		/*
-		 * FIXME: convert this to use hierarchical IRQ support!
-		 * this requires fixing the root irqchip to be hierarchical.
-		 */
+		girq->parents[0] = irq;
+	} else { /* F irqchip */
 		girq->parent_handler = ep93xx_gpio_f_irq_handler;
-		girq->num_parents = 8;
-		girq->parents = devm_kcalloc(dev, girq->num_parents,
-					     sizeof(*girq->parents),
-					     GFP_KERNEL);
-		if (!girq->parents)
-			return -ENOMEM;
-		/* Pick resources 1..8 for these IRQs */
+
 		for (i = 0; i < girq->num_parents; i++) {
-			girq->parents[i] = platform_get_irq(pdev, i + 1);
-			gpio_irq = bank->irq_base + i;
-			irq_set_chip_data(gpio_irq, &epg->gc[5]);
-			irq_set_chip_and_handler(gpio_irq,
-						 girq->chip,
-						 handle_level_irq);
-			irq_clear_status_flags(gpio_irq, IRQ_NOREQUEST);
+			irq = platform_get_irq(pdev, i);
+			if (irq < 0)
+				continue;
+
+			girq->parents[i] = irq;
 		}
-		girq->default_type = IRQ_TYPE_NONE;
-		girq->handler = handle_level_irq;
-		girq->first = bank->irq_base;
+
+		girq->map = girq->parents;
 	}
 
-	return devm_gpiochip_add_data(dev, gc, epg);
+	girq->default_type = IRQ_TYPE_NONE;
+	/* TODO: replace with handle_bad_irq() once we are fully hierarchical */
+	girq->handler = handle_simple_irq;
+
+	return 0;
 }
 
 static int ep93xx_gpio_probe(struct platform_device *pdev)
 {
-	struct ep93xx_gpio *epg;
-	int i;
+	struct ep93xx_gpio_chip *egc;
+	struct gpio_chip *gc;
+	void __iomem *data;
+	void __iomem *dir;
+	int ret;
 
-	epg = devm_kzalloc(&pdev->dev, sizeof(*epg), GFP_KERNEL);
-	if (!epg)
+	egc = devm_kzalloc(&pdev->dev, sizeof(*egc), GFP_KERNEL);
+	if (!egc)
 		return -ENOMEM;
 
-	epg->base = devm_platform_ioremap_resource(pdev, 0);
-	if (IS_ERR(epg->base))
-		return PTR_ERR(epg->base);
+	data = devm_platform_ioremap_resource_byname(pdev, "data");
+	if (IS_ERR(data))
+		return PTR_ERR(data);
 
-	for (i = 0; i < ARRAY_SIZE(ep93xx_gpio_banks); i++) {
-		struct ep93xx_gpio_chip *gc = &epg->gc[i];
-		struct ep93xx_gpio_bank *bank = &ep93xx_gpio_banks[i];
+	dir = devm_platform_ioremap_resource_byname(pdev, "dir");
+	if (IS_ERR(dir))
+		return PTR_ERR(dir);
 
-		if (ep93xx_gpio_add_bank(gc, pdev, epg, bank))
-			dev_warn(&pdev->dev, "Unable to add gpio bank %s\n",
-				 bank->label);
+	gc = &egc->gc;
+	ret = bgpio_init(gc, &pdev->dev, 1, data, NULL, NULL, dir, NULL, 0);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret, "unable to init generic GPIO\n");
+
+	gc->label = dev_name(&pdev->dev);
+	if (platform_irq_count(pdev) > 0) {
+		dev_dbg(&pdev->dev, "setting up irqs for %s\n", dev_name(&pdev->dev));
+		ret = ep93xx_setup_irqs(pdev, egc);
+		if (ret)
+			dev_err_probe(&pdev->dev, ret, "setup irqs failed");
 	}
 
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, gc, egc);
 }
 
 static struct platform_driver ep93xx_gpio_driver = {

-- 
2.41.0



From devnull+nikita.shubin.maquefel.me at kernel.org  Tue Dec 12 00:20:46 2023
From: devnull+nikita.shubin.maquefel.me at kernel.org (Nikita Shubin via B4 Relay)
Date: Tue, 12 Dec 2023 11:20:46 +0300
Subject: [PATCH v6 29/40] ASoC: dt-bindings: ep93xx: Document Audio Port
 support
In-Reply-To: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
Message-ID: <20231212-ep93xx-v6-29-c307b8ac9aa8@maquefel.me>

From: Nikita Shubin <nikita.shubin at maquefel.me>

Document Audio Graph Port support in binding document.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Nikita Shubin <nikita.shubin at maquefel.me>
---
 Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml
index 36a320ddf534..4693e85aed37 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml
@@ -50,6 +50,10 @@ properties:
       - const: tx
       - const: rx
 
+  port:
+    $ref: audio-graph-port.yaml#
+    unevaluatedProperties: false
+
 required:
   - compatible
   - '#sound-dai-cells'

-- 
2.41.0



From devnull+nikita.shubin.maquefel.me at kernel.org  Tue Dec 12 00:20:52 2023
From: devnull+nikita.shubin.maquefel.me at kernel.org (Nikita Shubin via B4 Relay)
Date: Tue, 12 Dec 2023 11:20:52 +0300
Subject: [PATCH v6 35/40] pwm: ep93xx: drop legacy pinctrl
In-Reply-To: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
Message-ID: <20231212-ep93xx-v6-35-c307b8ac9aa8@maquefel.me>

From: Nikita Shubin <nikita.shubin at maquefel.me>

Drop legacy gpio request/free since we are using
pinctrl for this now.

Acked-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Acked-by: Thierry Reding <thierry.reding at gmail.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Nikita Shubin <nikita.shubin at maquefel.me>
---
 arch/arm/mach-ep93xx/core.c       | 42 ---------------------------------------
 drivers/pwm/pwm-ep93xx.c          | 18 -----------------
 include/linux/soc/cirrus/ep93xx.h |  4 ----
 3 files changed, 64 deletions(-)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index b99c46d22c4d..4ddf1a4cba33 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -577,48 +577,6 @@ void __init ep93xx_register_pwm(int pwm0, int pwm1)
 		platform_device_register(&ep93xx_pwm1_device);
 }
 
-int ep93xx_pwm_acquire_gpio(struct platform_device *pdev)
-{
-	int err;
-
-	if (pdev->id == 0) {
-		err = 0;
-	} else if (pdev->id == 1) {
-		err = gpio_request(EP93XX_GPIO_LINE_EGPIO14,
-				   dev_name(&pdev->dev));
-		if (err)
-			return err;
-		err = gpio_direction_output(EP93XX_GPIO_LINE_EGPIO14, 0);
-		if (err)
-			goto fail;
-
-		/* PWM 1 output on EGPIO[14] */
-		ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_PONG);
-	} else {
-		err = -ENODEV;
-	}
-
-	return err;
-
-fail:
-	gpio_free(EP93XX_GPIO_LINE_EGPIO14);
-	return err;
-}
-EXPORT_SYMBOL(ep93xx_pwm_acquire_gpio);
-
-void ep93xx_pwm_release_gpio(struct platform_device *pdev)
-{
-	if (pdev->id == 1) {
-		gpio_direction_input(EP93XX_GPIO_LINE_EGPIO14);
-		gpio_free(EP93XX_GPIO_LINE_EGPIO14);
-
-		/* EGPIO[14] used for GPIO */
-		ep93xx_devcfg_clear_bits(EP93XX_SYSCON_DEVCFG_PONG);
-	}
-}
-EXPORT_SYMBOL(ep93xx_pwm_release_gpio);
-
-
 /*************************************************************************
  * EP93xx video peripheral handling
  *************************************************************************/
diff --git a/drivers/pwm/pwm-ep93xx.c b/drivers/pwm/pwm-ep93xx.c
index 7cf05d0b78fb..0d17dbe10fcf 100644
--- a/drivers/pwm/pwm-ep93xx.c
+++ b/drivers/pwm/pwm-ep93xx.c
@@ -27,8 +27,6 @@
 
 #include <asm/div64.h>
 
-#include <linux/soc/cirrus/ep93xx.h>	/* for ep93xx_pwm_{acquire,release}_gpio() */
-
 #define EP93XX_PWMx_TERM_COUNT	0x00
 #define EP93XX_PWMx_DUTY_CYCLE	0x04
 #define EP93XX_PWMx_ENABLE	0x08
@@ -45,20 +43,6 @@ static inline struct ep93xx_pwm *to_ep93xx_pwm(struct pwm_chip *chip)
 	return container_of(chip, struct ep93xx_pwm, chip);
 }
 
-static int ep93xx_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-	struct platform_device *pdev = to_platform_device(chip->dev);
-
-	return ep93xx_pwm_acquire_gpio(pdev);
-}
-
-static void ep93xx_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-	struct platform_device *pdev = to_platform_device(chip->dev);
-
-	ep93xx_pwm_release_gpio(pdev);
-}
-
 static int ep93xx_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 			    const struct pwm_state *state)
 {
@@ -157,8 +141,6 @@ static int ep93xx_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 }
 
 static const struct pwm_ops ep93xx_pwm_ops = {
-	.request = ep93xx_pwm_request,
-	.free = ep93xx_pwm_free,
 	.apply = ep93xx_pwm_apply,
 };
 
diff --git a/include/linux/soc/cirrus/ep93xx.h b/include/linux/soc/cirrus/ep93xx.h
index ea2b2c1074e4..fc4a2f9d4729 100644
--- a/include/linux/soc/cirrus/ep93xx.h
+++ b/include/linux/soc/cirrus/ep93xx.h
@@ -37,8 +37,6 @@ struct ep93xx_regmap_adev {
 	container_of((_adev), struct ep93xx_regmap_adev, adev)
 
 #ifdef CONFIG_ARCH_EP93XX
-int ep93xx_pwm_acquire_gpio(struct platform_device *pdev);
-void ep93xx_pwm_release_gpio(struct platform_device *pdev);
 int ep93xx_ide_acquire_gpio(struct platform_device *pdev);
 void ep93xx_ide_release_gpio(struct platform_device *pdev);
 int ep93xx_i2s_acquire(void);
@@ -46,8 +44,6 @@ void ep93xx_i2s_release(void);
 unsigned int ep93xx_chip_revision(void);
 
 #else
-static inline int ep93xx_pwm_acquire_gpio(struct platform_device *pdev) { return 0; }
-static inline void ep93xx_pwm_release_gpio(struct platform_device *pdev) {}
 static inline int ep93xx_ide_acquire_gpio(struct platform_device *pdev) { return 0; }
 static inline void ep93xx_ide_release_gpio(struct platform_device *pdev) {}
 static inline int ep93xx_i2s_acquire(void) { return 0; }

-- 
2.41.0



From devnull+nikita.shubin.maquefel.me at kernel.org  Tue Dec 12 00:20:45 2023
From: devnull+nikita.shubin.maquefel.me at kernel.org (Nikita Shubin via B4 Relay)
Date: Tue, 12 Dec 2023 11:20:45 +0300
Subject: [PATCH v6 28/40] ASoC: dt-bindings: ep93xx: Document DMA support
In-Reply-To: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
Message-ID: <20231212-ep93xx-v6-28-c307b8ac9aa8@maquefel.me>

From: Nikita Shubin <nikita.shubin at maquefel.me>

Document DMA support in binding document.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Nikita Shubin <nikita.shubin at maquefel.me>
---
 .../devicetree/bindings/sound/cirrus,ep9301-i2s.yaml         | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml
index 453d493c941f..36a320ddf534 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml
@@ -40,6 +40,16 @@ properties:
       - const: sclk
       - const: lrclk
 
+  dmas:
+    items:
+      - description: out DMA channel
+      - description: in DMA channel
+
+  dma-names:
+    items:
+      - const: tx
+      - const: rx
+
 required:
   - compatible
   - '#sound-dai-cells'
@@ -61,6 +71,8 @@ examples:
                  <&syscon 30>,
                  <&syscon 31>;
         clock-names = "mclk", "sclk", "lrclk";
+        dmas = <&dma0 0 1>, <&dma0 0 2>;
+        dma-names = "tx", "rx";
     };
 
 ...

-- 
2.41.0



From devnull+nikita.shubin.maquefel.me at kernel.org  Tue Dec 12 00:20:53 2023
From: devnull+nikita.shubin.maquefel.me at kernel.org (Nikita Shubin via B4 Relay)
Date: Tue, 12 Dec 2023 11:20:53 +0300
Subject: [PATCH v6 36/40] ata: pata_ep93xx: remove legacy pinctrl use
In-Reply-To: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
Message-ID: <20231212-ep93xx-v6-36-c307b8ac9aa8@maquefel.me>

From: Nikita Shubin <nikita.shubin at maquefel.me>

Drop legacy acquire/release since we are using pinctrl for this now.

Reviewed-by: Sergey Shtylyov <s.shtylyov at omp.ru>
Acked-by: Damien Le Moal <dlemoal at kernel.org>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Signed-off-by: Nikita Shubin <nikita.shubin at maquefel.me>
---
 arch/arm/mach-ep93xx/core.c       | 72 ---------------------------------------
 drivers/ata/pata_ep93xx.c         | 29 +++++-----------
 include/linux/soc/cirrus/ep93xx.h |  4 ---
 3 files changed, 8 insertions(+), 97 deletions(-)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 4ddf1a4cba33..9c6154bb37b5 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -779,78 +779,6 @@ void __init ep93xx_register_ide(void)
 	platform_device_register(&ep93xx_ide_device);
 }
 
-int ep93xx_ide_acquire_gpio(struct platform_device *pdev)
-{
-	int err;
-	int i;
-
-	err = gpio_request(EP93XX_GPIO_LINE_EGPIO2, dev_name(&pdev->dev));
-	if (err)
-		return err;
-	err = gpio_request(EP93XX_GPIO_LINE_EGPIO15, dev_name(&pdev->dev));
-	if (err)
-		goto fail_egpio15;
-	for (i = 2; i < 8; i++) {
-		err = gpio_request(EP93XX_GPIO_LINE_E(i), dev_name(&pdev->dev));
-		if (err)
-			goto fail_gpio_e;
-	}
-	for (i = 4; i < 8; i++) {
-		err = gpio_request(EP93XX_GPIO_LINE_G(i), dev_name(&pdev->dev));
-		if (err)
-			goto fail_gpio_g;
-	}
-	for (i = 0; i < 8; i++) {
-		err = gpio_request(EP93XX_GPIO_LINE_H(i), dev_name(&pdev->dev));
-		if (err)
-			goto fail_gpio_h;
-	}
-
-	/* GPIO ports E[7:2], G[7:4] and H used by IDE */
-	ep93xx_devcfg_clear_bits(EP93XX_SYSCON_DEVCFG_EONIDE |
-				 EP93XX_SYSCON_DEVCFG_GONIDE |
-				 EP93XX_SYSCON_DEVCFG_HONIDE);
-	return 0;
-
-fail_gpio_h:
-	for (--i; i >= 0; --i)
-		gpio_free(EP93XX_GPIO_LINE_H(i));
-	i = 8;
-fail_gpio_g:
-	for (--i; i >= 4; --i)
-		gpio_free(EP93XX_GPIO_LINE_G(i));
-	i = 8;
-fail_gpio_e:
-	for (--i; i >= 2; --i)
-		gpio_free(EP93XX_GPIO_LINE_E(i));
-	gpio_free(EP93XX_GPIO_LINE_EGPIO15);
-fail_egpio15:
-	gpio_free(EP93XX_GPIO_LINE_EGPIO2);
-	return err;
-}
-EXPORT_SYMBOL(ep93xx_ide_acquire_gpio);
-
-void ep93xx_ide_release_gpio(struct platform_device *pdev)
-{
-	int i;
-
-	for (i = 2; i < 8; i++)
-		gpio_free(EP93XX_GPIO_LINE_E(i));
-	for (i = 4; i < 8; i++)
-		gpio_free(EP93XX_GPIO_LINE_G(i));
-	for (i = 0; i < 8; i++)
-		gpio_free(EP93XX_GPIO_LINE_H(i));
-	gpio_free(EP93XX_GPIO_LINE_EGPIO15);
-	gpio_free(EP93XX_GPIO_LINE_EGPIO2);
-
-
-	/* GPIO ports E[7:2], G[7:4] and H used by GPIO */
-	ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_EONIDE |
-			       EP93XX_SYSCON_DEVCFG_GONIDE |
-			       EP93XX_SYSCON_DEVCFG_HONIDE);
-}
-EXPORT_SYMBOL(ep93xx_ide_release_gpio);
-
 /*************************************************************************
  * EP93xx ADC
  *************************************************************************/
diff --git a/drivers/ata/pata_ep93xx.c b/drivers/ata/pata_ep93xx.c
index 3f33916c2d23..83c2a0162cb0 100644
--- a/drivers/ata/pata_ep93xx.c
+++ b/drivers/ata/pata_ep93xx.c
@@ -652,13 +652,13 @@ static int ep93xx_pata_dma_init(struct ep93xx_pata_data *drv_data)
 	 * start of new transfer.
 	 */
 	drv_data->dma_rx_channel = dma_request_chan(dev, "rx");
-	if (IS_ERR(drv_data->dma_rx_channel)) {
+	if (PTR_ERR_OR_ZERO(drv_data->dma_rx_channel)) {
 		ret = PTR_ERR(drv_data->dma_rx_channel);
 		return dev_err_probe(dev, ret, "rx DMA setup failed");
 	}
 
 	drv_data->dma_tx_channel = dma_request_chan(&pdev->dev, "tx");
-	if (IS_ERR(drv_data->dma_tx_channel)) {
+	if (PTR_ERR_OR_ZERO(drv_data->dma_tx_channel)) {
 		ret = PTR_ERR(drv_data->dma_tx_channel);
 		dev_err_probe(dev, ret, "tx DMA setup failed");
 		goto fail_release_rx;
@@ -923,28 +923,18 @@ static int ep93xx_pata_probe(struct platform_device *pdev)
 	void __iomem *ide_base;
 	int err;
 
-	err = ep93xx_ide_acquire_gpio(pdev);
-	if (err)
-		return err;
-
 	/* INT[3] (IRQ_EP93XX_EXT3) line connected as pull down */
 	irq = platform_get_irq(pdev, 0);
-	if (irq < 0) {
-		err = irq;
-		goto err_rel_gpio;
-	}
+	if (irq < 0)
+		return irq;
 
 	ide_base = devm_platform_get_and_ioremap_resource(pdev, 0, &mem_res);
-	if (IS_ERR(ide_base)) {
-		err = PTR_ERR(ide_base);
-		goto err_rel_gpio;
-	}
+	if (IS_ERR(ide_base))
+		return PTR_ERR(ide_base);
 
 	drv_data = devm_kzalloc(&pdev->dev, sizeof(*drv_data), GFP_KERNEL);
-	if (!drv_data) {
-		err = -ENOMEM;
-		goto err_rel_gpio;
-	}
+	if (!drv_data)
+		return -ENOMEM;
 
 	drv_data->pdev = pdev;
 	drv_data->ide_base = ide_base;
@@ -1003,8 +993,6 @@ static int ep93xx_pata_probe(struct platform_device *pdev)
 
 err_rel_dma:
 	ep93xx_pata_release_dma(drv_data);
-err_rel_gpio:
-	ep93xx_ide_release_gpio(pdev);
 	return err;
 }
 
@@ -1016,7 +1004,6 @@ static void ep93xx_pata_remove(struct platform_device *pdev)
 	ata_host_detach(host);
 	ep93xx_pata_release_dma(drv_data);
 	ep93xx_pata_clear_regs(drv_data->ide_base);
-	ep93xx_ide_release_gpio(pdev);
 }
 
 static const struct of_device_id ep93xx_pata_of_ids[] = {
diff --git a/include/linux/soc/cirrus/ep93xx.h b/include/linux/soc/cirrus/ep93xx.h
index fc4a2f9d4729..da8bdfc36526 100644
--- a/include/linux/soc/cirrus/ep93xx.h
+++ b/include/linux/soc/cirrus/ep93xx.h
@@ -37,15 +37,11 @@ struct ep93xx_regmap_adev {
 	container_of((_adev), struct ep93xx_regmap_adev, adev)
 
 #ifdef CONFIG_ARCH_EP93XX
-int ep93xx_ide_acquire_gpio(struct platform_device *pdev);
-void ep93xx_ide_release_gpio(struct platform_device *pdev);
 int ep93xx_i2s_acquire(void);
 void ep93xx_i2s_release(void);
 unsigned int ep93xx_chip_revision(void);
 
 #else
-static inline int ep93xx_ide_acquire_gpio(struct platform_device *pdev) { return 0; }
-static inline void ep93xx_ide_release_gpio(struct platform_device *pdev) {}
 static inline int ep93xx_i2s_acquire(void) { return 0; }
 static inline void ep93xx_i2s_release(void) {}
 static inline unsigned int ep93xx_chip_revision(void) { return 0; }

-- 
2.41.0



From devnull+nikita.shubin.maquefel.me at kernel.org  Tue Dec 12 00:20:41 2023
From: devnull+nikita.shubin.maquefel.me at kernel.org (Nikita Shubin via B4 Relay)
Date: Tue, 12 Dec 2023 11:20:41 +0300
Subject: [PATCH v6 24/40] input: keypad: ep93xx: add DT support for Cirrus
 EP93xx
In-Reply-To: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
Message-ID: <20231212-ep93xx-v6-24-c307b8ac9aa8@maquefel.me>

From: Nikita Shubin <nikita.shubin at maquefel.me>

- drop flags, they were not used anyway
- add OF ID match table
- process "autorepeat", "debounce-delay-ms", prescale from device tree
- drop platform data usage and it's header
- keymap goes from device tree now on

Acked-by: Dmitry Torokhov <dmitry.torokhov at gmail.com>
Signed-off-by: Nikita Shubin <nikita.shubin at maquefel.me>
---
 arch/arm/mach-ep93xx/core.c            | 46 ---------------------
 drivers/input/keyboard/ep93xx_keypad.c | 74 ++++++++++------------------------
 include/linux/soc/cirrus/ep93xx.h      |  4 --
 3 files changed, 22 insertions(+), 102 deletions(-)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 03bce5e9d1f1..b99c46d22c4d 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -697,52 +697,6 @@ void __init ep93xx_register_keypad(struct ep93xx_keypad_platform_data *data)
 	platform_device_register(&ep93xx_keypad_device);
 }
 
-int ep93xx_keypad_acquire_gpio(struct platform_device *pdev)
-{
-	int err;
-	int i;
-
-	for (i = 0; i < 8; i++) {
-		err = gpio_request(EP93XX_GPIO_LINE_C(i), dev_name(&pdev->dev));
-		if (err)
-			goto fail_gpio_c;
-		err = gpio_request(EP93XX_GPIO_LINE_D(i), dev_name(&pdev->dev));
-		if (err)
-			goto fail_gpio_d;
-	}
-
-	/* Enable the keypad controller; GPIO ports C and D used for keypad */
-	ep93xx_devcfg_clear_bits(EP93XX_SYSCON_DEVCFG_KEYS |
-				 EP93XX_SYSCON_DEVCFG_GONK);
-
-	return 0;
-
-fail_gpio_d:
-	gpio_free(EP93XX_GPIO_LINE_C(i));
-fail_gpio_c:
-	for (--i; i >= 0; --i) {
-		gpio_free(EP93XX_GPIO_LINE_C(i));
-		gpio_free(EP93XX_GPIO_LINE_D(i));
-	}
-	return err;
-}
-EXPORT_SYMBOL(ep93xx_keypad_acquire_gpio);
-
-void ep93xx_keypad_release_gpio(struct platform_device *pdev)
-{
-	int i;
-
-	for (i = 0; i < 8; i++) {
-		gpio_free(EP93XX_GPIO_LINE_C(i));
-		gpio_free(EP93XX_GPIO_LINE_D(i));
-	}
-
-	/* Disable the keypad controller; GPIO ports C and D used for GPIO */
-	ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_KEYS |
-			       EP93XX_SYSCON_DEVCFG_GONK);
-}
-EXPORT_SYMBOL(ep93xx_keypad_release_gpio);
-
 /*************************************************************************
  * EP93xx I2S audio peripheral handling
  *************************************************************************/
diff --git a/drivers/input/keyboard/ep93xx_keypad.c b/drivers/input/keyboard/ep93xx_keypad.c
index 6b811d6bf625..515880c194c9 100644
--- a/drivers/input/keyboard/ep93xx_keypad.c
+++ b/drivers/input/keyboard/ep93xx_keypad.c
@@ -6,20 +6,13 @@
  *
  * Based on the pxa27x matrix keypad controller by Rodolfo Giometti.
  *
- * NOTE:
- *
- * The 3-key reset is triggered by pressing the 3 keys in
- * Row 0, Columns 2, 4, and 7 at the same time.  This action can
- * be disabled by setting the EP93XX_KEYPAD_DISABLE_3_KEY flag.
- *
- * Normal operation for the matrix does not autorepeat the key press.
- * This action can be enabled by setting the EP93XX_KEYPAD_AUTOREPEAT
- * flag.
  */
 
 #include <linux/bits.h>
+#include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/property.h>
 #include <linux/interrupt.h>
 #include <linux/clk.h>
 #include <linux/io.h>
@@ -27,7 +20,6 @@
 #include <linux/input/matrix_keypad.h>
 #include <linux/slab.h>
 #include <linux/soc/cirrus/ep93xx.h>
-#include <linux/platform_data/keypad-ep93xx.h>
 #include <linux/pm_wakeirq.h>
 
 /*
@@ -61,12 +53,16 @@
 #define KEY_REG_KEY1_MASK	GENMASK(5, 0)
 #define KEY_REG_KEY1_SHIFT	0
 
+#define EP93XX_MATRIX_ROWS		(8)
+#define EP93XX_MATRIX_COLS		(8)
+
 #define EP93XX_MATRIX_SIZE	(EP93XX_MATRIX_ROWS * EP93XX_MATRIX_COLS)
 
 struct ep93xx_keypad {
-	struct ep93xx_keypad_platform_data *pdata;
 	struct input_dev *input_dev;
 	struct clk *clk;
+	unsigned int	debounce;
+	uint16_t	prescale;
 
 	void __iomem *mmio_base;
 
@@ -133,23 +129,11 @@ static irqreturn_t ep93xx_keypad_irq_handler(int irq, void *dev_id)
 
 static void ep93xx_keypad_config(struct ep93xx_keypad *keypad)
 {
-	struct ep93xx_keypad_platform_data *pdata = keypad->pdata;
 	unsigned int val = 0;
 
-	clk_set_rate(keypad->clk, pdata->clk_rate);
+	val |= ((keypad->debounce << KEY_INIT_DBNC_SHIFT) & KEY_INIT_DBNC_MASK);
 
-	if (pdata->flags & EP93XX_KEYPAD_DISABLE_3_KEY)
-		val |= KEY_INIT_DIS3KY;
-	if (pdata->flags & EP93XX_KEYPAD_DIAG_MODE)
-		val |= KEY_INIT_DIAG;
-	if (pdata->flags & EP93XX_KEYPAD_BACK_DRIVE)
-		val |= KEY_INIT_BACK;
-	if (pdata->flags & EP93XX_KEYPAD_TEST_MODE)
-		val |= KEY_INIT_T2;
-
-	val |= ((pdata->debounce << KEY_INIT_DBNC_SHIFT) & KEY_INIT_DBNC_MASK);
-
-	val |= ((pdata->prescale << KEY_INIT_PRSCL_SHIFT) & KEY_INIT_PRSCL_MASK);
+	val |= ((keypad->prescale << KEY_INIT_PRSCL_SHIFT) & KEY_INIT_PRSCL_MASK);
 
 	__raw_writel(val, keypad->mmio_base + KEY_INIT);
 }
@@ -220,17 +204,10 @@ static int ep93xx_keypad_resume(struct device *dev)
 static DEFINE_SIMPLE_DEV_PM_OPS(ep93xx_keypad_pm_ops,
 				ep93xx_keypad_suspend, ep93xx_keypad_resume);
 
-static void ep93xx_keypad_release_gpio_action(void *_pdev)
-{
-	struct platform_device *pdev = _pdev;
-
-	ep93xx_keypad_release_gpio(pdev);
-}
-
 static int ep93xx_keypad_probe(struct platform_device *pdev)
 {
+	struct device *dev = &pdev->dev;
 	struct ep93xx_keypad *keypad;
-	const struct matrix_keymap_data *keymap_data;
 	struct input_dev *input_dev;
 	int err;
 
@@ -238,14 +215,6 @@ static int ep93xx_keypad_probe(struct platform_device *pdev)
 	if (!keypad)
 		return -ENOMEM;
 
-	keypad->pdata = dev_get_platdata(&pdev->dev);
-	if (!keypad->pdata)
-		return -EINVAL;
-
-	keymap_data = keypad->pdata->keymap_data;
-	if (!keymap_data)
-		return -EINVAL;
-
 	keypad->irq = platform_get_irq(pdev, 0);
 	if (keypad->irq < 0)
 		return keypad->irq;
@@ -254,19 +223,13 @@ static int ep93xx_keypad_probe(struct platform_device *pdev)
 	if (IS_ERR(keypad->mmio_base))
 		return PTR_ERR(keypad->mmio_base);
 
-	err = ep93xx_keypad_acquire_gpio(pdev);
-	if (err)
-		return err;
-
-	err = devm_add_action_or_reset(&pdev->dev,
-				       ep93xx_keypad_release_gpio_action, pdev);
-	if (err)
-		return err;
-
 	keypad->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(keypad->clk))
 		return PTR_ERR(keypad->clk);
 
+	device_property_read_u32(dev, "debounce-delay-ms", &keypad->debounce);
+	device_property_read_u16(dev, "cirrus,prescale", &keypad->prescale);
+
 	input_dev = devm_input_allocate_device(&pdev->dev);
 	if (!input_dev)
 		return -ENOMEM;
@@ -278,13 +241,13 @@ static int ep93xx_keypad_probe(struct platform_device *pdev)
 	input_dev->open = ep93xx_keypad_open;
 	input_dev->close = ep93xx_keypad_close;
 
-	err = matrix_keypad_build_keymap(keymap_data, NULL,
+	err = matrix_keypad_build_keymap(NULL, NULL,
 					 EP93XX_MATRIX_ROWS, EP93XX_MATRIX_COLS,
 					 keypad->keycodes, input_dev);
 	if (err)
 		return err;
 
-	if (keypad->pdata->flags & EP93XX_KEYPAD_AUTOREPEAT)
+	if (device_property_read_bool(&pdev->dev, "autorepeat"))
 		__set_bit(EV_REP, input_dev->evbit);
 	input_set_drvdata(input_dev, keypad);
 
@@ -313,10 +276,17 @@ static void ep93xx_keypad_remove(struct platform_device *pdev)
 	dev_pm_clear_wake_irq(&pdev->dev);
 }
 
+static const struct of_device_id ep93xx_keypad_of_ids[] = {
+	{ .compatible = "cirrus,ep9307-keypad" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ep93xx_keypad_of_ids);
+
 static struct platform_driver ep93xx_keypad_driver = {
 	.driver		= {
 		.name	= "ep93xx-keypad",
 		.pm	= pm_sleep_ptr(&ep93xx_keypad_pm_ops),
+		.of_match_table = ep93xx_keypad_of_ids,
 	},
 	.probe		= ep93xx_keypad_probe,
 	.remove_new	= ep93xx_keypad_remove,
diff --git a/include/linux/soc/cirrus/ep93xx.h b/include/linux/soc/cirrus/ep93xx.h
index fc35be3af723..ea2b2c1074e4 100644
--- a/include/linux/soc/cirrus/ep93xx.h
+++ b/include/linux/soc/cirrus/ep93xx.h
@@ -41,8 +41,6 @@ int ep93xx_pwm_acquire_gpio(struct platform_device *pdev);
 void ep93xx_pwm_release_gpio(struct platform_device *pdev);
 int ep93xx_ide_acquire_gpio(struct platform_device *pdev);
 void ep93xx_ide_release_gpio(struct platform_device *pdev);
-int ep93xx_keypad_acquire_gpio(struct platform_device *pdev);
-void ep93xx_keypad_release_gpio(struct platform_device *pdev);
 int ep93xx_i2s_acquire(void);
 void ep93xx_i2s_release(void);
 unsigned int ep93xx_chip_revision(void);
@@ -52,8 +50,6 @@ static inline int ep93xx_pwm_acquire_gpio(struct platform_device *pdev) { return
 static inline void ep93xx_pwm_release_gpio(struct platform_device *pdev) {}
 static inline int ep93xx_ide_acquire_gpio(struct platform_device *pdev) { return 0; }
 static inline void ep93xx_ide_release_gpio(struct platform_device *pdev) {}
-static inline int ep93xx_keypad_acquire_gpio(struct platform_device *pdev) { return 0; }
-static inline void ep93xx_keypad_release_gpio(struct platform_device *pdev) {}
 static inline int ep93xx_i2s_acquire(void) { return 0; }
 static inline void ep93xx_i2s_release(void) {}
 static inline unsigned int ep93xx_chip_revision(void) { return 0; }

-- 
2.41.0



From devnull+nikita.shubin.maquefel.me at kernel.org  Tue Dec 12 00:20:51 2023
From: devnull+nikita.shubin.maquefel.me at kernel.org (Nikita Shubin via B4 Relay)
Date: Tue, 12 Dec 2023 11:20:51 +0300
Subject: [PATCH v6 34/40] ARM: ep93xx: DT for the Cirrus ep93xx SoC
 platforms
In-Reply-To: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
Message-ID: <20231212-ep93xx-v6-34-c307b8ac9aa8@maquefel.me>

From: Nikita Shubin <nikita.shubin at maquefel.me>

Add compulsory device tree support to the Cirrus ep93xx ARMv4 platform.

- select PINCTRL_EP93xx
- select COMMON_CLK_EP93XX, as clock driver moved out of platform code
- select ARCH_HAS_RESET_CONTROLLER

Select ARM_ATAG_DTB_COMPAT to update device tree with information
about memory passed from bootloader.

We have to leave all MACH options as they are used for board checking
before decomp, to turn off watchdog and ethernet DMA.

Tested-by: Alexander Sverdlin <alexander.sverdlin at gmail.com>
Signed-off-by: Nikita Shubin <nikita.shubin at maquefel.me>
---
 arch/arm/Makefile             |  1 -
 arch/arm/mach-ep93xx/Kconfig  | 20 ++++++++++----------
 arch/arm/mach-ep93xx/Makefile | 11 -----------
 3 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5ba42f69f8ce..82349c2d7b17 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -179,7 +179,6 @@ machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_DAVINCI)		+= davinci
 machine-$(CONFIG_ARCH_DIGICOLOR)	+= digicolor
 machine-$(CONFIG_ARCH_DOVE)		+= dove
-machine-$(CONFIG_ARCH_EP93XX)		+= ep93xx
 machine-$(CONFIG_ARCH_EXYNOS)		+= exynos
 machine-$(CONFIG_ARCH_FOOTBRIDGE)	+= footbridge
 machine-$(CONFIG_ARCH_GEMINI)		+= gemini
diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index 703f3d232a60..812b71dcf60e 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -3,27 +3,27 @@ menuconfig ARCH_EP93XX
 	bool "EP93xx-based"
 	depends on ATAGS
 	depends on ARCH_MULTI_V4T
+	# CONFIG_ARCH_MULTI_V7 is not set
 	depends on CPU_LITTLE_ENDIAN
+	select ARCH_HAS_RESET_CONTROLLER
 	select ARCH_SPARSEMEM_ENABLE
 	select ARM_AMBA
 	select ARM_VIC
+	select ARM_APPENDED_DTB # Old Redboot bootloaders deployed
+	select ARM_ATAG_DTB_COMPAT # we need this to update dt memory node
+	select COMMON_CLK_EP93XX
+	select EP93XX_TIMER
 	select CLKSRC_MMIO
 	select CPU_ARM920T
 	select GPIOLIB
+	select PINCTRL
+	select PINCTRL_EP93XX
 	help
 	  This enables support for the Cirrus EP93xx series of CPUs.
 
 if ARCH_EP93XX
 
-menu "Cirrus EP93xx Implementation Options"
-
-config EP93XX_SOC_COMMON
-	bool
-	default y
-	select SOC_BUS
-	select LEDS_GPIO_REGISTER
-
-comment "EP93xx Platforms"
+# menu "EP93xx Platforms"
 
 config MACH_BK3
 	bool "Support Liebherr BK3.1"
@@ -103,6 +103,6 @@ config MACH_VISION_EP9307
 	  Say 'Y' here if you want your kernel to support the
 	  Vision Engraving Systems EP9307 SoM.
 
-endmenu
+# endmenu
 
 endif
diff --git a/arch/arm/mach-ep93xx/Makefile b/arch/arm/mach-ep93xx/Makefile
deleted file mode 100644
index 62e37403df14..000000000000
--- a/arch/arm/mach-ep93xx/Makefile
+++ /dev/null
@@ -1,11 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-#
-# Makefile for the linux kernel.
-#
-obj-y			:= core.o clock.o timer-ep93xx.o
-
-obj-$(CONFIG_EP93XX_DMA)	+= dma.o
-
-obj-$(CONFIG_MACH_EDB93XX)	+= edb93xx.o
-obj-$(CONFIG_MACH_TS72XX)	+= ts72xx.o
-obj-$(CONFIG_MACH_VISION_EP9307)+= vision_ep9307.o

-- 
2.41.0



From vincent.guittot at linaro.org  Tue Dec 12 00:32:06 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Tue, 12 Dec 2023 09:32:06 +0100
Subject: [PATCH v7 0/7] consolidate and cleanup CPU capacity
In-Reply-To: <CAJZ5v0i37gGqt=oGC4BxJ4hT5pxhAdL7dPxGf7w3D8THqwAOwQ@mail.gmail.com>
References: <20231211104855.558096-1-vincent.guittot@linaro.org> <CAJZ5v0i37gGqt=oGC4BxJ4hT5pxhAdL7dPxGf7w3D8THqwAOwQ@mail.gmail.com>
Message-ID: <CAKfTPtDXLDpGChy7UXVsV75NHK1OPGHaGYf5G663HWnau4kAHg@mail.gmail.com>

On Mon, 11 Dec 2023 at 20:52, Rafael J. Wysocki <rafael at kernel.org> wrote:
>
> On Mon, Dec 11, 2023 at 11:49?AM Vincent Guittot
> <vincent.guittot at linaro.org> wrote:

[..]

> >
> > Vincent Guittot (7):
> >   topology: Add a new arch_scale_freq_reference
> >   cpufreq: Use the fixed and coherent frequency for scaling capacity
> >   cpufreq/schedutil: Use a fixed reference frequency
> >   energy_model: Use a fixed reference frequency
> >   cpufreq/cppc: Move and rename cppc_cpufreq_{perf_to_khz|khz_to_perf}
> >   cpufreq/cppc: Set the frequency used for computing the capacity
> >   arm64/amu: Use capacity_ref_freq to set AMU ratio
>
> This series touches multiple places, but mostly schedutil, cpufreq and
> the EM, so please let me know if you want me to pick it up.

This serie has been rebased on top of tip/ched/core to fix a conflict
with another change already queued in kernel/sched/cpufreq_schedutil.c


From sean at mess.org  Tue Dec 12 00:34:00 2023
From: sean at mess.org (Sean Young)
Date: Tue, 12 Dec 2023 08:34:00 +0000
Subject: [PATCH v8 1/6] pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
In-Reply-To: <cover.1702369869.git.sean@mess.org>
References: <cover.1702369869.git.sean@mess.org>
Message-ID: <9af7ba748fd2eb7e04208b6b183185f1daf78016.1702369869.git.sean@mess.org>

In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:

	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
	int pwm_apply_atomic(struct pwm *, struct pwm_state *);

This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.

Acked-by: Dmitry Torokhov <dmitry.torokhov at gmail.com> # for input
Acked-by: Hans de Goede <hdegoede at redhat.com>
Acked-by: Jani Nikula <jani.nikula at intel.com>
Acked-by: Lee Jones <lee at kernel.org>
Signed-off-by: Sean Young <sean at mess.org>
---
 Documentation/driver-api/pwm.rst              |  8 +++---
 MAINTAINERS                                   |  2 +-
 .../gpu/drm/i915/display/intel_backlight.c    |  6 ++--
 drivers/gpu/drm/solomon/ssd130x.c             |  2 +-
 drivers/hwmon/pwm-fan.c                       |  8 +++---
 drivers/input/misc/da7280.c                   |  4 +--
 drivers/input/misc/pwm-beeper.c               |  4 +--
 drivers/input/misc/pwm-vibra.c                |  8 +++---
 drivers/leds/leds-pwm.c                       |  2 +-
 drivers/leds/rgb/leds-pwm-multicolor.c        |  4 +--
 drivers/media/rc/pwm-ir-tx.c                  |  4 +--
 drivers/platform/x86/lenovo-yogabook.c        |  2 +-
 drivers/pwm/core.c                            | 18 ++++++------
 drivers/pwm/pwm-twl-led.c                     |  2 +-
 drivers/pwm/pwm-vt8500.c                      |  2 +-
 drivers/pwm/sysfs.c                           | 10 +++----
 drivers/regulator/pwm-regulator.c             |  4 +--
 drivers/video/backlight/lm3630a_bl.c          |  2 +-
 drivers/video/backlight/lp855x_bl.c           |  2 +-
 drivers/video/backlight/pwm_bl.c              | 12 ++++----
 drivers/video/fbdev/ssd1307fb.c               |  2 +-
 include/linux/pwm.h                           | 28 +++++++++----------
 22 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index bb264490a87a1..f1d8197c8c430 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -41,7 +41,7 @@ the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also exist.
 
 After being requested, a PWM has to be configured using::
 
-	int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
+	int pwm_apply_might_sleep(struct pwm_device *pwm, struct pwm_state *state);
 
 This API controls both the PWM period/duty_cycle config and the
 enable/disable state.
@@ -57,13 +57,13 @@ If supported by the driver, the signal can be optimized, for example to improve
 EMI by phase shifting the individual channels of a chip.
 
 The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
-around pwm_apply_state() and should not be used if the user wants to change
+around pwm_apply_might_sleep() and should not be used if the user wants to change
 several parameter at once. For example, if you see pwm_config() and
 pwm_{enable,disable}() calls in the same function, this probably means you
-should switch to pwm_apply_state().
+should switch to pwm_apply_might_sleep().
 
 The PWM user API also allows one to query the PWM state that was passed to the
-last invocation of pwm_apply_state() using pwm_get_state(). Note this is
+last invocation of pwm_apply_might_sleep() using pwm_get_state(). Note this is
 different to what the driver has actually implemented if the request cannot be
 satisfied exactly with the hardware in use. There is currently no way for
 consumers to get the actually implemented settings.
diff --git a/MAINTAINERS b/MAINTAINERS
index 97f51d5ec1cfd..c584805952209 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17576,7 +17576,7 @@ F:	drivers/video/backlight/pwm_bl.c
 F:	include/dt-bindings/pwm/
 F:	include/linux/pwm.h
 F:	include/linux/pwm_backlight.h
-K:	pwm_(config|apply_state|ops)
+K:	pwm_(config|apply_might_sleep|ops)
 
 PXA GPIO DRIVER
 M:	Robert Jarzmik <robert.jarzmik at free.fr>
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c b/drivers/gpu/drm/i915/display/intel_backlight.c
index 2e8f17c045222..ff9b9918b0a13 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -274,7 +274,7 @@ static void ext_pwm_set_backlight(const struct drm_connector_state *conn_state,
 	struct intel_panel *panel = &to_intel_connector(conn_state->connector)->panel;
 
 	pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 static void
@@ -427,7 +427,7 @@ static void ext_pwm_disable_backlight(const struct drm_connector_state *old_conn
 	intel_backlight_set_pwm_level(old_conn_state, level);
 
 	panel->backlight.pwm_state.enabled = false;
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 void intel_backlight_disable(const struct drm_connector_state *old_conn_state)
@@ -749,7 +749,7 @@ static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
 
 	pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
 	panel->backlight.pwm_state.enabled = true;
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 static void __intel_backlight_enable(const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c
index e0174f82e3537..cce043a4a1dcd 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -319,7 +319,7 @@ static int ssd130x_pwm_enable(struct ssd130x_device *ssd130x)
 
 	pwm_init_state(ssd130x->pwm, &pwmstate);
 	pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
-	pwm_apply_state(ssd130x->pwm, &pwmstate);
+	pwm_apply_might_sleep(ssd130x->pwm, &pwmstate);
 
 	/* Enable the PWM */
 	pwm_enable(ssd130x->pwm);
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 6e4516c2ab894..b67bc9e833c01 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -151,7 +151,7 @@ static int pwm_fan_power_on(struct pwm_fan_ctx *ctx)
 	}
 
 	state->enabled = true;
-	ret = pwm_apply_state(ctx->pwm, state);
+	ret = pwm_apply_might_sleep(ctx->pwm, state);
 	if (ret) {
 		dev_err(ctx->dev, "failed to enable PWM\n");
 		goto disable_regulator;
@@ -181,7 +181,7 @@ static int pwm_fan_power_off(struct pwm_fan_ctx *ctx)
 
 	state->enabled = false;
 	state->duty_cycle = 0;
-	ret = pwm_apply_state(ctx->pwm, state);
+	ret = pwm_apply_might_sleep(ctx->pwm, state);
 	if (ret) {
 		dev_err(ctx->dev, "failed to disable PWM\n");
 		return ret;
@@ -207,7 +207,7 @@ static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
 
 		period = state->period;
 		state->duty_cycle = DIV_ROUND_UP(pwm * (period - 1), MAX_PWM);
-		ret = pwm_apply_state(ctx->pwm, state);
+		ret = pwm_apply_might_sleep(ctx->pwm, state);
 		if (ret)
 			return ret;
 		ret = pwm_fan_power_on(ctx);
@@ -278,7 +278,7 @@ static int pwm_fan_update_enable(struct pwm_fan_ctx *ctx, long val)
 						    state,
 						    &enable_regulator);
 
-			pwm_apply_state(ctx->pwm, state);
+			pwm_apply_might_sleep(ctx->pwm, state);
 			pwm_fan_switch_power(ctx, enable_regulator);
 			pwm_fan_update_state(ctx, 0);
 		}
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
index ce82548916bbc..c1fa75c0f970a 100644
--- a/drivers/input/misc/da7280.c
+++ b/drivers/input/misc/da7280.c
@@ -352,7 +352,7 @@ static int da7280_haptic_set_pwm(struct da7280_haptic *haptics, bool enabled)
 		state.duty_cycle = period_mag_multi;
 	}
 
-	error = pwm_apply_state(haptics->pwm_dev, &state);
+	error = pwm_apply_might_sleep(haptics->pwm_dev, &state);
 	if (error)
 		dev_err(haptics->dev, "Failed to apply pwm state: %d\n", error);
 
@@ -1175,7 +1175,7 @@ static int da7280_probe(struct i2c_client *client)
 		/* Sync up PWM state and ensure it is off. */
 		pwm_init_state(haptics->pwm_dev, &state);
 		state.enabled = false;
-		error = pwm_apply_state(haptics->pwm_dev, &state);
+		error = pwm_apply_might_sleep(haptics->pwm_dev, &state);
 		if (error) {
 			dev_err(dev, "Failed to apply PWM state: %d\n", error);
 			return error;
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 1e731d8397c6f..5b9aedf4362f4 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -39,7 +39,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
 	state.period = period;
 	pwm_set_relative_duty_cycle(&state, 50, 100);
 
-	error = pwm_apply_state(beeper->pwm, &state);
+	error = pwm_apply_might_sleep(beeper->pwm, &state);
 	if (error)
 		return error;
 
@@ -138,7 +138,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
 	/* Sync up PWM state and ensure it is off. */
 	pwm_init_state(beeper->pwm, &state);
 	state.enabled = false;
-	error = pwm_apply_state(beeper->pwm, &state);
+	error = pwm_apply_might_sleep(beeper->pwm, &state);
 	if (error) {
 		dev_err(dev, "failed to apply initial PWM state: %d\n",
 			error);
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index acac79c488aa1..3e5ed685ed8f5 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -56,7 +56,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 	pwm_set_relative_duty_cycle(&state, vibrator->level, 0xffff);
 	state.enabled = true;
 
-	err = pwm_apply_state(vibrator->pwm, &state);
+	err = pwm_apply_might_sleep(vibrator->pwm, &state);
 	if (err) {
 		dev_err(pdev, "failed to apply pwm state: %d\n", err);
 		return err;
@@ -67,7 +67,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 		state.duty_cycle = vibrator->direction_duty_cycle;
 		state.enabled = true;
 
-		err = pwm_apply_state(vibrator->pwm_dir, &state);
+		err = pwm_apply_might_sleep(vibrator->pwm_dir, &state);
 		if (err) {
 			dev_err(pdev, "failed to apply dir-pwm state: %d\n", err);
 			pwm_disable(vibrator->pwm);
@@ -160,7 +160,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
 	/* Sync up PWM state and ensure it is off. */
 	pwm_init_state(vibrator->pwm, &state);
 	state.enabled = false;
-	err = pwm_apply_state(vibrator->pwm, &state);
+	err = pwm_apply_might_sleep(vibrator->pwm, &state);
 	if (err) {
 		dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 			err);
@@ -174,7 +174,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
 		/* Sync up PWM state and ensure it is off. */
 		pwm_init_state(vibrator->pwm_dir, &state);
 		state.enabled = false;
-		err = pwm_apply_state(vibrator->pwm_dir, &state);
+		err = pwm_apply_might_sleep(vibrator->pwm_dir, &state);
 		if (err) {
 			dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 				err);
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 2b3bf1353b707..4e3936a39d0ed 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -54,7 +54,7 @@ static int led_pwm_set(struct led_classdev *led_cdev,
 
 	led_dat->pwmstate.duty_cycle = duty;
 	led_dat->pwmstate.enabled = true;
-	return pwm_apply_state(led_dat->pwm, &led_dat->pwmstate);
+	return pwm_apply_might_sleep(led_dat->pwm, &led_dat->pwmstate);
 }
 
 __attribute__((nonnull))
diff --git a/drivers/leds/rgb/leds-pwm-multicolor.c b/drivers/leds/rgb/leds-pwm-multicolor.c
index 46cd062b8b24c..e1a81e0109e8a 100644
--- a/drivers/leds/rgb/leds-pwm-multicolor.c
+++ b/drivers/leds/rgb/leds-pwm-multicolor.c
@@ -51,8 +51,8 @@ static int led_pwm_mc_set(struct led_classdev *cdev,
 
 		priv->leds[i].state.duty_cycle = duty;
 		priv->leds[i].state.enabled = duty > 0;
-		ret = pwm_apply_state(priv->leds[i].pwm,
-				      &priv->leds[i].state);
+		ret = pwm_apply_might_sleep(priv->leds[i].pwm,
+					    &priv->leds[i].state);
 		if (ret)
 			break;
 	}
diff --git a/drivers/media/rc/pwm-ir-tx.c b/drivers/media/rc/pwm-ir-tx.c
index c5f37c03af9c9..cf51e27609759 100644
--- a/drivers/media/rc/pwm-ir-tx.c
+++ b/drivers/media/rc/pwm-ir-tx.c
@@ -68,7 +68,7 @@ static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
 
 	for (i = 0; i < count; i++) {
 		state.enabled = !(i % 2);
-		pwm_apply_state(pwm, &state);
+		pwm_apply_might_sleep(pwm, &state);
 
 		edge = ktime_add_us(edge, txbuf[i]);
 		delta = ktime_us_delta(edge, ktime_get());
@@ -77,7 +77,7 @@ static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
 	}
 
 	state.enabled = false;
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 
 	return count;
 }
diff --git a/drivers/platform/x86/lenovo-yogabook.c b/drivers/platform/x86/lenovo-yogabook.c
index b8d0239192cbf..fd62bf746ebde 100644
--- a/drivers/platform/x86/lenovo-yogabook.c
+++ b/drivers/platform/x86/lenovo-yogabook.c
@@ -435,7 +435,7 @@ static int yogabook_pdev_set_kbd_backlight(struct yogabook_data *data, u8 level)
 		.enabled = level,
 	};
 
-	pwm_apply_state(data->kbd_bl_pwm, &state);
+	pwm_apply_might_sleep(data->kbd_bl_pwm, &state);
 	gpiod_set_value(data->kbd_bl_led_enable, level ? 1 : 0);
 	return 0;
 }
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f60b715abe62b..c2d78136625d5 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -326,8 +326,8 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
 }
 EXPORT_SYMBOL_GPL(pwm_request_from_chip);
 
-static void pwm_apply_state_debug(struct pwm_device *pwm,
-				  const struct pwm_state *state)
+static void pwm_apply_debug(struct pwm_device *pwm,
+			    const struct pwm_state *state)
 {
 	struct pwm_state *last = &pwm->last;
 	struct pwm_chip *chip = pwm->chip;
@@ -433,11 +433,11 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
 }
 
 /**
- * pwm_apply_state() - atomically apply a new state to a PWM device
+ * pwm_apply_might_sleep() - atomically apply a new state to a PWM device
  * @pwm: PWM device
  * @state: new state to apply
  */
-int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
+int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state)
 {
 	struct pwm_chip *chip;
 	int err;
@@ -445,7 +445,7 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	/*
 	 * Some lowlevel driver's implementations of .apply() make use of
 	 * mutexes, also with some drivers only returning when the new
-	 * configuration is active calling pwm_apply_state() from atomic context
+	 * configuration is active calling pwm_apply_might_sleep() from atomic context
 	 * is a bad idea. So make it explicit that calling this function might
 	 * sleep.
 	 */
@@ -475,11 +475,11 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	 * only do this after pwm->state was applied as some
 	 * implementations of .get_state depend on this
 	 */
-	pwm_apply_state_debug(pwm, state);
+	pwm_apply_debug(pwm, state);
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(pwm_apply_state);
+EXPORT_SYMBOL_GPL(pwm_apply_might_sleep);
 
 /**
  * pwm_capture() - capture and report a PWM signal
@@ -537,7 +537,7 @@ int pwm_adjust_config(struct pwm_device *pwm)
 		state.period = pargs.period;
 		state.polarity = pargs.polarity;
 
-		return pwm_apply_state(pwm, &state);
+		return pwm_apply_might_sleep(pwm, &state);
 	}
 
 	/*
@@ -560,7 +560,7 @@ int pwm_adjust_config(struct pwm_device *pwm)
 		state.duty_cycle = state.period - state.duty_cycle;
 	}
 
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 EXPORT_SYMBOL_GPL(pwm_adjust_config);
 
diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
index 8a870d0db3c69..c670ccb816536 100644
--- a/drivers/pwm/pwm-twl-led.c
+++ b/drivers/pwm/pwm-twl-led.c
@@ -172,7 +172,7 @@ static int twl4030_pwmled_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * We cannot skip calling ->config even if state->period ==
 	 * pwm->state.period && state->duty_cycle == pwm->state.duty_cycle
 	 * because we might have exited early in the last call to
-	 * pwm_apply_state because of !state->enabled and so the two values in
+	 * pwm_apply_might_sleep because of !state->enabled and so the two values in
 	 * pwm->state might not be configured in hardware.
 	 */
 	ret = twl4030_pwmled_config(chip, pwm,
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index bdea60389487e..7bfeacee05d0f 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -206,7 +206,7 @@ static int vt8500_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * We cannot skip calling ->config even if state->period ==
 	 * pwm->state.period && state->duty_cycle == pwm->state.duty_cycle
 	 * because we might have exited early in the last call to
-	 * pwm_apply_state because of !state->enabled and so the two values in
+	 * pwm_apply_might_sleep because of !state->enabled and so the two values in
 	 * pwm->state might not be configured in hardware.
 	 */
 	err = vt8500_pwm_config(chip, pwm, state->duty_cycle, state->period);
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 4edb994fa2e12..1698609d91c8a 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -62,7 +62,7 @@ static ssize_t period_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.period = val;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -97,7 +97,7 @@ static ssize_t duty_cycle_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.duty_cycle = val;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -144,7 +144,7 @@ static ssize_t enable_store(struct device *child,
 		goto unlock;
 	}
 
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 
 unlock:
 	mutex_unlock(&export->lock);
@@ -194,7 +194,7 @@ static ssize_t polarity_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.polarity = polarity;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -401,7 +401,7 @@ static int pwm_class_apply_state(struct pwm_export *export,
 				 struct pwm_device *pwm,
 				 struct pwm_state *state)
 {
-	int ret = pwm_apply_state(pwm, state);
+	int ret = pwm_apply_might_sleep(pwm, state);
 
 	/* release lock taken in pwm_class_get_state */
 	mutex_unlock(&export->lock);
diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
index 2aff6db748e2c..698c420e0869b 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -90,7 +90,7 @@ static int pwm_regulator_set_voltage_sel(struct regulator_dev *rdev,
 	pwm_set_relative_duty_cycle(&pstate,
 			drvdata->duty_cycle_table[selector].dutycycle, 100);
 
-	ret = pwm_apply_state(drvdata->pwm, &pstate);
+	ret = pwm_apply_might_sleep(drvdata->pwm, &pstate);
 	if (ret) {
 		dev_err(&rdev->dev, "Failed to configure PWM: %d\n", ret);
 		return ret;
@@ -216,7 +216,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
 
 	pwm_set_relative_duty_cycle(&pstate, dutycycle, duty_unit);
 
-	ret = pwm_apply_state(drvdata->pwm, &pstate);
+	ret = pwm_apply_might_sleep(drvdata->pwm, &pstate);
 	if (ret) {
 		dev_err(&rdev->dev, "Failed to configure PWM: %d\n", ret);
 		return ret;
diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
index 8fcb62be597b8..a3412c936ca28 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -180,7 +180,7 @@ static int lm3630a_pwm_ctrl(struct lm3630a_chip *pchip, int br, int br_max)
 
 	pchip->pwmd_state.enabled = pchip->pwmd_state.duty_cycle ? true : false;
 
-	return pwm_apply_state(pchip->pwmd, &pchip->pwmd_state);
+	return pwm_apply_might_sleep(pchip->pwmd, &pchip->pwmd_state);
 }
 
 /* update and get brightness */
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
index da1f124db69c0..7075bfab59c4d 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -234,7 +234,7 @@ static int lp855x_pwm_ctrl(struct lp855x *lp, int br, int max_br)
 	state.duty_cycle = div_u64(br * state.period, max_br);
 	state.enabled = state.duty_cycle;
 
-	return pwm_apply_state(lp->pwm, &state);
+	return pwm_apply_might_sleep(lp->pwm, &state);
 }
 
 static int lp855x_bl_update_status(struct backlight_device *bl)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 289bd9ce4d36d..35c716e9043c3 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -103,7 +103,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		pwm_get_state(pb->pwm, &state);
 		state.duty_cycle = compute_duty_cycle(pb, brightness, &state);
 		state.enabled = true;
-		pwm_apply_state(pb->pwm, &state);
+		pwm_apply_might_sleep(pb->pwm, &state);
 
 		pwm_backlight_power_on(pb);
 	} else {
@@ -120,7 +120,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		 * inactive output.
 		 */
 		state.enabled = !pb->power_supply && !pb->enable_gpio;
-		pwm_apply_state(pb->pwm, &state);
+		pwm_apply_might_sleep(pb->pwm, &state);
 	}
 
 	if (pb->notify_after)
@@ -528,7 +528,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 	if (!state.period && (data->pwm_period_ns > 0))
 		state.period = data->pwm_period_ns;
 
-	ret = pwm_apply_state(pb->pwm, &state);
+	ret = pwm_apply_might_sleep(pb->pwm, &state);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 			ret);
@@ -633,7 +633,7 @@ static void pwm_backlight_remove(struct platform_device *pdev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 
 	if (pb->exit)
 		pb->exit(&pdev->dev);
@@ -649,7 +649,7 @@ static void pwm_backlight_shutdown(struct platform_device *pdev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -673,7 +673,7 @@ static int pwm_backlight_suspend(struct device *dev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 
 	if (pb->notify_after)
 		pb->notify_after(pb->dev, 0);
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 5ae48e36fccb4..1a4f90ea7d5a8 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -347,7 +347,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
 
 		pwm_init_state(par->pwm, &pwmstate);
 		pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
-		pwm_apply_state(par->pwm, &pwmstate);
+		pwm_apply_might_sleep(par->pwm, &pwmstate);
 
 		/* Enable the PWM */
 		pwm_enable(par->pwm);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index f87655c06c825..b64b8a82415c4 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -92,8 +92,8 @@ struct pwm_device {
  * @state: state to fill with the current PWM state
  *
  * The returned PWM state represents the state that was applied by a previous call to
- * pwm_apply_state(). Drivers may have to slightly tweak that state before programming it to
- * hardware. If pwm_apply_state() was never called, this returns either the current hardware
+ * pwm_apply_might_sleep(). Drivers may have to slightly tweak that state before programming it to
+ * hardware. If pwm_apply_might_sleep() was never called, this returns either the current hardware
  * state (if supported) or the default settings.
  */
 static inline void pwm_get_state(const struct pwm_device *pwm,
@@ -157,20 +157,20 @@ static inline void pwm_get_args(const struct pwm_device *pwm,
 }
 
 /**
- * pwm_init_state() - prepare a new state to be applied with pwm_apply_state()
+ * pwm_init_state() - prepare a new state to be applied with pwm_apply_might_sleep()
  * @pwm: PWM device
  * @state: state to fill with the prepared PWM state
  *
  * This functions prepares a state that can later be tweaked and applied
- * to the PWM device with pwm_apply_state(). This is a convenient function
+ * to the PWM device with pwm_apply_might_sleep(). This is a convenient function
  * that first retrieves the current PWM state and the replaces the period
  * and polarity fields with the reference values defined in pwm->args.
  * Once the function returns, you can adjust the ->enabled and ->duty_cycle
- * fields according to your needs before calling pwm_apply_state().
+ * fields according to your needs before calling pwm_apply_might_sleep().
  *
  * ->duty_cycle is initially set to zero to avoid cases where the current
  * ->duty_cycle value exceed the pwm_args->period one, which would trigger
- * an error if the user calls pwm_apply_state() without adjusting ->duty_cycle
+ * an error if the user calls pwm_apply_might_sleep() without adjusting ->duty_cycle
  * first.
  */
 static inline void pwm_init_state(const struct pwm_device *pwm,
@@ -226,7 +226,7 @@ pwm_get_relative_duty_cycle(const struct pwm_state *state, unsigned int scale)
  *
  * pwm_init_state(pwm, &state);
  * pwm_set_relative_duty_cycle(&state, 50, 100);
- * pwm_apply_state(pwm, &state);
+ * pwm_apply_might_sleep(pwm, &state);
  *
  * This functions returns -EINVAL if @duty_cycle and/or @scale are
  * inconsistent (@scale == 0 or @duty_cycle > @scale).
@@ -304,7 +304,7 @@ struct pwm_chip {
 
 #if IS_ENABLED(CONFIG_PWM)
 /* PWM user APIs */
-int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state);
+int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state);
 int pwm_adjust_config(struct pwm_device *pwm);
 
 /**
@@ -332,7 +332,7 @@ static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
 
 	state.duty_cycle = duty_ns;
 	state.period = period_ns;
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 
 /**
@@ -353,7 +353,7 @@ static inline int pwm_enable(struct pwm_device *pwm)
 		return 0;
 
 	state.enabled = true;
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 
 /**
@@ -372,7 +372,7 @@ static inline void pwm_disable(struct pwm_device *pwm)
 		return;
 
 	state.enabled = false;
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 }
 
 /* PWM provider APIs */
@@ -403,8 +403,8 @@ struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
 				       struct fwnode_handle *fwnode,
 				       const char *con_id);
 #else
-static inline int pwm_apply_state(struct pwm_device *pwm,
-				  const struct pwm_state *state)
+static inline int pwm_apply_might_sleep(struct pwm_device *pwm,
+					const struct pwm_state *state)
 {
 	might_sleep();
 	return -ENOTSUPP;
@@ -521,7 +521,7 @@ static inline void pwm_apply_args(struct pwm_device *pwm)
 	state.period = pwm->args.period;
 	state.usage_power = false;
 
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 }
 
 struct pwm_lookup {
-- 
2.43.0



From sean at mess.org  Tue Dec 12 00:34:04 2023
From: sean at mess.org (Sean Young)
Date: Tue, 12 Dec 2023 08:34:04 +0000
Subject: [PATCH v8 5/6] pwm: bcm2835: Allow PWM driver to be used in atomic context
In-Reply-To: <cover.1702369869.git.sean@mess.org>
References: <cover.1702369869.git.sean@mess.org>
Message-ID: <e9e32c9789da3c90b5a2aa7d5a093120b76421fb.1702369869.git.sean@mess.org>

clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
rate changes using clk_rate_exclusive_get().

Signed-off-by: Sean Young <sean at mess.org>
Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
---
 drivers/pwm/pwm-bcm2835.c | 31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index ab30667f4f951..309d52ec43bbe 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -28,6 +28,7 @@ struct bcm2835_pwm {
 	struct device *dev;
 	void __iomem *base;
 	struct clk *clk;
+	unsigned long rate;
 };
 
 static inline struct bcm2835_pwm *to_bcm2835_pwm(struct pwm_chip *chip)
@@ -63,17 +64,11 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 {
 
 	struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
-	unsigned long rate = clk_get_rate(pc->clk);
 	unsigned long long period_cycles;
 	u64 max_period;
 
 	u32 val;
 
-	if (!rate) {
-		dev_err(pc->dev, "failed to get clock rate\n");
-		return -EINVAL;
-	}
-
 	/*
 	 * period_cycles must be a 32 bit value, so period * rate / NSEC_PER_SEC
 	 * must be <= U32_MAX. As U32_MAX * NSEC_PER_SEC < U64_MAX the
@@ -88,13 +83,13 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * <=> period < ((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate
 	 * <=> period <= ceil((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate) - 1
 	 */
-	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, rate) - 1;
+	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, pc->rate) - 1;
 
 	if (state->period > max_period)
 		return -EINVAL;
 
 	/* set period */
-	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * rate, NSEC_PER_SEC);
+	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * pc->rate, NSEC_PER_SEC);
 
 	/* don't accept a period that is too small */
 	if (period_cycles < PERIOD_MIN)
@@ -103,7 +98,7 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	writel(period_cycles, pc->base + PERIOD(pwm->hwpwm));
 
 	/* set duty cycle */
-	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * rate, NSEC_PER_SEC);
+	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * pc->rate, NSEC_PER_SEC);
 	writel(val, pc->base + DUTY(pwm->hwpwm));
 
 	/* set polarity */
@@ -151,16 +146,31 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
 				     "clock not found\n");
 
+	ret = clk_rate_exclusive_get(pc->clk);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret,
+				     "fail to get exclusive rate\n");
+
+	pc->rate = clk_get_rate(pc->clk);
+	if (!pc->rate) {
+		clk_rate_exclusive_put(pc->clk);
+		return dev_err_probe(&pdev->dev, -EINVAL,
+				     "failed to get clock rate\n");
+	}
+
 	pc->chip.dev = &pdev->dev;
 	pc->chip.ops = &bcm2835_pwm_ops;
+	pc->chip.atomic = true;
 	pc->chip.npwm = 2;
 
 	platform_set_drvdata(pdev, pc);
 
 	ret = devm_pwmchip_add(&pdev->dev, &pc->chip);
-	if (ret < 0)
+	if (ret < 0) {
+		clk_rate_exclusive_put(pc->clk);
 		return dev_err_probe(&pdev->dev, ret,
 				     "failed to add pwmchip\n");
+	}
 
 	return 0;
 }
@@ -169,6 +179,7 @@ static int bcm2835_pwm_suspend(struct device *dev)
 {
 	struct bcm2835_pwm *pc = dev_get_drvdata(dev);
 
+	clk_rate_exclusive_put(pc->clk);
 	clk_disable_unprepare(pc->clk);
 
 	return 0;
-- 
2.43.0



From piotr.firek at financialflows.pl  Tue Dec 12 00:36:02 2023
From: piotr.firek at financialflows.pl (Piotr Firek)
Date: Tue, 12 Dec 2023 08:36:02 GMT
Subject: =?UTF-8?Q?Prosz=C4=99_o_kontakt?=
Message-ID: <20231212074500-0.1.1i.8i4i.0.cs4hz1hy39@financialflows.pl>

Dzie? dobry,

Czy jest mo?liwo?? nawi?zania wsp??pracy z Pa?stwem?

Z ch?ci? porozmawiam z osob? zajmuj?c? si? dzia?aniami zwi?zanymi ze sprzeda??.

Pomagamy skutecznie pozyskiwa? nowych klient?w.

Zapraszam do kontaktu.


Pozdrawiam
Piotr Firek


From krzysztof.kozlowski at linaro.org  Tue Dec 12 01:01:25 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 10:01:25 +0100
Subject: [PATCH 1/3] dt-bindings: vendor-prefixes: add Transpeed
In-Reply-To: <20231212010859.11571-2-andre.przywara@arm.com>
References: <20231212010859.11571-1-andre.przywara@arm.com>
 <20231212010859.11571-2-andre.przywara@arm.com>
Message-ID: <cb28ca67-8648-4199-92d0-e3129277b624@linaro.org>

On 12/12/2023 02:08, Andre Przywara wrote:
> This is a name used by some Chinese TV boxes, add it to the bindings.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 309b94c328c84..d9dd3f929cdcf 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1438,6 +1438,8 @@ patternProperties:
>      description: Traverse Technologies Australia Pty Ltd
>    "^tronfy,.*":
>      description: Tronfy
> +  "^transpeed,.*":
> +    description: Transpeed

Please keep alphabetical order.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 12 01:01:56 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 10:01:56 +0100
Subject: [PATCH 2/3] dt-bindings: arm: sunxi: document Transpeed 8K618-T
 board name
In-Reply-To: <20231212010859.11571-3-andre.przywara@arm.com>
References: <20231212010859.11571-1-andre.przywara@arm.com>
 <20231212010859.11571-3-andre.przywara@arm.com>
Message-ID: <7d352882-5f6f-4c8b-a8c5-76ea31c2ae31@linaro.org>

On 12/12/2023 02:08, Andre Przywara wrote:
> The Transpeed 8K618-T TV box is a Chinese Android TV box, using the
> Allwinner H618 SoC.
> 
> Add the board/SoC compatible string pair to the list of known boards.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index 11c5ce941dd7e..5e91110cc9eb8 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -868,6 +868,11 @@ properties:
>            - const: topwise,a721
>            - const: allwinner,sun4i-a10
>  
> +      - description: Transpeed 8K618-T
> +        items:
> +          - const: transpeed,8k618-t
> +          - const: allwinner,sun50i-h618

Assuming you kept the existing order (its style) of a file:

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From fancer.lancer at gmail.com  Tue Dec 12 01:08:07 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue, 12 Dec 2023 12:08:07 +0300
Subject: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <CY5PR12MB6372C8770900AFF821325400BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com>
References: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
 <d202770a-3a3a-4ee2-b0de-b86e2f3e83ce@lunn.ch>
 <CY5PR12MB6372C8770900AFF821325400BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com>
Message-ID: <ulsdbn3iqzyokqbfejp5krrpbkzz3rqpxfw53m2rfm2ouzs2bz@ys4ynwqwewjo>

On Tue, Dec 12, 2023 at 07:22:24AM +0000, Jianheng Zhang wrote:
> Hi Andrew,  
> 
> > > +static int dwxgmac3_fpe_irq_status(void __iomem *ioaddr, struct net_device *dev)
> > > +{
> > > +	u32 value;
> > > +	int status;
> > >
> > > -		writel(value, ioaddr + XGMAC_FPE_CTRL_STS);
> > > -		return;
> > > +	status = FPE_EVENT_UNKNOWN;
> > > +
> > > +	/* Reads from the XGMAC_FPE_CTRL_STS register should only be performed
> > > +	 * here, since the status flags of MAC_FPE_CTRL_STS are "clear on read"
> > > +	 */
> > > +	value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
> > > +
> > > +	if (value & XGMAC_TRSP) {
> > > +		status |= FPE_EVENT_TRSP;
> > > +		netdev_info(dev, "FPE: Respond mPacket is transmitted\n");
> > 
> > netdev_info()?  Is this going to spam the logs? Should it be netdev_dbg()
> 
> Yes, netdev_dbg() should be better, let me fix it in the next patch.

Please do not forget to keep this change in the refactoring patch (if
one will be introduced). So instead of preserving the DW QoS Eth FPE
code snipped with netdev_info() utilized, the common FPE
implementation would have the netdev_dbg() calls.

-Serge(y)

> 
> Jianheng
> > 
> > 	Andrew
> 


From will at kernel.org  Tue Dec 12 01:10:48 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 09:10:48 +0000
Subject: [PATCH 06/13] arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion
 for DDI0601 2023-09
In-Reply-To: <CA+EHjTzdKS+ardXUofO+U1vnsOC3QjiJUBuKCHWw6z6zKdVGSA@mail.gmail.com>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
 <20231209-b4-arm64-sysreg-additions-v1-6-45284e538474@kernel.org>
 <CA+EHjTzdKS+ardXUofO+U1vnsOC3QjiJUBuKCHWw6z6zKdVGSA@mail.gmail.com>
Message-ID: <20231212091047.GA28147@willie-the-truck>

On Mon, Dec 11, 2023 at 09:07:25AM +0000, Fuad Tabba wrote:
> On Sat, Dec 9, 2023 at 1:03?AM Mark Brown <broonie at kernel.org> wrote:
> >
> > DDI0601 2023-09 defines some new fields in previously RES0 space in
> > ID_AA64ISAR2_EL1, together with one new enum value. Update the system
> > register definition to reflect this.
> >
> > Signed-off-by: Mark Brown <broonie at kernel.org>
> 
> > ---
> >  arch/arm64/tools/sysreg | 24 ++++++++++++++++++++++--
> >  1 file changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> > index c48a3b8d00ad..3f382f8d0f4a 100644
> > --- a/arch/arm64/tools/sysreg
> > +++ b/arch/arm64/tools/sysreg
> > @@ -1365,7 +1365,14 @@ EndEnum
> >  EndSysreg
> >
> >  Sysreg ID_AA64ISAR2_EL1        3       0       0       6       2
> > -Res0   63:56
> > +UnsignedEnum   63:60   ATS1A
> > +       0b0000  NI
> > +       0b0001  IMP
> > +EndEnum
> > +UnsignedEnum   59:56   LUT
> > +       0b0000  NI
> > +       0b0001  IMP
> > +EndEnum
> >  UnsignedEnum   55:52   CSSC
> >         0b0000  NI
> >         0b0001  IMP
> > @@ -1374,7 +1381,19 @@ UnsignedEnum     51:48   RPRFM
> >         0b0000  NI
> >         0b0001  IMP
> >  EndEnum
> > -Res0   47:32
> > +Res0   47:44
> > +UnsignedEnum   43:40   PRFMSLC
> > +       0b0000  NI
> > +       0b0001  IMP
> > +EndEnum
> > +UnsignedEnum   39:36   SYSINSTR_128
> > +       0b0000  NI
> > +       0b0001  IMP
> > +EndEnum
> > +UnsignedEnum   35:32   SYSREG_128
> > +       0b0000  NI
> > +       0b0001  IMP
> > +EndEnum
> >  UnsignedEnum   31:28   CLRBHB
> >         0b0000  NI
> >         0b0001  IMP
> > @@ -1398,6 +1417,7 @@ UnsignedEnum      15:12   APA3
> >         0b0011  PAuth2
> >         0b0100  FPAC
> >         0b0101  FPACCOMBINE
> > +       0b0110  PAUTH_LR
> 
> Nit: PAuth and PAuth2 only have the PA as uppercase in this file,
> which matches the spec. Should PAuth_LR be the same?

I renamed it to PAuth_LR following your comment, but it looks like
ID_AA64ISAR1_EL1 is still missing this field entirely for the API and
APA fields.

Will


From will at kernel.org  Tue Dec 12 01:16:54 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 09:16:54 +0000
Subject: [PATCH] perf/arm-cmn: Fail DTC counter allocation correctly
In-Reply-To: <ed589c0d8e4130dc68b8ad1625226d28bdc185d4.1702322847.git.robin.murphy@arm.com>
References: <ed589c0d8e4130dc68b8ad1625226d28bdc185d4.1702322847.git.robin.murphy@arm.com>
Message-ID: <20231212091654.GA28174@willie-the-truck>

On Mon, Dec 11, 2023 at 07:27:28PM +0000, Robin Murphy wrote:
> Calling arm_cmn_event_clear() before all DTC indices are allocated is
> wrong, and can lead to arm_cmn_event_add() erroneously clearing live
> counters from full DTCs where allocation fails. Since the DTC counters
> are only updated by arm_cmn_init_counter() after all DTC and DTM
> allocations succeed, nothing actually needs cleaning up in this case
> anyway, and it should just return directly as it did before.
> 
> Fixes: 7633ec2c262f ("perf/arm-cmn: Rework DTC counters (again)")
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/perf/arm-cmn.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> index 86d970e74129..c584165b13ba 100644
> --- a/drivers/perf/arm-cmn.c
> +++ b/drivers/perf/arm-cmn.c
> @@ -1816,7 +1816,7 @@ static int arm_cmn_event_add(struct perf_event *event, int flags)
>  			idx = 0;
>  			while (cmn->dtc[j].counters[idx])
>  				if (++idx == CMN_DT_NUM_COUNTERS)
> -					goto free_dtms;
> +					return -ENOSPC;
>  		}
>  		hw->dtc_idx[j] = idx;
>  	}
> -- 
> 2.39.2.101.g768bb238c484.dirty

Acked-by: Will Deacon <will at kernel.org>

Catalin -- please can you take this one as a fix?

Cheers,

Will


From haibo1.xu at intel.com  Tue Dec 12 01:31:09 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:09 +0800
Subject: [PATCH v4 00/11] RISCV: Add kvm Sstc timer selftests
Message-ID: <cover.1702371136.git.haibo1.xu@intel.com>

The RISC-V arch_timer selftests is used to validate Sstc timer
functionality in a guest, which sets up periodic timer interrupts
and check the basic interrupt status upon its receipt.

This KVM selftests was ported from aarch64 arch_timer and tested
with Linux v6.7-rc4 on a Qemu riscv64 virt machine.

---
Changed since v4:
  * Rebased to Linux 6.7-rc4
  * Included Paolo's patch(01/11) to fix issues with SPLIT_TESTS
  * Droped the patch(KVM: selftests: Unify the makefile rule for split targets) 
    since Paolo's patch had included the fix
  * Added new patch(05/11) to include header file vdso/processor.h from linux
    source tree to leverage the cpu_relax() definition - Conor/Andrew
  * Added new patch(11/11) to enable user configuration of timer error margin
    parameter which alleviate the intermitent failure in stress test - Andrew
  * Other minor fixes per Andrew's comments

Haibo Xu (10):
  KVM: arm64: selftests: Split arch_timer test code
  KVM: selftests: Add CONFIG_64BIT definition for the build
  tools: riscv: Add header file csr.h
  tools: riscv: Add header file vdso/processor.h
  KVM: riscv: selftests: Switch to use macro from csr.h
  KVM: riscv: selftests: Add exception handling support
  KVM: riscv: selftests: Add guest helper to get vcpu id
  KVM: riscv: selftests: Change vcpu_has_ext to a common function
  KVM: riscv: selftests: Add sstc timer test
  KVM: selftests: Enable tunning of err_margin_us in arch timer test

Paolo Bonzini (1):
  selftests/kvm: Fix issues with $(SPLIT_TESTS)

 tools/arch/riscv/include/asm/csr.h            | 521 ++++++++++++++++++
 tools/arch/riscv/include/asm/vdso/processor.h |  32 ++
 tools/testing/selftests/kvm/Makefile          |  27 +-
 .../selftests/kvm/aarch64/arch_timer.c        | 295 +---------
 tools/testing/selftests/kvm/arch_timer.c      | 259 +++++++++
 .../selftests/kvm/include/aarch64/processor.h |   4 -
 .../selftests/kvm/include/kvm_util_base.h     |   9 +
 .../selftests/kvm/include/riscv/arch_timer.h  |  71 +++
 .../selftests/kvm/include/riscv/processor.h   |  65 ++-
 .../testing/selftests/kvm/include/test_util.h |   2 +
 .../selftests/kvm/include/timer_test.h        |  45 ++
 .../selftests/kvm/lib/riscv/handlers.S        | 101 ++++
 .../selftests/kvm/lib/riscv/processor.c       |  87 +++
 .../testing/selftests/kvm/riscv/arch_timer.c  | 111 ++++
 .../selftests/kvm/riscv/get-reg-list.c        |  11 +-
 15 files changed, 1333 insertions(+), 307 deletions(-)
 create mode 100644 tools/arch/riscv/include/asm/csr.h
 create mode 100644 tools/arch/riscv/include/asm/vdso/processor.h
 create mode 100644 tools/testing/selftests/kvm/arch_timer.c
 create mode 100644 tools/testing/selftests/kvm/include/riscv/arch_timer.h
 create mode 100644 tools/testing/selftests/kvm/include/timer_test.h
 create mode 100644 tools/testing/selftests/kvm/lib/riscv/handlers.S
 create mode 100644 tools/testing/selftests/kvm/riscv/arch_timer.c

-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:10 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:10 +0800
Subject: [PATCH v4 01/11] selftests/kvm: Fix issues with $(SPLIT_TESTS)
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <234ad46de32c345cb5b26212a27f0336ce0c9379.1702371136.git.haibo1.xu@intel.com>

From: Paolo Bonzini <pbonzini at redhat.com>

From: Paolo Bonzini <pbonzini at redhat.com>

The introduction of $(SPLIT_TESTS) also introduced a warning when
building selftests on architectures that include get-reg-lists:

    make: Entering directory '/root/kvm/tools/testing/selftests/kvm'
    Makefile:272: warning: overriding recipe for target '/root/kvm/tools/testing/selftests/kvm/get-reg-list'
    Makefile:267: warning: ignoring old recipe for target '/root/kvm/tools/testing/selftests/kvm/get-reg-list'
    make: Leaving directory '/root/kvm/tools/testing/selftests/kvm'

In addition, the rule for $(SPLIT_TESTS_TARGETS) includes _all_
the $(SPLIT_TESTS_OBJS), which only works because there is just one.
So fix both by adjusting the rules:

- remove $(SPLIT_TESTS_TARGETS) from the $(TEST_GEN_PROGS) rules,
  and rename it to $(SPLIT_TEST_GEN_PROGS)

- fix $(SPLIT_TESTS_OBJS) so that it plays well with $(OUTPUT),
  rename it to $(SPLIT_TEST_GEN_OBJ), and list the object file
  explicitly in the $(SPLIT_TEST_GEN_PROGS) link rule

Fixes: 17da79e009c3 ("KVM: arm64: selftests: Split get-reg-list test code", 2023-08-09)
Signed-off-by: Paolo Bonzini <pbonzini at redhat.com>
Tested-by: Andrew Jones <ajones at ventanamicro.com>
---
 tools/testing/selftests/kvm/Makefile | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index 52c59bad7213..2200f06b740b 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -251,32 +251,36 @@ LIBKVM_C_OBJ := $(patsubst %.c, $(OUTPUT)/%.o, $(LIBKVM_C))
 LIBKVM_S_OBJ := $(patsubst %.S, $(OUTPUT)/%.o, $(LIBKVM_S))
 LIBKVM_STRING_OBJ := $(patsubst %.c, $(OUTPUT)/%.o, $(LIBKVM_STRING))
 LIBKVM_OBJS = $(LIBKVM_C_OBJ) $(LIBKVM_S_OBJ) $(LIBKVM_STRING_OBJ)
-SPLIT_TESTS_TARGETS := $(patsubst %, $(OUTPUT)/%, $(SPLIT_TESTS))
-SPLIT_TESTS_OBJS := $(patsubst %, $(ARCH_DIR)/%.o, $(SPLIT_TESTS))
+SPLIT_TEST_GEN_PROGS := $(patsubst %, $(OUTPUT)/%, $(SPLIT_TESTS))
+SPLIT_TEST_GEN_OBJ := $(patsubst %, $(OUTPUT)/$(ARCH_DIR)/%.o, $(SPLIT_TESTS))
 
 TEST_GEN_OBJ = $(patsubst %, %.o, $(TEST_GEN_PROGS))
 TEST_GEN_OBJ += $(patsubst %, %.o, $(TEST_GEN_PROGS_EXTENDED))
 TEST_DEP_FILES = $(patsubst %.o, %.d, $(TEST_GEN_OBJ))
 TEST_DEP_FILES += $(patsubst %.o, %.d, $(LIBKVM_OBJS))
-TEST_DEP_FILES += $(patsubst %.o, %.d, $(SPLIT_TESTS_OBJS))
+TEST_DEP_FILES += $(patsubst %.o, %.d, $(SPLIT_TEST_GEN_OBJ))
 -include $(TEST_DEP_FILES)
 
-$(TEST_GEN_PROGS) $(TEST_GEN_PROGS_EXTENDED): %: %.o
+x := $(shell mkdir -p $(sort $(OUTPUT)/$(ARCH_DIR) $(dir $(LIBKVM_C_OBJ) $(LIBKVM_S_OBJ))))
+
+$(filter-out $(SPLIT_TEST_GEN_PROGS), $(TEST_GEN_PROGS)) \
+$(TEST_GEN_PROGS_EXTENDED): %: %.o
 	$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $< $(LIBKVM_OBJS) $(LDLIBS) -o $@
 $(TEST_GEN_OBJ): $(OUTPUT)/%.o: %.c
 	$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< -o $@
 
-$(SPLIT_TESTS_TARGETS): %: %.o $(SPLIT_TESTS_OBJS)
+$(SPLIT_TEST_GEN_PROGS): $(OUTPUT)/%: $(OUTPUT)/%.o $(OUTPUT)/$(ARCH_DIR)/%.o
 	$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $^ $(LDLIBS) -o $@
+$(SPLIT_TEST_GEN_OBJ): $(OUTPUT)/$(ARCH_DIR)/%.o: $(ARCH_DIR)/%.c
+	$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< -o $@
 
 EXTRA_CLEAN += $(GEN_HDRS) \
 	       $(LIBKVM_OBJS) \
-	       $(SPLIT_TESTS_OBJS) \
+	       $(SPLIT_TEST_GEN_OBJ) \
 	       $(TEST_DEP_FILES) \
 	       $(TEST_GEN_OBJ) \
 	       cscope.*
 
-x := $(shell mkdir -p $(sort $(dir $(LIBKVM_C_OBJ) $(LIBKVM_S_OBJ))))
 $(LIBKVM_C_OBJ): $(OUTPUT)/%.o: %.c $(GEN_HDRS)
 	$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< -o $@
 
@@ -290,7 +294,7 @@ $(LIBKVM_STRING_OBJ): $(OUTPUT)/%.o: %.c
 	$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -ffreestanding $< -o $@
 
 x := $(shell mkdir -p $(sort $(dir $(TEST_GEN_PROGS))))
-$(SPLIT_TESTS_OBJS): $(GEN_HDRS)
+$(SPLIT_TEST_GEN_OBJ): $(GEN_HDRS)
 $(TEST_GEN_PROGS): $(LIBKVM_OBJS)
 $(TEST_GEN_PROGS_EXTENDED): $(LIBKVM_OBJS)
 $(TEST_GEN_OBJ): $(GEN_HDRS)
-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:11 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:11 +0800
Subject: [PATCH v4 02/11] KVM: arm64: selftests: Split arch_timer test code
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <636e8c3bf8b35be089182569621eaff331242d98.1702371136.git.haibo1.xu@intel.com>

Split the arch-neutral test code out of aarch64/arch_timer.c
and put them into a common arch_timer.c. This is a preparation
to share timer test codes in riscv.

Suggested-by: Andrew Jones <ajones at ventanamicro.com>
Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
---
 tools/testing/selftests/kvm/Makefile          |   3 +-
 .../selftests/kvm/aarch64/arch_timer.c        | 275 +-----------------
 tools/testing/selftests/kvm/arch_timer.c      | 249 ++++++++++++++++
 .../testing/selftests/kvm/include/test_util.h |   2 +
 .../selftests/kvm/include/timer_test.h        |  43 +++
 5 files changed, 302 insertions(+), 270 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/arch_timer.c
 create mode 100644 tools/testing/selftests/kvm/include/timer_test.h

diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index 2200f06b740b..4838ea899bbb 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -151,7 +151,6 @@ TEST_GEN_PROGS_x86_64 += system_counter_offset_test
 TEST_GEN_PROGS_EXTENDED_x86_64 += x86_64/nx_huge_pages_test
 
 TEST_GEN_PROGS_aarch64 += aarch64/aarch32_id_regs
-TEST_GEN_PROGS_aarch64 += aarch64/arch_timer
 TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions
 TEST_GEN_PROGS_aarch64 += aarch64/hypercalls
 TEST_GEN_PROGS_aarch64 += aarch64/page_fault_test
@@ -163,6 +162,7 @@ TEST_GEN_PROGS_aarch64 += aarch64/vgic_init
 TEST_GEN_PROGS_aarch64 += aarch64/vgic_irq
 TEST_GEN_PROGS_aarch64 += aarch64/vpmu_counter_access
 TEST_GEN_PROGS_aarch64 += access_tracking_perf_test
+TEST_GEN_PROGS_aarch64 += arch_timer
 TEST_GEN_PROGS_aarch64 += demand_paging_test
 TEST_GEN_PROGS_aarch64 += dirty_log_test
 TEST_GEN_PROGS_aarch64 += dirty_log_perf_test
@@ -201,6 +201,7 @@ TEST_GEN_PROGS_riscv += kvm_page_table_test
 TEST_GEN_PROGS_riscv += set_memory_region_test
 TEST_GEN_PROGS_riscv += kvm_binary_stats_test
 
+SPLIT_TESTS += arch_timer
 SPLIT_TESTS += get-reg-list
 
 TEST_PROGS += $(TEST_PROGS_$(ARCH_DIR))
diff --git a/tools/testing/selftests/kvm/aarch64/arch_timer.c b/tools/testing/selftests/kvm/aarch64/arch_timer.c
index 274b8465b42a..6fb47ba07e5b 100644
--- a/tools/testing/selftests/kvm/aarch64/arch_timer.c
+++ b/tools/testing/selftests/kvm/aarch64/arch_timer.c
@@ -1,64 +1,19 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * arch_timer.c - Tests the aarch64 timer IRQ functionality
- *
  * The test validates both the virtual and physical timer IRQs using
- * CVAL and TVAL registers. This consitutes the four stages in the test.
- * The guest's main thread configures the timer interrupt for a stage
- * and waits for it to fire, with a timeout equal to the timer period.
- * It asserts that the timeout doesn't exceed the timer period.
- *
- * On the other hand, upon receipt of an interrupt, the guest's interrupt
- * handler validates the interrupt by checking if the architectural state
- * is in compliance with the specifications.
- *
- * The test provides command-line options to configure the timer's
- * period (-p), number of vCPUs (-n), and iterations per stage (-i).
- * To stress-test the timer stack even more, an option to migrate the
- * vCPUs across pCPUs (-m), at a particular rate, is also provided.
+ * CVAL and TVAL registers.
  *
  * Copyright (c) 2021, Google LLC.
  */
 #define _GNU_SOURCE
 
-#include <stdlib.h>
-#include <pthread.h>
-#include <linux/kvm.h>
-#include <linux/sizes.h>
-#include <linux/bitmap.h>
-#include <sys/sysinfo.h>
-
-#include "kvm_util.h"
-#include "processor.h"
-#include "delay.h"
 #include "arch_timer.h"
+#include "delay.h"
 #include "gic.h"
+#include "processor.h"
+#include "timer_test.h"
 #include "vgic.h"
 
-#define NR_VCPUS_DEF			4
-#define NR_TEST_ITERS_DEF		5
-#define TIMER_TEST_PERIOD_MS_DEF	10
-#define TIMER_TEST_ERR_MARGIN_US	100
-#define TIMER_TEST_MIGRATION_FREQ_MS	2
-
-struct test_args {
-	int nr_vcpus;
-	int nr_iter;
-	int timer_period_ms;
-	int migration_freq_ms;
-	struct kvm_arm_counter_offset offset;
-};
-
-static struct test_args test_args = {
-	.nr_vcpus = NR_VCPUS_DEF,
-	.nr_iter = NR_TEST_ITERS_DEF,
-	.timer_period_ms = TIMER_TEST_PERIOD_MS_DEF,
-	.migration_freq_ms = TIMER_TEST_MIGRATION_FREQ_MS,
-	.offset = { .reserved = 1 },
-};
-
-#define msecs_to_usecs(msec)		((msec) * 1000LL)
-
 #define GICD_BASE_GPA			0x8000000ULL
 #define GICR_BASE_GPA			0x80A0000ULL
 
@@ -70,22 +25,8 @@ enum guest_stage {
 	GUEST_STAGE_MAX,
 };
 
-/* Shared variables between host and guest */
-struct test_vcpu_shared_data {
-	int nr_iter;
-	enum guest_stage guest_stage;
-	uint64_t xcnt;
-};
-
-static struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
-static pthread_t pt_vcpu_run[KVM_MAX_VCPUS];
-static struct test_vcpu_shared_data vcpu_shared_data[KVM_MAX_VCPUS];
-
 static int vtimer_irq, ptimer_irq;
 
-static unsigned long *vcpu_done_map;
-static pthread_mutex_t vcpu_done_map_lock;
-
 static void
 guest_configure_timer_action(struct test_vcpu_shared_data *shared_data)
 {
@@ -222,137 +163,6 @@ static void guest_code(void)
 	GUEST_DONE();
 }
 
-static void *test_vcpu_run(void *arg)
-{
-	unsigned int vcpu_idx = (unsigned long)arg;
-	struct ucall uc;
-	struct kvm_vcpu *vcpu = vcpus[vcpu_idx];
-	struct kvm_vm *vm = vcpu->vm;
-	struct test_vcpu_shared_data *shared_data = &vcpu_shared_data[vcpu_idx];
-
-	vcpu_run(vcpu);
-
-	/* Currently, any exit from guest is an indication of completion */
-	pthread_mutex_lock(&vcpu_done_map_lock);
-	__set_bit(vcpu_idx, vcpu_done_map);
-	pthread_mutex_unlock(&vcpu_done_map_lock);
-
-	switch (get_ucall(vcpu, &uc)) {
-	case UCALL_SYNC:
-	case UCALL_DONE:
-		break;
-	case UCALL_ABORT:
-		sync_global_from_guest(vm, *shared_data);
-		fprintf(stderr, "Guest assert failed,  vcpu %u; stage; %u; iter: %u\n",
-			vcpu_idx, shared_data->guest_stage, shared_data->nr_iter);
-		REPORT_GUEST_ASSERT(uc);
-		break;
-	default:
-		TEST_FAIL("Unexpected guest exit\n");
-	}
-
-	return NULL;
-}
-
-static uint32_t test_get_pcpu(void)
-{
-	uint32_t pcpu;
-	unsigned int nproc_conf;
-	cpu_set_t online_cpuset;
-
-	nproc_conf = get_nprocs_conf();
-	sched_getaffinity(0, sizeof(cpu_set_t), &online_cpuset);
-
-	/* Randomly find an available pCPU to place a vCPU on */
-	do {
-		pcpu = rand() % nproc_conf;
-	} while (!CPU_ISSET(pcpu, &online_cpuset));
-
-	return pcpu;
-}
-
-static int test_migrate_vcpu(unsigned int vcpu_idx)
-{
-	int ret;
-	cpu_set_t cpuset;
-	uint32_t new_pcpu = test_get_pcpu();
-
-	CPU_ZERO(&cpuset);
-	CPU_SET(new_pcpu, &cpuset);
-
-	pr_debug("Migrating vCPU: %u to pCPU: %u\n", vcpu_idx, new_pcpu);
-
-	ret = pthread_setaffinity_np(pt_vcpu_run[vcpu_idx],
-				     sizeof(cpuset), &cpuset);
-
-	/* Allow the error where the vCPU thread is already finished */
-	TEST_ASSERT(ret == 0 || ret == ESRCH,
-		    "Failed to migrate the vCPU:%u to pCPU: %u; ret: %d\n",
-		    vcpu_idx, new_pcpu, ret);
-
-	return ret;
-}
-
-static void *test_vcpu_migration(void *arg)
-{
-	unsigned int i, n_done;
-	bool vcpu_done;
-
-	do {
-		usleep(msecs_to_usecs(test_args.migration_freq_ms));
-
-		for (n_done = 0, i = 0; i < test_args.nr_vcpus; i++) {
-			pthread_mutex_lock(&vcpu_done_map_lock);
-			vcpu_done = test_bit(i, vcpu_done_map);
-			pthread_mutex_unlock(&vcpu_done_map_lock);
-
-			if (vcpu_done) {
-				n_done++;
-				continue;
-			}
-
-			test_migrate_vcpu(i);
-		}
-	} while (test_args.nr_vcpus != n_done);
-
-	return NULL;
-}
-
-static void test_run(struct kvm_vm *vm)
-{
-	pthread_t pt_vcpu_migration;
-	unsigned int i;
-	int ret;
-
-	pthread_mutex_init(&vcpu_done_map_lock, NULL);
-	vcpu_done_map = bitmap_zalloc(test_args.nr_vcpus);
-	TEST_ASSERT(vcpu_done_map, "Failed to allocate vcpu done bitmap\n");
-
-	for (i = 0; i < (unsigned long)test_args.nr_vcpus; i++) {
-		ret = pthread_create(&pt_vcpu_run[i], NULL, test_vcpu_run,
-				     (void *)(unsigned long)i);
-		TEST_ASSERT(!ret, "Failed to create vCPU-%d pthread\n", i);
-	}
-
-	/* Spawn a thread to control the vCPU migrations */
-	if (test_args.migration_freq_ms) {
-		srand(time(NULL));
-
-		ret = pthread_create(&pt_vcpu_migration, NULL,
-					test_vcpu_migration, NULL);
-		TEST_ASSERT(!ret, "Failed to create the migration pthread\n");
-	}
-
-
-	for (i = 0; i < test_args.nr_vcpus; i++)
-		pthread_join(pt_vcpu_run[i], NULL);
-
-	if (test_args.migration_freq_ms)
-		pthread_join(pt_vcpu_migration, NULL);
-
-	bitmap_free(vcpu_done_map);
-}
-
 static void test_init_timer_irq(struct kvm_vm *vm)
 {
 	/* Timer initid should be same for all the vCPUs, so query only vCPU-0 */
@@ -369,7 +179,7 @@ static void test_init_timer_irq(struct kvm_vm *vm)
 
 static int gic_fd;
 
-static struct kvm_vm *test_vm_create(void)
+struct kvm_vm *test_vm_create(void)
 {
 	struct kvm_vm *vm;
 	unsigned int i;
@@ -400,81 +210,8 @@ static struct kvm_vm *test_vm_create(void)
 	return vm;
 }
 
-static void test_vm_cleanup(struct kvm_vm *vm)
+void test_vm_cleanup(struct kvm_vm *vm)
 {
 	close(gic_fd);
 	kvm_vm_free(vm);
 }
-
-static void test_print_help(char *name)
-{
-	pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n",
-		name);
-	pr_info("\t-n: Number of vCPUs to configure (default: %u; max: %u)\n",
-		NR_VCPUS_DEF, KVM_MAX_VCPUS);
-	pr_info("\t-i: Number of iterations per stage (default: %u)\n",
-		NR_TEST_ITERS_DEF);
-	pr_info("\t-p: Periodicity (in ms) of the guest timer (default: %u)\n",
-		TIMER_TEST_PERIOD_MS_DEF);
-	pr_info("\t-m: Frequency (in ms) of vCPUs to migrate to different pCPU. 0 to turn off (default: %u)\n",
-		TIMER_TEST_MIGRATION_FREQ_MS);
-	pr_info("\t-o: Counter offset (in counter cycles, default: 0)\n");
-	pr_info("\t-h: print this help screen\n");
-}
-
-static bool parse_args(int argc, char *argv[])
-{
-	int opt;
-
-	while ((opt = getopt(argc, argv, "hn:i:p:m:o:")) != -1) {
-		switch (opt) {
-		case 'n':
-			test_args.nr_vcpus = atoi_positive("Number of vCPUs", optarg);
-			if (test_args.nr_vcpus > KVM_MAX_VCPUS) {
-				pr_info("Max allowed vCPUs: %u\n",
-					KVM_MAX_VCPUS);
-				goto err;
-			}
-			break;
-		case 'i':
-			test_args.nr_iter = atoi_positive("Number of iterations", optarg);
-			break;
-		case 'p':
-			test_args.timer_period_ms = atoi_positive("Periodicity", optarg);
-			break;
-		case 'm':
-			test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
-			break;
-		case 'o':
-			test_args.offset.counter_offset = strtol(optarg, NULL, 0);
-			test_args.offset.reserved = 0;
-			break;
-		case 'h':
-		default:
-			goto err;
-		}
-	}
-
-	return true;
-
-err:
-	test_print_help(argv[0]);
-	return false;
-}
-
-int main(int argc, char *argv[])
-{
-	struct kvm_vm *vm;
-
-	if (!parse_args(argc, argv))
-		exit(KSFT_SKIP);
-
-	__TEST_REQUIRE(!test_args.migration_freq_ms || get_nprocs() >= 2,
-		       "At least two physical CPUs needed for vCPU migration");
-
-	vm = test_vm_create();
-	test_run(vm);
-	test_vm_cleanup(vm);
-
-	return 0;
-}
diff --git a/tools/testing/selftests/kvm/arch_timer.c b/tools/testing/selftests/kvm/arch_timer.c
new file mode 100644
index 000000000000..6e442dbcfc8b
--- /dev/null
+++ b/tools/testing/selftests/kvm/arch_timer.c
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * arch_timer.c - Tests the arch timer IRQ functionality
+ *
+ * The guest's main thread configures the timer interrupt and waits
+ * for it to fire, with a timeout equal to the timer period.
+ * It asserts that the timeout doesn't exceed the timer period plus
+ * an error margin of 100us.
+ *
+ * On the other hand, upon receipt of an interrupt, the guest's interrupt
+ * handler validates the interrupt by checking if the architectural state
+ * is in compliance with the specifications.
+ *
+ * The test provides command-line options to configure the timer's
+ * period (-p), number of vCPUs (-n), and iterations per stage (-i).
+ * To stress-test the timer stack even more, an option to migrate the
+ * vCPUs across pCPUs (-m), at a particular rate, is also provided.
+ *
+ * Copyright (c) 2021, Google LLC.
+ */
+
+#define _GNU_SOURCE
+
+#include <stdlib.h>
+#include <pthread.h>
+#include <linux/sizes.h>
+#include <linux/bitmap.h>
+#include <sys/sysinfo.h>
+
+#include "timer_test.h"
+
+struct test_args test_args = {
+	.nr_vcpus = NR_VCPUS_DEF,
+	.nr_iter = NR_TEST_ITERS_DEF,
+	.timer_period_ms = TIMER_TEST_PERIOD_MS_DEF,
+	.migration_freq_ms = TIMER_TEST_MIGRATION_FREQ_MS,
+	.offset = { .reserved = 1 },
+};
+
+struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
+struct test_vcpu_shared_data vcpu_shared_data[KVM_MAX_VCPUS];
+
+static pthread_t pt_vcpu_run[KVM_MAX_VCPUS];
+static unsigned long *vcpu_done_map;
+static pthread_mutex_t vcpu_done_map_lock;
+
+static void *test_vcpu_run(void *arg)
+{
+	unsigned int vcpu_idx = (unsigned long)arg;
+	struct ucall uc;
+	struct kvm_vcpu *vcpu = vcpus[vcpu_idx];
+	struct kvm_vm *vm = vcpu->vm;
+	struct test_vcpu_shared_data *shared_data = &vcpu_shared_data[vcpu_idx];
+
+	vcpu_run(vcpu);
+
+	/* Currently, any exit from guest is an indication of completion */
+	pthread_mutex_lock(&vcpu_done_map_lock);
+	__set_bit(vcpu_idx, vcpu_done_map);
+	pthread_mutex_unlock(&vcpu_done_map_lock);
+
+	switch (get_ucall(vcpu, &uc)) {
+	case UCALL_SYNC:
+	case UCALL_DONE:
+		break;
+	case UCALL_ABORT:
+		sync_global_from_guest(vm, *shared_data);
+		fprintf(stderr, "Guest assert failed,  vcpu %u; stage; %u; iter: %u\n",
+			vcpu_idx, shared_data->guest_stage, shared_data->nr_iter);
+		REPORT_GUEST_ASSERT(uc);
+		break;
+	default:
+		TEST_FAIL("Unexpected guest exit\n");
+	}
+
+	return NULL;
+}
+
+static uint32_t test_get_pcpu(void)
+{
+	uint32_t pcpu;
+	unsigned int nproc_conf;
+	cpu_set_t online_cpuset;
+
+	nproc_conf = get_nprocs_conf();
+	sched_getaffinity(0, sizeof(cpu_set_t), &online_cpuset);
+
+	/* Randomly find an available pCPU to place a vCPU on */
+	do {
+		pcpu = rand() % nproc_conf;
+	} while (!CPU_ISSET(pcpu, &online_cpuset));
+
+	return pcpu;
+}
+
+static int test_migrate_vcpu(unsigned int vcpu_idx)
+{
+	int ret;
+	cpu_set_t cpuset;
+	uint32_t new_pcpu = test_get_pcpu();
+
+	CPU_ZERO(&cpuset);
+	CPU_SET(new_pcpu, &cpuset);
+
+	pr_debug("Migrating vCPU: %u to pCPU: %u\n", vcpu_idx, new_pcpu);
+
+	ret = pthread_setaffinity_np(pt_vcpu_run[vcpu_idx],
+				     sizeof(cpuset), &cpuset);
+
+	/* Allow the error where the vCPU thread is already finished */
+	TEST_ASSERT(ret == 0 || ret == ESRCH,
+		    "Failed to migrate the vCPU:%u to pCPU: %u; ret: %d\n",
+		    vcpu_idx, new_pcpu, ret);
+
+	return ret;
+}
+
+static void *test_vcpu_migration(void *arg)
+{
+	unsigned int i, n_done;
+	bool vcpu_done;
+
+	do {
+		usleep(msecs_to_usecs(test_args.migration_freq_ms));
+
+		for (n_done = 0, i = 0; i < test_args.nr_vcpus; i++) {
+			pthread_mutex_lock(&vcpu_done_map_lock);
+			vcpu_done = test_bit(i, vcpu_done_map);
+			pthread_mutex_unlock(&vcpu_done_map_lock);
+
+			if (vcpu_done) {
+				n_done++;
+				continue;
+			}
+
+			test_migrate_vcpu(i);
+		}
+	} while (test_args.nr_vcpus != n_done);
+
+	return NULL;
+}
+
+static void test_run(struct kvm_vm *vm)
+{
+	pthread_t pt_vcpu_migration;
+	unsigned int i;
+	int ret;
+
+	pthread_mutex_init(&vcpu_done_map_lock, NULL);
+	vcpu_done_map = bitmap_zalloc(test_args.nr_vcpus);
+	TEST_ASSERT(vcpu_done_map, "Failed to allocate vcpu done bitmap\n");
+
+	for (i = 0; i < (unsigned long)test_args.nr_vcpus; i++) {
+		ret = pthread_create(&pt_vcpu_run[i], NULL, test_vcpu_run,
+				     (void *)(unsigned long)i);
+		TEST_ASSERT(!ret, "Failed to create vCPU-%d pthread\n", i);
+	}
+
+	/* Spawn a thread to control the vCPU migrations */
+	if (test_args.migration_freq_ms) {
+		srand(time(NULL));
+
+		ret = pthread_create(&pt_vcpu_migration, NULL,
+					test_vcpu_migration, NULL);
+		TEST_ASSERT(!ret, "Failed to create the migration pthread\n");
+	}
+
+
+	for (i = 0; i < test_args.nr_vcpus; i++)
+		pthread_join(pt_vcpu_run[i], NULL);
+
+	if (test_args.migration_freq_ms)
+		pthread_join(pt_vcpu_migration, NULL);
+
+	bitmap_free(vcpu_done_map);
+}
+
+static void test_print_help(char *name)
+{
+	pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n",
+		name);
+	pr_info("\t-n: Number of vCPUs to configure (default: %u; max: %u)\n",
+		NR_VCPUS_DEF, KVM_MAX_VCPUS);
+	pr_info("\t-i: Number of iterations per stage (default: %u)\n",
+		NR_TEST_ITERS_DEF);
+	pr_info("\t-p: Periodicity (in ms) of the guest timer (default: %u)\n",
+		TIMER_TEST_PERIOD_MS_DEF);
+	pr_info("\t-m: Frequency (in ms) of vCPUs to migrate to different pCPU. 0 to turn off (default: %u)\n",
+		TIMER_TEST_MIGRATION_FREQ_MS);
+	pr_info("\t-o: Counter offset (in counter cycles, default: 0)\n");
+	pr_info("\t-h: print this help screen\n");
+}
+
+static bool parse_args(int argc, char *argv[])
+{
+	int opt;
+
+	while ((opt = getopt(argc, argv, "hn:i:p:m:o:")) != -1) {
+		switch (opt) {
+		case 'n':
+			test_args.nr_vcpus = atoi_positive("Number of vCPUs", optarg);
+			if (test_args.nr_vcpus > KVM_MAX_VCPUS) {
+				pr_info("Max allowed vCPUs: %u\n",
+					KVM_MAX_VCPUS);
+				goto err;
+			}
+			break;
+		case 'i':
+			test_args.nr_iter = atoi_positive("Number of iterations", optarg);
+			break;
+		case 'p':
+			test_args.timer_period_ms = atoi_positive("Periodicity", optarg);
+			break;
+		case 'm':
+			test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
+			break;
+		case 'o':
+			test_args.offset.counter_offset = strtol(optarg, NULL, 0);
+			test_args.offset.reserved = 0;
+			break;
+		case 'h':
+		default:
+			goto err;
+		}
+	}
+
+	return true;
+
+err:
+	test_print_help(argv[0]);
+	return false;
+}
+
+int main(int argc, char *argv[])
+{
+	struct kvm_vm *vm;
+
+	if (!parse_args(argc, argv))
+		exit(KSFT_SKIP);
+
+	__TEST_REQUIRE(!test_args.migration_freq_ms || get_nprocs() >= 2,
+		       "At least two physical CPUs needed for vCPU migration");
+
+	vm = test_vm_create();
+	test_run(vm);
+	test_vm_cleanup(vm);
+
+	return 0;
+}
diff --git a/tools/testing/selftests/kvm/include/test_util.h b/tools/testing/selftests/kvm/include/test_util.h
index 8e5f413a593d..36387e7ee8b2 100644
--- a/tools/testing/selftests/kvm/include/test_util.h
+++ b/tools/testing/selftests/kvm/include/test_util.h
@@ -20,6 +20,8 @@
 #include <sys/mman.h>
 #include "kselftest.h"
 
+#define msecs_to_usecs(msec)    ((msec) * 1000LL)
+
 static inline int _no_printf(const char *format, ...) { return 0; }
 
 #ifdef DEBUG
diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
new file mode 100644
index 000000000000..2234c513b510
--- /dev/null
+++ b/tools/testing/selftests/kvm/include/timer_test.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * timer test specific header
+ *
+ * Copyright (C) 2018, Google LLC
+ */
+
+#ifndef SELFTEST_KVM_TIMER_TEST_H
+#define SELFTEST_KVM_TIMER_TEST_H
+
+#include "kvm_util.h"
+
+#define NR_VCPUS_DEF            4
+#define NR_TEST_ITERS_DEF       5
+#define TIMER_TEST_PERIOD_MS_DEF    10
+#define TIMER_TEST_ERR_MARGIN_US    100
+#define TIMER_TEST_MIGRATION_FREQ_MS    2
+
+/* Timer test cmdline parameters */
+struct test_args {
+	int nr_vcpus;
+	int nr_iter;
+	int timer_period_ms;
+	int migration_freq_ms;
+	/* TODO: Change arm specific type to a common one */
+	struct kvm_arm_counter_offset offset;
+};
+
+/* Shared variables between host and guest */
+struct test_vcpu_shared_data {
+	int nr_iter;
+	int guest_stage;
+	uint64_t xcnt;
+};
+
+extern struct test_args test_args;
+extern struct kvm_vcpu *vcpus[];
+extern struct test_vcpu_shared_data vcpu_shared_data[];
+
+struct kvm_vm *test_vm_create(void);
+void test_vm_cleanup(struct kvm_vm *vm);
+
+#endif /* SELFTEST_KVM_TIMER_TEST_H */
-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:12 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:12 +0800
Subject: [PATCH v4 03/11] KVM: selftests: Add CONFIG_64BIT definition for the build
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <227b86955b24583b5cacedc8480e8f5d7e4fabf8.1702371136.git.haibo1.xu@intel.com>

Since only 64bit KVM selftests were supported on all architectures,
add the CONFIG_64BIT definition in kvm/Makefile to ensure only 64bit
definitions were available in the corresponding included files.

Suggested-by: Andrew Jones <ajones at ventanamicro.com>
Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
---
 tools/testing/selftests/kvm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index 4838ea899bbb..bb03e278a163 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -225,7 +225,7 @@ else
 LINUX_TOOL_ARCH_INCLUDE = $(top_srcdir)/tools/arch/$(ARCH)/include
 endif
 CFLAGS += -Wall -Wstrict-prototypes -Wuninitialized -O2 -g -std=gnu99 \
-	-Wno-gnu-variable-sized-type-not-at-end -MD\
+	-Wno-gnu-variable-sized-type-not-at-end -MD -DCONFIG_64BIT \
 	-fno-builtin-memcmp -fno-builtin-memcpy -fno-builtin-memset \
 	-fno-builtin-strnlen \
 	-fno-stack-protector -fno-PIE -I$(LINUX_TOOL_INCLUDE) \
-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:13 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:13 +0800
Subject: [PATCH v4 04/11] tools: riscv: Add header file csr.h
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <a5386f449f0bae9887769a79ef7ae6aed342767d.1702371136.git.haibo1.xu@intel.com>

Borrow the csr definitions and operations from kernel's
arch/riscv/include/asm/csr.h to tools/ for riscv.

Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
---
 tools/arch/riscv/include/asm/csr.h | 521 +++++++++++++++++++++++++++++
 1 file changed, 521 insertions(+)
 create mode 100644 tools/arch/riscv/include/asm/csr.h

diff --git a/tools/arch/riscv/include/asm/csr.h b/tools/arch/riscv/include/asm/csr.h
new file mode 100644
index 000000000000..4e86c82aacbd
--- /dev/null
+++ b/tools/arch/riscv/include/asm/csr.h
@@ -0,0 +1,521 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2015 Regents of the University of California
+ */
+
+#ifndef _ASM_RISCV_CSR_H
+#define _ASM_RISCV_CSR_H
+
+#include <linux/bits.h>
+
+/* Status register flags */
+#define SR_SIE		_AC(0x00000002, UL) /* Supervisor Interrupt Enable */
+#define SR_MIE		_AC(0x00000008, UL) /* Machine Interrupt Enable */
+#define SR_SPIE		_AC(0x00000020, UL) /* Previous Supervisor IE */
+#define SR_MPIE		_AC(0x00000080, UL) /* Previous Machine IE */
+#define SR_SPP		_AC(0x00000100, UL) /* Previously Supervisor */
+#define SR_MPP		_AC(0x00001800, UL) /* Previously Machine */
+#define SR_SUM		_AC(0x00040000, UL) /* Supervisor User Memory Access */
+
+#define SR_FS		_AC(0x00006000, UL) /* Floating-point Status */
+#define SR_FS_OFF	_AC(0x00000000, UL)
+#define SR_FS_INITIAL	_AC(0x00002000, UL)
+#define SR_FS_CLEAN	_AC(0x00004000, UL)
+#define SR_FS_DIRTY	_AC(0x00006000, UL)
+
+#define SR_VS		_AC(0x00000600, UL) /* Vector Status */
+#define SR_VS_OFF	_AC(0x00000000, UL)
+#define SR_VS_INITIAL	_AC(0x00000200, UL)
+#define SR_VS_CLEAN	_AC(0x00000400, UL)
+#define SR_VS_DIRTY	_AC(0x00000600, UL)
+
+#define SR_XS		_AC(0x00018000, UL) /* Extension Status */
+#define SR_XS_OFF	_AC(0x00000000, UL)
+#define SR_XS_INITIAL	_AC(0x00008000, UL)
+#define SR_XS_CLEAN	_AC(0x00010000, UL)
+#define SR_XS_DIRTY	_AC(0x00018000, UL)
+
+#define SR_FS_VS	(SR_FS | SR_VS) /* Vector and Floating-Point Unit */
+
+#ifndef CONFIG_64BIT
+#define SR_SD		_AC(0x80000000, UL) /* FS/VS/XS dirty */
+#else
+#define SR_SD		_AC(0x8000000000000000, UL) /* FS/VS/XS dirty */
+#endif
+
+#ifdef CONFIG_64BIT
+#define SR_UXL		_AC(0x300000000, UL) /* XLEN mask for U-mode */
+#define SR_UXL_32	_AC(0x100000000, UL) /* XLEN = 32 for U-mode */
+#define SR_UXL_64	_AC(0x200000000, UL) /* XLEN = 64 for U-mode */
+#endif
+
+/* SATP flags */
+#ifndef CONFIG_64BIT
+#define SATP_PPN	_AC(0x003FFFFF, UL)
+#define SATP_MODE_32	_AC(0x80000000, UL)
+#define SATP_ASID_BITS	9
+#define SATP_ASID_SHIFT	22
+#define SATP_ASID_MASK	_AC(0x1FF, UL)
+#else
+#define SATP_PPN	_AC(0x00000FFFFFFFFFFF, UL)
+#define SATP_MODE_39	_AC(0x8000000000000000, UL)
+#define SATP_MODE_48	_AC(0x9000000000000000, UL)
+#define SATP_MODE_57	_AC(0xa000000000000000, UL)
+#define SATP_ASID_BITS	16
+#define SATP_ASID_SHIFT	44
+#define SATP_ASID_MASK	_AC(0xFFFF, UL)
+#endif
+
+/* Exception cause high bit - is an interrupt if set */
+#define CAUSE_IRQ_FLAG		(_AC(1, UL) << (__riscv_xlen - 1))
+
+/* Interrupt causes (minus the high bit) */
+#define IRQ_S_SOFT		1
+#define IRQ_VS_SOFT		2
+#define IRQ_M_SOFT		3
+#define IRQ_S_TIMER		5
+#define IRQ_VS_TIMER		6
+#define IRQ_M_TIMER		7
+#define IRQ_S_EXT		9
+#define IRQ_VS_EXT		10
+#define IRQ_M_EXT		11
+#define IRQ_S_GEXT		12
+#define IRQ_PMU_OVF		13
+#define IRQ_LOCAL_MAX		(IRQ_PMU_OVF + 1)
+#define IRQ_LOCAL_MASK		GENMASK((IRQ_LOCAL_MAX - 1), 0)
+
+/* Exception causes */
+#define EXC_INST_MISALIGNED	0
+#define EXC_INST_ACCESS		1
+#define EXC_INST_ILLEGAL	2
+#define EXC_BREAKPOINT		3
+#define EXC_LOAD_MISALIGNED	4
+#define EXC_LOAD_ACCESS		5
+#define EXC_STORE_MISALIGNED	6
+#define EXC_STORE_ACCESS	7
+#define EXC_SYSCALL		8
+#define EXC_HYPERVISOR_SYSCALL	9
+#define EXC_SUPERVISOR_SYSCALL	10
+#define EXC_INST_PAGE_FAULT	12
+#define EXC_LOAD_PAGE_FAULT	13
+#define EXC_STORE_PAGE_FAULT	15
+#define EXC_INST_GUEST_PAGE_FAULT	20
+#define EXC_LOAD_GUEST_PAGE_FAULT	21
+#define EXC_VIRTUAL_INST_FAULT		22
+#define EXC_STORE_GUEST_PAGE_FAULT	23
+
+/* PMP configuration */
+#define PMP_R			0x01
+#define PMP_W			0x02
+#define PMP_X			0x04
+#define PMP_A			0x18
+#define PMP_A_TOR		0x08
+#define PMP_A_NA4		0x10
+#define PMP_A_NAPOT		0x18
+#define PMP_L			0x80
+
+/* HSTATUS flags */
+#ifdef CONFIG_64BIT
+#define HSTATUS_VSXL		_AC(0x300000000, UL)
+#define HSTATUS_VSXL_SHIFT	32
+#endif
+#define HSTATUS_VTSR		_AC(0x00400000, UL)
+#define HSTATUS_VTW		_AC(0x00200000, UL)
+#define HSTATUS_VTVM		_AC(0x00100000, UL)
+#define HSTATUS_VGEIN		_AC(0x0003f000, UL)
+#define HSTATUS_VGEIN_SHIFT	12
+#define HSTATUS_HU		_AC(0x00000200, UL)
+#define HSTATUS_SPVP		_AC(0x00000100, UL)
+#define HSTATUS_SPV		_AC(0x00000080, UL)
+#define HSTATUS_GVA		_AC(0x00000040, UL)
+#define HSTATUS_VSBE		_AC(0x00000020, UL)
+
+/* HGATP flags */
+#define HGATP_MODE_OFF		_AC(0, UL)
+#define HGATP_MODE_SV32X4	_AC(1, UL)
+#define HGATP_MODE_SV39X4	_AC(8, UL)
+#define HGATP_MODE_SV48X4	_AC(9, UL)
+#define HGATP_MODE_SV57X4	_AC(10, UL)
+
+#define HGATP32_MODE_SHIFT	31
+#define HGATP32_VMID_SHIFT	22
+#define HGATP32_VMID		GENMASK(28, 22)
+#define HGATP32_PPN		GENMASK(21, 0)
+
+#define HGATP64_MODE_SHIFT	60
+#define HGATP64_VMID_SHIFT	44
+#define HGATP64_VMID		GENMASK(57, 44)
+#define HGATP64_PPN		GENMASK(43, 0)
+
+#define HGATP_PAGE_SHIFT	12
+
+#ifdef CONFIG_64BIT
+#define HGATP_PPN		HGATP64_PPN
+#define HGATP_VMID_SHIFT	HGATP64_VMID_SHIFT
+#define HGATP_VMID		HGATP64_VMID
+#define HGATP_MODE_SHIFT	HGATP64_MODE_SHIFT
+#else
+#define HGATP_PPN		HGATP32_PPN
+#define HGATP_VMID_SHIFT	HGATP32_VMID_SHIFT
+#define HGATP_VMID		HGATP32_VMID
+#define HGATP_MODE_SHIFT	HGATP32_MODE_SHIFT
+#endif
+
+/* VSIP & HVIP relation */
+#define VSIP_TO_HVIP_SHIFT	(IRQ_VS_SOFT - IRQ_S_SOFT)
+#define VSIP_VALID_MASK		((_AC(1, UL) << IRQ_S_SOFT) | \
+				 (_AC(1, UL) << IRQ_S_TIMER) | \
+				 (_AC(1, UL) << IRQ_S_EXT))
+
+/* AIA CSR bits */
+#define TOPI_IID_SHIFT		16
+#define TOPI_IID_MASK		GENMASK(11, 0)
+#define TOPI_IPRIO_MASK		GENMASK(7, 0)
+#define TOPI_IPRIO_BITS		8
+
+#define TOPEI_ID_SHIFT		16
+#define TOPEI_ID_MASK		GENMASK(10, 0)
+#define TOPEI_PRIO_MASK		GENMASK(10, 0)
+
+#define ISELECT_IPRIO0		0x30
+#define ISELECT_IPRIO15		0x3f
+#define ISELECT_MASK		GENMASK(8, 0)
+
+#define HVICTL_VTI		BIT(30)
+#define HVICTL_IID		GENMASK(27, 16)
+#define HVICTL_IID_SHIFT	16
+#define HVICTL_DPR		BIT(9)
+#define HVICTL_IPRIOM		BIT(8)
+#define HVICTL_IPRIO		GENMASK(7, 0)
+
+/* xENVCFG flags */
+#define ENVCFG_STCE			(_AC(1, ULL) << 63)
+#define ENVCFG_PBMTE			(_AC(1, ULL) << 62)
+#define ENVCFG_CBZE			(_AC(1, UL) << 7)
+#define ENVCFG_CBCFE			(_AC(1, UL) << 6)
+#define ENVCFG_CBIE_SHIFT		4
+#define ENVCFG_CBIE			(_AC(0x3, UL) << ENVCFG_CBIE_SHIFT)
+#define ENVCFG_CBIE_ILL			_AC(0x0, UL)
+#define ENVCFG_CBIE_FLUSH		_AC(0x1, UL)
+#define ENVCFG_CBIE_INV			_AC(0x3, UL)
+#define ENVCFG_FIOM			_AC(0x1, UL)
+
+/* symbolic CSR names: */
+#define CSR_CYCLE		0xc00
+#define CSR_TIME		0xc01
+#define CSR_INSTRET		0xc02
+#define CSR_HPMCOUNTER3		0xc03
+#define CSR_HPMCOUNTER4		0xc04
+#define CSR_HPMCOUNTER5		0xc05
+#define CSR_HPMCOUNTER6		0xc06
+#define CSR_HPMCOUNTER7		0xc07
+#define CSR_HPMCOUNTER8		0xc08
+#define CSR_HPMCOUNTER9		0xc09
+#define CSR_HPMCOUNTER10	0xc0a
+#define CSR_HPMCOUNTER11	0xc0b
+#define CSR_HPMCOUNTER12	0xc0c
+#define CSR_HPMCOUNTER13	0xc0d
+#define CSR_HPMCOUNTER14	0xc0e
+#define CSR_HPMCOUNTER15	0xc0f
+#define CSR_HPMCOUNTER16	0xc10
+#define CSR_HPMCOUNTER17	0xc11
+#define CSR_HPMCOUNTER18	0xc12
+#define CSR_HPMCOUNTER19	0xc13
+#define CSR_HPMCOUNTER20	0xc14
+#define CSR_HPMCOUNTER21	0xc15
+#define CSR_HPMCOUNTER22	0xc16
+#define CSR_HPMCOUNTER23	0xc17
+#define CSR_HPMCOUNTER24	0xc18
+#define CSR_HPMCOUNTER25	0xc19
+#define CSR_HPMCOUNTER26	0xc1a
+#define CSR_HPMCOUNTER27	0xc1b
+#define CSR_HPMCOUNTER28	0xc1c
+#define CSR_HPMCOUNTER29	0xc1d
+#define CSR_HPMCOUNTER30	0xc1e
+#define CSR_HPMCOUNTER31	0xc1f
+#define CSR_CYCLEH		0xc80
+#define CSR_TIMEH		0xc81
+#define CSR_INSTRETH		0xc82
+#define CSR_HPMCOUNTER3H	0xc83
+#define CSR_HPMCOUNTER4H	0xc84
+#define CSR_HPMCOUNTER5H	0xc85
+#define CSR_HPMCOUNTER6H	0xc86
+#define CSR_HPMCOUNTER7H	0xc87
+#define CSR_HPMCOUNTER8H	0xc88
+#define CSR_HPMCOUNTER9H	0xc89
+#define CSR_HPMCOUNTER10H	0xc8a
+#define CSR_HPMCOUNTER11H	0xc8b
+#define CSR_HPMCOUNTER12H	0xc8c
+#define CSR_HPMCOUNTER13H	0xc8d
+#define CSR_HPMCOUNTER14H	0xc8e
+#define CSR_HPMCOUNTER15H	0xc8f
+#define CSR_HPMCOUNTER16H	0xc90
+#define CSR_HPMCOUNTER17H	0xc91
+#define CSR_HPMCOUNTER18H	0xc92
+#define CSR_HPMCOUNTER19H	0xc93
+#define CSR_HPMCOUNTER20H	0xc94
+#define CSR_HPMCOUNTER21H	0xc95
+#define CSR_HPMCOUNTER22H	0xc96
+#define CSR_HPMCOUNTER23H	0xc97
+#define CSR_HPMCOUNTER24H	0xc98
+#define CSR_HPMCOUNTER25H	0xc99
+#define CSR_HPMCOUNTER26H	0xc9a
+#define CSR_HPMCOUNTER27H	0xc9b
+#define CSR_HPMCOUNTER28H	0xc9c
+#define CSR_HPMCOUNTER29H	0xc9d
+#define CSR_HPMCOUNTER30H	0xc9e
+#define CSR_HPMCOUNTER31H	0xc9f
+
+#define CSR_SSCOUNTOVF		0xda0
+
+#define CSR_SSTATUS		0x100
+#define CSR_SIE			0x104
+#define CSR_STVEC		0x105
+#define CSR_SCOUNTEREN		0x106
+#define CSR_SSCRATCH		0x140
+#define CSR_SEPC		0x141
+#define CSR_SCAUSE		0x142
+#define CSR_STVAL		0x143
+#define CSR_SIP			0x144
+#define CSR_SATP		0x180
+
+#define CSR_STIMECMP		0x14D
+#define CSR_STIMECMPH		0x15D
+
+/* Supervisor-Level Window to Indirectly Accessed Registers (AIA) */
+#define CSR_SISELECT		0x150
+#define CSR_SIREG		0x151
+
+/* Supervisor-Level Interrupts (AIA) */
+#define CSR_STOPEI		0x15c
+#define CSR_STOPI		0xdb0
+
+/* Supervisor-Level High-Half CSRs (AIA) */
+#define CSR_SIEH		0x114
+#define CSR_SIPH		0x154
+
+#define CSR_VSSTATUS		0x200
+#define CSR_VSIE		0x204
+#define CSR_VSTVEC		0x205
+#define CSR_VSSCRATCH		0x240
+#define CSR_VSEPC		0x241
+#define CSR_VSCAUSE		0x242
+#define CSR_VSTVAL		0x243
+#define CSR_VSIP		0x244
+#define CSR_VSATP		0x280
+#define CSR_VSTIMECMP		0x24D
+#define CSR_VSTIMECMPH		0x25D
+
+#define CSR_HSTATUS		0x600
+#define CSR_HEDELEG		0x602
+#define CSR_HIDELEG		0x603
+#define CSR_HIE			0x604
+#define CSR_HTIMEDELTA		0x605
+#define CSR_HCOUNTEREN		0x606
+#define CSR_HGEIE		0x607
+#define CSR_HENVCFG		0x60a
+#define CSR_HTIMEDELTAH		0x615
+#define CSR_HENVCFGH		0x61a
+#define CSR_HTVAL		0x643
+#define CSR_HIP			0x644
+#define CSR_HVIP		0x645
+#define CSR_HTINST		0x64a
+#define CSR_HGATP		0x680
+#define CSR_HGEIP		0xe12
+
+/* Virtual Interrupts and Interrupt Priorities (H-extension with AIA) */
+#define CSR_HVIEN		0x608
+#define CSR_HVICTL		0x609
+#define CSR_HVIPRIO1		0x646
+#define CSR_HVIPRIO2		0x647
+
+/* VS-Level Window to Indirectly Accessed Registers (H-extension with AIA) */
+#define CSR_VSISELECT		0x250
+#define CSR_VSIREG		0x251
+
+/* VS-Level Interrupts (H-extension with AIA) */
+#define CSR_VSTOPEI		0x25c
+#define CSR_VSTOPI		0xeb0
+
+/* Hypervisor and VS-Level High-Half CSRs (H-extension with AIA) */
+#define CSR_HIDELEGH		0x613
+#define CSR_HVIENH		0x618
+#define CSR_HVIPH		0x655
+#define CSR_HVIPRIO1H		0x656
+#define CSR_HVIPRIO2H		0x657
+#define CSR_VSIEH		0x214
+#define CSR_VSIPH		0x254
+
+#define CSR_MSTATUS		0x300
+#define CSR_MISA		0x301
+#define CSR_MIDELEG		0x303
+#define CSR_MIE			0x304
+#define CSR_MTVEC		0x305
+#define CSR_MENVCFG		0x30a
+#define CSR_MENVCFGH		0x31a
+#define CSR_MSCRATCH		0x340
+#define CSR_MEPC		0x341
+#define CSR_MCAUSE		0x342
+#define CSR_MTVAL		0x343
+#define CSR_MIP			0x344
+#define CSR_PMPCFG0		0x3a0
+#define CSR_PMPADDR0		0x3b0
+#define CSR_MVENDORID		0xf11
+#define CSR_MARCHID		0xf12
+#define CSR_MIMPID		0xf13
+#define CSR_MHARTID		0xf14
+
+/* Machine-Level Window to Indirectly Accessed Registers (AIA) */
+#define CSR_MISELECT		0x350
+#define CSR_MIREG		0x351
+
+/* Machine-Level Interrupts (AIA) */
+#define CSR_MTOPEI		0x35c
+#define CSR_MTOPI		0xfb0
+
+/* Virtual Interrupts for Supervisor Level (AIA) */
+#define CSR_MVIEN		0x308
+#define CSR_MVIP		0x309
+
+/* Machine-Level High-Half CSRs (AIA) */
+#define CSR_MIDELEGH		0x313
+#define CSR_MIEH		0x314
+#define CSR_MVIENH		0x318
+#define CSR_MVIPH		0x319
+#define CSR_MIPH		0x354
+
+#define CSR_VSTART		0x8
+#define CSR_VCSR		0xf
+#define CSR_VL			0xc20
+#define CSR_VTYPE		0xc21
+#define CSR_VLENB		0xc22
+
+#ifdef CONFIG_RISCV_M_MODE
+# define CSR_STATUS	CSR_MSTATUS
+# define CSR_IE		CSR_MIE
+# define CSR_TVEC	CSR_MTVEC
+# define CSR_SCRATCH	CSR_MSCRATCH
+# define CSR_EPC	CSR_MEPC
+# define CSR_CAUSE	CSR_MCAUSE
+# define CSR_TVAL	CSR_MTVAL
+# define CSR_IP		CSR_MIP
+
+# define CSR_IEH		CSR_MIEH
+# define CSR_ISELECT	CSR_MISELECT
+# define CSR_IREG	CSR_MIREG
+# define CSR_IPH		CSR_MIPH
+# define CSR_TOPEI	CSR_MTOPEI
+# define CSR_TOPI	CSR_MTOPI
+
+# define SR_IE		SR_MIE
+# define SR_PIE		SR_MPIE
+# define SR_PP		SR_MPP
+
+# define RV_IRQ_SOFT		IRQ_M_SOFT
+# define RV_IRQ_TIMER	IRQ_M_TIMER
+# define RV_IRQ_EXT		IRQ_M_EXT
+#else /* CONFIG_RISCV_M_MODE */
+# define CSR_STATUS	CSR_SSTATUS
+# define CSR_IE		CSR_SIE
+# define CSR_TVEC	CSR_STVEC
+# define CSR_SCRATCH	CSR_SSCRATCH
+# define CSR_EPC	CSR_SEPC
+# define CSR_CAUSE	CSR_SCAUSE
+# define CSR_TVAL	CSR_STVAL
+# define CSR_IP		CSR_SIP
+
+# define CSR_IEH		CSR_SIEH
+# define CSR_ISELECT	CSR_SISELECT
+# define CSR_IREG	CSR_SIREG
+# define CSR_IPH		CSR_SIPH
+# define CSR_TOPEI	CSR_STOPEI
+# define CSR_TOPI	CSR_STOPI
+
+# define SR_IE		SR_SIE
+# define SR_PIE		SR_SPIE
+# define SR_PP		SR_SPP
+
+# define RV_IRQ_SOFT		IRQ_S_SOFT
+# define RV_IRQ_TIMER	IRQ_S_TIMER
+# define RV_IRQ_EXT		IRQ_S_EXT
+# define RV_IRQ_PMU	IRQ_PMU_OVF
+# define SIP_LCOFIP     (_AC(0x1, UL) << IRQ_PMU_OVF)
+
+#endif /* !CONFIG_RISCV_M_MODE */
+
+/* IE/IP (Supervisor/Machine Interrupt Enable/Pending) flags */
+#define IE_SIE		(_AC(0x1, UL) << RV_IRQ_SOFT)
+#define IE_TIE		(_AC(0x1, UL) << RV_IRQ_TIMER)
+#define IE_EIE		(_AC(0x1, UL) << RV_IRQ_EXT)
+
+#ifdef __ASSEMBLY__
+#define __ASM_STR(x)    x
+#else
+#define __ASM_STR(x)    #x
+#endif
+
+#ifndef __ASSEMBLY__
+
+#define csr_swap(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrrw %0, " __ASM_STR(csr) ", %1"\
+			      : "=r" (__v) : "rK" (__v)		\
+			      : "memory");			\
+	__v;							\
+})
+
+#define csr_read(csr)						\
+({								\
+	register unsigned long __v;				\
+	__asm__ __volatile__ ("csrr %0, " __ASM_STR(csr)	\
+			      : "=r" (__v) :			\
+			      : "memory");			\
+	__v;							\
+})
+
+#define csr_write(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrw " __ASM_STR(csr) ", %0"	\
+			      : : "rK" (__v)			\
+			      : "memory");			\
+})
+
+#define csr_read_set(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrrs %0, " __ASM_STR(csr) ", %1"\
+			      : "=r" (__v) : "rK" (__v)		\
+			      : "memory");			\
+	__v;							\
+})
+
+#define csr_set(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrs " __ASM_STR(csr) ", %0"	\
+			      : : "rK" (__v)			\
+			      : "memory");			\
+})
+
+#define csr_read_clear(csr, val)				\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrrc %0, " __ASM_STR(csr) ", %1"\
+			      : "=r" (__v) : "rK" (__v)		\
+			      : "memory");			\
+	__v;							\
+})
+
+#define csr_clear(csr, val)					\
+({								\
+	unsigned long __v = (unsigned long)(val);		\
+	__asm__ __volatile__ ("csrc " __ASM_STR(csr) ", %0"	\
+			      : : "rK" (__v)			\
+			      : "memory");			\
+})
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* _ASM_RISCV_CSR_H */
-- 
2.34.1



From fancer.lancer at gmail.com  Tue Dec 12 01:20:15 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue, 12 Dec 2023 12:20:15 +0300
Subject: [PATCH net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <20231211145944.0be51404@kernel.org>
References: <CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com>
 <zx7tfojtnzuhcpglkeiwg6ep265xpcb5lmz6fgjjugc2tue6qe@cmuqtneujsvb>
 <20231211145944.0be51404@kernel.org>
Message-ID: <edfg5hbcysvah5lnxoeygjn3qz2243c6o5ilt4uyeggegu5wzd@t2ngy4xikpio>

On Mon, Dec 11, 2023 at 02:59:44PM -0800, Jakub Kicinski wrote:
> On Mon, 11 Dec 2023 14:14:00 +0300 Serge Semin wrote:
> > Although in this case AFAICS the implementation is simpler and the
> > only difference is in the CSR offset and the frame preemption residue
> > queue ID setting. All of that can be easily solved in the same way as
> > it was done for EST (see the link above).
> > 
> > Jakub, what do you think?
> 
> Yup, less code duplication would be great. Highest prio, tho, is to
> focus on Vladimir's comment around this driver seemingly implementing
> FPE but not using the common ethtool APIs to configure it, yet :(

Fully agree. If that required to refactor the currently implemented
handshaking algo (looking not that safe and clumsy a bit), it would
have been even better. Although I guess refactoring the code
duplication could be done as a preparation patch anyway or as a patch
which would convert the feature-specific callbacks to be suitable for
the 802.3 MAC Merge layer.

-Serge(y)


From haibo1.xu at intel.com  Tue Dec 12 01:31:14 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:14 +0800
Subject: [PATCH v4 05/11] tools: riscv: Add header file vdso/processor.h
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <7b633cc441f5133608597463301fef122f5174d3.1702371136.git.haibo1.xu@intel.com>

Borrow the cpu_relax() definitions from kernel's
arch/riscv/include/asm/vdso/processor.h to tools/ for riscv.

Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
---
 tools/arch/riscv/include/asm/vdso/processor.h | 32 +++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 tools/arch/riscv/include/asm/vdso/processor.h

diff --git a/tools/arch/riscv/include/asm/vdso/processor.h b/tools/arch/riscv/include/asm/vdso/processor.h
new file mode 100644
index 000000000000..662aca039848
--- /dev/null
+++ b/tools/arch/riscv/include/asm/vdso/processor.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_VDSO_PROCESSOR_H
+#define __ASM_VDSO_PROCESSOR_H
+
+#ifndef __ASSEMBLY__
+
+#include <asm-generic/barrier.h>
+
+static inline void cpu_relax(void)
+{
+#ifdef __riscv_muldiv
+	int dummy;
+	/* In lieu of a halt instruction, induce a long-latency stall. */
+	__asm__ __volatile__ ("div %0, %0, zero" : "=r" (dummy));
+#endif
+
+#ifdef CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE
+	/*
+	 * Reduce instruction retirement.
+	 * This assumes the PC changes.
+	 */
+	__asm__ __volatile__ ("pause");
+#else
+	/* Encoding of the pause instruction */
+	__asm__ __volatile__ (".4byte 0x100000F");
+#endif
+	barrier();
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_VDSO_PROCESSOR_H */
-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:15 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:15 +0800
Subject: [PATCH v4 06/11] KVM: riscv: selftests: Switch to use macro from csr.h
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <5f5f837cd052587f1d49f81a2c4dc58a5330fe47.1702371136.git.haibo1.xu@intel.com>

Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
---
 tools/testing/selftests/kvm/include/riscv/processor.h | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/kvm/include/riscv/processor.h b/tools/testing/selftests/kvm/include/riscv/processor.h
index 5b62a3d2aa9b..6f9e1e5e466d 100644
--- a/tools/testing/selftests/kvm/include/riscv/processor.h
+++ b/tools/testing/selftests/kvm/include/riscv/processor.h
@@ -7,8 +7,9 @@
 #ifndef SELFTEST_KVM_PROCESSOR_H
 #define SELFTEST_KVM_PROCESSOR_H
 
-#include "kvm_util.h"
 #include <linux/stringify.h>
+#include <asm/csr.h>
+#include "kvm_util.h"
 
 static inline uint64_t __kvm_reg_id(uint64_t type, uint64_t idx,
 				    uint64_t  size)
@@ -95,13 +96,6 @@ static inline uint64_t __kvm_reg_id(uint64_t type, uint64_t idx,
 #define PGTBL_PAGE_SIZE				PGTBL_L0_BLOCK_SIZE
 #define PGTBL_PAGE_SIZE_SHIFT			PGTBL_L0_BLOCK_SHIFT
 
-#define SATP_PPN				_AC(0x00000FFFFFFFFFFF, UL)
-#define SATP_MODE_39				_AC(0x8000000000000000, UL)
-#define SATP_MODE_48				_AC(0x9000000000000000, UL)
-#define SATP_ASID_BITS				16
-#define SATP_ASID_SHIFT				44
-#define SATP_ASID_MASK				_AC(0xFFFF, UL)
-
 #define SBI_EXT_EXPERIMENTAL_START		0x08000000
 #define SBI_EXT_EXPERIMENTAL_END		0x08FFFFFF
 
-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:16 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:16 +0800
Subject: [PATCH v4 07/11] KVM: riscv: selftests: Add exception handling support
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <2e0db86f5256578df9a5ccf3e641041081c98a73.1702371136.git.haibo1.xu@intel.com>

Add the infrastructure for guest exception handling in riscv selftests.
Customized handlers can be enabled by vm_install_exception_handler(vector)
or vm_install_interrupt_handler().

The code is inspired from that of x86/arm64.

Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
---
 tools/testing/selftests/kvm/Makefile          |   1 +
 .../selftests/kvm/include/riscv/processor.h   |  43 ++++++++
 .../selftests/kvm/lib/riscv/handlers.S        | 101 ++++++++++++++++++
 .../selftests/kvm/lib/riscv/processor.c       |  69 ++++++++++++
 4 files changed, 214 insertions(+)
 create mode 100644 tools/testing/selftests/kvm/lib/riscv/handlers.S

diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index bb03e278a163..671224c4b9e0 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -63,6 +63,7 @@ LIBKVM_s390x += lib/s390x/diag318_test_handler.c
 LIBKVM_s390x += lib/s390x/processor.c
 LIBKVM_s390x += lib/s390x/ucall.c
 
+LIBKVM_riscv += lib/riscv/handlers.S
 LIBKVM_riscv += lib/riscv/processor.c
 LIBKVM_riscv += lib/riscv/ucall.c
 
diff --git a/tools/testing/selftests/kvm/include/riscv/processor.h b/tools/testing/selftests/kvm/include/riscv/processor.h
index 6f9e1e5e466d..b68b1b731a34 100644
--- a/tools/testing/selftests/kvm/include/riscv/processor.h
+++ b/tools/testing/selftests/kvm/include/riscv/processor.h
@@ -42,6 +42,49 @@ static inline uint64_t __kvm_reg_id(uint64_t type, uint64_t idx,
 #define RISCV_ISA_EXT_REG(idx)	__kvm_reg_id(KVM_REG_RISCV_ISA_EXT, \
 					     idx, KVM_REG_SIZE_ULONG)
 
+struct ex_regs {
+	unsigned long ra;
+	unsigned long sp;
+	unsigned long gp;
+	unsigned long tp;
+	unsigned long t0;
+	unsigned long t1;
+	unsigned long t2;
+	unsigned long s0;
+	unsigned long s1;
+	unsigned long a0;
+	unsigned long a1;
+	unsigned long a2;
+	unsigned long a3;
+	unsigned long a4;
+	unsigned long a5;
+	unsigned long a6;
+	unsigned long a7;
+	unsigned long s2;
+	unsigned long s3;
+	unsigned long s4;
+	unsigned long s5;
+	unsigned long s6;
+	unsigned long s7;
+	unsigned long s8;
+	unsigned long s9;
+	unsigned long s10;
+	unsigned long s11;
+	unsigned long t3;
+	unsigned long t4;
+	unsigned long t5;
+	unsigned long t6;
+	unsigned long epc;
+	unsigned long status;
+	unsigned long cause;
+};
+
+#define NR_VECTORS  2
+#define NR_EXCEPTIONS  32
+#define EC_MASK  (NR_EXCEPTIONS - 1)
+
+void vm_install_interrupt_handler(struct kvm_vm *vm, exception_handler_fn handler);
+
 /* L3 index Bit[47:39] */
 #define PGTBL_L3_INDEX_MASK			0x0000FF8000000000ULL
 #define PGTBL_L3_INDEX_SHIFT			39
diff --git a/tools/testing/selftests/kvm/lib/riscv/handlers.S b/tools/testing/selftests/kvm/lib/riscv/handlers.S
new file mode 100644
index 000000000000..aa0abd3f35bb
--- /dev/null
+++ b/tools/testing/selftests/kvm/lib/riscv/handlers.S
@@ -0,0 +1,101 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2023 Intel Corporation
+ */
+
+#ifndef __ASSEMBLY__
+#define __ASSEMBLY__
+#endif
+
+#include <asm/csr.h>
+
+.macro save_context
+	addi  sp, sp, (-8*34)
+	sd    x1, 0(sp)
+	sd    x2, 8(sp)
+	sd    x3, 16(sp)
+	sd    x4, 24(sp)
+	sd    x5, 32(sp)
+	sd    x6, 40(sp)
+	sd    x7, 48(sp)
+	sd    x8, 56(sp)
+	sd    x9, 64(sp)
+	sd    x10, 72(sp)
+	sd    x11, 80(sp)
+	sd    x12, 88(sp)
+	sd    x13, 96(sp)
+	sd    x14, 104(sp)
+	sd    x15, 112(sp)
+	sd    x16, 120(sp)
+	sd    x17, 128(sp)
+	sd    x18, 136(sp)
+	sd    x19, 144(sp)
+	sd    x20, 152(sp)
+	sd    x21, 160(sp)
+	sd    x22, 168(sp)
+	sd    x23, 176(sp)
+	sd    x24, 184(sp)
+	sd    x25, 192(sp)
+	sd    x26, 200(sp)
+	sd    x27, 208(sp)
+	sd    x28, 216(sp)
+	sd    x29, 224(sp)
+	sd    x30, 232(sp)
+	sd    x31, 240(sp)
+	csrr  s0, CSR_SEPC
+	csrr  s1, CSR_SSTATUS
+	csrr  s2, CSR_SCAUSE
+	sd    s0, 248(sp)
+	sd    s1, 256(sp)
+	sd    s2, 264(sp)
+.endm
+
+.macro restore_context
+	ld    s2, 264(sp)
+	ld    s1, 256(sp)
+	ld    s0, 248(sp)
+	csrw  CSR_SCAUSE, s2
+	csrw  CSR_SSTATUS, s1
+	csrw  CSR_SEPC, s0
+	ld    x31, 240(sp)
+	ld    x30, 232(sp)
+	ld    x29, 224(sp)
+	ld    x28, 216(sp)
+	ld    x27, 208(sp)
+	ld    x26, 200(sp)
+	ld    x25, 192(sp)
+	ld    x24, 184(sp)
+	ld    x23, 176(sp)
+	ld    x22, 168(sp)
+	ld    x21, 160(sp)
+	ld    x20, 152(sp)
+	ld    x19, 144(sp)
+	ld    x18, 136(sp)
+	ld    x17, 128(sp)
+	ld    x16, 120(sp)
+	ld    x15, 112(sp)
+	ld    x14, 104(sp)
+	ld    x13, 96(sp)
+	ld    x12, 88(sp)
+	ld    x11, 80(sp)
+	ld    x10, 72(sp)
+	ld    x9, 64(sp)
+	ld    x8, 56(sp)
+	ld    x7, 48(sp)
+	ld    x6, 40(sp)
+	ld    x5, 32(sp)
+	ld    x4, 24(sp)
+	ld    x3, 16(sp)
+	ld    x2, 8(sp)
+	ld    x1, 0(sp)
+	addi  sp, sp, (8*34)
+.endm
+
+.balign 4
+.global exception_vectors
+exception_vectors:
+	save_context
+	move  a0, sp
+	call  route_exception
+	restore_context
+	sret
diff --git a/tools/testing/selftests/kvm/lib/riscv/processor.c b/tools/testing/selftests/kvm/lib/riscv/processor.c
index d146ca71e0c0..efd9ac4b0198 100644
--- a/tools/testing/selftests/kvm/lib/riscv/processor.c
+++ b/tools/testing/selftests/kvm/lib/riscv/processor.c
@@ -13,6 +13,8 @@
 
 #define DEFAULT_RISCV_GUEST_STACK_VADDR_MIN	0xac0000
 
+static vm_vaddr_t exception_handlers;
+
 static uint64_t page_align(struct kvm_vm *vm, uint64_t v)
 {
 	return (v + vm->page_size) & ~(vm->page_size - 1);
@@ -364,6 +366,73 @@ void vcpu_args_set(struct kvm_vcpu *vcpu, unsigned int num, ...)
 	va_end(ap);
 }
 
+void kvm_exit_unexpected_exception(int vector, int ec)
+{
+	ucall(UCALL_UNHANDLED, 2, vector, ec);
+}
+
 void assert_on_unhandled_exception(struct kvm_vcpu *vcpu)
 {
+	struct ucall uc;
+
+	if (get_ucall(vcpu, &uc) == UCALL_UNHANDLED) {
+		TEST_FAIL("Unexpected exception (vector:0x%lx, ec:0x%lx)",
+			uc.args[0], uc.args[1]);
+	}
+}
+
+struct handlers {
+	exception_handler_fn exception_handlers[NR_VECTORS][NR_EXCEPTIONS];
+};
+
+void route_exception(struct ex_regs *regs)
+{
+	struct handlers *handlers = (struct handlers *)exception_handlers;
+	int vector = 0, ec;
+
+	ec = regs->cause & ~CAUSE_IRQ_FLAG;
+	if (ec >= NR_EXCEPTIONS)
+		goto unexpected_exception;
+
+	/* Use the same handler for all the interrupts */
+	if (regs->cause & CAUSE_IRQ_FLAG) {
+		vector = 1;
+		ec = 0;
+	}
+
+	if (handlers && handlers->exception_handlers[vector][ec])
+		return handlers->exception_handlers[vector][ec](regs);
+
+unexpected_exception:
+	return kvm_exit_unexpected_exception(vector, ec);
+}
+
+void vcpu_init_vector_tables(struct kvm_vcpu *vcpu)
+{
+	extern char exception_vectors;
+
+	vcpu_set_reg(vcpu, RISCV_CSR_REG(stvec), (unsigned long)&exception_vectors);
+}
+
+void vm_init_vector_tables(struct kvm_vm *vm)
+{
+	vm->handlers = __vm_vaddr_alloc(vm, sizeof(struct handlers),
+				   vm->page_size, MEM_REGION_DATA);
+
+	*(vm_vaddr_t *)addr_gva2hva(vm, (vm_vaddr_t)(&exception_handlers)) = vm->handlers;
+}
+
+void vm_install_exception_handler(struct kvm_vm *vm, int vector, exception_handler_fn handler)
+{
+	struct handlers *handlers = addr_gva2hva(vm, vm->handlers);
+
+	assert(vector < NR_EXCEPTIONS);
+	handlers->exception_handlers[0][vector] = handler;
+}
+
+void vm_install_interrupt_handler(struct kvm_vm *vm, exception_handler_fn handler)
+{
+	struct handlers *handlers = addr_gva2hva(vm, vm->handlers);
+
+	handlers->exception_handlers[1][0] = handler;
 }
-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:17 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:17 +0800
Subject: [PATCH v4 08/11] KVM: riscv: selftests: Add guest helper to get vcpu id
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <02f6c9ccaaeb4ceb67137863e0317f62cef62496.1702371136.git.haibo1.xu@intel.com>

Add guest_get_vcpuid() helper to simplify accessing to per-cpu
private data. The sscratch CSR was used to store the vcpu id.

Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
---
 tools/testing/selftests/kvm/include/aarch64/processor.h | 4 ----
 tools/testing/selftests/kvm/include/kvm_util_base.h     | 9 +++++++++
 tools/testing/selftests/kvm/lib/riscv/processor.c       | 8 ++++++++
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/kvm/include/aarch64/processor.h b/tools/testing/selftests/kvm/include/aarch64/processor.h
index c42d683102c7..16ae0ac01879 100644
--- a/tools/testing/selftests/kvm/include/aarch64/processor.h
+++ b/tools/testing/selftests/kvm/include/aarch64/processor.h
@@ -226,8 +226,4 @@ void smccc_smc(uint32_t function_id, uint64_t arg0, uint64_t arg1,
 	       uint64_t arg2, uint64_t arg3, uint64_t arg4, uint64_t arg5,
 	       uint64_t arg6, struct arm_smccc_res *res);
 
-
-
-uint32_t guest_get_vcpuid(void);
-
 #endif /* SELFTEST_KVM_PROCESSOR_H */
diff --git a/tools/testing/selftests/kvm/include/kvm_util_base.h b/tools/testing/selftests/kvm/include/kvm_util_base.h
index a18db6a7b3cf..666438113d22 100644
--- a/tools/testing/selftests/kvm/include/kvm_util_base.h
+++ b/tools/testing/selftests/kvm/include/kvm_util_base.h
@@ -932,4 +932,13 @@ void kvm_selftest_arch_init(void);
 
 void kvm_arch_vm_post_create(struct kvm_vm *vm);
 
+void vm_init_vector_tables(struct kvm_vm *vm);
+void vcpu_init_vector_tables(struct kvm_vcpu *vcpu);
+
+struct ex_regs;
+typedef void(*exception_handler_fn)(struct ex_regs *);
+void vm_install_exception_handler(struct kvm_vm *vm, int vector, exception_handler_fn handler);
+
+uint32_t guest_get_vcpuid(void);
+
 #endif /* SELFTEST_KVM_UTIL_BASE_H */
diff --git a/tools/testing/selftests/kvm/lib/riscv/processor.c b/tools/testing/selftests/kvm/lib/riscv/processor.c
index efd9ac4b0198..39a1e9902dec 100644
--- a/tools/testing/selftests/kvm/lib/riscv/processor.c
+++ b/tools/testing/selftests/kvm/lib/riscv/processor.c
@@ -316,6 +316,9 @@ struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, uint32_t vcpu_id,
 	vcpu_set_reg(vcpu, RISCV_CORE_REG(regs.sp), stack_vaddr + stack_size);
 	vcpu_set_reg(vcpu, RISCV_CORE_REG(regs.pc), (unsigned long)guest_code);
 
+	/* Setup sscratch for guest_get_vcpuid() */
+	vcpu_set_reg(vcpu, RISCV_CSR_REG(sscratch), vcpu_id);
+
 	/* Setup default exception vector of guest */
 	vcpu_set_reg(vcpu, RISCV_CSR_REG(stvec), (unsigned long)guest_unexp_trap);
 
@@ -436,3 +439,8 @@ void vm_install_interrupt_handler(struct kvm_vm *vm, exception_handler_fn handle
 
 	handlers->exception_handlers[1][0] = handler;
 }
+
+uint32_t guest_get_vcpuid(void)
+{
+	return csr_read(CSR_SSCRATCH);
+}
-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:18 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:18 +0800
Subject: [PATCH v4 09/11] KVM: riscv: selftests: Change vcpu_has_ext to a common function
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <3972ba512474a0a3c492877db82d19e988d7095e.1702371136.git.haibo1.xu@intel.com>

Move vcpu_has_ext to the processor.c and rename it to __vcpu_has_ext
so that other test cases can use it for vCPU extension check.

Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
---
 tools/testing/selftests/kvm/include/riscv/processor.h |  2 ++
 tools/testing/selftests/kvm/lib/riscv/processor.c     | 10 ++++++++++
 tools/testing/selftests/kvm/riscv/get-reg-list.c      | 11 +----------
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/tools/testing/selftests/kvm/include/riscv/processor.h b/tools/testing/selftests/kvm/include/riscv/processor.h
index b68b1b731a34..bd27e1c67579 100644
--- a/tools/testing/selftests/kvm/include/riscv/processor.h
+++ b/tools/testing/selftests/kvm/include/riscv/processor.h
@@ -42,6 +42,8 @@ static inline uint64_t __kvm_reg_id(uint64_t type, uint64_t idx,
 #define RISCV_ISA_EXT_REG(idx)	__kvm_reg_id(KVM_REG_RISCV_ISA_EXT, \
 					     idx, KVM_REG_SIZE_ULONG)
 
+bool __vcpu_has_ext(struct kvm_vcpu *vcpu, int ext);
+
 struct ex_regs {
 	unsigned long ra;
 	unsigned long sp;
diff --git a/tools/testing/selftests/kvm/lib/riscv/processor.c b/tools/testing/selftests/kvm/lib/riscv/processor.c
index 39a1e9902dec..dad73ce18164 100644
--- a/tools/testing/selftests/kvm/lib/riscv/processor.c
+++ b/tools/testing/selftests/kvm/lib/riscv/processor.c
@@ -15,6 +15,16 @@
 
 static vm_vaddr_t exception_handlers;
 
+bool __vcpu_has_ext(struct kvm_vcpu *vcpu, int ext)
+{
+	unsigned long value = 0;
+	int ret;
+
+	ret = __vcpu_get_reg(vcpu, RISCV_ISA_EXT_REG(ext), &value);
+
+	return !ret && !!value;
+}
+
 static uint64_t page_align(struct kvm_vm *vm, uint64_t v)
 {
 	return (v + vm->page_size) & ~(vm->page_size - 1);
diff --git a/tools/testing/selftests/kvm/riscv/get-reg-list.c b/tools/testing/selftests/kvm/riscv/get-reg-list.c
index 6bedaea95395..5da230e86728 100644
--- a/tools/testing/selftests/kvm/riscv/get-reg-list.c
+++ b/tools/testing/selftests/kvm/riscv/get-reg-list.c
@@ -75,15 +75,6 @@ bool check_reject_set(int err)
 	return err == EINVAL;
 }
 
-static inline bool vcpu_has_ext(struct kvm_vcpu *vcpu, int ext)
-{
-	int ret;
-	unsigned long value;
-
-	ret = __vcpu_get_reg(vcpu, RISCV_ISA_EXT_REG(ext), &value);
-	return (ret) ? false : !!value;
-}
-
 void finalize_vcpu(struct kvm_vcpu *vcpu, struct vcpu_reg_list *c)
 {
 	unsigned long isa_ext_state[KVM_RISCV_ISA_EXT_MAX] = { 0 };
@@ -111,7 +102,7 @@ void finalize_vcpu(struct kvm_vcpu *vcpu, struct vcpu_reg_list *c)
 		__vcpu_set_reg(vcpu, RISCV_ISA_EXT_REG(s->feature), 1);
 
 		/* Double check whether the desired extension was enabled */
-		__TEST_REQUIRE(vcpu_has_ext(vcpu, s->feature),
+		__TEST_REQUIRE(__vcpu_has_ext(vcpu, s->feature),
 			       "%s not available, skipping tests\n", s->name);
 	}
 }
-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:19 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:19 +0800
Subject: [PATCH v4 10/11] KVM: riscv: selftests: Add sstc timer test
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <3bb7d5ae5a1a016e970faa0759c47214c9391b19.1702371136.git.haibo1.xu@intel.com>

Add a KVM selftests to validate the Sstc timer functionality.
The test was ported from arm64 arch timer test.

Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
---
 tools/testing/selftests/kvm/Makefile          |   1 +
 .../selftests/kvm/aarch64/arch_timer.c        |  12 +-
 tools/testing/selftests/kvm/arch_timer.c      |  10 +-
 .../selftests/kvm/include/riscv/arch_timer.h  |  71 ++++++++++++
 .../selftests/kvm/include/riscv/processor.h   |  10 ++
 .../selftests/kvm/include/timer_test.h        |   5 +-
 .../testing/selftests/kvm/riscv/arch_timer.c  | 107 ++++++++++++++++++
 7 files changed, 206 insertions(+), 10 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/include/riscv/arch_timer.h
 create mode 100644 tools/testing/selftests/kvm/riscv/arch_timer.c

diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index 671224c4b9e0..eb8071aba80a 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -193,6 +193,7 @@ TEST_GEN_PROGS_s390x += rseq_test
 TEST_GEN_PROGS_s390x += set_memory_region_test
 TEST_GEN_PROGS_s390x += kvm_binary_stats_test
 
+TEST_GEN_PROGS_riscv += arch_timer
 TEST_GEN_PROGS_riscv += demand_paging_test
 TEST_GEN_PROGS_riscv += dirty_log_test
 TEST_GEN_PROGS_riscv += guest_print_test
diff --git a/tools/testing/selftests/kvm/aarch64/arch_timer.c b/tools/testing/selftests/kvm/aarch64/arch_timer.c
index 6fb47ba07e5b..4b421d421c3f 100644
--- a/tools/testing/selftests/kvm/aarch64/arch_timer.c
+++ b/tools/testing/selftests/kvm/aarch64/arch_timer.c
@@ -190,10 +190,14 @@ struct kvm_vm *test_vm_create(void)
 	vm_init_descriptor_tables(vm);
 	vm_install_exception_handler(vm, VECTOR_IRQ_CURRENT, guest_irq_handler);
 
-	if (!test_args.offset.reserved) {
-		if (kvm_has_cap(KVM_CAP_COUNTER_OFFSET))
-			vm_ioctl(vm, KVM_ARM_SET_COUNTER_OFFSET, &test_args.offset);
-		else
+	if (!test_args.reserved) {
+		if (kvm_has_cap(KVM_CAP_COUNTER_OFFSET)) {
+			struct kvm_arm_counter_offset offset = {
+				.counter_offset = test_args.counter_offset,
+				.reserved = 0,
+			};
+			vm_ioctl(vm, KVM_ARM_SET_COUNTER_OFFSET, &offset);
+		} else
 			TEST_FAIL("no support for global offset\n");
 	}
 
diff --git a/tools/testing/selftests/kvm/arch_timer.c b/tools/testing/selftests/kvm/arch_timer.c
index 6e442dbcfc8b..60963fce16f2 100644
--- a/tools/testing/selftests/kvm/arch_timer.c
+++ b/tools/testing/selftests/kvm/arch_timer.c
@@ -34,7 +34,7 @@ struct test_args test_args = {
 	.nr_iter = NR_TEST_ITERS_DEF,
 	.timer_period_ms = TIMER_TEST_PERIOD_MS_DEF,
 	.migration_freq_ms = TIMER_TEST_MIGRATION_FREQ_MS,
-	.offset = { .reserved = 1 },
+	.reserved = 1,
 };
 
 struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
@@ -73,6 +73,8 @@ static void *test_vcpu_run(void *arg)
 		TEST_FAIL("Unexpected guest exit\n");
 	}
 
+	pr_info("PASS(vCPU-%d).\n", vcpu_idx);
+
 	return NULL;
 }
 
@@ -187,7 +189,7 @@ static void test_print_help(char *name)
 		TIMER_TEST_PERIOD_MS_DEF);
 	pr_info("\t-m: Frequency (in ms) of vCPUs to migrate to different pCPU. 0 to turn off (default: %u)\n",
 		TIMER_TEST_MIGRATION_FREQ_MS);
-	pr_info("\t-o: Counter offset (in counter cycles, default: 0)\n");
+	pr_info("\t-o: Counter offset (in counter cycles, default: 0) [aarch64-only]\n");
 	pr_info("\t-h: print this help screen\n");
 }
 
@@ -215,8 +217,8 @@ static bool parse_args(int argc, char *argv[])
 			test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
 			break;
 		case 'o':
-			test_args.offset.counter_offset = strtol(optarg, NULL, 0);
-			test_args.offset.reserved = 0;
+			test_args.counter_offset = strtol(optarg, NULL, 0);
+			test_args.reserved = 0;
 			break;
 		case 'h':
 		default:
diff --git a/tools/testing/selftests/kvm/include/riscv/arch_timer.h b/tools/testing/selftests/kvm/include/riscv/arch_timer.h
new file mode 100644
index 000000000000..23d4a0e0e1cd
--- /dev/null
+++ b/tools/testing/selftests/kvm/include/riscv/arch_timer.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * RISC-V Arch Timer(sstc) specific interface
+ *
+ * Copyright (c) 2023 Intel Corporation
+ */
+
+#ifndef SELFTEST_KVM_ARCH_TIMER_H
+#define SELFTEST_KVM_ARCH_TIMER_H
+
+#include <asm/csr.h>
+#include <asm/vdso/processor.h>
+
+static unsigned long timer_freq;
+
+#define msec_to_cycles(msec)	\
+	((timer_freq) * (uint64_t)(msec) / 1000)
+
+#define usec_to_cycles(usec)	\
+	((timer_freq) * (uint64_t)(usec) / 1000000)
+
+#define cycles_to_usec(cycles) \
+	((uint64_t)(cycles) * 1000000 / (timer_freq))
+
+static inline uint64_t timer_get_cycles(void)
+{
+	return csr_read(CSR_TIME);
+}
+
+static inline void timer_set_cmp(uint64_t cval)
+{
+	csr_write(CSR_STIMECMP, cval);
+}
+
+static inline uint64_t timer_get_cmp(void)
+{
+	return csr_read(CSR_STIMECMP);
+}
+
+static inline void timer_irq_enable(void)
+{
+	csr_set(CSR_SIE, IE_TIE);
+}
+
+static inline void timer_irq_disable(void)
+{
+	csr_clear(CSR_SIE, IE_TIE);
+}
+
+static inline void timer_set_next_cmp_ms(uint32_t msec)
+{
+	uint64_t now_ct = timer_get_cycles();
+	uint64_t next_ct = now_ct + msec_to_cycles(msec);
+
+	timer_set_cmp(next_ct);
+}
+
+static inline void __delay(uint64_t cycles)
+{
+	uint64_t start = timer_get_cycles();
+
+	while ((timer_get_cycles() - start) < cycles)
+		cpu_relax();
+}
+
+static inline void udelay(unsigned long usec)
+{
+	__delay(usec_to_cycles(usec));
+}
+
+#endif /* SELFTEST_KVM_ARCH_TIMER_H */
diff --git a/tools/testing/selftests/kvm/include/riscv/processor.h b/tools/testing/selftests/kvm/include/riscv/processor.h
index bd27e1c67579..3e7f6b369a5e 100644
--- a/tools/testing/selftests/kvm/include/riscv/processor.h
+++ b/tools/testing/selftests/kvm/include/riscv/processor.h
@@ -158,4 +158,14 @@ struct sbiret sbi_ecall(int ext, int fid, unsigned long arg0,
 			unsigned long arg3, unsigned long arg4,
 			unsigned long arg5);
 
+static inline void local_irq_enable(void)
+{
+	csr_set(CSR_SSTATUS, SR_SIE);
+}
+
+static inline void local_irq_disable(void)
+{
+	csr_clear(CSR_SSTATUS, SR_SIE);
+}
+
 #endif /* SELFTEST_KVM_PROCESSOR_H */
diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
index 2234c513b510..968257b893a7 100644
--- a/tools/testing/selftests/kvm/include/timer_test.h
+++ b/tools/testing/selftests/kvm/include/timer_test.h
@@ -22,8 +22,9 @@ struct test_args {
 	int nr_iter;
 	int timer_period_ms;
 	int migration_freq_ms;
-	/* TODO: Change arm specific type to a common one */
-	struct kvm_arm_counter_offset offset;
+	/* Members of struct kvm_arm_counter_offset */
+	uint64_t counter_offset;
+	uint64_t reserved;
 };
 
 /* Shared variables between host and guest */
diff --git a/tools/testing/selftests/kvm/riscv/arch_timer.c b/tools/testing/selftests/kvm/riscv/arch_timer.c
new file mode 100644
index 000000000000..13bf184d1ff5
--- /dev/null
+++ b/tools/testing/selftests/kvm/riscv/arch_timer.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * arch_timer.c - Tests the riscv64 sstc timer IRQ functionality
+ *
+ * The test validates the sstc timer IRQs using vstimecmp registers.
+ * It's ported from the aarch64 arch_timer test.
+ *
+ * Copyright (c) 2023, Intel Corporation.
+ */
+
+#define _GNU_SOURCE
+
+#include "arch_timer.h"
+#include "kvm_util.h"
+#include "processor.h"
+#include "timer_test.h"
+
+static int timer_irq = IRQ_S_TIMER;
+
+static void guest_irq_handler(struct ex_regs *regs)
+{
+	uint64_t xcnt, xcnt_diff_us, cmp;
+	unsigned int intid = regs->cause & ~CAUSE_IRQ_FLAG;
+	uint32_t cpu = guest_get_vcpuid();
+	struct test_vcpu_shared_data *shared_data = &vcpu_shared_data[cpu];
+
+	timer_irq_disable();
+
+	xcnt = timer_get_cycles();
+	cmp = timer_get_cmp();
+	xcnt_diff_us = cycles_to_usec(xcnt - shared_data->xcnt);
+
+	/* Make sure we are dealing with the correct timer IRQ */
+	GUEST_ASSERT_EQ(intid, timer_irq);
+
+	__GUEST_ASSERT(xcnt >= cmp,
+			"xcnt = 0x%llx, cmp = 0x%llx, xcnt_diff_us = 0x%llx",
+			xcnt, cmp, xcnt_diff_us);
+
+	WRITE_ONCE(shared_data->nr_iter, shared_data->nr_iter + 1);
+}
+
+static void guest_run(struct test_vcpu_shared_data *shared_data)
+{
+	uint32_t irq_iter, config_iter;
+
+	shared_data->nr_iter = 0;
+	shared_data->guest_stage = 0;
+
+	for (config_iter = 0; config_iter < test_args.nr_iter; config_iter++) {
+		/* Setup the next interrupt */
+		timer_set_next_cmp_ms(test_args.timer_period_ms);
+		shared_data->xcnt = timer_get_cycles();
+		timer_irq_enable();
+
+		/* Setup a timeout for the interrupt to arrive */
+		udelay(msecs_to_usecs(test_args.timer_period_ms) +
+			TIMER_TEST_ERR_MARGIN_US);
+
+		irq_iter = READ_ONCE(shared_data->nr_iter);
+		GUEST_ASSERT_EQ(config_iter + 1, irq_iter);
+	}
+}
+
+static void guest_code(void)
+{
+	uint32_t cpu = guest_get_vcpuid();
+	struct test_vcpu_shared_data *shared_data = &vcpu_shared_data[cpu];
+
+	timer_irq_disable();
+	local_irq_enable();
+
+	guest_run(shared_data);
+
+	GUEST_DONE();
+}
+
+struct kvm_vm *test_vm_create(void)
+{
+	struct kvm_vm *vm;
+	int nr_vcpus = test_args.nr_vcpus;
+
+	vm = vm_create_with_vcpus(nr_vcpus, guest_code, vcpus);
+	__TEST_REQUIRE(__vcpu_has_ext(vcpus[0], KVM_RISCV_ISA_EXT_SSTC),
+				   "SSTC not available, skipping test\n");
+
+	vm_init_vector_tables(vm);
+	vm_install_interrupt_handler(vm, guest_irq_handler);
+
+	for (int i = 0; i < nr_vcpus; i++)
+		vcpu_init_vector_tables(vcpus[i]);
+
+	/* Initialize guest timer frequency. */
+	vcpu_get_reg(vcpus[0], RISCV_TIMER_REG(frequency), &timer_freq);
+	sync_global_to_guest(vm, timer_freq);
+	pr_debug("timer_freq: %lu\n", timer_freq);
+
+	/* Make all the test's cmdline args visible to the guest */
+	sync_global_to_guest(vm, test_args);
+
+	return vm;
+}
+
+void test_vm_cleanup(struct kvm_vm *vm)
+{
+	kvm_vm_free(vm);
+}
-- 
2.34.1



From haibo1.xu at intel.com  Tue Dec 12 01:31:20 2023
From: haibo1.xu at intel.com (Haibo Xu)
Date: Tue, 12 Dec 2023 17:31:20 +0800
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us in arch timer test
In-Reply-To: <cover.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
Message-ID: <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>

There are intermittent failures occured when stressing the
arch-timer test in a Qemu VM:

 Guest assert failed,  vcpu 0; stage; 4; iter: 3
 ==== Test Assertion Failure ====
   aarch64/arch_timer.c:196: config_iter + 1 == irq_iter
   pid=4048 tid=4049 errno=4 - Interrupted system call
      1  0x000000000040253b: test_vcpu_run at arch_timer.c:248
      2  0x0000ffffb60dd5c7: ?? ??:0
      3  0x0000ffffb6145d1b: ?? ??:0
   0x3 != 0x2 (config_iter + 1 != irq_iter)e

Further test and debug show that the timeout for an interrupt
to arrive do have random high fluctuation, espectially when
testing in an virtual environment.

To alleviate this issue, just expose the timeout value as user
configurable and print some hint message to increase the value
when hitting the failure..

Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
---
 .../selftests/kvm/aarch64/arch_timer.c        |  8 +++++--
 tools/testing/selftests/kvm/arch_timer.c      | 22 +++++++++++++------
 .../selftests/kvm/include/timer_test.h        |  1 +
 .../testing/selftests/kvm/riscv/arch_timer.c  |  8 +++++--
 4 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/tools/testing/selftests/kvm/aarch64/arch_timer.c b/tools/testing/selftests/kvm/aarch64/arch_timer.c
index 4b421d421c3f..139eecbf77e7 100644
--- a/tools/testing/selftests/kvm/aarch64/arch_timer.c
+++ b/tools/testing/selftests/kvm/aarch64/arch_timer.c
@@ -131,10 +131,14 @@ static void guest_run_stage(struct test_vcpu_shared_data *shared_data,
 
 		/* Setup a timeout for the interrupt to arrive */
 		udelay(msecs_to_usecs(test_args.timer_period_ms) +
-			TIMER_TEST_ERR_MARGIN_US);
+			test_args.timer_err_margin_us);
 
 		irq_iter = READ_ONCE(shared_data->nr_iter);
-		GUEST_ASSERT_EQ(config_iter + 1, irq_iter);
+		__GUEST_ASSERT(config_iter + 1 == irq_iter,
+			"config_iter + 1 = 0x%lx, irq_iter = 0x%lx.\n"
+			"  Guest timer interrupt was not trigged within the specified\n"
+			"  interval, try to increase the error margin by [-e] option.\n",
+			config_iter + 1, irq_iter);
 	}
 }
 
diff --git a/tools/testing/selftests/kvm/arch_timer.c b/tools/testing/selftests/kvm/arch_timer.c
index 60963fce16f2..5050022fd345 100644
--- a/tools/testing/selftests/kvm/arch_timer.c
+++ b/tools/testing/selftests/kvm/arch_timer.c
@@ -5,16 +5,17 @@
  * The guest's main thread configures the timer interrupt and waits
  * for it to fire, with a timeout equal to the timer period.
  * It asserts that the timeout doesn't exceed the timer period plus
- * an error margin of 100us.
+ * an user configurable error margin(default to 100us).
  *
  * On the other hand, upon receipt of an interrupt, the guest's interrupt
  * handler validates the interrupt by checking if the architectural state
  * is in compliance with the specifications.
  *
  * The test provides command-line options to configure the timer's
- * period (-p), number of vCPUs (-n), and iterations per stage (-i).
- * To stress-test the timer stack even more, an option to migrate the
- * vCPUs across pCPUs (-m), at a particular rate, is also provided.
+ * period (-p), number of vCPUs (-n), iterations per stage (-i), and timer
+ * interrupt arrival error margin (-e). To stress-test the timer stack even
+ * more, an option to migrate the vCPUs across pCPUs (-m), at a particular
+ * rate, is also provided.
  *
  * Copyright (c) 2021, Google LLC.
  */
@@ -34,6 +35,7 @@ struct test_args test_args = {
 	.nr_iter = NR_TEST_ITERS_DEF,
 	.timer_period_ms = TIMER_TEST_PERIOD_MS_DEF,
 	.migration_freq_ms = TIMER_TEST_MIGRATION_FREQ_MS,
+	.timer_err_margin_us = TIMER_TEST_ERR_MARGIN_US,
 	.reserved = 1,
 };
 
@@ -179,8 +181,9 @@ static void test_run(struct kvm_vm *vm)
 
 static void test_print_help(char *name)
 {
-	pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n",
-		name);
+	pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n"
+	        "\t\t    [-m migration_freq_ms] [-o counter_offset]\n"
+	        "\t\t    [-e timer_err_margin_us]\n", name);
 	pr_info("\t-n: Number of vCPUs to configure (default: %u; max: %u)\n",
 		NR_VCPUS_DEF, KVM_MAX_VCPUS);
 	pr_info("\t-i: Number of iterations per stage (default: %u)\n",
@@ -190,6 +193,8 @@ static void test_print_help(char *name)
 	pr_info("\t-m: Frequency (in ms) of vCPUs to migrate to different pCPU. 0 to turn off (default: %u)\n",
 		TIMER_TEST_MIGRATION_FREQ_MS);
 	pr_info("\t-o: Counter offset (in counter cycles, default: 0) [aarch64-only]\n");
+	pr_info("\t-e: Interrupt arrival error margin(in us) of the guest timer (default: %u)\n",
+		TIMER_TEST_ERR_MARGIN_US);
 	pr_info("\t-h: print this help screen\n");
 }
 
@@ -197,7 +202,7 @@ static bool parse_args(int argc, char *argv[])
 {
 	int opt;
 
-	while ((opt = getopt(argc, argv, "hn:i:p:m:o:")) != -1) {
+	while ((opt = getopt(argc, argv, "hn:i:p:m:o:e:")) != -1) {
 		switch (opt) {
 		case 'n':
 			test_args.nr_vcpus = atoi_positive("Number of vCPUs", optarg);
@@ -216,6 +221,9 @@ static bool parse_args(int argc, char *argv[])
 		case 'm':
 			test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
 			break;
+		case 'e':
+			test_args.timer_err_margin_us = atoi_non_negative("Error Margin", optarg);
+			break;
 		case 'o':
 			test_args.counter_offset = strtol(optarg, NULL, 0);
 			test_args.reserved = 0;
diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
index 968257b893a7..b1d405e7157d 100644
--- a/tools/testing/selftests/kvm/include/timer_test.h
+++ b/tools/testing/selftests/kvm/include/timer_test.h
@@ -22,6 +22,7 @@ struct test_args {
 	int nr_iter;
 	int timer_period_ms;
 	int migration_freq_ms;
+	int timer_err_margin_us;
 	/* Members of struct kvm_arm_counter_offset */
 	uint64_t counter_offset;
 	uint64_t reserved;
diff --git a/tools/testing/selftests/kvm/riscv/arch_timer.c b/tools/testing/selftests/kvm/riscv/arch_timer.c
index 13bf184d1ff5..45a139dc7ce3 100644
--- a/tools/testing/selftests/kvm/riscv/arch_timer.c
+++ b/tools/testing/selftests/kvm/riscv/arch_timer.c
@@ -55,10 +55,14 @@ static void guest_run(struct test_vcpu_shared_data *shared_data)
 
 		/* Setup a timeout for the interrupt to arrive */
 		udelay(msecs_to_usecs(test_args.timer_period_ms) +
-			TIMER_TEST_ERR_MARGIN_US);
+			test_args.timer_err_margin_us);
 
 		irq_iter = READ_ONCE(shared_data->nr_iter);
-		GUEST_ASSERT_EQ(config_iter + 1, irq_iter);
+		__GUEST_ASSERT(config_iter + 1 == irq_iter,
+			"config_iter + 1 = 0x%lx, irq_iter = 0x%lx.\n"
+			"  Guest timer interrupt was not trigged within the specified\n"
+			"  interval, try to increase the error margin by [-e] option.\n",
+			config_iter + 1, irq_iter);
 	}
 }
 
-- 
2.34.1



From quic_snehshah at quicinc.com  Tue Dec 12 01:22:08 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Tue, 12 Dec 2023 14:52:08 +0530
Subject: [PATCH net v4] net: stmmac: dwmac-qcom-ethqos: Fix drops in 10M SGMII RX
Message-ID: <20231212092208.22393-1-quic_snehshah@quicinc.com>

In 10M SGMII mode all the packets are being dropped due to wrong Rx clock.
SGMII 10MBPS mode needs RX clock divider programmed to avoid drops in Rx.
Update configure SGMII function with Rx clk divider programming.

Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
Tested-by: Andrew Halaney <ahalaney at redhat.com>
Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
---
v4 changelog:
- Updated commit message to add more details on why 10M SGMII Rx is failing
- Added a macro for Rx clock divider value
v3 changelog:
- Added comment to explain why MAC needs to be reconfigured for SGMII
v2 changelog:
- Use FIELD_PREP to prepare bifield values in place of GENMASK
- Add fixes tag
---
 .../net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index d3bf42d0fceb..31631e3f89d0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -34,6 +34,7 @@
 #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
 #define RGMII_CONFIG_PROG_SWAP			BIT(1)
 #define RGMII_CONFIG_DDR_MODE			BIT(0)
+#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)
 
 /* SDCC_HC_REG_DLL_CONFIG fields */
 #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
@@ -78,6 +79,8 @@
 #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
 #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
 
+#define SGMII_10M_RX_CLK_DVDR			0x31
+
 struct ethqos_emac_por {
 	unsigned int offset;
 	unsigned int value;
@@ -598,6 +601,9 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
 	return 0;
 }
 
+/* On interface toggle MAC registers gets reset.
+ * Configure MAC block for SGMII on ethernet phy link up
+ */
 static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
 {
 	int val;
@@ -617,6 +623,10 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
 	case SPEED_10:
 		val |= ETHQOS_MAC_CTRL_PORT_SEL;
 		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
+		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
+			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR,
+					 SGMII_10M_RX_CLK_DVDR),
+			      RGMII_IO_MACRO_CONFIG);
 		break;
 	}
 
-- 
2.17.1



From will at kernel.org  Tue Dec 12 01:22:21 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 09:22:21 +0000
Subject: [PATCH v3 2/4] perf/bpf: Remove unneeded
 uses_default_overflow_handler.
In-Reply-To: <20231211045543.31741-3-khuey@kylehuey.com>
References: <20231211045543.31741-1-khuey@kylehuey.com>
 <20231211045543.31741-3-khuey@kylehuey.com>
Message-ID: <20231212092221.GB28174@willie-the-truck>

On Sun, Dec 10, 2023 at 08:55:41PM -0800, Kyle Huey wrote:
> Now that struct perf_event's orig_overflow_handler is gone, there's no need
> for the functions and macros to support looking past overflow_handler to
> orig_overflow_handler.
> 
> This patch is solely a refactoring and results in no behavior change.
> 
> Signed-off-by: Kyle Huey <khuey at kylehuey.com>
> ---
>  arch/arm/kernel/hw_breakpoint.c   |  8 ++++----
>  arch/arm64/kernel/hw_breakpoint.c |  4 ++--
>  include/linux/perf_event.h        | 16 ++--------------
>  3 files changed, 8 insertions(+), 20 deletions(-)

Acked-by: Will Deacon <will at kernel.org>

Will


From will at kernel.org  Tue Dec 12 01:25:24 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 09:25:24 +0000
Subject: [PATCH] drivers/perf: Fix some null pointer dereference issues
 in thunderx2_pmu.c
In-Reply-To: <20231211090347.265240-1-chentao@kylinos.cn>
References: <20231211090347.265240-1-chentao@kylinos.cn>
Message-ID: <20231212092523.GC28174@willie-the-truck>

On Mon, Dec 11, 2023 at 05:03:47PM +0800, Kunwu Chan wrote:
> devm_kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure.
> 
> Fixes: 69c32972d593 ("drivers/perf: Add Cavium ThunderX2 SoC UNCORE PMU driver")
> Cc: Kunwu Chan <kunwu.chan at hotmail.com>
> Signed-off-by: Kunwu Chan <chentao at kylinos.cn>
> ---
>  drivers/perf/thunderx2_pmu.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
> index 1edb9c03704f..07edb174a0d7 100644
> --- a/drivers/perf/thunderx2_pmu.c
> +++ b/drivers/perf/thunderx2_pmu.c
> @@ -742,6 +742,8 @@ static int tx2_uncore_pmu_register(
>  
>  	tx2_pmu->pmu.name = devm_kasprintf(dev, GFP_KERNEL,
>  			"%s", name);
> +	if (!tx2_pmu->pmu.name)
> +		return -ENOMEM;
>  
>  	return perf_pmu_register(&tx2_pmu->pmu, tx2_pmu->pmu.name, -1);

AFAICT, perf_pmu_register() will WARN and return NULL, so I'm not sure what
we gain from the additional check.

>  }
> @@ -881,6 +883,11 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
>  		return NULL;
>  	}
>  
> +	if (!tx2_pmu->name) {
> +		dev_err(dev, "PMU type %d: Fail to allocate memory\n", type);
> +		devm_kfree(dev, tx2_pmu);
> +		return NULL;
> +	}

In the _highly_ unlikely even that devm_kasprintf() failed to allocate,
shouldn't we get a splat from the allocator? I don't think it's useful
to print another message.

Will


From horms at kernel.org  Tue Dec 12 01:29:43 2023
From: horms at kernel.org (Simon Horman)
Date: Tue, 12 Dec 2023 09:29:43 +0000
Subject: [RFC PATCH net-next v3 5/8] net: pcs: add driver for MediaTek
 USXGMII PCS
In-Reply-To: <07845ec900ba41ff992875dce12c622277592c32.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <07845ec900ba41ff992875dce12c622277592c32.1702352117.git.daniel@makrotopia.org>
Message-ID: <20231212092943.GS5817@kernel.org>

On Tue, Dec 12, 2023 at 03:47:47AM +0000, Daniel Golle wrote:
> Add driver for USXGMII PCS found in the MediaTek MT7988 SoC and supporting
> USXGMII, 10GBase-R and 5GBase-R interface modes.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

Hi Daniel,

some minor feedback from my side.

...

> diff --git a/drivers/net/pcs/pcs-mtk-usxgmii.c b/drivers/net/pcs/pcs-mtk-usxgmii.c

...

> +static int mtk_usxgmii_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
> +				  phy_interface_t interface,
> +				  const unsigned long *advertising,
> +				  bool permit_pause_to_mac)
> +{
> +	struct mtk_usxgmii_pcs *mpcs = pcs_to_mtk_usxgmii_pcs(pcs);
> +	unsigned int an_ctrl = 0, link_timer = 0, xfi_mode = 0, adapt_mode = 0;
> +	bool mode_changed = false;

nit: please consider arranging local variables in networking code
     in reverse xmas tree order - longest line to shortest.

     This may be useful:
     https://github.com/ecree-solarflare/xmastree

...
> diff --git a/include/linux/pcs/pcs-mtk-usxgmii.h b/include/linux/pcs/pcs-mtk-usxgmii.h
> new file mode 100644
> index 0000000000000..ef936d9c5f116
> --- /dev/null
> +++ b/include/linux/pcs/pcs-mtk-usxgmii.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __LINUX_PCS_MTK_USXGMII_H
> +#define __LINUX_PCS_MTK_USXGMII_H
> +
> +#include <linux/phylink.h>
> +
> +/**
> + * mtk_usxgmii_select_pcs() - Get MediaTek PCS instance
> + * @np:		Pointer to device node indentifying a MediaTek USXGMII PCS

nit: identifying

     ./scripts/checkpatch.py --codespell is your friend here.

> + * @mode:	Ethernet PHY interface mode
> + *
> + * Return PCS identified by a device node and the PHY interface mode in use
> + *
> + * Return:	Pointer to phylink PCS instance of NULL
> + */
> +#if IS_ENABLED(CONFIG_PCS_MTK_USXGMII)
> +struct phylink_pcs *mtk_usxgmii_pcs_get(struct device *dev, struct device_node *np);

nit: The kernel doc above does not match the signature
     of mtk_usxgmii_pcs_get().

     ./scripts/kernel-doc -none is helpful here.

> +void mtk_usxgmii_pcs_put(struct phylink_pcs *pcs);
> +#else
> +static inline struct phylink_pcs *mtk_usxgmii_pcs_get(struct device *dev, struct device_node *np)
> +{
> +	return NULL;
> +}
> +static inline void mtk_usxgmii_pcs_put(struct phylink_pcs *pcs) { }
> +#endif /* IS_ENABLED(CONFIG_PCS_MTK_USXGMII) */
> +
> +#endif /* __LINUX_PCS_MTK_USXGMII_H */
> -- 
> 2.43.0


From angelogioacchino.delregno at collabora.com  Tue Dec 12 01:31:02 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 10:31:02 +0100
Subject: [PATCH v5 4/5] clk: mediatek: add pcw_chg_bit control for PLLs of
 MT7988
In-Reply-To: <a43ad2a0131ea35988dd490ab235d16d4119bc3a.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
 <a43ad2a0131ea35988dd490ab235d16d4119bc3a.1702350213.git.daniel@makrotopia.org>
Message-ID: <27d8ce67-fb8b-403f-a35e-3e03a1ffd1a0@collabora.com>

Il 12/12/23 04:19, Daniel Golle ha scritto:
> From: Sam Shih <sam.shih at mediatek.com>
> 
> Introduce pcw_chg_bit member to struct mtk_pll_data and use it instead
> of the previously hardcoded PCW_CHG_MASK macro if set.
> This will needed for clocks on the MT7988 SoC.
> 
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From krzysztof.kozlowski at linaro.org  Tue Dec 12 01:31:04 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 10:31:04 +0100
Subject: [GIT PULL 1/2] arm64: dts: samsung: Exynops and Google for v6.8
Message-ID: <20231212093105.13938-1-krzysztof.kozlowski@linaro.org>

Hi,

DTS and bindings for v6.8, together.  Explanation for this is in first point of
pull-request tag message below.  The bindings are still kept on topic branch,
just in case if any other subsystem wants to pull them.

I expect this week to take more Google GS101 changes, so there will be later
another pull request on top of this one.  If you have any comments about GS101,
now is good time to say.

Best regards,
Krzysztof


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-6.8

for you to fetch changes up to 40af852a7ca59d23ab4afd02af2623121da2f116:

  Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64 (2023-12-11 08:41:24 +0100)

----------------------------------------------------------------
Samsung DTS ARM64 changes for v6.8

Two (and a half) major items are coming with this pull request:
1. Add specific compatibles to all Samsung Exynos and Tesla FSD blocks,
   because that's what guidelines expect [1] and is generally
   recommended practice.  Existing compatibles are left untouched, thus
   no driver changes are needed.  The work only cleans things up, so any
   future contributions will use recommended style: specific and
   fallback compatibles.

   Since no driver changes are needed in this work and the DTS is
   directly affected by bindings change (running tests with `make
   dtbs_check`), this pull includes all bindings changes, even though
   usual practice is that bindings come via driver subsystem.  Keeping
   everything here makes review and testing easier.  Also will allow us
   to avoid conflicts related to new platforms (see below).

2. Add ExynosAutov920 SoC and SADK board (Samsung Automotive Development
   Kit) with minimal support so far: serial console, GPIO-based keys and
   PWM fan.

3. Add few bindings for upcoming Google GS101 SoC.  This pull request
   does not include its DTS yet, just few reviewed dependencies.  DTS
   will be coming soon.

[1] Documentation/devicetree/bindings/writing-bindings.rst

----------------------------------------------------------------
Jaewon Kim (10):
      arm64: dts: exynos: add gpio-key node for exynosautov9-sadk
      dt-bindings: samsung: exynos-sysreg: add exynosautov920 sysreg
      dt-bindings: samsung: exynos-pmu: add exynosautov920 compatible
      dt-bindings: samsung: usi: add exynosautov920-usi compatible
      dt-bindings: serial: samsung: add exynosautov920-uart compatible
      dt-bindings: pwm: samsung: add exynosautov920 compatible
      dt-bindings: arm: samsung: Document exynosautov920 SADK board binding
      dt-bindings: hwinfo: samsung,exynos-chipid: add exynosautov920 compatible
      arm64: dts: exynos: add initial support for exynosautov920 SoC
      arm64: dts: exynos: add minimal support for exynosautov920 sadk board

Krzysztof Kozlowski (28):
      dt-bindings: hwinfo: samsung,exynos-chipid: add specific compatibles for existing SoC
      dt-bindings: i2c: exynos5: add specific compatibles for existing SoC
      dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for existing SoC
      dt-bindings: mmc: samsung,exynos-dw-mshc: add specific compatibles for existing SoC
      dt-bindings: rtc: s3c-rtc: add specific compatibles for existing SoC
      dt-bindings: serial: samsung: add specific compatibles for existing SoC
      dt-bindings: samsung: exynos-pmu: add specific compatibles for existing SoC
      dt-bindings: gpu: arm,mali-midgard: add specific compatibles for existing Exynos SoC
      dt-bindings: iio: samsung,exynos-adc: add specific compatibles for existing SoC
      ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing SoC
      dt-bindings: pwm: samsung: add specific compatibles for existing SoC
      arm64: dts: exynos5433: add specific compatibles to several blocks
      arm64: dts: exynos7: add specific compatibles to several blocks
      arm64: dts: exynos7885: add specific compatibles to several blocks
      arm64: dts: exynos850: add specific compatibles to several blocks
      arm64: dts: exynosautov9: add specific compatibles to several blocks
      Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64
      arm64: dts: exynos850: use Exynos7 fallbacks for pin wake-up controllers
      arm64: dts: exynosautov9: use Exynos7 fallbacks for pin wake-up controller
      dt-bindings: i2c: exynos5: add specific compatible for Tesla FSD
      dt-bindings: pwm: samsung: add specific compatible for Tesla FSD
      dt-bindings: serial: samsung: add specific compatible for Tesla FSD
      dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla FSD
      dt-bindings: watchdog: samsung: add specific compatible for Tesla FSD
      Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64
      arm64: dts: fsd: add specific compatibles for Tesla FSD
      dt-bindings: samsung: exynos-sysreg: combine exynosautov920 with other enum
      Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64

Peter Griffin (3):
      dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
      dt-bindings: clock: Add Google gs101 clock management unit bindings
      dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101

 .../bindings/arm/samsung/samsung-boards.yaml       |    6 +
 .../bindings/clock/google,gs101-clock.yaml         |  106 ++
 .../devicetree/bindings/gpu/arm,mali-midgard.yaml  |    5 +
 .../bindings/hwinfo/samsung,exynos-chipid.yaml     |   18 +-
 .../devicetree/bindings/i2c/i2c-exynos5.yaml       |   11 +-
 .../bindings/i2c/samsung,s3c2410-i2c.yaml          |   22 +-
 .../bindings/iio/adc/samsung,exynos-adc.yaml       |   29 +-
 .../bindings/mfd/samsung,exynos5433-lpass.yaml     |    2 +-
 .../bindings/mmc/samsung,exynos-dw-mshc.yaml       |   25 +-
 .../devicetree/bindings/pwm/pwm-samsung.yaml       |    4 +
 Documentation/devicetree/bindings/rtc/s3c-rtc.yaml |    5 +
 .../devicetree/bindings/serial/samsung_uart.yaml   |   17 +-
 .../bindings/soc/samsung/exynos-pmu.yaml           |   10 +
 .../bindings/soc/samsung/exynos-usi.yaml           |    6 +-
 .../soc/samsung/samsung,exynos-sysreg.yaml         |    5 +
 .../devicetree/bindings/sound/samsung-i2s.yaml     |   19 +-
 .../devicetree/bindings/watchdog/samsung-wdt.yaml  |   21 +-
 arch/arm64/boot/dts/exynos/Makefile                |    3 +-
 arch/arm64/boot/dts/exynos/exynos5433.dtsi         |   60 +-
 arch/arm64/boot/dts/exynos/exynos7.dtsi            |   18 +-
 arch/arm64/boot/dts/exynos/exynos7885.dtsi         |   45 +-
 arch/arm64/boot/dts/exynos/exynos850.dtsi          |   40 +-
 arch/arm64/boot/dts/exynos/exynosautov9-sadk.dts   |   51 +
 arch/arm64/boot/dts/exynos/exynosautov9.dtsi       |   10 +-
 .../boot/dts/exynos/exynosautov920-pinctrl.dtsi    | 1266 ++++++++++++++++++++
 arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts |   88 ++
 arch/arm64/boot/dts/exynos/exynosautov920.dtsi     |  312 +++++
 arch/arm64/boot/dts/tesla/fsd.dtsi                 |   32 +-
 include/dt-bindings/clock/google,gs101.h           |  392 ++++++
 29 files changed, 2494 insertions(+), 134 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920.dtsi
 create mode 100644 include/dt-bindings/clock/google,gs101.h


From krzysztof.kozlowski at linaro.org  Tue Dec 12 01:31:05 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 10:31:05 +0100
Subject: [GIT PULL 2/2] ARM: dts: samsung: Samsung for v6.8
In-Reply-To: <20231212093105.13938-1-krzysztof.kozlowski@linaro.org>
References: <20231212093105.13938-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231212093105.13938-2-krzysztof.kozlowski@linaro.org>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-6.8

for you to fetch changes up to 50c7cdc9a4d2d21373c1ab52c131109ab30c53f5:

  ARM: dts: samsung: exynos4210-i9100: Add accelerometer node (2023-12-08 20:42:17 +0100)

----------------------------------------------------------------
Samsung DTS ARM changes for v6.8

1. Exynos4212 and Exynos4412: Final fixes for dtbs_check warnings.
   Replace duplicate PMU node in FIMC IS node with syscon phandle.  The
   old solution of duplicated PMU node was not a correct representation of
   the hardware and could have concurrent access issues.

   The DTS change depends on media FIMC IS drivers changes already
   merged in previous cycle, thus it is not fully
   backwards-compatible.  It is a necessary trade-off in fixing wrong
   description in DTS.

   With this fix, `make dtbs_check` status looks like:
   S3C6410: no warnings
   Exynos: no warnings, one undocumented compatible
   S5PV210: one warning, one undocumented compatible

2. Exynos4210, Exynos4212, Exynos4412, S5PV210:
   Correct FIMC IS camera ranges and IO addresses to silence dtc W=1
   warnings.  No functional impact expected.
   After this fix, there are no dtc W=1 warnings on all ARMv7 platforms.

3. Galaxy I9100: Fix 12-second hang during boot by enabling regulator
   (real cause not really known), add touch keys and accelerometer.

----------------------------------------------------------------
Krzysztof Kozlowski (3):
      ARM: dts: samsung: exynos4x12: replace duplicate pmu node with phandle
      ARM: dts: samsung: exynos4: fix camera unit addresses/ranges
      ARM: dts: samsung: s5pv210: fix camera unit addresses/ranges

Paul Cercueil (3):
      ARM: dts: samsung: exynos4210-i9100: Unconditionally enable LDO12
      ARM: dts: samsung: exynos4210-i9100: Add node for touch keys
      ARM: dts: samsung: exynos4210-i9100: Add accelerometer node

 arch/arm/boot/dts/samsung/exynos4.dtsi         | 26 +++++++-------
 arch/arm/boot/dts/samsung/exynos4210-i9100.dts | 48 +++++++++++++++++++++++++-
 arch/arm/boot/dts/samsung/exynos4x12.dtsi      | 22 ++++++------
 arch/arm/boot/dts/samsung/s5pv210.dtsi         | 18 +++++-----
 4 files changed, 79 insertions(+), 35 deletions(-)


From angelogioacchino.delregno at collabora.com  Tue Dec 12 01:31:34 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 10:31:34 +0100
Subject: [PATCH v5 5/5] clk: mediatek: add drivers for MT7988 SoC
In-Reply-To: <14b00d8c9d1fcfdf8cd6b9b02e5a19566d970e6b.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
 <14b00d8c9d1fcfdf8cd6b9b02e5a19566d970e6b.1702350213.git.daniel@makrotopia.org>
Message-ID: <1cd5446a-37fd-4fbb-8c17-e0046e58c29b@collabora.com>

Il 12/12/23 04:19, Daniel Golle ha scritto:
> From: Sam Shih <sam.shih at mediatek.com>
> 
> Add APMIXED, ETH, INFRACFG and TOPCKGEN clock drivers which are
> typical MediaTek designs.
> 
> Also add driver for XFIPLL clock generating the 156.25MHz clock for
> the XFI SerDes. It needs an undocumented software workaround and has
> an unknown internal design.
> 
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From l.stelmach at samsung.com  Tue Dec 12 01:31:32 2023
From: l.stelmach at samsung.com (Lukasz Stelmach)
Date: Tue, 12 Dec 2023 10:31:32 +0100
Subject: [PATCH 03/12] hwrng: exynos - Convert to platform remove
 callback returning void
In-Reply-To: <817e91f7bb257745c0fb483037b83c1a6ba14e75.1702245873.git.u.kleine-koenig@pengutronix.de>
	("Uwe =?utf-8?Q?Kleine-K=C3=B6nig=22's?= message of "Sun, 10 Dec 2023
	23:12:18 +0100")
References: <817e91f7bb257745c0fb483037b83c1a6ba14e75.1702245873.git.u.kleine-koenig@pengutronix.de>
	<CGME20231212093133eucas1p1c19ba5aa058ca1e159bfd070aec0f306@eucas1p1.samsung.com>
Message-ID: <oypijdfs07937v.fsf%l.stelmach@samsung.com>

It was <2023-12-10 nie 23:12>, when Uwe Kleine-K?nig wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
>
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  drivers/char/hw_random/exynos-trng.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>

Acked-by: Lukasz Stelmach <l.stelmach at samsung.com>

> diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
> index 30207b7ac5f4..0ed5d22fe667 100644
> --- a/drivers/char/hw_random/exynos-trng.c
> +++ b/drivers/char/hw_random/exynos-trng.c
> @@ -173,7 +173,7 @@ static int exynos_trng_probe(struct platform_device *pdev)
>  	return ret;
>  }
>  
> -static int exynos_trng_remove(struct platform_device *pdev)
> +static void exynos_trng_remove(struct platform_device *pdev)
>  {
>  	struct exynos_trng_dev *trng =  platform_get_drvdata(pdev);
>  
> @@ -181,8 +181,6 @@ static int exynos_trng_remove(struct platform_device *pdev)
>  
>  	pm_runtime_put_sync(&pdev->dev);
>  	pm_runtime_disable(&pdev->dev);
> -
> -	return 0;
>  }
>  
>  static int exynos_trng_suspend(struct device *dev)
> @@ -223,7 +221,7 @@ static struct platform_driver exynos_trng_driver = {
>  		.of_match_table = exynos_trng_dt_match,
>  	},
>  	.probe = exynos_trng_probe,
> -	.remove = exynos_trng_remove,
> +	.remove_new = exynos_trng_remove,
>  };
>  
>  module_platform_driver(exynos_trng_driver);

-- 
?ukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/65468034/attachment.sig>

From angelogioacchino.delregno at collabora.com  Tue Dec 12 01:32:30 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 10:32:30 +0100
Subject: [PATCH v5 3/5] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <ce9b1e777090724794cf9f0c52bcd8618385fd06.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
 <ce9b1e777090724794cf9f0c52bcd8618385fd06.1702350213.git.daniel@makrotopia.org>
Message-ID: <55b785f4-a8dc-44e0-9320-9e71f0dc8853@collabora.com>

Il 12/12/23 04:18, Daniel Golle ha scritto:
> Add various clock controllers found in the MT7988 SoC to existing
> bindings (if applicable) and add files for the new ethwarp, mcusys
> and xfi-pll clock controllers not previously present in any SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From angelogioacchino.delregno at collabora.com  Tue Dec 12 01:32:53 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 10:32:53 +0100
Subject: [PATCH v5 2/5] dt-bindings: reset: mediatek: add MT7988 ethwarp
 reset IDs
In-Reply-To: <a60f5b5ed58626f3dbac1eab8a5845c3ce9bd17c.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
 <a60f5b5ed58626f3dbac1eab8a5845c3ce9bd17c.1702350213.git.daniel@makrotopia.org>
Message-ID: <4215d31d-99f0-4a47-a8c9-7324e5b51c02@collabora.com>

Il 12/12/23 04:18, Daniel Golle ha scritto:
> Add reset ID for ethwarp subsystem allowing to reset the built-in
> Ethernet switch of the MediaTek MT7988 SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Tue Dec 12 01:33:16 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 10:33:16 +0100
Subject: [PATCH v5 1/5] dt-bindings: clock: mediatek: add MT7988 clock IDs
In-Reply-To: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
Message-ID: <8585cdce-648e-4c27-a769-6441dac77707@collabora.com>

Il 12/12/23 04:18, Daniel Golle ha scritto:
> From: Sam Shih <sam.shih at mediatek.com>
> 
> Add MT7988 clock dt-bindings for topckgen, apmixedsys, infracfg,
> ethernet and xfipll subsystem clocks.
> 
> Signed-off-by: Sam Shih <sam.shih at mediatek.com>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From nicolas.ferre at microchip.com  Tue Dec 12 01:54:24 2023
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Tue, 12 Dec 2023 10:54:24 +0100
Subject: [PATCH] ARM: dts: microchip: sama5d27_som1_ek: Remove
 mmc-ddr-3_3v property from sdmmc0 node
In-Reply-To: <20231211070345.2792-1-mihai.sain@microchip.com>
References: <20231211070345.2792-1-mihai.sain@microchip.com>
Message-ID: <521ee68c-f204-4d56-a8ef-46f391bd1e1e@microchip.com>

On 11/12/2023 at 08:03, Mihai Sain wrote:
> On board the sdmmc0 interface is wired to a SD Card socket.
> According with mmc-controller bindings, the mmc-ddr-3_3v property
> is used for eMMC devices to enable high-speed DDR mode (3.3V I/O).
> Remove the mmc-ddr-3_3v property from sdmmc0 node.
> 
> Signed-off-by: Mihai Sain <mihai.sain at microchip.com>

Fine with me:
Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>

> ---
>   arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts
> index d0a6dbd377df..f3ffb8f01d8a 100644
> --- a/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts
> +++ b/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts
> @@ -54,7 +54,6 @@ usb2: ehci at 500000 {
>   
>   		sdmmc0: sdio-host at a0000000 {
>   			bus-width = <8>;
> -			mmc-ddr-3_3v;
>   			pinctrl-names = "default";
>   			pinctrl-0 = <&pinctrl_sdmmc0_default>;
>   			status = "okay";



From herve.codina at bootlin.com  Tue Dec 12 01:55:14 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Tue, 12 Dec 2023 10:55:14 +0100
Subject: [GIT PULL] PowerQUICC QMC and TSA drivers updates for v6.8
Message-ID: <20231212105514.273e8ab0@bootlin.com>

The following changes since commit 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab:

  Linux 6.7-rc3 (2023-11-26 19:59:33 -0800)

are available in the Git repository at:

  git at github.com:hcodina/linux.git tags/fsl_qmc_tsa_v6.8

for you to fetch changes up to 7a2ee1576dcc6bbe017a8283fba237b05b13fd15:

  soc: fsl: cpm1: qmc: Introduce functions to change timeslots at runtime (2023-12-12 10:29:20 +0100)

----------------------------------------------------------------
PowerQUICC QMC and TSA drivers updates for v6.8

This pull request contains updates to prepare the support for the QMC
HDLC driver.
        - Perform some fixes
        - Add support for child devices
        - Add QMC dynamic timeslot support

Signed-off-by: Herve Codina <herve.codina at bootlin.com>

----------------------------------------------------------------
Herve Codina (17):
      soc: fsl: cpm1: tsa: Fix __iomem addresses declaration
      soc: fsl: cpm1: qmc: Fix __iomem addresses declaration
      soc: fsl: cpm1: qmc: Fix rx channel reset
      soc: fsl: cpm1: qmc: Extend the API to provide Rx status
      soc: fsl: cpm1: qmc: Remove inline function specifiers
      soc: fsl: cpm1: qmc: Add support for child devices
      soc: fsl: cpm1: qmc: Introduce available timeslots masks
      soc: fsl: cpm1: qmc: Rename qmc_setup_tsa* to qmc_init_tsa*
      soc: fsl: cpm1: qmc: Introduce qmc_chan_setup_tsa*
      soc: fsl: cpm1: qmc: Remove no more needed checks from qmc_check_chans()
      soc: fsl: cpm1: qmc: Check available timeslots in qmc_check_chans()
      soc: fsl: cpm1: qmc: Add support for disabling channel TSA entries
      soc: fsl: cpm1: qmc: Split Tx and Rx TSA entries setup
      soc: fsl: cpm1: qmc: Introduce is_tsa_64rxtx flag
      soc: fsl: cpm1: qmc: Handle timeslot entries at channel start() and stop()
      soc: fsl: cpm1: qmc: Remove timeslots handling from setup_chan()
      soc: fsl: cpm1: qmc: Introduce functions to change timeslots at runtime

 drivers/soc/fsl/qe/qmc.c      | 658 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------
 drivers/soc/fsl/qe/tsa.c      |  22 ++--
 include/soc/fsl/qe/qmc.h      |  27 ++++-
 sound/soc/fsl/fsl_qmc_audio.c |   2 +-
 4 files changed, 538 insertions(+), 171 deletions(-)


From m-chawdhry at ti.com  Tue Dec 12 02:09:20 2023
From: m-chawdhry at ti.com (Manorit Chawdhry)
Date: Tue, 12 Dec 2023 15:39:20 +0530
Subject: [PATCH v2] watchdog: rti_wdt: Drop RPM count when unused
In-Reply-To: <20231122041642.2015936-1-vigneshr@ti.com>
References: <20231122041642.2015936-1-vigneshr@ti.com>
Message-ID: <20231212100920.wq26mylvn5qsms6w@uda0497581>

Hi Vignesh,

On 09:46-20231122, Vignesh Raghavendra wrote:
> Do a RPM put if watchdog is not already started during probe and re
> enable it in watchdog start.
> 
> On K3 SoCs, watchdogs and their corresponding CPUs are under same PD, so
> if the reference count of unused watchdogs aren't dropped, it will lead
> to CPU hotplug failures as Device Management firmware won't allow to
> turn off the PD due to dangling reference count.
> 
> Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support")
> Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
> ---
> 
> v2:
> * Drop 1/2 (will be posted along with runtime_pm callbacks)
> * Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync() which
>  takes care of err handling
> 
> v1: lore.kernel.org/r/20231110100726.2930218-1-vigneshr at ti.com
> 
>  drivers/watchdog/rti_wdt.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
> index 8e1be7ba0103..9215793a1c81 100644
> --- a/drivers/watchdog/rti_wdt.c
> +++ b/drivers/watchdog/rti_wdt.c
> @@ -77,6 +77,11 @@ static int rti_wdt_start(struct watchdog_device *wdd)
>  {
>  	u32 timer_margin;
>  	struct rti_wdt_device *wdt = watchdog_get_drvdata(wdd);
> +	int ret;
> +
> +	ret = pm_runtime_resume_and_get(wdd->parent);
> +	if (ret)
> +		return ret;
>  
>  	/* set timeout period */
>  	timer_margin = (u64)wdd->timeout * wdt->freq;
> @@ -343,6 +348,9 @@ static int rti_wdt_probe(struct platform_device *pdev)
>  	if (last_ping)
>  		watchdog_set_last_hw_keepalive(wdd, last_ping);
>  
> +	if (!watchdog_hw_running(wdd))
> +		pm_runtime_put_sync(&pdev->dev);
> +
>  	return 0;
>  
>  err_iomap:
> @@ -357,7 +365,10 @@ static void rti_wdt_remove(struct platform_device *pdev)
>  	struct rti_wdt_device *wdt = platform_get_drvdata(pdev);
>  
>  	watchdog_unregister_device(&wdt->wdd);
> -	pm_runtime_put(&pdev->dev);
> +
> +	if (!pm_runtime_suspended(&pdev->dev))
> +		pm_runtime_put(&pdev->dev);
> +
>  	pm_runtime_disable(&pdev->dev);
>  }
>  

Tested the following on j721s2 evm.
https://gist.github.com/manorit2001/05a85582fea670d39cc3cfb2df1e5328

Tested-by: Manorit Chawdhry <m-chawdhry at ti.com>

Regards,
Manorit

> -- 
> 2.42.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From lpieralisi at kernel.org  Tue Dec 12 02:18:47 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Tue, 12 Dec 2023 11:18:47 +0100
Subject: [PATCH v6 0/4] PCI: layerscape: Add suspend/resume support for ls1043 and ls1021
In-Reply-To: <20231204160829.2498703-1-Frank.Li@nxp.com>
References: <20231204160829.2498703-1-Frank.Li@nxp.com>
Message-ID: <170237631077.45230.13455897797263324456.b4-ty@kernel.org>

On Mon, 04 Dec 2023 11:08:25 -0500, Frank Li wrote:
> Add suspend/resume support for ls1043 and ls1021.
> 
> Change log see each patch
> 
> Frank Li (4):
>   PCI: layerscape: Add function pointer for exit_from_l2()
>   PCI: layerscape: Add suspend/resume for ls1021a
>   PCI: layerscape(ep): Rename pf_* as pf_lut_*
>   PCI: layerscape: Add suspend/resume for ls1043a
> 
> [...]

Applied to controller/layerscape, thanks!

[1/4] PCI: layerscape: Add function pointer for exit_from_l2()
      https://git.kernel.org/pci/pci/c/123971a193d9
[2/4] PCI: layerscape: Add suspend/resume for ls1021a
      https://git.kernel.org/pci/pci/c/6f8a41ba2623
[3/4] PCI: layerscape(ep): Rename pf_* as pf_lut_*
      https://git.kernel.org/pci/pci/c/762ef94b45d9
[4/4] PCI: layerscape: Add suspend/resume for ls1043a
      https://git.kernel.org/pci/pci/c/27b3bcbf8a79

Thanks,
Lorenzo


From peterlin at andestech.com  Tue Dec 12 02:17:41 2023
From: peterlin at andestech.com (Yu-Chien Peter Lin)
Date: Tue, 12 Dec 2023 18:17:41 +0800
Subject: [PATCH v4 02/13] irqchip/riscv-intc: Allow large non-standard
 interrupt number
In-Reply-To: <871qbwsn9h.ffs@tglx>
References: <20231122121235.827122-1-peterlin@andestech.com>
 <20231122121235.827122-3-peterlin@andestech.com>
 <871qbwsn9h.ffs@tglx>
Message-ID: <ZXgzRZK8uqgmY84L@APC323>

Hi Thomas,

On Fri, Dec 08, 2023 at 04:54:34PM +0100, Thomas Gleixner wrote:
> On Wed, Nov 22 2023 at 20:12, Yu Chien Peter Lin wrote:
> > Currently, the implementation of the RISC-V INTC driver uses the
> > interrupt cause as hwirq and has a limitation of supporting a
> 
> s/hwirq/hardware interrupt/
> 
> Please spell things out. We are not on Xitter here.
> 
> > maximum of 64 hwirqs. However, according to the privileged spec,
> > interrupt causes >= 16 are defined for platform use.
> >
> > This limitation prevents us from fully utilizing the available
> 
> This limitation prevents to fully utilize the ... 

Okay, will fix.

Thanks,
Peter Lin


From tabba at google.com  Tue Dec 12 02:24:46 2023
From: tabba at google.com (Fuad Tabba)
Date: Tue, 12 Dec 2023 10:24:46 +0000
Subject: [PATCH 06/13] arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion for
 DDI0601 2023-09
In-Reply-To: <20231212091047.GA28147@willie-the-truck>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
 <20231209-b4-arm64-sysreg-additions-v1-6-45284e538474@kernel.org>
 <CA+EHjTzdKS+ardXUofO+U1vnsOC3QjiJUBuKCHWw6z6zKdVGSA@mail.gmail.com> <20231212091047.GA28147@willie-the-truck>
Message-ID: <CA+EHjTzswc6Qji6yaTcYu7uc57MFY-79KxY45wFT8tQ+9PEhPw@mail.gmail.com>

Thank you Will.

...

> I renamed it to PAuth_LR following your comment, but it looks like
> ID_AA64ISAR1_EL1 is still missing this field entirely for the API and
> APA fields.

I noticed that, but thought it's more appropriate to have a separate
patch for that. I have one ready as part of my respin, unless we
accumulate a bunch of sysreg update patches first.

Cheers,
/fuad

> Will


From peterlin at andestech.com  Tue Dec 12 02:28:47 2023
From: peterlin at andestech.com (Yu-Chien Peter Lin)
Date: Tue, 12 Dec 2023 18:28:47 +0800
Subject: [PATCH v4 03/13] irqchip/riscv-intc: Introduce Andes hart-level
 interrupt controller
In-Reply-To: <87y1e4r8db.ffs@tglx>
References: <20231122121235.827122-1-peterlin@andestech.com>
 <20231122121235.827122-4-peterlin@andestech.com>
 <87y1e4r8db.ffs@tglx>
Message-ID: <ZXg130SN3AOUmx_v@APC323>

Hi Thomas,

On Fri, Dec 08, 2023 at 05:01:36PM +0100, Thomas Gleixner wrote:
> On Wed, Nov 22 2023 at 20:12, Yu Chien Peter Lin wrote:
> > To share the riscv_intc_domain_map() with the generic RISC-V INTC and
> > ACPI, we add a chip parameter to riscv_intc_init_common(), so it can be
> 
> s/we//
> 
> See: Documentation/process/
> 
> > passed to the irq_domain_set_info() as private data.
> > diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
> > index 2fdd40f2a791..30f0036c8978 100644
> > --- a/drivers/irqchip/irq-riscv-intc.c
> > +++ b/drivers/irqchip/irq-riscv-intc.c
> > @@ -17,6 +17,7 @@
> >  #include <linux/module.h>
> >  #include <linux/of.h>
> >  #include <linux/smp.h>
> > +#include <linux/soc/andes/irq.h>
> >  
> >  static struct irq_domain *intc_domain;
> >  
> > @@ -46,6 +47,31 @@ static void riscv_intc_irq_unmask(struct irq_data *d)
> >  	csr_set(CSR_IE, BIT(d->hwirq));
> >  }
> >  
> > +static void andes_intc_irq_mask(struct irq_data *d)
> > +{
> > +	/*
> > +	 * Andes specific S-mode local interrupt causes (hwirq)
> > +	 * are defined as (256 + n) and controlled by n-th bit
> > +	 * of SLIE.
> > +	 */
> > +	unsigned int mask = BIT(d->hwirq % BITS_PER_LONG);
> 
> How is this supposed to be correct with BITS_PER_LONG == 64?

Yes, I should subtract ANDES_SLI_CAUSE_BASE directly here.

> > +
> > +	if (d->hwirq < ANDES_SLI_CAUSE_BASE)
> > +		csr_clear(CSR_IE, mask);
> > +	else
> > +		csr_clear(ANDES_CSR_SLIE, mask);
> > +}
> > +
> > +static void andes_intc_irq_unmask(struct irq_data *d)
> > +{
> > +	unsigned int mask = BIT(d->hwirq % BITS_PER_LONG);
> 
> Ditto.
> 
> > +	if (d->hwirq < ANDES_SLI_CAUSE_BASE)
> > +		csr_set(CSR_IE, mask);
> > +	else
> > +		csr_set(ANDES_CSR_SLIE, mask);
> > +}
> 
> >  static int riscv_intc_domain_map(struct irq_domain *d, unsigned int irq,
> >  				 irq_hw_number_t hwirq)
> >  {
> > +	struct irq_chip *chip = d->host_data;
> > +
> >  	irq_set_percpu_devid(irq);
> > -	irq_domain_set_info(d, irq, hwirq, &riscv_intc_chip, d->host_data,
> > +	irq_domain_set_info(d, irq, hwirq, chip, d->host_data,
> 
> So this sets 'chip_data' to the chip itself. What's the point? Just set
> it to NULL as the chip obviously does not need chip_data at all.

Will fix. Thanks.

Best regards,
Peter Lin

> >  			    handle_percpu_devid_irq, NULL, NULL);
> >  
> >  	return 0;
> > @@ -112,11 +147,12 @@ static struct fwnode_handle *riscv_intc_hwnode(void)
> >  	return intc_domain->fwnode;
> >  }
> >  
> > -static int __init riscv_intc_init_common(struct fwnode_handle *fn)
> > +static int __init riscv_intc_init_common(struct fwnode_handle *fn,
> > +					 struct irq_chip *chip)
> >  {
> >  	int rc;
> >  
> > -	intc_domain = irq_domain_create_tree(fn, &riscv_intc_domain_ops, NULL);
> > +	intc_domain = irq_domain_create_tree(fn, &riscv_intc_domain_ops, chip);
> >  	if (!intc_domain) {
> >  		pr_err("unable to add IRQ domain\n");
> >  		return -ENXIO;
> > @@ -138,6 +174,7 @@ static int __init riscv_intc_init(struct device_node *node,
> >  {
> >  	int rc;
> >  	unsigned long hartid;
> > +	struct irq_chip *chip = &riscv_intc_chip;
> 
> https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#variable-declarations
> 
> Thanks
> 
>         tglx


From ulf.hansson at linaro.org  Tue Dec 12 02:36:35 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 12 Dec 2023 11:36:35 +0100
Subject: [PATCH] PM: domains: Drop the unused pm_genpd_opp_to_performance_state()
In-Reply-To: <CAJZ5v0jXRNDV7AhZPkrDvMtrk6cYeMJ+HuUs0kJ=kjbQ-YiyVA@mail.gmail.com>
References: <20231127151931.47055-1-ulf.hansson@linaro.org> <CAJZ5v0jXRNDV7AhZPkrDvMtrk6cYeMJ+HuUs0kJ=kjbQ-YiyVA@mail.gmail.com>
Message-ID: <CAPDyKFpJ6_+nF8q3L4Tg1E9St3stgJ06se0t=FLHkx4_36OJNA@mail.gmail.com>

On Mon, 11 Dec 2023 at 21:44, Rafael J. Wysocki <rafael at kernel.org> wrote:
>
> On Mon, Nov 27, 2023 at 4:19?PM Ulf Hansson <ulf.hansson at linaro.org> wrote:
> >
> > Since commit 7c41cdcd3bbe ("OPP: Simplify the over-designed pstate <->
> > level dance"), there is no longer any users of the
> > pm_genpd_opp_to_performance_state() API. Let's therefore drop it and its
> > corresponding ->opp_to_performance_state() callback, which also no longer
> > has any users.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
>
> I can take this in principle, but I'm wondering if you'd prefer to
> apply patches modifying domain.c yourself?  They are definitely
> related to the pmdomain tree.

Yes, it makes sense for me to pick the genpd core patches through the
pmdomain tree. In some cases there may be overlapping patches that are
more generic and not only limited to genpd, but I guess we can decide
on a case by case basis for those ones.

I can add the pmdomain tree to the GENERIC PM DOMAINS section in the
MAINTAINERS file to reflect this, if you think this is a good idea?

Kind regards
Uffe







>
> > ---
> >  drivers/base/power/domain.c | 32 --------------------------------
> >  include/linux/pm_domain.h   | 12 ------------
> >  2 files changed, 44 deletions(-)
> >
> > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> > index da1777e39eaa..cf65b5a9783c 100644
> > --- a/drivers/base/power/domain.c
> > +++ b/drivers/base/power/domain.c
> > @@ -3042,38 +3042,6 @@ int of_genpd_parse_idle_states(struct device_node *dn,
> >  }
> >  EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
> >
> > -/**
> > - * pm_genpd_opp_to_performance_state - Gets performance state of the genpd from its OPP node.
> > - *
> > - * @genpd_dev: Genpd's device for which the performance-state needs to be found.
> > - * @opp: struct dev_pm_opp of the OPP for which we need to find performance
> > - *     state.
> > - *
> > - * Returns performance state encoded in the OPP of the genpd. This calls
> > - * platform specific genpd->opp_to_performance_state() callback to translate
> > - * power domain OPP to performance state.
> > - *
> > - * Returns performance state on success and 0 on failure.
> > - */
> > -unsigned int pm_genpd_opp_to_performance_state(struct device *genpd_dev,
> > -                                              struct dev_pm_opp *opp)
> > -{
> > -       struct generic_pm_domain *genpd = NULL;
> > -       int state;
> > -
> > -       genpd = container_of(genpd_dev, struct generic_pm_domain, dev);
> > -
> > -       if (unlikely(!genpd->opp_to_performance_state))
> > -               return 0;
> > -
> > -       genpd_lock(genpd);
> > -       state = genpd->opp_to_performance_state(genpd, opp);
> > -       genpd_unlock(genpd);
> > -
> > -       return state;
> > -}
> > -EXPORT_SYMBOL_GPL(pm_genpd_opp_to_performance_state);
> > -
> >  static int __init genpd_bus_init(void)
> >  {
> >         return bus_register(&genpd_bus_type);
> > diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> > index 34663d0d5c55..b97c5e9820f9 100644
> > --- a/include/linux/pm_domain.h
> > +++ b/include/linux/pm_domain.h
> > @@ -118,7 +118,6 @@ struct genpd_power_state {
> >  };
> >
> >  struct genpd_lock_ops;
> > -struct dev_pm_opp;
> >  struct opp_table;
> >
> >  struct generic_pm_domain {
> > @@ -146,8 +145,6 @@ struct generic_pm_domain {
> >         int (*power_on)(struct generic_pm_domain *domain);
> >         struct raw_notifier_head power_notifiers; /* Power on/off notifiers */
> >         struct opp_table *opp_table;    /* OPP table of the genpd */
> > -       unsigned int (*opp_to_performance_state)(struct generic_pm_domain *genpd,
> > -                                                struct dev_pm_opp *opp);
> >         int (*set_performance_state)(struct generic_pm_domain *genpd,
> >                                      unsigned int state);
> >         struct gpd_dev_ops dev_ops;
> > @@ -348,8 +345,6 @@ int of_genpd_remove_subdomain(struct of_phandle_args *parent_spec,
> >  struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
> >  int of_genpd_parse_idle_states(struct device_node *dn,
> >                                struct genpd_power_state **states, int *n);
> > -unsigned int pm_genpd_opp_to_performance_state(struct device *genpd_dev,
> > -                                              struct dev_pm_opp *opp);
> >
> >  int genpd_dev_pm_attach(struct device *dev);
> >  struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> > @@ -395,13 +390,6 @@ static inline int of_genpd_parse_idle_states(struct device_node *dn,
> >         return -ENODEV;
> >  }
> >
> > -static inline unsigned int
> > -pm_genpd_opp_to_performance_state(struct device *genpd_dev,
> > -                                 struct dev_pm_opp *opp)
> > -{
> > -       return 0;
> > -}
> > -
> >  static inline int genpd_dev_pm_attach(struct device *dev)
> >  {
> >         return 0;
> > --
> > 2.34.1
> >


From angelogioacchino.delregno at collabora.com  Tue Dec 12 02:41:22 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 11:41:22 +0100
Subject: [RFC PATCH net-next v3 2/8] phy: add driver for MediaTek pextp
 10GE SerDes PHY
In-Reply-To: <a58dae1cce1b49093b0ae05159c784a9ec02f058.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <a58dae1cce1b49093b0ae05159c784a9ec02f058.1702352117.git.daniel@makrotopia.org>
Message-ID: <d5d0d01f-7df1-451a-a4bc-4c85f31b03db@collabora.com>

Il 12/12/23 04:46, Daniel Golle ha scritto:
> Add driver for MediaTek's pextp 10 Gigabit/s Ethernet SerDes PHY which
> can be found in the MT7988 SoC.
> 
> The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
> PHY_INTERFACE_MODE_* corresponding to the supported modes:
> 
>   * USXGMII
>   * 10GBase-R
>   * 5GBase-R
>   * 2500Base-X
>   * 1000Base-X
>   * Cisco SGMII (MAC side)
> 
> In order to work-around a performance issue present on the first of
> two PEXTP present in MT7988 special tuning is applied which can be
> selected by adding the mediatek,usxgmii-performance-errata property to
> the device tree node.
> 
> There is no documentation what-so-ever for the pextp registers and
> this driver is based on a GPL licensed implementation found in
> MediaTek's SDK.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---

..snip..

Can anyone from MediaTek **please** define those registers and fields?

In this form, this driver is pretty obscure and nobody knows what it's doing;
please remember that, by actually providing a definition for those registers and
fields, the operation (reliability) of this PHY may be improved and this driver
will be actually maintainable (and possibly support more than one variation of
this PHY in the future with less efforts).

MediaTek?

Regards,
Angelo

> +
> +	/* Setup operation mode */
> +	if (is_10g)
> +		iowrite32(0x00c9071c, pextp->base + 0x9024);
> +	else
> +		iowrite32(0x00d9071c, pextp->base + 0x9024);
> +
> +	if (is_5g)
> +		iowrite32(0xaaa5a5aa, pextp->base + 0x2020);
> +	else
> +		iowrite32(0xaa8585aa, pextp->base + 0x2020);
> +
> +	if (is_2p5g || is_5g || is_10g) {
> +		iowrite32(0x0c020707, pextp->base + 0x2030);
> +		iowrite32(0x0e050f0f, pextp->base + 0x2034);
> +		iowrite32(0x00140032, pextp->base + 0x2040);
> +	} else {
> +		iowrite32(0x0c020207, pextp->base + 0x2030);
> +		iowrite32(0x0e05050f, pextp->base + 0x2034);
> +		iowrite32(0x00200032, pextp->base + 0x2040);
> +	}
> +
> +	if (is_2p5g || is_10g)
> +		iowrite32(0x00c014aa, pextp->base + 0x50f0);
> +	else if (is_5g)
> +		iowrite32(0x00c018aa, pextp->base + 0x50f0);
> +	else
> +		iowrite32(0x00c014ba, pextp->base + 0x50f0);
> +
> +	if (is_5g) {
> +		iowrite32(0x3777812b, pextp->base + 0x50e0);
> +		iowrite32(0x005c9cff, pextp->base + 0x506c);
> +		iowrite32(0x9dfafafa, pextp->base + 0x5070);
> +		iowrite32(0x273f3f3f, pextp->base + 0x5074);
> +		iowrite32(0xa8883868, pextp->base + 0x5078);
> +		iowrite32(0x14661466, pextp->base + 0x507c);
> +	} else {
> +		iowrite32(0x3777c12b, pextp->base + 0x50e0);
> +		iowrite32(0x005f9cff, pextp->base + 0x506c);
> +		iowrite32(0x9d9dfafa, pextp->base + 0x5070);
> +		iowrite32(0x27273f3f, pextp->base + 0x5074);
> +		iowrite32(0xa7883c68, pextp->base + 0x5078);
> +		iowrite32(0x11661166, pextp->base + 0x507c);
> +	}
> +
> +	if (is_2p5g || is_10g) {
> +		iowrite32(0x0e000aaf, pextp->base + 0x5080);
> +		iowrite32(0x08080d0d, pextp->base + 0x5084);
> +		iowrite32(0x02030909, pextp->base + 0x5088);
> +	} else if (is_5g) {
> +		iowrite32(0x0e001abf, pextp->base + 0x5080);
> +		iowrite32(0x080b0d0d, pextp->base + 0x5084);
> +		iowrite32(0x02050909, pextp->base + 0x5088);
> +	} else {
> +		iowrite32(0x0e000eaf, pextp->base + 0x5080);
> +		iowrite32(0x08080e0d, pextp->base + 0x5084);
> +		iowrite32(0x02030b09, pextp->base + 0x5088);
> +	}
> +
> +	if (is_5g) {
> +		iowrite32(0x0c000000, pextp->base + 0x50e4);
> +		iowrite32(0x04000000, pextp->base + 0x50e8);
> +	} else {
> +		iowrite32(0x0c0c0000, pextp->base + 0x50e4);
> +		iowrite32(0x04040000, pextp->base + 0x50e8);
> +	}
> +
> +	if (is_2p5g || mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x0f0f0c06, pextp->base + 0x50eC);
> +	else
> +		iowrite32(0x0f0f0606, pextp->base + 0x50eC);
> +
> +	if (is_5g) {
> +		iowrite32(0x50808c8c, pextp->base + 0x50a8);
> +		iowrite32(0x18000000, pextp->base + 0x6004);
> +	} else {
> +		iowrite32(0x506e8c8c, pextp->base + 0x50a8);
> +		iowrite32(0x18190000, pextp->base + 0x6004);
> +	}
> +
> +	if (is_10g)
> +		iowrite32(0x01423342, pextp->base + 0x00f8);
> +	else if (is_5g)
> +		iowrite32(0x00a132a1, pextp->base + 0x00f8);
> +	else if (is_2p5g)
> +		iowrite32(0x009c329c, pextp->base + 0x00f8);
> +	else
> +		iowrite32(0x00fa32fa, pextp->base + 0x00f8);
> +
> +	/* Force SGDT_OUT off and select PCS */
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x80201f20, pextp->base + 0x00f4);
> +	else
> +		iowrite32(0x80201f21, pextp->base + 0x00f4);
> +
> +	/* Force GLB_CKDET_OUT */
> +	iowrite32(0x00050c00, pextp->base + 0x0030);
> +
> +	/* Force AEQ on */
> +	iowrite32(0x02002800, pextp->base + 0x0070);
> +	ndelay(1020);
> +
> +	/* Setup DA default value */
> +	iowrite32(0x00000020, pextp->base + 0x30b0);
> +	iowrite32(0x00008a01, pextp->base + 0x3028);
> +	iowrite32(0x0000a884, pextp->base + 0x302c);
> +	iowrite32(0x00083002, pextp->base + 0x3024);
> +	if (mtk_interface_mode_is_xgmii(interface)) {
> +		iowrite32(0x00022220, pextp->base + 0x3010);
> +		iowrite32(0x0f020a01, pextp->base + 0x5064);
> +		iowrite32(0x06100600, pextp->base + 0x50b4);
> +		if (interface == PHY_INTERFACE_MODE_USXGMII)
> +			iowrite32(0x40704000, pextp->base + 0x3048);
> +		else
> +			iowrite32(0x47684100, pextp->base + 0x3048);
> +	} else {
> +		iowrite32(0x00011110, pextp->base + 0x3010);
> +		iowrite32(0x40704000, pextp->base + 0x3048);
> +	}
> +
> +	if (!mtk_interface_mode_is_xgmii(interface) && !is_2p5g)
> +		iowrite32(0x0000c000, pextp->base + 0x3064);
> +
> +	if (interface != PHY_INTERFACE_MODE_10GBASER) {
> +		iowrite32(0xa8000000, pextp->base + 0x3050);
> +		iowrite32(0x000000aa, pextp->base + 0x3054);
> +	} else {
> +		iowrite32(0x00000000, pextp->base + 0x3050);
> +		iowrite32(0x00000000, pextp->base + 0x3054);
> +	}
> +
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x00000f00, pextp->base + 0x306c);
> +	else if (is_2p5g)
> +		iowrite32(0x22000f00, pextp->base + 0x306c);
> +	else
> +		iowrite32(0x20200f00, pextp->base + 0x306c);
> +
> +	if (interface == PHY_INTERFACE_MODE_10GBASER && pextp->da_war)
> +		iowrite32(0x0007b400, pextp->base + 0xa008);
> +
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x00040000, pextp->base + 0xa060);
> +	else
> +		iowrite32(0x00050000, pextp->base + 0xa060);
> +
> +	if (is_10g)
> +		iowrite32(0x00000001, pextp->base + 0x90d0);
> +	else if (is_5g)
> +		iowrite32(0x00000003, pextp->base + 0x90d0);
> +	else if (is_2p5g)
> +		iowrite32(0x00000005, pextp->base + 0x90d0);
> +	else
> +		iowrite32(0x00000007, pextp->base + 0x90d0);
> +
> +	/* Release reset */
> +	iowrite32(0x0200e800, pextp->base + 0x0070);
> +	usleep_range(150, 500);
> +
> +	/* Switch to P0 */
> +	iowrite32(0x0200c111, pextp->base + 0x0070);
> +	ndelay(1020);
> +	iowrite32(0x0200c101, pextp->base + 0x0070);
> +	usleep_range(15, 50);
> +
> +	if (mtk_interface_mode_is_xgmii(interface)) {
> +		/* Switch to Gen3 */
> +		iowrite32(0x0202c111, pextp->base + 0x0070);
> +	} else {
> +		/* Switch to Gen2 */
> +		iowrite32(0x0201c111, pextp->base + 0x0070);
> +	}
> +	ndelay(1020);
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x0202c101, pextp->base + 0x0070);
> +	else
> +		iowrite32(0x0201c101, pextp->base + 0x0070);
> +	usleep_range(100, 500);
> +	iowrite32(0x00000030, pextp->base + 0x30b0);
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x80201f00, pextp->base + 0x00f4);
> +	else
> +		iowrite32(0x80201f01, pextp->base + 0x00f4);
> +
> +	iowrite32(0x30000000, pextp->base + 0x3040);
> +	usleep_range(400, 1000);
> +}
> +
> +static int mtk_pextp_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> +	if (mode != PHY_MODE_ETHERNET)
> +		return -EINVAL;
> +
> +	switch (submode) {
> +	case PHY_INTERFACE_MODE_1000BASEX:
> +	case PHY_INTERFACE_MODE_2500BASEX:
> +	case PHY_INTERFACE_MODE_SGMII:
> +	case PHY_INTERFACE_MODE_5GBASER:
> +	case PHY_INTERFACE_MODE_10GBASER:
> +	case PHY_INTERFACE_MODE_USXGMII:
> +		mtk_pextp_setup(pextp, submode);
> +		return 0;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static int mtk_pextp_reset(struct phy *phy)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> +	reset_control_assert(pextp->reset);
> +	usleep_range(100, 500);
> +	reset_control_deassert(pextp->reset);
> +	usleep_range(1, 10);
> +
> +	return 0;
> +}
> +
> +static int mtk_pextp_power_on(struct phy *phy)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> +	return clk_bulk_prepare_enable(MTK_PEXTP_NUM_CLOCKS, pextp->clocks);
> +}
> +
> +static int mtk_pextp_power_off(struct phy *phy)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> +	clk_bulk_disable_unprepare(MTK_PEXTP_NUM_CLOCKS, pextp->clocks);
> +
> +	return 0;
> +}
> +
> +static const struct phy_ops mtk_pextp_ops = {
> +	.power_on	= mtk_pextp_power_on,
> +	.power_off	= mtk_pextp_power_off,
> +	.set_mode	= mtk_pextp_set_mode,
> +	.reset		= mtk_pextp_reset,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int mtk_pextp_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct phy_provider *phy_provider;
> +	struct mtk_pextp_phy *pextp;
> +	struct phy *phy;
> +
> +	if (!np)
> +		return -ENODEV;
> +
> +	pextp = devm_kzalloc(&pdev->dev, sizeof(*pextp), GFP_KERNEL);
> +	if (!pextp)
> +		return -ENOMEM;
> +
> +	pextp->base = devm_of_iomap(&pdev->dev, np, 0, NULL);
> +	if (!pextp->base)
> +		return -EIO;
> +
> +	pextp->dev = &pdev->dev;
> +
> +	pextp->clocks[0].id = "topxtal";
> +	pextp->clocks[0].clk = devm_clk_get(&pdev->dev, pextp->clocks[0].id);
> +	if (IS_ERR(pextp->clocks[0].clk))
> +		return PTR_ERR(pextp->clocks[0].clk);
> +
> +	pextp->clocks[1].id = "xfipll";
> +	pextp->clocks[1].clk = devm_clk_get(&pdev->dev, pextp->clocks[1].id);
> +	if (IS_ERR(pextp->clocks[1].clk))
> +		return PTR_ERR(pextp->clocks[1].clk);
> +
> +	pextp->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> +	if (IS_ERR(pextp->reset))
> +		return PTR_ERR(pextp->reset);
> +
> +	pextp->da_war = of_property_read_bool(np, "mediatek,usxgmii-performance-errata");
> +
> +	phy = devm_phy_create(&pdev->dev, NULL, &mtk_pextp_ops);
> +	if (IS_ERR(phy))
> +		return PTR_ERR(phy);
> +
> +	phy_set_drvdata(phy, pextp);
> +
> +	phy_provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
> +
> +	return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct of_device_id mtk_pextp_match[] = {
> +	{ .compatible = "mediatek,mt7988-xfi-pextp", },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, mtk_pextp_match);
> +
> +static struct platform_driver mtk_pextp_driver = {
> +	.probe = mtk_pextp_probe,
> +	.driver = {
> +		.name = "mtk-pextp",
> +		.of_match_table = mtk_pextp_match,
> +	},
> +};
> +module_platform_driver(mtk_pextp_driver);
> +
> +MODULE_DESCRIPTION("MediaTek pextp SerDes PHY driver");
> +MODULE_AUTHOR("Daniel Golle <daniel at makrotopia.org>");
> +MODULE_LICENSE("GPL");




From fancer.lancer at gmail.com  Tue Dec 12 02:42:35 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue, 12 Dec 2023 13:42:35 +0300
Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <slq3uvpe424lxksgc2ho4q5apon6yqyvmq3ubpmx3z5ln5yhqf@klnkglqb6o6r>
References: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>
 <jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz@ntepnnzzelta>
 <hxds75erxqcfkufxnfbyo2up4b4jeicmi3f5xr6qlb3yf7fe76@4byeq62jhu4o>
 <hgz3pt625kggix6kzincohw7kr2okcumrwfkmjgiauw2yvhrzt@ekeygo4b7k3b>
 <h5ucipgjtsesrz3jyul5xohu4pqom56v6ayx7aonnfesret3ht@wmblmndj6zir>
 <hpqssnt7odmuuyhsljuqovmwatdjz4s6kix6abq7lrvyciawy5@5ypscmmivnmh>
 <slq3uvpe424lxksgc2ho4q5apon6yqyvmq3ubpmx3z5ln5yhqf@klnkglqb6o6r>
Message-ID: <4e42erte4zvx77vgj77kcal2ss4nma3ggm3wa6wssleuubtzit@gbkbbudjfwhz>

On Mon, Dec 11, 2023 at 01:48:47PM -0600, Andrew Halaney wrote:
> On Mon, Dec 11, 2023 at 08:27:46PM +0300, Serge Semin wrote:
> > On Fri, Dec 08, 2023 at 10:50:29AM -0600, Andrew Halaney wrote:
> > > On Fri, Dec 08, 2023 at 06:07:06PM +0300, Serge Semin wrote:
> > > > On Thu, Dec 07, 2023 at 05:07:24PM -0600, Andrew Halaney wrote:
> > > > > On Fri, Dec 08, 2023 at 01:16:12AM +0300, Serge Semin wrote:
> > > > > > On Thu, Dec 07, 2023 at 03:12:40PM -0600, Andrew Halaney wrote:
> > > > > > > The stmmac_dt_phy() function, which parses the devicetree node of the
> > > > > > > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > > > > > > fixed-link means in relation to the MAC's MDIO bus. This results in
> > > > > > > a MDIO bus being created in situations it need not be.
> > > > > > > 
> > > > > > > Currently a MDIO bus is created if the description is either:
> > > > > > > 
> > > > > > >     1. Not fixed-link
> > > > > > >     2. fixed-link but contains a MDIO bus as well
> > > > > > > 
> > > > > > > The "1" case above isn't always accurate. If there's a phy-handle,
> > > > > > > it could be referencing a phy on another MDIO controller's bus[1]. In
> > > > > > > this case currently the MAC will make a MDIO bus and scan it all
> > > > > > > anyways unnecessarily.
> > > > > > > 
> > > > > > > There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> > > > > > > be created and scanned for a phy. This case can also be inferred from
> > > > > > > the platform description by not having a phy-handle && not being
> > > > > > > fixed-link. This hits case "1" in the current driver's logic.
> > > > > > > 
> > > > > > > Let's improve the logic to create a MDIO bus if either:
> > > > > > > 
> > > > > > 
> > > > > > >     - Devicetree contains a MDIO bus
> > > > > > >     - !fixed-link && !phy-handle (legacy handling)
> > > > > > 
> > > > > > If what you suggest here is a free from regressions semantics change
> > > > > > (really hope it is) I will be with both my hands for it. This will
> > > > > > solve the problem we have with one of our device which doesn't have
> > > > > > SMA interface (hardware designers decided to save ~4K gates of the
> > > > > > chip area) but has a PHY externally attached to the DW XGMAC<->XPCS
> > > > > > interface. PHY is accessible via a GPIO-based MDIO bus. BTW having no
> > > > > > SMA interface available on a DW *MAC device but creating the MDIO-bus
> > > > > > on top of the non-existent SMA CSRs anyway causes having _32_ dummy
> > > > > > PHYs created with zero IDs.
> > > > > 
> > > > 
> > > > > I hope it is regression free! I have tested both the [1] and [2] cases
> > > > > (I hacked up the devicetree for [1] to make it look like [2]) without
> > > > > any issue.
> > > > > 
> > > > 
> > > > I doubt you could have tested it on all the possible hardware the
> > > > STMMAC driver supports. The problem is that the DT-bindings thing is a
> > > > kind of contract which can't be changed that easily. It's like ABI but
> > > > for the hardware description so the kernel would bootup correctly on
> > > > the platforms with the old DT blobs. But if the change isn't that
> > > > critical, if the device-tree sources in the kernel fit to the updated
> > > > semantics, if the networking subsystem maintainers aren't against it
> > > > and I guess with the Rob, Krzysztof or Conor blessing (at least it
> > > > won't hurt to add them to the Cc-list together with the devicetree
> > > > mailing-list), then it will likely be accepted.
> > > 
> > 
> > > To be clear, I don't think we're violating the dt-binding ABI contract
> > > here. My intention is that all the existing use cases continue to work,
> > > and this just improves one use case. I did a write up
> > > over on v2 about the use cases I see and the current logic vs what
> > > changes with this patch series:
> > > 
> > >     https://lore.kernel.org/netdev/plvbqgi2bwlv5quvpiwplq7cxx6m5rl3ghnfhuxfx4bpuhyihl at zmydwrtwdeg6/
> > > 
> > > Please comment if you think I have broken some backwards
> > > compatibility.
> > 
> > To shortly sum up so I didn't miss something. Current semantics of the
> > MDIO-bus registration is:
> > if !fixed-link || mdio_node_present
> >     create MDIO-bus
> > and the semantics of the PHY auto-probe (legacy) is:
> > if !(fixed-link || mdio_node_present || phy_node_present)
> >     auto-probe PHY
> 

> I think phy_node_present doesn't belong in the current view of the
> semantics for PHY auto-probe (legacy). This devicetree would trigger a
> PHY auto-probe/scan on ethernet0's MAC's MDIO bus:
> 
> 	random-mdio-bus {
> 		rgmii_phy: phy at 0 {
> 		};
> 	};
> 
> 	ethernet0 {
> 		phy-handle = <&rgmii_phy>;
> 	};

Em, unless I miss something, but on STMMAC it wont due to the next
statement: stmmac_mdio_register():
	if (priv->plat->phy_node || mdio_node)
		goto bus_register_done;

Note by the "PHY auto-probe (legacy)" semantics I meant the algo
implemented at the bottom of the stmmac_mdio_register() method. If no
PHY-node or MDIO-node specified it tries to find any PHY on the
DW MAC SMA MDIO bus and use it in the driver.

If what you meant was the PHY auto-probe/scan executed in the
__mdiobus_register() method, then I guess it's relevant only _if_ the
stmmac_mdio_register() method performs the legacy auto-probing too.
Yes, the MDIO/PHY subsystem _will_ scan the MDIO-bus for PHYs, but
they won't be utilized in the STMMAC driver due to the conditional
statement above. In other words I guess the scanning performed in
__mdiobus_register() will be pointless anyway in that case, since no
detected PHY-devices will be actually used afterwards.

> 
> The assumption I make in this patch is that nothing useful could be on
> ethernet0's MDIO bus, it certainly at least is not the phy the MAC uses.
> 
> > 
> > You are changing the MDIO-bus creation semantics to:
> > if !(fixed-link || phy_node_present) || mdio_node_present
> >     create MDIO-bus
> > with no change in the PHY auto-probe semantics:
> > if !(fixed-link || mdio_node_present || phy_node_present)
> >     auto-probe PHY
> 
> Unfortunately as I highlighted above this logic (while accurate to the
> patch under review) is a change from the prior logic for the "auto-probe
> PHY" case.
> 
> > 
> > So the change is that if a PHY-handle is specified the MDIO-bus won't
> > be created with the rest conditions being the same.
> > 
> > The only concern I had was the so called legacy case and a possibility
> > to have MDIO-bus with other than PHY devices. Based on the pseudo-code
> > above the former case won't be affected since having PHY-node
> > specified didn't triggered MDIO-bus auto-probe even before your
> > change. The later case concerns for instance the DW XPCS devices which
> 
> As I've realized in your response here, there is the possibility that
> something is on the MDIO bus in the ethernet0 exmpale bus above, and would
> probe, in the before handling. So I guess this isn't totally backwards
> compatible. Gah, thanks for highlighting.

AFAICS what you suggest won't break currently supported by the STMMAC
driver _platforms_. This is what actually matters. The legacy PHY
auto-probing will work as before. None of the OF-based platforms
currently expect having non-PHY devices on the bus.

> 
> I'm not sure in practice if anyone out there is really relying on that
> or not. I can get away with the "no auto-probe/scan of bus" optimization I
> really desire by describing my MDIO bus as disabled in the devicetree
> (need to send patches to do that in the dts and handle it gracefully in
> stmmac). I'm wondering if I should keep forth with this patch as is, or
> if I should keep the same logic but clean it up a bit as is done in the
> current patch... I guess probably the latter.

It's better to limit some complicated logic before somebody tries to
use it to bypass a harder but correct way of directly defining all
devices (including non-PHY ones) in dts. Seeing presumably no
currently supported platform will be broken I think you should keep
the patch as is.

-Serge(y)

> 
> > on some platforms could be found on the DW MAC MDIO bus with not
> > having PHY living on that bus. But DW XPCS auto-probing currently is
> > only supported by the non-OF platforms (it's Intel). Thus your change
> > is supposed to be safe here too.
> > 
> > So to speak AFAICS from the STMMAC MDIO OF stuff your solution isn't
> > supposed to cause regressions and break the current DTs backward
> > compatibility indeed.
> > 
> > Regarding the ideal implementation. What could be much better is to
> > implement the next semantics:
> > if SMA-capability-detected &&
> >    (!mdio_node_present || (mdio_node_present && mdio_node_enabled))
> >     create MDIO-bus
> > and preserve the PHY auto-probe semantics for backwards compatibility.
> > Regarding the SMA-capability flag, it has been presented since DW GMAC
> > v3.50, so since very much early DW MAC releases. But even for the
> > early devices I think it could be auto-detected by checking the SMA
> > CSRs writability. At least DW XGMAC AFAICS has the command CSR not
> > writable if SMA is unavailable.
> > 
> > But I guess it's a matter of another patch.
> > 
> 
> I like that logic for what it is worth, although would be unsure of
> verifying the SMA-capability-detected part of it. But I wouldn't mind
> seeing that patch :)
> 


From angelogioacchino.delregno at collabora.com  Tue Dec 12 02:50:40 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 11:50:40 +0100
Subject: [PATCH v2] arm64: defconfig: Enable configs for
 MT8195-Cherry-Tomato Chromebook
In-Reply-To: <20231122181335.535498-1-nfraprado@collabora.com>
References: <20231122181335.535498-1-nfraprado@collabora.com>
Message-ID: <af322faf-a44a-462e-9ac8-0532cdf5824b@collabora.com>

Il 22/11/23 19:13, N?colas F. R. A. Prado ha scritto:
> Enable missing configs needed to boot the MT8195-Cherry-Tomato
> Chromebook with full support on the defconfig.
> 
> The configs enabled bring in support for the DSP and sound card,
> display, thermal sensor and keyboard backlight.
> 
> Signed-off-by: N?colas F. R. A. Prado <nfraprado at collabora.com>
> 

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From Jiangfeng.Ma at synopsys.com  Tue Dec 12 02:50:53 2023
From: Jiangfeng.Ma at synopsys.com (Jiangfeng Ma)
Date: Tue, 12 Dec 2023 10:50:53 +0000
Subject: =?utf-8?B?5Zue5aSNOiBbUEFUQ0hdIG5ldDpzdG1tYWM6c3RtbWFjX3BsYXRmb3JtOkFk?=
 =?utf-8?Q?d_snps,xpcs_devicetree_parsing?=
In-Reply-To: <uzss3af2cklc5bx5apszoegafeaaiv7o7iwgrgrml4grkyev6p@6tme4hdb4mkn>
References: <SA0PR12MB44138E48A245378CF54D2F9ED98AA@SA0PR12MB4413.namprd12.prod.outlook.com>
 <20231208091408.071680db@device.home>
 <uzss3af2cklc5bx5apszoegafeaaiv7o7iwgrgrml4grkyev6p@6tme4hdb4mkn>
Message-ID: <SA0PR12MB4413305305D47CAAAFEAD528D98EA@SA0PR12MB4413.namprd12.prod.outlook.com>



> -----????-----
> ???: Serge Semin <fancer.lancer at gmail.com>
> ????: Friday, December 8, 2023 10:28 PM
> ???: Maxime Chevallier <maxime.chevallier at bootlin.com>; Jiangfeng Ma <jiama at synopsys.com>
> ??: Jiangfeng Ma <jiama at synopsys.com>; Alexandre Torgue <alexandre.torgue at foss.st.com>; Jose
> Abreu <joabreu at synopsys.com>; David S. Miller <davem at davemloft.net>; Eric Dumazet
> <edumazet at google.com>; Jakub Kicinski <kuba at kernel.org>; Paolo Abeni <pabeni at redhat.com>;
> Maxime Coquelin <mcoquelin.stm32 at gmail.com>; Simon Horman <horms at kernel.org>; Andrew
> Halaney <ahalaney at redhat.com>; Bartosz Golaszewski <bartosz.golaszewski at linaro.org>; Shenwei
> Wang <shenwei.wang at nxp.com>; Johannes Zink <j.zink at pengutronix.de>; Russell King (Oracle
> <rmk+kernel at armlinux.org.uk>; Jochen Henneberg <jh at henneberg-systemdesign.com>; open
> list:STMMAC ETHERNET DRIVER <netdev at vger.kernel.org>; moderated list:ARM/STM32
> ARCHITECTURE <linux-stm32 at st-md-mailman.stormreply.com>; moderated list:ARM/STM32
> ARCHITECTURE <linux-arm-kernel at lists.infradead.org>; open list <linux-kernel at vger.kernel.org>; James
> Li <lijames at synopsys.com>; Martin McKenny <mmckenny at synopsys.com>
> ??: Re: [PATCH] net:stmmac:stmmac_platform:Add snps,xpcs devicetree parsing
> 
Hi Maxime, Serge
Thanks for your review!

> Hi Maxime, Jiangfeng
> 
> On Fri, Dec 08, 2023 at 09:14:08AM +0100, Maxime Chevallier wrote:
> > Hello,
> >
> > On Fri, 8 Dec 2023 07:02:19 +0000
> > Jiangfeng Ma <Jiangfeng.Ma at synopsys.com> wrote:
> >
> > > In order to setup xpcs, has_xpcs must be set to a non-zero value.
> > > Add new optional devicetree properties representing this.
> > >
> > > If has_xpcs is set to true, then xpcs_an_inband should preferably be
> > > consistent with it, Otherwise, some errors may occur when starting
> > > the network, For example, the phy interface that xpcs already supports,
> > > but link up fails.
> >
> > Can you elaborate on why you need this, and on which platform
> > especially ? Usually drivers for the various stmmac variants know if
> > they have XPCS or not, or can guess it based on some info such as the
> > configured PHY mode (dwmac-intel).

There is no specific platform here. I utilize the dwmcac-generic platform,
and xpcs is utilized as the MDIO device or it can be seen as a C45 PHY.
While it's sometimes possible to deduce the presence of xpcs based on information
such as the phy mode (dwmac-intel), this is not always a definitive indicator.
For instance, the support of SGMII by XPCS doesn't imply
that all SGMII-supporting PHYs include XPCS. But as Serge mentioned, using pcs-handle,
or pcs-handle-name might be a more effective approach.
> >
> > Besides that, there are a few issues with your submission. If DT is the
> > way to go (and I don't say it is), you would also need to update the
> > bindings to document that property.
> >
> > > The types of has_xpcs and xpcs_an_inband are unsigned int,
> > > and generally used as flags. So it may be more reasonable to set them to
> > > bool type. This can also be confirmed from the type of @ovr_an_inband.
> >
> > And this part would go into a separate patch.
Sorry for this issue, I will create the patch separately later.
> 
> In addition to what Maxime already said having DT-bindings adjusted to
> fit to the pattern implemented in the software part is a wrong way to
> go. The best choice in this case is to add the DW XPCS DT-node to the
> DW MAC MDIO/MI bus and then use the "pcs-handle" to inform the MAC
> (mainly it's driver) of what PCS-device is actually attached to it.
> The series I submitted on this week is exactly about that:
> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20231205103559.9605-1-fancer.lancer at g
> mail.com/__;!!A4F2R9G_pg!Y6R3WZWHeBdrkZklbqrAQARbHnQ-g_Tbb6r5IqcsSHMQ_l4rOzLLgZvLPl6YP
> BYferbjrbjZA6_XvSSSvkV35eo2jWPz$
> I guess I'll need about a month or so to settle all the comments, but
> the solution implemented there will be better than this one really.
>
Yes, I agree that binding the xpcs via the "pcs-handle" DT firmware node 
is a better way. but the current method of binding xpcs through scanning 
addresses still relies on mdio_bus_data->has_xpcs. 
The 16th patch in your patchset also mentions the difficulty of 
obtaining has_xpcs. Therefore, can we add parsing of pcs-handle-names 
in the platform to determine if the xpcs exists, like this:

if (plat->mdio_bus_data) {
	rc = of_property_match_string(np, "pcs-handle-names", "dw-xpcs");
	if (rc >= 0) {
		plat->mdio_bus_data->has_xpcs = true;
		plat->mdio_bus_data->xpcs_an_inband = true;
	}
}

Thanks,
Jiangfeng

> -Serge(y)
> 
> >
> > Thanks,
> >
> > Maxime
> >

From will at kernel.org  Tue Dec 12 02:55:13 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 10:55:13 +0000
Subject: [PATCH v4 0/4] arm64: Run kernel mode NEON with preemption
 enabled
In-Reply-To: <CAMj1kXE=2H_Jqyuv_gDp6QS2g2Vzdgf=fngp=ZXEUBXKOYWnbQ@mail.gmail.com>
References: <20231208113218.3001940-6-ardb@google.com>
 <170231871028.1857077.10318072500676133330.b4-ty@kernel.org>
 <CAMj1kXE=2H_Jqyuv_gDp6QS2g2Vzdgf=fngp=ZXEUBXKOYWnbQ@mail.gmail.com>
Message-ID: <20231212105513.GA28416@willie-the-truck>

On Tue, Dec 12, 2023 at 09:16:13AM +0100, Ard Biesheuvel wrote:
> On Mon, 11 Dec 2023 at 21:27, Will Deacon <will at kernel.org> wrote:
> > [1/4] arm64: fpsimd: Drop unneeded 'busy' flag
> >       https://git.kernel.org/arm64/c/e109130b0e5e
> > [2/4] arm64: fpsimd: Preserve/restore kernel mode NEON at context switch
> >       https://git.kernel.org/arm64/c/1e3a3de1ff6c
> 
> I spotted a typo in the commit log of this patch:
> 
> TIF_USING_KMODE_FPSIMD -> TIF_KERNEL_FPSTATE

Cheers, I'll go in and fix that (so the SHAs will change).

> > [3/4] arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD
> >       https://git.kernel.org/arm64/c/035262623959
> >
> > It would be nice to have an Ack from Herbert on the last one so that
> > he's aware of the possible conflicts.
> >
> > The other thing I tangentially wondered about is what happens now if code
> > calls uaccess routines (e.g. get_user()) within a kernel_neon_{begin,end}
> > section? I think previously the fact that preemption had to be disabled
> > would've caused the might_fault() to explode, but now I suppose the BUG_ON()
> > in kernel_neon_begin() will save us. Is that right?
> >
> 
> Not sure what you mean by 'save us'. Is there anything fundamentally
> wrong with doing user access from a kernel mode NEON region if
> preemption remains enabled?
> 
> The BUG_ON() will only catch uses from hardirq/NMI context, or cases
> where FP/SIMD is not implemented/enabled in the first place so it will
> not trigger on a user access.

As discussed off-list, the vague concern was if kernel_neon_begin() is
nested off the back of a user fault. The BUG_ON() should fire in that case,
so we're all good.

Thanks!

Will


From fancer.lancer at gmail.com  Tue Dec 12 02:59:25 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue, 12 Dec 2023 13:59:25 +0300
Subject: [PATCH net] net: stmmac: Handle disabled MDIO busses from
 devicetree
In-Reply-To: <20231211-b4-stmmac-handle-mdio-enodev-v1-1-73c20c44f8d6@redhat.com>
References: <20231211-b4-stmmac-handle-mdio-enodev-v1-1-73c20c44f8d6@redhat.com>
Message-ID: <ggbqvhdhgl6wmuewqtwtgud7ubx2ypmnb3p6p6w7cy37mnnyxn@2eqd63s2t5ii>

On Mon, Dec 11, 2023 at 03:31:17PM -0600, Andrew Halaney wrote:
> Many hardware configurations have the MDIO bus disabled, and are instead
> using some other MDIO bus to talk to the MAC's phy.
> 
> of_mdiobus_register() returns -ENODEV in this case. Let's handle it
> gracefully instead of failing to probe the MAC.
> 
> Fixes: 47dd7a540b8a (net: add support for STMicroelectronics Ethernet controllers.")
> Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> index fa9e7e7040b9..a39be15d41a8 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> @@ -591,7 +591,13 @@ int stmmac_mdio_register(struct net_device *ndev)
>  	new_bus->parent = priv->device;
>  
>  	err = of_mdiobus_register(new_bus, mdio_node);
> -	if (err != 0) {
> +	if (err) {
> +		if (err == -ENODEV) {
> +			/* The bus is disabled in the devicetree, that's ok */
> +			mdiobus_free(new_bus);
> +			return 0;
> +		}
> +
>  		dev_err_probe(dev, err, "Cannot register the MDIO bus\n");
>  		goto bus_register_fail;
>  	}

This can be implemented a bit simpler, more maintainable and saving
one indentations level:

	err = of_mdiobus_register(new_bus, mdio_node);
	if (err == -ENODEV) {
		err = 0;
		dev_warn(dev, "MDIO bus is disabled\n");
		goto bus_register_fail;
	} else if (err) {
  		dev_err_probe(dev, err, "Cannot register the MDIO bus\n");
  		goto bus_register_fail;
	}

-Serge(y)

> 
> ---
> base-commit: bbd220ce4e29ed55ab079007cff0b550895258eb
> change-id: 20231211-b4-stmmac-handle-mdio-enodev-82168de68c6a
> 
> Best regards,
> -- 
> Andrew Halaney <ahalaney at redhat.com>
> 


From masahiroy at kernel.org  Tue Dec 12 03:00:47 2023
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Tue, 12 Dec 2023 20:00:47 +0900
Subject: [PATCH] arm64: dts: xilinx: Apply overlays to base dtbs
In-Reply-To: <6410439d-cc02-408f-bc8e-3d8e808b8e47@amd.com>
References: <20230911214751.2202913-1-robh@kernel.org> <2eaa2e1d-b6cf-4032-af28-5e8f6428e95f@amd.com>
 <CAL_JsqLUKyNU7vrYhVzdTKKExXN8-Dyy8cEFd6PNW=b03VDOvg@mail.gmail.com> <6410439d-cc02-408f-bc8e-3d8e808b8e47@amd.com>
Message-ID: <CAK7LNAQr09+ei2mBkMBDEFOyx1kx70RScjsh1v-XaKGmDG8RgA@mail.gmail.com>

On Thu, Nov 30, 2023 at 5:01?PM Michal Simek <michal.simek at amd.com> wrote:
>
>
>
> On 11/29/23 17:13, Rob Herring wrote:
> > On Mon, Sep 18, 2023 at 5:56?AM Michal Simek <michal.simek at amd.com> wrote:
> >>
> >>
> >>
> >> On 9/11/23 23:47, Rob Herring wrote:
> >>> DT overlays in tree need to be applied to a base DTB to validate they
> >>> apply, to run schema checks on them, and to catch any errors at compile
> >>> time. Defining the "-dtbs" variable is not enough as the combined DT must
> >>> be added to dtbs-y.
> >>>
> >>> zynqmp-sck-kr-g-revA.dtso and zynqmp-sck-kr-g-revB.dtso don't exist, so drop
> >>> them.
> >>>
> >>> Signed-off-by: Rob Herring <robh at kernel.org>
> >>> ---
> >>>    arch/arm64/boot/dts/xilinx/Makefile | 9 ++++-----
> >>>    1 file changed, 4 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/xilinx/Makefile b/arch/arm64/boot/dts/xilinx/Makefile
> >>> index 5e40c0b4fa0a..1068b0fa8e98 100644
> >>> --- a/arch/arm64/boot/dts/xilinx/Makefile
> >>> +++ b/arch/arm64/boot/dts/xilinx/Makefile
> >>> @@ -22,11 +22,10 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-sm-k26-revA.dtb
> >>>    dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-smk-k26-revA.dtb
> >>>
> >>>    zynqmp-sm-k26-revA-sck-kv-g-revA-dtbs := zynqmp-sm-k26-revA.dtb zynqmp-sck-kv-g-revA.dtbo
> >>> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-sm-k26-revA-sck-kv-g-revA.dtb
> >>>    zynqmp-sm-k26-revA-sck-kv-g-revB-dtbs := zynqmp-sm-k26-revA.dtb zynqmp-sck-kv-g-revB.dtbo
> >>> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-sm-k26-revA-sck-kv-g-revB.dtb
> >>>    zynqmp-smk-k26-revA-sck-kv-g-revA-dtbs := zynqmp-smk-k26-revA.dtb zynqmp-sck-kv-g-revA.dtbo
> >>> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-smk-k26-revA-sck-kv-g-revA.dtb
> >>>    zynqmp-smk-k26-revA-sck-kv-g-revB-dtbs := zynqmp-smk-k26-revA.dtb zynqmp-sck-kv-g-revB.dtbo
> >>> -
> >>> -zynqmp-sm-k26-revA-sck-kr-g-revA-dtbs := zynqmp-sm-k26-revA.dtb zynqmp-sck-kr-g-revA.dtbo
> >>> -zynqmp-sm-k26-revA-sck-kr-g-revB-dtbs := zynqmp-sm-k26-revA.dtb zynqmp-sck-kr-g-revB.dtbo
> >>> -zynqmp-smk-k26-revA-sck-kr-g-revA-dtbs := zynqmp-smk-k26-revA.dtb zynqmp-sck-kr-g-revA.dtbo
> >>> -zynqmp-smk-k26-revA-sck-kr-g-revB-dtbs := zynqmp-smk-k26-revA.dtb zynqmp-sck-kr-g-revB.dtbo
> >>> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-smk-k26-revA-sck-kv-g-revB.dtb
> >>
> >> Applied.
> >
> > Why is this in next still, but not in Linus' tree?
>
> I was OOO and didn't send pull request to Arnd. I will do it for 6.8. It means
> in 2-3 weeks from now.
>
> Thanks,
> Michal
>


This is a regression by 45fe0dc4ea2e.



Fixes: 45fe0dc4ea2e ("arm64: xilinx: Use zynqmp prefix for SOM dt overlays")


is suitable.






-- 
Best Regards
Masahiro Yamada


From s-vadapalli at ti.com  Tue Dec 12 03:10:10 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Tue, 12 Dec 2023 16:40:10 +0530
Subject: [PATCH v2 3/4] dmaengine: ti: k3-udma-glue: Add function to request TX channel by ID
In-Reply-To: <20231212111011.1401641-1-s-vadapalli@ti.com>
References: <20231212111011.1401641-1-s-vadapalli@ti.com>
Message-ID: <20231212111011.1401641-4-s-vadapalli@ti.com>

The existing function k3_udma_glue_request_tx_chn() supports requesting
a TX DMA channel by its name. Add support to request TX channel by ID in
the form of a new function k3_udma_glue_request_tx_chn_by_id() and export
it for use by drivers which are probed by alternate methods (non
device-tree) but still wish to make use of the existing DMA APIs. Such
drivers could be informed about the TX channel to use by RPMsg for example.

Since the implementation of k3_udma_glue_request_tx_chn_by_id() reuses
most of the code in k3_udma_glue_request_tx_chn(), create a new function
for the common code named as k3_udma_glue_request_tx_chn_common().

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---
Changes since v1:
- Updated commit message indicating the use-case for which the patch is
  being added.

 drivers/dma/ti/k3-udma-glue.c    | 101 +++++++++++++++++++++++--------
 include/linux/dma/k3-udma-glue.h |   4 ++
 2 files changed, 79 insertions(+), 26 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index eff1ae3d3efe..ea5119a5e8eb 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -274,29 +274,13 @@ static int k3_udma_glue_cfg_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
 	return tisci_rm->tisci_udmap_ops->tx_ch_cfg(tisci_rm->tisci, &req);
 }
 
-struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
-		const char *name, struct k3_udma_glue_tx_channel_cfg *cfg)
+static int
+k3_udma_glue_request_tx_chn_common(struct device *dev,
+				   struct k3_udma_glue_tx_channel *tx_chn,
+				   struct k3_udma_glue_tx_channel_cfg *cfg)
 {
-	struct k3_udma_glue_tx_channel *tx_chn;
 	int ret;
 
-	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
-	if (!tx_chn)
-		return ERR_PTR(-ENOMEM);
-
-	tx_chn->common.dev = dev;
-	tx_chn->common.swdata_size = cfg->swdata_size;
-	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
-	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
-	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
-	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
-
-	/* parse of udmap channel */
-	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
-					&tx_chn->common, true);
-	if (ret)
-		goto err;
-
 	tx_chn->common.hdesc_size = cppi5_hdesc_calc_size(tx_chn->common.epib,
 						tx_chn->common.psdata_size,
 						tx_chn->common.swdata_size);
@@ -312,7 +296,7 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 	if (IS_ERR(tx_chn->udma_tchanx)) {
 		ret = PTR_ERR(tx_chn->udma_tchanx);
 		dev_err(dev, "UDMAX tchanx get err %d\n", ret);
-		goto err;
+		return ret;
 	}
 	tx_chn->udma_tchan_id = xudma_tchan_get_id(tx_chn->udma_tchanx);
 
@@ -325,7 +309,7 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 		dev_err(dev, "Channel Device registration failed %d\n", ret);
 		put_device(&tx_chn->common.chan_dev);
 		tx_chn->common.chan_dev.parent = NULL;
-		goto err;
+		return ret;
 	}
 
 	if (xudma_is_pktdma(tx_chn->common.udmax)) {
@@ -349,7 +333,7 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 					     &tx_chn->ringtxcq);
 	if (ret) {
 		dev_err(dev, "Failed to get TX/TXCQ rings %d\n", ret);
-		goto err;
+		return ret;
 	}
 
 	/* Set the dma_dev for the rings to be configured */
@@ -365,13 +349,13 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 	ret = k3_ringacc_ring_cfg(tx_chn->ringtx, &cfg->tx_cfg);
 	if (ret) {
 		dev_err(dev, "Failed to cfg ringtx %d\n", ret);
-		goto err;
+		return ret;
 	}
 
 	ret = k3_ringacc_ring_cfg(tx_chn->ringtxcq, &cfg->txcq_cfg);
 	if (ret) {
 		dev_err(dev, "Failed to cfg ringtx %d\n", ret);
-		goto err;
+		return ret;
 	}
 
 	/* request and cfg psi-l */
@@ -382,11 +366,42 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 	ret = k3_udma_glue_cfg_tx_chn(tx_chn);
 	if (ret) {
 		dev_err(dev, "Failed to cfg tchan %d\n", ret);
-		goto err;
+		return ret;
 	}
 
 	k3_udma_glue_dump_tx_chn(tx_chn);
 
+	return 0;
+}
+
+struct k3_udma_glue_tx_channel *
+k3_udma_glue_request_tx_chn(struct device *dev, const char *name,
+			    struct k3_udma_glue_tx_channel_cfg *cfg)
+{
+	struct k3_udma_glue_tx_channel *tx_chn;
+	int ret;
+
+	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
+	if (!tx_chn)
+		return ERR_PTR(-ENOMEM);
+
+	tx_chn->common.dev = dev;
+	tx_chn->common.swdata_size = cfg->swdata_size;
+	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
+	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
+	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
+	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
+
+	/* parse of udmap channel */
+	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
+					&tx_chn->common, true);
+	if (ret)
+		goto err;
+
+	ret = k3_udma_glue_request_tx_chn_common(dev, tx_chn, cfg);
+	if (ret)
+		goto err;
+
 	return tx_chn;
 
 err:
@@ -395,6 +410,40 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn);
 
+struct k3_udma_glue_tx_channel *
+k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg,
+				  struct device_node *udmax_np, u32 thread_id)
+{
+	struct k3_udma_glue_tx_channel *tx_chn;
+	int ret;
+
+	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
+	if (!tx_chn)
+		return ERR_PTR(-ENOMEM);
+
+	tx_chn->common.dev = dev;
+	tx_chn->common.swdata_size = cfg->swdata_size;
+	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
+	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
+	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
+	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
+
+	ret = of_k3_udma_glue_parse_chn_by_id(udmax_np, &tx_chn->common, true, thread_id);
+	if (ret)
+		goto err;
+
+	ret = k3_udma_glue_request_tx_chn_common(dev, tx_chn, cfg);
+	if (ret)
+		goto err;
+
+	return tx_chn;
+
+err:
+	k3_udma_glue_release_tx_chn(tx_chn);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn_by_id);
+
 void k3_udma_glue_release_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
 {
 	if (tx_chn->psil_paired) {
diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h
index e443be4d3b4b..6205d84430ca 100644
--- a/include/linux/dma/k3-udma-glue.h
+++ b/include/linux/dma/k3-udma-glue.h
@@ -26,6 +26,10 @@ struct k3_udma_glue_tx_channel;
 struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 		const char *name, struct k3_udma_glue_tx_channel_cfg *cfg);
 
+struct k3_udma_glue_tx_channel *
+k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg,
+				  struct device_node *udmax_np, u32 thread_id);
+
 void k3_udma_glue_release_tx_chn(struct k3_udma_glue_tx_channel *tx_chn);
 int k3_udma_glue_push_tx_chn(struct k3_udma_glue_tx_channel *tx_chn,
 			     struct cppi5_host_desc_t *desc_tx,
-- 
2.34.1



From s-vadapalli at ti.com  Tue Dec 12 03:10:11 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Tue, 12 Dec 2023 16:40:11 +0530
Subject: [PATCH v2 4/4] dmaengine: ti: k3-udma-glue: Add function to request RX channel by ID
In-Reply-To: <20231212111011.1401641-1-s-vadapalli@ti.com>
References: <20231212111011.1401641-1-s-vadapalli@ti.com>
Message-ID: <20231212111011.1401641-5-s-vadapalli@ti.com>

The existing function k3_udma_glue_request_remote_rx_chn() supports
requesting an RX DMA channel and flow by the name of the RX DMA channel.
Add support to request RX channel by ID in the form of a new function
k3_udma_glue_request_remote_rx_chn_by_id() and export it for use by drivers
which are probed by alternate methods (non device-tree) but still wish to
make use of the existing DMA APIs. Such drivers could be informed about the
RX channel to use by RPMsg for example.

Since the implementation of k3_udma_glue_request_remote_rx_chn_by_id()
reuses most of the code in k3_udma_glue_request_remote_rx_chn(), create
a new function k3_udma_glue_request_remote_rx_chn_common() for the
common code.

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---
Changes since v1:
- Updated commit message indicating the use-case for which the patch is
  being added.

 drivers/dma/ti/k3-udma-glue.c    | 136 ++++++++++++++++++++++---------
 include/linux/dma/k3-udma-glue.h |   4 +
 2 files changed, 101 insertions(+), 39 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index ea5119a5e8eb..996614b60675 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -1072,52 +1072,21 @@ k3_udma_glue_request_rx_chn_priv(struct device *dev, const char *name,
 	return ERR_PTR(ret);
 }
 
-static struct k3_udma_glue_rx_channel *
-k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
-				   struct k3_udma_glue_rx_channel_cfg *cfg)
+static int
+k3_udma_glue_request_remote_rx_chn_common(struct k3_udma_glue_rx_channel *rx_chn,
+					  struct k3_udma_glue_rx_channel_cfg *cfg,
+					  struct device *dev)
 {
-	struct k3_udma_glue_rx_channel *rx_chn;
 	int ret, i;
 
-	if (cfg->flow_id_num <= 0 ||
-	    cfg->flow_id_use_rxchan_id ||
-	    cfg->def_flow_cfg ||
-	    cfg->flow_id_base < 0)
-		return ERR_PTR(-EINVAL);
-
-	/*
-	 * Remote RX channel is under control of Remote CPU core, so
-	 * Linux can only request and manipulate by dedicated RX flows
-	 */
-
-	rx_chn = devm_kzalloc(dev, sizeof(*rx_chn), GFP_KERNEL);
-	if (!rx_chn)
-		return ERR_PTR(-ENOMEM);
-
-	rx_chn->common.dev = dev;
-	rx_chn->common.swdata_size = cfg->swdata_size;
-	rx_chn->remote = true;
-	rx_chn->udma_rchan_id = -1;
-	rx_chn->flow_num = cfg->flow_id_num;
-	rx_chn->flow_id_base = cfg->flow_id_base;
-	rx_chn->psil_paired = false;
-
-	/* parse of udmap channel */
-	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
-					&rx_chn->common, false);
-	if (ret)
-		goto err;
-
 	rx_chn->common.hdesc_size = cppi5_hdesc_calc_size(rx_chn->common.epib,
 						rx_chn->common.psdata_size,
 						rx_chn->common.swdata_size);
 
 	rx_chn->flows = devm_kcalloc(dev, rx_chn->flow_num,
 				     sizeof(*rx_chn->flows), GFP_KERNEL);
-	if (!rx_chn->flows) {
-		ret = -ENOMEM;
-		goto err;
-	}
+	if (!rx_chn->flows)
+		return -ENOMEM;
 
 	rx_chn->common.chan_dev.class = &k3_udma_glue_devclass;
 	rx_chn->common.chan_dev.parent = xudma_get_device(rx_chn->common.udmax);
@@ -1128,7 +1097,7 @@ k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
 		dev_err(dev, "Channel Device registration failed %d\n", ret);
 		put_device(&rx_chn->common.chan_dev);
 		rx_chn->common.chan_dev.parent = NULL;
-		goto err;
+		return ret;
 	}
 
 	if (xudma_is_pktdma(rx_chn->common.udmax)) {
@@ -1140,19 +1109,108 @@ k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
 
 	ret = k3_udma_glue_allocate_rx_flows(rx_chn, cfg);
 	if (ret)
-		goto err;
+		return ret;
 
 	for (i = 0; i < rx_chn->flow_num; i++)
 		rx_chn->flows[i].udma_rflow_id = rx_chn->flow_id_base + i;
 
 	k3_udma_glue_dump_rx_chn(rx_chn);
 
+	return 0;
+}
+
+static struct k3_udma_glue_rx_channel *
+k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
+				   struct k3_udma_glue_rx_channel_cfg *cfg)
+{
+	struct k3_udma_glue_rx_channel *rx_chn;
+	int ret;
+
+	if (cfg->flow_id_num <= 0 ||
+	    cfg->flow_id_use_rxchan_id ||
+	    cfg->def_flow_cfg ||
+	    cfg->flow_id_base < 0)
+		return ERR_PTR(-EINVAL);
+
+	/*
+	 * Remote RX channel is under control of Remote CPU core, so
+	 * Linux can only request and manipulate by dedicated RX flows
+	 */
+
+	rx_chn = devm_kzalloc(dev, sizeof(*rx_chn), GFP_KERNEL);
+	if (!rx_chn)
+		return ERR_PTR(-ENOMEM);
+
+	rx_chn->common.dev = dev;
+	rx_chn->common.swdata_size = cfg->swdata_size;
+	rx_chn->remote = true;
+	rx_chn->udma_rchan_id = -1;
+	rx_chn->flow_num = cfg->flow_id_num;
+	rx_chn->flow_id_base = cfg->flow_id_base;
+	rx_chn->psil_paired = false;
+
+	/* parse of udmap channel */
+	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
+					&rx_chn->common, false);
+	if (ret)
+		goto err;
+
+	ret = k3_udma_glue_request_remote_rx_chn_common(rx_chn, cfg, dev);
+	if (ret)
+		goto err;
+
+	return rx_chn;
+
+err:
+	k3_udma_glue_release_rx_chn(rx_chn);
+	return ERR_PTR(ret);
+}
+
+struct k3_udma_glue_rx_channel *
+k3_udma_glue_request_remote_rx_chn_by_id(struct device *dev, struct device_node *udmax_np,
+					 struct k3_udma_glue_rx_channel_cfg *cfg, u32 thread_id)
+{
+	struct k3_udma_glue_rx_channel *rx_chn;
+	int ret;
+
+	if (cfg->flow_id_num <= 0 ||
+	    cfg->flow_id_use_rxchan_id ||
+	    cfg->def_flow_cfg ||
+	    cfg->flow_id_base < 0)
+		return ERR_PTR(-EINVAL);
+
+	/*
+	 * Remote RX channel is under control of Remote CPU core, so
+	 * Linux can only request and manipulate by dedicated RX flows
+	 */
+
+	rx_chn = devm_kzalloc(dev, sizeof(*rx_chn), GFP_KERNEL);
+	if (!rx_chn)
+		return ERR_PTR(-ENOMEM);
+
+	rx_chn->common.dev = dev;
+	rx_chn->common.swdata_size = cfg->swdata_size;
+	rx_chn->remote = true;
+	rx_chn->udma_rchan_id = -1;
+	rx_chn->flow_num = cfg->flow_id_num;
+	rx_chn->flow_id_base = cfg->flow_id_base;
+	rx_chn->psil_paired = false;
+
+	ret = of_k3_udma_glue_parse_chn_by_id(udmax_np, &rx_chn->common, false, thread_id);
+	if (ret)
+		goto err;
+
+	ret = k3_udma_glue_request_remote_rx_chn_common(rx_chn, cfg, dev);
+	if (ret)
+		goto err;
+
 	return rx_chn;
 
 err:
 	k3_udma_glue_release_rx_chn(rx_chn);
 	return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(k3_udma_glue_request_remote_rx_chn_by_id);
 
 struct k3_udma_glue_rx_channel *
 k3_udma_glue_request_rx_chn(struct device *dev, const char *name,
diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h
index 6205d84430ca..89dc59d7c5e2 100644
--- a/include/linux/dma/k3-udma-glue.h
+++ b/include/linux/dma/k3-udma-glue.h
@@ -113,6 +113,10 @@ struct k3_udma_glue_rx_channel *k3_udma_glue_request_rx_chn(
 		const char *name,
 		struct k3_udma_glue_rx_channel_cfg *cfg);
 
+struct k3_udma_glue_rx_channel *
+k3_udma_glue_request_remote_rx_chn_by_id(struct device *dev, struct device_node *udmax_np,
+					 struct k3_udma_glue_rx_channel_cfg *cfg, u32 thread_id);
+
 void k3_udma_glue_release_rx_chn(struct k3_udma_glue_rx_channel *rx_chn);
 int k3_udma_glue_enable_rx_chn(struct k3_udma_glue_rx_channel *rx_chn);
 void k3_udma_glue_disable_rx_chn(struct k3_udma_glue_rx_channel *rx_chn);
-- 
2.34.1



From s-vadapalli at ti.com  Tue Dec 12 03:10:09 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Tue, 12 Dec 2023 16:40:09 +0530
Subject: [PATCH v2 2/4] dmaengine: ti: k3-udma-glue: Update name for remote RX channel device
In-Reply-To: <20231212111011.1401641-1-s-vadapalli@ti.com>
References: <20231212111011.1401641-1-s-vadapalli@ti.com>
Message-ID: <20231212111011.1401641-3-s-vadapalli@ti.com>

A single RX Channel can have multiple flows. It is possible that a
single device requests multiple flows on the same RX Channel. In such
cases, the existing implementation of naming the device on the basis of
the RX Channel can result in duplicate names. The existing implementation
only uses the RX Channel source thread when naming, which implies duplicate
names when different flows are being requested on the same RX Channel.

In order to avoid duplicate names, include the RX flow as well in the name.

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---
 drivers/dma/ti/k3-udma-glue.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index d8781625034b..eff1ae3d3efe 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -1072,8 +1072,8 @@ k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
 
 	rx_chn->common.chan_dev.class = &k3_udma_glue_devclass;
 	rx_chn->common.chan_dev.parent = xudma_get_device(rx_chn->common.udmax);
-	dev_set_name(&rx_chn->common.chan_dev, "rchan_remote-0x%04x",
-		     rx_chn->common.src_thread);
+	dev_set_name(&rx_chn->common.chan_dev, "rchan_remote-0x%04x-0x%02x",
+		     rx_chn->common.src_thread, rx_chn->flow_id_base);
 	ret = device_register(&rx_chn->common.chan_dev);
 	if (ret) {
 		dev_err(dev, "Channel Device registration failed %d\n", ret);
-- 
2.34.1



From s-vadapalli at ti.com  Tue Dec 12 03:10:08 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Tue, 12 Dec 2023 16:40:08 +0530
Subject: [PATCH v2 1/4] dmaengine: ti: k3-udma-glue: Add function to parse channel by ID
In-Reply-To: <20231212111011.1401641-1-s-vadapalli@ti.com>
References: <20231212111011.1401641-1-s-vadapalli@ti.com>
Message-ID: <20231212111011.1401641-2-s-vadapalli@ti.com>

The existing helper function of_k3_udma_glue_parse() fetches the DMA
Channel thread ID from the device-tree node. This makes it necessary to
have a device-tree node with the Channel thread IDs populated. However,
in the case where the thread ID is known by alternate methods (an
example being that of Firmware running on remote core sharing details of
the thread IDs), there is no equivalent function to implement the
functionality of the existing of_k3_udma_glue_parse() function. In such
cases, the driver utilizing the DMA APIs might not even have a
device-tree node to begin with, since it could be probed with other
methods (RPMsg-Bus for example).

Add the of_k3_udma_glue_parse_chn_by_id() helper function which accepts
the thread ID as an argument, thereby making it unnecessary to have a
device-tree node for obtaining the thread ID.

Since of_k3_udma_glue_parse() and of_k3_udma_glue_parse_chn_by_id()
share a lot of code in common, create a new function to handle the
common code which is named as of_k3_udma_glue_parse_chn_common().

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---
Changes since v1:
- Updated commit message indicating that this patch is helpful for cases
  where the driver utilizing the DMA APIs might not be probed by a
  device-tree node.
- Removed unnecessary return value check within
  "of_k3_udma_glue_parse_chn()" function since it will fall through to
  "out_put_spec" anyway.
- Removed unnecessary return value check within
  "of_k3_udma_glue_parse_chn_by_id()" function since it will fall through
  to "out_put_spec" anyway.

 drivers/dma/ti/k3-udma-glue.c | 79 ++++++++++++++++++++++-------------
 1 file changed, 51 insertions(+), 28 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index c278d5facf7d..d8781625034b 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -111,6 +111,35 @@ static int of_k3_udma_glue_parse(struct device_node *udmax_np,
 	return 0;
 }
 
+static int of_k3_udma_glue_parse_chn_common(struct k3_udma_glue_common *common, u32 thread_id,
+					    bool tx_chn)
+{
+	if (tx_chn && !(thread_id & K3_PSIL_DST_THREAD_ID_OFFSET))
+		return -EINVAL;
+
+	if (!tx_chn && (thread_id & K3_PSIL_DST_THREAD_ID_OFFSET))
+		return -EINVAL;
+
+	/* get psil endpoint config */
+	common->ep_config = psil_get_ep_config(thread_id);
+	if (IS_ERR(common->ep_config)) {
+		dev_err(common->dev,
+			"No configuration for psi-l thread 0x%04x\n",
+			thread_id);
+		return PTR_ERR(common->ep_config);
+	}
+
+	common->epib = common->ep_config->needs_epib;
+	common->psdata_size = common->ep_config->psd_size;
+
+	if (tx_chn)
+		common->dst_thread = thread_id;
+	else
+		common->src_thread = thread_id;
+
+	return 0;
+}
+
 static int of_k3_udma_glue_parse_chn(struct device_node *chn_np,
 		const char *name, struct k3_udma_glue_common *common,
 		bool tx_chn)
@@ -153,38 +182,32 @@ static int of_k3_udma_glue_parse_chn(struct device_node *chn_np,
 		common->atype_asel = dma_spec.args[1];
 	}
 
-	if (tx_chn && !(thread_id & K3_PSIL_DST_THREAD_ID_OFFSET)) {
-		ret = -EINVAL;
-		goto out_put_spec;
-	}
-
-	if (!tx_chn && (thread_id & K3_PSIL_DST_THREAD_ID_OFFSET)) {
-		ret = -EINVAL;
-		goto out_put_spec;
-	}
-
-	/* get psil endpoint config */
-	common->ep_config = psil_get_ep_config(thread_id);
-	if (IS_ERR(common->ep_config)) {
-		dev_err(common->dev,
-			"No configuration for psi-l thread 0x%04x\n",
-			thread_id);
-		ret = PTR_ERR(common->ep_config);
-		goto out_put_spec;
-	}
-
-	common->epib = common->ep_config->needs_epib;
-	common->psdata_size = common->ep_config->psd_size;
-
-	if (tx_chn)
-		common->dst_thread = thread_id;
-	else
-		common->src_thread = thread_id;
+	ret = of_k3_udma_glue_parse_chn_common(common, thread_id, tx_chn);
 
 out_put_spec:
 	of_node_put(dma_spec.np);
 	return ret;
-};
+}
+
+static int
+of_k3_udma_glue_parse_chn_by_id(struct device_node *udmax_np, struct k3_udma_glue_common *common,
+				bool tx_chn, u32 thread_id)
+{
+	int ret = 0;
+
+	if (unlikely(!udmax_np))
+		return -EINVAL;
+
+	ret = of_k3_udma_glue_parse(udmax_np, common);
+	if (ret)
+		goto out_put_spec;
+
+	ret = of_k3_udma_glue_parse_chn_common(common, thread_id, tx_chn);
+
+out_put_spec:
+	of_node_put(udmax_np);
+	return ret;
+}
 
 static void k3_udma_glue_dump_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
 {
-- 
2.34.1



From s-vadapalli at ti.com  Tue Dec 12 03:10:07 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Tue, 12 Dec 2023 16:40:07 +0530
Subject: [PATCH v2 0/4] Add APIs to request TX/RX DMA channels by ID
Message-ID: <20231212111011.1401641-1-s-vadapalli@ti.com>

The existing APIs for requesting TX and RX DMA channels rely on parsing
a device-tree node to obtain the Channel/Thread IDs from their names.
However, it is possible to know the thread IDs by alternative means such
as being informed by Firmware on a remote core via RPMsg regarding the
allocated TX/RX DMA channel IDs. In such cases, the driver can be probed
by non device-tree methods such as RPMsg-bus, due to which it is not
necessary that the device using the DMA has a device-tree node
corresponding to it. Thus, add APIs to enable the driver to make use of
the existing DMA APIs even when there's no device-tree node.

Additionally, since the name of the device for the remote RX channel is
being set purely on the basis of the RX channel ID itself, it can result
in duplicate names when multiple flows are used on the same channel.
Avoid name duplication by including the flow in the name.

Series is based on linux-next tagged next-20231212.

v1:
https://lore.kernel.org/r/20231114083906.3143548-1-s-vadapalli at ti.com/
Changes since v1:
- Rebased series on linux-next tagged next-20231212.
- Updated commit messages with details regarding the use-case for which
  the newly added APIs will be required.
- Removed unnecessary return value check within
  "of_k3_udma_glue_parse_chn()" function in patch 1, since it will fall
  through to "out_put_spec" anyway.
- Removed unnecessary return value check within
  "of_k3_udma_glue_parse_chn_by_id()" function in patch 1, since it will
  fall through to "out_put_spec" anyway.
- Moved patch 4 of v1 series to patch 2 of current series.

RFC Series:
https://lore.kernel.org/r/20231111121555.2656760-1-s-vadapalli at ti.com/
Changes since RFC Series:
- Rebased patches 1, 2 and 3 on linux-next tagged next-20231114.
- Added patch 4 to the series.

Siddharth Vadapalli (4):
  dmaengine: ti: k3-udma-glue: Add function to parse channel by ID
  dmaengine: ti: k3-udma-glue: Update name for remote RX channel device
  dmaengine: ti: k3-udma-glue: Add function to request TX channel by ID
  dmaengine: ti: k3-udma-glue: Add function to request RX channel by ID

 drivers/dma/ti/k3-udma-glue.c    | 304 ++++++++++++++++++++++---------
 include/linux/dma/k3-udma-glue.h |   8 +
 2 files changed, 225 insertions(+), 87 deletions(-)

-- 
2.34.1



From vigneshr at ti.com  Tue Dec 12 03:16:31 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Tue, 12 Dec 2023 16:46:31 +0530
Subject: [PATCH 0/3] arm64: dts: ti: k3: Add additioal regs for DMA components
Message-ID: <20231212111634.3515175-1-vigneshr@ti.com>

This adds additional reg ranges which are not directly used by Linux but
by other components like U-Boot

Binding is accepted via dmaengine tree and is in linux-next[0]

[0] https://lore.kernel.org/dmaengine/170083278148.771517.1841889156174413563.b4-ty at kernel.org/


Manorit Chawdhry (2):
  arm64: dts: ti: k3-am65: Add additional regs for DMA components
  arm64: dts: ti: k3-j7*: Add additional regs for DMA components

Vignesh Raghavendra (1):
  arm64: dts: ti: k3-am6*: Add additional regs for DMA components

 arch/arm64/boot/dts/ti/k3-am62-main.dtsi       | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi      | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am62p-main.dtsi      | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi       | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi       |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi        |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi      |  8 ++++++--
 .../arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi      |  8 ++++++--
 .../arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi     |  8 ++++++--
 .../boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi      |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi     |  8 ++++++--
 .../boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi      |  8 ++++++--
 14 files changed, 116 insertions(+), 36 deletions(-)

-- 
2.43.0



From vigneshr at ti.com  Tue Dec 12 03:16:32 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Tue, 12 Dec 2023 16:46:32 +0530
Subject: [PATCH 1/3] arm64: dts: ti: k3-am65: Add additional regs for DMA components
In-Reply-To: <20231212111634.3515175-1-vigneshr@ti.com>
References: <20231212111634.3515175-1-vigneshr@ti.com>
Message-ID: <20231212111634.3515175-2-vigneshr@ti.com>

From: Manorit Chawdhry <m-chawdhry at ti.com>

Add additional reg properties for UDMA and RingAcc nodes which are
mostly used by bootloader components before Device Manager firmware
services are available, in order to setup DMA transfers.

Signed-off-by: Manorit Chawdhry <m-chawdhry at ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi  | 8 ++++++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 5ebb87f467de..2033a8ec89d6 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -790,8 +790,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,am654-navss-main-udmap";
 			reg = <0x0 0x31150000 0x0 0x100>,
 			      <0x0 0x34000000 0x0 0x100000>,
-			      <0x0 0x35000000 0x0 0x100000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x35000000 0x0 0x100000>,
+			      <0x0 0x30b00000 0x0 0x20000>,
+			      <0x0 0x30c00000 0x0 0x8000>,
+			      <0x0 0x30d00000 0x0 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_udmass>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index edd5cfbec40e..ecd7356f3315 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -214,8 +214,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,am654-navss-mcu-udmap";
 			reg = <0x0 0x285c0000 0x0 0x100>,
 			      <0x0 0x2a800000 0x0 0x40000>,
-			      <0x0 0x2aa00000 0x0 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x2aa00000 0x0 0x40000>,
+			      <0x0 0x284a0000 0x0 0x4000>,
+			      <0x0 0x284c0000 0x0 0x4000>,
+			      <0x0 0x28400000 0x0 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_udmass>;
 			#dma-cells = <1>;
 
-- 
2.43.0



From vigneshr at ti.com  Tue Dec 12 03:16:33 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Tue, 12 Dec 2023 16:46:33 +0530
Subject: [PATCH 2/3] arm64: dts: ti: k3-j7*: Add additional regs for DMA components
In-Reply-To: <20231212111634.3515175-1-vigneshr@ti.com>
References: <20231212111634.3515175-1-vigneshr@ti.com>
Message-ID: <20231212111634.3515175-3-vigneshr@ti.com>

From: Manorit Chawdhry <m-chawdhry at ti.com>

Add additional reg properties for UDMA and RingAcc nodes which are
mostly used by bootloader components before Device Manager firmware
services are available, in order to setup DMA transfers.

Signed-off-by: Manorit Chawdhry <m-chawdhry at ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi        | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi  | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi        | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi  | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi       | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi       | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi | 8 ++++++--
 8 files changed, 48 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 264913f83287..97b90f4d09dd 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -281,8 +281,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,j721e-navss-main-udmap";
 			reg = <0x00 0x31150000 0x00 0x100>,
 			      <0x00 0x34000000 0x00 0x100000>,
-			      <0x00 0x35000000 0x00 0x100000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x00 0x35000000 0x00 0x100000>,
+			      <0x00 0x30b00000 0x00 0x20000>,
+			      <0x00 0x30c00000 0x00 0x8000>,
+			      <0x00 0x30d00000 0x00 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index 3fc588b848c6..576ed7494521 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -346,8 +346,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,j721e-navss-mcu-udmap";
 			reg = <0x00 0x285c0000 0x00 0x100>,
 			      <0x00 0x2a800000 0x00 0x40000>,
-			      <0x00 0x2aa00000 0x00 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x00 0x2aa00000 0x00 0x40000>,
+			      <0x00 0x284a0000 0x00 0x4000>,
+			      <0x00 0x284c0000 0x00 0x4000>,
+			      <0x00 0x28400000 0x00 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 746b9f8b1c64..f1e995d12d74 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -382,8 +382,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,j721e-navss-main-udmap";
 			reg = <0x0 0x31150000 0x0 0x100>,
 			      <0x0 0x34000000 0x0 0x100000>,
-			      <0x0 0x35000000 0x0 0x100000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x35000000 0x0 0x100000>,
+			      <0x0 0x30b00000 0x0 0x20000>,
+			      <0x0 0x30c00000 0x0 0x8000>,
+			      <0x0 0x30d00000 0x0 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index f7ab7719fc07..011d93e32238 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -468,8 +468,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,j721e-navss-mcu-udmap";
 			reg = <0x0 0x285c0000 0x0 0x100>,
 			      <0x0 0x2a800000 0x0 0x40000>,
-			      <0x0 0x2aa00000 0x0 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x2aa00000 0x0 0x40000>,
+			      <0x0 0x284a0000 0x0 0x4000>,
+			      <0x0 0x284c0000 0x0 0x4000>,
+			      <0x0 0x28400000 0x0 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index b03731b53a26..2ed469d36f1d 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -1086,8 +1086,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,j721e-navss-main-udmap";
 			reg = <0x0 0x31150000 0x0 0x100>,
 			      <0x0 0x34000000 0x0 0x80000>,
-			      <0x0 0x35000000 0x0 0x200000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x35000000 0x0 0x200000>,
+			      <0x0 0x30b00000 0x0 0x8000>,
+			      <0x0 0x30c00000 0x0 0x20000>,
+			      <0x0 0x30d00000 0x0 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
index 7254f3bd3634..75c6931480dd 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
@@ -471,8 +471,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,j721e-navss-mcu-udmap";
 			reg = <0x0 0x285c0000 0x0 0x100>,
 			      <0x0 0x2a800000 0x0 0x40000>,
-			      <0x0 0x2aa00000 0x0 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x2aa00000 0x0 0x40000>,
+			      <0x0 0x284a0000 0x0 0x4000>,
+			      <0x0 0x284c0000 0x0 0x4000>,
+			      <0x0 0x28400000 0x0 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index d89bcddcfe3d..827328450f96 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -1188,8 +1188,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,j721e-navss-main-udmap";
 			reg = <0x00 0x31150000 0x00 0x100>,
 			      <0x00 0x34000000 0x00 0x80000>,
-			      <0x00 0x35000000 0x00 0x200000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x00 0x35000000 0x00 0x200000>,
+			      <0x00 0x30b00000 0x00 0x20000>,
+			      <0x00 0x30c00000 0x00 0x8000>,
+			      <0x00 0x30d00000 0x00 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
index adb5ea6b9732..0eebb92e6a72 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
@@ -478,8 +478,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,j721e-navss-mcu-udmap";
 			reg = <0x00 0x285c0000 0x00 0x100>,
 			      <0x00 0x2a800000 0x00 0x40000>,
-			      <0x00 0x2aa00000 0x00 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x00 0x2aa00000 0x00 0x40000>,
+			      <0x00 0x284a0000 0x00 0x4000>,
+			      <0x00 0x284c0000 0x00 0x4000>,
+			      <0x00 0x28400000 0x00 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
-- 
2.43.0



From vigneshr at ti.com  Tue Dec 12 03:16:34 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Tue, 12 Dec 2023 16:46:34 +0530
Subject: [PATCH 3/3] arm64: dts: ti: k3-am6*: Add additional regs for DMA components
In-Reply-To: <20231212111634.3515175-1-vigneshr@ti.com>
References: <20231212111634.3515175-1-vigneshr@ti.com>
Message-ID: <20231212111634.3515175-4-vigneshr@ti.com>

Add additional reg properties for BCDMA and PKTDMA nodes which are
mostly used by bootloader components before Device Manager firmware
services are available, in order to setup DMA transfers.

Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi  | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi  | 18 ++++++++++++++----
 4 files changed, 56 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index e5c64c86d1d5..4514a140ad38 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -121,8 +121,13 @@ main_bcdma: dma-controller at 485c0100 {
 			      <0x00 0x4c000000 0x00 0x20000>,
 			      <0x00 0x4a820000 0x00 0x20000>,
 			      <0x00 0x4aa40000 0x00 0x20000>,
-			      <0x00 0x4bc00000 0x00 0x100000>;
-			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4bc00000 0x00 0x100000>,
+			      <0x00 0x48600000 0x00 0x8000>,
+			      <0x00 0x484a4000 0x00 0x2000>,
+			      <0x00 0x484c2000 0x00 0x2000>,
+			      <0x00 0x48420000 0x00 0x2000>;
+			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "bchan";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <3>;
 
@@ -138,8 +143,13 @@ main_pktdma: dma-controller at 485c0000 {
 			reg = <0x00 0x485c0000 0x00 0x100>,
 			      <0x00 0x4a800000 0x00 0x20000>,
 			      <0x00 0x4aa00000 0x00 0x40000>,
-			      <0x00 0x4b800000 0x00 0x400000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4b800000 0x00 0x400000>,
+			      <0x00 0x485e0000 0x00 0x20000>,
+			      <0x00 0x484a0000 0x00 0x4000>,
+			      <0x00 0x484c0000 0x00 0x2000>,
+			      <0x00 0x48430000 0x00 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <2>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index 4ae7fdc5221b..36947d9d644d 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -101,8 +101,13 @@ main_bcdma: dma-controller at 485c0100 {
 			      <0x00 0x4c000000 0x00 0x20000>,
 			      <0x00 0x4a820000 0x00 0x20000>,
 			      <0x00 0x4aa40000 0x00 0x20000>,
-			      <0x00 0x4bc00000 0x00 0x100000>;
-			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4bc00000 0x00 0x100000>,
+			      <0x00 0x48600000 0x00 0x8000>,
+			      <0x00 0x484a4000 0x00 0x2000>,
+			      <0x00 0x484c2000 0x00 0x2000>,
+			      <0x00 0x48420000 0x00 0x2000>;
+			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "bchan";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <3>;
 			ti,sci = <&dmsc>;
@@ -117,8 +122,13 @@ main_pktdma: dma-controller at 485c0000 {
 			reg = <0x00 0x485c0000 0x00 0x100>,
 			      <0x00 0x4a800000 0x00 0x20000>,
 			      <0x00 0x4aa00000 0x00 0x40000>,
-			      <0x00 0x4b800000 0x00 0x400000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4b800000 0x00 0x400000>,
+			      <0x00 0x485e0000 0x00 0x20000>,
+			      <0x00 0x484a0000 0x00 0x4000>,
+			      <0x00 0x484c0000 0x00 0x2000>,
+			      <0x00 0x48430000 0x00 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <2>;
 			ti,sci = <&dmsc>;
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
index 963758c7d377..21981489b4db 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
@@ -101,8 +101,13 @@ main_bcdma: dma-controller at 485c0100 {
 			      <0x00 0x4c000000 0x00 0x20000>,
 			      <0x00 0x4a820000 0x00 0x20000>,
 			      <0x00 0x4aa40000 0x00 0x20000>,
-			      <0x00 0x4bc00000 0x00 0x100000>;
-			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4bc00000 0x00 0x100000>,
+			      <0x00 0x48600000 0x00 0x8000>,
+			      <0x00 0x484a4000 0x00 0x2000>,
+			      <0x00 0x484c2000 0x00 0x2000>,
+			      <0x00 0x48420000 0x00 0x2000>;
+			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "bchan";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <3>;
 
@@ -119,8 +124,13 @@ main_pktdma: dma-controller at 485c0000 {
 			reg = <0x00 0x485c0000 0x00 0x100>,
 			      <0x00 0x4a800000 0x00 0x20000>,
 			      <0x00 0x4aa00000 0x00 0x40000>,
-			      <0x00 0x4b800000 0x00 0x400000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4b800000 0x00 0x400000>,
+			      <0x00 0x485e0000 0x00 0x20000>,
+			      <0x00 0x484a0000 0x00 0x4000>,
+			      <0x00 0x484c0000 0x00 0x2000>,
+			      <0x00 0x48430000 0x00 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <2>;
 			bootph-all;
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 0be642bc1b86..bcdfd61c7d98 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -138,8 +138,13 @@ main_bcdma: dma-controller at 485c0100 {
 			      <0x00 0x4c000000 0x00 0x20000>,
 			      <0x00 0x4a820000 0x00 0x20000>,
 			      <0x00 0x4aa40000 0x00 0x20000>,
-			      <0x00 0x4bc00000 0x00 0x100000>;
-			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4bc00000 0x00 0x100000>,
+			      <0x00 0x48600000 0x00 0x8000>,
+			      <0x00 0x484a4000 0x00 0x2000>,
+			      <0x00 0x484c2000 0x00 0x2000>,
+			      <0x00 0x48420000 0x00 0x2000>;
+			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "bchan";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <3>;
 
@@ -155,8 +160,13 @@ main_pktdma: dma-controller at 485c0000 {
 			reg = <0x00 0x485c0000 0x00 0x100>,
 			      <0x00 0x4a800000 0x00 0x20000>,
 			      <0x00 0x4aa00000 0x00 0x40000>,
-			      <0x00 0x4b800000 0x00 0x400000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4b800000 0x00 0x400000>,
+			      <0x00 0x485e0000 0x00 0x20000>,
+			      <0x00 0x484a0000 0x00 0x4000>,
+			      <0x00 0x484c0000 0x00 0x2000>,
+			      <0x00 0x48430000 0x00 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <2>;
 
-- 
2.43.0



From james.clark at arm.com  Tue Dec 12 03:20:45 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 11:20:45 +0000
Subject: [PATCH v1 01/14] libperf cpumap: Rename perf_cpu_map__dummy_new
In-Reply-To: <20231129060211.1890454-2-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-2-irogers@google.com>
Message-ID: <8b398a96-8c75-93fb-b315-2da4b016c9c3@arm.com>



On 29/11/2023 06:01, Ian Rogers wrote:
> Rename perf_cpu_map__dummy_new to perf_cpu_map__new_any_cpu to better
> indicate this is creating a CPU map for the perf_event_open "any" CPU
> case.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>

Reviewed-by: James Clark <james.clark at arm.com>

> ---
>  tools/lib/perf/Documentation/libperf.txt | 2 +-
>  tools/lib/perf/cpumap.c                  | 4 ++--
>  tools/lib/perf/evsel.c                   | 2 +-
>  tools/lib/perf/include/perf/cpumap.h     | 4 ++--
>  tools/lib/perf/libperf.map               | 2 +-
>  tools/lib/perf/tests/test-cpumap.c       | 2 +-
>  tools/lib/perf/tests/test-evlist.c       | 2 +-
>  tools/perf/tests/cpumap.c                | 2 +-
>  tools/perf/tests/sw-clock.c              | 2 +-
>  tools/perf/tests/task-exit.c             | 2 +-
>  tools/perf/util/evlist.c                 | 2 +-
>  tools/perf/util/evsel.c                  | 2 +-
>  12 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/lib/perf/Documentation/libperf.txt b/tools/lib/perf/Documentation/libperf.txt
> index a8f1a237931b..a256a26598b0 100644
> --- a/tools/lib/perf/Documentation/libperf.txt
> +++ b/tools/lib/perf/Documentation/libperf.txt
> @@ -37,7 +37,7 @@ SYNOPSIS
>  
>    struct perf_cpu_map;
>  
> -  struct perf_cpu_map *perf_cpu_map__dummy_new(void);
> +  struct perf_cpu_map *perf_cpu_map__new_any_cpu(void);
>    struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list);
>    struct perf_cpu_map *perf_cpu_map__read(FILE *file);
>    struct perf_cpu_map *perf_cpu_map__get(struct perf_cpu_map *map);
> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
> index 2a5a29217374..2bd6aba3d8c9 100644
> --- a/tools/lib/perf/cpumap.c
> +++ b/tools/lib/perf/cpumap.c
> @@ -27,7 +27,7 @@ struct perf_cpu_map *perf_cpu_map__alloc(int nr_cpus)
>  	return result;
>  }
>  
> -struct perf_cpu_map *perf_cpu_map__dummy_new(void)
> +struct perf_cpu_map *perf_cpu_map__new_any_cpu(void)
>  {
>  	struct perf_cpu_map *cpus = perf_cpu_map__alloc(1);
>  
> @@ -271,7 +271,7 @@ struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
>  	else if (*cpu_list != '\0')
>  		cpus = cpu_map__default_new();
>  	else
> -		cpus = perf_cpu_map__dummy_new();
> +		cpus = perf_cpu_map__new_any_cpu();
>  invalid:
>  	free(tmp_cpus);
>  out:
> diff --git a/tools/lib/perf/evsel.c b/tools/lib/perf/evsel.c
> index 8b51b008a81f..c07160953224 100644
> --- a/tools/lib/perf/evsel.c
> +++ b/tools/lib/perf/evsel.c
> @@ -120,7 +120,7 @@ int perf_evsel__open(struct perf_evsel *evsel, struct perf_cpu_map *cpus,
>  		static struct perf_cpu_map *empty_cpu_map;
>  
>  		if (empty_cpu_map == NULL) {
> -			empty_cpu_map = perf_cpu_map__dummy_new();
> +			empty_cpu_map = perf_cpu_map__new_any_cpu();
>  			if (empty_cpu_map == NULL)
>  				return -ENOMEM;
>  		}
> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> index e38d859a384d..d0bf218ada11 100644
> --- a/tools/lib/perf/include/perf/cpumap.h
> +++ b/tools/lib/perf/include/perf/cpumap.h
> @@ -19,9 +19,9 @@ struct perf_cache {
>  struct perf_cpu_map;
>  
>  /**
> - * perf_cpu_map__dummy_new - a map with a singular "any CPU"/dummy -1 value.
> + * perf_cpu_map__new_any_cpu - a map with a singular "any CPU"/dummy -1 value.
>   */
> -LIBPERF_API struct perf_cpu_map *perf_cpu_map__dummy_new(void);
> +LIBPERF_API struct perf_cpu_map *perf_cpu_map__new_any_cpu(void);
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__default_new(void);
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list);
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__read(FILE *file);
> diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> index 190b56ae923a..a8ff64baea3e 100644
> --- a/tools/lib/perf/libperf.map
> +++ b/tools/lib/perf/libperf.map
> @@ -1,7 +1,7 @@
>  LIBPERF_0.0.1 {
>  	global:
>  		libperf_init;
> -		perf_cpu_map__dummy_new;
> +		perf_cpu_map__new_any_cpu;
>  		perf_cpu_map__default_new;
>  		perf_cpu_map__get;
>  		perf_cpu_map__put;
> diff --git a/tools/lib/perf/tests/test-cpumap.c b/tools/lib/perf/tests/test-cpumap.c
> index 87b0510a556f..2c359bdb951e 100644
> --- a/tools/lib/perf/tests/test-cpumap.c
> +++ b/tools/lib/perf/tests/test-cpumap.c
> @@ -21,7 +21,7 @@ int test_cpumap(int argc, char **argv)
>  
>  	libperf_init(libperf_print);
>  
> -	cpus = perf_cpu_map__dummy_new();
> +	cpus = perf_cpu_map__new_any_cpu();
>  	if (!cpus)
>  		return -1;
>  
> diff --git a/tools/lib/perf/tests/test-evlist.c b/tools/lib/perf/tests/test-evlist.c
> index ed616fc19b4f..ab63878bacb9 100644
> --- a/tools/lib/perf/tests/test-evlist.c
> +++ b/tools/lib/perf/tests/test-evlist.c
> @@ -261,7 +261,7 @@ static int test_mmap_thread(void)
>  	threads = perf_thread_map__new_dummy();
>  	__T("failed to create threads", threads);
>  
> -	cpus = perf_cpu_map__dummy_new();
> +	cpus = perf_cpu_map__new_any_cpu();
>  	__T("failed to create cpus", cpus);
>  
>  	perf_thread_map__set_pid(threads, 0, pid);
> diff --git a/tools/perf/tests/cpumap.c b/tools/perf/tests/cpumap.c
> index 7730fc2ab40b..bd8e396f3e57 100644
> --- a/tools/perf/tests/cpumap.c
> +++ b/tools/perf/tests/cpumap.c
> @@ -213,7 +213,7 @@ static int test__cpu_map_intersect(struct test_suite *test __maybe_unused,
>  
>  static int test__cpu_map_equal(struct test_suite *test __maybe_unused, int subtest __maybe_unused)
>  {
> -	struct perf_cpu_map *any = perf_cpu_map__dummy_new();
> +	struct perf_cpu_map *any = perf_cpu_map__new_any_cpu();
>  	struct perf_cpu_map *one = perf_cpu_map__new("1");
>  	struct perf_cpu_map *two = perf_cpu_map__new("2");
>  	struct perf_cpu_map *empty = perf_cpu_map__intersect(one, two);
> diff --git a/tools/perf/tests/sw-clock.c b/tools/perf/tests/sw-clock.c
> index 4d7493fa0105..290716783ac6 100644
> --- a/tools/perf/tests/sw-clock.c
> +++ b/tools/perf/tests/sw-clock.c
> @@ -62,7 +62,7 @@ static int __test__sw_clock_freq(enum perf_sw_ids clock_id)
>  	}
>  	evlist__add(evlist, evsel);
>  
> -	cpus = perf_cpu_map__dummy_new();
> +	cpus = perf_cpu_map__new_any_cpu();
>  	threads = thread_map__new_by_tid(getpid());
>  	if (!cpus || !threads) {
>  		err = -ENOMEM;
> diff --git a/tools/perf/tests/task-exit.c b/tools/perf/tests/task-exit.c
> index 968dddde6dda..d33d0952025c 100644
> --- a/tools/perf/tests/task-exit.c
> +++ b/tools/perf/tests/task-exit.c
> @@ -70,7 +70,7 @@ static int test__task_exit(struct test_suite *test __maybe_unused, int subtest _
>  	 * evlist__prepare_workload we'll fill in the only thread
>  	 * we're monitoring, the one forked there.
>  	 */
> -	cpus = perf_cpu_map__dummy_new();
> +	cpus = perf_cpu_map__new_any_cpu();
>  	threads = thread_map__new_by_tid(-1);
>  	if (!cpus || !threads) {
>  		err = -ENOMEM;
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index e36da58522ef..ff7f85ded89d 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -1056,7 +1056,7 @@ int evlist__create_maps(struct evlist *evlist, struct target *target)
>  		return -1;
>  
>  	if (target__uses_dummy_map(target))
> -		cpus = perf_cpu_map__dummy_new();
> +		cpus = perf_cpu_map__new_any_cpu();
>  	else
>  		cpus = perf_cpu_map__new(target->cpu_list);
>  
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index a5da74e3a517..76ef3ab488a2 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -1801,7 +1801,7 @@ static int __evsel__prepare_open(struct evsel *evsel, struct perf_cpu_map *cpus,
>  
>  	if (cpus == NULL) {
>  		if (empty_cpu_map == NULL) {
> -			empty_cpu_map = perf_cpu_map__dummy_new();
> +			empty_cpu_map = perf_cpu_map__new_any_cpu();
>  			if (empty_cpu_map == NULL)
>  				return -ENOMEM;
>  		}


From james.clark at arm.com  Tue Dec 12 03:25:14 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 11:25:14 +0000
Subject: [PATCH v1 13/14] perf cpumap: Use perf_cpu_map__for_each_cpu when
 possible
In-Reply-To: <20231129060211.1890454-14-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-14-irogers@google.com>
Message-ID: <a4e6e2b4-a66a-2aa8-1200-250b4fbcc58d@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> Rather than manually iterating the CPU map, use
> perf_cpu_map__for_each_cpu. When possible tidy local variables.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>
> ---
>  tools/perf/arch/arm64/util/header.c           | 10 ++--
>  tools/perf/tests/bitmap.c                     | 13 +++---
>  tools/perf/tests/topology.c                   | 46 +++++++++----------
>  tools/perf/util/bpf_kwork.c                   | 16 ++++---
>  tools/perf/util/bpf_kwork_top.c               | 12 ++---
>  tools/perf/util/cpumap.c                      | 12 ++---
>  .../scripting-engines/trace-event-python.c    | 12 +++--
>  tools/perf/util/session.c                     |  5 +-
>  tools/perf/util/svghelper.c                   | 20 ++++----
>  9 files changed, 72 insertions(+), 74 deletions(-)
> 
[...]
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
> index 860e1837ba96..8ef0e5ac03c2 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -1693,13 +1693,15 @@ static void python_process_stat(struct perf_stat_config *config,
>  {
>  	struct perf_thread_map *threads = counter->core.threads;
>  	struct perf_cpu_map *cpus = counter->core.cpus;
> -	int cpu, thread;
>  
> -	for (thread = 0; thread < perf_thread_map__nr(threads); thread++) {
> -		for (cpu = 0; cpu < perf_cpu_map__nr(cpus); cpu++) {
> -			process_stat(counter, perf_cpu_map__cpu(cpus, cpu),
> +	for (int thread = 0; thread < perf_thread_map__nr(threads); thread++) {
> +		int idx;
> +		struct perf_cpu cpu;
> +
> +		perf_cpu_map__for_each_cpu(cpu, idx, cpus) {
> +			process_stat(counter, cpu,
>  				     perf_thread_map__pid(threads, thread), tstamp,
> -				     perf_counts(counter->counts, cpu, thread));
> +				     perf_counts(counter->counts, idx, thread));

I thought changing cpu to idx was fixing a bug, but it was actually just
hard to read before where cpu was actually idx and not cpu, so this
cleanup is pretty good.

Reviewed-by: James Clark <james.clark at arm.com>


From festevam at gmail.com  Tue Dec 12 03:27:27 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 12 Dec 2023 08:27:27 -0300
Subject: [PATCH 1/3] dt-bindings: extcon: ptn5150: Describe the USB connector
Message-ID: <20231212112729.700987-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

PTN5150 supports USB Type-C connector, so improve the bindings by
allowing to describe the connector like it is done on nxp,ptn5110.yaml.

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
index d5cfa32ea52d..3837da7416e9 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
+++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
@@ -37,6 +37,11 @@ properties:
       GPIO pin (output) used to control VBUS. If skipped, no such control
       takes place.
 
+  connector:
+    type: object
+    $ref: /schemas/connector/usb-connector.yaml#
+    unevaluatedProperties: false
+
 required:
   - compatible
   - interrupts
-- 
2.34.1



From festevam at gmail.com  Tue Dec 12 03:27:28 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 12 Dec 2023 08:27:28 -0300
Subject: [PATCH 2/3] arm64: dts: imx8mn-var-som-symphony: Describe the USB-C connector
In-Reply-To: <20231212112729.700987-1-festevam@gmail.com>
References: <20231212112729.700987-1-festevam@gmail.com>
Message-ID: <20231212112729.700987-2-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Describe the PTN5150 USB-C connector to improve the devicetree description
and fix the following dt-schema warning:

imx8mn-var-som-symphony.dtb: typec at 3d: 'port' does not match any of the regexes: 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/extcon/extcon-ptn5150.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 .../boot/dts/freescale/imx8mn-var-som-symphony.dts    | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts
index a6b94d1957c9..f38ee2266b25 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts
@@ -128,9 +128,14 @@ extcon_usbotg1: typec at 3d {
 		pinctrl-0 = <&pinctrl_ptn5150>;
 		status = "okay";
 
-		port {
-			typec1_dr_sw: endpoint {
-				remote-endpoint = <&usb1_drd_sw>;
+		connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+
+			port {
+				typec1_dr_sw: endpoint {
+					remote-endpoint = <&usb1_drd_sw>;
+				};
 			};
 		};
 	};
-- 
2.34.1



From festevam at gmail.com  Tue Dec 12 03:27:29 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 12 Dec 2023 08:27:29 -0300
Subject: [PATCH 3/3] arm64: dts: imx8mp-dhcom-pdk3: Describe the USB-C connector
In-Reply-To: <20231212112729.700987-1-festevam@gmail.com>
References: <20231212112729.700987-1-festevam@gmail.com>
Message-ID: <20231212112729.700987-3-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Describe the PTN5150 USB-C connector to improve the devicetree description
and fix the following dt-schema warning:

imx8mp-dhcom-pdk3.dtb: typec at 3d: 'port' does not match any of the regexes: 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/extcon/extcon-ptn5150.yaml#
	
Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts
index b749e28e5ede..fea67a9282f0 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts
@@ -175,10 +175,14 @@ typec at 3d {
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ptn5150>;
 
-				port {
-
-					ptn5150_out_ep: endpoint {
-						remote-endpoint = <&dwc3_0_ep>;
+				connector {
+					compatible = "usb-c-connector";
+					label = "USB-C";
+
+					port {
+						ptn5150_out_ep: endpoint {
+							remote-endpoint = <&dwc3_0_ep>;
+						};
 					};
 				};
 			};
-- 
2.34.1



From geert at linux-m68k.org  Tue Dec 12 03:27:50 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 12 Dec 2023 12:27:50 +0100
Subject: [PATCH v4 1/4] arm64: fpsimd: Drop unneeded 'busy' flag
In-Reply-To: <20231208113218.3001940-7-ardb@google.com>
References: <20231208113218.3001940-6-ardb@google.com> <20231208113218.3001940-7-ardb@google.com>
Message-ID: <CAMuHMdWewWJ1msJTcPNcbAf296gt+Kait3ECXjsJrSN+uerWyA@mail.gmail.com>

Hi Ard,

On Fri, Dec 8, 2023 at 12:34?PM Ard Biesheuvel <ardb at google.com> wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> Kernel mode NEON will preserve the user mode FPSIMD state by saving it
> into the task struct before clobbering the registers. In order to avoid
> the need for preserving kernel mode state too, we disallow nested use of
> kernel mode NEON, i..e, use in softirq context while the interrupted
> task context was using kernel mode NEON too.
>
> Originally, this policy was implemented using a per-CPU flag which was
> exposed via may_use_simd(), requiring the users of the kernel mode NEON
> to deal with the possibility that it might return false, and having NEON
> and non-NEON code paths. This policy was changed by commit
> 13150149aa6ded1 ("arm64: fpsimd: run kernel mode NEON with softirqs
> disabled"), and now, softirq processing is disabled entirely instead,
> and so may_use_simd() can never fail when called from task or softirq
> context.
>
> This means we can drop the fpsimd_context_busy flag entirely, and
> instead, ensure that we disable softirq processing in places where we
> formerly relied on the flag for preventing races in the FPSIMD preserve
> routines.
>
> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> Reviewed-by: Mark Brown <broonie at kernel.org>

Thanks for your patch, which is now commit e109130b0e5ec3fd
("arm64: fpsimd: Drop unneeded 'busy' flag") in arm64/for-next/core
and next-20231212.

I have bisected the following warning during boot (on Salvator-XS with
R-Car H3 ES2.0 and on White-Hawk with R-Car V4H) followed by a lock-up
(on Salvator-XS) to this commit:

Reverting commits 035262623959cbe1 ("arm64: fpsimd: Implement lazy
restore for kernel mode FPSIMD"), 1e3a3de1ff6ca6b1 ("arm64: fpsimd:
Preserve/restore kernel mode NEON at context switch"), and this commit
fixes the issue.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From james.clark at arm.com  Tue Dec 12 03:28:22 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 11:28:22 +0000
Subject: [PATCH v1 12/14] perf stat: Remove duplicate cpus_map_matched
 function
In-Reply-To: <20231129060211.1890454-13-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-13-irogers@google.com>
Message-ID: <1c5494f7-960e-07e9-eb8c-6c9dd8405004@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> Use libperf's perf_cpu_map__equal that performs the same function.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>
> ---

Reviewed-by: James Clark <james.clark at arm.com>

>  tools/perf/builtin-stat.c | 22 +---------------------
>  1 file changed, 1 insertion(+), 21 deletions(-)
> 
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index f583027a0639..8e2f90b5c276 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -164,26 +164,6 @@ static struct perf_stat_config stat_config = {
>  	.iostat_run		= false,
>  };
>  
> -static bool cpus_map_matched(struct evsel *a, struct evsel *b)
> -{
> -	if (!a->core.cpus && !b->core.cpus)
> -		return true;
> -
> -	if (!a->core.cpus || !b->core.cpus)
> -		return false;
> -
> -	if (perf_cpu_map__nr(a->core.cpus) != perf_cpu_map__nr(b->core.cpus))
> -		return false;
> -
> -	for (int i = 0; i < perf_cpu_map__nr(a->core.cpus); i++) {
> -		if (perf_cpu_map__cpu(a->core.cpus, i).cpu !=
> -		    perf_cpu_map__cpu(b->core.cpus, i).cpu)
> -			return false;
> -	}
> -
> -	return true;
> -}
> -
>  static void evlist__check_cpu_maps(struct evlist *evlist)
>  {
>  	struct evsel *evsel, *warned_leader = NULL;
> @@ -194,7 +174,7 @@ static void evlist__check_cpu_maps(struct evlist *evlist)
>  		/* Check that leader matches cpus with each member. */
>  		if (leader == evsel)
>  			continue;
> -		if (cpus_map_matched(leader, evsel))
> +		if (perf_cpu_map__equal(leader->core.cpus, evsel->core.cpus))
>  			continue;
>  
>  		/* If there's mismatch disable the group and warn user. */


From james.clark at arm.com  Tue Dec 12 03:32:49 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 11:32:49 +0000
Subject: [PATCH v1 02/14] libperf cpumap: Rename and prefer sysfs for
 perf_cpu_map__default_new
In-Reply-To: <20231129060211.1890454-3-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-3-irogers@google.com>
Message-ID: <e2284c10-1dc3-2c55-1e56-2cd8c0c8d461@arm.com>



On 29/11/2023 06:01, Ian Rogers wrote:
> Rename perf_cpu_map__default_new to perf_cpu_map__new_online_cpus to
> better indicate what the implementation does. Read the online CPUs
> from /sys/devices/system/cpu/online first before using sysconf as
> sysconf can't accurately configure holes in the CPU map. If sysconf is
> used, warn when the configured and online processors disagree.
> 
> When reading from a file, if the read doesn't yield a CPU map then
> return an empty map rather than the default online. This avoids
> recursion but also better yields being able to detect failures.
> 
> Add more comments.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>

Reviewed-by: James Clark <james.clark at arm.com>

> ---
>  tools/lib/perf/cpumap.c              | 59 +++++++++++++++++-----------
>  tools/lib/perf/include/perf/cpumap.h | 15 ++++++-
>  tools/lib/perf/libperf.map           |  2 +-
>  tools/lib/perf/tests/test-cpumap.c   |  2 +-
>  4 files changed, 51 insertions(+), 27 deletions(-)
> 
> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
> index 2bd6aba3d8c9..463ca8b37d45 100644
> --- a/tools/lib/perf/cpumap.c
> +++ b/tools/lib/perf/cpumap.c
> @@ -9,6 +9,7 @@
>  #include <unistd.h>
>  #include <ctype.h>
>  #include <limits.h>
> +#include "internal.h"
>  
>  void perf_cpu_map__set_nr(struct perf_cpu_map *map, int nr_cpus)
>  {
> @@ -66,15 +67,21 @@ void perf_cpu_map__put(struct perf_cpu_map *map)
>  	}
>  }
>  
> -static struct perf_cpu_map *cpu_map__default_new(void)
> +static struct perf_cpu_map *cpu_map__new_sysconf(void)
>  {
>  	struct perf_cpu_map *cpus;
> -	int nr_cpus;
> +	int nr_cpus, nr_cpus_conf;
>  
>  	nr_cpus = sysconf(_SC_NPROCESSORS_ONLN);
>  	if (nr_cpus < 0)
>  		return NULL;
>  
> +	nr_cpus_conf = sysconf(_SC_NPROCESSORS_CONF);
> +	if (nr_cpus != nr_cpus_conf) {
> +		pr_warning("Number of online CPUs (%d) differs from the number configured (%d) the CPU map will only cover the first %d CPUs.",
> +			nr_cpus, nr_cpus_conf, nr_cpus);
> +	}
> +
>  	cpus = perf_cpu_map__alloc(nr_cpus);
>  	if (cpus != NULL) {
>  		int i;
> @@ -86,9 +93,27 @@ static struct perf_cpu_map *cpu_map__default_new(void)
>  	return cpus;
>  }
>  
> -struct perf_cpu_map *perf_cpu_map__default_new(void)
> +static struct perf_cpu_map *cpu_map__new_syfs_online(void)
>  {
> -	return cpu_map__default_new();
> +	struct perf_cpu_map *cpus = NULL;
> +	FILE *onlnf;
> +
> +	onlnf = fopen("/sys/devices/system/cpu/online", "r");
> +	if (onlnf) {
> +		cpus = perf_cpu_map__read(onlnf);
> +		fclose(onlnf);
> +	}
> +	return cpus;
> +}
> +
> +struct perf_cpu_map *perf_cpu_map__new_online_cpus(void)
> +{
> +	struct perf_cpu_map *cpus = cpu_map__new_syfs_online();
> +
> +	if (cpus)
> +		return cpus;
> +
> +	return cpu_map__new_sysconf();
>  }
>  
>  
> @@ -180,27 +205,11 @@ struct perf_cpu_map *perf_cpu_map__read(FILE *file)
>  
>  	if (nr_cpus > 0)
>  		cpus = cpu_map__trim_new(nr_cpus, tmp_cpus);
> -	else
> -		cpus = cpu_map__default_new();
>  out_free_tmp:
>  	free(tmp_cpus);
>  	return cpus;
>  }
>  
> -static struct perf_cpu_map *cpu_map__read_all_cpu_map(void)
> -{
> -	struct perf_cpu_map *cpus = NULL;
> -	FILE *onlnf;
> -
> -	onlnf = fopen("/sys/devices/system/cpu/online", "r");
> -	if (!onlnf)
> -		return cpu_map__default_new();
> -
> -	cpus = perf_cpu_map__read(onlnf);
> -	fclose(onlnf);
> -	return cpus;
> -}
> -
>  struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
>  {
>  	struct perf_cpu_map *cpus = NULL;
> @@ -211,7 +220,7 @@ struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
>  	int max_entries = 0;
>  
>  	if (!cpu_list)
> -		return cpu_map__read_all_cpu_map();
> +		return perf_cpu_map__new_online_cpus();
>  
>  	/*
>  	 * must handle the case of empty cpumap to cover
> @@ -268,9 +277,11 @@ struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
>  
>  	if (nr_cpus > 0)
>  		cpus = cpu_map__trim_new(nr_cpus, tmp_cpus);
> -	else if (*cpu_list != '\0')
> -		cpus = cpu_map__default_new();
> -	else
> +	else if (*cpu_list != '\0') {
> +		pr_warning("Unexpected characters at end of cpu list ('%s'), using online CPUs.",
> +			   cpu_list);
> +		cpus = perf_cpu_map__new_online_cpus();
> +	} else
>  		cpus = perf_cpu_map__new_any_cpu();
>  invalid:
>  	free(tmp_cpus);
> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> index d0bf218ada11..b24bd8b8f34e 100644
> --- a/tools/lib/perf/include/perf/cpumap.h
> +++ b/tools/lib/perf/include/perf/cpumap.h
> @@ -22,7 +22,20 @@ struct perf_cpu_map;
>   * perf_cpu_map__new_any_cpu - a map with a singular "any CPU"/dummy -1 value.
>   */
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__new_any_cpu(void);
> -LIBPERF_API struct perf_cpu_map *perf_cpu_map__default_new(void);
> +/**
> + * perf_cpu_map__new_online_cpus - a map read from
> + *                                 /sys/devices/system/cpu/online if
> + *                                 available. If reading wasn't possible a map
> + *                                 is created using the online processors
> + *                                 assuming the first 'n' processors are all
> + *                                 online.
> + */
> +LIBPERF_API struct perf_cpu_map *perf_cpu_map__new_online_cpus(void);
> +/**
> + * perf_cpu_map__new - create a map from the given cpu_list such as "0-7". If no
> + *                     cpu_list argument is provided then
> + *                     perf_cpu_map__new_online_cpus is returned.
> + */
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list);
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__read(FILE *file);
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__get(struct perf_cpu_map *map);
> diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> index a8ff64baea3e..8a71f841498e 100644
> --- a/tools/lib/perf/libperf.map
> +++ b/tools/lib/perf/libperf.map
> @@ -2,7 +2,7 @@ LIBPERF_0.0.1 {
>  	global:
>  		libperf_init;
>  		perf_cpu_map__new_any_cpu;
> -		perf_cpu_map__default_new;
> +		perf_cpu_map__new_online_cpus;
>  		perf_cpu_map__get;
>  		perf_cpu_map__put;
>  		perf_cpu_map__new;
> diff --git a/tools/lib/perf/tests/test-cpumap.c b/tools/lib/perf/tests/test-cpumap.c
> index 2c359bdb951e..c998b1dae863 100644
> --- a/tools/lib/perf/tests/test-cpumap.c
> +++ b/tools/lib/perf/tests/test-cpumap.c
> @@ -29,7 +29,7 @@ int test_cpumap(int argc, char **argv)
>  	perf_cpu_map__put(cpus);
>  	perf_cpu_map__put(cpus);
>  
> -	cpus = perf_cpu_map__default_new();
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (!cpus)
>  		return -1;
>  


From will at kernel.org  Tue Dec 12 03:35:17 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 11:35:17 +0000
Subject: [PATCH v3 12/15] arm64/mm: Split __flush_tlb_range() to elide
 trailing DSB
In-Reply-To: <20231204105440.61448-13-ryan.roberts@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-13-ryan.roberts@arm.com>
Message-ID: <20231212113517.GA28857@willie-the-truck>

On Mon, Dec 04, 2023 at 10:54:37AM +0000, Ryan Roberts wrote:
> Split __flush_tlb_range() into __flush_tlb_range_nosync() +
> __flush_tlb_range(), in the same way as the existing flush_tlb_page()
> arrangement. This allows calling __flush_tlb_range_nosync() to elide the
> trailing DSB. Forthcoming "contpte" code will take advantage of this
> when clearing the young bit from a contiguous range of ptes.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>  arch/arm64/include/asm/tlbflush.h | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index bb2c2833a987..925ef3bdf9ed 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -399,7 +399,7 @@ do {									\
>  #define __flush_s2_tlb_range_op(op, start, pages, stride, tlb_level) \
>  	__flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false)
>  
> -static inline void __flush_tlb_range(struct vm_area_struct *vma,
> +static inline void __flush_tlb_range_nosync(struct vm_area_struct *vma,
>  				     unsigned long start, unsigned long end,
>  				     unsigned long stride, bool last_level,
>  				     int tlb_level)
> @@ -431,10 +431,19 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
>  	else
>  		__flush_tlb_range_op(vae1is, start, pages, stride, asid, tlb_level, true);
>  
> -	dsb(ish);
>  	mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, start, end);
>  }
>  
> +static inline void __flush_tlb_range(struct vm_area_struct *vma,
> +				     unsigned long start, unsigned long end,
> +				     unsigned long stride, bool last_level,
> +				     int tlb_level)
> +{
> +	__flush_tlb_range_nosync(vma, start, end, stride,
> +				 last_level, tlb_level);
> +	dsb(ish);
> +}

Hmm, are you sure it's safe to defer the DSB until after the secondary TLB
invalidation? It will have a subtle effect on e.g. an SMMU participating
in broadcast TLB maintenance, because now the ATC will be invalidated
before completion of the TLB invalidation and it's not obviously safe to me.

Will


From james.clark at arm.com  Tue Dec 12 03:38:36 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 11:38:36 +0000
Subject: [PATCH v1 03/14] libperf cpumap: Rename perf_cpu_map__empty
In-Reply-To: <20231129060211.1890454-4-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-4-irogers@google.com>
Message-ID: <c32bcf09-355a-54af-c136-861a3639f5cf@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> The name perf_cpu_map_empty is misleading as true is also returned
> when the map contains an "any" CPU (aka dummy) map. Rename to
> perf_cpu_map__has_any_cpu_or_is_empty, later changes will
> (re)introduce perf_cpu_map__empty and perf_cpu_map__has_any_cpu.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>

Reviewed-by: James Clark <james.clark at arm.com>
> ---
>  tools/lib/perf/Documentation/libperf.txt |  2 +-
>  tools/lib/perf/cpumap.c                  |  2 +-
>  tools/lib/perf/evlist.c                  |  4 ++--
>  tools/lib/perf/include/perf/cpumap.h     |  4 ++--
>  tools/lib/perf/libperf.map               |  2 +-
>  tools/perf/arch/arm/util/cs-etm.c        | 10 +++++-----
>  tools/perf/arch/arm64/util/arm-spe.c     |  4 ++--
>  tools/perf/arch/x86/util/intel-bts.c     |  4 ++--
>  tools/perf/arch/x86/util/intel-pt.c      | 10 +++++-----
>  tools/perf/builtin-c2c.c                 |  2 +-
>  tools/perf/builtin-stat.c                |  6 +++---
>  tools/perf/util/auxtrace.c               |  4 ++--
>  tools/perf/util/record.c                 |  2 +-
>  tools/perf/util/stat.c                   |  2 +-
>  14 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/tools/lib/perf/Documentation/libperf.txt b/tools/lib/perf/Documentation/libperf.txt
> index a256a26598b0..fcfb9499ef9c 100644
> --- a/tools/lib/perf/Documentation/libperf.txt
> +++ b/tools/lib/perf/Documentation/libperf.txt
> @@ -46,7 +46,7 @@ SYNOPSIS
>    void perf_cpu_map__put(struct perf_cpu_map *map);
>    int perf_cpu_map__cpu(const struct perf_cpu_map *cpus, int idx);
>    int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
> -  bool perf_cpu_map__empty(const struct perf_cpu_map *map);
> +  bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map);
>    int perf_cpu_map__max(struct perf_cpu_map *map);
>    bool perf_cpu_map__has(const struct perf_cpu_map *map, int cpu);
>  
> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
> index 463ca8b37d45..49fc98e16514 100644
> --- a/tools/lib/perf/cpumap.c
> +++ b/tools/lib/perf/cpumap.c
> @@ -311,7 +311,7 @@ int perf_cpu_map__nr(const struct perf_cpu_map *cpus)
>  	return cpus ? __perf_cpu_map__nr(cpus) : 1;
>  }
>  
> -bool perf_cpu_map__empty(const struct perf_cpu_map *map)
> +bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map)
>  {
>  	return map ? __perf_cpu_map__cpu(map, 0).cpu == -1 : true;
>  }
> diff --git a/tools/lib/perf/evlist.c b/tools/lib/perf/evlist.c
> index 3acbbccc1901..75f36218fdd9 100644
> --- a/tools/lib/perf/evlist.c
> +++ b/tools/lib/perf/evlist.c
> @@ -619,7 +619,7 @@ static int perf_evlist__nr_mmaps(struct perf_evlist *evlist)
>  
>  	/* One for each CPU */
>  	nr_mmaps = perf_cpu_map__nr(evlist->all_cpus);
> -	if (perf_cpu_map__empty(evlist->all_cpus)) {
> +	if (perf_cpu_map__has_any_cpu_or_is_empty(evlist->all_cpus)) {
>  		/* Plus one for each thread */
>  		nr_mmaps += perf_thread_map__nr(evlist->threads);
>  		/* Minus the per-thread CPU (-1) */
> @@ -653,7 +653,7 @@ int perf_evlist__mmap_ops(struct perf_evlist *evlist,
>  	if (evlist->pollfd.entries == NULL && perf_evlist__alloc_pollfd(evlist) < 0)
>  		return -ENOMEM;
>  
> -	if (perf_cpu_map__empty(cpus))
> +	if (perf_cpu_map__has_any_cpu_or_is_empty(cpus))
>  		return mmap_per_thread(evlist, ops, mp);
>  
>  	return mmap_per_cpu(evlist, ops, mp);
> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> index b24bd8b8f34e..9cf361fc5edc 100644
> --- a/tools/lib/perf/include/perf/cpumap.h
> +++ b/tools/lib/perf/include/perf/cpumap.h
> @@ -47,9 +47,9 @@ LIBPERF_API void perf_cpu_map__put(struct perf_cpu_map *map);
>  LIBPERF_API struct perf_cpu perf_cpu_map__cpu(const struct perf_cpu_map *cpus, int idx);
>  LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
>  /**
> - * perf_cpu_map__empty - is map either empty or the "any CPU"/dummy value.
> + * perf_cpu_map__has_any_cpu_or_is_empty - is map either empty or has the "any CPU"/dummy value.
>   */
> -LIBPERF_API bool perf_cpu_map__empty(const struct perf_cpu_map *map);
> +LIBPERF_API bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map);
>  LIBPERF_API struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map);
>  LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, struct perf_cpu cpu);
>  LIBPERF_API bool perf_cpu_map__equal(const struct perf_cpu_map *lhs,
> diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> index 8a71f841498e..10b3f3722642 100644
> --- a/tools/lib/perf/libperf.map
> +++ b/tools/lib/perf/libperf.map
> @@ -9,7 +9,7 @@ LIBPERF_0.0.1 {
>  		perf_cpu_map__read;
>  		perf_cpu_map__nr;
>  		perf_cpu_map__cpu;
> -		perf_cpu_map__empty;
> +		perf_cpu_map__has_any_cpu_or_is_empty;
>  		perf_cpu_map__max;
>  		perf_cpu_map__has;
>  		perf_thread_map__new_array;
> diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
> index 2cf873d71dff..c6b7b3066324 100644
> --- a/tools/perf/arch/arm/util/cs-etm.c
> +++ b/tools/perf/arch/arm/util/cs-etm.c
> @@ -211,7 +211,7 @@ static int cs_etm_validate_config(struct auxtrace_record *itr,
>  		 * program can run on any CPUs in this case, thus don't skip
>  		 * validation.
>  		 */
> -		if (!perf_cpu_map__empty(event_cpus) &&
> +		if (!perf_cpu_map__has_any_cpu_or_is_empty(event_cpus) &&
>  		    !perf_cpu_map__has(event_cpus, cpu))
>  			continue;
>  
> @@ -435,7 +435,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
>  	 * Also the case of per-cpu mmaps, need the contextID in order to be notified
>  	 * when a context switch happened.
>  	 */
> -	if (!perf_cpu_map__empty(cpus)) {
> +	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
>  		evsel__set_config_if_unset(cs_etm_pmu, cs_etm_evsel,
>  					   "timestamp", 1);
>  		evsel__set_config_if_unset(cs_etm_pmu, cs_etm_evsel,
> @@ -461,7 +461,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
>  	evsel->core.attr.sample_period = 1;
>  
>  	/* In per-cpu case, always need the time of mmap events etc */
> -	if (!perf_cpu_map__empty(cpus))
> +	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus))
>  		evsel__set_sample_bit(evsel, TIME);
>  
>  	err = cs_etm_validate_config(itr, cs_etm_evsel);
> @@ -539,7 +539,7 @@ cs_etm_info_priv_size(struct auxtrace_record *itr __maybe_unused,
>  	struct perf_cpu_map *online_cpus = perf_cpu_map__new(NULL);
>  
>  	/* cpu map is not empty, we have specific CPUs to work with */
> -	if (!perf_cpu_map__empty(event_cpus)) {
> +	if (!perf_cpu_map__has_any_cpu_or_is_empty(event_cpus)) {
>  		for (i = 0; i < cpu__max_cpu().cpu; i++) {
>  			struct perf_cpu cpu = { .cpu = i, };
>  
> @@ -814,7 +814,7 @@ static int cs_etm_info_fill(struct auxtrace_record *itr,
>  		return -EINVAL;
>  
>  	/* If the cpu_map is empty all online CPUs are involved */
> -	if (perf_cpu_map__empty(event_cpus)) {
> +	if (perf_cpu_map__has_any_cpu_or_is_empty(event_cpus)) {
>  		cpu_map = online_cpus;
>  	} else {
>  		/* Make sure all specified CPUs are online */
> diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
> index e3acc739bd00..51ccbfd3d246 100644
> --- a/tools/perf/arch/arm64/util/arm-spe.c
> +++ b/tools/perf/arch/arm64/util/arm-spe.c
> @@ -232,7 +232,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
>  	 * In the case of per-cpu mmaps, sample CPU for AUX event;
>  	 * also enable the timestamp tracing for samples correlation.
>  	 */
> -	if (!perf_cpu_map__empty(cpus)) {
> +	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
>  		evsel__set_sample_bit(arm_spe_evsel, CPU);
>  		evsel__set_config_if_unset(arm_spe_pmu, arm_spe_evsel,
>  					   "ts_enable", 1);
> @@ -265,7 +265,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
>  	tracking_evsel->core.attr.sample_period = 1;
>  
>  	/* In per-cpu case, always need the time of mmap events etc */
> -	if (!perf_cpu_map__empty(cpus)) {
> +	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
>  		evsel__set_sample_bit(tracking_evsel, TIME);
>  		evsel__set_sample_bit(tracking_evsel, CPU);
>  
> diff --git a/tools/perf/arch/x86/util/intel-bts.c b/tools/perf/arch/x86/util/intel-bts.c
> index d2c8cac11470..af8ae4647585 100644
> --- a/tools/perf/arch/x86/util/intel-bts.c
> +++ b/tools/perf/arch/x86/util/intel-bts.c
> @@ -143,7 +143,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
>  	if (!opts->full_auxtrace)
>  		return 0;
>  
> -	if (opts->full_auxtrace && !perf_cpu_map__empty(cpus)) {
> +	if (opts->full_auxtrace && !perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
>  		pr_err(INTEL_BTS_PMU_NAME " does not support per-cpu recording\n");
>  		return -EINVAL;
>  	}
> @@ -224,7 +224,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
>  		 * In the case of per-cpu mmaps, we need the CPU on the
>  		 * AUX event.
>  		 */
> -		if (!perf_cpu_map__empty(cpus))
> +		if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus))
>  			evsel__set_sample_bit(intel_bts_evsel, CPU);
>  	}
>  
> diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c
> index fa0c718b9e72..d199619df3ab 100644
> --- a/tools/perf/arch/x86/util/intel-pt.c
> +++ b/tools/perf/arch/x86/util/intel-pt.c
> @@ -369,7 +369,7 @@ static int intel_pt_info_fill(struct auxtrace_record *itr,
>  			ui__warning("Intel Processor Trace: TSC not available\n");
>  	}
>  
> -	per_cpu_mmaps = !perf_cpu_map__empty(session->evlist->core.user_requested_cpus);
> +	per_cpu_mmaps = !perf_cpu_map__has_any_cpu_or_is_empty(session->evlist->core.user_requested_cpus);
>  
>  	auxtrace_info->type = PERF_AUXTRACE_INTEL_PT;
>  	auxtrace_info->priv[INTEL_PT_PMU_TYPE] = intel_pt_pmu->type;
> @@ -774,7 +774,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
>  	 * Per-cpu recording needs sched_switch events to distinguish different
>  	 * threads.
>  	 */
> -	if (have_timing_info && !perf_cpu_map__empty(cpus) &&
> +	if (have_timing_info && !perf_cpu_map__has_any_cpu_or_is_empty(cpus) &&
>  	    !record_opts__no_switch_events(opts)) {
>  		if (perf_can_record_switch_events()) {
>  			bool cpu_wide = !target__none(&opts->target) &&
> @@ -832,7 +832,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
>  		 * In the case of per-cpu mmaps, we need the CPU on the
>  		 * AUX event.
>  		 */
> -		if (!perf_cpu_map__empty(cpus))
> +		if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus))
>  			evsel__set_sample_bit(intel_pt_evsel, CPU);
>  	}
>  
> @@ -858,7 +858,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
>  			tracking_evsel->immediate = true;
>  
>  		/* In per-cpu case, always need the time of mmap events etc */
> -		if (!perf_cpu_map__empty(cpus)) {
> +		if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
>  			evsel__set_sample_bit(tracking_evsel, TIME);
>  			/* And the CPU for switch events */
>  			evsel__set_sample_bit(tracking_evsel, CPU);
> @@ -870,7 +870,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
>  	 * Warn the user when we do not have enough information to decode i.e.
>  	 * per-cpu with no sched_switch (except workload-only).
>  	 */
> -	if (!ptr->have_sched_switch && !perf_cpu_map__empty(cpus) &&
> +	if (!ptr->have_sched_switch && !perf_cpu_map__has_any_cpu_or_is_empty(cpus) &&
>  	    !target__none(&opts->target) &&
>  	    !intel_pt_evsel->core.attr.exclude_user)
>  		ui__warning("Intel Processor Trace decoding will not be possible except for kernel tracing!\n");
> diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
> index a4cf9de7a7b5..f78eea9e2153 100644
> --- a/tools/perf/builtin-c2c.c
> +++ b/tools/perf/builtin-c2c.c
> @@ -2320,7 +2320,7 @@ static int setup_nodes(struct perf_session *session)
>  		nodes[node] = set;
>  
>  		/* empty node, skip */
> -		if (perf_cpu_map__empty(map))
> +		if (perf_cpu_map__has_any_cpu_or_is_empty(map))
>  			continue;
>  
>  		perf_cpu_map__for_each_cpu(cpu, idx, map) {
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index a3af805a1d57..3303aa20f326 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -1316,7 +1316,7 @@ static int cpu__get_cache_id_from_map(struct perf_cpu cpu, char *map)
>  	 * be the first online CPU in the cache domain else use the
>  	 * first online CPU of the cache domain as the ID.
>  	 */
> -	if (perf_cpu_map__empty(cpu_map))
> +	if (perf_cpu_map__has_any_cpu_or_is_empty(cpu_map))
>  		id = cpu.cpu;
>  	else
>  		id = perf_cpu_map__cpu(cpu_map, 0).cpu;
> @@ -1622,7 +1622,7 @@ static int perf_stat_init_aggr_mode(void)
>  	 * taking the highest cpu number to be the size of
>  	 * the aggregation translate cpumap.
>  	 */
> -	if (!perf_cpu_map__empty(evsel_list->core.user_requested_cpus))
> +	if (!perf_cpu_map__has_any_cpu_or_is_empty(evsel_list->core.user_requested_cpus))
>  		nr = perf_cpu_map__max(evsel_list->core.user_requested_cpus).cpu;
>  	else
>  		nr = 0;
> @@ -2289,7 +2289,7 @@ int process_stat_config_event(struct perf_session *session,
>  
>  	perf_event__read_stat_config(&stat_config, &event->stat_config);
>  
> -	if (perf_cpu_map__empty(st->cpus)) {
> +	if (perf_cpu_map__has_any_cpu_or_is_empty(st->cpus)) {
>  		if (st->aggr_mode != AGGR_UNSET)
>  			pr_warning("warning: processing task data, aggregation mode not set\n");
>  	} else if (st->aggr_mode != AGGR_UNSET) {
> diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
> index f528c4364d23..3684e6009b63 100644
> --- a/tools/perf/util/auxtrace.c
> +++ b/tools/perf/util/auxtrace.c
> @@ -174,7 +174,7 @@ void auxtrace_mmap_params__set_idx(struct auxtrace_mmap_params *mp,
>  				   struct evlist *evlist,
>  				   struct evsel *evsel, int idx)
>  {
> -	bool per_cpu = !perf_cpu_map__empty(evlist->core.user_requested_cpus);
> +	bool per_cpu = !perf_cpu_map__has_any_cpu_or_is_empty(evlist->core.user_requested_cpus);
>  
>  	mp->mmap_needed = evsel->needs_auxtrace_mmap;
>  
> @@ -648,7 +648,7 @@ int auxtrace_parse_snapshot_options(struct auxtrace_record *itr,
>  
>  static int evlist__enable_event_idx(struct evlist *evlist, struct evsel *evsel, int idx)
>  {
> -	bool per_cpu_mmaps = !perf_cpu_map__empty(evlist->core.user_requested_cpus);
> +	bool per_cpu_mmaps = !perf_cpu_map__has_any_cpu_or_is_empty(evlist->core.user_requested_cpus);
>  
>  	if (per_cpu_mmaps) {
>  		struct perf_cpu evlist_cpu = perf_cpu_map__cpu(evlist->core.all_cpus, idx);
> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
> index 9eb5c6a08999..40290382b2d7 100644
> --- a/tools/perf/util/record.c
> +++ b/tools/perf/util/record.c
> @@ -237,7 +237,7 @@ bool evlist__can_select_event(struct evlist *evlist, const char *str)
>  
>  	evsel = evlist__last(temp_evlist);
>  
> -	if (!evlist || perf_cpu_map__empty(evlist->core.user_requested_cpus)) {
> +	if (!evlist || perf_cpu_map__has_any_cpu_or_is_empty(evlist->core.user_requested_cpus)) {
>  		struct perf_cpu_map *cpus = perf_cpu_map__new(NULL);
>  
>  		if (cpus)
> diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
> index ec3506042217..012c4946b9c4 100644
> --- a/tools/perf/util/stat.c
> +++ b/tools/perf/util/stat.c
> @@ -315,7 +315,7 @@ static int check_per_pkg(struct evsel *counter, struct perf_counts_values *vals,
>  	if (!counter->per_pkg)
>  		return 0;
>  
> -	if (perf_cpu_map__empty(cpus))
> +	if (perf_cpu_map__has_any_cpu_or_is_empty(cpus))
>  		return 0;
>  
>  	if (!mask) {


From dave.stevenson at raspberrypi.com  Tue Dec 12 03:40:26 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Tue, 12 Dec 2023 11:40:26 +0000
Subject: [PATCH v5 18/44] drm/vc4: hdmi: Create destroy state implementation
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-18-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-18-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntBe9RfSjdnd5Smx23La5gQaR9WqY8ehXQyp=4D_11N55Q@mail.gmail.com>

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> Even though we were rolling our own custom state for the vc4 HDMI
> controller driver, we were still using the generic helper to destroy
> that state.
>
> It was mostly working since the underlying state is the first member of
> our state so the pointers are probably equal in all relevant cases, but
> it's still fragile so let's fix this properly.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 25c9c71256d3..f05e2c95a60d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -672,11 +672,21 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
>         return &new_state->base;
>  }
>
> +static void vc4_hdmi_connector_destroy_state(struct drm_connector *connector,
> +                                            struct drm_connector_state *state)
> +{
> +       struct vc4_hdmi_connector_state *vc4_state =
> +               conn_state_to_vc4_hdmi_conn_state(state);
> +
> +       __drm_atomic_helper_connector_destroy_state(state);
> +       kfree(vc4_state);
> +}
> +
>  static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
>         .fill_modes = drm_helper_probe_single_connector_modes,
>         .reset = vc4_hdmi_connector_reset,
>         .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
> -       .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +       .atomic_destroy_state = vc4_hdmi_connector_destroy_state,
>         .atomic_get_property = vc4_hdmi_connector_get_property,
>         .atomic_set_property = vc4_hdmi_connector_set_property,
>  };
>
> --
> 2.43.0
>


From u.kleine-koenig at pengutronix.de  Tue Dec 12 03:41:00 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 12:41:00 +0100
Subject: [PATCH v8 1/6] pwm: Rename pwm_apply_state() to
 pwm_apply_might_sleep()
In-Reply-To: <9af7ba748fd2eb7e04208b6b183185f1daf78016.1702369869.git.sean@mess.org>
References: <cover.1702369869.git.sean@mess.org>
 <9af7ba748fd2eb7e04208b6b183185f1daf78016.1702369869.git.sean@mess.org>
Message-ID: <20231212114100.sn7nzntousql2ays@pengutronix.de>

On Tue, Dec 12, 2023 at 08:34:00AM +0000, Sean Young wrote:
> In order to introduce a pwm api which can be used from atomic context,
> we will need two functions for applying pwm changes:
> 
> 	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
> 	int pwm_apply_atomic(struct pwm *, struct pwm_state *);
> 
> This commit just deals with renaming pwm_apply_state(), a following
> commit will introduce the pwm_apply_atomic() function.
> 
> Acked-by: Dmitry Torokhov <dmitry.torokhov at gmail.com> # for input
> Acked-by: Hans de Goede <hdegoede at redhat.com>
> Acked-by: Jani Nikula <jani.nikula at intel.com>
> Acked-by: Lee Jones <lee at kernel.org>
> Signed-off-by: Sean Young <sean at mess.org>

Acked-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Several affected maintainers already acked, so I guess it's fine to take
this via the pwm tree. An Ack from the remaining maintainers would be
very welcome, an alternative would be to split the patch.

Missing Acks so far:

 - Jean Delvare / Guenter Roeck for drivers/hwmon/pwm-fan.c
 - Javier Martinez Canillas for drivers/gpu/drm/solomon/ssd130x.c
 - Liam Girdwood / Mark Brown for drivers/regulator/pwm-regulator.c
 - Helge Deller for drivers/video/fbdev/ssd1307fb.c

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/4014ddd5/attachment.sig>

From james.clark at arm.com  Tue Dec 12 03:44:05 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 11:44:05 +0000
Subject: [PATCH v1 04/14] libperf cpumap: Replace usage of
 perf_cpu_map__new(NULL)
In-Reply-To: <20231129060211.1890454-5-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-5-irogers@google.com>
Message-ID: <2e2f9859-a53f-f7a2-1e2b-6a3e0f2ed7db@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> Passing NULL to perf_cpu_map__new performs
> perf_cpu_map__new_online_cpus, just directly call
> perf_cpu_map__new_online_cpus to be more intention revealing.

If it's not too much effort I would make perf_cpu_map__new() assert if
it's called with NULL now, to avoid any future divergance or hidden
behavior again.

Either way:

Reviewed-by: James Clark <james.clark at arm.com>

> 
> Signed-off-by: Ian Rogers <irogers at google.com>
> ---
>  tools/lib/perf/Documentation/examples/sampling.c  | 2 +-
>  tools/lib/perf/Documentation/libperf-sampling.txt | 2 +-
>  tools/lib/perf/evlist.c                           | 2 +-
>  tools/lib/perf/tests/test-evlist.c                | 4 ++--
>  tools/lib/perf/tests/test-evsel.c                 | 2 +-
>  tools/perf/arch/arm/util/cs-etm.c                 | 6 +++---
>  tools/perf/arch/arm64/util/header.c               | 2 +-
>  tools/perf/bench/epoll-ctl.c                      | 2 +-
>  tools/perf/bench/epoll-wait.c                     | 2 +-
>  tools/perf/bench/futex-hash.c                     | 2 +-
>  tools/perf/bench/futex-lock-pi.c                  | 2 +-
>  tools/perf/bench/futex-requeue.c                  | 2 +-
>  tools/perf/bench/futex-wake-parallel.c            | 2 +-
>  tools/perf/bench/futex-wake.c                     | 2 +-
>  tools/perf/builtin-ftrace.c                       | 2 +-
>  tools/perf/tests/code-reading.c                   | 2 +-
>  tools/perf/tests/keep-tracking.c                  | 2 +-
>  tools/perf/tests/mmap-basic.c                     | 2 +-
>  tools/perf/tests/openat-syscall-all-cpus.c        | 2 +-
>  tools/perf/tests/perf-time-to-tsc.c               | 2 +-
>  tools/perf/tests/switch-tracking.c                | 2 +-
>  tools/perf/tests/topology.c                       | 2 +-
>  tools/perf/util/bpf_counter.c                     | 2 +-
>  tools/perf/util/cpumap.c                          | 2 +-
>  tools/perf/util/cputopo.c                         | 2 +-
>  tools/perf/util/evlist.c                          | 2 +-
>  tools/perf/util/perf_api_probe.c                  | 4 ++--
>  tools/perf/util/record.c                          | 2 +-
>  28 files changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/tools/lib/perf/Documentation/examples/sampling.c b/tools/lib/perf/Documentation/examples/sampling.c
> index 8e1a926a9cfe..bc142f0664b5 100644
> --- a/tools/lib/perf/Documentation/examples/sampling.c
> +++ b/tools/lib/perf/Documentation/examples/sampling.c
> @@ -39,7 +39,7 @@ int main(int argc, char **argv)
>  
>  	libperf_init(libperf_print);
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (!cpus) {
>  		fprintf(stderr, "failed to create cpus\n");
>  		return -1;
> diff --git a/tools/lib/perf/Documentation/libperf-sampling.txt b/tools/lib/perf/Documentation/libperf-sampling.txt
> index d6ca24f6ef78..2378980fab8a 100644
> --- a/tools/lib/perf/Documentation/libperf-sampling.txt
> +++ b/tools/lib/perf/Documentation/libperf-sampling.txt
> @@ -97,7 +97,7 @@ In this case we will monitor all the available CPUs:
>  
>  [source,c]
>  --
> - 42         cpus = perf_cpu_map__new(NULL);
> + 42         cpus = perf_cpu_map__new_online_cpus();
>   43         if (!cpus) {
>   44                 fprintf(stderr, "failed to create cpus\n");
>   45                 return -1;
> diff --git a/tools/lib/perf/evlist.c b/tools/lib/perf/evlist.c
> index 75f36218fdd9..058e3ff10f9b 100644
> --- a/tools/lib/perf/evlist.c
> +++ b/tools/lib/perf/evlist.c
> @@ -39,7 +39,7 @@ static void __perf_evlist__propagate_maps(struct perf_evlist *evlist,
>  	if (evsel->system_wide) {
>  		/* System wide: set the cpu map of the evsel to all online CPUs. */
>  		perf_cpu_map__put(evsel->cpus);
> -		evsel->cpus = perf_cpu_map__new(NULL);
> +		evsel->cpus = perf_cpu_map__new_online_cpus();
>  	} else if (evlist->has_user_cpus && evsel->is_pmu_core) {
>  		/*
>  		 * User requested CPUs on a core PMU, ensure the requested CPUs
> diff --git a/tools/lib/perf/tests/test-evlist.c b/tools/lib/perf/tests/test-evlist.c
> index ab63878bacb9..10f70cb41ff1 100644
> --- a/tools/lib/perf/tests/test-evlist.c
> +++ b/tools/lib/perf/tests/test-evlist.c
> @@ -46,7 +46,7 @@ static int test_stat_cpu(void)
>  	};
>  	int err, idx;
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	__T("failed to create cpus", cpus);
>  
>  	evlist = perf_evlist__new();
> @@ -350,7 +350,7 @@ static int test_mmap_cpus(void)
>  
>  	attr.config = id;
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	__T("failed to create cpus", cpus);
>  
>  	evlist = perf_evlist__new();
> diff --git a/tools/lib/perf/tests/test-evsel.c b/tools/lib/perf/tests/test-evsel.c
> index a11fc51bfb68..545ec3150546 100644
> --- a/tools/lib/perf/tests/test-evsel.c
> +++ b/tools/lib/perf/tests/test-evsel.c
> @@ -27,7 +27,7 @@ static int test_stat_cpu(void)
>  	};
>  	int err, idx;
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	__T("failed to create cpus", cpus);
>  
>  	evsel = perf_evsel__new(&attr);
> diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
> index c6b7b3066324..77e6663c1703 100644
> --- a/tools/perf/arch/arm/util/cs-etm.c
> +++ b/tools/perf/arch/arm/util/cs-etm.c
> @@ -199,7 +199,7 @@ static int cs_etm_validate_config(struct auxtrace_record *itr,
>  {
>  	int i, err = -EINVAL;
>  	struct perf_cpu_map *event_cpus = evsel->evlist->core.user_requested_cpus;
> -	struct perf_cpu_map *online_cpus = perf_cpu_map__new(NULL);
> +	struct perf_cpu_map *online_cpus = perf_cpu_map__new_online_cpus();
>  
>  	/* Set option of each CPU we have */
>  	for (i = 0; i < cpu__max_cpu().cpu; i++) {
> @@ -536,7 +536,7 @@ cs_etm_info_priv_size(struct auxtrace_record *itr __maybe_unused,
>  	int i;
>  	int etmv3 = 0, etmv4 = 0, ete = 0;
>  	struct perf_cpu_map *event_cpus = evlist->core.user_requested_cpus;
> -	struct perf_cpu_map *online_cpus = perf_cpu_map__new(NULL);
> +	struct perf_cpu_map *online_cpus = perf_cpu_map__new_online_cpus();
>  
>  	/* cpu map is not empty, we have specific CPUs to work with */
>  	if (!perf_cpu_map__has_any_cpu_or_is_empty(event_cpus)) {
> @@ -802,7 +802,7 @@ static int cs_etm_info_fill(struct auxtrace_record *itr,
>  	u64 nr_cpu, type;
>  	struct perf_cpu_map *cpu_map;
>  	struct perf_cpu_map *event_cpus = session->evlist->core.user_requested_cpus;
> -	struct perf_cpu_map *online_cpus = perf_cpu_map__new(NULL);
> +	struct perf_cpu_map *online_cpus = perf_cpu_map__new_online_cpus();
>  	struct cs_etm_recording *ptr =
>  			container_of(itr, struct cs_etm_recording, itr);
>  	struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
> diff --git a/tools/perf/arch/arm64/util/header.c b/tools/perf/arch/arm64/util/header.c
> index a2eef9ec5491..97037499152e 100644
> --- a/tools/perf/arch/arm64/util/header.c
> +++ b/tools/perf/arch/arm64/util/header.c
> @@ -57,7 +57,7 @@ static int _get_cpuid(char *buf, size_t sz, struct perf_cpu_map *cpus)
>  
>  int get_cpuid(char *buf, size_t sz)
>  {
> -	struct perf_cpu_map *cpus = perf_cpu_map__new(NULL);
> +	struct perf_cpu_map *cpus = perf_cpu_map__new_online_cpus();
>  	int ret;
>  
>  	if (!cpus)
> diff --git a/tools/perf/bench/epoll-ctl.c b/tools/perf/bench/epoll-ctl.c
> index 6bfffe83dde9..d3db73dac66a 100644
> --- a/tools/perf/bench/epoll-ctl.c
> +++ b/tools/perf/bench/epoll-ctl.c
> @@ -330,7 +330,7 @@ int bench_epoll_ctl(int argc, const char **argv)
>  	act.sa_sigaction = toggle_done;
>  	sigaction(SIGINT, &act, NULL);
>  
> -	cpu = perf_cpu_map__new(NULL);
> +	cpu = perf_cpu_map__new_online_cpus();
>  	if (!cpu)
>  		goto errmem;
>  
> diff --git a/tools/perf/bench/epoll-wait.c b/tools/perf/bench/epoll-wait.c
> index cb5174b53940..06bb3187660a 100644
> --- a/tools/perf/bench/epoll-wait.c
> +++ b/tools/perf/bench/epoll-wait.c
> @@ -444,7 +444,7 @@ int bench_epoll_wait(int argc, const char **argv)
>  	act.sa_sigaction = toggle_done;
>  	sigaction(SIGINT, &act, NULL);
>  
> -	cpu = perf_cpu_map__new(NULL);
> +	cpu = perf_cpu_map__new_online_cpus();
>  	if (!cpu)
>  		goto errmem;
>  
> diff --git a/tools/perf/bench/futex-hash.c b/tools/perf/bench/futex-hash.c
> index 2005a3fa3026..0c69d20efa32 100644
> --- a/tools/perf/bench/futex-hash.c
> +++ b/tools/perf/bench/futex-hash.c
> @@ -138,7 +138,7 @@ int bench_futex_hash(int argc, const char **argv)
>  		exit(EXIT_FAILURE);
>  	}
>  
> -	cpu = perf_cpu_map__new(NULL);
> +	cpu = perf_cpu_map__new_online_cpus();
>  	if (!cpu)
>  		goto errmem;
>  
> diff --git a/tools/perf/bench/futex-lock-pi.c b/tools/perf/bench/futex-lock-pi.c
> index 092cbd52db82..7a4973346180 100644
> --- a/tools/perf/bench/futex-lock-pi.c
> +++ b/tools/perf/bench/futex-lock-pi.c
> @@ -172,7 +172,7 @@ int bench_futex_lock_pi(int argc, const char **argv)
>  	if (argc)
>  		goto err;
>  
> -	cpu = perf_cpu_map__new(NULL);
> +	cpu = perf_cpu_map__new_online_cpus();
>  	if (!cpu)
>  		err(EXIT_FAILURE, "calloc");
>  
> diff --git a/tools/perf/bench/futex-requeue.c b/tools/perf/bench/futex-requeue.c
> index c0035990a33c..d9ad736c1a3e 100644
> --- a/tools/perf/bench/futex-requeue.c
> +++ b/tools/perf/bench/futex-requeue.c
> @@ -174,7 +174,7 @@ int bench_futex_requeue(int argc, const char **argv)
>  	if (argc)
>  		goto err;
>  
> -	cpu = perf_cpu_map__new(NULL);
> +	cpu = perf_cpu_map__new_online_cpus();
>  	if (!cpu)
>  		err(EXIT_FAILURE, "cpu_map__new");
>  
> diff --git a/tools/perf/bench/futex-wake-parallel.c b/tools/perf/bench/futex-wake-parallel.c
> index 5ab0234d74e6..b66df553e561 100644
> --- a/tools/perf/bench/futex-wake-parallel.c
> +++ b/tools/perf/bench/futex-wake-parallel.c
> @@ -264,7 +264,7 @@ int bench_futex_wake_parallel(int argc, const char **argv)
>  			err(EXIT_FAILURE, "mlockall");
>  	}
>  
> -	cpu = perf_cpu_map__new(NULL);
> +	cpu = perf_cpu_map__new_online_cpus();
>  	if (!cpu)
>  		err(EXIT_FAILURE, "calloc");
>  
> diff --git a/tools/perf/bench/futex-wake.c b/tools/perf/bench/futex-wake.c
> index 18a5894af8bb..690fd6d3da13 100644
> --- a/tools/perf/bench/futex-wake.c
> +++ b/tools/perf/bench/futex-wake.c
> @@ -149,7 +149,7 @@ int bench_futex_wake(int argc, const char **argv)
>  		exit(EXIT_FAILURE);
>  	}
>  
> -	cpu = perf_cpu_map__new(NULL);
> +	cpu = perf_cpu_map__new_online_cpus();
>  	if (!cpu)
>  		err(EXIT_FAILURE, "calloc");
>  
> diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
> index ac2e6c75f912..eb30c8eca488 100644
> --- a/tools/perf/builtin-ftrace.c
> +++ b/tools/perf/builtin-ftrace.c
> @@ -333,7 +333,7 @@ static int set_tracing_func_irqinfo(struct perf_ftrace *ftrace)
>  
>  static int reset_tracing_cpu(void)
>  {
> -	struct perf_cpu_map *cpumap = perf_cpu_map__new(NULL);
> +	struct perf_cpu_map *cpumap = perf_cpu_map__new_online_cpus();
>  	int ret;
>  
>  	ret = set_tracing_cpumask(cpumap);
> diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
> index 8620146d0378..7a3a7bbbec71 100644
> --- a/tools/perf/tests/code-reading.c
> +++ b/tools/perf/tests/code-reading.c
> @@ -610,7 +610,7 @@ static int do_test_code_reading(bool try_kcore)
>  		goto out_put;
>  	}
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (!cpus) {
>  		pr_debug("perf_cpu_map__new failed\n");
>  		goto out_put;
> diff --git a/tools/perf/tests/keep-tracking.c b/tools/perf/tests/keep-tracking.c
> index 8f4f9b632e1e..5a3b2bed07f3 100644
> --- a/tools/perf/tests/keep-tracking.c
> +++ b/tools/perf/tests/keep-tracking.c
> @@ -81,7 +81,7 @@ static int test__keep_tracking(struct test_suite *test __maybe_unused, int subte
>  	threads = thread_map__new(-1, getpid(), UINT_MAX);
>  	CHECK_NOT_NULL__(threads);
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	CHECK_NOT_NULL__(cpus);
>  
>  	evlist = evlist__new();
> diff --git a/tools/perf/tests/mmap-basic.c b/tools/perf/tests/mmap-basic.c
> index 886a13a77a16..012c8ae439fd 100644
> --- a/tools/perf/tests/mmap-basic.c
> +++ b/tools/perf/tests/mmap-basic.c
> @@ -52,7 +52,7 @@ static int test__basic_mmap(struct test_suite *test __maybe_unused, int subtest
>  		return -1;
>  	}
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (cpus == NULL) {
>  		pr_debug("perf_cpu_map__new\n");
>  		goto out_free_threads;
> diff --git a/tools/perf/tests/openat-syscall-all-cpus.c b/tools/perf/tests/openat-syscall-all-cpus.c
> index f3275be83a33..fb114118c876 100644
> --- a/tools/perf/tests/openat-syscall-all-cpus.c
> +++ b/tools/perf/tests/openat-syscall-all-cpus.c
> @@ -37,7 +37,7 @@ static int test__openat_syscall_event_on_all_cpus(struct test_suite *test __mayb
>  		return -1;
>  	}
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (cpus == NULL) {
>  		pr_debug("perf_cpu_map__new\n");
>  		goto out_thread_map_delete;
> diff --git a/tools/perf/tests/perf-time-to-tsc.c b/tools/perf/tests/perf-time-to-tsc.c
> index efcd71c2738a..bbe2ddeb9b74 100644
> --- a/tools/perf/tests/perf-time-to-tsc.c
> +++ b/tools/perf/tests/perf-time-to-tsc.c
> @@ -93,7 +93,7 @@ static int test__perf_time_to_tsc(struct test_suite *test __maybe_unused, int su
>  	threads = thread_map__new(-1, getpid(), UINT_MAX);
>  	CHECK_NOT_NULL__(threads);
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	CHECK_NOT_NULL__(cpus);
>  
>  	evlist = evlist__new();
> diff --git a/tools/perf/tests/switch-tracking.c b/tools/perf/tests/switch-tracking.c
> index e52b031bedc5..5cab17a1942e 100644
> --- a/tools/perf/tests/switch-tracking.c
> +++ b/tools/perf/tests/switch-tracking.c
> @@ -351,7 +351,7 @@ static int test__switch_tracking(struct test_suite *test __maybe_unused, int sub
>  		goto out_err;
>  	}
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (!cpus) {
>  		pr_debug("perf_cpu_map__new failed!\n");
>  		goto out_err;
> diff --git a/tools/perf/tests/topology.c b/tools/perf/tests/topology.c
> index 9dee63734e66..2a842f53fbb5 100644
> --- a/tools/perf/tests/topology.c
> +++ b/tools/perf/tests/topology.c
> @@ -215,7 +215,7 @@ static int test__session_topology(struct test_suite *test __maybe_unused, int su
>  	if (session_write_header(path))
>  		goto free_path;
>  
> -	map = perf_cpu_map__new(NULL);
> +	map = perf_cpu_map__new_online_cpus();
>  	if (map == NULL) {
>  		pr_debug("failed to get system cpumap\n");
>  		goto free_path;
> diff --git a/tools/perf/util/bpf_counter.c b/tools/perf/util/bpf_counter.c
> index 7f9b0e46e008..7a8af60e0f51 100644
> --- a/tools/perf/util/bpf_counter.c
> +++ b/tools/perf/util/bpf_counter.c
> @@ -455,7 +455,7 @@ static int bperf__load(struct evsel *evsel, struct target *target)
>  		return -1;
>  
>  	if (!all_cpu_map) {
> -		all_cpu_map = perf_cpu_map__new(NULL);
> +		all_cpu_map = perf_cpu_map__new_online_cpus();
>  		if (!all_cpu_map)
>  			return -1;
>  	}
> diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
> index 0e090e8bc334..0581ee0fa5f2 100644
> --- a/tools/perf/util/cpumap.c
> +++ b/tools/perf/util/cpumap.c
> @@ -672,7 +672,7 @@ struct perf_cpu_map *cpu_map__online(void) /* thread unsafe */
>  	static struct perf_cpu_map *online;
>  
>  	if (!online)
> -		online = perf_cpu_map__new(NULL); /* from /sys/devices/system/cpu/online */
> +		online = perf_cpu_map__new_online_cpus(); /* from /sys/devices/system/cpu/online */
>  
>  	return online;
>  }
> diff --git a/tools/perf/util/cputopo.c b/tools/perf/util/cputopo.c
> index 81cfc85f4668..8bbeb2dc76fd 100644
> --- a/tools/perf/util/cputopo.c
> +++ b/tools/perf/util/cputopo.c
> @@ -267,7 +267,7 @@ struct cpu_topology *cpu_topology__new(void)
>  	ncpus = cpu__max_present_cpu().cpu;
>  
>  	/* build online CPU map */
> -	map = perf_cpu_map__new(NULL);
> +	map = perf_cpu_map__new_online_cpus();
>  	if (map == NULL) {
>  		pr_debug("failed to get system cpumap\n");
>  		return NULL;
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index ff7f85ded89d..0ed3ce2aa8eb 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -1352,7 +1352,7 @@ static int evlist__create_syswide_maps(struct evlist *evlist)
>  	 * error, and we may not want to do that fallback to a
>  	 * default cpu identity map :-\
>  	 */
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (!cpus)
>  		goto out;
>  
> diff --git a/tools/perf/util/perf_api_probe.c b/tools/perf/util/perf_api_probe.c
> index e1e2d701599c..1de3b69cdf4a 100644
> --- a/tools/perf/util/perf_api_probe.c
> +++ b/tools/perf/util/perf_api_probe.c
> @@ -64,7 +64,7 @@ static bool perf_probe_api(setup_probe_fn_t fn)
>  	struct perf_cpu cpu;
>  	int ret, i = 0;
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (!cpus)
>  		return false;
>  	cpu = perf_cpu_map__cpu(cpus, 0);
> @@ -140,7 +140,7 @@ bool perf_can_record_cpu_wide(void)
>  	struct perf_cpu cpu;
>  	int fd;
>  
> -	cpus = perf_cpu_map__new(NULL);
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (!cpus)
>  		return false;
>  
> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
> index 40290382b2d7..87e817b3cf7e 100644
> --- a/tools/perf/util/record.c
> +++ b/tools/perf/util/record.c
> @@ -238,7 +238,7 @@ bool evlist__can_select_event(struct evlist *evlist, const char *str)
>  	evsel = evlist__last(temp_evlist);
>  
>  	if (!evlist || perf_cpu_map__has_any_cpu_or_is_empty(evlist->core.user_requested_cpus)) {
> -		struct perf_cpu_map *cpus = perf_cpu_map__new(NULL);
> +		struct perf_cpu_map *cpus = perf_cpu_map__new_online_cpus();
>  
>  		if (cpus)
>  			cpu =  perf_cpu_map__cpu(cpus, 0);


From angelogioacchino.delregno at collabora.com  Tue Dec 12 03:44:28 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 12:44:28 +0100
Subject: [GIT,PULL,2/3] MediaTek soc driver updates for v6.8
In-Reply-To: <20231212114515.121695-1-angelogioacchino.delregno@collabora.com>
References: <20231212114515.121695-1-angelogioacchino.delregno@collabora.com>
Message-ID: <20231212114515.121695-2-angelogioacchino.delregno@collabora.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git tags/mtk-soc-for-v6.8

for you to fetch changes up to 2bfbf82956e2de75249ce83901800c68d17d9e62:

  soc: mediatek: mtk-svs: Constify runtime-immutable members of svs_bank (2023-12-11 11:36:15 +0100)

----------------------------------------------------------------
MediaTek soc driver updates for v6.8

This adds a refactoring of the MediaTek Smart Voltage Scaling (SVS)
driver and the addition of support for MT8186 and MT8195 in it, and
adds support for the MT8188 VDOSYS and resets in the MMSYS driver.

----------------------------------------------------------------
AngeloGioacchino Del Regno (17):
      soc: mediatek: mtk-svs: Subtract offset from regs_v2 to avoid conflict
      soc: mediatek: mtk-svs: Convert sw_id and type to enumerations
      soc: mediatek: mtk-svs: Build bank name string dynamically
      soc: mediatek: mtk-svs: Reduce memory footprint of struct svs_bank
      soc: mediatek: mtk-svs: Change the thermal sensor device name
      soc: mediatek: mtk-svs: Add a map to retrieve fused values
      soc: mediatek: mtk-svs: Add SVS-Thermal coefficient to SoC platform data
      soc: mediatek: mtk-svs: Move t-calibration-data retrieval to svs_probe()
      soc: mediatek: mtk-svs: Commonize efuse parse function for most SoCs
      soc: mediatek: mtk-svs: Drop supplementary svs per-bank pointer
      soc: mediatek: mtk-svs: Commonize MT8192 probe function for MT8186
      soc: mediatek: mtk-svs: Remove redundant print in svs_get_efuse_data
      soc: mediatek: mtk-svs: Compress of_device_id entries
      soc: mediatek: mtk-svs: Cleanup of svs_probe() function
      soc: mediatek: mtk-svs: Check if SVS mode is available in the beginning
      soc: mediatek: mtk-svs: Use ULONG_MAX to compare floor frequency
      soc: mediatek: mtk-svs: Constify runtime-immutable members of svs_bank

Hsiao Chien Sung (4):
      soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsys
      soc: mediatek: Support MT8188 VDOSYS1 Padding in mtk-mmsys
      soc: mediatek: Support reset bit mapping in mmsys driver
      soc: mediatek: Add MT8188 VDOSYS reset bit map

Mark Tseng (2):
      soc: mediatek: svs: Add support for MT8195 SoC
      soc: mediatek: svs: Add support for MT8186 SoC

yu-chang.lee (1):
      soc: mediatek: mmsys: Add support for MT8188 VPPSYS

 drivers/soc/mediatek/mt8188-mmsys.h    |  210 ++++++++++++
 drivers/soc/mediatek/mtk-mmsys.c       |   39 +++
 drivers/soc/mediatek/mtk-mmsys.h       |   32 ++
 drivers/soc/mediatek/mtk-mutex.c       |   51 +++
 drivers/soc/mediatek/mtk-svs.c         | 1678 +++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------
 include/linux/soc/mediatek/mtk-mmsys.h |    8 +
 6 files changed, 1342 insertions(+), 676 deletions(-)



From angelogioacchino.delregno at collabora.com  Tue Dec 12 03:44:29 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 12:44:29 +0100
Subject: [GIT,PULL,3/3] MediaTek ARM64 defconfig updates for v6.8
In-Reply-To: <20231212114515.121695-1-angelogioacchino.delregno@collabora.com>
References: <20231212114515.121695-1-angelogioacchino.delregno@collabora.com>
Message-ID: <20231212114515.121695-3-angelogioacchino.delregno@collabora.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git/ tags/mtk-defconfig-for-v6.8

for you to fetch changes up to ebb78614ce2ff73be14ed7339b832e24e381d3fc:

  arm64: defconfig: Enable configs for MT8195-Cherry-Tomato Chromebook (2023-12-12 11:52:15 +0100)

----------------------------------------------------------------
MediaTek ARM64 defconfig updates for v6.8

Those defconfig changes enable booting the MT8173 Chromebooks with the
enablement of the DA9211 regulator driver and adds modules for sound,
AudioDSP, DisplayPort and LVTS Thermal for MT8192/MT8195, and module
for the ChromeOS Keyboard LED backlight which is present on various
Google Chromebooks.

----------------------------------------------------------------
N?colas F. R. A. Prado (1):
      arm64: defconfig: Enable configs for MT8195-Cherry-Tomato Chromebook

Vignesh Raman (1):
      arm64: defconfig: Enable DA9211 regulator

 arch/arm64/configs/defconfig | 13 +++++++++++++
 1 file changed, 13 insertions(+)



From angelogioacchino.delregno at collabora.com  Tue Dec 12 03:44:27 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 12:44:27 +0100
Subject: [GIT,PULL,1/3] MediaTek ARM64 Device Tree updates for v6.8
Message-ID: <20231212114515.121695-1-angelogioacchino.delregno@collabora.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git tags/mtk-dts64-for-v6.8

for you to fetch changes up to 5dc289e08a4d0704583d8df70181cbeb47c817d9:

  arm64: dts: mediatek: mt8192: Add Smart Voltage Scaling node (2023-12-11 11:31:54 +0100)

----------------------------------------------------------------
MediaTek ARM64 DeviceTree updates for v6.8

This adds devicetree bindings and nodes for:
 - Media Data Path 3 (MDP3) bindings and enablement on MT8195
 - Smart Voltage Scaling (SVS) on MT8195
 - LVTS SoC thermal on MT8192
 - MT8188 SoC along with its resets, display bindings, and more
 - MT8183 hardware video decoder (mtk-vcodec-dec)

Adds the following new machines:
 - MT8188 Evaluation Board (EVB)
 - MT8183 Chromebooks: Kukui-Katsu, Jacuzzi-Makomo, Pico, Pico6

Performs cleanups for various MediaTek SoCs and PMICs, and also
includes some spare fixes.

----------------------------------------------------------------
AngeloGioacchino Del Regno (11):
      arm64: dts: mediatek: cherry: Add platform thermal configuration
      arm64: dts: mediatek: mt8183: Use interrupts-extended where possible
      arm64: dts: mediatek: mt8173: Use interrupts-extended where possible
      arm64: dts: mediatek: Use interrupts-extended where possible
      arm64: dts: mediatek: Move MT6358 PMIC interrupts to MT8183 boards
      arm64: dts: mediatek: mt8195-cherry: Add MFG0 domain supply
      arm64: dts: mediatek: mt8195-cherry: Assign sram supply to MFG1 pd
      media: dt-bindings: mediatek: Add phandle to mediatek,scp on MDP3 RDMA
      arm64: dts: mediatek: mt8183: Change iospaces for thermal and svs
      arm64: dts: mediatek: mt8195: Add SVS node and reduce LVTS_AP iospace
      arm64: dts: mediatek: mt8192: Add Smart Voltage Scaling node

Balsam CHIHI (1):
      arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones

Chen-Yu Tsai (4):
      arm64: dts: mediatek: mt6358: Merge ldo_vcn33_* regulators
      arm64: dts: mt8183: kukui-jacuzzi: Drop bogus anx7625 panel_flag property
      arm64: dts: mt6358: Drop bogus "regulator-fixed" compatible properties
      arm64: dts: mediatek: mt8186: Fix alias prefix for ovl_2l0

Eugen Hristev (2):
      dt-bindings: arm: mediatek: convert audsys and mt2701-afe-pcm to yaml
      arm64: dts: mediatek: mt8186: fix address warning for ADSP mailboxes

Hsiao Chien Sung (6):
      dt-bindings: display: mediatek: ethdr: Add compatible for MT8188
      dt-bindings: display: mediatek: mdp-rdma: Add compatible for MT8188
      dt-bindings: display: mediatek: merge: Add compatible for MT8188
      dt-bindings: display: mediatek: padding: Add MT8188
      dt-bindings: arm: mediatek: Add compatible for MT8188
      dt-bindings: reset: mt8188: Add VDOSYS reset control bits

Hsin-Yi Wang (6):
      dt-bindings: arm64: mediatek: Add mt8183-kukui-katsu
      arm64: dts: mt8183: Add kukui katsu board
      dt-bindings: arm64: mediatek: Add mt8183-kukui-jacuzzi-makomo
      arm64: dts: mt8183: Add jacuzzi makomo board
      dt-bindings: arm64: mediatek: Add mt8183-kukui-jacuzzi-pico
      arm64: dts: mt8183: Add jacuzzi pico/pico6 board

Mark Tseng (1):
      dt-bindings: soc: mediatek: add mt8186 and mt8195 svs dt-bindings

Michael Walle (2):
      dt-bindings: display: mediatek: dsi: add compatible for MediaTek MT8195
      arm64: dts: mediatek: mt8195: add DSI and MIPI DPHY nodes

Moudy Ho (19):
      dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with generic names
      dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under display
      dt-bindings: media: mediatek: mdp3: add config for MT8195 RDMA
      dt-bindings: media: mediatek: mdp3: add compatible for MT8195 RSZ
      dt-bindings: media: mediatek: mdp3: add compatible for MT8195 WROT
      dt-bindings: media: mediatek: mdp3: add component FG for MT8195
      dt-bindings: media: mediatek: mdp3: add component HDR for MT8195
      dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
      dt-bindings: media: mediatek: mdp3: add component TCC for MT8195
      dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195
      dt-bindings: display: mediatek: aal: add compatible for MT8195
      dt-bindings: display: mediatek: color: add compatible for MT8195
      dt-bindings: display: mediatek: merge: add compatible for MT8195
      dt-bindings: display: mediatek: ovl: add compatible for MT8195
      dt-bindings: display: mediatek: split: add compatible for MT8195
      dt-bindings: display: mediatek: padding: add compatible for MT8195
      arm64: dts: mediatek: mt8183: correct MDP3 DMA-related nodes
      arm64: dts: mediatek: mt8195: revise VDOSYS RDMA node name
      arm64: dts: mediatek: mt8195: add MDP3 nodes

N?colas F. R. A. Prado (1):
      arm64: dts: mediatek: mt8173: Drop VDEC_SYS reg from decoder

Rafa? Mi?ecki (1):
      dt-bindings: thermal: convert Mediatek Thermal to the json-schema

Yunfei Dong (1):
      arm64: dts: mediatek: mt8183: Add decoder

jason-ch chen (4):
      dt-bindings: arm: Add compatible for MediaTek MT8188
      dt-bindings: arm: mediatek: Add mt8188 pericfg compatible
      dt-bindings: soc: mediatek: pwrap: Modify compatible for MT8188
      arm64: dts: Add MediaTek MT8188 dts and evaluation board and Makefile

yu-chang.lee (1):
      dt-bindings: arm: mediatek: mmsys: Add VPPSYS compatible for MT8188

 Documentation/devicetree/bindings/arm/mediatek.yaml                       |  25 ++
 Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt        |  39 ---
 Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml       | 153 +++++++++
 Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml        |   3 +
 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml      |   1 +
 Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml        |   2 -
 Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml      |   1 +
 Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml    |   1 +
 Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml      |   4 +
 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml    |   6 +-
 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml |  88 -----
 Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml    |   4 +
 Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml      |   1 +
 Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml  |  83 +++++
 Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml    |  27 ++
 Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml             |  61 ++++
 Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml            |  61 ++++
 Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml           | 104 +++++-
 Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml            |   6 +-
 Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml         |  61 ++++
 Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml            |  62 ++++
 Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml          |  61 ++++
 Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml           |  29 +-
 Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml        |   6 +-
 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml               |   2 +
 Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml        | 116 +++++++
 Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt                | 146 ---------
 Documentation/devicetree/bindings/thermal/mediatek,thermal.yaml           |  99 ++++++
 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt            |  52 ---
 arch/arm64/boot/dts/mediatek/Makefile                                     |   7 +
 arch/arm64/boot/dts/mediatek/mt6358.dtsi                                  |  26 +-
 arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts                  |   3 +-
 arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts                  |   3 +-
 arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi                         |   9 +-
 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi                              |  24 +-
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts                               |   3 +-
 arch/arm64/boot/dts/mediatek/mt8173.dtsi                                  |   8 +-
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts                               |   4 +
 arch/arm64/boot/dts/mediatek/mt8183-kukui-audio-da7219.dtsi               |   3 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui-audio-ts3a227e.dtsi             |   3 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts                |   3 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dts         |   3 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dts         |   3 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku7.dts         |   3 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-makomo-sku0.dts         |  24 ++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-makomo-sku1.dts         |  24 ++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-pico.dts                |  35 ++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-pico6.dts               | 110 +++++++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi                    |   1 -
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu-sku22.dts                |  18 ++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dts                      |  18 ++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi                     |  15 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui-katsu-sku32.dts                 |  36 +++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-katsu-sku38.dts                 |  40 +++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi                     |   3 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi                      |   3 +-
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi                            |  10 +-
 arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts                           |   4 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi                                  |  62 +++-
 arch/arm64/boot/dts/mediatek/mt8186.dtsi                                  |   6 +-
 arch/arm64/boot/dts/mediatek/mt8188-evb.dts                               | 387 ++++++++++++++++++++++
 arch/arm64/boot/dts/mediatek/mt8188.dtsi                                  | 956 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/mediatek/mt8192.dtsi                                  | 466 +++++++++++++++++++++++++++
 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi                           | 115 ++++++-
 arch/arm64/boot/dts/mediatek/mt8195.dtsi                                  | 483 +++++++++++++++++++++++++++-
 arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts                    |   6 +-
 include/dt-bindings/reset/mt8188-resets.h                                 |  75 +++++
 67 files changed, 3826 insertions(+), 480 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
 create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
 delete mode 100644 Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
 create mode 100644 Documentation/devicetree/bindings/thermal/mediatek,thermal.yaml
 delete mode 100644 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-makomo-sku0.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-makomo-sku1.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-pico.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-pico6.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-katsu-sku32.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-katsu-sku38.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8188-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8188.dtsi



From ryan.roberts at arm.com  Tue Dec 12 03:47:03 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 12 Dec 2023 11:47:03 +0000
Subject: [PATCH v3 12/15] arm64/mm: Split __flush_tlb_range() to elide
 trailing DSB
In-Reply-To: <20231212113517.GA28857@willie-the-truck>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-13-ryan.roberts@arm.com>
 <20231212113517.GA28857@willie-the-truck>
Message-ID: <0969c413-bf40-4c46-9f1e-a92101ff2d2e@arm.com>

On 12/12/2023 11:35, Will Deacon wrote:
> On Mon, Dec 04, 2023 at 10:54:37AM +0000, Ryan Roberts wrote:
>> Split __flush_tlb_range() into __flush_tlb_range_nosync() +
>> __flush_tlb_range(), in the same way as the existing flush_tlb_page()
>> arrangement. This allows calling __flush_tlb_range_nosync() to elide the
>> trailing DSB. Forthcoming "contpte" code will take advantage of this
>> when clearing the young bit from a contiguous range of ptes.
>>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
>>  arch/arm64/include/asm/tlbflush.h | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
>> index bb2c2833a987..925ef3bdf9ed 100644
>> --- a/arch/arm64/include/asm/tlbflush.h
>> +++ b/arch/arm64/include/asm/tlbflush.h
>> @@ -399,7 +399,7 @@ do {									\
>>  #define __flush_s2_tlb_range_op(op, start, pages, stride, tlb_level) \
>>  	__flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false)
>>  
>> -static inline void __flush_tlb_range(struct vm_area_struct *vma,
>> +static inline void __flush_tlb_range_nosync(struct vm_area_struct *vma,
>>  				     unsigned long start, unsigned long end,
>>  				     unsigned long stride, bool last_level,
>>  				     int tlb_level)
>> @@ -431,10 +431,19 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
>>  	else
>>  		__flush_tlb_range_op(vae1is, start, pages, stride, asid, tlb_level, true);
>>  
>> -	dsb(ish);
>>  	mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, start, end);
>>  }
>>  
>> +static inline void __flush_tlb_range(struct vm_area_struct *vma,
>> +				     unsigned long start, unsigned long end,
>> +				     unsigned long stride, bool last_level,
>> +				     int tlb_level)
>> +{
>> +	__flush_tlb_range_nosync(vma, start, end, stride,
>> +				 last_level, tlb_level);
>> +	dsb(ish);
>> +}
> 
> Hmm, are you sure it's safe to defer the DSB until after the secondary TLB
> invalidation? It will have a subtle effect on e.g. an SMMU participating
> in broadcast TLB maintenance, because now the ATC will be invalidated
> before completion of the TLB invalidation and it's not obviously safe to me.

I'll be honest; I don't know that it's safe. The notifier calls turned up during
a rebase and I stared at it for a while, before eventually concluding that I
should just follow the existing pattern in __flush_tlb_page_nosync(): That one
calls the mmu notifier without the dsb, then flush_tlb_page() does the dsb
after. So I assumed it was safe.

If you think it's not safe, I guess there is a bug to fix in
__flush_tlb_page_nosync()?



> 
> Will



From u.kleine-koenig at pengutronix.de  Tue Dec 12 03:50:23 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 12:50:23 +0100
Subject: [PATCH v8 5/6] pwm: bcm2835: Allow PWM driver to be used in
 atomic context
In-Reply-To: <e9e32c9789da3c90b5a2aa7d5a093120b76421fb.1702369869.git.sean@mess.org>
References: <cover.1702369869.git.sean@mess.org>
 <e9e32c9789da3c90b5a2aa7d5a093120b76421fb.1702369869.git.sean@mess.org>
Message-ID: <20231212115023.r5pl2o5em6wl3zr7@pengutronix.de>

On Tue, Dec 12, 2023 at 08:34:04AM +0000, Sean Young wrote:
> clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
> rate changes using clk_rate_exclusive_get().
> 
> Signed-off-by: Sean Young <sean at mess.org>
> Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>

Looks good,

Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/6cdb2322/attachment-0001.sig>

From ryan.roberts at arm.com  Tue Dec 12 03:51:53 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 12 Dec 2023 11:51:53 +0000
Subject: [PATCH v3 01/15] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <87lea5a5qm.fsf@nvdebian.thelocal>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-2-ryan.roberts@arm.com>
 <87lea5a5qm.fsf@nvdebian.thelocal>
Message-ID: <f6792c43-1305-4c79-8bfb-c77919f0d0a1@arm.com>

On 08/12/2023 00:32, Alistair Popple wrote:
> 
> Ryan Roberts <ryan.roberts at arm.com> writes:
> 
> <snip>
> 
>>  /*
>>   * On some architectures hardware does not set page access bit when accessing
>>   * memory page, it is responsibility of software setting this bit. It brings
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 1f18ed4a5497..8a87a488950c 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -924,68 +924,162 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
>>  	return 0;
>>  }
>>  
>> +static int folio_nr_pages_cont_mapped(struct folio *folio,
>> +				      struct page *page, pte_t *pte,
>> +				      unsigned long addr, unsigned long end,
>> +				      pte_t ptent, bool enforce_uffd_wp,
>> +				      int *dirty_nr, int *writable_nr)
>> +{
>> +	int floops;
>> +	int i;
>> +	unsigned long pfn;
>> +	bool prot_none;
>> +	bool uffd_wp;
>> +
>> +	if (!folio_test_large(folio))
>> +		return 1;
>> +
>> +	/*
>> +	 * Loop either to `end` or to end of folio if its contiguously mapped,
>> +	 * whichever is smaller.
>> +	 */
>> +	floops = (end - addr) >> PAGE_SHIFT;
>> +	floops = min_t(int, floops,
>> +		       folio_pfn(folio_next(folio)) - page_to_pfn(page));
> 
> Much better, thanks for addressing my comments here.
> 
>> +
>> +	pfn = page_to_pfn(page);
>> +	prot_none = pte_protnone(ptent);
>> +	uffd_wp = pte_uffd_wp(ptent);
>> +
>> +	*dirty_nr = !!pte_dirty(ptent);
>> +	*writable_nr = !!pte_write(ptent);
>> +
>> +	pfn++;
>> +	pte++;
>> +
>> +	for (i = 1; i < floops; i++) {
>> +		ptent = ptep_get(pte);
>> +
>> +		if (!pte_present(ptent) || pte_pfn(ptent) != pfn ||
>> +		    prot_none != pte_protnone(ptent) ||
>> +		    (enforce_uffd_wp && uffd_wp != pte_uffd_wp(ptent)))
>> +			break;
>> +
>> +		if (pte_dirty(ptent))
>> +			(*dirty_nr)++;
>> +		if (pte_write(ptent))
>> +			(*writable_nr)++;
>> +
>> +		pfn++;
>> +		pte++;
>> +	}
>> +
>> +	return i;
>> +}
>> +
>>  /*
>> - * Copy one pte.  Returns 0 if succeeded, or -EAGAIN if one preallocated page
>> - * is required to copy this pte.
>> + * Copy set of contiguous ptes.  Returns number of ptes copied if succeeded
>> + * (always gte 1), or -EAGAIN if one preallocated page is required to copy the
>> + * first pte.
>>   */
>>  static inline int
>> -copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>> -		 pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
>> -		 struct folio **prealloc)
>> +copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>> +		  pte_t *dst_pte, pte_t *src_pte,
>> +		  unsigned long addr, unsigned long end,
>> +		  int *rss, struct folio **prealloc)
>>  {
>>  	struct mm_struct *src_mm = src_vma->vm_mm;
>>  	unsigned long vm_flags = src_vma->vm_flags;
>>  	pte_t pte = ptep_get(src_pte);
>>  	struct page *page;
>>  	struct folio *folio;
>> +	int nr = 1;
>> +	bool anon = false;
>> +	bool enforce_uffd_wp = userfaultfd_wp(dst_vma);
>> +	int nr_dirty = !!pte_dirty(pte);
>> +	int nr_writable = !!pte_write(pte);
>> +	int i, ret;
>>  
>>  	page = vm_normal_page(src_vma, addr, pte);
>> -	if (page)
>> +	if (page) {
>>  		folio = page_folio(page);
>> -	if (page && folio_test_anon(folio)) {
>> -		/*
>> -		 * If this page may have been pinned by the parent process,
>> -		 * copy the page immediately for the child so that we'll always
>> -		 * guarantee the pinned page won't be randomly replaced in the
>> -		 * future.
>> -		 */
>> -		folio_get(folio);
>> -		if (unlikely(page_try_dup_anon_rmap(page, false, src_vma))) {
>> -			/* Page may be pinned, we have to copy. */
>> -			folio_put(folio);
>> -			return copy_present_page(dst_vma, src_vma, dst_pte, src_pte,
>> -						 addr, rss, prealloc, page);
>> +		anon = folio_test_anon(folio);
>> +		nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr, end,
>> +						pte, enforce_uffd_wp, &nr_dirty,
>> +						&nr_writable);
>> +		folio_ref_add(folio, nr);
>> +
>> +		for (i = 0; i < nr; i++, page++) {
>> +			if (anon) {
>> +				/*
>> +				 * If this page may have been pinned by the
>> +				 * parent process, copy the page immediately for
>> +				 * the child so that we'll always guarantee the
>> +				 * pinned page won't be randomly replaced in the
>> +				 * future.
>> +				 */
>> +				if (unlikely(page_try_dup_anon_rmap(
>> +						page, false, src_vma))) {
>> +					if (i != 0)
>> +						break;
>> +					/* Page may be pinned, we have to copy. */
>> +					folio_ref_sub(folio, nr);
>> +					ret = copy_present_page(
>> +						dst_vma, src_vma, dst_pte,
>> +						src_pte, addr, rss, prealloc,
>> +						page);
>> +					return ret == 0 ? 1 : ret;
>> +				}
>> +				rss[MM_ANONPAGES]++;
>> +				VM_BUG_ON(PageAnonExclusive(page));
>> +			} else {
>> +				page_dup_file_rmap(page, false);
>> +				rss[mm_counter_file(page)]++;
>> +			}
>>  		}
>> -		rss[MM_ANONPAGES]++;
>> -	} else if (page) {
>> -		folio_get(folio);
>> -		page_dup_file_rmap(page, false);
>> -		rss[mm_counter_file(page)]++;
>> -	}
>>  
>> -	/*
>> -	 * If it's a COW mapping, write protect it both
>> -	 * in the parent and the child
>> -	 */
>> -	if (is_cow_mapping(vm_flags) && pte_write(pte)) {
>> -		ptep_set_wrprotect(src_mm, addr, src_pte);
>> -		pte = pte_wrprotect(pte);
>> +		if (i < nr) {
>> +			folio_ref_sub(folio, nr - i);
>> +			nr = i;
>> +		}
>>  	}
>> -	VM_BUG_ON(page && folio_test_anon(folio) && PageAnonExclusive(page));
>>  
>>  	/*
>> -	 * If it's a shared mapping, mark it clean in
>> -	 * the child
>> +	 * If it's a shared mapping, mark it clean and write protected in the
>> +	 * child, and rely on a write fault to fix up the permissions. This
>> +	 * allows determining batch size without having to consider RO/RW
>> +	 * permissions. As an optimization, skip wrprotect if all ptes in the
>> +	 * batch have the same permissions.
>> +	 *
>> +	 * If its a private (CoW) mapping, mark it dirty in the child if _any_
>> +	 * of the parent mappings in the block were marked dirty. The contiguous
>> +	 * block of mappings are all backed by the same folio, so if any are
>> +	 * dirty then the whole folio is dirty. This allows determining batch
>> +	 * size without having to consider the dirty bit. Further, write protect
>> +	 * it both in the parent and the child so that a future write will cause
>> +	 * a CoW. As as an optimization, skip the wrprotect if all the ptes in
>> +	 * the batch are already readonly.
>>  	 */
>> -	if (vm_flags & VM_SHARED)
>> +	if (vm_flags & VM_SHARED) {
>>  		pte = pte_mkclean(pte);
>> -	pte = pte_mkold(pte);
>> +		if (nr_writable > 0 && nr_writable < nr)
>> +			pte = pte_wrprotect(pte);
>> +	} else {
>> +		if (nr_dirty)
>> +			pte = pte_mkdirty(pte);
>> +		if (nr_writable) {
>> +			ptep_set_wrprotects(src_mm, addr, src_pte, nr);
>> +			pte = pte_wrprotect(pte);
>> +		}
>> +	}
>>  
>> -	if (!userfaultfd_wp(dst_vma))
>> +	pte = pte_mkold(pte);
>> +	pte = pte_clear_soft_dirty(pte);
>> +	if (!enforce_uffd_wp)
>>  		pte = pte_clear_uffd_wp(pte);
>>  
>> -	set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte);
>> -	return 0;
>> +	set_ptes(dst_vma->vm_mm, addr, dst_pte, pte, nr);
>> +	return nr;
> 
> I don't have any further comments and you have addressed my previous
> ones so feel free to add:
> 
> Reviewed-by: Alistair Popple <apopple at nvidia.com>
> 
> However whilst I think the above CoW sequence looks correct it would be
> nice if someone else could take a look as well.

Thanks for the RB! David has taken a look at the CoW part and helped develop the
logic, so I'm pretty confident in it.

However, David also sent me some microbenchmarks for fork, DONTNEED, munmap, etc
for order-0 and PTE-mapped THP (2M). I'm seeing a ferw performance regressions
with those, which I'm currently trying to resolve. At the moment it's looking
like I'll have to expose some function to allow the core code to skip forward a
number of ptes so that in the contpte-mapped case, the core code only does
ptep_get() once per contpte block. As a result there will be some churn here.

I'm currently working out some bugs and hope to post an updated series with perf
numbers for those microbenchmarks by the end of the week, all being well.

> 
>>  }
>>  
>>  static inline struct folio *page_copy_prealloc(struct mm_struct *src_mm,
>> @@ -1021,6 +1115,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>>  	int rss[NR_MM_COUNTERS];
>>  	swp_entry_t entry = (swp_entry_t){0};
>>  	struct folio *prealloc = NULL;
>> +	int nr_ptes;
>>  
>>  again:
>>  	progress = 0;
>> @@ -1051,6 +1146,8 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>>  	arch_enter_lazy_mmu_mode();
>>  
>>  	do {
>> +		nr_ptes = 1;
>> +
>>  		/*
>>  		 * We are holding two locks at this point - either of them
>>  		 * could generate latencies in another task on another CPU.
>> @@ -1086,16 +1183,21 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>>  			 * the now present pte.
>>  			 */
>>  			WARN_ON_ONCE(ret != -ENOENT);
>> +			ret = 0;
>>  		}
>> -		/* copy_present_pte() will clear `*prealloc' if consumed */
>> -		ret = copy_present_pte(dst_vma, src_vma, dst_pte, src_pte,
>> -				       addr, rss, &prealloc);
>> +		/* copy_present_ptes() will clear `*prealloc' if consumed */
>> +		nr_ptes = copy_present_ptes(dst_vma, src_vma, dst_pte, src_pte,
>> +					    addr, end, rss, &prealloc);
>> +
>>  		/*
>>  		 * If we need a pre-allocated page for this pte, drop the
>>  		 * locks, allocate, and try again.
>>  		 */
>> -		if (unlikely(ret == -EAGAIN))
>> +		if (unlikely(nr_ptes == -EAGAIN)) {
>> +			ret = -EAGAIN;
>>  			break;
>> +		}
>> +
>>  		if (unlikely(prealloc)) {
>>  			/*
>>  			 * pre-alloc page cannot be reused by next time so as
>> @@ -1106,8 +1208,9 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>>  			folio_put(prealloc);
>>  			prealloc = NULL;
>>  		}
>> -		progress += 8;
>> -	} while (dst_pte++, src_pte++, addr += PAGE_SIZE, addr != end);
>> +		progress += 8 * nr_ptes;
>> +	} while (dst_pte += nr_ptes, src_pte += nr_ptes,
>> +		 addr += PAGE_SIZE * nr_ptes, addr != end);
>>  
>>  	arch_leave_lazy_mmu_mode();
>>  	pte_unmap_unlock(orig_src_pte, src_ptl);
> 



From quic_mnaresh at quicinc.com  Tue Dec 12 03:55:10 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Tue, 12 Dec 2023 17:25:10 +0530
Subject: [PATCH V3 2/2] ufs: ufs-mediatek: Enable CPU latency PM QoS support for MEDIATEK SoC
In-Reply-To: <20231212115510.30935-1-quic_mnaresh@quicinc.com>
References: <20231212115510.30935-1-quic_mnaresh@quicinc.com>
Message-ID: <20231212115510.30935-3-quic_mnaresh@quicinc.com>

Revert the existing PM QoS feature from MEDIATEK UFS driver as similar
PM QoS feature implementation is moved to core ufshcd and also enable
CPU latency PM QoS capability for MEDIATEK SoC.

Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/host/ufs-mediatek.c | 20 +++-----------------
 drivers/ufs/host/ufs-mediatek.h |  3 ---
 2 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index fc61790d289b..d8ece88103b9 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -17,7 +17,6 @@
 #include <linux/of_platform.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
-#include <linux/pm_qos.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
@@ -626,21 +625,9 @@ static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
 	dev_info(hba->dev, "caps: 0x%x", host->caps);
 }
 
-static void ufs_mtk_boost_pm_qos(struct ufs_hba *hba, bool boost)
-{
-	struct ufs_mtk_host *host = ufshcd_get_variant(hba);
-
-	if (!host || !host->pm_qos_init)
-		return;
-
-	cpu_latency_qos_update_request(&host->pm_qos_req,
-				       boost ? 0 : PM_QOS_DEFAULT_VALUE);
-}
-
 static void ufs_mtk_scale_perf(struct ufs_hba *hba, bool scale_up)
 {
 	ufs_mtk_boost_crypt(hba, scale_up);
-	ufs_mtk_boost_pm_qos(hba, scale_up);
 }
 
 static void ufs_mtk_pwr_ctrl(struct ufs_hba *hba, bool on)
@@ -937,6 +924,9 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 	/* Enable clk scaling*/
 	hba->caps |= UFSHCD_CAP_CLK_SCALING;
 
+	/* Enable PM QoS */
+	hba->caps |= UFSHCD_CAP_PM_QOS;
+
 	hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
 	hba->quirks |= UFSHCD_QUIRK_MCQ_BROKEN_INTR;
 	hba->quirks |= UFSHCD_QUIRK_MCQ_BROKEN_RTC;
@@ -959,10 +949,6 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
 	host->ip_ver = ufshcd_readl(hba, REG_UFS_MTK_IP_VER);
 
-	/* Initialize pm-qos request */
-	cpu_latency_qos_add_request(&host->pm_qos_req, PM_QOS_DEFAULT_VALUE);
-	host->pm_qos_init = true;
-
 	goto out;
 
 out_variant_clear:
diff --git a/drivers/ufs/host/ufs-mediatek.h b/drivers/ufs/host/ufs-mediatek.h
index f76e80d91729..38eab95b0f79 100644
--- a/drivers/ufs/host/ufs-mediatek.h
+++ b/drivers/ufs/host/ufs-mediatek.h
@@ -7,7 +7,6 @@
 #define _UFS_MEDIATEK_H
 
 #include <linux/bitops.h>
-#include <linux/pm_qos.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
 
 /*
@@ -167,7 +166,6 @@ struct ufs_mtk_mcq_intr_info {
 
 struct ufs_mtk_host {
 	struct phy *mphy;
-	struct pm_qos_request pm_qos_req;
 	struct regulator *reg_va09;
 	struct reset_control *hci_reset;
 	struct reset_control *unipro_reset;
@@ -178,7 +176,6 @@ struct ufs_mtk_host {
 	struct ufs_mtk_hw_ver hw_ver;
 	enum ufs_mtk_host_caps caps;
 	bool mphy_powered_on;
-	bool pm_qos_init;
 	bool unipro_lpm;
 	bool ref_clk_enabled;
 	u16 ref_clk_ungating_wait_us;
-- 
2.17.1



From quic_mnaresh at quicinc.com  Tue Dec 12 03:55:08 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Tue, 12 Dec 2023 17:25:08 +0530
Subject: [PATCH V3 0/2] Add CPU latency QoS support for ufs driver 
Message-ID: <20231212115510.30935-1-quic_mnaresh@quicinc.com>

Add CPU latency QoS support for ufs driver. This improves random io
performance by 15% for ufs.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 37101.3
	Random Write(IPOS) | 41065.13

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 42943.4
	Random Write(IPOS) | 46784.9
(Improvement with PM QoS = ~15%).

This patch is based on below patch by Stanley Chu [1]. 
Moving the PM QoS code to ufshcd.c and making it generic.

[1] https://lore.kernel.org/r/20220623035052.18802-8-stanley.chu at mediatek.com

Changes from v2:
- Addressed bvanassche and mani comments
- Provided sysfs interface to enable/disable PM QoS feature

Changes from v1:
- Addressed bvanassche comments to have the code in core ufshcd
- Design is changed from per-device PM QoS to CPU latency QoS based support
- Reverted existing PM QoS feature from MEDIATEK UFS driver

Maramaina Naresh (2):
  ufs: core: Add CPU latency QoS support for ufs driver
  ufs: ufs-mediatek: Enable CPU latency PM QoS support for MEDIATEK SoC

 drivers/ufs/core/ufshcd.c       | 127 ++++++++++++++++++++++++++++++++
 drivers/ufs/host/ufs-mediatek.c |  20 +----
 drivers/ufs/host/ufs-mediatek.h |   3 -
 include/ufs/ufshcd.h            |   6 ++
 4 files changed, 136 insertions(+), 20 deletions(-)

-- 
2.17.1



From quic_mnaresh at quicinc.com  Tue Dec 12 03:55:09 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Tue, 12 Dec 2023 17:25:09 +0530
Subject: [PATCH V3 1/2] ufs: core: Add CPU latency QoS support for ufs driver
In-Reply-To: <20231212115510.30935-1-quic_mnaresh@quicinc.com>
References: <20231212115510.30935-1-quic_mnaresh@quicinc.com>
Message-ID: <20231212115510.30935-2-quic_mnaresh@quicinc.com>

Register ufs driver to CPU latency PM QoS framework to improve
ufs device random io performance.

PM QoS initialization will insert new QoS request into the CPU
latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
value.

UFS driver will vote for performance mode on scale up and power
save mode for scale down.

If clock scaling feature is not enabled then voting will be based
on clock on or off condition.

Provided sysfs interface to enable/disable PM QoS feature.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 41065.13
	Random Read(IPOS)  | 37101.3

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 46784.9
	Random Read(IPOS)  | 42943.4
(Improvement with PM QoS = ~15%).

Co-developed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall at quicinc.com>
Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/core/ufshcd.c | 127 ++++++++++++++++++++++++++++++++++++++
 include/ufs/ufshcd.h      |   6 ++
 2 files changed, 133 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index ae9936fc6ffb..7318fa480706 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1001,6 +1001,20 @@ static bool ufshcd_is_unipro_pa_params_tuning_req(struct ufs_hba *hba)
 	return ufshcd_get_local_unipro_ver(hba) < UFS_UNIPRO_VER_1_6;
 }
 
+/**
+ * ufshcd_pm_qos_update - update PM QoS request
+ * @hba: per adapter instance
+ * @on: If True, vote for perf PM QoS mode otherwise power save mode
+ */
+static void ufshcd_pm_qos_update(struct ufs_hba *hba, bool on)
+{
+	if (!hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? 0
+							: PM_QOS_DEFAULT_VALUE);
+}
+
 /**
  * ufshcd_set_clk_freq - set UFS controller clock frequencies
  * @hba: per adapter instance
@@ -1147,8 +1161,11 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, unsigned long freq,
 					    hba->devfreq->previous_freq);
 		else
 			ufshcd_set_clk_freq(hba, !scale_up);
+		goto out;
 	}
 
+	ufshcd_pm_qos_update(hba, scale_up);
+
 out:
 	trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
 			(scale_up ? "up" : "down"),
@@ -8615,6 +8632,109 @@ static void ufshcd_set_timestamp_attr(struct ufs_hba *hba)
 	ufshcd_release(hba);
 }
 
+/**
+ * ufshcd_pm_qos_init - initialize PM QoS request
+ * @hba: per adapter instance
+ */
+static void ufshcd_pm_qos_init(struct ufs_hba *hba)
+{
+
+	if (hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_add_request(&hba->pm_qos_req,
+					PM_QOS_DEFAULT_VALUE);
+
+	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
+		hba->pm_qos_enabled = true;
+}
+
+/**
+ * ufshcd_pm_qos_exit - remove request from PM QoS
+ * @hba: per adapter instance
+ */
+static void ufshcd_pm_qos_exit(struct ufs_hba *hba)
+{
+	if (!hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_remove_request(&hba->pm_qos_req);
+	hba->pm_qos_enabled = false;
+}
+
+/**
+ * ufshcd_pm_qos_enable_show - sysfs handler to show pm qos enable value
+ * @dev: device associated with the UFS controller
+ * @attr: sysfs attribute handle
+ * @buf: buffer for sysfs file
+ *
+ * Print 1 if PM QoS feature is enabled, 0 if disabled.
+ *
+ * Returns number of characters written to @buf.
+ */
+static ssize_t ufshcd_pm_qos_enable_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	return sysfs_emit(buf, "%d\n", hba->pm_qos_enabled);
+}
+
+/**
+ * ufshcd_pm_qos_enable_store - sysfs handler to store value
+ * @dev: device associated with the UFS controller
+ * @attr: sysfs attribute handle
+ * @buf: buffer for sysfs file
+ * @count: stores buffer characters count
+ *
+ * Input 0 to disable PM QoS and any non-zero positive value to enable.
+ * Default state: 1
+ *
+ * Return: number of characters written to @buf on success, < 0 upon failure.
+ */
+static ssize_t ufshcd_pm_qos_enable_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+	u32 value;
+
+	if (kstrtou32(buf, 0, &value))
+		return -EINVAL;
+
+	value = !!value;
+	if (value)
+		ufshcd_pm_qos_init(hba);
+	else
+		ufshcd_pm_qos_exit(hba);
+
+	return count;
+}
+
+/**
+ * ufshcd_init_pm_qos_sysfs - initialize PM QoS sysfs entry
+ * @hba: per adapter instance
+ */
+static void ufshcd_init_pm_qos_sysfs(struct ufs_hba *hba)
+{
+	hba->pm_qos_enable_attr.show = ufshcd_pm_qos_enable_show;
+	hba->pm_qos_enable_attr.store = ufshcd_pm_qos_enable_store;
+	sysfs_attr_init(&hba->pm_qos_enable_attr.attr);
+	hba->pm_qos_enable_attr.attr.name = "pm_qos_enable";
+	hba->pm_qos_enable_attr.attr.mode = 0644;
+	if (device_create_file(hba->dev, &hba->pm_qos_enable_attr))
+		dev_err(hba->dev, "Failed to create sysfs for pm_qos_enable\n");
+}
+
+/**
+ * ufshcd_remove_pm_qos_sysfs - remove PM QoS sysfs entry
+ * @hba: per adapter instance
+ */
+static void ufshcd_remove_pm_qos_sysfs(struct ufs_hba *hba)
+{
+	if (hba->pm_qos_enable_attr.attr.name)
+		device_remove_file(hba->dev, &hba->pm_qos_enable_attr);
+}
+
 /**
  * ufshcd_add_lus - probe and add UFS logical units
  * @hba: per-adapter instance
@@ -9204,6 +9324,8 @@ static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
 	if (ret)
 		return ret;
 
+	if (!ufshcd_is_clkscaling_supported(hba))
+		ufshcd_pm_qos_update(hba, on);
 out:
 	if (ret) {
 		list_for_each_entry(clki, head, list) {
@@ -9381,6 +9503,8 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
 static void ufshcd_hba_exit(struct ufs_hba *hba)
 {
 	if (hba->is_powered) {
+		ufshcd_remove_pm_qos_sysfs(hba);
+		ufshcd_pm_qos_exit(hba);
 		ufshcd_exit_clk_scaling(hba);
 		ufshcd_exit_clk_gating(hba);
 		if (hba->eh_wq)
@@ -10030,6 +10154,7 @@ static int ufshcd_suspend(struct ufs_hba *hba)
 	ufshcd_vreg_set_lpm(hba);
 	/* Put the host controller in low power mode if possible */
 	ufshcd_hba_vreg_set_lpm(hba);
+	ufshcd_pm_qos_update(hba, false);
 	return ret;
 }
 
@@ -10576,6 +10701,8 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 	ufs_sysfs_add_nodes(hba->dev);
 
 	device_enable_async_suspend(dev);
+	ufshcd_pm_qos_init(hba);
+	ufshcd_init_pm_qos_sysfs(hba);
 	return 0;
 
 free_tmf_queue:
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index d862c8ddce03..fa7434a9073d 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -912,6 +912,9 @@ enum ufshcd_mcq_opr {
  * @mcq_base: Multi circular queue registers base address
  * @uhq: array of supported hardware queues
  * @dev_cmd_queue: Queue for issuing device management commands
+ * @pm_qos_enable_attr: sysfs attribute to enable/disable  pm qos
+ * @pm_qos_req: PM QoS request handle
+ * @pm_qos_enabled: flag to check if pm qos is enabled
  */
 struct ufs_hba {
 	void __iomem *mmio_base;
@@ -1076,6 +1079,9 @@ struct ufs_hba {
 	struct ufs_hw_queue *uhq;
 	struct ufs_hw_queue *dev_cmd_queue;
 	struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
+	struct device_attribute pm_qos_enable_attr;
+	struct pm_qos_request pm_qos_req;
+	bool pm_qos_enabled;
 };
 
 /**
-- 
2.17.1



From rafael at kernel.org  Tue Dec 12 03:55:51 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Tue, 12 Dec 2023 12:55:51 +0100
Subject: [PATCH v7 0/7] consolidate and cleanup CPU capacity
In-Reply-To: <CAKfTPtDXLDpGChy7UXVsV75NHK1OPGHaGYf5G663HWnau4kAHg@mail.gmail.com>
References: <20231211104855.558096-1-vincent.guittot@linaro.org>
 <CAJZ5v0i37gGqt=oGC4BxJ4hT5pxhAdL7dPxGf7w3D8THqwAOwQ@mail.gmail.com> <CAKfTPtDXLDpGChy7UXVsV75NHK1OPGHaGYf5G663HWnau4kAHg@mail.gmail.com>
Message-ID: <CAJZ5v0ir=2qcQyCg5CPUG=A_09Tdw-rYOX_NQr7eib_yk5t=nA@mail.gmail.com>

On Tue, Dec 12, 2023 at 9:32?AM Vincent Guittot
<vincent.guittot at linaro.org> wrote:
>
> On Mon, 11 Dec 2023 at 20:52, Rafael J. Wysocki <rafael at kernel.org> wrote:
> >
> > On Mon, Dec 11, 2023 at 11:49?AM Vincent Guittot
> > <vincent.guittot at linaro.org> wrote:
>
> [..]
>
> > >
> > > Vincent Guittot (7):
> > >   topology: Add a new arch_scale_freq_reference
> > >   cpufreq: Use the fixed and coherent frequency for scaling capacity
> > >   cpufreq/schedutil: Use a fixed reference frequency
> > >   energy_model: Use a fixed reference frequency
> > >   cpufreq/cppc: Move and rename cppc_cpufreq_{perf_to_khz|khz_to_perf}
> > >   cpufreq/cppc: Set the frequency used for computing the capacity
> > >   arm64/amu: Use capacity_ref_freq to set AMU ratio
> >
> > This series touches multiple places, but mostly schedutil, cpufreq and
> > the EM, so please let me know if you want me to pick it up.
>
> This serie has been rebased on top of tip/ched/core to fix a conflict
> with another change already queued in kernel/sched/cpufreq_schedutil.c

OK, so I'm assuming that it will go in through tip.

Thanks!


From ryan.roberts at arm.com  Tue Dec 12 03:57:44 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 12 Dec 2023 11:57:44 +0000
Subject: [PATCH v3 02/15] mm: Batch-clear PTE ranges during
 zap_pte_range()
In-Reply-To: <87h6kta3ap.fsf@nvdebian.thelocal>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-3-ryan.roberts@arm.com>
 <87h6kta3ap.fsf@nvdebian.thelocal>
Message-ID: <97489e94-ea4e-40a3-9e56-d5f7d1219e81@arm.com>

On 08/12/2023 01:30, Alistair Popple wrote:
> 
> Ryan Roberts <ryan.roberts at arm.com> writes:
> 
>> Convert zap_pte_range() to clear a set of ptes in a batch. A given batch
>> maps a physically contiguous block of memory, all belonging to the same
>> folio. This will likely improve performance by a tiny amount due to
>> removing duplicate calls to mark the folio dirty and accessed. And also
>> provides us with a future opportunity to batch the rmap removal.
>>
>> However, the primary motivation for this change is to reduce the number
>> of tlb maintenance operations that the arm64 backend has to perform
>> during exit and other syscalls that cause zap_pte_range() (e.g. munmap,
>> madvise(DONTNEED), etc.), as it is about to add transparent support for
>> the "contiguous bit" in its ptes. By clearing ptes using the new
>> clear_ptes() API, the backend doesn't have to perform an expensive
>> unfold operation when a PTE being cleared is part of a contpte block.
>> Instead it can just clear the whole block immediately.
>>
>> This change addresses the core-mm refactoring only, and introduces
>> clear_ptes() with a default implementation that calls
>> ptep_get_and_clear_full() for each pte in the range. Note that this API
>> returns the pte at the beginning of the batch, but with the dirty and
>> young bits set if ANY of the ptes in the cleared batch had those bits
>> set; this information is applied to the folio by the core-mm. Given the
>> batch is garranteed to cover only a single folio, collapsing this state
> 
> Nit: s/garranteed/guaranteed/
> 
>> does not lose any useful information.
>>
>> A separate change will implement clear_ptes() in the arm64 backend to
>> realize the performance improvement as part of the work to enable
>> contpte mappings.
>>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
>>  include/asm-generic/tlb.h |  9 ++++++
>>  include/linux/pgtable.h   | 26 ++++++++++++++++
>>  mm/memory.c               | 63 ++++++++++++++++++++++++++-------------
>>  mm/mmu_gather.c           | 14 +++++++++
>>  4 files changed, 92 insertions(+), 20 deletions(-)
> 
> <snip>
> 
>> diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
>> index 4f559f4ddd21..57b4d5f0dfa4 100644
>> --- a/mm/mmu_gather.c
>> +++ b/mm/mmu_gather.c
>> @@ -47,6 +47,20 @@ static bool tlb_next_batch(struct mmu_gather *tlb)
>>  	return true;
>>  }
>>  
>> +unsigned int tlb_get_guaranteed_space(struct mmu_gather *tlb)
>> +{
>> +	struct mmu_gather_batch *batch = tlb->active;
>> +	unsigned int nr_next = 0;
>> +
>> +	/* Allocate next batch so we can guarrantee at least one batch. */
>> +	if (tlb_next_batch(tlb)) {
>> +		tlb->active = batch;
> 
> Rather than calling tlb_next_batch(tlb) and then undoing some of what it
> does I think it would be clearer to factor out the allocation part of
> tlb_next_batch(tlb) into a separate function (eg. tlb_alloc_batch) that
> you can call from both here and tlb_next_batch().

As per my email against patch 1, I have some perf regressions to iron out for
microbenchmarks; one issue is that this code forces the allocation of a page for
a batch even when we are only modifying a single pte (which would previously fit
in the embedded batch). So I've renamed this function to tlb_reserve_space(int
nr). If it already has enough room, it will jsut return immediately. Else it
will keep calling tlb_next_batch() in a loop until space has been allocated.
Then after the loop we set tlb->active back to the original batch.

Given the new potential need to loop a couple of times, and the need to build up
that linked list, I think it works nicely without refactoring tlb_next_batch().

> 
> Otherwise I think this overall direction looks better than trying to
> play funny games in the arch layer as it's much clearer what's going on
> to core-mm code.
> 
>  - Alistair
> 
>> +		nr_next = batch->next->max;
>> +	}
>> +
>> +	return batch->max - batch->nr + nr_next;
>> +}
>> +
>>  #ifdef CONFIG_SMP
>>  static void tlb_flush_rmap_batch(struct mmu_gather_batch *batch, struct vm_area_struct *vma)
>>  {
> 



From rafael at kernel.org  Tue Dec 12 03:59:15 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Tue, 12 Dec 2023 12:59:15 +0100
Subject: [PATCH] PM: domains: Drop the unused pm_genpd_opp_to_performance_state()
In-Reply-To: <CAPDyKFpJ6_+nF8q3L4Tg1E9St3stgJ06se0t=FLHkx4_36OJNA@mail.gmail.com>
References: <20231127151931.47055-1-ulf.hansson@linaro.org>
 <CAJZ5v0jXRNDV7AhZPkrDvMtrk6cYeMJ+HuUs0kJ=kjbQ-YiyVA@mail.gmail.com> <CAPDyKFpJ6_+nF8q3L4Tg1E9St3stgJ06se0t=FLHkx4_36OJNA@mail.gmail.com>
Message-ID: <CAJZ5v0jxMjb-bUbJiHgehe5xJ6cwspvsRp5P_2N6FyvRFshJQA@mail.gmail.com>

On Tue, Dec 12, 2023 at 11:37?AM Ulf Hansson <ulf.hansson at linaro.org> wrote:
>
> On Mon, 11 Dec 2023 at 21:44, Rafael J. Wysocki <rafael at kernel.org> wrote:
> >
> > On Mon, Nov 27, 2023 at 4:19?PM Ulf Hansson <ulf.hansson at linaro.org> wrote:
> > >
> > > Since commit 7c41cdcd3bbe ("OPP: Simplify the over-designed pstate <->
> > > level dance"), there is no longer any users of the
> > > pm_genpd_opp_to_performance_state() API. Let's therefore drop it and its
> > > corresponding ->opp_to_performance_state() callback, which also no longer
> > > has any users.
> > >
> > > Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> >
> > I can take this in principle, but I'm wondering if you'd prefer to
> > apply patches modifying domain.c yourself?  They are definitely
> > related to the pmdomain tree.
>
> Yes, it makes sense for me to pick the genpd core patches through the
> pmdomain tree. In some cases there may be overlapping patches that are
> more generic and not only limited to genpd, but I guess we can decide
> on a case by case basis for those ones.
>
> I can add the pmdomain tree to the GENERIC PM DOMAINS section in the
> MAINTAINERS file to reflect this, if you think this is a good idea?

Yes, please.

What about moving drivers/base/power/domain.c to drivers/pmdomain/ ?


From ryan.roberts at arm.com  Tue Dec 12 03:59:43 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 12 Dec 2023 11:59:43 +0000
Subject: [PATCH v3 14/15] arm64/mm: Implement ptep_set_wrprotects() to
 optimize fork()
In-Reply-To: <87cyvha2xd.fsf@nvdebian.thelocal>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-15-ryan.roberts@arm.com>
 <87cyvha2xd.fsf@nvdebian.thelocal>
Message-ID: <ecf129dd-000f-45be-95dc-1e8dad5a8c12@arm.com>

On 08/12/2023 01:37, Alistair Popple wrote:
> 
> Ryan Roberts <ryan.roberts at arm.com> writes:
> 
>> With the core-mm changes in place to batch-copy ptes during fork, we can
>> take advantage of this in arm64 to greatly reduce the number of tlbis we
>> have to issue, and recover the lost fork performance incured when adding
>> support for transparent contiguous ptes.
>>
>> If we are write-protecting a whole contig range, we can apply the
>> write-protection to the whole range and know that it won't change
>> whether the range should have the contiguous bit set or not. For ranges
>> smaller than the contig range, we will still have to unfold, apply the
>> write-protection, then fold if the change now means the range is
>> foldable.
>>
>> This optimization is possible thanks to the tightening of the Arm ARM in
>> respect to the definition and behaviour when 'Misprogramming the
>> Contiguous bit'. See section D21194 at
>> https://developer.arm.com/documentation/102105/latest/
>>
>> Performance tested with the following test written for the will-it-scale
>> framework:
>>
>> -------
>>
>> char *testcase_description = "fork and exit";
>>
>> void testcase(unsigned long long *iterations, unsigned long nr)
>> {
>> 	int pid;
>> 	char *mem;
>>
>> 	mem = malloc(SZ_128M);
>> 	assert(mem);
>> 	memset(mem, 1, SZ_128M);
>>
>> 	while (1) {
>> 		pid = fork();
>> 		assert(pid >= 0);
>>
>> 		if (!pid)
>> 			exit(0);
>>
>> 		waitpid(pid, NULL, 0);
>>
>> 		(*iterations)++;
>> 	}
>> }
>>
>> -------
>>
>> I see huge performance regression when PTE_CONT support was added, then
>> the regression is mostly fixed with the addition of this change. The
>> following shows regression relative to before PTE_CONT was enabled
>> (bigger negative value is bigger regression):
>>
>> |   cpus |   before opt |   after opt |
>> |-------:|-------------:|------------:|
>> |      1 |       -10.4% |       -5.2% |
>> |      8 |       -15.4% |       -3.5% |
>> |     16 |       -38.7% |       -3.7% |
>> |     24 |       -57.0% |       -4.4% |
>> |     32 |       -65.8% |       -5.4% |
>>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
>>  arch/arm64/include/asm/pgtable.h | 30 ++++++++++++++++++++---
>>  arch/arm64/mm/contpte.c          | 42 ++++++++++++++++++++++++++++++++
>>  2 files changed, 69 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 15bc9cf1eef4..9bd2f57a9e11 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -984,6 +984,16 @@ static inline void __ptep_set_wrprotect(struct mm_struct *mm,
>>  	} while (pte_val(pte) != pte_val(old_pte));
>>  }
>>  
>> +static inline void __ptep_set_wrprotects(struct mm_struct *mm,
>> +					unsigned long address, pte_t *ptep,
>> +					unsigned int nr)
>> +{
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
>> +		__ptep_set_wrprotect(mm, address, ptep);
>> +}
>> +
>>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>  #define __HAVE_ARCH_PMDP_SET_WRPROTECT
>>  static inline void pmdp_set_wrprotect(struct mm_struct *mm,
>> @@ -1139,6 +1149,8 @@ extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>  				unsigned long addr, pte_t *ptep);
>>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>>  				unsigned long addr, pte_t *ptep);
>> +extern void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
>> +				pte_t *ptep, unsigned int nr);
>>  extern int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
>>  				unsigned long addr, pte_t *ptep,
>>  				pte_t entry, int dirty);
>> @@ -1290,13 +1302,25 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
>>  	return contpte_ptep_clear_flush_young(vma, addr, ptep);
>>  }
>>  
>> +#define ptep_set_wrprotects ptep_set_wrprotects
>> +static inline void ptep_set_wrprotects(struct mm_struct *mm, unsigned long addr,
>> +				pte_t *ptep, unsigned int nr)
>> +{
>> +	if (!contpte_is_enabled(mm))
>> +		__ptep_set_wrprotects(mm, addr, ptep, nr);
>> +	else if (nr == 1) {
> 
> Why do we need the special case here? Couldn't we just call
> contpte_set_wrprotects() with nr == 1?

My intention is for this to be a fast path for ptep_set_wrprotect(). I'm having
to work hard to prevent regressing the order-0 folios case.

> 
>> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>> +		__ptep_set_wrprotects(mm, addr, ptep, 1);
>> +		contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
>> +	} else
>> +		contpte_set_wrprotects(mm, addr, ptep, nr);
>> +}
>> +
>>  #define __HAVE_ARCH_PTEP_SET_WRPROTECT
>>  static inline void ptep_set_wrprotect(struct mm_struct *mm,
>>  				unsigned long addr, pte_t *ptep)
>>  {
>> -	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>> -	__ptep_set_wrprotect(mm, addr, ptep);
>> -	contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
>> +	ptep_set_wrprotects(mm, addr, ptep, 1);
>>  }
>>  
>>  #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
>> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
>> index e079ec61d7d1..2a57df16bf58 100644
>> --- a/arch/arm64/mm/contpte.c
>> +++ b/arch/arm64/mm/contpte.c
>> @@ -303,6 +303,48 @@ int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>>  }
>>  EXPORT_SYMBOL(contpte_ptep_clear_flush_young);
>>  
>> +void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
>> +					pte_t *ptep, unsigned int nr)
>> +{
>> +	unsigned long next;
>> +	unsigned long end = addr + (nr << PAGE_SHIFT);
>> +
>> +	do {
>> +		next = pte_cont_addr_end(addr, end);
>> +		nr = (next - addr) >> PAGE_SHIFT;
>> +
>> +		/*
>> +		 * If wrprotecting an entire contig range, we can avoid
>> +		 * unfolding. Just set wrprotect and wait for the later
>> +		 * mmu_gather flush to invalidate the tlb. Until the flush, the
>> +		 * page may or may not be wrprotected. After the flush, it is
>> +		 * guarranteed wrprotected. If its a partial range though, we
>> +		 * must unfold, because we can't have a case where CONT_PTE is
>> +		 * set but wrprotect applies to a subset of the PTEs; this would
>> +		 * cause it to continue to be unpredictable after the flush.
>> +		 */
>> +		if (nr != CONT_PTES)
>> +			contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>> +
>> +		__ptep_set_wrprotects(mm, addr, ptep, nr);
>> +
>> +		addr = next;
>> +		ptep += nr;
>> +
>> +		/*
>> +		 * If applying to a partial contig range, the change could have
>> +		 * made the range foldable. Use the last pte in the range we
>> +		 * just set for comparison, since contpte_try_fold() only
>> +		 * triggers when acting on the last pte in the contig range.
>> +		 */
>> +		if (nr != CONT_PTES)
>> +			contpte_try_fold(mm, addr - PAGE_SIZE, ptep - 1,
>> +					 __ptep_get(ptep - 1));
>> +
>> +	} while (addr != end);
>> +}
>> +EXPORT_SYMBOL(contpte_set_wrprotects);
>> +
>>  int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
>>  					unsigned long addr, pte_t *ptep,
>>  					pte_t entry, int dirty)
> 



From ryan.roberts at arm.com  Tue Dec 12 04:02:19 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 12 Dec 2023 12:02:19 +0000
Subject: [PATCH v3 15/15] arm64/mm: Implement clear_ptes() to optimize
 exit()
In-Reply-To: <878r65a2m2.fsf@nvdebian.thelocal>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-16-ryan.roberts@arm.com>
 <878r65a2m2.fsf@nvdebian.thelocal>
Message-ID: <58152ed9-5c8d-484f-8e11-23ee5879bc1e@arm.com>

On 08/12/2023 01:45, Alistair Popple wrote:
> 
> Ryan Roberts <ryan.roberts at arm.com> writes:
> 
>> With the core-mm changes in place to batch-clear ptes during
>> zap_pte_range(), we can take advantage of this in arm64 to greatly
>> reduce the number of tlbis we have to issue, and recover the lost exit
>> performance incured when adding support for transparent contiguous ptes.
>>
>> If we are clearing a whole contpte range, we can elide first unfolding
>> that range and save the tlbis. We just clear the whole range.
>>
>> The following shows the results of running a kernel compilation workload
>> and measuring the cost of arm64_sys_exit_group() (which at ~1.5% is a
>> very small part of the overall workload).
>>
>> Benchmarks were run on Ampere Altra in 2 configs; single numa node and 2
>> numa nodes (tlbis are more expensive in 2 node config).
>>
>>  - baseline: v6.7-rc1 + anonfolio-v7
>>  - no-opt: contpte series without any attempt to optimize exit()
>>  - simple-ptep_get_clear_full: simple optimization to exploit full=1.
>>    ptep_get_clear_full() does not fully conform to its intended semantic
>>  - robust-ptep_get_clear_full: similar to previous but
>>    ptep_get_clear_full() fully conforms to its intended semantic
>>  - clear_ptes: optimization implemented by this patch
>>
>> | config                     | numa=1 | numa=2 |
>> |----------------------------|--------|--------|
>> | baseline                   |     0% |     0% |
>> | no-opt                     |   190% |   768% |
>> | simple-ptep_get_clear_full |     8% |    29% |
>> | robust-ptep_get_clear_full |    21% |    19% |
>> | clear_ptes                 |    13% |     9% |
>>
>> In all cases, the cost of arm64_sys_exit_group() increases; this is
>> anticipated because there is more work to do to tear down the page
>> tables. But clear_ptes() gives the smallest increase overall.
>>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
>>  arch/arm64/include/asm/pgtable.h | 32 ++++++++++++++++++++++++
>>  arch/arm64/mm/contpte.c          | 42 ++++++++++++++++++++++++++++++++
>>  2 files changed, 74 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 9bd2f57a9e11..ff6b3cc9e819 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -1145,6 +1145,8 @@ extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
>>  extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
>>  extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>>  				pte_t *ptep, pte_t pte, unsigned int nr);
>> +extern pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr,
>> +				pte_t *ptep, unsigned int nr);
>>  extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>  				unsigned long addr, pte_t *ptep);
>>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>> @@ -1270,6 +1272,36 @@ static inline void pte_clear(struct mm_struct *mm,
>>  	__pte_clear(mm, addr, ptep);
>>  }
>>  
>> +#define clear_ptes clear_ptes
>> +static inline pte_t clear_ptes(struct mm_struct *mm,
>> +				unsigned long addr, pte_t *ptep, int full,
>> +				unsigned int nr)
>> +{
>> +	pte_t pte;
>> +
>> +	if (!contpte_is_enabled(mm)) {
> 
> I think it would be better to call the generic definition of
> clear_ptes() here. Obviously that won't exist if clear_ptes is defined
> here, but you could alcall it __clear_ptes() and #define clear_ptes
> __clear_ptes when the arch specific helper isn't defined.

My thinking was that we wouldn't bother to expose clear_ptes() when
CONFIG_ARM64_CONTPTE is disabled, and just fall back to the core-mm generic one.
But I think your proposal is probably cleaner and more consistent with
everything else. So I'll do this for the next version.


> 
>> +		unsigned int i;
>> +		pte_t tail;
>> +
>> +		pte = __ptep_get_and_clear(mm, addr, ptep);
>> +		for (i = 1; i < nr; i++) {
>> +			addr += PAGE_SIZE;
>> +			ptep++;
>> +			tail = __ptep_get_and_clear(mm, addr, ptep);
>> +			if (pte_dirty(tail))
>> +				pte = pte_mkdirty(pte);
>> +			if (pte_young(tail))
>> +				pte = pte_mkyoung(pte);
>> +		}
>> +	} else if (nr == 1) {
>> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>> +		pte = __ptep_get_and_clear(mm, addr, ptep);
>> +	} else
>> +		pte = contpte_clear_ptes(mm, addr, ptep, nr);
>> +
>> +	return pte;
>> +}
>> +
>>  #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
>>  static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
>>  				unsigned long addr, pte_t *ptep)
>> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
>> index 2a57df16bf58..34b43bde3fcd 100644
>> --- a/arch/arm64/mm/contpte.c
>> +++ b/arch/arm64/mm/contpte.c
>> @@ -257,6 +257,48 @@ void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>>  }
>>  EXPORT_SYMBOL(contpte_set_ptes);
>>  
>> +pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
>> +					unsigned int nr)
>> +{
>> +	/*
>> +	 * If we cover a partial contpte block at the beginning or end of the
>> +	 * batch, unfold if currently folded. This makes it safe to clear some
>> +	 * of the entries while keeping others. contpte blocks in the middle of
>> +	 * the range, which are fully covered don't need to be unfolded because
>> +	 * we will clear the full block.
>> +	 */
>> +
>> +	unsigned int i;
>> +	pte_t pte;
>> +	pte_t tail;
>> +
>> +	if (ptep != contpte_align_down(ptep) || nr < CONT_PTES)
>> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>> +
>> +	if (ptep + nr != contpte_align_down(ptep + nr))
>> +		contpte_try_unfold(mm, addr + PAGE_SIZE * (nr - 1),
>> +				   ptep + nr - 1,
>> +				   __ptep_get(ptep + nr - 1));
>> +
>> +	pte = __ptep_get_and_clear(mm, addr, ptep);
>> +
>> +	for (i = 1; i < nr; i++) {
>> +		addr += PAGE_SIZE;
>> +		ptep++;
>> +
>> +		tail = __ptep_get_and_clear(mm, addr, ptep);
>> +
>> +		if (pte_dirty(tail))
>> +			pte = pte_mkdirty(pte);
>> +
>> +		if (pte_young(tail))
>> +			pte = pte_mkyoung(pte);
>> +	}
>> +
>> +	return pte;
>> +}
>> +EXPORT_SYMBOL(contpte_clear_ptes);
>> +
>>  int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>  					unsigned long addr, pte_t *ptep)
>>  {
> 



From szabolcs.nagy at arm.com  Tue Dec 12 04:03:32 2023
From: szabolcs.nagy at arm.com (Szabolcs Nagy)
Date: Tue, 12 Dec 2023 12:03:32 +0000
Subject: [PATCH v3 15/25] arm64: add POE signal support
In-Reply-To: <ZXdamak1wDyUdwSG@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-16-joey.gouly@arm.com>
 <ZXdamak1wDyUdwSG@arm.com>
Message-ID: <ZXhMFBK3khQHo2lX@arm.com>

The 12/11/2023 18:53, Catalin Marinas wrote:
> + Szabolcs for libc ack (and keeping the full patch quoted below)
> 
> You should cc Szabolcs when reposting, we need his ack on the UAPI
> changes.
> 
> On Fri, Nov 24, 2023 at 04:35:00PM +0000, Joey Gouly wrote:
> > Add PKEY support to signals, by saving and restoring POR_EL0 from the stackframe.

this looks good.

Acked-by: Szabolcs Nagy <szabolcs.nagy at arm.com>

> > 
> > Signed-off-by: Joey Gouly <joey.gouly at arm.com>
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> > Reviewed-by: Mark Brown <broonie at kernel.org>
> > ---
> >  arch/arm64/include/uapi/asm/sigcontext.h |  7 ++++
> >  arch/arm64/kernel/signal.c               | 51 ++++++++++++++++++++++++
> >  2 files changed, 58 insertions(+)
> > 
> > diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
> > index f23c1dc3f002..cef85eeaf541 100644
> > --- a/arch/arm64/include/uapi/asm/sigcontext.h
> > +++ b/arch/arm64/include/uapi/asm/sigcontext.h
> > @@ -98,6 +98,13 @@ struct esr_context {
> >  	__u64 esr;
> >  };
> >  
> > +#define POE_MAGIC	0x504f4530
> > +
> > +struct poe_context {
> > +	struct _aarch64_ctx head;
> > +	__u64 por_el0;
> > +};
> > +
> >  /*
> >   * extra_context: describes extra space in the signal frame for
> >   * additional structures that don't fit in sigcontext.__reserved[].
> > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> > index 0e8beb3349ea..379f364005bf 100644
> > --- a/arch/arm64/kernel/signal.c
> > +++ b/arch/arm64/kernel/signal.c
> > @@ -62,6 +62,7 @@ struct rt_sigframe_user_layout {
> >  	unsigned long zt_offset;
> >  	unsigned long extra_offset;
> >  	unsigned long end_offset;
> > +	unsigned long poe_offset;
> >  };
> >  
> >  #define BASE_SIGFRAME_SIZE round_up(sizeof(struct rt_sigframe), 16)
> > @@ -182,6 +183,8 @@ struct user_ctxs {
> >  	u32 za_size;
> >  	struct zt_context __user *zt;
> >  	u32 zt_size;
> > +	struct poe_context __user *poe;
> > +	u32 poe_size;
> >  };
> >  
> >  static int preserve_fpsimd_context(struct fpsimd_context __user *ctx)
> > @@ -227,6 +230,20 @@ static int restore_fpsimd_context(struct user_ctxs *user)
> >  	return err ? -EFAULT : 0;
> >  }
> >  
> > +static int restore_poe_context(struct user_ctxs *user)
> > +{
> > +	u64 por_el0;
> > +	int err = 0;
> > +
> > +	if (user->poe_size != sizeof(*user->poe))
> > +		return -EINVAL;
> > +
> > +	__get_user_error(por_el0, &(user->poe->por_el0), err);
> > +	if (!err)
> > +		write_sysreg_s(por_el0, SYS_POR_EL0);
> > +
> > +	return err;
> > +}
> >  
> >  #ifdef CONFIG_ARM64_SVE
> >  
> > @@ -590,6 +607,7 @@ static int parse_user_sigframe(struct user_ctxs *user,
> >  	user->tpidr2 = NULL;
> >  	user->za = NULL;
> >  	user->zt = NULL;
> > +	user->poe = NULL;
> >  
> >  	if (!IS_ALIGNED((unsigned long)base, 16))
> >  		goto invalid;
> > @@ -640,6 +658,17 @@ static int parse_user_sigframe(struct user_ctxs *user,
> >  			/* ignore */
> >  			break;
> >  
> > +		case POE_MAGIC:
> > +			if (!system_supports_poe())
> > +				goto invalid;
> > +
> > +			if (user->poe)
> > +				goto invalid;
> > +
> > +			user->poe = (struct poe_context __user *)head;
> > +			user->poe_size = size;
> > +			break;
> > +
> >  		case SVE_MAGIC:
> >  			if (!system_supports_sve() && !system_supports_sme())
> >  				goto invalid;
> > @@ -812,6 +841,9 @@ static int restore_sigframe(struct pt_regs *regs,
> >  	if (err == 0 && system_supports_sme2() && user.zt)
> >  		err = restore_zt_context(&user);
> >  
> > +	if (err == 0 && system_supports_poe() && user.poe)
> > +		err = restore_poe_context(&user);
> > +
> >  	return err;
> >  }
> >  
> > @@ -928,6 +960,13 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
> >  		}
> >  	}
> >  
> > +	if (system_supports_poe()) {
> > +		err = sigframe_alloc(user, &user->poe_offset,
> > +				     sizeof(struct poe_context));
> > +		if (err)
> > +			return err;
> > +	}
> > +
> >  	return sigframe_alloc_end(user);
> >  }
> >  
> > @@ -968,6 +1007,15 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
> >  		__put_user_error(current->thread.fault_code, &esr_ctx->esr, err);
> >  	}
> >  
> > +	if (system_supports_poe() && err == 0 && user->poe_offset) {
> > +		struct poe_context __user *poe_ctx =
> > +			apply_user_offset(user, user->poe_offset);
> > +
> > +		__put_user_error(POE_MAGIC, &poe_ctx->head.magic, err);
> > +		__put_user_error(sizeof(*poe_ctx), &poe_ctx->head.size, err);
> > +		__put_user_error(read_sysreg_s(SYS_POR_EL0), &poe_ctx->por_el0, err);
> > +	}
> > +
> >  	/* Scalable Vector Extension state (including streaming), if present */
> >  	if ((system_supports_sve() || system_supports_sme()) &&
> >  	    err == 0 && user->sve_offset) {
> > @@ -1119,6 +1167,9 @@ static void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
> >  		sme_smstop();
> >  	}
> >  
> > +	if (system_supports_poe())
> > +		write_sysreg_s(POR_EL0_INIT, SYS_POR_EL0);
> > +
> >  	if (ka->sa.sa_flags & SA_RESTORER)
> >  		sigtramp = ka->sa.sa_restorer;
> >  	else
> > -- 
> > 2.25.1


From suzuki.poulose at arm.com  Tue Dec 12 04:13:16 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 12 Dec 2023 12:13:16 +0000
Subject: [GIT PULL] coresight: Updates for linux v6.8
Message-ID: <20231212121316.2804146-1-suzuki.poulose@arm.com>

Hi Greg

Please find the updates for coresight and hwtracing subsystems targeting
Linux v6.8. Please note that the branch is based on the stable tag,
"coresight-fixes-for-v6.7-rc1" (which was merged in v6.7-rc5, on v6.7-rc1).

 i.e, coresight-next-v6.8....coresight-fixes-for-v6.7-rc1...v6.7-rc1


Kindly pull

Suzuki

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.8

for you to fetch changes up to 60e5f23dc5d68ec01e6dae8f4311230c7d2ccb8a:

  coresight: ultrasoc-smb: Use guards to cleanup (2023-11-21 11:21:59 +0000)

----------------------------------------------------------------
coresight: Updates for Linux v6.8

Updates for the hwtracing subsystem includes :
 - Support for CoreSight TPDM DSB set
 - Support for tuning Cycle count Threshold for CoreSight ETM via perf
 - Support for TRBE on ACPI based systems
 - Support for choosing buffer mode in ETR for sysfs mode
 - Improvements to HiSilicon PTT driver
 - Cleanups to Ultrasoc SMB driver
 - Cleanup .remove callback for various Coresight platform drivers
 - Remove Leo Yan from Reviewers

Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>

----------------------------------------------------------------
Anshuman Khandual (6):
      coresight: trbe: Add a representative coresight_platform_data for TRBE
      coresight: trbe: Enable ACPI based TRBE devices
      coresight: etm: Override TRCIDR3.CCITMIN on errata affected cpus
      coresight: etm: Make cycle count threshold user configurable
      Documentation: coresight: Add cc_threshold tunable
      coresight: tmc: Make etr buffer mode user configurable from sysfs

Bagas Sanjaya (1):
      Documentation: ABI: coresight-tpdm: Fix Bit[3] description indentation

James Clark (2):
      coresight: Fix crash when Perf and sysfs modes are used concurrently
      coresight: etm4x: Fix width of CCITMIN field

Junhao He (5):
      hwtracing: hisi_ptt: Add dummy callback pmu::read()
      coresight: ultrasoc-smb: Fix sleep while close preempt in enable_smb
      coresight: ultrasoc-smb: Config SMB buffer before register sink
      coresight: ultrasoc-smb: Fix uninitialized before use buf_hw_base
      coresight: ultrasoc-smb: Use guards to cleanup

Leo Yan (1):
      MAINTAINERS: Remove myself as a Arm CoreSight reviewer

Tao Zhang (14):
      coresight-tpdm: Remove the unnecessary lock
      dt-bindings: arm: Add support for DSB element size
      coresight-tpdm: Introduce TPDM subtype to TPDM driver
      coresight-tpda: Add DSB dataset support
      coresight-tpdm: Initialize DSB subunit configuration
      coresight-tpdm: Add reset node to TPDM node
      coresight-tpdm: Add nodes to set trigger timestamp and type
      coresight-tpdm: Add node to set dsb programming mode
      coresight-tpdm: Add nodes for dsb edge control
      coresight-tpdm: Add nodes to configure pattern match output
      coresight-tpdm: Add nodes for timestamp request
      dt-bindings: arm: Add support for DSB MSR register
      coresight-tpdm: Add nodes for dsb msr support
      coresight-tpdm: Correct the property name of MSR number

Uwe Kleine-K?nig (7):
      coresight: etm4x: Remove bogous __exit annotation for some functions
      coresight: dummy: Convert to platform remove callback returning void
      coresight: etm4x: Convert to platform remove callback returning void
      coresight: funnel: Convert to platform remove callback returning void
      coresight: replicator: Convert to platform remove callback returning void
      coresight: trbe: Convert to platform remove callback returning void
      coresight: ultrasoc-smb: Convert to platform remove callback returning void

Vegard Nossum (1):
      Documentation: coresight: fix `make refcheckdocs` warning

Yicong Yang (4):
      hwtracing: hisi_ptt: Handle the interrupt in hardirq context
      hwtracing: hisi_ptt: Don't try to attach a task
      hwtracing: hisi_ptt: Disable interrupt after trace end
      hwtracing: hisi_ptt: Optimize the trace data committing

 .../ABI/testing/sysfs-bus-coresight-devices-tmc    |  16 +
 .../ABI/testing/sysfs-bus-coresight-devices-tpdm   | 159 +++++
 Documentation/arch/arm64/silicon-errata.rst        |  10 +
 .../bindings/arm/qcom,coresight-tpdm.yaml          |  20 +
 Documentation/trace/coresight/coresight.rst        |   6 +-
 MAINTAINERS                                        |   1 -
 drivers/hwtracing/coresight/coresight-core.c       |   3 +
 drivers/hwtracing/coresight/coresight-dummy.c      |   5 +-
 drivers/hwtracing/coresight/coresight-etm-perf.c   |   6 +-
 drivers/hwtracing/coresight/coresight-etm4x-core.c |  56 +-
 drivers/hwtracing/coresight/coresight-etm4x.h      |   2 +-
 drivers/hwtracing/coresight/coresight-funnel.c     |   5 +-
 drivers/hwtracing/coresight/coresight-replicator.c |   5 +-
 drivers/hwtracing/coresight/coresight-tmc-core.c   |  15 +-
 drivers/hwtracing/coresight/coresight-tmc-etr.c    | 111 +++-
 drivers/hwtracing/coresight/coresight-tmc.h        |   3 +
 drivers/hwtracing/coresight/coresight-tpda.c       | 126 +++-
 drivers/hwtracing/coresight/coresight-tpda.h       |   2 +
 drivers/hwtracing/coresight/coresight-tpdm.c       | 718 ++++++++++++++++++++-
 drivers/hwtracing/coresight/coresight-tpdm.h       | 161 +++++
 drivers/hwtracing/coresight/coresight-trbe.c       |  28 +-
 drivers/hwtracing/coresight/coresight-trbe.h       |   2 +
 drivers/hwtracing/coresight/ultrasoc-smb.c         | 118 ++--
 drivers/hwtracing/coresight/ultrasoc-smb.h         |   6 +-
 drivers/hwtracing/ptt/hisi_ptt.c                   |  33 +-
 drivers/hwtracing/ptt/hisi_ptt.h                   |   1 +
 include/linux/coresight.h                          |   1 +
 27 files changed, 1463 insertions(+), 156 deletions(-)


From will at kernel.org  Tue Dec 12 04:17:42 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 12:17:42 +0000
Subject: [PATCH v3 1/2] kvm: arm64: introduce new flag for non-cacheable
 IO memory
In-Reply-To: <20231208164709.23101-2-ankita@nvidia.com>
References: <20231208164709.23101-1-ankita@nvidia.com>
 <20231208164709.23101-2-ankita@nvidia.com>
Message-ID: <20231212121742.GA29205@willie-the-truck>

On Fri, Dec 08, 2023 at 10:17:08PM +0530, ankita at nvidia.com wrote:
> From: Ankit Agrawal <ankita at nvidia.com>
> 
> For various reasons described in the cover letter, and primarily to
> allow VM get IO memory with NORMALNC properties, it is desired
> to relax the KVM stage 2 device memory attributes from DEVICE_nGnRE
> to NormalNC. So set S2 PTE for IO memory as NORMAL_NC.
> 
> A Normal-NC flag is not present today. So add a new kvm_pgtable_prot
> (KVM_PGTABLE_PROT_NORMAL_NC) flag for it, along with its
> corresponding PTE value 0x5 (0b101) determined from [1].
> 
> Lastly, adapt the stage2 PTE property setter function
> (stage2_set_prot_attr) to handle the NormalNC attribute.
> 
> [1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf
> 
> Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
> Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> Tested-by: Ankit Agrawal <ankita at nvidia.com>
> ---
>  arch/arm64/include/asm/kvm_pgtable.h |  2 ++
>  arch/arm64/include/asm/memory.h      |  2 ++
>  arch/arm64/kvm/hyp/pgtable.c         | 11 +++++++++--
>  3 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index cfdf40f734b1..19278dfe7978 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -197,6 +197,7 @@ enum kvm_pgtable_stage2_flags {
>   * @KVM_PGTABLE_PROT_W:		Write permission.
>   * @KVM_PGTABLE_PROT_R:		Read permission.
>   * @KVM_PGTABLE_PROT_DEVICE:	Device attributes.
> + * @KVM_PGTABLE_PROT_NORMAL_NC:	Normal noncacheable attributes.
>   * @KVM_PGTABLE_PROT_SW0:	Software bit 0.
>   * @KVM_PGTABLE_PROT_SW1:	Software bit 1.
>   * @KVM_PGTABLE_PROT_SW2:	Software bit 2.
> @@ -208,6 +209,7 @@ enum kvm_pgtable_prot {
>  	KVM_PGTABLE_PROT_R			= BIT(2),
>  
>  	KVM_PGTABLE_PROT_DEVICE			= BIT(3),
> +	KVM_PGTABLE_PROT_NORMAL_NC		= BIT(4),
>  
>  	KVM_PGTABLE_PROT_SW0			= BIT(55),
>  	KVM_PGTABLE_PROT_SW1			= BIT(56),
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index fde4186cc387..c247e5f29d5a 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -147,6 +147,7 @@
>   * Memory types for Stage-2 translation
>   */
>  #define MT_S2_NORMAL		0xf
> +#define MT_S2_NORMAL_NC		0x5
>  #define MT_S2_DEVICE_nGnRE	0x1
>  
>  /*
> @@ -154,6 +155,7 @@
>   * Stage-2 enforces Normal-WB and Device-nGnRE
>   */
>  #define MT_S2_FWB_NORMAL	6
> +#define MT_S2_FWB_NORMAL_NC	5
>  #define MT_S2_FWB_DEVICE_nGnRE	1
>  
>  #ifdef CONFIG_ARM64_4K_PAGES
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index c651df904fe3..d4835d553c61 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -718,10 +718,17 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
>  				kvm_pte_t *ptep)
>  {
>  	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
> -	kvm_pte_t attr = device ? KVM_S2_MEMATTR(pgt, DEVICE_nGnRE) :
> -			    KVM_S2_MEMATTR(pgt, NORMAL);
> +	bool normal_nc = prot & KVM_PGTABLE_PROT_NORMAL_NC;
> +	kvm_pte_t attr;
>  	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
>  
> +	if (device)
> +		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
> +	else if (normal_nc)
> +		attr = KVM_S2_MEMATTR(pgt, NORMAL_NC);
> +	else
> +		attr = KVM_S2_MEMATTR(pgt, NORMAL);

I think it would be worth rejecting the case where both
KVM_PGTABLE_PROT_DEVICE and KVM_PGTABLE_PROT_NORMAL_NC are passed, since
that's clearly a bug in the caller and silently going with device is
arbitrary and confusing.

Will


From shawn.sung at mediatek.com  Tue Dec 12 04:19:42 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:42 +0800
Subject: [PATCH v4 02/17] soc: mediatek: Disable 9-bit alpha in ETHDR
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-3-shawn.sung@mediatek.com>

ETHDR 9-bit alpha should be disabled by default,
otherwise alpha blending will not work.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/soc/mediatek/mtk-mmsys.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index a456c3e0aee7..e471be3bafc1 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -226,6 +226,7 @@ void mtk_mmsys_mixer_in_config(struct device *dev, int idx, bool alpha_sel, u16
 
 	mtk_mmsys_update_bits(mmsys, MT8195_VDO1_MIXER_IN1_ALPHA + (idx - 1) * 4, ~0,
 			      alpha << 16 | alpha, cmdq_pkt);
+	mtk_mmsys_update_bits(mmsys, MT8195_VDO1_HDR_TOP_CFG, BIT(15 + idx), 0, cmdq_pkt);
 	mtk_mmsys_update_bits(mmsys, MT8195_VDO1_HDR_TOP_CFG, BIT(19 + idx),
 			      alpha_sel << (19 + idx), cmdq_pkt);
 	mtk_mmsys_update_bits(mmsys, MT8195_VDO1_MIXER_IN1_PAD + (idx - 1) * 4,
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:57 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:57 +0800
Subject: [PATCH v4 17/17] drm/mediatek: Add comments for the structures
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-18-shawn.sung@mediatek.com>

Add comments for the structures to improve readability.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c     | 21 +++++++++++++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c     | 22 ++++++++++++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 32 +++++++++++++++++++++
 drivers/gpu/drm/mediatek/mtk_drm_drv.h      | 15 ++++++++++
 drivers/gpu/drm/mediatek/mtk_ethdr.c        | 11 +++++++
 5 files changed, 97 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index f019737078f6..78e5327ceda7 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -164,6 +164,20 @@ static const u32 mt8195_ovl_crc_ofs[] = {
 	DISP_REG_OVL_CRC,
 };
 
+/**
+ * struct mtk_disp_ovl_data - ovl driver data
+ * @addr: offset of the first layer (layer-0)
+ * @gmc_bits: gmc (gating memory clock) bit masks for adjusting positivity for ovl
+ * @layer_nr: layer numbers that ovl supports
+ * @fmt_rgb565_is_0: whether or not rgb565 is represented as 0
+ * @smi_id_en: determine if smi needs to be enabled
+ * @supports_afbc: determine if ovl supports afbc
+ * @formats: format table that ovl supports
+ * @num_formats: number of formats that ovl supports
+ * @supports_clrfmt_ext: whether the ovl supports clear format (for alpha blend)
+ * @crc_ofs: crc offset table
+ * @crc_cnt: count of crc registers (could be more than one bank)
+ */
 struct mtk_disp_ovl_data {
 	unsigned int addr;
 	unsigned int gmc_bits;
@@ -178,10 +192,15 @@ struct mtk_disp_ovl_data {
 	size_t crc_cnt;
 };
 
-/*
+/**
  * struct mtk_disp_ovl - DISP_OVL driver structure
  * @crtc: associated crtc to report vblank events to
+ * @clk: clock of the ovl
+ * @regs: base address of the ovl register that can be accessed by cpu
+ * @cmdq_reg: register related info for cmdq (subsys, offset ...etc.)
  * @data: platform data
+ * @vblank_cb: callback function when vblank irq happened
+ * @vblank_cb_data: data to the callback function
  * @crc: crc related information
  */
 struct mtk_disp_ovl {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index fad728690db7..beefa5804911 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -28,14 +28,30 @@
  * struct mtk_drm_crtc - MediaTek specific crtc structure.
  * @base: crtc object.
  * @enabled: records whether crtc_enable succeeded
+ * @pending_needs_vblank: determine if we need to handle vblank event
+ * @event: the vblank event to handle
  * @planes: array of 4 drm_plane structures, one for each overlay plane
+ * @layer_nr: layer numbers that the crtc supports
  * @pending_planes: whether any plane has pending changes to be applied
+ * @pending_async_planes: if there is any pending async update
+ * @cmdq_client: a handler to control cmdq (mbox channel, thread ...etc.)
+ * @cmdq_handle: cmdq packet to store the commands
+ * @cmdq_event: cmdq event that the thread is waiting for
+ * @cmdq_vblank_cnt: vblank count that is dedicated for the cmdq thread
+ * @cb_blocking_queue: wait queue to determine if cmdq is blocked
  * @mmsys_dev: pointer to the mmsys device for configuration registers
+ * @dma_dev: pointer to the dma device (usually rdma)
  * @mutex: handle to one of the ten disp_mutex streams
- * @ddp_comp_nr: number of components in ddp_comp
+ * @ddp_comp_nr_ori: number of the components excludes the route (origin)
+ * @max_ddp_comp_nr: maximum number of the components in routes
+ * @ddp_comp_nr: number of the components in the current path
  * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
- *
- * TODO: Needs update: this header is missing a bunch of member descriptions.
+ * @conn_route_nr: number of the components in route
+ * @conn_routes: route to the connector
+ * @hw_lock: mutex lock to avoid race condition when layer config
+ * @config_updating: determine if the layer configuration is done
+ * @crc_provider: get crc provider of the crtc
+ * @frames: count the frames that are added to crc entry
  */
 struct mtk_drm_crtc {
 	struct drm_crtc			base;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 38d08796fae4..af80c9e50d36 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -46,6 +46,38 @@ enum mtk_ddp_comp_type {
 
 struct mtk_ddp_comp;
 struct cmdq_pkt;
+
+/* struct mtk_ddp_comp_funcs - function pointers of the ddp components
+ * @clk_enable: enable the clocks of the component
+ * @clk_disable: disable the clocks of the component
+ * @config: configure the component
+ * @start: start (enable) the component
+ * @stop: stop (disable) the component
+ * @register_vblank_cb: to register a callback function when vblank irq occurs
+ * @unregister_vblank_cb: to unregister the callback function from the vblank irq
+ * @enable_vblank: enable vblank irq
+ * @disable_vblank: disable vblank irq
+ * @supported_rotations: return rotation capability of the component
+ * @layer_nr: how many layers the component supports
+ * @layer_check: to check if the state of the layer is valid for the component
+ * @layer_config: to configure the component according to the state of the layer
+ * @gamma_set: to set gamma for the component
+ * @bgclr_in_on: turn on background color
+ * @bgclr_in_off: turn off background color
+ * @ctm_set: set color transformation matrix
+ * @dma_dev_get: return the device that uses direct memory access
+ * @get_formats: get the format that is currently in use by the component
+ * @get_num_formats: get number of the formats that the component supports
+ * @connect: connect the sub modules of the component
+ * @disconnect: disconnect the sub modules of the component
+ * @add: add the device to the component (mount them in the mutex)
+ * @remove: remove the device from the component (unmount them from the mutex)
+ * @encoder_index: get the encoder index of the component
+ * @crc: return the start of crc array
+ * @crc_cnt: how many CRCs the component supports
+ * @crc_entry: get the pointer to the crc entry
+ * @crc_read: call this function to read crc from the hardware component
+ */
 struct mtk_ddp_comp_funcs {
 	int (*power_on)(struct device *dev);
 	void (*power_off)(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 3d6c1f58a7ec..6430433fd20d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -28,6 +28,21 @@ struct mtk_drm_route {
 	const unsigned int *route_ddp;
 };
 
+/**
+ * struct mtk_mmsys_driver_data - capabilities for the mmsys
+ * @main_path: path of the main display
+ * @main_len: length of the main display path
+ * @ext_path: path of the external display
+ * @ext_len: length of the external display path
+ * @third_path: path of the third display
+ * @third_len: length of the third display path
+ * @conn_routes: routing table of all the possible connectors
+ * @conn_routes_num: number of the routing table for the connectors
+ * @shadow_register: whether or not shadow register is enabled
+ * @mmsys_id: multi-media system ID
+ * @mmsys_dev_num: number of devices for in the mmsys as a whole
+ * @max_pitch: maximum pitch in bytes that the mmsys supports
+ */
 struct mtk_mmsys_driver_data {
 	const unsigned int *main_path;
 	unsigned int main_len;
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c b/drivers/gpu/drm/mediatek/mtk_ethdr.c
index 30eb2c3d95c0..eae72deacfd2 100644
--- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
@@ -82,6 +82,17 @@ struct mtk_ethdr_comp {
 	struct cmdq_client_reg	cmdq_base;
 };
 
+/**
+ * struct mtk_ethdr - ethdr driver data
+ * @ethdr_comp: components of ethdr(mixer)
+ * @ethdr_clk: clocks of ethdr components
+ * @mmsys_dev: mmsys device that ethdr binds to
+ * @vblank_cb: callback function when vblank irq occurs
+ * @vblank_cb_data: data fo vblank callback
+ * @irq: irq that triggers irq handler
+ * @reset_ctl: reset control of ethdr
+ * @crc: crc information
+ */
 struct mtk_ethdr {
 	struct mtk_ethdr_comp	ethdr_comp[ETHDR_ID_MAX];
 	struct clk_bulk_data	ethdr_clk[ETHDR_CLK_NUM];
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:44 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:44 +0800
Subject: [PATCH v4 04/17] drm/mediatek: Add OVL compatible name for MT8195
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-5-shawn.sung@mediatek.com>

Add OVL compatible name for MT8195.

Without this commit, DRM won't work after modifying
the device tree.

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index eecfeb8fbde1..5d551bff6b3f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -767,6 +767,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
 	  .data = (void *)MTK_DISP_OVL },
 	{ .compatible = "mediatek,mt8192-disp-ovl",
 	  .data = (void *)MTK_DISP_OVL },
+	{ .compatible = "mediatek,mt8195-disp-ovl",
+	  .data = (void *)MTK_DISP_OVL },
 	{ .compatible = "mediatek,mt8183-disp-ovl-2l",
 	  .data = (void *)MTK_DISP_OVL_2L },
 	{ .compatible = "mediatek,mt8192-disp-ovl-2l",
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:50 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:50 +0800
Subject: [PATCH v4 10/17] drm/mediatek: Support more color formats in OVL
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-11-shawn.sung@mediatek.com>

Support more color formats in Overlay.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 7e217142d0c4..a3f1630af5df 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -130,12 +130,20 @@ static const u32 mt8173_formats[] = {
 static const u32 mt8195_formats[] = {
 	DRM_FORMAT_XRGB8888,
 	DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_XRGB2101010,
 	DRM_FORMAT_ARGB2101010,
 	DRM_FORMAT_BGRX8888,
 	DRM_FORMAT_BGRA8888,
+	DRM_FORMAT_BGRX1010102,
 	DRM_FORMAT_BGRA1010102,
 	DRM_FORMAT_ABGR8888,
 	DRM_FORMAT_XBGR8888,
+	DRM_FORMAT_XBGR2101010,
+	DRM_FORMAT_ABGR2101010,
+	DRM_FORMAT_RGBX8888,
+	DRM_FORMAT_RGBA8888,
+	DRM_FORMAT_RGBX1010102,
+	DRM_FORMAT_RGBA1010102,
 	DRM_FORMAT_RGB888,
 	DRM_FORMAT_BGR888,
 	DRM_FORMAT_RGB565,
@@ -431,12 +439,16 @@ static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt,
 		return blend_mode == DRM_MODE_BLEND_COVERAGE ?
 		       OVL_CON_CLRFMT_ARGB8888 :
 		       OVL_CON_CLRFMT_PARGB8888;
+	case DRM_FORMAT_RGBX1010102:
+	case DRM_FORMAT_RGBA1010102:
+		return OVL_CON_CLRFMT_ARGB8888;
 	case DRM_FORMAT_BGRX8888:
 	case DRM_FORMAT_BGRA8888:
 		return OVL_CON_BYTE_SWAP |
 		       (blend_mode == DRM_MODE_BLEND_COVERAGE ?
 		       OVL_CON_CLRFMT_ARGB8888 :
 		       OVL_CON_CLRFMT_PARGB8888);
+	case DRM_FORMAT_BGRX1010102:
 	case DRM_FORMAT_BGRA1010102:
 		return OVL_CON_CLRFMT_ARGB8888 | OVL_CON_BYTE_SWAP;
 	case DRM_FORMAT_XRGB8888:
@@ -444,6 +456,7 @@ static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt,
 		return blend_mode == DRM_MODE_BLEND_COVERAGE ?
 		       OVL_CON_CLRFMT_RGBA8888 :
 		       OVL_CON_CLRFMT_PARGB8888;
+	case DRM_FORMAT_XRGB2101010:
 	case DRM_FORMAT_ARGB2101010:
 		return OVL_CON_CLRFMT_RGBA8888;
 	case DRM_FORMAT_XBGR8888:
@@ -452,6 +465,9 @@ static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt,
 		       (blend_mode == DRM_MODE_BLEND_COVERAGE ?
 		       OVL_CON_CLRFMT_RGBA8888 :
 		       OVL_CON_CLRFMT_PARGB8888);
+	case DRM_FORMAT_XBGR2101010:
+	case DRM_FORMAT_ABGR2101010:
+		return OVL_CON_CLRFMT_RGBA8888 | OVL_CON_BYTE_SWAP;
 	case DRM_FORMAT_UYVY:
 		return OVL_CON_CLRFMT_UYVY | OVL_CON_MTX_YUV_TO_RGB;
 	case DRM_FORMAT_YUYV:
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:43 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:43 +0800
Subject: [PATCH v4 03/17] dt-bindings: display: mediatek: ovl: Modify rules for MT8195/MT8188
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-4-shawn.sung@mediatek.com>

Modify rules for both MT8195 and MT8188.
Hardware capabilities include color formats and AFBC are
changed since MT8195, stop using the settings of MT8183.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../bindings/display/mediatek/mediatek,ovl.yaml      | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index 92e320d54ba2..b37208a9e370 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -26,20 +26,18 @@ properties:
           - mediatek,mt8173-disp-ovl
           - mediatek,mt8183-disp-ovl
           - mediatek,mt8192-disp-ovl
+          - mediatek,mt8195-disp-ovl
       - items:
           - enum:
               - mediatek,mt7623-disp-ovl
               - mediatek,mt2712-disp-ovl
           - const: mediatek,mt2701-disp-ovl
       - items:
-          - enum:
-              - mediatek,mt8188-disp-ovl
-              - mediatek,mt8195-disp-ovl
-          - const: mediatek,mt8183-disp-ovl
-      - items:
-          - enum:
-              - mediatek,mt8186-disp-ovl
+          - const: mediatek,mt8186-disp-ovl
           - const: mediatek,mt8192-disp-ovl
+      - items:
+          - const: mediatek,mt8188-disp-ovl
+          - const: mediatek,mt8195-disp-ovl
 
   reg:
     maxItems: 1
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:47 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:47 +0800
Subject: [PATCH v4 07/17] drm/mediatek: Support alpha blending in Mixer
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-8-shawn.sung@mediatek.com>

Support premultiply and coverage alpha blending in
Mixer.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_ethdr.c | 26 +++++++++++++++++++-------
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c b/drivers/gpu/drm/mediatek/mtk_ethdr.c
index 73dc4da3ba3b..73c9e3da56a7 100644
--- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
@@ -5,6 +5,7 @@
 
 #include <drm/drm_fourcc.h>
 #include <drm/drm_framebuffer.h>
+#include <drm/drm_blend.h>
 #include <linux/clk.h>
 #include <linux/component.h>
 #include <linux/of_device.h>
@@ -35,6 +36,7 @@
 #define MIX_SRC_L0_EN				BIT(0)
 #define MIX_L_SRC_CON(n)		(0x28 + 0x18 * (n))
 #define NON_PREMULTI_SOURCE			(2 << 12)
+#define PREMULTI_SOURCE				(3 << 12)
 #define MIX_L_SRC_SIZE(n)		(0x30 + 0x18 * (n))
 #define MIX_L_SRC_OFFSET(n)		(0x34 + 0x18 * (n))
 #define MIX_FUNC_DCM0			0x120
@@ -153,7 +155,8 @@ void mtk_ethdr_layer_config(struct device *dev, unsigned int idx,
 	struct mtk_plane_pending_state *pending = &state->pending;
 	unsigned int offset = (pending->x & 1) << 31 | pending->y << 16 | pending->x;
 	unsigned int align_width = ALIGN_DOWN(pending->width, 2);
-	unsigned int alpha_con = 0;
+	unsigned int mix_con = NON_PREMULTI_SOURCE;
+	bool replace_src_a = false;
 
 	dev_dbg(dev, "%s+ idx:%d", __func__, idx);
 
@@ -165,19 +168,28 @@ void mtk_ethdr_layer_config(struct device *dev, unsigned int idx,
 		return;
 	}
 
-	if (state->base.fb && state->base.fb->format->has_alpha)
-		alpha_con = MIXER_ALPHA_AEN | MIXER_ALPHA;
+	mix_con |= MIXER_ALPHA_AEN | (state->base.alpha & MIXER_ALPHA);
 
-	mtk_mmsys_mixer_in_config(priv->mmsys_dev, idx + 1, alpha_con ? false : true,
-				  DEFAULT_9BIT_ALPHA,
+	if (state->base.pixel_blend_mode != DRM_MODE_BLEND_COVERAGE)
+		mix_con |= PREMULTI_SOURCE;
+
+	if (state->base.pixel_blend_mode == DRM_MODE_BLEND_PIXEL_NONE ||
+	    (state->base.fb && !state->base.fb->format->has_alpha)) {
+		/*
+		 * Mixer doesn't support CONST_BLD mode,
+		 * use a trick to make the output equivalent
+		 */
+		replace_src_a = true;
+	}
+
+	mtk_mmsys_mixer_in_config(priv->mmsys_dev, idx + 1, replace_src_a, MIXER_ALPHA,
 				  pending->x & 1 ? MIXER_INX_MODE_EVEN_EXTEND :
 				  MIXER_INX_MODE_BYPASS, align_width / 2 - 1, cmdq_pkt);
 
 	mtk_ddp_write(cmdq_pkt, pending->height << 16 | align_width, &mixer->cmdq_base,
 		      mixer->regs, MIX_L_SRC_SIZE(idx));
 	mtk_ddp_write(cmdq_pkt, offset, &mixer->cmdq_base, mixer->regs, MIX_L_SRC_OFFSET(idx));
-	mtk_ddp_write_mask(cmdq_pkt, alpha_con, &mixer->cmdq_base, mixer->regs, MIX_L_SRC_CON(idx),
-			   0x1ff);
+	mtk_ddp_write(cmdq_pkt, mix_con, &mixer->cmdq_base, mixer->regs, MIX_L_SRC_CON(idx));
 	mtk_ddp_write_mask(cmdq_pkt, BIT(idx), &mixer->cmdq_base, mixer->regs, MIX_SRC_CON,
 			   BIT(idx));
 }
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:51 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:51 +0800
Subject: [PATCH v4 11/17] drm/mediatek: Turn off the layers with zero width or height
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-12-shawn.sung@mediatek.com>

We found that IGT (Intel GPU Tool) will try to commit layers with
zero width or height and lead to undefined behaviors in hardware.
Disable the layers in such situations.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 2 +-
 drivers/gpu/drm/mediatek/mtk_ethdr.c            | 7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 10d23e76acaa..8789442c039f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -156,7 +156,7 @@ void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
 	merge = ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_MERGE0 + idx];
 	ethdr = ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0];
 
-	if (!pending->enable) {
+	if (!pending->enable || !pending->width || !pending->height) {
 		mtk_merge_stop_cmdq(merge, cmdq_pkt);
 		mtk_mdp_rdma_stop(rdma_l, cmdq_pkt);
 		mtk_mdp_rdma_stop(rdma_r, cmdq_pkt);
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c b/drivers/gpu/drm/mediatek/mtk_ethdr.c
index 73c9e3da56a7..e95331c06815 100644
--- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
@@ -163,7 +163,12 @@ void mtk_ethdr_layer_config(struct device *dev, unsigned int idx,
 	if (idx >= 4)
 		return;
 
-	if (!pending->enable) {
+	if (!pending->enable || !pending->width || !pending->height) {
+		/*
+		 * instead of disabling layer with MIX_SRC_CON directly
+		 * set the size to 0 to avoid screen shift due to mixer
+		 * mode switch (hardware behavior)
+		 */
 		mtk_ddp_write(cmdq_pkt, 0, &mixer->cmdq_base, mixer->regs, MIX_L_SRC_SIZE(idx));
 		return;
 	}
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:41 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:41 +0800
Subject: [PATCH v4 01/17] soc: mediatek: Add register definitions for GCE
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-2-shawn.sung@mediatek.com>

Add register definitions for GCE so users can use them
as a buffer to store data.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 include/linux/soc/mediatek/mtk-cmdq.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 649955d2cf5c..a253c001c861 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -14,6 +14,16 @@
 #define CMDQ_ADDR_HIGH(addr)	((u32)(((addr) >> 16) & GENMASK(31, 0)))
 #define CMDQ_ADDR_LOW(addr)	((u16)(addr) | BIT(1))
 
+/*
+ * Every cmdq thread has its own SPRs (Specific Purpose Registers),
+ * so there are 4 * 24 (threads) = 96 SPRs in GCE that shares the
+ * same indexes below
+ */
+#define CMDQ_THR_SPR_IDX0	(0)
+#define CMDQ_THR_SPR_IDX1	(1)
+#define CMDQ_THR_SPR_IDX2	(2)
+#define CMDQ_THR_SPR_IDX3	(3)
+
 struct cmdq_pkt;
 
 struct cmdq_client_reg {
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:49 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:49 +0800
Subject: [PATCH v4 09/17] drm/mediatek: Support CSC in OVL
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-10-shawn.sung@mediatek.com>

Support Color Transform Control (CSC) in Overlay to
do Y2R or R2R conversion.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 121 +++++++++++++++++++++++-
 1 file changed, 118 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 66074c2d917c..7e217142d0c4 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -31,6 +31,7 @@
 #define OVL_LAYER_SMI_ID_EN				BIT(0)
 #define OVL_BGCLR_SEL_IN				BIT(2)
 #define OVL_LAYER_AFBC_EN(n)				BIT(4+n)
+#define OVL_OUTPUT_CLAMP				BIT(26)
 #define DISP_REG_OVL_ROI_BGCLR			0x0028
 #define DISP_REG_OVL_SRC_CON			0x002c
 #define DISP_REG_OVL_CON(n)			(0x0030 + 0x20 * (n))
@@ -44,6 +45,23 @@
 #define DISP_REG_OVL_RDMA_GMC(n)		(0x00c8 + 0x20 * (n))
 #define DISP_REG_OVL_ADDR_MT2701		0x0040
 #define DISP_REG_OVL_CLRFMT_EXT			0x02D0
+#define DISP_REG_OVL_CLRFMT_EXT1		0x02D8
+#define OVL_CLRFMT_EXT1_CSC_EN(n)			(1 << (((n) * 4) + 1))
+#define DISP_REG_OVL_Y2R_PARA_R0(n)		(0x0134 + 0x28 * (n))
+#define OVL_Y2R_PARA_C_CF_RMY				(GENMASK(14, 0))
+#define DISP_REG_OVL_Y2R_PARA_G0(n)		(0x013c + 0x28 * (n))
+#define OVL_Y2R_PARA_C_CF_GMU				(GENMASK(30, 16))
+#define DISP_REG_OVL_Y2R_PARA_B1(n)		(0x0148 + 0x28 * (n))
+#define OVL_Y2R_PARA_C_CF_BMV				(GENMASK(14, 0))
+#define DISP_REG_OVL_Y2R_PARA_YUV_A_0(n)	(0x014c + 0x28 * (n))
+#define OVL_Y2R_PARA_C_CF_YA				(GENMASK(10, 0))
+#define OVL_Y2R_PARA_C_CF_UA				(GENMASK(26, 16))
+#define DISP_REG_OVL_Y2R_PARA_YUV_A_1(n)	(0x0150 + 0x28 * (n))
+#define OVL_Y2R_PARA_C_CF_VA				(GENMASK(10, 0))
+#define DISP_REG_OVL_Y2R_PRE_ADD2(n)		(0x0154 + 0x28 * (n))
+#define DISP_REG_OVL_R2R_R0(n)			(0x0500 + 0x40 * (n))
+#define DISP_REG_OVL_R2R_G1(n)			(0x0510 + 0x40 * (n))
+#define DISP_REG_OVL_R2R_B2(n)			(0x0520 + 0x40 * (n))
 #define DISP_REG_OVL_ADDR_MT8173		0x0f40
 #define DISP_REG_OVL_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n))
 #define DISP_REG_OVL_HDR_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n) + 0x04)
@@ -56,6 +74,8 @@
 #define OVL_CON_CLRFMT_MAN		BIT(23)
 #define OVL_CON_BYTE_SWAP		BIT(24)
 #define OVL_CON_RGB_SWAP		BIT(25)
+#define OVL_CON_MTX_AUTO_DIS		BIT(26)
+#define OVL_CON_MTX_EN			BIT(27)
 #define OVL_CON_CLRFMT_RGB		(1 << 12)
 #define OVL_CON_CLRFMT_RGBA8888		(2 << 12)
 #define OVL_CON_CLRFMT_ARGB8888		(3 << 12)
@@ -63,6 +83,7 @@
 #define OVL_CON_CLRFMT_UYVY		(4 << 12)
 #define OVL_CON_CLRFMT_YUYV		(5 << 12)
 #define OVL_CON_MTX_YUV_TO_RGB		(6 << 16)
+#define OVL_CON_MTX_PROGRAMMABLE	(8 << 16)
 #define OVL_CON_CLRFMT_RGB565(ovl)	((ovl)->data->fmt_rgb565_is_0 ? \
 					0 : OVL_CON_CLRFMT_RGB)
 #define OVL_CON_CLRFMT_RGB888(ovl)	((ovl)->data->fmt_rgb565_is_0 ? \
@@ -76,6 +97,22 @@
 #define	OVL_CON_VIRT_FLIP	BIT(9)
 #define	OVL_CON_HORZ_FLIP	BIT(10)
 
+static inline bool is_10bit_rgb(u32 fmt)
+{
+	switch (fmt) {
+	case DRM_FORMAT_XRGB2101010:
+	case DRM_FORMAT_ARGB2101010:
+	case DRM_FORMAT_RGBX1010102:
+	case DRM_FORMAT_RGBA1010102:
+	case DRM_FORMAT_XBGR2101010:
+	case DRM_FORMAT_ABGR2101010:
+	case DRM_FORMAT_BGRX1010102:
+	case DRM_FORMAT_BGRA1010102:
+		return true;
+	}
+	return false;
+}
+
 static const u32 mt8173_formats[] = {
 	DRM_FORMAT_XRGB8888,
 	DRM_FORMAT_ARGB8888,
@@ -217,6 +254,14 @@ void mtk_ovl_start(struct device *dev)
 	if (ovl->data->smi_id_en)
 		reg |= OVL_LAYER_SMI_ID_EN;
 
+	/*
+	 * When doing Y2R conversion, it's common to get an output
+	 * that is larger than 10 bits (negative numbers).
+	 * Enable this bit to clamp the output to 10 bits per channel
+	 * (should always be enabled)
+	 */
+	reg |= OVL_OUTPUT_CLAMP;
+
 	writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
 	writel_relaxed(0x1, ovl->regs + DISP_REG_OVL_EN);
 }
@@ -256,9 +301,7 @@ static void mtk_ovl_set_bit_depth(struct device *dev, int idx, u32 format,
 	reg = readl(ovl->regs + DISP_REG_OVL_CLRFMT_EXT);
 	reg &= ~OVL_CON_CLRFMT_BIT_DEPTH_MASK(idx);
 
-	if (format == DRM_FORMAT_RGBA1010102 ||
-	    format == DRM_FORMAT_BGRA1010102 ||
-	    format == DRM_FORMAT_ARGB2101010)
+	if (is_10bit_rgb(format))
 		bit_depth = OVL_CON_CLRFMT_10_BIT;
 
 	reg |= OVL_CON_CLRFMT_BIT_DEPTH(bit_depth, idx);
@@ -458,6 +501,78 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
 	    (state->base.fb && !state->base.fb->format->has_alpha))
 		ignore_pixel_alpha = OVL_CONST_BLEND;
 
+	/* need to do Y2R and R2R to reduce 10bit data to 8bit for CRC calculation */
+	if (ovl->data->supports_clrfmt_ext) {
+		u32 y2r_coef = 0, y2r_offset = 0, r2r_coef = 0, csc_en = 0;
+
+		if (is_10bit_rgb(fmt)) {
+			con |= OVL_CON_MTX_AUTO_DIS | OVL_CON_MTX_EN | OVL_CON_MTX_PROGRAMMABLE;
+
+			/*
+			 * Y2R coef setting
+			 * bit 13 is 2^1, bit 12 is 2^0, bit 11 is 2^-1,
+			 * bit 10 is 2^-2 = 0.25
+			 */
+			y2r_coef = BIT(10);
+
+			/* -1 in 10bit */
+			y2r_offset = GENMASK(10, 0) - 1;
+
+			/*
+			 * R2R coef setting
+			 * bit 19 is 2^1, bit 18 is 2^0, bit 17 is 2^-1,
+			 * bit 20 is 2^2 = 4
+			 */
+			r2r_coef = BIT(20);
+
+			/* CSC_EN is for R2R */
+			csc_en = OVL_CLRFMT_EXT1_CSC_EN(idx);
+
+			/*
+			 * 1. YUV input data - 1 and shift right for 2 bits to remove it
+			 * [R']   [0.25    0    0]   [Y in - 1]
+			 * [G'] = [   0 0.25    0] * [U in - 1]
+			 * [B']   [   0    0 0.25]   [V in - 1]
+			 *
+			 * 2. shift left for 2 bit letting the last 2 bits become 0
+			 * [R out]   [ 4  0  0]   [R']
+			 * [G out] = [ 0  4  0] * [G']
+			 * [B out]   [ 0  0  4]   [B']
+			 */
+		}
+
+		mtk_ddp_write_mask(cmdq_pkt, y2r_coef,
+				   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_Y2R_PARA_R0(idx),
+				   OVL_Y2R_PARA_C_CF_RMY);
+		mtk_ddp_write_mask(cmdq_pkt, (y2r_coef << 16),
+				   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_Y2R_PARA_G0(idx),
+				   OVL_Y2R_PARA_C_CF_GMU);
+		mtk_ddp_write_mask(cmdq_pkt, y2r_coef,
+				   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_Y2R_PARA_B1(idx),
+				   OVL_Y2R_PARA_C_CF_BMV);
+
+		mtk_ddp_write_mask(cmdq_pkt, y2r_offset,
+				   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_Y2R_PARA_YUV_A_0(idx),
+				   OVL_Y2R_PARA_C_CF_YA);
+		mtk_ddp_write_mask(cmdq_pkt, (y2r_offset << 16),
+				   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_Y2R_PARA_YUV_A_0(idx),
+				   OVL_Y2R_PARA_C_CF_UA);
+		mtk_ddp_write_mask(cmdq_pkt, y2r_offset,
+				   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_Y2R_PARA_YUV_A_1(idx),
+				   OVL_Y2R_PARA_C_CF_VA);
+
+		mtk_ddp_write_relaxed(cmdq_pkt, r2r_coef,
+				      &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_R2R_R0(idx));
+		mtk_ddp_write_relaxed(cmdq_pkt, r2r_coef,
+				      &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_R2R_G1(idx));
+		mtk_ddp_write_relaxed(cmdq_pkt, r2r_coef,
+				      &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_R2R_B2(idx));
+
+		mtk_ddp_write_mask(cmdq_pkt, csc_en,
+				   &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_CLRFMT_EXT1,
+				   OVL_CLRFMT_EXT1_CSC_EN(idx));
+	}
+
 	if (pending->rotation & DRM_MODE_REFLECT_Y) {
 		con |= OVL_CON_VIRT_FLIP;
 		addr += (pending->height - 1) * pending->pitch;
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:56 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:56 +0800
Subject: [PATCH v4 16/17] drm/mediatek: Fix errors when reporting rotation capability
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-17-shawn.sung@mediatek.com>

Create rotation property according to the hardware capability.
Since currently OVL of all chips support same rotation,
no need to define it in the driver data.

Fixes: 84d805753983 ("drm/mediatek: Support reflect-y plane rotation")

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h        |  1 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c        | 18 ++++++------------
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c    |  9 +++++++++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c    |  1 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.c       |  2 +-
 5 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 4d6e8b667bc3..c5afeb7c5527 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -127,6 +127,7 @@ void mtk_ovl_adaptor_register_vblank_cb(struct device *dev, void (*vblank_cb)(vo
 void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev);
 void mtk_ovl_adaptor_enable_vblank(struct device *dev);
 void mtk_ovl_adaptor_disable_vblank(struct device *dev);
+unsigned int mtk_ovl_adaptor_supported_rotations(struct device *dev);
 void mtk_ovl_adaptor_start(struct device *dev);
 void mtk_ovl_adaptor_stop(struct device *dev);
 unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 78749dabeb43..f019737078f6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -399,6 +399,10 @@ unsigned int mtk_ovl_layer_nr(struct device *dev)
 
 unsigned int mtk_ovl_supported_rotations(struct device *dev)
 {
+	/*
+	 * although currently OVL can only do reflection,
+	 * reflect x + reflect y = rotate 180
+	 */
 	return DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180 |
 	       DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
 }
@@ -407,27 +411,17 @@ int mtk_ovl_layer_check(struct device *dev, unsigned int idx,
 			struct mtk_plane_state *mtk_state)
 {
 	struct drm_plane_state *state = &mtk_state->base;
-	unsigned int rotation = 0;
 
-	rotation = drm_rotation_simplify(state->rotation,
-					 DRM_MODE_ROTATE_0 |
-					 DRM_MODE_REFLECT_X |
-					 DRM_MODE_REFLECT_Y);
-	rotation &= ~DRM_MODE_ROTATE_0;
-
-	/* We can only do reflection, not rotation */
-	if ((rotation & DRM_MODE_ROTATE_MASK) != 0)
+	if (state->rotation & ~mtk_ovl_supported_rotations(dev))
 		return -EINVAL;
 
 	/*
 	 * TODO: Rotating/reflecting YUV buffers is not supported at this time.
 	 *	 Only RGB[AX] variants are supported.
 	 */
-	if (state->fb->format->is_yuv && rotation != 0)
+	if (state->fb->format->is_yuv && (state->rotation & ~DRM_MODE_ROTATE_0))
 		return -EINVAL;
 
-	state->rotation = rotation;
-
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 4398db9a6276..273c79d37bef 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -383,6 +383,15 @@ void mtk_ovl_adaptor_register_vblank_cb(struct device *dev, void (*vblank_cb)(vo
 				     vblank_cb, vblank_cb_data);
 }
 
+unsigned int mtk_ovl_adaptor_supported_rotations(struct device *dev)
+{
+	/*
+	 * should still return DRM_MODE_ROTATE_0 if rotation is not supported,
+	 * or IGT will fail.
+	 */
+	return DRM_MODE_ROTATE_0;
+}
+
 void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev)
 {
 	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index ffa4868b1222..206dd6f6f99e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -422,6 +422,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl_adaptor = {
 	.remove = mtk_ovl_adaptor_remove_comp,
 	.get_formats = mtk_ovl_adaptor_get_formats,
 	.get_num_formats = mtk_ovl_adaptor_get_num_formats,
+	.supported_rotations = mtk_ovl_adaptor_supported_rotations,
 };
 
 static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index ff300426b590..e73b9793dee2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -343,7 +343,7 @@ int mtk_plane_init(struct drm_device *dev, struct drm_plane *plane,
 		return err;
 	}
 
-	if (supported_rotations & ~DRM_MODE_ROTATE_0) {
+	if (supported_rotations) {
 		err = drm_plane_create_rotation_property(plane,
 							 DRM_MODE_ROTATE_0,
 							 supported_rotations);
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:52 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:52 +0800
Subject: [PATCH v4 12/17] drm/mediatek: Support CRC in display driver
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-13-shawn.sung@mediatek.com>

Register CRC related function pointers to support
CRC retrieval.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c     | 239 ++++++++++++++++++++
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h     |  39 ++++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   3 +
 3 files changed, 281 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index bc4cc75cca18..fad728690db7 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -71,6 +71,9 @@ struct mtk_drm_crtc {
 	/* lock for display hardware access */
 	struct mutex			hw_lock;
 	bool				config_updating;
+
+	struct mtk_ddp_comp		*crc_provider;
+	unsigned int			frames;
 };
 
 struct mtk_crtc_state {
@@ -625,6 +628,14 @@ static void mtk_crtc_ddp_irq(void *data)
 	struct drm_crtc *crtc = data;
 	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
 	struct mtk_drm_private *priv = crtc->dev->dev_private;
+	struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
+
+	/*
+	 * crc providers should make sure the crc is always correct
+	 * by resetting it in .crc_read()
+	 */
+	if (crtc->crc.opened)
+		comp->funcs->crc_read(comp->dev);
 
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 	if (!priv->data->shadow_register && !mtk_crtc->cmdq_client.chan)
@@ -636,6 +647,24 @@ static void mtk_crtc_ddp_irq(void *data)
 	if (!priv->data->shadow_register)
 		mtk_crtc_ddp_config(crtc, NULL);
 #endif
+
+	/*
+	 * drm_crtc_add_crc_entry() could take more than 50ms to finish
+	 * put it at the end of the isr
+	 */
+	if (crtc->crc.opened) {
+		/*
+		 * skip the first crc because the first frame is configured by
+		 * mtk_crtc_ddp_hw_init() when atomic enable
+		 */
+		if (++mtk_crtc->frames > 1) {
+			drm_crtc_add_crc_entry(crtc, true,
+					       drm_crtc_vblank_count(crtc),
+					       comp->funcs->crc_entry(comp->dev));
+		}
+	} else {
+		mtk_crtc->frames = 0;
+	}
 	mtk_drm_finish_page_flip(mtk_crtc);
 }
 
@@ -736,6 +765,40 @@ static int mtk_drm_crtc_update_output(struct drm_crtc *crtc,
 	return 0;
 }
 
+static int mtk_drm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src)
+{
+	if (src && strcmp(src, "auto") != 0) {
+		DRM_ERROR("%s(crtc-%d): unknown source '%s'\n",
+			  __func__, drm_crtc_index(crtc), src);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int mtk_drm_crtc_verify_crc_source(struct drm_crtc *crtc,
+					  const char *src,
+					  size_t *cnt)
+{
+	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+	struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
+
+	if (!comp) {
+		DRM_ERROR("%s(crtc-%d): no crc provider\n",
+			  __func__, drm_crtc_index(crtc));
+		return -ENOENT;
+	}
+
+	if (src && strcmp(src, "auto") != 0) {
+		DRM_ERROR("%s(crtc-%d): unknown source '%s'\n",
+			  __func__, drm_crtc_index(crtc), src);
+		return -EINVAL;
+	}
+
+	*cnt = comp->funcs->crc_cnt(comp->dev);
+
+	return 0;
+}
+
 int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,
 			     struct mtk_plane_state *state)
 {
@@ -872,6 +935,8 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
 	.atomic_destroy_state	= mtk_drm_crtc_destroy_state,
 	.enable_vblank		= mtk_drm_crtc_enable_vblank,
 	.disable_vblank		= mtk_drm_crtc_disable_vblank,
+	.set_crc_source		= mtk_drm_crtc_set_crc_source,
+	.verify_crc_source	= mtk_drm_crtc_verify_crc_source,
 };
 
 static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
@@ -1073,6 +1138,11 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
 
 			if (comp->funcs->ctm_set)
 				has_ctm = true;
+
+			if (comp->funcs->crc_cnt &&
+			    comp->funcs->crc_entry &&
+			    comp->funcs->crc_read)
+				mtk_crtc->crc_provider = comp;
 		}
 
 		mtk_ddp_comp_register_vblank_cb(comp, mtk_crtc_ddp_irq,
@@ -1152,3 +1222,172 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
 #endif
 	return 0;
 }
+
+void mtk_drm_crc_init(struct mtk_drm_crc *crc,
+		      const u32 *crc_offset_table, size_t crc_count,
+		      u32 reset_offset, u32 reset_mask)
+{
+	crc->ofs = crc_offset_table;
+	crc->cnt = crc_count;
+	crc->rst_ofs = reset_offset;
+	crc->rst_msk = reset_mask;
+	crc->va = kcalloc(crc->cnt, sizeof(*crc->va), GFP_KERNEL);
+	if (!crc->va) {
+		DRM_ERROR("failed to allocate memory for crc\n");
+		crc->cnt = 0;
+	}
+}
+
+void mtk_drm_crc_read(struct mtk_drm_crc *crc, void __iomem *reg)
+{
+	if (!crc->cnt || !crc->ofs || !crc->va)
+		return;
+
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	/* sync to see the most up-to-date copy of the DMA buffer */
+	dma_sync_single_for_cpu(crc->cmdq_client.chan->mbox->dev,
+				crc->pa, crc->cnt * sizeof(*crc->va),
+				DMA_FROM_DEVICE);
+#else
+	/* read crc with cpu for the platforms without cmdq */
+	{
+		u32 n;
+
+		for (n = 0; n < crc->cnt; n++)
+			crc->va[n] = readl(reg + crc->ofs[n]);
+
+		n = readl(reg + crc->rst_ofs);
+
+		/* pull reset bit */
+		n |= crc->rst_msk;
+		writel(n, reg + crc->rst_ofs);
+
+		/* release reset bit */
+		n &= ~crc->rst_msk;
+		writel(n, reg + crc->rst_ofs);
+	}
+#endif
+}
+
+void mtk_drm_crc_destroy(struct mtk_drm_crc *crc)
+{
+	if (!crc->cnt)
+		return;
+
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	if (crc->pa) {
+		dma_unmap_single(crc->cmdq_client.chan->mbox->dev,
+				 crc->pa, crc->cnt * sizeof(*crc->va),
+				 DMA_TO_DEVICE);
+		crc->pa = 0;
+	}
+	if (crc->cmdq_client.chan) {
+		mtk_drm_cmdq_pkt_destroy(&crc->cmdq_handle);
+		mbox_free_channel(crc->cmdq_client.chan);
+		crc->cmdq_client.chan = NULL;
+	}
+#endif
+	kfree(crc->va);
+	crc->va = NULL;
+	crc->cnt = 0;
+}
+
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+void mtk_drm_crc_cmdq_create(struct device *dev, struct mtk_drm_crc *crc)
+{
+	int i;
+
+	if (!crc->cnt) {
+		dev_warn(dev, "%s: not support\n", __func__);
+		goto cleanup;
+	}
+
+	if (!crc->ofs) {
+		dev_warn(dev, "%s: not defined\n", __func__);
+		goto cleanup;
+	}
+
+	crc->cmdq_client.client.dev = dev;
+	crc->cmdq_client.client.tx_block = false;
+	crc->cmdq_client.client.knows_txdone = true;
+	crc->cmdq_client.client.rx_callback = NULL;
+	crc->cmdq_client.chan = mbox_request_channel(&crc->cmdq_client.client, 0);
+	if (IS_ERR(crc->cmdq_client.chan)) {
+		dev_warn(dev, "%s: failed to create mailbox client\n", __func__);
+		crc->cmdq_client.chan = NULL;
+		goto cleanup;
+	}
+
+	if (mtk_drm_cmdq_pkt_create(&crc->cmdq_client, &crc->cmdq_handle, PAGE_SIZE)) {
+		dev_warn(dev, "%s: failed to create cmdq packet\n", __func__);
+		goto cleanup;
+	}
+
+	if (!crc->va) {
+		dev_warn(dev, "%s: no memory\n", __func__);
+		goto cleanup;
+	}
+
+	/* map the entry to get a dma address for cmdq to store the crc */
+	crc->pa = dma_map_single(crc->cmdq_client.chan->mbox->dev,
+				 crc->va, crc->cnt * sizeof(*crc->va),
+				 DMA_FROM_DEVICE);
+
+	if (dma_mapping_error(crc->cmdq_client.chan->mbox->dev, crc->pa)) {
+		dev_err(dev, "%s: failed to map dma\n", __func__);
+		goto cleanup;
+	}
+
+	if (crc->cmdq_event)
+		cmdq_pkt_wfe(&crc->cmdq_handle, crc->cmdq_event, true);
+
+	for (i = 0; i < crc->cnt; i++) {
+		/* put crc to spr1 register */
+		cmdq_pkt_read_s(&crc->cmdq_handle, crc->cmdq_reg->subsys,
+				crc->cmdq_reg->offset + crc->ofs[i],
+				CMDQ_THR_SPR_IDX1);
+
+		/* copy spr1 register to physical address of the crc */
+		cmdq_pkt_assign(&crc->cmdq_handle, CMDQ_THR_SPR_IDX0,
+				CMDQ_ADDR_HIGH(crc->pa + i * sizeof(*crc->va)));
+		cmdq_pkt_write_s(&crc->cmdq_handle, CMDQ_THR_SPR_IDX0,
+				 CMDQ_ADDR_LOW(crc->pa + i * sizeof(*crc->va)),
+				 CMDQ_THR_SPR_IDX1);
+	}
+	/* reset crc */
+	mtk_ddp_write_mask(&crc->cmdq_handle, ~0, crc->cmdq_reg, 0,
+			   crc->rst_ofs, crc->rst_msk);
+
+	/* clear reset bit */
+	mtk_ddp_write_mask(&crc->cmdq_handle, 0, crc->cmdq_reg, 0,
+			   crc->rst_ofs, crc->rst_msk);
+
+	/* jump to head of the cmdq packet */
+	cmdq_pkt_jump(&crc->cmdq_handle, crc->cmdq_handle.pa_base);
+
+	return;
+cleanup:
+	mtk_drm_crc_destroy(crc);
+}
+
+void mtk_drm_crc_cmdq_start(struct mtk_drm_crc *crc)
+{
+	if (!crc->cmdq_client.chan)
+		return;
+
+	dma_sync_single_for_device(crc->cmdq_client.chan->mbox->dev,
+				   crc->cmdq_handle.pa_base,
+				   crc->cmdq_handle.cmd_buf_size,
+				   DMA_TO_DEVICE);
+	mbox_send_message(crc->cmdq_client.chan, &crc->cmdq_handle);
+	mbox_client_txdone(crc->cmdq_client.chan, 0);
+}
+
+void mtk_drm_crc_cmdq_stop(struct mtk_drm_crc *crc)
+{
+	if (!crc->cmdq_client.chan)
+		return;
+
+	mbox_flush(crc->cmdq_client.chan, 2000);
+}
+#endif
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index 96790f8f7a94..3440c154ad1e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -15,6 +15,45 @@
 #define MTK_MAX_BPC	10
 #define MTK_MIN_BPC	3
 
+/**
+ * struct mtk_drm_crc - crc related information
+ * @ofs: register offset of crc
+ * @rst_ofs: register offset of crc reset
+ * @rst_msk: register mask of crc reset
+ * @cnt: count of crc
+ * @va: pointer to the start of crc array
+ * @pa: physical address of the crc for gce to access
+ * @cmdq_event: the event to trigger the cmdq
+ * @cmdq_reg: address of the register that cmdq is going to access
+ * @cmdq_client: handler to control cmdq (mbox channel, thread ...etc.)
+ * @cmdq_handle: cmdq packet to store the commands
+ */
+struct mtk_drm_crc {
+	const u32 *ofs;
+	u32 rst_ofs;
+	u32 rst_msk;
+	size_t cnt;
+	u32 *va;
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	dma_addr_t pa;
+	u32 cmdq_event;
+	struct cmdq_client_reg *cmdq_reg;
+	struct cmdq_client cmdq_client;
+	struct cmdq_pkt cmdq_handle;
+#endif
+};
+
+void mtk_drm_crc_init(struct mtk_drm_crc *crc,
+		      const u32 *crc_offset_table, size_t crc_count,
+		      u32 reset_offset, u32 reset_mask);
+void mtk_drm_crc_read(struct mtk_drm_crc *crc, void __iomem *reg);
+void mtk_drm_crc_destroy(struct mtk_drm_crc *crc);
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+void mtk_drm_crc_cmdq_create(struct device *dev, struct mtk_drm_crc *crc);
+void mtk_drm_crc_cmdq_start(struct mtk_drm_crc *crc);
+void mtk_drm_crc_cmdq_stop(struct mtk_drm_crc *crc);
+#endif
+
 void mtk_drm_crtc_commit(struct drm_crtc *crtc);
 int mtk_drm_crtc_create(struct drm_device *drm_dev,
 			const unsigned int *path,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 2597dd7ac0d2..38d08796fae4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -84,6 +84,9 @@ struct mtk_ddp_comp_funcs {
 	void (*add)(struct device *dev, struct mtk_mutex *mutex);
 	void (*remove)(struct device *dev, struct mtk_mutex *mutex);
 	int (*encoder_index)(struct device *dev);
+	size_t (*crc_cnt)(struct device *dev);
+	u32 *(*crc_entry)(struct device *dev);
+	void (*crc_read)(struct device *dev);
 };
 
 struct mtk_ddp_comp {
-- 
2.18.0



From retpolanne at posteo.net  Tue Dec 12 04:28:30 2023
From: retpolanne at posteo.net (Anne Macedo)
Date: Tue, 12 Dec 2023 12:28:30 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
Message-ID: <20231212122835.10850-2-retpolanne@posteo.net>

Adds compatible values to mdio subnodes for Ethernet PHY representing
Realtek 8211 PHY to Orange Pi One Plus.

Signed-off-by: Anne Macedo <retpolanne at posteo.net>
---
 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
index 29a081e72..7248ab72f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
@@ -37,7 +37,8 @@ &emac {
 
 &mdio {
 	ext_rgmii_phy: ethernet-phy at 1 {
-		compatible = "ethernet-phy-ieee802.3-c22";
+		compatible = "ethernet-phy-id001c.c915",
+			     "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
 	};
 };
-- 
2.43.0



From will at kernel.org  Tue Dec 12 04:29:55 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 12:29:55 +0000
Subject: [PATCH v4 1/4] arm64: fpsimd: Drop unneeded 'busy' flag
In-Reply-To: <CAMuHMdWewWJ1msJTcPNcbAf296gt+Kait3ECXjsJrSN+uerWyA@mail.gmail.com>
References: <20231208113218.3001940-6-ardb@google.com>
 <20231208113218.3001940-7-ardb@google.com>
 <CAMuHMdWewWJ1msJTcPNcbAf296gt+Kait3ECXjsJrSN+uerWyA@mail.gmail.com>
Message-ID: <20231212122955.GA29310@willie-the-truck>

Hi Geert,

Cheers for the report.

On Tue, Dec 12, 2023 at 12:27:50PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 8, 2023 at 12:34?PM Ard Biesheuvel <ardb at google.com> wrote:
> > From: Ard Biesheuvel <ardb at kernel.org>
> > Kernel mode NEON will preserve the user mode FPSIMD state by saving it
> > into the task struct before clobbering the registers. In order to avoid
> > the need for preserving kernel mode state too, we disallow nested use of
> > kernel mode NEON, i..e, use in softirq context while the interrupted
> > task context was using kernel mode NEON too.
> >
> > Originally, this policy was implemented using a per-CPU flag which was
> > exposed via may_use_simd(), requiring the users of the kernel mode NEON
> > to deal with the possibility that it might return false, and having NEON
> > and non-NEON code paths. This policy was changed by commit
> > 13150149aa6ded1 ("arm64: fpsimd: run kernel mode NEON with softirqs
> > disabled"), and now, softirq processing is disabled entirely instead,
> > and so may_use_simd() can never fail when called from task or softirq
> > context.
> >
> > This means we can drop the fpsimd_context_busy flag entirely, and
> > instead, ensure that we disable softirq processing in places where we
> > formerly relied on the flag for preventing races in the FPSIMD preserve
> > routines.
> >
> > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > Reviewed-by: Mark Brown <broonie at kernel.org>
> 
> Thanks for your patch, which is now commit e109130b0e5ec3fd
> ("arm64: fpsimd: Drop unneeded 'busy' flag") in arm64/for-next/core
> and next-20231212.
> 
> I have bisected the following warning during boot (on Salvator-XS with
> R-Car H3 ES2.0 and on White-Hawk with R-Car V4H) followed by a lock-up
> (on Salvator-XS) to this commit:

Please can you provide the output from the warning and, if possible, a
pointer to your .config?

Cheers,

Will


From shawn.sung at mediatek.com  Tue Dec 12 04:19:40 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:40 +0800
Subject: [PATCH v4 00/17] Support IGT in display driver
Message-ID: <20231212121957.19231-1-shawn.sung@mediatek.com>

This series is based on mediatek-drm-next.

This series adds support for running IGT (Intel GPU Tool) tests
with MediaTek display driver. The following changes will be
applied:

1. Add a new API for creating GCE thread loop to retrieve CRCs
   from the hardware component
2. Support hardware CRC calculation in both VDOSYS0 and VDOSYS1
3. Support alpha blending in both VDOSYS0 and VDOSYS1

Changes in v4:
- Seperate the patch into smaller ones
- Change the title of some patches
- Revert the changes that are not related to the series

Changes in v3:
- Modify the dt-binding document of Mediatek OVL
- Set DRM mode configs accroding to the hardware capabilities
- Replace cmdq_pkt_jump_absolute() with cmdq_pkt_jump()

Changes in v2:
- Simplify CMDQ by adding commands that are currently used only
- Integrate CRC related codes into new APIs for Mixer and OVL to reuse
- Add CPU version CRC retrieval when CMDQ is disabled

Hsiao Chien Sung (17):
  soc: mediatek: Add register definitions for GCE
  soc: mediatek: Disable 9-bit alpha in ETHDR
  dt-bindings: display: mediatek: ovl: Modify rules for MT8195/MT8188
  drm/mediatek: Add OVL compatible name for MT8195
  drm/mediatek: Set DRM mode configs accordingly
  drm/mediatek: Support alpha blending in OVL
  drm/mediatek: Support alpha blending in Mixer
  drm/mediatek: Support alpha blending in display driver
  drm/mediatek: Support CSC in OVL
  drm/mediatek: Support more color formats in OVL
  drm/mediatek: Turn off the layers with zero width or height
  drm/mediatek: Support CRC in display driver
  drm/mediatek: Support CRC in OVL
  drm/mediatek: Support CRC in OVL adaptor
  drm/mediatek: Add missing plane settings when async update
  drm/mediatek: Fix errors when reporting rotation capability
  drm/mediatek: Add comments for the structures

 .../display/mediatek/mediatek,ovl.yaml        |  12 +-
 drivers/gpu/drm/mediatek/mtk_disp_drv.h       |   7 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c       | 326 +++++++++++++++---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   |  32 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c       | 261 +++++++++++++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h       |  39 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |   7 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   |  35 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c        |  30 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h        |  16 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.c      |  15 +-
 drivers/gpu/drm/mediatek/mtk_ethdr.c          | 106 +++++-
 drivers/gpu/drm/mediatek/mtk_ethdr.h          |   5 +
 drivers/soc/mediatek/mtk-mmsys.c              |   1 +
 include/linux/soc/mediatek/mtk-cmdq.h         |  10 +
 15 files changed, 834 insertions(+), 68 deletions(-)

--
2.18.0



From zhourui at huaqin.corp-partner.google.com  Tue Dec 12 04:30:47 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Tue, 12 Dec 2023 20:30:47 +0800
Subject: [v9 1/4] ASoC: dt-bindings: mt8188-mt6359: add es8326 support
In-Reply-To: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
References: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
Message-ID: <20231212123050.4080083-2-zhourui@huaqin.corp-partner.google.com>

Add compatible string "mediatek,mt8188-es8326" to support new board
with es8326 codec.

Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Rui Zhou <zhourui at huaqin.corp-partner.google.com>
---
 .../devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml        | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
index 4c8c95057ef7..f94ad0715e32 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
@@ -15,6 +15,7 @@ allOf:
 properties:
   compatible:
     enum:
+      - mediatek,mt8188-es8326
       - mediatek,mt8188-mt6359-evb
       - mediatek,mt8188-nau8825
       - mediatek,mt8188-rt5682s
-- 
2.25.1



From zhourui at huaqin.corp-partner.google.com  Tue Dec 12 04:30:48 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Tue, 12 Dec 2023 20:30:48 +0800
Subject: [v9 2/4] ASoC: mediatek: mt8188-mt6359: commonize headset codec init/exit api
In-Reply-To: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
References: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
Message-ID: <20231212123050.4080083-3-zhourui@huaqin.corp-partner.google.com>

Reduce code duplication, unify the headset codec init/exit api.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Rui Zhou <zhourui at huaqin.corp-partner.google.com>
---
 sound/soc/mediatek/mt8188/mt8188-mt6359.c | 67 ++---------------------
 1 file changed, 6 insertions(+), 61 deletions(-)

diff --git a/sound/soc/mediatek/mt8188/mt8188-mt6359.c b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
index 33d477cc2e54..b4606a28794c 100644
--- a/sound/soc/mediatek/mt8188/mt8188-mt6359.c
+++ b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
@@ -726,7 +726,7 @@ static int mt8188_max98390_codec_init(struct snd_soc_pcm_runtime *rtd)
 	return 0;
 }
 
-static int mt8188_nau8825_codec_init(struct snd_soc_pcm_runtime *rtd)
+static int mt8188_headset_codec_init(struct snd_soc_pcm_runtime *rtd)
 {
 	struct snd_soc_card *card = rtd->card;
 	struct mtk_soc_card_data *soc_card_data = snd_soc_card_get_drvdata(card);
@@ -775,68 +775,13 @@ static int mt8188_nau8825_codec_init(struct snd_soc_pcm_runtime *rtd)
 	return 0;
 };
 
-static int mt8188_rt5682s_codec_init(struct snd_soc_pcm_runtime *rtd)
-{
-	struct snd_soc_card *card = rtd->card;
-	struct mtk_soc_card_data *soc_card_data = snd_soc_card_get_drvdata(card);
-	struct mt8188_mt6359_priv *priv = soc_card_data->mach_priv;
-	struct snd_soc_component *component = snd_soc_rtd_to_codec(rtd, 0)->component;
-	struct snd_soc_jack *jack = &priv->headset_jack;
-	int ret;
-
-	ret = snd_soc_dapm_new_controls(&card->dapm, mt8188_nau8825_widgets,
-					ARRAY_SIZE(mt8188_nau8825_widgets));
-	if (ret) {
-		dev_err(rtd->dev, "unable to add rt5682s card widget, ret %d\n", ret);
-		return ret;
-	}
-
-	ret = snd_soc_add_card_controls(card, mt8188_nau8825_controls,
-					ARRAY_SIZE(mt8188_nau8825_controls));
-	if (ret) {
-		dev_err(rtd->dev, "unable to add rt5682s card controls, ret %d\n", ret);
-		return ret;
-	}
-
-	ret = snd_soc_card_jack_new_pins(rtd->card, "Headset Jack",
-					 SND_JACK_HEADSET | SND_JACK_BTN_0 |
-					 SND_JACK_BTN_1 | SND_JACK_BTN_2 |
-					 SND_JACK_BTN_3,
-					 jack,
-					 nau8825_jack_pins,
-					 ARRAY_SIZE(nau8825_jack_pins));
-	if (ret) {
-		dev_err(rtd->dev, "Headset Jack creation failed: %d\n", ret);
-		return ret;
-	}
-
-	snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
-	snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
-	snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
-	snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);
-	ret = snd_soc_component_set_jack(component, jack, NULL);
-
-	if (ret) {
-		dev_err(rtd->dev, "Headset Jack call-back failed: %d\n", ret);
-		return ret;
-	}
-
-	return 0;
-};
-
-static void mt8188_nau8825_codec_exit(struct snd_soc_pcm_runtime *rtd)
+static void mt8188_headset_codec_exit(struct snd_soc_pcm_runtime *rtd)
 {
 	struct snd_soc_component *component = snd_soc_rtd_to_codec(rtd, 0)->component;
 
 	snd_soc_component_set_jack(component, NULL, NULL);
 }
 
-static void mt8188_rt5682s_codec_exit(struct snd_soc_pcm_runtime *rtd)
-{
-	struct snd_soc_component *component = snd_soc_rtd_to_codec(rtd, 0)->component;
-
-	snd_soc_component_set_jack(component, NULL, NULL);
-}
 
 static int mt8188_nau8825_hw_params(struct snd_pcm_substream *substream,
 				    struct snd_pcm_hw_params *params)
@@ -1407,15 +1352,15 @@ static int mt8188_mt6359_dev_probe(struct platform_device *pdev)
 			} else if (!strcmp(dai_link->codecs->dai_name, NAU8825_CODEC_DAI)) {
 				dai_link->ops = &mt8188_nau8825_ops;
 				if (!init_nau8825) {
-					dai_link->init = mt8188_nau8825_codec_init;
-					dai_link->exit = mt8188_nau8825_codec_exit;
+					dai_link->init = mt8188_headset_codec_init;
+					dai_link->exit = mt8188_headset_codec_exit;
 					init_nau8825 = true;
 				}
 			} else if (!strcmp(dai_link->codecs->dai_name, RT5682S_CODEC_DAI)) {
 				dai_link->ops = &mt8188_rt5682s_i2s_ops;
 				if (!init_rt5682s) {
-					dai_link->init = mt8188_rt5682s_codec_init;
-					dai_link->exit = mt8188_rt5682s_codec_exit;
+					dai_link->init = mt8188_headset_codec_init;
+					dai_link->exit = mt8188_headset_codec_exit;
 					init_rt5682s = true;
 				}
 			} else {
-- 
2.25.1



From zhourui at huaqin.corp-partner.google.com  Tue Dec 12 04:30:50 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Tue, 12 Dec 2023 20:30:50 +0800
Subject: [v9 4/4] ASoC: mediatek: mt8188-mt6359: Enable dual amp for mt8188-rt5682s
In-Reply-To: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
References: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
Message-ID: <20231212123050.4080083-5-zhourui@huaqin.corp-partner.google.com>

Enable support for dual MAX98390 amplifiers on the mt8188-rt5682s board.

Reviewed-by: Trevor Wu <trevor.wu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Rui Zhou <zhourui at huaqin.corp-partner.google.com>
---
 sound/soc/mediatek/mt8188/mt8188-mt6359.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/mediatek/mt8188/mt8188-mt6359.c b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
index d1884f23a1a7..a391066ab204 100644
--- a/sound/soc/mediatek/mt8188/mt8188-mt6359.c
+++ b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
@@ -1448,7 +1448,7 @@ static struct mt8188_card_data mt8188_nau8825_card = {
 
 static struct mt8188_card_data mt8188_rt5682s_card = {
 	.name = "mt8188_rt5682s",
-	.quirk = RT5682S_HS_PRESENT,
+	.quirk = RT5682S_HS_PRESENT | MAX98390_TWO_AMP,
 };
 
 static struct mt8188_card_data mt8188_es8326_card = {
-- 
2.25.1



From zhourui at huaqin.corp-partner.google.com  Tue Dec 12 04:30:46 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Tue, 12 Dec 2023 20:30:46 +0800
Subject: [v9 0/4] add es8326 dt-bindings, commonize headset codec API, es8326 support and Enable dual amp for rt5682s
Message-ID: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>

Add dt-bindings for es8326 and codec es8326 support. 
Remove duplicate code, commonize headset codec init/exit API.
At the same time, Enable dual amp max98390 for rt5682s.

Changes in v9:
- PATCH 3/4: Add comment for MAX98390_TWO_AMP.
- Link to v8: https://lore.kernel.org/all/20231208070933.720324-1-zhourui at huaqin.corp-partner.google.com/

Changes in v8:
- PATCH 3/4: Change the #define ES8326_CODEC_DAI macro definition and filter the es8326 widget
- Link to v7: https://lore.kernel.org/all/20231116093512.4180240-1-zhourui at huaqin.corp-partner.google.com/

Changes in v7:
- PATCH 3/4: Completion "}"
- Link to v6: https://lore.kernel.org/all/20231116073106.3757618-1-zhourui at huaqin.corp-partner.google.com/

Changes in v6:
- PATCH 2/4: add a patch, commonize headset codec init/exit API
- PATCH 3/4: Remove generalized code
- Link to v5: https://lore.kernel.org/all/20231115090903.578438-1-zhourui at huaqin.corp-partner.google.com/

Changes in v5:
- PATCH 2/3: Change the names of some apis
- Link to v4: https://lore.kernel.org/all/20231115085329.541764-1-zhourui at huaqin.corp-partner.google.com/

Changes in v4:
- PATCH 2/3: Change the names of some apis
- PATCH 3/3: Change commit description
- Link to v3: https://lore.kernel.org/all/20231108063804.592982-1-zhourui at huaqin.corp-partner.google.com/

Changes in v3:
- PATCH 3/3: Change theme description
- Link to v2: https://lore.kernel.org/all/20231108012617.3973539-1-zhourui at huaqin.corp-partner.google.com/

Changes in v2:
- PATCH 1/3: Change ES8326 location in bindings
- PATCH 3/3: Change theme description
- Link to v1: https://lore.kernel.org/all/20231107031442.2768765-1-zhourui at huaqin.corp-partner.google.com/

Rui Zhou (4):
  ASoC: dt-bindings: mt8188-mt6359: add es8326 support
  ASoC: mediatek: mt8188-mt6359: commonize headset codec init/exit api
  ASoC: mediatek: mt8188-mt6359: add es8326 support
  ASoC: mediatek: mt8188-mt6359: Enable dual amp for mt8188-rt5682s

 .../sound/mediatek,mt8188-mt6359.yaml         |   1 +
 sound/soc/mediatek/Kconfig                    |   1 +
 sound/soc/mediatek/mt8188/mt8188-mt6359.c     | 125 +++++++++---------
 3 files changed, 63 insertions(+), 64 deletions(-)

-- 
2.25.1



From zhourui at huaqin.corp-partner.google.com  Tue Dec 12 04:30:49 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Tue, 12 Dec 2023 20:30:49 +0800
Subject: [v9 3/4] ASoC: mediatek: mt8188-mt6359: add es8326 support
In-Reply-To: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
References: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
Message-ID: <20231212123050.4080083-4-zhourui@huaqin.corp-partner.google.com>

To use ES8326 as the codec, add a new sound card
named mt8186_es8326.

Reviewed-by: Trevor Wu <trevor.wu at mediatek.com>
Signed-off-by: Rui Zhou <zhourui at huaqin.corp-partner.google.com>
---
 sound/soc/mediatek/Kconfig                |  1 +
 sound/soc/mediatek/mt8188/mt8188-mt6359.c | 56 ++++++++++++++++++++++-
 2 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig
index b93d455744ab..296b434caf81 100644
--- a/sound/soc/mediatek/Kconfig
+++ b/sound/soc/mediatek/Kconfig
@@ -252,6 +252,7 @@ config SND_SOC_MT8188_MT6359
 	select SND_SOC_NAU8315
 	select SND_SOC_NAU8825
 	select SND_SOC_RT5682S
+	select SND_SOC_ES8326
 	help
 	  This adds support for ASoC machine driver for MediaTek MT8188
 	  boards with the MT6359 and other I2S audio codecs.
diff --git a/sound/soc/mediatek/mt8188/mt8188-mt6359.c b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
index b4606a28794c..d1884f23a1a7 100644
--- a/sound/soc/mediatek/mt8188/mt8188-mt6359.c
+++ b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
@@ -34,6 +34,8 @@
 
 #define NAU8825_HS_PRESENT	BIT(0)
 #define RT5682S_HS_PRESENT	BIT(1)
+#define ES8326_HS_PRESENT	BIT(2)
+#define MAX98390_TWO_AMP	BIT(3)
 /*
  * Maxim MAX98390
  */
@@ -48,6 +50,11 @@
  */
 #define NAU8825_CODEC_DAI  "nau8825-hifi"
 
+/*
+ * ES8326
+ */
+#define ES8326_CODEC_DAI  "ES8326 HiFi"
+
 #define SOF_DMA_DL2 "SOF_DMA_DL2"
 #define SOF_DMA_DL3 "SOF_DMA_DL3"
 #define SOF_DMA_UL4 "SOF_DMA_UL4"
@@ -888,6 +895,30 @@ static const struct snd_soc_ops mt8188_sof_be_ops = {
 	.hw_params = mt8188_sof_be_hw_params,
 };
 
+static int mt8188_es8326_hw_params(struct snd_pcm_substream *substream,
+				 struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_pcm_runtime *rtd = snd_soc_substream_to_rtd(substream);
+	struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
+	struct snd_soc_dai *codec_dai = snd_soc_rtd_to_codec(rtd, 0);
+	unsigned int rate = params_rate(params);
+	int ret;
+
+	/* Configure MCLK for codec */
+	ret = snd_soc_dai_set_sysclk(codec_dai, 0, rate * 256, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		dev_err(codec_dai->dev, "can't set MCLK %d\n", ret);
+		return ret;
+	}
+
+	/* Configure MCLK for cpu */
+	return snd_soc_dai_set_sysclk(cpu_dai, 0, rate * 256, SND_SOC_CLOCK_OUT);
+}
+
+static const struct snd_soc_ops mt8188_es8326_ops = {
+	.hw_params = mt8188_es8326_hw_params,
+};
+
 static struct snd_soc_dai_link mt8188_mt6359_dai_links[] = {
 	/* FE */
 	[DAI_LINK_DL2_FE] = {
@@ -1197,7 +1228,7 @@ static void mt8188_fixup_controls(struct snd_soc_card *card)
 	struct mt8188_card_data *card_data = (struct mt8188_card_data *)priv->private_data;
 	struct snd_kcontrol *kctl;
 
-	if (card_data->quirk & (NAU8825_HS_PRESENT | RT5682S_HS_PRESENT)) {
+	if (card_data->quirk & (NAU8825_HS_PRESENT | RT5682S_HS_PRESENT | ES8326_HS_PRESENT)) {
 		struct snd_soc_dapm_widget *w, *next_w;
 
 		for_each_card_widgets_safe(card, w, next_w) {
@@ -1238,6 +1269,7 @@ static int mt8188_mt6359_dev_probe(struct platform_device *pdev)
 	struct mt8188_card_data *card_data;
 	struct snd_soc_dai_link *dai_link;
 	bool init_mt6359 = false;
+	bool init_es8326 = false;
 	bool init_nau8825 = false;
 	bool init_rt5682s = false;
 	bool init_max98390 = false;
@@ -1344,7 +1376,14 @@ static int mt8188_mt6359_dev_probe(struct platform_device *pdev)
 			   strcmp(dai_link->name, "ETDM1_IN_BE") == 0 ||
 			   strcmp(dai_link->name, "ETDM2_IN_BE") == 0) {
 			if (!strcmp(dai_link->codecs->dai_name, MAX98390_CODEC_DAI)) {
-				dai_link->ops = &mt8188_max98390_ops;
+				/*
+				 * The TDM protocol settings with fixed 4 slots are defined in
+				 * mt8188_max98390_ops. Two amps is I2S mode,
+				 * SOC and codec don't require TDM settings.
+				 */
+				if (!(card_data->quirk & MAX98390_TWO_AMP)) {
+					dai_link->ops = &mt8188_max98390_ops;
+				}
 				if (!init_max98390) {
 					dai_link->init = mt8188_max98390_codec_init;
 					init_max98390 = true;
@@ -1363,6 +1402,13 @@ static int mt8188_mt6359_dev_probe(struct platform_device *pdev)
 					dai_link->exit = mt8188_headset_codec_exit;
 					init_rt5682s = true;
 				}
+			} else if (!strcmp(dai_link->codecs->dai_name, ES8326_CODEC_DAI)) {
+				dai_link->ops = &mt8188_es8326_ops;
+				if (!init_es8326) {
+					dai_link->init = mt8188_headset_codec_init;
+					dai_link->exit = mt8188_headset_codec_exit;
+					init_es8326 = true;
+				}
 			} else {
 				if (strcmp(dai_link->codecs->dai_name, "snd-soc-dummy-dai")) {
 					if (!init_dumb) {
@@ -1405,10 +1451,16 @@ static struct mt8188_card_data mt8188_rt5682s_card = {
 	.quirk = RT5682S_HS_PRESENT,
 };
 
+static struct mt8188_card_data mt8188_es8326_card = {
+	.name = "mt8188_es8326",
+	.quirk = ES8326_HS_PRESENT | MAX98390_TWO_AMP,
+};
+
 static const struct of_device_id mt8188_mt6359_dt_match[] = {
 	{ .compatible = "mediatek,mt8188-mt6359-evb", .data = &mt8188_evb_card, },
 	{ .compatible = "mediatek,mt8188-nau8825", .data = &mt8188_nau8825_card, },
 	{ .compatible = "mediatek,mt8188-rt5682s", .data = &mt8188_rt5682s_card, },
+	{ .compatible = "mediatek,mt8188-es8326", .data = &mt8188_es8326_card, },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, mt8188_mt6359_dt_match);
-- 
2.25.1



From geert at linux-m68k.org  Tue Dec 12 04:34:37 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 12 Dec 2023 13:34:37 +0100
Subject: [PATCH v4 1/4] arm64: fpsimd: Drop unneeded 'busy' flag
In-Reply-To: <20231212122955.GA29310@willie-the-truck>
References: <20231208113218.3001940-6-ardb@google.com> <20231208113218.3001940-7-ardb@google.com>
 <CAMuHMdWewWJ1msJTcPNcbAf296gt+Kait3ECXjsJrSN+uerWyA@mail.gmail.com> <20231212122955.GA29310@willie-the-truck>
Message-ID: <CAMuHMdVnqSpFUvT4wb4D=sHgBzQvhv_dWxn59scgUawoRAatNg@mail.gmail.com>

Hi Will,

On Tue, Dec 12, 2023 at 1:30?PM Will Deacon <will at kernel.org> wrote:
> On Tue, Dec 12, 2023 at 12:27:50PM +0100, Geert Uytterhoeven wrote:
> > On Fri, Dec 8, 2023 at 12:34?PM Ard Biesheuvel <ardb at google.com> wrote:
> > > From: Ard Biesheuvel <ardb at kernel.org>
> > > Kernel mode NEON will preserve the user mode FPSIMD state by saving it
> > > into the task struct before clobbering the registers. In order to avoid
> > > the need for preserving kernel mode state too, we disallow nested use of
> > > kernel mode NEON, i..e, use in softirq context while the interrupted
> > > task context was using kernel mode NEON too.
> > >
> > > Originally, this policy was implemented using a per-CPU flag which was
> > > exposed via may_use_simd(), requiring the users of the kernel mode NEON
> > > to deal with the possibility that it might return false, and having NEON
> > > and non-NEON code paths. This policy was changed by commit
> > > 13150149aa6ded1 ("arm64: fpsimd: run kernel mode NEON with softirqs
> > > disabled"), and now, softirq processing is disabled entirely instead,
> > > and so may_use_simd() can never fail when called from task or softirq
> > > context.
> > >
> > > This means we can drop the fpsimd_context_busy flag entirely, and
> > > instead, ensure that we disable softirq processing in places where we
> > > formerly relied on the flag for preventing races in the FPSIMD preserve
> > > routines.
> > >
> > > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > > Reviewed-by: Mark Brown <broonie at kernel.org>
> >
> > Thanks for your patch, which is now commit e109130b0e5ec3fd
> > ("arm64: fpsimd: Drop unneeded 'busy' flag") in arm64/for-next/core
> > and next-20231212.
> >
> > I have bisected the following warning during boot (on Salvator-XS with
> > R-Car H3 ES2.0 and on White-Hawk with R-Car V4H) followed by a lock-up
> > (on Salvator-XS) to this commit:
>
> Please can you provide the output from the warning and, if possible, a

Oops, how did that log disappear?

------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/softirq.c:361 __local_bh_enable_ip+0x1a4/0x1c8
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.7.0-rc3-arm64-renesas-00001-ge109130b0e5e #2383
Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __local_bh_enable_ip+0x1a4/0x1c8
lr : fpsimd_save_and_flush_cpu_state+0x4c/0x58
sp : ffff800081703bb0
x29: ffff800081703bb0 x28: ffff80008171c6b0 x27: ffff8000800167fc
x26: 0000000000000000 x25: 0000000000000000 x24: ffff800081710a68
x23: ffff8000813c4008 x22: ffff800081703ca4 x21: 0000000000000000
x20: ffff8000800167c8 x19: 0000000000000200 x18: ffffffffffffffff
x17: ffff0004c27f2400 x16: 0000000000000001 x15: 0000000000000003
x14: 0000000000000000 x13: 0000000000000003 x12: 0000000000000000
x11: 071c71c71c71c71c x10: ffff800082086b88 x9 : 0000000000000000
x8 : ffff80008203ab50 x7 : 0000000000000bb0 x6 : ffff80008203b700
x5 : ffff80067e2ee000 x4 : 0000000000000202 x3 : ffff80067e2ee000
x2 : ffff80067e2ee000 x1 : ffff800081719fc0 x0 : 0000000100000202
Call trace:
 __local_bh_enable_ip+0x1a4/0x1c8
 fpsimd_save_and_flush_cpu_state+0x4c/0x58
 fpsimd_cpu_pm_notifier+0x1c/0x28
 notifier_call_chain+0x9c/0x174
 raw_notifier_call_chain_robust+0x40/0x98
 cpu_pm_enter+0x3c/0x70
 psci_enter_idle_state+0x28/0x78
 cpuidle_enter_state+0xe4/0x568
 cpuidle_enter+0x34/0x48
 do_idle+0x214/0x290
 cpu_startup_entry+0x34/0x38
 rest_init+0xf8/0x188
 arch_post_acpi_subsys_init+0x0/0x8
 start_kernel+0x4fc/0x5ec
 __primary_switched+0xb4/0xbc
irq event stamp: 15351
hardirqs last  enabled at (15349): [<ffff80008015d9bc>]
tick_nohz_idle_enter+0xcc/0x198
hardirqs last disabled at (15350): [<ffff8000800e27a8>] do_idle+0xc4/0x290
softirqs last  enabled at (15330): [<ffff800080010614>] __do_softirq+0x494/0x4dc
softirqs last disabled at (15351): [<ffff8000800167c8>]
fpsimd_save_and_flush_cpu_state+0x24/0x58
---[ end trace 0000000000000000 ]---

> pointer to your .config?

renesas-defconfig from
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git/log/?h=topic/renesas-defconfig

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From michael at walle.cc  Tue Dec 12 04:34:51 2023
From: michael at walle.cc (Michael Walle)
Date: Tue, 12 Dec 2023 13:34:51 +0100
Subject: [PATCH v11 00/10] spi: Add support for stacked/parallel memories
In-Reply-To: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
Message-ID: <30ffd8378d3ef1c4fa6dfe4324b18345@walle.cc>

> This patch series updated the spi-nor, spi core and the AMD-Xilinx 
> GQSPI
> driver to add stacked and parallel memories support.

Honestly, I'm not thrilled about how this is implemented in the core
and what the restrictions are.
First, the pattern "if (n==1) then { old behavior } else { copy old
code modify for n==2 }" is hard to maintain. There should be no copy
and the old code shall be adapted to work for both n=1 and n>1.

But I agree with Tudor, some kind of abstraction (layer) would be nice.

Also, you hardcode n=2 everywhere. Please generalize that one.

Are you aware of any other controller supporting such a feature? I've
seen you also need to modify the spi controller and intercept some
commands. Can everything be moved there?

I'm not sure we are implementing controller specific things in the
core. Hard to judge without seeing other controllers doing a similar
thing. I'd like to avoid that.

If we had some kind of abstraction here, that might be easier to adapt
in the future, but just putting everything into the core will make it
really hard to maintain. So if everything related to stacked and
parallel memory would be in drivers/mtd/spi-nor/stacked.c, we'd have
at least everything in one place with a proper interface between
that and the core.

-michael


From shawn.sung at mediatek.com  Tue Dec 12 04:19:46 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:46 +0800
Subject: [PATCH v4 06/17] drm/mediatek: Support alpha blending in OVL
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-7-shawn.sung@mediatek.com>

Support premultiply and coverage alpha blending in
Overlay.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 73 +++++++++++++++++--------
 1 file changed, 51 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 5aaf4342cdbd..66074c2d917c 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -39,6 +39,7 @@
 #define DISP_REG_OVL_PITCH_MSB(n)		(0x0040 + 0x20 * (n))
 #define OVL_PITCH_MSB_2ND_SUBBUF			BIT(16)
 #define DISP_REG_OVL_PITCH(n)			(0x0044 + 0x20 * (n))
+#define OVL_CONST_BLEND					BIT(28)
 #define DISP_REG_OVL_RDMA_CTRL(n)		(0x00c0 + 0x20 * (n))
 #define DISP_REG_OVL_RDMA_GMC(n)		(0x00c8 + 0x20 * (n))
 #define DISP_REG_OVL_ADDR_MT2701		0x0040
@@ -52,13 +53,16 @@
 #define GMC_THRESHOLD_HIGH	((1 << GMC_THRESHOLD_BITS) / 4)
 #define GMC_THRESHOLD_LOW	((1 << GMC_THRESHOLD_BITS) / 8)
 
-#define OVL_CON_BYTE_SWAP	BIT(24)
-#define OVL_CON_MTX_YUV_TO_RGB	(6 << 16)
-#define OVL_CON_CLRFMT_RGB	(1 << 12)
-#define OVL_CON_CLRFMT_RGBA8888	(2 << 12)
-#define OVL_CON_CLRFMT_ARGB8888	(3 << 12)
-#define OVL_CON_CLRFMT_UYVY	(4 << 12)
-#define OVL_CON_CLRFMT_YUYV	(5 << 12)
+#define OVL_CON_CLRFMT_MAN		BIT(23)
+#define OVL_CON_BYTE_SWAP		BIT(24)
+#define OVL_CON_RGB_SWAP		BIT(25)
+#define OVL_CON_CLRFMT_RGB		(1 << 12)
+#define OVL_CON_CLRFMT_RGBA8888		(2 << 12)
+#define OVL_CON_CLRFMT_ARGB8888		(3 << 12)
+#define OVL_CON_CLRFMT_PARGB8888	(OVL_CON_CLRFMT_ARGB8888 | OVL_CON_CLRFMT_MAN)
+#define OVL_CON_CLRFMT_UYVY		(4 << 12)
+#define OVL_CON_CLRFMT_YUYV		(5 << 12)
+#define OVL_CON_MTX_YUV_TO_RGB		(6 << 16)
 #define OVL_CON_CLRFMT_RGB565(ovl)	((ovl)->data->fmt_rgb565_is_0 ? \
 					0 : OVL_CON_CLRFMT_RGB)
 #define OVL_CON_CLRFMT_RGB888(ovl)	((ovl)->data->fmt_rgb565_is_0 ? \
@@ -208,14 +212,12 @@ void mtk_ovl_clk_disable(struct device *dev)
 void mtk_ovl_start(struct device *dev)
 {
 	struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+	unsigned int reg = readl(ovl->regs + DISP_REG_OVL_DATAPATH_CON);
 
-	if (ovl->data->smi_id_en) {
-		unsigned int reg;
+	if (ovl->data->smi_id_en)
+		reg |= OVL_LAYER_SMI_ID_EN;
 
-		reg = readl(ovl->regs + DISP_REG_OVL_DATAPATH_CON);
-		reg = reg | OVL_LAYER_SMI_ID_EN;
-		writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
-	}
+	writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
 	writel_relaxed(0x1, ovl->regs + DISP_REG_OVL_EN);
 }
 
@@ -274,7 +276,13 @@ void mtk_ovl_config(struct device *dev, unsigned int w,
 	if (w != 0 && h != 0)
 		mtk_ddp_write_relaxed(cmdq_pkt, h << 16 | w, &ovl->cmdq_reg, ovl->regs,
 				      DISP_REG_OVL_ROI_SIZE);
-	mtk_ddp_write_relaxed(cmdq_pkt, 0x0, &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_ROI_BGCLR);
+
+	/*
+	 * The background color should be opaque black (ARGB),
+	 * otherwise there will be no effect with alpha blend
+	 */
+	mtk_ddp_write_relaxed(cmdq_pkt, 0xff000000, &ovl->cmdq_reg,
+			      ovl->regs, DISP_REG_OVL_ROI_BGCLR);
 
 	mtk_ddp_write(cmdq_pkt, 0x1, &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_RST);
 	mtk_ddp_write(cmdq_pkt, 0x0, &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_RST);
@@ -357,7 +365,8 @@ void mtk_ovl_layer_off(struct device *dev, unsigned int idx,
 		      DISP_REG_OVL_RDMA_CTRL(idx));
 }
 
-static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt)
+static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt,
+				    unsigned int blend_mode)
 {
 	/* The return value in switch "MEM_MODE_INPUT_FORMAT_XXX"
 	 * is defined in mediatek HW data sheet.
@@ -376,18 +385,30 @@ static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt)
 		return OVL_CON_CLRFMT_RGB888(ovl) | OVL_CON_BYTE_SWAP;
 	case DRM_FORMAT_RGBX8888:
 	case DRM_FORMAT_RGBA8888:
-		return OVL_CON_CLRFMT_ARGB8888;
+		return blend_mode == DRM_MODE_BLEND_COVERAGE ?
+		       OVL_CON_CLRFMT_ARGB8888 :
+		       OVL_CON_CLRFMT_PARGB8888;
 	case DRM_FORMAT_BGRX8888:
 	case DRM_FORMAT_BGRA8888:
+		return OVL_CON_BYTE_SWAP |
+		       (blend_mode == DRM_MODE_BLEND_COVERAGE ?
+		       OVL_CON_CLRFMT_ARGB8888 :
+		       OVL_CON_CLRFMT_PARGB8888);
 	case DRM_FORMAT_BGRA1010102:
 		return OVL_CON_CLRFMT_ARGB8888 | OVL_CON_BYTE_SWAP;
 	case DRM_FORMAT_XRGB8888:
 	case DRM_FORMAT_ARGB8888:
+		return blend_mode == DRM_MODE_BLEND_COVERAGE ?
+		       OVL_CON_CLRFMT_RGBA8888 :
+		       OVL_CON_CLRFMT_PARGB8888;
 	case DRM_FORMAT_ARGB2101010:
 		return OVL_CON_CLRFMT_RGBA8888;
 	case DRM_FORMAT_XBGR8888:
 	case DRM_FORMAT_ABGR8888:
-		return OVL_CON_CLRFMT_RGBA8888 | OVL_CON_BYTE_SWAP;
+		return OVL_CON_RGB_SWAP |
+		       (blend_mode == DRM_MODE_BLEND_COVERAGE ?
+		       OVL_CON_CLRFMT_RGBA8888 :
+		       OVL_CON_CLRFMT_PARGB8888);
 	case DRM_FORMAT_UYVY:
 		return OVL_CON_CLRFMT_UYVY | OVL_CON_MTX_YUV_TO_RGB;
 	case DRM_FORMAT_YUYV:
@@ -408,6 +429,8 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
 	unsigned int fmt = pending->format;
 	unsigned int offset = (pending->y << 16) | pending->x;
 	unsigned int src_size = (pending->height << 16) | pending->width;
+	unsigned int blend_mode = state->base.pixel_blend_mode;
+	unsigned int ignore_pixel_alpha = 0;
 	unsigned int con;
 	bool is_afbc = pending->modifier != DRM_FORMAT_MOD_LINEAR;
 	union overlay_pitch {
@@ -425,9 +448,15 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
 		return;
 	}
 
-	con = ovl_fmt_convert(ovl, fmt);
-	if (state->base.fb && state->base.fb->format->has_alpha)
-		con |= OVL_CON_AEN | OVL_CON_ALPHA;
+	con = ovl_fmt_convert(ovl, fmt, blend_mode);
+	if (state->base.fb) {
+		con |= OVL_CON_AEN;
+		con |= state->base.alpha & OVL_CON_ALPHA;
+	}
+
+	if (blend_mode == DRM_MODE_BLEND_PIXEL_NONE ||
+	    (state->base.fb && !state->base.fb->format->has_alpha))
+		ignore_pixel_alpha = OVL_CONST_BLEND;
 
 	if (pending->rotation & DRM_MODE_REFLECT_Y) {
 		con |= OVL_CON_VIRT_FLIP;
@@ -444,8 +473,8 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
 
 	mtk_ddp_write_relaxed(cmdq_pkt, con, &ovl->cmdq_reg, ovl->regs,
 			      DISP_REG_OVL_CON(idx));
-	mtk_ddp_write_relaxed(cmdq_pkt, overlay_pitch.split_pitch.lsb, &ovl->cmdq_reg, ovl->regs,
-			      DISP_REG_OVL_PITCH(idx));
+	mtk_ddp_write_relaxed(cmdq_pkt, overlay_pitch.split_pitch.lsb | ignore_pixel_alpha,
+			      &ovl->cmdq_reg, ovl->regs, DISP_REG_OVL_PITCH(idx));
 	mtk_ddp_write_relaxed(cmdq_pkt, src_size, &ovl->cmdq_reg, ovl->regs,
 			      DISP_REG_OVL_SRC_SIZE(idx));
 	mtk_ddp_write_relaxed(cmdq_pkt, offset, &ovl->cmdq_reg, ovl->regs,
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:45 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:45 +0800
Subject: [PATCH v4 05/17] drm/mediatek: Set DRM mode configs accordingly
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-6-shawn.sung@mediatek.com>

Set DRM mode configs limitation accroding to the
hardware capabilities.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 ++++++++++++++++++--------
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |  1 +
 2 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 5d551bff6b3f..a4b740420ebb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -304,6 +304,7 @@ static const struct mtk_mmsys_driver_data mt8188_vdosys0_driver_data = {
 	.conn_routes = mt8188_mtk_ddp_main_routes,
 	.conn_routes_num = ARRAY_SIZE(mt8188_mtk_ddp_main_routes),
 	.mmsys_dev_num = 2,
+	.max_pitch = GENMASK(15, 0),
 };
 
 static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
@@ -318,6 +319,7 @@ static const struct mtk_mmsys_driver_data mt8195_vdosys0_driver_data = {
 	.main_path = mt8195_mtk_ddp_main,
 	.main_len = ARRAY_SIZE(mt8195_mtk_ddp_main),
 	.mmsys_dev_num = 2,
+	.max_pitch = GENMASK(15, 0),
 };
 
 static const struct mtk_mmsys_driver_data mt8195_vdosys1_driver_data = {
@@ -325,6 +327,7 @@ static const struct mtk_mmsys_driver_data mt8195_vdosys1_driver_data = {
 	.ext_len = ARRAY_SIZE(mt8195_mtk_ddp_ext),
 	.mmsys_id = 1,
 	.mmsys_dev_num = 2,
+	.max_pitch = GENMASK(15, 0),
 };
 
 static const struct of_device_id mtk_drm_of_ids[] = {
@@ -463,16 +466,16 @@ static int mtk_drm_kms_init(struct drm_device *drm)
 	if (ret)
 		goto put_mutex_dev;
 
-	drm->mode_config.min_width = 64;
-	drm->mode_config.min_height = 64;
-
 	/*
-	 * set max width and height as default value(4096x4096).
-	 * this value would be used to check framebuffer size limitation
-	 * at drm_mode_addfb().
+	 * Set default values for drm mode config
+	 * these values will be referenced by drm_mode_addfb() as
+	 * frame buffer size limitation.
 	 */
-	drm->mode_config.max_width = 4096;
-	drm->mode_config.max_height = 4096;
+	drm->mode_config.min_width = 1;
+	drm->mode_config.min_height = 1;
+	drm->mode_config.cursor_width = 512;
+	drm->mode_config.cursor_height = 512;
+
 	drm->mode_config.funcs = &mtk_drm_mode_config_funcs;
 	drm->mode_config.helper_private = &mtk_drm_mode_config_helpers;
 
@@ -502,6 +505,15 @@ static int mtk_drm_kms_init(struct drm_device *drm)
 		for (j = 0; j < private->data->mmsys_dev_num; j++) {
 			priv_n = private->all_drm_private[j];
 
+			if (priv_n->data->max_pitch) {
+				/* Save 4 bytes for the color depth (pitch = width x bpp) */
+				drm->mode_config.max_width  = priv_n->data->max_pitch >> 2;
+				drm->mode_config.max_height = priv_n->data->max_pitch >> 2;
+			} else {
+				drm->mode_config.max_width = 4096;
+				drm->mode_config.max_height = 4096;
+			}
+
 			if (i == 0 && priv_n->data->main_len) {
 				ret = mtk_drm_crtc_create(drm, priv_n->data->main_path,
 							  priv_n->data->main_len, j,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index d2efd715699f..3d6c1f58a7ec 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -41,6 +41,7 @@ struct mtk_mmsys_driver_data {
 	bool shadow_register;
 	unsigned int mmsys_id;
 	unsigned int mmsys_dev_num;
+	u32 max_pitch;
 };
 
 struct mtk_drm_private {
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:54 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:54 +0800
Subject: [PATCH v4 14/17] drm/mediatek: Support CRC in OVL adaptor
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-15-shawn.sung@mediatek.com>

We choose Mixer as CRC generator in OVL adaptor since
its frame done event will trigger vblanks, we can know
when is safe to retrieve CRC of the frame.

In OVL adaptor, there's no image procession after Mixer,
unlike the OVL in VDOSYS0, Mixer's CRC will include all
the effects that are applied to the frame.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h       |  3 +
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 21 +++++++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |  3 +
 drivers/gpu/drm/mediatek/mtk_ethdr.c          | 62 +++++++++++++++++++
 drivers/gpu/drm/mediatek/mtk_ethdr.h          |  5 ++
 5 files changed, 94 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 08cc2d2fef9f..4d6e8b667bc3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -133,6 +133,9 @@ unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
 struct device *mtk_ovl_adaptor_dma_dev_get(struct device *dev);
 const u32 *mtk_ovl_adaptor_get_formats(struct device *dev);
 size_t mtk_ovl_adaptor_get_num_formats(struct device *dev);
+size_t mtk_ovl_adaptor_crc_cnt(struct device *dev);
+u32 *mtk_ovl_adaptor_crc_entry(struct device *dev);
+void mtk_ovl_adaptor_crc_read(struct device *dev);
 
 void mtk_rdma_bypass_shadow(struct device *dev);
 int mtk_rdma_clk_enable(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 8789442c039f..4398db9a6276 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -205,6 +205,27 @@ void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
 	mtk_ethdr_layer_config(ethdr, idx, state, cmdq_pkt);
 }
 
+size_t mtk_ovl_adaptor_crc_cnt(struct device *dev)
+{
+	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+	return mtk_ethdr_crc_cnt(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+}
+
+u32 *mtk_ovl_adaptor_crc_entry(struct device *dev)
+{
+	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+	return mtk_ethdr_crc_entry(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+}
+
+void mtk_ovl_adaptor_crc_read(struct device *dev)
+{
+	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+	mtk_ethdr_crc_read(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+}
+
 void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
 			    unsigned int h, unsigned int vrefresh,
 			    unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 1118efcde98a..ffa4868b1222 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -404,6 +404,9 @@ static const struct mtk_ddp_comp_funcs ddp_ovl_adaptor = {
 	.clk_enable = mtk_ovl_adaptor_clk_enable,
 	.clk_disable = mtk_ovl_adaptor_clk_disable,
 	.config = mtk_ovl_adaptor_config,
+	.crc_cnt = mtk_ovl_adaptor_crc_cnt,
+	.crc_entry = mtk_ovl_adaptor_crc_entry,
+	.crc_read = mtk_ovl_adaptor_crc_read,
 	.start = mtk_ovl_adaptor_start,
 	.stop = mtk_ovl_adaptor_stop,
 	.layer_nr = mtk_ovl_adaptor_layer_nr,
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c b/drivers/gpu/drm/mediatek/mtk_ethdr.c
index e95331c06815..30eb2c3d95c0 100644
--- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
@@ -24,6 +24,9 @@
 #define MIX_FME_CPL_INTEN			BIT(1)
 #define MIX_INTSTA			0x8
 #define MIX_EN				0xc
+#define MIX_TRIG			0x10
+#define MIX_TRIG_CRC_EN				BIT(8)
+#define MIX_TRIG_CRC_RST			BIT(9)
 #define MIX_RST				0x14
 #define MIX_ROI_SIZE			0x18
 #define MIX_DATAPATH_CON		0x1c
@@ -39,6 +42,11 @@
 #define PREMULTI_SOURCE				(3 << 12)
 #define MIX_L_SRC_SIZE(n)		(0x30 + 0x18 * (n))
 #define MIX_L_SRC_OFFSET(n)		(0x34 + 0x18 * (n))
+
+/* CRC register offsets for odd and even lines */
+#define MIX_CRC_ODD			0x110
+#define MIX_CRC_EVEN			0x114
+
 #define MIX_FUNC_DCM0			0x120
 #define MIX_FUNC_DCM1			0x124
 #define MIX_FUNC_DCM_ENABLE			0xffffffff
@@ -82,6 +90,7 @@ struct mtk_ethdr {
 	void			*vblank_cb_data;
 	int			irq;
 	struct reset_control	*reset_ctl;
+	struct mtk_drm_crc	crc;
 };
 
 static const char * const ethdr_clk_str[] = {
@@ -100,6 +109,32 @@ static const char * const ethdr_clk_str[] = {
 	"vdo_be_async",
 };
 
+static const u32 ethdr_crc_ofs[] = {
+	MIX_CRC_ODD,
+	MIX_CRC_EVEN,
+};
+
+size_t mtk_ethdr_crc_cnt(struct device *dev)
+{
+	struct mtk_ethdr *priv = dev_get_drvdata(dev);
+
+	return priv->crc.cnt;
+}
+
+u32 *mtk_ethdr_crc_entry(struct device *dev)
+{
+	struct mtk_ethdr *priv = dev_get_drvdata(dev);
+
+	return priv->crc.va;
+}
+
+void mtk_ethdr_crc_read(struct device *dev)
+{
+	struct mtk_ethdr *priv = dev_get_drvdata(dev);
+
+	mtk_drm_crc_read(&priv->crc, priv->ethdr_comp[ETHDR_MIXER].regs);
+}
+
 void mtk_ethdr_register_vblank_cb(struct device *dev,
 				  void (*vblank_cb)(void *),
 				  void *vblank_cb_data)
@@ -256,6 +291,13 @@ void mtk_ethdr_start(struct device *dev)
 	struct mtk_ethdr_comp *mixer = &priv->ethdr_comp[ETHDR_MIXER];
 
 	writel(1, mixer->regs + MIX_EN);
+
+	if (priv->crc.cnt) {
+		writel(MIX_TRIG_CRC_EN, mixer->regs + MIX_TRIG);
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+		mtk_drm_crc_cmdq_start(&priv->crc);
+#endif
+	}
 }
 
 void mtk_ethdr_stop(struct device *dev)
@@ -263,6 +305,9 @@ void mtk_ethdr_stop(struct device *dev)
 	struct mtk_ethdr *priv = dev_get_drvdata(dev);
 	struct mtk_ethdr_comp *mixer = &priv->ethdr_comp[ETHDR_MIXER];
 
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	mtk_drm_crc_cmdq_stop(&priv->crc);
+#endif
 	writel(0, mixer->regs + MIX_EN);
 	writel(1, mixer->regs + MIX_RST);
 	reset_control_reset(priv->reset_ctl);
@@ -317,6 +362,10 @@ static int mtk_ethdr_probe(struct platform_device *pdev)
 	if (!priv)
 		return -ENOMEM;
 
+	mtk_drm_crc_init(&priv->crc,
+			 ethdr_crc_ofs, ARRAY_SIZE(ethdr_crc_ofs),
+			 MIX_TRIG, MIX_TRIG_CRC_RST);
+
 	for (i = 0; i < ETHDR_ID_MAX; i++) {
 		priv->ethdr_comp[i].dev = dev;
 		priv->ethdr_comp[i].regs = of_iomap(dev->of_node, i);
@@ -325,6 +374,16 @@ static int mtk_ethdr_probe(struct platform_device *pdev)
 					      &priv->ethdr_comp[i].cmdq_base, i);
 		if (ret)
 			dev_dbg(dev, "get mediatek,gce-client-reg fail!\n");
+
+		if (i == ETHDR_MIXER) {
+			if (of_property_read_u32_index(dev->of_node,
+						       "mediatek,gce-events", i,
+						       &priv->crc.cmdq_event)) {
+				dev_warn(dev, "failed to get gce-events for crc\n");
+			}
+			priv->crc.cmdq_reg = &priv->ethdr_comp[i].cmdq_base;
+			mtk_drm_crc_cmdq_create(dev, &priv->crc);
+		}
 #endif
 		dev_dbg(dev, "[DRM]regs:0x%p, node:%d\n", priv->ethdr_comp[i].regs, i);
 	}
@@ -365,6 +424,9 @@ static int mtk_ethdr_probe(struct platform_device *pdev)
 
 static int mtk_ethdr_remove(struct platform_device *pdev)
 {
+	struct mtk_ethdr *priv = dev_get_drvdata(&pdev->dev);
+
+	mtk_drm_crc_destroy(&priv->crc);
 	component_del(&pdev->dev, &mtk_ethdr_component_ops);
 	return 0;
 }
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.h b/drivers/gpu/drm/mediatek/mtk_ethdr.h
index 81af9edea3f7..d17d7256bd12 100644
--- a/drivers/gpu/drm/mediatek/mtk_ethdr.h
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.h
@@ -22,4 +22,9 @@ void mtk_ethdr_register_vblank_cb(struct device *dev,
 void mtk_ethdr_unregister_vblank_cb(struct device *dev);
 void mtk_ethdr_enable_vblank(struct device *dev);
 void mtk_ethdr_disable_vblank(struct device *dev);
+
+size_t mtk_ethdr_crc_cnt(struct device *dev);
+u32 *mtk_ethdr_crc_entry(struct device *dev);
+void mtk_ethdr_crc_read(struct device *dev);
+
 #endif
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:55 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:55 +0800
Subject: [PATCH v4 15/17] drm/mediatek: Add missing plane settings when async update
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-16-shawn.sung@mediatek.com>

Fix an issue that plane coordinate was not saved when
calling async update.

Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic update")

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index dfd81172a940..ff300426b590 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -232,6 +232,8 @@ static void mtk_plane_atomic_async_update(struct drm_plane *plane,
 	plane->state->src_y = new_state->src_y;
 	plane->state->src_h = new_state->src_h;
 	plane->state->src_w = new_state->src_w;
+	plane->state->dst.x1 = new_state->dst.x1;
+	plane->state->dst.y1 = new_state->dst.y1;
 
 	mtk_plane_update_new_state(new_state, new_plane_state);
 	swap(plane->state->fb, new_state->fb);
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:48 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:48 +0800
Subject: [PATCH v4 08/17] drm/mediatek: Support alpha blending in display driver
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-9-shawn.sung@mediatek.com>

Support alpha blending by adding correct blend mode and
alpha property in plane initialization.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 9208f03b3f8c..dfd81172a940 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -349,6 +349,17 @@ int mtk_plane_init(struct drm_device *dev, struct drm_plane *plane,
 			DRM_INFO("Create rotation property failed\n");
 	}
 
+	err = drm_plane_create_alpha_property(plane);
+	if (err)
+		DRM_ERROR("failed to create property: alpha\n");
+
+	err = drm_plane_create_blend_mode_property(plane,
+						   BIT(DRM_MODE_BLEND_PREMULTI) |
+						   BIT(DRM_MODE_BLEND_COVERAGE) |
+						   BIT(DRM_MODE_BLEND_PIXEL_NONE));
+	if (err)
+		DRM_ERROR("failed to create property: blend_mode\n");
+
 	drm_plane_helper_add(plane, &mtk_plane_helper_funcs);
 
 	return 0;
-- 
2.18.0



From shawn.sung at mediatek.com  Tue Dec 12 04:19:53 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Tue, 12 Dec 2023 20:19:53 +0800
Subject: [PATCH v4 13/17] drm/mediatek: Support CRC in OVL
In-Reply-To: <20231212121957.19231-1-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
Message-ID: <20231212121957.19231-14-shawn.sung@mediatek.com>

We choose OVL as the CRC generator from other hardware
components that are also capable of calculating CRCs,
since its frame done event triggers vblanks, it can be
used as a signal to know when is safe to retrieve CRC of
the frame.

Please note that position of the hardware component
that is chosen as CRC generator in the display path is
significant. For example, while OVL is the first module
in VDOSYS0, its CRC won't be affected by the modules
after it, which means effects applied by PQ, Gamma,
Dither or any other components after OVL won't be
calculated in CRC generation.

Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h     |  3 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c     | 85 +++++++++++++++++++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  3 +
 3 files changed, 85 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index c44f5b31bab5..08cc2d2fef9f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -102,6 +102,9 @@ void mtk_ovl_enable_vblank(struct device *dev);
 void mtk_ovl_disable_vblank(struct device *dev);
 const u32 *mtk_ovl_get_formats(struct device *dev);
 size_t mtk_ovl_get_num_formats(struct device *dev);
+size_t mtk_ovl_crc_cnt(struct device *dev);
+u32 *mtk_ovl_crc_entry(struct device *dev);
+void mtk_ovl_crc_read(struct device *dev);
 
 void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex *mutex);
 void mtk_ovl_adaptor_remove_comp(struct device *dev, struct mtk_mutex *mutex);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index a3f1630af5df..78749dabeb43 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -25,6 +25,13 @@
 #define OVL_FME_CPL_INT					BIT(1)
 #define DISP_REG_OVL_INTSTA			0x0008
 #define DISP_REG_OVL_EN				0x000c
+#define OVL_EN						BIT(0)
+#define OVL_OP_8BIT_MODE				BIT(4)
+#define OVL_HG_FOVL_CK_ON				BIT(8)
+#define OVL_HF_FOVL_CK_ON				BIT(10)
+#define DISP_REG_OVL_TRIG			0x0010
+#define OVL_CRC_EN					BIT(8)
+#define OVL_CRC_CLR					BIT(9)
 #define DISP_REG_OVL_RST			0x0014
 #define DISP_REG_OVL_ROI_SIZE			0x0020
 #define DISP_REG_OVL_DATAPATH_CON		0x0024
@@ -44,6 +51,8 @@
 #define DISP_REG_OVL_RDMA_CTRL(n)		(0x00c0 + 0x20 * (n))
 #define DISP_REG_OVL_RDMA_GMC(n)		(0x00c8 + 0x20 * (n))
 #define DISP_REG_OVL_ADDR_MT2701		0x0040
+#define DISP_REG_OVL_CRC			0x0270
+#define OVL_CRC_OUT_MASK				GENMASK(30, 0)
 #define DISP_REG_OVL_CLRFMT_EXT			0x02D0
 #define DISP_REG_OVL_CLRFMT_EXT1		0x02D8
 #define OVL_CLRFMT_EXT1_CSC_EN(n)			(1 << (((n) * 4) + 1))
@@ -151,6 +160,10 @@ static const u32 mt8195_formats[] = {
 	DRM_FORMAT_YUYV,
 };
 
+static const u32 mt8195_ovl_crc_ofs[] = {
+	DISP_REG_OVL_CRC,
+};
+
 struct mtk_disp_ovl_data {
 	unsigned int addr;
 	unsigned int gmc_bits;
@@ -161,12 +174,15 @@ struct mtk_disp_ovl_data {
 	const u32 *formats;
 	size_t num_formats;
 	bool supports_clrfmt_ext;
+	const u32 *crc_ofs;
+	size_t crc_cnt;
 };
 
 /*
  * struct mtk_disp_ovl - DISP_OVL driver structure
  * @crtc: associated crtc to report vblank events to
  * @data: platform data
+ * @crc: crc related information
  */
 struct mtk_disp_ovl {
 	struct drm_crtc			*crtc;
@@ -176,8 +192,30 @@ struct mtk_disp_ovl {
 	const struct mtk_disp_ovl_data	*data;
 	void				(*vblank_cb)(void *data);
 	void				*vblank_cb_data;
+	struct mtk_drm_crc		crc;
 };
 
+size_t mtk_ovl_crc_cnt(struct device *dev)
+{
+	struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+	return ovl->crc.cnt;
+}
+
+u32 *mtk_ovl_crc_entry(struct device *dev)
+{
+	struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+	return ovl->crc.va;
+}
+
+void mtk_ovl_crc_read(struct device *dev)
+{
+	struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+	mtk_drm_crc_read(&ovl->crc, ovl->regs);
+}
+
 static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
 {
 	struct mtk_disp_ovl *priv = dev_id;
@@ -269,15 +307,28 @@ void mtk_ovl_start(struct device *dev)
 	 * (should always be enabled)
 	 */
 	reg |= OVL_OUTPUT_CLAMP;
-
 	writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
-	writel_relaxed(0x1, ovl->regs + DISP_REG_OVL_EN);
+
+	reg = OVL_EN;
+	if (ovl->data->crc_cnt) {
+		/* enable crc  and its related clocks */
+		writel_relaxed(OVL_CRC_EN, ovl->regs + DISP_REG_OVL_TRIG);
+		reg |= OVL_OP_8BIT_MODE | OVL_HG_FOVL_CK_ON | OVL_HF_FOVL_CK_ON;
+	}
+	writel_relaxed(reg, ovl->regs + DISP_REG_OVL_EN);
+
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	mtk_drm_crc_cmdq_start(&ovl->crc);
+#endif
 }
 
 void mtk_ovl_stop(struct device *dev)
 {
 	struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
 
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	mtk_drm_crc_cmdq_stop(&ovl->crc);
+#endif
 	writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_EN);
 	if (ovl->data->smi_id_en) {
 		unsigned int reg;
@@ -695,15 +746,31 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
 		dev_err(dev, "failed to ioremap ovl\n");
 		return PTR_ERR(priv->regs);
 	}
+
+	priv->data = of_device_get_match_data(dev);
+	platform_set_drvdata(pdev, priv);
+
+	if (priv->data->crc_cnt) {
+		mtk_drm_crc_init(&priv->crc,
+				 priv->data->crc_ofs, priv->data->crc_cnt,
+				 DISP_REG_OVL_TRIG, OVL_CRC_CLR);
+	}
+
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 	ret = cmdq_dev_get_client_reg(dev, &priv->cmdq_reg, 0);
 	if (ret)
 		dev_dbg(dev, "get mediatek,gce-client-reg fail!\n");
-#endif
-
-	priv->data = of_device_get_match_data(dev);
-	platform_set_drvdata(pdev, priv);
 
+	if (priv->data->crc_cnt) {
+		if (of_property_read_u32_index(dev->of_node,
+					       "mediatek,gce-events", 0,
+					       &priv->crc.cmdq_event)) {
+			dev_warn(dev, "failed to get gce-events for crc\n");
+		}
+		priv->crc.cmdq_reg = &priv->cmdq_reg;
+		mtk_drm_crc_cmdq_create(dev, &priv->crc);
+	}
+#endif
 	ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
 			       IRQF_TRIGGER_NONE, dev_name(dev), priv);
 	if (ret < 0) {
@@ -724,6 +791,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
 
 static void mtk_disp_ovl_remove(struct platform_device *pdev)
 {
+	struct device *dev = &pdev->dev;
+	struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+	mtk_drm_crc_destroy(&ovl->crc);
 	component_del(&pdev->dev, &mtk_disp_ovl_component_ops);
 	pm_runtime_disable(&pdev->dev);
 }
@@ -794,6 +865,8 @@ static const struct mtk_disp_ovl_data mt8195_ovl_driver_data = {
 	.formats = mt8195_formats,
 	.num_formats = ARRAY_SIZE(mt8195_formats),
 	.supports_clrfmt_ext = true,
+	.crc_ofs = mt8195_ovl_crc_ofs,
+	.crc_cnt = ARRAY_SIZE(mt8195_ovl_crc_ofs),
 };
 
 static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 9940909c7435..1118efcde98a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -349,6 +349,9 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = {
 	.clk_enable = mtk_ovl_clk_enable,
 	.clk_disable = mtk_ovl_clk_disable,
 	.config = mtk_ovl_config,
+	.crc_cnt = mtk_ovl_crc_cnt,
+	.crc_entry = mtk_ovl_crc_entry,
+	.crc_read = mtk_ovl_crc_read,
 	.start = mtk_ovl_start,
 	.stop = mtk_ovl_stop,
 	.register_vblank_cb = mtk_ovl_register_vblank_cb,
-- 
2.18.0



From andyshrk at 163.com  Tue Dec 12 04:42:02 2023
From: andyshrk at 163.com (Andy Yan)
Date: Tue, 12 Dec 2023 20:42:02 +0800
Subject: [PATCH v4 0/5] Add 2 rk3588 based boards from Cool Pi
Message-ID: <20231212124202.1897238-1-andyshrk@163.com>


This series add support for rk3588s based SBC Cool Pi 4B
and rk3588 based board Cool Pi CM5 EVB

Changes in v4:
- split pi-cm5 as a dtsi

Changes in v3:
- drop ununnecessary property status = "okay" for rtc
- reorder some nodes alphabetical
- remove disabled node
- Add compatible "coolpi,pi-cm5" for CM5
- drop ununnecessary property status = "okay" for backlight
- reorder some nodes alphabetical
- drop ununnecessary blank line

Changes in v2:
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b"
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b"
- drop ununnecessary property status = "okay" for gpio-led
- drop ununnecessary blank line
- change node name to rtc for hym8563
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"

Andy Yan (5):
  dt-bindings: vendor-prefixes: Add Cool Pi
  dt-bindings: arm: rockchip: Add Cool Pi 4B
  arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B
  dt-bindings: arm: rockchip: Add Cool Pi CM5
  arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5
    EVB

 .../devicetree/bindings/arm/rockchip.yaml     |  12 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/rockchip/Makefile         |   2 +
 .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 214 +++++
 .../boot/dts/rockchip/rk3588-coolpi-cm5.dtsi  | 659 ++++++++++++++
 .../boot/dts/rockchip/rk3588s-coolpi-4b.dts   | 823 ++++++++++++++++++
 6 files changed, 1712 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts

-- 
2.34.1



From andyshrk at 163.com  Tue Dec 12 04:42:23 2023
From: andyshrk at 163.com (Andy Yan)
Date: Tue, 12 Dec 2023 20:42:23 +0800
Subject: [PATCH v4 1/5] dt-bindings: vendor-prefixes: Add Cool Pi
In-Reply-To: <20231212124202.1897238-1-andyshrk@163.com>
References: <20231212124202.1897238-1-andyshrk@163.com>
Message-ID: <20231212124223.1897314-1-andyshrk@163.com>

Add vendor prefix for Cool Pi(https://cool-pi.com/)

Signed-off-by: Andy Yan <andyshrk at 163.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

(no changes since v1)

 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c8..ddbba46fcbad 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -294,6 +294,8 @@ patternProperties:
     description: CompuLab Ltd.
   "^congatec,.*":
     description: congatec GmbH
+  "^coolpi,.*":
+    description: cool-pi.com
   "^coreriver,.*":
     description: CORERIVER Semiconductor Co.,Ltd.
   "^corpro,.*":
-- 
2.34.1



From andyshrk at 163.com  Tue Dec 12 04:42:37 2023
From: andyshrk at 163.com (Andy Yan)
Date: Tue, 12 Dec 2023 20:42:37 +0800
Subject: [PATCH v4 2/5] dt-bindings: arm: rockchip: Add Cool Pi 4B
In-Reply-To: <20231212124202.1897238-1-andyshrk@163.com>
References: <20231212124202.1897238-1-andyshrk@163.com>
Message-ID: <20231212124237.1897378-1-andyshrk@163.com>

Add Cool Pi 4B, a SBC powered by RK3588S

Signed-off-by: Andy Yan <andyshrk at 163.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

(no changes since v2)

Changes in v2:
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b"

 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5deb66a5c7d9..11d03035f3db 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -95,6 +95,11 @@ properties:
           - const: chipspark,rayeager-px2
           - const: rockchip,rk3066a
 
+      - description: Cool Pi 4 Model B
+        items:
+          - const: coolpi,pi-4b
+          - const: rockchip,rk3588s
+
       - description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
         items:
           - const: edgeble,neural-compute-module-2-io   # Edgeble Neural Compute Module 2 IO Board
-- 
2.34.1



From andyshrk at 163.com  Tue Dec 12 04:42:53 2023
From: andyshrk at 163.com (Andy Yan)
Date: Tue, 12 Dec 2023 20:42:53 +0800
Subject: [PATCH v4 3/5] arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B
In-Reply-To: <20231212124202.1897238-1-andyshrk@163.com>
References: <20231212124202.1897238-1-andyshrk@163.com>
Message-ID: <20231212124253.1897438-1-andyshrk@163.com>

CoolPi 4B is a rk3588s based SBC.
Specification:
- Rockchip RK3588S
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- Gigabit ethernet drived by PCIE with RTL8111HS
- HDMI Type D out
- Mini DP out
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- WIFI/BT module AIC8800
- 40 pin header

Signed-off-by: Andy Yan <andyshrk at 163.com>

arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B

---

(no changes since v3)

Changes in v3:
- drop ununnecessary property status = "okay" for rtc
- reorder some nodes alphabetical
- remove disabled node

Changes in v2:
- change board compatible from "CoolPi 4 Model B" to "coolpi,pi-4b"
- drop ununnecessary property status = "okay" for gpio-led
- drop ununnecessary blank line
- change node name to rtc for hym8563

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3588s-coolpi-4b.dts   | 823 ++++++++++++++++++
 2 files changed, 824 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 41276ca535de..e59682691eb0 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -109,6 +109,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-orangepi-5-plus.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-quartzpro64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-turing-rk1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-coolpi-4b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
new file mode 100644
index 000000000000..50b3caae0151
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
@@ -0,0 +1,823 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ * https://cool-pi.com/topic/130/coolpi-4b-product-spec-introduction
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3588s.dtsi"
+
+/ {
+	model = "RK3588S CoolPi 4 Model B";
+	compatible = "coolpi,pi-4b", "rockchip,rk3588s";
+
+	aliases {
+		mmc0 = &sdhci;
+		mmc1 = &sdio;
+		mmc2 = &sdmmc;
+		serial2 = &uart2;
+	};
+
+	analog-sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
+
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+
+		dais = <&i2s0_8ch_p0>;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl- = <&gpio_leds>;
+
+		led0: led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led1: led-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_WLAN;
+			gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "phy0tx";
+			default-state = "off";
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&hym8563>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_h>;
+		/*
+		 * On the module itself this is one of these (depending
+		 * on the actual card populated):
+		 * - SDIO_RESET_L_WL_REG_ON
+		 * - PDN (power down when low)
+		 */
+		post-power-on-delay-ms = <200>;
+		reset-gpios = <&gpio0 RK_PC7 GPIO_ACTIVE_LOW>;
+	};
+
+	vcc12v_dcin: vcc12v-dcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usbdcin: vcc5v0-usbdcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usbdcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usbdcin>;
+	};
+
+	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v85_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <850000>;
+		regulator-max-microvolt = <850000>;
+		vin-supply = <&vdd_0v85_s0>;
+	};
+
+	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd1v8_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	vcc3v3_mipi: vcc3v3-mipi-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_mipi";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_otg: vcc5v0-otg-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_otg";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio3 RK_PC1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_u3host_en>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&i2c0 {
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c6 {
+	pinctrl-0 = <&i2c6m3_xfer>;
+	status = "okay";
+
+	hym8563: rtc at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hym8563_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+&i2c7 {
+	pinctrl-0 = <&i2c7m0_xfer>;
+	status = "okay";
+
+	es8316: audio-codec at 11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		#sound-dai-cells = <0>;
+
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
+		};
+	};
+};
+
+&i2s0_8ch {
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
+		};
+	};
+};
+
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rtl8111_isolate>;
+	status = "okay";
+};
+
+&pinctrl {
+	hym8563 {
+		hym8563_int: hym8563-int {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	led {
+		gpio_leds: gpio-leds {
+			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>,
+					<0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	rtl8111 {
+		rtl8111_isolate: rtl8111-isolate {
+			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sdio-pwrseq {
+		wifi_enable_h: wifi-enable-h {
+			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins = <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>,
+					<4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		vcc5v0_u3host_en: vcc5v0-u3host-en {
+			rockchip,pins = <3 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wireless-bluetooth {
+		uart9_gpios: uart9-gpios {
+			rockchip,pins = <3 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_reset_gpio: bt-reset-gpio {
+			rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_gpio: bt-wake-gpio {
+			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_host_irq: bt-wake-host-irq {
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	wireless-wlan {
+		wifi_host_wake_irq: wifi-host-wake-irq {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		wifi_poweren_gpio: wifi-poweren-gpio {
+			rockchip,pins = <1 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
+
+&pwm2 {
+	pinctrl-0 = <&pwm2m1_pins>;
+	status = "okay";
+};
+
+&pwm13 {
+	pinctrl-names = "active";
+	pinctrl-0 = <&pwm13m2_pins>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	status = "okay";
+};
+
+&sdio {
+	max-frequency = <150000000>;
+	no-sd;
+	no-mmc;
+	bus-width = <4>;
+	disable-wp;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdiom1_pins>,<&wifi_poweren_gpio>;
+	status = "okay";
+};
+
+&sdmmc {
+	max-frequency = <150000000>;
+	no-sdio;
+	no-mmc;
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	num-cs = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	status = "okay";
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		reg = <0x0>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		spi-max-frequency = <1000000>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-name = "vdd_gpu_s0";
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-name = "vdd_cpu_lit_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-name = "vdd_log_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-name = "vdd_vdenc_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-name = "vdd_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-name = "vdd2_ddr_s3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-name = "vdd_2v0_pldo_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-name = "vcc_3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-name = "vddq_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-name = "vcc_1v8_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-name = "avcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-name = "vcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-name = "avdd_1v2_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-name = "vcc_3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-name = "vccio_sd_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-name = "pldo6_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-name = "vdd_0v75_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-name = "vdd_ddr_pll_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-name = "avdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-name = "vdd_0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-name = "vdd_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&u2phy3_host {
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+/* bt */
+&uart9 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn>;
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
-- 
2.34.1



From andyshrk at 163.com  Tue Dec 12 04:43:40 2023
From: andyshrk at 163.com (Andy Yan)
Date: Tue, 12 Dec 2023 20:43:40 +0800
Subject: [PATCH v4 4/5] dt-bindings: arm: rockchip: Add Cool Pi CM5
In-Reply-To: <20231212124202.1897238-1-andyshrk@163.com>
References: <20231212124202.1897238-1-andyshrk@163.com>
Message-ID: <20231212124340.1897502-1-andyshrk@163.com>

Add Cool Pi CM5, a board powered by RK3588

CM5 EVB works with a mother board connect with
CM5

Signed-off-by: Andy Yan <andyshrk at 163.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

---

Changes in v4:
- Add compatible "coolpi,pi-cm5" for CM5

Changes in v2:
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"

 Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 11d03035f3db..7a81543132a5 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -95,6 +95,13 @@ properties:
           - const: chipspark,rayeager-px2
           - const: rockchip,rk3066a
 
+      - description: Cool Pi Compute Module 5(CM5) EVB
+        items:
+          - enum:
+              - coolpi,pi-cm5-evb
+          - const: coolpi,pi-cm5
+          - const: rockchip,rk3588
+
       - description: Cool Pi 4 Model B
         items:
           - const: coolpi,pi-4b
-- 
2.34.1



From andyshrk at 163.com  Tue Dec 12 04:44:07 2023
From: andyshrk at 163.com (Andy Yan)
Date: Tue, 12 Dec 2023 20:44:07 +0800
Subject: [PATCH v4 5/5] arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5 EVB
In-Reply-To: <20231212124202.1897238-1-andyshrk@163.com>
References: <20231212124202.1897238-1-andyshrk@163.com>
Message-ID: <20231212124407.1897604-1-andyshrk@163.com>

Cool Pi CM5 EVB works as a mother board connect with CM5.

CM5 Specification:
- Rockchip RK3588
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- Gigabit ethernet x 1 with PHY YT8531
- Gigabit ethernet x 1 drived by PCIE with YT6801S

CM5 EVB Specification:
- HDMI Type A out x 2
- HDMI Type D in x 1
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- PCIE M.2 E Key for Wireless connection
- PCIE M.2 M Key for NVME connection
- 40 pin header

Signed-off-by: Andy Yan <andyshrk at 163.com>

---

Changes in v4:
- split pi-cm5 as a dtsi

Changes in v3:
- drop ununnecessary property status = "okay" for backlight
- reorder some nodes alphabetical
- drop ununnecessary blank line

Changes in v2:
- change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 214 ++++++
 .../boot/dts/rockchip/rk3588-coolpi-cm5.dtsi  | 659 ++++++++++++++++++
 3 files changed, 874 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index e59682691eb0..9be8e4830158 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-odroid-m1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-radxa-e25.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-roc-pc.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-coolpi-cm5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6b-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
new file mode 100644
index 000000000000..61d01ca7b024
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
@@ -0,0 +1,214 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include "rk3588-coolpi-cm5.dtsi"
+
+/ {
+	model = "RK3588 CoolPi CM5 EVB";
+	compatible = "coolpi,pi-cm5-evb", "coolpi,pi-cm5", "rockchip,rk3588";
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		power-supply = <&vcc12v_dcin>;
+		pwms = <&pwm2 0 25000 0>;
+		enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bl_en>;
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+
+		led: led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	vcc12v_dcin: vcc12v-dcin-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_lcd: vcc3v3-lcd-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd";
+		enable-active-high;
+		gpio = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&lcdpwr_en>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	vcc5v0_usb30_host: vcc5v0-usb30-host-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_usb30_otg: vcc5v0-usb30-otg-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_otg";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_otg_pwren>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+/* M.2 E-Key */
+&pcie2x1l1 {
+	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie_clkreq &pcie_wake &pcie_rst &wifi_pwron &bt_pwron>;
+	status = "okay";
+};
+
+&pcie30phy {
+	status = "okay";
+};
+
+&pcie3x2 {
+	reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	status = "okay";
+};
+
+/* M.2 M-Key ssd */
+&pcie3x4 {
+	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	status = "okay";
+};
+
+&pinctrl {
+	lcd {
+		lcdpwr_en: lcdpwr-en {
+			rockchip,pins = <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		bl_en: bl-en {
+			rockchip,pins = <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		usb_host_pwren: usb-host-pwren {
+			rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		usb_otg_pwren: usb-otg-pwren {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	wifi {
+		bt_pwron: bt-pwron {
+			rockchip,pins = <3 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		pcie_clkreq: pcie-clkreq {
+			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		pcie_rst: pcie-rst {
+			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		wifi_pwron: wifi-pwron {
+			rockchip,pins = <3 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		pcie_wake: pcie-wake {
+			rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&sata1 {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_usb30_host>;
+	status = "okay";
+};
+
+&u2phy3_host {
+	phy-supply = <&vcc5v0_usb30_host>;
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi
new file mode 100644
index 000000000000..fcdc3e7a4351
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi
@@ -0,0 +1,659 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3588.dtsi"
+
+/ {
+	compatible = "coolpi,pi-cm5", "rockchip,rk3588";
+
+	aliases {
+		mmc0 = &sdhci;
+		mmc1 = &sdio;
+		mmc2 = &sdmmc;
+		serial2 = &uart2;
+	};
+
+	analog-sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
+
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+
+		dais = <&i2s0_8ch_p0>;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v85_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <850000>;
+		regulator-max-microvolt = <850000>;
+		vin-supply = <&vdd_0v85_s0>;
+	};
+
+	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd1v8_pcie20";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+
+	avdd0v75_pcie30: avdd0v75-pcie30-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "avdd0v75_pcie30";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <750000>;
+		regulator-max-microvolt = <750000>;
+		vin-supply = <&avdd_0v75_s0>;
+	};
+
+	pcie30_avdd1v8: avdd1v8-pcie30-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd1v8";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&avcc_1v8_s0>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy1_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&gmac0 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-rxid";
+	pinctrl-0 = <&gmac0_miim
+		     &gmac0_tx_bus2
+		     &gmac0_rx_bus2
+		     &gmac0_rgmii_clk
+		     &gmac0_rgmii_bus>;
+	pinctrl-names = "default";
+	rx_delay = <0x00>;
+	tx_delay = <0x43>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c6 {
+	status = "okay";
+
+	hym8563: rtc at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hym8563_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PD4 IRQ_TYPE_LEVEL_LOW>;
+		wakeup-source;
+	};
+};
+
+&i2c7 {
+	pinctrl-0 = <&i2c7m0_xfer>;
+	status = "okay";
+
+	es8316: audio-codec at 11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		#sound-dai-cells = <0>;
+
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
+		};
+	};
+};
+
+&i2s0_8ch {
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
+		};
+	};
+};
+
+&mdio0 {
+	rgmii_phy: ethernet-phy at 1 {
+		/* YT8531C/H */
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&yt8531_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
+	};
+};
+
+/* ethernet */
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_sys>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&yt6801_isolate>;
+	status = "okay";
+};
+
+&pinctrl {
+	hym8563 {
+		hym8563_int: hym8563-int {
+			rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	yt6801 {
+		yt6801_isolate: yt6801-isolate {
+			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	yt8531 {
+		yt8531_rst: yt8531-rst {
+			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	status = "okay";
+};
+
+&sdmmc {
+	max-frequency = <150000000>;
+	no-sdio;
+	no-mmc;
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	status = "okay";
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	num-cs = <1>;
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		spi-max-frequency = <1000000>;
+		reg = <0x0>;
+
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_2v0_pldo_s3>;
+		vcc14-supply = <&vcc_2v0_pldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_lit_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_log_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_vdenc_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vdd2_ddr_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_2v0_pldo_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vddq_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "avcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "avdd_1v2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vcc_3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vccio_sd_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "pldo6_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_ddr_pll_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "avdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_0v85_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
-- 
2.34.1



From angelogioacchino.delregno at collabora.com  Tue Dec 12 04:44:49 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 13:44:49 +0100
Subject: [v9 3/4] ASoC: mediatek: mt8188-mt6359: add es8326 support
In-Reply-To: <20231212123050.4080083-4-zhourui@huaqin.corp-partner.google.com>
References: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
 <20231212123050.4080083-4-zhourui@huaqin.corp-partner.google.com>
Message-ID: <25ec0476-0ee3-4f2a-b0e6-ee33580159ab@collabora.com>

Il 12/12/23 13:30, Rui Zhou ha scritto:
> To use ES8326 as the codec, add a new sound card
> named mt8186_es8326.
> 
> Reviewed-by: Trevor Wu <trevor.wu at mediatek.com>
> Signed-off-by: Rui Zhou <zhourui at huaqin.corp-partner.google.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>

....but this series is going to be ignored like that, because you didn't add the
right mailing lists to the To/Cc.

Please use scripts/get_maintainer.pl

Thanks,
Angelo


From andyshrk at 163.com  Tue Dec 12 04:46:57 2023
From: andyshrk at 163.com (Andy Yan)
Date: Tue, 12 Dec 2023 20:46:57 +0800 (CST)
Subject: [PATCH v3 5/5] arm64: dts: rockchip: Add support for rk3588
 based board Cool Pi CM5 EVB
In-Reply-To: <2215635.TLkxdtWsSY@diego>
References: <20231211104915.1779476-1-andyshrk@163.com>
 <20231211105043.1779852-1-andyshrk@163.com> <2215635.TLkxdtWsSY@diego>
Message-ID: <30c4856c.51cd.18c5e10efa0.Coremail.andyshrk@163.com>


Hi Heiko:

At 2023-12-11 20:33:00, "Heiko St?bner" <heiko at sntech.de> wrote:
>Am Montag, 11. Dezember 2023, 11:50:43 CET schrieb Andy Yan:
>> Cool Pi CM5 EVB is a board based on rk3588.
>> 
>> Specification:
>> - Rockchip RK3588
>> - LPDDR4 2/4/8/16 GB
>> - TF scard slot
>> - eMMC 8/32/64/128 GB module
>> - Gigabit ethernet x 1 with PHY YT8531
>> - Gigabit ethernet x 1 drived by PCIE with YT6801S
>> - HDMI Type A out x 2
>> - HDMI Type D in x 1
>> - USB 2.0 Host x 2
>> - USB 3.0 OTG x 1
>> - USB 3.0 Host x 1
>> - PCIE M.2 E Key for Wireless connection
>> - PCIE M.2 M Key for NVME connection
>> - 40 pin header
>> 
>> Signed-off-by: Andy Yan <andyshrk at 163.com>
>
>In the overall scheme of things I would really like to see the correct
>split between SoM dtsi and baseboard dts, like the other SoMs do.
>
>You said you wanted to wait for an actual second baseboard to come along
>before doing this and I guess for "yet another som" we can try going that
>route.
>
>But please state this explicitly in the commit message that this is a
>baseboard+som combination, so the next one working here should do
>that split.
>
>An update is needed anyway, cause the compatible thing mentioned in 
>the binding.
>

I try to split it as a SoM dtsi + board dts in V4

>
>Thanks
>Heiko
>
>> ---
>> 
>> Changes in v3:
>> - drop ununnecessary property status = "okay" for backlight
>> - reorder some nodes alphabetical
>> - drop ununnecessary blank line
>> 
>> Changes in v2:
>> - change board compatible from "CoolPi CM5 EVB" to "coolpi,pi-cm5-evb"
>> 
>>  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>>  .../dts/rockchip/rk3588-coolpi-cm5-evb.dts    | 879 ++++++++++++++++++
>>  2 files changed, 880 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
>> 
>> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
>> index e59682691eb0..9be8e4830158 100644
>> --- a/arch/arm64/boot/dts/rockchip/Makefile
>> +++ b/arch/arm64/boot/dts/rockchip/Makefile
>> @@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-odroid-m1.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-radxa-e25.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-roc-pc.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
>> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-coolpi-cm5-evb.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-io.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6b-io.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-evb1-v10.dtb
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
>> new file mode 100644
>> index 000000000000..ccf17185dc10
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
>> @@ -0,0 +1,879 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/leds/common.h>
>> +#include <dt-bindings/pwm/pwm.h>
>> +#include <dt-bindings/pinctrl/rockchip.h>
>> +#include "rk3588.dtsi"
>> +
>> +/ {
>> +	model = "RK3588 CoolPi CM5 EVB";
>> +	compatible = "coolpi,pi-cm5-evb", "rockchip,rk3588";
>> +
>> +	aliases {
>> +		mmc0 = &sdhci;
>> +		mmc1 = &sdio;
>> +		mmc2 = &sdmmc;
>> +		serial2 = &uart2;
>> +	};
>> +
>> +	analog-sound {
>> +		compatible = "audio-graph-card";
>> +		label = "rk3588-es8316";
>> +
>> +		widgets = "Microphone", "Mic Jack",
>> +			  "Headphone", "Headphones";
>> +
>> +		routing = "MIC2", "Mic Jack",
>> +			  "Headphones", "HPOL",
>> +			  "Headphones", "HPOR";
>> +
>> +		dais = <&i2s0_8ch_p0>;
>> +	};
>> +
>> +	backlight: backlight {
>> +		compatible = "pwm-backlight";
>> +		power-supply = <&vcc12v_dcin>;
>> +		pwms = <&pwm2 0 25000 0>;
>> +		enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&bl_en>;
>> +	};
>> +
>> +	chosen {
>> +		stdout-path = "serial2:1500000n8";
>> +	};
>> +
>> +	leds: leds {
>> +		compatible = "gpio-leds";
>> +
>> +		led: led-green {
>> +			color = <LED_COLOR_ID_GREEN>;
>> +			function = LED_FUNCTION_STATUS;
>> +			gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
>> +			linux,default-trigger = "heartbeat";
>> +		};
>> +	};
>> +
>> +	vcc12v_dcin: vcc12v-dcin-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc12v_dcin";
>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +		regulator-min-microvolt = <12000000>;
>> +		regulator-max-microvolt = <12000000>;
>> +	};
>> +
>> +	vcc5v0_sys: vcc5v0-sys-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc5v0_sys";
>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		vin-supply = <&vcc12v_dcin>;
>> +	};
>> +
>> +	vcc3v3_sys: vcc3v3-sys-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc3v3_sys";
>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +		regulator-min-microvolt = <3300000>;
>> +		regulator-max-microvolt = <3300000>;
>> +		vin-supply = <&vcc12v_dcin>;
>> +	};
>> +
>> +	vcc3v3_lcd: vcc3v3-lcd-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc3v3_lcd";
>> +		enable-active-high;
>> +		gpio = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&lcdpwr_en>;
>> +		vin-supply = <&vcc3v3_sys>;
>> +	};
>> +
>> +	avdd0v85_pcie20: avdd0v85-pcie20-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "avdd0v85_pcie20";
>> +		regulator-boot-on;
>> +		regulator-always-on;
>> +		regulator-min-microvolt = <850000>;
>> +		regulator-max-microvolt = <850000>;
>> +		vin-supply = <&vdd_0v85_s0>;
>> +	};
>> +
>> +	avdd1v8_pcie20: avdd1v8-pcie20-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "avdd1v8_pcie20";
>> +		regulator-boot-on;
>> +		regulator-always-on;
>> +		regulator-min-microvolt = <1800000>;
>> +		regulator-max-microvolt = <1800000>;
>> +		vin-supply = <&avcc_1v8_s0>;
>> +	};
>> +
>> +	avdd0v75_pcie30: avdd0v75-pcie30-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "avdd0v75_pcie30";
>> +		regulator-boot-on;
>> +		regulator-always-on;
>> +		regulator-min-microvolt = <750000>;
>> +		regulator-max-microvolt = <750000>;
>> +		vin-supply = <&avdd_0v75_s0>;
>> +	};
>> +
>> +	pcie30_avdd1v8: avdd1v8-pcie30-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "pcie30_avdd1v8";
>> +		regulator-boot-on;
>> +		regulator-always-on;
>> +		regulator-min-microvolt = <1800000>;
>> +		regulator-max-microvolt = <1800000>;
>> +		vin-supply = <&avcc_1v8_s0>;
>> +	};
>> +
>> +	vcc5v0_host: vcc5v0-host-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc5v0_host";
>> +		regulator-boot-on;
>> +		regulator-always-on;
>> +		enable-active-high;
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		gpio = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&vcc5v0_host1_en>;
>> +		vin-supply = <&vcc5v0_sys>;
>> +	};
>> +
>> +	vcc5v0_otg: vcc5v0-otg-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc5v0_otg";
>> +		regulator-boot-on;
>> +		regulator-always-on;
>> +		enable-active-high;
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&typec5v_pwren>;
>> +		vin-supply = <&vcc5v0_sys>;
>> +	};
>> +
>> +	vcc_mipidphy0: vcc-mipi-dphy0-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc_mipidphy0";
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		regulator-boot-on;
>> +		regulator-always-on;
>> +		enable-active-high;
>> +		gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
>> +		vin-supply = <&vcc5v0_sys>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&cam_en>;
>> +	};
>> +};
>> +
>> +&combphy0_ps {
>> +	status = "okay";
>> +};
>> +
>> +&combphy1_ps {
>> +	status = "okay";
>> +};
>> +
>> +&combphy2_psu {
>> +	status = "okay";
>> +};
>> +
>> +&cpu_b0 {
>> +	cpu-supply = <&vdd_cpu_big0_s0>;
>> +};
>> +
>> +&cpu_b1 {
>> +	cpu-supply = <&vdd_cpu_big0_s0>;
>> +};
>> +
>> +&cpu_b2 {
>> +	cpu-supply = <&vdd_cpu_big1_s0>;
>> +};
>> +
>> +&cpu_b3 {
>> +	cpu-supply = <&vdd_cpu_big1_s0>;
>> +};
>> +
>> +&cpu_l0 {
>> +	cpu-supply = <&vdd_cpu_lit_s0>;
>> +};
>> +
>> +&cpu_l1 {
>> +	cpu-supply = <&vdd_cpu_lit_s0>;
>> +};
>> +
>> +&cpu_l2 {
>> +	cpu-supply = <&vdd_cpu_lit_s0>;
>> +};
>> +
>> +&cpu_l3 {
>> +	cpu-supply = <&vdd_cpu_lit_s0>;
>> +};
>> +
>> +&gmac0 {
>> +	clock_in_out = "output";
>> +	phy-handle = <&rgmii_phy>;
>> +	phy-mode = "rgmii-rxid";
>> +	pinctrl-0 = <&gmac0_miim
>> +		     &gmac0_tx_bus2
>> +		     &gmac0_rx_bus2
>> +		     &gmac0_rgmii_clk
>> +		     &gmac0_rgmii_bus>;
>> +	pinctrl-names = "default";
>> +	rx_delay = <0x00>;
>> +	tx_delay = <0x43>;
>> +	status = "okay";
>> +};
>> +
>> +&i2c0 {
>> +	pinctrl-0 = <&i2c0m2_xfer>;
>> +	status = "okay";
>> +
>> +	vdd_cpu_big0_s0: regulator at 42 {
>> +		compatible = "rockchip,rk8602";
>> +		reg = <0x42>;
>> +		fcs,suspend-voltage-selector = <1>;
>> +		regulator-name = "vdd_cpu_big0_s0";
>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +		regulator-min-microvolt = <550000>;
>> +		regulator-max-microvolt = <1050000>;
>> +		regulator-ramp-delay = <2300>;
>> +		vin-supply = <&vcc5v0_sys>;
>> +
>> +		regulator-state-mem {
>> +			regulator-off-in-suspend;
>> +		};
>> +	};
>> +
>> +	vdd_cpu_big1_s0: regulator at 43 {
>> +		compatible = "rockchip,rk8603", "rockchip,rk8602";
>> +		reg = <0x43>;
>> +		fcs,suspend-voltage-selector = <1>;
>> +		regulator-name = "vdd_cpu_big1_s0";
>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +		regulator-min-microvolt = <550000>;
>> +		regulator-max-microvolt = <1050000>;
>> +		regulator-ramp-delay = <2300>;
>> +		vin-supply = <&vcc5v0_sys>;
>> +
>> +		regulator-state-mem {
>> +			regulator-off-in-suspend;
>> +		};
>> +	};
>> +};
>> +
>> +&i2c2 {
>> +	status = "okay";
>> +
>> +	vdd_npu_s0: regulator at 42 {
>> +		compatible = "rockchip,rk8602";
>> +		reg = <0x42>;
>> +		fcs,suspend-voltage-selector = <1>;
>> +		regulator-name = "vdd_npu_s0";
>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +		regulator-min-microvolt = <550000>;
>> +		regulator-max-microvolt = <950000>;
>> +		regulator-ramp-delay = <2300>;
>> +		vin-supply = <&vcc5v0_sys>;
>> +
>> +		regulator-state-mem {
>> +			regulator-off-in-suspend;
>> +		};
>> +	};
>> +};
>> +
>> +&i2c6 {
>> +	status = "okay";
>> +
>> +	hym8563: rtc at 51 {
>> +		compatible = "haoyu,hym8563";
>> +		reg = <0x51>;
>> +		#clock-cells = <0>;
>> +		clock-frequency = <32768>;
>> +		clock-output-names = "hym8563";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&hym8563_int>;
>> +		interrupt-parent = <&gpio0>;
>> +		interrupts = <RK_PD4 IRQ_TYPE_LEVEL_LOW>;
>> +		wakeup-source;
>> +	};
>> +};
>> +
>> +&i2c7 {
>> +	pinctrl-0 = <&i2c7m0_xfer>;
>> +	status = "okay";
>> +
>> +	es8316: audio-codec at 11 {
>> +		compatible = "everest,es8316";
>> +		reg = <0x11>;
>> +		clocks = <&cru I2S0_8CH_MCLKOUT>;
>> +		clock-names = "mclk";
>> +		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
>> +		assigned-clock-rates = <12288000>;
>> +		#sound-dai-cells = <0>;
>> +
>> +		port {
>> +			es8316_p0_0: endpoint {
>> +				remote-endpoint = <&i2s0_8ch_p0_0>;
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&i2s0_8ch {
>> +	pinctrl-0 = <&i2s0_lrck
>> +		     &i2s0_mclk
>> +		     &i2s0_sclk
>> +		     &i2s0_sdi0
>> +		     &i2s0_sdo0>;
>> +	status = "okay";
>> +
>> +	i2s0_8ch_p0: port {
>> +		i2s0_8ch_p0_0: endpoint {
>> +			dai-format = "i2s";
>> +			mclk-fs = <256>;
>> +			remote-endpoint = <&es8316_p0_0>;
>> +		};
>> +	};
>> +};
>> +
>> +&mdio0 {
>> +	rgmii_phy: ethernet-phy at 1 {
>> +		/* YT8531C/H */
>> +		compatible = "ethernet-phy-ieee802.3-c22";
>> +		reg = <0x1>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&yt8531_rst>;
>> +		reset-assert-us = <20000>;
>> +		reset-deassert-us = <100000>;
>> +		reset-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
>> +	};
>> +};
>> +
>> +/* M.2 E-Key */
>> +&pcie2x1l1 {
>> +	reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
>> +	vpcie3v3-supply = <&vcc3v3_sys>;
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pcie_clkreq &pcie_wake &pcie_rst &wifi_pwron &bt_pwron>;
>> +	status = "okay";
>> +};
>> +
>> +/* ethernet */
>> +&pcie2x1l2 {
>> +	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
>> +	vpcie3v3-supply = <&vcc3v3_sys>;
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&rtl8111_isolate>;
>> +	status = "okay";
>> +};
>> +
>> +&pcie30phy {
>> +	status = "okay";
>> +};
>> +
>> +&pcie3x2 {
>> +	reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
>> +	vpcie3v3-supply = <&vcc3v3_sys>;
>> +	status = "okay";
>> +};
>> +
>> +/* M.2 M-Kye ssd */
>> +&pcie3x4 {
>> +	reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
>> +	vpcie3v3-supply = <&vcc3v3_sys>;
>> +	status = "okay";
>> +};
>> +
>> +&pinctrl {
>> +	cam {
>> +		cam_en: cam-en {
>> +			rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_output_high>;
>> +		};
>> +	};
>> +
>> +	hym8563 {
>> +		hym8563_int: hym8563-int {
>> +			rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
>> +		};
>> +	};
>> +
>> +	lcd {
>> +		lcdpwr_en: lcdpwr-en {
>> +			rockchip,pins = <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
>> +		};
>> +
>> +		bl_en: bl-en {
>> +			rockchip,pins = <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
>> +		};
>> +	};
>> +
>> +	rtl8111 {
>> +		rtl8111_isolate: rtl8111-isolate {
>> +			rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
>> +		};
>> +	};
>> +
>> +	rtl8211f {
>> +		yt8531_rst: yt8531-rst {
>> +			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
>> +		};
>> +	};
>> +
>> +	usb {
>> +		vcc5v0_host1_en: vcc5v0-host1-en {
>> +			rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
>> +		};
>> +	};
>> +
>> +	usb-typec {
>> +		typec5v_pwren: typec5v-pwren {
>> +			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
>> +		};
>> +	};
>> +
>> +	wifi {
>> +		bt_pwron: bt-pwron {
>> +			rockchip,pins = <3 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
>> +		};
>> +
>> +		pcie_clkreq: pcie-clkreq {
>> +			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
>> +		};
>> +
>> +		pcie_rst: pcie-rst {
>> +			rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
>> +		};
>> +
>> +		wifi_pwron: wifi-pwron {
>> +			rockchip,pins = <3 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
>> +		};
>> +
>> +		pcie_wake: pcie-wake {
>> +			rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
>> +		};
>> +	};
>> +};
>> +
>> +&pwm2 {
>> +	status = "okay";
>> +};
>> +
>> +&saradc {
>> +	vref-supply = <&vcc_1v8_s0>;
>> +	status = "okay";
>> +};
>> +
>> +&sata1 {
>> +	status = "okay";
>> +};
>> +
>> +&sdhci {
>> +	bus-width = <8>;
>> +	no-sdio;
>> +	no-sd;
>> +	non-removable;
>> +	max-frequency = <200000000>;
>> +	mmc-hs400-1_8v;
>> +	mmc-hs400-enhanced-strobe;
>> +	status = "okay";
>> +};
>> +
>> +&sdmmc {
>> +	max-frequency = <150000000>;
>> +	no-sdio;
>> +	no-mmc;
>> +	bus-width = <4>;
>> +	cap-mmc-highspeed;
>> +	cap-sd-highspeed;
>> +	disable-wp;
>> +	sd-uhs-sdr104;
>> +	vqmmc-supply = <&vccio_sd_s0>;
>> +	status = "okay";
>> +};
>> +
>> +&spi2 {
>> +	status = "okay";
>> +	assigned-clocks = <&cru CLK_SPI2>;
>> +	assigned-clock-rates = <200000000>;
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
>> +	num-cs = <1>;
>> +
>> +	pmic at 0 {
>> +		compatible = "rockchip,rk806";
>> +		spi-max-frequency = <1000000>;
>> +		reg = <0x0>;
>> +
>> +		interrupt-parent = <&gpio0>;
>> +		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
>> +
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
>> +			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
>> +
>> +		vcc1-supply = <&vcc5v0_sys>;
>> +		vcc2-supply = <&vcc5v0_sys>;
>> +		vcc3-supply = <&vcc5v0_sys>;
>> +		vcc4-supply = <&vcc5v0_sys>;
>> +		vcc5-supply = <&vcc5v0_sys>;
>> +		vcc6-supply = <&vcc5v0_sys>;
>> +		vcc7-supply = <&vcc5v0_sys>;
>> +		vcc8-supply = <&vcc5v0_sys>;
>> +		vcc9-supply = <&vcc5v0_sys>;
>> +		vcc10-supply = <&vcc5v0_sys>;
>> +		vcc11-supply = <&vcc_2v0_pldo_s3>;
>> +		vcc12-supply = <&vcc5v0_sys>;
>> +		vcc13-supply = <&vcc_2v0_pldo_s3>;
>> +		vcc14-supply = <&vcc_2v0_pldo_s3>;
>> +		vcca-supply = <&vcc5v0_sys>;
>> +
>> +		gpio-controller;
>> +		#gpio-cells = <2>;
>> +
>> +		rk806_dvs1_null: dvs1-null-pins {
>> +			pins = "gpio_pwrctrl2";
>> +			function = "pin_fun0";
>> +		};
>> +
>> +		rk806_dvs2_null: dvs2-null-pins {
>> +			pins = "gpio_pwrctrl2";
>> +			function = "pin_fun0";
>> +		};
>> +
>> +		rk806_dvs3_null: dvs3-null-pins {
>> +			pins = "gpio_pwrctrl3";
>> +			function = "pin_fun0";
>> +		};
>> +
>> +		regulators {
>> +			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <550000>;
>> +				regulator-max-microvolt = <950000>;
>> +				regulator-ramp-delay = <12500>;
>> +				regulator-name = "vdd_gpu_s0";
>> +				regulator-enable-ramp-delay = <400>;
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <550000>;
>> +				regulator-max-microvolt = <950000>;
>> +				regulator-ramp-delay = <12500>;
>> +				regulator-name = "vdd_cpu_lit_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			vdd_log_s0: dcdc-reg3 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <675000>;
>> +				regulator-max-microvolt = <750000>;
>> +				regulator-ramp-delay = <12500>;
>> +				regulator-name = "vdd_log_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +					regulator-suspend-microvolt = <750000>;
>> +				};
>> +			};
>> +
>> +			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <550000>;
>> +				regulator-max-microvolt = <950000>;
>> +				regulator-ramp-delay = <12500>;
>> +				regulator-name = "vdd_vdenc_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			vdd_ddr_s0: dcdc-reg5 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <675000>;
>> +				regulator-max-microvolt = <900000>;
>> +				regulator-ramp-delay = <12500>;
>> +				regulator-name = "vdd_ddr_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +					regulator-suspend-microvolt = <850000>;
>> +				};
>> +			};
>> +
>> +			vdd2_ddr_s3: dcdc-reg6 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-name = "vdd2_ddr_s3";
>> +
>> +				regulator-state-mem {
>> +					regulator-on-in-suspend;
>> +				};
>> +			};
>> +
>> +			vcc_2v0_pldo_s3: dcdc-reg7 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <2000000>;
>> +				regulator-max-microvolt = <2000000>;
>> +				regulator-ramp-delay = <12500>;
>> +				regulator-name = "vdd_2v0_pldo_s3";
>> +
>> +				regulator-state-mem {
>> +					regulator-on-in-suspend;
>> +					regulator-suspend-microvolt = <2000000>;
>> +				};
>> +			};
>> +
>> +			vcc_3v3_s3: dcdc-reg8 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <3300000>;
>> +				regulator-max-microvolt = <3300000>;
>> +				regulator-name = "vcc_3v3_s3";
>> +
>> +				regulator-state-mem {
>> +					regulator-on-in-suspend;
>> +					regulator-suspend-microvolt = <3300000>;
>> +				};
>> +			};
>> +
>> +			vddq_ddr_s0: dcdc-reg9 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-name = "vddq_ddr_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			vcc_1v8_s3: dcdc-reg10 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-name = "vcc_1v8_s3";
>> +
>> +				regulator-state-mem {
>> +					regulator-on-in-suspend;
>> +					regulator-suspend-microvolt = <1800000>;
>> +				};
>> +			};
>> +
>> +			avcc_1v8_s0: pldo-reg1 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-name = "avcc_1v8_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			vcc_1v8_s0: pldo-reg2 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-name = "vcc_1v8_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +					regulator-suspend-microvolt = <1800000>;
>> +				};
>> +			};
>> +
>> +			avdd_1v2_s0: pldo-reg3 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <1200000>;
>> +				regulator-max-microvolt = <1200000>;
>> +				regulator-name = "avdd_1v2_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			vcc_3v3_s0: pldo-reg4 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <3300000>;
>> +				regulator-max-microvolt = <3300000>;
>> +				regulator-ramp-delay = <12500>;
>> +				regulator-name = "vcc_3v3_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			vccio_sd_s0: pldo-reg5 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <3300000>;
>> +				regulator-ramp-delay = <12500>;
>> +				regulator-name = "vccio_sd_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			pldo6_s3: pldo-reg6 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-name = "pldo6_s3";
>> +
>> +				regulator-state-mem {
>> +					regulator-on-in-suspend;
>> +					regulator-suspend-microvolt = <1800000>;
>> +				};
>> +			};
>> +
>> +			vdd_0v75_s3: nldo-reg1 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <750000>;
>> +				regulator-max-microvolt = <750000>;
>> +				regulator-name = "vdd_0v75_s3";
>> +
>> +				regulator-state-mem {
>> +					regulator-on-in-suspend;
>> +					regulator-suspend-microvolt = <750000>;
>> +				};
>> +			};
>> +
>> +			vdd_ddr_pll_s0: nldo-reg2 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <850000>;
>> +				regulator-max-microvolt = <850000>;
>> +				regulator-name = "vdd_ddr_pll_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +					regulator-suspend-microvolt = <850000>;
>> +				};
>> +			};
>> +
>> +			avdd_0v75_s0: nldo-reg3 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <750000>;
>> +				regulator-max-microvolt = <750000>;
>> +				regulator-name = "avdd_0v75_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			vdd_0v85_s0: nldo-reg4 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <850000>;
>> +				regulator-max-microvolt = <850000>;
>> +				regulator-name = "vdd_0v85_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +
>> +			vdd_0v75_s0: nldo-reg5 {
>> +				regulator-always-on;
>> +				regulator-boot-on;
>> +				regulator-min-microvolt = <750000>;
>> +				regulator-max-microvolt = <750000>;
>> +				regulator-name = "vdd_0v75_s0";
>> +
>> +				regulator-state-mem {
>> +					regulator-off-in-suspend;
>> +				};
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&tsadc {
>> +	status = "okay";
>> +};
>> +
>> +&u2phy2 {
>> +	status = "okay";
>> +};
>> +
>> +&u2phy3 {
>> +	status = "okay";
>> +};
>> +
>> +&u2phy2_host {
>> +	phy-supply = <&vcc5v0_host>;
>> +	status = "okay";
>> +};
>> +
>> +&u2phy3_host {
>> +	phy-supply = <&vcc5v0_host>;
>> +	status = "okay";
>> +};
>> +
>> +&uart2 {
>> +	pinctrl-0 = <&uart2m0_xfer>;
>> +	status = "okay";
>> +};
>> +
>> +&usb_host0_ehci {
>> +	status = "okay";
>> +};
>> +
>> +&usb_host0_ohci {
>> +	status = "okay";
>> +};
>> +
>> +&usb_host1_ehci {
>> +	status = "okay";
>> +};
>> +
>> +&usb_host1_ohci {
>> +	status = "okay";
>> +};
>> 
>
>
>
>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

From broonie at kernel.org  Tue Dec 12 04:56:15 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 12 Dec 2023 12:56:15 +0000
Subject: [PATCH 06/13] arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion
 for DDI0601 2023-09
In-Reply-To: <CA+EHjTzswc6Qji6yaTcYu7uc57MFY-79KxY45wFT8tQ+9PEhPw@mail.gmail.com>
References: <20231209-b4-arm64-sysreg-additions-v1-0-45284e538474@kernel.org>
 <20231209-b4-arm64-sysreg-additions-v1-6-45284e538474@kernel.org>
 <CA+EHjTzdKS+ardXUofO+U1vnsOC3QjiJUBuKCHWw6z6zKdVGSA@mail.gmail.com>
 <20231212091047.GA28147@willie-the-truck>
 <CA+EHjTzswc6Qji6yaTcYu7uc57MFY-79KxY45wFT8tQ+9PEhPw@mail.gmail.com>
Message-ID: <6fc35f94-176e-4ad3-ab5b-79b57c36750a@sirena.org.uk>

On Tue, Dec 12, 2023 at 10:24:46AM +0000, Fuad Tabba wrote:

> > I renamed it to PAuth_LR following your comment, but it looks like
> > ID_AA64ISAR1_EL1 is still missing this field entirely for the API and
> > APA fields.

> I noticed that, but thought it's more appropriate to have a separate
> patch for that. I have one ready as part of my respin, unless we
> accumulate a bunch of sysreg update patches first.

Yes, syncing each register individually should make life easier.  It's
definitely painful when there's a multi-register update and one of the
registers has a mistake.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/3ca85621/attachment.sig>

From ardb at kernel.org  Tue Dec 12 04:59:31 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Tue, 12 Dec 2023 13:59:31 +0100
Subject: [PATCH v4 1/4] arm64: fpsimd: Drop unneeded 'busy' flag
In-Reply-To: <CAMuHMdVnqSpFUvT4wb4D=sHgBzQvhv_dWxn59scgUawoRAatNg@mail.gmail.com>
References: <20231208113218.3001940-6-ardb@google.com> <20231208113218.3001940-7-ardb@google.com>
 <CAMuHMdWewWJ1msJTcPNcbAf296gt+Kait3ECXjsJrSN+uerWyA@mail.gmail.com>
 <20231212122955.GA29310@willie-the-truck> <CAMuHMdVnqSpFUvT4wb4D=sHgBzQvhv_dWxn59scgUawoRAatNg@mail.gmail.com>
Message-ID: <CAMj1kXFhzbJRyWHELCivQW1yJaF=p07LLtbuyXYX3G1WtsdyQg@mail.gmail.com>

On Tue, 12 Dec 2023 at 13:34, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>
> Hi Will,
>
> On Tue, Dec 12, 2023 at 1:30?PM Will Deacon <will at kernel.org> wrote:
> > On Tue, Dec 12, 2023 at 12:27:50PM +0100, Geert Uytterhoeven wrote:
> > > On Fri, Dec 8, 2023 at 12:34?PM Ard Biesheuvel <ardb at google.com> wrote:
> > > > From: Ard Biesheuvel <ardb at kernel.org>
> > > > Kernel mode NEON will preserve the user mode FPSIMD state by saving it
> > > > into the task struct before clobbering the registers. In order to avoid
> > > > the need for preserving kernel mode state too, we disallow nested use of
> > > > kernel mode NEON, i..e, use in softirq context while the interrupted
> > > > task context was using kernel mode NEON too.
> > > >
> > > > Originally, this policy was implemented using a per-CPU flag which was
> > > > exposed via may_use_simd(), requiring the users of the kernel mode NEON
> > > > to deal with the possibility that it might return false, and having NEON
> > > > and non-NEON code paths. This policy was changed by commit
> > > > 13150149aa6ded1 ("arm64: fpsimd: run kernel mode NEON with softirqs
> > > > disabled"), and now, softirq processing is disabled entirely instead,
> > > > and so may_use_simd() can never fail when called from task or softirq
> > > > context.
> > > >
> > > > This means we can drop the fpsimd_context_busy flag entirely, and
> > > > instead, ensure that we disable softirq processing in places where we
> > > > formerly relied on the flag for preventing races in the FPSIMD preserve
> > > > routines.
> > > >
> > > > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > > > Reviewed-by: Mark Brown <broonie at kernel.org>
> > >
> > > Thanks for your patch, which is now commit e109130b0e5ec3fd
> > > ("arm64: fpsimd: Drop unneeded 'busy' flag") in arm64/for-next/core
> > > and next-20231212.
> > >
> > > I have bisected the following warning during boot (on Salvator-XS with
> > > R-Car H3 ES2.0 and on White-Hawk with R-Car V4H) followed by a lock-up
> > > (on Salvator-XS) to this commit:
> >
> > Please can you provide the output from the warning and, if possible, a
>
> Oops, how did that log disappear?
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at kernel/softirq.c:361 __local_bh_enable_ip+0x1a4/0x1c8
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 6.7.0-rc3-arm64-renesas-00001-ge109130b0e5e #2383
> Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
> pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : __local_bh_enable_ip+0x1a4/0x1c8
> lr : fpsimd_save_and_flush_cpu_state+0x4c/0x58
> sp : ffff800081703bb0
> x29: ffff800081703bb0 x28: ffff80008171c6b0 x27: ffff8000800167fc
> x26: 0000000000000000 x25: 0000000000000000 x24: ffff800081710a68
> x23: ffff8000813c4008 x22: ffff800081703ca4 x21: 0000000000000000
> x20: ffff8000800167c8 x19: 0000000000000200 x18: ffffffffffffffff
> x17: ffff0004c27f2400 x16: 0000000000000001 x15: 0000000000000003
> x14: 0000000000000000 x13: 0000000000000003 x12: 0000000000000000
> x11: 071c71c71c71c71c x10: ffff800082086b88 x9 : 0000000000000000
> x8 : ffff80008203ab50 x7 : 0000000000000bb0 x6 : ffff80008203b700
> x5 : ffff80067e2ee000 x4 : 0000000000000202 x3 : ffff80067e2ee000
> x2 : ffff80067e2ee000 x1 : ffff800081719fc0 x0 : 0000000100000202
> Call trace:
>  __local_bh_enable_ip+0x1a4/0x1c8
>  fpsimd_save_and_flush_cpu_state+0x4c/0x58
>  fpsimd_cpu_pm_notifier+0x1c/0x28
>  notifier_call_chain+0x9c/0x174
>  raw_notifier_call_chain_robust+0x40/0x98
>  cpu_pm_enter+0x3c/0x70
>  psci_enter_idle_state+0x28/0x78
>  cpuidle_enter_state+0xe4/0x568
>  cpuidle_enter+0x34/0x48
>  do_idle+0x214/0x290

Thanks for the report. I missed the fact that this is called from the
idle path. The old code just set and cleared the 'busy' flag there

Could you please check whether this fixes the issue? Thanks.

--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -1835,13 +1835,15 @@ static void fpsimd_flush_cpu_state(void)
  */
 void fpsimd_save_and_flush_cpu_state(void)
 {
+       unsigned long flags;
+
        if (!system_supports_fpsimd())
                return;
        WARN_ON(preemptible());
-       get_cpu_fpsimd_context();
+       local_irq_save(flags);
        fpsimd_save_user_state();
        fpsimd_flush_cpu_state();
-       put_cpu_fpsimd_context();
+       local_irq_restore(flags);
 }

 #ifdef CONFIG_KERNEL_MODE_NEON


From maxime.chevallier at bootlin.com  Tue Dec 12 05:10:26 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Tue, 12 Dec 2023 14:10:26 +0100
Subject: [RFC PATCH net-next v3 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <67557c83-4318-4557-ac96-858053b5f89b@lunn.ch>
References: <20231201163704.1306431-1-maxime.chevallier@bootlin.com>
	<20231201163704.1306431-2-maxime.chevallier@bootlin.com>
	<20231209170241.GA5817@kernel.org>
	<20231211120623.03b1ced4@device.home>
	<67557c83-4318-4557-ac96-858053b5f89b@lunn.ch>
Message-ID: <20231212141026.37e7af58@device.home>

On Mon, 11 Dec 2023 15:09:09 +0100
Andrew Lunn <andrew at lunn.ch> wrote:

> > > > @@ -10832,6 +10833,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
> > > >  #ifdef CONFIG_NET_SCHED
> > > >  	hash_init(dev->qdisc_hash);
> > > >  #endif
> > > > +	phy_link_topo_init(&dev->link_topo);
> > > > +    
> > > 
> > > I don't think this can work unless PHYLIB is compiled as a built-in.  
> > 
> > Inded, I need to better clarify and document the dependency with
> > PHYLIB.  
> 
> It is getting harder and harder to make the phylib core a module :-(
> 
> How much work does phy_link_topo_init() do? Could it be an inline
> function? Are there other dependencies?

Sorry about that, I'll make sure it works with phylib entirely disabled
for next version. I try to keep the integration with net_device minimal
and avoid any dependency bloat, we don't need much besides xarray stuff
(hence the fact there are 2 headers, the phy_link_topology_core.h
containing the bare minimum), but I did miss that.

> Also look at ethtool_phy_ops and e.g. how plca_get_cfg_prepare_data()
> uses it.

Thanks, indeed that's a good example. I'll also address that in the
netlink part as well.

Thanks,

Maxime


From Jiangfeng.Ma at synopsys.com  Tue Dec 12 05:15:06 2023
From: Jiangfeng.Ma at synopsys.com (Jiangfeng Ma)
Date: Tue, 12 Dec 2023 13:15:06 +0000
Subject: [PATCH] net:stmmac:stmmac_platform:Add snps,xpcs devicetree
 parsing
In-Reply-To: <SA0PR12MB4413305305D47CAAAFEAD528D98EA@SA0PR12MB4413.namprd12.prod.outlook.com>
References: <SA0PR12MB44138E48A245378CF54D2F9ED98AA@SA0PR12MB4413.namprd12.prod.outlook.com>
 <20231208091408.071680db@device.home>
 <uzss3af2cklc5bx5apszoegafeaaiv7o7iwgrgrml4grkyev6p@6tme4hdb4mkn>
 <SA0PR12MB4413305305D47CAAAFEAD528D98EA@SA0PR12MB4413.namprd12.prod.outlook.com>
Message-ID: <SA0PR12MB4413B8B6EDF08A1075E0B5AFD98EA@SA0PR12MB4413.namprd12.prod.outlook.com>



> -----Original Message-----
> From: Jiangfeng Ma
> Sent: Tuesday, December 12, 2023 6:51 PM
> To: Serge Semin <fancer.lancer at gmail.com>; Maxime Chevallier <maxime.chevallier at bootlin.com>
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>; Jose Abreu <joabreu at synopsys.com>; David
> S. Miller <davem at davemloft.net>; Eric Dumazet <edumazet at google.com>; Jakub Kicinski
> <kuba at kernel.org>; Paolo Abeni <pabeni at redhat.com>; Maxime Coquelin
> <mcoquelin.stm32 at gmail.com>; Simon Horman <horms at kernel.org>; Andrew Halaney
> <ahalaney at redhat.com>; Bartosz Golaszewski <bartosz.golaszewski at linaro.org>; Shenwei Wang
> <shenwei.wang at nxp.com>; Johannes Zink <j.zink at pengutronix.de>; Russell King (Oracle
> <rmk+kernel at armlinux.org.uk>; Jochen Henneberg <jh at henneberg-systemdesign.com>; open
> list:STMMAC ETHERNET DRIVER <netdev at vger.kernel.org>; moderated list:ARM/STM32
> ARCHITECTURE <linux-stm32 at st-md-mailman.stormreply.com>; moderated list:ARM/STM32
> ARCHITECTURE <linux-arm-kernel at lists.infradead.org>; open list <linux-kernel at vger.kernel.org>;
> James Li <lijames at synopsys.com>; Martin McKenny <mmckenny at synopsys.com>
> Subject: Re: [PATCH] net:stmmac:stmmac_platform:Add snps,xpcs devicetree parsing
> 
Sorry for the problem with my mail settings.
> 
> > -----Original Message-----
> > From: Serge Semin <fancer.lancer at gmail.com>
> > Sent: Friday, December 8, 2023 10:28 PM
> > To: Maxime Chevallier <maxime.chevallier at bootlin.com>; Jiangfeng Ma
> <jiama at synopsys.com>
> > Cc: Jiangfeng Ma <jiama at synopsys.com>; Alexandre Torgue <alexandre.torgue at foss.st.com>;
> Jose
> > Abreu <joabreu at synopsys.com>; David S. Miller <davem at davemloft.net>; Eric Dumazet
> > <edumazet at google.com>; Jakub Kicinski <kuba at kernel.org>; Paolo Abeni <pabeni at redhat.com>;
> > Maxime Coquelin <mcoquelin.stm32 at gmail.com>; Simon Horman <horms at kernel.org>; Andrew
> > Halaney <ahalaney at redhat.com>; Bartosz Golaszewski <bartosz.golaszewski at linaro.org>; Shenwei
> > Wang <shenwei.wang at nxp.com>; Johannes Zink <j.zink at pengutronix.de>; Russell King (Oracle
> > <rmk+kernel at armlinux.org.uk>; Jochen Henneberg <jh at henneberg-systemdesign.com>; open
> > list:STMMAC ETHERNET DRIVER <netdev at vger.kernel.org>; moderated list:ARM/STM32
> > ARCHITECTURE <linux-stm32 at st-md-mailman.stormreply.com>; moderated list:ARM/STM32
> > ARCHITECTURE <linux-arm-kernel at lists.infradead.org>; open list <linux-kernel at vger.kernel.org>;
> James
> > Li <lijames at synopsys.com>; Martin McKenny <mmckenny at synopsys.com>
> > Subject:  Re: [PATCH] net:stmmac:stmmac_platform:Add snps,xpcs devicetree parsing
> >
> Hi Maxime, Serge
> Thanks for your review!
> 
> > Hi Maxime, Jiangfeng
> >
> > On Fri, Dec 08, 2023 at 09:14:08AM +0100, Maxime Chevallier wrote:
> > > Hello,
> > >
> > > On Fri, 8 Dec 2023 07:02:19 +0000
> > > Jiangfeng Ma <Jiangfeng.Ma at synopsys.com> wrote:
> > >
> > > > In order to setup xpcs, has_xpcs must be set to a non-zero value.
> > > > Add new optional devicetree properties representing this.
> > > >
> > > > If has_xpcs is set to true, then xpcs_an_inband should preferably be
> > > > consistent with it, Otherwise, some errors may occur when starting
> > > > the network, For example, the phy interface that xpcs already supports,
> > > > but link up fails.
> > >
> > > Can you elaborate on why you need this, and on which platform
> > > especially ? Usually drivers for the various stmmac variants know if
> > > they have XPCS or not, or can guess it based on some info such as the
> > > configured PHY mode (dwmac-intel).
> 
> There is no specific platform here. I utilize the dwmcac-generic platform,
> and xpcs is utilized as the MDIO device or it can be seen as a C45 PHY.
> While it's sometimes possible to deduce the presence of xpcs based on information
> such as the phy mode (dwmac-intel), this is not always a definitive indicator.
> For instance, the support of SGMII by XPCS doesn't imply
> that all SGMII-supporting PHYs include XPCS. But as Serge mentioned, using pcs-handle,
> or pcs-handle-name might be a more effective approach.
> > >
> > > Besides that, there are a few issues with your submission. If DT is the
> > > way to go (and I don't say it is), you would also need to update the
> > > bindings to document that property.
> > >
> > > > The types of has_xpcs and xpcs_an_inband are unsigned int,
> > > > and generally used as flags. So it may be more reasonable to set them to
> > > > bool type. This can also be confirmed from the type of @ovr_an_inband.
> > >
> > > And this part would go into a separate patch.
> Sorry for this issue, I will create the patch separately later.
> >
> > In addition to what Maxime already said having DT-bindings adjusted to
> > fit to the pattern implemented in the software part is a wrong way to
> > go. The best choice in this case is to add the DW XPCS DT-node to the
> > DW MAC MDIO/MI bus and then use the "pcs-handle" to inform the MAC
> > (mainly it's driver) of what PCS-device is actually attached to it.
> > The series I submitted on this week is exactly about that:
> > https://urldefense.com/v3/__https://lore.kernel.org/netdev/20231205103559.9605-1-
> fancer.lancer at g
> > mail.com/__;!!A4F2R9G_pg!Y6R3WZWHeBdrkZklbqrAQARbHnQ-
> g_Tbb6r5IqcsSHMQ_l4rOzLLgZvLPl6YP
> > BYferbjrbjZA6_XvSSSvkV35eo2jWPz$
> > I guess I'll need about a month or so to settle all the comments, but
> > the solution implemented there will be better than this one really.
> >
> Yes, I agree that binding the xpcs via the "pcs-handle" DT firmware node
> is a better way. but the current method of binding xpcs through scanning
> addresses still relies on mdio_bus_data->has_xpcs.
> The 16th patch in your patchset also mentions the difficulty of
> obtaining has_xpcs. Therefore, can we add parsing of pcs-handle-names
> in the platform to determine if the xpcs exists, like this:
> 
> if (plat->mdio_bus_data) {
> 	rc = of_property_match_string(np, "pcs-handle-names", "dw-xpcs");
> 	if (rc >= 0) {
> 		plat->mdio_bus_data->has_xpcs = true;
> 		plat->mdio_bus_data->xpcs_an_inband = true;
> 	}
> }
> 
> Thanks,
> Jiangfeng
> 
> > -Serge(y)
> >
> > >
> > > Thanks,
> > >
> > > Maxime
> > >

From will at kernel.org  Tue Dec 12 05:26:51 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 13:26:51 +0000
Subject: [PATCH v2 5/5] iommu/arm-smmu: Convert to domain_alloc_paging()
In-Reply-To: <5-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <5-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
Message-ID: <20231212132651.GA29569@willie-the-truck>

On Tue, Oct 17, 2023 at 03:11:44PM -0300, Jason Gunthorpe wrote:
> Now that the BLOCKED and IDENTITY behaviors are managed with their own
> domains change to the domain_alloc_paging() op.
> 
> The check for using_legacy_binding is now redundant,
> arm_smmu_def_domain_type() always returns IOMMU_DOMAIN_IDENTITY for this
> mode, so the core code will never attempt to create a DMA domain in the
> first place.
> 
> Since commit a4fdd9762272 ("iommu: Use flush queue capability") the core
> code only passes in IDENTITY/BLOCKED/UNMANAGED/DMA domain types. It will
> not pass in IDENTITY or BLOCKED if the global statics exist, so the test
> for DMA is also redundant now too.
> 
> Call arm_smmu_init_domain_context() early if a dev is available.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu.c | 21 +++++++++++++++------
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 6340ee8ab7c482..cea25afe9e49db 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -842,14 +842,11 @@ static void arm_smmu_destroy_domain_context(struct arm_smmu_domain *smmu_domain)
>  	arm_smmu_rpm_put(smmu);
>  }
>  
> -static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> +static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
>  {
> +	struct arm_smmu_master_cfg *cfg = NULL;
>  	struct arm_smmu_domain *smmu_domain;
>  
> -	if (type != IOMMU_DOMAIN_UNMANAGED) {
> -		if (using_legacy_binding || type != IOMMU_DOMAIN_DMA)
> -			return NULL;
> -	}
>  	/*
>  	 * Allocate the domain and initialise some of its data structures.
>  	 * We can't really do anything meaningful until we've added a
> @@ -862,6 +859,18 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
>  	mutex_init(&smmu_domain->init_mutex);
>  	spin_lock_init(&smmu_domain->cb_lock);
>  
> +	if (dev)
> +		cfg = dev_iommu_priv_get(dev);
> +	if (cfg) {
> +		int ret;
> +
> +		ret = arm_smmu_init_domain_context(smmu_domain, cfg->smmu, dev);
> +		if (ret) {
> +			kfree(smmu_domain);
> +			return NULL;

If we're just returning NULL, can we drop 'ret'?

> +		}
> +	}
> +
>  	return &smmu_domain->domain;

Why do we need to handle the 'dev && !cfg' case here, instead of just
returning NULL?

Will


From will at kernel.org  Tue Dec 12 05:27:08 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 13:27:08 +0000
Subject: [PATCH v2 2/5] iommu/arm-smmu: Convert to a global static
 identity domain
In-Reply-To: <2-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <2-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
Message-ID: <20231212132708.GB29569@willie-the-truck>

On Tue, Oct 17, 2023 at 03:11:41PM -0300, Jason Gunthorpe wrote:
> Create a global static identity domain with it's own
> arm_smmu_attach_dev_identity() that simply calls
> arm_smmu_master_install_s2crs() with the identity parameters.
> 
> This is done by giving the attach path for identity its own unique
> implementation that simply calls arm_smmu_master_install_s2crs().
> 
> Remove ARM_SMMU_DOMAIN_BYPASS and all checks of IOMMU_DOMAIN_IDENTITY.
> 
> Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu.c | 50 ++++++++++++++++++++-------
>  drivers/iommu/arm/arm-smmu/arm-smmu.h |  1 -
>  2 files changed, 37 insertions(+), 14 deletions(-)

[...]

> +static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
> +					struct device *dev)
> +{
> +	struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
> +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> +	struct arm_smmu_device *smmu;
> +	int ret;
> +
> +	if (!cfg)
> +		return -ENODEV;
> +	smmu = cfg->smmu;
> +
> +	ret = arm_smmu_rpm_get(smmu);
> +	if (ret < 0)
> +		return ret;
> +
> +	arm_smmu_master_install_s2crs(cfg, S2CR_TYPE_BYPASS, 0, fwspec);
> +
> +	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
> +	pm_runtime_use_autosuspend(smmu->dev);

This is cargo-culted from arm_smmu_attach_dev() with the comments dropped
and it's not clear at all to me that the autosuspend delay makes any sense
for the identity domain.

So I think it would be better to either drop the call to
pm_runtime_set_autosuspend_delay() or move the two autosuspend calls into
a helper which is used by both of the attach routines so that the comment
is maintained.

Will


From angelogioacchino.delregno at collabora.com  Tue Dec 12 05:27:15 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 14:27:15 +0100
Subject: [PATCH v4 17/17] drm/mediatek: Add comments for the structures
In-Reply-To: <20231212121957.19231-18-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
 <20231212121957.19231-18-shawn.sung@mediatek.com>
Message-ID: <1e05cb3e-3ef2-45ca-9754-add6d0e185f0@collabora.com>

Il 12/12/23 13:19, Hsiao Chien Sung ha scritto:
> Add comments for the structures to improve readability.
> 
> Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
> ---
>   drivers/gpu/drm/mediatek/mtk_disp_ovl.c     | 21 +++++++++++++-
>   drivers/gpu/drm/mediatek/mtk_drm_crtc.c     | 22 ++++++++++++--
>   drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 32 +++++++++++++++++++++
>   drivers/gpu/drm/mediatek/mtk_drm_drv.h      | 15 ++++++++++
>   drivers/gpu/drm/mediatek/mtk_ethdr.c        | 11 +++++++
>   5 files changed, 97 insertions(+), 4 deletions(-)
> 

..snip..

> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 38d08796fae4..af80c9e50d36 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -46,6 +46,38 @@ enum mtk_ddp_comp_type {
>   
>   struct mtk_ddp_comp;
>   struct cmdq_pkt;
> +
> +/* struct mtk_ddp_comp_funcs - function pointers of the ddp components
> + * @clk_enable: enable the clocks of the component
> + * @clk_disable: disable the clocks of the component
> + * @config: configure the component
> + * @start: start (enable) the component
> + * @stop: stop (disable) the component
> + * @register_vblank_cb: to register a callback function when vblank irq occurs
> + * @unregister_vblank_cb: to unregister the callback function from the vblank irq
> + * @enable_vblank: enable vblank irq
> + * @disable_vblank: disable vblank irq
> + * @supported_rotations: return rotation capability of the component
> + * @layer_nr: how many layers the component supports
> + * @layer_check: to check if the state of the layer is valid for the component
> + * @layer_config: to configure the component according to the state of the layer
> + * @gamma_set: to set gamma for the component
> + * @bgclr_in_on: turn on background color
> + * @bgclr_in_off: turn off background color
> + * @ctm_set: set color transformation matrix
> + * @dma_dev_get: return the device that uses direct memory access
> + * @get_formats: get the format that is currently in use by the component
> + * @get_num_formats: get number of the formats that the component supports
> + * @connect: connect the sub modules of the component
> + * @disconnect: disconnect the sub modules of the component
> + * @add: add the device to the component (mount them in the mutex)
> + * @remove: remove the device from the component (unmount them from the mutex)
> + * @encoder_index: get the encoder index of the component
> + * @crc: return the start of crc array
> + * @crc_cnt: how many CRCs the component supports
> + * @crc_entry: get the pointer to the crc entry
> + * @crc_read: call this function to read crc from the hardware component
> + */
>   struct mtk_ddp_comp_funcs {
>   	int (*power_on)(struct device *dev);
>   	void (*power_off)(struct device *dev);

Please rebase over the latest upstream kernel, as it doesn't apply like this.

After which:
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Tue Dec 12 05:27:16 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 14:27:16 +0100
Subject: [PATCH v4 11/17] drm/mediatek: Turn off the layers with zero
 width or height
In-Reply-To: <20231212121957.19231-12-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
 <20231212121957.19231-12-shawn.sung@mediatek.com>
Message-ID: <315011be-59c6-42b1-be9b-cd2eaf6debd9@collabora.com>

Il 12/12/23 13:19, Hsiao Chien Sung ha scritto:
> We found that IGT (Intel GPU Tool) will try to commit layers with
> zero width or height and lead to undefined behaviors in hardware.
> Disable the layers in such situations.
> 
> Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>

This commit needs a Fixes tag. Please add the relevant one.

Thanks,
Angelo

> ---
>   drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 2 +-
>   drivers/gpu/drm/mediatek/mtk_ethdr.c            | 7 ++++++-
>   2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> index 10d23e76acaa..8789442c039f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> @@ -156,7 +156,7 @@ void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
>   	merge = ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_MERGE0 + idx];
>   	ethdr = ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0];
>   
> -	if (!pending->enable) {
> +	if (!pending->enable || !pending->width || !pending->height) {
>   		mtk_merge_stop_cmdq(merge, cmdq_pkt);
>   		mtk_mdp_rdma_stop(rdma_l, cmdq_pkt);
>   		mtk_mdp_rdma_stop(rdma_r, cmdq_pkt);
> diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c b/drivers/gpu/drm/mediatek/mtk_ethdr.c
> index 73c9e3da56a7..e95331c06815 100644
> --- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
> +++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
> @@ -163,7 +163,12 @@ void mtk_ethdr_layer_config(struct device *dev, unsigned int idx,
>   	if (idx >= 4)
>   		return;
>   
> -	if (!pending->enable) {
> +	if (!pending->enable || !pending->width || !pending->height) {
> +		/*
> +		 * instead of disabling layer with MIX_SRC_CON directly
> +		 * set the size to 0 to avoid screen shift due to mixer
> +		 * mode switch (hardware behavior)
> +		 */
>   		mtk_ddp_write(cmdq_pkt, 0, &mixer->cmdq_base, mixer->regs, MIX_L_SRC_SIZE(idx));
>   		return;
>   	}



From angelogioacchino.delregno at collabora.com  Tue Dec 12 05:27:20 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 14:27:20 +0100
Subject: [PATCH v4 05/17] drm/mediatek: Set DRM mode configs accordingly
In-Reply-To: <20231212121957.19231-6-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
 <20231212121957.19231-6-shawn.sung@mediatek.com>
Message-ID: <8f2c5728-0be2-415e-bccb-798c4a22e853@collabora.com>

Il 12/12/23 13:19, Hsiao Chien Sung ha scritto:
> Set DRM mode configs limitation accroding to the
> hardware capabilities.
> 
> Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
> ---
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 ++++++++++++++++++--------
>   drivers/gpu/drm/mediatek/mtk_drm_drv.h |  1 +
>   2 files changed, 21 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 5d551bff6b3f..a4b740420ebb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -304,6 +304,7 @@ static const struct mtk_mmsys_driver_data mt8188_vdosys0_driver_data = {
>   	.conn_routes = mt8188_mtk_ddp_main_routes,
>   	.conn_routes_num = ARRAY_SIZE(mt8188_mtk_ddp_main_routes),
>   	.mmsys_dev_num = 2,
> +	.max_pitch = GENMASK(15, 0),
>   };
>   
>   static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
> @@ -318,6 +319,7 @@ static const struct mtk_mmsys_driver_data mt8195_vdosys0_driver_data = {
>   	.main_path = mt8195_mtk_ddp_main,
>   	.main_len = ARRAY_SIZE(mt8195_mtk_ddp_main),
>   	.mmsys_dev_num = 2,
> +	.max_pitch = GENMASK(15, 0),
>   };
>   
>   static const struct mtk_mmsys_driver_data mt8195_vdosys1_driver_data = {
> @@ -325,6 +327,7 @@ static const struct mtk_mmsys_driver_data mt8195_vdosys1_driver_data = {
>   	.ext_len = ARRAY_SIZE(mt8195_mtk_ddp_ext),
>   	.mmsys_id = 1,
>   	.mmsys_dev_num = 2,
> +	.max_pitch = GENMASK(15, 0),
>   };
>   
>   static const struct of_device_id mtk_drm_of_ids[] = {
> @@ -463,16 +466,16 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>   	if (ret)
>   		goto put_mutex_dev;
>   
> -	drm->mode_config.min_width = 64;
> -	drm->mode_config.min_height = 64;
> -
>   	/*
> -	 * set max width and height as default value(4096x4096).
> -	 * this value would be used to check framebuffer size limitation
> -	 * at drm_mode_addfb().
> +	 * Set default values for drm mode config
> +	 * these values will be referenced by drm_mode_addfb() as
> +	 * frame buffer size limitation.
>   	 */
> -	drm->mode_config.max_width = 4096;
> -	drm->mode_config.max_height = 4096;
> +	drm->mode_config.min_width = 1;
> +	drm->mode_config.min_height = 1;
> +	drm->mode_config.cursor_width = 512;
> +	drm->mode_config.cursor_height = 512;
> +
>   	drm->mode_config.funcs = &mtk_drm_mode_config_funcs;
>   	drm->mode_config.helper_private = &mtk_drm_mode_config_helpers;
>   
> @@ -502,6 +505,15 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>   		for (j = 0; j < private->data->mmsys_dev_num; j++) {
>   			priv_n = private->all_drm_private[j];
>   
> +			if (priv_n->data->max_pitch) {
> +				/* Save 4 bytes for the color depth (pitch = width x bpp) */

This comment is confusing. Did you mean 4 *bits*? Four bytes is 32 bits.

Also, I'd change the last part to "(pitch = [ width or height ] x bpp)"

> +				drm->mode_config.max_width  = priv_n->data->max_pitch >> 2;
> +				drm->mode_config.max_height = priv_n->data->max_pitch >> 2;
> +			} else {
> +				drm->mode_config.max_width = 4096;
> +				drm->mode_config.max_height = 4096;
> +			}
> +
>   			if (i == 0 && priv_n->data->main_len) {
>   				ret = mtk_drm_crtc_create(drm, priv_n->data->main_path,
>   							  priv_n->data->main_len, j,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index d2efd715699f..3d6c1f58a7ec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -41,6 +41,7 @@ struct mtk_mmsys_driver_data {
>   	bool shadow_register;
>   	unsigned int mmsys_id;
>   	unsigned int mmsys_dev_num;
> +	u32 max_pitch;

Is it expected to have a max_pitch > 0xFFFF on newer SoCs?
If not, please change this to u16.

Regards,
Angelo


From angelogioacchino.delregno at collabora.com  Tue Dec 12 05:27:23 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 14:27:23 +0100
Subject: [PATCH v4 04/17] drm/mediatek: Add OVL compatible name for MT8195
In-Reply-To: <20231212121957.19231-5-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
 <20231212121957.19231-5-shawn.sung@mediatek.com>
Message-ID: <fbaa1652-8402-4f6e-9f68-fbe16c78ce73@collabora.com>

Il 12/12/23 13:19, Hsiao Chien Sung ha scritto:
> Add OVL compatible name for MT8195.
> 
> Without this commit, DRM won't work after modifying
> the device tree.
> 
> Reviewed-by: CK Hu <ck.hu at mediatek.com>
> Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Tue Dec 12 05:27:25 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 12 Dec 2023 14:27:25 +0100
Subject: [PATCH v4 03/17] dt-bindings: display: mediatek: ovl: Modify
 rules for MT8195/MT8188
In-Reply-To: <20231212121957.19231-4-shawn.sung@mediatek.com>
References: <20231212121957.19231-1-shawn.sung@mediatek.com>
 <20231212121957.19231-4-shawn.sung@mediatek.com>
Message-ID: <5d9e6f6c-604d-4e2d-a448-fc5b8bd24a75@collabora.com>

Il 12/12/23 13:19, Hsiao Chien Sung ha scritto:
> Modify rules for both MT8195 and MT8188.
> Hardware capabilities include color formats and AFBC are
> changed since MT8195, stop using the settings of MT8183.
> 
> Acked-by: Rob Herring <robh at kernel.org>
> Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From gregkh at linuxfoundation.org  Tue Dec 12 05:35:15 2023
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 12 Dec 2023 14:35:15 +0100
Subject: [GIT PULL] coresight: Updates for linux v6.8
In-Reply-To: <20231212121316.2804146-1-suzuki.poulose@arm.com>
References: <20231212121316.2804146-1-suzuki.poulose@arm.com>
Message-ID: <2023121204-subsoil-herring-1ff1@gregkh>

On Tue, Dec 12, 2023 at 12:13:16PM +0000, Suzuki K Poulose wrote:
> Hi Greg
> 
> Please find the updates for coresight and hwtracing subsystems targeting
> Linux v6.8. Please note that the branch is based on the stable tag,
> "coresight-fixes-for-v6.7-rc1" (which was merged in v6.7-rc5, on v6.7-rc1).
> 
>  i.e, coresight-next-v6.8....coresight-fixes-for-v6.7-rc1...v6.7-rc1
> 
> 
> Kindly pull
> 
> Suzuki
> 
> The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
> 
>   Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.8

Pulled and pushed out, thanks.

greg k-h


From u.kleine-koenig at pengutronix.de  Tue Dec 12 05:41:10 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 14:41:10 +0100
Subject: [PATCH v2] arm64: dts: imx8mq-kontron-pitx-imx8m: remove
 vqmmc-supply node
In-Reply-To: <CAEyMn7aYYkGZ1Eawd=yazdKeBuHVQc=3F7PnHSCSRyYCu=CJ9A@mail.gmail.com>
References: <20210914072627.24173-1-heiko.thiery@gmail.com>
 <449f718706fd5af03190bdda986de37aa8fa14e3.camel@pengutronix.de>
 <79fb60ea9a002ea553a92ea08b28b866@walle.cc>
 <2dc72116ec935a5a5d7a1a176868b7af7ff3227c.camel@pengutronix.de>
 <9e3d52c297ed024594a1e610a5cf61b2@walle.cc>
 <CAEyMn7aYYkGZ1Eawd=yazdKeBuHVQc=3F7PnHSCSRyYCu=CJ9A@mail.gmail.com>
Message-ID: <20231212134110.cijyajgwljkzovvo@pengutronix.de>

Hello Heiko,

On Tue, Sep 14, 2021 at 11:37:04AM +0200, Heiko Thiery wrote:
> dependency between emmc and PMIC. Debian 11 unfortunately does not
> have a driver enabled for the PMIC used and therefore cannot
> initialize the emmc driver.

Updating to Debian 12 should give you a kernel that supports the
pfuze100 driver. (But I guess you know that, because it was enabled by
someone named Heiko Thiery. :-)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/8af402b1/attachment.sig>

From ulf.hansson at linaro.org  Tue Dec 12 05:42:23 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 12 Dec 2023 14:42:23 +0100
Subject: [PATCH] PM: domains: Drop the unused pm_genpd_opp_to_performance_state()
In-Reply-To: <CAJZ5v0jxMjb-bUbJiHgehe5xJ6cwspvsRp5P_2N6FyvRFshJQA@mail.gmail.com>
References: <20231127151931.47055-1-ulf.hansson@linaro.org>
 <CAJZ5v0jXRNDV7AhZPkrDvMtrk6cYeMJ+HuUs0kJ=kjbQ-YiyVA@mail.gmail.com>
 <CAPDyKFpJ6_+nF8q3L4Tg1E9St3stgJ06se0t=FLHkx4_36OJNA@mail.gmail.com> <CAJZ5v0jxMjb-bUbJiHgehe5xJ6cwspvsRp5P_2N6FyvRFshJQA@mail.gmail.com>
Message-ID: <CAPDyKFobQ7dYb6SBD5tmxcK-u0w1mdQxBhY10GVNVgHj3aYNGA@mail.gmail.com>

On Tue, 12 Dec 2023 at 12:59, Rafael J. Wysocki <rafael at kernel.org> wrote:
>
> On Tue, Dec 12, 2023 at 11:37?AM Ulf Hansson <ulf.hansson at linaro.org> wrote:
> >
> > On Mon, 11 Dec 2023 at 21:44, Rafael J. Wysocki <rafael at kernel.org> wrote:
> > >
> > > On Mon, Nov 27, 2023 at 4:19?PM Ulf Hansson <ulf.hansson at linaro.org> wrote:
> > > >
> > > > Since commit 7c41cdcd3bbe ("OPP: Simplify the over-designed pstate <->
> > > > level dance"), there is no longer any users of the
> > > > pm_genpd_opp_to_performance_state() API. Let's therefore drop it and its
> > > > corresponding ->opp_to_performance_state() callback, which also no longer
> > > > has any users.
> > > >
> > > > Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> > >
> > > I can take this in principle, but I'm wondering if you'd prefer to
> > > apply patches modifying domain.c yourself?  They are definitely
> > > related to the pmdomain tree.
> >
> > Yes, it makes sense for me to pick the genpd core patches through the
> > pmdomain tree. In some cases there may be overlapping patches that are
> > more generic and not only limited to genpd, but I guess we can decide
> > on a case by case basis for those ones.
> >
> > I can add the pmdomain tree to the GENERIC PM DOMAINS section in the
> > MAINTAINERS file to reflect this, if you think this is a good idea?
>
> Yes, please.
>
> What about moving drivers/base/power/domain.c to drivers/pmdomain/ ?

Yes, it seems reasonable to do that too. I will send a patch for you
to have a look at shortly.

Kind regards
Uffe


From festevam at gmail.com  Tue Dec 12 05:44:45 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 12 Dec 2023 10:44:45 -0300
Subject: [PATCH] ARM: dts: nxp: imx7d-pico: add cpu-supply nodes
In-Reply-To: <5b285fdd-9d69-400c-978f-234665fca73e@gmail.com>
References: <20231117232352.101713-1-lech.perczak@gmail.com>
 <20231206013247.GY236001@dragon> <5b285fdd-9d69-400c-978f-234665fca73e@gmail.com>
Message-ID: <CAOMZO5Bd+mVV0BQPgUD+45M6SKQ-txN7uJTgMrh5wtZXFXZtWw@mail.gmail.com>

Hi Lech,

On Mon, Dec 11, 2023 at 7:41?PM Lech Perczak <lech.perczak at gmail.com> wrote:

> Hi Shawn,
>
> Do you think this could be backported to stable later?
> OpenWrt and Debian could then pick this change up - I have a pull
> request open in OpenWrt backporting this.

As your patch is not a bug fix, it does not qualify to be backported
to linux-stable.

Please check the stable kernel rules at:
https://github.com/torvalds/linux/blob/master/Documentation/process/stable-kernel-rules.rst


From james.clark at arm.com  Tue Dec 12 05:54:21 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 13:54:21 +0000
Subject: [PATCH v1 05/14] libperf cpumap: Add for_each_cpu that skips the
 "any CPU" case
In-Reply-To: <20231129060211.1890454-6-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-6-irogers@google.com>
Message-ID: <bfb1936a-7f91-089e-c8c4-f27824779fde@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> When iterating CPUs in a CPU map it is often desirable to skip the
> "any CPU" (aka dummy) case. Add a helper for this and use in
> builtin-record.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>

Reviewed-by: James Clark <james.clark at arm.com>

> ---
>  tools/lib/perf/include/perf/cpumap.h | 6 ++++++
>  tools/perf/builtin-record.c          | 4 +---
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> index 9cf361fc5edc..dbe0a7352b64 100644
> --- a/tools/lib/perf/include/perf/cpumap.h
> +++ b/tools/lib/perf/include/perf/cpumap.h
> @@ -64,6 +64,12 @@ LIBPERF_API bool perf_cpu_map__has_any_cpu(const struct perf_cpu_map *map);
>  	     (idx) < perf_cpu_map__nr(cpus);			\
>  	     (idx)++, (cpu) = perf_cpu_map__cpu(cpus, idx))
>  
> +#define perf_cpu_map__for_each_cpu_skip_any(_cpu, idx, cpus)	\
> +	for ((idx) = 0, (_cpu) = perf_cpu_map__cpu(cpus, idx);	\
> +	     (idx) < perf_cpu_map__nr(cpus);			\
> +	     (idx)++, (_cpu) = perf_cpu_map__cpu(cpus, idx))	\
> +		if ((_cpu).cpu != -1)
> +
>  #define perf_cpu_map__for_each_idx(idx, cpus)				\
>  	for ((idx) = 0; (idx) < perf_cpu_map__nr(cpus); (idx)++)
>  
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 8ec818568662..066f9232e947 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -3580,9 +3580,7 @@ static int record__mmap_cpu_mask_init(struct mmap_cpu_mask *mask, struct perf_cp
>  	if (cpu_map__is_dummy(cpus))
>  		return 0;
>  
> -	perf_cpu_map__for_each_cpu(cpu, idx, cpus) {
> -		if (cpu.cpu == -1)
> -			continue;
> +	perf_cpu_map__for_each_cpu_skip_any(cpu, idx, cpus) {
>  		/* Return ENODEV is input cpu is greater than max cpu */
>  		if ((unsigned long)cpu.cpu > mask->nbits)
>  			return -ENODEV;


From geert at linux-m68k.org  Tue Dec 12 05:54:33 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 12 Dec 2023 14:54:33 +0100
Subject: [PATCH v4 1/4] arm64: fpsimd: Drop unneeded 'busy' flag
In-Reply-To: <CAMj1kXFhzbJRyWHELCivQW1yJaF=p07LLtbuyXYX3G1WtsdyQg@mail.gmail.com>
References: <20231208113218.3001940-6-ardb@google.com> <20231208113218.3001940-7-ardb@google.com>
 <CAMuHMdWewWJ1msJTcPNcbAf296gt+Kait3ECXjsJrSN+uerWyA@mail.gmail.com>
 <20231212122955.GA29310@willie-the-truck> <CAMuHMdVnqSpFUvT4wb4D=sHgBzQvhv_dWxn59scgUawoRAatNg@mail.gmail.com>
 <CAMj1kXFhzbJRyWHELCivQW1yJaF=p07LLtbuyXYX3G1WtsdyQg@mail.gmail.com>
Message-ID: <CAMuHMdWca4Mhuqg90b5zJhRJ+HneNjzHtXC3w24_k=t182ryfw@mail.gmail.com>

Hi Ard,

On Tue, Dec 12, 2023 at 1:59?PM Ard Biesheuvel <ardb at kernel.org> wrote:
> On Tue, 12 Dec 2023 at 13:34, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > On Tue, Dec 12, 2023 at 1:30?PM Will Deacon <will at kernel.org> wrote:
> > > On Tue, Dec 12, 2023 at 12:27:50PM +0100, Geert Uytterhoeven wrote:
> > > > On Fri, Dec 8, 2023 at 12:34?PM Ard Biesheuvel <ardb at google.com> wrote:
> > > > > From: Ard Biesheuvel <ardb at kernel.org>
> > > > > Kernel mode NEON will preserve the user mode FPSIMD state by saving it
> > > > > into the task struct before clobbering the registers. In order to avoid
> > > > > the need for preserving kernel mode state too, we disallow nested use of
> > > > > kernel mode NEON, i..e, use in softirq context while the interrupted
> > > > > task context was using kernel mode NEON too.
> > > > >
> > > > > Originally, this policy was implemented using a per-CPU flag which was
> > > > > exposed via may_use_simd(), requiring the users of the kernel mode NEON
> > > > > to deal with the possibility that it might return false, and having NEON
> > > > > and non-NEON code paths. This policy was changed by commit
> > > > > 13150149aa6ded1 ("arm64: fpsimd: run kernel mode NEON with softirqs
> > > > > disabled"), and now, softirq processing is disabled entirely instead,
> > > > > and so may_use_simd() can never fail when called from task or softirq
> > > > > context.
> > > > >
> > > > > This means we can drop the fpsimd_context_busy flag entirely, and
> > > > > instead, ensure that we disable softirq processing in places where we
> > > > > formerly relied on the flag for preventing races in the FPSIMD preserve
> > > > > routines.
> > > > >
> > > > > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > > > > Reviewed-by: Mark Brown <broonie at kernel.org>
> > > >
> > > > Thanks for your patch, which is now commit e109130b0e5ec3fd
> > > > ("arm64: fpsimd: Drop unneeded 'busy' flag") in arm64/for-next/core
> > > > and next-20231212.
> > > >
> > > > I have bisected the following warning during boot (on Salvator-XS with
> > > > R-Car H3 ES2.0 and on White-Hawk with R-Car V4H) followed by a lock-up
> > > > (on Salvator-XS) to this commit:
> > >
> > > Please can you provide the output from the warning and, if possible, a
> >
> > Oops, how did that log disappear?
> >
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 0 at kernel/softirq.c:361 __local_bh_enable_ip+0x1a4/0x1c8
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> > 6.7.0-rc3-arm64-renesas-00001-ge109130b0e5e #2383
> > Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
> > pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : __local_bh_enable_ip+0x1a4/0x1c8
> > lr : fpsimd_save_and_flush_cpu_state+0x4c/0x58
> > sp : ffff800081703bb0
> > x29: ffff800081703bb0 x28: ffff80008171c6b0 x27: ffff8000800167fc
> > x26: 0000000000000000 x25: 0000000000000000 x24: ffff800081710a68
> > x23: ffff8000813c4008 x22: ffff800081703ca4 x21: 0000000000000000
> > x20: ffff8000800167c8 x19: 0000000000000200 x18: ffffffffffffffff
> > x17: ffff0004c27f2400 x16: 0000000000000001 x15: 0000000000000003
> > x14: 0000000000000000 x13: 0000000000000003 x12: 0000000000000000
> > x11: 071c71c71c71c71c x10: ffff800082086b88 x9 : 0000000000000000
> > x8 : ffff80008203ab50 x7 : 0000000000000bb0 x6 : ffff80008203b700
> > x5 : ffff80067e2ee000 x4 : 0000000000000202 x3 : ffff80067e2ee000
> > x2 : ffff80067e2ee000 x1 : ffff800081719fc0 x0 : 0000000100000202
> > Call trace:
> >  __local_bh_enable_ip+0x1a4/0x1c8
> >  fpsimd_save_and_flush_cpu_state+0x4c/0x58
> >  fpsimd_cpu_pm_notifier+0x1c/0x28
> >  notifier_call_chain+0x9c/0x174
> >  raw_notifier_call_chain_robust+0x40/0x98
> >  cpu_pm_enter+0x3c/0x70
> >  psci_enter_idle_state+0x28/0x78
> >  cpuidle_enter_state+0xe4/0x568
> >  cpuidle_enter+0x34/0x48
> >  do_idle+0x214/0x290
>
> Thanks for the report. I missed the fact that this is called from the
> idle path. The old code just set and cleared the 'busy' flag there
>
> Could you please check whether this fixes the issue? Thanks.

Thanks, that fixed the issue!

Tested-by: Geert Uytterhoeven <geert+renesas at glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From james.clark at arm.com  Tue Dec 12 06:00:55 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 14:00:55 +0000
Subject: [PATCH v1 06/14] libperf cpumap: Add any, empty and min helpers
In-Reply-To: <20231129060211.1890454-7-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-7-irogers@google.com>
Message-ID: <63d7fe55-719e-43f8-531c-eb7fa30c473a@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> Additional helpers to better replace
> perf_cpu_map__has_any_cpu_or_is_empty.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>
> ---
>  tools/lib/perf/cpumap.c              | 27 +++++++++++++++++++++++++++
>  tools/lib/perf/include/perf/cpumap.h | 16 ++++++++++++++++
>  tools/lib/perf/libperf.map           |  4 ++++
>  3 files changed, 47 insertions(+)
> 
> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
> index 49fc98e16514..7403819da8fd 100644
> --- a/tools/lib/perf/cpumap.c
> +++ b/tools/lib/perf/cpumap.c
> @@ -316,6 +316,19 @@ bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map)
>  	return map ? __perf_cpu_map__cpu(map, 0).cpu == -1 : true;
>  }
>  
> +bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map)
> +{
> +	if (!map)
> +		return true;
> +
> +	return __perf_cpu_map__nr(map) == 1 && __perf_cpu_map__cpu(map, 0).cpu == -1;
> +}
> +
> +bool perf_cpu_map__is_empty(const struct perf_cpu_map *map)
> +{
> +	return map == NULL;
> +}
> +

Maybe it doesn't currently happen, but it seems a bit weird that the
'new' function can create a map of length 0 which would return empty ==
false here.

Could we either make this check also return true for maps with length 0,
or prevent the new function from returning a map of 0 length?

>  int perf_cpu_map__idx(const struct perf_cpu_map *cpus, struct perf_cpu cpu)
>  {
>  	int low, high;
> @@ -372,6 +385,20 @@ bool perf_cpu_map__has_any_cpu(const struct perf_cpu_map *map)
>  	return map && __perf_cpu_map__cpu(map, 0).cpu == -1;
>  }
>  
> +struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map)
> +{
> +	struct perf_cpu cpu, result = {
> +		.cpu = -1
> +	};
> +	int idx;
> +
> +	perf_cpu_map__for_each_cpu_skip_any(cpu, idx, map) {
> +		result = cpu;
> +		break;
> +	}
> +	return result;
> +}
> +
>  struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map)
>  {
>  	struct perf_cpu result = {
> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> index dbe0a7352b64..523e4348fc96 100644
> --- a/tools/lib/perf/include/perf/cpumap.h
> +++ b/tools/lib/perf/include/perf/cpumap.h
> @@ -50,6 +50,22 @@ LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
>   * perf_cpu_map__has_any_cpu_or_is_empty - is map either empty or has the "any CPU"/dummy value.
>   */
>  LIBPERF_API bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map);
> +/**
> + * perf_cpu_map__is_any_cpu_or_is_empty - is map either empty or the "any CPU"/dummy value.
> + */
> +LIBPERF_API bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map);
> +/**
> + * perf_cpu_map__is_empty - does the map contain no values and it doesn't
> + *                          contain the special "any CPU"/dummy value.
> + */
> +LIBPERF_API bool perf_cpu_map__is_empty(const struct perf_cpu_map *map);
> +/**
> + * perf_cpu_map__min - the minimum CPU value or -1 if empty or just the "any CPU"/dummy value.
> + */
> +LIBPERF_API struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map);
> +/**
> + * perf_cpu_map__max - the maximum CPU value or -1 if empty or just the "any CPU"/dummy value.
> + */
>  LIBPERF_API struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map);
>  LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, struct perf_cpu cpu);
>  LIBPERF_API bool perf_cpu_map__equal(const struct perf_cpu_map *lhs,
> diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> index 10b3f3722642..2aa79b696032 100644
> --- a/tools/lib/perf/libperf.map
> +++ b/tools/lib/perf/libperf.map
> @@ -10,6 +10,10 @@ LIBPERF_0.0.1 {
>  		perf_cpu_map__nr;
>  		perf_cpu_map__cpu;
>  		perf_cpu_map__has_any_cpu_or_is_empty;
> +		perf_cpu_map__is_any_cpu_or_is_empty;
> +		perf_cpu_map__is_empty;
> +		perf_cpu_map__has_any_cpu;
> +		perf_cpu_map__min;
>  		perf_cpu_map__max;
>  		perf_cpu_map__has;
>  		perf_thread_map__new_array;


From jgg at nvidia.com  Tue Dec 12 06:03:07 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 12 Dec 2023 10:03:07 -0400
Subject: [PATCH v2 5/5] iommu/arm-smmu: Convert to domain_alloc_paging()
In-Reply-To: <20231212132651.GA29569@willie-the-truck>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <5-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <20231212132651.GA29569@willie-the-truck>
Message-ID: <20231212140307.GD3014157@nvidia.com>

On Tue, Dec 12, 2023 at 01:26:51PM +0000, Will Deacon wrote:
> > @@ -862,6 +859,18 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> >  	mutex_init(&smmu_domain->init_mutex);
> >  	spin_lock_init(&smmu_domain->cb_lock);
> >  
> > +	if (dev)
> > +		cfg = dev_iommu_priv_get(dev);
> > +	if (cfg) {
> > +		int ret;
> > +
> > +		ret = arm_smmu_init_domain_context(smmu_domain, cfg->smmu, dev);
> > +		if (ret) {
> > +			kfree(smmu_domain);
> > +			return NULL;
> 
> If we're just returning NULL, can we drop 'ret'?

It is waiting to be changed to ERR_PTR. The dependent patches are
merged to rc5 now, so I can fix it in v3.

> > +		}
> > +	}
> > +
> >  	return &smmu_domain->domain;
> 
> Why do we need to handle the 'dev && !cfg' case here, instead g
> returning NULL?

dev && !cfg is impossible these days, so we can shuffle the if and
then just crash on that case like the other drivers do.

Jason


From Jianheng.Zhang at synopsys.com  Tue Dec 12 06:05:02 2023
From: Jianheng.Zhang at synopsys.com (Jianheng Zhang)
Date: Tue, 12 Dec 2023 14:05:02 +0000
Subject: [PATCH v2 net-next] net: stmmac: xgmac3+: add FPE handshaking support
Message-ID: <CY5PR12MB63727C24923AE855CFF0D425BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com>

Adds the HW specific support for Frame Preemption handshaking on XGMAC3+
cores.

Signed-off-by: Jianheng Zhang <Jianheng.Zhang at synopsys.com>
---
v2:
  - updating the FPE debug message to use netdev_dbg()
v1: https://lore.kernel.org/all/CY5PR12MB63726FED738099761A9B81E7BF8FA at CY5PR12MB6372.namprd12.prod.outlook.com/
---
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h     |  6 ++
 .../net/ethernet/stmicro/stmmac/dwxgmac2_core.c    | 66 ++++++++++++++++++----
 2 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 207ff17..306d15b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -194,6 +194,12 @@
 #define XGMAC_MDIO_DATA			0x00000204
 #define XGMAC_MDIO_C22P			0x00000220
 #define XGMAC_FPE_CTRL_STS		0x00000280
+#define XGMAC_TRSP			BIT(19)
+#define XGMAC_TVER			BIT(18)
+#define XGMAC_RRSP			BIT(17)
+#define XGMAC_RVER			BIT(16)
+#define XGMAC_SRSP			BIT(2)
+#define XGMAC_SVER			BIT(1)
 #define XGMAC_EFPE			BIT(0)
 #define XGMAC_ADDRx_HIGH(x)		(0x00000300 + (x) * 0x8)
 #define XGMAC_ADDR_MAX			32
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index eb48211..2f14f9b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -1439,22 +1439,64 @@ static void dwxgmac3_fpe_configure(void __iomem *ioaddr, struct stmmac_fpe_cfg *
 {
 	u32 value;
 
-	if (!enable) {
-		value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
+	if (enable) {
+		cfg->fpe_csr = XGMAC_EFPE;
+		value = readl(ioaddr + XGMAC_RXQ_CTRL1);
+		value &= ~XGMAC_RQ;
+		value |= (num_rxq - 1) << XGMAC_RQ_SHIFT;
+		writel(value, ioaddr + XGMAC_RXQ_CTRL1);
+	} else {
+		cfg->fpe_csr = 0;
+	}
+	writel(cfg->fpe_csr, ioaddr + XGMAC_FPE_CTRL_STS);
+}
 
-		value &= ~XGMAC_EFPE;
+static int dwxgmac3_fpe_irq_status(void __iomem *ioaddr, struct net_device *dev)
+{
+	u32 value;
+	int status;
 
-		writel(value, ioaddr + XGMAC_FPE_CTRL_STS);
-		return;
+	status = FPE_EVENT_UNKNOWN;
+
+	/* Reads from the XGMAC_FPE_CTRL_STS register should only be performed
+	 * here, since the status flags of MAC_FPE_CTRL_STS are "clear on read"
+	 */
+	value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
+
+	if (value & XGMAC_TRSP) {
+		status |= FPE_EVENT_TRSP;
+		netdev_dbg(dev, "FPE: Respond mPacket is transmitted\n");
 	}
 
-	value = readl(ioaddr + XGMAC_RXQ_CTRL1);
-	value &= ~XGMAC_RQ;
-	value |= (num_rxq - 1) << XGMAC_RQ_SHIFT;
-	writel(value, ioaddr + XGMAC_RXQ_CTRL1);
+	if (value & XGMAC_TVER) {
+		status |= FPE_EVENT_TVER;
+		netdev_dbg(dev, "FPE: Verify mPacket is transmitted\n");
+	}
+
+	if (value & XGMAC_RRSP) {
+		status |= FPE_EVENT_RRSP;
+		netdev_dbg(dev, "FPE: Respond mPacket is received\n");
+	}
+
+	if (value & XGMAC_RVER) {
+		status |= FPE_EVENT_RVER;
+		netdev_dbg(dev, "FPE: Verify mPacket is received\n");
+	}
+
+	return status;
+}
+
+static void dwxgmac3_fpe_send_mpacket(void __iomem *ioaddr,
+				      struct stmmac_fpe_cfg *cfg,
+				      enum stmmac_mpacket_type type)
+{
+	u32 value = cfg->fpe_csr;
+
+	if (type == MPACKET_VERIFY)
+		value |= XGMAC_SVER;
+	else if (type == MPACKET_RESPONSE)
+		value |= XGMAC_SRSP;
 
-	value = readl(ioaddr + XGMAC_FPE_CTRL_STS);
-	value |= XGMAC_EFPE;
 	writel(value, ioaddr + XGMAC_FPE_CTRL_STS);
 }
 
@@ -1503,6 +1545,8 @@ static void dwxgmac3_fpe_configure(void __iomem *ioaddr, struct stmmac_fpe_cfg *
 	.config_l4_filter = dwxgmac2_config_l4_filter,
 	.set_arp_offload = dwxgmac2_set_arp_offload,
 	.fpe_configure = dwxgmac3_fpe_configure,
+	.fpe_send_mpacket = dwxgmac3_fpe_send_mpacket,
+	.fpe_irq_status = dwxgmac3_fpe_irq_status,
 };
 
 static void dwxlgmac2_rx_queue_enable(struct mac_device_info *hw, u8 mode,
-- 
1.8.3.1



From will at kernel.org  Tue Dec 12 06:10:23 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 14:10:23 +0000
Subject: [PATCH v2 5/5] iommu/arm-smmu: Convert to domain_alloc_paging()
In-Reply-To: <20231212140307.GD3014157@nvidia.com>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <5-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <20231212132651.GA29569@willie-the-truck>
 <20231212140307.GD3014157@nvidia.com>
Message-ID: <20231212141023.GA29699@willie-the-truck>

On Tue, Dec 12, 2023 at 10:03:07AM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 12, 2023 at 01:26:51PM +0000, Will Deacon wrote:
> > > @@ -862,6 +859,18 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> > >  	mutex_init(&smmu_domain->init_mutex);
> > >  	spin_lock_init(&smmu_domain->cb_lock);
> > >  
> > > +	if (dev)
> > > +		cfg = dev_iommu_priv_get(dev);
> > > +	if (cfg) {
> > > +		int ret;
> > > +
> > > +		ret = arm_smmu_init_domain_context(smmu_domain, cfg->smmu, dev);
> > > +		if (ret) {
> > > +			kfree(smmu_domain);
> > > +			return NULL;
> > 
> > If we're just returning NULL, can we drop 'ret'?
> 
> It is waiting to be changed to ERR_PTR. The dependent patches are
> merged to rc5 now, so I can fix it in v3.

Sorry, I missed that. You can leave it as-is, since my SMMU branch is based
on -rc3.

> > > +		}
> > > +	}
> > > +
> > >  	return &smmu_domain->domain;
> > 
> > Why do we need to handle the 'dev && !cfg' case here, instead g
> > returning NULL?
> 
> dev && !cfg is impossible these days, so we can shuffle the if and
> then just crash on that case like the other drivers do.

Thanks, that would simplify it a little.

Will


From jgg at nvidia.com  Tue Dec 12 06:15:16 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 12 Dec 2023 10:15:16 -0400
Subject: [PATCH v2 2/5] iommu/arm-smmu: Convert to a global static
 identity domain
In-Reply-To: <20231212132708.GB29569@willie-the-truck>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <2-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <20231212132708.GB29569@willie-the-truck>
Message-ID: <20231212141516.GE3014157@nvidia.com>

On Tue, Dec 12, 2023 at 01:27:08PM +0000, Will Deacon wrote:
> > +static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
> > +					struct device *dev)
> > +{
> > +	struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
> > +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > +	struct arm_smmu_device *smmu;
> > +	int ret;
> > +
> > +	if (!cfg)
> > +		return -ENODEV;
> > +	smmu = cfg->smmu;
> > +
> > +	ret = arm_smmu_rpm_get(smmu);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	arm_smmu_master_install_s2crs(cfg, S2CR_TYPE_BYPASS, 0, fwspec);
> > +
> > +	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
> > +	pm_runtime_use_autosuspend(smmu->dev);
> 
> This is cargo-culted from arm_smmu_attach_dev() with the comments dropped
> and it's not clear at all to me that the autosuspend delay makes any sense
> for the identity domain.

Indeed, however it was how it worked before this split up.

> So I think it would be better to either drop the call to
> pm_runtime_set_autosuspend_delay() 

I looked through it more carefully and this does seem like the right
thing, so I will drop them.

Thanks,
Jason


From james.clark at arm.com  Tue Dec 12 06:17:25 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 14:17:25 +0000
Subject: [PATCH v1 07/14] perf arm-spe/cs-etm: Directly iterate CPU maps
In-Reply-To: <20231129060211.1890454-8-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-8-irogers@google.com>
Message-ID: <e3a01313-ed03-bc54-0260-5445fb2c15ee@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> Rather than iterate all CPUs and see if they are in CPU maps, directly
> iterate the CPU map. Similarly make use of the intersect
> function. Switch perf_cpu_map__has_any_cpu_or_is_empty to more
> appropriate alternatives.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>
> ---
>  tools/perf/arch/arm/util/cs-etm.c    | 77 ++++++++++++----------------
>  tools/perf/arch/arm64/util/arm-spe.c |  4 +-
>  2 files changed, 34 insertions(+), 47 deletions(-)
> 
> diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
> index 77e6663c1703..a68a72f2f668 100644
> --- a/tools/perf/arch/arm/util/cs-etm.c
> +++ b/tools/perf/arch/arm/util/cs-etm.c
> @@ -197,38 +197,32 @@ static int cs_etm_validate_timestamp(struct auxtrace_record *itr,
>  static int cs_etm_validate_config(struct auxtrace_record *itr,
>  				  struct evsel *evsel)
>  {
> -	int i, err = -EINVAL;
> +	int idx, err = -EINVAL;
>  	struct perf_cpu_map *event_cpus = evsel->evlist->core.user_requested_cpus;
>  	struct perf_cpu_map *online_cpus = perf_cpu_map__new_online_cpus();
> +	struct perf_cpu_map *intersect_cpus = perf_cpu_map__intersect(event_cpus, online_cpus);
> +	struct perf_cpu cpu;
>  
> -	/* Set option of each CPU we have */
> -	for (i = 0; i < cpu__max_cpu().cpu; i++) {
> -		struct perf_cpu cpu = { .cpu = i, };
> -
> -		/*
> -		 * In per-cpu case, do the validation for CPUs to work with.
> -		 * In per-thread case, the CPU map is empty.  Since the traced
> -		 * program can run on any CPUs in this case, thus don't skip
> -		 * validation.
> -		 */
> -		if (!perf_cpu_map__has_any_cpu_or_is_empty(event_cpus) &&
> -		    !perf_cpu_map__has(event_cpus, cpu))
> -			continue;

This has broken validation for per-thread sessions.
perf_cpu_map__intersect() doesn't seem to be able to handle the case
where an 'any' map intersected with an online map should return the
online map. Or at least it should for this to work, and it seems to make
sense for it to work that way.

At least that was my initial impression, but I only debugged it and saw
that the loop is now skipped entirely.

> -
> -		if (!perf_cpu_map__has(online_cpus, cpu))
> -			continue;
> +	perf_cpu_map__put(online_cpus);
>  
> -		err = cs_etm_validate_context_id(itr, evsel, i);
> +	/*
> +	 * Set option of each CPU we have. In per-cpu case, do the validation
> +	 * for CPUs to work with.  In per-thread case, the CPU map is empty.
> +	 * Since the traced program can run on any CPUs in this case, thus don't
> +	 * skip validation.
> +	 */
> +	perf_cpu_map__for_each_cpu_skip_any(cpu, idx, intersect_cpus) {
> +		err = cs_etm_validate_context_id(itr, evsel, cpu.cpu);
>  		if (err)
>  			goto out;
> -		err = cs_etm_validate_timestamp(itr, evsel, i);
> +		err = cs_etm_validate_timestamp(itr, evsel, idx);
>  		if (err)
>  			goto out;
>  	}
>  
>  	err = 0;
>  out:
> -	perf_cpu_map__put(online_cpus);
> +	perf_cpu_map__put(intersect_cpus);
>  	return err;
>  }
>  
> @@ -435,7 +429,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
>  	 * Also the case of per-cpu mmaps, need the contextID in order to be notified
>  	 * when a context switch happened.
>  	 */
> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
> +	if (!perf_cpu_map__is_any_cpu_or_is_empty(cpus)) {
>  		evsel__set_config_if_unset(cs_etm_pmu, cs_etm_evsel,
>  					   "timestamp", 1);
>  		evsel__set_config_if_unset(cs_etm_pmu, cs_etm_evsel,
> @@ -461,7 +455,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
>  	evsel->core.attr.sample_period = 1;
>  
>  	/* In per-cpu case, always need the time of mmap events etc */
> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus))
> +	if (!perf_cpu_map__is_any_cpu_or_is_empty(cpus))
>  		evsel__set_sample_bit(evsel, TIME);
>  
>  	err = cs_etm_validate_config(itr, cs_etm_evsel);
> @@ -533,38 +527,32 @@ static size_t
>  cs_etm_info_priv_size(struct auxtrace_record *itr __maybe_unused,
>  		      struct evlist *evlist __maybe_unused)
>  {
> -	int i;
> +	int idx;
>  	int etmv3 = 0, etmv4 = 0, ete = 0;
>  	struct perf_cpu_map *event_cpus = evlist->core.user_requested_cpus;
>  	struct perf_cpu_map *online_cpus = perf_cpu_map__new_online_cpus();
> +	struct perf_cpu cpu;
>  
>  	/* cpu map is not empty, we have specific CPUs to work with */
> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(event_cpus)) {
> -		for (i = 0; i < cpu__max_cpu().cpu; i++) {
> -			struct perf_cpu cpu = { .cpu = i, };
> -
> -			if (!perf_cpu_map__has(event_cpus, cpu) ||
> -			    !perf_cpu_map__has(online_cpus, cpu))
> -				continue;
> +	if (!perf_cpu_map__is_empty(event_cpus)) {
> +		struct perf_cpu_map *intersect_cpus =
> +			perf_cpu_map__intersect(event_cpus, online_cpus);
>  
> -			if (cs_etm_is_ete(itr, i))
> +		perf_cpu_map__for_each_cpu_skip_any(cpu, idx, intersect_cpus) {
> +			if (cs_etm_is_ete(itr, cpu.cpu))
>  				ete++;
> -			else if (cs_etm_is_etmv4(itr, i))
> +			else if (cs_etm_is_etmv4(itr, cpu.cpu))
>  				etmv4++;
>  			else
>  				etmv3++;
>  		}
> +		perf_cpu_map__put(intersect_cpus);
>  	} else {
>  		/* get configuration for all CPUs in the system */
> -		for (i = 0; i < cpu__max_cpu().cpu; i++) {
> -			struct perf_cpu cpu = { .cpu = i, };
> -
> -			if (!perf_cpu_map__has(online_cpus, cpu))
> -				continue;
> -
> -			if (cs_etm_is_ete(itr, i))
> +		perf_cpu_map__for_each_cpu(cpu, idx, online_cpus) {
> +			if (cs_etm_is_ete(itr, cpu.cpu))
>  				ete++;
> -			else if (cs_etm_is_etmv4(itr, i))
> +			else if (cs_etm_is_etmv4(itr, cpu.cpu))
>  				etmv4++;
>  			else
>  				etmv3++;
> @@ -814,15 +802,14 @@ static int cs_etm_info_fill(struct auxtrace_record *itr,
>  		return -EINVAL;
>  
>  	/* If the cpu_map is empty all online CPUs are involved */
> -	if (perf_cpu_map__has_any_cpu_or_is_empty(event_cpus)) {
> +	if (perf_cpu_map__is_empty(event_cpus)) {
>  		cpu_map = online_cpus;
>  	} else {
>  		/* Make sure all specified CPUs are online */
> -		for (i = 0; i < perf_cpu_map__nr(event_cpus); i++) {
> -			struct perf_cpu cpu = { .cpu = i, };
> +		struct perf_cpu cpu;
>  
> -			if (perf_cpu_map__has(event_cpus, cpu) &&
> -			    !perf_cpu_map__has(online_cpus, cpu))
> +		perf_cpu_map__for_each_cpu(cpu, i, event_cpus) {
> +			if (!perf_cpu_map__has(online_cpus, cpu))
>  				return -EINVAL;
>  		}
>  
> diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
> index 51ccbfd3d246..0b52e67edb3b 100644
> --- a/tools/perf/arch/arm64/util/arm-spe.c
> +++ b/tools/perf/arch/arm64/util/arm-spe.c
> @@ -232,7 +232,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
>  	 * In the case of per-cpu mmaps, sample CPU for AUX event;
>  	 * also enable the timestamp tracing for samples correlation.
>  	 */
> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
> +	if (!perf_cpu_map__is_any_cpu_or_is_empty(cpus)) {
>  		evsel__set_sample_bit(arm_spe_evsel, CPU);
>  		evsel__set_config_if_unset(arm_spe_pmu, arm_spe_evsel,
>  					   "ts_enable", 1);
> @@ -265,7 +265,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
>  	tracking_evsel->core.attr.sample_period = 1;
>  
>  	/* In per-cpu case, always need the time of mmap events etc */
> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
> +	if (!perf_cpu_map__is_any_cpu_or_is_empty(cpus)) {
>  		evsel__set_sample_bit(tracking_evsel, TIME);
>  		evsel__set_sample_bit(tracking_evsel, CPU);
>  


From vincent.guittot at linaro.org  Tue Dec 12 06:27:26 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Tue, 12 Dec 2023 15:27:26 +0100
Subject: [PATCH 0/5] Rework system pressure interface to the scheduler
Message-ID: <20231212142730.998913-1-vincent.guittot@linaro.org>

Following the consolidation and cleanup of CPU capacity in [1], this serie
reworks how the scheduler gets the pressures on CPUs. We need to take into
account all pressures applied by cpufreq on the compute capacity of a CPU
for dozens of ms or more and not only cpufreq cooling device or HW
mitigiations. we split the pressure applied on CPU's capacity in 2 parts:
- one from cpufreq and freq_qos
- one from HW high freq mitigiation.

The next step will be to add a dedicated interface for long standing
capping of the CPU capacity (i.e. for seconds or more) like the
scaling_max_freq of cpufreq sysfs. The latter is already taken into
account by this serie but as a temporary pressure which is not always the
best choice when we know that it will happen for seconds or more.

[1] https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot at linaro.org/

Vincent Guittot (4):
  cpufreq: Add a cpufreq pressure feedback for the scheduler
  sched: Take cpufreq feedback into account
  thermal/cpufreq: Remove arch_update_thermal_pressure()
  sched: Rename arch_update_thermal_pressure into
    arch_update_hw_pressure

 arch/arm/include/asm/topology.h               |  6 +--
 arch/arm64/include/asm/topology.h             |  6 +--
 drivers/base/arch_topology.c                  | 26 ++++-----
 drivers/cpufreq/cpufreq.c                     | 48 +++++++++++++++++
 drivers/cpufreq/qcom-cpufreq-hw.c             |  4 +-
 drivers/thermal/cpufreq_cooling.c             |  3 --
 include/linux/arch_topology.h                 |  8 +--
 include/linux/cpufreq.h                       | 10 ++++
 include/linux/sched/topology.h                |  8 +--
 .../{thermal_pressure.h => hw_pressure.h}     | 14 ++---
 include/trace/events/sched.h                  |  2 +-
 init/Kconfig                                  | 12 ++---
 kernel/sched/core.c                           |  8 +--
 kernel/sched/fair.c                           | 53 ++++++++++---------
 kernel/sched/pelt.c                           | 18 +++----
 kernel/sched/pelt.h                           | 16 +++---
 kernel/sched/sched.h                          |  4 +-
 17 files changed, 152 insertions(+), 94 deletions(-)
 rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)

-- 
2.34.1
 


From vincent.guittot at linaro.org  Tue Dec 12 06:27:29 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Tue, 12 Dec 2023 15:27:29 +0100
Subject: [PATCH 3/4] thermal/cpufreq: Remove arch_update_thermal_pressure()
In-Reply-To: <20231212142730.998913-1-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
Message-ID: <20231212142730.998913-4-vincent.guittot@linaro.org>

arch_update_thermal_pressure() aims to update fast changing signal which
should be averaged using PELT filtering before being provided to the
scheduler which can't make smart use of fast changing signal.
cpufreq now provides the maximum freq_qos pressure on the capacity to the
scheduler, which includes cpufreq cooling device. Remove the call to
arch_update_thermal_pressure() in cpufreq cooling device as this is
handled by cpufreq_get_pressure().

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 drivers/thermal/cpufreq_cooling.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/thermal/cpufreq_cooling.c b/drivers/thermal/cpufreq_cooling.c
index e2cc7bd30862..e77d3b44903e 100644
--- a/drivers/thermal/cpufreq_cooling.c
+++ b/drivers/thermal/cpufreq_cooling.c
@@ -448,7 +448,6 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
 				 unsigned long state)
 {
 	struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
-	struct cpumask *cpus;
 	unsigned int frequency;
 	int ret;
 
@@ -465,8 +464,6 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
 	ret = freq_qos_update_request(&cpufreq_cdev->qos_req, frequency);
 	if (ret >= 0) {
 		cpufreq_cdev->cpufreq_state = state;
-		cpus = cpufreq_cdev->policy->related_cpus;
-		arch_update_thermal_pressure(cpus, frequency);
 		ret = 0;
 	}
 
-- 
2.34.1



From vincent.guittot at linaro.org  Tue Dec 12 06:27:27 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Tue, 12 Dec 2023 15:27:27 +0100
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the scheduler
In-Reply-To: <20231212142730.998913-1-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
Message-ID: <20231212142730.998913-2-vincent.guittot@linaro.org>

Provide to the scheduler a feedback about the temporary max available
capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
filtered as the pressure will happen for dozens ms or more.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++++++++++++++++++++++++
 include/linux/cpufreq.h   | 10 ++++++++
 2 files changed, 58 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 44db4f59c4cc..7d5f71be8d29 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2563,6 +2563,50 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 }
 EXPORT_SYMBOL(cpufreq_get_policy);
 
+DEFINE_PER_CPU(unsigned long, cpufreq_pressure);
+EXPORT_PER_CPU_SYMBOL_GPL(cpufreq_pressure);
+
+/**
+ * cpufreq_update_pressure() - Update cpufreq pressure for CPUs
+ * @cpus        : The related CPUs for which max capacity has been reduced
+ * @capped_freq : The maximum allowed frequency that CPUs can run at
+ *
+ * Update the value of cpufreq pressure for all @cpus in the mask. The
+ * cpumask should include all (online+offline) affected CPUs, to avoid
+ * operating on stale data when hot-plug is used for some CPUs. The
+ * @capped_freq reflects the currently allowed max CPUs frequency due to
+ * freq_qos capping. It might be also a boost frequency value, which is bigger
+ * than the internal 'capacity_freq_ref' max frequency. In such case the
+ * pressure value should simply be removed, since this is an indication that
+ * there is no capping. The @capped_freq must be provided in kHz.
+ */
+static void cpufreq_update_pressure(const struct cpumask *cpus,
+				      unsigned long capped_freq)
+{
+	unsigned long max_capacity, capacity, pressure;
+	u32 max_freq;
+	int cpu;
+
+	cpu = cpumask_first(cpus);
+	max_capacity = arch_scale_cpu_capacity(cpu);
+	max_freq = arch_scale_freq_ref(cpu);
+
+	/*
+	 * Handle properly the boost frequencies, which should simply clean
+	 * the thermal pressure value.
+	 */
+	if (max_freq <= capped_freq)
+		capacity = max_capacity;
+	else
+		capacity = mult_frac(max_capacity, capped_freq, max_freq);
+
+	pressure = max_capacity - capacity;
+
+
+	for_each_cpu(cpu, cpus)
+		WRITE_ONCE(per_cpu(cpufreq_pressure, cpu), pressure);
+}
+
 /**
  * cpufreq_set_policy - Modify cpufreq policy parameters.
  * @policy: Policy object to modify.
@@ -2584,6 +2628,7 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
 {
 	struct cpufreq_policy_data new_data;
 	struct cpufreq_governor *old_gov;
+	struct cpumask *cpus;
 	int ret;
 
 	memcpy(&new_data.cpuinfo, &policy->cpuinfo, sizeof(policy->cpuinfo));
@@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
 	policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
 	trace_cpu_frequency_limits(policy);
 
+	cpus = policy->related_cpus;
+	cpufreq_update_pressure(cpus, policy->max);
+
 	policy->cached_target_freq = UINT_MAX;
 
 	pr_debug("new min and max freqs are %u - %u kHz\n",
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index afda5f24d3dd..b1d97edd3253 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -241,6 +241,12 @@ struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy);
 void cpufreq_enable_fast_switch(struct cpufreq_policy *policy);
 void cpufreq_disable_fast_switch(struct cpufreq_policy *policy);
 bool has_target_index(void);
+
+DECLARE_PER_CPU(unsigned long, cpufreq_pressure);
+static inline unsigned long cpufreq_get_pressure(int cpu)
+{
+	return per_cpu(cpufreq_pressure, cpu);
+}
 #else
 static inline unsigned int cpufreq_get(unsigned int cpu)
 {
@@ -263,6 +269,10 @@ static inline bool cpufreq_supports_freq_invariance(void)
 	return false;
 }
 static inline void disable_cpufreq(void) { }
+static inline unsigned long cpufreq_get_pressure(int cpu)
+{
+	return 0;
+}
 #endif
 
 #ifdef CONFIG_CPU_FREQ_STAT
-- 
2.34.1



From vincent.guittot at linaro.org  Tue Dec 12 06:27:28 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Tue, 12 Dec 2023 15:27:28 +0100
Subject: [PATCH 2/4] sched: Take cpufreq feedback into account
In-Reply-To: <20231212142730.998913-1-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
Message-ID: <20231212142730.998913-3-vincent.guittot@linaro.org>

Aggregate the different pressures applied on the capacity of CPUs and
create a new function that returns the actual capacity of the CPU:
  get_actual_cpu_capacity()

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 kernel/sched/fair.c | 43 +++++++++++++++++++++++--------------------
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bcea3d55d95d..11d3be829302 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4932,12 +4932,20 @@ static inline void util_est_update(struct cfs_rq *cfs_rq,
 	trace_sched_util_est_se_tp(&p->se);
 }
 
+static inline unsigned long get_actual_cpu_capacity(int cpu)
+{
+	unsigned long capacity = arch_scale_cpu_capacity(cpu);
+
+	capacity -= max(thermal_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
+
+	return capacity;
+}
 static inline int util_fits_cpu(unsigned long util,
 				unsigned long uclamp_min,
 				unsigned long uclamp_max,
 				int cpu)
 {
-	unsigned long capacity_orig, capacity_orig_thermal;
+	unsigned long capacity_orig;
 	unsigned long capacity = capacity_of(cpu);
 	bool fits, uclamp_max_fits;
 
@@ -4970,7 +4978,6 @@ static inline int util_fits_cpu(unsigned long util,
 	 * goal is to cap the task. So it's okay if it's getting less.
 	 */
 	capacity_orig = arch_scale_cpu_capacity(cpu);
-	capacity_orig_thermal = capacity_orig - arch_scale_thermal_pressure(cpu);
 
 	/*
 	 * We want to force a task to fit a cpu as implied by uclamp_max.
@@ -5045,7 +5052,7 @@ static inline int util_fits_cpu(unsigned long util,
 	 * handle the case uclamp_min > uclamp_max.
 	 */
 	uclamp_min = min(uclamp_min, uclamp_max);
-	if (fits && (util < uclamp_min) && (uclamp_min > capacity_orig_thermal))
+	if (fits && (util < uclamp_min) && (uclamp_min > get_actual_cpu_capacity(cpu)))
 		return -1;
 
 	return fits;
@@ -7426,7 +7433,7 @@ select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target)
 		 * Look for the CPU with best capacity.
 		 */
 		else if (fits < 0)
-			cpu_cap = arch_scale_cpu_capacity(cpu) - thermal_load_avg(cpu_rq(cpu));
+			cpu_cap = get_actual_cpu_capacity(cpu);
 
 		/*
 		 * First, select CPU which fits better (-1 being better than 0).
@@ -7919,8 +7926,8 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 	struct root_domain *rd = this_rq()->rd;
 	int cpu, best_energy_cpu, target = -1;
 	int prev_fits = -1, best_fits = -1;
-	unsigned long best_thermal_cap = 0;
-	unsigned long prev_thermal_cap = 0;
+	unsigned long best_actual_cap = 0;
+	unsigned long prev_actual_cap = 0;
 	struct sched_domain *sd;
 	struct perf_domain *pd;
 	struct energy_env eenv;
@@ -7950,7 +7957,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 
 	for (; pd; pd = pd->next) {
 		unsigned long util_min = p_util_min, util_max = p_util_max;
-		unsigned long cpu_cap, cpu_thermal_cap, util;
+		unsigned long cpu_cap, cpu_actual_cap, util;
 		long prev_spare_cap = -1, max_spare_cap = -1;
 		unsigned long rq_util_min, rq_util_max;
 		unsigned long cur_delta, base_energy;
@@ -7962,18 +7969,17 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 		if (cpumask_empty(cpus))
 			continue;
 
-		/* Account thermal pressure for the energy estimation */
+		/* Account external pressure for the energy estimation */
 		cpu = cpumask_first(cpus);
-		cpu_thermal_cap = arch_scale_cpu_capacity(cpu);
-		cpu_thermal_cap -= arch_scale_thermal_pressure(cpu);
+		cpu_actual_cap = get_actual_cpu_capacity(cpu);
 
-		eenv.cpu_cap = cpu_thermal_cap;
+		eenv.cpu_cap = cpu_actual_cap;
 		eenv.pd_cap = 0;
 
 		for_each_cpu(cpu, cpus) {
 			struct rq *rq = cpu_rq(cpu);
 
-			eenv.pd_cap += cpu_thermal_cap;
+			eenv.pd_cap += cpu_actual_cap;
 
 			if (!cpumask_test_cpu(cpu, sched_domain_span(sd)))
 				continue;
@@ -8044,7 +8050,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 			if (prev_delta < base_energy)
 				goto unlock;
 			prev_delta -= base_energy;
-			prev_thermal_cap = cpu_thermal_cap;
+			prev_actual_cap = cpu_actual_cap;
 			best_delta = min(best_delta, prev_delta);
 		}
 
@@ -8059,7 +8065,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 			 * but best energy cpu has better capacity.
 			 */
 			if ((max_fits < 0) &&
-			    (cpu_thermal_cap <= best_thermal_cap))
+			    (cpu_actual_cap <= best_actual_cap))
 				continue;
 
 			cur_delta = compute_energy(&eenv, pd, cpus, p,
@@ -8080,14 +8086,14 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 			best_delta = cur_delta;
 			best_energy_cpu = max_spare_cap_cpu;
 			best_fits = max_fits;
-			best_thermal_cap = cpu_thermal_cap;
+			best_actual_cap = cpu_actual_cap;
 		}
 	}
 	rcu_read_unlock();
 
 	if ((best_fits > prev_fits) ||
 	    ((best_fits > 0) && (best_delta < prev_delta)) ||
-	    ((best_fits < 0) && (best_thermal_cap > prev_thermal_cap)))
+	    ((best_fits < 0) && (best_actual_cap > prev_actual_cap)))
 		target = best_energy_cpu;
 
 	return target;
@@ -9466,7 +9472,7 @@ static inline void init_sd_lb_stats(struct sd_lb_stats *sds)
 static unsigned long scale_rt_capacity(int cpu)
 {
 	struct rq *rq = cpu_rq(cpu);
-	unsigned long max = arch_scale_cpu_capacity(cpu);
+	unsigned long max = get_actual_cpu_capacity(cpu);
 	unsigned long used, free;
 	unsigned long irq;
 
@@ -9478,12 +9484,9 @@ static unsigned long scale_rt_capacity(int cpu)
 	/*
 	 * avg_rt.util_avg and avg_dl.util_avg track binary signals
 	 * (running and not running) with weights 0 and 1024 respectively.
-	 * avg_thermal.load_avg tracks thermal pressure and the weighted
-	 * average uses the actual delta max capacity(load).
 	 */
 	used = READ_ONCE(rq->avg_rt.util_avg);
 	used += READ_ONCE(rq->avg_dl.util_avg);
-	used += thermal_load_avg(rq);
 
 	if (unlikely(used >= max))
 		return 1;
-- 
2.34.1



From vincent.guittot at linaro.org  Tue Dec 12 06:27:30 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Tue, 12 Dec 2023 15:27:30 +0100
Subject: [PATCH 4/4] sched: Rename arch_update_thermal_pressure into arch_update_hw_pressure
In-Reply-To: <20231212142730.998913-1-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
Message-ID: <20231212142730.998913-5-vincent.guittot@linaro.org>

Now that cpufreq provides a pressure value to the scheduler, rename
arch_update_thermal_pressure into hw pressure to reflect that it returns
a pressure applied by HW with a high frequency and which needs filtering.
This pressure is not always related to thermal mitigation but can also be
generated by max current limitation as an example.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 arch/arm/include/asm/topology.h               |  6 ++---
 arch/arm64/include/asm/topology.h             |  6 ++---
 drivers/base/arch_topology.c                  | 26 +++++++++----------
 drivers/cpufreq/qcom-cpufreq-hw.c             |  4 +--
 include/linux/arch_topology.h                 |  8 +++---
 include/linux/sched/topology.h                |  8 +++---
 .../{thermal_pressure.h => hw_pressure.h}     | 14 +++++-----
 include/trace/events/sched.h                  |  2 +-
 init/Kconfig                                  | 12 ++++-----
 kernel/sched/core.c                           |  8 +++---
 kernel/sched/fair.c                           | 12 ++++-----
 kernel/sched/pelt.c                           | 18 ++++++-------
 kernel/sched/pelt.h                           | 16 ++++++------
 kernel/sched/sched.h                          |  4 +--
 14 files changed, 72 insertions(+), 72 deletions(-)
 rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)

diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index 853c4f81ba4a..e175e8596b5d 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -22,9 +22,9 @@
 /* Enable topology flag updates */
 #define arch_update_cpu_topology topology_update_cpu_topology
 
-/* Replace task scheduler's default thermal pressure API */
-#define arch_scale_thermal_pressure topology_get_thermal_pressure
-#define arch_update_thermal_pressure	topology_update_thermal_pressure
+/* Replace task scheduler's default hw pressure API */
+#define arch_scale_hw_pressure topology_get_hw_pressure
+#define arch_update_hw_pressure	topology_update_hw_pressure
 
 #else
 
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index a323b109b9c4..a427650bdfba 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -35,9 +35,9 @@ void update_freq_counters_refs(void);
 /* Enable topology flag updates */
 #define arch_update_cpu_topology topology_update_cpu_topology
 
-/* Replace task scheduler's default thermal pressure API */
-#define arch_scale_thermal_pressure topology_get_thermal_pressure
-#define arch_update_thermal_pressure	topology_update_thermal_pressure
+/* Replace task scheduler's default hw pressure API */
+#define arch_scale_hw_pressure topology_get_hw_pressure
+#define arch_update_hw_pressure	topology_update_hw_pressure
 
 #include <asm-generic/topology.h>
 
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 0906114963ff..3d8dc9d5c3ad 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -22,7 +22,7 @@
 #include <linux/units.h>
 
 #define CREATE_TRACE_POINTS
-#include <trace/events/thermal_pressure.h>
+#include <trace/events/hw_pressure.h>
 
 static DEFINE_PER_CPU(struct scale_freq_data __rcu *, sft_data);
 static struct cpumask scale_freq_counters_mask;
@@ -160,26 +160,26 @@ void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity)
 	per_cpu(cpu_scale, cpu) = capacity;
 }
 
-DEFINE_PER_CPU(unsigned long, thermal_pressure);
+DEFINE_PER_CPU(unsigned long, hw_pressure);
 
 /**
- * topology_update_thermal_pressure() - Update thermal pressure for CPUs
+ * topology_update_hw_pressure() - Update hw pressure for CPUs
  * @cpus        : The related CPUs for which capacity has been reduced
  * @capped_freq : The maximum allowed frequency that CPUs can run at
  *
- * Update the value of thermal pressure for all @cpus in the mask. The
+ * Update the value of hw pressure for all @cpus in the mask. The
  * cpumask should include all (online+offline) affected CPUs, to avoid
  * operating on stale data when hot-plug is used for some CPUs. The
  * @capped_freq reflects the currently allowed max CPUs frequency due to
- * thermal capping. It might be also a boost frequency value, which is bigger
+ * hw capping. It might be also a boost frequency value, which is bigger
  * than the internal 'capacity_freq_ref' max frequency. In such case the
  * pressure value should simply be removed, since this is an indication that
- * there is no thermal throttling. The @capped_freq must be provided in kHz.
+ * there is no hw throttling. The @capped_freq must be provided in kHz.
  */
-void topology_update_thermal_pressure(const struct cpumask *cpus,
+void topology_update_hw_pressure(const struct cpumask *cpus,
 				      unsigned long capped_freq)
 {
-	unsigned long max_capacity, capacity, th_pressure;
+	unsigned long max_capacity, capacity, hw_pressure;
 	u32 max_freq;
 	int cpu;
 
@@ -189,21 +189,21 @@ void topology_update_thermal_pressure(const struct cpumask *cpus,
 
 	/*
 	 * Handle properly the boost frequencies, which should simply clean
-	 * the thermal pressure value.
+	 * the hw pressure value.
 	 */
 	if (max_freq <= capped_freq)
 		capacity = max_capacity;
 	else
 		capacity = mult_frac(max_capacity, capped_freq, max_freq);
 
-	th_pressure = max_capacity - capacity;
+	hw_pressure = max_capacity - capacity;
 
-	trace_thermal_pressure_update(cpu, th_pressure);
+	trace_hw_pressure_update(cpu, hw_pressure);
 
 	for_each_cpu(cpu, cpus)
-		WRITE_ONCE(per_cpu(thermal_pressure, cpu), th_pressure);
+		WRITE_ONCE(per_cpu(hw_pressure, cpu), hw_pressure);
 }
-EXPORT_SYMBOL_GPL(topology_update_thermal_pressure);
+EXPORT_SYMBOL_GPL(topology_update_hw_pressure);
 
 static ssize_t cpu_capacity_show(struct device *dev,
 				 struct device_attribute *attr,
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index 70b0f21968a0..a619202ba81d 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -347,8 +347,8 @@ static void qcom_lmh_dcvs_notify(struct qcom_cpufreq_data *data)
 
 	throttled_freq = freq_hz / HZ_PER_KHZ;
 
-	/* Update thermal pressure (the boost frequencies are accepted) */
-	arch_update_thermal_pressure(policy->related_cpus, throttled_freq);
+	/* Update hw pressure (the boost frequencies are accepted) */
+	arch_update_hw_pressure(policy->related_cpus, throttled_freq);
 
 	/*
 	 * In the unlikely case policy is unregistered do not enable
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index a63d61ca55af..b721f360d759 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -60,14 +60,14 @@ void topology_scale_freq_tick(void);
 void topology_set_scale_freq_source(struct scale_freq_data *data, const struct cpumask *cpus);
 void topology_clear_scale_freq_source(enum scale_freq_source source, const struct cpumask *cpus);
 
-DECLARE_PER_CPU(unsigned long, thermal_pressure);
+DECLARE_PER_CPU(unsigned long, hw_pressure);
 
-static inline unsigned long topology_get_thermal_pressure(int cpu)
+static inline unsigned long topology_get_hw_pressure(int cpu)
 {
-	return per_cpu(thermal_pressure, cpu);
+	return per_cpu(hw_pressure, cpu);
 }
 
-void topology_update_thermal_pressure(const struct cpumask *cpus,
+void topology_update_hw_pressure(const struct cpumask *cpus,
 				      unsigned long capped_freq);
 
 struct cpu_topology {
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index a6e04b4a21d7..e3b2cf7de018 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -264,17 +264,17 @@ unsigned long arch_scale_cpu_capacity(int cpu)
 }
 #endif
 
-#ifndef arch_scale_thermal_pressure
+#ifndef arch_scale_hw_pressure
 static __always_inline
-unsigned long arch_scale_thermal_pressure(int cpu)
+unsigned long arch_scale_hw_pressure(int cpu)
 {
 	return 0;
 }
 #endif
 
-#ifndef arch_update_thermal_pressure
+#ifndef arch_update_hw_pressure
 static __always_inline
-void arch_update_thermal_pressure(const struct cpumask *cpus,
+void arch_update_hw_pressure(const struct cpumask *cpus,
 				  unsigned long capped_frequency)
 { }
 #endif
diff --git a/include/trace/events/thermal_pressure.h b/include/trace/events/hw_pressure.h
similarity index 55%
rename from include/trace/events/thermal_pressure.h
rename to include/trace/events/hw_pressure.h
index b68680201360..b9cd68854128 100644
--- a/include/trace/events/thermal_pressure.h
+++ b/include/trace/events/hw_pressure.h
@@ -1,27 +1,27 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 #undef TRACE_SYSTEM
-#define TRACE_SYSTEM thermal_pressure
+#define TRACE_SYSTEM hw_pressure
 
 #if !defined(_TRACE_THERMAL_PRESSURE_H) || defined(TRACE_HEADER_MULTI_READ)
 #define _TRACE_THERMAL_PRESSURE_H
 
 #include <linux/tracepoint.h>
 
-TRACE_EVENT(thermal_pressure_update,
-	TP_PROTO(int cpu, unsigned long thermal_pressure),
-	TP_ARGS(cpu, thermal_pressure),
+TRACE_EVENT(hw_pressure_update,
+	TP_PROTO(int cpu, unsigned long hw_pressure),
+	TP_ARGS(cpu, hw_pressure),
 
 	TP_STRUCT__entry(
-		__field(unsigned long, thermal_pressure)
+		__field(unsigned long, hw_pressure)
 		__field(int, cpu)
 	),
 
 	TP_fast_assign(
-		__entry->thermal_pressure = thermal_pressure;
+		__entry->hw_pressure = hw_pressure;
 		__entry->cpu = cpu;
 	),
 
-	TP_printk("cpu=%d thermal_pressure=%lu", __entry->cpu, __entry->thermal_pressure)
+	TP_printk("cpu=%d hw_pressure=%lu", __entry->cpu, __entry->hw_pressure)
 );
 #endif /* _TRACE_THERMAL_PRESSURE_H */
 
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index dbb01b4b7451..d115d64c4011 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -752,7 +752,7 @@ DECLARE_TRACE(pelt_dl_tp,
 	TP_PROTO(struct rq *rq),
 	TP_ARGS(rq));
 
-DECLARE_TRACE(pelt_thermal_tp,
+DECLARE_TRACE(pelt_hw_tp,
 	TP_PROTO(struct rq *rq),
 	TP_ARGS(rq));
 
diff --git a/init/Kconfig b/init/Kconfig
index 9ffb103fc927..37ceeb67e01c 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -538,24 +538,24 @@ config HAVE_SCHED_AVG_IRQ
 	depends on IRQ_TIME_ACCOUNTING || PARAVIRT_TIME_ACCOUNTING
 	depends on SMP
 
-config SCHED_THERMAL_PRESSURE
+config SCHED_HW_PRESSURE
 	bool
 	default y if ARM && ARM_CPU_TOPOLOGY
 	default y if ARM64
 	depends on SMP
 	depends on CPU_FREQ_THERMAL
 	help
-	  Select this option to enable thermal pressure accounting in the
-	  scheduler. Thermal pressure is the value conveyed to the scheduler
+	  Select this option to enable HW pressure accounting in the
+	  scheduler. HW pressure is the value conveyed to the scheduler
 	  that reflects the reduction in CPU compute capacity resulted from
-	  thermal throttling. Thermal throttling occurs when the performance of
-	  a CPU is capped due to high operating temperatures.
+	  HW throttling. HW throttling occurs when the performance of
+	  a CPU is capped due to high operating temperatures as an example.
 
 	  If selected, the scheduler will be able to balance tasks accordingly,
 	  i.e. put less load on throttled CPUs than on non/less throttled ones.
 
 	  This requires the architecture to implement
-	  arch_update_thermal_pressure() and arch_scale_thermal_pressure().
+	  arch_update_hw_pressure() and arch_scale_thermal_pressure().
 
 config BSD_PROCESS_ACCT
 	bool "BSD Process Accounting"
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index db4be4921e7f..c68e47bfd5ae 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -107,7 +107,7 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_rt_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_dl_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_irq_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_se_tp);
-EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_thermal_tp);
+EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_hw_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(sched_cpu_capacity_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(sched_overutilized_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(sched_util_est_cfs_tp);
@@ -5658,7 +5658,7 @@ void scheduler_tick(void)
 	struct rq *rq = cpu_rq(cpu);
 	struct task_struct *curr = rq->curr;
 	struct rq_flags rf;
-	unsigned long thermal_pressure;
+	unsigned long hw_pressure;
 	u64 resched_latency;
 
 	if (housekeeping_cpu(cpu, HK_TYPE_TICK))
@@ -5669,8 +5669,8 @@ void scheduler_tick(void)
 	rq_lock(rq, &rf);
 
 	update_rq_clock(rq);
-	thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
-	update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure);
+	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
+	update_hw_load_avg(rq_clock_task(rq), rq, hw_pressure);
 	curr->sched_class->task_tick(rq, curr, 0);
 	if (sched_feat(LATENCY_WARN))
 		resched_latency = cpu_resched_latency(rq);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 11d3be829302..07050955d6e0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4936,7 +4936,7 @@ static inline unsigned long get_actual_cpu_capacity(int cpu)
 {
 	unsigned long capacity = arch_scale_cpu_capacity(cpu);
 
-	capacity -= max(thermal_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
+	capacity -= max(hw_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
 
 	return capacity;
 }
@@ -4968,7 +4968,7 @@ static inline int util_fits_cpu(unsigned long util,
 	 * Similarly if a task is capped to arch_scale_cpu_capacity(little_cpu), it
 	 * should fit a little cpu even if there's some pressure.
 	 *
-	 * Only exception is for thermal pressure since it has a direct impact
+	 * Only exception is for hw or cpufreq pressure since it has a direct impact
 	 * on available OPP of the system.
 	 *
 	 * We honour it for uclamp_min only as a drop in performance level
@@ -9224,7 +9224,7 @@ static inline bool others_have_blocked(struct rq *rq)
 	if (READ_ONCE(rq->avg_dl.util_avg))
 		return true;
 
-	if (thermal_load_avg(rq))
+	if (hw_load_avg(rq))
 		return true;
 
 #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
@@ -9256,7 +9256,7 @@ static bool __update_blocked_others(struct rq *rq, bool *done)
 {
 	const struct sched_class *curr_class;
 	u64 now = rq_clock_pelt(rq);
-	unsigned long thermal_pressure;
+	unsigned long hw_pressure;
 	bool decayed;
 
 	/*
@@ -9265,11 +9265,11 @@ static bool __update_blocked_others(struct rq *rq, bool *done)
 	 */
 	curr_class = rq->curr->sched_class;
 
-	thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
+	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
 
 	decayed = update_rt_rq_load_avg(now, rq, curr_class == &rt_sched_class) |
 		  update_dl_rq_load_avg(now, rq, curr_class == &dl_sched_class) |
-		  update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure) |
+		  update_hw_load_avg(now, rq, hw_pressure) |
 		  update_irq_load_avg(rq, 0);
 
 	if (others_have_blocked(rq))
diff --git a/kernel/sched/pelt.c b/kernel/sched/pelt.c
index 63b6cf898220..cd599a5185c4 100644
--- a/kernel/sched/pelt.c
+++ b/kernel/sched/pelt.c
@@ -384,30 +384,30 @@ int update_dl_rq_load_avg(u64 now, struct rq *rq, int running)
 	return 0;
 }
 
-#ifdef CONFIG_SCHED_THERMAL_PRESSURE
+#ifdef CONFIG_SCHED_HW_PRESSURE
 /*
- * thermal:
+ * hardware:
  *
  *   load_sum = \Sum se->avg.load_sum but se->avg.load_sum is not tracked
  *
  *   util_avg and runnable_load_avg are not supported and meaningless.
  *
  * Unlike rt/dl utilization tracking that track time spent by a cpu
- * running a rt/dl task through util_avg, the average thermal pressure is
- * tracked through load_avg. This is because thermal pressure signal is
+ * running a rt/dl task through util_avg, the average hw pressure is
+ * tracked through load_avg. This is because hw pressure signal is
  * time weighted "delta" capacity unlike util_avg which is binary.
  * "delta capacity" =  actual capacity  -
- *			capped capacity a cpu due to a thermal event.
+ *			capped capacity a cpu due to a hw event.
  */
 
-int update_thermal_load_avg(u64 now, struct rq *rq, u64 capacity)
+int update_hw_load_avg(u64 now, struct rq *rq, u64 capacity)
 {
-	if (___update_load_sum(now, &rq->avg_thermal,
+	if (___update_load_sum(now, &rq->avg_hw,
 			       capacity,
 			       capacity,
 			       capacity)) {
-		___update_load_avg(&rq->avg_thermal, 1);
-		trace_pelt_thermal_tp(rq);
+		___update_load_avg(&rq->avg_hw, 1);
+		trace_pelt_hw_tp(rq);
 		return 1;
 	}
 
diff --git a/kernel/sched/pelt.h b/kernel/sched/pelt.h
index 3a0e0dc28721..e3ab44c4a2ef 100644
--- a/kernel/sched/pelt.h
+++ b/kernel/sched/pelt.h
@@ -7,21 +7,21 @@ int __update_load_avg_cfs_rq(u64 now, struct cfs_rq *cfs_rq);
 int update_rt_rq_load_avg(u64 now, struct rq *rq, int running);
 int update_dl_rq_load_avg(u64 now, struct rq *rq, int running);
 
-#ifdef CONFIG_SCHED_THERMAL_PRESSURE
-int update_thermal_load_avg(u64 now, struct rq *rq, u64 capacity);
+#ifdef CONFIG_SCHED_HW_PRESSURE
+int update_hw_load_avg(u64 now, struct rq *rq, u64 capacity);
 
-static inline u64 thermal_load_avg(struct rq *rq)
+static inline u64 hw_load_avg(struct rq *rq)
 {
-	return READ_ONCE(rq->avg_thermal.load_avg);
+	return READ_ONCE(rq->avg_hw.load_avg);
 }
 #else
 static inline int
-update_thermal_load_avg(u64 now, struct rq *rq, u64 capacity)
+update_hw_load_avg(u64 now, struct rq *rq, u64 capacity)
 {
 	return 0;
 }
 
-static inline u64 thermal_load_avg(struct rq *rq)
+static inline u64 hw_load_avg(struct rq *rq)
 {
 	return 0;
 }
@@ -202,12 +202,12 @@ update_dl_rq_load_avg(u64 now, struct rq *rq, int running)
 }
 
 static inline int
-update_thermal_load_avg(u64 now, struct rq *rq, u64 capacity)
+update_hw_load_avg(u64 now, struct rq *rq, u64 capacity)
 {
 	return 0;
 }
 
-static inline u64 thermal_load_avg(struct rq *rq)
+static inline u64 hw_load_avg(struct rq *rq)
 {
 	return 0;
 }
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index e58a54bda77d..7eaf186d071e 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1078,8 +1078,8 @@ struct rq {
 #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
 	struct sched_avg	avg_irq;
 #endif
-#ifdef CONFIG_SCHED_THERMAL_PRESSURE
-	struct sched_avg	avg_thermal;
+#ifdef CONFIG_SCHED_HW_PRESSURE
+	struct sched_avg	avg_hw;
 #endif
 	u64			idle_stamp;
 	u64			avg_idle;
-- 
2.34.1



From ahalaney at redhat.com  Tue Dec 12 06:28:35 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Tue, 12 Dec 2023 08:28:35 -0600
Subject: [PATCH net] net: stmmac: Handle disabled MDIO busses from
 devicetree
In-Reply-To: <ggbqvhdhgl6wmuewqtwtgud7ubx2ypmnb3p6p6w7cy37mnnyxn@2eqd63s2t5ii>
References: <20231211-b4-stmmac-handle-mdio-enodev-v1-1-73c20c44f8d6@redhat.com>
 <ggbqvhdhgl6wmuewqtwtgud7ubx2ypmnb3p6p6w7cy37mnnyxn@2eqd63s2t5ii>
Message-ID: <d7vwj7p55ig7fjste3ctqwpccuoowh2ryqnmcxq3qqrn6exzjd@z5mbsitxbupk>

On Tue, Dec 12, 2023 at 01:59:25PM +0300, Serge Semin wrote:
> On Mon, Dec 11, 2023 at 03:31:17PM -0600, Andrew Halaney wrote:
> > Many hardware configurations have the MDIO bus disabled, and are instead
> > using some other MDIO bus to talk to the MAC's phy.
> > 
> > of_mdiobus_register() returns -ENODEV in this case. Let's handle it
> > gracefully instead of failing to probe the MAC.
> > 
> > Fixes: 47dd7a540b8a (net: add support for STMicroelectronics Ethernet controllers.")
> > Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
> > ---
> >  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> > index fa9e7e7040b9..a39be15d41a8 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> > @@ -591,7 +591,13 @@ int stmmac_mdio_register(struct net_device *ndev)
> >  	new_bus->parent = priv->device;
> >  
> >  	err = of_mdiobus_register(new_bus, mdio_node);
> > -	if (err != 0) {
> > +	if (err) {
> > +		if (err == -ENODEV) {
> > +			/* The bus is disabled in the devicetree, that's ok */
> > +			mdiobus_free(new_bus);
> > +			return 0;
> > +		}
> > +
> >  		dev_err_probe(dev, err, "Cannot register the MDIO bus\n");
> >  		goto bus_register_fail;
> >  	}
> 
> This can be implemented a bit simpler, more maintainable and saving
> one indentations level:
> 
> 	err = of_mdiobus_register(new_bus, mdio_node);
> 	if (err == -ENODEV) {
> 		err = 0;
> 		dev_warn(dev, "MDIO bus is disabled\n");

Thanks for all your reviews, I agree this is cleaner!

I'm going to opt to use dev_info() here as this isn't something that's
wrong, just worth noting.

> 		goto bus_register_fail;
> 	} else if (err) {
>   		dev_err_probe(dev, err, "Cannot register the MDIO bus\n");
>   		goto bus_register_fail;
> 	}
> 
> -Serge(y)
> 
> > 
> > ---
> > base-commit: bbd220ce4e29ed55ab079007cff0b550895258eb
> > change-id: 20231211-b4-stmmac-handle-mdio-enodev-82168de68c6a
> > 
> > Best regards,
> > -- 
> > Andrew Halaney <ahalaney at redhat.com>
> > 
> 



From james.clark at arm.com  Tue Dec 12 06:36:21 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 14:36:21 +0000
Subject: [PATCH v1 07/14] perf arm-spe/cs-etm: Directly iterate CPU maps
In-Reply-To: <e3a01313-ed03-bc54-0260-5445fb2c15ee@arm.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-8-irogers@google.com>
 <e3a01313-ed03-bc54-0260-5445fb2c15ee@arm.com>
Message-ID: <2adf8e9c-e08d-a772-bfe2-378d6759721f@arm.com>



On 12/12/2023 14:17, James Clark wrote:
> 
> 
> On 29/11/2023 06:02, Ian Rogers wrote:
>> Rather than iterate all CPUs and see if they are in CPU maps, directly
>> iterate the CPU map. Similarly make use of the intersect
>> function. Switch perf_cpu_map__has_any_cpu_or_is_empty to more
>> appropriate alternatives.
>>
>> Signed-off-by: Ian Rogers <irogers at google.com>
>> ---
>>  tools/perf/arch/arm/util/cs-etm.c    | 77 ++++++++++++----------------
>>  tools/perf/arch/arm64/util/arm-spe.c |  4 +-
>>  2 files changed, 34 insertions(+), 47 deletions(-)
>>
>> diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
>> index 77e6663c1703..a68a72f2f668 100644
>> --- a/tools/perf/arch/arm/util/cs-etm.c
>> +++ b/tools/perf/arch/arm/util/cs-etm.c
>> @@ -197,38 +197,32 @@ static int cs_etm_validate_timestamp(struct auxtrace_record *itr,
>>  static int cs_etm_validate_config(struct auxtrace_record *itr,
>>  				  struct evsel *evsel)
>>  {
>> -	int i, err = -EINVAL;
>> +	int idx, err = -EINVAL;
>>  	struct perf_cpu_map *event_cpus = evsel->evlist->core.user_requested_cpus;
>>  	struct perf_cpu_map *online_cpus = perf_cpu_map__new_online_cpus();
>> +	struct perf_cpu_map *intersect_cpus = perf_cpu_map__intersect(event_cpus, online_cpus);
>> +	struct perf_cpu cpu;
>>  
>> -	/* Set option of each CPU we have */
>> -	for (i = 0; i < cpu__max_cpu().cpu; i++) {
>> -		struct perf_cpu cpu = { .cpu = i, };
>> -
>> -		/*
>> -		 * In per-cpu case, do the validation for CPUs to work with.
>> -		 * In per-thread case, the CPU map is empty.  Since the traced
>> -		 * program can run on any CPUs in this case, thus don't skip
>> -		 * validation.
>> -		 */
>> -		if (!perf_cpu_map__has_any_cpu_or_is_empty(event_cpus) &&
>> -		    !perf_cpu_map__has(event_cpus, cpu))
>> -			continue;
> 
> This has broken validation for per-thread sessions.
> perf_cpu_map__intersect() doesn't seem to be able to handle the case
> where an 'any' map intersected with an online map should return the
> online map. Or at least it should for this to work, and it seems to make
> sense for it to work that way.
> 
> At least that was my initial impression, but I only debugged it and saw
> that the loop is now skipped entirely.
> 
>> -
>> -		if (!perf_cpu_map__has(online_cpus, cpu))
>> -			continue;
>> +	perf_cpu_map__put(online_cpus);
>>  
>> -		err = cs_etm_validate_context_id(itr, evsel, i);
>> +	/*
>> +	 * Set option of each CPU we have. In per-cpu case, do the validation
>> +	 * for CPUs to work with.  In per-thread case, the CPU map is empty.
>> +	 * Since the traced program can run on any CPUs in this case, thus don't
>> +	 * skip validation.
>> +	 */
>> +	perf_cpu_map__for_each_cpu_skip_any(cpu, idx, intersect_cpus) {
>> +		err = cs_etm_validate_context_id(itr, evsel, cpu.cpu);
>>  		if (err)
>>  			goto out;
>> -		err = cs_etm_validate_timestamp(itr, evsel, i);
>> +		err = cs_etm_validate_timestamp(itr, evsel, idx);
>>  		if (err)
>>  			goto out;
>>  	}
>>  
>>  	err = 0;
>>  out:
>> -	perf_cpu_map__put(online_cpus);
>> +	perf_cpu_map__put(intersect_cpus);
>>  	return err;
>>  }
>>  
>> @@ -435,7 +429,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
>>  	 * Also the case of per-cpu mmaps, need the contextID in order to be notified
>>  	 * when a context switch happened.
>>  	 */
>> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
>> +	if (!perf_cpu_map__is_any_cpu_or_is_empty(cpus)) {
>>  		evsel__set_config_if_unset(cs_etm_pmu, cs_etm_evsel,
>>  					   "timestamp", 1);
>>  		evsel__set_config_if_unset(cs_etm_pmu, cs_etm_evsel,
>> @@ -461,7 +455,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
>>  	evsel->core.attr.sample_period = 1;
>>  
>>  	/* In per-cpu case, always need the time of mmap events etc */
>> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus))
>> +	if (!perf_cpu_map__is_any_cpu_or_is_empty(cpus))
>>  		evsel__set_sample_bit(evsel, TIME);
>>  
>>  	err = cs_etm_validate_config(itr, cs_etm_evsel);
>> @@ -533,38 +527,32 @@ static size_t
>>  cs_etm_info_priv_size(struct auxtrace_record *itr __maybe_unused,
>>  		      struct evlist *evlist __maybe_unused)
>>  {
>> -	int i;
>> +	int idx;
>>  	int etmv3 = 0, etmv4 = 0, ete = 0;
>>  	struct perf_cpu_map *event_cpus = evlist->core.user_requested_cpus;
>>  	struct perf_cpu_map *online_cpus = perf_cpu_map__new_online_cpus();
>> +	struct perf_cpu cpu;
>>  
>>  	/* cpu map is not empty, we have specific CPUs to work with */
>> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(event_cpus)) {
>> -		for (i = 0; i < cpu__max_cpu().cpu; i++) {
>> -			struct perf_cpu cpu = { .cpu = i, };
>> -
>> -			if (!perf_cpu_map__has(event_cpus, cpu) ||
>> -			    !perf_cpu_map__has(online_cpus, cpu))
>> -				continue;
>> +	if (!perf_cpu_map__is_empty(event_cpus)) {
>> +		struct perf_cpu_map *intersect_cpus =
>> +			perf_cpu_map__intersect(event_cpus, online_cpus);
>>  
>> -			if (cs_etm_is_ete(itr, i))
>> +		perf_cpu_map__for_each_cpu_skip_any(cpu, idx, intersect_cpus) {
>> +			if (cs_etm_is_ete(itr, cpu.cpu))

Similar problem here. For a per-thread session, the CPU map is not empty
(it's an 'any' map, presumably length 1), so it comes into this first
if, rather than the else below which is for the 'any' scenario.

Then the intersect with online CPUs results in an empty map, so no CPU
metadata is recorded, then the session fails.

If you made the intersect work in the way I mentioned above we could
also delete the else below, because that's just another way to convert
from 'any' to 'all online'.

>>  				ete++;
>> -			else if (cs_etm_is_etmv4(itr, i))
>> +			else if (cs_etm_is_etmv4(itr, cpu.cpu))
>>  				etmv4++;
>>  			else
>>  				etmv3++;
>>  		}
>> +		perf_cpu_map__put(intersect_cpus);
>>  	} else {
>>  		/* get configuration for all CPUs in the system */
>> -		for (i = 0; i < cpu__max_cpu().cpu; i++) {
>> -			struct perf_cpu cpu = { .cpu = i, };
>> -
>> -			if (!perf_cpu_map__has(online_cpus, cpu))
>> -				continue;
>> -
>> -			if (cs_etm_is_ete(itr, i))
>> +		perf_cpu_map__for_each_cpu(cpu, idx, online_cpus) {
>> +			if (cs_etm_is_ete(itr, cpu.cpu))
>>  				ete++;
>> -			else if (cs_etm_is_etmv4(itr, i))
>> +			else if (cs_etm_is_etmv4(itr, cpu.cpu))
>>  				etmv4++;
>>  			else
>>  				etmv3++;
>> @@ -814,15 +802,14 @@ static int cs_etm_info_fill(struct auxtrace_record *itr,
>>  		return -EINVAL;
>>  
>>  	/* If the cpu_map is empty all online CPUs are involved */
>> -	if (perf_cpu_map__has_any_cpu_or_is_empty(event_cpus)) {
>> +	if (perf_cpu_map__is_empty(event_cpus)) {
>>  		cpu_map = online_cpus;
>>  	} else {
>>  		/* Make sure all specified CPUs are online */
>> -		for (i = 0; i < perf_cpu_map__nr(event_cpus); i++) {
>> -			struct perf_cpu cpu = { .cpu = i, };
>> +		struct perf_cpu cpu;
>>  
>> -			if (perf_cpu_map__has(event_cpus, cpu) &&
>> -			    !perf_cpu_map__has(online_cpus, cpu))
>> +		perf_cpu_map__for_each_cpu(cpu, i, event_cpus) {
>> +			if (!perf_cpu_map__has(online_cpus, cpu))
>>  				return -EINVAL;
>>  		}
>>  
>> diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
>> index 51ccbfd3d246..0b52e67edb3b 100644
>> --- a/tools/perf/arch/arm64/util/arm-spe.c
>> +++ b/tools/perf/arch/arm64/util/arm-spe.c
>> @@ -232,7 +232,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
>>  	 * In the case of per-cpu mmaps, sample CPU for AUX event;
>>  	 * also enable the timestamp tracing for samples correlation.
>>  	 */
>> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
>> +	if (!perf_cpu_map__is_any_cpu_or_is_empty(cpus)) {
>>  		evsel__set_sample_bit(arm_spe_evsel, CPU);
>>  		evsel__set_config_if_unset(arm_spe_pmu, arm_spe_evsel,
>>  					   "ts_enable", 1);
>> @@ -265,7 +265,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
>>  	tracking_evsel->core.attr.sample_period = 1;
>>  
>>  	/* In per-cpu case, always need the time of mmap events etc */
>> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(cpus)) {
>> +	if (!perf_cpu_map__is_any_cpu_or_is_empty(cpus)) {
>>  		evsel__set_sample_bit(tracking_evsel, TIME);
>>  		evsel__set_sample_bit(tracking_evsel, CPU);
>>  


From afd at ti.com  Tue Dec 12 06:36:39 2023
From: afd at ti.com (Andrew Davis)
Date: Tue, 12 Dec 2023 08:36:39 -0600
Subject: [PATCH v3 1/2] arm64: dts: ti: k3-j721e-evm: Add overlay for
 PCIE0 Endpoint Mode
In-Reply-To: <20231211115535.1264353-2-s-vadapalli@ti.com>
References: <20231211115535.1264353-1-s-vadapalli@ti.com>
 <20231211115535.1264353-2-s-vadapalli@ti.com>
Message-ID: <5c92ae04-f8c3-40b4-a727-ac7ea5df4295@ti.com>

On 12/11/23 5:55 AM, Siddharth Vadapalli wrote:
> Add overlay to enable the PCIE0 instance of PCIe on J721E-EVM in
> Endpoint mode of operation.
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> Reviewed-by: Ravi Gunasekaran <r-gunasekaran at ti.com>
> ---
>   arch/arm64/boot/dts/ti/Makefile               |  6 ++-
>   .../boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso    | 53 +++++++++++++++++++
>   2 files changed, 58 insertions(+), 1 deletion(-)
>   create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
> 
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 1ac47876bc99..c6606b7678a3 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -67,6 +67,7 @@ k3-j721e-evm-dtbs := k3-j721e-common-proc-board.dtb k3-j721e-evm-quad-port-eth-e
>   dtb-$(CONFIG_ARCH_K3) += k3-j721e-beagleboneai64.dtb
>   dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm.dtb
>   dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-gesi-exp-board.dtbo
> +dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie0-ep.dtbo

See, much easier :)

Reviewed-by: Andrew Davis <afd at ti.com>

>   dtb-$(CONFIG_ARCH_K3) += k3-j721e-sk.dtb
>   
>   # Boards with J721s2 SoC
> @@ -103,6 +104,8 @@ k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
>   	k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
>   k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
>   	k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
> +k3-j721e-evm-pcie0-ep-dtbs := k3-j721e-common-proc-board.dtb \
> +	k3-j721e-evm-pcie0-ep.dtbo
>   dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
>   	k3-am625-beagleplay-csi2-tevi-ov5640.dtb \
>   	k3-am625-sk-csi2-imx219.dtb \
> @@ -113,7 +116,8 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
>   	k3-am62a7-sk-csi2-imx219.dtb \
>   	k3-am62a7-sk-csi2-ov5640.dtb \
>   	k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb \
> -	k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
> +	k3-am642-tqma64xxl-mbax4xxl-wlan.dtb \
> +	k3-j721e-evm-pcie0-ep.dtb
>   
>   # Enable support for device-tree overlays
>   DTC_FLAGS_k3-am625-beagleplay += -@
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso b/arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
> new file mode 100644
> index 000000000000..0c82a13b65a4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/**
> + * DT Overlay for enabling PCIE0 instance in Endpoint Configuration with the
> + * J7 common processor board.
> + *
> + * J7 Common Processor Board Product Link: https://www.ti.com/tool/J721EXCPXEVM
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +#include "k3-pinctrl.h"
> +
> +/*
> + * Since Root Complex and Endpoint modes are mutually exclusive
> + * disable Root Complex mode.
> + */
> +&pcie0_rc {
> +	status = "disabled";
> +};
> +
> +&cbass_main {
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +	interrupt-parent = <&gic500>;
> +
> +	pcie0_ep: pcie-ep at 2900000 {
> +		compatible = "ti,j721e-pcie-ep";
> +		reg = <0x00 0x02900000 0x00 0x1000>,
> +		      <0x00 0x02907000 0x00 0x400>,
> +		      <0x00 0x0d000000 0x00 0x00800000>,
> +		      <0x00 0x10000000 0x00 0x08000000>;
> +		reg-names = "intd_cfg", "user_cfg", "reg", "mem";
> +		interrupt-names = "link_state";
> +		interrupts = <GIC_SPI 318 IRQ_TYPE_EDGE_RISING>;
> +		ti,syscon-pcie-ctrl = <&scm_conf 0x4070>;
> +		max-link-speed = <3>;
> +		num-lanes = <1>;
> +		power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
> +		clocks = <&k3_clks 239 1>;
> +		clock-names = "fck";
> +		max-functions = /bits/ 8 <6>;
> +		max-virtual-functions = /bits/ 8 <4 4 4 4 0 0>;
> +		dma-coherent;
> +		phys = <&serdes0_pcie_link>;
> +		phy-names = "pcie-phy";
> +	};
> +};


From afd at ti.com  Tue Dec 12 06:38:12 2023
From: afd at ti.com (Andrew Davis)
Date: Tue, 12 Dec 2023 08:38:12 -0600
Subject: [PATCH v3 2/2] arm64: dts: ti: k3-j721s2-evm: Add overlay for
 PCIE1 Endpoint Mode
In-Reply-To: <20231211115535.1264353-3-s-vadapalli@ti.com>
References: <20231211115535.1264353-1-s-vadapalli@ti.com>
 <20231211115535.1264353-3-s-vadapalli@ti.com>
Message-ID: <977d9e00-df57-4b1e-877a-5f9137b2c0d4@ti.com>

On 12/11/23 5:55 AM, Siddharth Vadapalli wrote:
> Add overlay to enable the PCIE1 instance of PCIe on J721S2-EVM in
> Endpoint mode of operation.
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> Reviewed-by: Ravi Gunasekaran <r-gunasekaran at ti.com>
> ---

Reviewed-by: Andrew Davis <afd at ti.com>

>   arch/arm64/boot/dts/ti/Makefile               |  6 ++-
>   .../boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso   | 53 +++++++++++++++++++
>   2 files changed, 58 insertions(+), 1 deletion(-)
>   create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso
> 
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index c6606b7678a3..52c1dc910308 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -76,6 +76,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb
>   dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
>   k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
>   dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
> +dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
>   
>   # Boards with J784s4 SoC
>   dtb-$(CONFIG_ARCH_K3) += k3-am69-sk.dtb
> @@ -106,6 +107,8 @@ k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
>   	k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
>   k3-j721e-evm-pcie0-ep-dtbs := k3-j721e-common-proc-board.dtb \
>   	k3-j721e-evm-pcie0-ep.dtbo
> +k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
> +	k3-j721s2-evm-pcie1-ep.dtbo
>   dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
>   	k3-am625-beagleplay-csi2-tevi-ov5640.dtb \
>   	k3-am625-sk-csi2-imx219.dtb \
> @@ -117,7 +120,8 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
>   	k3-am62a7-sk-csi2-ov5640.dtb \
>   	k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb \
>   	k3-am642-tqma64xxl-mbax4xxl-wlan.dtb \
> -	k3-j721e-evm-pcie0-ep.dtb
> +	k3-j721e-evm-pcie0-ep.dtb \
> +	k3-j721s2-evm-pcie1-ep.dtb
>   
>   # Enable support for device-tree overlays
>   DTC_FLAGS_k3-am625-beagleplay += -@
> diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso b/arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso
> new file mode 100644
> index 000000000000..43568eb67d93
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/**
> + * DT Overlay for enabling PCIE1 instance in Endpoint Configuration with the
> + * J7 common processor board.
> + *
> + * J7 Common Processor Board Product Link: https://www.ti.com/tool/J721EXCPXEVM
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +#include "k3-pinctrl.h"
> +
> +/*
> + * Since Root Complex and Endpoint modes are mutually exclusive
> + * disable Root Complex mode.
> + */
> +&pcie1_rc {
> +	status = "disabled";
> +};
> +
> +&cbass_main {
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +	interrupt-parent = <&gic500>;
> +
> +	pcie1_ep: pcie-ep at 2910000 {
> +		compatible = "ti,j7200-pcie-ep", "ti,j721e-pcie-ep";
> +		reg = <0x00 0x02910000 0x00 0x1000>,
> +		      <0x00 0x02917000 0x00 0x400>,
> +		      <0x00 0x0d800000 0x00 0x00800000>,
> +		      <0x00 0x18000000 0x00 0x08000000>;
> +		reg-names = "intd_cfg", "user_cfg", "reg", "mem";
> +		interrupt-names = "link_state";
> +		interrupts = <GIC_SPI 330 IRQ_TYPE_EDGE_RISING>;
> +		ti,syscon-pcie-ctrl = <&scm_conf 0x074>;
> +		max-link-speed = <3>;
> +		num-lanes = <1>;
> +		power-domains = <&k3_pds 276 TI_SCI_PD_EXCLUSIVE>;
> +		clocks = <&k3_clks 276 41>;
> +		clock-names = "fck";
> +		max-functions = /bits/ 8 <6>;
> +		max-virtual-functions = /bits/ 8 <4 4 4 4 0 0>;
> +		dma-coherent;
> +		phys = <&serdes0_pcie_link>;
> +		phy-names = "pcie-phy";
> +	};
> +};


From james.clark at arm.com  Tue Dec 12 06:51:34 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 14:51:34 +0000
Subject: [PATCH v1 06/14] libperf cpumap: Add any, empty and min helpers
In-Reply-To: <63d7fe55-719e-43f8-531c-eb7fa30c473a@arm.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-7-irogers@google.com>
 <63d7fe55-719e-43f8-531c-eb7fa30c473a@arm.com>
Message-ID: <2cd09e7c-eb88-6726-6169-647dcd0a8101@arm.com>



On 12/12/2023 14:00, James Clark wrote:
> 
> 
> On 29/11/2023 06:02, Ian Rogers wrote:
>> Additional helpers to better replace
>> perf_cpu_map__has_any_cpu_or_is_empty.
>>
>> Signed-off-by: Ian Rogers <irogers at google.com>
>> ---
>>  tools/lib/perf/cpumap.c              | 27 +++++++++++++++++++++++++++
>>  tools/lib/perf/include/perf/cpumap.h | 16 ++++++++++++++++
>>  tools/lib/perf/libperf.map           |  4 ++++
>>  3 files changed, 47 insertions(+)
>>
>> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
>> index 49fc98e16514..7403819da8fd 100644
>> --- a/tools/lib/perf/cpumap.c
>> +++ b/tools/lib/perf/cpumap.c
>> @@ -316,6 +316,19 @@ bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map)
>>  	return map ? __perf_cpu_map__cpu(map, 0).cpu == -1 : true;
>>  }
>>  
>> +bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map)
>> +{
>> +	if (!map)
>> +		return true;
>> +
>> +	return __perf_cpu_map__nr(map) == 1 && __perf_cpu_map__cpu(map, 0).cpu == -1;
>> +}
>> +
>> +bool perf_cpu_map__is_empty(const struct perf_cpu_map *map)
>> +{
>> +	return map == NULL;
>> +}
>> +
> 
> Maybe it doesn't currently happen, but it seems a bit weird that the
> 'new' function can create a map of length 0 which would return empty ==
> false here.
> 
> Could we either make this check also return true for maps with length 0,
> or prevent the new function from returning a map of 0 length?
> 

By 'new' I actually meant perf_cpu_map__alloc(). I see
perf_cpu_map__new() actually takes a string, and returns all online CPUs
if the string is null, but similarly I don't see a use case where that
string is NULL.

Having something return either the parsed string, or all online CPUs if
the string was null seems like unnecessary hidden behaviour so it would
be good to remove that one too.

>>  int perf_cpu_map__idx(const struct perf_cpu_map *cpus, struct perf_cpu cpu)
>>  {
>>  	int low, high;
>> @@ -372,6 +385,20 @@ bool perf_cpu_map__has_any_cpu(const struct perf_cpu_map *map)
>>  	return map && __perf_cpu_map__cpu(map, 0).cpu == -1;
>>  }
>>  
>> +struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map)
>> +{
>> +	struct perf_cpu cpu, result = {
>> +		.cpu = -1
>> +	};
>> +	int idx;
>> +
>> +	perf_cpu_map__for_each_cpu_skip_any(cpu, idx, map) {
>> +		result = cpu;
>> +		break;
>> +	}
>> +	return result;
>> +}
>> +
>>  struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map)
>>  {
>>  	struct perf_cpu result = {
>> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
>> index dbe0a7352b64..523e4348fc96 100644
>> --- a/tools/lib/perf/include/perf/cpumap.h
>> +++ b/tools/lib/perf/include/perf/cpumap.h
>> @@ -50,6 +50,22 @@ LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
>>   * perf_cpu_map__has_any_cpu_or_is_empty - is map either empty or has the "any CPU"/dummy value.
>>   */
>>  LIBPERF_API bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map);
>> +/**
>> + * perf_cpu_map__is_any_cpu_or_is_empty - is map either empty or the "any CPU"/dummy value.
>> + */
>> +LIBPERF_API bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map);
>> +/**
>> + * perf_cpu_map__is_empty - does the map contain no values and it doesn't
>> + *                          contain the special "any CPU"/dummy value.
>> + */
>> +LIBPERF_API bool perf_cpu_map__is_empty(const struct perf_cpu_map *map);
>> +/**
>> + * perf_cpu_map__min - the minimum CPU value or -1 if empty or just the "any CPU"/dummy value.
>> + */
>> +LIBPERF_API struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map);
>> +/**
>> + * perf_cpu_map__max - the maximum CPU value or -1 if empty or just the "any CPU"/dummy value.
>> + */
>>  LIBPERF_API struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map);
>>  LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, struct perf_cpu cpu);
>>  LIBPERF_API bool perf_cpu_map__equal(const struct perf_cpu_map *lhs,
>> diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
>> index 10b3f3722642..2aa79b696032 100644
>> --- a/tools/lib/perf/libperf.map
>> +++ b/tools/lib/perf/libperf.map
>> @@ -10,6 +10,10 @@ LIBPERF_0.0.1 {
>>  		perf_cpu_map__nr;
>>  		perf_cpu_map__cpu;
>>  		perf_cpu_map__has_any_cpu_or_is_empty;
>> +		perf_cpu_map__is_any_cpu_or_is_empty;
>> +		perf_cpu_map__is_empty;
>> +		perf_cpu_map__has_any_cpu;
>> +		perf_cpu_map__min;
>>  		perf_cpu_map__max;
>>  		perf_cpu_map__has;
>>  		perf_thread_map__new_array;
> 


From david at redhat.com  Tue Dec 12 06:54:34 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 12 Dec 2023 15:54:34 +0100
Subject: [PATCH v9 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <20231207161211.2374093-4-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207161211.2374093-4-ryan.roberts@arm.com>
Message-ID: <ff7a3e9c-53cb-4283-9298-781d4fb7c7f8@redhat.com>

On 07.12.23 17:12, Ryan Roberts wrote:
> In preparation for adding support for anonymous multi-size THP,
> introduce new sysfs structure that will be used to control the new
> behaviours. A new directory is added under transparent_hugepage for each
> supported THP size, and contains an `enabled` file, which can be set to
> "inherit" (to inherit the global setting), "always", "madvise" or
> "never". For now, the kernel still only supports PMD-sized anonymous
> THP, so only 1 directory is populated.
> 
> The first half of the change converts transhuge_vma_suitable() and
> hugepage_vma_check() so that they take a bitfield of orders for which
> the user wants to determine support, and the functions filter out all
> the orders that can't be supported, given the current sysfs
> configuration and the VMA dimensions. The resulting functions are
> renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
> respectively. Convenience functions that take a single, unencoded order
> and return a boolean are also defined as thp_vma_suitable_order() and
> thp_vma_allowable_order().
> 
> The second half of the change implements the new sysfs interface. It has
> been done so that each supported THP size has a `struct thpsize`, which
> describes the relevant metadata and is itself a kobject. This is pretty
> minimal for now, but should make it easy to add new per-thpsize files to
> the interface if needed in future (e.g. per-size defrag). Rather than
> keep the `enabled` state directly in the struct thpsize, I've elected to
> directly encode it into huge_anon_orders_[always|madvise|inherit]
> bitfields since this reduces the amount of work required in
> thp_vma_allowable_orders() which is called for every page fault.
> 
> See Documentation/admin-guide/mm/transhuge.rst, as modified by this
> commit, for details of how the new sysfs interface works.
> 
> Reviewed-by: Barry Song <v-songbaohua at oppo.com>
> Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
> Tested-by: John Hubbard <jhubbard at nvidia.com>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---

[...]

> +
> +static ssize_t thpsize_enabled_store(struct kobject *kobj,
> +				     struct kobj_attribute *attr,
> +				     const char *buf, size_t count)
> +{
> +	int order = to_thpsize(kobj)->order;
> +	ssize_t ret = count;
> +
> +	if (sysfs_streq(buf, "always")) {
> +		spin_lock(&huge_anon_orders_lock);
> +		clear_bit(order, &huge_anon_orders_inherit);
> +		clear_bit(order, &huge_anon_orders_madvise);
> +		set_bit(order, &huge_anon_orders_always);
> +		spin_unlock(&huge_anon_orders_lock);
> +	} else if (sysfs_streq(buf, "inherit")) {
> +		spin_lock(&huge_anon_orders_lock);
> +		clear_bit(order, &huge_anon_orders_always);
> +		clear_bit(order, &huge_anon_orders_madvise);
> +		set_bit(order, &huge_anon_orders_inherit);
> +		spin_unlock(&huge_anon_orders_lock);
> +	} else if (sysfs_streq(buf, "madvise")) {
> +		spin_lock(&huge_anon_orders_lock);
> +		clear_bit(order, &huge_anon_orders_always);
> +		clear_bit(order, &huge_anon_orders_inherit);
> +		set_bit(order, &huge_anon_orders_madvise);
> +		spin_unlock(&huge_anon_orders_lock);
> +	} else if (sysfs_streq(buf, "never")) {
> +		spin_lock(&huge_anon_orders_lock);
> +		clear_bit(order, &huge_anon_orders_always);
> +		clear_bit(order, &huge_anon_orders_inherit);
> +		clear_bit(order, &huge_anon_orders_madvise);
> +		spin_unlock(&huge_anon_orders_lock);

Why not perform lock/unlock only once in surrounding code? :)


Much better

Acked-by: David Hildenbrand <david at redhat.com>

-- 
Cheers,

David / dhildenb



From tudor.ambarus at linaro.org  Tue Dec 12 07:02:31 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Tue, 12 Dec 2023 15:02:31 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
 <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
Message-ID: <c3fa1e04-92ed-48ab-a509-98e43abd5cd6@linaro.org>



On 12/11/23 13:37, Mahapatra, Amit Kumar wrote:

Hi!

cut

>>>>>>>  drivers/mtd/spi-nor/core.c  | 272
>>>>>>> +++++++++++++++++++++++++++++-----
>>>> --
>>>>>>>  drivers/mtd/spi-nor/core.h  |   4 +
>>>>>>>  include/linux/mtd/spi-nor.h |  15 +-
>>>>>>>  3 files changed, 240 insertions(+), 51 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/mtd/spi-nor/core.c
>>>>>>> b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6
>>>>>>> 100644
>>>>>>> --- a/drivers/mtd/spi-nor/core.c
>>>>>>> +++ b/drivers/mtd/spi-nor/core.c
>>>>>>
>>>>>> cut
>>>>>>
>>>>>>> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct
>>>>>>> spi_nor *nor)  static int spi_nor_late_init_params(struct spi_nor
>>>>>>> *nor)  {
>>>>>>>  	struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
>>>>>> 0);
>>>>>>> -	int ret;
>>>>>>> +	struct device_node *np = spi_nor_get_flash_node(nor);
>>>>>>> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
>>>>>>> +	u32 idx = 0;
>>>>>>> +	int rc, ret;
>>>>>>>
>>>>>>>  	if (nor->manufacturer && nor->manufacturer->fixups &&
>>>>>>>  	    nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44
>>>>>>> @@ static int spi_nor_late_init_params(struct spi_nor *nor)
>>>>>>>  	if (params->n_banks > 1)
>>>>>>>  		params->bank_size = div64_u64(params->size, params-
>>>> n_banks);
>>>>>>>
>>>>>>> +	nor->num_flash = 0;
>>>>>>> +
>>>>>>> +	/*
>>>>>>> +	 * The flashes that are connected in stacked mode should be
>> of
>>>>>>> +same
>>>>>> make.
>>>>>>> +	 * Except the flash size all other properties are identical for all
>> the
>>>>>>> +	 * flashes connected in stacked mode.
>>>>>>> +	 * The flashes that are connected in parallel mode should be
>> identical.
>>>>>>> +	 */
>>>>>>> +	while (idx < SNOR_FLASH_CNT_MAX) {
>>>>>>> +		rc = of_property_read_u64_index(np, "stacked-
>> memories",
>>>>>> idx,
>>>>>>> +&flash_size[idx]);
>>>>>>
>>>>>> This is a little late in my opinion, as we don't have any sanity
>>>>>> check on the flashes that are stacked on top of the first. We shall
>>>>>> at least read and compare the ID for all.
>>>>>
>>>>> Alright, I will incorporate a sanity check for reading and comparing
>>>>> the ID of the stacked flash. Subsequently, I believe this stacked
>>>>> logic should be relocated to spi_nor_get_flash_info() where we
>>>>> identify the first flash. Please share your thoughts on this.
>>>>> Additionally, do you
>>>>
>>>> I'm wondering whether we can add a layer on top of the flash type to
>>>> handle
>>>
>>> When you mention "on top," are you referring to incorporating it into
>>> the MTD layer? Initially, Miquel had submitted this patch to address
>>
>> I mean something above SPI MEM flashes, be it NOR, NANDs or whatever.
>> Instead of treating the stacked flashes as a monolithic device and treat in SPI
>> NOR some array of flashes, to have a layer above which probes the SPI MEM
>> flash driver for each stacked flash. In your case SPI NOR would be probed
>> twice, as you use 2 SPI NOR flashes.
>>
>>> stacked/parallel handling in the MTD layer.
>>> https://lore.kernel.org/linux-mtd/20200114191052.0a16d116 at xps13/t/
>>> However, the Device Tree bindings were initially not accepted.
>>
>> Okay, thanks for the pointer. I'll take a look.

haven't yet read the thread from above, but I skimmed over the AMD
controller datasheet.

>>
>>> Following a series of discussions, the below bindings were eventually
>>> merged.
>>> https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal at boot
>>> lin.com/
>>
>> I saw, thanks.
>>
>>>
>>>> the stacked/parallel modes. This way everything will become flash
>>>> type independent. Would it be possible to stack 2 SPI NANDs? How
>>>> about a SPI NOR and a SPI NAND?
>>>>
>>>> Is the datasheet of the controller public?
>>>
>>> Yes,
>>> https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Control
>>> ler
>>>
>>
>> Wonderful, I'll take a look. I see two clocks there. Does this mean that the
>> stacked flashes can be operated at different frequencies? Do you know if we
> 
> In stacked configuration, both flashes utilize a common clock (single 
> clock line). In a parallel setup, the flashes share the same clock but 
> have distinct clock lines. Please refer the diagrams in the sections 
> below for reference.
> https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Interface-Diagrams

Thanks! Can you share with us what flashes you used for testing in the
stacked and parallel configurations?

>> can combine a SPI NOR with a SPI NAND in stacked configuration?
> 
> No, Xilinx/AMD QSPI controllers doesn't support this configuration.
> 

2 SPI NANDs shall work with the AMD controller, right?

I skimmed over the QSPI controller datasheet and wondered why one would
get complicated with 2 Quad Flashes when we have Octal. But then I saw
that the same SoC can configure an Octal controller (the Octal and Quad
controllers seems mutual exclusive) and that the Octal one can operate 2
octal flashes in stacked mode :).

Cheers,
ta


From david at redhat.com  Tue Dec 12 07:02:36 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 12 Dec 2023 16:02:36 +0100
Subject: [PATCH v9 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <20231207161211.2374093-5-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207161211.2374093-5-ryan.roberts@arm.com>
Message-ID: <2bebcf33-e8b7-468d-86cc-31d6eb355b66@redhat.com>

On 07.12.23 17:12, Ryan Roberts wrote:
> Introduce the logic to allow THP to be configured (through the new sysfs
> interface we just added) to allocate large folios to back anonymous
> memory, which are larger than the base page size but smaller than
> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
> 
> mTHP continues to be PTE-mapped, but in many cases can still provide
> similar benefits to traditional PMD-sized THP: Page faults are
> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
> the configured order), but latency spikes are much less prominent
> because the size of each page isn't as huge as the PMD-sized variant and
> there is less memory to clear in each page fault. The number of per-page
> operations (e.g. ref counting, rmap management, lru list management) are
> also significantly reduced since those ops now become per-folio.

I'll note that with always-pte-mapped-thp it will be much easier to support
incremental page clearing (e.g., zero only parts of the folio and map the
remainder in a pro-non-like fashion whereby we'll zero on the next page fault).
With a PMD-sized thp, you have to eventually place/rip out page tables to
achieve that.

> 
> Some architectures also employ TLB compression mechanisms to squeeze
> more entries in when a set of PTEs are virtually and physically
> contiguous and approporiately aligned. In this case, TLB misses will
> occur less often.
> 
> The new behaviour is disabled by default, but can be enabled at runtime
> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
> (see documentation in previous commit). The long term aim is to change
> the default to include suitable lower orders, but there are some risks
> around internal fragmentation that need to be better understood first.
> 
> Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
> Tested-by: John Hubbard <jhubbard at nvidia.com>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>   include/linux/huge_mm.h |   6 ++-
>   mm/memory.c             | 111 ++++++++++++++++++++++++++++++++++++----
>   2 files changed, 106 insertions(+), 11 deletions(-)
> 
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 609c153bae57..fa7a38a30fc6 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>   #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)

[...]

> +
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
> +{
> +	struct vm_area_struct *vma = vmf->vma;
> +	unsigned long orders;
> +	struct folio *folio;
> +	unsigned long addr;
> +	pte_t *pte;
> +	gfp_t gfp;
> +	int order;
> +
> +	/*
> +	 * If uffd is active for the vma we need per-page fault fidelity to
> +	 * maintain the uffd semantics.
> +	 */
> +	if (unlikely(userfaultfd_armed(vma)))
> +		goto fallback;
> +
> +	/*
> +	 * Get a list of all the (large) orders below PMD_ORDER that are enabled
> +	 * for this vma. Then filter out the orders that can't be allocated over
> +	 * the faulting address and still be fully contained in the vma.
> +	 */
> +	orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
> +					  BIT(PMD_ORDER) - 1);
> +	orders = thp_vma_suitable_orders(vma, vmf->address, orders);
> +
> +	if (!orders)
> +		goto fallback;
> +
> +	pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
> +	if (!pte)
> +		return ERR_PTR(-EAGAIN);
> +
> +	/*
> +	 * Find the highest order where the aligned range is completely
> +	 * pte_none(). Note that all remaining orders will be completely
> +	 * pte_none().
> +	 */
> +	order = highest_order(orders);
> +	while (orders) {
> +		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> +		if (pte_range_none(pte + pte_index(addr), 1 << order))
> +			break;
> +		order = next_order(&orders, order);
> +	}
> +
> +	pte_unmap(pte);
> +
> +	/* Try allocating the highest of the remaining orders. */
> +	gfp = vma_thp_gfp_mask(vma);
> +	while (orders) {
> +		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
> +		folio = vma_alloc_folio(gfp, order, vma, addr, true);
> +		if (folio) {
> +			clear_huge_page(&folio->page, vmf->address, 1 << order);
> +			return folio;
> +		}
> +		order = next_order(&orders, order);
> +	}
> +
> +fallback:
> +	return vma_alloc_zeroed_movable_folio(vma, vmf->address);
> +}
> +#else
> +#define alloc_anon_folio(vmf) \
> +		vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
> +#endif

A neater alternative might be

static struct folio *alloc_anon_folio(struct vm_fault *vmf)
{
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
	/* magic */
fallback:
#endif
	return vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address):
}

[...]

Acked-by: David Hildenbrand <david at redhat.com>

-- 
Cheers,

David / dhildenb



From james.clark at arm.com  Tue Dec 12 07:06:39 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:06:39 +0000
Subject: [PATCH v1 06/14] libperf cpumap: Add any, empty and min helpers
In-Reply-To: <20231129060211.1890454-7-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-7-irogers@google.com>
Message-ID: <94e3745c-8c2b-bdf3-f331-1cbe56574d48@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> Additional helpers to better replace
> perf_cpu_map__has_any_cpu_or_is_empty.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>
> ---
>  tools/lib/perf/cpumap.c              | 27 +++++++++++++++++++++++++++
>  tools/lib/perf/include/perf/cpumap.h | 16 ++++++++++++++++
>  tools/lib/perf/libperf.map           |  4 ++++
>  3 files changed, 47 insertions(+)
> 
> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
> index 49fc98e16514..7403819da8fd 100644
> --- a/tools/lib/perf/cpumap.c
> +++ b/tools/lib/perf/cpumap.c
> @@ -316,6 +316,19 @@ bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map)
>  	return map ? __perf_cpu_map__cpu(map, 0).cpu == -1 : true;
>  }
>  
> +bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map)
> +{
> +	if (!map)
> +		return true;
> +
> +	return __perf_cpu_map__nr(map) == 1 && __perf_cpu_map__cpu(map, 0).cpu == -1;
> +}

I'm struggling to understand the relevance of the difference between
has_any and is_any I see that there is a slight difference, but could it
not be refactored out so we only need one?

Do you ever get an 'any' map that has more than 1 entry? It's quite a
subtle difference that is_any returns false if the first one is 'any'
but then there are subsequent entries. Whereas has_any would return
true. I'm not sure if future readers would be able to appreciate that.

I see has_any is only used twice, both on evlist->all_cpus. Is there
something about that member that means it could have a map that has an
'any' mixed with CPUs? Wouldn't that have the same result as a normal
'any' anyway?

> +
> +bool perf_cpu_map__is_empty(const struct perf_cpu_map *map)
> +{
> +	return map == NULL;
> +}
> +
>  int perf_cpu_map__idx(const struct perf_cpu_map *cpus, struct perf_cpu cpu)
>  {
>  	int low, high;
> @@ -372,6 +385,20 @@ bool perf_cpu_map__has_any_cpu(const struct perf_cpu_map *map)
>  	return map && __perf_cpu_map__cpu(map, 0).cpu == -1;
>  }
>  
> +struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map)
> +{
> +	struct perf_cpu cpu, result = {
> +		.cpu = -1
> +	};
> +	int idx;
> +
> +	perf_cpu_map__for_each_cpu_skip_any(cpu, idx, map) {
> +		result = cpu;
> +		break;
> +	}
> +	return result;
> +}
> +
>  struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map)
>  {
>  	struct perf_cpu result = {
> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> index dbe0a7352b64..523e4348fc96 100644
> --- a/tools/lib/perf/include/perf/cpumap.h
> +++ b/tools/lib/perf/include/perf/cpumap.h
> @@ -50,6 +50,22 @@ LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
>   * perf_cpu_map__has_any_cpu_or_is_empty - is map either empty or has the "any CPU"/dummy value.
>   */
>  LIBPERF_API bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map);
> +/**
> + * perf_cpu_map__is_any_cpu_or_is_empty - is map either empty or the "any CPU"/dummy value.
> + */
> +LIBPERF_API bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map);
> +/**
> + * perf_cpu_map__is_empty - does the map contain no values and it doesn't
> + *                          contain the special "any CPU"/dummy value.
> + */
> +LIBPERF_API bool perf_cpu_map__is_empty(const struct perf_cpu_map *map);
> +/**
> + * perf_cpu_map__min - the minimum CPU value or -1 if empty or just the "any CPU"/dummy value.
> + */
> +LIBPERF_API struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map);
> +/**
> + * perf_cpu_map__max - the maximum CPU value or -1 if empty or just the "any CPU"/dummy value.
> + */
>  LIBPERF_API struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map);
>  LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, struct perf_cpu cpu);
>  LIBPERF_API bool perf_cpu_map__equal(const struct perf_cpu_map *lhs,
> diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> index 10b3f3722642..2aa79b696032 100644
> --- a/tools/lib/perf/libperf.map
> +++ b/tools/lib/perf/libperf.map
> @@ -10,6 +10,10 @@ LIBPERF_0.0.1 {
>  		perf_cpu_map__nr;
>  		perf_cpu_map__cpu;
>  		perf_cpu_map__has_any_cpu_or_is_empty;
> +		perf_cpu_map__is_any_cpu_or_is_empty;
> +		perf_cpu_map__is_empty;
> +		perf_cpu_map__has_any_cpu;
> +		perf_cpu_map__min;
>  		perf_cpu_map__max;
>  		perf_cpu_map__has;
>  		perf_thread_map__new_array;


From kvalo at kernel.org  Tue Dec 12 07:09:27 2023
From: kvalo at kernel.org (Kalle Valo)
Date: Tue, 12 Dec 2023 15:09:27 +0000 (UTC)
Subject: [PATCH][next] wifi: mt76: mt7996: Use DECLARE_FLEX_ARRAY() and
 fix
 -Warray-bounds warnings
In-Reply-To: <ZVaCNAohuieMmdq9@work>
References: <ZVaCNAohuieMmdq9@work>
Message-ID: <170239376588.306086.11901816078975577906.kvalo@kernel.org>

"Gustavo A. R. Silva" <gustavoars at kernel.org> wrote:

> Transform zero-length arrays `adm_stat` and `msdu_cnt` into proper
> flexible-array members in anonymous union in `struct
> mt7996_mcu_all_sta_info_event` via the DECLARE_FLEX_ARRAY()
> helper; and fix multiple -Warray-bounds warnings:
> 
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:483:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:490:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:492:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:469:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:477:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:479:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> 
> This results in no differences in binary output, helps with the ongoing
> efforts to globally enable -Warray-bounds.
> 
> Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org>
> Reviewed-by: Kees Cook <keescook at chromium.org>

Fails to apply, please rebase on top of wireless-next.

Recorded preimage for 'drivers/net/wireless/mediatek/mt76/mt7996/mcu.h'
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Applying: wifi: mt76: mt7996: Use DECLARE_FLEX_ARRAY() and fix -Warray-bounds warnings
Using index info to reconstruct a base tree...
M	drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
CONFLICT (content): Merge conflict in drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
Patch failed at 0001 wifi: mt76: mt7996: Use DECLARE_FLEX_ARRAY() and fix -Warray-bounds warnings

Patch set to Changes Requested.

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/ZVaCNAohuieMmdq9 at work/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From james.clark at arm.com  Tue Dec 12 07:10:31 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:10:31 +0000
Subject: [PATCH v1 09/14] perf cpumap: Clean up use of
 perf_cpu_map__has_any_cpu_or_is_empty
In-Reply-To: <20231129060211.1890454-10-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-10-irogers@google.com>
Message-ID: <b9165c97-1097-6bc8-751a-2bc2ac464edb@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> Most uses of what was perf_cpu_map__empty but is now
> perf_cpu_map__has_any_cpu_or_is_empty want to do something with the
> CPU map if it contains CPUs. Replace uses of
> perf_cpu_map__has_any_cpu_or_is_empty with other helpers so that CPUs
> within the map can be handled.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>

Reviewed-by: James Clark <james.clark at arm.com>

> ---
>  tools/perf/builtin-c2c.c   | 6 +-----
>  tools/perf/builtin-stat.c  | 9 ++++-----
>  tools/perf/util/auxtrace.c | 4 ++--
>  tools/perf/util/record.c   | 2 +-
>  tools/perf/util/stat.c     | 2 +-
>  5 files changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
> index f78eea9e2153..ef7ed53a4b4e 100644
> --- a/tools/perf/builtin-c2c.c
> +++ b/tools/perf/builtin-c2c.c
> @@ -2319,11 +2319,7 @@ static int setup_nodes(struct perf_session *session)
>  
>  		nodes[node] = set;
>  
> -		/* empty node, skip */
> -		if (perf_cpu_map__has_any_cpu_or_is_empty(map))
> -			continue;
> -
> -		perf_cpu_map__for_each_cpu(cpu, idx, map) {
> +		perf_cpu_map__for_each_cpu_skip_any(cpu, idx, map) {
>  			__set_bit(cpu.cpu, set);
>  
>  			if (WARN_ONCE(cpu2node[cpu.cpu] != -1, "node/cpu topology bug"))
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 3303aa20f326..f583027a0639 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -1316,10 +1316,9 @@ static int cpu__get_cache_id_from_map(struct perf_cpu cpu, char *map)
>  	 * be the first online CPU in the cache domain else use the
>  	 * first online CPU of the cache domain as the ID.
>  	 */
> -	if (perf_cpu_map__has_any_cpu_or_is_empty(cpu_map))
> +	id = perf_cpu_map__min(cpu_map).cpu;
> +	if (id == -1)
>  		id = cpu.cpu;
> -	else
> -		id = perf_cpu_map__cpu(cpu_map, 0).cpu;
>  
>  	/* Free the perf_cpu_map used to find the cache ID */
>  	perf_cpu_map__put(cpu_map);
> @@ -1622,7 +1621,7 @@ static int perf_stat_init_aggr_mode(void)
>  	 * taking the highest cpu number to be the size of
>  	 * the aggregation translate cpumap.
>  	 */
> -	if (!perf_cpu_map__has_any_cpu_or_is_empty(evsel_list->core.user_requested_cpus))
> +	if (!perf_cpu_map__is_any_cpu_or_is_empty(evsel_list->core.user_requested_cpus))
>  		nr = perf_cpu_map__max(evsel_list->core.user_requested_cpus).cpu;
>  	else
>  		nr = 0;
> @@ -2289,7 +2288,7 @@ int process_stat_config_event(struct perf_session *session,
>  
>  	perf_event__read_stat_config(&stat_config, &event->stat_config);
>  
> -	if (perf_cpu_map__has_any_cpu_or_is_empty(st->cpus)) {
> +	if (perf_cpu_map__is_empty(st->cpus)) {
>  		if (st->aggr_mode != AGGR_UNSET)
>  			pr_warning("warning: processing task data, aggregation mode not set\n");
>  	} else if (st->aggr_mode != AGGR_UNSET) {
> diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
> index 3684e6009b63..6b1d4bafad59 100644
> --- a/tools/perf/util/auxtrace.c
> +++ b/tools/perf/util/auxtrace.c
> @@ -174,7 +174,7 @@ void auxtrace_mmap_params__set_idx(struct auxtrace_mmap_params *mp,
>  				   struct evlist *evlist,
>  				   struct evsel *evsel, int idx)
>  {
> -	bool per_cpu = !perf_cpu_map__has_any_cpu_or_is_empty(evlist->core.user_requested_cpus);
> +	bool per_cpu = !perf_cpu_map__has_any_cpu(evlist->core.user_requested_cpus);
>  
>  	mp->mmap_needed = evsel->needs_auxtrace_mmap;
>  
> @@ -648,7 +648,7 @@ int auxtrace_parse_snapshot_options(struct auxtrace_record *itr,
>  
>  static int evlist__enable_event_idx(struct evlist *evlist, struct evsel *evsel, int idx)
>  {
> -	bool per_cpu_mmaps = !perf_cpu_map__has_any_cpu_or_is_empty(evlist->core.user_requested_cpus);
> +	bool per_cpu_mmaps = !perf_cpu_map__has_any_cpu(evlist->core.user_requested_cpus);
>  
>  	if (per_cpu_mmaps) {
>  		struct perf_cpu evlist_cpu = perf_cpu_map__cpu(evlist->core.all_cpus, idx);
> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
> index 87e817b3cf7e..e867de8ddaaa 100644
> --- a/tools/perf/util/record.c
> +++ b/tools/perf/util/record.c
> @@ -237,7 +237,7 @@ bool evlist__can_select_event(struct evlist *evlist, const char *str)
>  
>  	evsel = evlist__last(temp_evlist);
>  
> -	if (!evlist || perf_cpu_map__has_any_cpu_or_is_empty(evlist->core.user_requested_cpus)) {
> +	if (!evlist || perf_cpu_map__is_any_cpu_or_is_empty(evlist->core.user_requested_cpus)) {
>  		struct perf_cpu_map *cpus = perf_cpu_map__new_online_cpus();
>  
>  		if (cpus)
> diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
> index 012c4946b9c4..915808a6211a 100644
> --- a/tools/perf/util/stat.c
> +++ b/tools/perf/util/stat.c
> @@ -315,7 +315,7 @@ static int check_per_pkg(struct evsel *counter, struct perf_counts_values *vals,
>  	if (!counter->per_pkg)
>  		return 0;
>  
> -	if (perf_cpu_map__has_any_cpu_or_is_empty(cpus))
> +	if (perf_cpu_map__is_any_cpu_or_is_empty(cpus))
>  		return 0;
>  
>  	if (!mask) {


From james.clark at arm.com  Tue Dec 12 07:11:53 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:11:53 +0000
Subject: [PATCH v1 10/14] perf top: Avoid repeated function calls
In-Reply-To: <20231129060211.1890454-11-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-11-irogers@google.com>
Message-ID: <e067c360-56ac-1756-3b3b-4bf5f663be87@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> Add a local variable to avoid repeated calls to perf_cpu_map__nr.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>

Reviewed-by: James Clark <james.clark at arm.com>

> ---
>  tools/perf/util/top.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/perf/util/top.c b/tools/perf/util/top.c
> index be7157de0451..4db3d1bd686c 100644
> --- a/tools/perf/util/top.c
> +++ b/tools/perf/util/top.c
> @@ -28,6 +28,7 @@ size_t perf_top__header_snprintf(struct perf_top *top, char *bf, size_t size)
>  	struct record_opts *opts = &top->record_opts;
>  	struct target *target = &opts->target;
>  	size_t ret = 0;
> +	int nr_cpus;
>  
>  	if (top->samples) {
>  		samples_per_sec = top->samples / top->delay_secs;
> @@ -93,19 +94,17 @@ size_t perf_top__header_snprintf(struct perf_top *top, char *bf, size_t size)
>  	else
>  		ret += SNPRINTF(bf + ret, size - ret, " (all");
>  
> +	nr_cpus = perf_cpu_map__nr(top->evlist->core.user_requested_cpus);
>  	if (target->cpu_list)
>  		ret += SNPRINTF(bf + ret, size - ret, ", CPU%s: %s)",
> -				perf_cpu_map__nr(top->evlist->core.user_requested_cpus) > 1
> -				? "s" : "",
> +				nr_cpus > 1 ? "s" : "",
>  				target->cpu_list);
>  	else {
>  		if (target->tid)
>  			ret += SNPRINTF(bf + ret, size - ret, ")");
>  		else
>  			ret += SNPRINTF(bf + ret, size - ret, ", %d CPU%s)",
> -					perf_cpu_map__nr(top->evlist->core.user_requested_cpus),
> -					perf_cpu_map__nr(top->evlist->core.user_requested_cpus) > 1
> -					? "s" : "");
> +					nr_cpus, nr_cpus > 1 ? "s" : "");
>  	}
>  
>  	perf_top__reset_sample_counters(top);


From james.clark at arm.com  Tue Dec 12 07:13:20 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:13:20 +0000
Subject: [PATCH v1 11/14] perf arm64 header: Remove unnecessary CPU map
 get and put
In-Reply-To: <20231129060211.1890454-12-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-12-irogers@google.com>
Message-ID: <5e2e56cf-9177-cb83-f88b-bd6592260a05@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> In both cases the CPU map is known owned by either the caller or a
> PMU.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>

Reviewed-by: James Clark <james.clark at arm.com>

> ---
>  tools/perf/arch/arm64/util/header.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/tools/perf/arch/arm64/util/header.c b/tools/perf/arch/arm64/util/header.c
> index 97037499152e..a9de0b5187dd 100644
> --- a/tools/perf/arch/arm64/util/header.c
> +++ b/tools/perf/arch/arm64/util/header.c
> @@ -25,8 +25,6 @@ static int _get_cpuid(char *buf, size_t sz, struct perf_cpu_map *cpus)
>  	if (!sysfs || sz < MIDR_SIZE)
>  		return EINVAL;
>  
> -	cpus = perf_cpu_map__get(cpus);
> -
>  	for (cpu = 0; cpu < perf_cpu_map__nr(cpus); cpu++) {
>  		char path[PATH_MAX];
>  		FILE *file;
> @@ -51,7 +49,6 @@ static int _get_cpuid(char *buf, size_t sz, struct perf_cpu_map *cpus)
>  		break;
>  	}
>  
> -	perf_cpu_map__put(cpus);
>  	return ret;
>  }
>  


From afd at ti.com  Tue Dec 12 07:19:07 2023
From: afd at ti.com (Andrew Davis)
Date: Tue, 12 Dec 2023 09:19:07 -0600
Subject: [PATCH] soc: ti: k3-socinfo: Add JTAG ID for J722S
In-Reply-To: <20231211132600.25289-1-vaishnav.a@ti.com>
References: <20231211132600.25289-1-vaishnav.a@ti.com>
Message-ID: <81f90d13-da10-4a68-a0e7-95212f40b3e8@ti.com>

On 12/11/23 7:26 AM, Vaishnav Achath wrote:
> Add JTAG ID info for the J722S SoC family to enable SoC detection.
> 
> More details about this SoC can be found in the TRM:
> 	https://www.ti.com/lit/zip/sprujb3
> 
> Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
> ---

Simple enough,

Reviewed-by: Andrew Davis <afd at ti.com>

Although I do question our use of the J7x names. All of our parts here
also have a "Sitara AMxx" branding. For instance here we could call
this new device by its "AM67" name, then J784S4 renamed as AM69, etc.
Then we would have a consistent naming (internally we will have to deal
with the part name madness, but why expose that externally if we don't
have to).

Andrew

> 
> Bootlog with changes:
> https://gist.github.com/vaishnavachath/23d859925277df9ccd628190e7c23371
> 
>   drivers/soc/ti/k3-socinfo.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
> index 7517a9c8c8fa..59101bf7cf23 100644
> --- a/drivers/soc/ti/k3-socinfo.c
> +++ b/drivers/soc/ti/k3-socinfo.c
> @@ -42,6 +42,7 @@
>   #define JTAG_ID_PARTNO_J784S4		0xBB80
>   #define JTAG_ID_PARTNO_AM62AX		0xBB8D
>   #define JTAG_ID_PARTNO_AM62PX		0xBB9D
> +#define JTAG_ID_PARTNO_J722S		0xBBA0
>   
>   static const struct k3_soc_id {
>   	unsigned int id;
> @@ -56,6 +57,7 @@ static const struct k3_soc_id {
>   	{ JTAG_ID_PARTNO_J784S4, "J784S4" },
>   	{ JTAG_ID_PARTNO_AM62AX, "AM62AX" },
>   	{ JTAG_ID_PARTNO_AM62PX, "AM62PX" },
> +	{ JTAG_ID_PARTNO_J722S, "J722S" },
>   };
>   
>   static const char * const j721e_rev_string_map[] = {


From james.clark at arm.com  Tue Dec 12 07:20:47 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:20:47 +0000
Subject: [PATCH v1 14/14] libperf cpumap: Document perf_cpu_map__nr's
 behavior
In-Reply-To: <20231129060211.1890454-15-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-15-irogers@google.com>
Message-ID: <0e1ca950-b5a4-1e08-8696-4e3e12e21b19@arm.com>



On 29/11/2023 06:02, Ian Rogers wrote:
> perf_cpu_map__nr's behavior around an empty CPU map is strange as it
> returns that there is 1 CPU. Changing code that may rely on this
> behavior is hard, we can at least document the behavior.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>
> ---
>  tools/lib/perf/include/perf/cpumap.h | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> index 523e4348fc96..90457d17fb2f 100644
> --- a/tools/lib/perf/include/perf/cpumap.h
> +++ b/tools/lib/perf/include/perf/cpumap.h
> @@ -44,7 +44,18 @@ LIBPERF_API struct perf_cpu_map *perf_cpu_map__merge(struct perf_cpu_map *orig,
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__intersect(struct perf_cpu_map *orig,
>  							 struct perf_cpu_map *other);
>  LIBPERF_API void perf_cpu_map__put(struct perf_cpu_map *map);
> +/**
> + * perf_cpu_map__cpu - get the CPU value at the given index. Returns -1 if index
> + *                     is invalid.
> + */
>  LIBPERF_API struct perf_cpu perf_cpu_map__cpu(const struct perf_cpu_map *cpus, int idx);
> +/**
> + * perf_cpu_map__nr - for an empty map returns 1, as perf_cpu_map__cpu returns a
> + *                    cpu of -1 for an invalid index, this makes an empty map
> + *                    look like it contains the "any CPU"/dummy value. Otherwise
> + *                    the result is the number CPUs in the map plus one if the
> + *                    "any CPU"/dummy value is present.

Hmmm... I'm not sure whether to laugh or cry at that API.

Reviewed-by: James Clark <james.clark at arm.com>

> + */
>  LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
>  /**
>   * perf_cpu_map__has_any_cpu_or_is_empty - is map either empty or has the "any CPU"/dummy value.


From linux at roeck-us.net  Tue Dec 12 07:22:18 2023
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 12 Dec 2023 07:22:18 -0800
Subject: [PATCH v8 1/6] pwm: Rename pwm_apply_state() to
 pwm_apply_might_sleep()
In-Reply-To: <20231212114100.sn7nzntousql2ays@pengutronix.de>
References: <cover.1702369869.git.sean@mess.org>
 <9af7ba748fd2eb7e04208b6b183185f1daf78016.1702369869.git.sean@mess.org>
 <20231212114100.sn7nzntousql2ays@pengutronix.de>
Message-ID: <f7be8d89-25ae-4d83-9577-12fcac41d0ab@roeck-us.net>

On 12/12/23 03:41, Uwe Kleine-K?nig wrote:
> On Tue, Dec 12, 2023 at 08:34:00AM +0000, Sean Young wrote:
>> In order to introduce a pwm api which can be used from atomic context,
>> we will need two functions for applying pwm changes:
>>
>> 	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
>> 	int pwm_apply_atomic(struct pwm *, struct pwm_state *);
>>
>> This commit just deals with renaming pwm_apply_state(), a following
>> commit will introduce the pwm_apply_atomic() function.
>>
>> Acked-by: Dmitry Torokhov <dmitry.torokhov at gmail.com> # for input
>> Acked-by: Hans de Goede <hdegoede at redhat.com>
>> Acked-by: Jani Nikula <jani.nikula at intel.com>
>> Acked-by: Lee Jones <lee at kernel.org>
>> Signed-off-by: Sean Young <sean at mess.org>
> 
> Acked-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> 
> Several affected maintainers already acked, so I guess it's fine to take
> this via the pwm tree. An Ack from the remaining maintainers would be
> very welcome, an alternative would be to split the patch.
> 
> Missing Acks so far:
> 
>   - Jean Delvare / Guenter Roeck for drivers/hwmon/pwm-fan.c
>   - Javier Martinez Canillas for drivers/gpu/drm/solomon/ssd130x.c
>   - Liam Girdwood / Mark Brown for drivers/regulator/pwm-regulator.c
>   - Helge Deller for drivers/video/fbdev/ssd1307fb.c
> 
> Best regards
> Uwe
> 


Personally I find the change unnecessary and pointless, which is why I
didn't ack it. Even if function names were deemed important enough, keeping
pwm_apply_state() for the time being and just adding pwm_apply_might_sleep()
as duplicate would have done it, all the changes could have gone in long
ago, and per-subsystem cleanup could have been orthogonal.

I refrained from commenting because it might be considered bike shedding,
but I don't want to ack something I deem unnecessary and pointless without
comment. But then don't want to keep arguing either, so

Acked-by: Guenter Roeck <linux at roeck-us.net>

Guenter



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:44 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:44 +0100
Subject: [PATCH v8 01/13] dt-bindings: document generic access controllers
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-2-gatien.chevallier@foss.st.com>

From: Oleksii Moisieiev <Oleksii_Moisieiev at epam.com>

Introducing of the generic access controllers bindings for the
access controller provider and consumer devices. Those bindings are
intended to allow a better handling of accesses to resources in a
hardware architecture supporting several compartments.

This patch is based on [1]. It is integrated in this patchset as it
provides a use-case for it.

Diffs with [1]:
	- Rename feature-domain* properties to access-control* to narrow
	  down the scope of the binding
	- YAML errors and typos corrected.
	- Example updated
	- Some rephrasing in the binding description

[1]: https://lore.kernel.org/lkml/0c0a82bb-18ae-d057-562b

Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev at epam.com>
Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
	- Renamed access-controller to access-controllers
	- Example updated
	- Removal of access-control-provider property

Changes in V5:
	- Diffs with [1]
	- Discarded the [IGNORE] tag as the patch is now part of the
	  patchset

 .../access-controllers.yaml                   | 84 +++++++++++++++++++
 1 file changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/access-controllers/access-controllers.yaml

diff --git a/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
new file mode 100644
index 000000000000..99e2865f0e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/access-controllers/access-controllers.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Domain Access Controllers
+
+maintainers:
+  - Oleksii Moisieiev <oleksii_moisieiev at epam.com>
+
+description: |+
+  Common access controllers properties
+
+  Access controllers are in charge of stating which of the hardware blocks under
+  their responsibility (their domain) can be accesssed by which compartment. A
+  compartment can be a cluster of CPUs (or coprocessors), a range of addresses
+  or a group of hardware blocks. An access controller's domain is the set of
+  resources covered by the access controller.
+
+  This device tree binding can be used to bind devices to their access
+  controller provided by access-controllers property. In this case, the device
+  is a consumer and the access controller is the provider.
+
+  An access controller can be represented by any node in the device tree and
+  can provide one or more configuration parameters, needed to control parameters
+  of the consumer device. A consumer node can refer to the provider by phandle
+  and a set of phandle arguments, specified by '#access-controller-cells'
+  property in the access controller node.
+
+  Access controllers are typically used to set/read the permissions of a
+  hardware block and grant access to it. Any of which depends on the access
+  controller. The capabilities of each access controller are defined by the
+  binding of the access controller device.
+
+  Each node can be a consumer for the several access controllers.
+
+# always select the core schema
+select: true
+
+properties:
+  "#access-controller-cells":
+    description:
+      Number of cells in an access-controllers specifier;
+      Can be any value as specified by device tree binding documentation
+      of a particular provider. The node is an access controller.
+
+  access-controller-names:
+    $ref: /schemas/types.yaml#/definitions/string-array
+    description:
+      A list of access-controllers names, sorted in the same order as
+      access-controllers entries. Consumer drivers will use
+      access-controller-names to match with existing access-controllers entries.
+
+  access-controllers:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description:
+      A list of access controller specifiers, as defined by the
+      bindings of the access-controllers provider.
+
+additionalProperties: true
+
+examples:
+  - |
+    clock_controller: access-controllers at 50000 {
+        reg = <0x50000 0x400>;
+        #access-controller-cells = <2>;
+    };
+
+    bus_controller: bus at 60000 {
+        reg = <0x60000 0x10000>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+        #access-controller-cells = <3>;
+
+        uart4: serial at 60100 {
+            reg = <0x60100 0x400>;
+            clocks = <&clk_serial>;
+            access-controllers = <&clock_controller 1 2>,
+                                 <&bus_controller 1 3 5>;
+            access-controller-names = "clock", "bus";
+        };
+    };
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:43 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:43 +0100
Subject: [PATCH v8 00/13] Introduce STM32 Firewall framework
Message-ID: <20231212152356.345703-1-gatien.chevallier@foss.st.com>

Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x
platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers
register to the framework to offer firewall services such as access
granting.

This series of patches is a new approach on the previous STM32 system
bus, history is available here:
https://lore.kernel.org/lkml/20230127164040.1047583/

The need for such framework arises from the fact that there are now
multiple hardware firewalls implemented across multiple products.
Drivers are shared between different products, using the same code.
When it comes to firewalls, the purpose mostly stays the same: Protect
hardware resources. But the implementation differs, and there are
multiple types of firewalls: peripheral, memory, ... 

Some hardware firewall controllers such as the RIFSC implemented on
STM32MP2x platforms may require to take ownership of a resource before
being able to use it, hence the requirement for firewall services to
take/release the ownership of such resources.

On the other hand, hardware firewall configurations are becoming
more and more complex. These mecanisms prevent platform crashes
or other firewall-related incoveniences by denying access to some
resources.

The stm32 firewall framework offers an API that is defined in
firewall controllers drivers to best fit the specificity of each
firewall.

For every peripherals protected by either the ETZPC or the RIFSC, the
firewall framework checks the firewall controlelr registers to see if
the peripheral's access is granted to the Linux kernel. If not, the
peripheral is configured as secure, the node is marked populated,
so that the driver is not probed for that device.

The firewall framework relies on the access-controller device tree
binding. It is used by peripherals to reference a domain access
controller. In this case a firewall controller. The bus uses the ID
referenced by the access-controller property to know where to look
in the firewall to get the security configuration for the peripheral.
This allows a device tree description rather than a hardcoded peripheral
table in the bus driver.

The STM32 ETZPC device is responsible for filtering accesses based on
security level, or co-processor isolation for any resource connected
to it.

The RIFSC is responsible for filtering accesses based on Compartment
ID / security level / privilege level for any resource connected to
it.

STM32MP13/15/25 SoC device tree files are updated in this series to
implement this mecanism.

Changes in V8:
	- Add missing "simple-bus" compatible in STM32MP13/25 SoC
	  device tree files for the ETZPC/RIFSC nodes
	- Add missing dependency on OF for OF_DYNAMIC that is selected
	  by STM32_FIREWALL

Changes in V7:
	- Separate indentation changes from access-controllers changes
	  in the device tree file commits
	- Select OF_DYNAMIC when STM32_FIREWALL is set in order to use
	  of_detach_node() in the firewall framework
	- Handle previously non-present RNG and HASH nodes in the
	  STM32MP13 device tree file

Changes in V6:
	- Rename access-controller to access-controllers
	- Remove access-controller-provider
	- Update device trees and other bindings accordingly
	- Rework ETZPC/RIFSC bindings to define what access-controllers
	  cells contain inside #access-controller-cells
	- Some other minor fixes

Changes in V5:
	- Integrate and rework the "feature-domains" binding patch in
	  this patchset. The binding is renamed to "access-controller"
	- Rename every feature-domain* reference to access-control*
	  ones
	- Correct loop bug and missing select STM32_FIREWALL in 32-bit
	  platform Kconfig
	

Changes in V4:
	- Fix typo in commit message and YAML check errors in
	  "dt-bindings: Document common device controller bindings"
	  Note: This patch should be ignored as stated in the cover
	  letter. I've done this to avoid errors on this series of
	  patch
	- Correct code syntax/style issues reported by Simon Horman
	- Added Jonathan's tag for IIO on the treewide patch

Changes in V3:

	Change incorrect ordering for bindings commits leading
	to an error while running
	"make DT_CHECKER_FLAGS=-m dt_binding_check"

Changes in V2:

	generic:
		- Add fw_devlink dependency for "feature-domains"
		  property.

	bindings:
		- Corrected YAMLS errors highlighted by Rob's robot
		- Firewall controllers YAMLs no longer define the
		  maxItems for the "feature-domains" property
		- Renamed st,stm32-rifsc.yaml to
		  st,stm32mp25-rifsc.yaml
		- Fix examples in YAML files
		- Change feature-domains maxItems to 2 in firewall
		  consumer files as there should not be more than
		  2 entries for now
		- Declare "feature-domain-names" as an optional
		  property for firewall controllers child nodes.
		- Add missing "feature-domains" property declaration
		  in bosch,m_can.yaml and st,stm32-cryp.yaml files

	firewall framework:
		- Support multiple entries for "feature-domains"
		  property
		- Better handle the device-tree parsing using
		  phandle+args APIs
		- Remove "resource firewall" type
		- Add a field for the name of the firewall entry
		- Fix licenses
	
	RIFSC:
		- Add controller name
		- Driver is now a module_platform_driver
		- Fix license

	ETZPC:
		- Add controller name
		- Driver is now a module_platform_driver
		- Fix license

	Device trees:
		- Fix rifsc node name
		- Move the "ranges" property under the
		  "feature-domains" one

Gatien Chevallier (12):
  dt-bindings: treewide: add access-controllers description
  dt-bindings: bus: document RIFSC
  dt-bindings: bus: document ETZPC
  firewall: introduce stm32_firewall framework
  of: property: fw_devlink: Add support for "access-controller"
  bus: rifsc: introduce RIFSC firewall controller driver
  arm64: dts: st: add RIFSC as an access controller for STM32MP25x
    boards
  bus: etzpc: introduce ETZPC firewall controller driver
  ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
  ARM: dts: stm32: put ETZPC as an access controller for STM32MP15x
    boards
  ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards
  ARM: dts: stm32: put ETZPC as an access controller for STM32MP13x
    boards

Oleksii Moisieiev (1):
  dt-bindings: document generic access controllers

 .../access-controllers.yaml                   |   84 +
 .../bindings/bus/st,stm32-etzpc.yaml          |   87 +
 .../bindings/bus/st,stm32mp25-rifsc.yaml      |   96 +
 .../bindings/crypto/st,stm32-cryp.yaml        |    4 +
 .../bindings/crypto/st,stm32-hash.yaml        |    4 +
 .../devicetree/bindings/dma/st,stm32-dma.yaml |    4 +
 .../bindings/dma/st,stm32-dmamux.yaml         |    4 +
 .../devicetree/bindings/i2c/st,stm32-i2c.yaml |    4 +
 .../bindings/iio/adc/st,stm32-adc.yaml        |    4 +
 .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml  |    4 +
 .../bindings/iio/dac/st,stm32-dac.yaml        |    4 +
 .../bindings/media/cec/st,stm32-cec.yaml      |    4 +
 .../bindings/media/st,stm32-dcmi.yaml         |    4 +
 .../memory-controllers/st,stm32-fmc2-ebi.yaml |    4 +
 .../bindings/mfd/st,stm32-lptimer.yaml        |    4 +
 .../bindings/mfd/st,stm32-timers.yaml         |    4 +
 .../devicetree/bindings/mmc/arm,pl18x.yaml    |    4 +
 .../bindings/net/can/bosch,m_can.yaml         |    4 +
 .../devicetree/bindings/net/stm32-dwmac.yaml  |    4 +
 .../bindings/phy/phy-stm32-usbphyc.yaml       |    4 +
 .../bindings/regulator/st,stm32-vrefbuf.yaml  |    4 +
 .../devicetree/bindings/rng/st,stm32-rng.yaml |    4 +
 .../bindings/serial/st,stm32-uart.yaml        |    4 +
 .../bindings/sound/st,stm32-i2s.yaml          |    4 +
 .../bindings/sound/st,stm32-sai.yaml          |    4 +
 .../bindings/sound/st,stm32-spdifrx.yaml      |    4 +
 .../bindings/spi/st,stm32-qspi.yaml           |    4 +
 .../devicetree/bindings/spi/st,stm32-spi.yaml |    4 +
 .../devicetree/bindings/usb/dwc2.yaml         |    4 +
 MAINTAINERS                                   |    7 +
 arch/arm/boot/dts/st/stm32mp131.dtsi          | 1063 ++++---
 arch/arm/boot/dts/st/stm32mp133.dtsi          |   51 +-
 arch/arm/boot/dts/st/stm32mp13xc.dtsi         |   19 +-
 arch/arm/boot/dts/st/stm32mp13xf.dtsi         |   19 +-
 arch/arm/boot/dts/st/stm32mp151.dtsi          | 2756 +++++++++--------
 arch/arm/boot/dts/st/stm32mp153.dtsi          |   52 +-
 arch/arm/boot/dts/st/stm32mp15xc.dtsi         |   19 +-
 arch/arm/mach-stm32/Kconfig                   |    1 +
 arch/arm64/Kconfig.platforms                  |    1 +
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |    7 +-
 drivers/bus/Kconfig                           |   10 +
 drivers/bus/Makefile                          |    1 +
 drivers/bus/stm32_etzpc.c                     |  141 +
 drivers/bus/stm32_firewall.c                  |  294 ++
 drivers/bus/stm32_firewall.h                  |   83 +
 drivers/bus/stm32_rifsc.c                     |  252 ++
 drivers/of/property.c                         |    2 +
 include/linux/bus/stm32_firewall_device.h     |  141 +
 48 files changed, 3352 insertions(+), 1938 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
 create mode 100644 Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
 create mode 100644 Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
 create mode 100644 drivers/bus/stm32_etzpc.c
 create mode 100644 drivers/bus/stm32_firewall.c
 create mode 100644 drivers/bus/stm32_firewall.h
 create mode 100644 drivers/bus/stm32_rifsc.c
 create mode 100644 include/linux/bus/stm32_firewall_device.h

-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:46 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:46 +0100
Subject: [PATCH v8 03/13] dt-bindings: bus: document RIFSC
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-4-gatien.chevallier@foss.st.com>

Document RIFSC (RIF security controller). RIFSC is a firewall controller
composed of different kinds of hardware resources.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
	- Renamed access-controller to access-controllers
	- Removal of access-control-provider property
	- Removal of access-controller and access-controller-names
	  declaration in the patternProperties field. Add
	  additionalProperties: true in this field.

Changes in V5:
	- Renamed feature-domain* to access-control*

Changes in V2:
	- Corrected errors highlighted by Rob's robot
	- No longer define the maxItems for the "feature-domains"
	  property
	- Fix example (node name, status)
	- Declare "feature-domain-names" as an optional
	  property for child nodes
	- Fix description of "feature-domains" property

 .../bindings/bus/st,stm32mp25-rifsc.yaml      | 96 +++++++++++++++++++
 1 file changed, 96 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml

diff --git a/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
new file mode 100644
index 000000000000..95aa7f04c739
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/st,stm32mp25-rifsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Resource isolation framework security controller
+
+maintainers:
+  - Gatien Chevallier <gatien.chevallier at foss.st.com>
+
+description: |
+  Resource isolation framework (RIF) is a comprehensive set of hardware blocks
+  designed to enforce and manage isolation of STM32 hardware resources like
+  memory and peripherals.
+
+  The RIFSC (RIF security controller) is composed of three sets of registers,
+  each managing a specific set of hardware resources:
+    - RISC registers associated with RISUP logic (resource isolation device unit
+      for peripherals), assign all non-RIF aware peripherals to zero, one or
+      any security domains (secure, privilege, compartment).
+    - RIMC registers: associated with RIMU logic (resource isolation master
+      unit), assign all non RIF-aware bus master to one security domain by
+      setting secure, privileged and compartment information on the system bus.
+      Alternatively, the RISUP logic controlling the device port access to a
+      peripheral can assign target bus attributes to this peripheral master port
+      (supported attribute: CID).
+    - RISC registers associated with RISAL logic (resource isolation device unit
+      for address space - Lite version), assign address space subregions to one
+      security domains (secure, privilege, compartment).
+
+properties:
+  compatible:
+    contains:
+      const: st,stm32mp25-rifsc
+
+  reg:
+    maxItems: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 1
+
+  ranges: true
+
+  "#access-controller-cells":
+    const: 1
+    description:
+      Contains the firewall ID associated to the peripheral.
+
+patternProperties:
+  "^.*@[0-9a-f]+$":
+    description: Peripherals
+    type: object
+
+    additionalProperties: true
+
+    required:
+      - access-controllers
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+  - "#access-controller-cells"
+  - ranges
+
+additionalProperties: false
+
+examples:
+  - |
+    // In this example, the usart2 device refers to rifsc as its domain
+    // controller.
+    // Access rights are verified before creating devices.
+
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    rifsc: bus at 42080000 {
+        compatible = "st,stm32mp25-rifsc";
+        reg = <0x42080000 0x1000>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        #access-controller-cells = <1>;
+        ranges;
+
+        usart2: serial at 400e0000 {
+              compatible = "st,stm32h7-uart";
+              reg = <0x400e0000 0x400>;
+              interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+              clocks = <&ck_flexgen_08>;
+              access-controllers = <&rifsc 32>;
+        };
+    };
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:45 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:45 +0100
Subject: [PATCH v8 02/13] dt-bindings: treewide: add access-controllers description
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-3-gatien.chevallier@foss.st.com>

access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).

Description of this property is added to all peripheral binding files of
the peripheral under the STM32 firewall controller. It allows an accurate
representation of the hardware, where various peripherals are connected
to a firewall bus. The firewall can then check the peripheral accesses
before allowing its device to probe.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
	- Minor changes in commit message
	- Renamed access-controller to access-controllers

Changes in V5:
	- Discarded review tags as the content has changed
	- Renamed feature-domains to access-controller

Changes in V4:
	- Added Jonathan's tag for IIO

Changes in V2:
	- Add missing "feature-domains" property declaration
	  in bosch,m_can.yaml and st,stm32-cryp.yaml files

 Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml   | 4 ++++
 Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml   | 4 ++++
 Documentation/devicetree/bindings/dma/st,stm32-dma.yaml       | 4 ++++
 Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml    | 4 ++++
 Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml       | 4 ++++
 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml   | 4 ++++
 .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml       | 4 ++++
 Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml   | 4 ++++
 Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml | 4 ++++
 Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml    | 4 ++++
 .../bindings/memory-controllers/st,stm32-fmc2-ebi.yaml        | 4 ++++
 Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml   | 4 ++++
 Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml    | 4 ++++
 Documentation/devicetree/bindings/mmc/arm,pl18x.yaml          | 4 ++++
 Documentation/devicetree/bindings/net/can/bosch,m_can.yaml    | 4 ++++
 Documentation/devicetree/bindings/net/stm32-dwmac.yaml        | 4 ++++
 Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml  | 4 ++++
 .../devicetree/bindings/regulator/st,stm32-vrefbuf.yaml       | 4 ++++
 Documentation/devicetree/bindings/rng/st,stm32-rng.yaml       | 4 ++++
 Documentation/devicetree/bindings/serial/st,stm32-uart.yaml   | 4 ++++
 Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml     | 4 ++++
 Documentation/devicetree/bindings/sound/st,stm32-sai.yaml     | 4 ++++
 Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml | 4 ++++
 Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml      | 4 ++++
 Documentation/devicetree/bindings/spi/st,stm32-spi.yaml       | 4 ++++
 Documentation/devicetree/bindings/usb/dwc2.yaml               | 4 ++++
 26 files changed, 104 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
index 0ddeb8a9a7a0..27354658d054 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
@@ -46,6 +46,10 @@ properties:
   power-domains:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
index ac480765cde0..822318414095 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
@@ -51,6 +51,10 @@ properties:
   power-domains:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
index 329847ef096a..ff935a0068ec 100644
--- a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
@@ -82,6 +82,10 @@ properties:
     description: if defined, it indicates that the controller
       supports memory-to-memory transfer
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
index e722fbcd8a5f..ddf82bf1e71a 100644
--- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
+++ b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
@@ -28,6 +28,10 @@ properties:
   resets:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
index 94b75d9f66cd..39fad8f7df44 100644
--- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
@@ -99,6 +99,10 @@ properties:
 
   wakeup-source: true
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
index 995cbf8cefc6..ec34c48d4878 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
@@ -93,6 +93,10 @@ properties:
   '#size-cells':
     const: 0
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 allOf:
   - if:
       properties:
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
index 1970503389aa..c1b1324fa132 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
@@ -59,6 +59,10 @@ properties:
       If not, SPI CLKOUT frequency will not be accurate.
     maximum: 20000000
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
index 04045b932bd2..b15de4eb209c 100644
--- a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
@@ -45,6 +45,10 @@ properties:
   '#size-cells':
     const: 0
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 additionalProperties: false
 
 required:
diff --git a/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
index 2314a9a14650..1d930d9e10fd 100644
--- a/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
+++ b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
@@ -29,6 +29,10 @@ properties:
       - const: cec
       - const: hdmi-cec
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index 6b3e413cedb2..34147127192f 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -36,6 +36,10 @@ properties:
   resets:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
   port:
     $ref: /schemas/graph.yaml#/$defs/port-base
     unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
index 14f1833d37c9..deef455bfd21 100644
--- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
@@ -45,6 +45,10 @@ properties:
       Reflects the memory layout with four integer values per bank. Format:
       <bank-number> 0 <address of the bank> <size>
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 patternProperties:
   "^.*@[0-4],[a-f0-9]+$":
     additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
index 27329c5dc38e..d41308856408 100644
--- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
@@ -44,6 +44,10 @@ properties:
 
   wakeup-source: true
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
   pwm:
     type: object
     additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
index f84e09a5743b..b0e438ff4950 100644
--- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
@@ -67,6 +67,10 @@ properties:
   "#size-cells":
     const: 0
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
   pwm:
     type: object
     additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
index 2459a55ed540..5644927be810 100644
--- a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
+++ b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
@@ -79,6 +79,10 @@ properties:
           - const: rx
           - const: tx
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
   power-domains: true
 
   resets:
diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
index f9ffb963d6b1..c4887522e8fe 100644
--- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
+++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
@@ -118,6 +118,10 @@ properties:
   phys:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index fc8c96b08d7d..f2714b5b6cf4 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -93,6 +93,10 @@ properties:
       select RCC clock instead of ETH_REF_CLK.
     type: boolean
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - clocks
diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
index 24a3dbde223b..ceea122ae1a6 100644
--- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
@@ -55,6 +55,10 @@ properties:
     description: number of clock cells for ck_usbo_48m consumer
     const: 0
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 # Required child nodes:
 
 patternProperties:
diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml
index 05f4ad2c7d3a..6ceaffb45dc9 100644
--- a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml
+++ b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml
@@ -30,6 +30,10 @@ properties:
   vdda-supply:
     description: phandle to the vdda input analog voltage.
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
index 717f6b321f88..340d01d481d1 100644
--- a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
@@ -37,6 +37,10 @@ properties:
     description: If set, the RNG configuration in RNG_CR, RNG_HTCR and
                   RNG_NSCR will be locked.
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
index 1df8ffe95fc6..1de03af4ead1 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -70,6 +70,10 @@ properties:
     enum: [1, 2, 4, 8, 12, 14, 16]
     default: 8
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 allOf:
   - $ref: rs485.yaml#
   - $ref: serial.yaml#
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
index b9111d375b93..8978f6bd63e5 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
@@ -65,6 +65,10 @@ properties:
     $ref: audio-graph-port.yaml#
     unevaluatedProperties: false
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - "#sound-dai-cells"
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
index 59df8a832310..b46a4778807d 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
@@ -48,6 +48,10 @@ properties:
   clock-names:
     maxItems: 3
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml
index bc48151b9adb..3dedc81ec12f 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml
@@ -50,6 +50,10 @@ properties:
   resets:
     maxItems: 1
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - "#sound-dai-cells"
diff --git a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
index 8bba965a9ae6..3f1a27efff80 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
@@ -46,6 +46,10 @@ properties:
       - const: tx
       - const: rx
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
index ae0f082bd377..0b303bf5c02c 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
@@ -50,6 +50,10 @@ properties:
       - const: rx
       - const: tx
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml
index 0a5c98ea711d..88c077673c8b 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
@@ -172,6 +172,10 @@ properties:
 
   tpl-support: true
 
+  access-controllers:
+    minItems: 1
+    maxItems: 2
+
 dependencies:
   port: [ usb-role-switch ]
   role-switch-default-mode: [ usb-role-switch ]
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:47 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:47 +0100
Subject: [PATCH v8 04/13] dt-bindings: bus: document ETZPC
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-5-gatien.chevallier@foss.st.com>

Document ETZPC (Extended TrustZone protection controller). ETZPC is a
firewall controller.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
    	- Renamed access-controller to access-controllers
    	- Removal of access-control-provider property
    	- Removal of access-controller and access-controller-names
    	  declaration in the patternProperties field. Add
    	  additionalProperties: true in this field.

Changes in V5:
	- Renamed feature-domain* to access-control*

Changes in V2:
	- Corrected errors highlighted by Rob's robot
	- No longer define the maxItems for the "feature-domains"
	  property
	- Fix example (node name, status)
	- Declare "feature-domain-names" as an optional
	  property for child nodes
	- Fix description of "feature-domains" property
	- Reordered the properties so it matches ETZPC
	- Add missing "feature-domain-controller" property

 .../bindings/bus/st,stm32-etzpc.yaml          | 87 +++++++++++++++++++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml

diff --git a/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
new file mode 100644
index 000000000000..9ca0ad39bc19
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/st,stm32-etzpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Extended TrustZone protection controller
+
+description: |
+  The ETZPC configures TrustZone security in a SoC having bus masters and
+  devices with programmable-security attributes (securable resources).
+
+maintainers:
+  - Gatien Chevallier <gatien.chevallier at foss.st.com>
+
+properties:
+  compatible:
+    contains:
+      const: st,stm32-etzpc
+
+  reg:
+    maxItems: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 1
+
+  ranges: true
+
+  "#access-controller-cells":
+    const: 1
+    description:
+      Contains the firewall ID associated to the peripheral.
+
+patternProperties:
+  "^.*@[0-9a-f]+$":
+    description: Peripherals
+    type: object
+
+    additionalProperties: true
+
+    required:
+      - access-controllers
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+  - "#access-controller-cells"
+  - ranges
+
+additionalProperties: false
+
+examples:
+  - |
+    // In this example, the usart2 device refers to rifsc as its access
+    // controller.
+    // Access rights are verified before creating devices.
+
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/stm32mp13-clks.h>
+    #include <dt-bindings/reset/stm32mp13-resets.h>
+
+    etzpc: bus at 5c007000 {
+        compatible = "st,stm32-etzpc";
+        reg = <0x5c007000 0x400>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        #access-controller-cells = <1>;
+        ranges;
+
+        usart2: serial at 4c001000 {
+            compatible = "st,stm32h7-uart";
+            reg = <0x4c001000 0x400>;
+            interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
+            clocks = <&rcc USART2_K>;
+            resets = <&rcc USART2_R>;
+            wakeup-source;
+            dmas = <&dmamux1 43 0x400 0x5>,
+                    <&dmamux1 44 0x400 0x1>;
+            dma-names = "rx", "tx";
+            access-controllers = <&etzpc 17>;
+        };
+    };
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:50 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:50 +0100
Subject: [PATCH v8 07/13] bus: rifsc: introduce RIFSC firewall controller driver
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-8-gatien.chevallier@foss.st.com>

RIFSC is a peripheral firewall controller that filter accesses based on
Arm TrustZone secure state, Arm CPU privilege execution level and
Compartment IDentification of the STM32 SoC subsystems.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V4:
	- Fix incorrect use of __set_bit() in
	- stm32_rif_acquire_semaphore()

Changes in V2:
	- Add controller name
	- Driver is now a module_platform_driver
	- Use error code returned by stm32_firewall_populate_bus()
	- Fix license

 MAINTAINERS               |   1 +
 drivers/bus/Makefile      |   2 +-
 drivers/bus/stm32_rifsc.c | 252 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 254 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bus/stm32_rifsc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 774c7e1601d8..a1152438b52d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20434,6 +20434,7 @@ ST STM32 FIREWALL
 M:	Gatien Chevallier <gatien.chevallier at foss.st.com>
 S:	Maintained
 F:	drivers/bus/stm32_firewall.c
+F:	drivers/bus/stm32_rifsc.c
 
 ST STM32 I2C/SMBUS DRIVER
 M:	Pierre-Yves MORDRET <pierre-yves.mordret at foss.st.com>
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index fc0511450ec2..e50d18e1d141 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_OMAP_INTERCONNECT)	+= omap_l3_smx.o omap_l3_noc.o
 obj-$(CONFIG_OMAP_OCP2SCP)	+= omap-ocp2scp.o
 obj-$(CONFIG_QCOM_EBI2)		+= qcom-ebi2.o
 obj-$(CONFIG_QCOM_SSC_BLOCK_BUS)	+= qcom-ssc-block-bus.o
-obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o
+obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o stm32_rifsc.o
 obj-$(CONFIG_SUN50I_DE2_BUS)	+= sun50i-de2.o
 obj-$(CONFIG_SUNXI_RSB)		+= sunxi-rsb.o
 obj-$(CONFIG_OF)		+= simple-pm-bus.o
diff --git a/drivers/bus/stm32_rifsc.c b/drivers/bus/stm32_rifsc.c
new file mode 100644
index 000000000000..4cf1b60014b7
--- /dev/null
+++ b/drivers/bus/stm32_rifsc.c
@@ -0,0 +1,252 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+#include "stm32_firewall.h"
+
+/*
+ * RIFSC offset register
+ */
+#define RIFSC_RISC_SECCFGR0		0x10
+#define RIFSC_RISC_PRIVCFGR0		0x30
+#define RIFSC_RISC_PER0_CIDCFGR		0x100
+#define RIFSC_RISC_PER0_SEMCR		0x104
+#define RIFSC_RISC_HWCFGR2		0xFEC
+
+/*
+ * SEMCR register
+ */
+#define SEMCR_MUTEX			BIT(0)
+
+/*
+ * HWCFGR2 register
+ */
+#define HWCFGR2_CONF1_MASK		GENMASK(15, 0)
+#define HWCFGR2_CONF2_MASK		GENMASK(23, 16)
+#define HWCFGR2_CONF3_MASK		GENMASK(31, 24)
+
+/*
+ * RIFSC miscellaneous
+ */
+#define RIFSC_RISC_CFEN_MASK		BIT(0)
+#define RIFSC_RISC_SEM_EN_MASK		BIT(1)
+#define RIFSC_RISC_SCID_MASK		GENMASK(6, 4)
+#define RIFSC_RISC_SEML_SHIFT		16
+#define RIFSC_RISC_SEMWL_MASK		GENMASK(23, 16)
+#define RIFSC_RISC_PER_ID_MASK		GENMASK(31, 24)
+
+#define RIFSC_RISC_PERx_CID_MASK	(RIFSC_RISC_CFEN_MASK | \
+					 RIFSC_RISC_SEM_EN_MASK | \
+					 RIFSC_RISC_SCID_MASK | \
+					 RIFSC_RISC_SEMWL_MASK)
+
+#define IDS_PER_RISC_SEC_PRIV_REGS	32
+
+/* RIF miscellaneous */
+/*
+ * CIDCFGR register fields
+ */
+#define CIDCFGR_CFEN			BIT(0)
+#define CIDCFGR_SEMEN			BIT(1)
+#define CIDCFGR_SEMWL(x)		BIT(RIFSC_RISC_SEML_SHIFT + (x))
+
+#define SEMWL_SHIFT			16
+
+/* Compartiment IDs */
+#define RIF_CID0			0x0
+#define RIF_CID1			0x1
+
+static bool stm32_rifsc_is_semaphore_available(void __iomem *addr)
+{
+	return !(readl(addr) & SEMCR_MUTEX);
+}
+
+static int stm32_rif_acquire_semaphore(struct stm32_firewall_controller *stm32_firewall_controller,
+				       int id)
+{
+	void __iomem *addr = stm32_firewall_controller->mmio + RIFSC_RISC_PER0_SEMCR + 0x8 * id;
+
+	writel(SEMCR_MUTEX, addr);
+
+	/* Check that CID1 has the semaphore */
+	if (stm32_rifsc_is_semaphore_available(addr) ||
+	    FIELD_GET(RIFSC_RISC_SCID_MASK, readl(addr)) != RIF_CID1)
+		return -EACCES;
+
+	return 0;
+}
+
+static void stm32_rif_release_semaphore(struct stm32_firewall_controller *stm32_firewall_controller,
+					int id)
+{
+	void __iomem *addr = stm32_firewall_controller->mmio + RIFSC_RISC_PER0_SEMCR + 0x8 * id;
+
+	if (stm32_rifsc_is_semaphore_available(addr))
+		return;
+
+	writel(SEMCR_MUTEX, addr);
+
+	/* Ok if another compartment takes the semaphore before the check */
+	WARN_ON(!stm32_rifsc_is_semaphore_available(addr) &&
+		FIELD_GET(RIFSC_RISC_SCID_MASK, readl(addr)) == RIF_CID1);
+}
+
+static int stm32_rifsc_grant_access(struct stm32_firewall_controller *ctrl, u32 firewall_id)
+{
+	struct stm32_firewall_controller *rifsc_controller = ctrl;
+	u32 reg_offset, reg_id, sec_reg_value, cid_reg_value;
+	int rc;
+
+	if (firewall_id >= rifsc_controller->max_entries) {
+		dev_err(rifsc_controller->dev, "Invalid sys bus ID %u", firewall_id);
+		return -EINVAL;
+	}
+
+	/*
+	 * RIFSC_RISC_PRIVCFGRx and RIFSC_RISC_SECCFGRx both handle configuration access for
+	 * 32 peripherals. On the other hand, there is one _RIFSC_RISC_PERx_CIDCFGR register
+	 * per peripheral
+	 */
+	reg_id = firewall_id / IDS_PER_RISC_SEC_PRIV_REGS;
+	reg_offset = firewall_id % IDS_PER_RISC_SEC_PRIV_REGS;
+	sec_reg_value = readl(rifsc_controller->mmio + RIFSC_RISC_SECCFGR0 + 0x4 * reg_id);
+	cid_reg_value = readl(rifsc_controller->mmio + RIFSC_RISC_PER0_CIDCFGR + 0x8 * firewall_id);
+
+	/* First check conditions for semaphore mode, which doesn't take into account static CID. */
+	if ((cid_reg_value & CIDCFGR_SEMEN) && (cid_reg_value & CIDCFGR_CFEN)) {
+		if (cid_reg_value & BIT(RIF_CID1 + SEMWL_SHIFT)) {
+			/* Static CID is irrelevant if semaphore mode */
+			goto skip_cid_check;
+		} else {
+			dev_dbg(rifsc_controller->dev,
+				"Invalid bus semaphore configuration: index %d\n", firewall_id);
+			return -EACCES;
+		}
+	}
+
+	/*
+	 * Skip CID check if CID filtering isn't enabled or filtering is enabled on CID0, which
+	 * corresponds to whatever CID.
+	 */
+	if (!(cid_reg_value & CIDCFGR_CFEN) ||
+	    FIELD_GET(RIFSC_RISC_SCID_MASK, cid_reg_value) == RIF_CID0)
+		goto skip_cid_check;
+
+	/* Coherency check with the CID configuration */
+	if (FIELD_GET(RIFSC_RISC_SCID_MASK, cid_reg_value) != RIF_CID1) {
+		dev_dbg(rifsc_controller->dev, "Invalid CID configuration for peripheral: %d\n",
+			firewall_id);
+		return -EACCES;
+	}
+
+skip_cid_check:
+	/* Check security configuration */
+	if (sec_reg_value & BIT(reg_offset)) {
+		dev_dbg(rifsc_controller->dev,
+			"Invalid security configuration for peripheral: %d\n", firewall_id);
+		return -EACCES;
+	}
+
+	/*
+	 * If the peripheral is in semaphore mode, take the semaphore so that
+	 * the CID1 has the ownership.
+	 */
+	if ((cid_reg_value & CIDCFGR_SEMEN) && (cid_reg_value & CIDCFGR_CFEN)) {
+		rc = stm32_rif_acquire_semaphore(rifsc_controller, firewall_id);
+		if (rc) {
+			dev_err(rifsc_controller->dev,
+				"Couldn't acquire semaphore for peripheral: %d\n", firewall_id);
+			return rc;
+		}
+	}
+
+	return 0;
+}
+
+static void stm32_rifsc_release_access(struct stm32_firewall_controller *ctrl, u32 firewall_id)
+{
+	stm32_rif_release_semaphore(ctrl, firewall_id);
+}
+
+static int stm32_rifsc_probe(struct platform_device *pdev)
+{
+	struct stm32_firewall_controller *rifsc_controller;
+	struct device_node *np = pdev->dev.of_node;
+	u32 nb_risup, nb_rimu, nb_risal;
+	struct resource *res;
+	void __iomem *mmio;
+	int rc;
+
+	rifsc_controller = devm_kzalloc(&pdev->dev, sizeof(*rifsc_controller), GFP_KERNEL);
+	if (!rifsc_controller)
+		return -ENOMEM;
+
+	mmio = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(mmio))
+		return PTR_ERR(mmio);
+
+	rifsc_controller->dev = &pdev->dev;
+	rifsc_controller->mmio = mmio;
+	rifsc_controller->name = dev_driver_string(rifsc_controller->dev);
+	rifsc_controller->type = STM32_PERIPHERAL_FIREWALL | STM32_MEMORY_FIREWALL;
+	rifsc_controller->grant_access = stm32_rifsc_grant_access;
+	rifsc_controller->release_access = stm32_rifsc_release_access;
+
+	/* Get number of RIFSC entries*/
+	nb_risup = readl(rifsc_controller->mmio + RIFSC_RISC_HWCFGR2) & HWCFGR2_CONF1_MASK;
+	nb_rimu = readl(rifsc_controller->mmio + RIFSC_RISC_HWCFGR2) & HWCFGR2_CONF2_MASK;
+	nb_risal = readl(rifsc_controller->mmio + RIFSC_RISC_HWCFGR2) & HWCFGR2_CONF3_MASK;
+	rifsc_controller->max_entries = nb_risup + nb_rimu + nb_risal;
+
+	platform_set_drvdata(pdev, rifsc_controller);
+
+	rc = stm32_firewall_controller_register(rifsc_controller);
+	if (rc) {
+		dev_err(rifsc_controller->dev, "Couldn't register as a firewall controller: %d",
+			rc);
+		return rc;
+	}
+
+	rc = stm32_firewall_populate_bus(rifsc_controller);
+	if (rc) {
+		dev_err(rifsc_controller->dev, "Couldn't populate RIFSC bus: %d",
+			rc);
+		return rc;
+	}
+
+	/* Populate all allowed nodes */
+	return of_platform_populate(np, NULL, NULL, &pdev->dev);
+}
+
+static const struct of_device_id stm32_rifsc_of_match[] = {
+	{ .compatible = "st,stm32mp25-rifsc" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, stm32_rifsc_of_match);
+
+static struct platform_driver stm32_rifsc_driver = {
+	.probe  = stm32_rifsc_probe,
+	.driver = {
+		.name = "stm32-rifsc",
+		.of_match_table = stm32_rifsc_of_match,
+	},
+};
+module_platform_driver(stm32_rifsc_driver);
+
+MODULE_AUTHOR("Gatien Chevallier <gatien.chevallier at foss.st.com>");
+MODULE_DESCRIPTION("STMicroelectronics RIFSC driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:49 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:49 +0100
Subject: [PATCH v8 06/13] of: property: fw_devlink: Add support for "access-controller"
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-7-gatien.chevallier@foss.st.com>

Allows tracking dependencies between devices and their access
controller.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V6:
    	- Renamed access-controller to access-controllers

Changes in V5:
	- Rename feature-domain* to access-control*

Patch not present in V1

 drivers/of/property.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index afdaefbd03f6..7f737eac91b2 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1268,6 +1268,7 @@ DEFINE_SIMPLE_PROP(leds, "leds", NULL)
 DEFINE_SIMPLE_PROP(backlight, "backlight", NULL)
 DEFINE_SIMPLE_PROP(panel, "panel", NULL)
 DEFINE_SIMPLE_PROP(msi_parent, "msi-parent", "#msi-cells")
+DEFINE_SIMPLE_PROP(access_controllers, "access-controllers", "#access-controller-cells")
 DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
 DEFINE_SUFFIX_PROP(gpio, "-gpio", "#gpio-cells")
 
@@ -1363,6 +1364,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
 	{ .parse_prop = parse_regulators, },
 	{ .parse_prop = parse_gpio, },
 	{ .parse_prop = parse_gpios, },
+	{ .parse_prop = parse_access_controllers, },
 	{}
 };
 
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:48 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:48 +0100
Subject: [PATCH v8 05/13] firewall: introduce stm32_firewall framework
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-6-gatien.chevallier@foss.st.com>

Introduce a STM32 firewall framework that offers to firewall consumers
different firewall services such as the ability to check their access
rights against their firewall controller(s).

The STM32 firewall framework offers a generic API for STM32 firewall
controllers that is defined in their drivers to best fit the
specificity of each firewall.

There are various types of firewalls:
-Peripheral firewalls that filter accesses to peripherals
-Memory firewalls that filter accesses to memories or memory regions
-No type for undefined type of firewall

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V8:
	- Add missing dependency on OF for OF_DYNAMIC

Changes in V7:
	- Select OF_DYNAMIC when STM32_FIREWALL is set in order to use
	  of_detach_node() in the firewall framework. Since the
	  simple-bus pre-probe creates devices for all subnodes. This
	  function is needed to detach particular nodes so that there's
	  no match

Changes in V6:
	- Renamed access-controller to access-controllers

Changes in V5:
	- Rename feature-domain* to access-control*
	- Fix index out of range in stm32_firewall_get_firewall()
	- Add mising "select STM32_FIREWALL" in config ARCH_STM32 in
	  arch/arm/mach-stm32/Kconfig

Changes in V4:
	- Fix documentation syntax
	- Put node in case of error in stm32_firewall_populate_bus()
	- Check firewall controller presence before using it in
	  stm32_firewall_controller_register()

Changes in V2:
	- Support multiple entries for "feature-domains"
	  property. Change stm32_firewall_get_firewall()
	  to do so.
	- Better handle the device-tree parsing using
	  phandle+args APIs and phandle iterator.
	- Remove "resource firewall" type
	- Rephrase STM32_FIREWALL description in the bus
	  Kconfig and remove useless default value
	- Add missing EXPORT_SYMBOL_GPL
	- Remove useless stm32_firewall_get_id() API
	- Add a field for the name of the firewall entry
	  in the stm32_firewall_controller structure
	- Minor fixes on some traces level (err -> debug)
	- Fix licenses to GPL-2.0-only
	- Fix stm32_firewall_get_firewall() description
	- Rephrase some sentences to better emphasize this
	  is STM32-specific
	- Switch to list_for_each_entry() in
	  stm32_firewall_controller_unregister() as we only
	  expect one firewall controller instance per device.
	  The loop just breaks when found
	- Do not register the firewall controller if it is
	  already registered to the framework


 MAINTAINERS                               |   5 +
 arch/arm/mach-stm32/Kconfig               |   1 +
 arch/arm64/Kconfig.platforms              |   1 +
 drivers/bus/Kconfig                       |  10 +
 drivers/bus/Makefile                      |   1 +
 drivers/bus/stm32_firewall.c              | 294 ++++++++++++++++++++++
 drivers/bus/stm32_firewall.h              |  83 ++++++
 include/linux/bus/stm32_firewall_device.h | 141 +++++++++++
 8 files changed, 536 insertions(+)
 create mode 100644 drivers/bus/stm32_firewall.c
 create mode 100644 drivers/bus/stm32_firewall.h
 create mode 100644 include/linux/bus/stm32_firewall_device.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e2c6187a3ac8..774c7e1601d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20430,6 +20430,11 @@ T:	git git://linuxtv.org/media_tree.git
 F:	Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml
 F:	drivers/media/i2c/st-mipid02.c
 
+ST STM32 FIREWALL
+M:	Gatien Chevallier <gatien.chevallier at foss.st.com>
+S:	Maintained
+F:	drivers/bus/stm32_firewall.c
+
 ST STM32 I2C/SMBUS DRIVER
 M:	Pierre-Yves MORDRET <pierre-yves.mordret at foss.st.com>
 M:	Alain Volmat <alain.volmat at foss.st.com>
diff --git a/arch/arm/mach-stm32/Kconfig b/arch/arm/mach-stm32/Kconfig
index 98145031586f..ae21a9f78f9c 100644
--- a/arch/arm/mach-stm32/Kconfig
+++ b/arch/arm/mach-stm32/Kconfig
@@ -12,6 +12,7 @@ menuconfig ARCH_STM32
 	select PINCTRL
 	select RESET_CONTROLLER
 	select STM32_EXTI
+	select STM32_FIREWALL
 	help
 	  Support for STMicroelectronics STM32 processors.
 
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 24335565bad5..13ed0a483617 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -305,6 +305,7 @@ config ARCH_STM32
 	select ARM_SMC_MBOX
 	select ARM_SCMI_PROTOCOL
 	select COMMON_CLK_SCMI
+	select STM32_FIREWALL
 	help
 	  This enables support for ARMv8 based STMicroelectronics
 	  STM32 family, including:
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index e6742998f372..7d47e0005cfe 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -163,6 +163,16 @@ config QCOM_SSC_BLOCK_BUS
 	  i2c/spi/uart controllers, a hexagon core, and a clock controller
 	  which provides clocks for the above.
 
+config STM32_FIREWALL
+	bool "STM32 Firewall framework"
+	depends on (ARCH_STM32 || COMPILE_TEST) && OF
+	select OF_DYNAMIC
+	help
+	  Say y to enable STM32 firewall framework and its services. Firewall
+	  controllers will be able to register to the framework. Access for
+	  hardware resources linked to a firewall controller can be requested
+	  through this STM32 framework.
+
 config SUN50I_DE2_BUS
 	bool "Allwinner A64 DE2 Bus Driver"
 	  default ARM64
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index d90eed189a65..fc0511450ec2 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_OMAP_INTERCONNECT)	+= omap_l3_smx.o omap_l3_noc.o
 obj-$(CONFIG_OMAP_OCP2SCP)	+= omap-ocp2scp.o
 obj-$(CONFIG_QCOM_EBI2)		+= qcom-ebi2.o
 obj-$(CONFIG_QCOM_SSC_BLOCK_BUS)	+= qcom-ssc-block-bus.o
+obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o
 obj-$(CONFIG_SUN50I_DE2_BUS)	+= sun50i-de2.o
 obj-$(CONFIG_SUNXI_RSB)		+= sunxi-rsb.o
 obj-$(CONFIG_OF)		+= simple-pm-bus.o
diff --git a/drivers/bus/stm32_firewall.c b/drivers/bus/stm32_firewall.c
new file mode 100644
index 000000000000..decb79449047
--- /dev/null
+++ b/drivers/bus/stm32_firewall.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/bus/stm32_firewall_device.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/slab.h>
+
+#include "stm32_firewall.h"
+
+/* Corresponds to STM32_FIREWALL_MAX_EXTRA_ARGS + firewall ID */
+#define STM32_FIREWALL_MAX_ARGS		(STM32_FIREWALL_MAX_EXTRA_ARGS + 1)
+
+static LIST_HEAD(firewall_controller_list);
+static DEFINE_MUTEX(firewall_controller_list_lock);
+
+/* Firewall device API */
+
+int stm32_firewall_get_firewall(struct device_node *np, struct stm32_firewall *firewall,
+				unsigned int nb_firewall)
+{
+	struct stm32_firewall_controller *ctrl;
+	struct of_phandle_iterator it;
+	unsigned int i, j = 0;
+	int err;
+
+	if (!firewall || !nb_firewall)
+		return -EINVAL;
+
+	/* Parse property with phandle parsed out */
+	of_for_each_phandle(&it, err, np, "access-controllers", "#access-controller-cells", 0) {
+		struct of_phandle_args provider_args;
+		struct device_node *provider = it.node;
+		const char *fw_entry;
+		bool match = false;
+
+		if (err) {
+			pr_err("Unable to get access-controllers property for node %s\n, err: %d",
+			       np->full_name, err);
+			of_node_put(provider);
+			return err;
+		}
+
+		if (j > nb_firewall) {
+			pr_err("Too many firewall controllers");
+			of_node_put(provider);
+			return -EINVAL;
+		}
+
+		provider_args.args_count = of_phandle_iterator_args(&it, provider_args.args,
+								    STM32_FIREWALL_MAX_ARGS);
+
+		/* Check if the parsed phandle corresponds to a registered firewall controller */
+		mutex_lock(&firewall_controller_list_lock);
+		list_for_each_entry(ctrl, &firewall_controller_list, entry) {
+			if (ctrl->dev->of_node->phandle == it.phandle) {
+				match = true;
+				firewall[j].firewall_ctrl = ctrl;
+				break;
+			}
+		}
+		mutex_unlock(&firewall_controller_list_lock);
+
+		if (!match) {
+			firewall[j].firewall_ctrl = NULL;
+			pr_err("No firewall controller registered for %s\n", np->full_name);
+			of_node_put(provider);
+			return -ENODEV;
+		}
+
+		err = of_property_read_string_index(np, "access-controller-names", j, &fw_entry);
+		if (err == 0)
+			firewall[j].entry = fw_entry;
+
+		/* Handle the case when there are no arguments given along with the phandle */
+		if (provider_args.args_count < 0 ||
+		    provider_args.args_count > STM32_FIREWALL_MAX_ARGS) {
+			of_node_put(provider);
+			return -EINVAL;
+		} else if (provider_args.args_count == 0) {
+			firewall[j].extra_args_size = 0;
+			firewall[j].firewall_id = U32_MAX;
+			j++;
+			continue;
+		}
+
+		/* The firewall ID is always the first argument */
+		firewall[j].firewall_id = provider_args.args[0];
+
+		/* Extra args start at the second argument */
+		for (i = 0; i < provider_args.args_count - 1; i++)
+			firewall[j].extra_args[i] = provider_args.args[i + 1];
+
+		/* Remove the firewall ID arg that is not an extra argument */
+		firewall[j].extra_args_size = provider_args.args_count - 1;
+
+		j++;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_get_firewall);
+
+int stm32_firewall_grant_access(struct stm32_firewall *firewall)
+{
+	struct stm32_firewall_controller *firewall_controller;
+
+	if (!firewall || firewall->firewall_id == U32_MAX)
+		return -EINVAL;
+
+	firewall_controller = firewall->firewall_ctrl;
+
+	if (!firewall_controller)
+		return -ENODEV;
+
+	return firewall_controller->grant_access(firewall_controller, firewall->firewall_id);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_grant_access);
+
+int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
+{
+	struct stm32_firewall_controller *firewall_controller;
+
+	if (!firewall || subsystem_id == U32_MAX || firewall->firewall_id == U32_MAX)
+		return -EINVAL;
+
+	firewall_controller = firewall->firewall_ctrl;
+
+	if (!firewall_controller)
+		return -ENODEV;
+
+	return firewall_controller->grant_access(firewall_controller, subsystem_id);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_grant_access_by_id);
+
+void stm32_firewall_release_access(struct stm32_firewall *firewall)
+{
+	struct stm32_firewall_controller *firewall_controller;
+
+	if (!firewall || firewall->firewall_id == U32_MAX) {
+		pr_debug("Incorrect arguments when releasing a firewall access\n");
+		return;
+	}
+
+	firewall_controller = firewall->firewall_ctrl;
+
+	if (!firewall_controller) {
+		pr_debug("No firewall controller to release\n");
+		return;
+	}
+
+	firewall_controller->release_access(firewall_controller, firewall->firewall_id);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_release_access);
+
+void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
+{
+	struct stm32_firewall_controller *firewall_controller;
+
+	if (!firewall || subsystem_id == U32_MAX || firewall->firewall_id == U32_MAX) {
+		pr_debug("Incorrect arguments when releasing a firewall access");
+		return;
+	}
+
+	firewall_controller = firewall->firewall_ctrl;
+
+	if (!firewall_controller) {
+		pr_debug("No firewall controller to release");
+		return;
+	}
+
+	firewall_controller->release_access(firewall_controller, subsystem_id);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_release_access_by_id);
+
+/* Firewall controller API */
+
+int stm32_firewall_controller_register(struct stm32_firewall_controller *firewall_controller)
+{
+	struct stm32_firewall_controller *ctrl;
+
+	if (!firewall_controller)
+		return -ENODEV;
+
+	pr_info("Registering %s firewall controller\n", firewall_controller->name);
+
+	mutex_lock(&firewall_controller_list_lock);
+	list_for_each_entry(ctrl, &firewall_controller_list, entry) {
+		if (ctrl == firewall_controller) {
+			pr_debug("%s firewall controller already registered\n",
+				 firewall_controller->name);
+			mutex_unlock(&firewall_controller_list_lock);
+			return 0;
+		}
+	}
+	list_add_tail(&firewall_controller->entry, &firewall_controller_list);
+	mutex_unlock(&firewall_controller_list_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_controller_register);
+
+void stm32_firewall_controller_unregister(struct stm32_firewall_controller *firewall_controller)
+{
+	struct stm32_firewall_controller *ctrl;
+	bool controller_removed = false;
+
+	if (!firewall_controller) {
+		pr_debug("Null reference while unregistering firewall controller\n");
+		return;
+	}
+
+	mutex_lock(&firewall_controller_list_lock);
+	list_for_each_entry(ctrl, &firewall_controller_list, entry) {
+		if (ctrl == firewall_controller) {
+			controller_removed = true;
+			list_del_init(&ctrl->entry);
+			break;
+		}
+	}
+	mutex_unlock(&firewall_controller_list_lock);
+
+	if (!controller_removed)
+		pr_debug("There was no firewall controller named %s to unregister\n",
+			 firewall_controller->name);
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_controller_unregister);
+
+int stm32_firewall_populate_bus(struct stm32_firewall_controller *firewall_controller)
+{
+	struct stm32_firewall *firewalls;
+	struct device_node *child;
+	struct device *parent;
+	unsigned int i;
+	int len;
+	int err;
+
+	parent = firewall_controller->dev;
+
+	dev_dbg(parent, "Populating %s system bus\n", dev_name(firewall_controller->dev));
+
+	for_each_available_child_of_node(dev_of_node(parent), child) {
+		/* The access-controllers property is mandatory for firewall bus devices */
+		len = of_count_phandle_with_args(child, "access-controllers",
+						 "#access-controller-cells");
+		if (len <= 0) {
+			of_node_put(child);
+			return -EINVAL;
+		}
+
+		firewalls = kcalloc(len, sizeof(*firewalls), GFP_KERNEL);
+		if (!firewalls) {
+			of_node_put(child);
+			return -ENOMEM;
+		}
+
+		err = stm32_firewall_get_firewall(child, firewalls, (unsigned int)len);
+		if (err) {
+			kfree(firewalls);
+			of_node_put(child);
+			return err;
+		}
+
+		for (i = 0; i < len; i++) {
+			if (firewall_controller->grant_access(firewall_controller,
+							      firewalls[i].firewall_id)) {
+				/*
+				 * Peripheral access not allowed or not defined.
+				 * Mark the node as populated so platform bus won't probe it
+				 */
+				of_detach_node(child);
+				dev_err(parent, "%s: Device driver will not be probed\n",
+					child->full_name);
+			}
+		}
+
+		kfree(firewalls);
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(stm32_firewall_populate_bus);
diff --git a/drivers/bus/stm32_firewall.h b/drivers/bus/stm32_firewall.h
new file mode 100644
index 000000000000..e5fac85fe346
--- /dev/null
+++ b/drivers/bus/stm32_firewall.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef _STM32_FIREWALL_H
+#define _STM32_FIREWALL_H
+
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+/**
+ * STM32_PERIPHERAL_FIREWALL:		This type of firewall protects peripherals
+ * STM32_MEMORY_FIREWALL:		This type of firewall protects memories/subsets of memory
+ *					zones
+ * STM32_NOTYPE_FIREWALL:		Undefined firewall type
+ */
+
+#define STM32_PERIPHERAL_FIREWALL	BIT(1)
+#define STM32_MEMORY_FIREWALL		BIT(2)
+#define STM32_NOTYPE_FIREWALL		BIT(3)
+
+/**
+ * struct stm32_firewall_controller - Information on firewall controller supplying services
+ *
+ * @name:			Name of the firewall controller
+ * @dev:			Device reference of the firewall controller
+ * @mmio:			Base address of the firewall controller
+ * @entry:			List entry of the firewall controller list
+ * @type:			Type of firewall
+ * @max_entries:		Number of entries covered by the firewall
+ * @grant_access:		Callback used to grant access for a device access against a
+ *				firewall controller
+ * @release_access:		Callback used to release resources taken by a device when access was
+ *				granted
+ * @grant_memory_range_access:	Callback used to grant access for a device to a given memory region
+ */
+struct stm32_firewall_controller {
+	const char *name;
+	struct device *dev;
+	void __iomem *mmio;
+	struct list_head entry;
+	unsigned int type;
+	unsigned int max_entries;
+
+	int (*grant_access)(struct stm32_firewall_controller *ctrl, u32 id);
+	void (*release_access)(struct stm32_firewall_controller *ctrl, u32 id);
+	int (*grant_memory_range_access)(struct stm32_firewall_controller *ctrl, phys_addr_t paddr,
+					 size_t size);
+};
+
+/**
+ * stm32_firewall_controller_register - Register a firewall controller to the STM32 firewall
+ *					framework
+ * @firewall_controller:	Firewall controller to register
+ *
+ * Returns 0 in case of success or -ENODEV if no controller was given.
+ */
+int stm32_firewall_controller_register(struct stm32_firewall_controller *firewall_controller);
+
+/**
+ * stm32_firewall_controller_unregister - Unregister a firewall controller from the STM32
+ *					  firewall framework
+ * @firewall_controller:	Firewall controller to unregister
+ */
+void stm32_firewall_controller_unregister(struct stm32_firewall_controller *firewall_controller);
+
+/**
+ * stm32_firewall_populate_bus - Populate device tree nodes that have a correct firewall
+ *				 configuration. This is used at boot-time only, as a sanity check
+ *				 between device tree and firewalls hardware configurations to
+ *				 prevent a kernel crash when a device driver is not granted access
+ *
+ * @firewall_controller:	Firewall controller which nodes will be populated or not
+ *
+ * Returns 0 in case of success or appropriate errno code if error occurred.
+ */
+int stm32_firewall_populate_bus(struct stm32_firewall_controller *firewall_controller);
+
+#endif /* _STM32_FIREWALL_H */
diff --git a/include/linux/bus/stm32_firewall_device.h b/include/linux/bus/stm32_firewall_device.h
new file mode 100644
index 000000000000..bbbee0b24ea8
--- /dev/null
+++ b/include/linux/bus/stm32_firewall_device.h
@@ -0,0 +1,141 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef STM32_FIREWALL_DEVICE_H
+#define STM32_FIREWALL_DEVICE_H
+
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+#define STM32_FIREWALL_MAX_EXTRA_ARGS		5
+
+/* Opaque reference to stm32_firewall_controller */
+struct stm32_firewall_controller;
+
+/**
+ * struct stm32_firewall - Information on a device's firewall. Each device can have more than one
+ *			   firewall.
+ *
+ * @firewall_ctrl:		Pointer referencing a firewall controller of the device. It is
+ *				opaque so a device cannot manipulate the controller's ops or access
+ *				the controller's data
+ * @extra_args:			Extra arguments that are implementation dependent
+ * @entry:			Name of the firewall entry
+ * @extra_args_size:		Number of extra arguments
+ * @firewall_id:		Firewall ID associated the device for this firewall controller
+ */
+struct stm32_firewall {
+	struct stm32_firewall_controller *firewall_ctrl;
+	u32 extra_args[STM32_FIREWALL_MAX_EXTRA_ARGS];
+	const char *entry;
+	size_t extra_args_size;
+	u32 firewall_id;
+};
+
+#if IS_ENABLED(CONFIG_STM32_FIREWALL)
+/**
+ * stm32_firewall_get_firewall - Get the firewall(s) associated to given device.
+ *				 The firewall controller reference is always the first argument
+ *				 of each of the access-controller property entries.
+ *				 The firewall ID is always the second argument of each of the
+ *				 access-controller  property entries.
+ *				 If there's no argument linked to the phandle, then the firewall ID
+ *				 field is set to U32_MAX, which is an invalid ID.
+ *
+ * @np:				Device node to parse
+ * @firewall:			Array of firewall references
+ * @nb_firewall:		Number of firewall references to get. Must be at least 1.
+ *
+ * Returns 0 on success, -ENODEV if there's no match with a firewall controller or appropriate errno
+ * code if error occurred.
+ */
+int stm32_firewall_get_firewall(struct device_node *np, struct stm32_firewall *firewall,
+				unsigned int nb_firewall);
+
+/**
+ * stm32_firewall_grant_access - Request firewall access rights and grant access.
+ *
+ * @firewall:			Firewall reference containing the ID to check against its firewall
+ *				controller
+ *
+ * Returns 0 if access is granted, -EACCES if access is denied, -ENODEV if firewall is null or
+ * appropriate errno code if error occurred
+ */
+int stm32_firewall_grant_access(struct stm32_firewall *firewall);
+
+/**
+ * stm32_firewall_release_access - Release access granted from a call to
+ *				   stm32_firewall_grant_access().
+ *
+ * @firewall:			Firewall reference containing the ID to check against its firewall
+ *				controller
+ */
+void stm32_firewall_release_access(struct stm32_firewall *firewall);
+
+/**
+ * stm32_firewall_grant_access_by_id - Request firewall access rights of a given device
+ *				       based on a specific firewall ID
+ *
+ * Warnings:
+ * There is no way to ensure that the given ID will correspond to the firewall referenced in the
+ * device node if the ID did not come from stm32_firewall_get_firewall(). In that case, this
+ * function must be used with caution.
+ * This function should be used for subsystem resources that do not have the same firewall ID
+ * as their parent.
+ * U32_MAX is an invalid ID.
+ *
+ * @firewall:			Firewall reference containing the firewall controller
+ * @subsystem_id:		Firewall ID of the subsystem resource
+ *
+ * Returns 0 if access is granted, -EACCES if access is denied, -ENODEV if firewall is null or
+ * appropriate errno code if error occurred
+ */
+int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id);
+
+/**
+ * stm32_firewall_release_access_by_id - Release access granted from a call to
+ *					 stm32_firewall_grant_access_by_id().
+ *
+ * Warnings:
+ * There is no way to ensure that the given ID will correspond to the firewall referenced in the
+ * device node if the ID did not come from stm32_firewall_get_firewall(). In that case, this
+ * function must be used with caution.
+ * This function should be used for subsystem resources that do not have the same firewall ID
+ * as their parent.
+ * U32_MAX is an invalid ID.
+ *
+ * @firewall:			Firewall reference containing the firewall controller
+ * @subsystem_id:		Firewall ID of the subsystem resource
+ */
+void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id);
+
+#else /* CONFIG_STM32_FIREWALL */
+
+int stm32_firewall_get_firewall(struct device_node *np, struct stm32_firewall *firewall)
+{
+	return -ENODEV;
+}
+
+int stm32_firewall_grant_access(struct stm32_firewall *firewall)
+{
+	return -ENODEV;
+}
+
+void stm32_firewall_release_access(struct stm32_firewall *firewall)
+{
+}
+
+int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
+{
+	return -ENODEV;
+}
+
+void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id)
+{
+}
+
+#endif /* CONFIG_STM32_FIREWALL */
+#endif /* STM32_FIREWALL_DEVICE_H */
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:51 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:51 +0100
Subject: [PATCH v8 08/13] arm64: dts: st: add RIFSC as an access controller for STM32MP25x boards
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-9-gatien.chevallier@foss.st.com>

RIFSC is a firewall controller. Add "st,stm32mp25-rifsc" compatible and
reference RIFSC as an access-control-provider. Keep "simple-bus"
compatible backward compatibility.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V8:
    	- Keep "simple-bus" compatible

Changes in V6:
    	- Renamed access-controller to access-controllers
    	- Removal of access-control-provider property

Changes in V5:
    	- Renamed feature-domain* to access-control*

Changes in V2:
	- Fix rifsc node name
	- Move the "ranges" property under the
	  "feature-domains" one

 arch/arm64/boot/dts/st/stm32mp251.dtsi | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 124403f5f1f4..3b0d6dced81f 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -111,11 +111,12 @@ soc at 0 {
 		interrupt-parent = <&intc>;
 		ranges = <0x0 0x0 0x0 0x80000000>;
 
-		rifsc: rifsc-bus at 42080000 {
-			compatible = "simple-bus";
+		rifsc: bus at 42080000 {
+			compatible = "st,stm32mp25-rifsc", "simple-bus";
 			reg = <0x42080000 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+			#access-controller-cells = <1>;
 			ranges;
 
 			usart2: serial at 400e0000 {
@@ -123,6 +124,7 @@ usart2: serial at 400e0000 {
 				reg = <0x400e0000 0x400>;
 				interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&ck_flexgen_08>;
+				access-controllers = <&rifsc 32>;
 				status = "disabled";
 			};
 
@@ -136,6 +138,7 @@ sdmmc1: mmc at 48220000 {
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
 				max-frequency = <120000000>;
+				access-controllers = <&rifsc 92>;
 				status = "disabled";
 			};
 		};
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:52 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:52 +0100
Subject: [PATCH v8 09/13] bus: etzpc: introduce ETZPC firewall controller driver
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-10-gatien.chevallier@foss.st.com>

ETZPC is a peripheral and memory firewall controller that filter accesses
based on Arm TrustZone secure state and Arm CPU privilege execution level.
It handles MCU isolation as well.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V2:
	- Add controller name
	- Driver is now a module_platform_driver
	- Use error code returned by stm32_firewall_populate_bus()
	- Fix license

 MAINTAINERS               |   1 +
 drivers/bus/Makefile      |   2 +-
 drivers/bus/stm32_etzpc.c | 141 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 143 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bus/stm32_etzpc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a1152438b52d..b83b471c8b73 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20433,6 +20433,7 @@ F:	drivers/media/i2c/st-mipid02.c
 ST STM32 FIREWALL
 M:	Gatien Chevallier <gatien.chevallier at foss.st.com>
 S:	Maintained
+F:	drivers/bus/stm32_etzpc.c
 F:	drivers/bus/stm32_firewall.c
 F:	drivers/bus/stm32_rifsc.c
 
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index e50d18e1d141..cddd4984d6af 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_OMAP_INTERCONNECT)	+= omap_l3_smx.o omap_l3_noc.o
 obj-$(CONFIG_OMAP_OCP2SCP)	+= omap-ocp2scp.o
 obj-$(CONFIG_QCOM_EBI2)		+= qcom-ebi2.o
 obj-$(CONFIG_QCOM_SSC_BLOCK_BUS)	+= qcom-ssc-block-bus.o
-obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o stm32_rifsc.o
+obj-$(CONFIG_STM32_FIREWALL)	+= stm32_firewall.o stm32_rifsc.o stm32_etzpc.o
 obj-$(CONFIG_SUN50I_DE2_BUS)	+= sun50i-de2.o
 obj-$(CONFIG_SUNXI_RSB)		+= sunxi-rsb.o
 obj-$(CONFIG_OF)		+= simple-pm-bus.o
diff --git a/drivers/bus/stm32_etzpc.c b/drivers/bus/stm32_etzpc.c
new file mode 100644
index 000000000000..7fc0f16960be
--- /dev/null
+++ b/drivers/bus/stm32_etzpc.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+#include "stm32_firewall.h"
+
+/*
+ * ETZPC registers
+ */
+#define ETZPC_DECPROT			0x10
+#define ETZPC_HWCFGR			0x3F0
+
+/*
+ * HWCFGR register
+ */
+#define ETZPC_HWCFGR_NUM_TZMA		GENMASK(7, 0)
+#define ETZPC_HWCFGR_NUM_PER_SEC	GENMASK(15, 8)
+#define ETZPC_HWCFGR_NUM_AHB_SEC	GENMASK(23, 16)
+#define ETZPC_HWCFGR_CHUNKS1N4		GENMASK(31, 24)
+
+/*
+ * ETZPC miscellaneous
+ */
+#define ETZPC_PROT_MASK			GENMASK(1, 0)
+#define ETZPC_PROT_A7NS			0x3
+#define ETZPC_DECPROT_SHIFT		1
+
+#define IDS_PER_DECPROT_REGS		16
+
+static int stm32_etzpc_grant_access(struct stm32_firewall_controller *ctrl, u32 firewall_id)
+{
+	u32 offset, reg_offset, sec_val;
+
+	if (firewall_id >= ctrl->max_entries) {
+		dev_err(ctrl->dev, "Invalid sys bus ID %u", firewall_id);
+		return -EINVAL;
+	}
+
+	/* Check access configuration, 16 peripherals per register */
+	reg_offset = ETZPC_DECPROT + 0x4 * (firewall_id / IDS_PER_DECPROT_REGS);
+	offset = (firewall_id % IDS_PER_DECPROT_REGS) << ETZPC_DECPROT_SHIFT;
+
+	/* Verify peripheral is non-secure and attributed to cortex A7 */
+	sec_val = (readl(ctrl->mmio + reg_offset) >> offset) & ETZPC_PROT_MASK;
+	if (sec_val != ETZPC_PROT_A7NS) {
+		dev_dbg(ctrl->dev, "Invalid bus configuration: reg_offset %#x, value %d\n",
+			reg_offset, sec_val);
+		return -EACCES;
+	}
+
+	return 0;
+}
+
+static void stm32_etzpc_release_access(struct stm32_firewall_controller *ctrl __maybe_unused,
+				       u32 firewall_id __maybe_unused)
+{
+}
+
+static int stm32_etzpc_probe(struct platform_device *pdev)
+{
+	struct stm32_firewall_controller *etzpc_controller;
+	struct device_node *np = pdev->dev.of_node;
+	u32 nb_per, nb_master;
+	struct resource *res;
+	void __iomem *mmio;
+	int rc;
+
+	etzpc_controller = devm_kzalloc(&pdev->dev, sizeof(*etzpc_controller), GFP_KERNEL);
+	if (!etzpc_controller)
+		return -ENOMEM;
+
+	mmio = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(mmio))
+		return PTR_ERR(mmio);
+
+	etzpc_controller->dev = &pdev->dev;
+	etzpc_controller->mmio = mmio;
+	etzpc_controller->name = dev_driver_string(etzpc_controller->dev);
+	etzpc_controller->type = STM32_PERIPHERAL_FIREWALL | STM32_MEMORY_FIREWALL;
+	etzpc_controller->grant_access = stm32_etzpc_grant_access;
+	etzpc_controller->release_access = stm32_etzpc_release_access;
+
+	/* Get number of etzpc entries*/
+	nb_per = FIELD_GET(ETZPC_HWCFGR_NUM_PER_SEC,
+			   readl(etzpc_controller->mmio + ETZPC_HWCFGR));
+	nb_master = FIELD_GET(ETZPC_HWCFGR_NUM_AHB_SEC,
+			      readl(etzpc_controller->mmio + ETZPC_HWCFGR));
+	etzpc_controller->max_entries = nb_per + nb_master;
+
+	platform_set_drvdata(pdev, etzpc_controller);
+
+	rc = stm32_firewall_controller_register(etzpc_controller);
+	if (rc) {
+		dev_err(etzpc_controller->dev, "Couldn't register as a firewall controller: %d",
+			rc);
+		return rc;
+	}
+
+	rc = stm32_firewall_populate_bus(etzpc_controller);
+	if (rc) {
+		dev_err(etzpc_controller->dev, "Couldn't populate ETZPC bus: %d",
+			rc);
+		return rc;
+	}
+
+	/* Populate all allowed nodes */
+	return of_platform_populate(np, NULL, NULL, &pdev->dev);
+}
+
+static const struct of_device_id stm32_etzpc_of_match[] = {
+	{ .compatible = "st,stm32-etzpc" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, stm32_etzpc_of_match);
+
+static struct platform_driver stm32_etzpc_driver = {
+	.probe  = stm32_etzpc_probe,
+	.driver = {
+		.name = "stm32-etzpc",
+		.of_match_table = stm32_etzpc_of_match,
+	},
+};
+module_platform_driver(stm32_etzpc_driver);
+
+MODULE_AUTHOR("Gatien Chevallier <gatien.chevallier at foss.st.com>");
+MODULE_DESCRIPTION("STMicroelectronics ETZPC driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:54 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:54 +0100
Subject: [PATCH v8 11/13] ARM: dts: stm32: put ETZPC as an access controller for STM32MP15x boards
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-12-gatien.chevallier@foss.st.com>

Reference ETZPC as an access-control-provider.

For more information on which peripheral is securable or supports MCU
isolation, please read the STM32MP13 reference manual

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Patch not present in V6

 arch/arm/boot/dts/st/stm32mp151.dtsi  | 66 ++++++++++++++++++++++++++-
 arch/arm/boot/dts/st/stm32mp153.dtsi  |  2 +
 arch/arm/boot/dts/st/stm32mp15xc.dtsi |  1 +
 3 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/st/stm32mp151.dtsi b/arch/arm/boot/dts/st/stm32mp151.dtsi
index 78c0d6ccdb09..8a40df8a097b 100644
--- a/arch/arm/boot/dts/st/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp151.dtsi
@@ -330,10 +330,11 @@ ts_cal2: calib at 5e {
 		};
 
 		etzpc: bus at 5c007000 {
-			compatible = "st,stm32-etzpc";
+			compatible = "st,stm32-etzpc", "simple-bus";
 			reg = <0x5c007000 0x400>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+			#access-controller-cells = <1>;
 			ranges;
 
 			timers2: timer at 40000000 {
@@ -351,6 +352,7 @@ timers2: timer at 40000000 {
 				       <&dmamux1 21 0x400 0x1>,
 				       <&dmamux1 22 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4", "up";
+				access-controllers = <&etzpc 16>;
 				status = "disabled";
 
 				pwm {
@@ -387,6 +389,7 @@ timers3: timer at 40001000 {
 				       <&dmamux1 27 0x400 0x1>,
 				       <&dmamux1 28 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+				access-controllers = <&etzpc 17>;
 				status = "disabled";
 
 				pwm {
@@ -421,6 +424,7 @@ timers4: timer at 40002000 {
 				       <&dmamux1 31 0x400 0x1>,
 				       <&dmamux1 32 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4";
+				access-controllers = <&etzpc 18>;
 				status = "disabled";
 
 				pwm {
@@ -457,6 +461,7 @@ timers5: timer at 40003000 {
 				       <&dmamux1 59 0x400 0x1>,
 				       <&dmamux1 60 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+				access-controllers = <&etzpc 19>;
 				status = "disabled";
 
 				pwm {
@@ -488,6 +493,7 @@ timers6: timer at 40004000 {
 				clock-names = "int";
 				dmas = <&dmamux1 69 0x400 0x1>;
 				dma-names = "up";
+				access-controllers = <&etzpc 20>;
 				status = "disabled";
 
 				timer at 5 {
@@ -508,6 +514,7 @@ timers7: timer at 40005000 {
 				clock-names = "int";
 				dmas = <&dmamux1 70 0x400 0x1>;
 				dma-names = "up";
+				access-controllers = <&etzpc 21>;
 				status = "disabled";
 
 				timer at 6 {
@@ -526,6 +533,7 @@ timers12: timer at 40006000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM12_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 22>;
 				status = "disabled";
 
 				pwm {
@@ -550,6 +558,7 @@ timers13: timer at 40007000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM13_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 23>;
 				status = "disabled";
 
 				pwm {
@@ -574,6 +583,7 @@ timers14: timer at 40008000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM14_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 24>;
 				status = "disabled";
 
 				pwm {
@@ -598,6 +608,7 @@ lptimer1: timer at 40009000 {
 				clocks = <&rcc LPTIM1_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 25>;
 				status = "disabled";
 
 				pwm {
@@ -626,6 +637,7 @@ i2s2: audio-controller at 4000b000 {
 				dmas = <&dmamux1 39 0x400 0x01>,
 				       <&dmamux1 40 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 27>;
 				status = "disabled";
 			};
 
@@ -640,6 +652,7 @@ spi2: spi at 4000b000 {
 				dmas = <&dmamux1 39 0x400 0x05>,
 				       <&dmamux1 40 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 27>;
 				status = "disabled";
 			};
 
@@ -651,6 +664,7 @@ i2s3: audio-controller at 4000c000 {
 				dmas = <&dmamux1 61 0x400 0x01>,
 				       <&dmamux1 62 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 28>;
 				status = "disabled";
 			};
 
@@ -665,6 +679,7 @@ spi3: spi at 4000c000 {
 				dmas = <&dmamux1 61 0x400 0x05>,
 				       <&dmamux1 62 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 28>;
 				status = "disabled";
 			};
 
@@ -678,6 +693,7 @@ spdifrx: audio-controller at 4000d000 {
 				dmas = <&dmamux1 93 0x400 0x01>,
 				       <&dmamux1 94 0x400 0x01>;
 				dma-names = "rx", "rx-ctrl";
+				access-controllers = <&etzpc 29>;
 				status = "disabled";
 			};
 
@@ -690,6 +706,7 @@ usart2: serial at 4000e000 {
 				dmas = <&dmamux1 43 0x400 0x15>,
 				       <&dmamux1 44 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 30>;
 				status = "disabled";
 			};
 
@@ -702,6 +719,7 @@ usart3: serial at 4000f000 {
 				dmas = <&dmamux1 45 0x400 0x15>,
 				       <&dmamux1 46 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 31>;
 				status = "disabled";
 			};
 
@@ -714,6 +732,7 @@ uart4: serial at 40010000 {
 				dmas = <&dmamux1 63 0x400 0x15>,
 				       <&dmamux1 64 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 32>;
 				status = "disabled";
 			};
 
@@ -726,6 +745,7 @@ uart5: serial at 40011000 {
 				dmas = <&dmamux1 65 0x400 0x15>,
 				       <&dmamux1 66 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 33>;
 				status = "disabled";
 			};
 
@@ -742,6 +762,7 @@ i2c1: i2c at 40012000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x1>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 34>;
 				status = "disabled";
 			};
 
@@ -758,6 +779,7 @@ i2c2: i2c at 40013000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x2>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 35>;
 				status = "disabled";
 			};
 
@@ -774,6 +796,7 @@ i2c3: i2c at 40014000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x4>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 36>;
 				status = "disabled";
 			};
 
@@ -790,6 +813,7 @@ i2c5: i2c at 40015000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x10>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 37>;
 				status = "disabled";
 			};
 
@@ -799,6 +823,7 @@ cec: cec at 40016000 {
 				interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&rcc CEC_K>, <&rcc CEC>;
 				clock-names = "cec", "hdmi-cec";
+				access-controllers = <&etzpc 38>;
 				status = "disabled";
 			};
 
@@ -809,6 +834,7 @@ dac: dac at 40017000 {
 				clock-names = "pclk";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 39>;
 				status = "disabled";
 
 				dac1: dac at 1 {
@@ -835,6 +861,7 @@ uart7: serial at 40018000 {
 				dmas = <&dmamux1 79 0x400 0x15>,
 				       <&dmamux1 80 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 40>;
 				status = "disabled";
 			};
 
@@ -847,6 +874,7 @@ uart8: serial at 40019000 {
 				dmas = <&dmamux1 81 0x400 0x15>,
 				       <&dmamux1 82 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 41>;
 				status = "disabled";
 			};
 
@@ -871,6 +899,7 @@ timers1: timer at 44000000 {
 				       <&dmamux1 17 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4",
 					    "up", "trig", "com";
+				access-controllers = <&etzpc 48>;
 				status = "disabled";
 
 				pwm {
@@ -912,6 +941,7 @@ timers8: timer at 44001000 {
 				       <&dmamux1 53 0x400 0x1>;
 				dma-names = "ch1", "ch2", "ch3", "ch4",
 					    "up", "trig", "com";
+				access-controllers = <&etzpc 49>;
 				status = "disabled";
 
 				pwm {
@@ -941,6 +971,7 @@ usart6: serial at 44003000 {
 				dmas = <&dmamux1 71 0x400 0x15>,
 				<&dmamux1 72 0x400 0x11>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 51>;
 				status = "disabled";
 			};
 
@@ -952,6 +983,7 @@ i2s1: audio-controller at 44004000 {
 				dmas = <&dmamux1 37 0x400 0x01>,
 				<&dmamux1 38 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 52>;
 				status = "disabled";
 			};
 
@@ -966,6 +998,7 @@ spi1: spi at 44004000 {
 				dmas = <&dmamux1 37 0x400 0x05>,
 				<&dmamux1 38 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 52>;
 				status = "disabled";
 			};
 
@@ -980,6 +1013,7 @@ spi4: spi at 44005000 {
 				dmas = <&dmamux1 83 0x400 0x05>,
 				<&dmamux1 84 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 53>;
 				status = "disabled";
 			};
 
@@ -997,6 +1031,7 @@ timers15: timer at 44006000 {
 				       <&dmamux1 107 0x400 0x1>,
 				       <&dmamux1 108 0x400 0x1>;
 				dma-names = "ch1", "up", "trig", "com";
+				access-controllers = <&etzpc 54>;
 				status = "disabled";
 
 				pwm {
@@ -1024,6 +1059,7 @@ timers16: timer at 44007000 {
 				dmas = <&dmamux1 109 0x400 0x1>,
 				<&dmamux1 110 0x400 0x1>;
 				dma-names = "ch1", "up";
+				access-controllers = <&etzpc 55>;
 				status = "disabled";
 
 				pwm {
@@ -1050,6 +1086,7 @@ timers17: timer at 44008000 {
 				dmas = <&dmamux1 111 0x400 0x1>,
 				<&dmamux1 112 0x400 0x1>;
 				dma-names = "ch1", "up";
+				access-controllers = <&etzpc 56>;
 				status = "disabled";
 
 				pwm {
@@ -1076,6 +1113,7 @@ spi5: spi at 44009000 {
 				dmas = <&dmamux1 85 0x400 0x05>,
 				<&dmamux1 86 0x400 0x05>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 57>;
 				status = "disabled";
 			};
 
@@ -1087,6 +1125,7 @@ sai1: sai at 4400a000 {
 				reg = <0x4400a000 0x4>, <0x4400a3f0 0x10>;
 				interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
 				resets = <&rcc SAI1_R>;
+				access-controllers = <&etzpc 58>;
 				status = "disabled";
 
 				sai1a: audio-controller at 4400a004 {
@@ -1119,6 +1158,7 @@ sai2: sai at 4400b000 {
 				reg = <0x4400b000 0x4>, <0x4400b3f0 0x10>;
 				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 				resets = <&rcc SAI2_R>;
+				access-controllers = <&etzpc 59>;
 				status = "disabled";
 
 				sai2a: audio-controller at 4400b004 {
@@ -1150,6 +1190,7 @@ sai3: sai at 4400c000 {
 				reg = <0x4400c000 0x4>, <0x4400c3f0 0x10>;
 				interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
 				resets = <&rcc SAI3_R>;
+				access-controllers = <&etzpc 60>;
 				status = "disabled";
 
 				sai3a: audio-controller at 4400c004 {
@@ -1180,6 +1221,7 @@ dfsdm: dfsdm at 4400d000 {
 				clock-names = "dfsdm";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 61>;
 				status = "disabled";
 
 				dfsdm0: filter at 0 {
@@ -1259,6 +1301,7 @@ dma1: dma-controller at 48000000 {
 				#dma-cells = <4>;
 				st,mem2mem;
 				dma-requests = <8>;
+				access-controllers = <&etzpc 88>;
 			};
 
 			dma2: dma-controller at 48001000 {
@@ -1277,6 +1320,7 @@ dma2: dma-controller at 48001000 {
 				#dma-cells = <4>;
 				st,mem2mem;
 				dma-requests = <8>;
+				access-controllers = <&etzpc 89>;
 			};
 
 			dmamux1: dma-router at 48002000 {
@@ -1288,6 +1332,7 @@ dmamux1: dma-router at 48002000 {
 				dma-channels = <16>;
 				clocks = <&rcc DMAMUX>;
 				resets = <&rcc DMAMUX_R>;
+				access-controllers = <&etzpc 90>;
 			};
 
 			adc: adc at 48003000 {
@@ -1302,6 +1347,7 @@ adc: adc at 48003000 {
 				#interrupt-cells = <1>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 72>;
 				status = "disabled";
 
 				adc1: adc at 0 {
@@ -1352,6 +1398,7 @@ sdmmc3: mmc at 48004000 {
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
 				max-frequency = <120000000>;
+				access-controllers = <&etzpc 86>;
 				status = "disabled";
 			};
 
@@ -1369,6 +1416,7 @@ usbotg_hs: usb-otg at 49000000 {
 				dr_mode = "otg";
 				otg-rev = <0x200>;
 				usb33d-supply = <&usb33>;
+				access-controllers = <&etzpc 85>;
 				status = "disabled";
 			};
 
@@ -1381,6 +1429,7 @@ dcmi: dcmi at 4c006000 {
 				clock-names = "mclk";
 				dmas = <&dmamux1 75 0x400 0x01>;
 				dma-names = "tx";
+				access-controllers = <&etzpc 70>;
 				status = "disabled";
 			};
 
@@ -1393,6 +1442,7 @@ lptimer2: timer at 50021000 {
 				clocks = <&rcc LPTIM2_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 64>;
 				status = "disabled";
 
 				pwm {
@@ -1422,6 +1472,7 @@ lptimer3: timer at 50022000 {
 				clocks = <&rcc LPTIM3_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 65>;
 				status = "disabled";
 
 				pwm {
@@ -1444,6 +1495,7 @@ lptimer4: timer at 50023000 {
 				clocks = <&rcc LPTIM4_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 66>;
 				status = "disabled";
 
 				pwm {
@@ -1460,6 +1512,7 @@ lptimer5: timer at 50024000 {
 				clocks = <&rcc LPTIM5_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 67>;
 				status = "disabled";
 
 				pwm {
@@ -1475,6 +1528,7 @@ vrefbuf: vrefbuf at 50025000 {
 				regulator-min-microvolt = <1500000>;
 				regulator-max-microvolt = <2500000>;
 				clocks = <&rcc VREF>;
+				access-controllers = <&etzpc 69>;
 				status = "disabled";
 			};
 
@@ -1486,6 +1540,7 @@ sai4: sai at 50027000 {
 				reg = <0x50027000 0x4>, <0x500273f0 0x10>;
 				interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
 				resets = <&rcc SAI4_R>;
+				access-controllers = <&etzpc 68>;
 				status = "disabled";
 
 				sai4a: audio-controller at 50027004 {
@@ -1518,6 +1573,7 @@ hash1: hash at 54002000 {
 				dmas = <&mdma1 31 0x2 0x1000A02 0x0 0x0>;
 				dma-names = "in";
 				dma-maxburst = <2>;
+				access-controllers = <&etzpc 8>;
 				status = "disabled";
 			};
 
@@ -1526,6 +1582,7 @@ rng1: rng at 54003000 {
 				reg = <0x54003000 0x400>;
 				clocks = <&rcc RNG1_K>;
 				resets = <&rcc RNG1_R>;
+				access-controllers = <&etzpc 7>;
 				status = "okay";
 			};
 
@@ -1536,6 +1593,7 @@ fmc: memory-controller at 58002000 {
 				reg = <0x58002000 0x1000>;
 				clocks = <&rcc FMC_K>;
 				resets = <&rcc FMC_R>;
+				access-controllers = <&etzpc 91>;
 				status = "disabled";
 
 				ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
@@ -1575,6 +1633,7 @@ qspi: spi at 58003000 {
 				resets = <&rcc QSPI_R>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 92>;
 				status = "disabled";
 			};
 
@@ -1602,6 +1661,7 @@ ethernet0: ethernet at 5800a000 {
 				snps,en-tx-lpi-clockgating;
 				snps,axi-config = <&stmmac_axi_config_0>;
 				snps,tso;
+				access-controllers = <&etzpc 94>;
 				status = "disabled";
 
 				stmmac_axi_config_0: stmmac-axi-config {
@@ -1617,6 +1677,7 @@ usart1: serial at 5c000000 {
 				interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&rcc USART1_K>;
 				wakeup-source;
+				access-controllers = <&etzpc 3>;
 				status = "disabled";
 			};
 
@@ -1630,6 +1691,7 @@ spi6: spi at 5c001000 {
 				resets = <&rcc SPI6_R>;
 				dmas = <&mdma1 34 0x0 0x40008 0x0 0x0>,
 				       <&mdma1 35 0x0 0x40002 0x0 0x0>;
+				access-controllers = <&etzpc 4>;
 				dma-names = "rx", "tx";
 				status = "disabled";
 			};
@@ -1647,6 +1709,7 @@ i2c4: i2c at 5c002000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x8>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 5>;
 				status = "disabled";
 			};
 
@@ -1663,6 +1726,7 @@ i2c6: i2c at 5c009000 {
 				st,syscfg-fmp = <&syscfg 0x4 0x20>;
 				wakeup-source;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 12>;
 				status = "disabled";
 			};
 		};
diff --git a/arch/arm/boot/dts/st/stm32mp153.dtsi b/arch/arm/boot/dts/st/stm32mp153.dtsi
index 36e17ea0b179..4640dafb1598 100644
--- a/arch/arm/boot/dts/st/stm32mp153.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp153.dtsi
@@ -41,6 +41,7 @@ m_can1: can at 4400e000 {
 		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
 		clock-names = "hclk", "cclk";
 		bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+		access-controllers = <&etzpc 62>;
 		status = "disabled";
 	};
 
@@ -54,6 +55,7 @@ m_can2: can at 4400f000 {
 		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
 		clock-names = "hclk", "cclk";
 		bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
+		access-controllers = <&etzpc 62>;
 		status = "disabled";
 	};
 };
diff --git a/arch/arm/boot/dts/st/stm32mp15xc.dtsi b/arch/arm/boot/dts/st/stm32mp15xc.dtsi
index d36c3457451a..97465717f932 100644
--- a/arch/arm/boot/dts/st/stm32mp15xc.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xc.dtsi
@@ -11,6 +11,7 @@ cryp1: cryp at 54001000 {
 		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&rcc CRYP1>;
 		resets = <&rcc CRYP1_R>;
+		access-controllers = <&etzpc 9>;
 		status = "disabled";
 	};
 };
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:53 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:53 +0100
Subject: [PATCH v8 10/13] ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-11-gatien.chevallier@foss.st.com>

ETZPC is a firewall controller. Put all peripherals filtered by the
ETZPC as ETZPC subnodes and keep the "simple-bus" compatible for
backward compatibility.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V8:
    	- Keep simple-bus compatible

Changes in V7:
    	- Remove access-controllers reference in this patch

Changes in V6:
    	- Renamed access-controller to access-controllers
    	- Removal of access-control-provider property

Changes in V5:
    	- Renamed feature-domain* to access-control*

 arch/arm/boot/dts/st/stm32mp151.dtsi  | 2676 +++++++++++++------------
 arch/arm/boot/dts/st/stm32mp153.dtsi  |   50 +-
 arch/arm/boot/dts/st/stm32mp15xc.dtsi |   18 +-
 3 files changed, 1375 insertions(+), 1369 deletions(-)

diff --git a/arch/arm/boot/dts/st/stm32mp151.dtsi b/arch/arm/boot/dts/st/stm32mp151.dtsi
index 61508917521c..78c0d6ccdb09 100644
--- a/arch/arm/boot/dts/st/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp151.dtsi
@@ -122,1543 +122,1551 @@ soc {
 		interrupt-parent = <&intc>;
 		ranges;
 
-		timers2: timer at 40000000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40000000 0x400>;
-			interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM2_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 18 0x400 0x1>,
-			       <&dmamux1 19 0x400 0x1>,
-			       <&dmamux1 20 0x400 0x1>,
-			       <&dmamux1 21 0x400 0x1>,
-			       <&dmamux1 22 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4", "up";
+		ipcc: mailbox at 4c001000 {
+			compatible = "st,stm32mp1-ipcc";
+			#mbox-cells = <1>;
+			reg = <0x4c001000 0x400>;
+			st,proc-id = <0>;
+			interrupts-extended =
+				<&exti 61 1>,
+				<&intc GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "rx", "tx";
+			clocks = <&rcc IPCC>;
+			wakeup-source;
 			status = "disabled";
+		};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 1 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <1>;
-				status = "disabled";
-			};
-
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
-			};
+		rcc: rcc at 50000000 {
+			compatible = "st,stm32mp1-rcc", "syscon";
+			reg = <0x50000000 0x1000>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
 		};
 
-		timers3: timer at 40001000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40001000 0x400>;
-			interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM3_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 23 0x400 0x1>,
-			       <&dmamux1 24 0x400 0x1>,
-			       <&dmamux1 25 0x400 0x1>,
-			       <&dmamux1 26 0x400 0x1>,
-			       <&dmamux1 27 0x400 0x1>,
-			       <&dmamux1 28 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
-			status = "disabled";
+		pwr_regulators: pwr at 50001000 {
+			compatible = "st,stm32mp1,pwr-reg";
+			reg = <0x50001000 0x10>;
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
+			reg11: reg11 {
+				regulator-name = "reg11";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
 			};
 
-			timer at 2 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <2>;
-				status = "disabled";
+			reg18: reg18 {
+				regulator-name = "reg18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
 			};
 
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
+			usb33: usb33 {
+				regulator-name = "usb33";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
 			};
 		};
 
-		timers4: timer at 40002000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40002000 0x400>;
-			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM4_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 29 0x400 0x1>,
-			       <&dmamux1 30 0x400 0x1>,
-			       <&dmamux1 31 0x400 0x1>,
-			       <&dmamux1 32 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
+		pwr_mcu: pwr_mcu at 50001014 {
+			compatible = "st,stm32mp151-pwr-mcu", "syscon";
+			reg = <0x50001014 0x4>;
+		};
 
-			timer at 3 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <3>;
-				status = "disabled";
-			};
+		exti: interrupt-controller at 5000d000 {
+			compatible = "st,stm32mp1-exti", "syscon";
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			reg = <0x5000d000 0x400>;
+		};
 
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
-			};
+		syscfg: syscon at 50020000 {
+			compatible = "st,stm32mp157-syscfg", "syscon";
+			reg = <0x50020000 0x400>;
+			clocks = <&rcc SYSCFG>;
 		};
 
-		timers5: timer at 40003000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40003000 0x400>;
-			interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM5_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 55 0x400 0x1>,
-			       <&dmamux1 56 0x400 0x1>,
-			       <&dmamux1 57 0x400 0x1>,
-			       <&dmamux1 58 0x400 0x1>,
-			       <&dmamux1 59 0x400 0x1>,
-			       <&dmamux1 60 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+		dts: thermal at 50028000 {
+			compatible = "st,stm32-thermal";
+			reg = <0x50028000 0x100>;
+			interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc TMPSENS>;
+			clock-names = "pclk";
+			#thermal-sensor-cells = <0>;
 			status = "disabled";
+		};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 4 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <4>;
-				status = "disabled";
-			};
-
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
-			};
+		mdma1: dma-controller at 58000000 {
+			compatible = "st,stm32h7-mdma";
+			reg = <0x58000000 0x1000>;
+			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc MDMA>;
+			resets = <&rcc MDMA_R>;
+			#dma-cells = <5>;
+			dma-channels = <32>;
+			dma-requests = <48>;
 		};
 
-		timers6: timer at 40004000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40004000 0x400>;
-			interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM6_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 69 0x400 0x1>;
-			dma-names = "up";
+		sdmmc1: mmc at 58005000 {
+			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+			arm,primecell-periphid = <0x00253180>;
+			reg = <0x58005000 0x1000>;
+			interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc SDMMC1_K>;
+			clock-names = "apb_pclk";
+			resets = <&rcc SDMMC1_R>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			max-frequency = <120000000>;
 			status = "disabled";
-
-			timer at 5 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <5>;
-				status = "disabled";
-			};
 		};
 
-		timers7: timer at 40005000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40005000 0x400>;
-			interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM7_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 70 0x400 0x1>;
-			dma-names = "up";
+		sdmmc2: mmc at 58007000 {
+			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+			arm,primecell-periphid = <0x00253180>;
+			reg = <0x58007000 0x1000>;
+			interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc SDMMC2_K>;
+			clock-names = "apb_pclk";
+			resets = <&rcc SDMMC2_R>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			max-frequency = <120000000>;
 			status = "disabled";
-
-			timer at 6 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <6>;
-				status = "disabled";
-			};
 		};
 
-		timers12: timer at 40006000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40006000 0x400>;
-			interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM12_K>;
-			clock-names = "int";
+		crc1: crc at 58009000 {
+			compatible = "st,stm32f7-crc";
+			reg = <0x58009000 0x400>;
+			clocks = <&rcc CRC1>;
 			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 11 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <11>;
-				status = "disabled";
-			};
 		};
 
-		timers13: timer at 40007000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40007000 0x400>;
-			interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM13_K>;
-			clock-names = "int";
+		usbh_ohci: usb at 5800c000 {
+			compatible = "generic-ohci";
+			reg = <0x5800c000 0x1000>;
+			clocks = <&usbphyc>, <&rcc USBH>;
+			resets = <&rcc USBH_R>;
+			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 12 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <12>;
-				status = "disabled";
-			};
 		};
 
-		timers14: timer at 40008000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x40008000 0x400>;
-			interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM14_K>;
-			clock-names = "int";
+		usbh_ehci: usb at 5800d000 {
+			compatible = "generic-ehci";
+			reg = <0x5800d000 0x1000>;
+			clocks = <&usbphyc>, <&rcc USBH>;
+			resets = <&rcc USBH_R>;
+			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+			companion = <&usbh_ohci>;
 			status = "disabled";
+		};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
+		ltdc: display-controller at 5a001000 {
+			compatible = "st,stm32-ltdc";
+			reg = <0x5a001000 0x400>;
+			interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&rcc LTDC_PX>;
+			clock-names = "lcd";
+			resets = <&rcc LTDC_R>;
+			status = "disabled";
+		};
 
-			timer at 13 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <13>;
-				status = "disabled";
-			};
+		iwdg2: watchdog at 5a002000 {
+			compatible = "st,stm32mp1-iwdg";
+			reg = <0x5a002000 0x400>;
+			clocks = <&rcc IWDG2>, <&rcc CK_LSI>;
+			clock-names = "pclk", "lsi";
+			status = "disabled";
 		};
 
-		lptimer1: timer at 40009000 {
+		usbphyc: usbphyc at 5a006000 {
 			#address-cells = <1>;
 			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x40009000 0x400>;
-			interrupts-extended = <&exti 47 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM1_K>;
-			clock-names = "mux";
-			wakeup-source;
+			#clock-cells = <0>;
+			compatible = "st,stm32mp1-usbphyc";
+			reg = <0x5a006000 0x1000>;
+			clocks = <&rcc USBPHY_K>;
+			resets = <&rcc USBPHY_R>;
+			vdda1v1-supply = <&reg11>;
+			vdda1v8-supply = <&reg18>;
 			status = "disabled";
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			trigger at 0 {
-				compatible = "st,stm32-lptimer-trigger";
+			usbphyc_port0: usb-phy at 0 {
+				#phy-cells = <0>;
 				reg = <0>;
-				status = "disabled";
 			};
 
-			counter {
-				compatible = "st,stm32-lptimer-counter";
-				status = "disabled";
+			usbphyc_port1: usb-phy at 1 {
+				#phy-cells = <1>;
+				reg = <1>;
 			};
 		};
 
-		spi2: spi at 4000b000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x4000b000 0x400>;
-			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI2_K>;
-			resets = <&rcc SPI2_R>;
-			dmas = <&dmamux1 39 0x400 0x05>,
-			       <&dmamux1 40 0x400 0x05>;
-			dma-names = "rx", "tx";
+		rtc: rtc at 5c004000 {
+			compatible = "st,stm32mp1-rtc";
+			reg = <0x5c004000 0x400>;
+			clocks = <&rcc RTCAPB>, <&rcc RTC>;
+			clock-names = "pclk", "rtc_ck";
+			interrupts-extended = <&exti 19 IRQ_TYPE_LEVEL_HIGH>;
 			status = "disabled";
 		};
 
-		i2s2: audio-controller at 4000b000 {
-			compatible = "st,stm32h7-i2s";
-			#sound-dai-cells = <0>;
-			reg = <0x4000b000 0x400>;
-			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 39 0x400 0x01>,
-			       <&dmamux1 40 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
+		bsec: efuse at 5c005000 {
+			compatible = "st,stm32mp15-bsec";
+			reg = <0x5c005000 0x400>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			part_number_otp: part-number-otp at 4 {
+				reg = <0x4 0x1>;
+			};
+			vrefint: vrefin-cal at 52 {
+				reg = <0x52 0x2>;
+			};
+			ts_cal1: calib at 5c {
+				reg = <0x5c 0x2>;
+			};
+			ts_cal2: calib at 5e {
+				reg = <0x5e 0x2>;
+			};
 		};
 
-		spi3: spi at 4000c000 {
+		etzpc: bus at 5c007000 {
+			compatible = "st,stm32-etzpc";
+			reg = <0x5c007000 0x400>;
 			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x4000c000 0x400>;
-			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI3_K>;
-			resets = <&rcc SPI3_R>;
-			dmas = <&dmamux1 61 0x400 0x05>,
-			       <&dmamux1 62 0x400 0x05>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			#size-cells = <1>;
+			ranges;
 
-		i2s3: audio-controller at 4000c000 {
-			compatible = "st,stm32h7-i2s";
-			#sound-dai-cells = <0>;
-			reg = <0x4000c000 0x400>;
-			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 61 0x400 0x01>,
-			       <&dmamux1 62 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			timers2: timer at 40000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40000000 0x400>;
+				interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM2_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 18 0x400 0x1>,
+				       <&dmamux1 19 0x400 0x1>,
+				       <&dmamux1 20 0x400 0x1>,
+				       <&dmamux1 21 0x400 0x1>,
+				       <&dmamux1 22 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		spdifrx: audio-controller at 4000d000 {
-			compatible = "st,stm32h7-spdifrx";
-			#sound-dai-cells = <0>;
-			reg = <0x4000d000 0x400>;
-			clocks = <&rcc SPDIF_K>;
-			clock-names = "kclk";
-			interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 93 0x400 0x01>,
-			       <&dmamux1 94 0x400 0x01>;
-			dma-names = "rx", "rx-ctrl";
-			status = "disabled";
-		};
+				timer at 1 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <1>;
+					status = "disabled";
+				};
 
-		usart2: serial at 4000e000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x4000e000 0x400>;
-			interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART2_K>;
-			wakeup-source;
-			dmas = <&dmamux1 43 0x400 0x15>,
-			       <&dmamux1 44 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
 
-		usart3: serial at 4000f000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x4000f000 0x400>;
-			interrupts-extended = <&exti 28 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART3_K>;
-			wakeup-source;
-			dmas = <&dmamux1 45 0x400 0x15>,
-			       <&dmamux1 46 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			timers3: timer at 40001000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40001000 0x400>;
+				interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM3_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 23 0x400 0x1>,
+				       <&dmamux1 24 0x400 0x1>,
+				       <&dmamux1 25 0x400 0x1>,
+				       <&dmamux1 26 0x400 0x1>,
+				       <&dmamux1 27 0x400 0x1>,
+				       <&dmamux1 28 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		uart4: serial at 40010000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x40010000 0x400>;
-			interrupts-extended = <&exti 30 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc UART4_K>;
-			wakeup-source;
-			dmas = <&dmamux1 63 0x400 0x15>,
-			       <&dmamux1 64 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+				timer at 2 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <2>;
+					status = "disabled";
+				};
 
-		uart5: serial at 40011000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x40011000 0x400>;
-			interrupts-extended = <&exti 31 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc UART5_K>;
-			wakeup-source;
-			dmas = <&dmamux1 65 0x400 0x15>,
-			       <&dmamux1 66 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
 
-		i2c1: i2c at 40012000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x40012000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C1_K>;
-			resets = <&rcc I2C1_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x1>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
+			timers4: timer at 40002000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40002000 0x400>;
+				interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM4_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 29 0x400 0x1>,
+				       <&dmamux1 30 0x400 0x1>,
+				       <&dmamux1 31 0x400 0x1>,
+				       <&dmamux1 32 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		i2c2: i2c at 40013000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x40013000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C2_K>;
-			resets = <&rcc I2C2_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x2>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
+				timer at 3 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <3>;
+					status = "disabled";
+				};
 
-		i2c3: i2c at 40014000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x40014000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C3_K>;
-			resets = <&rcc I2C3_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x4>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
 
-		i2c5: i2c at 40015000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x40015000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C5_K>;
-			resets = <&rcc I2C5_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x10>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
+			timers5: timer at 40003000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40003000 0x400>;
+				interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM5_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 55 0x400 0x1>,
+				       <&dmamux1 56 0x400 0x1>,
+				       <&dmamux1 57 0x400 0x1>,
+				       <&dmamux1 58 0x400 0x1>,
+				       <&dmamux1 59 0x400 0x1>,
+				       <&dmamux1 60 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		cec: cec at 40016000 {
-			compatible = "st,stm32-cec";
-			reg = <0x40016000 0x400>;
-			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CEC_K>, <&rcc CEC>;
-			clock-names = "cec", "hdmi-cec";
-			status = "disabled";
-		};
+				timer at 4 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <4>;
+					status = "disabled";
+				};
 
-		dac: dac at 40017000 {
-			compatible = "st,stm32h7-dac-core";
-			reg = <0x40017000 0x400>;
-			clocks = <&rcc DAC12>;
-			clock-names = "pclk";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
 
-			dac1: dac at 1 {
-				compatible = "st,stm32-dac";
-				#io-channel-cells = <1>;
-				reg = <1>;
-				status = "disabled";
+			timers6: timer at 40004000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40004000 0x400>;
+				interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM6_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 69 0x400 0x1>;
+				dma-names = "up";
+				status = "disabled";
+
+				timer at 5 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <5>;
+					status = "disabled";
+				};
 			};
 
-			dac2: dac at 2 {
-				compatible = "st,stm32-dac";
-				#io-channel-cells = <1>;
-				reg = <2>;
-				status = "disabled";
+			timers7: timer at 40005000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40005000 0x400>;
+				interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM7_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 70 0x400 0x1>;
+				dma-names = "up";
+				status = "disabled";
+
+				timer at 6 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <6>;
+					status = "disabled";
+				};
 			};
-		};
 
-		uart7: serial at 40018000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x40018000 0x400>;
-			interrupts-extended = <&exti 32 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc UART7_K>;
-			wakeup-source;
-			dmas = <&dmamux1 79 0x400 0x15>,
-			       <&dmamux1 80 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			timers12: timer at 40006000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40006000 0x400>;
+				interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM12_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		uart8: serial at 40019000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x40019000 0x400>;
-			interrupts-extended = <&exti 33 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc UART8_K>;
-			wakeup-source;
-			dmas = <&dmamux1 81 0x400 0x15>,
-			       <&dmamux1 82 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+				timer at 11 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <11>;
+					status = "disabled";
+				};
+			};
 
-		timers1: timer at 44000000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44000000 0x400>;
-			interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "brk", "up", "trg-com", "cc";
-			clocks = <&rcc TIM1_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 11 0x400 0x1>,
-			       <&dmamux1 12 0x400 0x1>,
-			       <&dmamux1 13 0x400 0x1>,
-			       <&dmamux1 14 0x400 0x1>,
-			       <&dmamux1 15 0x400 0x1>,
-			       <&dmamux1 16 0x400 0x1>,
-			       <&dmamux1 17 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4",
-				    "up", "trig", "com";
-			status = "disabled";
+			timers13: timer at 40007000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40007000 0x400>;
+				interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM13_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
+				timer at 12 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <12>;
+					status = "disabled";
+				};
 			};
 
-			timer at 0 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <0>;
-				status = "disabled";
-			};
+			timers14: timer at 40008000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x40008000 0x400>;
+				interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM14_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			counter {
-				compatible = "st,stm32-timer-counter";
-				status = "disabled";
+				timer at 13 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <13>;
+					status = "disabled";
+				};
 			};
-		};
 
-		timers8: timer at 44001000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44001000 0x400>;
-			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "brk", "up", "trg-com", "cc";
-			clocks = <&rcc TIM8_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 47 0x400 0x1>,
-			       <&dmamux1 48 0x400 0x1>,
-			       <&dmamux1 49 0x400 0x1>,
-			       <&dmamux1 50 0x400 0x1>,
-			       <&dmamux1 51 0x400 0x1>,
-			       <&dmamux1 52 0x400 0x1>,
-			       <&dmamux1 53 0x400 0x1>;
-			dma-names = "ch1", "ch2", "ch3", "ch4",
-				    "up", "trig", "com";
-			status = "disabled";
+			lptimer1: timer at 40009000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x40009000 0x400>;
+				interrupts-extended = <&exti 47 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM1_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
+				trigger at 0 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <0>;
+					status = "disabled";
+				};
+
+				counter {
+					compatible = "st,stm32-lptimer-counter";
+					status = "disabled";
+				};
 			};
 
-			timer at 7 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <7>;
+			i2s2: audio-controller at 4000b000 {
+				compatible = "st,stm32h7-i2s";
+				#sound-dai-cells = <0>;
+				reg = <0x4000b000 0x400>;
+				interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 39 0x400 0x01>,
+				       <&dmamux1 40 0x400 0x01>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			counter {
-				compatible = "st,stm32-timer-counter";
+			spi2: spi at 4000b000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x4000b000 0x400>;
+				interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI2_K>;
+				resets = <&rcc SPI2_R>;
+				dmas = <&dmamux1 39 0x400 0x05>,
+				       <&dmamux1 40 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
-
-		usart6: serial at 44003000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x44003000 0x400>;
-			interrupts-extended = <&exti 29 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART6_K>;
-			wakeup-source;
-			dmas = <&dmamux1 71 0x400 0x15>,
-			       <&dmamux1 72 0x400 0x11>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		spi1: spi at 44004000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x44004000 0x400>;
-			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI1_K>;
-			resets = <&rcc SPI1_R>;
-			dmas = <&dmamux1 37 0x400 0x05>,
-			       <&dmamux1 38 0x400 0x05>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		i2s1: audio-controller at 44004000 {
-			compatible = "st,stm32h7-i2s";
-			#sound-dai-cells = <0>;
-			reg = <0x44004000 0x400>;
-			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 37 0x400 0x01>,
-			       <&dmamux1 38 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
 
-		spi4: spi at 44005000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x44005000 0x400>;
-			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI4_K>;
-			resets = <&rcc SPI4_R>;
-			dmas = <&dmamux1 83 0x400 0x05>,
-			       <&dmamux1 84 0x400 0x05>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		timers15: timer at 44006000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44006000 0x400>;
-			interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM15_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 105 0x400 0x1>,
-			       <&dmamux1 106 0x400 0x1>,
-			       <&dmamux1 107 0x400 0x1>,
-			       <&dmamux1 108 0x400 0x1>;
-			dma-names = "ch1", "up", "trig", "com";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
+			i2s3: audio-controller at 4000c000 {
+				compatible = "st,stm32h7-i2s";
+				#sound-dai-cells = <0>;
+				reg = <0x4000c000 0x400>;
+				interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 61 0x400 0x01>,
+				       <&dmamux1 62 0x400 0x01>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			timer at 14 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <14>;
+			spi3: spi at 4000c000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x4000c000 0x400>;
+				interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI3_K>;
+				resets = <&rcc SPI3_R>;
+				dmas = <&dmamux1 61 0x400 0x05>,
+				       <&dmamux1 62 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
-
-		timers16: timer at 44007000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44007000 0x400>;
-			interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM16_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 109 0x400 0x1>,
-			       <&dmamux1 110 0x400 0x1>;
-			dma-names = "ch1", "up";
-			status = "disabled";
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
+			spdifrx: audio-controller at 4000d000 {
+				compatible = "st,stm32h7-spdifrx";
+				#sound-dai-cells = <0>;
+				reg = <0x4000d000 0x400>;
+				clocks = <&rcc SPDIF_K>;
+				clock-names = "kclk";
+				interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 93 0x400 0x01>,
+				       <&dmamux1 94 0x400 0x01>;
+				dma-names = "rx", "rx-ctrl";
+				status = "disabled";
+			};
+
+			usart2: serial at 4000e000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x4000e000 0x400>;
+				interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART2_K>;
+				wakeup-source;
+				dmas = <&dmamux1 43 0x400 0x15>,
+				       <&dmamux1 44 0x400 0x11>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			usart3: serial at 4000f000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x4000f000 0x400>;
+				interrupts-extended = <&exti 28 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART3_K>;
+				wakeup-source;
+				dmas = <&dmamux1 45 0x400 0x15>,
+				       <&dmamux1 46 0x400 0x11>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			uart4: serial at 40010000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x40010000 0x400>;
+				interrupts-extended = <&exti 30 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc UART4_K>;
+				wakeup-source;
+				dmas = <&dmamux1 63 0x400 0x15>,
+				       <&dmamux1 64 0x400 0x11>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			uart5: serial at 40011000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x40011000 0x400>;
+				interrupts-extended = <&exti 31 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc UART5_K>;
+				wakeup-source;
+				dmas = <&dmamux1 65 0x400 0x15>,
+				       <&dmamux1 66 0x400 0x11>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			i2c1: i2c at 40012000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x40012000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C1_K>;
+				resets = <&rcc I2C1_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x1>;
+				wakeup-source;
+				i2c-analog-filter;
 				status = "disabled";
 			};
-			timer at 15 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <15>;
+
+			i2c2: i2c at 40013000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x40013000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C2_K>;
+				resets = <&rcc I2C2_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x2>;
+				wakeup-source;
+				i2c-analog-filter;
 				status = "disabled";
 			};
-		};
 
-		timers17: timer at 44008000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x44008000 0x400>;
-			interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM17_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 111 0x400 0x1>,
-			       <&dmamux1 112 0x400 0x1>;
-			dma-names = "ch1", "up";
-			status = "disabled";
+			i2c3: i2c at 40014000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x40014000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C3_K>;
+				resets = <&rcc I2C3_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x4>;
+				wakeup-source;
+				i2c-analog-filter;
+				status = "disabled";
+			};
 
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
+			i2c5: i2c at 40015000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x40015000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C5_K>;
+				resets = <&rcc I2C5_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x10>;
+				wakeup-source;
+				i2c-analog-filter;
 				status = "disabled";
 			};
 
-			timer at 16 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <16>;
+			cec: cec at 40016000 {
+				compatible = "st,stm32-cec";
+				reg = <0x40016000 0x400>;
+				interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CEC_K>, <&rcc CEC>;
+				clock-names = "cec", "hdmi-cec";
 				status = "disabled";
 			};
-		};
 
-		spi5: spi at 44009000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x44009000 0x400>;
-			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI5_K>;
-			resets = <&rcc SPI5_R>;
-			dmas = <&dmamux1 85 0x400 0x05>,
-			       <&dmamux1 86 0x400 0x05>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
+			dac: dac at 40017000 {
+				compatible = "st,stm32h7-dac-core";
+				reg = <0x40017000 0x400>;
+				clocks = <&rcc DAC12>;
+				clock-names = "pclk";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
 
-		sai1: sai at 4400a000 {
-			compatible = "st,stm32h7-sai";
-			#address-cells = <1>;
-			#size-cells = <1>;
-			ranges = <0 0x4400a000 0x400>;
-			reg = <0x4400a000 0x4>, <0x4400a3f0 0x10>;
-			interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc SAI1_R>;
-			status = "disabled";
+				dac1: dac at 1 {
+					compatible = "st,stm32-dac";
+					#io-channel-cells = <1>;
+					reg = <1>;
+					status = "disabled";
+				};
 
-			sai1a: audio-controller at 4400a004 {
-				#sound-dai-cells = <0>;
+				dac2: dac at 2 {
+					compatible = "st,stm32-dac";
+					#io-channel-cells = <1>;
+					reg = <2>;
+					status = "disabled";
+				};
+			};
 
-				compatible = "st,stm32-sai-sub-a";
-				reg = <0x4 0x20>;
-				clocks = <&rcc SAI1_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 87 0x400 0x01>;
+			uart7: serial at 40018000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x40018000 0x400>;
+				interrupts-extended = <&exti 32 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc UART7_K>;
+				wakeup-source;
+				dmas = <&dmamux1 79 0x400 0x15>,
+				       <&dmamux1 80 0x400 0x11>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			sai1b: audio-controller at 4400a024 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-b";
-				reg = <0x24 0x20>;
-				clocks = <&rcc SAI1_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 88 0x400 0x01>;
+			uart8: serial at 40019000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x40019000 0x400>;
+				interrupts-extended = <&exti 33 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc UART8_K>;
+				wakeup-source;
+				dmas = <&dmamux1 81 0x400 0x15>,
+				       <&dmamux1 82 0x400 0x11>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
 
-		sai2: sai at 4400b000 {
-			compatible = "st,stm32h7-sai";
-			#address-cells = <1>;
-			#size-cells = <1>;
-			ranges = <0 0x4400b000 0x400>;
-			reg = <0x4400b000 0x4>, <0x4400b3f0 0x10>;
-			interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc SAI2_R>;
-			status = "disabled";
+			timers1: timer at 44000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44000000 0x400>;
+				interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "brk", "up", "trg-com", "cc";
+				clocks = <&rcc TIM1_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 11 0x400 0x1>,
+				       <&dmamux1 12 0x400 0x1>,
+				       <&dmamux1 13 0x400 0x1>,
+				       <&dmamux1 14 0x400 0x1>,
+				       <&dmamux1 15 0x400 0x1>,
+				       <&dmamux1 16 0x400 0x1>,
+				       <&dmamux1 17 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4",
+					    "up", "trig", "com";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			sai2a: audio-controller at 4400b004 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-a";
-				reg = <0x4 0x20>;
-				clocks = <&rcc SAI2_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 89 0x400 0x01>;
-				status = "disabled";
-			};
+				timer at 0 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <0>;
+					status = "disabled";
+				};
 
-			sai2b: audio-controller at 4400b024 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-b";
-				reg = <0x24 0x20>;
-				clocks = <&rcc SAI2_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 90 0x400 0x01>;
-				status = "disabled";
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
 			};
-		};
 
-		sai3: sai at 4400c000 {
-			compatible = "st,stm32h7-sai";
-			#address-cells = <1>;
-			#size-cells = <1>;
-			ranges = <0 0x4400c000 0x400>;
-			reg = <0x4400c000 0x4>, <0x4400c3f0 0x10>;
-			interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc SAI3_R>;
-			status = "disabled";
+			timers8: timer at 44001000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44001000 0x400>;
+				interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "brk", "up", "trg-com", "cc";
+				clocks = <&rcc TIM8_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 47 0x400 0x1>,
+				       <&dmamux1 48 0x400 0x1>,
+				       <&dmamux1 49 0x400 0x1>,
+				       <&dmamux1 50 0x400 0x1>,
+				       <&dmamux1 51 0x400 0x1>,
+				       <&dmamux1 52 0x400 0x1>,
+				       <&dmamux1 53 0x400 0x1>;
+				dma-names = "ch1", "ch2", "ch3", "ch4",
+					    "up", "trig", "com";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			sai3a: audio-controller at 4400c004 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-a";
-				reg = <0x04 0x20>;
-				clocks = <&rcc SAI3_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 113 0x400 0x01>;
+				timer at 7 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <7>;
+					status = "disabled";
+				};
+
+				counter {
+					compatible = "st,stm32-timer-counter";
+					status = "disabled";
+				};
+			};
+
+			usart6: serial at 44003000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x44003000 0x400>;
+				interrupts-extended = <&exti 29 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART6_K>;
+				wakeup-source;
+				dmas = <&dmamux1 71 0x400 0x15>,
+				<&dmamux1 72 0x400 0x11>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			sai3b: audio-controller at 4400c024 {
+			i2s1: audio-controller at 44004000 {
+				compatible = "st,stm32h7-i2s";
 				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-b";
-				reg = <0x24 0x20>;
-				clocks = <&rcc SAI3_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 114 0x400 0x01>;
+				reg = <0x44004000 0x400>;
+				interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 37 0x400 0x01>,
+				<&dmamux1 38 0x400 0x01>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
-
-		dfsdm: dfsdm at 4400d000 {
-			compatible = "st,stm32mp1-dfsdm";
-			reg = <0x4400d000 0x800>;
-			clocks = <&rcc DFSDM_K>;
-			clock-names = "dfsdm";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
 
-			dfsdm0: filter at 0 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <0>;
-				interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 101 0x400 0x01>;
-				dma-names = "rx";
+			spi1: spi at 44004000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x44004000 0x400>;
+				interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI1_K>;
+				resets = <&rcc SPI1_R>;
+				dmas = <&dmamux1 37 0x400 0x05>,
+				<&dmamux1 38 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			dfsdm1: filter at 1 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <1>;
-				interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 102 0x400 0x01>;
-				dma-names = "rx";
+			spi4: spi at 44005000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x44005000 0x400>;
+				interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI4_K>;
+				resets = <&rcc SPI4_R>;
+				dmas = <&dmamux1 83 0x400 0x05>,
+				<&dmamux1 84 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
 
-			dfsdm2: filter at 2 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <2>;
-				interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 103 0x400 0x01>;
-				dma-names = "rx";
-				status = "disabled";
+			timers15: timer at 44006000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44006000 0x400>;
+				interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM15_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 105 0x400 0x1>,
+				       <&dmamux1 106 0x400 0x1>,
+				       <&dmamux1 107 0x400 0x1>,
+				       <&dmamux1 108 0x400 0x1>;
+				dma-names = "ch1", "up", "trig", "com";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 14 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <14>;
+					status = "disabled";
+				};
 			};
 
-			dfsdm3: filter at 3 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <3>;
-				interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 104 0x400 0x01>;
-				dma-names = "rx";
-				status = "disabled";
+			timers16: timer at 44007000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44007000 0x400>;
+				interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM16_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 109 0x400 0x1>,
+				<&dmamux1 110 0x400 0x1>;
+				dma-names = "ch1", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+				timer at 15 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <15>;
+					status = "disabled";
+				};
 			};
 
-			dfsdm4: filter at 4 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <4>;
-				interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 91 0x400 0x01>;
-				dma-names = "rx";
-				status = "disabled";
+			timers17: timer at 44008000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x44008000 0x400>;
+				interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM17_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 111 0x400 0x1>,
+				<&dmamux1 112 0x400 0x1>;
+				dma-names = "ch1", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 16 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <16>;
+					status = "disabled";
+				};
 			};
 
-			dfsdm5: filter at 5 {
-				compatible = "st,stm32-dfsdm-adc";
-				#io-channel-cells = <1>;
-				reg = <5>;
-				interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&dmamux1 92 0x400 0x01>;
-				dma-names = "rx";
+			spi5: spi at 44009000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x44009000 0x400>;
+				interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI5_K>;
+				resets = <&rcc SPI5_R>;
+				dmas = <&dmamux1 85 0x400 0x05>,
+				<&dmamux1 86 0x400 0x05>;
+				dma-names = "rx", "tx";
 				status = "disabled";
 			};
-		};
 
-		dma1: dma-controller at 48000000 {
-			compatible = "st,stm32-dma";
-			reg = <0x48000000 0x400>;
-			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc DMA1>;
-			resets = <&rcc DMA1_R>;
-			#dma-cells = <4>;
-			st,mem2mem;
-			dma-requests = <8>;
-		};
+			sai1: sai at 4400a000 {
+				compatible = "st,stm32h7-sai";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x4400a000 0x400>;
+				reg = <0x4400a000 0x4>, <0x4400a3f0 0x10>;
+				interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc SAI1_R>;
+				status = "disabled";
+
+				sai1a: audio-controller at 4400a004 {
+					#sound-dai-cells = <0>;
+
+					compatible = "st,stm32-sai-sub-a";
+					reg = <0x4 0x20>;
+					clocks = <&rcc SAI1_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 87 0x400 0x01>;
+					status = "disabled";
+				};
 
-		dma2: dma-controller at 48001000 {
-			compatible = "st,stm32-dma";
-			reg = <0x48001000 0x400>;
-			interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc DMA2>;
-			resets = <&rcc DMA2_R>;
-			#dma-cells = <4>;
-			st,mem2mem;
-			dma-requests = <8>;
-		};
+				sai1b: audio-controller at 4400a024 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-b";
+					reg = <0x24 0x20>;
+					clocks = <&rcc SAI1_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 88 0x400 0x01>;
+					status = "disabled";
+				};
+			};
 
-		dmamux1: dma-router at 48002000 {
-			compatible = "st,stm32h7-dmamux";
-			reg = <0x48002000 0x40>;
-			#dma-cells = <3>;
-			dma-requests = <128>;
-			dma-masters = <&dma1 &dma2>;
-			dma-channels = <16>;
-			clocks = <&rcc DMAMUX>;
-			resets = <&rcc DMAMUX_R>;
-		};
+			sai2: sai at 4400b000 {
+				compatible = "st,stm32h7-sai";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x4400b000 0x400>;
+				reg = <0x4400b000 0x4>, <0x4400b3f0 0x10>;
+				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc SAI2_R>;
+				status = "disabled";
+
+				sai2a: audio-controller at 4400b004 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-a";
+					reg = <0x4 0x20>;
+					clocks = <&rcc SAI2_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 89 0x400 0x01>;
+					status = "disabled";
+				};
 
-		adc: adc at 48003000 {
-			compatible = "st,stm32mp1-adc-core";
-			reg = <0x48003000 0x400>;
-			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc ADC12>, <&rcc ADC12_K>;
-			clock-names = "bus", "adc";
-			interrupt-controller;
-			st,syscfg = <&syscfg>;
-			#interrupt-cells = <1>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
+				sai2b: audio-controller at 4400b024 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-b";
+					reg = <0x24 0x20>;
+					clocks = <&rcc SAI2_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 90 0x400 0x01>;
+					status = "disabled";
+				};
+			};
 
-			adc1: adc at 0 {
-				compatible = "st,stm32mp1-adc";
-				#io-channel-cells = <1>;
+			sai3: sai at 4400c000 {
+				compatible = "st,stm32h7-sai";
 				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x0>;
-				interrupt-parent = <&adc>;
-				interrupts = <0>;
-				dmas = <&dmamux1 9 0x400 0x01>;
-				dma-names = "rx";
-				status = "disabled";
+				#size-cells = <1>;
+				ranges = <0 0x4400c000 0x400>;
+				reg = <0x4400c000 0x4>, <0x4400c3f0 0x10>;
+				interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc SAI3_R>;
+				status = "disabled";
+
+				sai3a: audio-controller at 4400c004 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-a";
+					reg = <0x04 0x20>;
+					clocks = <&rcc SAI3_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 113 0x400 0x01>;
+					status = "disabled";
+				};
+
+				sai3b: audio-controller at 4400c024 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-b";
+					reg = <0x24 0x20>;
+					clocks = <&rcc SAI3_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 114 0x400 0x01>;
+					status = "disabled";
+				};
 			};
 
-			adc2: adc at 100 {
-				compatible = "st,stm32mp1-adc";
-				#io-channel-cells = <1>;
+			dfsdm: dfsdm at 4400d000 {
+				compatible = "st,stm32mp1-dfsdm";
+				reg = <0x4400d000 0x800>;
+				clocks = <&rcc DFSDM_K>;
+				clock-names = "dfsdm";
 				#address-cells = <1>;
 				#size-cells = <0>;
-				reg = <0x100>;
-				interrupt-parent = <&adc>;
-				interrupts = <1>;
-				dmas = <&dmamux1 10 0x400 0x01>;
-				dma-names = "rx";
-				nvmem-cells = <&vrefint>;
-				nvmem-cell-names = "vrefint";
-				status = "disabled";
-				channel at 13 {
-					reg = <13>;
-					label = "vrefint";
+				status = "disabled";
+
+				dfsdm0: filter at 0 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <0>;
+					interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 101 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
 				};
-				channel at 14 {
-					reg = <14>;
-					label = "vddcore";
+
+				dfsdm1: filter at 1 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <1>;
+					interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 102 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
 				};
-			};
-		};
 
-		sdmmc3: mmc at 48004000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x00253180>;
-			reg = <0x48004000 0x400>;
-			interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC3_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC3_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <120000000>;
-			status = "disabled";
-		};
+				dfsdm2: filter at 2 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <2>;
+					interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 103 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 
-		usbotg_hs: usb-otg at 49000000 {
-			compatible = "st,stm32mp15-hsotg", "snps,dwc2";
-			reg = <0x49000000 0x10000>;
-			clocks = <&rcc USBO_K>, <&usbphyc>;
-			clock-names = "otg", "utmi";
-			resets = <&rcc USBO_R>;
-			reset-names = "dwc2";
-			interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
-			g-rx-fifo-size = <512>;
-			g-np-tx-fifo-size = <32>;
-			g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
-			dr_mode = "otg";
-			otg-rev = <0x200>;
-			usb33d-supply = <&usb33>;
-			status = "disabled";
-		};
-
-		ipcc: mailbox at 4c001000 {
-			compatible = "st,stm32mp1-ipcc";
-			#mbox-cells = <1>;
-			reg = <0x4c001000 0x400>;
-			st,proc-id = <0>;
-			interrupts-extended =
-				<&exti 61 1>,
-				<&intc GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "rx", "tx";
-			clocks = <&rcc IPCC>;
-			wakeup-source;
-			status = "disabled";
-		};
-
-		dcmi: dcmi at 4c006000 {
-			compatible = "st,stm32-dcmi";
-			reg = <0x4c006000 0x400>;
-			interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc CAMITF_R>;
-			clocks = <&rcc DCMI>;
-			clock-names = "mclk";
-			dmas = <&dmamux1 75 0x400 0x01>;
-			dma-names = "tx";
-			status = "disabled";
-		};
-
-		rcc: rcc at 50000000 {
-			compatible = "st,stm32mp1-rcc", "syscon";
-			reg = <0x50000000 0x1000>;
-			#clock-cells = <1>;
-			#reset-cells = <1>;
-		};
-
-		pwr_regulators: pwr at 50001000 {
-			compatible = "st,stm32mp1,pwr-reg";
-			reg = <0x50001000 0x10>;
-
-			reg11: reg11 {
-				regulator-name = "reg11";
-				regulator-min-microvolt = <1100000>;
-				regulator-max-microvolt = <1100000>;
-			};
+				dfsdm3: filter at 3 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <3>;
+					interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 104 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 
-			reg18: reg18 {
-				regulator-name = "reg18";
-				regulator-min-microvolt = <1800000>;
-				regulator-max-microvolt = <1800000>;
-			};
+				dfsdm4: filter at 4 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <4>;
+					interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 91 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 
-			usb33: usb33 {
-				regulator-name = "usb33";
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
+				dfsdm5: filter at 5 {
+					compatible = "st,stm32-dfsdm-adc";
+					#io-channel-cells = <1>;
+					reg = <5>;
+					interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&dmamux1 92 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 			};
-		};
-
-		pwr_mcu: pwr_mcu at 50001014 {
-			compatible = "st,stm32mp151-pwr-mcu", "syscon";
-			reg = <0x50001014 0x4>;
-		};
-
-		exti: interrupt-controller at 5000d000 {
-			compatible = "st,stm32mp1-exti", "syscon";
-			interrupt-controller;
-			#interrupt-cells = <2>;
-			reg = <0x5000d000 0x400>;
-		};
 
-		syscfg: syscon at 50020000 {
-			compatible = "st,stm32mp157-syscfg", "syscon";
-			reg = <0x50020000 0x400>;
-			clocks = <&rcc SYSCFG>;
-		};
+			dma1: dma-controller at 48000000 {
+				compatible = "st,stm32-dma";
+				reg = <0x48000000 0x400>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc DMA1>;
+				resets = <&rcc DMA1_R>;
+				#dma-cells = <4>;
+				st,mem2mem;
+				dma-requests = <8>;
+			};
+
+			dma2: dma-controller at 48001000 {
+				compatible = "st,stm32-dma";
+				reg = <0x48001000 0x400>;
+				interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc DMA2>;
+				resets = <&rcc DMA2_R>;
+				#dma-cells = <4>;
+				st,mem2mem;
+				dma-requests = <8>;
+			};
+
+			dmamux1: dma-router at 48002000 {
+				compatible = "st,stm32h7-dmamux";
+				reg = <0x48002000 0x40>;
+				#dma-cells = <3>;
+				dma-requests = <128>;
+				dma-masters = <&dma1 &dma2>;
+				dma-channels = <16>;
+				clocks = <&rcc DMAMUX>;
+				resets = <&rcc DMAMUX_R>;
+			};
+
+			adc: adc at 48003000 {
+				compatible = "st,stm32mp1-adc-core";
+				reg = <0x48003000 0x400>;
+				interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc ADC12>, <&rcc ADC12_K>;
+				clock-names = "bus", "adc";
+				interrupt-controller;
+				st,syscfg = <&syscfg>;
+				#interrupt-cells = <1>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
 
-		lptimer2: timer at 50021000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x50021000 0x400>;
-			interrupts-extended = <&exti 48 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM2_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
+				adc1: adc at 0 {
+					compatible = "st,stm32mp1-adc";
+					#io-channel-cells = <1>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x0>;
+					interrupt-parent = <&adc>;
+					interrupts = <0>;
+					dmas = <&dmamux1 9 0x400 0x01>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
+				adc2: adc at 100 {
+					compatible = "st,stm32mp1-adc";
+					#io-channel-cells = <1>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x100>;
+					interrupt-parent = <&adc>;
+					interrupts = <1>;
+					dmas = <&dmamux1 10 0x400 0x01>;
+					dma-names = "rx";
+					nvmem-cells = <&vrefint>;
+					nvmem-cell-names = "vrefint";
+					status = "disabled";
+					channel at 13 {
+						reg = <13>;
+						label = "vrefint";
+					};
+					channel at 14 {
+						reg = <14>;
+						label = "vddcore";
+					};
+				};
 			};
 
-			trigger at 1 {
-				compatible = "st,stm32-lptimer-trigger";
-				reg = <1>;
+			sdmmc3: mmc at 48004000 {
+				compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+				arm,primecell-periphid = <0x00253180>;
+				reg = <0x48004000 0x400>;
+				interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SDMMC3_K>;
+				clock-names = "apb_pclk";
+				resets = <&rcc SDMMC3_R>;
+				cap-sd-highspeed;
+				cap-mmc-highspeed;
+				max-frequency = <120000000>;
 				status = "disabled";
 			};
 
-			counter {
-				compatible = "st,stm32-lptimer-counter";
+			usbotg_hs: usb-otg at 49000000 {
+				compatible = "st,stm32mp15-hsotg", "snps,dwc2";
+				reg = <0x49000000 0x10000>;
+				clocks = <&rcc USBO_K>, <&usbphyc>;
+				clock-names = "otg", "utmi";
+				resets = <&rcc USBO_R>;
+				reset-names = "dwc2";
+				interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+				g-rx-fifo-size = <512>;
+				g-np-tx-fifo-size = <32>;
+				g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
+				dr_mode = "otg";
+				otg-rev = <0x200>;
+				usb33d-supply = <&usb33>;
 				status = "disabled";
 			};
-		};
-
-		lptimer3: timer at 50022000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x50022000 0x400>;
-			interrupts-extended = <&exti 50 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM3_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
+			dcmi: dcmi at 4c006000 {
+				compatible = "st,stm32-dcmi";
+				reg = <0x4c006000 0x400>;
+				interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc CAMITF_R>;
+				clocks = <&rcc DCMI>;
+				clock-names = "mclk";
+				dmas = <&dmamux1 75 0x400 0x01>;
+				dma-names = "tx";
 				status = "disabled";
 			};
 
-			trigger at 2 {
-				compatible = "st,stm32-lptimer-trigger";
-				reg = <2>;
-				status = "disabled";
-			};
-		};
+			lptimer2: timer at 50021000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x50021000 0x400>;
+				interrupts-extended = <&exti 48 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM2_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-		lptimer4: timer at 50023000 {
-			compatible = "st,stm32-lptimer";
-			reg = <0x50023000 0x400>;
-			interrupts-extended = <&exti 52 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM4_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
+				trigger at 1 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <1>;
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
+				counter {
+					compatible = "st,stm32-lptimer-counter";
+					status = "disabled";
+				};
 			};
-		};
 
-		lptimer5: timer at 50024000 {
-			compatible = "st,stm32-lptimer";
-			reg = <0x50024000 0x400>;
-			interrupts-extended = <&exti 53 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM5_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
+			lptimer3: timer at 50022000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x50022000 0x400>;
+				interrupts-extended = <&exti 50 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM3_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
+				trigger at 2 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <2>;
+					status = "disabled";
+				};
 			};
-		};
 
-		vrefbuf: vrefbuf at 50025000 {
-			compatible = "st,stm32-vrefbuf";
-			reg = <0x50025000 0x8>;
-			regulator-min-microvolt = <1500000>;
-			regulator-max-microvolt = <2500000>;
-			clocks = <&rcc VREF>;
-			status = "disabled";
-		};
+			lptimer4: timer at 50023000 {
+				compatible = "st,stm32-lptimer";
+				reg = <0x50023000 0x400>;
+				interrupts-extended = <&exti 52 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM4_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
 
-		sai4: sai at 50027000 {
-			compatible = "st,stm32h7-sai";
-			#address-cells = <1>;
-			#size-cells = <1>;
-			ranges = <0 0x50027000 0x400>;
-			reg = <0x50027000 0x4>, <0x500273f0 0x10>;
-			interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
-			resets = <&rcc SAI4_R>;
-			status = "disabled";
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+			};
 
-			sai4a: audio-controller at 50027004 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-a";
-				reg = <0x04 0x20>;
-				clocks = <&rcc SAI4_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 99 0x400 0x01>;
+			lptimer5: timer at 50024000 {
+				compatible = "st,stm32-lptimer";
+				reg = <0x50024000 0x400>;
+				interrupts-extended = <&exti 53 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM5_K>;
+				clock-names = "mux";
+				wakeup-source;
 				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
 			};
 
-			sai4b: audio-controller at 50027024 {
-				#sound-dai-cells = <0>;
-				compatible = "st,stm32-sai-sub-b";
-				reg = <0x24 0x20>;
-				clocks = <&rcc SAI4_K>;
-				clock-names = "sai_ck";
-				dmas = <&dmamux1 100 0x400 0x01>;
+			vrefbuf: vrefbuf at 50025000 {
+				compatible = "st,stm32-vrefbuf";
+				reg = <0x50025000 0x8>;
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <2500000>;
+				clocks = <&rcc VREF>;
 				status = "disabled";
 			};
-		};
 
-		dts: thermal at 50028000 {
-			compatible = "st,stm32-thermal";
-			reg = <0x50028000 0x100>;
-			interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc TMPSENS>;
-			clock-names = "pclk";
-			#thermal-sensor-cells = <0>;
-			status = "disabled";
-		};
-
-		hash1: hash at 54002000 {
-			compatible = "st,stm32f756-hash";
-			reg = <0x54002000 0x400>;
-			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc HASH1>;
-			resets = <&rcc HASH1_R>;
-			dmas = <&mdma1 31 0x2 0x1000A02 0x0 0x0>;
-			dma-names = "in";
-			dma-maxburst = <2>;
-			status = "disabled";
-		};
-
-		rng1: rng at 54003000 {
-			compatible = "st,stm32-rng";
-			reg = <0x54003000 0x400>;
-			clocks = <&rcc RNG1_K>;
-			resets = <&rcc RNG1_R>;
-			status = "disabled";
-		};
-
-		mdma1: dma-controller at 58000000 {
-			compatible = "st,stm32h7-mdma";
-			reg = <0x58000000 0x1000>;
-			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc MDMA>;
-			resets = <&rcc MDMA_R>;
-			#dma-cells = <5>;
-			dma-channels = <32>;
-			dma-requests = <48>;
-		};
+			sai4: sai at 50027000 {
+				compatible = "st,stm32h7-sai";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x50027000 0x400>;
+				reg = <0x50027000 0x4>, <0x500273f0 0x10>;
+				interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&rcc SAI4_R>;
+				status = "disabled";
+
+				sai4a: audio-controller at 50027004 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-a";
+					reg = <0x04 0x20>;
+					clocks = <&rcc SAI4_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 99 0x400 0x01>;
+					status = "disabled";
+				};
 
-		fmc: memory-controller at 58002000 {
-			#address-cells = <2>;
-			#size-cells = <1>;
-			compatible = "st,stm32mp1-fmc2-ebi";
-			reg = <0x58002000 0x1000>;
-			clocks = <&rcc FMC_K>;
-			resets = <&rcc FMC_R>;
-			status = "disabled";
+				sai4b: audio-controller at 50027024 {
+					#sound-dai-cells = <0>;
+					compatible = "st,stm32-sai-sub-b";
+					reg = <0x24 0x20>;
+					clocks = <&rcc SAI4_K>;
+					clock-names = "sai_ck";
+					dmas = <&dmamux1 100 0x400 0x01>;
+					status = "disabled";
+				};
+			};
 
-			ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
-				 <1 0 0x64000000 0x04000000>, /* EBI CS 2 */
-				 <2 0 0x68000000 0x04000000>, /* EBI CS 3 */
-				 <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */
-				 <4 0 0x80000000 0x10000000>; /* NAND */
+			hash1: hash at 54002000 {
+				compatible = "st,stm32f756-hash";
+				reg = <0x54002000 0x400>;
+				interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc HASH1>;
+				resets = <&rcc HASH1_R>;
+				dmas = <&mdma1 31 0x2 0x1000A02 0x0 0x0>;
+				dma-names = "in";
+				dma-maxburst = <2>;
+				status = "disabled";
+			};
+
+			rng1: rng at 54003000 {
+				compatible = "st,stm32-rng";
+				reg = <0x54003000 0x400>;
+				clocks = <&rcc RNG1_K>;
+				resets = <&rcc RNG1_R>;
+				status = "okay";
+			};
+
+			fmc: memory-controller at 58002000 {
+				#address-cells = <2>;
+				#size-cells = <1>;
+				compatible = "st,stm32mp1-fmc2-ebi";
+				reg = <0x58002000 0x1000>;
+				clocks = <&rcc FMC_K>;
+				resets = <&rcc FMC_R>;
+				status = "disabled";
+
+				ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
+					 <1 0 0x64000000 0x04000000>, /* EBI CS 2 */
+					 <2 0 0x68000000 0x04000000>, /* EBI CS 3 */
+					 <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */
+					 <4 0 0x80000000 0x10000000>; /* NAND */
+
+				nand-controller at 4,0 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					compatible = "st,stm32mp1-fmc2-nfc";
+					reg = <4 0x00000000 0x1000>,
+					      <4 0x08010000 0x1000>,
+					      <4 0x08020000 0x1000>,
+					      <4 0x01000000 0x1000>,
+					      <4 0x09010000 0x1000>,
+					      <4 0x09020000 0x1000>;
+					interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
+					       <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
+					       <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
+					dma-names = "tx", "rx", "ecc";
+					status = "disabled";
+				};
+			};
 
-			nand-controller at 4,0 {
+			qspi: spi at 58003000 {
+				compatible = "st,stm32f469-qspi";
+				reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
+				reg-names = "qspi", "qspi_mm";
+				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&mdma1 22 0x2 0x10100002 0x0 0x0>,
+				       <&mdma1 22 0x2 0x10100008 0x0 0x0>;
+				dma-names = "tx", "rx";
+				clocks = <&rcc QSPI_K>;
+				resets = <&rcc QSPI_R>;
 				#address-cells = <1>;
 				#size-cells = <0>;
-				compatible = "st,stm32mp1-fmc2-nfc";
-				reg = <4 0x00000000 0x1000>,
-				      <4 0x08010000 0x1000>,
-				      <4 0x08020000 0x1000>,
-				      <4 0x01000000 0x1000>,
-				      <4 0x09010000 0x1000>,
-				      <4 0x09020000 0x1000>;
-				interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
-				       <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
-				       <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
-				dma-names = "tx", "rx", "ecc";
 				status = "disabled";
 			};
-		};
-
-		qspi: spi at 58003000 {
-			compatible = "st,stm32f469-qspi";
-			reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
-			reg-names = "qspi", "qspi_mm";
-			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&mdma1 22 0x2 0x10100002 0x0 0x0>,
-			       <&mdma1 22 0x2 0x10100008 0x0 0x0>;
-			dma-names = "tx", "rx";
-			clocks = <&rcc QSPI_K>;
-			resets = <&rcc QSPI_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-		};
-
-		sdmmc1: mmc at 58005000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x00253180>;
-			reg = <0x58005000 0x1000>;
-			interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC1_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC1_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <120000000>;
-			status = "disabled";
-		};
 
-		sdmmc2: mmc at 58007000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x00253180>;
-			reg = <0x58007000 0x1000>;
-			interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC2_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC2_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <120000000>;
-			status = "disabled";
-		};
-
-		crc1: crc at 58009000 {
-			compatible = "st,stm32f7-crc";
-			reg = <0x58009000 0x400>;
-			clocks = <&rcc CRC1>;
-			status = "disabled";
-		};
-
-		ethernet0: ethernet at 5800a000 {
-			compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a";
-			reg = <0x5800a000 0x2000>;
-			reg-names = "stmmaceth";
-			interrupts-extended = <&intc GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "macirq";
-			clock-names = "stmmaceth",
-				      "mac-clk-tx",
-				      "mac-clk-rx",
-				      "eth-ck",
-				      "ptp_ref",
-				      "ethstp";
-			clocks = <&rcc ETHMAC>,
-				 <&rcc ETHTX>,
-				 <&rcc ETHRX>,
-				 <&rcc ETHCK_K>,
-				 <&rcc ETHPTP_K>,
-				 <&rcc ETHSTP>;
-			st,syscon = <&syscfg 0x4>;
-			snps,mixed-burst;
-			snps,pbl = <2>;
-			snps,en-tx-lpi-clockgating;
-			snps,axi-config = <&stmmac_axi_config_0>;
-			snps,tso;
-			status = "disabled";
-
-			stmmac_axi_config_0: stmmac-axi-config {
-				snps,wr_osr_lmt = <0x7>;
-				snps,rd_osr_lmt = <0x7>;
-				snps,blen = <0 0 0 0 16 8 4>;
+			ethernet0: ethernet at 5800a000 {
+				compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a";
+				reg = <0x5800a000 0x2000>;
+				reg-names = "stmmaceth";
+				interrupts-extended = <&intc GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "macirq";
+				clock-names = "stmmaceth",
+					      "mac-clk-tx",
+					      "mac-clk-rx",
+					      "eth-ck",
+					      "ptp_ref",
+					      "ethstp";
+				clocks = <&rcc ETHMAC>,
+					 <&rcc ETHTX>,
+					 <&rcc ETHRX>,
+					 <&rcc ETHCK_K>,
+					 <&rcc ETHPTP_K>,
+					 <&rcc ETHSTP>;
+				st,syscon = <&syscfg 0x4>;
+				snps,mixed-burst;
+				snps,pbl = <2>;
+				snps,en-tx-lpi-clockgating;
+				snps,axi-config = <&stmmac_axi_config_0>;
+				snps,tso;
+				status = "disabled";
+
+				stmmac_axi_config_0: stmmac-axi-config {
+					snps,wr_osr_lmt = <0x7>;
+					snps,rd_osr_lmt = <0x7>;
+					snps,blen = <0 0 0 0 16 8 4>;
+				};
 			};
-		};
-
-		usbh_ohci: usb at 5800c000 {
-			compatible = "generic-ohci";
-			reg = <0x5800c000 0x1000>;
-			clocks = <&usbphyc>, <&rcc USBH>;
-			resets = <&rcc USBH_R>;
-			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-		};
-
-		usbh_ehci: usb at 5800d000 {
-			compatible = "generic-ehci";
-			reg = <0x5800d000 0x1000>;
-			clocks = <&usbphyc>, <&rcc USBH>;
-			resets = <&rcc USBH_R>;
-			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
-			companion = <&usbh_ohci>;
-			status = "disabled";
-		};
-
-		ltdc: display-controller at 5a001000 {
-			compatible = "st,stm32-ltdc";
-			reg = <0x5a001000 0x400>;
-			interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LTDC_PX>;
-			clock-names = "lcd";
-			resets = <&rcc LTDC_R>;
-			status = "disabled";
-		};
-
-		iwdg2: watchdog at 5a002000 {
-			compatible = "st,stm32mp1-iwdg";
-			reg = <0x5a002000 0x400>;
-			clocks = <&rcc IWDG2>, <&rcc CK_LSI>;
-			clock-names = "pclk", "lsi";
-			status = "disabled";
-		};
-
-		usbphyc: usbphyc at 5a006000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			#clock-cells = <0>;
-			compatible = "st,stm32mp1-usbphyc";
-			reg = <0x5a006000 0x1000>;
-			clocks = <&rcc USBPHY_K>;
-			resets = <&rcc USBPHY_R>;
-			vdda1v1-supply = <&reg11>;
-			vdda1v8-supply = <&reg18>;
-			status = "disabled";
 
-			usbphyc_port0: usb-phy at 0 {
-				#phy-cells = <0>;
-				reg = <0>;
+			usart1: serial at 5c000000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x5c000000 0x400>;
+				interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART1_K>;
+				wakeup-source;
+				status = "disabled";
 			};
 
-			usbphyc_port1: usb-phy at 1 {
-				#phy-cells = <1>;
-				reg = <1>;
+			spi6: spi at 5c001000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32h7-spi";
+				reg = <0x5c001000 0x400>;
+				interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI6_K>;
+				resets = <&rcc SPI6_R>;
+				dmas = <&mdma1 34 0x0 0x40008 0x0 0x0>,
+				       <&mdma1 35 0x0 0x40002 0x0 0x0>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			i2c4: i2c at 5c002000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x5c002000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C4_K>;
+				resets = <&rcc I2C4_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x8>;
+				wakeup-source;
+				i2c-analog-filter;
+				status = "disabled";
 			};
-		};
 
-		usart1: serial at 5c000000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x5c000000 0x400>;
-			interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART1_K>;
-			wakeup-source;
-			status = "disabled";
-		};
-
-		spi6: spi at 5c001000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32h7-spi";
-			reg = <0x5c001000 0x400>;
-			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI6_K>;
-			resets = <&rcc SPI6_R>;
-			dmas = <&mdma1 34 0x0 0x40008 0x0 0x0>,
-			       <&mdma1 35 0x0 0x40002 0x0 0x0>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		i2c4: i2c at 5c002000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x5c002000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C4_K>;
-			resets = <&rcc I2C4_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x8>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
-		rtc: rtc at 5c004000 {
-			compatible = "st,stm32mp1-rtc";
-			reg = <0x5c004000 0x400>;
-			clocks = <&rcc RTCAPB>, <&rcc RTC>;
-			clock-names = "pclk", "rtc_ck";
-			interrupts-extended = <&exti 19 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-		};
-
-		bsec: efuse at 5c005000 {
-			compatible = "st,stm32mp15-bsec";
-			reg = <0x5c005000 0x400>;
-			#address-cells = <1>;
-			#size-cells = <1>;
-			part_number_otp: part-number-otp at 4 {
-				reg = <0x4 0x1>;
-			};
-			vrefint: vrefin-cal at 52 {
-				reg = <0x52 0x2>;
-			};
-			ts_cal1: calib at 5c {
-				reg = <0x5c 0x2>;
-			};
-			ts_cal2: calib at 5e {
-				reg = <0x5e 0x2>;
+			i2c6: i2c at 5c009000 {
+				compatible = "st,stm32mp15-i2c";
+				reg = <0x5c009000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C6_K>;
+				resets = <&rcc I2C6_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				st,syscfg-fmp = <&syscfg 0x4 0x20>;
+				wakeup-source;
+				i2c-analog-filter;
+				status = "disabled";
 			};
 		};
 
-		i2c6: i2c at 5c009000 {
-			compatible = "st,stm32mp15-i2c";
-			reg = <0x5c009000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C6_K>;
-			resets = <&rcc I2C6_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			st,syscfg-fmp = <&syscfg 0x4 0x20>;
-			wakeup-source;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
 		tamp: tamp at 5c00a000 {
 			compatible = "st,stm32-tamp", "syscon", "simple-mfd";
 			reg = <0x5c00a000 0x400>;
diff --git a/arch/arm/boot/dts/st/stm32mp153.dtsi b/arch/arm/boot/dts/st/stm32mp153.dtsi
index 486084e0b80b..36e17ea0b179 100644
--- a/arch/arm/boot/dts/st/stm32mp153.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp153.dtsi
@@ -28,32 +28,32 @@ timer {
 			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
 			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
 	};
+};
 
-	soc {
-		m_can1: can at 4400e000 {
-			compatible = "bosch,m_can";
-			reg = <0x4400e000 0x400>, <0x44011000 0x1400>;
-			reg-names = "m_can", "message_ram";
-			interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "int0", "int1";
-			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
-			clock-names = "hclk", "cclk";
-			bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
-			status = "disabled";
-		};
+&etzpc {
+	m_can1: can at 4400e000 {
+		compatible = "bosch,m_can";
+		reg = <0x4400e000 0x400>, <0x44011000 0x1400>;
+		reg-names = "m_can", "message_ram";
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "int0", "int1";
+		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+		clock-names = "hclk", "cclk";
+		bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+		status = "disabled";
+	};
 
-		m_can2: can at 4400f000 {
-			compatible = "bosch,m_can";
-			reg = <0x4400f000 0x400>, <0x44011000 0x2800>;
-			reg-names = "m_can", "message_ram";
-			interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "int0", "int1";
-			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
-			clock-names = "hclk", "cclk";
-			bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
-			status = "disabled";
-		};
+	m_can2: can at 4400f000 {
+		compatible = "bosch,m_can";
+		reg = <0x4400f000 0x400>, <0x44011000 0x2800>;
+		reg-names = "m_can", "message_ram";
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "int0", "int1";
+		clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+		clock-names = "hclk", "cclk";
+		bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
+		status = "disabled";
 	};
 };
diff --git a/arch/arm/boot/dts/st/stm32mp15xc.dtsi b/arch/arm/boot/dts/st/stm32mp15xc.dtsi
index b06a55a2fa18..d36c3457451a 100644
--- a/arch/arm/boot/dts/st/stm32mp15xc.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xc.dtsi
@@ -4,15 +4,13 @@
  * Author: Alexandre Torgue <alexandre.torgue at st.com> for STMicroelectronics.
  */
 
-/ {
-	soc {
-		cryp1: cryp at 54001000 {
-			compatible = "st,stm32mp1-cryp";
-			reg = <0x54001000 0x400>;
-			interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CRYP1>;
-			resets = <&rcc CRYP1_R>;
-			status = "disabled";
-		};
+&etzpc {
+	cryp1: cryp at 54001000 {
+		compatible = "st,stm32mp1-cryp";
+		reg = <0x54001000 0x400>;
+		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&rcc CRYP1>;
+		resets = <&rcc CRYP1_R>;
+		status = "disabled";
 	};
 };
-- 
2.25.1



From broonie at kernel.org  Tue Dec 12 07:27:35 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 12 Dec 2023 15:27:35 +0000
Subject: [PATCH v8 1/6] pwm: Rename pwm_apply_state() to
 pwm_apply_might_sleep()
In-Reply-To: <f7be8d89-25ae-4d83-9577-12fcac41d0ab@roeck-us.net>
References: <cover.1702369869.git.sean@mess.org>
 <9af7ba748fd2eb7e04208b6b183185f1daf78016.1702369869.git.sean@mess.org>
 <20231212114100.sn7nzntousql2ays@pengutronix.de>
 <f7be8d89-25ae-4d83-9577-12fcac41d0ab@roeck-us.net>
Message-ID: <7594ea09-a6f3-4dac-acb3-d5f899f9cf84@sirena.org.uk>

On Tue, Dec 12, 2023 at 07:22:18AM -0800, Guenter Roeck wrote:
> On 12/12/23 03:41, Uwe Kleine-K?nig wrote:

> > Several affected maintainers already acked, so I guess it's fine to take
> > this via the pwm tree. An Ack from the remaining maintainers would be
> > very welcome, an alternative would be to split the patch.

> > Missing Acks so far:

> >   - Jean Delvare / Guenter Roeck for drivers/hwmon/pwm-fan.c
> >   - Javier Martinez Canillas for drivers/gpu/drm/solomon/ssd130x.c
> >   - Liam Girdwood / Mark Brown for drivers/regulator/pwm-regulator.c
> >   - Helge Deller for drivers/video/fbdev/ssd1307fb.c

> Personally I find the change unnecessary and pointless, which is why I
> didn't ack it. Even if function names were deemed important enough, keeping
> pwm_apply_state() for the time being and just adding pwm_apply_might_sleep()
> as duplicate would have done it, all the changes could have gone in long
> ago, and per-subsystem cleanup could have been orthogonal.

> I refrained from commenting because it might be considered bike shedding,
> but I don't want to ack something I deem unnecessary and pointless without
> comment. But then don't want to keep arguing either, so

I haven't been reading this series because I couldn't tell why I was
copied on it, it's only chance that made me open Guenter's mail here...

Acked-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/48819403/attachment.sig>

From linux at roeck-us.net  Tue Dec 12 07:27:57 2023
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 12 Dec 2023 07:27:57 -0800
Subject: [PATCH v2] watchdog: rti_wdt: Drop RPM count when unused
In-Reply-To: <20231122041642.2015936-1-vigneshr@ti.com>
References: <20231122041642.2015936-1-vigneshr@ti.com>
Message-ID: <98c12c55-1f9f-4529-ae34-cb9f22471dbe@roeck-us.net>

On 11/21/23 20:16, Vignesh Raghavendra wrote:
> Do a RPM put if watchdog is not already started during probe and re
> enable it in watchdog start.
> 
> On K3 SoCs, watchdogs and their corresponding CPUs are under same PD, so
> if the reference count of unused watchdogs aren't dropped, it will lead
> to CPU hotplug failures as Device Management firmware won't allow to
> turn off the PD due to dangling reference count.
> 
> Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support")
> Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>

I always find it amazing that people think everyone would understand the TLAs
(three-letter-acronyms) they use. While those who don't might find it confusing
why a watchdog driver would need or want to drop rotation-per-minute counts,
and what that has to do with police departments, that isn't worth
arguing about

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

Guenter



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:56 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:56 +0100
Subject: [PATCH v8 13/13] ARM: dts: stm32: put ETZPC as an access controller for STM32MP13x boards
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-14-gatien.chevallier@foss.st.com>

Reference ETZPC as an access-control-provider.

For more information on which peripheral is securable or supports MCU
isolation, please read the STM32MP13 reference manual

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Patch not present in V6

 arch/arm/boot/dts/st/stm32mp131.dtsi  | 26 ++++++++++++++++++++++++++
 arch/arm/boot/dts/st/stm32mp133.dtsi  |  1 +
 arch/arm/boot/dts/st/stm32mp13xc.dtsi |  1 +
 arch/arm/boot/dts/st/stm32mp13xf.dtsi |  1 +
 4 files changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
index 6ba8e3fd43b0..74ceece168ce 100644
--- a/arch/arm/boot/dts/st/stm32mp131.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
@@ -883,6 +883,7 @@ etzpc: bus at 5c007000 {
 			reg = <0x5c007000 0x400>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+			#access-controller-cells = <1>;
 			ranges;
 
 			adc_2: adc at 48004000 {
@@ -895,6 +896,7 @@ adc_2: adc at 48004000 {
 				#interrupt-cells = <1>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				access-controllers = <&etzpc 33>;
 				status = "disabled";
 
 				adc2: adc at 0 {
@@ -942,6 +944,7 @@ usbotg_hs: usb at 49000000 {
 				dr_mode = "otg";
 				otg-rev = <0x200>;
 				usb33d-supply = <&scmi_usb33>;
+				access-controllers = <&etzpc 34>;
 				status = "disabled";
 			};
 
@@ -955,6 +958,7 @@ usart1: serial at 4c000000 {
 				dmas = <&dmamux1 41 0x400 0x5>,
 				<&dmamux1 42 0x400 0x1>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 16>;
 				status = "disabled";
 			};
 
@@ -968,6 +972,7 @@ usart2: serial at 4c001000 {
 				dmas = <&dmamux1 43 0x400 0x5>,
 				<&dmamux1 44 0x400 0x1>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 17>;
 				status = "disabled";
 			};
 
@@ -979,6 +984,7 @@ i2s4: audio-controller at 4c002000 {
 				dmas = <&dmamux1 83 0x400 0x01>,
 				<&dmamux1 84 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 13>;
 				status = "disabled";
 			};
 
@@ -993,6 +999,7 @@ spi4: spi at 4c002000 {
 				dmas = <&dmamux1 83 0x400 0x01>,
 				       <&dmamux1 84 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 18>;
 				status = "disabled";
 			};
 
@@ -1007,6 +1014,7 @@ spi5: spi at 4c003000 {
 				dmas = <&dmamux1 85 0x400 0x01>,
 				       <&dmamux1 86 0x400 0x01>;
 				dma-names = "rx", "tx";
+				access-controllers = <&etzpc 19>;
 				status = "disabled";
 			};
 
@@ -1025,6 +1033,7 @@ i2c3: i2c at 4c004000 {
 				dma-names = "rx", "tx";
 				st,syscfg-fmp = <&syscfg 0x4 0x4>;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 20>;
 				status = "disabled";
 			};
 
@@ -1043,6 +1052,7 @@ i2c4: i2c at 4c005000 {
 				dma-names = "rx", "tx";
 				st,syscfg-fmp = <&syscfg 0x4 0x8>;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 21>;
 				status = "disabled";
 			};
 
@@ -1061,6 +1071,7 @@ i2c5: i2c at 4c006000 {
 				dma-names = "rx", "tx";
 				st,syscfg-fmp = <&syscfg 0x4 0x10>;
 				i2c-analog-filter;
+				access-controllers = <&etzpc 22>;
 				status = "disabled";
 			};
 
@@ -1073,6 +1084,7 @@ timers12: timer at 4c007000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM12_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 23>;
 				status = "disabled";
 
 				pwm {
@@ -1097,6 +1109,7 @@ timers13: timer at 4c008000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM13_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 24>;
 				status = "disabled";
 
 				pwm {
@@ -1121,6 +1134,7 @@ timers14: timer at 4c009000 {
 				interrupt-names = "global";
 				clocks = <&rcc TIM14_K>;
 				clock-names = "int";
+				access-controllers = <&etzpc 25>;
 				status = "disabled";
 
 				pwm {
@@ -1150,6 +1164,7 @@ timers15: timer at 4c00a000 {
 				<&dmamux1 107 0x400 0x1>,
 				<&dmamux1 108 0x400 0x1>;
 				dma-names = "ch1", "up", "trig", "com";
+				access-controllers = <&etzpc 26>;
 				status = "disabled";
 
 				pwm {
@@ -1177,6 +1192,7 @@ timers16: timer at 4c00b000 {
 				dmas = <&dmamux1 109 0x400 0x1>,
 				<&dmamux1 110 0x400 0x1>;
 				dma-names = "ch1", "up";
+				access-controllers = <&etzpc 27>;
 				status = "disabled";
 
 				pwm {
@@ -1204,6 +1220,7 @@ timers17: timer at 4c00c000 {
 				dmas = <&dmamux1 111 0x400 0x1>,
 				       <&dmamux1 112 0x400 0x1>;
 				dma-names = "ch1", "up";
+				access-controllers = <&etzpc 28>;
 				status = "disabled";
 
 				pwm {
@@ -1228,6 +1245,7 @@ lptimer2: timer at 50021000 {
 				clocks = <&rcc LPTIM2_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 1>;
 				status = "disabled";
 
 				pwm {
@@ -1262,6 +1280,7 @@ lptimer3: timer at 50022000 {
 				clocks = <&rcc LPTIM3_K>;
 				clock-names = "mux";
 				wakeup-source;
+				access-controllers = <&etzpc 2>;
 				status = "disabled";
 
 				pwm {
@@ -1290,6 +1309,7 @@ hash: hash at 54003000 {
 				resets = <&rcc HASH1_R>;
 				dmas = <&mdma 30 0x2 0x1000a02 0x0 0x0>;
 				dma-names = "in";
+				access-controllers = <&etzpc 41>;
 			};
 
 			rng: rng at 54004000 {
@@ -1297,6 +1317,7 @@ rng: rng at 54004000 {
 				reg = <0x54004000 0x400>;
 				clocks = <&rcc RNG1_K>;
 				resets = <&rcc RNG1_R>;
+				access-controllers = <&etzpc 40>;
 			};
 
 			fmc: memory-controller at 58002000 {
@@ -1311,6 +1332,7 @@ fmc: memory-controller at 58002000 {
 				#size-cells = <1>;
 				clocks = <&rcc FMC_K>;
 				resets = <&rcc FMC_R>;
+				access-controllers = <&etzpc 54>;
 				status = "disabled";
 
 				nand-controller at 4,0 {
@@ -1344,6 +1366,7 @@ qspi: spi at 58003000 {
 				dma-names = "tx", "rx";
 				clocks = <&rcc QSPI_K>;
 				resets = <&rcc QSPI_R>;
+				access-controllers = <&etzpc 55>;
 				status = "disabled";
 			};
 
@@ -1358,6 +1381,7 @@ sdmmc1: mmc at 58005000 {
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
 				max-frequency = <130000000>;
+				access-controllers = <&etzpc 50>;
 				status = "disabled";
 			};
 
@@ -1372,6 +1396,7 @@ sdmmc2: mmc at 58007000 {
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
 				max-frequency = <130000000>;
+				access-controllers = <&etzpc 51>;
 				status = "disabled";
 			};
 
@@ -1385,6 +1410,7 @@ usbphyc: usbphyc at 5a006000 {
 				resets = <&rcc USBPHY_R>;
 				vdda1v1-supply = <&scmi_reg11>;
 				vdda1v8-supply = <&scmi_reg18>;
+				access-controllers = <&etzpc 5>;
 				status = "disabled";
 
 				usbphyc_port0: usb-phy at 0 {
diff --git a/arch/arm/boot/dts/st/stm32mp133.dtsi b/arch/arm/boot/dts/st/stm32mp133.dtsi
index c4d3a520c14b..3e394c8e58b9 100644
--- a/arch/arm/boot/dts/st/stm32mp133.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp133.dtsi
@@ -47,6 +47,7 @@ adc_1: adc at 48003000 {
 		#interrupt-cells = <1>;
 		#address-cells = <1>;
 		#size-cells = <0>;
+		access-controllers = <&etzpc 32>;
 		status = "disabled";
 
 		adc1: adc at 0 {
diff --git a/arch/arm/boot/dts/st/stm32mp13xc.dtsi b/arch/arm/boot/dts/st/stm32mp13xc.dtsi
index b9fb071a1471..a8bd5fe6536c 100644
--- a/arch/arm/boot/dts/st/stm32mp13xc.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp13xc.dtsi
@@ -11,6 +11,7 @@ cryp: crypto at 54002000 {
 		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&rcc CRYP1>;
 		resets = <&rcc CRYP1_R>;
+		access-controllers = <&etzpc 42>;
 		status = "disabled";
 	};
 };
diff --git a/arch/arm/boot/dts/st/stm32mp13xf.dtsi b/arch/arm/boot/dts/st/stm32mp13xf.dtsi
index b9fb071a1471..a8bd5fe6536c 100644
--- a/arch/arm/boot/dts/st/stm32mp13xf.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp13xf.dtsi
@@ -11,6 +11,7 @@ cryp: crypto at 54002000 {
 		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&rcc CRYP1>;
 		resets = <&rcc CRYP1_R>;
+		access-controllers = <&etzpc 42>;
 		status = "disabled";
 	};
 };
-- 
2.25.1



From gatien.chevallier at foss.st.com  Tue Dec 12 07:23:55 2023
From: gatien.chevallier at foss.st.com (Gatien Chevallier)
Date: Tue, 12 Dec 2023 16:23:55 +0100
Subject: [PATCH v8 12/13] ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards
In-Reply-To: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
Message-ID: <20231212152356.345703-13-gatien.chevallier@foss.st.com>

ETZPC is a firewall controller. Put all peripherals filtered by the
ETZPC as ETZPC subnodes and keep the "simple-bus" compatible for
backward compatibility.

Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
---

Changes in V7:
    	- Keep simple-bus compatible
    	- Remove access-controllers reference in this patch

Changes in V6:
    	- Renamed access-controller to access-controllers
    	- Removal of access-control-provider property

Changes in V5:
    	- Renamed feature-domain* to access-control*

 arch/arm/boot/dts/st/stm32mp131.dtsi  | 1037 +++++++++++++------------
 arch/arm/boot/dts/st/stm32mp133.dtsi  |   50 +-
 arch/arm/boot/dts/st/stm32mp13xc.dtsi |   18 +-
 arch/arm/boot/dts/st/stm32mp13xf.dtsi |   18 +-
 4 files changed, 564 insertions(+), 559 deletions(-)

diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
index b04d24c939c3..6ba8e3fd43b0 100644
--- a/arch/arm/boot/dts/st/stm32mp131.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
@@ -745,340 +745,6 @@ dmamux1: dma-router at 48002000 {
 			dma-channels = <16>;
 		};
 
-		adc_2: adc at 48004000 {
-			compatible = "st,stm32mp13-adc-core";
-			reg = <0x48004000 0x400>;
-			interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc ADC2>, <&rcc ADC2_K>;
-			clock-names = "bus", "adc";
-			interrupt-controller;
-			#interrupt-cells = <1>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			status = "disabled";
-
-			adc2: adc at 0 {
-				compatible = "st,stm32mp13-adc";
-				#io-channel-cells = <1>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x0>;
-				interrupt-parent = <&adc_2>;
-				interrupts = <0>;
-				dmas = <&dmamux1 10 0x400 0x80000001>;
-				dma-names = "rx";
-				status = "disabled";
-
-				channel at 13 {
-					reg = <13>;
-					label = "vrefint";
-				};
-				channel at 14 {
-					reg = <14>;
-					label = "vddcore";
-				};
-				channel at 16 {
-					reg = <16>;
-					label = "vddcpu";
-				};
-				channel at 17 {
-					reg = <17>;
-					label = "vddq_ddr";
-				};
-			};
-		};
-
-		usbotg_hs: usb at 49000000 {
-			compatible = "st,stm32mp15-hsotg", "snps,dwc2";
-			reg = <0x49000000 0x40000>;
-			clocks = <&rcc USBO_K>;
-			clock-names = "otg";
-			resets = <&rcc USBO_R>;
-			reset-names = "dwc2";
-			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
-			g-rx-fifo-size = <512>;
-			g-np-tx-fifo-size = <32>;
-			g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
-			dr_mode = "otg";
-			otg-rev = <0x200>;
-			usb33d-supply = <&scmi_usb33>;
-			status = "disabled";
-		};
-
-		usart1: serial at 4c000000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x4c000000 0x400>;
-			interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART1_K>;
-			resets = <&rcc USART1_R>;
-			wakeup-source;
-			dmas = <&dmamux1 41 0x400 0x5>,
-			       <&dmamux1 42 0x400 0x1>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		usart2: serial at 4c001000 {
-			compatible = "st,stm32h7-uart";
-			reg = <0x4c001000 0x400>;
-			interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART2_K>;
-			resets = <&rcc USART2_R>;
-			wakeup-source;
-			dmas = <&dmamux1 43 0x400 0x5>,
-			       <&dmamux1 44 0x400 0x1>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		i2s4: audio-controller at 4c002000 {
-			compatible = "st,stm32h7-i2s";
-			reg = <0x4c002000 0x400>;
-			#sound-dai-cells = <0>;
-			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&dmamux1 83 0x400 0x01>,
-			       <&dmamux1 84 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		spi4: spi at 4c002000 {
-			compatible = "st,stm32h7-spi";
-			reg = <0x4c002000 0x400>;
-			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI4_K>;
-			resets = <&rcc SPI4_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 83 0x400 0x01>,
-			       <&dmamux1 84 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		spi5: spi at 4c003000 {
-			compatible = "st,stm32h7-spi";
-			reg = <0x4c003000 0x400>;
-			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI5_K>;
-			resets = <&rcc SPI5_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 85 0x400 0x01>,
-			       <&dmamux1 86 0x400 0x01>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		i2c3: i2c at 4c004000 {
-			compatible = "st,stm32mp13-i2c";
-			reg = <0x4c004000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C3_K>;
-			resets = <&rcc I2C3_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 73 0x400 0x1>,
-			       <&dmamux1 74 0x400 0x1>;
-			dma-names = "rx", "tx";
-			st,syscfg-fmp = <&syscfg 0x4 0x4>;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
-		i2c4: i2c at 4c005000 {
-			compatible = "st,stm32mp13-i2c";
-			reg = <0x4c005000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C4_K>;
-			resets = <&rcc I2C4_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 75 0x400 0x1>,
-			       <&dmamux1 76 0x400 0x1>;
-			dma-names = "rx", "tx";
-			st,syscfg-fmp = <&syscfg 0x4 0x8>;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
-		i2c5: i2c at 4c006000 {
-			compatible = "st,stm32mp13-i2c";
-			reg = <0x4c006000 0x400>;
-			interrupt-names = "event", "error";
-			interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C5_K>;
-			resets = <&rcc I2C5_R>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			dmas = <&dmamux1 115 0x400 0x1>,
-			       <&dmamux1 116 0x400 0x1>;
-			dma-names = "rx", "tx";
-			st,syscfg-fmp = <&syscfg 0x4 0x10>;
-			i2c-analog-filter;
-			status = "disabled";
-		};
-
-		timers12: timer at 4c007000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c007000 0x400>;
-			interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM12_K>;
-			clock-names = "int";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 11 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <11>;
-				status = "disabled";
-			};
-		};
-
-		timers13: timer at 4c008000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c008000 0x400>;
-			interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM13_K>;
-			clock-names = "int";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 12 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <12>;
-				status = "disabled";
-			};
-		};
-
-		timers14: timer at 4c009000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c009000 0x400>;
-			interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM14_K>;
-			clock-names = "int";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 13 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <13>;
-				status = "disabled";
-			};
-		};
-
-		timers15: timer at 4c00a000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c00a000 0x400>;
-			interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM15_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 105 0x400 0x1>,
-			       <&dmamux1 106 0x400 0x1>,
-			       <&dmamux1 107 0x400 0x1>,
-			       <&dmamux1 108 0x400 0x1>;
-			dma-names = "ch1", "up", "trig", "com";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 14 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <14>;
-				status = "disabled";
-			};
-		};
-
-		timers16: timer at 4c00b000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c00b000 0x400>;
-			interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM16_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 109 0x400 0x1>,
-			       <&dmamux1 110 0x400 0x1>;
-			dma-names = "ch1", "up";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 15 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <15>;
-				status = "disabled";
-			};
-		};
-
-		timers17: timer at 4c00c000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-timers";
-			reg = <0x4c00c000 0x400>;
-			interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "global";
-			clocks = <&rcc TIM17_K>;
-			clock-names = "int";
-			dmas = <&dmamux1 111 0x400 0x1>,
-			       <&dmamux1 112 0x400 0x1>;
-			dma-names = "ch1", "up";
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			timer at 16 {
-				compatible = "st,stm32h7-timer-trigger";
-				reg = <16>;
-				status = "disabled";
-			};
-		};
-
 		rcc: rcc at 50000000 {
 			compatible = "st,stm32mp13-rcc", "syscon";
 			reg = <0x50000000 0x1000>;
@@ -1105,69 +771,6 @@ syscfg: syscon at 50020000 {
 			clocks = <&rcc SYSCFG>;
 		};
 
-		lptimer2: timer at 50021000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x50021000 0x400>;
-			interrupts-extended = <&exti 48 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM2_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			trigger at 1 {
-				compatible = "st,stm32-lptimer-trigger";
-				reg = <1>;
-				status = "disabled";
-			};
-
-			counter {
-				compatible = "st,stm32-lptimer-counter";
-				status = "disabled";
-			};
-
-			timer {
-				compatible = "st,stm32-lptimer-timer";
-				status = "disabled";
-			};
-		};
-
-		lptimer3: timer at 50022000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			compatible = "st,stm32-lptimer";
-			reg = <0x50022000 0x400>;
-			interrupts-extended = <&exti 50 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc LPTIM3_K>;
-			clock-names = "mux";
-			wakeup-source;
-			status = "disabled";
-
-			pwm {
-				compatible = "st,stm32-pwm-lp";
-				#pwm-cells = <3>;
-				status = "disabled";
-			};
-
-			trigger at 2 {
-				compatible = "st,stm32-lptimer-trigger";
-				reg = <2>;
-				status = "disabled";
-			};
-
-			timer {
-				compatible = "st,stm32-lptimer-timer";
-				status = "disabled";
-			};
-		};
-
 		lptimer4: timer at 50023000 {
 			compatible = "st,stm32-lptimer";
 			reg = <0x50023000 0x400>;
@@ -1210,25 +813,6 @@ timer {
 			};
 		};
 
-		hash: hash at 54003000 {
-			compatible = "st,stm32mp13-hash";
-			reg = <0x54003000 0x400>;
-			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc HASH1>;
-			resets = <&rcc HASH1_R>;
-			dmas = <&mdma 30 0x2 0x1000a02 0x0 0x0>;
-			dma-names = "in";
-			status = "disabled";
-		};
-
-		rng: rng at 54004000 {
-			compatible = "st,stm32mp13-rng";
-			reg = <0x54004000 0x400>;
-			clocks = <&rcc RNG1_K>;
-			resets = <&rcc RNG1_R>;
-			status = "disabled";
-		};
-
 		mdma: dma-controller at 58000000 {
 			compatible = "st,stm32h7-mdma";
 			reg = <0x58000000 0x1000>;
@@ -1239,82 +823,6 @@ mdma: dma-controller at 58000000 {
 			dma-requests = <48>;
 		};
 
-		fmc: memory-controller at 58002000 {
-			compatible = "st,stm32mp1-fmc2-ebi";
-			reg = <0x58002000 0x1000>;
-			ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
-				 <1 0 0x64000000 0x04000000>, /* EBI CS 2 */
-				 <2 0 0x68000000 0x04000000>, /* EBI CS 3 */
-				 <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */
-				 <4 0 0x80000000 0x10000000>; /* NAND */
-			#address-cells = <2>;
-			#size-cells = <1>;
-			clocks = <&rcc FMC_K>;
-			resets = <&rcc FMC_R>;
-			status = "disabled";
-
-			nand-controller at 4,0 {
-				compatible = "st,stm32mp1-fmc2-nfc";
-				reg = <4 0x00000000 0x1000>,
-				      <4 0x08010000 0x1000>,
-				      <4 0x08020000 0x1000>,
-				      <4 0x01000000 0x1000>,
-				      <4 0x09010000 0x1000>,
-				      <4 0x09020000 0x1000>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
-				dmas = <&mdma 24 0x2 0x12000a02 0x0 0x0>,
-				       <&mdma 24 0x2 0x12000a08 0x0 0x0>,
-				       <&mdma 25 0x2 0x12000a0a 0x0 0x0>;
-				dma-names = "tx", "rx", "ecc";
-				status = "disabled";
-			};
-		};
-
-		qspi: spi at 58003000 {
-			compatible = "st,stm32f469-qspi";
-			reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
-			reg-names = "qspi", "qspi_mm";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&mdma 26 0x2 0x10100002 0x0 0x0>,
-			       <&mdma 26 0x2 0x10100008 0x0 0x0>;
-			dma-names = "tx", "rx";
-			clocks = <&rcc QSPI_K>;
-			resets = <&rcc QSPI_R>;
-			status = "disabled";
-		};
-
-		sdmmc1: mmc at 58005000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x20253180>;
-			reg = <0x58005000 0x1000>, <0x58006000 0x1000>;
-			interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC1_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC1_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <130000000>;
-			status = "disabled";
-		};
-
-		sdmmc2: mmc at 58007000 {
-			compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
-			arm,primecell-periphid = <0x20253180>;
-			reg = <0x58007000 0x1000>, <0x58008000 0x1000>;
-			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SDMMC2_K>;
-			clock-names = "apb_pclk";
-			resets = <&rcc SDMMC2_R>;
-			cap-sd-highspeed;
-			cap-mmc-highspeed;
-			max-frequency = <130000000>;
-			status = "disabled";
-		};
-
 		usbh_ohci: usb at 5800c000 {
 			compatible = "generic-ohci";
 			reg = <0x5800c000 0x1000>;
@@ -1342,29 +850,6 @@ iwdg2: watchdog at 5a002000 {
 			status = "disabled";
 		};
 
-		usbphyc: usbphyc at 5a006000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			#clock-cells = <0>;
-			compatible = "st,stm32mp1-usbphyc";
-			reg = <0x5a006000 0x1000>;
-			clocks = <&rcc USBPHY_K>;
-			resets = <&rcc USBPHY_R>;
-			vdda1v1-supply = <&scmi_reg11>;
-			vdda1v8-supply = <&scmi_reg18>;
-			status = "disabled";
-
-			usbphyc_port0: usb-phy at 0 {
-				#phy-cells = <0>;
-				reg = <0>;
-			};
-
-			usbphyc_port1: usb-phy at 1 {
-				#phy-cells = <1>;
-				reg = <1>;
-			};
-		};
-
 		rtc: rtc at 5c004000 {
 			compatible = "st,stm32mp1-rtc";
 			reg = <0x5c004000 0x400>;
@@ -1393,6 +878,527 @@ ts_cal2: calib at 5e {
 			};
 		};
 
+		etzpc: bus at 5c007000 {
+			compatible = "st,stm32-etzpc", "simple-bus";
+			reg = <0x5c007000 0x400>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			adc_2: adc at 48004000 {
+				compatible = "st,stm32mp13-adc-core";
+				reg = <0x48004000 0x400>;
+				interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc ADC2>, <&rcc ADC2_K>;
+				clock-names = "bus", "adc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+
+				adc2: adc at 0 {
+					compatible = "st,stm32mp13-adc";
+					#io-channel-cells = <1>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x0>;
+					interrupt-parent = <&adc_2>;
+					interrupts = <0>;
+					dmas = <&dmamux1 10 0x400 0x80000001>;
+					dma-names = "rx";
+					status = "disabled";
+
+					channel at 13 {
+						reg = <13>;
+						label = "vrefint";
+					};
+					channel at 14 {
+						reg = <14>;
+						label = "vddcore";
+					};
+					channel at 16 {
+						reg = <16>;
+						label = "vddcpu";
+					};
+					channel at 17 {
+						reg = <17>;
+						label = "vddq_ddr";
+					};
+				};
+			};
+
+			usbotg_hs: usb at 49000000 {
+				compatible = "st,stm32mp15-hsotg", "snps,dwc2";
+				reg = <0x49000000 0x40000>;
+				clocks = <&rcc USBO_K>;
+				clock-names = "otg";
+				resets = <&rcc USBO_R>;
+				reset-names = "dwc2";
+				interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+				g-rx-fifo-size = <512>;
+				g-np-tx-fifo-size = <32>;
+				g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
+				dr_mode = "otg";
+				otg-rev = <0x200>;
+				usb33d-supply = <&scmi_usb33>;
+				status = "disabled";
+			};
+
+			usart1: serial at 4c000000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x4c000000 0x400>;
+				interrupts-extended = <&exti 26 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART1_K>;
+				resets = <&rcc USART1_R>;
+				wakeup-source;
+				dmas = <&dmamux1 41 0x400 0x5>,
+				<&dmamux1 42 0x400 0x1>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			usart2: serial at 4c001000 {
+				compatible = "st,stm32h7-uart";
+				reg = <0x4c001000 0x400>;
+				interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc USART2_K>;
+				resets = <&rcc USART2_R>;
+				wakeup-source;
+				dmas = <&dmamux1 43 0x400 0x5>,
+				<&dmamux1 44 0x400 0x1>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			i2s4: audio-controller at 4c002000 {
+				compatible = "st,stm32h7-i2s";
+				reg = <0x4c002000 0x400>;
+				#sound-dai-cells = <0>;
+				interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&dmamux1 83 0x400 0x01>,
+				<&dmamux1 84 0x400 0x01>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			spi4: spi at 4c002000 {
+				compatible = "st,stm32h7-spi";
+				reg = <0x4c002000 0x400>;
+				interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI4_K>;
+				resets = <&rcc SPI4_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 83 0x400 0x01>,
+				       <&dmamux1 84 0x400 0x01>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			spi5: spi at 4c003000 {
+				compatible = "st,stm32h7-spi";
+				reg = <0x4c003000 0x400>;
+				interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SPI5_K>;
+				resets = <&rcc SPI5_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 85 0x400 0x01>,
+				       <&dmamux1 86 0x400 0x01>;
+				dma-names = "rx", "tx";
+				status = "disabled";
+			};
+
+			i2c3: i2c at 4c004000 {
+				compatible = "st,stm32mp13-i2c";
+				reg = <0x4c004000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C3_K>;
+				resets = <&rcc I2C3_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 73 0x400 0x1>,
+				       <&dmamux1 74 0x400 0x1>;
+				dma-names = "rx", "tx";
+				st,syscfg-fmp = <&syscfg 0x4 0x4>;
+				i2c-analog-filter;
+				status = "disabled";
+			};
+
+			i2c4: i2c at 4c005000 {
+				compatible = "st,stm32mp13-i2c";
+				reg = <0x4c005000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C4_K>;
+				resets = <&rcc I2C4_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 75 0x400 0x1>,
+				       <&dmamux1 76 0x400 0x1>;
+				dma-names = "rx", "tx";
+				st,syscfg-fmp = <&syscfg 0x4 0x8>;
+				i2c-analog-filter;
+				status = "disabled";
+			};
+
+			i2c5: i2c at 4c006000 {
+				compatible = "st,stm32mp13-i2c";
+				reg = <0x4c006000 0x400>;
+				interrupt-names = "event", "error";
+				interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc I2C5_K>;
+				resets = <&rcc I2C5_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				dmas = <&dmamux1 115 0x400 0x1>,
+				       <&dmamux1 116 0x400 0x1>;
+				dma-names = "rx", "tx";
+				st,syscfg-fmp = <&syscfg 0x4 0x10>;
+				i2c-analog-filter;
+				status = "disabled";
+			};
+
+			timers12: timer at 4c007000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c007000 0x400>;
+				interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM12_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 11 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <11>;
+					status = "disabled";
+				};
+			};
+
+			timers13: timer at 4c008000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c008000 0x400>;
+				interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM13_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 12 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <12>;
+					status = "disabled";
+				};
+			};
+
+			timers14: timer at 4c009000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c009000 0x400>;
+				interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM14_K>;
+				clock-names = "int";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 13 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <13>;
+					status = "disabled";
+				};
+			};
+
+			timers15: timer at 4c00a000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c00a000 0x400>;
+				interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM15_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 105 0x400 0x1>,
+				<&dmamux1 106 0x400 0x1>,
+				<&dmamux1 107 0x400 0x1>,
+				<&dmamux1 108 0x400 0x1>;
+				dma-names = "ch1", "up", "trig", "com";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 14 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <14>;
+					status = "disabled";
+				};
+			};
+
+			timers16: timer at 4c00b000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c00b000 0x400>;
+				interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM16_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 109 0x400 0x1>,
+				<&dmamux1 110 0x400 0x1>;
+				dma-names = "ch1", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 15 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <15>;
+					status = "disabled";
+				};
+			};
+
+			timers17: timer at 4c00c000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-timers";
+				reg = <0x4c00c000 0x400>;
+				interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "global";
+				clocks = <&rcc TIM17_K>;
+				clock-names = "int";
+				dmas = <&dmamux1 111 0x400 0x1>,
+				       <&dmamux1 112 0x400 0x1>;
+				dma-names = "ch1", "up";
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				timer at 16 {
+					compatible = "st,stm32h7-timer-trigger";
+					reg = <16>;
+					status = "disabled";
+				};
+			};
+
+			lptimer2: timer at 50021000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x50021000 0x400>;
+				interrupts-extended = <&exti 48 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM2_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				trigger at 1 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <1>;
+					status = "disabled";
+				};
+
+				counter {
+					compatible = "st,stm32-lptimer-counter";
+					status = "disabled";
+				};
+
+				timer {
+					compatible = "st,stm32-lptimer-timer";
+					status = "disabled";
+				};
+			};
+
+			lptimer3: timer at 50022000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32-lptimer";
+				reg = <0x50022000 0x400>;
+				interrupts-extended = <&exti 50 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc LPTIM3_K>;
+				clock-names = "mux";
+				wakeup-source;
+				status = "disabled";
+
+				pwm {
+					compatible = "st,stm32-pwm-lp";
+					#pwm-cells = <3>;
+					status = "disabled";
+				};
+
+				trigger at 2 {
+					compatible = "st,stm32-lptimer-trigger";
+					reg = <2>;
+					status = "disabled";
+				};
+
+				timer {
+					compatible = "st,stm32-lptimer-timer";
+					status = "disabled";
+				};
+			};
+
+			hash: hash at 54003000 {
+				compatible = "st,stm32mp13-hash";
+				reg = <0x54003000 0x400>;
+				interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc HASH1>;
+				resets = <&rcc HASH1_R>;
+				dmas = <&mdma 30 0x2 0x1000a02 0x0 0x0>;
+				dma-names = "in";
+			};
+
+			rng: rng at 54004000 {
+				compatible = "st,stm32mp13-rng";
+				reg = <0x54004000 0x400>;
+				clocks = <&rcc RNG1_K>;
+				resets = <&rcc RNG1_R>;
+			};
+
+			fmc: memory-controller at 58002000 {
+				compatible = "st,stm32mp1-fmc2-ebi";
+				reg = <0x58002000 0x1000>;
+				ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
+					 <1 0 0x64000000 0x04000000>, /* EBI CS 2 */
+					 <2 0 0x68000000 0x04000000>, /* EBI CS 3 */
+					 <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */
+					 <4 0 0x80000000 0x10000000>; /* NAND */
+				#address-cells = <2>;
+				#size-cells = <1>;
+				clocks = <&rcc FMC_K>;
+				resets = <&rcc FMC_R>;
+				status = "disabled";
+
+				nand-controller at 4,0 {
+					compatible = "st,stm32mp1-fmc2-nfc";
+					reg = <4 0x00000000 0x1000>,
+					      <4 0x08010000 0x1000>,
+					      <4 0x08020000 0x1000>,
+					      <4 0x01000000 0x1000>,
+					      <4 0x09010000 0x1000>,
+					      <4 0x09020000 0x1000>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+					dmas = <&mdma 24 0x2 0x12000a02 0x0 0x0>,
+					       <&mdma 24 0x2 0x12000a08 0x0 0x0>,
+					       <&mdma 25 0x2 0x12000a0a 0x0 0x0>;
+					dma-names = "tx", "rx", "ecc";
+					status = "disabled";
+				};
+			};
+
+			qspi: spi at 58003000 {
+				compatible = "st,stm32f469-qspi";
+				reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
+				reg-names = "qspi", "qspi_mm";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&mdma 26 0x2 0x10100002 0x0 0x0>,
+				       <&mdma 26 0x2 0x10100008 0x0 0x0>;
+				dma-names = "tx", "rx";
+				clocks = <&rcc QSPI_K>;
+				resets = <&rcc QSPI_R>;
+				status = "disabled";
+			};
+
+			sdmmc1: mmc at 58005000 {
+				compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+				arm,primecell-periphid = <0x20253180>;
+				reg = <0x58005000 0x1000>, <0x58006000 0x1000>;
+				interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SDMMC1_K>;
+				clock-names = "apb_pclk";
+				resets = <&rcc SDMMC1_R>;
+				cap-sd-highspeed;
+				cap-mmc-highspeed;
+				max-frequency = <130000000>;
+				status = "disabled";
+			};
+
+			sdmmc2: mmc at 58007000 {
+				compatible = "st,stm32-sdmmc2", "arm,pl18x", "arm,primecell";
+				arm,primecell-periphid = <0x20253180>;
+				reg = <0x58007000 0x1000>, <0x58008000 0x1000>;
+				interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc SDMMC2_K>;
+				clock-names = "apb_pclk";
+				resets = <&rcc SDMMC2_R>;
+				cap-sd-highspeed;
+				cap-mmc-highspeed;
+				max-frequency = <130000000>;
+				status = "disabled";
+			};
+
+			usbphyc: usbphyc at 5a006000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				#clock-cells = <0>;
+				compatible = "st,stm32mp1-usbphyc";
+				reg = <0x5a006000 0x1000>;
+				clocks = <&rcc USBPHY_K>;
+				resets = <&rcc USBPHY_R>;
+				vdda1v1-supply = <&scmi_reg11>;
+				vdda1v8-supply = <&scmi_reg18>;
+				status = "disabled";
+
+				usbphyc_port0: usb-phy at 0 {
+					#phy-cells = <0>;
+					reg = <0>;
+				};
+
+				usbphyc_port1: usb-phy at 1 {
+					#phy-cells = <1>;
+					reg = <1>;
+				};
+			};
+		};
+
 		/*
 		 * Break node order to solve dependency probe issue between
 		 * pinctrl and exti.
@@ -1404,6 +1410,7 @@ pinctrl: pinctrl at 50002000 {
 			ranges = <0 0x50002000 0x8400>;
 			interrupt-parent = <&exti>;
 			st,syscfg = <&exti 0x60 0xff>;
+			pins-are-numbered;
 
 			gpioa: gpio at 50002000 {
 				gpio-controller;
diff --git a/arch/arm/boot/dts/st/stm32mp133.dtsi b/arch/arm/boot/dts/st/stm32mp133.dtsi
index df451c3c2a26..c4d3a520c14b 100644
--- a/arch/arm/boot/dts/st/stm32mp133.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp133.dtsi
@@ -33,35 +33,37 @@ m_can2: can at 4400f000 {
 			bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
 			status = "disabled";
 		};
+	};
+};
 
-		adc_1: adc at 48003000 {
-			compatible = "st,stm32mp13-adc-core";
-			reg = <0x48003000 0x400>;
-			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc ADC1>, <&rcc ADC1_K>;
-			clock-names = "bus", "adc";
-			interrupt-controller;
-			#interrupt-cells = <1>;
+&etzpc {
+	adc_1: adc at 48003000 {
+		compatible = "st,stm32mp13-adc-core";
+		reg = <0x48003000 0x400>;
+		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&rcc ADC1>, <&rcc ADC1_K>;
+		clock-names = "bus", "adc";
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+
+		adc1: adc at 0 {
+			compatible = "st,stm32mp13-adc";
+			#io-channel-cells = <1>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+			reg = <0x0>;
+			interrupt-parent = <&adc_1>;
+			interrupts = <0>;
+			dmas = <&dmamux1 9 0x400 0x80000001>;
+			dma-names = "rx";
 			status = "disabled";
 
-			adc1: adc at 0 {
-				compatible = "st,stm32mp13-adc";
-				#io-channel-cells = <1>;
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x0>;
-				interrupt-parent = <&adc_1>;
-				interrupts = <0>;
-				dmas = <&dmamux1 9 0x400 0x80000001>;
-				dma-names = "rx";
-				status = "disabled";
-
-				channel at 18 {
-					reg = <18>;
-					label = "vrefint";
-				};
+			channel at 18 {
+				reg = <18>;
+				label = "vrefint";
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/st/stm32mp13xc.dtsi b/arch/arm/boot/dts/st/stm32mp13xc.dtsi
index 4d00e7592882..b9fb071a1471 100644
--- a/arch/arm/boot/dts/st/stm32mp13xc.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp13xc.dtsi
@@ -4,15 +4,13 @@
  * Author: Alexandre Torgue <alexandre.torgue at foss.st.com> for STMicroelectronics.
  */
 
-/ {
-	soc {
-		cryp: crypto at 54002000 {
-			compatible = "st,stm32mp1-cryp";
-			reg = <0x54002000 0x400>;
-			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CRYP1>;
-			resets = <&rcc CRYP1_R>;
-			status = "disabled";
-		};
+&etzpc {
+	cryp: crypto at 54002000 {
+		compatible = "st,stm32mp1-cryp";
+		reg = <0x54002000 0x400>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&rcc CRYP1>;
+		resets = <&rcc CRYP1_R>;
+		status = "disabled";
 	};
 };
diff --git a/arch/arm/boot/dts/st/stm32mp13xf.dtsi b/arch/arm/boot/dts/st/stm32mp13xf.dtsi
index 4d00e7592882..b9fb071a1471 100644
--- a/arch/arm/boot/dts/st/stm32mp13xf.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp13xf.dtsi
@@ -4,15 +4,13 @@
  * Author: Alexandre Torgue <alexandre.torgue at foss.st.com> for STMicroelectronics.
  */
 
-/ {
-	soc {
-		cryp: crypto at 54002000 {
-			compatible = "st,stm32mp1-cryp";
-			reg = <0x54002000 0x400>;
-			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CRYP1>;
-			resets = <&rcc CRYP1_R>;
-			status = "disabled";
-		};
+&etzpc {
+	cryp: crypto at 54002000 {
+		compatible = "st,stm32mp1-cryp";
+		reg = <0x54002000 0x400>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&rcc CRYP1>;
+		resets = <&rcc CRYP1_R>;
+		status = "disabled";
 	};
 };
-- 
2.25.1



From seanjc at google.com  Tue Dec 12 07:28:54 2023
From: seanjc at google.com (Sean Christopherson)
Date: Tue, 12 Dec 2023 07:28:54 -0800
Subject: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()
In-Reply-To: <CALMp9eTT97oDmQT7pxeOMLQbt-371aMtC2Kev+-kWXVRDVrjeg@mail.gmail.com>
References: <20220921003201.1441511-11-seanjc@google.com> <20231207010302.2240506-1-jmattson@google.com>
 <ZXHw7tykubfG04Um@google.com> <CALMp9eTT97oDmQT7pxeOMLQbt-371aMtC2Kev+-kWXVRDVrjeg@mail.gmail.com>
Message-ID: <ZXh8Nq_y_szj1WN0@google.com>

On Sun, Dec 10, 2023, Jim Mattson wrote:
> On Thu, Dec 7, 2023 at 8:21?AM Sean Christopherson <seanjc at google.com> wrote:
> > Doh.  We got the less obvious cases and missed the obvious one.
> >
> > Ugh, and we also missed a related mess in kvm_guest_apic_has_interrupt().  That
> > thing should really be folded into vmx_has_nested_events().
> >
> > Good gravy.  And vmx_interrupt_blocked() does the wrong thing because that
> > specifically checks if L1 interrupts are blocked.
> >
> > Compile tested only, and definitely needs to be chunked into multiple patches,
> > but I think something like this mess?
> 
> The proposed patch does not fix the problem. In fact, it messes things
> up so much that I don't get any test results back.

Drat.

> Google has an internal K-U-T test that demonstrates the problem. I
> will post it soon.

Received, I'll dig in soonish, though "soonish" might unfortunately might mean
2024.


From ryan.roberts at arm.com  Tue Dec 12 07:32:29 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 12 Dec 2023 15:32:29 +0000
Subject: [PATCH v9 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <ff7a3e9c-53cb-4283-9298-781d4fb7c7f8@redhat.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207161211.2374093-4-ryan.roberts@arm.com>
 <ff7a3e9c-53cb-4283-9298-781d4fb7c7f8@redhat.com>
Message-ID: <e424982c-8a2f-4c98-83aa-fdb0ee765776@arm.com>

On 12/12/2023 14:54, David Hildenbrand wrote:
> On 07.12.23 17:12, Ryan Roberts wrote:
>> In preparation for adding support for anonymous multi-size THP,
>> introduce new sysfs structure that will be used to control the new
>> behaviours. A new directory is added under transparent_hugepage for each
>> supported THP size, and contains an `enabled` file, which can be set to
>> "inherit" (to inherit the global setting), "always", "madvise" or
>> "never". For now, the kernel still only supports PMD-sized anonymous
>> THP, so only 1 directory is populated.
>>
>> The first half of the change converts transhuge_vma_suitable() and
>> hugepage_vma_check() so that they take a bitfield of orders for which
>> the user wants to determine support, and the functions filter out all
>> the orders that can't be supported, given the current sysfs
>> configuration and the VMA dimensions. The resulting functions are
>> renamed to thp_vma_suitable_orders() and thp_vma_allowable_orders()
>> respectively. Convenience functions that take a single, unencoded order
>> and return a boolean are also defined as thp_vma_suitable_order() and
>> thp_vma_allowable_order().
>>
>> The second half of the change implements the new sysfs interface. It has
>> been done so that each supported THP size has a `struct thpsize`, which
>> describes the relevant metadata and is itself a kobject. This is pretty
>> minimal for now, but should make it easy to add new per-thpsize files to
>> the interface if needed in future (e.g. per-size defrag). Rather than
>> keep the `enabled` state directly in the struct thpsize, I've elected to
>> directly encode it into huge_anon_orders_[always|madvise|inherit]
>> bitfields since this reduces the amount of work required in
>> thp_vma_allowable_orders() which is called for every page fault.
>>
>> See Documentation/admin-guide/mm/transhuge.rst, as modified by this
>> commit, for details of how the new sysfs interface works.
>>
>> Reviewed-by: Barry Song <v-songbaohua at oppo.com>
>> Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
> 
> [...]
> 
>> +
>> +static ssize_t thpsize_enabled_store(struct kobject *kobj,
>> +???????????????????? struct kobj_attribute *attr,
>> +???????????????????? const char *buf, size_t count)
>> +{
>> +??? int order = to_thpsize(kobj)->order;
>> +??? ssize_t ret = count;
>> +
>> +??? if (sysfs_streq(buf, "always")) {
>> +??????? spin_lock(&huge_anon_orders_lock);
>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>> +??????? set_bit(order, &huge_anon_orders_always);
>> +??????? spin_unlock(&huge_anon_orders_lock);
>> +??? } else if (sysfs_streq(buf, "inherit")) {
>> +??????? spin_lock(&huge_anon_orders_lock);
>> +??????? clear_bit(order, &huge_anon_orders_always);
>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>> +??????? set_bit(order, &huge_anon_orders_inherit);
>> +??????? spin_unlock(&huge_anon_orders_lock);
>> +??? } else if (sysfs_streq(buf, "madvise")) {
>> +??????? spin_lock(&huge_anon_orders_lock);
>> +??????? clear_bit(order, &huge_anon_orders_always);
>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>> +??????? set_bit(order, &huge_anon_orders_madvise);
>> +??????? spin_unlock(&huge_anon_orders_lock);
>> +??? } else if (sysfs_streq(buf, "never")) {
>> +??????? spin_lock(&huge_anon_orders_lock);
>> +??????? clear_bit(order, &huge_anon_orders_always);
>> +??????? clear_bit(order, &huge_anon_orders_inherit);
>> +??????? clear_bit(order, &huge_anon_orders_madvise);
>> +??????? spin_unlock(&huge_anon_orders_lock);
> 
> Why not perform lock/unlock only once in surrounding code? :)

I was nervous that sysfs_streq() may be unhappy in atomic context... Unfounded?

> 
> 
> Much better
> 
> Acked-by: David Hildenbrand <david at redhat.com>
> 



From ben.wolsieffer at hefring.com  Tue Dec 12 07:35:08 2023
From: ben.wolsieffer at hefring.com (Ben Wolsieffer)
Date: Tue, 12 Dec 2023 10:35:08 -0500
Subject: [PATCH 2/2] pinctrl: stm32: fix GPIO level interrupts
In-Reply-To: <87ttosqvbq.ffs@tglx>
References: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>
 <20231204203357.2897008-3-ben.wolsieffer@hefring.com>
 <87ttosqvbq.ffs@tglx>
Message-ID: <ZXh9rIyy6mu9zFry@dell-precision-5540>

Thank you for taking the time to look through the STM32 manual and
review the driver. Unfortunately, I don't have enough experience with
the Linux IRQ subsystem to give you a correspondingly in depth response,
but I will attempt to address the parts that relate to the bug in
question.

On Fri, Dec 08, 2023 at 09:43:21PM +0100, Thomas Gleixner wrote:
> Ben!
> 
> On Mon, Dec 04 2023 at 15:33, Ben Wolsieffer wrote:
> > The STM32 doesn't support GPIO level interrupts in hardware, so the
> > driver tries to emulate them using edge interrupts, by retriggering the
> > interrupt if necessary based on the pin state after the handler
> > finishes.
> >
> > Currently, this functionality does not work because the irqchip uses
> > handle_edge_irq(), which doesn't run the irq_eoi() or irq_unmask()
> > callbacks after handling the interrupt. This patch fixes this by using
> > handle_level_irq() for level interrupts, which causes irq_unmask() to be
> > called to retrigger the interrupt.
> 
> This does not make any sense at all. irq_unmask() does not retrigger
> anything. It sets the corresponding bit in the mask register, not more
> not less.

I don't think this is correct. I was referring to
stm32_gpio_irq_unmask(), which calls stm32_gpio_irq_trigger(), which in
turn (for level interrupts) checks the GPIO pin state and retriggers the
interrupt if necessary.

> 
> Switching to handle_level_irq() makes the following difference
> vs. handle_edge_irq() when an interrupt is handled (ignoring the inner
> loop):
> 
>       + irq_mask();
>         irq_ack();
>         ....
>         handle();
>         ....
>       + irq_unmask();

Yes, the additional call to irq_unmask() is the key difference here, as
that callback performs the retriggering for level interrupts.

> 
> So in both cases irq_ack() clears the interrupt in the Pending register,
> right?
> 
> Now comes the interesting difference.
> 
> When the interrupt is raised again after irq_ack() while the handler is
> running, i.e. a full toggle from active to inactive and back to active
> where the back to active transition causes the edge detector to trigger,
> then:

I don't see how this is relevant. The bug occurs with level interrupts
in the case where there are no new transitions while the handler is
running. For example, with a high level interrupt, if the pin is still
high after the handler finishes, the interrupt should be immediately
triggered again.

> 
>   1) in case of handle_edge_irq() this should immediately set it in the
>      pending register again and raise another CPU interrupt, which
>      should be handled once the interrupt service routine returned.
> 
>   2) in case of handle_level_irq() this does not set it in the pending
>      register because it's masked. The unmask will set the pending
>      register bit _if_ and only _if_ the edge detector has latched the
>      detection. No idea whether that's the case. The manual is
>      exceptionally blury about this.
> 
> So in theory both #1 and #2 should work. But the explanation in the
> changelog is fairy tale material.
> 
> As I couldn't figure out why #1 would not work, I looked at the driver
> in more detail and also at the STM32 manual. That tells me that the
> irqchip driver is at least suboptimal. Why?
> 
> The EXTI controller is just an intermediate between the peripheral
> (including GPIO pins) and the NVIC:
> 
>          |--------------|
>          | Edge config  |   |-----------------|
>  Source -|              |---| Int. Mask logic |---> Dedicated NVIC interrupt
>          | Edge detect  | | |-----------------|
>          |--------------| |
>                           | |-----------------|   
>                           |-| Evt. Mask logic |---> CPU event input
>                           | |-----------------|   
>                           |
>                           | |-----------------|   
>                           |-| Wakeup logic    |--->....
>                             |-----------------|   
> 
> So there are two classes of sources conntect to EXTI:
> 
>    1) Direct events
> 
>       - Have a fixed edge
>       - Can be masked for Interrupt and Event generation
>       - No software trigger
>       - Not tracked in the Pending register
>       - Can evtl. wakeup the CPUs or from D3
> 
>    2) Configurable events
> 
>       - Have a configurable edge
>       - Can be masked for Interrupt and Event generation
>       - Software trigger
>       - Tracked in the Pending register
>       - Can evtl. wakeup the CPUs or from D3
> 
> The CPU event is a single input to the CPU which can be triggered by any
> source which has the Event mask enabled.
> 
> For both classes there are sources which have no connection to the NVIC,
> they can only be used to generate CPU events or trigger the wakeup
> logic.
> 
> For direct events there is a category where the peripherial interrupt is
> routed to both the EXTI and the NVIC directly. The EXTI does not provide
> a connection to the NVIC and the event cannot be masked in EXTI to
> prevent CPU interrupts. Only the CPU event masking works.
> 
> GPIO pins are configurable events which are connected to the NVIC via
> the EXTI.
> 
> But the EXTI driver implements a chained interrupt handler which listens
> on a ton of NVIC interrupts. I.e. for the STM32H7 on:
> 
>   <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <62>, <76>
> 
> NVIC   1: PVD_PVM           EXTI-SRC 16
> NVIC   2: RTC_TAMP_STAMP    EXTI-SRC 18
> NVIC   3: RTC_WAKEUP        EXTI-SRC 19
> NVIC   6: EXTI0             EXTI-SRC  0
> NVIC   7: EXTI1             EXTI-SRC  1
> NVIC   8: EXTI2             EXTI-SRC  2
> NVIC   9: EXTI3             EXTI-SRC  3
> NVIC  10: EXTI4             EXTI-SRC  4
> NVIC  23: EXTI5-9           EXTI-SRC  5-9
> NVIC  40: EXTI10-15         EXTI-SRC 10-15
> NVIC  41: RTC_ALARM         EXTI-SRC 17
> NVIC  62: ETH_WKUP          EXTI-SRC 86
> NVIC  76: OTG_HS_WKUP       EXTI-SRC 43
> 
> Each of these chained interrupts handles the full EXTI interrupt domain
> with all three banks. This does not make any sense at all especially not
> on a SMP machine.
> 
> Though it _should_ work, but it might cause interrupts handlers to be
> invoked when nothing is pending when the edge handler is active. Which
> in turn can confuse the underlying device driver depending on the
> quality...
> 
> CPU0					CPU1
> 
> NVIC int X                      	NVIC int Y
> 
>  // read_pending() is serialized by a lock, but both read the same state
>  pend = read_pending()			pend = read_pending()
>  
>  for_each_bit(bit, pend)	 	for_each_bit(bit, pend)	
>     handle_irq(domain, base + bit)         handle_irq(domain, base + bit)
>       lock(desc);                            lock(desc);
>       ack();
>       do {
>          clear(PENDING);
>          set(IN_PROGRESS);
>          unlock(desc);
>          handle();                           if (IN_PROGRESS) {
>          lock(desc);                           ack();
>                                                set(PENDING);
>          				       unlock(desc);
>          clear(IN_PROGRESS);                   return;
>                                              }
>       } while (PENDING); <- Will loop
> 
> See?

Currently, this driver is only used on single core machines, and the
more complex devices use exti_h, so this shouldn't be a problem in
practice.

> 
> In fact the only NVIC interrupts which actually need demultiplexing are
> NVIC #23 and NVIC #40 and those should only care about the EXTI
> interrupts which are actually multiplexed on them. This let's randomly
> run whatever is pending on any demux handler is far from correct.
> 
> All others are direct NVIC interrupts which just have the extra EXTI
> interrupt masking, event masking and the wakeup magic. The indirection
> via the chained handler is just pointless overhead and not necessarily
> correct.
> 
> The exti_h variant of that driver does the right thing and installs a
> hierarchical interrupt domain which acts as man in the middle between
> the source and the NVIC. Though granted they don't have the odd problem
> of multiplexing several GPIO interrupts to a single NVIC interrupt.
> 
> But in fact the regular exti driver could do the same and just handle
> the two NVIC interrupts which need demultiplexing separately and let
> everything else go through the hierarchy without bells and whistles.

This sounds reasonable to me. It did seem strange to me that the exti
and exti_h drivers used such different approaches, although I wasn't
aware of the reasons behind them. I think this refactoring is out of
scope of this bug fix though.

> 
> Thanks,
> 
>         tglx

Thanks, Ben


From ryan.roberts at arm.com  Tue Dec 12 07:38:34 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 12 Dec 2023 15:38:34 +0000
Subject: [PATCH v9 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <2bebcf33-e8b7-468d-86cc-31d6eb355b66@redhat.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207161211.2374093-5-ryan.roberts@arm.com>
 <2bebcf33-e8b7-468d-86cc-31d6eb355b66@redhat.com>
Message-ID: <d67754d6-8f11-4d36-8e16-4f93bc04bea6@arm.com>

On 12/12/2023 15:02, David Hildenbrand wrote:
> On 07.12.23 17:12, Ryan Roberts wrote:
>> Introduce the logic to allow THP to be configured (through the new sysfs
>> interface we just added) to allocate large folios to back anonymous
>> memory, which are larger than the base page size but smaller than
>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>>
>> mTHP continues to be PTE-mapped, but in many cases can still provide
>> similar benefits to traditional PMD-sized THP: Page faults are
>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
>> the configured order), but latency spikes are much less prominent
>> because the size of each page isn't as huge as the PMD-sized variant and
>> there is less memory to clear in each page fault. The number of per-page
>> operations (e.g. ref counting, rmap management, lru list management) are
>> also significantly reduced since those ops now become per-folio.
> 
> I'll note that with always-pte-mapped-thp it will be much easier to support
> incremental page clearing (e.g., zero only parts of the folio and map the
> remainder in a pro-non-like fashion whereby we'll zero on the next page fault).
> With a PMD-sized thp, you have to eventually place/rip out page tables to
> achieve that.

But then you lose the benefits of reduced number of page faults; reducing page
faults gives a big speed up for workloads with lots of short lived processes
like compiling.

But yes, I agree this could be an interesting future optimization for some
workloads.

> 
>>
>> Some architectures also employ TLB compression mechanisms to squeeze
>> more entries in when a set of PTEs are virtually and physically
>> contiguous and approporiately aligned. In this case, TLB misses will
>> occur less often.
>>
>> The new behaviour is disabled by default, but can be enabled at runtime
>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
>> (see documentation in previous commit). The long term aim is to change
>> the default to include suitable lower orders, but there are some risks
>> around internal fragmentation that need to be better understood first.
>>
>> Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
>> ? include/linux/huge_mm.h |?? 6 ++-
>> ? mm/memory.c???????????? | 111 ++++++++++++++++++++++++++++++++++++----
>> ? 2 files changed, 106 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> index 609c153bae57..fa7a38a30fc6 100644
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>> ? #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> 
> [...]
> 
>> +
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>> +{
>> +??? struct vm_area_struct *vma = vmf->vma;
>> +??? unsigned long orders;
>> +??? struct folio *folio;
>> +??? unsigned long addr;
>> +??? pte_t *pte;
>> +??? gfp_t gfp;
>> +??? int order;
>> +
>> +??? /*
>> +???? * If uffd is active for the vma we need per-page fault fidelity to
>> +???? * maintain the uffd semantics.
>> +???? */
>> +??? if (unlikely(userfaultfd_armed(vma)))
>> +??????? goto fallback;
>> +
>> +??? /*
>> +???? * Get a list of all the (large) orders below PMD_ORDER that are enabled
>> +???? * for this vma. Then filter out the orders that can't be allocated over
>> +???? * the faulting address and still be fully contained in the vma.
>> +???? */
>> +??? orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
>> +????????????????????? BIT(PMD_ORDER) - 1);
>> +??? orders = thp_vma_suitable_orders(vma, vmf->address, orders);
>> +
>> +??? if (!orders)
>> +??????? goto fallback;
>> +
>> +??? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>> +??? if (!pte)
>> +??????? return ERR_PTR(-EAGAIN);
>> +
>> +??? /*
>> +???? * Find the highest order where the aligned range is completely
>> +???? * pte_none(). Note that all remaining orders will be completely
>> +???? * pte_none().
>> +???? */
>> +??? order = highest_order(orders);
>> +??? while (orders) {
>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>> +??????? if (pte_range_none(pte + pte_index(addr), 1 << order))
>> +??????????? break;
>> +??????? order = next_order(&orders, order);
>> +??? }
>> +
>> +??? pte_unmap(pte);
>> +
>> +??? /* Try allocating the highest of the remaining orders. */
>> +??? gfp = vma_thp_gfp_mask(vma);
>> +??? while (orders) {
>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>> +??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>> +??????? if (folio) {
>> +??????????? clear_huge_page(&folio->page, vmf->address, 1 << order);
>> +??????????? return folio;
>> +??????? }
>> +??????? order = next_order(&orders, order);
>> +??? }
>> +
>> +fallback:
>> +??? return vma_alloc_zeroed_movable_folio(vma, vmf->address);
>> +}
>> +#else
>> +#define alloc_anon_folio(vmf) \
>> +??????? vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
>> +#endif
> 
> A neater alternative might be
> 
> static struct folio *alloc_anon_folio(struct vm_fault *vmf)
> {
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> ????/* magic */
> fallback:
> #endif
> ????return vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address):
> }

I guess beauty lies in the eye of the beholder... I don't find it much neater
personally :). But happy to make the change if you insist; what's the process
now that its in mm-unstable? Just send a patch to Andrew for squashing?

> 
> [...]
> 
> Acked-by: David Hildenbrand <david at redhat.com>
> 



From seanjc at google.com  Tue Dec 12 07:39:29 2023
From: seanjc at google.com (Sean Christopherson)
Date: Tue, 12 Dec 2023 07:39:29 -0800
Subject: [PATCH v3 4/5] perf kvm: Support sampling guest callchains
In-Reply-To: <SYBPR01MB687083237B0E5C03B63EDAB99D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
References: <SYBPR01MB687069BFC9744585B4EEF8C49D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
 <SYBPR01MB687083237B0E5C03B63EDAB99D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
Message-ID: <ZXh-sRZQWvJYn0uJ@google.com>

On Sun, Dec 10, 2023, Tianyi Liu wrote:
> This patch provides support for sampling guests' callchains.
> 
> The signature of `get_perf_callchain` has been modified to explicitly
> specify whether it needs to sample the host or guest callchain. Based on
> the context, `get_perf_callchain` will distribute each sampling request
> to one of `perf_callchain_user`, `perf_callchain_kernel`,
> or `perf_callchain_guest`.
> 
> The reason for separately implementing `perf_callchain_user` and
> `perf_callchain_kernel` is that the kernel may utilize special unwinders
> like `ORC`. However, for the guest, we only support stackframe-based
> unwinding, so the implementation is generic and only needs to be
> separately implemented for 32-bit and 64-bit.
> 
> Signed-off-by: Tianyi Liu <i.pear at outlook.com>
> ---
>  arch/x86/events/core.c     | 63 ++++++++++++++++++++++++++++++++------
>  include/linux/perf_event.h |  3 +-
>  kernel/bpf/stackmap.c      |  8 ++---
>  kernel/events/callchain.c  | 27 +++++++++++++++-
>  kernel/events/core.c       |  7 ++++-
>  5 files changed, 91 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 40ad1425ffa2..4ff412225217 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -2758,11 +2758,6 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re
>  	struct unwind_state state;
>  	unsigned long addr;
>  
> -	if (perf_guest_state()) {
> -		/* TODO: We don't support guest os callchain now */
> -		return;
> -	}
> -
>  	if (perf_callchain_store(entry, regs->ip))
>  		return;
>  
> @@ -2778,6 +2773,59 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re
>  	}
>  }
>  
> +static inline void
> +perf_callchain_guest32(struct perf_callchain_entry_ctx *entry,
> +		       const struct perf_kvm_guest_unwind_info *unwind_info)
> +{
> +	unsigned long ss_base, cs_base;
> +	struct stack_frame_ia32 frame;
> +	const struct stack_frame_ia32 *fp;
> +
> +	cs_base = unwind_info->segment_cs_base;
> +	ss_base = unwind_info->segment_ss_base;
> +
> +	fp = (void *)(ss_base + unwind_info->frame_pointer);
> +	while (fp && entry->nr < entry->max_stack) {
> +		if (!perf_guest_read_virt((unsigned long)&fp->next_frame,

This is extremely confusing and potentially dangerous.  ss_base and
unwind_info->frame_pointer are *guest* SS:RBP, i.e. this is referencing a guest
virtual address.  It works, but it _looks_ like the code is fully dereferencing
a guest virtual address in the hose kernel.  And I can only imagine what type of
speculative accesses this generates.

*If* we want to support guest callchains, I think it would make more sense to
have a single hook for KVM/virtualization to fill perf_callchain_entry_ctx.  Then
there's no need for "struct perf_kvm_guest_unwind_info", perf doesn't need a hook
to read guest memory, and KVM can decide/control what to do with respect to
mitigating speculatiion issues. 

> +					  &frame.next_frame, sizeof(frame.next_frame)))
> +			break;
> +		if (!perf_guest_read_virt((unsigned long)&fp->return_address,
> +					  &frame.return_address, sizeof(frame.return_address)))
> +			break;
> +		perf_callchain_store(entry, cs_base + frame.return_address);
> +		fp = (void *)(ss_base + frame.next_frame);
> +	}
> +}


From nm at ti.com  Tue Dec 12 07:42:38 2023
From: nm at ti.com (Nishanth Menon)
Date: Tue, 12 Dec 2023 09:42:38 -0600
Subject: [PATCH] soc: ti: k3-socinfo: Add JTAG ID for J722S
In-Reply-To: <81f90d13-da10-4a68-a0e7-95212f40b3e8@ti.com>
References: <20231211132600.25289-1-vaishnav.a@ti.com>
 <81f90d13-da10-4a68-a0e7-95212f40b3e8@ti.com>
Message-ID: <20231212154238.3sn5fxpestaqacrc@defog>

On 09:19-20231212, Andrew Davis wrote:
> On 12/11/23 7:26 AM, Vaishnav Achath wrote:
> > Add JTAG ID info for the J722S SoC family to enable SoC detection.
> > 
> > More details about this SoC can be found in the TRM:
> > 	https://www.ti.com/lit/zip/sprujb3
> > 
> > Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
> > ---
> 
> Simple enough,
> 
> Reviewed-by: Andrew Davis <afd at ti.com>
> 
> Although I do question our use of the J7x names. All of our parts here
> also have a "Sitara AMxx" branding. For instance here we could call
> this new device by its "AM67" name, then J784S4 renamed as AM69, etc.
> Then we would have a consistent naming (internally we will have to deal
> with the part name madness, but why expose that externally if we don't
> have to).

J722S is a new die and the core part, what rebranding/spins happens to it is
subject to mktg group, not going to hold this series with that.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From broonie at kernel.org  Tue Dec 12 07:46:32 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 12 Dec 2023 15:46:32 +0000
Subject: [PATCH 0/8] regulator: Convert to platform remove callback
 returning void
In-Reply-To: <cover.1701778038.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701778038.git.u.kleine-koenig@pengutronix.de>
Message-ID: <170239599261.81481.1924826267147407361.b4-ty@kernel.org>

On Tue, 05 Dec 2023 13:26:15 +0100, Uwe Kleine-K?nig wrote:
> this series converts all drivers below drivers/regulator to struct
> platform_driver::remove_new(). See commit 5c5a7680e67b ("platform:
> Provide a remove callback that returns no value") for an extended
> explanation and the eventual goal.
> 
> All conversations are trivial, because all .remove() callbacks returned
> zero unconditionally.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/8] regulator: arizona-ldo1: Convert to platform remove callback returning void
      commit: 03560ff08d2839d7381f18576b329a2eee5cfb37
[2/8] regulator: bd9571mwv: Convert to platform remove callback returning void
      commit: cddda6f5f47f7cb13191b7753bc3882940b6f325
[3/8] regulator: db8500-prcmu: Convert to platform remove callback returning void
      commit: 0210a60aad02149d8503d259525bfbe0e99f8cb2
[4/8] regulator: stm32-vrefbuf: Convert to platform remove callback returning void
      commit: 6f382a0c7ec12f85f4e40d5343ba53f16f543ccb
[5/8] regulator: uniphier: Convert to platform remove callback returning void
      commit: 964575179663db70832e374edfacc91539e783d3
[6/8] regulator: userspace-consumer: Convert to platform remove callback returning void
      commit: 3b2e8e98692b20436d0346fc6adffff1b596d50f
[7/8] regulator: virtual: Convert to platform remove callback returning void
      commit: d637a75ede3db84f7ae4bc2ab398fe2232f22c26
[8/8] regulator: wm8350: Convert to platform remove callback returning void
      commit: 8d6fab52f3fdaeb8aabfd046d95e5d3f9464399e

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From broonie at kernel.org  Tue Dec 12 07:46:42 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 12 Dec 2023 15:46:42 +0000
Subject: [PATCH 0/2] spi: pl022: clean up some unused variables
In-Reply-To: <cover.1702298527.git.namcao@linutronix.de>
References: <cover.1702298527.git.namcao@linutronix.de>
Message-ID: <170239600215.81606.18013257147179685580.b4-ty@kernel.org>

On Mon, 11 Dec 2023 13:49:13 +0100, Nam Cao wrote:
> The driver was refactored in 9b2ef250b31d ("spi: spl022: switch to use
> default spi_transfer_one_message()"), and some variables are now unused
> because of that. Clean them up.
> 
> Nam Cao (2):
>   spi: pl022: delete unused cur_gpiod in struct pl022
>   spi: pl022: delete unused next_msg_cs_active in struct pl022
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/2] spi: pl022: delete unused cur_gpiod in struct pl022
      commit: 4c6dd33de9d3148909bc403d394f527bec4aec27
[2/2] spi: pl022: delete unused next_msg_cs_active in struct pl022
      commit: 3c49d848d2d3c6fe46522e4d750fc3a18e699997

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From james.clark at arm.com  Tue Dec 12 07:53:57 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:53:57 +0000
Subject: [PATCH 0/8] coresight: Separate sysfs and Perf usage and some other cleanups
Message-ID: <20231212155407.1429121-1-james.clark@arm.com>

I've been finding it quite difficult to reason about some of the state
and functions in coresight-core.c because they have generic names when
they are actually only relevant to the sysfs usage of Coresight rather
than usage through Perf. This is probably because sysfs came first and
Perf was added later. This has caused a couple of issues where these
things have been used in the wrong context, for example the first
commit is a fixup.

To fix this I've mainly just moved all of the sysfs stuff to the sysfs
file and removed the 'enable' state, which was just for sysfs. While
doing the refactor it became obvious that refcnt didn't need to be
atomic either, so that can be simplified along with some other comment
clarifications and simplifications.

Hopefully it's also a step towards to removing all of the duplicate
refcnt and mode tracking code from the individual devices. That tracking
pretty much always results in a one-shot enable/disable and fixes the
mode to either sysfs or Perf, and there is no reason that can't exist in
the core layer outside of the devices. I tried to finish that in this
set, but there turned out to be some complexities, so I cut it short at
a point where I can be sure that there are no behavioral changes.

James Clark (8):
  coresight: Fix issue where a source device's helpers aren't disabled
  coresight: Make language around "activated" sinks consistent
  coresight: Remove ops callback checks
  coresight: Move mode to struct coresight_device
  coresight: Remove the 'enable' field.
  coresight: Move all sysfs code to sysfs file
  coresight: Remove atomic type from refcnt
  coresight: Remove unused stubs

 drivers/hwtracing/coresight/coresight-core.c  | 494 +-----------------
 drivers/hwtracing/coresight/coresight-etb10.c |  29 +-
 .../hwtracing/coresight/coresight-etm-perf.c  |   2 +-
 drivers/hwtracing/coresight/coresight-etm.h   |   2 -
 .../coresight/coresight-etm3x-core.c          |  17 +-
 .../coresight/coresight-etm3x-sysfs.c         |   4 +-
 .../coresight/coresight-etm4x-core.c          |   4 +-
 drivers/hwtracing/coresight/coresight-priv.h  |   9 +-
 drivers/hwtracing/coresight/coresight-stm.c   |  24 +-
 drivers/hwtracing/coresight/coresight-sysfs.c | 391 ++++++++++++++
 .../hwtracing/coresight/coresight-tmc-core.c  |   2 +-
 .../hwtracing/coresight/coresight-tmc-etf.c   |  46 +-
 .../hwtracing/coresight/coresight-tmc-etr.c   |  33 +-
 drivers/hwtracing/coresight/coresight-tmc.h   |   2 -
 drivers/hwtracing/coresight/coresight-tpda.c  |  13 +-
 drivers/hwtracing/coresight/coresight-tpiu.c  |  14 +-
 drivers/hwtracing/coresight/ultrasoc-smb.c    |  22 +-
 drivers/hwtracing/coresight/ultrasoc-smb.h    |   2 -
 include/linux/coresight.h                     | 114 +---
 19 files changed, 561 insertions(+), 663 deletions(-)

-- 
2.34.1



From james.clark at arm.com  Tue Dec 12 07:53:58 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:53:58 +0000
Subject: [PATCH 1/8] coresight: Fix issue where a source device's helpers aren't disabled
In-Reply-To: <20231212155407.1429121-1-james.clark@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
Message-ID: <20231212155407.1429121-2-james.clark@arm.com>

The linked commit reverts the change that accidentally used some sysfs
enable/disable functions from Perf which broke the refcounting, but it
also removes the fact that the sysfs disable function disabled the
helpers.

Add a new wrapper function that does both which is used by both Perf and
sysfs, and label the sysfs disable function appropriately. The naming of
all of the functions will be tidied up later to avoid this happening
again.

Fixes: 287e82cf69aa ("coresight: Fix crash when Perf and sysfs modes are used concurrently")
Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/hwtracing/coresight/coresight-core.c  | 30 ++++++++++++++-----
 .../hwtracing/coresight/coresight-etm-perf.c  |  2 +-
 drivers/hwtracing/coresight/coresight-priv.h  |  2 +-
 3 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index d7f0e231feb9..965bb6d4e1bf 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -441,8 +441,26 @@ static void coresight_disable_helpers(struct coresight_device *csdev)
 	}
 }
 
+/*
+ * Helper function to call source_ops(csdev)->disable and also disable the
+ * helpers.
+ *
+ * There is an imbalance between coresight_enable_path() and
+ * coresight_disable_path(). Enabling also enables the source's helpers as part
+ * of the path, but disabling always skips the first item in the path (which is
+ * the source), so sources and their helpers don't get disabled as part of that
+ * function and we need the extra step here.
+ */
+void coresight_disable_source(struct coresight_device *csdev, void *data)
+{
+	if (source_ops(csdev)->disable)
+		source_ops(csdev)->disable(csdev, data);
+	coresight_disable_helpers(csdev);
+}
+EXPORT_SYMBOL_GPL(coresight_disable_source);
+
 /**
- *  coresight_disable_source - Drop the reference count by 1 and disable
+ *  coresight_disable_source_sysfs - Drop the reference count by 1 and disable
  *  the device if there are no users left.
  *
  *  @csdev: The coresight device to disable
@@ -451,17 +469,15 @@ static void coresight_disable_helpers(struct coresight_device *csdev)
  *
  *  Returns true if the device has been disabled.
  */
-bool coresight_disable_source(struct coresight_device *csdev, void *data)
+static bool coresight_disable_source_sysfs(struct coresight_device *csdev,
+					   void *data)
 {
 	if (atomic_dec_return(&csdev->refcnt) == 0) {
-		if (source_ops(csdev)->disable)
-			source_ops(csdev)->disable(csdev, data);
-		coresight_disable_helpers(csdev);
+		coresight_disable_source(csdev, data);
 		csdev->enable = false;
 	}
 	return !csdev->enable;
 }
-EXPORT_SYMBOL_GPL(coresight_disable_source);
 
 /*
  * coresight_disable_path_from : Disable components in the given path beyond
@@ -1204,7 +1220,7 @@ void coresight_disable(struct coresight_device *csdev)
 	if (ret)
 		goto out;
 
-	if (!csdev->enable || !coresight_disable_source(csdev, NULL))
+	if (!csdev->enable || !coresight_disable_source_sysfs(csdev, NULL))
 		goto out;
 
 	switch (csdev->subtype.source_subtype) {
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index a52cfcce25d6..c0c60e6a1703 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -589,7 +589,7 @@ static void etm_event_stop(struct perf_event *event, int mode)
 		return;
 
 	/* stop tracer */
-	source_ops(csdev)->disable(csdev, event);
+	coresight_disable_source(csdev, event);
 
 	/* tell the core */
 	event->hw.state = PERF_HES_STOPPED;
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 767076e07970..30c051055e54 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -233,6 +233,6 @@ void coresight_set_percpu_sink(int cpu, struct coresight_device *csdev);
 struct coresight_device *coresight_get_percpu_sink(int cpu);
 int coresight_enable_source(struct coresight_device *csdev, enum cs_mode mode,
 			    void *data);
-bool coresight_disable_source(struct coresight_device *csdev, void *data);
+void coresight_disable_source(struct coresight_device *csdev, void *data);
 
 #endif
-- 
2.34.1



From james.clark at arm.com  Tue Dec 12 07:53:59 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:53:59 +0000
Subject: [PATCH 2/8] coresight: Make language around "activated" sinks consistent
In-Reply-To: <20231212155407.1429121-1-james.clark@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
Message-ID: <20231212155407.1429121-3-james.clark@arm.com>

Activated has the specific meaning of a sink that's selected for use by
the user via sysfs. But comments in some code that's shared by Perf use
the same word, so in those cases change them to just say "selected"
instead. With selected implying either via Perf or "activated" via
sysfs.

coresight_get_enabled_sink() doesn't actually get an enabled sink, it
only gets an activated one, so change that too.

And change the activated variable name to include "sysfs" so it can't
be confused as a general status.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/hwtracing/coresight/coresight-core.c | 51 ++++++++------------
 drivers/hwtracing/coresight/coresight-priv.h |  2 -
 include/linux/coresight.h                    | 14 +++---
 3 files changed, 27 insertions(+), 40 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 965bb6d4e1bf..f79aa9ff9b64 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -500,7 +500,7 @@ static void coresight_disable_path_from(struct list_head *path,
 		/*
 		 * ETF devices are tricky... They can be a link or a sink,
 		 * depending on how they are configured.  If an ETF has been
-		 * "activated" it will be configured as a sink, otherwise
+		 * selected as a sink it will be configured as a sink, otherwise
 		 * go ahead with the link configuration.
 		 */
 		if (type == CORESIGHT_DEV_TYPE_LINKSINK)
@@ -578,7 +578,7 @@ int coresight_enable_path(struct list_head *path, enum cs_mode mode,
 		/*
 		 * ETF devices are tricky... They can be a link or a sink,
 		 * depending on how they are configured.  If an ETF has been
-		 * "activated" it will be configured as a sink, otherwise
+		 * selected as a sink it will be configured as a sink, otherwise
 		 * go ahead with the link configuration.
 		 */
 		if (type == CORESIGHT_DEV_TYPE_LINKSINK)
@@ -635,15 +635,21 @@ struct coresight_device *coresight_get_sink(struct list_head *path)
 	return csdev;
 }
 
+/**
+ * coresight_find_activated_sysfs_sink - returns the first sink activated via
+ * sysfs using connection based search starting from the source reference.
+ *
+ * @csdev: Coresight source device reference
+ */
 static struct coresight_device *
-coresight_find_enabled_sink(struct coresight_device *csdev)
+coresight_find_activated_sysfs_sink(struct coresight_device *csdev)
 {
 	int i;
 	struct coresight_device *sink = NULL;
 
 	if ((csdev->type == CORESIGHT_DEV_TYPE_SINK ||
 	     csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) &&
-	     csdev->activated)
+	     csdev->sysfs_sink_activated)
 		return csdev;
 
 	/*
@@ -654,7 +660,7 @@ coresight_find_enabled_sink(struct coresight_device *csdev)
 
 		child_dev = csdev->pdata->out_conns[i]->dest_dev;
 		if (child_dev)
-			sink = coresight_find_enabled_sink(child_dev);
+			sink = coresight_find_activated_sysfs_sink(child_dev);
 		if (sink)
 			return sink;
 	}
@@ -662,21 +668,6 @@ coresight_find_enabled_sink(struct coresight_device *csdev)
 	return NULL;
 }
 
-/**
- * coresight_get_enabled_sink - returns the first enabled sink using
- * connection based search starting from the source reference
- *
- * @source: Coresight source device reference
- */
-struct coresight_device *
-coresight_get_enabled_sink(struct coresight_device *source)
-{
-	if (!source)
-		return NULL;
-
-	return coresight_find_enabled_sink(source);
-}
-
 static int coresight_sink_by_id(struct device *dev, const void *data)
 {
 	struct coresight_device *csdev = to_coresight_device(dev);
@@ -810,11 +801,10 @@ static void coresight_drop_device(struct coresight_device *csdev)
  * @sink:	The final sink we want in this path.
  * @path:	The list to add devices to.
  *
- * The tree of Coresight device is traversed until an activated sink is
- * found.  From there the sink is added to the list along with all the
- * devices that led to that point - the end result is a list from source
- * to sink. In that list the source is the first device and the sink the
- * last one.
+ * The tree of Coresight device is traversed until the selected sink is found.
+ * From there the sink is added to the list along with all the devices that led
+ * to that point - the end result is a list from source to sink. In that list
+ * the source is the first device and the sink the last one.
  */
 static int _coresight_build_path(struct coresight_device *csdev,
 				 struct coresight_device *sink,
@@ -824,7 +814,7 @@ static int _coresight_build_path(struct coresight_device *csdev,
 	bool found = false;
 	struct coresight_node *node;
 
-	/* An activated sink has been found.  Enqueue the element */
+	/* The selected sink has been found.  Enqueue the element */
 	if (csdev == sink)
 		goto out;
 
@@ -1145,7 +1135,7 @@ int coresight_enable(struct coresight_device *csdev)
 		goto out;
 	}
 
-	sink = coresight_get_enabled_sink(csdev);
+	sink = coresight_find_activated_sysfs_sink(csdev);
 	if (!sink) {
 		ret = -EINVAL;
 		goto out;
@@ -1259,7 +1249,7 @@ static ssize_t enable_sink_show(struct device *dev,
 {
 	struct coresight_device *csdev = to_coresight_device(dev);
 
-	return scnprintf(buf, PAGE_SIZE, "%u\n", csdev->activated);
+	return scnprintf(buf, PAGE_SIZE, "%u\n", csdev->sysfs_sink_activated);
 }
 
 static ssize_t enable_sink_store(struct device *dev,
@@ -1274,10 +1264,7 @@ static ssize_t enable_sink_store(struct device *dev,
 	if (ret)
 		return ret;
 
-	if (val)
-		csdev->activated = true;
-	else
-		csdev->activated = false;
+	csdev->sysfs_sink_activated = !!val;
 
 	return size;
 
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 30c051055e54..ced5be05a527 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -130,8 +130,6 @@ void coresight_disable_path(struct list_head *path);
 int coresight_enable_path(struct list_head *path, enum cs_mode mode,
 			  void *sink_data);
 struct coresight_device *coresight_get_sink(struct list_head *path);
-struct coresight_device *
-coresight_get_enabled_sink(struct coresight_device *source);
 struct coresight_device *coresight_get_sink_by_id(u32 id);
 struct coresight_device *
 coresight_find_default_sink(struct coresight_device *csdev);
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index a4cb7dd6ca23..65131bfbd904 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -229,10 +229,12 @@ struct coresight_sysfs_link {
  * @refcnt:	keep track of what is in use.
  * @orphan:	true if the component has connections that haven't been linked.
  * @enable:	'true' if component is currently part of an active path.
- * @activated:	'true' only if a _sink_ has been activated.  A sink can be
- *		activated but not yet enabled.  Enabling for a _sink_
- *		happens when a source has been selected and a path is enabled
- *		from source to that sink.
+ * @sysfs_sink_activated: 'true' when a sink has been selected for use via sysfs
+ *		by writing a 1 to the 'enable_sink' file.  A sink can be
+ *		activated but not yet enabled.  Enabling for a _sink_ happens
+ *		when a source has been selected and a path is enabled from
+ *		source to that sink. A sink can also become enabled but not
+ *		activated if it's used via Perf.
  * @ea:		Device attribute for sink representation under PMU directory.
  * @def_sink:	cached reference to default sink found for this device.
  * @nr_links:   number of sysfs links created to other components from this
@@ -252,9 +254,9 @@ struct coresight_device {
 	struct device dev;
 	atomic_t refcnt;
 	bool orphan;
-	bool enable;	/* true only if configured as part of a path */
+	bool enable;
 	/* sink specific fields */
-	bool activated;	/* true only if a sink is part of a path */
+	bool sysfs_sink_activated;
 	struct dev_ext_attribute *ea;
 	struct coresight_device *def_sink;
 	/* sysfs links between components */
-- 
2.34.1



From james.clark at arm.com  Tue Dec 12 07:54:00 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:54:00 +0000
Subject: [PATCH 3/8] coresight: Remove ops callback checks
In-Reply-To: <20231212155407.1429121-1-james.clark@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
Message-ID: <20231212155407.1429121-4-james.clark@arm.com>

The check for the existence of callbacks before using them implies that
this happens and is supported. There are no devices without
enable/disable callbacks, and it wouldn't be possible to add a new
working device without adding them either, so just remove them.

Furthermore, there are more callbacks than just enable and disable that
are already used unguarded in other places.

The comment about new session compatibility doesn't seem to match up to
the line of code that it's on so remove it. I think it's alluding to the
fact that sinks will check if they were already enabled via sysfs or
Perf and fail the enable. But there are more detailed comments at those
places, and this one isn't very useful.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/hwtracing/coresight/coresight-core.c | 51 +++++---------------
 1 file changed, 12 insertions(+), 39 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index f79aa9ff9b64..ab226441e5f4 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -279,16 +279,8 @@ EXPORT_SYMBOL_GPL(coresight_add_helper);
 static int coresight_enable_sink(struct coresight_device *csdev,
 				 enum cs_mode mode, void *data)
 {
-	int ret;
-
-	/*
-	 * We need to make sure the "new" session is compatible with the
-	 * existing "mode" of operation.
-	 */
-	if (!sink_ops(csdev)->enable)
-		return -EINVAL;
+	int ret = sink_ops(csdev)->enable(csdev, mode, data);
 
-	ret = sink_ops(csdev)->enable(csdev, mode, data);
 	if (ret)
 		return ret;
 
@@ -299,12 +291,7 @@ static int coresight_enable_sink(struct coresight_device *csdev,
 
 static void coresight_disable_sink(struct coresight_device *csdev)
 {
-	int ret;
-
-	if (!sink_ops(csdev)->disable)
-		return;
-
-	ret = sink_ops(csdev)->disable(csdev);
+	int ret = sink_ops(csdev)->disable(csdev);
 	if (ret)
 		return;
 	csdev->enable = false;
@@ -330,11 +317,9 @@ static int coresight_enable_link(struct coresight_device *csdev,
 	if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_SPLIT && IS_ERR(outconn))
 		return PTR_ERR(outconn);
 
-	if (link_ops(csdev)->enable) {
-		ret = link_ops(csdev)->enable(csdev, inconn, outconn);
-		if (!ret)
-			csdev->enable = true;
-	}
+	ret = link_ops(csdev)->enable(csdev, inconn, outconn);
+	if (!ret)
+		csdev->enable = true;
 
 	return ret;
 }
@@ -354,9 +339,7 @@ static void coresight_disable_link(struct coresight_device *csdev,
 	outconn = coresight_find_out_connection(csdev, child);
 	link_subtype = csdev->subtype.link_subtype;
 
-	if (link_ops(csdev)->disable) {
-		link_ops(csdev)->disable(csdev, inconn, outconn);
-	}
+	link_ops(csdev)->disable(csdev, inconn, outconn);
 
 	if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG) {
 		for (i = 0; i < csdev->pdata->nr_inconns; i++)
@@ -382,11 +365,9 @@ int coresight_enable_source(struct coresight_device *csdev, enum cs_mode mode,
 	int ret;
 
 	if (!csdev->enable) {
-		if (source_ops(csdev)->enable) {
-			ret = source_ops(csdev)->enable(csdev, data, mode);
-			if (ret)
-				return ret;
-		}
+		ret = source_ops(csdev)->enable(csdev, data, mode);
+		if (ret)
+			return ret;
 		csdev->enable = true;
 	}
 
@@ -404,11 +385,8 @@ static bool coresight_is_helper(struct coresight_device *csdev)
 static int coresight_enable_helper(struct coresight_device *csdev,
 				   enum cs_mode mode, void *data)
 {
-	int ret;
+	int ret = helper_ops(csdev)->enable(csdev, mode, data);
 
-	if (!helper_ops(csdev)->enable)
-		return 0;
-	ret = helper_ops(csdev)->enable(csdev, mode, data);
 	if (ret)
 		return ret;
 
@@ -418,12 +396,8 @@ static int coresight_enable_helper(struct coresight_device *csdev,
 
 static void coresight_disable_helper(struct coresight_device *csdev)
 {
-	int ret;
-
-	if (!helper_ops(csdev)->disable)
-		return;
+	int ret = helper_ops(csdev)->disable(csdev, NULL);
 
-	ret = helper_ops(csdev)->disable(csdev, NULL);
 	if (ret)
 		return;
 	csdev->enable = false;
@@ -453,8 +427,7 @@ static void coresight_disable_helpers(struct coresight_device *csdev)
  */
 void coresight_disable_source(struct coresight_device *csdev, void *data)
 {
-	if (source_ops(csdev)->disable)
-		source_ops(csdev)->disable(csdev, data);
+	source_ops(csdev)->disable(csdev, data);
 	coresight_disable_helpers(csdev);
 }
 EXPORT_SYMBOL_GPL(coresight_disable_source);
-- 
2.34.1



From james.clark at arm.com  Tue Dec 12 07:54:01 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:54:01 +0000
Subject: [PATCH 4/8] coresight: Move mode to struct coresight_device
In-Reply-To: <20231212155407.1429121-1-james.clark@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
Message-ID: <20231212155407.1429121-5-james.clark@arm.com>

Most devices use mode, so move the mode definition out of the individual
devices and up to the Coresight device. This will allow the core code to
also know the mode which will be useful in a later commit.

This also fixes the inconsistency of the documentation of the mode field
on the individual device types. For example ETB10 had "this ETB is being
used".

Two devices didn't require an atomic mode type, so these usages have
been converted to atomic_get() and atomic_set() only to make it compile,
but the documentation of the field in struct coresight_device explains
this type of usage.

In the future, manipulation of the mode could be completely moved out of
the individual devices and into the core code because it's almost all
duplicate code, and this change is a step towards that.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 18 ++++++-------
 drivers/hwtracing/coresight/coresight-etm.h   |  2 --
 .../coresight/coresight-etm3x-core.c          | 13 +++++-----
 .../coresight/coresight-etm3x-sysfs.c         |  4 +--
 drivers/hwtracing/coresight/coresight-stm.c   | 20 +++++++-------
 .../hwtracing/coresight/coresight-tmc-core.c  |  2 +-
 .../hwtracing/coresight/coresight-tmc-etf.c   | 26 +++++++++----------
 .../hwtracing/coresight/coresight-tmc-etr.c   | 20 +++++++-------
 drivers/hwtracing/coresight/coresight-tmc.h   |  2 --
 drivers/hwtracing/coresight/ultrasoc-smb.c    | 13 +++++-----
 drivers/hwtracing/coresight/ultrasoc-smb.h    |  2 --
 include/linux/coresight.h                     |  6 +++++
 12 files changed, 62 insertions(+), 66 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index fa80039e0821..08e5bba862db 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -76,7 +76,6 @@ DEFINE_CORESIGHT_DEVLIST(etb_devs, "etb");
  * @pid:	Process ID of the process being monitored by the session
  *		that is using this component.
  * @buf:	area of memory where ETB buffer content gets sent.
- * @mode:	this ETB is being used.
  * @buffer_depth: size of @buf.
  * @trigger_cntr: amount of words to store after a trigger.
  */
@@ -89,7 +88,6 @@ struct etb_drvdata {
 	local_t			reading;
 	pid_t			pid;
 	u8			*buf;
-	u32			mode;
 	u32			buffer_depth;
 	u32			trigger_cntr;
 };
@@ -150,17 +148,17 @@ static int etb_enable_sysfs(struct coresight_device *csdev)
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
 	/* Don't messup with perf sessions. */
-	if (drvdata->mode == CS_MODE_PERF) {
+	if (local_read(&csdev->mode) == CS_MODE_PERF) {
 		ret = -EBUSY;
 		goto out;
 	}
 
-	if (drvdata->mode == CS_MODE_DISABLED) {
+	if (local_read(&csdev->mode) == CS_MODE_DISABLED) {
 		ret = etb_enable_hw(drvdata);
 		if (ret)
 			goto out;
 
-		drvdata->mode = CS_MODE_SYSFS;
+		local_set(&csdev->mode, CS_MODE_SYSFS);
 	}
 
 	atomic_inc(&csdev->refcnt);
@@ -181,7 +179,7 @@ static int etb_enable_perf(struct coresight_device *csdev, void *data)
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
 	/* No need to continue if the component is already in used by sysFS. */
-	if (drvdata->mode == CS_MODE_SYSFS) {
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_SYSFS) {
 		ret = -EBUSY;
 		goto out;
 	}
@@ -216,7 +214,7 @@ static int etb_enable_perf(struct coresight_device *csdev, void *data)
 	if (!ret) {
 		/* Associate with monitored process. */
 		drvdata->pid = pid;
-		drvdata->mode = CS_MODE_PERF;
+		local_set(&drvdata->csdev->mode, CS_MODE_PERF);
 		atomic_inc(&csdev->refcnt);
 	}
 
@@ -362,11 +360,11 @@ static int etb_disable(struct coresight_device *csdev)
 	}
 
 	/* Complain if we (somehow) got out of sync */
-	WARN_ON_ONCE(drvdata->mode == CS_MODE_DISABLED);
+	WARN_ON_ONCE(local_read(&csdev->mode) == CS_MODE_DISABLED);
 	etb_disable_hw(drvdata);
 	/* Dissociate from monitored process. */
 	drvdata->pid = -1;
-	drvdata->mode = CS_MODE_DISABLED;
+	local_set(&csdev->mode, CS_MODE_DISABLED);
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
 	dev_dbg(&csdev->dev, "ETB disabled\n");
@@ -589,7 +587,7 @@ static void etb_dump(struct etb_drvdata *drvdata)
 	unsigned long flags;
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
-	if (drvdata->mode == CS_MODE_SYSFS) {
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_SYSFS) {
 		__etb_disable_hw(drvdata);
 		etb_dump_hw(drvdata);
 		__etb_enable_hw(drvdata);
diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 9a0d08b092ae..e02c3ea972c9 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -215,7 +215,6 @@ struct etm_config {
  * @port_size:	port size as reported by ETMCR bit 4-6 and 21.
  * @arch:	ETM/PTM version number.
  * @use_cpu14:	true if management registers need to be accessed via CP14.
- * @mode:	this tracer's mode, i.e sysFS, Perf or disabled.
  * @sticky_enable: true if ETM base configuration has been done.
  * @boot_enable:true if we should start tracing at boot time.
  * @os_unlock:	true if access to management registers is allowed.
@@ -238,7 +237,6 @@ struct etm_drvdata {
 	int				port_size;
 	u8				arch;
 	bool				use_cp14;
-	local_t				mode;
 	bool				sticky_enable;
 	bool				boot_enable;
 	bool				os_unlock;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
index 116a91d90ac2..29f62dfac673 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
@@ -559,7 +559,7 @@ static int etm_enable(struct coresight_device *csdev, struct perf_event *event,
 	u32 val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	val = local_cmpxchg(&drvdata->mode, CS_MODE_DISABLED, mode);
+	val = local_cmpxchg(&drvdata->csdev->mode, CS_MODE_DISABLED, mode);
 
 	/* Someone is already using the tracer */
 	if (val)
@@ -578,7 +578,7 @@ static int etm_enable(struct coresight_device *csdev, struct perf_event *event,
 
 	/* The tracer didn't start */
 	if (ret)
-		local_set(&drvdata->mode, CS_MODE_DISABLED);
+		local_set(&drvdata->csdev->mode, CS_MODE_DISABLED);
 
 	return ret;
 }
@@ -672,14 +672,13 @@ static void etm_disable(struct coresight_device *csdev,
 			struct perf_event *event)
 {
 	enum cs_mode mode;
-	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
 	/*
 	 * For as long as the tracer isn't disabled another entity can't
 	 * change its status.  As such we can read the status here without
 	 * fearing it will change under us.
 	 */
-	mode = local_read(&drvdata->mode);
+	mode = local_read(&csdev->mode);
 
 	switch (mode) {
 	case CS_MODE_DISABLED:
@@ -696,7 +695,7 @@ static void etm_disable(struct coresight_device *csdev,
 	}
 
 	if (mode)
-		local_set(&drvdata->mode, CS_MODE_DISABLED);
+		local_set(&csdev->mode, CS_MODE_DISABLED);
 }
 
 static const struct coresight_ops_source etm_source_ops = {
@@ -730,7 +729,7 @@ static int etm_starting_cpu(unsigned int cpu)
 		etmdrvdata[cpu]->os_unlock = true;
 	}
 
-	if (local_read(&etmdrvdata[cpu]->mode))
+	if (local_read(&etmdrvdata[cpu]->csdev->mode))
 		etm_enable_hw(etmdrvdata[cpu]);
 	spin_unlock(&etmdrvdata[cpu]->spinlock);
 	return 0;
@@ -742,7 +741,7 @@ static int etm_dying_cpu(unsigned int cpu)
 		return 0;
 
 	spin_lock(&etmdrvdata[cpu]->spinlock);
-	if (local_read(&etmdrvdata[cpu]->mode))
+	if (local_read(&etmdrvdata[cpu]->csdev->mode))
 		etm_disable_hw(etmdrvdata[cpu]);
 	spin_unlock(&etmdrvdata[cpu]->spinlock);
 	return 0;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index 2f271b7fb048..6c8429c980b1 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -722,7 +722,7 @@ static ssize_t cntr_val_show(struct device *dev,
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
 	struct etm_config *config = &drvdata->config;
 
-	if (!local_read(&drvdata->mode)) {
+	if (!local_read(&drvdata->csdev->mode)) {
 		spin_lock(&drvdata->spinlock);
 		for (i = 0; i < drvdata->nr_cntr; i++)
 			ret += sprintf(buf, "counter %d: %x\n",
@@ -941,7 +941,7 @@ static ssize_t seq_curr_state_show(struct device *dev,
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
 	struct etm_config *config = &drvdata->config;
 
-	if (!local_read(&drvdata->mode)) {
+	if (!local_read(&drvdata->csdev->mode)) {
 		val = config->seq_curr_state;
 		goto out;
 	}
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index a1c27c901ad1..190ba569b05a 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -119,7 +119,6 @@ DEFINE_CORESIGHT_DEVLIST(stm_devs, "stm");
  * @spinlock:		only one at a time pls.
  * @chs:		the channels accociated to this STM.
  * @stm:		structure associated to the generic STM interface.
- * @mode:		this tracer's mode (enum cs_mode), i.e sysFS, or disabled.
  * @traceid:		value of the current ID for this component.
  * @write_bytes:	Maximus bytes this STM can write at a time.
  * @stmsper:		settings for register STMSPER.
@@ -136,7 +135,6 @@ struct stm_drvdata {
 	spinlock_t		spinlock;
 	struct channel_space	chs;
 	struct stm_data		stm;
-	local_t			mode;
 	u8			traceid;
 	u32			write_bytes;
 	u32			stmsper;
@@ -201,7 +199,7 @@ static int stm_enable(struct coresight_device *csdev, struct perf_event *event,
 	if (mode != CS_MODE_SYSFS)
 		return -EINVAL;
 
-	val = local_cmpxchg(&drvdata->mode, CS_MODE_DISABLED, mode);
+	val = local_cmpxchg(&csdev->mode, CS_MODE_DISABLED, mode);
 
 	/* Someone is already using the tracer */
 	if (val)
@@ -266,7 +264,7 @@ static void stm_disable(struct coresight_device *csdev,
 	 * change its status.  As such we can read the status here without
 	 * fearing it will change under us.
 	 */
-	if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
+	if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
 		spin_lock(&drvdata->spinlock);
 		stm_disable_hw(drvdata);
 		spin_unlock(&drvdata->spinlock);
@@ -276,7 +274,7 @@ static void stm_disable(struct coresight_device *csdev,
 
 		pm_runtime_put(csdev->dev.parent);
 
-		local_set(&drvdata->mode, CS_MODE_DISABLED);
+		local_set(&csdev->mode, CS_MODE_DISABLED);
 		dev_dbg(&csdev->dev, "STM tracing disabled\n");
 	}
 }
@@ -373,7 +371,7 @@ static long stm_generic_set_options(struct stm_data *stm_data,
 {
 	struct stm_drvdata *drvdata = container_of(stm_data,
 						   struct stm_drvdata, stm);
-	if (!(drvdata && local_read(&drvdata->mode)))
+	if (!(drvdata && local_read(&drvdata->csdev->mode)))
 		return -EINVAL;
 
 	if (channel >= drvdata->numsp)
@@ -408,7 +406,7 @@ static ssize_t notrace stm_generic_packet(struct stm_data *stm_data,
 						   struct stm_drvdata, stm);
 	unsigned int stm_flags;
 
-	if (!(drvdata && local_read(&drvdata->mode)))
+	if (!(drvdata && local_read(&drvdata->csdev->mode)))
 		return -EACCES;
 
 	if (channel >= drvdata->numsp)
@@ -515,7 +513,7 @@ static ssize_t port_select_show(struct device *dev,
 	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
 	unsigned long val;
 
-	if (!local_read(&drvdata->mode)) {
+	if (!local_read(&drvdata->csdev->mode)) {
 		val = drvdata->stmspscr;
 	} else {
 		spin_lock(&drvdata->spinlock);
@@ -541,7 +539,7 @@ static ssize_t port_select_store(struct device *dev,
 	spin_lock(&drvdata->spinlock);
 	drvdata->stmspscr = val;
 
-	if (local_read(&drvdata->mode)) {
+	if (local_read(&drvdata->csdev->mode)) {
 		CS_UNLOCK(drvdata->base);
 		/* Process as per ARM's TRM recommendation */
 		stmsper = readl_relaxed(drvdata->base + STMSPER);
@@ -562,7 +560,7 @@ static ssize_t port_enable_show(struct device *dev,
 	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
 	unsigned long val;
 
-	if (!local_read(&drvdata->mode)) {
+	if (!local_read(&drvdata->csdev->mode)) {
 		val = drvdata->stmsper;
 	} else {
 		spin_lock(&drvdata->spinlock);
@@ -588,7 +586,7 @@ static ssize_t port_enable_store(struct device *dev,
 	spin_lock(&drvdata->spinlock);
 	drvdata->stmsper = val;
 
-	if (local_read(&drvdata->mode)) {
+	if (local_read(&drvdata->csdev->mode)) {
 		CS_UNLOCK(drvdata->base);
 		writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
 		CS_LOCK(drvdata->base);
diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index 7ec5365e2b64..e5d47f61f9f3 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -558,7 +558,7 @@ static void tmc_shutdown(struct amba_device *adev)
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
-	if (drvdata->mode == CS_MODE_DISABLED)
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_DISABLED)
 		goto out;
 
 	if (drvdata->config_type == TMC_CONFIG_TYPE_ETR)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 7406b65e2cdd..2a7e516052a2 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -89,7 +89,7 @@ static void __tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
 	 * When operating in sysFS mode the content of the buffer needs to be
 	 * read before the TMC is disabled.
 	 */
-	if (drvdata->mode == CS_MODE_SYSFS)
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_SYSFS)
 		tmc_etb_dump_hw(drvdata);
 	tmc_disable_hw(drvdata);
 
@@ -205,7 +205,7 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev)
 	 * sink is already enabled no memory is needed and the HW need not be
 	 * touched.
 	 */
-	if (drvdata->mode == CS_MODE_SYSFS) {
+	if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
 		atomic_inc(&csdev->refcnt);
 		goto out;
 	}
@@ -228,7 +228,7 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev)
 
 	ret = tmc_etb_enable_hw(drvdata);
 	if (!ret) {
-		drvdata->mode = CS_MODE_SYSFS;
+		local_set(&csdev->mode, CS_MODE_SYSFS);
 		atomic_inc(&csdev->refcnt);
 	} else {
 		/* Free up the buffer if we failed to enable */
@@ -262,7 +262,7 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, void *data)
 		 * No need to continue if the ETB/ETF is already operated
 		 * from sysFS.
 		 */
-		if (drvdata->mode == CS_MODE_SYSFS) {
+		if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
 			ret = -EBUSY;
 			break;
 		}
@@ -292,7 +292,7 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, void *data)
 		if (!ret) {
 			/* Associate with monitored process. */
 			drvdata->pid = pid;
-			drvdata->mode = CS_MODE_PERF;
+			local_set(&csdev->mode, CS_MODE_PERF);
 			atomic_inc(&csdev->refcnt);
 		}
 	} while (0);
@@ -344,11 +344,11 @@ static int tmc_disable_etf_sink(struct coresight_device *csdev)
 	}
 
 	/* Complain if we (somehow) got out of sync */
-	WARN_ON_ONCE(drvdata->mode == CS_MODE_DISABLED);
+	WARN_ON_ONCE(local_read(&csdev->mode) == CS_MODE_DISABLED);
 	tmc_etb_disable_hw(drvdata);
 	/* Dissociate from monitored process. */
 	drvdata->pid = -1;
-	drvdata->mode = CS_MODE_DISABLED;
+	local_set(&csdev->mode, CS_MODE_DISABLED);
 
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
@@ -374,7 +374,7 @@ static int tmc_enable_etf_link(struct coresight_device *csdev,
 	if (atomic_read(&csdev->refcnt) == 0) {
 		ret = tmc_etf_enable_hw(drvdata);
 		if (!ret) {
-			drvdata->mode = CS_MODE_SYSFS;
+			local_set(&csdev->mode, CS_MODE_SYSFS);
 			first_enable = true;
 		}
 	}
@@ -403,7 +403,7 @@ static void tmc_disable_etf_link(struct coresight_device *csdev,
 
 	if (atomic_dec_return(&csdev->refcnt) == 0) {
 		tmc_etf_disable_hw(drvdata);
-		drvdata->mode = CS_MODE_DISABLED;
+		local_set(&csdev->mode, CS_MODE_DISABLED);
 		last_disable = true;
 	}
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
@@ -483,7 +483,7 @@ static unsigned long tmc_update_etf_buffer(struct coresight_device *csdev,
 		return 0;
 
 	/* This shouldn't happen */
-	if (WARN_ON_ONCE(drvdata->mode != CS_MODE_PERF))
+	if (WARN_ON_ONCE(local_read(&csdev->mode) != CS_MODE_PERF))
 		return 0;
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
@@ -629,7 +629,7 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
 	}
 
 	/* Don't interfere if operated from Perf */
-	if (drvdata->mode == CS_MODE_PERF) {
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_PERF) {
 		ret = -EINVAL;
 		goto out;
 	}
@@ -641,7 +641,7 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
 	}
 
 	/* Disable the TMC if need be */
-	if (drvdata->mode == CS_MODE_SYSFS) {
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_SYSFS) {
 		/* There is no point in reading a TMC in HW FIFO mode */
 		mode = readl_relaxed(drvdata->base + TMC_MODE);
 		if (mode != TMC_MODE_CIRCULAR_BUFFER) {
@@ -673,7 +673,7 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
 	/* Re-enable the TMC if need be */
-	if (drvdata->mode == CS_MODE_SYSFS) {
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_SYSFS) {
 		/* There is no point in reading a TMC in HW FIFO mode */
 		mode = readl_relaxed(drvdata->base + TMC_MODE);
 		if (mode != TMC_MODE_CIRCULAR_BUFFER) {
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index af02ba5d5f15..3dc989d4fcab 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1143,7 +1143,7 @@ static void __tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
 	 * When operating in sysFS mode the content of the buffer needs to be
 	 * read before the TMC is disabled.
 	 */
-	if (drvdata->mode == CS_MODE_SYSFS)
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_SYSFS)
 		tmc_etr_sync_sysfs_buf(drvdata);
 
 	tmc_disable_hw(drvdata);
@@ -1189,7 +1189,7 @@ static struct etr_buf *tmc_etr_get_sysfs_buffer(struct coresight_device *csdev)
 		spin_lock_irqsave(&drvdata->spinlock, flags);
 	}
 
-	if (drvdata->reading || drvdata->mode == CS_MODE_PERF) {
+	if (drvdata->reading || local_read(&csdev->mode) == CS_MODE_PERF) {
 		ret = -EBUSY;
 		goto out;
 	}
@@ -1230,14 +1230,14 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
 	 * sink is already enabled no memory is needed and the HW need not be
 	 * touched, even if the buffer size has changed.
 	 */
-	if (drvdata->mode == CS_MODE_SYSFS) {
+	if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
 		atomic_inc(&csdev->refcnt);
 		goto out;
 	}
 
 	ret = tmc_etr_enable_hw(drvdata, sysfs_buf);
 	if (!ret) {
-		drvdata->mode = CS_MODE_SYSFS;
+		local_set(&csdev->mode, CS_MODE_SYSFS);
 		atomic_inc(&csdev->refcnt);
 	}
 
@@ -1652,7 +1652,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 	 /* Don't use this sink if it is already claimed by sysFS */
-	if (drvdata->mode == CS_MODE_SYSFS) {
+	if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
 		rc = -EBUSY;
 		goto unlock_out;
 	}
@@ -1684,7 +1684,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
 	if (!rc) {
 		/* Associate with monitored process. */
 		drvdata->pid = pid;
-		drvdata->mode = CS_MODE_PERF;
+		local_set(&csdev->mode, CS_MODE_PERF);
 		drvdata->perf_buf = etr_perf->etr_buf;
 		atomic_inc(&csdev->refcnt);
 	}
@@ -1725,11 +1725,11 @@ static int tmc_disable_etr_sink(struct coresight_device *csdev)
 	}
 
 	/* Complain if we (somehow) got out of sync */
-	WARN_ON_ONCE(drvdata->mode == CS_MODE_DISABLED);
+	WARN_ON_ONCE(local_read(&csdev->mode) == CS_MODE_DISABLED);
 	tmc_etr_disable_hw(drvdata);
 	/* Dissociate from monitored process. */
 	drvdata->pid = -1;
-	drvdata->mode = CS_MODE_DISABLED;
+	local_set(&csdev->mode, CS_MODE_DISABLED);
 	/* Reset perf specific data */
 	drvdata->perf_buf = NULL;
 
@@ -1777,7 +1777,7 @@ int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
 	}
 
 	/* Disable the TMC if we are trying to read from a running session. */
-	if (drvdata->mode == CS_MODE_SYSFS)
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_SYSFS)
 		__tmc_etr_disable_hw(drvdata);
 
 	drvdata->reading = true;
@@ -1799,7 +1799,7 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
 	/* RE-enable the TMC if need be */
-	if (drvdata->mode == CS_MODE_SYSFS) {
+	if (local_read(&drvdata->csdev->mode) == CS_MODE_SYSFS) {
 		/*
 		 * The trace run will continue with the same allocated trace
 		 * buffer. Since the tracer is still enabled drvdata::buf can't
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index 8dcb426ac3e7..cef979c897e6 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -178,7 +178,6 @@ struct etr_buf {
  * @size:	trace buffer size for this TMC (common for all modes).
  * @max_burst_size: The maximum burst size that can be initiated by
  *		TMC-ETR on AXI bus.
- * @mode:	how this TMC is being used.
  * @config_type: TMC variant, must be of type @tmc_config_type.
  * @memwidth:	width of the memory interface databus, in bytes.
  * @trigger_cntr: amount of words to store after a trigger.
@@ -203,7 +202,6 @@ struct tmc_drvdata {
 	u32			len;
 	u32			size;
 	u32			max_burst_size;
-	u32			mode;
 	enum tmc_config_type	config_type;
 	enum tmc_mem_intf_width	memwidth;
 	u32			trigger_cntr;
diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.c b/drivers/hwtracing/coresight/ultrasoc-smb.c
index 10e886455b8b..1a8c64645b92 100644
--- a/drivers/hwtracing/coresight/ultrasoc-smb.c
+++ b/drivers/hwtracing/coresight/ultrasoc-smb.c
@@ -207,11 +207,11 @@ static void smb_enable_sysfs(struct coresight_device *csdev)
 {
 	struct smb_drv_data *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	if (drvdata->mode != CS_MODE_DISABLED)
+	if (local_read(&csdev->mode) != CS_MODE_DISABLED)
 		return;
 
 	smb_enable_hw(drvdata);
-	drvdata->mode = CS_MODE_SYSFS;
+	local_set(&csdev->mode, CS_MODE_SYSFS);
 }
 
 static int smb_enable_perf(struct coresight_device *csdev, void *data)
@@ -234,7 +234,7 @@ static int smb_enable_perf(struct coresight_device *csdev, void *data)
 	if (drvdata->pid == -1) {
 		smb_enable_hw(drvdata);
 		drvdata->pid = pid;
-		drvdata->mode = CS_MODE_PERF;
+		local_set(&csdev->mode, CS_MODE_PERF);
 	}
 
 	return 0;
@@ -253,7 +253,8 @@ static int smb_enable(struct coresight_device *csdev, enum cs_mode mode,
 		return -EBUSY;
 
 	/* Do nothing, the SMB is already enabled as other mode */
-	if (drvdata->mode != CS_MODE_DISABLED && drvdata->mode != mode)
+	if (local_read(&csdev->mode) != CS_MODE_DISABLED &&
+	    local_read(&csdev->mode) != mode)
 		return -EBUSY;
 
 	switch (mode) {
@@ -289,13 +290,13 @@ static int smb_disable(struct coresight_device *csdev)
 		return -EBUSY;
 
 	/* Complain if we (somehow) got out of sync */
-	WARN_ON_ONCE(drvdata->mode == CS_MODE_DISABLED);
+	WARN_ON_ONCE(local_read(&csdev->mode) == CS_MODE_DISABLED);
 
 	smb_disable_hw(drvdata);
 
 	/* Dissociate from the target process. */
 	drvdata->pid = -1;
-	drvdata->mode = CS_MODE_DISABLED;
+	local_set(&csdev->mode, CS_MODE_DISABLED);
 	dev_dbg(&csdev->dev, "Ultrasoc SMB disabled\n");
 
 	return 0;
diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.h b/drivers/hwtracing/coresight/ultrasoc-smb.h
index 82a44c14a882..a91d39cfccb8 100644
--- a/drivers/hwtracing/coresight/ultrasoc-smb.h
+++ b/drivers/hwtracing/coresight/ultrasoc-smb.h
@@ -109,7 +109,6 @@ struct smb_data_buffer {
  * @reading:	Synchronise user space access to SMB buffer.
  * @pid:	Process ID of the process being monitored by the
  *		session that is using this component.
- * @mode:	How this SMB is being used, perf mode or sysfs mode.
  */
 struct smb_drv_data {
 	void __iomem *base;
@@ -119,7 +118,6 @@ struct smb_drv_data {
 	spinlock_t spinlock;
 	bool reading;
 	pid_t pid;
-	enum cs_mode mode;
 };
 
 #endif
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 65131bfbd904..ba817f563ff7 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -226,6 +226,11 @@ struct coresight_sysfs_link {
  *		by @coresight_ops.
  * @access:	Device i/o access abstraction for this device.
  * @dev:	The device entity associated to this component.
+ * @mode:	This tracer's mode, i.e sysFS, Perf or disabled. This is
+ *		actually an 'enum cs_mode', but is stored in an atomic type.
+ *		This is always accessed through local_read() and local_set(),
+ *		but wherever it's done from within the Coresight device's lock,
+ *		a non-atomic read would also work.
  * @refcnt:	keep track of what is in use.
  * @orphan:	true if the component has connections that haven't been linked.
  * @enable:	'true' if component is currently part of an active path.
@@ -252,6 +257,7 @@ struct coresight_device {
 	const struct coresight_ops *ops;
 	struct csdev_access access;
 	struct device dev;
+	local_t	mode;
 	atomic_t refcnt;
 	bool orphan;
 	bool enable;
-- 
2.34.1



From james.clark at arm.com  Tue Dec 12 07:54:02 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:54:02 +0000
Subject: [PATCH 5/8] coresight: Remove the 'enable' field.
In-Reply-To: <20231212155407.1429121-1-james.clark@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
Message-ID: <20231212155407.1429121-6-james.clark@arm.com>

'enable', which probably should have been 'enabled', is only ever read
in the core code in relation to controlling sources, and specifically
only sources in sysfs mode. Confusingly it's not labelled as such and
relying on it can be a source of bugs like the one fixed by
commit 078dbba3f0c9 ("coresight: Fix crash when Perf and sysfs modes are
used concurrently").

Most importantly, it can only be used when the coresight_mutex is held
which is only done when enabling and disabling paths in sysfs mode, and
not Perf mode. So to prevent its usage spreading and leaking out to
other devices, remove it.

It's use is equivalent to checking if the mode is currently sysfs, as
due to the coresight_mutex lock, mode == CS_MODE_SYSFS can only become
true or untrue when that lock is held, and when mode == CS_MODE_SYSFS
the device is both enabled and in sysfs mode.

The one place it was used outside of the core code is in TPDA, but that
pattern is more appropriately represented using refcounts inside the
device's own spinlock.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/hwtracing/coresight/coresight-core.c | 86 +++++++-------------
 drivers/hwtracing/coresight/coresight-tpda.c | 12 ++-
 include/linux/coresight.h                    |  2 -
 3 files changed, 38 insertions(+), 62 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index ab226441e5f4..1d0bd1586590 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -279,29 +279,18 @@ EXPORT_SYMBOL_GPL(coresight_add_helper);
 static int coresight_enable_sink(struct coresight_device *csdev,
 				 enum cs_mode mode, void *data)
 {
-	int ret = sink_ops(csdev)->enable(csdev, mode, data);
-
-	if (ret)
-		return ret;
-
-	csdev->enable = true;
-
-	return 0;
+	return sink_ops(csdev)->enable(csdev, mode, data);
 }
 
 static void coresight_disable_sink(struct coresight_device *csdev)
 {
-	int ret = sink_ops(csdev)->disable(csdev);
-	if (ret)
-		return;
-	csdev->enable = false;
+	sink_ops(csdev)->disable(csdev);
 }
 
 static int coresight_enable_link(struct coresight_device *csdev,
 				 struct coresight_device *parent,
 				 struct coresight_device *child)
 {
-	int ret = 0;
 	int link_subtype;
 	struct coresight_connection *inconn, *outconn;
 
@@ -317,19 +306,13 @@ static int coresight_enable_link(struct coresight_device *csdev,
 	if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_SPLIT && IS_ERR(outconn))
 		return PTR_ERR(outconn);
 
-	ret = link_ops(csdev)->enable(csdev, inconn, outconn);
-	if (!ret)
-		csdev->enable = true;
-
-	return ret;
+	return link_ops(csdev)->enable(csdev, inconn, outconn);
 }
 
 static void coresight_disable_link(struct coresight_device *csdev,
 				   struct coresight_device *parent,
 				   struct coresight_device *child)
 {
-	int i;
-	int link_subtype;
 	struct coresight_connection *inconn, *outconn;
 
 	if (!parent || !child)
@@ -337,26 +320,8 @@ static void coresight_disable_link(struct coresight_device *csdev,
 
 	inconn = coresight_find_out_connection(parent, csdev);
 	outconn = coresight_find_out_connection(csdev, child);
-	link_subtype = csdev->subtype.link_subtype;
 
 	link_ops(csdev)->disable(csdev, inconn, outconn);
-
-	if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG) {
-		for (i = 0; i < csdev->pdata->nr_inconns; i++)
-			if (atomic_read(&csdev->pdata->in_conns[i]->dest_refcnt) !=
-			    0)
-				return;
-	} else if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_SPLIT) {
-		for (i = 0; i < csdev->pdata->nr_outconns; i++)
-			if (atomic_read(&csdev->pdata->out_conns[i]->src_refcnt) !=
-			    0)
-				return;
-	} else {
-		if (atomic_read(&csdev->refcnt) != 0)
-			return;
-	}
-
-	csdev->enable = false;
 }
 
 int coresight_enable_source(struct coresight_device *csdev, enum cs_mode mode,
@@ -364,11 +329,16 @@ int coresight_enable_source(struct coresight_device *csdev, enum cs_mode mode,
 {
 	int ret;
 
-	if (!csdev->enable) {
+	/*
+	 * Comparison with CS_MODE_SYSFS works without taking any device
+	 * specific spinlock because the truthyness of that comparison can only
+	 * change with coresight_mutex held, which we already have here.
+	 */
+	lockdep_assert_held(&coresight_mutex);
+	if (local_read(&csdev->mode) != CS_MODE_SYSFS) {
 		ret = source_ops(csdev)->enable(csdev, data, mode);
 		if (ret)
 			return ret;
-		csdev->enable = true;
 	}
 
 	atomic_inc(&csdev->refcnt);
@@ -385,22 +355,12 @@ static bool coresight_is_helper(struct coresight_device *csdev)
 static int coresight_enable_helper(struct coresight_device *csdev,
 				   enum cs_mode mode, void *data)
 {
-	int ret = helper_ops(csdev)->enable(csdev, mode, data);
-
-	if (ret)
-		return ret;
-
-	csdev->enable = true;
-	return 0;
+	return helper_ops(csdev)->enable(csdev, mode, data);
 }
 
 static void coresight_disable_helper(struct coresight_device *csdev)
 {
-	int ret = helper_ops(csdev)->disable(csdev, NULL);
-
-	if (ret)
-		return;
-	csdev->enable = false;
+	helper_ops(csdev)->disable(csdev, NULL);
 }
 
 static void coresight_disable_helpers(struct coresight_device *csdev)
@@ -445,11 +405,15 @@ EXPORT_SYMBOL_GPL(coresight_disable_source);
 static bool coresight_disable_source_sysfs(struct coresight_device *csdev,
 					   void *data)
 {
+	lockdep_assert_held(&coresight_mutex);
+	if (local_read(&csdev->mode) != CS_MODE_SYSFS)
+		return false;
+
 	if (atomic_dec_return(&csdev->refcnt) == 0) {
 		coresight_disable_source(csdev, data);
-		csdev->enable = false;
+		return true;
 	}
-	return !csdev->enable;
+	return false;
 }
 
 /*
@@ -1097,7 +1061,13 @@ int coresight_enable(struct coresight_device *csdev)
 	if (ret)
 		goto out;
 
-	if (csdev->enable) {
+	/*
+	 * mode == SYSFS implies that it's already enabled. Don't look at the
+	 * refcount to determine this because we don't claim the source until
+	 * coresight_enable_source() so can still race with Perf mode which
+	 * doesn't hold coresight_mutex.
+	 */
+	if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
 		/*
 		 * There could be multiple applications driving the software
 		 * source. So keep the refcount for each such user when the
@@ -1183,7 +1153,7 @@ void coresight_disable(struct coresight_device *csdev)
 	if (ret)
 		goto out;
 
-	if (!csdev->enable || !coresight_disable_source_sysfs(csdev, NULL))
+	if (!coresight_disable_source_sysfs(csdev, NULL))
 		goto out;
 
 	switch (csdev->subtype.source_subtype) {
@@ -1249,7 +1219,9 @@ static ssize_t enable_source_show(struct device *dev,
 {
 	struct coresight_device *csdev = to_coresight_device(dev);
 
-	return scnprintf(buf, PAGE_SIZE, "%u\n", csdev->enable);
+	guard(mutex)(&coresight_mutex);
+	return scnprintf(buf, PAGE_SIZE, "%u\n",
+			 local_read(&csdev->mode) == CS_MODE_SYSFS);
 }
 
 static ssize_t enable_source_store(struct device *dev,
diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c
index 5f82737c37bb..65c70995ab00 100644
--- a/drivers/hwtracing/coresight/coresight-tpda.c
+++ b/drivers/hwtracing/coresight/coresight-tpda.c
@@ -148,7 +148,11 @@ static int __tpda_enable(struct tpda_drvdata *drvdata, int port)
 
 	CS_UNLOCK(drvdata->base);
 
-	if (!drvdata->csdev->enable)
+	/*
+	 * Only do pre-port enable for first port that calls enable when the
+	 * device's main refcount is still 0
+	 */
+	if (!atomic_read(&drvdata->csdev->refcnt))
 		tpda_enable_pre_port(drvdata);
 
 	ret = tpda_enable_port(drvdata, port);
@@ -169,6 +173,7 @@ static int tpda_enable(struct coresight_device *csdev,
 		ret = __tpda_enable(drvdata, in->dest_port);
 		if (!ret) {
 			atomic_inc(&in->dest_refcnt);
+			atomic_inc(&csdev->refcnt);
 			dev_dbg(drvdata->dev, "TPDA inport %d enabled.\n", in->dest_port);
 		}
 	}
@@ -197,9 +202,10 @@ static void tpda_disable(struct coresight_device *csdev,
 	struct tpda_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
 	spin_lock(&drvdata->spinlock);
-	if (atomic_dec_return(&in->dest_refcnt) == 0)
+	if (atomic_dec_return(&in->dest_refcnt) == 0) {
 		__tpda_disable(drvdata, in->dest_port);
-
+		atomic_dec(&csdev->refcnt);
+	}
 	spin_unlock(&drvdata->spinlock);
 
 	dev_dbg(drvdata->dev, "TPDA inport %d disabled\n", in->dest_port);
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index ba817f563ff7..46e6667f72ce 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -233,7 +233,6 @@ struct coresight_sysfs_link {
  *		a non-atomic read would also work.
  * @refcnt:	keep track of what is in use.
  * @orphan:	true if the component has connections that haven't been linked.
- * @enable:	'true' if component is currently part of an active path.
  * @sysfs_sink_activated: 'true' when a sink has been selected for use via sysfs
  *		by writing a 1 to the 'enable_sink' file.  A sink can be
  *		activated but not yet enabled.  Enabling for a _sink_ happens
@@ -260,7 +259,6 @@ struct coresight_device {
 	local_t	mode;
 	atomic_t refcnt;
 	bool orphan;
-	bool enable;
 	/* sink specific fields */
 	bool sysfs_sink_activated;
 	struct dev_ext_attribute *ea;
-- 
2.34.1



From james.clark at arm.com  Tue Dec 12 07:54:03 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:54:03 +0000
Subject: [PATCH 6/8] coresight: Move all sysfs code to sysfs file
In-Reply-To: <20231212155407.1429121-1-james.clark@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
Message-ID: <20231212155407.1429121-7-james.clark@arm.com>

At the moment the core file contains both sysfs functionality and
core functionality, while the Perf mode is in a separate file in
coresight-etm-perf.c

Many of the functions have ambiguous names like
coresight_enable_source() which actually only work in relation to the
sysfs mode. To avoid further confusion, move everything that isn't core
functionality into the sysfs file and append  _sysfs to the ambiguous
functions.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/hwtracing/coresight/coresight-core.c  | 394 +-----------------
 .../coresight/coresight-etm3x-core.c          |   4 +-
 .../coresight/coresight-etm4x-core.c          |   4 +-
 drivers/hwtracing/coresight/coresight-priv.h  |   5 +-
 drivers/hwtracing/coresight/coresight-stm.c   |   4 +-
 drivers/hwtracing/coresight/coresight-sysfs.c | 390 +++++++++++++++++
 include/linux/coresight.h                     |   8 +-
 7 files changed, 407 insertions(+), 402 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 1d0bd1586590..eb72cdd1a273 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -9,7 +9,6 @@
 #include <linux/types.h>
 #include <linux/device.h>
 #include <linux/io.h>
-#include <linux/idr.h>
 #include <linux/err.h>
 #include <linux/export.h>
 #include <linux/slab.h>
@@ -25,15 +24,12 @@
 #include "coresight-priv.h"
 #include "coresight-syscfg.h"
 
-static DEFINE_MUTEX(coresight_mutex);
-static DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
-
 /*
- * Use IDR to map the hash of the source's device name
- * to the pointer of path for the source. The idr is for
- * the sources which aren't associated with CPU.
+ * Mutex used to lock all sysfs enable and disable actions and loading and
+ * unloading devices by the Coresight core.
  */
-static DEFINE_IDR(path_idr);
+DEFINE_MUTEX(coresight_mutex);
+static DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
 
 /**
  * struct coresight_node - elements of a path, from source to sink
@@ -45,12 +41,6 @@ struct coresight_node {
 	struct list_head link;
 };
 
-/*
- * When operating Coresight drivers from the sysFS interface, only a single
- * path can exist from a tracer (associated to a CPU) to a sink.
- */
-static DEFINE_PER_CPU(struct list_head *, tracer_path);
-
 /*
  * When losing synchronisation a new barrier packet needs to be inserted at the
  * beginning of the data collected in a buffer.  That way the decoder knows that
@@ -61,34 +51,6 @@ EXPORT_SYMBOL_GPL(coresight_barrier_pkt);
 
 static const struct cti_assoc_op *cti_assoc_ops;
 
-ssize_t coresight_simple_show_pair(struct device *_dev,
-			      struct device_attribute *attr, char *buf)
-{
-	struct coresight_device *csdev = container_of(_dev, struct coresight_device, dev);
-	struct cs_pair_attribute *cs_attr = container_of(attr, struct cs_pair_attribute, attr);
-	u64 val;
-
-	pm_runtime_get_sync(_dev->parent);
-	val = csdev_access_relaxed_read_pair(&csdev->access, cs_attr->lo_off, cs_attr->hi_off);
-	pm_runtime_put_sync(_dev->parent);
-	return sysfs_emit(buf, "0x%llx\n", val);
-}
-EXPORT_SYMBOL_GPL(coresight_simple_show_pair);
-
-ssize_t coresight_simple_show32(struct device *_dev,
-			      struct device_attribute *attr, char *buf)
-{
-	struct coresight_device *csdev = container_of(_dev, struct coresight_device, dev);
-	struct cs_off_attribute *cs_attr = container_of(attr, struct cs_off_attribute, attr);
-	u64 val;
-
-	pm_runtime_get_sync(_dev->parent);
-	val = csdev_access_relaxed_read32(&csdev->access, cs_attr->off);
-	pm_runtime_put_sync(_dev->parent);
-	return sysfs_emit(buf, "0x%llx\n", val);
-}
-EXPORT_SYMBOL_GPL(coresight_simple_show32);
-
 void coresight_set_cti_ops(const struct cti_assoc_op *cti_op)
 {
 	cti_assoc_ops = cti_op;
@@ -324,29 +286,6 @@ static void coresight_disable_link(struct coresight_device *csdev,
 	link_ops(csdev)->disable(csdev, inconn, outconn);
 }
 
-int coresight_enable_source(struct coresight_device *csdev, enum cs_mode mode,
-			    void *data)
-{
-	int ret;
-
-	/*
-	 * Comparison with CS_MODE_SYSFS works without taking any device
-	 * specific spinlock because the truthyness of that comparison can only
-	 * change with coresight_mutex held, which we already have here.
-	 */
-	lockdep_assert_held(&coresight_mutex);
-	if (local_read(&csdev->mode) != CS_MODE_SYSFS) {
-		ret = source_ops(csdev)->enable(csdev, data, mode);
-		if (ret)
-			return ret;
-	}
-
-	atomic_inc(&csdev->refcnt);
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(coresight_enable_source);
-
 static bool coresight_is_helper(struct coresight_device *csdev)
 {
 	return csdev->type == CORESIGHT_DEV_TYPE_HELPER;
@@ -392,30 +331,6 @@ void coresight_disable_source(struct coresight_device *csdev, void *data)
 }
 EXPORT_SYMBOL_GPL(coresight_disable_source);
 
-/**
- *  coresight_disable_source_sysfs - Drop the reference count by 1 and disable
- *  the device if there are no users left.
- *
- *  @csdev: The coresight device to disable
- *  @data: Opaque data to pass on to the disable function of the source device.
- *         For example in perf mode this is a pointer to the struct perf_event.
- *
- *  Returns true if the device has been disabled.
- */
-static bool coresight_disable_source_sysfs(struct coresight_device *csdev,
-					   void *data)
-{
-	lockdep_assert_held(&coresight_mutex);
-	if (local_read(&csdev->mode) != CS_MODE_SYSFS)
-		return false;
-
-	if (atomic_dec_return(&csdev->refcnt) == 0) {
-		coresight_disable_source(csdev, data);
-		return true;
-	}
-	return false;
-}
-
 /*
  * coresight_disable_path_from : Disable components in the given path beyond
  * @nd in the list. If @nd is NULL, all the components, except the SOURCE are
@@ -572,39 +487,6 @@ struct coresight_device *coresight_get_sink(struct list_head *path)
 	return csdev;
 }
 
-/**
- * coresight_find_activated_sysfs_sink - returns the first sink activated via
- * sysfs using connection based search starting from the source reference.
- *
- * @csdev: Coresight source device reference
- */
-static struct coresight_device *
-coresight_find_activated_sysfs_sink(struct coresight_device *csdev)
-{
-	int i;
-	struct coresight_device *sink = NULL;
-
-	if ((csdev->type == CORESIGHT_DEV_TYPE_SINK ||
-	     csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) &&
-	     csdev->sysfs_sink_activated)
-		return csdev;
-
-	/*
-	 * Recursively explore each port found on this element.
-	 */
-	for (i = 0; i < csdev->pdata->nr_outconns; i++) {
-		struct coresight_device *child_dev;
-
-		child_dev = csdev->pdata->out_conns[i]->dest_dev;
-		if (child_dev)
-			sink = coresight_find_activated_sysfs_sink(child_dev);
-		if (sink)
-			return sink;
-	}
-
-	return NULL;
-}
-
 static int coresight_sink_by_id(struct device *dev, const void *data)
 {
 	struct coresight_device *csdev = to_coresight_device(dev);
@@ -1015,274 +897,6 @@ static void coresight_clear_default_sink(struct coresight_device *csdev)
 	}
 }
 
-/** coresight_validate_source - make sure a source has the right credentials
- *  @csdev:	the device structure for a source.
- *  @function:	the function this was called from.
- *
- * Assumes the coresight_mutex is held.
- */
-static int coresight_validate_source(struct coresight_device *csdev,
-				     const char *function)
-{
-	u32 type, subtype;
-
-	type = csdev->type;
-	subtype = csdev->subtype.source_subtype;
-
-	if (type != CORESIGHT_DEV_TYPE_SOURCE) {
-		dev_err(&csdev->dev, "wrong device type in %s\n", function);
-		return -EINVAL;
-	}
-
-	if (subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_PROC &&
-	    subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE &&
-	    subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM &&
-	    subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS) {
-		dev_err(&csdev->dev, "wrong device subtype in %s\n", function);
-		return -EINVAL;
-	}
-
-	return 0;
-}
-
-int coresight_enable(struct coresight_device *csdev)
-{
-	int cpu, ret = 0;
-	struct coresight_device *sink;
-	struct list_head *path;
-	enum coresight_dev_subtype_source subtype;
-	u32 hash;
-
-	subtype = csdev->subtype.source_subtype;
-
-	mutex_lock(&coresight_mutex);
-
-	ret = coresight_validate_source(csdev, __func__);
-	if (ret)
-		goto out;
-
-	/*
-	 * mode == SYSFS implies that it's already enabled. Don't look at the
-	 * refcount to determine this because we don't claim the source until
-	 * coresight_enable_source() so can still race with Perf mode which
-	 * doesn't hold coresight_mutex.
-	 */
-	if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
-		/*
-		 * There could be multiple applications driving the software
-		 * source. So keep the refcount for each such user when the
-		 * source is already enabled.
-		 */
-		if (subtype == CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE)
-			atomic_inc(&csdev->refcnt);
-		goto out;
-	}
-
-	sink = coresight_find_activated_sysfs_sink(csdev);
-	if (!sink) {
-		ret = -EINVAL;
-		goto out;
-	}
-
-	path = coresight_build_path(csdev, sink);
-	if (IS_ERR(path)) {
-		pr_err("building path(s) failed\n");
-		ret = PTR_ERR(path);
-		goto out;
-	}
-
-	ret = coresight_enable_path(path, CS_MODE_SYSFS, NULL);
-	if (ret)
-		goto err_path;
-
-	ret = coresight_enable_source(csdev, CS_MODE_SYSFS, NULL);
-	if (ret)
-		goto err_source;
-
-	switch (subtype) {
-	case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
-		/*
-		 * When working from sysFS it is important to keep track
-		 * of the paths that were created so that they can be
-		 * undone in 'coresight_disable()'.  Since there can only
-		 * be a single session per tracer (when working from sysFS)
-		 * a per-cpu variable will do just fine.
-		 */
-		cpu = source_ops(csdev)->cpu_id(csdev);
-		per_cpu(tracer_path, cpu) = path;
-		break;
-	case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:
-	case CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM:
-	case CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS:
-		/*
-		 * Use the hash of source's device name as ID
-		 * and map the ID to the pointer of the path.
-		 */
-		hash = hashlen_hash(hashlen_string(NULL, dev_name(&csdev->dev)));
-		ret = idr_alloc_u32(&path_idr, path, &hash, hash, GFP_KERNEL);
-		if (ret)
-			goto err_source;
-		break;
-	default:
-		/* We can't be here */
-		break;
-	}
-
-out:
-	mutex_unlock(&coresight_mutex);
-	return ret;
-
-err_source:
-	coresight_disable_path(path);
-
-err_path:
-	coresight_release_path(path);
-	goto out;
-}
-EXPORT_SYMBOL_GPL(coresight_enable);
-
-void coresight_disable(struct coresight_device *csdev)
-{
-	int cpu, ret;
-	struct list_head *path = NULL;
-	u32 hash;
-
-	mutex_lock(&coresight_mutex);
-
-	ret = coresight_validate_source(csdev, __func__);
-	if (ret)
-		goto out;
-
-	if (!coresight_disable_source_sysfs(csdev, NULL))
-		goto out;
-
-	switch (csdev->subtype.source_subtype) {
-	case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
-		cpu = source_ops(csdev)->cpu_id(csdev);
-		path = per_cpu(tracer_path, cpu);
-		per_cpu(tracer_path, cpu) = NULL;
-		break;
-	case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:
-	case CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM:
-	case CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS:
-		hash = hashlen_hash(hashlen_string(NULL, dev_name(&csdev->dev)));
-		/* Find the path by the hash. */
-		path = idr_find(&path_idr, hash);
-		if (path == NULL) {
-			pr_err("Path is not found for %s\n", dev_name(&csdev->dev));
-			goto out;
-		}
-		idr_remove(&path_idr, hash);
-		break;
-	default:
-		/* We can't be here */
-		break;
-	}
-
-	coresight_disable_path(path);
-	coresight_release_path(path);
-
-out:
-	mutex_unlock(&coresight_mutex);
-}
-EXPORT_SYMBOL_GPL(coresight_disable);
-
-static ssize_t enable_sink_show(struct device *dev,
-				struct device_attribute *attr, char *buf)
-{
-	struct coresight_device *csdev = to_coresight_device(dev);
-
-	return scnprintf(buf, PAGE_SIZE, "%u\n", csdev->sysfs_sink_activated);
-}
-
-static ssize_t enable_sink_store(struct device *dev,
-				 struct device_attribute *attr,
-				 const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct coresight_device *csdev = to_coresight_device(dev);
-
-	ret = kstrtoul(buf, 10, &val);
-	if (ret)
-		return ret;
-
-	csdev->sysfs_sink_activated = !!val;
-
-	return size;
-
-}
-static DEVICE_ATTR_RW(enable_sink);
-
-static ssize_t enable_source_show(struct device *dev,
-				  struct device_attribute *attr, char *buf)
-{
-	struct coresight_device *csdev = to_coresight_device(dev);
-
-	guard(mutex)(&coresight_mutex);
-	return scnprintf(buf, PAGE_SIZE, "%u\n",
-			 local_read(&csdev->mode) == CS_MODE_SYSFS);
-}
-
-static ssize_t enable_source_store(struct device *dev,
-				   struct device_attribute *attr,
-				   const char *buf, size_t size)
-{
-	int ret = 0;
-	unsigned long val;
-	struct coresight_device *csdev = to_coresight_device(dev);
-
-	ret = kstrtoul(buf, 10, &val);
-	if (ret)
-		return ret;
-
-	if (val) {
-		ret = coresight_enable(csdev);
-		if (ret)
-			return ret;
-	} else {
-		coresight_disable(csdev);
-	}
-
-	return size;
-}
-static DEVICE_ATTR_RW(enable_source);
-
-static struct attribute *coresight_sink_attrs[] = {
-	&dev_attr_enable_sink.attr,
-	NULL,
-};
-ATTRIBUTE_GROUPS(coresight_sink);
-
-static struct attribute *coresight_source_attrs[] = {
-	&dev_attr_enable_source.attr,
-	NULL,
-};
-ATTRIBUTE_GROUPS(coresight_source);
-
-static struct device_type coresight_dev_type[] = {
-	{
-		.name = "sink",
-		.groups = coresight_sink_groups,
-	},
-	{
-		.name = "link",
-	},
-	{
-		.name = "linksink",
-		.groups = coresight_sink_groups,
-	},
-	{
-		.name = "source",
-		.groups = coresight_source_groups,
-	},
-	{
-		.name = "helper",
-	}
-};
-/* Ensure the enum matches the names and groups */
-static_assert(ARRAY_SIZE(coresight_dev_type) == CORESIGHT_DEV_TYPE_MAX);
-
 static void coresight_device_release(struct device *dev)
 {
 	struct coresight_device *csdev = to_coresight_device(dev);
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c b/drivers/hwtracing/coresight/coresight-etm3x-core.c
index 29f62dfac673..a8be115636f0 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-core.c
@@ -714,7 +714,7 @@ static int etm_online_cpu(unsigned int cpu)
 		return 0;
 
 	if (etmdrvdata[cpu]->boot_enable && !etmdrvdata[cpu]->sticky_enable)
-		coresight_enable(etmdrvdata[cpu]->csdev);
+		coresight_enable_sysfs(etmdrvdata[cpu]->csdev);
 	return 0;
 }
 
@@ -924,7 +924,7 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
 	dev_info(&drvdata->csdev->dev,
 		 "%s initialized\n", (char *)coresight_get_uci_data(id));
 	if (boot_enable) {
-		coresight_enable(drvdata->csdev);
+		coresight_enable_sysfs(drvdata->csdev);
 		drvdata->boot_enable = true;
 	}
 
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index ce1995a2827f..cbb4ac8be133 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -1650,7 +1650,7 @@ static int etm4_online_cpu(unsigned int cpu)
 		return etm4_probe_cpu(cpu);
 
 	if (etmdrvdata[cpu]->boot_enable && !etmdrvdata[cpu]->sticky_enable)
-		coresight_enable(etmdrvdata[cpu]->csdev);
+		coresight_enable_sysfs(etmdrvdata[cpu]->csdev);
 	return 0;
 }
 
@@ -2098,7 +2098,7 @@ static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg)
 		 drvdata->cpu, type_name, major, minor);
 
 	if (boot_enable) {
-		coresight_enable(drvdata->csdev);
+		coresight_enable_sysfs(drvdata->csdev);
 		drvdata->boot_enable = true;
 	}
 
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index ced5be05a527..eb365236f9a9 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -12,6 +12,9 @@
 #include <linux/coresight.h>
 #include <linux/pm_runtime.h>
 
+extern struct mutex coresight_mutex;
+extern struct device_type coresight_dev_type[];
+
 /*
  * Coresight management registers (0xf00-0xfcc)
  * 0xfa0 - 0xfa4: Management	registers in PFTv1.0
@@ -229,8 +232,6 @@ void coresight_add_helper(struct coresight_device *csdev,
 
 void coresight_set_percpu_sink(int cpu, struct coresight_device *csdev);
 struct coresight_device *coresight_get_percpu_sink(int cpu);
-int coresight_enable_source(struct coresight_device *csdev, enum cs_mode mode,
-			    void *data);
 void coresight_disable_source(struct coresight_device *csdev, void *data);
 
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index 190ba569b05a..af9b21224246 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -332,7 +332,7 @@ static int stm_generic_link(struct stm_data *stm_data,
 	if (!drvdata || !drvdata->csdev)
 		return -EINVAL;
 
-	return coresight_enable(drvdata->csdev);
+	return coresight_enable_sysfs(drvdata->csdev);
 }
 
 static void stm_generic_unlink(struct stm_data *stm_data,
@@ -343,7 +343,7 @@ static void stm_generic_unlink(struct stm_data *stm_data,
 	if (!drvdata || !drvdata->csdev)
 		return;
 
-	coresight_disable(drvdata->csdev);
+	coresight_disable_sysfs(drvdata->csdev);
 }
 
 static phys_addr_t
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index dd78e9fcfc4d..92cdf8139f23 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -5,10 +5,400 @@
  */
 
 #include <linux/device.h>
+#include <linux/idr.h>
 #include <linux/kernel.h>
 
 #include "coresight-priv.h"
 
+/*
+ * Use IDR to map the hash of the source's device name
+ * to the pointer of path for the source. The idr is for
+ * the sources which aren't associated with CPU.
+ */
+static DEFINE_IDR(path_idr);
+
+/*
+ * When operating Coresight drivers from the sysFS interface, only a single
+ * path can exist from a tracer (associated to a CPU) to a sink.
+ */
+static DEFINE_PER_CPU(struct list_head *, tracer_path);
+
+ssize_t coresight_simple_show_pair(struct device *_dev,
+			      struct device_attribute *attr, char *buf)
+{
+	struct coresight_device *csdev = container_of(_dev, struct coresight_device, dev);
+	struct cs_pair_attribute *cs_attr = container_of(attr, struct cs_pair_attribute, attr);
+	u64 val;
+
+	pm_runtime_get_sync(_dev->parent);
+	val = csdev_access_relaxed_read_pair(&csdev->access, cs_attr->lo_off, cs_attr->hi_off);
+	pm_runtime_put_sync(_dev->parent);
+	return sysfs_emit(buf, "0x%llx\n", val);
+}
+EXPORT_SYMBOL_GPL(coresight_simple_show_pair);
+
+ssize_t coresight_simple_show32(struct device *_dev,
+			      struct device_attribute *attr, char *buf)
+{
+	struct coresight_device *csdev = container_of(_dev, struct coresight_device, dev);
+	struct cs_off_attribute *cs_attr = container_of(attr, struct cs_off_attribute, attr);
+	u64 val;
+
+	pm_runtime_get_sync(_dev->parent);
+	val = csdev_access_relaxed_read32(&csdev->access, cs_attr->off);
+	pm_runtime_put_sync(_dev->parent);
+	return sysfs_emit(buf, "0x%llx\n", val);
+}
+EXPORT_SYMBOL_GPL(coresight_simple_show32);
+
+static int coresight_enable_source_sysfs(struct coresight_device *csdev,
+					 enum cs_mode mode, void *data)
+{
+	int ret;
+
+	/*
+	 * Comparison with CS_MODE_SYSFS works without taking any device
+	 * specific spinlock because the truthyness of that comparison can only
+	 * change with coresight_mutex held, which we already have here.
+	 */
+	lockdep_assert_held(&coresight_mutex);
+	if (local_read(&csdev->mode) != CS_MODE_SYSFS) {
+		ret = source_ops(csdev)->enable(csdev, data, mode);
+		if (ret)
+			return ret;
+	}
+
+	atomic_inc(&csdev->refcnt);
+
+	return 0;
+}
+
+/**
+ *  coresight_disable_source_sysfs - Drop the reference count by 1 and disable
+ *  the device if there are no users left.
+ *
+ *  @csdev: The coresight device to disable
+ *  @data: Opaque data to pass on to the disable function of the source device.
+ *         For example in perf mode this is a pointer to the struct perf_event.
+ *
+ *  Returns true if the device has been disabled.
+ */
+static bool coresight_disable_source_sysfs(struct coresight_device *csdev,
+					   void *data)
+{
+	lockdep_assert_held(&coresight_mutex);
+	if (local_read(&csdev->mode) != CS_MODE_SYSFS)
+		return false;
+
+	if (atomic_dec_return(&csdev->refcnt) == 0) {
+		coresight_disable_source(csdev, data);
+		return true;
+	}
+	return false;
+}
+
+/**
+ * coresight_find_activated_sysfs_sink - returns the first sink activated via
+ * sysfs using connection based search starting from the source reference.
+ *
+ * @csdev: Coresight source device reference
+ */
+static struct coresight_device *
+coresight_find_activated_sysfs_sink(struct coresight_device *csdev)
+{
+	int i;
+	struct coresight_device *sink = NULL;
+
+	if ((csdev->type == CORESIGHT_DEV_TYPE_SINK ||
+	     csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) &&
+	     csdev->sysfs_sink_activated)
+		return csdev;
+
+	/*
+	 * Recursively explore each port found on this element.
+	 */
+	for (i = 0; i < csdev->pdata->nr_outconns; i++) {
+		struct coresight_device *child_dev;
+
+		child_dev = csdev->pdata->out_conns[i]->dest_dev;
+		if (child_dev)
+			sink = coresight_find_activated_sysfs_sink(child_dev);
+		if (sink)
+			return sink;
+	}
+
+	return NULL;
+}
+
+/** coresight_validate_source - make sure a source has the right credentials to
+ *  be used via sysfs.
+ *  @csdev:	the device structure for a source.
+ *  @function:	the function this was called from.
+ *
+ * Assumes the coresight_mutex is held.
+ */
+static int coresight_validate_source_sysfs(struct coresight_device *csdev,
+				     const char *function)
+{
+	u32 type, subtype;
+
+	type = csdev->type;
+	subtype = csdev->subtype.source_subtype;
+
+	if (type != CORESIGHT_DEV_TYPE_SOURCE) {
+		dev_err(&csdev->dev, "wrong device type in %s\n", function);
+		return -EINVAL;
+	}
+
+	if (subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_PROC &&
+	    subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE &&
+	    subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM &&
+	    subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS) {
+		dev_err(&csdev->dev, "wrong device subtype in %s\n", function);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+int coresight_enable_sysfs(struct coresight_device *csdev)
+{
+	int cpu, ret = 0;
+	struct coresight_device *sink;
+	struct list_head *path;
+	enum coresight_dev_subtype_source subtype;
+	u32 hash;
+
+	subtype = csdev->subtype.source_subtype;
+
+	mutex_lock(&coresight_mutex);
+
+	ret = coresight_validate_source_sysfs(csdev, __func__);
+	if (ret)
+		goto out;
+
+	/*
+	 * mode == SYSFS implies that it's already enabled. Don't look at the
+	 * refcount to determine this because we don't claim the source until
+	 * coresight_enable_source() so can still race with Perf mode which
+	 * doesn't hold coresight_mutex.
+	 */
+	if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
+		/*
+		 * There could be multiple applications driving the software
+		 * source. So keep the refcount for each such user when the
+		 * source is already enabled.
+		 */
+		if (subtype == CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE)
+			atomic_inc(&csdev->refcnt);
+		goto out;
+	}
+
+	sink = coresight_find_activated_sysfs_sink(csdev);
+	if (!sink) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	path = coresight_build_path(csdev, sink);
+	if (IS_ERR(path)) {
+		pr_err("building path(s) failed\n");
+		ret = PTR_ERR(path);
+		goto out;
+	}
+
+	ret = coresight_enable_path(path, CS_MODE_SYSFS, NULL);
+	if (ret)
+		goto err_path;
+
+	ret = coresight_enable_source_sysfs(csdev, CS_MODE_SYSFS, NULL);
+	if (ret)
+		goto err_source;
+
+	switch (subtype) {
+	case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
+		/*
+		 * When working from sysFS it is important to keep track
+		 * of the paths that were created so that they can be
+		 * undone in 'coresight_disable()'.  Since there can only
+		 * be a single session per tracer (when working from sysFS)
+		 * a per-cpu variable will do just fine.
+		 */
+		cpu = source_ops(csdev)->cpu_id(csdev);
+		per_cpu(tracer_path, cpu) = path;
+		break;
+	case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:
+	case CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM:
+	case CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS:
+		/*
+		 * Use the hash of source's device name as ID
+		 * and map the ID to the pointer of the path.
+		 */
+		hash = hashlen_hash(hashlen_string(NULL, dev_name(&csdev->dev)));
+		ret = idr_alloc_u32(&path_idr, path, &hash, hash, GFP_KERNEL);
+		if (ret)
+			goto err_source;
+		break;
+	default:
+		/* We can't be here */
+		break;
+	}
+
+out:
+	mutex_unlock(&coresight_mutex);
+	return ret;
+
+err_source:
+	coresight_disable_path(path);
+
+err_path:
+	coresight_release_path(path);
+	goto out;
+}
+EXPORT_SYMBOL_GPL(coresight_enable_sysfs);
+
+void coresight_disable_sysfs(struct coresight_device *csdev)
+{
+	int cpu, ret;
+	struct list_head *path = NULL;
+	u32 hash;
+
+	mutex_lock(&coresight_mutex);
+
+	ret = coresight_validate_source_sysfs(csdev, __func__);
+	if (ret)
+		goto out;
+
+	if (!coresight_disable_source_sysfs(csdev, NULL))
+		goto out;
+
+	switch (csdev->subtype.source_subtype) {
+	case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
+		cpu = source_ops(csdev)->cpu_id(csdev);
+		path = per_cpu(tracer_path, cpu);
+		per_cpu(tracer_path, cpu) = NULL;
+		break;
+	case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:
+	case CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM:
+	case CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS:
+		hash = hashlen_hash(hashlen_string(NULL, dev_name(&csdev->dev)));
+		/* Find the path by the hash. */
+		path = idr_find(&path_idr, hash);
+		if (path == NULL) {
+			pr_err("Path is not found for %s\n", dev_name(&csdev->dev));
+			goto out;
+		}
+		idr_remove(&path_idr, hash);
+		break;
+	default:
+		/* We can't be here */
+		break;
+	}
+
+	coresight_disable_path(path);
+	coresight_release_path(path);
+
+out:
+	mutex_unlock(&coresight_mutex);
+}
+EXPORT_SYMBOL_GPL(coresight_disable_sysfs);
+
+static ssize_t enable_sink_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct coresight_device *csdev = to_coresight_device(dev);
+
+	return scnprintf(buf, PAGE_SIZE, "%u\n", csdev->sysfs_sink_activated);
+}
+
+static ssize_t enable_sink_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct coresight_device *csdev = to_coresight_device(dev);
+
+	ret = kstrtoul(buf, 10, &val);
+	if (ret)
+		return ret;
+
+	csdev->sysfs_sink_activated = !!val;
+
+	return size;
+
+}
+static DEVICE_ATTR_RW(enable_sink);
+
+static ssize_t enable_source_show(struct device *dev,
+				  struct device_attribute *attr, char *buf)
+{
+	struct coresight_device *csdev = to_coresight_device(dev);
+
+	guard(mutex)(&coresight_mutex);
+	return scnprintf(buf, PAGE_SIZE, "%u\n",
+			 local_read(&csdev->mode) == CS_MODE_SYSFS);
+}
+
+static ssize_t enable_source_store(struct device *dev,
+				   struct device_attribute *attr,
+				   const char *buf, size_t size)
+{
+	int ret = 0;
+	unsigned long val;
+	struct coresight_device *csdev = to_coresight_device(dev);
+
+	ret = kstrtoul(buf, 10, &val);
+	if (ret)
+		return ret;
+
+	if (val) {
+		ret = coresight_enable_sysfs(csdev);
+		if (ret)
+			return ret;
+	} else {
+		coresight_disable_sysfs(csdev);
+	}
+
+	return size;
+}
+static DEVICE_ATTR_RW(enable_source);
+
+static struct attribute *coresight_sink_attrs[] = {
+	&dev_attr_enable_sink.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(coresight_sink);
+
+static struct attribute *coresight_source_attrs[] = {
+	&dev_attr_enable_source.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(coresight_source);
+
+struct device_type coresight_dev_type[] = {
+	{
+		.name = "sink",
+		.groups = coresight_sink_groups,
+	},
+	{
+		.name = "link",
+	},
+	{
+		.name = "linksink",
+		.groups = coresight_sink_groups,
+	},
+	{
+		.name = "source",
+		.groups = coresight_source_groups,
+	},
+	{
+		.name = "helper",
+	}
+};
+/* Ensure the enum matches the names and groups */
+static_assert(ARRAY_SIZE(coresight_dev_type) == CORESIGHT_DEV_TYPE_MAX);
+
 /*
  * Connections group - links attribute.
  * Count of created links between coresight components in the group.
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 46e6667f72ce..e8dd0df98881 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -578,8 +578,8 @@ static inline bool coresight_is_percpu_sink(struct coresight_device *csdev)
 extern struct coresight_device *
 coresight_register(struct coresight_desc *desc);
 extern void coresight_unregister(struct coresight_device *csdev);
-extern int coresight_enable(struct coresight_device *csdev);
-extern void coresight_disable(struct coresight_device *csdev);
+extern int coresight_enable_sysfs(struct coresight_device *csdev);
+extern void coresight_disable_sysfs(struct coresight_device *csdev);
 extern int coresight_timeout(struct csdev_access *csa, u32 offset,
 			     int position, int value);
 
@@ -609,8 +609,8 @@ static inline struct coresight_device *
 coresight_register(struct coresight_desc *desc) { return NULL; }
 static inline void coresight_unregister(struct coresight_device *csdev) {}
 static inline int
-coresight_enable(struct coresight_device *csdev) { return -ENOSYS; }
-static inline void coresight_disable(struct coresight_device *csdev) {}
+coresight_enable_sysfs(struct coresight_device *csdev) { return -ENOSYS; }
+static inline void coresight_disable_sysfs(struct coresight_device *csdev) {}
 
 static inline int coresight_timeout(struct csdev_access *csa, u32 offset,
 				    int position, int value)
-- 
2.34.1



From james.clark at arm.com  Tue Dec 12 07:54:04 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:54:04 +0000
Subject: [PATCH 7/8] coresight: Remove atomic type from refcnt
In-Reply-To: <20231212155407.1429121-1-james.clark@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
Message-ID: <20231212155407.1429121-8-james.clark@arm.com>

Refcnt is only ever accessed from either inside the coresight_mutex, or
the device's spinlock, making the atomic type and atomic_dec_return()
calls confusing and unnecessary. The only point of synchronisation
outside of these two types of locks is already done with a compare and
swap on 'mode', which a comment has been added for.

There was one instance of refcnt being used outside of a lock in TPIU,
but that can easily be fixed by making it the same as all the other
devices and adding a spinlock. Potentially in the future all the
refcounting and locking can be moved up into the core code, and all the
mostly duplicate code from the individual devices can be removed.

Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 11 +++++-----
 drivers/hwtracing/coresight/coresight-sysfs.c |  7 ++++---
 .../hwtracing/coresight/coresight-tmc-etf.c   | 20 ++++++++++---------
 .../hwtracing/coresight/coresight-tmc-etr.c   | 13 ++++++------
 drivers/hwtracing/coresight/coresight-tpda.c  |  7 ++++---
 drivers/hwtracing/coresight/coresight-tpiu.c  | 14 +++++++++++--
 drivers/hwtracing/coresight/ultrasoc-smb.c    |  9 +++++----
 include/linux/coresight.h                     | 13 +++++++++---
 8 files changed, 59 insertions(+), 35 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 08e5bba862db..5f2bb95955b7 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -161,7 +161,7 @@ static int etb_enable_sysfs(struct coresight_device *csdev)
 		local_set(&csdev->mode, CS_MODE_SYSFS);
 	}
 
-	atomic_inc(&csdev->refcnt);
+	csdev->refcnt++;
 out:
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 	return ret;
@@ -197,7 +197,7 @@ static int etb_enable_perf(struct coresight_device *csdev, void *data)
 	 * use for this session.
 	 */
 	if (drvdata->pid == pid) {
-		atomic_inc(&csdev->refcnt);
+		csdev->refcnt++;
 		goto out;
 	}
 
@@ -215,7 +215,7 @@ static int etb_enable_perf(struct coresight_device *csdev, void *data)
 		/* Associate with monitored process. */
 		drvdata->pid = pid;
 		local_set(&drvdata->csdev->mode, CS_MODE_PERF);
-		atomic_inc(&csdev->refcnt);
+		csdev->refcnt++;
 	}
 
 out:
@@ -354,7 +354,8 @@ static int etb_disable(struct coresight_device *csdev)
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
-	if (atomic_dec_return(&csdev->refcnt)) {
+	csdev->refcnt--;
+	if (csdev->refcnt) {
 		spin_unlock_irqrestore(&drvdata->spinlock, flags);
 		return -EBUSY;
 	}
@@ -445,7 +446,7 @@ static unsigned long etb_update_buffer(struct coresight_device *csdev,
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
 	/* Don't do anything if another tracer is using this sink */
-	if (atomic_read(&csdev->refcnt) != 1)
+	if (csdev->refcnt != 1)
 		goto out;
 
 	__etb_disable_hw(drvdata);
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index 92cdf8139f23..5992f2c2200a 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -68,7 +68,7 @@ static int coresight_enable_source_sysfs(struct coresight_device *csdev,
 			return ret;
 	}
 
-	atomic_inc(&csdev->refcnt);
+	csdev->refcnt++;
 
 	return 0;
 }
@@ -90,7 +90,8 @@ static bool coresight_disable_source_sysfs(struct coresight_device *csdev,
 	if (local_read(&csdev->mode) != CS_MODE_SYSFS)
 		return false;
 
-	if (atomic_dec_return(&csdev->refcnt) == 0) {
+	csdev->refcnt--;
+	if (csdev->refcnt == 0) {
 		coresight_disable_source(csdev, data);
 		return true;
 	}
@@ -190,7 +191,7 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
 		 * source is already enabled.
 		 */
 		if (subtype == CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE)
-			atomic_inc(&csdev->refcnt);
+			csdev->refcnt++;
 		goto out;
 	}
 
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 2a7e516052a2..f3281c958a57 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -206,7 +206,7 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev)
 	 * touched.
 	 */
 	if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
-		atomic_inc(&csdev->refcnt);
+		csdev->refcnt++;
 		goto out;
 	}
 
@@ -229,7 +229,7 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev)
 	ret = tmc_etb_enable_hw(drvdata);
 	if (!ret) {
 		local_set(&csdev->mode, CS_MODE_SYSFS);
-		atomic_inc(&csdev->refcnt);
+		csdev->refcnt++;
 	} else {
 		/* Free up the buffer if we failed to enable */
 		used = false;
@@ -284,7 +284,7 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, void *data)
 		 * use for this session.
 		 */
 		if (drvdata->pid == pid) {
-			atomic_inc(&csdev->refcnt);
+			csdev->refcnt++;
 			break;
 		}
 
@@ -293,7 +293,7 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, void *data)
 			/* Associate with monitored process. */
 			drvdata->pid = pid;
 			local_set(&csdev->mode, CS_MODE_PERF);
-			atomic_inc(&csdev->refcnt);
+			csdev->refcnt++;
 		}
 	} while (0);
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
@@ -338,7 +338,8 @@ static int tmc_disable_etf_sink(struct coresight_device *csdev)
 		return -EBUSY;
 	}
 
-	if (atomic_dec_return(&csdev->refcnt)) {
+	csdev->refcnt--;
+	if (csdev->refcnt) {
 		spin_unlock_irqrestore(&drvdata->spinlock, flags);
 		return -EBUSY;
 	}
@@ -371,7 +372,7 @@ static int tmc_enable_etf_link(struct coresight_device *csdev,
 		return -EBUSY;
 	}
 
-	if (atomic_read(&csdev->refcnt) == 0) {
+	if (csdev->refcnt == 0) {
 		ret = tmc_etf_enable_hw(drvdata);
 		if (!ret) {
 			local_set(&csdev->mode, CS_MODE_SYSFS);
@@ -379,7 +380,7 @@ static int tmc_enable_etf_link(struct coresight_device *csdev,
 		}
 	}
 	if (!ret)
-		atomic_inc(&csdev->refcnt);
+		csdev->refcnt++;
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
 	if (first_enable)
@@ -401,7 +402,8 @@ static void tmc_disable_etf_link(struct coresight_device *csdev,
 		return;
 	}
 
-	if (atomic_dec_return(&csdev->refcnt) == 0) {
+	csdev->refcnt--;
+	if (csdev->refcnt == 0) {
 		tmc_etf_disable_hw(drvdata);
 		local_set(&csdev->mode, CS_MODE_DISABLED);
 		last_disable = true;
@@ -489,7 +491,7 @@ static unsigned long tmc_update_etf_buffer(struct coresight_device *csdev,
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
 	/* Don't do anything if another tracer is using this sink */
-	if (atomic_read(&csdev->refcnt) != 1)
+	if (csdev->refcnt != 1)
 		goto out;
 
 	CS_UNLOCK(drvdata->base);
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 3dc989d4fcab..88a0fc375b4d 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1231,14 +1231,14 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
 	 * touched, even if the buffer size has changed.
 	 */
 	if (local_read(&csdev->mode) == CS_MODE_SYSFS) {
-		atomic_inc(&csdev->refcnt);
+		csdev->refcnt++;
 		goto out;
 	}
 
 	ret = tmc_etr_enable_hw(drvdata, sysfs_buf);
 	if (!ret) {
 		local_set(&csdev->mode, CS_MODE_SYSFS);
-		atomic_inc(&csdev->refcnt);
+		csdev->refcnt++;
 	}
 
 out:
@@ -1564,7 +1564,7 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
 	/* Don't do anything if another tracer is using this sink */
-	if (atomic_read(&csdev->refcnt) != 1) {
+	if (csdev->refcnt != 1) {
 		spin_unlock_irqrestore(&drvdata->spinlock, flags);
 		goto out;
 	}
@@ -1676,7 +1676,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
 	 * use for this session.
 	 */
 	if (drvdata->pid == pid) {
-		atomic_inc(&csdev->refcnt);
+		csdev->refcnt++;
 		goto unlock_out;
 	}
 
@@ -1686,7 +1686,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
 		drvdata->pid = pid;
 		local_set(&csdev->mode, CS_MODE_PERF);
 		drvdata->perf_buf = etr_perf->etr_buf;
-		atomic_inc(&csdev->refcnt);
+		csdev->refcnt++;
 	}
 
 unlock_out:
@@ -1719,7 +1719,8 @@ static int tmc_disable_etr_sink(struct coresight_device *csdev)
 		return -EBUSY;
 	}
 
-	if (atomic_dec_return(&csdev->refcnt)) {
+	csdev->refcnt--;
+	if (csdev->refcnt) {
 		spin_unlock_irqrestore(&drvdata->spinlock, flags);
 		return -EBUSY;
 	}
diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c
index 65c70995ab00..135a89654c4c 100644
--- a/drivers/hwtracing/coresight/coresight-tpda.c
+++ b/drivers/hwtracing/coresight/coresight-tpda.c
@@ -152,7 +152,8 @@ static int __tpda_enable(struct tpda_drvdata *drvdata, int port)
 	 * Only do pre-port enable for first port that calls enable when the
 	 * device's main refcount is still 0
 	 */
-	if (!atomic_read(&drvdata->csdev->refcnt))
+	lockdep_assert_held(&drvdata->spinlock);
+	if (!drvdata->csdev->refcnt)
 		tpda_enable_pre_port(drvdata);
 
 	ret = tpda_enable_port(drvdata, port);
@@ -173,7 +174,7 @@ static int tpda_enable(struct coresight_device *csdev,
 		ret = __tpda_enable(drvdata, in->dest_port);
 		if (!ret) {
 			atomic_inc(&in->dest_refcnt);
-			atomic_inc(&csdev->refcnt);
+			csdev->refcnt++;
 			dev_dbg(drvdata->dev, "TPDA inport %d enabled.\n", in->dest_port);
 		}
 	}
@@ -204,7 +205,7 @@ static void tpda_disable(struct coresight_device *csdev,
 	spin_lock(&drvdata->spinlock);
 	if (atomic_dec_return(&in->dest_refcnt) == 0) {
 		__tpda_disable(drvdata, in->dest_port);
-		atomic_dec(&csdev->refcnt);
+		csdev->refcnt--;
 	}
 	spin_unlock(&drvdata->spinlock);
 
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 59eac93fd6bb..c23a6b9b41fe 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -58,6 +58,7 @@ struct tpiu_drvdata {
 	void __iomem		*base;
 	struct clk		*atclk;
 	struct coresight_device	*csdev;
+	spinlock_t		spinlock;
 };
 
 static void tpiu_enable_hw(struct csdev_access *csa)
@@ -72,8 +73,11 @@ static void tpiu_enable_hw(struct csdev_access *csa)
 static int tpiu_enable(struct coresight_device *csdev, enum cs_mode mode,
 		       void *__unused)
 {
+	struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	guard(spinlock)(&drvdata->spinlock);
 	tpiu_enable_hw(&csdev->access);
-	atomic_inc(&csdev->refcnt);
+	csdev->refcnt++;
 	dev_dbg(&csdev->dev, "TPIU enabled\n");
 	return 0;
 }
@@ -96,7 +100,11 @@ static void tpiu_disable_hw(struct csdev_access *csa)
 
 static int tpiu_disable(struct coresight_device *csdev)
 {
-	if (atomic_dec_return(&csdev->refcnt))
+	struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	guard(spinlock)(&drvdata->spinlock);
+	csdev->refcnt--;
+	if (csdev->refcnt)
 		return -EBUSY;
 
 	tpiu_disable_hw(&csdev->access);
@@ -132,6 +140,8 @@ static int tpiu_probe(struct amba_device *adev, const struct amba_id *id)
 	if (!drvdata)
 		return -ENOMEM;
 
+	spin_lock_init(&drvdata->spinlock);
+
 	drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
 	if (!IS_ERR(drvdata->atclk)) {
 		ret = clk_prepare_enable(drvdata->atclk);
diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.c b/drivers/hwtracing/coresight/ultrasoc-smb.c
index 1a8c64645b92..1146584a1745 100644
--- a/drivers/hwtracing/coresight/ultrasoc-smb.c
+++ b/drivers/hwtracing/coresight/ultrasoc-smb.c
@@ -103,7 +103,7 @@ static int smb_open(struct inode *inode, struct file *file)
 	if (drvdata->reading)
 		return -EBUSY;
 
-	if (atomic_read(&drvdata->csdev->refcnt))
+	if (drvdata->csdev->refcnt)
 		return -EBUSY;
 
 	smb_update_data_size(drvdata);
@@ -271,7 +271,7 @@ static int smb_enable(struct coresight_device *csdev, enum cs_mode mode,
 	if (ret)
 		return ret;
 
-	atomic_inc(&csdev->refcnt);
+	csdev->refcnt++;
 	dev_dbg(&csdev->dev, "Ultrasoc SMB enabled\n");
 
 	return ret;
@@ -286,7 +286,8 @@ static int smb_disable(struct coresight_device *csdev)
 	if (drvdata->reading)
 		return -EBUSY;
 
-	if (atomic_dec_return(&csdev->refcnt))
+	csdev->refcnt--;
+	if (csdev->refcnt)
 		return -EBUSY;
 
 	/* Complain if we (somehow) got out of sync */
@@ -381,7 +382,7 @@ static unsigned long smb_update_buffer(struct coresight_device *csdev,
 	guard(spinlock)(&drvdata->spinlock);
 
 	/* Don't do anything if another tracer is using this sink. */
-	if (atomic_read(&csdev->refcnt) != 1)
+	if (csdev->refcnt != 1)
 		return 0;
 
 	smb_disable_hw(drvdata);
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index e8dd0df98881..4400d554a16b 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -230,8 +230,15 @@ struct coresight_sysfs_link {
  *		actually an 'enum cs_mode', but is stored in an atomic type.
  *		This is always accessed through local_read() and local_set(),
  *		but wherever it's done from within the Coresight device's lock,
- *		a non-atomic read would also work.
- * @refcnt:	keep track of what is in use.
+ *		a non-atomic read would also work. This is the main point of
+ *		synchronisation between code happening inside the sysfs mode's
+ *		coresight_mutex and outside when running in Perf mode. A compare
+ *		and exchange swap is done to atomically claim one mode or the
+ *		other.
+ * @refcnt:	keep track of what is in use. Only access this outside of the
+ *		device's spinlock when the coresight_mutex held and mode ==
+ *		CS_MODE_SYSFS. Otherwise it must be accessed from inside the
+ *		spinlock.
  * @orphan:	true if the component has connections that haven't been linked.
  * @sysfs_sink_activated: 'true' when a sink has been selected for use via sysfs
  *		by writing a 1 to the 'enable_sink' file.  A sink can be
@@ -257,7 +264,7 @@ struct coresight_device {
 	struct csdev_access access;
 	struct device dev;
 	local_t	mode;
-	atomic_t refcnt;
+	int refcnt;
 	bool orphan;
 	/* sink specific fields */
 	bool sysfs_sink_activated;
-- 
2.34.1



From james.clark at arm.com  Tue Dec 12 07:54:05 2023
From: james.clark at arm.com (James Clark)
Date: Tue, 12 Dec 2023 15:54:05 +0000
Subject: [PATCH 8/8] coresight: Remove unused stubs
In-Reply-To: <20231212155407.1429121-1-james.clark@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
Message-ID: <20231212155407.1429121-9-james.clark@arm.com>

These are a bit annoying to keep up to date when the function signatures
change. But if CONFIG_CORESIGHT isn't enabled, then they're not used
anyway so just delete them.

Signed-off-by: James Clark <james.clark at arm.com>
---
 include/linux/coresight.h | 79 ---------------------------------------
 1 file changed, 79 deletions(-)

diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 4400d554a16b..c5be46d7f85c 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -391,8 +391,6 @@ struct coresight_ops {
 	const struct coresight_ops_helper *helper_ops;
 };
 
-#if IS_ENABLED(CONFIG_CORESIGHT)
-
 static inline u32 csdev_access_relaxed_read32(struct csdev_access *csa,
 					      u32 offset)
 {
@@ -611,83 +609,6 @@ void coresight_relaxed_write64(struct coresight_device *csdev,
 			       u64 val, u32 offset);
 void coresight_write64(struct coresight_device *csdev, u64 val, u32 offset);
 
-#else
-static inline struct coresight_device *
-coresight_register(struct coresight_desc *desc) { return NULL; }
-static inline void coresight_unregister(struct coresight_device *csdev) {}
-static inline int
-coresight_enable_sysfs(struct coresight_device *csdev) { return -ENOSYS; }
-static inline void coresight_disable_sysfs(struct coresight_device *csdev) {}
-
-static inline int coresight_timeout(struct csdev_access *csa, u32 offset,
-				    int position, int value)
-{
-	return 1;
-}
-
-static inline int coresight_claim_device_unlocked(struct coresight_device *csdev)
-{
-	return -EINVAL;
-}
-
-static inline int coresight_claim_device(struct coresight_device *csdev)
-{
-	return -EINVAL;
-}
-
-static inline void coresight_disclaim_device(struct coresight_device *csdev) {}
-static inline void coresight_disclaim_device_unlocked(struct coresight_device *csdev) {}
-
-static inline bool coresight_loses_context_with_cpu(struct device *dev)
-{
-	return false;
-}
-
-static inline u32 coresight_relaxed_read32(struct coresight_device *csdev, u32 offset)
-{
-	WARN_ON_ONCE(1);
-	return 0;
-}
-
-static inline u32 coresight_read32(struct coresight_device *csdev, u32 offset)
-{
-	WARN_ON_ONCE(1);
-	return 0;
-}
-
-static inline void coresight_write32(struct coresight_device *csdev, u32 val, u32 offset)
-{
-}
-
-static inline void coresight_relaxed_write32(struct coresight_device *csdev,
-					     u32 val, u32 offset)
-{
-}
-
-static inline u64 coresight_relaxed_read64(struct coresight_device *csdev,
-					   u32 offset)
-{
-	WARN_ON_ONCE(1);
-	return 0;
-}
-
-static inline u64 coresight_read64(struct coresight_device *csdev, u32 offset)
-{
-	WARN_ON_ONCE(1);
-	return 0;
-}
-
-static inline void coresight_relaxed_write64(struct coresight_device *csdev,
-					     u64 val, u32 offset)
-{
-}
-
-static inline void coresight_write64(struct coresight_device *csdev, u64 val, u32 offset)
-{
-}
-
-#endif		/* IS_ENABLED(CONFIG_CORESIGHT) */
-
 extern int coresight_get_cpu(struct device *dev);
 
 struct coresight_platform_data *coresight_get_platform_data(struct device *dev);
-- 
2.34.1



From claudiu.beznea at tuxon.dev  Tue Dec 12 07:56:27 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Tue, 12 Dec 2023 17:56:27 +0200
Subject: [PATCH] ARM: dts: microchip: sama5d27_som1_ek: Remove
 mmc-ddr-3_3v property from sdmmc0 node
In-Reply-To: <20231211070345.2792-1-mihai.sain@microchip.com>
References: <20231211070345.2792-1-mihai.sain@microchip.com>
Message-ID: <bae162b2-5f81-4275-a7bc-ac3f9886ff18@tuxon.dev>



On 11.12.2023 09:03, Mihai Sain wrote:
> On board the sdmmc0 interface is wired to a SD Card socket.
> According with mmc-controller bindings, the mmc-ddr-3_3v property
> is used for eMMC devices to enable high-speed DDR mode (3.3V I/O).
> Remove the mmc-ddr-3_3v property from sdmmc0 node.
> 
> Signed-off-by: Mihai Sain <mihai.sain at microchip.com>

Applied to at91-dt, thanks!

> ---
>  arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts
> index d0a6dbd377df..f3ffb8f01d8a 100644
> --- a/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts
> +++ b/arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts
> @@ -54,7 +54,6 @@ usb2: ehci at 500000 {
>  
>  		sdmmc0: sdio-host at a0000000 {
>  			bus-width = <8>;
> -			mmc-ddr-3_3v;
>  			pinctrl-names = "default";
>  			pinctrl-0 = <&pinctrl_sdmmc0_default>;
>  			status = "okay";


From u.kleine-koenig at pengutronix.de  Tue Dec 12 07:58:06 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 16:58:06 +0100
Subject: [PATCH v2] arm64: dts: imx8mq-kontron-pitx-imx8m: remove
 vqmmc-supply node
In-Reply-To: <CAEyMn7Y_ZsGQjKJtFn6zuqzRzUzf_ueSi7JWhjOX0zeDsBzM8w@mail.gmail.com>
References: <20210914072627.24173-1-heiko.thiery@gmail.com>
 <449f718706fd5af03190bdda986de37aa8fa14e3.camel@pengutronix.de>
 <79fb60ea9a002ea553a92ea08b28b866@walle.cc>
 <2dc72116ec935a5a5d7a1a176868b7af7ff3227c.camel@pengutronix.de>
 <9e3d52c297ed024594a1e610a5cf61b2@walle.cc>
 <CAEyMn7aYYkGZ1Eawd=yazdKeBuHVQc=3F7PnHSCSRyYCu=CJ9A@mail.gmail.com>
 <20231212134110.cijyajgwljkzovvo@pengutronix.de>
 <CAEyMn7Y_ZsGQjKJtFn6zuqzRzUzf_ueSi7JWhjOX0zeDsBzM8w@mail.gmail.com>
Message-ID: <20231212155806.yvjd5ozw2k7qex35@pengutronix.de>

Hello Heiko,

On Tue, Dec 12, 2023 at 02:50:04PM +0100, Heiko Thiery wrote:
> Am Di., 12. Dez. 2023 um 14:41 Uhr schrieb Uwe Kleine-K?nig <
> u.kleine-koenig at pengutronix.de>:
> > On Tue, Sep 14, 2021 at 11:37:04AM +0200, Heiko Thiery wrote:
> > > dependency between emmc and PMIC. Debian 11 unfortunately does not
> > > have a driver enabled for the PMIC used and therefore cannot
> > > initialize the emmc driver.
> >
> > Updating to Debian 12 should give you a kernel that supports the
> > pfuze100 driver. (But I guess you know that, because it was enabled by
> > someone named Heiko Thiery. :-)
> >
> Thanks for the hint!

I'm working on cleaning up my inbox and had old mails open without
noticing. I only noticed after sending out that the mail is 2 years old
already and I should have considered it done without a reply.

Sorry if my mail appeared sneaky.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/d5099ec8/attachment.sig>

From claudiu.beznea at tuxon.dev  Tue Dec 12 08:03:59 2023
From: claudiu.beznea at tuxon.dev (claudiu beznea)
Date: Tue, 12 Dec 2023 18:03:59 +0200
Subject: [PATCH v2] drivers: soc: atmel: Adjust defines to follow
 aphabetical order
In-Reply-To: <31d470f8-9f82-4c09-a6f9-dac528fda3bf@microchip.com>
References: <20231208194532.579893-1-Ryan.Wanner@microchip.com>
 <de0ddb41-8d78-45eb-bcb7-6d318bf154fd@tuxon.dev>
 <31d470f8-9f82-4c09-a6f9-dac528fda3bf@microchip.com>
Message-ID: <412d6500-7364-43b0-90a6-98e9c9e30e76@tuxon.dev>



On 11.12.2023 16:47, Ryan.Wanner at microchip.com wrote:
> On 12/9/23 05:50, claudiu beznea wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> Hi, Ryan,
>>
>> On 08.12.2023 21:45, Ryan.Wanner at microchip.com wrote:
>>> From: Ryan Wanner <Ryan.Wanner at microchip.com>
>>>
>>> Move the defines so that they are in aphabetical order based on SOC.
>>
>> s/aphabetical/alphabetical but maybe alphanumerical a better term.
>>
>> Could you please explain what level of alphabetical sort you wanted to
>> achieve? I see SAM9X60/SAMA7G5 b/w AT91SAM9X5_CIDR_MATCH and
>> AT91SAM9M11_EXID_MATCH or, e.g., AT91SAM9G35_EXID_MATCH after
>> AT91SAM9M10_EXID_MATCH.
> 
> I wanted to make the CIDR match in alphanumeric, for the EXID I wanted
> to keep them alphanumeric but keeping them in the original SOC grouping.

Even so, it looks to me that there is mixed approach in overall file.

>>
>>>
>>> Signed-off-by: Ryan Wanner <Ryan.Wanner at microchip.com>
>>> ---
>>> Changes from v1 -> v2:
>>> - Remove defines that are not yet in v6.7.
>>>
>>>  drivers/soc/atmel/soc.h | 38 +++++++++++++++++++-------------------
>>>  1 file changed, 19 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/soc/atmel/soc.h b/drivers/soc/atmel/soc.h
>>> index 7a9f47ce85fb..1f2af6f74160 100644
>>> --- a/drivers/soc/atmel/soc.h
>>> +++ b/drivers/soc/atmel/soc.h
>>> @@ -39,10 +39,10 @@ at91_soc_init(const struct at91_soc *socs);
>>>  #define AT91SAM9261_CIDR_MATCH               0x019703a0
>>>  #define AT91SAM9263_CIDR_MATCH               0x019607a0
>>>  #define AT91SAM9G20_CIDR_MATCH               0x019905a0
>>> -#define AT91SAM9RL64_CIDR_MATCH              0x019b03a0
>>>  #define AT91SAM9G45_CIDR_MATCH               0x019b05a0
>>> -#define AT91SAM9X5_CIDR_MATCH                0x019a05a0
>>>  #define AT91SAM9N12_CIDR_MATCH               0x019a07a0
>>> +#define AT91SAM9RL64_CIDR_MATCH              0x019b03a0
>>> +#define AT91SAM9X5_CIDR_MATCH                0x019a05a0
>>>  #define SAM9X60_CIDR_MATCH           0x019b35a0
>>>  #define SAMA7G5_CIDR_MATCH           0x00162100
>>>
>>> @@ -61,23 +61,15 @@ at91_soc_init(const struct at91_soc *socs);
>>>  #define AT91SAM9N12_EXID_MATCH               0x00000006
>>>  #define AT91SAM9CN11_EXID_MATCH              0x00000009
>>>
>>> +#define AT91SAM9XE128_CIDR_MATCH     0x329973a0
>>> +#define AT91SAM9XE256_CIDR_MATCH     0x329a93a0
>>> +#define AT91SAM9XE512_CIDR_MATCH     0x329aa3a0
>>> +
>>>  #define SAM9X60_EXID_MATCH           0x00000000
>>>  #define SAM9X60_D5M_EXID_MATCH               0x00000001
>>>  #define SAM9X60_D1G_EXID_MATCH               0x00000010
>>>  #define SAM9X60_D6K_EXID_MATCH               0x00000011
>>>
>>> -#define SAMA7G51_EXID_MATCH          0x3
>>> -#define SAMA7G52_EXID_MATCH          0x2
>>> -#define SAMA7G53_EXID_MATCH          0x1
>>> -#define SAMA7G54_EXID_MATCH          0x0
>>> -#define SAMA7G54_D1G_EXID_MATCH              0x00000018
>>> -#define SAMA7G54_D2G_EXID_MATCH              0x00000020
>>> -#define SAMA7G54_D4G_EXID_MATCH              0x00000028
>>> -
>>> -#define AT91SAM9XE128_CIDR_MATCH     0x329973a0
>>> -#define AT91SAM9XE256_CIDR_MATCH     0x329a93a0
>>> -#define AT91SAM9XE512_CIDR_MATCH     0x329aa3a0
>>> -
>>>  #define SAMA5D2_CIDR_MATCH           0x0a5c08c0
>>>  #define SAMA5D21CU_EXID_MATCH                0x0000005a
>>>  #define SAMA5D225C_D1M_EXID_MATCH    0x00000053
>>> @@ -113,6 +105,14 @@ at91_soc_init(const struct at91_soc *socs);
>>>  #define SAMA5D43_EXID_MATCH          0x00000003
>>>  #define SAMA5D44_EXID_MATCH          0x00000004
>>>
>>> +#define SAMA7G51_EXID_MATCH          0x3
>>> +#define SAMA7G52_EXID_MATCH          0x2
>>> +#define SAMA7G53_EXID_MATCH          0x1
>>> +#define SAMA7G54_EXID_MATCH          0x0
>>> +#define SAMA7G54_D1G_EXID_MATCH              0x00000018
>>> +#define SAMA7G54_D2G_EXID_MATCH              0x00000020
>>> +#define SAMA7G54_D4G_EXID_MATCH              0x00000028
>>> +
>>>  #define SAME70Q21_CIDR_MATCH         0x21020e00
>>>  #define SAME70Q21_EXID_MATCH         0x00000002
>>>  #define SAME70Q20_CIDR_MATCH         0x21020c00
>>> @@ -127,6 +127,11 @@ at91_soc_init(const struct at91_soc *socs);
>>>  #define SAMS70Q19_CIDR_MATCH         0x211d0a00
>>>  #define SAMS70Q19_EXID_MATCH         0x00000002
>>>
>>> +#define SAMV70Q20_CIDR_MATCH         0x21320c00
>>> +#define SAMV70Q20_EXID_MATCH         0x00000002
>>> +#define SAMV70Q19_CIDR_MATCH         0x213d0a00
>>> +#define SAMV70Q19_EXID_MATCH         0x00000002
>>> +
>>>  #define SAMV71Q21_CIDR_MATCH         0x21220e00
>>>  #define SAMV71Q21_EXID_MATCH         0x00000002
>>>  #define SAMV71Q20_CIDR_MATCH         0x21220c00
>>> @@ -134,9 +139,4 @@ at91_soc_init(const struct at91_soc *socs);
>>>  #define SAMV71Q19_CIDR_MATCH         0x212d0a00
>>>  #define SAMV71Q19_EXID_MATCH         0x00000002
>>>
>>> -#define SAMV70Q20_CIDR_MATCH         0x21320c00
>>> -#define SAMV70Q20_EXID_MATCH         0x00000002
>>> -#define SAMV70Q19_CIDR_MATCH         0x213d0a00
>>> -#define SAMV70Q19_EXID_MATCH         0x00000002
>>> -
>>>  #endif /* __AT91_SOC_H */
> 


From u.kleine-koenig at pengutronix.de  Tue Dec 12 08:08:38 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 17:08:38 +0100
Subject: [PATCH v8 5/6] pwm: bcm2835: Allow PWM driver to be used in
 atomic context
In-Reply-To: <e9e32c9789da3c90b5a2aa7d5a093120b76421fb.1702369869.git.sean@mess.org>
References: <cover.1702369869.git.sean@mess.org>
 <e9e32c9789da3c90b5a2aa7d5a093120b76421fb.1702369869.git.sean@mess.org>
Message-ID: <20231212160838.k4z4csy455a7qnje@pengutronix.de>

Hello Sean,

On Tue, Dec 12, 2023 at 08:34:04AM +0000, Sean Young wrote:
> @@ -169,6 +179,7 @@ static int bcm2835_pwm_suspend(struct device *dev)
>  {
>  	struct bcm2835_pwm *pc = dev_get_drvdata(dev);
>  
> +	clk_rate_exclusive_put(pc->clk);
>  	clk_disable_unprepare(pc->clk);

I thought this was the remove function, but that's suspend. Adding
clk_rate_exclusive_put() there is wrong.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/62e360c4/attachment.sig>

From florian.fainelli at broadcom.com  Tue Dec 12 08:11:41 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Tue, 12 Dec 2023 08:11:41 -0800
Subject: [PATCH v8 5/6] pwm: bcm2835: Allow PWM driver to be used in
 atomic context
In-Reply-To: <20231212160838.k4z4csy455a7qnje@pengutronix.de>
References: <cover.1702369869.git.sean@mess.org>
 <e9e32c9789da3c90b5a2aa7d5a093120b76421fb.1702369869.git.sean@mess.org>
 <20231212160838.k4z4csy455a7qnje@pengutronix.de>
Message-ID: <7b5da1f7-8dec-48b1-abf4-721fda18cbf4@broadcom.com>



On 12/12/2023 8:08 AM, Uwe Kleine-K?nig wrote:
> Hello Sean,
> 
> On Tue, Dec 12, 2023 at 08:34:04AM +0000, Sean Young wrote:
>> @@ -169,6 +179,7 @@ static int bcm2835_pwm_suspend(struct device *dev)
>>   {
>>   	struct bcm2835_pwm *pc = dev_get_drvdata(dev);
>>   
>> +	clk_rate_exclusive_put(pc->clk);
>>   	clk_disable_unprepare(pc->clk);
> 
> I thought this was the remove function, but that's suspend. Adding
> clk_rate_exclusive_put() there is wrong.

Oh yes I missed that somehow, good catch Uwe!
-- 
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/a83fd0f9/attachment-0001.p7s>

From afd at ti.com  Tue Dec 12 08:16:59 2023
From: afd at ti.com (Andrew Davis)
Date: Tue, 12 Dec 2023 10:16:59 -0600
Subject: [PATCH] soc: ti: k3-socinfo: Add JTAG ID for J722S
In-Reply-To: <20231212154238.3sn5fxpestaqacrc@defog>
References: <20231211132600.25289-1-vaishnav.a@ti.com>
 <81f90d13-da10-4a68-a0e7-95212f40b3e8@ti.com>
 <20231212154238.3sn5fxpestaqacrc@defog>
Message-ID: <6c331be3-350d-4840-acbd-144a65efa954@ti.com>

On 12/12/23 9:42 AM, Nishanth Menon wrote:
> On 09:19-20231212, Andrew Davis wrote:
>> On 12/11/23 7:26 AM, Vaishnav Achath wrote:
>>> Add JTAG ID info for the J722S SoC family to enable SoC detection.
>>>
>>> More details about this SoC can be found in the TRM:
>>> 	https://www.ti.com/lit/zip/sprujb3
>>>
>>> Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
>>> ---
>>
>> Simple enough,
>>
>> Reviewed-by: Andrew Davis <afd at ti.com>
>>
>> Although I do question our use of the J7x names. All of our parts here
>> also have a "Sitara AMxx" branding. For instance here we could call
>> this new device by its "AM67" name, then J784S4 renamed as AM69, etc.
>> Then we would have a consistent naming (internally we will have to deal
>> with the part name madness, but why expose that externally if we don't
>> have to).
> 
> J722S is a new die and the core part, what rebranding/spins happens to it is
> subject to mktg group, not going to hold this series with that.
> 

Never said to hold the series (I even gave my R-B), just a suggestion for
later. Or more important when we add the DTB and other names to be consistent
and use the correct part names and not always use the parent/die/family name.

Andrew


From patchwork-bot+bluetooth at kernel.org  Tue Dec 12 08:20:25 2023
From: patchwork-bot+bluetooth at kernel.org (patchwork-bot+bluetooth at kernel.org)
Date: Tue, 12 Dec 2023 16:20:25 +0000
Subject: [PATCH v2 0/3] Bluetooth: fix recv_buf() return value
In-Reply-To: <20231211164020.173253-1-francesco@dolcini.it>
References: <20231211164020.173253-1-francesco@dolcini.it>
Message-ID: <170239802557.22444.1717551799062581956.git-patchwork-notify@kernel.org>

Hello:

This series was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz at intel.com>:

On Mon, 11 Dec 2023 17:40:17 +0100 you wrote:
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> Serdev recv_buf() callback is supposed to return the amount of bytes consumed, therefore an int in between 0 and count.
> 
> Do not return negative number in case of issue, just print an error and return count. This fixes a WARN in ttyport_receive_buf().
> 
> In addition to that a small cleanup patch is added on btnxpuart to remove a useless assignment.
> 
> [...]

Here is the summary with links:
  - [v2,1/3] Bluetooth: btnxpuart: fix recv_buf() return value
    https://git.kernel.org/bluetooth/bluetooth-next/c/7954bbcdd7ea
  - [v2,2/3] Bluetooth: btmtkuart: fix recv_buf() return value
    https://git.kernel.org/bluetooth/bluetooth-next/c/687d2de93b11
  - [v2,3/3] Bluetooth: btnxpuart: remove useless assignment
    https://git.kernel.org/bluetooth/bluetooth-next/c/99f188d71731

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From conor at kernel.org  Tue Dec 12 08:21:38 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 16:21:38 +0000
Subject: [RFC PATCH net-next v3 1/8] dt-bindings: phy:
 mediatek,xfi-pextp: add new bindings
In-Reply-To: <b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel@makrotopia.org>
Message-ID: <20231212-renderer-strobe-2b46652cd6e7@spud>

On Tue, Dec 12, 2023 at 03:46:26AM +0000, Daniel Golle wrote:

> +  mediatek,usxgmii-performance-errata:
> +    $ref: /schemas/types.yaml#/definitions/flag
> +    description:
> +      USXGMII0 on MT7988 suffers from a performance problem in 10GBase-R
> +      mode which needs a work-around in the driver. The work-around is
> +      enabled using this flag.

Why do you need a property for this if you know that it is present on
the MT7988?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/d5298cbb/attachment.sig>

From andre.przywara at arm.com  Tue Dec 12 08:22:00 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 12 Dec 2023 16:22:00 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <20231212122835.10850-2-retpolanne@posteo.net>
References: <20231212122835.10850-2-retpolanne@posteo.net>
Message-ID: <20231212162200.10b3868b@donnerap.manchester.arm.com>

On Tue, 12 Dec 2023 12:28:30 +0000
Anne Macedo <retpolanne at posteo.net> wrote:

Hi Anne,

> Adds compatible values to mdio subnodes for Ethernet PHY representing
> Realtek 8211 PHY to Orange Pi One Plus.

So can you state why this would be needed? This is the RTL8211 ID,
right? Which should be autodetected via MDIO. Looking back in my inbox
you proposed this change before, for U-Boot, specifically, but I fail to
find a solution or explanation what really happens here. Two Renesas .dts
files have the same compatible, and the commit message talks about the
reset line there, is this related?

So can you please give some more background and explanation? That would be
part of a good commit message anyway ("why", not "what").

Cheers,
Andre

> Signed-off-by: Anne Macedo <retpolanne at posteo.net>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
> index 29a081e72..7248ab72f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
> @@ -37,7 +37,8 @@ &emac {
>  
>  &mdio {
>  	ext_rgmii_phy: ethernet-phy at 1 {
> -		compatible = "ethernet-phy-ieee802.3-c22";
> +		compatible = "ethernet-phy-id001c.c915",
> +			     "ethernet-phy-ieee802.3-c22";
>  		reg = <1>;
>  	};
>  };



From will at kernel.org  Tue Dec 12 08:23:53 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 16:23:53 +0000
Subject: [PATCH v3 04/19] iommu/arm-smmu-v3: Make STE programming
 independent of the callers
In-Reply-To: <4-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
References: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
Message-ID: <20231212162353.GA29871@willie-the-truck>

Hi Jason,

On Tue, Dec 05, 2023 at 03:14:36PM -0400, Jason Gunthorpe wrote:
> As the comment in arm_smmu_write_strtab_ent() explains, this routine has
> been limited to only work correctly in certain scenarios that the caller
> must ensure. Generally the caller must put the STE into ABORT or BYPASS
> before attempting to program it to something else.
> 
> The next patches/series are going to start removing some of this logic
> from the callers, and add more complex state combinations than currently.
> 
> Thus, consolidate all the complexity here. Callers do not have to care
> about what STE transition they are doing, this function will handle
> everything optimally.
> 
> Revise arm_smmu_write_strtab_ent() so it algorithmically computes the
> required programming sequence to avoid creating an incoherent 'torn' STE
> in the HW caches. The update algorithm follows the same design that the
> driver already uses: it is safe to change bits that HW doesn't currently
> use and then do a single 64 bit update, with sync's in between.
> 
> The basic idea is to express in a bitmask what bits the HW is actually
> using based on the V and CFG bits. Based on that mask we know what STE
> changes are safe and which are disruptive. We can count how many 64 bit
> QWORDS need a disruptive update and know if a step with V=0 is required.
> 
> This gives two basic flows through the algorithm.
> 
> If only a single 64 bit quantity needs disruptive replacement:
>  - Write the target value into all currently unused bits
>  - Write the single 64 bit quantity
>  - Zero the remaining different bits
> 
> If multiple 64 bit quantities need disruptive replacement then do:
>  - Write V=0 to QWORD 0
>  - Write the entire STE except QWORD 0
>  - Write QWORD 0
> 
> With HW flushes at each step, that can be skipped if the STE didn't change
> in that step.
> 
> At this point it generates the same sequence of updates as the current
> code, except that zeroing the VMID on entry to BYPASS/ABORT will do an
> extra sync (this seems to be an existing bug).

This is certainly very clever, but at the same time I can't help but feel
that it's slightly over-engineered to solve the general case, whereas I'm
struggling to see why such a level of complexity is necessary.

In the comment, you say:

> + * In the most general case we can make any update in three steps:
> + *  - Disrupting the entry (V=0)
> + *  - Fill now unused bits, all bits except V
> + *  - Make valid (V=1), single 64 bit store
> + *
> + * However this disrupts the HW while it is happening. There are several
> + * interesting cases where a STE/CD can be updated without disturbing the HW
> + * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
> + * because the used bits don't intersect. We can detect this by calculating how
> + * many 64 bit values need update after adjusting the unused bits and skip the
> + * V=0 process.

Please can you spell out these "interesting cases"? For cases where we're
changing CONFIG, I'd have thought it would be perfectly fine to go via an
invalid STE. What am I missing?

Generally, I like where the later patches in the series take things, but
I'd really like to reduce the complexity of the strtab updating code to
what is absolutely required.

I've left some minor comments on the code below, but I'd really like to
see this whole thing simplified if possible.

> + */
> +static bool arm_smmu_write_entry_step(__le64 *cur, const __le64 *cur_used,
> +				      const __le64 *target,
> +				      const __le64 *target_used, __le64 *step,
> +				      __le64 v_bit,
> +				      unsigned int len)
> +{
> +	u8 step_used_diff = 0;
> +	u8 step_change = 0;
> +	unsigned int i;
> +
> +	/*
> +	 * Compute a step that has all the bits currently unused by HW set to
> +	 * their target values.
> +	 */

Well, ok, I do have a cosmetic nit here: using 'step' for both "STE pointer"
and "incremental change" is perhaps, err, a step too far ;)

> +	for (i = 0; i != len; i++) {
> +		step[i] = (cur[i] & cur_used[i]) | (target[i] & ~cur_used[i]);

Isn't 'cur[i] & cur_used[i]' always cur[i]?

> +		if (cur[i] != step[i])
> +			step_change |= 1 << i;
> +		/*
> +		 * Each bit indicates if the step is incorrect compared to the
> +		 * target, considering only the used bits in the target
> +		 */
> +		if ((step[i] & target_used[i]) != (target[i] & target_used[i]))
> +			step_used_diff |= 1 << i;
> +	}
> +
> +	if (hweight8(step_used_diff) > 1) {
> +		/*
> +		 * More than 1 qword is mismatched, this cannot be done without
> +		 * a break. Clear the V bit and go again.
> +		 */
> +		step[0] &= ~v_bit;
> +	} else if (!step_change && step_used_diff) {
> +		/*
> +		 * Have exactly one critical qword, all the other qwords are set
> +		 * correctly, so we can set this qword now.
> +		 */
> +		i = ffs(step_used_diff) - 1;
> +		step[i] = target[i];
> +	} else if (!step_change) {
> +		/* cur == target, so all done */
> +		if (memcmp(cur, target, len * sizeof(*cur)) == 0)
> +			return true;
> +
> +		/*
> +		 * All the used HW bits match, but unused bits are different.
> +		 * Set them as well. Technically this isn't necessary but it
> +		 * brings the entry to the full target state, so if there are
> +		 * bugs in the mask calculation this will obscure them.
> +		 */
> +		memcpy(step, target, len * sizeof(*step));

Bah, I'm not a huge fan of this sort of defensive programming. I'd prefer
to propagate the error rather than quietly try to cover it up.

> +/*
> + * Based on the value of ent report which bits of the STE the HW will access. It
> + * would be nice if this was complete according to the spec, but minimally it
> + * has to capture the bits this driver uses.
> + */
> +static void arm_smmu_get_ste_used(const struct arm_smmu_ste *ent,
> +				  struct arm_smmu_ste *used_bits)
> +{
> +	memset(used_bits, 0, sizeof(*used_bits));
> +
> +	used_bits->data[0] = cpu_to_le64(STRTAB_STE_0_V);
> +	if (!(ent->data[0] & cpu_to_le64(STRTAB_STE_0_V)))
> +		return;
> +
> +	/*
> +	 * If S1 is enabled S1DSS is valid, see 13.5 Summary of
> +	 * attribute/permission configuration fields for the SHCFG behavior.
> +	 */
> +	if (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(ent->data[0])) & 1 &&
> +	    FIELD_GET(STRTAB_STE_1_S1DSS, le64_to_cpu(ent->data[1])) ==
> +		    STRTAB_STE_1_S1DSS_BYPASS)
> +		used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_SHCFG);
> +
> +	used_bits->data[0] |= cpu_to_le64(STRTAB_STE_0_CFG);
> +	switch (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(ent->data[0]))) {
> +	case STRTAB_STE_0_CFG_ABORT:
> +		break;
> +	case STRTAB_STE_0_CFG_BYPASS:
> +		used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_SHCFG);
> +		break;
> +	case STRTAB_STE_0_CFG_S1_TRANS:
> +		used_bits->data[0] |= cpu_to_le64(STRTAB_STE_0_S1FMT |
> +						  STRTAB_STE_0_S1CTXPTR_MASK |
> +						  STRTAB_STE_0_S1CDMAX);
> +		used_bits->data[1] |=
> +			cpu_to_le64(STRTAB_STE_1_S1DSS | STRTAB_STE_1_S1CIR |
> +				    STRTAB_STE_1_S1COR | STRTAB_STE_1_S1CSH |
> +				    STRTAB_STE_1_S1STALLD | STRTAB_STE_1_STRW);
> +		used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_EATS);
> +		break;
> +	case STRTAB_STE_0_CFG_S2_TRANS:
> +		used_bits->data[1] |=
> +			cpu_to_le64(STRTAB_STE_1_EATS | STRTAB_STE_1_SHCFG);
> +		used_bits->data[2] |=
> +			cpu_to_le64(STRTAB_STE_2_S2VMID | STRTAB_STE_2_VTCR |
> +				    STRTAB_STE_2_S2AA64 | STRTAB_STE_2_S2ENDI |
> +				    STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2R);
> +		used_bits->data[3] |= cpu_to_le64(STRTAB_STE_3_S2TTB_MASK);
> +		break;

I think this is going to be a pain to maintain :/

> +static bool arm_smmu_write_ste_step(struct arm_smmu_ste *cur,
> +				    const struct arm_smmu_ste *target,
> +				    const struct arm_smmu_ste *target_used)
> +{
> +	struct arm_smmu_ste cur_used;
> +	struct arm_smmu_ste step;
> +
> +	arm_smmu_get_ste_used(cur, &cur_used);
> +	return arm_smmu_write_entry_step(cur->data, cur_used.data, target->data,
> +					 target_used->data, step.data,
> +					 cpu_to_le64(STRTAB_STE_0_V),
> +					 ARRAY_SIZE(cur->data));
> +}
> +
> +static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
> +			       struct arm_smmu_ste *ste,
> +			       const struct arm_smmu_ste *target)
> +{
> +	struct arm_smmu_ste target_used;
> +	int i;
> +
> +	arm_smmu_get_ste_used(target, &target_used);
> +	/* Masks in arm_smmu_get_ste_used() are up to date */
> +	for (i = 0; i != ARRAY_SIZE(target->data); i++)
> +		WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);

That's a runtime cost on every single STE update for what would be a driver
bug.

> +
> +	while (true) {
> +		if (arm_smmu_write_ste_step(ste, target, &target_used))
> +			break;
> +		arm_smmu_sync_ste_for_sid(smmu, sid);
> +	}

This really should be bounded...

Will


From conor at kernel.org  Tue Dec 12 08:24:20 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 16:24:20 +0000
Subject: [RFC PATCH net-next v3 4/8] dt-bindings: net: pcs: add bindings
 for MediaTek USXGMII PCS
In-Reply-To: <510af8550385da947e2e2516629c4fbed7fc0f64.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <510af8550385da947e2e2516629c4fbed7fc0f64.1702352117.git.daniel@makrotopia.org>
Message-ID: <20231212-panhandle-pasty-243c3556ea51@spud>

On Tue, Dec 12, 2023 at 03:47:31AM +0000, Daniel Golle wrote:
> MediaTek's USXGMII can be found in the MT7988 SoC. We need to access
> it in order to configure and monitor the Ethernet SerDes link in
> USXGMII, 10GBase-R and 5GBase-R mode. By including a wrapped
> legacy 1000Base-X/2500Base-X/Cisco SGMII LynxI PCS as well, those
> interface modes are also available.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../bindings/net/pcs/mediatek,usxgmii.yaml    | 60 +++++++++++++++++++
>  1 file changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
> 
> diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
> new file mode 100644
> index 0000000000000..0cdaa3545edb0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/pcs/mediatek,usxgmii.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/pcs/mediatek,usxgmii.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek USXGMII PCS
> +
> +maintainers:
> +  - Daniel Golle <daniel at makrotopia.org>
> +
> +description:
> +  The MediaTek USXGMII PCS provides physical link control and status
> +  for USXGMII, 10GBase-R and 5GBase-R links on the SerDes interfaces
> +  provided by the PEXTP PHY.
> +  In order to also support legacy 2500Base-X, 1000Base-X and Cisco
> +  SGMII an existing mediatek,*-sgmiisys LynxI PCS is wrapped to
> +  provide those interfaces modes on the same SerDes interfaces shared
> +  with the USXGMII PCS.
> +
> +properties:
> +  $nodename:
> +    pattern: "^pcs@[0-9a-f]+$"
> +
> +  compatible:
> +    const: mediatek,mt7988-usxgmiisys
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    items:
> +      - description: USXGMII top-level clock
> +
> +  resets:
> +    items:
> +      - description: XFI reset

For this two, why not just "maxItems: 1", since there are only one of
each?

> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - resets
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/mediatek,mt7988-clk.h>

> +    #define MT7988_TOPRGU_XFI0_GRST 12

Why? You can just put the raw numbers here and avoid the issues with the
bot being unable to test your series.

> +    soc {
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +        usxgmiisys0: pcs at 10080000 {
> +          compatible = "mediatek,mt7988-usxgmiisys";
> +          reg = <0 0x10080000 0 0x1000>;
> +          clocks = <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>;
> +          resets = <&watchdog MT7988_TOPRGU_XFI0_GRST>;
> +        };
> +    };
> -- 
> 2.43.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/0be49839/attachment.sig>

From akpm at linux-foundation.org  Tue Dec 12 08:27:22 2023
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 12 Dec 2023 08:27:22 -0800
Subject: [PATCH v9 03/10] mm: thp: Introduce multi-size THP sysfs
 interface
In-Reply-To: <e424982c-8a2f-4c98-83aa-fdb0ee765776@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
	<20231207161211.2374093-4-ryan.roberts@arm.com>
	<ff7a3e9c-53cb-4283-9298-781d4fb7c7f8@redhat.com>
	<e424982c-8a2f-4c98-83aa-fdb0ee765776@arm.com>
Message-ID: <20231212082722.13e857daf589bd49d5e877d9@linux-foundation.org>

On Tue, 12 Dec 2023 15:32:29 +0000 Ryan Roberts <ryan.roberts at arm.com> wrote:

> > Why not perform lock/unlock only once in surrounding code? :)
> 
> I was nervous that sysfs_streq() may be unhappy in atomic context... Unfounded?
> 

Yes, unfounded.


From conor at kernel.org  Tue Dec 12 08:29:35 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 16:29:35 +0000
Subject: [RFC PATCH net-next v3 6/8] dt-bindings: net: mediatek: remove
 wrongly added clocks and SerDes
In-Reply-To: <5859da6629b8b6c100eca4062dd193105bf829ba.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <5859da6629b8b6c100eca4062dd193105bf829ba.1702352117.git.daniel@makrotopia.org>
Message-ID: <20231212-operative-stubbly-2104c96bdee5@spud>

On Tue, Dec 12, 2023 at 03:48:10AM +0000, Daniel Golle wrote:
> Several clocks as well as both sgmiisys phandles were added by mistake
> to the Ethernet bindings for MT7988.
> 
> This happened because the vendor driver which served as a reference
> uses a high number of syscon phandles to access various parts of the
> SoC which wasn't acceptable upstream. Hence several parts which have
> never previously been supported (such SerDes PHY and USXGMII PCS) have
> been moved to separate drivers which also result in a much more sane
> device tree.
> 
> Quickly align the bindings with the upcoming reality of the drivers
> actually adding full support for this SoC.
> 
> Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/c47f7c7e/attachment.sig>

From u-kumar1 at ti.com  Tue Dec 12 08:31:05 2023
From: u-kumar1 at ti.com (Kumar, Udit)
Date: Tue, 12 Dec 2023 22:01:05 +0530
Subject: [PATCH v10 0/7] Add TPS6594 PMIC support on several boards
In-Reply-To: <20231208114919.3429562-1-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
Message-ID: <ab20afc0-e42f-4ee1-a6aa-68a2688f22c0@ti.com>

Thanks Neha

On 12/8/2023 5:19 PM, Neha Malcom Francis wrote:
> TPS6594 is a Power Management IC which provides regulators and others
> features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
> PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can
> communicate through the I2C or SPI interfaces.
> TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives.
>
> This series adds device tree nodes for TI TPS6594 PMICs found in the
> following boards:
> - J721EXSOMXEVM:
>    Link: https://www.ti.com/tool/J721EXSOMXEVM
> - J721S2XSOMXEVM:
>    Link: https://www.ti.com/tool/J721S2XSOMXEVM
> - J7200XSOMXEVM:
>    Link: https://www.ti.com/tool/J7200XSOMXEVM
> - J784S4XEVM
>    Link: https://www.ti.com/tool/J784S4XEVM
> - SK-AM69
>    Link: https://www.ti.com/tool/SK-AM69
> - SK-TDA4VM (J721E-SK)
>    Link: https://www.ti.com/tool/SK-TDA4VM
>
> Boot Logs with required config (DONOTMERGE patch) enabled:
> https://gist.github.com/nehamalcom/f47fcd6183360ed8a146c9ba456202c3
> Boot Logs without config enabled:
> https://gist.github.com/nehamalcom/58217b100e614ae55726f314e02b5001

For series

Reviewed-by: Udit Kumar <u-kumar1 at ti.com>


> ---
> Changes from v9:
> https://lore.kernel.org/all/20231205093439.2298296-1-n-francis at ti.com/
> - moved from wkup_pmx1 to wkup_pmx2 (Udit)
> - changed boot logs for AM68-SK to the latest one
> - removed Tested-by tag for AM68-SK
> - modified order of properties in line with latest kernel DTS
>    conventions
>
> Changes from v8:
> https://lore.kernel.org/all/20231128055230.342547-4-n-francis at ti.com/
> - added bootph-pre-ram to AVS regulator (Udit)
> - keeping boot logs and Tested-by tags the same (no effect to kernel)
>
> Changes from v7:
> https://lore.kernel.org/all/20231122104513.2335757-1-n-francis at ti.com/
> - (New Patches) Add support for SK boards that have TPS6594xx PMIC
>    present (J721E-SK and AM69-SK) (Nishanth)
> - Add DONOTMERGE defconfig patch to show test logs
>
> Changes from v6:
> https://lore.kernel.org/all/20230810-tps6594-v6-0-2b2e2399e2ef at ti.com/
> - Modify patch series to include only patches not merged (J7)
> - Add boot logs for all affected boards
>
> Changes from v5:
> https://lore.kernel.org/all/20230809-tps6594-v5-0-485fd3d63670 at ti.com
> - Range-diff: http://0x0.st/H_fD.diff
> - Reword the patch fixing interrupt ranges for mcu domain gpio intr, and
>    add Fixes: tag
> - Also fix interrupt ranges for main domain gpio intr in the same patch
> - Change pinctrl node names to end in -pins to fix dtbs_check warnings
> - (New Patch) Enable TPS6594 in defconfig
>
> Changes from v4:
> https://lore.kernel.org/all/20230727130908.10656-1-eblanc at baylibre.com/
> - Range-diff: https://0x0.st/H_L7.diff
> - Rebased on top of linux-next
> - Fix min voltage on vdd_usb_3v3 regulator (ldo2) on j721e-som
> - Use 3-hex-digit format for pinctrl values
>
> Changes from v3:
> https://lore.kernel.org/all/20230417154832.216774-1-eblanc at baylibre.com/
> - Rebased on top of v6.5-rc1.
> - Change pinctrl number for irq pin as wkup_pmx0 was split on some boards.
> - Use already present wkup_i2c0 node instead of creating a new one.
>
> Changes from v2:
> https://lore.kernel.org/lkml/20230414112843.1358067-1-eblanc at baylibre.com/
> - Change node name as per Krzysztof review.
> - Add a fix for the interrupt range of wakeup gpio used by TPS6594 pmic
>    on J784S4.
>    The interruptions of the PMIC were not working before that.
> - Remove dependencies on other patch series as that was a mistake, see
>    https://lore.kernel.org/lkml/CRYY2V3HJ0CP.96JQ18PLZB3C at burritosblues/
>
> Changes from v1:
> https://lore.kernel.org/lkml/20230329142948.833800-1-eblanc at baylibre.com/
> - Harmonize regulators names across the different boards.
> - Adjust AVS voltage range.
> - Remove some outdated comments.
> - Add PMIC to J784S4 board.
> - Compatible string modified to match dt-bindings.
> - Add gpio-controller and gpio-cells properties.
>
> Esteban Blanc (2):
>    arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
>    arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs
>
> Jerome Neanne (2):
>    arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
>    arm64: dts: ti: k3-j784s4-evm: Add support for TPS6594 PMIC
>
> Neha Malcom Francis (3):
>    arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC
>    arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs
>    DONOTMERGE: arm64: defconfig: Enable TPS6594 PMIC for J7 devices
>
>   arch/arm64/boot/dts/ti/k3-am69-sk.dts        |  94 +++++++++
>   arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi  | 153 +++++++++++++++
>   arch/arm64/boot/dts/ti/k3-j721e-sk.dts       | 151 +++++++++++++++
>   arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi  | 160 +++++++++++++++
>   arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 193 +++++++++++++++++++
>   arch/arm64/boot/dts/ti/k3-j784s4-evm.dts     | 102 ++++++++++
>   arch/arm64/configs/defconfig                 |   2 +-
>   7 files changed, 854 insertions(+), 1 deletion(-)
>


From conor at kernel.org  Tue Dec 12 08:34:32 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 16:34:32 +0000
Subject: [RFC PATCH net-next v3 7/8] dt-bindings: net: mediatek,net: fix
 and complete mt7988-eth binding
In-Reply-To: <ac6a7277fc534f610386bc51b2ff87beade03be8.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <ac6a7277fc534f610386bc51b2ff87beade03be8.1702352117.git.daniel@makrotopia.org>
Message-ID: <20231212-unlinked-audio-94132ec03663@spud>

On Tue, Dec 12, 2023 at 03:51:01AM +0000, Daniel Golle wrote:
> Complete support for MT7988 which comes with 3 MACs, SRAM for DMA
> descriptors and uses a dedicated PCS for the SerDes units.

The commit message here seems a bit incomplete, mostly a lack of an
explanation for why the model was initially incorrect.

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> 
> Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  .../devicetree/bindings/net/mediatek,net.yaml | 148 +++++++++++++++++-
>  1 file changed, 146 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> index 030d106bc7d3f..ca0667c51c1c2 100644
> --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
> +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
> @@ -28,7 +28,10 @@ properties:
>        - ralink,rt5350-eth
>  
>    reg:
> -    maxItems: 1
> +    minItems: 1
> +    items:
> +      - description: Base of registers used to program the ethernet controller
> +      - description: SRAM region used for DMA descriptors
>  
>    clocks: true
>    clock-names: true
> @@ -115,6 +118,9 @@ allOf:
>                - mediatek,mt7623-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            maxItems: 3
>  
> @@ -149,6 +155,9 @@ allOf:
>                - mediatek,mt7621-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            maxItems: 1
>  
> @@ -174,6 +183,9 @@ allOf:
>              const: mediatek,mt7622-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            maxItems: 3
>  
> @@ -215,6 +227,9 @@ allOf:
>              const: mediatek,mt7629-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            maxItems: 3
>  
> @@ -257,6 +272,9 @@ allOf:
>              const: mediatek,mt7981-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            minItems: 4
>  
> @@ -295,6 +313,9 @@ allOf:
>              const: mediatek,mt7986-eth
>      then:
>        properties:
> +        reg:
> +          maxItems: 1
> +
>          interrupts:
>            minItems: 4
>  
> @@ -333,8 +354,12 @@ allOf:
>              const: mediatek,mt7988-eth
>      then:
>        properties:
> +        reg:
> +          minItems: 2
> +
>          interrupts:
>            minItems: 4
> +          maxItems: 4
>  
>          clocks:
>            minItems: 24
> @@ -368,7 +393,7 @@ allOf:
>              - const: top_netsys_warp_sel
>  
>  patternProperties:
> -  "^mac@[0-1]$":
> +  "^mac@[0-2]$":
>      type: object
>      unevaluatedProperties: false
>      allOf:
> @@ -382,6 +407,9 @@ patternProperties:
>        reg:
>          maxItems: 1
>  
> +      phys:
> +        maxItems: 1
> +
>      required:
>        - reg
>        - compatible
> @@ -559,3 +587,118 @@ examples:
>          };
>        };
>      };
> +
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/clock/mediatek,mt7988-clk.h>
> +
> +    soc {
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +
> +      ethernet at 15100000 {
> +        compatible = "mediatek,mt7988-eth";
> +        reg = <0 0x15100000 0 0x80000>, <0 0x15400000 0 0x380000>;
> +        interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
> +                     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
> +                     <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
> +                     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
> +
> +        clocks = <&ethsys CLK_ETHDMA_XGP1_EN>,
> +                 <&ethsys CLK_ETHDMA_XGP2_EN>,
> +                 <&ethsys CLK_ETHDMA_XGP3_EN>,
> +                 <&ethsys CLK_ETHDMA_FE_EN>,
> +                 <&ethsys CLK_ETHDMA_GP2_EN>,
> +                 <&ethsys CLK_ETHDMA_GP1_EN>,
> +                 <&ethsys CLK_ETHDMA_GP3_EN>,
> +                 <&ethsys CLK_ETHDMA_ESW_EN>,
> +                 <&ethsys CLK_ETHDMA_CRYPT0_EN>,
> +                 <&ethwarp CLK_ETHWARP_WOCPU2_EN>,
> +                 <&ethwarp CLK_ETHWARP_WOCPU1_EN>,
> +                 <&ethwarp CLK_ETHWARP_WOCPU0_EN>,
> +                 <&topckgen CLK_TOP_ETH_GMII_SEL>,
> +                 <&topckgen CLK_TOP_ETH_REFCK_50M_SEL>,
> +                 <&topckgen CLK_TOP_ETH_SYS_200M_SEL>,
> +                 <&topckgen CLK_TOP_ETH_SYS_SEL>,
> +                 <&topckgen CLK_TOP_ETH_XGMII_SEL>,
> +                 <&topckgen CLK_TOP_ETH_MII_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_500M_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_PAO_2X_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_SYNC_250M_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_PPEFB_250M_SEL>,
> +                 <&topckgen CLK_TOP_NETSYS_WARP_SEL>;
> +
> +        clock-names = "xgp1", "xgp2", "xgp3", "fe", "gp2", "gp1",
> +                      "gp3", "esw", "crypto",
> +                      "ethwarp_wocpu2", "ethwarp_wocpu1",
> +                      "ethwarp_wocpu0", "top_eth_gmii_sel",
> +                      "top_eth_refck_50m_sel", "top_eth_sys_200m_sel",
> +                      "top_eth_sys_sel", "top_eth_xgmii_sel",
> +                      "top_eth_mii_sel", "top_netsys_sel",
> +                      "top_netsys_500m_sel", "top_netsys_pao_2x_sel",
> +                      "top_netsys_sync_250m_sel",
> +                      "top_netsys_ppefb_250m_sel",
> +                      "top_netsys_warp_sel";
> +        assigned-clocks = <&topckgen CLK_TOP_NETSYS_2X_SEL>,
> +                          <&topckgen CLK_TOP_NETSYS_GSW_SEL>,
> +                          <&topckgen CLK_TOP_USXGMII_SBUS_0_SEL>,
> +                          <&topckgen CLK_TOP_USXGMII_SBUS_1_SEL>,
> +                          <&topckgen CLK_TOP_SGM_0_SEL>,
> +                          <&topckgen CLK_TOP_SGM_1_SEL>;
> +        assigned-clock-parents = <&apmixedsys CLK_APMIXED_NET2PLL>,
> +                                 <&topckgen CLK_TOP_NET1PLL_D4>,
> +                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
> +                                 <&topckgen CLK_TOP_NET1PLL_D8_D4>,
> +                                 <&apmixedsys CLK_APMIXED_SGMPLL>,
> +                                 <&apmixedsys CLK_APMIXED_SGMPLL>;
> +        mediatek,ethsys = <&ethsys>;
> +        mediatek,infracfg = <&topmisc>;
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        mac at 0 {
> +          compatible = "mediatek,eth-mac";
> +          reg = <0>;
> +          phy-mode = "internal"; /* CPU port of built-in 1GE switch */
> +
> +          fixed-link {
> +            speed = <10000>;
> +            full-duplex;
> +            pause;
> +          };
> +        };
> +
> +        mac at 1 {
> +          compatible = "mediatek,eth-mac";
> +          reg = <1>;
> +          phy-handle = <&int_2p5g_phy>;
> +        };
> +
> +        mac at 2 {
> +          compatible = "mediatek,eth-mac";
> +          reg = <2>;
> +          pcs-handle = <&usxgmiisys0>, <&sgmii0>;
> +          phys = <&pextp0>;
> +        };
> +
> +        mdio_bus: mdio-bus {
> +          #address-cells = <1>;
> +          #size-cells = <0>;
> +
> +          /* external PHY */
> +          phy0: ethernet-phy at 0 {
> +            reg = <0>;
> +            compatible = "ethernet-phy-ieee802.3-c45";
> +          };
> +
> +          /* internal 2.5G PHY */
> +          int_2p5g_phy: ethernet-phy at 15 {
> +            reg = <15>;
> +            compatible = "ethernet-phy-ieee802.3-c45";
> +            phy-mode = "internal";
> +          };
> +        };
> +      };
> +    };
> -- 
> 2.43.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/388d7200/attachment.sig>

From david at redhat.com  Tue Dec 12 08:35:23 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 12 Dec 2023 17:35:23 +0100
Subject: [PATCH v9 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <d67754d6-8f11-4d36-8e16-4f93bc04bea6@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207161211.2374093-5-ryan.roberts@arm.com>
 <2bebcf33-e8b7-468d-86cc-31d6eb355b66@redhat.com>
 <d67754d6-8f11-4d36-8e16-4f93bc04bea6@arm.com>
Message-ID: <deb312cc-aa77-4f34-b9af-0ccc58492648@redhat.com>

On 12.12.23 16:38, Ryan Roberts wrote:
> On 12/12/2023 15:02, David Hildenbrand wrote:
>> On 07.12.23 17:12, Ryan Roberts wrote:
>>> Introduce the logic to allow THP to be configured (through the new sysfs
>>> interface we just added) to allocate large folios to back anonymous
>>> memory, which are larger than the base page size but smaller than
>>> PMD-size. We call this new THP extension "multi-size THP" (mTHP).
>>>
>>> mTHP continues to be PTE-mapped, but in many cases can still provide
>>> similar benefits to traditional PMD-sized THP: Page faults are
>>> significantly reduced (by a factor of e.g. 4, 8, 16, etc. depending on
>>> the configured order), but latency spikes are much less prominent
>>> because the size of each page isn't as huge as the PMD-sized variant and
>>> there is less memory to clear in each page fault. The number of per-page
>>> operations (e.g. ref counting, rmap management, lru list management) are
>>> also significantly reduced since those ops now become per-folio.
>>
>> I'll note that with always-pte-mapped-thp it will be much easier to support
>> incremental page clearing (e.g., zero only parts of the folio and map the
>> remainder in a pro-non-like fashion whereby we'll zero on the next page fault).
>> With a PMD-sized thp, you have to eventually place/rip out page tables to
>> achieve that.
> 
> But then you lose the benefits of reduced number of page faults; reducing page
> faults gives a big speed up for workloads with lots of short lived processes
> like compiling.

Well, you can do interesting things like "allocate order-5", but zero in 
order-3 chunks. You get less page faults and pay for alloc/rmap only once.

But yes, all has pros and cons.

[...]

>>
>>>
>>> Some architectures also employ TLB compression mechanisms to squeeze
>>> more entries in when a set of PTEs are virtually and physically
>>> contiguous and approporiately aligned. In this case, TLB misses will
>>> occur less often.
>>>
>>> The new behaviour is disabled by default, but can be enabled at runtime
>>> by writing to /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled
>>> (see documentation in previous commit). The long term aim is to change
>>> the default to include suitable lower orders, but there are some risks
>>> around internal fragmentation that need to be better understood first.
>>>
>>> Tested-by: Kefeng Wang <wangkefeng.wang at huawei.com>
>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>> ---
>>>  ? include/linux/huge_mm.h |?? 6 ++-
>>>  ? mm/memory.c???????????? | 111 ++++++++++++++++++++++++++++++++++++----
>>>  ? 2 files changed, 106 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>> index 609c153bae57..fa7a38a30fc6 100644
>>> --- a/include/linux/huge_mm.h
>>> +++ b/include/linux/huge_mm.h
>>> @@ -68,9 +68,11 @@ extern struct kobj_attribute shmem_enabled_attr;
>>>  ? #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>>
>> [...]
>>
>>> +
>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>> +static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>>> +{
>>> +??? struct vm_area_struct *vma = vmf->vma;
>>> +??? unsigned long orders;
>>> +??? struct folio *folio;
>>> +??? unsigned long addr;
>>> +??? pte_t *pte;
>>> +??? gfp_t gfp;
>>> +??? int order;
>>> +
>>> +??? /*
>>> +???? * If uffd is active for the vma we need per-page fault fidelity to
>>> +???? * maintain the uffd semantics.
>>> +???? */
>>> +??? if (unlikely(userfaultfd_armed(vma)))
>>> +??????? goto fallback;
>>> +
>>> +??? /*
>>> +???? * Get a list of all the (large) orders below PMD_ORDER that are enabled
>>> +???? * for this vma. Then filter out the orders that can't be allocated over
>>> +???? * the faulting address and still be fully contained in the vma.
>>> +???? */
>>> +??? orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
>>> +????????????????????? BIT(PMD_ORDER) - 1);
>>> +??? orders = thp_vma_suitable_orders(vma, vmf->address, orders);
>>> +
>>> +??? if (!orders)
>>> +??????? goto fallback;
>>> +
>>> +??? pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
>>> +??? if (!pte)
>>> +??????? return ERR_PTR(-EAGAIN);
>>> +
>>> +??? /*
>>> +???? * Find the highest order where the aligned range is completely
>>> +???? * pte_none(). Note that all remaining orders will be completely
>>> +???? * pte_none().
>>> +???? */
>>> +??? order = highest_order(orders);
>>> +??? while (orders) {
>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>> +??????? if (pte_range_none(pte + pte_index(addr), 1 << order))
>>> +??????????? break;
>>> +??????? order = next_order(&orders, order);
>>> +??? }
>>> +
>>> +??? pte_unmap(pte);
>>> +
>>> +??? /* Try allocating the highest of the remaining orders. */
>>> +??? gfp = vma_thp_gfp_mask(vma);
>>> +??? while (orders) {
>>> +??????? addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
>>> +??????? folio = vma_alloc_folio(gfp, order, vma, addr, true);
>>> +??????? if (folio) {
>>> +??????????? clear_huge_page(&folio->page, vmf->address, 1 << order);
>>> +??????????? return folio;
>>> +??????? }
>>> +??????? order = next_order(&orders, order);
>>> +??? }
>>> +
>>> +fallback:
>>> +??? return vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>> +}
>>> +#else
>>> +#define alloc_anon_folio(vmf) \
>>> +??????? vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
>>> +#endif
>>
>> A neater alternative might be
>>
>> static struct folio *alloc_anon_folio(struct vm_fault *vmf)
>> {
>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>  ????/* magic */
>> fallback:
>> #endif
>>  ????return vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address):
>> }
> 
> I guess beauty lies in the eye of the beholder... I don't find it much neater
> personally :). But happy to make the change if you insist; what's the process
> now that its in mm-unstable? Just send a patch to Andrew for squashing?

That way it is clear that the fallback for thp is just what !thp does.

But either is fine for me; no need to change if you disagree.

-- 
Cheers,

David / dhildenb



From hch at infradead.org  Tue Dec 12 08:35:36 2023
From: hch at infradead.org (Christoph Hellwig)
Date: Tue, 12 Dec 2023 08:35:36 -0800
Subject: [PATCH v4 0/4] arm64: Run kernel mode NEON with preemption
 enabled
In-Reply-To: <20231212105513.GA28416@willie-the-truck>
References: <20231208113218.3001940-6-ardb@google.com>
 <170231871028.1857077.10318072500676133330.b4-ty@kernel.org>
 <CAMj1kXE=2H_Jqyuv_gDp6QS2g2Vzdgf=fngp=ZXEUBXKOYWnbQ@mail.gmail.com>
 <20231212105513.GA28416@willie-the-truck>
Message-ID: <ZXiL2FhAWozC4HVu@infradead.org>

On Tue, Dec 12, 2023 at 10:55:13AM +0000, Will Deacon wrote:
> As discussed off-list, the vague concern was if kernel_neon_begin() is
> nested off the back of a user fault. The BUG_ON() should fire in that case,
> so we're all good.

I think we should really document all these rules, and Samuel's series
to add the portable FPU API would be the right place for it.  I'd also
really love to see objtool support for enforcing the various rules
where possible.



From contact at emersion.fr  Tue Dec 12 08:36:35 2023
From: contact at emersion.fr (Simon Ser)
Date: Tue, 12 Dec 2023 16:36:35 +0000
Subject: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
In-Reply-To: <20231212024607.3681-1-yong.wu@mediatek.com>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
Message-ID: <DPBmATfmfvSP8Cwjz99kj_JvCEiAqRfuMFJZEBF2aIgl8NZqWFR66eyPTX1E8bHyOlimBihEE3E80p9bfOJ-0SNu8pwoIzL9gD2Xae6r97g=@emersion.fr>

Is there a chance to pick a better name than "secure" here?

"Secure" is super overloaded, it's not clear at all what it means from
just the name. Something like "restricted" would be an improvement.


From alexandru.elisei at arm.com  Tue Dec 12 08:38:32 2023
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Tue, 12 Dec 2023 16:38:32 +0000
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com>
 <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
Message-ID: <ZXiMiLz9ZyUdxUP8@raptor>

Hi Rob,

Thank you so much for the feedback, I'm not very familiar with device tree,
and any comments are very useful.

On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> <alexandru.elisei at arm.com> wrote:
> >
> > Allow the kernel to get the size and location of the MTE tag storage
> > regions from the DTB. This memory is marked as reserved for now.
> >
> > The DTB node for the tag storage region is defined as:
> >
> >         tags0: tag-storage at 8f8000000 {
> >                 compatible = "arm,mte-tag-storage";
> >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> >                 block-size = <0x1000>;
> >                 memory = <&memory0>;    // Associated tagged memory node
> >         };
> 
> I skimmed thru the discussion some. If this memory range is within
> main RAM, then it definitely belongs in /reserved-memory.

Ok, will do that.

If you don't mind, why do you say that it definitely belongs in
reserved-memory? I'm not trying to argue otherwise, I'm curious about the
motivation.

Tag storage is not DMA and can live anywhere in memory. In
arm64_memblock_init(), the kernel first removes the memory that it cannot
address from memblock. For example, because it has been compiled with
CONFIG_ARM64_VA_BITS_39=y. And then calls
early_init_fdt_scan_reserved_mem().

What happens if reserved memory is above what the kernel can address?

>From my testing, when the kernel is compiled with 39 bit VA, if I use
reserved memory to discover tag storage the lives above the virtua address
limit and then I try to use CMA to manage the tag storage memory, I get a
kernel panic:

[    0.000000] Reserved memory: created CMA memory pool at 0x0000010000000000, size 64 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000] OF: reserved mem: 0x0000010000000000..0x0000010003ffffff (65536 KiB) map reusable linux,cma
[..]
[    0.806945] Unable to handle kernel paging request at virtual address 00000001fe000000
[    0.807277] Mem abort info:
[    0.807277]   ESR = 0x0000000096000005
[    0.807693]   EC = 0x25: DABT (current EL), IL = 32 bits
[    0.808110]   SET = 0, FnV = 0
[    0.808443]   EA = 0, S1PTW = 0
[    0.808526]   FSC = 0x05: level 1 translation fault
[    0.808943] Data abort info:
[    0.808943]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[    0.809360]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    0.809776]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    0.810221] [00000001fe000000] user address but active_mm is swapper
[..]
[    0.820887] Call trace:
[    0.821027]  cma_init_reserved_areas+0xc4/0x378

> 
> You need a binding for this too.

By binding you mean having an yaml file in dt-schem [1] describing the tag
storage node, right?

[1] https://github.com/devicetree-org/dt-schema

> 
> > The tag storage region represents the largest contiguous memory region that
> > holds all the tags for the associated contiguous memory region which can be
> > tagged. For example, for a 32GB contiguous tagged memory the corresponding
> > tag storage region is 1GB of contiguous memory, not two adjacent 512M of
> > tag storage memory.
> >
> > "block-size" represents the minimum multiple of 4K of tag storage where all
> > the tags stored in the block correspond to a contiguous memory region. This
> > is needed for platforms where the memory controller interleaves tag writes
> > to memory. For example, if the memory controller interleaves tag writes for
> > 256KB of contiguous memory across 8K of tag storage (2-way interleave),
> > then the correct value for "block-size" is 0x2000. This value is a hardware
> > property, independent of the selected kernel page size.
> >
> > Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
> > ---
> >  arch/arm64/Kconfig                       |  12 ++
> >  arch/arm64/include/asm/mte_tag_storage.h |  15 ++
> >  arch/arm64/kernel/Makefile               |   1 +
> >  arch/arm64/kernel/mte_tag_storage.c      | 256 +++++++++++++++++++++++
> >  arch/arm64/kernel/setup.c                |   7 +
> >  5 files changed, 291 insertions(+)
> >  create mode 100644 arch/arm64/include/asm/mte_tag_storage.h
> >  create mode 100644 arch/arm64/kernel/mte_tag_storage.c
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 7b071a00425d..fe8276fdc7a8 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -2062,6 +2062,18 @@ config ARM64_MTE
> >
> >           Documentation/arch/arm64/memory-tagging-extension.rst.
> >
> > +if ARM64_MTE
> > +config ARM64_MTE_TAG_STORAGE
> > +       bool "Dynamic MTE tag storage management"
> > +       help
> > +         Adds support for dynamic management of the memory used by the hardware
> > +         for storing MTE tags. This memory, unlike normal memory, cannot be
> > +         tagged. When it is used to store tags for another memory location it
> > +         cannot be used for any type of allocation.
> > +
> > +         If unsure, say N
> > +endif # ARM64_MTE
> > +
> >  endmenu # "ARMv8.5 architectural features"
> >
> >  menu "ARMv8.7 architectural features"
> > diff --git a/arch/arm64/include/asm/mte_tag_storage.h b/arch/arm64/include/asm/mte_tag_storage.h
> > new file mode 100644
> > index 000000000000..8f86c4f9a7c3
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/mte_tag_storage.h
> > @@ -0,0 +1,15 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2023 ARM Ltd.
> > + */
> > +#ifndef __ASM_MTE_TAG_STORAGE_H
> > +#define __ASM_MTE_TAG_STORAGE_H
> > +
> > +#ifdef CONFIG_ARM64_MTE_TAG_STORAGE
> > +void mte_tag_storage_init(void);
> > +#else
> > +static inline void mte_tag_storage_init(void)
> > +{
> > +}
> > +#endif /* CONFIG_ARM64_MTE_TAG_STORAGE */
> > +#endif /* __ASM_MTE_TAG_STORAGE_H  */
> > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> > index d95b3d6b471a..5f031bf9f8f1 100644
> > --- a/arch/arm64/kernel/Makefile
> > +++ b/arch/arm64/kernel/Makefile
> > @@ -70,6 +70,7 @@ obj-$(CONFIG_CRASH_CORE)              += crash_core.o
> >  obj-$(CONFIG_ARM_SDE_INTERFACE)                += sdei.o
> >  obj-$(CONFIG_ARM64_PTR_AUTH)           += pointer_auth.o
> >  obj-$(CONFIG_ARM64_MTE)                        += mte.o
> > +obj-$(CONFIG_ARM64_MTE_TAG_STORAGE)    += mte_tag_storage.o
> >  obj-y                                  += vdso-wrap.o
> >  obj-$(CONFIG_COMPAT_VDSO)              += vdso32-wrap.o
> >  obj-$(CONFIG_UNWIND_PATCH_PAC_INTO_SCS)        += patch-scs.o
> > diff --git a/arch/arm64/kernel/mte_tag_storage.c b/arch/arm64/kernel/mte_tag_storage.c
> > new file mode 100644
> > index 000000000000..fa6267ef8392
> > --- /dev/null
> > +++ b/arch/arm64/kernel/mte_tag_storage.c
> > @@ -0,0 +1,256 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Support for dynamic tag storage.
> > + *
> > + * Copyright (C) 2023 ARM Ltd.
> > + */
> > +
> > +#include <linux/memblock.h>
> > +#include <linux/mm.h>
> > +#include <linux/of_device.h>
> 
> You probably don't need this header. If you depend on what it
> implicitly includes, then that will now break in linux-next.

I'll have a look if I can remove it. Might be an artifact from an earlier
version of the patches.

> 
> > +#include <linux/of_fdt.h>
> > +#include <linux/range.h>
> > +#include <linux/string.h>
> > +#include <linux/xarray.h>
> > +
> > +#include <asm/mte_tag_storage.h>
> > +
> > +struct tag_region {
> > +       struct range mem_range; /* Memory associated with the tag storage, in PFNs. */
> > +       struct range tag_range; /* Tag storage memory, in PFNs. */
> > +       u32 block_size;         /* Tag block size, in pages. */
> > +};
> > +
> > +#define MAX_TAG_REGIONS        32
> > +
> > +static struct tag_region tag_regions[MAX_TAG_REGIONS];
> > +static int num_tag_regions;
> > +
> > +static int __init tag_storage_of_flat_get_range(unsigned long node, const __be32 *reg,
> > +                                               int reg_len, struct range *range)
> > +{
> > +       int addr_cells = dt_root_addr_cells;
> > +       int size_cells = dt_root_size_cells;
> > +       u64 size;
> > +
> > +       if (reg_len / 4 > addr_cells + size_cells)
> > +               return -EINVAL;
> > +
> > +       range->start = PHYS_PFN(of_read_number(reg, addr_cells));
> > +       size = PHYS_PFN(of_read_number(reg + addr_cells, size_cells));
> > +       if (size == 0) {
> > +               pr_err("Invalid node");
> > +               return -EINVAL;
> > +       }
> > +       range->end = range->start + size - 1;
> 
> We have a function to read (and translate which you forgot) addresses.
> Add what's missing rather than open code your own.

I must have missed that there's already a function to read addresses. Would
you mind pointing me in the right direction?

> 
> > +
> > +       return 0;
> > +}
> > +
> > +static int __init tag_storage_of_flat_get_tag_range(unsigned long node,
> > +                                                   struct range *tag_range)
> > +{
> > +       const __be32 *reg;
> > +       int reg_len;
> > +
> > +       reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> > +       if (reg == NULL) {
> > +               pr_err("Invalid metadata node");
> > +               return -EINVAL;
> > +       }
> > +
> > +       return tag_storage_of_flat_get_range(node, reg, reg_len, tag_range);
> > +}
> > +
> > +static int __init tag_storage_of_flat_get_memory_range(unsigned long node, struct range *mem)
> > +{
> > +       const __be32 *reg;
> > +       int reg_len;
> > +
> > +       reg = of_get_flat_dt_prop(node, "linux,usable-memory", &reg_len);
> > +       if (reg == NULL)
> > +               reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> > +
> > +       if (reg == NULL) {
> > +               pr_err("Invalid memory node");
> > +               return -EINVAL;
> > +       }
> > +
> > +       return tag_storage_of_flat_get_range(node, reg, reg_len, mem);
> > +}
> > +
> > +struct find_memory_node_arg {
> > +       unsigned long node;
> > +       u32 phandle;
> > +};
> > +
> > +static int __init fdt_find_memory_node(unsigned long node, const char *uname,
> > +                                      int depth, void *data)
> > +{
> > +       const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> > +       struct find_memory_node_arg *arg = data;
> > +
> > +       if (depth != 1 || !type || strcmp(type, "memory") != 0)
> > +               return 0;
> > +
> > +       if (of_get_flat_dt_phandle(node) == arg->phandle) {
> > +               arg->node = node;
> > +               return 1;
> > +       }
> > +
> > +       return 0;
> > +}
> > +
> > +static int __init tag_storage_get_memory_node(unsigned long tag_node, unsigned long *mem_node)
> > +{
> > +       struct find_memory_node_arg arg = { 0 };
> > +       const __be32 *memory_prop;
> > +       u32 mem_phandle;
> > +       int ret, reg_len;
> > +
> > +       memory_prop = of_get_flat_dt_prop(tag_node, "memory", &reg_len);
> > +       if (!memory_prop) {
> > +               pr_err("Missing 'memory' property in the tag storage node");
> > +               return -EINVAL;
> > +       }
> > +
> > +       mem_phandle = be32_to_cpup(memory_prop);
> > +       arg.phandle = mem_phandle;
> > +
> > +       ret = of_scan_flat_dt(fdt_find_memory_node, &arg);
> 
> Do not use of_scan_flat_dt. It is a relic predating libfdt which can
> get a node by phandle directly.

I used that because that's what drivers/of/fdt.c uses. With reserved memory
I shouldn't need it, because struct reserved_mem already includes a
phandle.

> 
> > +       if (ret != 1) {
> > +               pr_err("Associated memory node not found");
> > +               return -EINVAL;
> > +       }
> > +
> > +       *mem_node = arg.node;
> > +
> > +       return 0;
> > +}
> > +
> > +static int __init tag_storage_of_flat_read_u32(unsigned long node, const char *propname,
> > +                                              u32 *retval)
> 
> If you are going to make a generic function, make it for everyone.

Sure. If I still need it, should I put the function in
include/linux/of_fdt.h?

> 
> > +{
> > +       const __be32 *reg;
> > +
> > +       reg = of_get_flat_dt_prop(node, propname, NULL);
> > +       if (!reg)
> > +               return -EINVAL;
> > +
> > +       *retval = be32_to_cpup(reg);
> > +       return 0;
> > +}
> > +
> > +static u32 __init get_block_size_pages(u32 block_size_bytes)
> > +{
> > +       u32 a = PAGE_SIZE;
> > +       u32 b = block_size_bytes;
> > +       u32 r;
> > +
> > +       /* Find greatest common divisor using the Euclidian algorithm. */
> > +       do {
> > +               r = a % b;
> > +               a = b;
> > +               b = r;
> > +       } while (b != 0);
> > +
> > +       return PHYS_PFN(PAGE_SIZE * block_size_bytes / a);
> > +}
> > +
> > +static int __init fdt_init_tag_storage(unsigned long node, const char *uname,
> > +                                      int depth, void *data)
> > +{
> > +       struct tag_region *region;
> > +       unsigned long mem_node;
> > +       struct range *mem_range;
> > +       struct range *tag_range;
> > +       u32 block_size_bytes;
> > +       u32 nid = 0;
> > +       int ret;
> > +
> > +       if (depth != 1 || !strstr(uname, "tag-storage"))
> > +               return 0;
> > +
> > +       if (!of_flat_dt_is_compatible(node, "arm,mte-tag-storage"))
> > +               return 0;
> > +
> > +       if (num_tag_regions == MAX_TAG_REGIONS) {
> > +               pr_err("Maximum number of tag storage regions exceeded");
> > +               return -EINVAL;
> > +       }
> > +
> > +       region = &tag_regions[num_tag_regions];
> > +       mem_range = &region->mem_range;
> > +       tag_range = &region->tag_range;
> > +
> > +       ret = tag_storage_of_flat_get_tag_range(node, tag_range);
> > +       if (ret) {
> > +               pr_err("Invalid tag storage node");
> > +               return ret;
> > +       }
> > +
> > +       ret = tag_storage_get_memory_node(node, &mem_node);
> > +       if (ret)
> > +               return ret;
> > +
> > +       ret = tag_storage_of_flat_get_memory_range(mem_node, mem_range);
> > +       if (ret) {
> > +               pr_err("Invalid address for associated data memory node");
> > +               return ret;
> > +       }
> > +
> > +       /* The tag region must exactly match the corresponding memory. */
> > +       if (range_len(tag_range) * 32 != range_len(mem_range)) {
> > +               pr_err("Tag storage region 0x%llx-0x%llx does not cover the memory region 0x%llx-0x%llx",
> > +                      PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->end),
> > +                      PFN_PHYS(mem_range->start), PFN_PHYS(mem_range->end));
> > +               return -EINVAL;
> > +       }
> > +
> > +       ret = tag_storage_of_flat_read_u32(node, "block-size", &block_size_bytes);
> > +       if (ret || block_size_bytes == 0) {
> > +               pr_err("Invalid or missing 'block-size' property");
> > +               return -EINVAL;
> > +       }
> > +       region->block_size = get_block_size_pages(block_size_bytes);
> > +       if (range_len(tag_range) % region->block_size != 0) {
> > +               pr_err("Tag storage region size 0x%llx is not a multiple of block size %u",
> > +                      PFN_PHYS(range_len(tag_range)), region->block_size);
> > +               return -EINVAL;
> > +       }
> > +
> > +       ret = tag_storage_of_flat_read_u32(mem_node, "numa-node-id", &nid);
> 
> I was going to say we already have a way to associate memory nodes
> other nodes using "numa-node-id", so the "memory" phandle property is
> somewhat redundant. Maybe the tag node should have a numa-node-id.
> With that, it looks like you don't even need to access the /memory
> node. Avoiding that would be good for 2 reasons. It avoids parsing
> memory nodes twice and it's not the kernel's job to validate the DT.
> Really, if you want memory info, you should use memblock to get it
> because all the special cases of memory layout are handled. For
> example you can have memory nodes with multiple 'reg' entries or
> multiple memory nodes or both, and then some of those could be
> contiguous.

I need to have a memory node associated with the tag storage node because
there is a static relationship between a page from "normal" memory and its
associated tag storage. If the code doesn't know that the memory region
A..B has the corresponding tag storage in the region X..Y, then it doesn't
know which tag storage to reserve when a page is allocated as tagged.

In the example above, assuming that page P is allocated as tagged, the
corresponding tag storage page that needs to be reserved is:

tag_storage_pfn = (page_to_pfn(P) - PHYS_PFN(A)) / 32* + PHYS_PFN(X)

numa-node-id is not enough for this, because as far I know you can have
multiple memory regions withing the same numa node.

*32 tagged pages use one tag storage page to store the tags.

Thanks,
Alex



From ninad at linux.ibm.com  Tue Dec 12 08:39:57 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 10:39:57 -0600
Subject: [PATCH v1 1/8] dt-bindings: arm: aspeed: add IBM system1-bmc
In-Reply-To: <20231212164004.1683589-1-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
Message-ID: <20231212164004.1683589-2-ninad@linux.ibm.com>

Document the new compatibles used on IBM system1-bmc

Tested:
    This board is tested using the simics simulator.

Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
---
 Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
 Documentation/devicetree/bindings/trivial-devices.yaml   | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 6f7543463d89..ebebe14c42aa 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -85,6 +85,7 @@ properties:
               - facebook,yosemite4-bmc
               - ibm,everest-bmc
               - ibm,rainier-bmc
+              - ibm,system1-bmc
               - ibm,tacoma-bmc
               - inventec,starscream-bmc
               - inventec,transformer-bmc
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 441b55723675..b12a60d2eb0f 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -135,6 +135,8 @@ properties:
           - ibm,cffps1
             # IBM Common Form Factor Power Supply Versions 2
           - ibm,cffps2
+            # Infineon barometric pressure and temperature sensor
+          - infineon,dps310
             # Infineon IR36021 digital POL buck controller
           - infineon,ir36021
             # Infineon IR38060 Voltage Regulator
-- 
2.39.2



From ninad at linux.ibm.com  Tue Dec 12 08:39:58 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 10:39:58 -0600
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <20231212164004.1683589-1-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
Message-ID: <20231212164004.1683589-3-ninad@linux.ibm.com>

From: Johannes Holland <johannes.holland at infineon.com>

Add a dt schema to support device tree bindings for the generic I2C
physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
Specification for TPM 2.0 v1.04 Revision 14.

This includes descriptions for the Nuvoton and Infineon devices.

OpenBMC-Staging-Count: 3
Signed-off-by: Johannes Holland <johannes.holland at infineon.com>
Signed-off-by: Joel Stanley <joel at jms.id.au>
Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
---
 .../bindings/security/tpm/tpm-tis-i2c.yaml    | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml

diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
new file mode 100644
index 000000000000..de1e34065748
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C PTP based TPM Devices
+
+maintainers:
+  - Johannes Holland <johannes.holland at infineon.com>
+
+description:
+  Device Tree Bindings for I2C based Trusted Platform Module (TPM).
+
+properties:
+  $nodename:
+    pattern: "^tpm(@[0-9a-f]+)?$"
+
+  compatible:
+    oneOf:
+      - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
+        items:
+          - const: infineon,slb9673
+          - const: tcg,tpm-tis-i2c
+      - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
+        items:
+          - const: nuvoton,npct75x
+          - const: tcg,tpm-tis-i2c
+      - const: tcg,tpm-tis-i2c
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      tpm at 2e {
+        compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
+        reg = <0x2e>;
+      };
+    };
+...
-- 
2.39.2



From ninad at linux.ibm.com  Tue Dec 12 08:40:00 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 10:40:00 -0600
Subject: [PATCH v1 4/8] ARM: dts: aspeed: System1: Add i2c and muxes
In-Reply-To: <20231212164004.1683589-1-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
Message-ID: <20231212164004.1683589-5-ninad@linux.ibm.com>

This commit adds i2c devices and muxes.

Tested:
    This board is tested using the simics simulator.

Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
---
 .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 577 ++++++++++++++++++
 1 file changed, 577 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
index 01291b407f59..0557bff9f36a 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
@@ -11,6 +11,65 @@ / {
 	model = "System1";
 	compatible = "ibm,system1-bmc", "aspeed,ast2600";
 
+	aliases {
+		i2c16 = &i2c8mux1chn0;
+		i2c17 = &i2c8mux1chn1;
+		i2c18 = &i2c8mux1chn2;
+		i2c19 = &i2c8mux1chn3;
+		i2c20 = &i2c8mux1chn4;
+		i2c21 = &i2c8mux1chn5;
+		i2c22 = &i2c8mux1chn6;
+		i2c23 = &i2c8mux1chn7;
+		i2c24 = &i2c3mux0chn0;
+		i2c25 = &i2c3mux0chn1;
+		i2c26 = &i2c3mux0chn2;
+		i2c27 = &i2c3mux0chn3;
+		i2c28 = &i2c3mux0chn4;
+		i2c29 = &i2c3mux0chn5;
+		i2c30 = &i2c3mux0chn6;
+		i2c31 = &i2c3mux0chn7;
+		i2c32 = &i2c6mux0chn0;
+		i2c33 = &i2c6mux0chn1;
+		i2c34 = &i2c6mux0chn2;
+		i2c35 = &i2c6mux0chn3;
+		i2c36 = &i2c6mux0chn4;
+		i2c37 = &i2c6mux0chn5;
+		i2c38 = &i2c6mux0chn6;
+		i2c39 = &i2c6mux0chn7;
+		i2c40 = &i2c7mux0chn0;
+		i2c41 = &i2c7mux0chn1;
+		i2c42 = &i2c7mux0chn2;
+		i2c43 = &i2c7mux0chn3;
+		i2c44 = &i2c7mux0chn4;
+		i2c45 = &i2c7mux0chn5;
+		i2c46 = &i2c7mux0chn6;
+		i2c47 = &i2c7mux0chn7;
+		i2c48 = &i2c8mux0chn0;
+		i2c49 = &i2c8mux0chn1;
+		i2c50 = &i2c8mux0chn2;
+		i2c51 = &i2c8mux0chn3;
+		i2c52 = &i2c8mux0chn4;
+		i2c53 = &i2c8mux0chn5;
+		i2c54 = &i2c8mux0chn6;
+		i2c55 = &i2c8mux0chn7;
+		i2c56 = &i2c14mux0chn0;
+		i2c57 = &i2c14mux0chn1;
+		i2c58 = &i2c14mux0chn2;
+		i2c59 = &i2c14mux0chn3;
+		i2c60 = &i2c14mux0chn4;
+		i2c61 = &i2c14mux0chn5;
+		i2c62 = &i2c14mux0chn6;
+		i2c63 = &i2c14mux0chn7;
+		i2c64 = &i2c15mux0chn0;
+		i2c65 = &i2c15mux0chn1;
+		i2c66 = &i2c15mux0chn2;
+		i2c67 = &i2c15mux0chn3;
+		i2c68 = &i2c15mux0chn4;
+		i2c69 = &i2c15mux0chn5;
+		i2c70 = &i2c15mux0chn6;
+		i2c71 = &i2c15mux0chn7;
+	};
+
 	chosen {
 		stdout-path = &uart5;
 		bootargs = "console=ttyS4,115200n8 earlycon";
@@ -54,10 +113,12 @@ vga_memory: region at bf000000 {
 			reg = <0xbf000000 0x01000000>;  /* 16M */
 		};
 	};
+
 };
 
 &adc1 {
 	status = "okay";
+
 	aspeed,int-vref-microvolt = <2500000>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_adc8_default
@@ -186,3 +247,519 @@ &kcs3 {
 	aspeed,lpc-io-reg = <0xca2>;
 	aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
 };
+
+&i2c0 {
+	status = "okay";
+};
+
+&i2c1 {
+	status = "okay";
+};
+
+&i2c2 {
+	status = "okay";
+};
+
+&i2c3 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9548";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+		i2c-mux-idle-disconnect;
+
+		i2c3mux0chn0: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+
+		i2c3mux0chn1: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+
+		i2c3mux0chn2: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+
+		i2c3mux0chn3: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+
+		i2c3mux0chn4: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <4>;
+		};
+
+		i2c3mux0chn5: i2c at 5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <5>;
+		};
+
+		i2c3mux0chn6: i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+		};
+
+		i2c3mux0chn7: i2c at 7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+		};
+	};
+};
+
+&i2c4 {
+	status = "okay";
+};
+
+&i2c5 {
+	status = "okay";
+};
+
+&i2c6 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9548";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+		i2c-mux-idle-disconnect;
+
+		i2c6mux0chn0: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+
+		i2c6mux0chn1: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+
+		i2c6mux0chn2: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+
+		i2c6mux0chn3: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+
+		i2c6mux0chn4: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <4>;
+		};
+
+		i2c6mux0chn5: i2c at 5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <5>;
+		};
+
+		i2c6mux0chn6: i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+		};
+
+		i2c6mux0chn7: i2c at 7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+		};
+	};
+};
+
+&i2c7 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9548";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+		i2c-mux-idle-disconnect;
+
+		i2c7mux0chn0: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+
+		i2c7mux0chn1: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+
+		i2c7mux0chn2: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+
+		i2c7mux0chn3: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+
+		i2c7mux0chn4: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <4>;
+		};
+
+		i2c7mux0chn5: i2c at 5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <5>;
+		};
+
+		i2c7mux0chn6: i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+		};
+
+		i2c7mux0chn7: i2c at 7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+		};
+	};
+};
+
+&i2c8 {
+	status = "okay";
+
+	i2c-mux at 71 {
+		compatible = "nxp,pca9548";
+		reg = <0x71>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+		i2c-mux-idle-disconnect;
+
+		i2c8mux0chn0: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+
+		i2c8mux0chn1: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+
+		i2c8mux0chn2: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+
+		i2c8mux0chn3: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+
+		i2c8mux0chn4: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <4>;
+
+			i2c-mux at 70 {
+				compatible = "nxp,pca9548";
+				reg = <0x70>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "okay";
+				i2c-mux-idle-disconnect;
+
+				i2c8mux1chn0: i2c at 0 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0>;
+				};
+
+				i2c8mux1chn1: i2c at 1 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <1>;
+				};
+
+				i2c8mux1chn2: i2c at 2 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <2>;
+				};
+
+				i2c8mux1chn3: i2c at 3 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <3>;
+				};
+
+				i2c8mux1chn4: i2c at 4 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <4>;
+				};
+
+				i2c8mux1chn5: i2c at 5 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <5>;
+				};
+
+				i2c8mux1chn6: i2c at 6 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <6>;
+				};
+
+				i2c8mux1chn7: i2c at 7 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <7>;
+				};
+			};
+		};
+
+		i2c8mux0chn5: i2c at 5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <5>;
+		};
+
+		i2c8mux0chn6: i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+		};
+
+		i2c8mux0chn7: i2c at 7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+		};
+	};
+};
+
+&i2c9 {
+	status = "okay";
+};
+
+&i2c11 {
+	status = "okay";
+};
+
+&i2c12 {
+	status = "okay";
+};
+
+&i2c13 {
+	status = "okay";
+};
+
+&i2c14 {
+	status = "okay";
+
+	i2c-mux at 70 {
+		compatible = "nxp,pca9548";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+		i2c-mux-idle-disconnect;
+
+		i2c14mux0chn0: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+
+		i2c14mux0chn1: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+
+		i2c14mux0chn2: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+
+		i2c14mux0chn3: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+
+		i2c14mux0chn4: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <4>;
+		};
+
+		i2c14mux0chn5: i2c at 5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <5>;
+		};
+
+		i2c14mux0chn6: i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+		};
+
+		i2c14mux0chn7: i2c at 7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+		};
+	};
+};
+
+&i2c15 {
+	status = "okay";
+
+	i2c-mux at 71 {
+		compatible = "nxp,pca9548";
+		reg = <0x71>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+		i2c-mux-idle-disconnect;
+
+		i2c15mux0chn0: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+
+		i2c15mux0chn1: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+
+		i2c15mux0chn2: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+
+		i2c15mux0chn3: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+
+		i2c15mux0chn4: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <4>;
+
+			i2c-mux at 70 {
+				compatible = "nxp,pca9548";
+				reg = <0x70>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "okay";
+				i2c-mux-idle-disconnect;
+
+				i2c15mux1chn0: i2c at 0 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0>;
+				};
+
+				i2c15mux1chn1: i2c at 1 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <1>;
+				};
+
+				i2c15mux1chn2: i2c at 2 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <2>;
+				};
+
+				i2c15mux1chn3: i2c at 3 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <3>;
+				};
+
+				i2c15mux1chn4: i2c at 4 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <4>;
+				};
+
+				i2c15mux1chn5: i2c at 5 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <5>;
+				};
+
+				i2c15mux1chn6: i2c at 6 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <6>;
+				};
+
+				i2c15mux1chn7: i2c at 7 {
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <7>;
+				};
+			};
+		};
+
+		i2c15mux0chn5: i2c at 5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <5>;
+		};
+
+		i2c15mux0chn6: i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+		};
+
+		i2c15mux0chn7: i2c at 7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+		};
+	};
+};
-- 
2.39.2



From ninad at linux.ibm.com  Tue Dec 12 08:40:01 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 10:40:01 -0600
Subject: [PATCH v1 5/8] ARM: dts: aspeed: System1: Voltage regulators
In-Reply-To: <20231212164004.1683589-1-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
Message-ID: <20231212164004.1683589-6-ninad@linux.ibm.com>

This commit adds different voltage regulators.

Tested:
    This board is tested using the simics simulator.

Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
---
 .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 266 ++++++++++++++++++
 1 file changed, 266 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
index 0557bff9f36a..b8e7e52d4600 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
@@ -114,10 +114,127 @@ vga_memory: region at bf000000 {
 		};
 	};
 
+	iio-hwmon {
+		compatible = "iio-hwmon";
+		io-channels = <&p12v_vd 0>, <&p5v_aux_vd 0>,
+			<&p5v_bmc_aux_vd 0>, <&p3v3_aux_vd 0>,
+			<&p3v3_bmc_aux_vd 0>, <&p1v8_bmc_aux_vd 0>,
+			<&adc1 4>, <&adc0 2>, <&adc1 0>,
+			<&p2V5_aux_vd 0>, <&adc1 7>;
+	};
+
+	p12v_vd: voltage_divider1 {
+		compatible = "voltage-divider";
+		io-channels = <&adc1 3>;
+		#io-channel-cells = <1>;
+
+		/* Scale the system voltage by 1127/127 to fit the ADC range.
+		 * Use small nominator to prevent integer overflow.
+		 */
+		output-ohms = <15>;
+		full-ohms = <133>;
+	};
+
+	p5v_aux_vd: voltage_divider2 {
+		compatible = "voltage-divider";
+		io-channels = <&adc1 5>;
+		#io-channel-cells = <1>;
+
+		/* Scale the system voltage by 1365/365 to fit the ADC range.
+		 * Use small nominator to prevent integer overflow.
+		 */
+		output-ohms = <50>;
+		full-ohms = <187>;
+	};
+
+	p5v_bmc_aux_vd: voltage_divider3 {
+		compatible = "voltage-divider";
+		io-channels = <&adc0 3>;
+		#io-channel-cells = <1>;
+
+		/* Scale the system voltage by 1365/365 to fit the ADC range.
+		 * Use small nominator to prevent integer overflow.
+		 */
+		output-ohms = <50>;
+		full-ohms = <187>;
+	};
+
+	p3v3_aux_vd: voltage_divider4 {
+		compatible = "voltage-divider";
+		io-channels = <&adc1 2>;
+		#io-channel-cells = <1>;
+
+		/* Scale the system voltage by 1698/698 to fit the ADC range.
+		 * Use small nominator to prevent integer overflow.
+		 */
+		output-ohms = <14>;
+		full-ohms = <34>;
+	};
+
+	p3v3_bmc_aux_vd: voltage_divider5 {
+		compatible = "voltage-divider";
+		io-channels = <&adc0 7>;
+		#io-channel-cells = <1>;
+
+		/* Scale the system voltage by 1698/698 to fit the ADC range.
+		 * Use small nominator to prevent integer overflow.
+		 */
+		output-ohms = <14>;
+		full-ohms = <34>;
+	};
+
+	p1v8_bmc_aux_vd: voltage_divider6 {
+		compatible = "voltage-divider";
+		io-channels = <&adc0 6>;
+		#io-channel-cells = <1>;
+
+		/* Scale the system voltage by 4000/3000 to fit the ADC range.
+		 * Use small nominator to prevent integer overflow.
+		 */
+		output-ohms = <3>;
+		full-ohms = <4>;
+	};
+
+	p2V5_aux_vd: voltage_divider7 {
+		compatible = "voltage-divider";
+		io-channels = <&adc1 1>;
+		#io-channel-cells = <1>;
+
+		/* Scale the system voltage by 2100/1100 to fit the ADC range.
+		 * Use small nominator to prevent integer overflow.
+		 */
+		output-ohms = <11>;
+		full-ohms = <21>;
+	};
+
+	p1v8_bmc_aux: fixedregulator-p1v8_bmc_aux {
+		compatible = "regulator-fixed";
+		regulator-name = "p1v8_bmc_aux";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+	};
+};
+
+&adc0 {
+	status = "okay";
+	vref-supply = <&p1v8_bmc_aux>;
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc0_default
+		&pinctrl_adc1_default
+		&pinctrl_adc2_default
+		&pinctrl_adc3_default
+		&pinctrl_adc4_default
+		&pinctrl_adc5_default
+		&pinctrl_adc6_default
+		&pinctrl_adc7_default>;
 };
 
 &adc1 {
 	status = "okay";
+	vref-supply = <&p1v8_bmc_aux>;
+	aspeed,battery-sensing;
 
 	aspeed,int-vref-microvolt = <2500000>;
 	pinctrl-names = "default";
@@ -250,10 +367,32 @@ &kcs3 {
 
 &i2c0 {
 	status = "okay";
+
+	regulator at 60 {
+		compatible = "maxim,max8952";
+		reg = <0x60>;
+
+		max8952,default-mode = <0>;
+		max8952,dvs-mode-microvolt = <1250000>, <1200000>,
+						<1050000>, <950000>;
+		max8952,sync-freq = <0>;
+		max8952,ramp-speed = <0>;
+
+		regulator-name = "VR_1.0V";
+		regulator-min-microvolt = <770000>;
+		regulator-max-microvolt = <1400000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
 };
 
 &i2c1 {
 	status = "okay";
+
+	regulator at 42 {
+		compatible = "infineon,ir38263";
+		reg = <0x42>;
+	};
 };
 
 &i2c2 {
@@ -327,6 +466,21 @@ &i2c4 {
 
 &i2c5 {
 	status = "okay";
+
+	regulator at 3a {
+		compatible = "maxim,max5970";
+		reg = <0x3a>;
+	};
+
+	regulator at 42 {
+		compatible = "infineon,ir38263";
+		reg = <0x42>;
+	};
+
+	regulator at 43 {
+		compatible = "infineon,ir38060";
+		reg = <0x43>;
+	};
 };
 
 &i2c6 {
@@ -423,6 +577,11 @@ i2c7mux0chn3: i2c at 3 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <3>;
+
+			regulator at 58 {
+				compatible = "mps,mp2973";
+				reg = <0x58>;
+			};
 		};
 
 		i2c7mux0chn4: i2c at 4 {
@@ -435,6 +594,11 @@ i2c7mux0chn5: i2c at 5 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <5>;
+
+			regulator at 40 {
+				compatible = "infineon,tda38640";
+				reg = <0x40>;
+			};
 		};
 
 		i2c7mux0chn6: i2c at 6 {
@@ -466,12 +630,37 @@ i2c8mux0chn0: i2c at 0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
+
+			regulator at 58 {
+				compatible = "mps,mp2971";
+				reg = <0x58>;
+			};
 		};
 
 		i2c8mux0chn1: i2c at 1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <1>;
+
+			regulator at 40 {
+				compatible = "infineon,tda38640";
+				reg = <0x40>;
+			};
+
+			regulator at 41 {
+				compatible = "infineon,tda38640";
+				reg = <0x41>;
+			};
+
+			regulator at 58 {
+				compatible = "mps,mp2971";
+				reg = <0x58>;
+			};
+
+			regulator at 5b {
+				compatible = "mps,mp2971";
+				reg = <0x5b>;
+			};
 		};
 
 		i2c8mux0chn2: i2c at 2 {
@@ -565,12 +754,44 @@ i2c8mux0chn7: i2c at 7 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <7>;
+
+			regulator at 40 {
+				compatible = "infineon,ir38060";
+				reg = <0x40>;
+			};
 		};
 	};
 };
 
 &i2c9 {
 	status = "okay";
+
+	regulator at 40 {
+		compatible = "infineon,ir38263";
+		reg = <0x40>;
+	};
+
+	regulator at 41 {
+		compatible = "infineon,ir38263";
+		reg = <0x41>;
+	};
+
+	regulator at 60 {
+		compatible = "maxim,max8952";
+		reg = <0x60>;
+
+		max8952,default-mode = <0>;
+		max8952,dvs-mode-microvolt = <1250000>, <1200000>,
+						<1050000>, <950000>;
+		max8952,sync-freq = <0>;
+		max8952,ramp-speed = <0>;
+
+		regulator-name = "VR_1.2V";
+		regulator-min-microvolt = <770000>;
+		regulator-max-microvolt = <1400000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
 };
 
 &i2c11 {
@@ -583,6 +804,11 @@ &i2c12 {
 
 &i2c13 {
 	status = "okay";
+
+	regulator at 41 {
+		compatible = "infineon,ir38263";
+		reg = <0x41>;
+	};
 };
 
 &i2c14 {
@@ -618,6 +844,11 @@ i2c14mux0chn3: i2c at 3 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <3>;
+
+			regulator at 58 {
+				compatible = "mps,mp2973";
+				reg = <0x58>;
+			};
 		};
 
 		i2c14mux0chn4: i2c at 4 {
@@ -630,6 +861,11 @@ i2c14mux0chn5: i2c at 5 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <5>;
+
+			regulator at 40 {
+				compatible = "infineon,tda38640";
+				reg = <0x40>;
+			};
 		};
 
 		i2c14mux0chn6: i2c at 6 {
@@ -661,12 +897,37 @@ i2c15mux0chn0: i2c at 0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
+
+			regulator at 58 {
+				compatible = "mps,mp2971";
+				reg = <0x58>;
+			};
 		};
 
 		i2c15mux0chn1: i2c at 1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <1>;
+
+			regulator at 40 {
+				compatible = "infineon,tda38640";
+				reg = <0x40>;
+			};
+
+			regulator at 41 {
+				compatible = "infineon,tda38640";
+				reg = <0x41>;
+			};
+
+			regulator at 58 {
+				compatible = "mps,mp2971";
+				reg = <0x58>;
+			};
+
+			regulator at 5b {
+				compatible = "mps,mp2971";
+				reg = <0x5b>;
+			};
 		};
 
 		i2c15mux0chn2: i2c at 2 {
@@ -760,6 +1021,11 @@ i2c15mux0chn7: i2c at 7 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <7>;
+
+			regulator at 40 {
+				compatible = "infineon,ir38060";
+				reg = <0x40>;
+			};
 		};
 	};
 };
-- 
2.39.2



From ninad at linux.ibm.com  Tue Dec 12 08:40:03 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 10:40:03 -0600
Subject: [PATCH v1 7/8] tpm: tis-i2c: Add more compatible strings
In-Reply-To: <20231212164004.1683589-1-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
Message-ID: <20231212164004.1683589-8-ninad@linux.ibm.com>

From: Joel Stanley <joel at jms.id.au>

The NPCT75x TPM is TIS compatible. It has an I2C and SPI interface.

https://www.nuvoton.com/products/cloud-computing/security/trusted-platform-module-tpm/

Add a compatible string for it, and the generic compatible.

OpenBMC-Staging-Count: 3
Signed-off-by: Joel Stanley <joel at jms.id.au>
Acked-by: Jarkko Sakkinen <jarkko at kernel.org>
Link: https://lore.kernel.org/r/20220928043957.2636877-4-joel at jms.id.au
Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
---
 drivers/char/tpm/tpm_tis_i2c.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/char/tpm/tpm_tis_i2c.c b/drivers/char/tpm/tpm_tis_i2c.c
index a897402cc36a..9511c0d50185 100644
--- a/drivers/char/tpm/tpm_tis_i2c.c
+++ b/drivers/char/tpm/tpm_tis_i2c.c
@@ -383,6 +383,8 @@ MODULE_DEVICE_TABLE(i2c, tpm_tis_i2c_id);
 #ifdef CONFIG_OF
 static const struct of_device_id of_tis_i2c_match[] = {
 	{ .compatible = "infineon,slb9673", },
+	{ .compatible = "nuvoton,npct75x", },
+	{ .compatible = "tcg,tpm-tis-i2c", },
 	{}
 };
 MODULE_DEVICE_TABLE(of, of_tis_i2c_match);
-- 
2.39.2



From ninad at linux.ibm.com  Tue Dec 12 08:40:02 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 10:40:02 -0600
Subject: [PATCH v1 6/8] ARM: dts: aspeed: System1: GPIO, Fan ctrl, Led
In-Reply-To: <20231212164004.1683589-1-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
Message-ID: <20231212164004.1683589-7-ninad@linux.ibm.com>

This commit adds following devices to the device tree.
- GPIO pin assignements, GPIO expansion devices
- LED brinker devices
- Fan controllers

Tested:
    This board is tested using the simics simulator.

Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
---
 .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 547 +++++++++++++++++-
 1 file changed, 542 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
index b8e7e52d4600..75562aa63701 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
@@ -114,6 +114,99 @@ vga_memory: region at bf000000 {
 		};
 	};
 
+	leds {
+		compatible = "gpio-leds";
+
+		bmc-ready {
+			gpios = <&gpio0 ASPEED_GPIO(L, 7) GPIO_ACTIVE_HIGH>;
+		};
+
+		bmc-hb {
+			gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_HIGH>;
+		};
+
+		rear-enc-fault0 {
+			gpios = <&gpio0 ASPEED_GPIO(S, 6) GPIO_ACTIVE_HIGH>;
+		};
+
+		rear-enc-id0 {
+			gpios = <&gpio0 ASPEED_GPIO(S, 7) GPIO_ACTIVE_HIGH>;
+		};
+
+		fan0-fault-led {
+			gpios = <&pca3 5 GPIO_ACTIVE_LOW>;
+		};
+
+		fan1-fault-led {
+			gpios = <&pca3 6 GPIO_ACTIVE_LOW>;
+		};
+
+		fan2-fault-led {
+			gpios = <&pca3 7 GPIO_ACTIVE_LOW>;
+		};
+
+		fan3-fault-led {
+			gpios = <&pca3 8 GPIO_ACTIVE_LOW>;
+		};
+
+		fan4-fault-led {
+			gpios = <&pca3 9 GPIO_ACTIVE_LOW>;
+		};
+
+		fan5-fault-led {
+			gpios = <&pca3 10 GPIO_ACTIVE_LOW>;
+		};
+
+		fan6-fault-led {
+			gpios = <&pca3 11 GPIO_ACTIVE_LOW>;
+		};
+
+		nvmed0-fault-led {
+			gpios = <&pca4 4 GPIO_ACTIVE_HIGH>;
+		};
+
+		nvmed1-fault-led {
+			gpios = <&pca4 5 GPIO_ACTIVE_HIGH>;
+		};
+
+		nvmed2-fault-led {
+			gpios = <&pca4 6 GPIO_ACTIVE_HIGH>;
+		};
+
+		nvmed3-fault-led {
+			gpios = <&pca4 7 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	gpio-keys-polled {
+		compatible = "gpio-keys-polled";
+		poll-interval = <1000>;
+
+		event-nvme0-presence {
+			label = "nvme0-presence";
+			gpios = <&pca4 0 GPIO_ACTIVE_LOW>;
+			linux,code = <0>;
+		};
+
+		event-nvme1-presence {
+			label = "nvme1-presence";
+			gpios = <&pca4 1 GPIO_ACTIVE_LOW>;
+			linux,code = <1>;
+		};
+
+		event-nvme2-presence {
+			label = "nvme2-presence";
+			gpios = <&pca4 2 GPIO_ACTIVE_LOW>;
+			linux,code = <2>;
+		};
+
+		event-nvme3-presence {
+			label = "nvme3-presence";
+			gpios = <&pca4 3 GPIO_ACTIVE_LOW>;
+			linux,code = <3>;
+		};
+	};
+
 	iio-hwmon {
 		compatible = "iio-hwmon";
 		io-channels = <&p12v_vd 0>, <&p5v_aux_vd 0>,
@@ -259,7 +352,7 @@ &uhci {
 &gpio0 {
 	gpio-line-names =
 	/*A0-A7*/	"","","","","","","","",
-	/*B0-B7*/	"","","","","","","","",
+	/*B0-B7*/	"","","","","bmc-tpm-reset","","","",
 	/*C0-C7*/	"","","","","","","","",
 	/*D0-D7*/	"","","","","","","","",
 	/*E0-E7*/	"","","","","","","","",
@@ -269,17 +362,17 @@ &gpio0 {
 	/*I0-I7*/	"","","","","","","","",
 	/*J0-J7*/	"","","","","","","","",
 	/*K0-K7*/	"","","","","","","","",
-	/*L0-L7*/	"","","","","","","","",
+	/*L0-L7*/	"","","","","","","","bmc-ready",
 	/*M0-M7*/	"","","","","","","","",
 	/*N0-N7*/	"","","","","","","","",
 	/*O0-O7*/	"","","","","","","","",
-	/*P0-P7*/	"","","","","","","","",
+	/*P0-P7*/	"","","","","","","","bmc-hb",
 	/*Q0-Q7*/	"","","","","","","","",
 	/*R0-R7*/	"","","","","","","","",
-	/*S0-S7*/	"","","","","","","","",
+	/*S0-S7*/	"","","","","","","rear-enc-fault0","rear-enc-id0",
 	/*T0-T7*/	"","","","","","","","",
 	/*U0-U7*/	"","","","","","","","",
-	/*V0-V7*/	"","","","power-chassis-control","","","","",
+	/*V0-V7*/	"","rtc-battery-voltage-read-enable","","power-chassis-control","","","","",
 	/*W0-W7*/	"","","","","","","","",
 	/*X0-X7*/	"","power-chassis-good","","","","","","",
 	/*Y0-Y7*/	"","","","","","","","",
@@ -393,6 +486,171 @@ regulator at 42 {
 		compatible = "infineon,ir38263";
 		reg = <0x42>;
 	};
+
+	led-controller at 60 {
+		compatible = "nxp,pca9552";
+		reg = <0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		led at 0 {
+			label = "nic1-perst";
+			reg = <0>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 1 {
+			label = "bmc-perst";
+			reg = <1>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 2 {
+			label = "reset-M2-SSD1-2-perst";
+			reg = <2>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 3 {
+			label = "pcie-perst1";
+			reg = <3>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 4 {
+			label = "pcie-perst2";
+			reg = <4>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 5 {
+			label = "pcie-perst3";
+			reg = <5>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 6 {
+			label = "pcie-perst4";
+			reg = <6>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 7 {
+			label = "pcie-perst5";
+			reg = <7>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 8 {
+			label = "pcie-perst6";
+			reg = <8>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 9 {
+			label = "pcie-perst7";
+			reg = <9>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 10 {
+			label = "pcie-perst8";
+			reg = <10>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 11 {
+			label = "PV-cp0-sw1stk4-perst";
+			reg = <11>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 12 {
+			label = "PV-cp0-sw1stk5-perst";
+			reg = <12>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 13 {
+			label = "pe-cp-drv0-perst";
+			reg = <13>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 14 {
+			label = "pe-cp-drv1-perst";
+			reg = <14>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 15 {
+			label = "lom-perst";
+			reg = <15>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+	};
+
+	pca0: pca9539 at 74 {
+		compatible = "nxp,pca9539";
+		reg = <0x74>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		gpio-line-names =
+			"PLUG_DETECT_PCIE_J101_N",
+			"PLUG_DETECT_PCIE_J102_N",
+			"PLUG_DETECT_PCIE_J103_N",
+			"PLUG_DETECT_PCIE_J104_N",
+			"PLUG_DETECT_PCIE_J105_N",
+			"PLUG_DETECT_PCIE_J106_N",
+			"PLUG_DETECT_PCIE_J107_N",
+			"PLUG_DETECT_PCIE_J108_N",
+			"PLUG_DETECT_M2_SSD1_N",
+			"PLUG_DETECT_NIC1_N",
+			"SEL_SMB_DIMM_CPU0",
+			"presence-ps2",
+			"presence-ps3",
+			"", "",
+			"PWRBRD_PLUG_DETECT2_N";
+	};
 };
 
 &i2c2 {
@@ -486,6 +744,20 @@ regulator at 43 {
 &i2c6 {
 	status = "okay";
 
+	fan-controller at 52 {
+		compatible = "maxim,max31785a";
+		reg = <0x52>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	fan-controller at 54 {
+		compatible = "maxim,max31785a";
+		reg = <0x54>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
 	i2c-mux at 70 {
 		compatible = "nxp,pca9548";
 		reg = <0x70>;
@@ -522,6 +794,48 @@ i2c6mux0chn4: i2c at 4 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <4>;
+
+			led-controller at 60 {
+				compatible = "nxp,pca9551";
+				reg = <0x60>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				gpio-controller;
+				#gpio-cells = <2>;
+
+				led at 0 {
+					label = "enclosure-id-led";
+					reg = <0>;
+					retain-state-shutdown;
+					default-state = "keep";
+					type = <PCA955X_TYPE_LED>;
+				};
+
+				led at 1 {
+					label = "attention-led";
+					reg = <1>;
+					retain-state-shutdown;
+					default-state = "keep";
+					type = <PCA955X_TYPE_LED>;
+				};
+
+				led at 2 {
+					label = "enclosure-fault-rollup-led";
+					reg = <2>;
+					retain-state-shutdown;
+					default-state = "keep";
+					type = <PCA955X_TYPE_LED>;
+				};
+
+				led at 3 {
+					label = "power-on-led";
+					reg = <3>;
+					retain-state-shutdown;
+					default-state = "keep";
+					type = <PCA955X_TYPE_LED>;
+				};
+			};
 		};
 
 		i2c6mux0chn5: i2c at 5 {
@@ -542,6 +856,44 @@ i2c6mux0chn7: i2c at 7 {
 			reg = <7>;
 		};
 	};
+
+	pca3: pca9539 at 74 {
+		compatible = "nxp,pca9539";
+		reg = <0x74>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	pca4: pca9539 at 77 {
+		compatible = "nxp,pca9539";
+		reg = <0x77>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		gpio-line-names =
+			"PE_NVMED0_EXP_PRSNT_N",
+			"PE_NVMED1_EXP_PRSNT_N",
+			"PE_NVMED2_EXP_PRSNT_N",
+			"PE_NVMED3_EXP_PRSNT_N",
+			"LED_FAULT_NVMED0",
+			"LED_FAULT_NVMED1",
+			"LED_FAULT_NVMED2",
+			"LED_FAULT_NVMED3",
+			"FAN0_PRESENCE_R_N",
+			"FAN1_PRESENCE_R_N",
+			"FAN2_PRESENCE_R_N",
+			"FAN3_PRESENCE_R_N",
+			"FAN4_PRESENCE_R_N",
+			"FAN5_PRESENCE_N",
+			"FAN6_PRESENCE_N",
+			"";
+	};
 };
 
 &i2c7 {
@@ -809,6 +1161,191 @@ regulator at 41 {
 		compatible = "infineon,ir38263";
 		reg = <0x41>;
 	};
+
+	led-controller at 61 {
+		compatible = "nxp,pca9552";
+		reg = <0x61>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		led at 0 {
+			label = "efuse-12v-slots";
+			reg = <0>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 1 {
+			label = "efuse-3p3v-slot";
+			reg = <1>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 3 {
+			label = "nic2-pert";
+			reg = <3>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 4 {
+			label = "pcie-perst9";
+			reg = <4>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 5 {
+			label = "pcie-perst10";
+			reg = <5>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 6 {
+			label = "pcie-perst11";
+			reg = <6>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 7 {
+			label = "pcie-perst12";
+			reg = <7>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 8 {
+			label = "pcie-perst13";
+			reg = <8>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 9 {
+			label = "pcie-perst14";
+			reg = <9>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 10 {
+			label = "pcie-perst15";
+			reg = <10>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 11 {
+			label = "pcie-perst16";
+			reg = <11>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 12 {
+			label = "PV-cp1-sw1stk4-perst";
+			reg = <12>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 13 {
+			label = "PV-cp1-sw1stk5-perst";
+			reg = <13>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 14 {
+			label = "pe-cp-drv2-perst";
+			reg = <14>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+
+		led at 15 {
+			label = "pe-cp-drv3-perst";
+			reg = <15>;
+			retain-state-shutdown;
+			default-state = "keep";
+			type = <PCA955X_TYPE_LED>;
+		};
+	};
+
+	pca1: pca9539 at 75 {
+		compatible = "nxp,pca9539";
+		reg = <0x75>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		gpio-line-names =
+			"PLUG_DETECT_PCIE_J109_N",
+			"PLUG_DETECT_PCIE_J110_N",
+			"PLUG_DETECT_PCIE_J111_N",
+			"PLUG_DETECT_PCIE_J112_N",
+			"PLUG_DETECT_PCIE_J113_N",
+			"PLUG_DETECT_PCIE_J114_N",
+			"PLUG_DETECT_PCIE_J115_N",
+			"PLUG_DETECT_PCIE_J116_N",
+			"PLUG_DETECT_M2_SSD2_N",
+			"PLUG_DETECT_NIC2_N",
+			"SEL_SMB_DIMM_CPU1",
+			"presence-ps0",
+			"presence-ps1",
+			"", "",
+			"PWRBRD_PLUG_DETECT1_N";
+	};
+
+	pca2: pca9539 at 76 {
+		compatible = "nxp,pca9539";
+		reg = <0x76>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		gpio-line-names =
+			"SW1_BOOTRCVRYB1_N",
+			"SW1_BOOTRCVRYB0_N",
+			"SW2_BOOTRCVRYB1_N",
+			"SW2_BOOTRCVRYB0_N",
+			"SW3_4_BOOTRCVRYB1_N",
+			"SW3_4_BOOTRCVRYB0_N",
+			"SW5_BOOTRCVRYB1_N",
+			"SW5_BOOTRCVRYB0_N",
+			"SW6_BOOTRCVRYB1_N",
+			"SW6_BOOTRCVRYB0_N",
+			"SW1_RESET_N",
+			"SW3_RESET_N",
+			"SW4_RESET_N",
+			"SW2_RESET_N",
+			"SW5_RESET_N",
+			"SW6_RESET_N";
+	};
 };
 
 &i2c14 {
-- 
2.39.2



From ninad at linux.ibm.com  Tue Dec 12 08:40:04 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 10:40:04 -0600
Subject: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
In-Reply-To: <20231212164004.1683589-1-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
Message-ID: <20231212164004.1683589-9-ninad@linux.ibm.com>

This drop adds following devices in the device tree.
- EEPROM/VPD
- Power supplies
- Humidity, pressure and temperature sensors.
- Trusted platform module(TPM) chip

Tested:
    This board is tested using the simics simulator.

Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
---
 .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 76 +++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
index 75562aa63701..d960b938fe8d 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
@@ -461,6 +461,11 @@ &kcs3 {
 &i2c0 {
 	status = "okay";
 
+	eeprom at 50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+	};
+
 	regulator at 60 {
 		compatible = "maxim,max8952";
 		reg = <0x60>;
@@ -655,6 +660,25 @@ pca0: pca9539 at 74 {
 
 &i2c2 {
 	status = "okay";
+
+	power-supply at 58 {
+		compatible = "ibm,cffps";
+		reg = <0x58>;
+	};
+
+	power-supply at 59 {
+		compatible = "ibm,cffps";
+		reg = <0x59>;
+	};
+
+	power-supply at 5a {
+		compatible = "ibm,cffps";
+		reg = <0x5a>;
+	};
+	power-supply at 5b {
+		compatible = "ibm,cffps";
+		reg = <0x5b>;
+	};
 };
 
 &i2c3 {
@@ -758,6 +782,11 @@ fan-controller at 54 {
 		#size-cells = <0>;
 	};
 
+	eeprom at 55 {
+		compatible = "atmel,24c64";
+		reg = <0x55>;
+	};
+
 	i2c-mux at 70 {
 		compatible = "nxp,pca9548";
 		reg = <0x70>;
@@ -795,6 +824,21 @@ i2c6mux0chn4: i2c at 4 {
 			#size-cells = <0>;
 			reg = <4>;
 
+			humidity-sensor at 40 {
+				compatible = "ti,hdc1080";
+				reg = <0x40>;
+			};
+
+			temperature-sensor at 48 {
+				compatible = "ti,tmp275";
+				reg = <0x48>;
+			};
+
+			eeprom at 50 {
+				compatible = "atmel,24c32";
+				reg = <0x50>;
+			};
+
 			led-controller at 60 {
 				compatible = "nxp,pca9551";
 				reg = <0x60>;
@@ -836,6 +880,12 @@ led at 3 {
 					type = <PCA955X_TYPE_LED>;
 				};
 			};
+
+			temperature-sensor at 76 {
+				compatible = "infineon,dps310";
+				reg = <0x76>;
+				#io-channel-cells = <0>;
+			};
 		};
 
 		i2c6mux0chn5: i2c at 5 {
@@ -1100,6 +1150,11 @@ i2c8mux0chn6: i2c at 6 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <6>;
+
+			temperature-sensor at 4c {
+				compatible = "ti,tmp423";
+				reg = <0x4c>;
+			};
 		};
 
 		i2c8mux0chn7: i2c at 7 {
@@ -1128,6 +1183,11 @@ regulator at 41 {
 		reg = <0x41>;
 	};
 
+	eeprom at 50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+	};
+
 	regulator at 60 {
 		compatible = "maxim,max8952";
 		reg = <0x60>;
@@ -1148,6 +1208,12 @@ regulator at 60 {
 
 &i2c11 {
 	status = "okay";
+
+	tpm at 2e {
+		compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
+		reg = <0x2e>;
+		memory-region = <&event_log>;
+	};
 };
 
 &i2c12 {
@@ -1552,6 +1618,11 @@ i2c15mux0chn6: i2c at 6 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <6>;
+
+			temperature-sensor at 4c {
+				compatible = "ti,tmp423";
+				reg = <0x4c>;
+			};
 		};
 
 		i2c15mux0chn7: i2c at 7 {
@@ -1563,6 +1634,11 @@ regulator at 40 {
 				compatible = "infineon,ir38060";
 				reg = <0x40>;
 			};
+
+			temperature-sensor at 4c {
+				compatible = "ti,tmp423";
+				reg = <0x4c>;
+			};
 		};
 	};
 };
-- 
2.39.2



From ninad at linux.ibm.com  Tue Dec 12 08:39:56 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 10:39:56 -0600
Subject: [PATCH v1 0/8] Add device tree for IBM system1 BMC
Message-ID: <20231212164004.1683589-1-ninad@linux.ibm.com>

This patchset adds device tree for IBM system1 bmc board.

Change log:
v1:
 - Added device binding for IBM system1-bmc
 - Added device binding for TIS I2C devices
 - Added device tree for IBM system1 BMC board
 - Added i2c and muxes
 - Added voltage regulators
 - Added GPIO, Fan ctrl, Led
 - Added more compatible strings for tpm_tis_i2c
 - Added power supplies, sensors, EEPROMS, TPM and more

Andrew Geissler (1):
  ARM: dts: aspeed: System1: IBM system1 BMC board

Joel Stanley (1):
  tpm: tis-i2c: Add more compatible strings

Johannes Holland (1):
  dt-bindings: tpm: Add schema for TIS I2C devices

Ninad Palsule (5):
  dt-bindings: arm: aspeed: add IBM system1-bmc
  ARM: dts: aspeed: System1: Add i2c and muxes
  ARM: dts: aspeed: System1: Voltage regulators
  ARM: dts: aspeed: System1: GPIO, Fan ctrl, Led
  ARM: dts: aspeed: System1: PS, sensor and more

 .../bindings/arm/aspeed/aspeed.yaml           |    1 +
 .../bindings/security/tpm/tpm-tis-i2c.yaml    |   50 +
 .../devicetree/bindings/trivial-devices.yaml  |    2 +
 arch/arm/boot/dts/aspeed/Makefile             |    1 +
 .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 1644 +++++++++++++++++
 drivers/char/tpm/tpm_tis_i2c.c                |    2 +
 6 files changed, 1700 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts

-- 
2.39.2



From ninad at linux.ibm.com  Tue Dec 12 08:39:59 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 10:39:59 -0600
Subject: [PATCH v1 3/8] ARM: dts: aspeed: System1: IBM system1 BMC board
In-Reply-To: <20231212164004.1683589-1-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
Message-ID: <20231212164004.1683589-4-ninad@linux.ibm.com>

From: Andrew Geissler <geissonator at yahoo.com>

Add a device tree for IBM system1 BMC board. It uses AST2600 SOC.

Tested:
    This board is tested using the simics simulator.

Signed-off-by: Andrew Geissler <geissonator at yahoo.com>
Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
---
 arch/arm/boot/dts/aspeed/Makefile             |   1 +
 .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 188 ++++++++++++++++++
 2 files changed, 189 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts

diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 3e3e6b96cb79..6f7ed11978ff 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -35,6 +35,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-ibm-rainier.dtb \
 	aspeed-bmc-ibm-rainier-1s4u.dtb \
 	aspeed-bmc-ibm-rainier-4u.dtb \
+	aspeed-bmc-ibm-system1.dtb \
 	aspeed-bmc-intel-s2600wf.dtb \
 	aspeed-bmc-inspur-fp5280g2.dtb \
 	aspeed-bmc-inspur-nf5280m6.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
new file mode 100644
index 000000000000..01291b407f59
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2023 IBM Corp.
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/i2c/i2c.h>
+#include <dt-bindings/leds/leds-pca955x.h>
+
+/ {
+	model = "System1";
+	compatible = "ibm,system1-bmc", "aspeed,ast2600";
+
+	chosen {
+		stdout-path = &uart5;
+		bootargs = "console=ttyS4,115200n8 earlycon";
+	};
+
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		event_log: tcg_event_log at b3d00000 {
+			no-map;
+			reg = <0xb3d00000 0x100000>;
+		};
+
+		ramoops at b3e00000 {
+			compatible = "ramoops";
+			reg = <0xb3e00000 0x200000>; /* 16 * (4 * 0x8000) */
+			record-size = <0x8000>;
+			console-size = <0x8000>;
+			ftrace-size = <0x8000>;
+			pmsg-size = <0x8000>;
+			max-reason = <3>; /* KMSG_DUMP_EMERG */
+		};
+
+		/* LPC FW cycle bridge region requires natural alignment */
+		flash_memory: region at b4000000 {
+			no-map;
+			reg = <0xb4000000 0x04000000>; /* 64M */
+		};
+
+		/* VGA region is dictated by hardware strapping */
+		vga_memory: region at bf000000 {
+			no-map;
+			compatible = "shared-dma-pool";
+			reg = <0xbf000000 0x01000000>;  /* 16M */
+		};
+	};
+};
+
+&adc1 {
+	status = "okay";
+	aspeed,int-vref-microvolt = <2500000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc8_default
+		&pinctrl_adc9_default
+		&pinctrl_adc10_default
+		&pinctrl_adc11_default
+		&pinctrl_adc12_default
+		&pinctrl_adc13_default
+		&pinctrl_adc14_default
+		&pinctrl_adc15_default>;
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&uhci {
+	status = "okay";
+};
+
+&gpio0 {
+	gpio-line-names =
+	/*A0-A7*/	"","","","","","","","",
+	/*B0-B7*/	"","","","","","","","",
+	/*C0-C7*/	"","","","","","","","",
+	/*D0-D7*/	"","","","","","","","",
+	/*E0-E7*/	"","","","","","","","",
+	/*F0-F7*/	"","","","","","","","",
+	/*G0-G7*/	"","","","","","","","",
+	/*H0-H7*/	"","","","","","","","",
+	/*I0-I7*/	"","","","","","","","",
+	/*J0-J7*/	"","","","","","","","",
+	/*K0-K7*/	"","","","","","","","",
+	/*L0-L7*/	"","","","","","","","",
+	/*M0-M7*/	"","","","","","","","",
+	/*N0-N7*/	"","","","","","","","",
+	/*O0-O7*/	"","","","","","","","",
+	/*P0-P7*/	"","","","","","","","",
+	/*Q0-Q7*/	"","","","","","","","",
+	/*R0-R7*/	"","","","","","","","",
+	/*S0-S7*/	"","","","","","","","",
+	/*T0-T7*/	"","","","","","","","",
+	/*U0-U7*/	"","","","","","","","",
+	/*V0-V7*/	"","","","power-chassis-control","","","","",
+	/*W0-W7*/	"","","","","","","","",
+	/*X0-X7*/	"","power-chassis-good","","","","","","",
+	/*Y0-Y7*/	"","","","","","","","",
+	/*Z0-Z7*/	"","","","","","","","";
+};
+
+&emmc_controller {
+	status = "okay";
+};
+
+&pinctrl_emmc_default {
+	bias-disable;
+};
+
+&emmc {
+	status = "okay";
+	clk-phase-mmc-hs200 = <180>, <180>;
+};
+
+&ibt {
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&vuart1 {
+	status = "okay";
+};
+
+&vuart2 {
+	status = "okay";
+};
+
+&lpc_ctrl {
+	status = "okay";
+	memory-region = <&flash_memory>;
+};
+
+&mac2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rmii3_default>;
+	clocks = <&syscon ASPEED_CLK_GATE_MAC3CLK>,
+		 <&syscon ASPEED_CLK_MAC3RCLK>;
+	clock-names = "MACCLK", "RCLK";
+	use-ncsi;
+};
+
+&mac3 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rmii4_default>;
+	clocks = <&syscon ASPEED_CLK_GATE_MAC4CLK>,
+		 <&syscon ASPEED_CLK_MAC4RCLK>;
+	clock-names = "MACCLK", "RCLK";
+	use-ncsi;
+};
+
+&wdt1 {
+	aspeed,reset-type = "none";
+	aspeed,external-signal;
+	aspeed,ext-push-pull;
+	aspeed,ext-active-high;
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdtrst1_default>;
+};
+
+&wdt2 {
+	status = "okay";
+};
+
+&kcs2 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca8 0xcac>;
+};
+
+&kcs3 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca2>;
+	aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+};
-- 
2.39.2



From daniel at makrotopia.org  Tue Dec 12 08:42:45 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 16:42:45 +0000
Subject: [RFC PATCH net-next v3 1/8] dt-bindings: phy:
 mediatek,xfi-pextp: add new bindings
In-Reply-To: <20231212-renderer-strobe-2b46652cd6e7@spud>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel@makrotopia.org>
 <20231212-renderer-strobe-2b46652cd6e7@spud>
Message-ID: <ZXiNhSYDbowUiNvy@makrotopia.org>

On Tue, Dec 12, 2023 at 04:21:38PM +0000, Conor Dooley wrote:
> On Tue, Dec 12, 2023 at 03:46:26AM +0000, Daniel Golle wrote:
> 
> > +  mediatek,usxgmii-performance-errata:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description:
> > +      USXGMII0 on MT7988 suffers from a performance problem in 10GBase-R
> > +      mode which needs a work-around in the driver. The work-around is
> > +      enabled using this flag.
> 
> Why do you need a property for this if you know that it is present on
> the MT7988?

Because it is only present in one of the two SerDes channels.
Channel 0 needs the work-around, Channel 1 doesn't.

See also this commit in the vendor driver for reference[1].

We previously discussed that[2] and it was decided that a property
would be the prefered way to represent this as there aren't any other
per-instance differences which would justify another compatible.


[1]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/a500d94cd47e279015ce22947e1ce396a7516598%5E%21/#F0

[2]: https://patchwork.kernel.org/comment/25592845/


From will at kernel.org  Tue Dec 12 08:47:52 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 16:47:52 +0000
Subject: [PATCH v4 1/2] rust: Refactor the build target to allow the use
 of builtin targets
In-Reply-To: <ZUDry1L3w4sdGRN5@arm.com>
References: <20231020155056.3495121-1-Jamie.Cunliffe@arm.com>
 <20231020155056.3495121-2-Jamie.Cunliffe@arm.com>
 <ZTT/h5wKL7STeOhC@arm.com>
 <ZTUCdS0Vrev1iQOv@gmail.com>
 <CALNs47vb+-_wD0uKQJYVMswHdivOr-1v6ajQ3hQw4wNs4Da0rg@mail.gmail.com>
 <ZUDry1L3w4sdGRN5@arm.com>
Message-ID: <20231212164751.GA30181@willie-the-truck>

On Tue, Oct 31, 2023 at 11:58:03AM +0000, Catalin Marinas wrote:
> On Mon, Oct 30, 2023 at 08:24:39PM -0400, Trevor Gross wrote:
> > On Sun, Oct 22, 2023 at 7:14?AM Ingo Molnar <mingo at kernel.org> wrote:
> > > * Catalin Marinas <catalin.marinas at arm.com> wrote:
> > > > Adding the x86 maintainers - no functional change for x86, any objection
> > > > to this patch going in via the arm64 tree (part of the two-patch series
> > > > enabling Rust for arm64)?
> > > >
> > > > Thanks.
> > > >
> > > > (keeping the rest of the patch below for your reference)
> > >
> > > If Masahiro Yamada (kbuild maintainer, Cc:-ed) is fine with it,
> > > then it will be OK to me too.
> [...]
> > I don't think this has been picked up yet. Is it only waiting on
> > Masahiro 's ack or is a new version expected?
> 
> I'd say Masahiro's ack only. However, it's probably too late for 6.7
> now, the merging window is already open and maintainers tend to pick
> stuff up in the weeks before.

Masahiro -- please can we have your Ack on this so that we can take it via
the arm64 tree?

Thanks,

Will


From manivannan.sadhasivam at linaro.org  Tue Dec 12 08:49:13 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Tue, 12 Dec 2023 22:19:13 +0530
Subject: [PATCH v3 01/13] PCI: imx6: Simplify clock handling by using
 HAS_CLK_* bitmask
In-Reply-To: <20231211215842.134823-2-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-2-Frank.Li@nxp.com>
Message-ID: <20231212164913.GA21240@thinkpad>

On Mon, Dec 11, 2023 at 04:58:30PM -0500, Frank Li wrote:
> Refactors the clock handling logic in the imx6 PCI driver by adding
> HAS_CLK_* bitmask define for drvdata::flags . Simplifies the code and makes
> it more maintainable, as future additions of SOC support will only require
> straightforward changes. The drvdata::flags and a bitmask ensures a cleaner
> and more scalable switch-case structure for handling clocks.
> 

Is there any necessity to validate each clock in the driver? I mean, can't you
just rely on devicetree to provide enough clocks for the functioning of the PCIe
controller?

If you can rely on devicetree (everyone should in an ideal world), then you can
just use devm_clk_bulk_get_all() to get all available clocks for the SoC and
just enable/disable whatever is available.

This will greatly simplify the code.

Only downside of this approach is, if the devicetree is not supplying enough
clocks, then it will be difficult to find why PCIe is not working. But this also
means that the devicetree is screwed.

- Mani

> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> 
> Notes:
>     Change from v1 to v3
>     - none
> 
>  drivers/pci/controller/dwc/pci-imx6.c | 84 +++++++++++++--------------
>  1 file changed, 42 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 74703362aeec7..8a9b527934f80 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -60,6 +60,10 @@ enum imx6_pcie_variants {
>  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
>  #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
>  #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
> +#define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
> +#define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
> +
> +#define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
>  
>  struct imx6_pcie_drvdata {
>  	enum imx6_pcie_variants variant;
> @@ -550,19 +554,23 @@ static int imx6_pcie_attach_pd(struct device *dev)
>  
>  static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
>  {
> -	struct dw_pcie *pci = imx6_pcie->pci;
> -	struct device *dev = pci->dev;
>  	unsigned int offset;
>  	int ret = 0;
>  
> -	switch (imx6_pcie->drvdata->variant) {
> -	case IMX6SX:
> +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
>  		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
> -		if (ret) {
> -			dev_err(dev, "unable to enable pcie_axi clock\n");
> -			break;
> -		}
> +		if (ret)
> +			return ret;
> +	}
>  
> +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
> +		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	switch (imx6_pcie->drvdata->variant) {
> +	case IMX6SX:
>  		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
>  				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
>  		break;
> @@ -589,12 +597,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
>  	case IMX8MQ_EP:
>  	case IMX8MP:
>  	case IMX8MP_EP:
> -		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> -		if (ret) {
> -			dev_err(dev, "unable to enable pcie_aux clock\n");
> -			break;
> -		}
> -
>  		offset = imx6_pcie_grp_offset(imx6_pcie);
>  		/*
>  		 * Set the over ride low and enabled
> @@ -614,10 +616,13 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
>  
>  static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
>  {
> -	switch (imx6_pcie->drvdata->variant) {
> -	case IMX6SX:
> +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI))
>  		clk_disable_unprepare(imx6_pcie->pcie_inbound_axi);
> -		break;
> +
> +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX))
> +		clk_disable_unprepare(imx6_pcie->pcie_aux);
> +
> +	switch (imx6_pcie->drvdata->variant) {
>  	case IMX6QP:
>  	case IMX6Q:
>  		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> @@ -631,14 +636,6 @@ static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
>  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
>  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
>  		break;
> -	case IMX8MM:
> -	case IMX8MM_EP:
> -	case IMX8MQ:
> -	case IMX8MQ_EP:
> -	case IMX8MP:
> -	case IMX8MP_EP:
> -		clk_disable_unprepare(imx6_pcie->pcie_aux);
> -		break;
>  	default:
>  		break;
>  	}
> @@ -1316,21 +1313,21 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
>  				     "pcie clock source missing or invalid\n");
>  
> -	switch (imx6_pcie->drvdata->variant) {
> -	case IMX6SX:
> -		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
> -							   "pcie_inbound_axi");
> +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
> +		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev, "pcie_inbound_axi");
>  		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
> -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
> -					     "pcie_inbound_axi clock missing or invalid\n");
> -		break;
> -	case IMX8MQ:
> -	case IMX8MQ_EP:
> +			dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
> +				      "pcie_inbound_axi clock missing or invalid\n");
> +	}
> +
> +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
>  		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
>  		if (IS_ERR(imx6_pcie->pcie_aux))
>  			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
>  					     "pcie_aux clock source missing or invalid\n");
> -		fallthrough;
> +	}
> +
> +	switch (imx6_pcie->drvdata->variant) {
>  	case IMX7D:
>  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
>  			imx6_pcie->controller_id = 1;
> @@ -1353,10 +1350,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	case IMX8MM_EP:
>  	case IMX8MP:
>  	case IMX8MP_EP:
> -		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> -		if (IS_ERR(imx6_pcie->pcie_aux))
> -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> -					     "pcie_aux clock source missing or invalid\n");
>  		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
>  									 "apps");
>  		if (IS_ERR(imx6_pcie->apps_reset))
> @@ -1482,7 +1475,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
>  		.variant = IMX6SX,
>  		.flags = IMX6_PCIE_FLAG_IMX6_PHY |
>  			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
> -			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> +			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> +			 IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI,
>  		.gpr = "fsl,imx6q-iomuxc-gpr",
>  	},
>  	[IMX6QP] = {
> @@ -1500,30 +1494,36 @@ static const struct imx6_pcie_drvdata drvdata[] = {
>  	},
>  	[IMX8MQ] = {
>  		.variant = IMX8MQ,
> +		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
>  		.gpr = "fsl,imx8mq-iomuxc-gpr",
>  	},
>  	[IMX8MM] = {
>  		.variant = IMX8MM,
> -		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> +			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
>  		.gpr = "fsl,imx8mm-iomuxc-gpr",
>  	},
>  	[IMX8MP] = {
>  		.variant = IMX8MP,
> -		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> +			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
>  		.gpr = "fsl,imx8mp-iomuxc-gpr",
>  	},
>  	[IMX8MQ_EP] = {
>  		.variant = IMX8MQ_EP,
> +		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
>  		.mode = DW_PCIE_EP_TYPE,
>  		.gpr = "fsl,imx8mq-iomuxc-gpr",
>  	},
>  	[IMX8MM_EP] = {
>  		.variant = IMX8MM_EP,
> +		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
>  		.mode = DW_PCIE_EP_TYPE,
>  		.gpr = "fsl,imx8mm-iomuxc-gpr",
>  	},
>  	[IMX8MP_EP] = {
>  		.variant = IMX8MP_EP,
> +		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
>  		.mode = DW_PCIE_EP_TYPE,
>  		.gpr = "fsl,imx8mp-iomuxc-gpr",
>  	},
> -- 
> 2.34.1
> 

-- 
????????? ????????


From conor at kernel.org  Tue Dec 12 08:51:06 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 16:51:06 +0000
Subject: [PATCH v3 12/13] dt-bindings: imx6q-pcie: Add iMX95 pcie
 endpoint compatible string
In-Reply-To: <20231211215842.134823-13-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-13-Frank.Li@nxp.com>
Message-ID: <20231212-snowiness-verbalize-d1fbb8c80a99@spud>

On Mon, Dec 11, 2023 at 04:58:41PM -0500, Frank Li wrote:
> Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
> Add reg-name: "atu", "dbi2", "dma" and "serdes".
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> ---
> 
> Notes:
>     Change from v1 to v3
>     - new patches at v3
> 
>  .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 20 +++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> index ee155ed5f1811..36d8f117fdfb3 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> @@ -22,6 +22,7 @@ properties:
>        - fsl,imx8mm-pcie-ep
>        - fsl,imx8mq-pcie-ep
>        - fsl,imx8mp-pcie-ep
> +      - fsl,imx95-pcie-ep
>  
>    reg:
>      minItems: 2
> @@ -62,11 +63,30 @@ required:
>  allOf:
>    - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
>    - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          enum:
> +            - fsl,imx95-pcie-ep
> +    then:
> +      properties:
> +        reg:
> +          minItems: 6
> +        reg-names:
> +          items:
> +            - const: dbi
> +            - const: atu
> +            - const: dbi2
> +            - const: serdes
> +            - const: dma
> +            - const: addr_space
> +
>    - if:
>        properties:
>          compatible:
>            enum:
>              - fsl,imx8mq-pcie-ep
> +            - fsl,imx95-pcie-ep
>      then:
>        properties:
>          clocks:
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/0d57b918/attachment.sig>

From reidt at ti.com  Tue Dec 12 08:52:23 2023
From: reidt at ti.com (reidt)
Date: Tue, 12 Dec 2023 10:52:23 -0600
Subject: [PATCH v10 1/7] arm64: dts: ti: k3-j7200-som-p0: Add TP6594
 family PMICs
In-Reply-To: <20231208114919.3429562-2-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
 <20231208114919.3429562-2-n-francis@ti.com>
Message-ID: <20231212165223.lowflzvrut6yxtgy@reidt-HP-Z2>

On 17:19-20231208, Neha Malcom Francis wrote:
> From: Esteban Blanc <eblanc at baylibre.com>
> 
> This patch adds support for TPS6594 PMIC family on wakup I2C0 bus.
> Theses devices provides regulators (bucks and LDOs), but also
> GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
> which monitors the SoC error output signal, and a PFSM
> (Pre-configurable Finite State Machine) which manages the
> operational modes of the PMIC.
> 
> Signed-off-by: Esteban Blanc <eblanc at baylibre.com>
> Signed-off-by: Jai Luthra <j-luthra at ti.com>
> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
> ---

Reviewed-by: Reid Tonking <reidt at ti.com>

>  arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 153 ++++++++++++++++++++
>  1 file changed, 153 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> index 5a300d4c8ba0..ea47f10d393a 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> @@ -127,6 +127,14 @@ J721E_WKUP_IOPAD(0x9c, PIN_INPUT_PULLUP, 0) /* (H21) WKUP_I2C0_SDA */
>  	};
>  };
>  
> +&wkup_pmx3 {
> +	pmic_irq_pins_default: pmic-irq-default-pins {
> +		pinctrl-single,pins = <
> +			J721E_WKUP_IOPAD(0x01c, PIN_INPUT, 7) /* (E18) WKUP_GPIO0_84 */
> +		>;
> +	};
> +};
> +
>  &main_pmx0 {
>  	main_i2c0_pins_default: main-i2c0-default-pins {
>  		pinctrl-single,pins = <
> @@ -264,6 +272,151 @@ eeprom at 50 {
>  		compatible = "atmel,24c256";
>  		reg = <0x50>;
>  	};
> +
> +	tps659414: pmic at 48 {
> +		compatible = "ti,tps6594-q1";
> +		reg = <0x48>;
> +		system-power-controller;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_irq_pins_default>;
> +		interrupt-parent = <&wkup_gpio0>;
> +		interrupts = <84 IRQ_TYPE_EDGE_FALLING>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		ti,primary-pmic;
> +		buck1-supply = <&vsys_3v3>;
> +		buck2-supply = <&vsys_3v3>;
> +		buck3-supply = <&vsys_3v3>;
> +		buck4-supply = <&vsys_3v3>;
> +		buck5-supply = <&vsys_3v3>;
> +		ldo1-supply = <&vsys_3v3>;
> +		ldo2-supply = <&vsys_3v3>;
> +		ldo3-supply = <&vsys_3v3>;
> +		ldo4-supply = <&vsys_3v3>;
> +
> +		regulators {
> +			bucka1: buck1 {
> +				regulator-name = "vda_mcu_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka2: buck2 {
> +				regulator-name = "vdd_mcuio_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka3: buck3 {
> +				regulator-name = "vdd_mcu_0v85";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka4: buck4 {
> +				regulator-name = "vdd_ddr_1v1";
> +				regulator-min-microvolt = <1100000>;
> +				regulator-max-microvolt = <1100000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			bucka5: buck5 {
> +				regulator-name = "vdd_phyio_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa1: ldo1 {
> +				regulator-name = "vdd1_lpddr4_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa2: ldo2 {
> +				regulator-name = "vda_dll_0v8";
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa3: ldo3 {
> +				regulator-name = "vdd_wk_0v8";
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldoa4: ldo4 {
> +				regulator-name = "vda_pll_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +		};
> +	};
> +
> +	lp876441: pmic at 4c {
> +		compatible = "ti,lp8764-q1";
> +		reg = <0x4c>;
> +		system-power-controller;
> +		interrupt-parent = <&wkup_gpio0>;
> +		interrupts = <84 IRQ_TYPE_EDGE_FALLING>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		buck1-supply = <&vsys_3v3>;
> +		buck2-supply = <&vsys_3v3>;
> +		buck3-supply = <&vsys_3v3>;
> +		buck4-supply = <&vsys_3v3>;
> +
> +		regulators: regulators {
> +			buckb1: buck1 {
> +				regulator-name = "vdd_cpu_avs";
> +				regulator-min-microvolt = <600000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-always-on;
> +				regulator-boot-on;
> +				bootph-pre-ram;
> +			};
> +
> +			buckb2: buck2 {
> +				regulator-name = "vdd_ram_0v85";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			buckb3: buck3 {
> +				regulator-name = "vdd_core_0v85";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			buckb4: buck4 {
> +				regulator-name = "vdd_io_1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +		};
> +	};
>  };
>  
>  &ospi0 {
> -- 
> 2.34.1
> 
> 


From linux at roeck-us.net  Tue Dec 12 08:55:15 2023
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 12 Dec 2023 08:55:15 -0800
Subject: [PATCH v2 1/2] dt-bindings: watchdog: mediatek,mtk-wdt: add
 MT7988 watchdog and toprgu
In-Reply-To: <e26a98fd0b7b7b431922405732275bac01eaf220.1699890006.git.daniel@makrotopia.org>
References: <e26a98fd0b7b7b431922405732275bac01eaf220.1699890006.git.daniel@makrotopia.org>
Message-ID: <17ece724-95d7-48d6-a95a-41c667df9fd7@roeck-us.net>

On Mon, Nov 13, 2023 at 03:43:24PM +0000, Daniel Golle wrote:
> Add compatible mediatek,mt7988-wdt.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

> ---
> v2: Drop adding include/dt-binding/mt7988-resets.h as that header is not
>     actually a binding header.
> 
>  Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> index cc502838bc398..8d2520241e37f 100644
> --- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> @@ -25,6 +25,7 @@ properties:
>            - mediatek,mt6735-wdt
>            - mediatek,mt6795-wdt
>            - mediatek,mt7986-wdt
> +          - mediatek,mt7988-wdt
>            - mediatek,mt8183-wdt
>            - mediatek,mt8186-wdt
>            - mediatek,mt8188-wdt
> -- 
> 2.42.1


From linux at roeck-us.net  Tue Dec 12 08:55:24 2023
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 12 Dec 2023 08:55:24 -0800
Subject: [PATCH v2 2/2] watchdog: mediatek: mt7988: add wdt support
In-Reply-To: <fc1c022551edc9ee2dfaa4c1dcf6b146b5b2aae5.1699890006.git.daniel@makrotopia.org>
References: <e26a98fd0b7b7b431922405732275bac01eaf220.1699890006.git.daniel@makrotopia.org>
 <fc1c022551edc9ee2dfaa4c1dcf6b146b5b2aae5.1699890006.git.daniel@makrotopia.org>
Message-ID: <c39a109b-a42d-4a86-a580-a3edc7d51e9a@roeck-us.net>

On Mon, Nov 13, 2023 at 03:43:47PM +0000, Daniel Golle wrote:
> Add support for watchdog and reset generator unit of the MediaTek
> MT7988 SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

> ---
> v2: call new toprgu_reset_sw_en_unlocked from toprgu_reset_update while
>     holding lock.
> 
>  drivers/watchdog/mtk_wdt.c | 40 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index b2330b16b497a..5a31a8746e954 100644
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -58,6 +58,8 @@
>  #define WDT_SWSYSRST		0x18U
>  #define WDT_SWSYS_RST_KEY	0x88000000
>  
> +#define WDT_SWSYSRST_EN		0xfc
> +
>  #define DRV_NAME		"mtk-wdt"
>  #define DRV_VERSION		"1.0"
>  
> @@ -71,10 +73,12 @@ struct mtk_wdt_dev {
>  	struct reset_controller_dev rcdev;
>  	bool disable_wdt_extrst;
>  	bool reset_by_toprgu;
> +	bool has_swsysrst_en;
>  };
>  
>  struct mtk_wdt_data {
>  	int toprgu_sw_rst_num;
> +	bool has_swsysrst_en;
>  };
>  
>  static const struct mtk_wdt_data mt2712_data = {
> @@ -89,6 +93,11 @@ static const struct mtk_wdt_data mt7986_data = {
>  	.toprgu_sw_rst_num = MT7986_TOPRGU_SW_RST_NUM,
>  };
>  
> +static const struct mtk_wdt_data mt7988_data = {
> +	.toprgu_sw_rst_num = 24,
> +	.has_swsysrst_en = true,
> +};
> +
>  static const struct mtk_wdt_data mt8183_data = {
>  	.toprgu_sw_rst_num = MT8183_TOPRGU_SW_RST_NUM,
>  };
> @@ -109,6 +118,28 @@ static const struct mtk_wdt_data mt8195_data = {
>  	.toprgu_sw_rst_num = MT8195_TOPRGU_SW_RST_NUM,
>  };
>  
> +/**
> + * toprgu_reset_sw_en_unlocked() - enable/disable software control for reset bit
> + * @mtk_wdt: Pointer to instance of struct mtk_wdt_dev.
> + * @id: Bit number identifying the reset to be enabled or disabled.
> + * @enable: If true, enable software control for that bit, disable otherwise.
> + *
> + * Context: The caller must hold lock of struct mtk_wdt_dev.
> + */
> +static void toprgu_reset_sw_en_unlocked(struct mtk_wdt_dev *data,
> +					unsigned long id, bool enable)
> +{
> +	u32 tmp;
> +
> +	tmp = readl(data->wdt_base + WDT_SWSYSRST_EN);
> +	if (enable)
> +		tmp |= BIT(id);
> +	else
> +		tmp &= ~BIT(id);
> +
> +	writel(tmp, data->wdt_base + WDT_SWSYSRST_EN);
> +}
> +
>  static int toprgu_reset_update(struct reset_controller_dev *rcdev,
>  			       unsigned long id, bool assert)
>  {
> @@ -119,6 +150,9 @@ static int toprgu_reset_update(struct reset_controller_dev *rcdev,
>  
>  	spin_lock_irqsave(&data->lock, flags);
>  
> +	if (assert && data->has_swsysrst_en)
> +		toprgu_reset_sw_en_unlocked(data, id, true);
> +
>  	tmp = readl(data->wdt_base + WDT_SWSYSRST);
>  	if (assert)
>  		tmp |= BIT(id);
> @@ -127,6 +161,9 @@ static int toprgu_reset_update(struct reset_controller_dev *rcdev,
>  	tmp |= WDT_SWSYS_RST_KEY;
>  	writel(tmp, data->wdt_base + WDT_SWSYSRST);
>  
> +	if (!assert && data->has_swsysrst_en)
> +		toprgu_reset_sw_en_unlocked(data, id, false);
> +
>  	spin_unlock_irqrestore(&data->lock, flags);
>  
>  	return 0;
> @@ -406,6 +443,8 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  						       wdt_data->toprgu_sw_rst_num);
>  		if (err)
>  			return err;
> +
> +		mtk_wdt->has_swsysrst_en = wdt_data->has_swsysrst_en;
>  	}
>  
>  	mtk_wdt->disable_wdt_extrst =
> @@ -444,6 +483,7 @@ static const struct of_device_id mtk_wdt_dt_ids[] = {
>  	{ .compatible = "mediatek,mt6589-wdt" },
>  	{ .compatible = "mediatek,mt6795-wdt", .data = &mt6795_data },
>  	{ .compatible = "mediatek,mt7986-wdt", .data = &mt7986_data },
> +	{ .compatible = "mediatek,mt7988-wdt", .data = &mt7988_data },
>  	{ .compatible = "mediatek,mt8183-wdt", .data = &mt8183_data },
>  	{ .compatible = "mediatek,mt8186-wdt", .data = &mt8186_data },
>  	{ .compatible = "mediatek,mt8188-wdt", .data = &mt8188_data },
> -- 
> 2.42.1


From quic_johmoo at quicinc.com  Tue Dec 12 08:58:16 2023
From: quic_johmoo at quicinc.com (John Moon)
Date: Tue, 12 Dec 2023 08:58:16 -0800
Subject: [PATCH v7 3/3] check-module-params: Introduce
 check-module-params.sh
In-Reply-To: <ZXgOpRzNYGtiE35T@infradead.org>
References: <20231212020259.2451253-1-quic_johmoo@quicinc.com>
 <20231212020259.2451253-4-quic_johmoo@quicinc.com>
 <ZXgOpRzNYGtiE35T@infradead.org>
Message-ID: <93ee22bc-b357-4291-b3d9-07ff2cd6c87b@quicinc.com>

On 12/11/2023 11:41 PM, Christoph Hellwig wrote:
> On Mon, Dec 11, 2023 at 06:02:59PM -0800, John Moon wrote:
>> One part of maintaining backwards compatibility with older
>> userspace programs is avoiding changes to module parameters.
> 
> Really?  I don't think module parameters are a UAPI in the traditional
> sense.  

Agreed, they're not UAPI in the traditional sense. But, we're trying to 
establish tooling to help the community stabilize all interfaces that 
cross the kernel <-> userspace boundary and module params do fall into 
that bucket.

> Now if you break a heavily used one you got to fix it, but
> applying strict stability guarantees on module options which are not
> availble to normal users or even normal programs doesn't make a whole
> lot of sense.
> 

True, but unfortunately we don't have any heuristic to determine if a 
param is "heavily used". However, in this rev, we added the ability to 
parse the permissions of a module param, so we could add a filter which 
does not flag change/removal of params with 0{0,4,6}000 permissions.

It's also obviously fine if the community has no interest in the script. 
We just wanted to share it as we find it to be a useful supplement to 
our code reviews and thought maintainers may find it useful as well.

Cheers,
John


From danishanwar at ti.com  Tue Dec 12 08:58:29 2023
From: danishanwar at ti.com (MD Danish Anwar)
Date: Tue, 12 Dec 2023 22:28:29 +0530
Subject: [PATCH v2 0/3] Add AM64x ICSSG Ethernet support
Message-ID: <20231212165832.3933335-1-danishanwar@ti.com>

Hi All,

This series adds support for ICSSG ethernet on AM64x. 
This series is based on the latest next-20231211 linux-next.

AM64x EVM has three ethernet ports. One is dedicated to CPSW and one is
dedicated to ICSSG1. The remaining port is muxed between CPSW and ICSSG1
ICSSG1 ports. The ICSSG1 node is added in the k3-am642-evm.dts. By default
the muxed port is used by CPSW so 2nd ICSSG1 port is disabled in the
k3-am642-evm.dts. But overlay k3-am642-evm-icssg1-dualemac.dtso can be
applied to use muxed port as ICSSG1.

This is the v2 of the series [v1]. This addresses comments made on v1.

Changes from v1 to v2:
*) Fixed aliases section in k3-am642-evm.dts
*) Fixed firmware-names in k3-am642-evm.dts
*) Changed icssg1_phy1 to ethernet-phy at f from ethernet-phy at 0 as suggested
   by Andrew L.
*) Changed makefile to handle overlays using CONFIG_OF_ALL_DTBS as
   suggested by Nishant and Andrew Davis.
*) Fixed aliases section in k3-am642-evm-icssg1-dualemac.dtso
*) Fixed pinctrl in k3-am642-evm-icssg1-dualemac.dtso
*) Updated commit message of patch 3/3 of the series to warn about adding
   label name to 'mdio-mux-1' node.

[v1] https://lore.kernel.org/all/20231207081917.340167-1-danishanwar at ti.com/

Thanks and Regards,
MD Danish Anwar

MD Danish Anwar (2):
  arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet support
  arm64: dts: ti: k3-am642-evm: add overlay for icssg1 2nd port

Suman Anna (1):
  arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes

 arch/arm64/boot/dts/ti/Makefile               |   7 +-
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi      |  24 ++++
 .../dts/ti/k3-am642-evm-icssg1-dualemac.dtso  |  75 +++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-evm.dts       | 104 +++++++++++++++++-
 4 files changed, 208 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso

base-commit: bbd220ce4e29ed55ab079007cff0b550895258eb
-- 
2.34.1



From danishanwar at ti.com  Tue Dec 12 08:58:30 2023
From: danishanwar at ti.com (MD Danish Anwar)
Date: Tue, 12 Dec 2023 22:28:30 +0530
Subject: [PATCH v2 1/3] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes
In-Reply-To: <20231212165832.3933335-1-danishanwar@ti.com>
References: <20231212165832.3933335-1-danishanwar@ti.com>
Message-ID: <20231212165832.3933335-2-danishanwar@ti.com>

From: Suman Anna <s-anna at ti.com>

The ICSSG IP on AM64x SoCs have two Industrial Ethernet Peripherals (IEPs)
to manage/generate Industrial Ethernet functions such as time stamping.
Each IEP sub-module is sourced from an internal clock mux that can be
derived from either of the IP instance's ICSSG_IEP_GCLK or from another
internal ICSSG CORE_CLK mux. Add both the IEP nodes for both the ICSSG
instances. The IEP clock is currently configured to be derived
indirectly from the ICSSG_ICLK running at 250 MHz.

Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
Signed-off-by: Suman Anna <s-anna at ti.com>
Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index c7be378492e2..055f6e3657c2 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -1234,6 +1234,18 @@ icssg0_iepclk_mux: iepclk-mux at 30 {
 			};
 		};
 
+		icssg0_iep0: iep at 2e000 {
+			compatible = "ti,am654-icss-iep";
+			reg = <0x2e000 0x1000>;
+			clocks = <&icssg0_iepclk_mux>;
+		};
+
+		icssg0_iep1: iep at 2f000 {
+			compatible = "ti,am654-icss-iep";
+			reg = <0x2f000 0x1000>;
+			clocks = <&icssg0_iepclk_mux>;
+		};
+
 		icssg0_mii_rt: mii-rt at 32000 {
 			compatible = "ti,pruss-mii", "syscon";
 			reg = <0x32000 0x100>;
@@ -1375,6 +1387,18 @@ icssg1_iepclk_mux: iepclk-mux at 30 {
 			};
 		};
 
+		icssg1_iep0: iep at 2e000 {
+			compatible = "ti,am654-icss-iep";
+			reg = <0x2e000 0x1000>;
+			clocks = <&icssg1_iepclk_mux>;
+		};
+
+		icssg1_iep1: iep at 2f000 {
+			compatible = "ti,am654-icss-iep";
+			reg = <0x2f000 0x1000>;
+			clocks = <&icssg1_iepclk_mux>;
+		};
+
 		icssg1_mii_rt: mii-rt at 32000 {
 			compatible = "ti,pruss-mii", "syscon";
 			reg = <0x32000 0x100>;
-- 
2.34.1



From danishanwar at ti.com  Tue Dec 12 08:58:31 2023
From: danishanwar at ti.com (MD Danish Anwar)
Date: Tue, 12 Dec 2023 22:28:31 +0530
Subject: [PATCH v2 2/3] arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet support
In-Reply-To: <20231212165832.3933335-1-danishanwar@ti.com>
References: <20231212165832.3933335-1-danishanwar@ti.com>
Message-ID: <20231212165832.3933335-3-danishanwar@ti.com>

ICSSG1 provides dual Gigabit Ethernet support with proper FW loaded.

The ICSSG1 MII0 (RGMII1) has DP83869 PHY attached to it. The ICSSG1 shares
MII1 (RGMII2) PHY DP83869 with CPSW3g and it's assigned by default to
CPSW3g. The MDIO access to MII1 (RGMII2) PHY DP83869 is controlled by MDIO
bus switch and also assigned to CPSW3g. Therefore the ICSSG1 MII1 (RGMII2)
port is kept disable and ICSSG1 is enabled in single MAC mode by
default.

Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am642-evm.dts | 102 ++++++++++++++++++++++++
 1 file changed, 102 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 8c5651d2cf5d..c08b0223be52 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -32,6 +32,8 @@ aliases {
 		mmc1 = &sdhci1;
 		ethernet0 = &cpsw_port1;
 		ethernet1 = &cpsw_port2;
+		ethernet2 = &icssg1_emac0;
+		ethernet3 = &icssg1_emac1;
 	};
 
 	memory at 80000000 {
@@ -229,6 +231,70 @@ transceiver2: can-phy1 {
 		max-bitrate = <5000000>;
 		standby-gpios = <&exp1 9 GPIO_ACTIVE_HIGH>;
 	};
+
+	icssg1_eth: icssg1-eth {
+		compatible = "ti,am642-icssg-prueth";
+		pinctrl-names = "default";
+		pinctrl-0 = <&icssg1_rgmii1_pins_default>;
+
+		sram = <&oc_sram>;
+		ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
+		firmware-name = "ti-pruss/am64x-sr2-pru0-prueth-fw.elf",
+				"ti-pruss/am64x-sr2-rtu0-prueth-fw.elf",
+				"ti-pruss/am64x-sr2-txpru0-prueth-fw.elf",
+				"ti-pruss/am64x-sr2-pru1-prueth-fw.elf",
+				"ti-pruss/am64x-sr2-rtu1-prueth-fw.elf",
+				"ti-pruss/am64x-sr2-txpru1-prueth-fw.elf";
+
+		ti,pruss-gp-mux-sel = <2>,	/* MII mode */
+				      <2>,
+				      <2>,
+				      <2>,	/* MII mode */
+				      <2>,
+				      <2>;
+
+		ti,mii-g-rt = <&icssg1_mii_g_rt>;
+		ti,mii-rt = <&icssg1_mii_rt>;
+		ti,iep = <&icssg1_iep0>,  <&icssg1_iep1>;
+
+		interrupt-parent = <&icssg1_intc>;
+		interrupts = <24 0 2>, <25 1 3>;
+		interrupt-names = "tx_ts0", "tx_ts1";
+
+		dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
+		       <&main_pktdma 0xc201 15>, /* egress slice 0 */
+		       <&main_pktdma 0xc202 15>, /* egress slice 0 */
+		       <&main_pktdma 0xc203 15>, /* egress slice 0 */
+		       <&main_pktdma 0xc204 15>, /* egress slice 1 */
+		       <&main_pktdma 0xc205 15>, /* egress slice 1 */
+		       <&main_pktdma 0xc206 15>, /* egress slice 1 */
+		       <&main_pktdma 0xc207 15>, /* egress slice 1 */
+		       <&main_pktdma 0x4200 15>, /* ingress slice 0 */
+		       <&main_pktdma 0x4201 15>; /* ingress slice 1 */
+		dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
+			    "tx1-0", "tx1-1", "tx1-2", "tx1-3",
+			    "rx0", "rx1";
+
+		ethernet-ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			icssg1_emac0: port at 0 {
+				reg = <0>;
+				phy-handle = <&icssg1_phy1>;
+				phy-mode = "rgmii-id";
+				ti,syscon-rgmii-delay = <&main_conf 0x4110>;
+				/* Filled in by bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+			};
+			icssg1_emac1: port at 1 {
+				reg = <1>;
+				ti,syscon-rgmii-delay = <&main_conf 0x4114>;
+				/* Filled in by bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				status = "disabled";
+			};
+		};
+	};
 };
 
 &main_pmx0 {
@@ -383,6 +449,30 @@ ddr_vtt_pins_default: ddr-vtt-default-pins {
 			AM64X_IOPAD(0x0030, PIN_OUTPUT_PULLUP, 7) /* (L18) OSPI0_CSN1.GPIO0_12 */
 		>;
 	};
+
+	icssg1_mdio1_pins_default: icssg1-mdio1-default-pins {
+		pinctrl-single,pins = <
+			AM64X_IOPAD(0x015c, PIN_OUTPUT, 0) /* (Y6) PRG1_MDIO0_MDC */
+			AM64X_IOPAD(0x0158, PIN_INPUT, 0) /* (AA6) PRG1_MDIO0_MDIO */
+		>;
+	};
+
+	icssg1_rgmii1_pins_default: icssg1-rgmii1-default-pins{
+		pinctrl-single,pins = <
+			AM64X_IOPAD(0x00b8, PIN_INPUT, 2) /* (Y7) PRG1_PRU0_GPO0.PRG1_RGMII1_RD0 */
+			AM64X_IOPAD(0x00bc, PIN_INPUT, 2) /* (U8) PRG1_PRU0_GPO1.PRG1_RGMII1_RD1 */
+			AM64X_IOPAD(0x00c0, PIN_INPUT, 2) /* (W8) PRG1_PRU0_GPO2.PRG1_RGMII1_RD2 */
+			AM64X_IOPAD(0x00c4, PIN_INPUT, 2) /* (V8) PRG1_PRU0_GPO3.PRG1_RGMII1_RD3 */
+			AM64X_IOPAD(0x00d0, PIN_INPUT, 2) /* (AA7) PRG1_PRU0_GPO6.PRG1_RGMII1_RXC */
+			AM64X_IOPAD(0x00c8, PIN_INPUT, 2) /* (Y8) PRG1_PRU0_GPO4.PRG1_RGMII1_RX_CTL */
+			AM64X_IOPAD(0x00e4, PIN_INPUT, 2) /* (AA8) PRG1_PRU0_GPO11.PRG1_RGMII1_TD0 */
+			AM64X_IOPAD(0x00e8, PIN_INPUT, 2) /* (U9) PRG1_PRU0_GPO12.PRG1_RGMII1_TD1 */
+			AM64X_IOPAD(0x00ec, PIN_INPUT, 2) /* (W9) PRG1_PRU0_GPO13.PRG1_RGMII1_TD2 */
+			AM64X_IOPAD(0x00f0, PIN_INPUT, 2) /* (AA9) PRG1_PRU0_GPO14.PRG1_RGMII1_TD3 */
+			AM64X_IOPAD(0x00f8, PIN_INPUT, 2) /* (V9) PRG1_PRU0_GPO16.PRG1_RGMII1_TXC */
+			AM64X_IOPAD(0x00f4, PIN_INPUT, 2) /* (Y9) PRG1_PRU0_GPO15.PRG1_RGMII1_TX_CTL */
+		>;
+	};
 };
 
 &main_uart0 {
@@ -731,3 +821,15 @@ &main_mcan1 {
 	pinctrl-0 = <&main_mcan1_pins_default>;
 	phys = <&transceiver2>;
 };
+
+&icssg1_mdio {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&icssg1_mdio1_pins_default>;
+
+	icssg1_phy1: ethernet-phy at f {
+		reg = <0xf>;
+		tx-internal-delay-ps = <250>;
+		rx-internal-delay-ps = <2000>;
+	};
+};
-- 
2.34.1



From danishanwar at ti.com  Tue Dec 12 08:58:32 2023
From: danishanwar at ti.com (MD Danish Anwar)
Date: Tue, 12 Dec 2023 22:28:32 +0530
Subject: [PATCH v2 3/3] arm64: dts: ti: k3-am642-evm: add overlay for icssg1 2nd port
In-Reply-To: <20231212165832.3933335-1-danishanwar@ti.com>
References: <20231212165832.3933335-1-danishanwar@ti.com>
Message-ID: <20231212165832.3933335-4-danishanwar@ti.com>

The am642-evm doesn't allow to enable 2 x CPSW3g ports and 2 x ICSSG1 ports
all together, so base k3-am642-evm.dts enables by default 2 x CPSW3g ports
and 1 x ICSSG1 ports, but it also possible to support 1 x CPSW3g ports and
2 x ICSSG1 ports configuration.

This patch adds overlay to support 1 x CPSW3g ports and 2 x ICSSG1 ports
configuration:
- Add label name 'mdio_mux_1' for 'mdio-mux-1' node so that the node
  'mdio-mux-1' can be disabled in the overlay using the label name.
- disable 2nd CPSW3g port
- update CPSW3g pinmuxes to not use RGMII2
- disable mdio-mux-1 and define mdio-mux-2 to route ICSSG1 MDIO to the
  shared DP83869 PHY
- add and enable ICSSG1 RGMII2 pinmuxes
- enable ICSSG1 MII1 port

Signed-off-by: MD Danish Anwar <danishanwar at ti.com>
---
 arch/arm64/boot/dts/ti/Makefile               |  7 +-
 .../dts/ti/k3-am642-evm-icssg1-dualemac.dtso  | 75 +++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  2 +-
 3 files changed, 82 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 1ac47876bc99..654d9cb6cfea 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -43,6 +43,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-icssg1-dualemac.dtbo
 
 # Boards with AM65x SoC
 k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb k3-am654-base-board-rocktech-rk101-panel.dtbo
@@ -103,6 +104,8 @@ k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
 	k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
 k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
 	k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
+k3-am642-evm-icssg1-dualemac-dtbs := \
+	k3-am642-evm.dtb k3-am642-evm-icssg1-dualemac.dtbo
 dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
 	k3-am625-beagleplay-csi2-tevi-ov5640.dtb \
 	k3-am625-sk-csi2-imx219.dtb \
@@ -113,7 +116,8 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
 	k3-am62a7-sk-csi2-imx219.dtb \
 	k3-am62a7-sk-csi2-ov5640.dtb \
 	k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb \
-	k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
+	k3-am642-tqma64xxl-mbax4xxl-wlan.dtb \
+	k3-am642-evm-icssg1-dualemac.dtb
 
 # Enable support for device-tree overlays
 DTC_FLAGS_k3-am625-beagleplay += -@
@@ -121,6 +125,7 @@ DTC_FLAGS_k3-am625-sk += -@
 DTC_FLAGS_k3-am62-lp-sk += -@
 DTC_FLAGS_k3-am62a7-sk += -@
 DTC_FLAGS_k3-am642-tqma64xxl-mbax4xxl += -@
+DTC_FLAGS_k3-am642-evm += -@
 DTC_FLAGS_k3-am6548-iot2050-advanced-m2 += -@
 DTC_FLAGS_k3-j721e-common-proc-board += -@
 DTC_FLAGS_k3-j721s2-common-proc-board += -@
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
new file mode 100644
index 000000000000..b2b1a6252e73
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm-icssg1-dualemac.dtso
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * DT overlay for enabling 2nd ICSSG1 port on AM642 EVM
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "k3-pinctrl.h"
+
+&{/} {
+	mdio-mux-2 {
+		compatible = "mdio-mux-multiplexer";
+		mux-controls = <&mdio_mux>;
+		mdio-parent-bus = <&icssg1_mdio>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		mdio at 0 {
+			reg = <0x0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			icssg1_phy2: ethernet-phy at 3 {
+				reg = <3>;
+				tx-internal-delay-ps = <250>;
+				rx-internal-delay-ps = <2000>;
+			};
+		};
+	};
+};
+
+&main_pmx0 {
+	icssg1_rgmii2_pins_default: icssg1-rgmii2-default-pins {
+		pinctrl-single,pins = <
+			AM64X_IOPAD(0x0108, PIN_INPUT, 2) /* (W11) PRG1_PRU1_GPO0.RGMII2_RD0 */
+			AM64X_IOPAD(0x010c, PIN_INPUT, 2) /* (V11) PRG1_PRU1_GPO1.RGMII2_RD1 */
+			AM64X_IOPAD(0x0110, PIN_INPUT, 2) /* (AA12) PRG1_PRU1_GPO2.RGMII2_RD2 */
+			AM64X_IOPAD(0x0114, PIN_INPUT, 2) /* (Y12) PRG1_PRU1_GPO3.RGMII2_RD3 */
+			AM64X_IOPAD(0x0120, PIN_INPUT, 2) /* (U11) PRG1_PRU1_GPO6.RGMII2_RXC */
+			AM64X_IOPAD(0x0118, PIN_INPUT, 2) /* (W12) PRG1_PRU1_GPO4.RGMII2_RX_CTL */
+			AM64X_IOPAD(0x0134, PIN_OUTPUT, 2) /* (AA10) PRG1_PRU1_GPO11.RGMII2_TD0 */
+			AM64X_IOPAD(0x0138, PIN_OUTPUT, 2) /* (V10) PRG1_PRU1_GPO12.RGMII2_TD1 */
+			AM64X_IOPAD(0x013c, PIN_OUTPUT, 2) /* (U10) PRG1_PRU1_GPO13.RGMII2_TD2 */
+			AM64X_IOPAD(0x0140, PIN_OUTPUT, 2) /* (AA11) PRG1_PRU1_GPO14.RGMII2_TD3 */
+			AM64X_IOPAD(0x0148, PIN_OUTPUT, 2) /* (Y10) PRG1_PRU1_GPO16.RGMII2_TXC */
+			AM64X_IOPAD(0x0144, PIN_OUTPUT, 2) /* (Y11) PRG1_PRU1_GPO15.RGMII2_TX_CTL */
+		>;
+	};
+};
+
+&cpsw3g {
+	pinctrl-0 = <&rgmii1_pins_default>;
+};
+
+&cpsw_port2 {
+	status = "disabled";
+};
+
+&mdio_mux_1 {
+	status = "disabled";
+};
+
+&icssg1_eth {
+	pinctrl-0 = <&icssg1_rgmii1_pins_default>, <&icssg1_rgmii2_pins_default>;
+};
+
+&icssg1_emac1 {
+	status = "okay";
+	phy-handle = <&icssg1_phy2>;
+	phy-mode = "rgmii-id";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index c08b0223be52..6ae43c12419f 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -200,7 +200,7 @@ mdio_mux: mux-controller {
 		mux-gpios = <&exp1 12 GPIO_ACTIVE_HIGH>;
 	};
 
-	mdio-mux-1 {
+	mdio_mux_1: mdio-mux-1 {
 		compatible = "mdio-mux-multiplexer";
 		mux-controls = <&mdio_mux>;
 		mdio-parent-bus = <&cpsw3g_mdio>;
-- 
2.34.1



From conor at kernel.org  Tue Dec 12 09:07:37 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 17:07:37 +0000
Subject: [PATCH v2 3/7] dt-bindings: i2c: document st,stm32mp25-i2c
 compatible
In-Reply-To: <20231208164719.3584028-4-alain.volmat@foss.st.com>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
 <20231208164719.3584028-4-alain.volmat@foss.st.com>
Message-ID: <20231212-slander-violation-8893701db296@spud>

On Fri, Dec 08, 2023 at 05:47:12PM +0100, Alain Volmat wrote:
> Add a new compatible st,stm32mp25-i2c for the STM32MP25 series which
> has only one interrupt line for both events and errors and differs in
> term of handling of FastModePlus.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>

Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/1c2e85be/attachment-0001.sig>

From mark.rutland at arm.com  Tue Dec 12 09:09:08 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 12 Dec 2023 17:09:08 +0000
Subject: [PATCH 0/2] arm64: cpucap handling cleanups
Message-ID: <20231212170910.3745497-1-mark.rutland@arm.com>

The recent changes to remove cpus_have_const_cap() left a period between
detecting cpucaps and patching alternatives where it is necessary to use
cpus_have_cap() to check that a cpucap has been detected. During this
period we do a few things, and there's a risk that code using a mixture
of cpus_have_cap() and alternative_has_cap_*() sees an inconsistent
state.

These patches rework the cpucap code to minimize the period between
detecting cpucaps and patching the relevant alternatives, deferring
other work until after the alternatives have been patched. This removes
the need for some code to use cpus_have_cap(), and allows them to use
common helper functions that may use alternative_has_cap_*() internally,
making them consistent with other kernel code.

This cleanup was requested by Will across:

  https://lore.kernel.org/linux-arm-kernel/20231127154818.GA8453 at willie-the-truck/
  https://lore.kernel.org/linux-arm-kernel/20231127163103.GA8627 at willie-the-truck/
  https://lore.kernel.org/linux-arm-kernel/20231127164127.GB8627 at willie-the-truck/
  https://lore.kernel.org/linux-arm-kernel/20231128110339.GA9717 at willie-the-truck/

The patches are based on the arm64 for-next/fixes branch, whose HEAD
commit is currently:

  f5259997f3e8d6ed ("arm64: Avoid enabling KPTI unnecessarily")

... which patch 1 is partially a cleanup for.

I've given both patches some testing in a few configurations (e.g.
with and without nVHE forced on the command line) to check that
detection and patching works as expected.

Mark.

Mark Rutland (2):
  arm64: Cleanup system cpucap handling
  arm64: Align boot cpucap handling with system cpucap handling

 arch/arm64/include/asm/cpufeature.h |   1 +
 arch/arm64/kernel/cpufeature.c      | 105 +++++++++++++++-------------
 arch/arm64/kernel/fpsimd.c          |   4 +-
 arch/arm64/kernel/smp.c             |  12 +---
 4 files changed, 64 insertions(+), 58 deletions(-)

-- 
2.30.2



From mark.rutland at arm.com  Tue Dec 12 09:09:09 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 12 Dec 2023 17:09:09 +0000
Subject: [PATCH 1/2] arm64: Cleanup system cpucap handling
In-Reply-To: <20231212170910.3745497-1-mark.rutland@arm.com>
References: <20231212170910.3745497-1-mark.rutland@arm.com>
Message-ID: <20231212170910.3745497-2-mark.rutland@arm.com>

Recent changes to remove cpus_have_const_cap() introduced new users of
cpus_have_cap() in the period between detecting system cpucaps and
patching alternatives. It would be preferable to defer these until after
the relevant cpucaps have been patched so that these can use the usual
feature check helper functions, which is clearer and has less risk of
accidental usage of code relying upon an alternative which has not yet
been patched.

This patch reworks the system-wide cpucap detection and patching to
minimize this transient period:

* The detection, enablement, and patching of system cpucaps is moved
  into a new setup_system_capabilities() function so that these can be
  grouped together more clearly, with no other functions called in the
  period between detection and patching. This is called from
  setup_system_features() before the subsequent checks that depend on
  the cpucaps.

  The logging of TTBR0 PAN and cpucaps with a mask is also moved here to
  keep these as close as possible to update_cpu_capabilities().

  At the same time, comments are corrected and improved to make the
  intent clearer.

* As hyp_mode_check() only tests system register values (not hwcaps) and
  must be called prior to patching, the call to hyp_mode_check() is
  moved before the call to setup_system_features().

* In setup_system_features(), the use of system_uses_ttbr0_pan() is
  restored, now that this occurs after alternatives are patched. This is
  a partial revert of commit:

    53d62e995d9eaed1 ("arm64: Avoid cpus_have_const_cap() for ARM64_HAS_PAN")

* In sve_setup() and sme_setup(), the use of system_supports_sve() and
  system_supports_sme() respectively are restored, now that these occur
  after alternatives are patched. This is a partial revert of commit:

    a76521d160284a1e ("arm64: Avoid cpus_have_const_cap() for ARM64_{SVE,SME,SME2,FA64}")

* In kpti_install_ng_mappings(), cpus_have_cap(ARM64_UNMAP_KERNEL_AT_EL0)
  is replaced with arm64_kernel_unmapped_at_el0(), now that this occurs
  after alternatives are patched. This is a cleanup to commit:

    f5259997f3e8d6ed ("arm64: Avoid enabling KPTI unnecessarily")

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Ard Biesheuvel <ardb at kernel.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 48 ++++++++++++++++++++--------------
 arch/arm64/kernel/fpsimd.c     |  4 +--
 arch/arm64/kernel/smp.c        |  3 +--
 3 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 91d2d67149691..a065c259cfcf4 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1840,7 +1840,7 @@ static int __init __kpti_install_ng_mappings(void *__unused)
 static void __init kpti_install_ng_mappings(void)
 {
 	/* Check whether KPTI is going to be used */
-	if (!cpus_have_cap(ARM64_UNMAP_KERNEL_AT_EL0))
+	if (!arm64_kernel_unmapped_at_el0())
 		return;
 
 	/*
@@ -3338,23 +3338,40 @@ unsigned long cpu_get_elf_hwcap2(void)
 	return elf_hwcap[1];
 }
 
-void __init setup_system_features(void)
+static void __init setup_system_capabilities(void)
 {
-	int i;
 	/*
-	 * The system-wide safe feature feature register values have been
-	 * finalized. Finalize and log the available system capabilities.
+	 * The system-wide safe feature register values have been finalized.
+	 * Detect, enable, and patch alternatives for the available system
+	 * cpucaps.
 	 */
 	update_cpu_capabilities(SCOPE_SYSTEM);
-	if (IS_ENABLED(CONFIG_ARM64_SW_TTBR0_PAN) &&
-	    !cpus_have_cap(ARM64_HAS_PAN))
-		pr_info("emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching\n");
+	enable_cpu_capabilities(SCOPE_ALL & ~SCOPE_BOOT_CPU);
+	apply_alternatives_all();
 
 	/*
-	 * Enable all the available capabilities which have not been enabled
-	 * already.
+	 * Log any cpucaps with a cpumask as these aren't logged by
+	 * update_cpu_capabilities().
 	 */
-	enable_cpu_capabilities(SCOPE_ALL & ~SCOPE_BOOT_CPU);
+	for (int i = 0; i < ARM64_NCAPS; i++) {
+		const struct arm64_cpu_capabilities *caps = cpucap_ptrs[i];
+
+		if (caps && caps->cpus && caps->desc &&
+			cpumask_any(caps->cpus) < nr_cpu_ids)
+			pr_info("detected: %s on CPU%*pbl\n",
+				caps->desc, cpumask_pr_args(caps->cpus));
+	}
+
+	/*
+	 * TTBR0 PAN doesn't have its own cpucap, so log it manually.
+	 */
+	if (system_uses_ttbr0_pan())
+		pr_info("emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching\n");
+}
+
+void __init setup_system_features(void)
+{
+	setup_system_capabilities();
 
 	kpti_install_ng_mappings();
 
@@ -3367,15 +3384,6 @@ void __init setup_system_features(void)
 	if (!cache_type_cwg())
 		pr_warn("No Cache Writeback Granule information, assuming %d\n",
 			ARCH_DMA_MINALIGN);
-
-	for (i = 0; i < ARM64_NCAPS; i++) {
-		const struct arm64_cpu_capabilities *caps = cpucap_ptrs[i];
-
-		if (caps && caps->cpus && caps->desc &&
-			cpumask_any(caps->cpus) < nr_cpu_ids)
-			pr_info("detected: %s on CPU%*pbl\n",
-				caps->desc, cpumask_pr_args(caps->cpus));
-	}
 }
 
 void __init setup_user_features(void)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 1559c706d32d1..bc9384517db3d 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -1171,7 +1171,7 @@ void __init sve_setup(void)
 	unsigned long b;
 	int max_bit;
 
-	if (!cpus_have_cap(ARM64_SVE))
+	if (!system_supports_sve())
 		return;
 
 	/*
@@ -1301,7 +1301,7 @@ void __init sme_setup(void)
 	struct vl_info *info = &vl_info[ARM64_VEC_SME];
 	int min_bit, max_bit;
 
-	if (!cpus_have_cap(ARM64_SME))
+	if (!system_supports_sme())
 		return;
 
 	/*
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index defbab84e9e5c..85384dc9a89d6 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -439,9 +439,8 @@ static void __init hyp_mode_check(void)
 void __init smp_cpus_done(unsigned int max_cpus)
 {
 	pr_info("SMP: Total of %d processors activated.\n", num_online_cpus());
-	setup_system_features();
 	hyp_mode_check();
-	apply_alternatives_all();
+	setup_system_features();
 	setup_user_features();
 	mark_linear_text_alias_ro();
 }
-- 
2.30.2



From mark.rutland at arm.com  Tue Dec 12 09:09:10 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 12 Dec 2023 17:09:10 +0000
Subject: [PATCH 2/2] arm64: Align boot cpucap handling with system cpucap handling
In-Reply-To: <20231212170910.3745497-1-mark.rutland@arm.com>
References: <20231212170910.3745497-1-mark.rutland@arm.com>
Message-ID: <20231212170910.3745497-3-mark.rutland@arm.com>

Currently the detection+enablement of boot cpucaps is separate from the
patching of boot cpucap alternatives, which means there's a period where
cpus_have_cap($CAP) and alternative_has_cap($CAP) may be mismatched.

It would be preferable to manage the boot cpucaps in the same way as the
system cpucaps, both for clarity and to minimize the risk of accidental
usage of code relying upon an alternative which has not yet been
patched.

This patch aligns the handling of boot cpucaps with the handling of
system cpucaps:

* The existing setup_boot_cpu_capabilities() function is moved to be
  closer to the setup_system_capabilities() and setup_system_features()
  functions so that they're more clearly related and more likely to be
  updated together in future.

* The patching of boot cpucap alternatives is moved into
  setup_boot_cpu_capabilities(), immediately after boot cpucaps are
  detected and enabled.

* A new setup_boot_cpu_features() function is added to mirror
  setup_system_features(); this handles initialization of cpucap data
  structures and calls setup_boot_cpu_capabilities(). This makes
  init_cpu_features() a closer mirror to update_cpu_features(), and
  makes smp_prepare_boot_cpu() a closer mirror to smp_cpus_done().

Importantly, while these changes alter the structure of the code, they
retain the existing order of calls to:

  init_cpu_features(); // prefix initializing feature regs
  init_cpucap_indirect_list();
  detect_system_supports_pseudo_nmi();
  update_cpu_capabilities(SCOPE_BOOT_CPU | SCOPE_LOCAL_CPU);
  enable_cpu_capabilities(SCOPE_BOOT_CPU);
  apply_boot_alternatives();

... and hence there should be no functional change as a result of this
patch; this is purely a structural cleanup.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
---
 arch/arm64/include/asm/cpufeature.h |  1 +
 arch/arm64/kernel/cpufeature.c      | 57 +++++++++++++++--------------
 arch/arm64/kernel/smp.c             |  9 +----
 3 files changed, 33 insertions(+), 34 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index f6d416fe49b09..2ea24c5cb900e 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -617,6 +617,7 @@ static inline bool id_aa64pfr1_mte(u64 pfr1)
 	return val >= ID_AA64PFR1_EL1_MTE_MTE2;
 }
 
+void __init setup_boot_cpu_features(void);
 void __init setup_system_features(void);
 void __init setup_user_features(void);
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index a065c259cfcf4..008164b7a2d49 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1081,25 +1081,6 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
 
 	if (id_aa64pfr1_mte(info->reg_id_aa64pfr1))
 		init_cpu_ftr_reg(SYS_GMID_EL1, info->reg_gmid);
-
-	/*
-	 * Initialize the indirect array of CPU capabilities pointers before we
-	 * handle the boot CPU below.
-	 */
-	init_cpucap_indirect_list();
-
-	/*
-	 * Detect broken pseudo-NMI. Must be called _before_ the call to
-	 * setup_boot_cpu_capabilities() since it interacts with
-	 * can_use_gic_priorities().
-	 */
-	detect_system_supports_pseudo_nmi();
-
-	/*
-	 * Detect and enable early CPU capabilities based on the boot CPU,
-	 * after we have initialised the CPU feature infrastructure.
-	 */
-	setup_boot_cpu_capabilities();
 }
 
 static void update_cpu_ftr_reg(struct arm64_ftr_reg *reg, u64 new)
@@ -3275,14 +3256,6 @@ void check_local_cpu_capabilities(void)
 		verify_local_cpu_capabilities();
 }
 
-static void __init setup_boot_cpu_capabilities(void)
-{
-	/* Detect capabilities with either SCOPE_BOOT_CPU or SCOPE_LOCAL_CPU */
-	update_cpu_capabilities(SCOPE_BOOT_CPU | SCOPE_LOCAL_CPU);
-	/* Enable the SCOPE_BOOT_CPU capabilities alone right away */
-	enable_cpu_capabilities(SCOPE_BOOT_CPU);
-}
-
 bool this_cpu_has_cap(unsigned int n)
 {
 	if (!WARN_ON(preemptible()) && n < ARM64_NCAPS) {
@@ -3338,6 +3311,36 @@ unsigned long cpu_get_elf_hwcap2(void)
 	return elf_hwcap[1];
 }
 
+static void __init setup_boot_cpu_capabilities(void)
+{
+	/*
+	 * The boot CPU's feature register values have been recorded. Detect
+	 * boot cpucaps and local cpucaps for the boot CPU, then enable and
+	 * patch alternatives for the available boot cpucaps.
+	 */
+	update_cpu_capabilities(SCOPE_BOOT_CPU | SCOPE_LOCAL_CPU);
+	enable_cpu_capabilities(SCOPE_BOOT_CPU);
+	apply_boot_alternatives();
+}
+
+void __init setup_boot_cpu_features(void)
+{
+	/*
+	 * Initialize the indirect array of CPU capabilities pointers before we
+	 * handle the boot CPU.
+	 */
+	init_cpucap_indirect_list();
+
+	/*
+	 * Detect broken pseudo-NMI. Must be called _before_ the call to
+	 * setup_boot_cpu_capabilities() since it interacts with
+	 * can_use_gic_priorities().
+	 */
+	detect_system_supports_pseudo_nmi();
+
+	setup_boot_cpu_capabilities();
+}
+
 static void __init setup_system_capabilities(void)
 {
 	/*
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 85384dc9a89d6..4ced34f62dab5 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -453,14 +453,9 @@ void __init smp_prepare_boot_cpu(void)
 	 * freed shortly, so we must move over to the runtime per-cpu area.
 	 */
 	set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
-	cpuinfo_store_boot_cpu();
 
-	/*
-	 * We now know enough about the boot CPU to apply the
-	 * alternatives that cannot wait until interrupt handling
-	 * and/or scheduling is enabled.
-	 */
-	apply_boot_alternatives();
+	cpuinfo_store_boot_cpu();
+	setup_boot_cpu_features();
 
 	/* Conditionally switch to GIC PMR for interrupt masking */
 	if (system_uses_irq_prio_masking())
-- 
2.30.2



From conor at kernel.org  Tue Dec 12 09:09:57 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 17:09:57 +0000
Subject: [PATCH v1 1/8] dt-bindings: arm: aspeed: add IBM system1-bmc
In-Reply-To: <20231212164004.1683589-2-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-2-ninad@linux.ibm.com>
Message-ID: <20231212-thrower-ebook-d29a85a6ed96@spud>

On Tue, Dec 12, 2023 at 10:39:57AM -0600, Ninad Palsule wrote:
> Document the new compatibles used on IBM system1-bmc
> 
> Tested:
>     This board is tested using the simics simulator.

I don't see how this is relevant to dt-bindings patches.

> 
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---
>  Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
>  Documentation/devicetree/bindings/trivial-devices.yaml   | 2 ++

IMO these should be split into two patches.

Cheers,
Conor.

>  2 files changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
> index 6f7543463d89..ebebe14c42aa 100644
> --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
> +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
> @@ -85,6 +85,7 @@ properties:
>                - facebook,yosemite4-bmc
>                - ibm,everest-bmc
>                - ibm,rainier-bmc
> +              - ibm,system1-bmc
>                - ibm,tacoma-bmc
>                - inventec,starscream-bmc
>                - inventec,transformer-bmc
> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> index 441b55723675..b12a60d2eb0f 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> @@ -135,6 +135,8 @@ properties:
>            - ibm,cffps1
>              # IBM Common Form Factor Power Supply Versions 2
>            - ibm,cffps2
> +            # Infineon barometric pressure and temperature sensor
> +          - infineon,dps310
>              # Infineon IR36021 digital POL buck controller
>            - infineon,ir36021
>              # Infineon IR38060 Voltage Regulator
> -- 
> 2.39.2
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/6650f52e/attachment.sig>

From gustavoars at kernel.org  Tue Dec 12 09:14:29 2023
From: gustavoars at kernel.org (Gustavo A. R. Silva)
Date: Tue, 12 Dec 2023 11:14:29 -0600
Subject: [PATCH v2][wireless-next/for-next] wifi: mt76: mt7996: Use
 DECLARE_FLEX_ARRAY() and fix -Warray-bounds warnings
Message-ID: <ZXiU9ayVCslt3qiI@work>

Transform zero-length arrays `rate`, `adm_stat` and `msdu_cnt` into
proper flexible-array members in anonymous union in `struct
mt7996_mcu_all_sta_info_event` via the DECLARE_FLEX_ARRAY()
helper; and fix multiple -Warray-bounds warnings:

drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:544:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:551:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:553:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:530:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:538:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:540:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:520:57: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]

This results in no differences in binary output, helps with the ongoing
efforts to globally enable -Warray-bounds.

Reviewed-by: Kees Cook <keescook at chromium.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org>
---
Changes in v2:
 - Add Kees' RB tag.
 - Transform zero-length array `rate` into flex-array member.
 - Address five more -Warray-bounds warnings introduced by fake
   flexible array `rate`

 drivers/net/wireless/mediatek/mt76/mt7996/mcu.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
index 3e013b20ee5e..36cacc495c75 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
@@ -206,20 +206,20 @@ struct mt7996_mcu_all_sta_info_event {
 	u8 rsv3[4];
 
 	union {
-		struct all_sta_trx_rate rate[0];
-		struct {
+		DECLARE_FLEX_ARRAY(struct all_sta_trx_rate, rate);
+		DECLARE_FLEX_ARRAY(struct {
 			__le16 wlan_idx;
 			u8 rsv[2];
 			__le32 tx_bytes[IEEE80211_NUM_ACS];
 			__le32 rx_bytes[IEEE80211_NUM_ACS];
-		} adm_stat[0] __packed;
+		} __packed, adm_stat);
 
-		struct {
+		DECLARE_FLEX_ARRAY(struct {
 			__le16 wlan_idx;
 			u8 rsv[2];
 			__le32 tx_msdu_cnt;
 			__le32 rx_msdu_cnt;
-		} msdu_cnt[0] __packed;
+		} __packed, msdu_cnt);
 	} __packed;
 } __packed;
 
-- 
2.34.1



From conor at kernel.org  Tue Dec 12 09:14:26 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 17:14:26 +0000
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <20231212164004.1683589-3-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-3-ninad@linux.ibm.com>
Message-ID: <20231212-amusement-elevation-28e42bcccc35@spud>

Hey,

On Tue, Dec 12, 2023 at 10:39:58AM -0600, Ninad Palsule wrote:
> From: Johannes Holland <johannes.holland at infineon.com>
> 
> Add a dt schema to support device tree bindings

"Add bindings for..."

> for the generic I2C
> physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
> Specification for TPM 2.0 v1.04 Revision 14.
> 
> This includes descriptions for the Nuvoton and Infineon devices.
> 

> OpenBMC-Staging-Count: 3

I have no idea what this is, but it needs to be removed from the patch.

> Signed-off-by: Johannes Holland <johannes.holland at infineon.com>
> Signed-off-by: Joel Stanley <joel at jms.id.au>
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---
>  .../bindings/security/tpm/tpm-tis-i2c.yaml    | 50 +++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> 
> diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> new file mode 100644
> index 000000000000..de1e34065748
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: I2C PTP based TPM Devices
> +
> +maintainers:
> +  - Johannes Holland <johannes.holland at infineon.com>
> +
> +description:
> +  Device Tree Bindings for I2C based Trusted Platform Module (TPM).

s/Device Tree Bindings for //. Doesn't dt_binding_check now complain if
you have this in a title or description?

> +properties:
> +  $nodename:
> +    pattern: "^tpm(@[0-9a-f]+)?$"
> +
> +  compatible:
> +    oneOf:
> +      - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
> +        items:
> +          - const: infineon,slb9673
> +          - const: tcg,tpm-tis-i2c
> +      - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
> +        items:
> +          - const: nuvoton,npct75x
> +          - const: tcg,tpm-tis-i2c

> +      - const: tcg,tpm-tis-i2c

IMO this should be removed and this fallback should only be used in
combination with device specific compatibles, like you have here for the
infineon and nuvoton devices.

Cheers,
Conor.

> +  reg:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    i2c {
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      tpm at 2e {
> +        compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
> +        reg = <0x2e>;
> +      };
> +    };
> +...
> -- 
> 2.39.2
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/bd67d6c0/attachment.sig>

From conor at kernel.org  Tue Dec 12 09:15:51 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 17:15:51 +0000
Subject: [PATCH v1 7/8] tpm: tis-i2c: Add more compatible strings
In-Reply-To: <20231212164004.1683589-8-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-8-ninad@linux.ibm.com>
Message-ID: <20231212-avid-grill-dbead068fac8@spud>

On Tue, Dec 12, 2023 at 10:40:03AM -0600, Ninad Palsule wrote:
> From: Joel Stanley <joel at jms.id.au>
> 
> The NPCT75x TPM is TIS compatible. It has an I2C and SPI interface.
> 
> https://www.nuvoton.com/products/cloud-computing/security/trusted-platform-module-tpm/
> 
> Add a compatible string for it, and the generic compatible.
> 
> OpenBMC-Staging-Count: 3

Delete this from every patch that it appears from.

> Signed-off-by: Joel Stanley <joel at jms.id.au>
> Acked-by: Jarkko Sakkinen <jarkko at kernel.org>
> Link: https://lore.kernel.org/r/20220928043957.2636877-4-joel at jms.id.au
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---
>  drivers/char/tpm/tpm_tis_i2c.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/char/tpm/tpm_tis_i2c.c b/drivers/char/tpm/tpm_tis_i2c.c
> index a897402cc36a..9511c0d50185 100644
> --- a/drivers/char/tpm/tpm_tis_i2c.c
> +++ b/drivers/char/tpm/tpm_tis_i2c.c
> @@ -383,6 +383,8 @@ MODULE_DEVICE_TABLE(i2c, tpm_tis_i2c_id);
>  #ifdef CONFIG_OF
>  static const struct of_device_id of_tis_i2c_match[] = {
>  	{ .compatible = "infineon,slb9673", },
> +	{ .compatible = "nuvoton,npct75x", },
> +	{ .compatible = "tcg,tpm-tis-i2c", },

What's the point of the generic compatible if you are adding the device
specific ones to the driver anyway?

Thanks,
Conor.

>  	{}
>  };
>  MODULE_DEVICE_TABLE(of, of_tis_i2c_match);
> -- 
> 2.39.2
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/4cb4290a/attachment.sig>

From catalin.marinas at arm.com  Tue Dec 12 09:16:15 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 12 Dec 2023 17:16:15 +0000
Subject: [PATCH v9 1/4] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <20231113105234.32058-2-glider@google.com>
References: <20231113105234.32058-1-glider@google.com>
 <20231113105234.32058-2-glider@google.com>
Message-ID: <ZXiVX5FAWZqHfr7m@arm.com>

On Mon, Nov 13, 2023 at 11:52:30AM +0100, Alexander Potapenko wrote:
> The config implements the algorithm compressing memory tags for ARM MTE
> during swapping.
> 
> The algorithm is based on RLE and specifically targets buffers of tags
> corresponding to a single page. In many cases a buffer can be compressed
> into 63 bits, making it possible to store it without additional memory
> allocation.
> 
> Suggested-by: Evgenii Stepanov <eugenis at google.com>
> Signed-off-by: Alexander Potapenko <glider at google.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>

> +void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
> +			size_t *out_len)
> +{
[...]
> +}
> +EXPORT_SYMBOL_NS(mte_tags_to_ranges, MTECOMP);

I may have asked before, what the reason for EXPORT_SYMBOL_NS? Is it for
the kunit tests? Otherwise we don't expect those to be accessed from
modules.

-- 
Catalin


From mark.rutland at arm.com  Tue Dec 12 09:16:12 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 12 Dec 2023 17:16:12 +0000
Subject: [PATCH v2 1/3] arm64: Avoid enabling KPTI unnecessarily
In-Reply-To: <20231211113939.GA24899@willie-the-truck>
References: <20231127120049.2258650-5-ardb@google.com>
 <20231127120049.2258650-6-ardb@google.com>
 <20231127154818.GA8453@willie-the-truck>
 <CAMj1kXFpN8NsS6a9XmBOQ+JybpJtbBb87gyvD5f7Ng4cFs7Sxg@mail.gmail.com>
 <20231127163103.GA8627@willie-the-truck>
 <20231127164127.GB8627@willie-the-truck>
 <ZWTWob3EuIAl_V_B@FVFF77S0Q05N>
 <20231128110339.GA9717@willie-the-truck>
 <ZWX1fHAaiaxLoX8O@FVFF77S0Q05N.cambridge.arm.com>
 <20231211113939.GA24899@willie-the-truck>
Message-ID: <ZXiVXLTYbAgfZcte@FVFF77S0Q05N.cambridge.arm.com>

On Mon, Dec 11, 2023 at 11:39:39AM +0000, Will Deacon wrote:
> On Tue, Nov 28, 2023 at 02:13:16PM +0000, Mark Rutland wrote:
> > On Tue, Nov 28, 2023 at 11:03:40AM +0000, Will Deacon wrote:
> > > On Mon, Nov 27, 2023 at 05:49:21PM +0000, Mark Rutland wrote:
> > > > If you want these cases moves back to alternatives-based feature check helpers,
> > > > I can go do that.
> > > 
> > > I was thinking of something like the diff below to start with.
> > 
> > Sure; as-is that breaks the hyp offset patching, and we'll need ensure we still
> > call hyp_mode_check() before apply_alternatives_all(). In hyp_mode_check() we
> > call kvm_compute_layout(), which generates the 'va_mask', 'tag_val', and
> > 'tag_lsb' values which are used by the kvm_update_va_mask() patching callback
> > (for kern_hyp_va() and __kern_hyp_va()).
> > 
> > I think that can be moved before enable_cpu_capabilities() ratehr than needing
> > to be between enable_cpu_capabilities() and apply_alternatives_all(), but I'll
> > need to go digging to make certain.
> > 
> > Do you want this as a cleanup for v6.7-rc*, or as something to queue for
> > v6.8-rc1?
> 
> Sorry, I keep forgetting to reply to this after we spoke in-person. If
> you're able to spin something in the next day or so, I can pick it up for
> the next merge window. In the meantime, I'll grab Ard's changes so this can
> go on top.

I've sent that to:

  https://lore.kernel.org/linux-arm-kernel/20231212170910.3745497-1-mark.rutland at arm.com/

... based on the arm64 for-next/fixes branch.

Mark.


From catalin.marinas at arm.com  Tue Dec 12 09:16:41 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 12 Dec 2023 17:16:41 +0000
Subject: [PATCH v9 2/4] arm64: mte: add a test for MTE tags compression
In-Reply-To: <20231113105234.32058-3-glider@google.com>
References: <20231113105234.32058-1-glider@google.com>
 <20231113105234.32058-3-glider@google.com>
Message-ID: <ZXiVedYRiJ3aH6IW@arm.com>

On Mon, Nov 13, 2023 at 11:52:31AM +0100, Alexander Potapenko wrote:
> Ensure that tag sequences containing alternating values are compressed
> to buffers of expected size and correctly decompressed afterwards.
> 
> Signed-off-by: Alexander Potapenko <glider at google.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From catalin.marinas at arm.com  Tue Dec 12 09:17:38 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 12 Dec 2023 17:17:38 +0000
Subject: [PATCH v9 3/4] arm64: mte: add compression support to mteswap.c
In-Reply-To: <20231113105234.32058-4-glider@google.com>
References: <20231113105234.32058-1-glider@google.com>
 <20231113105234.32058-4-glider@google.com>
Message-ID: <ZXiVsiPj7iULFCY5@arm.com>

On Mon, Nov 13, 2023 at 11:52:32AM +0100, Alexander Potapenko wrote:
> Update mteswap.c to perform inline compression of memory tags when
> possible.
> 
> If CONFIG_ARM64_MTE_COMP is enabled, mteswap.c will attempt to compress
> saved tags for a struct page and store them directly in Xarray entry
> instead of wasting heap space.
> 
> Soon after booting Android, tag compression saves ~2x memory previously
> spent by mteswap.c on tag allocations. On a moderately loaded device with
> ~20% tagged pages, this leads to saving several megabytes of kernel heap:
> 
>   # cat /sys/kernel/debug/mteswap/stats
>   8 bytes:	102496 allocations,	67302 deallocations
>   128 bytes:	212234 allocations,	178278 deallocations
>   uncompressed tag storage size:	8851200
>   compressed tag storage size:	4346368
> 
> (statistics collection is introduced in the following patch)
> 
> Signed-off-by: Alexander Potapenko <glider at google.com>

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>


From catalin.marinas at arm.com  Tue Dec 12 09:18:17 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 12 Dec 2023 17:18:17 +0000
Subject: [PATCH v9 4/4] arm64: mte: implement CONFIG_ARM64_MTE_SWAP_STATS
In-Reply-To: <20231113105234.32058-5-glider@google.com>
References: <20231113105234.32058-1-glider@google.com>
 <20231113105234.32058-5-glider@google.com>
Message-ID: <ZXiV2R-j0_seVp_i@arm.com>

On Mon, Nov 13, 2023 at 11:52:33AM +0100, Alexander Potapenko wrote:
> Provide a config to collect the usage statistics for ARM MTE tag
> compression. This patch introduces allocation/deallocation counters
> for buffers that were stored uncompressed (and thus occupy 128 bytes of
> heap plus the Xarray overhead to store a pointer) and those that were
> compressed into 8-byte pointers (effectively using 0 bytes of heap in
> addition to the Xarray overhead).
> 
> The counters are exposed to the userspace via
> /sys/kernel/debug/mteswap/stats:
> 
>   # cat /sys/kernel/debug/mteswap/stats
>   8 bytes:      102496 allocations,     67302 deallocations
>   128 bytes:    212234 allocations,     178278 deallocations
>   uncompressed tag storage size:        8851200
>   compressed tag storage size:  4346368
> 
> Suggested-by: Yury Norov <yury.norov at gmail.com>
> Signed-off-by: Alexander Potapenko <glider at google.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From will at kernel.org  Tue Dec 12 09:20:51 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 17:20:51 +0000
Subject: [PATCH v6 00/41] arm64: Reorganize kernel VA space for LPA2
In-Reply-To: <20231129111555.3594833-43-ardb@google.com>
References: <20231129111555.3594833-43-ardb@google.com>
Message-ID: <170237965695.387154.1215830654531305831.b4-ty@kernel.org>

Hi Ard,

I applied some of this:

On Wed, 29 Nov 2023 12:15:56 +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> 
> At the request of Catalin, this series was split off from my LPA2 series
> [0] in order to make the changes a bit more manageable.
> 
> This series reorganizes the kernel VA space, and refactors/replaces the
> early mapping code so that:
> - everything is done only once, in the appropriate order;
> - everything is done with the MMU and caches enabled (*)
> - everything is done from C code (notably, 100s of lines of
>   incomprehensible asm code are removed from head.S).
> 
> [...]

Applied the first three to arm64 (for-next/lpa2-prep):

[01/41] arm64: kernel: Disable latent_entropy GCC plugin in early C runtime
        https://git.kernel.org/arm64/c/3dfdc2750c6c
[02/41] arm64: mm: Take potential load offset into account when KASLR is off
        https://git.kernel.org/arm64/c/a22fc8e102dc
[03/41] arm64: mm: get rid of kimage_vaddr global variable
        https://git.kernel.org/arm64/c/376f5a3bd7e2

Applied the idreg-override part to arm64 (for-next/early-idreg-overrides):

[14/41] arm64: idreg-override: Omit non-NULL checks for override pointer
        https://git.kernel.org/arm64/c/cbc59c9a4e57
[15/41] arm64: idreg-override: Prepare for place relative reloc patching
        https://git.kernel.org/arm64/c/01fd29092a35
[16/41] arm64: idreg-override: Avoid parameq() and parameqn()
        https://git.kernel.org/arm64/c/dc3f5aae0638
[17/41] arm64: idreg-override: avoid strlen() to check for empty strings
        https://git.kernel.org/arm64/c/bcf1eed3f8a0
[18/41] arm64: idreg-override: Avoid sprintf() for simple string concatenation
        https://git.kernel.org/arm64/c/060260a6be47
[19/41] arm64: idreg-override: Avoid kstrtou64() to parse a single hex digit
        https://git.kernel.org/arm64/c/ea48626f8f0e
[20/41] arm64/kernel: Move 'nokaslr' parsing out of early idreg code
        https://git.kernel.org/arm64/c/50f176175e96

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec 12 09:20:52 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 17:20:52 +0000
Subject: [PATCH] drivers/perf: Remove usage of the deprecated ida_simple_xx() API
In-Reply-To: <85b0b73a1b2f743dd5db15d4765c7685100de27f.1702230488.git.christophe.jaillet@wanadoo.fr>
References: <85b0b73a1b2f743dd5db15d4765c7685100de27f.1702230488.git.christophe.jaillet@wanadoo.fr>
Message-ID: <170237283916.1645846.8049910363792099274.b4-ty@kernel.org>

On Sun, 10 Dec 2023 18:48:18 +0100, Christophe JAILLET wrote:
> ida_alloc() and ida_free() should be preferred to the deprecated
> ida_simple_get() and ida_simple_remove().
> 
> This is less verbose.
> 
> 

Applied to will (for-next/perf), thanks!

[1/1] drivers/perf: Remove usage of the deprecated ida_simple_xx() API
      https://git.kernel.org/will/c/79c03ed4b896

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec 12 09:20:53 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 17:20:53 +0000
Subject: [PATCH v7 00/11] arm64: perf: Add support for event counting threshold
In-Reply-To: <20231211161331.1277825-1-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
Message-ID: <170237438420.1648654.4727808470285684911.b4-ty@kernel.org>

On Mon, 11 Dec 2023 16:13:12 +0000, James Clark wrote:
> Changes since v6:
> 
>   * Remove inlines from arm_pmuv3.c
>   * Use format attribute mechanism from SPE
>   * Re-arrange attributes so that threshold comes last and can
>     potentially be extended
>   * Emit an error if the max threshold is exceeded rather than clamping
>   * Convert all register fields to GENMASK
> 
> [...]

Thanks for respinning, James. This looks really good now.

Applied to will (for-next/perf), thanks!

[01/11] arm: perf: Remove inlines from arm_pmuv3.c
        https://git.kernel.org/will/c/9343c790e6de
[02/11] arm: perf/kvm: Use GENMASK for ARMV8_PMU_PMCR_N
        https://git.kernel.org/will/c/62e1f212e5fe
[03/11] arm: perf: Use GENMASK for PMMIR fields
        https://git.kernel.org/will/c/2f6a00f30600
[04/11] arm: perf: Convert remaining fields to use GENMASK
        https://git.kernel.org/will/c/d30f09b6d7de
[05/11] arm64: perf: Include threshold control fields in PMEVTYPER mask
        https://git.kernel.org/will/c/3115ee021bfb
[06/11] arm: pmu: Share user ABI format mechanism with SPE
        https://git.kernel.org/will/c/f6da86969a3c
[07/11] perf/arm_dmc620: Remove duplicate format attribute #defines
        https://git.kernel.org/will/c/a5f4ca68f348
[08/11] KVM: selftests: aarch64: Update tools copy of arm_pmuv3.h
        https://git.kernel.org/will/c/c7b98bf0fc79
[09/11] arm: pmu: Move error message and -EOPNOTSUPP to individual PMUs
        https://git.kernel.org/will/c/186c91aaf549
[10/11] arm64: perf: Add support for event counting threshold
        https://git.kernel.org/will/c/816c26754447
[11/11] Documentation: arm64: Document the PMU event counting threshold feature
        https://git.kernel.org/will/c/bd690638e2c2

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec 12 09:20:54 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 17:20:54 +0000
Subject: [PATCH v2 0/6] SM8450 / SM8550 Adreno
In-Reply-To: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
Message-ID: <170238387694.3096344.13849459949323517316.b4-ty@kernel.org>

On Mon, 04 Dec 2023 13:55:19 +0100, Konrad Dybcio wrote:
> Following the merging of related bindings, driver and mesa changes, enable
> the GPU on both of these platforms.
> 
> P1 for Will/iommu, rest for qcom
> 
> 

Applied SMMU bindings change to will (for-joerg/arm-smmu/bindings), thanks!

[1/6] dt-bindings: arm-smmu: Document SM8[45]50 GPU SMMU
      https://git.kernel.org/will/c/4fff78dc2490
Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec 12 09:20:55 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 17:20:55 +0000
Subject: [PATCH v3 00/12] RB1/QCM2290 features
In-Reply-To: <20231125-topic-rb1_feat-v3-0-4cbb567743bb@linaro.org>
References: <20231125-topic-rb1_feat-v3-0-4cbb567743bb@linaro.org>
Message-ID: <170238433491.3098250.94876533885104502.b4-ty@kernel.org>

On Wed, 29 Nov 2023 15:43:57 +0100, Konrad Dybcio wrote:
> This series brings:
> - interconnect plumbing
> - display setup
> 
> for QCM2290/QRB2210 and
> 
> - CAN bus controller
> - HDMI display
> - wifi fw variant name
> 
> [...]

Applied SMMU update to will (for-joerg/arm-smmu/updates), thanks!

[05/12] iommu/arm-smmu-qcom: Add QCM2290 MDSS compatible
        https://git.kernel.org/will/c/28af105cb650

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec 12 09:20:56 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 17:20:56 +0000
Subject: [PATCH] dt-bindings: iommu: arm,smmu: document clocks for the SM8350 GPU SMMU
In-Reply-To: <20231112184522.3759-1-krzysztof.kozlowski@linaro.org>
References: <20231112184522.3759-1-krzysztof.kozlowski@linaro.org>
Message-ID: <170238274439.3091090.6038983968830615339.b4-ty@kernel.org>

On Sun, 12 Nov 2023 19:45:22 +0100, Krzysztof Kozlowski wrote:
> Document the clocks for Qualcomm SM8350 Adreno GPU SMMU, already used in
> DTS:
> 
>   sm8350-hdk.dtb: iommu at 3da0000: clock-names: False schema does not allow ['bus', 'iface', 'ahb', 'hlos1_vote_gpu_smmu', 'cx_gmu', 'hub_cx_int', 'hub_aon']
> 
> 

Applied to will (for-joerg/arm-smmu/bindings), thanks!

[1/1] dt-bindings: iommu: arm,smmu: document clocks for the SM8350 GPU SMMU
      https://git.kernel.org/will/c/54dae6d5d3f0

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec 12 09:20:57 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 17:20:57 +0000
Subject: [PATCH] iommu/qcom: restore IOMMU state if needed
In-Reply-To: <20231011-msm8953-iommu-restore-v1-1-48a0c93809a2@z3ntu.xyz>
References: <20231011-msm8953-iommu-restore-v1-1-48a0c93809a2@z3ntu.xyz>
Message-ID: <170238443082.3098533.11843607939616442768.b4-ty@kernel.org>

On Wed, 11 Oct 2023 19:57:26 +0200, Luca Weiss wrote:
> From: Vladimir Lypak <vladimir.lypak at gmail.com>
> 
> If the IOMMU has a power domain then some state will be lost in
> qcom_iommu_suspend and TZ will reset device if we don't call
> qcom_scm_restore_sec_cfg before accessing it again.
> 
> 
> [...]

Applied to will (for-joerg/arm-smmu/updates), thanks!

[1/1] iommu/qcom: restore IOMMU state if needed
      https://git.kernel.org/will/c/268dd4edb748

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec 12 09:20:58 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 17:20:58 +0000
Subject: [PATCH v2] dt-bindings: iommu: arm,smmu: document the SM8650 System MMU
In-Reply-To: <20231128-topic-sm8650-upstream-bindings-smmu-v2-1-d3fbcaf1ea92@linaro.org>
References: <20231128-topic-sm8650-upstream-bindings-smmu-v2-1-d3fbcaf1ea92@linaro.org>
Message-ID: <170238294290.3094261.9750012382616477796.b4-ty@kernel.org>

On Tue, 28 Nov 2023 09:41:23 +0100, Neil Armstrong wrote:
> Document the System MMU on the SM8650 Platform.
> 
> 

Applied to will (for-joerg/arm-smmu/bindings), thanks!

[1/1] dt-bindings: iommu: arm,smmu: document the SM8650 System MMU
      https://git.kernel.org/will/c/61683b47df44

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec 12 09:21:00 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 12 Dec 2023 17:21:00 +0000
Subject: [PATCH v2] iommu/arm-smmu-qcom: Add missing GMU entry to match table
In-Reply-To: <20231210180655.75542-1-robdclark@gmail.com>
References: <20231210180655.75542-1-robdclark@gmail.com>
Message-ID: <170238423845.3097390.5149753894021729752.b4-ty@kernel.org>

On Sun, 10 Dec 2023 10:06:53 -0800, Rob Clark wrote:
> From: Rob Clark <robdclark at chromium.org>
> 
> In some cases the firmware expects cbndx 1 to be assigned to the GMU,
> so we also want the default domain for the GMU to be an identy domain.
> This way it does not get a context bank assigned.  Without this, both
> of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
> allocating and configuring a context bank.  So GMU ends up attached to
> both cbndx 1 and later cbndx 2.  This arrangement seemingly confounds
> and surprises the firmware if the GPU later triggers a translation
> fault, resulting (on sc8280xp / lenovo x13s, at least) in the SMMU
> getting wedged and the GPU stuck without memory access.
> 
> [...]

Applied to will (for-joerg/arm-smmu/updates), thanks!

[1/1] iommu/arm-smmu-qcom: Add missing GMU entry to match table
      https://git.kernel.org/will/c/afc95681c306

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From catalin.marinas at arm.com  Tue Dec 12 09:22:54 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 12 Dec 2023 17:22:54 +0000
Subject: [PATCH] perf/arm-cmn: Fail DTC counter allocation correctly
In-Reply-To: <ed589c0d8e4130dc68b8ad1625226d28bdc185d4.1702322847.git.robin.murphy@arm.com>
References: <ed589c0d8e4130dc68b8ad1625226d28bdc185d4.1702322847.git.robin.murphy@arm.com>
Message-ID: <170240171501.947884.15604728153384166017.b4-ty@arm.com>

On Mon, 11 Dec 2023 19:27:28 +0000, Robin Murphy wrote:
> Calling arm_cmn_event_clear() before all DTC indices are allocated is
> wrong, and can lead to arm_cmn_event_add() erroneously clearing live
> counters from full DTCs where allocation fails. Since the DTC counters
> are only updated by arm_cmn_init_counter() after all DTC and DTM
> allocations succeed, nothing actually needs cleaning up in this case
> anyway, and it should just return directly as it did before.
> 
> [...]

Applied to arm64 (for-next/fixes), thanks!

[1/1] perf/arm-cmn: Fail DTC counter allocation correctly
      https://git.kernel.org/arm64/c/1892fe103c3a

-- 
Catalin



From u.kleine-koenig at pengutronix.de  Tue Dec 12 09:26:39 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 18:26:39 +0100
Subject: [PATCH 2/5] drm/meson: Simplify usage of clk_rate_exclusive_get()
In-Reply-To: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
Message-ID: <c39cc382fcceca0166440367307260c10de7200d.1702400947.git.u.kleine-koenig@pengutronix.de>

clk_rate_exclusive_get() returns 0 unconditionally. So remove error
handling. This prepares making clk_rate_exclusive_get() return void.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
Hello,

btw, the driver fails to call clk_rate_exclusive_put() in the error
paths of dw_mipi_dsi_phy_init().

Best regards
Uwe

 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
index a6bc1bdb3d0d..49571f1ed88a 100644
--- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -88,15 +88,9 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
 	}
 
 	/* Make sure the rate of the bit clock is not modified by someone else */
-	ret = clk_rate_exclusive_get(mipi_dsi->bit_clk);
-	if (ret) {
-		dev_err(mipi_dsi->dev,
-			"Failed to set the exclusivity on the bit clock rate (ret %d)\n", ret);
-		return ret;
-	}
+	clk_rate_exclusive_get(mipi_dsi->bit_clk);
 
 	ret = clk_set_rate(mipi_dsi->px_clk, mipi_dsi->mode->clock * 1000);
-
 	if (ret) {
 		dev_err(mipi_dsi->dev, "Failed to set DSI Pixel clock rate %u (%d)\n",
 			mipi_dsi->mode->clock * 1000, ret);
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Tue Dec 12 09:26:38 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 18:26:38 +0100
Subject: [PATCH 1/5] PM / devfreq: sun8i-a33-mbus: Simplify usage of clk_rate_exclusive_get()
In-Reply-To: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
Message-ID: <5ef585a3d7bee42bac5be0e40efcfbc6e75adfff.1702400947.git.u.kleine-koenig@pengutronix.de>

clk_rate_exclusive_get() returns 0 unconditionally. So remove error
handling. This prepares making clk_rate_exclusive_get() return void.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/devfreq/sun8i-a33-mbus.c | 14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/devfreq/sun8i-a33-mbus.c b/drivers/devfreq/sun8i-a33-mbus.c
index 13d32213139f..bbc577556944 100644
--- a/drivers/devfreq/sun8i-a33-mbus.c
+++ b/drivers/devfreq/sun8i-a33-mbus.c
@@ -381,18 +381,10 @@ static int sun8i_a33_mbus_probe(struct platform_device *pdev)
 				     "failed to enable bus clock\n");
 
 	/* Lock the DRAM clock rate to keep priv->nominal_bw in sync. */
-	ret = clk_rate_exclusive_get(priv->clk_dram);
-	if (ret) {
-		err = "failed to lock dram clock rate\n";
-		goto err_disable_bus;
-	}
+	clk_rate_exclusive_get(priv->clk_dram);
 
 	/* Lock the MBUS clock rate to keep MBUS_TMR_PERIOD in sync. */
-	ret = clk_rate_exclusive_get(priv->clk_mbus);
-	if (ret) {
-		err = "failed to lock mbus clock rate\n";
-		goto err_unlock_dram;
-	}
+	clk_rate_exclusive_get(priv->clk_mbus);
 
 	priv->gov_data.upthreshold	= 10;
 	priv->gov_data.downdifferential	=  5;
@@ -450,9 +442,7 @@ static int sun8i_a33_mbus_probe(struct platform_device *pdev)
 	dev_pm_opp_remove_all_dynamic(dev);
 err_unlock_mbus:
 	clk_rate_exclusive_put(priv->clk_mbus);
-err_unlock_dram:
 	clk_rate_exclusive_put(priv->clk_dram);
-err_disable_bus:
 	clk_disable_unprepare(priv->clk_bus);
 
 	return dev_err_probe(dev, ret, err);
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Tue Dec 12 09:26:42 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 18:26:42 +0100
Subject: [PATCH 5/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
Message-ID: <3f556647c09162be61edba6b50e76d235aace590.1702400947.git.u.kleine-koenig@pengutronix.de>

The function currently returns 0 unconditionally. This isn't very useful
and makes users create dead code error paths. So let this function
return no value. All users were adapted before to ignore the returned
value.

Also fix a few typos in the kernel doc comment for
clk_rate_exclusive_get().

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/clk/clk.c   | 6 ++----
 include/linux/clk.h | 8 +++-----
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2253c154a824..af2011c2a93b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -925,17 +925,15 @@ static void clk_core_rate_restore_protect(struct clk_core *core, int count)
  * clk_rate_exclusive_put(). Calls to this function may sleep.
  * Returns 0 on success, -EERROR otherwise
  */
-int clk_rate_exclusive_get(struct clk *clk)
+void clk_rate_exclusive_get(struct clk *clk)
 {
 	if (!clk)
-		return 0;
+		return;
 
 	clk_prepare_lock();
 	clk_core_rate_protect(clk->core);
 	clk->exclusive_count++;
 	clk_prepare_unlock();
-
-	return 0;
 }
 EXPORT_SYMBOL_GPL(clk_rate_exclusive_get);
 
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 06f1b292f8a0..f88c407925f8 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -190,16 +190,14 @@ bool clk_is_match(const struct clk *p, const struct clk *q);
  *
  * This function allows drivers to get exclusive control over the rate of a
  * provider. It prevents any other consumer to execute, even indirectly,
- * opereation which could alter the rate of the provider or cause glitches
+ * operation which could alter the rate of the provider or cause glitches
  *
- * If exlusivity is claimed more than once on clock, even by the same driver,
+ * If exclusivity is claimed more than once on clock, even by the same driver,
  * the rate effectively gets locked as exclusivity can't be preempted.
  *
  * Must not be called from within atomic context.
- *
- * Returns success (0) or negative errno.
  */
-int clk_rate_exclusive_get(struct clk *clk);
+void clk_rate_exclusive_get(struct clk *clk);
 
 /**
  * clk_rate_exclusive_put - release exclusivity over the rate control of a
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Tue Dec 12 09:26:37 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 18:26:37 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
Message-ID: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>

Hello,

clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
that and don't check the return value. This series fixes the four users
that do error checking on the returned value and then makes function
return void.

Given that the changes to the drivers are simple and so merge conflicts
(if any) should be easy to handle, I suggest to merge this complete
series via the clk tree.

Best regards
Uwe

Uwe Kleine-K?nig (5):
  PM / devfreq: sun8i-a33-mbus: Simplify usage of
    clk_rate_exclusive_get()
  drm/meson: Simplify usage of clk_rate_exclusive_get()
  memory: tegra210-emc: Simplify usage of clk_rate_exclusive_get()
  memory: tegra30-emc: Simplify usage of clk_rate_exclusive_get()
  clk: Make clk_rate_exclusive_get() return void

 drivers/clk/clk.c                         |  6 ++----
 drivers/devfreq/sun8i-a33-mbus.c          | 14 ++------------
 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c |  8 +-------
 drivers/memory/tegra/tegra210-emc-core.c  |  6 +-----
 drivers/memory/tegra/tegra30-emc.c        |  6 +-----
 include/linux/clk.h                       |  8 +++-----
 6 files changed, 10 insertions(+), 38 deletions(-)


base-commit: bbd220ce4e29ed55ab079007cff0b550895258eb
-- 
2.42.0



From catalin.marinas at arm.com  Tue Dec 12 09:31:59 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 12 Dec 2023 17:31:59 +0000
Subject: [PATCH v3 1/2] kvm: arm64: introduce new flag for non-cacheable
 IO memory
In-Reply-To: <20231208164709.23101-2-ankita@nvidia.com>
References: <20231208164709.23101-1-ankita@nvidia.com>
 <20231208164709.23101-2-ankita@nvidia.com>
Message-ID: <ZXiZDwaCtHpPGXh6@arm.com>

On Fri, Dec 08, 2023 at 10:17:08PM +0530, ankita at nvidia.com wrote:
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index c651df904fe3..d4835d553c61 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -718,10 +718,17 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
>  				kvm_pte_t *ptep)
>  {
>  	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
> -	kvm_pte_t attr = device ? KVM_S2_MEMATTR(pgt, DEVICE_nGnRE) :
> -			    KVM_S2_MEMATTR(pgt, NORMAL);
> +	bool normal_nc = prot & KVM_PGTABLE_PROT_NORMAL_NC;
> +	kvm_pte_t attr;
>  	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
>  
> +	if (device)
> +		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
> +	else if (normal_nc)
> +		attr = KVM_S2_MEMATTR(pgt, NORMAL_NC);
> +	else
> +		attr = KVM_S2_MEMATTR(pgt, NORMAL);

As Will said, maybe a WARN_ON_ONCE(device && normal_nc). It would fall
back to device which I think is fine.

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>


From conor at kernel.org  Tue Dec 12 09:33:06 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 17:33:06 +0000
Subject: [PATCH 1/3] dt-bindings: extcon: ptn5150: Describe the USB
 connector
In-Reply-To: <20231212112729.700987-1-festevam@gmail.com>
References: <20231212112729.700987-1-festevam@gmail.com>
Message-ID: <20231212-helium-sixtyfold-ec721c7b5e41@spud>

On Tue, Dec 12, 2023 at 08:27:27AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> PTN5150 supports USB Type-C connector, so improve the bindings by
> allowing to describe the connector like it is done on nxp,ptn5110.yaml.
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>
> ---
>  Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
> index d5cfa32ea52d..3837da7416e9 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
> +++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
> @@ -37,6 +37,11 @@ properties:
>        GPIO pin (output) used to control VBUS. If skipped, no such control
>        takes place.
>  
> +  connector:
> +    type: object
> +    $ref: /schemas/connector/usb-connector.yaml#
> +    unevaluatedProperties: false

FWIW, neither the type nor the uneval properties should be needed here,
the referenced schema has additionalProperties: False.

Otherwise,
Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> +
>  required:
>    - compatible
>    - interrupts
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/e76dc6cd/attachment-0001.sig>

From acme at kernel.org  Tue Dec 12 09:39:05 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Tue, 12 Dec 2023 14:39:05 -0300
Subject: [PATCH v1 02/14] libperf cpumap: Rename and prefer sysfs for
 perf_cpu_map__default_new
In-Reply-To: <20231129060211.1890454-3-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-3-irogers@google.com>
Message-ID: <ZXiauao3bIbc0ZCo@kernel.org>

Em Tue, Nov 28, 2023 at 10:01:59PM -0800, Ian Rogers escreveu:
> Rename perf_cpu_map__default_new to perf_cpu_map__new_online_cpus to
> better indicate what the implementation does. Read the online CPUs
> from /sys/devices/system/cpu/online first before using sysconf as
> sysconf can't accurately configure holes in the CPU map. If sysconf is
> used, warn when the configured and online processors disagree.
> 
> When reading from a file, if the read doesn't yield a CPU map then
> return an empty map rather than the default online. This avoids
> recursion but also better yields being able to detect failures.
> 
> Add more comments.
> 
> Signed-off-by: Ian Rogers <irogers at google.com>
> ---
>  tools/lib/perf/cpumap.c              | 59 +++++++++++++++++-----------
>  tools/lib/perf/include/perf/cpumap.h | 15 ++++++-
>  tools/lib/perf/libperf.map           |  2 +-
>  tools/lib/perf/tests/test-cpumap.c   |  2 +-
>  4 files changed, 51 insertions(+), 27 deletions(-)
> 
> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
> index 2bd6aba3d8c9..463ca8b37d45 100644
> --- a/tools/lib/perf/cpumap.c
> +++ b/tools/lib/perf/cpumap.c
> @@ -9,6 +9,7 @@
>  #include <unistd.h>
>  #include <ctype.h>
>  #include <limits.h>
> +#include "internal.h"
>  
>  void perf_cpu_map__set_nr(struct perf_cpu_map *map, int nr_cpus)
>  {
> @@ -66,15 +67,21 @@ void perf_cpu_map__put(struct perf_cpu_map *map)
>  	}
>  }
>  
> -static struct perf_cpu_map *cpu_map__default_new(void)
> +static struct perf_cpu_map *cpu_map__new_sysconf(void)
>  {
>  	struct perf_cpu_map *cpus;
> -	int nr_cpus;
> +	int nr_cpus, nr_cpus_conf;
>  
>  	nr_cpus = sysconf(_SC_NPROCESSORS_ONLN);
>  	if (nr_cpus < 0)
>  		return NULL;
>  
> +	nr_cpus_conf = sysconf(_SC_NPROCESSORS_CONF);
> +	if (nr_cpus != nr_cpus_conf) {
> +		pr_warning("Number of online CPUs (%d) differs from the number configured (%d) the CPU map will only cover the first %d CPUs.",
> +			nr_cpus, nr_cpus_conf, nr_cpus);
> +	}
> +
>  	cpus = perf_cpu_map__alloc(nr_cpus);
>  	if (cpus != NULL) {
>  		int i;
> @@ -86,9 +93,27 @@ static struct perf_cpu_map *cpu_map__default_new(void)
>  	return cpus;
>  }
>  
> -struct perf_cpu_map *perf_cpu_map__default_new(void)
> +static struct perf_cpu_map *cpu_map__new_syfs_online(void)

I'm renaming this to cpu_map__new_sysfs_online(), ok?

- Arnaldo

>  {
> -	return cpu_map__default_new();
> +	struct perf_cpu_map *cpus = NULL;
> +	FILE *onlnf;
> +
> +	onlnf = fopen("/sys/devices/system/cpu/online", "r");
> +	if (onlnf) {
> +		cpus = perf_cpu_map__read(onlnf);
> +		fclose(onlnf);
> +	}
> +	return cpus;
> +}
> +
> +struct perf_cpu_map *perf_cpu_map__new_online_cpus(void)
> +{
> +	struct perf_cpu_map *cpus = cpu_map__new_syfs_online();
> +
> +	if (cpus)
> +		return cpus;
> +
> +	return cpu_map__new_sysconf();
>  }
>  
>  
> @@ -180,27 +205,11 @@ struct perf_cpu_map *perf_cpu_map__read(FILE *file)
>  
>  	if (nr_cpus > 0)
>  		cpus = cpu_map__trim_new(nr_cpus, tmp_cpus);
> -	else
> -		cpus = cpu_map__default_new();
>  out_free_tmp:
>  	free(tmp_cpus);
>  	return cpus;
>  }
>  
> -static struct perf_cpu_map *cpu_map__read_all_cpu_map(void)
> -{
> -	struct perf_cpu_map *cpus = NULL;
> -	FILE *onlnf;
> -
> -	onlnf = fopen("/sys/devices/system/cpu/online", "r");
> -	if (!onlnf)
> -		return cpu_map__default_new();
> -
> -	cpus = perf_cpu_map__read(onlnf);
> -	fclose(onlnf);
> -	return cpus;
> -}
> -
>  struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
>  {
>  	struct perf_cpu_map *cpus = NULL;
> @@ -211,7 +220,7 @@ struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
>  	int max_entries = 0;
>  
>  	if (!cpu_list)
> -		return cpu_map__read_all_cpu_map();
> +		return perf_cpu_map__new_online_cpus();
>  
>  	/*
>  	 * must handle the case of empty cpumap to cover
> @@ -268,9 +277,11 @@ struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
>  
>  	if (nr_cpus > 0)
>  		cpus = cpu_map__trim_new(nr_cpus, tmp_cpus);
> -	else if (*cpu_list != '\0')
> -		cpus = cpu_map__default_new();
> -	else
> +	else if (*cpu_list != '\0') {
> +		pr_warning("Unexpected characters at end of cpu list ('%s'), using online CPUs.",
> +			   cpu_list);
> +		cpus = perf_cpu_map__new_online_cpus();
> +	} else
>  		cpus = perf_cpu_map__new_any_cpu();
>  invalid:
>  	free(tmp_cpus);
> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> index d0bf218ada11..b24bd8b8f34e 100644
> --- a/tools/lib/perf/include/perf/cpumap.h
> +++ b/tools/lib/perf/include/perf/cpumap.h
> @@ -22,7 +22,20 @@ struct perf_cpu_map;
>   * perf_cpu_map__new_any_cpu - a map with a singular "any CPU"/dummy -1 value.
>   */
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__new_any_cpu(void);
> -LIBPERF_API struct perf_cpu_map *perf_cpu_map__default_new(void);
> +/**
> + * perf_cpu_map__new_online_cpus - a map read from
> + *                                 /sys/devices/system/cpu/online if
> + *                                 available. If reading wasn't possible a map
> + *                                 is created using the online processors
> + *                                 assuming the first 'n' processors are all
> + *                                 online.
> + */
> +LIBPERF_API struct perf_cpu_map *perf_cpu_map__new_online_cpus(void);
> +/**
> + * perf_cpu_map__new - create a map from the given cpu_list such as "0-7". If no
> + *                     cpu_list argument is provided then
> + *                     perf_cpu_map__new_online_cpus is returned.
> + */
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list);
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__read(FILE *file);
>  LIBPERF_API struct perf_cpu_map *perf_cpu_map__get(struct perf_cpu_map *map);
> diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> index a8ff64baea3e..8a71f841498e 100644
> --- a/tools/lib/perf/libperf.map
> +++ b/tools/lib/perf/libperf.map
> @@ -2,7 +2,7 @@ LIBPERF_0.0.1 {
>  	global:
>  		libperf_init;
>  		perf_cpu_map__new_any_cpu;
> -		perf_cpu_map__default_new;
> +		perf_cpu_map__new_online_cpus;
>  		perf_cpu_map__get;
>  		perf_cpu_map__put;
>  		perf_cpu_map__new;
> diff --git a/tools/lib/perf/tests/test-cpumap.c b/tools/lib/perf/tests/test-cpumap.c
> index 2c359bdb951e..c998b1dae863 100644
> --- a/tools/lib/perf/tests/test-cpumap.c
> +++ b/tools/lib/perf/tests/test-cpumap.c
> @@ -29,7 +29,7 @@ int test_cpumap(int argc, char **argv)
>  	perf_cpu_map__put(cpus);
>  	perf_cpu_map__put(cpus);
>  
> -	cpus = perf_cpu_map__default_new();
> +	cpus = perf_cpu_map__new_online_cpus();
>  	if (!cpus)
>  		return -1;
>  
> -- 
> 2.43.0.rc1.413.gea7ed67945-goog
> 

-- 

- Arnaldo


From jpoimboe at kernel.org  Tue Dec 12 09:42:52 2023
From: jpoimboe at kernel.org (Josh Poimboeuf)
Date: Tue, 12 Dec 2023 09:42:52 -0800
Subject: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
In-Reply-To: <ZXgH6un2uLdjQ48X@infradead.org>
References: <20231122030621.3759313-1-samuel.holland@sifive.com>
 <20231122030621.3759313-4-samuel.holland@sifive.com>
 <ZV2+f/yu3C6xTVqn@infradead.org>
 <6d4cecd5-9083-4d68-a7e2-266dae9e3952@sifive.com>
 <ZXgH6un2uLdjQ48X@infradead.org>
Message-ID: <20231212174252.ycztjhgyhtcrffur@treble>

On Mon, Dec 11, 2023 at 11:12:42PM -0800, Christoph Hellwig wrote:
> On Thu, Dec 07, 2023 at 10:49:53PM -0600, Samuel Holland wrote:
> > Actually tracking all possibly-FPU-tainted functions and their call sites is
> > probably possible, but a much larger task.
> 
> I think objtool should be able to do that reasonably easily, it already
> does it for checking section where userspace address access is enabled
> or not, which is very similar.

Yeah, that might be doable.  I can look into it.

-- 
Josh


From suzuki.poulose at arm.com  Tue Dec 12 09:44:14 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 12 Dec 2023 17:44:14 +0000
Subject: [PATCH 1/8] coresight: Fix issue where a source device's helpers
 aren't disabled
In-Reply-To: <20231212155407.1429121-2-james.clark@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
 <20231212155407.1429121-2-james.clark@arm.com>
Message-ID: <a1ab2481-0ec0-4e29-b6af-bcce4cf0b57d@arm.com>

Hi James

On 12/12/2023 15:53, James Clark wrote:
> The linked commit reverts the change that accidentally used some sysfs
> enable/disable functions from Perf which broke the refcounting, but it
> also removes the fact that the sysfs disable function disabled the
> helpers.


> 
> Add a new wrapper function that does both which is used by both Perf and
> sysfs, and label the sysfs disable function appropriately. The naming of
> all of the functions will be tidied up later to avoid this happening
> again.
> 
> Fixes: 287e82cf69aa ("coresight: Fix crash when Perf and sysfs modes are used concurrently")

But we still don't "enable" the helpers from perf mode with this patch.
i.e., we use source_ops()->enable directly. So, I guess this patch
doesn't fix a bug as such. But that said, it would be good to
enable/disable helpers for sources, in perf mode.

Suzuki


> Signed-off-by: James Clark <james.clark at arm.com>
> ---
>   drivers/hwtracing/coresight/coresight-core.c  | 30 ++++++++++++++-----
>   .../hwtracing/coresight/coresight-etm-perf.c  |  2 +-
>   drivers/hwtracing/coresight/coresight-priv.h  |  2 +-
>   3 files changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index d7f0e231feb9..965bb6d4e1bf 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -441,8 +441,26 @@ static void coresight_disable_helpers(struct coresight_device *csdev)
>   	}
>   }
>   
> +/*
> + * Helper function to call source_ops(csdev)->disable and also disable the
> + * helpers.
> + *
> + * There is an imbalance between coresight_enable_path() and
> + * coresight_disable_path(). Enabling also enables the source's helpers as part
> + * of the path, but disabling always skips the first item in the path (which is
> + * the source), so sources and their helpers don't get disabled as part of that
> + * function and we need the extra step here.
> + */
> +void coresight_disable_source(struct coresight_device *csdev, void *data)
> +{
> +	if (source_ops(csdev)->disable)
> +		source_ops(csdev)->disable(csdev, data);
> +	coresight_disable_helpers(csdev);
> +}
> +EXPORT_SYMBOL_GPL(coresight_disable_source);
> +
>   /**
> - *  coresight_disable_source - Drop the reference count by 1 and disable
> + *  coresight_disable_source_sysfs - Drop the reference count by 1 and disable
>    *  the device if there are no users left.
>    *
>    *  @csdev: The coresight device to disable
> @@ -451,17 +469,15 @@ static void coresight_disable_helpers(struct coresight_device *csdev)
>    *
>    *  Returns true if the device has been disabled.
>    */
> -bool coresight_disable_source(struct coresight_device *csdev, void *data)
> +static bool coresight_disable_source_sysfs(struct coresight_device *csdev,
> +					   void *data)
>   {
>   	if (atomic_dec_return(&csdev->refcnt) == 0) {
> -		if (source_ops(csdev)->disable)
> -			source_ops(csdev)->disable(csdev, data);
> -		coresight_disable_helpers(csdev);
> +		coresight_disable_source(csdev, data);
>   		csdev->enable = false;
>   	}
>   	return !csdev->enable;
>   }
> -EXPORT_SYMBOL_GPL(coresight_disable_source);
>   
>   /*
>    * coresight_disable_path_from : Disable components in the given path beyond
> @@ -1204,7 +1220,7 @@ void coresight_disable(struct coresight_device *csdev)
>   	if (ret)
>   		goto out;
>   
> -	if (!csdev->enable || !coresight_disable_source(csdev, NULL))
> +	if (!csdev->enable || !coresight_disable_source_sysfs(csdev, NULL))
>   		goto out;
>   
>   	switch (csdev->subtype.source_subtype) {
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index a52cfcce25d6..c0c60e6a1703 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -589,7 +589,7 @@ static void etm_event_stop(struct perf_event *event, int mode)
>   		return;
>   
>   	/* stop tracer */
> -	source_ops(csdev)->disable(csdev, event);
> +	coresight_disable_source(csdev, event);

Does this result i
>   
>   	/* tell the core */
>   	event->hw.state = PERF_HES_STOPPED;
> diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
> index 767076e07970..30c051055e54 100644
> --- a/drivers/hwtracing/coresight/coresight-priv.h
> +++ b/drivers/hwtracing/coresight/coresight-priv.h
> @@ -233,6 +233,6 @@ void coresight_set_percpu_sink(int cpu, struct coresight_device *csdev);
>   struct coresight_device *coresight_get_percpu_sink(int cpu);
>   int coresight_enable_source(struct coresight_device *csdev, enum cs_mode mode,
>   			    void *data);
> -bool coresight_disable_source(struct coresight_device *csdev, void *data);
> +void coresight_disable_source(struct coresight_device *csdev, void *data);
>   
>   #endif



From catalin.marinas at arm.com  Tue Dec 12 09:46:34 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 12 Dec 2023 17:46:34 +0000
Subject: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for
 vfio pci devices
In-Reply-To: <20231208164709.23101-3-ankita@nvidia.com>
References: <20231208164709.23101-1-ankita@nvidia.com>
 <20231208164709.23101-3-ankita@nvidia.com>
Message-ID: <ZXicemDzXm8NShs1@arm.com>

On Fri, Dec 08, 2023 at 10:17:09PM +0530, ankita at nvidia.com wrote:
>  arch/arm64/kvm/hyp/pgtable.c     |  3 +++
>  arch/arm64/kvm/mmu.c             | 16 +++++++++++++---
>  drivers/vfio/pci/vfio_pci_core.c |  3 ++-
>  include/linux/mm.h               |  7 +++++++
>  4 files changed, 25 insertions(+), 4 deletions(-)

It might be worth factoring out the vfio bits into a separate patch
together with a bit of documentation around this new vma flag (up to
Alex really).

> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index d4835d553c61..c8696c9e7a60 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -722,6 +722,9 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
>  	kvm_pte_t attr;
>  	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
>  
> +	if (device && normal_nc)
> +		return -EINVAL;

Ah, the comment Will and I made on patch 1 is handled here. Add a
WARN_ON_ONCE() and please move this hunk to the first patch, it makes
more sense there.

> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index d14504821b79..1ce1b6d89bf9 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1381,7 +1381,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	int ret = 0;
>  	bool write_fault, writable, force_pte = false;
>  	bool exec_fault, mte_allowed;
> -	bool device = false;
> +	bool device = false, vfio_pci_device = false;

I don't think the variable here should be named vfio_pci_device, the
VM_* flag doesn't mention PCI. So just something like "vfio_allow_wc".

>  	unsigned long mmu_seq;
>  	struct kvm *kvm = vcpu->kvm;
>  	struct kvm_mmu_memory_cache *memcache = &vcpu->arch.mmu_page_cache;
> @@ -1472,6 +1472,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	gfn = fault_ipa >> PAGE_SHIFT;
>  	mte_allowed = kvm_vma_mte_allowed(vma);
>  
> +	vfio_pci_device = !!(vma->vm_flags & VM_VFIO_ALLOW_WC);

Nitpick: no need for !!, you are assigning to a bool variable already.

> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index 1cbc990d42e0..c3f95ec7fc3a 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -1863,7 +1863,8 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
>  	 * See remap_pfn_range(), called from vfio_pci_fault() but we can't
>  	 * change vm_flags within the fault handler.  Set them now.
>  	 */
> -	vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
> +	vm_flags_set(vma, VM_VFIO_ALLOW_WC | VM_IO | VM_PFNMAP |
> +			VM_DONTEXPAND | VM_DONTDUMP);

Please add a comment here that write-combining is allowed to be enabled
by the arch (KVM) code but the default user mmap() will still use
pgprot_noncached().

>  	vma->vm_ops = &vfio_pci_mmap_ops;
>  
>  	return 0;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index a422cc123a2d..8d3c4820c492 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -391,6 +391,13 @@ extern unsigned int kobjsize(const void *objp);
>  # define VM_UFFD_MINOR		VM_NONE
>  #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
>  
> +#ifdef CONFIG_64BIT
> +#define VM_VFIO_ALLOW_WC_BIT	39	/* Convey KVM to map S2 NORMAL_NC */

This comment shouldn't be in the core header file. It knows nothing
about S2 and Normal-NC, that's arm64 terminology. You can mention
something like VFIO can use this flag hint that write-combining is
allowed.

> +#define VM_VFIO_ALLOW_WC	BIT(VM_VFIO_ALLOW_WC_BIT)
> +#else
> +#define VM_VFIO_ALLOW_WC	VM_NONE
> +#endif

And I think we need to add some documentation (is there any
VFIO-specific doc) that describes what this flag actually means, what is
permitted. For example, arm64 doesn't have write-combining without
speculative fetches. So if one adds this flag to a new driver, they
should know the implications. There's also an expectation that the
actual driver (KVM guests) or maybe later DPDK can choose the safe
non-cacheable or write-combine (Linux terminology) attributes for the
BAR.

-- 
Catalin


From festevam at gmail.com  Tue Dec 12 09:48:45 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 12 Dec 2023 14:48:45 -0300
Subject: [PATCH v2 1/3] dt-bindings: extcon: ptn5150: Describe the USB connector
Message-ID: <20231212174847.759164-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

PTN5150 supports USB Type-C connector, so improve the bindings by
allowing to describe the connector like it is done on nxp,ptn5110.yaml.

Signed-off-by: Fabio Estevam <festevam at denx.de>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v1:
- Removed type and unevaluatedProperties: false (Conor).

 Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
index d5cfa32ea52d..b3e5c0df0cd7 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
+++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
@@ -37,6 +37,9 @@ properties:
       GPIO pin (output) used to control VBUS. If skipped, no such control
       takes place.
 
+  connector:
+    $ref: /schemas/connector/usb-connector.yaml#
+
 required:
   - compatible
   - interrupts
-- 
2.34.1



From festevam at gmail.com  Tue Dec 12 09:48:46 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 12 Dec 2023 14:48:46 -0300
Subject: [PATCH v2 2/3] arm64: dts: imx8mn-var-som-symphony: Describe the USB-C connector
In-Reply-To: <20231212174847.759164-1-festevam@gmail.com>
References: <20231212174847.759164-1-festevam@gmail.com>
Message-ID: <20231212174847.759164-2-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Describe the PTN5150 USB-C connector to improve the devicetree description
and fix the following dt-schema warning:

imx8mn-var-som-symphony.dtb: typec at 3d: 'port' does not match any of the regexes: 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/extcon/extcon-ptn5150.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
Changes since v1:
- None

 .../boot/dts/freescale/imx8mn-var-som-symphony.dts    | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts
index a6b94d1957c9..f38ee2266b25 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-var-som-symphony.dts
@@ -128,9 +128,14 @@ extcon_usbotg1: typec at 3d {
 		pinctrl-0 = <&pinctrl_ptn5150>;
 		status = "okay";
 
-		port {
-			typec1_dr_sw: endpoint {
-				remote-endpoint = <&usb1_drd_sw>;
+		connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+
+			port {
+				typec1_dr_sw: endpoint {
+					remote-endpoint = <&usb1_drd_sw>;
+				};
 			};
 		};
 	};
-- 
2.34.1



From festevam at gmail.com  Tue Dec 12 09:48:47 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 12 Dec 2023 14:48:47 -0300
Subject: [PATCH v2 3/3] arm64: dts: imx8mp-dhcom-pdk3: Describe the USB-C connector
In-Reply-To: <20231212174847.759164-1-festevam@gmail.com>
References: <20231212174847.759164-1-festevam@gmail.com>
Message-ID: <20231212174847.759164-3-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Describe the PTN5150 USB-C connector to improve the devicetree description
and fix the following dt-schema warning:

imx8mp-dhcom-pdk3.dtb: typec at 3d: 'port' does not match any of the regexes: 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/extcon/extcon-ptn5150.yaml#
	
Signed-off-by: Fabio Estevam <festevam at denx.de>
---
Changes since v1:
- None

 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts
index b749e28e5ede..fea67a9282f0 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts
@@ -175,10 +175,14 @@ typec at 3d {
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ptn5150>;
 
-				port {
-
-					ptn5150_out_ep: endpoint {
-						remote-endpoint = <&dwc3_0_ep>;
+				connector {
+					compatible = "usb-c-connector";
+					label = "USB-C";
+
+					port {
+						ptn5150_out_ep: endpoint {
+							remote-endpoint = <&dwc3_0_ep>;
+						};
 					};
 				};
 			};
-- 
2.34.1



From irogers at google.com  Tue Dec 12 09:52:55 2023
From: irogers at google.com (Ian Rogers)
Date: Tue, 12 Dec 2023 09:52:55 -0800
Subject: [PATCH v1 02/14] libperf cpumap: Rename and prefer sysfs for perf_cpu_map__default_new
In-Reply-To: <ZXiauao3bIbc0ZCo@kernel.org>
References: <20231129060211.1890454-1-irogers@google.com> <20231129060211.1890454-3-irogers@google.com>
 <ZXiauao3bIbc0ZCo@kernel.org>
Message-ID: <CAP-5=fVY8MOcJfJ77hqGSxD9GoZzVQ2EEgBFsLaZXHM5gHV3aQ@mail.gmail.com>

On Tue, Dec 12, 2023 at 9:39?AM Arnaldo Carvalho de Melo
<acme at kernel.org> wrote:
>
> Em Tue, Nov 28, 2023 at 10:01:59PM -0800, Ian Rogers escreveu:
> > Rename perf_cpu_map__default_new to perf_cpu_map__new_online_cpus to
> > better indicate what the implementation does. Read the online CPUs
> > from /sys/devices/system/cpu/online first before using sysconf as
> > sysconf can't accurately configure holes in the CPU map. If sysconf is
> > used, warn when the configured and online processors disagree.
> >
> > When reading from a file, if the read doesn't yield a CPU map then
> > return an empty map rather than the default online. This avoids
> > recursion but also better yields being able to detect failures.
> >
> > Add more comments.
> >
> > Signed-off-by: Ian Rogers <irogers at google.com>
> > ---
> >  tools/lib/perf/cpumap.c              | 59 +++++++++++++++++-----------
> >  tools/lib/perf/include/perf/cpumap.h | 15 ++++++-
> >  tools/lib/perf/libperf.map           |  2 +-
> >  tools/lib/perf/tests/test-cpumap.c   |  2 +-
> >  4 files changed, 51 insertions(+), 27 deletions(-)
> >
> > diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
> > index 2bd6aba3d8c9..463ca8b37d45 100644
> > --- a/tools/lib/perf/cpumap.c
> > +++ b/tools/lib/perf/cpumap.c
> > @@ -9,6 +9,7 @@
> >  #include <unistd.h>
> >  #include <ctype.h>
> >  #include <limits.h>
> > +#include "internal.h"
> >
> >  void perf_cpu_map__set_nr(struct perf_cpu_map *map, int nr_cpus)
> >  {
> > @@ -66,15 +67,21 @@ void perf_cpu_map__put(struct perf_cpu_map *map)
> >       }
> >  }
> >
> > -static struct perf_cpu_map *cpu_map__default_new(void)
> > +static struct perf_cpu_map *cpu_map__new_sysconf(void)
> >  {
> >       struct perf_cpu_map *cpus;
> > -     int nr_cpus;
> > +     int nr_cpus, nr_cpus_conf;
> >
> >       nr_cpus = sysconf(_SC_NPROCESSORS_ONLN);
> >       if (nr_cpus < 0)
> >               return NULL;
> >
> > +     nr_cpus_conf = sysconf(_SC_NPROCESSORS_CONF);
> > +     if (nr_cpus != nr_cpus_conf) {
> > +             pr_warning("Number of online CPUs (%d) differs from the number configured (%d) the CPU map will only cover the first %d CPUs.",
> > +                     nr_cpus, nr_cpus_conf, nr_cpus);
> > +     }
> > +
> >       cpus = perf_cpu_map__alloc(nr_cpus);
> >       if (cpus != NULL) {
> >               int i;
> > @@ -86,9 +93,27 @@ static struct perf_cpu_map *cpu_map__default_new(void)
> >       return cpus;
> >  }
> >
> > -struct perf_cpu_map *perf_cpu_map__default_new(void)
> > +static struct perf_cpu_map *cpu_map__new_syfs_online(void)
>
> I'm renaming this to cpu_map__new_sysfs_online(), ok?

Yep, typo. Thanks!

Ian

> - Arnaldo
>
> >  {
> > -     return cpu_map__default_new();
> > +     struct perf_cpu_map *cpus = NULL;
> > +     FILE *onlnf;
> > +
> > +     onlnf = fopen("/sys/devices/system/cpu/online", "r");
> > +     if (onlnf) {
> > +             cpus = perf_cpu_map__read(onlnf);
> > +             fclose(onlnf);
> > +     }
> > +     return cpus;
> > +}
> > +
> > +struct perf_cpu_map *perf_cpu_map__new_online_cpus(void)
> > +{
> > +     struct perf_cpu_map *cpus = cpu_map__new_syfs_online();
> > +
> > +     if (cpus)
> > +             return cpus;
> > +
> > +     return cpu_map__new_sysconf();
> >  }
> >
> >
> > @@ -180,27 +205,11 @@ struct perf_cpu_map *perf_cpu_map__read(FILE *file)
> >
> >       if (nr_cpus > 0)
> >               cpus = cpu_map__trim_new(nr_cpus, tmp_cpus);
> > -     else
> > -             cpus = cpu_map__default_new();
> >  out_free_tmp:
> >       free(tmp_cpus);
> >       return cpus;
> >  }
> >
> > -static struct perf_cpu_map *cpu_map__read_all_cpu_map(void)
> > -{
> > -     struct perf_cpu_map *cpus = NULL;
> > -     FILE *onlnf;
> > -
> > -     onlnf = fopen("/sys/devices/system/cpu/online", "r");
> > -     if (!onlnf)
> > -             return cpu_map__default_new();
> > -
> > -     cpus = perf_cpu_map__read(onlnf);
> > -     fclose(onlnf);
> > -     return cpus;
> > -}
> > -
> >  struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
> >  {
> >       struct perf_cpu_map *cpus = NULL;
> > @@ -211,7 +220,7 @@ struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
> >       int max_entries = 0;
> >
> >       if (!cpu_list)
> > -             return cpu_map__read_all_cpu_map();
> > +             return perf_cpu_map__new_online_cpus();
> >
> >       /*
> >        * must handle the case of empty cpumap to cover
> > @@ -268,9 +277,11 @@ struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list)
> >
> >       if (nr_cpus > 0)
> >               cpus = cpu_map__trim_new(nr_cpus, tmp_cpus);
> > -     else if (*cpu_list != '\0')
> > -             cpus = cpu_map__default_new();
> > -     else
> > +     else if (*cpu_list != '\0') {
> > +             pr_warning("Unexpected characters at end of cpu list ('%s'), using online CPUs.",
> > +                        cpu_list);
> > +             cpus = perf_cpu_map__new_online_cpus();
> > +     } else
> >               cpus = perf_cpu_map__new_any_cpu();
> >  invalid:
> >       free(tmp_cpus);
> > diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> > index d0bf218ada11..b24bd8b8f34e 100644
> > --- a/tools/lib/perf/include/perf/cpumap.h
> > +++ b/tools/lib/perf/include/perf/cpumap.h
> > @@ -22,7 +22,20 @@ struct perf_cpu_map;
> >   * perf_cpu_map__new_any_cpu - a map with a singular "any CPU"/dummy -1 value.
> >   */
> >  LIBPERF_API struct perf_cpu_map *perf_cpu_map__new_any_cpu(void);
> > -LIBPERF_API struct perf_cpu_map *perf_cpu_map__default_new(void);
> > +/**
> > + * perf_cpu_map__new_online_cpus - a map read from
> > + *                                 /sys/devices/system/cpu/online if
> > + *                                 available. If reading wasn't possible a map
> > + *                                 is created using the online processors
> > + *                                 assuming the first 'n' processors are all
> > + *                                 online.
> > + */
> > +LIBPERF_API struct perf_cpu_map *perf_cpu_map__new_online_cpus(void);
> > +/**
> > + * perf_cpu_map__new - create a map from the given cpu_list such as "0-7". If no
> > + *                     cpu_list argument is provided then
> > + *                     perf_cpu_map__new_online_cpus is returned.
> > + */
> >  LIBPERF_API struct perf_cpu_map *perf_cpu_map__new(const char *cpu_list);
> >  LIBPERF_API struct perf_cpu_map *perf_cpu_map__read(FILE *file);
> >  LIBPERF_API struct perf_cpu_map *perf_cpu_map__get(struct perf_cpu_map *map);
> > diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> > index a8ff64baea3e..8a71f841498e 100644
> > --- a/tools/lib/perf/libperf.map
> > +++ b/tools/lib/perf/libperf.map
> > @@ -2,7 +2,7 @@ LIBPERF_0.0.1 {
> >       global:
> >               libperf_init;
> >               perf_cpu_map__new_any_cpu;
> > -             perf_cpu_map__default_new;
> > +             perf_cpu_map__new_online_cpus;
> >               perf_cpu_map__get;
> >               perf_cpu_map__put;
> >               perf_cpu_map__new;
> > diff --git a/tools/lib/perf/tests/test-cpumap.c b/tools/lib/perf/tests/test-cpumap.c
> > index 2c359bdb951e..c998b1dae863 100644
> > --- a/tools/lib/perf/tests/test-cpumap.c
> > +++ b/tools/lib/perf/tests/test-cpumap.c
> > @@ -29,7 +29,7 @@ int test_cpumap(int argc, char **argv)
> >       perf_cpu_map__put(cpus);
> >       perf_cpu_map__put(cpus);
> >
> > -     cpus = perf_cpu_map__default_new();
> > +     cpus = perf_cpu_map__new_online_cpus();
> >       if (!cpus)
> >               return -1;
> >
> > --
> > 2.43.0.rc1.413.gea7ed67945-goog
> >
>
> --
>
> - Arnaldo


From ahalaney at redhat.com  Tue Dec 12 09:53:45 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Tue, 12 Dec 2023 11:53:45 -0600
Subject: [PATCH net-next v3] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <4e42erte4zvx77vgj77kcal2ss4nma3ggm3wa6wssleuubtzit@gbkbbudjfwhz>
References: <20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb@redhat.com>
 <jz6ot44fjkbmwcezi3fkgqd54nurglblbemrchfgxgq6udlhqz@ntepnnzzelta>
 <hxds75erxqcfkufxnfbyo2up4b4jeicmi3f5xr6qlb3yf7fe76@4byeq62jhu4o>
 <hgz3pt625kggix6kzincohw7kr2okcumrwfkmjgiauw2yvhrzt@ekeygo4b7k3b>
 <h5ucipgjtsesrz3jyul5xohu4pqom56v6ayx7aonnfesret3ht@wmblmndj6zir>
 <hpqssnt7odmuuyhsljuqovmwatdjz4s6kix6abq7lrvyciawy5@5ypscmmivnmh>
 <slq3uvpe424lxksgc2ho4q5apon6yqyvmq3ubpmx3z5ln5yhqf@klnkglqb6o6r>
 <4e42erte4zvx77vgj77kcal2ss4nma3ggm3wa6wssleuubtzit@gbkbbudjfwhz>
Message-ID: <726fd37c4ayubzzdyfh2cd3dkqdqzzkjcak4po7iudb73nnmp3@rq5j63ik2tvv>

On Tue, Dec 12, 2023 at 01:42:35PM +0300, Serge Semin wrote:
> On Mon, Dec 11, 2023 at 01:48:47PM -0600, Andrew Halaney wrote:
> > On Mon, Dec 11, 2023 at 08:27:46PM +0300, Serge Semin wrote:
> > > On Fri, Dec 08, 2023 at 10:50:29AM -0600, Andrew Halaney wrote:
> > > > On Fri, Dec 08, 2023 at 06:07:06PM +0300, Serge Semin wrote:
> > > > > On Thu, Dec 07, 2023 at 05:07:24PM -0600, Andrew Halaney wrote:
> > > > > > On Fri, Dec 08, 2023 at 01:16:12AM +0300, Serge Semin wrote:
> > > > > > > On Thu, Dec 07, 2023 at 03:12:40PM -0600, Andrew Halaney wrote:
> > > > > > > > The stmmac_dt_phy() function, which parses the devicetree node of the
> > > > > > > > MAC and ultimately causes MDIO bus allocation, misinterprets what
> > > > > > > > fixed-link means in relation to the MAC's MDIO bus. This results in
> > > > > > > > a MDIO bus being created in situations it need not be.
> > > > > > > > 
> > > > > > > > Currently a MDIO bus is created if the description is either:
> > > > > > > > 
> > > > > > > >     1. Not fixed-link
> > > > > > > >     2. fixed-link but contains a MDIO bus as well
> > > > > > > > 
> > > > > > > > The "1" case above isn't always accurate. If there's a phy-handle,
> > > > > > > > it could be referencing a phy on another MDIO controller's bus[1]. In
> > > > > > > > this case currently the MAC will make a MDIO bus and scan it all
> > > > > > > > anyways unnecessarily.
> > > > > > > > 
> > > > > > > > There's also a lot of upstream devicetrees[2] that expect a MDIO bus to
> > > > > > > > be created and scanned for a phy. This case can also be inferred from
> > > > > > > > the platform description by not having a phy-handle && not being
> > > > > > > > fixed-link. This hits case "1" in the current driver's logic.
> > > > > > > > 
> > > > > > > > Let's improve the logic to create a MDIO bus if either:
> > > > > > > > 
> > > > > > > 
> > > > > > > >     - Devicetree contains a MDIO bus
> > > > > > > >     - !fixed-link && !phy-handle (legacy handling)
> > > > > > > 
> > > > > > > If what you suggest here is a free from regressions semantics change
> > > > > > > (really hope it is) I will be with both my hands for it. This will
> > > > > > > solve the problem we have with one of our device which doesn't have
> > > > > > > SMA interface (hardware designers decided to save ~4K gates of the
> > > > > > > chip area) but has a PHY externally attached to the DW XGMAC<->XPCS
> > > > > > > interface. PHY is accessible via a GPIO-based MDIO bus. BTW having no
> > > > > > > SMA interface available on a DW *MAC device but creating the MDIO-bus
> > > > > > > on top of the non-existent SMA CSRs anyway causes having _32_ dummy
> > > > > > > PHYs created with zero IDs.
> > > > > > 
> > > > > 
> > > > > > I hope it is regression free! I have tested both the [1] and [2] cases
> > > > > > (I hacked up the devicetree for [1] to make it look like [2]) without
> > > > > > any issue.
> > > > > > 
> > > > > 
> > > > > I doubt you could have tested it on all the possible hardware the
> > > > > STMMAC driver supports. The problem is that the DT-bindings thing is a
> > > > > kind of contract which can't be changed that easily. It's like ABI but
> > > > > for the hardware description so the kernel would bootup correctly on
> > > > > the platforms with the old DT blobs. But if the change isn't that
> > > > > critical, if the device-tree sources in the kernel fit to the updated
> > > > > semantics, if the networking subsystem maintainers aren't against it
> > > > > and I guess with the Rob, Krzysztof or Conor blessing (at least it
> > > > > won't hurt to add them to the Cc-list together with the devicetree
> > > > > mailing-list), then it will likely be accepted.
> > > > 
> > > 
> > > > To be clear, I don't think we're violating the dt-binding ABI contract
> > > > here. My intention is that all the existing use cases continue to work,
> > > > and this just improves one use case. I did a write up
> > > > over on v2 about the use cases I see and the current logic vs what
> > > > changes with this patch series:
> > > > 
> > > >     https://lore.kernel.org/netdev/plvbqgi2bwlv5quvpiwplq7cxx6m5rl3ghnfhuxfx4bpuhyihl at zmydwrtwdeg6/
> > > > 
> > > > Please comment if you think I have broken some backwards
> > > > compatibility.
> > > 
> > > To shortly sum up so I didn't miss something. Current semantics of the
> > > MDIO-bus registration is:
> > > if !fixed-link || mdio_node_present
> > >     create MDIO-bus
> > > and the semantics of the PHY auto-probe (legacy) is:
> > > if !(fixed-link || mdio_node_present || phy_node_present)
> > >     auto-probe PHY
> > 
> 
> > I think phy_node_present doesn't belong in the current view of the
> > semantics for PHY auto-probe (legacy). This devicetree would trigger a
> > PHY auto-probe/scan on ethernet0's MAC's MDIO bus:
> > 
> > 	random-mdio-bus {
> > 		rgmii_phy: phy at 0 {
> > 		};
> > 	};
> > 
> > 	ethernet0 {
> > 		phy-handle = <&rgmii_phy>;
> > 	};
> 
> Em, unless I miss something, but on STMMAC it wont due to the next
> statement: stmmac_mdio_register():
> 	if (priv->plat->phy_node || mdio_node)
> 		goto bus_register_done;
> 
> Note by the "PHY auto-probe (legacy)" semantics I meant the algo
> implemented at the bottom of the stmmac_mdio_register() method. If no
> PHY-node or MDIO-node specified it tries to find any PHY on the
> DW MAC SMA MDIO bus and use it in the driver.
> 
> If what you meant was the PHY auto-probe/scan executed in the
> __mdiobus_register() method, then I guess it's relevant only _if_ the
> stmmac_mdio_register() method performs the legacy auto-probing too.
> Yes, the MDIO/PHY subsystem _will_ scan the MDIO-bus for PHYs, but
> they won't be utilized in the STMMAC driver due to the conditional
> statement above. In other words I guess the scanning performed in
> __mdiobus_register() will be pointless anyway in that case, since no
> detected PHY-devices will be actually used afterwards.
> 

Yes, I was referring to the __mdiobus_register() bit, and I now see what
you mean. So in the example I painted above the stmmac_mdio_register()
auto-probing would not happen since the phy-handle exists (and therefore
phy_node).

So the only change here is that the __mdiobus_register() scan wouldn't
happen, but since stmmac is the only MAC that would attach to a phy on
that bus it doesn't matter (the phy is already acquired by the
phy-handle).

> > 
> > The assumption I make in this patch is that nothing useful could be on
> > ethernet0's MDIO bus, it certainly at least is not the phy the MAC uses.
> > 
> > > 
> > > You are changing the MDIO-bus creation semantics to:
> > > if !(fixed-link || phy_node_present) || mdio_node_present
> > >     create MDIO-bus
> > > with no change in the PHY auto-probe semantics:
> > > if !(fixed-link || mdio_node_present || phy_node_present)
> > >     auto-probe PHY
> > 
> > Unfortunately as I highlighted above this logic (while accurate to the
> > patch under review) is a change from the prior logic for the "auto-probe
> > PHY" case.
> > 
> > > 
> > > So the change is that if a PHY-handle is specified the MDIO-bus won't
> > > be created with the rest conditions being the same.
> > > 
> > > The only concern I had was the so called legacy case and a possibility
> > > to have MDIO-bus with other than PHY devices. Based on the pseudo-code
> > > above the former case won't be affected since having PHY-node
> > > specified didn't triggered MDIO-bus auto-probe even before your
> > > change. The later case concerns for instance the DW XPCS devices which
> > 
> > As I've realized in your response here, there is the possibility that
> > something is on the MDIO bus in the ethernet0 exmpale bus above, and would
> > probe, in the before handling. So I guess this isn't totally backwards
> > compatible. Gah, thanks for highlighting.
> 
> AFAICS what you suggest won't break currently supported by the STMMAC
> driver _platforms_. This is what actually matters. The legacy PHY
> auto-probing will work as before. None of the OF-based platforms
> currently expect having non-PHY devices on the bus.

I agree, you've talked me off the edge of the cliff. Thanks so much for
your help in all this.

> 
> > 
> > I'm not sure in practice if anyone out there is really relying on that
> > or not. I can get away with the "no auto-probe/scan of bus" optimization I
> > really desire by describing my MDIO bus as disabled in the devicetree
> > (need to send patches to do that in the dts and handle it gracefully in
> > stmmac). I'm wondering if I should keep forth with this patch as is, or
> > if I should keep the same logic but clean it up a bit as is done in the
> > current patch... I guess probably the latter.
> 
> It's better to limit some complicated logic before somebody tries to
> use it to bypass a harder but correct way of directly defining all
> devices (including non-PHY ones) in dts. Seeing presumably no
> currently supported platform will be broken I think you should keep
> the patch as is.

Agreed. I'll send a new version this evening with your tags, Andrew
Lunn's requested motivation in commit message, etc. Thanks!

> 
> -Serge(y)
> 
> > 
> > > on some platforms could be found on the DW MAC MDIO bus with not
> > > having PHY living on that bus. But DW XPCS auto-probing currently is
> > > only supported by the non-OF platforms (it's Intel). Thus your change
> > > is supposed to be safe here too.
> > > 
> > > So to speak AFAICS from the STMMAC MDIO OF stuff your solution isn't
> > > supposed to cause regressions and break the current DTs backward
> > > compatibility indeed.
> > > 
> > > Regarding the ideal implementation. What could be much better is to
> > > implement the next semantics:
> > > if SMA-capability-detected &&
> > >    (!mdio_node_present || (mdio_node_present && mdio_node_enabled))
> > >     create MDIO-bus
> > > and preserve the PHY auto-probe semantics for backwards compatibility.
> > > Regarding the SMA-capability flag, it has been presented since DW GMAC
> > > v3.50, so since very much early DW MAC releases. But even for the
> > > early devices I think it could be auto-detected by checking the SMA
> > > CSRs writability. At least DW XGMAC AFAICS has the command CSR not
> > > writable if SMA is unavailable.
> > > 
> > > But I guess it's a matter of another patch.
> > > 
> > 
> > I like that logic for what it is worth, although would be unsure of
> > verifying the SMA-capability-detected part of it. But I wouldn't mind
> > seeing that patch :)
> > 
> 



From acme at kernel.org  Tue Dec 12 09:59:37 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Tue, 12 Dec 2023 14:59:37 -0300
Subject: [PATCH v1 00/14] Clean up libperf cpumap's empty function
In-Reply-To: <20231129060211.1890454-1-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
Message-ID: <ZXifiVytVbebYE3U@kernel.org>

Em Tue, Nov 28, 2023 at 10:01:57PM -0800, Ian Rogers escreveu:
> Rename and clean up the use of libperf CPU map functions particularly
> focussing on perf_cpu_map__empty that may return true for maps
> containing CPUs but also with an "any CPU"/dummy value.
> 
> perf_cpu_map__nr is also troubling in that iterating an empty CPU map
> will yield the "any CPU"/dummy value. Reduce the appearance of some
> calls to this by using the perf_cpu_map__for_each_cpu macro.
> 
> Ian Rogers (14):
>   libperf cpumap: Rename perf_cpu_map__dummy_new
>   libperf cpumap: Rename and prefer sysfs for perf_cpu_map__default_new
>   libperf cpumap: Rename perf_cpu_map__empty
>   libperf cpumap: Replace usage of perf_cpu_map__new(NULL)
>   libperf cpumap: Add for_each_cpu that skips the "any CPU" case

Applied 1-6, with James Reviewed-by tags, would be good to have Adrian
check the PT and BTS parts, testing the end result if he things its all
ok.

- Arnaldo


From linux at roeck-us.net  Tue Dec 12 10:00:39 2023
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 12 Dec 2023 10:00:39 -0800
Subject: [PATCH v1 7/8] tpm: tis-i2c: Add more compatible strings
In-Reply-To: <20231212-avid-grill-dbead068fac8@spud>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-8-ninad@linux.ibm.com>
 <20231212-avid-grill-dbead068fac8@spud>
Message-ID: <73381bb0-7fa7-4a9e-88df-ab0063058e26@roeck-us.net>

On Tue, Dec 12, 2023 at 05:15:51PM +0000, Conor Dooley wrote:
> On Tue, Dec 12, 2023 at 10:40:03AM -0600, Ninad Palsule wrote:
> > From: Joel Stanley <joel at jms.id.au>
> > 
> > The NPCT75x TPM is TIS compatible. It has an I2C and SPI interface.
> > 
> > https://www.nuvoton.com/products/cloud-computing/security/trusted-platform-module-tpm/
> > 
> > Add a compatible string for it, and the generic compatible.
> > 
> > OpenBMC-Staging-Count: 3
> 
> Delete this from every patch that it appears from.
> 
> > Signed-off-by: Joel Stanley <joel at jms.id.au>
> > Acked-by: Jarkko Sakkinen <jarkko at kernel.org>
> > Link: https://lore.kernel.org/r/20220928043957.2636877-4-joel at jms.id.au
> > Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> > ---
> >  drivers/char/tpm/tpm_tis_i2c.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/char/tpm/tpm_tis_i2c.c b/drivers/char/tpm/tpm_tis_i2c.c
> > index a897402cc36a..9511c0d50185 100644
> > --- a/drivers/char/tpm/tpm_tis_i2c.c
> > +++ b/drivers/char/tpm/tpm_tis_i2c.c
> > @@ -383,6 +383,8 @@ MODULE_DEVICE_TABLE(i2c, tpm_tis_i2c_id);
> >  #ifdef CONFIG_OF
> >  static const struct of_device_id of_tis_i2c_match[] = {
> >  	{ .compatible = "infineon,slb9673", },
> > +	{ .compatible = "nuvoton,npct75x", },
> > +	{ .compatible = "tcg,tpm-tis-i2c", },
> 
> What's the point of the generic compatible if you are adding the device
> specific ones to the driver anyway?
> 

$ git grep infineon,slb9673
Documentation/devicetree/bindings/trivial-devices.yaml:          - infineon,slb9673
drivers/char/tpm/tpm_tis_i2c.c: { .compatible = "infineon,slb9673", },
$ git grep nuvoton,npct75x
arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
$ git grep tcg,tpm-tis-i2c
arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
arch/arm/boot/dts/aspeed/aspeed-bmc-opp-tacoma.dts:             compatible = "tcg,tpm-tis-i2c";

It looks like at least the generic entry is needed, given that it is quite
likely that there is hardware out there using it. Other than that, this
makes me wonder: Is there some official guideline describing if and when
to use (only) generic devicetree compatible entries and when specific ones
may / should / have to be used ? I suspect the answer to your question might
simply be "because we did not know better", and it might be helpful to be
able to say "please see XXX for details".

Thanks,
Guenter


From jgg at nvidia.com  Tue Dec 12 10:04:26 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 12 Dec 2023 14:04:26 -0400
Subject: [PATCH v3 04/19] iommu/arm-smmu-v3: Make STE programming
 independent of the callers
In-Reply-To: <20231212162353.GA29871@willie-the-truck>
References: <0-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v3-d794f8d934da+411a-smmuv3_newapi_p1_jgg@nvidia.com>
 <20231212162353.GA29871@willie-the-truck>
Message-ID: <20231212180426.GN3014157@nvidia.com>

On Tue, Dec 12, 2023 at 04:23:53PM +0000, Will Deacon wrote:
> > At this point it generates the same sequence of updates as the current
> > code, except that zeroing the VMID on entry to BYPASS/ABORT will do an
> > extra sync (this seems to be an existing bug).
> 
> This is certainly very clever, but at the same time I can't help but feel
> that it's slightly over-engineered to solve the general case, whereas I'm
> struggling to see why such a level of complexity is necessary.

I'm open to any alternative that accomplishes the same outcome of
decoupling the STE programming from the STE state and adding the API
required hitless transitions.

This is a really important part of all of this work.

IMHO this is inherently complex. The SMMU spec devotes several pages
to describing how to do tearless updates. However, that text does not
even consider the need for hitless updates. It only contemplates the
V=0 flow.

Here we are very much adding hitless and intending to do so.

> In the comment, you say:
> 
> > + * In the most general case we can make any update in three steps:
> > + *  - Disrupting the entry (V=0)
> > + *  - Fill now unused bits, all bits except V
> > + *  - Make valid (V=1), single 64 bit store
> > + *
> > + * However this disrupts the HW while it is happening. There are several
> > + * interesting cases where a STE/CD can be updated without disturbing the HW
> > + * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
> > + * because the used bits don't intersect. We can detect this by calculating how
> > + * many 64 bit values need update after adjusting the unused bits and skip the
> > + * V=0 process.
> 
> Please can you spell out these "interesting cases"? For cases where we're
> changing CONFIG, I'd have thought it would be perfectly fine to go via an
> invalid STE. What am I missing?

The modern IOMMU driver API requires hitless transitions in a bunch of
cases. I think I explained it in an email to Michael:

https://lore.kernel.org/linux-iommu/20231012121616.GF3952 at nvidia.com/

 - IDENTIY -> DMA -> IDENTITY hitless with RESV_DIRECT
 - STE -> S1DSS -> STE hitless (PASID upgrade)
 - S1 -> BLOCKING -> S1 with active PASID hitless (iommufd case)
 - NESTING -> NESTING (eg to change S1DSS, change CD table pointers, etc)
 - CD ASID change hitless (BTM S1 replacement)
 - CD quiet_cd hitless (SVA mm release)

I will add that list to the commit message, the cover letter talks
about it a bit too.

To properly implement the API the driver has to support this.
Rather than try to just target those few cases (and hope I even know
all the needed cases) I just did everything.

"Everything" was a reaction to the complexity, at the end of part 3 we
have 7 different categories of STEs:
 - IDENTITY
 - BLOCKING
 - S2 domain
 - IDENTITY w/ PASID
 - BLOCKING w/ PASID
 - S1 domain
 - S1 domain nested on S2 domain

(plus a bunch of those have ATS and !ATS variations, and the nesting
has its own sub types..)

Which is 42 different permutations of transitions (plus the CD
stuff). Even if we want to just special case the sequences above we
still have to identify them and open code the arcs. Then the next
person along has to understand why those specific arcs are special
which is a complex and subtle argument based on the spec saying the HW
does not read certain bits.

Finally, there is a VM emulation reason - we don't know what the VM
will do so it may be assuming hitless changes. To actually correctly
emulate this we do need this general approach. Otherwise we have a
weird emulation gap where STE sequences generated by a VM that should
be hitless on real HW (eg the ones above, perhaps) will not
work. Indeed a VM running kernels with all three parts of this will be
doing and expecting hitless STE updates!

While this is perhaps not a real world functional concern it falls
under the usual rubrik of accurate VM emulation.

So, to my mind ignoring the general case and just doing V=0 all the
time is not OK.

> Generally, I like where the later patches in the series take things, but
> I'd really like to reduce the complexity of the strtab updating code to
> what is absolutely required.

This is the sort of thing where the algorithm in
arm_smmu_write_entry_step() is perhaps complex, but the ongoing
support of it is not. Just update the used bits function when new STE
features are (rarely) introduced.

> I've left some minor comments on the code below, but I'd really like to
> see this whole thing simplified if possible.

I have no particularly goood ideas on this front, sorry. I did try
several other things. Many thoughts were so difficult I couldn't even
write them down correctly :(

> > + */
> > +static bool arm_smmu_write_entry_step(__le64 *cur, const __le64 *cur_used,
> > +				      const __le64 *target,
> > +				      const __le64 *target_used, __le64 *step,
> > +				      __le64 v_bit,
> > +				      unsigned int len)
> > +{
> > +	u8 step_used_diff = 0;
> > +	u8 step_change = 0;
> > +	unsigned int i;
> > +
> > +	/*
> > +	 * Compute a step that has all the bits currently unused by HW set to
> > +	 * their target values.
> > +	 */
> 
> Well, ok, I do have a cosmetic nit here: using 'step' for both "STE pointer"
> and "incremental change" is perhaps, err, a step too far ;)

Ok.. I'll call it arm_smmu_write_entry_next()

> > +	for (i = 0; i != len; i++) {
> > +		step[i] = (cur[i] & cur_used[i]) | (target[i] & ~cur_used[i]);
> 
> Isn't 'cur[i] & cur_used[i]' always cur[i]?

No. The routine is called iteratively as the comment explained. The
first iteration may set unused bits to their target values, so we have
to mask them away again here during the second iteration. Later
iterations may change, eg the config, which means again we will have
unused values set from the prior config.

> > +	} else if (!step_change) {
> > +		/* cur == target, so all done */
> > +		if (memcmp(cur, target, len * sizeof(*cur)) == 0)
> > +			return true;
> > +
> > +		/*
> > +		 * All the used HW bits match, but unused bits are different.
> > +		 * Set them as well. Technically this isn't necessary but it
> > +		 * brings the entry to the full target state, so if there are
> > +		 * bugs in the mask calculation this will obscure them.
> > +		 */
> > +		memcpy(step, target, len * sizeof(*step));
> 
> Bah, I'm not a huge fan of this sort of defensive programming. I'd prefer
> to propagate the error rather than quietly try to cover it up.

There is no error.

This is adjusting the unused bits that were left over from the prior
config to 0, it is a similar answer to the 'cur[i]' question above.

The defensiveness is only a decision that the installed STE should
fully match the given target STE.

In principle the HW doesn't read unused bits in the target STE so we
could leave them set to 1 instead of fully matching.

"bugs in the mask calculation" means everything from the "HW should
not look at bit X but does" to "the spec was misread and the HW does
look at bit X"

> > +/*
> > + * Based on the value of ent report which bits of the STE the HW will access. It
> > + * would be nice if this was complete according to the spec, but minimally it
> > + * has to capture the bits this driver uses.
> > + */
> > +static void arm_smmu_get_ste_used(const struct arm_smmu_ste *ent,
> > +				  struct arm_smmu_ste *used_bits)
> > +{
> > +	memset(used_bits, 0, sizeof(*used_bits));
> > +
> > +	used_bits->data[0] = cpu_to_le64(STRTAB_STE_0_V);
> > +	if (!(ent->data[0] & cpu_to_le64(STRTAB_STE_0_V)))
> > +		return;
> > +
> > +	/*
> > +	 * If S1 is enabled S1DSS is valid, see 13.5 Summary of
> > +	 * attribute/permission configuration fields for the SHCFG behavior.
> > +	 */
> > +	if (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(ent->data[0])) & 1 &&
> > +	    FIELD_GET(STRTAB_STE_1_S1DSS, le64_to_cpu(ent->data[1])) ==
> > +		    STRTAB_STE_1_S1DSS_BYPASS)
> > +		used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_SHCFG);
> > +
> > +	used_bits->data[0] |= cpu_to_le64(STRTAB_STE_0_CFG);
> > +	switch (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(ent->data[0]))) {
> > +	case STRTAB_STE_0_CFG_ABORT:
> > +		break;
> > +	case STRTAB_STE_0_CFG_BYPASS:
> > +		used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_SHCFG);
> > +		break;
> > +	case STRTAB_STE_0_CFG_S1_TRANS:
> > +		used_bits->data[0] |= cpu_to_le64(STRTAB_STE_0_S1FMT |
> > +						  STRTAB_STE_0_S1CTXPTR_MASK |
> > +						  STRTAB_STE_0_S1CDMAX);
> > +		used_bits->data[1] |=
> > +			cpu_to_le64(STRTAB_STE_1_S1DSS | STRTAB_STE_1_S1CIR |
> > +				    STRTAB_STE_1_S1COR | STRTAB_STE_1_S1CSH |
> > +				    STRTAB_STE_1_S1STALLD | STRTAB_STE_1_STRW);
> > +		used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_EATS);
> > +		break;
> > +	case STRTAB_STE_0_CFG_S2_TRANS:
> > +		used_bits->data[1] |=
> > +			cpu_to_le64(STRTAB_STE_1_EATS | STRTAB_STE_1_SHCFG);
> > +		used_bits->data[2] |=
> > +			cpu_to_le64(STRTAB_STE_2_S2VMID | STRTAB_STE_2_VTCR |
> > +				    STRTAB_STE_2_S2AA64 | STRTAB_STE_2_S2ENDI |
> > +				    STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2R);
> > +		used_bits->data[3] |= cpu_to_le64(STRTAB_STE_3_S2TTB_MASK);
> > +		break;
> 
> I think this is going to be a pain to maintain :/

Ah, but not your pain :)

Some day someone adds a new STE bit, they don't understand this so
they just change one of the make functions.

They test and hit the WARN_ON, which brings them here. Then they
hopefully realize they need to read the spec and understand the new
bit so they do that and make a try at the right conditions.

Reviewer sees the new hunk in this function and double-checks that the
conditions for the new bit are correct. Reviewer needs to consider if
any hitless flows become broken (and I've considered adding an
explicit self test for this)

The hard work of reviewing the spec and deciding how a new STE bit is
processed cannot be skipped, but we can make it harder to notice that
it has been skipped. I think the current design makes skipping this
work too easy.

So you are calling it a "pain to maintain" I'm calling it an "enforced
rigor" going forward. Like type safety.

> > +static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
> > +			       struct arm_smmu_ste *ste,
> > +			       const struct arm_smmu_ste *target)
> > +{
> > +	struct arm_smmu_ste target_used;
> > +	int i;
> > +
> > +	arm_smmu_get_ste_used(target, &target_used);
> > +	/* Masks in arm_smmu_get_ste_used() are up to date */
> > +	for (i = 0; i != ARRAY_SIZE(target->data); i++)
> > +		WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);
> 
> That's a runtime cost on every single STE update for what would be a driver
> bug.

See above. STE programming is not critical path, and I think this
series makes it faster overall anyhow.

> > +	while (true) {
> > +		if (arm_smmu_write_ste_step(ste, target, &target_used))
> > +			break;
> > +		arm_smmu_sync_ste_for_sid(smmu, sid);
> > +	}
> 
> This really should be bounded...

Sure, I think the bound is 4 but I will check.

Thanks,
Jason


From u.kleine-koenig at pengutronix.de  Tue Dec 12 10:09:43 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 19:09:43 +0100
Subject: [PATCH 2/2] pwm: xilinx: Simplify using devm functions
In-Reply-To: <cover.1702403904.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702403904.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e51f9d16f7a0f29ce5c2385e11a14b1ebdac7530.1702403904.git.u.kleine-koenig@pengutronix.de>

devm_clk_get() + clk_prepare_enable() can be simplified to
devm_clk_get_enabled(). Both clk_rate_exclusive_get() and pwmchip_add()
have devm variants.

This allows to completely drop the remove callback and the error path in
the probe function.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-xilinx.c | 25 ++++++-------------------
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/pwm/pwm-xilinx.c b/drivers/pwm/pwm-xilinx.c
index 5f3c2a6fed11..19a2a496d555 100644
--- a/drivers/pwm/pwm-xilinx.c
+++ b/drivers/pwm/pwm-xilinx.c
@@ -268,38 +268,26 @@ static int xilinx_pwm_probe(struct platform_device *pdev)
 	 * alas, such properties are not allowed to be used.
 	 */
 
-	priv->clk = devm_clk_get(dev, "s_axi_aclk");
+	priv->clk = devm_clk_get_enabled(dev, "s_axi_aclk");
 	if (IS_ERR(priv->clk))
 		return dev_err_probe(dev, PTR_ERR(priv->clk),
 				     "Could not get clock\n");
 
-	ret = clk_prepare_enable(priv->clk);
+	ret = devm_clk_rate_exclusive_get(dev, priv->clk);
 	if (ret)
-		return dev_err_probe(dev, ret, "Clock enable failed\n");
-	clk_rate_exclusive_get(priv->clk);
+		return dev_err_probe(dev, ret,
+				     "Could not get exclusive control over clock\n");
 
 	xilinx_pwm->chip.dev = dev;
 	xilinx_pwm->chip.ops = &xilinx_pwm_ops;
 	xilinx_pwm->chip.npwm = 1;
-	ret = pwmchip_add(&xilinx_pwm->chip);
-	if (ret) {
-		clk_rate_exclusive_put(priv->clk);
-		clk_disable_unprepare(priv->clk);
+	ret = devm_pwmchip_add(dev, &xilinx_pwm->chip);
+	if (ret)
 		return dev_err_probe(dev, ret, "Could not register PWM chip\n");
-	}
 
 	return 0;
 }
 
-static void xilinx_pwm_remove(struct platform_device *pdev)
-{
-	struct xilinx_pwm_device *xilinx_pwm = platform_get_drvdata(pdev);
-
-	pwmchip_remove(&xilinx_pwm->chip);
-	clk_rate_exclusive_put(xilinx_pwm->priv.clk);
-	clk_disable_unprepare(xilinx_pwm->priv.clk);
-}
-
 static const struct of_device_id xilinx_pwm_of_match[] = {
 	{ .compatible = "xlnx,xps-timer-1.00.a", },
 	{},
@@ -308,7 +296,6 @@ MODULE_DEVICE_TABLE(of, xilinx_pwm_of_match);
 
 static struct platform_driver xilinx_pwm_driver = {
 	.probe = xilinx_pwm_probe,
-	.remove_new = xilinx_pwm_remove,
 	.driver = {
 		.name = "xilinx-pwm",
 		.of_match_table = of_match_ptr(xilinx_pwm_of_match),
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Tue Dec 12 10:09:42 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 19:09:42 +0100
Subject: [PATCH 1/2] clk: Add a devm variant of clk_rate_exclusive_get()
In-Reply-To: <cover.1702403904.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702403904.git.u.kleine-koenig@pengutronix.de>
Message-ID: <744a6371f94fe96f527eea6e52a600914e6fb6b5.1702403904.git.u.kleine-koenig@pengutronix.de>

This allows to simplify drivers that use clk_rate_exclusive_get()
in their probe routine as calling clk_rate_exclusive_put() is cared for
automatically.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/clk/clk.c   | 15 +++++++++++++++
 include/linux/clk.h | 12 ++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index af2011c2a93b..78249ca2341c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -937,6 +937,21 @@ void clk_rate_exclusive_get(struct clk *clk)
 }
 EXPORT_SYMBOL_GPL(clk_rate_exclusive_get);
 
+static void devm_clk_rate_exclusive_put(void *data)
+{
+	struct clk *clk = data;
+
+	clk_rate_exclusive_put(clk);
+}
+
+int devm_clk_rate_exclusive_get(struct device *dev, struct clk *clk)
+{
+	clk_rate_exclusive_get(clk);
+
+	return devm_add_action_or_reset(dev, devm_clk_rate_exclusive_put, clk);
+}
+EXPORT_SYMBOL_GPL(devm_clk_rate_exclusive_get);
+
 static void clk_core_unprepare(struct clk_core *core)
 {
 	lockdep_assert_held(&prepare_lock);
diff --git a/include/linux/clk.h b/include/linux/clk.h
index f88c407925f8..5a749459c3a3 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -199,6 +199,18 @@ bool clk_is_match(const struct clk *p, const struct clk *q);
  */
 void clk_rate_exclusive_get(struct clk *clk);
 
+/**
+ * devm_clk_rate_exclusive_get - devm variant of clk_rate_exclusive_get
+ * @dev: device the exclusivity is bound to
+ * @clk: clock source
+ *
+ * Calls clk_rate_exclusive_get() on @clk and registers a devm cleanup handler
+ * on @dev to cal clk_rate_exclusive_put().
+ *
+ * Must not be called from within atomic context.
+ */
+int devm_clk_rate_exclusive_get(struct device *dev, struct clk *clk);
+
 /**
  * clk_rate_exclusive_put - release exclusivity over the rate control of a
  *                          producer
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Tue Dec 12 10:09:41 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 19:09:41 +0100
Subject: [PATCH 0/2] clk: Add a devm variant of clk_rate_exclusive_get()
Message-ID: <cover.1702403904.git.u.kleine-koenig@pengutronix.de>

Hello,

patch #1 adds a new function devm_clk_rate_exclusive_get() that
simplifies usage of clk_rate_exclusive_get() in probe functions.

One downside is that a caller of clk_rate_exclusive_get() doesn't need
to check the return value, devm_clk_rate_exclusive_get() can fail
however. So to benefit from the new function you usually need to add a
check for devm_clk_rate_exclusive_get() failing in return to simplifying
error paths in .probe() and .remove().

Patch #2 shows an example conversion. Note that without
devm_clk_rate_exclusive_get() the pwm-xilinx driver cannot benefit from
devm_pwmchip_add().

This series bases on
https://lore.kernel.org/linux-clk/cover.1702400947.git.u.kleine-koenig at pengutronix.de/T/#t
. That's not a "hard" dependency, it can easily be rebased to next.
There is only a trivial context conflict in include/linux/clk.h.

Regarding how to merge this: I suggest to take patch #1 via clk. When
this is merged I will take care for the pwm-xilinx driver (and others
that might benefit).

Best regards
Uwe

Uwe Kleine-K?nig (2):
  clk: Add a devm variant of clk_rate_exclusive_get()
  pwm: xilinx: Simplify using devm functions

 drivers/clk/clk.c        | 15 +++++++++++++++
 drivers/pwm/pwm-xilinx.c | 25 ++++++-------------------
 include/linux/clk.h      | 12 ++++++++++++
 3 files changed, 33 insertions(+), 19 deletions(-)


base-commit: bbd220ce4e29ed55ab079007cff0b550895258eb
prerequisite-patch-id: 5a986d744a054000998ce06e3dbaaedede71c8ac
prerequisite-patch-id: cdb26f72d1fbd7fef4a9ef4476e0218dd3fcba22
prerequisite-patch-id: 838e3cb639cf13c7b571d77c1dea3d4ec479465d
prerequisite-patch-id: d5059c23f752a4861e5bbfe70b8ab771727bf68d
prerequisite-patch-id: c7ca9e00334dabe41f39e006ceb2b7d1afddcaa5
-- 
2.42.0



From bigunclemax at gmail.com  Tue Dec 12 10:09:45 2023
From: bigunclemax at gmail.com (Maxim Kiselev)
Date: Tue, 12 Dec 2023 21:09:45 +0300
Subject: [PATCH v3 5/6] thermal: sun8i: add support for H616 THS controller
In-Reply-To: <20231211000528.57cb646c@minigeek.lan>
References: <20231128005849.19044-6-andre.przywara@arm.com>
 <a14fb458-caf0-4a4a-b76b-c2503b0840d2@gmail.com> <20231211000528.57cb646c@minigeek.lan>
Message-ID: <CALHCpMjz4YiE_=6Cxq7RqF_3qPaw8UCA=6eLy9ZZuofRhr7mcA@mail.gmail.com>

??, 11 ???. 2023??. ? 02:48, Andre Przywara <andre.przywara at arm.com>:
>
> On Sat, 9 Dec 2023 13:44:34 +0300
> Maksim Kiselev <bigunclemax at gmail.com> wrote:
>
> Hi Maksim,
>
> > Hi Martin, Andre.
> >
> > May I inquire? Why do we need a separate sun50i_h616_ths_calibrate()
> > function? Why can't we just extend an existing sun50i_h6_ths_calibrate()?
> >
> > At my glance the calculations in both functions are the same. We just
> > need to handle a special case for the 4th sensor.
>
> You seem to be right, they are indeed the same, just written slightly
> differently. Do you already have any patches that unify that?

No, I don't have any patches for that yet. But I can do it if you told
me where to
send the patch. Should I put it here as a reply?

> I don't know if Martin or I find time to do it this week, but we could
> also optimise this later.
>
> Cheers,
> Andre

Best regards,
Maksim


From jgg at nvidia.com  Tue Dec 12 10:11:56 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Tue, 12 Dec 2023 14:11:56 -0400
Subject: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for
 vfio pci devices
In-Reply-To: <ZXicemDzXm8NShs1@arm.com>
References: <20231208164709.23101-1-ankita@nvidia.com>
 <20231208164709.23101-3-ankita@nvidia.com>
 <ZXicemDzXm8NShs1@arm.com>
Message-ID: <20231212181156.GO3014157@nvidia.com>

On Tue, Dec 12, 2023 at 05:46:34PM +0000, Catalin Marinas wrote:
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index a422cc123a2d..8d3c4820c492 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -391,6 +391,13 @@ extern unsigned int kobjsize(const void *objp);
> >  # define VM_UFFD_MINOR		VM_NONE
> >  #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
> >  
> > +#ifdef CONFIG_64BIT
> > +#define VM_VFIO_ALLOW_WC_BIT	39	/* Convey KVM to map S2 NORMAL_NC */
> 
> This comment shouldn't be in the core header file. It knows nothing
> about S2 and Normal-NC, that's arm64 terminology. You can mention
> something like VFIO can use this flag hint that write-combining is
> allowed.

Let's write a comment down here to address both remarks:

 This flag is used to connect VFIO to arch specific KVM code. It
 indicates that the memory under this VMA is safe for use with any
 non-cachable memory type inside KVM. Some VFIO devices, on some
 platforms, are thought to be unsafe and can cause machine crashes if
 KVM does not lock down the memory type.

> should know the implications. There's also an expectation that the
> actual driver (KVM guests) or maybe later DPDK can choose the safe
> non-cacheable or write-combine (Linux terminology) attributes for the
> BAR.

DPDK won't rely on this interface

Thanks,
Jason


From u.kleine-koenig at pengutronix.de  Tue Dec 12 10:14:44 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 19:14:44 +0100
Subject: [PATCH v8 5/6] pwm: bcm2835: Allow PWM driver to be used in
 atomic context
In-Reply-To: <20231212160838.k4z4csy455a7qnje@pengutronix.de>
References: <cover.1702369869.git.sean@mess.org>
 <e9e32c9789da3c90b5a2aa7d5a093120b76421fb.1702369869.git.sean@mess.org>
 <20231212160838.k4z4csy455a7qnje@pengutronix.de>
Message-ID: <20231212181444.mw5kxff5ijz676qh@pengutronix.de>

Hello Sean,

On Tue, Dec 12, 2023 at 05:08:38PM +0100, Uwe Kleine-K?nig wrote:
> On Tue, Dec 12, 2023 at 08:34:04AM +0000, Sean Young wrote:
> > @@ -169,6 +179,7 @@ static int bcm2835_pwm_suspend(struct device *dev)
> >  {
> >  	struct bcm2835_pwm *pc = dev_get_drvdata(dev);
> >  
> > +	clk_rate_exclusive_put(pc->clk);
> >  	clk_disable_unprepare(pc->clk);
> 
> I thought this was the remove function, but that's suspend. Adding
> clk_rate_exclusive_put() there is wrong.

https://lore.kernel.org/linux-clk/744a6371f94fe96f527eea6e52a600914e6fb6b5.1702403904.git.u.kleine-koenig at pengutronix.de/
might be useful to fix this.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/da7a9ef0/attachment-0001.sig>

From andre.przywara at arm.com  Tue Dec 12 10:16:55 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 12 Dec 2023 18:16:55 +0000
Subject: [PATCH 1/5] PM / devfreq: sun8i-a33-mbus: Simplify usage of
 clk_rate_exclusive_get()
In-Reply-To: <5ef585a3d7bee42bac5be0e40efcfbc6e75adfff.1702400947.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
	<5ef585a3d7bee42bac5be0e40efcfbc6e75adfff.1702400947.git.u.kleine-koenig@pengutronix.de>
Message-ID: <20231212181655.1a0d5971@donnerap.manchester.arm.com>

On Tue, 12 Dec 2023 18:26:38 +0100
Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote:

> clk_rate_exclusive_get() returns 0 unconditionally. So remove error
> handling. This prepares making clk_rate_exclusive_get() return void.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Looks alright to me:
Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Cheers,
Andre

> ---
>  drivers/devfreq/sun8i-a33-mbus.c | 14 ++------------
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/devfreq/sun8i-a33-mbus.c b/drivers/devfreq/sun8i-a33-mbus.c
> index 13d32213139f..bbc577556944 100644
> --- a/drivers/devfreq/sun8i-a33-mbus.c
> +++ b/drivers/devfreq/sun8i-a33-mbus.c
> @@ -381,18 +381,10 @@ static int sun8i_a33_mbus_probe(struct platform_device *pdev)
>  				     "failed to enable bus clock\n");
>  
>  	/* Lock the DRAM clock rate to keep priv->nominal_bw in sync. */
> -	ret = clk_rate_exclusive_get(priv->clk_dram);
> -	if (ret) {
> -		err = "failed to lock dram clock rate\n";
> -		goto err_disable_bus;
> -	}
> +	clk_rate_exclusive_get(priv->clk_dram);
>  
>  	/* Lock the MBUS clock rate to keep MBUS_TMR_PERIOD in sync. */
> -	ret = clk_rate_exclusive_get(priv->clk_mbus);
> -	if (ret) {
> -		err = "failed to lock mbus clock rate\n";
> -		goto err_unlock_dram;
> -	}
> +	clk_rate_exclusive_get(priv->clk_mbus);
>  
>  	priv->gov_data.upthreshold	= 10;
>  	priv->gov_data.downdifferential	=  5;
> @@ -450,9 +442,7 @@ static int sun8i_a33_mbus_probe(struct platform_device *pdev)
>  	dev_pm_opp_remove_all_dynamic(dev);
>  err_unlock_mbus:
>  	clk_rate_exclusive_put(priv->clk_mbus);
> -err_unlock_dram:
>  	clk_rate_exclusive_put(priv->clk_dram);
> -err_disable_bus:
>  	clk_disable_unprepare(priv->clk_bus);
>  
>  	return dev_err_probe(dev, ret, err);



From linux at roeck-us.net  Tue Dec 12 10:20:47 2023
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 12 Dec 2023 10:20:47 -0800
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <20231212-amusement-elevation-28e42bcccc35@spud>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-3-ninad@linux.ibm.com>
 <20231212-amusement-elevation-28e42bcccc35@spud>
Message-ID: <874d4416-86e5-48cc-9c84-97357e4caefe@roeck-us.net>

On Tue, Dec 12, 2023 at 05:14:26PM +0000, Conor Dooley wrote:
> Hey,
> 
> On Tue, Dec 12, 2023 at 10:39:58AM -0600, Ninad Palsule wrote:
> > From: Johannes Holland <johannes.holland at infineon.com>
> > 
> > Add a dt schema to support device tree bindings
> 
> "Add bindings for..."
> 
> > for the generic I2C
> > physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
> > Specification for TPM 2.0 v1.04 Revision 14.
> > 
> > This includes descriptions for the Nuvoton and Infineon devices.
> > 
> 
> > OpenBMC-Staging-Count: 3
> 
> I have no idea what this is, but it needs to be removed from the patch.
> 
> > Signed-off-by: Johannes Holland <johannes.holland at infineon.com>
> > Signed-off-by: Joel Stanley <joel at jms.id.au>
> > Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> > ---
> >  .../bindings/security/tpm/tpm-tis-i2c.yaml    | 50 +++++++++++++++++++
> >  1 file changed, 50 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> > new file mode 100644
> > index 000000000000..de1e34065748
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> > @@ -0,0 +1,50 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: I2C PTP based TPM Devices
> > +
> > +maintainers:
> > +  - Johannes Holland <johannes.holland at infineon.com>
> > +
> > +description:
> > +  Device Tree Bindings for I2C based Trusted Platform Module (TPM).
> 
> s/Device Tree Bindings for //. Doesn't dt_binding_check now complain if
> you have this in a title or description?
> 
> > +properties:
> > +  $nodename:
> > +    pattern: "^tpm(@[0-9a-f]+)?$"
> > +
> > +  compatible:
> > +    oneOf:
> > +      - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
> > +        items:
> > +          - const: infineon,slb9673
> > +          - const: tcg,tpm-tis-i2c
> > +      - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
> > +        items:
> > +          - const: nuvoton,npct75x
> > +          - const: tcg,tpm-tis-i2c
> 
> > +      - const: tcg,tpm-tis-i2c
> 
> IMO this should be removed and this fallback should only be used in
> combination with device specific compatibles, like you have here for the
> infineon and nuvoton devices.

As mentioned in my response to the other patch, "only" isn't sufficient
since the tacoma devicetree file only references the generic entry.
It would also make support for chips from other vendors unnecessarily
complex.

Question should in my opinion be if the non-fallback entries are really
needed.

Thanks,
Guenter


From khilman at kernel.org  Tue Dec 12 10:26:05 2023
From: khilman at kernel.org (Kevin Hilman)
Date: Tue, 12 Dec 2023 10:26:05 -0800
Subject: [PATCH 3/6] usb: cdns3-ti: add suspend/resume procedures for J7200
In-Reply-To: <CX9MMPFL7HAY.NGULD1FN5WPN@tleb-bootlin-xps13-01>
References: <20231113-j7200-usb-suspend-v1-0-ad1ee714835c@bootlin.com>
 <20231113-j7200-usb-suspend-v1-3-ad1ee714835c@bootlin.com>
 <5080372b-1f48-4cbc-a6c4-8689c28983cb@kernel.org>
 <CWZH66HQZNYM.T623ZOEEE0BK@tleb-bootlin-xps13-01>
 <dad980f3-e032-41e4-a1e4-a16a7f45ff95@kernel.org>
 <CX0GOP07I40N.198G7LJ0HYDBG@tleb-bootlin-xps13-01>
 <bdea68ad-7523-4738-8fa1-b670d81a6b93@kernel.org>
 <CX10D9YX1O1C.30PF317AG065N@tleb-bootlin-xps13-01>
 <3e00b2ad-b58f-4b09-9230-683c58d3bb92@kernel.org>
 <CX15J7B8F8HH.1WZ10OOW31X1H@tleb-bootlin-xps13-01>
 <7h34wxfmwn.fsf@baylibre.com>
 <CX63KP2UPL1N.J9Q344Q06IGP@tleb-bootlin-xps13-01>
 <7hil5odtwl.fsf@baylibre.com>
 <CX9MMPFL7HAY.NGULD1FN5WPN@tleb-bootlin-xps13-01>
Message-ID: <7h7cljcm6a.fsf@baylibre.com>

Th?o Lebrun <theo.lebrun at bootlin.com> writes:

> Hello,
>
> On Sun Nov 26, 2023 at 11:36 PM CET, Kevin Hilman wrote:
>> Th?o Lebrun <theo.lebrun at bootlin.com> writes:
>> > On Wed Nov 22, 2023 at 11:23 PM CET, Kevin Hilman wrote:
>> >> Th?o Lebrun <theo.lebrun at bootlin.com> writes:
>> >> The point is to signal to the power domain the device is in that it can
>> >> power on/off.  These IP blocks are (re)used on many different SoCs, so
>> >> the driver should not make any assumptions about what power domain it is
>> >> in (if any.)
>> >
>> > On my platform, when the device is attached to the PD it gets turned on.
>> > That feels logical to me: if a driver is not RPM aware it "just works".
>>
>> It "just works"... until the domain gets turned off.
>>
>> > Are there platforms where RPM must get enabled for the attached
>> > power-domains to be turned on?
>>
>> Yes, but but more importantly, there are platforms where RPM must get
>> enabled for the power domain to *stay* on.  For example, the power
>> domain might get turned on due to devices probing etc, but as soon as
>> all the RPM-enabled drivers drop their refcount, the domain will turn
>> off.  If there is a device in that domain with a non-RPM enabled driver,
>> that device will be powered off anc cause a crash.
>
> OK, that makes sense, thanks for taking the time to explain. This topic
> makes me see two things that I feel are close to being bugs. I'd be
> curious to get your view on both.

TL;DR; they are features, not bugs.  ;)

>  - If a device does not use RPM but its children do, it might get its
>    associated power-domain turned off. That forces every single driver
>    that want to stay alive to enable & increment RPM.
>
>    What I naively expect: a genpd with a device attached to it that is
>    not using RPM should mean that it should not be powered off at
>    runtime_suspend. Benefit: no RPM calls in drivers that do not use
>    it, and the behavior is that the genpd associated stays alive "as
>    expected".

Your expectation makes sense, but unfortunately, that's not how RPM was
designed.

Also remember that we don't really want specific device drivers to know
which PM domain they are in, or whether they are in a PM domain at
all. The same IP block can be integrated in different ways across
different SoCs, even within the same SoC family, and we want the device
driver to just work.  

For that to work well, any driver that might be in any PM domain should
add RPM calls.

>  - If a device uses RPM & has a refcount strictly positive, its
>    associated power-domain gets turned off either way at suspend_noirq.
>    That feels non-intuitive as well.
>
>    What I naively expect: check for RPM refcounts of attached devices
>    when doing suspend_noirq of power-domains. Benefit: control of what
>    power-domains do from attached devices is done through the RPM API.

I agree that this is non-intuitive from an RPM PoV, but remember that
RPM was added on top of existing system-wide suspend support.  And from
a system-wide suspend PoV, it might be non-intuitive that a driver
thinks it should be active (non-zero refcount) when user just requested
a system-wide suspend.  Traditionally, when a user requests a
system-wide suspend, they expect the whole system to shut down.

On real SoCs in real products, power management is not so black and
white, and I fully understand that, and personally, I'm definitely open
to not forcing RPM-active devices off in suspend, but that would require
changes to core code, and remove some assumptions of core code that
would need to be validated/tested.

Kevin


From shy828301 at gmail.com  Tue Dec 12 10:31:18 2023
From: shy828301 at gmail.com (Yang Shi)
Date: Tue, 12 Dec 2023 10:31:18 -0800
Subject: [PATCH] ARM64: Implement arch_report_meminfo()
In-Reply-To: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org>
References: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org>
Message-ID: <CAHbLzkpPTVHGUKfA1xeNwp100UAJxe0pmvMQdXpn_qmX3eLdag@mail.gmail.com>

On Fri, Dec 8, 2023 at 1:12?PM Christoph Lameter (Ampere) <cl at gentwo.org> wrote:
>
> X86 has information in /proc/meminfo showing the use of large mappings
> for the kernel direct map. This has now also become important for
> ARM since the kernel default CONFIG_RODATA_FULL_DEFAULT_ENABLED
> forces 4K PTE use for the direct map and users may not be aware
> of the performance impact of the increased TLB use etc.
>
> The output of /proc/meminfo on ARM64 is then after this patch:
>
> 4K page size:
>
> Hugepagesize:       2048 kB
> Hugetlb:               0 kB
> DirectMap4k:      155912 kB
> CONT DMap4k:        1176 kB
> DirectMap2M:      722944 kB
> CONT DMap2M:       28672 kB
> DirectMap1G:   534773760 kB
>
> 64K page size:
>
> Hugepagesize:     524288 kB
> Hugetlb:               0 kB
> DirectMap64k:      882624 kB
> CONT DMap64k:       19904 kB
> DirectMap512M:    534773760 kB
> CONT DMap512M:           0 kB
> DirectMap4096G:           0 kB
>
> Signed-off-by: Christoph Lameter <cl at linux.com>
>
> Index: linux/arch/arm64/mm/mmu.c
> ===================================================================
> --- linux.orig/arch/arm64/mm/mmu.c
> +++ linux/arch/arm64/mm/mmu.c
> @@ -66,6 +66,12 @@ u32 __boot_cpu_mode[] = { BOOT_CPU_MODE_
>    */
>   long __section(".mmuoff.data.write") __early_cpu_boot_status;
>
> +static atomic_t nr_pte;
> +static atomic_t nr_pmd;
> +static atomic_t nr_pud;
> +static atomic_t nr_pte_cont;
> +static atomic_t nr_pmd_cont;

These statistics are useful for debugging. However, why not use the
direct_pages_count[] array to save the counters like other
architectures, for example, x86, ppc and s390?

> +
>   /*
>    * Empty_zero_page is a special page that is used for zero-initialized data
>    * and COW.
> @@ -179,6 +185,7 @@ static void init_pte(pmd_t *pmdp, unsign
>                 pte_t old_pte = READ_ONCE(*ptep);
>
>                 set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
> +               atomic_inc(&nr_pte);
>
>                 /*
>                  * After the PTE entry has been populated once, we
> @@ -223,8 +230,10 @@ static void alloc_init_cont_pte(pmd_t *p
>
>                 /* use a contiguous mapping if the range is suitably aligned */
>                 if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
> -                   (flags & NO_CONT_MAPPINGS) == 0)
> +                   (flags & NO_CONT_MAPPINGS) == 0) {
>                         __prot = __pgprot(pgprot_val(prot) | PTE_CONT);
> +                       atomic_inc(&nr_pte_cont);
> +               }
>
>                 init_pte(pmdp, addr, next, phys, __prot);
>
> @@ -249,6 +258,7 @@ static void init_pmd(pud_t *pudp, unsign
>                 if (((addr | next | phys) & ~PMD_MASK) == 0 &&
>                     (flags & NO_BLOCK_MAPPINGS) == 0) {
>                         pmd_set_huge(pmdp, phys, prot);
> +                       atomic_inc(&nr_pmd);
>
>                         /*
>                          * After the PMD entry has been populated once, we
> @@ -301,8 +311,10 @@ static void alloc_init_cont_pmd(pud_t *p
>
>                 /* use a contiguous mapping if the range is suitably aligned */
>                 if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
> -                   (flags & NO_CONT_MAPPINGS) == 0)
> +                   (flags & NO_CONT_MAPPINGS) == 0) {
>                         __prot = __pgprot(pgprot_val(prot) | PTE_CONT);
> +                       atomic_inc(&nr_pmd_cont);
> +               }
>
>                 init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
>
> @@ -346,7 +358,7 @@ static void alloc_init_pud(pgd_t *pgdp,
>                    ((addr | next | phys) & ~PUD_MASK) == 0 &&
>                     (flags & NO_BLOCK_MAPPINGS) == 0) {
>                         pud_set_huge(pudp, phys, prot);
> -
> +                       atomic_inc(&nr_pud);
>                         /*
>                          * After the PUD entry has been populated once, we
>                          * only allow updates to the permission attributes.
> @@ -1486,3 +1498,35 @@ void ptep_modify_prot_commit(struct vm_a
>   {
>         set_pte_at(vma->vm_mm, addr, ptep, pte);
>   }
> +
> +#ifdef CONFIG_PROC_FS
> +void arch_report_meminfo(struct seq_file *m)
> +{
> +       unsigned long pagesize_in_kb = PAGE_SIZE / 1024;
> +
> +       seq_printf(m, "DirectMap%luk:    %8lu kB\n",
> +                       pagesize_in_kb,
> +                       (unsigned long)atomic_read(&nr_pte) * pagesize_in_kb);
> +
> +        seq_printf(m, "CONT DMap%luk:    %8lu kB\n",
> +                       pagesize_in_kb,
> +                       (unsigned long)atomic_read(&nr_pte_cont) * pagesize_in_kb);
> +
> +       pagesize_in_kb = PMD_SIZE / 1024;
> +
> +        seq_printf(m, "DirectMap%luM:    %8lu kB\n",
> +                       pagesize_in_kb / 1024,
> +                       (unsigned long)atomic_read(&nr_pmd) * pagesize_in_kb);
> +
> +       seq_printf(m, "CONT DMap%luM:    %8lu kB\n",
> +                       pagesize_in_kb / 1024,
> +                       (unsigned long)atomic_read(&nr_pmd_cont) * pagesize_in_kb);
> +
> +       pagesize_in_kb = PUD_SIZE / 1024;
> +
> +       seq_printf(m, "DirectMap%luG:  %10lu kB\n",
> +                       pagesize_in_kb >> 20,
> +                        (unsigned long)atomic_read(&nr_pud) * pagesize_in_kb);
> +}
> +#endif
> +
>


From Frank.li at nxp.com  Tue Dec 12 10:32:11 2023
From: Frank.li at nxp.com (Frank Li)
Date: Tue, 12 Dec 2023 13:32:11 -0500
Subject: [PATCH v3 01/13] PCI: imx6: Simplify clock handling by using
 HAS_CLK_* bitmask
In-Reply-To: <20231212164913.GA21240@thinkpad>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-2-Frank.Li@nxp.com>
 <20231212164913.GA21240@thinkpad>
Message-ID: <ZXinK/RF0Kc4ySYX@lizhi-Precision-Tower-5810>

On Tue, Dec 12, 2023 at 10:19:13PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Dec 11, 2023 at 04:58:30PM -0500, Frank Li wrote:
> > Refactors the clock handling logic in the imx6 PCI driver by adding
> > HAS_CLK_* bitmask define for drvdata::flags . Simplifies the code and makes
> > it more maintainable, as future additions of SOC support will only require
> > straightforward changes. The drvdata::flags and a bitmask ensures a cleaner
> > and more scalable switch-case structure for handling clocks.
> > 
> 
> Is there any necessity to validate each clock in the driver? I mean, can't you
> just rely on devicetree to provide enough clocks for the functioning of the PCIe
> controller?
> 
> If you can rely on devicetree (everyone should in an ideal world), then you can
> just use devm_clk_bulk_get_all() to get all available clocks for the SoC and
> just enable/disable whatever is available.
> 
> This will greatly simplify the code.
> 
> Only downside of this approach is, if the devicetree is not supplying enough
> clocks, then it will be difficult to find why PCIe is not working. But this also
> means that the devicetree is screwed.

I have idea, how about add clk name array in drvdata.

such as
      clk_names[] = {"bus", "aux", "axi", ...}
      clk_cnt = 4.

Then use devm_clk_blk_get_all().

Code will be simplied and not too much depend on devicetree's validate.

Frank

> 
> - Mani
> 
> > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > ---
> > 
> > Notes:
> >     Change from v1 to v3
> >     - none
> > 
> >  drivers/pci/controller/dwc/pci-imx6.c | 84 +++++++++++++--------------
> >  1 file changed, 42 insertions(+), 42 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> > index 74703362aeec7..8a9b527934f80 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -60,6 +60,10 @@ enum imx6_pcie_variants {
> >  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
> >  #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
> >  #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
> > +#define IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI	BIT(3)
> > +#define IMX6_PCIE_FLAG_HAS_CLK_AUX		BIT(4)
> > +
> > +#define imx6_check_flag(pci, val)	(pci->drvdata->flags & val)
> >  
> >  struct imx6_pcie_drvdata {
> >  	enum imx6_pcie_variants variant;
> > @@ -550,19 +554,23 @@ static int imx6_pcie_attach_pd(struct device *dev)
> >  
> >  static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> >  {
> > -	struct dw_pcie *pci = imx6_pcie->pci;
> > -	struct device *dev = pci->dev;
> >  	unsigned int offset;
> >  	int ret = 0;
> >  
> > -	switch (imx6_pcie->drvdata->variant) {
> > -	case IMX6SX:
> > +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
> >  		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
> > -		if (ret) {
> > -			dev_err(dev, "unable to enable pcie_axi clock\n");
> > -			break;
> > -		}
> > +		if (ret)
> > +			return ret;
> > +	}
> >  
> > +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
> > +		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	switch (imx6_pcie->drvdata->variant) {
> > +	case IMX6SX:
> >  		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> >  				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
> >  		break;
> > @@ -589,12 +597,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> >  	case IMX8MQ_EP:
> >  	case IMX8MP:
> >  	case IMX8MP_EP:
> > -		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
> > -		if (ret) {
> > -			dev_err(dev, "unable to enable pcie_aux clock\n");
> > -			break;
> > -		}
> > -
> >  		offset = imx6_pcie_grp_offset(imx6_pcie);
> >  		/*
> >  		 * Set the over ride low and enabled
> > @@ -614,10 +616,13 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
> >  
> >  static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
> >  {
> > -	switch (imx6_pcie->drvdata->variant) {
> > -	case IMX6SX:
> > +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI))
> >  		clk_disable_unprepare(imx6_pcie->pcie_inbound_axi);
> > -		break;
> > +
> > +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX))
> > +		clk_disable_unprepare(imx6_pcie->pcie_aux);
> > +
> > +	switch (imx6_pcie->drvdata->variant) {
> >  	case IMX6QP:
> >  	case IMX6Q:
> >  		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > @@ -631,14 +636,6 @@ static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
> >  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
> >  				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
> >  		break;
> > -	case IMX8MM:
> > -	case IMX8MM_EP:
> > -	case IMX8MQ:
> > -	case IMX8MQ_EP:
> > -	case IMX8MP:
> > -	case IMX8MP_EP:
> > -		clk_disable_unprepare(imx6_pcie->pcie_aux);
> > -		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -1316,21 +1313,21 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> >  		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
> >  				     "pcie clock source missing or invalid\n");
> >  
> > -	switch (imx6_pcie->drvdata->variant) {
> > -	case IMX6SX:
> > -		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
> > -							   "pcie_inbound_axi");
> > +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI)) {
> > +		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev, "pcie_inbound_axi");
> >  		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
> > -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
> > -					     "pcie_inbound_axi clock missing or invalid\n");
> > -		break;
> > -	case IMX8MQ:
> > -	case IMX8MQ_EP:
> > +			dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
> > +				      "pcie_inbound_axi clock missing or invalid\n");
> > +	}
> > +
> > +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_CLK_AUX)) {
> >  		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> >  		if (IS_ERR(imx6_pcie->pcie_aux))
> >  			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> >  					     "pcie_aux clock source missing or invalid\n");
> > -		fallthrough;
> > +	}
> > +
> > +	switch (imx6_pcie->drvdata->variant) {
> >  	case IMX7D:
> >  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> >  			imx6_pcie->controller_id = 1;
> > @@ -1353,10 +1350,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> >  	case IMX8MM_EP:
> >  	case IMX8MP:
> >  	case IMX8MP_EP:
> > -		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> > -		if (IS_ERR(imx6_pcie->pcie_aux))
> > -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> > -					     "pcie_aux clock source missing or invalid\n");
> >  		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> >  									 "apps");
> >  		if (IS_ERR(imx6_pcie->apps_reset))
> > @@ -1482,7 +1475,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
> >  		.variant = IMX6SX,
> >  		.flags = IMX6_PCIE_FLAG_IMX6_PHY |
> >  			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
> > -			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> > +			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> > +			 IMX6_PCIE_FLAG_HAS_CLK_INBOUND_AXI,
> >  		.gpr = "fsl,imx6q-iomuxc-gpr",
> >  	},
> >  	[IMX6QP] = {
> > @@ -1500,30 +1494,36 @@ static const struct imx6_pcie_drvdata drvdata[] = {
> >  	},
> >  	[IMX8MQ] = {
> >  		.variant = IMX8MQ,
> > +		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
> >  		.gpr = "fsl,imx8mq-iomuxc-gpr",
> >  	},
> >  	[IMX8MM] = {
> >  		.variant = IMX8MM,
> > -		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> > +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> > +			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
> >  		.gpr = "fsl,imx8mm-iomuxc-gpr",
> >  	},
> >  	[IMX8MP] = {
> >  		.variant = IMX8MP,
> > -		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> > +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> > +			 IMX6_PCIE_FLAG_HAS_CLK_AUX,
> >  		.gpr = "fsl,imx8mp-iomuxc-gpr",
> >  	},
> >  	[IMX8MQ_EP] = {
> >  		.variant = IMX8MQ_EP,
> > +		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
> >  		.mode = DW_PCIE_EP_TYPE,
> >  		.gpr = "fsl,imx8mq-iomuxc-gpr",
> >  	},
> >  	[IMX8MM_EP] = {
> >  		.variant = IMX8MM_EP,
> > +		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
> >  		.mode = DW_PCIE_EP_TYPE,
> >  		.gpr = "fsl,imx8mm-iomuxc-gpr",
> >  	},
> >  	[IMX8MP_EP] = {
> >  		.variant = IMX8MP_EP,
> > +		.flags = IMX6_PCIE_FLAG_HAS_CLK_AUX,
> >  		.mode = DW_PCIE_EP_TYPE,
> >  		.gpr = "fsl,imx8mp-iomuxc-gpr",
> >  	},
> > -- 
> > 2.34.1
> > 
> 
> -- 
> ????????? ????????


From bot at kernelci.org  Tue Dec 12 10:39:01 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Tue, 12 Dec 2023 10:39:01 -0800 (PST)
Subject: arm64/for-kernelci build: 1 build: 0 failed,
 1 passed (v6.7-rc5-71-gaedef4a80fb02)
Message-ID: <6578a8c5.a70a0220.ff5d1.ab1d@mx.google.com>

arm64/for-kernelci build: 1 build: 0 failed, 1 passed (v6.7-rc5-71-gaedef4a80fb02)

Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v6.7-rc5-71-gaedef4a80fb02/

Tree: arm64
Branch: for-kernelci
Git Describe: v6.7-rc5-71-gaedef4a80fb02
Git Commit: aedef4a80fb0244702dfd9ef9b6cd5a4e2757836
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Built: 1 unique architecture

================================================================================

Detailed per-defconfig build reports:

--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) ? PASS, 0 errors, 0 warnings, 0 section mismatches

---
For more info write to <info at kernelci.org>


From robh at kernel.org  Tue Dec 12 10:44:06 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 12 Dec 2023 12:44:06 -0600
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <ZXiMiLz9ZyUdxUP8@raptor>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com> <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
 <ZXiMiLz9ZyUdxUP8@raptor>
Message-ID: <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>

On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
<alexandru.elisei at arm.com> wrote:
>
> Hi Rob,
>
> Thank you so much for the feedback, I'm not very familiar with device tree,
> and any comments are very useful.
>
> On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > <alexandru.elisei at arm.com> wrote:
> > >
> > > Allow the kernel to get the size and location of the MTE tag storage
> > > regions from the DTB. This memory is marked as reserved for now.
> > >
> > > The DTB node for the tag storage region is defined as:
> > >
> > >         tags0: tag-storage at 8f8000000 {
> > >                 compatible = "arm,mte-tag-storage";
> > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > >                 block-size = <0x1000>;
> > >                 memory = <&memory0>;    // Associated tagged memory node
> > >         };
> >
> > I skimmed thru the discussion some. If this memory range is within
> > main RAM, then it definitely belongs in /reserved-memory.
>
> Ok, will do that.
>
> If you don't mind, why do you say that it definitely belongs in
> reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> motivation.

Simply so that /memory nodes describe all possible memory and
/reserved-memory is just adding restrictions. It's also because
/reserved-memory is what gets handled early, and we don't need
multiple things to handle early.

> Tag storage is not DMA and can live anywhere in memory.

Then why put it in DT at all? The only reason CMA is there is to set
the size. It's not even clear to me we need CMA in DT either. The
reasoning long ago was the kernel didn't do a good job of moving and
reclaiming contiguous space, but that's supposed to be better now (and
most h/w figured out they need IOMMUs).

But for tag storage you know the size as it is a function of the
memory size, right? After all, you are validating the size is correct.
I guess there is still the aspect of whether you want enable MTE or
not which could be done in a variety of ways.

> In
> arm64_memblock_init(), the kernel first removes the memory that it cannot
> address from memblock. For example, because it has been compiled with
> CONFIG_ARM64_VA_BITS_39=y. And then calls
> early_init_fdt_scan_reserved_mem().
>
> What happens if reserved memory is above what the kernel can address?

I would hope the kernel handles it. That's the kernel's problem unless
there's some h/w limitation to access some region. The DT can't have
things dependent on the kernel config.

> From my testing, when the kernel is compiled with 39 bit VA, if I use
> reserved memory to discover tag storage the lives above the virtua address
> limit and then I try to use CMA to manage the tag storage memory, I get a
> kernel panic:

Looks like we should handle that better...

>> [    0.000000] Reserved memory: created CMA memory pool at 0x0000010000000000, size 64 MiB
> [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> [    0.000000] OF: reserved mem: 0x0000010000000000..0x0000010003ffffff (65536 KiB) map reusable linux,cma
> [..]
> [    0.806945] Unable to handle kernel paging request at virtual address 00000001fe000000
> [    0.807277] Mem abort info:
> [    0.807277]   ESR = 0x0000000096000005
> [    0.807693]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    0.808110]   SET = 0, FnV = 0
> [    0.808443]   EA = 0, S1PTW = 0
> [    0.808526]   FSC = 0x05: level 1 translation fault
> [    0.808943] Data abort info:
> [    0.808943]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
> [    0.809360]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [    0.809776]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [    0.810221] [00000001fe000000] user address but active_mm is swapper
> [..]
> [    0.820887] Call trace:
> [    0.821027]  cma_init_reserved_areas+0xc4/0x378
>
> >
> > You need a binding for this too.
>
> By binding you mean having an yaml file in dt-schem [1] describing the tag
> storage node, right?

Yes, but in the kernel tree is fine.

[...]

> > > +static int __init tag_storage_of_flat_get_range(unsigned long node, const __be32 *reg,
> > > +                                               int reg_len, struct range *range)
> > > +{
> > > +       int addr_cells = dt_root_addr_cells;
> > > +       int size_cells = dt_root_size_cells;
> > > +       u64 size;
> > > +
> > > +       if (reg_len / 4 > addr_cells + size_cells)
> > > +               return -EINVAL;
> > > +
> > > +       range->start = PHYS_PFN(of_read_number(reg, addr_cells));
> > > +       size = PHYS_PFN(of_read_number(reg + addr_cells, size_cells));
> > > +       if (size == 0) {
> > > +               pr_err("Invalid node");
> > > +               return -EINVAL;
> > > +       }
> > > +       range->end = range->start + size - 1;
> >
> > We have a function to read (and translate which you forgot) addresses.
> > Add what's missing rather than open code your own.
>
> I must have missed that there's already a function to read addresses. Would
> you mind pointing me in the right direction?

drivers/of/fdt_address.c

Though it doesn't provide getting the size, so that will have to be added.


> > > +
> > > +       return 0;
> > > +}
> > > +
> > > +static int __init tag_storage_of_flat_get_tag_range(unsigned long node,
> > > +                                                   struct range *tag_range)
> > > +{
> > > +       const __be32 *reg;
> > > +       int reg_len;
> > > +
> > > +       reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> > > +       if (reg == NULL) {
> > > +               pr_err("Invalid metadata node");
> > > +               return -EINVAL;
> > > +       }
> > > +
> > > +       return tag_storage_of_flat_get_range(node, reg, reg_len, tag_range);
> > > +}
> > > +
> > > +static int __init tag_storage_of_flat_get_memory_range(unsigned long node, struct range *mem)
> > > +{
> > > +       const __be32 *reg;
> > > +       int reg_len;
> > > +
> > > +       reg = of_get_flat_dt_prop(node, "linux,usable-memory", &reg_len);
> > > +       if (reg == NULL)
> > > +               reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> > > +
> > > +       if (reg == NULL) {
> > > +               pr_err("Invalid memory node");
> > > +               return -EINVAL;
> > > +       }
> > > +
> > > +       return tag_storage_of_flat_get_range(node, reg, reg_len, mem);
> > > +}
> > > +
> > > +struct find_memory_node_arg {
> > > +       unsigned long node;
> > > +       u32 phandle;
> > > +};
> > > +
> > > +static int __init fdt_find_memory_node(unsigned long node, const char *uname,
> > > +                                      int depth, void *data)
> > > +{
> > > +       const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> > > +       struct find_memory_node_arg *arg = data;
> > > +
> > > +       if (depth != 1 || !type || strcmp(type, "memory") != 0)
> > > +               return 0;
> > > +
> > > +       if (of_get_flat_dt_phandle(node) == arg->phandle) {
> > > +               arg->node = node;
> > > +               return 1;
> > > +       }
> > > +
> > > +       return 0;
> > > +}
> > > +
> > > +static int __init tag_storage_get_memory_node(unsigned long tag_node, unsigned long *mem_node)
> > > +{
> > > +       struct find_memory_node_arg arg = { 0 };
> > > +       const __be32 *memory_prop;
> > > +       u32 mem_phandle;
> > > +       int ret, reg_len;
> > > +
> > > +       memory_prop = of_get_flat_dt_prop(tag_node, "memory", &reg_len);
> > > +       if (!memory_prop) {
> > > +               pr_err("Missing 'memory' property in the tag storage node");
> > > +               return -EINVAL;
> > > +       }
> > > +
> > > +       mem_phandle = be32_to_cpup(memory_prop);
> > > +       arg.phandle = mem_phandle;
> > > +
> > > +       ret = of_scan_flat_dt(fdt_find_memory_node, &arg);
> >
> > Do not use of_scan_flat_dt. It is a relic predating libfdt which can
> > get a node by phandle directly.
>
> I used that because that's what drivers/of/fdt.c uses. With reserved memory
> I shouldn't need it, because struct reserved_mem already includes a
> phandle.

Check again. Only some arch/ code (mostly powerpc) uses it. I've
killed off most of it.


> > > +       if (ret != 1) {
> > > +               pr_err("Associated memory node not found");
> > > +               return -EINVAL;
> > > +       }
> > > +
> > > +       *mem_node = arg.node;
> > > +
> > > +       return 0;
> > > +}
> > > +
> > > +static int __init tag_storage_of_flat_read_u32(unsigned long node, const char *propname,
> > > +                                              u32 *retval)
> >
> > If you are going to make a generic function, make it for everyone.
>
> Sure. If I still need it, should I put the function in
> include/linux/of_fdt.h?

Yes.

> > > +{
> > > +       const __be32 *reg;
> > > +
> > > +       reg = of_get_flat_dt_prop(node, propname, NULL);
> > > +       if (!reg)
> > > +               return -EINVAL;
> > > +
> > > +       *retval = be32_to_cpup(reg);
> > > +       return 0;
> > > +}
> > > +
> > > +static u32 __init get_block_size_pages(u32 block_size_bytes)
> > > +{
> > > +       u32 a = PAGE_SIZE;
> > > +       u32 b = block_size_bytes;
> > > +       u32 r;
> > > +
> > > +       /* Find greatest common divisor using the Euclidian algorithm. */
> > > +       do {
> > > +               r = a % b;
> > > +               a = b;
> > > +               b = r;
> > > +       } while (b != 0);
> > > +
> > > +       return PHYS_PFN(PAGE_SIZE * block_size_bytes / a);
> > > +}
> > > +
> > > +static int __init fdt_init_tag_storage(unsigned long node, const char *uname,
> > > +                                      int depth, void *data)
> > > +{
> > > +       struct tag_region *region;
> > > +       unsigned long mem_node;
> > > +       struct range *mem_range;
> > > +       struct range *tag_range;
> > > +       u32 block_size_bytes;
> > > +       u32 nid = 0;
> > > +       int ret;
> > > +
> > > +       if (depth != 1 || !strstr(uname, "tag-storage"))
> > > +               return 0;
> > > +
> > > +       if (!of_flat_dt_is_compatible(node, "arm,mte-tag-storage"))
> > > +               return 0;
> > > +
> > > +       if (num_tag_regions == MAX_TAG_REGIONS) {
> > > +               pr_err("Maximum number of tag storage regions exceeded");
> > > +               return -EINVAL;
> > > +       }
> > > +
> > > +       region = &tag_regions[num_tag_regions];
> > > +       mem_range = &region->mem_range;
> > > +       tag_range = &region->tag_range;
> > > +
> > > +       ret = tag_storage_of_flat_get_tag_range(node, tag_range);
> > > +       if (ret) {
> > > +               pr_err("Invalid tag storage node");
> > > +               return ret;
> > > +       }
> > > +
> > > +       ret = tag_storage_get_memory_node(node, &mem_node);
> > > +       if (ret)
> > > +               return ret;
> > > +
> > > +       ret = tag_storage_of_flat_get_memory_range(mem_node, mem_range);
> > > +       if (ret) {
> > > +               pr_err("Invalid address for associated data memory node");
> > > +               return ret;
> > > +       }
> > > +
> > > +       /* The tag region must exactly match the corresponding memory. */
> > > +       if (range_len(tag_range) * 32 != range_len(mem_range)) {
> > > +               pr_err("Tag storage region 0x%llx-0x%llx does not cover the memory region 0x%llx-0x%llx",
> > > +                      PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->end),
> > > +                      PFN_PHYS(mem_range->start), PFN_PHYS(mem_range->end));
> > > +               return -EINVAL;
> > > +       }
> > > +
> > > +       ret = tag_storage_of_flat_read_u32(node, "block-size", &block_size_bytes);
> > > +       if (ret || block_size_bytes == 0) {
> > > +               pr_err("Invalid or missing 'block-size' property");
> > > +               return -EINVAL;
> > > +       }
> > > +       region->block_size = get_block_size_pages(block_size_bytes);
> > > +       if (range_len(tag_range) % region->block_size != 0) {
> > > +               pr_err("Tag storage region size 0x%llx is not a multiple of block size %u",
> > > +                      PFN_PHYS(range_len(tag_range)), region->block_size);
> > > +               return -EINVAL;
> > > +       }
> > > +
> > > +       ret = tag_storage_of_flat_read_u32(mem_node, "numa-node-id", &nid);
> >
> > I was going to say we already have a way to associate memory nodes
> > other nodes using "numa-node-id", so the "memory" phandle property is
> > somewhat redundant. Maybe the tag node should have a numa-node-id.
> > With that, it looks like you don't even need to access the /memory
> > node. Avoiding that would be good for 2 reasons. It avoids parsing
> > memory nodes twice and it's not the kernel's job to validate the DT.
> > Really, if you want memory info, you should use memblock to get it
> > because all the special cases of memory layout are handled. For
> > example you can have memory nodes with multiple 'reg' entries or
> > multiple memory nodes or both, and then some of those could be
> > contiguous.
>
> I need to have a memory node associated with the tag storage node because
> there is a static relationship between a page from "normal" memory and its
> associated tag storage. If the code doesn't know that the memory region
> A..B has the corresponding tag storage in the region X..Y, then it doesn't
> know which tag storage to reserve when a page is allocated as tagged.
>
> In the example above, assuming that page P is allocated as tagged, the
> corresponding tag storage page that needs to be reserved is:
>
> tag_storage_pfn = (page_to_pfn(P) - PHYS_PFN(A)) / 32* + PHYS_PFN(X)
>
> numa-node-id is not enough for this, because as far I know you can have
> multiple memory regions withing the same numa node.

Okay.

Rob


From horms at kernel.org  Tue Dec 12 10:48:09 2023
From: horms at kernel.org (Simon Horman)
Date: Tue, 12 Dec 2023 18:48:09 +0000
Subject: [PATCH net] net: stmmac: Handle disabled MDIO busses from
 devicetree
In-Reply-To: <20231211-b4-stmmac-handle-mdio-enodev-v1-1-73c20c44f8d6@redhat.com>
References: <20231211-b4-stmmac-handle-mdio-enodev-v1-1-73c20c44f8d6@redhat.com>
Message-ID: <20231212184809.GA5817@kernel.org>

On Mon, Dec 11, 2023 at 03:31:17PM -0600, Andrew Halaney wrote:
> Many hardware configurations have the MDIO bus disabled, and are instead
> using some other MDIO bus to talk to the MAC's phy.
> 
> of_mdiobus_register() returns -ENODEV in this case. Let's handle it
> gracefully instead of failing to probe the MAC.
> 
> Fixes: 47dd7a540b8a (net: add support for STMicroelectronics Ethernet controllers.")

nit: the tag above is malformed, there is a '"' missing before 'net:'.

  Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.")


> Signed-off-by: Andrew Halaney <ahalaney at redhat.com>

...


From conor at kernel.org  Tue Dec 12 10:51:32 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 12 Dec 2023 18:51:32 +0000
Subject: [PATCH v1 7/8] tpm: tis-i2c: Add more compatible strings
In-Reply-To: <73381bb0-7fa7-4a9e-88df-ab0063058e26@roeck-us.net>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-8-ninad@linux.ibm.com>
 <20231212-avid-grill-dbead068fac8@spud>
 <73381bb0-7fa7-4a9e-88df-ab0063058e26@roeck-us.net>
Message-ID: <20231212-mouth-choice-40a83caa34ec@spud>

On Tue, Dec 12, 2023 at 10:00:39AM -0800, Guenter Roeck wrote:
> On Tue, Dec 12, 2023 at 05:15:51PM +0000, Conor Dooley wrote:
> > On Tue, Dec 12, 2023 at 10:40:03AM -0600, Ninad Palsule wrote:
> > > From: Joel Stanley <joel at jms.id.au>
> > > 
> > > The NPCT75x TPM is TIS compatible. It has an I2C and SPI interface.
> > > 
> > > https://www.nuvoton.com/products/cloud-computing/security/trusted-platform-module-tpm/
> > > 
> > > Add a compatible string for it, and the generic compatible.
> > > 
> > > OpenBMC-Staging-Count: 3
> > 
> > Delete this from every patch that it appears from.
> > 
> > > Signed-off-by: Joel Stanley <joel at jms.id.au>
> > > Acked-by: Jarkko Sakkinen <jarkko at kernel.org>
> > > Link: https://lore.kernel.org/r/20220928043957.2636877-4-joel at jms.id.au
> > > Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> > > ---
> > >  drivers/char/tpm/tpm_tis_i2c.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/char/tpm/tpm_tis_i2c.c b/drivers/char/tpm/tpm_tis_i2c.c
> > > index a897402cc36a..9511c0d50185 100644
> > > --- a/drivers/char/tpm/tpm_tis_i2c.c
> > > +++ b/drivers/char/tpm/tpm_tis_i2c.c
> > > @@ -383,6 +383,8 @@ MODULE_DEVICE_TABLE(i2c, tpm_tis_i2c_id);
> > >  #ifdef CONFIG_OF
> > >  static const struct of_device_id of_tis_i2c_match[] = {
> > >  	{ .compatible = "infineon,slb9673", },
> > > +	{ .compatible = "nuvoton,npct75x", },
> > > +	{ .compatible = "tcg,tpm-tis-i2c", },
> > 
> > What's the point of the generic compatible if you are adding the device
> > specific ones to the driver anyway?
> > 
> 
> $ git grep infineon,slb9673
> Documentation/devicetree/bindings/trivial-devices.yaml:          - infineon,slb9673

Hmm, this would then need to be moved into the new schema, out of
trivial devices.

> drivers/char/tpm/tpm_tis_i2c.c: { .compatible = "infineon,slb9673", },
> $ git grep nuvoton,npct75x
> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
> $ git grep tcg,tpm-tis-i2c
> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
> arch/arm/boot/dts/aspeed/aspeed-bmc-opp-tacoma.dts:             compatible = "tcg,tpm-tis-i2c";

pog, undocumented compatibles.

> It looks like at least the generic entry is needed, given that it is quite
> likely that there is hardware out there using it. Other than that, this
> makes me wonder: Is there some official guideline describing if and when
> to use (only) generic devicetree compatible entries and when specific ones
> may / should / have to be used ? I suspect the answer to your question might
> simply be "because we did not know better", and it might be helpful to be
> able to say "please see XXX for details".

To me using generic compatibles is okay when there is another mechanism
to identify the device. This patch would make more sense if the addition
of nuvoton,npct75x was omitted and the dt-binding had

properties:
  compatible:
    items:
      - enum:
          - infineon,slb9673
          - nuvoton,npct75x
      - const: tcg,tpm-tis-i2c

And whenever new i2c tpms showed up the device specific compatible was
added to the bindings and the driver had only* the generic compatible
static const struct of_device_id of_tis_i2c_match[] = {
	{ .compatible = "infineon,slb9673", },
	{ .compatible = "tcg,tpm-tis-i2c", },
};

* well, and the existing one since that cannot be removed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/05504858/attachment.sig>

From kibi at debian.org  Tue Dec 12 11:09:04 2023
From: kibi at debian.org (Cyril Brulebois)
Date: Tue, 12 Dec 2023 20:09:04 +0100
Subject: [PATCH V4 0/3] ARM: dts: bcm2711: Add BCM2711 xHCI support
In-Reply-To: <20231205200531.8232-1-wahrenst@gmx.net>
References: <20231205200531.8232-1-wahrenst@gmx.net>
Message-ID: <20231212190904.igxm2twvftokhdwr@mraw.org>

Stefan Wahren <wahrenst at gmx.net> (2023-12-05):
> In contrast to the Raspberry Pi 4, the Compute Module 4 or the IO board
> does not have a VL805 USB 3.0 host controller, which is connected via
> PCIe. Instead, the Compute Module provides the built-in
> xHCI of the BCM2711 SoC.
> 
> Changes in V4:
> - use "brcm,xhci-brcm-v2" as fallback compatible as suggested by
>   Conor & Florian
> 
> Changes in V3:
> - introduce a new compatible for BCM2711 in order to make the
>   power domain dependency SoC specific, which also results in
>   a driver change

This is still:

Tested-by: Cyril Brulebois <cyril at debamax.com>


Again, I'm also applying Jim Quinlan's PCIe patch series v8, to be able
to fully test what happens with USB devices, onboard and behind PCIe:
  https://lore.kernel.org/all/20231126201946.ffm3bhg5du2xgztv at mraw.org/

With the following on a CM4 IO Board, with a Samsung flash drive and a
USB keyboard connected to onboard USB ports:
 - CM4 Lite Rev 1.0
 - CM4 8/32 Rev 1.0
 - CM4 4/32 Rev 1.1

and using one of the three PCIe-to-USB boards referenced previously,
connecting another Samsung flash drive on one of its USB ports.

Conclusion: I can see and use onboard USB devices alongside behind-PCIe
USB devices, either with or without adding otg_mode=1 to config.txt.

On a CM4-based product that uses both onboard USB ports and PCIe-to-USB
ports, all USB components still work fine (3 RF adapters, 1 modem), with
or without otg_mode=1.

(All of this is still with a Debian 12 arm64 user space.)


Cheers,
-- 
Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/0bc4fdab/attachment.sig>

From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:17:15 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:17:15 +0100
Subject: (subset) [PATCH v7 09/16] pinctrl: samsung: Add gs101 SoC pinctrl configuration
In-Reply-To: <20231211162331.435900-10-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-10-peter.griffin@linaro.org>
Message-ID: <170240862865.229534.3131999037082419524.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:24 +0000, Peter Griffin wrote:
> Add support for the pin-controller found on the gs101 SoC used in
> Pixel 6 phones.
> 
> 

Applied, thanks!

[09/16] pinctrl: samsung: Add gs101 SoC pinctrl configuration
        https://git.kernel.org/pinctrl/samsung/c/4a8be01a1a7a030ae7b6138602d2e060cf7a0946

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From debug at rivosinc.com  Tue Dec 12 11:17:11 2023
From: debug at rivosinc.com (Deepak Gupta)
Date: Tue, 12 Dec 2023 11:17:11 -0800
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org> <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
Message-ID: <CAKC1njSC5cC_fXnyNAPt=WU6cD-OjLKFxo90oVPmsLJbuWf4nw@mail.gmail.com>

On Wed, Nov 22, 2023 at 1:43?AM Mark Brown <broonie at kernel.org> wrote:
>
> Three architectures (x86, aarch64, riscv) have announced support for
> shadow stacks with fairly similar functionality.  While x86 is using
> arch_prctl() to control the functionality neither arm64 nor riscv uses
> that interface so this patch adds arch-agnostic prctl() support to
> get and set status of shadow stacks and lock the current configuation to
> prevent further changes, with support for turning on and off individual
> subfeatures so applications can limit their exposure to features that
> they do not need.  The features are:
>
>   - PR_SHADOW_STACK_ENABLE: Tracking and enforcement of shadow stacks,
>     including allocation of a shadow stack if one is not already
>     allocated.
>   - PR_SHADOW_STACK_WRITE: Writes to specific addresses in the shadow
>     stack.
>   - PR_SHADOW_STACK_PUSH: Push additional values onto the shadow stack.
>
> These features are expected to be inherited by new threads and cleared
> on exec(), unknown features should be rejected for enable but accepted
> for locking (in order to allow for future proofing).
>
> This is based on a patch originally written by Deepak Gupta but modified
> fairly heavily, support for indirect landing pads is removed, additional
> modes added and the locking interface reworked.  The set status prctl()
> is also reworked to just set flags, if setting/reading the shadow stack
> pointer is required this could be a separate prctl.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  include/linux/mm.h         |  4 ++++
>  include/uapi/linux/prctl.h | 22 ++++++++++++++++++++++
>  kernel/sys.c               | 30 ++++++++++++++++++++++++++++++
>  3 files changed, 56 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 10462f354614..8b28483b4afa 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -4143,4 +4143,8 @@ static inline bool pfn_is_unaccepted_memory(unsigned long pfn)
>         return range_contains_unaccepted_memory(paddr, paddr + PAGE_SIZE);
>  }
>
> +int arch_get_shadow_stack_status(struct task_struct *t, unsigned long __user *status);
> +int arch_set_shadow_stack_status(struct task_struct *t, unsigned long status);
> +int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status);
> +
>  #endif /* _LINUX_MM_H */
> diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
> index 370ed14b1ae0..3c66ed8f46d8 100644
> --- a/include/uapi/linux/prctl.h
> +++ b/include/uapi/linux/prctl.h
> @@ -306,4 +306,26 @@ struct prctl_mm_map {
>  # define PR_RISCV_V_VSTATE_CTRL_NEXT_MASK      0xc
>  # define PR_RISCV_V_VSTATE_CTRL_MASK           0x1f
>
> +/*
> + * Get the current shadow stack configuration for the current thread,
> + * this will be the value configured via PR_SET_SHADOW_STACK_STATUS.
> + */
> +#define PR_GET_SHADOW_STACK_STATUS      71
> +
> +/*
> + * Set the current shadow stack configuration.  Enabling the shadow
> + * stack will cause a shadow stack to be allocated for the thread.
> + */
> +#define PR_SET_SHADOW_STACK_STATUS      72
> +# define PR_SHADOW_STACK_ENABLE         (1UL << 0)

Other architecture may require disabling shadow stack if glibc
tunables is set to permissive mode.
In permissive mode, if glibc encounters `dlopen` on an object which
doesn't support shadow stack,
glibc should be able to issue PR_SHADOW_STACK_DISABLE.

Architectures can choose to implement or not but I think arch agnostic
code should enumerate this.

> +# define PR_SHADOW_STACK_WRITE         (1UL << 1)
> +# define PR_SHADOW_STACK_PUSH          (1UL << 2)
> +
> +/*
> + * Prevent further changes to the specified shadow stack
> + * configuration.  All bits may be locked via this call, including
> + * undefined bits.
> + */


From wahrenst at gmx.net  Tue Dec 12 11:16:42 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Tue, 12 Dec 2023 20:16:42 +0100
Subject: [PATCH V4 0/3] ARM: dts: bcm2711: Add BCM2711 xHCI support
In-Reply-To: <20231212190904.igxm2twvftokhdwr@mraw.org>
References: <20231205200531.8232-1-wahrenst@gmx.net>
 <20231212190904.igxm2twvftokhdwr@mraw.org>
Message-ID: <6f5ced56-94fb-43dc-859d-42398624cd55@gmx.net>

Hi Cyril,

Am 12.12.23 um 20:09 schrieb Cyril Brulebois:
> Stefan Wahren <wahrenst at gmx.net> (2023-12-05):
>> In contrast to the Raspberry Pi 4, the Compute Module 4 or the IO board
>> does not have a VL805 USB 3.0 host controller, which is connected via
>> PCIe. Instead, the Compute Module provides the built-in
>> xHCI of the BCM2711 SoC.
>>
>> Changes in V4:
>> - use "brcm,xhci-brcm-v2" as fallback compatible as suggested by
>>    Conor & Florian
>>
>> Changes in V3:
>> - introduce a new compatible for BCM2711 in order to make the
>>    power domain dependency SoC specific, which also results in
>>    a driver change
> This is still:
>
> Tested-by: Cyril Brulebois <cyril at debamax.com>
thank you very much for your efforts. The series has been already
applied by Greg.

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/log/?h=usb-next
>
>
> Again, I'm also applying Jim Quinlan's PCIe patch series v8, to be able
> to fully test what happens with USB devices, onboard and behind PCIe:
>    https://lore.kernel.org/all/20231126201946.ffm3bhg5du2xgztv at mraw.org/
>
> With the following on a CM4 IO Board, with a Samsung flash drive and a
> USB keyboard connected to onboard USB ports:
>   - CM4 Lite Rev 1.0
>   - CM4 8/32 Rev 1.0
>   - CM4 4/32 Rev 1.1
>
> and using one of the three PCIe-to-USB boards referenced previously,
> connecting another Samsung flash drive on one of its USB ports.
>
> Conclusion: I can see and use onboard USB devices alongside behind-PCIe
> USB devices, either with or without adding otg_mode=1 to config.txt.
>
> On a CM4-based product that uses both onboard USB ports and PCIe-to-USB
> ports, all USB components still work fine (3 RF adapters, 1 modem), with
> or without otg_mode=1.
>
> (All of this is still with a Debian 12 arm64 user space.)
>
>
> Cheers,
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From broonie at kernel.org  Tue Dec 12 11:22:24 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 12 Dec 2023 19:22:24 +0000
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <CAKC1njSC5cC_fXnyNAPt=WU6cD-OjLKFxo90oVPmsLJbuWf4nw@mail.gmail.com>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
 <CAKC1njSC5cC_fXnyNAPt=WU6cD-OjLKFxo90oVPmsLJbuWf4nw@mail.gmail.com>
Message-ID: <d708b493-267a-4418-be91-9bde6b2cf50c@sirena.org.uk>

On Tue, Dec 12, 2023 at 11:17:11AM -0800, Deepak Gupta wrote:
> On Wed, Nov 22, 2023 at 1:43?AM Mark Brown <broonie at kernel.org> wrote:

> > +/*
> > + * Set the current shadow stack configuration.  Enabling the shadow
> > + * stack will cause a shadow stack to be allocated for the thread.
> > + */
> > +#define PR_SET_SHADOW_STACK_STATUS      72
> > +# define PR_SHADOW_STACK_ENABLE         (1UL << 0)

> Other architecture may require disabling shadow stack if glibc
> tunables is set to permissive mode.
> In permissive mode, if glibc encounters `dlopen` on an object which
> doesn't support shadow stack,
> glibc should be able to issue PR_SHADOW_STACK_DISABLE.

> Architectures can choose to implement or not but I think arch agnostic
> code should enumerate this.

The current implementation for arm64 and therefore API for the prctl()
is that whatever combination of flags is specified will be set, this
means that setting the status to something that does not include _ENABLE
will result in disabling and we don't need a separate flag for disable.
We have use cases that make active use of disabling at runtime.

Please delete unneeded context from replies, it makes it much easier to
find new content.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/fc139f1a/attachment.sig>

From retpolanne at posteo.net  Tue Dec 12 11:27:14 2023
From: retpolanne at posteo.net (Anne Macedo)
Date: Tue, 12 Dec 2023 19:27:14 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <20231212162200.10b3868b@donnerap.manchester.arm.com>
References: <20231212122835.10850-2-retpolanne@posteo.net>
 <20231212162200.10b3868b@donnerap.manchester.arm.com>
Message-ID: <axsvii25yrknfae6gdreti7lcskoscsdbsujwuispiieimsbdy@gwzm4l7mwlew>

On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:
> On Tue, 12 Dec 2023 12:28:30 +0000
> Anne Macedo <retpolanne at posteo.net> wrote:
> 
> Hi Anne,
> 
> > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > Realtek 8211 PHY to Orange Pi One Plus.
> 
> So can you state why this would be needed? This is the RTL8211 ID,

Apologies, I completely forgot to include some context. 

> right? Which should be autodetected via MDIO. Looking back in my inbox
> you proposed this change before, for U-Boot, specifically, but I fail to
> find a solution or explanation what really happens here. Two Renesas .dts
> files have the same compatible, and the commit message talks about the
> reset line there, is this related?
> 
> So can you please give some more background and explanation? That would be
> part of a good commit message anyway ("why", not "what").

Should I resend the commit with a more meaningful explanation? The
context is the following:

currently, ethernet doesn't seem to work on both u-boot and Linux on the
Orange Pi One Plus board. 

On the kernel, this error shows up:

Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)

After applying this fix, the PHY gets attached: 

Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)

The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
to find a PHY, so this patch includes the correct PHY ID with the
RTL8211 ID. 

The behaviour is described on [1]. U-boot fails completely if the
correct PHY ID is not correct, and in order to fix U-boot we need to fix
the upstream dts [2].

[1] https://elixir.bootlin.com/linux/v4.14/source/Documentation/devicetree/bindings/net/phy.txt#L20
[2] https://elixir.bootlin.com/u-boot/latest/source/drivers/core/ofnode.c#L1258

> 
> Cheers,
> Andre
> 
> > Signed-off-by: Anne Macedo <retpolanne at posteo.net>
> > ---
> >  arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
> > index 29a081e72..7248ab72f 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
> > @@ -37,7 +37,8 @@ &emac {
> >  
> >  &mdio {
> >  	ext_rgmii_phy: ethernet-phy at 1 {
> > -		compatible = "ethernet-phy-ieee802.3-c22";
> > +		compatible = "ethernet-phy-id001c.c915",
> > +			     "ethernet-phy-ieee802.3-c22";
> >  		reg = <1>;
> >  	};
> >  };
> 

Regards, Anne


From stern at rowland.harvard.edu  Tue Dec 12 11:31:31 2023
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 12 Dec 2023 14:31:31 -0500
Subject: [PATCH 3/6] usb: cdns3-ti: add suspend/resume procedures for
 J7200
In-Reply-To: <7h7cljcm6a.fsf@baylibre.com>
References: <CX0GOP07I40N.198G7LJ0HYDBG@tleb-bootlin-xps13-01>
 <bdea68ad-7523-4738-8fa1-b670d81a6b93@kernel.org>
 <CX10D9YX1O1C.30PF317AG065N@tleb-bootlin-xps13-01>
 <3e00b2ad-b58f-4b09-9230-683c58d3bb92@kernel.org>
 <CX15J7B8F8HH.1WZ10OOW31X1H@tleb-bootlin-xps13-01>
 <7h34wxfmwn.fsf@baylibre.com>
 <CX63KP2UPL1N.J9Q344Q06IGP@tleb-bootlin-xps13-01>
 <7hil5odtwl.fsf@baylibre.com>
 <CX9MMPFL7HAY.NGULD1FN5WPN@tleb-bootlin-xps13-01>
 <7h7cljcm6a.fsf@baylibre.com>
Message-ID: <ae99430d-12a3-4831-b4b7-586d6d045b15@rowland.harvard.edu>

On Tue, Dec 12, 2023 at 10:26:05AM -0800, Kevin Hilman wrote:
> Th?o Lebrun <theo.lebrun at bootlin.com> writes:

> 
> > Hello,
> >
> > On Sun Nov 26, 2023 at 11:36 PM CET, Kevin Hilman wrote:
> >> Th?o Lebrun <theo.lebrun at bootlin.com> writes:
> >> > On Wed Nov 22, 2023 at 11:23 PM CET, Kevin Hilman wrote:
> >> >> Th?o Lebrun <theo.lebrun at bootlin.com> writes:
> >> >> The point is to signal to the power domain the device is in that it can
> >> >> power on/off.  These IP blocks are (re)used on many different SoCs, so
> >> >> the driver should not make any assumptions about what power domain it is
> >> >> in (if any.)
> >> >
> >> > On my platform, when the device is attached to the PD it gets turned on.
> >> > That feels logical to me: if a driver is not RPM aware it "just works".
> >>
> >> It "just works"... until the domain gets turned off.
> >>
> >> > Are there platforms where RPM must get enabled for the attached
> >> > power-domains to be turned on?
> >>
> >> Yes, but but more importantly, there are platforms where RPM must get
> >> enabled for the power domain to *stay* on.  For example, the power
> >> domain might get turned on due to devices probing etc, but as soon as
> >> all the RPM-enabled drivers drop their refcount, the domain will turn
> >> off.  If there is a device in that domain with a non-RPM enabled driver,
> >> that device will be powered off anc cause a crash.
> >
> > OK, that makes sense, thanks for taking the time to explain. This topic
> > makes me see two things that I feel are close to being bugs. I'd be
> > curious to get your view on both.
> 
> TL;DR; they are features, not bugs.  ;)
> 
> >  - If a device does not use RPM but its children do, it might get its
> >    associated power-domain turned off. That forces every single driver
> >    that want to stay alive to enable & increment RPM.
> >
> >    What I naively expect: a genpd with a device attached to it that is
> >    not using RPM should mean that it should not be powered off at
> >    runtime_suspend. Benefit: no RPM calls in drivers that do not use
> >    it, and the behavior is that the genpd associated stays alive "as
> >    expected".
> 
> Your expectation makes sense, but unfortunately, that's not how RPM was
> designed.

I'm not sure how runtime PM is meant to work with power domains.  

However, from the very beginning of runtime PM the intention was that 
device drivers and subsystems could safely ignore it.  Their devices 
would have a permanently nonzero disable_depth (permanent because the 
driver/subsystem would not know to change it) and therefore would always 
remain in the active state (see rpm_check_suspend_allowed()).

It would be very surprising if runtime PM for power domains was written 
in a way that would subvert this intention.

Alan Stern


From tglx at linutronix.de  Tue Dec 12 11:32:50 2023
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 12 Dec 2023 20:32:50 +0100
Subject: [PATCH 2/2] pinctrl: stm32: fix GPIO level interrupts
In-Reply-To: <ZXh9rIyy6mu9zFry@dell-precision-5540>
References: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>
 <20231204203357.2897008-3-ben.wolsieffer@hefring.com>
 <87ttosqvbq.ffs@tglx> <ZXh9rIyy6mu9zFry@dell-precision-5540>
Message-ID: <87il53p671.ffs@tglx>

Ben!

On Tue, Dec 12 2023 at 10:35, Ben Wolsieffer wrote:
> On Fri, Dec 08, 2023 at 09:43:21PM +0100, Thomas Gleixner wrote:
>> On Mon, Dec 04 2023 at 15:33, Ben Wolsieffer wrote:
>> > The STM32 doesn't support GPIO level interrupts in hardware, so the
>> > driver tries to emulate them using edge interrupts, by retriggering the
>> > interrupt if necessary based on the pin state after the handler
>> > finishes.
>> >
>> > Currently, this functionality does not work because the irqchip uses
>> > handle_edge_irq(), which doesn't run the irq_eoi() or irq_unmask()
>> > callbacks after handling the interrupt. This patch fixes this by using
>> > handle_level_irq() for level interrupts, which causes irq_unmask() to be
>> > called to retrigger the interrupt.
>> 
>> This does not make any sense at all. irq_unmask() does not retrigger
>> anything. It sets the corresponding bit in the mask register, not more
>> not less.
>
> I don't think this is correct. I was referring to
> stm32_gpio_irq_unmask(), which calls stm32_gpio_irq_trigger(), which in
> turn (for level interrupts) checks the GPIO pin state and retriggers the
> interrupt if necessary.

Ah. That makes a lot more sense. Sorry that I missed that driver
detail. The changelog could mention explicitely where the retrigger
comes from. 

>> Switching to handle_level_irq() makes the following difference
>> vs. handle_edge_irq() when an interrupt is handled (ignoring the inner
>> loop):
>> 
>>       + irq_mask();
>>         irq_ack();
>>         ....
>>         handle();
>>         ....
>>       + irq_unmask();
>
> Yes, the additional call to irq_unmask() is the key difference here, as
> that callback performs the retriggering for level interrupts.

Sorry to be pedantic here. irq_unmask() is a function in the interrupt
core code which eventually ends up invoking the irqchip::irq_unmask().

>> When the interrupt is raised again after irq_ack() while the handler is
>> running, i.e. a full toggle from active to inactive and back to active
>> where the back to active transition causes the edge detector to trigger,
>> then:
>
> I don't see how this is relevant. The bug occurs with level interrupts
> in the case where there are no new transitions while the handler is
> running. For example, with a high level interrupt, if the pin is still
> high after the handler finishes, the interrupt should be immediately
> triggered again.

Ah. That's the problem you are trying to solve. Now we are getting
closer to a proper description :)

>> But in fact the regular exti driver could do the same and just handle
>> the two NVIC interrupts which need demultiplexing separately and let
>> everything else go through the hierarchy without bells and whistles.
>
> This sounds reasonable to me. It did seem strange to me that the exti
> and exti_h drivers used such different approaches, although I wasn't
> aware of the reasons behind them. I think this refactoring is out of
> scope of this bug fix though.

Sure. It just occured to me while looking at this stuff..

Care to resend with a proper explanation in the changelog?

Thanks,

        tglx


From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:38:40 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:38:40 +0100
Subject: [PATCH v7 08/16] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <CADrjBPrkso2cM8zKq-WU8WC3P3A9YoS6nqX-f6XvSNS-EofK9g@mail.gmail.com>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-9-peter.griffin@linaro.org>
 <CAL_JsqJ_NUajmQs8ZYiE2GpvNxBwtkLRE2jvWDU3hKtztt92Ug@mail.gmail.com>
 <CADrjBPrkso2cM8zKq-WU8WC3P3A9YoS6nqX-f6XvSNS-EofK9g@mail.gmail.com>
Message-ID: <d23cc32c-8a5b-48aa-be4d-608fbbb9ac3a@linaro.org>

On 11/12/2023 20:46, Peter Griffin wrote:
>>> +#include <linux/platform_device.h>
> 
> You are correct, this header isn't required. If a new series is
> required I will remove it.

I dropped it while applying.

> 
> Whilst you're here I'd like to draw your attention to [PATCH 2/16]
> where I've removed your reviewed-by tag in v7 because I added the ect
> node documentation in google.yaml. The empty ect node is required to
> be present by the bootloader or the device will boot loop. Can you
> re-review that patch?
> 
> The alternative is to remove the empty ect node, and the binding
> documentation for it and add your Reviewed-by tag back again. But then
> an upstream kernel won't boot 'out the box' on a pixel 6 which seems
> less than ideal default behaviour.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:39:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:39:12 +0100
Subject: (subset) [PATCH v7 03/16] dt-bindings: serial: samsung: Add google-gs101-uart compatible
In-Reply-To: <20231211162331.435900-4-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-4-peter.griffin@linaro.org>
Message-ID: <170240988143.242356.7915762427739298874.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:18 +0000, Peter Griffin wrote:
> Add dedicated google-gs101-uart compatible to the dt-schema for
> representing uart of the Google Tensor gs101 SoC.
> 
> 

Applied, thanks!

[03/16] dt-bindings: serial: samsung: Add google-gs101-uart compatible
        https://git.kernel.org/krzk/linux/c/bad3bc0a23b74e7b353978b6f58eed6c0f3b51a0

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:39:11 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:39:11 +0100
Subject: (subset) [PATCH v7 01/16] dt-bindings: watchdog: Document Google gs101 watchdog bindings
In-Reply-To: <20231211162331.435900-2-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-2-peter.griffin@linaro.org>
Message-ID: <170240988143.242356.11503491743323659918.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:16 +0000, Peter Griffin wrote:
> Add the "google,gs101-wdt" compatible to the dt-schema documentation.
> 
> gs101 SoC has two CPU clusters and each cluster has its own dedicated
> watchdog timer (similar to exynos850 and exynosautov9 SoCs).
> 
> These WDT instances are controlled using different bits in PMU
> registers.
> 
> [...]

Applied, thanks!

[01/16] dt-bindings: watchdog: Document Google gs101 watchdog bindings
        https://git.kernel.org/krzk/linux/c/81306efd22fff7eecf4e62919283dd27111f0173

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:39:13 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:39:13 +0100
Subject: (subset) [PATCH v7 04/16] dt-bindings: serial: samsung: Make samsung,uart-fifosize a required property
In-Reply-To: <20231211162331.435900-5-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-5-peter.griffin@linaro.org>
Message-ID: <170240988143.242356.13785462377089230139.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:19 +0000, Peter Griffin wrote:
> Specifying samsung,uart-fifosize in both DT and driver static data is error
> prone and relies on driver probe order and dt aliases to be correct.
> 
> Additionally on many Exynos platforms these are (USI) universal serial
> interfaces which can be uart, spi or i2c, so it can change per board.
> 
> For google,gs101-uart make samsung,uart-fifosize a required property.
> For this platform fifosize now *only* comes from DT.
> 
> [...]

Applied, thanks!

[04/16] dt-bindings: serial: samsung: Make samsung,uart-fifosize a required property
        https://git.kernel.org/krzk/linux/c/2072496129b7d7448f969b6334b4fd2e876a642d

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:39:14 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:39:14 +0100
Subject: (subset) [PATCH v7 05/16] dt-bindings: soc: samsung: usi: add google,gs101-usi compatible
In-Reply-To: <20231211162331.435900-6-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-6-peter.griffin@linaro.org>
Message-ID: <170240988144.242356.15535258892382463057.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:20 +0000, Peter Griffin wrote:
> Add google,gs101-usi dedicated compatible for representing USI of Google
> GS101 SoC.
> 
> 

Applied, thanks!

[05/16] dt-bindings: soc: samsung: usi: add google,gs101-usi compatible
        https://git.kernel.org/krzk/linux/c/d793f7c471fb1cc9b5cf5aee5484f4231ef48dc8

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:39:15 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:39:15 +0100
Subject: (subset) [PATCH v7 06/16] dt-bindings: clock: google,gs101: fix incorrect numbering and DGB suffix
In-Reply-To: <20231211162331.435900-7-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-7-peter.griffin@linaro.org>
Message-ID: <170240988142.242356.6771839605538323982.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:21 +0000, Peter Griffin wrote:
> 166 was skipped by mistake and two clocks:
> * CLK_MOUT_CMU_HSI0_USBDPDGB
> * CLK_GOUT_HSI0_USBDPDGB
> 
> Have an incorrect DGB ending instead of DBG.
> 
> This is an ABI break, but as the patch was only applied yesterday this
> header has never been in an actual release so it seems better to fix
> this early than ignore it.
> 
> [...]

Applied, thanks!

[06/16] dt-bindings: clock: google,gs101: fix incorrect numbering and DGB suffix
        https://git.kernel.org/krzk/linux/c/5b02a863ba502482f25ae3a1bfa259838793785b

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:39:16 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:39:16 +0100
Subject: (subset) [PATCH v7 07/16] clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
In-Reply-To: <20231211162331.435900-8-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-8-peter.griffin@linaro.org>
Message-ID: <170240988142.242356.3792346192498410733.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:22 +0000, Peter Griffin wrote:
> These plls are found in the Tensor gs101 SoC found in the Pixel 6.
> 
> pll0516x: Integer PLL with high frequency
> pll0517x: Integer PLL with middle frequency
> pll0518x: Integer PLL with low frequency
> 
> PLL0516x
> FOUT = (MDIV * 2 * FIN)/PDIV * 2^SDIV)
> 
> [...]

Applied, thanks!

[07/16] clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
        https://git.kernel.org/krzk/linux/c/13ff3bdafdd569e62e59330de18aae25ec15c97b

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:39:17 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:39:17 +0100
Subject: (subset) [PATCH v7 08/16] clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm support
In-Reply-To: <20231211162331.435900-9-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-9-peter.griffin@linaro.org>
Message-ID: <170240988142.242356.6873777616992390636.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:23 +0000, Peter Griffin wrote:
> cmu_top is the top level clock management unit which contains PLLs, muxes,
> dividers and gates that feed the other clock management units.
> 
> cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the
> APM module.
> 
> 
> [...]

Applied, thanks!

Dropped the header, pointed out by Rob.

[08/16] clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm support
        https://git.kernel.org/krzk/linux/c/2c597bb7d66a55f2af2fff9bf4629dd07b3b9a1e

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From krzysztof.kozlowski at linaro.org  Tue Dec 12 11:39:18 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 20:39:18 +0100
Subject: (subset) [PATCH v7 13/16] tty: serial: samsung: Add gs101 compatible and common fifoszdt_serial_drv_data
In-Reply-To: <20231211162331.435900-14-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org> <20231211162331.435900-14-peter.griffin@linaro.org>
Message-ID: <170240988144.242356.2200926663420450424.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:28 +0000, Peter Griffin wrote:
> Add serial driver data for Google Tensor gs101 SoC and a common
> fifoszdt_serial_drv_data that can be used by platforms that specify the
> samsung,uart-fifosize DT property.
> 
> A corresponding dt-bindings patch updates the yaml to ensure
> samsung,uart-fifosize is a required property.
> 
> [...]

Applied, thanks!

[13/16] tty: serial: samsung: Add gs101 compatible and common fifoszdt_serial_drv_data
        https://git.kernel.org/krzk/linux/c/c95f5b21a0eaa4a2701c28e2b209f9a7e09cd4f0

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From peter.griffin at linaro.org  Tue Dec 12 11:43:51 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Tue, 12 Dec 2023 19:43:51 +0000
Subject: [PATCH v7 08/16] clk: samsung: clk-gs101: Add cmu_top, cmu_misc
 and cmu_apm support
In-Reply-To: <d23cc32c-8a5b-48aa-be4d-608fbbb9ac3a@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-9-peter.griffin@linaro.org> <CAL_JsqJ_NUajmQs8ZYiE2GpvNxBwtkLRE2jvWDU3hKtztt92Ug@mail.gmail.com>
 <CADrjBPrkso2cM8zKq-WU8WC3P3A9YoS6nqX-f6XvSNS-EofK9g@mail.gmail.com> <d23cc32c-8a5b-48aa-be4d-608fbbb9ac3a@linaro.org>
Message-ID: <CADrjBPoireQMauac4D4d0Ry+PBBUUF=s0Lozp50KLz2y6ZLHKw@mail.gmail.com>

On Tue, 12 Dec 2023 at 19:38, Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> On 11/12/2023 20:46, Peter Griffin wrote:
> >>> +#include <linux/platform_device.h>
> >
> > You are correct, this header isn't required. If a new series is
> > required I will remove it.
>
> I dropped it while applying.

Thanks Krzysztof :)


From linux at roeck-us.net  Tue Dec 12 11:50:00 2023
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 12 Dec 2023 11:50:00 -0800
Subject: [PATCH v1 7/8] tpm: tis-i2c: Add more compatible strings
In-Reply-To: <20231212-mouth-choice-40a83caa34ec@spud>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-8-ninad@linux.ibm.com>
 <20231212-avid-grill-dbead068fac8@spud>
 <73381bb0-7fa7-4a9e-88df-ab0063058e26@roeck-us.net>
 <20231212-mouth-choice-40a83caa34ec@spud>
Message-ID: <2946fbb1-2a47-4d21-83dc-8e45bf6ba5a9@roeck-us.net>

On 12/12/23 10:51, Conor Dooley wrote:
> On Tue, Dec 12, 2023 at 10:00:39AM -0800, Guenter Roeck wrote:
>> On Tue, Dec 12, 2023 at 05:15:51PM +0000, Conor Dooley wrote:
>>> On Tue, Dec 12, 2023 at 10:40:03AM -0600, Ninad Palsule wrote:
>>>> From: Joel Stanley <joel at jms.id.au>
>>>>
>>>> The NPCT75x TPM is TIS compatible. It has an I2C and SPI interface.
>>>>
>>>> https://www.nuvoton.com/products/cloud-computing/security/trusted-platform-module-tpm/
>>>>
>>>> Add a compatible string for it, and the generic compatible.
>>>>
>>>> OpenBMC-Staging-Count: 3
>>>
>>> Delete this from every patch that it appears from.
>>>
>>>> Signed-off-by: Joel Stanley <joel at jms.id.au>
>>>> Acked-by: Jarkko Sakkinen <jarkko at kernel.org>
>>>> Link: https://lore.kernel.org/r/20220928043957.2636877-4-joel at jms.id.au
>>>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>>>> ---
>>>>   drivers/char/tpm/tpm_tis_i2c.c | 2 ++
>>>>   1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/char/tpm/tpm_tis_i2c.c b/drivers/char/tpm/tpm_tis_i2c.c
>>>> index a897402cc36a..9511c0d50185 100644
>>>> --- a/drivers/char/tpm/tpm_tis_i2c.c
>>>> +++ b/drivers/char/tpm/tpm_tis_i2c.c
>>>> @@ -383,6 +383,8 @@ MODULE_DEVICE_TABLE(i2c, tpm_tis_i2c_id);
>>>>   #ifdef CONFIG_OF
>>>>   static const struct of_device_id of_tis_i2c_match[] = {
>>>>   	{ .compatible = "infineon,slb9673", },
>>>> +	{ .compatible = "nuvoton,npct75x", },
>>>> +	{ .compatible = "tcg,tpm-tis-i2c", },
>>>
>>> What's the point of the generic compatible if you are adding the device
>>> specific ones to the driver anyway?
>>>
>>
>> $ git grep infineon,slb9673
>> Documentation/devicetree/bindings/trivial-devices.yaml:          - infineon,slb9673
> 
> Hmm, this would then need to be moved into the new schema, out of
> trivial devices.
> 
>> drivers/char/tpm/tpm_tis_i2c.c: { .compatible = "infineon,slb9673", },
>> $ git grep nuvoton,npct75x
>> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
>> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
>> $ git grep tcg,tpm-tis-i2c
>> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
>> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts:            compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
>> arch/arm/boot/dts/aspeed/aspeed-bmc-opp-tacoma.dts:             compatible = "tcg,tpm-tis-i2c";
> 
> pog, undocumented compatibles.
> 

Yes, I know, quite annoying. Though, to be fair, a generic "tcg,tpm-tis-i2c"
would make a lot of sense.

Note that Rob had rejected the original addition (into trivial devices)
with the argument that it is not a trivial device
(https://lore.kernel.org/lkml/20220605225610.GA3682221-robh at kernel.org/).

>> It looks like at least the generic entry is needed, given that it is quite
>> likely that there is hardware out there using it. Other than that, this
>> makes me wonder: Is there some official guideline describing if and when
>> to use (only) generic devicetree compatible entries and when specific ones
>> may / should / have to be used ? I suspect the answer to your question might
>> simply be "because we did not know better", and it might be helpful to be
>> able to say "please see XXX for details".
> 
> To me using generic compatibles is okay when there is another mechanism
> to identify the device. This patch would make more sense if the addition
> of nuvoton,npct75x was omitted and the dt-binding had
> 
> properties:
>    compatible:
>      items:
>        - enum:
>            - infineon,slb9673
>            - nuvoton,npct75x
>        - const: tcg,tpm-tis-i2c
> 
> And whenever new i2c tpms showed up the device specific compatible was
> added to the bindings and the driver had only* the generic compatible
> static const struct of_device_id of_tis_i2c_match[] = {
> 	{ .compatible = "infineon,slb9673", },
> 	{ .compatible = "tcg,tpm-tis-i2c", },
> };
> 
> * well, and the existing one since that cannot be removed.

That would be perfectly fine with me. All I personally care about is to get
"tcg,tpm-tis-i2c" added to the kernel source so I can start testing the
code in qemu.

Thanks,
Guenter



From linux at armlinux.org.uk  Tue Dec 12 11:58:46 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Tue, 12 Dec 2023 19:58:46 +0000
Subject: [RFC PATCH v3 00/39] ACPI/arm64: add support for virtual
 cpuhotplug
In-Reply-To: <ZW4ZBkj2oCmxv55T@shell.armlinux.org.uk>
References: <ZTffkAdOqL2pI2la@shell.armlinux.org.uk>
 <CAJZ5v0j-73_+9U3ngDAf9w1ADDhBTKctJdWboqUk-okH2TQGyg@mail.gmail.com>
 <ZW4ZBkj2oCmxv55T@shell.armlinux.org.uk>
Message-ID: <ZXi7do4mVfdsz/k0@shell.armlinux.org.uk>

On Mon, Dec 04, 2023 at 06:23:02PM +0000, Russell King (Oracle) wrote:
> On Tue, Oct 24, 2023 at 08:26:58PM +0200, Rafael J. Wysocki wrote:
> > On Tue, Oct 24, 2023 at 5:15?PM Russell King (Oracle)
> > <linux at armlinux.org.uk> wrote:
> > >
> > > Hi,
> > >
> > > I'm posting James' patch set updated with most of the review comments
> > > from his RFC v2 series back in September. Individual patches have a
> > > changelog attached at the bottom of the commit message. Those which
> > > I have finished updating have my S-o-b on them, those which still have
> > > outstanding review comments from RFC v2 do not. In some of these cases
> > > I've asked questions and am waiting for responses.
> > >
> > > I'm posting this as RFC v3 because there's still some unaddressed
> > > comments and it's clearly not ready for merging. Even if it was ready
> > > to be merged, it is too late in this development cycle to be taking
> > > this change in, so there would be little point posting it non-RFC.
> > > Also James stated that he's waiting for confirmation from the
> > > Kubernetes/Kata folk - I have no idea what the status is there.
> > >
> > > I will be sending each patch individually to a wider audience
> > > appropriate for that patch - apologies to those missing out on this
> > > cover message. I have added more mailing lists to the series with the
> > > exception of the acpica list in a hope of this cover message also
> > > reaching those folk.
> > >
> > > The changes that aren't included are:
> > >
> > > 1. Updates for my patch that was merged via Thomas (thanks!):
> > >    c4dd854f740c cpu-hotplug: Provide prototypes for arch CPU registration
> > >    rather than having this change spread through James' patches.
> > >
> > > 2. New patch - simplification of PA-RISC's smp_prepare_boot_cpu()
> > >
> > > 3. Moved "ACPI: Use the acpi_device_is_present() helper in more places"
> > >    and "ACPI: Rename acpi_scan_device_not_present() to be about
> > >    enumeration" to the beginning of the series - these two patches are
> > >    already queued up for merging into 6.7.
> > >
> > > 4. Moved "arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into
> > >    a helper" to the beginning of the series, which has been submitted,
> > >    but as yet the fate of that posting isn't known.
> > >
> > > The first four patches in this series are provided for completness only.
> > >
> > > There is an additional patch in James' git tree that isn't in the set
> > > of patches that James posted: "ACPI: processor: Only call
> > > arch_unregister_cpu() if HOTPLUG_CPU is selected" which looks to me to
> > > be a workaround for arch_unregister_cpu() being under the ifdef. I've
> > > commented on this on the RFC v2 posting making a suggestion, but as yet
> > > haven't had any response.
> > >
> > > I've included almost all of James' original covering body below the
> > > diffstat.
> > >
> > > The reason that I'm doing this is to help move this code forward so
> > > hopefully it can be merged - which is why I have been keen to dig out
> > > from James' patches anything that can be merged and submit it
> > > separately, since this is a feature for which some users have a
> > > definite need for.
> > 
> > I've gone through the series and there is at least one thing in it
> > that concerns me a lot and some others that at least appear to be
> > really questionable.
> > 
> > I need more time to send comments which I'm not going to do before the
> > 6.7 merge window (sorry), but from what I can say right now, this is
> > not looking good.
> 
> Hi Rafael,
> 
> Will you be able to send your comments, so that we can find out what
> your other concerns are please? I'm getting questions from interested
> parties who want to know what your concerns are.
> 
> Nothing much has changed to the ACPI changes, so I think it's still
> valid to have the comments back for this.

Hi Rafael,

Another gentle prod on this...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From irogers at google.com  Tue Dec 12 12:02:52 2023
From: irogers at google.com (Ian Rogers)
Date: Tue, 12 Dec 2023 12:02:52 -0800
Subject: [PATCH v1 06/14] libperf cpumap: Add any, empty and min helpers
In-Reply-To: <63d7fe55-719e-43f8-531c-eb7fa30c473a@arm.com>
References: <20231129060211.1890454-1-irogers@google.com> <20231129060211.1890454-7-irogers@google.com>
 <63d7fe55-719e-43f8-531c-eb7fa30c473a@arm.com>
Message-ID: <CAP-5=fXenjeSDcOiQPq0xUyZSpb9PiQ_W7=FVx5oYNYd--RqCA@mail.gmail.com>

On Tue, Dec 12, 2023 at 6:01?AM James Clark <james.clark at arm.com> wrote:
>
>
>
> On 29/11/2023 06:02, Ian Rogers wrote:
> > Additional helpers to better replace
> > perf_cpu_map__has_any_cpu_or_is_empty.
> >
> > Signed-off-by: Ian Rogers <irogers at google.com>
> > ---
> >  tools/lib/perf/cpumap.c              | 27 +++++++++++++++++++++++++++
> >  tools/lib/perf/include/perf/cpumap.h | 16 ++++++++++++++++
> >  tools/lib/perf/libperf.map           |  4 ++++
> >  3 files changed, 47 insertions(+)
> >
> > diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
> > index 49fc98e16514..7403819da8fd 100644
> > --- a/tools/lib/perf/cpumap.c
> > +++ b/tools/lib/perf/cpumap.c
> > @@ -316,6 +316,19 @@ bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map)
> >       return map ? __perf_cpu_map__cpu(map, 0).cpu == -1 : true;
> >  }
> >
> > +bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map)
> > +{
> > +     if (!map)
> > +             return true;
> > +
> > +     return __perf_cpu_map__nr(map) == 1 && __perf_cpu_map__cpu(map, 0).cpu == -1;
> > +}
> > +
> > +bool perf_cpu_map__is_empty(const struct perf_cpu_map *map)
> > +{
> > +     return map == NULL;
> > +}
> > +
>
> Maybe it doesn't currently happen, but it seems a bit weird that the
> 'new' function can create a map of length 0 which would return empty ==
> false here.
>
> Could we either make this check also return true for maps with length 0,
> or prevent the new function from returning a map of 0 length?

We can add an assert or return NULL for size 0 in alloc. I think I
prefer the return NULL option. It should never happen but it feels the
right defensive thing to do.

Thanks,
Ian

> >  int perf_cpu_map__idx(const struct perf_cpu_map *cpus, struct perf_cpu cpu)
> >  {
> >       int low, high;
> > @@ -372,6 +385,20 @@ bool perf_cpu_map__has_any_cpu(const struct perf_cpu_map *map)
> >       return map && __perf_cpu_map__cpu(map, 0).cpu == -1;
> >  }
> >
> > +struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map)
> > +{
> > +     struct perf_cpu cpu, result = {
> > +             .cpu = -1
> > +     };
> > +     int idx;
> > +
> > +     perf_cpu_map__for_each_cpu_skip_any(cpu, idx, map) {
> > +             result = cpu;
> > +             break;
> > +     }
> > +     return result;
> > +}
> > +
> >  struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map)
> >  {
> >       struct perf_cpu result = {
> > diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> > index dbe0a7352b64..523e4348fc96 100644
> > --- a/tools/lib/perf/include/perf/cpumap.h
> > +++ b/tools/lib/perf/include/perf/cpumap.h
> > @@ -50,6 +50,22 @@ LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
> >   * perf_cpu_map__has_any_cpu_or_is_empty - is map either empty or has the "any CPU"/dummy value.
> >   */
> >  LIBPERF_API bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map);
> > +/**
> > + * perf_cpu_map__is_any_cpu_or_is_empty - is map either empty or the "any CPU"/dummy value.
> > + */
> > +LIBPERF_API bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map);
> > +/**
> > + * perf_cpu_map__is_empty - does the map contain no values and it doesn't
> > + *                          contain the special "any CPU"/dummy value.
> > + */
> > +LIBPERF_API bool perf_cpu_map__is_empty(const struct perf_cpu_map *map);
> > +/**
> > + * perf_cpu_map__min - the minimum CPU value or -1 if empty or just the "any CPU"/dummy value.
> > + */
> > +LIBPERF_API struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map);
> > +/**
> > + * perf_cpu_map__max - the maximum CPU value or -1 if empty or just the "any CPU"/dummy value.
> > + */
> >  LIBPERF_API struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map);
> >  LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, struct perf_cpu cpu);
> >  LIBPERF_API bool perf_cpu_map__equal(const struct perf_cpu_map *lhs,
> > diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> > index 10b3f3722642..2aa79b696032 100644
> > --- a/tools/lib/perf/libperf.map
> > +++ b/tools/lib/perf/libperf.map
> > @@ -10,6 +10,10 @@ LIBPERF_0.0.1 {
> >               perf_cpu_map__nr;
> >               perf_cpu_map__cpu;
> >               perf_cpu_map__has_any_cpu_or_is_empty;
> > +             perf_cpu_map__is_any_cpu_or_is_empty;
> > +             perf_cpu_map__is_empty;
> > +             perf_cpu_map__has_any_cpu;
> > +             perf_cpu_map__min;
> >               perf_cpu_map__max;
> >               perf_cpu_map__has;
> >               perf_thread_map__new_array;


From heiko at sntech.de  Tue Dec 12 12:03:14 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 12 Dec 2023 21:03:14 +0100
Subject: [PATCH 00/31] Fix and improve Rockchip RK3128 support
In-Reply-To: <20230829171647.187787-1-knaerzche@gmail.com>
References: <20230829171647.187787-1-knaerzche@gmail.com>
Message-ID: <2167016.irdbgypaU6@phil>

Hi Alex,

Am Dienstag, 29. August 2023, 19:16:16 CET schrieb Alex Bee:
> this series fixes some issues I found when testing my "new" RK3128 board
> with the mainline kernel and adds some core functionality like SMP bringup,
> usb and networking.

before I discard this thread, is everything from here migrated to
separate serieses or are there patches in this big pile that are still
relevant on their own, that haven't been applied?
[I lost track of what did go where ;-) ]


Thanks
Heiko




From rafael at kernel.org  Tue Dec 12 12:05:14 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Tue, 12 Dec 2023 21:05:14 +0100
Subject: [RFC PATCH v3 00/39] ACPI/arm64: add support for virtual cpuhotplug
In-Reply-To: <ZXi7do4mVfdsz/k0@shell.armlinux.org.uk>
References: <ZTffkAdOqL2pI2la@shell.armlinux.org.uk> <CAJZ5v0j-73_+9U3ngDAf9w1ADDhBTKctJdWboqUk-okH2TQGyg@mail.gmail.com>
 <ZW4ZBkj2oCmxv55T@shell.armlinux.org.uk> <ZXi7do4mVfdsz/k0@shell.armlinux.org.uk>
Message-ID: <CAJZ5v0jOU4Re2g5QtxpG0RjP3MYBxqz5Z+TtfXq2dz8HTq9A0A@mail.gmail.com>

On Tue, Dec 12, 2023 at 8:58?PM Russell King (Oracle)
<linux at armlinux.org.uk> wrote:
>
> On Mon, Dec 04, 2023 at 06:23:02PM +0000, Russell King (Oracle) wrote:
> > On Tue, Oct 24, 2023 at 08:26:58PM +0200, Rafael J. Wysocki wrote:
> > > On Tue, Oct 24, 2023 at 5:15?PM Russell King (Oracle)
> > > <linux at armlinux.org.uk> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm posting James' patch set updated with most of the review comments
> > > > from his RFC v2 series back in September. Individual patches have a
> > > > changelog attached at the bottom of the commit message. Those which
> > > > I have finished updating have my S-o-b on them, those which still have
> > > > outstanding review comments from RFC v2 do not. In some of these cases
> > > > I've asked questions and am waiting for responses.
> > > >
> > > > I'm posting this as RFC v3 because there's still some unaddressed
> > > > comments and it's clearly not ready for merging. Even if it was ready
> > > > to be merged, it is too late in this development cycle to be taking
> > > > this change in, so there would be little point posting it non-RFC.
> > > > Also James stated that he's waiting for confirmation from the
> > > > Kubernetes/Kata folk - I have no idea what the status is there.
> > > >
> > > > I will be sending each patch individually to a wider audience
> > > > appropriate for that patch - apologies to those missing out on this
> > > > cover message. I have added more mailing lists to the series with the
> > > > exception of the acpica list in a hope of this cover message also
> > > > reaching those folk.
> > > >
> > > > The changes that aren't included are:
> > > >
> > > > 1. Updates for my patch that was merged via Thomas (thanks!):
> > > >    c4dd854f740c cpu-hotplug: Provide prototypes for arch CPU registration
> > > >    rather than having this change spread through James' patches.
> > > >
> > > > 2. New patch - simplification of PA-RISC's smp_prepare_boot_cpu()
> > > >
> > > > 3. Moved "ACPI: Use the acpi_device_is_present() helper in more places"
> > > >    and "ACPI: Rename acpi_scan_device_not_present() to be about
> > > >    enumeration" to the beginning of the series - these two patches are
> > > >    already queued up for merging into 6.7.
> > > >
> > > > 4. Moved "arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into
> > > >    a helper" to the beginning of the series, which has been submitted,
> > > >    but as yet the fate of that posting isn't known.
> > > >
> > > > The first four patches in this series are provided for completness only.
> > > >
> > > > There is an additional patch in James' git tree that isn't in the set
> > > > of patches that James posted: "ACPI: processor: Only call
> > > > arch_unregister_cpu() if HOTPLUG_CPU is selected" which looks to me to
> > > > be a workaround for arch_unregister_cpu() being under the ifdef. I've
> > > > commented on this on the RFC v2 posting making a suggestion, but as yet
> > > > haven't had any response.
> > > >
> > > > I've included almost all of James' original covering body below the
> > > > diffstat.
> > > >
> > > > The reason that I'm doing this is to help move this code forward so
> > > > hopefully it can be merged - which is why I have been keen to dig out
> > > > from James' patches anything that can be merged and submit it
> > > > separately, since this is a feature for which some users have a
> > > > definite need for.
> > >
> > > I've gone through the series and there is at least one thing in it
> > > that concerns me a lot and some others that at least appear to be
> > > really questionable.
> > >
> > > I need more time to send comments which I'm not going to do before the
> > > 6.7 merge window (sorry), but from what I can say right now, this is
> > > not looking good.
> >
> > Hi Rafael,
> >
> > Will you be able to send your comments, so that we can find out what
> > your other concerns are please? I'm getting questions from interested
> > parties who want to know what your concerns are.
> >
> > Nothing much has changed to the ACPI changes, so I think it's still
> > valid to have the comments back for this.
>
> Hi Rafael,
>
> Another gentle prod on this...

There was a selection of the patches in the series sent separately and
I believe that some of them have been applied already.

Can you please send the remaining patches again so it is clear what's
still outstanding?


From ninad at linux.ibm.com  Tue Dec 12 12:06:40 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Tue, 12 Dec 2023 14:06:40 -0600
Subject: [PATCH v1 1/8] dt-bindings: arm: aspeed: add IBM system1-bmc
In-Reply-To: <20231212-thrower-ebook-d29a85a6ed96@spud>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-2-ninad@linux.ibm.com>
 <20231212-thrower-ebook-d29a85a6ed96@spud>
Message-ID: <2ddae2e4-de55-41a1-a93e-819f8d55dde6@linux.ibm.com>

Hello Conor,

On 12/12/23 11:09, Conor Dooley wrote:
> On Tue, Dec 12, 2023 at 10:39:57AM -0600, Ninad Palsule wrote:
>> Document the new compatibles used on IBM system1-bmc
>>
>> Tested:
>>      This board is tested using the simics simulator.
> I don't see how this is relevant to dt-bindings patches.
Make sense. Removed it.
>
>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>> ---
>>   Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
>>   Documentation/devicetree/bindings/trivial-devices.yaml   | 2 ++
> IMO these should be split into two patches.

Make sense. Split it into two patches.

Thank you for the review.

Thanks & Regards,

Ninad

>
> Cheers,
> Conor.
>
>>   2 files changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
>> index 6f7543463d89..ebebe14c42aa 100644
>> --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
>> +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
>> @@ -85,6 +85,7 @@ properties:
>>                 - facebook,yosemite4-bmc
>>                 - ibm,everest-bmc
>>                 - ibm,rainier-bmc
>> +              - ibm,system1-bmc
>>                 - ibm,tacoma-bmc
>>                 - inventec,starscream-bmc
>>                 - inventec,transformer-bmc
>> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
>> index 441b55723675..b12a60d2eb0f 100644
>> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
>> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
>> @@ -135,6 +135,8 @@ properties:
>>             - ibm,cffps1
>>               # IBM Common Form Factor Power Supply Versions 2
>>             - ibm,cffps2
>> +            # Infineon barometric pressure and temperature sensor
>> +          - infineon,dps310
>>               # Infineon IR36021 digital POL buck controller
>>             - infineon,ir36021
>>               # Infineon IR38060 Voltage Regulator
>> -- 
>> 2.39.2
>>


From heiko at sntech.de  Tue Dec 12 12:16:17 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 12 Dec 2023 21:16:17 +0100
Subject: [PATCH 0/4] Remove ethernetX aliases from the SoC dtsi for RK3399, RK3368, RK3328 and PX30
In-Reply-To: <cover.1702366958.git.dsimic@manjaro.org>
References: <cover.1702366958.git.dsimic@manjaro.org>
Message-ID: <170241214697.534713.17361998299651815805.b4-ty@sntech.de>

On Tue, 12 Dec 2023 08:53:47 +0100, Dragan Simic wrote:
> Unlike for the I2C buses, GPIO lines and UARTs, the Rockchip SoC TRMs and
> datasheets define no numbering for the built-in GMAC(s) or MAC(s), if there
> are more than one found in the particular Rockchip SoC.
> 
> Moreover, not all boards or devices based on these SoCs actually use the
> built-in GMAC(s) or MAC(s).  Thus, let's remove the ethernetX aliases from
> the SoC dtsi files and add them back to the appropriate board and device
> dts(i) files.  See also [1] for the initial discussion.
> 
> [...]

Applied, thanks!

[1/4] arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for RK3399
      commit: 8030063ca9b019f9dfb90a654f557d8bb15a97a5
[2/4] arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for RK3368
      commit: 7aab60df473c70f74880267500884b12151b160b
[3/4] arm64: dts: rockchip: Remove ethernetX aliases from the SoC dtsi for RK3328
      commit: 20a9a7667af6b11b7369073d0186d9c92e52db04
[4/4] arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for PX30
      commit: a69907a915e4c15bf7e632cd324ec5c3e38c3afc

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Tue Dec 12 12:16:16 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 12 Dec 2023 21:16:16 +0100
Subject: [PATCH 0/2] arm64: dts: rockchip: Add ethernet0 aliases to the dts files for RK3566 and RK3588(S) boards
In-Reply-To: <cover.1702368023.git.dsimic@manjaro.org>
References: <cover.1702368023.git.dsimic@manjaro.org>
Message-ID: <170241214697.534713.13455667285782606746.b4-ty@sntech.de>

On Tue, 12 Dec 2023 09:01:38 +0100, Dragan Simic wrote:
> To complete the process started with the migration of the ethernet0 aliases
> from the SoC dtsi files to the board/device dts(i) files, started in [1],
> let's add ethernet0 aliases to the board dts files that had it missing.
> See also [2] for a related discussion.
> 
> At the same time, let's remove the ethernet0 alias from one SoM dtsi file,
> which doesn't enable the GMAC, and add the same alias back to the dependent
> board dts files, which actually enable the GMAC.
> 
> [...]

Applied, thanks!

[1/2] arm64: dts: rockchip: Add ethernet0 alias to the dts for RK3566 boards
      commit: 8a5f97b061432f72002b8aa158e372f1b10a079e
[2/2] arm64: dts: rockchip: Add ethernet0 alias to the dts for RK3588(S) boards
      commit: a40d30460dda56c6ad308cb338e240bc4a625faa

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Tue Dec 12 12:16:18 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 12 Dec 2023 21:16:18 +0100
Subject: (subset) [PATCH v1 1/3] dt-bindings: drm: rockchip: convert inno_hdmi-rockchip.txt to yaml
In-Reply-To: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
References: <49c6afec-022f-02de-99a0-d409b64da198@gmail.com>
Message-ID: <170241214695.534713.7214465445904239057.b4-ty@sntech.de>

On Mon, 4 Dec 2023 18:39:03 +0100, Johan Jonker wrote:
> Convert inno_hdmi-rockchip.txt to yaml.
> 
> 

Applied, thanks!

[2/3] ARM: dts: rockchip: rk3036: fix hdmi ports node
      commit: 27ded76ef0fcfcf939914532aae575cf23c221b4
[3/3] ARM: dts: rockchip: rk3036-kylin: add hdmi-connector node
      commit: 569b26af7919c15a8ce231b4fae29cfbd811f144

And changed the connector-type to "a" :-)


Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From linux at armlinux.org.uk  Tue Dec 12 12:16:59 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Tue, 12 Dec 2023 20:16:59 +0000
Subject: [RFC PATCH v3 00/39] ACPI/arm64: add support for virtual
 cpuhotplug
In-Reply-To: <CAJZ5v0jOU4Re2g5QtxpG0RjP3MYBxqz5Z+TtfXq2dz8HTq9A0A@mail.gmail.com>
References: <ZTffkAdOqL2pI2la@shell.armlinux.org.uk>
 <CAJZ5v0j-73_+9U3ngDAf9w1ADDhBTKctJdWboqUk-okH2TQGyg@mail.gmail.com>
 <ZW4ZBkj2oCmxv55T@shell.armlinux.org.uk>
 <ZXi7do4mVfdsz/k0@shell.armlinux.org.uk>
 <CAJZ5v0jOU4Re2g5QtxpG0RjP3MYBxqz5Z+TtfXq2dz8HTq9A0A@mail.gmail.com>
Message-ID: <ZXi/u7dZ20oLPF9n@shell.armlinux.org.uk>

On Tue, Dec 12, 2023 at 09:05:14PM +0100, Rafael J. Wysocki wrote:
> On Tue, Dec 12, 2023 at 8:58?PM Russell King (Oracle)
> <linux at armlinux.org.uk> wrote:
> >
> > On Mon, Dec 04, 2023 at 06:23:02PM +0000, Russell King (Oracle) wrote:
> > > On Tue, Oct 24, 2023 at 08:26:58PM +0200, Rafael J. Wysocki wrote:
> > > > I've gone through the series and there is at least one thing in it
> > > > that concerns me a lot and some others that at least appear to be
> > > > really questionable.
> > > >
> > > > I need more time to send comments which I'm not going to do before the
> > > > 6.7 merge window (sorry), but from what I can say right now, this is
> > > > not looking good.
> > >
> > > Hi Rafael,
> > >
> > > Will you be able to send your comments, so that we can find out what
> > > your other concerns are please? I'm getting questions from interested
> > > parties who want to know what your concerns are.
> > >
> > > Nothing much has changed to the ACPI changes, so I think it's still
> > > valid to have the comments back for this.
> >
> > Hi Rafael,
> >
> > Another gentle prod on this...
> 
> There was a selection of the patches in the series sent separately and
> I believe that some of them have been applied already.
> 
> Can you please send the remaining patches again so it is clear what's
> still outstanding?

I can do tomorrow, thanks. I will re-post as RFC again because it will
depend on the cleanup part that was merged into Greg's tree - and thus
the series isn't standalone (and I'll mention that in the cover
message.)

We need to hear your concerns, which sounded quite damning for the
series, so that if it's possible to save this a plan to address your
concerns can be formulated.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From rick.p.edgecombe at intel.com  Tue Dec 12 12:17:09 2023
From: rick.p.edgecombe at intel.com (Edgecombe, Rick P)
Date: Tue, 12 Dec 2023 20:17:09 +0000
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
	 <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
Message-ID: <e1362732ba86990b7707d3f5b785358b77c5f896.camel@intel.com>

On Wed, 2023-11-22 at 09:42 +0000, Mark Brown wrote:
> These features are expected to be inherited by new threads and
> cleared
> on exec(), unknown features should be rejected for enable but
> accepted
> for locking (in order to allow for future proofing).

The reason why I stuck with arch_prctl when this came up is that CRIU
(and probably other ptracers) needs a way to unlock via ptrace. ptrace
arch_prctl() can do this. Did you have a plan for unlocking via ptrace?

From krzysztof.kozlowski at linaro.org  Tue Dec 12 12:20:14 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 21:20:14 +0100
Subject: [PATCH v1 3/8] ARM: dts: aspeed: System1: IBM system1 BMC board
In-Reply-To: <20231212164004.1683589-4-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-4-ninad@linux.ibm.com>
Message-ID: <81d90c0d-9d7e-43a9-ade8-16b85a242b48@linaro.org>

On 12/12/2023 17:39, Ninad Palsule wrote:
> From: Andrew Geissler <geissonator at yahoo.com>
> 
> Add a device tree for IBM system1 BMC board. It uses AST2600 SOC.
> 
> Tested:
>     This board is tested using the simics simulator.
> 
> Signed-off-by: Andrew Geissler <geissonator at yahoo.com>
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---
>  arch/arm/boot/dts/aspeed/Makefile             |   1 +
>  .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 188 ++++++++++++++++++
>  2 files changed, 189 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> 
> diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
> index 3e3e6b96cb79..6f7ed11978ff 100644
> --- a/arch/arm/boot/dts/aspeed/Makefile
> +++ b/arch/arm/boot/dts/aspeed/Makefile
> @@ -35,6 +35,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>  	aspeed-bmc-ibm-rainier.dtb \
>  	aspeed-bmc-ibm-rainier-1s4u.dtb \
>  	aspeed-bmc-ibm-rainier-4u.dtb \
> +	aspeed-bmc-ibm-system1.dtb \
>  	aspeed-bmc-intel-s2600wf.dtb \
>  	aspeed-bmc-inspur-fp5280g2.dtb \
>  	aspeed-bmc-inspur-nf5280m6.dtb \
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> new file mode 100644
> index 000000000000..01291b407f59
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +// Copyright 2023 IBM Corp.
> +/dts-v1/;
> +
> +#include "aspeed-g6.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +#include <dt-bindings/i2c/i2c.h>
> +#include <dt-bindings/leds/leds-pca955x.h>
> +
> +/ {
> +	model = "System1";
> +	compatible = "ibm,system1-bmc", "aspeed,ast2600";
> +
> +	chosen {
> +		stdout-path = &uart5;
> +		bootargs = "console=ttyS4,115200n8 earlycon";

Drop early con, debugging feature not release. Then use stdout path
alone, so drop console as well.


> +	};
> +
> +	memory at 80000000 {
> +		device_type = "memory";
> +		reg = <0x80000000 0x40000000>;
> +	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		event_log: tcg_event_log at b3d00000 {

No underscores in node names.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 12 12:21:27 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 21:21:27 +0100
Subject: [PATCH v1 4/8] ARM: dts: aspeed: System1: Add i2c and muxes
In-Reply-To: <20231212164004.1683589-5-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-5-ninad@linux.ibm.com>
Message-ID: <72a749b9-b9be-4496-9bcc-37519044c109@linaro.org>

On 12/12/2023 17:40, Ninad Palsule wrote:
> This commit adds i2c devices and muxes.
> 
> Tested:
>     This board is tested using the simics simulator.
> 
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---
>  .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 577 ++++++++++++++++++
>  1 file changed, 577 insertions(+)
> 

Why do you split new submission into multiple chunks? The logical
feature here is new board, so all your DTS patches adding new board
should be in one patch.

> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> index 01291b407f59..0557bff9f36a 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> @@ -11,6 +11,65 @@ / {
>  	model = "System1";
>  	compatible = "ibm,system1-bmc", "aspeed,ast2600";
>  
> +	aliases {
> +		i2c16 = &i2c8mux1chn0;
> +		i2c17 = &i2c8mux1chn1;
> +		i2c18 = &i2c8mux1chn2;
> +		i2c19 = &i2c8mux1chn3;
> +		i2c20 = &i2c8mux1chn4;
> +		i2c21 = &i2c8mux1chn5;
> +		i2c22 = &i2c8mux1chn6;
> +		i2c23 = &i2c8mux1chn7;
> +		i2c24 = &i2c3mux0chn0;
> +		i2c25 = &i2c3mux0chn1;
> +		i2c26 = &i2c3mux0chn2;
> +		i2c27 = &i2c3mux0chn3;
> +		i2c28 = &i2c3mux0chn4;
> +		i2c29 = &i2c3mux0chn5;
> +		i2c30 = &i2c3mux0chn6;
> +		i2c31 = &i2c3mux0chn7;
> +		i2c32 = &i2c6mux0chn0;
> +		i2c33 = &i2c6mux0chn1;
> +		i2c34 = &i2c6mux0chn2;
> +		i2c35 = &i2c6mux0chn3;
> +		i2c36 = &i2c6mux0chn4;
> +		i2c37 = &i2c6mux0chn5;
> +		i2c38 = &i2c6mux0chn6;
> +		i2c39 = &i2c6mux0chn7;
> +		i2c40 = &i2c7mux0chn0;
> +		i2c41 = &i2c7mux0chn1;
> +		i2c42 = &i2c7mux0chn2;
> +		i2c43 = &i2c7mux0chn3;
> +		i2c44 = &i2c7mux0chn4;
> +		i2c45 = &i2c7mux0chn5;
> +		i2c46 = &i2c7mux0chn6;
> +		i2c47 = &i2c7mux0chn7;
> +		i2c48 = &i2c8mux0chn0;
> +		i2c49 = &i2c8mux0chn1;
> +		i2c50 = &i2c8mux0chn2;
> +		i2c51 = &i2c8mux0chn3;
> +		i2c52 = &i2c8mux0chn4;
> +		i2c53 = &i2c8mux0chn5;
> +		i2c54 = &i2c8mux0chn6;
> +		i2c55 = &i2c8mux0chn7;
> +		i2c56 = &i2c14mux0chn0;
> +		i2c57 = &i2c14mux0chn1;
> +		i2c58 = &i2c14mux0chn2;
> +		i2c59 = &i2c14mux0chn3;
> +		i2c60 = &i2c14mux0chn4;
> +		i2c61 = &i2c14mux0chn5;
> +		i2c62 = &i2c14mux0chn6;
> +		i2c63 = &i2c14mux0chn7;
> +		i2c64 = &i2c15mux0chn0;
> +		i2c65 = &i2c15mux0chn1;
> +		i2c66 = &i2c15mux0chn2;
> +		i2c67 = &i2c15mux0chn3;
> +		i2c68 = &i2c15mux0chn4;
> +		i2c69 = &i2c15mux0chn5;
> +		i2c70 = &i2c15mux0chn6;
> +		i2c71 = &i2c15mux0chn7;
> +	};
> +
>  	chosen {
>  		stdout-path = &uart5;
>  		bootargs = "console=ttyS4,115200n8 earlycon";
> @@ -54,10 +113,12 @@ vga_memory: region at bf000000 {
>  			reg = <0xbf000000 0x01000000>;  /* 16M */
>  		};
>  	};
> +

You need to clean your patchset...


>  };
>  
>  &adc1 {
>  	status = "okay";
> +

Really.

>  	aspeed,int-vref-microvolt = <2500000>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_adc8_default
> @@ -186,3 +247,519 @@ &kcs3 {
>  	aspeed,lpc-io-reg = <0xca2>;
>  	aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
>  };
> +
> +&i2c0 {
> +	status = "okay";
> +};
> +
> +&i2c1 {
> +	status = "okay";
> +};
> +
> +&i2c2 {
> +	status = "okay";
> +};
> +
> +&i2c3 {
> +	status = "okay";
> +
> +	i2c-mux at 70 {
> +		compatible = "nxp,pca9548";
> +		reg = <0x70>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "okay";

Drop

> +		i2c-mux-idle-disconnect;
> +
> +		i2c3mux0chn0: i2c at 0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0>;
> +		};
> +
> +		i2c3mux0chn1: i2c at 1 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <1>;
> +		};
> +
> +		i2c3mux0chn2: i2c at 2 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <2>;
> +		};
> +
> +		i2c3mux0chn3: i2c at 3 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <3>;
> +		};
> +
> +		i2c3mux0chn4: i2c at 4 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <4>;
> +		};
> +
> +		i2c3mux0chn5: i2c at 5 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <5>;
> +		};
> +
> +		i2c3mux0chn6: i2c at 6 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <6>;
> +		};
> +
> +		i2c3mux0chn7: i2c at 7 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <7>;
> +		};
> +	};
> +};
> +
> +&i2c4 {
> +	status = "okay";
> +};
> +
> +&i2c5 {
> +	status = "okay";
> +};
> +
> +&i2c6 {
> +	status = "okay";
> +
> +	i2c-mux at 70 {
> +		compatible = "nxp,pca9548";
> +		reg = <0x70>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "okay";

Drop

Other places as well.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 12 12:22:35 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 21:22:35 +0100
Subject: [PATCH v1 5/8] ARM: dts: aspeed: System1: Voltage regulators
In-Reply-To: <20231212164004.1683589-6-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-6-ninad@linux.ibm.com>
Message-ID: <6a3d4551-66a2-411a-9d5f-cffb57ee0ce2@linaro.org>

On 12/12/2023 17:40, Ninad Palsule wrote:
> This commit adds different voltage regulators.
> 
> Tested:
>     This board is tested using the simics simulator.
> 
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---
>  .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 266 ++++++++++++++++++

Squash it.

>  1 file changed, 266 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> index 0557bff9f36a..b8e7e52d4600 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> @@ -114,10 +114,127 @@ vga_memory: region at bf000000 {
>  		};
>  	};
>  
> +	iio-hwmon {
> +		compatible = "iio-hwmon";
> +		io-channels = <&p12v_vd 0>, <&p5v_aux_vd 0>,
> +			<&p5v_bmc_aux_vd 0>, <&p3v3_aux_vd 0>,
> +			<&p3v3_bmc_aux_vd 0>, <&p1v8_bmc_aux_vd 0>,
> +			<&adc1 4>, <&adc0 2>, <&adc1 0>,
> +			<&p2V5_aux_vd 0>, <&adc1 7>;
> +	};
> +
> +	p12v_vd: voltage_divider1 {

Same comments as in other patches.

> +		compatible = "voltage-divider";
> +		io-channels = <&adc1 3>;
> +		#io-channel-cells = <1>;
> +
> +		/* Scale the system voltage by 1127/127 to fit the ADC range.

Use Linux coding style comments. /* and blank line


....

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 12 12:25:01 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 21:25:01 +0100
Subject: [PATCH v1 6/8] ARM: dts: aspeed: System1: GPIO, Fan ctrl, Led
In-Reply-To: <20231212164004.1683589-7-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-7-ninad@linux.ibm.com>
Message-ID: <1b19af6f-645a-4913-b9db-49b1f3ad54f9@linaro.org>

On 12/12/2023 17:40, Ninad Palsule wrote:
> This commit adds following devices to the device tree.
> - GPIO pin assignements, GPIO expansion devices
> - LED brinker devices
> - Fan controllers
> 
> Tested:
>     This board is tested using the simics simulator.
> 
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---
>  .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 547 +++++++++++++++++-

Squash it.

>  1 file changed, 542 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> index b8e7e52d4600..75562aa63701 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> @@ -114,6 +114,99 @@ vga_memory: region at bf000000 {
>  		};
>  	};
>  
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		bmc-ready {

It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).

> +			gpios = <&gpio0 ASPEED_GPIO(L, 7) GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		bmc-hb {

None of these were tested.


>  	/*A0-A7*/	"","","","","","","","",
> -	/*B0-B7*/	"","","","","","","","",
> +	/*B0-B7*/	"","","","","bmc-tpm-reset","","","",

Really? You just added these lines. There is no point in adding a new
line and immediately changing it.

This points how your split is artificial and not helpful.
...


>  &i2c2 {
> @@ -486,6 +744,20 @@ regulator at 43 {
>  &i2c6 {
>  	status = "okay";
>  
> +	fan-controller at 52 {
> +		compatible = "maxim,max31785a";
> +		reg = <0x52>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;

Why do you need cells?

> +	};
> +
> +	fan-controller at 54 {
> +		compatible = "maxim,max31785a";
> +		reg = <0x54>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;

Why do you need cells?

> +	};
> +
>  	i2c-mux at 70 {
>  		compatible = "nxp,pca9548";
>  		reg = <0x70>;
> @@ -522,6 +794,48 @@ i2c6mux0chn4: i2c at 4 {
>  			#address-cells = <1>;
>  			#size-cells = <0>;
>  			reg = <4>;
> +
> +			led-controller at 60 {
> +				compatible = "nxp,pca9551";
> +				reg = <0x60>;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				gpio-controller;
> +				#gpio-cells = <2>;
> +
> +				led at 0 {
> +					label = "enclosure-id-led";
> +					reg = <0>;
> +					retain-state-shutdown;
> +					default-state = "keep";
> +					type = <PCA955X_TYPE_LED>;
> +				};
> +
> +				led at 1 {
> +					label = "attention-led";
> +					reg = <1>;
> +					retain-state-shutdown;
> +					default-state = "keep";
> +					type = <PCA955X_TYPE_LED>;
> +				};
> +
> +				led at 2 {
> +					label = "enclosure-fault-rollup-led";
> +					reg = <2>;
> +					retain-state-shutdown;
> +					default-state = "keep";
> +					type = <PCA955X_TYPE_LED>;
> +				};
> +
> +				led at 3 {
> +					label = "power-on-led";
> +					reg = <3>;
> +					retain-state-shutdown;
> +					default-state = "keep";
> +					type = <PCA955X_TYPE_LED>;
> +				};
> +			};
>  		};
>  
>  		i2c6mux0chn5: i2c at 5 {
> @@ -542,6 +856,44 @@ i2c6mux0chn7: i2c at 7 {
>  			reg = <7>;
>  		};
>  	};
> +
> +	pca3: pca9539 at 74 {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation


> +		compatible = "nxp,pca9539";
> +		reg = <0x74>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +	};
> +
> +	pca4: pca9539 at 77 {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation


> +		compatible = "nxp,pca9539";
> +		reg = <0x77>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +		gpio-line-names =
> +			"PE_NVMED0_EXP_PRSNT_N",
> +			"PE_NVMED1_EXP_PRSNT_N",
> +			"PE_NVMED2_EXP_PRSNT_N",
> +			"PE_NVMED3_EXP_PRSNT_N",
> +			"LED_FAULT_NVMED0",
> +			"LED_FAULT_NVMED1",
> +			"LED_FAULT_NVMED2",
> +			"LED_FAULT_NVMED3",
> +			"FAN0_PRESENCE_R_N",
> +			"FAN1_PRESENCE_R_N",
> +			"FAN2_PRESENCE_R_N",
> +			"FAN3_PRESENCE_R_N",
> +			"FAN4_PRESENCE_R_N",
> +			"FAN5_PRESENCE_N",
> +			"FAN6_PRESENCE_N",
> +			"";
> +	};
>  };
>  
>  &i2c7 {
> @@ -809,6 +1161,191 @@ regulator at 41 {
>  		compatible = "infineon,ir38263";
>  		reg = <0x41>;
>  	};
> +
> +	led-controller at 61 {
> +		compatible = "nxp,pca9552";
> +		reg = <0x61>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +

...

> +		led at 15 {
> +			label = "pe-cp-drv3-perst";
> +			reg = <15>;
> +			retain-state-shutdown;
> +			default-state = "keep";
> +			type = <PCA955X_TYPE_LED>;
> +		};
> +	};
> +
> +	pca1: pca9539 at 75 {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation




Best regards,
Krzysztof



From broonie at kernel.org  Tue Dec 12 12:26:15 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 12 Dec 2023 20:26:15 +0000
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <e1362732ba86990b7707d3f5b785358b77c5f896.camel@intel.com>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
 <e1362732ba86990b7707d3f5b785358b77c5f896.camel@intel.com>
Message-ID: <28c584ff-ef25-464f-852c-c5ddf66e5906@sirena.org.uk>

On Tue, Dec 12, 2023 at 08:17:09PM +0000, Edgecombe, Rick P wrote:
> On Wed, 2023-11-22 at 09:42 +0000, Mark Brown wrote:

> > These features are expected to be inherited by new threads and
> > cleared
> > on exec(), unknown features should be rejected for enable but
> > accepted
> > for locking (in order to allow for future proofing).

> The reason why I stuck with arch_prctl when this came up is that CRIU
> (and probably other ptracers) needs a way to unlock via ptrace. ptrace
> arch_prctl() can do this. Did you have a plan for unlocking via ptrace?

The set of locked features is read/write via ptrace in my arm64 series,
that's architecture specific unfortunately but that seems to be the way
with ptrace.

In general if things have a need to get at prctl()s via ptrace we should
just fix that, at least for arm64 there's things like the vector lengths
that are currently controlled via prctl(), but it shouldn't be a blocker
for the locking specifically.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/49912d5e/attachment.sig>

From krzysztof.kozlowski at linaro.org  Tue Dec 12 12:26:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 12 Dec 2023 21:26:32 +0100
Subject: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
In-Reply-To: <20231212164004.1683589-9-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-9-ninad@linux.ibm.com>
Message-ID: <5b98538a-8ffe-42ec-b020-514dcfcebba3@linaro.org>

On 12/12/2023 17:40, Ninad Palsule wrote:
> This drop adds following devices in the device tree.
> - EEPROM/VPD
> - Power supplies
> - Humidity, pressure and temperature sensors.
> - Trusted platform module(TPM) chip
> 
> Tested:
>     This board is tested using the simics simulator.
> 
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---

Don't mix DTS with drivers. DTS and drivers go via different subsystems
and cannot have dependencies, so why DTS is patch #6, then driver #7 and
now again DTS #7?


>  .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 76 +++++++++++++++++++
>  1 file changed, 76 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> index 75562aa63701..d960b938fe8d 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> @@ -461,6 +461,11 @@ &kcs3 {
>  &i2c0 {
>  	status = "okay";
>  
> +	eeprom at 50 {
> +		compatible = "atmel,24c64";
> +		reg = <0x50>;
> +	};
> +
>  	regulator at 60 {
>  		compatible = "maxim,max8952";
>  		reg = <0x60>;
> @@ -655,6 +660,25 @@ pca0: pca9539 at 74 {
>  
>  &i2c2 {
>  	status = "okay";
> +
> +	power-supply at 58 {
> +		compatible = "ibm,cffps";
> +		reg = <0x58>;
> +	};
> +
> +	power-supply at 59 {
> +		compatible = "ibm,cffps";
> +		reg = <0x59>;
> +	};
> +
> +	power-supply at 5a {
> +		compatible = "ibm,cffps";
> +		reg = <0x5a>;
> +	};

Missing blank line

> +	power-supply at 5b {
> +		compatible = "ibm,cffps";
> +		reg = <0x5b>;
> +	};


Best regards,
Krzysztof



From irogers at google.com  Tue Dec 12 12:27:11 2023
From: irogers at google.com (Ian Rogers)
Date: Tue, 12 Dec 2023 12:27:11 -0800
Subject: [PATCH v1 06/14] libperf cpumap: Add any, empty and min helpers
In-Reply-To: <94e3745c-8c2b-bdf3-f331-1cbe56574d48@arm.com>
References: <20231129060211.1890454-1-irogers@google.com> <20231129060211.1890454-7-irogers@google.com>
 <94e3745c-8c2b-bdf3-f331-1cbe56574d48@arm.com>
Message-ID: <CAP-5=fUWtgNMGWowN2+qnV5FV3viHd=kPqiwXUeEtkQAzabLGw@mail.gmail.com>

On Tue, Dec 12, 2023 at 7:06?AM James Clark <james.clark at arm.com> wrote:
>
>
>
> On 29/11/2023 06:02, Ian Rogers wrote:
> > Additional helpers to better replace
> > perf_cpu_map__has_any_cpu_or_is_empty.
> >
> > Signed-off-by: Ian Rogers <irogers at google.com>
> > ---
> >  tools/lib/perf/cpumap.c              | 27 +++++++++++++++++++++++++++
> >  tools/lib/perf/include/perf/cpumap.h | 16 ++++++++++++++++
> >  tools/lib/perf/libperf.map           |  4 ++++
> >  3 files changed, 47 insertions(+)
> >
> > diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
> > index 49fc98e16514..7403819da8fd 100644
> > --- a/tools/lib/perf/cpumap.c
> > +++ b/tools/lib/perf/cpumap.c
> > @@ -316,6 +316,19 @@ bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map)
> >       return map ? __perf_cpu_map__cpu(map, 0).cpu == -1 : true;
> >  }
> >
> > +bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map)
> > +{
> > +     if (!map)
> > +             return true;
> > +
> > +     return __perf_cpu_map__nr(map) == 1 && __perf_cpu_map__cpu(map, 0).cpu == -1;
> > +}
>
> I'm struggling to understand the relevance of the difference between
> has_any and is_any I see that there is a slight difference, but could it
> not be refactored out so we only need one?

Yep, that's what these changes are working toward. For has any the set
{-1, 0, 1} would return true while is any will return false.
Previously the has any behavior was called "empty" which I think is
actively misleading.

> Do you ever get an 'any' map that has more than 1 entry? It's quite a
> subtle difference that is_any returns false if the first one is 'any'
> but then there are subsequent entries. Whereas has_any would return
> true. I'm not sure if future readers would be able to appreciate that.
>
> I see has_any is only used twice, both on evlist->all_cpus. Is there
> something about that member that means it could have a map that has an
> 'any' mixed with CPUs? Wouldn't that have the same result as a normal
> 'any' anyway?

The dummy event may be opened on any CPU but then a particular event
may be opened on certain CPUs. We merge CPU maps in places like evlist
so that we can iterate the appropriate CPUs for events and
open/enable/disable/close all events on a certain CPU at the same time
(we also set the affinity to that CPU to avoid IPIs). What I'm hoping
to do in these changes is reduce the ambiguity, the corner cases are
by their nature unusual.

An example of a corner case is, uncore events often get opened just on
CPU 0 but on a multi-socket system you may have a CPU 32 that also
needs to open the event. Previous code treated the CPU map index and
value it contained pretty interchangeably. This is often fine for the
core PMU but is clearly wrong in this uncore case, {0, 32} has indexes
0 and 1 but those indexes don't match the CPU numbers. The case of -1
has often previously been called dummy but I'm trying to call it the
"any CPU" case to match the perf_event_open man page (I'm hoping it
also makes it less ambiguous with any CPU being used with a particular
event like cycles, calling it dummy makes the event sound like it may
have sideband data). The difference between "all CPUs" and "any CPU"
is that an evsel for all CPUs would need the event opening
individually on each CPU, while any CPU events are a single open call.
Any CPU is only valid to perf_event_open if a PID is specified.
Depending on the set up there could be overlaps in what they count but
hopefully it is clearer what the distinction is. I believe the case of
"any CPU" and specific CPU numbers is more common with aux buffers and
Adrian has mentioned needing it for intel-pt.

Thanks,
Ian

> > +
> > +bool perf_cpu_map__is_empty(const struct perf_cpu_map *map)
> > +{
> > +     return map == NULL;
> > +}
> > +
> >  int perf_cpu_map__idx(const struct perf_cpu_map *cpus, struct perf_cpu cpu)
> >  {
> >       int low, high;
> > @@ -372,6 +385,20 @@ bool perf_cpu_map__has_any_cpu(const struct perf_cpu_map *map)
> >       return map && __perf_cpu_map__cpu(map, 0).cpu == -1;
> >  }
> >
> > +struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map)
> > +{
> > +     struct perf_cpu cpu, result = {
> > +             .cpu = -1
> > +     };
> > +     int idx;
> > +
> > +     perf_cpu_map__for_each_cpu_skip_any(cpu, idx, map) {
> > +             result = cpu;
> > +             break;
> > +     }
> > +     return result;
> > +}
> > +
> >  struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map)
> >  {
> >       struct perf_cpu result = {
> > diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
> > index dbe0a7352b64..523e4348fc96 100644
> > --- a/tools/lib/perf/include/perf/cpumap.h
> > +++ b/tools/lib/perf/include/perf/cpumap.h
> > @@ -50,6 +50,22 @@ LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
> >   * perf_cpu_map__has_any_cpu_or_is_empty - is map either empty or has the "any CPU"/dummy value.
> >   */
> >  LIBPERF_API bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map);
> > +/**
> > + * perf_cpu_map__is_any_cpu_or_is_empty - is map either empty or the "any CPU"/dummy value.
> > + */
> > +LIBPERF_API bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map);
> > +/**
> > + * perf_cpu_map__is_empty - does the map contain no values and it doesn't
> > + *                          contain the special "any CPU"/dummy value.
> > + */
> > +LIBPERF_API bool perf_cpu_map__is_empty(const struct perf_cpu_map *map);
> > +/**
> > + * perf_cpu_map__min - the minimum CPU value or -1 if empty or just the "any CPU"/dummy value.
> > + */
> > +LIBPERF_API struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map);
> > +/**
> > + * perf_cpu_map__max - the maximum CPU value or -1 if empty or just the "any CPU"/dummy value.
> > + */
> >  LIBPERF_API struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map);
> >  LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, struct perf_cpu cpu);
> >  LIBPERF_API bool perf_cpu_map__equal(const struct perf_cpu_map *lhs,
> > diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
> > index 10b3f3722642..2aa79b696032 100644
> > --- a/tools/lib/perf/libperf.map
> > +++ b/tools/lib/perf/libperf.map
> > @@ -10,6 +10,10 @@ LIBPERF_0.0.1 {
> >               perf_cpu_map__nr;
> >               perf_cpu_map__cpu;
> >               perf_cpu_map__has_any_cpu_or_is_empty;
> > +             perf_cpu_map__is_any_cpu_or_is_empty;
> > +             perf_cpu_map__is_empty;
> > +             perf_cpu_map__has_any_cpu;
> > +             perf_cpu_map__min;
> >               perf_cpu_map__max;
> >               perf_cpu_map__has;
> >               perf_thread_map__new_array;


From u.kleine-koenig at pengutronix.de  Tue Dec 12 12:33:52 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 21:33:52 +0100
Subject: [PATCH] pwm: meson: Simplify using dev_err_probe()
In-Reply-To: <ZXcpswXxb1oQldp5@orome.fritz.box>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
 <ZXbsDRslZNKCeJF9@orome.fritz.box>
 <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>
 <ZXcpswXxb1oQldp5@orome.fritz.box>
Message-ID: <20231212203352.wl3rzob75fct4lov@pengutronix.de>

Hello Thierry,

On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> It all adds up in the end and keeps me from doing other things.

If that means you'd be glad to give up the PWM maintainer job, I'd
happily take over this post.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/ed14738a/attachment.sig>

From palmer at dabbelt.com  Tue Dec 12 13:04:42 2023
From: palmer at dabbelt.com (Palmer Dabbelt)
Date: Tue, 12 Dec 2023 13:04:42 -0800 (PST)
Subject: [PATCH] drivers: perf: constify the ctl_table argument of the riscv user access handler
In-Reply-To: <20231206-flanking-frill-fffeca740221@spud>
Message-ID: <mhng-8f7ddf72-8e2f-4dac-a67e-624eb5511a14@palmer-ri-x1c9a>

On Wed, 06 Dec 2023 02:55:48 PST (-0800), Conor Dooley wrote:
> On Wed, Dec 06, 2023 at 09:46:42AM +0100, Marek Szyprowski wrote:
>> 
>> Fix riscv build break after commit c8be9e66ca1e ("sysctl: treewide:
>> constify the ctl_table argument of handlers").
>> 
>> Fixes: c8be9e66ca1e ("sysctl: treewide: constify the ctl_table argument of handlers")
>> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
>
> This breaks the build when applied to the RISC-V tree. I'm going to mark
> it "handled elsewhere" in patchwork since it needs to go into whatever
> tree has the broken commit.

Ya, thanks.  There's a second copy of the fix over at 
https://lore.kernel.org/all/20231212-garage-pellet-c6a2bd34854c at spud/ .

Reviewed-by: Palmer Dabbelt <palmer at rivosinc.com>
Acked-by: Palmer Dabbelt <palmer at rivosinc.com>

for this one too.  Just trying to merge that fixed hash into 6.7-rc1 is 
giving me a conflict, so I don't really want to pull it in myself.  So I 
think the best bet here is to have whomever took the patch take the fix, 
but LMK if there's some shared tag thing I should grab to take this into 
the RISC-V tree.

>
> Thanks,
> Conor.


From u.kleine-koenig at pengutronix.de  Tue Dec 12 13:05:09 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 12 Dec 2023 22:05:09 +0100
Subject: [PATCH v4 000/115] pwm: Fix lifetime issues for pwm_chips
In-Reply-To: <ZXbzcFTnDTKoZAta@orome.fritz.box>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
 <ZXM4CdJxg-XrYhkn@orome.fritz.box>
 <20231208185033.e6ty2cajcfle6dgk@pengutronix.de>
 <ZXbzcFTnDTKoZAta@orome.fritz.box>
Message-ID: <20231212210509.focpb63fbmahqij3@pengutronix.de>

Hello Thierry,

On Mon, Dec 11, 2023 at 12:33:04PM +0100, Thierry Reding wrote:
> On Fri, Dec 08, 2023 at 07:50:33PM +0100, Uwe Kleine-K?nig wrote:
> > You don't need to touch all drivers because you didn't change struct
> > pwm_chip::dev yet. (If you really want, you don't need to change that,
> > but then you have some duplication as chip->dev holds the same value as
> > priv->dev.parent in the end.)
> 
> I don't think that's a problem. These are for two logically separate
> things, after all.

How are they different? I'd say one is the initializer for the other and
(ideally) unused after that. With that interpretation they are indeed
different, but then it's ugly that the initializer keeps staying around.

> Duplication can also sometimes be useful to simplify
> things. There are plently of cases where we use local variables for the
> same reason.

local variables go away though after the respective function is left.
chip->dev and its copy priv->dev.parent stay around for the full
lifetime of the chip.

> > > @@ -58,23 +60,24 @@ static struct pwm_chip *pwmchip_find_by_name(const char *name)
> > >  
> > >  static int pwm_device_request(struct pwm_device *pwm, const char *label)
> > >  {
> > > +	struct pwm_chip *chip = pwm->priv->chip;
> > 
> > With my approach getting the chip of a struct pwm_device is only one
> > pointer dereference away. You need two.
> 
> None of the functions here are called very often, so even if this isn't
> optimized away it would hardly matter.

I'd say pwm_apply_state() at least matters. Also I think that making a
slow path quicker is a good thing. 

I wonder how we'll converge to an approach that can go into the
mainline given that we both have our strong opinions.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/ce1d3650/attachment-0001.sig>

From linux at roeck-us.net  Tue Dec 12 13:18:59 2023
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 12 Dec 2023 13:18:59 -0800
Subject: [PATCH v7 12/16] watchdog: s3c2410_wdt: Add support for Google
 gs101 SoC
In-Reply-To: <20231211162331.435900-13-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-13-peter.griffin@linaro.org>
Message-ID: <cb84bee8-db33-41b3-b0f3-79b3df494496@roeck-us.net>

On 12/11/23 08:23, Peter Griffin wrote:
> This patch adds the compatibles and drvdata for the Google
> gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.
> 
> Similar to Exynos850 it has two watchdog instances, one for
> each cluster and has some control bits in PMU registers.
> 
> gs101 also has the dbgack_mask bit in wtcon register, so
> we also enable QUIRK_HAS_DBGACK_BIT.
> 
> Tested-by: Will McVicker <willmcvicker at google.com>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

> ---
>   drivers/watchdog/s3c2410_wdt.c | 49 ++++++++++++++++++++++++++++++----
>   1 file changed, 44 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> index b7a03668f743..c3046610ab5d 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -69,6 +69,13 @@
>   #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
>   #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
>   
> +#define GS_CLUSTER0_NONCPU_OUT			0x1220
> +#define GS_CLUSTER1_NONCPU_OUT			0x1420
> +#define GS_CLUSTER0_NONCPU_INT_EN		0x1244
> +#define GS_CLUSTER1_NONCPU_INT_EN		0x1444
> +#define GS_CLUSTER2_NONCPU_INT_EN		0x1644
> +#define GS_RST_STAT_REG_OFFSET			0x3B44
> +
>   /**
>    * DOC: Quirk flags for different Samsung watchdog IP-cores
>    *
> @@ -270,7 +277,35 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
>   		  QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
>   };
>   
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
> +	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 0,
> +	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
> +	.cnt_en_bit = 8,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET |
> +		  QUIRK_HAS_PMU_CNT_EN | QUIRK_HAS_WTCLRINT_REG |
> +		  QUIRK_HAS_DBGACK_BIT,
> +};
> +
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
> +	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 1,
> +	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
> +	.cnt_en_bit = 7,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET |
> +		  QUIRK_HAS_PMU_CNT_EN | QUIRK_HAS_WTCLRINT_REG |
> +		  QUIRK_HAS_DBGACK_BIT,
> +};
> +
>   static const struct of_device_id s3c2410_wdt_match[] = {
> +	{ .compatible = "google,gs101-wdt",
> +	  .data = &drv_data_gs101_cl0 },
>   	{ .compatible = "samsung,s3c2410-wdt",
>   	  .data = &drv_data_s3c2410 },
>   	{ .compatible = "samsung,s3c6410-wdt",
> @@ -605,9 +640,10 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>   	}
>   
>   #ifdef CONFIG_OF
> -	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
> +	/* Choose Exynos9 SoC family driver data w.r.t. cluster index */
>   	if (variant == &drv_data_exynos850_cl0 ||
> -	    variant == &drv_data_exynosautov9_cl0) {
> +	    variant == &drv_data_exynosautov9_cl0 ||
> +	    variant == &drv_data_gs101_cl0) {
>   		u32 index;
>   		int err;
>   
> @@ -620,9 +656,12 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>   		case 0:
>   			break;
>   		case 1:
> -			variant = (variant == &drv_data_exynos850_cl0) ?
> -				&drv_data_exynos850_cl1 :
> -				&drv_data_exynosautov9_cl1;
> +			if (variant == &drv_data_exynos850_cl0)
> +				variant = &drv_data_exynos850_cl1;
> +			else if (variant == &drv_data_exynosautov9_cl0)
> +				variant = &drv_data_exynosautov9_cl1;
> +			else if (variant == &drv_data_gs101_cl0)
> +				variant = &drv_data_gs101_cl1;
>   			break;
>   		default:
>   			return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);



From rick.p.edgecombe at intel.com  Tue Dec 12 13:22:59 2023
From: rick.p.edgecombe at intel.com (Edgecombe, Rick P)
Date: Tue, 12 Dec 2023 21:22:59 +0000
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <28c584ff-ef25-464f-852c-c5ddf66e5906@sirena.org.uk>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
	 <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
	 <e1362732ba86990b7707d3f5b785358b77c5f896.camel@intel.com>
	 <28c584ff-ef25-464f-852c-c5ddf66e5906@sirena.org.uk>
Message-ID: <4acb51ebb3764f6a48a741d7b7d33f9a68c996fb.camel@intel.com>

+Mike, who did the CRIU work

Re:
https://lore.kernel.org/lkml/e1362732ba86990b7707d3f5b785358b77c5f896.camel at intel.com/

On Tue, 2023-12-12 at 20:26 +0000, Mark Brown wrote:
> The set of locked features is read/write via ptrace in my arm64
> series,
> that's architecture specific unfortunately but that seems to be the
> way
> with ptrace.

Ah, sorry I didn't see that later in the series. Makes sense. 

> 
> In general if things have a need to get at prctl()s via ptrace we
> should
> just fix that, at least for arm64 there's things like the vector
> lengths
> that are currently controlled via prctl(), but it shouldn't be a
> blocker
> for the locking specifically.

ptrace arch_prctl() is a bit odd. Not all values of 'option' are
supported because ptrace arch_prctl's have to operate cross task. Some
have extra code to support doing this, and some only know how to
operate on the current task, so return an error in the ptrace case.

I guess a benefit would be that there could be some arch agnostic
ptrace userspace code. And I'd also guess (really a guess) that most
ptracing code has some arch awareness already, but the other way is
probably non-zero. Same for shadow stack enabling code. Then on the
kernel side we'd have to add and support a ptrace prctl() solution.

Is it worth the effort? I don't have a strong opinion.

From heiko at sntech.de  Tue Dec 12 13:32:52 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 12 Dec 2023 22:32:52 +0100
Subject: [GIT PULL] Rockchip dts64 changes for 6.8 #1
Message-ID: <3535836.iIbC2pHGDl@phil>

Hi Arnd, Kevin, Olof,

please find below and in a subsequent pull-request
Rockchip changes for for 6.8 .


The change that might need the most explanation is probably around the
aliases. In a recent discussion [0] the alias naming came up - with them
aimed at matching labeling / documentation.

As stated there all the Rockchip core busses (i2c, spi, and so on) use
a numbered scheme everywhere - from the SoC manual down to the board
schematics. Meaning i2c2 should always be i2c2.

Together with Krzysztof's additional mention [1] that aliases in board-
files
	"is just generic guideline",
a lot of people involved agreed that we don't want to repeat the same
huge stack of core-bus aliases on each and every board. On the other
hand, all the non-numbered busses should be living in the board dts
files. So a bit of a cleanup got underway to achieve that state on the
newer socs. (both arm64 and arm32).


Please pull!

Thanks
Heiko


[0] https://lore.kernel.org/linux-rockchip/4762834.KRxA6XjA2N at diego/#r
[1] https://lore.kernel.org/linux-rockchip/7b8a830d-42d0-4220-b9fe-3f5fff43e74d at linaro.org/


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v6.8-rockchip-dts64-1

for you to fetch changes up to 8174dff9e583f7791dacf6d8ce034eb18ec2b292:

  arm64: dts: rockchip: Add Anbernic RG351V (2023-12-12 21:43:48 +0100)

----------------------------------------------------------------
New boards are the Anberic RG351V handheld (rk3326), Theobroma Systems Jaguar
SBC (rk3588), Powkiddy X55 and RK2023 handheld (rk3566), Edgeble-Neu6b (rk3588)

The rk3588 got attention with one working usb3 host on Rock-5a/5b, Orangepi-5
and audio for the EVB1.

Some smaller improvements for the other socs (fifo-depths on rk3328,
gpio-line-names on rk3308-rock-pi-s, gpu power-coefficients on rk3399,
and a fix for the newly converted gpio-fan yaml binding).

Also a number of aliases were moved. Always-numbered core busses can have their
aliases in the soc dtsi, as is done in a number of cases already and other alises
like ethernet really should be per board.

----------------------------------------------------------------
Chris Morgan (8):
      dt-bindings: arm: rockchip: Add Powkiddy RK2023
      arm64: dts: rockchip: Update powkiddy,rgb30 include to rk2023 DTSI
      arm64: dts: rockchip: Add Powkiddy RK2023
      dt-bindings: arm: rockchip: Add Powkiddy X55
      arm64: dts: rockchip: Add Powkiddy X55
      dt-bindings: arm: rockchip: Add Anbernic RG351V
      arm64: dts: rockchip: Split RG351M from Odroid Go Advance
      arm64: dts: rockchip: Add Anbernic RG351V

David Heidelberg (1):
      arm64: dts: rockchip: make dts use gpio-fan matrix instead of array

Dragan Simic (6):
      arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for RK3399
      arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for RK3368
      arm64: dts: rockchip: Remove ethernetX aliases from the SoC dtsi for RK3328
      arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi for PX30
      arm64: dts: rockchip: Add ethernet0 alias to the dts for RK3566 boards
      arm64: dts: rockchip: Add ethernet0 alias to the dts for RK3588(S) boards

Heiko Stuebner (6):
      dt-bindings: arm: rockchip: Add Theobroma-Systems Jaguar SBC
      arm64: dts: rockchip: add Theobroma Jaguar SBC
      arm64: dts: rockchip: move rk3588 serial aliases to soc dtsi
      arm64: dts: rockchip: add rk3588 i2c aliases to soc dtsi
      arm64: dts: rockchip: add rk3588 gpio aliases to soc dtsi
      arm64: dts: rockchip: add rk3588 spi aliases to soc dtsi

Jagan Teki (2):
      dt-bindings: arm: rockchip: Update edgeble-neu6 bindings
      arm64: dts: rockchip: Use NCM6A-IO board for edgeble-neu6b

Jimmy Hon (1):
      arm64: dts: rockchip: add USB3 host on rk3588s-orangepi-5

Johan Jonker (1):
      arm64: dts: rockchip: add gpio alias for gpio dt nodes

Lukasz Luba (1):
      arm64: dts: rockchip: Add dynamic-power-coefficient to rk3399 GPU

Sebastian Reichel (3):
      arm64: dts: rockchip: add analog audio to RK3588 EVB1
      arm64: dts: rockchip: add USB3 host to rock-5b
      arm64: dts: rockchip: add USB3 host to rock-5a

Trevor Woerner (1):
      arm64: dts: rockchip: add gpio-line-names to rk3308-rock-pi-s

shironeko (1):
      arm64: dts: rockchip: add missing tx/rx-fifo-depth for rk3328 gmac

 .../devicetree/bindings/arm/rockchip.yaml          |  32 +-
 arch/arm64/boot/dts/rockchip/Makefile              |   4 +
 .../boot/dts/rockchip/px30-engicam-common.dtsi     |   1 +
 arch/arm64/boot/dts/rockchip/px30-evb.dts          |   1 +
 .../boot/dts/rockchip/px30-ringneck-haikou.dts     |   1 +
 arch/arm64/boot/dts/rockchip/px30.dtsi             |   1 -
 arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts  |  58 ++
 arch/arm64/boot/dts/rockchip/rk3308.dtsi           |   5 +
 arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts    |   1 +
 .../boot/dts/rockchip/rk3326-anbernic-rg351m.dts   |  18 +-
 .../boot/dts/rockchip/rk3326-anbernic-rg351m.dtsi  | 478 +++++++++++
 .../boot/dts/rockchip/rk3326-anbernic-rg351v.dts   |  44 +
 arch/arm64/boot/dts/rockchip/rk3328-a1.dts         |   1 +
 arch/arm64/boot/dts/rockchip/rk3328-evb.dts        |   1 +
 arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts |   1 +
 .../boot/dts/rockchip/rk3328-orangepi-r1-plus.dts  |   1 +
 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts     |   1 +
 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts  |   2 +
 arch/arm64/boot/dts/rockchip/rk3328-rock64.dts     |   1 +
 arch/arm64/boot/dts/rockchip/rk3328.dtsi           |  10 +-
 arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi       |   1 +
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts    |   1 +
 arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi      |   1 +
 .../boot/dts/rockchip/rk3368-orion-r68-meta.dts    |   1 +
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts        |   1 +
 arch/arm64/boot/dts/rockchip/rk3368.dtsi           |   5 +-
 arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts  |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts        |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-ficus.dts      |   4 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts    |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts |   1 +
 .../dts/rockchip/rk3399-khadas-edge-captain.dts    |   4 +
 .../boot/dts/rockchip/rk3399-khadas-edge-v.dts     |   4 +
 .../boot/dts/rockchip/rk3399-kobol-helios64.dts    |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts  |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi      |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi    |   1 +
 .../boot/dts/rockchip/rk3399-rock-4c-plus.dts      |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi  |   3 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |   7 +-
 .../boot/dts/rockchip/rk3399pro-vmarc-som.dtsi     |   1 +
 .../boot/dts/rockchip/rk3566-powkiddy-rgb30.dts    | 154 +---
 .../boot/dts/rockchip/rk3566-powkiddy-rk2023.dts   |  38 +
 .../boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi  | 875 +++++++++++++++++++
 .../boot/dts/rockchip/rk3566-powkiddy-x55.dts      | 926 +++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts |   5 +-
 .../boot/dts/rockchip/rk3566-radxa-cm3-io.dts      |   1 +
 arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts     |   1 +
 .../boot/dts/rockchip/rk3566-soquartz-blade.dts    |   4 +
 .../boot/dts/rockchip/rk3566-soquartz-cm4.dts      |   4 +
 .../boot/dts/rockchip/rk3566-soquartz-model-a.dts  |   4 +
 arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi  |   1 -
 .../boot/dts/rockchip/rk3588-edgeble-neu6a-io.dts  |   4 -
 .../boot/dts/rockchip/rk3588-edgeble-neu6b-io.dts  |   6 +-
 arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts   |  99 ++-
 arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts     | 803 ++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts  |   1 -
 .../boot/dts/rockchip/rk3588-orangepi-5-plus.dts   |   1 -
 .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts |   2 +-
 arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts    |   9 +-
 .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi |   2 -
 .../boot/dts/rockchip/rk3588s-indiedroid-nova.dts  |   1 -
 .../boot/dts/rockchip/rk3588s-khadas-edge2.dts     |   1 -
 .../arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts |   6 +-
 arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts   |  10 +-
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi          |  32 +
 70 files changed, 3502 insertions(+), 196 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3326-anbernic-rg351m.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3326-anbernic-rg351v.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-x55.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts





From heiko at sntech.de  Tue Dec 12 13:33:47 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 12 Dec 2023 22:33:47 +0100
Subject: [GIT PULL] Rockchip dts32 changes for 6.8 #1
Message-ID: <3197878.5fSG56mABF@phil>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v6.8-rockchip-dts32-1

for you to fetch changes up to 569b26af7919c15a8ce231b4fae29cfbd811f144:

  ARM: dts: rockchip: add hdmi-connector node to rk3036-kylin (2023-12-12 20:38:36 +0100)

----------------------------------------------------------------
New boards are the Geniatech XPI-3128 (RK3128), Sonoff iHost (rv1109)

One "new" soc is the rv1109 which is a two-core variant of the rv1126
and everything else is identical.

Lots of love for the old rk3128 (power-domains, gpu, gmac, usb) and
rv1126 (uart pins, i2c2 special case) and rework of aliases to have
core busses that are hard-numbered in boards and documentation centrally
in the dtsi, but the per board aliases in the boards (ethernet).

Plus the rk3036 got a yaml hdmi binding which required some small fixes.

----------------------------------------------------------------
Alex Bee (14):
      dt-bindings: arm: rockchip: Add Geniatech XPI-3128
      ARM: dts: rockchip: Add sdmmc_det pinctrl for RK3128
      ARM: dts: rockchip: Add Geniatech XPI-3128 RK3128 board
      ARM: dts: rockchip: Add USB host clocks for RK3128
      ARM: dts: rockchip: Add dwc2 otg fifo siztes for RK3128
      ARM: dts: rockchip: Make usbphy the parent of SCLK_USB480M for RK3128
      ARM: dts: rockchip: Add gmac node for RK3128
      ARM: dts: rockchip: Enable gmac for XPI-3128
      ARM: dts: rockchip: Add power-controller for RK3128
      ARM: dts: rockchip: Add GPU node for RK3128
      ARM: dts: rockchip: Enable GPU for XPI-3128
      ARM: dts: rockchip: Move gpio aliases to SoC dtsi for RK3128
      ARM: dts: rockchip: Move i2c aliases to SoC dtsi for RK3128
      ARM: dts: rockchip: Move uart aliases to SoC dtsi for RK3128

Johan Jonker (3):
      ARM: dts: rockchip: add gpio alias for gpio dt nodes
      ARM: dts: rockchip: fix rk3036 hdmi ports node
      ARM: dts: rockchip: add hdmi-connector node to rk3036-kylin

Tim Lunn (7):
      ARM: dts: rockchip: Add alternate UART pins to rv1126
      ARM: dts: rockchip: Serial aliases for rv1126
      ARM: dts: rockchip: Add i2c2 node to rv1126
      ARM: dts: rockchip: Split up rgmii1 pinctrl on rv1126
      ARM: dts: rockchip: Add rv1109 SoC
      dt-bindings: arm: rockchip: Add Sonoff iHost
      ARM: dts: rockchip: Add Sonoff iHost Smart Home Hub

 .../devicetree/bindings/arm/rockchip.yaml          |  12 +
 arch/arm/boot/dts/rockchip/Makefile                |   3 +
 arch/arm/boot/dts/rockchip/rk3036-kylin.dts        |  17 +
 arch/arm/boot/dts/rockchip/rk3036.dtsi             |  17 +-
 arch/arm/boot/dts/rockchip/rk3066a.dtsi            |   5 +
 arch/arm/boot/dts/rockchip/rk3128-evb.dts          |   5 -
 arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts     | 425 +++++++++++++++++++++
 arch/arm/boot/dts/rockchip/rk3128.dtsi             | 185 +++++++++
 arch/arm/boot/dts/rockchip/rk322x.dtsi             |   4 +
 arch/arm/boot/dts/rockchip/rk3288.dtsi             |   9 +
 arch/arm/boot/dts/rockchip/rk3xxx.dtsi             |   4 +
 arch/arm/boot/dts/rockchip/rv1109-sonoff-ihost.dts |  21 +
 arch/arm/boot/dts/rockchip/rv1109.dtsi             |  23 ++
 .../boot/dts/rockchip/rv1126-edgeble-neu2-io.dts   |   2 +-
 arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi     |  72 +++-
 arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dts |  29 ++
 .../arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi | 404 ++++++++++++++++++++
 arch/arm/boot/dts/rockchip/rv1126.dtsi             |  21 +
 18 files changed, 1236 insertions(+), 22 deletions(-)
 create mode 100644 arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
 create mode 100644 arch/arm/boot/dts/rockchip/rv1109-sonoff-ihost.dts
 create mode 100644 arch/arm/boot/dts/rockchip/rv1109.dtsi
 create mode 100644 arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dts
 create mode 100644 arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi





From ardb at kernel.org  Tue Dec 12 13:34:31 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Tue, 12 Dec 2023 22:34:31 +0100
Subject: [PATCH v6 08/41] arm64: vmemmap: Avoid base2 order of struct page
 size to dimension region
In-Reply-To: <ZXceH7WLEy2w_t2K@FVFF77S0Q05N.cambridge.arm.com>
References: <20231129111555.3594833-43-ardb@google.com> <20231129111555.3594833-51-ardb@google.com>
 <ZXceH7WLEy2w_t2K@FVFF77S0Q05N.cambridge.arm.com>
Message-ID: <CAMj1kXFM0UemkcKHrwKv6W_O5X-by1pQ99efZzZtJcdEmpc5RA@mail.gmail.com>

On Mon, 11 Dec 2023 at 15:35, Mark Rutland <mark.rutland at arm.com> wrote:
>
> On Wed, Nov 29, 2023 at 12:16:04PM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb at kernel.org>
> >
> > The placement and size of the vmemmap region in the kernel virtual
> > address space is currently derived from the base2 order of the size of a
> > struct page. This makes for nicely aligned constants with lots of
> > leading 0xf and trailing 0x0 digits, but given that the actual struct
> > pages are indexed as an ordinary array, this resulting region is
> > severely overdimensioned when the size of a struct page is just over a
> > power of 2.
> >
> > This doesn't matter today, but once we enable 52-bit virtual addressing
> > for 4k pages configurations, the vmemmap region may take up almost half
> > of the upper VA region with the current struct page upper bound at 64
> > bytes. And once we enable KMSAN or other features that push the size of
> > a struct page over 64 bytes, we will run out of VMALLOC space entirely.
> >
> > So instead, let's derive the region size from the actual size of a
> > struct page, and place the entire region 1 GB from the top of the VA
> > space, where it still doesn't share any lower level translation table
> > entries with the fixmap.
> >
> > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
>
> This is nice, and largely addresses the fear I mentioned on the earlier patches
> move the PCI_IO_* and FIXMAP_* regions. I'd still like to ensure that we have
> assertions that those don't overlap with the VMEMMAP region, but assuming those
> get added to the earlier patches, this looks good as-is:
>
> Acked-by: Mark Rutland <mark.rutland at arm.com>
>

Thanks.

But actually, the only meaningful assert here is that the fixmap does
not grow down into the PCI I/O region. Everything else is hard coded
to unambiguous numeric constants, i.e.

#define VMEMMAP_END             (-UL(SZ_1G))
#define PCI_IO_START            (VMEMMAP_END + SZ_8M)
#define PCI_IO_END              (PCI_IO_START + PCI_IO_SIZE)
#define FIXADDR_TOP             (-UL(SZ_8M))

So I will add the hunk below to

arm64: mm: Move fixmap region above vmemmap region

but adding a static assert that a region that starts at VMEMMAP_END+8M
does not overlap with the VMEMMAP region seems rather futile to me.


--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -16,6 +16,9 @@
 #include <asm/pgalloc.h>
 #include <asm/tlbflush.h>

+/* ensure that the fixmap region does not grow down into the PCI I/O region */
+static_assert(FIXADDR_TOT_START > PCI_IO_END);
+
 #define NR_BM_PTE_TABLES \
        SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, PMD_SHIFT)
 #define NR_BM_PMD_TABLES \


From arnd at kernel.org  Tue Dec 12 13:45:22 2023
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 12 Dec 2023 22:45:22 +0100
Subject: [PATCH] leds: sun50i-a100: avoid division-by-zero warning
Message-ID: <20231212214536.175327-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

When CONFIG_COMMON_CLK is disabled, e.g. on an x86 randconfig compile test,
clang reports a field overflow from propagating the result of a division by
zero:

drivers/leds/leds-sun50i-a100.c:309:12: error: call to '__compiletime_assert_265' declared with 'error' attribute: FIELD_PREP: value too large for the field
        control = FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T1H, timing->t1h_ns / cycle_ns) |

Avoid the problem by adding an explicit check for the zero value here. Alternatively
the assertion could be avoided with a Kconfig dependency on COMMON_CLK.

Fixes: 090a25ad9798 ("leds: sun50i-a100: New driver for the A100 LED controller")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/leds/leds-sun50i-a100.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/leds-sun50i-a100.c b/drivers/leds/leds-sun50i-a100.c
index e4a7e692a908..171cefd1ea0d 100644
--- a/drivers/leds/leds-sun50i-a100.c
+++ b/drivers/leds/leds-sun50i-a100.c
@@ -303,9 +303,13 @@ static void sun50i_a100_ledc_set_timing(struct sun50i_a100_ledc *priv)
 {
 	const struct sun50i_a100_ledc_timing *timing = &priv->timing;
 	unsigned long mod_freq = clk_get_rate(priv->mod_clk);
-	u32 cycle_ns = NSEC_PER_SEC / mod_freq;
+	u32 cycle_ns;
 	u32 control;
 
+	if (!mod_freq)
+		return;
+
+	cycle_ns = NSEC_PER_SEC / mod_freq;
 	control = FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T1H, timing->t1h_ns / cycle_ns) |
 		  FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T1L, timing->t1l_ns / cycle_ns) |
 		  FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T0H, timing->t0h_ns / cycle_ns) |
-- 
2.39.2



From arnd at kernel.org  Tue Dec 12 13:46:49 2023
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 12 Dec 2023 22:46:49 +0100
Subject: [PATCH] power: reset: at91: mark at91_wakeup_status non-__init
Message-ID: <20231212214658.213510-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

Two copies of the at91_wakeup_status() function are called by the
respective probe() callbacks and are marked __init, but the probe
functions are no longer annotated that way. This works with gcc because
the functions always get inlined, but clang keeps them separate, which
can lead to executing freed memory:

WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x80 (section: .text) -> at91_wakeup_status (section: .init.text)
WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text)

Drop the incorrect annotation on these.

Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/power/reset/at91-poweroff.c      | 2 +-
 drivers/power/reset/at91-sama5d2_shdwc.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/power/reset/at91-poweroff.c b/drivers/power/reset/at91-poweroff.c
index 126e774e210c..93eece027865 100644
--- a/drivers/power/reset/at91-poweroff.c
+++ b/drivers/power/reset/at91-poweroff.c
@@ -57,7 +57,7 @@ static struct shdwc {
 	void __iomem *mpddrc_base;
 } at91_shdwc;
 
-static void __init at91_wakeup_status(struct platform_device *pdev)
+static void at91_wakeup_status(struct platform_device *pdev)
 {
 	const char *reason;
 	u32 reg = readl(at91_shdwc.shdwc_base + AT91_SHDW_SR);
diff --git a/drivers/power/reset/at91-sama5d2_shdwc.c b/drivers/power/reset/at91-sama5d2_shdwc.c
index af95c7b39cb3..959ce0dbe91d 100644
--- a/drivers/power/reset/at91-sama5d2_shdwc.c
+++ b/drivers/power/reset/at91-sama5d2_shdwc.c
@@ -107,7 +107,7 @@ static const unsigned long long sdwc_dbc_period[] = {
 	0, 3, 32, 512, 4096, 32768,
 };
 
-static void __init at91_wakeup_status(struct platform_device *pdev)
+static void at91_wakeup_status(struct platform_device *pdev)
 {
 	struct shdwc *shdw = platform_get_drvdata(pdev);
 	const struct reg_config *rcfg = shdw->rcfg;
-- 
2.39.2



From arnd at kernel.org  Tue Dec 12 13:47:22 2023
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 12 Dec 2023 22:47:22 +0100
Subject: [PATCH] arm64: mediatek: remove broken pmic interrupt property
Message-ID: <20231212214737.230115-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

The pmic is connected to the GIC, which uses four-cell interrupt properties,
but its interrupt is specified as two-cell that would only make sense for
the GPIO irqchip:

arch/arm64/boot/dts/mediatek/mt8195.dtsi:464.4-27: Warning (interrupts_property): /soc/i2c at 11d01000/pmic at 34:#interrupt-cells: size is (8), expected multiple of 16

Remove the interrupt for now to shut up the warning. When someone figures out
what the correct interrupt and parent are, we can add it back.

Fixes: f2b543a191b6 ("arm64: dts: mediatek: add device-tree for Genio 1200 EVK board")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
index 70b465f7c6a7..a409ef998746 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
@@ -238,8 +238,6 @@ &i2c6 {
 	mt6360: pmic at 34 {
 		compatible = "mediatek,mt6360";
 		reg = <0x34>;
-		interrupts = <128 IRQ_TYPE_EDGE_FALLING>;
-		interrupt-names = "IRQB";
 		interrupt-controller;
 		#interrupt-cells = <1>;
 		pinctrl-0 = <&mt6360_pins>;
-- 
2.39.2



From arnd at kernel.org  Tue Dec 12 13:48:38 2023
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 12 Dec 2023 22:48:38 +0100
Subject: [PATCH] ACPI: arm64: export acpi_arch_thermal_cpufreq_pctg
Message-ID: <20231212214843.256622-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

The cpufreq code can be in a loadable module, so the architecture support
for it has to be exported:

ERROR: modpost: "acpi_arch_thermal_cpufreq_pctg" [drivers/acpi/processor.ko] undefined!

Fixes: 310293a2b941 ("ACPI: processor: reduce CPUFREQ thermal reduction pctg for Tegra241")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/acpi/arm64/thermal_cpufreq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/acpi/arm64/thermal_cpufreq.c b/drivers/acpi/arm64/thermal_cpufreq.c
index d524f2cd6044..582854914c5c 100644
--- a/drivers/acpi/arm64/thermal_cpufreq.c
+++ b/drivers/acpi/arm64/thermal_cpufreq.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 #include <linux/acpi.h>
+#include <linux/export.h>
 
 #include "../internal.h"
 
@@ -18,3 +19,4 @@ int acpi_arch_thermal_cpufreq_pctg(void)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(acpi_arch_thermal_cpufreq_pctg);
-- 
2.39.2



From nathan at kernel.org  Tue Dec 12 13:50:02 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Tue, 12 Dec 2023 14:50:02 -0700
Subject: [PATCH] power: reset: at91: mark at91_wakeup_status non-__init
In-Reply-To: <20231212214658.213510-1-arnd@kernel.org>
References: <20231212214658.213510-1-arnd@kernel.org>
Message-ID: <20231212215002.GA3300655@dev-arch.thelio-3990X>

On Tue, Dec 12, 2023 at 10:46:49PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> Two copies of the at91_wakeup_status() function are called by the
> respective probe() callbacks and are marked __init, but the probe
> functions are no longer annotated that way. This works with gcc because
> the functions always get inlined, but clang keeps them separate, which
> can lead to executing freed memory:
> 
> WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x80 (section: .text) -> at91_wakeup_status (section: .init.text)
> WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text)
> 
> Drop the incorrect annotation on these.
> 
> Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
> Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Thanks, I sent the same change three weeks ago at this point:

https://lore.kernel.org/20231120-fix-at91-modpost-warnings-v1-1-813671933863 at kernel.org/

Your commit message is a little better than mine and I don't really care
which one goes in but it would be good if this could get cleared up
soon...

Reviewed-by: Nathan Chancellor <nathan at kernel.org>

> ---
>  drivers/power/reset/at91-poweroff.c      | 2 +-
>  drivers/power/reset/at91-sama5d2_shdwc.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/reset/at91-poweroff.c b/drivers/power/reset/at91-poweroff.c
> index 126e774e210c..93eece027865 100644
> --- a/drivers/power/reset/at91-poweroff.c
> +++ b/drivers/power/reset/at91-poweroff.c
> @@ -57,7 +57,7 @@ static struct shdwc {
>  	void __iomem *mpddrc_base;
>  } at91_shdwc;
>  
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
>  {
>  	const char *reason;
>  	u32 reg = readl(at91_shdwc.shdwc_base + AT91_SHDW_SR);
> diff --git a/drivers/power/reset/at91-sama5d2_shdwc.c b/drivers/power/reset/at91-sama5d2_shdwc.c
> index af95c7b39cb3..959ce0dbe91d 100644
> --- a/drivers/power/reset/at91-sama5d2_shdwc.c
> +++ b/drivers/power/reset/at91-sama5d2_shdwc.c
> @@ -107,7 +107,7 @@ static const unsigned long long sdwc_dbc_period[] = {
>  	0, 3, 32, 512, 4096, 32768,
>  };
>  
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
>  {
>  	struct shdwc *shdw = platform_get_drvdata(pdev);
>  	const struct reg_config *rcfg = shdw->rcfg;
> -- 
> 2.39.2
> 
> 


From dsimic at manjaro.org  Tue Dec 12 13:52:38 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 22:52:38 +0100
Subject: [PATCH 0/4] Remove ethernetX aliases from the SoC dtsi for
 RK3399, RK3368, RK3328 and PX30
In-Reply-To: <170241214697.534713.17361998299651815805.b4-ty@sntech.de>
References: <cover.1702366958.git.dsimic@manjaro.org>
 <170241214697.534713.17361998299651815805.b4-ty@sntech.de>
Message-ID: <953de15233be59ae1b3bf69e0d2e7474@manjaro.org>

On 2023-12-12 21:16, Heiko Stuebner wrote:
> On Tue, 12 Dec 2023 08:53:47 +0100, Dragan Simic wrote:
>> Unlike for the I2C buses, GPIO lines and UARTs, the Rockchip SoC TRMs 
>> and
>> datasheets define no numbering for the built-in GMAC(s) or MAC(s), if 
>> there
>> are more than one found in the particular Rockchip SoC.
>> 
>> Moreover, not all boards or devices based on these SoCs actually use 
>> the
>> built-in GMAC(s) or MAC(s).  Thus, let's remove the ethernetX aliases 
>> from
>> the SoC dtsi files and add them back to the appropriate board and 
>> device
>> dts(i) files.  See also [1] for the initial discussion.
>> 
>> [...]
> 
> Applied, thanks!
> 
> [1/4] arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi 
> for RK3399
>       commit: 8030063ca9b019f9dfb90a654f557d8bb15a97a5
> [2/4] arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi 
> for RK3368
>       commit: 7aab60df473c70f74880267500884b12151b160b
> [3/4] arm64: dts: rockchip: Remove ethernetX aliases from the SoC dtsi
> for RK3328
>       commit: 20a9a7667af6b11b7369073d0186d9c92e52db04
> [4/4] arm64: dts: rockchip: Remove ethernet0 alias from the SoC dtsi 
> for PX30
>       commit: a69907a915e4c15bf7e632cd324ec5c3e38c3afc

Great, thanks!


From dsimic at manjaro.org  Tue Dec 12 13:53:10 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Tue, 12 Dec 2023 22:53:10 +0100
Subject: [PATCH 0/2] arm64: dts: rockchip: Add ethernet0 aliases to the
 dts files for RK3566 and RK3588(S) boards
In-Reply-To: <170241214697.534713.13455667285782606746.b4-ty@sntech.de>
References: <cover.1702368023.git.dsimic@manjaro.org>
 <170241214697.534713.13455667285782606746.b4-ty@sntech.de>
Message-ID: <5da1986c4db2e47c73ef8d33cdfd6fff@manjaro.org>

On 2023-12-12 21:16, Heiko Stuebner wrote:
> On Tue, 12 Dec 2023 09:01:38 +0100, Dragan Simic wrote:
>> To complete the process started with the migration of the ethernet0 
>> aliases
>> from the SoC dtsi files to the board/device dts(i) files, started in 
>> [1],
>> let's add ethernet0 aliases to the board dts files that had it 
>> missing.
>> See also [2] for a related discussion.
>> 
>> At the same time, let's remove the ethernet0 alias from one SoM dtsi 
>> file,
>> which doesn't enable the GMAC, and add the same alias back to the 
>> dependent
>> board dts files, which actually enable the GMAC.
>> 
>> [...]
> 
> Applied, thanks!
> 
> [1/2] arm64: dts: rockchip: Add ethernet0 alias to the dts for RK3566 
> boards
>       commit: 8a5f97b061432f72002b8aa158e372f1b10a079e
> [2/2] arm64: dts: rockchip: Add ethernet0 alias to the dts for 
> RK3588(S) boards
>       commit: a40d30460dda56c6ad308cb338e240bc4a625faa

Great, thanks!


From ahalaney at redhat.com  Tue Dec 12 14:07:36 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Tue, 12 Dec 2023 16:07:36 -0600
Subject: [PATCH net-next v4] net: stmmac: don't create a MDIO bus if
 unnecessary
Message-ID: <20231212-stmmac-no-mdio-node-v4-1-c121068ccd17@redhat.com>

Currently a MDIO bus is created if the devicetree description is either:

    1. Not fixed-link
    2. fixed-link but contains a MDIO bus as well

The "1" case above isn't always accurate. If there's a phy-handle,
it could be referencing a phy on another MDIO controller's bus[1]. In
this case, where the MDIO bus is not described at all, currently
stmmac will make a MDIO bus and scan its address space to discover
phys (of which there are none). This process takes time scanning a bus
that is known to be empty, delaying time to complete probe.

There are also a lot of upstream devicetrees[2] that expect a MDIO bus
to be created, scanned for phys, and the first one found connected
to the MAC. This case can be inferred from the platform description by
not having a phy-handle && not being fixed-link. This hits case "1" in
the current driver's logic, and must be handled in any logic change here
since it is a valid legacy dt-binding.

Let's improve the logic to create a MDIO bus if either:

    - Devicetree contains a MDIO bus
    - !fixed-link && !phy-handle (legacy handling)

This way the case where no MDIO bus should be made is handled, as well
as retaining backwards compatibility with the valid cases.

Below devicetree snippets can be found that explain some of
the cases above more concretely.

Here's[0] a devicetree example where the MAC is both fixed-link and
driving a switch on MDIO (case "2" above). This needs a MDIO bus to
be created:

    &fec1 {
            phy-mode = "rmii";

            fixed-link {
                    speed = <100>;
                    full-duplex;
            };

            mdio1: mdio {
                    switch0: switch0 at 0 {
                            compatible = "marvell,mv88e6190";
                            pinctrl-0 = <&pinctrl_gpio_switch0>;
                    };
            };
    };

Here's[1] an example where there is no MDIO bus or fixed-link for
the ethernet1 MAC, so no MDIO bus should be created since ethernet0
is the MDIO master for ethernet1's phy:

    &ethernet0 {
            phy-mode = "sgmii";
            phy-handle = <&sgmii_phy0>;

            mdio {
                    compatible = "snps,dwmac-mdio";
                    sgmii_phy0: phy at 8 {
                            compatible = "ethernet-phy-id0141.0dd4";
                            reg = <0x8>;
                            device_type = "ethernet-phy";
                    };

                    sgmii_phy1: phy at a {
                            compatible = "ethernet-phy-id0141.0dd4";
                            reg = <0xa>;
                            device_type = "ethernet-phy";
                    };
            };
    };

    &ethernet1 {
            phy-mode = "sgmii";
            phy-handle = <&sgmii_phy1>;
    };

Finally there's descriptions like this[2] which don't describe the
MDIO bus but expect it to be created and the whole address space
scanned for a phy since there's no phy-handle or fixed-link described:

    &gmac {
            phy-supply = <&vcc_lan>;
            phy-mode = "rmii";
            snps,reset-gpio = <&gpio3 RK_PB4 GPIO_ACTIVE_HIGH>;
            snps,reset-active-low;
            snps,reset-delays-us = <0 10000 1000000>;
    };

[0] https://elixir.bootlin.com/linux/v6.5-rc5/source/arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts
[1] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride.dts
[2] https://elixir.bootlin.com/linux/v6.6-rc5/source/arch/arm64/boot/dts/rockchip/rk3368-r88.dts#L164

Reviewed-by: Serge Semin <fancer.lancer at gmail.com>
Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
---
Changes in v4:
- Add a line about why it is advantageous to avoid creating the unused
  bus (Andrew Lunn)
- Use sizeof(var) instead of sizeof(struct ...) (Serge)
- Describe sa8775p MDIO controller in SoC dtsi (Andrew Lunn)
- New patch to handle disabled MDIO bus in stmmac

Changes in v3:
    - Keep logic out of stmmac_probe_config_dt() since it's already massive (Serge)

Changes in v2:
    - Handle the fixed-link + mdio case (Andrew Lunn)
    - Reworded commit message
    - Still handle the "legacy" case mentioned in the commit
    - Bit further refactoring of the function for readability

- Link to v3: https://lore.kernel.org/r/20231207-stmmac-no-mdio-node-v3-1-34b870f2bafb at redhat.com
- Link to v2: https://lore.kernel.org/r/20231206-stmmac-no-mdio-node-v2-1-333cae49b1ca at redhat.com
- Link to v1: https://lore.kernel.org/netdev/20230808120254.11653-1-brgl at bgdev.pl/
---
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 91 +++++++++++++---------
 1 file changed, 54 insertions(+), 37 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1ffde555da47..70eadc83ca68 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -296,62 +296,80 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
 }
 
 /**
- * stmmac_dt_phy - parse device-tree driver parameters to allocate PHY resources
- * @plat: driver data platform structure
- * @np: device tree node
- * @dev: device pointer
- * Description:
- * The mdio bus will be allocated in case of a phy transceiver is on board;
- * it will be NULL if the fixed-link is configured.
- * If there is the "snps,dwmac-mdio" sub-node the mdio will be allocated
- * in any case (for DSA, mdio must be registered even if fixed-link).
- * The table below sums the supported configurations:
- *	-------------------------------
- *	snps,phy-addr	|     Y
- *	-------------------------------
- *	phy-handle	|     Y
- *	-------------------------------
- *	fixed-link	|     N
- *	-------------------------------
- *	snps,dwmac-mdio	|
- *	  even if	|     Y
- *	fixed-link	|
- *	-------------------------------
+ * stmmac_of_get_mdio() - Gets the MDIO bus from the devicetree.
+ * @np: devicetree node
  *
- * It returns 0 in case of success otherwise -ENODEV.
+ * The MDIO bus will be searched for in the following ways:
+ * 1. The compatible is "snps,dwc-qos-ethernet-4.10" && a "mdio" named
+ *    child node exists
+ * 2. A child node with the "snps,dwmac-mdio" compatible is present
+ *
+ * Return: The MDIO node if present otherwise NULL
  */
-static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
-			 struct device_node *np, struct device *dev)
+static struct device_node *stmmac_of_get_mdio(struct device_node *np)
 {
-	bool mdio = !of_phy_is_fixed_link(np);
 	static const struct of_device_id need_mdio_ids[] = {
 		{ .compatible = "snps,dwc-qos-ethernet-4.10" },
 		{},
 	};
+	struct device_node *mdio_node = NULL;
 
 	if (of_match_node(need_mdio_ids, np)) {
-		plat->mdio_node = of_get_child_by_name(np, "mdio");
+		mdio_node = of_get_child_by_name(np, "mdio");
 	} else {
 		/**
 		 * If snps,dwmac-mdio is passed from DT, always register
 		 * the MDIO
 		 */
-		for_each_child_of_node(np, plat->mdio_node) {
-			if (of_device_is_compatible(plat->mdio_node,
+		for_each_child_of_node(np, mdio_node) {
+			if (of_device_is_compatible(mdio_node,
 						    "snps,dwmac-mdio"))
 				break;
 		}
 	}
 
-	if (plat->mdio_node) {
+	return mdio_node;
+}
+
+/**
+ * stmmac_mdio_setup() - Populate platform related MDIO structures.
+ * @plat: driver data platform structure
+ * @np: devicetree node
+ * @dev: device pointer
+ *
+ * This searches for MDIO information from the devicetree.
+ * If an MDIO node is found, it's assigned to plat->mdio_node and
+ * plat->mdio_bus_data is allocated.
+ * If no connection can be determined, just plat->mdio_bus_data is allocated
+ * to indicate a bus should be created and scanned for a phy.
+ * If it's determined there's no MDIO bus needed, both are left NULL.
+ *
+ * This expects that plat->phy_node has already been searched for.
+ *
+ * Return: 0 on success, errno otherwise.
+ */
+static int stmmac_mdio_setup(struct plat_stmmacenet_data *plat,
+			     struct device_node *np, struct device *dev)
+{
+	bool legacy_mdio;
+
+	plat->mdio_node = stmmac_of_get_mdio(np);
+	if (plat->mdio_node)
 		dev_dbg(dev, "Found MDIO subnode\n");
-		mdio = true;
-	}
 
-	if (mdio) {
-		plat->mdio_bus_data =
-			devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data),
-				     GFP_KERNEL);
+	/* Legacy devicetrees allowed for no MDIO bus description and expect
+	 * the bus to be scanned for devices. If there's no phy or fixed-link
+	 * described assume this is the case since there must be something
+	 * connected to the MAC.
+	 */
+	legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
+	if (legacy_mdio)
+		dev_info(dev, "Deprecated MDIO bus assumption used\n");
+
+	if (plat->mdio_node || legacy_mdio) {
+		plat->mdio_bus_data = devm_kzalloc(dev,
+						   sizeof(*plat->mdio_bus_data),
+						   GFP_KERNEL);
 		if (!plat->mdio_bus_data)
 			return -ENOMEM;
 
@@ -471,8 +489,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
 	if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
 		dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
 
-	/* To Configure PHY by using all device-tree supported properties */
-	rc = stmmac_dt_phy(plat, np, &pdev->dev);
+	rc = stmmac_mdio_setup(plat, np, &pdev->dev);
 	if (rc)
 		return ERR_PTR(rc);
 

---
base-commit: e9e952f599f2af1b11c9c5a032d8639ec4c6e4ef
change-id: 20231127-stmmac-no-mdio-node-1db9da8a25d9

Best regards,
-- 
Andrew Halaney <ahalaney at redhat.com>



From ahalaney at redhat.com  Tue Dec 12 14:18:33 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Tue, 12 Dec 2023 16:18:33 -0600
Subject: [PATCH net v2] net: stmmac: Handle disabled MDIO busses from
 devicetree
Message-ID: <20231212-b4-stmmac-handle-mdio-enodev-v2-1-600171acf79f@redhat.com>

Many hardware configurations have the MDIO bus disabled, and are instead
using some other MDIO bus to talk to the MAC's phy.

of_mdiobus_register() returns -ENODEV in this case. Let's handle it
gracefully instead of failing to probe the MAC.

Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.")
Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
---
Changes in v2:
- Improve error handling code (Serge)
- Fix malformed Fixes tag (Simon)
- Link to v1: https://lore.kernel.org/r/20231211-b4-stmmac-handle-mdio-enodev-v1-1-73c20c44f8d6 at redhat.com
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index fa9e7e7040b9..0542cfd1817e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -591,7 +591,11 @@ int stmmac_mdio_register(struct net_device *ndev)
 	new_bus->parent = priv->device;
 
 	err = of_mdiobus_register(new_bus, mdio_node);
-	if (err != 0) {
+	if (err == -ENODEV) {
+		err = 0;
+		dev_info(dev, "MDIO bus is disabled\n");
+		goto bus_register_fail;
+	} else if (err) {
 		dev_err_probe(dev, err, "Cannot register the MDIO bus\n");
 		goto bus_register_fail;
 	}

---
base-commit: bbd220ce4e29ed55ab079007cff0b550895258eb
change-id: 20231211-b4-stmmac-handle-mdio-enodev-82168de68c6a

Best regards,
-- 
Andrew Halaney <ahalaney at redhat.com>



From ricardo.neri-calderon at linux.intel.com  Tue Dec 12 14:25:16 2023
From: ricardo.neri-calderon at linux.intel.com (Ricardo Neri)
Date: Tue, 12 Dec 2023 14:25:16 -0800
Subject: [PATCH v4 1/4] cacheinfo: Check for null last-level cache info
In-Reply-To: <20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com>
References: <20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com>
Message-ID: <20231212222519.12834-2-ricardo.neri-calderon@linux.intel.com>

Before determining the validity of the last-level cache info, ensure that
it has been allocated. Simply checking for non-zero cache_leaves() is not
sufficient, as some architectures (e.g., Intel processors) have non-zero
cache_leaves() before allocation.

Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size().
This function iterates over all online CPUs. However, a CPU may have come
online recently, but its cacheinfo may not have been allocated yet.

Cc: Andreas Herrmann <aherrmann at suse.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Chen Yu <yu.c.chen at intel.com>
Cc: Huang Ying <ying.huang at intel.com>
Cc: Len Brown <len.brown at intel.com>
Cc: Radu Rendec <rrendec at redhat.com>
Cc: Pierre Gondois <Pierre.Gondois at arm.com>
Cc: Pu Wen <puwen at hygon.cn>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki at intel.com>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada at linux.intel.com>
Cc: Will Deacon <will at kernel.org>
Cc: Zhang Rui <rui.zhang at intel.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Signed-off-by: Ricardo Neri <ricardo.neri-calderon at linux.intel.com>
---
Changes since v3:
 * Introduced this patch.

Changes since v2:
 * N/A

Changes since v1:
 * N/A
---

The dereference of a NULL cacheinfo is not observed today because
cache_leaves(cpu) is zero until after init_cache_level() is called
(during the CPU hotplug callback). A subsequent changeset will set
the number of cache leaves earlier and the NULL-pointer dereference
will be observed.
---
 drivers/base/cacheinfo.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index f1e79263fe61..967c5cf3fb1d 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -61,6 +61,9 @@ bool last_level_cache_is_valid(unsigned int cpu)
 	if (!cache_leaves(cpu))
 		return false;
 
+	if (!per_cpu_cacheinfo(cpu))
+		return false;
+
 	llc = per_cpu_cacheinfo_idx(cpu, cache_leaves(cpu) - 1);
 
 	return (llc->attributes & CACHE_ID) || !!llc->fw_token;
-- 
2.25.1



From ricardo.neri-calderon at linux.intel.com  Tue Dec 12 14:25:17 2023
From: ricardo.neri-calderon at linux.intel.com (Ricardo Neri)
Date: Tue, 12 Dec 2023 14:25:17 -0800
Subject: [PATCH v4 2/4] cacheinfo: Allocate memory for memory if not done from the primary CPU
In-Reply-To: <20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com>
References: <20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com>
Message-ID: <20231212222519.12834-3-ricardo.neri-calderon@linux.intel.com>

Commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")
adds functionality that architectures can use to optionally allocate and
build cacheinfo early during boot. Commit 6539cffa9495 ("cacheinfo: Add
arch specific early level initializer") lets secondary CPUs correct (and
reallocate memory) cacheinfo data if needed.

If the early build functionality is not used and cacheinfo does not need
correction, memory for cacheinfo is never allocated. x86 does not use the
early build functionality. Consequently, during the cacheinfo CPU hotplug
callback, last_level_cache_is_valid() attempts to dereference a NULL
pointer:

     BUG: kernel NULL pointer dereference, address: 0000000000000100
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not present page
     PGD 0 P4D 0
     Oops: 0000 [#1] PREEPMT SMP NOPTI
     CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1
     RIP: 0010: last_level_cache_is_valid+0x95/0xe0a

Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if
not done earlier.

Cc: Andreas Herrmann <aherrmann at suse.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Chen Yu <yu.c.chen at intel.com>
Cc: Huang Ying <ying.huang at intel.com>
Cc: Len Brown <len.brown at intel.com>
Cc: Radu Rendec <rrendec at redhat.com>
Cc: Pierre Gondois <Pierre.Gondois at arm.com>
Cc: Pu Wen <puwen at hygon.cn>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki at intel.com>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada at linux.intel.com>
Cc: Will Deacon <will at kernel.org>
Cc: Zhang Rui <rui.zhang at intel.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Reviewed-by: Radu Rendec <rrendec at redhat.com>
Reviewed-by: Sudeep Holla <sudeep.holla at arm.com>
Fixes: 6539cffa9495 ("cacheinfo: Add arch specific early level initializer")
Signed-off-by: Ricardo Neri <ricardo.neri-calderon at linux.intel.com>
---
The motivation for commit 5944ce092b97 was to prevent a BUG splat in
PREEMPT_RT kernels during memory allocation. This splat is not observed on
x86 because the memory allocation for cacheinfo happens in
detect_cache_attributes() from the cacheinfo CPU hotplug callback.

The dereference of a NULL pointer is not observed today because
cache_leaves(cpu) is zero until after init_cache_level() is called (also
during the CPU hotplug callback). A subsequent changeset will set the
number of cache leaves earlier and the NULL-pointer dereference will be
observed.
---
Changes since v3:
 * Added Reviewed-by tag from Radu and Sudeep. Thanks!

Changes since v2:
 * Introduced this patch.

Changes since v1:
 * N/A
---
 drivers/base/cacheinfo.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 967c5cf3fb1d..735ccead190e 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -557,7 +557,11 @@ static inline int init_level_allocate_ci(unsigned int cpu)
 	 */
 	ci_cacheinfo(cpu)->early_ci_levels = false;
 
-	if (cache_leaves(cpu) <= early_leaves)
+	/*
+	 * Some architectures (e.g., x86) do not use early initialization.
+	 * Allocate memory now in such case.
+	 */
+	if (cache_leaves(cpu) <= early_leaves && per_cpu_cacheinfo(cpu))
 		return 0;
 
 	kfree(per_cpu_cacheinfo(cpu));
-- 
2.25.1



From ricardo.neri-calderon at linux.intel.com  Tue Dec 12 14:25:19 2023
From: ricardo.neri-calderon at linux.intel.com (Ricardo Neri)
Date: Tue, 12 Dec 2023 14:25:19 -0800
Subject: [PATCH v4 4/4] x86/cacheinfo: Clean out init_cache_level()
In-Reply-To: <20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com>
References: <20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com>
Message-ID: <20231212222519.12834-5-ricardo.neri-calderon@linux.intel.com>

init_cache_level() no longer has a purpose on x86. It no longer needs to
set num_leaves, and it never had to set num_levels, which was unnecessary
on x86.

Replace it with "return 0" simply to override the weak function, which
would return an error.

Cc: Andreas Herrmann <aherrmann at suse.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Chen Yu <yu.c.chen at intel.com>
CC: Huang Ying <ying.huang at intel.com>
Cc: Len Brown <len.brown at intel.com>
Cc: Radu Rendec <rrendec at redhat.com>
Cc: Pierre Gondois <Pierre.Gondois at arm.com>
Cc: Pu Wen <puwen at hygon.cn>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki at intel.com>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada at linux.intel.com>
Cc: Will Deacon <will at kernel.org>
Cc: Zhang Rui <rui.zhang at intel.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Reviewed-by: Len Brown <len.brown at intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon at linux.intel.com>
---
Changes since v3:
 * Rebased on v6.7-rc5.

Changes since v2:
 * None

Changes since v1:
 * Introduced this patch.
---
 arch/x86/kernel/cpu/cacheinfo.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 4125e53a5ef7..1cfe0921ac67 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -1002,11 +1002,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
 
 int init_cache_level(unsigned int cpu)
 {
-	struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
-
-	if (!this_cpu_ci)
-		return -EINVAL;
-	this_cpu_ci->num_levels = 3;
 	return 0;
 }
 
-- 
2.25.1



From ricardo.neri-calderon at linux.intel.com  Tue Dec 12 14:25:18 2023
From: ricardo.neri-calderon at linux.intel.com (Ricardo Neri)
Date: Tue, 12 Dec 2023 14:25:18 -0800
Subject: [PATCH v4 3/4] x86/cacheinfo: Delete global num_cache_leaves
In-Reply-To: <20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com>
References: <20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com>
Message-ID: <20231212222519.12834-4-ricardo.neri-calderon@linux.intel.com>

Linux remembers cpu_cachinfo::num_leaves per CPU, but x86 initializes all
CPUs from the same global "num_cache_leaves".

This is erroneous on systems such as Meteor Lake, where each CPU has a
distinct num_leaves value. Delete the global "num_cache_leaves" and
initialize num_leaves on each CPU.

Cc: Andreas Herrmann <aherrmann at suse.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Chen Yu <yu.c.chen at intel.com>
Cc: Huang Ying <ying.huang at intel.com>
Cc: Len Brown <len.brown at intel.com>
Cc: Radu Rendec <rrendec at redhat.com>
Cc: Pierre Gondois <Pierre.Gondois at arm.com>
Cc: Pu Wen <puwen at hygon.cn>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki at intel.com>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada at linux.intel.com>
Cc: Will Deacon <will at kernel.org>
Cc: Zhang Rui <rui.zhang at intel.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Reviewed-by: Len Brown <len.brown at intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon at linux.intel.com>
---
After this change, all CPUs will traverse CPUID leaf 0x4 when booted for
the first time. On systems with symmetric cache topologies this is
useless work.

Creating a list of processor models that have asymmetric cache topologies
was considered. The burden of maintaining such list would outweigh the
performance benefit of skipping this extra step.
---
Changes since v3:
 * Rebased on v6.7-rc5.

Changes since v2:
 * None

Changes since v1:
 * Do not make num_cache_leaves a per-CPU variable. Instead, reuse the
   existing per-CPU ci_cpu_cacheinfo variable. (Dave Hansen)
---
 arch/x86/kernel/cpu/cacheinfo.c | 44 +++++++++++++++++++--------------
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index c131c412db89..4125e53a5ef7 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -178,7 +178,16 @@ struct _cpuid4_info_regs {
 	struct amd_northbridge *nb;
 };
 
-static unsigned short num_cache_leaves;
+static inline unsigned int get_num_cache_leaves(unsigned int cpu)
+{
+	return get_cpu_cacheinfo(cpu)->num_leaves;
+}
+
+static inline void
+set_num_cache_leaves(unsigned int nr_leaves, unsigned int cpu)
+{
+	get_cpu_cacheinfo(cpu)->num_leaves = nr_leaves;
+}
 
 /* AMD doesn't have CPUID4. Emulate it here to report the same
    information to the user.  This makes some assumptions about the machine:
@@ -718,19 +727,21 @@ void cacheinfo_hygon_init_llc_id(struct cpuinfo_x86 *c)
 void init_amd_cacheinfo(struct cpuinfo_x86 *c)
 {
 
+	unsigned int cpu = c->cpu_index;
+
 	if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
-		num_cache_leaves = find_num_cache_leaves(c);
+		set_num_cache_leaves(find_num_cache_leaves(c), cpu);
 	} else if (c->extended_cpuid_level >= 0x80000006) {
 		if (cpuid_edx(0x80000006) & 0xf000)
-			num_cache_leaves = 4;
+			set_num_cache_leaves(4, cpu);
 		else
-			num_cache_leaves = 3;
+			set_num_cache_leaves(3, cpu);
 	}
 }
 
 void init_hygon_cacheinfo(struct cpuinfo_x86 *c)
 {
-	num_cache_leaves = find_num_cache_leaves(c);
+	set_num_cache_leaves(find_num_cache_leaves(c), c->cpu_index);
 }
 
 void init_intel_cacheinfo(struct cpuinfo_x86 *c)
@@ -742,19 +753,19 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c)
 	unsigned int l2_id = 0, l3_id = 0, num_threads_sharing, index_msb;
 
 	if (c->cpuid_level > 3) {
-		static int is_initialized;
-
-		if (is_initialized == 0) {
-			/* Init num_cache_leaves from boot CPU */
-			num_cache_leaves = find_num_cache_leaves(c);
-			is_initialized++;
-		}
+		/*
+		 * There should be at least one leaf. A non-zero value means
+		 * that the number of leaves has been initialized.
+		 */
+		if (!get_num_cache_leaves(c->cpu_index))
+			set_num_cache_leaves(find_num_cache_leaves(c),
+					     c->cpu_index);
 
 		/*
 		 * Whenever possible use cpuid(4), deterministic cache
 		 * parameters cpuid leaf to find the cache details
 		 */
-		for (i = 0; i < num_cache_leaves; i++) {
+		for (i = 0; i < get_num_cache_leaves(c->cpu_index); i++) {
 			struct _cpuid4_info_regs this_leaf = {};
 			int retval;
 
@@ -790,14 +801,14 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c)
 	 * Don't use cpuid2 if cpuid4 is supported. For P4, we use cpuid2 for
 	 * trace cache
 	 */
-	if ((num_cache_leaves == 0 || c->x86 == 15) && c->cpuid_level > 1) {
+	if ((!get_num_cache_leaves(c->cpu_index) || c->x86 == 15) && c->cpuid_level > 1) {
 		/* supports eax=2  call */
 		int j, n;
 		unsigned int regs[4];
 		unsigned char *dp = (unsigned char *)regs;
 		int only_trace = 0;
 
-		if (num_cache_leaves != 0 && c->x86 == 15)
+		if (get_num_cache_leaves(c->cpu_index) && c->x86 == 15)
 			only_trace = 1;
 
 		/* Number of times to iterate */
@@ -993,12 +1004,9 @@ int init_cache_level(unsigned int cpu)
 {
 	struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
 
-	if (!num_cache_leaves)
-		return -ENOENT;
 	if (!this_cpu_ci)
 		return -EINVAL;
 	this_cpu_ci->num_levels = 3;
-	this_cpu_ci->num_leaves = num_cache_leaves;
 	return 0;
 }
 
-- 
2.25.1



From quic_bjorande at quicinc.com  Tue Dec 12 14:26:43 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Tue, 12 Dec 2023 14:26:43 -0800
Subject: [PATCH net v4] net: stmmac: dwmac-qcom-ethqos: Fix drops in 10M
 SGMII RX
In-Reply-To: <20231212092208.22393-1-quic_snehshah@quicinc.com>
References: <20231212092208.22393-1-quic_snehshah@quicinc.com>
Message-ID: <20231212222643.GP1766637@hu-bjorande-lv.qualcomm.com>

On Tue, Dec 12, 2023 at 02:52:08PM +0530, Sneh Shah wrote:
> In 10M SGMII mode all the packets are being dropped due to wrong Rx clock.
> SGMII 10MBPS mode needs RX clock divider programmed to avoid drops in Rx.
> Update configure SGMII function with Rx clk divider programming.
> 

Thanks you for the updates!

Reviewed-by: Bjorn Andersson <quic_bjorande at quicinc.com>

> Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
> Tested-by: Andrew Halaney <ahalaney at redhat.com>
> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> ---
> v4 changelog:
> - Updated commit message to add more details on why 10M SGMII Rx is failing
> - Added a macro for Rx clock divider value
> v3 changelog:
> - Added comment to explain why MAC needs to be reconfigured for SGMII
> v2 changelog:
> - Use FIELD_PREP to prepare bifield values in place of GENMASK
> - Add fixes tag
> ---
>  .../net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index d3bf42d0fceb..31631e3f89d0 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -34,6 +34,7 @@
>  #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
>  #define RGMII_CONFIG_PROG_SWAP			BIT(1)
>  #define RGMII_CONFIG_DDR_MODE			BIT(0)
> +#define RGMII_CONFIG_SGMII_CLK_DVDR		GENMASK(18, 10)

Thank you for the clarification of rgmii vs sgmii. Perhaps this could be
made clearer by renaming the rgmii ones as well? In a separate patch
series, of course.

Regards,
Bjorn

>  
>  /* SDCC_HC_REG_DLL_CONFIG fields */
>  #define SDCC_DLL_CONFIG_DLL_RST			BIT(30)
> @@ -78,6 +79,8 @@
>  #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
>  #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
>  
> +#define SGMII_10M_RX_CLK_DVDR			0x31
> +
>  struct ethqos_emac_por {
>  	unsigned int offset;
>  	unsigned int value;
> @@ -598,6 +601,9 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>  	return 0;
>  }
>  
> +/* On interface toggle MAC registers gets reset.
> + * Configure MAC block for SGMII on ethernet phy link up
> + */
>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  {
>  	int val;
> @@ -617,6 +623,10 @@ static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  	case SPEED_10:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> +		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
> +			      FIELD_PREP(RGMII_CONFIG_SGMII_CLK_DVDR,
> +					 SGMII_10M_RX_CLK_DVDR),
> +			      RGMII_IO_MACRO_CONFIG);
>  		break;
>  	}
>  
> -- 
> 2.17.1
> 


From robh at kernel.org  Tue Dec 12 14:44:26 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 12 Dec 2023 16:44:26 -0600
Subject: [PATCH v3 08/13] dt-bindings: imx6q-pcie: Add imx95 pcie
 compatible string
In-Reply-To: <20231211215842.134823-9-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-9-Frank.Li@nxp.com>
Message-ID: <20231212224426.GA2948988-robh@kernel.org>

On Mon, Dec 11, 2023 at 04:58:37PM -0500, Frank Li wrote:
> From: Richard Zhu <hongxing.zhu at nxp.com>
> 
> Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
> Add "atu" and "serdes" to reg-names.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> ---
> 
> Notes:
>     Change from v2 to v3
>     - Remove krzy's ACK tag
>     - Add condition check for imx95, which required more reg-names then old
>     platform, so need Krzy review again,
>     
>     Change from v1 to v2
>     - add Krzy's ACK tag
> 
>  .../bindings/pci/fsl,imx6q-pcie.yaml           | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> index 81bbb8728f0f9..b8fcf8258f031 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> @@ -29,6 +29,7 @@ properties:
>        - fsl,imx8mq-pcie
>        - fsl,imx8mm-pcie
>        - fsl,imx8mp-pcie
> +      - fsl,imx95-pcie
>  
>    reg:
>      items:
> @@ -90,6 +91,22 @@ required:
>  allOf:
>    - $ref: /schemas/pci/snps,dw-pcie.yaml#
>    - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          enum:
> +            - fsl,imx95-pcie
> +    then:
> +      properties:
> +        reg:
> +          minItems: 4
> +        reg-names:
> +          items:
> +            - const: dbi
> +            - const: serdes

Did you test this? It should fail because 'serdes' would need to be 
added to snps,dw-pcie.yaml.

Is this really not a separate phy block? A separate node would be 
ideal. If not, there's already a 'phy' name you can use here. We don't 
want more random names.

Rob


From robh at kernel.org  Tue Dec 12 14:54:26 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 12 Dec 2023 16:54:26 -0600
Subject: [PATCH v3 01/13] PCI: imx6: Simplify clock handling by using
 HAS_CLK_* bitmask
In-Reply-To: <20231212164913.GA21240@thinkpad>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-2-Frank.Li@nxp.com>
 <20231212164913.GA21240@thinkpad>
Message-ID: <20231212225426.GB2948988-robh@kernel.org>

On Tue, Dec 12, 2023 at 10:19:13PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Dec 11, 2023 at 04:58:30PM -0500, Frank Li wrote:
> > Refactors the clock handling logic in the imx6 PCI driver by adding
> > HAS_CLK_* bitmask define for drvdata::flags . Simplifies the code and makes
> > it more maintainable, as future additions of SOC support will only require
> > straightforward changes. The drvdata::flags and a bitmask ensures a cleaner
> > and more scalable switch-case structure for handling clocks.
> > 
> 
> Is there any necessity to validate each clock in the driver? I mean, can't you
> just rely on devicetree to provide enough clocks for the functioning of the PCIe
> controller?
> 
> If you can rely on devicetree (everyone should in an ideal world), then you can
> just use devm_clk_bulk_get_all() to get all available clocks for the SoC and
> just enable/disable whatever is available.

Or just use the *_get_optional() variants of functions. They return NULL 
such that subsequent calls are just NOPs if the resource is not present. 
Of course, they aren't really optional on any given platform in this 
case, but does that really matter.

There isn't an optional variant for phys, but it can be added.

> 
> This will greatly simplify the code.
> 
> Only downside of this approach is, if the devicetree is not supplying enough
> clocks, then it will be difficult to find why PCIe is not working. But this also
> means that the devicetree is screwed.

A sufficient schema should prevent that... That's what they're for, not 
just torturing people to learn json-schema. :)

Rob


From tanmay.shah at amd.com  Tue Dec 12 15:03:53 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Tue, 12 Dec 2023 15:03:53 -0800
Subject: [PATCH v2] dt-bindings: mailbox: add Versal IPI bindings
Message-ID: <20231212230353.888714-1-tanmay.shah@amd.com>

Add documentation for AMD-Xilinx Versal platform Inter Processor Interrupt
controller. Versal IPI controller contains buffer-less IPI which do not
have buffers for message passing. For such IPI channels message buffers
are not expected and only notification to/from remote agent is expected.

Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
---

Changes in v2:
  - Add versal bindings to existing bindings doc instead of separate
    file.
  - Sort required list same as properties list
  - Add minimum and maximum range for xlnx,ipi-id vendor property
  - Move vendor property last in the list
  - Fix description of child node reg property for versal bindings
  - Change commit text

depends on: https://lore.kernel.org/linux-arm-kernel/79f65b96-9015-41c4-b4ee-a82526c9eefc at linaro.org/T/#meeacc5c57a9610b19758d313e5b2d17ab470f646

 .../mailbox/xlnx,zynqmp-ipi-mailbox.yaml      | 172 ++++++++++++++----
 1 file changed, 138 insertions(+), 34 deletions(-)

diff --git a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
index 8b15a0532120..95146adb9631 100644
--- a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
@@ -8,11 +8,11 @@ title: Xilinx IPI(Inter Processor Interrupt) mailbox controller
 
 description: |
   The Xilinx IPI(Inter Processor Interrupt) mailbox controller is to manage
-  messaging between two Xilinx Zynq UltraScale+ MPSoC IPI agents. Each IPI
-  agent owns registers used for notification and buffers for message.
+  messaging between two Xilinx Zynq UltraScale+ MPSoC and Versal IPI agents.
+  Each IPI agent owns registers used for notification and buffers for message.
 
                +-------------------------------------+
-               | Xilinx ZynqMP IPI Controller        |
+               | Xilinx IPI Controller               |
                +-------------------------------------+
     +--------------------------------------------------+
   TF-A                   |                     |
@@ -37,15 +37,13 @@ maintainers:
 
 properties:
   compatible:
-    const: xlnx,zynqmp-ipi-mailbox
+    enum:
+      - xlnx,zynqmp-ipi-mailbox
+      - xlnx,versal-ipi-mailbox
 
   method:
     description: |
       The method of calling the PM-API firmware layer.
-      Permitted values are.
-      - "smc" : SMC #0, following the SMCCC
-      - "hvc" : HVC #0, following the SMCCC
-
     $ref: /schemas/types.yaml#/definitions/string
     enum:
       - smc
@@ -58,16 +56,26 @@ properties:
   '#size-cells':
     const: 2
 
-  xlnx,ipi-id:
-    description: |
-      Remote Xilinx IPI agent ID of which the mailbox is connected to.
-    $ref: /schemas/types.yaml#/definitions/uint32
+  reg:
+    minItems: 1
+    maxItems: 2
+
+  reg-names:
+    minItems: 1
+    maxItems: 2
 
   interrupts:
     maxItems: 1
 
   ranges: true
 
+  xlnx,ipi-id:
+    description: |
+      Remote Xilinx IPI agent ID of which the mailbox is connected to.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 64
+
 patternProperties:
   '^mailbox@[0-9a-f]+$':
     description: Internal ipi mailbox node
@@ -76,57 +84,116 @@ patternProperties:
     properties:
 
       compatible:
-        const: xlnx,zynqmp-ipi-dest-mailbox
+        enum:
+          - xlnx,zynqmp-ipi-dest-mailbox
+          - xlnx,versal-ipi-dest-mailbox
 
-      xlnx,ipi-id:
-        description:
-          Remote Xilinx IPI agent ID of which the mailbox is connected to.
-        $ref: /schemas/types.yaml#/definitions/uint32
+      reg:
+        minItems: 1
+        maxItems: 4
+
+      reg-names:
+        minItems: 1
+        maxItems: 4
 
       '#mbox-cells':
         const: 1
         description:
           It contains tx(0) or rx(1) channel IPI id number.
 
-      reg:
-        maxItems: 4
-
-      reg-names:
-        items:
-          - const: local_request_region
-          - const: local_response_region
-          - const: remote_request_region
-          - const: remote_response_region
+      xlnx,ipi-id:
+        description:
+          Remote Xilinx IPI agent ID of which the mailbox is connected to.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        minimum: 0
+        maximum: 64
 
     required:
       - compatible
       - reg
       - reg-names
       - "#mbox-cells"
-
-additionalProperties: false
-
+      - xlnx,ipi-id
+
+    allOf:
+      - if:
+          properties:
+            compatible:
+              contains:
+                enum:
+                  - xlnx,zynqmp-ipi-dest-mailbox
+        then:
+          properties:
+            reg:
+              items:
+                - description: Host agent request message buffer
+                - description: Host agent response message buffer
+                - description: Remote agent request message buffer
+                - description: Remote agent response message buffer
+
+            reg-names:
+              items:
+                - const: local_request_region
+                - const: local_response_region
+                - const: remote_request_region
+                - const: remote_response_region
+        else:
+          properties:
+            reg:
+              minItems: 1
+              items:
+                - description: Remote IPI agent control register
+                - description: Remote IPI agent optional message buffer
+
+            reg-names:
+              minItems: 1
+              items:
+                - const: ctrl
+                - const: msg
 required:
   - compatible
-  - interrupts
   - '#address-cells'
   - '#size-cells'
+  - interrupts
   - xlnx,ipi-id
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - xlnx,versal-ipi-mailbox
+    then:
+      properties:
+        reg:
+          items:
+            - description: Host IPI agent control registers
+            - description: Host IPI agent optional message buffers
+
+        reg-names:
+          items:
+            - const: ctrl
+            - const: msg
+
+      required:
+        - reg
+        - reg-names
+
+additionalProperties: false
+
+
 examples:
   - |
     #include<dt-bindings/interrupt-controller/arm-gic.h>
 
-    amba {
-      #address-cells = <0x2>;
-      #size-cells = <0x2>;
+    bus {
       zynqmp-mailbox {
         compatible = "xlnx,zynqmp-ipi-mailbox";
         interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
         xlnx,ipi-id = <0>;
         #address-cells = <2>;
         #size-cells = <2>;
-        ranges;
 
         mailbox: mailbox at ff9905c0 {
           compatible = "xlnx,zynqmp-ipi-dest-mailbox";
@@ -144,4 +211,41 @@ examples:
       };
     };
 
+  - |
+    #include<dt-bindings/interrupt-controller/arm-gic.h>
+
+    bus {
+      #address-cells = <2>;
+      #size-cells = <2>;
+      zynqmp-mailbox at ff300000 {
+        compatible = "xlnx,versal-ipi-mailbox";
+        interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+        #address-cells = <2>;
+        #size-cells = <2>;
+        reg = <0x0 0xff300000 0x0 0x1000>,
+              <0x0 0xff990000 0x0 0x1ff>;
+        reg-names = "ctrl", "msg";
+        xlnx,ipi-id = <0>;
+        ranges;
+
+        /* buffered IPI */
+        mailbox at ff340000 {
+          compatible = "xlnx,versal-ipi-dest-mailbox";
+          reg = <0x0 0xff340000 0x0 0x1000>,
+                <0x0 0xff990400 0x0 0x1ff>;
+          reg-names = "ctrl", "msg";
+          #mbox-cells = <1>;
+          xlnx,ipi-id = <4>;
+        };
+
+        /* bufferless IPI */
+        mailbox at ff370000 {
+          compatible = "xlnx,versal-ipi-dest-mailbox";
+          reg = <0x0 0xff370000 0x0 0x1000>;
+          reg-names = "ctrl";
+          #mbox-cells = <1>;
+          xlnx,ipi-id = <7>;
+        };
+      };
+    };
 ...

base-commit: abb240f7a2bd14567ab53e602db562bb683391e6
prerequisite-patch-id: 70017c8eaded5fc85749995b9cf093c6c625fab3
-- 
2.25.1



From daniel at makrotopia.org  Tue Dec 12 15:10:07 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Tue, 12 Dec 2023 23:10:07 +0000
Subject: [PATCH v2] ASoC: mediatek: mt7986: silence error in case of
 -EPROBE_DEFER
Message-ID: <b941a404d97c01ef3e30c49925927b9a7dafeb19.1702422544.git.daniel@makrotopia.org>

If probe is defered no error should be printed. Use dev_err_probe() to
have it muted.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: Maso Huang <maso.huang at mediatek.com>
---
v2: use dev_err_probe()

 sound/soc/mediatek/mt7986/mt7986-wm8960.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/mediatek/mt7986/mt7986-wm8960.c b/sound/soc/mediatek/mt7986/mt7986-wm8960.c
index c1390b3734101..6982e833421d6 100644
--- a/sound/soc/mediatek/mt7986/mt7986-wm8960.c
+++ b/sound/soc/mediatek/mt7986/mt7986-wm8960.c
@@ -144,7 +144,7 @@ static int mt7986_wm8960_machine_probe(struct platform_device *pdev)
 
 	ret = devm_snd_soc_register_card(&pdev->dev, card);
 	if (ret) {
-		dev_err(&pdev->dev, "%s snd_soc_register_card fail: %d\n", __func__, ret);
+		dev_err_probe(&pdev->dev, ret, "%s snd_soc_register_card fail\n", __func__);
 		goto err_of_node_put;
 	}
 
-- 
2.43.0


From Frank.li at nxp.com  Tue Dec 12 15:18:55 2023
From: Frank.li at nxp.com (Frank Li)
Date: Tue, 12 Dec 2023 18:18:55 -0500
Subject: [PATCH v3 01/13] PCI: imx6: Simplify clock handling by using
 HAS_CLK_* bitmask
In-Reply-To: <20231212225426.GB2948988-robh@kernel.org>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-2-Frank.Li@nxp.com>
 <20231212164913.GA21240@thinkpad>
 <20231212225426.GB2948988-robh@kernel.org>
Message-ID: <ZXjqX7uYm3TGFdzE@lizhi-Precision-Tower-5810>

On Tue, Dec 12, 2023 at 04:54:26PM -0600, Rob Herring wrote:
> On Tue, Dec 12, 2023 at 10:19:13PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Dec 11, 2023 at 04:58:30PM -0500, Frank Li wrote:
> > > Refactors the clock handling logic in the imx6 PCI driver by adding
> > > HAS_CLK_* bitmask define for drvdata::flags . Simplifies the code and makes
> > > it more maintainable, as future additions of SOC support will only require
> > > straightforward changes. The drvdata::flags and a bitmask ensures a cleaner
> > > and more scalable switch-case structure for handling clocks.
> > > 
> > 
> > Is there any necessity to validate each clock in the driver? I mean, can't you
> > just rely on devicetree to provide enough clocks for the functioning of the PCIe
> > controller?
> > 
> > If you can rely on devicetree (everyone should in an ideal world), then you can
> > just use devm_clk_bulk_get_all() to get all available clocks for the SoC and
> > just enable/disable whatever is available.
> 
> Or just use the *_get_optional() variants of functions. They return NULL 
> such that subsequent calls are just NOPs if the resource is not present. 
> Of course, they aren't really optional on any given platform in this 
> case, but does that really matter.

I think it'd better use devm_clk_bulk_get() by passed down a clk name list
.clk_names = {"pcie_aux", ...},

So it will not silient when dts are not matched requirement. It is not
complex because only check once at probe.

Frank

> 
> There isn't an optional variant for phys, but it can be added.
> 
> > 
> > This will greatly simplify the code.
> > 
> > Only downside of this approach is, if the devicetree is not supplying enough
> > clocks, then it will be difficult to find why PCIe is not working. But this also
> > means that the devicetree is screwed.
> 
> A sufficient schema should prevent that... That's what they're for, not 
> just torturing people to learn json-schema. :)
> 
> Rob


From kuba at kernel.org  Tue Dec 12 15:23:47 2023
From: kuba at kernel.org (Jakub Kicinski)
Date: Tue, 12 Dec 2023 15:23:47 -0800
Subject: [PATCH v2 net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <CY5PR12MB63727C24923AE855CFF0D425BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com>
References: <CY5PR12MB63727C24923AE855CFF0D425BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com>
Message-ID: <20231212152347.167007f3@kernel.org>

On Tue, 12 Dec 2023 14:05:02 +0000 Jianheng Zhang wrote:
> Adds the HW specific support for Frame Preemption handshaking on XGMAC3+
> cores.
> 
> Signed-off-by: Jianheng Zhang <Jianheng.Zhang at synopsys.com>

I defer to Vladimir on whether to trust that the follow up with
the ethtool API support will come later (and not require rewrite
of existing code); or we should request that it's part of the same
series.
-- 
pw-bot: needs-ack


From Frank.li at nxp.com  Tue Dec 12 15:28:43 2023
From: Frank.li at nxp.com (Frank Li)
Date: Tue, 12 Dec 2023 18:28:43 -0500
Subject: [PATCH v3 08/13] dt-bindings: imx6q-pcie: Add imx95 pcie
 compatible string
In-Reply-To: <20231212224426.GA2948988-robh@kernel.org>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-9-Frank.Li@nxp.com>
 <20231212224426.GA2948988-robh@kernel.org>
Message-ID: <ZXjsq2QtFa2V0BAl@lizhi-Precision-Tower-5810>

On Tue, Dec 12, 2023 at 04:44:26PM -0600, Rob Herring wrote:
> On Mon, Dec 11, 2023 at 04:58:37PM -0500, Frank Li wrote:
> > From: Richard Zhu <hongxing.zhu at nxp.com>
> > 
> > Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
> > Add "atu" and "serdes" to reg-names.
> > 
> > Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> > ---
> > 
> > Notes:
> >     Change from v2 to v3
> >     - Remove krzy's ACK tag
> >     - Add condition check for imx95, which required more reg-names then old
> >     platform, so need Krzy review again,
> >     
> >     Change from v1 to v2
> >     - add Krzy's ACK tag
> > 
> >  .../bindings/pci/fsl,imx6q-pcie.yaml           | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > index 81bbb8728f0f9..b8fcf8258f031 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > @@ -29,6 +29,7 @@ properties:
> >        - fsl,imx8mq-pcie
> >        - fsl,imx8mm-pcie
> >        - fsl,imx8mp-pcie
> > +      - fsl,imx95-pcie
> >  
> >    reg:
> >      items:
> > @@ -90,6 +91,22 @@ required:
> >  allOf:
> >    - $ref: /schemas/pci/snps,dw-pcie.yaml#
> >    - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          enum:
> > +            - fsl,imx95-pcie
> > +    then:
> > +      properties:
> > +        reg:
> > +          minItems: 4
> > +        reg-names:
> > +          items:
> > +            - const: dbi
> > +            - const: serdes
> 
> Did you test this? It should fail because 'serdes' would need to be 
> added to snps,dw-pcie.yaml.

I run "make dt_binding_check DT_SCHEMA_FILES=/pci/", no error report.
And PCIe function can work.

> 
> Is this really not a separate phy block?

This is misc block, which included phy and also include some registers
about SID for each PCI devices. I plan do it later.


> A separate node would be 
> ideal. If not, there's already a 'phy' name you can use here. We don't 
> want more random names.

Chip reference manual call it as 'serdes'. If there are already similar
name, I can reuse it.

> 
> Rob


From florian.fainelli at broadcom.com  Tue Dec 12 15:51:12 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Tue, 12 Dec 2023 15:51:12 -0800
Subject: [PATCH v8 0/2] PCI: brcmstb: Configure appropriate HW CLKREQ#
 mode
In-Reply-To: <20231126201946.ffm3bhg5du2xgztv@mraw.org>
References: <20231113185607.1756-1-james.quinlan@broadcom.com>
 <20231126201946.ffm3bhg5du2xgztv@mraw.org>
Message-ID: <ae49227b-5026-43a4-8e19-aeeb63865a6a@broadcom.com>

On 11/26/23 12:19, Cyril Brulebois wrote:
> Hi Jim,
> 
> Jim Quinlan <james.quinlan at broadcom.com> (2023-11-13):
>> V8 -- Un-advertise L1SS capability when in "no-l1ss" mode (Bjorn)
>>     -- Squashed last two commits of v7 (Bjorn)
>>     -- Fix DT binding description text wrapping (Bjorn)
>>     -- Fix incorrect Spec reference (Bjorn)
>>           s/PCIe Spec/PCIe Express Mini CEM 2.1 specification/
>>     -- Text substitutions (Bjorn)
>>           s/WRT/With respect to/
>>           s/Tclron/T_CLRon/
>>
>> v7 -- Manivannan Sadhasivam suggested (a) making the property look like a
>>        network phy-mode and (b) keeping the code simple (not counting clkreq
>>        signal appearances, un-advertising capabilites, etc).  This is
>>        what I have done.  The property is now "brcm,clkreq-mode" and
>>        the values may be one of "safe", "default", and "no-l1ss".  The
>>        default setting is to employ the most capable power savings mode.
> 
> Still:
> 
> Tested-by: Cyril Brulebois <cyril at debamax.com>

Thanks Cyril! Bjorn, Lorenzo, any chance this can be applied soon? Thanks!
-- 
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231212/4bb3d3ad/attachment.p7s>

From graf at amazon.com  Tue Dec 12 16:04:38 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:38 +0000
Subject: [PATCH 01/15] mm,memblock: Add support for scratch memory
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-2-graf@amazon.com>

With KHO (Kexec HandOver), we need a way to ensure that the new kernel
does not allocate memory on top of any memory regions that the previous
kernel was handing over. But to know where those are, we need to include
them in the reserved memblocks array which may not be big enough to hold
all allocations. To resize the array, we need to allocate memory. That
brings us into a catch 22 situation.

The solution to that is the scratch region: a safe region to operate in.
KHO provides a "scratch region" as part of its metadata. This scratch
region is a single, contiguous memory block that we know does not
contain any KHO allocations. We can exclusively allocate from there until
we finish kernel initialization to a point where it knows about all the
KHO memory reservations. We introduce a new memblock_set_scratch_only()
function that allows KHO to indicate that any memblock allocation must
happen from the scratch region.

Later, we may want to perform another KHO kexec. For that, we reuse the
same scratch region. To ensure that no eventually handed over data gets
allocated inside that scratch region, we flip the semantics of the scratch
region with memblock_clear_scratch_only(): After that call, no allocations
may happen from scratch memblock regions. We will lift that restriction
in the next patch.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 include/linux/memblock.h | 19 +++++++++++++
 mm/Kconfig               |  4 +++
 mm/memblock.c            | 61 +++++++++++++++++++++++++++++++++++++++-
 3 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index ae3bde302f70..14043f5b696f 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -42,6 +42,10 @@ extern unsigned long long max_possible_pfn;
  * kernel resource tree.
  * @MEMBLOCK_RSRV_NOINIT: memory region for which struct pages are
  * not initialized (only for reserved regions).
+ * @MEMBLOCK_SCRATCH: memory region that kexec can pass to the next kernel in
+ * handover mode. During early boot, we do not know about all memory reservations
+ * yet, so we get scratch memory from the previous kernel that we know is good
+ * to use. It is the only memory that allocations may happen from in this phase.
  */
 enum memblock_flags {
 	MEMBLOCK_NONE		= 0x0,	/* No special request */
@@ -50,6 +54,7 @@ enum memblock_flags {
 	MEMBLOCK_NOMAP		= 0x4,	/* don't add to kernel direct mapping */
 	MEMBLOCK_DRIVER_MANAGED = 0x8,	/* always detected via a driver */
 	MEMBLOCK_RSRV_NOINIT	= 0x10,	/* don't initialize struct pages */
+	MEMBLOCK_SCRATCH	= 0x20,	/* scratch memory for kexec handover */
 };
 
 /**
@@ -129,6 +134,8 @@ int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
 int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
 int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
 int memblock_reserved_mark_noinit(phys_addr_t base, phys_addr_t size);
+int memblock_mark_scratch(phys_addr_t base, phys_addr_t size);
+int memblock_clear_scratch(phys_addr_t base, phys_addr_t size);
 
 void memblock_free_all(void);
 void memblock_free(void *ptr, size_t size);
@@ -273,6 +280,11 @@ static inline bool memblock_is_driver_managed(struct memblock_region *m)
 	return m->flags & MEMBLOCK_DRIVER_MANAGED;
 }
 
+static inline bool memblock_is_scratch(struct memblock_region *m)
+{
+	return m->flags & MEMBLOCK_SCRATCH;
+}
+
 int memblock_search_pfn_nid(unsigned long pfn, unsigned long *start_pfn,
 			    unsigned long  *end_pfn);
 void __next_mem_pfn_range(int *idx, int nid, unsigned long *out_start_pfn,
@@ -610,5 +622,12 @@ static inline void early_memtest(phys_addr_t start, phys_addr_t end) { }
 static inline void memtest_report_meminfo(struct seq_file *m) { }
 #endif
 
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+void memblock_set_scratch_only(void);
+void memblock_clear_scratch_only(void);
+#else
+static inline void memblock_set_scratch_only(void) { }
+static inline void memblock_clear_scratch_only(void) { }
+#endif
 
 #endif /* _LINUX_MEMBLOCK_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index 89971a894b60..36f5e7d95195 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -513,6 +513,10 @@ config ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
 config HAVE_MEMBLOCK_PHYS_MAP
 	bool
 
+# Enable memblock support for scratch memory which is needed for KHO
+config MEMBLOCK_SCRATCH
+	bool
+
 config HAVE_FAST_GUP
 	depends on MMU
 	bool
diff --git a/mm/memblock.c b/mm/memblock.c
index 5a88d6d24d79..e89e6c8f9d75 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -106,6 +106,13 @@ unsigned long min_low_pfn;
 unsigned long max_pfn;
 unsigned long long max_possible_pfn;
 
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+/* When set to true, only allocate from MEMBLOCK_SCRATCH ranges */
+static bool scratch_only;
+#else
+#define scratch_only false
+#endif
+
 static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_MEMORY_REGIONS] __initdata_memblock;
 static struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_RESERVED_REGIONS] __initdata_memblock;
 #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
@@ -168,6 +175,10 @@ bool __init_memblock memblock_has_mirror(void)
 
 static enum memblock_flags __init_memblock choose_memblock_flags(void)
 {
+	/* skip non-scratch memory for kho early boot allocations */
+	if (scratch_only)
+		return MEMBLOCK_SCRATCH;
+
 	return system_has_some_mirror ? MEMBLOCK_MIRROR : MEMBLOCK_NONE;
 }
 
@@ -643,7 +654,7 @@ static int __init_memblock memblock_add_range(struct memblock_type *type,
 #ifdef CONFIG_NUMA
 			WARN_ON(nid != memblock_get_region_node(rgn));
 #endif
-			WARN_ON(flags != rgn->flags);
+			WARN_ON(flags != (rgn->flags & ~MEMBLOCK_SCRATCH));
 			nr_new++;
 			if (insert) {
 				if (start_rgn == -1)
@@ -890,6 +901,18 @@ int __init_memblock memblock_physmem_add(phys_addr_t base, phys_addr_t size)
 }
 #endif
 
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+__init_memblock void memblock_set_scratch_only(void)
+{
+	scratch_only = true;
+}
+
+__init_memblock void memblock_clear_scratch_only(void)
+{
+	scratch_only = false;
+}
+#endif
+
 /**
  * memblock_setclr_flag - set or clear flag for a memory region
  * @type: memblock type to set/clear flag for
@@ -1015,6 +1038,33 @@ int __init_memblock memblock_reserved_mark_noinit(phys_addr_t base, phys_addr_t
 				    MEMBLOCK_RSRV_NOINIT);
 }
 
+/**
+ * memblock_mark_scratch - Mark a memory region with flag MEMBLOCK_SCRATCH.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * Only memory regions marked with %MEMBLOCK_SCRATCH will be considered for
+ * allocations during early boot with kexec handover.
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+int __init_memblock memblock_mark_scratch(phys_addr_t base, phys_addr_t size)
+{
+	return memblock_setclr_flag(&memblock.memory, base, size, 1, MEMBLOCK_SCRATCH);
+}
+
+/**
+ * memblock_clear_scratch - Clear flag MEMBLOCK_SCRATCH for a specified region.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+int __init_memblock memblock_clear_scratch(phys_addr_t base, phys_addr_t size)
+{
+	return memblock_setclr_flag(&memblock.memory, base, size, 0, MEMBLOCK_SCRATCH);
+}
+
 static bool should_skip_region(struct memblock_type *type,
 			       struct memblock_region *m,
 			       int nid, int flags)
@@ -1046,6 +1096,14 @@ static bool should_skip_region(struct memblock_type *type,
 	if (!(flags & MEMBLOCK_DRIVER_MANAGED) && memblock_is_driver_managed(m))
 		return true;
 
+	/* In early alloc during kho, we can only consider scratch allocations */
+	if ((flags & MEMBLOCK_SCRATCH) && !memblock_is_scratch(m))
+		return true;
+
+	/* Leave scratch memory alone after scratch-only phase */
+	if (!(flags & MEMBLOCK_SCRATCH) && memblock_is_scratch(m))
+		return true;
+
 	return false;
 }
 
@@ -2211,6 +2269,7 @@ static const char * const flagname[] = {
 	[ilog2(MEMBLOCK_MIRROR)] = "MIRROR",
 	[ilog2(MEMBLOCK_NOMAP)] = "NOMAP",
 	[ilog2(MEMBLOCK_DRIVER_MANAGED)] = "DRV_MNG",
+	[ilog2(MEMBLOCK_SCRATCH)] = "SCRATCH",
 };
 
 static int memblock_debug_show(struct seq_file *m, void *private)
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:37 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:37 +0000
Subject: [PATCH 00/15] kexec: Allow preservation of ftrace buffers
Message-ID: <20231213000452.88295-1-graf@amazon.com>

Kexec today considers itself purely a boot loader: When we enter the new
kernel, any state the previous kernel left behind is irrelevant and the
new kernel reinitializes the system.

However, there are use cases where this mode of operation is not what we
actually want. In virtualization hosts for example, we want to use kexec
to update the host kernel while virtual machine memory stays untouched.
When we add device assignment to the mix, we also need to ensure that
IOMMU and VFIO states are untouched. If we add PCIe peer to peer DMA, we
need to do the same for the PCI subsystem. If we want to kexec while an
SEV-SNP enabled virtual machine is running, we need to preserve the VM
context pages and physical memory. See James' and my Linux Plumbers
Conference 2023 presentation for details:

  https://lpc.events/event/17/contributions/1485/

To start us on the journey to support all the use cases above, this
patch implements basic infrastructure to allow hand over of kernel state
across kexec (Kexec HandOver, aka KHO). As example target, we use ftrace:
With this patch set applied, you can read ftrace records from the
pre-kexec environment in your post-kexec one. This creates a very powerful
debugging and performance analysis tool for kexec. It's also slightly
easier to reason about than full blown VFIO state preservation.

== Alternatives ==

There are alternative approaches to (parts of) the problems above:

  * Memory Pools [1] - preallocated persistent memory region + allocator
  * PRMEM [2] - resizable persistent memory regions with fixed metadata
                pointer on the kernel command line + allocator
  * Pkernfs [3] - preallocated file system for in-kernel data with fixed
                  address location on the kernel command line
  * PKRAM [4] - handover of user space pages using a fixed metadata page
                specified via command line

All of the approaches above fundamentally have the same problem: They
require the administrator to explicitly carve out a physical memory
location because they have no mechanism outside of the kernel command
line to pass data (including memory reservations) between kexec'ing
kernels.

KHO provides that base foundation. We will determine later whether we
still need any of the approaches above for fast bulk memory handover of for
example IOMMU page tables. But IMHO they would all be users of KHO, with
KHO providing the foundational primitive to pass metadata and bulk memory
reservations as well as provide easy versioning for data.

== Documentation ==

If people are happy with the approach in this patch set, I will write up
conclusive documentation including schemas for the metadata as part of its
next iteration. For now, here's a rudimentary overview:

We introduce a metadata file that the kernels pass between each other. How
they pass it is architecture specific. The file's format is a Flattened
Device Tree (fdt) which has a generator and parser already included in
Linux. When the root user enables KHO through /sys/kernel/kho/active, the
kernel invokes callbacks to every driver that supports KHO to serialize
its state. When the actual kexec happens, the fdt is part of the image
set that we boot into. In addition, we keep a "scratch region" available
for kexec: A physically contiguous memory region that is guaranteed to
not have any memory that KHO would preserve.  The new kernel bootstraps
itself using the scratch region and sets all handed over memory as in use.
When drivers initialize that support KHO, they introspect the fdt and
recover their state from it. This includes memory reservations, where the
driver can either discard or claim reservations.

== Limitations ==

I currently only implemented file based kexec. The kernel interfaces
in the patch set are already in place to support user space kexec as well,
but I have not implemented it yet.

== How to Use ==

To use the code, please boot the kernel with the "kho_scratch=" command
line parameter set: "kho_scratch=512M". KHO requires a scratch region.

Make sure to fill ftrace with contents that you want to observe after
kexec.  Then, before you invoke file based "kexec -l", activate KHO:

  # echo 1 > /sys/kernel/kho/active
  # kexec -l Image --initrd=initrd -s
  # kexec -e

The new kernel will boot up and contain the previous kernel's trace
buffers in /sys/kernel/debug/tracing/trace.



Alex

[1] https://lore.kernel.org/all/169645773092.11424.7258549771090599226.stgit at skinsburskii./
[2] https://lore.kernel.org/all/20231016233215.13090-1-madvenka at linux.microsoft.com/
[3] https://lpc.events/event/17/contributions/1485/attachments/1296/2650/jgowans-preserving-across-kexec.pdf
[4] https://lore.kernel.org/kexec/1682554137-13938-1-git-send-email-anthony.yznaga at oracle.com/


Alexander Graf (15):
  mm,memblock: Add support for scratch memory
  memblock: Declare scratch memory as CMA
  kexec: Add Kexec HandOver (KHO) generation helpers
  kexec: Add KHO parsing support
  kexec: Add KHO support to kexec file loads
  arm64: Add KHO support
  x86: Add KHO support
  tracing: Introduce names for ring buffers
  tracing: Introduce names for events
  tracing: Introduce kho serialization
  tracing: Add kho serialization of trace buffers
  tracing: Recover trace buffers from kexec handover
  tracing: Add kho serialization of trace events
  tracing: Recover trace events from kexec handover
  tracing: Add config option for kexec handover

 Documentation/ABI/testing/sysfs-firmware-kho  |   9 +
 Documentation/ABI/testing/sysfs-kernel-kho    |  53 ++
 .../admin-guide/kernel-parameters.txt         |  10 +
 MAINTAINERS                                   |   2 +
 arch/arm64/Kconfig                            |  12 +
 arch/arm64/kernel/setup.c                     |   2 +
 arch/arm64/mm/init.c                          |   8 +
 arch/x86/Kconfig                              |  12 +
 arch/x86/boot/compressed/kaslr.c              |  55 ++
 arch/x86/include/uapi/asm/bootparam.h         |  15 +-
 arch/x86/kernel/e820.c                        |   9 +
 arch/x86/kernel/kexec-bzimage64.c             |  39 ++
 arch/x86/kernel/setup.c                       |  46 ++
 arch/x86/mm/init_32.c                         |   7 +
 arch/x86/mm/init_64.c                         |   7 +
 drivers/of/fdt.c                              |  41 ++
 drivers/of/kexec.c                            |  36 ++
 include/linux/kexec.h                         |  56 ++
 include/linux/memblock.h                      |  19 +
 include/linux/ring_buffer.h                   |   9 +-
 include/linux/trace_events.h                  |   1 +
 include/trace/trace_events.h                  |   2 +
 include/uapi/linux/kexec.h                    |   6 +
 kernel/Makefile                               |   2 +
 kernel/kexec_file.c                           |  41 ++
 kernel/kexec_kho_in.c                         | 298 ++++++++++
 kernel/kexec_kho_out.c                        | 526 ++++++++++++++++++
 kernel/trace/Kconfig                          |  13 +
 kernel/trace/blktrace.c                       |   1 +
 kernel/trace/ring_buffer.c                    | 267 ++++++++-
 kernel/trace/trace.c                          |  76 ++-
 kernel/trace/trace_branch.c                   |   1 +
 kernel/trace/trace_events.c                   |   3 +
 kernel/trace/trace_functions_graph.c          |   4 +-
 kernel/trace/trace_output.c                   | 106 +++-
 kernel/trace/trace_output.h                   |   1 +
 kernel/trace/trace_probe.c                    |   3 +
 kernel/trace/trace_syscalls.c                 |  29 +
 mm/Kconfig                                    |   4 +
 mm/memblock.c                                 |  83 ++-
 40 files changed, 1901 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-kho
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-kho
 create mode 100644 kernel/kexec_kho_in.c
 create mode 100644 kernel/kexec_kho_out.c

-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:39 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:39 +0000
Subject: [PATCH 02/15] memblock: Declare scratch memory as CMA
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-3-graf@amazon.com>

When we finish populating our memory, we don't want to lose the scratch
region as memory we can use for useful data. Do do that, we mark it as
CMA memory. That means that any allocation within it only happens with
movable memory which we can then happily discard for the next kexec.

That way we don't lose the scratch region's memory anymore for
allocations after boot.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 mm/memblock.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index e89e6c8f9d75..44741424dab7 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -16,6 +16,7 @@
 #include <linux/kmemleak.h>
 #include <linux/seq_file.h>
 #include <linux/memblock.h>
+#include <linux/page-isolation.h>
 
 #include <asm/sections.h>
 #include <linux/io.h>
@@ -1100,10 +1101,6 @@ static bool should_skip_region(struct memblock_type *type,
 	if ((flags & MEMBLOCK_SCRATCH) && !memblock_is_scratch(m))
 		return true;
 
-	/* Leave scratch memory alone after scratch-only phase */
-	if (!(flags & MEMBLOCK_SCRATCH) && memblock_is_scratch(m))
-		return true;
-
 	return false;
 }
 
@@ -2153,6 +2150,20 @@ static void __init __free_pages_memory(unsigned long start, unsigned long end)
 	}
 }
 
+static void reserve_scratch_mem(phys_addr_t start, phys_addr_t end)
+{
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+	ulong start_pfn = pageblock_start_pfn(PFN_DOWN(start));
+	ulong end_pfn = pageblock_align(PFN_UP(end));
+	ulong pfn;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn += pageblock_nr_pages) {
+		/* Mark as CMA to prevent kernel allocations in it */
+		set_pageblock_migratetype(pfn_to_page(pfn), MIGRATE_CMA);
+	}
+#endif
+}
+
 static unsigned long __init __free_memory_core(phys_addr_t start,
 				 phys_addr_t end)
 {
@@ -2214,6 +2225,17 @@ static unsigned long __init free_low_memory_core_early(void)
 
 	memmap_init_reserved_pages();
 
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+	/*
+	 * Mark scratch mem as CMA before we return it. That way we ensure that
+	 * no kernel allocations happen on it. That means we can reuse it as
+	 * scratch memory again later.
+	 */
+	__for_each_mem_range(i, &memblock.memory, NULL, NUMA_NO_NODE,
+			     MEMBLOCK_SCRATCH, &start, &end, NULL)
+		reserve_scratch_mem(start, end);
+#endif
+
 	/*
 	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
 	 *  because in some case like Node0 doesn't have RAM installed
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:40 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:40 +0000
Subject: [PATCH 03/15] kexec: Add Kexec HandOver (KHO) generation helpers
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-4-graf@amazon.com>

This patch adds the core infrastructure to generate Kexec HandOver
metadata. Kexec HandOver is a mechanism that allows Linux to preserve
state - arbitrary properties as well as memory locations - across kexec.

It does so using 3 concepts:

  1) Device Tree - Every KHO kexec carries a KHO specific flattened
     device tree blob that describes the state of the system. Device
     drivers can register to KHO to serialize their state before kexec.

  2) Mem cache - A memblocks like structure that contains full page
     ranges of reservations. These can not be part of the architectural
     reservations, because they differ on every kexec.

  3) Scratch Region - A CMA region that we allocate in the first kernel.
     CMA gives us the guarantee that no handover pages land in that
     region, because handover pages must be at a static physical memory
     location. We use this region as the place to load future kexec
     images into which then won't collide with any handover data.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 Documentation/ABI/testing/sysfs-kernel-kho    |  53 +++
 .../admin-guide/kernel-parameters.txt         |  10 +
 MAINTAINERS                                   |   1 +
 include/linux/kexec.h                         |  24 ++
 include/uapi/linux/kexec.h                    |   6 +
 kernel/Makefile                               |   1 +
 kernel/kexec_kho_out.c                        | 316 ++++++++++++++++++
 7 files changed, 411 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-kho
 create mode 100644 kernel/kexec_kho_out.c

diff --git a/Documentation/ABI/testing/sysfs-kernel-kho b/Documentation/ABI/testing/sysfs-kernel-kho
new file mode 100644
index 000000000000..f69e7b81a337
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-kho
@@ -0,0 +1,53 @@
+What:		/sys/kernel/kho/active
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		Kexec HandOver (KHO) allows Linux to transition the state of
+		compatible drivers into the next kexec'ed kernel. To do so,
+		device drivers will serialize their current state into a DT.
+		While the state is serialized, they are unable to perform
+		any modifications to state that was serialized, such as
+		handed over memory allocations.
+
+		When this file contains "1", the system is in the transition
+		state. When contains "0", it is not. To switch between the
+		two states, echo the respective number into this file.
+
+What:		/sys/kernel/kho/dt_max
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		KHO needs to allocate a buffer for the DT that gets
+		generated before it knows the final size. By default, it
+		will allocate 10 MiB for it. You can write to this file
+		to modify the size of that allocation.
+
+What:		/sys/kernel/kho/scratch_len
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		To support continuous KHO kexecs, we need to reserve a
+		physically contiguous memory region that will always stay
+		available for future kexec allocations. This file describes
+		the length of that memory region. Kexec user space tooling
+		can use this to determine where it should place its payload
+		images.
+
+What:		/sys/kernel/kho/scratch_phys
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		To support continuous KHO kexecs, we need to reserve a
+		physically contiguous memory region that will always stay
+		available for future kexec allocations. This file describes
+		the physical location of that memory region. Kexec user space
+		tooling can use this to determine where it should place its
+		payload images.
+
+What:		/sys/kernel/kho/dt
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		When KHO is active, the kernel exposes the generated DT that
+		carries its current KHO state in this file. Kexec user space
+		tooling can use this as input file for the KHO payload image.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 51575cd31741..efeef075617e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2504,6 +2504,16 @@
 	kgdbwait	[KGDB] Stop kernel execution and enter the
 			kernel debugger at the earliest opportunity.
 
+	kho_scratch=n[KMG]	[KEXEC] Sets the size of the KHO scratch
+			region. The KHO scratch region is a physically
+			memory range that can only be used for non-kernel
+			allocations. That way, even when memory is heavily
+			fragmented with handed over memory, kexec will always
+			be able to find contiguous memory to place the next
+			kernel for kexec into.
+
+			The default is 0.
+
 	kmac=		[MIPS] Korina ethernet MAC address.
 			Configure the RouterBoard 532 series on-chip
 			Ethernet adapter MAC address.
diff --git a/MAINTAINERS b/MAINTAINERS
index 788be9ab5b73..4ebf7c5fd424 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11769,6 +11769,7 @@ M:	Eric Biederman <ebiederm at xmission.com>
 L:	kexec at lists.infradead.org
 S:	Maintained
 W:	http://kernel.org/pub/linux/utils/kernel/kexec/
+F:	Documentation/ABI/testing/sysfs-kernel-kho
 F:	include/linux/kexec.h
 F:	include/uapi/linux/kexec.h
 F:	kernel/kexec*
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 8227455192b7..db2597e5550d 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -21,6 +21,8 @@
 
 #include <uapi/linux/kexec.h>
 #include <linux/verification.h>
+#include <linux/libfdt.h>
+#include <linux/notifier.h>
 
 extern note_buf_t __percpu *crash_notes;
 
@@ -516,6 +518,28 @@ void set_kexec_sig_enforced(void);
 static inline void set_kexec_sig_enforced(void) {}
 #endif
 
+#ifdef CONFIG_KEXEC_KHO
+/* Notifier index */
+enum kho_event {
+	KEXEC_KHO_DUMP = 0,
+	KEXEC_KHO_ABORT = 1,
+};
+
+extern phys_addr_t kho_scratch_phys;
+extern phys_addr_t kho_scratch_len;
+
+/* egest handover metadata */
+void kho_reserve(void);
+int register_kho_notifier(struct notifier_block *nb);
+int unregister_kho_notifier(struct notifier_block *nb);
+bool kho_is_active(void);
+#else
+static inline void kho_reserve(void) { }
+static inline int register_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
+static inline int unregister_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
+static inline bool kho_is_active(void) { return false; }
+#endif
+
 #endif /* !defined(__ASSEBMLY__) */
 
 #endif /* LINUX_KEXEC_H */
diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
index 01766dd839b0..d02ffd5960d6 100644
--- a/include/uapi/linux/kexec.h
+++ b/include/uapi/linux/kexec.h
@@ -49,6 +49,12 @@
 /* The artificial cap on the number of segments passed to kexec_load. */
 #define KEXEC_SEGMENT_MAX 16
 
+/* KHO passes an array of kho_mem as "mem cache" to the new kernel */
+struct kho_mem {
+	__u64 addr;
+	__u64 len;
+};
+
 #ifndef __KERNEL__
 /*
  * This structure is used to hold the arguments that are used when
diff --git a/kernel/Makefile b/kernel/Makefile
index 3947122d618b..a6bd31e22c09 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC_FILE) += kexec_file.o
 obj-$(CONFIG_KEXEC_ELF) += kexec_elf.o
+obj-$(CONFIG_KEXEC_KHO) += kexec_kho_out.o
 obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
 obj-$(CONFIG_COMPAT) += compat.o
 obj-$(CONFIG_CGROUPS) += cgroup/
diff --git a/kernel/kexec_kho_out.c b/kernel/kexec_kho_out.c
new file mode 100644
index 000000000000..e6184bde5c10
--- /dev/null
+++ b/kernel/kexec_kho_out.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * kexec_kho_out.c - kexec handover code to egest metadata.
+ * Copyright (C) 2023 Alexander Graf <graf at amazon.com>
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/cma.h>
+#include <linux/kexec.h>
+#include <linux/device.h>
+#include <linux/compiler.h>
+#include <linux/kmsg_dump.h>
+
+struct kho_out {
+	struct kobject *kobj;
+	bool active;
+	struct cma *cma;
+	struct blocking_notifier_head chain_head;
+	void *dt;
+	u64 dt_len;
+	u64 dt_max;
+	struct mutex lock;
+};
+
+static struct kho_out kho = {
+	.dt_max = (1024 * 1024 * 10),
+	.chain_head = BLOCKING_NOTIFIER_INIT(kho.chain_head),
+	.lock = __MUTEX_INITIALIZER(kho.lock),
+};
+
+/*
+ * Size for scratch (non-KHO) memory. With KHO enabled, memory can become
+ * fragmented because KHO regions may be anywhere in physical address
+ * space. The scratch region gives us a safe zone that we will never see
+ * KHO allocations from. This is where we can later safely load our new kexec
+ * images into.
+ */
+static phys_addr_t kho_scratch_size __initdata;
+
+int register_kho_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_register(&kho.chain_head, nb);
+}
+EXPORT_SYMBOL_GPL(register_kho_notifier);
+
+int unregister_kho_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_unregister(&kho.chain_head, nb);
+}
+EXPORT_SYMBOL_GPL(unregister_kho_notifier);
+
+bool kho_is_active(void)
+{
+	return kho.active;
+}
+EXPORT_SYMBOL_GPL(kho_is_active);
+
+static ssize_t raw_read(struct file *file, struct kobject *kobj,
+			struct bin_attribute *attr, char *buf,
+			loff_t pos, size_t count)
+{
+	mutex_lock(&kho.lock);
+	memcpy(buf, attr->private + pos, count);
+	mutex_unlock(&kho.lock);
+
+	return count;
+}
+
+static BIN_ATTR(dt, 0400, raw_read, NULL, 0);
+
+static int kho_expose_dt(void *fdt)
+{
+	long fdt_len = fdt_totalsize(fdt);
+	int err;
+
+	kho.dt = fdt;
+	kho.dt_len = fdt_len;
+
+	bin_attr_dt.size = fdt_totalsize(fdt);
+	bin_attr_dt.private = fdt;
+	err = sysfs_create_bin_file(kho.kobj, &bin_attr_dt);
+
+	return err;
+}
+
+static void kho_abort(void)
+{
+	if (!kho.active)
+		return;
+
+	sysfs_remove_bin_file(kho.kobj, &bin_attr_dt);
+
+	kvfree(kho.dt);
+	kho.dt = NULL;
+	kho.dt_len = 0;
+
+	blocking_notifier_call_chain(&kho.chain_head, KEXEC_KHO_ABORT, NULL);
+
+	kho.active = false;
+}
+
+static int kho_serialize(void)
+{
+	void *fdt = NULL;
+	int err;
+
+	kho.active = true;
+	err = -ENOMEM;
+
+	fdt = kvmalloc(kho.dt_max, GFP_KERNEL);
+	if (!fdt)
+		goto out;
+
+	if (fdt_create(fdt, kho.dt_max)) {
+		err = -EINVAL;
+		goto out;
+	}
+
+	err = fdt_finish_reservemap(fdt);
+	if (err)
+		goto out;
+
+	err = fdt_begin_node(fdt, "");
+	if (err)
+		goto out;
+
+	err = fdt_property_string(fdt, "compatible", "kho-v1");
+	if (err)
+		goto out;
+
+	/* Loop through all kho dump functions */
+	err = blocking_notifier_call_chain(&kho.chain_head, KEXEC_KHO_DUMP, fdt);
+	err = notifier_to_errno(err);
+	if (err)
+		goto out;
+
+	/* Close / */
+	err =  fdt_end_node(fdt);
+	if (err)
+		goto out;
+
+	err = fdt_finish(fdt);
+	if (err)
+		goto out;
+
+	if (WARN_ON(fdt_check_header(fdt))) {
+		err = -EINVAL;
+		goto out;
+	}
+
+	err = kho_expose_dt(fdt);
+
+out:
+	if (err) {
+		pr_err("kho failed to serialize state: %d", err);
+		kho_abort();
+	}
+	return err;
+}
+
+/* Handling for /sys/kernel/kho */
+
+#define KHO_ATTR_RO(_name) static struct kobj_attribute _name##_attr = __ATTR_RO_MODE(_name, 0400)
+#define KHO_ATTR_RW(_name) static struct kobj_attribute _name##_attr = __ATTR_RW_MODE(_name, 0600)
+
+static ssize_t active_store(struct kobject *dev, struct kobj_attribute *attr,
+			    const char *buf, size_t size)
+{
+	ssize_t retsize = size;
+	bool val = false;
+	int ret;
+
+	if (kstrtobool(buf, &val) < 0)
+		return -EINVAL;
+
+	if (!kho_scratch_len)
+		return -ENOMEM;
+
+	mutex_lock(&kho.lock);
+	if (val != kho.active) {
+		if (val) {
+			ret = kho_serialize();
+			if (ret) {
+				retsize = -EINVAL;
+				goto out;
+			}
+		} else {
+			kho_abort();
+		}
+	}
+
+out:
+	mutex_unlock(&kho.lock);
+	return retsize;
+}
+
+static ssize_t active_show(struct kobject *dev, struct kobj_attribute *attr,
+			   char *buf)
+{
+	ssize_t ret;
+
+	mutex_lock(&kho.lock);
+	ret = sysfs_emit(buf, "%d\n", kho.active);
+	mutex_unlock(&kho.lock);
+
+	return ret;
+}
+KHO_ATTR_RW(active);
+
+static ssize_t dt_max_store(struct kobject *dev, struct kobj_attribute *attr,
+			    const char *buf, size_t size)
+{
+	u64 val;
+
+	if (kstrtoull(buf, 0, &val))
+		return -EINVAL;
+
+	kho.dt_max = val;
+
+	return size;
+}
+
+static ssize_t dt_max_show(struct kobject *dev, struct kobj_attribute *attr,
+			   char *buf)
+{
+	return sysfs_emit(buf, "0x%llx\n", kho.dt_max);
+}
+KHO_ATTR_RW(dt_max);
+
+static ssize_t scratch_len_show(struct kobject *dev, struct kobj_attribute *attr,
+				char *buf)
+{
+	return sysfs_emit(buf, "0x%llx\n", kho_scratch_len);
+}
+KHO_ATTR_RO(scratch_len);
+
+static ssize_t scratch_phys_show(struct kobject *dev, struct kobj_attribute *attr,
+				 char *buf)
+{
+	return sysfs_emit(buf, "0x%llx\n", kho_scratch_phys);
+}
+KHO_ATTR_RO(scratch_phys);
+
+static __init int kho_out_init(void)
+{
+	int ret = 0;
+
+	kho.kobj = kobject_create_and_add("kho", kernel_kobj);
+	if (!kho.kobj) {
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	ret = sysfs_create_file(kho.kobj, &active_attr.attr);
+	if (ret)
+		goto err;
+
+	ret = sysfs_create_file(kho.kobj, &dt_max_attr.attr);
+	if (ret)
+		goto err;
+
+	ret = sysfs_create_file(kho.kobj, &scratch_phys_attr.attr);
+	if (ret)
+		goto err;
+
+	ret = sysfs_create_file(kho.kobj, &scratch_len_attr.attr);
+	if (ret)
+		goto err;
+
+err:
+	return ret;
+}
+late_initcall(kho_out_init);
+
+static int __init early_kho_scratch(char *p)
+{
+	kho_scratch_size = memparse(p, &p);
+	return 0;
+}
+early_param("kho_scratch", early_kho_scratch);
+
+/**
+ * kho_reserve - Reserve a contiguous chunk of memory for kexec
+ *
+ * With KHO we can preserve arbitrary pages in the system. To ensure we still
+ * have a large contiguous region of memory when we search the physical address
+ * space for target memory, let's make sure we always have a large CMA region
+ * active. This CMA region will only be used for movable pages which are not a
+ * problem for us during KHO because we can just move them somewhere else.
+ */
+__init void kho_reserve(void)
+{
+	int r;
+
+	if (kho_get_fdt()) {
+		/*
+		 * We came from a previous KHO handover, so we already have
+		 * a known good scratch region that we preserve. No need to
+		 * allocate another.
+		 */
+		return;
+	}
+
+	/* Only allocate KHO scratch memory when we're asked to */
+	if (!kho_scratch_size)
+		return;
+
+	r = cma_declare_contiguous_nid(0, kho_scratch_size, 0, PAGE_SIZE, 0,
+				       false, "kho", &kho.cma, NUMA_NO_NODE);
+	if (WARN_ON(r))
+		return;
+
+	kho_scratch_phys = cma_get_base(kho.cma);
+	kho_scratch_len = cma_get_size(kho.cma);
+}
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:41 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:41 +0000
Subject: [PATCH 04/15] kexec: Add KHO parsing support
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-5-graf@amazon.com>

When we have a KHO kexec, we get a device tree, mem cache and scratch
region to populate the state of the system. Provide helper functions
that allow architecture code to easily handle memory reservations based
on them and give device drivers visibility into the KHO DT and memory
reservations so they can recover their own state.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 Documentation/ABI/testing/sysfs-firmware-kho |   9 +
 MAINTAINERS                                  |   1 +
 include/linux/kexec.h                        |  23 ++
 kernel/Makefile                              |   1 +
 kernel/kexec_kho_in.c                        | 298 +++++++++++++++++++
 5 files changed, 332 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-kho
 create mode 100644 kernel/kexec_kho_in.c

diff --git a/Documentation/ABI/testing/sysfs-firmware-kho b/Documentation/ABI/testing/sysfs-firmware-kho
new file mode 100644
index 000000000000..e4ed2cb7c810
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-kho
@@ -0,0 +1,9 @@
+What:		/sys/firmware/kho/dt
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		When the kernel was booted with Kexec HandOver (KHO),
+		the device tree that carries metadata about the previous
+		kernel's state is in this file. This file may disappear
+		when all consumers of it finished to interpret their
+		metadata.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4ebf7c5fd424..ec92a0dd628d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11769,6 +11769,7 @@ M:	Eric Biederman <ebiederm at xmission.com>
 L:	kexec at lists.infradead.org
 S:	Maintained
 W:	http://kernel.org/pub/linux/utils/kernel/kexec/
+F:	Documentation/ABI/testing/sysfs-firmware-kho
 F:	Documentation/ABI/testing/sysfs-kernel-kho
 F:	include/linux/kexec.h
 F:	include/uapi/linux/kexec.h
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index db2597e5550d..a3c4fee6f86a 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -528,12 +528,35 @@ enum kho_event {
 extern phys_addr_t kho_scratch_phys;
 extern phys_addr_t kho_scratch_len;
 
+/* ingest handover metadata */
+void kho_reserve_mem(void);
+void kho_populate(phys_addr_t dt_phys, phys_addr_t scratch_phys, u64 scratch_len,
+		  phys_addr_t mem_phys, u64 mem_len);
+void kho_populate_refcount(void);
+void *kho_get_fdt(void);
+void kho_return_mem(const struct kho_mem *mem);
+void *kho_claim_mem(const struct kho_mem *mem);
+static inline bool is_kho_boot(void)
+{
+	return !!kho_scratch_phys;
+}
+
 /* egest handover metadata */
 void kho_reserve(void);
 int register_kho_notifier(struct notifier_block *nb);
 int unregister_kho_notifier(struct notifier_block *nb);
 bool kho_is_active(void);
 #else
+/* ingest handover metadata */
+static inline void kho_reserve_mem(void) { }
+static inline bool is_kho_boot(void) { return false; }
+static inline void kho_populate(phys_addr_t dt_phys, phys_addr_t scratch_phys,
+				u64 scratch_len, phys_addr_t mem_phys,
+				u64 mem_len) { }
+static inline void kho_populate_refcount(void) { }
+static inline void *kho_get_fdt(void) { return NULL; }
+
+/* egest handover metadata */
 static inline void kho_reserve(void) { }
 static inline int register_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
 static inline int unregister_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
diff --git a/kernel/Makefile b/kernel/Makefile
index a6bd31e22c09..7c3065e40c75 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC_FILE) += kexec_file.o
 obj-$(CONFIG_KEXEC_ELF) += kexec_elf.o
+obj-$(CONFIG_KEXEC_KHO) += kexec_kho_in.o
 obj-$(CONFIG_KEXEC_KHO) += kexec_kho_out.o
 obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
 obj-$(CONFIG_COMPAT) += compat.o
diff --git a/kernel/kexec_kho_in.c b/kernel/kexec_kho_in.c
new file mode 100644
index 000000000000..12ec54fc537a
--- /dev/null
+++ b/kernel/kexec_kho_in.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * kexec_kho_in.c - kexec handover code to ingest metadata.
+ * Copyright (C) 2023 Alexander Graf <graf at amazon.com>
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/kexec.h>
+#include <linux/device.h>
+#include <linux/compiler.h>
+#include <linux/io.h>
+#include <linux/kmsg_dump.h>
+#include <linux/memblock.h>
+
+/* The kho dt during runtime */
+static void *fdt;
+
+/* Globals to hand over phys/len from early to runtime */
+static phys_addr_t handover_phys __initdata;
+static u32 handover_len __initdata;
+
+static phys_addr_t mem_phys __initdata;
+static u32 mem_len __initdata;
+
+phys_addr_t kho_scratch_phys;
+phys_addr_t kho_scratch_len;
+
+void *kho_get_fdt(void)
+{
+	return fdt;
+}
+EXPORT_SYMBOL_GPL(kho_get_fdt);
+
+/**
+ * kho_populate_refcount - Scan the DT for any memory ranges. Increase the
+ * affected pages' refcount by 1 for each.
+ */
+__init void kho_populate_refcount(void)
+{
+	void *fdt = kho_get_fdt();
+	void *mem_virt = __va(mem_phys);
+	int offset = 0, depth = 0, initial_depth = 0, len;
+
+	if (!fdt)
+		return;
+
+	/* Go through the mem list and add 1 for each reference */
+	for (offset = 0;
+	     offset >= 0 && depth >= initial_depth;
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		const struct kho_mem *mems;
+		u32 i;
+
+		mems = fdt_getprop(fdt, offset, "mem", &len);
+		if (!mems || len & (sizeof(*mems) - 1))
+			continue;
+
+		for (i = 0; i < len; i += sizeof(*mems)) {
+			const struct kho_mem *mem = ((void *)mems) + i;
+			u64 start_pfn = PFN_DOWN(mem->addr);
+			u64 end_pfn = PFN_UP(mem->addr + mem->len);
+			u64 pfn;
+
+			for (pfn = start_pfn; pfn < end_pfn; pfn++)
+				get_page(pfn_to_page(pfn));
+		}
+	}
+
+	/*
+	 * Then reduce the reference count by 1 to offset the initial ref count
+	 * of 1. In addition, unreserve the page. That way, we can free_page()
+	 * it for every consumer and automatically free it to the global memory
+	 * pool when everyone is done.
+	 */
+	for (offset = 0; offset < mem_len; offset += sizeof(struct kho_mem)) {
+		struct kho_mem *mem = mem_virt + offset;
+		u64 start_pfn = PFN_DOWN(mem->addr);
+		u64 end_pfn = PFN_UP(mem->addr + mem->len);
+		u64 pfn;
+
+		for (pfn = start_pfn; pfn < end_pfn; pfn++) {
+			struct page *page = pfn_to_page(pfn);
+
+			/*
+			 * This is similar to free_reserved_page(), but
+			 * preserves the reference count
+			 */
+			ClearPageReserved(page);
+			__free_page(page);
+			adjust_managed_page_count(page, 1);
+		}
+	}
+}
+
+static void kho_return_pfn(ulong pfn)
+{
+	struct page *page = pfn_to_page(pfn);
+
+	if (WARN_ON(!page))
+		return;
+	__free_page(page);
+}
+
+/**
+ * kho_return_mem - Notify the kernel that initially reserved memory is no
+ * longer needed. When the last consumer of a page returns their mem, kho
+ * returns the page to the buddy allocator as free page.
+ */
+void kho_return_mem(const struct kho_mem *mem)
+{
+	uint64_t start_pfn, end_pfn, pfn;
+
+	start_pfn = PFN_DOWN(mem->addr);
+	end_pfn = PFN_UP(mem->addr + mem->len);
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		kho_return_pfn(pfn);
+}
+EXPORT_SYMBOL_GPL(kho_return_mem);
+
+static void kho_claim_pfn(ulong pfn)
+{
+	struct page *page = pfn_to_page(pfn);
+
+	WARN_ON(!page);
+	if (WARN_ON(page_count(page) != 1))
+		pr_err("Claimed non kho pfn %lx", pfn);
+}
+
+/**
+ * kho_claim_mem - Notify the kernel that a handed over memory range is now in
+ * use by a kernel subsystem and considered an allocated page. This function
+ * removes the reserved state for all pages that the mem spans.
+ */
+void *kho_claim_mem(const struct kho_mem *mem)
+{
+	u64 start_pfn, end_pfn, pfn;
+	void *va = __va(mem->addr);
+
+	start_pfn = PFN_DOWN(mem->addr);
+	end_pfn = PFN_UP(mem->addr + mem->len);
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		kho_claim_pfn(pfn);
+
+	return va;
+}
+EXPORT_SYMBOL_GPL(kho_claim_mem);
+
+/**
+ * kho_reserve_mem - Adds all memory reservations into memblocks
+ * and moves us out of the scratch only phase. Must be called after page tables
+ * are initialized and memblock_allow_resize().
+ */
+void __init kho_reserve_mem(void)
+{
+	void *mem_virt = __va(mem_phys);
+	int off, err;
+
+	if (!handover_phys || !mem_phys)
+		return;
+
+	/*
+	 * We reached here because we are running inside a working linear map
+	 * that allows us to resize memblocks dynamically. Use the chance and
+	 * populate the global fdt pointer
+	 */
+	fdt = __va(handover_phys);
+
+	off = fdt_path_offset(fdt, "/");
+	if (off < 0) {
+		fdt = NULL;
+		return;
+	}
+
+	err = fdt_node_check_compatible(fdt, off, "kho-v1");
+	if (err) {
+		pr_warn("KHO has invalid compatible, disabling.");
+		return;
+	}
+
+	/* Then populate all preserved memory areas as reserved */
+	for (off = 0; off < mem_len; off += sizeof(struct kho_mem)) {
+		struct kho_mem *mem = mem_virt + off;
+
+		memblock_reserve(mem->addr, mem->len);
+	}
+
+	/* Unreserve the mem cache - we don't need it from here on */
+	memblock_phys_free(mem_phys, mem_len);
+
+	/*
+	 * Now we know about all memory reservations, release the scratch only
+	 * constraint and allow normal allocations from the scratch region.
+	 */
+	memblock_clear_scratch_only();
+}
+
+/* Handling for /sys/firmware/kho */
+static struct kobject *kho_kobj;
+
+static ssize_t raw_read(struct file *file, struct kobject *kobj,
+			struct bin_attribute *attr, char *buf,
+			loff_t pos, size_t count)
+{
+	memcpy(buf, attr->private + pos, count);
+	return count;
+}
+
+static BIN_ATTR(dt, 0400, raw_read, NULL, 0);
+
+static __init int kho_in_init(void)
+{
+	int ret = 0;
+
+	if (!fdt)
+		return 0;
+
+	kho_kobj = kobject_create_and_add("kho", firmware_kobj);
+	if (!kho_kobj) {
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	bin_attr_dt.size = fdt_totalsize(fdt);
+	bin_attr_dt.private = fdt;
+	ret = sysfs_create_bin_file(kho_kobj, &bin_attr_dt);
+	if (ret)
+		goto err;
+
+err:
+	return ret;
+}
+subsys_initcall(kho_in_init);
+
+void __init kho_populate(phys_addr_t handover_dt_phys, phys_addr_t scratch_phys,
+			 u64 scratch_len, phys_addr_t mem_cache_phys,
+			 u64 mem_cache_len)
+{
+	void *handover_dt;
+
+	/* Determine the real size of the DT */
+	handover_dt = early_memremap(handover_dt_phys, sizeof(struct fdt_header));
+	if (!handover_dt) {
+		pr_warn("setup: failed to memremap kexec FDT (0x%llx)\n", handover_dt_phys);
+		return;
+	}
+
+	if (fdt_check_header(handover_dt)) {
+		pr_warn("setup: kexec handover FDT is invalid (0x%llx)\n", handover_dt_phys);
+		early_memunmap(handover_dt, PAGE_SIZE);
+		return;
+	}
+
+	handover_len = fdt_totalsize(handover_dt);
+	handover_phys = handover_dt_phys;
+
+	/* Reserve the DT so we can still access it in late boot */
+	memblock_reserve(handover_phys, handover_len);
+
+	/* Reserve the mem cache so we can still access it later */
+	memblock_reserve(mem_cache_phys, mem_cache_len);
+
+	/*
+	 * We pass a safe contiguous block of memory to use for early boot purporses from
+	 * the previous kernel so that we can resize the memblock array as needed.
+	 */
+	memblock_add(scratch_phys, scratch_len);
+
+	if (WARN_ON(memblock_mark_scratch(scratch_phys, scratch_len))) {
+		pr_err("Kexec failed to mark the scratch region. Disabling KHO.");
+		handover_len = 0;
+		handover_phys = 0;
+		return;
+	}
+	pr_debug("Marked 0x%lx+0x%lx as scratch", (long)scratch_phys, (long)scratch_len);
+
+	/*
+	 * Now that we have a viable region of scratch memory, let's tell the memblocks
+	 * allocator to only use that for any allocations. That way we ensure that nothing
+	 * scribbles over in use data while we initialize the page tables which we will need
+	 * to ingest all memory reservations from the previous kernel.
+	 */
+	memblock_set_scratch_only();
+
+	early_memunmap(handover_dt, sizeof(struct fdt_header));
+
+	/* Remember the mem cache location for kho_reserve_mem() */
+	mem_len = mem_cache_len;
+	mem_phys = mem_cache_phys;
+
+	/* Remember the scratch block - we will reuse it again for the next kexec */
+	kho_scratch_phys = scratch_phys;
+	kho_scratch_len = scratch_len;
+
+	pr_info("setup: Found kexec handover data. Will skip init for some devices\n");
+}
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:42 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:42 +0000
Subject: [PATCH 05/15] kexec: Add KHO support to kexec file loads
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-6-graf@amazon.com>

Kexec has 2 modes: A user space driven mode and a kernel driven mode.
For the kernel driven mode, kernel code determines the physical
addresses of all target buffers that the payload gets copied into.

With KHO, we can only safely copy payloads into the "scratch area".
Teach the kexec file loader about it, so it only allocates for that
area. In addition, enlighten it with support to ask the KHO subsystem
for its respective payloads to copy into target memory. Also teach the
KHO subsystem how to fill the images for file loads.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 include/linux/kexec.h  |   9 ++
 kernel/kexec_file.c    |  41 ++++++++
 kernel/kexec_kho_out.c | 210 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 260 insertions(+)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index a3c4fee6f86a..c8859a2ca872 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -362,6 +362,13 @@ struct kimage {
 	size_t ima_buffer_size;
 #endif
 
+#ifdef CONFIG_KEXEC_KHO
+	struct {
+		struct kexec_buf dt;
+		struct kexec_buf mem_cache;
+	} kho;
+#endif
+
 	/* Core ELF header buffer */
 	void *elf_headers;
 	unsigned long elf_headers_sz;
@@ -543,6 +550,7 @@ static inline bool is_kho_boot(void)
 
 /* egest handover metadata */
 void kho_reserve(void);
+int kho_fill_kimage(struct kimage *image);
 int register_kho_notifier(struct notifier_block *nb);
 int unregister_kho_notifier(struct notifier_block *nb);
 bool kho_is_active(void);
@@ -558,6 +566,7 @@ static inline void *kho_get_fdt(void) { return NULL; }
 
 /* egest handover metadata */
 static inline void kho_reserve(void) { }
+static inline int kho_fill_kimage(struct kimage *image) { return 0; }
 static inline int register_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
 static inline int unregister_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
 static inline bool kho_is_active(void) { return false; }
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index f9a419cd22d4..d895d0a49bd9 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -113,6 +113,13 @@ void kimage_file_post_load_cleanup(struct kimage *image)
 	image->ima_buffer = NULL;
 #endif /* CONFIG_IMA_KEXEC */
 
+#ifdef CONFIG_KEXEC_KHO
+	kvfree(image->kho.mem_cache.buffer);
+	image->kho.mem_cache = (struct kexec_buf) {};
+	kvfree(image->kho.dt.buffer);
+	image->kho.dt = (struct kexec_buf) {};
+#endif
+
 	/* See if architecture has anything to cleanup post load */
 	arch_kimage_file_post_load_cleanup(image);
 
@@ -249,6 +256,11 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd,
 	/* IMA needs to pass the measurement list to the next kernel. */
 	ima_add_kexec_buffer(image);
 
+	/* If KHO is active, add its images to the list */
+	ret = kho_fill_kimage(image);
+	if (ret)
+		goto out;
+
 	/* Call image load handler */
 	ldata = kexec_image_load_default(image);
 
@@ -518,6 +530,24 @@ static int locate_mem_hole_callback(struct resource *res, void *arg)
 	return locate_mem_hole_bottom_up(start, end, kbuf);
 }
 
+#ifdef CONFIG_KEXEC_KHO
+static int kexec_walk_kho_scratch(struct kexec_buf *kbuf,
+				  int (*func)(struct resource *, void *))
+{
+	int ret = 0;
+
+	struct resource res = {
+		.start = kho_scratch_phys,
+		.end = kho_scratch_phys + kho_scratch_len,
+	};
+
+	/* Try to fit the kimage into our KHO scratch region */
+	ret = func(&res, kbuf);
+
+	return ret;
+}
+#endif
+
 #ifdef CONFIG_ARCH_KEEP_MEMBLOCK
 static int kexec_walk_memblock(struct kexec_buf *kbuf,
 			       int (*func)(struct resource *, void *))
@@ -612,6 +642,17 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
 	if (kbuf->mem != KEXEC_BUF_MEM_UNKNOWN)
 		return 0;
 
+#ifdef CONFIG_KEXEC_KHO
+	/*
+	 * If KHO is active, only use KHO scratch memory. All other memory
+	 * could potentially be handed over.
+	 */
+	if (kho_is_active() && kbuf->image->type != KEXEC_TYPE_CRASH) {
+		ret = kexec_walk_kho_scratch(kbuf, locate_mem_hole_callback);
+		return ret == 1 ? 0 : -EADDRNOTAVAIL;
+	}
+#endif
+
 	if (!IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK))
 		ret = kexec_walk_resources(kbuf, locate_mem_hole_callback);
 	else
diff --git a/kernel/kexec_kho_out.c b/kernel/kexec_kho_out.c
index e6184bde5c10..24ced6c3013f 100644
--- a/kernel/kexec_kho_out.c
+++ b/kernel/kexec_kho_out.c
@@ -50,6 +50,216 @@ int unregister_kho_notifier(struct notifier_block *nb)
 }
 EXPORT_SYMBOL_GPL(unregister_kho_notifier);
 
+static int kho_mem_cache_add(void *fdt, struct kho_mem *mem_cache, int size,
+			     struct kho_mem *new_mem)
+{
+	int entries = size / sizeof(*mem_cache);
+	u64 new_start = new_mem->addr;
+	u64 new_end = new_mem->addr + new_mem->len;
+	u64 prev_start = 0;
+	u64 prev_end = 0;
+	int i;
+
+	if (WARN_ON((new_start < (kho_scratch_phys + kho_scratch_len)) &&
+		    (new_end > kho_scratch_phys))) {
+		pr_err("KHO memory runs over scratch memory");
+		return -EINVAL;
+	}
+
+	/*
+	 * We walk the existing sorted mem cache and find the spot where this
+	 * new entry would start, so we can insert it right there.
+	 */
+	for (i = 0; i < entries; i++) {
+		struct kho_mem *mem = &mem_cache[i];
+		u64 mem_end = (mem->addr + mem->len);
+
+		if (mem_end < new_start) {
+			/* No overlap */
+			prev_start = mem->addr;
+			prev_end = mem->addr + mem->len;
+			continue;
+		} else if ((new_start >= mem->addr) && (new_end <= mem_end)) {
+			/* new_mem fits into mem, skip */
+			return size;
+		} else if ((new_end >= mem->addr) && (new_start <= mem_end)) {
+			/* new_mem and mem overlap, fold them */
+			bool remove = false;
+
+			mem->addr = min(new_start, mem->addr);
+			mem->len = max(mem_end, new_end) - mem->addr;
+			mem_end = (mem->addr + mem->len);
+
+			if (i > 0 && prev_end >= mem->addr) {
+				/* We now overlap with the previous mem, fold */
+				struct kho_mem *prev = &mem_cache[i - 1];
+
+				prev->addr = min(prev->addr, mem->addr);
+				prev->len = max(mem_end, prev_end) - prev->addr;
+				remove = true;
+			} else if (i < (entries - 1) && mem_end >= mem_cache[i + 1].addr) {
+				/* We now overlap with the next mem, fold */
+				struct kho_mem *next = &mem_cache[i + 1];
+				u64 next_end = (next->addr + next->len);
+
+				next->addr = min(next->addr, mem->addr);
+				next->len = max(mem_end, next_end) - next->addr;
+				remove = true;
+			}
+
+			if (remove) {
+				/* We folded this mem into another, remove it */
+				memmove(mem, mem + 1, (entries - i - 1) * sizeof(*mem));
+				size -= sizeof(*new_mem);
+			}
+
+			return size;
+		} else if (mem->addr > new_end) {
+			/*
+			 * The mem cache is sorted. If we find the current
+			 * entry start after our new_mem's end, we shot over
+			 * which means we need to add it by creating a new
+			 * hole right after the current entry.
+			 */
+			memmove(mem + 1, mem, (entries - i) * sizeof(*mem));
+			break;
+		}
+	}
+
+	mem_cache[i] = *new_mem;
+	size += sizeof(*new_mem);
+
+	return size;
+}
+
+/**
+ * kho_alloc_mem_cache - Allocate and initialize the mem cache kexec_buf
+ */
+static int kho_alloc_mem_cache(struct kimage *image, void *fdt)
+{
+	int offset, depth, initial_depth, len;
+	void *mem_cache;
+	int size;
+
+	/* Count the elements inside all "mem" properties in the DT */
+	size = offset = depth = initial_depth = 0;
+	for (offset = 0;
+	     offset >= 0 && depth >= initial_depth;
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		const struct kho_mem *mems;
+
+		mems = fdt_getprop(fdt, offset, "mem", &len);
+		if (!mems || len & (sizeof(*mems) - 1))
+			continue;
+		size += len;
+	}
+
+	/* Allocate based on the max size we determined */
+	mem_cache = kvmalloc(size, GFP_KERNEL);
+	if (!mem_cache)
+		return -ENOMEM;
+
+	/* And populate the array */
+	size = offset = depth = initial_depth = 0;
+	for (offset = 0;
+	     offset >= 0 && depth >= initial_depth;
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		const struct kho_mem *mems;
+		int nr_mems, i;
+
+		mems = fdt_getprop(fdt, offset, "mem", &len);
+		if (!mems || len & (sizeof(*mems) - 1))
+			continue;
+
+		for (i = 0, nr_mems = len / sizeof(*mems); i < nr_mems; i++) {
+			const struct kho_mem *mem = &mems[i];
+			ulong mstart = PAGE_ALIGN_DOWN(mem->addr);
+			ulong mend = PAGE_ALIGN(mem->addr + mem->len);
+			struct kho_mem cmem = {
+				.addr = mstart,
+				.len = (mend - mstart),
+			};
+
+			size = kho_mem_cache_add(fdt, mem_cache, size, &cmem);
+			if (size < 0)
+				return size;
+		}
+	}
+
+	image->kho.mem_cache.buffer = mem_cache;
+	image->kho.mem_cache.bufsz = size;
+	image->kho.mem_cache.memsz = size;
+
+	return 0;
+}
+
+int kho_fill_kimage(struct kimage *image)
+{
+	int err = 0;
+	void *dt;
+
+	mutex_lock(&kho.lock);
+
+	if (!kho.active)
+		goto out;
+
+	/* Initialize kexec_buf for mem_cache */
+	image->kho.mem_cache = (struct kexec_buf) {
+		.image = image,
+		.buffer = NULL,
+		.bufsz = 0,
+		.mem = KEXEC_BUF_MEM_UNKNOWN,
+		.memsz = 0,
+		.buf_align = SZ_64K, /* Makes it easier to map */
+		.buf_max = ULONG_MAX,
+		.top_down = true,
+	};
+
+	/*
+	 * We need to make all allocations visible here via the mem_cache so that
+	 * kho_is_destination_range() can identify overlapping regions and ensure
+	 * that no kimage (including the DT one) lands on handed over memory.
+	 *
+	 * Since we conveniently already built an array of all allocations, let's
+	 * pass that on to the target kernel so that reuse it to initialize its
+	 * memory blocks.
+	 */
+	err = kho_alloc_mem_cache(image, kho.dt);
+	if (err)
+		goto out;
+
+	err = kexec_add_buffer(&image->kho.mem_cache);
+	if (err)
+		goto out;
+
+	/*
+	 * Create a kexec copy of the DT here. We need this because lifetime may
+	 * be different between kho.dt and the kimage
+	 */
+	dt = kvmemdup(kho.dt, kho.dt_len, GFP_KERNEL);
+	if (!dt) {
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* Allocate target memory for kho dt */
+	image->kho.dt = (struct kexec_buf) {
+		.image = image,
+		.buffer = dt,
+		.bufsz = kho.dt_len,
+		.mem = KEXEC_BUF_MEM_UNKNOWN,
+		.memsz = kho.dt_len,
+		.buf_align = SZ_64K, /* Makes it easier to map */
+		.buf_max = ULONG_MAX,
+		.top_down = true,
+	};
+	err = kexec_add_buffer(&image->kho.dt);
+
+out:
+	mutex_unlock(&kho.lock);
+	return err;
+}
+
 bool kho_is_active(void)
 {
 	return kho.active;
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:43 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:43 +0000
Subject: [PATCH 06/15] arm64: Add KHO support
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-7-graf@amazon.com>

We now have all bits in place to support KHO kexecs. This patch adds
awareness of KHO in the kexec file as well as boot path for arm64 and
adds the respective kconfig option to the architecture so that it can
use KHO successfully.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 arch/arm64/Kconfig        | 12 ++++++++++++
 arch/arm64/kernel/setup.c |  2 ++
 arch/arm64/mm/init.c      |  8 ++++++++
 drivers/of/fdt.c          | 41 +++++++++++++++++++++++++++++++++++++++
 drivers/of/kexec.c        | 36 ++++++++++++++++++++++++++++++++++
 5 files changed, 99 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..1ba338ce7598 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1501,6 +1501,18 @@ config ARCH_SUPPORTS_CRASH_DUMP
 config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
 	def_bool CRASH_CORE
 
+config KEXEC_KHO
+	bool "kexec handover"
+	depends on KEXEC
+	select MEMBLOCK_SCRATCH
+	select LIBFDT
+	select CMA
+	help
+	  Allow kexec to hand over state across kernels by generating and
+	  passing additional metadata to the target kernel. This is useful
+	  to keep data or state alive across the kexec. For this to work,
+	  both source and target kernels need to have this option enabled.
+
 config TRANS_TABLE
 	def_bool y
 	depends on HIBERNATION || KEXEC_CORE
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 417a8a86b2db..8035b673d96d 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -346,6 +346,8 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
 
 	paging_init();
 
+	kho_reserve_mem();
+
 	acpi_table_upgrade();
 
 	/* Parse the ACPI tables for possible boot-time configuration */
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 74c1db8ce271..254d82f3383a 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -358,6 +358,8 @@ void __init bootmem_init(void)
 	 */
 	arch_reserve_crashkernel();
 
+	kho_reserve();
+
 	memblock_dump_all();
 }
 
@@ -386,6 +388,12 @@ void __init mem_init(void)
 	/* this will put all unused low memory onto the freelists */
 	memblock_free_all();
 
+	/*
+	 * Now that all KHO pages are marked as reserved, let's flip them back
+	 * to normal pages with accurate refcount.
+	 */
+	kho_populate_refcount();
+
 	/*
 	 * Check boundaries twice: Some fundamental inconsistencies can be
 	 * detected at build time already.
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bf502ba8da95..af95139351ed 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1006,6 +1006,44 @@ void __init early_init_dt_check_for_usable_mem_range(void)
 		memblock_add(rgn[i].base, rgn[i].size);
 }
 
+/**
+ * early_init_dt_check_kho - Decode info required for kexec handover from DT
+ */
+void __init early_init_dt_check_kho(void)
+{
+#ifdef CONFIG_KEXEC_KHO
+	unsigned long node = chosen_node_offset;
+	u64 kho_start, scratch_start, scratch_size, mem_start, mem_size;
+	const __be32 *p;
+	int l;
+
+	if ((long)node < 0)
+		return;
+
+	p = of_get_flat_dt_prop(node, "linux,kho-dt", &l);
+	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
+		return;
+
+	kho_start = dt_mem_next_cell(dt_root_addr_cells, &p);
+
+	p = of_get_flat_dt_prop(node, "linux,kho-scratch", &l);
+	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
+		return;
+
+	scratch_start = dt_mem_next_cell(dt_root_addr_cells, &p);
+	scratch_size = dt_mem_next_cell(dt_root_addr_cells, &p);
+
+	p = of_get_flat_dt_prop(node, "linux,kho-mem", &l);
+	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
+		return;
+
+	mem_start = dt_mem_next_cell(dt_root_addr_cells, &p);
+	mem_size = dt_mem_next_cell(dt_root_addr_cells, &p);
+
+	kho_populate(kho_start, scratch_start, scratch_size, mem_start, mem_size);
+#endif
+}
+
 #ifdef CONFIG_SERIAL_EARLYCON
 
 int __init early_init_dt_scan_chosen_stdout(void)
@@ -1304,6 +1342,9 @@ void __init early_init_dt_scan_nodes(void)
 
 	/* Handle linux,usable-memory-range property */
 	early_init_dt_check_for_usable_mem_range();
+
+	/* Handle kexec handover */
+	early_init_dt_check_kho();
 }
 
 bool __init early_init_dt_scan(void *params)
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 68278340cecf..a612e6bb8c75 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -264,6 +264,37 @@ static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
 }
 #endif /* CONFIG_IMA_KEXEC */
 
+static int kho_add_chosen(const struct kimage *image, void *fdt, int chosen_node)
+{
+	int ret = 0;
+
+#ifdef CONFIG_KEXEC_KHO
+	if (!image->kho.dt.buffer || !image->kho.mem_cache.buffer)
+		goto out;
+
+	pr_debug("Adding kho metadata to DT");
+
+	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-dt",
+				       image->kho.dt.mem, image->kho.dt.memsz);
+	if (ret)
+		goto out;
+
+	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-scratch",
+				       kho_scratch_phys, kho_scratch_len);
+	if (ret)
+		goto out;
+
+	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-mem",
+				       image->kho.mem_cache.mem,
+				       image->kho.mem_cache.bufsz);
+	if (ret)
+		goto out;
+
+out:
+#endif
+	return ret;
+}
+
 /*
  * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
  *
@@ -412,6 +443,11 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
 		}
 	}
 
+	/* Add kho metadata if this is a KHO image */
+	ret = kho_add_chosen(image, fdt, chosen_node);
+	if (ret)
+		goto out;
+
 	/* add bootargs */
 	if (cmdline) {
 		ret = fdt_setprop_string(fdt, chosen_node, "bootargs", cmdline);
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:44 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:44 +0000
Subject: [PATCH 07/15] x86: Add KHO support
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-8-graf@amazon.com>

We now have all bits in place to support KHO kexecs. This patch adds
awareness of KHO in the kexec file as well as boot path for x86 and
adds the respective kconfig option to the architecture so that it can
use KHO successfully.

In addition, it enlightens it decompression code with KHO so that its
KASLR location finder only considers memory regions that are not already
occupied by KHO memory.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 arch/x86/Kconfig                      | 12 ++++++
 arch/x86/boot/compressed/kaslr.c      | 55 +++++++++++++++++++++++++++
 arch/x86/include/uapi/asm/bootparam.h | 15 +++++++-
 arch/x86/kernel/e820.c                |  9 +++++
 arch/x86/kernel/kexec-bzimage64.c     | 39 +++++++++++++++++++
 arch/x86/kernel/setup.c               | 46 ++++++++++++++++++++++
 arch/x86/mm/init_32.c                 |  7 ++++
 arch/x86/mm/init_64.c                 |  7 ++++
 8 files changed, 189 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3762f41bb092..849e6ddc5d94 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2103,6 +2103,18 @@ config ARCH_SUPPORTS_CRASH_HOTPLUG
 config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
 	def_bool CRASH_CORE
 
+config KEXEC_KHO
+	bool "kexec handover"
+	depends on KEXEC
+	select MEMBLOCK_SCRATCH
+	select LIBFDT
+	select CMA
+	help
+	  Allow kexec to hand over state across kernels by generating and
+	  passing additional metadata to the target kernel. This is useful
+	  to keep data or state alive across the kexec. For this to work,
+	  both source and target kernels need to have this option enabled.
+
 config PHYSICAL_START
 	hex "Physical address where the kernel is loaded" if (EXPERT || CRASH_DUMP)
 	default "0x1000000"
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index dec961c6d16a..93ea292e4c18 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -29,6 +29,7 @@
 #include <linux/uts.h>
 #include <linux/utsname.h>
 #include <linux/ctype.h>
+#include <uapi/linux/kexec.h>
 #include <generated/utsversion.h>
 #include <generated/utsrelease.h>
 
@@ -472,6 +473,60 @@ static bool mem_avoid_overlap(struct mem_vector *img,
 			}
 		}
 
+#ifdef CONFIG_KEXEC_KHO
+		if (ptr->type == SETUP_KEXEC_KHO) {
+			struct kho_data *kho = (struct kho_data *)ptr->data;
+			struct kho_mem *mems = (void *)kho->mem_cache_addr;
+			int nr_mems = kho->mem_cache_size / sizeof(*mems);
+			int i;
+
+			/* Avoid the mem cache */
+			avoid = (struct mem_vector) {
+				.start = kho->mem_cache_addr,
+				.size = kho->mem_cache_size,
+			};
+
+			if (mem_overlaps(img, &avoid) && (avoid.start < earliest)) {
+				*overlap = avoid;
+				earliest = overlap->start;
+				is_overlapping = true;
+			}
+
+			/* And the KHO DT */
+			avoid = (struct mem_vector) {
+				.start = kho->dt_addr,
+				.size = kho->dt_size,
+			};
+
+			if (mem_overlaps(img, &avoid) && (avoid.start < earliest)) {
+				*overlap = avoid;
+				earliest = overlap->start;
+				is_overlapping = true;
+			}
+
+			/* As well as any other KHO memory reservations */
+			for (i = 0; i < nr_mems; i++) {
+				avoid = (struct mem_vector) {
+					.start = mems[i].addr,
+					.size = mems[i].len,
+				};
+
+				/*
+				 * This mem starts after our current break.
+				 * The array is sorted, so we're done.
+				 */
+				if (avoid.start >= earliest)
+					break;
+
+				if (mem_overlaps(img, &avoid)) {
+					*overlap = avoid;
+					earliest = overlap->start;
+					is_overlapping = true;
+				}
+			}
+		}
+#endif
+
 		ptr = (struct setup_data *)(unsigned long)ptr->next;
 	}
 
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 01d19fc22346..013af38a9673 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -13,7 +13,8 @@
 #define SETUP_CC_BLOB			7
 #define SETUP_IMA			8
 #define SETUP_RNG_SEED			9
-#define SETUP_ENUM_MAX			SETUP_RNG_SEED
+#define SETUP_KEXEC_KHO		10
+#define SETUP_ENUM_MAX			SETUP_KEXEC_KHO
 
 #define SETUP_INDIRECT			(1<<31)
 #define SETUP_TYPE_MAX			(SETUP_ENUM_MAX | SETUP_INDIRECT)
@@ -181,6 +182,18 @@ struct ima_setup_data {
 	__u64 size;
 } __attribute__((packed));
 
+/*
+ * Locations of kexec handover metadata
+ */
+struct kho_data {
+	__u64 dt_addr;
+	__u64 dt_size;
+	__u64 scratch_addr;
+	__u64 scratch_size;
+	__u64 mem_cache_addr;
+	__u64 mem_cache_size;
+} __attribute__((packed));
+
 /* The so-called "zeropage" */
 struct boot_params {
 	struct screen_info screen_info;			/* 0x000 */
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index fb8cf953380d..c891b83f5b1c 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1341,6 +1341,15 @@ void __init e820__memblock_setup(void)
 			continue;
 
 		memblock_add(entry->addr, entry->size);
+
+		/*
+		 * At this point with KHO we only allocate from scratch memory
+		 * and only from memory below ISA_END_ADDRESS. Make sure that
+		 * when we add memory for the eligible range, we add it as
+		 * scratch memory so that we can resize the memblocks array.
+		 */
+		if (is_kho_boot() && (end <= ISA_END_ADDRESS))
+			memblock_mark_scratch(entry->addr, end);
 	}
 
 	/* Throw away partial pages: */
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index a61c12c01270..0cb8d0650a02 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -15,6 +15,7 @@
 #include <linux/slab.h>
 #include <linux/kexec.h>
 #include <linux/kernel.h>
+#include <linux/libfdt.h>
 #include <linux/mm.h>
 #include <linux/efi.h>
 #include <linux/random.h>
@@ -233,6 +234,33 @@ setup_ima_state(const struct kimage *image, struct boot_params *params,
 #endif /* CONFIG_IMA_KEXEC */
 }
 
+static void setup_kho(const struct kimage *image, struct boot_params *params,
+		       unsigned long params_load_addr,
+		       unsigned int setup_data_offset)
+{
+#ifdef CONFIG_KEXEC_KHO
+	struct setup_data *sd = (void *)params + setup_data_offset;
+	struct kho_data *kho = (void *)sd + sizeof(*sd);
+
+	sd->type = SETUP_KEXEC_KHO;
+	sd->len = sizeof(struct kho_data);
+
+	/* Only add if we have all KHO images in place */
+	if (!image->kho.dt.buffer || !image->kho.mem_cache.buffer)
+		return;
+
+	/* Add setup data */
+	kho->dt_addr = image->kho.dt.mem;
+	kho->dt_size = image->kho.dt.bufsz;
+	kho->scratch_addr = kho_scratch_phys;
+	kho->scratch_size = kho_scratch_len;
+	kho->mem_cache_addr = image->kho.mem_cache.mem;
+	kho->mem_cache_size = image->kho.mem_cache.bufsz;
+	sd->next = params->hdr.setup_data;
+	params->hdr.setup_data = params_load_addr + setup_data_offset;
+#endif /* CONFIG_KEXEC_KHO */
+}
+
 static int
 setup_boot_parameters(struct kimage *image, struct boot_params *params,
 		      unsigned long params_load_addr,
@@ -305,6 +333,13 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
 				     sizeof(struct ima_setup_data);
 	}
 
+	if (IS_ENABLED(CONFIG_KEXEC_KHO)) {
+		/* Setup space to store preservation metadata */
+		setup_kho(image, params, params_load_addr, setup_data_offset);
+		setup_data_offset += sizeof(struct setup_data) +
+				     sizeof(struct kho_data);
+	}
+
 	/* Setup RNG seed */
 	setup_rng_seed(params, params_load_addr, setup_data_offset);
 
@@ -470,6 +505,10 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
 		kbuf.bufsz += sizeof(struct setup_data) +
 			      sizeof(struct ima_setup_data);
 
+	if (IS_ENABLED(CONFIG_KEXEC_KHO))
+		kbuf.bufsz += sizeof(struct setup_data) +
+			      sizeof(struct kho_data);
+
 	params = kzalloc(kbuf.bufsz, GFP_KERNEL);
 	if (!params)
 		return ERR_PTR(-ENOMEM);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1526747bedf2..196414c9c9e6 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -382,6 +382,29 @@ int __init ima_get_kexec_buffer(void **addr, size_t *size)
 }
 #endif
 
+static void __init add_kho(u64 phys_addr, u32 data_len)
+{
+#ifdef CONFIG_KEXEC_KHO
+	struct kho_data *kho;
+	u64 addr = phys_addr + sizeof(struct setup_data);
+	u64 size = data_len - sizeof(struct setup_data);
+
+	kho = early_memremap(addr, size);
+	if (!kho) {
+		pr_warn("setup: failed to memremap kho data (0x%llx, 0x%llx)\n",
+			 addr, size);
+		return;
+	}
+
+	kho_populate(kho->dt_addr, kho->scratch_addr, kho->scratch_size,
+		     kho->mem_cache_addr, kho->mem_cache_size);
+
+	early_memunmap(kho, size);
+#else
+	pr_warn("Passed KHO data, but CONFIG_KEXEC_KHO not set. Ignoring.\n");
+#endif
+}
+
 static void __init parse_setup_data(void)
 {
 	struct setup_data *data;
@@ -410,6 +433,9 @@ static void __init parse_setup_data(void)
 		case SETUP_IMA:
 			add_early_ima_buffer(pa_data);
 			break;
+		case SETUP_KEXEC_KHO:
+			add_kho(pa_data, data_len);
+			break;
 		case SETUP_RNG_SEED:
 			data = early_memremap(pa_data, data_len);
 			add_bootloader_randomness(data->data, data->len);
@@ -989,8 +1015,26 @@ void __init setup_arch(char **cmdline_p)
 	cleanup_highmap();
 
 	memblock_set_current_limit(ISA_END_ADDRESS);
+
 	e820__memblock_setup();
 
+	/*
+	 * We can resize memblocks at this point, let's dump all KHO
+	 * reservations in and switch from scratch-only to normal allocations
+	 */
+	kho_reserve_mem();
+
+	/* Allocations now skip scratch mem, return low 1M to the pool */
+	if (is_kho_boot()) {
+		u64 i;
+		phys_addr_t base, end;
+
+		__for_each_mem_range(i, &memblock.memory, NULL, NUMA_NO_NODE,
+				     MEMBLOCK_SCRATCH, &base, &end, NULL)
+			if (end <= ISA_END_ADDRESS)
+				memblock_clear_scratch(base, end - base);
+	}
+
 	/*
 	 * Needs to run after memblock setup because it needs the physical
 	 * memory size.
@@ -1106,6 +1150,8 @@ void __init setup_arch(char **cmdline_p)
 	 */
 	arch_reserve_crashkernel();
 
+	kho_reserve();
+
 	memblock_find_dma_reserve();
 
 	if (!early_xdbc_setup_hardware())
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index b63403d7179d..6c3810afed04 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -20,6 +20,7 @@
 #include <linux/smp.h>
 #include <linux/init.h>
 #include <linux/highmem.h>
+#include <linux/kexec.h>
 #include <linux/pagemap.h>
 #include <linux/pci.h>
 #include <linux/pfn.h>
@@ -738,6 +739,12 @@ void __init mem_init(void)
 	after_bootmem = 1;
 	x86_init.hyper.init_after_bootmem();
 
+	/*
+	 * Now that all KHO pages are marked as reserved, let's flip them back
+	 * to normal pages with accurate refcount.
+	 */
+	kho_populate_refcount();
+
 	/*
 	 * Check boundaries twice: Some fundamental inconsistencies can
 	 * be detected at build time already.
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index a190aae8ceaf..3ce1a4767610 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -20,6 +20,7 @@
 #include <linux/smp.h>
 #include <linux/init.h>
 #include <linux/initrd.h>
+#include <linux/kexec.h>
 #include <linux/pagemap.h>
 #include <linux/memblock.h>
 #include <linux/proc_fs.h>
@@ -1339,6 +1340,12 @@ void __init mem_init(void)
 	after_bootmem = 1;
 	x86_init.hyper.init_after_bootmem();
 
+	/*
+	 * Now that all KHO pages are marked as reserved, let's flip them back
+	 * to normal pages with accurate refcount.
+	 */
+	kho_populate_refcount();
+
 	/*
 	 * Must be done after boot memory is put on freelist, because here we
 	 * might set fields in deferred struct pages that have not yet been
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:45 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:45 +0000
Subject: [PATCH 08/15] tracing: Introduce names for ring buffers
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-9-graf@amazon.com>

With KHO (Kexec HandOver), we want to preserve trace buffers across
kexec. To carry over their state between kernels, the kernel needs a
common handle for them that exists on both sides. As handle we introduce
names for ring buffers. In a follow-up patch, the kernel can then use
these names to recover buffer contents for specific ring buffers.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 include/linux/ring_buffer.h | 7 ++++---
 kernel/trace/ring_buffer.c  | 5 ++++-
 kernel/trace/trace.c        | 7 ++++---
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index 782e14f62201..f34538f97c75 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -85,17 +85,18 @@ void ring_buffer_discard_commit(struct trace_buffer *buffer,
  * size is in bytes for each per CPU buffer.
  */
 struct trace_buffer *
-__ring_buffer_alloc(unsigned long size, unsigned flags, struct lock_class_key *key);
+__ring_buffer_alloc(const char *name, unsigned long size, unsigned flags,
+		    struct lock_class_key *key);
 
 /*
  * Because the ring buffer is generic, if other users of the ring buffer get
  * traced by ftrace, it can produce lockdep warnings. We need to keep each
  * ring buffer's lock class separate.
  */
-#define ring_buffer_alloc(size, flags)			\
+#define ring_buffer_alloc(name, size, flags)			\
 ({							\
 	static struct lock_class_key __key;		\
-	__ring_buffer_alloc((size), (flags), &__key);	\
+	__ring_buffer_alloc((name), (size), (flags), &__key);	\
 })
 
 int ring_buffer_wait(struct trace_buffer *buffer, int cpu, int full);
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 43cc47d7faaf..eaaf823ddedb 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -557,6 +557,7 @@ struct trace_buffer {
 
 	struct rb_irq_work		irq_work;
 	bool				time_stamp_abs;
+	const char			*name;
 };
 
 struct ring_buffer_iter {
@@ -1801,7 +1802,8 @@ static void rb_free_cpu_buffer(struct ring_buffer_per_cpu *cpu_buffer)
  * when the buffer wraps. If this flag is not set, the buffer will
  * drop data when the tail hits the head.
  */
-struct trace_buffer *__ring_buffer_alloc(unsigned long size, unsigned flags,
+struct trace_buffer *__ring_buffer_alloc(const char *name,
+					unsigned long size, unsigned flags,
 					struct lock_class_key *key)
 {
 	struct trace_buffer *buffer;
@@ -1823,6 +1825,7 @@ struct trace_buffer *__ring_buffer_alloc(unsigned long size, unsigned flags,
 	buffer->flags = flags;
 	buffer->clock = trace_clock_local;
 	buffer->reader_lock_key = key;
+	buffer->name = name;
 
 	init_irq_work(&buffer->irq_work.work, rb_wake_up_waiters);
 	init_waitqueue_head(&buffer->irq_work.waiters);
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 9aebf904ff97..7700ca1be2a5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -9384,7 +9384,8 @@ allocate_trace_buffer(struct trace_array *tr, struct array_buffer *buf, int size
 
 	buf->tr = tr;
 
-	buf->buffer = ring_buffer_alloc(size, rb_flags);
+	buf->buffer = ring_buffer_alloc(tr->name ? tr->name : "global_trace",
+					size, rb_flags);
 	if (!buf->buffer)
 		return -ENOMEM;
 
@@ -9421,7 +9422,7 @@ static int allocate_trace_buffers(struct trace_array *tr, int size)
 		return ret;
 
 #ifdef CONFIG_TRACER_MAX_TRACE
-	ret = allocate_trace_buffer(tr, &tr->max_buffer,
+	ret = allocate_trace_buffer(NULL, &tr->max_buffer,
 				    allocate_snapshot ? size : 1);
 	if (MEM_FAIL(ret, "Failed to allocate trace buffer\n")) {
 		free_trace_buffer(&tr->array_buffer);
@@ -10473,7 +10474,7 @@ __init static int tracer_alloc_buffers(void)
 		goto out_free_cpumask;
 	/* Used for event triggers */
 	ret = -ENOMEM;
-	temp_buffer = ring_buffer_alloc(PAGE_SIZE, RB_FL_OVERWRITE);
+	temp_buffer = ring_buffer_alloc("temp_buffer", PAGE_SIZE, RB_FL_OVERWRITE);
 	if (!temp_buffer)
 		goto out_rm_hp_state;
 
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:46 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:46 +0000
Subject: [PATCH 09/15] tracing: Introduce names for events
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-10-graf@amazon.com>

With KHO (Kexec HandOver), we want to preserve trace buffers. To parse
them, we need to ensure that all trace events that exist in the logs are
identical to the ones we parse as. That means we need to match the
events before and after kexec.

As a first step towards that, let's give every event a unique name. That
way we can clearly identify the event before and after kexec and restore
its ID post-kexec.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 include/linux/trace_events.h         |  1 +
 include/trace/trace_events.h         |  2 ++
 kernel/trace/blktrace.c              |  1 +
 kernel/trace/trace_branch.c          |  1 +
 kernel/trace/trace_events.c          |  3 +++
 kernel/trace/trace_functions_graph.c |  4 +++-
 kernel/trace/trace_output.c          | 13 +++++++++++++
 kernel/trace/trace_probe.c           |  3 +++
 kernel/trace/trace_syscalls.c        | 29 ++++++++++++++++++++++++++++
 9 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index d68ff9b1247f..7670224aa92d 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -149,6 +149,7 @@ struct trace_event {
 	struct hlist_node		node;
 	int				type;
 	struct trace_event_functions	*funcs;
+	const char			*name;
 };
 
 extern int register_trace_event(struct trace_event *event);
diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h
index c2f9cabf154d..bb4e6a33eef9 100644
--- a/include/trace/trace_events.h
+++ b/include/trace/trace_events.h
@@ -443,6 +443,7 @@ static struct trace_event_call __used event_##call = {			\
 		.tp			= &__tracepoint_##call,		\
 	},								\
 	.event.funcs		= &trace_event_type_funcs_##template,	\
+	.event.name		= __stringify(call),			\
 	.print_fmt		= print_fmt_##template,			\
 	.flags			= TRACE_EVENT_FL_TRACEPOINT,		\
 };									\
@@ -460,6 +461,7 @@ static struct trace_event_call __used event_##call = {			\
 		.tp			= &__tracepoint_##call,		\
 	},								\
 	.event.funcs		= &trace_event_type_funcs_##call,	\
+	.event.name		= __stringify(template),		\
 	.print_fmt		= print_fmt_##call,			\
 	.flags			= TRACE_EVENT_FL_TRACEPOINT,		\
 };									\
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index d5d94510afd3..7f86fd41b38e 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -1584,6 +1584,7 @@ static struct trace_event_functions trace_blk_event_funcs = {
 static struct trace_event trace_blk_event = {
 	.type		= TRACE_BLK,
 	.funcs		= &trace_blk_event_funcs,
+	.name		= "blk",
 };
 
 static int __init init_blk_tracer(void)
diff --git a/kernel/trace/trace_branch.c b/kernel/trace/trace_branch.c
index e47fdb4c92fb..3372070f2e85 100644
--- a/kernel/trace/trace_branch.c
+++ b/kernel/trace/trace_branch.c
@@ -168,6 +168,7 @@ static struct trace_event_functions trace_branch_funcs = {
 static struct trace_event trace_branch_event = {
 	.type		= TRACE_BRANCH,
 	.funcs		= &trace_branch_funcs,
+	.name		= "branch",
 };
 
 static struct tracer branch_trace __read_mostly =
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index f29e815ca5b2..4f5d37f96a17 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2658,6 +2658,9 @@ static int event_init(struct trace_event_call *call)
 	if (WARN_ON(!name))
 		return -EINVAL;
 
+	if (!call->event.name)
+		call->event.name = name;
+
 	if (call->class->raw_init) {
 		ret = call->class->raw_init(call);
 		if (ret < 0 && ret != -ENOSYS)
diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
index c35fbaab2a47..088dfd4a1a56 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -1342,11 +1342,13 @@ static struct trace_event_functions graph_functions = {
 static struct trace_event graph_trace_entry_event = {
 	.type		= TRACE_GRAPH_ENT,
 	.funcs		= &graph_functions,
+	.name		= "graph_ent",
 };
 
 static struct trace_event graph_trace_ret_event = {
 	.type		= TRACE_GRAPH_RET,
-	.funcs		= &graph_functions
+	.funcs		= &graph_functions,
+	.name		= "graph_ret",
 };
 
 static struct tracer graph_trace __tracer_data = {
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index d8b302d01083..f3677e0da795 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -1067,6 +1067,7 @@ static struct trace_event_functions trace_fn_funcs = {
 static struct trace_event trace_fn_event = {
 	.type		= TRACE_FN,
 	.funcs		= &trace_fn_funcs,
+	.name		= "fn",
 };
 
 /* TRACE_CTX an TRACE_WAKE */
@@ -1207,6 +1208,7 @@ static struct trace_event_functions trace_ctx_funcs = {
 static struct trace_event trace_ctx_event = {
 	.type		= TRACE_CTX,
 	.funcs		= &trace_ctx_funcs,
+	.name		= "ctx",
 };
 
 static struct trace_event_functions trace_wake_funcs = {
@@ -1219,6 +1221,7 @@ static struct trace_event_functions trace_wake_funcs = {
 static struct trace_event trace_wake_event = {
 	.type		= TRACE_WAKE,
 	.funcs		= &trace_wake_funcs,
+	.name		= "wake",
 };
 
 /* TRACE_STACK */
@@ -1256,6 +1259,7 @@ static struct trace_event_functions trace_stack_funcs = {
 static struct trace_event trace_stack_event = {
 	.type		= TRACE_STACK,
 	.funcs		= &trace_stack_funcs,
+	.name		= "stack",
 };
 
 /* TRACE_USER_STACK */
@@ -1309,6 +1313,7 @@ static struct trace_event_functions trace_user_stack_funcs = {
 static struct trace_event trace_user_stack_event = {
 	.type		= TRACE_USER_STACK,
 	.funcs		= &trace_user_stack_funcs,
+	.name		= "user_stack",
 };
 
 /* TRACE_HWLAT */
@@ -1373,6 +1378,7 @@ static struct trace_event_functions trace_hwlat_funcs = {
 static struct trace_event trace_hwlat_event = {
 	.type		= TRACE_HWLAT,
 	.funcs		= &trace_hwlat_funcs,
+	.name		= "hwlat",
 };
 
 /* TRACE_OSNOISE */
@@ -1443,6 +1449,7 @@ static struct trace_event_functions trace_osnoise_funcs = {
 static struct trace_event trace_osnoise_event = {
 	.type		= TRACE_OSNOISE,
 	.funcs		= &trace_osnoise_funcs,
+	.name		= "osnoise",
 };
 
 /* TRACE_TIMERLAT */
@@ -1491,6 +1498,7 @@ static struct trace_event_functions trace_timerlat_funcs = {
 static struct trace_event trace_timerlat_event = {
 	.type		= TRACE_TIMERLAT,
 	.funcs		= &trace_timerlat_funcs,
+	.name		= "timerlat",
 };
 
 /* TRACE_BPUTS */
@@ -1535,6 +1543,7 @@ static struct trace_event_functions trace_bputs_funcs = {
 static struct trace_event trace_bputs_event = {
 	.type		= TRACE_BPUTS,
 	.funcs		= &trace_bputs_funcs,
+	.name		= "bputs",
 };
 
 /* TRACE_BPRINT */
@@ -1579,6 +1588,7 @@ static struct trace_event_functions trace_bprint_funcs = {
 static struct trace_event trace_bprint_event = {
 	.type		= TRACE_BPRINT,
 	.funcs		= &trace_bprint_funcs,
+	.name		= "bprint",
 };
 
 /* TRACE_PRINT */
@@ -1616,6 +1626,7 @@ static struct trace_event_functions trace_print_funcs = {
 static struct trace_event trace_print_event = {
 	.type	 	= TRACE_PRINT,
 	.funcs		= &trace_print_funcs,
+	.name		= "print",
 };
 
 static enum print_line_t trace_raw_data(struct trace_iterator *iter, int flags,
@@ -1645,6 +1656,7 @@ static struct trace_event_functions trace_raw_data_funcs = {
 static struct trace_event trace_raw_data_event = {
 	.type	 	= TRACE_RAW_DATA,
 	.funcs		= &trace_raw_data_funcs,
+	.name		= "raw_data",
 };
 
 static enum print_line_t
@@ -1691,6 +1703,7 @@ static struct trace_event_functions trace_func_repeats_funcs = {
 static struct trace_event trace_func_repeats_event = {
 	.type	 	= TRACE_FUNC_REPEATS,
 	.funcs		= &trace_func_repeats_funcs,
+	.name		= "func_repeats",
 };
 
 static struct trace_event *events[] __initdata = {
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 4dc74d73fc1d..9356f3f2fdc0 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -1835,6 +1835,9 @@ int trace_probe_register_event_call(struct trace_probe *tp)
 				  trace_probe_name(tp)))
 		return -EEXIST;
 
+	if (!call->event.name)
+		call->event.name = call->name;
+
 	ret = register_trace_event(&call->event);
 	if (!ret)
 		return -ENODEV;
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 9c581d6da843..3e7e10b691f5 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -441,8 +441,29 @@ static void unreg_event_syscall_exit(struct trace_event_file *file,
 	mutex_unlock(&syscall_trace_lock);
 }
 
+/**
+ * trace_csum - a simple checksum generator
+ *
+ * This returns a checksum for data that should not generate
+ * a lot of collisions, but is trivial to read.
+ */
+static u32 __init trace_csum(void *data, u32 len)
+{
+	u32 r = 0, i;
+	char *p = data;
+
+	if (!data)
+		return 0;
+
+	for (i = 0; i < len; i++)
+		r = (r >> 31) + (r << 1) + p[i];
+
+	return (r << 4) + len;
+}
+
 static int __init init_syscall_trace(struct trace_event_call *call)
 {
+	u32 csum;
 	int id;
 	int num;
 
@@ -456,9 +477,17 @@ static int __init init_syscall_trace(struct trace_event_call *call)
 	if (set_syscall_print_fmt(call) < 0)
 		return -ENOMEM;
 
+	csum = (trace_csum(call->print_fmt, strlen(call->print_fmt)) << 4) + num;
+	call->event.name = kasprintf(GFP_KERNEL, "sc-%x", csum);
+	if (!call->event.name) {
+		free_syscall_print_fmt(call);
+		return -ENOMEM;
+	}
+
 	id = trace_event_raw_init(call);
 
 	if (id < 0) {
+		kfree(call->event.name);
 		free_syscall_print_fmt(call);
 		return id;
 	}
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:47 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:47 +0000
Subject: [PATCH 10/15] tracing: Introduce kho serialization
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-11-graf@amazon.com>

We want to be able to transfer ftrace state from one kernel to the next.
To start off with, let's establish all the boiler plate to get a write
hook when KHO wants to serialize and fill out basic data.

Follow-up patches will fill in serialization of ring buffers and events.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 kernel/trace/trace.c | 52 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7700ca1be2a5..3e7f61cf773e 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -32,6 +32,7 @@
 #include <linux/percpu.h>
 #include <linux/splice.h>
 #include <linux/kdebug.h>
+#include <linux/kexec.h>
 #include <linux/string.h>
 #include <linux/mount.h>
 #include <linux/rwsem.h>
@@ -866,6 +867,10 @@ static struct tracer		*trace_types __read_mostly;
  */
 DEFINE_MUTEX(trace_types_lock);
 
+#ifdef CONFIG_FTRACE_KHO
+static bool trace_in_kho;
+#endif
+
 /*
  * serialize the access of the ring buffer
  *
@@ -10591,12 +10596,59 @@ void __init early_trace_init(void)
 	init_events();
 }
 
+#ifdef CONFIG_FTRACE_KHO
+static int trace_kho_notifier(struct notifier_block *self,
+			      unsigned long cmd,
+			      void *v)
+{
+	const char compatible[] = "ftrace-v1";
+	void *fdt = v;
+	int err = 0;
+
+	switch (cmd) {
+	case KEXEC_KHO_ABORT:
+		if (trace_in_kho)
+			mutex_unlock(&trace_types_lock);
+		trace_in_kho = false;
+		return NOTIFY_DONE;
+	case KEXEC_KHO_DUMP:
+		/* Handled below */
+		break;
+	default:
+		return NOTIFY_BAD;
+	}
+
+	if (unlikely(tracing_disabled))
+		return NOTIFY_DONE;
+
+	err |= fdt_begin_node(fdt, "ftrace");
+	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= fdt_end_node(fdt);
+
+	if (!err) {
+		/* Hold all future allocations */
+		mutex_lock(&trace_types_lock);
+		trace_in_kho = true;
+	}
+
+	return err ? NOTIFY_BAD : NOTIFY_DONE;
+}
+
+static struct notifier_block trace_kho_nb = {
+	.notifier_call = trace_kho_notifier,
+};
+#endif
+
 void __init trace_init(void)
 {
 	trace_event_init();
 
 	if (boot_instance_index)
 		enable_instances();
+
+#ifdef CONFIG_FTRACE_KHO
+	register_kho_notifier(&trace_kho_nb);
+#endif
 }
 
 __init static void clear_boot_tracer(void)
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:49 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:49 +0000
Subject: [PATCH 12/15] tracing: Recover trace buffers from kexec handover
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-13-graf@amazon.com>

When kexec handover is in place, we now know the location of all
previous buffers for ftrace rings. With this patch applied, ftrace
reassembles any new trace buffer that carries the same name as a
previous one with the same data pages that the previous buffer had.

That way, a buffer that we had in place before kexec becomes readable
after kexec again as soon as it gets initialized with the same name.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 kernel/trace/ring_buffer.c | 173 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 171 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 691d1236eeb1..f3d07cb90762 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -575,6 +575,28 @@ struct ring_buffer_iter {
 	int				missed_events;
 };
 
+struct trace_kho_cpu {
+	const struct kho_mem *mem;
+	uint32_t nr_mems;
+};
+
+#ifdef CONFIG_FTRACE_KHO
+static int trace_kho_replace_buffers(struct ring_buffer_per_cpu *cpu_buffer,
+				     struct trace_kho_cpu *kho);
+static int trace_kho_read_cpu(const char *name, int cpu, struct trace_kho_cpu *kho);
+#else
+static int trace_kho_replace_buffers(struct ring_buffer_per_cpu *cpu_buffer,
+				     struct trace_kho_cpu *kho)
+{
+	return -EINVAL;
+}
+
+static int trace_kho_read_cpu(const char *name, int cpu, struct trace_kho_cpu *kho)
+{
+	return -EINVAL;
+}
+#endif
+
 #ifdef RB_TIME_32
 
 /*
@@ -1807,10 +1829,12 @@ struct trace_buffer *__ring_buffer_alloc(const char *name,
 					unsigned long size, unsigned flags,
 					struct lock_class_key *key)
 {
+	int cpu = raw_smp_processor_id();
+	struct trace_kho_cpu kho = {};
 	struct trace_buffer *buffer;
+	bool use_kho = false;
 	long nr_pages;
 	int bsize;
-	int cpu;
 	int ret;
 
 	/* keep it in its own cache line */
@@ -1823,6 +1847,12 @@ struct trace_buffer *__ring_buffer_alloc(const char *name,
 		goto fail_free_buffer;
 
 	nr_pages = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
+	if (!trace_kho_read_cpu(name, cpu, &kho) && kho.nr_mems > 4) {
+		nr_pages = kho.nr_mems / 2;
+		use_kho = true;
+		pr_debug("Using kho for buffer '%s' on CPU [%03d]", name, cpu);
+	}
+
 	buffer->flags = flags;
 	buffer->clock = trace_clock_local;
 	buffer->reader_lock_key = key;
@@ -1843,12 +1873,14 @@ struct trace_buffer *__ring_buffer_alloc(const char *name,
 	if (!buffer->buffers)
 		goto fail_free_cpumask;
 
-	cpu = raw_smp_processor_id();
 	cpumask_set_cpu(cpu, buffer->cpumask);
 	buffer->buffers[cpu] = rb_allocate_cpu_buffer(buffer, nr_pages, cpu);
 	if (!buffer->buffers[cpu])
 		goto fail_free_buffers;
 
+	if (use_kho && trace_kho_replace_buffers(buffer->buffers[cpu], &kho))
+		pr_warn("Could not revive all previous trace data");
+
 	ret = cpuhp_state_add_instance(CPUHP_TRACE_RB_PREPARE, &buffer->node);
 	if (ret < 0)
 		goto fail_free_buffers;
@@ -5886,7 +5918,9 @@ EXPORT_SYMBOL_GPL(ring_buffer_read_page);
  */
 int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node)
 {
+	struct trace_kho_cpu kho = {};
 	struct trace_buffer *buffer;
+	bool use_kho = false;
 	long nr_pages_same;
 	int cpu_i;
 	unsigned long nr_pages;
@@ -5910,6 +5944,12 @@ int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node)
 	/* allocate minimum pages, user can later expand it */
 	if (!nr_pages_same)
 		nr_pages = 2;
+
+	if (!trace_kho_read_cpu(buffer->name, cpu, &kho) && kho.nr_mems > 4) {
+		nr_pages = kho.nr_mems / 2;
+		use_kho = true;
+	}
+
 	buffer->buffers[cpu] =
 		rb_allocate_cpu_buffer(buffer, nr_pages, cpu);
 	if (!buffer->buffers[cpu]) {
@@ -5917,12 +5957,141 @@ int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node)
 		     cpu);
 		return -ENOMEM;
 	}
+
+	if (use_kho && trace_kho_replace_buffers(buffer->buffers[cpu], &kho))
+		pr_warn("Could not revive all previous trace data");
+
 	smp_wmb();
 	cpumask_set_cpu(cpu, buffer->cpumask);
 	return 0;
 }
 
 #ifdef CONFIG_FTRACE_KHO
+static int trace_kho_replace_buffers(struct ring_buffer_per_cpu *cpu_buffer,
+				     struct trace_kho_cpu *kho)
+{
+	bool first_loop = true;
+	struct list_head *tmp;
+	int err = 0;
+	int i = 0;
+
+	if (kho->nr_mems != cpu_buffer->nr_pages * 2)
+		return -EINVAL;
+
+	for (tmp = rb_list_head(cpu_buffer->pages);
+	     tmp != rb_list_head(cpu_buffer->pages) || first_loop;
+	     tmp = rb_list_head(tmp->next), first_loop = false) {
+		struct buffer_page *bpage = (struct buffer_page *)tmp;
+		const struct kho_mem *mem_bpage = &kho->mem[i++];
+		const struct kho_mem *mem_page = &kho->mem[i++];
+		const uint64_t rb_page_head = 1;
+		struct buffer_page *old_bpage;
+		void *old_page;
+
+		old_bpage = __va(mem_bpage->addr);
+		if (!bpage)
+			goto out;
+
+		if ((ulong)old_bpage->list.next & rb_page_head) {
+			struct list_head *new_lhead;
+			struct buffer_page *new_head;
+
+			new_lhead = rb_list_head(bpage->list.next);
+			new_head = (struct buffer_page *)new_lhead;
+
+			/* Assume the buffer is completely full */
+			cpu_buffer->tail_page = bpage;
+			cpu_buffer->commit_page = bpage;
+			/* Set the head pointers to what they were before */
+			cpu_buffer->head_page->list.prev->next = (struct list_head *)
+				((ulong)cpu_buffer->head_page->list.prev->next & ~rb_page_head);
+			cpu_buffer->head_page = new_head;
+			bpage->list.next = (struct list_head *)((ulong)new_lhead | rb_page_head);
+		}
+
+		if (rb_page_entries(old_bpage) || rb_page_write(old_bpage)) {
+			/*
+			 * We want to recycle the pre-kho page, it contains
+			 * trace data. To do so, we unreserve it and swap the
+			 * current data page with the pre-kho one
+			 */
+			old_page = kho_claim_mem(mem_page);
+
+			/* Recycle the old page, it contains data */
+			free_page((ulong)bpage->page);
+			bpage->page = old_page;
+
+			bpage->write = old_bpage->write;
+			bpage->entries = old_bpage->entries;
+			bpage->real_end = old_bpage->real_end;
+
+			local_inc(&cpu_buffer->pages_touched);
+		} else {
+			kho_return_mem(mem_page);
+		}
+
+		kho_return_mem(mem_bpage);
+	}
+
+out:
+	return err;
+}
+
+static int trace_kho_read_cpu(const char *name, int cpu,
+			      struct trace_kho_cpu *kho)
+{
+	void *fdt = kho_get_fdt();
+	int mem_len;
+	int err = 0;
+	char *path;
+	int off;
+
+	if (!fdt)
+		return -ENOENT;
+
+	if (!kho)
+		return -EINVAL;
+
+	path = kasprintf(GFP_KERNEL, "/ftrace/%s/buffer/cpu%x", name, cpu);
+	if (!path)
+		return -ENOMEM;
+
+	pr_debug("Trying to revive trace buffer '%s'", path);
+
+	off = fdt_path_offset(fdt, path);
+	if (off < 0) {
+		pr_debug("Could not find '%s' in DT", path);
+		err = -ENOENT;
+		goto out;
+	}
+
+	err = fdt_node_check_compatible(fdt, off, "ftrace,cpu-v1");
+	if (err) {
+		pr_warn("Node '%s' has invalid compatible", path);
+		err = -EINVAL;
+		goto out;
+	}
+
+	kho->mem = fdt_getprop(fdt, off, "mem", &mem_len);
+	if (!kho->mem) {
+		pr_warn("Node '%s' has invalid mem property", path);
+		err = -EINVAL;
+		goto out;
+	}
+
+	kho->nr_mems = mem_len / sizeof(*kho->mem);
+
+	/* Should follow "bpage 0, page 0, bpage 1, page 1, ..." pattern */
+	if ((kho->nr_mems & 1)) {
+		err = -EINVAL;
+		goto out;
+	}
+
+out:
+	kfree(path);
+	return err;
+}
+
 static int trace_kho_write_cpu(void *fdt, struct trace_buffer *buffer, int cpu)
 {
 	int i = 0;
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:48 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:48 +0000
Subject: [PATCH 11/15] tracing: Add kho serialization of trace buffers
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-12-graf@amazon.com>

When we do a kexec handover, we want to preserve previous ftrace data
into the new kernel. At the point when we write out the handover data,
ftrace may still be running and recording new events and we want to
capture all of those too.

To allow the new kernel to revive all trace data up to reboot, we store
all locations of trace buffers as well as their linked list metadata. We
can then later reuse the linked list to reconstruct the head pointer.

This patch implements the write-out logic for trace buffers.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 include/linux/ring_buffer.h |  2 +
 kernel/trace/ring_buffer.c  | 89 +++++++++++++++++++++++++++++++++++++
 kernel/trace/trace.c        | 16 +++++++
 3 files changed, 107 insertions(+)

diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index f34538f97c75..049565677ef8 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -212,4 +212,6 @@ int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node);
 #define trace_rb_cpu_prepare	NULL
 #endif
 
+int trace_kho_write_trace_buffer(void *fdt, struct trace_buffer *buffer);
+
 #endif /* _LINUX_RING_BUFFER_H */
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index eaaf823ddedb..691d1236eeb1 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -20,6 +20,7 @@
 #include <linux/percpu.h>
 #include <linux/mutex.h>
 #include <linux/delay.h>
+#include <linux/kexec.h>
 #include <linux/slab.h>
 #include <linux/init.h>
 #include <linux/hash.h>
@@ -5921,6 +5922,94 @@ int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node)
 	return 0;
 }
 
+#ifdef CONFIG_FTRACE_KHO
+static int trace_kho_write_cpu(void *fdt, struct trace_buffer *buffer, int cpu)
+{
+	int i = 0;
+	int err = 0;
+	struct list_head *tmp;
+	const char compatible[] = "ftrace,cpu-v1";
+	char name[] = "cpuffffffff";
+	int nr_pages;
+	struct ring_buffer_per_cpu *cpu_buffer;
+	bool first_loop = true;
+	struct kho_mem *mem;
+	uint64_t mem_len;
+
+	if (!cpumask_test_cpu(cpu, buffer->cpumask))
+		return 0;
+
+	cpu_buffer = buffer->buffers[cpu];
+
+	nr_pages = cpu_buffer->nr_pages;
+	mem_len = sizeof(*mem) * nr_pages * 2;
+	mem = vmalloc(mem_len);
+
+	snprintf(name, sizeof(name), "cpu%x", cpu);
+
+	err |= fdt_begin_node(fdt, name);
+	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= fdt_property(fdt, "cpu", &cpu, sizeof(cpu));
+
+	for (tmp = rb_list_head(cpu_buffer->pages);
+	     tmp != rb_list_head(cpu_buffer->pages) || first_loop;
+	     tmp = rb_list_head(tmp->next), first_loop = false) {
+		struct buffer_page *bpage = (struct buffer_page *)tmp;
+
+		/* Ring is larger than it should be? */
+		if (i >= (nr_pages * 2)) {
+			pr_err("ftrace ring has more pages than nr_pages (%d / %d)", i, nr_pages);
+			err = -EINVAL;
+			break;
+		}
+
+		/* First describe the bpage */
+		mem[i++] = (struct kho_mem) {
+			.addr = __pa(bpage),
+			.len = sizeof(*bpage)
+		};
+
+		/* Then the data page */
+		mem[i++] = (struct kho_mem) {
+			.addr = __pa(bpage->page),
+			.len = PAGE_SIZE
+		};
+	}
+
+	err |= fdt_property(fdt, "mem", mem, mem_len);
+	err |= fdt_end_node(fdt);
+
+	vfree(mem);
+	return err;
+}
+
+int trace_kho_write_trace_buffer(void *fdt, struct trace_buffer *buffer)
+{
+	const char compatible[] = "ftrace,buffer-v1";
+	char name[] = "buffer";
+	int err;
+	int i;
+
+	err = fdt_begin_node(fdt, name);
+	if (err)
+		return err;
+
+	fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+
+	for (i = 0; i < buffer->cpus; i++) {
+		err = trace_kho_write_cpu(fdt, buffer, i);
+		if (err)
+			return err;
+	}
+
+	err =  fdt_end_node(fdt);
+	if (err)
+		return err;
+
+	return 0;
+}
+#endif
+
 #ifdef CONFIG_RING_BUFFER_STARTUP_TEST
 /*
  * This is a basic integrity check of the ring buffer.
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 3e7f61cf773e..71c249cc5b43 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -10597,6 +10597,21 @@ void __init early_trace_init(void)
 }
 
 #ifdef CONFIG_FTRACE_KHO
+static int trace_kho_write_trace_array(void *fdt, struct trace_array *tr)
+{
+	const char *name = tr->name ? tr->name : "global_trace";
+	const char compatible[] = "ftrace,array-v1";
+	int err = 0;
+
+	err |= fdt_begin_node(fdt, name);
+	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= fdt_property(fdt, "trace_flags", &tr->trace_flags, sizeof(tr->trace_flags));
+	err |= trace_kho_write_trace_buffer(fdt, tr->array_buffer.buffer);
+	err |= fdt_end_node(fdt);
+
+	return err;
+}
+
 static int trace_kho_notifier(struct notifier_block *self,
 			      unsigned long cmd,
 			      void *v)
@@ -10623,6 +10638,7 @@ static int trace_kho_notifier(struct notifier_block *self,
 
 	err |= fdt_begin_node(fdt, "ftrace");
 	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= trace_kho_write_trace_array(fdt, &global_trace);
 	err |= fdt_end_node(fdt);
 
 	if (!err) {
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:50 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:50 +0000
Subject: [PATCH 13/15] tracing: Add kho serialization of trace events
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-14-graf@amazon.com>

Events and thus their parsing handle in ftrace have dynamic IDs that get
assigned whenever the event is added to the system. If we want to parse
trace events after kexec, we need to link event IDs back to the original
trace event that existed before we kexec'ed.

There are broadly 2 paths we could take for that:

  1) Save full event description across KHO, restore after kexec,
     merge identical trace events into a single identifier.
  2) Recover the ID of post-kexec added events so they get the same
     ID after kexec that they had before kexec

This patch implements the second option. It's simpler and thus less
intrusive. However, it means we can not fully parse affected events
when the kernel removes or modifies trace events across a kho kexec.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 kernel/trace/trace.c        |  1 +
 kernel/trace/trace_output.c | 28 ++++++++++++++++++++++++++++
 kernel/trace/trace_output.h |  1 +
 3 files changed, 30 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 71c249cc5b43..26edfd2a85fd 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -10639,6 +10639,7 @@ static int trace_kho_notifier(struct notifier_block *self,
 	err |= fdt_begin_node(fdt, "ftrace");
 	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
 	err |= trace_kho_write_trace_array(fdt, &global_trace);
+	err |= trace_kho_write_events(fdt);
 	err |= fdt_end_node(fdt);
 
 	if (!err) {
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index f3677e0da795..113de40c616f 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -12,6 +12,7 @@
 #include <linux/sched/clock.h>
 #include <linux/sched/mm.h>
 #include <linux/idr.h>
+#include <linux/kexec.h>
 
 #include "trace_output.h"
 
@@ -669,6 +670,33 @@ int trace_print_lat_context(struct trace_iterator *iter)
 	return !trace_seq_has_overflowed(s);
 }
 
+int trace_kho_write_events(void *fdt)
+{
+#ifdef CONFIG_FTRACE_KHO
+	const char compatible[] = "ftrace,events-v1";
+	const char *name = "events";
+	struct trace_event *event;
+	unsigned key;
+	int err = 0;
+
+	err |= fdt_begin_node(fdt, name);
+	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+
+	for (key = 0; key < EVENT_HASHSIZE; key++) {
+		hlist_for_each_entry(event, &event_hash[key], node)
+			err |= fdt_property(fdt, event->name, &event->type,
+					    sizeof(event->type));
+	}
+
+	err |= fdt_end_node(fdt);
+
+	return err;
+#else
+	return 0;
+#endif
+}
+
+
 /**
  * ftrace_find_event - find a registered event
  * @type: the type of event to look for
diff --git a/kernel/trace/trace_output.h b/kernel/trace/trace_output.h
index dca40f1f1da4..36dc7963269e 100644
--- a/kernel/trace/trace_output.h
+++ b/kernel/trace/trace_output.h
@@ -25,6 +25,7 @@ extern enum print_line_t print_event_fields(struct trace_iterator *iter,
 extern void trace_event_read_lock(void);
 extern void trace_event_read_unlock(void);
 extern struct trace_event *ftrace_find_event(int type);
+extern int trace_kho_write_events(void *fdt);
 
 extern enum print_line_t trace_nop_print(struct trace_iterator *iter,
 					 int flags, struct trace_event *event);
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:51 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:51 +0000
Subject: [PATCH 14/15] tracing: Recover trace events from kexec handover
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-15-graf@amazon.com>

This patch implements all logic necessary to match a new trace event
that we add against preserved trace events from kho. If we find a match,
we give the new trace event the old event's identifier. That way, trace
read-outs are able to make sense of buffer contents again because the
parsing code for events looks at the same identifiers.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 kernel/trace/trace_output.c | 65 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 113de40c616f..d2e2a6346322 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -749,6 +749,67 @@ void trace_event_read_unlock(void)
 	up_read(&trace_event_sem);
 }
 
+/**
+ * trace_kho_fill_event_type - restore event type info from KHO
+ * @event: the event type to enumerate
+ *
+ * Event types are semi-dynamically generated. To ensure that
+ * their identifiers match before and after kexec with KHO,
+ * let's match up unique name identifiers and fill in the
+ * respective ID information if we booted with KHO.
+ */
+static bool trace_kho_fill_event_type(struct trace_event *event)
+{
+#ifdef CONFIG_FTRACE_KHO
+	const char *path = "/ftrace/events";
+	void *fdt = kho_get_fdt();
+	int err, len, off, id;
+	const void *p;
+
+	if (!fdt)
+		return false;
+
+	if (WARN_ON(!event->name))
+		return false;
+
+	pr_debug("Trying to revive event '%s'", event->name);
+
+	off = fdt_path_offset(fdt, path);
+	if (off < 0) {
+		pr_debug("Could not find '%s' in DT", path);
+		return false;
+	}
+
+	err = fdt_node_check_compatible(fdt, off, "ftrace,events-v1");
+	if (err) {
+		pr_warn("Node '%s' has invalid compatible", path);
+		return false;
+	}
+
+	p = fdt_getprop(fdt, off, event->name, &len);
+	if (!p) {
+		pr_warn("Event '%s' not found", event->name);
+		return false;
+	}
+
+	if (len != sizeof(event->type)) {
+		pr_warn("Event '%s' has invalid length", event->name);
+		return false;
+	}
+
+	id = *(const u32 *)p;
+
+	/* Mark ID as in use */
+	if (ida_alloc_range(&trace_event_ida, id, id, GFP_KERNEL) != id)
+		return false;
+
+	event->type = id;
+	return true;
+#endif
+
+	return false;
+}
+
 /**
  * register_trace_event - register output for an event type
  * @event: the event type to register
@@ -777,7 +838,9 @@ int register_trace_event(struct trace_event *event)
 	if (WARN_ON(!event->funcs))
 		goto out;
 
-	if (!event->type) {
+	if (trace_kho_fill_event_type(event)) {
+		pr_debug("Recovered '%s' as id=%d", event->name, event->type);
+	} else if (!event->type) {
 		event->type = alloc_trace_event_type();
 		if (!event->type)
 			goto out;
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Tue Dec 12 16:04:52 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 00:04:52 +0000
Subject: [PATCH 15/15] tracing: Add config option for kexec handover
In-Reply-To: <20231213000452.88295-1-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <20231213000452.88295-16-graf@amazon.com>

Now that all bits are in place to allow ftrace to pass its trace data
into the next kernel on kexec, let's give users a kconfig option to
enable the functionality.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 kernel/trace/Kconfig | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 61c541c36596..af83ee755b9e 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -1169,6 +1169,19 @@ config HIST_TRIGGERS_DEBUG
 
           If unsure, say N.
 
+config FTRACE_KHO
+	bool "Ftrace Kexec handover support"
+	depends on KEXEC_KHO
+	help
+          Enable support for ftrace to pass metadata across kexec so the new
+	  kernel continues to use the previous kernel's trace buffers.
+
+	  This can be useful when debugging kexec performance or correctness
+	  issues: The new kernel can dump the old kernel's trace buffer which
+	  contains all events until reboot.
+
+	  If unsure, say N.
+
 source "kernel/trace/rv/Kconfig"
 
 endif # FTRACE
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From rostedt at goodmis.org  Tue Dec 12 16:15:46 2023
From: rostedt at goodmis.org (Steven Rostedt)
Date: Tue, 12 Dec 2023 19:15:46 -0500
Subject: [PATCH 08/15] tracing: Introduce names for ring buffers
In-Reply-To: <20231213000452.88295-9-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
	<20231213000452.88295-9-graf@amazon.com>
Message-ID: <20231212191546.603c0703@gandalf.local.home>

On Wed, 13 Dec 2023 00:04:45 +0000
Alexander Graf <graf at amazon.com> wrote:

> With KHO (Kexec HandOver), we want to preserve trace buffers across
> kexec. To carry over their state between kernels, the kernel needs a
> common handle for them that exists on both sides. As handle we introduce
> names for ring buffers. In a follow-up patch, the kernel can then use
> these names to recover buffer contents for specific ring buffers.
> 

Is there a way to use the trace_array name instead?

The trace_array is the structure that represents each tracing instance. And
it already has a name field. And if you can get the associated ring buffer
from that too.

struct trace_array *tr;

	tr->array_buffer.buffer

	tr->name

When you do: mkdir /sys/kernel/tracing/instance/foo

You create a new trace_array instance where tr->name = "foo" and allocates
the buffer for it as well.

-- Steve


From ilkka at os.amperecomputing.com  Tue Dec 12 16:32:56 2023
From: ilkka at os.amperecomputing.com (Ilkka Koskinen)
Date: Tue, 12 Dec 2023 16:32:56 -0800 (PST)
Subject: [PATCH v12 4/5] drivers/perf: add DesignWare PCIe PMU driver
In-Reply-To: <20231208025652.87192-5-xueshuai@linux.alibaba.com>
References: <20231208025652.87192-1-xueshuai@linux.alibaba.com> <20231208025652.87192-5-xueshuai@linux.alibaba.com>
Message-ID: <2bbd5a57-b2ce-6e52-ebf-5935335c148@os.amperecomputing.com>


On Fri, 8 Dec 2023, Shuai Xue wrote:
> This commit adds the PCIe Performance Monitoring Unit (PMU) driver support
> for T-Head Yitian SoC chip. Yitian is based on the Synopsys PCI Express
> Core controller IP which provides statistics feature. The PMU is a PCIe
> configuration space register block provided by each PCIe Root Port in a
> Vendor-Specific Extended Capability named RAS D.E.S (Debug, Error
> injection, and Statistics).
>
> To facilitate collection of statistics the controller provides the
> following two features for each Root Port:
>
> - one 64-bit counter for Time Based Analysis (RX/TX data throughput and
>  time spent in each low-power LTSSM state) and
> - one 32-bit counter for Event Counting (error and non-error events for
>  a specified lane)
>
> Note: There is no interrupt for counter overflow.
>
> This driver adds PMU devices for each PCIe Root Port. And the PMU device is
> named based the BDF of Root Port. For example,
>
>    30:03.0 PCI bridge: Device 1ded:8000 (rev 01)
>
> the PMU device name for this Root Port is dwc_rootport_3018.
>
> Example usage of counting PCIe RX TLP data payload (Units of bytes)::
>
>    $# perf stat -a -e dwc_rootport_3018/Rx_PCIe_TLP_Data_Payload/
>
> average RX bandwidth can be calculated like this:
>
>    PCIe TX Bandwidth = Rx_PCIe_TLP_Data_Payload / Measure_Time_Window
>
> Signed-off-by: Shuai Xue <xueshuai at linux.alibaba.com>
> Reviewed-by: Baolin Wang <baolin.wang at linux.alibaba.com>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> Reviewed-by: Yicong Yang <yangyicong at hisilicon.com>
> Reviewed-and-tested-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
> ---
> drivers/perf/Kconfig        |   7 +
> drivers/perf/Makefile       |   1 +
> drivers/perf/dwc_pcie_pmu.c | 792 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 800 insertions(+)
> create mode 100644 drivers/perf/dwc_pcie_pmu.c
>
> diff --git a/drivers/perf/dwc_pcie_pmu.c b/drivers/perf/dwc_pcie_pmu.c
> new file mode 100644
> index 000000000000..6ee66c4b44bf
> --- /dev/null
> +++ b/drivers/perf/dwc_pcie_pmu.c
> @@ -0,0 +1,792 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Synopsys DesignWare PCIe PMU driver
> + *
> + * Copyright (C) 2021-2023 Alibaba Inc.
> + */
> +

...

> +static int dwc_pcie_pmu_event_init(struct perf_event *event)
> +{
> +	struct dwc_pcie_pmu *pcie_pmu = to_dwc_pcie_pmu(event->pmu);
> +	enum dwc_pcie_event_type type = DWC_PCIE_EVENT_TYPE(event);
> +	struct perf_event *sibling;
> +	u32 lane;
> +
> +	if (event->attr.type != event->pmu->type)
> +		return -ENOENT;
> +
> +	/* We don't support sampling */
> +	if (is_sampling_event(event))
> +		return -EINVAL;
> +
> +	/* We cannot support task bound events */
> +	if (event->cpu < 0 || event->attach_state & PERF_ATTACH_TASK)
> +		return -EINVAL;
> +
> +	if (event->group_leader != event &&
> +	    !is_software_event(event->group_leader))
> +		return -EINVAL;
> +
> +	for_each_sibling_event(sibling, event->group_leader) {
> +		if (sibling->pmu != event->pmu && !is_software_event(sibling))
> +			return -EINVAL;
> +	}
> +
> +	if (type < 0 || type >= DWC_PCIE_EVENT_TYPE_MAX)
> +		return -EINVAL;
> +
> +	if (type == DWC_PCIE_LANE_EVENT) {
> +		lane = DWC_PCIE_EVENT_LANE(event);
> +		if (lane < 0 || lane >= pcie_pmu->nr_lanes)

Just a minor thing that doesn't really matter: 'lane' is unsigned and, 
therefore, cannot be negative.

Otherwise, everything looks good and seems to work fine still.

Cheers, Ilkka


From graf at amazon.com  Tue Dec 12 16:35:16 2023
From: graf at amazon.com (Alexander Graf)
Date: Wed, 13 Dec 2023 01:35:16 +0100
Subject: [PATCH 08/15] tracing: Introduce names for ring buffers
In-Reply-To: <20231212191546.603c0703@gandalf.local.home>
References: <20231213000452.88295-1-graf@amazon.com>
 <20231213000452.88295-9-graf@amazon.com>
 <20231212191546.603c0703@gandalf.local.home>
Message-ID: <eb567d99-e03b-4718-9cc9-e27c5e408ea2@amazon.com>

Hi Steve,

On 13.12.23 01:15, Steven Rostedt wrote:
>
> On Wed, 13 Dec 2023 00:04:45 +0000
> Alexander Graf <graf at amazon.com> wrote:
>
>> With KHO (Kexec HandOver), we want to preserve trace buffers across
>> kexec. To carry over their state between kernels, the kernel needs a
>> common handle for them that exists on both sides. As handle we introduce
>> names for ring buffers. In a follow-up patch, the kernel can then use
>> these names to recover buffer contents for specific ring buffers.
>>
> Is there a way to use the trace_array name instead?
>
> The trace_array is the structure that represents each tracing instance. And
> it already has a name field. And if you can get the associated ring buffer
> from that too.
>
> struct trace_array *tr;
>
>          tr->array_buffer.buffer
>
>          tr->name
>
> When you do: mkdir /sys/kernel/tracing/instance/foo
>
> You create a new trace_array instance where tr->name = "foo" and allocates
> the buffer for it as well.

The name in the ring buffer is pretty much just a copy of the trace 
array name. I use it to reconstruct which buffer we're actually 
referring to inside __ring_buffer_alloc().

I'm all ears for alternative suggestions. I suppose we could pass tr as 
argument to ring_buffer_alloc() instead of the name?


Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From olteanv at gmail.com  Tue Dec 12 16:43:11 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Wed, 13 Dec 2023 02:43:11 +0200
Subject: [PATCH v2 net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <20231212152347.167007f3@kernel.org>
References: <CY5PR12MB63727C24923AE855CFF0D425BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com>
 <20231212152347.167007f3@kernel.org>
Message-ID: <20231213004311.nptkcubaxuiineec@skbuf>

On Tue, Dec 12, 2023 at 03:23:47PM -0800, Jakub Kicinski wrote:
> On Tue, 12 Dec 2023 14:05:02 +0000 Jianheng Zhang wrote:
> > Adds the HW specific support for Frame Preemption handshaking on XGMAC3+
> > cores.
> > 
> > Signed-off-by: Jianheng Zhang <Jianheng.Zhang at synopsys.com>
> 
> I defer to Vladimir on whether to trust that the follow up with
> the ethtool API support will come later (and not require rewrite
> of existing code); or we should request that it's part of the same
> series.
> -- 
> pw-bot: needs-ack
> 

Here's the thing - my understanding of what Synopsys is doing is that
they use TC_TAPRIO_CMD_SET_AND_HOLD and TC_TAPRIO_CMD_SET_AND_RELEASE
as implicit hints to the stmmac driver that FPE should be enabled.

Hold/Release is merely one use case for frame preemption. The "fp"
argument in the tc framework gives you access to the rest: preemption
without scheduling, preemption with scheduling but without hold/release.

And the ethtool-mm framework gives you compatibility with LLDP, so you
can adjust the minimum fragment sizes according to the link partner.
Roger Quadros is adding am65-cpsw support for FPE using the generic
framework, and the TI device has an erratum that the minimum fragment
size that can be received cannot be lower than 124 bytes. LLDP allows
link partners to discover that and still interoperate - which is very
important, because if first-gen TSN hardware, with all its pre-standard
quirks, does not deliver, there may not be a second-gen.

By using LLDP, you can also enable the FPE handshake based on user space
input - when the LLDP daemon gets an LLDPDU with an Additional Ethernet
Capabilities TLV, rather than during each and every stmmac_mac_link_up(),
and hoping for someone to respond. Depending on your hardware design,
this can even lead to power savings, because you can power on your pMAC
only when LLDP says the link partner is also capable, and it will be required.

Ethtool also gives you the ability to report standardized stats per eMAC
and per pMAC, and standardized stats for the MAC Merge layer itself.

Also, the FPE state machine from the stmmac driver is so chatty and
spams the kernel log so bad, because it has nowhere else to report its
current (fragile) state. The ethtool MAC Merge layer gives the driver
a way to report its verification state ("FPE Handshake" as Synopsys
calls it) in a standardized enum.

A small note that the mainline iproute2 does not even expose the
TC_TAPRIO_CMD_SET_AND_HOLD and TC_TAPRIO_CMD_SET_AND_RELEASE netlink
attribute values. To quote from the manpage (which is not out of date
with the code; I checked - again): 'The only supported <command> is "S",
which means "SetGateStates"'.

So I can only guess that Synopsys and anyone else who wants to turn on
FPE on stmmac has to patch their iproute2. A Github code search made me
land here:
https://github.com/altera-opensource/meta-intel-fpga-refdes/blob/7b050ca9968f5ff71598e86bb3a10bb8e011439c/recipes-connectivity/iproute2/iproute2/0003-taprio-Add-support-for-the-SetAndHold-and-SetAndRele.patch

In principle there's nothing wrong with not sharing patches on community
software with the rest of the world. But I cannot help but get the
impression that stmmac support for FPE is abandonware / extremely low
priority / code written to tick the boxes. It's not in the best state
even in the "good" case where the XGMAC3+ support gets accepted.
Jianheng, please contradict me by showing what testing is currently
conducted with this implementation. If none or close to that, let's get
it to a more "observable" state, where at least others' tests could be
reused.

Even this very patch is slightly strange - it is not brand new hardware
support, but it fills in some more FPE ops in dwxlgmac2_ops - when
dwxgmac3_fpe_configure() was already there. So this suggests the
existing support was incomplete. How complete is it now? No way to tell.
There is a selftest to tell, but we can't run it because the driver
doesn't integrate with those kernel APIs.

There are long periods of radio silence from Synopsys engineers in upstream,
and as maintainers we simply don't know what stmmac's FPE implementation
does and what it doesn't do. If a future user gets into trouble, having
a "known good" bisection point, by means of a selftest that passes, is
going to allow even non-expert maintainers like us provide some help,
even if Synopsys engineers go radio silent again.

It may be that Jianheng just needs a little nudge to help the management
prioritize, by getting a NACK. It's a simple "help us help you" situation:
the framework is there and it is a gateway for better Linux user space
support for your platform, you just need to use it. And what better time
to integrate with new API than with new hardware... :) Because it's not
as if FPE on XGMAC3+ ever worked in mainline given my reading of the code.
So why would users not start learning to use it with what is becoming
the common tool set for everybody else.

Allow me to change the "needs-ack" into:

pw-bot: cr


From rostedt at goodmis.org  Tue Dec 12 16:44:41 2023
From: rostedt at goodmis.org (Steven Rostedt)
Date: Tue, 12 Dec 2023 19:44:41 -0500
Subject: [PATCH 08/15] tracing: Introduce names for ring buffers
In-Reply-To: <eb567d99-e03b-4718-9cc9-e27c5e408ea2@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
	<20231213000452.88295-9-graf@amazon.com>
	<20231212191546.603c0703@gandalf.local.home>
	<eb567d99-e03b-4718-9cc9-e27c5e408ea2@amazon.com>
Message-ID: <20231212194441.2701c48b@gandalf.local.home>

On Wed, 13 Dec 2023 01:35:16 +0100
Alexander Graf <graf at amazon.com> wrote:

> > The trace_array is the structure that represents each tracing instance. And
> > it already has a name field. And if you can get the associated ring buffer
> > from that too.
> >
> > struct trace_array *tr;
> >
> >          tr->array_buffer.buffer
> >
> >          tr->name
> >
> > When you do: mkdir /sys/kernel/tracing/instance/foo
> >
> > You create a new trace_array instance where tr->name = "foo" and allocates
> > the buffer for it as well.  
> 
> The name in the ring buffer is pretty much just a copy of the trace 
> array name. I use it to reconstruct which buffer we're actually 
> referring to inside __ring_buffer_alloc().

No, I rather not tie the ring buffer to the trace_array.

> 
> I'm all ears for alternative suggestions. I suppose we could pass tr as 
> argument to ring_buffer_alloc() instead of the name?

I'll have to spend some time (that I don't currently have :-( ) on looking
at this more. I really don't like the copying of the name into the ring
buffer allocation, as it may be an unneeded burden to maintain, not to
mention the duplicate field.

-- Steve


From rostedt at goodmis.org  Tue Dec 12 16:49:52 2023
From: rostedt at goodmis.org (Steven Rostedt)
Date: Tue, 12 Dec 2023 19:49:52 -0500
Subject: [PATCH 09/15] tracing: Introduce names for events
In-Reply-To: <20231213000452.88295-10-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
	<20231213000452.88295-10-graf@amazon.com>
Message-ID: <20231212194952.5f6d599b@gandalf.local.home>

On Wed, 13 Dec 2023 00:04:46 +0000
Alexander Graf <graf at amazon.com> wrote:

> With KHO (Kexec HandOver), we want to preserve trace buffers. To parse
> them, we need to ensure that all trace events that exist in the logs are
> identical to the ones we parse as. That means we need to match the
> events before and after kexec.
> 
> As a first step towards that, let's give every event a unique name. That
> way we can clearly identify the event before and after kexec and restore
> its ID post-kexec.
> 
> Signed-off-by: Alexander Graf <graf at amazon.com>
> ---
>  include/linux/trace_events.h         |  1 +
>  include/trace/trace_events.h         |  2 ++
>  kernel/trace/blktrace.c              |  1 +
>  kernel/trace/trace_branch.c          |  1 +
>  kernel/trace/trace_events.c          |  3 +++
>  kernel/trace/trace_functions_graph.c |  4 +++-
>  kernel/trace/trace_output.c          | 13 +++++++++++++
>  kernel/trace/trace_probe.c           |  3 +++
>  kernel/trace/trace_syscalls.c        | 29 ++++++++++++++++++++++++++++
>  9 files changed, 56 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
> index d68ff9b1247f..7670224aa92d 100644
> --- a/include/linux/trace_events.h
> +++ b/include/linux/trace_events.h
> @@ -149,6 +149,7 @@ struct trace_event {
>  	struct hlist_node		node;
>  	int				type;
>  	struct trace_event_functions	*funcs;
> +	const char			*name;
>  };

OK, this is a hard no. We definitely need to find a different way to do
this. I'm trying hard to lower the footprint of tracing, and this just
added 8 bytes to every event on a 64 bit machine.

On my box I have 1953 events, and they are constantly growing. This just
added 15,624 bytes of tracing overhead to that machine.

That may not sound like much, but as this is only for this feature, it just
added 15K to the overhead for the majority of users.

I'm not sure how easy it is to make this a config option that takes away
that field when not set. But I would need that at a minimum.

-- Steve



From debug at rivosinc.com  Tue Dec 12 16:50:38 2023
From: debug at rivosinc.com (Deepak Gupta)
Date: Tue, 12 Dec 2023 16:50:38 -0800
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <d708b493-267a-4418-be91-9bde6b2cf50c@sirena.org.uk>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org> <CAKC1njSC5cC_fXnyNAPt=WU6cD-OjLKFxo90oVPmsLJbuWf4nw@mail.gmail.com>
 <d708b493-267a-4418-be91-9bde6b2cf50c@sirena.org.uk>
Message-ID: <CAKC1njSQPO8ja7AkTzQ724hhSsGjchH9dLbbH9LXP0ZiKj-zPQ@mail.gmail.com>

On Tue, Dec 12, 2023 at 11:23?AM Mark Brown <broonie at kernel.org> wrote:
>
> On Tue, Dec 12, 2023 at 11:17:11AM -0800, Deepak Gupta wrote:
> > On Wed, Nov 22, 2023 at 1:43?AM Mark Brown <broonie at kernel.org> wrote:
>
> > > +/*
> > > + * Set the current shadow stack configuration.  Enabling the shadow
> > > + * stack will cause a shadow stack to be allocated for the thread.
> > > + */
> > > +#define PR_SET_SHADOW_STACK_STATUS      72
> > > +# define PR_SHADOW_STACK_ENABLE         (1UL << 0)
>
> > Other architecture may require disabling shadow stack if glibc
> > tunables is set to permissive mode.
> > In permissive mode, if glibc encounters `dlopen` on an object which
> > doesn't support shadow stack,
> > glibc should be able to issue PR_SHADOW_STACK_DISABLE.
>
> > Architectures can choose to implement or not but I think arch agnostic
> > code should enumerate this.
>
> The current implementation for arm64 and therefore API for the prctl()
> is that whatever combination of flags is specified will be set, this
> means that setting the status to something that does not include _ENABLE
> will result in disabling and we don't need a separate flag for disable.
> We have use cases that make active use of disabling at runtime.

A theoretical scenario (no current workloads should've this case
because no shadow stack)

- User mode did _ENABLE on the main thread. Shadow stack was allocated
for the current
  thread.
- User mode created a bunch worker threads to run untrusted contained
code. They shadow
  stack too.
- main thread had to do dlopen and now need to disable shadow stack on
itself due to
  incompatibility of incoming object in address space.
- main thread controls worker threads and knows they're contained and
should still be running
  with a shadow stack. Although once in a while the main thread needs
to perform writes to a shadow
  stack of worker threads for some fixup (in the same addr space).
main thread doesn't want to delegate
  this responsibility of ss writes to worker threads because they're untrusted.

How will it do that (currently _ENABLE is married to _WRITE and _PUSH) ?

Please note that I am making up this scenario just for sake of discussion
And don't know if software would be using it in this manner.

>
> Please delete unneeded context from replies, it makes it much easier to
> find new content.

Sorry about that.
Noted.


From shijie at os.amperecomputing.com  Tue Dec 12 17:20:46 2023
From: shijie at os.amperecomputing.com (Huang Shijie)
Date: Wed, 13 Dec 2023 09:20:46 +0800
Subject: [PATCH] arm64: irq: set the correct node for shadow call stack
Message-ID: <20231213012046.12014-1-shijie@os.amperecomputing.com>

The init_irq_stacks() has been changed to use the correct node:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf

The init_irq_scs() has the same issue with init_irq_stacks():
	cpu_to_node() is not initialized yet, it does not work.

This patch uses early_cpu_to_node() to set the init_irq_scs()
with the correct node.

Signed-off-by: Huang Shijie <shijie at os.amperecomputing.com>
---
 arch/arm64/kernel/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 9f253d8efe90..85087e2df564 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -48,7 +48,7 @@ static void init_irq_scs(void)
 
 	for_each_possible_cpu(cpu)
 		per_cpu(irq_shadow_call_stack_ptr, cpu) =
-			scs_alloc(cpu_to_node(cpu));
+			scs_alloc(early_cpu_to_node(cpu));
 }
 
 #ifdef CONFIG_VMAP_STACK
-- 
2.40.1



From guoren at kernel.org  Tue Dec 12 17:26:01 2023
From: guoren at kernel.org (Guo Ren)
Date: Wed, 13 Dec 2023 09:26:01 +0800
Subject: [PATCH] leds: sun50i-a100: avoid division-by-zero warning
In-Reply-To: <20231212214536.175327-1-arnd@kernel.org>
References: <20231212214536.175327-1-arnd@kernel.org>
Message-ID: <CAJF2gTQckdn=uDfeLKu7wceOq7LT1KGJUT0vARMr9zUy3xc4xw@mail.gmail.com>

On Wed, Dec 13, 2023 at 5:45?AM Arnd Bergmann <arnd at kernel.org> wrote:
>
> From: Arnd Bergmann <arnd at arndb.de>
>
> When CONFIG_COMMON_CLK is disabled, e.g. on an x86 randconfig compile test,
> clang reports a field overflow from propagating the result of a division by
> zero:
>
> drivers/leds/leds-sun50i-a100.c:309:12: error: call to '__compiletime_assert_265' declared with 'error' attribute: FIELD_PREP: value too large for the field
>         control = FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T1H, timing->t1h_ns / cycle_ns) |
>
> Avoid the problem by adding an explicit check for the zero value here. Alternatively
> the assertion could be avoided with a Kconfig dependency on COMMON_CLK.
>
> Fixes: 090a25ad9798 ("leds: sun50i-a100: New driver for the A100 LED controller")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/leds/leds-sun50i-a100.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/leds/leds-sun50i-a100.c b/drivers/leds/leds-sun50i-a100.c
> index e4a7e692a908..171cefd1ea0d 100644
> --- a/drivers/leds/leds-sun50i-a100.c
> +++ b/drivers/leds/leds-sun50i-a100.c
> @@ -303,9 +303,13 @@ static void sun50i_a100_ledc_set_timing(struct sun50i_a100_ledc *priv)
>  {
>         const struct sun50i_a100_ledc_timing *timing = &priv->timing;
>         unsigned long mod_freq = clk_get_rate(priv->mod_clk);
> -       u32 cycle_ns = NSEC_PER_SEC / mod_freq;
> +       u32 cycle_ns;
>         u32 control;
>
> +       if (!mod_freq)
> +               return;
> +
Shall we need err_disable_bus_clk?

+ static int sun50i_a100_ledc_set_timing(struct sun50i_a100_ledc *priv)
- static void sun50i_a100_ledc_set_timing(struct sun50i_a100_ledc *priv)
 {
         const struct sun50i_a100_ledc_timing *timing = &priv->timing;
         unsigned long mod_freq = clk_get_rate(priv->mod_clk);
 -       u32 cycle_ns = NSEC_PER_SEC / mod_freq;
 +       u32 cycle_ns;
         u32 control;

+       if (!mod_freq)
+               return -EINVAL;

 +       cycle_ns = NSEC_PER_SEC / mod_freq;
         control = FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T1H,
timing->t1h_ns / cycle_ns) |
                   FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T1L,
timing->t1l_ns / cycle_ns) |
                   FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T0H,
timing->t0h_ns / cycle_ns) |
...
       return 0;

----------

+ ret = sun50i_a100_ledc_set_timing(priv);
+ if (ret)
+         goto err_disable_bus_clk;



> --
> 2.39.2
>


-- 
Best Regards
 Guo Ren


From andre.przywara at arm.com  Tue Dec 12 17:35:44 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 13 Dec 2023 01:35:44 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <axsvii25yrknfae6gdreti7lcskoscsdbsujwuispiieimsbdy@gwzm4l7mwlew>
References: <20231212122835.10850-2-retpolanne@posteo.net>
	<20231212162200.10b3868b@donnerap.manchester.arm.com>
	<axsvii25yrknfae6gdreti7lcskoscsdbsujwuispiieimsbdy@gwzm4l7mwlew>
Message-ID: <20231213013544.2fc7e0d1@minigeek.lan>

On Tue, 12 Dec 2023 19:27:14 +0000
Anne Macedo <retpolanne at posteo.net> wrote:

Hi Anne,

> On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:
> > On Tue, 12 Dec 2023 12:28:30 +0000
> > Anne Macedo <retpolanne at posteo.net> wrote:
> > 
> > Hi Anne,
> >   
> > > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > > Realtek 8211 PHY to Orange Pi One Plus.  
> > 
> > So can you state why this would be needed? This is the RTL8211 ID,  
> 
> Apologies, I completely forgot to include some context. 
> 
> > right? Which should be autodetected via MDIO. Looking back in my inbox
> > you proposed this change before, for U-Boot, specifically, but I fail to
> > find a solution or explanation what really happens here. Two Renesas .dts
> > files have the same compatible, and the commit message talks about the
> > reset line there, is this related?
> > 
> > So can you please give some more background and explanation? That would be
> > part of a good commit message anyway ("why", not "what").  
> 
> Should I resend the commit with a more meaningful explanation? The
> context is the following:
> 
> currently, ethernet doesn't seem to work on both u-boot and Linux on the
> Orange Pi One Plus board. 
> 
> On the kernel, this error shows up:
> 
> Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> [    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> 
> After applying this fix, the PHY gets attached: 
> 
> Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> [    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
> 
> The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
> to find a PHY, so this patch includes the correct PHY ID with the
> RTL8211 ID. 
> 
> The behaviour is described on [1].

So this is all an observation, but no real explanation, isn't it?
To cite [1]: "If the PHY reports an incorrect ID (or none at all) ...".
I am pretty sure this is not the case here, instead we are looking at
some missing platform bits, like a missing clock, reset, or most likely
regulator. Or one of the existing resources is wrongly assigned or
configured? If the PHY is not (yet?) powered correctly when the code
does the auto-detection via the MDIO bus, then the initialisation would
fail. But since it works when overriding the auto-detection, I feel
like we are papering over something here.
Do you have the schematics for this board? I can only find the one for
the Orange Pi Plus 2E, and I don't know how similar those two are. This
shows *two* regulators, but both are activated by the same GPIO.
It would also be interesting to see if any of Corentin's work for the
Orange Pi 3 helps here?

Cheers,
Andre


> U-boot fails completely if the
> correct PHY ID is not correct, and in order to fix U-boot we need to fix
> the upstream dts [2].
> 
> [1] https://elixir.bootlin.com/linux/v4.14/source/Documentation/devicetree/bindings/net/phy.txt#L20
> [2] https://elixir.bootlin.com/u-boot/latest/source/drivers/core/ofnode.c#L1258
> 
> > 
> > Cheers,
> > Andre
> >   
> > > Signed-off-by: Anne Macedo <retpolanne at posteo.net>
> > > ---
> > >  arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
> > > index 29a081e72..7248ab72f 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
> > > @@ -37,7 +37,8 @@ &emac {
> > >  
> > >  &mdio {
> > >  	ext_rgmii_phy: ethernet-phy at 1 {
> > > -		compatible = "ethernet-phy-ieee802.3-c22";
> > > +		compatible = "ethernet-phy-id001c.c915",
> > > +			     "ethernet-phy-ieee802.3-c22";
> > >  		reg = <1>;
> > >  	};
> > >  };  
> >   
> 
> Regards, Anne
> 



From Chunfeng.Yun at mediatek.com  Tue Dec 12 18:13:10 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Wed, 13 Dec 2023 02:13:10 +0000
Subject: [RFC PATCH net-next v3 2/8] phy: add driver for MediaTek pextp
 10GE SerDes PHY
In-Reply-To: <d5d0d01f-7df1-451a-a4bc-4c85f31b03db@collabora.com>
References: <cover.1702352117.git.daniel@makrotopia.org>
	 <a58dae1cce1b49093b0ae05159c784a9ec02f058.1702352117.git.daniel@makrotopia.org>
	 <d5d0d01f-7df1-451a-a4bc-4c85f31b03db@collabora.com>
Message-ID: <d54e1438f6d18d0c3e9ad6493903a3434c7fcd3c.camel@mediatek.com>

On Tue, 2023-12-12 at 11:41 +0100, AngeloGioacchino Del Regno wrote:
> Il 12/12/23 04:46, Daniel Golle ha scritto:
> > Add driver for MediaTek's pextp 10 Gigabit/s Ethernet SerDes PHY
> > which
> > can be found in the MT7988 SoC.
> > 
> > The PHY can operates only in PHY_MODE_ETHERNET, the submode is one
> > of
> > PHY_INTERFACE_MODE_* corresponding to the supported modes:
> > 
> >   * USXGMII
> >   * 10GBase-R
> >   * 5GBase-R
> >   * 2500Base-X
> >   * 1000Base-X
> >   * Cisco SGMII (MAC side)
> > 
> > In order to work-around a performance issue present on the first of
> > two PEXTP present in MT7988 special tuning is applied which can be
> > selected by adding the mediatek,usxgmii-performance-errata property
> > to
> > the device tree node.
> > 
> > There is no documentation what-so-ever for the pextp registers and
> > this driver is based on a GPL licensed implementation found in
> > MediaTek's SDK.
> > 
> > Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> > ---
> 
> ..snip..
> 
> Can anyone from MediaTek **please** define those registers and
> fields?
I discussed with my software coworker who also don't have register map
doc, need our hardware designer help to provide the names of these
register and fields.

Thanks
> 
> In this form, this driver is pretty obscure and nobody knows what
> it's doing;
> please remember that, by actually providing a definition for those
> registers and
> fields, the operation (reliability) of this PHY may be improved and
> this driver
> will be actually maintainable (and possibly support more than one
> variation of
> this PHY in the future with less efforts).
> 
> MediaTek?
> 
> Regards,
> Angelo
> 
> > +
> > +	/* Setup operation mode */
> > +	if (is_10g)
> > +		iowrite32(0x00c9071c, pextp->base + 0x9024);
> > +	else
> > +		iowrite32(0x00d9071c, pextp->base + 0x9024);
> > +
> > +	if (is_5g)
> > +		iowrite32(0xaaa5a5aa, pextp->base + 0x2020);
> > +	else
> > +		iowrite32(0xaa8585aa, pextp->base + 0x2020);
> > +
> > +	if (is_2p5g || is_5g || is_10g) {
> > +		iowrite32(0x0c020707, pextp->base + 0x2030);
> > +		iowrite32(0x0e050f0f, pextp->base + 0x2034);
> > +		iowrite32(0x00140032, pextp->base + 0x2040);
> > +	} else {
> > +		iowrite32(0x0c020207, pextp->base + 0x2030);
> > +		iowrite32(0x0e05050f, pextp->base + 0x2034);
> > +		iowrite32(0x00200032, pextp->base + 0x2040);
> > +	}
> > +
> > +	if (is_2p5g || is_10g)
> > +		iowrite32(0x00c014aa, pextp->base + 0x50f0);
> > +	else if (is_5g)
> > +		iowrite32(0x00c018aa, pextp->base + 0x50f0);
> > +	else
> > +		iowrite32(0x00c014ba, pextp->base + 0x50f0);
> > +
> > +	if (is_5g) {
> > +		iowrite32(0x3777812b, pextp->base + 0x50e0);
> > +		iowrite32(0x005c9cff, pextp->base + 0x506c);
> > +		iowrite32(0x9dfafafa, pextp->base + 0x5070);
> > +		iowrite32(0x273f3f3f, pextp->base + 0x5074);
> > +		iowrite32(0xa8883868, pextp->base + 0x5078);
> > +		iowrite32(0x14661466, pextp->base + 0x507c);
> > +	} else {
> > +		iowrite32(0x3777c12b, pextp->base + 0x50e0);
> > +		iowrite32(0x005f9cff, pextp->base + 0x506c);
> > +		iowrite32(0x9d9dfafa, pextp->base + 0x5070);
> > +		iowrite32(0x27273f3f, pextp->base + 0x5074);
> > +		iowrite32(0xa7883c68, pextp->base + 0x5078);
> > +		iowrite32(0x11661166, pextp->base + 0x507c);
> > +	}
> > +
> > +	if (is_2p5g || is_10g) {
> > +		iowrite32(0x0e000aaf, pextp->base + 0x5080);
> > +		iowrite32(0x08080d0d, pextp->base + 0x5084);
> > +		iowrite32(0x02030909, pextp->base + 0x5088);
> > +	} else if (is_5g) {
> > +		iowrite32(0x0e001abf, pextp->base + 0x5080);
> > +		iowrite32(0x080b0d0d, pextp->base + 0x5084);
> > +		iowrite32(0x02050909, pextp->base + 0x5088);
> > +	} else {
> > +		iowrite32(0x0e000eaf, pextp->base + 0x5080);
> > +		iowrite32(0x08080e0d, pextp->base + 0x5084);
> > +		iowrite32(0x02030b09, pextp->base + 0x5088);
> > +	}
> > +
> > +	if (is_5g) {
> > +		iowrite32(0x0c000000, pextp->base + 0x50e4);
> > +		iowrite32(0x04000000, pextp->base + 0x50e8);
> > +	} else {
> > +		iowrite32(0x0c0c0000, pextp->base + 0x50e4);
> > +		iowrite32(0x04040000, pextp->base + 0x50e8);
> > +	}
> > +
> > +	if (is_2p5g || mtk_interface_mode_is_xgmii(interface))
> > +		iowrite32(0x0f0f0c06, pextp->base + 0x50eC);
> > +	else
> > +		iowrite32(0x0f0f0606, pextp->base + 0x50eC);
> > +
> > +	if (is_5g) {
> > +		iowrite32(0x50808c8c, pextp->base + 0x50a8);
> > +		iowrite32(0x18000000, pextp->base + 0x6004);
> > +	} else {
> > +		iowrite32(0x506e8c8c, pextp->base + 0x50a8);
> > +		iowrite32(0x18190000, pextp->base + 0x6004);
> > +	}
> > +
> > +	if (is_10g)
> > +		iowrite32(0x01423342, pextp->base + 0x00f8);
> > +	else if (is_5g)
> > +		iowrite32(0x00a132a1, pextp->base + 0x00f8);
> > +	else if (is_2p5g)
> > +		iowrite32(0x009c329c, pextp->base + 0x00f8);
> > +	else
> > +		iowrite32(0x00fa32fa, pextp->base + 0x00f8);
> > +
> > +	/* Force SGDT_OUT off and select PCS */
> > +	if (mtk_interface_mode_is_xgmii(interface))
> > +		iowrite32(0x80201f20, pextp->base + 0x00f4);
> > +	else
> > +		iowrite32(0x80201f21, pextp->base + 0x00f4);
> > +
> > +	/* Force GLB_CKDET_OUT */
> > +	iowrite32(0x00050c00, pextp->base + 0x0030);
> > +
> > +	/* Force AEQ on */
> > +	iowrite32(0x02002800, pextp->base + 0x0070);
> > +	ndelay(1020);
> > +
> > +	/* Setup DA default value */
> > +	iowrite32(0x00000020, pextp->base + 0x30b0);
> > +	iowrite32(0x00008a01, pextp->base + 0x3028);
> > +	iowrite32(0x0000a884, pextp->base + 0x302c);
> > +	iowrite32(0x00083002, pextp->base + 0x3024);
> > +	if (mtk_interface_mode_is_xgmii(interface)) {
> > +		iowrite32(0x00022220, pextp->base + 0x3010);
> > +		iowrite32(0x0f020a01, pextp->base + 0x5064);
> > +		iowrite32(0x06100600, pextp->base + 0x50b4);
> > +		if (interface == PHY_INTERFACE_MODE_USXGMII)
> > +			iowrite32(0x40704000, pextp->base + 0x3048);
> > +		else
> > +			iowrite32(0x47684100, pextp->base + 0x3048);
> > +	} else {
> > +		iowrite32(0x00011110, pextp->base + 0x3010);
> > +		iowrite32(0x40704000, pextp->base + 0x3048);
> > +	}
> > +
> > +	if (!mtk_interface_mode_is_xgmii(interface) && !is_2p5g)
> > +		iowrite32(0x0000c000, pextp->base + 0x3064);
> > +
> > +	if (interface != PHY_INTERFACE_MODE_10GBASER) {
> > +		iowrite32(0xa8000000, pextp->base + 0x3050);
> > +		iowrite32(0x000000aa, pextp->base + 0x3054);
> > +	} else {
> > +		iowrite32(0x00000000, pextp->base + 0x3050);
> > +		iowrite32(0x00000000, pextp->base + 0x3054);
> > +	}
> > +
> > +	if (mtk_interface_mode_is_xgmii(interface))
> > +		iowrite32(0x00000f00, pextp->base + 0x306c);
> > +	else if (is_2p5g)
> > +		iowrite32(0x22000f00, pextp->base + 0x306c);
> > +	else
> > +		iowrite32(0x20200f00, pextp->base + 0x306c);
> > +
> > +	if (interface == PHY_INTERFACE_MODE_10GBASER && pextp->da_war)
> > +		iowrite32(0x0007b400, pextp->base + 0xa008);
> > +
> > +	if (mtk_interface_mode_is_xgmii(interface))
> > +		iowrite32(0x00040000, pextp->base + 0xa060);
> > +	else
> > +		iowrite32(0x00050000, pextp->base + 0xa060);
> > +
> > +	if (is_10g)
> > +		iowrite32(0x00000001, pextp->base + 0x90d0);
> > +	else if (is_5g)
> > +		iowrite32(0x00000003, pextp->base + 0x90d0);
> > +	else if (is_2p5g)
> > +		iowrite32(0x00000005, pextp->base + 0x90d0);
> > +	else
> > +		iowrite32(0x00000007, pextp->base + 0x90d0);
> > +
> > +	/* Release reset */
> > +	iowrite32(0x0200e800, pextp->base + 0x0070);
> > +	usleep_range(150, 500);
> > +
> > +	/* Switch to P0 */
> > +	iowrite32(0x0200c111, pextp->base + 0x0070);
> > +	ndelay(1020);
> > +	iowrite32(0x0200c101, pextp->base + 0x0070);
> > +	usleep_range(15, 50);
> > +
> > +	if (mtk_interface_mode_is_xgmii(interface)) {
> > +		/* Switch to Gen3 */
> > +		iowrite32(0x0202c111, pextp->base + 0x0070);
> > +	} else {
> > +		/* Switch to Gen2 */
> > +		iowrite32(0x0201c111, pextp->base + 0x0070);
> > +	}
> > +	ndelay(1020);
> > +	if (mtk_interface_mode_is_xgmii(interface))
> > +		iowrite32(0x0202c101, pextp->base + 0x0070);
> > +	else
> > +		iowrite32(0x0201c101, pextp->base + 0x0070);
> > +	usleep_range(100, 500);
> > +	iowrite32(0x00000030, pextp->base + 0x30b0);
> > +	if (mtk_interface_mode_is_xgmii(interface))
> > +		iowrite32(0x80201f00, pextp->base + 0x00f4);
> > +	else
> > +		iowrite32(0x80201f01, pextp->base + 0x00f4);
> > +
> > +	iowrite32(0x30000000, pextp->base + 0x3040);
> > +	usleep_range(400, 1000);
> > +}
> > +
> > +static int mtk_pextp_set_mode(struct phy *phy, enum phy_mode mode,
> > int submode)
> > +{
> > +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> > +
> > +	if (mode != PHY_MODE_ETHERNET)
> > +		return -EINVAL;
> > +
> > +	switch (submode) {
> > +	case PHY_INTERFACE_MODE_1000BASEX:
> > +	case PHY_INTERFACE_MODE_2500BASEX:
> > +	case PHY_INTERFACE_MODE_SGMII:
> > +	case PHY_INTERFACE_MODE_5GBASER:
> > +	case PHY_INTERFACE_MODE_10GBASER:
> > +	case PHY_INTERFACE_MODE_USXGMII:
> > +		mtk_pextp_setup(pextp, submode);
> > +		return 0;
> > +	default:
> > +		return -EINVAL;
> > +	}
> > +}
> > +
> > +static int mtk_pextp_reset(struct phy *phy)
> > +{
> > +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> > +
> > +	reset_control_assert(pextp->reset);
> > +	usleep_range(100, 500);
> > +	reset_control_deassert(pextp->reset);
> > +	usleep_range(1, 10);
> > +
> > +	return 0;
> > +}
> > +
> > +static int mtk_pextp_power_on(struct phy *phy)
> > +{
> > +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> > +
> > +	return clk_bulk_prepare_enable(MTK_PEXTP_NUM_CLOCKS, pextp-
> > >clocks);
> > +}
> > +
> > +static int mtk_pextp_power_off(struct phy *phy)
> > +{
> > +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> > +
> > +	clk_bulk_disable_unprepare(MTK_PEXTP_NUM_CLOCKS, pextp-
> > >clocks);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct phy_ops mtk_pextp_ops = {
> > +	.power_on	= mtk_pextp_power_on,
> > +	.power_off	= mtk_pextp_power_off,
> > +	.set_mode	= mtk_pextp_set_mode,
> > +	.reset		= mtk_pextp_reset,
> > +	.owner		= THIS_MODULE,
> > +};
> > +
> > +static int mtk_pextp_probe(struct platform_device *pdev)
> > +{
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct phy_provider *phy_provider;
> > +	struct mtk_pextp_phy *pextp;
> > +	struct phy *phy;
> > +
> > +	if (!np)
> > +		return -ENODEV;
> > +
> > +	pextp = devm_kzalloc(&pdev->dev, sizeof(*pextp), GFP_KERNEL);
> > +	if (!pextp)
> > +		return -ENOMEM;
> > +
> > +	pextp->base = devm_of_iomap(&pdev->dev, np, 0, NULL);
> > +	if (!pextp->base)
> > +		return -EIO;
> > +
> > +	pextp->dev = &pdev->dev;
> > +
> > +	pextp->clocks[0].id = "topxtal";
> > +	pextp->clocks[0].clk = devm_clk_get(&pdev->dev, pextp-
> > >clocks[0].id);
> > +	if (IS_ERR(pextp->clocks[0].clk))
> > +		return PTR_ERR(pextp->clocks[0].clk);
> > +
> > +	pextp->clocks[1].id = "xfipll";
> > +	pextp->clocks[1].clk = devm_clk_get(&pdev->dev, pextp-
> > >clocks[1].id);
> > +	if (IS_ERR(pextp->clocks[1].clk))
> > +		return PTR_ERR(pextp->clocks[1].clk);
> > +
> > +	pextp->reset = devm_reset_control_get_exclusive(&pdev->dev,
> > NULL);
> > +	if (IS_ERR(pextp->reset))
> > +		return PTR_ERR(pextp->reset);
> > +
> > +	pextp->da_war = of_property_read_bool(np, "mediatek,usxgmii-
> > performance-errata");
> > +
> > +	phy = devm_phy_create(&pdev->dev, NULL, &mtk_pextp_ops);
> > +	if (IS_ERR(phy))
> > +		return PTR_ERR(phy);
> > +
> > +	phy_set_drvdata(phy, pextp);
> > +
> > +	phy_provider = devm_of_phy_provider_register(&pdev->dev,
> > of_phy_simple_xlate);
> > +
> > +	return PTR_ERR_OR_ZERO(phy_provider);
> > +}
> > +
> > +static const struct of_device_id mtk_pextp_match[] = {
> > +	{ .compatible = "mediatek,mt7988-xfi-pextp", },
> > +	{ }
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_pextp_match);
> > +
> > +static struct platform_driver mtk_pextp_driver = {
> > +	.probe = mtk_pextp_probe,
> > +	.driver = {
> > +		.name = "mtk-pextp",
> > +		.of_match_table = mtk_pextp_match,
> > +	},
> > +};
> > +module_platform_driver(mtk_pextp_driver);
> > +
> > +MODULE_DESCRIPTION("MediaTek pextp SerDes PHY driver");
> > +MODULE_AUTHOR("Daniel Golle <daniel at makrotopia.org>");
> > +MODULE_LICENSE("GPL");
> 
> 

From seanjc at google.com  Tue Dec 12 18:22:00 2023
From: seanjc at google.com (Sean Christopherson)
Date: Tue, 12 Dec 2023 18:22:00 -0800
Subject: [PATCH 05/26] vfio: KVM: Pass get/put helpers from KVM to VFIO,
 don't do circular lookup
In-Reply-To: <20231203140756.GI1489931@ziepe.ca>
References: <20230916003118.2540661-1-seanjc@google.com> <20230916003118.2540661-6-seanjc@google.com>
 <20230918152110.GI13795@ziepe.ca> <ZQhxpesyXeG+qbS6@google.com>
 <20230918160258.GL13795@ziepe.ca> <ZWp_q1w01NCZi8KX@google.com> <20231203140756.GI1489931@ziepe.ca>
Message-ID: <ZXkVSKULLivrMkBl@google.com>

On Sun, Dec 03, 2023, Jason Gunthorpe wrote:
> On Fri, Dec 01, 2023 at 04:51:55PM -0800, Sean Christopherson wrote:
> 
> > There's one more wrinkle: this patch is buggy in that it doesn't ensure the liveliness
> > of KVM-the-module, i.e. nothing prevents userspace from unloading kvm.ko while VFIO
> > still holds a reference to a kvm structure, and so invoking ->put_kvm() could jump
> > into freed code.  To fix that, KVM would also need to pass along a module pointer :-(
> 
> Maybe we should be refcounting the struct file not the struct kvm?
> 
> Then we don't need special helpers and it keeps the module alive correctly.

Huh.  It took my brain a while to catch up, but this seems comically obvious in
hindsight.  I *love* this approach, both conceptually and from a code perspective.

Handing VFIO (and any other external entities) a file makes it so that KVM effectively
interacts with users via files, regardless of whether the user lives in userspace
or the kernel.  That makes it easier to reason about the safety of operations,
e.g. in addition to ensuring KVM-the-module is pinned, having a file pointer allows
KVM to verify that the incoming pointer does indeed represent a VM.  Which isn't
necessary by any means, but it's a nice sanity check.

>From a code perspective, it's far cleaner than manually grabbing module references,
and having only a file pointers makes it a wee bit harder for non-KVM code to
poke into KVM, e.g. keeps us honest.

Assuming nothing blows up in testing, I'll go this route for v2.

Thanks!


From thiago.bauermann at linaro.org  Tue Dec 12 18:45:06 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Tue, 12 Dec 2023 23:45:06 -0300
Subject: [PATCH v7 37/39] kselftest/arm64: Add a GCS stress test
In-Reply-To: <20231122-arm64-gcs-v7-37-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-37-201c483bd775@kernel.org>
Message-ID: <87zfyex1l9.fsf@linaro.org>


I'm going a bit out-of-order to report a build failure in a test:

Mark Brown <broonie at kernel.org> writes:

> +// Recurse x20 times
> +.macro recurse id

I get an assembler error here:

gcc -nostdlib gcs-stress-thread.S -o /home/thiago.bauermann/src/linux/tools/testing/selftests/arm64/gcs/gcs-stress-thread
gcs-stress-thread.S: Assembler messages:
gcs-stress-thread.S:236: Error: unexpected end of file in macro `recurse' definition
make[2]: *** [Makefile:24: /home/thiago.bauermann/src/linux/tools/testing/selftests/arm64/gcs/gcs-stress-thread] Error 1

This is with gas from Ubuntu 22.04, which ships binutils 2.38.

> +function recurse\id
> +	stp	x29, x30, [sp, #-16]!
> +	mov	x29, sp
> +
> +	cmp	x20, 0
> +	beq	1f
> +	sub	x20, x20, 1
> +	bl	recurse\id
> +
> +1:
> +	ldp	x29, x30, [sp], #16
> +
> +	// Do a syscall immediately prior to returning to try to provoke
> +	// scheduling and migration at a point where coherency issues
> +	// might trigger.
> +	mov	x8, #__NR_getpid
> +	svc	#0
> +
> +	ret
> +endfunction
> +.endmacro
> +
> +// Generate and use two copies so we're changing the GCS contents
> +recurse 1
> +recurse 2

-- 
Thiago


From bhe at redhat.com  Tue Dec 12 19:23:06 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 13 Dec 2023 11:23:06 +0800
Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <ZXECHg37DRZ9BQsP@MiWiFi-R3L-srv>
References: <20231130023955.5257-1-bhe@redhat.com>
 <20231130023955.5257-6-bhe@redhat.com>
 <20231201-blog-blasphemy-985d2665903c@wendy>
 <ZW3yXWJ7rTrtZzyg@MiWiFi-R3L-srv>
 <20231204-liftoff-enclosure-d3e3daf0ab6e@spud>
 <ZXCVUD9cCYEShrrj@MiWiFi-R3L-srv>
 <20231206-pasta-embassy-c7250740b16c@spud>
 <ZXECHg37DRZ9BQsP@MiWiFi-R3L-srv>
Message-ID: <ZXkjmrWOH1dLbHGB@MiWiFi-R3L-srv>

On 12/07/23 at 07:22am, Baoquan He wrote:
> On 12/06/23 at 04:54pm, Conor Dooley wrote:
> > On Wed, Dec 06, 2023 at 11:37:52PM +0800, Baoquan He wrote:
> > > On 12/04/23 at 04:14pm, Conor Dooley wrote:
> > > > On Mon, Dec 04, 2023 at 11:38:05PM +0800, Baoquan He wrote:
> > > > > On 12/01/23 at 10:38am, Conor Dooley wrote:
> > > > > > On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
> > > > > > 
> > > > > > $subject has a typo in the arch bit :)
> > > > > 
> > > > > Indeed, will fix if need report. Thanks for careful checking.
> > > > > 
> > > > > > 
> > > > > > > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > > > > > > loading related codes.
> > > > > > 
> > > > > > Commit messages should be understandable in isolation, but this only
> > > > > > explains (part of) what is obvious in the diff. Why is this change
> > > > > > being made?
> > > > > 
> > > > > The purpose has been detailedly described in cover letter and patch 1
> > > > > log. Andrew has picked these patches into his tree and grabbed the cover
> > > > > letter log into the relevant commit for people's later checking. All
> > > > > these seven patches will be present in mainline together. This is common
> > > > > way when posting patch series? Please let me know if I misunderstand
> > > > > anything.
> > > > 
> > > > Each patch having a commit message that explains why a change is being
> > > > made is the expectation. It is especially useful to explain the why
> > > > here, since it is not just a mechanical conversion of pr_debug()s as the
> > > > commit message suggests.
> > > 
> > > Sounds reasonable. I rephrase the patch 3 log as below, do you think
> > > it's OK to you?
> > 
> > Yes, but with one comment.
> > 
> > > 
> > > I will also adjust patch logs on other ARCH once this one is done.
> > > Thanks.
> > > 
> > > =============================
> > > Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if required
> > > 
> > > Then when specifying '-d' for kexec_file_load interface, loaded
> > > locations of kernel/initrd/cmdline etc can be printed out to help debug.
> > > 
> > > Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > > loading related codes.
> > > 
> > 
> > > And also replace pr_notice() with kexec_dprintk() in elf_kexec_load()
> > > because it's make sense to always print out loaded location of purgatory
>               ~
> > > and device tree even though users don't expect the message.
> 
> Fixed typo:
> ==========
> 
> And also replace pr_notice() with kexec_dprintk() in elf_kexec_load()
> because it doesn't make sense to always print out loaded location of
> purgatory and device tree even though users don't expect the message.

I will post v4 to include these suggested changes, please add comments
if there's any concern. Thanks for reviewing.

> 
> > 
> > This seems to contradict what you said in your earlier mail, about
> > moving these from notice to debug. I think you missed a negation in your
> > new version of the commit message. What you said in response to me seems
> > like a more complete explanation anyway:
> 
> Ah, I made mistake when typing, these printing is only for debugging,
> so always printing out them is not suggested.
> 
> > 	always printing out the loaded location of purgatory and
> > 	device tree doesn't make sense. It will be confusing when users
> > 	see these even when they do normal kexec/kdump loading.
> > 
> > Thanks,
> > Conor.
> > 
> > > And also remove kexec_image_info() because the content has been printed
> > > out in generic code.
> > > 
> > > ============================
> > > 
> > > > 
> > > > > > 
> > > > > > > 
> > > > > > > And also remove kexec_image_info() because the content has been printed
> > > > > > > out in generic code.
> > > > > > > 
> > > > > > > Signed-off-by: Baoquan He <bhe at redhat.com>
> > > > > > > ---
> > > > > > >  arch/riscv/kernel/elf_kexec.c     | 11 ++++++-----
> > > > > > >  arch/riscv/kernel/machine_kexec.c | 26 --------------------------
> > > > > > >  2 files changed, 6 insertions(+), 31 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
> > > > > > > index e60fbd8660c4..5bd1ec3341fe 100644
> > > > > > > --- a/arch/riscv/kernel/elf_kexec.c
> > > > > > > +++ b/arch/riscv/kernel/elf_kexec.c
> > > > > > > @@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > > >  	if (ret)
> > > > > > >  		goto out;
> > > > > > >  	kernel_start = image->start;
> > > > > > > -	pr_notice("The entry point of kernel at 0x%lx\n", image->start);
> > > > > > >  
> > > > > > >  	/* Add the kernel binary to the image */
> > > > > > >  	ret = riscv_kexec_elf_load(image, &ehdr, &elf_info,
> > > > > > > @@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > > >  		image->elf_load_addr = kbuf.mem;
> > > > > > >  		image->elf_headers_sz = headers_sz;
> > > > > > >  
> > > > > > > -		pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > > > > > -			 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > > > > > +		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > > > > > +			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> > > > > > >  
> > > > > > >  		/* Setup cmdline for kdump kernel case */
> > > > > > >  		modified_cmdline = setup_kdump_cmdline(image, cmdline,
> > > > > > > @@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > > >  		pr_err("Error loading purgatory ret=%d\n", ret);
> > > > > > >  		goto out;
> > > > > > >  	}
> > > > > > > +	kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem);
> > > > > > > +
> > > > > > >  	ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry",
> > > > > > >  					     &kernel_start,
> > > > > > >  					     sizeof(kernel_start), 0);
> > > > > > > @@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > > >  		if (ret)
> > > > > > >  			goto out;
> > > > > > >  		initrd_pbase = kbuf.mem;
> > > > > > 
> > > > > > > -		pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > > > > > +		kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase);
> > > > > > 
> > > > > > This is not a pr_debug().
> > > > > > 
> > > > > > >  	}
> > > > > > >  
> > > > > > >  	/* Add the DTB to the image */
> > > > > > > @@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
> > > > > > >  	}
> > > > > > >  	/* Cache the fdt buffer address for memory cleanup */
> > > > > > >  	image->arch.fdt = fdt;
> > > > > > 
> > > > > > > -	pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > > > > > +	kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem);
> > > > > > 
> > > > > > Neither is this. Why are they being moved from pr_notice()?
> > > > > 
> > > > > You are right. 
> > > > > 
> > > > > While always printing out the loaded location of purgatory and
> > > > > device tree doesn't make sense. It will be confusing when users
> > > > > see these even when they do normal kexec/kdump loading. It should be
> > > > > changed to pr_debug().
> > > > > 
> > > > > Which way do you suggest?
> > > > > 1) change it back to pr_debug(), fix it in another patch;
> > > > > 2) keep it as is in the patch;
> > > > 
> > > > Personally I think it is fine to change them all in one patch, but the
> > > > rationale for converting pr_notice() to your new debug infrastructure
> > > > needs to be in the commit message.
> > > 
> > > Sure, sounds good to me. I have changed the patch log to reflect this as
> > > you suggested, please help check. Thanks again.
> > > 
> 
> 



From billy_tsai at aspeedtech.com  Tue Dec 12 19:23:23 2023
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Wed, 13 Dec 2023 03:23:23 +0000
Subject: [PATCH RESEND v10 0/3] Support pwm/tach driver for aspeed ast26xx
In-Reply-To: <ed9d28e0-f879-41f3-8679-7ed5e0eec7ce@linaro.org>
References: <20231107105025.1480561-1-billy_tsai@aspeedtech.com>
 <3ea9ef0c-27c0-4304-8bf7-26710224c3b1@roeck-us.net>
 <20231206174823.ok6rrufhez33rte5@pengutronix.de>
 <ed9d28e0-f879-41f3-8679-7ed5e0eec7ce@linaro.org>
Message-ID: <OSQPR06MB72529B0769B89A21DDFB8B1F8B8DA@OSQPR06MB7252.apcprd06.prod.outlook.com>

On 06/12/2023 18:48, Uwe Kleine-K?nig wrote:
>> On Tue, Nov 07, 2023 at 11:02:43AM -0800, Guenter Roeck wrote:
>>> On 11/7/23 02:50, Billy Tsai wrote:
>>>> Unlike the old design that the register setting of the TACH should based
>>>> on the configure of the PWM. In ast26xx, the dependency between pwm and
>>>> tach controller is eliminated and becomes a separate hardware block. One
>>>> is used to provide pwm output and another is used to monitor the frequency
>>>> of the input. This driver implements them by exposing two kernel
>>>> subsystems: PWM and HWMON. The PWM subsystem can be utilized alongside
>>>> existing drivers for controlling elements such as fans (pwm-fan.c),
>>>> beepers (pwm-beeper.c) and so on. Through the HWMON subsystem, the driver
>>>> provides sysfs interfaces for fan.
>>>>
>>>> Changes since v9:
>>>> Change the type of fan-driving-mode to string
>>>> Fix some typos and formatting issues.
>>>>
>>>
>>> What is the resend about ?
>>
>> And to the original v10 there is a reply by Krzysztof;
>> see https://lore.kernel.org/linux-pwm/3d9e50db-19f0-43b3-8042-2f80a1e7b79e at linaro.org/ .
>>
>> I'll mark the original and this resend as "changes-requested" in our
>> patchwork. Probably the most cooperative way to object is to send a v11
>> and point out the changes compared to v10.

> The resend might be fixing issues from v10, but who knows which and how
> many. In any case it should be v11, not a resend.

I apologize for responding to this question inappropriately. I only replied to Guenter and removed
the others.
The reason for the resend is simply to remove the 'Change-Id' in the commit log, which triggers an
error when running scripts/checkpatch.pl. 
It's a minor issue, and I forgot to mention this change in the cover letter.
I sincerely apologize for any confusion.

Best regards,
Billy Tsai


From anshuman.khandual at arm.com  Tue Dec 12 19:55:52 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 13 Dec 2023 09:25:52 +0530
Subject: [PATCH V15 2/8] KVM: arm64: Prevent guest accesses into BRBE
 system registers/instructions
In-Reply-To: <86v89ebcn2.wl-maz@kernel.org>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
 <20231201053906.1261704-3-anshuman.khandual@arm.com>
 <86v89ebcn2.wl-maz@kernel.org>
Message-ID: <b319f8ed-5848-4663-bc1b-7afe160bbcd3@arm.com>



On 12/4/23 13:52, Marc Zyngier wrote:
> On Fri, 01 Dec 2023 05:39:00 +0000,
> Anshuman Khandual <anshuman.khandual at arm.com> wrote:
>> Currently BRBE feature is not supported in a guest environment. This hides
>> BRBE feature availability via masking ID_AA64DFR0_EL1.BRBE field. This also
>> blocks guest accesses into BRBE system registers and instructions as if the
>> underlying hardware never implemented FEAT_BRBE feature.
>>
>> Cc: Marc Zyngier <maz at kernel.org>
>> Cc: Oliver Upton <oliver.upton at linux.dev>
>> Cc: James Morse <james.morse at arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will at kernel.org>
>> Cc: kvmarm at lists.linux.dev
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>>  arch/arm64/kvm/sys_regs.c | 130 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 130 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 4735e1b37fb3..42701065b3cd 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -1583,6 +1583,9 @@ static u64 read_sanitised_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
>>  	/* Hide SPE from guests */
>>  	val &= ~ID_AA64DFR0_EL1_PMSVer_MASK;
>>  
>> +	/* Hide BRBE from guests */
>> +	val &= ~ID_AA64DFR0_EL1_BRBE_MASK;
>> +
>>  	return val;
>>  }
>>  
>> @@ -2042,6 +2045,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>  	{ SYS_DESC(SYS_DC_CISW), access_dcsw },
>>  	{ SYS_DESC(SYS_DC_CIGSW), access_dcgsw },
>>  	{ SYS_DESC(SYS_DC_CIGDSW), access_dcgsw },
>> +	{ SYS_DESC(OP_BRB_IALL), undef_access },
>> +	{ SYS_DESC(OP_BRB_INJ), undef_access },
>>  
>>  	DBG_BCR_BVR_WCR_WVR_EL1(0),
>>  	DBG_BCR_BVR_WCR_WVR_EL1(1),
>> @@ -2072,6 +2077,131 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>  	{ SYS_DESC(SYS_DBGCLAIMCLR_EL1), trap_raz_wi },
>>  	{ SYS_DESC(SYS_DBGAUTHSTATUS_EL1), trap_dbgauthstatus_el1 },
>>  
>> +	/*
>> +	 * BRBE branch record sysreg address space is interleaved between
>> +	 * corresponding BRBINF<N>_EL1, BRBSRC<N>_EL1, and BRBTGT<N>_EL1.
>> +	 */
>> +	{ SYS_DESC(SYS_BRBINF0_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBSRC0_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBTGT0_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBINF16_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBSRC16_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBTGT16_EL1), undef_access },
> Surely we can do better than this wall of text. Please look at what we
> do for the debug registers, and adopt a similar pattern. This should
> result in one line per group of 3 registers.
> 
> What is the plan for KVM support beyond this?
We are planning to add support for simultaneous and independent branch record
tracing via perf branch stack sampling inside the guest and the host. But will
prevent tracing of the guest execution from the host.


From rdunlap at infradead.org  Tue Dec 12 20:38:36 2023
From: rdunlap at infradead.org (Randy Dunlap)
Date: Tue, 12 Dec 2023 20:38:36 -0800
Subject: [PATCH] soc: fsl: dpio: fix spelling errors
Message-ID: <20231213043836.6921-1-rdunlap@infradead.org>

Correct spelling mistakes as identified by codespell.

Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
Cc: Roy Pledge <Roy.Pledge at nxp.com>
Cc: Li Yang <leoyang.li at nxp.com>
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
---
 include/soc/fsl/dpaa2-io.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -- a/include/soc/fsl/dpaa2-io.h b/include/soc/fsl/dpaa2-io.h
--- a/include/soc/fsl/dpaa2-io.h
+++ b/include/soc/fsl/dpaa2-io.h
@@ -22,7 +22,7 @@ struct device;
  * DOC: DPIO Service
  *
  * The DPIO service provides APIs for users to interact with the datapath
- * by enqueueing and dequeing frame descriptors.
+ * by enqueueing and dequeueing frame descriptors.
  *
  * The following set of APIs can be used to enqueue and dequeue frames
  * as well as producing notification callbacks when data is available
@@ -33,7 +33,7 @@ struct device;
 
 /**
  * struct dpaa2_io_desc - The DPIO descriptor
- * @receives_notifications: Use notificaton mode. Non-zero if the DPIO
+ * @receives_notifications: Use notification mode. Non-zero if the DPIO
  *                  has a channel.
  * @has_8prio:      Set to non-zero for channel with 8 priority WQs.  Ignored
  *                  unless receives_notification is TRUE.


From anshuman.khandual at arm.com  Tue Dec 12 20:56:16 2023
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 13 Dec 2023 10:26:16 +0530
Subject: [PATCH V15 5/8] KVM: arm64: nvhe: Disable branch generation in
 nVHE guests
In-Reply-To: <e48f5cdc-2711-4a03-a074-da87d84b3caf@arm.com>
References: <20231201053906.1261704-1-anshuman.khandual@arm.com>
 <20231201053906.1261704-6-anshuman.khandual@arm.com>
 <86ttoybbp4.wl-maz@kernel.org> <e48f5cdc-2711-4a03-a074-da87d84b3caf@arm.com>
Message-ID: <26ab1190-f437-477b-b09c-6522a1d3fe1d@arm.com>



On 12/11/23 11:30, Anshuman Khandual wrote:
> On 12/4/23 14:12, Marc Zyngier wrote:
>> On Fri, 01 Dec 2023 05:39:03 +0000,
>> Anshuman Khandual <anshuman.khandual at arm.com> wrote:
>>> Disable the BRBE before we enter the guest, saving the status and enable it
>>> back once we get out of the guest. This is just to avoid capturing records
>>> in the guest kernel/userspace, which would be confusing the samples.
>> Why does it have to be limited to non-VHE? What protects host EL0
>> records from guest's EL0 execution when the host is VHE?
> In a scenario when running the host in VHE mode
>  
> - The host might have enabled branch records for host EL0 through BRBCR_EL2.E0HBRE
>   indirectly via accessing BRBCR_EL1.E0BRE
> 
> - But after the guest switches in on the cpu - BRBCR_EL2.E0HBRE will still remain
>   set and enable branch records in guest EL0 as well because BRBCR_EL1.E0BRE will
>   not have any effect when EL2 is implemented and HCR_EL2.TGE == 1. The guest EL0
>   execution branch records will find their way into branch records being captured
>   for host EL0
> 
> You are right. The host EL0 branch records too need to be protected from guest EL0
> execution. A similar BRBCR_EL1 save/restore mechanism is needed for VHE as well ?

Looking at this again, seems like host EL0 records will be protected from
guest EL0 execution as HCR_EL2.TGE toggles when th guest switches in thus
enforcing BRBCR_EL1.E0BRE (which is clear) requirement for capturing guest
EL0 branch records.

arch/arm64/kvm/hyp/vhe/tlb.c

__tlb_switch_to_guest() {
	....
	val = read_sysreg(hcr_el2);
        val &= ~HCR_TGE;
        write_sysreg(val, hcr_el2);
	isb();
}

HCR_TGE comes back via HCR_HOST_VHE_FLAGS when the host switches back in.

__tlb_switch_to_host() {
	write_sysreg(HCR_HOST_VHE_FLAGS, hcr_el2);
        isb();
	....
}


From bhe at redhat.com  Tue Dec 12 21:57:40 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 13 Dec 2023 13:57:40 +0800
Subject: [PATCH v4 0/7] kexec_file: print out debugging message if required
Message-ID: <20231213055747.61826-1-bhe@redhat.com>

Currently, specifying '-d' on kexec command will print a lot of debugging
informationabout kexec/kdump loading with kexec_load interface.

However, kexec_file_load prints nothing even though '-d' is specified.
It's very inconvenient to debug or analyze the kexec/kdump loading when
something wrong happened with kexec/kdump itself or develper want to
check the kexec/kdump loading.

In this patchset, a kexec_file flag is KEXEC_FILE_DEBUG added and checked
in code. If it's passed in, debugging message of kexec_file code will be
printed out and can be seen from console and dmesg. Otherwise, the
debugging message is printed like beofre when pr_debug() is taken.

Note:
****
=====
1) The code in kexec-tools utility also need be changed to support
passing KEXEC_FILE_DEBUG to kernel when 'kexec -s -d' is specified.
The patch link is here:
=========
[PATCH] kexec_file: add kexec_file flag to support debug printing
http://lists.infradead.org/pipermail/kexec/2023-November/028505.html

2) s390 also has kexec_file code, while I am not sure what debugging
information is necessary. So leave it to s390 developer.

Test:
****
====
Testing was done in v1 on x86_64 and arm64. For v4, tested on x86_64
again. And on x86_64, the printed messages look like below:
--------------------------------------------------------------
kexec measurement buffer for the loaded kernel at 0x207fffe000.
Loaded purgatory at 0x207fff9000
Loaded boot_param, command line and misc at 0x207fff3000 bufsz=0x1180 memsz=0x1180
Loaded 64bit kernel at 0x207c000000 bufsz=0xc88200 memsz=0x3c4a000
Loaded initrd at 0x2079e79000 bufsz=0x2186280 memsz=0x2186280
Final command line is: root=/dev/mapper/fedora_intel--knightslanding--lb--02-root ro
rd.lvm.lv=fedora_intel-knightslanding-lb-02/root console=ttyS0,115200N81 crashkernel=256M
E820 memmap:
0000000000000000-000000000009a3ff (1)
000000000009a400-000000000009ffff (2)
00000000000e0000-00000000000fffff (2)
0000000000100000-000000006ff83fff (1)
000000006ff84000-000000007ac50fff (2)
......
000000207fff6150-000000207fff615f (128)
000000207fff6160-000000207fff714f (1)
000000207fff7150-000000207fff715f (128)
000000207fff7160-000000207fff814f (1)
000000207fff8150-000000207fff815f (128)
000000207fff8160-000000207fffffff (1)
nr_segments = 5
segment[0]: buf=0x000000004e5ece74 bufsz=0x211 mem=0x207fffe000 memsz=0x1000
segment[1]: buf=0x000000009e871498 bufsz=0x4000 mem=0x207fff9000 memsz=0x5000
segment[2]: buf=0x00000000d879f1fe bufsz=0x1180 mem=0x207fff3000 memsz=0x2000
segment[3]: buf=0x000000001101cd86 bufsz=0xc88200 mem=0x207c000000 memsz=0x3c4a000
segment[4]: buf=0x00000000c6e38ac7 bufsz=0x2186280 mem=0x2079e79000 memsz=0x2187000
kexec_file_load: type:0, start:0x207fff91a0 head:0x109e004002 flags:0x8
---------------------------------------------------------------------------

History:
=========
v3->v4:
- Add the explanation about why kexec_dprintk() need be introduced to
  replace pr_debug() in log of ARCH patch, suggested by Conor.
- Mentioned why pr_notice() need be replaced with kexec_dprintk() in
  function elf_kexec_load() of risc-v, Suggested by Conor.
- Change breaking one message line into two back to one line, pointed
  out by Joe.
v2->v3:
- Adjust all the indentation of continuation line to the open parenthesis
  for all kexec_dprintk() call sites. Thank Joe to point this out.
- Fix the LKP report that macro kexec_dprintk() is invalid when
  CONFIG_KEXEC=Y, CONFIG_KEXEC_FILE=n, CONFIG_CRASH_DUMP=y.

v1->v2:
- Take the new format of kexec_dprintk() suggested by Joe which can
  reduce kernel text size.
- Fix building error of patch 2 in kernel/crash_core.c reported by LKP.
- Fix building warning on arm64 in patch 4 reported by LKP.

Baoquan He (7):
  kexec_file: add kexec_file flag to control debug printing
  kexec_file: print out debugging message if required
  kexec_file, x86: print out debugging message if required
  kexec_file, arm64: print out debugging message if required
  kexec_file, ricv: print out debugging message if required
  kexec_file, power: print out debugging message if required
  kexec_file, parisc: print out debugging message if required

 arch/arm64/kernel/kexec_image.c        |  6 +++---
 arch/arm64/kernel/machine_kexec.c      | 26 ++++++--------------------
 arch/arm64/kernel/machine_kexec_file.c | 12 ++++++------
 arch/parisc/kernel/kexec_file.c        |  8 ++++----
 arch/powerpc/kexec/elf_64.c            |  8 ++++----
 arch/powerpc/kexec/file_load_64.c      | 18 +++++++++---------
 arch/riscv/kernel/elf_kexec.c          | 11 ++++++-----
 arch/riscv/kernel/machine_kexec.c      | 26 --------------------------
 arch/x86/kernel/crash.c                |  4 ++--
 arch/x86/kernel/kexec-bzimage64.c      | 23 ++++++++++++++---------
 include/linux/kexec.h                  |  9 ++++++++-
 include/uapi/linux/kexec.h             |  1 +
 kernel/crash_core.c                    |  8 +++++---
 kernel/kexec_core.c                    |  2 ++
 kernel/kexec_file.c                    | 14 +++++++++++---
 security/integrity/ima/ima_kexec.c     |  4 ++--
 16 files changed, 83 insertions(+), 97 deletions(-)

-- 
2.41.0



From bhe at redhat.com  Tue Dec 12 21:57:41 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 13 Dec 2023 13:57:41 +0800
Subject: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing
In-Reply-To: <20231213055747.61826-1-bhe@redhat.com>
References: <20231213055747.61826-1-bhe@redhat.com>
Message-ID: <20231213055747.61826-2-bhe@redhat.com>

When specifying 'kexec -c -d', kexec_load interface will print loading
information, e.g the regions where kernel/initrd/purgatory/cmdline
are put, the memmap passed to 2nd kernel taken as system RAM ranges,
and printing all contents of struct kexec_segment, etc. These are
very helpful for analyzing or positioning what's happening when
kexec/kdump itself failed. The debugging printing for kexec_load
interface is made in user space utility kexec-tools.

Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
Because kexec_file code is mostly implemented in kernel space, and the
debugging printing functionality is missed. It's not convenient when
debugging kexec/kdump loading and jumping with kexec_file_load
interface.

Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
message printing. And add global variable kexec_file_dbg_print and
macro kexec_dprintk() to facilitate the printing.

This is a preparation, later kexec_dprintk() will be used to replace the
existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
kexec/kdump loading information. If '-d' is not specified, it regresses
to pr_debug().

Signed-off-by: Baoquan He <bhe at redhat.com>
---
 include/linux/kexec.h      | 9 ++++++++-
 include/uapi/linux/kexec.h | 1 +
 kernel/kexec_core.c        | 2 ++
 kernel/kexec_file.c        | 3 +++
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 8227455192b7..400cb6c02176 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -403,7 +403,7 @@ bool kexec_load_permitted(int kexec_image_type);
 
 /* List of defined/legal kexec file flags */
 #define KEXEC_FILE_FLAGS	(KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
-				 KEXEC_FILE_NO_INITRAMFS)
+				 KEXEC_FILE_NO_INITRAMFS | KEXEC_FILE_DEBUG)
 
 /* flag to track if kexec reboot is in progress */
 extern bool kexec_in_progress;
@@ -500,6 +500,13 @@ static inline int crash_hotplug_memory_support(void) { return 0; }
 static inline unsigned int crash_get_elfcorehdr_size(void) { return 0; }
 #endif
 
+extern bool kexec_file_dbg_print;
+
+#define kexec_dprintk(fmt, ...)					\
+	printk("%s" fmt,					\
+	       kexec_file_dbg_print ? KERN_INFO : KERN_DEBUG,	\
+	       ##__VA_ARGS__)
+
 #else /* !CONFIG_KEXEC_CORE */
 struct pt_regs;
 struct task_struct;
diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
index 01766dd839b0..c17bb096ea68 100644
--- a/include/uapi/linux/kexec.h
+++ b/include/uapi/linux/kexec.h
@@ -25,6 +25,7 @@
 #define KEXEC_FILE_UNLOAD	0x00000001
 #define KEXEC_FILE_ON_CRASH	0x00000002
 #define KEXEC_FILE_NO_INITRAMFS	0x00000004
+#define KEXEC_FILE_DEBUG	0x00000008
 
 /* These values match the ELF architecture values.
  * Unless there is a good reason that should continue to be the case.
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index be5642a4ec49..f70bf3a7885c 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -52,6 +52,8 @@ atomic_t __kexec_lock = ATOMIC_INIT(0);
 /* Flag to indicate we are going to kexec a new kernel */
 bool kexec_in_progress = false;
 
+bool kexec_file_dbg_print;
+
 int kexec_should_crash(struct task_struct *p)
 {
 	/*
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index f9a419cd22d4..aca5dac74044 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -123,6 +123,8 @@ void kimage_file_post_load_cleanup(struct kimage *image)
 	 */
 	kfree(image->image_loader_data);
 	image->image_loader_data = NULL;
+
+	kexec_file_dbg_print = false;
 }
 
 #ifdef CONFIG_KEXEC_SIG
@@ -278,6 +280,7 @@ kimage_file_alloc_init(struct kimage **rimage, int kernel_fd,
 	if (!image)
 		return -ENOMEM;
 
+	kexec_file_dbg_print = !!(flags & KEXEC_FILE_DEBUG);
 	image->file_mode = 1;
 
 	if (kexec_on_panic) {
-- 
2.41.0



From bhe at redhat.com  Tue Dec 12 21:57:42 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 13 Dec 2023 13:57:42 +0800
Subject: [PATCH v4 2/7] kexec_file: print out debugging message if required
In-Reply-To: <20231213055747.61826-1-bhe@redhat.com>
References: <20231213055747.61826-1-bhe@redhat.com>
Message-ID: <20231213055747.61826-3-bhe@redhat.com>

Then when specifying '-d' for kexec_file_load interface, loaded
locations of kernel/initrd/cmdline etc can be printed out to help
debug.

Here replace pr_debug() with the newly added kexec_dprintk() in
kexec_file loading related codes.

And also print out type/start/head of kimage and flags to help debug.

Signed-off-by: Baoquan He <bhe at redhat.com>
---
 kernel/crash_core.c                |  8 +++++---
 kernel/kexec_file.c                | 11 ++++++++---
 security/integrity/ima/ima_kexec.c |  4 ++--
 3 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index efe87d501c8c..380d0d3acc7b 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -551,9 +551,11 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
 		phdr->p_filesz = phdr->p_memsz = mend - mstart + 1;
 		phdr->p_align = 0;
 		ehdr->e_phnum++;
-		pr_debug("Crash PT_LOAD ELF header. phdr=%p vaddr=0x%llx, paddr=0x%llx, sz=0x%llx e_phnum=%d p_offset=0x%llx\n",
-			phdr, phdr->p_vaddr, phdr->p_paddr, phdr->p_filesz,
-			ehdr->e_phnum, phdr->p_offset);
+#ifdef CONFIG_KEXEC_FILE
+		kexec_dprintk("Crash PT_LOAD ELF header. phdr=%p vaddr=0x%llx, paddr=0x%llx, sz=0x%llx e_phnum=%d p_offset=0x%llx\n",
+			      phdr, phdr->p_vaddr, phdr->p_paddr, phdr->p_filesz,
+			      ehdr->e_phnum, phdr->p_offset);
+#endif
 		phdr++;
 	}
 
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index aca5dac74044..76de1ac7c424 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -204,6 +204,8 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd,
 	if (ret < 0)
 		return ret;
 	image->kernel_buf_len = ret;
+	kexec_dprintk("kernel: %p kernel_size: %#lx\n",
+		      image->kernel_buf, image->kernel_buf_len);
 
 	/* Call arch image probe handlers */
 	ret = arch_kexec_kernel_image_probe(image, image->kernel_buf,
@@ -387,13 +389,14 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
 	if (ret)
 		goto out;
 
+	kexec_dprintk("nr_segments = %lu\n", image->nr_segments);
 	for (i = 0; i < image->nr_segments; i++) {
 		struct kexec_segment *ksegment;
 
 		ksegment = &image->segment[i];
-		pr_debug("Loading segment %d: buf=0x%p bufsz=0x%zx mem=0x%lx memsz=0x%zx\n",
-			 i, ksegment->buf, ksegment->bufsz, ksegment->mem,
-			 ksegment->memsz);
+		kexec_dprintk("segment[%d]: buf=0x%p bufsz=0x%zx mem=0x%lx memsz=0x%zx\n",
+			      i, ksegment->buf, ksegment->bufsz, ksegment->mem,
+			      ksegment->memsz);
 
 		ret = kimage_load_segment(image, &image->segment[i]);
 		if (ret)
@@ -406,6 +409,8 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
 	if (ret)
 		goto out;
 
+	kexec_dprintk("kexec_file_load: type:%u, start:0x%lx head:0x%lx flags:0x%lx\n",
+		      image->type, image->start, image->head, flags);
 	/*
 	 * Free up any temporary buffers allocated which are not needed
 	 * after image has been loaded
diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
index ad133fe120db..dadc1d138118 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -129,8 +129,8 @@ void ima_add_kexec_buffer(struct kimage *image)
 	image->ima_buffer_size = kexec_segment_size;
 	image->ima_buffer = kexec_buffer;
 
-	pr_debug("kexec measurement buffer for the loaded kernel at 0x%lx.\n",
-		 kbuf.mem);
+	kexec_dprintk("kexec measurement buffer for the loaded kernel at 0x%lx.\n",
+		      kbuf.mem);
 }
 #endif /* IMA_KEXEC */
 
-- 
2.41.0



From bhe at redhat.com  Tue Dec 12 21:57:43 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 13 Dec 2023 13:57:43 +0800
Subject: [PATCH v4 3/7] kexec_file, x86: print out debugging message if required
In-Reply-To: <20231213055747.61826-1-bhe@redhat.com>
References: <20231213055747.61826-1-bhe@redhat.com>
Message-ID: <20231213055747.61826-4-bhe@redhat.com>

Then when specifying '-d' for kexec_file_load interface, loaded
locations of kernel/initrd/cmdline etc can be printed out to help
debug.

Here replace pr_debug() with the newly added kexec_dprintk() in
kexec_file loading related codes.

And also print out e820 memmap passed to 2nd kernel just as kexec_load
interface has been doing.

Signed-off-by: Baoquan He <bhe at redhat.com>
---
 arch/x86/kernel/crash.c           |  4 ++--
 arch/x86/kernel/kexec-bzimage64.c | 23 ++++++++++++++---------
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index c92d88680dbf..1715e5f06a59 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -386,8 +386,8 @@ int crash_load_segments(struct kimage *image)
 	if (ret)
 		return ret;
 	image->elf_load_addr = kbuf.mem;
-	pr_debug("Loaded ELF headers at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
-		 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
+	kexec_dprintk("Loaded ELF headers at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+		      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
 
 	return ret;
 }
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index a61c12c01270..e9ae0eac6bf9 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -82,7 +82,7 @@ static int setup_cmdline(struct kimage *image, struct boot_params *params,
 
 	cmdline_ptr[cmdline_len - 1] = '\0';
 
-	pr_debug("Final command line is: %s\n", cmdline_ptr);
+	kexec_dprintk("Final command line is: %s\n", cmdline_ptr);
 	cmdline_ptr_phys = bootparams_load_addr + cmdline_offset;
 	cmdline_low_32 = cmdline_ptr_phys & 0xffffffffUL;
 	cmdline_ext_32 = cmdline_ptr_phys >> 32;
@@ -272,7 +272,12 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
 
 	nr_e820_entries = params->e820_entries;
 
+	kexec_dprintk("E820 memmap:\n");
 	for (i = 0; i < nr_e820_entries; i++) {
+		kexec_dprintk("%016llx-%016llx (%d)\n",
+			      params->e820_table[i].addr,
+			      params->e820_table[i].addr + params->e820_table[i].size - 1,
+			      params->e820_table[i].type);
 		if (params->e820_table[i].type != E820_TYPE_RAM)
 			continue;
 		start = params->e820_table[i].addr;
@@ -424,7 +429,7 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
 	 * command line. Make sure it does not overflow
 	 */
 	if (cmdline_len + MAX_ELFCOREHDR_STR_LEN > header->cmdline_size) {
-		pr_debug("Appending elfcorehdr=<addr> to command line exceeds maximum allowed length\n");
+		kexec_dprintk("Appending elfcorehdr=<addr> to command line exceeds maximum allowed length\n");
 		return ERR_PTR(-EINVAL);
 	}
 
@@ -445,7 +450,7 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
 		return ERR_PTR(ret);
 	}
 
-	pr_debug("Loaded purgatory at 0x%lx\n", pbuf.mem);
+	kexec_dprintk("Loaded purgatory at 0x%lx\n", pbuf.mem);
 
 
 	/*
@@ -490,8 +495,8 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
 	if (ret)
 		goto out_free_params;
 	bootparam_load_addr = kbuf.mem;
-	pr_debug("Loaded boot_param, command line and misc at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
-		 bootparam_load_addr, kbuf.bufsz, kbuf.bufsz);
+	kexec_dprintk("Loaded boot_param, command line and misc at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+		      bootparam_load_addr, kbuf.bufsz, kbuf.bufsz);
 
 	/* Load kernel */
 	kbuf.buffer = kernel + kern16_size;
@@ -505,8 +510,8 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
 		goto out_free_params;
 	kernel_load_addr = kbuf.mem;
 
-	pr_debug("Loaded 64bit kernel at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
-		 kernel_load_addr, kbuf.bufsz, kbuf.memsz);
+	kexec_dprintk("Loaded 64bit kernel at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+		      kernel_load_addr, kbuf.bufsz, kbuf.memsz);
 
 	/* Load initrd high */
 	if (initrd) {
@@ -520,8 +525,8 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
 			goto out_free_params;
 		initrd_load_addr = kbuf.mem;
 
-		pr_debug("Loaded initrd at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
-				initrd_load_addr, initrd_len, initrd_len);
+		kexec_dprintk("Loaded initrd at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+			      initrd_load_addr, initrd_len, initrd_len);
 
 		setup_initrd(params, initrd_load_addr, initrd_len);
 	}
-- 
2.41.0



From bhe at redhat.com  Tue Dec 12 21:57:44 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 13 Dec 2023 13:57:44 +0800
Subject: [PATCH v4 4/7] kexec_file, arm64: print out debugging message if required
In-Reply-To: <20231213055747.61826-1-bhe@redhat.com>
References: <20231213055747.61826-1-bhe@redhat.com>
Message-ID: <20231213055747.61826-5-bhe@redhat.com>

Then when specifying '-d' for kexec_file_load interface, loaded
locations of kernel/initrd/cmdline etc can be printed out to help
debug.

Here replace pr_debug() with the newly added kexec_dprintk() in
kexec_file loading related codes.

And also remove the kimage->segment[] printing because the generic code
has done the printing.

Signed-off-by: Baoquan He <bhe at redhat.com>
---
 arch/arm64/kernel/kexec_image.c        |  6 +++---
 arch/arm64/kernel/machine_kexec.c      | 26 ++++++--------------------
 arch/arm64/kernel/machine_kexec_file.c | 12 ++++++------
 3 files changed, 15 insertions(+), 29 deletions(-)

diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
index 636be6715155..532d72ea42ee 100644
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -122,9 +122,9 @@ static void *image_load(struct kimage *image,
 	kernel_segment->memsz -= text_offset;
 	image->start = kernel_segment->mem;
 
-	pr_debug("Loaded kernel at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
-				kernel_segment->mem, kbuf.bufsz,
-				kernel_segment->memsz);
+	kexec_dprintk("Loaded kernel at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+		      kernel_segment->mem, kbuf.bufsz,
+		      kernel_segment->memsz);
 
 	return NULL;
 }
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index 078910db77a4..b38aae5b488d 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -32,26 +32,12 @@
 static void _kexec_image_info(const char *func, int line,
 	const struct kimage *kimage)
 {
-	unsigned long i;
-
-	pr_debug("%s:%d:\n", func, line);
-	pr_debug("  kexec kimage info:\n");
-	pr_debug("    type:        %d\n", kimage->type);
-	pr_debug("    start:       %lx\n", kimage->start);
-	pr_debug("    head:        %lx\n", kimage->head);
-	pr_debug("    nr_segments: %lu\n", kimage->nr_segments);
-	pr_debug("    dtb_mem: %pa\n", &kimage->arch.dtb_mem);
-	pr_debug("    kern_reloc: %pa\n", &kimage->arch.kern_reloc);
-	pr_debug("    el2_vectors: %pa\n", &kimage->arch.el2_vectors);
-
-	for (i = 0; i < kimage->nr_segments; i++) {
-		pr_debug("      segment[%lu]: %016lx - %016lx, 0x%lx bytes, %lu pages\n",
-			i,
-			kimage->segment[i].mem,
-			kimage->segment[i].mem + kimage->segment[i].memsz,
-			kimage->segment[i].memsz,
-			kimage->segment[i].memsz /  PAGE_SIZE);
-	}
+	kexec_dprintk("%s:%d:\n", func, line);
+	kexec_dprintk("  kexec kimage info:\n");
+	kexec_dprintk("    type:        %d\n", kimage->type);
+	kexec_dprintk("    head:        %lx\n", kimage->head);
+	kexec_dprintk("    kern_reloc: %pa\n", &kimage->arch.kern_reloc);
+	kexec_dprintk("    el2_vectors: %pa\n", &kimage->arch.el2_vectors);
 }
 
 void machine_kexec_cleanup(struct kimage *kimage)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index a11a6e14ba89..0e017358f4ba 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -127,8 +127,8 @@ int load_other_segments(struct kimage *image,
 		image->elf_load_addr = kbuf.mem;
 		image->elf_headers_sz = headers_sz;
 
-		pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
-			 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
+		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
 	}
 
 	/* load initrd */
@@ -148,8 +148,8 @@ int load_other_segments(struct kimage *image,
 			goto out_err;
 		initrd_load_addr = kbuf.mem;
 
-		pr_debug("Loaded initrd at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
-				initrd_load_addr, kbuf.bufsz, kbuf.memsz);
+		kexec_dprintk("Loaded initrd at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+			      initrd_load_addr, kbuf.bufsz, kbuf.memsz);
 	}
 
 	/* load dtb */
@@ -179,8 +179,8 @@ int load_other_segments(struct kimage *image,
 	image->arch.dtb = dtb;
 	image->arch.dtb_mem = kbuf.mem;
 
-	pr_debug("Loaded dtb at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
-			kbuf.mem, kbuf.bufsz, kbuf.memsz);
+	kexec_dprintk("Loaded dtb at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+		      kbuf.mem, kbuf.bufsz, kbuf.memsz);
 
 	return 0;
 
-- 
2.41.0



From bhe at redhat.com  Tue Dec 12 21:57:45 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 13 Dec 2023 13:57:45 +0800
Subject: [PATCH v4 5/7] kexec_file, ricv: print out debugging message if required
In-Reply-To: <20231213055747.61826-1-bhe@redhat.com>
References: <20231213055747.61826-1-bhe@redhat.com>
Message-ID: <20231213055747.61826-6-bhe@redhat.com>

Then when specifying '-d' for kexec_file_load interface, loaded
locations of kernel/initrd/cmdline etc can be printed out to help debug.

Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file
loading related codes.

And also replace pr_notice() with kexec_dprintk() in elf_kexec_load()
because loaded location of purgatory and device tree are only printed
out for debugging, it doesn't make sense to always print them out.

And also remove kexec_image_info() because the content has been printed
out in generic code.

Signed-off-by: Baoquan He <bhe at redhat.com>
---
 arch/riscv/kernel/elf_kexec.c     | 11 ++++++-----
 arch/riscv/kernel/machine_kexec.c | 26 --------------------------
 2 files changed, 6 insertions(+), 31 deletions(-)

diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c
index e60fbd8660c4..5bd1ec3341fe 100644
--- a/arch/riscv/kernel/elf_kexec.c
+++ b/arch/riscv/kernel/elf_kexec.c
@@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
 	if (ret)
 		goto out;
 	kernel_start = image->start;
-	pr_notice("The entry point of kernel at 0x%lx\n", image->start);
 
 	/* Add the kernel binary to the image */
 	ret = riscv_kexec_elf_load(image, &ehdr, &elf_info,
@@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
 		image->elf_load_addr = kbuf.mem;
 		image->elf_headers_sz = headers_sz;
 
-		pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
-			 image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
+		kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+			      image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
 
 		/* Setup cmdline for kdump kernel case */
 		modified_cmdline = setup_kdump_cmdline(image, cmdline,
@@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
 		pr_err("Error loading purgatory ret=%d\n", ret);
 		goto out;
 	}
+	kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem);
+
 	ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry",
 					     &kernel_start,
 					     sizeof(kernel_start), 0);
@@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
 		if (ret)
 			goto out;
 		initrd_pbase = kbuf.mem;
-		pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase);
+		kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase);
 	}
 
 	/* Add the DTB to the image */
@@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf,
 	}
 	/* Cache the fdt buffer address for memory cleanup */
 	image->arch.fdt = fdt;
-	pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem);
+	kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem);
 	goto out;
 
 out_free_fdt:
diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
index 2d139b724bc8..ed9cad20c039 100644
--- a/arch/riscv/kernel/machine_kexec.c
+++ b/arch/riscv/kernel/machine_kexec.c
@@ -18,30 +18,6 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 
-/*
- * kexec_image_info - Print received image details
- */
-static void
-kexec_image_info(const struct kimage *image)
-{
-	unsigned long i;
-
-	pr_debug("Kexec image info:\n");
-	pr_debug("\ttype:        %d\n", image->type);
-	pr_debug("\tstart:       %lx\n", image->start);
-	pr_debug("\thead:        %lx\n", image->head);
-	pr_debug("\tnr_segments: %lu\n", image->nr_segments);
-
-	for (i = 0; i < image->nr_segments; i++) {
-		pr_debug("\t    segment[%lu]: %016lx - %016lx", i,
-			image->segment[i].mem,
-			image->segment[i].mem + image->segment[i].memsz);
-		pr_debug("\t\t0x%lx bytes, %lu pages\n",
-			(unsigned long) image->segment[i].memsz,
-			(unsigned long) image->segment[i].memsz /  PAGE_SIZE);
-	}
-}
-
 /*
  * machine_kexec_prepare - Initialize kexec
  *
@@ -60,8 +36,6 @@ machine_kexec_prepare(struct kimage *image)
 	unsigned int control_code_buffer_sz = 0;
 	int i = 0;
 
-	kexec_image_info(image);
-
 	/* Find the Flattened Device Tree and save its physical address */
 	for (i = 0; i < image->nr_segments; i++) {
 		if (image->segment[i].memsz <= sizeof(fdt))
-- 
2.41.0



From bhe at redhat.com  Tue Dec 12 21:57:46 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 13 Dec 2023 13:57:46 +0800
Subject: [PATCH v4 6/7] kexec_file, power: print out debugging message if required
In-Reply-To: <20231213055747.61826-1-bhe@redhat.com>
References: <20231213055747.61826-1-bhe@redhat.com>
Message-ID: <20231213055747.61826-7-bhe@redhat.com>

Then when specifying '-d' for kexec_file_load interface, loaded
locations of kernel/initrd/cmdline etc can be printed out to help
debug.

Here replace pr_debug() with the newly added kexec_dprintk() in
kexec_file loading related codes.

Signed-off-by: Baoquan He <bhe at redhat.com>
---
 arch/powerpc/kexec/elf_64.c       |  8 ++++----
 arch/powerpc/kexec/file_load_64.c | 18 +++++++++---------
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
index eeb258002d1e..904016cf89ea 100644
--- a/arch/powerpc/kexec/elf_64.c
+++ b/arch/powerpc/kexec/elf_64.c
@@ -59,7 +59,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
 	if (ret)
 		goto out;
 
-	pr_debug("Loaded the kernel at 0x%lx\n", kernel_load_addr);
+	kexec_dprintk("Loaded the kernel at 0x%lx\n", kernel_load_addr);
 
 	ret = kexec_load_purgatory(image, &pbuf);
 	if (ret) {
@@ -67,7 +67,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
 		goto out;
 	}
 
-	pr_debug("Loaded purgatory at 0x%lx\n", pbuf.mem);
+	kexec_dprintk("Loaded purgatory at 0x%lx\n", pbuf.mem);
 
 	/* Load additional segments needed for panic kernel */
 	if (image->type == KEXEC_TYPE_CRASH) {
@@ -99,7 +99,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
 			goto out;
 		initrd_load_addr = kbuf.mem;
 
-		pr_debug("Loaded initrd at 0x%lx\n", initrd_load_addr);
+		kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_load_addr);
 	}
 
 	fdt = of_kexec_alloc_and_setup_fdt(image, initrd_load_addr,
@@ -132,7 +132,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
 
 	fdt_load_addr = kbuf.mem;
 
-	pr_debug("Loaded device tree at 0x%lx\n", fdt_load_addr);
+	kexec_dprintk("Loaded device tree at 0x%lx\n", fdt_load_addr);
 
 	slave_code = elf_info.buffer + elf_info.proghdrs[0].p_offset;
 	ret = setup_purgatory_ppc64(image, slave_code, fdt, kernel_load_addr,
diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c
index 961a6dd67365..5b4c5cb23354 100644
--- a/arch/powerpc/kexec/file_load_64.c
+++ b/arch/powerpc/kexec/file_load_64.c
@@ -577,7 +577,7 @@ static int add_usable_mem_property(void *fdt, struct device_node *dn,
 		       NODE_PATH_LEN, dn);
 		return -EOVERFLOW;
 	}
-	pr_debug("Memory node path: %s\n", path);
+	kexec_dprintk("Memory node path: %s\n", path);
 
 	/* Now that we know the path, find its offset in kdump kernel's fdt */
 	node = fdt_path_offset(fdt, path);
@@ -590,8 +590,8 @@ static int add_usable_mem_property(void *fdt, struct device_node *dn,
 	/* Get the address & size cells */
 	n_mem_addr_cells = of_n_addr_cells(dn);
 	n_mem_size_cells = of_n_size_cells(dn);
-	pr_debug("address cells: %d, size cells: %d\n", n_mem_addr_cells,
-		 n_mem_size_cells);
+	kexec_dprintk("address cells: %d, size cells: %d\n", n_mem_addr_cells,
+		      n_mem_size_cells);
 
 	um_info->idx  = 0;
 	if (!check_realloc_usable_mem(um_info, 2)) {
@@ -664,7 +664,7 @@ static int update_usable_mem_fdt(void *fdt, struct crash_mem *usable_mem)
 
 	node = fdt_path_offset(fdt, "/ibm,dynamic-reconfiguration-memory");
 	if (node == -FDT_ERR_NOTFOUND)
-		pr_debug("No dynamic reconfiguration memory found\n");
+		kexec_dprintk("No dynamic reconfiguration memory found\n");
 	else if (node < 0) {
 		pr_err("Malformed device tree: error reading /ibm,dynamic-reconfiguration-memory.\n");
 		return -EINVAL;
@@ -776,8 +776,8 @@ static void update_backup_region_phdr(struct kimage *image, Elf64_Ehdr *ehdr)
 	for (i = 0; i < ehdr->e_phnum; i++) {
 		if (phdr->p_paddr == BACKUP_SRC_START) {
 			phdr->p_offset = image->arch.backup_start;
-			pr_debug("Backup region offset updated to 0x%lx\n",
-				 image->arch.backup_start);
+			kexec_dprintk("Backup region offset updated to 0x%lx\n",
+				      image->arch.backup_start);
 			return;
 		}
 	}
@@ -850,7 +850,7 @@ int load_crashdump_segments_ppc64(struct kimage *image,
 		pr_err("Failed to load backup segment\n");
 		return ret;
 	}
-	pr_debug("Loaded the backup region at 0x%lx\n", kbuf->mem);
+	kexec_dprintk("Loaded the backup region at 0x%lx\n", kbuf->mem);
 
 	/* Load elfcorehdr segment - to export crashing kernel's vmcore */
 	ret = load_elfcorehdr_segment(image, kbuf);
@@ -858,8 +858,8 @@ int load_crashdump_segments_ppc64(struct kimage *image,
 		pr_err("Failed to load elfcorehdr segment\n");
 		return ret;
 	}
-	pr_debug("Loaded elf core header at 0x%lx, bufsz=0x%lx memsz=0x%lx\n",
-		 image->elf_load_addr, kbuf->bufsz, kbuf->memsz);
+	kexec_dprintk("Loaded elf core header at 0x%lx, bufsz=0x%lx memsz=0x%lx\n",
+		      image->elf_load_addr, kbuf->bufsz, kbuf->memsz);
 
 	return 0;
 }
-- 
2.41.0



From bhe at redhat.com  Tue Dec 12 21:57:47 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 13 Dec 2023 13:57:47 +0800
Subject: [PATCH v4 7/7] kexec_file, parisc: print out debugging message if required
In-Reply-To: <20231213055747.61826-1-bhe@redhat.com>
References: <20231213055747.61826-1-bhe@redhat.com>
Message-ID: <20231213055747.61826-8-bhe@redhat.com>

Then when specifying '-d' for kexec_file_load interface, loaded
locations of kernel/initrd/cmdline etc can be printed out to help
debug.

Here replace pr_debug() with the newly added kexec_dprintk() in
kexec_file loading related codes.

Signed-off-by: Baoquan He <bhe at redhat.com>
---
 arch/parisc/kernel/kexec_file.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/parisc/kernel/kexec_file.c b/arch/parisc/kernel/kexec_file.c
index 8c534204f0fd..3fc82130b6c3 100644
--- a/arch/parisc/kernel/kexec_file.c
+++ b/arch/parisc/kernel/kexec_file.c
@@ -38,8 +38,8 @@ static void *elf_load(struct kimage *image, char *kernel_buf,
 	for (i = 0; i < image->nr_segments; i++)
 		image->segment[i].mem = __pa(image->segment[i].mem);
 
-	pr_debug("Loaded the kernel at 0x%lx, entry at 0x%lx\n",
-		 kernel_load_addr, image->start);
+	kexec_dprintk("Loaded the kernel at 0x%lx, entry at 0x%lx\n",
+		      kernel_load_addr, image->start);
 
 	if (initrd != NULL) {
 		kbuf.buffer = initrd;
@@ -51,7 +51,7 @@ static void *elf_load(struct kimage *image, char *kernel_buf,
 		if (ret)
 			goto out;
 
-		pr_debug("Loaded initrd at 0x%lx\n", kbuf.mem);
+		kexec_dprintk("Loaded initrd at 0x%lx\n", kbuf.mem);
 		image->arch.initrd_start = kbuf.mem;
 		image->arch.initrd_end = kbuf.mem + initrd_len;
 	}
@@ -68,7 +68,7 @@ static void *elf_load(struct kimage *image, char *kernel_buf,
 		if (ret)
 			goto out;
 
-		pr_debug("Loaded cmdline at 0x%lx\n", kbuf.mem);
+		kexec_dprintk("Loaded cmdline at 0x%lx\n", kbuf.mem);
 		image->arch.cmdline = kbuf.mem;
 	}
 out:
-- 
2.41.0



From xinglong.yang at cixtech.com  Tue Dec 12 22:02:18 2023
From: xinglong.yang at cixtech.com (Xinglong Yang)
Date: Wed, 13 Dec 2023 06:02:18 +0000
Subject: [BUG REPORT] firmware: arm_scmi: Shared Memory Overwritten in SCMI
 Mailbox Communication
Message-ID: <PUZPR06MB54981E6FA00D82BFDBB864FBF08DA@PUZPR06MB5498.apcprd06.prod.outlook.com>

The shared memory is overwritten happened in some condition and the detail are
as follows:
Based on mailbox transportation. The thread A is waiting for response and The 
thread B is waiting the mark_txdone() to submit the next message. When the thread
A is timed out because that the callee do not reply promptly and then caller begins
to tx_tick() for the next message(for thread B). At the same time, the shared memory
is written by the callee(response for thread A) and set channel free. After the callee
has written the shared memory. The caller written the shared memory again for
thread B. In such case the shared memory written by callee is overwritten by caller. 
Later, the caller received the completion IRQ for Thread A(BUT has been overwritten
by Thread B's tx->buffer). The caller checks the shared memory discover that the buffer
is error. Which case triggers a chain of errors.

The part of error logs are as follows:
[    19.135368] arm-scmi firmware:scmi: timed out in resp(caller: xxx)
[    19.508536] arm-scmi firmware:scmi: Invalid message type:0 for 301 - HDR:0x%X state:1

Because the same token ID are received twice by caller, the second IRQ with the same token
will be treated as invalid message and abandoned.

Regards,
Xinglong


From mcgrof at kernel.org  Tue Dec 12 22:27:01 2023
From: mcgrof at kernel.org (Luis Chamberlain)
Date: Tue, 12 Dec 2023 22:27:01 -0800
Subject: [PATCH] drivers: perf: constify the ctl_table argument of the
 riscv user access handler
In-Reply-To: <mhng-8f7ddf72-8e2f-4dac-a67e-624eb5511a14@palmer-ri-x1c9a>
References: <20231206-flanking-frill-fffeca740221@spud>
 <mhng-8f7ddf72-8e2f-4dac-a67e-624eb5511a14@palmer-ri-x1c9a>
Message-ID: <ZXlOtWf8ItvQwPT/@bombadil.infradead.org>

On Tue, Dec 12, 2023 at 01:04:42PM -0800, Palmer Dabbelt wrote:
> On Wed, 06 Dec 2023 02:55:48 PST (-0800), Conor Dooley wrote:
> > On Wed, Dec 06, 2023 at 09:46:42AM +0100, Marek Szyprowski wrote:
> > > 
> > > Fix riscv build break after commit c8be9e66ca1e ("sysctl: treewide:
> > > constify the ctl_table argument of handlers").
> > > 
> > > Fixes: c8be9e66ca1e ("sysctl: treewide: constify the ctl_table argument of handlers")
> > > Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
> > 
> > This breaks the build when applied to the RISC-V tree. I'm going to mark
> > it "handled elsewhere" in patchwork since it needs to go into whatever
> > tree has the broken commit.
> 
> Ya, thanks.  There's a second copy of the fix over at
> https://lore.kernel.org/all/20231212-garage-pellet-c6a2bd34854c at spud/ .
> 
> Reviewed-by: Palmer Dabbelt <palmer at rivosinc.com>
> Acked-by: Palmer Dabbelt <palmer at rivosinc.com>
> 
> for this one too.  Just trying to merge that fixed hash into 6.7-rc1 is
> giving me a conflict, so I don't really want to pull it in myself.  So I
> think the best bet here is to have whomever took the patch take the fix, but
> LMK if there's some shared tag thing I should grab to take this into the
> RISC-V tree.

Thomas has to fold this in to his patch. I'll drop his patches for now
from linux-next.

  Luis


From krzysztof.kozlowski at linaro.org  Tue Dec 12 22:28:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 07:28:07 +0100
Subject: [PATCH v3 08/13] dt-bindings: imx6q-pcie: Add imx95 pcie
 compatible string
In-Reply-To: <ZXjsq2QtFa2V0BAl@lizhi-Precision-Tower-5810>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-9-Frank.Li@nxp.com>
 <20231212224426.GA2948988-robh@kernel.org>
 <ZXjsq2QtFa2V0BAl@lizhi-Precision-Tower-5810>
Message-ID: <8ea476e0-e026-4599-a5d5-66a499a1f422@linaro.org>

On 13/12/2023 00:28, Frank Li wrote:
	>>>      items:
>>> @@ -90,6 +91,22 @@ required:
>>>  allOf:
>>>    - $ref: /schemas/pci/snps,dw-pcie.yaml#
>>>    - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          enum:
>>> +            - fsl,imx95-pcie
>>> +    then:
>>> +      properties:
>>> +        reg:
>>> +          minItems: 4
>>> +        reg-names:
>>> +          items:
>>> +            - const: dbi
>>> +            - const: serdes
>>
>> Did you test this? It should fail because 'serdes' would need to be 
>> added to snps,dw-pcie.yaml.
> 
> I run "make dt_binding_check DT_SCHEMA_FILES=/pci/", no error report.
> And PCIe function can work.

Did you test your DTS. The answer is, like Rob suspected: no, you did
not test it.

This fails.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 12 22:29:22 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 07:29:22 +0100
Subject: [PATCH v3 12/13] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint
 compatible string
In-Reply-To: <20231211215842.134823-13-Frank.Li@nxp.com>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-13-Frank.Li@nxp.com>
Message-ID: <de84c311-ee02-4bb7-89cf-8b4f4d80d204@linaro.org>

On 11/12/2023 22:58, Frank Li wrote:
> Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
> Add reg-name: "atu", "dbi2", "dma" and "serdes".
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> 
> Notes:
>     Change from v1 to v3
>     - new patches at v3
> 
>  .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 20 +++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> index ee155ed5f1811..36d8f117fdfb3 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> @@ -22,6 +22,7 @@ properties:
>        - fsl,imx8mm-pcie-ep
>        - fsl,imx8mq-pcie-ep
>        - fsl,imx8mp-pcie-ep
> +      - fsl,imx95-pcie-ep
>  
>    reg:
>      minItems: 2
> @@ -62,11 +63,30 @@ required:
>  allOf:
>    - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
>    - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          enum:
> +            - fsl,imx95-pcie-ep
> +    then:
> +      properties:
> +        reg:
> +          minItems: 6
> +        reg-names:
> +          items:
> +            - const: dbi
> +            - const: atu
> +            - const: dbi2
> +            - const: serdes
> +            - const: dma
> +            - const: addr_space

Again, was it tested? Testing in this context means: bindings check pass
(dt_binding_check) and all your DTS pass, or at least do not introduce
any new warning.


Best regards,
Krzysztof



From arnd at arndb.de  Tue Dec 12 22:32:14 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 13 Dec 2023 07:32:14 +0100
Subject: [PATCH] leds: sun50i-a100: avoid division-by-zero warning
In-Reply-To: <CAJF2gTQckdn=uDfeLKu7wceOq7LT1KGJUT0vARMr9zUy3xc4xw@mail.gmail.com>
References: <20231212214536.175327-1-arnd@kernel.org>
 <CAJF2gTQckdn=uDfeLKu7wceOq7LT1KGJUT0vARMr9zUy3xc4xw@mail.gmail.com>
Message-ID: <42f522b5-6406-4bef-8180-3a431ee884a5@app.fastmail.com>

On Wed, Dec 13, 2023, at 02:26, Guo Ren wrote:
> On Wed, Dec 13, 2023 at 5:45?AM Arnd Bergmann <arnd at kernel.org> wrote:
>>  {
>>         const struct sun50i_a100_ledc_timing *timing = &priv->timing;
>>         unsigned long mod_freq = clk_get_rate(priv->mod_clk);
>> -       u32 cycle_ns = NSEC_PER_SEC / mod_freq;
>> +       u32 cycle_ns;
>>         u32 control;
>>
>> +       if (!mod_freq)
>> +               return;
>> +
> Shall we need err_disable_bus_clk?
>
> + static int sun50i_a100_ledc_set_timing(struct sun50i_a100_ledc *priv)
> - static void sun50i_a100_ledc_set_timing(struct sun50i_a100_ledc *priv)

I'm not worried about it too much, as there is already an error check
on priv->mod_clk being unavailable during initialization. The case that
the warning is about is just for build-testing on architectures that
don't even use COMMON_CLK.

     Arnd


From krzysztof.kozlowski at linaro.org  Tue Dec 12 22:35:04 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 07:35:04 +0100
Subject: [PATCH v2] dt-bindings: mailbox: add Versal IPI bindings
In-Reply-To: <20231212230353.888714-1-tanmay.shah@amd.com>
References: <20231212230353.888714-1-tanmay.shah@amd.com>
Message-ID: <d91a9278-f70e-4f0f-92c1-ce0bdac69ff5@linaro.org>

On 13/12/2023 00:03, Tanmay Shah wrote:
> Add documentation for AMD-Xilinx Versal platform Inter Processor Interrupt
> controller. Versal IPI controller contains buffer-less IPI which do not
> have buffers for message passing. For such IPI channels message buffers
> are not expected and only notification to/from remote agent is expected.
> 
> Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> ---
> 


>  properties:
>    compatible:
> -    const: xlnx,zynqmp-ipi-mailbox
> +    enum:
> +      - xlnx,zynqmp-ipi-mailbox
> +      - xlnx,versal-ipi-mailbox
>  
>    method:
>      description: |
>        The method of calling the PM-API firmware layer.
> -      Permitted values are.
> -      - "smc" : SMC #0, following the SMCCC
> -      - "hvc" : HVC #0, following the SMCCC
> -

Independent change. Please do not mix logical changes in one patch.

>      $ref: /schemas/types.yaml#/definitions/string
>      enum:
>        - smc
> @@ -58,16 +56,26 @@ properties:
>    '#size-cells':
>      const: 2
>  
> -  xlnx,ipi-id:
> -    description: |
> -      Remote Xilinx IPI agent ID of which the mailbox is connected to.
> -    $ref: /schemas/types.yaml#/definitions/uint32
> +  reg:
> +    minItems: 1
> +    maxItems: 2
> +
> +  reg-names:
> +    minItems: 1
> +    maxItems: 2

I don't understand why this change is here. Previously you did not have
MMIO address space? If yes, then where do you restrict the old device to
disallow these?


>  
>    interrupts:
>      maxItems: 1
>  
>    ranges: true
>  
> +  xlnx,ipi-id:
> +    description: |
> +      Remote Xilinx IPI agent ID of which the mailbox is connected to.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 64
> +
>  patternProperties:
>    '^mailbox@[0-9a-f]+$':
>      description: Internal ipi mailbox node
> @@ -76,57 +84,116 @@ patternProperties:
>      properties:
>  
>        compatible:
> -        const: xlnx,zynqmp-ipi-dest-mailbox
> +        enum:
> +          - xlnx,zynqmp-ipi-dest-mailbox
> +          - xlnx,versal-ipi-dest-mailbox
>  
> -      xlnx,ipi-id:
> -        description:
> -          Remote Xilinx IPI agent ID of which the mailbox is connected to.
> -        $ref: /schemas/types.yaml#/definitions/uint32
> +      reg:
> +        minItems: 1
> +        maxItems: 4
> +
> +      reg-names:
> +        minItems: 1
> +        maxItems: 4

Same concern.

>  
>        '#mbox-cells':
>          const: 1
>          description:
>            It contains tx(0) or rx(1) channel IPI id number.
>  
> -      reg:
> -        maxItems: 4
> -
> -      reg-names:
> -        items:
> -          - const: local_request_region
> -          - const: local_response_region
> -          - const: remote_request_region
> -          - const: remote_response_region
> +      xlnx,ipi-id:
> +        description:
> +          Remote Xilinx IPI agent ID of which the mailbox is connected to.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 64
>  
>      required:
>        - compatible
>        - reg
>        - reg-names
>        - "#mbox-cells"
> -
> -additionalProperties: false
> -
> +      - xlnx,ipi-id
> +
> +    allOf:
> +      - if:
> +          properties:
> +            compatible:
> +              contains:
> +                enum:
> +                  - xlnx,zynqmp-ipi-dest-mailbox
> +        then:
> +          properties:
> +            reg:
> +              items:
> +                - description: Host agent request message buffer
> +                - description: Host agent response message buffer
> +                - description: Remote agent request message buffer
> +                - description: Remote agent response message buffer
> +
> +            reg-names:
> +              items:
> +                - const: local_request_region
> +                - const: local_response_region
> +                - const: remote_request_region
> +                - const: remote_response_region
> +        else:
> +          properties:
> +            reg:
> +              minItems: 1
> +              items:
> +                - description: Remote IPI agent control register
> +                - description: Remote IPI agent optional message buffer

Were these described in old binding? If not, it's a separate change.

> +
> +            reg-names:
> +              minItems: 1
> +              items:
> +                - const: ctrl
> +                - const: msg

Blank line

>  required:
>    - compatible
> -  - interrupts
>    - '#address-cells'
>    - '#size-cells'
> +  - interrupts

Separate change with its own rationale. Trivial cleanups can be
organized in one patch, but should not be mixed with adding new devices.

>    - xlnx,ipi-id
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - xlnx,versal-ipi-mailbox
> +    then:
> +      properties:
> +        reg:
> +          items:
> +            - description: Host IPI agent control registers
> +            - description: Host IPI agent optional message buffers
> +
> +        reg-names:
> +          items:
> +            - const: ctrl
> +            - const: msg
> +
> +      required:
> +        - reg
> +        - reg-names
> +
> +additionalProperties: false
> +
> +

Just one blank line.

>  examples:
>    - |
>      #include<dt-bindings/interrupt-controller/arm-gic.h>
>  
> -    amba {
> -      #address-cells = <0x2>;
> -      #size-cells = <0x2>;
> +    bus {
>        zynqmp-mailbox {
>          compatible = "xlnx,zynqmp-ipi-mailbox";
>          interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
>          xlnx,ipi-id = <0>;
>          #address-cells = <2>;
>          #size-cells = <2>;
> -        ranges;

How is this related to Versal?

>  
>          mailbox: mailbox at ff9905c0 {
>            compatible = "xlnx,zynqmp-ipi-dest-mailbox";
> @@ -144,4 +211,41 @@ examples:
>        };
>      };
>  
> +  - |
> +    #include<dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    bus {
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +      zynqmp-mailbox at ff300000 {

mailbox@

> +        compatible = "xlnx,versal-ipi-mailbox";
> +        interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        reg = <0x0 0xff300000 0x0 0x1000>,
> +              <0x0 0xff990000 0x0 0x1ff>;
> +        reg-names = "ctrl", "msg";
> +        xlnx,ipi-id = <0>;
> +        ranges;
> +


Best regards,
Krzysztof



From chunfeng.yun at mediatek.com  Tue Dec 12 22:35:42 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Wed, 13 Dec 2023 14:35:42 +0800
Subject: [PATCH 2/3] usb: xhci-mtk: fix a short packet issue of gen1 isoc-in transfer
In-Reply-To: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
References: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
Message-ID: <20231213063543.12435-2-chunfeng.yun@mediatek.com>

For Gen1 isoc-in transfer, host still send out unexpected ACK after device
finish the burst with a short packet, this will cause an exception on the
connected device, such as, a usb 4k camera.
It can be fixed by setting rxfifo depth less than 3, prefer to use 2 here,
the side-effect is that may cause performance drop about 10%, including
bulk transfer.

Fixes: 926d60ae64a6 ("usb: xhci-mtk: modify the SOF/ITP interval for mt8195")
Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/host/xhci-mtk.c | 35 +++++++++++++++++++++++++++++++++--
 drivers/usb/host/xhci-mtk.h |  1 +
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bbdf1b0b7be1..a54535877e90 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -73,6 +73,9 @@
 #define FRMCNT_LEV1_RANG	(0x12b << 8)
 #define FRMCNT_LEV1_RANG_MASK	GENMASK(19, 8)
 
+#define HSCH_CFG1		0x960
+#define SCH3_RXFIFO_DEPTH_MASK	GENMASK(21, 20)
+
 #define SS_GEN2_EOF_CFG		0x990
 #define SSG2EOF_OFFSET		0x3c
 
@@ -165,6 +168,33 @@ static void xhci_mtk_set_frame_interval(struct xhci_hcd_mtk *mtk)
 	writel(value, hcd->regs + SS_GEN2_EOF_CFG);
 }
 
+/*
+ * workaround: usb3.2 gen1 isoc rx hw issue
+ * host send out unexpected ACK afer device fininsh a burst transfer with
+ * a short packet.
+ */
+static void xhci_mtk_rxfifo_depth_set(struct xhci_hcd_mtk *mtk)
+{
+	struct usb_hcd *hcd = mtk->hcd;
+	u32 value;
+
+	if (mtk->rxfifo_depth_quirk) {
+		value = readl(hcd->regs + HSCH_CFG1);
+		value &= ~SCH3_RXFIFO_DEPTH_MASK;
+		value |= FIELD_PREP(SCH3_RXFIFO_DEPTH_MASK, 2);
+		writel(value, hcd->regs + HSCH_CFG1);
+	}
+}
+
+static void xhci_mtk_init_quirk(struct xhci_hcd_mtk *mtk)
+{
+	/* workaround only for mt8195 */
+	xhci_mtk_set_frame_interval(mtk);
+
+	/* workaround for SoCs using SSUSB about before IPM v1.6.0 */
+	xhci_mtk_rxfifo_depth_set(mtk);
+}
+
 static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
 {
 	struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
@@ -448,8 +478,7 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
 		if (ret)
 			return ret;
 
-		/* workaround only for mt8195 */
-		xhci_mtk_set_frame_interval(mtk);
+		xhci_mtk_init_quirk(mtk);
 	}
 
 	ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
@@ -527,6 +556,8 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	of_property_read_u32(node, "mediatek,u2p-dis-msk",
 			     &mtk->u2p_dis_msk);
 
+	mtk->rxfifo_depth_quirk = of_property_read_bool(node, "mediatek,rxfifo-depth");
+
 	ret = usb_wakeup_of_property_parse(mtk, node);
 	if (ret) {
 		dev_err(dev, "failed to parse uwk property\n");
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 39f7ae7d3087..2443075530e3 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -166,6 +166,7 @@ struct xhci_hcd_mtk {
 	unsigned int has_ippc:1;
 	unsigned int lpm_support:1;
 	unsigned int u2_lpm_disable:1;
+	unsigned int rxfifo_depth_quirk:1;
 	/* usb remote wakeup */
 	unsigned int uwk_en:1;
 	struct regmap *uwk;
-- 
2.25.1



From chunfeng.yun at mediatek.com  Tue Dec 12 22:35:43 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Wed, 13 Dec 2023 14:35:43 +0800
Subject: [PATCH 3/3] arm64: dts: mediatek: mt8195: Add mediatek,rxfifo-depth to cherry
In-Reply-To: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
References: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
Message-ID: <20231213063543.12435-3-chunfeng.yun@mediatek.com>

Add the quirk property "mediatek,rxfifo-depth" to work around Gen1 isoc-in
transfer issue which send out unexpected ACK even after device already
finished the burst transfer with a short patcket, specially for a 4K
camera device.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index dd5b89b73190..2f2133931846 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -1185,6 +1185,7 @@ &xhci0 {
 
 	vusb33-supply = <&mt6359_vusb_ldo_reg>;
 	vbus-supply = <&usb_vbus>;
+	mediatek,rxfifo-depth;
 };
 
 &xhci1 {
@@ -1192,6 +1193,7 @@ &xhci1 {
 
 	vusb33-supply = <&mt6359_vusb_ldo_reg>;
 	vbus-supply = <&usb_vbus>;
+	mediatek,rxfifo-depth;
 };
 
 &xhci2 {
-- 
2.25.1



From chunfeng.yun at mediatek.com  Tue Dec 12 22:35:41 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Wed, 13 Dec 2023 14:35:41 +0800
Subject: [PATCH 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1 isoc-in transfer issue
Message-ID: <20231213063543.12435-1-chunfeng.yun@mediatek.com>

For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
still send out unexpected ACK after receiving a short packet in burst
transfer, this will cause an exception on connected device, specially for
a 4k camera.
Add a quirk property "mediatek,rxfifo-depth" to work around this hardware
issue;
The side-effect is that may cause performance drop about 10%, including
bulk transfer.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml     | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index e9644e333d78..b8ed68574ba4 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -124,6 +124,16 @@ properties:
       defined in the xHCI spec on MTK's controller.
     default: 5000
 
+  mediatek,rxfifo-depth:
+    description:
+      It is a quirk flag used to work around Gen1 isoc-in endpoint transfer
+      issue that still send out unexpected ACK after device finish the burst
+      transfer with a short packet and cause an exception, specially on a 4K
+      camera device, it happens on controller before about IPM v1.6.0; the
+      side-effect is that may cause performance drop about 10%, include bulk
+      transfer.
+    type: boolean
+
   # the following properties are only used for case 1
   wakeup-source:
     description: enable USB remote wakeup, see power/wakeup-source.txt
-- 
2.25.1



From krzysztof.kozlowski at linaro.org  Tue Dec 12 22:58:33 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 07:58:33 +0100
Subject: [RFC PATCH net-next v3 7/8] dt-bindings: net: mediatek,net: fix
 and complete mt7988-eth binding
In-Reply-To: <ac6a7277fc534f610386bc51b2ff87beade03be8.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <ac6a7277fc534f610386bc51b2ff87beade03be8.1702352117.git.daniel@makrotopia.org>
Message-ID: <06dfdf57-3cc7-4e9c-96c4-f2639d581ecf@linaro.org>

On 12/12/2023 04:51, Daniel Golle wrote:
> Complete support for MT7988 which comes with 3 MACs, SRAM for DMA
> descriptors and uses a dedicated PCS for the SerDes units.
> 
> Fixes: c94a9aabec36 ("dt-bindings: net: mediatek,net: add mt7988-eth binding")
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 12 23:00:59 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 08:00:59 +0100
Subject: [PATCH v5 2/5] dt-bindings: reset: mediatek: add MT7988 ethwarp
 reset IDs
In-Reply-To: <a60f5b5ed58626f3dbac1eab8a5845c3ce9bd17c.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
 <a60f5b5ed58626f3dbac1eab8a5845c3ce9bd17c.1702350213.git.daniel@makrotopia.org>
Message-ID: <1ca36158-c57d-4130-94f5-c3650594498c@linaro.org>

On 12/12/2023 04:18, Daniel Golle wrote:
> Add reset ID for ethwarp subsystem allowing to reset the built-in
> Ethernet switch of the MediaTek MT7988 SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---

No need for one patch per one header. Headers are parts of new binding
patch. If you decide to keep headers separate for easier review, then
they could be in one header-only-patch.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 12 23:04:23 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 08:04:23 +0100
Subject: [PATCH v5 3/5] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <ce9b1e777090724794cf9f0c52bcd8618385fd06.1702350213.git.daniel@makrotopia.org>
References: <152b256d253508cdc7514c0f1c5a9324bde83d46.1702350213.git.daniel@makrotopia.org>
 <ce9b1e777090724794cf9f0c52bcd8618385fd06.1702350213.git.daniel@makrotopia.org>
Message-ID: <7c878a4e-da9b-4e8e-a965-9eeefe073d13@linaro.org>

On 12/12/2023 04:18, Daniel Golle wrote:
> Add various clock controllers found in the MT7988 SoC to existing
> bindings (if applicable) and add files for the new ethwarp, mcusys
> and xfi-pll clock controllers not previously present in any SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---

...

> -      - const: syscon
> +    oneOf:
> +      - items:
> +          - enum:
> +              - mediatek,mt7622-sgmiisys
> +              - mediatek,mt7629-sgmiisys
> +              - mediatek,mt7981-sgmiisys_0
> +              - mediatek,mt7981-sgmiisys_1
> +              - mediatek,mt7986-sgmiisys_0
> +              - mediatek,mt7986-sgmiisys_1
> +          - const: syscon
> +      - items:
> +          - enum:
> +              - mediatek,mt7988-sgmiisys_0
> +              - mediatek,mt7988-sgmiisys_1

No underscores in compatibles. At least for new ones, because you cannot
touch the old.

> +          - const: simple-mfd
> +          - const: syscon
>  
>    reg:
>      maxItems: 1
> @@ -35,11 +42,47 @@ properties:
>      description: Invert polarity of the SGMII data lanes
>      type: boolean
>  
> +  pcs:
> +    type: object
> +    description: HSGMII PCS logic
> +    properties:
> +      compatible:
> +        const: mediatek,mt7988-sgmii
> +
> +      clocks:
> +        maxItems: 3
> +        minItems: 3

drop minItems

> +
> +      clock-names:
> +        items:
> +          - const: sgmii_sel
> +          - const: sgmii_tx
> +          - const: sgmii_rx
> +
> +    required:
> +      - compatible
> +      - clocks
> +      - clock-names
> +
> +    additionalProperties: false
> +
>  required:
>    - compatible
>    - reg
>    - '#clock-cells'
>  

add allOf: here

> +if:
> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - mediatek,mt7988-sgmiisys_0
> +          - mediatek,mt7988-sgmiisys_1
> +
> +then:
> +  required:
> +    - pcs

else: also valid?

Maybe there is no point to have it in this binding?

Best regards,
Krzysztof



From mripard at kernel.org  Tue Dec 12 23:16:04 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Wed, 13 Dec 2023 08:16:04 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
Message-ID: <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>

Hi,

On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> that and don't check the return value. This series fixes the four users
> that do error checking on the returned value and then makes function
> return void.
> 
> Given that the changes to the drivers are simple and so merge conflicts
> (if any) should be easy to handle, I suggest to merge this complete
> series via the clk tree.

I don't think it's the right way to go about it.

clk_rate_exclusive_get() should be expected to fail. For example if
there's another user getting an exclusive rate on the same clock.

If we're not checking for it right now, then it should probably be
fixed, but the callers checking for the error are right to do so if they
rely on an exclusive rate. It's the ones that don't that should be
modified.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/2ce15ac7/attachment.sig>

From viresh.kumar at linaro.org  Tue Dec 12 23:17:22 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Wed, 13 Dec 2023 12:47:22 +0530
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the
 scheduler
In-Reply-To: <20231212142730.998913-2-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org>
Message-ID: <20231213071722.u6n2fokrfs7hf3nb@vireshk-i7>

On 12-12-23, 15:27, Vincent Guittot wrote:
> Provide to the scheduler a feedback about the temporary max available
> capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
> filtered as the pressure will happen for dozens ms or more.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>  drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++++++++++++++++++++++++
>  include/linux/cpufreq.h   | 10 ++++++++
>  2 files changed, 58 insertions(+)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 44db4f59c4cc..7d5f71be8d29 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2563,6 +2563,50 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
>  }
>  EXPORT_SYMBOL(cpufreq_get_policy);
>  
> +DEFINE_PER_CPU(unsigned long, cpufreq_pressure);
> +EXPORT_PER_CPU_SYMBOL_GPL(cpufreq_pressure);
> +
> +/**
> + * cpufreq_update_pressure() - Update cpufreq pressure for CPUs
> + * @cpus        : The related CPUs for which max capacity has been reduced
> + * @capped_freq : The maximum allowed frequency that CPUs can run at
> + *
> + * Update the value of cpufreq pressure for all @cpus in the mask. The
> + * cpumask should include all (online+offline) affected CPUs, to avoid
> + * operating on stale data when hot-plug is used for some CPUs. The
> + * @capped_freq reflects the currently allowed max CPUs frequency due to
> + * freq_qos capping. It might be also a boost frequency value, which is bigger
> + * than the internal 'capacity_freq_ref' max frequency. In such case the
> + * pressure value should simply be removed, since this is an indication that
> + * there is no capping. The @capped_freq must be provided in kHz.
> + */
> +static void cpufreq_update_pressure(const struct cpumask *cpus,

Since this is defined as 'static', why not just pass policy here ?

> +				      unsigned long capped_freq)
> +{
> +	unsigned long max_capacity, capacity, pressure;
> +	u32 max_freq;
> +	int cpu;
> +
> +	cpu = cpumask_first(cpus);
> +	max_capacity = arch_scale_cpu_capacity(cpu);

This anyway expects all of them to be from the same policy ..

> +	max_freq = arch_scale_freq_ref(cpu);
> +
> +	/*
> +	 * Handle properly the boost frequencies, which should simply clean
> +	 * the thermal pressure value.
> +	 */
> +	if (max_freq <= capped_freq)
> +		capacity = max_capacity;
> +	else
> +		capacity = mult_frac(max_capacity, capped_freq, max_freq);
> +
> +	pressure = max_capacity - capacity;
> +

Extra blank line here.

> +
> +	for_each_cpu(cpu, cpus)
> +		WRITE_ONCE(per_cpu(cpufreq_pressure, cpu), pressure);
> +}
> +
>  /**
>   * cpufreq_set_policy - Modify cpufreq policy parameters.
>   * @policy: Policy object to modify.
> @@ -2584,6 +2628,7 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
>  {
>  	struct cpufreq_policy_data new_data;
>  	struct cpufreq_governor *old_gov;
> +	struct cpumask *cpus;
>  	int ret;
>  
>  	memcpy(&new_data.cpuinfo, &policy->cpuinfo, sizeof(policy->cpuinfo));
> @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
>  	policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
>  	trace_cpu_frequency_limits(policy);
>  
> +	cpus = policy->related_cpus;

You don't need the extra variable anyway, but lets just pass policy
instead to the routine.

> +	cpufreq_update_pressure(cpus, policy->max);
> +
>  	policy->cached_target_freq = UINT_MAX;
>  
>  	pr_debug("new min and max freqs are %u - %u kHz\n",
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index afda5f24d3dd..b1d97edd3253 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -241,6 +241,12 @@ struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy);
>  void cpufreq_enable_fast_switch(struct cpufreq_policy *policy);
>  void cpufreq_disable_fast_switch(struct cpufreq_policy *policy);
>  bool has_target_index(void);
> +
> +DECLARE_PER_CPU(unsigned long, cpufreq_pressure);
> +static inline unsigned long cpufreq_get_pressure(int cpu)
> +{
> +	return per_cpu(cpufreq_pressure, cpu);
> +}
>  #else
>  static inline unsigned int cpufreq_get(unsigned int cpu)
>  {
> @@ -263,6 +269,10 @@ static inline bool cpufreq_supports_freq_invariance(void)
>  	return false;
>  }
>  static inline void disable_cpufreq(void) { }
> +static inline unsigned long cpufreq_get_pressure(int cpu)
> +{
> +	return 0;
> +}
>  #endif
>  
>  #ifdef CONFIG_CPU_FREQ_STAT
> -- 
> 2.34.1

-- 
viresh


From krzysztof.kozlowski at linaro.org  Tue Dec 12 23:20:25 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 08:20:25 +0100
Subject: [PATCH v3 08/14] ARM: dts: aspeed: yosemite4: Revise i2c11 and
 i2c12 schematic change
In-Reply-To: <20231211054730.208588-9-Delphine_CC_Chiu@wiwynn.com>
References: <20231211054730.208588-1-Delphine_CC_Chiu@wiwynn.com>
 <20231211054730.208588-9-Delphine_CC_Chiu@wiwynn.com>
Message-ID: <ae52b0d3-84a4-4c78-97e0-e5b479b54f16@linaro.org>

On 11/12/2023 06:47, Delphine CC Chiu wrote:
> Revise i2c11 and i2c12 schematic change:
> - remove space for adm1272 compatible
> - enable interrupt setting for pca9555
> - add eeprom for yosemite4 medusa board/BSM use
> - remove temperature sensor for yosemite4 schematic change
> - add power sensor for power module reading

Way too many changes in one patch. Especially mixing fixes and new
features is bad. Please don't.

> 
> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu at wiwynn.com>
> ---
>  .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 118 ++++++++++++++----
>  1 file changed, 93 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> index da413325ce30..ccb5ecd8d9a6 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> @@ -821,41 +821,94 @@ imux29: i2c at 1 {
>  &i2c11 {
>  	status = "okay";
>  	power-sensor at 10 {
> -		compatible = "adi, adm1272";
> +		compatible = "adi,adm1272";
>  		reg = <0x10>;
>  	};
>  
>  	power-sensor at 12 {
> -		compatible = "adi, adm1272";
> +		compatible = "adi,adm1272";
>  		reg = <0x12>;
>  	};
>  
> -	gpio at 20 {
> +	gpio_ext1: pca9555 at 20 {

That's wrong name.


>  		compatible = "nxp,pca9555";
> -		reg = <0x20>;
> +		pinctrl-names = "default";
>  		gpio-controller;
>  		#gpio-cells = <2>;
> -	};
> -
> -	gpio at 21 {
> +		reg = <0x20>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
> +		gpio-line-names =
> +		"P48V_OCP_GPIO1","P48V_OCP_GPIO2",
> +		"P48V_OCP_GPIO3","FAN_BOARD_0_REVISION_0_R",
> +		"FAN_BOARD_0_REVISION_1_R","FAN_BOARD_1_REVISION_0_R",
> +		"FAN_BOARD_1_REVISION_1_R","RST_MUX_R_N",
> +		"RST_LED_CONTROL_FAN_BOARD_0_N","RST_LED_CONTROL_FAN_BOARD_1_N",
> +		"RST_IOEXP_FAN_BOARD_0_N","RST_IOEXP_FAN_BOARD_1_N",
> +		"PWRGD_LOAD_SWITCH_FAN_BOARD_0_R","PWRGD_LOAD_SWITCH_FAN_BOARD_1_R",
> +		"","";
> +	};
> +
> +	gpio_ext2: pca9555 at 21 {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation


>  		compatible = "nxp,pca9555";
> -		reg = <0x21>;
> +		pinctrl-names = "default";
>  		gpio-controller;
>  		#gpio-cells = <2>;
> -	};
> -
> -	gpio at 22 {
> +		reg = <0x21>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
> +		gpio-line-names =
> +		"DELTA_MODULE_TYPE","VSENSE_ERR_VDROP_R",
> +		"EN_P48V_AUX_0","EN_P48V_AUX_1",
> +		"MEDUSA_BOARD_REV_0","MEDUSA_BOARD_REV_1",
> +		"MEDUSA_BOARD_REV_2","MEDUSA_BOARD_TYPE",
> +		"HSC_OCP_SLOT_ODD_GPIO1","HSC_OCP_SLOT_ODD_GPIO2",
> +		"HSC_OCP_SLOT_ODD_GPIO3","HSC_OCP_SLOT_EVEN_GPIO1",
> +		"HSC_OCP_SLOT_EVEN_GPIO2","HSC_OCP_SLOT_EVEN_GPIO3",
> +		"ADC_TYPE_0_R","ADC_TYPE_1_R";
> +	};
> +
> +	gpio_ext3: pca9555 at 22 {

Please fix it everywhere.

In this patch and all your future patches. I keep repeating the same
feedback...


Best regards,
Krzysztof



From dan.carpenter at linaro.org  Tue Dec 12 23:21:52 2023
From: dan.carpenter at linaro.org (Dan Carpenter)
Date: Wed, 13 Dec 2023 10:21:52 +0300
Subject: [PATCH v9 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <20231207161211.2374093-5-ryan.roberts@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207161211.2374093-5-ryan.roberts@arm.com>
Message-ID: <cb1fe352-ca47-4c3b-ab51-ecf51a83ce50@moroto.mountain>

On Thu, Dec 07, 2023 at 04:12:05PM +0000, Ryan Roberts wrote:
> @@ -4176,10 +4260,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>  	/* Allocate our own private page. */
>  	if (unlikely(anon_vma_prepare(vma)))
>  		goto oom;
> -	folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
> +	folio = alloc_anon_folio(vmf);
> +	if (IS_ERR(folio))
> +		return 0;
>  	if (!folio)
>  		goto oom;

Returning zero is weird.  I think it should be a vm_fault_t code.

This mixing of error pointers and NULL is going to cause problems.
Normally when we have a mix of error pointers and NULL then the NULL is
not an error but instead means that the feature has been deliberately
turned off.  I'm unable to figure out what the meaning is here.

It should return one or the other, or if it's a mix then add a giant
comment explaining what they mean.

regards,
dan carpenter

>  
> +	nr_pages = folio_nr_pages(folio);
> +	addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
> +
>  	if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
>  		goto oom_free_page;
>  	folio_throttle_swaprate(folio, GFP_KERNEL);



From u.kleine-koenig at pengutronix.de  Tue Dec 12 23:25:21 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 13 Dec 2023 08:25:21 +0100
Subject: [PATCH] power: reset: at91: mark at91_wakeup_status non-__init
In-Reply-To: <20231212215002.GA3300655@dev-arch.thelio-3990X>
References: <20231212214658.213510-1-arnd@kernel.org>
 <20231212215002.GA3300655@dev-arch.thelio-3990X>
Message-ID: <20231213072521.z7a37uayjide7ui4@pengutronix.de>

Hello,

[dropped Justin Stitt from Cc, their email address bounced for me in the
past]

On Tue, Dec 12, 2023 at 02:50:02PM -0700, Nathan Chancellor wrote:
> On Tue, Dec 12, 2023 at 10:46:49PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd at arndb.de>
> > 
> > Two copies of the at91_wakeup_status() function are called by the
> > respective probe() callbacks and are marked __init, but the probe
> > functions are no longer annotated that way. This works with gcc because
> > the functions always get inlined, but clang keeps them separate, which
> > can lead to executing freed memory:
> > 
> > WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x80 (section: .text) -> at91_wakeup_status (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text)
> > 
> > Drop the incorrect annotation on these.
> > 
> > Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
> > Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> 
> Thanks, I sent the same change three weeks ago at this point:
> 
> https://lore.kernel.org/20231120-fix-at91-modpost-warnings-v1-1-813671933863 at kernel.org/
> 
> Your commit message is a little better than mine and I don't really care
> which one goes in but it would be good if this could get cleared up
> soon...
> 
> Reviewed-by: Nathan Chancellor <nathan at kernel.org>

I don't care either. Given the change is identical (Nathan's submission
even has "index 126e774e210c..93eece027865 100644" which exactly matches
Arnd's patch), I'll forward my Reviewed-by: tag to here:

Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/f95c75c3/attachment.sig>

From u.kleine-koenig at pengutronix.de  Tue Dec 12 23:43:00 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 13 Dec 2023 08:43:00 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
Message-ID: <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>

Hello Maxime,

On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> > clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> > that and don't check the return value. This series fixes the four users
> > that do error checking on the returned value and then makes function
> > return void.
> > 
> > Given that the changes to the drivers are simple and so merge conflicts
> > (if any) should be easy to handle, I suggest to merge this complete
> > series via the clk tree.
> 
> I don't think it's the right way to go about it.
> 
> clk_rate_exclusive_get() should be expected to fail. For example if
> there's another user getting an exclusive rate on the same clock.
> 
> If we're not checking for it right now, then it should probably be
> fixed, but the callers checking for the error are right to do so if they
> rely on an exclusive rate. It's the ones that don't that should be
> modified.

If some other consumer has already "locked" a clock that I call
clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
this function because I don't want the rate to change e.g. because I
setup some registers in the consuming device to provide a fixed UART
baud rate or i2c bus frequency (and that works as expected). In this
case I won't be able to change the rate of the clock, but that is
signalled by clk_set_rate() failing (iff and when I need awother rate)
which also seems the right place to fail to me.

It's like that since clk_rate_exclusive_get() was introduced in 2017
(commit 55e9b8b7b806ec3f9a8817e13596682a5981c19c).

BTW, I just noticed that my assertion "Most users \"know\" that
[clk_rate_exclusive_get() returns zero unconditionally]" is wrong. As of
next-20231213 there are 3 callers ignoring the return value of
clk_rate_exclusive_get() and 4 that handle (imaginary) returned errors.
I expected this function to be used more extensively. (In fact I think
it should be used more as several drivers rely on the clk rate not
changing.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/583b0b68/attachment-0001.sig>

From krzysztof.kozlowski at linaro.org  Tue Dec 12 23:50:00 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 08:50:00 +0100
Subject: [PATCH v4 0/2] Introduce ExynosAutov920 SoC and SADK board
In-Reply-To: <20231211114145.106255-1-jaewon02.kim@samsung.com>
References: <CGME20231211114215epcas2p226d66c6dd01a4414559272c648c3d464@epcas2p2.samsung.com>
 <20231211114145.106255-1-jaewon02.kim@samsung.com>
Message-ID: <170245380069.18789.1595497375493388753.b4-ty@linaro.org>


On Mon, 11 Dec 2023 20:41:43 +0900, Jaewon Kim wrote:
> ExynosAutov920[1] is ARMv8-based automotive-oriented SoC.
> This SoC is the next generation of exynosautov9 and AE(Automotive Enhanced)
> IPs are used for safety.
> 
> This patchset is the minimal set for ExynosAutov920 SoC and SADK board.
> Currently, ramdisk console is available and Clock, UFS, and USI will be
> added after this patchset.
> 
> [...]

Applied, thanks!

[1/2] pinctrl: samsung: support ExynosAuto GPIO structure
      https://git.kernel.org/pinctrl/samsung/c/884fdaa53b38921165cd9afdb230502b4e1690b0
[2/2] pinctrl: samsung: add exynosautov920 pinctrl
      https://git.kernel.org/pinctrl/samsung/c/6cf96df77338c6a7e753229fe6d330ab60e28cda

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Tue Dec 12 23:52:03 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 08:52:03 +0100
Subject: [PATCH v4 2/2] pinctrl: samsung: add exynosautov920 pinctrl
In-Reply-To: <20231211114145.106255-3-jaewon02.kim@samsung.com>
References: <20231211114145.106255-1-jaewon02.kim@samsung.com>
 <CGME20231211114216epcas2p300bbf4c592d495991c6cc2d96e0b1f85@epcas2p3.samsung.com>
 <20231211114145.106255-3-jaewon02.kim@samsung.com>
Message-ID: <68a36910-e528-45ff-8b59-e7cd95aaef0b@linaro.org>

On 11/12/2023 12:41, Jaewon Kim wrote:
> Add pinctrl data for ExynosAutov920 SoC.
> It has a newly applied pinctrl register layer for ExynosAuto series.
> 
> Pinctrl data for ExynosAutoV920 SoC.
>  - GPA0,GPA1 (10): External wake up interrupt
>  - GPQ0 (2): SPMI (PMIC I/F)
>  - GPB0,GPB1,GPB2,GPB3,GPB4,GPB5,GPB6 (47): I2S Audio
>  - GPH0,GPH1,GPH2,GPH3,GPH4,GPH5,GPH6,GPH8 (49): PCIE, UFS, Ethernet
>  - GPG0,GPG1,GPG2,GPG3,GPG4,GPG5 (29): General purpose
>  - GPP0,GPP1,GPP2,GPP3,GPP4,GPP5,GPP6,GPP7,GPP8,GPP9,GPP10 (77): USI
> 
> Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
> ---
>  .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 140 ++++++++++++++++++
>  drivers/pinctrl/samsung/pinctrl-exynos.c      |  23 ++-
>  drivers/pinctrl/samsung/pinctrl-exynos.h      |  25 ++++
>  drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
>  drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
>  5 files changed, 190 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> index cb965cf93705..a998c296dd05 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> @@ -796,3 +796,143 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
>  	.ctrl		= fsd_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
>  };
> +
> +/* pin banks of exynosautov920 pin-controller 0 (ALIVE) */
> +static const struct samsung_pin_bank_data exynosautov920_pin_banks0[] = {
> +	EXYNOSV920_PIN_BANK_EINTW(8, 0x0000, "gpa0", 0x18, 0x24, 0x28),
> +	EXYNOSV920_PIN_BANK_EINTW(2, 0x1000, "gpa1", 0x18, 0x20, 0x24),
> +	EXYNOS850_PIN_BANK_EINTN(2, 0x2000, "gpq0"),
> +};

Applied with re-ordering it, to keep it after ExynosAutov9. For the
future: don't add entries to the end of lists because it causes exactly
this issue we have here: unnecessary conflicts. Please keep this rule
for entire development, not only pinctrl.

If both you and Peter were observing this basic rule, I would not have
work of reshuffling and fixing conflicts.

Please check the result if I reshuffled/solved conflicts correctly.

Best regards,
Krzysztof



From s-vadapalli at ti.com  Wed Dec 13 00:02:16 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Wed, 13 Dec 2023 13:32:16 +0530
Subject: [PATCH v2] arm64: dts: ti: k3-am654-icssg2: Enable PHY interrupts for ICSSG2
Message-ID: <20231213080216.1710730-1-s-vadapalli@ti.com>

Enable interrupt mode of operation of the DP83867 Ethernet PHY which is
used by ICSSG2. The DP83867 PHY driver already supports interrupt handling
for interrupts generated by the PHY. Thus, add the necessary device-tree
support to enable it.

Since the GPIO1_87 line is muxed with EXT_REFCLK1 and SYNC1_OUT, update
the pinmux to select GPIO1_87 for routing the interrupt.

As the same interrupt line and therefore the same pinmux configuration is
applicable to both Ethernet PHYs used by ICSSG2, allocate the pinmux
resource to the first Ethernet PHY alone.

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
Reviewed-by: MD Danish Anwar <danishanwar at ti.com>
---
Hello,

This patch is based on linux-next tagged next-20231213.

v1:
https://lore.kernel.org/r/20231120063159.539306-1-s-vadapalli at ti.com/
Changes since v1:
- Rebased patch on next-20231213.
- Collected Reviewed-by tag from
  MD Danish Anwar <danishanwar at ti.com>
- Moved pinctrl from MDIO node to Ethernet PHY node based on feedback from
  Nishanth Menon <nm at ti.com>
- Replaced the hard-coded value 0x2 with IRQ_TYPE_EDGE_FALLING for
  setting the interrupt trigger type and level flag based on feedback from
  Nishanth Menon <nm at ti.com>
- Included dt-bindings/interrupt-controller/irq.h in the overlay.
- Updated commit message with details of the pinmux resource allocation.

Regards,
Siddharth.

 arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
index ec8cf20ca3ac..6eabdfa0d602 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
+++ b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
@@ -8,6 +8,7 @@
 /dts-v1/;
 /plugin/;
 
+#include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/net/ti-dp83867.h>
 #include "k3-pinctrl.h"
 
@@ -124,6 +125,15 @@ AM65X_IOPAD(0x0088, PIN_INPUT, 2) /* (AG17) PRG2_PRU0_GPO4.PRG2_RGMII1_RX_CTL */
 	};
 };
 
+&main_pmx1 {
+	/* Select GPIO1_87 for ICSSG2 PHY interrupt */
+	icssg2_phy_irq_pins_default: icssg2-phy-irq-default-pins {
+		pinctrl-single,pins = <
+			AM65X_IOPAD(0x0014, PIN_INPUT, 7) /* (A22) EXT_REFCLK1.GPIO1_87 */
+		>;
+	};
+};
+
 &icssg2_mdio {
 	status = "okay";
 	pinctrl-names = "default";
@@ -132,13 +142,20 @@ &icssg2_mdio {
 	#size-cells = <0>;
 
 	icssg2_phy0: ethernet-phy at 0 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&icssg2_phy_irq_pins_default>;
+
 		reg = <0>;
+		interrupt-parent = <&main_gpio1>;
+		interrupts = <87 IRQ_TYPE_EDGE_FALLING>;
 		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
 		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
 	};
 
 	icssg2_phy1: ethernet-phy at 3 {
 		reg = <3>;
+		interrupt-parent = <&main_gpio1>;
+		interrupts = <87 IRQ_TYPE_EDGE_FALLING>;
 		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
 		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
 	};
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Wed Dec 13 00:05:54 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 09:05:54 +0100
Subject: [PATCH 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1
 isoc-in transfer issue
In-Reply-To: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
References: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
Message-ID: <c1bc144d-07d6-422c-8294-42be47f83e59@linaro.org>

On 13/12/2023 07:35, Chunfeng Yun wrote:
> For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
> still send out unexpected ACK after receiving a short packet in burst
> transfer, this will cause an exception on connected device, specially for
> a 4k camera.
> Add a quirk property "mediatek,rxfifo-depth" to work around this hardware
> issue;
> The side-effect is that may cause performance drop about 10%, including
> bulk transfer.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
>  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml     | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> index e9644e333d78..b8ed68574ba4 100644
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> @@ -124,6 +124,16 @@ properties:
>        defined in the xHCI spec on MTK's controller.
>      default: 5000
>  
> +  mediatek,rxfifo-depth:
> +    description:

The property description and driver patch suggest you configure the
depth of FIFO, so this should be not bool, but some uint32. And then,
use generic "fifo-depth" property to set desired depth.


Best regards,
Krzysztof



From vincent.guittot at linaro.org  Wed Dec 13 00:05:57 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Wed, 13 Dec 2023 09:05:57 +0100
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the scheduler
In-Reply-To: <20231213071722.u6n2fokrfs7hf3nb@vireshk-i7>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org> <20231213071722.u6n2fokrfs7hf3nb@vireshk-i7>
Message-ID: <CAKfTPtC=C3ERO_RDUxxe_Nvq1NuLcNsCsdj=G=vinXmhfpUQZw@mail.gmail.com>

On Wed, 13 Dec 2023 at 08:17, Viresh Kumar <viresh.kumar at linaro.org> wrote:
>
> On 12-12-23, 15:27, Vincent Guittot wrote:
> > Provide to the scheduler a feedback about the temporary max available
> > capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
> > filtered as the pressure will happen for dozens ms or more.
> >
> > Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> > ---
> >  drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++++++++++++++++++++++++
> >  include/linux/cpufreq.h   | 10 ++++++++
> >  2 files changed, 58 insertions(+)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 44db4f59c4cc..7d5f71be8d29 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2563,6 +2563,50 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
> >  }
> >  EXPORT_SYMBOL(cpufreq_get_policy);
> >
> > +DEFINE_PER_CPU(unsigned long, cpufreq_pressure);
> > +EXPORT_PER_CPU_SYMBOL_GPL(cpufreq_pressure);
> > +
> > +/**
> > + * cpufreq_update_pressure() - Update cpufreq pressure for CPUs
> > + * @cpus        : The related CPUs for which max capacity has been reduced
> > + * @capped_freq : The maximum allowed frequency that CPUs can run at
> > + *
> > + * Update the value of cpufreq pressure for all @cpus in the mask. The
> > + * cpumask should include all (online+offline) affected CPUs, to avoid
> > + * operating on stale data when hot-plug is used for some CPUs. The
> > + * @capped_freq reflects the currently allowed max CPUs frequency due to
> > + * freq_qos capping. It might be also a boost frequency value, which is bigger
> > + * than the internal 'capacity_freq_ref' max frequency. In such case the
> > + * pressure value should simply be removed, since this is an indication that
> > + * there is no capping. The @capped_freq must be provided in kHz.
> > + */
> > +static void cpufreq_update_pressure(const struct cpumask *cpus,
>
> Since this is defined as 'static', why not just pass policy here ?

Mainly because we only need the cpumask and also because this follows
the same pattern as other place like arch_topology.c

>
> > +                                   unsigned long capped_freq)
> > +{
> > +     unsigned long max_capacity, capacity, pressure;
> > +     u32 max_freq;
> > +     int cpu;
> > +
> > +     cpu = cpumask_first(cpus);
> > +     max_capacity = arch_scale_cpu_capacity(cpu);
>
> This anyway expects all of them to be from the same policy ..
>
> > +     max_freq = arch_scale_freq_ref(cpu);
> > +
> > +     /*
> > +      * Handle properly the boost frequencies, which should simply clean
> > +      * the thermal pressure value.
> > +      */
> > +     if (max_freq <= capped_freq)
> > +             capacity = max_capacity;
> > +     else
> > +             capacity = mult_frac(max_capacity, capped_freq, max_freq);
> > +
> > +     pressure = max_capacity - capacity;
> > +
>
> Extra blank line here.
>
> > +
> > +     for_each_cpu(cpu, cpus)
> > +             WRITE_ONCE(per_cpu(cpufreq_pressure, cpu), pressure);
> > +}
> > +
> >  /**
> >   * cpufreq_set_policy - Modify cpufreq policy parameters.
> >   * @policy: Policy object to modify.
> > @@ -2584,6 +2628,7 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
> >  {
> >       struct cpufreq_policy_data new_data;
> >       struct cpufreq_governor *old_gov;
> > +     struct cpumask *cpus;
> >       int ret;
> >
> >       memcpy(&new_data.cpuinfo, &policy->cpuinfo, sizeof(policy->cpuinfo));
> > @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
> >       policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
> >       trace_cpu_frequency_limits(policy);
> >
> > +     cpus = policy->related_cpus;
>
> You don't need the extra variable anyway, but lets just pass policy
> instead to the routine.

In fact I have followed what was done in cpufreq_cooling.c with
arch_update_thermal_pressure().

Will remove it

>
> > +     cpufreq_update_pressure(cpus, policy->max);
> > +
> >       policy->cached_target_freq = UINT_MAX;
> >
> >       pr_debug("new min and max freqs are %u - %u kHz\n",
> > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> > index afda5f24d3dd..b1d97edd3253 100644
> > --- a/include/linux/cpufreq.h
> > +++ b/include/linux/cpufreq.h
> > @@ -241,6 +241,12 @@ struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy);
> >  void cpufreq_enable_fast_switch(struct cpufreq_policy *policy);
> >  void cpufreq_disable_fast_switch(struct cpufreq_policy *policy);
> >  bool has_target_index(void);
> > +
> > +DECLARE_PER_CPU(unsigned long, cpufreq_pressure);
> > +static inline unsigned long cpufreq_get_pressure(int cpu)
> > +{
> > +     return per_cpu(cpufreq_pressure, cpu);
> > +}
> >  #else
> >  static inline unsigned int cpufreq_get(unsigned int cpu)
> >  {
> > @@ -263,6 +269,10 @@ static inline bool cpufreq_supports_freq_invariance(void)
> >       return false;
> >  }
> >  static inline void disable_cpufreq(void) { }
> > +static inline unsigned long cpufreq_get_pressure(int cpu)
> > +{
> > +     return 0;
> > +}
> >  #endif
> >
> >  #ifdef CONFIG_CPU_FREQ_STAT
> > --
> > 2.34.1
>
> --
> viresh


From aakarsh.jain at samsung.com  Tue Dec 12 23:58:11 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:28:11 +0530
Subject: [Patch v5 00/11] Add MFC V12 support
In-Reply-To: <d00fa740-bcf8-47af-b70a-cabbb7237d99@xs4all.nl>
References: <CGME20231206063105epcas5p3034f89af2be6922ab04771de099a124a@epcas5p3.samsung.com>
	<20231206063045.97234-1-aakarsh.jain@samsung.com>
	<d00fa740-bcf8-47af-b70a-cabbb7237d99@xs4all.nl>
Message-ID: <108d01da2d9a$20eda670$62c8f350$@samsung.com>



> -----Original Message-----
> From: Hans Verkuil <hverkuil-cisco at xs4all.nl>
> Sent: 06 December 2023 18:29
> To: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org; linux-
> kernel at vger.kernel.org; devicetree at vger.kernel.org
> Cc: m.szyprowski at samsung.com; andrzej.hajda at intel.com;
> mchehab at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> robh+dt at kernel.org; conor+dt at kernel.org; linux-samsung-
> soc at vger.kernel.org; andi at etezian.org; gost.dev at samsung.com;
> alim.akhtar at samsung.com; aswani.reddy at samsung.com;
> pankaj.dubey at samsung.com; ajaykumar.rs at samsung.com
> Subject: Re: [Patch v5 00/11] Add MFC V12 support
> 
> On 06/12/2023 07:30, Aakarsh Jain wrote:
> > This patch series adds MFC v12 support. MFC v12 is used in Tesla FSD SoC.
> >
> > This adds support for following:
> >
> > -Add support for YV12 and I420 format (3-plane) -Add support for Rate
> > Control, UHD and DMABUF for encoder -Add support for DPB buffers
> > allocation based on MFC requirement
> 
> I'm getting one smatch warning:
> 
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c:2453
> s5p_mfc_queue_setup() error: we previously assumed 'ctx->src_fmt' could
> be null (see line 2441)
> 
> And a few kerneldoc warnings:
> 
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h:729:
> warning: Function parameter or member 'chroma_size_1' not described in
> 's5p_mfc_ctx'
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h:729:
> warning: Function parameter or member 'is_10bit' not described in
> 's5p_mfc_ctx'
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h:729:
> warning: Function parameter or member 'is_422' not described in
> 's5p_mfc_ctx'
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h:729:
> warning: Function parameter or member 'stride' not described in
> 's5p_mfc_ctx'
> 
> Something for v6.
> 

Sure. Will fix in v6.

Thanks for review!

> Regards,
> 
> 	Hans
> 
> >
> > Changes since v4:
> > -Addressed review comments by Krzysztof Kozlowski.
> > As per discussion included iommus property in dt-schema.
> > -Addressed review comments by Hans Verkuil.
> > Fixed checkpatch warnings with --strict flag enabled.
> > Upstreamed s5p-mfc-v12.fw to linux-firmware.
> > Added comment in the patch 9 regarding loading mfc firmware v12
> > sequentially.
> > -Addressed review comments by Nicolas Dufresne Made use of v4l2-
> common
> > library to get number of planes needed for particular format in patch
> > 4.
> > v4
> > link:https://patchwork.kernel.org/project/linux-media/patch/2023102510
> > 2216.50480-2-aakarsh.jain at samsung.com/
> >
> > Changes since v3:
> > -Removed vp9 codec support for now and just keeping MFC v12 base
> > patches with necessary hardware controls, decoder, encoder and
> > structural changes. Also covers luma dbp, chroma dpb and mv sizes for
> > each codec as per the UM for MFCv12, along with appropriate alignment.
> > v3 link:
> > https://patchwork.kernel.org/project/linux-media/cover/20221011122516.
> > 32135-1-aakarsh.jain at samsung.com/
> >
> > Changes since v2:
> > -Addressed review comments by Rob Herring.
> > This was regarding the errors found by Rob bot in yaml file. File
> > 'samsung,s5p-mfc.yaml' is already converted into json schema and is
> > merged.
> >
> > -Addressed review comments by Krzysztof Kozlowski.
> > This was regarding depricated properties mentioned in s5p-mfc.txt file.
> > Review comment was addressed and 'samsung,s5p-mfc.yaml' is already
> > merged now.
> >
> > -Addressed review comments by Andi Shyti.
> > This was regarding addition of 'MFC_V10PLUS_BITS' macro in
> > 's5p_mfc_common.h file.
> > v2 link:
> > https://patchwork.kernel.org/project/linux-media/cover/20220907064715.
> > 55778-1-smitha.t at samsung.com/
> >
> > Changes since v1:
> > -Addressed review comments by Krzysztof Kozlowski.
> > Separated bug fixes patches, resent again with fix tag and those are
> > merged now.
> > -Added SoC based compatible string.
> >
> > -Addressed review comments by Andrzej Hajda Assigned width64 and
> > height32 variable with ALIGN(ctx->img_..) used in the code in
> > 's5p_mfc_opr_v6.c' file.
> > v1 link:
> > https://patchwork.kernel.org/project/linux-media/patch/20220517125548.
> > 14746-2-smitha.t at samsung.com/
> >
> > Aakarsh Jain (11):
> >   dt-bindings: media: s5p-mfc: Add mfcv12 variant
> >   media: s5p-mfc: Rename IS_MFCV10 macro
> >   media: s5p-mfc: Add initial support for MFCv12
> >   media: s5p-mfc: Add YV12 and I420 multiplanar format support
> >   media: s5p-mfc: Add support for rate controls in MFCv12
> >   media: s5p-mfc: Add support for UHD encoding.
> >   media: s5p-mfc: Add support for DMABUF for encoder
> >   media: s5p-mfc: Set context for valid case before calling try_run
> >   media: s5p-mfc: Load firmware for each run in MFCv12.
> >   media: s5p-mfc: DPB Count Independent of VIDIOC_REQBUF
> >   arm64: dts: fsd: Add MFC related DT enteries
> >
> >  .../bindings/media/samsung,s5p-mfc.yaml       |  18 ++
> >  arch/arm64/boot/dts/tesla/fsd.dtsi            |  21 ++
> >  .../platform/samsung/s5p-mfc/regs-mfc-v12.h   |  52 +++
> >  .../platform/samsung/s5p-mfc/regs-mfc-v7.h    |   1 +
> >  .../platform/samsung/s5p-mfc/regs-mfc-v8.h    |   3 +
> >  .../media/platform/samsung/s5p-mfc/s5p_mfc.c  |  36 ++-
> > .../platform/samsung/s5p-mfc/s5p_mfc_common.h |  29 +-
> >  .../platform/samsung/s5p-mfc/s5p_mfc_ctrl.c   |  10 +-
> >  .../platform/samsung/s5p-mfc/s5p_mfc_dec.c    |  60 +++-
> >  .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    | 149 ++++++---
> >  .../platform/samsung/s5p-mfc/s5p_mfc_opr.h    |  14 +-
> >  .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c |  12 +-
> > .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 300 ++++++++++++++-
> ---
> >  .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h |   7 +-
> >  14 files changed, 563 insertions(+), 149 deletions(-)  create mode
> > 100644 drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
> >




From aakarsh.jain at samsung.com  Tue Dec 12 23:59:49 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:29:49 +0530
Subject: [Patch v5 09/11] media: s5p-mfc: Load firmware for each run in
 MFCv12.
In-Reply-To: <2c9b85dc-ebd7-43a7-bb66-d96ba9a28082@xs4all.nl>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
	<CGME20231206063134epcas5p2b3b9ca0351cd9c1cb169d7a4a3a30b80@epcas5p2.samsung.com>
	<20231206063045.97234-10-aakarsh.jain@samsung.com>
	<2c9b85dc-ebd7-43a7-bb66-d96ba9a28082@xs4all.nl>
Message-ID: <108e01da2d9a$5b177b50$114671f0$@samsung.com>



> -----Original Message-----
> From: Hans Verkuil <hverkuil-cisco at xs4all.nl>
> Sent: 06 December 2023 18:28
> To: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org; linux-
> kernel at vger.kernel.org; devicetree at vger.kernel.org
> Cc: m.szyprowski at samsung.com; andrzej.hajda at intel.com;
> mchehab at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> robh+dt at kernel.org; conor+dt at kernel.org; linux-samsung-
> soc at vger.kernel.org; andi at etezian.org; gost.dev at samsung.com;
> alim.akhtar at samsung.com; aswani.reddy at samsung.com;
> pankaj.dubey at samsung.com; ajaykumar.rs at samsung.com; linux-
> fsd at tesla.com; Smitha T Murthy <smithatmurthy at gmail.com>
> Subject: Re: [Patch v5 09/11] media: s5p-mfc: Load firmware for each run in
> MFCv12.
> 
> On 06/12/2023 07:30, Aakarsh Jain wrote:
> > In MFCv12, some section of firmware gets updated at each MFC run.
> > Hence we need to reload original firmware for each run at the start.
> >
> > Cc: linux-fsd at tesla.com
> > Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
> > Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
> > ---
> >  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> > b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> > index b49159142c53..24dd40ae71ec 100644
> > --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> > +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> > @@ -51,8 +51,10 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev
> *dev)
> >  	 * into kernel. */
> >  	mfc_debug_enter();
> >
> > -	if (dev->fw_get_done)
> > -		return 0;
> > +	/* Load MFC v12 firmware for each run when MFC runs sequentially
> */
> 
> You had a much longer explanation in your reply to my original question.
> 
> I think it is better if that longer explanation is added here.
> 
okay sure. Will add that explanation here.

> Things that are weird and unexpected need good comments, explaining why
> it is done, and also what you know and do not know about this.
> 
> E.g. you know through trial and error that it is needed (or perhaps you got
> information on this some the fw team), but there might be open questions
> that are not yet answered.
> 
> This is all information that you can't get from the source code since it has to
> do with the black box firmware. So putting all you know in a comment is the
> best way of communicating this to future readers of the source code.
> 

Thanks for the review!

> Regards,
> 
> 	Hans
> 
> > +	if (!IS_MFCV12(dev))
> > +		if (dev->fw_get_done)
> > +			return 0;
> >
> >  	for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
> >  		if (!dev->variant->fw_name[i])




From shawnguo at kernel.org  Wed Dec 13 00:07:48 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 13 Dec 2023 16:07:48 +0800
Subject: [PATCH] arm64: dts: ls1012a: Remove big-endian from thermal
In-Reply-To: <20230929185510.707475-1-festevam@gmail.com>
References: <20230929185510.707475-1-festevam@gmail.com>
Message-ID: <20231213080748.GG270430@dragon>

On Fri, Sep 29, 2023 at 03:55:10PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per qoriq-thermal.yaml, 'big-endian' is not a valid property.
> 
> When the 'little-endian' property is absent, the default is big endian.
> 
> Remove it to fix the following schema warning:
> 
> tmu at 1f00000: 'big-endian' does not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From jaewon02.kim at samsung.com  Wed Dec 13 00:10:38 2023
From: jaewon02.kim at samsung.com (Jaewon Kim)
Date: Wed, 13 Dec 2023 17:10:38 +0900
Subject: [PATCH v4 2/2] pinctrl: samsung: add exynosautov920 pinctrl
In-Reply-To: <68a36910-e528-45ff-8b59-e7cd95aaef0b@linaro.org>
References: <20231211114145.106255-1-jaewon02.kim@samsung.com>
	<CGME20231211114216epcas2p300bbf4c592d495991c6cc2d96e0b1f85@epcas2p3.samsung.com>
	<20231211114145.106255-3-jaewon02.kim@samsung.com>
	<68a36910-e528-45ff-8b59-e7cd95aaef0b@linaro.org>
Message-ID: <2b72464e-d60a-6adc-0ef7-ed92ff495859@samsung.com>


On 23. 12. 13. 16:52, Krzysztof Kozlowski wrote:
> On 11/12/2023 12:41, Jaewon Kim wrote:
>> Add pinctrl data for ExynosAutov920 SoC.
>> It has a newly applied pinctrl register layer for ExynosAuto series.
>>
>> Pinctrl data for ExynosAutoV920 SoC.
>>   - GPA0,GPA1 (10): External wake up interrupt
>>   - GPQ0 (2): SPMI (PMIC I/F)
>>   - GPB0,GPB1,GPB2,GPB3,GPB4,GPB5,GPB6 (47): I2S Audio
>>   - GPH0,GPH1,GPH2,GPH3,GPH4,GPH5,GPH6,GPH8 (49): PCIE, UFS, Ethernet
>>   - GPG0,GPG1,GPG2,GPG3,GPG4,GPG5 (29): General purpose
>>   - GPP0,GPP1,GPP2,GPP3,GPP4,GPP5,GPP6,GPP7,GPP8,GPP9,GPP10 (77): USI
>>
>> Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
>> ---
>>   .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 140 ++++++++++++++++++
>>   drivers/pinctrl/samsung/pinctrl-exynos.c      |  23 ++-
>>   drivers/pinctrl/samsung/pinctrl-exynos.h      |  25 ++++
>>   drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
>>   drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
>>   5 files changed, 190 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>> index cb965cf93705..a998c296dd05 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>> @@ -796,3 +796,143 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
>>   	.ctrl		= fsd_pin_ctrl,
>>   	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
>>   };
>> +
>> +/* pin banks of exynosautov920 pin-controller 0 (ALIVE) */
>> +static const struct samsung_pin_bank_data exynosautov920_pin_banks0[] = {
>> +	EXYNOSV920_PIN_BANK_EINTW(8, 0x0000, "gpa0", 0x18, 0x24, 0x28),
>> +	EXYNOSV920_PIN_BANK_EINTW(2, 0x1000, "gpa1", 0x18, 0x20, 0x24),
>> +	EXYNOS850_PIN_BANK_EINTN(2, 0x2000, "gpq0"),
>> +};e
> Applied with re-ordering it, to keep it after ExynosAutov9. For the
> future: don't add entries to the end of lists because it causes exactly
> this issue we have here: unnecessary conflicts. Please keep this rule
> for entire development, not only pinctrl.
>
> If both you and Peter were observing this basic rule, I would not have
> work of reshuffling and fixing conflicts.
>
> Please check the result if I reshuffled/solved conflicts correctly.
>

I thought the new SoC should go to the end, but I was wrong.

I will follow your comments in alphabetical order.

Thanks you sincerely.


Thanks

Jaewon Kim




From shawnguo at kernel.org  Wed Dec 13 00:12:23 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 13 Dec 2023 16:12:23 +0800
Subject: [PATCH v2 2/2] arm64: dts: freescale: imx93: add i3c1 and i3c2
In-Reply-To: <20231017194657.3199749-2-Frank.Li@nxp.com>
References: <20231017194657.3199749-1-Frank.Li@nxp.com>
 <20231017194657.3199749-2-Frank.Li@nxp.com>
Message-ID: <20231213081223.GH270430@dragon>

On Tue, Oct 17, 2023 at 03:46:57PM -0400, Frank Li wrote:
> Add I3C1 and I3C2.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>

Applied, thanks!


From krzysztof.kozlowski at linaro.org  Wed Dec 13 00:14:58 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 09:14:58 +0100
Subject: [PATCH v4 2/2] pinctrl: samsung: add exynosautov920 pinctrl
In-Reply-To: <2b72464e-d60a-6adc-0ef7-ed92ff495859@samsung.com>
References: <20231211114145.106255-1-jaewon02.kim@samsung.com>
 <CGME20231211114216epcas2p300bbf4c592d495991c6cc2d96e0b1f85@epcas2p3.samsung.com>
 <20231211114145.106255-3-jaewon02.kim@samsung.com>
 <68a36910-e528-45ff-8b59-e7cd95aaef0b@linaro.org>
 <2b72464e-d60a-6adc-0ef7-ed92ff495859@samsung.com>
Message-ID: <a26032ca-1a05-43a9-b6e6-7240193db79c@linaro.org>

On 13/12/2023 09:10, Jaewon Kim wrote:
> 
> On 23. 12. 13. 16:52, Krzysztof Kozlowski wrote:
>> On 11/12/2023 12:41, Jaewon Kim wrote:
>>> Add pinctrl data for ExynosAutov920 SoC.
>>> It has a newly applied pinctrl register layer for ExynosAuto series.
>>>
>>> Pinctrl data for ExynosAutoV920 SoC.
>>>   - GPA0,GPA1 (10): External wake up interrupt
>>>   - GPQ0 (2): SPMI (PMIC I/F)
>>>   - GPB0,GPB1,GPB2,GPB3,GPB4,GPB5,GPB6 (47): I2S Audio
>>>   - GPH0,GPH1,GPH2,GPH3,GPH4,GPH5,GPH6,GPH8 (49): PCIE, UFS, Ethernet
>>>   - GPG0,GPG1,GPG2,GPG3,GPG4,GPG5 (29): General purpose
>>>   - GPP0,GPP1,GPP2,GPP3,GPP4,GPP5,GPP6,GPP7,GPP8,GPP9,GPP10 (77): USI
>>>
>>> Signed-off-by: Jaewon Kim <jaewon02.kim at samsung.com>
>>> ---
>>>   .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 140 ++++++++++++++++++
>>>   drivers/pinctrl/samsung/pinctrl-exynos.c      |  23 ++-
>>>   drivers/pinctrl/samsung/pinctrl-exynos.h      |  25 ++++
>>>   drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
>>>   drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
>>>   5 files changed, 190 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>>> index cb965cf93705..a998c296dd05 100644
>>> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
>>> @@ -796,3 +796,143 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
>>>   	.ctrl		= fsd_pin_ctrl,
>>>   	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
>>>   };
>>> +
>>> +/* pin banks of exynosautov920 pin-controller 0 (ALIVE) */
>>> +static const struct samsung_pin_bank_data exynosautov920_pin_banks0[] = {
>>> +	EXYNOSV920_PIN_BANK_EINTW(8, 0x0000, "gpa0", 0x18, 0x24, 0x28),
>>> +	EXYNOSV920_PIN_BANK_EINTW(2, 0x1000, "gpa1", 0x18, 0x20, 0x24),
>>> +	EXYNOS850_PIN_BANK_EINTN(2, 0x2000, "gpq0"),
>>> +};e
>> Applied with re-ordering it, to keep it after ExynosAutov9. For the
>> future: don't add entries to the end of lists because it causes exactly
>> this issue we have here: unnecessary conflicts. Please keep this rule
>> for entire development, not only pinctrl.
>>
>> If both you and Peter were observing this basic rule, I would not have
>> work of reshuffling and fixing conflicts.
>>
>> Please check the result if I reshuffled/solved conflicts correctly.
>>
> 
> I thought the new SoC should go to the end, but I was wrong.
> 

Peter's Google's structures went to the end, which was actually
alphabetical. You also added to the end thus git could not apply the
patch. Even cherry-pick had troubles, so I need to manually copy code
from downloaded patch. That's the main reason of not putting stuff to
the end, but to some logical place, usually alphabetical.

Best regards,
Krzysztof



From s-vadapalli at ti.com  Wed Dec 13 00:16:28 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Wed, 13 Dec 2023 13:46:28 +0530
Subject: [PATCH] arm64: dts: ti: k3-am654-icssg2: Enable PHY interrupts
 for ICSSG2
In-Reply-To: <20231204132103.ikkxjz3yxz3ynq6s@demystify>
References: <20231120063159.539306-1-s-vadapalli@ti.com>
 <20231204132103.ikkxjz3yxz3ynq6s@demystify>
Message-ID: <89ed9033-7fbd-4a48-9a83-0a0b3b208e3d@ti.com>

Hello Nishanth,

Thank you for reviewing the patch. I have addressed your feedback in the v2
patch at:
https://lore.kernel.org/r/20231213080216.1710730-1-s-vadapalli at ti.com/

On 04/12/23 18:51, Nishanth Menon wrote:
> On 12:01-20231120, Siddharth Vadapalli wrote:
>> Enable interrupt mode of operation of the DP83867 Ethernet PHY which is
>> used by ICSSG2. The DP83867 PHY driver already supports interrupt handling
>> for interrupts generated by the PHY. Thus, add the necessary device-tree
>> support to enable it.
>>
>> Since the GPIO1_87 line is muxed with EXT_REFCLK1 and SYNC1_OUT, update
>> the pinmux to select GPIO1_87 for routing the interrupt.
>>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
>> ---
>>
>> This patch is based on linux-next tagged next-20231120.
>>
>> Regards,
>> Siddharth.
>>
>>  arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso | 17 +++++++++++++++--
>>  1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
>> index ec8cf20ca3ac..9f723592d0f4 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
>> +++ b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
>> @@ -124,21 +124,34 @@ AM65X_IOPAD(0x0088, PIN_INPUT, 2) /* (AG17) PRG2_PRU0_GPO4.PRG2_RGMII1_RX_CTL */
>>  	};
>>  };
>>  
>> +&main_pmx1 {
>> +	/* Select GPIO1_87 for ICSSG2 PHY interrupt */
>> +	icssg2_phy_irq_pins_default: icssg2-phy-irq-default-pins {
>> +		pinctrl-single,pins = <
>> +			AM65X_IOPAD(0x0014, PIN_INPUT, 7) /* (A22) EXT_REFCLK1.GPIO1_87 */
>> +		>;
>> +	};
>> +};
>> +
>>  &icssg2_mdio {
>>  	status = "okay";
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&icssg2_mdio_pins_default>;
>> +	pinctrl-names = "default", "icssg2-phy-irq";
>> +	pinctrl-0 = <&icssg2_mdio_pins_default>, <&icssg2_phy_irq_pins_default>;
> 
> why should the pins be part of mdio pinctrl instead of phy?
> 
>>  	#address-cells = <1>;
>>  	#size-cells = <0>;
>>  
>>  	icssg2_phy0: ethernet-phy at 0 {
>>  		reg = <0>;
>> +		interrupt-parent = <&main_gpio1>;
>> +		interrupts = <87 0x2>;
>>  		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>>  		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
>>  	};
>>  
>>  	icssg2_phy1: ethernet-phy at 3 {
>>  		reg = <3>;
>> +		interrupt-parent = <&main_gpio1>;
>> +		interrupts = <87 0x2>;
> 
> Shouldn't you be using macros for interrupt level like IRQ_TYPE_EDGE_FALLING?
> 
>>  		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>>  		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
>>  	};
>> -- 
>> 2.34.1
>>
> 

-- 
Regards,
Siddharth.


From linus.walleij at linaro.org  Wed Dec 13 00:26:19 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 13 Dec 2023 09:26:19 +0100
Subject: [PATCH linux-next] ARM/dma-mapping: replace kzalloc() and
 vzalloc() with kvzalloc()
In-Reply-To: <202312121120348064534@zte.com.cn>
References: <202312121120348064534@zte.com.cn>
Message-ID: <CACRpkdap4LUbMcKv_zi=25A-SZf0DJhXiyR1zn0PfuR+b=3NfA@mail.gmail.com>

On Tue, Dec 12, 2023 at 4:20?AM <yang.guang5 at zte.com.cn> wrote:

> From: Yang Guang <yang.guang5 at zte.com.cn>
> using kvzalloc() simplifies the code by avoiding the
> use of different memory allocation functions for different
> situations, making the code more uniform and readable.
>
> Signed-off-by: Chen Haonan <chen.haonan2 at zte.com.cn>

Looks good to me:
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Please put this patch into Russell's patch tracker.

Yours,
Linus Walleij


From ashimida.1990 at gmail.com  Wed Dec 13 00:28:41 2023
From: ashimida.1990 at gmail.com (Dan Li)
Date: Wed, 13 Dec 2023 16:28:41 +0800
Subject: [RFC/RFT] CFI: Add support for gcc CFI in aarch64
In-Reply-To: <20221219061758.23321-1-ashimida.1990@gmail.com>
References: <20221219061758.23321-1-ashimida.1990@gmail.com>
Message-ID: <CAE+Z0PGx02FuQt3J8qzckH-YDbRpMyESCJgM1tRZu6xAS_JciA@mail.gmail.com>

Hi all,

I am happy to introduce to you that I have contacted a colleague Likun Wang, who
 is willing to continue completing this patch.
This patch has been delayed for a long time. I hope that gcc will
support this feature
in the near future.

Thanks.
Dan.

On Mon, 19 Dec 2022 at 14:18, Dan Li <ashimida.1990 at gmail.com> wrote:
>
> Based on Sami's patch[1], this patch makes the corresponding kernel
> configuration of CFI available when compiling the kernel with the gcc[2].
>
> The code after enabling cfi is as follows:
>
> int (*p)(void);
> int func (int)
> {
>         p();
> }
>
> __cfi_func:
>         .4byte 0x439d3502
> func:
>         ......
>         adrp    x0, p
>         add     x0, x0, :lo12:p
>         mov     w1, 23592
>         movk    w1, 0x4601, lsl 16
>         cmp     w0, w1
>         beq     .L2
>         ......
>         bl      cfi_check_failed
> .L2:
>         blr     x19
>         ret
>
> In the compiler part[4], there are some differences from Sami's
> implementation[3], mainly including:
>
> 1. When a typeid mismatch is detected, the cfi_check_failed function
>    will be called instead of the brk instruction. This function needs
>    to be implemented by the compiler user.
>    If there are user mode programs or other systems that want to use
>    this feature, it may be more convenient to use a callback (so this
>    compilation option is set to -fsanitize=cfi instead of kcfi).
>
> 2. A reserved typeid (such as 0x0U on the aarch64 platform) is always
>    inserted in front of functions that should not be called indirectly.
>    Functions that can be called indirectly will not use this hash value,
>    which prevents instructions/data before the function from being used
>    as a typeid by an attacker.
>
> 3. Some bits are ignored in the typeid to avoid conflicts between the
>    typeid and the instruction set of a specific platform, thereby
>    preventing an attacker from bypassing the CFI check by using the
>    instruction as a typeid, such as on the aarch64 platform:
>    * If the following instruction sequence exists:
>           400620:       a9be7bfd        stp     x29, x30, [sp, #-32]!
>           400624:       910003fd        mov     x29, sp
>           400628:       f9000bf3        str     x19, [sp, #16]
>    * If the expected typeid of the indirect call is exactly 0x910003fd,
>      the attacker can jump to the next instruction position of any
>      "mov x29,sp" instruction (such as 0x400628 here).
>
> 4. Insert a symbol __cfi_<function> before each function's typeid,
>    which may be helpful for fine-grained KASLR implementations (or not?).
>
> 5. The current implementation of gcc only supports the aarch64 platform.
>
> This produces the following oops on CFI failure (generated using lkdtm):
>
> /kselftest_install/lkdtm # ./CFI_FORWARD_PROTO.sh
> [   74.856516] lkdtm: Performing direct entry CFI_FORWARD_PROTO
> [   74.856878] lkdtm: Calling matched prototype ...
> [   74.857011] lkdtm: Calling mismatched prototype ...
> [   74.857133] CFI failure at lkdtm_indirect_call+0x30/0x50 (target: lkdtm_increment_int+0x0/0x1c; expected type: 0xc59c68f1)
> [   74.858185] Kernel panic - not syncing: Oops - CFI
> [   74.859240] CPU: 0 PID: 129 Comm: cat Not tainted 6.0.0-rc4-00024-g32bf7f14f497-dirty #150
> [   74.859481] Hardware name: linux,dummy-virt (DT)
> [   74.859795] Call trace:
> [   74.859959]  dump_backtrace.part.0+0xcc/0xe0
> [   74.860212]  show_stack+0x18/0x5c
> [   74.860327]  dump_stack_lvl+0x64/0x84
> [   74.860398]  dump_stack+0x18/0x38
> [   74.860443]  panic+0x170/0x36c
> [   74.860496]  cfi_check_failed+0x38/0x44
> [   74.860564]  lkdtm_indirect_call+0x30/0x50
> [   74.860614]  lkdtm_CFI_FORWARD_PROTO+0x3c/0x6c
> [   74.860701]  lkdtm_do_action+0x44/0x58
> [   74.860764]  direct_entry+0x148/0x160
> [   74.860814]  full_proxy_write+0x74/0xe0
> [   74.860874]  vfs_write+0xd8/0x2d0
> [   74.860942]  ksys_write+0x70/0x110
> [   74.861000]  __arm64_sys_write+0x1c/0x30
> [   74.861067]  invoke_syscall+0x5c/0x140
> [   74.861117]  el0_svc_common.constprop.0+0x44/0xf0
> [   74.861190]  do_el0_svc+0x2c/0xc0
> [   74.861233]  el0_svc+0x20/0x60
> [   74.861287]  el0t_64_sync_handler+0xf4/0x124
> [   74.861340]  el0t_64_sync+0x160/0x164
> [   74.861782] SMP: stopping secondary CPUs
> [   74.862336] Kernel Offset: disabled
> [   74.862439] CPU features: 0x0000,00075024,699418af
> [   74.862799] Memory Limit: none
> [   74.863373] ---[ end Kernel panic - not syncing: Oops - CFI ]---
>
> The gcc-related patches[4] are based on tag: releases/gcc-12.2.0.
>
> Any suggestion please let me know :).
>
> Thanks, Dan.
>
> [1] https://lore.kernel.org/all/20220908215504.3686827-1-samitolvanen at google.com/
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107048
> [3] https://reviews.llvm.org/D119296
> [4] https://lore.kernel.org/linux-hardening/20221219055431.22596-1-ashimida.1990 at gmail.com/
>
> Signed-off-by: Dan Li <ashimida.1990 at gmail.com>
> ---
>  Makefile                     |  6 ++++++
>  arch/Kconfig                 | 24 +++++++++++++++++++++++-
>  arch/arm64/Kconfig           |  1 +
>  include/linux/cfi_types.h    | 15 +++++++++++----
>  include/linux/compiler-gcc.h |  4 ++++
>  kernel/Makefile              |  1 +
>  kernel/cfi.c                 | 23 +++++++++++++++++++++++
>  scripts/kallsyms.c           |  4 +++-
>  8 files changed, 72 insertions(+), 6 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 43e08c9f95e9..7c74dac57aa4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -926,6 +926,12 @@ KBUILD_CFLAGS      += $(CC_FLAGS_CFI)
>  export CC_FLAGS_CFI
>  endif
>
> +ifdef CONFIG_CFI_GCC
> +CC_FLAGS_CFI   := -fsanitize=cfi
> +KBUILD_CFLAGS  += $(CC_FLAGS_CFI)
> +export CC_FLAGS_CFI
> +endif
> +
>  ifdef CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B
>  KBUILD_CFLAGS += -falign-functions=64
>  endif
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 1c1eca0c0019..8b43a9fd3b54 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -756,9 +756,31 @@ config CFI_CLANG
>
>             https://clang.llvm.org/docs/ControlFlowIntegrity.html
>
> +config ARCH_SUPPORTS_CFI_GCC
> +       bool
> +       help
> +         An architecture should select this option if it can support GCC's
> +         Control-Flow Integrity (CFI) checking.
> +
> +config CFI_GCC
> +       bool "Use GCC's Control Flow Integrity (CFI)"
> +       depends on ARCH_SUPPORTS_CFI_GCC
> +       depends on $(cc-option,-fsanitize=cfi)
> +       help
> +         This option enables GCC?s forward-edge Control Flow Integrity
> +         (CFI) checking, where the compiler injects a runtime check to each
> +         indirect function call to ensure the target is a valid function with
> +         the correct static type. This restricts possible call targets and
> +         makes it more difficult for an attacker to exploit bugs that allow
> +         the modification of stored function pointers. More information can be
> +         found from the compiler's documentation:
> +
> +         - Clang: https://clang.llvm.org/docs/ControlFlowIntegrity.html
> +         - GCC: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#Instrumentation-Options
> +
>  config CFI_PERMISSIVE
>         bool "Use CFI in permissive mode"
> -       depends on CFI_CLANG
> +       depends on CFI_CLANG || CFI_GCC
>         help
>           When selected, Control Flow Integrity (CFI) violations result in a
>           warning instead of a kernel panic. This option should only be used
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9fb9fff08c94..60fdfb01cecb 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -89,6 +89,7 @@ config ARM64
>         select ARCH_SUPPORTS_LTO_CLANG if CPU_LITTLE_ENDIAN
>         select ARCH_SUPPORTS_LTO_CLANG_THIN
>         select ARCH_SUPPORTS_CFI_CLANG
> +       select ARCH_SUPPORTS_CFI_GCC
>         select ARCH_SUPPORTS_ATOMIC_RMW
>         select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
>         select ARCH_SUPPORTS_NUMA_BALANCING
> diff --git a/include/linux/cfi_types.h b/include/linux/cfi_types.h
> index 6b8713675765..1c3b7ea6a79f 100644
> --- a/include/linux/cfi_types.h
> +++ b/include/linux/cfi_types.h
> @@ -8,18 +8,25 @@
>  #ifdef __ASSEMBLY__
>  #include <linux/linkage.h>
>
> -#ifdef CONFIG_CFI_CLANG
> +#if defined(CONFIG_CFI_CLANG) || defined(CONFIG_CFI_GCC)
>  /*
> - * Use the __kcfi_typeid_<function> type identifier symbol to
> + * Use the __[k]cfi_typeid_<function> type identifier symbol to
>   * annotate indirectly called assembly functions. The compiler emits
>   * these symbols for all address-taken function declarations in C
>   * code.
>   */
>  #ifndef __CFI_TYPE
> +
> +#ifdef CONFIG_CFI_GCC
> +#define __CFI_TYPE(name)                               \
> +       .4byte __cfi_typeid_##name
> +#else
>  #define __CFI_TYPE(name)                               \
>         .4byte __kcfi_typeid_##name
>  #endif
>
> +#endif
> +
>  #define SYM_TYPED_ENTRY(name, linkage, align...)       \
>         linkage(name) ASM_NL                            \
>         align ASM_NL                                    \
> @@ -29,12 +36,12 @@
>  #define SYM_TYPED_START(name, linkage, align...)       \
>         SYM_TYPED_ENTRY(name, linkage, align)
>
> -#else /* CONFIG_CFI_CLANG */
> +#else /* defined(CONFIG_CFI_CLANG) || defined(CONFIG_CFI_GCC) */
>
>  #define SYM_TYPED_START(name, linkage, align...)       \
>         SYM_START(name, linkage, align)
>
> -#endif /* CONFIG_CFI_CLANG */
> +#endif /* defined(CONFIG_CFI_CLANG) || defined(CONFIG_CFI_GCC) */
>
>  #ifndef SYM_TYPED_FUNC_START
>  #define SYM_TYPED_FUNC_START(name)                     \
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 9b157b71036f..aec1ce327b1a 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -82,6 +82,10 @@
>  #define __noscs __attribute__((__no_sanitize__("shadow-call-stack")))
>  #endif
>
> +#ifdef CONFIG_CFI_GCC
> +#define __nocfi __attribute__((no_sanitize("cfi")))
> +#endif
> +
>  #if __has_attribute(__no_sanitize_address__)
>  #define __no_sanitize_address __attribute__((no_sanitize_address))
>  #else
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 318789c728d3..923d3e060852 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -114,6 +114,7 @@ obj-$(CONFIG_SHADOW_CALL_STACK) += scs.o
>  obj-$(CONFIG_HAVE_STATIC_CALL) += static_call.o
>  obj-$(CONFIG_HAVE_STATIC_CALL_INLINE) += static_call_inline.o
>  obj-$(CONFIG_CFI_CLANG) += cfi.o
> +obj-$(CONFIG_CFI_GCC) += cfi.o
>
>  obj-$(CONFIG_PERF_EVENTS) += events/
>
> diff --git a/kernel/cfi.c b/kernel/cfi.c
> index 08caad776717..9bff35736756 100644
> --- a/kernel/cfi.c
> +++ b/kernel/cfi.c
> @@ -25,6 +25,7 @@ enum bug_trap_type report_cfi_failure(struct pt_regs *regs, unsigned long addr,
>         return BUG_TRAP_TYPE_BUG;
>  }
>
> +#ifdef CONFIG_CFI_CLANG
>  #ifdef CONFIG_ARCH_USES_CFI_TRAPS
>  static inline unsigned long trap_address(s32 *p)
>  {
> @@ -99,3 +100,25 @@ bool is_cfi_trap(unsigned long addr)
>         return is_module_cfi_trap(addr);
>  }
>  #endif /* CONFIG_ARCH_USES_CFI_TRAPS */
> +#endif /* CONFIG_CFI_CLANG */
> +
> +
> +#ifdef CONFIG_CFI_GCC
> +void cfi_check_failed(u32 caller_hash, u32 callee_hash, void *callee_addr)
> +{
> +       unsigned long pc, target;
> +
> +       pc = (unsigned long)__builtin_return_address(0);
> +       target = (unsigned long)callee_addr;
> +
> +       switch (report_cfi_failure(NULL, pc, &target, caller_hash)) {
> +       case BUG_TRAP_TYPE_WARN:
> +               break;
> +
> +       default:
> +               panic("Oops - CFI");
> +       }
> +}
> +EXPORT_SYMBOL(cfi_check_failed);
> +
> +#endif /* CONFIG_CFI_GCC */
> diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> index ccdf0c897f31..ed8db513b918 100644
> --- a/scripts/kallsyms.c
> +++ b/scripts/kallsyms.c
> @@ -119,7 +119,9 @@ static bool is_ignored_symbol(const char *name, char type)
>                 "__ThumbV7PILongThunk_",
>                 "__LA25Thunk_",         /* mips lld */
>                 "__microLA25Thunk_",
> -               "__kcfi_typeid_",       /* CFI type identifiers */
> +               "__kcfi_typeid_",       /* CFI type identifiers in Clang */
> +               "__cfi_",               /* CFI type identifiers in GCC */
> +               "__pi___cfi",           /* CFI type identifiers in GCC */
>                 NULL
>         };
>
> --
> 2.17.1
>


From mripard at kernel.org  Wed Dec 13 00:36:49 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Wed, 13 Dec 2023 09:36:49 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
Message-ID: <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>

Hi,

On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> > > clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> > > that and don't check the return value. This series fixes the four users
> > > that do error checking on the returned value and then makes function
> > > return void.
> > > 
> > > Given that the changes to the drivers are simple and so merge conflicts
> > > (if any) should be easy to handle, I suggest to merge this complete
> > > series via the clk tree.
> > 
> > I don't think it's the right way to go about it.
> > 
> > clk_rate_exclusive_get() should be expected to fail. For example if
> > there's another user getting an exclusive rate on the same clock.
> > 
> > If we're not checking for it right now, then it should probably be
> > fixed, but the callers checking for the error are right to do so if they
> > rely on an exclusive rate. It's the ones that don't that should be
> > modified.
> 
> If some other consumer has already "locked" a clock that I call
> clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
> this function because I don't want the rate to change e.g. because I
> setup some registers in the consuming device to provide a fixed UART
> baud rate or i2c bus frequency (and that works as expected).

I guess it's a larger conversation, but I don't see how that can
possibly work.

The way the API is designed, you have no guarantee (outside of
clk_rate_exclusive_*) that the rate is going to change.

And clk_rate_exclusive_get() doesn't allow the rate to change while in
the "critical section".

So the only possible thing to do is clk_set_rate() +
clk_rate_exclusive_get().

So there's a window where the clock can indeed be changed, and the
consumer that is about to lock its rate wouldn't be aware of it.

I guess it would work if you don't care about the rate at all, you just
want to make sure it doesn't change.

Out of the 7 users of that function, 3 are in that situation, so I guess
it's fair.

3 are open to that race condition I mentioned above.

1 is calling clk_set_rate while in the critical section, which works if
there's a single user but not if there's multiple, so it should be
discouraged.

> In this case I won't be able to change the rate of the clock, but that
> is signalled by clk_set_rate() failing (iff and when I need awother
> rate) which also seems the right place to fail to me.

Which is ignored by like half the callers, including the one odd case I
mentioned above.

And that's super confusing still: you can *always* get exclusivity, but
not always do whatever you want with the rate when you have it? How are
drivers supposed to recover from that? You can handle failing to get
exclusivity, but certainly not working around variable guarantees.

> It's like that since clk_rate_exclusive_get() was introduced in 2017
> (commit 55e9b8b7b806ec3f9a8817e13596682a5981c19c).

Right, but "it's always been that way" surely can't be an argument,
otherwise you wouldn't have done that series in the first place.

> BTW, I just noticed that my assertion "Most users \"know\" that
> [clk_rate_exclusive_get() returns zero unconditionally]" is wrong. As of
> next-20231213 there are 3 callers ignoring the return value of
> clk_rate_exclusive_get() and 4 that handle (imaginary) returned errors.
> I expected this function to be used more extensively. (In fact I think
> it should be used more as several drivers rely on the clk rate not
> changing.)

Yes, but also it's super difficult to use in practice, and most devices
don't care.

The current situation is something like this:

  * Only a handful of devices really care about their clock rate, and
    often only for one of their clock if they have several. You would
    probably get all the devices that create an analog signal somehow
    there, so audio, display, i2c, spi, uarts, etc. Plus the ones doing
    frequency scaling so CPU and GPUs.

  * CPUs and GPUs are very likely to have a dedicated clock, so we can
    rule the "another user is going to mess with my clock" case.

  * UARTs/i2c/etc. are usually taking their clock from the bus interface
    directly which is pretty much never going to change (for good
    reason). And the rate of the bus is not really likely to change.

  * SPI/NAND/MMC usually have their dedicated clock too, and the bus
    rate is not likely to change after the initial setup either.

So, the only affected devices are the ones generating external signals,
with the rate changing during the life of the system. Even for audio or
video devices, that's fairly unlikely to happen. And you need to have
multiple devices sharing the same clock tree for that issue to occur,
which is further reducing the chances it happens.

Realistically speaking, this only occurs with multi-head display outputs
where it's somewhat likely to have all the display controllers feeding
from the same clock, and the power up of the various output is done in
sequence which creates that situation.

And even then, the clk_rate_exclusive_* interface effectively locks the
entire clock subtree to its current rate, so the effect on the rest of
the devices can be significant.

So... yeah. Even though you're right, it's trying to address a problem
that is super unlikely to happen with a pretty big hammer that might be
too much for most. So it's not really surprising it's not used more.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/5af3990e/attachment.sig>

From ardb at google.com  Wed Dec 13 00:40:26 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Wed, 13 Dec 2023 09:40:26 +0100
Subject: [PATCH v7 1/7] arm64: mm: Move PCI I/O emulation region above the
 vmemmap region
In-Reply-To: <20231213084024.2367360-9-ardb@google.com>
References: <20231213084024.2367360-9-ardb@google.com>
Message-ID: <20231213084024.2367360-10-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

Move the PCI I/O region above the vmemmap region in the kernel's VA
space. This will permit us to reclaim the lower part of the vmemmap
region for vmalloc/vmap allocations when running a 52-bit VA capable
build on a 48-bit VA capable system.

Also, given that PCI_IO_START is derived from VMEMMAP_END, use that
symbolic constant directly in ptdump rather than deriving it from
VMEMMAP_START and VMEMMAP_SIZE, as those definitions will change in
subsequent patches.

Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
---
 arch/arm64/include/asm/memory.h | 4 ++--
 arch/arm64/mm/ptdump.c          | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b8d726f951ae..99caeff78e1a 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -49,8 +49,8 @@
 #define MODULES_VSIZE		(SZ_2G)
 #define VMEMMAP_START		(-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
 #define VMEMMAP_END		(VMEMMAP_START + VMEMMAP_SIZE)
-#define PCI_IO_END		(VMEMMAP_START - SZ_8M)
-#define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
+#define PCI_IO_START		(VMEMMAP_END + SZ_8M)
+#define PCI_IO_END		(PCI_IO_START + PCI_IO_SIZE)
 #define FIXADDR_TOP		(VMEMMAP_START - SZ_32M)
 
 #if VA_BITS > 48
diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index e305b6593c4e..46acb2a24da0 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -47,10 +47,10 @@ static struct addr_marker address_markers[] = {
 	{ VMALLOC_END,			"vmalloc() end" },
 	{ FIXADDR_TOT_START,		"Fixmap start" },
 	{ FIXADDR_TOP,			"Fixmap end" },
+	{ VMEMMAP_START,		"vmemmap start" },
+	{ VMEMMAP_END,			"vmemmap end" },
 	{ PCI_IO_START,			"PCI I/O start" },
 	{ PCI_IO_END,			"PCI I/O end" },
-	{ VMEMMAP_START,		"vmemmap start" },
-	{ VMEMMAP_START + VMEMMAP_SIZE,	"vmemmap end" },
 	{ -1,				NULL },
 };
 
-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Wed Dec 13 00:40:25 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Wed, 13 Dec 2023 09:40:25 +0100
Subject: [PATCH v7 0/7] arm64: Reorganize kernel VA space
Message-ID: <20231213084024.2367360-9-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

These seven patches were taken from [0] and tweaked to address the
feedback by Mark Rutland. They reconfigure the upper region of the
kernel VA space so that the vmemmap region can be resized dynamically
on 52-bit builds running on 48-bit-only hardware. This is needed for
LPA2 support.

They can be applied onto the arm62 lpa2-prep branch.

[0] https://lore.kernel.org/all/20231129111555.3594833-43-ardb at google.com

v7:
- add static assert to avoid the fixmap overlapping with the PCI I/O
  region
- avoid deriving VMEMMAP_END from VMEMMAP_START+VMEMMAP_SIZE in ptdump.c
- add ack from Mark

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Mark Rutland <mark.rutland at arm.com>

Ard Biesheuvel (7):
  arm64: mm: Move PCI I/O emulation region above the vmemmap region
  arm64: mm: Move fixmap region above vmemmap region
  arm64: ptdump: Allow all region boundaries to be defined at boot time
  arm64: ptdump: Discover start of vmemmap region at runtime
  arm64: vmemmap: Avoid base2 order of struct page size to dimension
    region
  arm64: mm: Reclaim unused vmemmap region for vmalloc use
  arm64: kaslr: Adjust randomization range dynamically

 arch/arm64/include/asm/memory.h    | 14 ++---
 arch/arm64/include/asm/pgtable.h   | 10 ++--
 arch/arm64/kernel/image-vars.h     |  2 +
 arch/arm64/kernel/pi/kaslr_early.c | 11 ++--
 arch/arm64/mm/fixmap.c             |  3 ++
 arch/arm64/mm/ptdump.c             | 56 +++++++++-----------
 6 files changed, 49 insertions(+), 47 deletions(-)

-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Wed Dec 13 00:40:27 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Wed, 13 Dec 2023 09:40:27 +0100
Subject: [PATCH v7 2/7] arm64: mm: Move fixmap region above vmemmap region
In-Reply-To: <20231213084024.2367360-9-ardb@google.com>
References: <20231213084024.2367360-9-ardb@google.com>
Message-ID: <20231213084024.2367360-11-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

Move the fixmap region above the vmemmap region, so that the start of
the vmemmap delineates the end of the region available for vmalloc and
vmap allocations and the randomized placement of the kernel and modules.

In a subsequent patch, we will take advantage of this to reclaim most of
the vmemmap area when running a 52-bit VA capable build with 52-bit
virtual addressing disabled at runtime.

Note that the existing guard region of 256 MiB covers the fixmap and PCI
I/O regions as well, so we can reduce it 8 MiB, which is what we use in
other places too.

Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
---
 arch/arm64/include/asm/memory.h  | 2 +-
 arch/arm64/include/asm/pgtable.h | 2 +-
 arch/arm64/mm/fixmap.c           | 3 +++
 arch/arm64/mm/ptdump.c           | 4 ++--
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 99caeff78e1a..2745bed8ae5b 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -51,7 +51,7 @@
 #define VMEMMAP_END		(VMEMMAP_START + VMEMMAP_SIZE)
 #define PCI_IO_START		(VMEMMAP_END + SZ_8M)
 #define PCI_IO_END		(PCI_IO_START + PCI_IO_SIZE)
-#define FIXADDR_TOP		(VMEMMAP_START - SZ_32M)
+#define FIXADDR_TOP		(-UL(SZ_8M))
 
 #if VA_BITS > 48
 #define VA_BITS_MIN		(48)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b19a8aee684c..8d30e2787b1f 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -22,7 +22,7 @@
  *	and fixed mappings
  */
 #define VMALLOC_START		(MODULES_END)
-#define VMALLOC_END		(VMEMMAP_START - SZ_256M)
+#define VMALLOC_END		(VMEMMAP_START - SZ_8M)
 
 #define vmemmap			((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
 
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index c0a3301203bd..6fc17b2e1714 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -16,6 +16,9 @@
 #include <asm/pgalloc.h>
 #include <asm/tlbflush.h>
 
+/* ensure that the fixmap region does not grow down into the PCI I/O region */
+static_assert(FIXADDR_TOT_START > PCI_IO_END);
+
 #define NR_BM_PTE_TABLES \
 	SPAN_NR_ENTRIES(FIXADDR_TOT_START, FIXADDR_TOP, PMD_SHIFT)
 #define NR_BM_PMD_TABLES \
diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index 46acb2a24da0..a929b5a321db 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -45,12 +45,12 @@ static struct addr_marker address_markers[] = {
 	{ MODULES_END,			"Modules end" },
 	{ VMALLOC_START,		"vmalloc() area" },
 	{ VMALLOC_END,			"vmalloc() end" },
-	{ FIXADDR_TOT_START,		"Fixmap start" },
-	{ FIXADDR_TOP,			"Fixmap end" },
 	{ VMEMMAP_START,		"vmemmap start" },
 	{ VMEMMAP_END,			"vmemmap end" },
 	{ PCI_IO_START,			"PCI I/O start" },
 	{ PCI_IO_END,			"PCI I/O end" },
+	{ FIXADDR_TOT_START,		"Fixmap start" },
+	{ FIXADDR_TOP,			"Fixmap end" },
 	{ -1,				NULL },
 };
 
-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Wed Dec 13 00:40:28 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Wed, 13 Dec 2023 09:40:28 +0100
Subject: [PATCH v7 3/7] arm64: ptdump: Allow all region boundaries to be
 defined at boot time
In-Reply-To: <20231213084024.2367360-9-ardb@google.com>
References: <20231213084024.2367360-9-ardb@google.com>
Message-ID: <20231213084024.2367360-12-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

Rework the way the address_markers array is populated so that we can
tolerate values that are not compile time constants generally, rather
than keeping track manually of the array indexes in question, and poking
new values into them manually. This will be needed for VMALLOC_END,
which will cease to be a compile time constant after a subsequent patch.

Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
---
 arch/arm64/mm/ptdump.c | 54 ++++++++------------
 1 file changed, 22 insertions(+), 32 deletions(-)

diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index a929b5a321db..66ccb8d6997e 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -26,34 +26,6 @@
 #include <asm/ptdump.h>
 
 
-enum address_markers_idx {
-	PAGE_OFFSET_NR = 0,
-	PAGE_END_NR,
-#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
-	KASAN_START_NR,
-#endif
-};
-
-static struct addr_marker address_markers[] = {
-	{ PAGE_OFFSET,			"Linear Mapping start" },
-	{ 0 /* PAGE_END */,		"Linear Mapping end" },
-#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
-	{ 0 /* KASAN_SHADOW_START */,	"Kasan shadow start" },
-	{ KASAN_SHADOW_END,		"Kasan shadow end" },
-#endif
-	{ MODULES_VADDR,		"Modules start" },
-	{ MODULES_END,			"Modules end" },
-	{ VMALLOC_START,		"vmalloc() area" },
-	{ VMALLOC_END,			"vmalloc() end" },
-	{ VMEMMAP_START,		"vmemmap start" },
-	{ VMEMMAP_END,			"vmemmap end" },
-	{ PCI_IO_START,			"PCI I/O start" },
-	{ PCI_IO_END,			"PCI I/O end" },
-	{ FIXADDR_TOT_START,		"Fixmap start" },
-	{ FIXADDR_TOP,			"Fixmap end" },
-	{ -1,				NULL },
-};
-
 #define pt_dump_seq_printf(m, fmt, args...)	\
 ({						\
 	if (m)					\
@@ -339,9 +311,8 @@ static void __init ptdump_initialize(void)
 				pg_level[i].mask |= pg_level[i].bits[j].mask;
 }
 
-static struct ptdump_info kernel_ptdump_info = {
+static struct ptdump_info kernel_ptdump_info __ro_after_init = {
 	.mm		= &init_mm,
-	.markers	= address_markers,
 	.base_addr	= PAGE_OFFSET,
 };
 
@@ -375,10 +346,29 @@ void ptdump_check_wx(void)
 
 static int __init ptdump_init(void)
 {
-	address_markers[PAGE_END_NR].start_address = PAGE_END;
+	struct addr_marker m[] = {
+		{ PAGE_OFFSET,		"Linear Mapping start" },
+		{ PAGE_END,		"Linear Mapping end" },
 #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
-	address_markers[KASAN_START_NR].start_address = KASAN_SHADOW_START;
+		{ KASAN_SHADOW_START,   "Kasan shadow start" },
+		{ KASAN_SHADOW_END,     "Kasan shadow end" },
 #endif
+		{ MODULES_VADDR,	"Modules start" },
+		{ MODULES_END,		"Modules end" },
+		{ VMALLOC_START,	"vmalloc() area" },
+		{ VMALLOC_END,		"vmalloc() end" },
+		{ VMEMMAP_START,	"vmemmap start" },
+		{ VMEMMAP_END,		"vmemmap end" },
+		{ PCI_IO_START,		"PCI I/O start" },
+		{ PCI_IO_END,		"PCI I/O end" },
+		{ FIXADDR_TOT_START,    "Fixmap start" },
+		{ FIXADDR_TOP,	        "Fixmap end" },
+		{ -1,			NULL },
+	};
+	static struct addr_marker address_markers[ARRAY_SIZE(m)] __ro_after_init;
+
+	kernel_ptdump_info.markers = memcpy(address_markers, m, sizeof(m));
+
 	ptdump_initialize();
 	ptdump_debugfs_register(&kernel_ptdump_info, "kernel_page_tables");
 	return 0;
-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Wed Dec 13 00:40:29 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Wed, 13 Dec 2023 09:40:29 +0100
Subject: [PATCH v7 4/7] arm64: ptdump: Discover start of vmemmap region at runtime
In-Reply-To: <20231213084024.2367360-9-ardb@google.com>
References: <20231213084024.2367360-9-ardb@google.com>
Message-ID: <20231213084024.2367360-13-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

We will soon reclaim the part of the vmemmap region that covers VA space
that is not addressable by the hardware. To avoid confusion, ensure that
the 'vmemmap start' marker points at the start of the region that is
actually being used for the struct page array, rather than the start of
the region we set aside for it at build time.

Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
---
 arch/arm64/mm/ptdump.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index 66ccb8d6997e..5f0849528ccf 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -346,6 +346,8 @@ void ptdump_check_wx(void)
 
 static int __init ptdump_init(void)
 {
+	u64 page_offset = _PAGE_OFFSET(vabits_actual);
+	u64 vmemmap_start = (u64)virt_to_page((void *)page_offset);
 	struct addr_marker m[] = {
 		{ PAGE_OFFSET,		"Linear Mapping start" },
 		{ PAGE_END,		"Linear Mapping end" },
@@ -357,7 +359,7 @@ static int __init ptdump_init(void)
 		{ MODULES_END,		"Modules end" },
 		{ VMALLOC_START,	"vmalloc() area" },
 		{ VMALLOC_END,		"vmalloc() end" },
-		{ VMEMMAP_START,	"vmemmap start" },
+		{ vmemmap_start,	"vmemmap start" },
 		{ VMEMMAP_END,		"vmemmap end" },
 		{ PCI_IO_START,		"PCI I/O start" },
 		{ PCI_IO_END,		"PCI I/O end" },
-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Wed Dec 13 00:40:31 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Wed, 13 Dec 2023 09:40:31 +0100
Subject: [PATCH v7 6/7] arm64: mm: Reclaim unused vmemmap region for vmalloc use
In-Reply-To: <20231213084024.2367360-9-ardb@google.com>
References: <20231213084024.2367360-9-ardb@google.com>
Message-ID: <20231213084024.2367360-15-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

The vmemmap array is statically sized based on the maximum supported
size of the virtual address space, but it is located inside the upper VA
region, which is statically sized based on the *minimum* supported size
of the VA space. This doesn't matter much when using 64k pages, which is
the only configuration that currently supports 52-bit virtual
addressing.

However, upcoming LPA2 support will change this picture somewhat, as in
that case, the vmemmap array will take up more than 25% of the upper VA
region when using 4k pages. Given that most of this space is never used
when running on a system that does not support 52-bit virtual
addressing, let's reclaim the unused vmemmap area in that case.

Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
---
 arch/arm64/include/asm/pgtable.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 8d30e2787b1f..5b5bedfa320e 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -18,11 +18,15 @@
  * VMALLOC range.
  *
  * VMALLOC_START: beginning of the kernel vmalloc space
- * VMALLOC_END: extends to the available space below vmemmap, PCI I/O space
- *	and fixed mappings
+ * VMALLOC_END: extends to the available space below vmemmap
  */
 #define VMALLOC_START		(MODULES_END)
+#if VA_BITS == VA_BITS_MIN
 #define VMALLOC_END		(VMEMMAP_START - SZ_8M)
+#else
+#define VMEMMAP_UNUSED_NPAGES	((_PAGE_OFFSET(vabits_actual) - PAGE_OFFSET) >> PAGE_SHIFT)
+#define VMALLOC_END		(VMEMMAP_START + VMEMMAP_UNUSED_NPAGES * sizeof(struct page) - SZ_8M)
+#endif
 
 #define vmemmap			((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
 
-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Wed Dec 13 00:40:30 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Wed, 13 Dec 2023 09:40:30 +0100
Subject: [PATCH v7 5/7] arm64: vmemmap: Avoid base2 order of struct page size
 to dimension region
In-Reply-To: <20231213084024.2367360-9-ardb@google.com>
References: <20231213084024.2367360-9-ardb@google.com>
Message-ID: <20231213084024.2367360-14-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

The placement and size of the vmemmap region in the kernel virtual
address space is currently derived from the base2 order of the size of a
struct page. This makes for nicely aligned constants with lots of
leading 0xf and trailing 0x0 digits, but given that the actual struct
pages are indexed as an ordinary array, this resulting region is
severely overdimensioned when the size of a struct page is just over a
power of 2.

This doesn't matter today, but once we enable 52-bit virtual addressing
for 4k pages configurations, the vmemmap region may take up almost half
of the upper VA region with the current struct page upper bound at 64
bytes. And once we enable KMSAN or other features that push the size of
a struct page over 64 bytes, we will run out of VMALLOC space entirely.

So instead, let's derive the region size from the actual size of a
struct page, and place the entire region 1 GB from the top of the VA
space, where it still doesn't share any lower level translation table
entries with the fixmap.

Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
---
 arch/arm64/include/asm/memory.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 2745bed8ae5b..b49575a92afc 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -30,8 +30,8 @@
  * keep a constant PAGE_OFFSET and "fallback" to using the higher end
  * of the VMEMMAP where 52-bit support is not available in hardware.
  */
-#define VMEMMAP_SHIFT	(PAGE_SHIFT - STRUCT_PAGE_MAX_SHIFT)
-#define VMEMMAP_SIZE	((_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) >> VMEMMAP_SHIFT)
+#define VMEMMAP_RANGE	(_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET)
+#define VMEMMAP_SIZE	((VMEMMAP_RANGE >> PAGE_SHIFT) * sizeof(struct page))
 
 /*
  * PAGE_OFFSET - the virtual address of the start of the linear map, at the
@@ -47,8 +47,8 @@
 #define MODULES_END		(MODULES_VADDR + MODULES_VSIZE)
 #define MODULES_VADDR		(_PAGE_END(VA_BITS_MIN))
 #define MODULES_VSIZE		(SZ_2G)
-#define VMEMMAP_START		(-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
-#define VMEMMAP_END		(VMEMMAP_START + VMEMMAP_SIZE)
+#define VMEMMAP_START		(VMEMMAP_END - VMEMMAP_SIZE)
+#define VMEMMAP_END		(-UL(SZ_1G))
 #define PCI_IO_START		(VMEMMAP_END + SZ_8M)
 #define PCI_IO_END		(PCI_IO_START + PCI_IO_SIZE)
 #define FIXADDR_TOP		(-UL(SZ_8M))
-- 
2.43.0.472.g3155946c3a-goog



From ardb at google.com  Wed Dec 13 00:40:32 2023
From: ardb at google.com (Ard Biesheuvel)
Date: Wed, 13 Dec 2023 09:40:32 +0100
Subject: [PATCH v7 7/7] arm64: kaslr: Adjust randomization range dynamically
In-Reply-To: <20231213084024.2367360-9-ardb@google.com>
References: <20231213084024.2367360-9-ardb@google.com>
Message-ID: <20231213084024.2367360-16-ardb@google.com>

From: Ard Biesheuvel <ardb at kernel.org>

Currently, we base the KASLR randomization range on a rough estimate of
the available space in the upper VA region: the lower 1/4th has the
module region and the upper 1/4th has the fixmap, vmemmap and PCI I/O
ranges, and so we pick a random location in the remaining space in the
middle.

Once we enable support for 5-level paging with 4k pages, this no longer
works: the vmemmap region, being dimensioned to cover a 52-bit linear
region, takes up so much space in the upper VA region (the size of which
is based on a 48-bit VA space for compatibility with non-LVA hardware)
that the region above the vmalloc region takes up more than a quarter of
the available space.

So instead of a heuristic, let's derive the randomization range from the
actual boundaries of the vmalloc region.

Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
---
 arch/arm64/kernel/image-vars.h     |  2 ++
 arch/arm64/kernel/pi/kaslr_early.c | 11 ++++++-----
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
index 5e4dc72ab1bd..e931ce078a00 100644
--- a/arch/arm64/kernel/image-vars.h
+++ b/arch/arm64/kernel/image-vars.h
@@ -36,6 +36,8 @@ PROVIDE(__pi___memcpy			= __pi_memcpy);
 PROVIDE(__pi___memmove			= __pi_memmove);
 PROVIDE(__pi___memset			= __pi_memset);
 
+PROVIDE(__pi_vabits_actual		= vabits_actual);
+
 #ifdef CONFIG_KVM
 
 /*
diff --git a/arch/arm64/kernel/pi/kaslr_early.c b/arch/arm64/kernel/pi/kaslr_early.c
index 17bff6e399e4..b9e0bb4bc6a9 100644
--- a/arch/arm64/kernel/pi/kaslr_early.c
+++ b/arch/arm64/kernel/pi/kaslr_early.c
@@ -14,6 +14,7 @@
 
 #include <asm/archrandom.h>
 #include <asm/memory.h>
+#include <asm/pgtable.h>
 
 /* taken from lib/string.c */
 static char *__strstr(const char *s1, const char *s2)
@@ -87,7 +88,7 @@ static u64 get_kaslr_seed(void *fdt)
 
 asmlinkage u64 kaslr_early_init(void *fdt)
 {
-	u64 seed;
+	u64 seed, range;
 
 	if (is_kaslr_disabled_cmdline(fdt))
 		return 0;
@@ -102,9 +103,9 @@ asmlinkage u64 kaslr_early_init(void *fdt)
 	/*
 	 * OK, so we are proceeding with KASLR enabled. Calculate a suitable
 	 * kernel image offset from the seed. Let's place the kernel in the
-	 * middle half of the VMALLOC area (VA_BITS_MIN - 2), and stay clear of
-	 * the lower and upper quarters to avoid colliding with other
-	 * allocations.
+	 * 'middle' half of the VMALLOC area, and stay clear of the lower and
+	 * upper quarters to avoid colliding with other allocations.
 	 */
-	return BIT(VA_BITS_MIN - 3) + (seed & GENMASK(VA_BITS_MIN - 3, 0));
+	range = (VMALLOC_END - KIMAGE_VADDR) / 2;
+	return range / 2 + (((__uint128_t)range * seed) >> 64);
 }
-- 
2.43.0.472.g3155946c3a-goog



From ppaalanen at gmail.com  Wed Dec 13 01:05:17 2023
From: ppaalanen at gmail.com (Pekka Paalanen)
Date: Wed, 13 Dec 2023 11:05:17 +0200
Subject: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
In-Reply-To: <DPBmATfmfvSP8Cwjz99kj_JvCEiAqRfuMFJZEBF2aIgl8NZqWFR66eyPTX1E8bHyOlimBihEE3E80p9bfOJ-0SNu8pwoIzL9gD2Xae6r97g=@emersion.fr>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
	<DPBmATfmfvSP8Cwjz99kj_JvCEiAqRfuMFJZEBF2aIgl8NZqWFR66eyPTX1E8bHyOlimBihEE3E80p9bfOJ-0SNu8pwoIzL9gD2Xae6r97g=@emersion.fr>
Message-ID: <20231213110517.6ce36aca@eldfell>

On Tue, 12 Dec 2023 16:36:35 +0000
Simon Ser <contact at emersion.fr> wrote:

> Is there a chance to pick a better name than "secure" here?
> 
> "Secure" is super overloaded, it's not clear at all what it means from
> just the name. Something like "restricted" would be an improvement.
> 

My thoughts exactly. Every time I see "secure" used for something that
either gives you garbage, refuses to work, or crashes your whole machine
*intentionally* when you try to do normal usual things to it in
userspace (like use it for GL texturing, or try to use KMS writeback), I
get an unscratchable itch.

There is nothing "secure" from security perspective there for end users
and developers. It's just inaccessible buffers.

I've been biting my lip until now, thinking it's too late.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/e71af21b/attachment.sig>

From shawnguo at kernel.org  Wed Dec 13 01:10:42 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 13 Dec 2023 17:10:42 +0800
Subject: [PATCH 2/3] ARM: dts: imx25-pdk: Pass #sound-dai-cells
In-Reply-To: <20231206115826.2244964-2-festevam@gmail.com>
References: <20231206115826.2244964-1-festevam@gmail.com>
 <20231206115826.2244964-2-festevam@gmail.com>
Message-ID: <20231213091042.GI270430@dragon>

On Wed, Dec 06, 2023 at 08:58:25AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per sgtl5000.yaml, '#sound-dai-cells' is a required property.
> 
> Pass it to fix the following dt-schema warning:
> 
> imx25-pdk.dtb: sgtl5000 at a: '#sound-dai-cells' is a required property
> 	from schema $id: http://devicetree.org/schemas/sound/sgtl5000.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>
> ---
>  arch/arm/boot/dts/nxp/imx/imx25-pdk.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts b/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
> index 04f4b127a172..14a61dc1e742 100644
> --- a/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
> +++ b/arch/arm/boot/dts/nxp/imx/imx25-pdk.dts
> @@ -122,6 +122,7 @@ &i2c1 {
>  	codec: sgtl5000 at a {
>  		compatible = "fsl,sgtl5000";
>  		reg = <0x0a>;
> +		 #sound-dai-cells = <0>;

There is a white space.

Fixed it up and applied all 3 patches.

Shawn

>  		clocks = <&clks 129>;
>  		VDDA-supply = <&reg_2p5v>;
>  		VDDIO-supply = <&reg_3p3v>;
> -- 
> 2.34.1
> 


From shawnguo at kernel.org  Wed Dec 13 01:12:33 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 13 Dec 2023 17:12:33 +0800
Subject: [PATCH v2] ARM: dts: imx: Use flash@0,0 pattern
In-Reply-To: <20231206123605.2255158-1-festevam@gmail.com>
References: <20231206123605.2255158-1-festevam@gmail.com>
Message-ID: <20231213091233.GJ270430@dragon>

On Wed, Dec 06, 2023 at 09:36:05AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per mtd-physmap.yaml, 'nor at 0,0' is not a valid node pattern.
> 
> Change it to 'flash at 0,0' to fix the following dt-schema warning:
> 
> imx1-ads.dtb: nor at 0,0: $nodename:0: 'nor at 0,0' does not match '^(flash|.*sram|nand)(@.*)?$'
> 	from schema $id: http://devicetree.org/schemas/mtd/mtd-physmap.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 01:13:24 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 13 Dec 2023 17:13:24 +0800
Subject: [PATCH 1/2] ARM: dts: imx27: Fix sram node
In-Reply-To: <20231206123921.2255532-1-festevam@gmail.com>
References: <20231206123921.2255532-1-festevam@gmail.com>
Message-ID: <20231213091324.GK270430@dragon>

On Wed, Dec 06, 2023 at 09:39:20AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per sram.yaml, address-cells, size-cells and ranges are mandatory.
> 
> Pass them to fix the following dt-schema warnings:
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied both, thanks!


From shawnguo at kernel.org  Wed Dec 13 01:14:13 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 13 Dec 2023 17:14:13 +0800
Subject: [PATCH] ARM: dts: imx27-phytec-phycore-som: Use the mux- prefix
In-Reply-To: <20231206124529.2256756-1-festevam@gmail.com>
References: <20231206124529.2256756-1-festevam@gmail.com>
Message-ID: <20231213091413.GL270430@dragon>

On Wed, Dec 06, 2023 at 09:45:29AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> According to Documentation/devicetree/bindings/sound/imx-audmux.yaml,
> there must be a "mux-" prefix in the audmux port nodes.
> 
> Add the "mux-" prefix to avoid the following dt-schema warning:
> 
> imx27-phytec-phycore-rdk.dtb: audmux at 10016000: 'pins4', 'ssi0' do not match any of the regexes: '^mux-[0-9a-z]*$', 'pinctrl-[0-9]+'
> 	from schema $id: http://devicetree.org/schemas/sound/imx-audmux.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 01:18:44 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 13 Dec 2023 17:18:44 +0800
Subject: [PATCH 0/2] TQMLX2160A support
In-Reply-To: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>
References: <20231206-for-ml-tqmlx2160a-v1-0-622e41ae4d8e@ew.tq-group.com>
Message-ID: <20231213091844.GM270430@dragon>

On Wed, Dec 06, 2023 at 03:01:00PM +0100, Gregor Herburger wrote:
> Hi,
> 
> this series adds initial support for the TQMLX2160A SoM on MBLX2160a
> baseboard. The various supported Serdes Configurations are added with
> overlay files.
> 
> Patch 1 adds the compatible to dt bindings
> Patch 2 adds the dts files
> 
> ---
> Gregor Herburger (2):
>       dt-bindings: arm: fsl: Add TQ-Systems LX2160A based boards
>       arm64: dts: freescale: add fsl-lx2160a-mblx2160a board

Applied both, thanks!


From sherry.sun at nxp.com  Wed Dec 13 01:28:46 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Wed, 13 Dec 2023 17:28:46 +0800
Subject: [PATCH V2 0/4] PCI: imx6: Add pci host wakeup support
Message-ID: <20231213092850.1706042-1-sherry.sun@nxp.com>

Add pci host wakeup feature for imx platforms. The host wake pin is a
standard feature in the PCIe bus specification, so we can add this
property under PCI dts node to support the host gpio wakeup feature.

Example of configuring the corresponding dts property under the PCI node:
    wake-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;

---
changes in V2:
1. Rename host-wake-gpio property to wake-gpios.
2. Improve the wake-gpios property description in the dt-binding doc to avoid
confusion.
3. Remove unnecessary debugging info in host_wake_irq_handler().
4. Remove unnecessary imx6_pcie->host_wake_irq = -1 resetting in error paths.
5. Use dev_err_probe() to simplify error path code.
---

Sherry Sun (4):
  PCI: imx6: Add pci host wakeup support on imx platforms.
  dt-bindings: imx6q-pcie: Add wake-gpios property
  arm64: dts: imx8mp-evk: add wake-gpios property for pci bus
  arm64: dts: imx8mq-evk: add wake-gpios property for pci bus

 .../bindings/pci/fsl,imx6q-pcie.yaml          |  6 ++
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts  |  2 +
 arch/arm64/boot/dts/freescale/imx8mq-evk.dts  |  2 +
 drivers/pci/controller/dwc/pci-imx6.c         | 60 +++++++++++++++++++
 4 files changed, 70 insertions(+)

-- 
2.34.1



From sherry.sun at nxp.com  Wed Dec 13 01:28:47 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Wed, 13 Dec 2023 17:28:47 +0800
Subject: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx platforms.
In-Reply-To: <20231213092850.1706042-1-sherry.sun@nxp.com>
References: <20231213092850.1706042-1-sherry.sun@nxp.com>
Message-ID: <20231213092850.1706042-2-sherry.sun@nxp.com>

Add pci host wakeup feature for imx platforms.
Example of configuring the corresponding dts property under the PCI
node:
wake-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;

Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 60 +++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 74703362aeec..0cf7f21adff8 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -72,6 +72,7 @@ struct imx6_pcie_drvdata {
 struct imx6_pcie {
 	struct dw_pcie		*pci;
 	int			reset_gpio;
+	int			host_wake_irq;
 	bool			gpio_active_high;
 	bool			link_is_up;
 	struct clk		*pcie_bus;
@@ -1237,11 +1238,44 @@ static int imx6_pcie_resume_noirq(struct device *dev)
 	return 0;
 }
 
+static int imx6_pcie_suspend(struct device *dev)
+{
+	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+
+	if (imx6_pcie->host_wake_irq >= 0)
+		enable_irq_wake(imx6_pcie->host_wake_irq);
+
+	return 0;
+}
+
+static int imx6_pcie_resume(struct device *dev)
+{
+	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+
+	if (imx6_pcie->host_wake_irq >= 0)
+		disable_irq_wake(imx6_pcie->host_wake_irq);
+
+	return 0;
+}
+
 static const struct dev_pm_ops imx6_pcie_pm_ops = {
 	NOIRQ_SYSTEM_SLEEP_PM_OPS(imx6_pcie_suspend_noirq,
 				  imx6_pcie_resume_noirq)
+	SYSTEM_SLEEP_PM_OPS(imx6_pcie_suspend, imx6_pcie_resume)
 };
 
+irqreturn_t host_wake_irq_handler(int irq, void *priv)
+{
+	struct imx6_pcie *imx6_pcie = priv;
+	struct device *dev = imx6_pcie->pci->dev;
+
+	/* Notify PM core we are wakeup source */
+	pm_wakeup_event(dev, 0);
+	pm_system_wakeup();
+
+	return IRQ_HANDLED;
+}
+
 static int imx6_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1250,6 +1284,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	struct device_node *np;
 	struct resource *dbi_base;
 	struct device_node *node = dev->of_node;
+	struct gpio_desc *host_wake_gpio;
 	int ret;
 	u16 val;
 
@@ -1457,6 +1492,26 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			val |= PCI_MSI_FLAGS_ENABLE;
 			dw_pcie_writew_dbi(pci, offset + PCI_MSI_FLAGS, val);
 		}
+
+		/* host wakeup support */
+		imx6_pcie->host_wake_irq = -1;
+		host_wake_gpio = devm_gpiod_get_optional(dev, "wake", GPIOD_IN);
+		if (IS_ERR(host_wake_gpio))
+			return PTR_ERR(host_wake_gpio);
+
+		if (host_wake_gpio != NULL) {
+			imx6_pcie->host_wake_irq = gpiod_to_irq(host_wake_gpio);
+			ret = devm_request_threaded_irq(dev, imx6_pcie->host_wake_irq, NULL,
+							host_wake_irq_handler,
+							IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
+							"host_wake", imx6_pcie);
+			if (ret)
+				return dev_err_probe(dev, ret, "Failed to request host_wake_irq\n");
+
+			ret = device_init_wakeup(dev, true);
+			if (ret)
+				return dev_err_probe(dev, ret, "Failed to init host_wake_irq\n");
+		}
 	}
 
 	return 0;
@@ -1466,6 +1521,11 @@ static void imx6_pcie_shutdown(struct platform_device *pdev)
 {
 	struct imx6_pcie *imx6_pcie = platform_get_drvdata(pdev);
 
+	if (imx6_pcie->host_wake_irq >= 0) {
+		device_init_wakeup(&pdev->dev, false);
+		disable_irq(imx6_pcie->host_wake_irq);
+	}
+
 	/* bring down link, so bootloader gets clean state in case of reboot */
 	imx6_pcie_assert_core_reset(imx6_pcie);
 }
-- 
2.34.1



From sherry.sun at nxp.com  Wed Dec 13 01:28:48 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Wed, 13 Dec 2023 17:28:48 +0800
Subject: [PATCH V2 2/4] dt-bindings: imx6q-pcie: Add wake-gpios property
In-Reply-To: <20231213092850.1706042-1-sherry.sun@nxp.com>
References: <20231213092850.1706042-1-sherry.sun@nxp.com>
Message-ID: <20231213092850.1706042-3-sherry.sun@nxp.com>

Add wake-gpios property that can be used to wakeup the host
processor.

Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
---
 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 81bbb8728f0f..fba757d937e1 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -72,6 +72,12 @@ properties:
       L=operation state) (optional required).
     type: boolean
 
+  wake-gpios:
+    description: If present this property specifies WAKE# sideband signaling
+      to implement wakeup functionality. This is an input GPIO pin for the Root
+      Port mode here. Host drivers will wakeup the host using the IRQ
+      corresponding to the passed GPIO.
+
 required:
   - compatible
   - reg
-- 
2.34.1



From sherry.sun at nxp.com  Wed Dec 13 01:28:50 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Wed, 13 Dec 2023 17:28:50 +0800
Subject: [PATCH V2 4/4] arm64: dts: imx8mq-evk: add wake-gpios property for pci bus
In-Reply-To: <20231213092850.1706042-1-sherry.sun@nxp.com>
References: <20231213092850.1706042-1-sherry.sun@nxp.com>
Message-ID: <20231213092850.1706042-5-sherry.sun@nxp.com>

The host wake pin is a standard feature in the PCIe bus specification,
so we add this property under PCI dts node to enable the host wake
function.

Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index 7507548cdb16..b8463ef230c5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -367,6 +367,7 @@ &pcie1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_pcie1>;
 	reset-gpio = <&gpio5 12 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
 	clocks = <&clk IMX8MQ_CLK_PCIE2_ROOT>,
 		 <&pcie0_refclk>,
 		 <&clk IMX8MQ_CLK_PCIE2_PHY>,
@@ -545,6 +546,7 @@ pinctrl_pcie1: pcie1grp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_I2C4_SDA_PCIE2_CLKREQ_B		0x76
 			MX8MQ_IOMUXC_ECSPI2_MISO_GPIO5_IO12		0x16
+			MX8MQ_IOMUXC_ECSPI2_MOSI_GPIO5_IO11		0x41
 		>;
 	};
 
-- 
2.34.1



From shawnguo at kernel.org  Wed Dec 13 01:31:34 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 13 Dec 2023 17:31:34 +0800
Subject: [PATCH v3 00/14] arm64: dts: imx8mm-kontron: DT updates
In-Reply-To: <20231206144201.46911-1-frieder@fris.de>
References: <20231206144201.46911-1-frieder@fris.de>
Message-ID: <20231213093134.GN270430@dragon>

On Wed, Dec 06, 2023 at 03:41:03PM +0100, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf at kontron.de>
...
>  arch/arm64/boot/dts/freescale/Makefile        |   4 +
>  .../dts/freescale/imx8mm-kontron-bl-osm-s.dts | 295 +++------
>  .../boot/dts/freescale/imx8mm-kontron-bl.dts  | 198 +++++-
>  .../boot/dts/freescale/imx8mm-kontron-dl.dtso | 201 +++++++
>  .../dts/freescale/imx8mm-kontron-osm-s.dtsi   | 567 +++++++++++++++++-
>  .../boot/dts/freescale/imx8mm-kontron-sl.dtsi |   4 +-
>  6 files changed, 1035 insertions(+), 234 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso

A couple of things:

- I have to use 'git am -3' apply some of the patches.  Could you rebase
  the series on imx/dt64 branch?

- There are a few DTC warnings that need to be addressed.

../arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts:235.34-238.7: Warning (graph_endpoint): /soc at 0/bus at 30800000/i2c at 30a40000/bridge at 2c/ports/port at 0/endpoint: graph connection to node '/soc at 0/bus at 32c00000/dsi at 32e10000/ports/port at 1/endpoint' is not bidirectional

arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtbo: Warning (graph_port): /fragment at 3: graph port node name should be 'port'
../arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso:61.17-63.3: Warning (graph_endpoint): /fragment at 3/__overlay__: graph endpoint node name should be 'endpoint'

Shawn


From geert+renesas at glider.be  Wed Dec 13 01:32:25 2023
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Wed, 13 Dec 2023 10:32:25 +0100
Subject: [PATCH] arm64: dts: renesas: white-hawk-cpu: Fix missing serial console pin control
Message-ID: <8a51516581cd71ecbfa174af9c7cebad1fc83c5b.1702459865.git.geert+renesas@glider.be>

The pin control description for the serial console was added, but not
enabled, due to missing pinctrl properties in the serial port device
node.

Fixes: 7a8d590de8132853 ("arm64: dts: renesas: white-hawk-cpu: Add serial port pin control")
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
To be queued in renesas-devel for v6.8.

 arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
index bb4a5270f71b6a75..913f70fe6c5cd2d8 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
@@ -187,6 +187,9 @@ &extalr_clk {
 };
 
 &hscif0 {
+	pinctrl-0 = <&hscif0_pins>;
+	pinctrl-names = "default";
+
 	status = "okay";
 };
 
-- 
2.34.1



From j-luthra at ti.com  Wed Dec 13 01:39:35 2023
From: j-luthra at ti.com (Jai Luthra)
Date: Wed, 13 Dec 2023 15:09:35 +0530
Subject: [PATCH 3/3] arm64: dts: ti: k3-am6*: Add additional regs for DMA
 components
In-Reply-To: <20231212111634.3515175-4-vigneshr@ti.com>
References: <20231212111634.3515175-1-vigneshr@ti.com>
 <20231212111634.3515175-4-vigneshr@ti.com>
Message-ID: <rtvhpdfxap73gbpxjungp3kcexwfqao3drfrolkwcjdrin3cyb@3lyy3xhspml7>

Hi Vignesh,

Thanks for the patch, PKTDMA address region sizes don't seem to match 
the TRM. Not sure if the patch is wrong or TRM is wrong.

On Dec 12, 2023 at 16:46:34 +0530, Vignesh Raghavendra wrote:
> Add additional reg properties for BCDMA and PKTDMA nodes which are
> mostly used by bootloader components before Device Manager firmware
> services are available, in order to setup DMA transfers.
> 
> Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
> ---
>  arch/arm64/boot/dts/ti/k3-am62-main.dtsi  | 18 ++++++++++++++----
>  arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 18 ++++++++++++++----
>  arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 18 ++++++++++++++----
>  arch/arm64/boot/dts/ti/k3-am64-main.dtsi  | 18 ++++++++++++++----
>  4 files changed, 56 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> index e5c64c86d1d5..4514a140ad38 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
> @@ -121,8 +121,13 @@ main_bcdma: dma-controller at 485c0100 {
>  			      <0x00 0x4c000000 0x00 0x20000>,
>  			      <0x00 0x4a820000 0x00 0x20000>,
>  			      <0x00 0x4aa40000 0x00 0x20000>,
> -			      <0x00 0x4bc00000 0x00 0x100000>;
> -			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
> +			      <0x00 0x4bc00000 0x00 0x100000>,
> +			      <0x00 0x48600000 0x00 0x8000>,
> +			      <0x00 0x484a4000 0x00 0x2000>,
> +			      <0x00 0x484c2000 0x00 0x2000>,
> +			      <0x00 0x48420000 0x00 0x2000>;
> +			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
> +				    "ring", "tchan", "rchan", "bchan";

BCDMA ranges LGTM, but PDMA ranges below are not matching with the TRM.

>  			msi-parent = <&inta_main_dmss>;
>  			#dma-cells = <3>;
>  
> @@ -138,8 +143,13 @@ main_pktdma: dma-controller at 485c0000 {
>  			reg = <0x00 0x485c0000 0x00 0x100>,
>  			      <0x00 0x4a800000 0x00 0x20000>,
>  			      <0x00 0x4aa00000 0x00 0x40000>,
> -			      <0x00 0x4b800000 0x00 0x400000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
> +			      <0x00 0x4b800000 0x00 0x400000>,
> +			      <0x00 0x485e0000 0x00 0x20000>,

PKTDMA RING region range 0x10000 in the TRM.

> +			      <0x00 0x484a0000 0x00 0x4000>,

PKTDMA TCHAN region range is 0x2000 in the TRM.

> +			      <0x00 0x484c0000 0x00 0x2000>,

This matches TRM.

> +			      <0x00 0x48430000 0x00 0x4000>;

PKGTMA RFLOW region range is 0x1000 in the TRM.

> +			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
> +				    "ring", "tchan", "rchan", "rflow";
>  			msi-parent = <&inta_main_dmss>;
>  			#dma-cells = <2>;
>  
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
> index 4ae7fdc5221b..36947d9d644d 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
> @@ -101,8 +101,13 @@ main_bcdma: dma-controller at 485c0100 {
>  			      <0x00 0x4c000000 0x00 0x20000>,
>  			      <0x00 0x4a820000 0x00 0x20000>,
>  			      <0x00 0x4aa40000 0x00 0x20000>,
> -			      <0x00 0x4bc00000 0x00 0x100000>;
> -			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
> +			      <0x00 0x4bc00000 0x00 0x100000>,
> +			      <0x00 0x48600000 0x00 0x8000>,
> +			      <0x00 0x484a4000 0x00 0x2000>,
> +			      <0x00 0x484c2000 0x00 0x2000>,
> +			      <0x00 0x48420000 0x00 0x2000>;
> +			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
> +				    "ring", "tchan", "rchan", "bchan";
>  			msi-parent = <&inta_main_dmss>;
>  			#dma-cells = <3>;
>  			ti,sci = <&dmsc>;
> @@ -117,8 +122,13 @@ main_pktdma: dma-controller at 485c0000 {
>  			reg = <0x00 0x485c0000 0x00 0x100>,
>  			      <0x00 0x4a800000 0x00 0x20000>,
>  			      <0x00 0x4aa00000 0x00 0x40000>,
> -			      <0x00 0x4b800000 0x00 0x400000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
> +			      <0x00 0x4b800000 0x00 0x400000>,
> +			      <0x00 0x485e0000 0x00 0x20000>,
> +			      <0x00 0x484a0000 0x00 0x4000>,
> +			      <0x00 0x484c0000 0x00 0x2000>,
> +			      <0x00 0x48430000 0x00 0x4000>;

Same issue as AM62, the TRM mentions a different size for these regions.

> +			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
> +				    "ring", "tchan", "rchan", "rflow";
>  			msi-parent = <&inta_main_dmss>;
>  			#dma-cells = <2>;
>  			ti,sci = <&dmsc>;
> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> index 963758c7d377..21981489b4db 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
> @@ -101,8 +101,13 @@ main_bcdma: dma-controller at 485c0100 {
>  			      <0x00 0x4c000000 0x00 0x20000>,
>  			      <0x00 0x4a820000 0x00 0x20000>,
>  			      <0x00 0x4aa40000 0x00 0x20000>,
> -			      <0x00 0x4bc00000 0x00 0x100000>;
> -			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
> +			      <0x00 0x4bc00000 0x00 0x100000>,
> +			      <0x00 0x48600000 0x00 0x8000>,
> +			      <0x00 0x484a4000 0x00 0x2000>,
> +			      <0x00 0x484c2000 0x00 0x2000>,
> +			      <0x00 0x48420000 0x00 0x2000>;
> +			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
> +				    "ring", "tchan", "rchan", "bchan";
>  			msi-parent = <&inta_main_dmss>;
>  			#dma-cells = <3>;
>  
> @@ -119,8 +124,13 @@ main_pktdma: dma-controller at 485c0000 {
>  			reg = <0x00 0x485c0000 0x00 0x100>,
>  			      <0x00 0x4a800000 0x00 0x20000>,
>  			      <0x00 0x4aa00000 0x00 0x40000>,
> -			      <0x00 0x4b800000 0x00 0x400000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
> +			      <0x00 0x4b800000 0x00 0x400000>,
> +			      <0x00 0x485e0000 0x00 0x20000>,
> +			      <0x00 0x484a0000 0x00 0x4000>,
> +			      <0x00 0x484c0000 0x00 0x2000>,
> +			      <0x00 0x48430000 0x00 0x4000>;

Same here as well.

> +			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
> +				    "ring", "tchan", "rchan", "rflow";
>  			msi-parent = <&inta_main_dmss>;
>  			#dma-cells = <2>;
>  			bootph-all;
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> index 0be642bc1b86..bcdfd61c7d98 100644
> --- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -138,8 +138,13 @@ main_bcdma: dma-controller at 485c0100 {
>  			      <0x00 0x4c000000 0x00 0x20000>,
>  			      <0x00 0x4a820000 0x00 0x20000>,
>  			      <0x00 0x4aa40000 0x00 0x20000>,
> -			      <0x00 0x4bc00000 0x00 0x100000>;
> -			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
> +			      <0x00 0x4bc00000 0x00 0x100000>,
> +			      <0x00 0x48600000 0x00 0x8000>,
> +			      <0x00 0x484a4000 0x00 0x2000>,
> +			      <0x00 0x484c2000 0x00 0x2000>,
> +			      <0x00 0x48420000 0x00 0x2000>;
> +			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
> +				    "ring", "tchan", "rchan", "bchan";
>  			msi-parent = <&inta_main_dmss>;
>  			#dma-cells = <3>;
>  
> @@ -155,8 +160,13 @@ main_pktdma: dma-controller at 485c0000 {
>  			reg = <0x00 0x485c0000 0x00 0x100>,
>  			      <0x00 0x4a800000 0x00 0x20000>,
>  			      <0x00 0x4aa00000 0x00 0x40000>,
> -			      <0x00 0x4b800000 0x00 0x400000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
> +			      <0x00 0x4b800000 0x00 0x400000>,
> +			      <0x00 0x485e0000 0x00 0x20000>,
> +			      <0x00 0x484a0000 0x00 0x4000>,
> +			      <0x00 0x484c0000 0x00 0x2000>,
> +			      <0x00 0x48430000 0x00 0x4000>;

Did not check TRM for AM64, might need a fix here as well.

> +			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
> +				    "ring", "tchan", "rchan", "rflow";
>  			msi-parent = <&inta_main_dmss>;
>  			#dma-cells = <2>;
>  
> -- 
> 2.43.0
> 
> 

-- 
Thanks,
Jai

GPG Fingerprint: 4DE0 D818 E5D5 75E8 D45A AFC5 43DE 91F9 249A 7145
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/b09f96f0/attachment.sig>

From sherry.sun at nxp.com  Wed Dec 13 01:28:49 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Wed, 13 Dec 2023 17:28:49 +0800
Subject: [PATCH V2 3/4] arm64: dts: imx8mp-evk: add wake-gpios property for pci bus
In-Reply-To: <20231213092850.1706042-1-sherry.sun@nxp.com>
References: <20231213092850.1706042-1-sherry.sun@nxp.com>
Message-ID: <20231213092850.1706042-4-sherry.sun@nxp.com>

The host wake pin is a standard feature in the PCIe bus specification,
so we add this property under PCI dts node to enable the host wake
function.

Signed-off-by: Sherry Sun <sherry.sun at nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
index f87fa5a948cc..4378b9c1308c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -542,6 +542,7 @@ &pcie {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_pcie0>;
 	reset-gpio = <&gpio2 7 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;
 	vpcie-supply = <&reg_pcie0>;
 	status = "okay";
 };
@@ -772,6 +773,7 @@ pinctrl_pcie0: pcie0grp {
 		fsl,pins = <
 			MX8MP_IOMUXC_I2C4_SCL__PCIE_CLKREQ_B	0x60 /* open drain, pull up */
 			MX8MP_IOMUXC_SD1_DATA5__GPIO2_IO07	0x40
+			MX8MP_IOMUXC_I2C4_SDA__GPIO5_IO21	0x1c4
 		>;
 	};
 
-- 
2.34.1



From j-luthra at ti.com  Wed Dec 13 01:46:02 2023
From: j-luthra at ti.com (Jai Luthra)
Date: Wed, 13 Dec 2023 15:16:02 +0530
Subject: [PATCH 1/3] arm64: dts: ti: k3-am65: Add additional regs for DMA
 components
In-Reply-To: <20231212111634.3515175-2-vigneshr@ti.com>
References: <20231212111634.3515175-1-vigneshr@ti.com>
 <20231212111634.3515175-2-vigneshr@ti.com>
Message-ID: <rbwjt352yewngagypraqjzaynks65d3ttabeqqbdffifnoal55@aiuybx2bvx6l>

Hi Vignesh/Manorit,

Thanks for the patch. BCDMA regions don't seem to match the TRM for 
AM65, can you recheck?

On Dec 12, 2023 at 16:46:32 +0530, Vignesh Raghavendra wrote:
> From: Manorit Chawdhry <m-chawdhry at ti.com>
> 
> Add additional reg properties for UDMA and RingAcc nodes which are
> mostly used by bootloader components before Device Manager firmware
> services are available, in order to setup DMA transfers.
> 
> Signed-off-by: Manorit Chawdhry <m-chawdhry at ti.com>
> Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
> ---
>  arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8 ++++++--
>  arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi  | 8 ++++++--
>  2 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index 5ebb87f467de..2033a8ec89d6 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -790,8 +790,12 @@ main_udmap: dma-controller at 31150000 {
>  			compatible = "ti,am654-navss-main-udmap";
>  			reg = <0x0 0x31150000 0x0 0x100>,
>  			      <0x0 0x34000000 0x0 0x100000>,
> -			      <0x0 0x35000000 0x0 0x100000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x0 0x35000000 0x0 0x100000>,
> +			      <0x0 0x30b00000 0x0 0x20000>,

AM65 TRM mentions TCHAN region size as 0x10000 in the memory map. Can 
you confirm if this is correct and send a v2 if not?

> +			      <0x0 0x30c00000 0x0 0x8000>,

Same here, TRM says size is 0x10000.

> +			      <0x0 0x30d00000 0x0 0x4000>;

Same here, TRM says size is 0x8000.

> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&inta_main_udmass>;
>  			#dma-cells = <1>;
>  
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> index edd5cfbec40e..ecd7356f3315 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> @@ -214,8 +214,12 @@ mcu_udmap: dma-controller at 285c0000 {
>  			compatible = "ti,am654-navss-mcu-udmap";
>  			reg = <0x0 0x285c0000 0x0 0x100>,
>  			      <0x0 0x2a800000 0x0 0x40000>,
> -			      <0x0 0x2aa00000 0x0 0x40000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x0 0x2aa00000 0x0 0x40000>,
> +			      <0x0 0x284a0000 0x0 0x4000>,
> +			      <0x0 0x284c0000 0x0 0x4000>,
> +			      <0x0 0x28400000 0x0 0x2000>;

These look okay.

> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&inta_main_udmass>;
>  			#dma-cells = <1>;
>  
> -- 
> 2.43.0
> 
> 

-- 
Thanks,
Jai

GPG Fingerprint: 4DE0 D818 E5D5 75E8 D45A AFC5 43DE 91F9 249A 7145
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/2d326772/attachment-0001.sig>

From conor at kernel.org  Wed Dec 13 01:46:44 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 09:46:44 +0000
Subject: [RFC PATCH net-next v3 1/8] dt-bindings: phy:
 mediatek,xfi-pextp: add new bindings
In-Reply-To: <ZXiNhSYDbowUiNvy@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel@makrotopia.org>
 <20231212-renderer-strobe-2b46652cd6e7@spud>
 <ZXiNhSYDbowUiNvy@makrotopia.org>
Message-ID: <20231213-confined-shaping-f56b1fdfb135@spud>

On Tue, Dec 12, 2023 at 04:42:45PM +0000, Daniel Golle wrote:
> On Tue, Dec 12, 2023 at 04:21:38PM +0000, Conor Dooley wrote:
> > On Tue, Dec 12, 2023 at 03:46:26AM +0000, Daniel Golle wrote:
> > 
> > > +  mediatek,usxgmii-performance-errata:
> > > +    $ref: /schemas/types.yaml#/definitions/flag
> > > +    description:
> > > +      USXGMII0 on MT7988 suffers from a performance problem in 10GBase-R
> > > +      mode which needs a work-around in the driver. The work-around is
> > > +      enabled using this flag.
> > 
> > Why do you need a property for this if you know that it is present on
> > the MT7988?
> 
> Because it is only present in one of the two SerDes channels.
> Channel 0 needs the work-around, Channel 1 doesn't.
> 
> See also this commit in the vendor driver for reference[1].
> 
> We previously discussed that[2] and it was decided that a property
> would be the prefered way to represent this as there aren't any other
> per-instance differences which would justify another compatible.

Please put it in the commit message so that when the next version shows
up, Krzysztof doesn't show up and question the property for the third
time.

Also, on another note, this series is aimed at net-next but half the
series is fixed for incorrect bindings. Why not net?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/2bc4decc/attachment.sig>

From atrajeev at linux.vnet.ibm.com  Wed Dec 13 01:51:56 2023
From: atrajeev at linux.vnet.ibm.com (Athira Rajeev)
Date: Wed, 13 Dec 2023 15:21:56 +0530
Subject: [PATCH V2 0/5] Clean up perf mem
In-Reply-To: <ZXIrtcYkvpA8Uwj1@kernel.org>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <ZXIrtcYkvpA8Uwj1@kernel.org>
Message-ID: <DC029166-B60F-4E90-833D-F43818A3C54B@linux.vnet.ibm.com>



> On 08-Dec-2023, at 2:01?AM, Arnaldo Carvalho de Melo <acme at kernel.org> wrote:
> 
> Em Thu, Dec 07, 2023 at 11:23:33AM -0800, kan.liang at linux.intel.com escreveu:
>> From: Kan Liang <kan.liang at linux.intel.com>
>> 
>> Changes since V1:
>> - Fix strcmp of PMU name checking (Ravi)
>> - Fix "/," typo (Ian)
>> - Rename several functions with perf_pmu__mem_events prefix. (Ian)
>> - Fold the header removal patch into the patch where the cleanups made.
>>  (Arnaldo)
>> - Add reviewed-by and tested-by from Ian and Ravi
> 
> It would be good to have a Tested-by from people working in all the
> architectures affectes, like we got from Ravi for AMD, can we get those?
> 
> I'm applying it locally for test building, will push to
> perf-tools-next/tmp.perf-tools-next for a while, so there is some time
> to test.
> 
> ARM64 (Leo?) and ppc, for PPC... humm Ravi did it, who could test it now?
Hi Arnaldo, Ravi

Looking into this for testing on powerpc. Will update back.

Thanks
Athira
> 
> - Arnaldo
> 
>> As discussed in the below thread, the patch set is to clean up perf mem.
>> https://lore.kernel.org/lkml/afefab15-cffc-4345-9cf4-c6a4128d4d9c at linux.intel.com/
>> 
>> Introduce generic functions perf_mem_events__ptr(),
>> perf_mem_events__name() ,and is_mem_loads_aux_event() to replace the
>> ARCH specific ones.
>> Simplify the perf_mem_event__supported().
>> 
>> Only keeps the ARCH-specific perf_mem_events array in the corresponding
>> mem-events.c for each ARCH.
>> 
>> There is no functional change.
>> 
>> The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
>> etc. But I can only test it on two Intel platforms.
>> Please give it try, if you have machines with other ARCHs.
>> 
>> Here are the test results:
>> Intel hybrid machine:
>> 
>> $perf mem record -e list
>> ldlat-loads  : available
>> ldlat-stores : available
>> 
>> $perf mem record -e ldlat-loads -v --ldlat 50
>> calling: record -e cpu_atom/mem-loads,ldlat=50/P -e cpu_core/mem-loads,ldlat=50/P
>> 
>> $perf mem record -v
>> calling: record -e cpu_atom/mem-loads,ldlat=30/P -e cpu_atom/mem-stores/P -e cpu_core/mem-loads,ldlat=30/P -e cpu_core/mem-stores/P
>> 
>> $perf mem record -t store -v
>> calling: record -e cpu_atom/mem-stores/P -e cpu_core/mem-stores/P
>> 
>> 
>> Intel SPR:
>> $perf mem record -e list
>> ldlat-loads  : available
>> ldlat-stores : available
>> 
>> $perf mem record -e ldlat-loads -v --ldlat 50
>> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=50/}:P
>> 
>> $perf mem record -v
>> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=30/}:P -e cpu/mem-stores/P
>> 
>> $perf mem record -t store -v
>> calling: record -e cpu/mem-stores/P
>> 
>> Kan Liang (5):
>>  perf mem: Add mem_events into the supported perf_pmu
>>  perf mem: Clean up perf_mem_events__ptr()
>>  perf mem: Clean up perf_mem_events__name()
>>  perf mem: Clean up perf_mem_event__supported()
>>  perf mem: Clean up is_mem_loads_aux_event()
>> 
>> tools/perf/arch/arm64/util/mem-events.c   |  36 +----
>> tools/perf/arch/arm64/util/pmu.c          |   6 +
>> tools/perf/arch/powerpc/util/mem-events.c |  13 +-
>> tools/perf/arch/powerpc/util/mem-events.h |   7 +
>> tools/perf/arch/powerpc/util/pmu.c        |  11 ++
>> tools/perf/arch/s390/util/pmu.c           |   3 +
>> tools/perf/arch/x86/util/mem-events.c     |  99 ++----------
>> tools/perf/arch/x86/util/pmu.c            |  11 ++
>> tools/perf/builtin-c2c.c                  |  28 +++-
>> tools/perf/builtin-mem.c                  |  28 +++-
>> tools/perf/util/mem-events.c              | 181 +++++++++++++---------
>> tools/perf/util/mem-events.h              |  15 +-
>> tools/perf/util/pmu.c                     |   4 +-
>> tools/perf/util/pmu.h                     |   7 +
>> 14 files changed, 233 insertions(+), 216 deletions(-)
>> create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
>> create mode 100644 tools/perf/arch/powerpc/util/pmu.c
>> 
>> -- 
>> 2.35.1
>> 
> 
> -- 
> 
> - Arnaldo




From andrew at lunn.ch  Wed Dec 13 01:54:02 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 13 Dec 2023 10:54:02 +0100
Subject: [PATCH net-next] net: stmmac: qcom-ethqos: Add sysfs nodes for
 qcom ethqos
In-Reply-To: <dd585977-50c4-40a4-a664-0ecb5a84807a@quicinc.com>
References: <20231204084854.31543-1-quic_snehshah@quicinc.com>
 <3e4a1b9c-ed0f-466e-ba11-fc5b7ef308a1@lunn.ch>
 <5d5f3955-fc30-428c-99f4-42f9b7580a84@quicinc.com>
 <0c966845-2bbc-4196-806d-6a33e435bf7d@lunn.ch>
 <dd585977-50c4-40a4-a664-0ecb5a84807a@quicinc.com>
Message-ID: <428bba44-c0b9-48b2-b4fc-feba3e2245ae@lunn.ch>

> >> We need to route vlan traffic of a specific Priority to GVM Queue
> >> (Ethernet queue 5) via programming a MAC register. The MAC register
> >> is not accessible in GVM and has to be programmed from PVM. stmmac
> >> already has TC OPS to program this routing via vlan
> >> priority. However, as PVM has only 4 queues enabled, TC tool will
> >> not take 5th queue as input. Hence, these nodes were added to
> >> conifure the MAC register to route specific vlan packets to 5th
> >> queue in GVM.
> >  
> >> Note: The queues mentioned above are HW MTL Queues and DMA
> >> Channels. The routing can be done in the HW itself based on vlan pcp
> >> before the packets reach to driver.
> > 
> > Is the normal way you would do this is like this:
> > 
> > tc qdisc add dev eth1 parent root handle 100 \
> > mqprio num_tc 4 \
> > map 0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0 \
> > queues 1 at 0 1 at 1 1 at 2 1 at 3 \
> > hw 1
> > 
> > But you are saying that you cannot extend this to 5 queues?
> > 
> >     Andrew
> 

> Yes this can't extend to 5 queues. Because, stmmac in primary
> virtual machine will only have 4 netdev queues. So TC won't take
> input for 5th queue.

I still don't understand your architecture. How can you have 5 queues
if the physical hardware only has 4?

Is there any documentation for all this? Any datasheet?

   Andrew


From paul at crapouillou.net  Wed Dec 13 01:55:46 2023
From: paul at crapouillou.net (Paul Cercueil)
Date: Wed, 13 Dec 2023 10:55:46 +0100
Subject: [PATCH v5 03/13] pinctrl: ingenic: Use C99 initializers in
 PINCTRL_PIN_GROUP()
In-Reply-To: <20231211190321.307330-4-andriy.shevchenko@linux.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
	 <20231211190321.307330-4-andriy.shevchenko@linux.intel.com>
Message-ID: <fb29c3bca8d245e3f7496539b7293aa4fc4bccd0.camel@crapouillou.net>

Hi Andy,

Le lundi 11 d?cembre 2023 ? 20:57 +0200, Andy Shevchenko a ?crit?:
> For the better flexibility use C99 initializers in
> PINCTRL_PIN_GROUP().
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> ---
> ?drivers/pinctrl/pinctrl-ingenic.c | 21 +++++++++++++--------
> ?1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-ingenic.c
> b/drivers/pinctrl/pinctrl-ingenic.c
> index ee718f6e2556..f5661dcdedf5 100644
> --- a/drivers/pinctrl/pinctrl-ingenic.c
> +++ b/drivers/pinctrl/pinctrl-ingenic.c
> @@ -82,16 +82,21 @@
> ?#define PINS_PER_GPIO_CHIP			32
> ?#define JZ4730_PINS_PER_PAIRED_REG	16
> ?
> -#define INGENIC_PIN_GROUP_FUNCS(name, id, funcs)		\
> -	{						\
> -		name,					\
> -		id##_pins,				\
> -		ARRAY_SIZE(id##_pins),			\
> -		funcs,					\
> +#define INGENIC_PIN_GROUP_FUNCS(_name_, id,
> funcs)					\
> +	{							
> 			\
> +		.name =
> _name_,								\
> +		.pins =
> id##_pins,							\
> +		.num_pins =
> ARRAY_SIZE(id##_pins),					\
> +		.data =
> funcs,								\
> ?	}
> ?
> -#define INGENIC_PIN_GROUP(name, id, func)		\
> -	INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
> +#define INGENIC_PIN_GROUP(_name_, id,
> func)						\
> +	{							
> 			\
> +		.name =
> _name_,								\
> +		.pins =
> id##_pins,							\
> +		.num_pins =
> ARRAY_SIZE(id##_pins),					\
> +		.data = (void
> *)func,							\
> +	}

This INGENIC_PIN_GROUP() macro doesn't need to be modified, does it?

Cheers,
-Paul

> ?
> ?enum jz_version {
> ?	ID_JZ4730,



From j-luthra at ti.com  Wed Dec 13 01:55:47 2023
From: j-luthra at ti.com (Jai Luthra)
Date: Wed, 13 Dec 2023 15:25:47 +0530
Subject: [PATCH 2/3] arm64: dts: ti: k3-j7*: Add additional regs for DMA
 components
In-Reply-To: <20231212111634.3515175-3-vigneshr@ti.com>
References: <20231212111634.3515175-1-vigneshr@ti.com>
 <20231212111634.3515175-3-vigneshr@ti.com>
Message-ID: <go65ysuu74xsg6xuqozlp4f6iqyxluxpxbafrizrj3xk5nkexk@uihz45d7wst3>

Hi Manorit/Vignesh,

Please recheck the addresses match each SoCs TRM.

On Dec 12, 2023 at 16:46:33 +0530, Vignesh Raghavendra wrote:
> From: Manorit Chawdhry <m-chawdhry at ti.com>
> 
> Add additional reg properties for UDMA and RingAcc nodes which are
> mostly used by bootloader components before Device Manager firmware
> services are available, in order to setup DMA transfers.
> 
> Signed-off-by: Manorit Chawdhry <m-chawdhry at ti.com>
> Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
> ---
>  arch/arm64/boot/dts/ti/k3-j7200-main.dtsi        | 8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi  | 8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j721e-main.dtsi        | 8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi  | 8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi       | 8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi | 8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi       | 8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi | 8 ++++++--
>  8 files changed, 48 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> index 264913f83287..97b90f4d09dd 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> @@ -281,8 +281,12 @@ main_udmap: dma-controller at 31150000 {
>  			compatible = "ti,j721e-navss-main-udmap";
>  			reg = <0x00 0x31150000 0x00 0x100>,
>  			      <0x00 0x34000000 0x00 0x100000>,
> -			      <0x00 0x35000000 0x00 0x100000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x00 0x35000000 0x00 0x100000>,
> +			      <0x00 0x30b00000 0x00 0x20000>,
> +			      <0x00 0x30c00000 0x00 0x8000>,
> +			      <0x00 0x30d00000 0x00 0x4000>;
> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&main_udmass_inta>;
>  			#dma-cells = <1>;
>  
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> index 3fc588b848c6..576ed7494521 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> @@ -346,8 +346,12 @@ mcu_udmap: dma-controller at 285c0000 {
>  			compatible = "ti,j721e-navss-mcu-udmap";
>  			reg = <0x00 0x285c0000 0x00 0x100>,
>  			      <0x00 0x2a800000 0x00 0x40000>,
> -			      <0x00 0x2aa00000 0x00 0x40000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x00 0x2aa00000 0x00 0x40000>,
> +			      <0x00 0x284a0000 0x00 0x4000>,
> +			      <0x00 0x284c0000 0x00 0x4000>,
> +			      <0x00 0x28400000 0x00 0x2000>;
> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&main_udmass_inta>;
>  			#dma-cells = <1>;
>  
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> index 746b9f8b1c64..f1e995d12d74 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> @@ -382,8 +382,12 @@ main_udmap: dma-controller at 31150000 {
>  			compatible = "ti,j721e-navss-main-udmap";
>  			reg = <0x0 0x31150000 0x0 0x100>,
>  			      <0x0 0x34000000 0x0 0x100000>,
> -			      <0x0 0x35000000 0x0 0x100000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x0 0x35000000 0x0 0x100000>,
> +			      <0x0 0x30b00000 0x0 0x20000>,
> +			      <0x0 0x30c00000 0x0 0x8000>,

Above don't match J721E TRM, which says TCHAN has size 0x10000.

> +			      <0x00 0x30d00000 0x00 0x4000>;

Same here, TRM says 0x8000.
I did not check J7200/J721S2 TRMs, please do.

> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&main_udmass_inta>;
>  			#dma-cells = <1>;
>  
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> index f7ab7719fc07..011d93e32238 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> @@ -468,8 +468,12 @@ mcu_udmap: dma-controller at 285c0000 {
>  			compatible = "ti,j721e-navss-mcu-udmap";
>  			reg = <0x0 0x285c0000 0x0 0x100>,
>  			      <0x0 0x2a800000 0x0 0x40000>,
> -			      <0x0 0x2aa00000 0x0 0x40000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x0 0x2aa00000 0x0 0x40000>,
> +			      <0x0 0x284a0000 0x0 0x4000>,
> +			      <0x0 0x284c0000 0x0 0x4000>,
> +			      <0x0 0x28400000 0x0 0x2000>;
> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&main_udmass_inta>;
>  			#dma-cells = <1>;
>  
> diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> index b03731b53a26..2ed469d36f1d 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
> @@ -1086,8 +1086,12 @@ main_udmap: dma-controller at 31150000 {
>  			compatible = "ti,j721e-navss-main-udmap";
>  			reg = <0x0 0x31150000 0x0 0x100>,
>  			      <0x0 0x34000000 0x0 0x80000>,
> -			      <0x0 0x35000000 0x0 0x200000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x0 0x35000000 0x0 0x200000>,
> +			      <0x0 0x30b00000 0x0 0x8000>,
> +			      <0x0 0x30c00000 0x0 0x20000>,
> +			      <0x0 0x30d00000 0x0 0x4000>;
> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&main_udmass_inta>;
>  			#dma-cells = <1>;
>  
> diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
> index 7254f3bd3634..75c6931480dd 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
> @@ -471,8 +471,12 @@ mcu_udmap: dma-controller at 285c0000 {
>  			compatible = "ti,j721e-navss-mcu-udmap";
>  			reg = <0x0 0x285c0000 0x0 0x100>,
>  			      <0x0 0x2a800000 0x0 0x40000>,
> -			      <0x0 0x2aa00000 0x0 0x40000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x0 0x2aa00000 0x0 0x40000>,
> +			      <0x0 0x284a0000 0x0 0x4000>,
> +			      <0x0 0x284c0000 0x0 0x4000>,
> +			      <0x0 0x28400000 0x0 0x2000>;
> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&main_udmass_inta>;
>  			#dma-cells = <1>;
>  
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index d89bcddcfe3d..827328450f96 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -1188,8 +1188,12 @@ main_udmap: dma-controller at 31150000 {
>  			compatible = "ti,j721e-navss-main-udmap";
>  			reg = <0x00 0x31150000 0x00 0x100>,
>  			      <0x00 0x34000000 0x00 0x80000>,
> -			      <0x00 0x35000000 0x00 0x200000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x00 0x35000000 0x00 0x200000>,
> +			      <0x00 0x30b00000 0x00 0x20000>,
> +			      <0x00 0x30c00000 0x00 0x8000>,
> +			      <0x00 0x30d00000 0x00 0x4000>;
> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&main_udmass_inta>;
>  			#dma-cells = <1>;
>  
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
> index adb5ea6b9732..0eebb92e6a72 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
> @@ -478,8 +478,12 @@ mcu_udmap: dma-controller at 285c0000 {
>  			compatible = "ti,j721e-navss-mcu-udmap";
>  			reg = <0x00 0x285c0000 0x00 0x100>,
>  			      <0x00 0x2a800000 0x00 0x40000>,
> -			      <0x00 0x2aa00000 0x00 0x40000>;
> -			reg-names = "gcfg", "rchanrt", "tchanrt";
> +			      <0x00 0x2aa00000 0x00 0x40000>,
> +			      <0x00 0x284a0000 0x00 0x4000>,
> +			      <0x00 0x284c0000 0x00 0x4000>,
> +			      <0x00 0x28400000 0x00 0x2000>;
> +			reg-names = "gcfg", "rchanrt", "tchanrt",
> +				    "tchan", "rchan", "rflow";
>  			msi-parent = <&main_udmass_inta>;
>  			#dma-cells = <1>;
>  
> -- 
> 2.43.0
> 
> 

-- 
Thanks,
Jai

GPG Fingerprint: 4DE0 D818 E5D5 75E8 D45A AFC5 43DE 91F9 249A 7145
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/03835135/attachment.sig>

From joakim.bech at linaro.org  Wed Dec 13 02:15:49 2023
From: joakim.bech at linaro.org (Joakim Bech)
Date: Wed, 13 Dec 2023 11:15:49 +0100
Subject: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
In-Reply-To: <20231213110517.6ce36aca@eldfell>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
 <DPBmATfmfvSP8Cwjz99kj_JvCEiAqRfuMFJZEBF2aIgl8NZqWFR66eyPTX1E8bHyOlimBihEE3E80p9bfOJ-0SNu8pwoIzL9gD2Xae6r97g=@emersion.fr>
 <20231213110517.6ce36aca@eldfell>
Message-ID: <20231213101549.lioqfzjxcvmqxqu3@pop-os.localdomain>

On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> On Tue, 12 Dec 2023 16:36:35 +0000
> Simon Ser <contact at emersion.fr> wrote:
> 
> > Is there a chance to pick a better name than "secure" here?
> > 
> > "Secure" is super overloaded, it's not clear at all what it means from
> > just the name. Something like "restricted" would be an improvement.
> > 
> 
> My thoughts exactly. Every time I see "secure" used for something that
> either gives you garbage, refuses to work, or crashes your whole machine
> *intentionally* when you try to do normal usual things to it in
> userspace (like use it for GL texturing, or try to use KMS writeback), I
> get an unscratchable itch.
> 
> There is nothing "secure" from security perspective there for end users
> and developers. It's just inaccessible buffers.
> 
> I've been biting my lip until now, thinking it's too late.
> 
The characteristics we're looking for here is a buffer where the content
is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
EL2. I.e, the content of the buffer is meant to be used and accessible
primarily by the secure side and other devices that has been granted
access to it (for example decoders, display controllers if we're talking
about video use cases). However, since the use cases for this exercises
the whole stack, from non-secure user space (EL0) all the way to secure
user space (S-EL0), with various devices needing access to the buffer at
various times, it makes sense to let Linux manage the buffers, although
it still cannot access the content. That's the overall context.

As for the name, it's always difficult to find a name suitable precisely
describing what it is. "Secure" is perhaps vague, but it might still a
good choice, if you carefully describe what secure means for this
particular heap (in the source code and the documentation for it). For
example, the definition of "secure" for a secure heap as here could mean
that buffer content is inaccessible to the host OS and user space
running in normal world (using Arm nomenclature). I wouldn't have any
problems with calling it secure if, as said it's defined what we mean by
saying so. But I'm all ears for other suggestions as well.

Safe, protected, shielded, unreachable, isolated, inaccessible,
unaccessible, fortified, ... would any of these make more sense?

> 
> Thanks,
> pq

-- 
// Regards
Joakim


From ulf.hansson at linaro.org  Wed Dec 13 02:33:43 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 13 Dec 2023 11:33:43 +0100
Subject: [PATCH] PM: domains: Drop the unused pm_genpd_opp_to_performance_state()
In-Reply-To: <20231127151931.47055-1-ulf.hansson@linaro.org>
References: <20231127151931.47055-1-ulf.hansson@linaro.org>
Message-ID: <CAPDyKFofR7AHDctZErs3QG_mXdnhY+yjqNYungim+yeLpx1gBQ@mail.gmail.com>

On Mon, 27 Nov 2023 at 16:19, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>
> Since commit 7c41cdcd3bbe ("OPP: Simplify the over-designed pstate <->
> level dance"), there is no longer any users of the
> pm_genpd_opp_to_performance_state() API. Let's therefore drop it and its
> corresponding ->opp_to_performance_state() callback, which also no longer
> has any users.
>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>

So, I have applied this for next and by adding your ack.

Kind regards
Uffe


> ---
>  drivers/base/power/domain.c | 32 --------------------------------
>  include/linux/pm_domain.h   | 12 ------------
>  2 files changed, 44 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index da1777e39eaa..cf65b5a9783c 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -3042,38 +3042,6 @@ int of_genpd_parse_idle_states(struct device_node *dn,
>  }
>  EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
>
> -/**
> - * pm_genpd_opp_to_performance_state - Gets performance state of the genpd from its OPP node.
> - *
> - * @genpd_dev: Genpd's device for which the performance-state needs to be found.
> - * @opp: struct dev_pm_opp of the OPP for which we need to find performance
> - *     state.
> - *
> - * Returns performance state encoded in the OPP of the genpd. This calls
> - * platform specific genpd->opp_to_performance_state() callback to translate
> - * power domain OPP to performance state.
> - *
> - * Returns performance state on success and 0 on failure.
> - */
> -unsigned int pm_genpd_opp_to_performance_state(struct device *genpd_dev,
> -                                              struct dev_pm_opp *opp)
> -{
> -       struct generic_pm_domain *genpd = NULL;
> -       int state;
> -
> -       genpd = container_of(genpd_dev, struct generic_pm_domain, dev);
> -
> -       if (unlikely(!genpd->opp_to_performance_state))
> -               return 0;
> -
> -       genpd_lock(genpd);
> -       state = genpd->opp_to_performance_state(genpd, opp);
> -       genpd_unlock(genpd);
> -
> -       return state;
> -}
> -EXPORT_SYMBOL_GPL(pm_genpd_opp_to_performance_state);
> -
>  static int __init genpd_bus_init(void)
>  {
>         return bus_register(&genpd_bus_type);
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 34663d0d5c55..b97c5e9820f9 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -118,7 +118,6 @@ struct genpd_power_state {
>  };
>
>  struct genpd_lock_ops;
> -struct dev_pm_opp;
>  struct opp_table;
>
>  struct generic_pm_domain {
> @@ -146,8 +145,6 @@ struct generic_pm_domain {
>         int (*power_on)(struct generic_pm_domain *domain);
>         struct raw_notifier_head power_notifiers; /* Power on/off notifiers */
>         struct opp_table *opp_table;    /* OPP table of the genpd */
> -       unsigned int (*opp_to_performance_state)(struct generic_pm_domain *genpd,
> -                                                struct dev_pm_opp *opp);
>         int (*set_performance_state)(struct generic_pm_domain *genpd,
>                                      unsigned int state);
>         struct gpd_dev_ops dev_ops;
> @@ -348,8 +345,6 @@ int of_genpd_remove_subdomain(struct of_phandle_args *parent_spec,
>  struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
>  int of_genpd_parse_idle_states(struct device_node *dn,
>                                struct genpd_power_state **states, int *n);
> -unsigned int pm_genpd_opp_to_performance_state(struct device *genpd_dev,
> -                                              struct dev_pm_opp *opp);
>
>  int genpd_dev_pm_attach(struct device *dev);
>  struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> @@ -395,13 +390,6 @@ static inline int of_genpd_parse_idle_states(struct device_node *dn,
>         return -ENODEV;
>  }
>
> -static inline unsigned int
> -pm_genpd_opp_to_performance_state(struct device *genpd_dev,
> -                                 struct dev_pm_opp *opp)
> -{
> -       return 0;
> -}
> -
>  static inline int genpd_dev_pm_attach(struct device *dev)
>  {
>         return 0;
> --
> 2.34.1
>


From angelogioacchino.delregno at collabora.com  Wed Dec 13 02:35:37 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 13 Dec 2023 11:35:37 +0100
Subject: [PATCH v2] ASoC: mediatek: mt7986: silence error in case of
 -EPROBE_DEFER
In-Reply-To: <b941a404d97c01ef3e30c49925927b9a7dafeb19.1702422544.git.daniel@makrotopia.org>
References: <b941a404d97c01ef3e30c49925927b9a7dafeb19.1702422544.git.daniel@makrotopia.org>
Message-ID: <38909757-5b30-485a-8482-b75a36f1442a@collabora.com>

Il 13/12/23 00:10, Daniel Golle ha scritto:
> If probe is defered no error should be printed. Use dev_err_probe() to
> have it muted.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> Reviewed-by: Maso Huang <maso.huang at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From quic_mnaresh at quicinc.com  Wed Dec 13 02:36:40 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Wed, 13 Dec 2023 16:06:40 +0530
Subject: [PATCH V4 0/2] Add CPU latency QoS support for ufs driver 
Message-ID: <20231213103642.15320-1-quic_mnaresh@quicinc.com>

Add CPU latency QoS support for ufs driver. This improves random io
performance by 15% for ufs.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 37101.3
	Random Write(IPOS) | 41065.13

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 42943.4
	Random Write(IPOS) | 46784.9
(Improvement with PM QoS = ~15%).

This patch is based on below patch by Stanley Chu [1]. 
Moving the PM QoS code to ufshcd.c and making it generic.

[1] https://lore.kernel.org/r/20220623035052.18802-8-stanley.chu at mediatek.com

Changes from v3:
- Removed UFSHCD_CAP_PM_QOS capability flag from patch#2.

Changes from v2:
- Addressed bvanassche and mani comments
- Provided sysfs interface to enable/disable PM QoS feature

Changes from v1:
- Addressed bvanassche comments to have the code in core ufshcd

Maramaina Naresh (2):
  ufs: core: Add CPU latency QoS support for ufs driver
  ufs: ufs-mediatek: Enable CPU latency PM QoS support for MEDIATEK SoC

 drivers/ufs/core/ufshcd.c       | 127 ++++++++++++++++++++++++++++++++
 drivers/ufs/host/ufs-mediatek.c |  17 -----
 drivers/ufs/host/ufs-mediatek.h |   3 -
 include/ufs/ufshcd.h            |   6 ++
 4 files changed, 133 insertions(+), 20 deletions(-)

-- 
2.17.1



From patchwork-bot+netdevbpf at kernel.org  Wed Dec 13 02:40:30 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 13 Dec 2023 10:40:30 +0000
Subject: [PATCH net-next v1] net: stmmac: mmc: Support more counters for XGMAC
 Core
In-Reply-To: <20231211060828.1629247-1-0x1207@gmail.com>
References: <20231211060828.1629247-1-0x1207@gmail.com>
Message-ID: <170246403017.27343.5850945742501390562.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (main)
by David S. Miller <davem at davemloft.net>:

On Mon, 11 Dec 2023 14:08:28 +0800 you wrote:
> Complete all counters on XGMAC Core.
> These can be useful for debugging.
> 
> Signed-off-by: Furong Xu <0x1207 at gmail.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/mmc.h     |  14 +++
>  .../net/ethernet/stmicro/stmmac/mmc_core.c    | 117 +++++++++++++++++-
>  .../ethernet/stmicro/stmmac/stmmac_ethtool.c  |  10 ++
>  3 files changed, 140 insertions(+), 1 deletion(-)

Here is the summary with links:
  - [net-next,v1] net: stmmac: mmc: Support more counters for XGMAC Core
    https://git.kernel.org/netdev/net-next/c/e5bc1f4c6554

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From quic_mnaresh at quicinc.com  Wed Dec 13 02:36:42 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Wed, 13 Dec 2023 16:06:42 +0530
Subject: [PATCH V4 2/2] ufs: ufs-mediatek: Enable CPU latency PM QoS support for MEDIATEK SoC
In-Reply-To: <20231213103642.15320-1-quic_mnaresh@quicinc.com>
References: <20231213103642.15320-1-quic_mnaresh@quicinc.com>
Message-ID: <20231213103642.15320-3-quic_mnaresh@quicinc.com>

Revert the existing PM QoS feature from MEDIATEK UFS driver as similar
PM QoS feature implementation is moved to core ufshcd.

Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/host/ufs-mediatek.c | 17 -----------------
 drivers/ufs/host/ufs-mediatek.h |  3 ---
 2 files changed, 20 deletions(-)

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index fc61790d289b..1e7dadcb644f 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -17,7 +17,6 @@
 #include <linux/of_platform.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
-#include <linux/pm_qos.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
@@ -626,21 +625,9 @@ static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
 	dev_info(hba->dev, "caps: 0x%x", host->caps);
 }
 
-static void ufs_mtk_boost_pm_qos(struct ufs_hba *hba, bool boost)
-{
-	struct ufs_mtk_host *host = ufshcd_get_variant(hba);
-
-	if (!host || !host->pm_qos_init)
-		return;
-
-	cpu_latency_qos_update_request(&host->pm_qos_req,
-				       boost ? 0 : PM_QOS_DEFAULT_VALUE);
-}
-
 static void ufs_mtk_scale_perf(struct ufs_hba *hba, bool scale_up)
 {
 	ufs_mtk_boost_crypt(hba, scale_up);
-	ufs_mtk_boost_pm_qos(hba, scale_up);
 }
 
 static void ufs_mtk_pwr_ctrl(struct ufs_hba *hba, bool on)
@@ -959,10 +946,6 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
 	host->ip_ver = ufshcd_readl(hba, REG_UFS_MTK_IP_VER);
 
-	/* Initialize pm-qos request */
-	cpu_latency_qos_add_request(&host->pm_qos_req, PM_QOS_DEFAULT_VALUE);
-	host->pm_qos_init = true;
-
 	goto out;
 
 out_variant_clear:
diff --git a/drivers/ufs/host/ufs-mediatek.h b/drivers/ufs/host/ufs-mediatek.h
index f76e80d91729..38eab95b0f79 100644
--- a/drivers/ufs/host/ufs-mediatek.h
+++ b/drivers/ufs/host/ufs-mediatek.h
@@ -7,7 +7,6 @@
 #define _UFS_MEDIATEK_H
 
 #include <linux/bitops.h>
-#include <linux/pm_qos.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
 
 /*
@@ -167,7 +166,6 @@ struct ufs_mtk_mcq_intr_info {
 
 struct ufs_mtk_host {
 	struct phy *mphy;
-	struct pm_qos_request pm_qos_req;
 	struct regulator *reg_va09;
 	struct reset_control *hci_reset;
 	struct reset_control *unipro_reset;
@@ -178,7 +176,6 @@ struct ufs_mtk_host {
 	struct ufs_mtk_hw_ver hw_ver;
 	enum ufs_mtk_host_caps caps;
 	bool mphy_powered_on;
-	bool pm_qos_init;
 	bool unipro_lpm;
 	bool ref_clk_enabled;
 	u16 ref_clk_ungating_wait_us;
-- 
2.17.1



From quic_mnaresh at quicinc.com  Wed Dec 13 02:36:41 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Wed, 13 Dec 2023 16:06:41 +0530
Subject: [PATCH V4 1/2] ufs: core: Add CPU latency QoS support for ufs driver
In-Reply-To: <20231213103642.15320-1-quic_mnaresh@quicinc.com>
References: <20231213103642.15320-1-quic_mnaresh@quicinc.com>
Message-ID: <20231213103642.15320-2-quic_mnaresh@quicinc.com>

Register ufs driver to CPU latency PM QoS framework to improve
ufs device random io performance.

PM QoS initialization will insert new QoS request into the CPU
latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
value.

UFS driver will vote for performance mode on scale up and power
save mode for scale down.

If clock scaling feature is not enabled then voting will be based
on clock on or off condition.

Provided sysfs interface to enable/disable PM QoS feature.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 41065.13
	Random Read(IPOS)  | 37101.3

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 46784.9
	Random Read(IPOS)  | 42943.4
(Improvement with PM QoS = ~15%).

Co-developed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall at quicinc.com>
Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/core/ufshcd.c | 127 ++++++++++++++++++++++++++++++++++++++
 include/ufs/ufshcd.h      |   6 ++
 2 files changed, 133 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index ae9936fc6ffb..7318fa480706 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1001,6 +1001,20 @@ static bool ufshcd_is_unipro_pa_params_tuning_req(struct ufs_hba *hba)
 	return ufshcd_get_local_unipro_ver(hba) < UFS_UNIPRO_VER_1_6;
 }
 
+/**
+ * ufshcd_pm_qos_update - update PM QoS request
+ * @hba: per adapter instance
+ * @on: If True, vote for perf PM QoS mode otherwise power save mode
+ */
+static void ufshcd_pm_qos_update(struct ufs_hba *hba, bool on)
+{
+	if (!hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? 0
+							: PM_QOS_DEFAULT_VALUE);
+}
+
 /**
  * ufshcd_set_clk_freq - set UFS controller clock frequencies
  * @hba: per adapter instance
@@ -1147,8 +1161,11 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, unsigned long freq,
 					    hba->devfreq->previous_freq);
 		else
 			ufshcd_set_clk_freq(hba, !scale_up);
+		goto out;
 	}
 
+	ufshcd_pm_qos_update(hba, scale_up);
+
 out:
 	trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
 			(scale_up ? "up" : "down"),
@@ -8615,6 +8632,109 @@ static void ufshcd_set_timestamp_attr(struct ufs_hba *hba)
 	ufshcd_release(hba);
 }
 
+/**
+ * ufshcd_pm_qos_init - initialize PM QoS request
+ * @hba: per adapter instance
+ */
+static void ufshcd_pm_qos_init(struct ufs_hba *hba)
+{
+
+	if (hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_add_request(&hba->pm_qos_req,
+					PM_QOS_DEFAULT_VALUE);
+
+	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
+		hba->pm_qos_enabled = true;
+}
+
+/**
+ * ufshcd_pm_qos_exit - remove request from PM QoS
+ * @hba: per adapter instance
+ */
+static void ufshcd_pm_qos_exit(struct ufs_hba *hba)
+{
+	if (!hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_remove_request(&hba->pm_qos_req);
+	hba->pm_qos_enabled = false;
+}
+
+/**
+ * ufshcd_pm_qos_enable_show - sysfs handler to show pm qos enable value
+ * @dev: device associated with the UFS controller
+ * @attr: sysfs attribute handle
+ * @buf: buffer for sysfs file
+ *
+ * Print 1 if PM QoS feature is enabled, 0 if disabled.
+ *
+ * Returns number of characters written to @buf.
+ */
+static ssize_t ufshcd_pm_qos_enable_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	return sysfs_emit(buf, "%d\n", hba->pm_qos_enabled);
+}
+
+/**
+ * ufshcd_pm_qos_enable_store - sysfs handler to store value
+ * @dev: device associated with the UFS controller
+ * @attr: sysfs attribute handle
+ * @buf: buffer for sysfs file
+ * @count: stores buffer characters count
+ *
+ * Input 0 to disable PM QoS and any non-zero positive value to enable.
+ * Default state: 1
+ *
+ * Return: number of characters written to @buf on success, < 0 upon failure.
+ */
+static ssize_t ufshcd_pm_qos_enable_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+	u32 value;
+
+	if (kstrtou32(buf, 0, &value))
+		return -EINVAL;
+
+	value = !!value;
+	if (value)
+		ufshcd_pm_qos_init(hba);
+	else
+		ufshcd_pm_qos_exit(hba);
+
+	return count;
+}
+
+/**
+ * ufshcd_init_pm_qos_sysfs - initialize PM QoS sysfs entry
+ * @hba: per adapter instance
+ */
+static void ufshcd_init_pm_qos_sysfs(struct ufs_hba *hba)
+{
+	hba->pm_qos_enable_attr.show = ufshcd_pm_qos_enable_show;
+	hba->pm_qos_enable_attr.store = ufshcd_pm_qos_enable_store;
+	sysfs_attr_init(&hba->pm_qos_enable_attr.attr);
+	hba->pm_qos_enable_attr.attr.name = "pm_qos_enable";
+	hba->pm_qos_enable_attr.attr.mode = 0644;
+	if (device_create_file(hba->dev, &hba->pm_qos_enable_attr))
+		dev_err(hba->dev, "Failed to create sysfs for pm_qos_enable\n");
+}
+
+/**
+ * ufshcd_remove_pm_qos_sysfs - remove PM QoS sysfs entry
+ * @hba: per adapter instance
+ */
+static void ufshcd_remove_pm_qos_sysfs(struct ufs_hba *hba)
+{
+	if (hba->pm_qos_enable_attr.attr.name)
+		device_remove_file(hba->dev, &hba->pm_qos_enable_attr);
+}
+
 /**
  * ufshcd_add_lus - probe and add UFS logical units
  * @hba: per-adapter instance
@@ -9204,6 +9324,8 @@ static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
 	if (ret)
 		return ret;
 
+	if (!ufshcd_is_clkscaling_supported(hba))
+		ufshcd_pm_qos_update(hba, on);
 out:
 	if (ret) {
 		list_for_each_entry(clki, head, list) {
@@ -9381,6 +9503,8 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
 static void ufshcd_hba_exit(struct ufs_hba *hba)
 {
 	if (hba->is_powered) {
+		ufshcd_remove_pm_qos_sysfs(hba);
+		ufshcd_pm_qos_exit(hba);
 		ufshcd_exit_clk_scaling(hba);
 		ufshcd_exit_clk_gating(hba);
 		if (hba->eh_wq)
@@ -10030,6 +10154,7 @@ static int ufshcd_suspend(struct ufs_hba *hba)
 	ufshcd_vreg_set_lpm(hba);
 	/* Put the host controller in low power mode if possible */
 	ufshcd_hba_vreg_set_lpm(hba);
+	ufshcd_pm_qos_update(hba, false);
 	return ret;
 }
 
@@ -10576,6 +10701,8 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 	ufs_sysfs_add_nodes(hba->dev);
 
 	device_enable_async_suspend(dev);
+	ufshcd_pm_qos_init(hba);
+	ufshcd_init_pm_qos_sysfs(hba);
 	return 0;
 
 free_tmf_queue:
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index d862c8ddce03..fa7434a9073d 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -912,6 +912,9 @@ enum ufshcd_mcq_opr {
  * @mcq_base: Multi circular queue registers base address
  * @uhq: array of supported hardware queues
  * @dev_cmd_queue: Queue for issuing device management commands
+ * @pm_qos_enable_attr: sysfs attribute to enable/disable  pm qos
+ * @pm_qos_req: PM QoS request handle
+ * @pm_qos_enabled: flag to check if pm qos is enabled
  */
 struct ufs_hba {
 	void __iomem *mmio_base;
@@ -1076,6 +1079,9 @@ struct ufs_hba {
 	struct ufs_hw_queue *uhq;
 	struct ufs_hw_queue *dev_cmd_queue;
 	struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
+	struct device_attribute pm_qos_enable_attr;
+	struct pm_qos_request pm_qos_req;
+	bool pm_qos_enabled;
 };
 
 /**
-- 
2.17.1



From angelogioacchino.delregno at collabora.com  Wed Dec 13 02:46:58 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 13 Dec 2023 11:46:58 +0100
Subject: [v9 3/4] ASoC: mediatek: mt8188-mt6359: add es8326 support
In-Reply-To: <CABRjgztKkpE8KOBfj47Bdt_EXFiXA8+6eh6+=WMyPHW2UOF-oA@mail.gmail.com>
References: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
 <20231212123050.4080083-4-zhourui@huaqin.corp-partner.google.com>
 <25ec0476-0ee3-4f2a-b0e6-ee33580159ab@collabora.com>
 <CABRjgztKkpE8KOBfj47Bdt_EXFiXA8+6eh6+=WMyPHW2UOF-oA@mail.gmail.com>
Message-ID: <bbc6d09b-c472-4334-ba67-1072e94a89e9@collabora.com>

Il 13/12/23 02:48, Rui Zhou ha scritto:
> Hi Angelo,
> Thank you for your review.
> I'm so sorry, but the person I added was obtained through the command
> ./scripts/get_maintainer.pl. Do you mean that the order of my TO/CC people
> is out of order? For example, it should be TO but CC is used.
> Or maybe I added less people to my email. In your spare time, could you
> please help check it out?
> Thank you very much!
> 
> ./scripts/get_maintainer.pl 00*.patch
> ./scripts/get_maintainer.pl: file '0000-cover-letter.patch' doesn't appear
> to be a patch.  Add -f to options?
> Liam Girdwood <lgirdwood at gmail.com> (supporter:SOUND - SOC LAYER / DYNAMIC
> AUDIO POWER MANAGEM...)
> Mark Brown <broonie at kernel.org> (supporter:SOUND - SOC LAYER / DYNAMIC
> AUDIO POWER MANAGEM...,commit_signer:10/11=91%,commit_signer:16/19=84%)
> Rob Herring <robh+dt at kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS,authored:1/19=5%)
> Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org> (maintainer:OPEN
> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
> Conor Dooley <conor+dt at kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS)
> Matthias Brugger <matthias.bgg at gmail.com> (maintainer:ARM/Mediatek SoC
> support)
> AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> (maintainer:ARM/Mediatek SoC
> support,commit_signer:4/11=36%,commit_signer:11/19=58%,authored:4/19=21%,removed_lines:41/157=26%)
> Jaroslav Kysela <perex at perex.cz> (maintainer:SOUND)
> Takashi Iwai <tiwai at suse.com> (maintainer:SOUND,removed_lines:11/157=7%)
> Trevor Wu <trevor.wu at mediatek.com>
> (commit_signer:5/11=45%,authored:3/11=27%,added_lines:27/54=50%,commit_signer:10/19=53%,authored:7/19=37%,added_lines:1401/1640=85%,removed_lines:26/157=17%,in
> file)
> xiazhengqiao <xiazhengqiao at huaqin.corp-partner.google.com>
> (commit_signer:2/11=18%,authored:2/11=18%,added_lines:120/1640=7%)
> Maso Huang <maso.huang at mediatek.com>
> (commit_signer:2/11=18%,authored:2/11=18%,added_lines:20/54=37%)
> Arnd Bergmann <arnd at arndb.de> (authored:1/11=9%)
> Rui Zhou <zhourui at huaqin.corp-partner.google.com>
> (authored:1/11=9%,commit_signer:3/19=16%,authored:3/19=16%,removed_lines:64/157=41%)
> Allen-KH Cheng <allen-kh.cheng at mediatek.com> (removed_lines:1/1=100%)
> Alexandre Mergnat <amergnat at baylibre.com> (commit_signer:7/19=37%)
> Dan Carpenter <dan.carpenter at linaro.org> (authored:1/19=5%)
> Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> (removed_lines:11/157=7%)


> linux-sound at vger.kernel.org (open list:SOUND - SOC LAYER / DYNAMIC AUDIO
> POWER MANAGEM...)

^^^^ You forgot to add this one :-)

Regards,
Angelo




From aakarsh.jain at samsung.com  Wed Dec 13 00:10:55 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:40:55 +0530
Subject: [Patch v6 00/10] Add MFC v12 support
References: <CGME20231213081112epcas5p171f1b69376bc4b1e8ced03f8b56efe35@epcas5p1.samsung.com>
Message-ID: <20231213081105.25817-1-aakarsh.jain@samsung.com>

This patch series adds MFC v12 support. MFC v12 is used in Tesla FSD SoC.

This adds support for following:

-Add support for YV12 and I420 format (3-plane)
-Add support for Rate Control, UHD and DMABUF for encoder
-Add support for DPB buffers allocation based on MFC requirement

changes since v5:
-As per Krzysztof, he will take MFC dt-entries patch via Samsung SoC
once dt-bindings patch gets accepted. Therefore, excluded MFC dt-entries
patch from v6.
-Addressed review comments by Hans Verkuil.
Resolved smatch warning from 'drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c'.
Resolved kernel doc warnings from 'drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h'.
Added explanation in the patch 9 as comment on why mfc v12 firmware loading is
needed for each run.
v5 link: https://patchwork.kernel.org/project/linux-media/cover/20231206063045.97234-1-aakarsh.jain at samsung.com/

Changes since v4:
-Addressed review comments by Krzysztof Kozlowski.
As per discussion included iommus property in dt-schema.
-Addressed review comments by Hans Verkuil.
Fixed checkpatch warnings with --strict flag enabled.
Upstreamed s5p-mfc-v12.fw to linux-firmware.
Added comment in the patch 9 regarding loading mfc firmware v12
sequentially.
-Addressed review comments by Nicolas Dufresne
Made use of v4l2-common library to get number of planes needed for
particular format in patch 4.
v4 link:https://patchwork.kernel.org/project/linux-media/patch/20231025102216.50480-2-aakarsh.jain at samsung.com/

Changes since v3:
-Removed vp9 codec support for now and just keeping MFC v12 base
patches with necessary hardware controls, decoder, encoder and
structural changes. Also covers luma dbp, chroma dpb and mv sizes
for each codec as per the UM for MFCv12, along with appropriate
alignment.
v3 link: https://patchwork.kernel.org/project/linux-media/cover/20221011122516.32135-1-aakarsh.jain at samsung.com/

Changes since v2:
-Addressed review comments by Rob Herring.
This was regarding the errors found by Rob bot in yaml file. File
'samsung,s5p-mfc.yaml' is already converted into json schema and is
merged.

-Addressed review comments by Krzysztof Kozlowski.
This was regarding depricated properties mentioned in s5p-mfc.txt file.
Review comment was addressed and 'samsung,s5p-mfc.yaml' is already
merged now.

-Addressed review comments by Andi Shyti.
This was regarding addition of 'MFC_V10PLUS_BITS' macro in
's5p_mfc_common.h file.
v2 link: https://patchwork.kernel.org/project/linux-media/cover/20220907064715.55778-1-smitha.t at samsung.com/

Changes since v1:
-Addressed review comments by Krzysztof Kozlowski.
Separated bug fixes patches, resent again with fix tag
and those are merged now.
-Added SoC based compatible string.

-Addressed review comments by Andrzej Hajda
Assigned width64 and height32 variable with ALIGN(ctx->img_..)
used in the code in 's5p_mfc_opr_v6.c' file.
v1 link: https://patchwork.kernel.org/project/linux-media/patch/20220517125548.14746-2-smitha.t at samsung.com/

Aakarsh Jain (10):
  dt-bindings: media: s5p-mfc: Add mfcv12 variant
  media: s5p-mfc: Rename IS_MFCV10 macro
  media: s5p-mfc: Add initial support for MFCv12
  media: s5p-mfc: Add YV12 and I420 multiplanar format support
  media: s5p-mfc: Add support for rate controls in MFCv12
  media: s5p-mfc: Add support for UHD encoding.
  media: s5p-mfc: Add support for DMABUF for encoder
  media: s5p-mfc: Set context for valid case before calling try_run
  media: s5p-mfc: Load firmware for each run in MFCv12.
  media: s5p-mfc: DPB Count Independent of VIDIOC_REQBUF

 .../bindings/media/samsung,s5p-mfc.yaml       |  18 ++
 .../platform/samsung/s5p-mfc/regs-mfc-v12.h   |  52 +++
 .../platform/samsung/s5p-mfc/regs-mfc-v7.h    |   1 +
 .../platform/samsung/s5p-mfc/regs-mfc-v8.h    |   3 +
 .../media/platform/samsung/s5p-mfc/s5p_mfc.c  |  36 ++-
 .../platform/samsung/s5p-mfc/s5p_mfc_common.h |  33 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_ctrl.c   |  15 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_dec.c    |  60 +++-
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    | 149 ++++++---
 .../platform/samsung/s5p-mfc/s5p_mfc_opr.h    |  14 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c |  12 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 299 ++++++++++++++----
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h |   7 +-
 13 files changed, 550 insertions(+), 149 deletions(-)
 create mode 100644 drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h

-- 
2.17.1



From aakarsh.jain at samsung.com  Wed Dec 13 00:10:56 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:40:56 +0530
Subject: [Patch v6 01/10] dt-bindings: media: s5p-mfc: Add mfcv12 variant
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081115epcas5p395d6fd6fdcf7ce8e20c5b0aba400af12@epcas5p3.samsung.com>
Message-ID: <20231213081105.25817-2-aakarsh.jain@samsung.com>

Add Tesla FSD MFC(MFC v12) compatible.

Cc: linux-fsd at tesla.com
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/media/samsung,s5p-mfc.yaml        | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
index 084b44582a43..d66e51547482 100644
--- a/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
+++ b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
@@ -24,6 +24,7 @@ properties:
           - samsung,mfc-v7                # Exynos5420
           - samsung,mfc-v8                # Exynos5800
           - samsung,mfc-v10               # Exynos7880
+          - tesla,fsd-mfc                 # Tesla FSD
       - items:
           - enum:
               - samsung,exynos3250-mfc    # Exynos3250
@@ -165,6 +166,23 @@ allOf:
           minItems: 1
           maxItems: 2
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - tesla,fsd-mfc
+    then:
+      properties:
+        clocks:
+          maxItems: 1
+        clock-names:
+          items:
+            - const: mfc
+        iommus:
+          maxItems: 2
+        iommus-names: false
+
 examples:
   - |
     #include <dt-bindings/clock/exynos4.h>
-- 
2.17.1



From aakarsh.jain at samsung.com  Wed Dec 13 00:10:57 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:40:57 +0530
Subject: [Patch v6 02/10] media: s5p-mfc: Rename IS_MFCV10 macro
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081118epcas5p1bfa3f9790c9c48f1bac20c5683fed00d@epcas5p1.samsung.com>
Message-ID: <20231213081105.25817-3-aakarsh.jain@samsung.com>

Renames macro IS_MFCV10 to IS_MFCV10_PLUS so that the MFCv10 code can
be resued for MFCv12 support. Since some part of MFCv10 specific code
holds good for MFCv12 also.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>
---
 .../platform/samsung/s5p-mfc/s5p_mfc_common.h | 10 +++----
 .../platform/samsung/s5p-mfc/s5p_mfc_ctrl.c   |  2 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 28 +++++++++----------
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index 5304f42c8c72..2ae2f23c4741 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -771,11 +771,11 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq);
 #define HAS_PORTNUM(dev)	(dev ? (dev->variant ? \
 				(dev->variant->port_num ? 1 : 0) : 0) : 0)
 #define IS_TWOPORT(dev)		(dev->variant->port_num == 2 ? 1 : 0)
-#define IS_MFCV6_PLUS(dev)	(dev->variant->version >= 0x60 ? 1 : 0)
-#define IS_MFCV7_PLUS(dev)	(dev->variant->version >= 0x70 ? 1 : 0)
-#define IS_MFCV8_PLUS(dev)	(dev->variant->version >= 0x80 ? 1 : 0)
-#define IS_MFCV10(dev)		(dev->variant->version >= 0xA0 ? 1 : 0)
-#define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10(dev))
+#define IS_MFCV6_PLUS(dev)	((dev)->variant->version >= 0x60)
+#define IS_MFCV7_PLUS(dev)	((dev)->variant->version >= 0x70)
+#define IS_MFCV8_PLUS(dev)	((dev)->variant->version >= 0x80)
+#define IS_MFCV10_PLUS(dev)	((dev)->variant->version >= 0xA0)
+#define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10_PLUS(dev))
 
 #define MFC_V5_BIT	BIT(0)
 #define MFC_V6_BIT	BIT(1)
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
index 6d3c92045c05..54b54b2fa9b1 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
@@ -236,7 +236,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
 	else
 		mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
 
-	if (IS_MFCV10(dev))
+	if (IS_MFCV10_PLUS(dev))
 		mfc_write(dev, 0x0, S5P_FIMV_MFC_CLOCK_OFF_V10);
 
 	mfc_debug(2, "Will now wait for completion of firmware transfer\n");
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index c0df5ac9fcff..882166e4ac50 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -72,9 +72,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			  ctx->luma_size, ctx->chroma_size, ctx->mv_size);
 		mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
 	} else if (ctx->type == MFCINST_ENCODER) {
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev))
 			ctx->tmv_buffer_size = 0;
-		} else if (IS_MFCV8_PLUS(dev))
+		else if (IS_MFCV8_PLUS(dev))
 			ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
 			ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, mb_height),
 			S5P_FIMV_TMV_BUFFER_ALIGN_V6);
@@ -82,7 +82,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
 			ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
 			S5P_FIMV_TMV_BUFFER_ALIGN_V6);
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			lcu_width = S5P_MFC_LCU_WIDTH(ctx->img_width);
 			lcu_height = S5P_MFC_LCU_HEIGHT(ctx->img_height);
 			if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
@@ -133,7 +133,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 	switch (ctx->codec_mode) {
 	case S5P_MFC_CODEC_H264_DEC:
 	case S5P_MFC_CODEC_H264_MVC_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else if (IS_MFCV8_PLUS(dev))
 			ctx->scratch_buf_size =
@@ -152,7 +152,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			(ctx->mv_count * ctx->mv_size);
 		break;
 	case S5P_MFC_CODEC_MPEG4_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else if (IS_MFCV7_PLUS(dev)) {
 			ctx->scratch_buf_size =
@@ -172,7 +172,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		break;
 	case S5P_MFC_CODEC_VC1RCV_DEC:
 	case S5P_MFC_CODEC_VC1_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else
 			ctx->scratch_buf_size =
@@ -189,7 +189,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank2.size = 0;
 		break;
 	case S5P_MFC_CODEC_H263_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else
 			ctx->scratch_buf_size =
@@ -201,7 +201,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank1.size = ctx->scratch_buf_size;
 		break;
 	case S5P_MFC_CODEC_VP8_DEC:
-		if (IS_MFCV10(dev))
+		if (IS_MFCV10_PLUS(dev))
 			mfc_debug(2, "Use min scratch buffer size\n");
 		else if (IS_MFCV8_PLUS(dev))
 			ctx->scratch_buf_size =
@@ -230,7 +230,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			DEC_VP9_STATIC_BUFFER_SIZE;
 		break;
 	case S5P_MFC_CODEC_H264_ENC:
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 			ALIGN(ENC_V100_H264_ME_SIZE(mb_width, mb_height), 16);
@@ -254,7 +254,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		break;
 	case S5P_MFC_CODEC_MPEG4_ENC:
 	case S5P_MFC_CODEC_H263_ENC:
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 				ALIGN(ENC_V100_MPEG4_ME_SIZE(mb_width,
@@ -273,7 +273,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank2.size = 0;
 		break;
 	case S5P_MFC_CODEC_VP8_ENC:
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 				ALIGN(ENC_V100_VP8_ME_SIZE(mb_width, mb_height),
@@ -452,7 +452,7 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
 
 	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
 			ctx->codec_mode == S5P_MFC_CODEC_H264_MVC_DEC) {
-		if (IS_MFCV10(dev)) {
+		if (IS_MFCV10_PLUS(dev)) {
 			ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V10(ctx->img_width,
 					ctx->img_height);
 		} else {
@@ -668,7 +668,7 @@ static int s5p_mfc_set_enc_ref_buffer_v6(struct s5p_mfc_ctx *ctx)
 
 	mfc_debug(2, "Buf1: %p (%d)\n", (void *)buf_addr1, buf_size1);
 
-	if (IS_MFCV10(dev)) {
+	if (IS_MFCV10_PLUS(dev)) {
 		/* start address of per buffer is aligned */
 		for (i = 0; i < ctx->pb_count; i++) {
 			writel(buf_addr1, mfc_regs->e_luma_dpb + (4 * i));
@@ -2455,7 +2455,7 @@ const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev)
 	R(e_h264_options, S5P_FIMV_E_H264_OPTIONS_V8);
 	R(e_min_scratch_buffer_size, S5P_FIMV_E_MIN_SCRATCH_BUFFER_SIZE_V8);
 
-	if (!IS_MFCV10(dev))
+	if (!IS_MFCV10_PLUS(dev))
 		goto done;
 
 	/* Initialize registers used in MFC v10 only.
-- 
2.17.1



From aakarsh.jain at samsung.com  Wed Dec 13 00:10:58 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:40:58 +0530
Subject: [Patch v6 03/10] media: s5p-mfc: Add initial support for MFCv12
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081121epcas5p1db0ef76c8ae06a2d1b195153c67acbb6@epcas5p1.samsung.com>
Message-ID: <20231213081105.25817-4-aakarsh.jain@samsung.com>

Add support for MFCv12, with a new register file and necessary hw
control, decoder, encoder and structural changes. Add luma dbp, chroma
dpb and mv sizes for each codec as per the UM for MFCv12, along with
appropriate alignment.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../platform/samsung/s5p-mfc/regs-mfc-v12.h   | 50 +++++++++++
 .../media/platform/samsung/s5p-mfc/s5p_mfc.c  | 30 +++++++
 .../platform/samsung/s5p-mfc/s5p_mfc_common.h | 17 +++-
 .../platform/samsung/s5p-mfc/s5p_mfc_ctrl.c   |  2 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_dec.c    |  6 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    |  5 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr.h    |  8 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 83 +++++++++++++++----
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h |  6 +-
 9 files changed, 172 insertions(+), 35 deletions(-)
 create mode 100644 drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h

diff --git a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
new file mode 100644
index 000000000000..d987bba1ffbd
--- /dev/null
+++ b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Register definition file for Samsung MFC V12.x Interface (FIMV) driver
+ *
+ * Copyright (c) 2020 Samsung Electronics Co., Ltd.
+ *     http://www.samsung.com/
+ */
+
+#ifndef _REGS_MFC_V12_H
+#define _REGS_MFC_V12_H
+
+#include <linux/sizes.h>
+#include "regs-mfc-v10.h"
+
+/* MFCv12 Context buffer sizes */
+#define MFC_CTX_BUF_SIZE_V12		(30 * SZ_1K)
+#define MFC_H264_DEC_CTX_BUF_SIZE_V12	(2 * SZ_1M)
+#define MFC_OTHER_DEC_CTX_BUF_SIZE_V12	(30 * SZ_1K)
+#define MFC_H264_ENC_CTX_BUF_SIZE_V12	(100 * SZ_1K)
+#define MFC_HEVC_ENC_CTX_BUF_SIZE_V12	(40 * SZ_1K)
+#define MFC_OTHER_ENC_CTX_BUF_SIZE_V12	(25 * SZ_1K)
+
+/* MFCv12 variant defines */
+#define MAX_FW_SIZE_V12			(SZ_1M)
+#define MAX_CPB_SIZE_V12		(7 * SZ_1M)
+#define MFC_VERSION_V12			0xC0
+#define MFC_NUM_PORTS_V12		1
+#define S5P_FIMV_CODEC_VP9_ENC		27
+
+/* Encoder buffer size for MFCv12 */
+#define ENC_V120_BASE_SIZE(x, y) \
+	((((x) + 3) * ((y) + 3) * 8) \
+	+ ((((y) * 64) + 2304) * ((x) + 7) / 8))
+
+#define ENC_V120_H264_ME_SIZE(x, y) \
+	ALIGN((ENC_V120_BASE_SIZE(x, y) \
+	+ (DIV_ROUND_UP((x) * (y), 64) * 32)), 256)
+
+#define ENC_V120_MPEG4_ME_SIZE(x, y) \
+	ALIGN((ENC_V120_BASE_SIZE(x, y) \
+	+ (DIV_ROUND_UP((x) * (y), 128) * 16)), 256)
+
+#define ENC_V120_VP8_ME_SIZE(x, y) \
+	ALIGN(ENC_V120_BASE_SIZE((x), (y)), 256)
+
+#define ENC_V120_HEVC_ME_SIZE(x, y)     \
+	ALIGN(((((x) + 3) * ((y) + 3) * 32)       \
+	+ ((((y) * 128) + 2304) * ((x) + 3) / 4)), 256)
+
+#endif /*_REGS_MFC_V12_H*/
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index e30e54935d79..dee9ef017997 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -790,6 +790,8 @@ static int s5p_mfc_open(struct file *file)
 	INIT_LIST_HEAD(&ctx->dst_queue);
 	ctx->src_queue_cnt = 0;
 	ctx->dst_queue_cnt = 0;
+	ctx->is_422 = 0;
+	ctx->is_10bit = 0;
 	/* Get context number */
 	ctx->num = 0;
 	while (dev->ctx[ctx->num]) {
@@ -1660,6 +1662,31 @@ static struct s5p_mfc_variant mfc_drvdata_v10 = {
 	.fw_name[0]     = "s5p-mfc-v10.fw",
 };
 
+static struct s5p_mfc_buf_size_v6 mfc_buf_size_v12 = {
+	.dev_ctx        = MFC_CTX_BUF_SIZE_V12,
+	.h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V12,
+	.other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V12,
+	.h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V12,
+	.hevc_enc_ctx   = MFC_HEVC_ENC_CTX_BUF_SIZE_V12,
+	.other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V12,
+};
+
+static struct s5p_mfc_buf_size buf_size_v12 = {
+	.fw     = MAX_FW_SIZE_V12,
+	.cpb    = MAX_CPB_SIZE_V12,
+	.priv   = &mfc_buf_size_v12,
+};
+
+static struct s5p_mfc_variant mfc_drvdata_v12 = {
+	.version        = MFC_VERSION_V12,
+	.version_bit    = MFC_V12_BIT,
+	.port_num       = MFC_NUM_PORTS_V12,
+	.buf_size       = &buf_size_v12,
+	.fw_name[0]     = "s5p-mfc-v12.fw",
+	.clk_names	= {"mfc"},
+	.num_clocks	= 1,
+};
+
 static const struct of_device_id exynos_mfc_match[] = {
 	{
 		.compatible = "samsung,mfc-v5",
@@ -1682,6 +1709,9 @@ static const struct of_device_id exynos_mfc_match[] = {
 	}, {
 		.compatible = "samsung,mfc-v10",
 		.data = &mfc_drvdata_v10,
+	}, {
+		.compatible = "tesla,fsd-mfc",
+		.data = &mfc_drvdata_v12,
 	},
 	{},
 };
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index 2ae2f23c4741..aa87b3404b33 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -19,7 +19,7 @@
 #include <media/v4l2-ioctl.h>
 #include <media/videobuf2-v4l2.h>
 #include "regs-mfc.h"
-#include "regs-mfc-v10.h"
+#include "regs-mfc-v12.h"
 
 #define S5P_MFC_NAME		"s5p-mfc"
 
@@ -621,6 +621,8 @@ struct s5p_mfc_codec_ops {
  *			v4l2 control framework
  * @ctrl_handler:	handler for v4l2 framework
  * @scratch_buf_size:	scratch buffer size
+ * @is_10bit:		state to check 10bit support
+ * @is_422:		state to check YUV422 10bit format
  */
 struct s5p_mfc_ctx {
 	struct s5p_mfc_dev *dev;
@@ -720,6 +722,8 @@ struct s5p_mfc_ctx {
 	struct v4l2_ctrl *ctrls[MFC_MAX_CTRLS];
 	struct v4l2_ctrl_handler ctrl_handler;
 	size_t scratch_buf_size;
+	int is_10bit;
+	int is_422;
 };
 
 /*
@@ -775,6 +779,7 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq);
 #define IS_MFCV7_PLUS(dev)	((dev)->variant->version >= 0x70)
 #define IS_MFCV8_PLUS(dev)	((dev)->variant->version >= 0x80)
 #define IS_MFCV10_PLUS(dev)	((dev)->variant->version >= 0xA0)
+#define IS_MFCV12(dev)		((dev)->variant->version >= 0xC0)
 #define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10_PLUS(dev))
 
 #define MFC_V5_BIT	BIT(0)
@@ -782,11 +787,15 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq);
 #define MFC_V7_BIT	BIT(2)
 #define MFC_V8_BIT	BIT(3)
 #define MFC_V10_BIT	BIT(5)
+#define MFC_V12_BIT	BIT(7)
 
 #define MFC_V5PLUS_BITS		(MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT | \
-					MFC_V8_BIT | MFC_V10_BIT)
+					MFC_V8_BIT | MFC_V10_BIT | MFC_V12_BIT)
 #define MFC_V6PLUS_BITS		(MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT | \
-					MFC_V10_BIT)
-#define MFC_V7PLUS_BITS		(MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT)
+					MFC_V10_BIT | MFC_V12_BIT)
+#define MFC_V7PLUS_BITS		(MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT | \
+					MFC_V12_BIT)
+
+#define MFC_V10PLUS_BITS	(MFC_V10_BIT | MFC_V12_BIT)
 
 #endif /* S5P_MFC_COMMON_H_ */
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
index 54b54b2fa9b1..b49159142c53 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
@@ -130,7 +130,7 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
 			mfc_write(dev, 0, S5P_FIMV_REG_CLEAR_BEGIN_V6 + (i*4));
 
 		/* check bus reset control before reset */
-		if (dev->risc_on)
+		if (dev->risc_on && !IS_MFCV12(dev))
 			if (s5p_mfc_bus_reset(dev))
 				return -EIO;
 		/* Reset
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
index 268ffe4da53c..e219cbcd86d5 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
@@ -146,7 +146,7 @@ static struct s5p_mfc_fmt formats[] = {
 		.codec_mode	= S5P_FIMV_CODEC_HEVC_DEC,
 		.type		= MFC_FMT_DEC,
 		.num_planes	= 1,
-		.versions	= MFC_V10_BIT,
+		.versions	= MFC_V10PLUS_BITS,
 		.flags		= V4L2_FMT_FLAG_DYN_RESOLUTION |
 				  V4L2_FMT_FLAG_CONTINUOUS_BYTESTREAM,
 	},
@@ -155,7 +155,7 @@ static struct s5p_mfc_fmt formats[] = {
 		.codec_mode	= S5P_FIMV_CODEC_VP9_DEC,
 		.type		= MFC_FMT_DEC,
 		.num_planes	= 1,
-		.versions	= MFC_V10_BIT,
+		.versions	= MFC_V10PLUS_BITS,
 		.flags		= V4L2_FMT_FLAG_DYN_RESOLUTION,
 	},
 };
@@ -355,7 +355,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 		pix_mp->width = ctx->buf_width;
 		pix_mp->height = ctx->buf_height;
 		pix_mp->field = V4L2_FIELD_NONE;
-		pix_mp->num_planes = 2;
+		pix_mp->num_planes = ctx->dst_fmt->num_planes;
 		/* Set pixelformat to the format in which MFC
 		   outputs the decoded frame */
 		pix_mp->pixelformat = ctx->dst_fmt->fourcc;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index 4b4c129c09e7..d518e329ffbb 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -92,7 +92,7 @@ static struct s5p_mfc_fmt formats[] = {
 		.codec_mode	= S5P_FIMV_CODEC_HEVC_ENC,
 		.type		= MFC_FMT_ENC,
 		.num_planes	= 1,
-		.versions	= MFC_V10_BIT,
+		.versions	= MFC_V10PLUS_BITS,
 	},
 };
 
@@ -1179,7 +1179,8 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
 		if (FW_HAS_E_MIN_SCRATCH_BUF(dev)) {
 			ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
 					get_e_min_scratch_buf_size, dev);
-			ctx->bank1.size += ctx->scratch_buf_size;
+			if (!IS_MFCV12(dev))
+				ctx->bank1.size += ctx->scratch_buf_size;
 		}
 		ctx->state = MFCINST_HEAD_PRODUCED;
 	}
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
index b9831275f3ab..87ac56756a16 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
@@ -166,9 +166,9 @@ struct s5p_mfc_regs {
 	void __iomem *d_decoded_third_addr;/* only v7 */
 	void __iomem *d_used_dpb_flag_upper;/* v7 and v8 */
 	void __iomem *d_used_dpb_flag_lower;/* v7 and v8 */
-	void __iomem *d_min_scratch_buffer_size; /* v10 */
-	void __iomem *d_static_buffer_addr; /* v10 */
-	void __iomem *d_static_buffer_size; /* v10 */
+	void __iomem *d_min_scratch_buffer_size; /* v10 and v12 */
+	void __iomem *d_static_buffer_addr; /* v10 and v12 */
+	void __iomem *d_static_buffer_size; /* v10 and v12 */
 
 	/* encoder registers */
 	void __iomem *e_frame_width;
@@ -268,7 +268,7 @@ struct s5p_mfc_regs {
 	void __iomem *e_vp8_hierarchical_qp_layer0;/* v7 and v8 */
 	void __iomem *e_vp8_hierarchical_qp_layer1;/* v7 and v8 */
 	void __iomem *e_vp8_hierarchical_qp_layer2;/* v7 and v8 */
-	void __iomem *e_min_scratch_buffer_size; /* v10 */
+	void __iomem *e_min_scratch_buffer_size; /* v10 and v12 */
 	void __iomem *e_num_t_layer; /* v10 */
 	void __iomem *e_hier_qp_layer0; /* v10 */
 	void __iomem *e_hier_bit_rate_layer0; /* v10 */
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 882166e4ac50..a49aa6c1e30b 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -60,12 +60,14 @@ static void s5p_mfc_release_dec_desc_buffer_v6(struct s5p_mfc_ctx *ctx)
 static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	unsigned int mb_width, mb_height;
+	unsigned int mb_width, mb_height, width64, height32;
 	unsigned int lcu_width = 0, lcu_height = 0;
 	int ret;
 
 	mb_width = MB_WIDTH(ctx->img_width);
 	mb_height = MB_HEIGHT(ctx->img_height);
+	width64 = ALIGN(ctx->img_width, 64);
+	height32 = ALIGN(ctx->img_height, 32);
 
 	if (ctx->type == MFCINST_DECODER) {
 		mfc_debug(2, "Luma size:%d Chroma size:%d MV size:%d\n",
@@ -82,7 +84,39 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
 			ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
 			S5P_FIMV_TMV_BUFFER_ALIGN_V6);
-		if (IS_MFCV10_PLUS(dev)) {
+		if (IS_MFCV12(dev)) {
+			lcu_width = S5P_MFC_LCU_WIDTH(ctx->img_width);
+			lcu_height = S5P_MFC_LCU_HEIGHT(ctx->img_height);
+			if (ctx->codec_mode == S5P_FIMV_CODEC_HEVC_ENC && ctx->is_10bit) {
+				ctx->luma_dpb_size =
+					width64 * height32 +
+					ALIGN(DIV_ROUND_UP(lcu_width * 32, 4), 16) * height32 + 128;
+				if (ctx->is_422)
+					ctx->chroma_dpb_size =
+						ctx->luma_dpb_size;
+				else
+					ctx->chroma_dpb_size =
+						width64 * height32 / 2 +
+						ALIGN(DIV_ROUND_UP(lcu_width *
+							32, 4), 16) * height32 / 2 + 128;
+			} else if (ctx->codec_mode == S5P_FIMV_CODEC_VP9_ENC &&	ctx->is_10bit) {
+				ctx->luma_dpb_size =
+					ALIGN(ctx->img_width * 2, 128) * height32 + 64;
+				ctx->chroma_dpb_size =
+					ALIGN(ctx->img_width * 2, 128) * height32 / 2 + 64;
+			} else {
+				ctx->luma_dpb_size =
+					width64 * height32 + 64;
+				if (ctx->is_422)
+					ctx->chroma_dpb_size =
+						ctx->luma_dpb_size;
+				else
+					ctx->chroma_dpb_size =
+						width64 * height32 / 2 + 64;
+			}
+			ctx->luma_dpb_size = ALIGN(ctx->luma_dpb_size + 256, SZ_2K);
+			ctx->chroma_dpb_size = ALIGN(ctx->chroma_dpb_size + 256, SZ_2K);
+		} else if (IS_MFCV10_PLUS(dev)) {
 			lcu_width = S5P_MFC_LCU_WIDTH(ctx->img_width);
 			lcu_height = S5P_MFC_LCU_HEIGHT(ctx->img_height);
 			if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
@@ -230,7 +264,11 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 			DEC_VP9_STATIC_BUFFER_SIZE;
 		break;
 	case S5P_MFC_CODEC_H264_ENC:
-		if (IS_MFCV10_PLUS(dev)) {
+		if (IS_MFCV12(dev)) {
+			mfc_debug(2, "Use min scratch buffer size\n");
+			ctx->me_buffer_size =
+				ENC_V120_H264_ME_SIZE(mb_width, mb_height);
+		} else if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 			ALIGN(ENC_V100_H264_ME_SIZE(mb_width, mb_height), 16);
@@ -254,7 +292,11 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		break;
 	case S5P_MFC_CODEC_MPEG4_ENC:
 	case S5P_MFC_CODEC_H263_ENC:
-		if (IS_MFCV10_PLUS(dev)) {
+		if (IS_MFCV12(dev)) {
+			mfc_debug(2, "Use min scratch buffer size\n");
+			ctx->me_buffer_size =
+				ENC_V120_MPEG4_ME_SIZE(mb_width, mb_height);
+		} else if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 				ALIGN(ENC_V100_MPEG4_ME_SIZE(mb_width,
@@ -265,7 +307,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 						mb_width,
 						mb_height);
 		ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size,
-				S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);
+					S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);
 		ctx->bank1.size =
 			ctx->scratch_buf_size + ctx->tmv_buffer_size +
 			(ctx->pb_count * (ctx->luma_dpb_size +
@@ -273,7 +315,11 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank2.size = 0;
 		break;
 	case S5P_MFC_CODEC_VP8_ENC:
-		if (IS_MFCV10_PLUS(dev)) {
+		if (IS_MFCV12(dev)) {
+			mfc_debug(2, "Use min scratch buffer size\n");
+			ctx->me_buffer_size =
+				ENC_V120_VP8_ME_SIZE(mb_width, mb_height);
+		} else if (IS_MFCV10_PLUS(dev)) {
 			mfc_debug(2, "Use min scratch buffer size\n");
 			ctx->me_buffer_size =
 				ALIGN(ENC_V100_VP8_ME_SIZE(mb_width, mb_height),
@@ -297,9 +343,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 		ctx->bank2.size = 0;
 		break;
 	case S5P_MFC_CODEC_HEVC_ENC:
+		if (IS_MFCV12(dev))
+			ctx->me_buffer_size =
+				ENC_V120_HEVC_ME_SIZE(lcu_width, lcu_height);
+		else
+			ctx->me_buffer_size =
+				ALIGN(ENC_V100_HEVC_ME_SIZE(lcu_width, lcu_height), 16);
 		mfc_debug(2, "Use min scratch buffer size\n");
-		ctx->me_buffer_size =
-			ALIGN(ENC_V100_HEVC_ME_SIZE(lcu_width, lcu_height), 16);
 		ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size, 256);
 		ctx->bank1.size =
 			ctx->scratch_buf_size + ctx->tmv_buffer_size +
@@ -452,16 +502,15 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
 
 	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
 			ctx->codec_mode == S5P_MFC_CODEC_H264_MVC_DEC) {
-		if (IS_MFCV10_PLUS(dev)) {
-			ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V10(ctx->img_width,
-					ctx->img_height);
-		} else {
-			ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V6(ctx->img_width,
-					ctx->img_height);
-		}
+		if (IS_MFCV12(dev))
+			ctx->mv_size = S5P_MFC_DEC_MV_SIZE(ctx->img_width, ctx->img_height, 1024);
+		else if (IS_MFCV10_PLUS(dev))
+			ctx->mv_size = S5P_MFC_DEC_MV_SIZE(ctx->img_width, ctx->img_height, 512);
+		else
+			ctx->mv_size = S5P_MFC_DEC_MV_SIZE(ctx->img_width, ctx->img_height, 128);
+
 	} else if (ctx->codec_mode == S5P_MFC_CODEC_HEVC_DEC) {
-		ctx->mv_size = s5p_mfc_dec_hevc_mv_size(ctx->img_width,
-				ctx->img_height);
+		ctx->mv_size = s5p_mfc_dec_hevc_mv_size(ctx->img_width, ctx->img_height);
 		ctx->mv_size = ALIGN(ctx->mv_size, 32);
 	} else {
 		ctx->mv_size = 0;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
index e4dd03c5454c..ff582eea4217 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
@@ -19,10 +19,8 @@
 
 #define MB_WIDTH(x_size)		DIV_ROUND_UP(x_size, 16)
 #define MB_HEIGHT(y_size)		DIV_ROUND_UP(y_size, 16)
-#define S5P_MFC_DEC_MV_SIZE_V6(x, y)	(MB_WIDTH(x) * \
-					(((MB_HEIGHT(y)+1)/2)*2) * 64 + 128)
-#define S5P_MFC_DEC_MV_SIZE_V10(x, y)	(MB_WIDTH(x) * \
-					(((MB_HEIGHT(y)+1)/2)*2) * 64 + 512)
+#define S5P_MFC_DEC_MV_SIZE(x, y, offset)	(MB_WIDTH(x) * \
+					(((MB_HEIGHT(y) + 1) / 2) * 2) * 64 + (offset))
 #define S5P_MFC_LCU_WIDTH(x_size)	DIV_ROUND_UP(x_size, 32)
 #define S5P_MFC_LCU_HEIGHT(y_size)	DIV_ROUND_UP(y_size, 32)
 
-- 
2.17.1



From angelogioacchino.delregno at collabora.com  Wed Dec 13 02:59:53 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 13 Dec 2023 11:59:53 +0100
Subject: [PATCH V4 1/2] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231213103642.15320-2-quic_mnaresh@quicinc.com>
References: <20231213103642.15320-1-quic_mnaresh@quicinc.com>
 <20231213103642.15320-2-quic_mnaresh@quicinc.com>
Message-ID: <ecf4d4f8-8232-44bc-b1a0-c6bd4b579949@collabora.com>

Il 13/12/23 11:36, Maramaina Naresh ha scritto:
> Register ufs driver to CPU latency PM QoS framework to improve
> ufs device random io performance.
> 
> PM QoS initialization will insert new QoS request into the CPU
> latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
> value.
> 
> UFS driver will vote for performance mode on scale up and power
> save mode for scale down.
> 
> If clock scaling feature is not enabled then voting will be based
> on clock on or off condition.
> 
> Provided sysfs interface to enable/disable PM QoS feature.
> 
> tiotest benchmark tool io performance results on sm8550 platform:
> 
> 1. Without PM QoS support
> 	Type (Speed in)    | Average of 18 iterations
> 	Random Write(IPOS) | 41065.13
> 	Random Read(IPOS)  | 37101.3
> 
> 2. With PM QoS support
> 	Type (Speed in)    | Average of 18 iterations
> 	Random Write(IPOS) | 46784.9
> 	Random Read(IPOS)  | 42943.4
> (Improvement with PM QoS = ~15%).
> 
> Co-developed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
> Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
> Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall at quicinc.com>
> Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
> ---
>   drivers/ufs/core/ufshcd.c | 127 ++++++++++++++++++++++++++++++++++++++
>   include/ufs/ufshcd.h      |   6 ++
>   2 files changed, 133 insertions(+)
> 
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index ae9936fc6ffb..7318fa480706 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -1001,6 +1001,20 @@ static bool ufshcd_is_unipro_pa_params_tuning_req(struct ufs_hba *hba)
>   	return ufshcd_get_local_unipro_ver(hba) < UFS_UNIPRO_VER_1_6;
>   }
>   
> +/**
> + * ufshcd_pm_qos_update - update PM QoS request
> + * @hba: per adapter instance
> + * @on: If True, vote for perf PM QoS mode otherwise power save mode
> + */
> +static void ufshcd_pm_qos_update(struct ufs_hba *hba, bool on)
> +{
> +	if (!hba->pm_qos_enabled)
> +		return;
> +
> +	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? 0
> +							: PM_QOS_DEFAULT_VALUE);

This fits in one line.

> +}
> +
>   /**
>    * ufshcd_set_clk_freq - set UFS controller clock frequencies
>    * @hba: per adapter instance
> @@ -1147,8 +1161,11 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, unsigned long freq,
>   					    hba->devfreq->previous_freq);
>   		else
>   			ufshcd_set_clk_freq(hba, !scale_up);
> +		goto out;
>   	}
>   
> +	ufshcd_pm_qos_update(hba, scale_up);
> +
>   out:
>   	trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
>   			(scale_up ? "up" : "down"),
> @@ -8615,6 +8632,109 @@ static void ufshcd_set_timestamp_attr(struct ufs_hba *hba)
>   	ufshcd_release(hba);
>   }
>   
> +/**
> + * ufshcd_pm_qos_init - initialize PM QoS request
> + * @hba: per adapter instance
> + */
> +static void ufshcd_pm_qos_init(struct ufs_hba *hba)
> +{
> +
> +	if (hba->pm_qos_enabled)
> +		return;
> +
> +	cpu_latency_qos_add_request(&hba->pm_qos_req,
> +					PM_QOS_DEFAULT_VALUE);

same here.

> +
> +	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
> +		hba->pm_qos_enabled = true;
> +}
> +

Apart from that,

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Wed Dec 13 02:59:55 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 13 Dec 2023 11:59:55 +0100
Subject: [PATCH V4 2/2] ufs: ufs-mediatek: Enable CPU latency PM QoS
 support for MEDIATEK SoC
In-Reply-To: <20231213103642.15320-3-quic_mnaresh@quicinc.com>
References: <20231213103642.15320-1-quic_mnaresh@quicinc.com>
 <20231213103642.15320-3-quic_mnaresh@quicinc.com>
Message-ID: <84446493-2c3f-45b7-9d77-54a77e753d16@collabora.com>

Il 13/12/23 11:36, Maramaina Naresh ha scritto:
> Revert the existing PM QoS feature from MEDIATEK UFS driver as similar
> PM QoS feature implementation is moved to core ufshcd.
> 
> Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>

IMO, title and description should say:

ufs: ufs-mediatek: Migrate to UFSHCD generic CPU latency PM QoS support

The PM QoS feature found in the MediaTek UFS driver was moved to the UFSHCD
core: remove it from here as it's now redundant.

with that fixed:

Reviewed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From aakarsh.jain at samsung.com  Wed Dec 13 00:10:59 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:40:59 +0530
Subject: [Patch v6 04/10] media: s5p-mfc: Add YV12 and I420 multiplanar
 format support
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081127epcas5p2555e322569ac3a239f097330d1450cf8@epcas5p2.samsung.com>
Message-ID: <20231213081105.25817-5-aakarsh.jain@samsung.com>

YV12 and I420 format (3-plane) support is added. Stride information is
added to all formats and planes since it is necessary for YV12/I420
which are different from width.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../platform/samsung/s5p-mfc/regs-mfc-v12.h   |   2 +
 .../platform/samsung/s5p-mfc/regs-mfc-v7.h    |   1 +
 .../platform/samsung/s5p-mfc/regs-mfc-v8.h    |   3 +
 .../platform/samsung/s5p-mfc/s5p_mfc_common.h |   6 +
 .../platform/samsung/s5p-mfc/s5p_mfc_dec.c    |  54 +++++-
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    |  98 +++++++++--
 .../platform/samsung/s5p-mfc/s5p_mfc_opr.h    |   6 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c |  12 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 157 ++++++++++++++----
 9 files changed, 276 insertions(+), 63 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
index d987bba1ffbd..24e669d8ea29 100644
--- a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
+++ b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
@@ -26,6 +26,8 @@
 #define MFC_VERSION_V12			0xC0
 #define MFC_NUM_PORTS_V12		1
 #define S5P_FIMV_CODEC_VP9_ENC		27
+#define MFC_CHROMA_PAD_BYTES_V12        256
+#define S5P_FIMV_D_ALIGN_PLANE_SIZE_V12 256
 
 /* Encoder buffer size for MFCv12 */
 #define ENC_V120_BASE_SIZE(x, y) \
diff --git a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v7.h b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v7.h
index 4a7adfdaa359..50f9bf0603c1 100644
--- a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v7.h
+++ b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v7.h
@@ -24,6 +24,7 @@
 
 #define S5P_FIMV_E_ENCODED_SOURCE_FIRST_ADDR_V7		0xfa70
 #define S5P_FIMV_E_ENCODED_SOURCE_SECOND_ADDR_V7	0xfa74
+#define S5P_FIMV_E_ENCODED_SOURCE_THIRD_ADDR_V7		0xfa78
 
 #define S5P_FIMV_E_VP8_OPTIONS_V7			0xfdb0
 #define S5P_FIMV_E_VP8_FILTER_OPTIONS_V7		0xfdb4
diff --git a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v8.h b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v8.h
index 162e3c7e920f..0ef9eb2dff22 100644
--- a/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v8.h
+++ b/drivers/media/platform/samsung/s5p-mfc/regs-mfc-v8.h
@@ -17,13 +17,16 @@
 #define S5P_FIMV_D_MIN_SCRATCH_BUFFER_SIZE_V8	0xf108
 #define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8	0xf144
 #define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V8	0xf148
+#define S5P_FIMV_D_THIRD_PLANE_DPB_SIZE_V8	0xf14C
 #define S5P_FIMV_D_MV_BUFFER_SIZE_V8		0xf150
 
 #define S5P_FIMV_D_FIRST_PLANE_DPB_STRIDE_SIZE_V8	0xf138
 #define S5P_FIMV_D_SECOND_PLANE_DPB_STRIDE_SIZE_V8	0xf13c
+#define S5P_FIMV_D_THIRD_PLANE_DPB_STRIDE_SIZE_V8	0xf140
 
 #define S5P_FIMV_D_FIRST_PLANE_DPB_V8		0xf160
 #define S5P_FIMV_D_SECOND_PLANE_DPB_V8		0xf260
+#define S5P_FIMV_D_THIRD_PLANE_DPB_V8		0xf360
 #define S5P_FIMV_D_MV_BUFFER_V8			0xf460
 
 #define S5P_FIMV_D_NUM_MV_V8			0xf134
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index aa87b3404b33..59450b324f7d 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -56,6 +56,7 @@
 #define MFC_NO_INSTANCE_SET	-1
 #define MFC_ENC_CAP_PLANE_COUNT	1
 #define MFC_ENC_OUT_PLANE_COUNT	2
+#define VB2_MAX_PLANE_COUNT	3
 #define STUFF_BYTE		4
 #define MFC_MAX_CTRLS		128
 
@@ -181,6 +182,7 @@ struct s5p_mfc_buf {
 		struct {
 			size_t luma;
 			size_t chroma;
+			size_t chroma_1;
 		} raw;
 		size_t stream;
 	} cookie;
@@ -623,6 +625,8 @@ struct s5p_mfc_codec_ops {
  * @scratch_buf_size:	scratch buffer size
  * @is_10bit:		state to check 10bit support
  * @is_422:		state to check YUV422 10bit format
+ * @chroma_size_1:	size of a chroma third plane
+ * @stride:		size of stride for all planes
  */
 struct s5p_mfc_ctx {
 	struct s5p_mfc_dev *dev;
@@ -659,6 +663,7 @@ struct s5p_mfc_ctx {
 
 	int luma_size;
 	int chroma_size;
+	int chroma_size_1;
 	int mv_size;
 
 	unsigned long consumed_stream;
@@ -724,6 +729,7 @@ struct s5p_mfc_ctx {
 	size_t scratch_buf_size;
 	int is_10bit;
 	int is_422;
+	int stride[VB2_MAX_PLANE_COUNT];
 };
 
 /*
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
index e219cbcd86d5..3957f28d4547 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
@@ -56,6 +56,20 @@ static struct s5p_mfc_fmt formats[] = {
 		.num_planes	= 2,
 		.versions	= MFC_V6PLUS_BITS,
 	},
+	{
+		.fourcc         = V4L2_PIX_FMT_YUV420M,
+		.codec_mode     = S5P_MFC_CODEC_NONE,
+		.type           = MFC_FMT_RAW,
+		.num_planes     = 3,
+		.versions       = MFC_V12_BIT,
+	},
+	{
+		.fourcc         = V4L2_PIX_FMT_YVU420M,
+		.codec_mode     = S5P_MFC_CODEC_NONE,
+		.type           = MFC_FMT_RAW,
+		.num_planes     = 3,
+		.versions       = MFC_V12_BIT
+	},
 	{
 		.fourcc		= V4L2_PIX_FMT_H264,
 		.codec_mode	= S5P_MFC_CODEC_H264_DEC,
@@ -359,10 +373,15 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 		/* Set pixelformat to the format in which MFC
 		   outputs the decoded frame */
 		pix_mp->pixelformat = ctx->dst_fmt->fourcc;
-		pix_mp->plane_fmt[0].bytesperline = ctx->buf_width;
+		pix_mp->plane_fmt[0].bytesperline = ctx->stride[0];
 		pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
-		pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
+		pix_mp->plane_fmt[1].bytesperline = ctx->stride[1];
 		pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			pix_mp->plane_fmt[2].bytesperline = ctx->stride[2];
+			pix_mp->plane_fmt[2].sizeimage = ctx->chroma_size_1;
+		}
 	} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 		/* This is run on OUTPUT
 		   The buffer contains compressed image
@@ -920,6 +939,7 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
 {
 	struct s5p_mfc_ctx *ctx = fh_to_ctx(vq->drv_priv);
 	struct s5p_mfc_dev *dev = ctx->dev;
+	const struct v4l2_format_info *format;
 
 	/* Video output for decoding (source)
 	 * this can be set after getting an instance */
@@ -936,7 +956,13 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
 	} else if (ctx->state == MFCINST_HEAD_PARSED &&
 		   vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 		/* Output plane count is 2 - one for Y and one for CbCr */
-		*plane_count = 2;
+		format = v4l2_format_info(ctx->dst_fmt->fourcc);
+		if (!format) {
+			mfc_err("invalid format\n");
+			return -EINVAL;
+		}
+		*plane_count = format->comp_planes;
+
 		/* Setup buffer count */
 		if (*buf_count < ctx->pb_count)
 			*buf_count = ctx->pb_count;
@@ -955,14 +981,18 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
 	    vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 		psize[0] = ctx->luma_size;
 		psize[1] = ctx->chroma_size;
-
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			psize[2] = ctx->chroma_size_1;
 		if (IS_MFCV6_PLUS(dev))
 			alloc_devs[0] = ctx->dev->mem_dev[BANK_L_CTX];
 		else
 			alloc_devs[0] = ctx->dev->mem_dev[BANK_R_CTX];
 		alloc_devs[1] = ctx->dev->mem_dev[BANK_L_CTX];
-	} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE &&
-		   ctx->state == MFCINST_INIT) {
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			alloc_devs[2] = ctx->dev->mem_dev[BANK_L_CTX];
+	} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && ctx->state == MFCINST_INIT) {
 		psize[0] = ctx->dec_src_buf_size;
 		alloc_devs[0] = ctx->dev->mem_dev[BANK_L_CTX];
 	} else {
@@ -994,12 +1024,24 @@ static int s5p_mfc_buf_init(struct vb2_buffer *vb)
 			mfc_err("Plane buffer (CAPTURE) is too small\n");
 			return -EINVAL;
 		}
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			if (vb2_plane_size(vb, 2) < ctx->chroma_size_1) {
+				mfc_err("Plane buffer (CAPTURE) is too small\n");
+				return -EINVAL;
+			}
+		}
 		i = vb->index;
 		ctx->dst_bufs[i].b = vbuf;
 		ctx->dst_bufs[i].cookie.raw.luma =
 					vb2_dma_contig_plane_dma_addr(vb, 0);
 		ctx->dst_bufs[i].cookie.raw.chroma =
 					vb2_dma_contig_plane_dma_addr(vb, 1);
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			ctx->dst_bufs[i].cookie.raw.chroma_1 =
+					vb2_dma_contig_plane_dma_addr(vb, 2);
+		}
 		ctx->dst_bufs_cnt++;
 	} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 		if (IS_ERR_OR_NULL(ERR_PTR(
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index d518e329ffbb..2f11a1e861e1 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -59,6 +59,20 @@ static struct s5p_mfc_fmt formats[] = {
 		.num_planes	= 2,
 		.versions	= MFC_V6PLUS_BITS,
 	},
+	{
+		.fourcc         = V4L2_PIX_FMT_YUV420M,
+		.codec_mode     = S5P_MFC_CODEC_NONE,
+		.type           = MFC_FMT_RAW,
+		.num_planes     = 3,
+		.versions       = MFC_V12_BIT,
+	},
+	{
+		.fourcc         = V4L2_PIX_FMT_YVU420M,
+		.codec_mode     = S5P_MFC_CODEC_NONE,
+		.type           = MFC_FMT_RAW,
+		.num_planes     = 3,
+		.versions       = MFC_V12_BIT,
+	},
 	{
 		.fourcc		= V4L2_PIX_FMT_H264,
 		.codec_mode	= S5P_MFC_CODEC_H264_ENC,
@@ -1193,14 +1207,20 @@ static int enc_pre_frame_start(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	struct s5p_mfc_buf *dst_mb;
 	struct s5p_mfc_buf *src_mb;
-	unsigned long src_y_addr, src_c_addr, dst_addr;
+	unsigned long src_y_addr, src_c_addr, src_c_1_addr, dst_addr;
 	unsigned int dst_size;
 
 	src_mb = list_entry(ctx->src_queue.next, struct s5p_mfc_buf, list);
 	src_y_addr = vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 0);
 	src_c_addr = vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 1);
+	if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+			V4L2_PIX_FMT_YVU420M)
+		src_c_1_addr =
+			vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 2);
+	else
+		src_c_1_addr = 0;
 	s5p_mfc_hw_call(dev->mfc_ops, set_enc_frame_buffer, ctx,
-							src_y_addr, src_c_addr);
+					src_y_addr, src_c_addr, src_c_1_addr);
 
 	dst_mb = list_entry(ctx->dst_queue.next, struct s5p_mfc_buf, list);
 	dst_addr = vb2_dma_contig_plane_dma_addr(&dst_mb->b->vb2_buf, 0);
@@ -1215,8 +1235,8 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	struct s5p_mfc_buf *mb_entry;
-	unsigned long enc_y_addr = 0, enc_c_addr = 0;
-	unsigned long mb_y_addr, mb_c_addr;
+	unsigned long enc_y_addr = 0, enc_c_addr = 0, enc_c_1_addr = 0;
+	unsigned long mb_y_addr, mb_c_addr, mb_c_1_addr;
 	int slice_type;
 	unsigned int strm_size;
 	bool src_ready;
@@ -1229,18 +1249,26 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
 		  mfc_read(dev, S5P_FIMV_ENC_SI_PIC_CNT));
 	if (slice_type >= 0) {
 		s5p_mfc_hw_call(dev->mfc_ops, get_enc_frame_buffer, ctx,
-				&enc_y_addr, &enc_c_addr);
+				&enc_y_addr, &enc_c_addr, &enc_c_1_addr);
 		list_for_each_entry(mb_entry, &ctx->src_queue, list) {
 			mb_y_addr = vb2_dma_contig_plane_dma_addr(
 					&mb_entry->b->vb2_buf, 0);
 			mb_c_addr = vb2_dma_contig_plane_dma_addr(
 					&mb_entry->b->vb2_buf, 1);
-			if ((enc_y_addr == mb_y_addr) &&
-						(enc_c_addr == mb_c_addr)) {
+			if (ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YUV420M ||
+					ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YVU420M)
+				mb_c_1_addr = vb2_dma_contig_plane_dma_addr
+					(&mb_entry->b->vb2_buf, 2);
+			else
+				mb_c_1_addr = 0;
+			if (enc_y_addr == mb_y_addr && enc_c_addr == mb_c_addr && enc_c_1_addr
+					== mb_c_1_addr) {
 				list_del(&mb_entry->list);
 				ctx->src_queue_cnt--;
 				vb2_buffer_done(&mb_entry->b->vb2_buf,
-							VB2_BUF_STATE_DONE);
+						VB2_BUF_STATE_DONE);
 				break;
 			}
 		}
@@ -1249,20 +1277,27 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
 					&mb_entry->b->vb2_buf, 0);
 			mb_c_addr = vb2_dma_contig_plane_dma_addr(
 					&mb_entry->b->vb2_buf, 1);
-			if ((enc_y_addr == mb_y_addr) &&
-						(enc_c_addr == mb_c_addr)) {
+			if (ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YUV420M ||
+					ctx->src_fmt->fourcc == V4L2_PIX_FMT_YVU420M)
+				mb_c_1_addr = vb2_dma_contig_plane_dma_addr(&
+						mb_entry->b->vb2_buf, 2);
+			else
+				mb_c_1_addr = 0;
+			if (enc_y_addr == mb_y_addr && enc_c_addr == mb_c_addr && enc_c_1_addr
+					== mb_c_1_addr) {
 				list_del(&mb_entry->list);
 				ctx->ref_queue_cnt--;
 				vb2_buffer_done(&mb_entry->b->vb2_buf,
-							VB2_BUF_STATE_DONE);
+						VB2_BUF_STATE_DONE);
 				break;
 			}
 		}
 	}
 	if (ctx->src_queue_cnt > 0 && (ctx->state == MFCINST_RUNNING ||
-				       ctx->state == MFCINST_FINISHING)) {
+				ctx->state == MFCINST_FINISHING)) {
 		mb_entry = list_entry(ctx->src_queue.next, struct s5p_mfc_buf,
-									list);
+				list);
 		if (mb_entry->flags & MFC_BUF_FLAG_USED) {
 			list_del(&mb_entry->list);
 			ctx->src_queue_cnt--;
@@ -1381,10 +1416,15 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 		pix_fmt_mp->pixelformat = ctx->src_fmt->fourcc;
 		pix_fmt_mp->num_planes = ctx->src_fmt->num_planes;
 
-		pix_fmt_mp->plane_fmt[0].bytesperline = ctx->buf_width;
+		pix_fmt_mp->plane_fmt[0].bytesperline = ctx->stride[0];
 		pix_fmt_mp->plane_fmt[0].sizeimage = ctx->luma_size;
-		pix_fmt_mp->plane_fmt[1].bytesperline = ctx->buf_width;
+		pix_fmt_mp->plane_fmt[1].bytesperline = ctx->stride[1];
 		pix_fmt_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+		if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			pix_fmt_mp->plane_fmt[2].bytesperline = ctx->stride[2];
+			pix_fmt_mp->plane_fmt[2].sizeimage = ctx->chroma_size_1;
+		}
 	} else {
 		mfc_err("invalid buf type\n");
 		return -EINVAL;
@@ -1468,9 +1508,14 @@ static int vidioc_s_fmt(struct file *file, void *priv, struct v4l2_format *f)
 
 		s5p_mfc_hw_call(dev->mfc_ops, enc_calc_src_size, ctx);
 		pix_fmt_mp->plane_fmt[0].sizeimage = ctx->luma_size;
-		pix_fmt_mp->plane_fmt[0].bytesperline = ctx->buf_width;
+		pix_fmt_mp->plane_fmt[0].bytesperline = ctx->stride[0];
 		pix_fmt_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
-		pix_fmt_mp->plane_fmt[1].bytesperline = ctx->buf_width;
+		pix_fmt_mp->plane_fmt[1].bytesperline = ctx->stride[1];
+		if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			pix_fmt_mp->plane_fmt[2].bytesperline = ctx->stride[2];
+			pix_fmt_mp->plane_fmt[2].sizeimage = ctx->chroma_size_1;
+		}
 
 		ctx->src_bufs_cnt = 0;
 		ctx->output_state = QUEUE_FREE;
@@ -2414,10 +2459,18 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
 
 		psize[0] = ctx->luma_size;
 		psize[1] = ctx->chroma_size;
+		if (ctx->src_fmt && (ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YVU420M))
+			psize[2] = ctx->chroma_size_1;
 
 		if (IS_MFCV6_PLUS(dev)) {
 			alloc_devs[0] = ctx->dev->mem_dev[BANK_L_CTX];
 			alloc_devs[1] = ctx->dev->mem_dev[BANK_L_CTX];
+			if (ctx->src_fmt && (ctx->src_fmt->fourcc ==
+						V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+						V4L2_PIX_FMT_YVU420M))
+				alloc_devs[2] = ctx->dev->mem_dev[BANK_L_CTX];
 		} else {
 			alloc_devs[0] = ctx->dev->mem_dev[BANK_R_CTX];
 			alloc_devs[1] = ctx->dev->mem_dev[BANK_R_CTX];
@@ -2456,6 +2509,11 @@ static int s5p_mfc_buf_init(struct vb2_buffer *vb)
 					vb2_dma_contig_plane_dma_addr(vb, 0);
 		ctx->src_bufs[i].cookie.raw.chroma =
 					vb2_dma_contig_plane_dma_addr(vb, 1);
+		if (ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			ctx->src_bufs[i].cookie.raw.chroma_1 =
+					vb2_dma_contig_plane_dma_addr(vb, 2);
 		ctx->src_bufs_cnt++;
 	} else {
 		mfc_err("invalid queue type: %d\n", vq->type);
@@ -2493,6 +2551,12 @@ static int s5p_mfc_buf_prepare(struct vb2_buffer *vb)
 			mfc_err("plane size is too small for output\n");
 			return -EINVAL;
 		}
+		if ((ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M ||
+		     ctx->src_fmt->fourcc == V4L2_PIX_FMT_YVU420M) &&
+		    (vb2_plane_size(vb, 2) < ctx->chroma_size_1)) {
+			mfc_err("plane size is too small for output\n");
+			return -EINVAL;
+		}
 	} else {
 		mfc_err("invalid queue type: %d\n", vq->type);
 		return -EINVAL;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
index 87ac56756a16..7c5e851c8191 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.h
@@ -293,9 +293,11 @@ struct s5p_mfc_hw_ops {
 	int (*set_enc_stream_buffer)(struct s5p_mfc_ctx *ctx,
 			unsigned long addr, unsigned int size);
 	void (*set_enc_frame_buffer)(struct s5p_mfc_ctx *ctx,
-			unsigned long y_addr, unsigned long c_addr);
+			unsigned long y_addr, unsigned long c_addr,
+			unsigned long c_1_addr);
 	void (*get_enc_frame_buffer)(struct s5p_mfc_ctx *ctx,
-			unsigned long *y_addr, unsigned long *c_addr);
+			unsigned long *y_addr, unsigned long *c_addr,
+			unsigned long *c_1_addr);
 	void (*try_run)(struct s5p_mfc_dev *dev);
 	void (*clear_int_flags)(struct s5p_mfc_dev *dev);
 	int (*get_dspl_y_adr)(struct s5p_mfc_dev *dev);
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
index 28a06dc343fd..fcfaf125a5a1 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
@@ -516,7 +516,8 @@ static int s5p_mfc_set_enc_stream_buffer_v5(struct s5p_mfc_ctx *ctx,
 }
 
 static void s5p_mfc_set_enc_frame_buffer_v5(struct s5p_mfc_ctx *ctx,
-		unsigned long y_addr, unsigned long c_addr)
+		unsigned long y_addr, unsigned long c_addr,
+		unsigned long c_1_addr)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 
@@ -525,7 +526,8 @@ static void s5p_mfc_set_enc_frame_buffer_v5(struct s5p_mfc_ctx *ctx,
 }
 
 static void s5p_mfc_get_enc_frame_buffer_v5(struct s5p_mfc_ctx *ctx,
-		unsigned long *y_addr, unsigned long *c_addr)
+		unsigned long *y_addr, unsigned long *c_addr,
+		unsigned long *c_1_addr)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 
@@ -1210,7 +1212,7 @@ static int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 	if (list_empty(&ctx->src_queue)) {
 		/* send null frame */
 		s5p_mfc_set_enc_frame_buffer_v5(ctx, dev->dma_base[BANK_R_CTX],
-						dev->dma_base[BANK_R_CTX]);
+						dev->dma_base[BANK_R_CTX], 0);
 		src_mb = NULL;
 	} else {
 		src_mb = list_entry(ctx->src_queue.next, struct s5p_mfc_buf,
@@ -1220,7 +1222,7 @@ static int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 			/* send null frame */
 			s5p_mfc_set_enc_frame_buffer_v5(ctx,
 						dev->dma_base[BANK_R_CTX],
-						dev->dma_base[BANK_R_CTX]);
+						dev->dma_base[BANK_R_CTX], 0);
 			ctx->state = MFCINST_FINISHING;
 		} else {
 			src_y_addr = vb2_dma_contig_plane_dma_addr(
@@ -1228,7 +1230,7 @@ static int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 			src_c_addr = vb2_dma_contig_plane_dma_addr(
 					&src_mb->b->vb2_buf, 1);
 			s5p_mfc_set_enc_frame_buffer_v5(ctx, src_y_addr,
-								src_c_addr);
+								src_c_addr, 0);
 			if (src_mb->flags & MFC_BUF_FLAG_EOS)
 				ctx->state = MFCINST_FINISHING;
 		}
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index a49aa6c1e30b..36aebca11313 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -488,16 +488,35 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	ctx->buf_width = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
 	ctx->buf_height = ALIGN(ctx->img_height, S5P_FIMV_NV12MT_VALIGN_V6);
+	ctx->chroma_size_1 = 0;
 	mfc_debug(2, "SEQ Done: Movie dimensions %dx%d,\n"
 			"buffer dimensions: %dx%d\n", ctx->img_width,
 			ctx->img_height, ctx->buf_width, ctx->buf_height);
 
-	ctx->luma_size = calc_plane(ctx->img_width, ctx->img_height);
-	ctx->chroma_size = calc_plane(ctx->img_width, (ctx->img_height >> 1));
+	switch (ctx->dst_fmt->fourcc) {
+	case V4L2_PIX_FMT_NV12M:
+	case V4L2_PIX_FMT_NV21M:
+		ctx->stride[0] = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->stride[1] = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->luma_size = calc_plane(ctx->stride[0], ctx->img_height);
+		ctx->chroma_size = calc_plane(ctx->stride[1], (ctx->img_height / 2));
+		break;
+	case V4L2_PIX_FMT_YUV420M:
+	case V4L2_PIX_FMT_YVU420M:
+		ctx->stride[0] = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->stride[1] = ALIGN(ctx->img_width / 2, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->stride[2] = ALIGN(ctx->img_width / 2, S5P_FIMV_NV12MT_HALIGN_V6);
+		ctx->luma_size = calc_plane(ctx->stride[0], ctx->img_height);
+		ctx->chroma_size = calc_plane(ctx->stride[1], (ctx->img_height / 2));
+		ctx->chroma_size_1 = calc_plane(ctx->stride[2], (ctx->img_height / 2));
+		break;
+	}
+
 	if (IS_MFCV8_PLUS(ctx->dev)) {
 		/* MFCv8 needs additional 64 bytes for luma,chroma dpb*/
 		ctx->luma_size += S5P_FIMV_D_ALIGN_PLANE_SIZE_V8;
 		ctx->chroma_size += S5P_FIMV_D_ALIGN_PLANE_SIZE_V8;
+		ctx->chroma_size_1 += S5P_FIMV_D_ALIGN_PLANE_SIZE_V8;
 	}
 
 	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
@@ -524,14 +543,40 @@ static void s5p_mfc_enc_calc_src_size_v6(struct s5p_mfc_ctx *ctx)
 	mb_width = MB_WIDTH(ctx->img_width);
 	mb_height = MB_HEIGHT(ctx->img_height);
 
-	ctx->buf_width = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
-	ctx->luma_size = ALIGN((mb_width * mb_height) * 256, 256);
-	ctx->chroma_size = ALIGN((mb_width * mb_height) * 128, 256);
-
-	/* MFCv7 needs pad bytes for Luma and Chroma */
-	if (IS_MFCV7_PLUS(ctx->dev)) {
+	if (IS_MFCV12(ctx->dev)) {
+		switch (ctx->src_fmt->fourcc) {
+		case V4L2_PIX_FMT_NV12M:
+		case V4L2_PIX_FMT_NV21M:
+			ctx->stride[0] = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->stride[1] = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->luma_size = ctx->stride[0] * ALIGN(ctx->img_height, 16);
+			ctx->chroma_size =  ctx->stride[0] * ALIGN(ctx->img_height / 2, 16);
+			break;
+		case V4L2_PIX_FMT_YUV420M:
+		case V4L2_PIX_FMT_YVU420M:
+			ctx->stride[0] = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->stride[1] = ALIGN(ctx->img_width / 2, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->stride[2] = ALIGN(ctx->img_width / 2, S5P_FIMV_NV12M_HALIGN_V6);
+			ctx->luma_size = ctx->stride[0] * ALIGN(ctx->img_height, 16);
+			ctx->chroma_size =  ctx->stride[1] * ALIGN(ctx->img_height / 2, 16);
+			ctx->chroma_size_1 =  ctx->stride[2] * ALIGN(ctx->img_height / 2, 16);
+			break;
+		}
 		ctx->luma_size += MFC_LUMA_PAD_BYTES_V7;
-		ctx->chroma_size += MFC_CHROMA_PAD_BYTES_V7;
+		ctx->chroma_size += MFC_CHROMA_PAD_BYTES_V12;
+		ctx->chroma_size_1 += MFC_CHROMA_PAD_BYTES_V12;
+	} else {
+		ctx->buf_width = ALIGN(ctx->img_width, S5P_FIMV_NV12M_HALIGN_V6);
+		ctx->stride[0] = ctx->buf_width;
+		ctx->stride[1] = ctx->buf_width;
+		ctx->luma_size = ALIGN((mb_width * mb_height) * 256, 256);
+		ctx->chroma_size = ALIGN((mb_width * mb_height) * 128, 256);
+		ctx->chroma_size_1 = 0;
+		/* MFCv7 needs pad bytes for Luma and Chroma */
+		if (IS_MFCV7_PLUS(ctx->dev)) {
+			ctx->luma_size += MFC_LUMA_PAD_BYTES_V7;
+			ctx->chroma_size += MFC_LUMA_PAD_BYTES_V7;
+		}
 	}
 }
 
@@ -578,15 +623,18 @@ static int s5p_mfc_set_dec_frame_buffer_v6(struct s5p_mfc_ctx *ctx)
 	writel(ctx->total_dpb_count, mfc_regs->d_num_dpb);
 	writel(ctx->luma_size, mfc_regs->d_first_plane_dpb_size);
 	writel(ctx->chroma_size, mfc_regs->d_second_plane_dpb_size);
-
+	if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+			V4L2_PIX_FMT_YVU420M)
+		writel(ctx->chroma_size_1, mfc_regs->d_third_plane_dpb_size);
 	writel(buf_addr1, mfc_regs->d_scratch_buffer_addr);
 	writel(ctx->scratch_buf_size, mfc_regs->d_scratch_buffer_size);
 
 	if (IS_MFCV8_PLUS(dev)) {
-		writel(ctx->img_width,
-			mfc_regs->d_first_plane_dpb_stride_size);
-		writel(ctx->img_width,
-			mfc_regs->d_second_plane_dpb_stride_size);
+		writel(ctx->stride[0], mfc_regs->d_first_plane_dpb_stride_size);
+		writel(ctx->stride[1], mfc_regs->d_second_plane_dpb_stride_size);
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			writel(ctx->stride[2], mfc_regs->d_third_plane_dpb_stride_size);
 	}
 
 	buf_addr1 += ctx->scratch_buf_size;
@@ -615,6 +663,13 @@ static int s5p_mfc_set_dec_frame_buffer_v6(struct s5p_mfc_ctx *ctx)
 					ctx->dst_bufs[i].cookie.raw.chroma);
 		writel(ctx->dst_bufs[i].cookie.raw.chroma,
 				mfc_regs->d_second_plane_dpb + i * 4);
+		if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->dst_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M) {
+			mfc_debug(2, "\tChroma_1 %d: %zx\n", i, ctx
+					->dst_bufs[i].cookie.raw.chroma_1);
+			writel(ctx->dst_bufs[i].cookie.raw.chroma_1, mfc_regs->d_third_plane_dpb +
+					i * 4);
+		}
 	}
 	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
 			ctx->codec_mode == S5P_MFC_CODEC_H264_MVC_DEC ||
@@ -673,20 +728,24 @@ static int s5p_mfc_set_enc_stream_buffer_v6(struct s5p_mfc_ctx *ctx,
 }
 
 static void s5p_mfc_set_enc_frame_buffer_v6(struct s5p_mfc_ctx *ctx,
-		unsigned long y_addr, unsigned long c_addr)
+		unsigned long y_addr, unsigned long c_addr,
+		unsigned long c_1_addr)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
 
 	writel(y_addr, mfc_regs->e_source_first_plane_addr);
 	writel(c_addr, mfc_regs->e_source_second_plane_addr);
+	writel(c_1_addr, mfc_regs->e_source_third_plane_addr);
 
 	mfc_debug(2, "enc src y buf addr: 0x%08lx\n", y_addr);
 	mfc_debug(2, "enc src c buf addr: 0x%08lx\n", c_addr);
+	mfc_debug(2, "enc src cr buf addr: 0x%08lx\n", c_1_addr);
 }
 
 static void s5p_mfc_get_enc_frame_buffer_v6(struct s5p_mfc_ctx *ctx,
-		unsigned long *y_addr, unsigned long *c_addr)
+		unsigned long *y_addr, unsigned long *c_addr,
+		unsigned long *c_1_addr)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
@@ -694,12 +753,17 @@ static void s5p_mfc_get_enc_frame_buffer_v6(struct s5p_mfc_ctx *ctx,
 
 	*y_addr = readl(mfc_regs->e_encoded_source_first_plane_addr);
 	*c_addr = readl(mfc_regs->e_encoded_source_second_plane_addr);
+	if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+			V4L2_PIX_FMT_YVU420M)
+		*c_1_addr = readl(mfc_regs->e_encoded_source_third_plane_addr);
+	else
+		*c_1_addr = 0;
 
 	enc_recon_y_addr = readl(mfc_regs->e_recon_luma_dpb_addr);
 	enc_recon_c_addr = readl(mfc_regs->e_recon_chroma_dpb_addr);
 
 	mfc_debug(2, "recon y addr: 0x%08lx y_addr: 0x%08lx\n", enc_recon_y_addr, *y_addr);
-	mfc_debug(2, "recon c addr: 0x%08lx\n", enc_recon_c_addr);
+	mfc_debug(2, "recon c addr: 0x%08lx c_addr: 0x%08lx\n", enc_recon_c_addr, *c_addr);
 }
 
 /* Set encoding ref & codec buffer */
@@ -876,6 +940,20 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
 		writel(reg, mfc_regs->e_enc_options);
 		/* 0: NV12(CbCr), 1: NV21(CrCb) */
 		writel(0x0, mfc_regs->pixel_format);
+	} else if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YVU420M) {
+		/* 0: Linear, 1: 2D tiled*/
+		reg = readl(mfc_regs->e_enc_options);
+		reg &= ~(0x1 << 7);
+		writel(reg, mfc_regs->e_enc_options);
+		/* 2: YV12(CrCb), 3: I420(CrCb) */
+		writel(0x2, mfc_regs->pixel_format);
+	} else if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M) {
+		/* 0: Linear, 1: 2D tiled*/
+		reg = readl(mfc_regs->e_enc_options);
+		reg &= ~(0x1 << 7);
+		writel(reg, mfc_regs->e_enc_options);
+		/* 2: YV12(CrCb), 3: I420(CrCb) */
+		writel(0x3, mfc_regs->pixel_format);
 	}
 
 	/* memory structure recon. frame */
@@ -1686,8 +1764,12 @@ static int s5p_mfc_init_decode_v6(struct s5p_mfc_ctx *ctx)
 	else
 		writel(reg, mfc_regs->d_dec_options);
 
-	/* 0: NV12(CbCr), 1: NV21(CrCb) */
-	if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_NV21M)
+	/* 0: NV12(CbCr), 1: NV21(CrCb), 2: YV12(CrCb), 3: I420(CbCr) */
+	if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YUV420M)
+		writel(0x3, mfc_regs->pixel_format);
+	else if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_YVU420M)
+		writel(0x2, mfc_regs->pixel_format);
+	else if (ctx->dst_fmt->fourcc == V4L2_PIX_FMT_NV21M)
 		writel(0x1, mfc_regs->pixel_format);
 	else
 		writel(0x0, mfc_regs->pixel_format);
@@ -1771,8 +1853,11 @@ static int s5p_mfc_init_encode_v6(struct s5p_mfc_ctx *ctx)
 
 	/* Set stride lengths for v7 & above */
 	if (IS_MFCV7_PLUS(dev)) {
-		writel(ctx->img_width, mfc_regs->e_source_first_plane_stride);
-		writel(ctx->img_width, mfc_regs->e_source_second_plane_stride);
+		writel(ctx->stride[0], mfc_regs->e_source_first_plane_stride);
+		writel(ctx->stride[1], mfc_regs->e_source_second_plane_stride);
+		if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+				V4L2_PIX_FMT_YVU420M)
+			writel(ctx->stride[2], mfc_regs->e_source_third_plane_stride);
 	}
 
 	writel(ctx->inst_no, mfc_regs->instance_id);
@@ -1881,7 +1966,7 @@ static inline int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	struct s5p_mfc_buf *dst_mb;
 	struct s5p_mfc_buf *src_mb;
-	unsigned long src_y_addr, src_c_addr, dst_addr;
+	unsigned long src_y_addr, src_c_addr, src_c_1_addr, dst_addr;
 	/*
 	unsigned int src_y_size, src_c_size;
 	*/
@@ -1899,22 +1984,28 @@ static inline int s5p_mfc_run_enc_frame(struct s5p_mfc_ctx *ctx)
 
 	if (list_empty(&ctx->src_queue)) {
 		/* send null frame */
-		s5p_mfc_set_enc_frame_buffer_v6(ctx, 0, 0);
+		s5p_mfc_set_enc_frame_buffer_v6(ctx, 0, 0, 0);
 		src_mb = NULL;
 	} else {
 		src_mb = list_entry(ctx->src_queue.next, struct s5p_mfc_buf, list);
 		src_mb->flags |= MFC_BUF_FLAG_USED;
 		if (src_mb->b->vb2_buf.planes[0].bytesused == 0) {
-			s5p_mfc_set_enc_frame_buffer_v6(ctx, 0, 0);
+			s5p_mfc_set_enc_frame_buffer_v6(ctx, 0, 0, 0);
 			ctx->state = MFCINST_FINISHING;
 		} else {
 			src_y_addr = vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 0);
 			src_c_addr = vb2_dma_contig_plane_dma_addr(&src_mb->b->vb2_buf, 1);
+			if (ctx->src_fmt->fourcc == V4L2_PIX_FMT_YUV420M || ctx->src_fmt->fourcc ==
+					V4L2_PIX_FMT_YVU420M)
+				src_c_1_addr = vb2_dma_contig_plane_dma_addr
+					(&src_mb->b->vb2_buf, 2);
+			else
+				src_c_1_addr = 0;
 
 			mfc_debug(2, "enc src y addr: 0x%08lx\n", src_y_addr);
 			mfc_debug(2, "enc src c addr: 0x%08lx\n", src_c_addr);
 
-			s5p_mfc_set_enc_frame_buffer_v6(ctx, src_y_addr, src_c_addr);
+			s5p_mfc_set_enc_frame_buffer_v6(ctx, src_y_addr, src_c_addr, src_c_1_addr);
 			if (src_mb->flags & MFC_BUF_FLAG_EOS)
 				ctx->state = MFCINST_FINISHING;
 		}
@@ -2436,10 +2527,9 @@ const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev)
 	R(e_source_first_plane_stride, S5P_FIMV_E_SOURCE_FIRST_STRIDE_V7);
 	R(e_source_second_plane_stride, S5P_FIMV_E_SOURCE_SECOND_STRIDE_V7);
 	R(e_source_third_plane_stride, S5P_FIMV_E_SOURCE_THIRD_STRIDE_V7);
-	R(e_encoded_source_first_plane_addr,
-			S5P_FIMV_E_ENCODED_SOURCE_FIRST_ADDR_V7);
-	R(e_encoded_source_second_plane_addr,
-			S5P_FIMV_E_ENCODED_SOURCE_SECOND_ADDR_V7);
+	R(e_encoded_source_first_plane_addr, S5P_FIMV_E_ENCODED_SOURCE_FIRST_ADDR_V7);
+	R(e_encoded_source_second_plane_addr, S5P_FIMV_E_ENCODED_SOURCE_SECOND_ADDR_V7);
+	R(e_encoded_source_third_plane_addr, S5P_FIMV_E_ENCODED_SOURCE_THIRD_ADDR_V7);
 	R(e_vp8_options, S5P_FIMV_E_VP8_OPTIONS_V7);
 
 	if (!IS_MFCV8_PLUS(dev))
@@ -2454,16 +2544,17 @@ const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev)
 	R(d_cpb_buffer_offset, S5P_FIMV_D_CPB_BUFFER_OFFSET_V8);
 	R(d_first_plane_dpb_size, S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8);
 	R(d_second_plane_dpb_size, S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V8);
+	R(d_third_plane_dpb_size, S5P_FIMV_D_THIRD_PLANE_DPB_SIZE_V8);
 	R(d_scratch_buffer_addr, S5P_FIMV_D_SCRATCH_BUFFER_ADDR_V8);
 	R(d_scratch_buffer_size, S5P_FIMV_D_SCRATCH_BUFFER_SIZE_V8);
-	R(d_first_plane_dpb_stride_size,
-			S5P_FIMV_D_FIRST_PLANE_DPB_STRIDE_SIZE_V8);
-	R(d_second_plane_dpb_stride_size,
-			S5P_FIMV_D_SECOND_PLANE_DPB_STRIDE_SIZE_V8);
+	R(d_first_plane_dpb_stride_size, S5P_FIMV_D_FIRST_PLANE_DPB_STRIDE_SIZE_V8);
+	R(d_second_plane_dpb_stride_size, S5P_FIMV_D_SECOND_PLANE_DPB_STRIDE_SIZE_V8);
+	R(d_third_plane_dpb_stride_size, S5P_FIMV_D_THIRD_PLANE_DPB_STRIDE_SIZE_V8);
 	R(d_mv_buffer_size, S5P_FIMV_D_MV_BUFFER_SIZE_V8);
 	R(d_num_mv, S5P_FIMV_D_NUM_MV_V8);
 	R(d_first_plane_dpb, S5P_FIMV_D_FIRST_PLANE_DPB_V8);
 	R(d_second_plane_dpb, S5P_FIMV_D_SECOND_PLANE_DPB_V8);
+	R(d_third_plane_dpb, S5P_FIMV_D_THIRD_PLANE_DPB_V8);
 	R(d_mv_buffer, S5P_FIMV_D_MV_BUFFER_V8);
 	R(d_init_buffer_options, S5P_FIMV_D_INIT_BUFFER_OPTIONS_V8);
 	R(d_available_dpb_flag_lower, S5P_FIMV_D_AVAILABLE_DPB_FLAG_LOWER_V8);
-- 
2.17.1



From aakarsh.jain at samsung.com  Wed Dec 13 00:11:00 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:41:00 +0530
Subject: [Patch v6 05/10] media: s5p-mfc: Add support for rate controls in
 MFCv12
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081131epcas5p181e1178375a69d021e138b4c16f8da67@epcas5p1.samsung.com>
Message-ID: <20231213081105.25817-6-aakarsh.jain@samsung.com>

In MFCv12, the rc configs are changed with support for CBR loose,
CBR tight and Variable Bitrate (VBR) added.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 22 +++++++++++++++----
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h |  1 +
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 36aebca11313..4a0d0e228e78 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -992,10 +992,24 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
 
 	/* reaction coefficient */
 	if (p->rc_frame) {
-		if (p->rc_reaction_coeff < TIGHT_CBR_MAX) /* tight CBR */
-			writel(1, mfc_regs->e_rc_mode);
-		else					  /* loose CBR */
-			writel(2, mfc_regs->e_rc_mode);
+		if (IS_MFCV12(dev)) {
+			/* loose CBR */
+			if (p->rc_reaction_coeff < LOOSE_CBR_MAX)
+				writel(1, mfc_regs->e_rc_mode);
+			/* tight CBR */
+			else if (p->rc_reaction_coeff < TIGHT_CBR_MAX)
+				writel(0, mfc_regs->e_rc_mode);
+			/* VBR */
+			else
+				writel(2, mfc_regs->e_rc_mode);
+		} else {
+			/* tight CBR */
+			if (p->rc_reaction_coeff < TIGHT_CBR_MAX)
+				writel(1, mfc_regs->e_rc_mode);
+			/* loose CBR */
+			else
+				writel(2, mfc_regs->e_rc_mode);
+		}
 	}
 
 	/* seq header ctrl */
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
index ff582eea4217..94ecb0e6e7c7 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
@@ -40,6 +40,7 @@
 #define ENC_H264_LEVEL_MAX		42
 #define ENC_MPEG4_VOP_TIME_RES_MAX	((1 << 16) - 1)
 #define FRAME_DELTA_H264_H263		1
+#define LOOSE_CBR_MAX			5
 #define TIGHT_CBR_MAX			10
 #define ENC_HEVC_RC_FRAME_RATE_MAX	((1 << 16) - 1)
 #define ENC_HEVC_QP_INDEX_MIN		-12
-- 
2.17.1



From aakarsh.jain at samsung.com  Wed Dec 13 00:11:01 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:41:01 +0530
Subject: [Patch v6 06/10] media: s5p-mfc: Add support for UHD encoding.
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081134epcas5p2fdbd2577fe46b848c87ea5d89cbb96f5@epcas5p2.samsung.com>
Message-ID: <20231213081105.25817-7-aakarsh.jain@samsung.com>

MFC driver had restriction on max resolution of 1080p, updated it for
UHD. Added corresponding support to set recommended profile and level
for H264 in UHD scenario.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c |  9 ++++++---
 .../media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c  | 12 ++++++++++++
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index 2f11a1e861e1..67fe0302464f 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -1461,9 +1461,12 @@ static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 			mfc_err("Unsupported format by this MFC version.\n");
 			return -EINVAL;
 		}
-
-		v4l_bound_align_image(&pix_fmt_mp->width, 8, 1920, 1,
-			&pix_fmt_mp->height, 4, 1080, 1, 0);
+		if (IS_MFCV12(dev))
+			v4l_bound_align_image(&pix_fmt_mp->width, 8, 3840, 1, &pix_fmt_mp
+					->height, 4, 2160, 1, 0);
+		else
+			v4l_bound_align_image(&pix_fmt_mp->width, 8, 1920, 1, &pix_fmt_mp
+					->height, 4, 1080, 1, 0);
 	} else {
 		mfc_err("invalid buf type\n");
 		return -EINVAL;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 4a0d0e228e78..572293f3b190 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1071,6 +1071,18 @@ static int s5p_mfc_set_enc_params_h264(struct s5p_mfc_ctx *ctx)
 	reg |= ((p->num_b_frame & 0x3) << 16);
 	writel(reg, mfc_regs->e_gop_config);
 
+	/* UHD encoding case */
+	if (ctx->img_width == 3840 && ctx->img_height == 2160) {
+		if (p_h264->level < 51) {
+			mfc_debug(2, "Set Level 5.1 for UHD\n");
+			p_h264->level = 51;
+		}
+		if (p_h264->profile != 0x2) {
+			mfc_debug(2, "Set High profile for UHD\n");
+			p_h264->profile = 0x2;
+		}
+	}
+
 	/* profile & level */
 	reg = 0;
 	/** level */
-- 
2.17.1



From aakarsh.jain at samsung.com  Wed Dec 13 00:11:02 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:41:02 +0530
Subject: [Patch v6 07/10] media: s5p-mfc: Add support for DMABUF for encoder
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081137epcas5p132baeb4789897e3386b9357b55cc63c4@epcas5p1.samsung.com>
Message-ID: <20231213081105.25817-8-aakarsh.jain@samsung.com>

Add dmabuf support for mfc encoder

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../media/platform/samsung/s5p-mfc/s5p_mfc.c  |  4 ++--
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    | 20 ++++++++++---------
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index dee9ef017997..bd055dea827e 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -865,7 +865,7 @@ static int s5p_mfc_open(struct file *file)
 		q->io_modes = VB2_MMAP;
 		q->ops = get_dec_queue_ops();
 	} else if (vdev == dev->vfd_enc) {
-		q->io_modes = VB2_MMAP | VB2_USERPTR;
+		q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
 		q->ops = get_enc_queue_ops();
 	} else {
 		ret = -ENOENT;
@@ -892,7 +892,7 @@ static int s5p_mfc_open(struct file *file)
 		q->io_modes = VB2_MMAP;
 		q->ops = get_dec_queue_ops();
 	} else if (vdev == dev->vfd_enc) {
-		q->io_modes = VB2_MMAP | VB2_USERPTR;
+		q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
 		q->ops = get_enc_queue_ops();
 	} else {
 		ret = -ENOENT;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index 67fe0302464f..ae3764969473 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -1538,9 +1538,10 @@ static int vidioc_reqbufs(struct file *file, void *priv,
 	struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
 	int ret = 0;
 
-	/* if memory is not mmp or userptr return error */
+	/* if memory is not mmp or userptr or dmabuf return error */
 	if ((reqbufs->memory != V4L2_MEMORY_MMAP) &&
-		(reqbufs->memory != V4L2_MEMORY_USERPTR))
+		(reqbufs->memory != V4L2_MEMORY_USERPTR) &&
+		(reqbufs->memory != V4L2_MEMORY_DMABUF))
 		return -EINVAL;
 	if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 		if (reqbufs->count == 0) {
@@ -1617,9 +1618,10 @@ static int vidioc_querybuf(struct file *file, void *priv,
 	struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
 	int ret = 0;
 
-	/* if memory is not mmp or userptr return error */
+	/* if memory is not mmp or userptr or dmabuf return error */
 	if ((buf->memory != V4L2_MEMORY_MMAP) &&
-		(buf->memory != V4L2_MEMORY_USERPTR))
+		(buf->memory != V4L2_MEMORY_USERPTR) &&
+		(buf->memory != V4L2_MEMORY_DMABUF))
 		return -EINVAL;
 	if (buf->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
 		if (ctx->state != MFCINST_GOT_INST) {
@@ -2581,11 +2583,11 @@ static int s5p_mfc_start_streaming(struct vb2_queue *q, unsigned int count)
 						S5P_MFC_R2H_CMD_SEQ_DONE_RET,
 						0);
 		}
-
-		if (ctx->src_bufs_cnt < ctx->pb_count) {
-			mfc_err("Need minimum %d OUTPUT buffers\n",
-					ctx->pb_count);
-			return -ENOBUFS;
+		if (q->memory != V4L2_MEMORY_DMABUF) {
+			if (ctx->src_bufs_cnt < ctx->pb_count) {
+				mfc_err("Need minimum %d OUTPUT buffers\n", ctx->pb_count);
+				return -ENOBUFS;
+			}
 		}
 	}
 
-- 
2.17.1



From aakarsh.jain at samsung.com  Wed Dec 13 00:11:03 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:41:03 +0530
Subject: [Patch v6 08/10] media: s5p-mfc: Set context for valid case before
 calling try_run
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081140epcas5p2bf0e2edea2d24224d775b348b1d5ca50@epcas5p2.samsung.com>
Message-ID: <20231213081105.25817-9-aakarsh.jain@samsung.com>

Context bit is set for hardware execution if there is a buffer in
source and destination queue before calling try_run in the
init_buffers function. Now there will be a new context created and
hardware will be invoked for the buffer queued instead of waiting for
another buffer to be queued from userspace to set this context bit for
hw execution.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index bd055dea827e..fbb047eadf5a 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -604,6 +604,8 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx *ctx,
 		s5p_mfc_clock_off();
 
 		wake_up(&ctx->queue);
+		if (ctx->src_queue_cnt >= 1 && ctx->dst_queue_cnt >= 1)
+			set_work_bit_irqsave(ctx);
 		s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 	} else {
 		WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
-- 
2.17.1



From catalin.marinas at arm.com  Wed Dec 13 03:01:54 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 13 Dec 2023 11:01:54 +0000
Subject: [PATCH] arm64: irq: set the correct node for shadow call stack
In-Reply-To: <20231213012046.12014-1-shijie@os.amperecomputing.com>
References: <20231213012046.12014-1-shijie@os.amperecomputing.com>
Message-ID: <ZXmPImuyntNM7a1Z@arm.com>

On Wed, Dec 13, 2023 at 09:20:46AM +0800, Huang Shijie wrote:
> The init_irq_stacks() has been changed to use the correct node:
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf
> 
> The init_irq_scs() has the same issue with init_irq_stacks():
> 	cpu_to_node() is not initialized yet, it does not work.
> 
> This patch uses early_cpu_to_node() to set the init_irq_scs()
> with the correct node.
> 
> Signed-off-by: Huang Shijie <shijie at os.amperecomputing.com>

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>


From aakarsh.jain at samsung.com  Wed Dec 13 00:11:04 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:41:04 +0530
Subject: [Patch v6 09/10] media: s5p-mfc: Load firmware for each run in
 MFCv12.
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081143epcas5p1a3acbe09ca033b356a19e2acb2d9411f@epcas5p1.samsung.com>
Message-ID: <20231213081105.25817-10-aakarsh.jain@samsung.com>

In MFCv12, some section of firmware gets updated at each MFC run.
Hence we need to reload original firmware for each run at the start.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
index b49159142c53..503487f34a80 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
@@ -51,8 +51,14 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
 	 * into kernel. */
 	mfc_debug_enter();
 
-	if (dev->fw_get_done)
-		return 0;
+	/* In case of MFC v12, RET_SYS_INIT response from hardware fails due to
+	 * incorrect firmware transfer and therefore it is not able to initialize
+	 * the hardware. This causes failed response for SYS_INIT command when
+	 * MFC runs for second time. So, load the MFC v12 firmware for each run.
+	 */
+	if (!IS_MFCV12(dev))
+		if (dev->fw_get_done)
+			return 0;
 
 	for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
 		if (!dev->variant->fw_name[i])
-- 
2.17.1



From aakarsh.jain at samsung.com  Wed Dec 13 00:11:05 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Wed, 13 Dec 2023 13:41:05 +0530
Subject: [Patch v6 10/10] media: s5p-mfc: DPB Count Independent of
 VIDIOC_REQBUF
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <20231213081105.25817-1-aakarsh.jain@samsung.com>
	<CGME20231213081148epcas5p215061f6452b43e00dd20e5db6b50bbb9@epcas5p2.samsung.com>
Message-ID: <20231213081105.25817-11-aakarsh.jain@samsung.com>

Add allocation of DPB buffers based on MFC requirement so,
codec buffers allocations has been moved after state
MFCINST_HEAD_PRODUCED. It is taken care that codec buffer allocation
is performed in process context from userspace IOCTL call.

Cc: linux-fsd at tesla.com
Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
---
 .../platform/samsung/s5p-mfc/s5p_mfc_enc.c     | 18 ++----------------
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c  |  7 +++++++
 2 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index ae3764969473..ef8bb40b9712 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -1164,7 +1164,6 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	struct s5p_mfc_enc_params *p = &ctx->enc_params;
 	struct s5p_mfc_buf *dst_mb;
-	unsigned int enc_pb_count;
 
 	if (p->seq_hdr_mode == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) {
 		if (!list_empty(&ctx->dst_queue)) {
@@ -1186,10 +1185,7 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
 			set_work_bit_irqsave(ctx);
 		s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 	} else {
-		enc_pb_count = s5p_mfc_hw_call(dev->mfc_ops,
-				get_enc_dpb_count, dev);
-		if (ctx->pb_count < enc_pb_count)
-			ctx->pb_count = enc_pb_count;
+		ctx->pb_count = s5p_mfc_hw_call(dev->mfc_ops, get_enc_dpb_count, dev);
 		if (FW_HAS_E_MIN_SCRATCH_BUF(dev)) {
 			ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
 					get_e_min_scratch_buf_size, dev);
@@ -1564,14 +1560,6 @@ static int vidioc_reqbufs(struct file *file, void *priv,
 		}
 		ctx->capture_state = QUEUE_BUFS_REQUESTED;
 
-		ret = s5p_mfc_hw_call(ctx->dev->mfc_ops,
-				alloc_codec_buffers, ctx);
-		if (ret) {
-			mfc_err("Failed to allocate encoding buffers\n");
-			reqbufs->count = 0;
-			ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
-			return -ENOMEM;
-		}
 	} else if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 		if (reqbufs->count == 0) {
 			mfc_debug(2, "Freeing buffers\n");
@@ -1587,15 +1575,13 @@ static int vidioc_reqbufs(struct file *file, void *priv,
 			return -EINVAL;
 		}
 
-		if (IS_MFCV6_PLUS(dev)) {
+		if (IS_MFCV6_PLUS(dev) && (!IS_MFCV12(dev))) {
 			/* Check for min encoder buffers */
 			if (ctx->pb_count &&
 				(reqbufs->count < ctx->pb_count)) {
 				reqbufs->count = ctx->pb_count;
 				mfc_debug(2, "Minimum %d output buffers needed\n",
 						ctx->pb_count);
-			} else {
-				ctx->pb_count = reqbufs->count;
 			}
 		}
 
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 572293f3b190..fd945211d28e 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -2110,6 +2110,13 @@ static inline int s5p_mfc_run_init_enc_buffers(struct s5p_mfc_ctx *ctx)
 	struct s5p_mfc_dev *dev = ctx->dev;
 	int ret;
 
+	ret = s5p_mfc_hw_call(ctx->dev->mfc_ops, alloc_codec_buffers, ctx);
+	if (ret) {
+		mfc_err("Failed to allocate encoding buffers\n");
+		return -ENOMEM;
+	}
+	mfc_debug(2, "Allocated Internal Encoding Buffers\n");
+
 	dev->curr_ctx = ctx->num;
 	ret = s5p_mfc_set_enc_ref_buffer_v6(ctx);
 	if (ret) {
-- 
2.17.1



From retpolanne at posteo.net  Wed Dec 13 03:02:39 2023
From: retpolanne at posteo.net (Anne Macedo)
Date: Wed, 13 Dec 2023 11:02:39 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <20231213013544.2fc7e0d1@minigeek.lan>
References: <20231212122835.10850-2-retpolanne@posteo.net>
 <20231212162200.10b3868b@donnerap.manchester.arm.com>
 <axsvii25yrknfae6gdreti7lcskoscsdbsujwuispiieimsbdy@gwzm4l7mwlew>
 <20231213013544.2fc7e0d1@minigeek.lan>
Message-ID: <ceuoq3xxgb5kkel7e7wqpslcg7h6dde3wgdqhyo7jgop6owovk@5a76ks5fiun4>

On Wed, Dec 13, 2023 at 01:35:44AM +0000, Andre Przywara wrote:
> On Tue, 12 Dec 2023 19:27:14 +0000
> Anne Macedo <retpolanne at posteo.net> wrote:
> 
> Hi Anne,
> 
> > On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:
> > > On Tue, 12 Dec 2023 12:28:30 +0000
> > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > 
> > > Hi Anne,
> > >   
> > > > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > > > Realtek 8211 PHY to Orange Pi One Plus.  
> > > 
> > > So can you state why this would be needed? This is the RTL8211 ID,  
> > 
> > Apologies, I completely forgot to include some context. 
> > 
> > > right? Which should be autodetected via MDIO. Looking back in my inbox
> > > you proposed this change before, for U-Boot, specifically, but I fail to
> > > find a solution or explanation what really happens here. Two Renesas .dts
> > > files have the same compatible, and the commit message talks about the
> > > reset line there, is this related?
> > > 
> > > So can you please give some more background and explanation? That would be
> > > part of a good commit message anyway ("why", not "what").  
> > 
> > Should I resend the commit with a more meaningful explanation? The
> > context is the following:
> > 
> > currently, ethernet doesn't seem to work on both u-boot and Linux on the
> > Orange Pi One Plus board. 
> > 
> > On the kernel, this error shows up:
> > 
> > Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > [    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> > 
> > After applying this fix, the PHY gets attached: 
> > 
> > Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > [    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
> > 
> > The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
> > to find a PHY, so this patch includes the correct PHY ID with the
> > RTL8211 ID. 
> > 
> > The behaviour is described on [1].
> 
> So this is all an observation, but no real explanation, isn't it?

I've made some analysis on [3] on this bug, but it was based solely on
u-boot. I was having trouble with the regulator and on u-boot nothing
would trigger the GPIO PD6 and the vcc-gmac-3v3 regulator, so the NIC
was completely dead. Next I did an analysis based on [2] because the
u-boot PHY initialization was flaky.

> To cite [1]: "If the PHY reports an incorrect ID (or none at all) ...".
> I am pretty sure this is not the case here, instead we are looking at
> some missing platform bits, like a missing clock, reset, or most likely
> regulator. Or one of the existing resources is wrongly assigned or

As I mentioned, PHY initialization is flaky on u-boot, so maybe that
assumption is correct. 

> configured? If the PHY is not (yet?) powered correctly when the code
> does the auto-detection via the MDIO bus, then the initialisation would

If I recall correctly (I don't know if I kept it in my notes :c), that
could be the case. regulator-boot-on makes the NIC work (LEDs blink, at
least) but it doesn't get initialized. 

> fail. But since it works when overriding the auto-detection, I feel
> like we are papering over something here.
> Do you have the schematics for this board? I can only find the one for
> the Orange Pi Plus 2E, and I don't know how similar those two are. This
> shows *two* regulators, but both are activated by the same GPIO.

I do. It's available on [4]

> It would also be interesting to see if any of Corentin's work for the
> Orange Pi 3 helps here?

Adding [5] for reference here, thanks! Will check it out. 
> 
> Cheers,
> Andre
> 

[3] https://blog.retpolanne.com/hardware/embedded/2023/07/07/embedded-phy.html
[4] https://linux-sunxi.org/images/7/7c/OrangePi_OnePlus_Schematics_v2.0.pdf
[5] https://lore.kernel.org/netdev/20220509074857.195302-1-clabbe at baylibre.com/

Regards, Anne


From shawnguo at kernel.org  Wed Dec 13 03:05:29 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 13 Dec 2023 19:05:29 +0800
Subject: [PATCH 1/6] ARM: dts: imx27: Use 'bus' for AIPI bus
In-Reply-To: <20231206150023.2305685-1-festevam@gmail.com>
References: <20231206150023.2305685-1-festevam@gmail.com>
Message-ID: <20231213110529.GO270430@dragon>

On Wed, Dec 06, 2023 at 12:00:18PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per simple-bus.yaml, 'aipi' is not a valid node name.
> 
> Change it to 'bus' to fix the following dt-schema warning:
> 
> imx27-pdk.dtb: aipi at 10020000: $nodename:0: 'aipi at 10020000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
> 	from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied all, thanks!


From u.kleine-koenig at pengutronix.de  Wed Dec 13 03:08:29 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 13 Dec 2023 12:08:29 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
 <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
Message-ID: <20231213110829.bjaxjjiyy4ug7o67@pengutronix.de>

Hello Maxime,

On Wed, Dec 13, 2023 at 09:36:49AM +0100, Maxime Ripard wrote:
> On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
> > On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > > On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> > > > clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> > > > that and don't check the return value. This series fixes the four users
> > > > that do error checking on the returned value and then makes function
> > > > return void.
> > > > 
> > > > Given that the changes to the drivers are simple and so merge conflicts
> > > > (if any) should be easy to handle, I suggest to merge this complete
> > > > series via the clk tree.
> > > 
> > > I don't think it's the right way to go about it.
> > > 
> > > clk_rate_exclusive_get() should be expected to fail. For example if
> > > there's another user getting an exclusive rate on the same clock.
> > > 
> > > If we're not checking for it right now, then it should probably be
> > > fixed, but the callers checking for the error are right to do so if they
> > > rely on an exclusive rate. It's the ones that don't that should be
> > > modified.
> > 
> > If some other consumer has already "locked" a clock that I call
> > clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
> > this function because I don't want the rate to change e.g. because I
> > setup some registers in the consuming device to provide a fixed UART
> > baud rate or i2c bus frequency (and that works as expected).
> 
> [a long text of mostly right things (Uwe's interpretation) that are
> however totally unrelated to the patches under discussion.]

The clk API works with and without my patches in exactly the same way.
It just makes more explicit that clk_rate_exclusive_get() cannot fail
today and removes the error handling from consumers that is never used.

Yes, my series doesn't fix any race conditions that are there without
doubt in some consumers. It also doesn't make the situation any worse.
It also doesn't fix other problems that are orthogonal to the intention
of this patch series (neither makes it any of them any worse).

It's just dead code removal and making sure no new dead code of the same
type is introduced in the future.

Is there anyone working on improving the clk framework regarding how clk
rate exclusivity works? I'd probably not notice, but I guess there is
noone that I need to consider for. And if in the future someone
redesigns how all that works *and* clk_rate_exclusive_get() stays around
*and* that makes it possible that clk_rate_exclusive_get() fails (and
thus breaking all consumers that don't care for the actual clk rate and
only want it to not change), then they'll have to review all users
anyhow and reintroduce error handling. I can live with that and suggest
until then we're happy that we have a few drivers with less dead code
than before.

Cheers!
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/1baf61c8/attachment.sig>

From angelogioacchino.delregno at collabora.com  Wed Dec 13 03:09:10 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 13 Dec 2023 12:09:10 +0100
Subject: [PATCH] arm64: mediatek: remove broken pmic interrupt property
In-Reply-To: <20231212214737.230115-1-arnd@kernel.org>
References: <20231212214737.230115-1-arnd@kernel.org>
Message-ID: <bc5dafe4-5487-4794-97f1-f4e4d967a665@collabora.com>

Il 12/12/23 22:47, Arnd Bergmann ha scritto:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> The pmic is connected to the GIC, which uses four-cell interrupt properties,
> but its interrupt is specified as two-cell that would only make sense for
> the GPIO irqchip:
> 
> arch/arm64/boot/dts/mediatek/mt8195.dtsi:464.4-27: Warning (interrupts_property): /soc/i2c at 11d01000/pmic at 34:#interrupt-cells: size is (8), expected multiple of 16
> 
> Remove the interrupt for now to shut up the warning. When someone figures out
> what the correct interrupt and parent are, we can add it back.
> 

Please, can anyone from MediaTek comment on that?

I see a mt6360_pins on PIO:
			pinmux = <PINMUX_GPIO17__FUNC_GPIO17>,
				 <PINMUX_GPIO128__FUNC_GPIO128>;

...and that's GPIO128, which may effectively be the IRQ pin for MT6360.

Still, I'm not sure whether the interrupt is on GIC or PIO, please clarify,
otherwise we will have to get this commit upstream.

Thanks,
Angelo

> Fixes: f2b543a191b6 ("arm64: dts: mediatek: add device-tree for Genio 1200 EVK board")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>   arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
> index 70b465f7c6a7..a409ef998746 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
> @@ -238,8 +238,6 @@ &i2c6 {
>   	mt6360: pmic at 34 {
>   		compatible = "mediatek,mt6360";
>   		reg = <0x34>;
> -		interrupts = <128 IRQ_TYPE_EDGE_FALLING>;
> -		interrupt-names = "IRQB";
>   		interrupt-controller;
>   		#interrupt-cells = <1>;
>   		pinctrl-0 = <&mt6360_pins>;




From angelogioacchino.delregno at collabora.com  Wed Dec 13 03:17:17 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 13 Dec 2023 12:17:17 +0100
Subject: [PATCH 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1
 isoc-in transfer issue
In-Reply-To: <c1bc144d-07d6-422c-8294-42be47f83e59@linaro.org>
References: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
 <c1bc144d-07d6-422c-8294-42be47f83e59@linaro.org>
Message-ID: <5327b2fd-94c6-46fe-b987-52cfff042033@collabora.com>

Il 13/12/23 09:05, Krzysztof Kozlowski ha scritto:
> On 13/12/2023 07:35, Chunfeng Yun wrote:
>> For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
>> still send out unexpected ACK after receiving a short packet in burst
>> transfer, this will cause an exception on connected device, specially for
>> a 4k camera.
>> Add a quirk property "mediatek,rxfifo-depth" to work around this hardware
>> issue;
>> The side-effect is that may cause performance drop about 10%, including
>> bulk transfer.
>>
>> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
>> ---
>>   .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml     | 10 ++++++++++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>> index e9644e333d78..b8ed68574ba4 100644
>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>> @@ -124,6 +124,16 @@ properties:
>>         defined in the xHCI spec on MTK's controller.
>>       default: 5000
>>   
>> +  mediatek,rxfifo-depth:
>> +    description:
> 
> The property description and driver patch suggest you configure the
> depth of FIFO, so this should be not bool, but some uint32. And then,
> use generic "fifo-depth" property to set desired depth.

Did you mean "rx-fifo-depth" instead, as used in net?
This FIFO depth parameter is for RX only.

Cheers,
Angelo




From lkp at intel.com  Wed Dec 13 03:22:33 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 13 Dec 2023 19:22:33 +0800
Subject: [PATCH 06/15] arm64: Add KHO support
In-Reply-To: <20231213000452.88295-7-graf@amazon.com>
References: <20231213000452.88295-7-graf@amazon.com>
Message-ID: <202312131958.BJ7skdaN-lkp@intel.com>

Hi Alexander,

kernel test robot noticed the following build warnings:

[auto build test WARNING on tip/x86/core]
[also build test WARNING on arm64/for-next/core akpm-mm/mm-everything linus/master v6.7-rc5 next-20231213]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Alexander-Graf/mm-memblock-Add-support-for-scratch-memory/20231213-080941
base:   tip/x86/core
patch link:    https://lore.kernel.org/r/20231213000452.88295-7-graf%40amazon.com
patch subject: [PATCH 06/15] arm64: Add KHO support
config: i386-buildonly-randconfig-001-20231213 (https://download.01.org/0day-ci/archive/20231213/202312131958.BJ7skdaN-lkp at intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231213/202312131958.BJ7skdaN-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312131958.BJ7skdaN-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> drivers/of/fdt.c:1012:13: warning: no previous prototype for function 'early_init_dt_check_kho' [-Wmissing-prototypes]
   void __init early_init_dt_check_kho(void)
               ^
   drivers/of/fdt.c:1012:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void __init early_init_dt_check_kho(void)
   ^
   static 
   1 warning generated.


vim +/early_init_dt_check_kho +1012 drivers/of/fdt.c

  1008	
  1009	/**
  1010	 * early_init_dt_check_kho - Decode info required for kexec handover from DT
  1011	 */
> 1012	void __init early_init_dt_check_kho(void)
  1013	{
  1014	#ifdef CONFIG_KEXEC_KHO
  1015		unsigned long node = chosen_node_offset;
  1016		u64 kho_start, scratch_start, scratch_size, mem_start, mem_size;
  1017		const __be32 *p;
  1018		int l;
  1019	
  1020		if ((long)node < 0)
  1021			return;
  1022	
  1023		p = of_get_flat_dt_prop(node, "linux,kho-dt", &l);
  1024		if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
  1025			return;
  1026	
  1027		kho_start = dt_mem_next_cell(dt_root_addr_cells, &p);
  1028	
  1029		p = of_get_flat_dt_prop(node, "linux,kho-scratch", &l);
  1030		if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
  1031			return;
  1032	
  1033		scratch_start = dt_mem_next_cell(dt_root_addr_cells, &p);
  1034		scratch_size = dt_mem_next_cell(dt_root_addr_cells, &p);
  1035	
  1036		p = of_get_flat_dt_prop(node, "linux,kho-mem", &l);
  1037		if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
  1038			return;
  1039	
  1040		mem_start = dt_mem_next_cell(dt_root_addr_cells, &p);
  1041		mem_size = dt_mem_next_cell(dt_root_addr_cells, &p);
  1042	
  1043		kho_populate(kho_start, scratch_start, scratch_size, mem_start, mem_size);
  1044	#endif
  1045	}
  1046	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Wed Dec 13 03:22:32 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 13 Dec 2023 19:22:32 +0800
Subject: [PATCH 08/15] tracing: Introduce names for ring buffers
In-Reply-To: <20231213000452.88295-9-graf@amazon.com>
References: <20231213000452.88295-9-graf@amazon.com>
Message-ID: <202312131922.5dJORQu4-lkp@intel.com>

Hi Alexander,

kernel test robot noticed the following build errors:

[auto build test ERROR on tip/x86/core]
[also build test ERROR on arm64/for-next/core akpm-mm/mm-everything linus/master v6.7-rc5 next-20231213]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Alexander-Graf/mm-memblock-Add-support-for-scratch-memory/20231213-080941
base:   tip/x86/core
patch link:    https://lore.kernel.org/r/20231213000452.88295-9-graf%40amazon.com
patch subject: [PATCH 08/15] tracing: Introduce names for ring buffers
config: i386-buildonly-randconfig-003-20231213 (https://download.01.org/0day-ci/archive/20231213/202312131922.5dJORQu4-lkp at intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231213/202312131922.5dJORQu4-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312131922.5dJORQu4-lkp at intel.com/

All errors (new ones prefixed by >>):

>> kernel/trace/ring_buffer_benchmark.c:435:53: error: too few arguments provided to function-like macro invocation
           buffer = ring_buffer_alloc(1000000, RB_FL_OVERWRITE);
                                                              ^
   include/linux/ring_buffer.h:96:9: note: macro 'ring_buffer_alloc' defined here
   #define ring_buffer_alloc(name, size, flags)                    \
           ^
>> kernel/trace/ring_buffer_benchmark.c:435:11: error: use of undeclared identifier 'ring_buffer_alloc'; did you mean '__ring_buffer_alloc'?
           buffer = ring_buffer_alloc(1000000, RB_FL_OVERWRITE);
                    ^~~~~~~~~~~~~~~~~
                    __ring_buffer_alloc
   include/linux/ring_buffer.h:88:1: note: '__ring_buffer_alloc' declared here
   __ring_buffer_alloc(const char *name, unsigned long size, unsigned flags,
   ^
   2 errors generated.
--
>> kernel/trace/ring_buffer.c:6096:65: error: too few arguments provided to function-like macro invocation
           buffer = ring_buffer_alloc(RB_TEST_BUFFER_SIZE, RB_FL_OVERWRITE);
                                                                          ^
   include/linux/ring_buffer.h:96:9: note: macro 'ring_buffer_alloc' defined here
   #define ring_buffer_alloc(name, size, flags)                    \
           ^
>> kernel/trace/ring_buffer.c:6096:11: error: use of undeclared identifier 'ring_buffer_alloc'; did you mean '__ring_buffer_alloc'?
           buffer = ring_buffer_alloc(RB_TEST_BUFFER_SIZE, RB_FL_OVERWRITE);
                    ^~~~~~~~~~~~~~~~~
                    __ring_buffer_alloc
   kernel/trace/ring_buffer.c:1873:19: note: '__ring_buffer_alloc' declared here
   EXPORT_SYMBOL_GPL(__ring_buffer_alloc);
                     ^
   2 errors generated.


vim +435 kernel/trace/ring_buffer_benchmark.c

5092dbc96f3acd Steven Rostedt 2009-05-05  429  
5092dbc96f3acd Steven Rostedt 2009-05-05  430  static int __init ring_buffer_benchmark_init(void)
5092dbc96f3acd Steven Rostedt 2009-05-05  431  {
5092dbc96f3acd Steven Rostedt 2009-05-05  432  	int ret;
5092dbc96f3acd Steven Rostedt 2009-05-05  433  
5092dbc96f3acd Steven Rostedt 2009-05-05  434  	/* make a one meg buffer in overwite mode */
5092dbc96f3acd Steven Rostedt 2009-05-05 @435  	buffer = ring_buffer_alloc(1000000, RB_FL_OVERWRITE);
5092dbc96f3acd Steven Rostedt 2009-05-05  436  	if (!buffer)
5092dbc96f3acd Steven Rostedt 2009-05-05  437  		return -ENOMEM;
5092dbc96f3acd Steven Rostedt 2009-05-05  438  
5092dbc96f3acd Steven Rostedt 2009-05-05  439  	if (!disable_reader) {
5092dbc96f3acd Steven Rostedt 2009-05-05  440  		consumer = kthread_create(ring_buffer_consumer_thread,
5092dbc96f3acd Steven Rostedt 2009-05-05  441  					  NULL, "rb_consumer");
5092dbc96f3acd Steven Rostedt 2009-05-05  442  		ret = PTR_ERR(consumer);
5092dbc96f3acd Steven Rostedt 2009-05-05  443  		if (IS_ERR(consumer))
5092dbc96f3acd Steven Rostedt 2009-05-05  444  			goto out_fail;
5092dbc96f3acd Steven Rostedt 2009-05-05  445  	}
5092dbc96f3acd Steven Rostedt 2009-05-05  446  
5092dbc96f3acd Steven Rostedt 2009-05-05  447  	producer = kthread_run(ring_buffer_producer_thread,
5092dbc96f3acd Steven Rostedt 2009-05-05  448  			       NULL, "rb_producer");
5092dbc96f3acd Steven Rostedt 2009-05-05  449  	ret = PTR_ERR(producer);
5092dbc96f3acd Steven Rostedt 2009-05-05  450  
5092dbc96f3acd Steven Rostedt 2009-05-05  451  	if (IS_ERR(producer))
5092dbc96f3acd Steven Rostedt 2009-05-05  452  		goto out_kill;
5092dbc96f3acd Steven Rostedt 2009-05-05  453  
98e4833ba3c314 Ingo Molnar    2009-11-23  454  	/*
98e4833ba3c314 Ingo Molnar    2009-11-23  455  	 * Run them as low-prio background tasks by default:
98e4833ba3c314 Ingo Molnar    2009-11-23  456  	 */
7ac07434048001 Steven Rostedt 2009-11-25  457  	if (!disable_reader) {
4fd5750af02ab7 Peter Zijlstra 2020-07-20  458  		if (consumer_fifo >= 2)
4fd5750af02ab7 Peter Zijlstra 2020-07-20  459  			sched_set_fifo(consumer);
4fd5750af02ab7 Peter Zijlstra 2020-07-20  460  		else if (consumer_fifo == 1)
4fd5750af02ab7 Peter Zijlstra 2020-07-20  461  			sched_set_fifo_low(consumer);
4fd5750af02ab7 Peter Zijlstra 2020-07-20  462  		else
7ac07434048001 Steven Rostedt 2009-11-25  463  			set_user_nice(consumer, consumer_nice);
7ac07434048001 Steven Rostedt 2009-11-25  464  	}
7ac07434048001 Steven Rostedt 2009-11-25  465  
4fd5750af02ab7 Peter Zijlstra 2020-07-20  466  	if (producer_fifo >= 2)
4fd5750af02ab7 Peter Zijlstra 2020-07-20  467  		sched_set_fifo(producer);
4fd5750af02ab7 Peter Zijlstra 2020-07-20  468  	else if (producer_fifo == 1)
4fd5750af02ab7 Peter Zijlstra 2020-07-20  469  		sched_set_fifo_low(producer);
4fd5750af02ab7 Peter Zijlstra 2020-07-20  470  	else
7ac07434048001 Steven Rostedt 2009-11-25  471  		set_user_nice(producer, producer_nice);
98e4833ba3c314 Ingo Molnar    2009-11-23  472  
5092dbc96f3acd Steven Rostedt 2009-05-05  473  	return 0;
5092dbc96f3acd Steven Rostedt 2009-05-05  474  
5092dbc96f3acd Steven Rostedt 2009-05-05  475   out_kill:
5092dbc96f3acd Steven Rostedt 2009-05-05  476  	if (consumer)
5092dbc96f3acd Steven Rostedt 2009-05-05  477  		kthread_stop(consumer);
5092dbc96f3acd Steven Rostedt 2009-05-05  478  
5092dbc96f3acd Steven Rostedt 2009-05-05  479   out_fail:
5092dbc96f3acd Steven Rostedt 2009-05-05  480  	ring_buffer_free(buffer);
5092dbc96f3acd Steven Rostedt 2009-05-05  481  	return ret;
5092dbc96f3acd Steven Rostedt 2009-05-05  482  }
5092dbc96f3acd Steven Rostedt 2009-05-05  483  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From krzysztof.kozlowski at linaro.org  Wed Dec 13 03:24:58 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 12:24:58 +0100
Subject: [PATCH 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1
 isoc-in transfer issue
In-Reply-To: <5327b2fd-94c6-46fe-b987-52cfff042033@collabora.com>
References: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
 <c1bc144d-07d6-422c-8294-42be47f83e59@linaro.org>
 <5327b2fd-94c6-46fe-b987-52cfff042033@collabora.com>
Message-ID: <8745cfde-57d1-4b08-9020-bbec9b9c7fc1@linaro.org>

On 13/12/2023 12:17, AngeloGioacchino Del Regno wrote:
> Il 13/12/23 09:05, Krzysztof Kozlowski ha scritto:
>> On 13/12/2023 07:35, Chunfeng Yun wrote:
>>> For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
>>> still send out unexpected ACK after receiving a short packet in burst
>>> transfer, this will cause an exception on connected device, specially for
>>> a 4k camera.
>>> Add a quirk property "mediatek,rxfifo-depth" to work around this hardware
>>> issue;
>>> The side-effect is that may cause performance drop about 10%, including
>>> bulk transfer.
>>>
>>> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
>>> ---
>>>   .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml     | 10 ++++++++++
>>>   1 file changed, 10 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>>> index e9644e333d78..b8ed68574ba4 100644
>>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>>> @@ -124,6 +124,16 @@ properties:
>>>         defined in the xHCI spec on MTK's controller.
>>>       default: 5000
>>>   
>>> +  mediatek,rxfifo-depth:
>>> +    description:
>>
>> The property description and driver patch suggest you configure the
>> depth of FIFO, so this should be not bool, but some uint32. And then,
>> use generic "fifo-depth" property to set desired depth.
> 
> Did you mean "rx-fifo-depth" instead, as used in net?
> This FIFO depth parameter is for RX only.

I guess yes, if it is specific to RX.

Best regards,
Krzysztof



From ulf.hansson at linaro.org  Wed Dec 13 03:32:45 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 13 Dec 2023 12:32:45 +0100
Subject: [PATCH 1/2] PM: domains: Drop redundant header for genpd
Message-ID: <20231213113245.29075-1-ulf.hansson@linaro.org>

The "power.h" is no longer needed by genpd, so let's simply drop the
include of it.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/base/power/domain.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index cf65b5a9783c..9ee1bf2ece10 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -23,8 +23,6 @@
 #include <linux/cpu.h>
 #include <linux/debugfs.h>
 
-#include "power.h"
-
 #define GENPD_RETRY_MAX_MS	250		/* Approximate */
 
 #define GENPD_DEV_CALLBACK(genpd, type, callback, dev)		\
-- 
2.34.1



From lkp at intel.com  Wed Dec 13 03:32:49 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 13 Dec 2023 19:32:49 +0800
Subject: [PATCH 02/15] memblock: Declare scratch memory as CMA
In-Reply-To: <20231213000452.88295-3-graf@amazon.com>
References: <20231213000452.88295-3-graf@amazon.com>
Message-ID: <202312131930.gMiphjju-lkp@intel.com>

Hi Alexander,

kernel test robot noticed the following build warnings:

[auto build test WARNING on tip/x86/core]
[also build test WARNING on arm64/for-next/core akpm-mm/mm-everything linus/master v6.7-rc5 next-20231213]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Alexander-Graf/mm-memblock-Add-support-for-scratch-memory/20231213-080941
base:   tip/x86/core
patch link:    https://lore.kernel.org/r/20231213000452.88295-3-graf%40amazon.com
patch subject: [PATCH 02/15] memblock: Declare scratch memory as CMA
config: arc-allnoconfig (https://download.01.org/0day-ci/archive/20231213/202312131930.gMiphjju-lkp at intel.com/config)
compiler: arc-elf-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231213/202312131930.gMiphjju-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312131930.gMiphjju-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> mm/memblock.c:2153:13: warning: 'reserve_scratch_mem' defined but not used [-Wunused-function]
    2153 | static void reserve_scratch_mem(phys_addr_t start, phys_addr_t end)
         |             ^~~~~~~~~~~~~~~~~~~


vim +/reserve_scratch_mem +2153 mm/memblock.c

  2152	
> 2153	static void reserve_scratch_mem(phys_addr_t start, phys_addr_t end)
  2154	{
  2155	#ifdef CONFIG_MEMBLOCK_SCRATCH
  2156		ulong start_pfn = pageblock_start_pfn(PFN_DOWN(start));
  2157		ulong end_pfn = pageblock_align(PFN_UP(end));
  2158		ulong pfn;
  2159	
  2160		for (pfn = start_pfn; pfn < end_pfn; pfn += pageblock_nr_pages) {
  2161			/* Mark as CMA to prevent kernel allocations in it */
  2162			set_pageblock_migratetype(pfn_to_page(pfn), MIGRATE_CMA);
  2163		}
  2164	#endif
  2165	}
  2166	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From ulf.hansson at linaro.org  Wed Dec 13 03:33:05 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 13 Dec 2023 12:33:05 +0100
Subject: [PATCH 2/2] PM: domains: Move genpd and its governor to the pmdomain subsystem
Message-ID: <20231213113305.29098-1-ulf.hansson@linaro.org>

It seems reasonable to collect the core parts for the generic PM domain,
along with its corresponding provider drivers. Therefore let's move the
files from drivers/base/power/ to drivers/pmdomain/ and while at it, let's
also rename the files accordingly.

Moreover, let's also update MAINTAINERS to reflect the update.

Cc: Kevin Hilman <khilman at kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 MAINTAINERS                                            | 10 +---------
 drivers/base/power/Makefile                            |  1 -
 drivers/pmdomain/Makefile                              |  1 +
 drivers/{base/power/domain.c => pmdomain/core.c}       |  0
 .../power/domain_governor.c => pmdomain/governor.c}    |  0
 5 files changed, 2 insertions(+), 10 deletions(-)
 rename drivers/{base/power/domain.c => pmdomain/core.c} (100%)
 rename drivers/{base/power/domain_governor.c => pmdomain/governor.c} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index ea790149af79..ab4b0aed34f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8878,21 +8878,13 @@ F:	Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
 F:	drivers/i2c/muxes/i2c-demux-pinctrl.c
 
 GENERIC PM DOMAINS
-M:	"Rafael J. Wysocki" <rafael at kernel.org>
-M:	Kevin Hilman <khilman at kernel.org>
 M:	Ulf Hansson <ulf.hansson at linaro.org>
 L:	linux-pm at vger.kernel.org
 S:	Supported
 F:	Documentation/devicetree/bindings/power/power?domain*
-F:	drivers/base/power/domain*.c
-F:	include/linux/pm_domain.h
-
-GENERIC PM DOMAIN PROVIDERS
-M:	Ulf Hansson <ulf.hansson at linaro.org>
-L:	linux-pm at vger.kernel.org
-S:	Supported
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git
 F:	drivers/pmdomain/
+F:	include/linux/pm_domain.h
 
 GENERIC RADIX TREE
 M:	Kent Overstreet <kent.overstreet at linux.dev>
diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
index 8fdd0073eeeb..01f11629d241 100644
--- a/drivers/base/power/Makefile
+++ b/drivers/base/power/Makefile
@@ -2,7 +2,6 @@
 obj-$(CONFIG_PM)	+= sysfs.o generic_ops.o common.o qos.o runtime.o wakeirq.o
 obj-$(CONFIG_PM_SLEEP)	+= main.o wakeup.o wakeup_stats.o
 obj-$(CONFIG_PM_TRACE_RTC)	+= trace.o
-obj-$(CONFIG_PM_GENERIC_DOMAINS)	+=  domain.o domain_governor.o
 obj-$(CONFIG_HAVE_CLK)	+= clock_ops.o
 obj-$(CONFIG_PM_QOS_KUNIT_TEST) += qos-test.o
 
diff --git a/drivers/pmdomain/Makefile b/drivers/pmdomain/Makefile
index f0326b27b30b..a68ece2f4c68 100644
--- a/drivers/pmdomain/Makefile
+++ b/drivers/pmdomain/Makefile
@@ -16,3 +16,4 @@ obj-y					+= sunxi/
 obj-y					+= tegra/
 obj-y					+= ti/
 obj-y					+= xilinx/
+obj-y					+= core.o governor.o
diff --git a/drivers/base/power/domain.c b/drivers/pmdomain/core.c
similarity index 100%
rename from drivers/base/power/domain.c
rename to drivers/pmdomain/core.c
diff --git a/drivers/base/power/domain_governor.c b/drivers/pmdomain/governor.c
similarity index 100%
rename from drivers/base/power/domain_governor.c
rename to drivers/pmdomain/governor.c
-- 
2.34.1



From ppaalanen at gmail.com  Wed Dec 13 03:38:25 2023
From: ppaalanen at gmail.com (Pekka Paalanen)
Date: Wed, 13 Dec 2023 13:38:25 +0200
Subject: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
In-Reply-To: <20231213101549.lioqfzjxcvmqxqu3@pop-os.localdomain>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
	<DPBmATfmfvSP8Cwjz99kj_JvCEiAqRfuMFJZEBF2aIgl8NZqWFR66eyPTX1E8bHyOlimBihEE3E80p9bfOJ-0SNu8pwoIzL9gD2Xae6r97g=@emersion.fr>
	<20231213110517.6ce36aca@eldfell>
	<20231213101549.lioqfzjxcvmqxqu3@pop-os.localdomain>
Message-ID: <20231213133825.0a329864@eldfell>

On Wed, 13 Dec 2023 11:15:49 +0100
Joakim Bech <joakim.bech at linaro.org> wrote:

> On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> > On Tue, 12 Dec 2023 16:36:35 +0000
> > Simon Ser <contact at emersion.fr> wrote:
> >   
> > > Is there a chance to pick a better name than "secure" here?
> > > 
> > > "Secure" is super overloaded, it's not clear at all what it means from
> > > just the name. Something like "restricted" would be an improvement.
> > >   
> > 
> > My thoughts exactly. Every time I see "secure" used for something that
> > either gives you garbage, refuses to work, or crashes your whole machine
> > *intentionally* when you try to do normal usual things to it in
> > userspace (like use it for GL texturing, or try to use KMS writeback), I
> > get an unscratchable itch.
> > 
> > There is nothing "secure" from security perspective there for end users
> > and developers. It's just inaccessible buffers.
> > 
> > I've been biting my lip until now, thinking it's too late.
> >   
> The characteristics we're looking for here is a buffer where the content
> is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
> EL2. I.e, the content of the buffer is meant to be used and accessible
> primarily by the secure side and other devices that has been granted

s/secure side/proprietary side/

I presume nothing of the other side can ever be in any way open?

Maybe the other side is even less secure than the FOSS side...

> access to it (for example decoders, display controllers if we're talking
> about video use cases). However, since the use cases for this exercises
> the whole stack, from non-secure user space (EL0) all the way to secure
> user space (S-EL0), with various devices needing access to the buffer at
> various times, it makes sense to let Linux manage the buffers, although
> it still cannot access the content. That's the overall context.

Yes, we know all this (except for the exact meaning of EL0 etc.).

> As for the name, it's always difficult to find a name suitable precisely
> describing what it is. "Secure" is perhaps vague, but it might still a
> good choice, if you carefully describe what secure means for this
> particular heap (in the source code and the documentation for it). For

Carefully describe, as in, re-define.

> example, the definition of "secure" for a secure heap as here could mean
> that buffer content is inaccessible to the host OS and user space
> running in normal world (using Arm nomenclature). I wouldn't have any
> problems with calling it secure if, as said it's defined what we mean by
> saying so. But I'm all ears for other suggestions as well.
> 
> Safe, protected, shielded, unreachable, isolated, inaccessible,
> unaccessible, fortified, ... would any of these make more sense?

"Restricted" sounds like a good compromise to me. The buffers' usage is
severely restricted.

It is the opposite of "safe", because accessing the contents the wrong
way can return garbage or intentionally crash the whole system,
depending on the hardware implementation. One example is attempting to
put such a buffer on a KMS plane while the connector HDCP state is not
high enough, or a writeback connector is connected to the CRTC. It is
really fragile. (Do KMS drivers fail an atomic commit that would
violate the heap rules? Somehow I doubt that, who'd even know what the
rules are.)

It is protected/shielded/fortified from all the kernel and userspace,
but a more familiar word to describe that is inaccessible.
"Inaccessible buffer" per se OTOH sounds like a useless concept.

It is not secure, because it does not involve security in any way. In
fact, given it's so fragile, I'd classify it as mildly opposite of
secure, as e.g. clients of a Wayland compositor can potentially DoS the
compositor with it by simply sending such a dmabuf. Or DoS the whole
system.

"Poisonous heap" would be fitting but politically inappropriate I
guess. After all, "poison" is data that is not meant to be read by
anything normal.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/c1017619/attachment-0001.sig>

From zhourui at huaqin.corp-partner.google.com  Wed Dec 13 03:39:51 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Wed, 13 Dec 2023 19:39:51 +0800
Subject: [RESEND PATCH v9 0/4] add es8326 dt-bindings, commonize headset codec API, es8326 support and Enable dual amp for rt5682s
Message-ID: <20231213113955.47668-1-zhourui@huaqin.corp-partner.google.com>

Add dt-bindings for es8326 and codec es8326 support. 
Remove duplicate code, commonize headset codec init/exit API.
At the same time, Enable dual amp max98390 for rt5682s.

Changes in v9:
- PATCH 3/4: Add comment for MAX98390_TWO_AMP.
- Link to v8: https://lore.kernel.org/all/20231208070933.720324-1-zhourui at huaqin.corp-partner.google.com/

Changes in v8:
- PATCH 3/4: Change the #define ES8326_CODEC_DAI macro definition and filter the es8326 widget
- Link to v7: https://lore.kernel.org/all/20231116093512.4180240-1-zhourui at huaqin.corp-partner.google.com/

Changes in v7:
- PATCH 3/4: Completion "}"
- Link to v6: https://lore.kernel.org/all/20231116073106.3757618-1-zhourui at huaqin.corp-partner.google.com/

Changes in v6:
- PATCH 2/4: add a patch, commonize headset codec init/exit API
- PATCH 3/4: Remove generalized code
- Link to v5: https://lore.kernel.org/all/20231115090903.578438-1-zhourui at huaqin.corp-partner.google.com/

Changes in v5:
- PATCH 2/3: Change the names of some apis
- Link to v4: https://lore.kernel.org/all/20231115085329.541764-1-zhourui at huaqin.corp-partner.google.com/

Changes in v4:
- PATCH 2/3: Change the names of some apis
- PATCH 3/3: Change commit description
- Link to v3: https://lore.kernel.org/all/20231108063804.592982-1-zhourui at huaqin.corp-partner.google.com/

Changes in v3:
- PATCH 3/3: Change theme description
- Link to v2: https://lore.kernel.org/all/20231108012617.3973539-1-zhourui at huaqin.corp-partner.google.com/

Changes in v2:
- PATCH 1/3: Change ES8326 location in bindings
- PATCH 3/3: Change theme description
- Link to v1: https://lore.kernel.org/all/20231107031442.2768765-1-zhourui at huaqin.corp-partner.google.com/

Rui Zhou (4):
  ASoC: dt-bindings: mt8188-mt6359: add es8326 support
  ASoC: mediatek: mt8188-mt6359: commonize headset codec init/exit api
  ASoC: mediatek: mt8188-mt6359: add es8326 support
  ASoC: mediatek: mt8188-mt6359: Enable dual amp for mt8188-rt5682s

 .../sound/mediatek,mt8188-mt6359.yaml         |   1 +
 sound/soc/mediatek/Kconfig                    |   1 +
 sound/soc/mediatek/mt8188/mt8188-mt6359.c     | 125 +++++++++---------
 3 files changed, 63 insertions(+), 64 deletions(-)

-- 
2.25.1



From zhourui at huaqin.corp-partner.google.com  Wed Dec 13 03:39:52 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Wed, 13 Dec 2023 19:39:52 +0800
Subject: [RESEND PATCH v9 1/4] ASoC: dt-bindings: mt8188-mt6359: add es8326 support
In-Reply-To: <20231213113955.47668-1-zhourui@huaqin.corp-partner.google.com>
References: <20231213113955.47668-1-zhourui@huaqin.corp-partner.google.com>
Message-ID: <20231213113955.47668-2-zhourui@huaqin.corp-partner.google.com>

Add compatible string "mediatek,mt8188-es8326" to support new board
with es8326 codec.

Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Rui Zhou <zhourui at huaqin.corp-partner.google.com>
---
 .../devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml        | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
index 4c8c95057ef7..f94ad0715e32 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
@@ -15,6 +15,7 @@ allOf:
 properties:
   compatible:
     enum:
+      - mediatek,mt8188-es8326
       - mediatek,mt8188-mt6359-evb
       - mediatek,mt8188-nau8825
       - mediatek,mt8188-rt5682s
-- 
2.25.1



From zhourui at huaqin.corp-partner.google.com  Wed Dec 13 03:39:53 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Wed, 13 Dec 2023 19:39:53 +0800
Subject: [RESEND PATCH v9 2/4] ASoC: mediatek: mt8188-mt6359: commonize headset codec init/exit api
In-Reply-To: <20231213113955.47668-1-zhourui@huaqin.corp-partner.google.com>
References: <20231213113955.47668-1-zhourui@huaqin.corp-partner.google.com>
Message-ID: <20231213113955.47668-3-zhourui@huaqin.corp-partner.google.com>

Reduce code duplication, unify the headset codec init/exit api.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Rui Zhou <zhourui at huaqin.corp-partner.google.com>
---
 sound/soc/mediatek/mt8188/mt8188-mt6359.c | 67 ++---------------------
 1 file changed, 6 insertions(+), 61 deletions(-)

diff --git a/sound/soc/mediatek/mt8188/mt8188-mt6359.c b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
index 33d477cc2e54..b4606a28794c 100644
--- a/sound/soc/mediatek/mt8188/mt8188-mt6359.c
+++ b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
@@ -726,7 +726,7 @@ static int mt8188_max98390_codec_init(struct snd_soc_pcm_runtime *rtd)
 	return 0;
 }
 
-static int mt8188_nau8825_codec_init(struct snd_soc_pcm_runtime *rtd)
+static int mt8188_headset_codec_init(struct snd_soc_pcm_runtime *rtd)
 {
 	struct snd_soc_card *card = rtd->card;
 	struct mtk_soc_card_data *soc_card_data = snd_soc_card_get_drvdata(card);
@@ -775,68 +775,13 @@ static int mt8188_nau8825_codec_init(struct snd_soc_pcm_runtime *rtd)
 	return 0;
 };
 
-static int mt8188_rt5682s_codec_init(struct snd_soc_pcm_runtime *rtd)
-{
-	struct snd_soc_card *card = rtd->card;
-	struct mtk_soc_card_data *soc_card_data = snd_soc_card_get_drvdata(card);
-	struct mt8188_mt6359_priv *priv = soc_card_data->mach_priv;
-	struct snd_soc_component *component = snd_soc_rtd_to_codec(rtd, 0)->component;
-	struct snd_soc_jack *jack = &priv->headset_jack;
-	int ret;
-
-	ret = snd_soc_dapm_new_controls(&card->dapm, mt8188_nau8825_widgets,
-					ARRAY_SIZE(mt8188_nau8825_widgets));
-	if (ret) {
-		dev_err(rtd->dev, "unable to add rt5682s card widget, ret %d\n", ret);
-		return ret;
-	}
-
-	ret = snd_soc_add_card_controls(card, mt8188_nau8825_controls,
-					ARRAY_SIZE(mt8188_nau8825_controls));
-	if (ret) {
-		dev_err(rtd->dev, "unable to add rt5682s card controls, ret %d\n", ret);
-		return ret;
-	}
-
-	ret = snd_soc_card_jack_new_pins(rtd->card, "Headset Jack",
-					 SND_JACK_HEADSET | SND_JACK_BTN_0 |
-					 SND_JACK_BTN_1 | SND_JACK_BTN_2 |
-					 SND_JACK_BTN_3,
-					 jack,
-					 nau8825_jack_pins,
-					 ARRAY_SIZE(nau8825_jack_pins));
-	if (ret) {
-		dev_err(rtd->dev, "Headset Jack creation failed: %d\n", ret);
-		return ret;
-	}
-
-	snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
-	snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
-	snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
-	snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);
-	ret = snd_soc_component_set_jack(component, jack, NULL);
-
-	if (ret) {
-		dev_err(rtd->dev, "Headset Jack call-back failed: %d\n", ret);
-		return ret;
-	}
-
-	return 0;
-};
-
-static void mt8188_nau8825_codec_exit(struct snd_soc_pcm_runtime *rtd)
+static void mt8188_headset_codec_exit(struct snd_soc_pcm_runtime *rtd)
 {
 	struct snd_soc_component *component = snd_soc_rtd_to_codec(rtd, 0)->component;
 
 	snd_soc_component_set_jack(component, NULL, NULL);
 }
 
-static void mt8188_rt5682s_codec_exit(struct snd_soc_pcm_runtime *rtd)
-{
-	struct snd_soc_component *component = snd_soc_rtd_to_codec(rtd, 0)->component;
-
-	snd_soc_component_set_jack(component, NULL, NULL);
-}
 
 static int mt8188_nau8825_hw_params(struct snd_pcm_substream *substream,
 				    struct snd_pcm_hw_params *params)
@@ -1407,15 +1352,15 @@ static int mt8188_mt6359_dev_probe(struct platform_device *pdev)
 			} else if (!strcmp(dai_link->codecs->dai_name, NAU8825_CODEC_DAI)) {
 				dai_link->ops = &mt8188_nau8825_ops;
 				if (!init_nau8825) {
-					dai_link->init = mt8188_nau8825_codec_init;
-					dai_link->exit = mt8188_nau8825_codec_exit;
+					dai_link->init = mt8188_headset_codec_init;
+					dai_link->exit = mt8188_headset_codec_exit;
 					init_nau8825 = true;
 				}
 			} else if (!strcmp(dai_link->codecs->dai_name, RT5682S_CODEC_DAI)) {
 				dai_link->ops = &mt8188_rt5682s_i2s_ops;
 				if (!init_rt5682s) {
-					dai_link->init = mt8188_rt5682s_codec_init;
-					dai_link->exit = mt8188_rt5682s_codec_exit;
+					dai_link->init = mt8188_headset_codec_init;
+					dai_link->exit = mt8188_headset_codec_exit;
 					init_rt5682s = true;
 				}
 			} else {
-- 
2.25.1



From zhourui at huaqin.corp-partner.google.com  Wed Dec 13 03:39:54 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Wed, 13 Dec 2023 19:39:54 +0800
Subject: [RESEND PATCH v9 3/4] ASoC: mediatek: mt8188-mt6359: add es8326 support
In-Reply-To: <20231213113955.47668-1-zhourui@huaqin.corp-partner.google.com>
References: <20231213113955.47668-1-zhourui@huaqin.corp-partner.google.com>
Message-ID: <20231213113955.47668-4-zhourui@huaqin.corp-partner.google.com>

To use ES8326 as the codec, add a new sound card
named mt8186_es8326.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Reviewed-by: Trevor Wu <trevor.wu at mediatek.com>
Signed-off-by: Rui Zhou <zhourui at huaqin.corp-partner.google.com>
---
 sound/soc/mediatek/Kconfig                |  1 +
 sound/soc/mediatek/mt8188/mt8188-mt6359.c | 56 ++++++++++++++++++++++-
 2 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig
index b93d455744ab..296b434caf81 100644
--- a/sound/soc/mediatek/Kconfig
+++ b/sound/soc/mediatek/Kconfig
@@ -252,6 +252,7 @@ config SND_SOC_MT8188_MT6359
 	select SND_SOC_NAU8315
 	select SND_SOC_NAU8825
 	select SND_SOC_RT5682S
+	select SND_SOC_ES8326
 	help
 	  This adds support for ASoC machine driver for MediaTek MT8188
 	  boards with the MT6359 and other I2S audio codecs.
diff --git a/sound/soc/mediatek/mt8188/mt8188-mt6359.c b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
index b4606a28794c..d1884f23a1a7 100644
--- a/sound/soc/mediatek/mt8188/mt8188-mt6359.c
+++ b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
@@ -34,6 +34,8 @@
 
 #define NAU8825_HS_PRESENT	BIT(0)
 #define RT5682S_HS_PRESENT	BIT(1)
+#define ES8326_HS_PRESENT	BIT(2)
+#define MAX98390_TWO_AMP	BIT(3)
 /*
  * Maxim MAX98390
  */
@@ -48,6 +50,11 @@
  */
 #define NAU8825_CODEC_DAI  "nau8825-hifi"
 
+/*
+ * ES8326
+ */
+#define ES8326_CODEC_DAI  "ES8326 HiFi"
+
 #define SOF_DMA_DL2 "SOF_DMA_DL2"
 #define SOF_DMA_DL3 "SOF_DMA_DL3"
 #define SOF_DMA_UL4 "SOF_DMA_UL4"
@@ -888,6 +895,30 @@ static const struct snd_soc_ops mt8188_sof_be_ops = {
 	.hw_params = mt8188_sof_be_hw_params,
 };
 
+static int mt8188_es8326_hw_params(struct snd_pcm_substream *substream,
+				 struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_pcm_runtime *rtd = snd_soc_substream_to_rtd(substream);
+	struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
+	struct snd_soc_dai *codec_dai = snd_soc_rtd_to_codec(rtd, 0);
+	unsigned int rate = params_rate(params);
+	int ret;
+
+	/* Configure MCLK for codec */
+	ret = snd_soc_dai_set_sysclk(codec_dai, 0, rate * 256, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		dev_err(codec_dai->dev, "can't set MCLK %d\n", ret);
+		return ret;
+	}
+
+	/* Configure MCLK for cpu */
+	return snd_soc_dai_set_sysclk(cpu_dai, 0, rate * 256, SND_SOC_CLOCK_OUT);
+}
+
+static const struct snd_soc_ops mt8188_es8326_ops = {
+	.hw_params = mt8188_es8326_hw_params,
+};
+
 static struct snd_soc_dai_link mt8188_mt6359_dai_links[] = {
 	/* FE */
 	[DAI_LINK_DL2_FE] = {
@@ -1197,7 +1228,7 @@ static void mt8188_fixup_controls(struct snd_soc_card *card)
 	struct mt8188_card_data *card_data = (struct mt8188_card_data *)priv->private_data;
 	struct snd_kcontrol *kctl;
 
-	if (card_data->quirk & (NAU8825_HS_PRESENT | RT5682S_HS_PRESENT)) {
+	if (card_data->quirk & (NAU8825_HS_PRESENT | RT5682S_HS_PRESENT | ES8326_HS_PRESENT)) {
 		struct snd_soc_dapm_widget *w, *next_w;
 
 		for_each_card_widgets_safe(card, w, next_w) {
@@ -1238,6 +1269,7 @@ static int mt8188_mt6359_dev_probe(struct platform_device *pdev)
 	struct mt8188_card_data *card_data;
 	struct snd_soc_dai_link *dai_link;
 	bool init_mt6359 = false;
+	bool init_es8326 = false;
 	bool init_nau8825 = false;
 	bool init_rt5682s = false;
 	bool init_max98390 = false;
@@ -1344,7 +1376,14 @@ static int mt8188_mt6359_dev_probe(struct platform_device *pdev)
 			   strcmp(dai_link->name, "ETDM1_IN_BE") == 0 ||
 			   strcmp(dai_link->name, "ETDM2_IN_BE") == 0) {
 			if (!strcmp(dai_link->codecs->dai_name, MAX98390_CODEC_DAI)) {
-				dai_link->ops = &mt8188_max98390_ops;
+				/*
+				 * The TDM protocol settings with fixed 4 slots are defined in
+				 * mt8188_max98390_ops. Two amps is I2S mode,
+				 * SOC and codec don't require TDM settings.
+				 */
+				if (!(card_data->quirk & MAX98390_TWO_AMP)) {
+					dai_link->ops = &mt8188_max98390_ops;
+				}
 				if (!init_max98390) {
 					dai_link->init = mt8188_max98390_codec_init;
 					init_max98390 = true;
@@ -1363,6 +1402,13 @@ static int mt8188_mt6359_dev_probe(struct platform_device *pdev)
 					dai_link->exit = mt8188_headset_codec_exit;
 					init_rt5682s = true;
 				}
+			} else if (!strcmp(dai_link->codecs->dai_name, ES8326_CODEC_DAI)) {
+				dai_link->ops = &mt8188_es8326_ops;
+				if (!init_es8326) {
+					dai_link->init = mt8188_headset_codec_init;
+					dai_link->exit = mt8188_headset_codec_exit;
+					init_es8326 = true;
+				}
 			} else {
 				if (strcmp(dai_link->codecs->dai_name, "snd-soc-dummy-dai")) {
 					if (!init_dumb) {
@@ -1405,10 +1451,16 @@ static struct mt8188_card_data mt8188_rt5682s_card = {
 	.quirk = RT5682S_HS_PRESENT,
 };
 
+static struct mt8188_card_data mt8188_es8326_card = {
+	.name = "mt8188_es8326",
+	.quirk = ES8326_HS_PRESENT | MAX98390_TWO_AMP,
+};
+
 static const struct of_device_id mt8188_mt6359_dt_match[] = {
 	{ .compatible = "mediatek,mt8188-mt6359-evb", .data = &mt8188_evb_card, },
 	{ .compatible = "mediatek,mt8188-nau8825", .data = &mt8188_nau8825_card, },
 	{ .compatible = "mediatek,mt8188-rt5682s", .data = &mt8188_rt5682s_card, },
+	{ .compatible = "mediatek,mt8188-es8326", .data = &mt8188_es8326_card, },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, mt8188_mt6359_dt_match);
-- 
2.25.1



From zhourui at huaqin.corp-partner.google.com  Wed Dec 13 03:39:55 2023
From: zhourui at huaqin.corp-partner.google.com (Rui Zhou)
Date: Wed, 13 Dec 2023 19:39:55 +0800
Subject: [RESEND PATCH v9 4/4] ASoC: mediatek: mt8188-mt6359: Enable dual amp for mt8188-rt5682s
In-Reply-To: <20231213113955.47668-1-zhourui@huaqin.corp-partner.google.com>
References: <20231213113955.47668-1-zhourui@huaqin.corp-partner.google.com>
Message-ID: <20231213113955.47668-5-zhourui@huaqin.corp-partner.google.com>

Enable support for dual MAX98390 amplifiers on the mt8188-rt5682s board.

Reviewed-by: Trevor Wu <trevor.wu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Rui Zhou <zhourui at huaqin.corp-partner.google.com>
---
 sound/soc/mediatek/mt8188/mt8188-mt6359.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/mediatek/mt8188/mt8188-mt6359.c b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
index d1884f23a1a7..a391066ab204 100644
--- a/sound/soc/mediatek/mt8188/mt8188-mt6359.c
+++ b/sound/soc/mediatek/mt8188/mt8188-mt6359.c
@@ -1448,7 +1448,7 @@ static struct mt8188_card_data mt8188_nau8825_card = {
 
 static struct mt8188_card_data mt8188_rt5682s_card = {
 	.name = "mt8188_rt5682s",
-	.quirk = RT5682S_HS_PRESENT,
+	.quirk = RT5682S_HS_PRESENT | MAX98390_TWO_AMP,
 };
 
 static struct mt8188_card_data mt8188_es8326_card = {
-- 
2.25.1



From rafael at kernel.org  Wed Dec 13 03:42:55 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 13 Dec 2023 12:42:55 +0100
Subject: [PATCH 2/2] PM: domains: Move genpd and its governor to the
 pmdomain subsystem
In-Reply-To: <20231213113305.29098-1-ulf.hansson@linaro.org>
References: <20231213113305.29098-1-ulf.hansson@linaro.org>
Message-ID: <CAJZ5v0hZPAUDhtzGX7GzdCe=jO63Zby65kgUMUFRShifUKEjZw@mail.gmail.com>

On Wed, Dec 13, 2023 at 12:33?PM Ulf Hansson <ulf.hansson at linaro.org> wrote:
>
> It seems reasonable to collect the core parts for the generic PM domain,
> along with its corresponding provider drivers. Therefore let's move the
> files from drivers/base/power/ to drivers/pmdomain/ and while at it, let's
> also rename the files accordingly.
>
> Moreover, let's also update MAINTAINERS to reflect the update.
>
> Cc: Kevin Hilman <khilman at kernel.org>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>

Acked-by: Rafael J. Wysocki <rafael at kernel.org>

for both patches in the series.

Thanks!

> ---
>  MAINTAINERS                                            | 10 +---------
>  drivers/base/power/Makefile                            |  1 -
>  drivers/pmdomain/Makefile                              |  1 +
>  drivers/{base/power/domain.c => pmdomain/core.c}       |  0
>  .../power/domain_governor.c => pmdomain/governor.c}    |  0
>  5 files changed, 2 insertions(+), 10 deletions(-)
>  rename drivers/{base/power/domain.c => pmdomain/core.c} (100%)
>  rename drivers/{base/power/domain_governor.c => pmdomain/governor.c} (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea790149af79..ab4b0aed34f9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8878,21 +8878,13 @@ F:      Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
>  F:     drivers/i2c/muxes/i2c-demux-pinctrl.c
>
>  GENERIC PM DOMAINS
> -M:     "Rafael J. Wysocki" <rafael at kernel.org>
> -M:     Kevin Hilman <khilman at kernel.org>
>  M:     Ulf Hansson <ulf.hansson at linaro.org>
>  L:     linux-pm at vger.kernel.org
>  S:     Supported
>  F:     Documentation/devicetree/bindings/power/power?domain*
> -F:     drivers/base/power/domain*.c
> -F:     include/linux/pm_domain.h
> -
> -GENERIC PM DOMAIN PROVIDERS
> -M:     Ulf Hansson <ulf.hansson at linaro.org>
> -L:     linux-pm at vger.kernel.org
> -S:     Supported
>  T:     git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git
>  F:     drivers/pmdomain/
> +F:     include/linux/pm_domain.h
>
>  GENERIC RADIX TREE
>  M:     Kent Overstreet <kent.overstreet at linux.dev>
> diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
> index 8fdd0073eeeb..01f11629d241 100644
> --- a/drivers/base/power/Makefile
> +++ b/drivers/base/power/Makefile
> @@ -2,7 +2,6 @@
>  obj-$(CONFIG_PM)       += sysfs.o generic_ops.o common.o qos.o runtime.o wakeirq.o
>  obj-$(CONFIG_PM_SLEEP) += main.o wakeup.o wakeup_stats.o
>  obj-$(CONFIG_PM_TRACE_RTC)     += trace.o
> -obj-$(CONFIG_PM_GENERIC_DOMAINS)       +=  domain.o domain_governor.o
>  obj-$(CONFIG_HAVE_CLK) += clock_ops.o
>  obj-$(CONFIG_PM_QOS_KUNIT_TEST) += qos-test.o
>
> diff --git a/drivers/pmdomain/Makefile b/drivers/pmdomain/Makefile
> index f0326b27b30b..a68ece2f4c68 100644
> --- a/drivers/pmdomain/Makefile
> +++ b/drivers/pmdomain/Makefile
> @@ -16,3 +16,4 @@ obj-y                                 += sunxi/
>  obj-y                                  += tegra/
>  obj-y                                  += ti/
>  obj-y                                  += xilinx/
> +obj-y                                  += core.o governor.o
> diff --git a/drivers/base/power/domain.c b/drivers/pmdomain/core.c
> similarity index 100%
> rename from drivers/base/power/domain.c
> rename to drivers/pmdomain/core.c
> diff --git a/drivers/base/power/domain_governor.c b/drivers/pmdomain/governor.c
> similarity index 100%
> rename from drivers/base/power/domain_governor.c
> rename to drivers/pmdomain/governor.c
> --
> 2.34.1
>


From mripard at kernel.org  Wed Dec 13 03:54:14 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Wed, 13 Dec 2023 12:54:14 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <20231213110829.bjaxjjiyy4ug7o67@pengutronix.de>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
 <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
 <20231213110829.bjaxjjiyy4ug7o67@pengutronix.de>
Message-ID: <6wnsxbi27xdxjtaqaaaq5wtwwilp4jfw4mg5y2ctdl7xrs44ry@ns6y36pf7hge>

On Wed, Dec 13, 2023 at 12:08:29PM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Dec 13, 2023 at 09:36:49AM +0100, Maxime Ripard wrote:
> > On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
> > > On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > > > On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> > > > > clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> > > > > that and don't check the return value. This series fixes the four users
> > > > > that do error checking on the returned value and then makes function
> > > > > return void.
> > > > > 
> > > > > Given that the changes to the drivers are simple and so merge conflicts
> > > > > (if any) should be easy to handle, I suggest to merge this complete
> > > > > series via the clk tree.
> > > > 
> > > > I don't think it's the right way to go about it.
> > > > 
> > > > clk_rate_exclusive_get() should be expected to fail. For example if
> > > > there's another user getting an exclusive rate on the same clock.
> > > > 
> > > > If we're not checking for it right now, then it should probably be
> > > > fixed, but the callers checking for the error are right to do so if they
> > > > rely on an exclusive rate. It's the ones that don't that should be
> > > > modified.
> > > 
> > > If some other consumer has already "locked" a clock that I call
> > > clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
> > > this function because I don't want the rate to change e.g. because I
> > > setup some registers in the consuming device to provide a fixed UART
> > > baud rate or i2c bus frequency (and that works as expected).
> > 
> > [a long text of mostly right things (Uwe's interpretation) that are
> > however totally unrelated to the patches under discussion.]

I'm glad you consider it "mostly" right.

> 
> The clk API works with and without my patches in exactly the same way.
> It just makes more explicit that clk_rate_exclusive_get() cannot fail
> today and removes the error handling from consumers that is never used.

Not really, no.

An API is an interface, meant to provide an abstraction. The only
relevant thing is whether or not that function, from an abstract point
of view, can fail.

Can you fail to get the exclusivity? Yes. On a theoretical basis, you
can, and the function was explicitly documented as such.

Whether or not the function actually can fail in its current
implementation is irrelevant.

> Yes, my series doesn't fix any race conditions that are there without
> doubt in some consumers. It also doesn't make the situation any worse.

Sure it does. If we ever improve that function to handle those unrelated
cases, then all your patches will have to be reverted, while we already
had code to deal with it written down.

> It also doesn't fix other problems that are orthogonal to the intention
> of this patch series (neither makes it any of them any worse).
> 
> It's just dead code removal and making sure no new dead code of the same
> type is introduced in the future.

Again, it's not. It's a modification of the abstraction.

> Is there anyone working on improving the clk framework regarding how clk
> rate exclusivity works? I'd probably not notice, but I guess there is
> noone that I need to consider for.

I started working on it.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/620130c9/attachment.sig>

From sudeep.holla at arm.com  Wed Dec 13 03:57:13 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 13 Dec 2023 11:57:13 +0000
Subject: [PATCH] arm64: dts: juno: align thermal zone names with bindings
In-Reply-To: <20231209171612.250868-1-krzysztof.kozlowski@linaro.org>
References: <20231209171612.250868-1-krzysztof.kozlowski@linaro.org>
Message-ID: <170246838542.3577011.6881453625869054003.b4-ty@arm.com>

On Sat, 09 Dec 2023 18:16:12 +0100, Krzysztof Kozlowski wrote:
> Thermal bindings require thermal zone node names to match
> certain patterns:
>
>   juno.dtb: thermal-zones: 'big-cluster', 'gpu0', 'gpu1', 'little-cluster', 'pmic', 'soc'
>     do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+'
>
>
> [...]

Applied to sudeep.holla/linux (for-next/juno/updates), thanks!

[1/1] arm64: dts: juno: align thermal zone names with bindings
      https://git.kernel.org/sudeep.holla/c/fb4d25d7a33f

--
Regards,
Sudeep



From sudeep.holla at arm.com  Wed Dec 13 03:58:25 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 13 Dec 2023 11:58:25 +0000
Subject: [GIT PULL] arm64: dts: juno: Updates for v6.8
Message-ID: <20231213115826.3577764-1-sudeep.holla@arm.com>

Hi ARM SoC Team,

Please pull !

Regards,
Sudeep

-->8

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-update-6.8

for you to fetch changes up to fb4d25d7a33f568bcbb945e64fb94d18ddf229fd:

  arm64: dts: juno: Align thermal zone names with bindings (2023-12-12 10:04:51 +0000)

----------------------------------------------------------------
Arm Vexpress/Juno update for v6.8

Just a single update to align the thermal zone names with bindings matching
[alphanumericals]*-thermal pattern.

----------------------------------------------------------------
Krzysztof Kozlowski (1):
      arm64: dts: juno: Align thermal zone names with bindings

 arch/arm64/boot/dts/arm/juno-base.dtsi | 12 ++++++------
 arch/arm64/boot/dts/arm/juno-scmi.dtsi | 12 ++++++------
 2 files changed, 12 insertions(+), 12 deletions(-)


From sudeep.holla at arm.com  Wed Dec 13 03:59:52 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 13 Dec 2023 11:59:52 +0000
Subject: [GIT PULL] firmware: arm_scmi: Updates for v6.8
Message-ID: <20231213115953.3578115-1-sudeep.holla@arm.com>

Hi ARM SoC Team,

Please pull !

Regards,
Sudeep

-->8

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-6.8

for you to fetch changes up to b5efc28a754d2e90b9d52ba5aaa051cc24a5c85d:

  firmware: arm_scmi: Add protocol versioning checks (2023-12-01 16:46:10 +0000)

----------------------------------------------------------------
Arm SCMI updates for v6.8

Few minor updates:

1. Addition of protocol versioning checks to warn if the firmware version
   is newer or greater than the version supported by the kernel driver

2. Increment of the maximum OPP count in the perf protocol from 16 to 32
   as needed by a few recent/future qualcomm platforms

3. Optimisation of set performance operations by returning error
   immediately and avoiding to send the command to the platform(which
   would return error eventually) if the domain doesn't support perf
   operations. Similarly, the fastchannel handling is also optimised by
   avoiding to initialise the corresponding set operations fastchannels.

4. Extension of extended names helper to accomodate recently added new
   flags parameter to be able to properly configure the command used to
   query the extended name of a resource.

----------------------------------------------------------------
Cristian Marussi (2):
      firmware: arm_scmi: Add optional flags to extended names helper
      firmware: arm_scmi: Add protocol versioning checks

Sibi Sankar (2):
      firmware: arm_scmi: Fix NULL pointer dereference during fastchannel init
      firmware: arm_scmi: Increase the maximum opp count in the perf protocol

Sudeep Holla (1):
      firmware: arm_scmi: Populate fastchannel info only if set operations are allowed

xinglong.yang (1):
      firmware: arm_scmi: Check beforehand if the perf domain set operations are allowed

 drivers/firmware/arm_scmi/base.c      |  6 ++++-
 drivers/firmware/arm_scmi/clock.c     |  8 ++++--
 drivers/firmware/arm_scmi/driver.c    | 24 ++++++++++++++----
 drivers/firmware/arm_scmi/perf.c      | 48 ++++++++++++++++++++++-------------
 drivers/firmware/arm_scmi/power.c     |  8 ++++--
 drivers/firmware/arm_scmi/powercap.c  |  8 ++++--
 drivers/firmware/arm_scmi/protocols.h | 11 ++++++--
 drivers/firmware/arm_scmi/reset.c     |  9 +++++--
 drivers/firmware/arm_scmi/sensors.c   |  8 ++++--
 drivers/firmware/arm_scmi/system.c    |  6 ++++-
 drivers/firmware/arm_scmi/voltage.c   |  8 ++++--
 11 files changed, 105 insertions(+), 39 deletions(-)


From will at kernel.org  Wed Dec 13 04:13:53 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 12:13:53 +0000
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <20231202035511.487946-3-sjg@chromium.org>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-3-sjg@chromium.org>
Message-ID: <20231213121353.GA31326@willie-the-truck>

On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> Add a script which produces a Flat Image Tree (FIT), a single file
> containing the built kernel and associated devicetree files.
> Compression defaults to gzip which gives a good balance of size and
> performance.
> 
> The files compress from about 86MB to 24MB using this approach.
> 
> The FIT can be used by bootloaders which support it, such as U-Boot
> and Linuxboot. It permits automatic selection of the correct
> devicetree, matching the compatible string of the running board with
> the closest compatible string in the FIT. There is no need for
> filenames or other workarounds.
> 
> Add a 'make image.fit' build target for arm64, as well. Use
> FIT_COMPRESSION to select a different algorithm.
> 
> The FIT can be examined using 'dumpimage -l'.
> 
> This features requires pylibfdt (use 'pip install libfdt'). It also
> requires compression utilities for the algorithm being used. Supported
> compression options are the same as the Image.xxx files. For now there
> is no way to change the compression other than by editing the rule for
> $(obj)/image.fit
> 
> While FIT supports a ramdisk / initrd, no attempt is made to support
> this here, since it must be built separately from the Linux build.
> 
> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---
> 
> Changes in v9:
> - Move the compression control into Makefile.lib
> 
> Changes in v8:
> - Drop compatible string in FDT node
> - Correct sorting of MAINTAINERS to before ARM64 PORT
> - Turn compress part of the make_fit.py comment in to a sentence
> - Add two blank lines before parse_args() and setup_fit()
> - Use 'image.fit: dtbs' instead of BUILD_DTBS var
> - Use '$(<D)/dts' instead of '$(dir $<)dts'
> - Add 'mkimage' details Documentation/process/changes.rst
> - Allow changing the compression used
> - Tweak cover letter since there is only one clean-up patch
> 
> Changes in v7:
> - Add Image as a dependency of image.fit
> - Drop kbuild tag
> - Add dependency on dtbs
> - Drop unnecessary path separator for dtbs
> - Rebase to -next
> 
> Changes in v5:
> - Drop patch previously applied
> - Correct compression rule which was broken in v4
> 
> Changes in v4:
> - Use single quotes for UIMAGE_NAME
> 
> Changes in v3:
> - Drop temporary file image.itk
> - Drop patch 'Use double quotes for image name'
> - Drop double quotes in use of UIMAGE_NAME
> - Drop unnecessary CONFIG_EFI_ZBOOT condition for help
> - Avoid hard-coding "arm64" for the DT architecture
> 
> Changes in v2:
> - Drop patch previously applied
> - Add .gitignore file
> - Move fit rule to Makefile.lib using an intermediate file
> - Drop dependency on CONFIG_EFI_ZBOOT
> - Pick up .dtb files separately from the kernel
> - Correct pylint too-many-args warning for write_kernel()
> - Include the kernel image in the file count
> - Add a pointer to the FIT spec and mention of its wide industry usage
> - Mention the kernel version in the FIT description
> 
>  Documentation/process/changes.rst |   9 +
>  MAINTAINERS                       |   7 +
>  arch/arm64/Makefile               |   7 +-
>  arch/arm64/boot/.gitignore        |   1 +
>  arch/arm64/boot/Makefile          |   6 +-
>  scripts/Makefile.lib              |  16 ++
>  scripts/make_fit.py               | 291 ++++++++++++++++++++++++++++++
>  7 files changed, 334 insertions(+), 3 deletions(-)
>  create mode 100755 scripts/make_fit.py

I'll need Masahiro's Ack on the scripts/ changes before I can take this
one.

Will


From will at kernel.org  Wed Dec 13 04:16:05 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 12:16:05 +0000
Subject: [PATCH v9 1/4] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <ZXiVX5FAWZqHfr7m@arm.com>
References: <20231113105234.32058-1-glider@google.com>
 <20231113105234.32058-2-glider@google.com>
 <ZXiVX5FAWZqHfr7m@arm.com>
Message-ID: <20231213121605.GB31326@willie-the-truck>

On Tue, Dec 12, 2023 at 05:16:15PM +0000, Catalin Marinas wrote:
> On Mon, Nov 13, 2023 at 11:52:30AM +0100, Alexander Potapenko wrote:
> > The config implements the algorithm compressing memory tags for ARM MTE
> > during swapping.
> > 
> > The algorithm is based on RLE and specifically targets buffers of tags
> > corresponding to a single page. In many cases a buffer can be compressed
> > into 63 bits, making it possible to store it without additional memory
> > allocation.
> > 
> > Suggested-by: Evgenii Stepanov <eugenis at google.com>
> > Signed-off-by: Alexander Potapenko <glider at google.com>
> 
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> 
> > +void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
> > +			size_t *out_len)
> > +{
> [...]
> > +}
> > +EXPORT_SYMBOL_NS(mte_tags_to_ranges, MTECOMP);
> 
> I may have asked before, what the reason for EXPORT_SYMBOL_NS? Is it for
> the kunit tests? Otherwise we don't expect those to be accessed from
> modules.

It looks like it. The Kconfig option for the test is tristate and it calls
this symbol directly.

Will


From dario.binacchi at amarulasolutions.com  Wed Dec 13 04:18:34 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Wed, 13 Dec 2023 13:18:34 +0100
Subject: (subset) [PATCH v5 00/10] Add displays support for bsh-smm-s2/pro boards
In-Reply-To: <170228617622.2409693.12899768447819855539.b4-ty@linaro.org>
References: <20231207141723.108004-1-dario.binacchi@amarulasolutions.com> <170228617622.2409693.12899768447819855539.b4-ty@linaro.org>
Message-ID: <CABGWkvp+40oCpajZKH8GDJq6qTD1g_+sVrcxHv6yHAxk4szXiw@mail.gmail.com>

Hi Neil,

On Mon, Dec 11, 2023 at 10:16?AM Neil Armstrong
<neil.armstrong at linaro.org> wrote:
>
> Hi,
>
> On Thu, 07 Dec 2023 15:16:29 +0100, Dario Binacchi wrote:
> > The series adds drivers for the displays used by bsh-smm-s2/pro boards.
> > This required applying some patches to the samsung-dsim driver and the
> > drm_bridge.c module.
> >
> > Changes in v5:
> > - Replace a 'return ret' with a 'goto fail' in the r63353_panel_activate()
> > - Add 'Reviewed-by' tag of Krzysztof Kozlowski
> >
> > [...]
>
> Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)
>
> [06/10] drm/panel: Add Synaptics R63353 panel driver
>         https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2e87bad7cd339882cf26b7101a1c87dab71962c9
> [07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
>         https://cgit.freedesktop.org/drm/drm-misc/commit/?id=549240c98e50207244bc1ac182622b8daba89a89
> [08/10] drm/panel: Add Ilitek ILI9805 panel driver
>         https://cgit.freedesktop.org/drm/drm-misc/commit/?id=edbf1d506ebe8c0857c406bd5d5b81d46ffd8437
> [09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
>         https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b1fcb7ee3707290466b2cc4956325fb91f09f13b
>
> --
> Neil
>

I think you forgot the patch:
[05/10] dt-bindings: display: panel: Add synaptics r63353 panel controller

I received an email complaining about the lack of documentation for
the Synaptics panel.

Thanks and regards,
Dario

--

Dario Binacchi

Senior Embedded Linux Developer

dario.binacchi at amarulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
info at amarulasolutions.com

www.amarulasolutions.com


From eugen.hristev at collabora.com  Wed Dec 13 04:20:14 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Wed, 13 Dec 2023 14:20:14 +0200
Subject: [PATCH 1/4] dt-bindings: media: mtk-vcodec-encoder: add dma-ranges
Message-ID: <20231213122017.102100-1-eugen.hristev@collabora.com>

As IOMMUs are supported, dma-ranges is not mentioned but
additionalProperties=false, thus we have an error when adding dma-ranges.
Add dma-ranges as a possible property because this may be present.

Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
 .../devicetree/bindings/media/mediatek,vcodec-encoder.yaml      | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
index a2051b31fa29..403530de5624 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
@@ -38,6 +38,8 @@ properties:
     minItems: 1
     maxItems: 5
 
+  dma-ranges: true
+
   assigned-clocks: true
 
   assigned-clock-parents: true
-- 
2.34.1



From eugen.hristev at collabora.com  Wed Dec 13 04:20:17 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Wed, 13 Dec 2023 14:20:17 +0200
Subject: [PATCH 4/4] arm64: dts: mediatek: mt8186: Add venc node
In-Reply-To: <20231213122017.102100-1-eugen.hristev@collabora.com>
References: <20231213122017.102100-1-eugen.hristev@collabora.com>
Message-ID: <20231213122017.102100-4-eugen.hristev@collabora.com>

From: Kyrie Wu <kyrie.wu at mediatek.com>

Add video encoder node.

Signed-off-by: Kyrie Wu <kyrie.wu at mediatek.com>
Signed-off-by: Allen-KH Cheng <allen-kh.cheng at mediatek.com>
Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.org>
[eugen.hristev at collabora.com: minor cleanup]
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index 66ead3f23336..8535ff2b44e9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1993,6 +1993,30 @@ larb7: smi at 17010000 {
 			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
 		};
 
+		venc: venc at 17020000 {
+			compatible = "mediatek,mt8183-vcodec-enc";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			reg = <0 0x17020000 0 0x2000>;
+			interrupts = <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH 0>;
+			iommus = <&iommu_mm IOMMU_PORT_L7_VENC_RCPU>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_REC>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_BSDMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_SV_COMV>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_RD_COMV>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_LUMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_CHROMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_LUMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_CHROMA>;
+			dma-ranges = <0x1 0x0 0x1 0x0 0x1 0x0>;
+			mediatek,scp = <&scp>;
+			clocks = <&vencsys CLK_VENC_CKE1_VENC>;
+			clock-names = "MT_CG_VENC";
+			assigned-clocks = <&topckgen CLK_TOP_VENC>;
+			assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D3>;
+			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
+		};
+
 		camsys: clock-controller at 1a000000 {
 			compatible = "mediatek,mt8186-camsys";
 			reg = <0 0x1a000000 0 0x1000>;
-- 
2.34.1



From eugen.hristev at collabora.com  Wed Dec 13 04:20:16 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Wed, 13 Dec 2023 14:20:16 +0200
Subject: [PATCH 3/4] arm64: dts: mediatek: mt8186: fix VENC power domain clocks
In-Reply-To: <20231213122017.102100-1-eugen.hristev@collabora.com>
References: <20231213122017.102100-1-eugen.hristev@collabora.com>
Message-ID: <20231213122017.102100-3-eugen.hristev@collabora.com>

The larb clock is in fact a subsys clock, so it must be prefixed by
'subsys-' to be correctly identified in the driver.

Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index df0c04f2ba1d..66ead3f23336 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1061,7 +1061,7 @@ power-domain at MT8186_POWER_DOMAIN_VENC {
 						reg = <MT8186_POWER_DOMAIN_VENC>;
 						clocks = <&topckgen CLK_TOP_VENC>,
 							 <&vencsys CLK_VENC_CKE1_VENC>;
-						clock-names = "venc0", "larb";
+						clock-names = "venc0", "subsys-larb";
 						mediatek,infracfg = <&infracfg_ao>;
 						#power-domain-cells = <0>;
 					};
-- 
2.34.1



From eugen.hristev at collabora.com  Wed Dec 13 04:20:15 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Wed, 13 Dec 2023 14:20:15 +0200
Subject: [PATCH 2/4] media: mediatek: vcodec: fix possible unbalanced PM counter
In-Reply-To: <20231213122017.102100-1-eugen.hristev@collabora.com>
References: <20231213122017.102100-1-eugen.hristev@collabora.com>
Message-ID: <20231213122017.102100-2-eugen.hristev@collabora.com>

It is possible that mtk_vcodec_enc_pw_on fails, and in that scenario
the PM counter is not incremented, and subsequent call to
mtk_vcodec_enc_pw_off decrements the counter, leading to a PM imbalance.
Fix by bailing out of venc_if_encode in the case when mtk_vcodec_enc_pw_on
fails.

Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
 .../platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c     | 4 +++-
 .../platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h     | 2 +-
 drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c | 5 ++++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c
index a22b7dfc656e..1a2b14a3e219 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c
@@ -58,13 +58,15 @@ int mtk_vcodec_init_enc_clk(struct mtk_vcodec_enc_dev *mtkdev)
 	return 0;
 }
 
-void mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm)
+int mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm)
 {
 	int ret;
 
 	ret = pm_runtime_resume_and_get(pm->dev);
 	if (ret)
 		dev_err(pm->dev, "pm_runtime_resume_and_get fail: %d", ret);
+
+	return ret;
 }
 
 void mtk_vcodec_enc_pw_off(struct mtk_vcodec_pm *pm)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h
index 157ea08ba9e3..2e28f25e36cc 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h
@@ -10,7 +10,7 @@
 #include "mtk_vcodec_enc_drv.h"
 
 int mtk_vcodec_init_enc_clk(struct mtk_vcodec_enc_dev *dev);
-void mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm);
+int mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm);
 void mtk_vcodec_enc_pw_off(struct mtk_vcodec_pm *pm);
 void mtk_vcodec_enc_clock_on(struct mtk_vcodec_pm *pm);
 void mtk_vcodec_enc_clock_off(struct mtk_vcodec_pm *pm);
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
index c402a686f3cb..e83747b8d69a 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
@@ -64,7 +64,9 @@ int venc_if_encode(struct mtk_vcodec_enc_ctx *ctx,
 	ctx->dev->curr_ctx = ctx;
 	spin_unlock_irqrestore(&ctx->dev->irqlock, flags);
 
-	mtk_vcodec_enc_pw_on(&ctx->dev->pm);
+	ret = mtk_vcodec_enc_pw_on(&ctx->dev->pm);
+	if (ret)
+		goto venc_if_encode_pw_on_err;
 	mtk_vcodec_enc_clock_on(&ctx->dev->pm);
 	ret = ctx->enc_if->encode(ctx->drv_handle, opt, frm_buf,
 				  bs_buf, result);
@@ -75,6 +77,7 @@ int venc_if_encode(struct mtk_vcodec_enc_ctx *ctx,
 	ctx->dev->curr_ctx = NULL;
 	spin_unlock_irqrestore(&ctx->dev->irqlock, flags);
 
+venc_if_encode_pw_on_err:
 	mtk_venc_unlock(ctx);
 	return ret;
 }
-- 
2.34.1



From vigneshr at ti.com  Wed Dec 13 04:22:34 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Wed, 13 Dec 2023 17:52:34 +0530
Subject: [PATCH v2] watchdog: rti_wdt: Drop RPM count when unused
In-Reply-To: <98c12c55-1f9f-4529-ae34-cb9f22471dbe@roeck-us.net>
References: <20231122041642.2015936-1-vigneshr@ti.com>
 <98c12c55-1f9f-4529-ae34-cb9f22471dbe@roeck-us.net>
Message-ID: <62762227-04e5-475e-aab7-ac594f99e317@ti.com>



On 12/12/23 20:57, Guenter Roeck wrote:
> On 11/21/23 20:16, Vignesh Raghavendra wrote:
>> Do a RPM put if watchdog is not already started during probe and re
>> enable it in watchdog start.
>>
>> On K3 SoCs, watchdogs and their corresponding CPUs are under same PD, so
>> if the reference count of unused watchdogs aren't dropped, it will lead
>> to CPU hotplug failures as Device Management firmware won't allow to
>> turn off the PD due to dangling reference count.
>>
>> Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support")
>> Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
> 
> I always find it amazing that people think everyone would understand the
> TLAs
> (three-letter-acronyms) they use. While those who don't might find it
> confusing
> why a watchdog driver would need or want to drop rotation-per-minute
> counts,
> and what that has to do with police departments, that isn't worth
> arguing about
> 

Oops, my apologies. I will respin with TLAs expanded

> Reviewed-by: Guenter Roeck <linux at roeck-us.net>
> 

Thanks!

> Guenter
> 

-- 
Regards
Vignesh


From andre.przywara at arm.com  Wed Dec 13 04:25:23 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 13 Dec 2023 12:25:23 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <ceuoq3xxgb5kkel7e7wqpslcg7h6dde3wgdqhyo7jgop6owovk@5a76ks5fiun4>
References: <20231212122835.10850-2-retpolanne@posteo.net>
	<20231212162200.10b3868b@donnerap.manchester.arm.com>
	<axsvii25yrknfae6gdreti7lcskoscsdbsujwuispiieimsbdy@gwzm4l7mwlew>
	<20231213013544.2fc7e0d1@minigeek.lan>
	<ceuoq3xxgb5kkel7e7wqpslcg7h6dde3wgdqhyo7jgop6owovk@5a76ks5fiun4>
Message-ID: <20231213122523.219cbfc0@donnerap.manchester.arm.com>

On Wed, 13 Dec 2023 11:02:39 +0000
Anne Macedo <retpolanne at posteo.net> wrote:

Hi Anne,

> On Wed, Dec 13, 2023 at 01:35:44AM +0000, Andre Przywara wrote:
> > On Tue, 12 Dec 2023 19:27:14 +0000
> > Anne Macedo <retpolanne at posteo.net> wrote:
> > 
> > Hi Anne,
> >   
> > > On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:  
> > > > On Tue, 12 Dec 2023 12:28:30 +0000
> > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > 
> > > > Hi Anne,
> > > >     
> > > > > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > > > > Realtek 8211 PHY to Orange Pi One Plus.    
> > > > 
> > > > So can you state why this would be needed? This is the RTL8211 ID,    
> > > 
> > > Apologies, I completely forgot to include some context. 
> > >   
> > > > right? Which should be autodetected via MDIO. Looking back in my inbox
> > > > you proposed this change before, for U-Boot, specifically, but I fail to
> > > > find a solution or explanation what really happens here. Two Renesas .dts
> > > > files have the same compatible, and the commit message talks about the
> > > > reset line there, is this related?
> > > > 
> > > > So can you please give some more background and explanation? That would be
> > > > part of a good commit message anyway ("why", not "what").    
> > > 
> > > Should I resend the commit with a more meaningful explanation? The
> > > context is the following:
> > > 
> > > currently, ethernet doesn't seem to work on both u-boot and Linux on the
> > > Orange Pi One Plus board. 
> > > 
> > > On the kernel, this error shows up:
> > > 
> > > Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > [    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> > > 
> > > After applying this fix, the PHY gets attached: 
> > > 
> > > Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > [    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
> > > 
> > > The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
> > > to find a PHY, so this patch includes the correct PHY ID with the
> > > RTL8211 ID. 
> > > 
> > > The behaviour is described on [1].  
> > 
> > So this is all an observation, but no real explanation, isn't it?  
> 
> I've made some analysis on [3] on this bug, but it was based solely on
> u-boot. I was having trouble with the regulator and on u-boot nothing
> would trigger the GPIO PD6 and the vcc-gmac-3v3 regulator, so the NIC
> was completely dead. Next I did an analysis based on [2] because the
> u-boot PHY initialization was flaky.
> 
> > To cite [1]: "If the PHY reports an incorrect ID (or none at all) ...".
> > I am pretty sure this is not the case here, instead we are looking at
> > some missing platform bits, like a missing clock, reset, or most likely
> > regulator. Or one of the existing resources is wrongly assigned or  
> 
> As I mentioned, PHY initialization is flaky on u-boot, so maybe that
> assumption is correct. 
> 
> > configured? If the PHY is not (yet?) powered correctly when the code
> > does the auto-detection via the MDIO bus, then the initialisation would  
> 
> If I recall correctly (I don't know if I kept it in my notes :c), that
> could be the case. regulator-boot-on makes the NIC work (LEDs blink, at
> least) but it doesn't get initialized. 
> 
> > fail. But since it works when overriding the auto-detection, I feel
> > like we are papering over something here.
> > Do you have the schematics for this board? I can only find the one for
> > the Orange Pi Plus 2E, and I don't know how similar those two are. This
> > shows *two* regulators, but both are activated by the same GPIO.  
> 
> I do. It's available on [4]

Oh damn it, I got lost in Orange Pi's naming maze again - and was looking
for the wrong board! So thanks for the link, and this clears things up!

So yes, the Orange Pi *One* Plus, much like the Orange Pi 3, uses *two*
regulators for Ethernet: one 3.3V from the PMIC's ALDO2 rail to power the
PHY, and a discrete 2.5V regulator, enabled by GPIO PD6, for the voltage
level on the MDIO lines. On top of this there is a reset line for the PHY,
though this is held up by a pull-up resistor, so it *should* work,
although we should describe this in the DT.

So the DT looks wrong then: The reg_gmac_3v3 is actually a 2.5V regulator,
and phy-supply is aldo2. I think it was done the way it is to somehow make
it work with the current DT binding and code, which just supports one
regulator. And aldo2 is referenced as the source of reg_gmac_3v3, which
smells like another hack to me.

> > It would also be interesting to see if any of Corentin's work for the
> > Orange Pi 3 helps here?  
> 
> Adding [5] for reference here, thanks! Will check it out. 

This is an older version, there are actually updates. And he also mentions
your board as well, so I think it just can sail in the wake of the OPi 3
Ethernet enablement.

Can you try if this change, just applied to your .dts instead, works?
https://github.com/montjoie/linux/commit/cf6e192eca1d59be630e6729d2cef9e897b3da8c

Cheers,
Andre

P.S. Is there any chance where I can reply/comment on your blog? It seems
like I can clear some things up...

> [3] https://blog.retpolanne.com/hardware/embedded/2023/07/07/embedded-phy.html
> [4] https://linux-sunxi.org/images/7/7c/OrangePi_OnePlus_Schematics_v2.0.pdf
> [5] https://lore.kernel.org/netdev/20220509074857.195302-1-clabbe at baylibre.com/
> 
> Regards, Anne



From will at kernel.org  Wed Dec 13 04:31:30 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 12:31:30 +0000
Subject: [PATCH v9 0/4] Implement MTE tag compression for swapped pages
In-Reply-To: <20231113105234.32058-1-glider@google.com>
References: <20231113105234.32058-1-glider@google.com>
Message-ID: <20231213123130.GC31326@willie-the-truck>

On Mon, Nov 13, 2023 at 11:52:29AM +0100, Alexander Potapenko wrote:
> Currently, when MTE pages are swapped out, the tags are kept in the
> memory, occupying PAGE_SIZE/32 bytes per page. This is especially
> problematic for devices that use zram-backed in-memory swap, because
> tags stored uncompressed in the heap effectively reduce the available
> amount of swap memory.
> 
> The RLE-based algorithm suggested by Evgenii Stepanov and implemented in
> this patch series is able to efficiently compress fixed-size tag buffers,
> resulting in practical compression ratio of 2x. In many cases it is
> possible to store the compressed data in 63-bit Xarray values, resulting
> in no extra memory allocations.
> 
> This patch series depends on "lib/bitmap: add bitmap_{read,write}()"
> (https://lore.kernel.org/linux-arm-kernel/20231030153210.139512-1-glider at google.com/T/)
> that is mailed separately.

That's a shame, because it means I can't apply the series as-is:


arch/arm64/mm/mtecomp.c: In function ?mte_bitmap_write?:
arch/arm64/mm/mtecomp.c:105:2: error: implicit declaration of function ?bitmap_write?; did you mean ?bitmap_free?? [-Werror=implicit-function-declaration]
  105 |  bitmap_write(bitmap, value, *pos, bits);
      |  ^~~~~~~~~~~~
      |  bitmap_free
arch/arm64/mm/mtecomp.c: In function ?mte_bitmap_read?:
arch/arm64/mm/mtecomp.c:198:9: error: implicit declaration of function ?bitmap_read?; did you mean ?bitmap_remap?? [-Werror=implicit-function-declaration]
  198 |  return bitmap_read(bitmap, start, bits);
      |         ^~~~~~~~~~~
      |         bitmap_remap
cc1: some warnings being treated as errors
make[5]: *** [scripts/Makefile.build:243: arch/arm64/mm/mtecomp.o] Error 1


Do you really have such a hard dependency on those new bitmap ops?

Will


From nm at ti.com  Wed Dec 13 04:38:19 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 13 Dec 2023 06:38:19 -0600
Subject: [PATCH v2] arm64: dts: ti: k3-am654-icssg2: Enable PHY
 interrupts for ICSSG2
In-Reply-To: <20231213080216.1710730-1-s-vadapalli@ti.com>
References: <20231213080216.1710730-1-s-vadapalli@ti.com>
Message-ID: <20231213123819.tqh3lm2ceir3qjbk@swimmer>

On 13:32-20231213, Siddharth Vadapalli wrote:
> Enable interrupt mode of operation of the DP83867 Ethernet PHY which is
> used by ICSSG2. The DP83867 PHY driver already supports interrupt handling
> for interrupts generated by the PHY. Thus, add the necessary device-tree
> support to enable it.
> 
> Since the GPIO1_87 line is muxed with EXT_REFCLK1 and SYNC1_OUT, update
> the pinmux to select GPIO1_87 for routing the interrupt.
> 
> As the same interrupt line and therefore the same pinmux configuration is
> applicable to both Ethernet PHYs used by ICSSG2, allocate the pinmux
> resource to the first Ethernet PHY alone.
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> Reviewed-by: MD Danish Anwar <danishanwar at ti.com>
> ---
> Hello,
> 
> This patch is based on linux-next tagged next-20231213.
> 
> v1:
> https://lore.kernel.org/r/20231120063159.539306-1-s-vadapalli at ti.com/
> Changes since v1:
> - Rebased patch on next-20231213.
> - Collected Reviewed-by tag from
>   MD Danish Anwar <danishanwar at ti.com>
> - Moved pinctrl from MDIO node to Ethernet PHY node based on feedback from
>   Nishanth Menon <nm at ti.com>
> - Replaced the hard-coded value 0x2 with IRQ_TYPE_EDGE_FALLING for
>   setting the interrupt trigger type and level flag based on feedback from
>   Nishanth Menon <nm at ti.com>
> - Included dt-bindings/interrupt-controller/irq.h in the overlay.
> - Updated commit message with details of the pinmux resource allocation.
> 
> Regards,
> Siddharth.
> 
>  arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
> index ec8cf20ca3ac..6eabdfa0d602 100644
> --- a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
> +++ b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
> @@ -8,6 +8,7 @@
>  /dts-v1/;
>  /plugin/;
>  
> +#include <dt-bindings/interrupt-controller/irq.h>
>  #include <dt-bindings/net/ti-dp83867.h>
>  #include "k3-pinctrl.h"
>  
> @@ -124,6 +125,15 @@ AM65X_IOPAD(0x0088, PIN_INPUT, 2) /* (AG17) PRG2_PRU0_GPO4.PRG2_RGMII1_RX_CTL */
>  	};
>  };
>  
> +&main_pmx1 {
> +	/* Select GPIO1_87 for ICSSG2 PHY interrupt */
> +	icssg2_phy_irq_pins_default: icssg2-phy-irq-default-pins {
> +		pinctrl-single,pins = <
> +			AM65X_IOPAD(0x0014, PIN_INPUT, 7) /* (A22) EXT_REFCLK1.GPIO1_87 */
> +		>;
> +	};
> +};
> +
>  &icssg2_mdio {
>  	status = "okay";
>  	pinctrl-names = "default";
> @@ -132,13 +142,20 @@ &icssg2_mdio {
>  	#size-cells = <0>;
>  
>  	icssg2_phy0: ethernet-phy at 0 {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&icssg2_phy_irq_pins_default>;
> +
>  		reg = <0>;
> +		interrupt-parent = <&main_gpio1>;
> +		interrupts = <87 IRQ_TYPE_EDGE_FALLING>;
>  		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>  		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
>  	};
>  
>  	icssg2_phy1: ethernet-phy at 3 {
>  		reg = <3>;
> +		interrupt-parent = <&main_gpio1>;
> +		interrupts = <87 IRQ_TYPE_EDGE_FALLING>;

https://www.ti.com/lit/ds/symlink/dp83867ir.pdf -> it looks like the
interrupt pin is level event. but drivers/gpio/gpio-davinci.c::
gpio_irq_type() -> The SoC cannot handle level, only edge.

A bit confused here..  GPIO 87 is shared between two phys. isn't it a
case of race?

PHY1 assets low
phy1 handler starts, but before the driver it clears the condition:
PHY2 asserts low - but since the signal is already low, there is no
pulse
phy1 handler clears phy1 condition, but signal is still low due to phy2?
now phy2 OR phy1 never gets handled since there is never a pulse event
ever again.


>  		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>  		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
>  	};
> -- 
> 2.34.1
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From quic_mnaresh at quicinc.com  Wed Dec 13 04:43:53 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Wed, 13 Dec 2023 18:13:53 +0530
Subject: [PATCH V5 2/2] ufs: ufs-mediatek: Migrate to UFSHCD generic CPU latency PM QoS support
In-Reply-To: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
References: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
Message-ID: <20231213124353.16407-3-quic_mnaresh@quicinc.com>

The PM QoS feature found in the MediaTek UFS driver was moved to the UFSHCD
core. Hence remove it from MediaTek UFS driver as it is redundant now.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/host/ufs-mediatek.c | 17 -----------------
 drivers/ufs/host/ufs-mediatek.h |  3 ---
 2 files changed, 20 deletions(-)

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index fc61790d289b..1e7dadcb644f 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -17,7 +17,6 @@
 #include <linux/of_platform.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
-#include <linux/pm_qos.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
@@ -626,21 +625,9 @@ static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
 	dev_info(hba->dev, "caps: 0x%x", host->caps);
 }
 
-static void ufs_mtk_boost_pm_qos(struct ufs_hba *hba, bool boost)
-{
-	struct ufs_mtk_host *host = ufshcd_get_variant(hba);
-
-	if (!host || !host->pm_qos_init)
-		return;
-
-	cpu_latency_qos_update_request(&host->pm_qos_req,
-				       boost ? 0 : PM_QOS_DEFAULT_VALUE);
-}
-
 static void ufs_mtk_scale_perf(struct ufs_hba *hba, bool scale_up)
 {
 	ufs_mtk_boost_crypt(hba, scale_up);
-	ufs_mtk_boost_pm_qos(hba, scale_up);
 }
 
 static void ufs_mtk_pwr_ctrl(struct ufs_hba *hba, bool on)
@@ -959,10 +946,6 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
 	host->ip_ver = ufshcd_readl(hba, REG_UFS_MTK_IP_VER);
 
-	/* Initialize pm-qos request */
-	cpu_latency_qos_add_request(&host->pm_qos_req, PM_QOS_DEFAULT_VALUE);
-	host->pm_qos_init = true;
-
 	goto out;
 
 out_variant_clear:
diff --git a/drivers/ufs/host/ufs-mediatek.h b/drivers/ufs/host/ufs-mediatek.h
index f76e80d91729..38eab95b0f79 100644
--- a/drivers/ufs/host/ufs-mediatek.h
+++ b/drivers/ufs/host/ufs-mediatek.h
@@ -7,7 +7,6 @@
 #define _UFS_MEDIATEK_H
 
 #include <linux/bitops.h>
-#include <linux/pm_qos.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
 
 /*
@@ -167,7 +166,6 @@ struct ufs_mtk_mcq_intr_info {
 
 struct ufs_mtk_host {
 	struct phy *mphy;
-	struct pm_qos_request pm_qos_req;
 	struct regulator *reg_va09;
 	struct reset_control *hci_reset;
 	struct reset_control *unipro_reset;
@@ -178,7 +176,6 @@ struct ufs_mtk_host {
 	struct ufs_mtk_hw_ver hw_ver;
 	enum ufs_mtk_host_caps caps;
 	bool mphy_powered_on;
-	bool pm_qos_init;
 	bool unipro_lpm;
 	bool ref_clk_enabled;
 	u16 ref_clk_ungating_wait_us;
-- 
2.17.1



From quic_mnaresh at quicinc.com  Wed Dec 13 04:43:51 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Wed, 13 Dec 2023 18:13:51 +0530
Subject: [PATCH V5 0/2] Add CPU latency QoS support for ufs driver
Message-ID: <20231213124353.16407-1-quic_mnaresh@quicinc.com>

Add CPU latency QoS support for ufs driver. This improves random io
performance by 15% for ufs.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 37101.3
	Random Write(IPOS) | 41065.13

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 42943.4
	Random Write(IPOS) | 46784.9
(Improvement with PM QoS = ~15%).

This patch is based on below patch by Stanley Chu [1]. 
Moving the PM QoS code to ufshcd.c and making it generic.

[1] https://lore.kernel.org/r/20220623035052.18802-8-stanley.chu at mediatek.com

Changes from v4:
- Addressed angelogioacchino's comments to update commit text
- Addressed angelogioacchino's comments to code alignment

Changes from v3:
- Removed UFSHCD_CAP_PM_QOS capability flag from patch#2

Changes from v2:
- Addressed bvanassche and mani comments
- Provided sysfs interface to enable/disable PM QoS feature

Changes from v1:
- Addressed bvanassche comments to have the code in core ufshcd
- Design is changed from per-device PM QoS to CPU latency QoS based support
- Reverted existing PM QoS feature from MEDIATEK UFS driver
- Added PM QoS capability for both QCOM and MEDIATEK SoCs

Maramaina Naresh (2):
  ufs: core: Add CPU latency QoS support for ufs driver
  ufs: ufs-mediatek: Migrate to UFSHCD generic CPU latency PM QoS
    support

 drivers/ufs/core/ufshcd.c       | 125 ++++++++++++++++++++++++++++++++
 drivers/ufs/host/ufs-mediatek.c |  17 -----
 drivers/ufs/host/ufs-mediatek.h |   3 -
 include/ufs/ufshcd.h            |   6 ++
 4 files changed, 131 insertions(+), 20 deletions(-)

-- 
2.17.1



From quic_mnaresh at quicinc.com  Wed Dec 13 04:43:52 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Wed, 13 Dec 2023 18:13:52 +0530
Subject: [PATCH V5 1/2] ufs: core: Add CPU latency QoS support for ufs driver
In-Reply-To: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
References: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
Message-ID: <20231213124353.16407-2-quic_mnaresh@quicinc.com>

Register ufs driver to CPU latency PM QoS framework to improve
ufs device random io performance.

PM QoS initialization will insert new QoS request into the CPU
latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
value.

UFS driver will vote for performance mode on scale up and power
save mode for scale down.

If clock scaling feature is not enabled then voting will be based
on clock on or off condition.

Provided sysfs interface to enable/disable PM QoS feature.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 41065.13
	Random Read(IPOS)  | 37101.3

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 46784.9
	Random Read(IPOS)  | 42943.4
(Improvement with PM QoS = ~15%).

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Co-developed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall at quicinc.com>
Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/core/ufshcd.c | 125 ++++++++++++++++++++++++++++++++++++++
 include/ufs/ufshcd.h      |   6 ++
 2 files changed, 131 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index ae9936fc6ffb..a8ee6e02e83e 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1001,6 +1001,19 @@ static bool ufshcd_is_unipro_pa_params_tuning_req(struct ufs_hba *hba)
 	return ufshcd_get_local_unipro_ver(hba) < UFS_UNIPRO_VER_1_6;
 }
 
+/**
+ * ufshcd_pm_qos_update - update PM QoS request
+ * @hba: per adapter instance
+ * @on: If True, vote for perf PM QoS mode otherwise power save mode
+ */
+static void ufshcd_pm_qos_update(struct ufs_hba *hba, bool on)
+{
+	if (!hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? 0 : PM_QOS_DEFAULT_VALUE);
+}
+
 /**
  * ufshcd_set_clk_freq - set UFS controller clock frequencies
  * @hba: per adapter instance
@@ -1147,8 +1160,11 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, unsigned long freq,
 					    hba->devfreq->previous_freq);
 		else
 			ufshcd_set_clk_freq(hba, !scale_up);
+		goto out;
 	}
 
+	ufshcd_pm_qos_update(hba, scale_up);
+
 out:
 	trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
 			(scale_up ? "up" : "down"),
@@ -8615,6 +8631,108 @@ static void ufshcd_set_timestamp_attr(struct ufs_hba *hba)
 	ufshcd_release(hba);
 }
 
+/**
+ * ufshcd_pm_qos_init - initialize PM QoS request
+ * @hba: per adapter instance
+ */
+static void ufshcd_pm_qos_init(struct ufs_hba *hba)
+{
+
+	if (hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_add_request(&hba->pm_qos_req, PM_QOS_DEFAULT_VALUE);
+
+	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
+		hba->pm_qos_enabled = true;
+}
+
+/**
+ * ufshcd_pm_qos_exit - remove request from PM QoS
+ * @hba: per adapter instance
+ */
+static void ufshcd_pm_qos_exit(struct ufs_hba *hba)
+{
+	if (!hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_remove_request(&hba->pm_qos_req);
+	hba->pm_qos_enabled = false;
+}
+
+/**
+ * ufshcd_pm_qos_enable_show - sysfs handler to show pm qos enable value
+ * @dev: device associated with the UFS controller
+ * @attr: sysfs attribute handle
+ * @buf: buffer for sysfs file
+ *
+ * Print 1 if PM QoS feature is enabled, 0 if disabled.
+ *
+ * Returns number of characters written to @buf.
+ */
+static ssize_t ufshcd_pm_qos_enable_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	return sysfs_emit(buf, "%d\n", hba->pm_qos_enabled);
+}
+
+/**
+ * ufshcd_pm_qos_enable_store - sysfs handler to store value
+ * @dev: device associated with the UFS controller
+ * @attr: sysfs attribute handle
+ * @buf: buffer for sysfs file
+ * @count: stores buffer characters count
+ *
+ * Input 0 to disable PM QoS and any non-zero positive value to enable.
+ * Default state: 1
+ *
+ * Return: number of characters written to @buf on success, < 0 upon failure.
+ */
+static ssize_t ufshcd_pm_qos_enable_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+	u32 value;
+
+	if (kstrtou32(buf, 0, &value))
+		return -EINVAL;
+
+	value = !!value;
+	if (value)
+		ufshcd_pm_qos_init(hba);
+	else
+		ufshcd_pm_qos_exit(hba);
+
+	return count;
+}
+
+/**
+ * ufshcd_init_pm_qos_sysfs - initialize PM QoS sysfs entry
+ * @hba: per adapter instance
+ */
+static void ufshcd_init_pm_qos_sysfs(struct ufs_hba *hba)
+{
+	hba->pm_qos_enable_attr.show = ufshcd_pm_qos_enable_show;
+	hba->pm_qos_enable_attr.store = ufshcd_pm_qos_enable_store;
+	sysfs_attr_init(&hba->pm_qos_enable_attr.attr);
+	hba->pm_qos_enable_attr.attr.name = "pm_qos_enable";
+	hba->pm_qos_enable_attr.attr.mode = 0644;
+	if (device_create_file(hba->dev, &hba->pm_qos_enable_attr))
+		dev_err(hba->dev, "Failed to create sysfs for pm_qos_enable\n");
+}
+
+/**
+ * ufshcd_remove_pm_qos_sysfs - remove PM QoS sysfs entry
+ * @hba: per adapter instance
+ */
+static void ufshcd_remove_pm_qos_sysfs(struct ufs_hba *hba)
+{
+	if (hba->pm_qos_enable_attr.attr.name)
+		device_remove_file(hba->dev, &hba->pm_qos_enable_attr);
+}
+
 /**
  * ufshcd_add_lus - probe and add UFS logical units
  * @hba: per-adapter instance
@@ -9204,6 +9322,8 @@ static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
 	if (ret)
 		return ret;
 
+	if (!ufshcd_is_clkscaling_supported(hba))
+		ufshcd_pm_qos_update(hba, on);
 out:
 	if (ret) {
 		list_for_each_entry(clki, head, list) {
@@ -9381,6 +9501,8 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
 static void ufshcd_hba_exit(struct ufs_hba *hba)
 {
 	if (hba->is_powered) {
+		ufshcd_remove_pm_qos_sysfs(hba);
+		ufshcd_pm_qos_exit(hba);
 		ufshcd_exit_clk_scaling(hba);
 		ufshcd_exit_clk_gating(hba);
 		if (hba->eh_wq)
@@ -10030,6 +10152,7 @@ static int ufshcd_suspend(struct ufs_hba *hba)
 	ufshcd_vreg_set_lpm(hba);
 	/* Put the host controller in low power mode if possible */
 	ufshcd_hba_vreg_set_lpm(hba);
+	ufshcd_pm_qos_update(hba, false);
 	return ret;
 }
 
@@ -10576,6 +10699,8 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 	ufs_sysfs_add_nodes(hba->dev);
 
 	device_enable_async_suspend(dev);
+	ufshcd_pm_qos_init(hba);
+	ufshcd_init_pm_qos_sysfs(hba);
 	return 0;
 
 free_tmf_queue:
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index d862c8ddce03..fa7434a9073d 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -912,6 +912,9 @@ enum ufshcd_mcq_opr {
  * @mcq_base: Multi circular queue registers base address
  * @uhq: array of supported hardware queues
  * @dev_cmd_queue: Queue for issuing device management commands
+ * @pm_qos_enable_attr: sysfs attribute to enable/disable  pm qos
+ * @pm_qos_req: PM QoS request handle
+ * @pm_qos_enabled: flag to check if pm qos is enabled
  */
 struct ufs_hba {
 	void __iomem *mmio_base;
@@ -1076,6 +1079,9 @@ struct ufs_hba {
 	struct ufs_hw_queue *uhq;
 	struct ufs_hw_queue *dev_cmd_queue;
 	struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
+	struct device_attribute pm_qos_enable_attr;
+	struct pm_qos_request pm_qos_req;
+	bool pm_qos_enabled;
 };
 
 /**
-- 
2.17.1



From linux at armlinux.org.uk  Wed Dec 13 04:47:31 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:47:31 +0000
Subject: [RFC PATCH v3 00/21] ACPI/arm64: add support for virtual cpu hotplug
Message-ID: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>

Hi,

This is this remaining patches for ARM64 virtual cpu hotplug, which
follows on from the previous set of 21 patches that GregKH has
recently queued up, and "x86: intel_epb: Don't rely on link order"
which can be found at:

https://lore.kernel.org/r/E1r6SeD-00DCuK-M6 at rmk-PC.armlinux.org.uk
https://lore.kernel.org/r/ZVyz/Ve5pPu8AWoA at shell.armlinux.org.uk

The entire series can be found at:

 git://git.armlinux.org.uk/~rmk/linux-arm.git aarch64/hotplug-vcpu/head

The original cover message from the entire series is below the
diffstat.

 Documentation/arch/arm64/cpu-hotplug.rst   |  79 ++++++++++++++++
 Documentation/arch/arm64/index.rst         |   1 +
 arch/arm64/include/asm/acpi.h              |  11 +++
 arch/arm64/kernel/acpi_numa.c              |  11 ---
 arch/arm64/kernel/psci.c                   |   2 +-
 arch/arm64/kernel/smp.c                    |   3 +-
 arch/loongarch/Kconfig                     |   2 +-
 arch/loongarch/configs/loongson3_defconfig |   2 +-
 arch/loongarch/kernel/acpi.c               |   4 +-
 arch/x86/Kconfig                           |   3 +-
 arch/x86/kernel/acpi/boot.c                |   4 +-
 drivers/acpi/Kconfig                       |  13 ++-
 drivers/acpi/acpi_processor.c              | 141 ++++++++++++++++++++++++++---
 drivers/acpi/bus.c                         |  16 ++++
 drivers/acpi/device_pm.c                   |   2 +-
 drivers/acpi/device_sysfs.c                |   2 +-
 drivers/acpi/internal.h                    |   1 -
 drivers/acpi/property.c                    |   2 +-
 drivers/acpi/scan.c                        | 140 ++++++++++++++++++----------
 drivers/base/cpu.c                         |  16 +++-
 drivers/irqchip/irq-gic-v3.c               |  32 ++++---
 include/acpi/acpi_bus.h                    |   1 +
 include/acpi/actbl2.h                      |   1 +
 include/linux/acpi.h                       |  10 +-
 include/linux/cpumask.h                    |  25 +++++
 kernel/cpu.c                               |   3 +
 26 files changed, 421 insertions(+), 106 deletions(-)

On Tue, Oct 24, 2023 at 04:15:28PM +0100, Russell King (Oracle) wrote:
> Hi,
> 
> I'm posting James' patch set updated with most of the review comments
> from his RFC v2 series back in September. Individual patches have a
> changelog attached at the bottom of the commit message. Those which
> I have finished updating have my S-o-b on them, those which still have
> outstanding review comments from RFC v2 do not. In some of these cases
> I've asked questions and am waiting for responses.
> 
> I'm posting this as RFC v3 because there's still some unaddressed
> comments and it's clearly not ready for merging. Even if it was ready
> to be merged, it is too late in this development cycle to be taking
> this change in, so there would be little point posting it non-RFC.
> Also James stated that he's waiting for confirmation from the
> Kubernetes/Kata folk - I have no idea what the status is there.
> 
> I will be sending each patch individually to a wider audience
> appropriate for that patch - apologies to those missing out on this
> cover message. I have added more mailing lists to the series with the
> exception of the acpica list in a hope of this cover message also
> reaching those folk.
> 
> The changes that aren't included are:
> 
> 1. Updates for my patch that was merged via Thomas (thanks!):
>    c4dd854f740c cpu-hotplug: Provide prototypes for arch CPU registration
>    rather than having this change spread through James' patches.
> 
> 2. New patch - simplification of PA-RISC's smp_prepare_boot_cpu()
> 
> 3. Moved "ACPI: Use the acpi_device_is_present() helper in more places"
>    and "ACPI: Rename acpi_scan_device_not_present() to be about
>    enumeration" to the beginning of the series - these two patches are
>    already queued up for merging into 6.7.
> 
> 4. Moved "arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into
>    a helper" to the beginning of the series, which has been submitted,
>    but as yet the fate of that posting isn't known.
> 
> The first four patches in this series are provided for completness only.
> 
> There is an additional patch in James' git tree that isn't in the set
> of patches that James posted: "ACPI: processor: Only call
> arch_unregister_cpu() if HOTPLUG_CPU is selected" which looks to me to
> be a workaround for arch_unregister_cpu() being under the ifdef. I've
> commented on this on the RFC v2 posting making a suggestion, but as yet
> haven't had any response.
> 
> I've included almost all of James' original covering body below the
> diffstat.
> 
> The reason that I'm doing this is to help move this code forward so
> hopefully it can be merged - which is why I have been keen to dig out
> from James' patches anything that can be merged and submit it
> separately, since this is a feature for which some users have a
> definite need for.
> 
> Please note that I haven't tested this beyond building for aarch64 at
> the present time.
> 
> The series can be found at:
> 
>  git://git.armlinux.org.uk/~rmk/linux-arm.git aarch64/hotplug-vcpu/v6.6-rc7
> 
>  Documentation/arch/arm64/cpu-hotplug.rst   |  79 +++++++++++++++
>  Documentation/arch/arm64/index.rst         |   1 +
>  arch/arm64/Kconfig                         |   1 +
>  arch/arm64/include/asm/acpi.h              |  11 +++
>  arch/arm64/include/asm/cpu.h               |   1 -
>  arch/arm64/kernel/acpi_numa.c              |  11 ---
>  arch/arm64/kernel/psci.c                   |   2 +-
>  arch/arm64/kernel/setup.c                  |  13 +--
>  arch/arm64/kernel/smp.c                    |   5 +-
>  arch/ia64/Kconfig                          |   3 +
>  arch/ia64/include/asm/acpi.h               |   2 +-
>  arch/ia64/include/asm/cpu.h                |   6 --
>  arch/ia64/kernel/acpi.c                    |   6 +-
>  arch/ia64/kernel/setup.c                   |   2 +-
>  arch/ia64/kernel/topology.c                |  35 +------
>  arch/loongarch/Kconfig                     |   2 +
>  arch/loongarch/configs/loongson3_defconfig |   2 +-
>  arch/loongarch/kernel/acpi.c               |   4 +-
>  arch/loongarch/kernel/topology.c           |  38 +-------
>  arch/parisc/kernel/smp.c                   |   8 +-
>  arch/riscv/Kconfig                         |   1 +
>  arch/riscv/kernel/setup.c                  |  19 +---
>  arch/x86/Kconfig                           |   3 +
>  arch/x86/include/asm/cpu.h                 |   4 -
>  arch/x86/kernel/acpi/boot.c                |   4 +-
>  arch/x86/kernel/cpu/intel_epb.c            |   2 +-
>  arch/x86/kernel/topology.c                 |  27 +-----
>  drivers/acpi/Kconfig                       |  14 ++-
>  drivers/acpi/acpi_processor.c              | 151 +++++++++++++++++++++++------
>  drivers/acpi/bus.c                         |  16 +++
>  drivers/acpi/device_pm.c                   |   2 +-
>  drivers/acpi/device_sysfs.c                |   2 +-
>  drivers/acpi/internal.h                    |   1 -
>  drivers/acpi/processor_core.c              |   2 +-
>  drivers/acpi/property.c                    |   2 +-
>  drivers/acpi/scan.c                        | 148 ++++++++++++++++++----------
>  drivers/base/arch_topology.c               |  38 +++++---
>  drivers/base/cpu.c                         |  44 +++++++--
>  drivers/base/init.c                        |   2 +-
>  drivers/base/node.c                        |   7 --
>  drivers/firmware/psci/psci.c               |   2 +
>  drivers/irqchip/irq-gic-v3.c               |  38 +++++---
>  include/acpi/acpi_bus.h                    |   1 +
>  include/acpi/actbl2.h                      |   1 +
>  include/linux/acpi.h                       |  13 ++-
>  include/linux/cpu.h                        |   4 +
>  include/linux/cpumask.h                    |  25 +++++
>  kernel/cpu.c                               |   3 +
>  48 files changed, 516 insertions(+), 292 deletions(-)
> 
> 
> On Wed, Sep 13, 2023 at 04:37:48PM +0000, James Morse wrote:
> > Hello!
> > 
> > Changes since RFC-v1:
> >  * riscv is new, ia64 is gone
> >  * The KVM support is different, and upstream - no need to patch the host.
> > 
> > ---
> > 
> > This series adds what looks like cpuhotplug support to arm64 for use in
> > virtual machines. It does this by moving the cpu_register() calls for
> > architectures that support ACPI out of the arch code by using
> > GENERIC_CPU_DEVICES, then into the ACPI processor driver.
> > 
> > The kubernetes folk really want to be able to add CPUs to an existing VM,
> > in exactly the same way they do on x86. The use-case is pre-booting guests
> > with one CPU, then adding the number that were actually needed when the
> > workload is provisioned.
> > 
> > Wait? Doesn't arm64 support cpuhotplug already!?
> > In the arm world, cpuhotplug gets used to mean removing the power from a CPU.
> > The CPU is offline, and remains present. For x86, and ACPI, cpuhotplug
> > has the additional step of physically removing the CPU, so that it isn't
> > present anymore.
> > 
> > Arm64 doesn't support this, and can't support it: CPUs are really a slice
> > of the SoC, and there is not enough information in the existing ACPI tables
> > to describe which bits of the slice also got removed. Without a reference
> > machine: adding this support to the spec is a wild goose chase.
> > 
> > Critically: everything described in the firmware tables must remain present.
> > 
> > For a virtual machine this is easy as all the other bits of 'virtual SoC'
> > are emulated, so they can (and do) remain present when a vCPU is 'removed'.
> > 
> > On a system that supports cpuhotplug the MADT has to describe every possible
> > CPU at boot. Under KVM, the vGIC needs to know about every possible vCPU before
> > the guest is started.
> > With these constraints, virtual-cpuhotplug is really just a hypervisor/firmware
> > policy about which CPUs can be brought online.
> > 
> > This series adds support for virtual-cpuhotplug as exactly that: firmware
> > policy. This may even work on a physical machine too; for a guest the part of
> > firmware is played by the VMM. (typically Qemu).
> > 
> > PSCI support is modified to return 'DENIED' if the CPU can't be brought
> > online/enabled yet. The CPU object's _STA method's enabled bit is used to
> > indicate firmware's current disposition. If the CPU has its enabled bit clear,
> > it will not be registered with sysfs, and attempts to bring it online will
> > fail. The notifications that _STA has changed its value then work in the same
> > way as physical hotplug, and firmware can cause the CPU to be registered some
> > time later, allowing it to be brought online.
> > 
> > This creates something that looks like cpuhotplug to user-space, as the sysfs
> > files appear and disappear, and the udev notifications look the same.
> > 
> > One notable difference is the CPU present mask, which is exposed via sysfs.
> > Because the CPUs remain present throughout, they can still be seen in that mask.
> > This value does get used by webbrowsers to estimate the number of CPUs
> > as the CPU online mask is constantly changed on mobile phones.
> > 
> > Linux is tolerant of PSCI returning errors, as its always been allowed to do
> > that. To avoid confusing OS that can't tolerate this, we needed an additional
> > bit in the MADT GICC flags. This series copies ACPI_MADT_ONLINE_CAPABLE, which
> > appears to be for this purpose, but calls it ACPI_MADT_GICC_CPU_CAPABLE as it
> > has a different bit position in the GICC.
> > 
> > This code is unconditionally enabled for all ACPI architectures.
> > If there are problems with firmware tables on some devices, the CPUs will
> > already be online by the time the acpi_processor_make_enabled() is called.
> > A mismatch here causes a firmware-bug message and kernel taint. This should
> > only affect people with broken firmware who also boot with maxcpus=1, and
> > bring CPUs online later.
> > 
> > I had a go at switching the remaining architectures over to GENERIC_CPU_DEVICES,
> > so that the Kconfig symbol can be removed, but I got stuck with powerpc
> > and s390.
> > 
> > I've only build tested Loongarch and riscv. I've removed the ia64 specific
> > patches, but left the changes in other patches to make git-grep review of
> > renames easier.
> > 
> > If folk want to play along at home, you'll need a copy of Qemu that supports this.
> > https://github.com/salil-mehta/qemu.git salil/virt-cpuhp-armv8/rfc-v2-rc6
> > 
> > Replace your '-smp' argument with something like:
> > | -smp cpus=1,maxcpus=3,cores=3,threads=1,sockets=1
> > 
> > then feed the following to the Qemu montior;
> > | (qemu) device_add driver=host-arm-cpu,core-id=1,id=cpu1
> > | (qemu) device_del cpu1
> > 
> > 
> > Why is this still an RFC? I'm still looking for confirmation from the
> > kubernetes/kata folk that this works for them. Because of this I've culled
> > the CC list...
> > 
> > 
> > This series is based on v6.6-rc1, and can be retrieved from:
> > https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/ virtual_cpu_hotplug/rfc/v2
> > 
> > 
> > Thanks,
> > 
> > James Morse (34):
> >   ACPI: Move ACPI_HOTPLUG_CPU to be disabled on arm64 and riscv
> >   drivers: base: Use present CPUs in GENERIC_CPU_DEVICES
> >   drivers: base: Allow parts of GENERIC_CPU_DEVICES to be overridden
> >   drivers: base: Move cpu_dev_init() after node_dev_init()
> >   drivers: base: Print a warning instead of panic() when register_cpu()
> >     fails
> >   arm64: setup: Switch over to GENERIC_CPU_DEVICES using
> >     arch_register_cpu()
> >   x86: intel_epb: Don't rely on link order
> >   x86/topology: Switch over to GENERIC_CPU_DEVICES
> >   LoongArch: Switch over to GENERIC_CPU_DEVICES
> >   riscv: Switch over to GENERIC_CPU_DEVICES
> >   arch_topology: Make register_cpu_capacity_sysctl() tolerant to late
> >     CPUs
> >   ACPI: Use the acpi_device_is_present() helper in more places
> >   ACPI: Rename acpi_scan_device_not_present() to be about enumeration
> >   ACPI: Only enumerate enabled (or functional) devices
> >   ACPI: processor: Add support for processors described as container
> >     packages
> >   ACPI: processor: Register CPUs that are online, but not described in
> >     the DSDT
> >   ACPI: processor: Register all CPUs from acpi_processor_get_info()
> >   ACPI: Rename ACPI_HOTPLUG_CPU to include 'present'
> >   ACPI: Move acpi_bus_trim_one() before acpi_scan_hot_remove()
> >   ACPI: Rename acpi_processor_hotadd_init and remove pre-processor
> >     guards
> >   ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
> >   ACPI: Check _STA present bit before making CPUs not present
> >   ACPI: Warn when the present bit changes but the feature is not enabled
> >   drivers: base: Implement weak arch_unregister_cpu()
> >   LoongArch: Use the __weak version of arch_unregister_cpu()
> >   arm64: acpi: Move get_cpu_for_acpi_id() to a header
> >   ACPICA: Add new MADT GICC flags fields [code first?]
> >   arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a
> >     helper
> >   irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc()
> >   irqchip/gic-v3: Add support for ACPI's disabled but 'online capable'
> >     CPUs
> >   ACPI: add support to register CPUs based on the _STA enabled bit
> >   arm64: document virtual CPU hotplug's expectations
> >   ACPI: Add _OSC bits to advertise OS support for toggling CPU
> >     present/enabled
> >   cpumask: Add enabled cpumask for present CPUs that can be brought
> >     online
> > 
> > Jean-Philippe Brucker (1):
> >   arm64: psci: Ignore DENIED CPUs
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From adrian.hunter at intel.com  Wed Dec 13 04:48:15 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Wed, 13 Dec 2023 14:48:15 +0200
Subject: [PATCH v1 00/14] Clean up libperf cpumap's empty function
In-Reply-To: <ZXifiVytVbebYE3U@kernel.org>
References: <20231129060211.1890454-1-irogers@google.com>
 <ZXifiVytVbebYE3U@kernel.org>
Message-ID: <84755553-3a79-4693-9396-084e9ae41235@intel.com>

On 12/12/23 19:59, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 28, 2023 at 10:01:57PM -0800, Ian Rogers escreveu:
>> Rename and clean up the use of libperf CPU map functions particularly
>> focussing on perf_cpu_map__empty that may return true for maps
>> containing CPUs but also with an "any CPU"/dummy value.
>>
>> perf_cpu_map__nr is also troubling in that iterating an empty CPU map
>> will yield the "any CPU"/dummy value. Reduce the appearance of some
>> calls to this by using the perf_cpu_map__for_each_cpu macro.
>>
>> Ian Rogers (14):
>>   libperf cpumap: Rename perf_cpu_map__dummy_new
>>   libperf cpumap: Rename and prefer sysfs for perf_cpu_map__default_new
>>   libperf cpumap: Rename perf_cpu_map__empty
>>   libperf cpumap: Replace usage of perf_cpu_map__new(NULL)
>>   libperf cpumap: Add for_each_cpu that skips the "any CPU" case
> 
> Applied 1-6, with James Reviewed-by tags, would be good to have Adrian
> check the PT and BTS parts, testing the end result if he things its all
> ok.
> 

Changing the same lines of code twice in the same patch set is not
really kernel style.

Some of the churn could be reduced by applying and rebasing on the
patch below.

Ideally the patches should be reordered so that the lines only
change once i.e.

	perf_cpu_map__empty -> <replacement>

instead of

	perf_cpu_map__empty -> <rename> -> <replacement>

If that is too much trouble, please accept my ack instead:

Acked-by: Adrian Hunter <adrian.hunter at intel.com>


From: Adrian Hunter <adrian.hunter at intel.com>

Factor out perf_cpu_map__empty() use to reduce the occurrences and make
the code more readable.

Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
---
 tools/perf/arch/x86/util/intel-bts.c | 11 ++++++++---
 tools/perf/arch/x86/util/intel-pt.c  | 21 ++++++++++++---------
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/tools/perf/arch/x86/util/intel-bts.c b/tools/perf/arch/x86/util/intel-bts.c
index d2c8cac11470..cebe994eb9db 100644
--- a/tools/perf/arch/x86/util/intel-bts.c
+++ b/tools/perf/arch/x86/util/intel-bts.c
@@ -59,6 +59,11 @@ intel_bts_info_priv_size(struct auxtrace_record *itr __maybe_unused,
 	return INTEL_BTS_AUXTRACE_PRIV_SIZE;
 }
 
+static bool intel_bts_per_cpu(struct evlist *evlist)
+{
+	return !perf_cpu_map__empty(evlist->core.user_requested_cpus);
+}
+
 static int intel_bts_info_fill(struct auxtrace_record *itr,
 			       struct perf_session *session,
 			       struct perf_record_auxtrace_info *auxtrace_info,
@@ -109,8 +114,8 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
 	struct intel_bts_recording *btsr =
 			container_of(itr, struct intel_bts_recording, itr);
 	struct perf_pmu *intel_bts_pmu = btsr->intel_bts_pmu;
+	bool per_cpu_mmaps = intel_bts_per_cpu(evlist);
 	struct evsel *evsel, *intel_bts_evsel = NULL;
-	const struct perf_cpu_map *cpus = evlist->core.user_requested_cpus;
 	bool privileged = perf_event_paranoid_check(-1);
 
 	if (opts->auxtrace_sample_mode) {
@@ -143,7 +148,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
 	if (!opts->full_auxtrace)
 		return 0;
 
-	if (opts->full_auxtrace && !perf_cpu_map__empty(cpus)) {
+	if (opts->full_auxtrace && per_cpu_mmaps) {
 		pr_err(INTEL_BTS_PMU_NAME " does not support per-cpu recording\n");
 		return -EINVAL;
 	}
@@ -224,7 +229,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
 		 * In the case of per-cpu mmaps, we need the CPU on the
 		 * AUX event.
 		 */
-		if (!perf_cpu_map__empty(cpus))
+		if (per_cpu_mmaps)
 			evsel__set_sample_bit(intel_bts_evsel, CPU);
 	}
 
diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c
index fa0c718b9e72..0ff9147c75da 100644
--- a/tools/perf/arch/x86/util/intel-pt.c
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -312,6 +312,11 @@ static void intel_pt_tsc_ctc_ratio(u32 *n, u32 *d)
 	*d = eax;
 }
 
+static bool intel_pt_per_cpu(struct evlist *evlist)
+{
+	return !perf_cpu_map__empty(evlist->core.user_requested_cpus);
+}
+
 static int intel_pt_info_fill(struct auxtrace_record *itr,
 			      struct perf_session *session,
 			      struct perf_record_auxtrace_info *auxtrace_info,
@@ -322,7 +327,8 @@ static int intel_pt_info_fill(struct auxtrace_record *itr,
 	struct perf_pmu *intel_pt_pmu = ptr->intel_pt_pmu;
 	struct perf_event_mmap_page *pc;
 	struct perf_tsc_conversion tc = { .time_mult = 0, };
-	bool cap_user_time_zero = false, per_cpu_mmaps;
+	bool per_cpu_mmaps = intel_pt_per_cpu(session->evlist);
+	bool cap_user_time_zero = false;
 	u64 tsc_bit, mtc_bit, mtc_freq_bits, cyc_bit, noretcomp_bit;
 	u32 tsc_ctc_ratio_n, tsc_ctc_ratio_d;
 	unsigned long max_non_turbo_ratio;
@@ -369,8 +375,6 @@ static int intel_pt_info_fill(struct auxtrace_record *itr,
 			ui__warning("Intel Processor Trace: TSC not available\n");
 	}
 
-	per_cpu_mmaps = !perf_cpu_map__empty(session->evlist->core.user_requested_cpus);
-
 	auxtrace_info->type = PERF_AUXTRACE_INTEL_PT;
 	auxtrace_info->priv[INTEL_PT_PMU_TYPE] = intel_pt_pmu->type;
 	auxtrace_info->priv[INTEL_PT_TIME_SHIFT] = tc.time_shift;
@@ -604,8 +608,8 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
 	struct perf_pmu *intel_pt_pmu = ptr->intel_pt_pmu;
 	bool have_timing_info, need_immediate = false;
 	struct evsel *evsel, *intel_pt_evsel = NULL;
-	const struct perf_cpu_map *cpus = evlist->core.user_requested_cpus;
 	bool privileged = perf_event_paranoid_check(-1);
+	bool per_cpu_mmaps = intel_pt_per_cpu(evlist);
 	u64 tsc_bit;
 	int err;
 
@@ -774,8 +778,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
 	 * Per-cpu recording needs sched_switch events to distinguish different
 	 * threads.
 	 */
-	if (have_timing_info && !perf_cpu_map__empty(cpus) &&
-	    !record_opts__no_switch_events(opts)) {
+	if (have_timing_info && per_cpu_mmaps && !record_opts__no_switch_events(opts)) {
 		if (perf_can_record_switch_events()) {
 			bool cpu_wide = !target__none(&opts->target) &&
 					!target__has_task(&opts->target);
@@ -832,7 +835,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
 		 * In the case of per-cpu mmaps, we need the CPU on the
 		 * AUX event.
 		 */
-		if (!perf_cpu_map__empty(cpus))
+		if (per_cpu_mmaps)
 			evsel__set_sample_bit(intel_pt_evsel, CPU);
 	}
 
@@ -858,7 +861,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
 			tracking_evsel->immediate = true;
 
 		/* In per-cpu case, always need the time of mmap events etc */
-		if (!perf_cpu_map__empty(cpus)) {
+		if (per_cpu_mmaps) {
 			evsel__set_sample_bit(tracking_evsel, TIME);
 			/* And the CPU for switch events */
 			evsel__set_sample_bit(tracking_evsel, CPU);
@@ -870,7 +873,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
 	 * Warn the user when we do not have enough information to decode i.e.
 	 * per-cpu with no sched_switch (except workload-only).
 	 */
-	if (!ptr->have_sched_switch && !perf_cpu_map__empty(cpus) &&
+	if (!ptr->have_sched_switch && per_cpu_mmaps &&
 	    !target__none(&opts->target) &&
 	    !intel_pt_evsel->core.attr.exclude_user)
 		ui__warning("Intel Processor Trace decoding will not be possible except for kernel tracing!\n");
-- 
2.34.1





From vaishnav.a at ti.com  Wed Dec 13 04:49:27 2023
From: vaishnav.a at ti.com (Vaishnav Achath)
Date: Wed, 13 Dec 2023 18:19:27 +0530
Subject: [PATCH 0/3] arm64: dts: ti: Introduce J722S SoC and EVM
Message-ID: <20231213124930.3012-1-vaishnav.a@ti.com>

This series adds basic support for J722S family of SoCs. Also add
J722S EVM support with basic peripheral like MMC and UART.

TRM: https://www.ti.com/lit/zip/sprujb3
EVM Schematics: https://www.ti.com/lit/zip/sprr495

Bootlog:
https://gist.github.com/vaishnavachath/23d859925277df9ccd628190e7c23371

Depends on:
https://lore.kernel.org/all/20231211132600.25289-1-vaishnav.a at ti.com/
https://lore.kernel.org/all/20231213081318.26203-1-vaishnav.a at ti.com/

Vaishnav Achath (3):
  dt-bindings: arm: ti: Add bindings for J722S SoCs
  arm64: dts: ti: Introduce J722S family of SoCs
  arm64: dts: ti: Add support for TI J722S Evaluation Module

 .../devicetree/bindings/arm/ti/k3.yaml        |   6 +
 arch/arm64/boot/dts/ti/Makefile               |   3 +
 arch/arm64/boot/dts/ti/k3-j722s-evm.dts       | 253 ++++++++++++++++
 arch/arm64/boot/dts/ti/k3-j722s.dtsi          | 275 ++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-pinctrl.h           |   3 +
 5 files changed, 540 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-evm.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-j722s.dtsi

-- 
2.17.1



From vaishnav.a at ti.com  Wed Dec 13 04:49:29 2023
From: vaishnav.a at ti.com (Vaishnav Achath)
Date: Wed, 13 Dec 2023 18:19:29 +0530
Subject: [PATCH 2/3] arm64: dts: ti: Introduce J722S family of SoCs
In-Reply-To: <20231213124930.3012-1-vaishnav.a@ti.com>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
Message-ID: <20231213124930.3012-3-vaishnav.a@ti.com>

The J722S is a family of  application processors built for Automotive and
Linux Application development. Scalable Arm Cortex-A53 performance and
embedded features, such as multi high-definition display support,
3D-graphics acceleration, 4K video acceleration, and extensive peripherals
make the J722S well-suited for a broad range of automation and industrial
application, including automotive digital instrumentation, automotive
displays, industrial HMI, and more.

Some highlights of J722S SoC are:
    * Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
    * One Device manager Cortext-R5F for system power and resource
      management, two Cortex-R5F for Functional Safety or
      general-purpose usage and two C7x floating point vector DSPs
      with Matrix Multiply Accelerator(MMA) for deep learning.
    * One 3D GPU up to 50 GLFOPS
    * H.264/H.265, JPEG Video Encode/Decode.
    * Display support: 3x display support over OLDI/LVDS (1x OLDI-DL, 1x or
      2x OLDI-SL), DSI, or DPI. Up to 3840x1080 at 60fps resolution
    * Integrated Giga-bit Ethernet switch supporting up to a total of two
      external ports (TSN capable).
    * Vision Processing Accelerator (VPAC) with image signal processor
      and Depth and Motion Processing Accelerator (DMPAC).
    * 7xUARTs, 3xSPI, 5xI2C, 2xUSB2, 2xCAN-FD, 3xMMC and SD, GPMC for
      NAND/FPGA connection, OSPI memory controller, 5xMcASP for audio,
      4xCSI-RX for Camera, 1 PCIe Gen3 controller, eCAP/eQEP,
      ePWM, among other peripherals.
    * Dedicated Centralized Hardware Security Module with support for
      secure boot, debug security and crypto acceleration and trusted
      execution environment.
    * One 32-bit DDR Subsystem that supports LPDDR4 memory type.

J722S family of SoCs is a superset of the AM62P SoC family and shares
similar memory map, thus the nodes are being reused from AM62P includes
instead of duplicating the definitions. Unused nodes with dependencies
are kept disabled and will be enabled later when the dependencies are
enabled.

For those interested, more details about this SoC can be found in the
Technical Reference Manual here:
	https://www.ti.com/lit/zip/sprujb3

Co-developed-by: Jayesh Choudhary <j-choudhary at ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary at ti.com>
Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
---

checkpatch error is ignored for arch/arm64/boot/dts/ti/k3-pinctrl.h:
ERROR: Macros with complex values should be enclosed in parentheses

However, we do not need parentheses enclosing the values for this
macro as we do intend it to generate two separate values as has been
done for other similar platforms.

Depends on:
https://lore.kernel.org/all/20231211132600.25289-1-vaishnav.a at ti.com/
https://lore.kernel.org/all/20231213081318.26203-1-vaishnav.a at ti.com/

 arch/arm64/boot/dts/ti/k3-j722s.dtsi | 275 +++++++++++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-pinctrl.h  |   3 +
 2 files changed, 278 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/k3-j722s.dtsi

diff --git a/arch/arm64/boot/dts/ti/k3-j722s.dtsi b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
new file mode 100644
index 000000000000..dbd762bfd779
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for J722S SoC Family
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+#include "k3-pinctrl.h"
+
+/ {
+	model = "Texas Instruments K3 J722S SoC";
+	compatible = "ti,j722s";
+	interrupt-parent = <&gic500>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0: cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+
+				core1 {
+					cpu = <&cpu1>;
+				};
+
+				core2 {
+					cpu = <&cpu2>;
+				};
+
+				core3 {
+					cpu = <&cpu3>;
+				};
+			};
+		};
+
+		cpu0: cpu at 0 {
+			compatible = "arm,cortex-a53";
+			reg = <0x000>;
+			device_type = "cpu";
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2_0>;
+			clocks = <&k3_clks 135 0>;
+		};
+
+		cpu1: cpu at 1 {
+			compatible = "arm,cortex-a53";
+			reg = <0x001>;
+			device_type = "cpu";
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2_0>;
+			clocks = <&k3_clks 136 0>;
+		};
+
+		cpu2: cpu at 2 {
+			compatible = "arm,cortex-a53";
+			reg = <0x002>;
+			device_type = "cpu";
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2_0>;
+			clocks = <&k3_clks 137 0>;
+		};
+
+		cpu3: cpu at 3 {
+			compatible = "arm,cortex-a53";
+			reg = <0x003>;
+			device_type = "cpu";
+			enable-method = "psci";
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2_0>;
+			clocks = <&k3_clks 138 0>;
+		};
+	};
+
+	l2_0: l2-cache0 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+		cache-size = <0x80000>;
+		cache-line-size = <64>;
+		cache-sets = <512>;
+	};
+
+	firmware {
+		optee {
+			compatible = "linaro,optee-tz";
+			method = "smc";
+		};
+
+		psci: psci {
+			compatible = "arm,psci-1.0";
+			method = "smc";
+		};
+	};
+
+	a53_timer0: timer-cl0-cpu0 {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
+	};
+
+	pmu: pmu {
+		compatible = "arm,cortex-a53-pmu";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	cbass_main: bus at f0000 {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		bootph-all;
+
+		ranges = <0x00 0x000f0000 0x00 0x000f0000 0x00 0x00030000>, /* Main MMRs */
+			 <0x00 0x00420000 0x00 0x00420000 0x00 0x00001000>, /* ESM0 */
+			 <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
+			 <0x00 0x00703000 0x00 0x00703000 0x00 0x00000200>, /* USB0 debug trace */
+			 <0x00 0x0070c000 0x00 0x0070c000 0x00 0x00000200>, /* USB1 debug trace */
+			 <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
+			 <0x00 0x01000000 0x00 0x01000000 0x00 0x01b28400>, /* First peripheral window */
+			 <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
+			 <0x00 0x0e000000 0x00 0x0e000000 0x00 0x01d20000>, /* Second peripheral window */
+			 <0x00 0x0fd80000 0x00 0x0fd80000 0x00 0x00080000>, /* GPU */
+			 <0x00 0x0fd20000 0x00 0x0fd20000 0x00 0x00000100>, /* JPEGENC0_CORE */
+			 <0x00 0x0fd20200 0x00 0x0fd20200 0x00 0x00000200>, /* JPEGENC0_CORE_MMU */
+			 <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
+			 <0x00 0x30040000 0x00 0x30040000 0x00 0x00080000>, /* PRUSS-M */
+			 <0x00 0x301C0000 0x00 0x301C0000 0x00 0x00001000>, /* DPHY-TX */
+			 <0x00 0x30101000 0x00 0x30101000 0x00 0x00080100>, /* CSI window */
+			 <0x00 0x30200000 0x00 0x30200000 0x00 0x00010000>, /* DSS */
+			 <0x00 0x30210000 0x00 0x30210000 0x00 0x00010000>, /* VPU */
+			 <0x00 0x30220000 0x00 0x30220000 0x00 0x00010000>, /* DSS1 */
+			 <0x00 0x30270000 0x00 0x30270000 0x00 0x00010000>, /* DSI-base1 */
+			 <0x00 0x30500000 0x00 0x30500000 0x00 0x00100000>, /* DSI-base2 */
+			 <0x00 0x31000000 0x00 0x31000000 0x00 0x00050000>, /* USB0 DWC3 Core window */
+			 <0x00 0x31200000 0x00 0x31200000 0x00 0x00040000>, /* USB1 DWC3 Core window */
+			 <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, /* SA3UL */
+			 <0x00 0x43600000 0x00 0x43600000 0x00 0x00010000>, /* SA3 sproxy data */
+			 <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
+			 <0x00 0x44860000 0x00 0x44860000 0x00 0x00040000>, /* SA3 sproxy config */
+			 <0x00 0x48000000 0x00 0x48000000 0x00 0x06408000>, /* DMSS */
+			 <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
+			 <0x00 0x70000000 0x00 0x70000000 0x00 0x00040000>, /* OCSRAM */
+			 <0x00 0x78400000 0x00 0x78400000 0x00 0x00008000>, /* MAIN R5FSS0 ATCM */
+			 <0x00 0x78500000 0x00 0x78500000 0x00 0x00008000>, /* MAIN R5FSS0 BTCM */
+			 <0x00 0x7e000000 0x00 0x7e000000 0x00 0x00200000>, /* C7X_0 L2SRAM */
+			 <0x00 0x7e200000 0x00 0x7e200000 0x00 0x00200000>, /* C7X_1 L2SRAM */
+			 <0x01 0x00000000 0x01 0x00000000 0x00 0x00310000>, /* A53 PERIPHBASE */
+			 <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
+
+			 /* MCU Domain Range */
+			 <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>,
+			 <0x00 0x79000000 0x00 0x79000000 0x00 0x00008000>,
+			 <0x00 0x79020000 0x00 0x79020000 0x00 0x00008000>,
+			 <0x00 0x79100000 0x00 0x79100000 0x00 0x00040000>,
+			 <0x00 0x79140000 0x00 0x79140000 0x00 0x00040000>,
+
+			 /* Wakeup Domain Range */
+			 <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>,
+			 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>,
+			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>,
+			 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>,
+			 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>;
+
+		cbass_mcu: bus at 4000000 {
+			compatible = "simple-bus";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>, /* Peripheral window */
+				 <0x00 0x79000000 0x00 0x79000000 0x00 0x00008000>, /* MCU R5 ATCM */
+				 <0x00 0x79020000 0x00 0x79020000 0x00 0x00008000>, /* MCU R5 BTCM */
+				 <0x00 0x79100000 0x00 0x79100000 0x00 0x00040000>, /* MCU IRAM0 */
+				 <0x00 0x79140000 0x00 0x79140000 0x00 0x00040000>; /* MCU IRAM1 */
+			bootph-all;
+		};
+
+		cbass_wakeup: bus at b00000 {
+			compatible = "simple-bus";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges = <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
+				 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
+				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* WKUP CTRL MMR */
+				 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
+				 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
+			bootph-all;
+		};
+	};
+
+	#include "k3-am62p-thermal.dtsi"
+};
+
+/*
+ * Include peripherals for each bus segment derived
+ * from AM62P and overrides specific to J722S.
+ */
+#include "k3-am62p-main.dtsi"
+#include "k3-am62p-mcu.dtsi"
+#include "k3-am62p-wakeup.dtsi"
+
+/* Main domain overrides */
+
+&cpsw3g {
+	status = "disabled";
+};
+
+&inta_main_dmss {
+	ti,interrupt-ranges = <5 69 35>;
+};
+
+&mailbox0_cluster0 {
+	status = "disabled";
+};
+
+&mailbox0_cluster1 {
+	status = "disabled";
+};
+
+&mailbox0_cluster2 {
+	status = "disabled";
+};
+
+&mailbox0_cluster3 {
+	status = "disabled";
+};
+
+&oc_sram {
+	reg = <0x00 0x70000000 0x00 0x40000>;
+	ranges = <0x00 0x00 0x70000000 0x40000>;
+};
+
+/* MCU domain overrides */
+
+&mcu_r5fss0 {
+	status = "disabled";
+};
+
+/* wakeup domain overrides */
+
+&wkup_r5fss0 {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-pinctrl.h b/arch/arm64/boot/dts/ti/k3-pinctrl.h
index 2a4e0e084d69..591be4489f37 100644
--- a/arch/arm64/boot/dts/ti/k3-pinctrl.h
+++ b/arch/arm64/boot/dts/ti/k3-pinctrl.h
@@ -59,6 +59,9 @@
 #define J721S2_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
 #define J721S2_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
 
+#define J722S_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
+#define J722S_MCU_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
+
 #define J784S4_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
 #define J784S4_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
 
-- 
2.17.1



From vaishnav.a at ti.com  Wed Dec 13 04:49:28 2023
From: vaishnav.a at ti.com (Vaishnav Achath)
Date: Wed, 13 Dec 2023 18:19:28 +0530
Subject: [PATCH 1/3] dt-bindings: arm: ti: Add bindings for J722S SoCs
In-Reply-To: <20231213124930.3012-1-vaishnav.a@ti.com>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
Message-ID: <20231213124930.3012-2-vaishnav.a@ti.com>

Add bindings for TI J722S family of devices.

Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
---
 Documentation/devicetree/bindings/arm/ti/k3.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index c6506bccfe88..d52672348424 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -123,6 +123,12 @@ properties:
               - ti,j721s2-evm
           - const: ti,j721s2
 
+      - description: K3 J722S SoC and Boards
+        items:
+          - enum:
+              - ti,j722s-evm
+          - const: ti,j722s
+
       - description: K3 J784s4 SoC
         items:
           - enum:
-- 
2.17.1



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:49:31 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:49:31 +0000
Subject: [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from
 acpi_processor_get_info()
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOg7-00Dvjq-VZ@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

To allow ACPI to skip the call to arch_register_cpu() when the _STA
value indicates the CPU can't be brought online right now, move the
arch_register_cpu() call into acpi_processor_get_info().

Systems can still be booted with 'acpi=off', or not include an
ACPI description at all. For these, the CPUs continue to be
registered by cpu_dev_register_generic().

This moves the CPU register logic back to a subsys_initcall(),
while the memory nodes will have been registered earlier.

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by: Gavin Shan <gshan at redhat.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
Changes since RFC v2:
 * Fixup comment in acpi_processor_get_info() (Gavin Shan)
 * Add comment in cpu_dev_register_generic() (Gavin Shan)
---
 drivers/acpi/acpi_processor.c | 12 ++++++++++++
 drivers/base/cpu.c            |  6 +++++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 0511f2bc10bc..e7ed4730cbbe 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -314,6 +314,18 @@ static int acpi_processor_get_info(struct acpi_device *device)
 			cpufreq_add_device("acpi-cpufreq");
 	}
 
+	/*
+	 * Register CPUs that are present. get_cpu_device() is used to skip
+	 * duplicate CPU descriptions from firmware.
+	 */
+	if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id) &&
+	    !get_cpu_device(pr->id)) {
+		int ret = arch_register_cpu(pr->id);
+
+		if (ret)
+			return ret;
+	}
+
 	/*
 	 *  Extra Processor objects may be enumerated on MP systems with
 	 *  less than the max # of CPUs. They should be ignored _iff
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 47de0f140ba6..13d052bf13f4 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -553,7 +553,11 @@ static void __init cpu_dev_register_generic(void)
 {
 	int i, ret;
 
-	if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES))
+	/*
+	 * When ACPI is enabled, CPUs are registered via
+	 * acpi_processor_get_info().
+	 */
+	if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES) || !acpi_disabled)
 		return;
 
 	for_each_present_cpu(i) {
-- 
2.30.2



From vaishnav.a at ti.com  Wed Dec 13 04:49:30 2023
From: vaishnav.a at ti.com (Vaishnav Achath)
Date: Wed, 13 Dec 2023 18:19:30 +0530
Subject: [PATCH 3/3] arm64: dts: ti: Add support for TI J722S Evaluation Module
In-Reply-To: <20231213124930.3012-1-vaishnav.a@ti.com>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
Message-ID: <20231213124930.3012-4-vaishnav.a@ti.com>

Add basic support for the J722S EVM with UART console and
MMC SD as rootfs.

Schematics are available at:
	https://www.ti.com/lit/zip/sprr495

Co-developed-by: Jayesh Choudhary <j-choudhary at ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary at ti.com>
Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
---
 arch/arm64/boot/dts/ti/Makefile         |   3 +
 arch/arm64/boot/dts/ti/k3-j722s-evm.dts | 253 ++++++++++++++++++++++++
 2 files changed, 256 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-evm.dts

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 1ac47876bc99..aa7cc33e239b 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -76,6 +76,9 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
 k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
 
+# Boards with J722s SoC
+dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
+
 # Boards with J784s4 SoC
 dtb-$(CONFIG_ARCH_K3) += k3-am69-sk.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
new file mode 100644
index 000000000000..1cb29203a8ed
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
@@ -0,0 +1,253 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for the J722S-EVM
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ *
+ * Schematics: https://www.ti.com/lit/zip/sprr495
+ */
+
+/dts-v1/;
+
+#include "k3-j722s.dtsi"
+
+/ {
+	compatible = "ti,j722s-evm", "ti,j722s";
+	model = "Texas Instruments J722S EVM";
+
+	aliases {
+		serial0 = &wkup_uart0;
+		serial2 = &main_uart0;
+		mmc0 = &sdhci0;
+		mmc1 = &sdhci1;
+	};
+
+	chosen {
+		stdout-path = &main_uart0;
+	};
+
+	memory at 80000000 {
+		/* 8G RAM */
+		reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+		      <0x00000008 0x80000000 0x00000001 0x80000000>;
+		device_type = "memory";
+		bootph-pre-ram;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		secure_tfa_ddr: tfa at 9e780000 {
+			reg = <0x00 0x9e780000 0x00 0x80000>;
+			no-map;
+		};
+
+		secure_ddr: optee at 9e800000 {
+			reg = <0x00 0x9e800000 0x00 0x01800000>;
+			no-map;
+		};
+
+		wkup_r5fss0_core0_memory_region: r5f-memory at a0100000 {
+			compatible = "shared-dma-pool";
+			reg = <0x00 0xa0100000 0x00 0xf00000>;
+			no-map;
+		};
+
+	};
+
+	vmain_pd: regulator-0 {
+		/* TPS65988 PD CONTROLLER OUTPUT */
+		compatible = "regulator-fixed";
+		regulator-name = "vmain_pd";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+		regulator-boot-on;
+		bootph-all;
+	};
+
+	vsys_5v0: regulator-vsys5v0 {
+		/* Output of LM5140 */
+		compatible = "regulator-fixed";
+		regulator-name = "vsys_5v0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vmain_pd>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vdd_mmc1: regulator-mmc1 {
+		/* TPS22918DBVR */
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_mmc1";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&exp1 15 GPIO_ACTIVE_HIGH>;
+		bootph-all;
+	};
+
+	vdd_sd_dv: regulator-TLV71033 {
+		compatible = "regulator-gpio";
+		regulator-name = "tlv71033";
+		pinctrl-names = "default";
+		pinctrl-0 = <&vdd_sd_dv_pins_default>;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		vin-supply = <&vsys_5v0>;
+		gpios = <&main_gpio0 70 GPIO_ACTIVE_HIGH>;
+		states = <1800000 0x0>,
+			 <3300000 0x1>;
+	};
+
+	vsys_io_1v8: regulator-vsys-io-1v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "vsys_io_1v8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vsys_io_1v2: regulator-vsys-io-1v2 {
+		compatible = "regulator-fixed";
+		regulator-name = "vsys_io_1v2";
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+&main_pmx0 {
+	bootph-all;
+
+	main_i2c0_pins_default: main-i2c0-default-pins {
+		pinctrl-single,pins = <
+			J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
+			J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
+		>;
+		bootph-all;
+	};
+
+	main_uart0_pins_default: main-uart0-default-pins {
+		pinctrl-single,pins = <
+			J722S_IOPAD(0x1c8, PIN_INPUT, 0)	/* (A22) UART0_RXD */
+			J722S_IOPAD(0x1cc, PIN_OUTPUT, 0)	/* (B22) UART0_TXD */
+		>;
+		bootph-all;
+	};
+
+	vdd_sd_dv_pins_default: vdd-sd-dv-default-pins {
+		pinctrl-single,pins = <
+			J722S_IOPAD(0x0120, PIN_INPUT, 7) /* (F27) MMC2_CMD.GPIO0_70 */
+		>;
+		bootph-all;
+	};
+
+	main_mmc1_pins_default: main-mmc1-default-pins {
+		pinctrl-single,pins = <
+			J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
+			J722S_IOPAD(0x0234, PIN_OUTPUT, 0) /* (H24) MMC1_CLK */
+			J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
+			J722S_IOPAD(0x022c, PIN_INPUT_PULLUP, 0) /* (H20) MMC1_DAT1 */
+			J722S_IOPAD(0x0228, PIN_INPUT_PULLUP, 0) /* (J23) MMC1_DAT2 */
+			J722S_IOPAD(0x0224, PIN_INPUT_PULLUP, 0) /* (H25) MMC1_DAT3 */
+			J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
+		>;
+		bootph-all;
+	};
+};
+
+&main_gpio1 {
+	status = "okay";
+};
+
+&main_uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&main_uart0_pins_default>;
+	status = "okay";
+	bootph-all;
+};
+
+&mcu_pmx0 {
+	bootph-all;
+
+	wkup_uart0_pins_default: wkup-uart0-default-pins {
+		pinctrl-single,pins = <
+			J722S_MCU_IOPAD(0x02c, PIN_INPUT, 0)	/* (C7) WKUP_UART0_CTSn */
+			J722S_MCU_IOPAD(0x030, PIN_OUTPUT, 0)	/* (C6) WKUP_UART0_RTSn */
+			J722S_MCU_IOPAD(0x024, PIN_INPUT, 0)	/* (D8) WKUP_UART0_RXD */
+			J722S_MCU_IOPAD(0x028, PIN_OUTPUT, 0)	/* (D7) WKUP_UART0_TXD */
+		>;
+		bootph-all;
+	};
+
+	wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+		pinctrl-single,pins = <
+			J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0)	/* (C7) WKUP_I2C0_SCL */
+			J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0)	/* (C6) WKUP_I2C1_SDA */
+		>;
+		bootph-all;
+	};
+};
+
+&wkup_uart0 {
+	/* WKUP UART0 is used by DM firmware */
+	pinctrl-names = "default";
+	pinctrl-0 = <&wkup_uart0_pins_default>;
+	status = "reserved";
+	bootph-all;
+};
+
+&wkup_i2c0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&wkup_i2c0_pins_default>;
+	clock-frequency = <400000>;
+	bootph-all;
+};
+
+&main_i2c0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&main_i2c0_pins_default>;
+	clock-frequency = <400000>;
+	bootph-all;
+
+	exp1: gpio at 23 {
+		compatible = "ti,tca6424";
+		reg = <0x23>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-line-names = "TRC_MUX_SEL", "OSPI/ONAND_MUX_SEL",
+				  "MCASP1_FET_SEL", "CTRL_PM_I2C_OE#",
+				  "CSI_VIO_SEL", "USB2.0_MUX_SEL",
+				  "CSI01_MUX_SEL_2", "CSI23_MUX_SEL_2",
+				  "LMK1_OE1", "LMK1_OE0",
+				  "LMK2_OE0", "LMK2_OE1",
+				  "GPIO_RGMII1_RST#", "GPIO_AUD_RSTn",
+				  "GPIO_eMMC_RSTn", "GPIO_uSD_PWR_EN",
+				  "USER_LED2", "MCAN0_STB",
+				  "PCIe0_1L_RC_RSTz", "PCIe0_1L_PRSNT#",
+				  "ENET1_EXP_SPARE2", "ENET1_EXP_PWRDN",
+				  "PD_I2ENET1_I2CMUX_SELC_IRQ", "ENET1_EXP_RESETZ";
+	};
+};
+
+&sdhci1 {
+	/* SD/MMC */
+	status = "okay";
+	vmmc-supply = <&vdd_mmc1>;
+	vqmmc-supply = <&vdd_sd_dv>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&main_mmc1_pins_default>;
+	ti,driver-strength-ohm = <50>;
+	disable-wp;
+	no-1-8-v;
+	bootph-all;
+};
-- 
2.17.1



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:49:42 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:49:42 +0000
Subject: [PATCH RFC v3 06/21] ACPI: Move acpi_bus_trim_one() before
 acpi_scan_hot_remove()
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgI-00Dvk8-8X@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

A subsequent patch will change acpi_scan_hot_remove() to call
acpi_bus_trim_one() instead of acpi_bus_trim(), meaning it can no longer
rely on the prototype in the header file.

Move these functions further up the file.
No change in behaviour.

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Reviewed-by: Gavin Shan <gshan at redhat.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
 drivers/acpi/scan.c | 76 ++++++++++++++++++++++-----------------------
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 728649a2a251..ec42fe9d0611 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -244,6 +244,44 @@ static int acpi_scan_try_to_offline(struct acpi_device *device)
 	return 0;
 }
 
+static int acpi_bus_trim_one(struct acpi_device *adev, void *not_used)
+{
+	struct acpi_scan_handler *handler = adev->handler;
+
+	acpi_dev_for_each_child_reverse(adev, acpi_bus_trim_one, NULL);
+
+	adev->flags.match_driver = false;
+	if (handler) {
+		if (handler->detach)
+			handler->detach(adev);
+
+		adev->handler = NULL;
+	} else {
+		device_release_driver(&adev->dev);
+	}
+	/*
+	 * Most likely, the device is going away, so put it into D3cold before
+	 * that.
+	 */
+	acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
+	adev->flags.initialized = false;
+	acpi_device_clear_enumerated(adev);
+
+	return 0;
+}
+
+/**
+ * acpi_bus_trim - Detach scan handlers and drivers from ACPI device objects.
+ * @adev: Root of the ACPI namespace scope to walk.
+ *
+ * Must be called under acpi_scan_lock.
+ */
+void acpi_bus_trim(struct acpi_device *adev)
+{
+	acpi_bus_trim_one(adev, NULL);
+}
+EXPORT_SYMBOL_GPL(acpi_bus_trim);
+
 static int acpi_scan_hot_remove(struct acpi_device *device)
 {
 	acpi_handle handle = device->handle;
@@ -2513,44 +2551,6 @@ int acpi_bus_scan(acpi_handle handle)
 }
 EXPORT_SYMBOL(acpi_bus_scan);
 
-static int acpi_bus_trim_one(struct acpi_device *adev, void *not_used)
-{
-	struct acpi_scan_handler *handler = adev->handler;
-
-	acpi_dev_for_each_child_reverse(adev, acpi_bus_trim_one, NULL);
-
-	adev->flags.match_driver = false;
-	if (handler) {
-		if (handler->detach)
-			handler->detach(adev);
-
-		adev->handler = NULL;
-	} else {
-		device_release_driver(&adev->dev);
-	}
-	/*
-	 * Most likely, the device is going away, so put it into D3cold before
-	 * that.
-	 */
-	acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
-	adev->flags.initialized = false;
-	acpi_device_clear_enumerated(adev);
-
-	return 0;
-}
-
-/**
- * acpi_bus_trim - Detach scan handlers and drivers from ACPI device objects.
- * @adev: Root of the ACPI namespace scope to walk.
- *
- * Must be called under acpi_scan_lock.
- */
-void acpi_bus_trim(struct acpi_device *adev)
-{
-	acpi_bus_trim_one(adev, NULL);
-}
-EXPORT_SYMBOL_GPL(acpi_bus_trim);
-
 int acpi_bus_register_early_device(int type)
 {
 	struct acpi_device *device = NULL;
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:49:47 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:49:47 +0000
Subject: [PATCH RFC v3 07/21] ACPI: Rename acpi_processor_hotadd_init and
 remove pre-processor guards
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgN-00DvkE-D8@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

acpi_processor_hotadd_init() will make a CPU present by mapping it
based on its hardware id.

'hotadd_init' is ambiguous once there are two different behaviours
for cpu hotplug. This is for toggling the _STA present bit. Subsequent
patches will add support for toggling the _STA enabled bit, named
acpi_processor_make_enabled().

Rename it acpi_processor_make_present() to make it clear this is
for CPUs that were not previously present.

Expose the function prototypes it uses to allow the preprocessor
guards to be removed. The IS_ENABLED() check will let the compiler
dead-code elimination pass remove this if it isn't going to be
used.

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
---
Outstanding comments:
 https://lore.kernel.org/r/20230914151720.00007105 at Huawei.com
 https://lore.kernel.org/r/b8f430c1-c30f-191f-18c6-f750fa6ba476 at redhat.com
  For this comment, we use IS_ENABLED() in multiple places in the kernel in
  this way, and it isn't a problem.
---
 drivers/acpi/acpi_processor.c | 14 +++++---------
 include/linux/acpi.h          |  2 --
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index c8e960ff0aca..26e3efb74614 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -183,13 +183,15 @@ static void __init acpi_pcc_cpufreq_init(void) {}
 #endif /* CONFIG_X86 */
 
 /* Initialization */
-#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
-static int acpi_processor_hotadd_init(struct acpi_processor *pr)
+static int acpi_processor_make_present(struct acpi_processor *pr)
 {
 	unsigned long long sta;
 	acpi_status status;
 	int ret;
 
+	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
+		return -ENODEV;
+
 	if (invalid_phys_cpuid(pr->phys_id))
 		return -ENODEV;
 
@@ -223,12 +225,6 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
 	cpu_maps_update_done();
 	return ret;
 }
-#else
-static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
-{
-	return -ENODEV;
-}
-#endif /* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
 
 static int acpi_processor_get_info(struct acpi_device *device)
 {
@@ -335,7 +331,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
 	 *  because cpuid <-> apicid mapping is persistent now.
 	 */
 	if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
-		int ret = acpi_processor_hotadd_init(pr);
+		int ret = acpi_processor_make_present(pr);
 
 		if (ret)
 			return ret;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 36071bc11acd..19d009ca9e7a 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -301,12 +301,10 @@ static inline int acpi_processor_evaluate_cst(acpi_handle handle, u32 cpu,
 }
 #endif
 
-#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 /* Arch dependent functions for cpu hotplug support */
 int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 acpi_id,
 		 int *pcpu);
 int acpi_unmap_cpu(int cpu);
-#endif /* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
 
 #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
 int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:49:52 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:49:52 +0000
Subject: [PATCH RFC v3 08/21] ACPI: Add post_eject to struct acpi_scan_handler
 for cpu hotplug
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgS-00DvkK-HR@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

struct acpi_scan_handler has a detach callback that is used to remove
a driver when a bus is changed. When interacting with an eject-request,
the detach callback is called before _EJ0.

This means the ACPI processor driver can't use _STA to determine if a
CPU has been made not-present, or some of the other _STA bits have been
changed. acpi_processor_remove() needs to know the value of _STA after
_EJ0 has been called.

Add a post_eject callback to struct acpi_scan_handler. This is called
after acpi_scan_hot_remove() has successfully called _EJ0. Because
acpi_bus_trim_one() also clears the handler pointer, it needs to be
told if the caller will go on to call acpi_bus_post_eject(), so
that acpi_device_clear_enumerated() and clearing the handler pointer
can be deferred. The existing not-used pointer is used for this.

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by: Joanthan Cameron <Jonathan.Cameron at huawei.com>
Reviewed-by: Gavin Shan <gshan at redhat.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
---
Outstanding comments:
 https://lore.kernel.org/r/20230914152809.00003152 at Huawei.com
 https://lore.kernel.org/r/c3ef8123-1fcc-7289-c475-c753de44d564 at redhat.com
---
 drivers/acpi/acpi_processor.c |  4 +--
 drivers/acpi/scan.c           | 52 ++++++++++++++++++++++++++++++-----
 include/acpi/acpi_bus.h       |  1 +
 3 files changed, 48 insertions(+), 9 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 26e3efb74614..b6f5005985c3 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -459,7 +459,7 @@ static int acpi_processor_add(struct acpi_device *device,
 
 #ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 /* Removal */
-static void acpi_processor_remove(struct acpi_device *device)
+static void acpi_processor_post_eject(struct acpi_device *device)
 {
 	struct acpi_processor *pr;
 
@@ -627,7 +627,7 @@ static struct acpi_scan_handler processor_handler = {
 	.ids = processor_device_ids,
 	.attach = acpi_processor_add,
 #ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
-	.detach = acpi_processor_remove,
+	.post_eject = acpi_processor_post_eject,
 #endif
 	.hotplug = {
 		.enabled = true,
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index ec42fe9d0611..6ffd65e9e512 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -244,18 +244,28 @@ static int acpi_scan_try_to_offline(struct acpi_device *device)
 	return 0;
 }
 
-static int acpi_bus_trim_one(struct acpi_device *adev, void *not_used)
+/**
+ * acpi_bus_trim_one() - Detach scan handlers and drivers from ACPI device
+ *                       objects.
+ * @adev:       Root of the ACPI namespace scope to walk.
+ * @eject:      Pointer to a bool that indicates if this was due to an
+ *              eject-request.
+ *
+ * Must be called under acpi_scan_lock.
+ * If @eject points to true, clearing the device enumeration is deferred until
+ * acpi_bus_post_eject() is called.
+ */
+static int acpi_bus_trim_one(struct acpi_device *adev, void *eject)
 {
 	struct acpi_scan_handler *handler = adev->handler;
+	bool is_eject = *(bool *)eject;
 
-	acpi_dev_for_each_child_reverse(adev, acpi_bus_trim_one, NULL);
+	acpi_dev_for_each_child_reverse(adev, acpi_bus_trim_one, eject);
 
 	adev->flags.match_driver = false;
 	if (handler) {
 		if (handler->detach)
 			handler->detach(adev);
-
-		adev->handler = NULL;
 	} else {
 		device_release_driver(&adev->dev);
 	}
@@ -265,7 +275,12 @@ static int acpi_bus_trim_one(struct acpi_device *adev, void *not_used)
 	 */
 	acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
 	adev->flags.initialized = false;
-	acpi_device_clear_enumerated(adev);
+
+	/* For eject this is deferred to acpi_bus_post_eject() */
+	if (!is_eject) {
+		adev->handler = NULL;
+		acpi_device_clear_enumerated(adev);
+	}
 
 	return 0;
 }
@@ -278,15 +293,36 @@ static int acpi_bus_trim_one(struct acpi_device *adev, void *not_used)
  */
 void acpi_bus_trim(struct acpi_device *adev)
 {
-	acpi_bus_trim_one(adev, NULL);
+	bool eject = false;
+
+	acpi_bus_trim_one(adev, &eject);
 }
 EXPORT_SYMBOL_GPL(acpi_bus_trim);
 
+static int acpi_bus_post_eject(struct acpi_device *adev, void *not_used)
+{
+	struct acpi_scan_handler *handler = adev->handler;
+
+	acpi_dev_for_each_child_reverse(adev, acpi_bus_post_eject, NULL);
+
+	if (handler) {
+		if (handler->post_eject)
+			handler->post_eject(adev);
+
+		adev->handler = NULL;
+	}
+
+	acpi_device_clear_enumerated(adev);
+
+	return 0;
+}
+
 static int acpi_scan_hot_remove(struct acpi_device *device)
 {
 	acpi_handle handle = device->handle;
 	unsigned long long sta;
 	acpi_status status;
+	bool eject = true;
 
 	if (device->handler && device->handler->hotplug.demand_offline) {
 		if (!acpi_scan_is_offline(device, true))
@@ -299,7 +335,7 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
 
 	acpi_handle_debug(handle, "Ejecting\n");
 
-	acpi_bus_trim(device);
+	acpi_bus_trim_one(device, &eject);
 
 	acpi_evaluate_lck(handle, 0);
 	/*
@@ -322,6 +358,8 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
 	} else if (sta & ACPI_STA_DEVICE_ENABLED) {
 		acpi_handle_warn(handle,
 			"Eject incomplete - status 0x%llx\n", sta);
+	} else {
+		acpi_bus_post_eject(device, NULL);
 	}
 
 	return 0;
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 1216d72c650f..c887c2dfc5b5 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -130,6 +130,7 @@ struct acpi_scan_handler {
 	bool (*match)(const char *idstr, const struct acpi_device_id **matchid);
 	int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
 	void (*detach)(struct acpi_device *dev);
+	void (*post_eject)(struct acpi_device *dev);
 	void (*bind)(struct device *phys_dev);
 	void (*unbind)(struct device *phys_dev);
 	struct acpi_hotplug_profile hotplug;
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:49:57 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:49:57 +0000
Subject: [PATCH RFC v3 09/21] ACPI: convert acpi_processor_post_eject() to use
 IS_ENABLED()
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgX-00DvkQ-Lg@rmk-PC.armlinux.org.uk>

Rather than ifdef'ing acpi_processor_post_eject() and its use site, use
IS_ENABLED() to increase compile coverage.

Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
 drivers/acpi/acpi_processor.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index b6f5005985c3..01c460881662 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -457,12 +457,14 @@ static int acpi_processor_add(struct acpi_device *device,
 	return result;
 }
 
-#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 /* Removal */
 static void acpi_processor_post_eject(struct acpi_device *device)
 {
 	struct acpi_processor *pr;
 
+	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
+		return;
+
 	if (!device || !acpi_driver_data(device))
 		return;
 
@@ -501,7 +503,6 @@ static void acpi_processor_post_eject(struct acpi_device *device)
 	free_cpumask_var(pr->throttling.shared_cpu_map);
 	kfree(pr);
 }
-#endif /* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
 
 #ifdef CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC
 bool __init processor_physically_present(acpi_handle handle)
@@ -626,9 +627,7 @@ static const struct acpi_device_id processor_device_ids[] = {
 static struct acpi_scan_handler processor_handler = {
 	.ids = processor_device_ids,
 	.attach = acpi_processor_add,
-#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 	.post_eject = acpi_processor_post_eject,
-#endif
 	.hotplug = {
 		.enabled = true,
 	},
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:02 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:02 +0000
Subject: [PATCH RFC v3 10/21] ACPI: Check _STA present bit before making CPUs
 not present
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgc-00DvkW-PZ@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

When called acpi_processor_post_eject() unconditionally make a CPU
not-present and unregisters it.

To add support for AML events where the CPU has become disabled, but
remains present, the _STA method should be checked before calling
acpi_processor_remove().

Rename acpi_processor_post_eject() acpi_processor_remove_possible(), and
check the _STA before calling.

Adding the function prototype for arch_unregister_cpu() allows the
preprocessor guards to be removed.

After this change CPUs will remain registered and visible to
user-space as offline if buggy firmware triggers an eject-request,
but doesn't clear the corresponding _STA bits after _EJ0 has been
called.

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
---
Changes since RFC v3:
 * Move IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU) into separate patch.
Outstanding comments:
 https://lore.kernel.org/r/20230914153110.00003e38 at Huawei.com
 https://lore.kernel.org/r/518859b1-64a9-d723-963c-56c7f6fc2da1 at redhat.com
  This contains a repeat of the IS_ENABLED() issue which we don't think
  is a problem - but there is another issue mentioned in that comment.
---
 drivers/acpi/acpi_processor.c | 28 ++++++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 01c460881662..19fceb3ec4e2 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -458,16 +458,13 @@ static int acpi_processor_add(struct acpi_device *device,
 }
 
 /* Removal */
-static void acpi_processor_post_eject(struct acpi_device *device)
+static void acpi_processor_make_not_present(struct acpi_device *device)
 {
 	struct acpi_processor *pr;
 
 	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
 		return;
 
-	if (!device || !acpi_driver_data(device))
-		return;
-
 	pr = acpi_driver_data(device);
 	if (pr->id >= nr_cpu_ids)
 		goto out;
@@ -504,6 +501,29 @@ static void acpi_processor_post_eject(struct acpi_device *device)
 	kfree(pr);
 }
 
+static void acpi_processor_post_eject(struct acpi_device *device)
+{
+	struct acpi_processor *pr;
+	unsigned long long sta;
+	acpi_status status;
+
+	if (!device)
+		return;
+
+	pr = acpi_driver_data(device);
+	if (!pr || pr->id >= nr_cpu_ids || invalid_phys_cpuid(pr->phys_id))
+		return;
+
+	status = acpi_evaluate_integer(pr->handle, "_STA", NULL, &sta);
+	if (ACPI_FAILURE(status))
+		return;
+
+	if (cpu_present(pr->id) && !(sta & ACPI_STA_DEVICE_PRESENT)) {
+		acpi_processor_make_not_present(device);
+		return;
+	}
+}
+
 #ifdef CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC
 bool __init processor_physically_present(acpi_handle handle)
 {
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:13 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:13 +0000
Subject: [PATCH RFC v3 12/21] arm64: acpi: Move get_cpu_for_acpi_id() to a
 header
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgn-00Dvki-2N@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

ACPI identifies CPUs by UID. get_cpu_for_acpi_id() maps the ACPI UID
to the linux CPU number.

The helper to retrieve this mapping is only available in arm64's numa
code.

Move it to live next to get_acpi_id_for_cpu().

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Reviewed-by: Gavin Shan <gshan at redhat.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
 arch/arm64/include/asm/acpi.h | 11 +++++++++++
 arch/arm64/kernel/acpi_numa.c | 11 -----------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 6792a1f83f2a..bc9a6656fc0c 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -119,6 +119,17 @@ static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
 	return	acpi_cpu_get_madt_gicc(cpu)->uid;
 }
 
+static inline int get_cpu_for_acpi_id(u32 uid)
+{
+	int cpu;
+
+	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
+		if (uid == get_acpi_id_for_cpu(cpu))
+			return cpu;
+
+	return -EINVAL;
+}
+
 static inline void arch_fix_phys_package_id(int num, u32 slot) { }
 void __init acpi_init_cpus(void);
 int apei_claim_sea(struct pt_regs *regs);
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index e51535a5f939..0c036a9a3c33 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -34,17 +34,6 @@ int __init acpi_numa_get_nid(unsigned int cpu)
 	return acpi_early_node_map[cpu];
 }
 
-static inline int get_cpu_for_acpi_id(u32 uid)
-{
-	int cpu;
-
-	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
-		if (uid == get_acpi_id_for_cpu(cpu))
-			return cpu;
-
-	return -EINVAL;
-}
-
 static int __init acpi_parse_gicc_pxm(union acpi_subtable_headers *header,
 				      const unsigned long end)
 {
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:18 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:18 +0000
Subject: [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgs-00Dvko-6t@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

Add the new flag field to the MADT's GICC structure.

'Online Capable' indicates a disabled CPU can be enabled later. See
ACPI specification 6.5 Tabel 5.37: GICC CPU Interface Flags.

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
This patch probably needs to go via the upstream acpica project,
but is included here so the feature can be tested.

If the ACPICA header files are updated before merging this patch set,
this patch will need to be dropped.

Changes since RFC v2:
 * Add ACPI specification reference.
---
 include/acpi/actbl2.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index 3751ae69432f..c433a079d8e1 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -1046,6 +1046,7 @@ struct acpi_madt_generic_interrupt {
 /* ACPI_MADT_ENABLED                    (1)      Processor is usable if set */
 #define ACPI_MADT_PERFORMANCE_IRQ_MODE  (1<<1)	/* 01: Performance Interrupt Mode */
 #define ACPI_MADT_VGIC_IRQ_MODE         (1<<2)	/* 02: VGIC Maintenance Interrupt mode */
+#define ACPI_MADT_GICC_CPU_CAPABLE      (1<<3)	/* 03: CPU is online capable */
 
 /* 12: Generic Distributor (ACPI 5.0 + ACPI 6.0 changes) */
 
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:23 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:23 +0000
Subject: [PATCH RFC v3 14/21] irqchip/gic-v3: Don't return errors from
 gic_acpi_match_gicc()
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgx-00Dvkv-Bb@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

gic_acpi_match_gicc() is only called via gic_acpi_count_gicr_regions().
It should only count the number of enabled redistributors, but it
also tries to sanity check the GICC entry, currently returning an
error if the Enabled bit is set, but the gicr_base_address is zero.

Adding support for the online-capable bit to the sanity check
complicates it, for no benefit. The existing check implicitly
depends on gic_acpi_count_gicr_regions() previous failing to find
any GICR regions (as it is valid to have gicr_base_address of zero if
the redistributors are described via a GICR entry).

Instead of complicating the check, remove it. Failures that happen
at this point cause the irqchip not to register, meaning no irqs
can be requested. The kernel grinds to a panic() pretty quickly.

Without the check, MADT tables that exhibit this problem are still
caught by gic_populate_rdist(), which helpfully also prints what
went wrong:
| CPU4: mpidr 100 has no re-distributor!

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by: Gavin Shan <gshan at redhat.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
 drivers/irqchip/irq-gic-v3.c | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 98b0329b7154..ebecd4546830 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -2420,21 +2420,15 @@ static int __init gic_acpi_match_gicc(union acpi_subtable_headers *header,
 
 	/*
 	 * If GICC is enabled and has valid gicr base address, then it means
-	 * GICR base is presented via GICC
+	 * GICR base is presented via GICC. The redistributor is only known to
+	 * be accessible if the GICC is marked as enabled. If this bit is not
+	 * set, we'd need to add the redistributor at runtime, which isn't
+	 * supported.
 	 */
-	if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) {
+	if (gicc->flags & ACPI_MADT_ENABLED && gicc->gicr_base_address)
 		acpi_data.enabled_rdists++;
-		return 0;
-	}
 
-	/*
-	 * It's perfectly valid firmware can pass disabled GICC entry, driver
-	 * should not treat as errors, skip the entry instead of probe fail.
-	 */
-	if (!acpi_gicc_is_usable(gicc))
-		return 0;
-
-	return -ENODEV;
+	return 0;
 }
 
 static int __init gic_acpi_count_gicr_regions(void)
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:28 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:28 +0000
Subject: [PATCH RFC v3 15/21] irqchip/gic-v3: Add support for ACPI's disabled
 but 'online capable' CPUs
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOh2-00Dvl1-H6@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

To support virtual CPU hotplug, ACPI has added an 'online capable' bit
to the MADT GICC entries. This indicates a disabled CPU entry may not
be possible to online via PSCI until firmware has set enabled bit in
_STA.

What about the redistributor in the GICC entry? ACPI doesn't want to say.
Assume the worst: When a redistributor is described in the GICC entry,
but the entry is marked as disabled at boot, assume the redistributor
is inaccessible.

The GICv3 driver doesn't support late online of redistributors, so this
means the corresponding CPU can't be brought online either. Clear the
possible and present bits.

Systems that want CPU hotplug in a VM can ensure their redistributors
are always-on, and describe them that way with a GICR entry in the MADT.

When mapping redistributors found via GICC entries, handle the case
where the arch code believes the CPU is present and possible, but it
does not have an accessible redistributor. Print a warning and clear
the present and possible bits.

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
----
Disabled but online-capable CPUs cause this message to be printed
if their redistributors are described via GICC:
| GICv3: CPU 3's redistributor is inaccessible: this CPU can't be brought online

If ACPI's _STA tries to make the cpu present later, this message is printed:
| Changing CPU present bit is not supported

Changes since RFC v2:
 * use gicc->flags & (ACPI_MADT_ENABLED | ACPI_MADT_GICC_CPU_CAPABLE)
---
 drivers/irqchip/irq-gic-v3.c | 14 ++++++++++++++
 include/linux/acpi.h         |  2 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index ebecd4546830..6d0f98d3540e 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -2370,11 +2370,25 @@ gic_acpi_parse_madt_gicc(union acpi_subtable_headers *header,
 				(struct acpi_madt_generic_interrupt *)header;
 	u32 reg = readl_relaxed(acpi_data.dist_base + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
 	u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
+	int cpu = get_cpu_for_acpi_id(gicc->uid);
 	void __iomem *redist_base;
 
 	if (!acpi_gicc_is_usable(gicc))
 		return 0;
 
+	/*
+	 * Capable but disabled CPUs can be brought online later. What about
+	 * the redistributor? ACPI doesn't want to say!
+	 * Virtual hotplug systems can use the MADT's "always-on" GICR entries.
+	 * Otherwise, prevent such CPUs from being brought online.
+	 */
+	if (!(gicc->flags & ACPI_MADT_ENABLED)) {
+		pr_warn_once("CPU %u's redistributor is inaccessible: this CPU can't be brought online\n", cpu);
+		set_cpu_present(cpu, false);
+		set_cpu_possible(cpu, false);
+		return 0;
+	}
+
 	redist_base = ioremap(gicc->gicr_base_address, size);
 	if (!redist_base)
 		return -ENOMEM;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 19d009ca9e7a..00be66683505 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -238,7 +238,7 @@ void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
 
 static inline bool acpi_gicc_is_usable(struct acpi_madt_generic_interrupt *gicc)
 {
-	return gicc->flags & ACPI_MADT_ENABLED;
+	return gicc->flags & (ACPI_MADT_ENABLED | ACPI_MADT_GICC_CPU_CAPABLE);
 }
 
 /* the following numa functions are architecture-dependent */
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:33 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:33 +0000
Subject: [PATCH RFC v3 16/21] arm64: psci: Ignore DENIED CPUs
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOh7-00Dvl7-LR@rmk-PC.armlinux.org.uk>

From: Jean-Philippe Brucker <jean-philippe at linaro.org>

When a CPU is marked as disabled, but online capable in the MADT, PSCI
applies some firmware policy to control when it can be brought online.
PSCI returns DENIED to a CPU_ON request if this is not currently
permitted. The OS can learn the current policy from the _STA enabled bit.

Handle the PSCI DENIED return code gracefully instead of printing an
error.

See https://developer.arm.com/documentation/den0022/f/?lang=en page 58.

Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
[ morse: Rewrote commit message ]
Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
Changes since RFC v2
 * Add specification reference
 * Use EPERM rather than EPROBE_DEFER
Changes since RFC v3:
 * Use EPERM everywhere
 * Drop unnecessary changes to drivers/firmware/psci/psci.c
---
 arch/arm64/kernel/psci.c | 2 +-
 arch/arm64/kernel/smp.c  | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index 29a8e444db83..fabd732d0a2d 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -40,7 +40,7 @@ static int cpu_psci_cpu_boot(unsigned int cpu)
 {
 	phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry);
 	int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry);
-	if (err)
+	if (err && err != -EPERM)
 		pr_err("failed to boot CPU%d (%d)\n", cpu, err);
 
 	return err;
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index defbab84e9e5..6bc9094feb19 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -132,7 +132,8 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 	/* Now bring the CPU into our world */
 	ret = boot_secondary(cpu, idle);
 	if (ret) {
-		pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
+		if (ret != -EPERM)
+			pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
 		return ret;
 	}
 
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:38 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:38 +0000
Subject: [PATCH RFC v3 17/21] ACPI: add support to register CPUs based on the
 _STA enabled bit
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOhC-00DvlI-Pp@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

acpi_processor_get_info() registers all present CPUs. Registering a
CPU is what creates the sysfs entries and triggers the udev
notifications.

arm64 virtual machines that support 'virtual cpu hotplug' use the
enabled bit to indicate whether the CPU can be brought online, as
the existing ACPI tables require all hardware to be described and
present.

If firmware describes a CPU as present, but disabled, skip the
registration. Such CPUs are present, but can't be brought online for
whatever reason. (e.g. firmware/hypervisor policy).

Once firmware sets the enabled bit, the CPU can be registered and
brought online by user-space. Online CPUs, or CPUs that are missing
an _STA method must always be registered.

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by: Gavin Shan <gshan at redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
 drivers/acpi/acpi_processor.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index b7a94c1348b0..5dabb426481f 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -228,6 +228,32 @@ static int acpi_processor_make_present(struct acpi_processor *pr)
 	return ret;
 }
 
+static int acpi_processor_make_enabled(struct acpi_processor *pr)
+{
+	unsigned long long sta;
+	acpi_status status;
+	bool present, enabled;
+
+	if (!acpi_has_method(pr->handle, "_STA"))
+		return arch_register_cpu(pr->id);
+
+	status = acpi_evaluate_integer(pr->handle, "_STA", NULL, &sta);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	present = sta & ACPI_STA_DEVICE_PRESENT;
+	enabled = sta & ACPI_STA_DEVICE_ENABLED;
+
+	if (cpu_online(pr->id) && (!present || !enabled)) {
+		pr_err_once(FW_BUG "CPU %u is online, but described as not present or disabled!\n", pr->id);
+		add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
+	} else if (!present || !enabled) {
+		return -ENODEV;
+	}
+
+	return arch_register_cpu(pr->id);
+}
+
 static int acpi_processor_get_info(struct acpi_device *device)
 {
 	union acpi_object object = { 0 };
@@ -318,7 +344,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
 	 */
 	if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id) &&
 	    !get_cpu_device(pr->id)) {
-		int ret = arch_register_cpu(pr->id);
+		int ret = acpi_processor_make_enabled(pr);
 
 		if (ret)
 			return ret;
@@ -526,6 +552,9 @@ static void acpi_processor_post_eject(struct acpi_device *device)
 		acpi_processor_make_not_present(device);
 		return;
 	}
+
+	if (cpu_present(pr->id) && !(sta & ACPI_STA_DEVICE_ENABLED))
+		arch_unregister_cpu(pr->id);
 }
 
 #ifdef CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:43 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:43 +0000
Subject: [PATCH RFC v3 18/21] ACPI: processor: Only call arch_unregister_cpu()
 if HOTPLUG_CPU is selected
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOhH-00DvlO-UP@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

The kbuild robot points out that configurations without HOTPLUG_CPU
selected can try to build acpi_processor_post_eject() without success
as arch_unregister_cpu() is not defined.

Check this explicitly. This will be merged into:
| ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
for any subsequent posting.

Reported-by: kbuild test robot <lkp at intel.com>
Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
---
This should probably be squashed into an earlier patch.
---
 drivers/acpi/acpi_processor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 5dabb426481f..ea12e70dfd39 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -537,7 +537,7 @@ static void acpi_processor_post_eject(struct acpi_device *device)
 	unsigned long long sta;
 	acpi_status status;
 
-	if (!device)
+	if (!IS_ENABLED(CONFIG_HOTPLUG_CPU) || !device)
 		return;
 
 	pr = acpi_driver_data(device);
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:49 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:49 +0000
Subject: [PATCH RFC v3 19/21] arm64: document virtual CPU hotplug's
 expectations
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOhN-00DvlU-2e@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

Add a description of physical and virtual CPU hotplug, explain the
differences and elaborate on what is required in ACPI for a working
virtual hotplug system.

Signed-off-by: James Morse <james.morse at arm.com>
---
 Outstanding comment:
  https://lore.kernel.org/r/20230914174137.00000a62 at Huawei.com
---
 Documentation/arch/arm64/cpu-hotplug.rst | 79 ++++++++++++++++++++++++
 Documentation/arch/arm64/index.rst       |  1 +
 2 files changed, 80 insertions(+)
 create mode 100644 Documentation/arch/arm64/cpu-hotplug.rst

diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst
new file mode 100644
index 000000000000..76ba8d932c72
--- /dev/null
+++ b/Documentation/arch/arm64/cpu-hotplug.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _cpuhp_index:
+
+====================
+CPU Hotplug and ACPI
+====================
+
+CPU hotplug in the arm64 world is commonly used to describe the kernel taking
+CPUs online/offline using PSCI. This document is about ACPI firmware allowing
+CPUs that were not available during boot to be added to the system later.
+
+``possible`` and ``present`` refer to the state of the CPU as seen by linux.
+
+
+CPU Hotplug on physical systems - CPUs not present at boot
+----------------------------------------------------------
+
+Physical systems need to mark a CPU that is ``possible`` but not ``present`` as
+being ``present``. An example would be a dual socket machine, where the package
+in one of the sockets can be replaced while the system is running.
+
+This is not supported.
+
+In the arm64 world CPUs are not a single device but a slice of the system.
+There are no systems that support the physical addition (or removal) of CPUs
+while the system is running, and ACPI is not able to sufficiently describe
+them.
+
+e.g. New CPUs come with new caches, but the platform's cache toplogy is
+described in a static table, the PPTT. How caches are shared between CPUs is
+not discoverable, and must be described by firmware.
+
+e.g. The GIC redistributor for each CPU must be accessed by the driver during
+boot to discover the system wide supported features. ACPI's MADT GICC
+structures can describe a redistributor associated with a disabled CPU, but
+can't describe whether the redistributor is accessible, only that it is not
+'always on'.
+
+arm64's ACPI tables assume that everything described is ``present``.
+
+
+CPU Hotplug on virtual systems - CPUs not enabled at boot
+---------------------------------------------------------
+
+Virtual systems have the advantage that all the properties the system will
+ever have can be described at boot. There are no power-domain considerations
+as such devices are emulated.
+
+CPU Hotplug on virtual systems is supported. It is distinct from physical
+CPU Hotplug as all resources are described as ``present``, but CPUs may be
+marked as disabled by firmware. Only the CPU's online/offline behaviour is
+influenced by firmware. An example is where a virtual machine boots with a
+single CPU, and additional CPUs are added once a cloud orchestrator deploys
+the workload.
+
+For a virtual machine, the VMM (e.g. Qemu) plays the part of firmware.
+
+Virtual hotplug is implemented as a firmware policy affecting which CPUs can be
+brought online. Firmware can enforce its policy via PSCI's return codes. e.g.
+``DENIED``.
+
+The ACPI tables must describe all the resources of the virtual machine. CPUs
+that firmware wishes to disable either from boot (or later) should not be
+``enabled`` in the MADT GICC structures, but should have the ``online capable``
+bit set, to indicate they can be enabled later. The boot CPU must be marked as
+``enabled``.  The 'always on' GICR structure must be used to describe the
+redistributors.
+
+CPUs described as ``online capable`` but not ``enabled`` can be set to enabled
+by the DSDT's Processor object's _STA method. On virtual systems the _STA method
+must always report the CPU as ``present``. Changes to the firmware policy can
+be notified to the OS via device-check or eject-request.
+
+CPUs described as ``enabled`` in the static table, should not have their _STA
+modified dynamically by firmware. Soft-restart features such as kexec will
+re-read the static properties of the system from these static tables, and
+may malfunction if these no longer describe the running system. Linux will
+re-discover the dynamic properties of the system from the _STA method later
+during boot.
diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
index d08e924204bf..78544de0a8a9 100644
--- a/Documentation/arch/arm64/index.rst
+++ b/Documentation/arch/arm64/index.rst
@@ -13,6 +13,7 @@ ARM64 Architecture
     asymmetric-32bit
     booting
     cpu-feature-registers
+    cpu-hotplug
     elf_hwcaps
     hugetlbpage
     kdump
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:54 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:54 +0000
Subject: [PATCH RFC v3 20/21] ACPI: Add _OSC bits to advertise OS support for
 toggling CPU present/enabled
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOhS-00Dvla-7i@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

Platform firmware can disabled a CPU, or make it not-present by making
an eject-request notification, then waiting for the os to make it offline
and call _EJx. After the firmware updates _STA with the new status.

Not all operating systems support this. For arm64 making CPUs not-present
has never been supported. For all ACPI architectures, making CPUs disabled
has recently been added. Firmware can't know what the OS has support for.

Add two new _OSC bits to advertise whether the OS supports the _STA enabled
or present bits being toggled for CPUs. This will be important for arm64
if systems that support physical CPU hotplug ever appear as arm64 linux
doesn't currently support this, so firmware shouldn't try.

Advertising this support to firmware is useful for cloud orchestrators
to know whether they can scale a particular VM by adding CPUs.

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
---
I'm assuming Loongarch machines do not support physical CPU hotplug.

Changes since RFC v3:
 * Drop ia64 changes
 * Update James' comment below "---" to remove reference to ia64

Outstanding comment:
 https://lore.kernel.org/r/20230914175021.000018fd at Huawei.com
---
 arch/x86/Kconfig              |  1 +
 drivers/acpi/Kconfig          |  9 +++++++++
 drivers/acpi/acpi_processor.c | 14 +++++++++++++-
 drivers/acpi/bus.c            | 16 ++++++++++++++++
 include/linux/acpi.h          |  4 ++++
 5 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 64fc7c475ab0..33fc4dcd950c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -60,6 +60,7 @@ config X86
 	select ACPI_LEGACY_TABLES_LOOKUP	if ACPI
 	select ACPI_SYSTEM_POWER_STATES_SUPPORT	if ACPI
 	select ACPI_HOTPLUG_PRESENT_CPU		if ACPI_PROCESSOR && HOTPLUG_CPU
+	select ACPI_HOTPLUG_IGNORE_OSC		if ACPI && HOTPLUG_CPU
 	select ARCH_32BIT_OFF_T			if X86_32
 	select ARCH_CLOCKSOURCE_INIT
 	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 9c5a43d0aff4..020e7c0ab985 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -311,6 +311,15 @@ config ACPI_HOTPLUG_PRESENT_CPU
 	depends on ACPI_PROCESSOR && HOTPLUG_CPU
 	select ACPI_CONTAINER
 
+config ACPI_HOTPLUG_IGNORE_OSC
+	bool
+	depends on ACPI_HOTPLUG_PRESENT_CPU
+	help
+	  Ignore whether firmware acknowledged support for toggling the CPU
+	  present bit in _STA. Some architectures predate the _OSC bits, so
+	  firmware doesn't know to do this.
+
+
 config ACPI_PROCESSOR_AGGREGATOR
 	tristate "Processor Aggregator"
 	depends on ACPI_PROCESSOR
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index ea12e70dfd39..5bb207a7a1dd 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -182,6 +182,18 @@ static void __init acpi_pcc_cpufreq_init(void)
 static void __init acpi_pcc_cpufreq_init(void) {}
 #endif /* CONFIG_X86 */
 
+static bool acpi_processor_hotplug_present_supported(void)
+{
+	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
+		return false;
+
+	/* x86 systems pre-date the _OSC bit */
+	if (IS_ENABLED(CONFIG_ACPI_HOTPLUG_IGNORE_OSC))
+		return true;
+
+	return osc_sb_hotplug_present_support_acked;
+}
+
 /* Initialization */
 static int acpi_processor_make_present(struct acpi_processor *pr)
 {
@@ -189,7 +201,7 @@ static int acpi_processor_make_present(struct acpi_processor *pr)
 	acpi_status status;
 	int ret;
 
-	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU)) {
+	if (!acpi_processor_hotplug_present_supported()) {
 		pr_err_once("Changing CPU present bit is not supported\n");
 		return -ENODEV;
 	}
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 72e64c0718c9..7122450739d6 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -298,6 +298,13 @@ EXPORT_SYMBOL_GPL(osc_sb_native_usb4_support_confirmed);
 
 bool osc_sb_cppc2_support_acked;
 
+/*
+ * ACPI 6.? Proposed Operating System Capabilities for modifying CPU
+ * present/enable.
+ */
+bool osc_sb_hotplug_enabled_support_acked;
+bool osc_sb_hotplug_present_support_acked;
+
 static u8 sb_uuid_str[] = "0811B06E-4A27-44F9-8D60-3CBBC22E7B48";
 static void acpi_bus_osc_negotiate_platform_control(void)
 {
@@ -346,6 +353,11 @@ static void acpi_bus_osc_negotiate_platform_control(void)
 
 	if (!ghes_disable)
 		capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_APEI_SUPPORT;
+
+	capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_HOTPLUG_ENABLED_SUPPORT;
+	if (IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
+		capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_HOTPLUG_PRESENT_SUPPORT;
+
 	if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
 		return;
 
@@ -383,6 +395,10 @@ static void acpi_bus_osc_negotiate_platform_control(void)
 			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT;
 		osc_cpc_flexible_adr_space_confirmed =
 			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_CPC_FLEXIBLE_ADR_SPACE;
+		osc_sb_hotplug_enabled_support_acked =
+			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_HOTPLUG_ENABLED_SUPPORT;
+		osc_sb_hotplug_present_support_acked =
+			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_HOTPLUG_PRESENT_SUPPORT;
 	}
 
 	kfree(context.ret.pointer);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 00be66683505..c572abac803c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -559,12 +559,16 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
 #define OSC_SB_NATIVE_USB4_SUPPORT		0x00040000
 #define OSC_SB_PRM_SUPPORT			0x00200000
 #define OSC_SB_FFH_OPR_SUPPORT			0x00400000
+#define OSC_SB_HOTPLUG_ENABLED_SUPPORT		0x00800000
+#define OSC_SB_HOTPLUG_PRESENT_SUPPORT		0x01000000
 
 extern bool osc_sb_apei_support_acked;
 extern bool osc_pc_lpi_support_confirmed;
 extern bool osc_sb_native_usb4_support_confirmed;
 extern bool osc_sb_cppc2_support_acked;
 extern bool osc_cpc_flexible_adr_space_confirmed;
+extern bool osc_sb_hotplug_enabled_support_acked;
+extern bool osc_sb_hotplug_present_support_acked;
 
 /* USB4 Capabilities */
 #define OSC_USB_USB3_TUNNELING			0x00000001
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:59 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:59 +0000
Subject: [PATCH RFC v3 21/21] cpumask: Add enabled cpumask for present CPUs
 that can be brought online
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOhX-00Dvlg-Ci@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

The 'offline' file in sysfs shows all offline CPUs, including those
that aren't present. User-space is expected to remove not-present CPUs
from this list to learn which CPUs could be brought online.

CPUs can be present but not-enabled. These CPUs can't be brought online
until the firmware policy changes, which comes with an ACPI notification
that will register the CPUs.

With only the offline and present files, user-space is unable to
determine which CPUs it can try to bring online. Add a new CPU mask
that shows this based on all the registered CPUs.

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
---
Outstanding comment:
 https://lore.kernel.org/r/20230914175443.000038f6 at Huawei.com
---
 drivers/base/cpu.c      | 10 ++++++++++
 include/linux/cpumask.h | 25 +++++++++++++++++++++++++
 kernel/cpu.c            |  3 +++
 3 files changed, 38 insertions(+)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 13d052bf13f4..a6e96a0a92b7 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -95,6 +95,7 @@ void unregister_cpu(struct cpu *cpu)
 {
 	int logical_cpu = cpu->dev.id;
 
+	set_cpu_enabled(logical_cpu, false);
 	unregister_cpu_under_node(logical_cpu, cpu_to_node(logical_cpu));
 
 	device_unregister(&cpu->dev);
@@ -273,6 +274,13 @@ static ssize_t print_cpus_offline(struct device *dev,
 }
 static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
 
+static ssize_t print_cpus_enabled(struct device *dev,
+				  struct device_attribute *attr, char *buf)
+{
+	return sysfs_emit(buf, "%*pbl\n", cpumask_pr_args(cpu_enabled_mask));
+}
+static DEVICE_ATTR(enabled, 0444, print_cpus_enabled, NULL);
+
 static ssize_t print_cpus_isolated(struct device *dev,
 				  struct device_attribute *attr, char *buf)
 {
@@ -413,6 +421,7 @@ int register_cpu(struct cpu *cpu, int num)
 	register_cpu_under_node(num, cpu_to_node(num));
 	dev_pm_qos_expose_latency_limit(&cpu->dev,
 					PM_QOS_RESUME_LATENCY_NO_CONSTRAINT);
+	set_cpu_enabled(num, true);
 
 	return 0;
 }
@@ -494,6 +503,7 @@ static struct attribute *cpu_root_attrs[] = {
 	&cpu_attrs[2].attr.attr,
 	&dev_attr_kernel_max.attr,
 	&dev_attr_offline.attr,
+	&dev_attr_enabled.attr,
 	&dev_attr_isolated.attr,
 #ifdef CONFIG_NO_HZ_FULL
 	&dev_attr_nohz_full.attr,
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index cfb545841a2c..cc72a0887f04 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -92,6 +92,7 @@ static inline void set_nr_cpu_ids(unsigned int nr)
  *
  *     cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
  *     cpu_present_mask - has bit 'cpu' set iff cpu is populated
+ *     cpu_enabled_mask  - has bit 'cpu' set iff cpu can be brought online
  *     cpu_online_mask  - has bit 'cpu' set iff cpu available to scheduler
  *     cpu_active_mask  - has bit 'cpu' set iff cpu available to migration
  *
@@ -124,11 +125,13 @@ static inline void set_nr_cpu_ids(unsigned int nr)
 
 extern struct cpumask __cpu_possible_mask;
 extern struct cpumask __cpu_online_mask;
+extern struct cpumask __cpu_enabled_mask;
 extern struct cpumask __cpu_present_mask;
 extern struct cpumask __cpu_active_mask;
 extern struct cpumask __cpu_dying_mask;
 #define cpu_possible_mask ((const struct cpumask *)&__cpu_possible_mask)
 #define cpu_online_mask   ((const struct cpumask *)&__cpu_online_mask)
+#define cpu_enabled_mask   ((const struct cpumask *)&__cpu_enabled_mask)
 #define cpu_present_mask  ((const struct cpumask *)&__cpu_present_mask)
 #define cpu_active_mask   ((const struct cpumask *)&__cpu_active_mask)
 #define cpu_dying_mask    ((const struct cpumask *)&__cpu_dying_mask)
@@ -993,6 +996,7 @@ extern const DECLARE_BITMAP(cpu_all_bits, NR_CPUS);
 #else
 #define for_each_possible_cpu(cpu) for_each_cpu((cpu), cpu_possible_mask)
 #define for_each_online_cpu(cpu)   for_each_cpu((cpu), cpu_online_mask)
+#define for_each_enabled_cpu(cpu)   for_each_cpu((cpu), cpu_enabled_mask)
 #define for_each_present_cpu(cpu)  for_each_cpu((cpu), cpu_present_mask)
 #endif
 
@@ -1015,6 +1019,15 @@ set_cpu_possible(unsigned int cpu, bool possible)
 		cpumask_clear_cpu(cpu, &__cpu_possible_mask);
 }
 
+static inline void
+set_cpu_enabled(unsigned int cpu, bool can_be_onlined)
+{
+	if (can_be_onlined)
+		cpumask_set_cpu(cpu, &__cpu_enabled_mask);
+	else
+		cpumask_clear_cpu(cpu, &__cpu_enabled_mask);
+}
+
 static inline void
 set_cpu_present(unsigned int cpu, bool present)
 {
@@ -1096,6 +1109,7 @@ static __always_inline unsigned int num_online_cpus(void)
 	return raw_atomic_read(&__num_online_cpus);
 }
 #define num_possible_cpus()	cpumask_weight(cpu_possible_mask)
+#define num_enabled_cpus()	cpumask_weight(cpu_enabled_mask)
 #define num_present_cpus()	cpumask_weight(cpu_present_mask)
 #define num_active_cpus()	cpumask_weight(cpu_active_mask)
 
@@ -1104,6 +1118,11 @@ static inline bool cpu_online(unsigned int cpu)
 	return cpumask_test_cpu(cpu, cpu_online_mask);
 }
 
+static inline bool cpu_enabled(unsigned int cpu)
+{
+	return cpumask_test_cpu(cpu, cpu_enabled_mask);
+}
+
 static inline bool cpu_possible(unsigned int cpu)
 {
 	return cpumask_test_cpu(cpu, cpu_possible_mask);
@@ -1128,6 +1147,7 @@ static inline bool cpu_dying(unsigned int cpu)
 
 #define num_online_cpus()	1U
 #define num_possible_cpus()	1U
+#define num_enabled_cpus()	1U
 #define num_present_cpus()	1U
 #define num_active_cpus()	1U
 
@@ -1141,6 +1161,11 @@ static inline bool cpu_possible(unsigned int cpu)
 	return cpu == 0;
 }
 
+static inline bool cpu_enabled(unsigned int cpu)
+{
+	return cpu == 0;
+}
+
 static inline bool cpu_present(unsigned int cpu)
 {
 	return cpu == 0;
diff --git a/kernel/cpu.c b/kernel/cpu.c
index a86972a91991..fe0a5189f8ae 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -3122,6 +3122,9 @@ EXPORT_SYMBOL(__cpu_possible_mask);
 struct cpumask __cpu_online_mask __read_mostly;
 EXPORT_SYMBOL(__cpu_online_mask);
 
+struct cpumask __cpu_enabled_mask __read_mostly;
+EXPORT_SYMBOL(__cpu_enabled_mask);
+
 struct cpumask __cpu_present_mask __read_mostly;
 EXPORT_SYMBOL(__cpu_present_mask);
 
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:49:16 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:49:16 +0000
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or functional)
 devices
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

Today the ACPI enumeration code 'visits' all devices that are present.

This is a problem for arm64, where CPUs are always present, but not
always enabled. When a device-check occurs because the firmware-policy
has changed and a CPU is now enabled, the following error occurs:
| acpi ACPI0007:48: Enumeration failure

This is ultimately because acpi_dev_ready_for_enumeration() returns
true for a device that is not enabled. The ACPI Processor driver
will not register such CPUs as they are not 'decoding their resources'.

Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
ACPI allows a device to be functional instead of maintaining the
present and enabled bit. Make this behaviour an explicit check with
a reference to the spec, and then check the present and enabled bits.
This is needed to avoid enumerating present && functional devices that
are not enabled.

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
If this change causes problems on deployed hardware, I suggest an
arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
acpi_dev_ready_for_enumeration() to only check the present bit.

Changes since RFC v2:
 * Incorporate comment suggestion by Gavin Shan.
Other review comments from Jonathan Cameron not yet addressed.
---
 drivers/acpi/device_pm.c    |  2 +-
 drivers/acpi/device_sysfs.c |  2 +-
 drivers/acpi/internal.h     |  1 -
 drivers/acpi/property.c     |  2 +-
 drivers/acpi/scan.c         | 24 ++++++++++++++----------
 5 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 3b4d048c4941..e3c80f3b3b57 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -313,7 +313,7 @@ int acpi_bus_init_power(struct acpi_device *device)
 		return -EINVAL;
 
 	device->power.state = ACPI_STATE_UNKNOWN;
-	if (!acpi_device_is_present(device)) {
+	if (!acpi_dev_ready_for_enumeration(device)) {
 		device->flags.initialized = false;
 		return -ENXIO;
 	}
diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
index 23373faa35ec..a0256d2493a7 100644
--- a/drivers/acpi/device_sysfs.c
+++ b/drivers/acpi/device_sysfs.c
@@ -141,7 +141,7 @@ static int create_pnp_modalias(const struct acpi_device *acpi_dev, char *modalia
 	struct acpi_hardware_id *id;
 
 	/* Avoid unnecessarily loading modules for non present devices. */
-	if (!acpi_device_is_present(acpi_dev))
+	if (!acpi_dev_ready_for_enumeration(acpi_dev))
 		return 0;
 
 	/*
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 866c7c4ed233..a1b45e345bcc 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -107,7 +107,6 @@ int acpi_device_setup_files(struct acpi_device *dev);
 void acpi_device_remove_files(struct acpi_device *dev);
 void acpi_device_add_finalize(struct acpi_device *device);
 void acpi_free_pnp_ids(struct acpi_device_pnp *pnp);
-bool acpi_device_is_present(const struct acpi_device *adev);
 bool acpi_device_is_battery(struct acpi_device *adev);
 bool acpi_device_is_first_physical_node(struct acpi_device *adev,
 					const struct device *dev);
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 6979a3f9f90a..14d6948fd88a 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1420,7 +1420,7 @@ static bool acpi_fwnode_device_is_available(const struct fwnode_handle *fwnode)
 	if (!is_acpi_device_node(fwnode))
 		return false;
 
-	return acpi_device_is_present(to_acpi_device_node(fwnode));
+	return acpi_dev_ready_for_enumeration(to_acpi_device_node(fwnode));
 }
 
 static const void *
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 02bb2cce423f..728649a2a251 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -304,7 +304,7 @@ static int acpi_scan_device_check(struct acpi_device *adev)
 	int error;
 
 	acpi_bus_get_status(adev);
-	if (acpi_device_is_present(adev)) {
+	if (acpi_dev_ready_for_enumeration(adev)) {
 		/*
 		 * This function is only called for device objects for which
 		 * matching scan handlers exist.  The only situation in which
@@ -338,7 +338,7 @@ static int acpi_scan_bus_check(struct acpi_device *adev, void *not_used)
 	int error;
 
 	acpi_bus_get_status(adev);
-	if (!acpi_device_is_present(adev)) {
+	if (!acpi_dev_ready_for_enumeration(adev)) {
 		acpi_scan_device_not_enumerated(adev);
 		return 0;
 	}
@@ -1913,11 +1913,6 @@ static bool acpi_device_should_be_hidden(acpi_handle handle)
 	return true;
 }
 
-bool acpi_device_is_present(const struct acpi_device *adev)
-{
-	return adev->status.present || adev->status.functional;
-}
-
 static bool acpi_scan_handler_matching(struct acpi_scan_handler *handler,
 				       const char *idstr,
 				       const struct acpi_device_id **matchid)
@@ -2381,16 +2376,25 @@ EXPORT_SYMBOL_GPL(acpi_dev_clear_dependencies);
  * acpi_dev_ready_for_enumeration - Check if the ACPI device is ready for enumeration
  * @device: Pointer to the &struct acpi_device to check
  *
- * Check if the device is present and has no unmet dependencies.
+ * Check if the device is functional or enabled and has no unmet dependencies.
  *
- * Return true if the device is ready for enumeratino. Otherwise, return false.
+ * Return true if the device is ready for enumeration. Otherwise, return false.
  */
 bool acpi_dev_ready_for_enumeration(const struct acpi_device *device)
 {
 	if (device->flags.honor_deps && device->dep_unmet)
 		return false;
 
-	return acpi_device_is_present(device);
+	/*
+	 * ACPI 6.5's 6.3.7 "_STA (Device Status)" allows firmware to return
+	 * (!present && functional) for certain types of devices that should be
+	 * enumerated. Note that the enabled bit can't be sert until the present
+	 * bit is set.
+	 */
+	if (device->status.present)
+		return device->status.enabled;
+	else
+		return device->status.functional;
 }
 EXPORT_SYMBOL_GPL(acpi_dev_ready_for_enumeration);
 
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:49:21 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:49:21 +0000
Subject: [PATCH RFC v3 02/21] ACPI: processor: Add support for processors
 described as container packages
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOfx-00Dvje-MS@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

ACPI has two ways of describing processors in the DSDT. From ACPI v6.5,
5.2.12:

"Starting with ACPI Specification 6.3, the use of the Processor() object
was deprecated. Only legacy systems should continue with this usage. On
the Itanium architecture only, a _UID is provided for the Processor()
that is a string object. This usage of _UID is also deprecated since it
can preclude an OSPM from being able to match a processor to a
non-enumerable device, such as those defined in the MADT. From ACPI
Specification 6.3 onward, all processor objects for all architectures
except Itanium must now use Device() objects with an _HID of ACPI0007,
and use only integer _UID values."

Also see https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html#declaring-processors

Duplicate descriptions are not allowed, the ACPI processor driver already
parses the UID from both devices and containers. acpi_processor_get_info()
returns an error if the UID exists twice in the DSDT.

The missing probe for CPUs described as packages creates a problem for
moving the cpu_register() calls into the acpi_processor driver, as CPUs
described like this don't get registered, leading to errors from other
subsystems when they try to add new sysfs entries to the CPU node.
(e.g. topology_sysfs_init()'s use of topology_add_dev() via cpuhp)

To fix this, parse the processor container and call acpi_processor_add()
for each processor that is discovered like this. The processor container
handler is added with acpi_scan_add_handler(), so no detach call will
arrive.

Qemu TCG describes CPUs using processor devices in a processor container.
For more information, see build_cpus_aml() in Qemu hw/acpi/cpu.c and
https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html#processor-container-device

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
---
Outstanding comments:
 https://lore.kernel.org/r/20230914145353.000072e2 at Huawei.com
 https://lore.kernel.org/r/50571c2f-aa3c-baeb-3add-cd59e0eddc02 at redhat.com
---
 drivers/acpi/acpi_processor.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 4fe2ef54088c..6a542e0ce396 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -626,9 +626,31 @@ static struct acpi_scan_handler processor_handler = {
 	},
 };
 
+static acpi_status acpi_processor_container_walk(acpi_handle handle,
+						 u32 lvl,
+						 void *context,
+						 void **rv)
+{
+	struct acpi_device *adev;
+	acpi_status status;
+
+	adev = acpi_get_acpi_dev(handle);
+	if (!adev)
+		return AE_ERROR;
+
+	status = acpi_processor_add(adev, &processor_device_ids[0]);
+	acpi_put_acpi_dev(adev);
+
+	return status;
+}
+
 static int acpi_processor_container_attach(struct acpi_device *dev,
 					   const struct acpi_device_id *id)
 {
+	acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle,
+			    ACPI_UINT32_MAX, acpi_processor_container_walk,
+			    NULL, NULL, NULL);
+
 	return 1;
 }
 
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:49:26 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:49:26 +0000
Subject: [PATCH RFC v3 03/21] ACPI: processor: Register CPUs that are online,
 but not described in the DSDT
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOg2-00Dvjk-RI@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

ACPI has two descriptions of CPUs, one in the MADT/APIC table, the other
in the DSDT. Both are required. (ACPI 6.5's 8.4 "Declaring Processors"
says "Each processor in the system must be declared in the ACPI
namespace"). Having two descriptions allows firmware authors to get
this wrong.

If CPUs are described in the MADT/APIC, they will be brought online
early during boot. Once the register_cpu() calls are moved to ACPI,
they will be based on the DSDT description of the CPUs. When CPUs are
missing from the DSDT description, they will end up online, but not
registered.

Add a helper that runs after acpi_init() has completed to register
CPUs that are online, but weren't found in the DSDT. Any CPU that
is registered by this code triggers a firmware-bug warning and kernel
taint.

Qemu TCG only describes the first CPU in the DSDT, unless cpu-hotplug
is configured.

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Reviewed-by: Gavin Shan <gshan at redhat.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
 drivers/acpi/acpi_processor.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 6a542e0ce396..0511f2bc10bc 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -791,6 +791,25 @@ void __init acpi_processor_init(void)
 	acpi_pcc_cpufreq_init();
 }
 
+static int __init acpi_processor_register_missing_cpus(void)
+{
+	int cpu;
+
+	if (acpi_disabled)
+		return 0;
+
+	for_each_online_cpu(cpu) {
+		if (!get_cpu_device(cpu)) {
+			pr_err_once(FW_BUG "CPU %u has no ACPI namespace description!\n", cpu);
+			add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
+			arch_register_cpu(cpu);
+		}
+	}
+
+	return 0;
+}
+subsys_initcall_sync(acpi_processor_register_missing_cpus);
+
 #ifdef CONFIG_ACPI_PROCESSOR_CSTATE
 /**
  * acpi_processor_claim_cst_control - Request _CST control from the platform.
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:49:37 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:49:37 +0000
Subject: [PATCH RFC v3 05/21] ACPI: Rename ACPI_HOTPLUG_CPU to include
 'present'
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgD-00Dvk2-3h@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

The code behind ACPI_HOTPLUG_CPU allows a not-present CPU to become
present. This isn't the only use of HOTPLUG_CPU. On arm64 and riscv
CPUs can be taken offline as a power saving measure.

On arm64 an offline CPU may be disabled by firmware, preventing it from
being brought back online, but it remains present throughout.

Adding code to prevent user-space trying to online these disabled CPUs
needs some additional terminology.

Rename the Kconfig symbol CONFIG_ACPI_HOTPLUG_PRESENT_CPU to reflect
that it makes possible CPUs present.

HOTPLUG_CPU is untouched as this is only about the ACPI mechanism.

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
Changes since RFC v2:
 * Add Loongarch update
Changes since RFC v3:
 * Dropped ia64 changes
---
 arch/loongarch/Kconfig                     |  2 +-
 arch/loongarch/configs/loongson3_defconfig |  2 +-
 arch/loongarch/kernel/acpi.c               |  4 ++--
 arch/x86/Kconfig                           |  2 +-
 arch/x86/kernel/acpi/boot.c                |  4 ++--
 drivers/acpi/Kconfig                       |  4 ++--
 drivers/acpi/acpi_processor.c              | 10 +++++-----
 include/linux/acpi.h                       |  6 +++---
 8 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index 15d05dd2b7f3..b1e87b90468d 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -5,7 +5,7 @@ config LOONGARCH
 	select ACPI
 	select ACPI_GENERIC_GSI if ACPI
 	select ACPI_MCFG if ACPI
-	select ACPI_HOTPLUG_CPU if ACPI_PROCESSOR && HOTPLUG_CPU
+	select ACPI_HOTPLUG_PRESENT_CPU if ACPI_PROCESSOR && HOTPLUG_CPU
 	select ACPI_PPTT if ACPI
 	select ACPI_SYSTEM_POWER_STATES_SUPPORT	if ACPI
 	select ARCH_BINFMT_ELF_STATE
diff --git a/arch/loongarch/configs/loongson3_defconfig b/arch/loongarch/configs/loongson3_defconfig
index 33795e4a5bd6..85d37b143077 100644
--- a/arch/loongarch/configs/loongson3_defconfig
+++ b/arch/loongarch/configs/loongson3_defconfig
@@ -59,7 +59,7 @@ CONFIG_ACPI_SPCR_TABLE=y
 CONFIG_ACPI_TAD=y
 CONFIG_ACPI_DOCK=y
 CONFIG_ACPI_IPMI=m
-CONFIG_ACPI_HOTPLUG_CPU=y
+CONFIG_ACPI_HOTPLUG_PRESENT_CPU=y
 CONFIG_ACPI_PCI_SLOT=y
 CONFIG_ACPI_HOTPLUG_MEMORY=y
 CONFIG_EFI_ZBOOT=y
diff --git a/arch/loongarch/kernel/acpi.c b/arch/loongarch/kernel/acpi.c
index 8e00a754e548..dfa56119b56f 100644
--- a/arch/loongarch/kernel/acpi.c
+++ b/arch/loongarch/kernel/acpi.c
@@ -288,7 +288,7 @@ void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)
 	memblock_reserve(addr, size);
 }
 
-#ifdef CONFIG_ACPI_HOTPLUG_CPU
+#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 
 #include <acpi/processor.h>
 
@@ -340,4 +340,4 @@ int acpi_unmap_cpu(int cpu)
 }
 EXPORT_SYMBOL(acpi_unmap_cpu);
 
-#endif /* CONFIG_ACPI_HOTPLUG_CPU */
+#endif /* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8330c4ac26b3..64fc7c475ab0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -59,7 +59,7 @@ config X86
 	#
 	select ACPI_LEGACY_TABLES_LOOKUP	if ACPI
 	select ACPI_SYSTEM_POWER_STATES_SUPPORT	if ACPI
-	select ACPI_HOTPLUG_CPU			if ACPI_PROCESSOR && HOTPLUG_CPU
+	select ACPI_HOTPLUG_PRESENT_CPU		if ACPI_PROCESSOR && HOTPLUG_CPU
 	select ARCH_32BIT_OFF_T			if X86_32
 	select ARCH_CLOCKSOURCE_INIT
 	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 1a0dd80d81ac..33d259ddd188 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -826,7 +826,7 @@ static void __init acpi_set_irq_model_ioapic(void)
 /*
  *  ACPI based hotplug support for CPU
  */
-#ifdef CONFIG_ACPI_HOTPLUG_CPU
+#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 #include <acpi/processor.h>
 
 static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
@@ -875,7 +875,7 @@ int acpi_unmap_cpu(int cpu)
 	return (0);
 }
 EXPORT_SYMBOL(acpi_unmap_cpu);
-#endif				/* CONFIG_ACPI_HOTPLUG_CPU */
+#endif				/* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
 
 int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base)
 {
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index a3acfc750fce..9c5a43d0aff4 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -306,7 +306,7 @@ config ACPI_IPMI
 	  To compile this driver as a module, choose M here:
 	  the module will be called as acpi_ipmi.
 
-config ACPI_HOTPLUG_CPU
+config ACPI_HOTPLUG_PRESENT_CPU
 	bool
 	depends on ACPI_PROCESSOR && HOTPLUG_CPU
 	select ACPI_CONTAINER
@@ -400,7 +400,7 @@ config ACPI_PCI_SLOT
 
 config ACPI_CONTAINER
 	bool "Container and Module Devices"
-	default (ACPI_HOTPLUG_MEMORY || ACPI_HOTPLUG_CPU)
+	default (ACPI_HOTPLUG_MEMORY || ACPI_HOTPLUG_PRESENT_CPU)
 	help
 	  This driver supports ACPI Container and Module devices (IDs
 	  ACPI0004, PNP0A05, and PNP0A06).
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index e7ed4730cbbe..c8e960ff0aca 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -183,7 +183,7 @@ static void __init acpi_pcc_cpufreq_init(void) {}
 #endif /* CONFIG_X86 */
 
 /* Initialization */
-#ifdef CONFIG_ACPI_HOTPLUG_CPU
+#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 static int acpi_processor_hotadd_init(struct acpi_processor *pr)
 {
 	unsigned long long sta;
@@ -228,7 +228,7 @@ static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
 {
 	return -ENODEV;
 }
-#endif /* CONFIG_ACPI_HOTPLUG_CPU */
+#endif /* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
 
 static int acpi_processor_get_info(struct acpi_device *device)
 {
@@ -461,7 +461,7 @@ static int acpi_processor_add(struct acpi_device *device,
 	return result;
 }
 
-#ifdef CONFIG_ACPI_HOTPLUG_CPU
+#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 /* Removal */
 static void acpi_processor_remove(struct acpi_device *device)
 {
@@ -505,7 +505,7 @@ static void acpi_processor_remove(struct acpi_device *device)
 	free_cpumask_var(pr->throttling.shared_cpu_map);
 	kfree(pr);
 }
-#endif /* CONFIG_ACPI_HOTPLUG_CPU */
+#endif /* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
 
 #ifdef CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC
 bool __init processor_physically_present(acpi_handle handle)
@@ -630,7 +630,7 @@ static const struct acpi_device_id processor_device_ids[] = {
 static struct acpi_scan_handler processor_handler = {
 	.ids = processor_device_ids,
 	.attach = acpi_processor_add,
-#ifdef CONFIG_ACPI_HOTPLUG_CPU
+#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 	.detach = acpi_processor_remove,
 #endif
 	.hotplug = {
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4db54e928b36..36071bc11acd 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -301,12 +301,12 @@ static inline int acpi_processor_evaluate_cst(acpi_handle handle, u32 cpu,
 }
 #endif
 
-#ifdef CONFIG_ACPI_HOTPLUG_CPU
+#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
 /* Arch dependent functions for cpu hotplug support */
 int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 acpi_id,
 		 int *pcpu);
 int acpi_unmap_cpu(int cpu);
-#endif /* CONFIG_ACPI_HOTPLUG_CPU */
+#endif /* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
 
 #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
 int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);
@@ -629,7 +629,7 @@ static inline u32 acpi_osc_ctx_get_cxl_control(struct acpi_osc_context *context)
 #define ACPI_GSB_ACCESS_ATTRIB_RAW_PROCESS	0x0000000F
 
 /* Enable _OST when all relevant hotplug operations are enabled */
-#if defined(CONFIG_ACPI_HOTPLUG_CPU) &&			\
+#if defined(CONFIG_ACPI_HOTPLUG_PRESENT_CPU) &&			\
 	defined(CONFIG_ACPI_HOTPLUG_MEMORY) &&		\
 	defined(CONFIG_ACPI_CONTAINER)
 #define ACPI_HOTPLUG_OST
-- 
2.30.2



From rmk+kernel at armlinux.org.uk  Wed Dec 13 04:50:07 2023
From: rmk+kernel at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 12:50:07 +0000
Subject: [PATCH RFC v3 11/21] ACPI: Warn when the present bit changes but the
 feature is not enabled
In-Reply-To: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
Message-ID: <E1rDOgh-00Dvkc-U3@rmk-PC.armlinux.org.uk>

From: James Morse <james.morse at arm.com>

ACPI firmware can trigger the events to add and remove CPUs, but the
OS may not support this.

Print an error message when this happens.

This gives early warning on arm64 systems that don't support
CONFIG_ACPI_HOTPLUG_PRESENT_CPU, as making CPUs not present has
side effects for other parts of the system.

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Reviewed-by: Gavin Shan <gshan at redhat.com>
Tested-by: Miguel Luis <miguel.luis at oracle.com>
Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu at arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
---
Changes since RFC v2:
 * Update commit message with suggestion from Gavin Shan
---
 drivers/acpi/acpi_processor.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 19fceb3ec4e2..b7a94c1348b0 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -189,8 +189,10 @@ static int acpi_processor_make_present(struct acpi_processor *pr)
 	acpi_status status;
 	int ret;
 
-	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
+	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU)) {
+		pr_err_once("Changing CPU present bit is not supported\n");
 		return -ENODEV;
+	}
 
 	if (invalid_phys_cpuid(pr->phys_id))
 		return -ENODEV;
@@ -462,8 +464,10 @@ static void acpi_processor_make_not_present(struct acpi_device *device)
 {
 	struct acpi_processor *pr;
 
-	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
+	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU)) {
+		pr_err_once("Changing CPU present bit is not supported");
 		return;
+	}
 
 	pr = acpi_driver_data(device);
 	if (pr->id >= nr_cpu_ids)
-- 
2.30.2



From rafael at kernel.org  Wed Dec 13 04:54:09 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 13 Dec 2023 13:54:09 +0100
Subject: [PATCH] ACPI: arm64: export acpi_arch_thermal_cpufreq_pctg
In-Reply-To: <20231212214843.256622-1-arnd@kernel.org>
References: <20231212214843.256622-1-arnd@kernel.org>
Message-ID: <CAJZ5v0jMcHCJpDBFO90217Q264JN1LLtc215oP5YQhBk8s1wVA@mail.gmail.com>

On Tue, Dec 12, 2023 at 10:48?PM Arnd Bergmann <arnd at kernel.org> wrote:
>
> From: Arnd Bergmann <arnd at arndb.de>
>
> The cpufreq code can be in a loadable module, so the architecture support
> for it has to be exported:
>
> ERROR: modpost: "acpi_arch_thermal_cpufreq_pctg" [drivers/acpi/processor.ko] undefined!
>
> Fixes: 310293a2b941 ("ACPI: processor: reduce CPUFREQ thermal reduction pctg for Tegra241")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/acpi/arm64/thermal_cpufreq.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/acpi/arm64/thermal_cpufreq.c b/drivers/acpi/arm64/thermal_cpufreq.c
> index d524f2cd6044..582854914c5c 100644
> --- a/drivers/acpi/arm64/thermal_cpufreq.c
> +++ b/drivers/acpi/arm64/thermal_cpufreq.c
> @@ -1,5 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  #include <linux/acpi.h>
> +#include <linux/export.h>
>
>  #include "../internal.h"
>
> @@ -18,3 +19,4 @@ int acpi_arch_thermal_cpufreq_pctg(void)
>
>         return 0;
>  }
> +EXPORT_SYMBOL_GPL(acpi_arch_thermal_cpufreq_pctg);
> --

Applied, thanks!


From retpolanne at posteo.net  Wed Dec 13 04:55:58 2023
From: retpolanne at posteo.net (Anne Macedo)
Date: Wed, 13 Dec 2023 12:55:58 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <20231213122523.219cbfc0@donnerap.manchester.arm.com>
References: <20231212122835.10850-2-retpolanne@posteo.net>
 <20231212162200.10b3868b@donnerap.manchester.arm.com>
 <axsvii25yrknfae6gdreti7lcskoscsdbsujwuispiieimsbdy@gwzm4l7mwlew>
 <20231213013544.2fc7e0d1@minigeek.lan>
 <ceuoq3xxgb5kkel7e7wqpslcg7h6dde3wgdqhyo7jgop6owovk@5a76ks5fiun4>
 <20231213122523.219cbfc0@donnerap.manchester.arm.com>
Message-ID: <cm5e7g2ozviyin6p3dh2qtuh4i3f2sbqq4c2arjtdektgk7i6c@l7aawekyj6t2>

On Wed, Dec 13, 2023 at 12:25:23PM +0000, Andre Przywara wrote:
> On Wed, 13 Dec 2023 11:02:39 +0000
> Anne Macedo <retpolanne at posteo.net> wrote:
> 
> Hi Anne,
> 
> > On Wed, Dec 13, 2023 at 01:35:44AM +0000, Andre Przywara wrote:
> > > On Tue, 12 Dec 2023 19:27:14 +0000
> > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > 
> > > Hi Anne,
> > >   
> > > > On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:  
> > > > > On Tue, 12 Dec 2023 12:28:30 +0000
> > > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > > 
> > > > > Hi Anne,
> > > > >     
> > > > > > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > > > > > Realtek 8211 PHY to Orange Pi One Plus.    
> > > > > 
> > > > > So can you state why this would be needed? This is the RTL8211 ID,    
> > > > 
> > > > Apologies, I completely forgot to include some context. 
> > > >   
> > > > > right? Which should be autodetected via MDIO. Looking back in my inbox
> > > > > you proposed this change before, for U-Boot, specifically, but I fail to
> > > > > find a solution or explanation what really happens here. Two Renesas .dts
> > > > > files have the same compatible, and the commit message talks about the
> > > > > reset line there, is this related?
> > > > > 
> > > > > So can you please give some more background and explanation? That would be
> > > > > part of a good commit message anyway ("why", not "what").    
> > > > 
> > > > Should I resend the commit with a more meaningful explanation? The
> > > > context is the following:
> > > > 
> > > > currently, ethernet doesn't seem to work on both u-boot and Linux on the
> > > > Orange Pi One Plus board. 
> > > > 
> > > > On the kernel, this error shows up:
> > > > 
> > > > Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > [    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> > > > 
> > > > After applying this fix, the PHY gets attached: 
> > > > 
> > > > Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > [    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
> > > > 
> > > > The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
> > > > to find a PHY, so this patch includes the correct PHY ID with the
> > > > RTL8211 ID. 
> > > > 
> > > > The behaviour is described on [1].  
> > > 
> > > So this is all an observation, but no real explanation, isn't it?  
> > 
> > I've made some analysis on [3] on this bug, but it was based solely on
> > u-boot. I was having trouble with the regulator and on u-boot nothing
> > would trigger the GPIO PD6 and the vcc-gmac-3v3 regulator, so the NIC
> > was completely dead. Next I did an analysis based on [2] because the
> > u-boot PHY initialization was flaky.
> > 
> > > To cite [1]: "If the PHY reports an incorrect ID (or none at all) ...".
> > > I am pretty sure this is not the case here, instead we are looking at
> > > some missing platform bits, like a missing clock, reset, or most likely
> > > regulator. Or one of the existing resources is wrongly assigned or  
> > 
> > As I mentioned, PHY initialization is flaky on u-boot, so maybe that
> > assumption is correct. 
> > 
> > > configured? If the PHY is not (yet?) powered correctly when the code
> > > does the auto-detection via the MDIO bus, then the initialisation would  
> > 
> > If I recall correctly (I don't know if I kept it in my notes :c), that
> > could be the case. regulator-boot-on makes the NIC work (LEDs blink, at
> > least) but it doesn't get initialized. 
> > 
> > > fail. But since it works when overriding the auto-detection, I feel
> > > like we are papering over something here.
> > > Do you have the schematics for this board? I can only find the one for
> > > the Orange Pi Plus 2E, and I don't know how similar those two are. This
> > > shows *two* regulators, but both are activated by the same GPIO.  
> > 
> > I do. It's available on [4]
> 
> Oh damn it, I got lost in Orange Pi's naming maze again - and was looking
> for the wrong board! So thanks for the link, and this clears things up!

Yay! 

> 
> So yes, the Orange Pi *One* Plus, much like the Orange Pi 3, uses *two*
> regulators for Ethernet: one 3.3V from the PMIC's ALDO2 rail to power the
> PHY, and a discrete 2.5V regulator, enabled by GPIO PD6, for the voltage

Oh! I didn't know about the PMIC's ALDO2.

> level on the MDIO lines. On top of this there is a reset line for the PHY,
> though this is held up by a pull-up resistor, so it *should* work,
> although we should describe this in the DT.

Noting here to take a look at the reset line so I can add it as well to
the DT.

> 
> So the DT looks wrong then: The reg_gmac_3v3 is actually a 2.5V regulator,
> and phy-supply is aldo2. I think it was done the way it is to somehow make
> it work with the current DT binding and code, which just supports one
> regulator. And aldo2 is referenced as the source of reg_gmac_3v3, which
> smells like another hack to me.

	reg_gmac_3v3: gmac-3v3 {
		compatible = "regulator-fixed";
		regulator-name = "vcc-gmac-3v3";
		regulator-min-microvolt = <3300000>;
		regulator-max-microvolt = <3300000>;
		startup-delay-us = <100000>;
		enable-active-high;
		gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
		vin-supply = <&reg_aldo2>;
	};

Interesting, I see the reg_aldo2 on vin-supply for reg_gmac_3v3. I don't
understand how it works, is it linking the regulator with the ALDO2 but
it also enables the PD6 GPIO?

> 
> > > It would also be interesting to see if any of Corentin's work for the
> > > Orange Pi 3 helps here?  
> > 
> > Adding [5] for reference here, thanks! Will check it out. 
> 
> This is an older version, there are actually updates. And he also mentions
> your board as well, so I think it just can sail in the wake of the OPi 3
> Ethernet enablement.
> 
> Can you try if this change, just applied to your .dts instead, works?
> https://github.com/montjoie/linux/commit/cf6e192eca1d59be630e6729d2cef9e897b3da8c

Will do! I'll be out of my lab today but will try it at night Brazil
time. 
> 
> Cheers,
> Andre
> 
> P.S. Is there any chance where I can reply/comment on your blog? It seems
> like I can clear some things up...

Please send me suggestions off thread, the blog is a static GHPages
blog, so I didn't implement replies yet. I will be happy to include them
to my notes :) 

> 
> > [3] https://blog.retpolanne.com/hardware/embedded/2023/07/07/embedded-phy.html
> > [4] https://linux-sunxi.org/images/7/7c/OrangePi_OnePlus_Schematics_v2.0.pdf
> > [5] https://lore.kernel.org/netdev/20220509074857.195302-1-clabbe at baylibre.com/
> > 
> > Regards, Anne
> 

Regards, Anne


From manikanta.guntupalli at amd.com  Wed Dec 13 05:00:20 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Wed, 13 Dec 2023 18:30:20 +0530
Subject: [PATCH V5 0/3] Add rs485 support to uartps driver
Message-ID: <20231213130023.606486-1-manikanta.guntupalli@amd.com>

Add reference to rs485.yaml.
Add rs485 support to uartps driver.
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.
Add support for RTS, delay_rts_before_send and delay_rts_after_send in RS485 mode.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.
Move cdns_uart_tx_empty function to avoid prototype statement.
Remove assignment of struct serial_rs485 to port->rs485 as
serial core performs that.
Switch to native RTS in non GPIO case.
Handle rs485 during stop tx.
Remove explicit calls to configure gpio direction and value,
as devm_gpiod_get_optional performs that by using GPIOD_OUT_LOW argument.
Update implementation to support configuration of GPIO/RTS value
based on user configuration of SER_RS485_RTS_ON_SEND and
SER_RS485_RTS_AFTER_SEND. Move implementation to start_tx from handle_tx.

Changes for V4:
Update rts-gpios description.
Create separate patch for cdns_uart_tx_empty relocation.
Call cdns_rs485_rx_setup() before uart_add_one_port() in probe.
Update gpio descriptor name to gpiod_rts.
Instead of cdns_rs485_config_gpio_rts_high() and
cdns_rs485_config_gpio_rts_low() functions for RTS/GPIO value
configuration implement cdns_rts_gpio_enable().
Disable auto rts and call cdns_uart_stop_tx() from cdns_rs485_config.
Use timer instead of mdelay for delay_rts_before_send and delay_rts_after_send.
Update cdns_uart_set_mctrl to support GPIO/RTS.

Changes for V5:
Remove rts-gpios description.
Update commit message and description.

Manikanta Guntupalli (3):
  dt-bindings: Add reference to rs485.yaml
  tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485
  tty: serial: uartps: Add rs485 support to uartps driver

 .../devicetree/bindings/serial/cdns,uart.yaml |   1 +
 drivers/tty/serial/xilinx_uartps.c            | 244 ++++++++++++++++--
 2 files changed, 221 insertions(+), 24 deletions(-)

-- 
2.25.1



From manikanta.guntupalli at amd.com  Wed Dec 13 05:00:21 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Wed, 13 Dec 2023 18:30:21 +0530
Subject: [PATCH V5 1/3] dt-bindings: Add reference to rs485.yaml
In-Reply-To: <20231213130023.606486-1-manikanta.guntupalli@amd.com>
References: <20231213130023.606486-1-manikanta.guntupalli@amd.com>
Message-ID: <20231213130023.606486-2-manikanta.guntupalli@amd.com>

Add reference to rs485.yaml

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.

Changes for V4:
Update rts-gpios description.

Changes for V5:
Remove rts-gpios description.
Update commit message and description.
---
 Documentation/devicetree/bindings/serial/cdns,uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
index e35ad1109efc..2129247d7c81 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
@@ -55,6 +55,7 @@ required:
 
 allOf:
   - $ref: serial.yaml#
+  - $ref: rs485.yaml#
   - if:
       properties:
         compatible:
-- 
2.25.1



From manikanta.guntupalli at amd.com  Wed Dec 13 05:00:22 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Wed, 13 Dec 2023 18:30:22 +0530
Subject: [PATCH V5 2/3] tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485
In-Reply-To: <20231213130023.606486-1-manikanta.guntupalli@amd.com>
References: <20231213130023.606486-1-manikanta.guntupalli@amd.com>
Message-ID: <20231213130023.606486-3-manikanta.guntupalli@amd.com>

Relocate cdns_uart_tx_empty function to avoid prototype statement in
rs485 changes.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes since V4:
This patch introduced in V4.

Changes for V5:
None.
---
 drivers/tty/serial/xilinx_uartps.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 920762d7b4a4..aafcc2179e0e 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -305,6 +305,21 @@ static void cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus)
 	tty_flip_buffer_push(&port->state->port);
 }
 
+/**
+ * cdns_uart_tx_empty -  Check whether TX is empty
+ * @port: Handle to the uart port structure
+ *
+ * Return: TIOCSER_TEMT on success, 0 otherwise
+ */
+static unsigned int cdns_uart_tx_empty(struct uart_port *port)
+{
+	unsigned int status;
+
+	status = readl(port->membase + CDNS_UART_SR);
+	status &= (CDNS_UART_SR_TXEMPTY | CDNS_UART_SR_TACTIVE);
+	return (status == CDNS_UART_SR_TXEMPTY) ? TIOCSER_TEMT : 0;
+}
+
 /**
  * cdns_uart_handle_tx - Handle the bytes to be Txed.
  * @dev_id: Id of the UART port
@@ -626,21 +641,6 @@ static void cdns_uart_stop_rx(struct uart_port *port)
 	writel(regval, port->membase + CDNS_UART_CR);
 }
 
-/**
- * cdns_uart_tx_empty -  Check whether TX is empty
- * @port: Handle to the uart port structure
- *
- * Return: TIOCSER_TEMT on success, 0 otherwise
- */
-static unsigned int cdns_uart_tx_empty(struct uart_port *port)
-{
-	unsigned int status;
-
-	status = readl(port->membase + CDNS_UART_SR) &
-		       (CDNS_UART_SR_TXEMPTY | CDNS_UART_SR_TACTIVE);
-	return (status == CDNS_UART_SR_TXEMPTY) ? TIOCSER_TEMT : 0;
-}
-
 /**
  * cdns_uart_break_ctl - Based on the input ctl we have to start or stop
  *			transmitting char breaks
-- 
2.25.1



From manikanta.guntupalli at amd.com  Wed Dec 13 05:00:23 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Wed, 13 Dec 2023 18:30:23 +0530
Subject: [PATCH V5 3/3] tty: serial: uartps: Add rs485 support to uartps driver
In-Reply-To: <20231213130023.606486-1-manikanta.guntupalli@amd.com>
References: <20231213130023.606486-1-manikanta.guntupalli@amd.com>
Message-ID: <20231213130023.606486-4-manikanta.guntupalli@amd.com>

Add rs485 support to uartps driver. Use either rts-gpios or RTS
to control RS485 phy as driver or a receiver.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.
Add support for RTS, delay_rts_before_send and delay_rts_after_send in RS485 mode.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.
Move cdns_uart_tx_empty function to avoid prototype statement.
Remove assignment of struct serial_rs485 to port->rs485 as
serial core performs that.
Switch to native RTS in non GPIO case.
Handle rs485 during stop tx.
Remove explicit calls to configure gpio direction and value,
as devm_gpiod_get_optional performs that by using GPIOD_OUT_LOW argument.
Update implementation to support configuration of GPIO/RTS value
based on user configuration of SER_RS485_RTS_ON_SEND and
SER_RS485_RTS_AFTER_SEND. Move implementation to start_tx from handle_tx.

Changes for V4:
Create separate patch for cdns_uart_tx_empty relocation.
Call cdns_rs485_rx_setup() before uart_add_one_port() in probe.
Update gpio descriptor name to gpiod_rts.
Instead of cdns_rs485_config_gpio_rts_high() and
cdns_rs485_config_gpio_rts_low() functions for RTS/GPIO value
configuration implement cdns_rts_gpio_enable().
Disable auto rts and call cdns_uart_stop_tx() from cdns_rs485_config.
Use timer instead of mdelay for delay_rts_before_send and delay_rts_after_send.
Update cdns_uart_set_mctrl to support GPIO/RTS.

Changes for V5:
None.
---
 drivers/tty/serial/xilinx_uartps.c | 214 +++++++++++++++++++++++++++--
 1 file changed, 205 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index aafcc2179e0e..3e1045896812 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -22,7 +22,9 @@
 #include <linux/of.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
-#include <linux/iopoll.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/delay.h>
 
 #define CDNS_UART_TTY_NAME	"ttyPS"
 #define CDNS_UART_NAME		"xuartps"
@@ -193,6 +195,10 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255");
  * @clk_rate_change_nb:	Notifier block for clock changes
  * @quirks:		Flags for RXBS support.
  * @cts_override:	Modem control state override
+ * @gpiod_rts:		Pointer to the gpio descriptor
+ * @rs485_tx_started:	RS485 tx state
+ * @timer:		Timer for tx and rx
+ * @stop_tx_timer:	Timer for stop tx
  */
 struct cdns_uart {
 	struct uart_port	*port;
@@ -203,10 +209,22 @@ struct cdns_uart {
 	struct notifier_block	clk_rate_change_nb;
 	u32			quirks;
 	bool cts_override;
+	struct gpio_desc	*gpiod_rts;
+	bool			rs485_tx_started;
+	struct timer_list	timer;
+	struct timer_list	stop_tx_timer;
 };
 struct cdns_platform_data {
 	u32 quirks;
 };
+
+struct serial_rs485 cdns_rs485_supported = {
+	.flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND |
+		 SER_RS485_RTS_AFTER_SEND,
+	.delay_rts_before_send = 1,
+	.delay_rts_after_send = 1,
+};
+
 #define to_cdns_uart(_nb) container_of(_nb, struct cdns_uart, \
 		clk_rate_change_nb)
 
@@ -305,6 +323,55 @@ static void cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus)
 	tty_flip_buffer_push(&port->state->port);
 }
 
+/**
+ * cdns_rts_gpio_enable - Configure RTS/GPIO to high/low
+ * @cdns_uart: Handle to the cdns_uart
+ * @enable: Value to be set to RTS/GPIO
+ */
+static void cdns_rts_gpio_enable(struct cdns_uart *cdns_uart, bool enable)
+{
+	u32 val;
+
+	if (cdns_uart->gpiod_rts) {
+		gpiod_set_value(cdns_uart->gpiod_rts, enable);
+	} else {
+		val = readl(cdns_uart->port->membase + CDNS_UART_MODEMCR);
+		if (enable)
+			val &= ~CDNS_UART_MODEMCR_RTS;
+		else
+			val |= CDNS_UART_MODEMCR_RTS;
+		writel(val, cdns_uart->port->membase + CDNS_UART_MODEMCR);
+	}
+}
+
+/**
+ * cdns_rs485_tx_setup - Tx setup specific to rs485
+ * @cdns_uart: Handle to the cdns_uart
+ */
+static void cdns_rs485_tx_setup(struct cdns_uart *cdns_uart)
+{
+	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_ON_SEND)
+		cdns_rts_gpio_enable(cdns_uart, 1);
+	else
+		cdns_rts_gpio_enable(cdns_uart, 0);
+
+	cdns_uart->rs485_tx_started = true;
+}
+
+/**
+ * cdns_rs485_rx_setup - Rx setup specific to rs485
+ * @cdns_uart: Handle to the cdns_uart
+ */
+static void cdns_rs485_rx_setup(struct cdns_uart *cdns_uart)
+{
+	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_AFTER_SEND)
+		cdns_rts_gpio_enable(cdns_uart, 1);
+	else
+		cdns_rts_gpio_enable(cdns_uart, 0);
+
+	cdns_uart->rs485_tx_started = false;
+}
+
 /**
  * cdns_uart_tx_empty -  Check whether TX is empty
  * @port: Handle to the uart port structure
@@ -579,6 +646,42 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
 }
 #endif
 
+/**
+ * cdns_rs485_rx_callback - Timer rx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_rx_callback(struct timer_list *t)
+{
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
+
+	/*
+	 * Default Rx should be setup, because Rx signaling path
+	 * need to enable to receive data.
+	 */
+	cdns_rs485_rx_setup(cdns_uart);
+}
+
+/**
+ * cdns_rs485_tx_callback - Timer tx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_tx_callback(struct timer_list *t)
+{
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
+
+	cdns_uart_handle_tx(cdns_uart->port);
+
+	/* Enable the TX Empty interrupt */
+	writel(CDNS_UART_IXR_TXEMPTY, cdns_uart->port->membase + CDNS_UART_IER);
+
+	if (uart_circ_empty(&cdns_uart->port->state->xmit) ||
+	    uart_tx_stopped(cdns_uart->port)) {
+		timer_setup(&cdns_uart->timer, cdns_rs485_rx_callback, 0);
+		mod_timer(&cdns_uart->timer, jiffies +
+			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
+	}
+}
+
 /**
  * cdns_uart_start_tx -  Start transmitting bytes
  * @port: Handle to the uart port structure
@@ -586,6 +689,7 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
 static void cdns_uart_start_tx(struct uart_port *port)
 {
 	unsigned int status;
+	struct cdns_uart *cdns_uart = port->private_data;
 
 	if (uart_tx_stopped(port))
 		return;
@@ -604,10 +708,40 @@ static void cdns_uart_start_tx(struct uart_port *port)
 
 	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_ISR);
 
-	cdns_uart_handle_tx(port);
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		if (!cdns_uart->rs485_tx_started) {
+			timer_setup(&cdns_uart->timer,
+				    cdns_rs485_tx_callback, 0);
+			cdns_rs485_tx_setup(cdns_uart);
+			mod_timer(&cdns_uart->timer, jiffies +
+				  msecs_to_jiffies(port->rs485.delay_rts_before_send));
+		} else {
+			if (!timer_pending(&cdns_uart->timer))
+				mod_timer(&cdns_uart->timer, jiffies);
+		}
+	} else {
+		cdns_uart_handle_tx(port);
 
-	/* Enable the TX Empty interrupt */
-	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
+		/* Enable the TX Empty interrupt */
+		writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
+	}
+}
+
+/**
+ * cdns_rs485_stop_tx_callback - Timer stop tx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_stop_tx_callback(struct timer_list *t)
+{
+	unsigned int regval;
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, stop_tx_timer);
+
+	cdns_rs485_rx_setup(cdns_uart);
+
+	regval = readl(cdns_uart->port->membase + CDNS_UART_CR);
+	regval |= CDNS_UART_CR_TX_DIS;
+	/* Disable the transmitter */
+	writel(regval, cdns_uart->port->membase + CDNS_UART_CR);
 }
 
 /**
@@ -617,11 +751,19 @@ static void cdns_uart_start_tx(struct uart_port *port)
 static void cdns_uart_stop_tx(struct uart_port *port)
 {
 	unsigned int regval;
+	struct cdns_uart *cdns_uart = port->private_data;
 
-	regval = readl(port->membase + CDNS_UART_CR);
-	regval |= CDNS_UART_CR_TX_DIS;
-	/* Disable the transmitter */
-	writel(regval, port->membase + CDNS_UART_CR);
+	if ((cdns_uart->port->rs485.flags & SER_RS485_ENABLED) &&
+	    !timer_pending(&cdns_uart->stop_tx_timer) &&
+	    cdns_uart->rs485_tx_started) {
+		mod_timer(&cdns_uart->stop_tx_timer, jiffies +
+			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
+	} else {
+		regval = readl(port->membase + CDNS_UART_CR);
+		regval |= CDNS_UART_CR_TX_DIS;
+		/* Disable the transmitter */
+		writel(regval, port->membase + CDNS_UART_CR);
+	}
 }
 
 /**
@@ -829,6 +971,12 @@ static int cdns_uart_startup(struct uart_port *port)
 		(CDNS_UART_CR_TXRST | CDNS_UART_CR_RXRST))
 		cpu_relax();
 
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		timer_setup(&cdns_uart->stop_tx_timer,
+			    cdns_rs485_stop_tx_callback, 0);
+		cdns_rs485_rx_setup(cdns_uart);
+	}
+
 	/*
 	 * Clear the RX disable bit and then set the RX enable bit to enable
 	 * the receiver.
@@ -888,6 +1036,7 @@ static void cdns_uart_shutdown(struct uart_port *port)
 {
 	int status;
 	unsigned long flags;
+	struct cdns_uart *cdns_uart = port->private_data;
 
 	uart_port_lock_irqsave(port, &flags);
 
@@ -903,6 +1052,11 @@ static void cdns_uart_shutdown(struct uart_port *port)
 	uart_port_unlock_irqrestore(port, flags);
 
 	free_irq(port->irq, port);
+
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		del_timer_sync(&cdns_uart->timer);
+		del_timer_sync(&cdns_uart->stop_tx_timer);
+	}
 }
 
 /**
@@ -1032,7 +1186,7 @@ static void cdns_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
 	mode_reg &= ~CDNS_UART_MR_CHMODE_MASK;
 
 	if (mctrl & TIOCM_RTS)
-		val |= CDNS_UART_MODEMCR_RTS;
+		cdns_rts_gpio_enable(cdns_uart_data, 1);
 	if (mctrl & TIOCM_DTR)
 		val |= CDNS_UART_MODEMCR_DTR;
 	if (mctrl & TIOCM_LOOP)
@@ -1455,6 +1609,31 @@ MODULE_DEVICE_TABLE(of, cdns_uart_of_match);
 /* Temporary variable for storing number of instances */
 static int instances;
 
+/**
+ * cdns_rs485_config - Called when an application calls TIOCSRS485 ioctl.
+ * @port: Pointer to the uart_port structure
+ * @termios: Pointer to the ktermios structure
+ * @rs485: Pointer to the serial_rs485 structure
+ *
+ * Return: 0
+ */
+static int cdns_rs485_config(struct uart_port *port, struct ktermios *termios,
+			     struct serial_rs485 *rs485)
+{
+	u32 val;
+
+	if (rs485->flags & SER_RS485_ENABLED) {
+		dev_dbg(port->dev, "Setting UART to RS485\n");
+		/* Make sure auto RTS is disabled */
+		val = readl(port->membase + CDNS_UART_MODEMCR);
+		val &= ~CDNS_UART_MODEMCR_FCM;
+		writel(val, port->membase + CDNS_UART_MODEMCR);
+		/* Disable transmitter and make Rx setup*/
+		cdns_uart_stop_tx(port);
+	}
+	return 0;
+}
+
 /**
  * cdns_uart_probe - Platform driver probe
  * @pdev: Pointer to the platform device structure
@@ -1597,9 +1776,23 @@ static int cdns_uart_probe(struct platform_device *pdev)
 	port->private_data = cdns_uart_data;
 	port->read_status_mask = CDNS_UART_IXR_TXEMPTY | CDNS_UART_IXR_RXTRIG |
 			CDNS_UART_IXR_OVERRUN | CDNS_UART_IXR_TOUT;
+	port->rs485_config = cdns_rs485_config;
+	port->rs485_supported = cdns_rs485_supported;
 	cdns_uart_data->port = port;
 	platform_set_drvdata(pdev, port);
 
+	rc = uart_get_rs485_mode(port);
+	if (rc)
+		goto err_out_clk_notifier;
+
+	cdns_uart_data->gpiod_rts = devm_gpiod_get_optional(&pdev->dev, "rts",
+							    GPIOD_OUT_LOW);
+	if (IS_ERR(cdns_uart_data->gpiod_rts)) {
+		rc = PTR_ERR(cdns_uart_data->gpiod_rts);
+		dev_err(port->dev, "xuartps: devm_gpiod_get_optional failed\n");
+		goto err_out_clk_notifier;
+	}
+
 	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_set_autosuspend_delay(&pdev->dev, UART_AUTOSUSPEND_TIMEOUT);
 	pm_runtime_set_active(&pdev->dev);
@@ -1618,6 +1811,8 @@ static int cdns_uart_probe(struct platform_device *pdev)
 		console_port = port;
 	}
 #endif
+	if (cdns_uart_data->port->rs485.flags & SER_RS485_ENABLED)
+		cdns_rs485_rx_setup(cdns_uart_data);
 
 	rc = uart_add_one_port(&cdns_uart_uart_driver, port);
 	if (rc) {
@@ -1646,6 +1841,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
+err_out_clk_notifier:
 #ifdef CONFIG_COMMON_CLK
 	clk_notifier_unregister(cdns_uart_data->uartclk,
 			&cdns_uart_data->clk_rate_change_nb);
-- 
2.25.1



From nicolas.ferre at microchip.com  Wed Dec 13 05:01:30 2023
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Wed, 13 Dec 2023 14:01:30 +0100
Subject: [PATCH] power: reset: at91: mark at91_wakeup_status non-__init
In-Reply-To: <20231213072521.z7a37uayjide7ui4@pengutronix.de>
References: <20231212214658.213510-1-arnd@kernel.org>
 <20231212215002.GA3300655@dev-arch.thelio-3990X>
 <20231213072521.z7a37uayjide7ui4@pengutronix.de>
Message-ID: <d9b7c682-97f7-4a09-a534-9954865cfc29@microchip.com>

On 13/12/2023 at 08:25, Uwe Kleine-K?nig wrote:
> On Tue, Dec 12, 2023 at 02:50:02PM -0700, Nathan Chancellor wrote:
>> On Tue, Dec 12, 2023 at 10:46:49PM +0100, Arnd Bergmann wrote:
>>> From: Arnd Bergmann<arnd at arndb.de>
>>>
>>> Two copies of the at91_wakeup_status() function are called by the
>>> respective probe() callbacks and are marked __init, but the probe
>>> functions are no longer annotated that way. This works with gcc because
>>> the functions always get inlined, but clang keeps them separate, which
>>> can lead to executing freed memory:
>>>
>>> WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x80 (section: .text) -> at91_wakeup_status (section: .init.text)
>>> WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text)
>>>
>>> Drop the incorrect annotation on these.
>>>
>>> Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
>>> Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
>>> Signed-off-by: Arnd Bergmann<arnd at arndb.de>
>> Thanks, I sent the same change three weeks ago at this point:
>>
>> https://lore.kernel.org/20231120-fix-at91-modpost-warnings-v1-1-813671933863 at kernel.org/
>>
>> Your commit message is a little better than mine and I don't really care
>> which one goes in but it would be good if this could get cleared up
>> soon...
>>
>> Reviewed-by: Nathan Chancellor<nathan at kernel.org>
> I don't care either. Given the change is identical (Nathan's submission
> even has "index 126e774e210c..93eece027865 100644" which exactly matches
> Arnd's patch), I'll forward my Reviewed-by: tag to here:
> 
> Reviewed-by: Uwe Kleine-K?nig<u.kleine-koenig at pengutronix.de>

Likewise:
Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>

Use whichever is preferred.
Regards,
   Nicolas


From alexandru.elisei at arm.com  Wed Dec 13 05:04:56 2023
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed, 13 Dec 2023 13:04:56 +0000
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com>
 <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
 <ZXiMiLz9ZyUdxUP8@raptor>
 <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
Message-ID: <ZXmr-Kl9L2SO13--@raptor>

Hi Rob,

On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
> <alexandru.elisei at arm.com> wrote:
> >
> > Hi Rob,
> >
> > Thank you so much for the feedback, I'm not very familiar with device tree,
> > and any comments are very useful.
> >
> > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > > <alexandru.elisei at arm.com> wrote:
> > > >
> > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > regions from the DTB. This memory is marked as reserved for now.
> > > >
> > > > The DTB node for the tag storage region is defined as:
> > > >
> > > >         tags0: tag-storage at 8f8000000 {
> > > >                 compatible = "arm,mte-tag-storage";
> > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > >                 block-size = <0x1000>;
> > > >                 memory = <&memory0>;    // Associated tagged memory node
> > > >         };
> > >
> > > I skimmed thru the discussion some. If this memory range is within
> > > main RAM, then it definitely belongs in /reserved-memory.
> >
> > Ok, will do that.
> >
> > If you don't mind, why do you say that it definitely belongs in
> > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > motivation.
> 
> Simply so that /memory nodes describe all possible memory and
> /reserved-memory is just adding restrictions. It's also because
> /reserved-memory is what gets handled early, and we don't need
> multiple things to handle early.
> 
> > Tag storage is not DMA and can live anywhere in memory.
> 
> Then why put it in DT at all? The only reason CMA is there is to set
> the size. It's not even clear to me we need CMA in DT either. The
> reasoning long ago was the kernel didn't do a good job of moving and
> reclaiming contiguous space, but that's supposed to be better now (and
> most h/w figured out they need IOMMUs).
> 
> But for tag storage you know the size as it is a function of the
> memory size, right? After all, you are validating the size is correct.
> I guess there is still the aspect of whether you want enable MTE or
> not which could be done in a variety of ways.

Oh, sorry, my bad, I should have been clearer about this. I don't want to
put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.

> 
> > In
> > arm64_memblock_init(), the kernel first removes the memory that it cannot
> > address from memblock. For example, because it has been compiled with
> > CONFIG_ARM64_VA_BITS_39=y. And then calls
> > early_init_fdt_scan_reserved_mem().
> >
> > What happens if reserved memory is above what the kernel can address?
> 
> I would hope the kernel handles it. That's the kernel's problem unless
> there's some h/w limitation to access some region. The DT can't have
> things dependent on the kernel config.

I would hope so too, that's why I was surprised when I put reserved memory
at 1TB in a 39 bit VA kernel and got a panic.

> 
> > From my testing, when the kernel is compiled with 39 bit VA, if I use
> > reserved memory to discover tag storage the lives above the virtua address
> > limit and then I try to use CMA to manage the tag storage memory, I get a
> > kernel panic:
> 
> Looks like we should handle that better...

I guess we don't need to tackle that problem right now. I don't know of
many systems in the wild that have memory above the 1TB address.

> 
> >> [    0.000000] Reserved memory: created CMA memory pool at 0x0000010000000000, size 64 MiB
> > [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> > [    0.000000] OF: reserved mem: 0x0000010000000000..0x0000010003ffffff (65536 KiB) map reusable linux,cma
> > [..]
> > [    0.806945] Unable to handle kernel paging request at virtual address 00000001fe000000
> > [    0.807277] Mem abort info:
> > [    0.807277]   ESR = 0x0000000096000005
> > [    0.807693]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [    0.808110]   SET = 0, FnV = 0
> > [    0.808443]   EA = 0, S1PTW = 0
> > [    0.808526]   FSC = 0x05: level 1 translation fault
> > [    0.808943] Data abort info:
> > [    0.808943]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
> > [    0.809360]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> > [    0.809776]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > [    0.810221] [00000001fe000000] user address but active_mm is swapper
> > [..]
> > [    0.820887] Call trace:
> > [    0.821027]  cma_init_reserved_areas+0xc4/0x378
> >
> > >
> > > You need a binding for this too.
> >
> > By binding you mean having an yaml file in dt-schem [1] describing the tag
> > storage node, right?
> 
> Yes, but in the kernel tree is fine.

Cool, thanks.

> 
> [...]
> 
> > > > +static int __init tag_storage_of_flat_get_range(unsigned long node, const __be32 *reg,
> > > > +                                               int reg_len, struct range *range)
> > > > +{
> > > > +       int addr_cells = dt_root_addr_cells;
> > > > +       int size_cells = dt_root_size_cells;
> > > > +       u64 size;
> > > > +
> > > > +       if (reg_len / 4 > addr_cells + size_cells)
> > > > +               return -EINVAL;
> > > > +
> > > > +       range->start = PHYS_PFN(of_read_number(reg, addr_cells));
> > > > +       size = PHYS_PFN(of_read_number(reg + addr_cells, size_cells));
> > > > +       if (size == 0) {
> > > > +               pr_err("Invalid node");
> > > > +               return -EINVAL;
> > > > +       }
> > > > +       range->end = range->start + size - 1;
> > >
> > > We have a function to read (and translate which you forgot) addresses.
> > > Add what's missing rather than open code your own.
> >
> > I must have missed that there's already a function to read addresses. Would
> > you mind pointing me in the right direction?
> 
> drivers/of/fdt_address.c
> 
> Though it doesn't provide getting the size, so that will have to be added.

Ok, will do!

> 
> 
> > > > +
> > > > +       return 0;
> > > > +}
> > > > +
> > > > +static int __init tag_storage_of_flat_get_tag_range(unsigned long node,
> > > > +                                                   struct range *tag_range)
> > > > +{
> > > > +       const __be32 *reg;
> > > > +       int reg_len;
> > > > +
> > > > +       reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> > > > +       if (reg == NULL) {
> > > > +               pr_err("Invalid metadata node");
> > > > +               return -EINVAL;
> > > > +       }
> > > > +
> > > > +       return tag_storage_of_flat_get_range(node, reg, reg_len, tag_range);
> > > > +}
> > > > +
> > > > +static int __init tag_storage_of_flat_get_memory_range(unsigned long node, struct range *mem)
> > > > +{
> > > > +       const __be32 *reg;
> > > > +       int reg_len;
> > > > +
> > > > +       reg = of_get_flat_dt_prop(node, "linux,usable-memory", &reg_len);
> > > > +       if (reg == NULL)
> > > > +               reg = of_get_flat_dt_prop(node, "reg", &reg_len);
> > > > +
> > > > +       if (reg == NULL) {
> > > > +               pr_err("Invalid memory node");
> > > > +               return -EINVAL;
> > > > +       }
> > > > +
> > > > +       return tag_storage_of_flat_get_range(node, reg, reg_len, mem);
> > > > +}
> > > > +
> > > > +struct find_memory_node_arg {
> > > > +       unsigned long node;
> > > > +       u32 phandle;
> > > > +};
> > > > +
> > > > +static int __init fdt_find_memory_node(unsigned long node, const char *uname,
> > > > +                                      int depth, void *data)
> > > > +{
> > > > +       const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> > > > +       struct find_memory_node_arg *arg = data;
> > > > +
> > > > +       if (depth != 1 || !type || strcmp(type, "memory") != 0)
> > > > +               return 0;
> > > > +
> > > > +       if (of_get_flat_dt_phandle(node) == arg->phandle) {
> > > > +               arg->node = node;
> > > > +               return 1;
> > > > +       }
> > > > +
> > > > +       return 0;
> > > > +}
> > > > +
> > > > +static int __init tag_storage_get_memory_node(unsigned long tag_node, unsigned long *mem_node)
> > > > +{
> > > > +       struct find_memory_node_arg arg = { 0 };
> > > > +       const __be32 *memory_prop;
> > > > +       u32 mem_phandle;
> > > > +       int ret, reg_len;
> > > > +
> > > > +       memory_prop = of_get_flat_dt_prop(tag_node, "memory", &reg_len);
> > > > +       if (!memory_prop) {
> > > > +               pr_err("Missing 'memory' property in the tag storage node");
> > > > +               return -EINVAL;
> > > > +       }
> > > > +
> > > > +       mem_phandle = be32_to_cpup(memory_prop);
> > > > +       arg.phandle = mem_phandle;
> > > > +
> > > > +       ret = of_scan_flat_dt(fdt_find_memory_node, &arg);
> > >
> > > Do not use of_scan_flat_dt. It is a relic predating libfdt which can
> > > get a node by phandle directly.
> >
> > I used that because that's what drivers/of/fdt.c uses. With reserved memory
> > I shouldn't need it, because struct reserved_mem already includes a
> > phandle.
> 
> Check again. Only some arch/ code (mostly powerpc) uses it. I've
> killed off most of it.

You're right, I think I grep'ed for a different function name in
drivers/of/fdt.c Either way, the message is clear: no of_scan_flat_dt().

> 
> 
> > > > +       if (ret != 1) {
> > > > +               pr_err("Associated memory node not found");
> > > > +               return -EINVAL;
> > > > +       }
> > > > +
> > > > +       *mem_node = arg.node;
> > > > +
> > > > +       return 0;
> > > > +}
> > > > +
> > > > +static int __init tag_storage_of_flat_read_u32(unsigned long node, const char *propname,
> > > > +                                              u32 *retval)
> > >
> > > If you are going to make a generic function, make it for everyone.
> >
> > Sure. If I still need it, should I put the function in
> > include/linux/of_fdt.h?
> 
> Yes.

Noted.

> 
> > > > +{
> > > > +       const __be32 *reg;
> > > > +
> > > > +       reg = of_get_flat_dt_prop(node, propname, NULL);
> > > > +       if (!reg)
> > > > +               return -EINVAL;
> > > > +
> > > > +       *retval = be32_to_cpup(reg);
> > > > +       return 0;
> > > > +}
> > > > +
> > > > +static u32 __init get_block_size_pages(u32 block_size_bytes)
> > > > +{
> > > > +       u32 a = PAGE_SIZE;
> > > > +       u32 b = block_size_bytes;
> > > > +       u32 r;
> > > > +
> > > > +       /* Find greatest common divisor using the Euclidian algorithm. */
> > > > +       do {
> > > > +               r = a % b;
> > > > +               a = b;
> > > > +               b = r;
> > > > +       } while (b != 0);
> > > > +
> > > > +       return PHYS_PFN(PAGE_SIZE * block_size_bytes / a);
> > > > +}
> > > > +
> > > > +static int __init fdt_init_tag_storage(unsigned long node, const char *uname,
> > > > +                                      int depth, void *data)
> > > > +{
> > > > +       struct tag_region *region;
> > > > +       unsigned long mem_node;
> > > > +       struct range *mem_range;
> > > > +       struct range *tag_range;
> > > > +       u32 block_size_bytes;
> > > > +       u32 nid = 0;
> > > > +       int ret;
> > > > +
> > > > +       if (depth != 1 || !strstr(uname, "tag-storage"))
> > > > +               return 0;
> > > > +
> > > > +       if (!of_flat_dt_is_compatible(node, "arm,mte-tag-storage"))
> > > > +               return 0;
> > > > +
> > > > +       if (num_tag_regions == MAX_TAG_REGIONS) {
> > > > +               pr_err("Maximum number of tag storage regions exceeded");
> > > > +               return -EINVAL;
> > > > +       }
> > > > +
> > > > +       region = &tag_regions[num_tag_regions];
> > > > +       mem_range = &region->mem_range;
> > > > +       tag_range = &region->tag_range;
> > > > +
> > > > +       ret = tag_storage_of_flat_get_tag_range(node, tag_range);
> > > > +       if (ret) {
> > > > +               pr_err("Invalid tag storage node");
> > > > +               return ret;
> > > > +       }
> > > > +
> > > > +       ret = tag_storage_get_memory_node(node, &mem_node);
> > > > +       if (ret)
> > > > +               return ret;
> > > > +
> > > > +       ret = tag_storage_of_flat_get_memory_range(mem_node, mem_range);
> > > > +       if (ret) {
> > > > +               pr_err("Invalid address for associated data memory node");
> > > > +               return ret;
> > > > +       }
> > > > +
> > > > +       /* The tag region must exactly match the corresponding memory. */
> > > > +       if (range_len(tag_range) * 32 != range_len(mem_range)) {
> > > > +               pr_err("Tag storage region 0x%llx-0x%llx does not cover the memory region 0x%llx-0x%llx",
> > > > +                      PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->end),
> > > > +                      PFN_PHYS(mem_range->start), PFN_PHYS(mem_range->end));
> > > > +               return -EINVAL;
> > > > +       }
> > > > +
> > > > +       ret = tag_storage_of_flat_read_u32(node, "block-size", &block_size_bytes);
> > > > +       if (ret || block_size_bytes == 0) {
> > > > +               pr_err("Invalid or missing 'block-size' property");
> > > > +               return -EINVAL;
> > > > +       }
> > > > +       region->block_size = get_block_size_pages(block_size_bytes);
> > > > +       if (range_len(tag_range) % region->block_size != 0) {
> > > > +               pr_err("Tag storage region size 0x%llx is not a multiple of block size %u",
> > > > +                      PFN_PHYS(range_len(tag_range)), region->block_size);
> > > > +               return -EINVAL;
> > > > +       }
> > > > +
> > > > +       ret = tag_storage_of_flat_read_u32(mem_node, "numa-node-id", &nid);
> > >
> > > I was going to say we already have a way to associate memory nodes
> > > other nodes using "numa-node-id", so the "memory" phandle property is
> > > somewhat redundant. Maybe the tag node should have a numa-node-id.
> > > With that, it looks like you don't even need to access the /memory
> > > node. Avoiding that would be good for 2 reasons. It avoids parsing
> > > memory nodes twice and it's not the kernel's job to validate the DT.
> > > Really, if you want memory info, you should use memblock to get it
> > > because all the special cases of memory layout are handled. For
> > > example you can have memory nodes with multiple 'reg' entries or
> > > multiple memory nodes or both, and then some of those could be
> > > contiguous.
> >
> > I need to have a memory node associated with the tag storage node because
> > there is a static relationship between a page from "normal" memory and its
> > associated tag storage. If the code doesn't know that the memory region
> > A..B has the corresponding tag storage in the region X..Y, then it doesn't
> > know which tag storage to reserve when a page is allocated as tagged.
> >
> > In the example above, assuming that page P is allocated as tagged, the
> > corresponding tag storage page that needs to be reserved is:
> >
> > tag_storage_pfn = (page_to_pfn(P) - PHYS_PFN(A)) / 32* + PHYS_PFN(X)
> >
> > numa-node-id is not enough for this, because as far I know you can have
> > multiple memory regions withing the same numa node.
> 
> Okay.

Great, glad we are on the same page.

Thanks,
Alex


From fancer.lancer at gmail.com  Wed Dec 13 05:09:12 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Wed, 13 Dec 2023 16:09:12 +0300
Subject: [PATCH net v2] net: stmmac: Handle disabled MDIO busses from
 devicetree
In-Reply-To: <20231212-b4-stmmac-handle-mdio-enodev-v2-1-600171acf79f@redhat.com>
References: <20231212-b4-stmmac-handle-mdio-enodev-v2-1-600171acf79f@redhat.com>
Message-ID: <f2pf2g23ln4qcoqxidy55plysn735qtfspj6nuu6f7isqxotp2@rj6ejru5eon7>

On Tue, Dec 12, 2023 at 04:18:33PM -0600, Andrew Halaney wrote:
> Many hardware configurations have the MDIO bus disabled, and are instead
> using some other MDIO bus to talk to the MAC's phy.
> 
> of_mdiobus_register() returns -ENODEV in this case. Let's handle it
> gracefully instead of failing to probe the MAC.
> 
> Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.")
> Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
> ---
> Changes in v2:
> - Improve error handling code (Serge)
> - Fix malformed Fixes tag (Simon)
> - Link to v1: https://lore.kernel.org/r/20231211-b4-stmmac-handle-mdio-enodev-v1-1-73c20c44f8d6 at redhat.com

Looking good. Thanks!
Reviewed-by: Serge Semin <fancer.lancer at gmail.com>

-Serge(y)

> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> index fa9e7e7040b9..0542cfd1817e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
> @@ -591,7 +591,11 @@ int stmmac_mdio_register(struct net_device *ndev)
>  	new_bus->parent = priv->device;
>  
>  	err = of_mdiobus_register(new_bus, mdio_node);
> -	if (err != 0) {
> +	if (err == -ENODEV) {
> +		err = 0;
> +		dev_info(dev, "MDIO bus is disabled\n");
> +		goto bus_register_fail;
> +	} else if (err) {
>  		dev_err_probe(dev, err, "Cannot register the MDIO bus\n");
>  		goto bus_register_fail;
>  	}
> 
> ---
> base-commit: bbd220ce4e29ed55ab079007cff0b550895258eb
> change-id: 20231211-b4-stmmac-handle-mdio-enodev-82168de68c6a
> 
> Best regards,
> -- 
> Andrew Halaney <ahalaney at redhat.com>
> 


From twoerner at gmail.com  Wed Dec 13 05:17:38 2023
From: twoerner at gmail.com (Trevor Woerner)
Date: Wed, 13 Dec 2023 08:17:38 -0500
Subject: [PATCH] amd64: rockchip: dts: rk3328-rock-pi-e add gpio-line-names
Message-ID: <20231213131739.13900-1-twoerner@gmail.com>

Add names to the pins of the general-purpose expansion header as given
in the Radxa GPIO page[1] following the conventions in the kernel
documentation[2] to make it easier for users to correlate the pins with
functions when using utilities such as 'gpioinfo'.

[1] https://wiki.radxa.com/RockpiE/hardware/gpio
[2] Documentation/devicetree/bindings/gpio/gpio.txt

Signed-off-by: Trevor Woerner <twoerner at gmail.com>
---
 .../boot/dts/rockchip/rk3328-rock-pi-e.dts    | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
index 018a3a5075c7..3169c0854061 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -388,3 +388,56 @@ &usbdrd3 {
 &usb_host0_ehci {
 	status = "okay";
 };
+
+&gpio0 {
+	gpio-line-names =
+	/* GPIO0_A0 - A7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO0_B0 - B7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO0_C0 - C7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO0_D0 - D7 */
+	"", "", "", "pin-15 [GPIO0_D3]", "", "", "", "";
+};
+
+&gpio1 {
+	gpio-line-names =
+	/* GPIO1_A0 - A7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO1_B0 - B7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO1_C0 - C7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO1_D0 - D7 */
+	"", "", "", "", "pin-07 [GPIO1_D4]", "", "", "";
+};
+
+&gpio2 {
+	gpio-line-names =
+	/* GPIO2_A0 - A7 */
+	"pin-08 [GPIO2_A0]", "pin-10 [GPIO2_A1]", "pin-11 [GPIO2_A2]",
+	"pin-13 [GPIO2-A3]", "pin-27 [GPIO2_A4]", "pin-28 [GPIO2_A5]",
+	"pin-33 [GPIO2_A6]", "",
+	/* GPIO2_B0 - B7 */
+	"", "", "", "", "pin-26 [GPIO2_B4]", "", "", "pin-36 [GPIO2_B7]",
+	/* GPIO2_C0 - C7 */
+	"pin-32 [GPIO2_C0]", "pin-35 [GPIO2_C1]", "pin-12 [GPIO2_C2]",
+	"pin-38 [GPIO2_C3]", "pin-29 [GPIO2_C4]", "pin-31 [GPIO2_C5]",
+	"pin-37 [GPIO2_C6]", "pin-40 [GPIO2_C7]",
+	/* GPIO2_D0 - D7 */
+	"", "", "", "", "", "", "", "";
+};
+
+&gpio3 {
+	gpio-line-names =
+	/* GPIO3_A0 - A7 */
+	"pin-23 [GPIO3_A0]", "pin-19 [GPIO3_A1]", "pin-21 [GPIO3_A2]",
+	"", "pin-03 [GPIO3_A4]", "", "pin-05 [GPIO3_A6]", "",
+	/* GPIO3_B0 - B7 */
+	"pin-24 [GPIO3_B0]", "", "", "", "", "", "", "",
+	/* GPIO3_C0 - C7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO3_D0 - D7 */
+	"", "", "", "", "", "", "", "";
+};
-- 
2.41.0.327.gaa9166bcc0ba



From andrew at lunn.ch  Wed Dec 13 05:20:45 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 13 Dec 2023 14:20:45 +0100
Subject: [RFC PATCH net-next v3 1/8] dt-bindings: phy:
 mediatek,xfi-pextp: add new bindings
In-Reply-To: <ZXiNhSYDbowUiNvy@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel@makrotopia.org>
 <20231212-renderer-strobe-2b46652cd6e7@spud>
 <ZXiNhSYDbowUiNvy@makrotopia.org>
Message-ID: <c9605d38-e4b8-477d-84d8-de7b4dedd1f1@lunn.ch>

> Because it is only present in one of the two SerDes channels.
> Channel 0 needs the work-around, Channel 1 doesn't.

Does the channel know its own number?

     Andrew


From andriy.shevchenko at linux.intel.com  Wed Dec 13 05:21:55 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Wed, 13 Dec 2023 15:21:55 +0200
Subject: [PATCH v5 03/13] pinctrl: ingenic: Use C99 initializers in
 PINCTRL_PIN_GROUP()
In-Reply-To: <fb29c3bca8d245e3f7496539b7293aa4fc4bccd0.camel@crapouillou.net>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
 <20231211190321.307330-4-andriy.shevchenko@linux.intel.com>
 <fb29c3bca8d245e3f7496539b7293aa4fc4bccd0.camel@crapouillou.net>
Message-ID: <ZXmv81bJRMqB1GLY@smile.fi.intel.com>

On Wed, Dec 13, 2023 at 10:55:46AM +0100, Paul Cercueil wrote:
> Le lundi 11 d?cembre 2023 ? 20:57 +0200, Andy Shevchenko a ?crit?:

...

> > -#define INGENIC_PIN_GROUP(name, id, func)		\
> > -	INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
> > +#define INGENIC_PIN_GROUP(_name_, id,
> > func)						\
> > +	{							
> > 			\
> > +		.name =
> > _name_,								\
> > +		.pins =
> > id##_pins,							\
> > +		.num_pins =
> > ARRAY_SIZE(id##_pins),					\
> > +		.data = (void
> > *)func,							\
> > +	}
> 
> This INGENIC_PIN_GROUP() macro doesn't need to be modified, does it?

We can go either way. I prefer to go this way as it reduces level of
indirections in the macros. It makes code easier to read and understand.
But if you insist, I can drop that change in next version.

-- 
With Best Regards,
Andy Shevchenko




From joakim.bech at linaro.org  Wed Dec 13 05:22:29 2023
From: joakim.bech at linaro.org (Joakim Bech)
Date: Wed, 13 Dec 2023 14:22:29 +0100
Subject: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
In-Reply-To: <20231213133825.0a329864@eldfell>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
 <DPBmATfmfvSP8Cwjz99kj_JvCEiAqRfuMFJZEBF2aIgl8NZqWFR66eyPTX1E8bHyOlimBihEE3E80p9bfOJ-0SNu8pwoIzL9gD2Xae6r97g=@emersion.fr>
 <20231213110517.6ce36aca@eldfell>
 <20231213101549.lioqfzjxcvmqxqu3@pop-os.localdomain>
 <20231213133825.0a329864@eldfell>
Message-ID: <20231213132229.q3uxdhtdsxuzw3w6@pop-os.localdomain>

On Wed, Dec 13, 2023 at 01:38:25PM +0200, Pekka Paalanen wrote:
> On Wed, 13 Dec 2023 11:15:49 +0100
> Joakim Bech <joakim.bech at linaro.org> wrote:
> 
> > On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
> > > On Tue, 12 Dec 2023 16:36:35 +0000
> > > Simon Ser <contact at emersion.fr> wrote:
> > >   
> > > > Is there a chance to pick a better name than "secure" here?
> > > > 
> > > > "Secure" is super overloaded, it's not clear at all what it means from
> > > > just the name. Something like "restricted" would be an improvement.
> > > >   
> > > 
> > > My thoughts exactly. Every time I see "secure" used for something that
> > > either gives you garbage, refuses to work, or crashes your whole machine
> > > *intentionally* when you try to do normal usual things to it in
> > > userspace (like use it for GL texturing, or try to use KMS writeback), I
> > > get an unscratchable itch.
> > > 
> > > There is nothing "secure" from security perspective there for end users
> > > and developers. It's just inaccessible buffers.
> > > 
> > > I've been biting my lip until now, thinking it's too late.
> > >   
> > The characteristics we're looking for here is a buffer where the content
> > is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
> > EL2. I.e, the content of the buffer is meant to be used and accessible
> > primarily by the secure side and other devices that has been granted
> 
> s/secure side/proprietary side/
> 
I'm using the nomenclature as written by Arm (other architectures have
other names for their secure execution states).

> I presume nothing of the other side can ever be in any way open?
> 
I'm sure there are lots of examples of things running on the secure side
that are open. The OP-TEE project where I'm a maintainer has been fully
open source since 2014, to give one example that I'm familiar with
myself.

> Maybe the other side is even less secure than the FOSS side...
> 
> > access to it (for example decoders, display controllers if we're talking
> > about video use cases). However, since the use cases for this exercises
> > the whole stack, from non-secure user space (EL0) all the way to secure
> > user space (S-EL0), with various devices needing access to the buffer at
> > various times, it makes sense to let Linux manage the buffers, although
> > it still cannot access the content. That's the overall context.
> 
> Yes, we know all this (except for the exact meaning of EL0 etc.).
> 
Great!

> > As for the name, it's always difficult to find a name suitable precisely
> > describing what it is. "Secure" is perhaps vague, but it might still a
> > good choice, if you carefully describe what secure means for this
> > particular heap (in the source code and the documentation for it). For
> 
> Carefully describe, as in, re-define.
> 
> > example, the definition of "secure" for a secure heap as here could mean
> > that buffer content is inaccessible to the host OS and user space
> > running in normal world (using Arm nomenclature). I wouldn't have any
> > problems with calling it secure if, as said it's defined what we mean by
> > saying so. But I'm all ears for other suggestions as well.
> > 
> > Safe, protected, shielded, unreachable, isolated, inaccessible,
> > unaccessible, fortified, ... would any of these make more sense?
> 
> "Restricted" sounds like a good compromise to me. The buffers' usage is
> severely restricted.
> 
Yes, restricted isn't a bad choice. We would still need to describe what
we mean by saying it's restricted, i.e., what is it restricted from,
since I'd guess that "restricted" by itself also could be a bit open
ended for a lot of people.

> It is the opposite of "safe", because accessing the contents the wrong
> way can return garbage or intentionally crash the whole system,
> depending on the hardware implementation. One example is attempting to
> put such a buffer on a KMS plane while the connector HDCP state is not
> high enough, or a writeback connector is connected to the CRTC. It is
> really fragile. (Do KMS drivers fail an atomic commit that would
> violate the heap rules? Somehow I doubt that, who'd even know what the
> rules are.)
> 
I believe one of the goals with reviewing the patches is to highlight
issues like this and try to figure out how to avoid ending up in
situations like what you described by suggesting alternative solutions
and ideas.

> It is protected/shielded/fortified from all the kernel and userspace,
> but a more familiar word to describe that is inaccessible.
> "Inaccessible buffer" per se OTOH sounds like a useless concept.
> 
> It is not secure, because it does not involve security in any way. In
> fact, given it's so fragile, I'd classify it as mildly opposite of
> secure, as e.g. clients of a Wayland compositor can potentially DoS the
> compositor with it by simply sending such a dmabuf. Or DoS the whole
> system.
> 
I hear what you are saying and DoS is a known problem and attack vector,
but regardless, we have use cases where we don't want to expose
information in the clear and where we also would like to have some
guarantees about correctness. That is where various secure elements and
more generally security is needed.

So, it sounds like we have two things here, the first is the naming and
the meaning behind it. I'm pretty sure the people following and
contributing to this thread can agree on a name that makes sense. Would
you personally be OK with "restricted" as the name? It sounds like that.

The other thing is the feature and functionality itself offered by this
patch series. My impression from reading your replies is that you think
this is the wrong approach. If my impression is correct, what would you
suggest as an alternative approach?

> "Poisonous heap" would be fitting but politically inappropriate I
> guess. After all, "poison" is data that is not meant to be read by
> anything normal.
> 
> 
> Thanks,
> pq

-- 
// Regards
Joakim


From andrew at lunn.ch  Wed Dec 13 05:26:42 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 13 Dec 2023 14:26:42 +0100
Subject: [PATCH v2 2/3] arm64: dts: ti: k3-am642-evm: add ICSSG1 Ethernet
 support
In-Reply-To: <20231212165832.3933335-3-danishanwar@ti.com>
References: <20231212165832.3933335-1-danishanwar@ti.com>
 <20231212165832.3933335-3-danishanwar@ti.com>
Message-ID: <1a2aba0c-5c4d-4258-b89c-b1be4593d7ff@lunn.ch>

On Tue, Dec 12, 2023 at 10:28:31PM +0530, MD Danish Anwar wrote:
> ICSSG1 provides dual Gigabit Ethernet support with proper FW loaded.
> 
> The ICSSG1 MII0 (RGMII1) has DP83869 PHY attached to it. The ICSSG1 shares
> MII1 (RGMII2) PHY DP83869 with CPSW3g and it's assigned by default to
> CPSW3g. The MDIO access to MII1 (RGMII2) PHY DP83869 is controlled by MDIO
> bus switch and also assigned to CPSW3g. Therefore the ICSSG1 MII1 (RGMII2)
> port is kept disable and ICSSG1 is enabled in single MAC mode by
> default.

FYI

I want to review all this MII muxing, but it won't be today.

  Andrew


From will at kernel.org  Wed Dec 13 05:26:52 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 13:26:52 +0000
Subject: [PATCH v2 2/5] iommu/arm-smmu: Convert to a global static
 identity domain
In-Reply-To: <20231212141516.GE3014157@nvidia.com>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <2-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <20231212132708.GB29569@willie-the-truck>
 <20231212141516.GE3014157@nvidia.com>
Message-ID: <20231213132651.GB31729@willie-the-truck>

On Tue, Dec 12, 2023 at 10:15:16AM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 12, 2023 at 01:27:08PM +0000, Will Deacon wrote:
> > > +static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
> > > +					struct device *dev)
> > > +{
> > > +	struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
> > > +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > > +	struct arm_smmu_device *smmu;
> > > +	int ret;
> > > +
> > > +	if (!cfg)
> > > +		return -ENODEV;
> > > +	smmu = cfg->smmu;
> > > +
> > > +	ret = arm_smmu_rpm_get(smmu);
> > > +	if (ret < 0)
> > > +		return ret;
> > > +
> > > +	arm_smmu_master_install_s2crs(cfg, S2CR_TYPE_BYPASS, 0, fwspec);
> > > +
> > > +	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
> > > +	pm_runtime_use_autosuspend(smmu->dev);
> > 
> > This is cargo-culted from arm_smmu_attach_dev() with the comments dropped
> > and it's not clear at all to me that the autosuspend delay makes any sense
> > for the identity domain.
> 
> Indeed, however it was how it worked before this split up.

Yeah, and I suppose given that I certainly don't have an easy way to test
this, there's a lot to be said for preserving the current behaviour.

> > So I think it would be better to either drop the call to
> > pm_runtime_set_autosuspend_delay() 
> 
> I looked through it more carefully and this does seem like the right
> thing, so I will drop them.

In the interests of getting this queued, I've gone ahead and stuck 'em
in a helper. We can drop the call later, but it would be good to either
test that or get confirmation from Rob that it doesn't break anything
first.

Will

--->8

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index dde912f8ef35..dec912c27141 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -82,6 +82,23 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
 		pm_runtime_put_autosuspend(smmu->dev);
 }
 
+static void arm_smmu_rpm_use_autosuspend(struct arm_smmu_device *smmu)
+{
+	/*
+	 * Setup an autosuspend delay to avoid bouncing runpm state.
+	 * Otherwise, if a driver for a suspended consumer device
+	 * unmaps buffers, it will runpm resume/suspend for each one.
+	 *
+	 * For example, when used by a GPU device, when an application
+	 * or game exits, it can trigger unmapping 100s or 1000s of
+	 * buffers.  With a runpm cycle for each buffer, that adds up
+	 * to 5-10sec worth of reprogramming the context bank, while
+	 * the system appears to be locked up to the user.
+	 */
+	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
+	pm_runtime_use_autosuspend(smmu->dev);
+}
+
 static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
 {
 	return container_of(dom, struct arm_smmu_domain, domain);
@@ -1141,21 +1158,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	/* Looks ok, so add the device to the domain */
 	arm_smmu_master_install_s2crs(cfg, S2CR_TYPE_TRANS,
 				      smmu_domain->cfg.cbndx, fwspec);
-
-	/*
-	 * Setup an autosuspend delay to avoid bouncing runpm state.
-	 * Otherwise, if a driver for a suspended consumer device
-	 * unmaps buffers, it will runpm resume/suspend for each one.
-	 *
-	 * For example, when used by a GPU device, when an application
-	 * or game exits, it can trigger unmapping 100s or 1000s of
-	 * buffers.  With a runpm cycle for each buffer, that adds up
-	 * to 5-10sec worth of reprogramming the context bank, while
-	 * the system appears to be locked up to the user.
-	 */
-	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
-	pm_runtime_use_autosuspend(smmu->dev);
-
+	arm_smmu_rpm_use_autosuspend(smmu);
 rpm_put:
 	arm_smmu_rpm_put(smmu);
 	return ret;
@@ -1178,9 +1181,7 @@ static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
 		return ret;
 
 	arm_smmu_master_install_s2crs(cfg, S2CR_TYPE_BYPASS, 0, fwspec);
-
-	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
-	pm_runtime_use_autosuspend(smmu->dev);
+	arm_smmu_rpm_use_autosuspend(smmu);
 	arm_smmu_rpm_put(smmu);
 	return 0;
 }


From will at kernel.org  Wed Dec 13 05:27:01 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 13:27:01 +0000
Subject: [PATCH v2 5/5] iommu/arm-smmu: Convert to domain_alloc_paging()
In-Reply-To: <20231212141023.GA29699@willie-the-truck>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <5-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <20231212132651.GA29569@willie-the-truck>
 <20231212140307.GD3014157@nvidia.com>
 <20231212141023.GA29699@willie-the-truck>
Message-ID: <20231213132700.GC31729@willie-the-truck>

On Tue, Dec 12, 2023 at 02:10:23PM +0000, Will Deacon wrote:
> On Tue, Dec 12, 2023 at 10:03:07AM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 12, 2023 at 01:26:51PM +0000, Will Deacon wrote:
> > > Why do we need to handle the 'dev && !cfg' case here, instead g
> > > returning NULL?
> > 
> > dev && !cfg is impossible these days, so we can shuffle the if and
> > then just crash on that case like the other drivers do.
> 
> Thanks, that would simplify it a little.

Folded in the diff below.

Will

--->8

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 536e47e3a65a..b0a6b367d8a2 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -861,7 +861,6 @@ static void arm_smmu_destroy_domain_context(struct arm_smmu_domain *smmu_domain)
 
 static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
 {
-	struct arm_smmu_master_cfg *cfg = NULL;
 	struct arm_smmu_domain *smmu_domain;
 
 	/*
@@ -876,13 +875,10 @@ static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
 	mutex_init(&smmu_domain->init_mutex);
 	spin_lock_init(&smmu_domain->cb_lock);
 
-	if (dev)
-		cfg = dev_iommu_priv_get(dev);
-	if (cfg) {
-		int ret;
+	if (dev) {
+		struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
 
-		ret = arm_smmu_init_domain_context(smmu_domain, cfg->smmu, dev);
-		if (ret) {
+		if (arm_smmu_init_domain_context(smmu_domain, cfg->smmu, dev)) {
 			kfree(smmu_domain);
 			return NULL;
 		}


From jgg at nvidia.com  Wed Dec 13 05:32:36 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 13 Dec 2023 09:32:36 -0400
Subject: [PATCH v2 2/5] iommu/arm-smmu: Convert to a global static
 identity domain
In-Reply-To: <20231213132651.GB31729@willie-the-truck>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <2-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <20231212132708.GB29569@willie-the-truck>
 <20231212141516.GE3014157@nvidia.com>
 <20231213132651.GB31729@willie-the-truck>
Message-ID: <20231213133236.GA3259566@nvidia.com>

On Wed, Dec 13, 2023 at 01:26:52PM +0000, Will Deacon wrote:
> On Tue, Dec 12, 2023 at 10:15:16AM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 12, 2023 at 01:27:08PM +0000, Will Deacon wrote:
> > > > +static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
> > > > +					struct device *dev)
> > > > +{
> > > > +	struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
> > > > +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > > > +	struct arm_smmu_device *smmu;
> > > > +	int ret;
> > > > +
> > > > +	if (!cfg)
> > > > +		return -ENODEV;
> > > > +	smmu = cfg->smmu;
> > > > +
> > > > +	ret = arm_smmu_rpm_get(smmu);
> > > > +	if (ret < 0)
> > > > +		return ret;
> > > > +
> > > > +	arm_smmu_master_install_s2crs(cfg, S2CR_TYPE_BYPASS, 0, fwspec);
> > > > +
> > > > +	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
> > > > +	pm_runtime_use_autosuspend(smmu->dev);
> > > 
> > > This is cargo-culted from arm_smmu_attach_dev() with the comments dropped
> > > and it's not clear at all to me that the autosuspend delay makes any sense
> > > for the identity domain.
> > 
> > Indeed, however it was how it worked before this split up.
> 
> Yeah, and I suppose given that I certainly don't have an easy way to test
> this, there's a lot to be said for preserving the current behaviour.

Right, it is why I did it..

> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index dde912f8ef35..dec912c27141 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -82,6 +82,23 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
>  		pm_runtime_put_autosuspend(smmu->dev);
>  }
>  
> +static void arm_smmu_rpm_use_autosuspend(struct arm_smmu_device *smmu)
> +{
> +	/*
> +	 * Setup an autosuspend delay to avoid bouncing runpm state.
> +	 * Otherwise, if a driver for a suspended consumer device
> +	 * unmaps buffers, it will runpm resume/suspend for each one.
> +	 *
> +	 * For example, when used by a GPU device, when an application
> +	 * or game exits, it can trigger unmapping 100s or 1000s of
> +	 * buffers.  With a runpm cycle for each buffer, that adds up
> +	 * to 5-10sec worth of reprogramming the context bank, while
> +	 * the system appears to be locked up to the user.
> +	 */
> +	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
> +	pm_runtime_use_autosuspend(smmu->dev);
> +}
> +
>  static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
>  {
>  	return container_of(dom, struct arm_smmu_domain, domain);
> @@ -1141,21 +1158,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
>  	/* Looks ok, so add the device to the domain */
>  	arm_smmu_master_install_s2crs(cfg, S2CR_TYPE_TRANS,
>  				      smmu_domain->cfg.cbndx, fwspec);
> -
> -	/*
> -	 * Setup an autosuspend delay to avoid bouncing runpm state.
> -	 * Otherwise, if a driver for a suspended consumer device
> -	 * unmaps buffers, it will runpm resume/suspend for each one.
> -	 *
> -	 * For example, when used by a GPU device, when an application
> -	 * or game exits, it can trigger unmapping 100s or 1000s of
> -	 * buffers.  With a runpm cycle for each buffer, that adds up
> -	 * to 5-10sec worth of reprogramming the context bank, while
> -	 * the system appears to be locked up to the user.
> -	 */
> -	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
> -	pm_runtime_use_autosuspend(smmu->dev);
> -
> +	arm_smmu_rpm_use_autosuspend(smmu);
>  rpm_put:
>  	arm_smmu_rpm_put(smmu);
>  	return ret;
> @@ -1178,9 +1181,7 @@ static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
>  		return ret;
>  
>  	arm_smmu_master_install_s2crs(cfg, S2CR_TYPE_BYPASS, 0, fwspec);
> -
> -	pm_runtime_set_autosuspend_delay(smmu->dev, 20);
> -	pm_runtime_use_autosuspend(smmu->dev);
> +	arm_smmu_rpm_use_autosuspend(smmu);
>  	arm_smmu_rpm_put(smmu);
>  	return 0;
>  }

Looks good, thanks

Jason


From jgg at nvidia.com  Wed Dec 13 05:32:51 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 13 Dec 2023 09:32:51 -0400
Subject: [PATCH v2 5/5] iommu/arm-smmu: Convert to domain_alloc_paging()
In-Reply-To: <20231213132700.GC31729@willie-the-truck>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <5-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
 <20231212132651.GA29569@willie-the-truck>
 <20231212140307.GD3014157@nvidia.com>
 <20231212141023.GA29699@willie-the-truck>
 <20231213132700.GC31729@willie-the-truck>
Message-ID: <20231213133251.GB3259566@nvidia.com>

On Wed, Dec 13, 2023 at 01:27:01PM +0000, Will Deacon wrote:
> On Tue, Dec 12, 2023 at 02:10:23PM +0000, Will Deacon wrote:
> > On Tue, Dec 12, 2023 at 10:03:07AM -0400, Jason Gunthorpe wrote:
> > > On Tue, Dec 12, 2023 at 01:26:51PM +0000, Will Deacon wrote:
> > > > Why do we need to handle the 'dev && !cfg' case here, instead g
> > > > returning NULL?
> > > 
> > > dev && !cfg is impossible these days, so we can shuffle the if and
> > > then just crash on that case like the other drivers do.
> > 
> > Thanks, that would simplify it a little.
> 
> Folded in the diff below.
> 
> Will
> 
> --->8
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 536e47e3a65a..b0a6b367d8a2 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -861,7 +861,6 @@ static void arm_smmu_destroy_domain_context(struct arm_smmu_domain *smmu_domain)
>  
>  static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
>  {
> -	struct arm_smmu_master_cfg *cfg = NULL;
>  	struct arm_smmu_domain *smmu_domain;
>  
>  	/*
> @@ -876,13 +875,10 @@ static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
>  	mutex_init(&smmu_domain->init_mutex);
>  	spin_lock_init(&smmu_domain->cb_lock);
>  
> -	if (dev)
> -		cfg = dev_iommu_priv_get(dev);
> -	if (cfg) {
> -		int ret;
> +	if (dev) {
> +		struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
>  
> -		ret = arm_smmu_init_domain_context(smmu_domain, cfg->smmu, dev);
> -		if (ret) {
> +		if (arm_smmu_init_domain_context(smmu_domain, cfg->smmu, dev)) {
>  			kfree(smmu_domain);
>  			return NULL;
>  		}

Looks good, thanks

Jason


From leo.yan at linaro.org  Wed Dec 13 05:33:36 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Wed, 13 Dec 2023 21:33:36 +0800
Subject: [PATCH V2 3/5] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <3b67c2de-741d-4d5e-8c8f-87b8b9e08825@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-4-kan.liang@linux.intel.com>
 <20231209054809.GB2116834@leoy-yangtze.lan>
 <3b67c2de-741d-4d5e-8c8f-87b8b9e08825@linux.intel.com>
Message-ID: <20231213133336.GA3895246@leoy-yangtze.lan>

On Mon, Dec 11, 2023 at 01:39:36PM -0500, Liang, Kan wrote:
> On 2023-12-09 12:48 a.m., Leo Yan wrote:
> > On Thu, Dec 07, 2023 at 11:23:36AM -0800, kan.liang at linux.intel.com wrote:
> >> From: Kan Liang <kan.liang at linux.intel.com>
> >>
> >> Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
> >> one.
> > 
> > Now memory event naming is arch dependent, this is because every arch
> > has different memory PMU names, and it appends specific configurations
> > (e.g. aarch64 appends 'ts_enable=1,...,min_latency=%u', and x86_64
> > appends 'ldlat=%u', etc).  This is not friendly for extension, e.g. it's
> > impossible for users to specify any extra attributes for memory events.
> > 
> > This patch tries to consolidate in a central place for generating memory
> > event names, its approach is to add more flags to meet special usage
> > cases, which means the code gets more complex (and more difficult for
> > later's maintenance).
> > 
> > I think we need to distinguish the event naming into two levels: in
> > util/mem-events.c, we can consider it as a common layer, and we maintain
> > common options in it, e.g. 'latency', 'all-user', 'all-kernel',
> > 'timestamp', 'physical_address', etc.  In every arch's mem-events.c
> > file, it converts the common options to arch specific configurations.
> > 
> > In the end, this can avoid to add more and more flags into the
> > structure perf_mem_event.
> 
> The purpose of this cleanup patch set is to remove the unnecessary
> __weak functions, and try to make the code more generic.

I understand weak functions are not very good practice.  The point is
weak functions are used for some archs have implemented a feature but
other archs have not.

I can think a potential case to use a central place to maintain the
code for all archs - when we want to support cross analysis.  But this
patch series is for supporting cross analysis, to be honest, I still
don't see benefit for this series, though I know you might try to
support hybrid modes.

> The two flags has already covered all the current usage.
> For now, it's good enough.
> 
> I agree that if there are more flags, it should not be a perfect
> solution. But we don't have the third flag right now. Could we clean up
> it later e.g., when introducing the third flag?
> 
> I just don't want to make the patch bigger and bigger. Also, I don't
> think we usually implement something just for future possibilities.

Fine for me, but please address two main concerns in next spin:

- Fix building failure in patch 01;
- Fix the concerned regression on Arm64/AMD archs in patch 04.  I will
  give a bit more explanation in another reply.


[...]

> >> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
> >> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
> >>  
> >>  struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
> >> -	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
> >> -	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
> >> -	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
> >> +	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0",	true,	0),
> >> +	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0",	false,	0),
> >> +	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0",	true,	0),
> > 
> > Arm SPE is AUX event, should set '1' to the field '.aux_event'.
> 
> It actually means whether an extra event is required with a mem_loads
> event.  I guess for ARM the answer is no.

Thanks for confirmation.

> > I am a bit suspect if we really need the field '.aux_event', the
> > '.aux_event' field is only used for generating event string.
> 
> No, it stores the event encoding for the extra event.
> ARM doesn't need it, so it's 0.

I searched a bit and confirmed '.aux_event' is only used in
util/mem-events.c and for 'perf record'.

I failed to connect the code with "it stores the event encoding for the
extra event".  Could you elaborate a bit for this?

Thanks,
Leo


From broonie at kernel.org  Wed Dec 13 05:37:32 2023
From: broonie at kernel.org (Mark Brown)
Date: Wed, 13 Dec 2023 13:37:32 +0000
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <CAKC1njSQPO8ja7AkTzQ724hhSsGjchH9dLbbH9LXP0ZiKj-zPQ@mail.gmail.com>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
 <CAKC1njSC5cC_fXnyNAPt=WU6cD-OjLKFxo90oVPmsLJbuWf4nw@mail.gmail.com>
 <d708b493-267a-4418-be91-9bde6b2cf50c@sirena.org.uk>
 <CAKC1njSQPO8ja7AkTzQ724hhSsGjchH9dLbbH9LXP0ZiKj-zPQ@mail.gmail.com>
Message-ID: <0d0d8802-09e3-4ea5-a0b4-b3a08c8a282e@sirena.org.uk>

On Tue, Dec 12, 2023 at 04:50:38PM -0800, Deepak Gupta wrote:

> A theoretical scenario (no current workloads should've this case
> because no shadow stack)

> - User mode did _ENABLE on the main thread. Shadow stack was allocated
> for the current
>   thread.
> - User mode created a bunch worker threads to run untrusted contained
> code. They shadow
>   stack too.
> - main thread had to do dlopen and now need to disable shadow stack on
> itself due to
>   incompatibility of incoming object in address space.
> - main thread controls worker threads and knows they're contained and
> should still be running
>   with a shadow stack. Although once in a while the main thread needs
> to perform writes to a shadow
>   stack of worker threads for some fixup (in the same addr space).
> main thread doesn't want to delegate
>   this responsibility of ss writes to worker threads because they're untrusted.

> How will it do that (currently _ENABLE is married to _WRITE and _PUSH) ?

That's feeling moderately firmly into "don't do that" territory to be
honest, the problems of trying to modify the stack of another running
thread while it's active just don't seem worth it - if you're
coordinating enough to do the modifications it's probably possible to
just ask the thread who's stack is being modified to do the modification
itself and having an unprotected thread writing into shadow stack memory
doesn't feel great.

That said in terms of the API there would be nothing stopping us saying
that _WRITE by itself is a valid combination of flags, in which case the
thread would have permission to write to any shadow stack memory it
could get to.  For arm64 I think we can implement that, I'm not sure
about x86.  _PUSH without _ENABLE is a lot less clear, you would at the
very least at some point have had a stack enabled to have a stack
pointer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/a02b278d/attachment.sig>

From lkp at intel.com  Wed Dec 13 05:41:10 2023
From: lkp at intel.com (kernel test robot)
Date: Wed, 13 Dec 2023 21:41:10 +0800
Subject: [PATCH 06/15] arm64: Add KHO support
In-Reply-To: <20231213000452.88295-7-graf@amazon.com>
References: <20231213000452.88295-7-graf@amazon.com>
Message-ID: <202312132139.g2NKV67G-lkp@intel.com>

Hi Alexander,

kernel test robot noticed the following build warnings:

[auto build test WARNING on tip/x86/core]
[also build test WARNING on arm64/for-next/core akpm-mm/mm-everything linus/master v6.7-rc5 next-20231213]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Alexander-Graf/mm-memblock-Add-support-for-scratch-memory/20231213-080941
base:   tip/x86/core
patch link:    https://lore.kernel.org/r/20231213000452.88295-7-graf%40amazon.com
patch subject: [PATCH 06/15] arm64: Add KHO support
config: microblaze-randconfig-r133-20231213 (https://download.01.org/0day-ci/archive/20231213/202312132139.g2NKV67G-lkp at intel.com/config)
compiler: microblaze-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231213/202312132139.g2NKV67G-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312132139.g2NKV67G-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/of/fdt.c:1012:13: sparse: sparse: symbol 'early_init_dt_check_kho' was not declared. Should it be static?

vim +/early_init_dt_check_kho +1012 drivers/of/fdt.c

  1008	
  1009	/**
  1010	 * early_init_dt_check_kho - Decode info required for kexec handover from DT
  1011	 */
> 1012	void __init early_init_dt_check_kho(void)
  1013	{
  1014	#ifdef CONFIG_KEXEC_KHO
  1015		unsigned long node = chosen_node_offset;
  1016		u64 kho_start, scratch_start, scratch_size, mem_start, mem_size;
  1017		const __be32 *p;
  1018		int l;
  1019	
  1020		if ((long)node < 0)
  1021			return;
  1022	
  1023		p = of_get_flat_dt_prop(node, "linux,kho-dt", &l);
  1024		if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
  1025			return;
  1026	
  1027		kho_start = dt_mem_next_cell(dt_root_addr_cells, &p);
  1028	
  1029		p = of_get_flat_dt_prop(node, "linux,kho-scratch", &l);
  1030		if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
  1031			return;
  1032	
  1033		scratch_start = dt_mem_next_cell(dt_root_addr_cells, &p);
  1034		scratch_size = dt_mem_next_cell(dt_root_addr_cells, &p);
  1035	
  1036		p = of_get_flat_dt_prop(node, "linux,kho-mem", &l);
  1037		if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
  1038			return;
  1039	
  1040		mem_start = dt_mem_next_cell(dt_root_addr_cells, &p);
  1041		mem_size = dt_mem_next_cell(dt_root_addr_cells, &p);
  1042	
  1043		kho_populate(kho_start, scratch_start, scratch_size, mem_start, mem_size);
  1044	#endif
  1045	}
  1046	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From james.clark at arm.com  Wed Dec 13 05:48:22 2023
From: james.clark at arm.com (James Clark)
Date: Wed, 13 Dec 2023 13:48:22 +0000
Subject: [PATCH v1 06/14] libperf cpumap: Add any, empty and min helpers
In-Reply-To: <CAP-5=fUWtgNMGWowN2+qnV5FV3viHd=kPqiwXUeEtkQAzabLGw@mail.gmail.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-7-irogers@google.com>
 <94e3745c-8c2b-bdf3-f331-1cbe56574d48@arm.com>
 <CAP-5=fUWtgNMGWowN2+qnV5FV3viHd=kPqiwXUeEtkQAzabLGw@mail.gmail.com>
Message-ID: <ef228b62-c39f-5155-f012-6ed81508e99a@arm.com>



On 12/12/2023 20:27, Ian Rogers wrote:
> On Tue, Dec 12, 2023 at 7:06?AM James Clark <james.clark at arm.com> wrote:
>>
>>
>>
>> On 29/11/2023 06:02, Ian Rogers wrote:
>>> Additional helpers to better replace
>>> perf_cpu_map__has_any_cpu_or_is_empty.
>>>
>>> Signed-off-by: Ian Rogers <irogers at google.com>
>>> ---
>>>  tools/lib/perf/cpumap.c              | 27 +++++++++++++++++++++++++++
>>>  tools/lib/perf/include/perf/cpumap.h | 16 ++++++++++++++++
>>>  tools/lib/perf/libperf.map           |  4 ++++
>>>  3 files changed, 47 insertions(+)
>>>
>>> diff --git a/tools/lib/perf/cpumap.c b/tools/lib/perf/cpumap.c
>>> index 49fc98e16514..7403819da8fd 100644
>>> --- a/tools/lib/perf/cpumap.c
>>> +++ b/tools/lib/perf/cpumap.c
>>> @@ -316,6 +316,19 @@ bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map)
>>>       return map ? __perf_cpu_map__cpu(map, 0).cpu == -1 : true;
>>>  }
>>>
>>> +bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map)
>>> +{
>>> +     if (!map)
>>> +             return true;
>>> +
>>> +     return __perf_cpu_map__nr(map) == 1 && __perf_cpu_map__cpu(map, 0).cpu == -1;
>>> +}
>>
>> I'm struggling to understand the relevance of the difference between
>> has_any and is_any I see that there is a slight difference, but could it
>> not be refactored out so we only need one?
> 
> Yep, that's what these changes are working toward. For has any the set
> {-1, 0, 1} would return true while is any will return false.
> Previously the has any behavior was called "empty" which I think is
> actively misleading.
> 
>> Do you ever get an 'any' map that has more than 1 entry? It's quite a
>> subtle difference that is_any returns false if the first one is 'any'
>> but then there are subsequent entries. Whereas has_any would return
>> true. I'm not sure if future readers would be able to appreciate that.
>>
>> I see has_any is only used twice, both on evlist->all_cpus. Is there
>> something about that member that means it could have a map that has an
>> 'any' mixed with CPUs? Wouldn't that have the same result as a normal
>> 'any' anyway?
> 
> The dummy event may be opened on any CPU but then a particular event
> may be opened on certain CPUs. We merge CPU maps in places like evlist
> so that we can iterate the appropriate CPUs for events and
> open/enable/disable/close all events on a certain CPU at the same time
> (we also set the affinity to that CPU to avoid IPIs). What I'm hoping
> to do in these changes is reduce the ambiguity, the corner cases are
> by their nature unusual.
> 
> An example of a corner case is, uncore events often get opened just on
> CPU 0 but on a multi-socket system you may have a CPU 32 that also
> needs to open the event. Previous code treated the CPU map index and
> value it contained pretty interchangeably. This is often fine for the
> core PMU but is clearly wrong in this uncore case, {0, 32} has indexes
> 0 and 1 but those indexes don't match the CPU numbers. The case of -1
> has often previously been called dummy but I'm trying to call it the
> "any CPU" case to match the perf_event_open man page (I'm hoping it
> also makes it less ambiguous with any CPU being used with a particular
> event like cycles, calling it dummy makes the event sound like it may
> have sideband data). The difference between "all CPUs" and "any CPU"
> is that an evsel for all CPUs would need the event opening
> individually on each CPU, while any CPU events are a single open call.
> Any CPU is only valid to perf_event_open if a PID is specified.
> Depending on the set up there could be overlaps in what they count but
> hopefully it is clearer what the distinction is. I believe the case of
> "any CPU" and specific CPU numbers is more common with aux buffers and
> Adrian has mentioned needing it for intel-pt.
> 
> Thanks,
> Ian
> 

Thanks for explaining. I suppose I didn't realise that 'any' could be
merged with per-cpu maps, but it makes sense.

>>> +
>>> +bool perf_cpu_map__is_empty(const struct perf_cpu_map *map)
>>> +{
>>> +     return map == NULL;
>>> +}
>>> +
>>>  int perf_cpu_map__idx(const struct perf_cpu_map *cpus, struct perf_cpu cpu)
>>>  {
>>>       int low, high;
>>> @@ -372,6 +385,20 @@ bool perf_cpu_map__has_any_cpu(const struct perf_cpu_map *map)
>>>       return map && __perf_cpu_map__cpu(map, 0).cpu == -1;
>>>  }
>>>
>>> +struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map)
>>> +{
>>> +     struct perf_cpu cpu, result = {
>>> +             .cpu = -1
>>> +     };
>>> +     int idx;
>>> +
>>> +     perf_cpu_map__for_each_cpu_skip_any(cpu, idx, map) {
>>> +             result = cpu;
>>> +             break;
>>> +     }
>>> +     return result;
>>> +}
>>> +
>>>  struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map)
>>>  {
>>>       struct perf_cpu result = {
>>> diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/perf/cpumap.h
>>> index dbe0a7352b64..523e4348fc96 100644
>>> --- a/tools/lib/perf/include/perf/cpumap.h
>>> +++ b/tools/lib/perf/include/perf/cpumap.h
>>> @@ -50,6 +50,22 @@ LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
>>>   * perf_cpu_map__has_any_cpu_or_is_empty - is map either empty or has the "any CPU"/dummy value.
>>>   */
>>>  LIBPERF_API bool perf_cpu_map__has_any_cpu_or_is_empty(const struct perf_cpu_map *map);
>>> +/**
>>> + * perf_cpu_map__is_any_cpu_or_is_empty - is map either empty or the "any CPU"/dummy value.
>>> + */
>>> +LIBPERF_API bool perf_cpu_map__is_any_cpu_or_is_empty(const struct perf_cpu_map *map);
>>> +/**
>>> + * perf_cpu_map__is_empty - does the map contain no values and it doesn't
>>> + *                          contain the special "any CPU"/dummy value.
>>> + */
>>> +LIBPERF_API bool perf_cpu_map__is_empty(const struct perf_cpu_map *map);
>>> +/**
>>> + * perf_cpu_map__min - the minimum CPU value or -1 if empty or just the "any CPU"/dummy value.
>>> + */
>>> +LIBPERF_API struct perf_cpu perf_cpu_map__min(const struct perf_cpu_map *map);
>>> +/**
>>> + * perf_cpu_map__max - the maximum CPU value or -1 if empty or just the "any CPU"/dummy value.
>>> + */
>>>  LIBPERF_API struct perf_cpu perf_cpu_map__max(const struct perf_cpu_map *map);
>>>  LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, struct perf_cpu cpu);
>>>  LIBPERF_API bool perf_cpu_map__equal(const struct perf_cpu_map *lhs,
>>> diff --git a/tools/lib/perf/libperf.map b/tools/lib/perf/libperf.map
>>> index 10b3f3722642..2aa79b696032 100644
>>> --- a/tools/lib/perf/libperf.map
>>> +++ b/tools/lib/perf/libperf.map
>>> @@ -10,6 +10,10 @@ LIBPERF_0.0.1 {
>>>               perf_cpu_map__nr;
>>>               perf_cpu_map__cpu;
>>>               perf_cpu_map__has_any_cpu_or_is_empty;
>>> +             perf_cpu_map__is_any_cpu_or_is_empty;
>>> +             perf_cpu_map__is_empty;
>>> +             perf_cpu_map__has_any_cpu;
>>> +             perf_cpu_map__min;
>>>               perf_cpu_map__max;
>>>               perf_cpu_map__has;
>>>               perf_thread_map__new_array;


From broonie at kernel.org  Wed Dec 13 05:49:29 2023
From: broonie at kernel.org (Mark Brown)
Date: Wed, 13 Dec 2023 13:49:29 +0000
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <4acb51ebb3764f6a48a741d7b7d33f9a68c996fb.camel@intel.com>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
 <e1362732ba86990b7707d3f5b785358b77c5f896.camel@intel.com>
 <28c584ff-ef25-464f-852c-c5ddf66e5906@sirena.org.uk>
 <4acb51ebb3764f6a48a741d7b7d33f9a68c996fb.camel@intel.com>
Message-ID: <d723fdb4-9be9-4846-a49d-6bd00602afb3@sirena.org.uk>

On Tue, Dec 12, 2023 at 09:22:59PM +0000, Edgecombe, Rick P wrote:
> On Tue, 2023-12-12 at 20:26 +0000, Mark Brown wrote:

> > In general if things have a need to get at prctl()s via ptrace we
> > should
> > just fix that, at least for arm64 there's things like the vector
> > lengths
> > that are currently controlled via prctl(), but it shouldn't be a
> > blocker
> > for the locking specifically.

> ptrace arch_prctl() is a bit odd. Not all values of 'option' are
> supported because ptrace arch_prctl's have to operate cross task. Some
> have extra code to support doing this, and some only know how to
> operate on the current task, so return an error in the ptrace case.

It feels like x86 is doing some things via arch_prctl() rather than
implementing specific ptrace() interfaces for them, there's a lot of
stuff where ptrace isn't a great fit for due to it's concept that it's
going to work with an array of registers so that's understandable.

> I guess a benefit would be that there could be some arch agnostic
> ptrace userspace code. And I'd also guess (really a guess) that most
> ptracing code has some arch awareness already, but the other way is
> probably non-zero. Same for shadow stack enabling code. Then on the
> kernel side we'd have to add and support a ptrace prctl() solution.

> Is it worth the effort? I don't have a strong opinion.

I don't have a strong enough opinion on it to start working on it
immediately at any rate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/55c5319c/attachment.sig>

From mark.rutland at arm.com  Wed Dec 13 05:49:39 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 13 Dec 2023 13:49:39 +0000
Subject: [PATCH v7 5/7] arm64: vmemmap: Avoid base2 order of struct page
 size to dimension region
In-Reply-To: <20231213084024.2367360-14-ardb@google.com>
References: <20231213084024.2367360-9-ardb@google.com>
 <20231213084024.2367360-14-ardb@google.com>
Message-ID: <ZXm2c5_oA5rPrfm8@FVFF77S0Q05N>

Hi Ard,

On Wed, Dec 13, 2023 at 09:40:30AM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb at kernel.org>
> 
> The placement and size of the vmemmap region in the kernel virtual
> address space is currently derived from the base2 order of the size of a
> struct page. This makes for nicely aligned constants with lots of
> leading 0xf and trailing 0x0 digits, but given that the actual struct
> pages are indexed as an ordinary array, this resulting region is
> severely overdimensioned when the size of a struct page is just over a
> power of 2.
> 
> This doesn't matter today, but once we enable 52-bit virtual addressing
> for 4k pages configurations, the vmemmap region may take up almost half
> of the upper VA region with the current struct page upper bound at 64
> bytes. And once we enable KMSAN or other features that push the size of
> a struct page over 64 bytes, we will run out of VMALLOC space entirely.
> 
> So instead, let's derive the region size from the actual size of a
> struct page, and place the entire region 1 GB from the top of the VA
> space, where it still doesn't share any lower level translation table
> entries with the fixmap.
> 
> Acked-by: Mark Rutland <mark.rutland at arm.com>
> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> ---
>  arch/arm64/include/asm/memory.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 2745bed8ae5b..b49575a92afc 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -30,8 +30,8 @@
>   * keep a constant PAGE_OFFSET and "fallback" to using the higher end
>   * of the VMEMMAP where 52-bit support is not available in hardware.
>   */
> -#define VMEMMAP_SHIFT	(PAGE_SHIFT - STRUCT_PAGE_MAX_SHIFT)
> -#define VMEMMAP_SIZE	((_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) >> VMEMMAP_SHIFT)
> +#define VMEMMAP_RANGE	(_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET)
> +#define VMEMMAP_SIZE	((VMEMMAP_RANGE >> PAGE_SHIFT) * sizeof(struct page))
>  
>  /*
>   * PAGE_OFFSET - the virtual address of the start of the linear map, at the
> @@ -47,8 +47,8 @@
>  #define MODULES_END		(MODULES_VADDR + MODULES_VSIZE)
>  #define MODULES_VADDR		(_PAGE_END(VA_BITS_MIN))
>  #define MODULES_VSIZE		(SZ_2G)
> -#define VMEMMAP_START		(-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
> -#define VMEMMAP_END		(VMEMMAP_START + VMEMMAP_SIZE)
> +#define VMEMMAP_START		(VMEMMAP_END - VMEMMAP_SIZE)
> +#define VMEMMAP_END		(-UL(SZ_1G))
>  #define PCI_IO_START		(VMEMMAP_END + SZ_8M)
>  #define PCI_IO_END		(PCI_IO_START + PCI_IO_SIZE)
>  #define FIXADDR_TOP		(-UL(SZ_8M))

I realise I've acked this already, but my big concern here is still that it's
hard to see why these don't overlap (though the assert in fixmap.c will save
us). Usually we try to make that clear by construction, and I think we can do
that here with something like:

| #define GUARD_VA_SIZE          (UL(SZ_8M))
| 
| #define FIXADDR_TOP            (-GUARD_VA_SIZE)
| #define FIXADDR_SIZE_MAX       SZ_8M
| #define FIXADDR_START_MIN      (FIXADDR_TOP - FIXADDR_SIZE_MAX)
| 
| #define PCI_IO_END             (FIXADDR_START_MIN - GUARD_VA_SIZE)
| #define PCI_IO_START           (PCI_IO_END - PCI_IO_SIZE)
| 
| #define VMEMMAP_END            (ALIGN_DOWN(PCI_IO_START - GUARD_VA_SIZE, SZ_1G))
| #define VMEMMAP_START          (VMEMMAP_END - VMEMMAP_SIZE)

... and in fixmap.h have:

/* Ensure the estimate in memory.h was big enough */
static_assert(FIXADDR_SIZE_MAX > FIXADDR_SIZE);

I might be missing some reason why we can't do that; I locally tried the above
atop this series with defconfig+4K and defcconfig+64K, and both build and boot
without sisue.

Other than that, the series looks good to me.

If you're happy with the above I can go spin that as a patch to apply atop.

Mark.


From leo.yan at linaro.org  Wed Dec 13 05:51:19 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Wed, 13 Dec 2023 21:51:19 +0800
Subject: [PATCH V2 4/5] perf mem: Clean up perf_mem_event__supported()
In-Reply-To: <2865c1b4-a003-44df-a734-1e1c90bfa14d@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-5-kan.liang@linux.intel.com>
 <20231209061723.GC2116834@leoy-yangtze.lan>
 <2865c1b4-a003-44df-a734-1e1c90bfa14d@linux.intel.com>
Message-ID: <20231213134911.GB3895246@leoy-yangtze.lan>

On Mon, Dec 11, 2023 at 01:44:54PM -0500, Liang, Kan wrote:
> 
> 
> On 2023-12-09 1:17 a.m., Leo Yan wrote:
> > On Thu, Dec 07, 2023 at 11:23:37AM -0800, kan.liang at linux.intel.com wrote:
> >> From: Kan Liang <kan.liang at linux.intel.com>
> >>
> >> For some ARCHs, e.g., ARM and AMD, to get the availability of the
> >> mem-events, perf checks the existence of a specific PMU. For the other
> >> ARCHs, e.g., Intel and Power, perf has to check the existence of some
> >> specific events.
> >>
> >> The current perf only iterates the mem-events-supported PMUs. It's not
> >> required to check the existence of a specific PMU anymore.
> > 
> > With this change, both Arm and AMD archs have no chance to detect if the
> > hardware (or the device driver) is supported and the tool will always
> > take the memory events are exited on the system, right?
> 
> Currently, the Arm and AMD only check the specific PMU. If the PMU is
> detected, the memory events are supported. The patch set doesn't change
> it. It just moves the check to perf_pmu__arch_init(). When the specific
> PMU is initialized, the mem_events is assigned. You don't need to do
> runtime sysfs check. It should be an improvement for ARM and AMD.

Okay, I understand now.  For Arm SPE, it has a dedicated PMU so if the
PMU is detected, then we can assume the memory events are supported.

For other cases, you need to check furthermore if PMU has supported
specific memory events.

This patch is fine for me, you could ignore my comment for the
regression caused by this patch.

Thanks,
Leo


From vigneshr at ti.com  Wed Dec 13 05:51:35 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Wed, 13 Dec 2023 19:21:35 +0530
Subject: [PATCH v2 0/3] arm64: dts: ti: k3: Add additioal regs for DMA components
Message-ID: <20231213135138.929517-1-vigneshr@ti.com>

This adds additional reg ranges which are not directly used by Linux but
by other components like U-Boot

Binding is accepted via dmaengine tree and is in linux-next[0]

[0] https://lore.kernel.org/dmaengine/170083278148.771517.1841889156174413563.b4-ty at kernel.org/

v2:
Extend register ranges to match TRM as pointed out by Jai

v1: https://lore.kernel.org/linux-arm-kernel/20231212111634.3515175-1-vigneshr at ti.com/

Manorit Chawdhry (2):
  arm64: dts: ti: k3-am65: Add additional regs for DMA components
  arm64: dts: ti: k3-j7*: Add additional regs for DMA components

Vignesh Raghavendra (1):
  arm64: dts: ti: k3-am6*: Add additional regs for DMA components

 arch/arm64/boot/dts/ti/k3-am62-main.dtsi       | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi      | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am62p-main.dtsi      | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi       | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi       |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi        |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi      |  8 ++++++--
 .../arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi      |  8 ++++++--
 .../arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi     |  8 ++++++--
 .../boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi      |  8 ++++++--
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi     |  8 ++++++--
 .../boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi      |  8 ++++++--
 14 files changed, 116 insertions(+), 36 deletions(-)

-- 
2.43.0



From vigneshr at ti.com  Wed Dec 13 05:51:36 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Wed, 13 Dec 2023 19:21:36 +0530
Subject: [PATCH v2 1/3] arm64: dts: ti: k3-am65: Add additional regs for DMA components
In-Reply-To: <20231213135138.929517-1-vigneshr@ti.com>
References: <20231213135138.929517-1-vigneshr@ti.com>
Message-ID: <20231213135138.929517-2-vigneshr@ti.com>

From: Manorit Chawdhry <m-chawdhry at ti.com>

Add additional reg properties for UDMA and RingAcc nodes which are
mostly used by bootloader components before Device Manager firmware
services are available, in order to setup DMA transfers.

Signed-off-by: Manorit Chawdhry <m-chawdhry at ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi  | 8 ++++++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index cc59fc648b56..fcea54465636 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -792,8 +792,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,am654-navss-main-udmap";
 			reg = <0x0 0x31150000 0x0 0x100>,
 			      <0x0 0x34000000 0x0 0x100000>,
-			      <0x0 0x35000000 0x0 0x100000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x35000000 0x0 0x100000>,
+			      <0x0 0x30b00000 0x0 0x10000>,
+			      <0x0 0x30c00000 0x0 0x10000>,
+			      <0x0 0x30d00000 0x0 0x8000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_udmass>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index edd5cfbec40e..ecd7356f3315 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -214,8 +214,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,am654-navss-mcu-udmap";
 			reg = <0x0 0x285c0000 0x0 0x100>,
 			      <0x0 0x2a800000 0x0 0x40000>,
-			      <0x0 0x2aa00000 0x0 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x2aa00000 0x0 0x40000>,
+			      <0x0 0x284a0000 0x0 0x4000>,
+			      <0x0 0x284c0000 0x0 0x4000>,
+			      <0x0 0x28400000 0x0 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_udmass>;
 			#dma-cells = <1>;
 
-- 
2.43.0



From vigneshr at ti.com  Wed Dec 13 05:51:37 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Wed, 13 Dec 2023 19:21:37 +0530
Subject: [PATCH v2 2/3] arm64: dts: ti: k3-j7*: Add additional regs for DMA components
In-Reply-To: <20231213135138.929517-1-vigneshr@ti.com>
References: <20231213135138.929517-1-vigneshr@ti.com>
Message-ID: <20231213135138.929517-3-vigneshr@ti.com>

From: Manorit Chawdhry <m-chawdhry at ti.com>

Add additional reg properties for UDMA and RingAcc nodes which are
mostly used by bootloader components before Device Manager firmware
services are available, in order to setup DMA transfers.

Signed-off-by: Manorit Chawdhry <m-chawdhry at ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi        | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi  | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi        | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi  | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi       | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi       | 8 ++++++--
 arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi | 8 ++++++--
 8 files changed, 48 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 264913f83287..b8424994ac5f 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -281,8 +281,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,j721e-navss-main-udmap";
 			reg = <0x00 0x31150000 0x00 0x100>,
 			      <0x00 0x34000000 0x00 0x100000>,
-			      <0x00 0x35000000 0x00 0x100000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x00 0x35000000 0x00 0x100000>,
+			      <0x00 0x30b00000 0x00 0x4000>,
+			      <0x00 0x30c00000 0x00 0x4000>,
+			      <0x00 0x30d00000 0x00 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index 672cb2acc1be..60b26374ae0c 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -353,8 +353,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,j721e-navss-mcu-udmap";
 			reg = <0x00 0x285c0000 0x00 0x100>,
 			      <0x00 0x2a800000 0x00 0x40000>,
-			      <0x00 0x2aa00000 0x00 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x00 0x2aa00000 0x00 0x40000>,
+			      <0x00 0x284a0000 0x00 0x4000>,
+			      <0x00 0x284c0000 0x00 0x4000>,
+			      <0x00 0x28400000 0x00 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 746b9f8b1c64..2569b4c08ffb 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -382,8 +382,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,j721e-navss-main-udmap";
 			reg = <0x0 0x31150000 0x0 0x100>,
 			      <0x0 0x34000000 0x0 0x100000>,
-			      <0x0 0x35000000 0x0 0x100000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x35000000 0x0 0x100000>,
+			      <0x0 0x30b00000 0x0 0x20000>,
+			      <0x0 0x30c00000 0x0 0x10000>,
+			      <0x0 0x30d00000 0x0 0x8000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index 8f259efe3af9..a74912d9e4da 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -475,8 +475,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,j721e-navss-mcu-udmap";
 			reg = <0x0 0x285c0000 0x0 0x100>,
 			      <0x0 0x2a800000 0x0 0x40000>,
-			      <0x0 0x2aa00000 0x0 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x2aa00000 0x0 0x40000>,
+			      <0x0 0x284a0000 0x0 0x4000>,
+			      <0x0 0x284c0000 0x0 0x4000>,
+			      <0x0 0x28400000 0x0 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index b03731b53a26..bf959312fad0 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -1086,8 +1086,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,j721e-navss-main-udmap";
 			reg = <0x0 0x31150000 0x0 0x100>,
 			      <0x0 0x34000000 0x0 0x80000>,
-			      <0x0 0x35000000 0x0 0x200000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x35000000 0x0 0x200000>,
+			      <0x0 0x30b00000 0x0 0x20000>,
+			      <0x0 0x30c00000 0x0 0x8000>,
+			      <0x0 0x30d00000 0x0 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
index d9e2cab8a8c5..80aa33c58a45 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi
@@ -478,8 +478,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,j721e-navss-mcu-udmap";
 			reg = <0x0 0x285c0000 0x0 0x100>,
 			      <0x0 0x2a800000 0x0 0x40000>,
-			      <0x0 0x2aa00000 0x0 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x0 0x2aa00000 0x0 0x40000>,
+			      <0x0 0x284a0000 0x0 0x4000>,
+			      <0x0 0x284c0000 0x0 0x4000>,
+			      <0x0 0x28400000 0x0 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index d89bcddcfe3d..827328450f96 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -1188,8 +1188,12 @@ main_udmap: dma-controller at 31150000 {
 			compatible = "ti,j721e-navss-main-udmap";
 			reg = <0x00 0x31150000 0x00 0x100>,
 			      <0x00 0x34000000 0x00 0x80000>,
-			      <0x00 0x35000000 0x00 0x200000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x00 0x35000000 0x00 0x200000>,
+			      <0x00 0x30b00000 0x00 0x20000>,
+			      <0x00 0x30c00000 0x00 0x8000>,
+			      <0x00 0x30d00000 0x00 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
index 119f4e2cc0d1..3902a921d7e5 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
@@ -486,8 +486,12 @@ mcu_udmap: dma-controller at 285c0000 {
 			compatible = "ti,j721e-navss-mcu-udmap";
 			reg = <0x00 0x285c0000 0x00 0x100>,
 			      <0x00 0x2a800000 0x00 0x40000>,
-			      <0x00 0x2aa00000 0x00 0x40000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt";
+			      <0x00 0x2aa00000 0x00 0x40000>,
+			      <0x00 0x284a0000 0x00 0x4000>,
+			      <0x00 0x284c0000 0x00 0x4000>,
+			      <0x00 0x28400000 0x00 0x2000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt",
+				    "tchan", "rchan", "rflow";
 			msi-parent = <&main_udmass_inta>;
 			#dma-cells = <1>;
 
-- 
2.43.0



From vigneshr at ti.com  Wed Dec 13 05:51:38 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Wed, 13 Dec 2023 19:21:38 +0530
Subject: [PATCH v2 3/3] arm64: dts: ti: k3-am6*: Add additional regs for DMA components
In-Reply-To: <20231213135138.929517-1-vigneshr@ti.com>
References: <20231213135138.929517-1-vigneshr@ti.com>
Message-ID: <20231213135138.929517-4-vigneshr@ti.com>

Add additional reg properties for BCDMA and PKTDMA nodes which are
mostly used by bootloader components before Device Manager firmware
services are available, in order to setup DMA transfers.

Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi  | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 18 ++++++++++++++----
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi  | 18 ++++++++++++++----
 4 files changed, 56 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index 49000a97c153..357970f1134f 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -121,8 +121,13 @@ main_bcdma: dma-controller at 485c0100 {
 			      <0x00 0x4c000000 0x00 0x20000>,
 			      <0x00 0x4a820000 0x00 0x20000>,
 			      <0x00 0x4aa40000 0x00 0x20000>,
-			      <0x00 0x4bc00000 0x00 0x100000>;
-			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4bc00000 0x00 0x100000>,
+			      <0x00 0x48600000 0x00 0x8000>,
+			      <0x00 0x484a4000 0x00 0x2000>,
+			      <0x00 0x484c2000 0x00 0x2000>,
+			      <0x00 0x48420000 0x00 0x2000>;
+			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "bchan";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <3>;
 
@@ -138,8 +143,13 @@ main_pktdma: dma-controller at 485c0000 {
 			reg = <0x00 0x485c0000 0x00 0x100>,
 			      <0x00 0x4a800000 0x00 0x20000>,
 			      <0x00 0x4aa00000 0x00 0x40000>,
-			      <0x00 0x4b800000 0x00 0x400000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4b800000 0x00 0x400000>,
+			      <0x00 0x485e0000 0x00 0x10000>,
+			      <0x00 0x484a0000 0x00 0x2000>,
+			      <0x00 0x484c0000 0x00 0x2000>,
+			      <0x00 0x48430000 0x00 0x1000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <2>;
 
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index 2338a92a4c9f..f0b8c9ab1459 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -101,8 +101,13 @@ main_bcdma: dma-controller at 485c0100 {
 			      <0x00 0x4c000000 0x00 0x20000>,
 			      <0x00 0x4a820000 0x00 0x20000>,
 			      <0x00 0x4aa40000 0x00 0x20000>,
-			      <0x00 0x4bc00000 0x00 0x100000>;
-			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4bc00000 0x00 0x100000>,
+			      <0x00 0x48600000 0x00 0x8000>,
+			      <0x00 0x484a4000 0x00 0x2000>,
+			      <0x00 0x484c2000 0x00 0x2000>,
+			      <0x00 0x48420000 0x00 0x2000>;
+			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "bchan";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <3>;
 			ti,sci = <&dmsc>;
@@ -117,8 +122,13 @@ main_pktdma: dma-controller at 485c0000 {
 			reg = <0x00 0x485c0000 0x00 0x100>,
 			      <0x00 0x4a800000 0x00 0x20000>,
 			      <0x00 0x4aa00000 0x00 0x40000>,
-			      <0x00 0x4b800000 0x00 0x400000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4b800000 0x00 0x400000>,
+			      <0x00 0x485e0000 0x00 0x10000>,
+			      <0x00 0x484a0000 0x00 0x2000>,
+			      <0x00 0x484c0000 0x00 0x2000>,
+			      <0x00 0x48430000 0x00 0x1000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <2>;
 			ti,sci = <&dmsc>;
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
index 963758c7d377..4c51bae06b57 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
@@ -101,8 +101,13 @@ main_bcdma: dma-controller at 485c0100 {
 			      <0x00 0x4c000000 0x00 0x20000>,
 			      <0x00 0x4a820000 0x00 0x20000>,
 			      <0x00 0x4aa40000 0x00 0x20000>,
-			      <0x00 0x4bc00000 0x00 0x100000>;
-			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4bc00000 0x00 0x100000>,
+			      <0x00 0x48600000 0x00 0x8000>,
+			      <0x00 0x484a4000 0x00 0x2000>,
+			      <0x00 0x484c2000 0x00 0x2000>,
+			      <0x00 0x48420000 0x00 0x2000>;
+			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "bchan";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <3>;
 
@@ -119,8 +124,13 @@ main_pktdma: dma-controller at 485c0000 {
 			reg = <0x00 0x485c0000 0x00 0x100>,
 			      <0x00 0x4a800000 0x00 0x20000>,
 			      <0x00 0x4aa00000 0x00 0x40000>,
-			      <0x00 0x4b800000 0x00 0x400000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4b800000 0x00 0x400000>,
+			      <0x00 0x485e0000 0x00 0x10000>,
+			      <0x00 0x484a0000 0x00 0x2000>,
+			      <0x00 0x484c0000 0x00 0x2000>,
+			      <0x00 0x48430000 0x00 0x1000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <2>;
 			bootph-all;
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index c7be378492e2..e348114f42e0 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -138,8 +138,13 @@ main_bcdma: dma-controller at 485c0100 {
 			      <0x00 0x4c000000 0x00 0x20000>,
 			      <0x00 0x4a820000 0x00 0x20000>,
 			      <0x00 0x4aa40000 0x00 0x20000>,
-			      <0x00 0x4bc00000 0x00 0x100000>;
-			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4bc00000 0x00 0x100000>,
+			      <0x00 0x48600000 0x00 0x8000>,
+			      <0x00 0x484a4000 0x00 0x2000>,
+			      <0x00 0x484c2000 0x00 0x2000>,
+			      <0x00 0x48420000 0x00 0x2000>;
+			reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "bchan";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <3>;
 
@@ -155,8 +160,13 @@ main_pktdma: dma-controller at 485c0000 {
 			reg = <0x00 0x485c0000 0x00 0x100>,
 			      <0x00 0x4a800000 0x00 0x20000>,
 			      <0x00 0x4aa00000 0x00 0x40000>,
-			      <0x00 0x4b800000 0x00 0x400000>;
-			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+			      <0x00 0x4b800000 0x00 0x400000>,
+			      <0x00 0x485e0000 0x00 0x20000>,
+			      <0x00 0x484a0000 0x00 0x4000>,
+			      <0x00 0x484c0000 0x00 0x2000>,
+			      <0x00 0x48430000 0x00 0x4000>;
+			reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+				    "ring", "tchan", "rchan", "rflow";
 			msi-parent = <&inta_main_dmss>;
 			#dma-cells = <2>;
 
-- 
2.43.0



From ajones at ventanamicro.com  Wed Dec 13 05:52:15 2023
From: ajones at ventanamicro.com (Andrew Jones)
Date: Wed, 13 Dec 2023 14:52:15 +0100
Subject: [PATCH v4 03/11] KVM: selftests: Add CONFIG_64BIT definition for
 the build
In-Reply-To: <227b86955b24583b5cacedc8480e8f5d7e4fabf8.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
 <227b86955b24583b5cacedc8480e8f5d7e4fabf8.1702371136.git.haibo1.xu@intel.com>
Message-ID: <20231213-b7a894416841716b792da2d5@orel>

On Tue, Dec 12, 2023 at 05:31:12PM +0800, Haibo Xu wrote:
> Since only 64bit KVM selftests were supported on all architectures,
> add the CONFIG_64BIT definition in kvm/Makefile to ensure only 64bit
> definitions were available in the corresponding included files.
> 
> Suggested-by: Andrew Jones <ajones at ventanamicro.com>
> Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
> ---
>  tools/testing/selftests/kvm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> index 4838ea899bbb..bb03e278a163 100644
> --- a/tools/testing/selftests/kvm/Makefile
> +++ b/tools/testing/selftests/kvm/Makefile
> @@ -225,7 +225,7 @@ else
>  LINUX_TOOL_ARCH_INCLUDE = $(top_srcdir)/tools/arch/$(ARCH)/include
>  endif
>  CFLAGS += -Wall -Wstrict-prototypes -Wuninitialized -O2 -g -std=gnu99 \
> -	-Wno-gnu-variable-sized-type-not-at-end -MD\
> +	-Wno-gnu-variable-sized-type-not-at-end -MD -DCONFIG_64BIT \
>  	-fno-builtin-memcmp -fno-builtin-memcpy -fno-builtin-memset \
>  	-fno-builtin-strnlen \
>  	-fno-stack-protector -fno-PIE -I$(LINUX_TOOL_INCLUDE) \
> -- 
> 2.34.1
>

Reviewed-by: Andrew Jones <ajones at ventanamicro.com>


From james.clark at arm.com  Wed Dec 13 05:54:26 2023
From: james.clark at arm.com (James Clark)
Date: Wed, 13 Dec 2023 13:54:26 +0000
Subject: [PATCH 1/8] coresight: Fix issue where a source device's helpers
 aren't disabled
In-Reply-To: <a1ab2481-0ec0-4e29-b6af-bcce4cf0b57d@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
 <20231212155407.1429121-2-james.clark@arm.com>
 <a1ab2481-0ec0-4e29-b6af-bcce4cf0b57d@arm.com>
Message-ID: <3c7665ff-b2e2-f10d-a78a-4ddc1791926f@arm.com>



On 12/12/2023 17:44, Suzuki K Poulose wrote:
> Hi James
> 
> On 12/12/2023 15:53, James Clark wrote:
>> The linked commit reverts the change that accidentally used some sysfs
>> enable/disable functions from Perf which broke the refcounting, but it
>> also removes the fact that the sysfs disable function disabled the
>> helpers.
> 
> 
>>
>> Add a new wrapper function that does both which is used by both Perf and
>> sysfs, and label the sysfs disable function appropriately. The naming of
>> all of the functions will be tidied up later to avoid this happening
>> again.
>>
>> Fixes: 287e82cf69aa ("coresight: Fix crash when Perf and sysfs modes
>> are used concurrently")
> 
> But we still don't "enable" the helpers from perf mode with this patch.
> i.e., we use source_ops()->enable directly. So, I guess this patch
> doesn't fix a bug as such. But that said, it would be good to
> enable/disable helpers for sources, in perf mode.
> 
> Suzuki

We do, it happens in coresight_enable_path() which Perf uses. I added
the comment below about that.

 [...]

>> ? +/*
>> + * Helper function to call source_ops(csdev)->disable and also
>> disable the
>> + * helpers.
>> + *
>> + * There is an imbalance between coresight_enable_path() and
>> + * coresight_disable_path(). Enabling also enables the source's
>> helpers as part
>> + * of the path, but disabling always skips the first item in the path
>> (which is
>> + * the source), so sources and their helpers don't get disabled as
>> part of that
>> + * function and we need the extra step here.
>> + */

The reason coresight_disable_path() skips the first item is because it's
used after errors where a path is only partially enabled and it unwinds,
skipping the last item, because the last item didn't enable.

It seemed a bit more intrusive to change that, and it's already working.


From ravi.bangoria at amd.com  Wed Dec 13 05:55:14 2023
From: ravi.bangoria at amd.com (Ravi Bangoria)
Date: Wed, 13 Dec 2023 19:25:14 +0530
Subject: [PATCH V2 4/5] perf mem: Clean up perf_mem_event__supported()
In-Reply-To: <20231213134911.GB3895246@leoy-yangtze.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-5-kan.liang@linux.intel.com>
 <20231209061723.GC2116834@leoy-yangtze.lan>
 <2865c1b4-a003-44df-a734-1e1c90bfa14d@linux.intel.com>
 <20231213134911.GB3895246@leoy-yangtze.lan>
Message-ID: <1c2965b5-28f7-e80e-250e-200d189d5eec@amd.com>

>>>> For some ARCHs, e.g., ARM and AMD, to get the availability of the
>>>> mem-events, perf checks the existence of a specific PMU. For the other
>>>> ARCHs, e.g., Intel and Power, perf has to check the existence of some
>>>> specific events.
>>>>
>>>> The current perf only iterates the mem-events-supported PMUs. It's not
>>>> required to check the existence of a specific PMU anymore.
>>>
>>> With this change, both Arm and AMD archs have no chance to detect if the
>>> hardware (or the device driver) is supported and the tool will always
>>> take the memory events are exited on the system, right?
>>
>> Currently, the Arm and AMD only check the specific PMU. If the PMU is
>> detected, the memory events are supported. The patch set doesn't change
>> it. It just moves the check to perf_pmu__arch_init(). When the specific
>> PMU is initialized, the mem_events is assigned. You don't need to do
>> runtime sysfs check. It should be an improvement for ARM and AMD.
> 
> Okay, I understand now.  For Arm SPE, it has a dedicated PMU so if the
> PMU is detected, then we can assume the memory events are supported.

Same for AMD. If ibs_op// pmu is present, the mem event is supported.

Thanks,
Ravi


From ilpo.jarvinen at linux.intel.com  Wed Dec 13 05:57:41 2023
From: ilpo.jarvinen at linux.intel.com (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Wed, 13 Dec 2023 15:57:41 +0200 (EET)
Subject: [PATCH V5 3/3] tty: serial: uartps: Add rs485 support to uartps
 driver
In-Reply-To: <20231213130023.606486-4-manikanta.guntupalli@amd.com>
References: <20231213130023.606486-1-manikanta.guntupalli@amd.com> <20231213130023.606486-4-manikanta.guntupalli@amd.com>
Message-ID: <7919791e-f52f-eb35-ead-deea90cbe8@linux.intel.com>

On Wed, 13 Dec 2023, Manikanta Guntupalli wrote:

> Add rs485 support to uartps driver. Use either rts-gpios or RTS
> to control RS485 phy as driver or a receiver.
> 
> Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
> ---
> Changes for V2:
> Modify optional gpio name to xlnx,phy-ctrl-gpios.
> Update commit description.
> Add support for RTS, delay_rts_before_send and delay_rts_after_send in RS485 mode.
> 
> Changes for V3:
> Modify optional gpio name to rts-gpios.
> Update commit description.
> Move cdns_uart_tx_empty function to avoid prototype statement.
> Remove assignment of struct serial_rs485 to port->rs485 as
> serial core performs that.
> Switch to native RTS in non GPIO case.
> Handle rs485 during stop tx.
> Remove explicit calls to configure gpio direction and value,
> as devm_gpiod_get_optional performs that by using GPIOD_OUT_LOW argument.
> Update implementation to support configuration of GPIO/RTS value
> based on user configuration of SER_RS485_RTS_ON_SEND and
> SER_RS485_RTS_AFTER_SEND. Move implementation to start_tx from handle_tx.
> 
> Changes for V4:
> Create separate patch for cdns_uart_tx_empty relocation.
> Call cdns_rs485_rx_setup() before uart_add_one_port() in probe.
> Update gpio descriptor name to gpiod_rts.
> Instead of cdns_rs485_config_gpio_rts_high() and
> cdns_rs485_config_gpio_rts_low() functions for RTS/GPIO value
> configuration implement cdns_rts_gpio_enable().
> Disable auto rts and call cdns_uart_stop_tx() from cdns_rs485_config.
> Use timer instead of mdelay for delay_rts_before_send and delay_rts_after_send.
> Update cdns_uart_set_mctrl to support GPIO/RTS.
> 
> Changes for V5:
> None.
> ---
>  drivers/tty/serial/xilinx_uartps.c | 214 +++++++++++++++++++++++++++--
>  1 file changed, 205 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
> index aafcc2179e0e..3e1045896812 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -22,7 +22,9 @@
>  #include <linux/of.h>
>  #include <linux/module.h>
>  #include <linux/pm_runtime.h>
> -#include <linux/iopoll.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/delay.h>
>  
>  #define CDNS_UART_TTY_NAME	"ttyPS"
>  #define CDNS_UART_NAME		"xuartps"
> @@ -193,6 +195,10 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255");
>   * @clk_rate_change_nb:	Notifier block for clock changes
>   * @quirks:		Flags for RXBS support.
>   * @cts_override:	Modem control state override
> + * @gpiod_rts:		Pointer to the gpio descriptor
> + * @rs485_tx_started:	RS485 tx state
> + * @timer:		Timer for tx and rx
> + * @stop_tx_timer:	Timer for stop tx
>   */
>  struct cdns_uart {
>  	struct uart_port	*port;
> @@ -203,10 +209,22 @@ struct cdns_uart {
>  	struct notifier_block	clk_rate_change_nb;
>  	u32			quirks;
>  	bool cts_override;
> +	struct gpio_desc	*gpiod_rts;
> +	bool			rs485_tx_started;
> +	struct timer_list	timer;
> +	struct timer_list	stop_tx_timer;
>  };
>  struct cdns_platform_data {
>  	u32 quirks;
>  };
> +
> +struct serial_rs485 cdns_rs485_supported = {
> +	.flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND |
> +		 SER_RS485_RTS_AFTER_SEND,
> +	.delay_rts_before_send = 1,
> +	.delay_rts_after_send = 1,
> +};
> +
>  #define to_cdns_uart(_nb) container_of(_nb, struct cdns_uart, \
>  		clk_rate_change_nb)
>  
> @@ -305,6 +323,55 @@ static void cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus)
>  	tty_flip_buffer_push(&port->state->port);
>  }
>  
> +/**
> + * cdns_rts_gpio_enable - Configure RTS/GPIO to high/low
> + * @cdns_uart: Handle to the cdns_uart
> + * @enable: Value to be set to RTS/GPIO
> + */
> +static void cdns_rts_gpio_enable(struct cdns_uart *cdns_uart, bool enable)
> +{
> +	u32 val;
> +
> +	if (cdns_uart->gpiod_rts) {
> +		gpiod_set_value(cdns_uart->gpiod_rts, enable);
> +	} else {
> +		val = readl(cdns_uart->port->membase + CDNS_UART_MODEMCR);
> +		if (enable)
> +			val &= ~CDNS_UART_MODEMCR_RTS;
> +		else
> +			val |= CDNS_UART_MODEMCR_RTS;
> +		writel(val, cdns_uart->port->membase + CDNS_UART_MODEMCR);
> +	}
> +}
> +
> +/**
> + * cdns_rs485_tx_setup - Tx setup specific to rs485
> + * @cdns_uart: Handle to the cdns_uart
> + */
> +static void cdns_rs485_tx_setup(struct cdns_uart *cdns_uart)
> +{
> +	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_ON_SEND)
> +		cdns_rts_gpio_enable(cdns_uart, 1);
> +	else
> +		cdns_rts_gpio_enable(cdns_uart, 0);
> +
> +	cdns_uart->rs485_tx_started = true;
> +}
> +
> +/**
> + * cdns_rs485_rx_setup - Rx setup specific to rs485
> + * @cdns_uart: Handle to the cdns_uart
> + */
> +static void cdns_rs485_rx_setup(struct cdns_uart *cdns_uart)
> +{
> +	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_AFTER_SEND)
> +		cdns_rts_gpio_enable(cdns_uart, 1);
> +	else
> +		cdns_rts_gpio_enable(cdns_uart, 0);
> +
> +	cdns_uart->rs485_tx_started = false;
> +}
> +
>  /**
>   * cdns_uart_tx_empty -  Check whether TX is empty
>   * @port: Handle to the uart port structure
> @@ -579,6 +646,42 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
>  }
>  #endif
>  
> +/**
> + * cdns_rs485_rx_callback - Timer rx callback handler for rs485.
> + * @t: Handle to the timer list structure
> + */
> +static void cdns_rs485_rx_callback(struct timer_list *t)
> +{
> +	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
> +
> +	/*
> +	 * Default Rx should be setup, because Rx signaling path
> +	 * need to enable to receive data.
> +	 */
> +	cdns_rs485_rx_setup(cdns_uart);
> +}
> +
> +/**
> + * cdns_rs485_tx_callback - Timer tx callback handler for rs485.
> + * @t: Handle to the timer list structure
> + */
> +static void cdns_rs485_tx_callback(struct timer_list *t)
> +{
> +	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
> +
> +	cdns_uart_handle_tx(cdns_uart->port);
> +
> +	/* Enable the TX Empty interrupt */
> +	writel(CDNS_UART_IXR_TXEMPTY, cdns_uart->port->membase + CDNS_UART_IER);
> +
> +	if (uart_circ_empty(&cdns_uart->port->state->xmit) ||
> +	    uart_tx_stopped(cdns_uart->port)) {
> +		timer_setup(&cdns_uart->timer, cdns_rs485_rx_callback, 0);
> +		mod_timer(&cdns_uart->timer, jiffies +
> +			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
> +	}
> +}
> +
>  /**
>   * cdns_uart_start_tx -  Start transmitting bytes
>   * @port: Handle to the uart port structure
> @@ -586,6 +689,7 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
>  static void cdns_uart_start_tx(struct uart_port *port)
>  {
>  	unsigned int status;
> +	struct cdns_uart *cdns_uart = port->private_data;
>  
>  	if (uart_tx_stopped(port))
>  		return;
> @@ -604,10 +708,40 @@ static void cdns_uart_start_tx(struct uart_port *port)
>  
>  	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_ISR);
>  
> -	cdns_uart_handle_tx(port);
> +	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
> +		if (!cdns_uart->rs485_tx_started) {
> +			timer_setup(&cdns_uart->timer,
> +				    cdns_rs485_tx_callback, 0);
> +			cdns_rs485_tx_setup(cdns_uart);
> +			mod_timer(&cdns_uart->timer, jiffies +
> +				  msecs_to_jiffies(port->rs485.delay_rts_before_send));
> +		} else {
> +			if (!timer_pending(&cdns_uart->timer))
> +				mod_timer(&cdns_uart->timer, jiffies);
> +		}
> +	} else {
> +		cdns_uart_handle_tx(port);
>  
> -	/* Enable the TX Empty interrupt */
> -	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
> +		/* Enable the TX Empty interrupt */
> +		writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
> +	}
> +}
> +
> +/**
> + * cdns_rs485_stop_tx_callback - Timer stop tx callback handler for rs485.
> + * @t: Handle to the timer list structure
> + */
> +static void cdns_rs485_stop_tx_callback(struct timer_list *t)
> +{
> +	unsigned int regval;
> +	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, stop_tx_timer);
> +
> +	cdns_rs485_rx_setup(cdns_uart);
> +
> +	regval = readl(cdns_uart->port->membase + CDNS_UART_CR);
> +	regval |= CDNS_UART_CR_TX_DIS;
> +	/* Disable the transmitter */
> +	writel(regval, cdns_uart->port->membase + CDNS_UART_CR);
>  }
>  
>  /**
> @@ -617,11 +751,19 @@ static void cdns_uart_start_tx(struct uart_port *port)
>  static void cdns_uart_stop_tx(struct uart_port *port)
>  {
>  	unsigned int regval;
> +	struct cdns_uart *cdns_uart = port->private_data;
>  
> -	regval = readl(port->membase + CDNS_UART_CR);
> -	regval |= CDNS_UART_CR_TX_DIS;
> -	/* Disable the transmitter */
> -	writel(regval, port->membase + CDNS_UART_CR);
> +	if ((cdns_uart->port->rs485.flags & SER_RS485_ENABLED) &&
> +	    !timer_pending(&cdns_uart->stop_tx_timer) &&
> +	    cdns_uart->rs485_tx_started) {
> +		mod_timer(&cdns_uart->stop_tx_timer, jiffies +
> +			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
> +	} else {
> +		regval = readl(port->membase + CDNS_UART_CR);
> +		regval |= CDNS_UART_CR_TX_DIS;
> +		/* Disable the transmitter */
> +		writel(regval, port->membase + CDNS_UART_CR);
> +	}
>  }
>  
>  /**
> @@ -829,6 +971,12 @@ static int cdns_uart_startup(struct uart_port *port)
>  		(CDNS_UART_CR_TXRST | CDNS_UART_CR_RXRST))
>  		cpu_relax();
>  
> +	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
> +		timer_setup(&cdns_uart->stop_tx_timer,
> +			    cdns_rs485_stop_tx_callback, 0);
> +		cdns_rs485_rx_setup(cdns_uart);
> +	}
> +
>  	/*
>  	 * Clear the RX disable bit and then set the RX enable bit to enable
>  	 * the receiver.
> @@ -888,6 +1036,7 @@ static void cdns_uart_shutdown(struct uart_port *port)
>  {
>  	int status;
>  	unsigned long flags;
> +	struct cdns_uart *cdns_uart = port->private_data;
>  
>  	uart_port_lock_irqsave(port, &flags);
>  
> @@ -903,6 +1052,11 @@ static void cdns_uart_shutdown(struct uart_port *port)
>  	uart_port_unlock_irqrestore(port, flags);
>  
>  	free_irq(port->irq, port);
> +
> +	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
> +		del_timer_sync(&cdns_uart->timer);
> +		del_timer_sync(&cdns_uart->stop_tx_timer);
> +	}
>  }
>  
>  /**
> @@ -1032,7 +1186,7 @@ static void cdns_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
>  	mode_reg &= ~CDNS_UART_MR_CHMODE_MASK;
>  
>  	if (mctrl & TIOCM_RTS)
> -		val |= CDNS_UART_MODEMCR_RTS;
> +		cdns_rts_gpio_enable(cdns_uart_data, 1);
>  	if (mctrl & TIOCM_DTR)
>  		val |= CDNS_UART_MODEMCR_DTR;
>  	if (mctrl & TIOCM_LOOP)
> @@ -1455,6 +1609,31 @@ MODULE_DEVICE_TABLE(of, cdns_uart_of_match);
>  /* Temporary variable for storing number of instances */
>  static int instances;
>  
> +/**
> + * cdns_rs485_config - Called when an application calls TIOCSRS485 ioctl.
> + * @port: Pointer to the uart_port structure
> + * @termios: Pointer to the ktermios structure
> + * @rs485: Pointer to the serial_rs485 structure
> + *
> + * Return: 0
> + */
> +static int cdns_rs485_config(struct uart_port *port, struct ktermios *termios,
> +			     struct serial_rs485 *rs485)
> +{
> +	u32 val;
> +
> +	if (rs485->flags & SER_RS485_ENABLED) {
> +		dev_dbg(port->dev, "Setting UART to RS485\n");
> +		/* Make sure auto RTS is disabled */
> +		val = readl(port->membase + CDNS_UART_MODEMCR);
> +		val &= ~CDNS_UART_MODEMCR_FCM;
> +		writel(val, port->membase + CDNS_UART_MODEMCR);
> +		/* Disable transmitter and make Rx setup*/

Missing space.

> +		cdns_uart_stop_tx(port);
> +	}

So you provide no way to disable RS485 after it once gets enable?
Arguably that might not usually be a very useful thing to do in practice 
but API-wise this function is expected to be able to also turn RS485 off.

I didn't do a full review but having to add a timer smells like you could
reuse the existing em485 framework for timing, please check.


-- 
 i.



From nm at ti.com  Wed Dec 13 05:58:00 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 13 Dec 2023 07:58:00 -0600
Subject: (subset) [PATCH v10 0/7] Add TPS6594 PMIC support on several boards
In-Reply-To: <20231208114919.3429562-1-n-francis@ti.com>
References: <20231208114919.3429562-1-n-francis@ti.com>
Message-ID: <170247584177.2577232.10722538239180811630.b4-ty@ti.com>

Hi Neha Malcom Francis,

On Fri, 08 Dec 2023 17:19:12 +0530, Neha Malcom Francis wrote:
> TPS6594 is a Power Management IC which provides regulators and others
> features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
> PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can
> communicate through the I2C or SPI interfaces.
> TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives.
> 
> This series adds device tree nodes for TI TPS6594 PMICs found in the
> following boards:
> - J721EXSOMXEVM:
>   Link: https://www.ti.com/tool/J721EXSOMXEVM
> - J721S2XSOMXEVM:
>   Link: https://www.ti.com/tool/J721S2XSOMXEVM
> - J7200XSOMXEVM:
>   Link: https://www.ti.com/tool/J7200XSOMXEVM
> - J784S4XEVM
>   Link: https://www.ti.com/tool/J784S4XEVM
> - SK-AM69
>   Link: https://www.ti.com/tool/SK-AM69
> - SK-TDA4VM (J721E-SK)
>   Link: https://www.ti.com/tool/SK-TDA4VM
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/7] arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
      commit: 08aaf5f02e9d593cf6b2dc7da9c568e19199e00e
[2/7] arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs
      commit: f4eb94b898f5b708d024a70fd544cdd76537bcf9
[3/7] arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
      commit: 46774eddde0ce499621cc8887106bcb449856e1f
[4/7] arm64: dts: ti: k3-j784s4-evm: Add support for TPS6594 PMIC
      commit: 3044f0184089e910f4da923bf64dca60ff47a117
[5/7] arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC
      commit: 865a1593bf99e1b3d4ffa6182919429694b17a36
[6/7] arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs
      commit: b808cef0be467318d862f87b64d7eddde6906ba3

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Wed Dec 13 05:58:31 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 13 Dec 2023 07:58:31 -0600
Subject: [PATCH v3 0/2] Add PCIe Endpoint overlays for J721E and J721S2
In-Reply-To: <20231211115535.1264353-1-s-vadapalli@ti.com>
References: <20231211115535.1264353-1-s-vadapalli@ti.com>
Message-ID: <170247588949.2577332.11579176748260902766.b4-ty@ti.com>

Hi Siddharth Vadapalli,

On Mon, 11 Dec 2023 17:25:33 +0530, Siddharth Vadapalli wrote:
> This series adds device-tree overlays for enabling PCIe in Endpoint mode
> of operation on J721E-EVM and J721S2-EVM.
> 
> NOTE: This series is based on linux-next tagged next-20231211.
> 
> v2:
> https://lore.kernel.org/r/20231115085204.3578616-1-s-vadapalli at ti.com/
> Changes since v2:
> - Rebased series on linux-next tagged next-20231211.
> - Collected Reviewed-by tag from:
>   Ravi Gunasekaran <r-gunasekaran at ti.com>
> - Updated Makefile based on Andrew's suggestion to build the DTBs
>   corresponding to the overlays only with an OF_ALL_DTBS build config
>   since the generated DTBs are not required except to ensure that the
>   overlays apply on the base DTB.
>   Reference:
>   https://lore.kernel.org/r/20231128-csi_dts-v3-9-0bb11cfa9d43 at ti.com
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/2] arm64: dts: ti: k3-j721e-evm: Add overlay for PCIE0 Endpoint Mode
      commit: 3942697901eb5340dc51202352f035ae191c37f2
[2/2] arm64: dts: ti: k3-j721s2-evm: Add overlay for PCIE1 Endpoint Mode
      commit: 729cfcf8ac2447f175eb4b6a0604983618ba07d5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Wed Dec 13 05:58:52 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 13 Dec 2023 07:58:52 -0600
Subject: [PATCH] soc: ti: k3-socinfo: Add JTAG ID for J722S
In-Reply-To: <20231211132600.25289-1-vaishnav.a@ti.com>
References: <20231211132600.25289-1-vaishnav.a@ti.com>
Message-ID: <170247592434.2577664.9645918157736470871.b4-ty@ti.com>

Hi Vaishnav Achath,

On Mon, 11 Dec 2023 18:56:00 +0530, Vaishnav Achath wrote:
> Add JTAG ID info for the J722S SoC family to enable SoC detection.
> 
> More details about this SoC can be found in the TRM:
> 	https://www.ti.com/lit/zip/sprujb3
> 
> 

I have applied the following to branch ti-drivers-soc-next on [1].
Thank you!

[1/1] soc: ti: k3-socinfo: Add JTAG ID for J722S
      commit: 2c2235292b33d788a1436f1d2a6108184a657f51

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From vigneshr at ti.com  Wed Dec 13 06:01:10 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Wed, 13 Dec 2023 19:31:10 +0530
Subject: [PATCH v3] watchdog: rti_wdt: Drop runtime pm reference count when watchdog is unused
Message-ID: <20231213140110.938129-1-vigneshr@ti.com>

Call runtime_pm_put*() if watchdog is not already started during probe and re
enable it in watchdog start as required.

On K3 SoCs, watchdogs and their corresponding CPUs are under same
power-domain, so if the reference count of unused watchdogs aren't
dropped, it will lead to CPU hotplug failures as Device Management
firmware won't allow to turn off the power-domain due to dangling
reference count.

Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support")
Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
Reviewed-by: Guenter Roeck <linux at roeck-us.net>
Tested-by: Manorit Chawdhry <m-chawdhry at ti.com>
---
v3:
Reword commit message to expand non std acronyms
Collect Reviewed-by and Tested-by tags
No code change

v2: https://lore.kernel.org/r/20231122041642.2015936-1-vigneshr at ti.com

v2:
* Drop 1/2 (will be posted along with runtime_pm callbacks)
* Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync() which
 takes care of err handling

v1: https://lore.kernel.org/r/20231110100726.2930218-1-vigneshr at ti.com

 drivers/watchdog/rti_wdt.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
index 8e1be7ba0103..9215793a1c81 100644
--- a/drivers/watchdog/rti_wdt.c
+++ b/drivers/watchdog/rti_wdt.c
@@ -77,6 +77,11 @@ static int rti_wdt_start(struct watchdog_device *wdd)
 {
 	u32 timer_margin;
 	struct rti_wdt_device *wdt = watchdog_get_drvdata(wdd);
+	int ret;
+
+	ret = pm_runtime_resume_and_get(wdd->parent);
+	if (ret)
+		return ret;
 
 	/* set timeout period */
 	timer_margin = (u64)wdd->timeout * wdt->freq;
@@ -343,6 +348,9 @@ static int rti_wdt_probe(struct platform_device *pdev)
 	if (last_ping)
 		watchdog_set_last_hw_keepalive(wdd, last_ping);
 
+	if (!watchdog_hw_running(wdd))
+		pm_runtime_put_sync(&pdev->dev);
+
 	return 0;
 
 err_iomap:
@@ -357,7 +365,10 @@ static void rti_wdt_remove(struct platform_device *pdev)
 	struct rti_wdt_device *wdt = platform_get_drvdata(pdev);
 
 	watchdog_unregister_device(&wdt->wdd);
-	pm_runtime_put(&pdev->dev);
+
+	if (!pm_runtime_suspended(&pdev->dev))
+		pm_runtime_put(&pdev->dev);
+
 	pm_runtime_disable(&pdev->dev);
 }
 
-- 
2.43.0



From glider at google.com  Wed Dec 13 06:01:17 2023
From: glider at google.com (Alexander Potapenko)
Date: Wed, 13 Dec 2023 15:01:17 +0100
Subject: [PATCH v9 0/4] Implement MTE tag compression for swapped pages
In-Reply-To: <20231213123130.GC31326@willie-the-truck>
References: <20231113105234.32058-1-glider@google.com> <20231213123130.GC31326@willie-the-truck>
Message-ID: <CAG_fn=WsYJmcABW3aXDyGrd04Sh2Hi7_2rReLc5xXPjQ4paScQ@mail.gmail.com>

On Wed, Dec 13, 2023 at 1:31?PM Will Deacon <will at kernel.org> wrote:
>
> On Mon, Nov 13, 2023 at 11:52:29AM +0100, Alexander Potapenko wrote:
> > Currently, when MTE pages are swapped out, the tags are kept in the
> > memory, occupying PAGE_SIZE/32 bytes per page. This is especially
> > problematic for devices that use zram-backed in-memory swap, because
> > tags stored uncompressed in the heap effectively reduce the available
> > amount of swap memory.
> >
> > The RLE-based algorithm suggested by Evgenii Stepanov and implemented in
> > this patch series is able to efficiently compress fixed-size tag buffers,
> > resulting in practical compression ratio of 2x. In many cases it is
> > possible to store the compressed data in 63-bit Xarray values, resulting
> > in no extra memory allocations.
> >
> > This patch series depends on "lib/bitmap: add bitmap_{read,write}()"
> > (https://lore.kernel.org/linux-arm-kernel/20231030153210.139512-1-glider at google.com/T/)
> > that is mailed separately.
>
> That's a shame, because it means I can't apply the series as-is:
>

Uh-oh, sorry about that. There was another series depending on the
bitmap_read/bitmap_write API, and I thought mailing those patches
separately would speed things up.
But in fact Yury requested them to have at least one user, so now that
the MTE series is also acked I'd better bring everything back
together.
Let me send out another version.

>
> arch/arm64/mm/mtecomp.c: In function ?mte_bitmap_write?:
> arch/arm64/mm/mtecomp.c:105:2: error: implicit declaration of function ?bitmap_write?; did you mean ?bitmap_free?? [-Werror=implicit-function-declaration]
>   105 |  bitmap_write(bitmap, value, *pos, bits);
>       |  ^~~~~~~~~~~~
>       |  bitmap_free
> arch/arm64/mm/mtecomp.c: In function ?mte_bitmap_read?:
> arch/arm64/mm/mtecomp.c:198:9: error: implicit declaration of function ?bitmap_read?; did you mean ?bitmap_remap?? [-Werror=implicit-function-declaration]
>   198 |  return bitmap_read(bitmap, start, bits);
>       |         ^~~~~~~~~~~
>       |         bitmap_remap
> cc1: some warnings being treated as errors
> make[5]: *** [scripts/Makefile.build:243: arch/arm64/mm/mtecomp.o] Error 1
>
>
> Do you really have such a hard dependency on those new bitmap ops?

Having them in bitmap.h seems natural - this way they can be reused by
other people.


From ajones at ventanamicro.com  Wed Dec 13 06:02:51 2023
From: ajones at ventanamicro.com (Andrew Jones)
Date: Wed, 13 Dec 2023 15:02:51 +0100
Subject: [PATCH v4 05/11] tools: riscv: Add header file vdso/processor.h
In-Reply-To: <7b633cc441f5133608597463301fef122f5174d3.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
 <7b633cc441f5133608597463301fef122f5174d3.1702371136.git.haibo1.xu@intel.com>
Message-ID: <20231213-9d5ad03bed3056007c6e714d@orel>

On Tue, Dec 12, 2023 at 05:31:14PM +0800, Haibo Xu wrote:
> Borrow the cpu_relax() definitions from kernel's
> arch/riscv/include/asm/vdso/processor.h to tools/ for riscv.
> 
> Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
> ---
>  tools/arch/riscv/include/asm/vdso/processor.h | 32 +++++++++++++++++++
>  1 file changed, 32 insertions(+)
>  create mode 100644 tools/arch/riscv/include/asm/vdso/processor.h
> 
> diff --git a/tools/arch/riscv/include/asm/vdso/processor.h b/tools/arch/riscv/include/asm/vdso/processor.h
> new file mode 100644
> index 000000000000..662aca039848
> --- /dev/null
> +++ b/tools/arch/riscv/include/asm/vdso/processor.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_VDSO_PROCESSOR_H
> +#define __ASM_VDSO_PROCESSOR_H
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <asm-generic/barrier.h>
> +
> +static inline void cpu_relax(void)
> +{
> +#ifdef __riscv_muldiv
> +	int dummy;
> +	/* In lieu of a halt instruction, induce a long-latency stall. */
> +	__asm__ __volatile__ ("div %0, %0, zero" : "=r" (dummy));
> +#endif
> +
> +#ifdef CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE
> +	/*
> +	 * Reduce instruction retirement.
> +	 * This assumes the PC changes.
> +	 */
> +	__asm__ __volatile__ ("pause");
> +#else
> +	/* Encoding of the pause instruction */
> +	__asm__ __volatile__ (".4byte 0x100000F");
> +#endif
> +	barrier();
> +}
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* __ASM_VDSO_PROCESSOR_H */
> -- 
> 2.34.1
>

Reviewed-by: Andrew Jones <ajones at ventanamicro.com>


From dario.binacchi at amarulasolutions.com  Wed Dec 13 06:03:41 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Wed, 13 Dec 2023 15:03:41 +0100
Subject: [PATCH v6 0/4] Add displays support for bsh-smm-s2/pro boards
Message-ID: <20231213140437.2769508-1-dario.binacchi@amarulasolutions.com>

The series adds drivers for the displays used by bsh-smm-s2/pro boards.
This required applying some patches to the samsung-dsim driver.

Changes in v6:
- Drop patches:
  - [06/10] drm/panel: Add Synaptics R63353 panel driver
  - [07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  - [08/10] drm/panel: Add Ilitek ILI9805 panel driver
  - [09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  Because applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)
  Drop patches:
  - [01/10] drm/bridge: Fix bridge disable logic
  - [02/10] drm/bridge: Fix a use case in the bridge disable logic
  Because they are wrong

Changes in v3:
- Add 'Reviewed-by' tag of Krzysztof Kozlowski.
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Dario Binacchi (2):
  drm: bridge: samsung-dsim: enter display mode in the enable() callback
  drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Michael Trimarchi (2):
  dt-bindings: display: panel: Add synaptics r63353 panel controller
  arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup

 .../display/panel/synaptics,r63353.yaml       |  61 +++++++++
 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++++++++++++++
 drivers/gpu/drm/bridge/samsung-dsim.c         |  14 +-
 4 files changed, 194 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi

-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Wed Dec 13 06:03:45 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Wed, 13 Dec 2023 15:03:45 +0100
Subject: [PATCH v6 4/4] arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup
In-Reply-To: <20231213140437.2769508-1-dario.binacchi@amarulasolutions.com>
References: <20231213140437.2769508-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231213140437.2769508-5-dario.binacchi@amarulasolutions.com>

From: Michael Trimarchi <michael at amarulasolutions.com>

Add the display and nodes required for its operation.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>

---

Changes in v6:
- Drop patches:
  - [06/10] drm/panel: Add Synaptics R63353 panel driver
  - [07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  - [08/10] drm/panel: Add Ilitek ILI9805 panel driver
  - [09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  Because applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)
  Drop patches:
  - [01/10] drm/bridge: Fix bridge disable logic
  - [02/10] drm/bridge: Fix a use case in the bridge disable logic
  Because they are wrong

Changes in v3:
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++++++++++++++
 2 files changed, 122 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
index 22a754d438f1..bbb07c650da9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
@@ -7,6 +7,7 @@
 /dts-v1/;
 
 #include "imx8mn.dtsi"
+#include "imx8mn-bsh-smm-s2-display.dtsi"
 
 / {
 	chosen {
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
new file mode 100644
index 000000000000..f0a924cbe548
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 BSH
+ */
+
+/ {
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm1 0 700000 0>;	/* 700000 ns = 1337Hz */
+		brightness-levels = <0 100>;
+		num-interpolated-steps = <100>;
+		default-brightness-level = <50>;
+		status = "okay";
+	};
+
+	reg_3v3_dvdd: regulator-3v3-O3 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_dvdd>;
+		regulator-name = "3v3-dvdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
+	};
+
+	reg_v3v3_avdd: regulator-3v3-O2 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_avdd>;
+		regulator-name = "3v3-avdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 5 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pwm1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_bl>;
+};
+
+&lcdif {
+	status = "okay";
+	assigned-clocks = <&clk IMX8MN_VIDEO_PLL1>;
+	assigned-clock-rates = <594000000>;
+};
+
+&pgc_dispmix {
+	assigned-clocks = <&clk IMX8MN_CLK_DISP_AXI>, <&clk IMX8MN_CLK_DISP_APB>;
+	assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_1000M>, <&clk IMX8MN_SYS_PLL1_800M>;
+	assigned-clock-rates = <500000000>, <200000000>;
+};
+
+&mipi_dsi {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+	samsung,esc-clock-frequency = <20000000>;
+	samsung,pll-clock-frequency = <12000000>;
+
+	panel at 0 {
+		compatible = "sharp,ls068b3sx02", "syna,r63353";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel>;
+		reg = <0>;
+
+		backlight = <&backlight>;
+		dvdd-supply = <&reg_3v3_dvdd>;
+		avdd-supply = <&reg_v3v3_avdd>;
+		reset-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+
+		port {
+			panel_in: endpoint {
+				remote-endpoint = <&mipi_dsi_out>;
+			};
+		};
+
+	};
+
+	ports {
+		port at 1 {
+			reg = <1>;
+			mipi_dsi_out: endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+	};
+};
+
+&gpu {
+	status = "okay";
+};
+
+&iomuxc {
+
+	/* This is for both PWM and voltage regulators for display */
+	pinctrl_bl: pwm1grp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO01_PWM1_OUT	0x16
+		>;
+	};
+
+	pinctrl_panel: panelgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_SAI3_RXC_GPIO4_IO29	0x16	/* panel reset */
+		>;
+	};
+
+	pinctrl_dvdd: dvddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x16	/* VDD 3V3_VO3 */
+		>;
+	};
+
+	pinctrl_avdd: avddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO05_GPIO1_IO5	0x16	/* VDD 3V3_VO2 */
+		>;
+	};
+};
-- 
2.43.0



From krzysztof.kozlowski at linaro.org  Wed Dec 13 06:05:57 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 15:05:57 +0100
Subject: [Patch v5 11/11] arm64: dts: fsd: Add MFC related DT enteries
In-Reply-To: <20231206063045.97234-12-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com>
 <CGME20231206063140epcas5p1ba86525117f4d9ec9172ae7cb18b7420@epcas5p1.samsung.com>
 <20231206063045.97234-12-aakarsh.jain@samsung.com>
Message-ID: <5013146f-ff8c-4462-a94e-061478268cb2@linaro.org>

On 06/12/2023 07:30, Aakarsh Jain wrote:
> Add MFC DT node and reserve memory node for MFC usage.
> 
> Cc: linux-fsd at tesla.com
> Signed-off-by: Smitha T Murthy <smithatmurthy at gmail.com>
> Signed-off-by: Aakarsh Jain <aakarsh.jain at samsung.com>
> ---

Always run checkpatch on your patches:

[Checkpatch]
WARNING: Use a single space after Cc:
#8:
Cc:  <linux-fsd at tesla.com>


Best regards,
Krzysztof



From robh at kernel.org  Wed Dec 13 06:06:44 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 13 Dec 2023 08:06:44 -0600
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <ZXmr-Kl9L2SO13--@raptor>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com> <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
 <ZXiMiLz9ZyUdxUP8@raptor> <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
 <ZXmr-Kl9L2SO13--@raptor>
Message-ID: <CAL_JsqL=P1Y6w38LD_xw+vK4CNqt22FW_FE9oi_XTLHVQEne7Q@mail.gmail.com>

On Wed, Dec 13, 2023 at 7:05?AM Alexandru Elisei
<alexandru.elisei at arm.com> wrote:
>
> Hi Rob,
>
> On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
> > <alexandru.elisei at arm.com> wrote:
> > >
> > > Hi Rob,
> > >
> > > Thank you so much for the feedback, I'm not very familiar with device tree,
> > > and any comments are very useful.
> > >
> > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > > > <alexandru.elisei at arm.com> wrote:
> > > > >
> > > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > >
> > > > > The DTB node for the tag storage region is defined as:
> > > > >
> > > > >         tags0: tag-storage at 8f8000000 {
> > > > >                 compatible = "arm,mte-tag-storage";
> > > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > > >                 block-size = <0x1000>;
> > > > >                 memory = <&memory0>;    // Associated tagged memory node
> > > > >         };
> > > >
> > > > I skimmed thru the discussion some. If this memory range is within
> > > > main RAM, then it definitely belongs in /reserved-memory.
> > >
> > > Ok, will do that.
> > >
> > > If you don't mind, why do you say that it definitely belongs in
> > > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > > motivation.
> >
> > Simply so that /memory nodes describe all possible memory and
> > /reserved-memory is just adding restrictions. It's also because
> > /reserved-memory is what gets handled early, and we don't need
> > multiple things to handle early.
> >
> > > Tag storage is not DMA and can live anywhere in memory.
> >
> > Then why put it in DT at all? The only reason CMA is there is to set
> > the size. It's not even clear to me we need CMA in DT either. The
> > reasoning long ago was the kernel didn't do a good job of moving and
> > reclaiming contiguous space, but that's supposed to be better now (and
> > most h/w figured out they need IOMMUs).
> >
> > But for tag storage you know the size as it is a function of the
> > memory size, right? After all, you are validating the size is correct.
> > I guess there is still the aspect of whether you want enable MTE or
> > not which could be done in a variety of ways.
>
> Oh, sorry, my bad, I should have been clearer about this. I don't want to
> put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.

Yes, I understand, but my point remains. Why do you need this in DT?
If the location doesn't matter and you can calculate the size from the
memory size, what else is there to add to the DT?

Rob


From krzysztof.kozlowski at linaro.org  Wed Dec 13 06:06:59 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 15:06:59 +0100
Subject: (subset) [Patch v5 11/11] arm64: dts: fsd: Add MFC related DT enteries
In-Reply-To: <20231206063045.97234-12-aakarsh.jain@samsung.com>
References: <20231206063045.97234-1-aakarsh.jain@samsung.com> <CGME20231206063140epcas5p1ba86525117f4d9ec9172ae7cb18b7420@epcas5p1.samsung.com> <20231206063045.97234-12-aakarsh.jain@samsung.com>
Message-ID: <170247641057.38939.10066985368657963484.b4-ty@linaro.org>


On Wed, 06 Dec 2023 12:00:45 +0530, Aakarsh Jain wrote:
> Add MFC DT node and reserve memory node for MFC usage.
> 
> 

Applied, thanks!

[11/11] arm64: dts: fsd: Add MFC related DT enteries
        https://git.kernel.org/krzk/linux/c/a41d9b3287b1d2d737984465e6efbf09a4fb51d2

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From ajones at ventanamicro.com  Wed Dec 13 06:08:48 2023
From: ajones at ventanamicro.com (Andrew Jones)
Date: Wed, 13 Dec 2023 15:08:48 +0100
Subject: [PATCH v4 08/11] KVM: riscv: selftests: Add guest helper to get
 vcpu id
In-Reply-To: <02f6c9ccaaeb4ceb67137863e0317f62cef62496.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
 <02f6c9ccaaeb4ceb67137863e0317f62cef62496.1702371136.git.haibo1.xu@intel.com>
Message-ID: <20231213-b02db86aaf7957be22b200f1@orel>

On Tue, Dec 12, 2023 at 05:31:17PM +0800, Haibo Xu wrote:
> Add guest_get_vcpuid() helper to simplify accessing to per-cpu
> private data. The sscratch CSR was used to store the vcpu id.
> 
> Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
> Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
> ---
>  tools/testing/selftests/kvm/include/aarch64/processor.h | 4 ----
>  tools/testing/selftests/kvm/include/kvm_util_base.h     | 9 +++++++++
>  tools/testing/selftests/kvm/lib/riscv/processor.c       | 8 ++++++++
>  3 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/testing/selftests/kvm/include/aarch64/processor.h b/tools/testing/selftests/kvm/include/aarch64/processor.h
> index c42d683102c7..16ae0ac01879 100644
> --- a/tools/testing/selftests/kvm/include/aarch64/processor.h
> +++ b/tools/testing/selftests/kvm/include/aarch64/processor.h
> @@ -226,8 +226,4 @@ void smccc_smc(uint32_t function_id, uint64_t arg0, uint64_t arg1,
>  	       uint64_t arg2, uint64_t arg3, uint64_t arg4, uint64_t arg5,
>  	       uint64_t arg6, struct arm_smccc_res *res);
>  
> -
> -
> -uint32_t guest_get_vcpuid(void);
> -
>  #endif /* SELFTEST_KVM_PROCESSOR_H */
> diff --git a/tools/testing/selftests/kvm/include/kvm_util_base.h b/tools/testing/selftests/kvm/include/kvm_util_base.h
> index a18db6a7b3cf..666438113d22 100644
> --- a/tools/testing/selftests/kvm/include/kvm_util_base.h
> +++ b/tools/testing/selftests/kvm/include/kvm_util_base.h
> @@ -932,4 +932,13 @@ void kvm_selftest_arch_init(void);
>  
>  void kvm_arch_vm_post_create(struct kvm_vm *vm);
>  
> +void vm_init_vector_tables(struct kvm_vm *vm);
> +void vcpu_init_vector_tables(struct kvm_vcpu *vcpu);
> +
> +struct ex_regs;
> +typedef void(*exception_handler_fn)(struct ex_regs *);
> +void vm_install_exception_handler(struct kvm_vm *vm, int vector, exception_handler_fn handler);

I think something happend on rebase since the above should be in a
different patch (and were for v3). I suggest checking your previous
and current version branches with git-range-diff after rebasing in
order to catch stuff like this.

Thanks,
drew

> +
> +uint32_t guest_get_vcpuid(void);
> +
>  #endif /* SELFTEST_KVM_UTIL_BASE_H */
> diff --git a/tools/testing/selftests/kvm/lib/riscv/processor.c b/tools/testing/selftests/kvm/lib/riscv/processor.c
> index efd9ac4b0198..39a1e9902dec 100644
> --- a/tools/testing/selftests/kvm/lib/riscv/processor.c
> +++ b/tools/testing/selftests/kvm/lib/riscv/processor.c
> @@ -316,6 +316,9 @@ struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, uint32_t vcpu_id,
>  	vcpu_set_reg(vcpu, RISCV_CORE_REG(regs.sp), stack_vaddr + stack_size);
>  	vcpu_set_reg(vcpu, RISCV_CORE_REG(regs.pc), (unsigned long)guest_code);
>  
> +	/* Setup sscratch for guest_get_vcpuid() */
> +	vcpu_set_reg(vcpu, RISCV_CSR_REG(sscratch), vcpu_id);
> +
>  	/* Setup default exception vector of guest */
>  	vcpu_set_reg(vcpu, RISCV_CSR_REG(stvec), (unsigned long)guest_unexp_trap);
>  
> @@ -436,3 +439,8 @@ void vm_install_interrupt_handler(struct kvm_vm *vm, exception_handler_fn handle
>  
>  	handlers->exception_handlers[1][0] = handler;
>  }
> +
> +uint32_t guest_get_vcpuid(void)
> +{
> +	return csr_read(CSR_SSCRATCH);
> +}
> -- 
> 2.34.1
> 


From ardb at kernel.org  Wed Dec 13 06:09:54 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Wed, 13 Dec 2023 15:09:54 +0100
Subject: [PATCH v7 5/7] arm64: vmemmap: Avoid base2 order of struct page
 size to dimension region
In-Reply-To: <ZXm2c5_oA5rPrfm8@FVFF77S0Q05N>
References: <20231213084024.2367360-9-ardb@google.com> <20231213084024.2367360-14-ardb@google.com>
 <ZXm2c5_oA5rPrfm8@FVFF77S0Q05N>
Message-ID: <CAMj1kXHTPYrmBx3Zbd5aceAnB-yDhh5gC+Nt8n2VjhY2hcbeEw@mail.gmail.com>

On Wed, 13 Dec 2023 at 14:49, Mark Rutland <mark.rutland at arm.com> wrote:
>
> Hi Ard,
>
> On Wed, Dec 13, 2023 at 09:40:30AM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb at kernel.org>
> >
> > The placement and size of the vmemmap region in the kernel virtual
> > address space is currently derived from the base2 order of the size of a
> > struct page. This makes for nicely aligned constants with lots of
> > leading 0xf and trailing 0x0 digits, but given that the actual struct
> > pages are indexed as an ordinary array, this resulting region is
> > severely overdimensioned when the size of a struct page is just over a
> > power of 2.
> >
> > This doesn't matter today, but once we enable 52-bit virtual addressing
> > for 4k pages configurations, the vmemmap region may take up almost half
> > of the upper VA region with the current struct page upper bound at 64
> > bytes. And once we enable KMSAN or other features that push the size of
> > a struct page over 64 bytes, we will run out of VMALLOC space entirely.
> >
> > So instead, let's derive the region size from the actual size of a
> > struct page, and place the entire region 1 GB from the top of the VA
> > space, where it still doesn't share any lower level translation table
> > entries with the fixmap.
> >
> > Acked-by: Mark Rutland <mark.rutland at arm.com>
> > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > ---
> >  arch/arm64/include/asm/memory.h | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index 2745bed8ae5b..b49575a92afc 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -30,8 +30,8 @@
> >   * keep a constant PAGE_OFFSET and "fallback" to using the higher end
> >   * of the VMEMMAP where 52-bit support is not available in hardware.
> >   */
> > -#define VMEMMAP_SHIFT        (PAGE_SHIFT - STRUCT_PAGE_MAX_SHIFT)
> > -#define VMEMMAP_SIZE ((_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) >> VMEMMAP_SHIFT)
> > +#define VMEMMAP_RANGE        (_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET)
> > +#define VMEMMAP_SIZE ((VMEMMAP_RANGE >> PAGE_SHIFT) * sizeof(struct page))
> >
> >  /*
> >   * PAGE_OFFSET - the virtual address of the start of the linear map, at the
> > @@ -47,8 +47,8 @@
> >  #define MODULES_END          (MODULES_VADDR + MODULES_VSIZE)
> >  #define MODULES_VADDR                (_PAGE_END(VA_BITS_MIN))
> >  #define MODULES_VSIZE                (SZ_2G)
> > -#define VMEMMAP_START                (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
> > -#define VMEMMAP_END          (VMEMMAP_START + VMEMMAP_SIZE)
> > +#define VMEMMAP_START                (VMEMMAP_END - VMEMMAP_SIZE)
> > +#define VMEMMAP_END          (-UL(SZ_1G))
> >  #define PCI_IO_START         (VMEMMAP_END + SZ_8M)
> >  #define PCI_IO_END           (PCI_IO_START + PCI_IO_SIZE)
> >  #define FIXADDR_TOP          (-UL(SZ_8M))
>
> I realise I've acked this already, but my big concern here is still that it's
> hard to see why these don't overlap (though the assert in fixmap.c will save
> us). Usually we try to make that clear by construction, and I think we can do
> that here with something like:
>
> | #define GUARD_VA_SIZE          (UL(SZ_8M))
> |
> | #define FIXADDR_TOP            (-GUARD_VA_SIZE)
> | #define FIXADDR_SIZE_MAX       SZ_8M
> | #define FIXADDR_START_MIN      (FIXADDR_TOP - FIXADDR_SIZE_MAX)
> |
> | #define PCI_IO_END             (FIXADDR_START_MIN - GUARD_VA_SIZE)
> | #define PCI_IO_START           (PCI_IO_END - PCI_IO_SIZE)
> |
> | #define VMEMMAP_END            (ALIGN_DOWN(PCI_IO_START - GUARD_VA_SIZE, SZ_1G))
> | #define VMEMMAP_START          (VMEMMAP_END - VMEMMAP_SIZE)
>
> ... and in fixmap.h have:
>
> /* Ensure the estimate in memory.h was big enough */
> static_assert(FIXADDR_SIZE_MAX > FIXADDR_SIZE);
>
> I might be missing some reason why we can't do that; I locally tried the above
> atop this series with defconfig+4K and defcconfig+64K, and both build and boot
> without sisue.
>

I am really struggling to understand what the issue is that you are
trying to solve here.

What I am proposing is

#define VMEMMAP_END          (-UL(SZ_1G))
#define PCI_IO_START         (VMEMMAP_END + SZ_8M)
#define PCI_IO_END           (PCI_IO_START + PCI_IO_SIZE)
#define FIXADDR_TOP          (-UL(SZ_8M))

and in fixmap.c

static_assert(FIXADDR_TOT_START > PCI_IO_END);

(which sadly has to live outside of asm/memory.h for reasons of #include hell).

This leaves the top 1G for PCI I/O plus fixmap, and ensures that the
latter does not collide with the former.

> Other than that, the series looks good to me.
>

Thanks.

> If you're happy with the above I can go spin that as a patch to apply atop.
>

I won't object to that but I can't say I am convinced of the need.

Thanks,


From christian.koenig at amd.com  Wed Dec 13 05:59:28 2023
From: christian.koenig at amd.com (=?UTF-8?Q?Christian_K=C3=B6nig?=)
Date: Wed, 13 Dec 2023 14:59:28 +0100
Subject: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
In-Reply-To: <20231213132229.q3uxdhtdsxuzw3w6@pop-os.localdomain>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
 <DPBmATfmfvSP8Cwjz99kj_JvCEiAqRfuMFJZEBF2aIgl8NZqWFR66eyPTX1E8bHyOlimBihEE3E80p9bfOJ-0SNu8pwoIzL9gD2Xae6r97g=@emersion.fr>
 <20231213110517.6ce36aca@eldfell>
 <20231213101549.lioqfzjxcvmqxqu3@pop-os.localdomain>
 <20231213133825.0a329864@eldfell>
 <20231213132229.q3uxdhtdsxuzw3w6@pop-os.localdomain>
Message-ID: <f2f2b676-295d-4792-a26d-7fafb7340f36@amd.com>

Am 13.12.23 um 14:22 schrieb Joakim Bech:
> On Wed, Dec 13, 2023 at 01:38:25PM +0200, Pekka Paalanen wrote:
>> On Wed, 13 Dec 2023 11:15:49 +0100
>> Joakim Bech <joakim.bech at linaro.org> wrote:
>>
>>> On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:
>>>> On Tue, 12 Dec 2023 16:36:35 +0000
>>>> Simon Ser <contact at emersion.fr> wrote:
>>>>    
>>>>> Is there a chance to pick a better name than "secure" here?
>>>>>
>>>>> "Secure" is super overloaded, it's not clear at all what it means from
>>>>> just the name. Something like "restricted" would be an improvement.
>>>>>    
>>>> My thoughts exactly. Every time I see "secure" used for something that
>>>> either gives you garbage, refuses to work, or crashes your whole machine
>>>> *intentionally* when you try to do normal usual things to it in
>>>> userspace (like use it for GL texturing, or try to use KMS writeback), I
>>>> get an unscratchable itch.
>>>>
>>>> There is nothing "secure" from security perspective there for end users
>>>> and developers. It's just inaccessible buffers.
>>>>
>>>> I've been biting my lip until now, thinking it's too late.
>>>>    
>>> The characteristics we're looking for here is a buffer where the content
>>> is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
>>> EL2. I.e, the content of the buffer is meant to be used and accessible
>>> primarily by the secure side and other devices that has been granted
>> s/secure side/proprietary side/
>>
> I'm using the nomenclature as written by Arm (other architectures have
> other names for their secure execution states).

AMDs GPUs call that "trusted" which is only minimal better than secure I 
think.

>
>> I presume nothing of the other side can ever be in any way open?
>>
> I'm sure there are lots of examples of things running on the secure side
> that are open. The OP-TEE project where I'm a maintainer has been fully
> open source since 2014, to give one example that I'm familiar with
> myself.

On AMDs GPUs you can actually write shaders which works with the trusted 
data and can read and write.

What is prevented is that you copy the data outside of the trusted zone, 
e.g. to the CPU. When you do this you only get garbage.

Only engines which have the proper decryption key can send out the data 
(for example) to a display device which has authenticated itself using HDCP.

Just a few infos how this is done elsewhere.

Cheers,
Christian.

>
>> Maybe the other side is even less secure than the FOSS side...
>>
>>> access to it (for example decoders, display controllers if we're talking
>>> about video use cases). However, since the use cases for this exercises
>>> the whole stack, from non-secure user space (EL0) all the way to secure
>>> user space (S-EL0), with various devices needing access to the buffer at
>>> various times, it makes sense to let Linux manage the buffers, although
>>> it still cannot access the content. That's the overall context.
>> Yes, we know all this (except for the exact meaning of EL0 etc.).
>>
> Great!
>
>>> As for the name, it's always difficult to find a name suitable precisely
>>> describing what it is. "Secure" is perhaps vague, but it might still a
>>> good choice, if you carefully describe what secure means for this
>>> particular heap (in the source code and the documentation for it). For
>> Carefully describe, as in, re-define.
>>
>>> example, the definition of "secure" for a secure heap as here could mean
>>> that buffer content is inaccessible to the host OS and user space
>>> running in normal world (using Arm nomenclature). I wouldn't have any
>>> problems with calling it secure if, as said it's defined what we mean by
>>> saying so. But I'm all ears for other suggestions as well.
>>>
>>> Safe, protected, shielded, unreachable, isolated, inaccessible,
>>> unaccessible, fortified, ... would any of these make more sense?
>> "Restricted" sounds like a good compromise to me. The buffers' usage is
>> severely restricted.
>>
> Yes, restricted isn't a bad choice. We would still need to describe what
> we mean by saying it's restricted, i.e., what is it restricted from,
> since I'd guess that "restricted" by itself also could be a bit open
> ended for a lot of people.
>
>> It is the opposite of "safe", because accessing the contents the wrong
>> way can return garbage or intentionally crash the whole system,
>> depending on the hardware implementation. One example is attempting to
>> put such a buffer on a KMS plane while the connector HDCP state is not
>> high enough, or a writeback connector is connected to the CRTC. It is
>> really fragile. (Do KMS drivers fail an atomic commit that would
>> violate the heap rules? Somehow I doubt that, who'd even know what the
>> rules are.)
>>
> I believe one of the goals with reviewing the patches is to highlight
> issues like this and try to figure out how to avoid ending up in
> situations like what you described by suggesting alternative solutions
> and ideas.
>
>> It is protected/shielded/fortified from all the kernel and userspace,
>> but a more familiar word to describe that is inaccessible.
>> "Inaccessible buffer" per se OTOH sounds like a useless concept.
>>
>> It is not secure, because it does not involve security in any way. In
>> fact, given it's so fragile, I'd classify it as mildly opposite of
>> secure, as e.g. clients of a Wayland compositor can potentially DoS the
>> compositor with it by simply sending such a dmabuf. Or DoS the whole
>> system.
>>
> I hear what you are saying and DoS is a known problem and attack vector,
> but regardless, we have use cases where we don't want to expose
> information in the clear and where we also would like to have some
> guarantees about correctness. That is where various secure elements and
> more generally security is needed.
>
> So, it sounds like we have two things here, the first is the naming and
> the meaning behind it. I'm pretty sure the people following and
> contributing to this thread can agree on a name that makes sense. Would
> you personally be OK with "restricted" as the name? It sounds like that.
>
> The other thing is the feature and functionality itself offered by this
> patch series. My impression from reading your replies is that you think
> this is the wrong approach. If my impression is correct, what would you
> suggest as an alternative approach?
>
>> "Poisonous heap" would be fitting but politically inappropriate I
>> guess. After all, "poison" is data that is not meant to be read by
>> anything normal.
>>
>>
>> Thanks,
>> pq



From ppaalanen at gmail.com  Wed Dec 13 06:16:14 2023
From: ppaalanen at gmail.com (Pekka Paalanen)
Date: Wed, 13 Dec 2023 16:16:14 +0200
Subject: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
In-Reply-To: <20231213132229.q3uxdhtdsxuzw3w6@pop-os.localdomain>
References: <20231212024607.3681-1-yong.wu@mediatek.com>
	<DPBmATfmfvSP8Cwjz99kj_JvCEiAqRfuMFJZEBF2aIgl8NZqWFR66eyPTX1E8bHyOlimBihEE3E80p9bfOJ-0SNu8pwoIzL9gD2Xae6r97g=@emersion.fr>
	<20231213110517.6ce36aca@eldfell>
	<20231213101549.lioqfzjxcvmqxqu3@pop-os.localdomain>
	<20231213133825.0a329864@eldfell>
	<20231213132229.q3uxdhtdsxuzw3w6@pop-os.localdomain>
Message-ID: <20231213161614.43e5bca8@eldfell>

On Wed, 13 Dec 2023 14:22:29 +0100
Joakim Bech <joakim.bech at linaro.org> wrote:

> On Wed, Dec 13, 2023 at 01:38:25PM +0200, Pekka Paalanen wrote:
> > On Wed, 13 Dec 2023 11:15:49 +0100
> > Joakim Bech <joakim.bech at linaro.org> wrote:
> >   
> > > On Wed, Dec 13, 2023 at 11:05:17AM +0200, Pekka Paalanen wrote:  
> > > > On Tue, 12 Dec 2023 16:36:35 +0000
> > > > Simon Ser <contact at emersion.fr> wrote:
> > > >     
> > > > > Is there a chance to pick a better name than "secure" here?
> > > > > 
> > > > > "Secure" is super overloaded, it's not clear at all what it means from
> > > > > just the name. Something like "restricted" would be an improvement.
> > > > >     
> > > > 
> > > > My thoughts exactly. Every time I see "secure" used for something that
> > > > either gives you garbage, refuses to work, or crashes your whole machine
> > > > *intentionally* when you try to do normal usual things to it in
> > > > userspace (like use it for GL texturing, or try to use KMS writeback), I
> > > > get an unscratchable itch.
> > > > 
> > > > There is nothing "secure" from security perspective there for end users
> > > > and developers. It's just inaccessible buffers.
> > > > 
> > > > I've been biting my lip until now, thinking it's too late.
> > > >     
> > > The characteristics we're looking for here is a buffer where the content
> > > is inaccessible to the normal OS and user space, i.e., Non-secure EL0 to
> > > EL2. I.e, the content of the buffer is meant to be used and accessible
> > > primarily by the secure side and other devices that has been granted  
> > 
> > s/secure side/proprietary side/
> >   
> I'm using the nomenclature as written by Arm (other architectures have
> other names for their secure execution states).
> 
> > I presume nothing of the other side can ever be in any way open?
> >   
> I'm sure there are lots of examples of things running on the secure side
> that are open. The OP-TEE project where I'm a maintainer has been fully
> open source since 2014, to give one example that I'm familiar with
> myself.

Oh, I didn't realise there were FOSS implementations of the other side
that tie in with this secure/restricted heap here. Sorry.

I think the patch series cover letter should point to those to give a
view of the other side to the reviewers, just like DRM requires
userspace to be open for new UAPI.

> > Maybe the other side is even less secure than the FOSS side...
> >   
> > > access to it (for example decoders, display controllers if we're talking
> > > about video use cases). However, since the use cases for this exercises
> > > the whole stack, from non-secure user space (EL0) all the way to secure
> > > user space (S-EL0), with various devices needing access to the buffer at
> > > various times, it makes sense to let Linux manage the buffers, although
> > > it still cannot access the content. That's the overall context.  
> > 
> > Yes, we know all this (except for the exact meaning of EL0 etc.).
> >   
> Great!
> 
> > > As for the name, it's always difficult to find a name suitable precisely
> > > describing what it is. "Secure" is perhaps vague, but it might still a
> > > good choice, if you carefully describe what secure means for this
> > > particular heap (in the source code and the documentation for it). For  
> > 
> > Carefully describe, as in, re-define.
> >   
> > > example, the definition of "secure" for a secure heap as here could mean
> > > that buffer content is inaccessible to the host OS and user space
> > > running in normal world (using Arm nomenclature). I wouldn't have any
> > > problems with calling it secure if, as said it's defined what we mean by
> > > saying so. But I'm all ears for other suggestions as well.
> > > 
> > > Safe, protected, shielded, unreachable, isolated, inaccessible,
> > > unaccessible, fortified, ... would any of these make more sense?  
> > 
> > "Restricted" sounds like a good compromise to me. The buffers' usage is
> > severely restricted.
> >   
> Yes, restricted isn't a bad choice. We would still need to describe what
> we mean by saying it's restricted, i.e., what is it restricted from,
> since I'd guess that "restricted" by itself also could be a bit open
> ended for a lot of people.

Yes, but "restricted" also does not give out an immediate wrong
impression. Label something as "secure", and it immediately raises the
questions of what kind of attacks it prevents and how can I make use of
it.

Is there any use of restricted buffers outside of Digital Rights
Management though? Could a private person somehow make use of it to
protect their own contents? Like a photographer sending drafts to a
customer while not wanting give out any digital copies?

If not, then restricted buffers are something people would generally
like to avoid, not embrace. "Secure" gives a positive impression,
"restricted" a negative impression.

> > It is the opposite of "safe", because accessing the contents the wrong
> > way can return garbage or intentionally crash the whole system,
> > depending on the hardware implementation. One example is attempting to
> > put such a buffer on a KMS plane while the connector HDCP state is not
> > high enough, or a writeback connector is connected to the CRTC. It is
> > really fragile. (Do KMS drivers fail an atomic commit that would
> > violate the heap rules? Somehow I doubt that, who'd even know what the
> > rules are.)
> >   
> I believe one of the goals with reviewing the patches is to highlight
> issues like this and try to figure out how to avoid ending up in
> situations like what you described by suggesting alternative solutions
> and ideas.
> 
> > It is protected/shielded/fortified from all the kernel and userspace,
> > but a more familiar word to describe that is inaccessible.
> > "Inaccessible buffer" per se OTOH sounds like a useless concept.
> > 
> > It is not secure, because it does not involve security in any way. In
> > fact, given it's so fragile, I'd classify it as mildly opposite of
> > secure, as e.g. clients of a Wayland compositor can potentially DoS the
> > compositor with it by simply sending such a dmabuf. Or DoS the whole
> > system.
> >   
> I hear what you are saying and DoS is a known problem and attack vector,
> but regardless, we have use cases where we don't want to expose
> information in the clear and where we also would like to have some
> guarantees about correctness. That is where various secure elements and
> more generally security is needed.
> 
> So, it sounds like we have two things here, the first is the naming and
> the meaning behind it. I'm pretty sure the people following and
> contributing to this thread can agree on a name that makes sense. Would
> you personally be OK with "restricted" as the name? It sounds like that.

I would. I'm also just a by-stander, not a maintainer of kernel
anything. I have no power to accept nor reject anything here.

> The other thing is the feature and functionality itself offered by this
> patch series. My impression from reading your replies is that you think
> this is the wrong approach. If my impression is correct, what would you
> suggest as an alternative approach?

I just generally dislike locking people out of what their systems hold,
but I also understand why extremely big companies want this Digital
Rights Management technology for their business model. If Linux does
not support that business model, they and the whole broadcast industry
might use something else. At least it pays for kernel developers who
can hopefully do some genuinely useful work on the side as well,
benefiting the community.

Let's just be honest about what is what.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/d33dc940/attachment-0001.sig>

From ajones at ventanamicro.com  Wed Dec 13 06:18:14 2023
From: ajones at ventanamicro.com (Andrew Jones)
Date: Wed, 13 Dec 2023 15:18:14 +0100
Subject: [PATCH v4 10/11] KVM: riscv: selftests: Add sstc timer test
In-Reply-To: <3bb7d5ae5a1a016e970faa0759c47214c9391b19.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
 <3bb7d5ae5a1a016e970faa0759c47214c9391b19.1702371136.git.haibo1.xu@intel.com>
Message-ID: <20231213-4ba5fcc75b41cd19ec96f08e@orel>

On Tue, Dec 12, 2023 at 05:31:19PM +0800, Haibo Xu wrote:
> Add a KVM selftests to validate the Sstc timer functionality.
> The test was ported from arm64 arch timer test.
> 
> Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
> ---
>  tools/testing/selftests/kvm/Makefile          |   1 +
>  .../selftests/kvm/aarch64/arch_timer.c        |  12 +-
>  tools/testing/selftests/kvm/arch_timer.c      |  10 +-
>  .../selftests/kvm/include/riscv/arch_timer.h  |  71 ++++++++++++
>  .../selftests/kvm/include/riscv/processor.h   |  10 ++
>  .../selftests/kvm/include/timer_test.h        |   5 +-
>  .../testing/selftests/kvm/riscv/arch_timer.c  | 107 ++++++++++++++++++
>  7 files changed, 206 insertions(+), 10 deletions(-)
>  create mode 100644 tools/testing/selftests/kvm/include/riscv/arch_timer.h
>  create mode 100644 tools/testing/selftests/kvm/riscv/arch_timer.c
>

Reviewed-by: Andrew Jones <ajones at ventanamicro.com>


From leo.yan at linaro.org  Wed Dec 13 06:24:14 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Wed, 13 Dec 2023 22:24:14 +0800
Subject: [PATCH V2 1/5] perf mem: Add mem_events into the supported
 perf_pmu
In-Reply-To: <ee9db34a-2b3d-46b3-ba36-22a22b080d70@linux.intel.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-2-kan.liang@linux.intel.com>
 <20231208102922.GB769184@leoy-huanghe.lan>
 <98863f44-4a35-4910-8db0-dbbf0474f6ae@linux.intel.com>
 <20231209063440.GE2116834@leoy-yangtze.lan>
 <ee9db34a-2b3d-46b3-ba36-22a22b080d70@linux.intel.com>
Message-ID: <20231213142414.GH86143@leoy-huanghe.lan>

On Mon, Dec 11, 2023 at 02:01:37PM -0500, Liang, Kan wrote:

[...]

> > I will hold on a bit for the test until this patch set addresses the
> > concern for the breakage issues on Arm64. Please check my review in
> > other replies.
> 
> The reviews in the other replies don't look like break any current usage
> on Arm64. I think the breakage issue is what you described in this
> patch, right?

I mentioned the breakage is in the patch 04, but I think the concern
is dismissed.

> If we move the check of "arm_spe_0" to arch/arm/util/pmu.c, it seems we
> have to move the perf_mem_events_arm[] into arch/arm/util/mem-events.c
> as well. Is it OK?

No.  For fixing Arm64 building, please refer:

https://termbin.com/0dkn

> I'm not familiar with ARM and have no idea how those events are
> organized under arm64 and arm. Could you please send a fix for the
> building failure on aarch64? I will fold it into the V3.

After apply the change in above link on the top of your patch set,
it can build successfully at my side. Hope it's helpful.

Thanks,
Leo


> 
> Thanks,
> Kan
> > 
> > Thanks,
> > Leo
> > 


From ajones at ventanamicro.com  Wed Dec 13 06:27:53 2023
From: ajones at ventanamicro.com (Andrew Jones)
Date: Wed, 13 Dec 2023 15:27:53 +0100
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us
 in arch timer test
In-Reply-To: <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
 <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
Message-ID: <20231213-e11bcfdf39a34099bbc48cea@orel>

On Tue, Dec 12, 2023 at 05:31:20PM +0800, Haibo Xu wrote:
> There are intermittent failures occured when stressing the
> arch-timer test in a Qemu VM:
> 
>  Guest assert failed,  vcpu 0; stage; 4; iter: 3
>  ==== Test Assertion Failure ====
>    aarch64/arch_timer.c:196: config_iter + 1 == irq_iter
>    pid=4048 tid=4049 errno=4 - Interrupted system call
>       1  0x000000000040253b: test_vcpu_run at arch_timer.c:248
>       2  0x0000ffffb60dd5c7: ?? ??:0
>       3  0x0000ffffb6145d1b: ?? ??:0
>    0x3 != 0x2 (config_iter + 1 != irq_iter)e
> 
> Further test and debug show that the timeout for an interrupt
> to arrive do have random high fluctuation, espectially when
> testing in an virtual environment.
> 
> To alleviate this issue, just expose the timeout value as user
> configurable and print some hint message to increase the value
> when hitting the failure..
> 
> Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
> ---
>  .../selftests/kvm/aarch64/arch_timer.c        |  8 +++++--
>  tools/testing/selftests/kvm/arch_timer.c      | 22 +++++++++++++------
>  .../selftests/kvm/include/timer_test.h        |  1 +
>  .../testing/selftests/kvm/riscv/arch_timer.c  |  8 +++++--
>  4 files changed, 28 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/testing/selftests/kvm/aarch64/arch_timer.c b/tools/testing/selftests/kvm/aarch64/arch_timer.c
> index 4b421d421c3f..139eecbf77e7 100644
> --- a/tools/testing/selftests/kvm/aarch64/arch_timer.c
> +++ b/tools/testing/selftests/kvm/aarch64/arch_timer.c
> @@ -131,10 +131,14 @@ static void guest_run_stage(struct test_vcpu_shared_data *shared_data,
>  
>  		/* Setup a timeout for the interrupt to arrive */
>  		udelay(msecs_to_usecs(test_args.timer_period_ms) +
> -			TIMER_TEST_ERR_MARGIN_US);
> +			test_args.timer_err_margin_us);
>  
>  		irq_iter = READ_ONCE(shared_data->nr_iter);
> -		GUEST_ASSERT_EQ(config_iter + 1, irq_iter);
> +		__GUEST_ASSERT(config_iter + 1 == irq_iter,
> +			"config_iter + 1 = 0x%lx, irq_iter = 0x%lx.\n"
> +			"  Guest timer interrupt was not trigged within the specified\n"
> +			"  interval, try to increase the error margin by [-e] option.\n",
> +			config_iter + 1, irq_iter);
>  	}
>  }
>  
> diff --git a/tools/testing/selftests/kvm/arch_timer.c b/tools/testing/selftests/kvm/arch_timer.c
> index 60963fce16f2..5050022fd345 100644
> --- a/tools/testing/selftests/kvm/arch_timer.c
> +++ b/tools/testing/selftests/kvm/arch_timer.c
> @@ -5,16 +5,17 @@
>   * The guest's main thread configures the timer interrupt and waits
>   * for it to fire, with a timeout equal to the timer period.
>   * It asserts that the timeout doesn't exceed the timer period plus
> - * an error margin of 100us.
> + * an user configurable error margin(default to 100us).
>   *
>   * On the other hand, upon receipt of an interrupt, the guest's interrupt
>   * handler validates the interrupt by checking if the architectural state
>   * is in compliance with the specifications.
>   *
>   * The test provides command-line options to configure the timer's
> - * period (-p), number of vCPUs (-n), and iterations per stage (-i).
> - * To stress-test the timer stack even more, an option to migrate the
> - * vCPUs across pCPUs (-m), at a particular rate, is also provided.
> + * period (-p), number of vCPUs (-n), iterations per stage (-i), and timer
> + * interrupt arrival error margin (-e). To stress-test the timer stack even
> + * more, an option to migrate the vCPUs across pCPUs (-m), at a particular
> + * rate, is also provided.
>   *
>   * Copyright (c) 2021, Google LLC.
>   */
> @@ -34,6 +35,7 @@ struct test_args test_args = {
>  	.nr_iter = NR_TEST_ITERS_DEF,
>  	.timer_period_ms = TIMER_TEST_PERIOD_MS_DEF,
>  	.migration_freq_ms = TIMER_TEST_MIGRATION_FREQ_MS,
> +	.timer_err_margin_us = TIMER_TEST_ERR_MARGIN_US,
>  	.reserved = 1,
>  };
>  
> @@ -179,8 +181,9 @@ static void test_run(struct kvm_vm *vm)
>  
>  static void test_print_help(char *name)
>  {
> -	pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n",
> -		name);
> +	pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n"
> +	        "\t\t    [-m migration_freq_ms] [-o counter_offset]\n"
> +	        "\t\t    [-e timer_err_margin_us]\n", name);
>  	pr_info("\t-n: Number of vCPUs to configure (default: %u; max: %u)\n",
>  		NR_VCPUS_DEF, KVM_MAX_VCPUS);
>  	pr_info("\t-i: Number of iterations per stage (default: %u)\n",
> @@ -190,6 +193,8 @@ static void test_print_help(char *name)
>  	pr_info("\t-m: Frequency (in ms) of vCPUs to migrate to different pCPU. 0 to turn off (default: %u)\n",
>  		TIMER_TEST_MIGRATION_FREQ_MS);
>  	pr_info("\t-o: Counter offset (in counter cycles, default: 0) [aarch64-only]\n");
> +	pr_info("\t-e: Interrupt arrival error margin(in us) of the guest timer (default: %u)\n",
                                                     ^ need space here

> +		TIMER_TEST_ERR_MARGIN_US);
>  	pr_info("\t-h: print this help screen\n");
>  }
>  
> @@ -197,7 +202,7 @@ static bool parse_args(int argc, char *argv[])
>  {
>  	int opt;
>  
> -	while ((opt = getopt(argc, argv, "hn:i:p:m:o:")) != -1) {
> +	while ((opt = getopt(argc, argv, "hn:i:p:m:o:e:")) != -1) {
>  		switch (opt) {
>  		case 'n':
>  			test_args.nr_vcpus = atoi_positive("Number of vCPUs", optarg);
> @@ -216,6 +221,9 @@ static bool parse_args(int argc, char *argv[])
>  		case 'm':
>  			test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
>  			break;
> +		case 'e':
> +			test_args.timer_err_margin_us = atoi_non_negative("Error Margin", optarg);
> +			break;
>  		case 'o':
>  			test_args.counter_offset = strtol(optarg, NULL, 0);
>  			test_args.reserved = 0;
> diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
> index 968257b893a7..b1d405e7157d 100644
> --- a/tools/testing/selftests/kvm/include/timer_test.h
> +++ b/tools/testing/selftests/kvm/include/timer_test.h
> @@ -22,6 +22,7 @@ struct test_args {
>  	int nr_iter;
>  	int timer_period_ms;
>  	int migration_freq_ms;
> +	int timer_err_margin_us;
>  	/* Members of struct kvm_arm_counter_offset */
>  	uint64_t counter_offset;
>  	uint64_t reserved;
> diff --git a/tools/testing/selftests/kvm/riscv/arch_timer.c b/tools/testing/selftests/kvm/riscv/arch_timer.c
> index 13bf184d1ff5..45a139dc7ce3 100644
> --- a/tools/testing/selftests/kvm/riscv/arch_timer.c
> +++ b/tools/testing/selftests/kvm/riscv/arch_timer.c
> @@ -55,10 +55,14 @@ static void guest_run(struct test_vcpu_shared_data *shared_data)
>  
>  		/* Setup a timeout for the interrupt to arrive */
>  		udelay(msecs_to_usecs(test_args.timer_period_ms) +
> -			TIMER_TEST_ERR_MARGIN_US);
> +			test_args.timer_err_margin_us);
>  
>  		irq_iter = READ_ONCE(shared_data->nr_iter);
> -		GUEST_ASSERT_EQ(config_iter + 1, irq_iter);
> +		__GUEST_ASSERT(config_iter + 1 == irq_iter,
> +			"config_iter + 1 = 0x%lx, irq_iter = 0x%lx.\n"
> +			"  Guest timer interrupt was not trigged within the specified\n"
> +			"  interval, try to increase the error margin by [-e] option.\n",
> +			config_iter + 1, irq_iter);
>  	}
>  }
>  
> -- 
> 2.34.1
>

I probably would have started the series with this patch since you said
you could reproduce the problem on aarch64. Starting the series with
this patch would allow just this patch to get picked up to fix aarch64,
if that's necessary, and also avoids touching a couple places twice
with the code split for riscv.

But anyway, other than the missing space in the help text,

Reviewed-by: Andrew Jones <ajones at ventanamicro.com>

Thanks,
drew


From chunkuang.hu at kernel.org  Wed Dec 13 06:28:09 2023
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Wed, 13 Dec 2023 22:28:09 +0800
Subject: [PATCH v11 14/23] drm/mediatek: Power on/off devices with
 function pointers
In-Reply-To: <20231024130048.14749-15-shawn.sung@mediatek.com>
References: <20231024130048.14749-1-shawn.sung@mediatek.com> <20231024130048.14749-15-shawn.sung@mediatek.com>
Message-ID: <CAAOTY_-6bbE394ViQfyXg7zNv+uFygj70eF9dG+QDoSgELOFYg@mail.gmail.com>

Hi, Hsiao-chien:

Hsiao Chien Sung <shawn.sung at mediatek.com> ? 2023?10?24? ?? ??9:01???
>
> Different from OVL, OVL adaptor is a pseudo device so we didn't
> define it in the device tree, consequently, pm_runtime_resume_and_get()
> called by .atomic_enable() powers on no device. For this reason, we
> implement a function to power on the RDMAs in OVL adaptor, and the
> system will make sure the IOMMUs are powered on as well because of the
> device link (iommus) in the RDMA nodes in DTS.
>
> This patch separates power and clock management process, it would be
> easier to maintain and add extensions.

There is conflict while apply this patch into latest kernel. Please
rebase this series onto latest kernel and send next version patches.

Regards,
Chun-Kuang.

>
> Reviewed-by: CK Hu <ck.hu at mediatek.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_drv.h       |  4 +
>  .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 75 +++++++++++++++----
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c       | 10 +--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |  2 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   | 20 +++++
>  drivers/gpu/drm/mediatek/mtk_mdp_rdma.c       | 16 ++++
>  6 files changed, 107 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index bf06ccb65652..8465beeab435 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -109,6 +109,8 @@ void mtk_ovl_adaptor_connect(struct device *dev, struct device *mmsys_dev,
>                              unsigned int next);
>  void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev,
>                                 unsigned int next);
> +int mtk_ovl_adaptor_power_on(struct device *dev);
> +void mtk_ovl_adaptor_power_off(struct device *dev);
>  int mtk_ovl_adaptor_clk_enable(struct device *dev);
>  void mtk_ovl_adaptor_clk_disable(struct device *dev);
>  void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
> @@ -150,6 +152,8 @@ void mtk_rdma_disable_vblank(struct device *dev);
>  const u32 *mtk_rdma_get_formats(struct device *dev);
>  size_t mtk_rdma_get_num_formats(struct device *dev);
>
> +int mtk_mdp_rdma_power_on(struct device *dev);
> +void mtk_mdp_rdma_power_off(struct device *dev);
>  int mtk_mdp_rdma_clk_enable(struct device *dev);
>  void mtk_mdp_rdma_clk_disable(struct device *dev);
>  void mtk_mdp_rdma_start(struct device *dev, struct cmdq_pkt *cmdq_pkt);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> index 81067f49ea69..048d56ee344d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> @@ -79,6 +79,8 @@ static const struct mtk_ddp_comp_funcs merge = {
>  };
>
>  static const struct mtk_ddp_comp_funcs rdma = {
> +       .power_on = mtk_mdp_rdma_power_on,
> +       .power_off = mtk_mdp_rdma_power_off,
>         .clk_enable = mtk_mdp_rdma_clk_enable,
>         .clk_disable = mtk_mdp_rdma_clk_disable,
>  };
> @@ -200,21 +202,72 @@ void mtk_ovl_adaptor_stop(struct device *dev)
>         mtk_ethdr_stop(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
>  }
>
> -int mtk_ovl_adaptor_clk_enable(struct device *dev)
> +/**
> + * power_off - Power off the devices in OVL adaptor
> + * @dev: Device to be powered off
> + * @num: Number of the devices to be powered off
> + *
> + * Calls the .power_off() ovl_adaptor component callback if it is present.
> + */
> +static inline void power_off(struct device *dev, int num)
>  {
>         struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
> -       struct device *comp;
> -       int ret;
>         int i;
>
> -       for (i = 0; i < OVL_ADAPTOR_MERGE0; i++) {
> -               comp = ovl_adaptor->ovl_adaptor_comp[i];
> -               ret = pm_runtime_get_sync(comp);
> +       if (num > OVL_ADAPTOR_ID_MAX)
> +               num = OVL_ADAPTOR_ID_MAX;
> +
> +       for (i = num - 1; i >= 0; i--) {
> +               if (!ovl_adaptor->ovl_adaptor_comp[i] ||
> +                   !comp_matches[i].funcs->power_off)
> +                       continue;
> +
> +               comp_matches[i].funcs->power_off(ovl_adaptor->ovl_adaptor_comp[i]);
> +       }
> +}
> +
> +/**
> + * mtk_ovl_adaptor_power_on - Power on the devices in OVL adaptor
> + * @dev: Device to be powered on
> + *
> + * Different from OVL, OVL adaptor is a pseudo device so
> + * we didn't define it in the device tree, pm_runtime_resume_and_get()
> + * called by .atomic_enable() power on no device in OVL adaptor,
> + * we have to implement a function to do the job instead.
> + *
> + * Return: Zero for success or negative number for failure.
> + */
> +int mtk_ovl_adaptor_power_on(struct device *dev)
> +{
> +       struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
> +       int i, ret;
> +
> +       for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
> +               if (!ovl_adaptor->ovl_adaptor_comp[i] ||
> +                   !comp_matches[i].funcs->power_on)
> +                       continue;
> +
> +               ret = comp_matches[i].funcs->power_on(ovl_adaptor->ovl_adaptor_comp[i]);
>                 if (ret < 0) {
>                         dev_err(dev, "Failed to enable power domain %d, err %d\n", i, ret);
> -                       goto error;
> +                       power_off(dev, i);
> +                       return ret;
>                 }
>         }
> +       return 0;
> +}
> +
> +void mtk_ovl_adaptor_power_off(struct device *dev)
> +{
> +       power_off(dev, OVL_ADAPTOR_ID_MAX);
> +}
> +
> +int mtk_ovl_adaptor_clk_enable(struct device *dev)
> +{
> +       struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
> +       struct device *comp;
> +       int ret;
> +       int i;
>
>         for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
>                 comp = ovl_adaptor->ovl_adaptor_comp[i];
> @@ -225,16 +278,10 @@ int mtk_ovl_adaptor_clk_enable(struct device *dev)
>                         dev_err(dev, "Failed to enable clock %d, err %d\n", i, ret);
>                         while (--i >= 0)
>                                 comp_matches[i].funcs->clk_disable(comp);
> -                       i = OVL_ADAPTOR_MERGE0;
> -                       goto error;
> +                       return ret;
>                 }
>         }
>         return 0;
> -error:
> -       while (--i >= 0)
> -               pm_runtime_put(ovl_adaptor->ovl_adaptor_comp[i]);
> -
> -       return ret;
>  }
>
>  void mtk_ovl_adaptor_clk_disable(struct device *dev)
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index a0b2ba3cbcdb..bc4cc75cca18 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -774,7 +774,7 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
>                 return;
>         }
>
> -       ret = pm_runtime_resume_and_get(comp->dev);
> +       ret = mtk_ddp_comp_power_on(comp);
>         if (ret < 0) {
>                 DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n", ret);
>                 return;
> @@ -782,7 +782,7 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
>
>         ret = mtk_crtc_ddp_hw_init(mtk_crtc, state);
>         if (ret) {
> -               pm_runtime_put(comp->dev);
> +               mtk_ddp_comp_power_off(comp);
>                 return;
>         }
>
> @@ -795,7 +795,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
>  {
>         struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
>         struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> -       int i, ret;
> +       int i;
>
>         DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
>         if (!mtk_crtc->enabled)
> @@ -825,9 +825,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
>
>         drm_crtc_vblank_off(crtc);
>         mtk_crtc_ddp_hw_fini(mtk_crtc);
> -       ret = pm_runtime_put(comp->dev);
> -       if (ret < 0)
> -               DRM_DEV_ERROR(comp->dev, "Failed to disable power domain: %d\n", ret);
> +       mtk_ddp_comp_power_off(comp);
>
>         mtk_crtc->enabled = false;
>  }
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 10402e07a4a7..9940909c7435 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -396,6 +396,8 @@ static const struct mtk_ddp_comp_funcs ddp_ufoe = {
>  };
>
>  static const struct mtk_ddp_comp_funcs ddp_ovl_adaptor = {
> +       .power_on = mtk_ovl_adaptor_power_on,
> +       .power_off = mtk_ovl_adaptor_power_off,
>         .clk_enable = mtk_ovl_adaptor_clk_enable,
>         .clk_disable = mtk_ovl_adaptor_clk_disable,
>         .config = mtk_ovl_adaptor_config,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 1c1d670cfe41..2597dd7ac0d2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -7,6 +7,7 @@
>  #define MTK_DRM_DDP_COMP_H
>
>  #include <linux/io.h>
> +#include <linux/pm_runtime.h>
>  #include <linux/soc/mediatek/mtk-cmdq.h>
>  #include <linux/soc/mediatek/mtk-mmsys.h>
>  #include <linux/soc/mediatek/mtk-mutex.h>
> @@ -46,6 +47,8 @@ enum mtk_ddp_comp_type {
>  struct mtk_ddp_comp;
>  struct cmdq_pkt;
>  struct mtk_ddp_comp_funcs {
> +       int (*power_on)(struct device *dev);
> +       void (*power_off)(struct device *dev);
>         int (*clk_enable)(struct device *dev);
>         void (*clk_disable)(struct device *dev);
>         void (*config)(struct device *dev, unsigned int w,
> @@ -91,6 +94,23 @@ struct mtk_ddp_comp {
>         int encoder_index;
>  };
>
> +static inline int mtk_ddp_comp_power_on(struct mtk_ddp_comp *comp)
> +{
> +       if (comp->funcs && comp->funcs->power_on)
> +               return comp->funcs->power_on(comp->dev);
> +       else
> +               return pm_runtime_resume_and_get(comp->dev);
> +       return 0;
> +}
> +
> +static inline void mtk_ddp_comp_power_off(struct mtk_ddp_comp *comp)
> +{
> +       if (comp->funcs && comp->funcs->power_off)
> +               comp->funcs->power_off(comp->dev);
> +       else
> +               pm_runtime_put(comp->dev);
> +}
> +
>  static inline int mtk_ddp_comp_clk_enable(struct mtk_ddp_comp *comp)
>  {
>         if (comp->funcs && comp->funcs->clk_enable)
> diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> index 5746f06220c1..769ae7564da2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> @@ -243,6 +243,22 @@ size_t mtk_mdp_rdma_get_num_formats(struct device *dev)
>         return ARRAY_SIZE(formats);
>  }
>
> +int mtk_mdp_rdma_power_on(struct device *dev)
> +{
> +       int ret = pm_runtime_resume_and_get(dev);
> +
> +       if (ret < 0) {
> +               dev_err(dev, "Failed to power on: %d\n", ret);
> +               return ret;
> +       }
> +       return 0;
> +}
> +
> +void mtk_mdp_rdma_power_off(struct device *dev)
> +{
> +       pm_runtime_put(dev);
> +}
> +
>  int mtk_mdp_rdma_clk_enable(struct device *dev)
>  {
>         struct mtk_mdp_rdma *rdma = dev_get_drvdata(dev);
> --
> 2.18.0
>


From robh at kernel.org  Wed Dec 13 06:32:42 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 13 Dec 2023 08:32:42 -0600
Subject: [PATCH v7 02/16] dt-bindings: arm: google: Add bindings for
 Google ARM platforms
In-Reply-To: <20231211162331.435900-3-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-3-peter.griffin@linaro.org>
Message-ID: <170247795662.1093374.11352509671907840697.robh@kernel.org>


On Mon, 11 Dec 2023 16:23:17 +0000, Peter Griffin wrote:
> This introduces bindings and dt-schema for the Google Tensor SoCs.
> Currently just gs101 and pixel 6 are supported.
> 
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
> @RobH I removed your 'Reviewed-by: Rob Herring <robh at kernel.org>' tag
> as since you reviewed this I added the empty ect node. Can you please
> do the review again?
> 
> x# Please enter the commit message for your changes. Lines starting
> ---
>  .../devicetree/bindings/arm/google.yaml       | 53 +++++++++++++++++++
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>



From peter.griffin at linaro.org  Wed Dec 13 06:34:58 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Wed, 13 Dec 2023 14:34:58 +0000
Subject: [PATCH v7 02/16] dt-bindings: arm: google: Add bindings for
 Google ARM platforms
In-Reply-To: <170247795662.1093374.11352509671907840697.robh@kernel.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-3-peter.griffin@linaro.org> <170247795662.1093374.11352509671907840697.robh@kernel.org>
Message-ID: <CADrjBPqqTtimdR_twqqvvzyMAZ=Z4YoVKm80LT_utqcO6LAgOA@mail.gmail.com>

On Wed, 13 Dec 2023 at 14:32, Rob Herring <robh at kernel.org> wrote:
>
>
> On Mon, 11 Dec 2023 16:23:17 +0000, Peter Griffin wrote:
> > This introduces bindings and dt-schema for the Google Tensor SoCs.
> > Currently just gs101 and pixel 6 are supported.
> >
> > Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> > Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> > ---
> > @RobH I removed your 'Reviewed-by: Rob Herring <robh at kernel.org>' tag
> > as since you reviewed this I added the empty ect node. Can you please
> > do the review again?
> >
> > x# Please enter the commit message for your changes. Lines starting
> > ---
> >  .../devicetree/bindings/arm/google.yaml       | 53 +++++++++++++++++++
> >  1 file changed, 53 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
> >
>
> Reviewed-by: Rob Herring <robh at kernel.org>

Thanks Rob :)


From robh at kernel.org  Wed Dec 13 06:36:15 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 13 Dec 2023 08:36:15 -0600
Subject: [PATCH v3 08/13] dt-bindings: imx6q-pcie: Add imx95 pcie
 compatible string
In-Reply-To: <ZXjsq2QtFa2V0BAl@lizhi-Precision-Tower-5810>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-9-Frank.Li@nxp.com>
 <20231212224426.GA2948988-robh@kernel.org>
 <ZXjsq2QtFa2V0BAl@lizhi-Precision-Tower-5810>
Message-ID: <20231213143615.GA1093782-robh@kernel.org>

On Tue, Dec 12, 2023 at 06:28:43PM -0500, Frank Li wrote:
> On Tue, Dec 12, 2023 at 04:44:26PM -0600, Rob Herring wrote:
> > On Mon, Dec 11, 2023 at 04:58:37PM -0500, Frank Li wrote:
> > > From: Richard Zhu <hongxing.zhu at nxp.com>
> > > 
> > > Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
> > > Add "atu" and "serdes" to reg-names.
> > > 
> > > Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> > > ---
> > > 
> > > Notes:
> > >     Change from v2 to v3
> > >     - Remove krzy's ACK tag
> > >     - Add condition check for imx95, which required more reg-names then old
> > >     platform, so need Krzy review again,
> > >     
> > >     Change from v1 to v2
> > >     - add Krzy's ACK tag
> > > 
> > >  .../bindings/pci/fsl,imx6q-pcie.yaml           | 18 ++++++++++++++++++
> > >  1 file changed, 18 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > index 81bbb8728f0f9..b8fcf8258f031 100644
> > > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > @@ -29,6 +29,7 @@ properties:
> > >        - fsl,imx8mq-pcie
> > >        - fsl,imx8mm-pcie
> > >        - fsl,imx8mp-pcie
> > > +      - fsl,imx95-pcie
> > >  
> > >    reg:
> > >      items:
> > > @@ -90,6 +91,22 @@ required:
> > >  allOf:
> > >    - $ref: /schemas/pci/snps,dw-pcie.yaml#
> > >    - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          enum:
> > > +            - fsl,imx95-pcie
> > > +    then:
> > > +      properties:
> > > +        reg:
> > > +          minItems: 4
> > > +        reg-names:
> > > +          items:
> > > +            - const: dbi
> > > +            - const: serdes
> > 
> > Did you test this? It should fail because 'serdes' would need to be 
> > added to snps,dw-pcie.yaml.
> 
> I run "make dt_binding_check DT_SCHEMA_FILES=/pci/", no error report.

Only because you have no example. What about your actual .dts?

> And PCIe function can work.
> 
> > 
> > Is this really not a separate phy block?
> 
> This is misc block, which included phy and also include some registers
> about SID for each PCI devices. I plan do it later.

Sounds like it should be a separate node and use the phy binding. Do it 
correctly from the start, not later. Later is an ABI break.

What is SID?

Rob


From andre.przywara at arm.com  Wed Dec 13 06:37:43 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 13 Dec 2023 14:37:43 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <cm5e7g2ozviyin6p3dh2qtuh4i3f2sbqq4c2arjtdektgk7i6c@l7aawekyj6t2>
References: <20231212122835.10850-2-retpolanne@posteo.net>
	<20231212162200.10b3868b@donnerap.manchester.arm.com>
	<axsvii25yrknfae6gdreti7lcskoscsdbsujwuispiieimsbdy@gwzm4l7mwlew>
	<20231213013544.2fc7e0d1@minigeek.lan>
	<ceuoq3xxgb5kkel7e7wqpslcg7h6dde3wgdqhyo7jgop6owovk@5a76ks5fiun4>
	<20231213122523.219cbfc0@donnerap.manchester.arm.com>
	<cm5e7g2ozviyin6p3dh2qtuh4i3f2sbqq4c2arjtdektgk7i6c@l7aawekyj6t2>
Message-ID: <20231213143743.272e4d3c@donnerap.manchester.arm.com>

On Wed, 13 Dec 2023 12:55:58 +0000
Anne Macedo <retpolanne at posteo.net> wrote:

Hi Anne,

> On Wed, Dec 13, 2023 at 12:25:23PM +0000, Andre Przywara wrote:
> > On Wed, 13 Dec 2023 11:02:39 +0000
> > Anne Macedo <retpolanne at posteo.net> wrote:
> > 
> > Hi Anne,
> >   
> > > On Wed, Dec 13, 2023 at 01:35:44AM +0000, Andre Przywara wrote:  
> > > > On Tue, 12 Dec 2023 19:27:14 +0000
> > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > 
> > > > Hi Anne,
> > > >     
> > > > > On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:    
> > > > > > On Tue, 12 Dec 2023 12:28:30 +0000
> > > > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > > > 
> > > > > > Hi Anne,
> > > > > >       
> > > > > > > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > > > > > > Realtek 8211 PHY to Orange Pi One Plus.      
> > > > > > 
> > > > > > So can you state why this would be needed? This is the RTL8211 ID,      
> > > > > 
> > > > > Apologies, I completely forgot to include some context. 
> > > > >     
> > > > > > right? Which should be autodetected via MDIO. Looking back in my inbox
> > > > > > you proposed this change before, for U-Boot, specifically, but I fail to
> > > > > > find a solution or explanation what really happens here. Two Renesas .dts
> > > > > > files have the same compatible, and the commit message talks about the
> > > > > > reset line there, is this related?
> > > > > > 
> > > > > > So can you please give some more background and explanation? That would be
> > > > > > part of a good commit message anyway ("why", not "what").      
> > > > > 
> > > > > Should I resend the commit with a more meaningful explanation? The
> > > > > context is the following:
> > > > > 
> > > > > currently, ethernet doesn't seem to work on both u-boot and Linux on the
> > > > > Orange Pi One Plus board. 
> > > > > 
> > > > > On the kernel, this error shows up:
> > > > > 
> > > > > Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > [    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> > > > > 
> > > > > After applying this fix, the PHY gets attached: 
> > > > > 
> > > > > Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > [    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
> > > > > 
> > > > > The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
> > > > > to find a PHY, so this patch includes the correct PHY ID with the
> > > > > RTL8211 ID. 
> > > > > 
> > > > > The behaviour is described on [1].    
> > > > 
> > > > So this is all an observation, but no real explanation, isn't it?    
> > > 
> > > I've made some analysis on [3] on this bug, but it was based solely on
> > > u-boot. I was having trouble with the regulator and on u-boot nothing
> > > would trigger the GPIO PD6 and the vcc-gmac-3v3 regulator, so the NIC
> > > was completely dead. Next I did an analysis based on [2] because the
> > > u-boot PHY initialization was flaky.
> > >   
> > > > To cite [1]: "If the PHY reports an incorrect ID (or none at all) ...".
> > > > I am pretty sure this is not the case here, instead we are looking at
> > > > some missing platform bits, like a missing clock, reset, or most likely
> > > > regulator. Or one of the existing resources is wrongly assigned or    
> > > 
> > > As I mentioned, PHY initialization is flaky on u-boot, so maybe that
> > > assumption is correct. 
> > >   
> > > > configured? If the PHY is not (yet?) powered correctly when the code
> > > > does the auto-detection via the MDIO bus, then the initialisation would    
> > > 
> > > If I recall correctly (I don't know if I kept it in my notes :c), that
> > > could be the case. regulator-boot-on makes the NIC work (LEDs blink, at
> > > least) but it doesn't get initialized. 
> > >   
> > > > fail. But since it works when overriding the auto-detection, I feel
> > > > like we are papering over something here.
> > > > Do you have the schematics for this board? I can only find the one for
> > > > the Orange Pi Plus 2E, and I don't know how similar those two are. This
> > > > shows *two* regulators, but both are activated by the same GPIO.    
> > > 
> > > I do. It's available on [4]  
> > 
> > Oh damn it, I got lost in Orange Pi's naming maze again - and was looking
> > for the wrong board! So thanks for the link, and this clears things up!  
> 
> Yay! 
> 
> > 
> > So yes, the Orange Pi *One* Plus, much like the Orange Pi 3, uses *two*
> > regulators for Ethernet: one 3.3V from the PMIC's ALDO2 rail to power the
> > PHY, and a discrete 2.5V regulator, enabled by GPIO PD6, for the voltage  
> 
> Oh! I didn't know about the PMIC's ALDO2.

That's a bit obscure in the schematic, but it's a common thing to do:
- On page 12 (LAN), in the top right box, you see the EPHY-DVDD33 and
EPHY-AVDD33 signals connected to GMAC-3V.
- On the same page, in the middle left part, you see GMAC-3V connected to
VCC3V3-MAC.
- On page 8 (POWER), in the lower left corner, you see VCC3V3-MAC
connected to ALDO2.
- On the same page, in the right hand part, you see the ALDO2 signal
connected to the ALDO2 pin on the PMIC.

Easy, huh? ;-)

> > level on the MDIO lines. On top of this there is a reset line for the PHY,
> > though this is held up by a pull-up resistor, so it *should* work,
> > although we should describe this in the DT.  
> 
> Noting here to take a look at the reset line so I can add it as well to
> the DT.

Yeah, maybe it helps to bring the PHY back into a sane state?

> > So the DT looks wrong then: The reg_gmac_3v3 is actually a 2.5V regulator,
> > and phy-supply is aldo2. I think it was done the way it is to somehow make
> > it work with the current DT binding and code, which just supports one
> > regulator. And aldo2 is referenced as the source of reg_gmac_3v3, which
> > smells like another hack to me.  
> 
> 	reg_gmac_3v3: gmac-3v3 {
> 		compatible = "regulator-fixed";
> 		regulator-name = "vcc-gmac-3v3";
> 		regulator-min-microvolt = <3300000>;
> 		regulator-max-microvolt = <3300000>;
> 		startup-delay-us = <100000>;
> 		enable-active-high;
> 		gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
> 		vin-supply = <&reg_aldo2>;
> 	};
> 
> Interesting, I see the reg_aldo2 on vin-supply for reg_gmac_3v3. I don't
> understand how it works, is it linking the regulator with the ALDO2 but
> it also enables the PD6 GPIO?

So yes, this is one hack I was talking about: This DT node describes a
regulator with a GPIO controlled enable pin (PD6), which feeds itself off
another regulator (vin-supply), namely ALDO2.
So to enable reg_gmac_3v3, which is referenced by the MAC DT node as the
"phy-supply", the regulator driver code would need to enable ALDO2 first,
then make PD6 go high, (to enable this regulator here), then wait 100ms.
So even though the MAC DT node only references one regulator, this trick
will allow *two* regulators to be turned on.

The only problem with this is that it's the wrong order: there are
comments somewhere that say it's required to enable the 2.5V supply
*earlier* or at the same time as the 3.3V supply. And since this PD6
controlled regulator is actually the 2.5V regulator (compare the
schematic!), and ALDO2 is the 3.3V supply, we get it the other way around,
and the PHY operation becomes unstable (that's what those comments say).

And we can't apply this same trick the other way around, since the ALDO
input supply clearly does not feed off this PD6 regulator. 
And besides, it would be wrong and a hack anyway, as we should be able to
describe two regulators as the requirement: this is what Corentin's
of_regulator_bulk_get_all() patch takes care of.

> > > > It would also be interesting to see if any of Corentin's work for the
> > > > Orange Pi 3 helps here?    
> > > 
> > > Adding [5] for reference here, thanks! Will check it out.   
> > 
> > This is an older version, there are actually updates. And he also mentions
> > your board as well, so I think it just can sail in the wake of the OPi 3
> > Ethernet enablement.
> > 
> > Can you try if this change, just applied to your .dts instead, works?
> > https://github.com/montjoie/linux/commit/cf6e192eca1d59be630e6729d2cef9e897b3da8c  
> 
> Will do! I'll be out of my lab today but will try it at night Brazil
> time. 
> > 
> > Cheers,
> > Andre
> > 
> > P.S. Is there any chance where I can reply/comment on your blog? It seems
> > like I can clear some things up...  
> 
> Please send me suggestions off thread, the blog is a static GHPages
> blog, so I didn't implement replies yet. I will be happy to include them
> to my notes :) 

OK, will do later today!

Cheers,
Andre

> 
> >   
> > > [3] https://blog.retpolanne.com/hardware/embedded/2023/07/07/embedded-phy.html
> > > [4] https://linux-sunxi.org/images/7/7c/OrangePi_OnePlus_Schematics_v2.0.pdf
> > > [5] https://lore.kernel.org/netdev/20220509074857.195302-1-clabbe at baylibre.com/
> > > 
> > > Regards, Anne  
> >   
> 
> Regards, Anne
> 



From mark.rutland at arm.com  Wed Dec 13 06:39:30 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 13 Dec 2023 14:39:30 +0000
Subject: [PATCH v7 5/7] arm64: vmemmap: Avoid base2 order of struct page
 size to dimension region
In-Reply-To: <CAMj1kXHTPYrmBx3Zbd5aceAnB-yDhh5gC+Nt8n2VjhY2hcbeEw@mail.gmail.com>
References: <20231213084024.2367360-9-ardb@google.com>
 <20231213084024.2367360-14-ardb@google.com>
 <ZXm2c5_oA5rPrfm8@FVFF77S0Q05N>
 <CAMj1kXHTPYrmBx3Zbd5aceAnB-yDhh5gC+Nt8n2VjhY2hcbeEw@mail.gmail.com>
Message-ID: <ZXnCEWeCZKfm_7GG@FVFF77S0Q05N>

On Wed, Dec 13, 2023 at 03:09:54PM +0100, Ard Biesheuvel wrote:
> On Wed, 13 Dec 2023 at 14:49, Mark Rutland <mark.rutland at arm.com> wrote:
> >
> > Hi Ard,
> >
> > On Wed, Dec 13, 2023 at 09:40:30AM +0100, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel <ardb at kernel.org>
> > >
> > > The placement and size of the vmemmap region in the kernel virtual
> > > address space is currently derived from the base2 order of the size of a
> > > struct page. This makes for nicely aligned constants with lots of
> > > leading 0xf and trailing 0x0 digits, but given that the actual struct
> > > pages are indexed as an ordinary array, this resulting region is
> > > severely overdimensioned when the size of a struct page is just over a
> > > power of 2.
> > >
> > > This doesn't matter today, but once we enable 52-bit virtual addressing
> > > for 4k pages configurations, the vmemmap region may take up almost half
> > > of the upper VA region with the current struct page upper bound at 64
> > > bytes. And once we enable KMSAN or other features that push the size of
> > > a struct page over 64 bytes, we will run out of VMALLOC space entirely.
> > >
> > > So instead, let's derive the region size from the actual size of a
> > > struct page, and place the entire region 1 GB from the top of the VA
> > > space, where it still doesn't share any lower level translation table
> > > entries with the fixmap.
> > >
> > > Acked-by: Mark Rutland <mark.rutland at arm.com>
> > > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > > ---
> > >  arch/arm64/include/asm/memory.h | 8 ++++----
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > index 2745bed8ae5b..b49575a92afc 100644
> > > --- a/arch/arm64/include/asm/memory.h
> > > +++ b/arch/arm64/include/asm/memory.h
> > > @@ -30,8 +30,8 @@
> > >   * keep a constant PAGE_OFFSET and "fallback" to using the higher end
> > >   * of the VMEMMAP where 52-bit support is not available in hardware.
> > >   */
> > > -#define VMEMMAP_SHIFT        (PAGE_SHIFT - STRUCT_PAGE_MAX_SHIFT)
> > > -#define VMEMMAP_SIZE ((_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) >> VMEMMAP_SHIFT)
> > > +#define VMEMMAP_RANGE        (_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET)
> > > +#define VMEMMAP_SIZE ((VMEMMAP_RANGE >> PAGE_SHIFT) * sizeof(struct page))
> > >
> > >  /*
> > >   * PAGE_OFFSET - the virtual address of the start of the linear map, at the
> > > @@ -47,8 +47,8 @@
> > >  #define MODULES_END          (MODULES_VADDR + MODULES_VSIZE)
> > >  #define MODULES_VADDR                (_PAGE_END(VA_BITS_MIN))
> > >  #define MODULES_VSIZE                (SZ_2G)
> > > -#define VMEMMAP_START                (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
> > > -#define VMEMMAP_END          (VMEMMAP_START + VMEMMAP_SIZE)
> > > +#define VMEMMAP_START                (VMEMMAP_END - VMEMMAP_SIZE)
> > > +#define VMEMMAP_END          (-UL(SZ_1G))
> > >  #define PCI_IO_START         (VMEMMAP_END + SZ_8M)
> > >  #define PCI_IO_END           (PCI_IO_START + PCI_IO_SIZE)
> > >  #define FIXADDR_TOP          (-UL(SZ_8M))
> >
> > I realise I've acked this already, but my big concern here is still that it's
> > hard to see why these don't overlap (though the assert in fixmap.c will save
> > us). Usually we try to make that clear by construction, and I think we can do
> > that here with something like:
> >
> > | #define GUARD_VA_SIZE          (UL(SZ_8M))
> > |
> > | #define FIXADDR_TOP            (-GUARD_VA_SIZE)
> > | #define FIXADDR_SIZE_MAX       SZ_8M
> > | #define FIXADDR_START_MIN      (FIXADDR_TOP - FIXADDR_SIZE_MAX)
> > |
> > | #define PCI_IO_END             (FIXADDR_START_MIN - GUARD_VA_SIZE)
> > | #define PCI_IO_START           (PCI_IO_END - PCI_IO_SIZE)
> > |
> > | #define VMEMMAP_END            (ALIGN_DOWN(PCI_IO_START - GUARD_VA_SIZE, SZ_1G))
> > | #define VMEMMAP_START          (VMEMMAP_END - VMEMMAP_SIZE)
> >
> > ... and in fixmap.h have:
> >
> > /* Ensure the estimate in memory.h was big enough */
> > static_assert(FIXADDR_SIZE_MAX > FIXADDR_SIZE);
> >
> > I might be missing some reason why we can't do that; I locally tried the above
> > atop this series with defconfig+4K and defcconfig+64K, and both build and boot
> > without sisue.
> >
> 
> I am really struggling to understand what the issue is that you are
> trying to solve here.
> 
> What I am proposing is
> 
> #define VMEMMAP_END          (-UL(SZ_1G))
> #define PCI_IO_START         (VMEMMAP_END + SZ_8M)
> #define PCI_IO_END           (PCI_IO_START + PCI_IO_SIZE)
> #define FIXADDR_TOP          (-UL(SZ_8M))
> 
> and in fixmap.c
> 
> static_assert(FIXADDR_TOT_START > PCI_IO_END);
> 
> (which sadly has to live outside of asm/memory.h for reasons of #include hell).
> 
> This leaves the top 1G for PCI I/O plus fixmap, and ensures that the
> latter does not collide with the former.

Sure, I get that (and that #include hell is why I have FIXADDR_SIZE_MAX above).

What I'm trying to do is make the relationship between those regions clear *in
one place*, so that this is easier to follow, as that was one of the things I
found painful during review. That said, it's not clear cut, and I'll happily
defer to the judgement of Will and Catalin.

For the series as-is:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Will/Catalin, please let me know your preference on the above.

Thanks,
Mark.


From chenguanxi11234 at 163.com  Wed Dec 13 06:39:54 2023
From: chenguanxi11234 at 163.com (chenguanxi11234 at 163.com)
Date: Wed, 13 Dec 2023 22:39:54 +0800
Subject: [PATCH linux-next] ARM/dma-mapping: replace kzalloc() and vzalloc() with kvzalloc()
In-Reply-To: <CACRpkdap4LUbMcKv_zi=25A-SZf0DJhXiyR1zn0PfuR+b=3NfA@mail.gmail.com>
References: <CACRpkdap4LUbMcKv_zi=25A-SZf0DJhXiyR1zn0PfuR+b=3NfA@mail.gmail.com>
Message-ID: <20231213143954.2541-1-chenguanxi11234@163.com>

>Looks good to me:
>Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
>Please put this patch into Russell's patch tracker.

Hello, I would like to ask, do you mean to have 
me CC the patch email to Russell?I don't really 
understand what patch tracker means.Thank you.



From alexandru.elisei at arm.com  Wed Dec 13 06:51:11 2023
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed, 13 Dec 2023 14:51:11 +0000
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <CAL_JsqL=P1Y6w38LD_xw+vK4CNqt22FW_FE9oi_XTLHVQEne7Q@mail.gmail.com>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com>
 <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
 <ZXiMiLz9ZyUdxUP8@raptor>
 <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
 <ZXmr-Kl9L2SO13--@raptor>
 <CAL_JsqL=P1Y6w38LD_xw+vK4CNqt22FW_FE9oi_XTLHVQEne7Q@mail.gmail.com>
Message-ID: <ZXnE3724jYYSg4o6@raptor>

Hi,

On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> On Wed, Dec 13, 2023 at 7:05?AM Alexandru Elisei
> <alexandru.elisei at arm.com> wrote:
> >
> > Hi Rob,
> >
> > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
> > > <alexandru.elisei at arm.com> wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > Thank you so much for the feedback, I'm not very familiar with device tree,
> > > > and any comments are very useful.
> > > >
> > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > > > > <alexandru.elisei at arm.com> wrote:
> > > > > >
> > > > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > > >
> > > > > > The DTB node for the tag storage region is defined as:
> > > > > >
> > > > > >         tags0: tag-storage at 8f8000000 {
> > > > > >                 compatible = "arm,mte-tag-storage";
> > > > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > > > >                 block-size = <0x1000>;
> > > > > >                 memory = <&memory0>;    // Associated tagged memory node
> > > > > >         };
> > > > >
> > > > > I skimmed thru the discussion some. If this memory range is within
> > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > >
> > > > Ok, will do that.
> > > >
> > > > If you don't mind, why do you say that it definitely belongs in
> > > > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > > > motivation.
> > >
> > > Simply so that /memory nodes describe all possible memory and
> > > /reserved-memory is just adding restrictions. It's also because
> > > /reserved-memory is what gets handled early, and we don't need
> > > multiple things to handle early.
> > >
> > > > Tag storage is not DMA and can live anywhere in memory.
> > >
> > > Then why put it in DT at all? The only reason CMA is there is to set
> > > the size. It's not even clear to me we need CMA in DT either. The
> > > reasoning long ago was the kernel didn't do a good job of moving and
> > > reclaiming contiguous space, but that's supposed to be better now (and
> > > most h/w figured out they need IOMMUs).
> > >
> > > But for tag storage you know the size as it is a function of the
> > > memory size, right? After all, you are validating the size is correct.
> > > I guess there is still the aspect of whether you want enable MTE or
> > > not which could be done in a variety of ways.
> >
> > Oh, sorry, my bad, I should have been clearer about this. I don't want to
> > put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.
> 
> Yes, I understand, but my point remains. Why do you need this in DT?
> If the location doesn't matter and you can calculate the size from the
> memory size, what else is there to add to the DT?

I am afraid there has been a misunderstanding. What do you mean by
"location doesn't matter"?

At the very least, Linux needs to know the address and size of a memory
region to use it. The series is about using the tag storage memory for
data. Tag storage cannot be described as a regular memory node because it
cannot be tagged (and normal memory can).

Then there's the matter of the tag storage block size (explained in this
commit message), and also knowing the memory range for which a tag storage
region stores the tags. This is explained in the cover letter.

Is there something that you feel that is not clear enough? I am more than
happy to go into details.

Thanks,
Alex


From guoren at kernel.org  Wed Dec 13 06:51:12 2023
From: guoren at kernel.org (Guo Ren)
Date: Wed, 13 Dec 2023 22:51:12 +0800
Subject: [PATCH] leds: sun50i-a100: avoid division-by-zero warning
In-Reply-To: <42f522b5-6406-4bef-8180-3a431ee884a5@app.fastmail.com>
References: <20231212214536.175327-1-arnd@kernel.org> <CAJF2gTQckdn=uDfeLKu7wceOq7LT1KGJUT0vARMr9zUy3xc4xw@mail.gmail.com>
 <42f522b5-6406-4bef-8180-3a431ee884a5@app.fastmail.com>
Message-ID: <CAJF2gTQ2jCKO4my9pNvEDyf0R+Cro8ZE_RgvWi-ts8pD6vJ=Nw@mail.gmail.com>

On Wed, Dec 13, 2023 at 2:32?PM Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Wed, Dec 13, 2023, at 02:26, Guo Ren wrote:
> > On Wed, Dec 13, 2023 at 5:45?AM Arnd Bergmann <arnd at kernel.org> wrote:
> >>  {
> >>         const struct sun50i_a100_ledc_timing *timing = &priv->timing;
> >>         unsigned long mod_freq = clk_get_rate(priv->mod_clk);
> >> -       u32 cycle_ns = NSEC_PER_SEC / mod_freq;
> >> +       u32 cycle_ns;
> >>         u32 control;
> >>
> >> +       if (!mod_freq)
> >> +               return;
> >> +
> > Shall we need err_disable_bus_clk?
> >
> > + static int sun50i_a100_ledc_set_timing(struct sun50i_a100_ledc *priv)
> > - static void sun50i_a100_ledc_set_timing(struct sun50i_a100_ledc *priv)
>
> I'm not worried about it too much, as there is already an error check
> on priv->mod_clk being unavailable during initialization. The case that
> the warning is about is just for build-testing on architectures that
> don't even use COMMON_CLK.
Okay

Reviewed-by: Guo Ren <guoren at kernel.org>

>
>      Arnd



-- 
Best Regards
 Guo Ren


From mripard at redhat.com  Wed Dec 13 06:55:57 2023
From: mripard at redhat.com (Maxime Ripard)
Date: Wed, 13 Dec 2023 15:55:57 +0100
Subject: [PATCH v2 0/2] Enable PowerVR driver for TI AM62x
In-Reply-To: <cover.1701773390.git.donald.robson@imgtec.com>
References: <cover.1701773390.git.donald.robson@imgtec.com>
Message-ID: <zq3qtz7rherh2fp2yoe6ail5yvyfkfi46i7fqcbecdagflyj4x@htcfxyhunewx>

Hi Nishanth, Tero, Vignesh,

On Tue, Dec 05, 2023 at 11:39:31AM +0000, Donald Robson wrote:
> These patches enable the new open source PowerVR driver for TI AM62x SoCs,
> currently the only one supported.
> 
> Changes since v1:
> - Added patch 1 for arm64 defconfig (requested by Nishanth Menon)
> 
> Donald Robson (1):
>   arm64: defconfig: enable DRM_POWERVR
> 
> Sarah Walker (1):
>   arm64: dts: ti: k3-am62-main: Add GPU device node

Any chance we can get that in 6.8?

Since the driver will reach 6.8 as well, it would be a bit of a bummer
to not have it enabled anywhere.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/0d61ee25/attachment-0001.sig>

From joey.gouly at arm.com  Wed Dec 13 07:02:59 2023
From: joey.gouly at arm.com (Joey Gouly)
Date: Wed, 13 Dec 2023 15:02:59 +0000
Subject: [PATCH v3 12/25] arm64: handle PKEY/POE faults
In-Reply-To: <ZXdSaRIJGWrtXin-@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-13-joey.gouly@arm.com>
 <ZXdSaRIJGWrtXin-@arm.com>
Message-ID: <20231213150259.GA1129554@e124191.cambridge.arm.com>

Hi,

On Mon, Dec 11, 2023 at 06:18:17PM +0000, Catalin Marinas wrote:
> On Fri, Nov 24, 2023 at 04:34:57PM +0000, Joey Gouly wrote:
> > @@ -497,6 +498,23 @@ static void do_bad_area(unsigned long far, unsigned long esr,
> >  #define VM_FAULT_BADMAP		((__force vm_fault_t)0x010000)
> >  #define VM_FAULT_BADACCESS	((__force vm_fault_t)0x020000)
> >  
> > +static bool fault_from_pkey(unsigned long esr, struct vm_area_struct *vma,
> > +			unsigned int mm_flags)
> > +{
> > +	unsigned long iss2 = ESR_ELx_ISS2(esr);
> > +
> > +	if (!arch_pkeys_enabled())
> > +		return false;
> > +
> > +	if (iss2 & ESR_ELx_Overlay)
> > +		return true;
> > +
> > +	return !arch_vma_access_permitted(vma,
> > +			mm_flags & FAULT_FLAG_WRITE,
> > +			mm_flags & FAULT_FLAG_INSTRUCTION,
> > +			mm_flags & FAULT_FLAG_REMOTE);
> > +}
> 
> Do we actually need this additional arch_vma_access_permitted() check?
> The ESR should tell us if it was a POE fault. Permission overlay faults
> have priority over the base permission faults, so we'd not need to fall
> back to this additional checks. Well, see below, we could do something
> slightly smarter here.

We want this here as it follows other arch's which will fail with a pkey fault
even if the page isn't actually mapped. If the paged isn't mapped we'd get a
translation fault, but since we know the type of access and have the pkey in
the VMA we check it here.

> 
> I can see x86 and powerpc have similar checks (though at a different
> point under the mmap lock) but I'm not familiar with their exception
> model, exception priorities.
> 
> > +
> >  static vm_fault_t __do_page_fault(struct mm_struct *mm,
> >  				  struct vm_area_struct *vma, unsigned long addr,
> >  				  unsigned int mm_flags, unsigned long vm_flags,
> > @@ -688,9 +706,29 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> >  		 * Something tried to access memory that isn't in our memory
> >  		 * map.
> >  		 */
> > -		arm64_force_sig_fault(SIGSEGV,
> > -				      fault == VM_FAULT_BADACCESS ? SEGV_ACCERR : SEGV_MAPERR,
> > -				      far, inf->name);
> > +		int fault_kind;
> > +		/*
> > +		 * The pkey value that we return to userspace can be different
> > +		 * from the pkey that caused the fault.
> > +		 *
> > +		 * 1. T1   : mprotect_key(foo, PAGE_SIZE, pkey=4);
> > +		 * 2. T1   : set AMR to deny access to pkey=4, touches, page
> > +		 * 3. T1   : faults...
> > +		 * 4.    T2: mprotect_key(foo, PAGE_SIZE, pkey=5);
> > +		 * 5. T1   : enters fault handler, takes mmap_lock, etc...
> > +		 * 6. T1   : reaches here, sees vma_pkey(vma)=5, when we really
> > +		 *	     faulted on a pte with its pkey=4.
> > +		 */
> > +		int pkey = vma_pkey(vma);
> 
> Other than the vma_pkey() race, I'm more worried about the vma
> completely disappearing, e.g. munmap() in another thread. We end up
> dereferencing a free pointer here. We need to do this under the mmap
> lock.
> 
> Since we need to do this check under the mmap lock, we could add an
> additional check to see if the pkey fault we got was a racy and just
> restart the instruction if it no longer faults according to
> por_el0_allows_pkey(). However, the code below is too late in the fault
> handling to be able to do much other than SIGSEGV.

After discussing in person, I agree with the assesment that this is the wrong
place to do the check, and after looking at the x86 arch code, I see how
they're doing it earlier.

Thanks,
Joey


From nm at ti.com  Wed Dec 13 07:02:48 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 13 Dec 2023 09:02:48 -0600
Subject: [PATCH v2 0/2] Enable PowerVR driver for TI AM62x
In-Reply-To: <cover.1701773390.git.donald.robson@imgtec.com>
References: <cover.1701773390.git.donald.robson@imgtec.com>
Message-ID: <170247938530.2591587.1832314289335489574.b4-ty@ti.com>

Hi Donald Robson,

On Tue, 05 Dec 2023 11:39:31 +0000, Donald Robson wrote:
> These patches enable the new open source PowerVR driver for TI AM62x SoCs,
> currently the only one supported.
> 
> Changes since v1:
> - Added patch 1 for arm64 defconfig (requested by Nishanth Menon)
> 
> Donald Robson (1):
>   arm64: defconfig: enable DRM_POWERVR
> 
> [...]

NOTE: This series creates checkpatch warnings against v6.7-rc1 and
complains that it cannot find ti,am62-gpu or img,img-axe which
has been merged in drm tree for next. This is clean in linux-next
for a few weeks now. Given the number of people who would really
like to see it in v6.8-rc1 to continue the work towards enabling a
opensource graphics support in the tree without carried patches and
work on next set of features on display and graphics, and given the
real low risk of this NOT making to linus-master, we are making an
specific exception here for this time around. So, please keep a watch
on drm-next and if for any reason the support is dropped going to
linus's tree in the merge window or before, let this chain know with
appropriate maintainers so that we can take corrective actions.

I have applied the following to branch ti-k3-config-next on [1].

[1/2] arm64: defconfig: enable DRM_POWERVR
      commit: e8779517788fa0f3d04840cb7d4121d3df8dfd54

And the following to branch ti-k3-dts-next on [1].

[2/2] arm64: dts: ti: k3-am62-main: Add GPU device node
      commit: a5683d26e09e46362fb3fa87e834cf7073b6a2ec

Thank you!

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From wenst at chromium.org  Wed Dec 13 07:04:24 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:24 +0800
Subject: [PATCH v4 0/9] arm64: dts: mediatek: Add MT8186 Corsola Chromebooks
Message-ID: <20231213150435.4134390-1-wenst@chromium.org>

Hi everyone,

This is v4 of the MT8186 Chromebook device tree series. Sending now in
case you still want to apply more patches.

Changes since v3:
- Collected reviewed-by from Angelo
- Reorder some properties to conform better to the newly proposed DT
  style guidelines
- Drop unused labels
- Rename bt-sco node name to bt-sco-codec
- Drop i2s*-share properties from afe node
- Drop aud_gpio_tdm_{on,off} pinctrl nodes
- Replace interrupts with interrupts-extended in tpm node
- Enable adsp device

Changes since v2:
- Picked up Conor's ack
- Renamed remaining "touchpad" nodes to "trackpad"
- Dropped pinctrl from tentacruel/tentacool second source trackpad

Changes since v1:
- Reorder SKU numbers in descending order.
- Fixed pinconfig node names
- Moved pinctrl-* properties after interrupts-*
- Switched to interrupts-extended for external components
- Marked ADSP as explicitly disabled, with a comment explaining that it
  stalls the system
- Renamed "touchpad" to "trackpad"
- Dropped bogus "no-laneswap" property from it6505 node
- Moved "realtek,jd-src" property to after all the regulator supplies
- Switched to macros for MT6366 regulator "regulator-allowed-modes"
- Renamed "vgpu" regulator name to allow coupling, with a comment
  containing the name used in the design
- Renamed "cr50" node name to "tpm"
- Moved trackpad_pins reference up to i2c2; workaround for second source
  component resource sharing.
- Fix copyright year
- Fixed touchscreen supply name
- Mark missing components as disabled instead of deleting the node
- Dropped reset-gpios from touchscreen nodes
- Drop status = "okay", which is the default


This series adds device trees for the various MT8186 Chromebooks that
were initially released. These are the Tentacruel / Tentacool devices
released by ASUS, and the Steelix / Rusty / Magneton devices released
by Lenovo. The device trees are taken from the downstream ChromeOS v5.15
kernel, ported to mainline and cleaned up.

Corsola is the Google codename given to the MT8186 platform. This
platform has two reference designs, Krabby and Kingler. Kingler was not
used in any actual product, and is therefor not included. Steelix is
an alternative design put forward and is effectively a mix-and-match of
the two reference designs.

Most of the core design is shared between the variants. The differences
are on which external components, such as the display bridges, are used.

Patch 1 cleans up the current list of MediaTek boards. The entries are
reordered by SoC model first, then by board name.

Patch 2 through 5 add DT binding entries for the Tentacruel/Tentacool,
Steelix, Rusty, and Magneton Chromebooks.

Patch 6 through 9 add board device tree files for these devices. Patch 6
also adds the corsola dtsi file for the commonalities between the designs,
as well as a dtsi file for the krabby reference design.

Currently external display support is missing. Audio is not working, as
enabling the audio DSP causes my test systems to hang.

Please have a look and test if possible.


Regards
ChenYu

Chen-Yu Tsai (9):
  dt-bindings: arm: mediatek: Sort entries by SoC then board compatibles
  dt-bindings: arm: mediatek: Add MT8186 Tentacruel / Tentacool
    Chromebooks
  dt-bindings: arm: mediatek: Add MT8186 Steelix Chromebook
  dt-bindings: arm: mediatek: Add MT8186 Rusty Chromebook
  dt-bindings: arm: mediatek: Add MT8186 Magneton Chromebooks
  arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel /
    Tentacool
  arm64: dts: mediatek: Introduce MT8186 Steelix
  arm64: dts: mediatek: Add MT8186 Steelix platform based Rusty
  arm64: dts: mediatek: Add MT8186 Magneton Chromebooks

 .../devicetree/bindings/arm/mediatek.yaml     |  180 +-
 arch/arm64/boot/dts/mediatek/Makefile         |   10 +
 .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
 .../mt8186-corsola-magneton-sku393216.dts     |   39 +
 .../mt8186-corsola-magneton-sku393217.dts     |   39 +
 .../mt8186-corsola-magneton-sku393218.dts     |   26 +
 .../mt8186-corsola-rusty-sku196608.dts        |   26 +
 .../mt8186-corsola-steelix-sku131072.dts      |   18 +
 .../mt8186-corsola-steelix-sku131073.dts      |   18 +
 .../dts/mediatek/mt8186-corsola-steelix.dtsi  |  195 ++
 .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
 .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
 .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
 .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
 .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1707 +++++++++++++++++
 15 files changed, 2477 insertions(+), 61 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi

-- 
2.43.0.472.g3155946c3a-goog



From wenst at chromium.org  Wed Dec 13 07:04:26 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:26 +0800
Subject: [PATCH v4 2/9] dt-bindings: arm: mediatek: Add MT8186 Tentacruel / Tentacool Chromebooks
In-Reply-To: <20231213150435.4134390-1-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
Message-ID: <20231213150435.4134390-3-wenst@chromium.org>

Add entries for MT8186 based Tentacruel / Tentacool Chromebooks. The two
are based on the same board design: the former is a convertible device
with a touchscreen, stylus, and some extra buttons; the latter is a
clamshell device and lacks these additional features.

The two devices both have two variants. The difference is a second
source touchpad controller that shares the same address as the original,
but is incompatible.

The extra SKU IDs for the Tentacruel devices map to different sensor
components attached to the Embedded Controller. These are not visible
to the main processor.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
Changes since v3:
- Collected reviewed-by from Angelo

Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.
---
 .../devicetree/bindings/arm/mediatek.yaml     | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 60337b439744..709a1292bca7 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -206,6 +206,32 @@ properties:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
+        items:
+          - const: google,tentacruel-sku262147
+          - const: google,tentacruel-sku262146
+          - const: google,tentacruel-sku262145
+          - const: google,tentacruel-sku262144
+          - const: google,tentacruel
+          - const: mediatek,mt8186
+      - description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
+        items:
+          - const: google,tentacruel-sku262151
+          - const: google,tentacruel-sku262150
+          - const: google,tentacruel-sku262149
+          - const: google,tentacruel-sku262148
+          - const: google,tentacruel
+          - const: mediatek,mt8186
+      - description: Google Tentacool (ASUS Chromebook CM14 CM1402C)
+        items:
+          - const: google,tentacruel-sku327681
+          - const: google,tentacruel
+          - const: mediatek,mt8186
+      - description: Google Tentacool (ASUS Chromebook CM14 CM1402C)
+        items:
+          - const: google,tentacruel-sku327683
+          - const: google,tentacruel
+          - const: mediatek,mt8186
       - items:
           - enum:
               - mediatek,mt8186-evb
-- 
2.43.0.472.g3155946c3a-goog



From wenst at chromium.org  Wed Dec 13 07:04:25 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:25 +0800
Subject: [PATCH v4 1/9] dt-bindings: arm: mediatek: Sort entries by SoC then board compatibles
In-Reply-To: <20231213150435.4134390-1-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
Message-ID: <20231213150435.4134390-2-wenst@chromium.org>

Some of the new MediaTek board entries were inserted in a chronological
order, or just randomly. This makes it harder to search for an entry.

Sort the entries by first grouping by SoC, then sorting by board
compatible strings. Also add a comment at the top asking people to do
the same.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
Changes since v3:
- Collected reviewed-by from Angelo
Changes since v2:
- none
Changes since v1:
- Collected ack from Conor
---
 .../devicetree/bindings/arm/mediatek.yaml     | 123 +++++++++---------
 1 file changed, 62 insertions(+), 61 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index a5999b3afc35..60337b439744 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -17,6 +17,7 @@ properties:
     const: '/'
   compatible:
     oneOf:
+      # Sort by SoC (last) compatible, then board compatible
       - items:
           - enum:
               - mediatek,mt2701-evb
@@ -129,71 +130,10 @@ properties:
           - enum:
               - mediatek,mt8173-evb
           - const: mediatek,mt8173
-      - items:
-          - enum:
-              - mediatek,mt8183-evb
-          - const: mediatek,mt8183
-      - description: Google Hayato rev5
-        items:
-          - const: google,hayato-rev5-sku2
-          - const: google,hayato-sku2
-          - const: google,hayato
-          - const: mediatek,mt8192
-      - description: Google Hayato
-        items:
-          - const: google,hayato-rev1
-          - const: google,hayato
-          - const: mediatek,mt8192
-      - description: Google Spherion rev4 (Acer Chromebook 514)
-        items:
-          - const: google,spherion-rev4
-          - const: google,spherion
-          - const: mediatek,mt8192
-      - description: Google Spherion (Acer Chromebook 514)
-        items:
-          - const: google,spherion-rev3
-          - const: google,spherion-rev2
-          - const: google,spherion-rev1
-          - const: google,spherion-rev0
-          - const: google,spherion
-          - const: mediatek,mt8192
-      - description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H)
-        items:
-          - enum:
-              - google,tomato-rev2
-              - google,tomato-rev1
-          - const: google,tomato
-          - const: mediatek,mt8195
-      - description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H)
-        items:
-          - const: google,tomato-rev4
-          - const: google,tomato-rev3
-          - const: google,tomato
-          - const: mediatek,mt8195
-      - items:
-          - enum:
-              - mediatek,mt8186-evb
-          - const: mediatek,mt8186
-      - items:
-          - enum:
-              - mediatek,mt8192-evb
-          - const: mediatek,mt8192
-      - items:
-          - enum:
-              - mediatek,mt8195-demo
-              - mediatek,mt8195-evb
-          - const: mediatek,mt8195
       - description: Google Burnet (HP Chromebook x360 11MK G3 EE)
         items:
           - const: google,burnet
           - const: mediatek,mt8183
-      - description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
-        items:
-          - enum:
-              - google,krane-sku0
-              - google,krane-sku176
-          - const: google,krane
-          - const: mediatek,mt8183
       - description: Google Cozmo (Acer Chromebook 314)
         items:
           - const: google,cozmo
@@ -244,6 +184,13 @@ properties:
               - google,kodama-sku32
           - const: google,kodama
           - const: mediatek,mt8183
+      - description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
+        items:
+          - enum:
+              - google,krane-sku0
+              - google,krane-sku176
+          - const: google,krane
+          - const: mediatek,mt8183
       - description: Google Willow (Acer Chromebook 311 C722/C722T)
         items:
           - enum:
@@ -251,10 +198,64 @@ properties:
               - google,willow-sku1
           - const: google,willow
           - const: mediatek,mt8183
+      - items:
+          - enum:
+              - mediatek,mt8183-evb
+          - const: mediatek,mt8183
       - items:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - items:
+          - enum:
+              - mediatek,mt8186-evb
+          - const: mediatek,mt8186
+      - description: Google Hayato
+        items:
+          - const: google,hayato-rev1
+          - const: google,hayato
+          - const: mediatek,mt8192
+      - description: Google Hayato rev5
+        items:
+          - const: google,hayato-rev5-sku2
+          - const: google,hayato-sku2
+          - const: google,hayato
+          - const: mediatek,mt8192
+      - description: Google Spherion (Acer Chromebook 514)
+        items:
+          - const: google,spherion-rev3
+          - const: google,spherion-rev2
+          - const: google,spherion-rev1
+          - const: google,spherion-rev0
+          - const: google,spherion
+          - const: mediatek,mt8192
+      - description: Google Spherion rev4 (Acer Chromebook 514)
+        items:
+          - const: google,spherion-rev4
+          - const: google,spherion
+          - const: mediatek,mt8192
+      - items:
+          - enum:
+              - mediatek,mt8192-evb
+          - const: mediatek,mt8192
+      - description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H)
+        items:
+          - enum:
+              - google,tomato-rev2
+              - google,tomato-rev1
+          - const: google,tomato
+          - const: mediatek,mt8195
+      - description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H)
+        items:
+          - const: google,tomato-rev4
+          - const: google,tomato-rev3
+          - const: google,tomato
+          - const: mediatek,mt8195
+      - items:
+          - enum:
+              - mediatek,mt8195-demo
+              - mediatek,mt8195-evb
+          - const: mediatek,mt8195
       - items:
           - enum:
               - mediatek,mt8365-evk
-- 
2.43.0.472.g3155946c3a-goog



From wenst at chromium.org  Wed Dec 13 07:04:27 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:27 +0800
Subject: [PATCH v4 3/9] dt-bindings: arm: mediatek: Add MT8186 Steelix Chromebook
In-Reply-To: <20231213150435.4134390-1-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
Message-ID: <20231213150435.4134390-4-wenst@chromium.org>

Add an entry for the MT8186 based Steelix Chromebook, also known as the
Lenovo 300e Yoga Chromebook Gen 4.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
Changes since v3:
- Collected reviewed-by from Angelo

Changes since v2:
- Picked up Conor's ack
Changes since v1:
none
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 709a1292bca7..95d2b430ab17 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -206,6 +206,13 @@ properties:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - description: Google Steelix (Lenovo 300e Yoga Chromebook Gen 4)
+        items:
+          - enum:
+              - google,steelix-sku131072
+              - google,steelix-sku131073
+          - const: google,steelix
+          - const: mediatek,mt8186
       - description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
         items:
           - const: google,tentacruel-sku262147
-- 
2.43.0.472.g3155946c3a-goog



From wenst at chromium.org  Wed Dec 13 07:04:28 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:28 +0800
Subject: [PATCH v4 4/9] dt-bindings: arm: mediatek: Add MT8186 Rusty Chromebook
In-Reply-To: <20231213150435.4134390-1-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
Message-ID: <20231213150435.4134390-5-wenst@chromium.org>

Add an entry for the MT8186 based Rusty Chromebook, also known as the
Lenovo 100e Chromebook Gen 4.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
Changes since v3:
- Collected reviewed-by from Angelo

Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 95d2b430ab17..85d394e390f0 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -206,6 +206,12 @@ properties:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - description: Google Rusty (Lenovo 100e Chromebook Gen 4)
+        items:
+          - const: google,steelix-sku196609
+          - const: google,steelix-sku196608
+          - const: google,steelix
+          - const: mediatek,mt8186
       - description: Google Steelix (Lenovo 300e Yoga Chromebook Gen 4)
         items:
           - enum:
-- 
2.43.0.472.g3155946c3a-goog



From wenst at chromium.org  Wed Dec 13 07:04:30 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:30 +0800
Subject: [PATCH v4 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel / Tentacool
In-Reply-To: <20231213150435.4134390-1-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
Message-ID: <20231213150435.4134390-7-wenst@chromium.org>

Tentacruel and Tentacool are MT8186 based Chromebooks based on the
Krabby design.

Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
convertible device with touchscreen and stylus.

Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
device. It does not have a touchscreen or stylus.

The two devices both have two variants. The difference is a second
source touchpad controller that shares the same address as the original,
but is incompatible.

The extra SKU IDs for the Tentacruel devices map to different sensor
components attached to the Embedded Controller. These are not visible
to the main processor.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v3:
- Reorder some properties to conform better to the newly proposed DT
  style guidelines
- Drop unused labels
- Rename bt-sco node name to bt-sco-codec
- Drop i2s*-share properties from afe node
- Drop aud_gpio_tdm_{on,off} pinctrl nodes
- Replace interrupts with interrupts-extended in tpm node
- Enable adsp device

Changes since v2:
- Picked up Conor's ack
- Rename touchpad to trackpad
- Drop pinctrl properties from trackpad in tentacruel/tentacool second
  source trackpad

Changes since v1:
- Reorder SKU numbers in descending order.
- Fixed pinconfig node names
- Moved pinctrl-* properties after interrupts-*
- Switched to interrupts-extended for external components
- Marked ADSP as explicitly disabled, with a comment explaining that it
  stalls the system
- Renamed "touchpad" to "trackpad"
- Dropped bogus "no-laneswap" property from it6505 node
- Moved "realtek,jd-src" property to after all the regulator supplies
- Switched to macros for MT6366 regulator "regulator-allowed-modes"
- Renamed "vgpu" regulator name to allow coupling, with a comment
  containing the name used in the design
- Renamed "cr50" node name to "tpm"
- Moved trackpad_pins reference up to i2c2; workaround for second source
  component resource sharing.
- Fix copyright year
- Fixed touchscreen supply name
---
 arch/arm64/boot/dts/mediatek/Makefile         |    4 +
 .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
 .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
 .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
 .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
 .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
 .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1707 +++++++++++++++++
 7 files changed, 1991 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index e6e7592a3645..442af61b1305 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
new file mode 100644
index 000000000000..7c971198fa95
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	aliases {
+		i2c4 = &i2c4;
+	};
+};
+
+&dsi_out {
+	remote-endpoint = <&ps8640_in>;
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+
+	edp-bridge at 8 {
+		compatible = "parade,ps8640";
+		reg = <0x8>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ps8640_pins>;
+		powerdown-gpios = <&pio 96 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&pio 98 GPIO_ACTIVE_LOW>;
+		vdd12-supply = <&mt6366_vrf12_reg>;
+		vdd33-supply = <&mt6366_vcn33_reg>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				ps8640_in: endpoint {
+					remote-endpoint = <&dsi_out>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+
+				ps8640_out: endpoint {
+					remote-endpoint = <&panel_in>;
+				};
+			};
+		};
+
+		aux-bus {
+			panel {
+				compatible = "edp-panel";
+				power-supply = <&pp3300_disp_x>;
+				backlight = <&backlight_lcd0>;
+
+				port {
+					panel_in: endpoint {
+						remote-endpoint = <&ps8640_out>;
+					};
+				};
+			};
+		};
+	};
+};
+
+&i2c1 {
+	i2c-scl-internal-delay-ns = <10000>;
+
+	touchscreen: touchscreen at 10 {
+		compatible = "hid-over-i2c";
+		reg = <0x10>;
+		interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		post-power-on-delay-ms = <10>;
+		hid-descr-addr = <0x0001>;
+		vdd-supply = <&pp3300_s3>;
+	};
+};
+
+&i2c4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c4_pins>;
+	clock-frequency = <400000>;
+	status = "okay";
+
+	proximity at 28 {
+		compatible = "semtech,sx9324";
+		reg = <0x28>;
+		#io-channel-cells = <1>;
+		interrupts-extended = <&pio 5 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sar_sensor_pins>;
+		vdd-supply = <&mt6366_vio18_reg>;
+		svdd-supply = <&mt6366_vio18_reg>;
+	};
+};
+
+&pio {
+	i2c4_pins: i2c4-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO136__FUNC_SDA4>,
+				 <PINMUX_GPIO135__FUNC_SCL4>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	ps8640_pins: ps8640-pins {
+		pins-pwrdn-rst {
+			pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
+				 <PINMUX_GPIO98__FUNC_GPIO98>;
+			output-low;
+		};
+	};
+
+	sar_sensor_pins: sar-sensor-pins {
+		pins-irq {
+			pinmux = <PINMUX_GPIO5__FUNC_GPIO5>;
+			input-enable;
+			bias-pull-up;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
new file mode 100644
index 000000000000..9bb64353ca65
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-krabby.dtsi"
+
+/ {
+	model = "Google Tentacool board";
+	compatible = "google,tentacruel-sku327681", "google,tentacruel", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+/* Tentacool omits the pen. */
+&gpio_keys {
+	status = "disabled";
+};
+
+/* Tentacool omits the touchscreen; nothing else is on i2c1. */
+&i2c1 {
+	status = "disabled";
+};
+
+&keyboard_controller {
+	function-row-physmap = <
+		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
+		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
+		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
+		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
+		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
+		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
+		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
+		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
+		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
+		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
+	>;
+
+	linux,keymap = <
+		MATRIX_KEY(0x00, 0x02, KEY_BACK)
+		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
+		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
+		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
+		MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
+		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
+		MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
+		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
+		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
+		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
+		CROS_STD_MAIN_KEYMAP
+	>;
+};
+
+/* Tentacool omits the touchscreen. */
+&touchscreen {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
new file mode 100644
index 000000000000..c3ae6f9616c8
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2023 Google LLC
+ */
+
+#include "mt8186-corsola-tentacool-sku327681.dts"
+
+/ {
+	compatible = "google,tentacruel-sku327683", "google,tentacruel", "mediatek,mt8186";
+};
+
+/* This variant replaces only the trackpad controller. */
+&i2c2 {
+	/delete-node/ trackpad at 15;
+
+	trackpad at 15 {
+		compatible = "hid-over-i2c";
+		reg = <0x15>;
+		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
+		hid-descr-addr = <0x0001>;
+		vdd-supply = <&pp3300_s3>;
+		wakeup-source;
+	};
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
new file mode 100644
index 000000000000..26d3451a5e47
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-krabby.dtsi"
+
+/ {
+	model = "Google Tentacruel board";
+	compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
+		     "google,tentacruel-sku262145", "google,tentacruel-sku262144",
+		     "google,tentacruel", "mediatek,mt8186";
+	chassis-type = "convertible";
+};
+
+&keyboard_controller {
+	function-row-physmap = <
+		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
+		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
+		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
+		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
+		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
+		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
+		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
+		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
+		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
+		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
+	>;
+
+	linux,keymap = <
+		MATRIX_KEY(0x00, 0x02, KEY_BACK)
+		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
+		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
+		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
+		MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
+		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
+		MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
+		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
+		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
+		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
+		CROS_STD_MAIN_KEYMAP
+	>;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
new file mode 100644
index 000000000000..447b57b12b41
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2023 Google LLC
+ */
+
+#include "mt8186-corsola-tentacruel-sku262144.dts"
+
+/ {
+	compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
+		     "google,tentacruel-sku262149", "google,tentacruel-sku262148",
+		     "google,tentacruel", "mediatek,mt8186";
+};
+
+/* This variant replaces only the trackpad controller. */
+&i2c2 {
+	/delete-node/ trackpad at 15;
+
+	trackpad at 15 {
+		compatible = "hid-over-i2c";
+		reg = <0x15>;
+		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
+		hid-descr-addr = <0x0001>;
+		vdd-supply = <&pp3300_s3>;
+		wakeup-source;
+	};
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
new file mode 100644
index 000000000000..adbeb0c765d3
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
@@ -0,0 +1,1707 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2022 MediaTek Inc.
+ */
+/dts-v1/;
+#include "mt8186.dtsi"
+#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
+
+/ {
+	aliases {
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c5 = &i2c5;
+		mmc0 = &mmc0;
+		mmc1 = &mmc1;
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory at 40000000 {
+		device_type = "memory";
+		/* The size should be filled in by the bootloader. */
+		reg = <0 0x40000000 0 0>;
+	};
+
+	backlight_lcd0: backlight-lcd0 {
+		compatible = "pwm-backlight";
+		pwms = <&pwm0 0 500000>;
+		power-supply = <&ppvar_sys>;
+		enable-gpios = <&pio 152 0>;
+		brightness-levels = <0 1023>;
+		num-interpolated-steps = <1023>;
+		default-brightness-level = <576>;
+	};
+
+	bt-sco-codec {
+		compatible = "linux,bt-sco";
+		#sound-dai-cells = <0>;
+	};
+
+	dmic-codec {
+		compatible = "dmic-codec";
+		#sound-dai-cells = <0>;
+		num-channels = <2>;
+		wakeup-delay-ms = <50>;
+	};
+
+	gpio_keys: gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pen_eject>;
+
+		pen_insert: pen-insert-switch {
+			label = "Pen Insert";
+			/* Insert = low, eject = high */
+			gpios = <&pio 18 GPIO_ACTIVE_LOW>;
+			wakeup-event-action = <EV_ACT_DEASSERTED>;
+			wakeup-source;
+			linux,code = <SW_PEN_INSERTED>;
+			linux,input-type = <EV_SW>;
+		};
+	};
+
+	pp1800_dpbrdg_dx: regulator-pp1800-dpbrdg-dx {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp1800_dpbrdg>;
+		gpios = <&pio 39 GPIO_ACTIVE_HIGH>;
+		regulator-name = "pp1800_dpbrdg_dx";
+		enable-active-high;
+		vin-supply = <&mt6366_vio18_reg>;
+	};
+
+	pp3300_disp_x: regulator-pp3300-disp-x {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&edp_panel_fixed_pins>;
+		gpios = <&pio 153 GPIO_ACTIVE_HIGH>;
+		regulator-name = "pp3300_disp_x";
+		enable-active-high;
+		regulator-boot-on;
+		vin-supply = <&pp3300_z2>;
+	};
+
+	/* system wide LDO 3.3V power rail */
+	pp3300_z5: regulator-pp3300-ldo-z5 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_ldo_z5";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* separately switched 3.3V power rail */
+	pp3300_s3: regulator-pp3300-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_s3";
+		/* automatically sequenced by PMIC EXT_PMIC_EN2 */
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&pp3300_z2>;
+	};
+
+	/* system wide 3.3V power rail */
+	pp3300_z2: regulator-pp3300-z2 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_z2";
+		/* EN pin tied to pp4200_z2, which is controlled by EC */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* system wide 4.2V power rail */
+	pp4200_z2: regulator-pp4200-z2 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp4200_z2";
+		/* controlled by EC */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <4200000>;
+		regulator-max-microvolt = <4200000>;
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* system wide switching 5.0V power rail */
+	pp5000_z2: regulator-pp5000-z2 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp5000_z2";
+		/* controlled by EC */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* system wide semi-regulated power rail from battery or USB */
+	ppvar_sys: regulator-ppvar-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "ppvar_sys";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		adsp_dma_mem: memory at 61000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x61000000 0 0x100000>;
+			no-map;
+		};
+
+		adsp_mem: memory at 60000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x60000000 0 0xA00000>;
+			no-map;
+		};
+
+		scp_mem: memory at 50000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x50000000 0 0x10a0000>;
+			no-map;
+		};
+	};
+
+	sound: sound {
+		compatible = "mediatek,mt8186-mt6366-rt1019-rt5682s-sound";
+		pinctrl-names = "aud_clk_mosi_off",
+				"aud_clk_mosi_on",
+				"aud_clk_miso_off",
+				"aud_clk_miso_on",
+				"aud_dat_miso_off",
+				"aud_dat_miso_on",
+				"aud_dat_mosi_off",
+				"aud_dat_mosi_on",
+				"aud_gpio_i2s0_off",
+				"aud_gpio_i2s0_on",
+				"aud_gpio_i2s1_off",
+				"aud_gpio_i2s1_on",
+				"aud_gpio_i2s2_off",
+				"aud_gpio_i2s2_on",
+				"aud_gpio_i2s3_off",
+				"aud_gpio_i2s3_on",
+				"aud_gpio_pcm_off",
+				"aud_gpio_pcm_on",
+				"aud_gpio_dmic_sec";
+		pinctrl-0 = <&aud_clk_mosi_off>;
+		pinctrl-1 = <&aud_clk_mosi_on>;
+		pinctrl-2 = <&aud_clk_miso_off>;
+		pinctrl-3 = <&aud_clk_miso_on>;
+		pinctrl-4 = <&aud_dat_miso_off>;
+		pinctrl-5 = <&aud_dat_miso_on>;
+		pinctrl-6 = <&aud_dat_mosi_off>;
+		pinctrl-7 = <&aud_dat_mosi_on>;
+		pinctrl-8 = <&aud_gpio_i2s0_off>;
+		pinctrl-9 = <&aud_gpio_i2s0_on>;
+		pinctrl-10 = <&aud_gpio_i2s1_off>;
+		pinctrl-11 = <&aud_gpio_i2s1_on>;
+		pinctrl-12 = <&aud_gpio_i2s2_off>;
+		pinctrl-13 = <&aud_gpio_i2s2_on>;
+		pinctrl-14 = <&aud_gpio_i2s3_off>;
+		pinctrl-15 = <&aud_gpio_i2s3_on>;
+		pinctrl-16 = <&aud_gpio_pcm_off>;
+		pinctrl-17 = <&aud_gpio_pcm_on>;
+		pinctrl-18 = <&aud_gpio_dmic_sec>;
+		mediatek,adsp = <&adsp>;
+		mediatek,platform = <&afe>;
+
+		playback-codecs {
+			sound-dai = <&it6505dptx>, <&rt1019p>;
+		};
+
+		headset-codec {
+			sound-dai = <&rt5682s 0>;
+		};
+	};
+
+	rt1019p: speaker-codec {
+		compatible = "realtek,rt1019p";
+		pinctrl-names = "default";
+		pinctrl-0 = <&rt1019p_pins_default>;
+		#sound-dai-cells = <0>;
+		sdb-gpios = <&pio 150 GPIO_ACTIVE_HIGH>;
+	};
+
+	usb_p1_vbus: regulator-usb-p1-vbus {
+		compatible = "regulator-fixed";
+		gpio = <&pio 148 GPIO_ACTIVE_HIGH>;
+		regulator-name = "vbus1";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		vin-supply = <&pp5000_z2>;
+	};
+
+	wifi_pwrseq: wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_pin>;
+		post-power-on-delay-ms = <50>;
+		reset-gpios = <&pio 54 GPIO_ACTIVE_LOW>;
+	};
+
+	wifi_wakeup: wifi-wakeup {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_wakeup_pin>;
+
+		wowlan-event {
+			label = "Wake on WiFi";
+			gpios = <&pio 7 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_WAKEUP>;
+			wakeup-source;
+		};
+	};
+};
+
+&adsp {
+	memory-region = <&adsp_dma_mem>, <&adsp_mem>;
+	status = "okay";
+};
+
+&afe {
+	status = "okay";
+};
+
+&cci {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu0 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu1 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu2 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu3 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu4 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu5 {
+	proc-supply = <&mt6366_vproc12_reg>;
+};
+
+&cpu6 {
+	proc-supply = <&mt6366_vproc11_reg>;
+};
+
+&cpu7 {
+	proc-supply = <&mt6366_vproc11_reg>;
+};
+
+&dpi {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&dpi_pins_default>;
+	pinctrl-1 = <&dpi_pins_sleep>;
+	status = "okay";
+};
+
+&dpi_out {
+	remote-endpoint = <&it6505_in>;
+};
+
+&dsi0 {
+	status = "okay";
+};
+
+&gic {
+	mediatek,broken-save-restore-fw;
+};
+
+&gpu {
+	mali-supply = <&mt6366_vgpu_reg>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+	clock-frequency = <400000>;
+	i2c-scl-internal-delay-ns = <8000>;
+	status = "okay";
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	/*
+	 * Trackpad pin put here to work around second source components
+	 * sharing the pinmux in steelix designs.
+	 */
+	pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
+	clock-frequency = <400000>;
+	i2c-scl-internal-delay-ns = <10000>;
+	status = "okay";
+
+	trackpad at 15 {
+		compatible = "elan,ekth3000";
+		reg = <0x15>;
+		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
+		vcc-supply = <&pp3300_s3>;
+		wakeup-source;
+	};
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c3_pins>;
+	clock-frequency = <100000>;
+	status = "okay";
+
+	it6505dptx: dp-bridge at 5c {
+		compatible = "ite,it6505";
+		reg = <0x5c>;
+		interrupts-extended = <&pio 8 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&it6505_pins>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		#sound-dai-cells = <0>;
+		ovdd-supply = <&mt6366_vsim2_reg>;
+		pwr18-supply = <&pp1800_dpbrdg_dx>;
+		reset-gpios = <&pio 177 GPIO_ACTIVE_HIGH>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				it6505_in: endpoint {
+					link-frequencies = /bits/ 64 <150000000>;
+					remote-endpoint = <&dpi_out>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+			};
+		};
+	};
+};
+
+&i2c5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c5_pins>;
+	status = "okay";
+
+	rt5682s: codec at 1a {
+		compatible = "realtek,rt5682s";
+		reg = <0x1a>;
+		interrupts-extended = <&pio 17 IRQ_TYPE_EDGE_BOTH>;
+		#sound-dai-cells = <1>;
+		AVDD-supply = <&mt6366_vio18_reg>;
+		DBVDD-supply = <&mt6366_vio18_reg>;
+		LDO1-IN-supply = <&mt6366_vio18_reg>;
+		MICVDD-supply = <&pp3300_z2>;
+		realtek,jd-src = <1>;
+	};
+};
+
+&mfg0 {
+	domain-supply = <&mt6366_vsram_gpu_reg>;
+};
+
+&mfg1 {
+	domain-supply = <&mt6366_vgpu_reg>;
+};
+
+&mipi_tx0 {
+	status = "okay";
+};
+
+&mmc0 {
+	pinctrl-names = "default", "state_uhs";
+	pinctrl-0 = <&mmc0_pins_default>;
+	pinctrl-1 = <&mmc0_pins_uhs>;
+	bus-width = <8>;
+	max-frequency = <200000000>;
+	non-removable;
+	cap-mmc-highspeed;
+	mmc-hs200-1_8v;
+	mmc-hs400-1_8v;
+	supports-cqe;
+	no-sd;
+	no-sdio;
+	cap-mmc-hw-reset;
+	hs400-ds-delay = <0x11814>;
+	mediatek,hs400-ds-dly3 = <0x14>;
+	vmmc-supply = <&mt6366_vemc_reg>;
+	vqmmc-supply = <&mt6366_vio18_reg>;
+	status = "okay";
+};
+
+&mmc1 {
+	pinctrl-names = "default", "state_uhs", "state_eint";
+	pinctrl-0 = <&mmc1_pins_default>;
+	pinctrl-1 = <&mmc1_pins_uhs>;
+	pinctrl-2 = <&mmc1_pins_eint>;
+	/delete-property/ interrupts;
+	interrupt-names = "msdc", "sdio_wakeup";
+	interrupts-extended = <&gic GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH 0>,
+			      <&pio 87 IRQ_TYPE_LEVEL_LOW>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	bus-width = <4>;
+	max-frequency = <200000000>;
+	cap-sd-highspeed;
+	sd-uhs-sdr104;
+	sd-uhs-sdr50;
+	keep-power-in-suspend;
+	wakeup-source;
+	cap-sdio-irq;
+	no-mmc;
+	no-sd;
+	non-removable;
+	vmmc-supply = <&pp3300_s3>;
+	vqmmc-supply = <&mt6366_vio18_reg>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	status = "okay";
+
+	bluetooth at 2 {
+		compatible = "mediatek,mt7921s-bluetooth";
+		reg = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_pins_reset>;
+		reset-gpios = <&pio 155 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&nor_flash {
+	assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D7_D4>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&nor_pins_default>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	flash at 0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <39000000>;
+	};
+};
+
+&pio {
+	/* 185 lines */
+	gpio-line-names = "TP",
+			  "TP",
+			  "TP",
+			  "I2S0_HP_DI",
+			  "I2S3_DP_SPKR_DO",
+			  "SAR_INT_ODL",
+			  "BT_WAKE_AP_ODL",
+			  "WIFI_INT_ODL",
+			  "DPBRDG_INT_ODL",
+			  "EDPBRDG_INT_ODL",
+			  "EC_AP_HPD_OD",
+			  "TCHPAD_INT_ODL",
+			  "TCHSCR_INT_1V8_ODL",
+			  "EC_AP_INT_ODL",
+			  "EC_IN_RW_ODL",
+			  "GSC_AP_INT_ODL",
+			  /* AP_FLASH_WP_L is crossystem ABI. Rev1 schematics call it AP_WP_ODL. */
+			  "AP_FLASH_WP_L",
+			  "HP_INT_ODL",
+			  "PEN_EJECT_OD",
+			  "WCAM_PWDN_L",
+			  "WCAM_RST_L",
+			  "UCAM_SEN_EN",
+			  "UCAM_RST_L",
+			  "LTE_RESET_L",
+			  "LTE_SAR_DETECT_L",
+			  "I2S2_DP_SPK_MCK",
+			  "I2S2_DP_SPKR_BCK",
+			  "I2S2_DP_SPKR_LRCK",
+			  "I2S2_DP_SPKR_DI (TP)",
+			  "EN_PP1000_EDPBRDG",
+			  "EN_PP1800_EDPBRDG",
+			  "EN_PP3300_EDPBRDG",
+			  "UART_GSC_TX_AP_RX",
+			  "UART_AP_TX_GSC_RX",
+			  "UART_DBGCON_TX_ADSP_RX",
+			  "UART_ADSP_TX_DBGCON_RX",
+			  "EN_PP1000_DPBRDG",
+			  "TCHSCR_REPORT_DISABLE",
+			  "EN_PP3300_DPBRDG",
+			  "EN_PP1800_DPBRDG",
+			  "SPI_AP_CLK_EC",
+			  "SPI_AP_CS_EC_L",
+			  "SPI_AP_DO_EC_DI",
+			  "SPI_AP_DI_EC_DO",
+			  "SPI_AP_CLK_GSC",
+			  "SPI_AP_CS_GSC_L",
+			  "SPI_AP_DO_GSC_DI",
+			  "SPI_AP_DI_GSC_DO",
+			  "UART_DBGCON_TX_SCP_RX",
+			  "UART_SCP_TX_DBGCON_RX",
+			  "EN_PP1200_CAM_X",
+			  "EN_PP2800A_VCM_X",
+			  "EN_PP2800A_UCAM_X",
+			  "EN_PP2800A_WCAM_X",
+			  "WLAN_MODULE_RST_L",
+			  "EN_PP1200_UCAM_X",
+			  "I2S1_HP_DO",
+			  "I2S1_HP_BCK",
+			  "I2S1_HP_LRCK",
+			  "I2S1_HP_MCK",
+			  "TCHSCR_RST_1V8_L",
+			  "SPI_AP_CLK_ROM",
+			  "SPI_AP_CS_ROM_L",
+			  "SPI_AP_DO_ROM_DI",
+			  "SPI_AP_DI_ROM_DO",
+			  "NC",
+			  "NC",
+			  "EMMC_STRB",
+			  "EMMC_CLK",
+			  "EMMC_CMD",
+			  "EMMC_RST_L",
+			  "EMMC_DATA0",
+			  "EMMC_DATA1",
+			  "EMMC_DATA2",
+			  "EMMC_DATA3",
+			  "EMMC_DATA4",
+			  "EMMC_DATA5",
+			  "EMMC_DATA6",
+			  "EMMC_DATA7",
+			  "AP_KPCOL0",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "TP",
+			  "SDIO_CLK",
+			  "SDIO_CMD",
+			  "SDIO_DATA0",
+			  "SDIO_DATA1",
+			  "SDIO_DATA2",
+			  "SDIO_DATA3",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "NC",
+			  "EDPBRDG_PWREN",
+			  "BL_PWM_1V8",
+			  "EDPBRDG_RST_L",
+			  "MIPI_DPI_CLK",
+			  "MIPI_DPI_VSYNC",
+			  "MIPI_DPI_HSYNC",
+			  "MIPI_DPI_DE",
+			  "MIPI_DPI_D0",
+			  "MIPI_DPI_D1",
+			  "MIPI_DPI_D2",
+			  "MIPI_DPI_D3",
+			  "MIPI_DPI_D4",
+			  "MIPI_DPI_D5",
+			  "MIPI_DPI_D6",
+			  "MIPI_DPI_DA7",
+			  "MIPI_DPI_D8",
+			  "MIPI_DPI_D9",
+			  "MIPI_DPI_D10",
+			  "MIPI_DPI_D11",
+			  "PCM_BT_CLK",
+			  "PCM_BT_SYNC",
+			  "PCM_BT_DI",
+			  "PCM_BT_DO",
+			  "JTAG_TMS_TP",
+			  "JTAG_TCK_TP",
+			  "JTAG_TDI_TP",
+			  "JTAG_TDO_TP",
+			  "JTAG_TRSTN_TP",
+			  "CLK_24M_WCAM",
+			  "CLK_24M_UCAM",
+			  "UCAM_DET_ODL",
+			  "AP_I2C_EDPBRDG_SCL_1V8",
+			  "AP_I2C_EDPBRDG_SDA_1V8",
+			  "AP_I2C_TCHSCR_SCL_1V8",
+			  "AP_I2C_TCHSCR_SDA_1V8",
+			  "AP_I2C_TCHPAD_SCL_1V8",
+			  "AP_I2C_TCHPAD_SDA_1V8",
+			  "AP_I2C_DPBRDG_SCL_1V8",
+			  "AP_I2C_DPBRDG_SDA_1V8",
+			  "AP_I2C_WLAN_SCL_1V8",
+			  "AP_I2C_WLAN_SDA_1V8",
+			  "AP_I2C_AUD_SCL_1V8",
+			  "AP_I2C_AUD_SDA_1V8",
+			  "AP_I2C_TPM_SCL_1V8",
+			  "AP_I2C_UCAM_SDA_1V8",
+			  "AP_I2C_UCAM_SCL_1V8",
+			  "AP_I2C_UCAM_SDA_1V8",
+			  "AP_I2C_WCAM_SCL_1V8",
+			  "AP_I2C_WCAM_SDA_1V8",
+			  "SCP_I2C_SENSOR_SCL_1V8",
+			  "SCP_I2C_SENSOR_SDA_1V8",
+			  "AP_EC_WARM_RST_REQ",
+			  "AP_XHCI_INIT_DONE",
+			  "USB3_HUB_RST_L",
+			  "EN_SPKR",
+			  "BEEP_ON",
+			  "AP_EDP_BKLTEN",
+			  "EN_PP3300_DISP_X",
+			  "EN_PP3300_SDBRDG_X",
+			  "BT_KILL_1V8_L",
+			  "WIFI_KILL_1V8_L",
+			  "PWRAP_SPI0_CSN",
+			  "PWRAP_SPI0_CK",
+			  "PWRAP_SPI0_MO",
+			  "PWRAP_SPI0_MI",
+			  "SRCLKENA0",
+			  "SRCLKENA1",
+			  "SCP_VREQ_VAO",
+			  "AP_RTC_CLK32K",
+			  "AP_PMIC_WDTRST_L",
+			  "AUD_CLK_MOSI",
+			  "AUD_SYNC_MOSI",
+			  "AUD_DAT_MOSI0",
+			  "AUD_DAT_MOSI1",
+			  "AUD_CLK_MISO",
+			  "AUD_SYNC_MISO",
+			  "AUD_DAT_MISO0",
+			  "AUD_DAT_MISO1",
+			  "NC",
+			  "NC",
+			  "DPBRDG_PWREN",
+			  "DPBRDG_RST_L",
+			  "LTE_W_DISABLE_L",
+			  "LTE_SAR_DETECT_L",
+			  "EN_PP3300_LTE_X",
+			  "LTE_PWR_OFF_L",
+			  "LTE_RESET_L",
+			  "TP",
+			  "TP";
+
+	aud_clk_mosi_off: aud-clk-mosi-off-pins {
+		pins-clk-sync {
+			pinmux = <PINMUX_GPIO166__FUNC_GPIO166>,
+				 <PINMUX_GPIO167__FUNC_GPIO167>;
+			input-enable;
+			bias-pull-down;
+		};
+	};
+
+	aud_clk_mosi_on: aud-clk-mosi-on-pins {
+		pins-clk-sync {
+			pinmux = <PINMUX_GPIO166__FUNC_AUD_CLK_MOSI>,
+				 <PINMUX_GPIO167__FUNC_AUD_SYNC_MOSI>;
+		};
+	};
+
+	aud_clk_miso_off: aud-clk-miso-off-pins {
+		pins-clk-sync {
+			pinmux = <PINMUX_GPIO170__FUNC_GPIO170>,
+				 <PINMUX_GPIO171__FUNC_GPIO171>;
+			input-enable;
+			bias-pull-down;
+		};
+	};
+
+	aud_clk_miso_on: aud-clk-miso-on-pins {
+		pins-clk-sync {
+			pinmux = <PINMUX_GPIO170__FUNC_AUD_CLK_MISO>,
+				 <PINMUX_GPIO171__FUNC_AUD_SYNC_MISO>;
+		};
+	};
+
+	aud_dat_mosi_off: aud-dat-mosi-off-pins {
+		pins-dat {
+			pinmux = <PINMUX_GPIO168__FUNC_GPIO168>,
+				 <PINMUX_GPIO169__FUNC_GPIO169>;
+			input-enable;
+			bias-pull-down;
+		};
+	};
+
+	aud_dat_mosi_on: aud-dat-mosi-on-pins {
+		pins-dat {
+			pinmux = <PINMUX_GPIO168__FUNC_AUD_DAT_MOSI0>,
+				 <PINMUX_GPIO169__FUNC_AUD_DAT_MOSI1>;
+		};
+	};
+
+	aud_dat_miso_off: aud-dat-miso-off-pins {
+		pins-dat {
+			pinmux = <PINMUX_GPIO172__FUNC_GPIO172>,
+				 <PINMUX_GPIO173__FUNC_GPIO173>;
+			input-enable;
+			bias-pull-down;
+		};
+	};
+
+	aud_dat_miso_on: aud-dat-miso-on-pins {
+		pins-dat {
+			pinmux = <PINMUX_GPIO172__FUNC_AUD_DAT_MISO0>,
+				 <PINMUX_GPIO173__FUNC_AUD_DAT_MISO1>;
+			input-schmitt-enable;
+			bias-disable;
+		};
+	};
+
+	aud_gpio_i2s0_off: aud-gpio-i2s0-off-pins {
+		pins-sdata {
+			pinmux = <PINMUX_GPIO3__FUNC_GPIO3>;
+		};
+	};
+
+	aud_gpio_i2s0_on: aud-gpio-i2s0-on-pins {
+		pins-sdata {
+			pinmux = <PINMUX_GPIO3__FUNC_I2S0_DI>;
+		};
+	};
+
+	aud_gpio_i2s1_off: aud-gpio-i2s-off-pins {
+		pins-clk-sdata {
+			pinmux = <PINMUX_GPIO56__FUNC_GPIO56>,
+				 <PINMUX_GPIO57__FUNC_GPIO57>,
+				 <PINMUX_GPIO58__FUNC_GPIO58>,
+				 <PINMUX_GPIO59__FUNC_GPIO59>;
+			output-low;
+		};
+	};
+
+	aud_gpio_i2s1_on: aud-gpio-i2s1-on-pins {
+		pins-clk-sdata {
+			pinmux = <PINMUX_GPIO56__FUNC_I2S1_DO>,
+				 <PINMUX_GPIO57__FUNC_I2S1_BCK>,
+				 <PINMUX_GPIO58__FUNC_I2S1_LRCK>,
+				 <PINMUX_GPIO59__FUNC_I2S1_MCK>;
+		};
+	};
+
+	aud_gpio_i2s2_off: aud-gpio-i2s2-off-pins {
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO26__FUNC_GPIO26>,
+				 <PINMUX_GPIO27__FUNC_GPIO27>;
+			output-low;
+		};
+	};
+
+	aud_gpio_i2s2_on: aud-gpio-i2s2-on-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO26__FUNC_I2S2_BCK>,
+				 <PINMUX_GPIO27__FUNC_I2S2_LRCK>;
+			drive-strength = <4>;
+		};
+	};
+
+	aud_gpio_i2s3_off: aud-gpio-i2s3-off-pins {
+		pins-sdata {
+			pinmux = <PINMUX_GPIO4__FUNC_GPIO4>;
+			output-low;
+		};
+	};
+
+	aud_gpio_i2s3_on: aud-gpio-i2s3-on-pins {
+		pins-sdata {
+			pinmux = <PINMUX_GPIO4__FUNC_I2S3_DO>;
+			drive-strength = <4>;
+		};
+	};
+
+	aud_gpio_pcm_off: aud-gpio-pcm-off-pins {
+		pins-clk-sdata {
+			pinmux = <PINMUX_GPIO115__FUNC_GPIO115>,
+				 <PINMUX_GPIO116__FUNC_GPIO116>,
+				 <PINMUX_GPIO117__FUNC_GPIO117>,
+				 <PINMUX_GPIO118__FUNC_GPIO118>;
+			output-low;
+		};
+	};
+
+	aud_gpio_pcm_on: aud-gpio-pcm-on-pins {
+		pins-clk-sdata {
+			pinmux = <PINMUX_GPIO115__FUNC_PCM_CLK>,
+				 <PINMUX_GPIO116__FUNC_PCM_SYNC>,
+				 <PINMUX_GPIO117__FUNC_PCM_DI>,
+				 <PINMUX_GPIO118__FUNC_PCM_DO>;
+		};
+	};
+
+	aud_gpio_dmic_sec: aud-gpio-dmic-sec-pins {
+		pins {
+			pinmux = <PINMUX_GPIO23__FUNC_GPIO23>;
+			output-low;
+		};
+	};
+
+	bt_pins_reset: bt-reset-pins {
+		pins-bt-reset {
+			pinmux = <PINMUX_GPIO155__FUNC_GPIO155>;
+			output-high;
+		};
+	};
+
+	dpi_pins_sleep: dpi-sleep-pins {
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO103__FUNC_GPIO103>,
+				 <PINMUX_GPIO104__FUNC_GPIO104>,
+				 <PINMUX_GPIO105__FUNC_GPIO105>,
+				 <PINMUX_GPIO106__FUNC_GPIO106>,
+				 <PINMUX_GPIO107__FUNC_GPIO107>,
+				 <PINMUX_GPIO108__FUNC_GPIO108>,
+				 <PINMUX_GPIO109__FUNC_GPIO109>,
+				 <PINMUX_GPIO110__FUNC_GPIO110>,
+				 <PINMUX_GPIO111__FUNC_GPIO111>,
+				 <PINMUX_GPIO112__FUNC_GPIO112>,
+				 <PINMUX_GPIO113__FUNC_GPIO113>,
+				 <PINMUX_GPIO114__FUNC_GPIO114>,
+				 <PINMUX_GPIO101__FUNC_GPIO101>,
+				 <PINMUX_GPIO100__FUNC_GPIO100>,
+				 <PINMUX_GPIO102__FUNC_GPIO102>,
+				 <PINMUX_GPIO99__FUNC_GPIO99>;
+			drive-strength = <10>;
+			output-low;
+		};
+	};
+
+	dpi_pins_default: dpi-default-pins {
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO103__FUNC_DPI_DATA0>,
+				 <PINMUX_GPIO104__FUNC_DPI_DATA1>,
+				 <PINMUX_GPIO105__FUNC_DPI_DATA2>,
+				 <PINMUX_GPIO106__FUNC_DPI_DATA3>,
+				 <PINMUX_GPIO107__FUNC_DPI_DATA4>,
+				 <PINMUX_GPIO108__FUNC_DPI_DATA5>,
+				 <PINMUX_GPIO109__FUNC_DPI_DATA6>,
+				 <PINMUX_GPIO110__FUNC_DPI_DATA7>,
+				 <PINMUX_GPIO111__FUNC_DPI_DATA8>,
+				 <PINMUX_GPIO112__FUNC_DPI_DATA9>,
+				 <PINMUX_GPIO113__FUNC_DPI_DATA10>,
+				 <PINMUX_GPIO114__FUNC_DPI_DATA11>,
+				 <PINMUX_GPIO101__FUNC_DPI_HSYNC>,
+				 <PINMUX_GPIO100__FUNC_DPI_VSYNC>,
+				 <PINMUX_GPIO102__FUNC_DPI_DE>,
+				 <PINMUX_GPIO99__FUNC_DPI_PCLK>;
+			drive-strength = <10>;
+		};
+	};
+
+	ec_ap_int: cros-ec-int-pins {
+		pins-ec-ap-int-odl {
+			pinmux = <PINMUX_GPIO13__FUNC_GPIO13>;
+			input-enable;
+		};
+	};
+
+	edp_panel_fixed_pins: edp-panel-fixed-pins {
+		pins-vreg-en {
+			pinmux = <PINMUX_GPIO153__FUNC_GPIO153>;
+			output-high;
+		};
+	};
+
+	en_pp1800_dpbrdg: en-pp1800-dpbrdg-pins {
+		pins-vreg-en {
+			pinmux = <PINMUX_GPIO39__FUNC_GPIO39>;
+			output-low;
+		};
+	};
+
+	gsc_int: gsc-int-pins {
+		pins-gsc-ap-int-odl {
+			pinmux = <PINMUX_GPIO15__FUNC_GPIO15>;
+			input-enable;
+		};
+	};
+
+	i2c0_pins: i2c0-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO128__FUNC_SDA0>,
+				 <PINMUX_GPIO127__FUNC_SCL0>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	i2c1_pins: i2c1-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO130__FUNC_SDA1>,
+				 <PINMUX_GPIO129__FUNC_SCL1>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	i2c2_pins: i2c2-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO132__FUNC_SDA2>,
+				 <PINMUX_GPIO131__FUNC_SCL2>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	i2c3_pins: i2c3-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO134__FUNC_SDA3>,
+				 <PINMUX_GPIO133__FUNC_SCL3>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	i2c5_pins: i2c5-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO138__FUNC_SDA5>,
+				 <PINMUX_GPIO137__FUNC_SCL5>;
+			bias-disable;
+			drive-strength = <4>;
+			input-enable;
+		};
+	};
+
+	it6505_pins: it6505-pins {
+		pins-hpd {
+			pinmux = <PINMUX_GPIO10__FUNC_GPIO10>;
+			input-enable;
+			bias-pull-up;
+		};
+
+		pins-int {
+			pinmux = <PINMUX_GPIO8__FUNC_GPIO8>;
+			input-enable;
+			bias-pull-up;
+		};
+
+		pins-reset {
+			pinmux = <PINMUX_GPIO177__FUNC_GPIO177>;
+			output-low;
+			bias-pull-up;
+		};
+	};
+
+	mmc0_pins_default: mmc0-default-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO68__FUNC_MSDC0_CLK>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO71__FUNC_MSDC0_DAT0>,
+				 <PINMUX_GPIO72__FUNC_MSDC0_DAT1>,
+				 <PINMUX_GPIO73__FUNC_MSDC0_DAT2>,
+				 <PINMUX_GPIO74__FUNC_MSDC0_DAT3>,
+				 <PINMUX_GPIO75__FUNC_MSDC0_DAT4>,
+				 <PINMUX_GPIO76__FUNC_MSDC0_DAT5>,
+				 <PINMUX_GPIO77__FUNC_MSDC0_DAT6>,
+				 <PINMUX_GPIO78__FUNC_MSDC0_DAT7>,
+				 <PINMUX_GPIO69__FUNC_MSDC0_CMD>;
+			input-enable;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+
+		pins-rst {
+			pinmux = <PINMUX_GPIO70__FUNC_MSDC0_RSTB>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	mmc0_pins_uhs: mmc0-uhs-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO68__FUNC_MSDC0_CLK>;
+			drive-strength = <6>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO71__FUNC_MSDC0_DAT0>,
+				 <PINMUX_GPIO72__FUNC_MSDC0_DAT1>,
+				 <PINMUX_GPIO73__FUNC_MSDC0_DAT2>,
+				 <PINMUX_GPIO74__FUNC_MSDC0_DAT3>,
+				 <PINMUX_GPIO75__FUNC_MSDC0_DAT4>,
+				 <PINMUX_GPIO76__FUNC_MSDC0_DAT5>,
+				 <PINMUX_GPIO77__FUNC_MSDC0_DAT6>,
+				 <PINMUX_GPIO78__FUNC_MSDC0_DAT7>,
+				 <PINMUX_GPIO69__FUNC_MSDC0_CMD>;
+			input-enable;
+			drive-strength = <6>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+
+		pins-ds {
+			pinmux = <PINMUX_GPIO67__FUNC_MSDC0_DSL>;
+			drive-strength = <6>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-rst {
+			pinmux = <PINMUX_GPIO70__FUNC_MSDC0_RSTB>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	mmc1_pins_default: mmc1-default-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO84__FUNC_MSDC1_CLK>;
+			drive-strength = <6>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO86__FUNC_MSDC1_DAT0>,
+				 <PINMUX_GPIO87__FUNC_MSDC1_DAT1>,
+				 <PINMUX_GPIO88__FUNC_MSDC1_DAT2>,
+				 <PINMUX_GPIO89__FUNC_MSDC1_DAT3>,
+				 <PINMUX_GPIO85__FUNC_MSDC1_CMD>;
+			input-enable;
+			drive-strength = <6>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	mmc1_pins_uhs: mmc1-uhs-pins {
+		pins-clk {
+			pinmux = <PINMUX_GPIO84__FUNC_MSDC1_CLK>;
+			drive-strength = <6>;
+			bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+		};
+
+		pins-cmd-dat {
+			pinmux = <PINMUX_GPIO86__FUNC_MSDC1_DAT0>,
+				 <PINMUX_GPIO87__FUNC_MSDC1_DAT1>,
+				 <PINMUX_GPIO88__FUNC_MSDC1_DAT2>,
+				 <PINMUX_GPIO89__FUNC_MSDC1_DAT3>,
+				 <PINMUX_GPIO85__FUNC_MSDC1_CMD>;
+			input-enable;
+			drive-strength = <8>;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	mmc1_pins_eint: mmc1-eint-pins {
+		pins-dat1 {
+			pinmux = <PINMUX_GPIO87__FUNC_GPIO87>;
+			input-enable;
+			bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+		};
+	};
+
+	nor_pins_default: nor-default-pins {
+		pins-clk-dat {
+			pinmux = <PINMUX_GPIO63__FUNC_SPINOR_IO0>,
+				 <PINMUX_GPIO61__FUNC_SPINOR_CK>,
+				 <PINMUX_GPIO64__FUNC_SPINOR_IO1>;
+			drive-strength = <6>;
+			bias-pull-down;
+		};
+
+		pins-cs-dat {
+			pinmux = <PINMUX_GPIO62__FUNC_SPINOR_CS>,
+				 <PINMUX_GPIO65__FUNC_SPINOR_IO2>,
+				 <PINMUX_GPIO66__FUNC_SPINOR_IO3>;
+			drive-strength = <6>;
+			bias-pull-up;
+		};
+	};
+
+	pen_eject: pen-eject-pins {
+		pins {
+			pinmux = <PINMUX_GPIO18__FUNC_GPIO18>;
+			input-enable;
+			/* External pull-up. */
+			bias-disable;
+		};
+	};
+
+	pwm0_pin: disp-pwm-pins {
+		pins {
+			pinmux = <PINMUX_GPIO97__FUNC_DISP_PWM>;
+			output-high;
+		};
+	};
+
+	rt1019p_pins_default: rt1019p-default-pins {
+		pins-sdb {
+			pinmux = <PINMUX_GPIO150__FUNC_GPIO150>;
+			output-low;
+		};
+	};
+
+	scp_pins: scp-default-pins {
+		pins-scp-uart {
+			pinmux = <PINMUX_GPIO48__FUNC_TP_URXD2_AO>,
+				 <PINMUX_GPIO49__FUNC_TP_UTXD2_AO>;
+		};
+	};
+
+	spi1_pins: spi1-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO40__FUNC_SPI1_CLK_A>,
+				 <PINMUX_GPIO41__FUNC_SPI1_CSB_A>,
+				 <PINMUX_GPIO42__FUNC_SPI1_MO_A>,
+				 <PINMUX_GPIO43__FUNC_SPI1_MI_A>;
+			bias-disable;
+			input-enable;
+		};
+	};
+
+	spi2_pins: spi2-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO44__FUNC_SPI2_CLK_A>,
+				 <PINMUX_GPIO45__FUNC_GPIO45>,
+				 <PINMUX_GPIO46__FUNC_SPI2_MO_A>,
+				 <PINMUX_GPIO47__FUNC_SPI2_MI_A>;
+			bias-disable;
+			input-enable;
+		};
+	};
+
+	spmi_pins: spmi-pins {
+		pins-bus {
+			pinmux = <PINMUX_GPIO183__FUNC_SPMI_SCL>,
+				 <PINMUX_GPIO184__FUNC_SPMI_SDA>;
+		};
+	};
+
+	touchscreen_pins: touchscreen-pins {
+		pins-irq {
+			pinmux = <PINMUX_GPIO12__FUNC_GPIO12>;
+			input-enable;
+			bias-pull-up;
+		};
+
+		pins-reset {
+			pinmux = <PINMUX_GPIO60__FUNC_GPIO60>;
+			output-high;
+		};
+
+		pins-report-sw {
+			pinmux = <PINMUX_GPIO37__FUNC_GPIO37>;
+			output-low;
+		};
+	};
+
+	trackpad_pin: trackpad-default-pins {
+		pins-int-n {
+			pinmux = <PINMUX_GPIO11__FUNC_GPIO11>;
+			input-enable;
+			bias-disable; /* pulled externally */
+		};
+	};
+
+	wifi_enable_pin: wifi-enable-pins {
+		pins-wifi-enable {
+			pinmux = <PINMUX_GPIO54__FUNC_GPIO54>;
+		};
+	};
+
+	wifi_wakeup_pin: wifi-wakeup-pins {
+		pins-wifi-wakeup {
+			pinmux = <PINMUX_GPIO7__FUNC_GPIO7>;
+			input-enable;
+		};
+	};
+};
+
+&pwm0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm0_pin>;
+	status = "okay";
+};
+
+&pwrap {
+	pmic {
+		compatible = "mediatek,mt6366", "mediatek,mt6358";
+		interrupt-controller;
+		interrupts-extended = <&pio 201 IRQ_TYPE_LEVEL_HIGH>;
+		#interrupt-cells = <2>;
+
+		mt6366codec: codec {
+			compatible = "mediatek,mt6366-sound", "mediatek,mt6358-sound";
+			Avdd-supply = <&mt6366_vaud28_reg>;
+			mediatek,dmic-mode = <1>; /* one-wire */
+		};
+
+		mt6366_regulators: regulators {
+			compatible = "mediatek,mt6366-regulator", "mediatek,mt6358-regulator";
+			vsys-ldo1-supply = <&pp4200_z2>;
+			vsys-ldo2-supply = <&pp4200_z2>;
+			vsys-ldo3-supply = <&pp4200_z2>;
+			vsys-vcore-supply = <&pp4200_z2>;
+			vsys-vdram1-supply = <&pp4200_z2>;
+			vsys-vgpu-supply = <&pp4200_z2>;
+			vsys-vmodem-supply = <&pp4200_z2>;
+			vsys-vpa-supply = <&pp4200_z2>;
+			vsys-vproc11-supply = <&pp4200_z2>;
+			vsys-vproc12-supply = <&pp4200_z2>;
+			vsys-vs1-supply = <&pp4200_z2>;
+			vsys-vs2-supply = <&pp4200_z2>;
+			vs1-ldo1-supply = <&mt6366_vs1_reg>;
+			vs2-ldo1-supply = <&mt6366_vdram1_reg>;
+			vs2-ldo2-supply = <&mt6366_vs2_reg>;
+			vs2-ldo3-supply = <&mt6366_vs2_reg>;
+
+			vcore {
+				regulator-name = "pp0750_dvdd_core";
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <800000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <200>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-always-on;
+			};
+
+			mt6366_vdram1_reg: vdram1 {
+				regulator-name = "pp1125_emi_vdd2";
+				regulator-min-microvolt = <1125000>;
+				regulator-max-microvolt = <1125000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <0>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-always-on;
+			};
+
+			mt6366_vgpu_reg: vgpu {
+				/*
+				 * Called "ppvar_dvdd_gpu" in the schematic.
+				 * Called "ppvar_dvdd_vgpu" here to match
+				 * regulator coupling requirements.
+				 */
+				regulator-name = "ppvar_dvdd_vgpu";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <200>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-coupled-with = <&mt6366_vsram_gpu_reg>;
+				regulator-coupled-max-spread = <10000>;
+			};
+
+			mt6366_vproc11_reg: vproc11 {
+				regulator-name = "ppvar_dvdd_proc_bc_mt6366";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <200>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-always-on;
+			};
+
+			mt6366_vproc12_reg: vproc12 {
+				regulator-name = "ppvar_dvdd_proc_lc";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <200>;
+				regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+							   MT6397_BUCK_MODE_FORCE_PWM>;
+				regulator-always-on;
+			};
+
+			mt6366_vs1_reg: vs1 {
+				regulator-name = "pp2000_vs1";
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <0>;
+				regulator-always-on;
+			};
+
+			mt6366_vs2_reg: vs2 {
+				regulator-name = "pp1350_vs2";
+				regulator-min-microvolt = <1350000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <0>;
+				regulator-always-on;
+			};
+
+			va12 {
+				regulator-name = "pp1200_va12";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-enable-ramp-delay = <270>;
+				regulator-always-on;
+			};
+
+			mt6366_vaud28_reg: vaud28 {
+				regulator-name = "pp2800_vaud28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vaux18_reg: vaux18 {
+				regulator-name = "pp1840_vaux18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1840000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vbif28_reg: vbif28 {
+				regulator-name = "pp2800_vbif28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vcn18_reg: vcn18 {
+				regulator-name = "pp1800_vcn18_x";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vcn28_reg: vcn28 {
+				regulator-name = "pp2800_vcn28_x";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vefuse_reg: vefuse {
+				regulator-name = "pp1800_vefuse";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vfe28_reg: vfe28 {
+				regulator-name = "pp2800_vfe28_x";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vemc_reg: vemc {
+				regulator-name = "pp3000_vemc";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <60>;
+			};
+
+			mt6366_vibr_reg: vibr {
+				regulator-name = "pp2800_vibr_x";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <60>;
+			};
+
+			mt6366_vio18_reg: vio18 {
+				regulator-name = "pp1800_vio18_s3";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <2700>;
+				regulator-always-on;
+			};
+
+			mt6366_vio28_reg: vio28 {
+				regulator-name = "pp2800_vio28_x";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			mt6366_vm18_reg: vm18 {
+				regulator-name = "pp1800_emi_vdd1";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1840000>;
+				regulator-enable-ramp-delay = <325>;
+				regulator-always-on;
+			};
+
+			mt6366_vmc_reg: vmc {
+				regulator-name = "pp3000_vmc";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <60>;
+			};
+
+			mt6366_vmddr_reg: vmddr {
+				regulator-name = "pm0750_emi_vmddr";
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <750000>;
+				regulator-enable-ramp-delay = <325>;
+				regulator-always-on;
+			};
+
+			mt6366_vmch_reg: vmch {
+				regulator-name = "pp3000_vmch";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <60>;
+			};
+
+			mt6366_vcn33_reg: vcn33 {
+				regulator-name = "pp3300_vcn33_x";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <270>;
+			};
+
+			vdram2 {
+				regulator-name = "pp0600_emi_vddq";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <600000>;
+				regulator-enable-ramp-delay = <3300>;
+				regulator-always-on;
+			};
+
+			mt6366_vrf12_reg: vrf12 {
+				regulator-name = "pp1200_vrf12_x";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-enable-ramp-delay = <120>;
+			};
+
+			mt6366_vrf18_reg: vrf18 {
+				regulator-name = "pp1800_vrf18_x";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <120>;
+			};
+
+			vsim1 {
+				regulator-name = "pp1860_vsim1_x";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1860000>;
+				regulator-enable-ramp-delay = <540>;
+			};
+
+			mt6366_vsim2_reg: vsim2 {
+				regulator-name = "pp2760_vsim2_x";
+				regulator-min-microvolt = <2700000>;
+				regulator-max-microvolt = <2760000>;
+				regulator-enable-ramp-delay = <540>;
+			};
+
+			mt6366_vsram_gpu_reg: vsram-gpu {
+				regulator-name = "pp0900_dvdd_sram_gpu";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <1050000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <240>;
+				regulator-coupled-with = <&mt6366_vgpu_reg>;
+				regulator-coupled-max-spread = <10000>;
+			};
+
+			mt6366_vsram_others_reg: vsram-others {
+				regulator-name = "pp0900_dvdd_sram_core";
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <240>;
+				regulator-always-on;
+			};
+
+			mt6366_vsram_proc11_reg: vsram-proc11 {
+				regulator-name = "pp0900_dvdd_sram_bc";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <1120000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <240>;
+				regulator-always-on;
+			};
+
+			mt6366_vsram_proc12_reg: vsram-proc12 {
+				regulator-name = "pp0900_dvdd_sram_lc";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <1120000>;
+				regulator-ramp-delay = <6250>;
+				regulator-enable-ramp-delay = <240>;
+				regulator-always-on;
+			};
+
+			vusb {
+				regulator-name = "pp3070_vusb";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3070000>;
+				regulator-enable-ramp-delay = <270>;
+				regulator-always-on;
+			};
+
+			vxo22 {
+				regulator-name = "pp2240_vxo22";
+				regulator-min-microvolt = <2200000>;
+				regulator-max-microvolt = <2240000>;
+				regulator-enable-ramp-delay = <120>;
+				/* Feeds DCXO internally */
+				regulator-always-on;
+			};
+		};
+
+		rtc {
+			compatible = "mediatek,mt6366-rtc", "mediatek,mt6358-rtc";
+		};
+	};
+};
+
+&scp {
+	pinctrl-names = "default";
+	pinctrl-0 = <&scp_pins>;
+	firmware-name = "mediatek/mt8186/scp.img";
+	memory-region = <&scp_mem>;
+	status = "okay";
+
+	cros-ec-rpmsg {
+		compatible = "google,cros-ec-rpmsg";
+		mediatek,rpmsg-name = "cros-ec-rpmsg";
+	};
+};
+
+&spi1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi1_pins>;
+	mediatek,pad-select = <0>;
+	status = "okay";
+
+	cros_ec: ec at 0 {
+		compatible = "google,cros-ec-spi";
+		reg = <0>;
+		interrupts-extended = <&pio 13 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ec_ap_int>;
+		spi-max-frequency = <1000000>;
+
+		i2c_tunnel: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			google,remote-bus = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		typec {
+			compatible = "google,cros-ec-typec";
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			usb_c0: connector at 0 {
+				compatible = "usb-c-connector";
+				reg = <0>;
+				label = "left";
+				power-role = "dual";
+				data-role = "host";
+				try-power-role = "source";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port at 1 {
+						reg = <1>;
+
+						typec_port0: endpoint { };
+					};
+				};
+			};
+
+			usb_c1: connector at 1 {
+				compatible = "usb-c-connector";
+				reg = <1>;
+				label = "right";
+				power-role = "dual";
+				data-role = "host";
+				try-power-role = "source";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port at 1 {
+						reg = <1>;
+
+						typec_port1: endpoint { };
+					};
+				};
+			};
+		};
+	};
+};
+
+&spi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2_pins>;
+	cs-gpios = <&pio 45 GPIO_ACTIVE_LOW>;
+	mediatek,pad-select = <0>;
+	status = "okay";
+
+	tpm at 0 {
+		compatible = "google,cr50";
+		reg = <0>;
+		interrupts-extended = <&pio 15 IRQ_TYPE_EDGE_RISING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gsc_int>;
+		spi-max-frequency = <1000000>;
+	};
+};
+
+&ssusb0 {
+	status = "okay";
+};
+
+&ssusb1 {
+	status = "okay";
+};
+
+&u3phy0 {
+	status = "okay";
+};
+
+&u3phy1 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&usb_host0 {
+	vbus-supply = <&pp3300_s3>;
+	status = "okay";
+};
+
+&usb_host1 {
+	#address-cells = <2>;
+	#size-cells = <2>;
+	vbus-supply = <&usb_p1_vbus>;
+	status = "okay";
+};
+
+&watchdog {
+	mediatek,reset-by-toprgu;
+};
+
+#include <arm/cros-ec-keyboard.dtsi>
+#include <arm/cros-ec-sbs.dtsi>
-- 
2.43.0.472.g3155946c3a-goog



From wenst at chromium.org  Wed Dec 13 07:04:29 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:29 +0800
Subject: [PATCH v4 5/9] dt-bindings: arm: mediatek: Add MT8186 Magneton Chromebooks
In-Reply-To: <20231213150435.4134390-1-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
Message-ID: <20231213150435.4134390-6-wenst@chromium.org>

Add entries for the MT8186 based Chromebooks, also collectively known
as the Lenovo IdeaPad Slim 3 Chromebook (14M868). It is also based on
the "Steelix" design. Being a laptop instead of a convertible device,
there is no touchscreen or stylus, which is similar to Rusty. However
Magneton does not have ports on the right side of the device.

Three variants are listed separately. These use different touchscreen
controllers, or lack a touchscreen altogether.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
Changes since v3:
- Collected reviewed-by from Angelo

Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.
---
 .../devicetree/bindings/arm/mediatek.yaml      | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 85d394e390f0..155ba22e2ad3 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -206,6 +206,24 @@ properties:
           - enum:
               - mediatek,mt8183-pumpkin
           - const: mediatek,mt8183
+      - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
+        items:
+          - const: google,steelix-sku393219
+          - const: google,steelix-sku393216
+          - const: google,steelix
+          - const: mediatek,mt8186
+      - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
+        items:
+          - const: google,steelix-sku393220
+          - const: google,steelix-sku393217
+          - const: google,steelix
+          - const: mediatek,mt8186
+      - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
+        items:
+          - const: google,steelix-sku393221
+          - const: google,steelix-sku393218
+          - const: google,steelix
+          - const: mediatek,mt8186
       - description: Google Rusty (Lenovo 100e Chromebook Gen 4)
         items:
           - const: google,steelix-sku196609
-- 
2.43.0.472.g3155946c3a-goog



From wenst at chromium.org  Wed Dec 13 07:04:31 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:31 +0800
Subject: [PATCH v4 7/9] arm64: dts: mediatek: Introduce MT8186 Steelix
In-Reply-To: <20231213150435.4134390-1-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
Message-ID: <20231213150435.4134390-8-wenst@chromium.org>

The MT8186 Steelix, also known as the Lenovo 300e Yoga Chromebook Gen 4,
is a convertible device based on a common design of the same name. The
device comes in different variants. Of them, whether a world facing
camera is integrated is the only differentiating factor between the
two device trees added. The different SKU IDs describe this alone.

The other device difference is the touchpad component used. This is
simply handled by having both possible components described in the
device tree, and letting the implementation figure out which one is
actually available. The system bootloader / firmware does not
differentiate this in that they share the same SKU IDs.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
---
Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Removed trackpad_pins reference (moved to i2c2 in corsola dtsi)
- Fixed copyright year
- Renamed touchpad to trackpad
---
 arch/arm64/boot/dts/mediatek/Makefile         |   2 +
 .../mt8186-corsola-steelix-sku131072.dts      |  18 ++
 .../mt8186-corsola-steelix-sku131073.dts      |  18 ++
 .../dts/mediatek/mt8186-corsola-steelix.dtsi  | 195 ++++++++++++++++++
 4 files changed, 233 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 442af61b1305..7bd9471b89f9 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -43,6 +43,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131072.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131073.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
new file mode 100644
index 000000000000..eae17bca8585
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Steelix board";
+	compatible = "google,steelix-sku131072", "google,steelix",
+		     "mediatek,mt8186";
+	chassis-type = "convertible";
+};
+
+&mt6366codec {
+	mediatek,dmic-mode = <0>; /* two-wire */
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
new file mode 100644
index 000000000000..a55375b95d0d
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Steelix board";
+	compatible = "google,steelix-sku131073", "google,steelix",
+		     "mediatek,mt8186";
+	chassis-type = "convertible";
+};
+
+&mt6366codec {
+	mediatek,dmic-mode = <1>; /* one-wire */
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
new file mode 100644
index 000000000000..47262bc499ad
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/{
+	pp1000_edpbrdg: regulator-pp1000-edpbrdg {
+		compatible = "regulator-fixed";
+		regulator-name = "pp1000_edpbrdg";
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp1000_edpbrdg>;
+		enable-active-high;
+		regulator-boot-on;
+		gpio = <&pio 29 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&pp3300_z2>;
+	};
+
+	pp1800_edpbrdg_dx: regulator-pp1800-edpbrdg-dx {
+		compatible = "regulator-fixed";
+		regulator-name = "pp1800_edpbrdg_dx";
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp1800_edpbrdg>;
+		enable-active-high;
+		regulator-boot-on;
+		gpio = <&pio 30 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&mt6366_vio18_reg>;
+	};
+
+	pp3300_edp_dx: regulator-pp3300-edp-dx {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_edp_dx";
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp3300_edpbrdg>;
+		enable-active-high;
+		regulator-boot-on;
+		gpio = <&pio 31 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&pp3300_z2>;
+	};
+};
+
+&dsi_out {
+	remote-endpoint = <&anx7625_in>;
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+
+	anx_bridge: anx7625 at 58 {
+		compatible = "analogix,anx7625";
+		reg = <0x58>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&anx7625_pins>;
+		enable-gpios = <&pio 96 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>;
+		vdd10-supply = <&pp1000_edpbrdg>;
+		vdd18-supply = <&pp1800_edpbrdg_dx>;
+		vdd33-supply = <&pp3300_edp_dx>;
+		analogix,lane0-swing = /bits/ 8 <0x70 0x30>;
+		analogix,lane1-swing = /bits/ 8 <0x70 0x30>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				anx7625_in: endpoint {
+					remote-endpoint = <&dsi_out>;
+					data-lanes = <0 1 2 3>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+
+				anx7625_out: endpoint {
+					remote-endpoint = <&panel_in>;
+				};
+			};
+		};
+
+		aux-bus {
+			panel: panel {
+				compatible = "edp-panel";
+				power-supply = <&pp3300_disp_x>;
+				backlight = <&backlight_lcd0>;
+
+				port {
+					panel_in: endpoint {
+						remote-endpoint = <&anx7625_out>;
+					};
+				};
+			};
+		};
+	};
+};
+
+&i2c1 {
+	touchscreen: touchscreen at 5d {
+		compatible = "goodix,gt7375p";
+		reg = <0x5d>;
+		interrupts-extended = <&pio 12 IRQ_TYPE_EDGE_FALLING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>;
+		vdd-supply = <&pp3300_s3>;
+		goodix,no-reset-during-suspend;
+	};
+};
+
+&i2c2 {
+	i2c-scl-internal-delay-ns = <22000>;
+
+	/* second source component */
+	trackpad at 2c {
+		compatible = "hid-over-i2c";
+		reg = <0x2c>;
+		hid-descr-addr = <0x20>;
+		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
+		vdd-supply = <&pp3300_s3>;
+		wakeup-source;
+	};
+};
+
+&keyboard_controller {
+	function-row-physmap = <
+		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
+		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
+		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
+		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
+		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
+		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
+		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
+		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
+		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
+		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
+	>;
+
+	linux,keymap = <
+		MATRIX_KEY(0x00, 0x02, KEY_BACK)
+		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
+		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
+		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
+		MATRIX_KEY(0x03, 0x04, KEY_BRIGHTNESSDOWN)
+		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSUP)
+		MATRIX_KEY(0x01, 0x04, KEY_MICMUTE)
+		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
+		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
+		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
+		CROS_STD_MAIN_KEYMAP
+	>;
+};
+
+&pio {
+	anx7625_pins: anx7625-pins {
+		pins1 {
+			pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
+				 <PINMUX_GPIO98__FUNC_GPIO98>;
+			output-low;
+		};
+
+		pins2 {
+			pinmux = <PINMUX_GPIO9__FUNC_GPIO9>;
+			input-enable;
+			bias-disable;
+		};
+	};
+
+	en_pp1000_edpbrdg: pp1000-edpbrdg-en-pins {
+		pins {
+			pinmux = <PINMUX_GPIO29__FUNC_GPIO29>;
+			output-low;
+		};
+	};
+
+	en_pp1800_edpbrdg: pp1800-edpbrdg-en-pins {
+		pins {
+			pinmux = <PINMUX_GPIO30__FUNC_GPIO30>;
+			output-low;
+		};
+	};
+
+	en_pp3300_edpbrdg: pp3300-edpbrdg-en-pins {
+		pins {
+			pinmux = <PINMUX_GPIO31__FUNC_GPIO31>;
+			output-low;
+		};
+	};
+};
-- 
2.43.0.472.g3155946c3a-goog



From wenst at chromium.org  Wed Dec 13 07:04:32 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:32 +0800
Subject: [PATCH v4 8/9] arm64: dts: mediatek: Add MT8186 Steelix platform based Rusty
In-Reply-To: <20231213150435.4134390-1-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
Message-ID: <20231213150435.4134390-9-wenst@chromium.org>

MT8186 Rusty, otherwise known as the Lenovo 100e Chromebook Gen 4, is an
MT8186 based laptop. It is based on the "Steelix" design. Being a laptop
instead of a convertible device, there is no touchscreen or stylus.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
Changes since v3:
- Collected reviewed-by from Angelo

Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.
- Mark missing components as disabled instead of deleting the node
---
 arch/arm64/boot/dts/mediatek/Makefile         |  1 +
 .../mt8186-corsola-rusty-sku196608.dts        | 26 +++++++++++++++++++
 2 files changed, 27 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 7bd9471b89f9..6b05f1f2e645 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -43,6 +43,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-rusty-sku196608.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131072.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131073.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts
new file mode 100644
index 000000000000..731b0d60228d
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-rusty-sku196608.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Rusty board";
+	compatible = "google,steelix-sku196609", "google,steelix-sku196608",
+		     "google,steelix", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+&gpio_keys {
+	status = "disabled";
+};
+
+&i2c1 {
+	status = "disabled";
+};
+
+&touchscreen {
+	status = "disabled";
+};
-- 
2.43.0.472.g3155946c3a-goog



From wenst at chromium.org  Wed Dec 13 07:04:33 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Wed, 13 Dec 2023 23:04:33 +0800
Subject: [PATCH v4 9/9] arm64: dts: mediatek: Add MT8186 Magneton Chromebooks
In-Reply-To: <20231213150435.4134390-1-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
Message-ID: <20231213150435.4134390-10-wenst@chromium.org>

Add entries for the MT8186 based Chromebooks, also collectively known
as the Lenovo IdeaPad Slim 3 Chromebook (14M868). It is also based on
the "Steelix" design. Being a laptop instead of a convertible device,
there is no stylus, which is similar to Rusty. However Magneton does
not have ports on the right side of the device.

Three variants are listed separately. These use different touchscreen
controllers, or lack a touchscreen altogether.

Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
Changes since v3:
- Collected reviewed-by from Angelo

Changes since v2:
- Picked up Conor's ack

Changes since v1:
- Reorder SKU numbers in descending order.
- Mark missing components as disabled instead of deleting the node
- Switched to interrupts-extended in touchscreen nodes
- Dropped reset-gpios from touchscreen nodes
- Drop status = "okay", which is the default
---
 arch/arm64/boot/dts/mediatek/Makefile         |  3 ++
 .../mt8186-corsola-magneton-sku393216.dts     | 39 +++++++++++++++++++
 .../mt8186-corsola-magneton-sku393217.dts     | 39 +++++++++++++++++++
 .../mt8186-corsola-magneton-sku393218.dts     | 26 +++++++++++++
 4 files changed, 107 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 6b05f1f2e645..7e365e9516ab 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -43,6 +43,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-magneton-sku393216.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-magneton-sku393217.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-magneton-sku393218.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-rusty-sku196608.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131072.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131073.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts
new file mode 100644
index 000000000000..c9673381ad3b
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393216.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Magneton board";
+	compatible = "google,steelix-sku393219", "google,steelix-sku393216",
+		     "google,steelix", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+&gpio_keys {
+	status = "disabled";
+};
+
+&i2c1 {
+	touchscreen at 10 {
+		compatible = "hid-over-i2c";
+		reg = <0x10>;
+		interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		vdd-supply = <&pp3300_s3>;
+		post-power-on-delay-ms = <350>;
+		hid-descr-addr = <0x0001>;
+	};
+};
+
+&touchscreen {
+	status = "disabled";
+};
+
+&usb_c1 {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts
new file mode 100644
index 000000000000..28e3bbe56421
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393217.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Magneton board";
+	compatible = "google,steelix-sku393220", "google,steelix-sku393217",
+		     "google,steelix", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+&gpio_keys {
+	status = "disabled";
+};
+
+&i2c1 {
+	touchscreen at 40 {
+		compatible = "hid-over-i2c";
+		reg = <0x40>;
+		interrupts-extended = <&pio 12 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		vdd-supply = <&pp3300_s3>;
+		post-power-on-delay-ms = <450>;
+		hid-descr-addr = <0x0001>;
+	};
+};
+
+&touchscreen {
+	status = "disabled";
+};
+
+&usb_c1 {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts
new file mode 100644
index 000000000000..332894218f07
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-magneton-sku393218.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2022 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8186-corsola-steelix.dtsi"
+
+/ {
+	model = "Google Magneton board";
+	compatible = "google,steelix-sku393221", "google,steelix-sku393218",
+		     "google,steelix", "mediatek,mt8186";
+	chassis-type = "laptop";
+};
+
+&gpio_keys {
+	status = "disabled";
+};
+
+&touchscreen {
+	status = "disabled";
+};
+
+&usb_c1 {
+	status = "disabled";
+};
-- 
2.43.0.472.g3155946c3a-goog



From olteanv at gmail.com  Wed Dec 13 07:19:10 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Wed, 13 Dec 2023 17:19:10 +0200
Subject: [PATCH net-next 00/15] MT7530 DSA subdriver improvements
In-Reply-To: <45221d69-a780-4e81-b4c3-db1b9894a1db@arinc9.com>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <45221d69-a780-4e81-b4c3-db1b9894a1db@arinc9.com>
Message-ID: <20231213151910.hr3n4px7a4upc372@skbuf>

Hi Ar?n?,

On Sat, Dec 02, 2023 at 11:52:13AM +0300, Ar?n? ?NAL wrote:
> Can I receive reviews for patches 6, 12, 13, 14, and 15?
> 
> Thanks.
> Ar?n?

Sorry, I don't have time to look at this old thread anymore.

Please repost the series with the feedback you got so far addressed.
Also, you can try to split into smaller, more cohesive groups of
patches, that have higher chances of getting merged.


From mripard at kernel.org  Wed Dec 13 07:22:32 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Wed, 13 Dec 2023 16:22:32 +0100
Subject: (subset) [PATCH v5 18/44] drm/vc4: hdmi: Create destroy state
 implementation
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-18-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
 <20231207-kms-hdmi-connector-state-v5-18-6538e19d634d@kernel.org>
Message-ID: <170248095242.191897.1505855856456253349.b4-ty@kernel.org>

On Thu, 07 Dec 2023 16:49:41 +0100, Maxime Ripard wrote:
> Even though we were rolling our own custom state for the vc4 HDMI
> controller driver, we were still using the generic helper to destroy
> that state.
> 
> It was mostly working since the underlying state is the first member of
> our state so the pointers are probably equal in all relevant cases, but
> it's still fragile so let's fix this properly.
> 
> [...]

Applied to drm/drm-misc (drm-misc-next).

Thanks!
Maxime



From conor at kernel.org  Wed Dec 13 07:23:32 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 15:23:32 +0000
Subject: [PATCH v5 12/16] riscv: dts: sophgo: Add T-Head PMU extension
 for cv1800b
In-Reply-To: <20231213070301.1684751-13-peterlin@andestech.com>
References: <20231213070301.1684751-1-peterlin@andestech.com>
 <20231213070301.1684751-13-peterlin@andestech.com>
Message-ID: <20231213-creatable-skintight-be6749ec63e5@spud>

On Wed, Dec 13, 2023 at 03:02:57PM +0800, Yu Chien Peter Lin wrote:
> xtheadpmu stands for T-Head Performance Monitor Unit extension.
> Based on the added T-Head PMU ISA string, the SBI PMU driver
> will make use of the non-standard irq source.
> 
> Signed-off-by: Yu Chien Peter Lin <peterlin at andestech.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> ---
> Changes v4 -> v5:
>   - New patch
> ---
>  arch/riscv/boot/dts/sophgo/cv1800b.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/boot/dts/sophgo/cv1800b.dtsi b/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
> index aec6401a467b..8c0143f0a01b 100644
> --- a/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
> +++ b/arch/riscv/boot/dts/sophgo/cv1800b.dtsi
> @@ -29,7 +29,7 @@ cpu0: cpu at 0 {
>  			riscv,isa = "rv64imafdc";
>  			riscv,isa-base = "rv64i";
>  			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr",
> -					       "zifencei", "zihpm";
> +					       "zifencei", "zihpm", "xtheadpmu";
>  
>  			cpu0_intc: interrupt-controller {
>  				compatible = "riscv,cpu-intc";
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/839cd24d/attachment.sig>

From conor at kernel.org  Wed Dec 13 07:23:58 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 15:23:58 +0000
Subject: [PATCH v5 14/16] riscv: dts: thead: Add T-Head PMU extension for
 th1520
In-Reply-To: <20231213070301.1684751-15-peterlin@andestech.com>
References: <20231213070301.1684751-1-peterlin@andestech.com>
 <20231213070301.1684751-15-peterlin@andestech.com>
Message-ID: <20231213-placate-flashily-fa1032e5fbbe@spud>

On Wed, Dec 13, 2023 at 03:02:59PM +0800, Yu Chien Peter Lin wrote:
> xtheadpmu stands for T-Head Performance Monitor Unit extension.
> Based on the added T-Head PMU ISA string, the SBI PMU driver
> will make use of the non-standard irq source.
> 
> Signed-off-by: Yu Chien Peter Lin <peterlin at andestech.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> ---
> Changes v4 -> v5:
>   - New patch
> ---
>  arch/riscv/boot/dts/thead/th1520.dtsi | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/riscv/boot/dts/thead/th1520.dtsi b/arch/riscv/boot/dts/thead/th1520.dtsi
> index ba4d2c673ac8..2dad2b22824a 100644
> --- a/arch/riscv/boot/dts/thead/th1520.dtsi
> +++ b/arch/riscv/boot/dts/thead/th1520.dtsi
> @@ -22,7 +22,7 @@ c910_0: cpu at 0 {
>  			riscv,isa = "rv64imafdc";
>  			riscv,isa-base = "rv64i";
>  			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr",
> -					       "zifencei", "zihpm";
> +					       "zifencei", "zihpm", "xtheadpmu";
>  			reg = <0>;
>  			i-cache-block-size = <64>;
>  			i-cache-size = <65536>;
> @@ -46,7 +46,7 @@ c910_1: cpu at 1 {
>  			riscv,isa = "rv64imafdc";
>  			riscv,isa-base = "rv64i";
>  			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr",
> -					       "zifencei", "zihpm";
> +					       "zifencei", "zihpm", "xtheadpmu";
>  			reg = <1>;
>  			i-cache-block-size = <64>;
>  			i-cache-size = <65536>;
> @@ -70,7 +70,7 @@ c910_2: cpu at 2 {
>  			riscv,isa = "rv64imafdc";
>  			riscv,isa-base = "rv64i";
>  			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr",
> -					       "zifencei", "zihpm";
> +					       "zifencei", "zihpm", "xtheadpmu";
>  			reg = <2>;
>  			i-cache-block-size = <64>;
>  			i-cache-size = <65536>;
> @@ -94,7 +94,7 @@ c910_3: cpu at 3 {
>  			riscv,isa = "rv64imafdc";
>  			riscv,isa-base = "rv64i";
>  			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr",
> -					       "zifencei", "zihpm";
> +					       "zifencei", "zihpm", "xtheadpmu";
>  			reg = <3>;
>  			i-cache-block-size = <64>;
>  			i-cache-size = <65536>;
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/ae2c42bf/attachment-0001.sig>

From conor at kernel.org  Wed Dec 13 07:24:25 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 15:24:25 +0000
Subject: [PATCH v5 13/16] riscv: dts: sophgo: Add T-Head PMU extension
 for sg2042
In-Reply-To: <20231213070301.1684751-14-peterlin@andestech.com>
References: <20231213070301.1684751-1-peterlin@andestech.com>
 <20231213070301.1684751-14-peterlin@andestech.com>
Message-ID: <20231213-maturely-freezing-07edd52717d9@spud>

On Wed, Dec 13, 2023 at 03:02:58PM +0800, Yu Chien Peter Lin wrote:
> xtheadpmu stands for T-Head Performance Monitor Unit extension.
> Based on the added T-Head PMU ISA string, the SBI PMU driver
> will make use of the non-standard irq source.
> 
> Signed-off-by: Yu Chien Peter Lin <peterlin at andestech.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/711d538c/attachment.sig>

From j-luthra at ti.com  Wed Dec 13 07:24:21 2023
From: j-luthra at ti.com (Jai Luthra)
Date: Wed, 13 Dec 2023 20:54:21 +0530
Subject: [PATCH v2 0/3] arm64: dts: ti: k3: Add additioal regs for DMA
 components
In-Reply-To: <20231213135138.929517-1-vigneshr@ti.com>
References: <20231213135138.929517-1-vigneshr@ti.com>
Message-ID: <ve2zjmq3adj6v4vqeecitvad2ndlzxsldu2wdpqh6e4xdb3cqs@xvwwbzqq5avr>

Hi Vignesh,

On Dec 13, 2023 at 19:21:35 +0530, Raghavendra, Vignesh wrote:
> This adds additional reg ranges which are not directly used by Linux but
> by other components like U-Boot
> 
> Binding is accepted via dmaengine tree and is in linux-next[0]
> 
> [0] https://lore.kernel.org/dmaengine/170083278148.771517.1841889156174413563.b4-ty at kernel.org/
> 
> v2:
> Extend register ranges to match TRM as pointed out by Jai

For the series,

Reviewed-by: Jai Luthra <j-luthra at ti.com>

> 
> v1: https://lore.kernel.org/linux-arm-kernel/20231212111634.3515175-1-vigneshr at ti.com/
> 
> Manorit Chawdhry (2):
>   arm64: dts: ti: k3-am65: Add additional regs for DMA components
>   arm64: dts: ti: k3-j7*: Add additional regs for DMA components
> 
> Vignesh Raghavendra (1):
>   arm64: dts: ti: k3-am6*: Add additional regs for DMA components
> 
>  arch/arm64/boot/dts/ti/k3-am62-main.dtsi       | 18 ++++++++++++++----
>  arch/arm64/boot/dts/ti/k3-am62a-main.dtsi      | 18 ++++++++++++++----
>  arch/arm64/boot/dts/ti/k3-am62p-main.dtsi      | 18 ++++++++++++++----
>  arch/arm64/boot/dts/ti/k3-am64-main.dtsi       | 18 ++++++++++++++----
>  arch/arm64/boot/dts/ti/k3-am65-main.dtsi       |  8 ++++++--
>  arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi        |  8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j7200-main.dtsi      |  8 ++++++--
>  .../arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi |  8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j721e-main.dtsi      |  8 ++++++--
>  .../arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi |  8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi     |  8 ++++++--
>  .../boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi      |  8 ++++++--
>  arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi     |  8 ++++++--
>  .../boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi      |  8 ++++++--
>  14 files changed, 116 insertions(+), 36 deletions(-)
> 
> -- 
> 2.43.0
> 

-- 
Thanks,
Jai

GPG Fingerprint: 4DE0 D818 E5D5 75E8 D45A AFC5 43DE 91F9 249A 7145
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/6f4e1059/attachment.sig>

From conor at kernel.org  Wed Dec 13 07:24:57 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 15:24:57 +0000
Subject: [PATCH v5 15/16] riscv: dts: renesas: Add Andes PMU extension
 for r9a07g043f
In-Reply-To: <20231213070301.1684751-16-peterlin@andestech.com>
References: <20231213070301.1684751-1-peterlin@andestech.com>
 <20231213070301.1684751-16-peterlin@andestech.com>
Message-ID: <20231213-porous-panic-015409053e1d@spud>

On Wed, Dec 13, 2023 at 03:03:00PM +0800, Yu Chien Peter Lin wrote:
> xandespmu stands for Andes Performance Monitor Unit extension.
> Based on the added Andes PMU ISA string, the SBI PMU driver
> will make use of the non-standard irq source.
> 
> Signed-off-by: Yu Chien Peter Lin <peterlin at andestech.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj at bp.renesas.com>
> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj at bp.renesas.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/4e54ecba/attachment.sig>

From p.zabel at pengutronix.de  Wed Dec 13 07:26:06 2023
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 13 Dec 2023 16:26:06 +0100
Subject: [GIT PULL] Reset controller fixes for v6.7
Message-ID: <20231213152606.231044-1-p.zabel@pengutronix.de>

Dear arm-soc maintainers,

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.pengutronix.de/pza/linux.git tags/reset-fixes-for-v6.7

for you to fetch changes up to 4a6756f56bcf8e64c87144a626ce53aea4899c0e:

  reset: Fix crash when freeing non-existent optional resets (2023-11-30 15:02:21 +0100)

----------------------------------------------------------------
Reset controller fixes for v6.7

Fix a void-pointer-to-enum-cast warning in the hisilicon hi6220 reset
driver and fix a NULL pointer dereference when freeing non-existent
optional resets requested via the reset_array API in the core.

----------------------------------------------------------------
Geert Uytterhoeven (1):
      reset: Fix crash when freeing non-existent optional resets

Krzysztof Kozlowski (1):
      reset: hisilicon: hi6220: fix Wvoid-pointer-to-enum-cast warning

 drivers/reset/core.c                   | 8 ++++----
 drivers/reset/hisilicon/hi6220_reset.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)


From conor at kernel.org  Wed Dec 13 07:26:28 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 15:26:28 +0000
Subject: [PATCH v5 09/16] dt-bindings: riscv: Add T-Head PMU extension
 description
In-Reply-To: <20231213070301.1684751-10-peterlin@andestech.com>
References: <20231213070301.1684751-1-peterlin@andestech.com>
 <20231213070301.1684751-10-peterlin@andestech.com>
Message-ID: <20231213-romp-squeegee-0cdb44aff415@spud>

On Wed, Dec 13, 2023 at 03:02:54PM +0800, Yu Chien Peter Lin wrote:
> Document the ISA string for T-Head performance monitor extension
> which provides counter overflow interrupt mechanism.
> 
> Signed-off-by: Yu Chien Peter Lin <peterlin at andestech.com>
> Reviewed-by: Guo Ren <guoren at kernel.org>
> Reviewed-by: Inochi Amaoto <inochiama at outlook.com>
> ---
> Changes v2 -> v3:
>   - New patch
> Changes v3 -> v4:
>   - No change
> Changes v4 -> v5:
>   - Include Guo's Reviewed-by
>   - Include Inochi's Reviewed-by
>   - Update to C910 documentation with its commit hash
> ---
>  Documentation/devicetree/bindings/riscv/extensions.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index c91ab0e46648..b5cb8ac7ac80 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -258,5 +258,11 @@ properties:
>              in commit 2e5236 ("Ztso is now ratified.") of the
>              riscv-isa-manual.
>  
> +        - const: xtheadpmu
> +          description:
> +            The T-Head performance monitor extension for counter overflow, as ratified

I'm not sure that "ratified" here is the right word, probably
"documented" is better, but I don't think that is worth a resend.

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> +            in commit 4c4981 ("Initial commit") of Xuantie C910 user manual.
> +            https://github.com/T-head-Semi/openc910/tree/main/doc
> +
>  additionalProperties: true
>  ...
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/0f946a7f/attachment-0001.sig>

From conor at kernel.org  Wed Dec 13 07:27:25 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 15:27:25 +0000
Subject: [PATCH v5 07/16] RISC-V: Move T-Head PMU to CPU feature
 alternative framework
In-Reply-To: <20231213070301.1684751-8-peterlin@andestech.com>
References: <20231213070301.1684751-1-peterlin@andestech.com>
 <20231213070301.1684751-8-peterlin@andestech.com>
Message-ID: <20231213-prewar-poison-f2781b4a6e84@spud>

On Wed, Dec 13, 2023 at 03:02:52PM +0800, Yu Chien Peter Lin wrote:
> The custom PMU extension aims to support perf event sampling prior
> to the ratification of Sscofpmf. Instead of diverting the bits and
> register reserved for future standard, a set of custom registers is
> added.  Hence, we may consider it as a CPU feature rather than an
> erratum.
> 
> T-Head cores need to append "xtheadpmu" to the riscv,isa-extensions
> for each cpu node in device tree, and enable CONFIG_THEAD_CUSTOM_PMU
> for proper functioning as of this commit.
> 
> Signed-off-by: Yu Chien Peter Lin <peterlin at andestech.com>
> Reviewed-by: Guo Ren <guoren at kernel.org>

Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/76e65fd1/attachment.sig>

From andreyknvl at gmail.com  Wed Dec 13 07:31:35 2023
From: andreyknvl at gmail.com (Andrey Konovalov)
Date: Wed, 13 Dec 2023 16:31:35 +0100
Subject: [PATCH] fix comparison of unsigned expression < 0
In-Reply-To: <ecf38b22-ee64-41e5-b9b5-c32fc1cb57bc@moroto.mountain>
References: <20231128075532.110251-1-haibo.li@mediatek.com>
 <20231128172238.f80ed8dd74ab2a13eba33091@linux-foundation.org>
 <CA+fCnZcLwXn6crGF1E1cY3TknMaUN=H8-_hp0-cC+s8-wj95PQ@mail.gmail.com> <ecf38b22-ee64-41e5-b9b5-c32fc1cb57bc@moroto.mountain>
Message-ID: <CA+fCnZc73qNqNiCMcKFKRuoBki=Bmhdw-mOY9chV=CjAtm0R+g@mail.gmail.com>

On Mon, Dec 4, 2023 at 5:12?AM Dan Carpenter <dan.carpenter at linaro.org> wrote:
>
> > But I actually don't think we need to fix anything here.
> >
> > This issue looks quite close to a similar comparison with 0 issue
> > Linus shared his opinion on here:
> >
> > https://lore.kernel.org/all/Pine.LNX.4.58.0411230958260.20993 at ppc970.osdl.org/
> >
> > I don't know if the common consensus with the regard to issues like
> > that changed since then. But if not, perhaps we can treat this kernel
> > test robot report as a false positive.
>
> I would say that the consensus has changed somewhere around 2015 or
> so.  Unsigned comparisons to zero used to be one of the most common
> types of bugs in new code but now almost all subsystems have turned on
> the GCC warning for this.
>
> However, this is a Smatch warning and I agree with Linus on this.  For
> example, Smatch doesn't complain about the example code the Linus
> mentioned.
>
>         if (a < 0 || a > X)
>
> And in this case, it's a one liner fix for me to add KASAN_SHADOW_OFFSET
> as an allowed macro and silence the warning.

Hi Dan,

If this sounds like a good idea to you, please add an exception.

>From the KASAN side, I think adding an exception for this case makes sense.

Thank you!


From conor at kernel.org  Wed Dec 13 07:32:54 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 15:32:54 +0000
Subject: [PATCH v5 07/16] RISC-V: Move T-Head PMU to CPU feature
 alternative framework
In-Reply-To: <20231213-prewar-poison-f2781b4a6e84@spud>
References: <20231213070301.1684751-1-peterlin@andestech.com>
 <20231213070301.1684751-8-peterlin@andestech.com>
 <20231213-prewar-poison-f2781b4a6e84@spud>
Message-ID: <20231213-embattled-makeshift-914c2dc0d678@spud>

On Wed, Dec 13, 2023 at 03:27:25PM +0000, Conor Dooley wrote:
> On Wed, Dec 13, 2023 at 03:02:52PM +0800, Yu Chien Peter Lin wrote:
> > The custom PMU extension aims to support perf event sampling prior
> > to the ratification of Sscofpmf. Instead of diverting the bits and
> > register reserved for future standard, a set of custom registers is
> > added.  Hence, we may consider it as a CPU feature rather than an
> > erratum.
> > 
> > T-Head cores need to append "xtheadpmu" to the riscv,isa-extensions
> > for each cpu node in device tree, and enable CONFIG_THEAD_CUSTOM_PMU
> > for proper functioning as of this commit.
> > 
> > Signed-off-by: Yu Chien Peter Lin <peterlin at andestech.com>
> > Reviewed-by: Guo Ren <guoren at kernel.org>
> 
> Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

I think it is also worth mentioning that the only SoC, to my knowledge,
that works with a mainline kernel, and supports the SBI PMU is the D1,
and only recently has the OpenSBI port for the SoC been fixed to
actually work correctly, and that has apparently not yet made it to
a release of OpenSBI, making the "damage" caused by requiring a DT
property for PMU support not all that bad since the firmware needs to be
changed anyway.

Thanks for your work on this,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/ae20c7b1/attachment.sig>

From p.zabel at pengutronix.de  Wed Dec 13 07:33:13 2023
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 13 Dec 2023 16:33:13 +0100
Subject: [GIT PULL] Reset controller updates for v6.8
Message-ID: <20231213153313.278867-1-p.zabel@pengutronix.de>

Dear arm-soc maintainers,

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.pengutronix.de/pza/linux.git tags/reset-for-v6.8

for you to fetch changes up to c3c46acd5be9a3351c163d2869045cab4d5342dc:

  dt-bindings: reset: hisilicon,hi3660-reset: Drop providers and consumers from example (2023-11-29 11:49:45 +0100)

----------------------------------------------------------------
Reset controller updates for v6.8

Make use of devm_platform_get_and_ioremap_resource() and
device_get_match_data() in several drivers, support the Amlogic C3 reset
controller, and improve various device tree binding documents.

----------------------------------------------------------------
Lad Prabhakar (1):
      dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/Five SoC

Rob Herring (4):
      reset: Use device_get_match_data()
      dt-bindings: reset: qcom: drop unneeded quotes
      dt-bindings: reset: imx-src: Simplify compatible schema and drop unneeded quotes
      dt-bindings: reset: hisilicon,hi3660-reset: Drop providers and consumers from example

Yangtao Li (7):
      reset: brcmstb: Use devm_platform_get_and_ioremap_resource()
      reset: meson-audio-arb: Convert to devm_platform_ioremap_resource()
      reset: qcom-aoss: Convert to devm_platform_ioremap_resource()
      reset: qcom: Convert to devm_platform_ioremap_resource()
      reset: simple: Convert to devm_platform_get_and_ioremap_resource()
      reset: sunplus: Use devm_platform_get_and_ioremap_resource()
      reset: uniphier-glue: Use devm_platform_get_and_ioremap_resource()

Zelong Dong (2):
      dt-bindings: reset: Add compatible and DT bindings for Amlogic C3 Reset Controller
      reset: reset-meson: add support for Amlogic C3 SoC Reset Controller

 .../bindings/reset/amlogic,meson-reset.yaml        |   1 +
 .../devicetree/bindings/reset/fsl,imx-src.yaml     |  31 ++----
 .../bindings/reset/hisilicon,hi3660-reset.yaml     |  25 +----
 .../devicetree/bindings/reset/qcom,aoss-reset.yaml |  10 +-
 .../devicetree/bindings/reset/qcom,pdc-global.yaml |   8 +-
 .../bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml  |   2 +-
 drivers/reset/reset-brcmstb.c                      |   3 +-
 drivers/reset/reset-meson-audio-arb.c              |   4 +-
 drivers/reset/reset-meson.c                        |   1 +
 drivers/reset/reset-npcm.c                         |   5 +-
 drivers/reset/reset-qcom-aoss.c                    |   4 +-
 drivers/reset/reset-qcom-pdc.c                     |   4 +-
 drivers/reset/reset-simple.c                       |   3 +-
 drivers/reset/reset-sunplus.c                      |   3 +-
 drivers/reset/reset-uniphier-glue.c                |   3 +-
 drivers/reset/sti/reset-syscfg.c                   |  11 +-
 include/dt-bindings/reset/amlogic,c3-reset.h       | 119 +++++++++++++++++++++
 17 files changed, 157 insertions(+), 80 deletions(-)
 create mode 100644 include/dt-bindings/reset/amlogic,c3-reset.h


From Frank.li at nxp.com  Wed Dec 13 07:39:20 2023
From: Frank.li at nxp.com (Frank Li)
Date: Wed, 13 Dec 2023 10:39:20 -0500
Subject: [PATCH v3 08/13] dt-bindings: imx6q-pcie: Add imx95 pcie
 compatible string
In-Reply-To: <20231213143615.GA1093782-robh@kernel.org>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-9-Frank.Li@nxp.com>
 <20231212224426.GA2948988-robh@kernel.org>
 <ZXjsq2QtFa2V0BAl@lizhi-Precision-Tower-5810>
 <20231213143615.GA1093782-robh@kernel.org>
Message-ID: <ZXnQKBnweCT+si6/@lizhi-Precision-Tower-5810>

On Wed, Dec 13, 2023 at 08:36:15AM -0600, Rob Herring wrote:
> On Tue, Dec 12, 2023 at 06:28:43PM -0500, Frank Li wrote:
> > On Tue, Dec 12, 2023 at 04:44:26PM -0600, Rob Herring wrote:
> > > On Mon, Dec 11, 2023 at 04:58:37PM -0500, Frank Li wrote:
> > > > From: Richard Zhu <hongxing.zhu at nxp.com>
> > > > 
> > > > Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
> > > > Add "atu" and "serdes" to reg-names.
> > > > 
> > > > Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> > > > ---
> > > > 
> > > > Notes:
> > > >     Change from v2 to v3
> > > >     - Remove krzy's ACK tag
> > > >     - Add condition check for imx95, which required more reg-names then old
> > > >     platform, so need Krzy review again,
> > > >     
> > > >     Change from v1 to v2
> > > >     - add Krzy's ACK tag
> > > > 
> > > >  .../bindings/pci/fsl,imx6q-pcie.yaml           | 18 ++++++++++++++++++
> > > >  1 file changed, 18 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > > index 81bbb8728f0f9..b8fcf8258f031 100644
> > > > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > > @@ -29,6 +29,7 @@ properties:
> > > >        - fsl,imx8mq-pcie
> > > >        - fsl,imx8mm-pcie
> > > >        - fsl,imx8mp-pcie
> > > > +      - fsl,imx95-pcie
> > > >  
> > > >    reg:
> > > >      items:
> > > > @@ -90,6 +91,22 @@ required:
> > > >  allOf:
> > > >    - $ref: /schemas/pci/snps,dw-pcie.yaml#
> > > >    - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
> > > > +  - if:
> > > > +      properties:
> > > > +        compatible:
> > > > +          enum:
> > > > +            - fsl,imx95-pcie
> > > > +    then:
> > > > +      properties:
> > > > +        reg:
> > > > +          minItems: 4
> > > > +        reg-names:
> > > > +          items:
> > > > +            - const: dbi
> > > > +            - const: serdes
> > > 
> > > Did you test this? It should fail because 'serdes' would need to be 
> > > added to snps,dw-pcie.yaml.
> > 
> > I run "make dt_binding_check DT_SCHEMA_FILES=/pci/", no error report.
> 
> Only because you have no example. What about your actual .dts?

I see. 95 is quite new. Still have not good base yet.
I may just take take care this session.

> 
> > And PCIe function can work.
> > 
> > > 
> > > Is this really not a separate phy block?
> > 
> > This is misc block, which included phy and also include some registers
> > about SID for each PCI devices. I plan do it later.
> 
> Sounds like it should be a separate node and use the phy binding. Do it 
> correctly from the start, not later. Later is an ABI break.

Actually, I considerred phy binding. The major problem is LUT (look up
table) for MSI and SMMU. LUT need be config according to some PCI device
information. I have not find good hook for that at PHY driver.

> 
> What is SID?

Stream ID, each device master have SID, which pass to IOMMU and GIC ITS.

Frank

> 
> Rob


From khilman at kernel.org  Wed Dec 13 07:41:44 2023
From: khilman at kernel.org (Kevin Hilman)
Date: Wed, 13 Dec 2023 07:41:44 -0800
Subject: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure
 ti-sysc for wkup_uart0
In-Reply-To: <20231209035900.GW5169@atomide.com>
References: <20231114073209.40756-1-tony@atomide.com>
 <7h5y1c7c0q.fsf@baylibre.com> <20231207060854.GQ5169@atomide.com>
 <7hedfwd3co.fsf@baylibre.com> <20231209035900.GW5169@atomide.com>
Message-ID: <7hcyvam7nr.fsf@baylibre.com>

Tony Lindgren <tony at atomide.com> writes:

> * Kevin Hilman <khilman at kernel.org> [231208 17:13]:
>> Tony Lindgren <tony at atomide.com> writes:
>> 
>> > * Kevin Hilman <khilman at kernel.org> [231205 18:14]:
>> >> I'm a little confused why these power-domain and clocks stay here and
>> >> are not moved under the wkup_uart0 node... 
>> >
>> > The resources are also needed by the interconnect target module. It's the
>> > wrapper IP for the child device(s). In this case there's one chip 8250 IP
>> > instance. In some other devices there can be multiple child IP devices
>> > wired to one target module.
>> >
>> >> > -		clock-names = "fclk";
>> >> > -		status = "disabled";
>> >> > +		clock-names = "fck";
>> >> > +		#address-cells = <1>;
>> >> > +		#size-cells = <1>;
>> >> > +		ranges = <0 0 0x2b300000 0x100000>;
>> >> > +
>> >> > +		wkup_uart0: serial at 2b300000 {
>> >> > +			compatible = "ti,am64-uart", "ti,am654-uart";
>> >> > +			reg = <0 0x100>;
>> >> > +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
>> >> > +			status = "disabled";
>> >> 
>> >> ...here.
>> >> 
>> >> The SCI device ID 114 is specifically for wkup_uart0[1], so it seems to
>> >> me those should be in the wkup_uart0 node.
>> >
>> > Those resources are also needed for the parent target module for revision
>> > detection, quirks, reset, idle register configuration, and to probe the
>> > child devices.
>> >
>> > Here the 8250 IP can be set to status = "reserved" when used by the
>> > firmware, and 8250 not touched by Linux. However, the parent interconnect
>> > target module still needs to be configured for idle registers and wake-up
>> > path register bit so the wake-up from deeper suspend states works.
>> 
>> OK, makes sense.  Thanks for the clarification.
>
> One more thing to clarify, there's nothing stopping also mapping the needed
> resources for the child IP too if needed by the driver or the dts binding.
> The calls for resources by the 8250 driver just won't do anything as the
> resources are already enabled by the parent.

OK, thanks.

>> In that case, shouldn't the same be done for the other wakeup sources
>> there (e.g. wkup_rtc0) ?
>
> Yes it should be done for devices with the wake-up path wired like
> wkup_rtc0.

OK, in that case, this all makes sense to me.

Reviewed-by: Kevin Hilman <khilman at baylibre.com>

Kevin


From michal.simek at amd.com  Wed Dec 13 07:44:57 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 13 Dec 2023 16:44:57 +0100
Subject: [PATCH v4 1/2] dt-bindings: soc: xilinx: Move xilinx.yaml from
 arm to soc
In-Reply-To: <9653338d293c25ff0e591213698d59ac55cf5c27.1700722941.git.michal.simek@amd.com>
References: <9653338d293c25ff0e591213698d59ac55cf5c27.1700722941.git.michal.simek@amd.com>
Message-ID: <e128d826-0a62-4e7e-b8d3-2a7d2ef30f62@amd.com>



On 11/23/23 08:02, Michal Simek wrote:
> All Xilinx boards can hosts also soft core CPUs like MicroBlaze or
> MicroBlaze V (RISC-V ISA) that's why move boards description from arm
> folder to soc folder.
> Similar change was done for Renesas by commit c27ce08b806d ("dt-bindings:
> soc: renesas: Move renesas.yaml from arm to soc").
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
> 
> Changes in v4:
> - s/chagne/change/ in commit message
> - Fix binding location
> 
> Changes in v3:
> - Fix commit message reported by Krzysztof and add his ACK
> 
> Changes in v2:
> - New patch in the series
> 
> Based on discussion here.
> https://lore.kernel.org/r/20231108-copper-scoff-b4de5febb954 at spud
> 
> ---
>   .../devicetree/bindings/{arm => soc/xilinx}/xilinx.yaml         | 2 +-
>   MAINTAINERS                                                     | 1 +
>   2 files changed, 2 insertions(+), 1 deletion(-)
>   rename Documentation/devicetree/bindings/{arm => soc/xilinx}/xilinx.yaml (98%)
> 
> diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> similarity index 98%
> rename from Documentation/devicetree/bindings/arm/xilinx.yaml
> rename to Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> index f57ed0347894..95758deca325 100644
> --- a/Documentation/devicetree/bindings/arm/xilinx.yaml
> +++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> @@ -1,7 +1,7 @@
>   # SPDX-License-Identifier: GPL-2.0
>   %YAML 1.2
>   ---
> -$id: http://devicetree.org/schemas/arm/xilinx.yaml#
> +$id: http://devicetree.org/schemas/soc/xilinx/xilinx.yaml#
>   $schema: http://devicetree.org/meta-schemas/core.yaml#
>   
>   title: Xilinx Zynq Platforms
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea790149af79..14ad00009a63 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3020,6 +3020,7 @@ F:	Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
>   F:	Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
>   F:	Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml
>   F:	Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
> +F:	Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
>   F:	Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
>   F:	arch/arm/mach-zynq/
>   F:	drivers/clocksource/timer-cadence-ttc.c


Applied.
M


From michal.simek at amd.com  Wed Dec 13 07:45:08 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 13 Dec 2023 16:45:08 +0100
Subject: [PATCH v4 2/2] dt-bindings: soc: Add new board description for
 MicroBlaze V
In-Reply-To: <69670e5a46c98a2eb73d4f2e2d571a27c46b4640.1700722941.git.michal.simek@amd.com>
References: <9653338d293c25ff0e591213698d59ac55cf5c27.1700722941.git.michal.simek@amd.com>
 <69670e5a46c98a2eb73d4f2e2d571a27c46b4640.1700722941.git.michal.simek@amd.com>
Message-ID: <0164c37a-872f-43d0-9b3f-f351a7fda31c@amd.com>



On 11/23/23 08:02, Michal Simek wrote:
> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
> It is hardware compatible with classic MicroBlaze processor. Processor can
> be used with standard AMD/Xilinx IPs including interrupt controller and
> timer.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
> 
> Changes in v4:
> - Fix indentation reported by bot
> 
> Changes in v3:
> - Add Krzysztof's ACK
> 
> Changes in v2:
> - Put MicroBlaze V description to xilinx.yaml
> - Add qemu target platform as platform used for testing.
> 
>   Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> index 95758deca325..d4c0fe1fe435 100644
> --- a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> +++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> @@ -132,6 +132,11 @@ properties:
>             - const: xlnx,zynqmp-smk-k26
>             - const: xlnx,zynqmp
>   
> +      - description: AMD MicroBlaze V (QEMU)
> +        items:
> +          - const: qemu,mbv
> +          - const: amd,mbv
> +
>   additionalProperties: true
>   
>   ...

Applied.
M


From michal.simek at amd.com  Wed Dec 13 07:46:21 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 13 Dec 2023 16:46:21 +0100
Subject: [PATCH 0/2] arm64: zynqmp: Align fixed-clock nodes for kv260
In-Reply-To: <cover.1701338352.git.michal.simek@amd.com>
References: <cover.1701338352.git.michal.simek@amd.com>
Message-ID: <ff1a121c-e674-47a5-8187-52135fbf404f@amd.com>



On 11/30/23 10:59, Michal Simek wrote:
> Hi,
> 
> these two patches are moving clock nodes out of bus because they don't have
> reg property and also align node names.
> 
> Thanks,
> Michal
> 
> 
> Michal Simek (2):
>    arm64: zynqmp: Move fixed clock to / for kv260
>    arm64: zynqmp: Fix clock node name in kv260 cards
> 
>   .../boot/dts/xilinx/zynqmp-sck-kv-g-revA.dtso | 40 +++++++++---------
>   .../boot/dts/xilinx/zynqmp-sck-kv-g-revB.dtso | 42 +++++++++----------
>   2 files changed, 41 insertions(+), 41 deletions(-)
> 

Applied.
M


From michal.simek at amd.com  Wed Dec 13 07:47:09 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 13 Dec 2023 16:47:09 +0100
Subject: [PATCH] arm64: zynqmp: Add missing destination mailbox compatible
In-Reply-To: <96460adbb99ea829a2a95c72a40118f81946a559.1701335951.git.michal.simek@amd.com>
References: <96460adbb99ea829a2a95c72a40118f81946a559.1701335951.git.michal.simek@amd.com>
Message-ID: <fc38f9a4-6ce8-4d27-9bdc-f317ad03c930@amd.com>



On 11/30/23 10:19, Michal Simek wrote:
> The commit 81186dc16101 ("dt-bindings: zynqmp: add destination mailbox
> compatible") make compatible string for child nodes mandatory that's why
> add it.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---
> 
>   arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index f5e1eb8cb3b7..eaba466804bc 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -141,6 +141,7 @@ zynqmp_ipi: zynqmp-ipi {
>   
>   		ipi_mailbox_pmu1: mailbox at ff9905c0 {
>   			bootph-all;
> +			compatible = "xlnx,zynqmp-ipi-dest-mailbox";
>   			reg = <0x0 0xff9905c0 0x0 0x20>,
>   			      <0x0 0xff9905e0 0x0 0x20>,
>   			      <0x0 0xff990e80 0x0 0x20>,

Applied.
M


From zajec5 at gmail.com  Wed Dec 13 07:47:20 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Wed, 13 Dec 2023 16:47:20 +0100
Subject: [PATCH 1/2] dt-bindings: nvmem: add "data-size" property
Message-ID: <20231213154721.5037-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Allow specifying NVMEM device content size in case it differs from
device total size.

Cc: Christian Marangi <ansuelsmth at gmail.com>
Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 Documentation/devicetree/bindings/nvmem/nvmem.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 4fd015d402ce..095aed4250de 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -26,6 +26,13 @@ properties:
   "#size-cells":
     const: 1
 
+  data-size:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      NVMEM device actual data (content) size. It may be need to be specified
+      if it differs by design from the total NVMEM device size and it's
+      impossible to determine it on runtime.
+
   read-only:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
-- 
2.35.3



From zajec5 at gmail.com  Wed Dec 13 07:47:21 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Wed, 13 Dec 2023 16:47:21 +0100
Subject: [PATCH 2/2] dt-bindings: nvmem: u-boot,env: describe "data-size" property
In-Reply-To: <20231213154721.5037-1-zajec5@gmail.com>
References: <20231213154721.5037-1-zajec5@gmail.com>
Message-ID: <20231213154721.5037-2-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Describe what "data-size" means in U-Boot env context and why it may be
needed. It's a generic property but giving it some extra meaning in
U-Boot context may be helpful.

Cc: Christian Marangi <ansuelsmth at gmail.com>
Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 .../devicetree/bindings/nvmem/u-boot,env.yaml          | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
index 9c36afc7084b..0006f022d0af 100644
--- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
@@ -44,6 +44,15 @@ properties:
   reg:
     maxItems: 1
 
+  data-size:
+    description:
+      U-Boot environment data size is set and hardcoded during compilation using
+      CONFIG_ENV_SIZE. Knowing it is critical for CRC32 checksum calculation.
+
+      This property allows specifying it in case it differs from NVMEM device
+      size. It may happen if device partitioning was designed with different
+      concepts in mind (like block alignment or future-proof size).
+
   bootcmd:
     type: object
     description: Command to use for automatic booting
@@ -76,6 +85,7 @@ examples:
         env: partition at 40000 {
             compatible = "u-boot,env";
             reg = <0x40000 0x10000>;
+            data-size = <0x4000>;
 
             mac: ethaddr {
                 #nvmem-cell-cells = <1>;
-- 
2.35.3



From zajec5 at gmail.com  Wed Dec 13 07:49:02 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Wed, 13 Dec 2023 16:49:02 +0100
Subject: [PATCH 1/2] dt-bindings: nvmem: add "data-size" property
In-Reply-To: <20231213154721.5037-1-zajec5@gmail.com>
References: <20231213154721.5037-1-zajec5@gmail.com>
Message-ID: <9b7676f4-4922-40cc-98b2-67224c901773@gmail.com>

On 13.12.2023 16:47, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> Allow specifying NVMEM device content size in case it differs from
> device total size.
> 
> Cc: Christian Marangi <ansuelsmth at gmail.com>
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

I forgot to link Rob's comment where he suggested we may need such a property:
https://patchwork.ozlabs.org/comment/3154781/

Let's now see if I got it right.


> ---
>   Documentation/devicetree/bindings/nvmem/nvmem.yaml | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> index 4fd015d402ce..095aed4250de 100644
> --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> @@ -26,6 +26,13 @@ properties:
>     "#size-cells":
>       const: 1
>   
> +  data-size:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      NVMEM device actual data (content) size. It may be need to be specified
> +      if it differs by design from the total NVMEM device size and it's
> +      impossible to determine it on runtime.
> +
>     read-only:
>       $ref: /schemas/types.yaml#/definitions/flag
>       description:



From u.kleine-koenig at pengutronix.de  Wed Dec 13 07:52:52 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 13 Dec 2023 16:52:52 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <6wnsxbi27xdxjtaqaaaq5wtwwilp4jfw4mg5y2ctdl7xrs44ry@ns6y36pf7hge>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
 <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
 <20231213110829.bjaxjjiyy4ug7o67@pengutronix.de>
 <6wnsxbi27xdxjtaqaaaq5wtwwilp4jfw4mg5y2ctdl7xrs44ry@ns6y36pf7hge>
Message-ID: <20231213155252.eq6cdzk2vuwllzdu@pengutronix.de>

On Wed, Dec 13, 2023 at 12:54:14PM +0100, Maxime Ripard wrote:
> On Wed, Dec 13, 2023 at 12:08:29PM +0100, Uwe Kleine-K?nig wrote:
> > On Wed, Dec 13, 2023 at 09:36:49AM +0100, Maxime Ripard wrote:
> > > On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
> > > > On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > > > > On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> > > > > > clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> > > > > > that and don't check the return value. This series fixes the four users
> > > > > > that do error checking on the returned value and then makes function
> > > > > > return void.
> > > > > > 
> > > > > > Given that the changes to the drivers are simple and so merge conflicts
> > > > > > (if any) should be easy to handle, I suggest to merge this complete
> > > > > > series via the clk tree.
> > > > > 
> > > > > I don't think it's the right way to go about it.
> > > > > 
> > > > > clk_rate_exclusive_get() should be expected to fail. For example if
> > > > > there's another user getting an exclusive rate on the same clock.
> > > > > 
> > > > > If we're not checking for it right now, then it should probably be
> > > > > fixed, but the callers checking for the error are right to do so if they
> > > > > rely on an exclusive rate. It's the ones that don't that should be
> > > > > modified.
> > > > 
> > > > If some other consumer has already "locked" a clock that I call
> > > > clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
> > > > this function because I don't want the rate to change e.g. because I
> > > > setup some registers in the consuming device to provide a fixed UART
> > > > baud rate or i2c bus frequency (and that works as expected).
> > > 
> > > [a long text of mostly right things (Uwe's interpretation) that are
> > > however totally unrelated to the patches under discussion.]
> 
> I'm glad you consider it "mostly" right.

there was no offense intended. I didn't agree to all points, but didn't
think it was helpful to discuss that given that I considered them
orthogonal to my suggested modifications.
 
> > The clk API works with and without my patches in exactly the same way.
> > It just makes more explicit that clk_rate_exclusive_get() cannot fail
> > today and removes the error handling from consumers that is never used.
> 
> Not really, no.

What exactly do you oppose here? Both of my sentences are correct?!
 
> An API is an interface, meant to provide an abstraction. The only
> relevant thing is whether or not that function, from an abstract point
> of view, can fail.

What is the ideal API that you imagine? For me the ideal API is:

A consumer might call clk_rate_exclusive_get() and after that returns
all other consumers are prohibited to change the rate of the clock
(directly and indirectly) until clk_rate_exclusive_put() is called. If
this ends in a double lock (i.e. two different consumers locked the
clock), then I cannot change the rate (and neither can anybody else).

That is fine iff I don't need to change the rate and just want to rely
on it to keep its current value (which is a valid use case). And if I
want to change the rate but another consumer prevents that, I handle
that in the same away as I handle all other failures to set the rate to
the value I need. I have to prepare for that anyhow even if I have
ensured that I'm the only one having exclusivity on that clock.

Letting clk_rate_exclusive_get() fail in the assumption that the
consumer also wants to modify the rate is wrong. The obvious point where
to stop such consumers is when they call clk_rate_set(). And those who
don't modify the rate then continue without interruption even if there
are two lockers.

This can easily be implemented without clk_rate_exclusive_get() ever
failing.

> Can you fail to get the exclusivity? Yes. On a theoretical basis, you
> can, and the function was explicitly documented as such.

Sure, you could modify the clk internals such that
clk_rate_exclusive_get() needs to allocate memory. Or that it fails if
another consumer already has called it. At least the latter is a change
in semantics that requires to review (and maybe fix) all users. Also
note that calling clk_rate_exclusive_get() essentially locks all parent
clocks up to the root clock. So if clk_rate_exclusive_get() fails in the
presence of another locker, you can only have one locker per clock
hierarchy because it's impossible that both grab the lock on the root
clock.

> > Is there anyone working on improving the clk framework regarding how clk
> > rate exclusivity works? I'd probably not notice, but I guess there is
> > noone that I need to consider for.
> 
> I started working on it.

That is indeed a reason to postpone my patches. Feel free to Cc: me when
you're done. And please mention if you need longer than (say) 6 months,
then I'd argue that applying my patches now without caring for
out-of-tree users is the way to go.

My demand for such a rework would be that there is a function for 
consumers to call that don't have the requirement for a certain rate but
only any fixed rate that results in locking the clock's rate to whatever
it currently is. Today that function exists and is called
clk_rate_exclusive_get(); this might not be the best name, so maybe
rename it to something that you consider more sensible at the start of
your rework?!

Semantically that is similar to read_lock() (which never fails and
still prevents any writers). And clk_set_rate() is like 

	try_upgrade_read_lock_to_write_lock();
	actually_change_the_rate()
	downgrade_write_lock_to_read_lock();

where try_upgrade_read_lock_to_write_lock() fails if there are other
readers. So maybe a sensible name for today's clk_rate_exclusive_get()
is clk_rate_read_lock()?

If your variant of clk_rate_exclusive_get() might fail, you can already
prepare for me questioning why this is sensible and needed.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/f6203b5a/attachment.sig>

From michal.simek at amd.com  Wed Dec 13 07:54:57 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 13 Dec 2023 16:54:57 +0100
Subject: [PATCH] soc: xilinx: Add error message for invalid payload
 received from IPI callback.
In-Reply-To: <85749bde3e71148533d31ea2092f4514ec347768.1701962639.git.michal.simek@amd.com>
References: <85749bde3e71148533d31ea2092f4514ec347768.1701962639.git.michal.simek@amd.com>
Message-ID: <325f7135-305b-4fdc-8912-acf257b86d22@amd.com>



On 12/7/23 16:24, Michal Simek wrote:
> From: Naman Trivedi Manojbhai <naman.trivedimanojbhai at amd.com>
> 
> payload[0] of response buffer of zynqmp_pm_get_callback_data()
> contains valid payload or error code in case of error.
> 
> Added error message to inform user about the error code received in
> payload[0].
> 
> Signed-off-by: Naman Trivedi Manojbhai <naman.trivedimanojbhai at amd.com>
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---
> 
>   drivers/soc/xilinx/zynqmp_power.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/soc/xilinx/zynqmp_power.c b/drivers/soc/xilinx/zynqmp_power.c
> index abcf7e883279..07d735b38b49 100644
> --- a/drivers/soc/xilinx/zynqmp_power.c
> +++ b/drivers/soc/xilinx/zynqmp_power.c
> @@ -86,6 +86,8 @@ static irqreturn_t zynqmp_pm_isr(int irq, void *data)
>   			pr_err("%s Unsupported InitSuspendCb reason code %d\n",
>   			       __func__, payload[1]);
>   		}
> +	} else {
> +		pr_err("%s() Unsupported Callback %d\n", __func__, payload[0]);
>   	}
>   
>   	return IRQ_HANDLED;

Applied.
M


From conor at kernel.org  Wed Dec 13 08:02:16 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 16:02:16 +0000
Subject: [PATCH V5 1/3] dt-bindings: Add reference to rs485.yaml
In-Reply-To: <20231213130023.606486-2-manikanta.guntupalli@amd.com>
References: <20231213130023.606486-1-manikanta.guntupalli@amd.com>
 <20231213130023.606486-2-manikanta.guntupalli@amd.com>
Message-ID: <20231213-chief-heroics-fd8ba9dbb653@spud>

On Wed, Dec 13, 2023 at 06:30:21PM +0530, Manikanta Guntupalli wrote:
> Add reference to rs485.yaml

I can see this both from the diff and from $subject. What is missing
here is why.

> Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
> ---
> Changes for V2:
> Modify optional gpio name to xlnx,phy-ctrl-gpios.
> Update commit description.
> 
> Changes for V3:
> Modify optional gpio name to rts-gpios.
> Update commit description.
> 
> Changes for V4:
> Update rts-gpios description.
> 
> Changes for V5:
> Remove rts-gpios description.
> Update commit message and description.
> ---
>  Documentation/devicetree/bindings/serial/cdns,uart.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
> index e35ad1109efc..2129247d7c81 100644
> --- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
> @@ -55,6 +55,7 @@ required:
>  
>  allOf:
>    - $ref: serial.yaml#
> +  - $ref: rs485.yaml#
>    - if:
>        properties:
>          compatible:
> -- 
> 2.25.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/591eb724/attachment.sig>

From alim.akhtar at samsung.com  Wed Dec 13 08:03:45 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Wed, 13 Dec 2023 21:33:45 +0530
Subject: [Patch v6 00/10] Add MFC v12 support
In-Reply-To: <20231213081105.25817-1-aakarsh.jain@samsung.com>
References: <CGME20231213081112epcas5p171f1b69376bc4b1e8ced03f8b56efe35@epcas5p1.samsung.com>
	<20231213081105.25817-1-aakarsh.jain@samsung.com>
Message-ID: <016d01da2ddd$f5606ad0$e0214070$@samsung.com>



> -----Original Message-----
> From: Aakarsh Jain <aakarsh.jain at samsung.com>
> Sent: Wednesday, December 13, 2023 1:41 PM
> To: linux-arm-kernel at lists.infradead.org; linux-media at vger.kernel.org;
> linux-kernel at vger.kernel.org; devicetree at vger.kernel.org
> Cc: m.szyprowski at samsung.com; andrzej.hajda at intel.com;
> mchehab at kernel.org; hverkuil-cisco at xs4all.nl;
> krzysztof.kozlowski+dt at linaro.org; robh+dt at kernel.org;
> conor+dt at kernel.org; linux-samsung-soc at vger.kernel.org;
> andi at etezian.org; gost.dev at samsung.com; alim.akhtar at samsung.com;
> aswani.reddy at samsung.com; pankaj.dubey at samsung.com;
> ajaykumar.rs at samsung.com; aakarsh.jain at samsung.com
> Subject: [Patch v6 00/10] Add MFC v12 support
> 
> This patch series adds MFC v12 support. MFC v12 is used in Tesla FSD SoC.
> 
> This adds support for following:
> 
> -Add support for YV12 and I420 format (3-plane) -Add support for Rate
> Control, UHD and DMABUF for encoder -Add support for DPB buffers
> allocation based on MFC requirement
> 
> changes since v5:
> -As per Krzysztof, he will take MFC dt-entries patch via Samsung SoC once dt-
> bindings patch gets accepted. Therefore, excluded MFC dt-entries patch
> from v6.
> -Addressed review comments by Hans Verkuil.
> Resolved smatch warning from 'drivers/media/platform/samsung/s5p-
> mfc/s5p_mfc_enc.c'.
> Resolved kernel doc warnings from 'drivers/media/platform/samsung/s5p-
> mfc/s5p_mfc_common.h'.
> Added explanation in the patch 9 as comment on why mfc v12 firmware
> loading is needed for each run.
> v5 link: https://patchwork.kernel.org/project/linux-
> media/cover/20231206063045.97234-1-aakarsh.jain at samsung.com/
> 
[snip]
> Aakarsh Jain (10):
>   dt-bindings: media: s5p-mfc: Add mfcv12 variant
>   media: s5p-mfc: Rename IS_MFCV10 macro
>   media: s5p-mfc: Add initial support for MFCv12
>   media: s5p-mfc: Add YV12 and I420 multiplanar format support
>   media: s5p-mfc: Add support for rate controls in MFCv12
>   media: s5p-mfc: Add support for UHD encoding.
>   media: s5p-mfc: Add support for DMABUF for encoder
>   media: s5p-mfc: Set context for valid case before calling try_run
>   media: s5p-mfc: Load firmware for each run in MFCv12.
>   media: s5p-mfc: DPB Count Independent of VIDIOC_REQBUF
> 
>  .../bindings/media/samsung,s5p-mfc.yaml       |  18 ++
>  .../platform/samsung/s5p-mfc/regs-mfc-v12.h   |  52 +++
>  .../platform/samsung/s5p-mfc/regs-mfc-v7.h    |   1 +
>  .../platform/samsung/s5p-mfc/regs-mfc-v8.h    |   3 +
>  .../media/platform/samsung/s5p-mfc/s5p_mfc.c  |  36 ++-
> .../platform/samsung/s5p-mfc/s5p_mfc_common.h |  33 +-
>  .../platform/samsung/s5p-mfc/s5p_mfc_ctrl.c   |  15 +-
>  .../platform/samsung/s5p-mfc/s5p_mfc_dec.c    |  60 +++-
>  .../platform/samsung/s5p-mfc/s5p_mfc_enc.c    | 149 ++++++---
>  .../platform/samsung/s5p-mfc/s5p_mfc_opr.h    |  14 +-
>  .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c |  12 +-
> .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 299 ++++++++++++++---
> -
>  .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h |   7 +-
>  13 files changed, 550 insertions(+), 149 deletions(-)  create mode 100644
> drivers/media/platform/samsung/s5p-mfc/regs-mfc-v12.h
> 
Tested this series on FSD platform, feel free to add
Tested-by: Alim Akhtar <alim.akhtar at samsung.com>

> --
> 2.17.1




From conor at kernel.org  Wed Dec 13 08:03:59 2023
From: conor at kernel.org (Conor Dooley)
Date: Wed, 13 Dec 2023 16:03:59 +0000
Subject: [PATCH 1/3] dt-bindings: arm: ti: Add bindings for J722S SoCs
In-Reply-To: <20231213124930.3012-2-vaishnav.a@ti.com>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
 <20231213124930.3012-2-vaishnav.a@ti.com>
Message-ID: <20231213-facsimile-circular-857af819f76f@spud>

On Wed, Dec 13, 2023 at 06:19:28PM +0530, Vaishnav Achath wrote:
> Add bindings for TI J722S family of devices.

Just repeating $subject in the body isn't really all that valuable, but
these new soc additions are super straightforward (usually) so w/e.

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> 
> Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
> ---
>  Documentation/devicetree/bindings/arm/ti/k3.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
> index c6506bccfe88..d52672348424 100644
> --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
> +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
> @@ -123,6 +123,12 @@ properties:
>                - ti,j721s2-evm
>            - const: ti,j721s2
>  
> +      - description: K3 J722S SoC and Boards
> +        items:
> +          - enum:
> +              - ti,j722s-evm
> +          - const: ti,j722s
> +
>        - description: K3 J784s4 SoC
>          items:
>            - enum:
> -- 
> 2.17.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/77b794dc/attachment.sig>

From linux at armlinux.org.uk  Wed Dec 13 08:04:12 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Wed, 13 Dec 2023 16:04:12 +0000
Subject: [RFC PATCH net-next v3 3/8] net: pcs: pcs-mtk-lynxi: add
 platform driver for MT7988
In-Reply-To: <8aa905080bdb6760875d62cb3b2b41258837f80e.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <8aa905080bdb6760875d62cb3b2b41258837f80e.1702352117.git.daniel@makrotopia.org>
Message-ID: <ZXnV/Pk1PYxAm/jS@shell.armlinux.org.uk>

On Tue, Dec 12, 2023 at 03:47:18AM +0000, Daniel Golle wrote:
> Introduce a proper platform MFD driver for the LynxI (H)SGMII PCS which
> is going to initially be used for the MT7988 SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

I made some specific suggestions about what I wanted to see for
"getting" PCS in the previous review, and I'm disappointed that this
patch set is still inventing its own solution.

> +struct phylink_pcs *mtk_pcs_lynxi_get(struct device *dev, struct device_node *np)
> +{
> +	struct platform_device *pdev;
> +	struct mtk_pcs_lynxi *mpcs;
> +
> +	if (!np)
> +		return NULL;
> +
> +	if (!of_device_is_available(np))
> +		return ERR_PTR(-ENODEV);
> +
> +	if (!of_match_node(mtk_pcs_lynxi_of_match, np))
> +		return ERR_PTR(-EINVAL);
> +
> +	pdev = of_find_device_by_node(np);
> +	if (!pdev || !platform_get_drvdata(pdev)) {

This is racy - as I thought I described before, userspace can unbind
the device in one thread, while another thread is calling this
function. With just the right timing, this check succeeds, but...

> +		if (pdev)
> +			put_device(&pdev->dev);
> +		return ERR_PTR(-EPROBE_DEFER);
> +	}
> +
> +	mpcs = platform_get_drvdata(pdev);

mpcs ends up being read as NULL here. Even if you did manage to get a
valid pointer, "mpcs" being devm-alloced could be freed from under
you at this point...

> +	device_link_add(dev, mpcs->dev, DL_FLAG_AUTOREMOVE_CONSUMER);

resulting in this accessing memory which has been freed.

The solution would be either to suppress the bind/unbind attributes
(provided the underlying struct device can't go away, which probably
also means ensuring the same of the MDIO bus. Aternatively, adding
a lock around the remove path and around the checking of
platform_get_drvdata() down to adding the device link would probably
solve it.

However, I come back to my general point - this kind of stuff is
hairy. Do we want N different implementations of it in various drivers
with subtle bugs, or do we want _one_ implemenatation.

If we go with the one implemenation approach, then we need to think
about whether we should be using device links or not. The problem
could be for network interfaces where one struct device is
associated with multiple network interfaces. Using device links has
the unfortunate side effect that if the PCS for one of those network
interfaces is removed, _all_ network interfaces disappear.

My original suggestion was to hook into phylink to cause that to
take the link down when an in-use PCS gets removed.

> +
> +	return &mpcs->pcs;
> +}
> +EXPORT_SYMBOL(mtk_pcs_lynxi_get);
> +
> +void mtk_pcs_lynxi_put(struct phylink_pcs *pcs)
> +{
> +	struct mtk_pcs_lynxi *cur, *mpcs = NULL;
> +
> +	if (!pcs)
> +		return;
> +
> +	mutex_lock(&instance_mutex);
> +	list_for_each_entry(cur, &mtk_pcs_lynxi_instances, node)
> +		if (pcs == &cur->pcs) {
> +			mpcs = cur;
> +			break;
> +		}
> +	mutex_unlock(&instance_mutex);

I don't see what this loop gains us, other than checking that the "pcs"
is still on the list and hasn't already been removed. If that is all
that this is about, then I would suggest:

	bool found = false;

	if (!pcs)
		return;

	mpcs = pcs_to_mtk_pcs_lynxi(pcs);
	mutex_lock(&instance_mutex);
	list_for_each_entry(cur, &mtk_pcs_lynxi_instances, node)
		if (cur == mpcs) {
			found = true;
			break;
		}
	mutex_unlock(&instance_mutex);

	if (WARN_ON(!found))
		return;

which makes it more obvious why this exists.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From twoerner at gmail.com  Wed Dec 13 08:05:55 2023
From: twoerner at gmail.com (Trevor Woerner)
Date: Wed, 13 Dec 2023 11:05:55 -0500
Subject: [PATCH v2] arm64: rockchip: dts: rk3328-rock-pi-e: add gpio-line-names
Message-ID: <20231213160556.14424-1-twoerner@gmail.com>

Add names to the pins of the general-purpose expansion header as given
in the Radxa GPIO page[1] following the conventions in the kernel
documentation[2] to make it easier for users to correlate the pins with
functions when using utilities such as 'gpioinfo'.

Signed-off-by: Trevor Woerner <twoerner at gmail.com>
---
changes in v2:
- fix subject from "amd64..." to "arm64..."
---
 .../boot/dts/rockchip/rk3328-rock-pi-e.dts    | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
index 018a3a5075c7..3169c0854061 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -388,3 +388,56 @@ &usbdrd3 {
 &usb_host0_ehci {
 	status = "okay";
 };
+
+&gpio0 {
+	gpio-line-names =
+	/* GPIO0_A0 - A7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO0_B0 - B7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO0_C0 - C7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO0_D0 - D7 */
+	"", "", "", "pin-15 [GPIO0_D3]", "", "", "", "";
+};
+
+&gpio1 {
+	gpio-line-names =
+	/* GPIO1_A0 - A7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO1_B0 - B7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO1_C0 - C7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO1_D0 - D7 */
+	"", "", "", "", "pin-07 [GPIO1_D4]", "", "", "";
+};
+
+&gpio2 {
+	gpio-line-names =
+	/* GPIO2_A0 - A7 */
+	"pin-08 [GPIO2_A0]", "pin-10 [GPIO2_A1]", "pin-11 [GPIO2_A2]",
+	"pin-13 [GPIO2-A3]", "pin-27 [GPIO2_A4]", "pin-28 [GPIO2_A5]",
+	"pin-33 [GPIO2_A6]", "",
+	/* GPIO2_B0 - B7 */
+	"", "", "", "", "pin-26 [GPIO2_B4]", "", "", "pin-36 [GPIO2_B7]",
+	/* GPIO2_C0 - C7 */
+	"pin-32 [GPIO2_C0]", "pin-35 [GPIO2_C1]", "pin-12 [GPIO2_C2]",
+	"pin-38 [GPIO2_C3]", "pin-29 [GPIO2_C4]", "pin-31 [GPIO2_C5]",
+	"pin-37 [GPIO2_C6]", "pin-40 [GPIO2_C7]",
+	/* GPIO2_D0 - D7 */
+	"", "", "", "", "", "", "", "";
+};
+
+&gpio3 {
+	gpio-line-names =
+	/* GPIO3_A0 - A7 */
+	"pin-23 [GPIO3_A0]", "pin-19 [GPIO3_A1]", "pin-21 [GPIO3_A2]",
+	"", "pin-03 [GPIO3_A4]", "", "pin-05 [GPIO3_A6]", "",
+	/* GPIO3_B0 - B7 */
+	"pin-24 [GPIO3_B0]", "", "", "", "", "", "", "",
+	/* GPIO3_C0 - C7 */
+	"", "", "", "", "", "", "", "",
+	/* GPIO3_D0 - D7 */
+	"", "", "", "", "", "", "", "";
+};
-- 
2.41.0.327.gaa9166bcc0ba



From alim.akhtar at samsung.com  Wed Dec 13 08:09:41 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Wed, 13 Dec 2023 21:39:41 +0530
Subject: [PATCH] dt-bindings: pinctrl: samsung: correct ExynosAutov920
 wake-up compatibles
In-Reply-To: <20231210133915.42112-1-krzysztof.kozlowski@linaro.org>
References: <CGME20231210133923epcas5p2b8c2e0d2bd5f54a338deb13ccde8f9ba@epcas5p2.samsung.com>
	<20231210133915.42112-1-krzysztof.kozlowski@linaro.org>
Message-ID: <016e01da2dde$c9777610$5c666230$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: Sunday, December 10, 2023 7:09 PM
> To: Tomasz Figa <tomasz.figa at gmail.com>; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>; Sylwester Nawrocki
> <s.nawrocki at samsung.com>; Alim Akhtar <alim.akhtar at samsung.com>;
> Linus Walleij <linus.walleij at linaro.org>; Rob Herring
<robh+dt at kernel.org>;
> Conor Dooley <conor+dt at kernel.org>; Jaewon Kim
> <jaewon02.kim at samsung.com>; linux-arm-kernel at lists.infradead.org;
> linux-samsung-soc at vger.kernel.org; linux-gpio at vger.kernel.org;
> devicetree at vger.kernel.org; linux-kernel at vger.kernel.org
> Subject: [PATCH] dt-bindings: pinctrl: samsung: correct ExynosAutov920
> wake-up compatibles
> 
> ExynosAutov920 SoC wake-up pin controller has different register layout
> than Exynos7, thus it should not be marked as compatible.  Neither DTS nor
> Linux driver was merged yet, so the change does not impact ABI.
> 
> Cc: Jaewon Kim <jaewon02.kim at samsung.com>
> Fixes: 904140fa4553 ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks
for
> newer wake-up controllers")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>

> ---
> 
.
.
.
--
> 2.34.1
> 




From kernel at xen0n.name  Wed Dec 13 08:13:11 2023
From: kernel at xen0n.name (WANG Xuerui)
Date: Thu, 14 Dec 2023 00:13:11 +0800
Subject: [RFC PATCH 06/12] LoongArch: Implement
 ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-7-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-7-samuel.holland@sifive.com>
Message-ID: <cc762327-796a-481b-9d79-3751361daff8@xen0n.name>

On 12/8/23 13:54, Samuel Holland wrote:
> LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
> asm/fpu.h, so it only needs to add kernel_fpu_available() and export
> the CFLAGS adjustments.
>
> Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
> ---
>
>   arch/loongarch/Kconfig           | 1 +
>   arch/loongarch/Makefile          | 5 ++++-
>   arch/loongarch/include/asm/fpu.h | 1 +
>   3 files changed, 6 insertions(+), 1 deletion(-)

This is all intuitive wrapping, so:

Acked-by: WANG Xuerui <git at xen0n.name>

Thanks!

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/



From robh at kernel.org  Wed Dec 13 08:13:47 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 13 Dec 2023 10:13:47 -0600
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <20231212164004.1683589-3-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-3-ninad@linux.ibm.com>
Message-ID: <20231213161347.GA1204384-robh@kernel.org>

On Tue, Dec 12, 2023 at 10:39:58AM -0600, Ninad Palsule wrote:
> From: Johannes Holland <johannes.holland at infineon.com>
> 
> Add a dt schema to support device tree bindings for the generic I2C
> physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
> Specification for TPM 2.0 v1.04 Revision 14.
> 
> This includes descriptions for the Nuvoton and Infineon devices.

This is incomplete and conflicts with this series[1]. Please help 
review and make sure it works for the cases you care about.

Rob

[1] https://lore.kernel.org/all/cover.1701093036.git.lukas at wunner.de/


From lee at kernel.org  Wed Dec 13 08:16:24 2023
From: lee at kernel.org (Lee Jones)
Date: Wed, 13 Dec 2023 16:16:24 +0000
Subject: (subset) [PATCH] leds: sun50i-a100: avoid division-by-zero
 warning
In-Reply-To: <20231212214536.175327-1-arnd@kernel.org>
References: <20231212214536.175327-1-arnd@kernel.org>
Message-ID: <170248418423.1005780.5339514949375553684.b4-ty@kernel.org>

On Tue, 12 Dec 2023 22:45:22 +0100, Arnd Bergmann wrote:
> When CONFIG_COMMON_CLK is disabled, e.g. on an x86 randconfig compile test,
> clang reports a field overflow from propagating the result of a division by
> zero:
> 
> drivers/leds/leds-sun50i-a100.c:309:12: error: call to '__compiletime_assert_265' declared with 'error' attribute: FIELD_PREP: value too large for the field
>         control = FIELD_PREP(LEDC_T01_TIMING_CTRL_REG_T1H, timing->t1h_ns / cycle_ns) |
> 
> [...]

Applied, thanks!

[1/1] leds: sun50i-a100: avoid division-by-zero warning
      commit: f969d75a0218da32c40dd4940bd430b0530433cf

--
Lee Jones [???]



From kan.liang at linux.intel.com  Wed Dec 13 08:17:47 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Wed, 13 Dec 2023 11:17:47 -0500
Subject: [PATCH V2 3/5] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <20231213133336.GA3895246@leoy-yangtze.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-4-kan.liang@linux.intel.com>
 <20231209054809.GB2116834@leoy-yangtze.lan>
 <3b67c2de-741d-4d5e-8c8f-87b8b9e08825@linux.intel.com>
 <20231213133336.GA3895246@leoy-yangtze.lan>
Message-ID: <64c2808e-ac2b-41c0-9e98-61b22e3031c1@linux.intel.com>



On 2023-12-13 8:33 a.m., Leo Yan wrote:
>>> I am a bit suspect if we really need the field '.aux_event', the
>>> '.aux_event' field is only used for generating event string.
>> No, it stores the event encoding for the extra event.
>> ARM doesn't need it, so it's 0.
> I searched a bit and confirmed '.aux_event' is only used in
> util/mem-events.c and for 'perf record'.
> 
> I failed to connect the code with "it stores the event encoding for the
> extra event".  Could you elaborate a bit for this?

The details of the reason of introducing the mem_load aux event can be
found here.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=61b985e3e775a3a75fda04ce7ef1b1aefc4758bc

A mem_load_aux event is a new requirement for SPR. For the other Intel
platforms, a single mem_load event is good enough to collect the data
source information. But for SPR, we have to group both the mem_load
event and the mem_load_aux event when collecting the data source
information. In the group, the mem_load_aux event must be the leader
event. But for the sample read case, only the sampling of the mem_load
make sense. So the is_mem_loads_aux_event() is introduced to switch the
sampling event to the mem_load event. Here is the perf tool patch.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a57d40832dc8366bc517bcbbfdb1d7fb583735b

The .aux_event is to store the event encoding of the mem_load_aux event.
If it's the leader of a sampling read group, we should use the second
event as a sampling event.

Thanks,
Kan


From tanmay.shah at amd.com  Wed Dec 13 08:18:14 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Wed, 13 Dec 2023 10:18:14 -0600
Subject: [PATCH v2] dt-bindings: mailbox: add Versal IPI bindings
In-Reply-To: <d91a9278-f70e-4f0f-92c1-ce0bdac69ff5@linaro.org>
References: <20231212230353.888714-1-tanmay.shah@amd.com>
 <d91a9278-f70e-4f0f-92c1-ce0bdac69ff5@linaro.org>
Message-ID: <44052047-06c9-4b95-b040-2d4c7c1343d1@amd.com>

Hi Krzysztof,

Thanks for reviews. Please find my comments below inline.


On 12/13/23 12:35 AM, Krzysztof Kozlowski wrote:
> On 13/12/2023 00:03, Tanmay Shah wrote:
> > Add documentation for AMD-Xilinx Versal platform Inter Processor Interrupt
> > controller. Versal IPI controller contains buffer-less IPI which do not
> > have buffers for message passing. For such IPI channels message buffers
> > are not expected and only notification to/from remote agent is expected.
> > 
> > Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> > ---
> > 
>
>
> >  properties:
> >    compatible:
> > -    const: xlnx,zynqmp-ipi-mailbox
> > +    enum:
> > +      - xlnx,zynqmp-ipi-mailbox
> > +      - xlnx,versal-ipi-mailbox
> >  
> >    method:
> >      description: |
> >        The method of calling the PM-API firmware layer.
> > -      Permitted values are.
> > -      - "smc" : SMC #0, following the SMCCC
> > -      - "hvc" : HVC #0, following the SMCCC
> > -
>
> Independent change. Please do not mix logical changes in one patch.
>
> >      $ref: /schemas/types.yaml#/definitions/string
> >      enum:
> >        - smc
> > @@ -58,16 +56,26 @@ properties:
> >    '#size-cells':
> >      const: 2
> >  
> > -  xlnx,ipi-id:
> > -    description: |
> > -      Remote Xilinx IPI agent ID of which the mailbox is connected to.
> > -    $ref: /schemas/types.yaml#/definitions/uint32
> > +  reg:
> > +    minItems: 1
> > +    maxItems: 2
> > +
> > +  reg-names:
> > +    minItems: 1
> > +    maxItems: 2
>
> I don't understand why this change is here. Previously you did not have
> MMIO address space? If yes, then where do you restrict the old device to
> disallow these?


Hardware description is different between ZynqMP and Versal. And so, we have to design

new bindings for Versal. reg and reg-names for parent node, is only available for new devices.

The new device is checked with compatible string after "required" section.

Should I add "unevaluatedProperties: false" after "additionalProperties: false" for parent node below [1] ?


>
> >  
> >    interrupts:
> >      maxItems: 1
> >  
> >    ranges: true
> >  
> > +  xlnx,ipi-id:
> > +    description: |
> > +      Remote Xilinx IPI agent ID of which the mailbox is connected to.
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 0
> > +    maximum: 64
> > +
> >  patternProperties:
> >    '^mailbox@[0-9a-f]+$':
> >      description: Internal ipi mailbox node
> > @@ -76,57 +84,116 @@ patternProperties:
> >      properties:
> >  
> >        compatible:
> > -        const: xlnx,zynqmp-ipi-dest-mailbox
> > +        enum:
> > +          - xlnx,zynqmp-ipi-dest-mailbox
> > +          - xlnx,versal-ipi-dest-mailbox
> >  
> > -      xlnx,ipi-id:
> > -        description:
> > -          Remote Xilinx IPI agent ID of which the mailbox is connected to.
> > -        $ref: /schemas/types.yaml#/definitions/uint32
> > +      reg:
> > +        minItems: 1
> > +        maxItems: 4
> > +
> > +      reg-names:
> > +        minItems: 1
> > +        maxItems: 4
>
> Same concern.

This one, reg and reg-names are available for both old and new devices but, with different

definition. And this is checked based on compatible of child node below [2].


>
> >  
> >        '#mbox-cells':
> >          const: 1
> >          description:
> >            It contains tx(0) or rx(1) channel IPI id number.
> >  
> > -      reg:
> > -        maxItems: 4
> > -
> > -      reg-names:
> > -        items:
> > -          - const: local_request_region
> > -          - const: local_response_region
> > -          - const: remote_request_region
> > -          - const: remote_response_region
> > +      xlnx,ipi-id:
> > +        description:
> > +          Remote Xilinx IPI agent ID of which the mailbox is connected to.
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +        minimum: 0
> > +        maximum: 64
> >  
> >      required:
> >        - compatible
> >        - reg
> >        - reg-names
> >        - "#mbox-cells"
> > -
> > -additionalProperties: false
> > -
> > +      - xlnx,ipi-id
> > +
> > +    allOf:
> > +      - if:
> > +          properties:
> > +            compatible:
> > +              contains:
> > +                enum:
> > +                  - xlnx,zynqmp-ipi-dest-mailbox

[2] Here based on compatible string, "reg" and "reg-names" are defined.


> > +        then:
> > +          properties:
> > +            reg:
> > +              items:
> > +                - description: Host agent request message buffer
> > +                - description: Host agent response message buffer
> > +                - description: Remote agent request message buffer
> > +                - description: Remote agent response message buffer
> > +
> > +            reg-names:
> > +              items:
> > +                - const: local_request_region
> > +                - const: local_response_region
> > +                - const: remote_request_region
> > +                - const: remote_response_region
> > +        else:
> > +          properties:
> > +            reg:
> > +              minItems: 1
> > +              items:
> > +                - description: Remote IPI agent control register
> > +                - description: Remote IPI agent optional message buffer
>
> Were these described in old binding? If not, it's a separate change.

Okay, so I will split this in two patches:

1) Clean up current bindings (like remove redundant descriptino, sort "required" property order etc..)

2) Add versal platforms bindings doc. (This will add if else cases and Versal platform support)


> > +
> > +            reg-names:
> > +              minItems: 1
> > +              items:
> > +                - const: ctrl
> > +                - const: msg
>
> Blank line
>
> >  required:
> >    - compatible
> > -  - interrupts
> >    - '#address-cells'
> >    - '#size-cells'
> > +  - interrupts
>
> Separate change with its own rationale. Trivial cleanups can be
> organized in one patch, but should not be mixed with adding new devices.

Ack


> >    - xlnx,ipi-id
> >  
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - xlnx,versal-ipi-mailbox
> > +    then:
> > +      properties:
> > +        reg:
> > +          items:
> > +            - description: Host IPI agent control registers
> > +            - description: Host IPI agent optional message buffers
> > +
> > +        reg-names:
> > +          items:
> > +            - const: ctrl
> > +            - const: msg
> > +
> > +      required:
> > +        - reg
> > +        - reg-names
> > +
> > +additionalProperties: false

[1] Here, if I add unevaluatedProperties: false then is it enough for old device to disallow

"reg" and "reg-names" for parent node ?

If not, could you please suggest how to achieve this?

Or is there a way to undefine "reg" and "reg-names" based on compatible property ?

Based on your feedback, I will post v3.


> > +
> > +
>
> Just one blank line.

Ack.


>
> >  examples:
> >    - |
> >      #include<dt-bindings/interrupt-controller/arm-gic.h>
> >  
> > -    amba {
> > -      #address-cells = <0x2>;
> > -      #size-cells = <0x2>;
> > +    bus {
> >        zynqmp-mailbox {
> >          compatible = "xlnx,zynqmp-ipi-mailbox";
> >          interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
> >          xlnx,ipi-id = <0>;
> >          #address-cells = <2>;
> >          #size-cells = <2>;
> > -        ranges;
>
> How is this related to Versal?

Yeah its not, will go in cleanup patch.

>
> >  
> >          mailbox: mailbox at ff9905c0 {
> >            compatible = "xlnx,zynqmp-ipi-dest-mailbox";
> > @@ -144,4 +211,41 @@ examples:
> >        };
> >      };
> >  
> > +  - |
> > +    #include<dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +    bus {
> > +      #address-cells = <2>;
> > +      #size-cells = <2>;
> > +      zynqmp-mailbox at ff300000 {
>
> mailbox@

Ack.

>
> > +        compatible = "xlnx,versal-ipi-mailbox";
> > +        interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
> > +        #address-cells = <2>;
> > +        #size-cells = <2>;
> > +        reg = <0x0 0xff300000 0x0 0x1000>,
> > +              <0x0 0xff990000 0x0 0x1ff>;
> > +        reg-names = "ctrl", "msg";
> > +        xlnx,ipi-id = <0>;
> > +        ranges;
> > +
>
>
> Best regards,
> Krzysztof
>


From kan.liang at linux.intel.com  Wed Dec 13 08:19:42 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Wed, 13 Dec 2023 11:19:42 -0500
Subject: [PATCH V2 1/5] perf mem: Add mem_events into the supported
 perf_pmu
In-Reply-To: <20231213142414.GH86143@leoy-huanghe.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-2-kan.liang@linux.intel.com>
 <20231208102922.GB769184@leoy-huanghe.lan>
 <98863f44-4a35-4910-8db0-dbbf0474f6ae@linux.intel.com>
 <20231209063440.GE2116834@leoy-yangtze.lan>
 <ee9db34a-2b3d-46b3-ba36-22a22b080d70@linux.intel.com>
 <20231213142414.GH86143@leoy-huanghe.lan>
Message-ID: <95fee418-27bc-4a0c-b438-8d6d770dbefc@linux.intel.com>



On 2023-12-13 9:24 a.m., Leo Yan wrote:
> On Mon, Dec 11, 2023 at 02:01:37PM -0500, Liang, Kan wrote:
> 
> [...]
> 
>>> I will hold on a bit for the test until this patch set addresses the
>>> concern for the breakage issues on Arm64. Please check my review in
>>> other replies.
>>
>> The reviews in the other replies don't look like break any current usage
>> on Arm64. I think the breakage issue is what you described in this
>> patch, right?
> 
> I mentioned the breakage is in the patch 04, but I think the concern
> is dismissed.
> 
>> If we move the check of "arm_spe_0" to arch/arm/util/pmu.c, it seems we
>> have to move the perf_mem_events_arm[] into arch/arm/util/mem-events.c
>> as well. Is it OK?
> 
> No.  For fixing Arm64 building, please refer:
> 
> https://termbin.com/0dkn


That's great! Thanks a lot!

> 
>> I'm not familiar with ARM and have no idea how those events are
>> organized under arm64 and arm. Could you please send a fix for the
>> building failure on aarch64? I will fold it into the V3.
> 
> After apply the change in above link on the top of your patch set,
> it can build successfully at my side. Hope it's helpful.
> 

Yes, that's help a lot. I will send the V3 shortly.

Thanks,
Kan


From will at kernel.org  Wed Dec 13 08:19:44 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 16:19:44 +0000
Subject: [RFC PATCH 04/12] arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231208055501.2916202-5-samuel.holland@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-5-samuel.holland@sifive.com>
Message-ID: <20231213161944.GA32062@willie-the-truck>

On Thu, Dec 07, 2023 at 09:54:34PM -0800, Samuel Holland wrote:
> arm64 provides an equivalent to the common kernel-mode FPU API, but in a
> different header and using different function names. Add a wrapper
> header, and export CFLAGS adjustments as found in lib/raid6/Makefile.
> 
> Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
> ---
> 
>  arch/arm64/Kconfig           |  1 +
>  arch/arm64/Makefile          |  9 ++++++++-
>  arch/arm64/include/asm/fpu.h | 17 +++++++++++++++++
>  3 files changed, 26 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/include/asm/fpu.h
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7b071a00425d..485ac389ac11 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -30,6 +30,7 @@ config ARM64
>  	select ARCH_HAS_GCOV_PROFILE_ALL
>  	select ARCH_HAS_GIGANTIC_PAGE
>  	select ARCH_HAS_KCOV
> +	select ARCH_HAS_KERNEL_FPU_SUPPORT if KERNEL_MODE_NEON
>  	select ARCH_HAS_KEEPINITRD
>  	select ARCH_HAS_MEMBARRIER_SYNC_CORE
>  	select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 9a2d3723cd0f..4a65f24c7998 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -36,7 +36,14 @@ ifeq ($(CONFIG_BROKEN_GAS_INST),y)
>  $(warning Detected assembler with broken .inst; disassembly will be unreliable)
>  endif
>  
> -KBUILD_CFLAGS	+= -mgeneral-regs-only	\
> +# The GCC option -ffreestanding is required in order to compile code containing
> +# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
> +CC_FLAGS_FPU	:= -ffreestanding
> +# Enable <arm_neon.h>
> +CC_FLAGS_FPU	+= -isystem $(shell $(CC) -print-file-name=include)
> +CC_FLAGS_NO_FPU	:= -mgeneral-regs-only
> +
> +KBUILD_CFLAGS	+= $(CC_FLAGS_NO_FPU) \
>  		   $(compat_vdso) $(cc_has_k_constraint)
>  KBUILD_CFLAGS	+= $(call cc-disable-warning, psabi)
>  KBUILD_AFLAGS	+= $(compat_vdso)

Can you use this to replace the same logic in arch/arm64/lib/Makefile,
like you do for arch/arm/?

Will


From krzysztof.kozlowski at linaro.org  Wed Dec 13 08:21:36 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 17:21:36 +0100
Subject: [PATCH v2] dt-bindings: mailbox: add Versal IPI bindings
In-Reply-To: <44052047-06c9-4b95-b040-2d4c7c1343d1@amd.com>
References: <20231212230353.888714-1-tanmay.shah@amd.com>
 <d91a9278-f70e-4f0f-92c1-ce0bdac69ff5@linaro.org>
 <44052047-06c9-4b95-b040-2d4c7c1343d1@amd.com>
Message-ID: <daa14201-2027-4732-bbea-acbb2675e4b8@linaro.org>

On 13/12/2023 17:18, Tanmay Shah wrote:


>>> +    minItems: 1
>>> +    maxItems: 2
>>
>> I don't understand why this change is here. Previously you did not have
>> MMIO address space? If yes, then where do you restrict the old device to
>> disallow these?
> 
> 
> Hardware description is different between ZynqMP and Versal. And so, we have to design
> 
> new bindings for Versal. reg and reg-names for parent node, is only available for new devices.
> 
> The new device is checked with compatible string after "required" section.

Hm? What does that mean?

> 
> Should I add "unevaluatedProperties: false" after "additionalProperties: false" for parent node below [1] ?

No, you should disallow reg/reg-names for older device.

...

> 
>>> +        then:
>>> +          properties:
>>> +            reg:
>>> +              items:
>>> +                - description: Host agent request message buffer
>>> +                - description: Host agent response message buffer
>>> +                - description: Remote agent request message buffer
>>> +                - description: Remote agent response message buffer
>>> +
>>> +            reg-names:
>>> +              items:
>>> +                - const: local_request_region
>>> +                - const: local_response_region
>>> +                - const: remote_request_region
>>> +                - const: remote_response_region
>>> +        else:
>>> +          properties:
>>> +            reg:
>>> +              minItems: 1
>>> +              items:
>>> +                - description: Remote IPI agent control register
>>> +                - description: Remote IPI agent optional message buffer
>>
>> Were these described in old binding? If not, it's a separate change.
> 
> Okay, so I will split this in two patches:
> 
> 1) Clean up current bindings (like remove redundant descriptino, sort "required" property order etc..)

If you want to combine cleanup and functional changes, then this would
be two patches.

> 
> 2) Add versal platforms bindings doc. (This will add if else cases and Versal platform support)

> 
> 
>>> +
>>> +            reg-names:
>>> +              minItems: 1
>>> +              items:
>>> +                - const: ctrl
>>> +                - const: msg
>>
>> Blank line
>>
>>>  required:
>>>    - compatible
>>> -  - interrupts
>>>    - '#address-cells'
>>>    - '#size-cells'
>>> +  - interrupts
>>
>> Separate change with its own rationale. Trivial cleanups can be
>> organized in one patch, but should not be mixed with adding new devices.
> 
> Ack
> 
> 
>>>    - xlnx,ipi-id
>>>  
>>> +allOf:
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            enum:
>>> +              - xlnx,versal-ipi-mailbox
>>> +    then:
>>> +      properties:
>>> +        reg:
>>> +          items:
>>> +            - description: Host IPI agent control registers
>>> +            - description: Host IPI agent optional message buffers
>>> +
>>> +        reg-names:
>>> +          items:
>>> +            - const: ctrl
>>> +            - const: msg
>>> +
>>> +      required:
>>> +        - reg
>>> +        - reg-names
>>> +
>>> +additionalProperties: false
> 
> [1] Here, if I add unevaluatedProperties: false then is it enough for old device to disallow

No, you need reg:false

Best regards,
Krzysztof



From alim.akhtar at samsung.com  Wed Dec 13 08:24:01 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Wed, 13 Dec 2023 21:54:01 +0530
Subject: [PATCH v7 09/16] pinctrl: samsung: Add gs101 SoC pinctrl
 configuration
In-Reply-To: <20231211162331.435900-10-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
	<CGME20231211162431epcas5p2e2ec25eea1849559515c4e2855a8d58c@epcas5p2.samsung.com>
	<20231211162331.435900-10-peter.griffin@linaro.org>
Message-ID: <017201da2de0$cb2ed820$618c8860$@samsung.com>

Hi Peter

> -----Original Message-----
> From: Peter Griffin <peter.griffin at linaro.org>
> Sent: Monday, December 11, 2023 9:53 PM
> To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> will at kernel.org; arnd at arndb.de; olof at lixom.net;
> gregkh at linuxfoundation.org; jirislaby at kernel.org;
> cw00.choi at samsung.com; alim.akhtar at samsung.com
> Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
> andre.draszik at linaro.org; semen.protsenko at linaro.org;
> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> team at android.com; linux-serial at vger.kernel.org
> Subject: [PATCH v7 09/16] pinctrl: samsung: Add gs101 SoC pinctrl
> configuration
> 
> Add support for the pin-controller found on the gs101 SoC used in Pixel 6
> phones.
> 
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>

Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>

> ---
>  .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 140 ++++++++++++++++++
>  drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
>  drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
>  3 files changed, 143 insertions(+)
> 
[snip]
> 
> --
> 2.43.0.472.g3155946c3a-goog




From robin.murphy at arm.com  Wed Dec 13 08:24:07 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 13 Dec 2023 16:24:07 +0000
Subject: [PATCH] perf/arm-cmn: Improve debugfs pretty-printing for large configs
Message-ID: <1d1517eadd1bac5992fab679c9dc531b381944da.1702484646.git.robin.murphy@arm.com>

The debugfs pretty-printer was written for the CMN-600 assumptions of a
maximum 8x8 mesh, but CMN-700 now allows coordinates and ID values up to
12 and 128 respectively, which can overflow the format strings, mess up
the alignment of the table and hurt overall readability. This table does
prove useful for double-checking that the driver is picking up the
topology of new systems correctly and for verifying user expectations,
so tweak the formatting to stay nice and readable with wider values.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/perf/arm-cmn.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index 878b95920ed2..1f3ebfd8c057 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -493,6 +493,7 @@ static void arm_cmn_show_logid(struct seq_file *s, int x, int y, int p, int d)
 
 	for (dn = cmn->dns; dn->type; dn++) {
 		struct arm_cmn_nodeid nid = arm_cmn_nid(cmn, dn->id);
+		int pad = dn->logid < 10;
 
 		if (dn->type == CMN_TYPE_XP)
 			continue;
@@ -503,7 +504,7 @@ static void arm_cmn_show_logid(struct seq_file *s, int x, int y, int p, int d)
 		if (nid.x != x || nid.y != y || nid.port != p || nid.dev != d)
 			continue;
 
-		seq_printf(s, "   #%-2d  |", dn->logid);
+		seq_printf(s, " %*c#%-*d  |", pad + 1, ' ', 3 - pad, dn->logid);
 		return;
 	}
 	seq_puts(s, "        |");
@@ -516,7 +517,7 @@ static int arm_cmn_map_show(struct seq_file *s, void *data)
 
 	seq_puts(s, "     X");
 	for (x = 0; x < cmn->mesh_x; x++)
-		seq_printf(s, "    %d    ", x);
+		seq_printf(s, "    %-2d   ", x);
 	seq_puts(s, "\nY P D+");
 	y = cmn->mesh_y;
 	while (y--) {
@@ -526,13 +527,13 @@ static int arm_cmn_map_show(struct seq_file *s, void *data)
 		for (x = 0; x < cmn->mesh_x; x++)
 			seq_puts(s, "--------+");
 
-		seq_printf(s, "\n%d    |", y);
+		seq_printf(s, "\n%-2d   |", y);
 		for (x = 0; x < cmn->mesh_x; x++) {
 			struct arm_cmn_node *xp = cmn->xps + xp_base + x;
 
 			for (p = 0; p < CMN_MAX_PORTS; p++)
 				port[p][x] = arm_cmn_device_connect_info(cmn, xp, p);
-			seq_printf(s, " XP #%-2d |", xp_base + x);
+			seq_printf(s, " XP #%-3d|", xp_base + x);
 		}
 
 		seq_puts(s, "\n     |");
-- 
2.39.2.101.g768bb238c484.dirty



From suzuki.poulose at arm.com  Wed Dec 13 08:28:49 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Wed, 13 Dec 2023 16:28:49 +0000
Subject: [PATCH 1/8] coresight: Fix issue where a source device's helpers
 aren't disabled
In-Reply-To: <3c7665ff-b2e2-f10d-a78a-4ddc1791926f@arm.com>
References: <20231212155407.1429121-1-james.clark@arm.com>
 <20231212155407.1429121-2-james.clark@arm.com>
 <a1ab2481-0ec0-4e29-b6af-bcce4cf0b57d@arm.com>
 <3c7665ff-b2e2-f10d-a78a-4ddc1791926f@arm.com>
Message-ID: <68d6f2bb-3c18-4dce-ba32-6925955dcc35@arm.com>

On 13/12/2023 13:54, James Clark wrote:
> 
> 
> On 12/12/2023 17:44, Suzuki K Poulose wrote:
>> Hi James
>>
>> On 12/12/2023 15:53, James Clark wrote:
>>> The linked commit reverts the change that accidentally used some sysfs
>>> enable/disable functions from Perf which broke the refcounting, but it
>>> also removes the fact that the sysfs disable function disabled the
>>> helpers.
>>
>>
>>>
>>> Add a new wrapper function that does both which is used by both Perf and
>>> sysfs, and label the sysfs disable function appropriately. The naming of
>>> all of the functions will be tidied up later to avoid this happening
>>> again.
>>>
>>> Fixes: 287e82cf69aa ("coresight: Fix crash when Perf and sysfs modes
>>> are used concurrently")
>>
>> But we still don't "enable" the helpers from perf mode with this patch.
>> i.e., we use source_ops()->enable directly. So, I guess this patch
>> doesn't fix a bug as such. But that said, it would be good to
>> enable/disable helpers for sources, in perf mode.
>>
>> Suzuki
> 
> We do, it happens in coresight_enable_path() which Perf uses. I added
> the comment below about that.

Ah, I see. That indeed is a bit confusing. And I think all users of 
coresight_enable_path() enables the source right after. So, I don't
see any point in having it separate. That said, this fix makes sense
and apologies for the confusion. We could may be cleanup the 
enable_path() to enable the source too, in a separate patch.

Suzuki


> 
>   [...]
> 
>>>  ? +/*
>>> + * Helper function to call source_ops(csdev)->disable and also
>>> disable the
>>> + * helpers.
>>> + *
>>> + * There is an imbalance between coresight_enable_path() and
>>> + * coresight_disable_path(). Enabling also enables the source's
>>> helpers as part
>>> + * of the path, but disabling always skips the first item in the path
>>> (which is
>>> + * the source), so sources and their helpers don't get disabled as
>>> part of that
>>> + * function and we need the extra step here.
>>> + */
> 
> The reason coresight_disable_path() skips the first item is because it's
> used after errors where a path is only partially enabled and it unwinds,
> skipping the last item, because the last item didn't enable.
> 
> It seemed a bit more intrusive to change that, and it's already working.



From alim.akhtar at samsung.com  Wed Dec 13 08:32:00 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Wed, 13 Dec 2023 22:02:00 +0530
Subject: [PATCH v7 10/16] watchdog: s3c2410_wdt: Add support for WTCON
 register DBGACK_MASK bit
In-Reply-To: <20231211162331.435900-11-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
	<CGME20231211162433epcas5p382678abfa0f045b73a2d8c12c74d3f17@epcas5p3.samsung.com>
	<20231211162331.435900-11-peter.griffin@linaro.org>
Message-ID: <017301da2de1$e8cafe80$ba60fb80$@samsung.com>

Hi Peter

> -----Original Message-----
> From: Peter Griffin <peter.griffin at linaro.org>
> Sent: Monday, December 11, 2023 9:53 PM
> To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> will at kernel.org; arnd at arndb.de; olof at lixom.net;
> gregkh at linuxfoundation.org; jirislaby at kernel.org;
> cw00.choi at samsung.com; alim.akhtar at samsung.com
> Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
> andre.draszik at linaro.org; semen.protsenko at linaro.org;
> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> team at android.com; linux-serial at vger.kernel.org
> Subject: [PATCH v7 10/16] watchdog: s3c2410_wdt: Add support for WTCON
> register DBGACK_MASK bit
> 
> The WDT uses the CPU core signal DBGACK to determine whether the SoC is
> running in debug mode or not. If the DBGACK signal is asserted and
> DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
> (disabled).
> 
> Presence of the DBGACK_MASK bit is determined by adding a new
> QUIRK_HAS_DBGACK_BIT quirk. Also update to use BIT macro to avoid
> checkpatch --strict warnings.
> 
> Tested-by: Will McVicker <willmcvicker at google.com>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  drivers/watchdog/s3c2410_wdt.c | 28 +++++++++++++++++++++++++---
>  1 file changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/watchdog/s3c2410_wdt.c
> b/drivers/watchdog/s3c2410_wdt.c index 0b4bd883ff28..7ecb762a371d
> 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -9,6 +9,7 @@
>   *     (c) Copyright 1996 Alan Cox <alan at lxorguk.ukuu.org.uk>
>   */
> 
> +#include <linux/bits.h>
>  #include <linux/module.h>
>  #include <linux/moduleparam.h>
>  #include <linux/types.h>
> @@ -34,9 +35,10 @@
> 
>  #define S3C2410_WTCNT_MAXCNT	0xffff
> 
> -#define S3C2410_WTCON_RSTEN	(1 << 0)
> -#define S3C2410_WTCON_INTEN	(1 << 2)
> -#define S3C2410_WTCON_ENABLE	(1 << 5)
> +#define S3C2410_WTCON_RSTEN		BIT(0)
> +#define S3C2410_WTCON_INTEN		BIT(2)
> +#define S3C2410_WTCON_ENABLE		BIT(5)
> +#define S3C2410_WTCON_DBGACK_MASK	BIT(16)
> 
>  #define S3C2410_WTCON_DIV16	(0 << 3)
>  #define S3C2410_WTCON_DIV32	(1 << 3)
> @@ -100,12 +102,17 @@
>   * %QUIRK_HAS_PMU_CNT_EN: PMU block has some register (e.g.
> CLUSTERx_NONCPU_OUT)
>   * with "watchdog counter enable" bit. That bit should be set to make
> watchdog
>   * counter running.
> + *
> + * %QUIRK_HAS_DBGACK_BIT: WTCON register has DBGACK_MASK bit.
> Setting
> + the
> + * DBGACK_MASK bit disables the watchdog outputs when the SoC is in
> debug mode.
> + * Debug mode is determined by the DBGACK CPU signal.
>   */
>  #define QUIRK_HAS_WTCLRINT_REG			(1 << 0)
>  #define QUIRK_HAS_PMU_MASK_RESET		(1 << 1)
>  #define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
>  #define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
>  #define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
Probably these above defines might also give checkpatch --strict warnings,
so you can change to use  BIT macro here as well.

> +#define QUIRK_HAS_DBGACK_BIT			BIT(5)
> 
>  /* These quirks require that we have a PMU register map */  #define
> QUIRKS_HAVE_PMUREG \ @@ -375,6 +382,19 @@ static int
> s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
>  	return 0;
>  }
> 
> +/* Disable watchdog outputs if CPU is in debug mode */ static void
> +s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt) {
> +	unsigned long wtcon;
> +
> +	if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
> +		return;
> +
> +	wtcon = readl(wdt->reg_base + S3C2410_WTCON);
> +	wtcon |= S3C2410_WTCON_DBGACK_MASK;
> +	writel(wtcon, wdt->reg_base + S3C2410_WTCON); }
> +
>  static int s3c2410wdt_keepalive(struct watchdog_device *wdd)  {
>  	struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd); @@ -700,6
> +720,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
>  	wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
>  	wdt->wdt_device.parent = dev;
> 
> +	s3c2410wdt_mask_dbgack(wdt);
> +
>  	/*
>  	 * If "tmr_atboot" param is non-zero, start the watchdog right now.
> Also
>  	 * set WDOG_HW_RUNNING bit, so that watchdog core can kick the
> watchdog.
> --
> 2.43.0.472.g3155946c3a-goog




From alim.akhtar at samsung.com  Wed Dec 13 08:34:26 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Wed, 13 Dec 2023 22:04:26 +0530
Subject: [PATCH v7 11/16] watchdog: s3c2410_wdt: Update QUIRK macros to
 use BIT macro
In-Reply-To: <20231211162331.435900-12-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
	<CGME20231211162434epcas5p485e7b2edbb02a1b6ea04ff5cc758f5db@epcas5p4.samsung.com>
	<20231211162331.435900-12-peter.griffin@linaro.org>
Message-ID: <017401da2de2$400ec6e0$c02c54a0$@samsung.com>



> -----Original Message-----
> From: Peter Griffin <peter.griffin at linaro.org>
> Sent: Monday, December 11, 2023 9:53 PM
> To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> will at kernel.org; arnd at arndb.de; olof at lixom.net;
> gregkh at linuxfoundation.org; jirislaby at kernel.org;
> cw00.choi at samsung.com; alim.akhtar at samsung.com
> Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
> andre.draszik at linaro.org; semen.protsenko at linaro.org;
> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> team at android.com; linux-serial at vger.kernel.org
> Subject: [PATCH v7 11/16] watchdog: s3c2410_wdt: Update QUIRK macros to
> use BIT macro
> 
> Update the remaining QUIRK macros to use the BIT macro.
> 
Ah! I see you have change use BIT here, so you can squash this patch to
patch 10/16 or
Move BIT change from patch 10/16 to this patch. Either way is fine.

> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  drivers/watchdog/s3c2410_wdt.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/s3c2410_wdt.c
> b/drivers/watchdog/s3c2410_wdt.c index 7ecb762a371d..b7a03668f743
> 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -107,11 +107,11 @@
>   * DBGACK_MASK bit disables the watchdog outputs when the SoC is in
> debug mode.
>   * Debug mode is determined by the DBGACK CPU signal.
>   */
> -#define QUIRK_HAS_WTCLRINT_REG			(1 << 0)
> -#define QUIRK_HAS_PMU_MASK_RESET		(1 << 1)
> -#define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
> -#define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
> -#define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
> +#define QUIRK_HAS_WTCLRINT_REG			BIT(0)
> +#define QUIRK_HAS_PMU_MASK_RESET		BIT(1)
> +#define QUIRK_HAS_PMU_RST_STAT			BIT(2)
> +#define QUIRK_HAS_PMU_AUTO_DISABLE		BIT(3)
> +#define QUIRK_HAS_PMU_CNT_EN			BIT(4)
>  #define QUIRK_HAS_DBGACK_BIT			BIT(5)
> 
>  /* These quirks require that we have a PMU register map */
> --
> 2.43.0.472.g3155946c3a-goog




From tanmay.shah at amd.com  Wed Dec 13 08:35:57 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Wed, 13 Dec 2023 10:35:57 -0600
Subject: [PATCH v2] dt-bindings: mailbox: add Versal IPI bindings
In-Reply-To: <daa14201-2027-4732-bbea-acbb2675e4b8@linaro.org>
References: <20231212230353.888714-1-tanmay.shah@amd.com>
 <d91a9278-f70e-4f0f-92c1-ce0bdac69ff5@linaro.org>
 <44052047-06c9-4b95-b040-2d4c7c1343d1@amd.com>
 <daa14201-2027-4732-bbea-acbb2675e4b8@linaro.org>
Message-ID: <1027ec80-bed6-4b51-b346-60bc19aa04e6@amd.com>


On 12/13/23 10:21 AM, Krzysztof Kozlowski wrote:
> On 13/12/2023 17:18, Tanmay Shah wrote:
>
>
> >>> +    minItems: 1
> >>> +    maxItems: 2
> >>
> >> I don't understand why this change is here. Previously you did not have
> >> MMIO address space? If yes, then where do you restrict the old device to
> >> disallow these?
> > 
> > 
> > Hardware description is different between ZynqMP and Versal. And so, we have to design
> > 
> > new bindings for Versal. reg and reg-names for parent node, is only available for new devices.
> > 
> > The new device is checked with compatible string after "required" section.
>
> Hm? What does that mean?


Following [1]. I think You answered what needs to be done. I will have reg: false for old devices.

Thanks.


>
> > 
> > Should I add "unevaluatedProperties: false" after "additionalProperties: false" for parent node below [1] ?
>
> No, you should disallow reg/reg-names for older device.
>
> ...
>
> > 
> >>> +        then:
> >>> +          properties:
> >>> +            reg:
> >>> +              items:
> >>> +                - description: Host agent request message buffer
> >>> +                - description: Host agent response message buffer
> >>> +                - description: Remote agent request message buffer
> >>> +                - description: Remote agent response message buffer
> >>> +
> >>> +            reg-names:
> >>> +              items:
> >>> +                - const: local_request_region
> >>> +                - const: local_response_region
> >>> +                - const: remote_request_region
> >>> +                - const: remote_response_region
> >>> +        else:
> >>> +          properties:
> >>> +            reg:
> >>> +              minItems: 1
> >>> +              items:
> >>> +                - description: Remote IPI agent control register
> >>> +                - description: Remote IPI agent optional message buffer
> >>
> >> Were these described in old binding? If not, it's a separate change.
> > 
> > Okay, so I will split this in two patches:
> > 
> > 1) Clean up current bindings (like remove redundant descriptino, sort "required" property order etc..)
>
> If you want to combine cleanup and functional changes, then this would
> be two patches.
>
> > 
> > 2) Add versal platforms bindings doc. (This will add if else cases and Versal platform support)

In that case, can I just post single patch that adds new device support ?

Won't touch anything that is not needed for new device support.


>
> > 
> > 
> >>> +
> >>> +            reg-names:
> >>> +              minItems: 1
> >>> +              items:
> >>> +                - const: ctrl
> >>> +                - const: msg
> >>
> >> Blank line
> >>
> >>>  required:
> >>>    - compatible
> >>> -  - interrupts
> >>>    - '#address-cells'
> >>>    - '#size-cells'
> >>> +  - interrupts
> >>
> >> Separate change with its own rationale. Trivial cleanups can be
> >> organized in one patch, but should not be mixed with adding new devices.
> > 
> > Ack
> > 
> > 
> >>>    - xlnx,ipi-id
> >>>  
> >>> +allOf:
> >>> +  - if:
> >>> +      properties:
> >>> +        compatible:
> >>> +          contains:
> >>> +            enum:
> >>> +              - xlnx,versal-ipi-mailbox
> >>> +    then:
> >>> +      properties:
> >>> +        reg:
> >>> +          items:
> >>> +            - description: Host IPI agent control registers
> >>> +            - description: Host IPI agent optional message buffers
> >>> +
> >>> +        reg-names:
> >>> +          items:
> >>> +            - const: ctrl
> >>> +            - const: msg
> >>> +
> >>> +      required:
> >>> +        - reg
> >>> +        - reg-names
> >>> +
> >>> +additionalProperties: false
> > 
> > [1] Here, if I add unevaluatedProperties: false then is it enough for old device to disallow
>
> No, you need reg:false
>
> Best regards,
> Krzysztof
>


From alim.akhtar at samsung.com  Wed Dec 13 08:42:02 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Wed, 13 Dec 2023 22:12:02 +0530
Subject: [PATCH v7 12/16] watchdog: s3c2410_wdt: Add support for Google
 gs101 SoC
In-Reply-To: <20231211162331.435900-13-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
	<CGME20231211162436epcas5p4161dfb5a2b849edc6856662e5b42693d@epcas5p4.samsung.com>
	<20231211162331.435900-13-peter.griffin@linaro.org>
Message-ID: <017501da2de3$4fad8950$ef089bf0$@samsung.com>



> -----Original Message-----
> From: Peter Griffin <peter.griffin at linaro.org>
> Sent: Monday, December 11, 2023 9:53 PM
> To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> will at kernel.org; arnd at arndb.de; olof at lixom.net;
> gregkh at linuxfoundation.org; jirislaby at kernel.org;
> cw00.choi at samsung.com; alim.akhtar at samsung.com
> Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
> andre.draszik at linaro.org; semen.protsenko at linaro.org;
> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> team at android.com; linux-serial at vger.kernel.org
> Subject: [PATCH v7 12/16] watchdog: s3c2410_wdt: Add support for Google
> gs101 SoC
> 
> This patch adds the compatibles and drvdata for the Google
> gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.
> 
> Similar to Exynos850 it has two watchdog instances, one for each cluster
and
> has some control bits in PMU registers.
> 
> gs101 also has the dbgack_mask bit in wtcon register, so we also enable
> QUIRK_HAS_DBGACK_BIT.
> 
> Tested-by: Will McVicker <willmcvicker at google.com>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
>  drivers/watchdog/s3c2410_wdt.c | 49
> ++++++++++++++++++++++++++++++----
>  1 file changed, 44 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/s3c2410_wdt.c
> b/drivers/watchdog/s3c2410_wdt.c index b7a03668f743..c3046610ab5d
> 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -69,6 +69,13 @@
>  #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
>  #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
> 
> 
[snip]
>  static const struct of_device_id s3c2410_wdt_match[] = {
> +	{ .compatible = "google,gs101-wdt",
> +	  .data = &drv_data_gs101_cl0 },
>  	{ .compatible = "samsung,s3c2410-wdt",
>  	  .data = &drv_data_s3c2410 },
>  	{ .compatible = "samsung,s3c6410-wdt", @@ -605,9 +640,10 @@
> s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct
> s3c2410_wdt *wdt)
>  	}
> 
>  #ifdef CONFIG_OF
> -	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index
> */
> +	/* Choose Exynos9 SoC family driver data w.r.t. cluster index */
Exynos9 introduction is out of context here, so you can leave it as original
comment, it is not adding anything here.

>  	if (variant == &drv_data_exynos850_cl0 ||
> -	    variant == &drv_data_exynosautov9_cl0) {
> +	    variant == &drv_data_exynosautov9_cl0 ||
> +	    variant == &drv_data_gs101_cl0) {
>  		u32 index;
[snip]
> --
> 2.43.0.472.g3155946c3a-goog




From lee at kernel.org  Wed Dec 13 08:42:29 2023
From: lee at kernel.org (Lee Jones)
Date: Wed, 13 Dec 2023 16:42:29 +0000
Subject: [PATCH 00/12] usb: Replace {v}snprintf() variants with safer alternatives
Message-ID: <20231213164246.1021885-1-lee@kernel.org>

This series is part of an effort to rid {v}snprintf() where possible.

For a far better description of the problem than I could author, see
Jon's write-up on LWN [1] and/or Alex's on the Kernel Self Protection
Project [1].

[0] https://lwn.net/Articles/69419/
[1] https://github.com/KSPP/linux/issues/105

Lee Jones (12):
  usb: gadget: configfs: Replace snprintf() with the safer scnprintf()
    variant
  usb: gadget: f_uac1: Replace snprintf() with the safer scnprintf()
    variant
  usb: gadget: f_uac2: Replace snprintf() with the safer scnprintf()
    variant
  usb: gadget: uvc: Replace snprintf() with the safer scnprintf()
    variant
  usb: gadget: udc: atmel: Replace snprintf() with the safer scnprintf()
    variant
  usb: cdns2: Replace snprintf() with the safer scnprintf() variant
  usb: host: max3421-hcd: Replace snprintf() with the safer scnprintf()
    variant
  usb: yurex: Replace snprintf() with the safer scnprintf() variant
  usb: mon_stat: Replace snprintf() with the safer scnprintf() variant
  usb: mon_text: Replace snprintf() with the safer scnprintf() variant
  usb: phy: twl6030: Remove snprintf() from sysfs call-backs and replace
    with sysfs_emit()
  usb: storage: Remove snprintf() from sysfs call-backs and replace with
    sysfs_emit()

 drivers/usb/gadget/configfs.c              |  11 +-
 drivers/usb/gadget/function/f_uac1.c       |   6 +-
 drivers/usb/gadget/function/f_uac2.c       |   6 +-
 drivers/usb/gadget/function/uvc_configfs.c |   2 +-
 drivers/usb/gadget/udc/atmel_usba_udc.c    |   3 +-
 drivers/usb/gadget/udc/cdns2/cdns2-debug.h | 138 ++++++++++-----------
 drivers/usb/host/max3421-hcd.c             |  18 +--
 drivers/usb/misc/yurex.c                   |  12 +-
 drivers/usb/mon/mon_stat.c                 |   6 +-
 drivers/usb/mon/mon_text.c                 |  28 +----
 drivers/usb/phy/phy-twl6030-usb.c          |   8 +-
 drivers/usb/storage/sierra_ms.c            |  16 +--
 12 files changed, 120 insertions(+), 134 deletions(-)

Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Alexandre Belloni <alexandre.belloni at bootlin.com>
Cc: Andrzej Pietrasiewicz <andrzejtp2010 at gmail.com>
Cc: Bryan Wu <cooloney at kernel.org>
Cc: Claudiu Beznea <claudiu.beznea at tuxon.dev>
Cc: Cristian Birsan <cristian.birsan at microchip.com>
Cc: Daniel Scally <dan.scally at ideasonboard.com>
Cc: Hema HK <hemahk at ti.com>
Cc: James Gruber <jimmyjgruber at gmail.com>
Cc: Jaswinder Singh <jaswinder.singh at linaro.org>
Cc: Julian Scheel <julian at jusst.de>
Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Nicolas Ferre <nicolas.ferre at microchip.com>
Cc: Pawel Laszczak <pawell at cadence.com>
Cc: Ruslan Bilovol <ruslan.bilovol at gmail.com>
Cc: Tomoki Sekiyama <tomoki.sekiyama at gmail.com>
Cc: usb-storage at lists.one-eyed-alien.net
Cc: Yadwinder Singh <yadi.brar01 at gmail.com>
-- 
2.43.0.472.g3155946c3a-goog



From lee at kernel.org  Wed Dec 13 08:42:34 2023
From: lee at kernel.org (Lee Jones)
Date: Wed, 13 Dec 2023 16:42:34 +0000
Subject: [PATCH 05/12] usb: gadget: udc: atmel: Replace snprintf() with the safer scnprintf() variant
In-Reply-To: <20231213164246.1021885-1-lee@kernel.org>
References: <20231213164246.1021885-1-lee@kernel.org>
Message-ID: <20231213164246.1021885-6-lee@kernel.org>

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Cristian Birsan <cristian.birsan at microchip.com>
Cc: Nicolas Ferre <nicolas.ferre at microchip.com>
Cc: Alexandre Belloni <alexandre.belloni at bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea at tuxon.dev>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Lee Jones <lee at kernel.org>
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 02b1bef5e22e2..b76885d78e8a7 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -94,7 +94,7 @@ static ssize_t queue_dbg_read(struct file *file, char __user *buf,
 
 	inode_lock(file_inode(file));
 	list_for_each_entry_safe(req, tmp_req, queue, queue) {
-		len = snprintf(tmpbuf, sizeof(tmpbuf),
+		len = scnprintf(tmpbuf, sizeof(tmpbuf),
 				"%8p %08x %c%c%c %5d %c%c%c\n",
 				req->req.buf, req->req.length,
 				req->req.no_interrupt ? 'i' : 'I',
@@ -104,7 +104,6 @@ static ssize_t queue_dbg_read(struct file *file, char __user *buf,
 				req->submitted ? 'F' : 'f',
 				req->using_dma ? 'D' : 'd',
 				req->last_transaction ? 'L' : 'l');
-		len = min(len, sizeof(tmpbuf));
 		if (len > nbytes)
 			break;
 
-- 
2.43.0.472.g3155946c3a-goog



From lee at kernel.org  Wed Dec 13 08:42:36 2023
From: lee at kernel.org (Lee Jones)
Date: Wed, 13 Dec 2023 16:42:36 +0000
Subject: [PATCH 07/12] usb: host: max3421-hcd: Replace snprintf() with the safer scnprintf() variant
In-Reply-To: <20231213164246.1021885-1-lee@kernel.org>
References: <20231213164246.1021885-1-lee@kernel.org>
Message-ID: <20231213164246.1021885-8-lee@kernel.org>

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Cristian Birsan <cristian.birsan at microchip.com>
Cc: Nicolas Ferre <nicolas.ferre at microchip.com>
Cc: Alexandre Belloni <alexandre.belloni at bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea at tuxon.dev>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Lee Jones <lee at kernel.org>
---
 drivers/usb/host/max3421-hcd.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index d152d72de1269..9fe4f48b18980 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1158,12 +1158,12 @@ dump_eps(struct usb_hcd *hcd)
 		end = dp + sizeof(ubuf);
 		*dp = '\0';
 		list_for_each_entry(urb, &ep->urb_list, urb_list) {
-			ret = snprintf(dp, end - dp, " %p(%d.%s %d/%d)", urb,
-				       usb_pipetype(urb->pipe),
-				       usb_urb_dir_in(urb) ? "IN" : "OUT",
-				       urb->actual_length,
-				       urb->transfer_buffer_length);
-			if (ret < 0 || ret >= end - dp)
+			ret = scnprintf(dp, end - dp, " %p(%d.%s %d/%d)", urb,
+					usb_pipetype(urb->pipe),
+					usb_urb_dir_in(urb) ? "IN" : "OUT",
+					urb->actual_length,
+					urb->transfer_buffer_length);
+			if (ret == end - dp - 1)
 				break;	/* error or buffer full */
 			dp += ret;
 		}
@@ -1255,9 +1255,9 @@ max3421_handle_irqs(struct usb_hcd *hcd)
 			end = sbuf + sizeof(sbuf);
 			*dp = '\0';
 			for (i = 0; i < 16; ++i) {
-				int ret = snprintf(dp, end - dp, " %lu",
-						   max3421_hcd->err_stat[i]);
-				if (ret < 0 || ret >= end - dp)
+				int ret = scnprintf(dp, end - dp, " %lu",
+						    max3421_hcd->err_stat[i]);
+				if (ret == end - dp - 1)
 					break;	/* error or buffer full */
 				dp += ret;
 			}
-- 
2.43.0.472.g3155946c3a-goog



From tharvey at gateworks.com  Wed Dec 13 08:43:40 2023
From: tharvey at gateworks.com (Tim Harvey)
Date: Wed, 13 Dec 2023 08:43:40 -0800
Subject: [PATCH 2/3] arm64: dts: imx8mp-venice: Fix USB connector description
In-Reply-To: <20231207185543.2699697-2-festevam@gmail.com>
References: <20231207185543.2699697-1-festevam@gmail.com> <20231207185543.2699697-2-festevam@gmail.com>
Message-ID: <CAJ+vNU1gw6=56bD_uNbsQ8qkFtk-COhGRC4nE1SJ60FO+9diyg@mail.gmail.com>

On Thu, Dec 7, 2023 at 10:55?AM Fabio Estevam <festevam at gmail.com> wrote:
>
> From: Fabio Estevam <festevam at denx.de>
>
> The USB connector should not be placed under the dwc3 node.
>
> Move the USB connector out of the SoC level and use port to describe
> the connection to the dwc3 controller.
>
> This fixes the following dt-schema warning:
>
> imx8mp-venice-gw72xx-2x.dtb: usb at 38100000: Unevaluated properties are not allowed ('connector' was unexpected)
>         from schema $id: http://devicetree.org/schemas/usb/snps,dwc3.yaml#
>

Fabio,

Thank you for this. There is an extra leading blank line before
'connector' that should probably be fixed:

> Signed-off-by: Fabio Estevam <festevam at denx.de>
> ---
>  .../dts/freescale/imx8mp-venice-gw71xx.dtsi   | 26 +++++++++++++-----
>  .../dts/freescale/imx8mp-venice-gw72xx.dtsi   | 27 ++++++++++++++-----
>  .../dts/freescale/imx8mp-venice-gw73xx.dtsi   | 27 ++++++++++++++-----
>  .../dts/freescale/imx8mp-venice-gw74xx.dts    | 27 ++++++++++++++-----
>  4 files changed, 79 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi
> index bf47b5e9dd8c..0e8d0f3c7ea8 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi
> @@ -8,6 +8,21 @@
>  #include <dt-bindings/phy/phy-imx8-pcie.h>
>
>  / {
> +       connector {
> +               compatible = "gpio-usb-b-connector", "usb-b-connector";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_usbcon1>;
> +               type = "micro";
> +               label = "Type-C";
> +               id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +
> +               port {
> +                       usb_dr_connector: endpoint {
> +                               remote-endpoint = <&usb3_dwc>;
> +                       };
> +               };
> +       };
> +
>         led-controller {
>                 compatible = "gpio-leds";
>                 pinctrl-names = "default";
> @@ -132,13 +147,10 @@ &usb_dwc3_0 {
>         role-switch-default-mode = "peripheral";
>         status = "okay";
>
> -       connector {
> -               compatible = "gpio-usb-b-connector", "usb-b-connector";
> -               pinctrl-names = "default";
> -               pinctrl-0 = <&pinctrl_usbcon1>;
> -               type = "micro";
> -               label = "Type-C";
> -               id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +       port {
> +               usb3_dwc: endpoint {
> +                       remote-endpoint = <&usb_dr_connector>;
> +               };
>         };
>  };
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi
> index 28eb7c00a1d9..f8ad5ea96330 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi
> @@ -8,6 +8,22 @@
>  #include <dt-bindings/phy/phy-imx8-pcie.h>
>
>  / {
> +

leading blank line

> +       connector {
> +               compatible = "gpio-usb-b-connector", "usb-b-connector";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_usbcon1>;
> +               type = "micro";
> +               label = "otg";
> +               id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +
> +               port {
> +                       usb_dr_connector: endpoint {
> +                               remote-endpoint = <&usb3_dwc>;
> +                       };
> +               };
> +       };
> +
>         led-controller {
>                 compatible = "gpio-leds";
>                 pinctrl-names = "default";
> @@ -182,13 +198,10 @@ &usb_dwc3_0 {
>         role-switch-default-mode = "peripheral";
>         status = "okay";
>
> -       connector {
> -               compatible = "gpio-usb-b-connector", "usb-b-connector";
> -               pinctrl-names = "default";
> -               pinctrl-0 = <&pinctrl_usbcon1>;
> -               type = "micro";
> -               label = "otg";
> -               id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +       port {
> +               usb3_dwc: endpoint {
> +                       remote-endpoint = <&usb_dr_connector>;
> +               };
>         };
>  };
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi
> index b0d42b18c5ce..0b89aa73998c 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi
> @@ -8,6 +8,22 @@
>  #include <dt-bindings/phy/phy-imx8-pcie.h>
>
>  / {
> +

leading blank line

> +       connector {
> +               compatible = "gpio-usb-b-connector", "usb-b-connector";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_usbcon1>;
> +               type = "micro";
> +               label = "otg";
> +               id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +
> +               port {
> +                       usb_dr_connector: endpoint {
> +                               remote-endpoint = <&usb3_dwc>;
> +                       };
> +               };
> +       };
> +
>         led-controller {
>                 compatible = "gpio-leds";
>                 pinctrl-names = "default";
> @@ -201,13 +217,10 @@ &usb_dwc3_0 {
>         role-switch-default-mode = "peripheral";
>         status = "okay";
>
> -       connector {
> -               compatible = "gpio-usb-b-connector", "usb-b-connector";
> -               pinctrl-names = "default";
> -               pinctrl-0 = <&pinctrl_usbcon1>;
> -               type = "micro";
> -               label = "otg";
> -               id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +       port {
> +               usb3_dwc: endpoint {
> +                       remote-endpoint = <&usb_dr_connector>;
> +               };
>         };
>  };
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts
> index dcf9bababffc..b323711fa090 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts
> @@ -35,6 +35,22 @@ memory at 40000000 {
>                 reg = <0x0 0x40000000 0 0x80000000>;
>         };
>
> +

leading blank line

> +       connector {
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_usbcon1>;
> +               compatible = "gpio-usb-b-connector", "usb-b-connector";
> +               type = "micro";
> +               label = "Type-C";
> +               id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
> +
> +               port {
> +                       usb_dr_connector: endpoint {
> +                               remote-endpoint = <&usb3_dwc>;
> +                       };
> +               };
> +       };
> +
>         gpio-keys {
>                 compatible = "gpio-keys";
>
> @@ -692,13 +708,10 @@ &usb_dwc3_0 {
>         role-switch-default-mode = "peripheral";
>         status = "okay";
>
> -       connector {
> -               pinctrl-names = "default";
> -               pinctrl-0 = <&pinctrl_usbcon1>;
> -               compatible = "gpio-usb-b-connector", "usb-b-connector";
> -               type = "micro";
> -               label = "Type-C";
> -               id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
> +       port {
> +               usb3_dwc: endpoint {
> +                       remote-endpoint = <&usb_dr_connector>;
> +               };
>         };
>  };
>

with those minor changes (if we even care to make them):

Acked-by: Tim Harvey <tharvey at gateworks.com>

Best regards,

Tim


From neil.armstrong at linaro.org  Wed Dec 13 08:44:28 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Wed, 13 Dec 2023 17:44:28 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
 <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
Message-ID: <212239ae-60ab-46f3-a838-39a4d61091fe@linaro.org>

Hi Maxime,

Le 13/12/2023 ? 09:36, Maxime Ripard a ?crit?:
> Hi,
> 
> On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
>> On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
>>> On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
>>>> clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
>>>> that and don't check the return value. This series fixes the four users
>>>> that do error checking on the returned value and then makes function
>>>> return void.
>>>>
>>>> Given that the changes to the drivers are simple and so merge conflicts
>>>> (if any) should be easy to handle, I suggest to merge this complete
>>>> series via the clk tree.
>>>
>>> I don't think it's the right way to go about it.
>>>
>>> clk_rate_exclusive_get() should be expected to fail. For example if
>>> there's another user getting an exclusive rate on the same clock.
>>>
>>> If we're not checking for it right now, then it should probably be
>>> fixed, but the callers checking for the error are right to do so if they
>>> rely on an exclusive rate. It's the ones that don't that should be
>>> modified.
>>
>> If some other consumer has already "locked" a clock that I call
>> clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
>> this function because I don't want the rate to change e.g. because I
>> setup some registers in the consuming device to provide a fixed UART
>> baud rate or i2c bus frequency (and that works as expected).
> 
> I guess it's a larger conversation, but I don't see how that can
> possibly work.
> 
> The way the API is designed, you have no guarantee (outside of
> clk_rate_exclusive_*) that the rate is going to change.
> 
> And clk_rate_exclusive_get() doesn't allow the rate to change while in
> the "critical section".
> 
> So the only possible thing to do is clk_set_rate() +
> clk_rate_exclusive_get().

There's clk_set_rate_exclusive() for this purpose.

> 
> So there's a window where the clock can indeed be changed, and the
> consumer that is about to lock its rate wouldn't be aware of it.
> 
> I guess it would work if you don't care about the rate at all, you just
> want to make sure it doesn't change.
> 
> Out of the 7 users of that function, 3 are in that situation, so I guess
> it's fair.
> 
> 3 are open to that race condition I mentioned above.
> 
> 1 is calling clk_set_rate while in the critical section, which works if
> there's a single user but not if there's multiple, so it should be
> discouraged.
> 
>> In this case I won't be able to change the rate of the clock, but that
>> is signalled by clk_set_rate() failing (iff and when I need awother
>> rate) which also seems the right place to fail to me.
> 
> Which is ignored by like half the callers, including the one odd case I
> mentioned above.
> 
> And that's super confusing still: you can *always* get exclusivity, but
> not always do whatever you want with the rate when you have it? How are
> drivers supposed to recover from that? You can handle failing to get
> exclusivity, but certainly not working around variable guarantees.
> 
>> It's like that since clk_rate_exclusive_get() was introduced in 2017
>> (commit 55e9b8b7b806ec3f9a8817e13596682a5981c19c).
> 
> Right, but "it's always been that way" surely can't be an argument,
> otherwise you wouldn't have done that series in the first place.
> 
>> BTW, I just noticed that my assertion "Most users \"know\" that
>> [clk_rate_exclusive_get() returns zero unconditionally]" is wrong. As of
>> next-20231213 there are 3 callers ignoring the return value of
>> clk_rate_exclusive_get() and 4 that handle (imaginary) returned errors.
>> I expected this function to be used more extensively. (In fact I think
>> it should be used more as several drivers rely on the clk rate not
>> changing.)
> 
> Yes, but also it's super difficult to use in practice, and most devices
> don't care.
> 
> The current situation is something like this:
> 
>    * Only a handful of devices really care about their clock rate, and
>      often only for one of their clock if they have several. You would
>      probably get all the devices that create an analog signal somehow
>      there, so audio, display, i2c, spi, uarts, etc. Plus the ones doing
>      frequency scaling so CPU and GPUs.
> 
>    * CPUs and GPUs are very likely to have a dedicated clock, so we can
>      rule the "another user is going to mess with my clock" case.
> 
>    * UARTs/i2c/etc. are usually taking their clock from the bus interface
>      directly which is pretty much never going to change (for good
>      reason). And the rate of the bus is not really likely to change.
> 
>    * SPI/NAND/MMC usually have their dedicated clock too, and the bus
>      rate is not likely to change after the initial setup either.
> 
> So, the only affected devices are the ones generating external signals,
> with the rate changing during the life of the system. Even for audio or
> video devices, that's fairly unlikely to happen. And you need to have
> multiple devices sharing the same clock tree for that issue to occur,
> which is further reducing the chances it happens.

Well, thanks for HW designers, this exists and some SoCs has less PLLs than
needed, and they can't be dedicated for some hw blocks.

> 
> Realistically speaking, this only occurs with multi-head display outputs
> where it's somewhat likely to have all the display controllers feeding
> from the same clock, and the power up of the various output is done in
> sequence which creates that situation.
> 
> And even then, the clk_rate_exclusive_* interface effectively locks the
> entire clock subtree to its current rate, so the effect on the rest of
> the devices can be significant.
> 
> So... yeah. Even though you're right, it's trying to address a problem
> that is super unlikely to happen with a pretty big hammer that might be
> too much for most. So it's not really surprising it's not used more.

Honestly I tried my best to find a smart way to set the DSI clock tree
with only 2 endpoints of the tree, but CCF will explore all possibilities
and since you cannot set constraints, locking a sub-tree is the smartest
way I found.
In this case, the PLL is common between the DSI controller and video generator,
so to keep the expected clock ratio, the smart way is to set the freq on
one side, lock the subtree and set the rate on the other side.
An API permitting to set multiple rates to multiple clocks in a single call
would be the solution, but not sure if we could possibly write such algorithm.

> 
> Maxime

Neil


From alim.akhtar at samsung.com  Wed Dec 13 08:44:41 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Wed, 13 Dec 2023 22:14:41 +0530
Subject: [PATCH v7 13/16] tty: serial: samsung: Add gs101 compatible and
 common fifoszdt_serial_drv_data
In-Reply-To: <20231211162331.435900-14-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
	<CGME20231211162437epcas5p2d640158c5afd1b4a58c7f9f7b2966300@epcas5p2.samsung.com>
	<20231211162331.435900-14-peter.griffin@linaro.org>
Message-ID: <017601da2de3$ae2298e0$0a67caa0$@samsung.com>



> -----Original Message-----
> From: Peter Griffin <peter.griffin at linaro.org>
> Sent: Monday, December 11, 2023 9:53 PM
> To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> will at kernel.org; arnd at arndb.de; olof at lixom.net;
> gregkh at linuxfoundation.org; jirislaby at kernel.org;
> cw00.choi at samsung.com; alim.akhtar at samsung.com
> Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
> andre.draszik at linaro.org; semen.protsenko at linaro.org;
> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> team at android.com; linux-serial at vger.kernel.org
> Subject: [PATCH v7 13/16] tty: serial: samsung: Add gs101 compatible and
> common fifoszdt_serial_drv_data
> 
> Add serial driver data for Google Tensor gs101 SoC and a common
> fifoszdt_serial_drv_data that can be used by platforms that specify the
> samsung,uart-fifosize DT property.
> 
> A corresponding dt-bindings patch updates the yaml to ensure
> samsung,uart-fifosize is a required property.
> 
> Tested-by: Will McVicker <willmcvicker at google.com>
> Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Reviewed-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>

>  drivers/tty/serial/samsung_tty.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/tty/serial/samsung_tty.c
> b/drivers/tty/serial/samsung_tty.c
> index 1b0c2b467a30..71d17d804fda 100644
> --- a/drivers/tty/serial/samsung_tty.c
> +++ b/drivers/tty/serial/samsung_tty.c
> @@ -2490,14 +2490,25 @@ static const struct s3c24xx_serial_drv_data
> exynos850_serial_drv_data = {
>  	.fifosize = { 256, 64, 64, 64 },
>  };
> 
> +/*
> + * Common drv_data struct for platforms that specify
> +samsung,uart-fifosize in
> + * device tree.
> + */
> +static const struct s3c24xx_serial_drv_data
> exynos_fifoszdt_serial_drv_data = {
> +	EXYNOS_COMMON_SERIAL_DRV_DATA(),
> +	.fifosize = { 0 },
> +};
[snip]
>  MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
> --
> 2.43.0.472.g3155946c3a-goog




From Frank.li at nxp.com  Wed Dec 13 08:46:17 2023
From: Frank.li at nxp.com (Frank Li)
Date: Wed, 13 Dec 2023 11:46:17 -0500
Subject: [PATCH v3 08/13] dt-bindings: imx6q-pcie: Add imx95 pcie
 compatible string
In-Reply-To: <ZXnQKBnweCT+si6/@lizhi-Precision-Tower-5810>
References: <20231211215842.134823-1-Frank.Li@nxp.com>
 <20231211215842.134823-9-Frank.Li@nxp.com>
 <20231212224426.GA2948988-robh@kernel.org>
 <ZXjsq2QtFa2V0BAl@lizhi-Precision-Tower-5810>
 <20231213143615.GA1093782-robh@kernel.org>
 <ZXnQKBnweCT+si6/@lizhi-Precision-Tower-5810>
Message-ID: <ZXnf2f8C2i2TFVBh@lizhi-Precision-Tower-5810>

On Wed, Dec 13, 2023 at 10:39:20AM -0500, Frank Li wrote:
> On Wed, Dec 13, 2023 at 08:36:15AM -0600, Rob Herring wrote:
> > On Tue, Dec 12, 2023 at 06:28:43PM -0500, Frank Li wrote:
> > > On Tue, Dec 12, 2023 at 04:44:26PM -0600, Rob Herring wrote:
> > > > On Mon, Dec 11, 2023 at 04:58:37PM -0500, Frank Li wrote:
> > > > > From: Richard Zhu <hongxing.zhu at nxp.com>
> > > > > 
> > > > > Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
> > > > > Add "atu" and "serdes" to reg-names.
> > > > > 
> > > > > Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> > > > > ---
> > > > > 
> > > > > Notes:
> > > > >     Change from v2 to v3
> > > > >     - Remove krzy's ACK tag
> > > > >     - Add condition check for imx95, which required more reg-names then old
> > > > >     platform, so need Krzy review again,
> > > > >     
> > > > >     Change from v1 to v2
> > > > >     - add Krzy's ACK tag
> > > > > 
> > > > >  .../bindings/pci/fsl,imx6q-pcie.yaml           | 18 ++++++++++++++++++
> > > > >  1 file changed, 18 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > > > index 81bbb8728f0f9..b8fcf8258f031 100644
> > > > > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > > > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > > > > @@ -29,6 +29,7 @@ properties:
> > > > >        - fsl,imx8mq-pcie
> > > > >        - fsl,imx8mm-pcie
> > > > >        - fsl,imx8mp-pcie
> > > > > +      - fsl,imx95-pcie
> > > > >  
> > > > >    reg:
> > > > >      items:
> > > > > @@ -90,6 +91,22 @@ required:
> > > > >  allOf:
> > > > >    - $ref: /schemas/pci/snps,dw-pcie.yaml#
> > > > >    - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
> > > > > +  - if:
> > > > > +      properties:
> > > > > +        compatible:
> > > > > +          enum:
> > > > > +            - fsl,imx95-pcie
> > > > > +    then:
> > > > > +      properties:
> > > > > +        reg:
> > > > > +          minItems: 4
> > > > > +        reg-names:
> > > > > +          items:
> > > > > +            - const: dbi
> > > > > +            - const: serdes
> > > > 
> > > > Did you test this? It should fail because 'serdes' would need to be 
> > > > added to snps,dw-pcie.yaml.
> > > 
> > > I run "make dt_binding_check DT_SCHEMA_FILES=/pci/", no error report.
> > 
> > Only because you have no example. What about your actual .dts?
> 
> I see. 95 is quite new. Still have not good base yet.
> I may just take take care this session.
> 
> > 
> > > And PCIe function can work.
> > > 
> > > > 
> > > > Is this really not a separate phy block?
> > > 
> > > This is misc block, which included phy and also include some registers
> > > about SID for each PCI devices. I plan do it later.
> > 
> > Sounds like it should be a separate node and use the phy binding. Do it 
> > correctly from the start, not later. Later is an ABI break.
> 
> Actually, I considerred phy binding. The major problem is LUT (look up
> table) for MSI and SMMU. LUT need be config according to some PCI device
> information. I have not find good hook for that at PHY driver.
> 
> > 
> > What is SID?
> 
> Stream ID, each device master have SID, which pass to IOMMU and GIC ITS.
> 
> Frank

Similar case at

commit c6523c4a301d3adff7ddcf57515b9c847beb7566
Author: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Date:   Fri May 6 18:21:02 2022 +0300

    dt-bindings: PCI: qcom: Specify reg-names explicitly
    
    Instead of specifying the enum of possible reg-names, specify them
    explicitly. This allows us to specify which chipsets need the "atu"
    regions and which do not. Also it clearly describes which platforms
    enumerate PCIe cores using the dbi region and which use parf region for
    that.
    
    Link: https://lore.kernel.org/r/20220506152107.1527552-4-dmitry.baryshkov at linaro.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
    Acked-by: Rob Herring <robh at kernel.org>


+            - const: dbi # DesignWare PCIe registers
+            - const: elbi # External local bus interface registers
+            - const: parf # Qualcomm specific registers
                      ^^^^

+            - const: config # PCIe configuration space

Qualcomm called "part",  nxp call "serdes"

Frank

> 
> > 
> > Rob


From arinc.unal at arinc9.com  Wed Dec 13 08:51:49 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Wed, 13 Dec 2023 19:51:49 +0300
Subject: [PATCH net-next 00/15] MT7530 DSA subdriver improvements
In-Reply-To: <20231213151910.hr3n4px7a4upc372@skbuf>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <45221d69-a780-4e81-b4c3-db1b9894a1db@arinc9.com>
 <20231213151910.hr3n4px7a4upc372@skbuf>
Message-ID: <fe48082e-1545-4cb6-a29a-79b4f6276c91@arinc9.com>

On 13.12.2023 18:19, Vladimir Oltean wrote:
> Hi Ar?n?,
> 
> On Sat, Dec 02, 2023 at 11:52:13AM +0300, Ar?n? ?NAL wrote:
>> Can I receive reviews for patches 6, 12, 13, 14, and 15?
>>
>> Thanks.
>> Ar?n?
> 
> Sorry, I don't have time to look at this old thread anymore.
> 
> Please repost the series with the feedback you got so far addressed.
> Also, you can try to split into smaller, more cohesive groups of
> patches, that have higher chances of getting merged.

Thanks Vladimir. I've been fighting a bad fever with sore throat. I'll
submit the first 7 patches after working on your reviews.

Thanks a lot for your attention to my patches that's been going on for more
than half a year now.

Ar?n?


From alim.akhtar at samsung.com  Wed Dec 13 08:59:41 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Wed, 13 Dec 2023 22:29:41 +0530
Subject: [PATCH v7 15/16] arm64: dts: exynos: google: Add initial
 Oriole/pixel 6 board support
In-Reply-To: <20231211162331.435900-16-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
	<CGME20231211162439epcas5p208ddd651650cb5e8de3e8f411db7663d@epcas5p2.samsung.com>
	<20231211162331.435900-16-peter.griffin@linaro.org>
Message-ID: <018d01da2de5$c7153ef0$553fbcd0$@samsung.com>



> -----Original Message-----
> From: Peter Griffin <peter.griffin at linaro.org>
> Sent: Monday, December 11, 2023 9:54 PM
> To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> will at kernel.org; arnd at arndb.de; olof at lixom.net;
> gregkh at linuxfoundation.org; jirislaby at kernel.org;
> cw00.choi at samsung.com; alim.akhtar at samsung.com
> Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
> andre.draszik at linaro.org; semen.protsenko at linaro.org;
> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> team at android.com; linux-serial at vger.kernel.org
> Subject: [PATCH v7 15/16] arm64: dts: exynos: google: Add initial
Oriole/pixel
> 6 board support
> 
> Add initial board support for the Pixel 6 phone code named Oriole. This
has
> been tested with a minimal busybox initramfs and boots to a shell.
> 
> Tested-by: Will McVicker <willmcvicker at google.com>
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>

>  arch/arm64/boot/dts/exynos/Makefile           |   2 +
>  arch/arm64/boot/dts/exynos/google/Makefile    |   4 +
>  .../boot/dts/exynos/google/gs101-oriole.dts   | 105 ++++++++++++++++++
>  3 files changed, 111 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
>  create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> 
> diff --git a/arch/arm64/boot/dts/exynos/Makefile
> b/arch/arm64/boot/dts/exynos/Makefile
> index 6e4ba69268e5..44c24a8ad9e1 100644
> --- a/arch/arm64/boot/dts/exynos/Makefile
> +++ b/arch/arm64/boot/dts/exynos/Makefile
> @@ -1,4 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
> +subdir-y += google
> +
>  dtb-$(CONFIG_ARCH_EXYNOS) += \
>  	exynos5433-tm2.dtb		\
>  	exynos5433-tm2e.dtb		\
> diff --git a/arch/arm64/boot/dts/exynos/google/Makefile
> b/arch/arm64/boot/dts/exynos/google/Makefile
> new file mode 100644
> index 000000000000..0a6d5e1fe4ee
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +dtb-$(CONFIG_ARCH_EXYNOS) += \
> +	gs101-oriole.dtb \
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> new file mode 100644
> index 000000000000..4a71f752200d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Oriole Device Tree
> + *
> + * Copyright 2021-2023 Google LLC
> + * Copyright 2023 Linaro Ltd - <peter.griffin at linaro.org>  */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "gs101-pinctrl.h"
> +#include "gs101.dtsi"
> +
> +/ {
> +	model = "Oriole";
> +	compatible = "google,gs101-oriole", "google,gs101";
> +
> +	aliases {
> +		serial0 = &serial_0;
> +	};
> +
> +	chosen {
> +		/* Bootloader expects bootargs specified otherwise it
> crashes */
> +		bootargs = "";
> +		stdout-path = &serial_0;
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&key_voldown>, <&key_volup>,
> <&key_power>;
> +
> +		button-vol-down {
> +			label = "KEY_VOLUMEDOWN";
> +			linux,code = <KEY_VOLUMEDOWN>;
> +			gpios = <&gpa7 3 GPIO_ACTIVE_LOW>;
> +			wakeup-source;
> +		};
> +
> +		button-vol-up {
> +			label = "KEY_VOLUMEUP";
> +			linux,code = <KEY_VOLUMEUP>;
> +			gpios = <&gpa8 1 GPIO_ACTIVE_LOW>;
> +			wakeup-source;
> +		};
> +
> +		button-power {
> +			label = "KEY_POWER";
> +			linux,code = <KEY_POWER>;
> +			gpios = <&gpa10 1 GPIO_ACTIVE_LOW>;
> +			wakeup-source;
> +		};
> +	};
> +};
> +
> +&ext_24_5m {
> +	clock-frequency = <24576000>;
> +};
> +
> +&ext_200m {
> +	clock-frequency = <200000000>;
> +};
> +
> +&pinctrl_far_alive {
> +	key_voldown: key-voldown-pins {
> +		samsung,pins = "gpa7-3";
> +		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +
> +	key_volup: key-volup-pins {
> +		samsung,pins = "gpa8-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +};
> +
> +&pinctrl_gpio_alive {
> +	key_power: key-power-pins {
> +		samsung,pins = "gpa10-1";
> +		samsung,pin-function = <GS101_PIN_FUNC_EINT>;
> +		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
> +		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
> +	};
> +};
> +
> +&serial_0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_bus>;
> +	status = "okay";
> +};
> +
> +&usi_uart {
> +	samsung,clkreq-on; /* needed for UART mode */
> +	status = "okay";
> +};
> +
> +&watchdog_cl0 {
> +	timeout-sec = <30>;
> +	status = "okay";
> +};
> --
> 2.43.0.472.g3155946c3a-goog




From alim.akhtar at samsung.com  Wed Dec 13 09:00:16 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Wed, 13 Dec 2023 22:30:16 +0530
Subject: [PATCH v7 16/16] MAINTAINERS: add entry for Google Tensor SoC
In-Reply-To: <20231211162331.435900-17-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
	<CGME20231211162440epcas5p2a6f884784e8d9b03fcd9e6024ca9d3cf@epcas5p2.samsung.com>
	<20231211162331.435900-17-peter.griffin@linaro.org>
Message-ID: <018e01da2de5$dbb40620$931c1260$@samsung.com>



> -----Original Message-----
> From: Peter Griffin <peter.griffin at linaro.org>
> Sent: Monday, December 11, 2023 9:54 PM
> To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> will at kernel.org; arnd at arndb.de; olof at lixom.net;
> gregkh at linuxfoundation.org; jirislaby at kernel.org;
> cw00.choi at samsung.com; alim.akhtar at samsung.com
> Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
> andre.draszik at linaro.org; semen.protsenko at linaro.org;
> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> team at android.com; linux-serial at vger.kernel.org
> Subject: [PATCH v7 16/16] MAINTAINERS: add entry for Google Tensor SoC
> 
> Add maintainers entry for the Google tensor SoC based platforms.
> 
> Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---
Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>

>  MAINTAINERS | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 98f7dd0499f1..b731d6b9876a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8990,6 +8990,16 @@ S:	Maintained
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-
> platform/linux.git
>  F:	drivers/firmware/google/
> 
> +GOOGLE TENSOR SoC SUPPORT
> +M:	Peter Griffin <peter.griffin at linaro.org>
> +L:	linux-arm-kernel at lists.infradead.org (moderated for non-
> subscribers)
> +L:	linux-samsung-soc at vger.kernel.org
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> +F:	arch/arm64/boot/dts/exynos/google/
> +F:	drivers/clk/samsung/clk-gs101.c
> +F:	include/dt-bindings/clock/google,clk-gs101.h
> +
>  GPD POCKET FAN DRIVER
>  M:	Hans de Goede <hdegoede at redhat.com>
>  L:	platform-driver-x86 at vger.kernel.org
> --
> 2.43.0.472.g3155946c3a-goog




From robin.murphy at arm.com  Wed Dec 13 09:17:53 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 13 Dec 2023 17:17:53 +0000
Subject: [PATCH v2 0/7] dma-mapping: Simplify arch_setup_dma_ops()
Message-ID: <cover.1702486837.git.robin.murphy@arm.com>

v1: https://lore.kernel.org/linux-iommu/cover.1701268753.git.robin.murphy at arm.com/

Hi all,

Here's v2 with a few tweaks and fixes to address review comments, a
couple of major issues fixed in the last two patches that I really
should have spotted initially, plus a bit more code deletion that I
realised could fit in this step. I've left it tagged as a dma-mapping
series since spiritually it still is, but it looks like it will want
to go via the IOMMU tree.

Thanks,
Robin.


Robin Murphy (7):
  OF: Retire dma-ranges mask workaround
  OF: Simplify DMA range calculations
  ACPI/IORT: Handle memory address size limits as limits
  dma-mapping: Add helpers for dma_range_map bounds
  iommu/dma: Make limit checks self-contained
  iommu/dma: Centralise iommu_setup_dma_ops()
  dma-mapping: Simplify arch_setup_dma_ops()

 arch/arc/mm/dma.c               |  3 +--
 arch/arm/mm/dma-mapping-nommu.c |  3 +--
 arch/arm/mm/dma-mapping.c       | 18 +++++++-------
 arch/arm64/mm/dma-mapping.c     |  5 +---
 arch/loongarch/kernel/dma.c     |  9 ++-----
 arch/mips/mm/dma-noncoherent.c  |  3 +--
 arch/riscv/mm/dma-noncoherent.c |  3 +--
 drivers/acpi/arm64/dma.c        | 17 ++++---------
 drivers/acpi/arm64/iort.c       | 20 ++++++++--------
 drivers/acpi/scan.c             |  3 +--
 drivers/hv/hv_common.c          |  6 +----
 drivers/iommu/amd/iommu.c       |  8 -------
 drivers/iommu/dma-iommu.c       | 39 ++++++++++++------------------
 drivers/iommu/dma-iommu.h       | 14 +++++------
 drivers/iommu/intel/iommu.c     |  7 ------
 drivers/iommu/iommu.c           |  6 ++---
 drivers/iommu/s390-iommu.c      |  6 -----
 drivers/iommu/virtio-iommu.c    | 10 --------
 drivers/of/device.c             | 42 ++++++---------------------------
 include/linux/acpi_iort.h       |  4 ++--
 include/linux/dma-direct.h      | 18 ++++++++++++++
 include/linux/dma-map-ops.h     |  6 ++---
 include/linux/iommu.h           |  7 ------
 23 files changed, 86 insertions(+), 171 deletions(-)

-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Wed Dec 13 09:17:54 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 13 Dec 2023 17:17:54 +0000
Subject: [PATCH v2 1/7] OF: Retire dma-ranges mask workaround
In-Reply-To: <cover.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
Message-ID: <6b4156c5061e29bfd95fdd2f6744ee727ea7f1a2.1702486837.git.robin.murphy@arm.com>

The fixup adding 1 to the dma-ranges size may have been for the benefit
of some early AMD Seattle DTs, or may have merely been a just-in-case,
but either way anyone who might have deserved to get the message has
hopefully seen the warning in the 9 years we've had it there. The modern
dma_range_map mechanism should happily handle odd-sized ranges with no
ill effect, so there's little need to care anyway now. Clean it up.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
v2: Tweak commit message
---
 drivers/of/device.c | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 1ca42ad9dd15..526a42cdf66e 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -129,22 +129,6 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
 				dma_end = r->dma_start + r->size;
 		}
 		size = dma_end - dma_start;
-
-		/*
-		 * Add a work around to treat the size as mask + 1 in case
-		 * it is defined in DT as a mask.
-		 */
-		if (size & 1) {
-			dev_warn(dev, "Invalid size 0x%llx for dma-range(s)\n",
-				 size);
-			size = size + 1;
-		}
-
-		if (!size) {
-			dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
-			kfree(map);
-			return -EINVAL;
-		}
 	}
 
 	/*
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Wed Dec 13 09:17:55 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 13 Dec 2023 17:17:55 +0000
Subject: [PATCH v2 2/7] OF: Simplify DMA range calculations
In-Reply-To: <cover.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
Message-ID: <368a546e36235bd0008f66838d0c8edcd864ab94.1702486837.git.robin.murphy@arm.com>

Juggling start, end, and size values for a range is somewhat redundant
and a little hard to follow. Consolidate down to just using inclusive
start and end, which saves us worrying about size overflows for full
64-bit ranges (note that passing a potentially-overflowed value through
to arch_setup_dma_ops() is benign for all current implementations, and
this is working towards removing that anyway).

Acked-by: Rob Herring <robh at kernel.org>
Reviewed-by: Jason Gunthorpe <jgg at nvidia.com>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/of/device.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 526a42cdf66e..51062a831970 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -97,7 +97,7 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
 	const struct bus_dma_region *map = NULL;
 	struct device_node *bus_np;
 	u64 dma_start = 0;
-	u64 mask, end, size = 0;
+	u64 mask, end = 0;
 	bool coherent;
 	int ret;
 
@@ -118,17 +118,15 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
 			return ret == -ENODEV ? 0 : ret;
 	} else {
 		const struct bus_dma_region *r = map;
-		u64 dma_end = 0;
 
 		/* Determine the overall bounds of all DMA regions */
 		for (dma_start = ~0; r->size; r++) {
 			/* Take lower and upper limits */
 			if (r->dma_start < dma_start)
 				dma_start = r->dma_start;
-			if (r->dma_start + r->size > dma_end)
-				dma_end = r->dma_start + r->size;
+			if (r->dma_start + r->size > end)
+				end = r->dma_start + r->size;
 		}
-		size = dma_end - dma_start;
 	}
 
 	/*
@@ -142,16 +140,15 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
 		dev->dma_mask = &dev->coherent_dma_mask;
 	}
 
-	if (!size && dev->coherent_dma_mask)
-		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
-	else if (!size)
-		size = 1ULL << 32;
+	if (!end && dev->coherent_dma_mask)
+		end = dev->coherent_dma_mask;
+	else if (!end)
+		end = (1ULL << 32) - 1;
 
 	/*
 	 * Limit coherent and dma mask based on size and default mask
 	 * set by the driver.
 	 */
-	end = dma_start + size - 1;
 	mask = DMA_BIT_MASK(ilog2(end) + 1);
 	dev->coherent_dma_mask &= mask;
 	*dev->dma_mask &= mask;
@@ -177,7 +174,7 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
 	dev_dbg(dev, "device is%sbehind an iommu\n",
 		iommu ? " " : " not ");
 
-	arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
+	arch_setup_dma_ops(dev, dma_start, end - dma_start + 1, iommu, coherent);
 
 	if (!iommu)
 		of_dma_set_restricted_buffer(dev, np);
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Wed Dec 13 09:17:56 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 13 Dec 2023 17:17:56 +0000
Subject: [PATCH v2 3/7] ACPI/IORT: Handle memory address size limits as limits
In-Reply-To: <cover.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
Message-ID: <c8a5195e6376ab11d44e867db43e30db866e04a8.1702486837.git.robin.murphy@arm.com>

Return the Root Complex/Named Component memory address size limit as an
inclusive limit value, rather than an exclusive size. This saves having
to fudge an off-by-one for the 64-bit case, and simplifies our caller.

Reviewed-by: Jason Gunthorpe <jgg at nvidia.com>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
v2: Avoid undefined shifts (grr...)
---
 drivers/acpi/arm64/dma.c  |  9 +++------
 drivers/acpi/arm64/iort.c | 20 ++++++++++----------
 include/linux/acpi_iort.h |  4 ++--
 3 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/acpi/arm64/dma.c b/drivers/acpi/arm64/dma.c
index 93d796531af3..b98a149f8d50 100644
--- a/drivers/acpi/arm64/dma.c
+++ b/drivers/acpi/arm64/dma.c
@@ -8,7 +8,6 @@ void acpi_arch_dma_setup(struct device *dev)
 {
 	int ret;
 	u64 end, mask;
-	u64 size = 0;
 	const struct bus_dma_region *map = NULL;
 
 	/*
@@ -23,9 +22,9 @@ void acpi_arch_dma_setup(struct device *dev)
 	}
 
 	if (dev->coherent_dma_mask)
-		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
+		end = dev->coherent_dma_mask;
 	else
-		size = 1ULL << 32;
+		end = (1ULL << 32) - 1;
 
 	ret = acpi_dma_get_range(dev, &map);
 	if (!ret && map) {
@@ -36,18 +35,16 @@ void acpi_arch_dma_setup(struct device *dev)
 				end = r->dma_start + r->size - 1;
 		}
 
-		size = end + 1;
 		dev->dma_range_map = map;
 	}
 
 	if (ret == -ENODEV)
-		ret = iort_dma_get_ranges(dev, &size);
+		ret = iort_dma_get_ranges(dev, &end);
 	if (!ret) {
 		/*
 		 * Limit coherent and dma mask based on size retrieved from
 		 * firmware.
 		 */
-		end = size - 1;
 		mask = DMA_BIT_MASK(ilog2(end) + 1);
 		dev->bus_dma_limit = end;
 		dev->coherent_dma_mask = min(dev->coherent_dma_mask, mask);
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 6496ff5a6ba2..c0b1c2c19444 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1367,7 +1367,7 @@ int iort_iommu_configure_id(struct device *dev, const u32 *input_id)
 { return -ENODEV; }
 #endif
 
-static int nc_dma_get_range(struct device *dev, u64 *size)
+static int nc_dma_get_range(struct device *dev, u64 *limit)
 {
 	struct acpi_iort_node *node;
 	struct acpi_iort_named_component *ncomp;
@@ -1384,13 +1384,13 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
 		return -EINVAL;
 	}
 
-	*size = ncomp->memory_address_limit >= 64 ? U64_MAX :
-			1ULL<<ncomp->memory_address_limit;
+	*limit = ncomp->memory_address_limit >= 64 ? U64_MAX :
+			(1ULL << ncomp->memory_address_limit) - 1;
 
 	return 0;
 }
 
-static int rc_dma_get_range(struct device *dev, u64 *size)
+static int rc_dma_get_range(struct device *dev, u64 *limit)
 {
 	struct acpi_iort_node *node;
 	struct acpi_iort_root_complex *rc;
@@ -1408,8 +1408,8 @@ static int rc_dma_get_range(struct device *dev, u64 *size)
 		return -EINVAL;
 	}
 
-	*size = rc->memory_address_limit >= 64 ? U64_MAX :
-			1ULL<<rc->memory_address_limit;
+	*limit = rc->memory_address_limit >= 64 ? U64_MAX :
+			(1ULL << rc->memory_address_limit) - 1;
 
 	return 0;
 }
@@ -1417,16 +1417,16 @@ static int rc_dma_get_range(struct device *dev, u64 *size)
 /**
  * iort_dma_get_ranges() - Look up DMA addressing limit for the device
  * @dev: device to lookup
- * @size: DMA range size result pointer
+ * @limit: DMA limit result pointer
  *
  * Return: 0 on success, an error otherwise.
  */
-int iort_dma_get_ranges(struct device *dev, u64 *size)
+int iort_dma_get_ranges(struct device *dev, u64 *limit)
 {
 	if (dev_is_pci(dev))
-		return rc_dma_get_range(dev, size);
+		return rc_dma_get_range(dev, limit);
 	else
-		return nc_dma_get_range(dev, size);
+		return nc_dma_get_range(dev, limit);
 }
 
 static void __init acpi_iort_register_irq(int hwirq, const char *name,
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 1cb65592c95d..d4ed5622cf2b 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -39,7 +39,7 @@ void iort_get_rmr_sids(struct fwnode_handle *iommu_fwnode,
 void iort_put_rmr_sids(struct fwnode_handle *iommu_fwnode,
 		       struct list_head *head);
 /* IOMMU interface */
-int iort_dma_get_ranges(struct device *dev, u64 *size);
+int iort_dma_get_ranges(struct device *dev, u64 *limit);
 int iort_iommu_configure_id(struct device *dev, const u32 *id_in);
 void iort_iommu_get_resv_regions(struct device *dev, struct list_head *head);
 phys_addr_t acpi_iort_dma_get_max_cpu_address(void);
@@ -55,7 +55,7 @@ void iort_get_rmr_sids(struct fwnode_handle *iommu_fwnode, struct list_head *hea
 static inline
 void iort_put_rmr_sids(struct fwnode_handle *iommu_fwnode, struct list_head *head) { }
 /* IOMMU interface */
-static inline int iort_dma_get_ranges(struct device *dev, u64 *size)
+static inline int iort_dma_get_ranges(struct device *dev, u64 *limit)
 { return -ENODEV; }
 static inline int iort_iommu_configure_id(struct device *dev, const u32 *id_in)
 { return -ENODEV; }
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Wed Dec 13 09:17:57 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 13 Dec 2023 17:17:57 +0000
Subject: [PATCH v2 4/7] dma-mapping: Add helpers for dma_range_map bounds
In-Reply-To: <cover.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
Message-ID: <16d3e9100cd4a4a397641df963f416cc7f70cc4c.1702486837.git.robin.murphy@arm.com>

Several places want to compute the lower and/or upper bounds of a
dma_range_map, so let's factor that out into reusable helpers.

Reviewed-by: Christoph Hellwig <hch at lst.de>
Reviewed-by: Jason Gunthorpe <jgg at nvidia.com>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
v2: fix warning for 32-bit builds
---
 arch/loongarch/kernel/dma.c |  9 ++-------
 drivers/acpi/arm64/dma.c    |  8 +-------
 drivers/of/device.c         | 11 ++---------
 include/linux/dma-direct.h  | 18 ++++++++++++++++++
 4 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/loongarch/kernel/dma.c b/arch/loongarch/kernel/dma.c
index 7a9c6a9dd2d0..429555fb4e13 100644
--- a/arch/loongarch/kernel/dma.c
+++ b/arch/loongarch/kernel/dma.c
@@ -8,17 +8,12 @@
 void acpi_arch_dma_setup(struct device *dev)
 {
 	int ret;
-	u64 mask, end = 0;
+	u64 mask, end;
 	const struct bus_dma_region *map = NULL;
 
 	ret = acpi_dma_get_range(dev, &map);
 	if (!ret && map) {
-		const struct bus_dma_region *r = map;
-
-		for (end = 0; r->size; r++) {
-			if (r->dma_start + r->size - 1 > end)
-				end = r->dma_start + r->size - 1;
-		}
+		end = dma_range_map_max(map);
 
 		mask = DMA_BIT_MASK(ilog2(end) + 1);
 		dev->bus_dma_limit = end;
diff --git a/drivers/acpi/arm64/dma.c b/drivers/acpi/arm64/dma.c
index b98a149f8d50..52b2abf88689 100644
--- a/drivers/acpi/arm64/dma.c
+++ b/drivers/acpi/arm64/dma.c
@@ -28,13 +28,7 @@ void acpi_arch_dma_setup(struct device *dev)
 
 	ret = acpi_dma_get_range(dev, &map);
 	if (!ret && map) {
-		const struct bus_dma_region *r = map;
-
-		for (end = 0; r->size; r++) {
-			if (r->dma_start + r->size - 1 > end)
-				end = r->dma_start + r->size - 1;
-		}
-
+		end = dma_range_map_max(map);
 		dev->dma_range_map = map;
 	}
 
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 51062a831970..66879edb4a61 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -117,16 +117,9 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
 		if (!force_dma)
 			return ret == -ENODEV ? 0 : ret;
 	} else {
-		const struct bus_dma_region *r = map;
-
 		/* Determine the overall bounds of all DMA regions */
-		for (dma_start = ~0; r->size; r++) {
-			/* Take lower and upper limits */
-			if (r->dma_start < dma_start)
-				dma_start = r->dma_start;
-			if (r->dma_start + r->size > end)
-				end = r->dma_start + r->size;
-		}
+		dma_start = dma_range_map_min(map);
+		end = dma_range_map_max(map);
 	}
 
 	/*
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 3eb3589ff43e..edbe13d00776 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -54,6 +54,24 @@ static inline phys_addr_t translate_dma_to_phys(struct device *dev,
 	return (phys_addr_t)-1;
 }
 
+static inline dma_addr_t dma_range_map_min(const struct bus_dma_region *map)
+{
+	dma_addr_t ret = (dma_addr_t)U64_MAX;
+
+	for (; map->size; map++)
+		ret = min(ret, map->dma_start);
+	return ret;
+}
+
+static inline dma_addr_t dma_range_map_max(const struct bus_dma_region *map)
+{
+	dma_addr_t ret = 0;
+
+	for (; map->size; map++)
+		ret = max(ret, map->dma_start + map->size - 1);
+	return ret;
+}
+
 #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
 #include <asm/dma-direct.h>
 #ifndef phys_to_dma_unencrypted
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Wed Dec 13 09:17:58 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 13 Dec 2023 17:17:58 +0000
Subject: [PATCH v2 5/7] iommu/dma: Make limit checks self-contained
In-Reply-To: <cover.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
Message-ID: <6d1aac26db65bf439f4625986ca76be520774759.1702486837.git.robin.murphy@arm.com>

It's now easy to retrieve the device's DMA limits if we want to check
them against the domain aperture, so do that ourselves instead of
relying on them being passed through the callchain.

Reviewed-by: Jason Gunthorpe <jgg at nvidia.com>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/iommu/dma-iommu.c | 21 +++++++++------------
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5dc012220ca9..27a167f4cd3e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -659,19 +659,16 @@ static void iommu_dma_init_options(struct iommu_dma_options *options,
 /**
  * iommu_dma_init_domain - Initialise a DMA mapping domain
  * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
- * @base: IOVA at which the mappable address space starts
- * @limit: Last address of the IOVA space
  * @dev: Device the domain is being initialised for
  *
- * @base and @limit + 1 should be exact multiples of IOMMU page granularity to
- * avoid rounding surprises. If necessary, we reserve the page at address 0
+ * If the geometry and dma_range_map include address 0, we reserve that page
  * to ensure it is an invalid IOVA. It is safe to reinitialise a domain, but
  * any change which could make prior IOVAs invalid will fail.
  */
-static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
-				 dma_addr_t limit, struct device *dev)
+static int iommu_dma_init_domain(struct iommu_domain *domain, struct device *dev)
 {
 	struct iommu_dma_cookie *cookie = domain->iova_cookie;
+	const struct bus_dma_region *map = dev->dma_range_map;
 	unsigned long order, base_pfn;
 	struct iova_domain *iovad;
 	int ret;
@@ -683,18 +680,18 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
 
 	/* Use the smallest supported page size for IOVA granularity */
 	order = __ffs(domain->pgsize_bitmap);
-	base_pfn = max_t(unsigned long, 1, base >> order);
+	base_pfn = 1;
 
 	/* Check the domain allows at least some access to the device... */
-	if (domain->geometry.force_aperture) {
+	if (map) {
+		dma_addr_t base = dma_range_map_min(map);
 		if (base > domain->geometry.aperture_end ||
-		    limit < domain->geometry.aperture_start) {
+		    dma_range_map_max(map) < domain->geometry.aperture_start) {
 			pr_warn("specified DMA range outside IOMMU capability\n");
 			return -EFAULT;
 		}
 		/* ...then finally give it a kicking to make sure it fits */
-		base_pfn = max_t(unsigned long, base_pfn,
-				domain->geometry.aperture_start >> order);
+		base_pfn = max(base, domain->geometry.aperture_start) >> order;
 	}
 
 	/* start_pfn is always nonzero for an already-initialised domain */
@@ -1743,7 +1740,7 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
 	 * underlying IOMMU driver needs to support via the dma-iommu layer.
 	 */
 	if (iommu_is_dma_domain(domain)) {
-		if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev))
+		if (iommu_dma_init_domain(domain, dev))
 			goto out_err;
 		dev->dma_ops = &iommu_dma_ops;
 	}
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Wed Dec 13 09:17:59 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 13 Dec 2023 17:17:59 +0000
Subject: [PATCH v2 6/7] iommu/dma: Centralise iommu_setup_dma_ops()
In-Reply-To: <cover.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
Message-ID: <5d89190b35720bf5b66621f46b6d3c85323d8eab.1702486837.git.robin.murphy@arm.com>

It's somewhat hard to see, but arm64's arch_setup_dma_ops() should only
ever call iommu_setup_dma_ops() after a successful iommu_probe_device(),
which means there should be no harm in achieving the same orer of
operations by running it off the back of iommu_probe_device() itself.
This then puts it in line with the x86 and s390 .probe_finalize bodges,
letting us pull it all into the main flow properly. As a bonus this lets
us fold in and de-scope the PCI workaround setup as well.

At this point we can also then pull the call inside the group mutex, and
avoid having to think about whether iommu_group_store_type() could
theroetically race and free the domain where iommu_setup_dma_ops() may
currently run just *before* iommu_device_use_default_domain() claims it.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
v2: Shuffle around to make sure the iommu_group_do_probe_finalize() cases
    are covered as well, with bonus side-effects as above.
---
 arch/arm64/mm/dma-mapping.c  |  2 --
 drivers/iommu/amd/iommu.c    |  8 --------
 drivers/iommu/dma-iommu.c    | 18 ++++++------------
 drivers/iommu/dma-iommu.h    | 14 ++++++--------
 drivers/iommu/intel/iommu.c  |  7 -------
 drivers/iommu/iommu.c        |  6 +++---
 drivers/iommu/s390-iommu.c   |  6 ------
 drivers/iommu/virtio-iommu.c | 10 ----------
 include/linux/iommu.h        |  7 -------
 9 files changed, 15 insertions(+), 63 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3cb101e8cb29..96ff791199e8 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -58,8 +58,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 		   ARCH_DMA_MINALIGN, cls);
 
 	dev->dma_coherent = coherent;
-	if (iommu)
-		iommu_setup_dma_ops(dev, dma_base, dma_base + size - 1);
 
 	xen_setup_dma_ops(dev);
 }
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index fcc987f5d4ed..9418808009ba 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1985,13 +1985,6 @@ static struct iommu_device *amd_iommu_probe_device(struct device *dev)
 	return iommu_dev;
 }
 
-static void amd_iommu_probe_finalize(struct device *dev)
-{
-	/* Domains are initialized for this device - have a look what we ended up with */
-	set_dma_ops(dev, NULL);
-	iommu_setup_dma_ops(dev, 0, U64_MAX);
-}
-
 static void amd_iommu_release_device(struct device *dev)
 {
 	struct amd_iommu *iommu;
@@ -2646,7 +2639,6 @@ const struct iommu_ops amd_iommu_ops = {
 	.domain_alloc_user = amd_iommu_domain_alloc_user,
 	.probe_device = amd_iommu_probe_device,
 	.release_device = amd_iommu_release_device,
-	.probe_finalize = amd_iommu_probe_finalize,
 	.device_group = amd_iommu_device_group,
 	.get_resv_regions = amd_iommu_get_resv_regions,
 	.is_attach_deferred = amd_iommu_is_attach_deferred,
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 27a167f4cd3e..d808c8dcf5cb 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1724,25 +1724,20 @@ static const struct dma_map_ops iommu_dma_ops = {
 	.opt_mapping_size	= iommu_dma_opt_mapping_size,
 };
 
-/*
- * The IOMMU core code allocates the default DMA domain, which the underlying
- * IOMMU driver needs to support via the dma-iommu layer.
- */
-void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
+void iommu_setup_dma_ops(struct device *dev)
 {
 	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
 
-	if (!domain)
-		goto out_err;
+	if (dev_is_pci(dev))
+		dev->iommu->pci_32bit_workaround = !iommu_dma_forcedac;
 
-	/*
-	 * The IOMMU core code allocates the default DMA domain, which the
-	 * underlying IOMMU driver needs to support via the dma-iommu layer.
-	 */
 	if (iommu_is_dma_domain(domain)) {
 		if (iommu_dma_init_domain(domain, dev))
 			goto out_err;
 		dev->dma_ops = &iommu_dma_ops;
+	} else if (dev->dma_ops == &iommu_dma_ops) {
+		/* Clean up if we've switched *from* a DMA domain */
+		dev->dma_ops = NULL;
 	}
 
 	return;
@@ -1750,7 +1745,6 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
 	 pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n",
 		 dev_name(dev));
 }
-EXPORT_SYMBOL_GPL(iommu_setup_dma_ops);
 
 static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
 		phys_addr_t msi_addr, struct iommu_domain *domain)
diff --git a/drivers/iommu/dma-iommu.h b/drivers/iommu/dma-iommu.h
index c829f1f82a99..c12d63457c76 100644
--- a/drivers/iommu/dma-iommu.h
+++ b/drivers/iommu/dma-iommu.h
@@ -9,6 +9,8 @@
 
 #ifdef CONFIG_IOMMU_DMA
 
+void iommu_setup_dma_ops(struct device *dev);
+
 int iommu_get_dma_cookie(struct iommu_domain *domain);
 void iommu_put_dma_cookie(struct iommu_domain *domain);
 
@@ -17,13 +19,13 @@ int iommu_dma_init_fq(struct iommu_domain *domain);
 void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
 
 extern bool iommu_dma_forcedac;
-static inline void iommu_dma_set_pci_32bit_workaround(struct device *dev)
-{
-	dev->iommu->pci_32bit_workaround = !iommu_dma_forcedac;
-}
 
 #else /* CONFIG_IOMMU_DMA */
 
+static inline void iommu_setup_dma_ops(struct device *dev)
+{
+}
+
 static inline int iommu_dma_init_fq(struct iommu_domain *domain)
 {
 	return -EINVAL;
@@ -42,9 +44,5 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
 {
 }
 
-static inline void iommu_dma_set_pci_32bit_workaround(struct device *dev)
-{
-}
-
 #endif	/* CONFIG_IOMMU_DMA */
 #endif	/* __DMA_IOMMU_H */
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 3531b956556c..f7347ed41e89 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4480,12 +4480,6 @@ static void intel_iommu_release_device(struct device *dev)
 	set_dma_ops(dev, NULL);
 }
 
-static void intel_iommu_probe_finalize(struct device *dev)
-{
-	set_dma_ops(dev, NULL);
-	iommu_setup_dma_ops(dev, 0, U64_MAX);
-}
-
 static void intel_iommu_get_resv_regions(struct device *device,
 					 struct list_head *head)
 {
@@ -4937,7 +4931,6 @@ const struct iommu_ops intel_iommu_ops = {
 	.domain_alloc		= intel_iommu_domain_alloc,
 	.domain_alloc_user	= intel_iommu_domain_alloc_user,
 	.probe_device		= intel_iommu_probe_device,
-	.probe_finalize		= intel_iommu_probe_finalize,
 	.release_device		= intel_iommu_release_device,
 	.get_resv_regions	= intel_iommu_get_resv_regions,
 	.device_group		= intel_iommu_device_group,
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 824989874dee..43f630d0530e 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -560,10 +560,10 @@ static int __iommu_probe_device(struct device *dev, struct list_head *group_list
 		if (list_empty(&group->entry))
 			list_add_tail(&group->entry, group_list);
 	}
-	mutex_unlock(&group->mutex);
 
-	if (dev_is_pci(dev))
-		iommu_dma_set_pci_32bit_workaround(dev);
+	iommu_setup_dma_ops(dev);
+
+	mutex_unlock(&group->mutex);
 
 	return 0;
 
diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c
index 9a5196f523de..d8eaa7ea380b 100644
--- a/drivers/iommu/s390-iommu.c
+++ b/drivers/iommu/s390-iommu.c
@@ -695,11 +695,6 @@ static size_t s390_iommu_unmap_pages(struct iommu_domain *domain,
 	return size;
 }
 
-static void s390_iommu_probe_finalize(struct device *dev)
-{
-	iommu_setup_dma_ops(dev, 0, U64_MAX);
-}
-
 struct zpci_iommu_ctrs *zpci_get_iommu_ctrs(struct zpci_dev *zdev)
 {
 	if (!zdev || !zdev->s390_domain)
@@ -785,7 +780,6 @@ static const struct iommu_ops s390_iommu_ops = {
 	.capable = s390_iommu_capable,
 	.domain_alloc_paging = s390_domain_alloc_paging,
 	.probe_device = s390_iommu_probe_device,
-	.probe_finalize = s390_iommu_probe_finalize,
 	.release_device = s390_iommu_release_device,
 	.device_group = generic_device_group,
 	.pgsize_bitmap = SZ_4K,
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 9bcffdde6175..5a558456946b 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -998,15 +998,6 @@ static struct iommu_device *viommu_probe_device(struct device *dev)
 	return ERR_PTR(ret);
 }
 
-static void viommu_probe_finalize(struct device *dev)
-{
-#ifndef CONFIG_ARCH_HAS_SETUP_DMA_OPS
-	/* First clear the DMA ops in case we're switching from a DMA domain */
-	set_dma_ops(dev, NULL);
-	iommu_setup_dma_ops(dev, 0, U64_MAX);
-#endif
-}
-
 static void viommu_release_device(struct device *dev)
 {
 	struct viommu_endpoint *vdev = dev_iommu_priv_get(dev);
@@ -1043,7 +1034,6 @@ static struct iommu_ops viommu_ops = {
 	.capable		= viommu_capable,
 	.domain_alloc		= viommu_domain_alloc,
 	.probe_device		= viommu_probe_device,
-	.probe_finalize		= viommu_probe_finalize,
 	.release_device		= viommu_release_device,
 	.device_group		= viommu_device_group,
 	.get_resv_regions	= viommu_get_resv_regions,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 20ed3a4fc5e0..3a3bf8afb8ca 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -1283,9 +1283,6 @@ static inline void iommu_debugfs_setup(void) {}
 #ifdef CONFIG_IOMMU_DMA
 #include <linux/msi.h>
 
-/* Setup call for arch DMA mapping code */
-void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit);
-
 int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
 
 int iommu_dma_prepare_msi(struct msi_desc *desc, phys_addr_t msi_addr);
@@ -1296,10 +1293,6 @@ void iommu_dma_compose_msi_msg(struct msi_desc *desc, struct msi_msg *msg);
 struct msi_desc;
 struct msi_msg;
 
-static inline void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
-{
-}
-
 static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
 {
 	return -ENODEV;
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Wed Dec 13 09:18:00 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 13 Dec 2023 17:18:00 +0000
Subject: [PATCH v2 7/7] dma-mapping: Simplify arch_setup_dma_ops()
In-Reply-To: <cover.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
Message-ID: <7e6af148e0df9a10b51cd60234ec6b35f7d4cc20.1702486837.git.robin.murphy@arm.com>

The dma_base, size and iommu arguments are only used by ARM, and can
now easily be deduced from the device itself, so there's no need to pass
them through the callchain as well.

Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
v2: Make sure the ARM changes actually build (oops...)
---
 arch/arc/mm/dma.c               |  3 +--
 arch/arm/mm/dma-mapping-nommu.c |  3 +--
 arch/arm/mm/dma-mapping.c       | 18 ++++++++++--------
 arch/arm64/mm/dma-mapping.c     |  3 +--
 arch/mips/mm/dma-noncoherent.c  |  3 +--
 arch/riscv/mm/dma-noncoherent.c |  3 +--
 drivers/acpi/scan.c             |  3 +--
 drivers/hv/hv_common.c          |  6 +-----
 drivers/of/device.c             |  4 +---
 include/linux/dma-map-ops.h     |  6 ++----
 10 files changed, 20 insertions(+), 32 deletions(-)

diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 2a7fbbb83b70..6b85e94f3275 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -90,8 +90,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
 /*
  * Plug in direct dma map ops.
  */
-void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-			const struct iommu_ops *iommu, bool coherent)
+void arch_setup_dma_ops(struct device *dev, bool coherent)
 {
 	/*
 	 * IOC hardware snoops all DMA traffic keeping the caches consistent
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index cfd9c933d2f0..97db5397c320 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -33,8 +33,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
 	}
 }
 
-void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-			const struct iommu_ops *iommu, bool coherent)
+void arch_setup_dma_ops(struct device *dev, bool coherent)
 {
 	if (IS_ENABLED(CONFIG_CPU_V7M)) {
 		/*
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 5409225b4abc..5ac482d7ff94 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1712,11 +1712,15 @@ void arm_iommu_detach_device(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(arm_iommu_detach_device);
 
-static void arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size,
-				    const struct iommu_ops *iommu, bool coherent)
+static void arm_setup_iommu_dma_ops(struct device *dev)
 {
 	struct dma_iommu_mapping *mapping;
+	u64 dma_base = 0, size = 1ULL << 32;
 
+	if (dev->dma_range_map) {
+		dma_base = dma_range_map_min(dev->dma_range_map);
+		size = dma_range_map_max(dev->dma_range_map) - dma_base;
+	}
 	mapping = arm_iommu_create_mapping(dev->bus, dma_base, size);
 	if (IS_ERR(mapping)) {
 		pr_warn("Failed to create %llu-byte IOMMU mapping for device %s\n",
@@ -1747,8 +1751,7 @@ static void arm_teardown_iommu_dma_ops(struct device *dev)
 
 #else
 
-static void arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size,
-				    const struct iommu_ops *iommu, bool coherent)
+static void arm_setup_iommu_dma_ops(struct device *dev)
 {
 }
 
@@ -1756,8 +1759,7 @@ static void arm_teardown_iommu_dma_ops(struct device *dev) { }
 
 #endif	/* CONFIG_ARM_DMA_USE_IOMMU */
 
-void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-			const struct iommu_ops *iommu, bool coherent)
+void arch_setup_dma_ops(struct device *dev, bool coherent)
 {
 	/*
 	 * Due to legacy code that sets the ->dma_coherent flag from a bus
@@ -1776,8 +1778,8 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 	if (dev->dma_ops)
 		return;
 
-	if (iommu)
-		arm_setup_iommu_dma_ops(dev, dma_base, size, iommu, coherent);
+	if (device_iommu_mapped(dev))
+		arm_setup_iommu_dma_ops(dev);
 
 	xen_setup_dma_ops(dev);
 	dev->archdata.dma_ops_setup = true;
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 96ff791199e8..0b320a25a471 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -46,8 +46,7 @@ void arch_teardown_dma_ops(struct device *dev)
 }
 #endif
 
-void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-			const struct iommu_ops *iommu, bool coherent)
+void arch_setup_dma_ops(struct device *dev, bool coherent)
 {
 	int cls = cache_line_size_of_cpu();
 
diff --git a/arch/mips/mm/dma-noncoherent.c b/arch/mips/mm/dma-noncoherent.c
index 3c4fc97b9f39..ab4f2a75a7d0 100644
--- a/arch/mips/mm/dma-noncoherent.c
+++ b/arch/mips/mm/dma-noncoherent.c
@@ -137,8 +137,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
 #endif
 
 #ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS
-void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-		const struct iommu_ops *iommu, bool coherent)
+void arch_setup_dma_ops(struct device *dev, bool coherent)
 {
 	dev->dma_coherent = coherent;
 }
diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
index 4e4e469b8dd6..cb89d7e0ba88 100644
--- a/arch/riscv/mm/dma-noncoherent.c
+++ b/arch/riscv/mm/dma-noncoherent.c
@@ -128,8 +128,7 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
 	ALT_CMO_OP(FLUSH, flush_addr, size, riscv_cbom_block_size);
 }
 
-void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-		const struct iommu_ops *iommu, bool coherent)
+void arch_setup_dma_ops(struct device *dev, bool coherent)
 {
 	WARN_TAINT(!coherent && riscv_cbom_block_size > ARCH_DMA_MINALIGN,
 		   TAINT_CPU_OUT_OF_SPEC,
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index ee88a727f200..cad171fc31e8 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1640,8 +1640,7 @@ int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
 	if (PTR_ERR(iommu) == -EPROBE_DEFER)
 		return -EPROBE_DEFER;
 
-	arch_setup_dma_ops(dev, 0, U64_MAX,
-				iommu, attr == DEV_DMA_COHERENT);
+	arch_setup_dma_ops(dev, attr == DEV_DMA_COHERENT);
 
 	return 0;
 }
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 4372f5d146ab..0e2decd1167a 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -484,11 +484,7 @@ EXPORT_SYMBOL_GPL(hv_query_ext_cap);
 
 void hv_setup_dma_ops(struct device *dev, bool coherent)
 {
-	/*
-	 * Hyper-V does not offer a vIOMMU in the guest
-	 * VM, so pass 0/NULL for the IOMMU settings
-	 */
-	arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
+	arch_setup_dma_ops(dev, coherent);
 }
 EXPORT_SYMBOL_GPL(hv_setup_dma_ops);
 
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 66879edb4a61..3394751015d3 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -96,7 +96,6 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
 	const struct iommu_ops *iommu;
 	const struct bus_dma_region *map = NULL;
 	struct device_node *bus_np;
-	u64 dma_start = 0;
 	u64 mask, end = 0;
 	bool coherent;
 	int ret;
@@ -118,7 +117,6 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
 			return ret == -ENODEV ? 0 : ret;
 	} else {
 		/* Determine the overall bounds of all DMA regions */
-		dma_start = dma_range_map_min(map);
 		end = dma_range_map_max(map);
 	}
 
@@ -167,7 +165,7 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
 	dev_dbg(dev, "device is%sbehind an iommu\n",
 		iommu ? " " : " not ");
 
-	arch_setup_dma_ops(dev, dma_start, end - dma_start + 1, iommu, coherent);
+	arch_setup_dma_ops(dev, coherent);
 
 	if (!iommu)
 		of_dma_set_restricted_buffer(dev, np);
diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index a52e508d1869..023f265eae2e 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -426,11 +426,9 @@ bool arch_dma_unmap_sg_direct(struct device *dev, struct scatterlist *sg,
 #endif
 
 #ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS
-void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-		const struct iommu_ops *iommu, bool coherent);
+void arch_setup_dma_ops(struct device *dev, bool coherent);
 #else
-static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base,
-		u64 size, const struct iommu_ops *iommu, bool coherent)
+static inline void arch_setup_dma_ops(struct device *dev, bool coherent)
 {
 }
 #endif /* CONFIG_ARCH_HAS_SETUP_DMA_OPS */
-- 
2.39.2.101.g768bb238c484.dirty



From robh at kernel.org  Wed Dec 13 09:22:17 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 13 Dec 2023 11:22:17 -0600
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <ZXnE3724jYYSg4o6@raptor>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com> <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
 <ZXiMiLz9ZyUdxUP8@raptor> <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
 <ZXmr-Kl9L2SO13--@raptor> <CAL_JsqL=P1Y6w38LD_xw+vK4CNqt22FW_FE9oi_XTLHVQEne7Q@mail.gmail.com>
 <ZXnE3724jYYSg4o6@raptor>
Message-ID: <CAL_JsqJgTnuQjo13cKo1Ebm5j9tCRT8GhNavdqu5vwp+fdnTLw@mail.gmail.com>

On Wed, Dec 13, 2023 at 8:51?AM Alexandru Elisei
<alexandru.elisei at arm.com> wrote:
>
> Hi,
>
> On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> > On Wed, Dec 13, 2023 at 7:05?AM Alexandru Elisei
> > <alexandru.elisei at arm.com> wrote:
> > >
> > > Hi Rob,
> > >
> > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > > On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
> > > > <alexandru.elisei at arm.com> wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > Thank you so much for the feedback, I'm not very familiar with device tree,
> > > > > and any comments are very useful.
> > > > >
> > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > >
> > > > > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > > > >
> > > > > > > The DTB node for the tag storage region is defined as:
> > > > > > >
> > > > > > >         tags0: tag-storage at 8f8000000 {
> > > > > > >                 compatible = "arm,mte-tag-storage";
> > > > > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > > > > >                 block-size = <0x1000>;
> > > > > > >                 memory = <&memory0>;    // Associated tagged memory node
> > > > > > >         };
> > > > > >
> > > > > > I skimmed thru the discussion some. If this memory range is within
> > > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > > >
> > > > > Ok, will do that.
> > > > >
> > > > > If you don't mind, why do you say that it definitely belongs in
> > > > > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > > > > motivation.
> > > >
> > > > Simply so that /memory nodes describe all possible memory and
> > > > /reserved-memory is just adding restrictions. It's also because
> > > > /reserved-memory is what gets handled early, and we don't need
> > > > multiple things to handle early.
> > > >
> > > > > Tag storage is not DMA and can live anywhere in memory.
> > > >
> > > > Then why put it in DT at all? The only reason CMA is there is to set
> > > > the size. It's not even clear to me we need CMA in DT either. The
> > > > reasoning long ago was the kernel didn't do a good job of moving and
> > > > reclaiming contiguous space, but that's supposed to be better now (and
> > > > most h/w figured out they need IOMMUs).
> > > >
> > > > But for tag storage you know the size as it is a function of the
> > > > memory size, right? After all, you are validating the size is correct.
> > > > I guess there is still the aspect of whether you want enable MTE or
> > > > not which could be done in a variety of ways.
> > >
> > > Oh, sorry, my bad, I should have been clearer about this. I don't want to
> > > put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.
> >
> > Yes, I understand, but my point remains. Why do you need this in DT?
> > If the location doesn't matter and you can calculate the size from the
> > memory size, what else is there to add to the DT?
>
> I am afraid there has been a misunderstanding. What do you mean by
> "location doesn't matter"?

You said:
> Tag storage is not DMA and can live anywhere in memory.

Which I took as the kernel can figure out where to put it. But maybe
you meant the h/w platform can hard code it to be anywhere in memory?
If so, then yes, DT is needed.

> At the very least, Linux needs to know the address and size of a memory
> region to use it. The series is about using the tag storage memory for
> data. Tag storage cannot be described as a regular memory node because it
> cannot be tagged (and normal memory can).

If the tag storage lives in the middle of memory, then it would be
described in the memory node, but removed by being in reserved-memory
node.

> Then there's the matter of the tag storage block size (explained in this
> commit message), and also knowing the memory range for which a tag storage
> region stores the tags. This is explained in the cover letter.

Honestly, I just forgot about that part.

Rob


From andriy.shevchenko at intel.com  Wed Dec 13 09:24:02 2023
From: andriy.shevchenko at intel.com (Andy Shevchenko)
Date: Wed, 13 Dec 2023 19:24:02 +0200
Subject: [PATCH v6 01/40] ARM: ep93xx: Add terminator to
 gpiod_lookup_table
In-Reply-To: <20231212-ep93xx-v6-1-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
 <20231212-ep93xx-v6-1-c307b8ac9aa8@maquefel.me>
Message-ID: <ZXnosnuRKFQL5XDo@smile.fi.intel.com>

On Tue, Dec 12, 2023 at 11:20:18AM +0300, Nikita Shubin wrote:
> Without the terminator, if a con_id is passed to gpio_find() that
> does not exist in the lookup table the function will not stop looping
> correctly, and eventually cause an oops.

Reported-by?
Fixes?

-- 
With Best Regards,
Andy Shevchenko




From will at kernel.org  Wed Dec 13 09:25:17 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 17:25:17 +0000
Subject: [PATCH v2 0/5] Convert SMMU to domain_alloc_paging()
In-Reply-To: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
References: <0-v2-c86cc8c2230e+160bb-smmu_newapi_jgg@nvidia.com>
Message-ID: <170247134058.2137421.298272092445922389.b4-ty@kernel.org>

On Tue, 17 Oct 2023 15:11:39 -0300, Jason Gunthorpe wrote:
> Add the global statics for IDENTITY and BLOCKED to the SMMU driver and
> change to use domain_alloc_paging(). This allows SMMU to finalize the
> domain during allocation.
> 
> This relies on the first few patches of the dart conversion series:
> 
> https://lore.kernel.org/r/0-v2-bff223cf6409+282-dart_paging_jgg at nvidia.com
> 
> [...]

Applied to will (for-joerg/arm-smmu/updates), thanks!

[1/5] iommu/arm-smmu: Reorganize arm_smmu_domain_add_master()
      https://git.kernel.org/will/c/ff0f80297413
[2/5] iommu/arm-smmu: Convert to a global static identity domain
      https://git.kernel.org/will/c/22bb7b41476a
[3/5] iommu/arm-smmu: Implement IOMMU_DOMAIN_BLOCKED
      https://git.kernel.org/will/c/bbbf11eea38c
[4/5] iommu/arm-smmu: Pass arm_smmu_domain to internal functions
      https://git.kernel.org/will/c/e0976331ad11
[5/5] iommu/arm-smmu: Convert to domain_alloc_paging()
      https://git.kernel.org/will/c/9b3febc3a3da

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Wed Dec 13 09:25:18 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 17:25:18 +0000
Subject: [PATCH 0/2] arm64: cpucap handling cleanups
In-Reply-To: <20231212170910.3745497-1-mark.rutland@arm.com>
References: <20231212170910.3745497-1-mark.rutland@arm.com>
Message-ID: <170248332281.2991306.7731192579703060918.b4-ty@kernel.org>

On Tue, 12 Dec 2023 17:09:08 +0000, Mark Rutland wrote:
> The recent changes to remove cpus_have_const_cap() left a period between
> detecting cpucaps and patching alternatives where it is necessary to use
> cpus_have_cap() to check that a cpucap has been detected. During this
> period we do a few things, and there's a risk that code using a mixture
> of cpus_have_cap() and alternative_has_cap_*() sees an inconsistent
> state.
> 
> [...]

Applied to arm64 (for-next/cpufeature), thanks!

Basing the series on for-next/fixes makes it fiddly to manage, so I
dropped the kpti_install_ng_mappings() hunk from patch 1 and will
re-introduce it when I merge the branches together.

[1/2] arm64: Cleanup system cpucap handling
      https://git.kernel.org/arm64/c/63a2d92e1461
[2/2] arm64: Align boot cpucap handling with system cpucap handling
      https://git.kernel.org/arm64/c/eb15d707c252

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Wed Dec 13 09:25:19 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 17:25:19 +0000
Subject: [PATCH] arm64: irq: set the correct node for shadow call stack
In-Reply-To: <20231213012046.12014-1-shijie@os.amperecomputing.com>
References: <20231213012046.12014-1-shijie@os.amperecomputing.com>
Message-ID: <170246934075.98561.2845796203103432401.b4-ty@kernel.org>

On Wed, 13 Dec 2023 09:20:46 +0800, Huang Shijie wrote:
> The init_irq_stacks() has been changed to use the correct node:
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf
> 
> The init_irq_scs() has the same issue with init_irq_stacks():
> 	cpu_to_node() is not initialized yet, it does not work.
> 
> This patch uses early_cpu_to_node() to set the init_irq_scs()
> with the correct node.
> 
> [...]

Applied to arm64 (for-next/mm), thanks!

[1/1] arm64: irq: set the correct node for shadow call stack
      https://git.kernel.org/arm64/c/7b1a09e44dc6

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Wed Dec 13 09:25:20 2023
From: will at kernel.org (Will Deacon)
Date: Wed, 13 Dec 2023 17:25:20 +0000
Subject: [PATCH v12 0/5] drivers/perf: add Synopsys DesignWare PCIe PMU driver support
In-Reply-To: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
References: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
Message-ID: <170247454282.4025634.10934949931800191482.b4-ty@kernel.org>

On Fri, 8 Dec 2023 10:56:47 +0800, Shuai Xue wrote:
> Change Log
> ==========
> change sinces v11:
> - Fix uninitialized symbol 'now' (Per Dan and Will)
> - Pick up Reviewed-and-tested-by tag from Ilkka for Patch 4/5
> 
> change sinces v10:
> - Rename to pci_clear_and_set_config_dword() to retain the "config"
>   information and match the other accessors. (Per Bjorn)
> - Align pci_clear_and_set_config_dword() and its call site (Per Bjorn)
> - Polish commit log (Per Bjorn)
> - Simplify dwc_pcie_pmu_time_based_event_enable() with bool value (Per Ilkka)
> - Fix dwc_pcie_register_dev() return value (Per Ilkka)
> - Fix vesc capability discovery by pdev->vendor (Per Ilkka)
> - pick up Acked-by tag from Bjorn for Patch 3/5
> - pick up Tested-by tag from Ilkka for all patch set
> 
> [...]

Applied to will (for-next/perf), thanks!

[1/5] docs: perf: Add description for Synopsys DesignWare PCIe PMU driver
      https://git.kernel.org/will/c/cae40614cdd6
[2/5] PCI: Add Alibaba Vendor ID to linux/pci_ids.h
      https://git.kernel.org/will/c/ad6534c626fe
[3/5] PCI: Move pci_clear_and_set_dword() helper to PCI header
      https://git.kernel.org/will/c/ac16087134b8
[4/5] drivers/perf: add DesignWare PCIe PMU driver
      https://git.kernel.org/will/c/af9597adc2f1
[5/5] MAINTAINERS: add maintainers for DesignWare PCIe PMU driver
      https://git.kernel.org/will/c/f56bb3de66bc

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From irogers at google.com  Wed Dec 13 09:33:24 2023
From: irogers at google.com (Ian Rogers)
Date: Wed, 13 Dec 2023 09:33:24 -0800
Subject: [PATCH V2 3/5] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <20231213133336.GA3895246@leoy-yangtze.lan>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-4-kan.liang@linux.intel.com> <20231209054809.GB2116834@leoy-yangtze.lan>
 <3b67c2de-741d-4d5e-8c8f-87b8b9e08825@linux.intel.com> <20231213133336.GA3895246@leoy-yangtze.lan>
Message-ID: <CAP-5=fVGoQbaUmDqr8CmoRT3Wx=Pp7TtmWuwvXrvEeGw5eannA@mail.gmail.com>

On Wed, Dec 13, 2023 at 5:33?AM Leo Yan <leo.yan at linaro.org> wrote:
>
> On Mon, Dec 11, 2023 at 01:39:36PM -0500, Liang, Kan wrote:
> > On 2023-12-09 12:48 a.m., Leo Yan wrote:
> > > On Thu, Dec 07, 2023 at 11:23:36AM -0800, kan.liang at linux.intel.com wrote:
> > >> From: Kan Liang <kan.liang at linux.intel.com>
> > >>
> > >> Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
> > >> one.
> > >
> > > Now memory event naming is arch dependent, this is because every arch
> > > has different memory PMU names, and it appends specific configurations
> > > (e.g. aarch64 appends 'ts_enable=1,...,min_latency=%u', and x86_64
> > > appends 'ldlat=%u', etc).  This is not friendly for extension, e.g. it's
> > > impossible for users to specify any extra attributes for memory events.
> > >
> > > This patch tries to consolidate in a central place for generating memory
> > > event names, its approach is to add more flags to meet special usage
> > > cases, which means the code gets more complex (and more difficult for
> > > later's maintenance).
> > >
> > > I think we need to distinguish the event naming into two levels: in
> > > util/mem-events.c, we can consider it as a common layer, and we maintain
> > > common options in it, e.g. 'latency', 'all-user', 'all-kernel',
> > > 'timestamp', 'physical_address', etc.  In every arch's mem-events.c
> > > file, it converts the common options to arch specific configurations.
> > >
> > > In the end, this can avoid to add more and more flags into the
> > > structure perf_mem_event.
> >
> > The purpose of this cleanup patch set is to remove the unnecessary
> > __weak functions, and try to make the code more generic.
>
> I understand weak functions are not very good practice.  The point is
> weak functions are used for some archs have implemented a feature but
> other archs have not.
>
> I can think a potential case to use a central place to maintain the
> code for all archs - when we want to support cross analysis.  But this
> patch series is for supporting cross analysis, to be honest, I still
> don't see benefit for this series, though I know you might try to
> support hybrid modes.

So thanks to Kan for doing this series and trying to clean the code
up. My complaint about the code is that it was overly hard wired.
Heck, we have event strings to parse that hard code PMU and event
names. In fixing hybrid my complaint was that we were adding yet more
complexity and as a lot of this was resting on printf format strings
it was hard to check that these were being used correctly. The
direction of this patch series I agree with.

Imo we should avoid weak definitions. Weak definitions are outside of
the C specification and have introduced bugs into the code base -
specifically a weak const array was having its size propagated into
code but then the linker later replaced that weak array. An
architecture #ifdef is better than a weak definition as the behavior
is defined and things blow up early rather than suffering from subtle
corruptions.

The Linux kernel device driver is abstracting what the hardware is
doing and since the more recent changes the PMU abstraction in the
perf tool is trying to match that. If we need to interface with PMUs
differently on each architecture then something is wrong. It happens
that things are wrong and we need to work with that. For example, on
intel there are topdown events that introduce ordering issues. We have
default initialization functions for different PMUs. The perf_pmu
struct is created in perf_pmu__lookup and that always calls an
perf_pmu__arch_init where the name of the PMU is already set. In the
weak perf_pmu__arch_init we tweak the perf_pmu struct so that it will
behave correctly elsewhere in the code. These changes are paralleling
that. That said, the Intel perf_pmu__arch_init does strcmps against
"intel_pt" and "intel_bts", does it really need to be arch specific
given it is already PMU specific? A situation we see in testing is
people trying to run user space ISA emulators like qemu, say ARM on
x86, should the PMU set up for intel_pt and intel_bts be broken in
this environment? I think that as the names are very specific I'd
prefer if the code were outside of the tools/perf/arch directory.
There are cases with PMU names like "cpu" where we're probably going
to need ifdefs or runtime is_intel() calls.

Anyway, my point is that I think we should be moving away from arch
specific stuff, as this patch series tries, and that way we have the
best chance of changes benefitting users regardless of hardware. It
may be that to make all of this work properly we need to modify PMUs,
but that all seems good, such as adding the extended type support for
legacy events on ARM PMUs so that legacy events can work without a
fixed CPU. We haven't got core PMUs working properly, see the recent
perf top hybrid problem. There are obviously issues with uncore as,
for example, most memory controllers are replicated PMUs but some
kernel perf drivers select a memory controller via a config value. We
either need to change the drivers for some kind of uniformity or do
some kind of abstracting in the perf tool. I think we'll probably need
to do it in the tool and when doing that we really shouldn't be doing
it in an arch specific or weak function way.

Thanks,
Ian

> > The two flags has already covered all the current usage.
> > For now, it's good enough.
> >
> > I agree that if there are more flags, it should not be a perfect
> > solution. But we don't have the third flag right now. Could we clean up
> > it later e.g., when introducing the third flag?
> >
> > I just don't want to make the patch bigger and bigger. Also, I don't
> > think we usually implement something just for future possibilities.
>
> Fine for me, but please address two main concerns in next spin:
>
> - Fix building failure in patch 01;
> - Fix the concerned regression on Arm64/AMD archs in patch 04.  I will
>   give a bit more explanation in another reply.
>
>
> [...]
>
> > >> -#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
> > >> +#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
> > >>
> > >>  struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
> > >> -  E("spe-load",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",       "arm_spe_0"),
> > >> -  E("spe-store",  "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                      "arm_spe_0"),
> > >> -  E("spe-ldst",   "arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",       "arm_spe_0"),
> > >> +  E("spe-load",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",      "arm_spe_0",    true,   0),
> > >> +  E("spe-store",  "%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",                     "arm_spe_0",    false,  0),
> > >> +  E("spe-ldst",   "%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",      "arm_spe_0",    true,   0),
> > >
> > > Arm SPE is AUX event, should set '1' to the field '.aux_event'.
> >
> > It actually means whether an extra event is required with a mem_loads
> > event.  I guess for ARM the answer is no.
>
> Thanks for confirmation.
>
> > > I am a bit suspect if we really need the field '.aux_event', the
> > > '.aux_event' field is only used for generating event string.
> >
> > No, it stores the event encoding for the extra event.
> > ARM doesn't need it, so it's 0.
>
> I searched a bit and confirmed '.aux_event' is only used in
> util/mem-events.c and for 'perf record'.
>
> I failed to connect the code with "it stores the event encoding for the
> extra event".  Could you elaborate a bit for this?
>
> Thanks,
> Leo


From mark.rutland at arm.com  Wed Dec 13 09:39:24 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 13 Dec 2023 17:39:24 +0000
Subject: [PATCH 0/2] arm64: cpucap handling cleanups
In-Reply-To: <170248332281.2991306.7731192579703060918.b4-ty@kernel.org>
References: <20231212170910.3745497-1-mark.rutland@arm.com>
 <170248332281.2991306.7731192579703060918.b4-ty@kernel.org>
Message-ID: <ZXnsTHbRxe7b7YNL@FVFF77S0Q05N>

On Wed, Dec 13, 2023 at 05:25:18PM +0000, Will Deacon wrote:
> On Tue, 12 Dec 2023 17:09:08 +0000, Mark Rutland wrote:
> > The recent changes to remove cpus_have_const_cap() left a period between
> > detecting cpucaps and patching alternatives where it is necessary to use
> > cpus_have_cap() to check that a cpucap has been detected. During this
> > period we do a few things, and there's a risk that code using a mixture
> > of cpus_have_cap() and alternative_has_cap_*() sees an inconsistent
> > state.
> > 
> > [...]
> 
> Applied to arm64 (for-next/cpufeature), thanks!
> 
> Basing the series on for-next/fixes makes it fiddly to manage, so I
> dropped the kpti_install_ng_mappings() hunk from patch 1 and will
> re-introduce it when I merge the branches together.

Thanks, and sorry for the hassle!

The changes and resolution in that branch look good to me (and build and boot
cleanly); I'll go throw that on my test system and see if anything blows up
overnight.

Mark.

> [1/2] arm64: Cleanup system cpucap handling
>       https://git.kernel.org/arm64/c/63a2d92e1461
> [2/2] arm64: Align boot cpucap handling with system cpucap handling
>       https://git.kernel.org/arm64/c/eb15d707c252
> 
> Cheers,
> -- 
> Will
> 
> https://fixes.arm64.dev
> https://next.arm64.dev
> https://will.arm64.dev


From alexandru.elisei at arm.com  Wed Dec 13 09:44:37 2023
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed, 13 Dec 2023 17:44:37 +0000
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <CAL_JsqJgTnuQjo13cKo1Ebm5j9tCRT8GhNavdqu5vwp+fdnTLw@mail.gmail.com>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com>
 <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
 <ZXiMiLz9ZyUdxUP8@raptor>
 <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
 <ZXmr-Kl9L2SO13--@raptor>
 <CAL_JsqL=P1Y6w38LD_xw+vK4CNqt22FW_FE9oi_XTLHVQEne7Q@mail.gmail.com>
 <ZXnE3724jYYSg4o6@raptor>
 <CAL_JsqJgTnuQjo13cKo1Ebm5j9tCRT8GhNavdqu5vwp+fdnTLw@mail.gmail.com>
Message-ID: <ZXnthcg0BkEd-RgK@raptor>

On Wed, Dec 13, 2023 at 11:22:17AM -0600, Rob Herring wrote:
> On Wed, Dec 13, 2023 at 8:51?AM Alexandru Elisei
> <alexandru.elisei at arm.com> wrote:
> >
> > Hi,
> >
> > On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> > > On Wed, Dec 13, 2023 at 7:05?AM Alexandru Elisei
> > > <alexandru.elisei at arm.com> wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > > > On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
> > > > > <alexandru.elisei at arm.com> wrote:
> > > > > >
> > > > > > Hi Rob,
> > > > > >
> > > > > > Thank you so much for the feedback, I'm not very familiar with device tree,
> > > > > > and any comments are very useful.
> > > > > >
> > > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > > > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > > >
> > > > > > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > > > > >
> > > > > > > > The DTB node for the tag storage region is defined as:
> > > > > > > >
> > > > > > > >         tags0: tag-storage at 8f8000000 {
> > > > > > > >                 compatible = "arm,mte-tag-storage";
> > > > > > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > > > > > >                 block-size = <0x1000>;
> > > > > > > >                 memory = <&memory0>;    // Associated tagged memory node
> > > > > > > >         };
> > > > > > >
> > > > > > > I skimmed thru the discussion some. If this memory range is within
> > > > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > > > >
> > > > > > Ok, will do that.
> > > > > >
> > > > > > If you don't mind, why do you say that it definitely belongs in
> > > > > > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > > > > > motivation.
> > > > >
> > > > > Simply so that /memory nodes describe all possible memory and
> > > > > /reserved-memory is just adding restrictions. It's also because
> > > > > /reserved-memory is what gets handled early, and we don't need
> > > > > multiple things to handle early.
> > > > >
> > > > > > Tag storage is not DMA and can live anywhere in memory.
> > > > >
> > > > > Then why put it in DT at all? The only reason CMA is there is to set
> > > > > the size. It's not even clear to me we need CMA in DT either. The
> > > > > reasoning long ago was the kernel didn't do a good job of moving and
> > > > > reclaiming contiguous space, but that's supposed to be better now (and
> > > > > most h/w figured out they need IOMMUs).
> > > > >
> > > > > But for tag storage you know the size as it is a function of the
> > > > > memory size, right? After all, you are validating the size is correct.
> > > > > I guess there is still the aspect of whether you want enable MTE or
> > > > > not which could be done in a variety of ways.
> > > >
> > > > Oh, sorry, my bad, I should have been clearer about this. I don't want to
> > > > put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.
> > >
> > > Yes, I understand, but my point remains. Why do you need this in DT?
> > > If the location doesn't matter and you can calculate the size from the
> > > memory size, what else is there to add to the DT?
> >
> > I am afraid there has been a misunderstanding. What do you mean by
> > "location doesn't matter"?
> 
> You said:
> > Tag storage is not DMA and can live anywhere in memory.
> 
> Which I took as the kernel can figure out where to put it. But maybe
> you meant the h/w platform can hard code it to be anywhere in memory?
> If so, then yes, DT is needed.

Ah, I see, sorry for not being clear enough, you are correct: tag storage
is a hardware property, and software needs a mechanism (in this case, the
dt) to discover its properties.

> 
> > At the very least, Linux needs to know the address and size of a memory
> > region to use it. The series is about using the tag storage memory for
> > data. Tag storage cannot be described as a regular memory node because it
> > cannot be tagged (and normal memory can).
> 
> If the tag storage lives in the middle of memory, then it would be
> described in the memory node, but removed by being in reserved-memory
> node.

I don't follow. Would you mind going into more details?

> 
> > Then there's the matter of the tag storage block size (explained in this
> > commit message), and also knowing the memory range for which a tag storage
> > region stores the tags. This is explained in the cover letter.
> 
> Honestly, I just forgot about that part.

I totally understand, there are a lot of things to consider at the same
time.

Thanks,
Alex


From robh at kernel.org  Wed Dec 13 09:53:30 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 13 Dec 2023 11:53:30 -0600
Subject: [PATCH v6 0/4] Add displays support for bsh-smm-s2/pro boards
In-Reply-To: <20231213140437.2769508-1-dario.binacchi@amarulasolutions.com>
References: <20231213140437.2769508-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231213175330.GA1582432-robh@kernel.org>

On Wed, Dec 13, 2023 at 03:03:41PM +0100, Dario Binacchi wrote:
> The series adds drivers for the displays used by bsh-smm-s2/pro boards.
> This required applying some patches to the samsung-dsim driver.
> 
> Changes in v6:
> - Drop patches:
>   - [06/10] drm/panel: Add Synaptics R63353 panel driver

The binding should have gone with this. I'll apply it then.

Rob


From markhas at chromium.org  Wed Dec 13 10:00:20 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Wed, 13 Dec 2023 11:00:20 -0700
Subject: [PATCH v1 2/6] arm: arm64: dts: Enable cros-ec-spi as wake source
In-Reply-To: <20231213110009.v1.1.Ifd0903f1c351e84376d71dbdadbd43931197f5ea@changeid>
References: <20231213110009.v1.1.Ifd0903f1c351e84376d71dbdadbd43931197f5ea@changeid>
Message-ID: <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to match expected behavior.

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

 arch/arm/boot/dts/nvidia/tegra124-nyan.dtsi              | 1 +
 arch/arm/boot/dts/nvidia/tegra124-venice2.dts            | 1 +
 arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi | 1 +
 arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts       | 1 +
 arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts        | 1 +
 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi             | 1 +
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi           | 1 +
 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi         | 1 +
 arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi         | 1 +
 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi          | 1 +
 arch/arm64/boot/dts/nvidia/tegra132-norrin.dts           | 1 +
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi             | 1 +
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi           | 1 +
 arch/arm64/boot/dts/qcom/sc7280-idp-ec-h1.dtsi           | 1 +
 arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi               | 1 +
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi             | 1 +
 16 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/nvidia/tegra124-nyan.dtsi b/arch/arm/boot/dts/nvidia/tegra124-nyan.dtsi
index a2ee371802004..8125c1b3e8d79 100644
--- a/arch/arm/boot/dts/nvidia/tegra124-nyan.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra124-nyan.dtsi
@@ -338,6 +338,7 @@ cros_ec: cros-ec at 0 {
 			interrupt-parent = <&gpio>;
 			interrupts = <TEGRA_GPIO(C, 7) IRQ_TYPE_LEVEL_LOW>;
 			reg = <0>;
+			wakeup-source;
 
 			google,cros-ec-spi-msg-delay = <2000>;
 
diff --git a/arch/arm/boot/dts/nvidia/tegra124-venice2.dts b/arch/arm/boot/dts/nvidia/tegra124-venice2.dts
index 3924ee385dee0..df98dc2a67b85 100644
--- a/arch/arm/boot/dts/nvidia/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/nvidia/tegra124-venice2.dts
@@ -857,6 +857,7 @@ cros_ec: cros-ec at 0 {
 			interrupt-parent = <&gpio>;
 			interrupts = <TEGRA_GPIO(C, 7) IRQ_TYPE_LEVEL_LOW>;
 			reg = <0>;
+			wakeup-source;
 
 			google,cros-ec-spi-msg-delay = <2000>;
 
diff --git a/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi
index 092316be67f74..1554fe36e60fe 100644
--- a/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi
@@ -112,6 +112,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_int>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
diff --git a/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts b/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts
index 4e757b6e28e1c..3759742d38cac 100644
--- a/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts
@@ -967,6 +967,7 @@ cros_ec: cros-ec at 0 {
 		reg = <0>;
 		spi-max-frequency = <3125000>;
 		google,has-vbc-nvram;
+		wakeup-source;
 
 		controller-data {
 			samsung,spi-feedback-delay = <1>;
diff --git a/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts b/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts
index f91bc4ae008e4..9bbbdce9103a6 100644
--- a/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts
@@ -949,6 +949,7 @@ cros_ec: cros-ec at 0 {
 		reg = <0>;
 		spi-max-frequency = <3125000>;
 		google,has-vbc-nvram;
+		wakeup-source;
 
 		controller-data {
 			samsung,spi-feedback-delay = <1>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index 4dd21dd317026..f0395da659a86 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -1168,6 +1168,7 @@ cros_ec: ec at 0 {
 		interrupt-parent = <&pio>;
 		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
 		google,cros-ec-spi-msg-delay = <500>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel0 {
 			compatible = "google,cros-ec-i2c-tunnel";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index 44647d462e20b..359859f23b1fd 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -1013,6 +1013,7 @@ cros_ec: cros-ec at 0 {
 		interrupts = <151 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_ap_int_odl>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
index 5f62dc83013f0..74c534d475cb0 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
@@ -1918,6 +1918,7 @@ cros_ec: ec at 0 {
 		interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_ap_int>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
index a29da53d17894..4594287d60926 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
@@ -1454,6 +1454,7 @@ cros_ec: ec at 0 {
 		spi-max-frequency = <3000000>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&cros_ec_int>;
+		wakeup-source;
 
 		#address-cells = <1>;
 		#size-cells = <0>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index 37a3e9de90ff7..a5ace1b02c3d2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -1034,6 +1034,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&cros_ec_int>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		keyboard-backlight {
 			compatible = "google,cros-kbd-led-backlight";
diff --git a/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts b/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
index bbc2e9bef08da..14d58859bb55c 100644
--- a/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
@@ -762,6 +762,7 @@ ec: cros-ec at 0 {
 			interrupt-parent = <&gpio>;
 			interrupts = <TEGRA_GPIO(C, 7) IRQ_TYPE_LEVEL_LOW>;
 			reg = <0>;
+			wakeup-source;
 
 			google,cros-ec-spi-msg-delay = <2000>;
 
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 5a33e16a8b677..e6a2ed0463997 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -650,6 +650,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ap_ec_int_l>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		cros_ec_pwm: pwm {
 			compatible = "google,cros-ec-pwm";
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 9ea6636125ad9..2ba4ea60cb147 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -548,6 +548,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ap_ec_int_l>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		cros_ec_pwm: pwm {
 			compatible = "google,cros-ec-pwm";
diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp-ec-h1.dtsi b/arch/arm64/boot/dts/qcom/sc7280-idp-ec-h1.dtsi
index ebae545c587c4..fbfac7534d3c6 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-idp-ec-h1.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-idp-ec-h1.dtsi
@@ -19,6 +19,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ap_ec_int_l>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		cros_ec_pwm: pwm {
 			compatible = "google,cros-ec-pwm";
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index f86e7acdfd99f..d8eb45662c931 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -838,6 +838,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_ap_int_l>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		cros_ec_pwm: pwm {
 			compatible = "google,cros-ec-pwm";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index c9bf1d5c3a426..69a0b34f0615b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -602,6 +602,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_ap_int_l>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
-- 
2.43.0.472.g3155946c3a-goog



From krzysztof.kozlowski at linaro.org  Wed Dec 13 10:08:02 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 19:08:02 +0100
Subject: [PATCH v1 2/6] arm: arm64: dts: Enable cros-ec-spi as wake source
In-Reply-To: <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid>
References: <20231213110009.v1.1.Ifd0903f1c351e84376d71dbdadbd43931197f5ea@changeid>
 <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid>
Message-ID: <ab3c00da-5dec-4274-a9ef-2ac0fef6efee@linaro.org>

On 13/12/2023 19:00, Mark Hasemeyer wrote:
> The cros_ec driver currently assumes that cros-ec-spi compatible device
> nodes are a wakeup-source even though the wakeup-source property is not
> defined.
> 
> Add the wakeup-source property to all cros-ec-spi compatible device
> nodes to match expected behavior.
> 
> Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
> ---
> 

I did not get any other patches in the set, so no clue what's there...
but for this patch: please split per subarch. At least Samsung bits.

Best regards,
Krzysztof



From andriy.shevchenko at linux.intel.com  Wed Dec 13 10:16:26 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Wed, 13 Dec 2023 20:16:26 +0200
Subject: [PATCH v6 36/40] ata: pata_ep93xx: remove legacy pinctrl use
In-Reply-To: <20231212-ep93xx-v6-36-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
 <20231212-ep93xx-v6-36-c307b8ac9aa8@maquefel.me>
Message-ID: <ZXn0-pHxIztvRFLK@smile.fi.intel.com>

On Tue, Dec 12, 2023 at 11:20:53AM +0300, Nikita Shubin wrote:
> Drop legacy acquire/release since we are using pinctrl for this now.

...

> -	if (IS_ERR(drv_data->dma_rx_channel)) {
> +	if (PTR_ERR_OR_ZERO(drv_data->dma_rx_channel)) {

This seems incorrect.

>  		ret = PTR_ERR(drv_data->dma_rx_channel);
>  		return dev_err_probe(dev, ret, "rx DMA setup failed");

		return dev_err_probe(...);

>  	}

I think you wanted

	ret = PTR_ERR_OR_ZERO(drv_data->dma_rx_channel);
	if (ret)
		return dev_err_probe(dev, ret, "rx DMA setup failed");

...

>  	drv_data->dma_tx_channel = dma_request_chan(&pdev->dev, "tx");
> -	if (IS_ERR(drv_data->dma_tx_channel)) {
> +	if (PTR_ERR_OR_ZERO(drv_data->dma_tx_channel)) {
>  		ret = PTR_ERR(drv_data->dma_tx_channel);
>  		dev_err_probe(dev, ret, "tx DMA setup failed");
>  		goto fail_release_rx;

Ditto.

-- 
With Best Regards,
Andy Shevchenko




From jarkko at kernel.org  Wed Dec 13 10:18:35 2023
From: jarkko at kernel.org (Jarkko Sakkinen)
Date: Wed, 13 Dec 2023 20:18:35 +0200
Subject: [PATCH v1 1/8] dt-bindings: arm: aspeed: add IBM system1-bmc
In-Reply-To: <20231212164004.1683589-2-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-2-ninad@linux.ibm.com>
Message-ID: <CXNEVH8BZUJT.1UHVUI66SZMTE@suppilovahvero>

On Tue Dec 12, 2023 at 6:39 PM EET, Ninad Palsule wrote:
> Document the new compatibles used on IBM system1-bmc
>
> Tested:

this not very useful line :-) (nit)

>     This board is tested using the simics simulator.

Just leave this (w/o indentation)

>
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---
>  Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
>  Documentation/devicetree/bindings/trivial-devices.yaml   | 2 ++
>  2 files changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
> index 6f7543463d89..ebebe14c42aa 100644
> --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
> +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
> @@ -85,6 +85,7 @@ properties:
>                - facebook,yosemite4-bmc
>                - ibm,everest-bmc
>                - ibm,rainier-bmc
> +              - ibm,system1-bmc
>                - ibm,tacoma-bmc
>                - inventec,starscream-bmc
>                - inventec,transformer-bmc
> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> index 441b55723675..b12a60d2eb0f 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> @@ -135,6 +135,8 @@ properties:
>            - ibm,cffps1
>              # IBM Common Form Factor Power Supply Versions 2
>            - ibm,cffps2
> +            # Infineon barometric pressure and temperature sensor
> +          - infineon,dps310
>              # Infineon IR36021 digital POL buck controller
>            - infineon,ir36021
>              # Infineon IR38060 Voltage Regulator

BR, Jarkko


From jarkko at kernel.org  Wed Dec 13 10:20:20 2023
From: jarkko at kernel.org (Jarkko Sakkinen)
Date: Wed, 13 Dec 2023 20:20:20 +0200
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <20231212164004.1683589-3-ninad@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-3-ninad@linux.ibm.com>
Message-ID: <CXNEWTC7G66C.8KM5X4BWMK7P@suppilovahvero>

On Tue Dec 12, 2023 at 6:39 PM EET, Ninad Palsule wrote:
> From: Johannes Holland <johannes.holland at infineon.com>
>
> Add a dt schema to support device tree bindings for the generic I2C
> physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
> Specification for TPM 2.0 v1.04 Revision 14.
>
> This includes descriptions for the Nuvoton and Infineon devices.
>
> OpenBMC-Staging-Count: 3

Please don't invent your own tags.

> Signed-off-by: Johannes Holland <johannes.holland at infineon.com>
> Signed-off-by: Joel Stanley <joel at jms.id.au>
> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> ---
>  .../bindings/security/tpm/tpm-tis-i2c.yaml    | 50 +++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>
> diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> new file mode 100644
> index 000000000000..de1e34065748
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: I2C PTP based TPM Devices
> +
> +maintainers:
> +  - Johannes Holland <johannes.holland at infineon.com>
> +
> +description:
> +  Device Tree Bindings for I2C based Trusted Platform Module (TPM).
> +
> +properties:
> +  $nodename:
> +    pattern: "^tpm(@[0-9a-f]+)?$"
> +
> +  compatible:
> +    oneOf:
> +      - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
> +        items:
> +          - const: infineon,slb9673
> +          - const: tcg,tpm-tis-i2c
> +      - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
> +        items:
> +          - const: nuvoton,npct75x
> +          - const: tcg,tpm-tis-i2c
> +      - const: tcg,tpm-tis-i2c
> +  reg:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    i2c {
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      tpm at 2e {
> +        compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
> +        reg = <0x2e>;
> +      };
> +    };
> +...


BR, Jarkko


From u.kleine-koenig at pengutronix.de  Wed Dec 13 10:33:49 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 13 Dec 2023 19:33:49 +0100
Subject: [PATCH v6 36/40] ata: pata_ep93xx: remove legacy pinctrl use
In-Reply-To: <ZXn0-pHxIztvRFLK@smile.fi.intel.com>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
 <20231212-ep93xx-v6-36-c307b8ac9aa8@maquefel.me>
 <ZXn0-pHxIztvRFLK@smile.fi.intel.com>
Message-ID: <20231213183349.hdjoxxszrrc4hqrg@pengutronix.de>

On Wed, Dec 13, 2023 at 08:16:26PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 12, 2023 at 11:20:53AM +0300, Nikita Shubin wrote:
> > Drop legacy acquire/release since we are using pinctrl for this now.
> 
> ...
> 
> > -	if (IS_ERR(drv_data->dma_rx_channel)) {
> > +	if (PTR_ERR_OR_ZERO(drv_data->dma_rx_channel)) {
> 
> This seems incorrect.
> 
> >  		ret = PTR_ERR(drv_data->dma_rx_channel);
> >  		return dev_err_probe(dev, ret, "rx DMA setup failed");
> 
> 		return dev_err_probe(...);
> 
> >  	}
> 
> I think you wanted
> 
> 	ret = PTR_ERR_OR_ZERO(drv_data->dma_rx_channel);
> 	if (ret)
> 		return dev_err_probe(dev, ret, "rx DMA setup failed");

How is that different from

	if (IS_ERR(drv_data->dma_rx_channel))
		return dev_err_probe(dev, PTR_ERR(drv_data->dma_rx_channel), "....");

(which seems to be more idiomatic to me)? While I was involved in
creating PTR_ERR_OR_ZERO, I don't particularily like it (today).

Also note that you want a \n at the end of error messages.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/fdb75ca4/attachment-0001.sig>

From skinsburskii at linux.microsoft.com  Wed Dec 13 10:36:14 2023
From: skinsburskii at linux.microsoft.com (Stanislav Kinsburskii)
Date: Wed, 13 Dec 2023 10:36:14 -0800
Subject: [PATCH 03/15] kexec: Add Kexec HandOver (KHO) generation helpers
In-Reply-To: <20231213000452.88295-4-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
 <20231213000452.88295-4-graf@amazon.com>
Message-ID: <20231213183614.GA14669@skinsburskii.>

On Wed, Dec 13, 2023 at 12:04:40AM +0000, Alexander Graf wrote:
> +int register_kho_notifier(struct notifier_block *nb)
> +{
> +	return blocking_notifier_chain_register(&kho.chain_head, nb);
> +}
> +EXPORT_SYMBOL_GPL(register_kho_notifier);
> +
> +int unregister_kho_notifier(struct notifier_block *nb)
> +{
> +	return blocking_notifier_chain_unregister(&kho.chain_head, nb);
> +}
> +EXPORT_SYMBOL_GPL(unregister_kho_notifier);
> +
> +bool kho_is_active(void)
> +{
> +	return kho.active;
> +}
> +EXPORT_SYMBOL_GPL(kho_is_active);
> +

Why should these helpers be restricted to GPL code?



From dario.binacchi at amarulasolutions.com  Wed Dec 13 10:37:09 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Wed, 13 Dec 2023 19:37:09 +0100
Subject: [PATCH v7 0/3] Add displays support for bsh-smm-s2/pro boards
Message-ID: <20231213183737.4182996-1-dario.binacchi@amarulasolutions.com>

The series adds drivers for the displays used by bsh-smm-s2/pro boards.
This required applying some patches to the samsung-dsim driver and the
drm_bridge.c module.

Changes in v7:
- Drop [3/4] dt-bindings: display: panel: Add synaptics r63353 panel controller
  because applied.

Changes in v6:
- Drop patches:
  - [06/10] drm/panel: Add Synaptics R63353 panel driver
  - [07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  - [08/10] drm/panel: Add Ilitek ILI9805 panel driver
  - [09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  Because applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)
  Drop patches:
  - [01/10] drm/bridge: Fix bridge disable logic
  - [02/10] drm/bridge: Fix a use case in the bridge disable logic
  Because they are wrong

Changes in v3:
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Dario Binacchi (2):
  drm: bridge: samsung-dsim: enter display mode in the enable() callback
  drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Michael Trimarchi (1):
  arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup

 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++++++++++++++
 drivers/gpu/drm/bridge/samsung-dsim.c         |  14 +-
 3 files changed, 133 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi

-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Wed Dec 13 10:37:12 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Wed, 13 Dec 2023 19:37:12 +0100
Subject: [PATCH v7 3/3] arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup
In-Reply-To: <20231213183737.4182996-1-dario.binacchi@amarulasolutions.com>
References: <20231213183737.4182996-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231213183737.4182996-4-dario.binacchi@amarulasolutions.com>

From: Michael Trimarchi <michael at amarulasolutions.com>

Add the display and nodes required for its operation.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>

---

Changes in v7:
- Drop [3/4] dt-bindings: display: panel: Add synaptics r63353 panel controller
  because applied.

Changes in v6:
- Drop patches:
  - [06/10] drm/panel: Add Synaptics R63353 panel driver
  - [07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  - [08/10] drm/panel: Add Ilitek ILI9805 panel driver
  - [09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  Because applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)
  Drop patches:
  - [01/10] drm/bridge: Fix bridge disable logic
  - [02/10] drm/bridge: Fix a use case in the bridge disable logic
  Because they are wrong

Changes in v3:
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++++++++++++++
 2 files changed, 122 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
index 22a754d438f1..bbb07c650da9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
@@ -7,6 +7,7 @@
 /dts-v1/;
 
 #include "imx8mn.dtsi"
+#include "imx8mn-bsh-smm-s2-display.dtsi"
 
 / {
 	chosen {
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
new file mode 100644
index 000000000000..f0a924cbe548
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 BSH
+ */
+
+/ {
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm1 0 700000 0>;	/* 700000 ns = 1337Hz */
+		brightness-levels = <0 100>;
+		num-interpolated-steps = <100>;
+		default-brightness-level = <50>;
+		status = "okay";
+	};
+
+	reg_3v3_dvdd: regulator-3v3-O3 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_dvdd>;
+		regulator-name = "3v3-dvdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
+	};
+
+	reg_v3v3_avdd: regulator-3v3-O2 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_avdd>;
+		regulator-name = "3v3-avdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 5 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pwm1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_bl>;
+};
+
+&lcdif {
+	status = "okay";
+	assigned-clocks = <&clk IMX8MN_VIDEO_PLL1>;
+	assigned-clock-rates = <594000000>;
+};
+
+&pgc_dispmix {
+	assigned-clocks = <&clk IMX8MN_CLK_DISP_AXI>, <&clk IMX8MN_CLK_DISP_APB>;
+	assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_1000M>, <&clk IMX8MN_SYS_PLL1_800M>;
+	assigned-clock-rates = <500000000>, <200000000>;
+};
+
+&mipi_dsi {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+	samsung,esc-clock-frequency = <20000000>;
+	samsung,pll-clock-frequency = <12000000>;
+
+	panel at 0 {
+		compatible = "sharp,ls068b3sx02", "syna,r63353";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel>;
+		reg = <0>;
+
+		backlight = <&backlight>;
+		dvdd-supply = <&reg_3v3_dvdd>;
+		avdd-supply = <&reg_v3v3_avdd>;
+		reset-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+
+		port {
+			panel_in: endpoint {
+				remote-endpoint = <&mipi_dsi_out>;
+			};
+		};
+
+	};
+
+	ports {
+		port at 1 {
+			reg = <1>;
+			mipi_dsi_out: endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+	};
+};
+
+&gpu {
+	status = "okay";
+};
+
+&iomuxc {
+
+	/* This is for both PWM and voltage regulators for display */
+	pinctrl_bl: pwm1grp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO01_PWM1_OUT	0x16
+		>;
+	};
+
+	pinctrl_panel: panelgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_SAI3_RXC_GPIO4_IO29	0x16	/* panel reset */
+		>;
+	};
+
+	pinctrl_dvdd: dvddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x16	/* VDD 3V3_VO3 */
+		>;
+	};
+
+	pinctrl_avdd: avddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO05_GPIO1_IO5	0x16	/* VDD 3V3_VO2 */
+		>;
+	};
+};
-- 
2.43.0



From ninad at linux.ibm.com  Wed Dec 13 10:36:48 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Wed, 13 Dec 2023 12:36:48 -0600
Subject: [PATCH v1 1/8] dt-bindings: arm: aspeed: add IBM system1-bmc
In-Reply-To: <CXNEVH8BZUJT.1UHVUI66SZMTE@suppilovahvero>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-2-ninad@linux.ibm.com>
 <CXNEVH8BZUJT.1UHVUI66SZMTE@suppilovahvero>
Message-ID: <6e1a7f5d-c15f-4938-893b-0aa77ef9fcfc@linux.ibm.com>

Hello Jarkko,

On 12/13/23 12:18, Jarkko Sakkinen wrote:
> On Tue Dec 12, 2023 at 6:39 PM EET, Ninad Palsule wrote:
>> Document the new compatibles used on IBM system1-bmc
>>
>> Tested:
> this not very useful line :-) (nit)
>
>>      This board is tested using the simics simulator.
> Just leave this (w/o indentation)

Based on Conor's suggestion, I have removed both lines.

Thanks for the review.

Thanks & Regards,

Ninad

>
>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>> ---
>>   Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
>>   Documentation/devicetree/bindings/trivial-devices.yaml   | 2 ++
>>   2 files changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
>> index 6f7543463d89..ebebe14c42aa 100644
>> --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
>> +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
>> @@ -85,6 +85,7 @@ properties:
>>                 - facebook,yosemite4-bmc
>>                 - ibm,everest-bmc
>>                 - ibm,rainier-bmc
>> +              - ibm,system1-bmc
>>                 - ibm,tacoma-bmc
>>                 - inventec,starscream-bmc
>>                 - inventec,transformer-bmc
>> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
>> index 441b55723675..b12a60d2eb0f 100644
>> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
>> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
>> @@ -135,6 +135,8 @@ properties:
>>             - ibm,cffps1
>>               # IBM Common Form Factor Power Supply Versions 2
>>             - ibm,cffps2
>> +            # Infineon barometric pressure and temperature sensor
>> +          - infineon,dps310
>>               # Infineon IR36021 digital POL buck controller
>>             - infineon,ir36021
>>               # Infineon IR38060 Voltage Regulator
> BR, Jarkko


From ninad at linux.ibm.com  Wed Dec 13 10:38:22 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Wed, 13 Dec 2023 12:38:22 -0600
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <CXNEWTC7G66C.8KM5X4BWMK7P@suppilovahvero>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-3-ninad@linux.ibm.com>
 <CXNEWTC7G66C.8KM5X4BWMK7P@suppilovahvero>
Message-ID: <719949a9-ddd5-451f-a765-d875cea85ba5@linux.ibm.com>

Hello Jarkko,

On 12/13/23 12:20, Jarkko Sakkinen wrote:
> On Tue Dec 12, 2023 at 6:39 PM EET, Ninad Palsule wrote:
>> From: Johannes Holland <johannes.holland at infineon.com>
>>
>> Add a dt schema to support device tree bindings for the generic I2C
>> physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
>> Specification for TPM 2.0 v1.04 Revision 14.
>>
>> This includes descriptions for the Nuvoton and Infineon devices.
>>
>> OpenBMC-Staging-Count: 3
> Please don't invent your own tags.

Yes, Sorry. I have cherry-picked this commit from openbmc. Now I have 
removed this line.

Thanks for the review.

Thanks & Regards,

Ninad

>
>> Signed-off-by: Johannes Holland <johannes.holland at infineon.com>
>> Signed-off-by: Joel Stanley <joel at jms.id.au>
>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>> ---
>>   .../bindings/security/tpm/tpm-tis-i2c.yaml    | 50 +++++++++++++++++++
>>   1 file changed, 50 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>> new file mode 100644
>> index 000000000000..de1e34065748
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>> @@ -0,0 +1,50 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: I2C PTP based TPM Devices
>> +
>> +maintainers:
>> +  - Johannes Holland <johannes.holland at infineon.com>
>> +
>> +description:
>> +  Device Tree Bindings for I2C based Trusted Platform Module (TPM).
>> +
>> +properties:
>> +  $nodename:
>> +    pattern: "^tpm(@[0-9a-f]+)?$"
>> +
>> +  compatible:
>> +    oneOf:
>> +      - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
>> +        items:
>> +          - const: infineon,slb9673
>> +          - const: tcg,tpm-tis-i2c
>> +      - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
>> +        items:
>> +          - const: nuvoton,npct75x
>> +          - const: tcg,tpm-tis-i2c
>> +      - const: tcg,tpm-tis-i2c
>> +  reg:
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    i2c {
>> +      #address-cells = <1>;
>> +      #size-cells = <0>;
>> +
>> +      tpm at 2e {
>> +        compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
>> +        reg = <0x2e>;
>> +      };
>> +    };
>> +...
>
> BR, Jarkko


From andriy.shevchenko at linux.intel.com  Wed Dec 13 10:41:49 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Wed, 13 Dec 2023 20:41:49 +0200
Subject: [PATCH v6 24/40] input: keypad: ep93xx: add DT support for
 Cirrus EP93xx
In-Reply-To: <20231212-ep93xx-v6-24-c307b8ac9aa8@maquefel.me>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
 <20231212-ep93xx-v6-24-c307b8ac9aa8@maquefel.me>
Message-ID: <ZXn67cynJdto4lAb@smile.fi.intel.com>

On Tue, Dec 12, 2023 at 11:20:41AM +0300, Nikita Shubin wrote:
> - drop flags, they were not used anyway
> - add OF ID match table
> - process "autorepeat", "debounce-delay-ms", prescale from device tree
> - drop platform data usage and it's header
> - keymap goes from device tree now on

...

>  static void ep93xx_keypad_config(struct ep93xx_keypad *keypad)
>  {
>  	unsigned int val = 0;
>  
> +	val |= ((keypad->debounce << KEY_INIT_DBNC_SHIFT) & KEY_INIT_DBNC_MASK);

Since you are touching these lines (see below) you can drop unneeded outer
parentheses.

>  
> +	val |= ((keypad->prescale << KEY_INIT_PRSCL_SHIFT) & KEY_INIT_PRSCL_MASK);

See above.

>  	__raw_writel(val, keypad->mmio_base + KEY_INIT);
>  }

-- 
With Best Regards,
Andy Shevchenko




From andriy.shevchenko at linux.intel.com  Wed Dec 13 10:48:55 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Wed, 13 Dec 2023 20:48:55 +0200
Subject: [PATCH v6 36/40] ata: pata_ep93xx: remove legacy pinctrl use
In-Reply-To: <20231213183349.hdjoxxszrrc4hqrg@pengutronix.de>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
 <20231212-ep93xx-v6-36-c307b8ac9aa8@maquefel.me>
 <ZXn0-pHxIztvRFLK@smile.fi.intel.com>
 <20231213183349.hdjoxxszrrc4hqrg@pengutronix.de>
Message-ID: <ZXn8lzb953iDiM_m@smile.fi.intel.com>

On Wed, Dec 13, 2023 at 07:33:49PM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Dec 13, 2023 at 08:16:26PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 12, 2023 at 11:20:53AM +0300, Nikita Shubin wrote:
> > > Drop legacy acquire/release since we are using pinctrl for this now.

...

> > > -	if (IS_ERR(drv_data->dma_rx_channel)) {
> > > +	if (PTR_ERR_OR_ZERO(drv_data->dma_rx_channel)) {
> > 
> > This seems incorrect.
> > 
> > >  		ret = PTR_ERR(drv_data->dma_rx_channel);
> > >  		return dev_err_probe(dev, ret, "rx DMA setup failed");
> > 
> > 		return dev_err_probe(...);
> > 
> > >  	}
> > 
> > I think you wanted
> > 
> > 	ret = PTR_ERR_OR_ZERO(drv_data->dma_rx_channel);
> > 	if (ret)
> > 		return dev_err_probe(dev, ret, "rx DMA setup failed");
> 
> How is that different from
> 
> 	if (IS_ERR(drv_data->dma_rx_channel))
> 		return dev_err_probe(dev, PTR_ERR(drv_data->dma_rx_channel), "....");
> 
> (which seems to be more idiomatic to me)? While I was involved in
> creating PTR_ERR_OR_ZERO, I don't particularily like it (today).

Makes lines shorter, either works for me.

> Also note that you want a \n at the end of error messages.

Indeed.

-- 
With Best Regards,
Andy Shevchenko




From skinsburskii at linux.microsoft.com  Wed Dec 13 10:56:31 2023
From: skinsburskii at linux.microsoft.com (Stanislav Kinsburskii)
Date: Wed, 13 Dec 2023 10:56:31 -0800
Subject: [PATCH 04/15] kexec: Add KHO parsing support
In-Reply-To: <20231213000452.88295-5-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
 <20231213000452.88295-5-graf@amazon.com>
Message-ID: <20231213185631.GA14708@skinsburskii.>

On Wed, Dec 13, 2023 at 12:04:41AM +0000, Alexander Graf wrote:
> +void *kho_get_fdt(void)
> +{
> +	return fdt;
> +}
> +EXPORT_SYMBOL_GPL(kho_get_fdt);
> +

Same question here (and in other places of this code): shouldn't this
facility be provided to non-GPL drivers as well?

Also a minor nit: "const void *" looks like a cleaner prototype here.



From miguel.ojeda.sandonis at gmail.com  Wed Dec 13 11:00:44 2023
From: miguel.ojeda.sandonis at gmail.com (Miguel Ojeda)
Date: Wed, 13 Dec 2023 20:00:44 +0100
Subject: [PATCH v4 2/2] arm64: rust: Enable Rust support for AArch64
In-Reply-To: <CAGSQo01pOixiPXkW867h4vPUaAjtKtHGKhkV-rpifJvKxAf4Ww@mail.gmail.com>
References: <20231020155056.3495121-1-Jamie.Cunliffe@arm.com>
 <20231020155056.3495121-3-Jamie.Cunliffe@arm.com> <CAGSQo01pOixiPXkW867h4vPUaAjtKtHGKhkV-rpifJvKxAf4Ww@mail.gmail.com>
Message-ID: <CANiq72kNBm1woJAy+64rLqSWjhp16BD6=Uw5Ah0qNH=NAcnY2w@mail.gmail.com>

On Tue, Oct 31, 2023 at 7:31?PM Matthew Maurer <mmaurer at google.com> wrote:
>
> If we really do want to go ahead with using targets directly form
> rustc, this patch should add `--sysroot=/dev/null` or a similar
> override to `rustc_library_cmd` and `rust_common_cmd` to prevent rustc
> from picking up any already installed sysroot libraries.

For reference, Matthew sent the patch to do this at
https://lore.kernel.org/rust-for-linux/20231031201752.1189213-1-mmaurer at google.com/
and I have picked it up in `rust-next` (with a couple extra changes
noted in that thread), so this should be OK.

When this series also arrives in `-next` I will be testing the
combination further just in case.

Cheers,
Miguel


From kw at linux.com  Wed Dec 13 11:05:58 2023
From: kw at linux.com (Krzysztof =?utf-8?Q?Wilczy=C5=84ski?=)
Date: Thu, 14 Dec 2023 04:05:58 +0900
Subject: [PATCH v13 0/5] PCI: add 4x lane support for pci-j721e
 controllers
In-Reply-To: <20231128054402.2155183-1-s-vadapalli@ti.com>
References: <20231128054402.2155183-1-s-vadapalli@ti.com>
Message-ID: <20231213190558.GA988516@rocinante>

Hello,

> This series adds support to the pci-j721e PCIe controller for up to 4x Lane
> configuration supported by TI's J784S4 SoC. Bindings are also added for
> the num-lanes property which shall be used by the driver. The compatible
> for J784S4 SoC is added.
> 
> This series is based on linux-next tagged next-20231128.

Applied to controller/cadence, thank you!

[01/05] dt-bindings: PCI: ti,j721e-pci-*: Add checks for num-lanes
        https://git.kernel.org/pci/pci/c/b3ba0f6e82cb
[02/05] dt-bindings: PCI: ti,j721e-pci-*: Add j784s4-pci-* compatible strings
        https://git.kernel.org/pci/pci/c/adc14d44d7cb
[03/05] PCI: j721e: Add per platform maximum lane settings
        https://git.kernel.org/pci/pci/c/3ac7f14084f5
[04/05] PCI: j721e: Add PCIe 4x lane selection support
        https://git.kernel.org/pci/pci/c/4490f559f755
[05/05] PCI: j721e: Add j784s4 PCIe configuration
        https://git.kernel.org/pci/pci/c/9ca59b45ecf3

	Krzysztof


From ninad at linux.ibm.com  Wed Dec 13 11:02:06 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Wed, 13 Dec 2023 13:02:06 -0600
Subject: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
In-Reply-To: <5b98538a-8ffe-42ec-b020-514dcfcebba3@linaro.org>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-9-ninad@linux.ibm.com>
 <5b98538a-8ffe-42ec-b020-514dcfcebba3@linaro.org>
Message-ID: <44abff4a-0a8e-499b-8b98-a4a1680cb431@linux.ibm.com>

Hello Krzysztof,

On 12/12/23 14:26, Krzysztof Kozlowski wrote:
> On 12/12/2023 17:40, Ninad Palsule wrote:
>> This drop adds following devices in the device tree.
>> - EEPROM/VPD
>> - Power supplies
>> - Humidity, pressure and temperature sensors.
>> - Trusted platform module(TPM) chip
>>
>> Tested:
>>      This board is tested using the simics simulator.
>>
>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>> ---
> Don't mix DTS with drivers. DTS and drivers go via different subsystems
> and cannot have dependencies, so why DTS is patch #6, then driver #7 and
> now again DTS #7?

There is a dependency on driver code as patch #8 uses the compatibility 
string added in driver patch #7.? I have now moved driver patch at the 
start. Is that ok? OR you are suggesting something else?

v1-0001-tpm-tis-i2c-Add-more-compatible-strings.patch
 ??? ??? ??? ??? ??? ??? |
v1-0009-ARM-dts-aspeed-System1-PS-sensor-and-more.patch

>
>>   .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 76 +++++++++++++++++++
>>   1 file changed, 76 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> index 75562aa63701..d960b938fe8d 100644
>> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> @@ -461,6 +461,11 @@ &kcs3 {
>>   &i2c0 {
>>   	status = "okay";
>>   
>> +	eeprom at 50 {
>> +		compatible = "atmel,24c64";
>> +		reg = <0x50>;
>> +	};
>> +
>>   	regulator at 60 {
>>   		compatible = "maxim,max8952";
>>   		reg = <0x60>;
>> @@ -655,6 +660,25 @@ pca0: pca9539 at 74 {
>>   
>>   &i2c2 {
>>   	status = "okay";
>> +
>> +	power-supply at 58 {
>> +		compatible = "ibm,cffps";
>> +		reg = <0x58>;
>> +	};
>> +
>> +	power-supply at 59 {
>> +		compatible = "ibm,cffps";
>> +		reg = <0x59>;
>> +	};
>> +
>> +	power-supply at 5a {
>> +		compatible = "ibm,cffps";
>> +		reg = <0x5a>;
>> +	};
> Missing blank line

Fixed it.

Thanks for the review.

Regards,

Ninad

>
>> +	power-supply at 5b {
>> +		compatible = "ibm,cffps";
>> +		reg = <0x5b>;
>> +	};
>
> Best regards,
> Krzysztof
>


From peter.griffin at linaro.org  Wed Dec 13 11:13:30 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Wed, 13 Dec 2023 19:13:30 +0000
Subject: [PATCH v7 11/16] watchdog: s3c2410_wdt: Update QUIRK macros to
 use BIT macro
In-Reply-To: <017401da2de2$400ec6e0$c02c54a0$@samsung.com>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <CGME20231211162434epcas5p485e7b2edbb02a1b6ea04ff5cc758f5db@epcas5p4.samsung.com>
 <20231211162331.435900-12-peter.griffin@linaro.org> <017401da2de2$400ec6e0$c02c54a0$@samsung.com>
Message-ID: <CADrjBPoFu8azjZ65RGqae6HSCCoHQuhcBHNO_Fo0nVsE9pYGaA@mail.gmail.com>

Hi Alim,

Thanks for your reviews.

On Wed, 13 Dec 2023 at 16:34, Alim Akhtar <alim.akhtar at samsung.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Peter Griffin <peter.griffin at linaro.org>
> > Sent: Monday, December 11, 2023 9:53 PM
> > To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> > mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
> > tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
> > wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
> > will at kernel.org; arnd at arndb.de; olof at lixom.net;
> > gregkh at linuxfoundation.org; jirislaby at kernel.org;
> > cw00.choi at samsung.com; alim.akhtar at samsung.com
> > Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
> > andre.draszik at linaro.org; semen.protsenko at linaro.org;
> > saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
> > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> > samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
> > gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
> > team at android.com; linux-serial at vger.kernel.org
> > Subject: [PATCH v7 11/16] watchdog: s3c2410_wdt: Update QUIRK macros to
> > use BIT macro
> >
> > Update the remaining QUIRK macros to use the BIT macro.
> >
> Ah! I see you have change use BIT here, so you can squash this patch to
> patch 10/16 or
> Move BIT change from patch 10/16 to this patch. Either way is fine.

I actually kept them separate deliberately to avoid conflating adding
of the DBGACK quirk with cleanup of the driver to use BIT macro.

As such one patch adds the QUIRK and only updates the macros that were
touched by that patch (to avoid the --strict warnings), and the second
patch cleans up the rest of the macros to use BIT macro for
consistency.

regards,

Peter


From kw at linux.com  Wed Dec 13 11:13:58 2023
From: kw at linux.com (Krzysztof =?utf-8?Q?Wilczy=C5=84ski?=)
Date: Thu, 14 Dec 2023 04:13:58 +0900
Subject: [PATCH v13 0/5] PCI: add 4x lane support for pci-j721e
 controllers
In-Reply-To: <isttx4vp7warwowlz46oo7y2zex7xuizfvovfse3yb4ww72e6u@nuev2jbkhnhw>
References: <20231128054402.2155183-1-s-vadapalli@ti.com>
 <isttx4vp7warwowlz46oo7y2zex7xuizfvovfse3yb4ww72e6u@nuev2jbkhnhw>
Message-ID: <20231213191358.GB988516@rocinante>

Hi Maxime,

> > This series adds support to the pci-j721e PCIe controller for up to 4x Lane
> > configuration supported by TI's J784S4 SoC. Bindings are also added for
> > the num-lanes property which shall be used by the driver. The compatible
> > for J784S4 SoC is added.
> > 
> > This series is based on linux-next tagged next-20231128.
> 
> These patches have been floating around for a long time (v12 was almost
> identical and was submitted back in April, without any review back then
> already [1]), and it looks like reviewers are happy with it.

Having a glance, it looks good to me, too.

> Could you merge them to get them in 6.8?


Applied, so it should make it to 6.8.  Apologies for the delay.

	Krzysztof


From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:14:28 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:14:28 +0100
Subject: [PATCH v7 12/16] watchdog: s3c2410_wdt: Add support for Google
 gs101 SoC
In-Reply-To: <017501da2de3$4fad8950$ef089bf0$@samsung.com>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <CGME20231211162436epcas5p4161dfb5a2b849edc6856662e5b42693d@epcas5p4.samsung.com>
 <20231211162331.435900-13-peter.griffin@linaro.org>
 <017501da2de3$4fad8950$ef089bf0$@samsung.com>
Message-ID: <631e30a2-bad1-47ba-8daf-4dbb91e2b629@linaro.org>

On 13/12/2023 17:42, Alim Akhtar wrote:
>>  static const struct of_device_id s3c2410_wdt_match[] = {
>> +	{ .compatible = "google,gs101-wdt",
>> +	  .data = &drv_data_gs101_cl0 },
>>  	{ .compatible = "samsung,s3c2410-wdt",
>>  	  .data = &drv_data_s3c2410 },
>>  	{ .compatible = "samsung,s3c6410-wdt", @@ -605,9 +640,10 @@
>> s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct
>> s3c2410_wdt *wdt)
>>  	}
>>
>>  #ifdef CONFIG_OF
>> -	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index
>> */
>> +	/* Choose Exynos9 SoC family driver data w.r.t. cluster index */
> Exynos9 introduction is out of context here, so you can leave it as original
> comment, it is not adding anything here.

Dropped that hunk and applied.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:16:16 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:16:16 +0100
Subject: (subset) [PATCH v7 02/16] dt-bindings: arm: google: Add
 bindings for Google ARM platforms
In-Reply-To: <20231211162331.435900-3-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-3-peter.griffin@linaro.org>
Message-ID: <170249497603.308886.8052027202781573184.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:17 +0000, Peter Griffin wrote:
> This introduces bindings and dt-schema for the Google Tensor SoCs.
> Currently just gs101 and pixel 6 are supported.
> 
> 

Applied, thanks!

[02/16] dt-bindings: arm: google: Add bindings for Google ARM platforms
        https://git.kernel.org/krzk/linux/c/b3582328b9c52f179de7fdd7694c42548d416e39

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:16:18 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:16:18 +0100
Subject: (subset) [PATCH v7 10/16] watchdog: s3c2410_wdt: Add support
 for WTCON register DBGACK_MASK bit
In-Reply-To: <20231211162331.435900-11-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-11-peter.griffin@linaro.org>
Message-ID: <170249497853.308886.14491280069451216694.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:25 +0000, Peter Griffin wrote:
> The WDT uses the CPU core signal DBGACK to determine whether the SoC
> is running in debug mode or not. If the DBGACK signal is asserted and
> DBGACK_MASK bit is enabled, then WDT output and interrupt is masked
> (disabled).
> 
> Presence of the DBGACK_MASK bit is determined by adding a new
> QUIRK_HAS_DBGACK_BIT quirk. Also update to use BIT macro to avoid
> checkpatch --strict warnings.
> 
> [...]

Applied, thanks!

[10/16] watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bit
        https://git.kernel.org/krzk/linux/c/6584cd34901056bc12e015781e4adf03b44ba485

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:16:20 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:16:20 +0100
Subject: (subset) [PATCH v7 11/16] watchdog: s3c2410_wdt: Update QUIRK
 macros to use BIT macro
In-Reply-To: <20231211162331.435900-12-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-12-peter.griffin@linaro.org>
Message-ID: <170249498093.308886.1000238484233229719.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:26 +0000, Peter Griffin wrote:
> Update the remaining QUIRK macros to use the BIT macro.
> 
> 

Applied, thanks!

[11/16] watchdog: s3c2410_wdt: Update QUIRK macros to use BIT macro
        https://git.kernel.org/krzk/linux/c/d429928dde2d7e3e98cbea5f170d089d10a45c39

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:16:23 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:16:23 +0100
Subject: (subset) [PATCH v7 12/16] watchdog: s3c2410_wdt: Add support
 for Google gs101 SoC
In-Reply-To: <20231211162331.435900-13-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-13-peter.griffin@linaro.org>
Message-ID: <170249498306.308886.7093117515363733145.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:27 +0000, Peter Griffin wrote:
> This patch adds the compatibles and drvdata for the Google
> gs101 SoC found in Pixel 6, Pixel 6a & Pixel 6 pro phones.
> 
> Similar to Exynos850 it has two watchdog instances, one for
> each cluster and has some control bits in PMU registers.
> 
> gs101 also has the dbgack_mask bit in wtcon register, so
> we also enable QUIRK_HAS_DBGACK_BIT.
> 
> [...]

Applied, thanks!

[12/16] watchdog: s3c2410_wdt: Add support for Google gs101 SoC
        https://git.kernel.org/krzk/linux/c/796bb2d3a16c1e786ed51183162783405b5c8f85

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:16:25 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:16:25 +0100
Subject: (subset) [PATCH v7 14/16] arm64: dts: exynos: google: Add
 initial Google gs101 SoC support
In-Reply-To: <20231211162331.435900-15-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-15-peter.griffin@linaro.org>
Message-ID: <170249498523.308886.9560205658028235022.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:29 +0000, Peter Griffin wrote:
> Google gs101 SoC is a ARMv8 mobile SoC found in the Pixel 6
> (oriole), Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
> phones.
> 
> It features:
> * 4xA55 Little cluster
> * 2xA76 Mid cluster
> * 2xX1 Big cluster
> 
> [...]

Applied, thanks!

[14/16] arm64: dts: exynos: google: Add initial Google gs101 SoC support
        https://git.kernel.org/krzk/linux/c/ea89fdf24fd94cd37a7e2c51e09c39423ced7ccb

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:16:27 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:16:27 +0100
Subject: (subset) [PATCH v7 15/16] arm64: dts: exynos: google: Add
 initial Oriole/pixel 6 board support
In-Reply-To: <20231211162331.435900-16-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-16-peter.griffin@linaro.org>
Message-ID: <170249498744.308886.17508790332822828341.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:30 +0000, Peter Griffin wrote:
> Add initial board support for the Pixel 6 phone code named Oriole. This
> has been tested with a minimal busybox initramfs and boots to a shell.
> 
> 

Applied, thanks!

[15/16] arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
        https://git.kernel.org/krzk/linux/c/6a5713fc7853c3998c706cb809c5d9fd1c6acaa5

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:16:29 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:16:29 +0100
Subject: (subset) [PATCH v7 16/16] MAINTAINERS: add entry for Google
 Tensor SoC
In-Reply-To: <20231211162331.435900-17-peter.griffin@linaro.org>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <20231211162331.435900-17-peter.griffin@linaro.org>
Message-ID: <170249498967.308886.12609033691141279701.b4-ty@linaro.org>


On Mon, 11 Dec 2023 16:23:31 +0000, Peter Griffin wrote:
> Add maintainers entry for the Google tensor SoC based
> platforms.
> 
> 

Applied, thanks!

[16/16] MAINTAINERS: add entry for Google Tensor SoC
        https://git.kernel.org/krzk/linux/c/9d71df3e6eb773f23d6f1f3f8790bae6aba1a088

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:19:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:19:08 +0100
Subject: [PATCH v7 11/16] watchdog: s3c2410_wdt: Update QUIRK macros to
 use BIT macro
In-Reply-To: <CADrjBPoFu8azjZ65RGqae6HSCCoHQuhcBHNO_Fo0nVsE9pYGaA@mail.gmail.com>
References: <20231211162331.435900-1-peter.griffin@linaro.org>
 <CGME20231211162434epcas5p485e7b2edbb02a1b6ea04ff5cc758f5db@epcas5p4.samsung.com>
 <20231211162331.435900-12-peter.griffin@linaro.org>
 <017401da2de2$400ec6e0$c02c54a0$@samsung.com>
 <CADrjBPoFu8azjZ65RGqae6HSCCoHQuhcBHNO_Fo0nVsE9pYGaA@mail.gmail.com>
Message-ID: <8099aabc-a98e-444b-862f-72845e03476d@linaro.org>

On 13/12/2023 20:13, Peter Griffin wrote:
> Hi Alim,
> 
> Thanks for your reviews.
> 
> On Wed, 13 Dec 2023 at 16:34, Alim Akhtar <alim.akhtar at samsung.com> wrote:
>>
>>
>>
>>> -----Original Message-----
>>> From: Peter Griffin <peter.griffin at linaro.org>
>>> Sent: Monday, December 11, 2023 9:53 PM
>>> To: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
>>> mturquette at baylibre.com; conor+dt at kernel.org; sboyd at kernel.org;
>>> tomasz.figa at gmail.com; s.nawrocki at samsung.com; linus.walleij at linaro.org;
>>> wim at linux-watchdog.org; linux at roeck-us.net; catalin.marinas at arm.com;
>>> will at kernel.org; arnd at arndb.de; olof at lixom.net;
>>> gregkh at linuxfoundation.org; jirislaby at kernel.org;
>>> cw00.choi at samsung.com; alim.akhtar at samsung.com
>>> Cc: peter.griffin at linaro.org; tudor.ambarus at linaro.org;
>>> andre.draszik at linaro.org; semen.protsenko at linaro.org;
>>> saravanak at google.com; willmcvicker at google.com; soc at kernel.org;
>>> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>>> samsung-soc at vger.kernel.org; linux-clk at vger.kernel.org; linux-
>>> gpio at vger.kernel.org; linux-watchdog at vger.kernel.org; kernel-
>>> team at android.com; linux-serial at vger.kernel.org
>>> Subject: [PATCH v7 11/16] watchdog: s3c2410_wdt: Update QUIRK macros to
>>> use BIT macro
>>>
>>> Update the remaining QUIRK macros to use the BIT macro.
>>>
>> Ah! I see you have change use BIT here, so you can squash this patch to
>> patch 10/16 or
>> Move BIT change from patch 10/16 to this patch. Either way is fine.
> 
> I actually kept them separate deliberately to avoid conflating adding
> of the DBGACK quirk with cleanup of the driver to use BIT macro.
> 
> As such one patch adds the QUIRK and only updates the macros that were
> touched by that patch (to avoid the --strict warnings), and the second
> patch cleans up the rest of the macros to use BIT macro for
> consistency.

Yeah, the defines are from existing code, so not really related to GS101
patch. Keeping it as separate cleanup is fine.

Best regards,
Krzysztof



From jernej.skrabec at gmail.com  Wed Dec 13 11:22:55 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 13 Dec 2023 20:22:55 +0100
Subject: [PATCH 3/3] arm64: dts: allwinner: h618: add Transpeed 8K618-T TV box
In-Reply-To: <20231212010859.11571-4-andre.przywara@arm.com>
References: <20231212010859.11571-1-andre.przywara@arm.com>
 <20231212010859.11571-4-andre.przywara@arm.com>
Message-ID: <4533903.LvFx2qVVIh@archlinux>

Hi Andre!

On Tuesday, December 12, 2023 2:08:59 AM CET Andre Przywara wrote:
> This is a Chinese TV box, probably very similar if not identical to
> various other cheap TV boxes with the same specs:
>       - Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache)
>       - 2 or 4GiB DDR3L DRAM
>       - 32, 64, or 128 GiB eMMC flash
>       - AXP313a PMIC
>       - 100 Mbit/s Ethernet (using yet unsupported internal PHY)
>       - HDMI port
>       - 2 * USB 2.0 ports
>       - microSD card slot
>       - 3.5mm A/V port
>       - 7-segment display
>       - 5V barrel plug power supply
> 
> The PCB provides holes for soldering a UART header or cable, this is
> connected to the debug UART0. UART1 is used for the Bluetooth chip,
> although this isn't working yet.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>  .../sun50i-h618-transpeed-8k618-t.dts         | 164 ++++++++++++++++++
>  2 files changed, 165 insertions(+)
>  create mode 100644
> arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile index 3aca6787a1679..91d505b385de5
> 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -43,3 +43,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero3.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-transpeed-8k618-t.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts new file
> mode 100644
> index 0000000000000..fd7ea7bcde2c1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2023 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	model = "Transpeed 8K618-T";
> +	compatible = "transpeed,8k618-t", "allwinner,sun50i-h618";
> +
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;

Any particular reason for above alias?

> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	reg_vcc5v: vcc5v {
> +		/* board wide 5V supply directly from the DC input */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-5v";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-always-on;
> +	};
> +
> +	reg_vcc3v3: vcc3v3 {
> +		/* discrete 3.3V regulator */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-3v3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-always-on;
> +	};
> +};
> +
> +&ehci0 {
> +	status = "okay";
> +};
> +
> +&ehci1 {
> +	status = "okay";
> +};
> +
> +&ir {
> +	status = "okay";
> +};
> +
> +&mmc0 {
> +	vmmc-supply = <&reg_dldo1>;
> +	cd-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>;	/* PI16 */
> +	bus-width = <4>;
> +	status = "okay";
> +};
> +
> +&mmc2 {
> +	vmmc-supply = <&reg_dldo1>;
> +	vqmmc-supply = <&reg_aldo1>;
> +	bus-width = <8>;
> +	non-removable;
> +	cap-mmc-hw-reset;
> +	mmc-ddr-1_8v;
> +	mmc-hs200-1_8v;
> +	status = "okay";
> +};
> +
> +&ohci0 {
> +	status = "okay";
> +};
> +
> +&ohci1 {
> +	status = "okay";
> +};
> +
> +&r_i2c {
> +	status = "okay";
> +
> +	axp313: pmic at 36 {
> +		compatible = "x-powers,axp313a";
> +		reg = <0x36>;
> +		#interrupt-cells = <1>;
> +		interrupt-controller;
> +
> +		vin1-supply = <&reg_vcc5v>;
> +		vin2-supply = <&reg_vcc5v>;
> +		vin3-supply = <&reg_vcc5v>;
> +
> +		regulators {
> +			/* Supplies VCC-PLL, so needs to be always 
on. */
> +			reg_aldo1: aldo1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<1800000>;
> +				regulator-max-microvolt = 
<1800000>;
> +				regulator-name = "vcc1v8";

It would be great to expand all PMIC regulator names with (known) areas they 
power, so something like "vcc1v8-pll-pc". With that, I think you can remove 
comments.

Best regards,
Jernej

> +			};
> +
> +			/* Supplies VCC-IO, so needs to be always on. 
*/
> +			reg_dldo1: dldo1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<3300000>;
> +				regulator-max-microvolt = 
<3300000>;
> +				regulator-name = "vcc3v3";
> +			};
> +
> +			reg_dcdc1: dcdc1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<810000>;
> +				regulator-max-microvolt = 
<990000>;
> +				regulator-name = "vdd-gpu-sys";
> +			};
> +
> +			reg_dcdc2: dcdc2 {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<810000>;
> +				regulator-max-microvolt = 
<1100000>;
> +				regulator-name = "vdd-cpu";
> +			};
> +
> +			reg_dcdc3: dcdc3 {
> +				regulator-always-on;
> +				regulator-min-microvolt = 
<1360000>;
> +				regulator-max-microvolt = 
<1360000>;
> +				regulator-name = "vdd-dram";
> +			};
> +		};
> +	};
> +};
> +
> +&pio {
> +	vcc-pc-supply = <&reg_aldo1>;
> +	vcc-pg-supply = <&reg_dldo1>;
> +	vcc-ph-supply = <&reg_dldo1>;
> +	vcc-pi-supply = <&reg_dldo1>;
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_ph_pins>;
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
> +	uart-has-rtscts;
> +	status = "okay";
> +};
> +
> +&usbotg {
> +	dr_mode = "host";	/* USB A type receptable */
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	status = "okay";
> +};






From broonie at kernel.org  Wed Dec 13 11:23:40 2023
From: broonie at kernel.org (Mark Brown)
Date: Wed, 13 Dec 2023 19:23:40 +0000
Subject: [PATCH v2] ASoC: mediatek: mt7986: silence error in case of
 -EPROBE_DEFER
In-Reply-To: <b941a404d97c01ef3e30c49925927b9a7dafeb19.1702422544.git.daniel@makrotopia.org>
References: <b941a404d97c01ef3e30c49925927b9a7dafeb19.1702422544.git.daniel@makrotopia.org>
Message-ID: <170249542061.33569.6338427444807634963.b4-ty@kernel.org>

On Tue, 12 Dec 2023 23:10:07 +0000, Daniel Golle wrote:
> If probe is defered no error should be printed. Use dev_err_probe() to
> have it muted.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: mediatek: mt7986: silence error in case of -EPROBE_DEFER
      commit: 6475b8e1821c9d14e60592a74c10d75431500c7c

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From krzysztof.kozlowski at linaro.org  Wed Dec 13 11:37:50 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 13 Dec 2023 20:37:50 +0100
Subject: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
In-Reply-To: <44abff4a-0a8e-499b-8b98-a4a1680cb431@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-9-ninad@linux.ibm.com>
 <5b98538a-8ffe-42ec-b020-514dcfcebba3@linaro.org>
 <44abff4a-0a8e-499b-8b98-a4a1680cb431@linux.ibm.com>
Message-ID: <427fa99c-764c-4d6a-b9f1-cd9089710d5e@linaro.org>

On 13/12/2023 20:02, Ninad Palsule wrote:
> Hello Krzysztof,
> 
> On 12/12/23 14:26, Krzysztof Kozlowski wrote:
>> On 12/12/2023 17:40, Ninad Palsule wrote:
>>> This drop adds following devices in the device tree.
>>> - EEPROM/VPD
>>> - Power supplies
>>> - Humidity, pressure and temperature sensors.
>>> - Trusted platform module(TPM) chip
>>>
>>> Tested:
>>>      This board is tested using the simics simulator.
>>>
>>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>>> ---
>> Don't mix DTS with drivers. DTS and drivers go via different subsystems
>> and cannot have dependencies, so why DTS is patch #6, then driver #7 and
>> now again DTS #7?
> 
> There is a dependency on driver code as patch #8 uses the compatibility 
> string added in driver patch #7.? I have now moved driver patch at the 
> start. Is that ok? OR you are suggesting something else?

First, there is no dependency. Second, except confusing order anyway DTS
will go via separate trees. Third, again, there is no dependency. If
there is, your patchset is broken and this needs to be fixed. Although I
don't understand how new hardware can depend on driver... it's really odd.

Best regards,
Krzysztof



From debug at rivosinc.com  Wed Dec 13 11:43:49 2023
From: debug at rivosinc.com (Deepak Gupta)
Date: Wed, 13 Dec 2023 11:43:49 -0800
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <0d0d8802-09e3-4ea5-a0b4-b3a08c8a282e@sirena.org.uk>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org> <CAKC1njSC5cC_fXnyNAPt=WU6cD-OjLKFxo90oVPmsLJbuWf4nw@mail.gmail.com>
 <d708b493-267a-4418-be91-9bde6b2cf50c@sirena.org.uk> <CAKC1njSQPO8ja7AkTzQ724hhSsGjchH9dLbbH9LXP0ZiKj-zPQ@mail.gmail.com>
 <0d0d8802-09e3-4ea5-a0b4-b3a08c8a282e@sirena.org.uk>
Message-ID: <CAKC1njRHs0R=VKfn4jBap9__oR0rBHmNy7_tqHR8=xEHdUE4+A@mail.gmail.com>

On Wed, Dec 13, 2023 at 5:37?AM Mark Brown <broonie at kernel.org> wrote:
>
> On Tue, Dec 12, 2023 at 04:50:38PM -0800, Deepak Gupta wrote:
>
> > A theoretical scenario (no current workloads should've this case
> > because no shadow stack)
>
> > - User mode did _ENABLE on the main thread. Shadow stack was allocated
> > for the current
> >   thread.
> > - User mode created a bunch worker threads to run untrusted contained
> > code. They shadow
> >   stack too.
> > - main thread had to do dlopen and now need to disable shadow stack on
> > itself due to
> >   incompatibility of incoming object in address space.
> > - main thread controls worker threads and knows they're contained and
> > should still be running
> >   with a shadow stack. Although once in a while the main thread needs
> > to perform writes to a shadow
> >   stack of worker threads for some fixup (in the same addr space).
> > main thread doesn't want to delegate
> >   this responsibility of ss writes to worker threads because they're untrusted.
>
> > How will it do that (currently _ENABLE is married to _WRITE and _PUSH) ?
>
> That's feeling moderately firmly into "don't do that" territory to be
> honest, the problems of trying to modify the stack of another running
> thread while it's active just don't seem worth it - if you're
> coordinating enough to do the modifications it's probably possible to
> just ask the thread who's stack is being modified to do the modification
> itself and having an unprotected thread writing into shadow stack memory
> doesn't feel great.
>

Yeah no leanings on my side. Just wanted to articulate this scenario.
Since this is new ground,
we can define what's appropriate. Let's keep it this way where a
thread can write to shadow
stack mappings only when it itself has shadow stack enabled.


From broonie at kernel.org  Wed Dec 13 11:48:28 2023
From: broonie at kernel.org (Mark Brown)
Date: Wed, 13 Dec 2023 19:48:28 +0000
Subject: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack
In-Reply-To: <CAKC1njRHs0R=VKfn4jBap9__oR0rBHmNy7_tqHR8=xEHdUE4+A@mail.gmail.com>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-2-201c483bd775@kernel.org>
 <CAKC1njSC5cC_fXnyNAPt=WU6cD-OjLKFxo90oVPmsLJbuWf4nw@mail.gmail.com>
 <d708b493-267a-4418-be91-9bde6b2cf50c@sirena.org.uk>
 <CAKC1njSQPO8ja7AkTzQ724hhSsGjchH9dLbbH9LXP0ZiKj-zPQ@mail.gmail.com>
 <0d0d8802-09e3-4ea5-a0b4-b3a08c8a282e@sirena.org.uk>
 <CAKC1njRHs0R=VKfn4jBap9__oR0rBHmNy7_tqHR8=xEHdUE4+A@mail.gmail.com>
Message-ID: <feb6d1fc-c144-4f2b-833f-b3e00646cf30@sirena.org.uk>

On Wed, Dec 13, 2023 at 11:43:49AM -0800, Deepak Gupta wrote:
> On Wed, Dec 13, 2023 at 5:37?AM Mark Brown <broonie at kernel.org> wrote:
> > On Tue, Dec 12, 2023 at 04:50:38PM -0800, Deepak Gupta wrote:

> > > How will it do that (currently _ENABLE is married to _WRITE and _PUSH) ?

> > That's feeling moderately firmly into "don't do that" territory to be
> > honest, the problems of trying to modify the stack of another running
> > thread while it's active just don't seem worth it - if you're
> > coordinating enough to do the modifications it's probably possible to
> > just ask the thread who's stack is being modified to do the modification
> > itself and having an unprotected thread writing into shadow stack memory
> > doesn't feel great.

> Yeah no leanings on my side. Just wanted to articulate this scenario.
> Since this is new ground,
> we can define what's appropriate. Let's keep it this way where a
> thread can write to shadow
> stack mappings only when it itself has shadow stack enabled.

Sounds good to me - it's much easier to relax permissions later than to
tighten them up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/2b5079b7/attachment-0001.sig>

From ninad at linux.ibm.com  Wed Dec 13 11:49:21 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Wed, 13 Dec 2023 13:49:21 -0600
Subject: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
In-Reply-To: <427fa99c-764c-4d6a-b9f1-cd9089710d5e@linaro.org>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-9-ninad@linux.ibm.com>
 <5b98538a-8ffe-42ec-b020-514dcfcebba3@linaro.org>
 <44abff4a-0a8e-499b-8b98-a4a1680cb431@linux.ibm.com>
 <427fa99c-764c-4d6a-b9f1-cd9089710d5e@linaro.org>
Message-ID: <edcdcea2-febc-4859-9ccf-b8c59b794f01@linux.ibm.com>

Hello Krzysztof,

On 12/13/23 13:37, Krzysztof Kozlowski wrote:
> On 13/12/2023 20:02, Ninad Palsule wrote:
>> Hello Krzysztof,
>>
>> On 12/12/23 14:26, Krzysztof Kozlowski wrote:
>>> On 12/12/2023 17:40, Ninad Palsule wrote:
>>>> This drop adds following devices in the device tree.
>>>> - EEPROM/VPD
>>>> - Power supplies
>>>> - Humidity, pressure and temperature sensors.
>>>> - Trusted platform module(TPM) chip
>>>>
>>>> Tested:
>>>>       This board is tested using the simics simulator.
>>>>
>>>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>>>> ---
>>> Don't mix DTS with drivers. DTS and drivers go via different subsystems
>>> and cannot have dependencies, so why DTS is patch #6, then driver #7 and
>>> now again DTS #7?
>> There is a dependency on driver code as patch #8 uses the compatibility
>> string added in driver patch #7.? I have now moved driver patch at the
>> start. Is that ok? OR you are suggesting something else?
> First, there is no dependency. Second, except confusing order anyway DTS
> will go via separate trees. Third, again, there is no dependency. If
> there is, your patchset is broken and this needs to be fixed. Although I
> don't understand how new hardware can depend on driver... it's really odd.

Thanks for the quick response.

This board uses the nuvoton TPM device. The tpm devices uses 
"nuvoton,npct75x" driver hence we added it in the device tree. If the 
driver doesn't have this compatibility string then it won't load. So if 
someone tries to use this board then tpm won't work unless the 
compatibility string is added in the driver. That is the dependency I am 
talking about.

Please let me know.

Regards,

Ninad

>
> Best regards,
> Krzysztof
>


From knaerzche at gmail.com  Wed Dec 13 11:51:16 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:16 +0100
Subject: [PATCH 02/11] drm/rockchip: vop: Add output selection registers for RK312x
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-3-knaerzche@gmail.com>

In contrast to RK3036, RK312x SoCs have multiple output channels such as
RGB (i.e. LVDS TTL), LVDS, DSI and HDMI.

In order to support that, this adds a new vop_output struct for rk3126_vop
with the registers required to enable the appropriate output and setup the
correct polarity.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 ++++++++++++-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  3 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index c51ca82320cb..b9ee02061d5b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -227,11 +227,22 @@ static const struct vop_win_data rk3126_vop_win_data[] = {
 	  .type = DRM_PLANE_TYPE_CURSOR },
 };
 
+static const struct vop_output rk3126_output = {
+	.pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+	.hdmi_pin_pol = VOP_REG(RK3126_INT_SCALER, 0x7, 4),
+	.hdmi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 22),
+	.hdmi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 23),
+	.rgb_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 24),
+	.rgb_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 25),
+	.mipi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 28),
+	.mipi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 29),
+};
+
 static const struct vop_data rk3126_vop = {
 	.intr = &rk3036_intr,
 	.common = &rk3036_common,
 	.modeset = &rk3036_modeset,
-	.output = &rk3036_output,
+	.output = &rk3126_output,
 	.win = rk3126_vop_win_data,
 	.win_size = ARRAY_SIZE(rk3126_vop_win_data),
 	.max_output = { 1920, 1080 },
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 406e981c75bd..fbf1bcc68625 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -872,6 +872,9 @@
 /* rk3036 register definition end */
 
 /* rk3126 register definition */
+#define RK3126_INT_SCALER		0x0c
+
+/* win1 register */
 #define RK3126_WIN1_MST			0x4c
 #define RK3126_WIN1_DSP_INFO		0x50
 #define RK3126_WIN1_DSP_ST		0x54
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:14 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:14 +0100
Subject: [PATCH 00/11] Add HDMI support for RK3128
Message-ID: <20231213195125.212923-1-knaerzche@gmail.com>

This series aims to add support for the display controller (VOP) and the
HDMI controller block of RK3128 (which is very similar to the one found in
RK3036).

The VOP part is very simple -  everything we need for HDMI support is
already there. I only needed to split the output selection registers from
RK3036.
The VOP has an IOMMU attached, but it has a serious silicon bug:
Registers can only be written, but not be read. As it's not possible to use
it with the IOMMU driver in it's current state I'm not adding it here and
we have to live with CMA for now - which works fine also. Andy, maybe you
can shed a light on whether there is any way to not have to write the
registers only and hope for the best (a.k.a rockchip,skip-mmu-read). I have
it working here locally - but nothing for upstream (yet).

The inno-hdmi driver currently gets a lot of attention [0-2] and I'm
hooking in now also. I did only the bare minimum to get a correctly colored
picture and a stable signal for RK3128. I leave the cleanups to those other
series and will come back with sound/CEC support later. It shouldn't
interfere to much, only the csc-part must not get dropped completely and
the mode-check-hooks are no longer dead.

Note: Patches are based and tested on next-20231213.

[0] https://lore.kernel.org/all/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org
[1] https://lore.kernel.org/all/20231204123315.28456-1-keith.zhao at starfivetech.com
[2] https://lore.kernel.org/all/2601b669-c570-f39d-8cf9-bff56c939912 at gmail.com

Alex Bee (11):
  dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible
  drm/rockchip: vop: Add output selection registers for RK312x
  drm/rockchip: inno_hdmi: Fix video timing
  drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
  drm/rockchip: inno_hdmi: Add variant support
  drm/rockchip: inno_hdmi: Add RK3128 support
  drm/rockchip: inno_hdmi: Add basic mode validation
  drm/rockchip: inno_hdmi: Drop custom fill_modes hook
  ARM: dts: rockchip: Add display subsystem for RK3128
  ARM: dts rockchip: Add HDMI node for RK3128
  ARM: dts: rockchip: Enable HDMI output for XPI-3128

 .../display/rockchip/rockchip,inno-hdmi.yaml  |  30 ++-
 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts |  29 +++
 arch/arm/boot/dts/rockchip/rk3128.dtsi        |  60 ++++++
 drivers/gpu/drm/rockchip/inno_hdmi.c          | 203 +++++++++++++++---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c   |  13 +-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h   |   3 +
 6 files changed, 309 insertions(+), 29 deletions(-)


base-commit: 48e8992e33abf054bcc0bb2e77b2d43bb899212e
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:18 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:18 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-5-knaerzche@gmail.com>

The display controller will always give full range RGB regardless of the
mode set, but HDMI requires certain modes to be transmitted in limited
range RGB. This is especially required for HDMI sinks which do not support
non-standard quantization ranges.

This enables color space conversion for those modes and sets the
quantization range accordingly in the AVI infoframe.

Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 345253e033c5..32626a75723c 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -33,6 +33,7 @@ struct hdmi_data_info {
 	unsigned int enc_in_format;
 	unsigned int enc_out_format;
 	unsigned int colorimetry;
+	bool rgb_limited_range;
 };
 
 struct inno_hdmi_i2c {
@@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
+	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
+		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
+						   &hdmi->connector, mode,
+						   hdmi->hdmi_data.rgb_limited_range ?
+						   HDMI_QUANTIZATION_RANGE_LIMITED :
+						   HDMI_QUANTIZATION_RANGE_FULL);
+	} else {
+		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
+		frame.avi.ycc_quantization_range =
+			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
+	}
+
 	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
 }
 
@@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 	if (data->enc_in_format == data->enc_out_format) {
 		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
 		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
-			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
-			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
-			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
-				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
-				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
-				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
-			return 0;
+			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
+			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
+			    hdmi->hdmi_data.rgb_limited_range) {
+				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
+				auto_csc = AUTO_CSC_DISABLE;
+				c0_c2_change = C0_C2_CHANGE_DISABLE;
+				csc_enable = v_CSC_ENABLE;
+			} else {
+				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+				return 0;
+			}
 		}
 	}
 
@@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	else
 		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
 
+	hdmi->hdmi_data.rgb_limited_range =
+		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
+
 	/* Mute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
 		  v_AUDIO_MUTE(1) | v_VIDEO_MUTE(1));
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:15 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:15 +0100
Subject: [PATCH 01/11] dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-2-knaerzche@gmail.com>

Document the compatible for RK3128's HDMI controller block.
The integration for this SoC is somewhat different here: It needs the PHY's
reference clock rate to calculate the ddc bus frequency correctly. This
clock is part of a power-domain (PD_VIO), so this gets added as an optional
property too.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 .../display/rockchip/rockchip,inno-hdmi.yaml  | 30 +++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
index 96889c86849a..9f00abcbfb38 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
@@ -14,6 +14,7 @@ properties:
   compatible:
     enum:
       - rockchip,rk3036-inno-hdmi
+      - rockchip,rk3128-inno-hdmi
 
   reg:
     maxItems: 1
@@ -22,10 +23,21 @@ properties:
     maxItems: 1
 
   clocks:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: The HDMI controller main clock
+      - description: The HDMI PHY reference clock
 
   clock-names:
-    const: pclk
+    minItems: 1
+    items:
+      - const: pclk
+      - enum:
+          - pclk
+          - ref
+
+  power-domains:
+    maxItems: 1
 
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
@@ -55,6 +67,20 @@ required:
   - pinctrl-names
   - ports
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: rockchip,rk3128-inno-hdmi
+
+    then:
+      properties:
+        clocks:
+          minItems: 2
+        clock-names:
+          minItems: 2
+
 additionalProperties: false
 
 examples:
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:17 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:17 +0100
Subject: [PATCH 03/11] drm/rockchip: inno_hdmi: Fix video timing
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-4-knaerzche@gmail.com>

The controller wants the difference between *total and *sync_start in
the HDMI_VIDEO_EXT_*DELAY registers. Otherwise the signal is very
unstable for certain non-VIC modes.
See downstream commit [0]

[0] https://github.com/rockchip-linux/kernel/commit/8eb559f2502c

Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Co-developed-by: Zheng Yang <zhengyang at rock-chips.com>
Signed-off-by: Zheng Yang <zhengyang at rock-chips.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 6e5b922a121e..345253e033c5 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -412,7 +412,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_L, value & 0xFF);
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_H, (value >> 8) & 0xFF);
 
-	value = mode->hsync_start - mode->hdisplay;
+	value = mode->htotal - mode->hsync_start;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_L, value & 0xFF);
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_H, (value >> 8) & 0xFF);
 
@@ -427,7 +427,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
 	value = mode->vtotal - mode->vdisplay;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VBLANK, value & 0xFF);
 
-	value = mode->vsync_start - mode->vdisplay;
+	value = mode->vtotal - mode->vsync_start;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VDELAY, value & 0xFF);
 
 	value = mode->vsync_end - mode->vsync_start;
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:20 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:20 +0100
Subject: [PATCH 06/11] drm/rockchip: inno_hdmi: Add RK3128 support
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-7-knaerzche@gmail.com>

This variant requires the phy reference clock to be enabled before the
DDC block can work and the (initial) DDC bus frequency is calculated
based on the rate of this clock.
Besides the only difference is phy configuration which is required to make
the driver working for this variant as well.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 46 +++++++++++++++++++++++++---
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 593b184bd0ad..f7f0bec725f9 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -63,6 +63,7 @@ struct inno_hdmi {
 
 	int irq;
 	struct clk *pclk;
+	struct clk *refclk;
 	void __iomem *regs;
 
 	struct drm_connector	connector;
@@ -85,6 +86,12 @@ static struct inno_hdmi_phy_config rk3036_hdmi_phy_configs[] = {
 	{ ~0UL,	     0x00, 0x00 }
 };
 
+static struct inno_hdmi_phy_config rk3128_hdmi_phy_configs[] = {
+	{ 74250000,  0x3f, 0xaa },
+	{ 165000000, 0x5f, 0xaa },
+	{ ~0UL,	     0x00, 0x00 }
+};
+
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
 {
 	struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
@@ -930,6 +937,20 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		return ret;
 	}
 
+	hdmi->refclk = devm_clk_get_optional(hdmi->dev, "ref");
+	if (IS_ERR(hdmi->refclk)) {
+		DRM_DEV_ERROR(hdmi->dev, "Unable to get HDMI reference clock\n");
+		ret = PTR_ERR(hdmi->refclk);
+		goto err_disable_pclk;
+	}
+
+	ret = clk_prepare_enable(hdmi->refclk);
+	if (ret) {
+		DRM_DEV_ERROR(hdmi->dev,
+			      "Cannot enable HDMI reference clock: %d\n", ret);
+		goto err_disable_pclk;
+	}
+
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		ret = irq;
@@ -946,12 +967,16 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	}
 
 	/*
-	 * When IP controller haven't configured to an accurate video
-	 * timing, then the TMDS clock source would be switched to
-	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
-	 * and reconfigure the DDC clock.
+	 * When IP controller isn't configured to an accurate
+	 * video timing and there is no reference clock available,
+	 * then the TMDS clock source would be switched to PCLK_HDMI,
+	 * so we need to init the TMDS rate to PCLK rate, and
+	 * reconfigure the DDC clock.
 	 */
-	hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
+	if (hdmi->refclk)
+		hdmi->tmds_rate = clk_get_rate(hdmi->refclk);
+	else
+		hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
 	inno_hdmi_i2c_init(hdmi);
 
 	ret = inno_hdmi_register(drm, hdmi);
@@ -976,6 +1001,8 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 err_put_adapter:
 	i2c_put_adapter(hdmi->ddc);
 err_disable_clk:
+	clk_disable_unprepare(hdmi->refclk);
+err_disable_pclk:
 	clk_disable_unprepare(hdmi->pclk);
 	return ret;
 }
@@ -989,6 +1016,7 @@ static void inno_hdmi_unbind(struct device *dev, struct device *master,
 	hdmi->encoder.encoder.funcs->destroy(&hdmi->encoder.encoder);
 
 	i2c_put_adapter(hdmi->ddc);
+	clk_disable_unprepare(hdmi->refclk);
 	clk_disable_unprepare(hdmi->pclk);
 }
 
@@ -1012,10 +1040,18 @@ static const struct inno_hdmi_variant rk3036_inno_hdmi_variant = {
 	.default_phy_config = &rk3036_hdmi_phy_configs[1],
 };
 
+static const struct inno_hdmi_variant rk3128_inno_hdmi_variant = {
+	.phy_configs = rk3128_hdmi_phy_configs,
+	.default_phy_config = &rk3128_hdmi_phy_configs[1],
+};
+
 static const struct of_device_id inno_hdmi_dt_ids[] = {
 	{ .compatible = "rockchip,rk3036-inno-hdmi",
 	  .data = &rk3036_inno_hdmi_variant,
 	},
+	{ .compatible = "rockchip,rk3128-inno-hdmi",
+	  .data = &rk3128_inno_hdmi_variant,
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, inno_hdmi_dt_ids);
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:19 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:19 +0100
Subject: [PATCH 05/11] drm/rockchip: inno_hdmi: Add variant support
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-6-knaerzche@gmail.com>

In preparation to support RK3128's integration of the controller, this
patch adds a simple variant implementation. They mainly differ in the
phy configuration required, so those are part of the match_data.
The values have been taken from downstream. The pixelclocks in there are
meant to be max-inclusive.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 68 +++++++++++++++++++++++++++-
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 32626a75723c..593b184bd0ad 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -27,6 +27,17 @@
 
 #include "inno_hdmi.h"
 
+struct inno_hdmi_phy_config {
+	unsigned int pixelclock;
+	u8 pre_emphasis;
+	u8 voltage_level_control;
+};
+
+struct inno_hdmi_variant {
+	struct inno_hdmi_phy_config *phy_configs;
+	struct inno_hdmi_phy_config *default_phy_config;
+};
+
 struct hdmi_data_info {
 	int vic;
 	bool sink_has_audio;
@@ -64,6 +75,14 @@ struct inno_hdmi {
 
 	struct hdmi_data_info	hdmi_data;
 	struct drm_display_mode previous_mode;
+
+	const struct inno_hdmi_variant *variant;
+};
+
+static struct inno_hdmi_phy_config rk3036_hdmi_phy_configs[] = {
+	{ 74250000,  0x3f, 0xbb },
+	{ 165000000, 0x6f, 0xbb },
+	{ ~0UL,	     0x00, 0x00 }
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -176,6 +195,24 @@ static inline void hdmi_modb(struct inno_hdmi *hdmi, u16 offset,
 	hdmi_writeb(hdmi, offset, temp);
 }
 
+static int inno_hdmi_find_phy_config(struct inno_hdmi *hdmi,
+				     unsigned int pixelclk)
+{
+	const struct inno_hdmi_phy_config *phy_configs =
+						hdmi->variant->phy_configs;
+	int i;
+
+	for (i = 0; phy_configs[i].pixelclock != ~0UL; i++) {
+		if (pixelclk <= phy_configs[i].pixelclock)
+			return i;
+	}
+
+	DRM_DEV_DEBUG(hdmi->dev, "No phy configuration for pixelclock %u\n",
+		      pixelclk);
+
+	return -EINVAL;
+}
+
 static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
 {
 	int ddc_bus_freq;
@@ -200,12 +237,25 @@ static void inno_hdmi_sys_power(struct inno_hdmi *hdmi, bool enable)
 
 static void inno_hdmi_set_pwr_mode(struct inno_hdmi *hdmi, int mode)
 {
+	int ret;
+	struct inno_hdmi_phy_config *phy_config;
+
 	switch (mode) {
 	case NORMAL:
 		inno_hdmi_sys_power(hdmi, false);
 
-		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
-		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
+		ret = inno_hdmi_find_phy_config(hdmi, hdmi->tmds_rate);
+		if (ret < 0) {
+			phy_config = hdmi->variant->default_phy_config;
+			DRM_DEV_ERROR(hdmi->dev,
+				      "Using default phy configuration for TMDS rate %u",
+				      hdmi->tmds_rate);
+		} else {
+			phy_config = &hdmi->variant->phy_configs[ret];
+		}
+
+		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, phy_config->pre_emphasis);
+		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, phy_config->voltage_level_control);
 
 		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
 		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
@@ -845,6 +895,8 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	struct platform_device *pdev = to_platform_device(dev);
 	struct drm_device *drm = data;
 	struct inno_hdmi *hdmi;
+	const struct inno_hdmi_variant *variant;
+
 	int irq;
 	int ret;
 
@@ -853,6 +905,12 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		return -ENOMEM;
 
 	hdmi->dev = dev;
+
+	variant = of_device_get_match_data(hdmi->dev);
+	if (!variant)
+		return -EINVAL;
+
+	hdmi->variant = variant;
 	hdmi->drm_dev = drm;
 
 	hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
@@ -949,8 +1007,14 @@ static void inno_hdmi_remove(struct platform_device *pdev)
 	component_del(&pdev->dev, &inno_hdmi_ops);
 }
 
+static const struct inno_hdmi_variant rk3036_inno_hdmi_variant = {
+	.phy_configs = rk3036_hdmi_phy_configs,
+	.default_phy_config = &rk3036_hdmi_phy_configs[1],
+};
+
 static const struct of_device_id inno_hdmi_dt_ids[] = {
 	{ .compatible = "rockchip,rk3036-inno-hdmi",
+	  .data = &rk3036_inno_hdmi_variant,
 	},
 	{},
 };
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:23 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:23 +0100
Subject: [PATCH 09/11] ARM: dts: rockchip: Add display subsystem for RK3128
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-10-knaerzche@gmail.com>

Add vop and display-subsysem nodes to RK3128's device tree.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128.dtsi | 27 ++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index e2264c40b924..1a3bc8b2bc6e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -115,6 +115,12 @@ opp-1200000000 {
 		};
 	};
 
+	display_subsystem: display-subsystem {
+		compatible = "rockchip,display-subsystem";
+		ports = <&vop_out>;
+		status = "disabled";
+	};
+
 	gpu_opp_table: opp-table-1 {
 		compatible = "operating-points-v2";
 
@@ -246,6 +252,27 @@ power-domain at RK3128_PD_GPU {
 		};
 	};
 
+	vop: vop at 1010e000 {
+		compatible = "rockchip,rk3126-vop";
+		reg = <0x1010e000 0x300>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru ACLK_LCDC0>, <&cru DCLK_VOP>,
+			 <&cru HCLK_LCDC0>;
+		clock-names = "aclk_vop", "dclk_vop",
+			      "hclk_vop";
+		resets = <&cru SRST_VOP_A>, <&cru SRST_VOP_H>,
+			 <&cru SRST_VOP_D>;
+		reset-names = "axi", "ahb",
+			      "dclk";
+		power-domains = <&power RK3128_PD_VIO>;
+		status = "disabled";
+
+		vop_out: port {
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	qos_gpu: qos at 1012d000 {
 		compatible = "rockchip,rk3128-qos", "syscon";
 		reg = <0x1012d000 0x20>;
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:24 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:24 +0100
Subject: [PATCH 10/11] ARM: dts rockchip: Add HDMI node for RK3128
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-11-knaerzche@gmail.com>

RK3128 has Innosilicon based HDMI TX controller similar to the one found in
RK3036.
Add it and the respective port nodes to the SoC device tree.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 arch/arm/boot/dts/rockchip/rk3128.dtsi | 33 ++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 1a3bc8b2bc6e..fb98873fd94e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -270,6 +270,11 @@ vop: vop at 1010e000 {
 		vop_out: port {
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			vop_out_hdmi: endpoint at 0 {
+				reg = <0>;
+				remote-endpoint = <&hdmi_in_vop>;
+			};
 		};
 	};
 
@@ -463,6 +468,34 @@ usb2phy_otg: otg-port {
 		};
 	};
 
+	hdmi: hdmi at 20034000 {
+		compatible = "rockchip,rk3128-inno-hdmi";
+		reg = <0x20034000 0x4000>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru PCLK_HDMI>, <&cru DCLK_VOP>;
+		clock-names = "pclk", "ref";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hdmii2c_xfer &hdmi_hpd &hdmi_cec>;
+		power-domains = <&power RK3128_PD_VIO>;
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			hdmi_in: port at 0 {
+				reg = <0>;
+				hdmi_in_vop: endpoint {
+					remote-endpoint = <&vop_out_hdmi>;
+				};
+			};
+
+			hdmi_out: port at 1 {
+				reg = <1>;
+			};
+		};
+	};
+
 	timer0: timer at 20044000 {
 		compatible = "rockchip,rk3128-timer", "rockchip,rk3288-timer";
 		reg = <0x20044000 0x20>;
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:22 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:22 +0100
Subject: [PATCH 08/11] drm/rockchip: inno_hdmi: Drop custom fill_modes hook
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-9-knaerzche@gmail.com>

Now that we have proper pixelclock-based validation we can drop the
custom fill_modes hook.
CRTC size validation for the display controller has been added with
Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
hardware capabilities")

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 2f839ff31c1c..84520da8c995 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -696,13 +696,6 @@ inno_hdmi_connector_mode_valid(struct drm_connector *connector,
 	return inno_hdmi_mode_valid(hdmi, mode);
 }
 
-static int
-inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
-				       uint32_t maxX, uint32_t maxY)
-{
-	return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
-}
-
 static void inno_hdmi_connector_destroy(struct drm_connector *connector)
 {
 	drm_connector_unregister(connector);
@@ -710,7 +703,7 @@ static void inno_hdmi_connector_destroy(struct drm_connector *connector)
 }
 
 static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
-	.fill_modes = inno_hdmi_probe_single_connector_modes,
+	.fill_modes = drm_helper_probe_single_connector_modes,
 	.detect = inno_hdmi_connector_detect,
 	.destroy = inno_hdmi_connector_destroy,
 	.reset = drm_atomic_helper_connector_reset,
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:21 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:21 +0100
Subject: [PATCH 07/11] drm/rockchip: inno_hdmi: Add basic mode validation
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-8-knaerzche@gmail.com>

As per TRM this controller supports pixelclocks starting from 25 MHz. The
maximum supported pixelclocks are defined by the phy configurations we
have. Also it can't support modes that require doubled clocks.
If there is a phy reference clock we can additionally validate against
VESA DMT's recommendations.
Those checks are added to the mode_valid hook of the connector and
encoder's mode_fixup hook.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 38 ++++++++++++++++++++++++++--
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f7f0bec725f9..2f839ff31c1c 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -38,6 +38,8 @@ struct inno_hdmi_variant {
 	struct inno_hdmi_phy_config *default_phy_config;
 };
 
+#define INNO_HDMI_MIN_TMDS_CLOCK  25000000U
+
 struct hdmi_data_info {
 	int vic;
 	bool sink_has_audio;
@@ -572,6 +574,34 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	return 0;
 }
 
+static enum drm_mode_status inno_hdmi_mode_valid(struct inno_hdmi *hdmi,
+						 struct drm_display_mode *mode)
+{
+	/* No support for double-clock modes */
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+		return MODE_BAD;
+
+	unsigned int mpixelclk = mode->clock * 1000;
+
+	if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
+		return MODE_CLOCK_LOW;
+
+	if (inno_hdmi_find_phy_config(hdmi, mpixelclk) < 0)
+		return MODE_CLOCK_HIGH;
+
+	if (hdmi->refclk) {
+		long refclk = clk_round_rate(hdmi->refclk, mpixelclk);
+		unsigned int max_tolerance = mpixelclk / 5000;
+
+		/* Vesa DMT standard mentions +/- 0.5% max tolerance */
+		if (abs(refclk - mpixelclk) > max_tolerance ||
+		    mpixelclk - refclk > max_tolerance)
+			return MODE_NOCLOCK;
+	}
+
+	return MODE_OK;
+}
+
 static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
 				       struct drm_display_mode *mode,
 				       struct drm_display_mode *adj_mode)
@@ -602,7 +632,9 @@ static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
 					 const struct drm_display_mode *mode,
 					 struct drm_display_mode *adj_mode)
 {
-	return true;
+	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
+
+	return inno_hdmi_mode_valid(hdmi, adj_mode) == MODE_OK;
 }
 
 static int
@@ -659,7 +691,9 @@ static enum drm_mode_status
 inno_hdmi_connector_mode_valid(struct drm_connector *connector,
 			       struct drm_display_mode *mode)
 {
-	return MODE_OK;
+	struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
+
+	return inno_hdmi_mode_valid(hdmi, mode);
 }
 
 static int
-- 
2.43.0



From knaerzche at gmail.com  Wed Dec 13 11:51:25 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 20:51:25 +0100
Subject: [PATCH 11/11] ARM: dts: rockchip: Enable HDMI output for XPI-3128
In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
Message-ID: <20231213195125.212923-12-knaerzche@gmail.com>

Add an hdmi-connector node and enable the hdmi, display-subsystem and vop
nodes.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index 03a97881519a..21c1678f4e91 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -47,6 +47,17 @@ dc_5v: dc-5v-regulator {
 		regulator-boot-on;
 	};
 
+	hdmi-connnector {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_connector_in: endpoint {
+				remote-endpoint = <&hdmi_connector_out>;
+			};
+		};
+	};
+
 	/*
 	 * This is a vbus-supply, which also supplies the GL852G usb hub,
 	 * thus has to be always-on
@@ -239,6 +250,10 @@ &cpu0 {
 	cpu-supply = <&vdd_arm>;
 };
 
+&display_subsystem {
+	status = "okay";
+};
+
 &emmc {
 	bus-width = <8>;
 	vmmc-supply = <&vcc_io>;
@@ -328,6 +343,16 @@ &gpu {
 	status = "okay";
 };
 
+&hdmi {
+	status = "okay";
+};
+
+&hdmi_out {
+	hdmi_connector_out: endpoint {
+		remote-endpoint = <&hdmi_connector_in>;
+	};
+};
+
 &mdio {
 	phy0: ethernet-phy at 1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
@@ -423,3 +448,7 @@ &usb2phy_host {
 &usb2phy_otg {
 	status = "okay";
 };
+
+&vop {
+	status = "okay";
+};
-- 
2.43.0



From kan.liang at linux.intel.com  Wed Dec 13 11:51:47 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed, 13 Dec 2023 11:51:47 -0800
Subject: [PATCH V3 0/7] Clean up perf mem
Message-ID: <20231213195154.1085945-1-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

Changes since V2:
- Fix the Arm64 building error (Leo)
- Add two new patches to clean up perf_mem_events__record_args()
  and perf_pmus__num_mem_pmus() (Leo)

Changes since V1:
- Fix strcmp of PMU name checking (Ravi)
- Fix "/," typo (Ian)
- Rename several functions with perf_pmu__mem_events prefix. (Ian)
- Fold the header removal patch into the patch where the cleanups made.
  (Arnaldo)
- Add reviewed-by and tested-by from Ian and Ravi

As discussed in the below thread, the patch set is to clean up perf mem.
https://lore.kernel.org/lkml/afefab15-cffc-4345-9cf4-c6a4128d4d9c at linux.intel.com/

Introduce generic functions perf_mem_events__ptr(),
perf_mem_events__name() ,and is_mem_loads_aux_event() to replace the
ARCH specific ones.
Simplify the perf_mem_event__supported().

Only keeps the ARCH-specific perf_mem_events array in the corresponding
mem-events.c for each ARCH.

There is no functional change.

The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
etc. But I can only test it on two Intel platforms.
Please give it try, if you have machines with other ARCHs.

Here are the test results:
Intel hybrid machine:

$perf mem record -e list
ldlat-loads  : available
ldlat-stores : available

$perf mem record -e ldlat-loads -v --ldlat 50
calling: record -e cpu_atom/mem-loads,ldlat=50/P -e cpu_core/mem-loads,ldlat=50/P

$perf mem record -v
calling: record -e cpu_atom/mem-loads,ldlat=30/P -e cpu_atom/mem-stores/P -e cpu_core/mem-loads,ldlat=30/P -e cpu_core/mem-stores/P

$perf mem record -t store -v
calling: record -e cpu_atom/mem-stores/P -e cpu_core/mem-stores/P


Intel SPR:
$perf mem record -e list
ldlat-loads  : available
ldlat-stores : available

$perf mem record -e ldlat-loads -v --ldlat 50
calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=50/}:P

$perf mem record -v
calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=30/}:P -e cpu/mem-stores/P

$perf mem record -t store -v
calling: record -e cpu/mem-stores/P

Kan Liang (7):
  perf mem: Add mem_events into the supported perf_pmu
  perf mem: Clean up perf_mem_events__ptr()
  perf mem: Clean up perf_mem_events__name()
  perf mem: Clean up perf_mem_event__supported()
  perf mem: Clean up is_mem_loads_aux_event()
  perf mem: Clean up perf_mem_events__record_args()
  perf mem: Clean up perf_pmus__num_mem_pmus()

 tools/perf/arch/arm/util/pmu.c            |   3 +
 tools/perf/arch/arm64/util/mem-events.c   |  39 +---
 tools/perf/arch/arm64/util/mem-events.h   |   7 +
 tools/perf/arch/powerpc/util/mem-events.c |  13 +-
 tools/perf/arch/powerpc/util/mem-events.h |   7 +
 tools/perf/arch/powerpc/util/pmu.c        |  11 ++
 tools/perf/arch/s390/util/pmu.c           |   3 +
 tools/perf/arch/x86/util/mem-events.c     |  99 ++--------
 tools/perf/arch/x86/util/mem-events.h     |  10 +
 tools/perf/arch/x86/util/pmu.c            |  19 +-
 tools/perf/builtin-c2c.c                  |  45 ++---
 tools/perf/builtin-mem.c                  |  48 ++---
 tools/perf/util/mem-events.c              | 217 +++++++++++++---------
 tools/perf/util/mem-events.h              |  19 +-
 tools/perf/util/pmu.c                     |   4 +-
 tools/perf/util/pmu.h                     |   7 +
 tools/perf/util/pmus.c                    |   6 -
 tools/perf/util/pmus.h                    |   1 -
 18 files changed, 278 insertions(+), 280 deletions(-)
 create mode 100644 tools/perf/arch/arm64/util/mem-events.h
 create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
 create mode 100644 tools/perf/arch/powerpc/util/pmu.c
 create mode 100644 tools/perf/arch/x86/util/mem-events.h

-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec 13 11:51:48 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed, 13 Dec 2023 11:51:48 -0800
Subject: [PATCH V3 1/7] perf mem: Add mem_events into the supported perf_pmu
In-Reply-To: <20231213195154.1085945-1-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
Message-ID: <20231213195154.1085945-2-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

With the mem_events, perf doesn't need to read sysfs for each PMU to
find the mem-events-supported PMU. The patch also makes it possible to
clean up the related __weak functions later.

The patch is only to add the mem_events into the perf_pmu for all ARCHs.
It will be used in the later cleanup patches.

Reviewed-by: Ian Rogers <irogers at google.com>
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Suggested-by: Leo Yan <leo.yan at linaro.org>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm/util/pmu.c          | 3 +++
 tools/perf/arch/arm64/util/mem-events.c | 7 ++++---
 tools/perf/arch/arm64/util/mem-events.h | 7 +++++++
 tools/perf/arch/s390/util/pmu.c         | 3 +++
 tools/perf/arch/x86/util/mem-events.c   | 4 ++--
 tools/perf/arch/x86/util/mem-events.h   | 9 +++++++++
 tools/perf/arch/x86/util/pmu.c          | 7 +++++++
 tools/perf/util/mem-events.c            | 2 +-
 tools/perf/util/mem-events.h            | 1 +
 tools/perf/util/pmu.c                   | 4 +++-
 tools/perf/util/pmu.h                   | 7 +++++++
 11 files changed, 47 insertions(+), 7 deletions(-)
 create mode 100644 tools/perf/arch/arm64/util/mem-events.h
 create mode 100644 tools/perf/arch/x86/util/mem-events.h

diff --git a/tools/perf/arch/arm/util/pmu.c b/tools/perf/arch/arm/util/pmu.c
index 7f3af3b97f3b..8b7cb68ba1a8 100644
--- a/tools/perf/arch/arm/util/pmu.c
+++ b/tools/perf/arch/arm/util/pmu.c
@@ -13,6 +13,7 @@
 #include "hisi-ptt.h"
 #include "../../../util/pmu.h"
 #include "../../../util/cs-etm.h"
+#include "../../arm64/util/mem-events.h"
 
 void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
 {
@@ -26,6 +27,8 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
 		pmu->selectable = true;
 		pmu->is_uncore = false;
 		pmu->perf_event_attr_init_default = arm_spe_pmu_default_config;
+		if (!strcmp(pmu->name, "arm_spe_0"))
+			pmu->mem_events = perf_mem_events_arm;
 	} else if (strstarts(pmu->name, HISI_PTT_PMU_NAME)) {
 		pmu->selectable = true;
 #endif
diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index 3bcc5c7035c2..edf8207f7812 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -1,10 +1,11 @@
 // SPDX-License-Identifier: GPL-2.0
-#include "map_symbol.h"
+#include "util/map_symbol.h"
+#include "util/mem-events.h"
 #include "mem-events.h"
 
 #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
 
-static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
 	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
 	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
 	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
@@ -17,7 +18,7 @@ struct perf_mem_event *perf_mem_events__ptr(int i)
 	if (i >= PERF_MEM_EVENTS__MAX)
 		return NULL;
 
-	return &perf_mem_events[i];
+	return &perf_mem_events_arm[i];
 }
 
 const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
diff --git a/tools/perf/arch/arm64/util/mem-events.h b/tools/perf/arch/arm64/util/mem-events.h
new file mode 100644
index 000000000000..5fc50be4be38
--- /dev/null
+++ b/tools/perf/arch/arm64/util/mem-events.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ARM64_MEM_EVENTS_H
+#define _ARM64_MEM_EVENTS_H
+
+extern struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX];
+
+#endif /* _ARM64_MEM_EVENTS_H */
diff --git a/tools/perf/arch/s390/util/pmu.c b/tools/perf/arch/s390/util/pmu.c
index 886c30e001fa..225d7dc2379c 100644
--- a/tools/perf/arch/s390/util/pmu.c
+++ b/tools/perf/arch/s390/util/pmu.c
@@ -19,4 +19,7 @@ void perf_pmu__arch_init(struct perf_pmu *pmu)
 	    !strcmp(pmu->name, S390_PMUPAI_EXT) ||
 	    !strcmp(pmu->name, S390_PMUCPUM_CF))
 		pmu->selectable = true;
+
+	if (pmu->is_core)
+		pmu->mem_events = perf_mem_events;
 }
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 191b372f9a2d..2b81d229982c 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -16,13 +16,13 @@ static char mem_stores_name[100];
 
 #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
 
-static struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
 	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads"),
 	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores"),
 	E(NULL,			NULL,				NULL),
 };
 
-static struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
 	E(NULL,		NULL,		NULL),
 	E(NULL,		NULL,		NULL),
 	E("mem-ldst",	"ibs_op//",	"ibs_op"),
diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
new file mode 100644
index 000000000000..3959e427f482
--- /dev/null
+++ b/tools/perf/arch/x86/util/mem-events.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _X86_MEM_EVENTS_H
+#define _X86_MEM_EVENTS_H
+
+extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
+
+extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
+
+#endif /* _X86_MEM_EVENTS_H */
diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
index 469555ae9b3c..cd22e80e5657 100644
--- a/tools/perf/arch/x86/util/pmu.c
+++ b/tools/perf/arch/x86/util/pmu.c
@@ -15,6 +15,7 @@
 #include "../../../util/pmu.h"
 #include "../../../util/fncache.h"
 #include "../../../util/pmus.h"
+#include "mem-events.h"
 #include "env.h"
 
 void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
@@ -30,6 +31,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
 		pmu->selectable = true;
 	}
 #endif
+
+	if (x86__is_amd_cpu()) {
+		if (!strcmp(pmu->name, "ibs_op"))
+			pmu->mem_events = perf_mem_events_amd;
+	} else if (pmu->is_core)
+		pmu->mem_events = perf_mem_events_intel;
 }
 
 int perf_pmus__num_mem_pmus(void)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 3a2e3687878c..0a8f415f5efe 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -19,7 +19,7 @@ unsigned int perf_mem_events__loads_ldlat = 30;
 
 #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
 
-static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
+struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
 	E("ldlat-loads",	"cpu/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads"),
 	E("ldlat-stores",	"cpu/mem-stores/P",		"cpu/events/mem-stores"),
 	E(NULL,			NULL,				NULL),
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index b40ad6ea93fc..8c5694b2d0b0 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -34,6 +34,7 @@ enum {
 };
 
 extern unsigned int perf_mem_events__loads_ldlat;
+extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
 
 int perf_mem_events__parse(const char *str);
 int perf_mem_events__init(void);
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 3c9609944a2f..3d4373b8ab63 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -986,8 +986,10 @@ static int pmu_max_precise(int dirfd, struct perf_pmu *pmu)
 }
 
 void __weak
-perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
+perf_pmu__arch_init(struct perf_pmu *pmu)
 {
+	if (pmu->is_core)
+		pmu->mem_events = perf_mem_events;
 }
 
 struct perf_pmu *perf_pmu__lookup(struct list_head *pmus, int dirfd, const char *name)
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 424c3fee0949..e35d985206db 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -10,6 +10,8 @@
 #include <stdio.h>
 #include "parse-events.h"
 #include "pmu-events/pmu-events.h"
+#include "map_symbol.h"
+#include "mem-events.h"
 
 struct evsel_config_term;
 struct perf_cpu_map;
@@ -162,6 +164,11 @@ struct perf_pmu {
 		 */
 		bool exclude_guest;
 	} missing_features;
+
+	/**
+	 * @mem_events: List of the supported mem events
+	 */
+	struct perf_mem_event *mem_events;
 };
 
 /** @perf_pmu__fake: A special global PMU used for testing. */
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec 13 11:51:49 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed, 13 Dec 2023 11:51:49 -0800
Subject: [PATCH V3 2/7] perf mem: Clean up perf_mem_events__ptr()
In-Reply-To: <20231213195154.1085945-1-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
Message-ID: <20231213195154.1085945-3-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

The mem_events can be retrieved from the struct perf_pmu now. An ARCH
specific perf_mem_events__ptr() is not required anymore. Remove all of
them.

The Intel hybrid has multiple mem-events-supported PMUs. But they share
the same mem_events. Other ARCHs only support one mem-events-supported
PMU. In the configuration, it's good enough to only configure the
mem_events for one PMU. Add perf_mem_events_find_pmu() which returns the
first mem-events-supported PMU.

In the perf_mem_events__init(), the perf_pmus__scan() is not required
anymore. It avoids checking the sysfs for every PMU on the system.

Make the perf_mem_events__record_args() more generic. Remove the
perf_mem_events__print_unsupport_hybrid().

Since pmu is added as a new parameter, rename perf_mem_events__ptr() to
perf_pmu__mem_events_ptr(). Several other functions also do a similar
rename.

Reviewed-by: Ian Rogers <irogers at google.com>
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c |  10 +--
 tools/perf/arch/x86/util/mem-events.c   |  18 ++---
 tools/perf/builtin-c2c.c                |  28 +++++--
 tools/perf/builtin-mem.c                |  28 +++++--
 tools/perf/util/mem-events.c            | 103 ++++++++++++------------
 tools/perf/util/mem-events.h            |   9 ++-
 6 files changed, 104 insertions(+), 92 deletions(-)

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index edf8207f7812..d3e69a520c2b 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -13,17 +13,9 @@ struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
 
 static char mem_ev_name[100];
 
-struct perf_mem_event *perf_mem_events__ptr(int i)
-{
-	if (i >= PERF_MEM_EVENTS__MAX)
-		return NULL;
-
-	return &perf_mem_events_arm[i];
-}
-
 const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
 {
-	struct perf_mem_event *e = perf_mem_events__ptr(i);
+	struct perf_mem_event *e = &perf_mem_events_arm[i];
 
 	if (i >= PERF_MEM_EVENTS__MAX)
 		return NULL;
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 2b81d229982c..5fb41d50118d 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -28,17 +28,6 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
 	E("mem-ldst",	"ibs_op//",	"ibs_op"),
 };
 
-struct perf_mem_event *perf_mem_events__ptr(int i)
-{
-	if (i >= PERF_MEM_EVENTS__MAX)
-		return NULL;
-
-	if (x86__is_amd_cpu())
-		return &perf_mem_events_amd[i];
-
-	return &perf_mem_events_intel[i];
-}
-
 bool is_mem_loads_aux_event(struct evsel *leader)
 {
 	struct perf_pmu *pmu = perf_pmus__find("cpu");
@@ -54,7 +43,12 @@ bool is_mem_loads_aux_event(struct evsel *leader)
 
 const char *perf_mem_events__name(int i, const char *pmu_name)
 {
-	struct perf_mem_event *e = perf_mem_events__ptr(i);
+	struct perf_mem_event *e;
+
+	if (x86__is_amd_cpu())
+		e = &perf_mem_events_amd[i];
+	else
+		e = &perf_mem_events_intel[i];
 
 	if (!e)
 		return NULL;
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index f78eea9e2153..838481505e08 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -3215,12 +3215,19 @@ static int parse_record_events(const struct option *opt,
 			       const char *str, int unset __maybe_unused)
 {
 	bool *event_set = (bool *) opt->value;
+	struct perf_pmu *pmu;
+
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: there is no PMU that supports perf c2c\n");
+		exit(-1);
+	}
 
 	if (!strcmp(str, "list")) {
-		perf_mem_events__list();
+		perf_pmu__mem_events_list(pmu);
 		exit(0);
 	}
-	if (perf_mem_events__parse(str))
+	if (perf_pmu__mem_events_parse(pmu, str))
 		exit(-1);
 
 	*event_set = true;
@@ -3245,6 +3252,7 @@ static int perf_c2c__record(int argc, const char **argv)
 	bool all_user = false, all_kernel = false;
 	bool event_set = false;
 	struct perf_mem_event *e;
+	struct perf_pmu *pmu;
 	struct option options[] = {
 	OPT_CALLBACK('e', "event", &event_set, "event",
 		     "event selector. Use 'perf c2c record -e list' to list available events",
@@ -3256,7 +3264,13 @@ static int perf_c2c__record(int argc, const char **argv)
 	OPT_END()
 	};
 
-	if (perf_mem_events__init()) {
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: no PMU supports the memory events\n");
+		return -1;
+	}
+
+	if (perf_pmu__mem_events_init(pmu)) {
 		pr_err("failed: memory events not supported\n");
 		return -1;
 	}
@@ -3280,7 +3294,7 @@ static int perf_c2c__record(int argc, const char **argv)
 	rec_argv[i++] = "record";
 
 	if (!event_set) {
-		e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD_STORE);
+		e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD_STORE);
 		/*
 		 * The load and store operations are required, use the event
 		 * PERF_MEM_EVENTS__LOAD_STORE if it is supported.
@@ -3289,15 +3303,15 @@ static int perf_c2c__record(int argc, const char **argv)
 			e->record = true;
 			rec_argv[i++] = "-W";
 		} else {
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+			e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD);
 			e->record = true;
 
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__STORE);
+			e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__STORE);
 			e->record = true;
 		}
 	}
 
-	e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+	e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD);
 	if (e->record)
 		rec_argv[i++] = "-W";
 
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index 51499c20da01..ef64bae77ca7 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -43,12 +43,19 @@ static int parse_record_events(const struct option *opt,
 			       const char *str, int unset __maybe_unused)
 {
 	struct perf_mem *mem = *(struct perf_mem **)opt->value;
+	struct perf_pmu *pmu;
+
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: there is no PMU that supports perf mem\n");
+		exit(-1);
+	}
 
 	if (!strcmp(str, "list")) {
-		perf_mem_events__list();
+		perf_pmu__mem_events_list(pmu);
 		exit(0);
 	}
-	if (perf_mem_events__parse(str))
+	if (perf_pmu__mem_events_parse(pmu, str))
 		exit(-1);
 
 	mem->operation = 0;
@@ -72,6 +79,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 	int ret;
 	bool all_user = false, all_kernel = false;
 	struct perf_mem_event *e;
+	struct perf_pmu *pmu;
 	struct option options[] = {
 	OPT_CALLBACK('e', "event", &mem, "event",
 		     "event selector. use 'perf mem record -e list' to list available events",
@@ -84,7 +92,13 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 	OPT_END()
 	};
 
-	if (perf_mem_events__init()) {
+	pmu = perf_mem_events_find_pmu();
+	if (!pmu) {
+		pr_err("failed: no PMU supports the memory events\n");
+		return -1;
+	}
+
+	if (perf_pmu__mem_events_init(pmu)) {
 		pr_err("failed: memory events not supported\n");
 		return -1;
 	}
@@ -113,7 +127,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 
 	rec_argv[i++] = "record";
 
-	e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD_STORE);
+	e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD_STORE);
 
 	/*
 	 * The load and store operations are required, use the event
@@ -126,17 +140,17 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 		rec_argv[i++] = "-W";
 	} else {
 		if (mem->operation & MEM_OPERATION_LOAD) {
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+			e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD);
 			e->record = true;
 		}
 
 		if (mem->operation & MEM_OPERATION_STORE) {
-			e = perf_mem_events__ptr(PERF_MEM_EVENTS__STORE);
+			e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__STORE);
 			e->record = true;
 		}
 	}
 
-	e = perf_mem_events__ptr(PERF_MEM_EVENTS__LOAD);
+	e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD);
 	if (e->record)
 		rec_argv[i++] = "-W";
 
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 0a8f415f5efe..27a33dc44964 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -29,17 +29,42 @@ struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
 static char mem_loads_name[100];
 static bool mem_loads_name__init;
 
-struct perf_mem_event * __weak perf_mem_events__ptr(int i)
+struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i)
 {
-	if (i >= PERF_MEM_EVENTS__MAX)
+	if (i >= PERF_MEM_EVENTS__MAX || !pmu)
 		return NULL;
 
-	return &perf_mem_events[i];
+	return &pmu->mem_events[i];
+}
+
+static struct perf_pmu *perf_pmus__scan_mem(struct perf_pmu *pmu)
+{
+	while ((pmu = perf_pmus__scan(pmu)) != NULL) {
+		if (pmu->mem_events)
+			return pmu;
+	}
+	return NULL;
+}
+
+struct perf_pmu *perf_mem_events_find_pmu(void)
+{
+	/*
+	 * The current perf mem doesn't support per-PMU configuration.
+	 * The exact same configuration is applied to all the
+	 * mem_events supported PMUs.
+	 * Return the first mem_events supported PMU.
+	 *
+	 * Notes: The only case which may support multiple mem_events
+	 * supported PMUs is Intel hybrid. The exact same mem_events
+	 * is shared among the PMUs. Only configure the first PMU
+	 * is good enough as well.
+	 */
+	return perf_pmus__scan_mem(NULL);
 }
 
 const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
 {
-	struct perf_mem_event *e = perf_mem_events__ptr(i);
+	struct perf_mem_event *e = &perf_mem_events[i];
 
 	if (!e)
 		return NULL;
@@ -61,7 +86,7 @@ __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
 	return false;
 }
 
-int perf_mem_events__parse(const char *str)
+int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str)
 {
 	char *tok, *saveptr = NULL;
 	bool found = false;
@@ -79,7 +104,7 @@ int perf_mem_events__parse(const char *str)
 
 	while (tok) {
 		for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-			struct perf_mem_event *e = perf_mem_events__ptr(j);
+			struct perf_mem_event *e = perf_pmu__mem_events_ptr(pmu, j);
 
 			if (!e->tag)
 				continue;
@@ -112,7 +137,7 @@ static bool perf_mem_event__supported(const char *mnt, struct perf_pmu *pmu,
 	return !stat(path, &st);
 }
 
-int perf_mem_events__init(void)
+int perf_pmu__mem_events_init(struct perf_pmu *pmu)
 {
 	const char *mnt = sysfs__mount();
 	bool found = false;
@@ -122,8 +147,7 @@ int perf_mem_events__init(void)
 		return -ENOENT;
 
 	for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-		struct perf_mem_event *e = perf_mem_events__ptr(j);
-		struct perf_pmu *pmu = NULL;
+		struct perf_mem_event *e = perf_pmu__mem_events_ptr(pmu, j);
 
 		/*
 		 * If the event entry isn't valid, skip initialization
@@ -132,29 +156,20 @@ int perf_mem_events__init(void)
 		if (!e->tag)
 			continue;
 
-		/*
-		 * Scan all PMUs not just core ones, since perf mem/c2c on
-		 * platforms like AMD uses IBS OP PMU which is independent
-		 * of core PMU.
-		 */
-		while ((pmu = perf_pmus__scan(pmu)) != NULL) {
-			e->supported |= perf_mem_event__supported(mnt, pmu, e);
-			if (e->supported) {
-				found = true;
-				break;
-			}
-		}
+		e->supported |= perf_mem_event__supported(mnt, pmu, e);
+		if (e->supported)
+			found = true;
 	}
 
 	return found ? 0 : -ENOENT;
 }
 
-void perf_mem_events__list(void)
+void perf_pmu__mem_events_list(struct perf_pmu *pmu)
 {
 	int j;
 
 	for (j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-		struct perf_mem_event *e = perf_mem_events__ptr(j);
+		struct perf_mem_event *e = perf_pmu__mem_events_ptr(pmu, j);
 
 		fprintf(stderr, "%-*s%-*s%s",
 			e->tag ? 13 : 0,
@@ -165,50 +180,32 @@ void perf_mem_events__list(void)
 	}
 }
 
-static void perf_mem_events__print_unsupport_hybrid(struct perf_mem_event *e,
-						    int idx)
-{
-	const char *mnt = sysfs__mount();
-	struct perf_pmu *pmu = NULL;
-
-	while ((pmu = perf_pmus__scan(pmu)) != NULL) {
-		if (!perf_mem_event__supported(mnt, pmu, e)) {
-			pr_err("failed: event '%s' not supported\n",
-			       perf_mem_events__name(idx, pmu->name));
-		}
-	}
-}
-
 int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 				 char **rec_tmp, int *tmp_nr)
 {
 	const char *mnt = sysfs__mount();
+	struct perf_pmu *pmu = NULL;
 	int i = *argv_nr, k = 0;
 	struct perf_mem_event *e;
 
-	for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
-		e = perf_mem_events__ptr(j);
-		if (!e->record)
-			continue;
 
-		if (perf_pmus__num_mem_pmus() == 1) {
-			if (!e->supported) {
-				pr_err("failed: event '%s' not supported\n",
-				       perf_mem_events__name(j, NULL));
-				return -1;
-			}
+	while ((pmu = perf_pmus__scan_mem(pmu)) != NULL) {
+		for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
+			e = perf_pmu__mem_events_ptr(pmu, j);
 
-			rec_argv[i++] = "-e";
-			rec_argv[i++] = perf_mem_events__name(j, NULL);
-		} else {
-			struct perf_pmu *pmu = NULL;
+			if (!e->record)
+				continue;
 
 			if (!e->supported) {
-				perf_mem_events__print_unsupport_hybrid(e, j);
+				pr_err("failed: event '%s' not supported\n",
+					perf_mem_events__name(j, pmu->name));
 				return -1;
 			}
 
-			while ((pmu = perf_pmus__scan(pmu)) != NULL) {
+			if (perf_pmus__num_mem_pmus() == 1) {
+				rec_argv[i++] = "-e";
+				rec_argv[i++] = perf_mem_events__name(j, NULL);
+			} else {
 				const char *s = perf_mem_events__name(j, pmu->name);
 
 				if (!perf_mem_event__supported(mnt, pmu, e))
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index 8c5694b2d0b0..0ad301a2e424 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -36,14 +36,15 @@ enum {
 extern unsigned int perf_mem_events__loads_ldlat;
 extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
 
-int perf_mem_events__parse(const char *str);
-int perf_mem_events__init(void);
+int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str);
+int perf_pmu__mem_events_init(struct perf_pmu *pmu);
 
 const char *perf_mem_events__name(int i, const char *pmu_name);
-struct perf_mem_event *perf_mem_events__ptr(int i);
+struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i);
+struct perf_pmu *perf_mem_events_find_pmu(void);
 bool is_mem_loads_aux_event(struct evsel *leader);
 
-void perf_mem_events__list(void);
+void perf_pmu__mem_events_list(struct perf_pmu *pmu);
 int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 				 char **rec_tmp, int *tmp_nr);
 
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec 13 11:51:50 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed, 13 Dec 2023 11:51:50 -0800
Subject: [PATCH V3 3/7] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <20231213195154.1085945-1-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
Message-ID: <20231213195154.1085945-4-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

Introduce a generic perf_mem_events__name(). Remove the ARCH-specific
one.

The mem_load events may have a different format. Add ldlat and aux_event
in the struct perf_mem_event to indicate the format and the extra aux
event.

Add perf_mem_events_intel_aux[] to support the extra mem_load_aux event.

Rename perf_mem_events__name to perf_pmu__mem_events_name.

Reviewed-by: Ian Rogers <irogers at google.com>
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c   | 26 ++-------
 tools/perf/arch/powerpc/util/mem-events.c | 13 ++---
 tools/perf/arch/powerpc/util/mem-events.h |  7 +++
 tools/perf/arch/powerpc/util/pmu.c        | 11 ++++
 tools/perf/arch/x86/util/mem-events.c     | 70 +++++------------------
 tools/perf/arch/x86/util/mem-events.h     |  1 +
 tools/perf/arch/x86/util/pmu.c            |  8 ++-
 tools/perf/util/mem-events.c              | 60 +++++++++++++------
 tools/perf/util/mem-events.h              |  3 +-
 9 files changed, 93 insertions(+), 106 deletions(-)
 create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
 create mode 100644 tools/perf/arch/powerpc/util/pmu.c

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index d3e69a520c2b..96460c46640a 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -3,28 +3,10 @@
 #include "util/mem-events.h"
 #include "mem-events.h"
 
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
-	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
-	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
-	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
+	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0",	true,	0),
+	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0",	false,	0),
+	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0",	true,	0),
 };
-
-static char mem_ev_name[100];
-
-const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
-{
-	struct perf_mem_event *e = &perf_mem_events_arm[i];
-
-	if (i >= PERF_MEM_EVENTS__MAX)
-		return NULL;
-
-	if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE)
-		scnprintf(mem_ev_name, sizeof(mem_ev_name),
-			  e->name, perf_mem_events__loads_ldlat);
-	else /* PERF_MEM_EVENTS__STORE */
-		scnprintf(mem_ev_name, sizeof(mem_ev_name), e->name);
-
-	return mem_ev_name;
-}
diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
index 78b986e5268d..b7883e38950f 100644
--- a/tools/perf/arch/powerpc/util/mem-events.c
+++ b/tools/perf/arch/powerpc/util/mem-events.c
@@ -2,11 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-/* PowerPC does not support 'ldlat' parameter. */
-const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
-{
-	if (i == PERF_MEM_EVENTS__LOAD)
-		return "cpu/mem-loads/";
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
-	return "cpu/mem-stores/";
-}
+struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
+	E("ldlat-loads",	"%s/mem-loads/",	"cpu/events/mem-loads",		false,	0),
+	E("ldlat-stores",	"%s/mem-stores/",	"cpu/events/mem-stores",	false,	0),
+	E(NULL,			NULL,			NULL,				false,	0),
+};
diff --git a/tools/perf/arch/powerpc/util/mem-events.h b/tools/perf/arch/powerpc/util/mem-events.h
new file mode 100644
index 000000000000..6acc3d1b6873
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/mem-events.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _POWER_MEM_EVENTS_H
+#define _POWER_MEM_EVENTS_H
+
+extern struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX];
+
+#endif /* _POWER_MEM_EVENTS_H */
diff --git a/tools/perf/arch/powerpc/util/pmu.c b/tools/perf/arch/powerpc/util/pmu.c
new file mode 100644
index 000000000000..168173f88ddb
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/pmu.c
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <string.h>
+
+#include "../../../util/pmu.h"
+
+void perf_pmu__arch_init(struct perf_pmu *pmu)
+{
+	if (pmu->is_core)
+		pmu->mem_events = perf_mem_events_power;
+}
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index 5fb41d50118d..f0e66a0151a0 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -7,25 +7,26 @@
 #include "linux/string.h"
 #include "env.h"
 
-static char mem_loads_name[100];
-static bool mem_loads_name__init;
-static char mem_stores_name[100];
-
 #define MEM_LOADS_AUX		0x8203
-#define MEM_LOADS_AUX_NAME     "{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P"
 
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads"),
-	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores"),
-	E(NULL,			NULL,				NULL),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads",	true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,			false,	0),
+};
+
+struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
+	E("ldlat-loads",	"{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P",	"%s/events/mem-loads",	true,	MEM_LOADS_AUX),
+	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,			false,	0),
 };
 
 struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
-	E(NULL,		NULL,		NULL),
-	E(NULL,		NULL,		NULL),
-	E("mem-ldst",	"ibs_op//",	"ibs_op"),
+	E(NULL,		NULL,		NULL,		false,	0),
+	E(NULL,		NULL,		NULL,		false,	0),
+	E("mem-ldst",	"%s//",		"ibs_op",	false,	0),
 };
 
 bool is_mem_loads_aux_event(struct evsel *leader)
@@ -40,48 +41,3 @@ bool is_mem_loads_aux_event(struct evsel *leader)
 
 	return leader->core.attr.config == MEM_LOADS_AUX;
 }
-
-const char *perf_mem_events__name(int i, const char *pmu_name)
-{
-	struct perf_mem_event *e;
-
-	if (x86__is_amd_cpu())
-		e = &perf_mem_events_amd[i];
-	else
-		e = &perf_mem_events_intel[i];
-
-	if (!e)
-		return NULL;
-
-	if (i == PERF_MEM_EVENTS__LOAD) {
-		if (mem_loads_name__init && !pmu_name)
-			return mem_loads_name;
-
-		if (!pmu_name) {
-			mem_loads_name__init = true;
-			pmu_name = "cpu";
-		}
-
-		if (perf_pmus__have_event(pmu_name, "mem-loads-aux")) {
-			scnprintf(mem_loads_name, sizeof(mem_loads_name),
-				  MEM_LOADS_AUX_NAME, pmu_name, pmu_name,
-				  perf_mem_events__loads_ldlat);
-		} else {
-			scnprintf(mem_loads_name, sizeof(mem_loads_name),
-				  e->name, pmu_name,
-				  perf_mem_events__loads_ldlat);
-		}
-		return mem_loads_name;
-	}
-
-	if (i == PERF_MEM_EVENTS__STORE) {
-		if (!pmu_name)
-			pmu_name = "cpu";
-
-		scnprintf(mem_stores_name, sizeof(mem_stores_name),
-			  e->name, pmu_name);
-		return mem_stores_name;
-	}
-
-	return e->name;
-}
diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
index 3959e427f482..f55c8d3b7d59 100644
--- a/tools/perf/arch/x86/util/mem-events.h
+++ b/tools/perf/arch/x86/util/mem-events.h
@@ -3,6 +3,7 @@
 #define _X86_MEM_EVENTS_H
 
 extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
+extern struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX];
 
 extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
 
diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
index cd22e80e5657..0f49ff13cfe2 100644
--- a/tools/perf/arch/x86/util/pmu.c
+++ b/tools/perf/arch/x86/util/pmu.c
@@ -35,8 +35,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
 	if (x86__is_amd_cpu()) {
 		if (!strcmp(pmu->name, "ibs_op"))
 			pmu->mem_events = perf_mem_events_amd;
-	} else if (pmu->is_core)
-		pmu->mem_events = perf_mem_events_intel;
+	} else if (pmu->is_core) {
+		if (perf_pmu__have_event(pmu, "mem-loads-aux"))
+			pmu->mem_events = perf_mem_events_intel_aux;
+		else
+			pmu->mem_events = perf_mem_events_intel;
+	}
 }
 
 int perf_pmus__num_mem_pmus(void)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 27a33dc44964..51e53e33df03 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -17,17 +17,17 @@
 
 unsigned int perf_mem_events__loads_ldlat = 30;
 
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"cpu/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads"),
-	E("ldlat-stores",	"cpu/mem-stores/P",		"cpu/events/mem-stores"),
-	E(NULL,			NULL,				NULL),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads",		true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"cpu/events/mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,				false,	0),
 };
 #undef E
 
 static char mem_loads_name[100];
-static bool mem_loads_name__init;
+static char mem_stores_name[100];
 
 struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i)
 {
@@ -62,23 +62,49 @@ struct perf_pmu *perf_mem_events_find_pmu(void)
 	return perf_pmus__scan_mem(NULL);
 }
 
-const char * __weak perf_mem_events__name(int i, const char *pmu_name  __maybe_unused)
+static const char *perf_pmu__mem_events_name(int i, struct perf_pmu *pmu)
 {
-	struct perf_mem_event *e = &perf_mem_events[i];
+	struct perf_mem_event *e;
 
+	if (i >= PERF_MEM_EVENTS__MAX || !pmu)
+		return NULL;
+
+	e = &pmu->mem_events[i];
 	if (!e)
 		return NULL;
 
-	if (i == PERF_MEM_EVENTS__LOAD) {
-		if (!mem_loads_name__init) {
-			mem_loads_name__init = true;
-			scnprintf(mem_loads_name, sizeof(mem_loads_name),
-				  e->name, perf_mem_events__loads_ldlat);
+	if (i == PERF_MEM_EVENTS__LOAD || i == PERF_MEM_EVENTS__LOAD_STORE) {
+		if (e->ldlat) {
+			if (!e->aux_event) {
+				/* ARM and Most of Intel */
+				scnprintf(mem_loads_name, sizeof(mem_loads_name),
+					  e->name, pmu->name,
+					  perf_mem_events__loads_ldlat);
+			} else {
+				/* Intel with mem-loads-aux event */
+				scnprintf(mem_loads_name, sizeof(mem_loads_name),
+					  e->name, pmu->name, pmu->name,
+					  perf_mem_events__loads_ldlat);
+			}
+		} else {
+			if (!e->aux_event) {
+				/* AMD and POWER */
+				scnprintf(mem_loads_name, sizeof(mem_loads_name),
+					  e->name, pmu->name);
+			} else
+				return NULL;
 		}
+
 		return mem_loads_name;
 	}
 
-	return e->name;
+	if (i == PERF_MEM_EVENTS__STORE) {
+		scnprintf(mem_stores_name, sizeof(mem_stores_name),
+			  e->name, pmu->name);
+		return mem_stores_name;
+	}
+
+	return NULL;
 }
 
 __weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
@@ -175,7 +201,7 @@ void perf_pmu__mem_events_list(struct perf_pmu *pmu)
 			e->tag ? 13 : 0,
 			e->tag ? : "",
 			e->tag && verbose > 0 ? 25 : 0,
-			e->tag && verbose > 0 ? perf_mem_events__name(j, NULL) : "",
+			e->tag && verbose > 0 ? perf_pmu__mem_events_name(j, pmu) : "",
 			e->supported ? ": available\n" : "");
 	}
 }
@@ -198,15 +224,15 @@ int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 
 			if (!e->supported) {
 				pr_err("failed: event '%s' not supported\n",
-					perf_mem_events__name(j, pmu->name));
+					perf_pmu__mem_events_name(j, pmu));
 				return -1;
 			}
 
 			if (perf_pmus__num_mem_pmus() == 1) {
 				rec_argv[i++] = "-e";
-				rec_argv[i++] = perf_mem_events__name(j, NULL);
+				rec_argv[i++] = perf_pmu__mem_events_name(j, pmu);
 			} else {
-				const char *s = perf_mem_events__name(j, pmu->name);
+				const char *s = perf_pmu__mem_events_name(j, pmu);
 
 				if (!perf_mem_event__supported(mnt, pmu, e))
 					continue;
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index 0ad301a2e424..79d342768d12 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -14,6 +14,8 @@
 struct perf_mem_event {
 	bool		record;
 	bool		supported;
+	bool		ldlat;
+	u32		aux_event;
 	const char	*tag;
 	const char	*name;
 	const char	*sysfs_name;
@@ -39,7 +41,6 @@ extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
 int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str);
 int perf_pmu__mem_events_init(struct perf_pmu *pmu);
 
-const char *perf_mem_events__name(int i, const char *pmu_name);
 struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i);
 struct perf_pmu *perf_mem_events_find_pmu(void);
 bool is_mem_loads_aux_event(struct evsel *leader);
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec 13 11:51:51 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed, 13 Dec 2023 11:51:51 -0800
Subject: [PATCH V3 4/7] perf mem: Clean up perf_mem_event__supported()
In-Reply-To: <20231213195154.1085945-1-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
Message-ID: <20231213195154.1085945-5-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

For some ARCHs, e.g., ARM and AMD, to get the availability of the
mem-events, perf checks the existence of a specific PMU. For the other
ARCHs, e.g., Intel and Power, perf has to check the existence of some
specific events.

The current perf only iterates the mem-events-supported PMUs. It's not
required to check the existence of a specific PMU anymore.

Rename sysfs_name to event_name, which stores the specific mem-events.
Perf only needs to check those events for the availability of the
mem-events.

Rename perf_mem_event__supported to perf_pmu__mem_events_supported.

Reviewed-by: Ian Rogers <irogers at google.com>
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/arm64/util/mem-events.c   |  8 ++++----
 tools/perf/arch/powerpc/util/mem-events.c |  8 ++++----
 tools/perf/arch/x86/util/mem-events.c     | 20 ++++++++++----------
 tools/perf/util/mem-events.c              | 22 ++++++++++++----------
 tools/perf/util/mem-events.h              |  2 +-
 5 files changed, 31 insertions(+), 29 deletions(-)

diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
index 96460c46640a..9f8da7937255 100644
--- a/tools/perf/arch/arm64/util/mem-events.c
+++ b/tools/perf/arch/arm64/util/mem-events.c
@@ -3,10 +3,10 @@
 #include "util/mem-events.h"
 #include "mem-events.h"
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
-	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0",	true,	0),
-	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0",	false,	0),
-	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0",	true,	0),
+	E("spe-load",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	NULL,	true,	0),
+	E("spe-store",	"%s/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			NULL,	false,	0),
+	E("spe-ldst",	"%s/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	NULL,	true,	0),
 };
diff --git a/tools/perf/arch/powerpc/util/mem-events.c b/tools/perf/arch/powerpc/util/mem-events.c
index b7883e38950f..72a6ac2b52f5 100644
--- a/tools/perf/arch/powerpc/util/mem-events.c
+++ b/tools/perf/arch/powerpc/util/mem-events.c
@@ -2,10 +2,10 @@
 #include "map_symbol.h"
 #include "mem-events.h"
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_power[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads/",	"cpu/events/mem-loads",		false,	0),
-	E("ldlat-stores",	"%s/mem-stores/",	"cpu/events/mem-stores",	false,	0),
-	E(NULL,			NULL,			NULL,				false,	0),
+	E("ldlat-loads",	"%s/mem-loads/",	"mem-loads",	false,	0),
+	E("ldlat-stores",	"%s/mem-stores/",	"mem-stores",	false,	0),
+	E(NULL,			NULL,			NULL,		false,	0),
 };
diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index f0e66a0151a0..b776d849fc64 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -9,24 +9,24 @@
 
 #define MEM_LOADS_AUX		0x8203
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads",	true,	0),
-	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
-	E(NULL,			NULL,				NULL,			false,	0),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"mem-loads",	true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,		false,	0),
 };
 
 struct perf_mem_event perf_mem_events_intel_aux[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P",	"%s/events/mem-loads",	true,	MEM_LOADS_AUX),
-	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores",	false,	0),
-	E(NULL,			NULL,				NULL,			false,	0),
+	E("ldlat-loads",	"{%s/mem-loads-aux/,%s/mem-loads,ldlat=%u/}:P",	"mem-loads",	true,	MEM_LOADS_AUX),
+	E("ldlat-stores",	"%s/mem-stores/P",		"mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,		false,	0),
 };
 
 struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
-	E(NULL,		NULL,		NULL,		false,	0),
-	E(NULL,		NULL,		NULL,		false,	0),
-	E("mem-ldst",	"%s//",		"ibs_op",	false,	0),
+	E(NULL,		NULL,		NULL,	false,	0),
+	E(NULL,		NULL,		NULL,	false,	0),
+	E("mem-ldst",	"%s//",		NULL,	false,	0),
 };
 
 bool is_mem_loads_aux_event(struct evsel *leader)
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 51e53e33df03..32890848bb3d 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -17,12 +17,12 @@
 
 unsigned int perf_mem_events__loads_ldlat = 30;
 
-#define E(t, n, s, l, a) { .tag = t, .name = n, .sysfs_name = s, .ldlat = l, .aux_event = a }
+#define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat = l, .aux_event = a }
 
 struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
-	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads",		true,	0),
-	E("ldlat-stores",	"%s/mem-stores/P",		"cpu/events/mem-stores",	false,	0),
-	E(NULL,			NULL,				NULL,				false,	0),
+	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"mem-loads",	true,	0),
+	E("ldlat-stores",	"%s/mem-stores/P",		"mem-stores",	false,	0),
+	E(NULL,			NULL,				NULL,		false,	0),
 };
 #undef E
 
@@ -151,15 +151,17 @@ int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str)
 	return -1;
 }
 
-static bool perf_mem_event__supported(const char *mnt, struct perf_pmu *pmu,
+static bool perf_pmu__mem_events_supported(const char *mnt, struct perf_pmu *pmu,
 				      struct perf_mem_event *e)
 {
-	char sysfs_name[100];
 	char path[PATH_MAX];
 	struct stat st;
 
-	scnprintf(sysfs_name, sizeof(sysfs_name), e->sysfs_name, pmu->name);
-	scnprintf(path, PATH_MAX, "%s/devices/%s", mnt, sysfs_name);
+	if (!e->event_name)
+		return true;
+
+	scnprintf(path, PATH_MAX, "%s/devices/%s/events/%s", mnt, pmu->name, e->event_name);
+
 	return !stat(path, &st);
 }
 
@@ -182,7 +184,7 @@ int perf_pmu__mem_events_init(struct perf_pmu *pmu)
 		if (!e->tag)
 			continue;
 
-		e->supported |= perf_mem_event__supported(mnt, pmu, e);
+		e->supported |= perf_pmu__mem_events_supported(mnt, pmu, e);
 		if (e->supported)
 			found = true;
 	}
@@ -234,7 +236,7 @@ int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 			} else {
 				const char *s = perf_pmu__mem_events_name(j, pmu);
 
-				if (!perf_mem_event__supported(mnt, pmu, e))
+				if (!perf_pmu__mem_events_supported(mnt, pmu, e))
 					continue;
 
 				rec_argv[i++] = "-e";
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index 79d342768d12..f817a507b106 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -18,7 +18,7 @@ struct perf_mem_event {
 	u32		aux_event;
 	const char	*tag;
 	const char	*name;
-	const char	*sysfs_name;
+	const char	*event_name;
 };
 
 struct mem_info {
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec 13 11:51:52 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed, 13 Dec 2023 11:51:52 -0800
Subject: [PATCH V3 5/7] perf mem: Clean up is_mem_loads_aux_event()
In-Reply-To: <20231213195154.1085945-1-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
Message-ID: <20231213195154.1085945-6-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

The aux_event can be retrieved from the perf_pmu now. Implement a
generic support.

Reviewed-by: Ian Rogers <irogers at google.com>
Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/x86/util/mem-events.c | 23 ++++-------------------
 tools/perf/util/mem-events.c          | 14 ++++++++++++--
 2 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
index b776d849fc64..62df03e91c7e 100644
--- a/tools/perf/arch/x86/util/mem-events.c
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -1,11 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
-#include "util/pmu.h"
-#include "util/pmus.h"
-#include "util/env.h"
-#include "map_symbol.h"
-#include "mem-events.h"
 #include "linux/string.h"
-#include "env.h"
+#include "util/map_symbol.h"
+#include "util/mem-events.h"
+#include "mem-events.h"
+
 
 #define MEM_LOADS_AUX		0x8203
 
@@ -28,16 +26,3 @@ struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
 	E(NULL,		NULL,		NULL,	false,	0),
 	E("mem-ldst",	"%s//",		NULL,	false,	0),
 };
-
-bool is_mem_loads_aux_event(struct evsel *leader)
-{
-	struct perf_pmu *pmu = perf_pmus__find("cpu");
-
-	if (!pmu)
-		pmu = perf_pmus__find("cpu_core");
-
-	if (pmu && !perf_pmu__have_event(pmu, "mem-loads-aux"))
-		return false;
-
-	return leader->core.attr.config == MEM_LOADS_AUX;
-}
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 32890848bb3d..7d7df3d0b2b9 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -107,9 +107,19 @@ static const char *perf_pmu__mem_events_name(int i, struct perf_pmu *pmu)
 	return NULL;
 }
 
-__weak bool is_mem_loads_aux_event(struct evsel *leader __maybe_unused)
+bool is_mem_loads_aux_event(struct evsel *leader)
 {
-	return false;
+	struct perf_pmu *pmu = leader->pmu;
+	struct perf_mem_event *e;
+
+	if (!pmu || !pmu->mem_events)
+		return false;
+
+	e = &pmu->mem_events[PERF_MEM_EVENTS__LOAD];
+	if (!e->aux_event)
+		return false;
+
+	return leader->core.attr.config == e->aux_event;
 }
 
 int perf_pmu__mem_events_parse(struct perf_pmu *pmu, const char *str)
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec 13 11:51:53 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed, 13 Dec 2023 11:51:53 -0800
Subject: [PATCH V3 6/7] perf mem: Clean up perf_mem_events__record_args()
In-Reply-To: <20231213195154.1085945-1-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
Message-ID: <20231213195154.1085945-7-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

The current code iterates all memory PMUs. It doesn't matter if the
system has only one memory PMU or multiple PMUs. The check of
perf_pmus__num_mem_pmus() is not required anymore.

The rec_tmp is not used in c2c and mem. Removing them as well.

Suggested-by: Leo Yan <leo.yan at linaro.org>
Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/builtin-c2c.c     | 15 ++-------------
 tools/perf/builtin-mem.c     | 18 ++----------------
 tools/perf/util/mem-events.c | 34 ++++++++++++----------------------
 tools/perf/util/mem-events.h |  3 +--
 4 files changed, 17 insertions(+), 53 deletions(-)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 838481505e08..3bcb903b6b38 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -3245,9 +3245,8 @@ static const char * const *record_mem_usage = __usage_record;
 
 static int perf_c2c__record(int argc, const char **argv)
 {
-	int rec_argc, i = 0, j, rec_tmp_nr = 0;
+	int rec_argc, i = 0, j;
 	const char **rec_argv;
-	char **rec_tmp;
 	int ret;
 	bool all_user = false, all_kernel = false;
 	bool event_set = false;
@@ -3285,12 +3284,6 @@ static int perf_c2c__record(int argc, const char **argv)
 	if (!rec_argv)
 		return -1;
 
-	rec_tmp = calloc(rec_argc + 1, sizeof(char *));
-	if (!rec_tmp) {
-		free(rec_argv);
-		return -1;
-	}
-
 	rec_argv[i++] = "record";
 
 	if (!event_set) {
@@ -3319,7 +3312,7 @@ static int perf_c2c__record(int argc, const char **argv)
 	rec_argv[i++] = "--phys-data";
 	rec_argv[i++] = "--sample-cpu";
 
-	ret = perf_mem_events__record_args(rec_argv, &i, rec_tmp, &rec_tmp_nr);
+	ret = perf_mem_events__record_args(rec_argv, &i);
 	if (ret)
 		goto out;
 
@@ -3346,10 +3339,6 @@ static int perf_c2c__record(int argc, const char **argv)
 
 	ret = cmd_record(i, rec_argv);
 out:
-	for (i = 0; i < rec_tmp_nr; i++)
-		free(rec_tmp[i]);
-
-	free(rec_tmp);
 	free(rec_argv);
 	return ret;
 }
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index ef64bae77ca7..1d92e309c97c 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -72,10 +72,9 @@ static const char * const *record_mem_usage = __usage;
 
 static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 {
-	int rec_argc, i = 0, j, tmp_nr = 0;
+	int rec_argc, i = 0, j;
 	int start, end;
 	const char **rec_argv;
-	char **rec_tmp;
 	int ret;
 	bool all_user = false, all_kernel = false;
 	struct perf_mem_event *e;
@@ -116,15 +115,6 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 	if (!rec_argv)
 		return -1;
 
-	/*
-	 * Save the allocated event name strings.
-	 */
-	rec_tmp = calloc(rec_argc + 1, sizeof(char *));
-	if (!rec_tmp) {
-		free(rec_argv);
-		return -1;
-	}
-
 	rec_argv[i++] = "record";
 
 	e = perf_pmu__mem_events_ptr(pmu, PERF_MEM_EVENTS__LOAD_STORE);
@@ -163,7 +153,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 		rec_argv[i++] = "--data-page-size";
 
 	start = i;
-	ret = perf_mem_events__record_args(rec_argv, &i, rec_tmp, &tmp_nr);
+	ret = perf_mem_events__record_args(rec_argv, &i);
 	if (ret)
 		goto out;
 	end = i;
@@ -193,10 +183,6 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 
 	ret = cmd_record(i, rec_argv);
 out:
-	for (i = 0; i < tmp_nr; i++)
-		free(rec_tmp[i]);
-
-	free(rec_tmp);
 	free(rec_argv);
 	return ret;
 }
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 7d7df3d0b2b9..a20611b4fb1b 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -218,14 +218,14 @@ void perf_pmu__mem_events_list(struct perf_pmu *pmu)
 	}
 }
 
-int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
-				 char **rec_tmp, int *tmp_nr)
+int perf_mem_events__record_args(const char **rec_argv, int *argv_nr)
 {
 	const char *mnt = sysfs__mount();
 	struct perf_pmu *pmu = NULL;
-	int i = *argv_nr, k = 0;
 	struct perf_mem_event *e;
-
+	int i = *argv_nr;
+	const char *s;
+	char *copy;
 
 	while ((pmu = perf_pmus__scan_mem(pmu)) != NULL) {
 		for (int j = 0; j < PERF_MEM_EVENTS__MAX; j++) {
@@ -240,30 +240,20 @@ int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
 				return -1;
 			}
 
-			if (perf_pmus__num_mem_pmus() == 1) {
-				rec_argv[i++] = "-e";
-				rec_argv[i++] = perf_pmu__mem_events_name(j, pmu);
-			} else {
-				const char *s = perf_pmu__mem_events_name(j, pmu);
-
-				if (!perf_pmu__mem_events_supported(mnt, pmu, e))
-					continue;
+			s = perf_pmu__mem_events_name(j, pmu);
+			if (!s || !perf_pmu__mem_events_supported(mnt, pmu, e))
+				continue;
 
-				rec_argv[i++] = "-e";
-				if (s) {
-					char *copy = strdup(s);
-					if (!copy)
-						return -1;
+			copy = strdup(s);
+			if (!copy)
+				return -1;
 
-					rec_argv[i++] = copy;
-					rec_tmp[k++] = copy;
-				}
-			}
+			rec_argv[i++] = "-e";
+			rec_argv[i++] = copy;
 		}
 	}
 
 	*argv_nr = i;
-	*tmp_nr = k;
 	return 0;
 }
 
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index f817a507b106..c97cd3caa766 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -46,8 +46,7 @@ struct perf_pmu *perf_mem_events_find_pmu(void);
 bool is_mem_loads_aux_event(struct evsel *leader);
 
 void perf_pmu__mem_events_list(struct perf_pmu *pmu);
-int perf_mem_events__record_args(const char **rec_argv, int *argv_nr,
-				 char **rec_tmp, int *tmp_nr);
+int perf_mem_events__record_args(const char **rec_argv, int *argv_nr);
 
 int perf_mem__tlb_scnprintf(char *out, size_t sz, struct mem_info *mem_info);
 int perf_mem__lvl_scnprintf(char *out, size_t sz, struct mem_info *mem_info);
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec 13 11:51:54 2023
From: kan.liang at linux.intel.com (kan.liang at linux.intel.com)
Date: Wed, 13 Dec 2023 11:51:54 -0800
Subject: [PATCH V3 7/7] perf mem: Clean up perf_pmus__num_mem_pmus()
In-Reply-To: <20231213195154.1085945-1-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
Message-ID: <20231213195154.1085945-8-kan.liang@linux.intel.com>

From: Kan Liang <kan.liang at linux.intel.com>

The number of mem PMUs can be calculated by searching the
perf_pmus__scan_mem().

Remove the ARCH specific perf_pmus__num_mem_pmus()

Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
---
 tools/perf/arch/x86/util/pmu.c | 10 ----------
 tools/perf/builtin-c2c.c       |  2 +-
 tools/perf/builtin-mem.c       |  2 +-
 tools/perf/util/mem-events.c   | 14 ++++++++++++++
 tools/perf/util/mem-events.h   |  1 +
 tools/perf/util/pmus.c         |  6 ------
 tools/perf/util/pmus.h         |  1 -
 7 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
index 0f49ff13cfe2..c3d89d6ba1bf 100644
--- a/tools/perf/arch/x86/util/pmu.c
+++ b/tools/perf/arch/x86/util/pmu.c
@@ -42,13 +42,3 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
 			pmu->mem_events = perf_mem_events_intel;
 	}
 }
-
-int perf_pmus__num_mem_pmus(void)
-{
-	/* AMD uses IBS OP pmu and not a core PMU for perf mem/c2c */
-	if (x86__is_amd_cpu())
-		return 1;
-
-	/* Intel uses core pmus for perf mem/c2c */
-	return perf_pmus__num_core_pmus();
-}
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 3bcb903b6b38..16b40f5d43db 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -3278,7 +3278,7 @@ static int perf_c2c__record(int argc, const char **argv)
 			     PARSE_OPT_KEEP_UNKNOWN);
 
 	/* Max number of arguments multiplied by number of PMUs that can support them. */
-	rec_argc = argc + 11 * perf_pmus__num_mem_pmus();
+	rec_argc = argc + 11 * (perf_pmu__mem_events_num_mem_pmus(pmu) + 1);
 
 	rec_argv = calloc(rec_argc + 1, sizeof(char *));
 	if (!rec_argv)
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index 1d92e309c97c..5b851e64e4a1 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -106,7 +106,7 @@ static int __cmd_record(int argc, const char **argv, struct perf_mem *mem)
 			     PARSE_OPT_KEEP_UNKNOWN);
 
 	/* Max number of arguments multiplied by number of PMUs that can support them. */
-	rec_argc = argc + 9 * perf_pmus__num_mem_pmus();
+	rec_argc = argc + 9 * (perf_pmu__mem_events_num_mem_pmus(pmu) + 1);
 
 	if (mem->cpu_list)
 		rec_argc += 2;
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index a20611b4fb1b..637cbd4a7bfb 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -62,6 +62,20 @@ struct perf_pmu *perf_mem_events_find_pmu(void)
 	return perf_pmus__scan_mem(NULL);
 }
 
+/**
+ * perf_pmu__mem_events_num_mem_pmus - Get the number of mem PMUs since the given pmu
+ * @pmu: Start pmu. If it's NULL, search the entire PMU list.
+ */
+int perf_pmu__mem_events_num_mem_pmus(struct perf_pmu *pmu)
+{
+	int num = 0;
+
+	while ((pmu = perf_pmus__scan_mem(pmu)) != NULL)
+		num++;
+
+	return num;
+}
+
 static const char *perf_pmu__mem_events_name(int i, struct perf_pmu *pmu)
 {
 	struct perf_mem_event *e;
diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
index c97cd3caa766..15d5f0320d27 100644
--- a/tools/perf/util/mem-events.h
+++ b/tools/perf/util/mem-events.h
@@ -43,6 +43,7 @@ int perf_pmu__mem_events_init(struct perf_pmu *pmu);
 
 struct perf_mem_event *perf_pmu__mem_events_ptr(struct perf_pmu *pmu, int i);
 struct perf_pmu *perf_mem_events_find_pmu(void);
+int perf_pmu__mem_events_num_mem_pmus(struct perf_pmu *pmu);
 bool is_mem_loads_aux_event(struct evsel *leader);
 
 void perf_pmu__mem_events_list(struct perf_pmu *pmu);
diff --git a/tools/perf/util/pmus.c b/tools/perf/util/pmus.c
index ce4931461741..16505071d362 100644
--- a/tools/perf/util/pmus.c
+++ b/tools/perf/util/pmus.c
@@ -345,12 +345,6 @@ const struct perf_pmu *perf_pmus__pmu_for_pmu_filter(const char *str)
 	return NULL;
 }
 
-int __weak perf_pmus__num_mem_pmus(void)
-{
-	/* All core PMUs are for mem events. */
-	return perf_pmus__num_core_pmus();
-}
-
 /** Struct for ordering events as output in perf list. */
 struct sevent {
 	/** PMU for event. */
diff --git a/tools/perf/util/pmus.h b/tools/perf/util/pmus.h
index 4c67153ac257..94d2a08d894b 100644
--- a/tools/perf/util/pmus.h
+++ b/tools/perf/util/pmus.h
@@ -17,7 +17,6 @@ struct perf_pmu *perf_pmus__scan_core(struct perf_pmu *pmu);
 
 const struct perf_pmu *perf_pmus__pmu_for_pmu_filter(const char *str);
 
-int perf_pmus__num_mem_pmus(void);
 void perf_pmus__print_pmu_events(const struct print_callbacks *print_cb, void *print_state);
 bool perf_pmus__have_event(const char *pname, const char *name);
 int perf_pmus__num_core_pmus(void);
-- 
2.35.1



From kan.liang at linux.intel.com  Wed Dec 13 11:54:36 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Wed, 13 Dec 2023 14:54:36 -0500
Subject: [PATCH V2 0/5] Clean up perf mem
In-Reply-To: <DC029166-B60F-4E90-833D-F43818A3C54B@linux.vnet.ibm.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <ZXIrtcYkvpA8Uwj1@kernel.org>
 <DC029166-B60F-4E90-833D-F43818A3C54B@linux.vnet.ibm.com>
Message-ID: <ab50cc75-2273-47a3-a0c3-fa2d8f1d2fd3@linux.intel.com>



On 2023-12-13 4:51 a.m., Athira Rajeev wrote:
> 
> 
>> On 08-Dec-2023, at 2:01?AM, Arnaldo Carvalho de Melo <acme at kernel.org> wrote:
>>
>> Em Thu, Dec 07, 2023 at 11:23:33AM -0800, kan.liang at linux.intel.com escreveu:
>>> From: Kan Liang <kan.liang at linux.intel.com>
>>>
>>> Changes since V1:
>>> - Fix strcmp of PMU name checking (Ravi)
>>> - Fix "/," typo (Ian)
>>> - Rename several functions with perf_pmu__mem_events prefix. (Ian)
>>> - Fold the header removal patch into the patch where the cleanups made.
>>>  (Arnaldo)
>>> - Add reviewed-by and tested-by from Ian and Ravi
>>
>> It would be good to have a Tested-by from people working in all the
>> architectures affectes, like we got from Ravi for AMD, can we get those?
>>
>> I'm applying it locally for test building, will push to
>> perf-tools-next/tmp.perf-tools-next for a while, so there is some time
>> to test.
>>
>> ARM64 (Leo?) and ppc, for PPC... humm Ravi did it, who could test it now?
> Hi Arnaldo, Ravi
> 
> Looking into this for testing on powerpc. Will update back.
>

Thanks Athira. I've sent out the latest V3. Please give it a try.

https://lore.kernel.org/lkml/20231213195154.1085945-1-kan.liang at linux.intel.com/

Thanks,
Kan

> Thanks
> Athira
>>
>> - Arnaldo
>>
>>> As discussed in the below thread, the patch set is to clean up perf mem.
>>> https://lore.kernel.org/lkml/afefab15-cffc-4345-9cf4-c6a4128d4d9c at linux.intel.com/
>>>
>>> Introduce generic functions perf_mem_events__ptr(),
>>> perf_mem_events__name() ,and is_mem_loads_aux_event() to replace the
>>> ARCH specific ones.
>>> Simplify the perf_mem_event__supported().
>>>
>>> Only keeps the ARCH-specific perf_mem_events array in the corresponding
>>> mem-events.c for each ARCH.
>>>
>>> There is no functional change.
>>>
>>> The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
>>> etc. But I can only test it on two Intel platforms.
>>> Please give it try, if you have machines with other ARCHs.
>>>
>>> Here are the test results:
>>> Intel hybrid machine:
>>>
>>> $perf mem record -e list
>>> ldlat-loads  : available
>>> ldlat-stores : available
>>>
>>> $perf mem record -e ldlat-loads -v --ldlat 50
>>> calling: record -e cpu_atom/mem-loads,ldlat=50/P -e cpu_core/mem-loads,ldlat=50/P
>>>
>>> $perf mem record -v
>>> calling: record -e cpu_atom/mem-loads,ldlat=30/P -e cpu_atom/mem-stores/P -e cpu_core/mem-loads,ldlat=30/P -e cpu_core/mem-stores/P
>>>
>>> $perf mem record -t store -v
>>> calling: record -e cpu_atom/mem-stores/P -e cpu_core/mem-stores/P
>>>
>>>
>>> Intel SPR:
>>> $perf mem record -e list
>>> ldlat-loads  : available
>>> ldlat-stores : available
>>>
>>> $perf mem record -e ldlat-loads -v --ldlat 50
>>> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=50/}:P
>>>
>>> $perf mem record -v
>>> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=30/}:P -e cpu/mem-stores/P
>>>
>>> $perf mem record -t store -v
>>> calling: record -e cpu/mem-stores/P
>>>
>>> Kan Liang (5):
>>>  perf mem: Add mem_events into the supported perf_pmu
>>>  perf mem: Clean up perf_mem_events__ptr()
>>>  perf mem: Clean up perf_mem_events__name()
>>>  perf mem: Clean up perf_mem_event__supported()
>>>  perf mem: Clean up is_mem_loads_aux_event()
>>>
>>> tools/perf/arch/arm64/util/mem-events.c   |  36 +----
>>> tools/perf/arch/arm64/util/pmu.c          |   6 +
>>> tools/perf/arch/powerpc/util/mem-events.c |  13 +-
>>> tools/perf/arch/powerpc/util/mem-events.h |   7 +
>>> tools/perf/arch/powerpc/util/pmu.c        |  11 ++
>>> tools/perf/arch/s390/util/pmu.c           |   3 +
>>> tools/perf/arch/x86/util/mem-events.c     |  99 ++----------
>>> tools/perf/arch/x86/util/pmu.c            |  11 ++
>>> tools/perf/builtin-c2c.c                  |  28 +++-
>>> tools/perf/builtin-mem.c                  |  28 +++-
>>> tools/perf/util/mem-events.c              | 181 +++++++++++++---------
>>> tools/perf/util/mem-events.h              |  15 +-
>>> tools/perf/util/pmu.c                     |   4 +-
>>> tools/perf/util/pmu.h                     |   7 +
>>> 14 files changed, 233 insertions(+), 216 deletions(-)
>>> create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
>>> create mode 100644 tools/perf/arch/powerpc/util/pmu.c
>>>
>>> -- 
>>> 2.35.1
>>>
>>
>> -- 
>>
>> - Arnaldo
> 
> 
> 


From helgaas at kernel.org  Wed Dec 13 11:57:43 2023
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 13 Dec 2023 13:57:43 -0600
Subject: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx
 platforms.
In-Reply-To: <20231213092850.1706042-2-sherry.sun@nxp.com>
Message-ID: <20231213195743.GA1055303@bhelgaas>

Drop period at the end of subject line.  It only adds the possibility
of unnecessary line wrapping in git log.

On Wed, Dec 13, 2023 at 05:28:47PM +0800, Sherry Sun wrote:
> Add pci host wakeup feature for imx platforms.

s/pci/PCI/
s/imx/i.MX/ (based on how nxp.com web pages refer to it)

> Example of configuring the corresponding dts property under the PCI
> node:
> wake-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;

Add newline between paragraphs or wrap into a single paragraph.

> +		/* host wakeup support */
> +		imx6_pcie->host_wake_irq = -1;

AFAIK, 0 is an invalid IRQ value.  So why not drop this assignment
since imx6_pcie->host_wake_irq is 0 by default since it was allocated
with devm_kzalloc(), and test like this elsewhere:

  if (imx6_pcie->host_wake_irq) {
    enable_irq_wake(imx6_pcie->host_wake_irq)

> +		host_wake_gpio = devm_gpiod_get_optional(dev, "wake", GPIOD_IN);
> +		if (IS_ERR(host_wake_gpio))
> +			return PTR_ERR(host_wake_gpio);
> +
> +		if (host_wake_gpio != NULL) {

  if (host_wake_gpio)

Bjorn


From helgaas at kernel.org  Wed Dec 13 11:59:47 2023
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 13 Dec 2023 13:59:47 -0600
Subject: [PATCH v8 0/2] PCI: brcmstb: Configure appropriate HW CLKREQ#
 mode
In-Reply-To: <ae49227b-5026-43a4-8e19-aeeb63865a6a@broadcom.com>
Message-ID: <20231213195947.GA1056194@bhelgaas>

On Tue, Dec 12, 2023 at 03:51:12PM -0800, Florian Fainelli wrote:
> On 11/26/23 12:19, Cyril Brulebois wrote:
> > Hi Jim,
> > 
> > Jim Quinlan <james.quinlan at broadcom.com> (2023-11-13):
> > > V8 -- Un-advertise L1SS capability when in "no-l1ss" mode (Bjorn)
> > >     -- Squashed last two commits of v7 (Bjorn)
> > >     -- Fix DT binding description text wrapping (Bjorn)
> > >     -- Fix incorrect Spec reference (Bjorn)
> > >           s/PCIe Spec/PCIe Express Mini CEM 2.1 specification/
> > >     -- Text substitutions (Bjorn)
> > >           s/WRT/With respect to/
> > >           s/Tclron/T_CLRon/
> > > 
> > > v7 -- Manivannan Sadhasivam suggested (a) making the property look like a
> > >        network phy-mode and (b) keeping the code simple (not counting clkreq
> > >        signal appearances, un-advertising capabilites, etc).  This is
> > >        what I have done.  The property is now "brcm,clkreq-mode" and
> > >        the values may be one of "safe", "default", and "no-l1ss".  The
> > >        default setting is to employ the most capable power savings mode.
> > 
> > Still:
> > 
> > Tested-by: Cyril Brulebois <cyril at debamax.com>
> 
> Thanks Cyril! Bjorn, Lorenzo, any chance this can be applied soon? Thanks!

Seems OK to me if Lorenzo or Krzysztof W. are OK with it.


From debug at rivosinc.com  Wed Dec 13 11:59:45 2023
From: debug at rivosinc.com (Deepak Gupta)
Date: Wed, 13 Dec 2023 11:59:45 -0800
Subject: [PATCH v7 20/39] arm64/gcs: Context switch GCS state for EL0
In-Reply-To: <20231122-arm64-gcs-v7-20-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org> <20231122-arm64-gcs-v7-20-201c483bd775@kernel.org>
Message-ID: <CAKC1njQVB71A8fQBLmBnx++agM12XDLhS=7iL7-A4NTXSqUM+A@mail.gmail.com>

On Wed, Nov 22, 2023 at 1:45?AM Mark Brown <broonie at kernel.org> wrote:
> +
> +/*
> + * Apply the GCS mode configured for the specified task to the
> + * hardware.
> + */
> +void gcs_set_el0_mode(struct task_struct *task)
> +{
> +       u64 gcscre0_el1 = GCSCRE0_EL1_nTR;
> +
> +       if (task->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE)
> +               gcscre0_el1 |= GCSCRE0_EL1_RVCHKEN | GCSCRE0_EL1_PCRSEL;

If the intent is to disable, is the GCS stack freed or kept around?
I expect if libc is taking the decision to disable, kernel should free it up.
Is it freed in some other flow?

> +
> +       if (task->thread.gcs_el0_mode & PR_SHADOW_STACK_WRITE)
> +               gcscre0_el1 |= GCSCRE0_EL1_STREn;
> +
> +       if (task->thread.gcs_el0_mode & PR_SHADOW_STACK_PUSH)
> +               gcscre0_el1 |= GCSCRE0_EL1_PUSHMEn;
> +
> +       write_sysreg_s(gcscre0_el1, SYS_GCSCRE0_EL1);
> +}


From broonie at kernel.org  Wed Dec 13 12:02:24 2023
From: broonie at kernel.org (Mark Brown)
Date: Wed, 13 Dec 2023 20:02:24 +0000
Subject: [PATCH v7 20/39] arm64/gcs: Context switch GCS state for EL0
In-Reply-To: <CAKC1njQVB71A8fQBLmBnx++agM12XDLhS=7iL7-A4NTXSqUM+A@mail.gmail.com>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-20-201c483bd775@kernel.org>
 <CAKC1njQVB71A8fQBLmBnx++agM12XDLhS=7iL7-A4NTXSqUM+A@mail.gmail.com>
Message-ID: <b2a717a7-e6d3-4fa9-921e-156c17ad5424@sirena.org.uk>

On Wed, Dec 13, 2023 at 11:59:45AM -0800, Deepak Gupta wrote:
> On Wed, Nov 22, 2023 at 1:45?AM Mark Brown <broonie at kernel.org> wrote:

> > +       if (task->thread.gcs_el0_mode & PR_SHADOW_STACK_ENABLE)
> > +               gcscre0_el1 |= GCSCRE0_EL1_RVCHKEN | GCSCRE0_EL1_PCRSEL;

> If the intent is to disable, is the GCS stack freed or kept around?
> I expect if libc is taking the decision to disable, kernel should free it up.
> Is it freed in some other flow?

Kept around and freed on thread exit.  There is a potential race between
for example disabling in a signal handler and something trying to walk
the stack so we err on the side of caution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231213/1b52713c/attachment.sig>

From oliver.upton at linux.dev  Wed Dec 13 12:05:29 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Wed, 13 Dec 2023 20:05:29 +0000
Subject: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for
 vfio pci devices
In-Reply-To: <20231212181156.GO3014157@nvidia.com>
References: <20231208164709.23101-1-ankita@nvidia.com>
 <20231208164709.23101-3-ankita@nvidia.com>
 <ZXicemDzXm8NShs1@arm.com>
 <20231212181156.GO3014157@nvidia.com>
Message-ID: <ZXoOieQN7rBiLL4A@linux.dev>

Hi,

Sorry, a bit late to the discussion :)

On Tue, Dec 12, 2023 at 02:11:56PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 12, 2023 at 05:46:34PM +0000, Catalin Marinas wrote:
> > should know the implications. There's also an expectation that the
> > actual driver (KVM guests) or maybe later DPDK can choose the safe
> > non-cacheable or write-combine (Linux terminology) attributes for the
> > BAR.
> 
> DPDK won't rely on this interface

Wait, so what's the expected interface for determining the memory
attributes at stage-1? I'm somewhat concerned that we're conflating two
things here:

 1) KVM needs to know the memory attributes to use at stage-2, which
    isn't fundamentally different from what's needed for userspace
    stage-1 mappings.

 2) KVM additionally needs a hint that the device / VFIO can handle
    mismatched aliases w/o the machine exploding. This goes beyond
    supporting Normal-NC mappings at stage-2 and is really a bug
    with our current scheme (nGnRnE at stage-1, nGnRE at stage-2).

I was hoping that (1) could be some 'common' plumbing for both userspace
and KVM mappings. And for (2), any case where a device is intolerant of
mismatches && KVM cannot force the memory attributes should be rejected.

AFAICT, the only reason PCI devices can get the blanket treatment of
Normal-NC at stage-2 is because userspace has a Device-* mapping and can't
speculatively load from the alias. This feels a bit hacky, and maybe we
should prioritize an interface for mapping a device into a VM w/o a
valid userspace mapping.

I very much understand that this has been going on for a while, and we
need to do *something* to get passthrough working well for devices that
like 'WC'. I just want to make sure we don't paint ourselves into a corner
that's hard to get out of in the future.

-- 
Thanks,
Oliver


From jernej.skrabec at gmail.com  Wed Dec 13 12:07:20 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 13 Dec 2023 21:07:20 +0100
Subject: [PATCH v7 3/7] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
In-Reply-To: <20231122141426.329694-4-paul.kocialkowski@bootlin.com>
References: <20231122141426.329694-1-paul.kocialkowski@bootlin.com>
 <20231122141426.329694-4-paul.kocialkowski@bootlin.com>
Message-ID: <2169265.irdbgypaU6@archlinux>

Hi Paul!

Sorry for late reply.

On Wednesday, November 22, 2023 3:14:21 PM CET Paul Kocialkowski wrote:
> MIPI CSI-2 is supported on the V3s with an A31-based MIPI CSI-2 bridge
> controller. The controller uses a separate D-PHY, which is the same
> that is otherwise used for MIPI DSI, but used in Rx mode.
> 
> On the V3s, the CSI0 controller is dedicated to MIPI CSI-2 as it does
> not have access to any parallel interface pins.
> 
> Add all the necessary nodes (CSI0, MIPI CSI-2 bridge and D-PHY) to
> support the MIPI CSI-2 interface.
> 
> Note that a fwnode graph link is created between CSI0 and MIPI CSI-2
> even when no sensor is connected. This will result in a probe failure
> for the controller as long as no sensor is connected but this is fine
> since no other interface is available.
> 
> The interconnects property is used to inherit the proper DMA offset.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> ---
>  arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi | 71 ++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> index 506e98f4f69d..d57612023aa4 100644
> --- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> @@ -621,6 +621,77 @@ gic: interrupt-controller at 1c81000 {
>  			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>  		};
>  
> +		csi0: camera at 1cb0000 {
> +			compatible = "allwinner,sun8i-v3s-csi";
> +			reg = <0x01cb0000 0x1000>;
> +			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_BUS_CSI>,
> +				 <&ccu CLK_CSI1_SCLK>,
> +				 <&ccu CLK_DRAM_CSI>;
> +			clock-names = "bus", "mod", "ram";
> +			resets = <&ccu RST_BUS_CSI>;
> +			interconnects = <&mbus 5>;
> +			interconnect-names = "dma-mem";

As far as I can see, interconnects are not documented in
allwinner,sun6i-a31-csi.yaml. Please run make dtbs_check on this.

Best regards,
Jernej

> +			status = "disabled";
> +
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				port at 1 {
> +					reg = <1>;
> +
> +					csi0_in_mipi_csi2: endpoint {
> +						remote-endpoint = <&mipi_csi2_out_csi0>;
> +					};
> +				};
> +			};
> +		};
> +
> +		mipi_csi2: csi at 1cb1000 {
> +			compatible = "allwinner,sun8i-v3s-mipi-csi2",
> +				     "allwinner,sun6i-a31-mipi-csi2";
> +			reg = <0x01cb1000 0x1000>;
> +			interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_BUS_CSI>,
> +				 <&ccu CLK_CSI1_SCLK>;
> +			clock-names = "bus", "mod";
> +			resets = <&ccu RST_BUS_CSI>;
> +			status = "disabled";
> +
> +			phys = <&dphy>;
> +			phy-names = "dphy";
> +
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				mipi_csi2_in: port at 0 {
> +					reg = <0>;
> +				};
> +
> +				mipi_csi2_out: port at 1 {
> +					reg = <1>;
> +
> +					mipi_csi2_out_csi0: endpoint {
> +						remote-endpoint = <&csi0_in_mipi_csi2>;
> +					};
> +				};
> +			};
> +		};
> +
> +		dphy: d-phy at 1cb2000 {
> +			compatible = "allwinner,sun6i-a31-mipi-dphy";
> +			reg = <0x01cb2000 0x1000>;
> +			clocks = <&ccu CLK_BUS_CSI>,
> +				 <&ccu CLK_MIPI_CSI>;
> +			clock-names = "bus", "mod";
> +			resets = <&ccu RST_BUS_CSI>;
> +			allwinner,direction = "rx";
> +			status = "disabled";
> +			#phy-cells = <0>;
> +		};
> +
>  		csi1: camera at 1cb4000 {
>  			compatible = "allwinner,sun8i-v3s-csi";
>  			reg = <0x01cb4000 0x3000>;
> 






From jernej.skrabec at gmail.com  Wed Dec 13 12:09:32 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 13 Dec 2023 21:09:32 +0100
Subject: [PATCH v7 4/7] ARM: dts: sun8i: v3s: Add support for the ISP
In-Reply-To: <20231122141426.329694-5-paul.kocialkowski@bootlin.com>
References: <20231122141426.329694-1-paul.kocialkowski@bootlin.com>
 <20231122141426.329694-5-paul.kocialkowski@bootlin.com>
Message-ID: <3267480.aeNJFYEL58@archlinux>

On Wednesday, November 22, 2023 3:14:22 PM CET Paul Kocialkowski wrote:
> The V3s (and related platforms) come with an instance of the A31 ISP.
> Even though it is very close to the A31 ISP, it is not exactly
> register-compatible and a dedicated compatible only is used as a
> result.
> 
> Just like most other blocks of the camera pipeline, the ISP uses
> the common CSI bus, module and ram clock as well as reset.
> 
> A port connection to the ISP is added to CSI0 for convenience since
> CSI0 serves for MIPI CSI-2 interface support, which is likely to
> receive raw data that will need to be processed by the ISP to produce
> a final image.
> 
> The interconnects property is used to inherit the proper DMA offset.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> ---
>  arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> index d57612023aa4..1a1dcd36cba4 100644
> --- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> @@ -645,6 +645,14 @@ csi0_in_mipi_csi2: endpoint {
>  						remote-endpoint = <&mipi_csi2_out_csi0>;
>  					};
>  				};
> +
> +				port at 2 {
> +					reg = <2>;
> +
> +					csi0_out_isp: endpoint {
> +						remote-endpoint = <&isp_in_csi0>;
> +					};
> +				};
>  			};
>  		};
>  
> @@ -703,5 +711,32 @@ csi1: camera at 1cb4000 {
>  			resets = <&ccu RST_BUS_CSI>;
>  			status = "disabled";
>  		};
> +
> +		isp: isp at 1cb8000 {
> +			compatible = "allwinner,sun8i-v3s-isp";
> +			reg = <0x01cb8000 0x1000>;
> +			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_BUS_CSI>,
> +				 <&ccu CLK_CSI1_SCLK>,
> +				 <&ccu CLK_DRAM_CSI>;
> +			clock-names = "bus", "mod", "ram";
> +			resets = <&ccu RST_BUS_CSI>;
> +			interconnects = <&mbus 5>;
> +			interconnect-names = "dma-mem";

Same as in previous patch, interconnects properties are not described in
bindings, please update.

Best regards,
Jernej

> +			status = "disabled";
> +
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				port at 0 {
> +					reg = <0>;
> +
> +					isp_in_csi0: endpoint {
> +						remote-endpoint = <&csi0_out_isp>;
> +					};
> +				};
> +			};
> +		};
>  	};
>  };
> 






From jernej.skrabec at gmail.com  Wed Dec 13 12:11:52 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 13 Dec 2023 21:11:52 +0100
Subject: [PATCH v7 5/7] ARM: dts: sun8i: a83t: Add MIPI CSI-2 controller node
In-Reply-To: <20231122141426.329694-6-paul.kocialkowski@bootlin.com>
References: <20231122141426.329694-1-paul.kocialkowski@bootlin.com>
 <20231122141426.329694-6-paul.kocialkowski@bootlin.com>
Message-ID: <8310859.T7Z3S40VBb@archlinux>

On Wednesday, November 22, 2023 3:14:23 PM CET Paul Kocialkowski wrote:
> MIPI CSI-2 is supported on the A83T with a dedicated controller that
> covers both the protocol and D-PHY. It is connected to the only CSI
> receiver with a fwnode graph link. Note that the CSI receiver supports
> both this MIPI CSI-2 source and a parallel source.
> 
> An empty port with a label for the MIPI CSI-2 sensor input is also
> defined for convenience.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski at bootlin.com>

Reviewed-by: Jernej Skrabec <jernej.skrabec at gmail.com>

Best regards,
Jernej

> ---
>  arch/arm/boot/dts/allwinner/sun8i-a83t.dtsi | 43 +++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-a83t.dtsi b/arch/arm/boot/dts/allwinner/sun8i-a83t.dtsi
> index 94eb3bfc989e..b74c3f9e6598 100644
> --- a/arch/arm/boot/dts/allwinner/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/allwinner/sun8i-a83t.dtsi
> @@ -1062,6 +1062,49 @@ csi: camera at 1cb0000 {
>  			clock-names = "bus", "mod", "ram";
>  			resets = <&ccu RST_BUS_CSI>;
>  			status = "disabled";
> +
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				port at 1 {
> +					reg = <1>;
> +
> +					csi_in_mipi_csi2: endpoint {
> +						remote-endpoint = <&mipi_csi2_out_csi>;
> +					};
> +				};
> +			};
> +		};
> +
> +		mipi_csi2: csi at 1cb1000 {
> +			compatible = "allwinner,sun8i-a83t-mipi-csi2";
> +			reg = <0x01cb1000 0x1000>;
> +			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_BUS_CSI>,
> +				 <&ccu CLK_CSI_SCLK>,
> +				 <&ccu CLK_MIPI_CSI>,
> +				 <&ccu CLK_CSI_MISC>;
> +			clock-names = "bus", "mod", "mipi", "misc";
> +			resets = <&ccu RST_BUS_CSI>;
> +			status = "disabled";
> +
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				mipi_csi2_in: port at 0 {
> +					reg = <0>;
> +				};
> +
> +				mipi_csi2_out: port at 1 {
> +					reg = <1>;
> +
> +					mipi_csi2_out_csi: endpoint {
> +						remote-endpoint = <&csi_in_mipi_csi2>;
> +					};
> +				};
> +			};
>  		};
>  
>  		hdmi: hdmi at 1ee0000 {
> 






From oliver.upton at linux.dev  Wed Dec 13 12:24:59 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Wed, 13 Dec 2023 20:24:59 +0000
Subject: [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest
In-Reply-To: <20231207150804.3425468-1-james.morse@arm.com>
References: <20231207150804.3425468-1-james.morse@arm.com>
Message-ID: <ZXoTG1Y4O16Cjq39@linux.dev>

Hi James,

Thank you very much for posting these fixes.

On Thu, Dec 07, 2023 at 03:08:00PM +0000, James Morse wrote:
> 'lo
> 
> This series fixes up a long standing bug where MPAM was accidentally exposed
> to a guest, but the feature was not otherwise trapped or context switched.
> This could result in KVM warning about unexpected traps, and injecting an
> undef into the guest contradicting the ID registers.
> This would prevent an MPAM aware kernel from booting - fortunately, there
> aren't any of those.
> 
> Ideally, we'd take the MPAM feature away from the ID registers, but that
> would leave existing guests unable to migrate to a newer kernel. Instead,
> use the writable ID registers to allow MPAM to be re-enabled - but emulate
> it as RAZ/WI for the system registers that are trapped.

This is certainly a reasonable approach, but TBH I'm not too terribly
concerned about the completeness of the workaround plumbing that we need
here. Undoubtedly what you propose is the most complete solution to the
problem, but it is somewhat involved.

So long as we don't break migration at the userspace ioctl level I'm not
too worried. Maybe something like:

 - Ensure the reset value of ID_AA64PFR0_EL1.MPAM is 0

 - Allow userspace to write ID_AA64PFR0_EL1.MPAM as 1, *but*

 - KVM reinterprets this as '0' behind the scenes for the final register
   value

 - Add the MPAM registers to the sysreg table with trap_raz_wi() as the
   handler to avoid the unsupported sysreg printk, since it is possible
   that older VMs may've already seen the MPAM feature.

We've already done something similar to hide our mistakes with IMP DEF
PMU versions in commit f90f9360c3d7 ("KVM: arm64: Rewrite IMPDEF PMU
version as NI"), and I think MPAM may be a good candidate for something
similar.

-- 
Thanks,
Oliver


From jernej.skrabec at gmail.com  Wed Dec 13 12:25:06 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 13 Dec 2023 21:25:06 +0100
Subject: [PATCH v7 6/7] ARM: dts: sun8i-a83t: Add BananaPi M3 OV5640 camera
 overlay
In-Reply-To: <20231122141426.329694-7-paul.kocialkowski@bootlin.com>
References: <20231122141426.329694-1-paul.kocialkowski@bootlin.com>
 <20231122141426.329694-7-paul.kocialkowski@bootlin.com>
Message-ID: <22116368.EfDdHjke4D@archlinux>

Hi Paul!

On Wednesday, November 22, 2023 3:14:24 PM CET Paul Kocialkowski wrote:
> Add an overlay supporting the OV5640 from the BananaPi Camera v3
> peripheral board. The board has two sensors (OV5640 and OV8865)
> which cannot be supported in parallel as they share the same reset
> pin and the kernel currently has no support for this case.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> ---
>  arch/arm/boot/dts/allwinner/Makefile          |   1 +
>  .../sun8i-a83t-bananapi-m3-camera-ov5640.dtso | 117 ++++++++++++++++++
>  2 files changed, 118 insertions(+)
>  create mode 100644 arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov5640.dtso
> 
> diff --git a/arch/arm/boot/dts/allwinner/Makefile b/arch/arm/boot/dts/allwinner/Makefile
> index eebb5a0c873a..a0a9aa6595e4 100644
> --- a/arch/arm/boot/dts/allwinner/Makefile
> +++ b/arch/arm/boot/dts/allwinner/Makefile
> @@ -277,6 +277,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>  	sun8i-a33-sinlinx-sina33.dtb \
>  	sun8i-a83t-allwinner-h8homlet-v2.dtb \
>  	sun8i-a83t-bananapi-m3.dtb \
> +	sun8i-a83t-bananapi-m3-camera-ov5640.dtbo \
>  	sun8i-a83t-cubietruck-plus.dtb \
>  	sun8i-a83t-tbs-a711.dtb \
>  	sun8i-h2-plus-bananapi-m2-zero.dtb \
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov5640.dtso b/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov5640.dtso
> new file mode 100644
> index 000000000000..5868ef11bdee
> --- /dev/null
> +++ b/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov5640.dtso
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0 OR X11
> +/*
> + * Copyright 2022 Bootlin
> + * Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/sun8i-a83t-ccu.h>
> +#include <dt-bindings/gpio/gpio.h>

I think you should tie this overlay to BananaPi M3 board by specifying its
compatible here, like:

/ {
	compatible = "sinovoip,bpi-m3";
};

> +
> +&{/} {
> +	/*
> +	 * These regulators actually have DLDO4 tied to their EN pin, which is
> +	 * described as input supply here for lack of a better representation.
> +	 * Their actual supply is PS, which is always-on.
> +	 */
> +
> +	ov5640_avdd: ov5640-avdd {
> +		compatible = "regulator-fixed";
> +		regulator-name = "ov5640-avdd";
> +		regulator-min-microvolt = <2800000>;
> +		regulator-max-microvolt = <2800000>;
> +		vin-supply = <&reg_dldo4>;
> +	};
> +
> +	ov5640_dovdd: ov5640-dovdd {
> +		compatible = "regulator-fixed";
> +		regulator-name = "ov5640-dovdd";
> +		regulator-min-microvolt = <2800000>;
> +		regulator-max-microvolt = <2800000>;
> +		vin-supply = <&reg_dldo4>;
> +	};
> +
> +	ov5640_dvdd: ov5640-dvdd {
> +		compatible = "regulator-fixed";
> +		regulator-name = "ov5640-dvdd";
> +		regulator-min-microvolt = <1500000>;
> +		regulator-max-microvolt = <1500000>;
> +		vin-supply = <&reg_dldo4>;
> +	};
> +};
> +
> +&csi {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&csi_8bit_parallel_pins>;
> +	status = "okay";
> +
> +	ports {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		port at 0 {
> +			reg = <0>;
> +
> +			csi_in_ov5640: endpoint {
> +				remote-endpoint = <&ov5640_out_csi>;
> +				bus-width = <8>;
> +				data-shift = <2>;
> +				hsync-active = <1>;
> +				vsync-active = <1>;
> +				pclk-sample = <1>;
> +			};
> +		};
> +	};
> +};
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c2_pe_pins>;
> +	status = "okay";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	ov5640: camera at 3c {
> +		compatible = "ovti,ov5640";
> +		reg = <0x3c>;
> +
> +		clocks = <&ccu CLK_CSI_MCLK>;
> +		clock-names = "xclk";
> +		assigned-clocks = <&ccu CLK_CSI_MCLK>;
> +		assigned-clock-parents = <&osc24M>;
> +		assigned-clock-rates = <24000000>;

Are those really necessary? If so, can it be moved to the driver? Assigned
clock rates have no guarantee that they will stay at that rate. Additionally,
same sensor in pinetab doesn't need that. What's the difference?

> +
> +		AVDD-supply = <&ov5640_avdd>;
> +		DOVDD-supply = <&ov5640_dovdd>;
> +		DVDD-supply = <&ov5640_dvdd>;
> +
> +		powerdown-gpios = <&pio 3 15 GPIO_ACTIVE_HIGH>; /* PD15 */
> +		reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
> +
> +		rotation = <180>;
> +
> +		port {
> +			ov5640_out_csi: endpoint {
> +				remote-endpoint = <&csi_in_ov5640>;
> +				bus-width = <8>;
> +				data-shift = <2>;
> +				hsync-active = <1>; 
> +				vsync-active = <1>;
> +				pclk-sample = <1>;
> +			};
> +		};
> +	};
> +};
> +
> +&pio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&csi_mclk_pin>;

This should be moved to ov5640 node.

Best regards,
Jernej

> +};
> +
> +&reg_dldo4 {
> +	regulator-min-microvolt = <2800000>;
> +	regulator-max-microvolt = <2800000>;
> +};
> 






From jernej.skrabec at gmail.com  Wed Dec 13 12:26:32 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 13 Dec 2023 21:26:32 +0100
Subject: [PATCH v7 7/7] ARM: dts: sun8i-a83t: Add BananaPi M3 OV8865 camera
 overlay
In-Reply-To: <20231122141426.329694-8-paul.kocialkowski@bootlin.com>
References: <20231122141426.329694-1-paul.kocialkowski@bootlin.com>
 <20231122141426.329694-8-paul.kocialkowski@bootlin.com>
Message-ID: <3780932.kQq0lBPeGt@archlinux>

Hi Paul,

same comments as for patch 6.

Best regards,
Jernej

On Wednesday, November 22, 2023 3:14:25 PM CET Paul Kocialkowski wrote:
> Add an overlay supporting the OV8865 from the BananaPi Camera v3
> peripheral board. The board has two sensors (OV5640 and OV8865)
> which cannot be supported in parallel as they share the same reset
> pin and the kernel currently has no support for this case.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> ---
>  arch/arm/boot/dts/allwinner/Makefile          |   1 +
>  .../sun8i-a83t-bananapi-m3-camera-ov8865.dtso | 109 ++++++++++++++++++
>  2 files changed, 110 insertions(+)
>  create mode 100644 arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov8865.dtso
> 
> diff --git a/arch/arm/boot/dts/allwinner/Makefile b/arch/arm/boot/dts/allwinner/Makefile
> index a0a9aa6595e4..980ac88634e3 100644
> --- a/arch/arm/boot/dts/allwinner/Makefile
> +++ b/arch/arm/boot/dts/allwinner/Makefile
> @@ -278,6 +278,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>  	sun8i-a83t-allwinner-h8homlet-v2.dtb \
>  	sun8i-a83t-bananapi-m3.dtb \
>  	sun8i-a83t-bananapi-m3-camera-ov5640.dtbo \
> +	sun8i-a83t-bananapi-m3-camera-ov8865.dtbo \
>  	sun8i-a83t-cubietruck-plus.dtb \
>  	sun8i-a83t-tbs-a711.dtb \
>  	sun8i-h2-plus-bananapi-m2-zero.dtb \
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov8865.dtso b/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov8865.dtso
> new file mode 100644
> index 000000000000..0656ee8d4bfe
> --- /dev/null
> +++ b/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov8865.dtso
> @@ -0,0 +1,109 @@
> +// SPDX-License-Identifier: GPL-2.0 OR X11
> +/*
> + * Copyright 2022 Bootlin
> + * Author: K?vin L'h?pital <kevin.lhopital at bootlin.com>
> + * Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/sun8i-a83t-ccu.h>
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&{/} {
> +	/*
> +	 * These regulators actually have DLDO4 tied to their EN pin, which is
> +	 * described as input supply here for lack of a better representation.
> +	 * Their actual supply is PS, which is always-on.
> +	 */
> +
> +	ov8865_avdd: ov8865-avdd {
> +		compatible = "regulator-fixed";
> +		regulator-name = "ov8865-avdd";
> +		regulator-min-microvolt = <2800000>;
> +		regulator-max-microvolt = <2800000>;
> +		vin-supply = <&reg_dldo4>;
> +	};
> +
> +	ov8865_dovdd: ov8865-dovdd {
> +		compatible = "regulator-fixed";
> +		regulator-name = "ov8865-dovdd";
> +		regulator-min-microvolt = <2800000>;
> +		regulator-max-microvolt = <2800000>;
> +		vin-supply = <&reg_dldo4>;
> +	};
> +
> +	ov8865_dvdd: ov8865-dvdd {
> +		compatible = "regulator-fixed";
> +		regulator-name = "ov8865-dvdd";
> +		regulator-min-microvolt = <1200000>;
> +		regulator-max-microvolt = <1200000>;
> +		vin-supply = <&reg_dldo4>;
> +	};
> +};
> +
> +&ccu {
> +	assigned-clocks = <&ccu CLK_CSI_MCLK>;
> +	assigned-clock-parents = <&osc24M>;
> +	assigned-clock-rates = <24000000>;
> +};
> +
> +&csi {
> +	status = "okay";
> +};
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c2_pe_pins>;
> +	status = "okay";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	ov8865: camera at 36 {
> +		compatible = "ovti,ov8865";
> +		reg = <0x36>;
> +
> +		clocks = <&ccu CLK_CSI_MCLK>;
> +		assigned-clocks = <&ccu CLK_CSI_MCLK>;
> +		assigned-clock-parents = <&osc24M>;
> +		assigned-clock-rates = <24000000>;
> +
> +		avdd-supply = <&ov8865_avdd>;
> +		dovdd-supply = <&ov8865_dovdd>;
> +		dvdd-supply = <&ov8865_dvdd>;
> +
> +		powerdown-gpios = <&pio 4 17 GPIO_ACTIVE_LOW>; /* PE17 */
> +		reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
> +
> +		port {
> +			ov8865_out_mipi_csi2: endpoint {
> +				remote-endpoint = <&mipi_csi2_in_ov8865>;
> +				link-frequencies = /bits/ 64 <360000000>;
> +				data-lanes = <1 2 3 4>;
> +			};
> +		};
> +	};
> +};
> +
> +&mipi_csi2 {
> +	status = "okay";
> +};
> +
> +&mipi_csi2_in {
> +	mipi_csi2_in_ov8865: endpoint {
> +		remote-endpoint = <&ov8865_out_mipi_csi2>;
> +		data-lanes = <1 2 3 4>;
> +	};
> +};
> +
> +&pio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&csi_mclk_pin>;
> +};
> +
> +&reg_dldo4 {
> +	regulator-min-microvolt = <2800000>;
> +	regulator-max-microvolt = <2800000>;
> +};
> 






From nm at ti.com  Wed Dec 13 12:27:05 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 13 Dec 2023 14:27:05 -0600
Subject: [PATCH 2/3] arm64: dts: ti: Introduce J722S family of SoCs
In-Reply-To: <20231213124930.3012-3-vaishnav.a@ti.com>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
 <20231213124930.3012-3-vaishnav.a@ti.com>
Message-ID: <20231213202705.6tspycl5qicb6gwd@germproof>

On 18:19-20231213, Vaishnav Achath wrote:
> The J722S is a family of  application processors built for Automotive and
> Linux Application development. Scalable Arm Cortex-A53 performance and
> embedded features, such as multi high-definition display support,
> 3D-graphics acceleration, 4K video acceleration, and extensive peripherals
> make the J722S well-suited for a broad range of automation and industrial
> application, including automotive digital instrumentation, automotive
> displays, industrial HMI, and more.

Trim this down please
> 
> Some highlights of J722S SoC are:
>     * Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
>     * One Device manager Cortext-R5F for system power and resource
>       management, two Cortex-R5F for Functional Safety or
>       general-purpose usage and two C7x floating point vector DSPs
>       with Matrix Multiply Accelerator(MMA) for deep learning.
>     * One 3D GPU up to 50 GLFOPS
>     * H.264/H.265, JPEG Video Encode/Decode.
>     * Display support: 3x display support over OLDI/LVDS (1x OLDI-DL, 1x or
>       2x OLDI-SL), DSI, or DPI. Up to 3840x1080 at 60fps resolution
>     * Integrated Giga-bit Ethernet switch supporting up to a total of two
>       external ports (TSN capable).
>     * Vision Processing Accelerator (VPAC) with image signal processor
>       and Depth and Motion Processing Accelerator (DMPAC).
>     * 7xUARTs, 3xSPI, 5xI2C, 2xUSB2, 2xCAN-FD, 3xMMC and SD, GPMC for
>       NAND/FPGA connection, OSPI memory controller, 5xMcASP for audio,
>       4xCSI-RX for Camera, 1 PCIe Gen3 controller, eCAP/eQEP,
>       ePWM, among other peripherals.
>     * Dedicated Centralized Hardware Security Module with support for
>       secure boot, debug security and crypto acceleration and trusted
>       execution environment.
>     * One 32-bit DDR Subsystem that supports LPDDR4 memory type.

Trim this down to what is different from AM62P?

> 
> J722S family of SoCs is a superset of the AM62P SoC family and shares
> similar memory map, thus the nodes are being reused from AM62P includes
> instead of duplicating the definitions. Unused nodes with dependencies
> are kept disabled and will be enabled later when the dependencies are
> enabled.
> 
> For those interested, more details about this SoC can be found in the
> Technical Reference Manual here:
> 	https://www.ti.com/lit/zip/sprujb3
> 
> Co-developed-by: Jayesh Choudhary <j-choudhary at ti.com>
> Signed-off-by: Jayesh Choudhary <j-choudhary at ti.com>
> Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
> ---
> 
> checkpatch error is ignored for arch/arm64/boot/dts/ti/k3-pinctrl.h:
> ERROR: Macros with complex values should be enclosed in parentheses
> 
> However, we do not need parentheses enclosing the values for this
> macro as we do intend it to generate two separate values as has been
> done for other similar platforms.
> 
> Depends on:
> https://lore.kernel.org/all/20231211132600.25289-1-vaishnav.a at ti.com/
> https://lore.kernel.org/all/20231213081318.26203-1-vaishnav.a at ti.com/
> 
>  arch/arm64/boot/dts/ti/k3-j722s.dtsi | 275 +++++++++++++++++++++++++++
>  arch/arm64/boot/dts/ti/k3-pinctrl.h  |   3 +
>  2 files changed, 278 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/ti/k3-j722s.dtsi
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j722s.dtsi b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
> new file mode 100644
> index 000000000000..dbd762bfd779
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
> @@ -0,0 +1,275 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for J722S SoC Family
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +#include "k3-pinctrl.h"
> +
> +/ {
> +	model = "Texas Instruments K3 J722S SoC";
> +	compatible = "ti,j722s";
> +	interrupt-parent = <&gic500>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu-map {
> +			cluster0: cluster0 {
> +				core0 {
> +					cpu = <&cpu0>;
> +				};
> +
> +				core1 {
> +					cpu = <&cpu1>;
> +				};
> +
> +				core2 {
> +					cpu = <&cpu2>;
> +				};
> +
> +				core3 {
> +					cpu = <&cpu3>;
> +				};
> +			};
> +		};
> +
> +		cpu0: cpu at 0 {
> +			compatible = "arm,cortex-a53";
> +			reg = <0x000>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			i-cache-size = <0x8000>;
> +			i-cache-line-size = <64>;
> +			i-cache-sets = <256>;
> +			d-cache-size = <0x8000>;
> +			d-cache-line-size = <64>;
> +			d-cache-sets = <128>;
> +			next-level-cache = <&l2_0>;
> +			clocks = <&k3_clks 135 0>;
> +		};
> +
> +		cpu1: cpu at 1 {
> +			compatible = "arm,cortex-a53";
> +			reg = <0x001>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			i-cache-size = <0x8000>;
> +			i-cache-line-size = <64>;
> +			i-cache-sets = <256>;
> +			d-cache-size = <0x8000>;
> +			d-cache-line-size = <64>;
> +			d-cache-sets = <128>;
> +			next-level-cache = <&l2_0>;
> +			clocks = <&k3_clks 136 0>;
> +		};
> +
> +		cpu2: cpu at 2 {
> +			compatible = "arm,cortex-a53";
> +			reg = <0x002>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			i-cache-size = <0x8000>;
> +			i-cache-line-size = <64>;
> +			i-cache-sets = <256>;
> +			d-cache-size = <0x8000>;
> +			d-cache-line-size = <64>;
> +			d-cache-sets = <128>;
> +			next-level-cache = <&l2_0>;
> +			clocks = <&k3_clks 137 0>;
> +		};
> +
> +		cpu3: cpu at 3 {
> +			compatible = "arm,cortex-a53";
> +			reg = <0x003>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			i-cache-size = <0x8000>;
> +			i-cache-line-size = <64>;
> +			i-cache-sets = <256>;
> +			d-cache-size = <0x8000>;
> +			d-cache-line-size = <64>;
> +			d-cache-sets = <128>;
> +			next-level-cache = <&l2_0>;
> +			clocks = <&k3_clks 138 0>;
> +		};
> +	};
> +
> +	l2_0: l2-cache0 {
> +		compatible = "cache";
> +		cache-unified;
> +		cache-level = <2>;
> +		cache-size = <0x80000>;
> +		cache-line-size = <64>;
> +		cache-sets = <512>;
> +	};

^^ this is a duplication of am62p5.dtsi? what about the spins with
different CPUs enabled?

> +
> +	firmware {
> +		optee {
> +			compatible = "linaro,optee-tz";
> +			method = "smc";
> +		};
> +
> +		psci: psci {
> +			compatible = "arm,psci-1.0";
> +			method = "smc";
> +		};
> +	};
> +
> +	a53_timer0: timer-cl0-cpu0 {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> +			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> +			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> +			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> +	};
> +
> +	pmu: pmu {
> +		compatible = "arm,cortex-a53-pmu";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> +	};
> +
> +	cbass_main: bus at f0000 {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		bootph-all;

Nope.

> +
> +		ranges = <0x00 0x000f0000 0x00 0x000f0000 0x00 0x00030000>, /* Main MMRs */
> +			 <0x00 0x00420000 0x00 0x00420000 0x00 0x00001000>, /* ESM0 */
> +			 <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
> +			 <0x00 0x00703000 0x00 0x00703000 0x00 0x00000200>, /* USB0 debug trace */
> +			 <0x00 0x0070c000 0x00 0x0070c000 0x00 0x00000200>, /* USB1 debug trace */
> +			 <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
> +			 <0x00 0x01000000 0x00 0x01000000 0x00 0x01b28400>, /* First peripheral window */
> +			 <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
> +			 <0x00 0x0e000000 0x00 0x0e000000 0x00 0x01d20000>, /* Second peripheral window */
> +			 <0x00 0x0fd80000 0x00 0x0fd80000 0x00 0x00080000>, /* GPU */
> +			 <0x00 0x0fd20000 0x00 0x0fd20000 0x00 0x00000100>, /* JPEGENC0_CORE */
> +			 <0x00 0x0fd20200 0x00 0x0fd20200 0x00 0x00000200>, /* JPEGENC0_CORE_MMU */
> +			 <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
> +			 <0x00 0x30040000 0x00 0x30040000 0x00 0x00080000>, /* PRUSS-M */
> +			 <0x00 0x301C0000 0x00 0x301C0000 0x00 0x00001000>, /* DPHY-TX */
> +			 <0x00 0x30101000 0x00 0x30101000 0x00 0x00080100>, /* CSI window */
> +			 <0x00 0x30200000 0x00 0x30200000 0x00 0x00010000>, /* DSS */
> +			 <0x00 0x30210000 0x00 0x30210000 0x00 0x00010000>, /* VPU */
> +			 <0x00 0x30220000 0x00 0x30220000 0x00 0x00010000>, /* DSS1 */
> +			 <0x00 0x30270000 0x00 0x30270000 0x00 0x00010000>, /* DSI-base1 */
> +			 <0x00 0x30500000 0x00 0x30500000 0x00 0x00100000>, /* DSI-base2 */
> +			 <0x00 0x31000000 0x00 0x31000000 0x00 0x00050000>, /* USB0 DWC3 Core window */
> +			 <0x00 0x31200000 0x00 0x31200000 0x00 0x00040000>, /* USB1 DWC3 Core window */
> +			 <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, /* SA3UL */
> +			 <0x00 0x43600000 0x00 0x43600000 0x00 0x00010000>, /* SA3 sproxy data */
> +			 <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
> +			 <0x00 0x44860000 0x00 0x44860000 0x00 0x00040000>, /* SA3 sproxy config */
> +			 <0x00 0x48000000 0x00 0x48000000 0x00 0x06408000>, /* DMSS */
> +			 <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
> +			 <0x00 0x70000000 0x00 0x70000000 0x00 0x00040000>, /* OCSRAM */
> +			 <0x00 0x78400000 0x00 0x78400000 0x00 0x00008000>, /* MAIN R5FSS0 ATCM */
> +			 <0x00 0x78500000 0x00 0x78500000 0x00 0x00008000>, /* MAIN R5FSS0 BTCM */
> +			 <0x00 0x7e000000 0x00 0x7e000000 0x00 0x00200000>, /* C7X_0 L2SRAM */
> +			 <0x00 0x7e200000 0x00 0x7e200000 0x00 0x00200000>, /* C7X_1 L2SRAM */
> +			 <0x01 0x00000000 0x01 0x00000000 0x00 0x00310000>, /* A53 PERIPHBASE */
> +			 <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
> +
> +			 /* MCU Domain Range */
> +			 <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>,
> +			 <0x00 0x79000000 0x00 0x79000000 0x00 0x00008000>,
> +			 <0x00 0x79020000 0x00 0x79020000 0x00 0x00008000>,
> +			 <0x00 0x79100000 0x00 0x79100000 0x00 0x00040000>,
> +			 <0x00 0x79140000 0x00 0x79140000 0x00 0x00040000>,
> +
> +			 /* Wakeup Domain Range */
> +			 <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>,
> +			 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>,
> +			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>,
> +			 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>,
> +			 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>;
> +
> +		cbass_mcu: bus at 4000000 {
> +			compatible = "simple-bus";
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>, /* Peripheral window */
> +				 <0x00 0x79000000 0x00 0x79000000 0x00 0x00008000>, /* MCU R5 ATCM */
> +				 <0x00 0x79020000 0x00 0x79020000 0x00 0x00008000>, /* MCU R5 BTCM */
> +				 <0x00 0x79100000 0x00 0x79100000 0x00 0x00040000>, /* MCU IRAM0 */
> +				 <0x00 0x79140000 0x00 0x79140000 0x00 0x00040000>; /* MCU IRAM1 */
> +			bootph-all;
> +		};
> +
> +		cbass_wakeup: bus at b00000 {
> +			compatible = "simple-bus";
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			ranges = <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
> +				 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
> +				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* WKUP CTRL MMR */
> +				 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
> +				 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
> +			bootph-all;

Not in the bus nodes.. only in the leaf nodes please.


Also what is wrong with expanding the am62p to include the
missing bus segments instead of duplicating all of them?

> +		};
> +	};
> +
> +	#include "k3-am62p-thermal.dtsi"

Is this correct?

> +};
> +
> +/*
> + * Include peripherals for each bus segment derived
> + * from AM62P and overrides specific to J722S.
> + */
> +#include "k3-am62p-main.dtsi"
> +#include "k3-am62p-mcu.dtsi"
> +#include "k3-am62p-wakeup.dtsi"
> +
> +/* Main domain overrides */
> +
> +&cpsw3g {
> +	status = "disabled";

	here and rest: Why disabled?
> +};
> +
> +&inta_main_dmss {
> +	ti,interrupt-ranges = <5 69 35>;
> +};
> +
> +&mailbox0_cluster0 {
> +	status = "disabled";
> +};
> +
> +&mailbox0_cluster1 {
> +	status = "disabled";
> +};
> +
> +&mailbox0_cluster2 {
> +	status = "disabled";
> +};
> +
> +&mailbox0_cluster3 {
> +	status = "disabled";
> +};
> +
> +&oc_sram {
> +	reg = <0x00 0x70000000 0x00 0x40000>;
> +	ranges = <0x00 0x00 0x70000000 0x40000>;
> +};
> +
> +/* MCU domain overrides */
> +
> +&mcu_r5fss0 {
> +	status = "disabled";
> +};
> +
> +/* wakeup domain overrides */
> +
> +&wkup_r5fss0 {
> +	status = "disabled";
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-pinctrl.h b/arch/arm64/boot/dts/ti/k3-pinctrl.h
> index 2a4e0e084d69..591be4489f37 100644
> --- a/arch/arm64/boot/dts/ti/k3-pinctrl.h
> +++ b/arch/arm64/boot/dts/ti/k3-pinctrl.h
> @@ -59,6 +59,9 @@
>  #define J721S2_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
>  #define J721S2_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
>  
> +#define J722S_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
> +#define J722S_MCU_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
> +
>  #define J784S4_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
>  #define J784S4_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
>  
> -- 
> 2.17.1
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From nm at ti.com  Wed Dec 13 12:28:13 2023
From: nm at ti.com (Nishanth Menon)
Date: Wed, 13 Dec 2023 14:28:13 -0600
Subject: [PATCH 3/3] arm64: dts: ti: Add support for TI J722S Evaluation
 Module
In-Reply-To: <20231213124930.3012-4-vaishnav.a@ti.com>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
 <20231213124930.3012-4-vaishnav.a@ti.com>
Message-ID: <20231213202813.7wgncys4qxgslsro@bulldog>

On 18:19-20231213, Vaishnav Achath wrote:
> Add basic support for the J722S EVM with UART console and
> MMC SD as rootfs.
> 
> Schematics are available at:
> 	https://www.ti.com/lit/zip/sprr495
> 
> Co-developed-by: Jayesh Choudhary <j-choudhary at ti.com>
> Signed-off-by: Jayesh Choudhary <j-choudhary at ti.com>
> Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
> ---
>  arch/arm64/boot/dts/ti/Makefile         |   3 +
>  arch/arm64/boot/dts/ti/k3-j722s-evm.dts | 253 ++++++++++++++++++++++++
>  2 files changed, 256 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-evm.dts
> 
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 1ac47876bc99..aa7cc33e239b 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -76,6 +76,9 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
>  k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
>  dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
>  
> +# Boards with J722s SoC
> +dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
> +
>  # Boards with J784s4 SoC
>  dtb-$(CONFIG_ARCH_K3) += k3-am69-sk.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm.dtb
> diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
> new file mode 100644
> index 000000000000..1cb29203a8ed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
> @@ -0,0 +1,253 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree file for the J722S-EVM
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + *
> + * Schematics: https://www.ti.com/lit/zip/sprr495
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-j722s.dtsi"
> +
> +/ {
> +	compatible = "ti,j722s-evm", "ti,j722s";
> +	model = "Texas Instruments J722S EVM";
> +
> +	aliases {
> +		serial0 = &wkup_uart0;
> +		serial2 = &main_uart0;
> +		mmc0 = &sdhci0;
> +		mmc1 = &sdhci1;
> +	};
> +
> +	chosen {
> +		stdout-path = &main_uart0;
> +	};
> +
> +	memory at 80000000 {
> +		/* 8G RAM */
> +		reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
> +		      <0x00000008 0x80000000 0x00000001 0x80000000>;
> +		device_type = "memory";
> +		bootph-pre-ram;
> +	};
> +
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		secure_tfa_ddr: tfa at 9e780000 {
> +			reg = <0x00 0x9e780000 0x00 0x80000>;
> +			no-map;
> +		};
> +
> +		secure_ddr: optee at 9e800000 {
> +			reg = <0x00 0x9e800000 0x00 0x01800000>;
> +			no-map;
> +		};
> +
> +		wkup_r5fss0_core0_memory_region: r5f-memory at a0100000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0xa0100000 0x00 0xf00000>;
> +			no-map;
> +		};
> +
> +	};
> +
> +	vmain_pd: regulator-0 {
> +		/* TPS65988 PD CONTROLLER OUTPUT */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vmain_pd";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		bootph-all;
> +	};
> +
> +	vsys_5v0: regulator-vsys5v0 {
> +		/* Output of LM5140 */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vsys_5v0";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vmain_pd>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +
> +	vdd_mmc1: regulator-mmc1 {
> +		/* TPS22918DBVR */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vdd_mmc1";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-boot-on;
> +		enable-active-high;
> +		gpio = <&exp1 15 GPIO_ACTIVE_HIGH>;
> +		bootph-all;
> +	};
> +
> +	vdd_sd_dv: regulator-TLV71033 {
> +		compatible = "regulator-gpio";
> +		regulator-name = "tlv71033";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vdd_sd_dv_pins_default>;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-boot-on;
> +		vin-supply = <&vsys_5v0>;
> +		gpios = <&main_gpio0 70 GPIO_ACTIVE_HIGH>;
> +		states = <1800000 0x0>,
> +			 <3300000 0x1>;
> +	};
> +
> +	vsys_io_1v8: regulator-vsys-io-1v8 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vsys_io_1v8";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +
> +	vsys_io_1v2: regulator-vsys-io-1v2 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vsys_io_1v2";
> +		regulator-min-microvolt = <1200000>;
> +		regulator-max-microvolt = <1200000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +};
> +
> +&main_pmx0 {
> +	bootph-all;

Only in leaf nodes.

> +
> +	main_i2c0_pins_default: main-i2c0-default-pins {
> +		pinctrl-single,pins = <
> +			J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
> +			J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
> +		>;
> +		bootph-all;
> +	};
> +
> +	main_uart0_pins_default: main-uart0-default-pins {
> +		pinctrl-single,pins = <
> +			J722S_IOPAD(0x1c8, PIN_INPUT, 0)	/* (A22) UART0_RXD */
> +			J722S_IOPAD(0x1cc, PIN_OUTPUT, 0)	/* (B22) UART0_TXD */
> +		>;
> +		bootph-all;
> +	};
> +
> +	vdd_sd_dv_pins_default: vdd-sd-dv-default-pins {
> +		pinctrl-single,pins = <
> +			J722S_IOPAD(0x0120, PIN_INPUT, 7) /* (F27) MMC2_CMD.GPIO0_70 */
> +		>;
> +		bootph-all;
> +	};
> +
> +	main_mmc1_pins_default: main-mmc1-default-pins {
> +		pinctrl-single,pins = <
> +			J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
> +			J722S_IOPAD(0x0234, PIN_OUTPUT, 0) /* (H24) MMC1_CLK */
> +			J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
> +			J722S_IOPAD(0x022c, PIN_INPUT_PULLUP, 0) /* (H20) MMC1_DAT1 */
> +			J722S_IOPAD(0x0228, PIN_INPUT_PULLUP, 0) /* (J23) MMC1_DAT2 */
> +			J722S_IOPAD(0x0224, PIN_INPUT_PULLUP, 0) /* (H25) MMC1_DAT3 */
> +			J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
> +		>;
> +		bootph-all;
> +	};
> +};
> +
> +&main_gpio1 {
> +	status = "okay";
> +};
> +
> +&main_uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&main_uart0_pins_default>;
> +	status = "okay";
> +	bootph-all;
> +};
> +
> +&mcu_pmx0 {
> +	bootph-all;

Same..

> +
> +	wkup_uart0_pins_default: wkup-uart0-default-pins {
> +		pinctrl-single,pins = <
> +			J722S_MCU_IOPAD(0x02c, PIN_INPUT, 0)	/* (C7) WKUP_UART0_CTSn */
> +			J722S_MCU_IOPAD(0x030, PIN_OUTPUT, 0)	/* (C6) WKUP_UART0_RTSn */
> +			J722S_MCU_IOPAD(0x024, PIN_INPUT, 0)	/* (D8) WKUP_UART0_RXD */
> +			J722S_MCU_IOPAD(0x028, PIN_OUTPUT, 0)	/* (D7) WKUP_UART0_TXD */
> +		>;
> +		bootph-all;
> +	};
> +
> +	wkup_i2c0_pins_default: wkup-i2c0-default-pins {
> +		pinctrl-single,pins = <
> +			J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0)	/* (C7) WKUP_I2C0_SCL */
> +			J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0)	/* (C6) WKUP_I2C1_SDA */
> +		>;
> +		bootph-all;
> +	};
> +};
> +
> +&wkup_uart0 {
> +	/* WKUP UART0 is used by DM firmware */
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&wkup_uart0_pins_default>;
> +	status = "reserved";
> +	bootph-all;
> +};
> +
> +&wkup_i2c0 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&wkup_i2c0_pins_default>;
> +	clock-frequency = <400000>;
> +	bootph-all;
> +};
> +
> +&main_i2c0 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&main_i2c0_pins_default>;
> +	clock-frequency = <400000>;
> +	bootph-all;
> +
> +	exp1: gpio at 23 {
> +		compatible = "ti,tca6424";
> +		reg = <0x23>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		gpio-line-names = "TRC_MUX_SEL", "OSPI/ONAND_MUX_SEL",
> +				  "MCASP1_FET_SEL", "CTRL_PM_I2C_OE#",
> +				  "CSI_VIO_SEL", "USB2.0_MUX_SEL",
> +				  "CSI01_MUX_SEL_2", "CSI23_MUX_SEL_2",
> +				  "LMK1_OE1", "LMK1_OE0",
> +				  "LMK2_OE0", "LMK2_OE1",
> +				  "GPIO_RGMII1_RST#", "GPIO_AUD_RSTn",
> +				  "GPIO_eMMC_RSTn", "GPIO_uSD_PWR_EN",
> +				  "USER_LED2", "MCAN0_STB",
> +				  "PCIe0_1L_RC_RSTz", "PCIe0_1L_PRSNT#",
> +				  "ENET1_EXP_SPARE2", "ENET1_EXP_PWRDN",
> +				  "PD_I2ENET1_I2CMUX_SELC_IRQ", "ENET1_EXP_RESETZ";
> +	};
> +};
> +
> +&sdhci1 {
> +	/* SD/MMC */
> +	status = "okay";
> +	vmmc-supply = <&vdd_mmc1>;
> +	vqmmc-supply = <&vdd_sd_dv>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&main_mmc1_pins_default>;
> +	ti,driver-strength-ohm = <50>;
> +	disable-wp;
> +	no-1-8-v;
> +	bootph-all;
> +};
> -- 
> 2.17.1
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From knaerzche at gmail.com  Wed Dec 13 12:29:45 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 13 Dec 2023 21:29:45 +0100
Subject: [PATCH 00/31] Fix and improve Rockchip RK3128 support
In-Reply-To: <2167016.irdbgypaU6@phil>
References: <20230829171647.187787-1-knaerzche@gmail.com>
 <2167016.irdbgypaU6@phil>
Message-ID: <a5889aba-75b6-4671-918b-26a4b9ec12c5@gmail.com>

Hi Heiko

Am 12.12.23 um 21:03 schrieb Heiko Stuebner:
> Hi Alex,
>
> Am Dienstag, 29. August 2023, 19:16:16 CET schrieb Alex Bee:
>> this series fixes some issues I found when testing my "new" RK3128 board
>> with the mainline kernel and adds some core functionality like SMP bringup,
>> usb and networking.
> before I discard this thread, is everything from here migrated to
> separate serieses or are there patches in this big pile that are still
> relevant on their own, that haven't been applied?
> [I lost track of what did go where ;-) ]

No worries - I kept track :)

Not everything is re-sent yet (sound nodes, RK3126/RK3128 split-up) but 
you can discard this and will re-send everything left in separate series 
(as I said [0])

[0] 
https://lore.kernel.org/linux-arm-kernel/170109134007.42627.12929766893521974712.b4-ty at kernel.org/T/#m63efa1c1379353b5cf764d2f9a260cf0329c864c

Regards,

Alex

>
>
> Thanks
> Heiko
>
>


From robh at kernel.org  Wed Dec 13 12:30:42 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 13 Dec 2023 14:30:42 -0600
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <ZXnthcg0BkEd-RgK@raptor>
References: <20231119165721.9849-1-alexandru.elisei@arm.com>
 <20231119165721.9849-12-alexandru.elisei@arm.com> <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
 <ZXiMiLz9ZyUdxUP8@raptor> <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
 <ZXmr-Kl9L2SO13--@raptor> <CAL_JsqL=P1Y6w38LD_xw+vK4CNqt22FW_FE9oi_XTLHVQEne7Q@mail.gmail.com>
 <ZXnE3724jYYSg4o6@raptor> <CAL_JsqJgTnuQjo13cKo1Ebm5j9tCRT8GhNavdqu5vwp+fdnTLw@mail.gmail.com>
 <ZXnthcg0BkEd-RgK@raptor>
Message-ID: <CAL_JsqLAW0--F8R0oTaajN3YpbK2KgE6Ypn8tk4_pf_s=xC+aw@mail.gmail.com>

On Wed, Dec 13, 2023 at 11:44?AM Alexandru Elisei
<alexandru.elisei at arm.com> wrote:
>
> On Wed, Dec 13, 2023 at 11:22:17AM -0600, Rob Herring wrote:
> > On Wed, Dec 13, 2023 at 8:51?AM Alexandru Elisei
> > <alexandru.elisei at arm.com> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> > > > On Wed, Dec 13, 2023 at 7:05?AM Alexandru Elisei
> > > > <alexandru.elisei at arm.com> wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > > > > On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
> > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > >
> > > > > > > Hi Rob,
> > > > > > >
> > > > > > > Thank you so much for the feedback, I'm not very familiar with device tree,
> > > > > > > and any comments are very useful.
> > > > > > >
> > > > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > > > > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > > > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > > > >
> > > > > > > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > > > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > > > > > >
> > > > > > > > > The DTB node for the tag storage region is defined as:
> > > > > > > > >
> > > > > > > > >         tags0: tag-storage at 8f8000000 {
> > > > > > > > >                 compatible = "arm,mte-tag-storage";
> > > > > > > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > > > > > > >                 block-size = <0x1000>;
> > > > > > > > >                 memory = <&memory0>;    // Associated tagged memory node
> > > > > > > > >         };
> > > > > > > >
> > > > > > > > I skimmed thru the discussion some. If this memory range is within
> > > > > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > > > > >
> > > > > > > Ok, will do that.
> > > > > > >
> > > > > > > If you don't mind, why do you say that it definitely belongs in
> > > > > > > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > > > > > > motivation.
> > > > > >
> > > > > > Simply so that /memory nodes describe all possible memory and
> > > > > > /reserved-memory is just adding restrictions. It's also because
> > > > > > /reserved-memory is what gets handled early, and we don't need
> > > > > > multiple things to handle early.
> > > > > >
> > > > > > > Tag storage is not DMA and can live anywhere in memory.
> > > > > >
> > > > > > Then why put it in DT at all? The only reason CMA is there is to set
> > > > > > the size. It's not even clear to me we need CMA in DT either. The
> > > > > > reasoning long ago was the kernel didn't do a good job of moving and
> > > > > > reclaiming contiguous space, but that's supposed to be better now (and
> > > > > > most h/w figured out they need IOMMUs).
> > > > > >
> > > > > > But for tag storage you know the size as it is a function of the
> > > > > > memory size, right? After all, you are validating the size is correct.
> > > > > > I guess there is still the aspect of whether you want enable MTE or
> > > > > > not which could be done in a variety of ways.
> > > > >
> > > > > Oh, sorry, my bad, I should have been clearer about this. I don't want to
> > > > > put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.
> > > >
> > > > Yes, I understand, but my point remains. Why do you need this in DT?
> > > > If the location doesn't matter and you can calculate the size from the
> > > > memory size, what else is there to add to the DT?
> > >
> > > I am afraid there has been a misunderstanding. What do you mean by
> > > "location doesn't matter"?
> >
> > You said:
> > > Tag storage is not DMA and can live anywhere in memory.
> >
> > Which I took as the kernel can figure out where to put it. But maybe
> > you meant the h/w platform can hard code it to be anywhere in memory?
> > If so, then yes, DT is needed.
>
> Ah, I see, sorry for not being clear enough, you are correct: tag storage
> is a hardware property, and software needs a mechanism (in this case, the
> dt) to discover its properties.
>
> >
> > > At the very least, Linux needs to know the address and size of a memory
> > > region to use it. The series is about using the tag storage memory for
> > > data. Tag storage cannot be described as a regular memory node because it
> > > cannot be tagged (and normal memory can).
> >
> > If the tag storage lives in the middle of memory, then it would be
> > described in the memory node, but removed by being in reserved-memory
> > node.
>
> I don't follow. Would you mind going into more details?

It goes back to what I said earlier about /memory nodes describing all
the memory. There's no reason to reserve memory if you haven't
described that range as memory to begin with. One could presumably
just have a memory node for each contiguous chunk and not need
/reserved-memory (ignoring the need to say what things are reserved
for). That would become very difficult to adjust. Note that the kernel
has a hardcoded limit of 64 reserved regions currently and that is not
enough for some people. Seems like a lot, but I have no idea how they
are (ab)using /reserved-memory.

Let me give an example. Presumably using MTE at all is configurable.
If you boot a kernel with MTE disabled (or older and not supporting
it), then I'd assume you'd want to use the tag storage for regular
memory. Well, If tag storage is already part of /memory, then all you
have to do is ignore the tag reserved-memory region. Tweaking the
memory nodes would be more work.


Also, I should point out that /memory and /reserved-memory nodes are
not used for UEFI boot.

Rob


From jernej.skrabec at gmail.com  Wed Dec 13 12:31:17 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 13 Dec 2023 21:31:17 +0100
Subject: [PATCH v4 097/115] pwm: sun4i: Make use of devm_pwmchip_alloc() function
In-Reply-To: <c79e120b120df9eedddaaf70364d28e15df23d91.1701860672.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701860672.git.u.kleine-koenig@pengutronix.de>
 <c79e120b120df9eedddaaf70364d28e15df23d91.1701860672.git.u.kleine-koenig@pengutronix.de>
Message-ID: <9208689.CDJkKcVGEf@archlinux>

On Wednesday, December 6, 2023 12:44:51 PM CET Uwe Kleine-K?nig wrote:
> This prepares the pwm-sun4i driver to further changes of the pwm core
> outlined in the commit introducing devm_pwmchip_alloc(). There is no
> intended semantical change and the driver should behave as before.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Reviewed-by: Jernej Skrabec <jernej.skrabec at gmail.com>

Best regards,
Jernej




From lkp at intel.com  Wed Dec 13 13:03:40 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 14 Dec 2023 05:03:40 +0800
Subject: [PATCH 2/3] usb: xhci-mtk: fix a short packet issue of gen1
 isoc-in transfer
In-Reply-To: <20231213063543.12435-2-chunfeng.yun@mediatek.com>
References: <20231213063543.12435-2-chunfeng.yun@mediatek.com>
Message-ID: <202312140415.r09Wbh8D-lkp@intel.com>

Hi Chunfeng,

kernel test robot noticed the following build errors:

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on usb/usb-next usb/usb-linus robh/for-next krzk/for-next linus/master v6.7-rc5 next-20231213]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Chunfeng-Yun/usb-xhci-mtk-fix-a-short-packet-issue-of-gen1-isoc-in-transfer/20231213-143959
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
patch link:    https://lore.kernel.org/r/20231213063543.12435-2-chunfeng.yun%40mediatek.com
patch subject: [PATCH 2/3] usb: xhci-mtk: fix a short packet issue of gen1 isoc-in transfer
config: arm-randconfig-001-20231213 (https://download.01.org/0day-ci/archive/20231214/202312140415.r09Wbh8D-lkp at intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231214/202312140415.r09Wbh8D-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312140415.r09Wbh8D-lkp at intel.com/

All errors (new ones prefixed by >>):

>> drivers/usb/host/xhci-mtk.c:184:12: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     184 |                 value |= FIELD_PREP(SCH3_RXFIFO_DEPTH_MASK, 2);
         |                          ^
   1 error generated.


vim +/FIELD_PREP +184 drivers/usb/host/xhci-mtk.c

   170	
   171	/*
   172	 * workaround: usb3.2 gen1 isoc rx hw issue
   173	 * host send out unexpected ACK afer device fininsh a burst transfer with
   174	 * a short packet.
   175	 */
   176	static void xhci_mtk_rxfifo_depth_set(struct xhci_hcd_mtk *mtk)
   177	{
   178		struct usb_hcd *hcd = mtk->hcd;
   179		u32 value;
   180	
   181		if (mtk->rxfifo_depth_quirk) {
   182			value = readl(hcd->regs + HSCH_CFG1);
   183			value &= ~SCH3_RXFIFO_DEPTH_MASK;
 > 184			value |= FIELD_PREP(SCH3_RXFIFO_DEPTH_MASK, 2);
   185			writel(value, hcd->regs + HSCH_CFG1);
   186		}
   187	}
   188	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Wed Dec 13 13:03:33 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 14 Dec 2023 05:03:33 +0800
Subject: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx
 platforms.
In-Reply-To: <20231213092850.1706042-2-sherry.sun@nxp.com>
References: <20231213092850.1706042-2-sherry.sun@nxp.com>
Message-ID: <202312140402.hZsD0IVQ-lkp@intel.com>

Hi Sherry,

kernel test robot noticed the following build warnings:

[auto build test WARNING on pci/next]
[also build test WARNING on pci/for-linus shawnguo/for-next robh/for-next linus/master v6.7-rc5 next-20231213]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Sherry-Sun/PCI-imx6-Add-pci-host-wakeup-support-on-imx-platforms/20231213-173031
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:    https://lore.kernel.org/r/20231213092850.1706042-2-sherry.sun%40nxp.com
patch subject: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx platforms.
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20231214/202312140402.hZsD0IVQ-lkp at intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231214/202312140402.hZsD0IVQ-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312140402.hZsD0IVQ-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> drivers/pci/controller/dwc/pci-imx6.c:1267:13: warning: no previous prototype for 'host_wake_irq_handler' [-Wmissing-prototypes]
    1267 | irqreturn_t host_wake_irq_handler(int irq, void *priv)
         |             ^~~~~~~~~~~~~~~~~~~~~


vim +/host_wake_irq_handler +1267 drivers/pci/controller/dwc/pci-imx6.c

  1266	
> 1267	irqreturn_t host_wake_irq_handler(int irq, void *priv)
  1268	{
  1269		struct imx6_pcie *imx6_pcie = priv;
  1270		struct device *dev = imx6_pcie->pci->dev;
  1271	
  1272		/* Notify PM core we are wakeup source */
  1273		pm_wakeup_event(dev, 0);
  1274		pm_system_wakeup();
  1275	
  1276		return IRQ_HANDLED;
  1277	}
  1278	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From festevam at gmail.com  Wed Dec 13 13:18:45 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 13 Dec 2023 18:18:45 -0300
Subject: [PATCH v2 1/3] arm64: dts: imx8mp-verdin: Fix USB connector description
Message-ID: <20231213211847.1096033-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The USB connector should not be placed under the dwc3 node.

Move the USB connector out of the SoC level and use port to describe
the connection to the dwc3 controller.

This fixes the following dt-schema warning:

imx8mp-verdin-wifi-mallow.dtb: usb at 32f10100: usb at 38100000: Unevaluated properties are not allowed ('connector' was unexpected)
	from schema $id: http://devicetree.org/schemas/usb/fsl,imx8mp-dwc3.yaml#
	
Signed-off-by: Fabio Estevam <festevam at denx.de>
---
Changes since v1:
- None

 .../boot/dts/freescale/imx8mp-verdin.dtsi     | 30 +++++++++++++------
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
index 04f2083c4ab2..c3305f0d4001 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
@@ -45,6 +45,23 @@ backlight_mezzanine: backlight-mezzanine {
 		status = "disabled";
 	};
 
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		id-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
+		label = "Type-C";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usb_1_id>;
+		self-powered;
+		type = "micro";
+		vbus-supply = <&reg_usb1_vbus>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 		pinctrl-names = "default";
@@ -835,15 +852,10 @@ &usb_dwc3_0 {
 	srp-disable;
 	usb-role-switch;
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		id-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
-		label = "Type-C";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usb_1_id>;
-		self-powered;
-		type = "micro";
-		vbus-supply = <&reg_usb1_vbus>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
-- 
2.34.1



From festevam at gmail.com  Wed Dec 13 13:18:46 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 13 Dec 2023 18:18:46 -0300
Subject: [PATCH v2 2/3] arm64: dts: imx8mp-venice: Fix USB connector description
In-Reply-To: <20231213211847.1096033-1-festevam@gmail.com>
References: <20231213211847.1096033-1-festevam@gmail.com>
Message-ID: <20231213211847.1096033-2-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The USB connector should not be placed under the dwc3 node.

Move the USB connector out of the SoC level and use port to describe
the connection to the dwc3 controller.

This fixes the following dt-schema warning:

imx8mp-venice-gw72xx-2x.dtb: usb at 38100000: Unevaluated properties are not allowed ('connector' was unexpected)
	from schema $id: http://devicetree.org/schemas/usb/snps,dwc3.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
Acked-by: Tim Harvey <tharvey at gateworks.com>
---
Changes since v1:
- Removed blank lines. (Tim)
- Collected Tim's ACK.

 .../dts/freescale/imx8mp-venice-gw71xx.dtsi   | 26 ++++++++++++++-----
 .../dts/freescale/imx8mp-venice-gw72xx.dtsi   | 26 ++++++++++++++-----
 .../dts/freescale/imx8mp-venice-gw73xx.dtsi   | 26 ++++++++++++++-----
 .../dts/freescale/imx8mp-venice-gw74xx.dts    | 26 ++++++++++++++-----
 4 files changed, 76 insertions(+), 28 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi
index bf47b5e9dd8c..0e8d0f3c7ea8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi
@@ -8,6 +8,21 @@
 #include <dt-bindings/phy/phy-imx8-pcie.h>
 
 / {
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon1>;
+		type = "micro";
+		label = "Type-C";
+		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	led-controller {
 		compatible = "gpio-leds";
 		pinctrl-names = "default";
@@ -132,13 +147,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon1>;
-		type = "micro";
-		label = "Type-C";
-		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi
index 28eb7c00a1d9..c24587c895e1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw72xx.dtsi
@@ -8,6 +8,21 @@
 #include <dt-bindings/phy/phy-imx8-pcie.h>
 
 / {
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon1>;
+		type = "micro";
+		label = "otg";
+		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	led-controller {
 		compatible = "gpio-leds";
 		pinctrl-names = "default";
@@ -182,13 +197,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon1>;
-		type = "micro";
-		label = "otg";
-		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi
index b0d42b18c5ce..628ffba69862 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw73xx.dtsi
@@ -8,6 +8,21 @@
 #include <dt-bindings/phy/phy-imx8-pcie.h>
 
 / {
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon1>;
+		type = "micro";
+		label = "otg";
+		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	led-controller {
 		compatible = "gpio-leds";
 		pinctrl-names = "default";
@@ -201,13 +216,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon1>;
-		type = "micro";
-		label = "otg";
-		id-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts
index dcf9bababffc..9caf7ca25444 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts
@@ -35,6 +35,21 @@ memory at 40000000 {
 		reg = <0x0 0x40000000 0 0x80000000>;
 	};
 
+	connector {
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon1>;
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		type = "micro";
+		label = "Type-C";
+		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	gpio-keys {
 		compatible = "gpio-keys";
 
@@ -692,13 +707,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon1>;
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		type = "micro";
-		label = "Type-C";
-		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
-- 
2.34.1



From festevam at gmail.com  Wed Dec 13 13:18:47 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 13 Dec 2023 18:18:47 -0300
Subject: [PATCH v2 3/3] arm64: dts: imx8mp-tqma8mpql-mba8mpxl: Fix USB connector description
In-Reply-To: <20231213211847.1096033-1-festevam@gmail.com>
References: <20231213211847.1096033-1-festevam@gmail.com>
Message-ID: <20231213211847.1096033-3-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

The USB connector should not be placed under the dwc3 node.

Move the USB connector out of the SoC level and use port to describe
the connection to the dwc3 controller.

This fixes the following dt-schema warning:

imx8mp-tqma8mpql-mba8mpxl.dtb: usb at 38100000: Unevaluated properties are not allowed ('connector' was unexpected)
	from schema $id: http://devicetree.org/schemas/usb/snps,dwc3.yaml#
	
Signed-off-by: Fabio Estevam <festevam at denx.de>
Reviewed-by: Alexander Stein <alexander.stein at ew.tq-group.com>
Tested-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
Changes since v1:
- Collected Alexander's tags. 

 .../freescale/imx8mp-tqma8mpql-mba8mpxl.dts   | 26 ++++++++++++++-----
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
index 4b161564a284..505b70cb2bd7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
@@ -55,6 +55,21 @@ clk_xtal25: clk-xtal25 {
 		clock-frequency = <25000000>;
 	};
 
+	connector {
+		compatible = "gpio-usb-b-connector", "usb-b-connector";
+		type = "micro";
+		label = "X29";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbcon0>;
+		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+
+		port {
+			usb_dr_connector: endpoint {
+				remote-endpoint = <&usb3_dwc>;
+			};
+		};
+	};
+
 	fan0: pwm-fan {
 		compatible = "pwm-fan";
 		pinctrl-names = "default";
@@ -625,13 +640,10 @@ &usb_dwc3_0 {
 	role-switch-default-mode = "peripheral";
 	status = "okay";
 
-	connector {
-		compatible = "gpio-usb-b-connector", "usb-b-connector";
-		type = "micro";
-		label = "X29";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_usbcon0>;
-		id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+	port {
+		usb3_dwc: endpoint {
+			remote-endpoint = <&usb_dr_connector>;
+		};
 	};
 };
 
-- 
2.34.1



From sukrut.bellary at linux.com  Wed Dec 13 13:32:19 2023
From: sukrut.bellary at linux.com (Sukrut Bellary)
Date: Wed, 13 Dec 2023 13:32:19 -0800
Subject: [PATCH] arm64: dts: ti: k3-am625-beagleplay: Use pwrseq for TI's wl18xx enable.
Message-ID: <20231213213219.566369-1-sukrut.bellary@linux.com>

BeaglePlay SBC has Texas Instrument's WL18xx WiFi Chipset.

BeaglePlay SBC:
https://www.beagleboard.org/boards/beagleplay

TI WL18XX:
https://www.ti.com/lit/ds/symlink/wl1807mod.pdf

Currently, WLAN_EN is configured as regulator and regulator-always-on.
During hibernation thaw, WiFi fails to come online.
During freeze/suspend,
the WLAN_EN line is not put to low '0' to power down the WiFi.
So during restore, the WiFi driver tries to load the FW without following
correct power sequence.
WLAN_EN => '1'/assert (high) to power-up the chipset.
WLAN_EN => '0'/deassert (low) to shut-down the chipset.

thaw failure log below:

Use mmc-pwrseq-simple to drive TI's WiFi (WL18xx) chipset enable 'WLAN_EN'.
mmc-pwrseq-simple provides power sequence flexibility with support for
post power-on and power-off delays.

================ thaw failure Log ================
[  161.418528] ------------[ cut here ]------------
[  161.418540] WARNING: CPU: 1 PID: 45 at drivers/net/wireless/ti/wlcore/sdio.c:123 wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]
[  161.418576] Modules linked in: br_netfilter bridge stp llc overlay usb_f_mass_storage usb_f_acm u_serial usb_f_ncm usb_f_rndis u_ether libcomposite wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce6[  161.418676] CPU: 1 PID: 45 Comm: kworker/u8:2 Not tainted 6.5.0-rc6+ #2
[  161.418684] Hardware name: BeagleBoard.org BeaglePlay (DT)
[  161.418691] Workqueue: events_unbound async_run_entry_fn
[  161.418711] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  161.418719] pc : wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]
[  161.418731] lr : wl12xx_sdio_raw_write+0x94/0x168 [wlcore_sdio]
[  161.418743] sp : ffff800082b43970
[  161.418746] x29: ffff800082b43970 x28: ffff800083c5b000 x27: 0000000000000003
[  161.418757] x26: ffff80007aab3800 x25: ffff800083c53000 x24: 0000000000000000
[  161.418767] x23: 0000000000004000 x22: ffff00000f938000 x21: ffff000005bd3010
[  161.418778] x20: 0000000000008000 x19: ffff000005bd2000 x18: 0000000000000000
[  161.418789] x17: 0000000000000100 x16: 0000000000000000 x15: f44fb9a9e0200014
[  161.418799] x14: 0000000000000049 x13: 000000000000038f x12: 0000000000000000
[  161.418809] x11: 0000000000000001 x10: 0000000000000a50 x9 : ffff800082b43550
[  161.418819] x8 : ffff000000ca2830 x7 : ffff00007fb92f40 x6 : 00000007e5428bd2
[  161.418829] x5 : 03ffffffffffffff x4 : ffff0000002569c0 x3 : 0000000000000000
[  161.418839] x2 : 0000000000000001 x1 : ffff000000256810 x0 : 00000000ffffff92
[  161.418850] Call trace:
[  161.418856]  wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]
[  161.418869]  wlcore_raw_write.constprop.0+0x4c/0xac [wlcore]
[  161.418931]  wlcore_boot_upload_firmware+0x140/0x3c0 [wlcore]
[  161.418973]  wl18xx_boot+0x574/0x77c [wl18xx]
[  161.419011]  wl1271_op_add_interface+0x5f0/0xaa8 [wlcore]
[  161.419052]  drv_add_interface+0x3c/0x88 [mac80211]
[  161.419228]  ieee80211_reconfig+0x1a8/0xf1c [mac80211]
[  161.419330]  ieee80211_resume+0x54/0x70 [mac80211]
[  161.419432]  wiphy_resume+0x84/0xf8 [cfg80211]
[  161.419562]  device_resume+0x84/0x178
[  161.419576]  async_resume+0x28/0x74
[  161.419584]  async_run_entry_fn+0x34/0xe0
[  161.419596]  process_one_work+0x1e0/0x340
[  161.419605]  worker_thread+0x68/0x428
[  161.419613]  kthread+0x114/0x118
[  161.419620]  ret_from_fork+0x10/0x20
[  161.419630] ---[ end trace 0000000000000000 ]---
[  161.419726] wl1271_sdio mmc2:0001:2: sdio write failed (-110)
[  162.341981] wlcore: using inverted interrupt logic: 2
[  170.553515] ------------[ cut here ]------------

[  180.315942] ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume+0x0/0xf8 [cfg80211] returns -110
[  180.316090] ieee80211 phy0: PM: failed to thaw async: error -110
======================================================

Full thaw failure log -
https://gist.github.com/sukrutb/8b02a9ffa7bd1cb9fb514220e9af097e

Suggested-by: Shengyu Qu <wiagn233 at outlook.com>
Signed-off-by: Sukrut Bellary <sukrut.bellary at linux.com>
---
 .../arm64/boot/dts/ti/k3-am625-beagleplay.dts | 25 ++++++++-----------
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
index eadbdd9ffe37..d388c5e78658 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
@@ -83,6 +83,15 @@ wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory at 9db00000 {
 		};
 	};
 
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_en_pins_default>;
+		post-power-on-delay-ms = <1>;
+		power-off-delay-us = <80>;
+		reset-gpios = <&main_gpio0 38 GPIO_ACTIVE_LOW>;
+	};
+
 	vsys_5v0: regulator-1 {
 		bootph-all;
 		compatible = "regulator-fixed";
@@ -105,20 +114,6 @@ vdd_3v3: regulator-2 {
 		regulator-boot-on;
 	};
 
-	wlan_en: regulator-3 {
-		/* OUTPUT of SN74AVC2T244DQMR */
-		compatible = "regulator-fixed";
-		regulator-name = "wlan_en";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-		enable-active-high;
-		regulator-always-on;
-		vin-supply = <&vdd_3v3>;
-		gpio = <&main_gpio0 38 GPIO_ACTIVE_HIGH>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&wifi_en_pins_default>;
-	};
-
 	vdd_3v3_sd: regulator-4 {
 		/* output of TPS22918DBVR-U21 */
 		bootph-all;
@@ -849,7 +844,6 @@ &sdhci1 {
 };
 
 &sdhci2 {
-	vmmc-supply = <&wlan_en>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&wifi_pins_default>, <&wifi_32k_clk>;
 	bus-width = <4>;
@@ -857,6 +851,7 @@ &sdhci2 {
 	ti,fails-without-test-cd;
 	cap-power-off-card;
 	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
 	ti,driver-strength-ohm = <50>;
 	assigned-clocks = <&k3_clks 157 158>;
 	assigned-clock-parents = <&k3_clks 157 160>;
-- 
2.34.1



From neil.armstrong at linaro.org  Wed Dec 13 13:59:35 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Wed, 13 Dec 2023 22:59:35 +0100
Subject: [PATCH v6 0/4] Add displays support for bsh-smm-s2/pro boards
In-Reply-To: <20231213175330.GA1582432-robh@kernel.org>
References: <20231213140437.2769508-1-dario.binacchi@amarulasolutions.com>
 <20231213175330.GA1582432-robh@kernel.org>
Message-ID: <98e93632-45e2-4d7b-bde2-4326d07b3c25@linaro.org>

Le 13/12/2023 ? 18:53, Rob Herring a ?crit?:
> On Wed, Dec 13, 2023 at 03:03:41PM +0100, Dario Binacchi wrote:
>> The series adds drivers for the displays used by bsh-smm-s2/pro boards.
>> This required applying some patches to the samsung-dsim driver.
>>
>> Changes in v6:
>> - Drop patches:
>>    - [06/10] drm/panel: Add Synaptics R63353 panel driver
> 
> The binding should have gone with this. I'll apply it then.
> 
> Rob

Oops I missed it,

Thanks for applying it

Neil


From robh at kernel.org  Wed Dec 13 14:11:24 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 13 Dec 2023 16:11:24 -0600
Subject: [PATCH v1 2/6] arm: arm64: dts: Enable cros-ec-spi as wake source
In-Reply-To: <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid>
References: <20231213110009.v1.1.Ifd0903f1c351e84376d71dbdadbd43931197f5ea@changeid>
 <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid>
Message-ID: <20231213221124.GB2115075-robh@kernel.org>

On Wed, Dec 13, 2023 at 11:00:20AM -0700, Mark Hasemeyer wrote:
> The cros_ec driver currently assumes that cros-ec-spi compatible device
> nodes are a wakeup-source even though the wakeup-source property is not
> defined.

If a device knows it is wakeup capable, why do you need a property too?
I haven't looked closely enough, but it smells like after patch 6, these 
properties would be required for wakeup? That would be an ABI break.

Rob


From bot at kernelci.org  Wed Dec 13 14:18:04 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Wed, 13 Dec 2023 14:18:04 -0800 (PST)
Subject: arm64/for-kernelci build: 1 build: 0 failed,
 1 passed (v6.7-rc5-83-gd5b235ec8eab1)
Message-ID: <657a2d9c.170a0220.ab149.2796@mx.google.com>

arm64/for-kernelci build: 1 build: 0 failed, 1 passed (v6.7-rc5-83-gd5b235ec8eab1)

Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v6.7-rc5-83-gd5b235ec8eab1/

Tree: arm64
Branch: for-kernelci
Git Describe: v6.7-rc5-83-gd5b235ec8eab1
Git Commit: d5b235ec8eab1ea9a3d1aa1ae4819c4a4dfaef31
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Built: 1 unique architecture

================================================================================

Detailed per-defconfig build reports:

--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) ? PASS, 0 errors, 0 warnings, 0 section mismatches

---
For more info write to <info at kernelci.org>


From mlevitsk at redhat.com  Wed Dec 13 14:25:50 2023
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu, 14 Dec 2023 00:25:50 +0200
Subject: [PATCH v4 10/12] KVM: x86: never write to memory from
 kvm_vcpu_check_block()
In-Reply-To: <ZXh8Nq_y_szj1WN0@google.com>
References: <20220921003201.1441511-11-seanjc@google.com>
	 <20231207010302.2240506-1-jmattson@google.com>
	 <ZXHw7tykubfG04Um@google.com>
	 <CALMp9eTT97oDmQT7pxeOMLQbt-371aMtC2Kev+-kWXVRDVrjeg@mail.gmail.com>
	 <ZXh8Nq_y_szj1WN0@google.com>
Message-ID: <5ca5592b21131f515e296afae006e5bb28b1fb87.camel@redhat.com>

On Tue, 2023-12-12 at 07:28 -0800, Sean Christopherson wrote:
> On Sun, Dec 10, 2023, Jim Mattson wrote:
> > On Thu, Dec 7, 2023 at 8:21?AM Sean Christopherson <seanjc at google.com> wrote:
> > > Doh.  We got the less obvious cases and missed the obvious one.
> > > 
> > > Ugh, and we also missed a related mess in kvm_guest_apic_has_interrupt().  That
> > > thing should really be folded into vmx_has_nested_events().
> > > 
> > > Good gravy.  And vmx_interrupt_blocked() does the wrong thing because that
> > > specifically checks if L1 interrupts are blocked.
> > > 
> > > Compile tested only, and definitely needs to be chunked into multiple patches,
> > > but I think something like this mess?
> > 
> > The proposed patch does not fix the problem. In fact, it messes things
> > up so much that I don't get any test results back.
> 
> Drat.
> 
> > Google has an internal K-U-T test that demonstrates the problem. I
> > will post it soon.
> 
> Received, I'll dig in soonish, though "soonish" might unfortunately might mean
> 2024.
> 

Hi,

So this is what I think:


KVM does have kvm_guest_apic_has_interrupt() for this exact purpose,
to check if nested APICv has a pending interrupt before halting.


However the problem is bigger - with APICv we have in essence 2 pending interrupt
bitmaps - the PIR and the IRR, and to know if the guest has a pending interrupt
one has in theory to copy PIR to IRR, then see if the max is larger then the current PPR.

Since we don't want to write to guest memory, and the IRR here resides in the guest memory,
I guess we have to do a 'dry-run' version of 'vmx_complete_nested_posted_interrupt' and call
it from  kvm_guest_apic_has_interrupt().

What do you think? I can prepare a patch for this.

Can you share a reproducer or write a new one that can be shared?

Best regards,
	Maxim Levitsky



From jmattson at google.com  Wed Dec 13 14:31:40 2023
From: jmattson at google.com (Jim Mattson)
Date: Wed, 13 Dec 2023 14:31:40 -0800
Subject: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()
In-Reply-To: <5ca5592b21131f515e296afae006e5bb28b1fb87.camel@redhat.com>
References: <20220921003201.1441511-11-seanjc@google.com> <20231207010302.2240506-1-jmattson@google.com>
 <ZXHw7tykubfG04Um@google.com> <CALMp9eTT97oDmQT7pxeOMLQbt-371aMtC2Kev+-kWXVRDVrjeg@mail.gmail.com>
 <ZXh8Nq_y_szj1WN0@google.com> <5ca5592b21131f515e296afae006e5bb28b1fb87.camel@redhat.com>
Message-ID: <CALMp9eQ69dGSix-9pJdEtEw9T1Mqz9E1eaf1-yGP9k4_nMZogw@mail.gmail.com>

On Wed, Dec 13, 2023 at 2:25?PM Maxim Levitsky <mlevitsk at redhat.com> wrote:
>
> On Tue, 2023-12-12 at 07:28 -0800, Sean Christopherson wrote:
> > On Sun, Dec 10, 2023, Jim Mattson wrote:
> > > On Thu, Dec 7, 2023 at 8:21?AM Sean Christopherson <seanjc at google.com> wrote:
> > > > Doh.  We got the less obvious cases and missed the obvious one.
> > > >
> > > > Ugh, and we also missed a related mess in kvm_guest_apic_has_interrupt().  That
> > > > thing should really be folded into vmx_has_nested_events().
> > > >
> > > > Good gravy.  And vmx_interrupt_blocked() does the wrong thing because that
> > > > specifically checks if L1 interrupts are blocked.
> > > >
> > > > Compile tested only, and definitely needs to be chunked into multiple patches,
> > > > but I think something like this mess?
> > >
> > > The proposed patch does not fix the problem. In fact, it messes things
> > > up so much that I don't get any test results back.
> >
> > Drat.
> >
> > > Google has an internal K-U-T test that demonstrates the problem. I
> > > will post it soon.
> >
> > Received, I'll dig in soonish, though "soonish" might unfortunately might mean
> > 2024.
> >
>
> Hi,
>
> So this is what I think:
>
>
> KVM does have kvm_guest_apic_has_interrupt() for this exact purpose,
> to check if nested APICv has a pending interrupt before halting.
>
>
> However the problem is bigger - with APICv we have in essence 2 pending interrupt
> bitmaps - the PIR and the IRR, and to know if the guest has a pending interrupt
> one has in theory to copy PIR to IRR, then see if the max is larger then the current PPR.
>
> Since we don't want to write to guest memory, and the IRR here resides in the guest memory,
> I guess we have to do a 'dry-run' version of 'vmx_complete_nested_posted_interrupt' and call
> it from  kvm_guest_apic_has_interrupt().
>
> What do you think? I can prepare a patch for this.
>
> Can you share a reproducer or write a new one that can be shared?

See https://lore.kernel.org/kvm/20231211185552.3856862-1-jmattson at google.com/.

> Best regards,
>         Maxim Levitsky
>


From robh at kernel.org  Wed Dec 13 14:42:01 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 13 Dec 2023 16:42:01 -0600
Subject: [PATCH] dt-bindings: display: samsung,exynos-mixer: Fix 'regs' typo
Message-ID: <20231213224201.2191358-1-robh@kernel.org>

The correct property name is 'reg' not 'regs'.

Fixes: 68e89bb36d58 ("dt-bindings: display: samsung,exynos-mixer: convert to dtschema")
Signed-off-by: Rob Herring <robh at kernel.org>
---
 .../bindings/display/samsung/samsung,exynos-mixer.yaml      | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
index 25d53fde92e1..597c9cc6a312 100644
--- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
@@ -85,7 +85,7 @@ allOf:
         clocks:
           minItems: 6
           maxItems: 6
-        regs:
+        reg:
           minItems: 2
           maxItems: 2
 
@@ -99,7 +99,7 @@ allOf:
         clocks:
           minItems: 4
           maxItems: 4
-        regs:
+        reg:
           minItems: 2
           maxItems: 2
 
@@ -116,7 +116,7 @@ allOf:
         clocks:
           minItems: 3
           maxItems: 3
-        regs:
+        reg:
           minItems: 1
           maxItems: 1
 
-- 
2.43.0



From mlevitsk at redhat.com  Wed Dec 13 14:44:12 2023
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu, 14 Dec 2023 00:44:12 +0200
Subject: [PATCH v4 10/12] KVM: x86: never write to memory from
 kvm_vcpu_check_block()
In-Reply-To: <CALMp9eQ69dGSix-9pJdEtEw9T1Mqz9E1eaf1-yGP9k4_nMZogw@mail.gmail.com>
References: <20220921003201.1441511-11-seanjc@google.com>
	 <20231207010302.2240506-1-jmattson@google.com>
	 <ZXHw7tykubfG04Um@google.com>
	 <CALMp9eTT97oDmQT7pxeOMLQbt-371aMtC2Kev+-kWXVRDVrjeg@mail.gmail.com>
	 <ZXh8Nq_y_szj1WN0@google.com>
	 <5ca5592b21131f515e296afae006e5bb28b1fb87.camel@redhat.com>
	 <CALMp9eQ69dGSix-9pJdEtEw9T1Mqz9E1eaf1-yGP9k4_nMZogw@mail.gmail.com>
Message-ID: <0c86e5ffb65f07cd3e444038d1f0ed39f0f4130a.camel@redhat.com>

On Wed, 2023-12-13 at 14:31 -0800, Jim Mattson wrote:
> On Wed, Dec 13, 2023 at 2:25?PM Maxim Levitsky <mlevitsk at redhat.com> wrote:
> > On Tue, 2023-12-12 at 07:28 -0800, Sean Christopherson wrote:
> > > On Sun, Dec 10, 2023, Jim Mattson wrote:
> > > > On Thu, Dec 7, 2023 at 8:21?AM Sean Christopherson <seanjc at google.com> wrote:
> > > > > Doh.  We got the less obvious cases and missed the obvious one.
> > > > > 
> > > > > Ugh, and we also missed a related mess in kvm_guest_apic_has_interrupt().  That
> > > > > thing should really be folded into vmx_has_nested_events().
> > > > > 
> > > > > Good gravy.  And vmx_interrupt_blocked() does the wrong thing because that
> > > > > specifically checks if L1 interrupts are blocked.
> > > > > 
> > > > > Compile tested only, and definitely needs to be chunked into multiple patches,
> > > > > but I think something like this mess?
> > > > 
> > > > The proposed patch does not fix the problem. In fact, it messes things
> > > > up so much that I don't get any test results back.
> > > 
> > > Drat.
> > > 
> > > > Google has an internal K-U-T test that demonstrates the problem. I
> > > > will post it soon.
> > > 
> > > Received, I'll dig in soonish, though "soonish" might unfortunately might mean
> > > 2024.
> > > 
> > 
> > Hi,
> > 
> > So this is what I think:
> > 
> > 
> > KVM does have kvm_guest_apic_has_interrupt() for this exact purpose,
> > to check if nested APICv has a pending interrupt before halting.
> > 
> > 
> > However the problem is bigger - with APICv we have in essence 2 pending interrupt
> > bitmaps - the PIR and the IRR, and to know if the guest has a pending interrupt
> > one has in theory to copy PIR to IRR, then see if the max is larger then the current PPR.
> > 
> > Since we don't want to write to guest memory, and the IRR here resides in the guest memory,
> > I guess we have to do a 'dry-run' version of 'vmx_complete_nested_posted_interrupt' and call
> > it from  kvm_guest_apic_has_interrupt().
> > 
> > What do you think? I can prepare a patch for this.
> > 
> > Can you share a reproducer or write a new one that can be shared?
> 
> See https://lore.kernel.org/kvm/20231211185552.3856862-1-jmattson at google.com/.

Thank you!

Best regards,
	Maxim Levitsky

> 
> > Best regards,
> >         Maxim Levitsky
> > 




From seanjc at google.com  Wed Dec 13 14:59:16 2023
From: seanjc at google.com (Sean Christopherson)
Date: Wed, 13 Dec 2023 14:59:16 -0800
Subject: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()
In-Reply-To: <5ca5592b21131f515e296afae006e5bb28b1fb87.camel@redhat.com>
References: <20220921003201.1441511-11-seanjc@google.com> <20231207010302.2240506-1-jmattson@google.com>
 <ZXHw7tykubfG04Um@google.com> <CALMp9eTT97oDmQT7pxeOMLQbt-371aMtC2Kev+-kWXVRDVrjeg@mail.gmail.com>
 <ZXh8Nq_y_szj1WN0@google.com> <5ca5592b21131f515e296afae006e5bb28b1fb87.camel@redhat.com>
Message-ID: <ZXo3REB8g-ZecT2U@google.com>

On Thu, Dec 14, 2023, Maxim Levitsky wrote:
> On Tue, 2023-12-12 at 07:28 -0800, Sean Christopherson wrote:
> > On Sun, Dec 10, 2023, Jim Mattson wrote:
> > > On Thu, Dec 7, 2023 at 8:21?AM Sean Christopherson <seanjc at google.com> wrote:
> > > > Doh.  We got the less obvious cases and missed the obvious one.
> > > > 
> > > > Ugh, and we also missed a related mess in kvm_guest_apic_has_interrupt().  That
> > > > thing should really be folded into vmx_has_nested_events().
> > > > 
> > > > Good gravy.  And vmx_interrupt_blocked() does the wrong thing because that
> > > > specifically checks if L1 interrupts are blocked.
> > > > 
> > > > Compile tested only, and definitely needs to be chunked into multiple patches,
> > > > but I think something like this mess?
> > > 
> > > The proposed patch does not fix the problem. In fact, it messes things
> > > up so much that I don't get any test results back.
> > 
> > Drat.
> > 
> > > Google has an internal K-U-T test that demonstrates the problem. I
> > > will post it soon.
> > 
> > Received, I'll dig in soonish, though "soonish" might unfortunately might mean
> > 2024.
> > 
> 
> Hi,
> 
> So this is what I think:
> 
> KVM does have kvm_guest_apic_has_interrupt() for this exact purpose,
> to check if nested APICv has a pending interrupt before halting.

For all intents and purposes, so was nested_ops->has_events().  I don't see
any reason to have two APIs that do the same thing, and the call to
kvm_guest_apic_has_interrupt() is wrong in that it doesn't verify that IRQs are
enabled for _L2_.  That's why my preference is to fold the two together.

> However the problem is bigger - with APICv we have in essence 2 pending
> interrupt bitmaps - the PIR and the IRR, and to know if the guest has a
> pending interrupt one has in theory to copy PIR to IRR, then see if the max
> is larger then the current PPR.

Yeah, this is what my untested hack-a-patch tried to do.

> Since we don't want to write to guest memory,

The changelog is misleading/wrong.  Writing guest memory is ok, what isn't safe
is blocking or sleeping, i.e. KVM must not trigger a host page fault due to
accessing a page that's been swapped out.  Read vs. write doesn't matter.

So KVM can safely read and write guest memory so long as it already mapped by 
kvm_vcpu_map() (or I suppose if we wrapped an access with pagefault_disable(),
but I can't think of a sane reason to do that).  E.g. nVMX can access a vCPU's
PID mapping, but synthesizing a nested VM-Exit will cause explosions on nSVM.

> and the IRR here resides in the guest memory, I guess we have to do a
> 'dry-run' version of 'vmx_complete_nested_posted_interrupt' and call it from
> kvm_guest_apic_has_interrupt().

nested_ops->has_events() is the much better fit, e.g. the naming won't get weird
and we can gate the whole thing on is_guest_mode().  Though we probably need a
wrapper to handle any commonalities between nVMX and nSVM.

> What do you think? I can prepare a patch for this.

As above, this is what I tried to do, sort of.  Though it's obviously broken.  We
don't need a full dry-run because KVM only needs to detect events that are unique
to L2, e.g. nVMX's preemption timer, MTF, and pending virtual interrupts (hmm,
I suspect nSVM's vNMI is broken too).  Things like INIT and SMI don't require
nested virtualization awareness because the event itself is tracked for the vCPU
as a whole.


From bot at kernelci.org  Wed Dec 13 15:01:21 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Wed, 13 Dec 2023 15:01:21 -0800 (PST)
Subject: arm64/for-kernelci baseline: 42 runs,
 2 regressions (v6.7-rc5-83-gd5b235ec8eab1)
Message-ID: <657a37c1.a70a0220.4d2f8.1216@mx.google.com>

arm64/for-kernelci baseline: 42 runs, 2 regressions (v6.7-rc5-83-gd5b235ec8eab1)

Regressions Summary
-------------------

platform                 | arch  | lab             | compiler | defconfig | regressions
-------------------------+-------+-----------------+----------+-----------+------------
imx8mm-innocomm-wb15-evk | arm64 | lab-pengutronix | gcc-10   | defconfig | 1          
k3-j721e-sk              | arm64 | lab-baylibre    | gcc-10   | defconfig | 1          

  Details:  https://kernelci.org/test/job/arm64/branch/for-kernelci/kernel/v6.7-rc5-83-gd5b235ec8eab1/plan/baseline/

  Test:     baseline
  Tree:     arm64
  Branch:   for-kernelci
  Describe: v6.7-rc5-83-gd5b235ec8eab1
  URL:      https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
  SHA:      d5b235ec8eab1ea9a3d1aa1ae4819c4a4dfaef31 


Test Regressions
---------------- 


platform                 | arch  | lab             | compiler | defconfig | regressions
-------------------------+-------+-----------------+----------+-----------+------------
imx8mm-innocomm-wb15-evk | arm64 | lab-pengutronix | gcc-10   | defconfig | 1          

  Details:     https://kernelci.org/test/plan/id/657a2d9b8b5c795ee5e1347a

  Results:     0 PASS, 1 FAIL, 0 SKIP
  Full config: defconfig
  Compiler:    gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
  Plain log:   https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc5-83-gd5b235ec8eab1/arm64/defconfig/gcc-10/lab-pengutronix/baseline-imx8mm-innocomm-wb15-evk.txt
  HTML log:    https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc5-83-gd5b235ec8eab1/arm64/defconfig/gcc-10/lab-pengutronix/baseline-imx8mm-innocomm-wb15-evk.html
  Rootfs:      http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230623.0/arm64/rootfs.cpio.gz 


  * baseline.login: https://kernelci.org/test/case/id/657a2d9b8b5c795ee5e1347b
        new failure (last pass: v6.7-rc5-71-gaedef4a80fb02) 
 


platform                 | arch  | lab             | compiler | defconfig | regressions
-------------------------+-------+-----------------+----------+-----------+------------
k3-j721e-sk              | arm64 | lab-baylibre    | gcc-10   | defconfig | 1          

  Details:     https://kernelci.org/test/plan/id/657a2efe659ff525f9e13477

  Results:     0 PASS, 1 FAIL, 0 SKIP
  Full config: defconfig
  Compiler:    gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
  Plain log:   https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc5-83-gd5b235ec8eab1/arm64/defconfig/gcc-10/lab-baylibre/baseline-k3-j721e-sk.txt
  HTML log:    https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc5-83-gd5b235ec8eab1/arm64/defconfig/gcc-10/lab-baylibre/baseline-k3-j721e-sk.html
  Rootfs:      http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230623.0/arm64/rootfs.cpio.gz 


  * baseline.login: https://kernelci.org/test/case/id/657a2efe659ff525f9e13478
        new failure (last pass: v6.7-rc5-71-gaedef4a80fb02) 
  


From namhyung at kernel.org  Wed Dec 13 15:29:23 2023
From: namhyung at kernel.org (Namhyung Kim)
Date: Wed, 13 Dec 2023 15:29:23 -0800
Subject: [PATCH v1 00/14] Clean up libperf cpumap's empty function
In-Reply-To: <20231129060211.1890454-1-irogers@google.com>
References: <20231129060211.1890454-1-irogers@google.com>
Message-ID: <CAM9d7civJ00iRmJ3CFfFcKteOLDaBY9tFkMTLi8vgjHipuBB1g@mail.gmail.com>

On Tue, Nov 28, 2023 at 10:02?PM Ian Rogers <irogers at google.com> wrote:
>
> Rename and clean up the use of libperf CPU map functions particularly
> focussing on perf_cpu_map__empty that may return true for maps
> containing CPUs but also with an "any CPU"/dummy value.
>
> perf_cpu_map__nr is also troubling in that iterating an empty CPU map
> will yield the "any CPU"/dummy value. Reduce the appearance of some
> calls to this by using the perf_cpu_map__for_each_cpu macro.
>
> Ian Rogers (14):
>   libperf cpumap: Rename perf_cpu_map__dummy_new
>   libperf cpumap: Rename and prefer sysfs for perf_cpu_map__default_new
>   libperf cpumap: Rename perf_cpu_map__empty
>   libperf cpumap: Replace usage of perf_cpu_map__new(NULL)
>   libperf cpumap: Add for_each_cpu that skips the "any CPU" case
>   libperf cpumap: Add any, empty and min helpers
>   perf arm-spe/cs-etm: Directly iterate CPU maps
>   perf intel-pt/intel-bts: Switch perf_cpu_map__has_any_cpu_or_is_empty
>     use
>   perf cpumap: Clean up use of perf_cpu_map__has_any_cpu_or_is_empty
>   perf top: Avoid repeated function calls
>   perf arm64 header: Remove unnecessary CPU map get and put
>   perf stat: Remove duplicate cpus_map_matched function
>   perf cpumap: Use perf_cpu_map__for_each_cpu when possible
>   libperf cpumap: Document perf_cpu_map__nr's behavior

Acked-by: Namhyung Kim <namhyung at kernel.org>

Thanks,
Namhyung


From graf at amazon.com  Wed Dec 13 15:36:32 2023
From: graf at amazon.com (Alexander Graf)
Date: Thu, 14 Dec 2023 00:36:32 +0100
Subject: [PATCH 03/15] kexec: Add Kexec HandOver (KHO) generation helpers
In-Reply-To: <20231213183614.GA14669@skinsburskii.>
References: <20231213000452.88295-1-graf@amazon.com>
 <20231213000452.88295-4-graf@amazon.com>
 <20231213183614.GA14669@skinsburskii.>
Message-ID: <6748dc7e-534e-4b45-8fa9-052fae591534@amazon.com>


On 13.12.23 19:36, Stanislav Kinsburskii wrote:
> On Wed, Dec 13, 2023 at 12:04:40AM +0000, Alexander Graf wrote:
>> +int register_kho_notifier(struct notifier_block *nb)
>> +{
>> +     return blocking_notifier_chain_register(&kho.chain_head, nb);
>> +}
>> +EXPORT_SYMBOL_GPL(register_kho_notifier);
>> +
>> +int unregister_kho_notifier(struct notifier_block *nb)
>> +{
>> +     return blocking_notifier_chain_unregister(&kho.chain_head, nb);
>> +}
>> +EXPORT_SYMBOL_GPL(unregister_kho_notifier);
>> +
>> +bool kho_is_active(void)
>> +{
>> +     return kho.active;
>> +}
>> +EXPORT_SYMBOL_GPL(kho_is_active);
>> +
> Why should these helpers be restricted to GPL code?


That's a simple one: Everything should be EXPORT_SYMBOL_GPL by default. 
You need to have really good reasons to export anything for non-GPL 
modules. I don't have a good reason for them, so it's GPL only :)


Alex





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From linus.walleij at linaro.org  Wed Dec 13 16:19:04 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 14 Dec 2023 01:19:04 +0100
Subject: [PATCH v2 2/2] spi: spl022: switch to use default spi_transfer_one_message()
In-Reply-To: <ae1940abd6ff6a9e77b4373cff60007c641a0c6c.1701274975.git.namcao@linutronix.de>
References: <cover.1701274975.git.namcao@linutronix.de> <ae1940abd6ff6a9e77b4373cff60007c641a0c6c.1701274975.git.namcao@linutronix.de>
Message-ID: <CACRpkdZfuKmg8gY1J+prF0L0=S7PSW+0ZuqM3HhNrB1sXcNG5g@mail.gmail.com>

On Wed, Nov 29, 2023 at 5:32?PM Nam Cao <namcao at linutronix.de> wrote:

> Except for polling mode, this driver's transfer_one_message() makes use
> of interrupt handler and tasklet. This is problematic because
> spi_transfer_delay_exec(), who may sleep, is called in interrupt handler
> and tasklet. This causes the following warning:
> BUG: sleeping function called from invalid context at drivers/spi/spi.c:1428
>
> Switch to use the default spi_transfer_one_message() instead, which
> calls spi_transfer_delay_exec() appropriately.
>
> Signed-off-by: Nam Cao <namcao at linutronix.de>
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> Tested with polling mode and interrupt mode, NOT with DMA mode.
> Support with testing very appreciated!

FWIW I tested this now on a device using DMA for the transfers
and everything works fine like before.

Yours,
Linus Walleij


From tim.c.chen at linux.intel.com  Wed Dec 13 16:41:04 2023
From: tim.c.chen at linux.intel.com (Tim Chen)
Date: Wed, 13 Dec 2023 16:41:04 -0800
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the
 scheduler
In-Reply-To: <20231212142730.998913-2-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
	 <20231212142730.998913-2-vincent.guittot@linaro.org>
Message-ID: <2e8807b68133f4b3a72227122a9d9a05f3fbf9d8.camel@linux.intel.com>

On Tue, 2023-12-12 at 15:27 +0100, Vincent Guittot wrote:
> Provide to the scheduler a feedback about the temporary max available
> capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
> filtered as the pressure will happen for dozens ms or more.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>  drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++++++++++++++++++++++++
>  include/linux/cpufreq.h   | 10 ++++++++
>  2 files changed, 58 insertions(+)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 44db4f59c4cc..7d5f71be8d29 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2563,6 +2563,50 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
>  }
>  EXPORT_SYMBOL(cpufreq_get_policy);
>  
> +DEFINE_PER_CPU(unsigned long, cpufreq_pressure);
> +EXPORT_PER_CPU_SYMBOL_GPL(cpufreq_pressure);
> +
> +/**
> + * cpufreq_update_pressure() - Update cpufreq pressure for CPUs
> + * @cpus        : The related CPUs for which max capacity has been reduced
> + * @capped_freq : The maximum allowed frequency that CPUs can run at
> + *
> + * Update the value of cpufreq pressure for all @cpus in the mask. The
> + * cpumask should include all (online+offline) affected CPUs, to avoid
> + * operating on stale data when hot-plug is used for some CPUs. The
> + * @capped_freq reflects the currently allowed max CPUs frequency due to
> + * freq_qos capping. It might be also a boost frequency value, which is bigger
> + * than the internal 'capacity_freq_ref' max frequency. In such case the
> + * pressure value should simply be removed, since this is an indication that
> + * there is no capping. The @capped_freq must be provided in kHz.
> + */
> +static void cpufreq_update_pressure(const struct cpumask *cpus,
> +				      unsigned long capped_freq)
> +{
> +	unsigned long max_capacity, capacity, pressure;
> +	u32 max_freq;
> +	int cpu;
> +
> +	cpu = cpumask_first(cpus);
> +	max_capacity = arch_scale_cpu_capacity(cpu);
> +	max_freq = arch_scale_freq_ref(cpu);
> +
> +	/*
> +	 * Handle properly the boost frequencies, which should simply clean
> +	 * the thermal pressure value.
> +	 */
> +	if (max_freq <= capped_freq)
> +		capacity = max_capacity;
> +	else
> +		capacity = mult_frac(max_capacity, capped_freq, max_freq);
> +
> +	pressure = max_capacity - capacity;
> +
> +
> +	for_each_cpu(cpu, cpus)
> +		WRITE_ONCE(per_cpu(cpufreq_pressure, cpu), pressure);

Seems like the pressure value computed from the first CPU applies to all CPU.
Will this be valid for non-homogeneous CPUs that could have different
max_freq and max_capacity?

Tim


From joel at jms.id.au  Wed Dec 13 16:43:30 2023
From: joel at jms.id.au (Joel Stanley)
Date: Thu, 14 Dec 2023 11:13:30 +1030
Subject: [PATCH 00/11] Modify DTS of META Minerva CMM BMC(AST2600)
In-Reply-To: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
References: <20231212075200.983536-1-yangchen.openbmc@gmail.com>
Message-ID: <CACPK8Xc7XjgBj-SQH45=omjEXd-BpXgcQDp6s8UkJ8QsbnYSPg@mail.gmail.com>

On Tue, 12 Dec 2023 at 18:24, Yang Chen <yangchen.openbmc at gmail.com> wrote:
>
> This series modifies the DTS of the Minerva CMM which is the board on the
> META platform that uses the ASPEED SoC(AST2600).

Looks good. I've merged this for submission in v6.8.

Reviewed-by: Joel Stanley <joel at jms.id.au>


From andre.przywara at arm.com  Wed Dec 13 16:56:46 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 00:56:46 +0000
Subject: [PATCH 2/3] dt-bindings: arm: sunxi: document Transpeed 8K618-T
 board name
In-Reply-To: <7d352882-5f6f-4c8b-a8c5-76ea31c2ae31@linaro.org>
References: <20231212010859.11571-1-andre.przywara@arm.com>
	<20231212010859.11571-3-andre.przywara@arm.com>
	<7d352882-5f6f-4c8b-a8c5-76ea31c2ae31@linaro.org>
Message-ID: <20231214005646.15c2b69e@minigeek.lan>

On Tue, 12 Dec 2023 10:01:56 +0100
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

Hi,

> On 12/12/2023 02:08, Andre Przywara wrote:
> > The Transpeed 8K618-T TV box is a Chinese Android TV box, using the
> > Allwinner H618 SoC.
> > 
> > Add the board/SoC compatible string pair to the list of known boards.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> > ---
> >  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > index 11c5ce941dd7e..5e91110cc9eb8 100644
> > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > @@ -868,6 +868,11 @@ properties:
> >            - const: topwise,a721
> >            - const: allwinner,sun4i-a10
> >  
> > +      - description: Transpeed 8K618-T
> > +        items:
> > +          - const: transpeed,8k618-t
> > +          - const: allwinner,sun50i-h618  
> 
> Assuming you kept the existing order (its style) of a file:

Ah, a good point. The file seems to be sort alphabetically after the
"description" name, though there are some outliers. Will send a patch
to fix them.
But at least this entry is correctly sorted.
 
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Thanks!
Andre

> 
> Best regards,
> Krzysztof
> 
> 



From andre.przywara at arm.com  Wed Dec 13 16:58:10 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 00:58:10 +0000
Subject: [PATCH 1/3] dt-bindings: vendor-prefixes: add Transpeed
In-Reply-To: <cb28ca67-8648-4199-92d0-e3129277b624@linaro.org>
References: <20231212010859.11571-1-andre.przywara@arm.com>
	<20231212010859.11571-2-andre.przywara@arm.com>
	<cb28ca67-8648-4199-92d0-e3129277b624@linaro.org>
Message-ID: <20231214005810.7b0318c6@minigeek.lan>

On Tue, 12 Dec 2023 10:01:25 +0100
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

> On 12/12/2023 02:08, Andre Przywara wrote:
> > This is a name used by some Chinese TV boxes, add it to the bindings.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > index 309b94c328c84..d9dd3f929cdcf 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > @@ -1438,6 +1438,8 @@ patternProperties:
> >      description: Traverse Technologies Australia Pty Ltd
> >    "^tronfy,.*":
> >      description: Tronfy
> > +  "^transpeed,.*":
> > +    description: Transpeed  
> 
> Please keep alphabetical order.

Argh, sorry, managed indeed to mess up this super simple patch!

Will fix it, thanks for having a look and spotting this!

Cheers,
Andre

> Best regards,
> Krzysztof
> 
> 



From samuel.holland at sifive.com  Wed Dec 13 17:03:20 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 13 Dec 2023 19:03:20 -0600
Subject: [RFC PATCH 10/12] drm/amd/display: Use
 ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <87h6kpdj20.fsf@mail.lhotse>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-11-samuel.holland@sifive.com>
 <87h6kpdj20.fsf@mail.lhotse>
Message-ID: <7ed20fcf-8a9d-40d5-b913-b5d2da443cd6@sifive.com>

On 2023-12-11 6:23 AM, Michael Ellerman wrote:
> Hi Samuel,
> 
> Thanks for trying to clean all this up.
> 
> One problem below.
> 
> Samuel Holland <samuel.holland at sifive.com> writes:
>> Now that all previously-supported architectures select
>> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
>> of the existing list of architectures. It can also take advantage of the
>> common kernel-mode FPU API and method of adjusting CFLAGS.
>>
>> Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
> ...
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>> index 4ae4720535a5..b64f917174ca 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>> @@ -87,20 +78,9 @@ void dc_fpu_begin(const char *function_name, const int line)
>>  	WARN_ON_ONCE(!in_task());
>>  	preempt_disable();
>>  	depth = __this_cpu_inc_return(fpu_recursion_depth);
>> -
>>  	if (depth == 1) {
>> -#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
>> +		BUG_ON(!kernel_fpu_available());
>>  		kernel_fpu_begin();
>> -#elif defined(CONFIG_PPC64)
>> -		if (cpu_has_feature(CPU_FTR_VSX_COMP))
>> -			enable_kernel_vsx();
>> -		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
>> -			enable_kernel_altivec();
>  
> Note altivec.
> 
>> -		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
>> -			enable_kernel_fp();
>> -#elif defined(CONFIG_ARM64)
>> -		kernel_neon_begin();
>> -#endif
>>  	}
>>  
>>  	TRACE_DCN_FPU(true, function_name, line, depth);
>> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>> index ea7d60f9a9b4..5aad0f572ba3 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
>> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>> @@ -25,40 +25,8 @@
>>  # It provides the general basic services required by other DAL
>>  # subcomponents.
>>  
>> -ifdef CONFIG_X86
>> -dml_ccflags-$(CONFIG_CC_IS_GCC) := -mhard-float
>> -dml_ccflags := $(dml_ccflags-y) -msse
>> -endif
>> -
>> -ifdef CONFIG_PPC64
>> -dml_ccflags := -mhard-float -maltivec
>> -endif
> 
> And altivec is enabled in the flags there.
> 
> That doesn't match your implementation for powerpc in patch 7, which
> only deals with float.
> 
> I suspect the AMD driver actually doesn't need altivec enabled, but I
> don't know that for sure. It compiles without it, but I don't have a GPU
> to actually test. I've added Timothy on Cc who added the support for
> powerpc to the driver originally, hopefully he has a test system.

I tested this series on a POWER9 system with an AMD Radeon RX 6400 GPU (which
requires this FPU code to initialize), and got functioning graphics output.

> Anyway if that's true that it doesn't need altivec we should probably do
> a lead-up patch that drops altivec from the AMD driver explicitly, eg.
> as below.

That makes sense to me. Do you want to provide your Signed-off-by so I can send
this patch with your authorship?

Regards,
Samuel

> cheers
> 
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
> index 4ae4720535a5..0de16796466b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
> @@ -92,11 +92,7 @@ void dc_fpu_begin(const char *function_name, const int line)
>  #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
>  		kernel_fpu_begin();
>  #elif defined(CONFIG_PPC64)
> -		if (cpu_has_feature(CPU_FTR_VSX_COMP))
> -			enable_kernel_vsx();
> -		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
> -			enable_kernel_altivec();
> -		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
> +		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
>  			enable_kernel_fp();
>  #elif defined(CONFIG_ARM64)
>  		kernel_neon_begin();
> @@ -125,11 +121,7 @@ void dc_fpu_end(const char *function_name, const int line)
>  #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
>  		kernel_fpu_end();
>  #elif defined(CONFIG_PPC64)
> -		if (cpu_has_feature(CPU_FTR_VSX_COMP))
> -			disable_kernel_vsx();
> -		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
> -			disable_kernel_altivec();
> -		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
> +		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
>  			disable_kernel_fp();
>  #elif defined(CONFIG_ARM64)
>  		kernel_neon_end();
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> index 6042a5a6a44f..554c39024a40 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> @@ -31,7 +31,7 @@ dml_ccflags := $(dml_ccflags-y) -msse
>  endif
>  
>  ifdef CONFIG_PPC64
> -dml_ccflags := -mhard-float -maltivec
> +dml_ccflags := -mhard-float
>  endif
>  
>  ifdef CONFIG_ARM64
> diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
> index acff3449b8d7..7b51364084b5 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
> @@ -30,7 +30,7 @@ dml2_ccflags := $(dml2_ccflags-y) -msse
>  endif
>  
>  ifdef CONFIG_PPC64
> -dml2_ccflags := -mhard-float -maltivec
> +dml2_ccflags := -mhard-float
>  endif
>  
>  ifdef CONFIG_ARM64



From andre.przywara at arm.com  Wed Dec 13 17:23:57 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 01:23:57 +0000
Subject: [PATCH 3/3] arm64: dts: allwinner: h618: add Transpeed 8K618-T
 TV box
In-Reply-To: <4533903.LvFx2qVVIh@archlinux>
References: <20231212010859.11571-1-andre.przywara@arm.com>
	<20231212010859.11571-4-andre.przywara@arm.com>
	<4533903.LvFx2qVVIh@archlinux>
Message-ID: <20231214012357.37526feb@minigeek.lan>

On Wed, 13 Dec 2023 20:22:55 +0100
Jernej ?krabec <jernej.skrabec at gmail.com> wrote:

Hi Jernej,

thanks for having a look, much appreciated.

> On Tuesday, December 12, 2023 2:08:59 AM CET Andre Przywara wrote:
> > This is a Chinese TV box, probably very similar if not identical to
> > various other cheap TV boxes with the same specs:
> >       - Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache)
> >       - 2 or 4GiB DDR3L DRAM
> >       - 32, 64, or 128 GiB eMMC flash
> >       - AXP313a PMIC
> >       - 100 Mbit/s Ethernet (using yet unsupported internal PHY)
> >       - HDMI port
> >       - 2 * USB 2.0 ports
> >       - microSD card slot
> >       - 3.5mm A/V port
> >       - 7-segment display
> >       - 5V barrel plug power supply
> > 
> > The PCB provides holes for soldering a UART header or cable, this is
> > connected to the debug UART0. UART1 is used for the Bluetooth chip,
> > although this isn't working yet.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> > ---
> >  arch/arm64/boot/dts/allwinner/Makefile        |   1 +
> >  .../sun50i-h618-transpeed-8k618-t.dts         | 164 ++++++++++++++++++
> >  2 files changed, 165 insertions(+)
> >  create mode 100644
> > arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> > b/arch/arm64/boot/dts/allwinner/Makefile index 3aca6787a1679..91d505b385de5
> > 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -43,3 +43,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> >  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
> >  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero3.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-transpeed-8k618-t.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts new file
> > mode 100644
> > index 0000000000000..fd7ea7bcde2c1
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
> > @@ -0,0 +1,164 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (C) 2023 Arm Ltd.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h616.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > +	model = "Transpeed 8K618-T";
> > +	compatible = "transpeed,8k618-t", "allwinner,sun50i-h618";
> > +
> > +	aliases {
> > +		serial0 = &uart0;
> > +		serial1 = &uart1;  
> 
> Any particular reason for above alias?

Not really, and since UART1 is used for Bluetooth, its name should not
matter at all, the BT driver will just use its parent device.
Will remove it.

> 
> > +	};
> > +
> > +	chosen {
> > +		stdout-path = "serial0:115200n8";
> > +	};
> > +
> > +	reg_vcc5v: vcc5v {
> > +		/* board wide 5V supply directly from the DC input */
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "vcc-5v";
> > +		regulator-min-microvolt = <5000000>;
> > +		regulator-max-microvolt = <5000000>;
> > +		regulator-always-on;
> > +	};
> > +
> > +	reg_vcc3v3: vcc3v3 {
> > +		/* discrete 3.3V regulator */
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "vcc-3v3";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		regulator-always-on;
> > +	};
> > +};
> > +
> > +&ehci0 {
> > +	status = "okay";
> > +};
> > +
> > +&ehci1 {
> > +	status = "okay";
> > +};
> > +
> > +&ir {
> > +	status = "okay";
> > +};
> > +
> > +&mmc0 {
> > +	vmmc-supply = <&reg_dldo1>;
> > +	cd-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>;	/* PI16 */
> > +	bus-width = <4>;
> > +	status = "okay";
> > +};
> > +
> > +&mmc2 {
> > +	vmmc-supply = <&reg_dldo1>;
> > +	vqmmc-supply = <&reg_aldo1>;
> > +	bus-width = <8>;
> > +	non-removable;
> > +	cap-mmc-hw-reset;
> > +	mmc-ddr-1_8v;
> > +	mmc-hs200-1_8v;
> > +	status = "okay";
> > +};
> > +
> > +&ohci0 {
> > +	status = "okay";
> > +};
> > +
> > +&ohci1 {
> > +	status = "okay";
> > +};
> > +
> > +&r_i2c {
> > +	status = "okay";
> > +
> > +	axp313: pmic at 36 {
> > +		compatible = "x-powers,axp313a";
> > +		reg = <0x36>;
> > +		#interrupt-cells = <1>;
> > +		interrupt-controller;
> > +
> > +		vin1-supply = <&reg_vcc5v>;
> > +		vin2-supply = <&reg_vcc5v>;
> > +		vin3-supply = <&reg_vcc5v>;
> > +
> > +		regulators {
> > +			/* Supplies VCC-PLL, so needs to be always   
> on. */
> > +			reg_aldo1: aldo1 {
> > +				regulator-always-on;
> > +				regulator-min-microvolt =   
> <1800000>;
> > +				regulator-max-microvolt =   
> <1800000>;
> > +				regulator-name = "vcc1v8";  
> 
> It would be great to expand all PMIC regulator names with (known) areas they 
> power, so something like "vcc1v8-pll-pc". With that, I think you can remove 
> comments.

Alright, will do. I will stick with those users that I am pretty sure
of, either because they are mentioned in the BSP DT, or because they
must be supplied by that rail: there seem to be only one 1.8V source.

Cheers,
Andre

> 
> Best regards,
> Jernej
> 
> > +			};
> > +
> > +			/* Supplies VCC-IO, so needs to be always on.   
> */
> > +			reg_dldo1: dldo1 {
> > +				regulator-always-on;
> > +				regulator-min-microvolt =   
> <3300000>;
> > +				regulator-max-microvolt =   
> <3300000>;
> > +				regulator-name = "vcc3v3";
> > +			};
> > +
> > +			reg_dcdc1: dcdc1 {
> > +				regulator-always-on;
> > +				regulator-min-microvolt =   
> <810000>;
> > +				regulator-max-microvolt =   
> <990000>;
> > +				regulator-name = "vdd-gpu-sys";
> > +			};
> > +
> > +			reg_dcdc2: dcdc2 {
> > +				regulator-always-on;
> > +				regulator-min-microvolt =   
> <810000>;
> > +				regulator-max-microvolt =   
> <1100000>;
> > +				regulator-name = "vdd-cpu";
> > +			};
> > +
> > +			reg_dcdc3: dcdc3 {
> > +				regulator-always-on;
> > +				regulator-min-microvolt =   
> <1360000>;
> > +				regulator-max-microvolt =   
> <1360000>;
> > +				regulator-name = "vdd-dram";
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +&pio {
> > +	vcc-pc-supply = <&reg_aldo1>;
> > +	vcc-pg-supply = <&reg_dldo1>;
> > +	vcc-ph-supply = <&reg_dldo1>;
> > +	vcc-pi-supply = <&reg_dldo1>;
> > +};
> > +
> > +&uart0 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&uart0_ph_pins>;
> > +	status = "okay";
> > +};
> > +
> > +&uart1 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
> > +	uart-has-rtscts;
> > +	status = "okay";
> > +};
> > +
> > +&usbotg {
> > +	dr_mode = "host";	/* USB A type receptable */
> > +	status = "okay";
> > +};
> > +
> > +&usbphy {
> > +	status = "okay";
> > +};  
> 
> 
> 
> 
> 



From shawnguo at kernel.org  Wed Dec 13 17:50:00 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 09:50:00 +0800
Subject: [PATCH] ARM: dts: imx25: Fix the iim compatible string
In-Reply-To: <20231206200033.2360532-1-festevam@gmail.com>
References: <20231206200033.2360532-1-festevam@gmail.com>
Message-ID: <20231214015000.GP270430@dragon>

On Wed, Dec 06, 2023 at 05:00:33PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per imx-iim.yaml, the compatible string should only contain a single
> entry.
> 
> Use it as "fsl,imx25-iim" to fix the following dt-schema warning:
> 
> imx25-karo-tx25.dtb: efuse at 53ff0000: compatible: ['fsl,imx25-iim', 'fsl,imx27-iim'] is too long
> 	from schema $id: http://devicetree.org/schemas/nvmem/imx-iim.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From andre.przywara at arm.com  Wed Dec 13 17:53:10 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 01:53:10 +0000
Subject: [PATCH v2 1/3] dt-bindings: vendor-prefixes: add Transpeed
In-Reply-To: <20231214015312.17363-1-andre.przywara@arm.com>
References: <20231214015312.17363-1-andre.przywara@arm.com>
Message-ID: <20231214015312.17363-2-andre.przywara@arm.com>

This is a name used by some Chinese TV boxes, add it to the bindings.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c84..c545c63b316d4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1434,6 +1434,8 @@ patternProperties:
     description: TPO
   "^tq,.*":
     description: TQ-Systems GmbH
+  "^transpeed,.*":
+    description: Transpeed
   "^traverse,.*":
     description: Traverse Technologies Australia Pty Ltd
   "^tronfy,.*":
-- 
2.35.8



From andre.przywara at arm.com  Wed Dec 13 17:53:11 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 01:53:11 +0000
Subject: [PATCH v2 2/3] dt-bindings: arm: sunxi: document Transpeed 8K618-T board name
In-Reply-To: <20231214015312.17363-1-andre.przywara@arm.com>
References: <20231214015312.17363-1-andre.przywara@arm.com>
Message-ID: <20231214015312.17363-3-andre.przywara@arm.com>

The Transpeed 8K618-T TV box is a Chinese Android TV box, using the
Allwinner H618 SoC.

Add the board/SoC compatible string pair to the list of known boards.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 11c5ce941dd7e..5e91110cc9eb8 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -868,6 +868,11 @@ properties:
           - const: topwise,a721
           - const: allwinner,sun4i-a10
 
+      - description: Transpeed 8K618-T
+        items:
+          - const: transpeed,8k618-t
+          - const: allwinner,sun50i-h618
+
       - description: Utoo P66
         items:
           - const: utoo,p66
-- 
2.35.8



From andre.przywara at arm.com  Wed Dec 13 17:53:09 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 01:53:09 +0000
Subject: [PATCH v2 0/3] arm64: dts: allwinner: Add Transpeed 8K618-T TV box
Message-ID: <20231214015312.17363-1-andre.przywara@arm.com>

A quick update, with the few fixes for issues that reviewers spotted.
See below for a changelog.
================================

The Transpeed 8K618-T is one example of various cheap Chinese TV boxes
using the Allwinner H618 SoC. It comes with up to 4GB DRAM and up to
128GB eMMC flash, plus the usual HDMI, 100Mbit Ethernet, WiFi/BT and
dual USB ports, not to forget the mandatory microSD card slot.
More details: https://linux-sunxi.org/Transpeed_8K618-T

Ethernet relies on the yet unsupported integrated PHY, and the HDMI
output is similarly not yet supported, but patches exist that await
polishing for mainline submission.
Meanwhile USB and eMMC plus SD card work, so you can hook up an USB
Ethernet or WiFi adapter to get things going.

This series is the usual trilogy of DT support patches: adding the vendor
name in patch 1, the board compatible name in patch 2, and the actual
.dts file in patch 3.

Please have a look!

Thanks,
Andre

Changelog v1 .. v2:
- fix alphabetical ordering in vendor-prefixes
- remove unneeded UART1 alias
- extend regulator names, drop now redundant comments

Andre Przywara (3):
  dt-bindings: vendor-prefixes: add Transpeed
  dt-bindings: arm: sunxi: document Transpeed 8K618-T board name
  arm64: dts: allwinner: h618: add Transpeed 8K618-T TV box

 .../devicetree/bindings/arm/sunxi.yaml        |   5 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../sun50i-h618-transpeed-8k618-t.dts         | 161 ++++++++++++++++++
 4 files changed, 169 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts

-- 
2.35.8



From andre.przywara at arm.com  Wed Dec 13 17:53:12 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 01:53:12 +0000
Subject: [PATCH v2 3/3] arm64: dts: allwinner: h618: add Transpeed 8K618-T TV box
In-Reply-To: <20231214015312.17363-1-andre.przywara@arm.com>
References: <20231214015312.17363-1-andre.przywara@arm.com>
Message-ID: <20231214015312.17363-4-andre.przywara@arm.com>

This is a Chinese TV box, probably very similar if not identical to
various other cheap TV boxes with the same specs:
      - Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache)
      - 2 or 4GiB DDR3L DRAM
      - 32, 64, or 128 GiB eMMC flash
      - AXP313a PMIC
      - 100 Mbit/s Ethernet (using yet unsupported internal PHY)
      - HDMI port
      - 2 * USB 2.0 ports
      - microSD card slot
      - 3.5mm A/V port
      - 7-segment display
      - 5V barrel plug power supply

The PCB provides holes for soldering a UART header or cable, this is
connected to the debug UART0. UART1 is used for the Bluetooth chip,
although this isn't working yet.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../sun50i-h618-transpeed-8k618-t.dts         | 161 ++++++++++++++++++
 2 files changed, 162 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 3aca6787a1679..91d505b385de5 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -43,3 +43,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero3.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-transpeed-8k618-t.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
new file mode 100644
index 0000000000000..8ea1fd41aebaa
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2023 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Transpeed 8K618-T";
+	compatible = "transpeed,8k618-t", "allwinner,sun50i-h618";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	reg_vcc5v: vcc5v {
+		/* board wide 5V supply directly from the DC input */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-5v";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	reg_vcc3v3: vcc3v3 {
+		/* discrete 3.3V regulator */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&ir {
+	status = "okay";
+};
+
+&mmc0 {
+	vmmc-supply = <&reg_dldo1>;
+	cd-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>;	/* PI16 */
+	bus-width = <4>;
+	status = "okay";
+};
+
+&mmc2 {
+	vmmc-supply = <&reg_dldo1>;
+	vqmmc-supply = <&reg_aldo1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	mmc-ddr-1_8v;
+	mmc-hs200-1_8v;
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&r_i2c {
+	status = "okay";
+
+	axp313: pmic at 36 {
+		compatible = "x-powers,axp313a";
+		reg = <0x36>;
+		#interrupt-cells = <1>;
+		interrupt-controller;
+
+		vin1-supply = <&reg_vcc5v>;
+		vin2-supply = <&reg_vcc5v>;
+		vin3-supply = <&reg_vcc5v>;
+
+		regulators {
+			reg_aldo1: aldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc-1v8-pll";
+			};
+
+			reg_dldo1: dldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc-3v3-io-mmc";
+			};
+
+			reg_dcdc1: dcdc1 {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <990000>;
+				regulator-name = "vdd-gpu-sys";
+			};
+
+			reg_dcdc2: dcdc2 {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-cpu";
+			};
+
+			reg_dcdc3: dcdc3 {
+				regulator-always-on;
+				regulator-min-microvolt = <1360000>;
+				regulator-max-microvolt = <1360000>;
+				regulator-name = "vdd-dram";
+			};
+		};
+	};
+};
+
+&pio {
+	vcc-pc-supply = <&reg_aldo1>;
+	vcc-pg-supply = <&reg_dldo1>;
+	vcc-ph-supply = <&reg_dldo1>;
+	vcc-pi-supply = <&reg_dldo1>;
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_ph_pins>;
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&usbotg {
+	dr_mode = "host";	/* USB A type receptable */
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+};
-- 
2.35.8



From shawnguo at kernel.org  Wed Dec 13 18:00:53 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:00:53 +0800
Subject: [PATCH 1/1] arm64: dts: imx8qm: Fix edma3 power-domains and
 interrupt number
In-Reply-To: <20231206201256.1113800-1-Frank.Li@nxp.com>
References: <20231206201256.1113800-1-Frank.Li@nxp.com>
Message-ID: <20231214020053.GQ270430@dragon>

On Wed, Dec 06, 2023 at 03:12:55PM -0500, Frank Li wrote:
> Fixed a kernel dump when access edma3 registers.
> 
> [    1.517547] SError Interrupt on CPU1, code 0x00000000bf000002 -- SError
> [    1.517556] CPU: 1 PID: 59 Comm: kworker/u8:2 Not tainted 6.7.0-rc3-next-20231129-dirty #3
> [    1.517564] Hardware name: Freescale i.MX8QM MEK (DT)
> [    1.517570] Workqueue: events_unbound deferred_probe_work_func
> [    1.517593] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [    1.517601] pc : vsnprintf+0x60/0x770
> [    1.517612] lr : snprintf+0x58/0x80
> [    1.517619] sp : ffff800082f0b9e0
> [    1.517622] x29: ffff800082f0b9e0 x28: ffff8000819a8af8 x27: ffff000801f90080
> [    1.517632] x26: ffff000801f90510 x25: 0000000000000001 x24: 0000000000000020
> [    1.517640] x23: 00000000ffffffd8 x22: ffff000800114800 x21: ffff800082f0baf0
> [    1.517650] x20: ffff000801f90698 x19: ffff000801f906b8 x18: ffffffffffffffff
> [    1.517659] x17: 6e6f632d616d642e x16: 3030303066396135 x15: ffff800102f0b687
> [    1.517668] x14: 0000000000000000 x13: 30206e6168632065 x12: 74697277203a7265
> [    1.517677] x11: 6c6c6f72746e6f63 x10: 2d616d642e303030 x9 : 72656c6c6f72746e
> [    1.517686] x8 : ffff000800396740 x7 : 205d333337383035 x6 : ffff800082f0baf0
> [    1.517694] x5 : 00000000ffffffd8 x4 : ffff000800396740 x3 : ffff800082f0ba70
> [    1.517703] x2 : ffff8000819a8af8 x1 : ffff800082f0baf0 x0 : 0000000000000025
> [    1.517713] Kernel panic - not syncing: Asynchronous SError Interrupt
> [    1.517718] CPU: 1 PID: 59 Comm: kworker/u8:2 Not tainted 6.7.0-rc3-next-20231129-dirty #3
> [    1.517724] Hardware name: Freescale i.MX8QM MEK (DT)
> [    1.517727] Workqueue: events_unbound deferred_probe_work_func
> [    1.517736] Call trace:
> [    1.517739]  dump_backtrace+0x90/0xe8
> [    1.517752]  show_stack+0x18/0x24
> [    1.517761]  dump_stack_lvl+0x48/0x60
> [    1.517771]  dump_stack+0x18/0x24
> [    1.517780]  panic+0x36c/0x3ac
> [    1.517789]  nmi_panic+0x48/0x94
> [    1.517796]  arm64_serror_panic+0x6c/0x78
> [    1.517801]  do_serror+0x3c/0x78
> [    1.517806]  el1h_64_error_handler+0x30/0x48
> [    1.517813]  el1h_64_error+0x64/0x68
> [    1.517819]  vsnprintf+0x60/0x770
> [    1.517827]  snprintf+0x58/0x80
> [    1.517834]  fsl_edma_probe+0x2ac/0x830
> 
> It is eDMA1 at QM, which have the same register with eDMA3 at qxp.
> 
> Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]")
> Signed-off-by: Frank Li <Frank.Li at nxp.com>

Hi Frank,

Did you see the fix [1] from Xiaolei?  It has landed on Linus' tree.

Shawn

[1] https://lore.kernel.org/all/20231110072531.1957891-1-xiaolei.wang at windriver.com/

> ---
>  .../boot/dts/freescale/imx8qm-ss-dma.dtsi     | 27 +++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
> index 01539df335f8c..5d76b4dee4cef 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
> @@ -44,6 +44,33 @@ can2_lpcg: clock-controller at 5acf0000 {
>  	};
>  };
>  
> +/* It is eDMA1 in 8QM RM, but 8QXP it is eDMA3 */
> +&edma3 {
> +	reg = <0x5a9f0000 0x210000>;
> +	dma-channels = <10>;
> +	interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
> +		     <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>,
> +		     <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH>,
> +		     <GIC_SPI 427 IRQ_TYPE_LEVEL_HIGH>,
> +		     <GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH>,
> +		     <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
> +		     <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>,
> +		     <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
> +		     <GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>,
> +		     <GIC_SPI 433 IRQ_TYPE_LEVEL_HIGH>;
> +	power-domains = <&pd IMX_SC_R_DMA_1_CH0>,
> +			<&pd IMX_SC_R_DMA_1_CH1>,
> +			<&pd IMX_SC_R_DMA_1_CH2>,
> +			<&pd IMX_SC_R_DMA_1_CH3>,
> +			<&pd IMX_SC_R_DMA_1_CH4>,
> +			<&pd IMX_SC_R_DMA_1_CH5>,
> +			<&pd IMX_SC_R_DMA_1_CH6>,
> +			<&pd IMX_SC_R_DMA_1_CH7>,
> +			<&pd IMX_SC_R_DMA_1_CH8>,
> +			<&pd IMX_SC_R_DMA_1_CH9>;
> +};
> +
> +/* It is edma0 in 8QM RM, but it is eDMA2 at 8QXP */
>  &edma2 {
>  	reg = <0x5a1f0000 0x170000>;
>  	#dma-cells = <3>;
> -- 
> 2.34.1
> 


From Frank.li at nxp.com  Wed Dec 13 18:05:39 2023
From: Frank.li at nxp.com (Frank Li)
Date: Wed, 13 Dec 2023 21:05:39 -0500
Subject: [PATCH 1/1] arm64: dts: imx8qm: Fix edma3 power-domains and
 interrupt numbery
In-Reply-To: <20231214020053.GQ270430@dragon>
References: <20231206201256.1113800-1-Frank.Li@nxp.com>
 <20231214020053.GQ270430@dragon>
Message-ID: <ZXpi8/asoBMBAtmz@lizhi-Precision-Tower-5810>

On Thu, Dec 14, 2023 at 10:00:53AM +0800, Shawn Guo wrote:
> On Wed, Dec 06, 2023 at 03:12:55PM -0500, Frank Li wrote:
> > Fixed a kernel dump when access edma3 registers.
> > 
> > [    1.517547] SError Interrupt on CPU1, code 0x00000000bf000002 -- SError
> > [    1.517556] CPU: 1 PID: 59 Comm: kworker/u8:2 Not tainted 6.7.0-rc3-next-20231129-dirty #3
> > [    1.517564] Hardware name: Freescale i.MX8QM MEK (DT)
> > [    1.517570] Workqueue: events_unbound deferred_probe_work_func
> > [    1.517593] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [    1.517601] pc : vsnprintf+0x60/0x770
> > [    1.517612] lr : snprintf+0x58/0x80
> > [    1.517619] sp : ffff800082f0b9e0
> > [    1.517622] x29: ffff800082f0b9e0 x28: ffff8000819a8af8 x27: ffff000801f90080
> > [    1.517632] x26: ffff000801f90510 x25: 0000000000000001 x24: 0000000000000020
> > [    1.517640] x23: 00000000ffffffd8 x22: ffff000800114800 x21: ffff800082f0baf0
> > [    1.517650] x20: ffff000801f90698 x19: ffff000801f906b8 x18: ffffffffffffffff
> > [    1.517659] x17: 6e6f632d616d642e x16: 3030303066396135 x15: ffff800102f0b687
> > [    1.517668] x14: 0000000000000000 x13: 30206e6168632065 x12: 74697277203a7265
> > [    1.517677] x11: 6c6c6f72746e6f63 x10: 2d616d642e303030 x9 : 72656c6c6f72746e
> > [    1.517686] x8 : ffff000800396740 x7 : 205d333337383035 x6 : ffff800082f0baf0
> > [    1.517694] x5 : 00000000ffffffd8 x4 : ffff000800396740 x3 : ffff800082f0ba70
> > [    1.517703] x2 : ffff8000819a8af8 x1 : ffff800082f0baf0 x0 : 0000000000000025
> > [    1.517713] Kernel panic - not syncing: Asynchronous SError Interrupt
> > [    1.517718] CPU: 1 PID: 59 Comm: kworker/u8:2 Not tainted 6.7.0-rc3-next-20231129-dirty #3
> > [    1.517724] Hardware name: Freescale i.MX8QM MEK (DT)
> > [    1.517727] Workqueue: events_unbound deferred_probe_work_func
> > [    1.517736] Call trace:
> > [    1.517739]  dump_backtrace+0x90/0xe8
> > [    1.517752]  show_stack+0x18/0x24
> > [    1.517761]  dump_stack_lvl+0x48/0x60
> > [    1.517771]  dump_stack+0x18/0x24
> > [    1.517780]  panic+0x36c/0x3ac
> > [    1.517789]  nmi_panic+0x48/0x94
> > [    1.517796]  arm64_serror_panic+0x6c/0x78
> > [    1.517801]  do_serror+0x3c/0x78
> > [    1.517806]  el1h_64_error_handler+0x30/0x48
> > [    1.517813]  el1h_64_error+0x64/0x68
> > [    1.517819]  vsnprintf+0x60/0x770
> > [    1.517827]  snprintf+0x58/0x80
> > [    1.517834]  fsl_edma_probe+0x2ac/0x830
> > 
> > It is eDMA1 at QM, which have the same register with eDMA3 at qxp.
> > 
> > Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]")
> > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> 
> Hi Frank,
> 
> Did you see the fix [1] from Xiaolei?  It has landed on Linus' tree.

Sorry, not yet!. He have not fixed irq numbers. 
Let me do addition fix.

Frank

> 
> Shawn
> 
> [1] https://lore.kernel.org/all/20231110072531.1957891-1-xiaolei.wang at windriver.com/
> 
> > ---
> >  .../boot/dts/freescale/imx8qm-ss-dma.dtsi     | 27 +++++++++++++++++++
> >  1 file changed, 27 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
> > index 01539df335f8c..5d76b4dee4cef 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
> > @@ -44,6 +44,33 @@ can2_lpcg: clock-controller at 5acf0000 {
> >  	};
> >  };
> >  
> > +/* It is eDMA1 in 8QM RM, but 8QXP it is eDMA3 */
> > +&edma3 {
> > +	reg = <0x5a9f0000 0x210000>;
> > +	dma-channels = <10>;
> > +	interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
> > +		     <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>,
> > +		     <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH>,
> > +		     <GIC_SPI 427 IRQ_TYPE_LEVEL_HIGH>,
> > +		     <GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH>,
> > +		     <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
> > +		     <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>,
> > +		     <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
> > +		     <GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>,
> > +		     <GIC_SPI 433 IRQ_TYPE_LEVEL_HIGH>;
> > +	power-domains = <&pd IMX_SC_R_DMA_1_CH0>,
> > +			<&pd IMX_SC_R_DMA_1_CH1>,
> > +			<&pd IMX_SC_R_DMA_1_CH2>,
> > +			<&pd IMX_SC_R_DMA_1_CH3>,
> > +			<&pd IMX_SC_R_DMA_1_CH4>,
> > +			<&pd IMX_SC_R_DMA_1_CH5>,
> > +			<&pd IMX_SC_R_DMA_1_CH6>,
> > +			<&pd IMX_SC_R_DMA_1_CH7>,
> > +			<&pd IMX_SC_R_DMA_1_CH8>,
> > +			<&pd IMX_SC_R_DMA_1_CH9>;
> > +};
> > +
> > +/* It is edma0 in 8QM RM, but it is eDMA2 at 8QXP */
> >  &edma2 {
> >  	reg = <0x5a1f0000 0x170000>;
> >  	#dma-cells = <3>;
> > -- 
> > 2.34.1
> > 


From shawnguo at kernel.org  Wed Dec 13 18:07:37 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:07:37 +0800
Subject: [PATCH v2] ARM: dts: imx25/27: Pass timing0
In-Reply-To: <20231206201405.2376738-1-festevam@gmail.com>
References: <20231206201405.2376738-1-festevam@gmail.com>
Message-ID: <20231214020737.GR270430@dragon>

On Wed, Dec 06, 2023 at 05:14:05PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per display-timings.yaml, the 'timing' pattern should be used to
> describe the display timings.
> 
> Change it accordingly to fix the following dt-schema warning:
> 
> imx27-apf27dev.dtb: display-timings: '800x480' does not match any of the regexes: '^timing', 'pinctrl-[0-9]+'
> 	from schema $id: http://devicetree.org/schemas/display/panel/display-timings.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 18:08:55 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:08:55 +0800
Subject: [PATCH 1/1] arm64: dts: imx8qm: Fix edma3 power-domains and
 interrupt numbery
In-Reply-To: <ZXpi8/asoBMBAtmz@lizhi-Precision-Tower-5810>
References: <20231206201256.1113800-1-Frank.Li@nxp.com>
 <20231214020053.GQ270430@dragon>
 <ZXpi8/asoBMBAtmz@lizhi-Precision-Tower-5810>
Message-ID: <20231214020855.GS270430@dragon>

On Wed, Dec 13, 2023 at 09:05:39PM -0500, Frank Li wrote:
> On Thu, Dec 14, 2023 at 10:00:53AM +0800, Shawn Guo wrote:
> > On Wed, Dec 06, 2023 at 03:12:55PM -0500, Frank Li wrote:
> > > Fixed a kernel dump when access edma3 registers.
> > > 
> > > [    1.517547] SError Interrupt on CPU1, code 0x00000000bf000002 -- SError
> > > [    1.517556] CPU: 1 PID: 59 Comm: kworker/u8:2 Not tainted 6.7.0-rc3-next-20231129-dirty #3
> > > [    1.517564] Hardware name: Freescale i.MX8QM MEK (DT)
> > > [    1.517570] Workqueue: events_unbound deferred_probe_work_func
> > > [    1.517593] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > [    1.517601] pc : vsnprintf+0x60/0x770
> > > [    1.517612] lr : snprintf+0x58/0x80
> > > [    1.517619] sp : ffff800082f0b9e0
> > > [    1.517622] x29: ffff800082f0b9e0 x28: ffff8000819a8af8 x27: ffff000801f90080
> > > [    1.517632] x26: ffff000801f90510 x25: 0000000000000001 x24: 0000000000000020
> > > [    1.517640] x23: 00000000ffffffd8 x22: ffff000800114800 x21: ffff800082f0baf0
> > > [    1.517650] x20: ffff000801f90698 x19: ffff000801f906b8 x18: ffffffffffffffff
> > > [    1.517659] x17: 6e6f632d616d642e x16: 3030303066396135 x15: ffff800102f0b687
> > > [    1.517668] x14: 0000000000000000 x13: 30206e6168632065 x12: 74697277203a7265
> > > [    1.517677] x11: 6c6c6f72746e6f63 x10: 2d616d642e303030 x9 : 72656c6c6f72746e
> > > [    1.517686] x8 : ffff000800396740 x7 : 205d333337383035 x6 : ffff800082f0baf0
> > > [    1.517694] x5 : 00000000ffffffd8 x4 : ffff000800396740 x3 : ffff800082f0ba70
> > > [    1.517703] x2 : ffff8000819a8af8 x1 : ffff800082f0baf0 x0 : 0000000000000025
> > > [    1.517713] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > [    1.517718] CPU: 1 PID: 59 Comm: kworker/u8:2 Not tainted 6.7.0-rc3-next-20231129-dirty #3
> > > [    1.517724] Hardware name: Freescale i.MX8QM MEK (DT)
> > > [    1.517727] Workqueue: events_unbound deferred_probe_work_func
> > > [    1.517736] Call trace:
> > > [    1.517739]  dump_backtrace+0x90/0xe8
> > > [    1.517752]  show_stack+0x18/0x24
> > > [    1.517761]  dump_stack_lvl+0x48/0x60
> > > [    1.517771]  dump_stack+0x18/0x24
> > > [    1.517780]  panic+0x36c/0x3ac
> > > [    1.517789]  nmi_panic+0x48/0x94
> > > [    1.517796]  arm64_serror_panic+0x6c/0x78
> > > [    1.517801]  do_serror+0x3c/0x78
> > > [    1.517806]  el1h_64_error_handler+0x30/0x48
> > > [    1.517813]  el1h_64_error+0x64/0x68
> > > [    1.517819]  vsnprintf+0x60/0x770
> > > [    1.517827]  snprintf+0x58/0x80
> > > [    1.517834]  fsl_edma_probe+0x2ac/0x830
> > > 
> > > It is eDMA1 at QM, which have the same register with eDMA3 at qxp.
> > > 
> > > Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]")
> > > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > 
> > Hi Frank,
> > 
> > Did you see the fix [1] from Xiaolei?  It has landed on Linus' tree.
> 
> Sorry, not yet!. He have not fixed irq numbers. 
> Let me do addition fix.

Please copy Xiaolei on your fix, thanks!

Shawn


From shawnguo at kernel.org  Wed Dec 13 18:09:47 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:09:47 +0800
Subject: [PATCH] ARM: dts: imx27-apf27dev: Fix LED name
In-Reply-To: <20231206201905.2383591-1-festevam@gmail.com>
References: <20231206201905.2383591-1-festevam@gmail.com>
Message-ID: <20231214020947.GT270430@dragon>

On Wed, Dec 06, 2023 at 05:19:05PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per leds-gpio.yaml, the led names should start with 'led'.
> 
> Change it to fix the following dt-schema warning:
> 
> imx27-apf27dev.dtb: leds: 'user' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
> 	from schema $id: http://devicetree.org/schemas/leds/leds-gpio.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 18:11:23 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:11:23 +0800
Subject: [PATCH] ARM: dts: imx23-sansa: Use preferred i2c-gpios properties
In-Reply-To: <20231207101212.2495648-1-festevam@gmail.com>
References: <20231207101212.2495648-1-festevam@gmail.com>
Message-ID: <20231214021123.GU270430@dragon>

On Thu, Dec 07, 2023 at 07:12:12AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> The 'gpios' property to describe the SDA and SCL GPIOs is considered
> deprecated according to i2c-gpio.yaml.
> 
> Switch to the preferred 'sda-gpios' and 'scl-gpios' properties.
> 
> This fixes the following schema warnings:
> 
> imx23-sansa.dtb: i2c-0: 'sda-gpios' is a required property
> 	from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml#
> imx23-sansa.dtb: i2c-0: 'scl-gpios' is a required property
> 	from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 18:12:02 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:12:02 +0800
Subject: [PATCH] ARM: dts: imx23/28: Fix the DMA controller node name
In-Reply-To: <20231207102631.2498659-1-festevam@gmail.com>
References: <20231207102631.2498659-1-festevam@gmail.com>
Message-ID: <20231214021202.GV270430@dragon>

On Thu, Dec 07, 2023 at 07:26:31AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per fsl,mxs-dma.yaml, the node name should be 'dma-controller'.
> 
> Change it to fix the following dt-schema warning.
> 
> imx28-apf28.dtb: dma-apbx at 80024000: $nodename:0: 'dma-apbx at 80024000' does not match '^dma-controller(@.*)?$'
> 	from schema $id: http://devicetree.org/schemas/dma/fsl,mxs-dma.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 18:13:52 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:13:52 +0800
Subject: [PATCH] arm64: dts: imx93: Fix the micfil clock-names entries
In-Reply-To: <20231207122056.2526158-1-festevam@gmail.com>
References: <20231207122056.2526158-1-festevam@gmail.com>
Message-ID: <20231214021352.GW270430@dragon>

On Thu, Dec 07, 2023 at 09:20:56AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> fsl,micfil.yaml defines the clock-names in the following sequence:
> 
>   clock-names:
>     items:
>       - const: ipg_clk
>       - const: ipg_clk_app
>       - const: pll8k
>       - const: pll11k
>       - const: clkext3
>     minItems: 2
> 
> imx93.dtsi currently misses the 'pll11k' entry and jump to 'clkext3'.
> 
> This leads to the following dt-schema warning:
> 
> imx93-11x11-evk.dtb: micfil at 44520000: clock-names:3: 'pll11k' was expected
> 	from schema $id: http://devicetree.org/schemas/sound/fsl,micfil.yaml#
> 
> Fix the warning by describing the clocks up to 'pll8k' as 'clkext3'
> is assigned to a dummy clock.
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 18:17:34 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:17:34 +0800
Subject: [PATCH v5 10/10] arm64: dts: imx8mn-bsh-smm-s2/pro: add display
 setup
In-Reply-To: <20231207141723.108004-11-dario.binacchi@amarulasolutions.com>
References: <20231207141723.108004-1-dario.binacchi@amarulasolutions.com>
 <20231207141723.108004-11-dario.binacchi@amarulasolutions.com>
Message-ID: <20231214021734.GX270430@dragon>

On Thu, Dec 07, 2023 at 03:16:39PM +0100, Dario Binacchi wrote:
> From: Michael Trimarchi <michael at amarulasolutions.com>
> 
> Add the display and nodes required for its operation.
> 
> Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
> Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>
> 
> ---
> 
> (no changes since v3)
> 
> Changes in v3:
> - Replace "synaptics,r63353" compatible with "syna,r63353", as
>   required by vendor-prefixes.yaml.
> - Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
>   into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.
> 
> Changes in v2:
> - Adjust the mipi_dsi node based on the latest patches merged into
>   the mainline in the dtsi files it includes.
> - Added to the series the following patches:
>   - 0001 drm/bridge: Fix bridge disable logic
>   - 0002 drm/bridge: Fix a use case in the bridge disable logic
>   - 0003 samsung-dsim: enter display mode in the enable() callback
>   - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting
> 
>  .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
>  .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++++++++++++++
>  2 files changed, 122 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
> index 22a754d438f1..bbb07c650da9 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
> @@ -7,6 +7,7 @@
>  /dts-v1/;
>  
>  #include "imx8mn.dtsi"
> +#include "imx8mn-bsh-smm-s2-display.dtsi"
>  
>  / {
>  	chosen {
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
> new file mode 100644
> index 000000000000..f0a924cbe548
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
> @@ -0,0 +1,121 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2021 BSH
> + */
> +
> +/ {
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm1 0 700000 0>;	/* 700000 ns = 1337Hz */
> +		brightness-levels = <0 100>;
> +		num-interpolated-steps = <100>;
> +		default-brightness-level = <50>;
> +		status = "okay";
> +	};
> +
> +	reg_3v3_dvdd: regulator-3v3-O3 {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_dvdd>;
> +		regulator-name = "3v3-dvdd-supply";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
> +	};
> +
> +	reg_v3v3_avdd: regulator-3v3-O2 {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_avdd>;
> +		regulator-name = "3v3-avdd-supply";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio1 5 GPIO_ACTIVE_LOW>;
> +	};
> +};
> +
> +&pwm1 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_bl>;

We usually end property list with 'status'.

> +};
> +
> +&lcdif {
> +	status = "okay";

Ditto

> +	assigned-clocks = <&clk IMX8MN_VIDEO_PLL1>;
> +	assigned-clock-rates = <594000000>;
> +};
> +
> +&pgc_dispmix {
> +	assigned-clocks = <&clk IMX8MN_CLK_DISP_AXI>, <&clk IMX8MN_CLK_DISP_APB>;
> +	assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_1000M>, <&clk IMX8MN_SYS_PLL1_800M>;
> +	assigned-clock-rates = <500000000>, <200000000>;
> +};
> +
> +&mipi_dsi {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	status = "okay";

Ditto

> +	samsung,esc-clock-frequency = <20000000>;
> +	samsung,pll-clock-frequency = <12000000>;
> +
> +	panel at 0 {
> +		compatible = "sharp,ls068b3sx02", "syna,r63353";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_panel>;
> +		reg = <0>;
> +
> +		backlight = <&backlight>;
> +		dvdd-supply = <&reg_3v3_dvdd>;
> +		avdd-supply = <&reg_v3v3_avdd>;
> +		reset-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
> +
> +		port {
> +			panel_in: endpoint {
> +				remote-endpoint = <&mipi_dsi_out>;
> +			};
> +		};
> +
> +	};
> +
> +	ports {
> +		port at 1 {
> +			reg = <1>;

Have a newline between properties and child node.

> +			mipi_dsi_out: endpoint {
> +				remote-endpoint = <&panel_in>;
> +			};
> +		};
> +	};
> +};
> +
> +&gpu {
> +	status = "okay";
> +};
> +
> +&iomuxc {
> +
> +	/* This is for both PWM and voltage regulators for display */
> +	pinctrl_bl: pwm1grp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_GPIO1_IO01_PWM1_OUT	0x16
> +		>;
> +	};
> +
> +	pinctrl_panel: panelgrp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_SAI3_RXC_GPIO4_IO29	0x16	/* panel reset */
> +		>;
> +	};
> +
> +	pinctrl_dvdd: dvddgrp {
> +		fsl,pins = <
> +			MX8MN_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x16	/* VDD 3V3_VO3 */
> +		>;
> +	};
> +
> +	pinctrl_avdd: avddgrp {

Can we sort the pinctrl node alphabetically?

Shawn

> +		fsl,pins = <
> +			MX8MN_IOMUXC_GPIO1_IO05_GPIO1_IO5	0x16	/* VDD 3V3_VO2 */
> +		>;
> +	};
> +};
> -- 
> 2.43.0
> 


From shawnguo at kernel.org  Wed Dec 13 18:22:50 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:22:50 +0800
Subject: [PATCH 1/3] arm64: dts: imx8mm: Reduce GPU to nominal speed
In-Reply-To: <20231128200219.226038-1-aford173@gmail.com>
References: <20231128200219.226038-1-aford173@gmail.com>
Message-ID: <20231214022250.GY270430@dragon>

On Tue, Nov 28, 2023 at 02:02:16PM -0600, Adam Ford wrote:
> When the GPU nodes were added, the GPU_PLL_OUT was configured
> for 1000MHz, but this requires the SoC to run in overdrive mode
> which requires an elevated voltage operating point.
> 
> Since this may run some boards out of spec, the default clock
> should be set to 800MHz for nominal operating mode. Boards
> that run at the higher voltage can update their clocks
> accordingly.
> 
> Fixes: 4523be8e46be ("arm64: dts: imx8mm: Add GPU nodes for 2D and 3D core")
> Signed-off-by: Adam Ford <aford173 at gmail.com>

Applied all, thanks!


From shawnguo at kernel.org  Wed Dec 13 18:23:12 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:23:12 +0800
Subject: [PATCH 1/2] arm64: dts: imx8mn: Enable Overdrive mode
In-Reply-To: <20231128211832.313544-1-aford173@gmail.com>
References: <20231128211832.313544-1-aford173@gmail.com>
Message-ID: <20231214022312.GZ270430@dragon>

On Tue, Nov 28, 2023 at 03:18:31PM -0600, Adam Ford wrote:
> The i.MX8M Nano supports and overdrive mode if the SoC is given
> the proper voltage.  Add imx8mn-overdrive.dtsi file which can
> be included by boards who support the voltage necessary to handle
> the faster clocks.  This increases the GPU clocks from 400MHz to
> 600MHz.
> 
> Signed-off-by: Adam Ford <aford173 at gmail.com>

Applied both, thanks!


From shawnguo at kernel.org  Wed Dec 13 18:24:50 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:24:50 +0800
Subject: [PATCH 1/1] arm64: dts: imx8m*-tqma8m*: Add chassis-type
In-Reply-To: <20231207145401.2102898-1-alexander.stein@ew.tq-group.com>
References: <20231207145401.2102898-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214022450.GA270430@dragon>

On Thu, Dec 07, 2023 at 03:54:01PM +0100, Alexander Stein wrote:
> Device tree specification 0.4 defines an optional, but recommended
> 'chassis-type' property. Add it to TQMa8M* based board files.
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 18:50:09 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:50:09 +0800
Subject: [PATCH v2 0/3] board: imx8mn-dimonoff-gateway-evk: add support
 for Dimonoff gateway EVK board
In-Reply-To: <20231207150519.1264808-1-hugo@hugovil.com>
References: <20231207150519.1264808-1-hugo@hugovil.com>
Message-ID: <20231214025009.GB270430@dragon>

On Thu, Dec 07, 2023 at 10:05:16AM -0500, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve at dimonoff.com>
> 
> Hello,
> this patch series add support for the Dimonoff gateway EVK board.
> 
> Based on shawnguo/for-next branch.
> 
> Thank you.
> 
> Link: [v1] https://lore.kernel.org/all/20231206160303.33185-1-hugo at hugovil.com/
> 
> Changes for V2:
> - Add Krzysztof Acked-by tag
> - Wrap lines at 80 columns in dts
> - Remove company name from compatible property
> 
> Hugo Villeneuve (3):
>   dt-bindings: vendor-prefixes: add dimonoff
>   dt-bindings: arm: fsl: add Dimonoff gateway EVK board
>   arm64: dts: freescale: introduce dimonoff-gateway-evk board

Applied all, thanks!


From shawnguo at kernel.org  Wed Dec 13 18:51:33 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:51:33 +0800
Subject: [PATCH 1/2] arm64: dts: imx8mm-evk: Move port under USB connector
In-Reply-To: <20231207155842.2645290-1-festevam@gmail.com>
References: <20231207155842.2645290-1-festevam@gmail.com>
Message-ID: <20231214025133.GC270430@dragon>

On Thu, Dec 07, 2023 at 12:58:41PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per nxp,ptn5110.yaml, 'port' should be placed under 'connector'.
> 
> Do as requested to fix the following dt-schema warning:
> 
> imx8mm-evkb.dtb: tcpc at 50: 'port' does not match any of the regexes: 'pinctrl-[0-9]+'
> 	from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied both, thanks!


From chentao at kylinos.cn  Wed Dec 13 18:57:38 2023
From: chentao at kylinos.cn (Kunwu Chan)
Date: Thu, 14 Dec 2023 10:57:38 +0800
Subject: [PATCH] drivers/perf: Fix some null pointer dereference issues in
 thunderx2_pmu.c
In-Reply-To: <20231212092523.GC28174@willie-the-truck>
References: <20231211090347.265240-1-chentao@kylinos.cn>
 <20231212092523.GC28174@willie-the-truck>
Message-ID: <9586be60-35f9-401f-b473-b16e86d13d07@kylinos.cn>

Thanks for your reply.

After read tx2_uncore_pmu_register again.
 From the defination: 'char *name = tx2_pmu->name;',
we could know 'tx2_pmu->pmu.name' equals 'tx2_pmu->name'

The difference is that a new memory space is allocated for 
'tx2_pmu->pmu.name'.

If 'tx2_pmu->pmu.name' is always the same as 'tx2_pmu->name', whether we 
should use 'tx2_pmu->pmu.name =  tx2_pmu->name;'
to replace the 'devm_kasprintf'.

I'm not sure it's appropriate to do that.

Thanks again.


On 2023/12/12 17:25, Will Deacon wrote:
> On Mon, Dec 11, 2023 at 05:03:47PM +0800, Kunwu Chan wrote:
>> devm_kasprintf() returns a pointer to dynamically allocated memory
>> which can be NULL upon failure.
>>
>> Fixes: 69c32972d593 ("drivers/perf: Add Cavium ThunderX2 SoC UNCORE PMU driver")
>> Cc: Kunwu Chan <kunwu.chan at hotmail.com>
>> Signed-off-by: Kunwu Chan <chentao at kylinos.cn>
>> ---
>>   drivers/perf/thunderx2_pmu.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
>> index 1edb9c03704f..07edb174a0d7 100644
>> --- a/drivers/perf/thunderx2_pmu.c
>> +++ b/drivers/perf/thunderx2_pmu.c
>> @@ -742,6 +742,8 @@ static int tx2_uncore_pmu_register(
>>   
>>   	tx2_pmu->pmu.name = devm_kasprintf(dev, GFP_KERNEL,
>>   			"%s", name);
>> +	if (!tx2_pmu->pmu.name)
>> +		return -ENOMEM;
>>   
>>   	return perf_pmu_register(&tx2_pmu->pmu, tx2_pmu->pmu.name, -1);
> 
> AFAICT, perf_pmu_register() will WARN and return NULL, so I'm not sure what
> we gain from the additional check.
> 
>>   }
>> @@ -881,6 +883,11 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
>>   		return NULL;
>>   	}
>>   
>> +	if (!tx2_pmu->name) {
>> +		dev_err(dev, "PMU type %d: Fail to allocate memory\n", type);
>> +		devm_kfree(dev, tx2_pmu);
>> +		return NULL;
>> +	}
> 
> In the _highly_ unlikely even that devm_kasprintf() failed to allocate,
> shouldn't we get a splat from the allocator? I don't think it's useful
> to print another message.
> 
> Will


From shawnguo at kernel.org  Wed Dec 13 18:59:20 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 10:59:20 +0800
Subject: [PATCH] arm64: dts: imx8dxl-ss-conn: Move clk_dummy out of USB
 node
In-Reply-To: <20231211172435.503962-1-festevam@gmail.com>
References: <20231211172435.503962-1-festevam@gmail.com>
Message-ID: <20231214025920.GD270430@dragon>

On Mon, Dec 11, 2023 at 02:24:35PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> The clk_dummy is not part of the usbotg2 block, so move it
> to the root node to fix the following dt-schema warning:
> 
> imx8dxl-evk.dtb: usb at 5b0e0000: Unevaluated properties are not allowed ('clock-dummy' was unexpected)
> 	from schema $id: http://devicetree.org/schemas/usb/ci-hdrc-usb2.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 19:01:38 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 11:01:38 +0800
Subject: [PATCH] arm64: dts: imx8qxp-mek: Move port under USB connector
In-Reply-To: <20231211214054.570295-1-festevam@gmail.com>
References: <20231211214054.570295-1-festevam@gmail.com>
Message-ID: <20231214030138.GE270430@dragon>

On Mon, Dec 11, 2023 at 06:40:54PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per nxp,ptn5110.yaml, 'port' should be placed under 'connector'.
> 
> Do as requested to fix the following dt-schema warning:
> 
> imx8qxp-mek.dtb: tcpc at 50: connector:ports: 'port at 0' is a required property
> 	from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
> imx8qxp-mek.dtb: tcpc at 50: connector: Unevaluated properties are not allowed ('ports' was unexpected)
> 	from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>
> ---
>  arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> index 6c3d8715bc11..096f9501fa32 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> @@ -152,12 +152,6 @@ ptn5110: tcpc at 50 {
>  		interrupt-parent = <&lsio_gpio1>;
>  		interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
>  
> -		port {
> -			typec_dr_sw: endpoint {
> -				remote-endpoint = <&usb3_drd_sw>;
> -			};
> -		};
> -
>  		usb_con1: connector {
>  			compatible = "usb-c-connector";
>  			label = "USB-C";
> @@ -169,6 +163,13 @@ ports {
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  
> +				port at 0 {
> +					reg = <0>;

Have a newline between properties and child node.

Shawn

> +					typec_dr_sw: endpoint {
> +						remote-endpoint = <&usb3_drd_sw>;
> +					};
> +				};
> +
>  				port at 1 {
>  					reg = <1>;
>  					typec_con_ss: endpoint {
> -- 
> 2.34.1
> 


From shawnguo at kernel.org  Wed Dec 13 19:06:04 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 11:06:04 +0800
Subject: [PATCH v2 1/3] arm64: dts: imx8mp-verdin: Fix USB connector
 description
In-Reply-To: <20231213211847.1096033-1-festevam@gmail.com>
References: <20231213211847.1096033-1-festevam@gmail.com>
Message-ID: <20231214030604.GF270430@dragon>

On Wed, Dec 13, 2023 at 06:18:45PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> The USB connector should not be placed under the dwc3 node.
> 
> Move the USB connector out of the SoC level and use port to describe
> the connection to the dwc3 controller.
> 
> This fixes the following dt-schema warning:
> 
> imx8mp-verdin-wifi-mallow.dtb: usb at 32f10100: usb at 38100000: Unevaluated properties are not allowed ('connector' was unexpected)
> 	from schema $id: http://devicetree.org/schemas/usb/fsl,imx8mp-dwc3.yaml#
> 	
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied all, thanks!


From shawnguo at kernel.org  Wed Dec 13 19:07:12 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 11:07:12 +0800
Subject: [PATCH v2 2/3] arm64: dts: imx8mn-var-som-symphony: Describe the
 USB-C connector
In-Reply-To: <20231212174847.759164-2-festevam@gmail.com>
References: <20231212174847.759164-1-festevam@gmail.com>
 <20231212174847.759164-2-festevam@gmail.com>
Message-ID: <20231214030712.GG270430@dragon>

On Tue, Dec 12, 2023 at 02:48:46PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Describe the PTN5150 USB-C connector to improve the devicetree description
> and fix the following dt-schema warning:
> 
> imx8mn-var-som-symphony.dtb: typec at 3d: 'port' does not match any of the regexes: 'pinctrl-[0-9]+'
> 	from schema $id: http://devicetree.org/schemas/extcon/extcon-ptn5150.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Wed Dec 13 19:07:32 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 14 Dec 2023 11:07:32 +0800
Subject: [PATCH v2 3/3] arm64: dts: imx8mp-dhcom-pdk3: Describe the USB-C
 connector
In-Reply-To: <20231212174847.759164-3-festevam@gmail.com>
References: <20231212174847.759164-1-festevam@gmail.com>
 <20231212174847.759164-3-festevam@gmail.com>
Message-ID: <20231214030732.GH270430@dragon>

On Tue, Dec 12, 2023 at 02:48:47PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Describe the PTN5150 USB-C connector to improve the devicetree description
> and fix the following dt-schema warning:
> 
> imx8mp-dhcom-pdk3.dtb: typec at 3d: 'port' does not match any of the regexes: 'pinctrl-[0-9]+'
> 	from schema $id: http://devicetree.org/schemas/extcon/extcon-ptn5150.yaml#
> 	
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From tpearson at raptorengineering.com  Wed Dec 13 19:13:01 2023
From: tpearson at raptorengineering.com (Timothy Pearson)
Date: Wed, 13 Dec 2023 21:13:01 -0600 (CST)
Subject: [RFC PATCH 10/12] drm/amd/display: Use
 ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <7ed20fcf-8a9d-40d5-b913-b5d2da443cd6@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com> <20231208055501.2916202-11-samuel.holland@sifive.com> <87h6kpdj20.fsf@mail.lhotse> <7ed20fcf-8a9d-40d5-b913-b5d2da443cd6@sifive.com>
Message-ID: <1124363169.403562.1702523581672.JavaMail.zimbra@raptorengineeringinc.com>



----- Original Message -----
> From: "Samuel Holland" <samuel.holland at sifive.com>
> To: "Michael Ellerman" <mpe at ellerman.id.au>
> Cc: "linux-kernel" <linux-kernel at vger.kernel.org>, "amd-gfx" <amd-gfx at lists.freedesktop.org>, "linux-arch"
> <linux-arch at vger.kernel.org>, "linux-arm-kernel" <linux-arm-kernel at lists.infradead.org>, loongarch at lists.linux.dev,
> "linuxppc-dev" <linuxppc-dev at lists.ozlabs.org>, "x86" <x86 at kernel.org>, linux-riscv at lists.infradead.org, "Christoph
> Hellwig" <hch at infradead.org>, "Timothy Pearson" <tpearson at raptorengineering.com>
> Sent: Wednesday, December 13, 2023 7:03:20 PM
> Subject: Re: [RFC PATCH 10/12] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT

> On 2023-12-11 6:23 AM, Michael Ellerman wrote:
>> Hi Samuel,
>> 
>> Thanks for trying to clean all this up.
>> 
>> One problem below.
>> 
>> Samuel Holland <samuel.holland at sifive.com> writes:
>>> Now that all previously-supported architectures select
>>> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
>>> of the existing list of architectures. It can also take advantage of the
>>> common kernel-mode FPU API and method of adjusting CFLAGS.
>>>
>>> Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
>> ...
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>>> index 4ae4720535a5..b64f917174ca 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>>> @@ -87,20 +78,9 @@ void dc_fpu_begin(const char *function_name, const int line)
>>>  	WARN_ON_ONCE(!in_task());
>>>  	preempt_disable();
>>>  	depth = __this_cpu_inc_return(fpu_recursion_depth);
>>> -
>>>  	if (depth == 1) {
>>> -#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
>>> +		BUG_ON(!kernel_fpu_available());
>>>  		kernel_fpu_begin();
>>> -#elif defined(CONFIG_PPC64)
>>> -		if (cpu_has_feature(CPU_FTR_VSX_COMP))
>>> -			enable_kernel_vsx();
>>> -		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
>>> -			enable_kernel_altivec();
>>  
>> Note altivec.
>> 
>>> -		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
>>> -			enable_kernel_fp();
>>> -#elif defined(CONFIG_ARM64)
>>> -		kernel_neon_begin();
>>> -#endif
>>>  	}
>>>  
>>>  	TRACE_DCN_FPU(true, function_name, line, depth);
>>> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>> b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>> index ea7d60f9a9b4..5aad0f572ba3 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>> @@ -25,40 +25,8 @@
>>>  # It provides the general basic services required by other DAL
>>>  # subcomponents.
>>>  
>>> -ifdef CONFIG_X86
>>> -dml_ccflags-$(CONFIG_CC_IS_GCC) := -mhard-float
>>> -dml_ccflags := $(dml_ccflags-y) -msse
>>> -endif
>>> -
>>> -ifdef CONFIG_PPC64
>>> -dml_ccflags := -mhard-float -maltivec
>>> -endif
>> 
>> And altivec is enabled in the flags there.
>> 
>> That doesn't match your implementation for powerpc in patch 7, which
>> only deals with float.
>> 
>> I suspect the AMD driver actually doesn't need altivec enabled, but I
>> don't know that for sure. It compiles without it, but I don't have a GPU
>> to actually test. I've added Timothy on Cc who added the support for
>> powerpc to the driver originally, hopefully he has a test system.

If you would like me to test I'm happy to do so, but I am travelling until Friday so would need to wait until then.

Thanks!


From alim.akhtar at samsung.com  Wed Dec 13 19:39:19 2023
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Thu, 14 Dec 2023 09:09:19 +0530
Subject: [PATCH] dt-bindings: display: samsung,exynos-mixer: Fix 'regs'
 typo
In-Reply-To: <20231213224201.2191358-1-robh@kernel.org>
References: <CGME20231213224223epcas5p31386d8403f97b986d39cd738af0ba781@epcas5p3.samsung.com>
	<20231213224201.2191358-1-robh@kernel.org>
Message-ID: <007301da2e3f$20c35320$6249f960$@samsung.com>



> -----Original Message-----
> From: Rob Herring <robh at kernel.org>
> Sent: Thursday, December 14, 2023 4:12 AM
> To: Inki Dae <inki.dae at samsung.com>; Seung-Woo Kim
> <sw0312.kim at samsung.com>; Kyungmin Park
> <kyungmin.park at samsung.com>; Maarten Lankhorst
> <maarten.lankhorst at linux.intel.com>; Maxime Ripard
> <mripard at kernel.org>; Thomas Zimmermann <tzimmermann at suse.de>;
> David Airlie <airlied at gmail.com>; Daniel Vetter <daniel at ffwll.ch>;
Krzysztof
> Kozlowski <krzysztof.kozlowski+dt at linaro.org>; Conor Dooley
> <conor+dt at kernel.org>; Alim Akhtar <alim.akhtar at samsung.com>
> Cc: Krzysztof Kozlowski <krzk at kernel.org>;
dri-devel at lists.freedesktop.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-kernel at vger.kernel.org
> Subject: [PATCH] dt-bindings: display: samsung,exynos-mixer: Fix 'regs'
typo
> 
> The correct property name is 'reg' not 'regs'.
> 
> Fixes: 68e89bb36d58 ("dt-bindings: display: samsung,exynos-mixer: convert
> to dtschema")
> Signed-off-by: Rob Herring <robh at kernel.org>
> ---
Thanks,

Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>

>  .../bindings/display/samsung/samsung,exynos-mixer.yaml      | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
[snip]
> 2.43.0




From martin.petersen at oracle.com  Wed Dec 13 19:44:36 2023
From: martin.petersen at oracle.com (Martin K. Petersen)
Date: Wed, 13 Dec 2023 22:44:36 -0500
Subject: [PATCH v8 00/10] Enable HS-G5 support on SM8550
In-Reply-To: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com> (Can
	Guo's message of "Sat, 2 Dec 2023 04:36:06 -0800")
References: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
Message-ID: <yq1fs05h2j0.fsf@ca-mkp.ca.oracle.com>


Can,

> This series enables HS-G5 support on SM8550.

Applied patches 1-8 to 6.8/scsi-staging, thanks!

The phy patches didn't apply. I assume they'll go through the phy tree.

-- 
Martin K. Petersen	Oracle Linux Engineering


From wenst at chromium.org  Wed Dec 13 20:02:59 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 14 Dec 2023 13:02:59 +0900
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAMuHMdVMZs6mnwWBgFwktO=8o=QzROv60cfZe085MhD6HxQjpQ@mail.gmail.com>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com> <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
 <20231209152946.GC13421@pendragon.ideasonboard.com> <CAMuHMdVMZs6mnwWBgFwktO=8o=QzROv60cfZe085MhD6HxQjpQ@mail.gmail.com>
Message-ID: <CAGXv+5Est3FL-XcEL-vB-6zVNas0mqb2cNYa==Yb7W2SQU9xVQ@mail.gmail.com>

On Sun, Dec 10, 2023 at 1:31?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>
> Hi Laurent,
>
> On Sat, Dec 9, 2023 at 4:29?PM Laurent Pinchart
> <laurent.pinchart at ideasonboard.com> wrote:
> > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > On Thu, Dec 7, 2023 at 11:38?PM Laurent Pinchart
> > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > performance.
> > > > > > >
> > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > >
> > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > filenames or other workarounds.
> > > > > > >
> > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > >
> > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > >
> > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > $(obj)/image.fit
> > > > > > >
> > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > this here, since it must be built separately from the Linux build.
> > > > > >
> > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > versatile nature of FIT images, there can't be any
> > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > balance between what makes sense for the kernel and the features that
> > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > to delay merging this series.
> > > > > >
> > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > to a second question: would you consider merging extensions to this
> > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > users who manually invoke the script ? More generally, is the script
> > > > >
> > > > > We'd also be interested in some customization, though in a different way.
> > > > > We imagine having a rule file that says X compatible string should map
> > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > carry all the possible second source components, like different display
> > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > >
> > > > Do you envision the "mapping" compatible string mapping to a config
> > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > >
> > > That's exactly the idea. The mapping compatible string could be untied
> > > from the base board's compatible string if needed (which we probably do).
> > >
> > > So something like:
> > >
> > > config {
> > >     config-1 {
> > >         compatible = "google,krane-sku0";
> > >         fdt = "krane-baseboard", "krane-sku0-overlay";
> > >     };
> > > };
> > >
> > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > between the SKUs, in this case the display panel and MIPI camera (not
> > > upstreamed) that applies to SKU0 in particular.
> >
> > The kernel DT makefiles already contain information on what overlays to
> > apply to what base boards, in order to test the overlays and produce
> > "full" DTBs. Maybe that information could be leveraged to create the
> > configurations in the FIT image ?
>
> Although the "full" DTBs created may only be a subset of all possible
> combinations (I believe Rob just started with creating one "full" DTB
> for each overlay, cfr. the additions I made in commit a09c3e105a208580
> ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> definitely be a start.
>
> Now, since the kernel build system already creates "full" DTBs, does
> that mean that all of the base DTBs, overlays, and "full" DTBs will
> end up in the FIT image?

I suppose we could add an option to the packing tool to be able to _not_
add the "full" DTBs if they can also be assembled with a base DTB and
overlays. Think of it as a firmware compatibility option: if the firmware
supports overlays, then you almost always want the deconstructed parts,
not the fully assembled ones. Vice versa.

If we don't we could end up with two configurations that have the same
compatible string?


ChenYu


> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds


From sherry.sun at nxp.com  Wed Dec 13 20:08:13 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Thu, 14 Dec 2023 04:08:13 +0000
Subject: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx
 platforms.
In-Reply-To: <20231213195743.GA1055303@bhelgaas>
References: <20231213092850.1706042-2-sherry.sun@nxp.com>
 <20231213195743.GA1055303@bhelgaas>
Message-ID: <AS8PR04MB84044B72EAF25185AB66EB94928CA@AS8PR04MB8404.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Bjorn Helgaas <helgaas at kernel.org>
> Sent: 2023?12?14? 3:58
> To: Sherry Sun <sherry.sun at nxp.com>
> Cc: Hongxing Zhu <hongxing.zhu at nxp.com>; l.stach at pengutronix.de;
> lpieralisi at kernel.org; kw at linux.com; robh at kernel.org;
> bhelgaas at google.com; krzysztof.kozlowski+dt at linaro.org;
> conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de;
> kernel at pengutronix.de; festevam at gmail.com; dl-linux-imx <linux-
> imx at nxp.com>; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx
> platforms.
> 
> Drop period at the end of subject line.  It only adds the possibility of
> unnecessary line wrapping in git log.

Hi Bjorn, thanks for the comments, will do in V3.

> 
> On Wed, Dec 13, 2023 at 05:28:47PM +0800, Sherry Sun wrote:
> > Add pci host wakeup feature for imx platforms.
> 
> s/pci/PCI/
> s/imx/i.MX/ (based on how nxp.com web pages refer to it)
> 

Will do.

> > Example of configuring the corresponding dts property under the PCI
> > node:
> > wake-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;
> 
> Add newline between paragraphs or wrap into a single paragraph.

Will do.

> 
> > +		/* host wakeup support */
> > +		imx6_pcie->host_wake_irq = -1;
> 
> AFAIK, 0 is an invalid IRQ value.  So why not drop this assignment since
> imx6_pcie->host_wake_irq is 0 by default since it was allocated with
> devm_kzalloc(), and test like this elsewhere:
> 
>   if (imx6_pcie->host_wake_irq) {
>     enable_irq_wake(imx6_pcie->host_wake_irq)

I plan to change the host_wake_irq to unsigned int type, and add following codes, then "if (imx6_pcie->host_wake_irq)" condition seems more reasonable, let me know if you have any further suggestions. thanks!
-                       imx6_pcie->host_wake_irq = gpiod_to_irq(host_wake_gpio);
+                       ret = gpiod_to_irq(host_wake_gpio);
+                       if (ret < 0)
+                               return dev_err_probe(dev, ret, "Failed to get IRQ for WAKE gpio\n");
+
+                       imx6_pcie->host_wake_irq = (unsigned int)ret;

> 
> > +		host_wake_gpio = devm_gpiod_get_optional(dev, "wake",
> GPIOD_IN);
> > +		if (IS_ERR(host_wake_gpio))
> > +			return PTR_ERR(host_wake_gpio);
> > +
> > +		if (host_wake_gpio != NULL) {
> 
>   if (host_wake_gpio)

Will do.

Best Regards
Sherry



From mpe at ellerman.id.au  Wed Dec 13 20:45:21 2023
From: mpe at ellerman.id.au (Michael Ellerman)
Date: Thu, 14 Dec 2023 15:45:21 +1100
Subject: [RFC PATCH 10/12] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <7ed20fcf-8a9d-40d5-b913-b5d2da443cd6@sifive.com>
References: <20231208055501.2916202-1-samuel.holland@sifive.com>
 <20231208055501.2916202-11-samuel.holland@sifive.com>
 <87h6kpdj20.fsf@mail.lhotse>
 <7ed20fcf-8a9d-40d5-b913-b5d2da443cd6@sifive.com>
Message-ID: <87bkatxuhq.fsf@mail.lhotse>

Samuel Holland <samuel.holland at sifive.com> writes:
> On 2023-12-11 6:23 AM, Michael Ellerman wrote:
>> Hi Samuel,
>> 
>> Thanks for trying to clean all this up.
>> 
>> One problem below.
>> 
>> Samuel Holland <samuel.holland at sifive.com> writes:
>>> Now that all previously-supported architectures select
>>> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
>>> of the existing list of architectures. It can also take advantage of the
>>> common kernel-mode FPU API and method of adjusting CFLAGS.
>>>
>>> Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
>> ...
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>>> index 4ae4720535a5..b64f917174ca 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
>>> @@ -87,20 +78,9 @@ void dc_fpu_begin(const char *function_name, const int line)
>>>  	WARN_ON_ONCE(!in_task());
>>>  	preempt_disable();
>>>  	depth = __this_cpu_inc_return(fpu_recursion_depth);
>>> -
>>>  	if (depth == 1) {
>>> -#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
>>> +		BUG_ON(!kernel_fpu_available());
>>>  		kernel_fpu_begin();
>>> -#elif defined(CONFIG_PPC64)
>>> -		if (cpu_has_feature(CPU_FTR_VSX_COMP))
>>> -			enable_kernel_vsx();
>>> -		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
>>> -			enable_kernel_altivec();
>>  
>> Note altivec.
>> 
>>> -		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
>>> -			enable_kernel_fp();
>>> -#elif defined(CONFIG_ARM64)
>>> -		kernel_neon_begin();
>>> -#endif
>>>  	}
>>>  
>>>  	TRACE_DCN_FPU(true, function_name, line, depth);
>>> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>> index ea7d60f9a9b4..5aad0f572ba3 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>> @@ -25,40 +25,8 @@
>>>  # It provides the general basic services required by other DAL
>>>  # subcomponents.
>>>  
>>> -ifdef CONFIG_X86
>>> -dml_ccflags-$(CONFIG_CC_IS_GCC) := -mhard-float
>>> -dml_ccflags := $(dml_ccflags-y) -msse
>>> -endif
>>> -
>>> -ifdef CONFIG_PPC64
>>> -dml_ccflags := -mhard-float -maltivec
>>> -endif
>> 
>> And altivec is enabled in the flags there.
>> 
>> That doesn't match your implementation for powerpc in patch 7, which
>> only deals with float.
>> 
>> I suspect the AMD driver actually doesn't need altivec enabled, but I
>> don't know that for sure. It compiles without it, but I don't have a GPU
>> to actually test. I've added Timothy on Cc who added the support for
>> powerpc to the driver originally, hopefully he has a test system.
>
> I tested this series on a POWER9 system with an AMD Radeon RX 6400 GPU (which
> requires this FPU code to initialize), and got functioning graphics output.

Awesome.

>> Anyway if that's true that it doesn't need altivec we should probably do
>> a lead-up patch that drops altivec from the AMD driver explicitly, eg.
>> as below.
>
> That makes sense to me. Do you want to provide your Signed-off-by so I can send
> this patch with your authorship?

Yeah that'd be great. Patch below. Feel free to adjust the commit
message as you see fit.

cheers


>From c8a2862d2ebe76a023eceb3267fd85262925c0ba Mon Sep 17 00:00:00 2001
From: Michael Ellerman <mpe at ellerman.id.au>
Date: Thu, 14 Dec 2023 15:39:05 +1100
Subject: [PATCH] drm/amd/display: Only use hard-float, not altivec on powerpc

The compiler flags enable altivec, but that is not required, hard-float
is sufficient for the code to build and function.

Drop altivec from the compiler flags and adjust the enable/disable code
to only enable FPU use.

Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c | 12 ++----------
 drivers/gpu/drm/amd/display/dc/dml/Makefile    |  2 +-
 drivers/gpu/drm/amd/display/dc/dml2/Makefile   |  2 +-
 3 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
index 4ae4720535a5..0de16796466b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
@@ -92,11 +92,7 @@ void dc_fpu_begin(const char *function_name, const int line)
 #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 		kernel_fpu_begin();
 #elif defined(CONFIG_PPC64)
-		if (cpu_has_feature(CPU_FTR_VSX_COMP))
-			enable_kernel_vsx();
-		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
-			enable_kernel_altivec();
-		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
+		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
 			enable_kernel_fp();
 #elif defined(CONFIG_ARM64)
 		kernel_neon_begin();
@@ -125,11 +121,7 @@ void dc_fpu_end(const char *function_name, const int line)
 #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 		kernel_fpu_end();
 #elif defined(CONFIG_PPC64)
-		if (cpu_has_feature(CPU_FTR_VSX_COMP))
-			disable_kernel_vsx();
-		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
-			disable_kernel_altivec();
-		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
+		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
 			disable_kernel_fp();
 #elif defined(CONFIG_ARM64)
 		kernel_neon_end();
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 6042a5a6a44f..554c39024a40 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -31,7 +31,7 @@ dml_ccflags := $(dml_ccflags-y) -msse
 endif
 
 ifdef CONFIG_PPC64
-dml_ccflags := -mhard-float -maltivec
+dml_ccflags := -mhard-float
 endif
 
 ifdef CONFIG_ARM64
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index acff3449b8d7..7b51364084b5 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -30,7 +30,7 @@ dml2_ccflags := $(dml2_ccflags-y) -msse
 endif
 
 ifdef CONFIG_PPC64
-dml2_ccflags := -mhard-float -maltivec
+dml2_ccflags := -mhard-float
 endif
 
 ifdef CONFIG_ARM64
-- 
2.43.0




From manivannan.sadhasivam at linaro.org  Wed Dec 13 21:13:28 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Thu, 14 Dec 2023 10:43:28 +0530
Subject: [PATCH V2 0/4] PCI: imx6: Add pci host wakeup support
In-Reply-To: <20231213092850.1706042-1-sherry.sun@nxp.com>
References: <20231213092850.1706042-1-sherry.sun@nxp.com>
Message-ID: <20231214051328.GD2938@thinkpad>

On Wed, Dec 13, 2023 at 05:28:46PM +0800, Sherry Sun wrote:
> Add pci host wakeup feature for imx platforms. The host wake pin is a
> standard feature in the PCIe bus specification, so we can add this
> property under PCI dts node to support the host gpio wakeup feature.
> 
> Example of configuring the corresponding dts property under the PCI node:
>     wake-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;
> 

As you mentioned, WAKE# is a standard sideband signal defined in the PCI spec.
So the support for handling it has to be in the PCI core layer, not in the
host controller drivers.

There is already a series floating to add support for WAKE# in PCI core. Please
take a look:

https://lore.kernel.org/linux-pci/20230208111645.3863534-1-mmaddireddy at nvidia.com/

- Mani

> ---
> changes in V2:
> 1. Rename host-wake-gpio property to wake-gpios.
> 2. Improve the wake-gpios property description in the dt-binding doc to avoid
> confusion.
> 3. Remove unnecessary debugging info in host_wake_irq_handler().
> 4. Remove unnecessary imx6_pcie->host_wake_irq = -1 resetting in error paths.
> 5. Use dev_err_probe() to simplify error path code.
> ---
> 
> Sherry Sun (4):
>   PCI: imx6: Add pci host wakeup support on imx platforms.
>   dt-bindings: imx6q-pcie: Add wake-gpios property
>   arm64: dts: imx8mp-evk: add wake-gpios property for pci bus
>   arm64: dts: imx8mq-evk: add wake-gpios property for pci bus
> 
>  .../bindings/pci/fsl,imx6q-pcie.yaml          |  6 ++
>  arch/arm64/boot/dts/freescale/imx8mp-evk.dts  |  2 +
>  arch/arm64/boot/dts/freescale/imx8mq-evk.dts  |  2 +
>  drivers/pci/controller/dwc/pci-imx6.c         | 60 +++++++++++++++++++
>  4 files changed, 70 insertions(+)
> 
> -- 
> 2.34.1
> 
> 

-- 
????????? ????????


From cl at linux.com  Wed Dec 13 21:25:10 2023
From: cl at linux.com (Christoph Lameter (Ampere))
Date: Wed, 13 Dec 2023 21:25:10 -0800 (PST)
Subject: [PATCH] ARM64: Implement arch_report_meminfo()
In-Reply-To: <CAHbLzkpPTVHGUKfA1xeNwp100UAJxe0pmvMQdXpn_qmX3eLdag@mail.gmail.com>
References: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org> <CAHbLzkpPTVHGUKfA1xeNwp100UAJxe0pmvMQdXpn_qmX3eLdag@mail.gmail.com>
Message-ID: <62201f98-eebc-ce13-4384-99eeb19c09cc@linux.com>

On Tue, 12 Dec 2023, Yang Shi wrote:

>> +static atomic_t nr_pte;
>> +static atomic_t nr_pmd;
>> +static atomic_t nr_pud;
>> +static atomic_t nr_pte_cont;
>> +static atomic_t nr_pmd_cont;
>
> These statistics are useful for debugging. However, why not use the
> direct_pages_count[] array to save the counters like other
> architectures, for example, x86, ppc and s390?

That is because ARM64 also has the CONT features. The code significantly
differs from x86.

Using the above naming scheme ties the values directly to what is supported by
the hardware and results in easier to read source code.

Calling this "direct" something is then a presentation issue.
That is actually something I was not sure about. CONT Direct is a bit 
strange. I'd prefer to see PTE/PMD/PUD there whic makes it clear to me.
But I guess others expect to see "Direct Pages" there since they are
used to it from x86.



From viresh.kumar at linaro.org  Wed Dec 13 21:36:53 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 14 Dec 2023 11:06:53 +0530
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the
 scheduler
In-Reply-To: <2e8807b68133f4b3a72227122a9d9a05f3fbf9d8.camel@linux.intel.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org>
 <2e8807b68133f4b3a72227122a9d9a05f3fbf9d8.camel@linux.intel.com>
Message-ID: <20231214053653.hnyeormwu42un5sc@vireshk-i7>

On 13-12-23, 16:41, Tim Chen wrote:
> Seems like the pressure value computed from the first CPU applies to all CPU.
> Will this be valid for non-homogeneous CPUs that could have different
> max_freq and max_capacity?

The will be part of different cpufreq policies and so it will work
fine.

-- 
viresh


From tanmay.shah at amd.com  Wed Dec 13 21:42:23 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Wed, 13 Dec 2023 21:42:23 -0800
Subject: [PATCH v3 0/2] Add Versal IPI bindings 
Message-ID: <20231214054224.957336-1-tanmay.shah@amd.com>

Add documentation for AMD-Xilinx Versal platform Inter Processor Interrupt
controller. Versal IPI controller contains buffer-less IPI which do not
have buffers for message passing. For such IPI channels message buffers
are not expected and only notification to/from remote agent is expected.

Before adding Versal IPI bindings add fix current bindings by adding
xlnx,ipi-id in required property list.

Changes in v3:
  - disallow parent node "reg" and "reg-names" properties for old device
  - remove cleanup changes for old device and only keep Versal related
    changes
  - replace zynqmp-mailbox node name with mailbox
  - Add blank line before required properties
  - Remove extra blank line

Changes in v2:
  - Add versal bindings to existing bindings doc instead of separate
    file.
  - Sort required list same as properties list
  - Add minimum and maximum range for xlnx,ipi-id vendor property
  - Move vendor property last in the list
  - Fix description of child node reg property for versal bindings
  - Change commit text

depends on: https://lore.kernel.org/linux-arm-kernel/79f65b96-9015-41c4-b4ee-a82526c9eefc at linaro.org/T/#meeacc5c57a9610b19758d313e5b2d17ab470f646

Tanmay Shah (2):
  dt-bindings: mailbox: zynqmp: extend required list
  dt-bindings: mailbox: add Versal IPI bindings

 .../mailbox/xlnx,zynqmp-ipi-mailbox.yaml      | 132 ++++++++++++++++--
 1 file changed, 119 insertions(+), 13 deletions(-)


base-commit: 48e8992e33abf054bcc0bb2e77b2d43bb899212e
prerequisite-patch-id: 70017c8eaded5fc85749995b9cf093c6c625fab3
-- 
2.25.1



From viresh.kumar at linaro.org  Wed Dec 13 21:43:07 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 14 Dec 2023 11:13:07 +0530
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the
 scheduler
In-Reply-To: <20231212142730.998913-2-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org>
Message-ID: <20231214054307.axl33gagxacidjbn@vireshk-i7>

On 12-12-23, 15:27, Vincent Guittot wrote:
> @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
>  	policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
>  	trace_cpu_frequency_limits(policy);
>  
> +	cpus = policy->related_cpus;
> +	cpufreq_update_pressure(cpus, policy->max);
> +
>  	policy->cached_target_freq = UINT_MAX;

One more question, why are you doing this from cpufreq_set_policy ? If
due to cpufreq cooling or from userspace, we end up limiting the
maximum possible frequency, will this routine always get called ?

-- 
viresh


From tanmay.shah at amd.com  Wed Dec 13 21:42:25 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Wed, 13 Dec 2023 21:42:25 -0800
Subject: [PATCH v3 1/2] dt-bindings: mailbox: zynqmp: extend required list
In-Reply-To: <20231214054224.957336-1-tanmay.shah@amd.com>
References: <20231214054224.957336-1-tanmay.shah@amd.com>
Message-ID: <20231214054224.957336-2-tanmay.shah@amd.com>

"xlnx,ipi-id" is handled as required property but is
missing from binding doc required list of mailbox child node.
Add that to required list. This does not break backward
compatibility but bug in bindings document.

Fixes: 4a855a957936 ("dt-bindings: mailbox: zynqmp_ipi: convert to yaml")

Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
---
 .../devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml     | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
index 8b15a0532120..73c180871605 100644
--- a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
@@ -103,6 +103,7 @@ patternProperties:
       - reg
       - reg-names
       - "#mbox-cells"
+      - xlnx,ipi-id
 
 additionalProperties: false
 
-- 
2.25.1



From tanmay.shah at amd.com  Wed Dec 13 21:42:27 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Wed, 13 Dec 2023 21:42:27 -0800
Subject: [PATCH v3 2/2] dt-bindings: mailbox: add Versal IPI bindings
In-Reply-To: <20231214054224.957336-1-tanmay.shah@amd.com>
References: <20231214054224.957336-1-tanmay.shah@amd.com>
Message-ID: <20231214054224.957336-3-tanmay.shah@amd.com>

Add documentation for AMD-Xilinx Versal platform Inter Processor Interrupt
controller. Versal IPI controller contains buffer-less IPI which do not
have buffers for message passing. For such IPI channels message buffers
are not expected and only notification to/from remote agent is expected.

Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
---

Changes in v3:
  - disallow parent node "reg" and "reg-names" properties for old device
  - remove cleanup changes for old device and only keep Versal related
    changes
  - replace zynqmp-mailbox node name with mailbox

Changes in v2:
  - Add versal bindings to existing bindings doc instead of separate
    file.
  - Sort required list same as properties list
  - Add minimum and maximum range for xlnx,ipi-id vendor property
  - Move vendor property last in the list
  - Fix description of child node reg property for versal bindings
  - Change commit text

 .../mailbox/xlnx,zynqmp-ipi-mailbox.yaml      | 131 ++++++++++++++++--
 1 file changed, 118 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
index 73c180871605..fe83b5cb1278 100644
--- a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
@@ -37,7 +37,9 @@ maintainers:
 
 properties:
   compatible:
-    const: xlnx,zynqmp-ipi-mailbox
+    enum:
+      - xlnx,zynqmp-ipi-mailbox
+      - xlnx,versal-ipi-mailbox
 
   method:
     description: |
@@ -58,6 +60,12 @@ properties:
   '#size-cells':
     const: 2
 
+  reg:
+    maxItems: 2
+
+  reg-names:
+    maxItems: 2
+
   xlnx,ipi-id:
     description: |
       Remote Xilinx IPI agent ID of which the mailbox is connected to.
@@ -76,7 +84,17 @@ patternProperties:
     properties:
 
       compatible:
-        const: xlnx,zynqmp-ipi-dest-mailbox
+        enum:
+          - xlnx,zynqmp-ipi-dest-mailbox
+          - xlnx,versal-ipi-dest-mailbox
+
+      reg:
+        minItems: 1
+        maxItems: 4
+
+      reg-names:
+        minItems: 1
+        maxItems: 4
 
       xlnx,ipi-id:
         description:
@@ -88,15 +106,37 @@ patternProperties:
         description:
           It contains tx(0) or rx(1) channel IPI id number.
 
-      reg:
-        maxItems: 4
-
-      reg-names:
-        items:
-          - const: local_request_region
-          - const: local_response_region
-          - const: remote_request_region
-          - const: remote_response_region
+    allOf:
+      - if:
+          properties:
+            compatible:
+              contains:
+                enum:
+                  - xlnx,zynqmp-ipi-dest-mailbox
+        then:
+          properties:
+            reg:
+              maxItems: 4
+
+            reg-names:
+              items:
+                - const: local_request_region
+                - const: local_response_region
+                - const: remote_request_region
+                - const: remote_response_region
+        else:
+          properties:
+            reg:
+              minItems: 1
+              items:
+                - description: Remote IPI agent control register region
+                - description: Remote IPI agent optional message buffers
+
+            reg-names:
+              minItems: 1
+              items:
+                - const: ctrl
+                - const: msg
 
     required:
       - compatible
@@ -105,8 +145,6 @@ patternProperties:
       - "#mbox-cells"
       - xlnx,ipi-id
 
-additionalProperties: false
-
 required:
   - compatible
   - interrupts
@@ -114,6 +152,36 @@ required:
   - '#size-cells'
   - xlnx,ipi-id
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - xlnx,zynqmp-ipi-mailbox
+    then:
+      properties:
+        reg: false
+        reg-names: false
+
+    else:
+      properties:
+        reg:
+          items:
+            - description: Host IPI agent control register region
+            - description: Host IPI agent optional message buffers
+
+        reg-names:
+          items:
+            - const: ctrl
+            - const: msg
+
+      required:
+        - reg
+        - reg-names
+
+additionalProperties: false
+
 examples:
   - |
     #include<dt-bindings/interrupt-controller/arm-gic.h>
@@ -145,4 +213,41 @@ examples:
       };
     };
 
+  - |
+    #include<dt-bindings/interrupt-controller/arm-gic.h>
+
+    bus {
+      #address-cells = <2>;
+      #size-cells = <2>;
+      mailbox at ff300000 {
+        compatible = "xlnx,versal-ipi-mailbox";
+        interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+        #address-cells = <2>;
+        #size-cells = <2>;
+        reg = <0x0 0xff300000 0x0 0x1000>,
+              <0x0 0xff990000 0x0 0x1ff>;
+        reg-names = "ctrl", "msg";
+        xlnx,ipi-id = <0>;
+        ranges;
+
+        /* buffered IPI */
+        mailbox at ff340000 {
+          compatible = "xlnx,versal-ipi-dest-mailbox";
+          reg = <0x0 0xff340000 0x0 0x1000>,
+                <0x0 0xff990400 0x0 0x1ff>;
+          reg-names = "ctrl", "msg";
+          #mbox-cells = <1>;
+          xlnx,ipi-id = <4>;
+        };
+
+        /* bufferless IPI */
+        mailbox at ff370000 {
+          compatible = "xlnx,versal-ipi-dest-mailbox";
+          reg = <0x0 0xff370000 0x0 0x1000>;
+          reg-names = "ctrl";
+          #mbox-cells = <1>;
+          xlnx,ipi-id = <7>;
+        };
+      };
+    };
 ...
-- 
2.25.1



From s-vadapalli at ti.com  Wed Dec 13 21:44:13 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Thu, 14 Dec 2023 11:14:13 +0530
Subject: [PATCH v2] arm64: dts: ti: k3-am654-icssg2: Enable PHY interrupts
 for ICSSG2
In-Reply-To: <20231213123819.tqh3lm2ceir3qjbk@swimmer>
References: <20231213080216.1710730-1-s-vadapalli@ti.com>
 <20231213123819.tqh3lm2ceir3qjbk@swimmer>
Message-ID: <6f1c1a59-cec0-46d1-8ecb-a82d9d444ccf@ti.com>

Hello Nishanth,

On 13/12/23 18:08, Nishanth Menon wrote:
> On 13:32-20231213, Siddharth Vadapalli wrote:
>> Enable interrupt mode of operation of the DP83867 Ethernet PHY which is
>> used by ICSSG2. The DP83867 PHY driver already supports interrupt handling
>> for interrupts generated by the PHY. Thus, add the necessary device-tree
>> support to enable it.
>>
>> Since the GPIO1_87 line is muxed with EXT_REFCLK1 and SYNC1_OUT, update
>> the pinmux to select GPIO1_87 for routing the interrupt.
>>
>> As the same interrupt line and therefore the same pinmux configuration is
>> applicable to both Ethernet PHYs used by ICSSG2, allocate the pinmux
>> resource to the first Ethernet PHY alone.

...

> 
> https://www.ti.com/lit/ds/symlink/dp83867ir.pdf -> it looks like the
> interrupt pin is level event. but drivers/gpio/gpio-davinci.c::
> gpio_irq_type() -> The SoC cannot handle level, only edge.
> 
> A bit confused here..  GPIO 87 is shared between two phys. isn't it a
> case of race?
> 
> PHY1 assets low
> phy1 handler starts, but before the driver it clears the condition:
> PHY2 asserts low - but since the signal is already low, there is no
> pulse
> phy1 handler clears phy1 condition, but signal is still low due to phy2?
> now phy2 OR phy1 never gets handled since there is never a pulse event
> ever again.

Yes, you are right! Edge-Triggered interrupts shouldn't be shared. I missed
noticing this. Thank you for pointing it out. Since the SoC only supports
Edge-Triggered interrupts, I believe that the correct decision would be to use
the interrupt for only one of the two PHYs, while leaving the other PHY in
polled mode of operation which is the default.

Kindly let me know if this is acceptable and I shall update this patch accordingly.

> 
> 
>>  		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>>  		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
>>  	};
>> -- 
>> 2.34.1
>>
> 

-- 
Regards,
Siddharth.


From shawn.sung at mediatek.com  Wed Dec 13 21:58:29 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:29 +0800
Subject: [PATCH v12 05/23] dt-bindings: arm: mediatek: Add compatible for MT8188
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-6-shawn.sung@mediatek.com>

Add compatible name for MediaTek MT8188 VDOSYS1.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml         | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index 536f5a5ebd24..642fa2e4736e 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -32,6 +32,7 @@ properties:
               - mediatek,mt8183-mmsys
               - mediatek,mt8186-mmsys
               - mediatek,mt8188-vdosys0
+              - mediatek,mt8188-vdosys1
               - mediatek,mt8192-mmsys
               - mediatek,mt8195-vdosys1
               - mediatek,mt8195-vppsys0
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:44 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:44 +0800
Subject: [PATCH v12 20/23] drm/mediatek: Return error if MDP RDMA failed to enable the clock
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-21-shawn.sung@mediatek.com>

Return the result of clk_prepare_enable() instead of
always returns 0.

Fixes: f8946e2b6bb2 ("drm/mediatek: Add display MDP RDMA support for MT8195")

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
index dc7c9e991990..ee9ce9b6d078 100644
--- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
@@ -262,8 +262,7 @@ int mtk_mdp_rdma_clk_enable(struct device *dev)
 {
 	struct mtk_mdp_rdma *rdma = dev_get_drvdata(dev);
 
-	clk_prepare_enable(rdma->clk);
-	return 0;
+	return clk_prepare_enable(rdma->clk);
 }
 
 void mtk_mdp_rdma_clk_disable(struct device *dev)
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:25 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:25 +0800
Subject: [PATCH v12 01/23] dt-bindings: display: mediatek: ethdr: Add compatible for MT8188
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-2-shawn.sung@mediatek.com>

Add compatible name for MediaTek MT8188 ETHDR.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: CK Hu <ck.hu at mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../bindings/display/mediatek/mediatek,ethdr.yaml           | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
index 801fa66ae615..677882348ede 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
@@ -23,7 +23,11 @@ description:
 
 properties:
   compatible:
-    const: mediatek,mt8195-disp-ethdr
+    oneOf:
+      - const: mediatek,mt8195-disp-ethdr
+      - items:
+          - const: mediatek,mt8188-disp-ethdr
+          - const: mediatek,mt8195-disp-ethdr
 
   reg:
     maxItems: 7
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:37 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:37 +0800
Subject: [PATCH v12 13/23] drm/mediatek: Manage component's clock with function pointers
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-14-shawn.sung@mediatek.com>

By registering component related functions to the pointers,
we can easily manage them within a for-loop and simplify the
logic of clock control significantly.

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 89 +++++++++----------
 1 file changed, 43 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 9f569d0f52b3..a815dc8e2110 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -54,6 +54,7 @@ struct ovl_adaptor_comp_match {
 	enum mtk_ovl_adaptor_comp_type type;
 	enum mtk_ddp_comp_id comp_id;
 	int alias_id;
+	const struct mtk_ddp_comp_funcs *funcs;
 };
 
 struct mtk_disp_ovl_adaptor {
@@ -68,20 +69,35 @@ static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
 	[OVL_ADAPTOR_TYPE_ETHDR]	= "ethdr",
 };
 
+static const struct mtk_ddp_comp_funcs ethdr = {
+	.clk_enable = mtk_ethdr_clk_enable,
+	.clk_disable = mtk_ethdr_clk_disable,
+};
+
+static const struct mtk_ddp_comp_funcs merge = {
+	.clk_enable = mtk_merge_clk_enable,
+	.clk_disable = mtk_merge_clk_disable,
+};
+
+static const struct mtk_ddp_comp_funcs rdma = {
+	.clk_enable = mtk_mdp_rdma_clk_enable,
+	.clk_disable = mtk_mdp_rdma_clk_disable,
+};
+
 static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
-	[OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA0, 0 },
-	[OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA1, 1 },
-	[OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA2, 2 },
-	[OVL_ADAPTOR_MDP_RDMA3] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA3, 3 },
-	[OVL_ADAPTOR_MDP_RDMA4] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA4, 4 },
-	[OVL_ADAPTOR_MDP_RDMA5] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA5, 5 },
-	[OVL_ADAPTOR_MDP_RDMA6] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA6, 6 },
-	[OVL_ADAPTOR_MDP_RDMA7] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA7, 7 },
-	[OVL_ADAPTOR_MERGE0] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE1, 1 },
-	[OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 2 },
-	[OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 3 },
-	[OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 4 },
-	[OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, DDP_COMPONENT_ETHDR_MIXER, 0 },
+	[OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA0, 0, &rdma },
+	[OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA1, 1, &rdma },
+	[OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA2, 2, &rdma },
+	[OVL_ADAPTOR_MDP_RDMA3] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA3, 3, &rdma },
+	[OVL_ADAPTOR_MDP_RDMA4] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA4, 4, &rdma },
+	[OVL_ADAPTOR_MDP_RDMA5] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA5, 5, &rdma },
+	[OVL_ADAPTOR_MDP_RDMA6] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA6, 6, &rdma },
+	[OVL_ADAPTOR_MDP_RDMA7] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA7, 7, &rdma },
+	[OVL_ADAPTOR_MERGE0] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE1, 1, &merge },
+	[OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 2, &merge },
+	[OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 3, &merge },
+	[OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 4, &merge },
+	[OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, DDP_COMPONENT_ETHDR_MIXER, 0, &ethdr },
 };
 
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
@@ -197,40 +213,25 @@ int mtk_ovl_adaptor_clk_enable(struct device *dev)
 		ret = pm_runtime_get_sync(comp);
 		if (ret < 0) {
 			dev_err(dev, "Failed to enable power domain %d, err %d\n", i, ret);
-			goto pwr_err;
+			goto error;
 		}
 	}
 
 	for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
 		comp = ovl_adaptor->ovl_adaptor_comp[i];
-
-		if (i < OVL_ADAPTOR_MERGE0)
-			ret = mtk_mdp_rdma_clk_enable(comp);
-		else if (i < OVL_ADAPTOR_ETHDR0)
-			ret = mtk_merge_clk_enable(comp);
-		else
-			ret = mtk_ethdr_clk_enable(comp);
+		if (!comp || !comp_matches[i].funcs->clk_enable)
+			continue;
+		ret = comp_matches[i].funcs->clk_enable(comp);
 		if (ret) {
 			dev_err(dev, "Failed to enable clock %d, err %d\n", i, ret);
-			goto clk_err;
+			while (--i >= 0)
+				comp_matches[i].funcs->clk_disable(comp);
+			i = OVL_ADAPTOR_MERGE0;
+			goto error;
 		}
 	}
-
-	return ret;
-
-clk_err:
-	while (--i >= 0) {
-		comp = ovl_adaptor->ovl_adaptor_comp[i];
-		if (i < OVL_ADAPTOR_MERGE0)
-			mtk_mdp_rdma_clk_disable(comp);
-		else if (i < OVL_ADAPTOR_ETHDR0)
-			mtk_merge_clk_disable(comp);
-		else
-			mtk_ethdr_clk_disable(comp);
-	}
-	i = OVL_ADAPTOR_MERGE0;
-
-pwr_err:
+	return 0;
+error:
 	while (--i >= 0)
 		pm_runtime_put(ovl_adaptor->ovl_adaptor_comp[i]);
 
@@ -245,15 +246,11 @@ void mtk_ovl_adaptor_clk_disable(struct device *dev)
 
 	for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
 		comp = ovl_adaptor->ovl_adaptor_comp[i];
-
-		if (i < OVL_ADAPTOR_MERGE0) {
-			mtk_mdp_rdma_clk_disable(comp);
+		if (!comp || !comp_matches[i].funcs->clk_disable)
+			continue;
+		comp_matches[i].funcs->clk_disable(comp);
+		if (i < OVL_ADAPTOR_MERGE0)
 			pm_runtime_put(comp);
-		} else if (i < OVL_ADAPTOR_ETHDR0) {
-			mtk_merge_clk_disable(comp);
-		} else {
-			mtk_ethdr_clk_disable(comp);
-		}
 	}
 }
 
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:30 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:30 +0800
Subject: [PATCH v12 06/23] dt-bindings: reset: mt8188: Add VDOSYS reset control bits
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-7-shawn.sung@mediatek.com>

Add MT8188 VDOSYS0 and VDOSYS1 reset control bits.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 include/dt-bindings/reset/mt8188-resets.h | 75 +++++++++++++++++++++++
 1 file changed, 75 insertions(+)

diff --git a/include/dt-bindings/reset/mt8188-resets.h b/include/dt-bindings/reset/mt8188-resets.h
index ba9a5e9b8899..5a58c54e7d20 100644
--- a/include/dt-bindings/reset/mt8188-resets.h
+++ b/include/dt-bindings/reset/mt8188-resets.h
@@ -38,4 +38,79 @@
 #define MT8188_INFRA_RST1_THERMAL_CTRL_RST         1
 #define MT8188_INFRA_RST3_PTP_CTRL_RST             2
 
+#define MT8188_VDO0_RST_DISP_OVL0		0
+#define MT8188_VDO0_RST_FAKE_ENG0		1
+#define MT8188_VDO0_RST_DISP_CCORR0		2
+#define MT8188_VDO0_RST_DISP_MUTEX0		3
+#define MT8188_VDO0_RST_DISP_GAMMA0		4
+#define MT8188_VDO0_RST_DISP_DITHER0		5
+#define MT8188_VDO0_RST_DISP_WDMA0		6
+#define MT8188_VDO0_RST_DISP_RDMA0		7
+#define MT8188_VDO0_RST_DSI0			8
+#define MT8188_VDO0_RST_DSI1			9
+#define MT8188_VDO0_RST_DSC_WRAP0		10
+#define MT8188_VDO0_RST_VPP_MERGE0		11
+#define MT8188_VDO0_RST_DP_INTF0		12
+#define MT8188_VDO0_RST_DISP_AAL0		13
+#define MT8188_VDO0_RST_INLINEROT0		14
+#define MT8188_VDO0_RST_APB_BUS			15
+#define MT8188_VDO0_RST_DISP_COLOR0		16
+#define MT8188_VDO0_RST_MDP_WROT0		17
+#define MT8188_VDO0_RST_DISP_RSZ0		18
+
+#define MT8188_VDO1_RST_SMI_LARB2		0
+#define MT8188_VDO1_RST_SMI_LARB3		1
+#define MT8188_VDO1_RST_GALS			2
+#define MT8188_VDO1_RST_FAKE_ENG0		3
+#define MT8188_VDO1_RST_FAKE_ENG1		4
+#define MT8188_VDO1_RST_MDP_RDMA0		5
+#define MT8188_VDO1_RST_MDP_RDMA1		6
+#define MT8188_VDO1_RST_MDP_RDMA2		7
+#define MT8188_VDO1_RST_MDP_RDMA3		8
+#define MT8188_VDO1_RST_VPP_MERGE0		9
+#define MT8188_VDO1_RST_VPP_MERGE1		10
+#define MT8188_VDO1_RST_VPP_MERGE2		11
+#define MT8188_VDO1_RST_VPP_MERGE3		12
+#define MT8188_VDO1_RST_VPP_MERGE4		13
+#define MT8188_VDO1_RST_VPP2_TO_VDO1_DL_ASYNC	14
+#define MT8188_VDO1_RST_VPP3_TO_VDO1_DL_ASYNC	15
+#define MT8188_VDO1_RST_DISP_MUTEX		16
+#define MT8188_VDO1_RST_MDP_RDMA4		17
+#define MT8188_VDO1_RST_MDP_RDMA5		18
+#define MT8188_VDO1_RST_MDP_RDMA6		19
+#define MT8188_VDO1_RST_MDP_RDMA7		20
+#define MT8188_VDO1_RST_DP_INTF1_MMCK		21
+#define MT8188_VDO1_RST_DPI0_MM_CK		22
+#define MT8188_VDO1_RST_DPI1_MM_CK		23
+#define MT8188_VDO1_RST_MERGE0_DL_ASYNC		24
+#define MT8188_VDO1_RST_MERGE1_DL_ASYNC		25
+#define MT8188_VDO1_RST_MERGE2_DL_ASYNC		26
+#define MT8188_VDO1_RST_MERGE3_DL_ASYNC		27
+#define MT8188_VDO1_RST_MERGE4_DL_ASYNC		28
+#define MT8188_VDO1_RST_VDO0_DSC_TO_VDO1_DL_ASYNC	29
+#define MT8188_VDO1_RST_VDO0_MERGE_TO_VDO1_DL_ASYNC	30
+#define MT8188_VDO1_RST_PADDING0		31
+#define MT8188_VDO1_RST_PADDING1		32
+#define MT8188_VDO1_RST_PADDING2		33
+#define MT8188_VDO1_RST_PADDING3		34
+#define MT8188_VDO1_RST_PADDING4		35
+#define MT8188_VDO1_RST_PADDING5		36
+#define MT8188_VDO1_RST_PADDING6		37
+#define MT8188_VDO1_RST_PADDING7		38
+#define MT8188_VDO1_RST_DISP_RSZ0		39
+#define MT8188_VDO1_RST_DISP_RSZ1		40
+#define MT8188_VDO1_RST_DISP_RSZ2		41
+#define MT8188_VDO1_RST_DISP_RSZ3		42
+#define MT8188_VDO1_RST_HDR_VDO_FE0		43
+#define MT8188_VDO1_RST_HDR_GFX_FE0		44
+#define MT8188_VDO1_RST_HDR_VDO_BE		45
+#define MT8188_VDO1_RST_HDR_VDO_FE1		46
+#define MT8188_VDO1_RST_HDR_GFX_FE1		47
+#define MT8188_VDO1_RST_DISP_MIXER		48
+#define MT8188_VDO1_RST_HDR_VDO_FE0_DL_ASYNC	49
+#define MT8188_VDO1_RST_HDR_VDO_FE1_DL_ASYNC	50
+#define MT8188_VDO1_RST_HDR_GFX_FE0_DL_ASYNC	51
+#define MT8188_VDO1_RST_HDR_GFX_FE1_DL_ASYNC	52
+#define MT8188_VDO1_RST_HDR_VDO_BE_DL_ASYNC	53
+
 #endif  /* _DT_BINDINGS_RESET_CONTROLLER_MT8188 */
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:24 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:24 +0800
Subject: [PATCH v12 00/23] Add display driver for MT8188 VDOSYS1
Message-ID: <20231214055847.4936-1-shawn.sung@mediatek.com>

This series is based on mediatek-drm-next branch of
kernel/git/chunkuang.hu/linux.git

Changes in v12:
- Rebase on mediatek-drm-next branch of kernel/git/chunkuang.hu/linux.git

Changes in v11:
- Change "mtk-padding" to "mtk-disp-padding" for consistency
- Remove patch "drm/mediatek: Remove ineffectual power management codes
  for backward compatibility

Changes in v10:
- Remove "Reviewed-by" tags from the following commits:
    - drm/mediatek: Power on/off devices with function pointers
    - drm/mediatek: Manage component's clock with function pointers
- Separate the commit into smaller ones
    - (new) drm/mediatek: Remove ineffectual power management codes

Changes in v9:
- Add a static inline function to power off the device
- Change driver name to "mediatek-disp-padding"
- Fix typo and kernel doc format error

Changes in v8:
- Power on/off the components with .power_on() and .power_off()
- Remove mtk_padding_config()
- Remove "Reviewed-by" tags from "drm/mediatek: Add Padding to OVL adaptor"

Changes in v7:
- Start/Stop the components in OVL Adaptor with function pointers
- Refine Padding driver
- Fix underrun when the layer is switching off

Changes in v6:
- Separate the commits into smaller ones
- Add DPI input mode setting
- Fix VDOSYS1 power-on issues

Changes in v5:
- Reuse .clk_enable/.clk_disable in struct mtk_ddp_comp_funcs
  in mtk_disp_ovl_adaptor.c
- Adjust commits order

Changes in v4:
- Add new functions in mtk_disp_ovl_adaptor.c to enable/disable
  components and reuse them when clock enable/disable
- Rename components in mtk_disp_ovl_adaptor.c and sort them in
  alphabetical order

Changes in v3:
- Define macro MMSYS_RST_NR in mtk-mmsys.h and update reset table
- Fix typos (ETDHR -> ETHDR, VSNYC -> VSYNC)
- Rebase dt-bindings on linux-next
- Refine description of Padding
- Squash reset bit map commits for VDO0 and VDO1 into one

Changes in v2:
- Remove redundant compatibles of MT8188 because it shares the same
  configuration with MT8195
- Separate dt-bindings by modules
- Support reset bit mapping in mmsys driver

Hsiao Chien Sung (23):
  dt-bindings: display: mediatek: ethdr: Add compatible for MT8188
  dt-bindings: display: mediatek: mdp-rdma: Add compatible for MT8188
  dt-bindings: display: mediatek: merge: Add compatible for MT8188
  dt-bindings: display: mediatek: padding: Add MT8188
  dt-bindings: arm: mediatek: Add compatible for MT8188
  dt-bindings: reset: mt8188: Add VDOSYS reset control bits
  soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsys
  soc: mediatek: Support MT8188 VDOSYS1 Padding in mtk-mmsys
  soc: mediatek: Support reset bit mapping in mmsys driver
  soc: mediatek: Add MT8188 VDOSYS reset bit map
  drm/mediatek: Rename OVL_ADAPTOR_TYPE_RDMA
  drm/mediatek: Add component ID to component match structure
  drm/mediatek: Manage component's clock with function pointers
  drm/mediatek: Power on/off devices with function pointers
  drm/mediatek: Start/Stop components with function pointers
  drm/mediatek: Sort OVL adaptor components
  drm/mediatek: Refine device table of OVL adaptor
  drm/mediatek: Support MT8188 Padding in display driver
  drm/mediatek: Add Padding to OVL adaptor
  drm/mediatek: Return error if MDP RDMA failed to enable the clock
  drm/mediatek: Remove the redundant driver data for DPI
  drm/mediatek: Fix underrun in VDO1 when switches off the layer
  drm/mediatek: Support MT8188 VDOSYS1 in display driver

 .../bindings/arm/mediatek/mediatek,mmsys.yaml |   1 +
 .../display/mediatek/mediatek,ethdr.yaml      |   6 +-
 .../display/mediatek/mediatek,mdp-rdma.yaml   |   6 +-
 .../display/mediatek/mediatek,merge.yaml      |   3 +
 .../display/mediatek/mediatek,padding.yaml    |  81 ++++++
 drivers/gpu/drm/mediatek/Makefile             |   3 +-
 drivers/gpu/drm/mediatek/mtk_disp_drv.h       |   8 +
 drivers/gpu/drm/mediatek/mtk_disp_merge.c     |   2 +-
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 274 +++++++++++-------
 drivers/gpu/drm/mediatek/mtk_dpi.c            |  16 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c       |  10 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |   2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   |  20 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c        |   5 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h        |   2 +-
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c       |  19 +-
 drivers/gpu/drm/mediatek/mtk_padding.c        | 160 ++++++++++
 drivers/soc/mediatek/mt8188-mmsys.h           | 210 ++++++++++++++
 drivers/soc/mediatek/mtk-mmsys.c              |  27 ++
 drivers/soc/mediatek/mtk-mmsys.h              |  32 ++
 drivers/soc/mediatek/mtk-mutex.c              |  51 ++++
 include/dt-bindings/reset/mt8188-resets.h     |  75 +++++
 include/linux/soc/mediatek/mtk-mmsys.h        |   8 +
 23 files changed, 890 insertions(+), 131 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
 create mode 100644 drivers/gpu/drm/mediatek/mtk_padding.c

--
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:36 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:36 +0800
Subject: [PATCH v12 12/23] drm/mediatek: Add component ID to component match structure
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-13-shawn.sung@mediatek.com>

Add component ID to component match structure so we can
configure them with a for-loop.

The main reason we do such code refactoring is that
there is a new hardware component called "Padding" since
MT8188, while MT8195 doesn't have this module, we can't
use the original logic to manage the components.

While MT8195 does not define Padding in the device tree,
the corresponding components will be NULL and being skipped
by the functions.

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 69 ++++++++-----------
 1 file changed, 30 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 114eded8177e..9f569d0f52b3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -52,6 +52,7 @@ enum mtk_ovl_adaptor_comp_id {
 
 struct ovl_adaptor_comp_match {
 	enum mtk_ovl_adaptor_comp_type type;
+	enum mtk_ddp_comp_id comp_id;
 	int alias_id;
 };
 
@@ -68,19 +69,19 @@ static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
 };
 
 static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
-	[OVL_ADAPTOR_MDP_RDMA0]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 0 },
-	[OVL_ADAPTOR_MDP_RDMA1]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 1 },
-	[OVL_ADAPTOR_MDP_RDMA2]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 2 },
-	[OVL_ADAPTOR_MDP_RDMA3]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 3 },
-	[OVL_ADAPTOR_MDP_RDMA4]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 4 },
-	[OVL_ADAPTOR_MDP_RDMA5]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 5 },
-	[OVL_ADAPTOR_MDP_RDMA6]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 6 },
-	[OVL_ADAPTOR_MDP_RDMA7]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 7 },
-	[OVL_ADAPTOR_MERGE0]	= { OVL_ADAPTOR_TYPE_MERGE, 1 },
-	[OVL_ADAPTOR_MERGE1]	= { OVL_ADAPTOR_TYPE_MERGE, 2 },
-	[OVL_ADAPTOR_MERGE2]	= { OVL_ADAPTOR_TYPE_MERGE, 3 },
-	[OVL_ADAPTOR_MERGE3]	= { OVL_ADAPTOR_TYPE_MERGE, 4 },
-	[OVL_ADAPTOR_ETHDR0]	= { OVL_ADAPTOR_TYPE_ETHDR, 0 },
+	[OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA0, 0 },
+	[OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA1, 1 },
+	[OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA2, 2 },
+	[OVL_ADAPTOR_MDP_RDMA3] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA3, 3 },
+	[OVL_ADAPTOR_MDP_RDMA4] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA4, 4 },
+	[OVL_ADAPTOR_MDP_RDMA5] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA5, 5 },
+	[OVL_ADAPTOR_MDP_RDMA6] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA6, 6 },
+	[OVL_ADAPTOR_MDP_RDMA7] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA7, 7 },
+	[OVL_ADAPTOR_MERGE0] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE1, 1 },
+	[OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 2 },
+	[OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 3 },
+	[OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 4 },
+	[OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, DDP_COMPONENT_ETHDR_MIXER, 0 },
 };
 
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
@@ -314,36 +315,26 @@ size_t mtk_ovl_adaptor_get_num_formats(struct device *dev)
 
 void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex *mutex)
 {
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA0);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA1);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA2);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA3);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA4);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA5);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA6);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA7);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MERGE1);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MERGE2);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MERGE3);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_MERGE4);
-	mtk_mutex_add_comp(mutex, DDP_COMPONENT_ETHDR_MIXER);
+	int i;
+	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+	for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+		if (!ovl_adaptor->ovl_adaptor_comp[i])
+			continue;
+		mtk_mutex_add_comp(mutex, comp_matches[i].comp_id);
+	}
 }
 
 void mtk_ovl_adaptor_remove_comp(struct device *dev, struct mtk_mutex *mutex)
 {
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA0);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA1);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA2);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA3);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA4);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA5);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA6);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MDP_RDMA7);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MERGE1);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MERGE2);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MERGE3);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_MERGE4);
-	mtk_mutex_remove_comp(mutex, DDP_COMPONENT_ETHDR_MIXER);
+	int i;
+	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+	for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+		if (!ovl_adaptor->ovl_adaptor_comp[i])
+			continue;
+		mtk_mutex_remove_comp(mutex, comp_matches[i].comp_id);
+	}
 }
 
 void mtk_ovl_adaptor_connect(struct device *dev, struct device *mmsys_dev, unsigned int next)
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:34 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:34 +0800
Subject: [PATCH v12 10/23] soc: mediatek: Add MT8188 VDOSYS reset bit map
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-11-shawn.sung@mediatek.com>

Add MT8188 reset bit map for VDOSYS0 and VDOSYS1.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/soc/mediatek/mt8188-mmsys.h | 84 +++++++++++++++++++++++++++++
 drivers/soc/mediatek/mtk-mmsys.c    |  7 ++-
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mt8188-mmsys.h b/drivers/soc/mediatek/mt8188-mmsys.h
index a9490c3c4256..6bebf1a69fc0 100644
--- a/drivers/soc/mediatek/mt8188-mmsys.h
+++ b/drivers/soc/mediatek/mt8188-mmsys.h
@@ -3,6 +3,10 @@
 #ifndef __SOC_MEDIATEK_MT8188_MMSYS_H
 #define __SOC_MEDIATEK_MT8188_MMSYS_H
 
+#include <linux/soc/mediatek/mtk-mmsys.h>
+#include <dt-bindings/reset/mt8188-resets.h>
+
+#define MT8188_VDO0_SW0_RST_B				0x190
 #define MT8188_VDO0_OVL_MOUT_EN				0xf14
 #define MT8188_MOUT_DISP_OVL0_TO_DISP_RDMA0		BIT(0)
 #define MT8188_MOUT_DISP_OVL0_TO_DISP_WDMA0		BIT(1)
@@ -67,6 +71,7 @@
 #define MT8188_SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE		BIT(18)
 #define MT8188_SOUT_DSC_WRAP0_OUT_TO_DISP_WDMA0		BIT(19)
 
+#define MT8188_VDO1_SW0_RST_B					0x1d0
 #define MT8188_VDO1_HDR_TOP_CFG					0xd00
 #define MT8188_VDO1_MIXER_IN1_ALPHA				0xd30
 #define MT8188_VDO1_MIXER_IN1_PAD				0xd40
@@ -117,6 +122,85 @@
 #define MT8188_VDO1_MIXER_SOUT_SEL_IN				0xf68
 #define MT8188_MIXER_SOUT_SEL_IN_FROM_DISP_MIXER		0
 
+static const u8 mmsys_mt8188_vdo0_rst_tb[] = {
+	[MT8188_VDO0_RST_DISP_OVL0]	= MMSYS_RST_NR(0, 0),
+	[MT8188_VDO0_RST_FAKE_ENG0]	= MMSYS_RST_NR(0, 2),
+	[MT8188_VDO0_RST_DISP_CCORR0]	= MMSYS_RST_NR(0, 4),
+	[MT8188_VDO0_RST_DISP_MUTEX0]	= MMSYS_RST_NR(0, 6),
+	[MT8188_VDO0_RST_DISP_GAMMA0]	= MMSYS_RST_NR(0, 8),
+	[MT8188_VDO0_RST_DISP_DITHER0]	= MMSYS_RST_NR(0, 10),
+	[MT8188_VDO0_RST_DISP_WDMA0]	= MMSYS_RST_NR(0, 17),
+	[MT8188_VDO0_RST_DISP_RDMA0]	= MMSYS_RST_NR(0, 19),
+	[MT8188_VDO0_RST_DSI0]		= MMSYS_RST_NR(0, 21),
+	[MT8188_VDO0_RST_DSI1]		= MMSYS_RST_NR(0, 22),
+	[MT8188_VDO0_RST_DSC_WRAP0]	= MMSYS_RST_NR(0, 23),
+	[MT8188_VDO0_RST_VPP_MERGE0]	= MMSYS_RST_NR(0, 24),
+	[MT8188_VDO0_RST_DP_INTF0]	= MMSYS_RST_NR(0, 25),
+	[MT8188_VDO0_RST_DISP_AAL0]	= MMSYS_RST_NR(0, 26),
+	[MT8188_VDO0_RST_INLINEROT0]	= MMSYS_RST_NR(0, 27),
+	[MT8188_VDO0_RST_APB_BUS]	= MMSYS_RST_NR(0, 28),
+	[MT8188_VDO0_RST_DISP_COLOR0]	= MMSYS_RST_NR(0, 29),
+	[MT8188_VDO0_RST_MDP_WROT0]	= MMSYS_RST_NR(0, 30),
+	[MT8188_VDO0_RST_DISP_RSZ0]	= MMSYS_RST_NR(0, 31),
+};
+
+static const u8 mmsys_mt8188_vdo1_rst_tb[] = {
+	[MT8188_VDO1_RST_SMI_LARB2]			= MMSYS_RST_NR(0, 0),
+	[MT8188_VDO1_RST_SMI_LARB3]			= MMSYS_RST_NR(0, 1),
+	[MT8188_VDO1_RST_GALS]				= MMSYS_RST_NR(0, 2),
+	[MT8188_VDO1_RST_FAKE_ENG0]			= MMSYS_RST_NR(0, 3),
+	[MT8188_VDO1_RST_FAKE_ENG1]			= MMSYS_RST_NR(0, 4),
+	[MT8188_VDO1_RST_MDP_RDMA0]			= MMSYS_RST_NR(0, 5),
+	[MT8188_VDO1_RST_MDP_RDMA1]			= MMSYS_RST_NR(0, 6),
+	[MT8188_VDO1_RST_MDP_RDMA2]			= MMSYS_RST_NR(0, 7),
+	[MT8188_VDO1_RST_MDP_RDMA3]			= MMSYS_RST_NR(0, 8),
+	[MT8188_VDO1_RST_VPP_MERGE0]			= MMSYS_RST_NR(0, 9),
+	[MT8188_VDO1_RST_VPP_MERGE1]			= MMSYS_RST_NR(0, 10),
+	[MT8188_VDO1_RST_VPP_MERGE2]			= MMSYS_RST_NR(0, 11),
+	[MT8188_VDO1_RST_VPP_MERGE3]			= MMSYS_RST_NR(1, 0),
+	[MT8188_VDO1_RST_VPP_MERGE4]			= MMSYS_RST_NR(1, 1),
+	[MT8188_VDO1_RST_VPP2_TO_VDO1_DL_ASYNC]		= MMSYS_RST_NR(1, 2),
+	[MT8188_VDO1_RST_VPP3_TO_VDO1_DL_ASYNC]		= MMSYS_RST_NR(1, 3),
+	[MT8188_VDO1_RST_DISP_MUTEX]			= MMSYS_RST_NR(1, 4),
+	[MT8188_VDO1_RST_MDP_RDMA4]			= MMSYS_RST_NR(1, 5),
+	[MT8188_VDO1_RST_MDP_RDMA5]			= MMSYS_RST_NR(1, 6),
+	[MT8188_VDO1_RST_MDP_RDMA6]			= MMSYS_RST_NR(1, 7),
+	[MT8188_VDO1_RST_MDP_RDMA7]			= MMSYS_RST_NR(1, 8),
+	[MT8188_VDO1_RST_DP_INTF1_MMCK]			= MMSYS_RST_NR(1, 9),
+	[MT8188_VDO1_RST_DPI0_MM_CK]			= MMSYS_RST_NR(1, 10),
+	[MT8188_VDO1_RST_DPI1_MM_CK]			= MMSYS_RST_NR(1, 11),
+	[MT8188_VDO1_RST_MERGE0_DL_ASYNC]		= MMSYS_RST_NR(1, 13),
+	[MT8188_VDO1_RST_MERGE1_DL_ASYNC]		= MMSYS_RST_NR(1, 14),
+	[MT8188_VDO1_RST_MERGE2_DL_ASYNC]		= MMSYS_RST_NR(1, 15),
+	[MT8188_VDO1_RST_MERGE3_DL_ASYNC]		= MMSYS_RST_NR(1, 16),
+	[MT8188_VDO1_RST_MERGE4_DL_ASYNC]		= MMSYS_RST_NR(1, 17),
+	[MT8188_VDO1_RST_VDO0_DSC_TO_VDO1_DL_ASYNC]	= MMSYS_RST_NR(1, 18),
+	[MT8188_VDO1_RST_VDO0_MERGE_TO_VDO1_DL_ASYNC]	= MMSYS_RST_NR(1, 19),
+	[MT8188_VDO1_RST_PADDING0]			= MMSYS_RST_NR(1, 20),
+	[MT8188_VDO1_RST_PADDING1]			= MMSYS_RST_NR(1, 21),
+	[MT8188_VDO1_RST_PADDING2]			= MMSYS_RST_NR(1, 22),
+	[MT8188_VDO1_RST_PADDING3]			= MMSYS_RST_NR(1, 23),
+	[MT8188_VDO1_RST_PADDING4]			= MMSYS_RST_NR(1, 24),
+	[MT8188_VDO1_RST_PADDING5]			= MMSYS_RST_NR(1, 25),
+	[MT8188_VDO1_RST_PADDING6]			= MMSYS_RST_NR(1, 26),
+	[MT8188_VDO1_RST_PADDING7]			= MMSYS_RST_NR(1, 27),
+	[MT8188_VDO1_RST_DISP_RSZ0]			= MMSYS_RST_NR(1, 28),
+	[MT8188_VDO1_RST_DISP_RSZ1]			= MMSYS_RST_NR(1, 29),
+	[MT8188_VDO1_RST_DISP_RSZ2]			= MMSYS_RST_NR(1, 30),
+	[MT8188_VDO1_RST_DISP_RSZ3]			= MMSYS_RST_NR(1, 31),
+	[MT8188_VDO1_RST_HDR_VDO_FE0]			= MMSYS_RST_NR(2, 0),
+	[MT8188_VDO1_RST_HDR_GFX_FE0]			= MMSYS_RST_NR(2, 1),
+	[MT8188_VDO1_RST_HDR_VDO_BE]			= MMSYS_RST_NR(2, 2),
+	[MT8188_VDO1_RST_HDR_VDO_FE1]			= MMSYS_RST_NR(2, 16),
+	[MT8188_VDO1_RST_HDR_GFX_FE1]			= MMSYS_RST_NR(2, 17),
+	[MT8188_VDO1_RST_DISP_MIXER]			= MMSYS_RST_NR(2, 18),
+	[MT8188_VDO1_RST_HDR_VDO_FE0_DL_ASYNC]		= MMSYS_RST_NR(2, 19),
+	[MT8188_VDO1_RST_HDR_VDO_FE1_DL_ASYNC]		= MMSYS_RST_NR(2, 20),
+	[MT8188_VDO1_RST_HDR_GFX_FE0_DL_ASYNC]		= MMSYS_RST_NR(2, 21),
+	[MT8188_VDO1_RST_HDR_GFX_FE1_DL_ASYNC]		= MMSYS_RST_NR(2, 22),
+	[MT8188_VDO1_RST_HDR_VDO_BE_DL_ASYNC]		= MMSYS_RST_NR(2, 23),
+};
+
 static const struct mtk_mmsys_routes mmsys_mt8188_routing_table[] = {
 	{
 		DDP_COMPONENT_OVL0, DDP_COMPONENT_RDMA0,
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index fee958d0b8a6..08a1c22de00b 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -87,13 +87,18 @@ static const struct mtk_mmsys_driver_data mt8188_vdosys0_driver_data = {
 	.clk_driver = "clk-mt8188-vdo0",
 	.routes = mmsys_mt8188_routing_table,
 	.num_routes = ARRAY_SIZE(mmsys_mt8188_routing_table),
+	.sw0_rst_offset = MT8188_VDO0_SW0_RST_B,
+	.rst_tb = mmsys_mt8188_vdo0_rst_tb,
+	.num_resets = ARRAY_SIZE(mmsys_mt8188_vdo0_rst_tb),
 };
 
 static const struct mtk_mmsys_driver_data mt8188_vdosys1_driver_data = {
 	.clk_driver = "clk-mt8188-vdo1",
 	.routes = mmsys_mt8188_vdo1_routing_table,
 	.num_routes = ARRAY_SIZE(mmsys_mt8188_vdo1_routing_table),
-	.num_resets = 96,
+	.sw0_rst_offset = MT8188_VDO1_SW0_RST_B,
+	.rst_tb = mmsys_mt8188_vdo1_rst_tb,
+	.num_resets = ARRAY_SIZE(mmsys_mt8188_vdo1_rst_tb),
 	.vsync_len = 1,
 };
 
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:31 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:31 +0800
Subject: [PATCH v12 07/23] soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsys
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-8-shawn.sung@mediatek.com>

- Add register definitions for MT8188
- Add VDOSYS1 routing table
- Update MUTEX definitions accordingly
- Set VSYNC length from 0x40 (default) to 1 since ETHDR is bypassed

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/soc/mediatek/mt8188-mmsys.h | 126 ++++++++++++++++++++++++++++
 drivers/soc/mediatek/mtk-mmsys.c    |  13 +++
 drivers/soc/mediatek/mtk-mmsys.h    |  29 +++++++
 drivers/soc/mediatek/mtk-mutex.c    |  35 ++++++++
 4 files changed, 203 insertions(+)

diff --git a/drivers/soc/mediatek/mt8188-mmsys.h b/drivers/soc/mediatek/mt8188-mmsys.h
index 448cc3761b43..a9490c3c4256 100644
--- a/drivers/soc/mediatek/mt8188-mmsys.h
+++ b/drivers/soc/mediatek/mt8188-mmsys.h
@@ -67,6 +67,56 @@
 #define MT8188_SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE		BIT(18)
 #define MT8188_SOUT_DSC_WRAP0_OUT_TO_DISP_WDMA0		BIT(19)
 
+#define MT8188_VDO1_HDR_TOP_CFG					0xd00
+#define MT8188_VDO1_MIXER_IN1_ALPHA				0xd30
+#define MT8188_VDO1_MIXER_IN1_PAD				0xd40
+#define MT8188_VDO1_MIXER_VSYNC_LEN				0xd5c
+#define MT8188_VDO1_MERGE0_ASYNC_CFG_WD				0xe30
+#define MT8188_VDO1_HDRBE_ASYNC_CFG_WD				0xe70
+#define MT8188_VDO1_VPP_MERGE0_P0_SEL_IN			0xf04
+#define MT8188_VPP_MERGE0_P0_SEL_IN_FROM_MDP_RDMA0		1
+#define MT8188_VDO1_VPP_MERGE0_P1_SEL_IN			0xf08
+#define MT8188_VPP_MERGE0_P1_SEL_IN_FROM_MDP_RDMA1		1
+#define MT8188_VDO1_DISP_DPI1_SEL_IN				0xf10
+#define MT8188_DISP_DPI1_SEL_IN_FROM_VPP_MERGE4_MOUT		0
+#define MT8188_VDO1_DISP_DP_INTF0_SEL_IN			0xf14
+#define MT8188_DISP_DP_INTF0_SEL_IN_FROM_VPP_MERGE4_MOUT	0
+#define MT8188_VDO1_MERGE4_SOUT_SEL				0xf18
+#define MT8188_MERGE4_SOUT_TO_DPI1_SEL				BIT(2)
+#define MT8188_MERGE4_SOUT_TO_DP_INTF0_SEL			BIT(3)
+#define MT8188_VDO1_MIXER_IN1_SEL_IN				0xf24
+#define MT8188_MIXER_IN1_SEL_IN_FROM_MERGE0_ASYNC_SOUT		1
+#define MT8188_VDO1_MIXER_IN2_SEL_IN				0xf28
+#define MT8188_MIXER_IN2_SEL_IN_FROM_MERGE1_ASYNC_SOUT		1
+#define MT8188_VDO1_MIXER_IN3_SEL_IN				0xf2c
+#define MT8188_MIXER_IN3_SEL_IN_FROM_MERGE2_ASYNC_SOUT		1
+#define MT8188_VDO1_MIXER_IN4_SEL_IN				0xf30
+#define MT8188_MIXER_IN4_SEL_IN_FROM_MERGE3_ASYNC_SOUT		1
+#define MT8188_VDO1_MIXER_OUT_SOUT_SEL				0xf34
+#define MT8188_MIXER_SOUT_TO_MERGE4_ASYNC_SEL			1
+#define MT8188_VDO1_VPP_MERGE1_P0_SEL_IN			0xf3c
+#define MT8188_VPP_MERGE1_P0_SEL_IN_FROM_MDP_RDMA2		1
+#define MT8188_VDO1_MERGE0_ASYNC_SOUT_SEL			0xf40
+#define MT8188_SOUT_TO_MIXER_IN1_SEL				1
+#define MT8188_VDO1_MERGE1_ASYNC_SOUT_SEL			0xf44
+#define MT8188_SOUT_TO_MIXER_IN2_SEL				1
+#define MT8188_VDO1_MERGE2_ASYNC_SOUT_SEL			0xf48
+#define MT8188_SOUT_TO_MIXER_IN3_SEL				1
+#define MT8188_VDO1_MERGE3_ASYNC_SOUT_SEL			0xf4c
+#define MT8188_SOUT_TO_MIXER_IN4_SEL				1
+#define MT8188_VDO1_MERGE4_ASYNC_SEL_IN				0xf50
+#define MT8188_MERGE4_ASYNC_SEL_IN_FROM_MIXER_OUT_SOUT		1
+#define MT8188_VDO1_MIXER_IN1_SOUT_SEL				0xf58
+#define MT8188_MIXER_IN1_SOUT_TO_DISP_MIXER			0
+#define MT8188_VDO1_MIXER_IN2_SOUT_SEL				0xf5c
+#define MT8188_MIXER_IN2_SOUT_TO_DISP_MIXER			0
+#define MT8188_VDO1_MIXER_IN3_SOUT_SEL				0xf60
+#define MT8188_MIXER_IN3_SOUT_TO_DISP_MIXER			0
+#define MT8188_VDO1_MIXER_IN4_SOUT_SEL				0xf64
+#define MT8188_MIXER_IN4_SOUT_TO_DISP_MIXER			0
+#define MT8188_VDO1_MIXER_SOUT_SEL_IN				0xf68
+#define MT8188_MIXER_SOUT_SEL_IN_FROM_DISP_MIXER		0
+
 static const struct mtk_mmsys_routes mmsys_mt8188_routing_table[] = {
 	{
 		DDP_COMPONENT_OVL0, DDP_COMPONENT_RDMA0,
@@ -146,4 +196,80 @@ static const struct mtk_mmsys_routes mmsys_mt8188_routing_table[] = {
 	},
 };
 
+static const struct mtk_mmsys_routes mmsys_mt8188_vdo1_routing_table[] = {
+	{
+		DDP_COMPONENT_MDP_RDMA0, DDP_COMPONENT_MERGE1,
+		MT8188_VDO1_VPP_MERGE0_P0_SEL_IN, GENMASK(0, 0),
+		MT8188_VPP_MERGE0_P0_SEL_IN_FROM_MDP_RDMA0
+	}, {
+		DDP_COMPONENT_MDP_RDMA1, DDP_COMPONENT_MERGE1,
+		MT8188_VDO1_VPP_MERGE0_P1_SEL_IN, GENMASK(0, 0),
+		MT8188_VPP_MERGE0_P1_SEL_IN_FROM_MDP_RDMA1
+	}, {
+		DDP_COMPONENT_MDP_RDMA2, DDP_COMPONENT_MERGE2,
+		MT8188_VDO1_VPP_MERGE1_P0_SEL_IN, GENMASK(0, 0),
+		MT8188_VPP_MERGE1_P0_SEL_IN_FROM_MDP_RDMA2
+	}, {
+		DDP_COMPONENT_MERGE1, DDP_COMPONENT_ETHDR_MIXER,
+		MT8188_VDO1_MERGE0_ASYNC_SOUT_SEL, GENMASK(1, 0),
+		MT8188_SOUT_TO_MIXER_IN1_SEL
+	}, {
+		DDP_COMPONENT_MERGE2, DDP_COMPONENT_ETHDR_MIXER,
+		MT8188_VDO1_MERGE1_ASYNC_SOUT_SEL, GENMASK(1, 0),
+		MT8188_SOUT_TO_MIXER_IN2_SEL
+	}, {
+		DDP_COMPONENT_MERGE3, DDP_COMPONENT_ETHDR_MIXER,
+		MT8188_VDO1_MERGE2_ASYNC_SOUT_SEL, GENMASK(1, 0),
+		MT8188_SOUT_TO_MIXER_IN3_SEL
+	}, {
+		DDP_COMPONENT_MERGE4, DDP_COMPONENT_ETHDR_MIXER,
+		MT8188_VDO1_MERGE3_ASYNC_SOUT_SEL, GENMASK(1, 0),
+		MT8188_SOUT_TO_MIXER_IN4_SEL
+	}, {
+		DDP_COMPONENT_ETHDR_MIXER, DDP_COMPONENT_MERGE5,
+		MT8188_VDO1_MIXER_OUT_SOUT_SEL, GENMASK(0, 0),
+		MT8188_MIXER_SOUT_TO_MERGE4_ASYNC_SEL
+	}, {
+		DDP_COMPONENT_MERGE1, DDP_COMPONENT_ETHDR_MIXER,
+		MT8188_VDO1_MIXER_IN1_SEL_IN, GENMASK(0, 0),
+		MT8188_MIXER_IN1_SEL_IN_FROM_MERGE0_ASYNC_SOUT
+	}, {
+		DDP_COMPONENT_MERGE2, DDP_COMPONENT_ETHDR_MIXER,
+		MT8188_VDO1_MIXER_IN2_SEL_IN, GENMASK(0, 0),
+		MT8188_MIXER_IN2_SEL_IN_FROM_MERGE1_ASYNC_SOUT
+	}, {
+		DDP_COMPONENT_MERGE3, DDP_COMPONENT_ETHDR_MIXER,
+		MT8188_VDO1_MIXER_IN3_SEL_IN, GENMASK(0, 0),
+		MT8188_MIXER_IN3_SEL_IN_FROM_MERGE2_ASYNC_SOUT
+	}, {
+		DDP_COMPONENT_MERGE4, DDP_COMPONENT_ETHDR_MIXER,
+		MT8188_VDO1_MIXER_IN4_SEL_IN, GENMASK(0, 0),
+		MT8188_MIXER_IN4_SEL_IN_FROM_MERGE3_ASYNC_SOUT
+	}, {
+		DDP_COMPONENT_ETHDR_MIXER, DDP_COMPONENT_MERGE5,
+		MT8188_VDO1_MIXER_SOUT_SEL_IN, GENMASK(2, 0),
+		MT8188_MIXER_SOUT_SEL_IN_FROM_DISP_MIXER
+	}, {
+		DDP_COMPONENT_ETHDR_MIXER, DDP_COMPONENT_MERGE5,
+		MT8188_VDO1_MERGE4_ASYNC_SEL_IN, GENMASK(2, 0),
+		MT8188_MERGE4_ASYNC_SEL_IN_FROM_MIXER_OUT_SOUT
+	}, {
+		DDP_COMPONENT_MERGE5, DDP_COMPONENT_DPI1,
+		MT8188_VDO1_DISP_DPI1_SEL_IN, GENMASK(1, 0),
+		MT8188_DISP_DPI1_SEL_IN_FROM_VPP_MERGE4_MOUT
+	}, {
+		DDP_COMPONENT_MERGE5, DDP_COMPONENT_DPI1,
+		MT8188_VDO1_MERGE4_SOUT_SEL, GENMASK(1, 0),
+		MT8188_MERGE4_SOUT_TO_DPI1_SEL
+	}, {
+		DDP_COMPONENT_MERGE5, DDP_COMPONENT_DP_INTF1,
+		MT8188_VDO1_DISP_DP_INTF0_SEL_IN, GENMASK(1, 0),
+		MT8188_DISP_DP_INTF0_SEL_IN_FROM_VPP_MERGE4_MOUT
+	}, {
+		DDP_COMPONENT_MERGE5, DDP_COMPONENT_DP_INTF1,
+		MT8188_VDO1_MERGE4_SOUT_SEL, GENMASK(3, 0),
+		MT8188_MERGE4_SOUT_TO_DP_INTF0_SEL
+	}
+};
+
 #endif /* __SOC_MEDIATEK_MT8188_MMSYS_H */
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 88209102ff3b..1b160fcc1d27 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -89,6 +89,14 @@ static const struct mtk_mmsys_driver_data mt8188_vdosys0_driver_data = {
 	.num_routes = ARRAY_SIZE(mmsys_mt8188_routing_table),
 };
 
+static const struct mtk_mmsys_driver_data mt8188_vdosys1_driver_data = {
+	.clk_driver = "clk-mt8188-vdo1",
+	.routes = mmsys_mt8188_vdo1_routing_table,
+	.num_routes = ARRAY_SIZE(mmsys_mt8188_vdo1_routing_table),
+	.num_resets = 96,
+	.vsync_len = 1,
+};
+
 static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
 	.clk_driver = "clk-mt8192-mm",
 	.routes = mmsys_mt8192_routing_table,
@@ -169,6 +177,10 @@ void mtk_mmsys_ddp_connect(struct device *dev,
 		if (cur == routes[i].from_comp && next == routes[i].to_comp)
 			mtk_mmsys_update_bits(mmsys, routes[i].addr, routes[i].mask,
 					      routes[i].val, NULL);
+
+	if (mmsys->data->vsync_len)
+		mtk_mmsys_update_bits(mmsys, MT8188_VDO1_MIXER_VSYNC_LEN, GENMASK(31, 0),
+				      mmsys->data->vsync_len, NULL);
 }
 EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_connect);
 
@@ -429,6 +441,7 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
 	{ .compatible = "mediatek,mt8183-mmsys", .data = &mt8183_mmsys_driver_data },
 	{ .compatible = "mediatek,mt8186-mmsys", .data = &mt8186_mmsys_driver_data },
 	{ .compatible = "mediatek,mt8188-vdosys0", .data = &mt8188_vdosys0_driver_data },
+	{ .compatible = "mediatek,mt8188-vdosys1", .data = &mt8188_vdosys1_driver_data },
 	{ .compatible = "mediatek,mt8192-mmsys", .data = &mt8192_mmsys_driver_data },
 	/* "mediatek,mt8195-mmsys" compatible is deprecated */
 	{ .compatible = "mediatek,mt8195-mmsys", .data = &mt8195_vdosys0_driver_data },
diff --git a/drivers/soc/mediatek/mtk-mmsys.h b/drivers/soc/mediatek/mtk-mmsys.h
index 6725403d2e3a..9d8507f98b7a 100644
--- a/drivers/soc/mediatek/mtk-mmsys.h
+++ b/drivers/soc/mediatek/mtk-mmsys.h
@@ -86,6 +86,34 @@ struct mtk_mmsys_routes {
 	u32 val;
 };
 
+/**
+ * struct mtk_mmsys_driver_data - Settings of the mmsys
+ * @clk_driver: Clock driver name that the mmsys is using
+ *              (defined in drivers/clk/mediatek/clk-*.c).
+ * @routes: Routing table of the mmsys.
+ *          It provides mux settings from one module to another.
+ * @num_routes: Array size of the routes.
+ * @sw0_rst_offset: Register offset for the reset control.
+ * @num_resets: Number of reset bits that are defined
+ * @is_vppsys: Whether the mmsys is VPPSYS (Video Processing Pipe)
+ *             or VDOSYS (Video). Only VDOSYS needs to be added to drm driver.
+ * @vsync_len: VSYNC length of the MIXER.
+ *             VSYNC is usually triggered by the connector, so its length is a
+ *             fixed value when the frame rate is decided, but ETHDR and
+ *             MIXER generate their own VSYNC due to hardware design, therefore
+ *             MIXER has to sync with ETHDR by adjusting VSYNC length.
+ *             On MT8195, there is no such setting so we use the gap between
+ *             falling edge and rising edge of SOF (Start of Frame) signal to
+ *             do the job, but since MT8188, VSYNC_LEN setting is introduced to
+ *             solve the problem and is given 0x40 (ticks) as the default value.
+ *             Please notice that this value has to be set to 1 (minimum) if
+ *             ETHDR is bypassed, otherwise MIXER could wait too long and causing
+ *             underflow.
+ *
+ * Each MMSYS (multi-media system) may have different settings, they may use
+ * different clock sources, mux settings, reset control ...etc., and these
+ * differences are all stored here.
+ */
 struct mtk_mmsys_driver_data {
 	const char *clk_driver;
 	const struct mtk_mmsys_routes *routes;
@@ -93,6 +121,7 @@ struct mtk_mmsys_driver_data {
 	const u16 sw0_rst_offset;
 	const u32 num_resets;
 	const bool is_vppsys;
+	const u8 vsync_len;
 };
 
 /*
diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index 9d9f5ae578ac..e76722289175 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -133,6 +133,22 @@
 #define MT8188_MUTEX_MOD_DISP_POSTMASK0		24
 #define MT8188_MUTEX_MOD2_DISP_PWM0		33
 
+#define MT8188_MUTEX_MOD_DISP1_MDP_RDMA0	0
+#define MT8188_MUTEX_MOD_DISP1_MDP_RDMA1	1
+#define MT8188_MUTEX_MOD_DISP1_MDP_RDMA2	2
+#define MT8188_MUTEX_MOD_DISP1_MDP_RDMA3	3
+#define MT8188_MUTEX_MOD_DISP1_MDP_RDMA4	4
+#define MT8188_MUTEX_MOD_DISP1_MDP_RDMA5	5
+#define MT8188_MUTEX_MOD_DISP1_MDP_RDMA6	6
+#define MT8188_MUTEX_MOD_DISP1_MDP_RDMA7	7
+#define MT8188_MUTEX_MOD_DISP1_VPP_MERGE0	20
+#define MT8188_MUTEX_MOD_DISP1_VPP_MERGE1	21
+#define MT8188_MUTEX_MOD_DISP1_VPP_MERGE2	22
+#define MT8188_MUTEX_MOD_DISP1_VPP_MERGE3	23
+#define MT8188_MUTEX_MOD_DISP1_VPP_MERGE4	24
+#define MT8188_MUTEX_MOD_DISP1_DISP_MIXER	30
+#define MT8188_MUTEX_MOD_DISP1_DP_INTF1		39
+
 #define MT8195_MUTEX_MOD_DISP_OVL0		0
 #define MT8195_MUTEX_MOD_DISP_WDMA0		1
 #define MT8195_MUTEX_MOD_DISP_RDMA0		2
@@ -264,6 +280,7 @@
 #define MT8183_MUTEX_SOF_DPI0			2
 #define MT8188_MUTEX_SOF_DSI0			1
 #define MT8188_MUTEX_SOF_DP_INTF0		3
+#define MT8188_MUTEX_SOF_DP_INTF1		4
 #define MT8195_MUTEX_SOF_DSI0			1
 #define MT8195_MUTEX_SOF_DSI1			2
 #define MT8195_MUTEX_SOF_DP_INTF0		3
@@ -275,6 +292,7 @@
 #define MT8183_MUTEX_EOF_DPI0			(MT8183_MUTEX_SOF_DPI0 << 6)
 #define MT8188_MUTEX_EOF_DSI0			(MT8188_MUTEX_SOF_DSI0 << 7)
 #define MT8188_MUTEX_EOF_DP_INTF0		(MT8188_MUTEX_SOF_DP_INTF0 << 7)
+#define MT8188_MUTEX_EOF_DP_INTF1		(MT8188_MUTEX_SOF_DP_INTF1 << 7)
 #define MT8195_MUTEX_EOF_DSI0			(MT8195_MUTEX_SOF_DSI0 << 7)
 #define MT8195_MUTEX_EOF_DSI1			(MT8195_MUTEX_SOF_DSI1 << 7)
 #define MT8195_MUTEX_EOF_DP_INTF0		(MT8195_MUTEX_SOF_DP_INTF0 << 7)
@@ -445,6 +463,21 @@ static const unsigned int mt8188_mutex_mod[DDP_COMPONENT_ID_MAX] = {
 	[DDP_COMPONENT_DSI0] = MT8188_MUTEX_MOD_DISP_DSI0,
 	[DDP_COMPONENT_PWM0] = MT8188_MUTEX_MOD2_DISP_PWM0,
 	[DDP_COMPONENT_DP_INTF0] = MT8188_MUTEX_MOD_DISP_DP_INTF0,
+	[DDP_COMPONENT_DP_INTF1] = MT8188_MUTEX_MOD_DISP1_DP_INTF1,
+	[DDP_COMPONENT_ETHDR_MIXER] = MT8188_MUTEX_MOD_DISP1_DISP_MIXER,
+	[DDP_COMPONENT_MDP_RDMA0] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA0,
+	[DDP_COMPONENT_MDP_RDMA1] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA1,
+	[DDP_COMPONENT_MDP_RDMA2] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA2,
+	[DDP_COMPONENT_MDP_RDMA3] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA3,
+	[DDP_COMPONENT_MDP_RDMA4] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA4,
+	[DDP_COMPONENT_MDP_RDMA5] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA5,
+	[DDP_COMPONENT_MDP_RDMA6] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA6,
+	[DDP_COMPONENT_MDP_RDMA7] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA7,
+	[DDP_COMPONENT_MERGE1] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE0,
+	[DDP_COMPONENT_MERGE2] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE1,
+	[DDP_COMPONENT_MERGE3] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE2,
+	[DDP_COMPONENT_MERGE4] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE3,
+	[DDP_COMPONENT_MERGE5] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE4,
 };
 
 static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
@@ -605,6 +638,8 @@ static const unsigned int mt8188_mutex_sof[DDP_MUTEX_SOF_MAX] = {
 		MT8188_MUTEX_SOF_DSI0 | MT8188_MUTEX_EOF_DSI0,
 	[MUTEX_SOF_DP_INTF0] =
 		MT8188_MUTEX_SOF_DP_INTF0 | MT8188_MUTEX_EOF_DP_INTF0,
+	[MUTEX_SOF_DP_INTF1] =
+		MT8188_MUTEX_SOF_DP_INTF1 | MT8188_MUTEX_EOF_DP_INTF1,
 };
 
 static const unsigned int mt8195_mutex_sof[DDP_MUTEX_SOF_MAX] = {
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:41 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:41 +0800
Subject: [PATCH v12 17/23] drm/mediatek: Refine device table of OVL adaptor
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-18-shawn.sung@mediatek.com>

- Adjust indentation to align with other files
- Sort device table in alphabetical order
- Add sentinel to device table

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 30f2475d1c0b..92eeb1005ec3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -437,17 +437,10 @@ static int ovl_adaptor_comp_get_id(struct device *dev, struct device_node *node,
 }
 
 static const struct of_device_id mtk_ovl_adaptor_comp_dt_ids[] = {
-	{
-		.compatible = "mediatek,mt8195-vdo1-rdma",
-		.data = (void *)OVL_ADAPTOR_TYPE_MDP_RDMA,
-	}, {
-		.compatible = "mediatek,mt8195-disp-merge",
-		.data = (void *)OVL_ADAPTOR_TYPE_MERGE,
-	}, {
-		.compatible = "mediatek,mt8195-disp-ethdr",
-		.data = (void *)OVL_ADAPTOR_TYPE_ETHDR,
-	},
-	{},
+	{ .compatible = "mediatek,mt8195-disp-ethdr", .data = (void *)OVL_ADAPTOR_TYPE_ETHDR },
+	{ .compatible = "mediatek,mt8195-disp-merge", .data = (void *)OVL_ADAPTOR_TYPE_MERGE },
+	{ .compatible = "mediatek,mt8195-vdo1-rdma", .data = (void *)OVL_ADAPTOR_TYPE_MDP_RDMA },
+	{ /* sentinel */ }
 };
 
 static int compare_of(struct device *dev, void *data)
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:40 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:40 +0800
Subject: [PATCH v12 16/23] drm/mediatek: Sort OVL adaptor components
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-17-shawn.sung@mediatek.com>

Sort OVL adaptor components' names in alphabetical order.

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 65c5153bdcd8..30f2475d1c0b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -27,13 +27,14 @@
 #define MTK_OVL_ADAPTOR_LAYER_NUM 4
 
 enum mtk_ovl_adaptor_comp_type {
-	OVL_ADAPTOR_TYPE_MDP_RDMA = 0,
-	OVL_ADAPTOR_TYPE_MERGE,
 	OVL_ADAPTOR_TYPE_ETHDR,
+	OVL_ADAPTOR_TYPE_MDP_RDMA,
+	OVL_ADAPTOR_TYPE_MERGE,
 	OVL_ADAPTOR_TYPE_NUM,
 };
 
 enum mtk_ovl_adaptor_comp_id {
+	OVL_ADAPTOR_ETHDR0,
 	OVL_ADAPTOR_MDP_RDMA0,
 	OVL_ADAPTOR_MDP_RDMA1,
 	OVL_ADAPTOR_MDP_RDMA2,
@@ -46,7 +47,6 @@ enum mtk_ovl_adaptor_comp_id {
 	OVL_ADAPTOR_MERGE1,
 	OVL_ADAPTOR_MERGE2,
 	OVL_ADAPTOR_MERGE3,
-	OVL_ADAPTOR_ETHDR0,
 	OVL_ADAPTOR_ID_MAX
 };
 
@@ -64,9 +64,9 @@ struct mtk_disp_ovl_adaptor {
 };
 
 static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
+	[OVL_ADAPTOR_TYPE_ETHDR]	= "ethdr",
 	[OVL_ADAPTOR_TYPE_MDP_RDMA]	= "vdo1-rdma",
 	[OVL_ADAPTOR_TYPE_MERGE]	= "merge",
-	[OVL_ADAPTOR_TYPE_ETHDR]	= "ethdr",
 };
 
 static const struct mtk_ddp_comp_funcs ethdr = {
@@ -89,6 +89,7 @@ static const struct mtk_ddp_comp_funcs rdma = {
 };
 
 static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
+	[OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, DDP_COMPONENT_ETHDR_MIXER, 0, &ethdr },
 	[OVL_ADAPTOR_MDP_RDMA0] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA0, 0, &rdma },
 	[OVL_ADAPTOR_MDP_RDMA1] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA1, 1, &rdma },
 	[OVL_ADAPTOR_MDP_RDMA2] = { OVL_ADAPTOR_TYPE_MDP_RDMA, DDP_COMPONENT_MDP_RDMA2, 2, &rdma },
@@ -101,7 +102,6 @@ static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
 	[OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 2, &merge },
 	[OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 3, &merge },
 	[OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 4, &merge },
-	[OVL_ADAPTOR_ETHDR0] = { OVL_ADAPTOR_TYPE_ETHDR, DDP_COMPONENT_ETHDR_MIXER, 0, &ethdr },
 };
 
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
@@ -399,6 +399,7 @@ void mtk_ovl_adaptor_remove_comp(struct device *dev, struct mtk_mutex *mutex)
 
 void mtk_ovl_adaptor_connect(struct device *dev, struct device *mmsys_dev, unsigned int next)
 {
+	mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_ETHDR_MIXER, next);
 	mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MDP_RDMA0, DDP_COMPONENT_MERGE1);
 	mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MDP_RDMA1, DDP_COMPONENT_MERGE1);
 	mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MDP_RDMA2, DDP_COMPONENT_MERGE2);
@@ -406,11 +407,11 @@ void mtk_ovl_adaptor_connect(struct device *dev, struct device *mmsys_dev, unsig
 	mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MERGE2, DDP_COMPONENT_ETHDR_MIXER);
 	mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MERGE3, DDP_COMPONENT_ETHDR_MIXER);
 	mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_MERGE4, DDP_COMPONENT_ETHDR_MIXER);
-	mtk_mmsys_ddp_connect(mmsys_dev, DDP_COMPONENT_ETHDR_MIXER, next);
 }
 
 void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev, unsigned int next)
 {
+	mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_ETHDR_MIXER, next);
 	mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MDP_RDMA0, DDP_COMPONENT_MERGE1);
 	mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MDP_RDMA1, DDP_COMPONENT_MERGE1);
 	mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MDP_RDMA2, DDP_COMPONENT_MERGE2);
@@ -418,7 +419,6 @@ void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev, un
 	mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MERGE2, DDP_COMPONENT_ETHDR_MIXER);
 	mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MERGE3, DDP_COMPONENT_ETHDR_MIXER);
 	mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_MERGE4, DDP_COMPONENT_ETHDR_MIXER);
-	mtk_mmsys_ddp_disconnect(mmsys_dev, DDP_COMPONENT_ETHDR_MIXER, next);
 }
 
 static int ovl_adaptor_comp_get_id(struct device *dev, struct device_node *node,
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:39 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:39 +0800
Subject: [PATCH v12 15/23] drm/mediatek: Start/Stop components with function pointers
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-16-shawn.sung@mediatek.com>

By registering component related functions to the pointers,
we can easily manage them within a for-loop and simplify the
logic of component start/stop process.

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 20 +++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index e00d8a395ca0..65c5153bdcd8 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -72,6 +72,8 @@ static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
 static const struct mtk_ddp_comp_funcs ethdr = {
 	.clk_enable = mtk_ethdr_clk_enable,
 	.clk_disable = mtk_ethdr_clk_disable,
+	.start = mtk_ethdr_start,
+	.stop = mtk_ethdr_stop,
 };
 
 static const struct mtk_ddp_comp_funcs merge = {
@@ -191,16 +193,30 @@ void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
 
 void mtk_ovl_adaptor_start(struct device *dev)
 {
+	int i;
 	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
 
-	mtk_ethdr_start(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+	for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+		if (!ovl_adaptor->ovl_adaptor_comp[i] ||
+		    !comp_matches[i].funcs->start)
+			continue;
+
+		comp_matches[i].funcs->start(ovl_adaptor->ovl_adaptor_comp[i]);
+	}
 }
 
 void mtk_ovl_adaptor_stop(struct device *dev)
 {
+	int i;
 	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
 
-	mtk_ethdr_stop(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+	for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+		if (!ovl_adaptor->ovl_adaptor_comp[i] ||
+		    !comp_matches[i].funcs->stop)
+			continue;
+
+		comp_matches[i].funcs->stop(ovl_adaptor->ovl_adaptor_comp[i]);
+	}
 }
 
 /**
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:42 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:42 +0800
Subject: [PATCH v12 18/23] drm/mediatek: Support MT8188 Padding in display driver
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-19-shawn.sung@mediatek.com>

Padding is a new display module on MT8188, it provides ability
to add pixels to width and height of a layer with specified colors.

Due to hardware design, Mixer in VDOSYS1 requires width of a layer
to be 2-pixel-align, or 4-pixel-align when ETHDR is enabled,
we need Padding to deal with odd width.

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/Makefile       |   3 +-
 drivers/gpu/drm/mediatek/mtk_disp_drv.h |   4 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   2 +-
 drivers/gpu/drm/mediatek/mtk_padding.c  | 160 ++++++++++++++++++++++++
 5 files changed, 168 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_padding.c

diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
index d4d193f60271..5e4436403b8d 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -16,7 +16,8 @@ mediatek-drm-y := mtk_disp_aal.o \
 		  mtk_dsi.o \
 		  mtk_dpi.o \
 		  mtk_ethdr.o \
-		  mtk_mdp_rdma.o
+		  mtk_mdp_rdma.o \
+		  mtk_padding.o
 
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
 
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 2d426775b7ea..74fa56339383 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -164,4 +164,8 @@ void mtk_mdp_rdma_config(struct device *dev, struct mtk_mdp_rdma_cfg *cfg,
 const u32 *mtk_mdp_rdma_get_formats(struct device *dev);
 size_t mtk_mdp_rdma_get_num_formats(struct device *dev);
 
+int mtk_padding_clk_enable(struct device *dev);
+void mtk_padding_clk_disable(struct device *dev);
+void mtk_padding_start(struct device *dev);
+void mtk_padding_stop(struct device *dev);
 #endif
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 48581da51857..f7504d1edc62 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -996,6 +996,7 @@ static struct platform_driver * const mtk_drm_drivers[] = {
 	&mtk_dsi_driver,
 	&mtk_ethdr_driver,
 	&mtk_mdp_rdma_driver,
+	&mtk_padding_driver,
 };
 
 static int __init mtk_drm_init(void)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 6f98fff4f1a4..33fadb08dc1c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -77,5 +77,5 @@ extern struct platform_driver mtk_dpi_driver;
 extern struct platform_driver mtk_dsi_driver;
 extern struct platform_driver mtk_ethdr_driver;
 extern struct platform_driver mtk_mdp_rdma_driver;
-
+extern struct platform_driver mtk_padding_driver;
 #endif /* MTK_DRM_DRV_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_padding.c b/drivers/gpu/drm/mediatek/mtk_padding.c
new file mode 100644
index 000000000000..0d6451c149b6
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_padding.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/soc/mediatek/mtk-cmdq.h>
+
+#include "mtk_disp_drv.h"
+#include "mtk_drm_crtc.h"
+#include "mtk_drm_ddp_comp.h"
+
+#define PADDING_CONTROL_REG	0x00
+#define PADDING_BYPASS			BIT(0)
+#define PADDING_ENABLE			BIT(1)
+#define PADDING_PIC_SIZE_REG	0x04
+#define PADDING_H_REG		0x08 /* horizontal */
+#define PADDING_V_REG		0x0c /* vertical */
+#define PADDING_COLOR_REG	0x10
+
+/**
+ * struct mtk_padding - Basic information of the Padding
+ * @clk: Clock of the module
+ * @reg: Virtual address of the Padding for CPU to access
+ * @cmdq_reg: CMDQ setting of the Padding
+ *
+ * Every Padding should have different clock source, register base, and
+ * CMDQ settings, we stored these differences all together.
+ */
+struct mtk_padding {
+	struct clk		*clk;
+	void __iomem		*reg;
+	struct cmdq_client_reg	cmdq_reg;
+};
+
+int mtk_padding_clk_enable(struct device *dev)
+{
+	struct mtk_padding *padding = dev_get_drvdata(dev);
+
+	return clk_prepare_enable(padding->clk);
+}
+
+void mtk_padding_clk_disable(struct device *dev)
+{
+	struct mtk_padding *padding = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(padding->clk);
+}
+
+void mtk_padding_start(struct device *dev)
+{
+	struct mtk_padding *padding = dev_get_drvdata(dev);
+
+	writel(PADDING_ENABLE | PADDING_BYPASS,
+	       padding->reg + PADDING_CONTROL_REG);
+
+	/*
+	 * Notice that even the padding is in bypass mode,
+	 * all the settings must be cleared to 0 or
+	 * undefined behaviors could happen
+	 */
+	writel(0, padding->reg + PADDING_PIC_SIZE_REG);
+	writel(0, padding->reg + PADDING_H_REG);
+	writel(0, padding->reg + PADDING_V_REG);
+	writel(0, padding->reg + PADDING_COLOR_REG);
+}
+
+void mtk_padding_stop(struct device *dev)
+{
+	struct mtk_padding *padding = dev_get_drvdata(dev);
+
+	writel(0, padding->reg + PADDING_CONTROL_REG);
+}
+
+static int mtk_padding_bind(struct device *dev, struct device *master, void *data)
+{
+	return 0;
+}
+
+static void mtk_padding_unbind(struct device *dev, struct device *master, void *data)
+{
+}
+
+static const struct component_ops mtk_padding_component_ops = {
+	.bind	= mtk_padding_bind,
+	.unbind = mtk_padding_unbind,
+};
+
+static int mtk_padding_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_padding *priv;
+	struct resource *res;
+	int ret;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(priv->clk)) {
+		dev_err(dev, "failed to get clk\n");
+		return PTR_ERR(priv->clk);
+	}
+
+	priv->reg = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(priv->reg)) {
+		dev_err(dev, "failed to do ioremap\n");
+		return PTR_ERR(priv->reg);
+	}
+
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	ret = cmdq_dev_get_client_reg(dev, &priv->cmdq_reg, 0);
+	if (ret) {
+		dev_err(dev, "failed to get gce client reg\n");
+		return ret;
+	}
+#endif
+
+	platform_set_drvdata(pdev, priv);
+
+	ret = devm_pm_runtime_enable(dev);
+	if (ret)
+		return ret;
+
+	ret = component_add(dev, &mtk_padding_component_ops);
+	if (ret) {
+		pm_runtime_disable(dev);
+		return dev_err_probe(dev, ret, "failed to add component\n");
+	}
+
+	return 0;
+}
+
+static int mtk_padding_remove(struct platform_device *pdev)
+{
+	component_del(&pdev->dev, &mtk_padding_component_ops);
+	return 0;
+}
+
+static const struct of_device_id mtk_padding_driver_dt_match[] = {
+	{ .compatible = "mediatek,mt8188-disp-padding" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mtk_padding_driver_dt_match);
+
+struct platform_driver mtk_padding_driver = {
+	.probe		= mtk_padding_probe,
+	.remove		= mtk_padding_remove,
+	.driver		= {
+		.name	= "mediatek-disp-padding",
+		.owner	= THIS_MODULE,
+		.of_match_table = mtk_padding_driver_dt_match,
+	},
+};
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:47 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:47 +0800
Subject: [PATCH v12 23/23] drm/mediatek: Support MT8188 VDOSYS1 in display driver
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-24-shawn.sung@mediatek.com>

- The mmsys_dev_num in MT8188 VDOSYS0 was set to 1 since
  VDOSYS1 was not available before. Increase it to support
  VDOSYS1 in display driver.
- Add compatible name for MT8188 VDOSYS1
  (shares the same driver data with MT8195 VDOSYS1)

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index f7504d1edc62..8cbbf55a6454 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -293,7 +293,7 @@ static const struct mtk_mmsys_driver_data mt8188_vdosys0_driver_data = {
 	.main_len = ARRAY_SIZE(mt8188_mtk_ddp_main),
 	.conn_routes = mt8188_mtk_ddp_main_routes,
 	.num_conn_routes = ARRAY_SIZE(mt8188_mtk_ddp_main_routes),
-	.mmsys_dev_num = 1,
+	.mmsys_dev_num = 2,
 };
 
 static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
@@ -334,6 +334,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
 	  .data = &mt8186_mmsys_driver_data},
 	{ .compatible = "mediatek,mt8188-vdosys0",
 	  .data = &mt8188_vdosys0_driver_data},
+	{ .compatible = "mediatek,mt8188-vdosys1",
+	  .data = &mt8195_vdosys1_driver_data},
 	{ .compatible = "mediatek,mt8192-mmsys",
 	  .data = &mt8192_mmsys_driver_data},
 	{ .compatible = "mediatek,mt8195-mmsys",
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:38 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:38 +0800
Subject: [PATCH v12 14/23] drm/mediatek: Power on/off devices with function pointers
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-15-shawn.sung@mediatek.com>

Different from OVL, OVL adaptor is a pseudo device so we didn't
define it in the device tree, consequently, pm_runtime_resume_and_get()
called by .atomic_enable() powers on no device. For this reason, we
implement a function to power on the RDMAs in OVL adaptor, and the
system will make sure the IOMMUs are powered on as well because of the
device link (iommus) in the RDMA nodes in DTS.

This patch separates power and clock management process, it would be
easier to maintain and add extensions.

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h       |  4 +
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 75 +++++++++++++++----
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c       | 10 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |  2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   | 20 +++++
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c       | 16 ++++
 6 files changed, 107 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 1311562d25cc..2d426775b7ea 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -110,6 +110,8 @@ void mtk_ovl_adaptor_connect(struct device *dev, struct device *mmsys_dev,
 			     unsigned int next);
 void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev,
 				unsigned int next);
+int mtk_ovl_adaptor_power_on(struct device *dev);
+void mtk_ovl_adaptor_power_off(struct device *dev);
 int mtk_ovl_adaptor_clk_enable(struct device *dev);
 void mtk_ovl_adaptor_clk_disable(struct device *dev);
 void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
@@ -151,6 +153,8 @@ void mtk_rdma_disable_vblank(struct device *dev);
 const u32 *mtk_rdma_get_formats(struct device *dev);
 size_t mtk_rdma_get_num_formats(struct device *dev);
 
+int mtk_mdp_rdma_power_on(struct device *dev);
+void mtk_mdp_rdma_power_off(struct device *dev);
 int mtk_mdp_rdma_clk_enable(struct device *dev);
 void mtk_mdp_rdma_clk_disable(struct device *dev);
 void mtk_mdp_rdma_start(struct device *dev, struct cmdq_pkt *cmdq_pkt);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index a815dc8e2110..e00d8a395ca0 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -80,6 +80,8 @@ static const struct mtk_ddp_comp_funcs merge = {
 };
 
 static const struct mtk_ddp_comp_funcs rdma = {
+	.power_on = mtk_mdp_rdma_power_on,
+	.power_off = mtk_mdp_rdma_power_off,
 	.clk_enable = mtk_mdp_rdma_clk_enable,
 	.clk_disable = mtk_mdp_rdma_clk_disable,
 };
@@ -201,21 +203,72 @@ void mtk_ovl_adaptor_stop(struct device *dev)
 	mtk_ethdr_stop(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
 }
 
-int mtk_ovl_adaptor_clk_enable(struct device *dev)
+/**
+ * power_off - Power off the devices in OVL adaptor
+ * @dev: Device to be powered off
+ * @num: Number of the devices to be powered off
+ *
+ * Calls the .power_off() ovl_adaptor component callback if it is present.
+ */
+static inline void power_off(struct device *dev, int num)
 {
 	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
-	struct device *comp;
-	int ret;
 	int i;
 
-	for (i = 0; i < OVL_ADAPTOR_MERGE0; i++) {
-		comp = ovl_adaptor->ovl_adaptor_comp[i];
-		ret = pm_runtime_get_sync(comp);
+	if (num > OVL_ADAPTOR_ID_MAX)
+		num = OVL_ADAPTOR_ID_MAX;
+
+	for (i = num - 1; i >= 0; i--) {
+		if (!ovl_adaptor->ovl_adaptor_comp[i] ||
+		    !comp_matches[i].funcs->power_off)
+			continue;
+
+		comp_matches[i].funcs->power_off(ovl_adaptor->ovl_adaptor_comp[i]);
+	}
+}
+
+/**
+ * mtk_ovl_adaptor_power_on - Power on the devices in OVL adaptor
+ * @dev: Device to be powered on
+ *
+ * Different from OVL, OVL adaptor is a pseudo device so
+ * we didn't define it in the device tree, pm_runtime_resume_and_get()
+ * called by .atomic_enable() power on no device in OVL adaptor,
+ * we have to implement a function to do the job instead.
+ *
+ * Return: Zero for success or negative number for failure.
+ */
+int mtk_ovl_adaptor_power_on(struct device *dev)
+{
+	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+	int i, ret;
+
+	for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+		if (!ovl_adaptor->ovl_adaptor_comp[i] ||
+		    !comp_matches[i].funcs->power_on)
+			continue;
+
+		ret = comp_matches[i].funcs->power_on(ovl_adaptor->ovl_adaptor_comp[i]);
 		if (ret < 0) {
 			dev_err(dev, "Failed to enable power domain %d, err %d\n", i, ret);
-			goto error;
+			power_off(dev, i);
+			return ret;
 		}
 	}
+	return 0;
+}
+
+void mtk_ovl_adaptor_power_off(struct device *dev)
+{
+	power_off(dev, OVL_ADAPTOR_ID_MAX);
+}
+
+int mtk_ovl_adaptor_clk_enable(struct device *dev)
+{
+	struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+	struct device *comp;
+	int ret;
+	int i;
 
 	for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
 		comp = ovl_adaptor->ovl_adaptor_comp[i];
@@ -226,16 +279,10 @@ int mtk_ovl_adaptor_clk_enable(struct device *dev)
 			dev_err(dev, "Failed to enable clock %d, err %d\n", i, ret);
 			while (--i >= 0)
 				comp_matches[i].funcs->clk_disable(comp);
-			i = OVL_ADAPTOR_MERGE0;
-			goto error;
+			return ret;
 		}
 	}
 	return 0;
-error:
-	while (--i >= 0)
-		pm_runtime_put(ovl_adaptor->ovl_adaptor_comp[i]);
-
-	return ret;
 }
 
 void mtk_ovl_adaptor_clk_disable(struct device *dev)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index c277b9fae950..4d5ff39dc2ef 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -721,7 +721,7 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
 
 	DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
 
-	ret = pm_runtime_resume_and_get(comp->dev);
+	ret = mtk_ddp_comp_power_on(comp);
 	if (ret < 0) {
 		DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n", ret);
 		return;
@@ -731,7 +731,7 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
 
 	ret = mtk_crtc_ddp_hw_init(mtk_crtc);
 	if (ret) {
-		pm_runtime_put(comp->dev);
+		mtk_ddp_comp_power_off(comp);
 		return;
 	}
 
@@ -744,7 +744,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
 {
 	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
 	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
-	int i, ret;
+	int i;
 
 	DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
 	if (!mtk_crtc->enabled)
@@ -774,9 +774,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
 
 	drm_crtc_vblank_off(crtc);
 	mtk_crtc_ddp_hw_fini(mtk_crtc);
-	ret = pm_runtime_put(comp->dev);
-	if (ret < 0)
-		DRM_DEV_ERROR(comp->dev, "Failed to disable power domain: %d\n", ret);
+	mtk_ddp_comp_power_off(comp);
 
 	mtk_crtc->enabled = false;
 }
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3046c0409353..a9b5a21cde2d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -398,6 +398,8 @@ static const struct mtk_ddp_comp_funcs ddp_ufoe = {
 };
 
 static const struct mtk_ddp_comp_funcs ddp_ovl_adaptor = {
+	.power_on = mtk_ovl_adaptor_power_on,
+	.power_off = mtk_ovl_adaptor_power_off,
 	.clk_enable = mtk_ovl_adaptor_clk_enable,
 	.clk_disable = mtk_ovl_adaptor_clk_disable,
 	.config = mtk_ovl_adaptor_config,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 4bae55bdb034..15b2eafff438 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -7,6 +7,7 @@
 #define MTK_DRM_DDP_COMP_H
 
 #include <linux/io.h>
+#include <linux/pm_runtime.h>
 #include <linux/soc/mediatek/mtk-cmdq.h>
 #include <linux/soc/mediatek/mtk-mmsys.h>
 #include <linux/soc/mediatek/mtk-mutex.h>
@@ -46,6 +47,8 @@ enum mtk_ddp_comp_type {
 struct mtk_ddp_comp;
 struct cmdq_pkt;
 struct mtk_ddp_comp_funcs {
+	int (*power_on)(struct device *dev);
+	void (*power_off)(struct device *dev);
 	int (*clk_enable)(struct device *dev);
 	void (*clk_disable)(struct device *dev);
 	void (*config)(struct device *dev, unsigned int w,
@@ -92,6 +95,23 @@ struct mtk_ddp_comp {
 	const struct mtk_ddp_comp_funcs *funcs;
 };
 
+static inline int mtk_ddp_comp_power_on(struct mtk_ddp_comp *comp)
+{
+	if (comp->funcs && comp->funcs->power_on)
+		return comp->funcs->power_on(comp->dev);
+	else
+		return pm_runtime_resume_and_get(comp->dev);
+	return 0;
+}
+
+static inline void mtk_ddp_comp_power_off(struct mtk_ddp_comp *comp)
+{
+	if (comp->funcs && comp->funcs->power_off)
+		comp->funcs->power_off(comp->dev);
+	else
+		pm_runtime_put(comp->dev);
+}
+
 static inline int mtk_ddp_comp_clk_enable(struct mtk_ddp_comp *comp)
 {
 	if (comp->funcs && comp->funcs->clk_enable)
diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
index c3adaeefd551..dc7c9e991990 100644
--- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
@@ -242,6 +242,22 @@ size_t mtk_mdp_rdma_get_num_formats(struct device *dev)
 	return ARRAY_SIZE(formats);
 }
 
+int mtk_mdp_rdma_power_on(struct device *dev)
+{
+	int ret = pm_runtime_resume_and_get(dev);
+
+	if (ret < 0) {
+		dev_err(dev, "Failed to power on: %d\n", ret);
+		return ret;
+	}
+	return 0;
+}
+
+void mtk_mdp_rdma_power_off(struct device *dev)
+{
+	pm_runtime_put(dev);
+}
+
 int mtk_mdp_rdma_clk_enable(struct device *dev)
 {
 	struct mtk_mdp_rdma *rdma = dev_get_drvdata(dev);
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:35 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:35 +0800
Subject: [PATCH v12 11/23] drm/mediatek: Rename OVL_ADAPTOR_TYPE_RDMA
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-12-shawn.sung@mediatek.com>

Rename OVL_ADAPTOR_TYPE_RDMA to OVL_ADAPTOR_TYPE_MDP_RDMA
to align the naming rule of mtk_ovl_adaptor_comp_id.

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 6bf6367853fb..114eded8177e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -27,7 +27,7 @@
 #define MTK_OVL_ADAPTOR_LAYER_NUM 4
 
 enum mtk_ovl_adaptor_comp_type {
-	OVL_ADAPTOR_TYPE_RDMA = 0,
+	OVL_ADAPTOR_TYPE_MDP_RDMA = 0,
 	OVL_ADAPTOR_TYPE_MERGE,
 	OVL_ADAPTOR_TYPE_ETHDR,
 	OVL_ADAPTOR_TYPE_NUM,
@@ -62,20 +62,20 @@ struct mtk_disp_ovl_adaptor {
 };
 
 static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
-	[OVL_ADAPTOR_TYPE_RDMA]		= "vdo1-rdma",
+	[OVL_ADAPTOR_TYPE_MDP_RDMA]	= "vdo1-rdma",
 	[OVL_ADAPTOR_TYPE_MERGE]	= "merge",
 	[OVL_ADAPTOR_TYPE_ETHDR]	= "ethdr",
 };
 
 static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
-	[OVL_ADAPTOR_MDP_RDMA0]	= { OVL_ADAPTOR_TYPE_RDMA, 0 },
-	[OVL_ADAPTOR_MDP_RDMA1]	= { OVL_ADAPTOR_TYPE_RDMA, 1 },
-	[OVL_ADAPTOR_MDP_RDMA2]	= { OVL_ADAPTOR_TYPE_RDMA, 2 },
-	[OVL_ADAPTOR_MDP_RDMA3]	= { OVL_ADAPTOR_TYPE_RDMA, 3 },
-	[OVL_ADAPTOR_MDP_RDMA4]	= { OVL_ADAPTOR_TYPE_RDMA, 4 },
-	[OVL_ADAPTOR_MDP_RDMA5]	= { OVL_ADAPTOR_TYPE_RDMA, 5 },
-	[OVL_ADAPTOR_MDP_RDMA6]	= { OVL_ADAPTOR_TYPE_RDMA, 6 },
-	[OVL_ADAPTOR_MDP_RDMA7]	= { OVL_ADAPTOR_TYPE_RDMA, 7 },
+	[OVL_ADAPTOR_MDP_RDMA0]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 0 },
+	[OVL_ADAPTOR_MDP_RDMA1]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 1 },
+	[OVL_ADAPTOR_MDP_RDMA2]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 2 },
+	[OVL_ADAPTOR_MDP_RDMA3]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 3 },
+	[OVL_ADAPTOR_MDP_RDMA4]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 4 },
+	[OVL_ADAPTOR_MDP_RDMA5]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 5 },
+	[OVL_ADAPTOR_MDP_RDMA6]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 6 },
+	[OVL_ADAPTOR_MDP_RDMA7]	= { OVL_ADAPTOR_TYPE_MDP_RDMA, 7 },
 	[OVL_ADAPTOR_MERGE0]	= { OVL_ADAPTOR_TYPE_MERGE, 1 },
 	[OVL_ADAPTOR_MERGE1]	= { OVL_ADAPTOR_TYPE_MERGE, 2 },
 	[OVL_ADAPTOR_MERGE2]	= { OVL_ADAPTOR_TYPE_MERGE, 3 },
@@ -388,7 +388,7 @@ static int ovl_adaptor_comp_get_id(struct device *dev, struct device_node *node,
 static const struct of_device_id mtk_ovl_adaptor_comp_dt_ids[] = {
 	{
 		.compatible = "mediatek,mt8195-vdo1-rdma",
-		.data = (void *)OVL_ADAPTOR_TYPE_RDMA,
+		.data = (void *)OVL_ADAPTOR_TYPE_MDP_RDMA,
 	}, {
 		.compatible = "mediatek,mt8195-disp-merge",
 		.data = (void *)OVL_ADAPTOR_TYPE_MERGE,
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:45 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:45 +0800
Subject: [PATCH v12 21/23] drm/mediatek: Remove the redundant driver data for DPI
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-22-shawn.sung@mediatek.com>

DPI input is in 1T2P mode on both MT8195 and MT8188.
Remove the redundant driver data to align the settings, or
the screen will glitch.

Fixes: 2847cd7e6403 ("drm/mediatek: Add mt8188 dpi compatibles and platform data")

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +---------------
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 4e3d9f7b4d8c..beb7d9d08e97 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -966,20 +966,6 @@ static const struct mtk_dpi_conf mt8186_conf = {
 	.csc_enable_bit = CSC_ENABLE,
 };
 
-static const struct mtk_dpi_conf mt8188_dpintf_conf = {
-	.cal_factor = mt8195_dpintf_calculate_factor,
-	.max_clock_khz = 600000,
-	.output_fmts = mt8195_output_fmts,
-	.num_output_fmts = ARRAY_SIZE(mt8195_output_fmts),
-	.pixels_per_iter = 4,
-	.input_2pixel = false,
-	.dimension_mask = DPINTF_HPW_MASK,
-	.hvsize_mask = DPINTF_HSIZE_MASK,
-	.channel_swap_shift = DPINTF_CH_SWAP,
-	.yuv422_en_bit = DPINTF_YUV422_EN,
-	.csc_enable_bit = DPINTF_CSC_ENABLE,
-};
-
 static const struct mtk_dpi_conf mt8192_conf = {
 	.cal_factor = mt8183_calculate_factor,
 	.reg_h_fre_con = 0xe0,
@@ -1103,7 +1089,7 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
 	{ .compatible = "mediatek,mt8173-dpi", .data = &mt8173_conf },
 	{ .compatible = "mediatek,mt8183-dpi", .data = &mt8183_conf },
 	{ .compatible = "mediatek,mt8186-dpi", .data = &mt8186_conf },
-	{ .compatible = "mediatek,mt8188-dp-intf", .data = &mt8188_dpintf_conf },
+	{ .compatible = "mediatek,mt8188-dp-intf", .data = &mt8195_dpintf_conf },
 	{ .compatible = "mediatek,mt8192-dpi", .data = &mt8192_conf },
 	{ .compatible = "mediatek,mt8195-dp-intf", .data = &mt8195_dpintf_conf },
 	{ /* sentinel */ },
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:46 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:46 +0800
Subject: [PATCH v12 22/23] drm/mediatek: Fix underrun in VDO1 when switches off the layer
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-23-shawn.sung@mediatek.com>

Do not reset Merge while using CMDQ because reset API doesn't
wait for frame done event as CMDQ does and could lead to
underrun when the layer is switching off.

Fixes: aaf94f7c3ae6 ("drm/mediatek: Add display merge async reset control")

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_merge.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
index e525a6b9e5b0..22f768d923d5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
@@ -103,7 +103,7 @@ void mtk_merge_stop_cmdq(struct device *dev, struct cmdq_pkt *cmdq_pkt)
 	mtk_ddp_write(cmdq_pkt, 0, &priv->cmdq_reg, priv->regs,
 		      DISP_REG_MERGE_CTRL);
 
-	if (priv->async_clk)
+	if (!cmdq_pkt && priv->async_clk)
 		reset_control_reset(priv->reset_ctl);
 }
 
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:26 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:26 +0800
Subject: [PATCH v12 02/23] dt-bindings: display: mediatek: mdp-rdma: Add compatible for MT8188
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-3-shawn.sung@mediatek.com>

Add compatible name for MediaTek MT8188 MDP-RDMA.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: CK Hu <ck.hu at mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../bindings/display/mediatek/mediatek,mdp-rdma.yaml        | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
index dd12e2ff685c..7570a0684967 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
@@ -21,7 +21,11 @@ description:
 
 properties:
   compatible:
-    const: mediatek,mt8195-vdo1-rdma
+    oneOf:
+      - const: mediatek,mt8195-vdo1-rdma
+      - items:
+          - const: mediatek,mt8188-vdo1-rdma
+          - const: mediatek,mt8195-vdo1-rdma
 
   reg:
     maxItems: 1
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:32 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:32 +0800
Subject: [PATCH v12 08/23] soc: mediatek: Support MT8188 VDOSYS1 Padding in mtk-mmsys
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-9-shawn.sung@mediatek.com>

- Add Padding components
- Add Mutex module definitions for Padding

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/soc/mediatek/mtk-mutex.c       | 16 ++++++++++++++++
 include/linux/soc/mediatek/mtk-mmsys.h |  8 ++++++++
 2 files changed, 24 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index e76722289175..73c256d3950b 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -141,6 +141,14 @@
 #define MT8188_MUTEX_MOD_DISP1_MDP_RDMA5	5
 #define MT8188_MUTEX_MOD_DISP1_MDP_RDMA6	6
 #define MT8188_MUTEX_MOD_DISP1_MDP_RDMA7	7
+#define MT8188_MUTEX_MOD_DISP1_PADDING0		8
+#define MT8188_MUTEX_MOD_DISP1_PADDING1		9
+#define MT8188_MUTEX_MOD_DISP1_PADDING2		10
+#define MT8188_MUTEX_MOD_DISP1_PADDING3		11
+#define MT8188_MUTEX_MOD_DISP1_PADDING4		12
+#define MT8188_MUTEX_MOD_DISP1_PADDING5		13
+#define MT8188_MUTEX_MOD_DISP1_PADDING6		14
+#define MT8188_MUTEX_MOD_DISP1_PADDING7		15
 #define MT8188_MUTEX_MOD_DISP1_VPP_MERGE0	20
 #define MT8188_MUTEX_MOD_DISP1_VPP_MERGE1	21
 #define MT8188_MUTEX_MOD_DISP1_VPP_MERGE2	22
@@ -473,6 +481,14 @@ static const unsigned int mt8188_mutex_mod[DDP_COMPONENT_ID_MAX] = {
 	[DDP_COMPONENT_MDP_RDMA5] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA5,
 	[DDP_COMPONENT_MDP_RDMA6] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA6,
 	[DDP_COMPONENT_MDP_RDMA7] = MT8188_MUTEX_MOD_DISP1_MDP_RDMA7,
+	[DDP_COMPONENT_PADDING0] = MT8188_MUTEX_MOD_DISP1_PADDING0,
+	[DDP_COMPONENT_PADDING1] = MT8188_MUTEX_MOD_DISP1_PADDING1,
+	[DDP_COMPONENT_PADDING2] = MT8188_MUTEX_MOD_DISP1_PADDING2,
+	[DDP_COMPONENT_PADDING3] = MT8188_MUTEX_MOD_DISP1_PADDING3,
+	[DDP_COMPONENT_PADDING4] = MT8188_MUTEX_MOD_DISP1_PADDING4,
+	[DDP_COMPONENT_PADDING5] = MT8188_MUTEX_MOD_DISP1_PADDING5,
+	[DDP_COMPONENT_PADDING6] = MT8188_MUTEX_MOD_DISP1_PADDING6,
+	[DDP_COMPONENT_PADDING7] = MT8188_MUTEX_MOD_DISP1_PADDING7,
 	[DDP_COMPONENT_MERGE1] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE0,
 	[DDP_COMPONENT_MERGE2] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE1,
 	[DDP_COMPONENT_MERGE3] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE2,
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h b/include/linux/soc/mediatek/mtk-mmsys.h
index 2475ef914746..4885b065b849 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -62,6 +62,14 @@ enum mtk_ddp_comp_id {
 	DDP_COMPONENT_OVL_2L1,
 	DDP_COMPONENT_OVL_2L2,
 	DDP_COMPONENT_OVL1,
+	DDP_COMPONENT_PADDING0,
+	DDP_COMPONENT_PADDING1,
+	DDP_COMPONENT_PADDING2,
+	DDP_COMPONENT_PADDING3,
+	DDP_COMPONENT_PADDING4,
+	DDP_COMPONENT_PADDING5,
+	DDP_COMPONENT_PADDING6,
+	DDP_COMPONENT_PADDING7,
 	DDP_COMPONENT_POSTMASK0,
 	DDP_COMPONENT_PWM0,
 	DDP_COMPONENT_PWM1,
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:27 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:27 +0800
Subject: [PATCH v12 03/23] dt-bindings: display: mediatek: merge: Add compatible for MT8188
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-4-shawn.sung@mediatek.com>

Add compatible name for MediaTek MT8188 MERGE.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: CK Hu <ck.hu at mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../devicetree/bindings/display/mediatek/mediatek,merge.yaml   | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
index eead5cb8636e..5c678695162e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
@@ -27,6 +27,9 @@ properties:
       - items:
           - const: mediatek,mt6795-disp-merge
           - const: mediatek,mt8173-disp-merge
+      - items:
+          - const: mediatek,mt8188-disp-merge
+          - const: mediatek,mt8195-disp-merge
 
   reg:
     maxItems: 1
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:33 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:33 +0800
Subject: [PATCH v12 09/23] soc: mediatek: Support reset bit mapping in mmsys driver
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-10-shawn.sung@mediatek.com>

- Reset ID must starts from 0 and be consecutive, but
  the reset bits in our hardware design is not continuous,
  some bits are left unused, we need a map to solve the problem
- Use old style 1-to-1 mapping if .rst_tb is not defined

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 drivers/soc/mediatek/mtk-mmsys.c | 9 +++++++++
 drivers/soc/mediatek/mtk-mmsys.h | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 1b160fcc1d27..fee958d0b8a6 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -314,6 +314,15 @@ static int mtk_mmsys_reset_update(struct reset_controller_dev *rcdev, unsigned l
 	u32 offset;
 	u32 reg;
 
+	if (mmsys->data->rst_tb) {
+		if (id >= mmsys->data->num_resets) {
+			dev_err(rcdev->dev, "Invalid reset ID: %lu (>=%u)\n",
+				id, mmsys->data->num_resets);
+			return -EINVAL;
+		}
+		id = mmsys->data->rst_tb[id];
+	}
+
 	offset = (id / MMSYS_SW_RESET_PER_REG) * sizeof(u32);
 	id = id % MMSYS_SW_RESET_PER_REG;
 	reg = mmsys->data->sw0_rst_offset + offset;
diff --git a/drivers/soc/mediatek/mtk-mmsys.h b/drivers/soc/mediatek/mtk-mmsys.h
index 9d8507f98b7a..d370192737ca 100644
--- a/drivers/soc/mediatek/mtk-mmsys.h
+++ b/drivers/soc/mediatek/mtk-mmsys.h
@@ -78,6 +78,8 @@
 #define DSI_SEL_IN_RDMA				0x1
 #define DSI_SEL_IN_MASK				0x1
 
+#define MMSYS_RST_NR(bank, bit) (((bank) * 32) + (bit))
+
 struct mtk_mmsys_routes {
 	u32 from_comp;
 	u32 to_comp;
@@ -119,6 +121,7 @@ struct mtk_mmsys_driver_data {
 	const struct mtk_mmsys_routes *routes;
 	const unsigned int num_routes;
 	const u16 sw0_rst_offset;
+	const u8 *rst_tb;
 	const u32 num_resets;
 	const bool is_vppsys;
 	const u8 vsync_len;
-- 
2.18.0



From shawn.sung at mediatek.com  Wed Dec 13 21:58:43 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:43 +0800
Subject: [PATCH v12 19/23] drm/mediatek: Add Padding to OVL adaptor
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-20-shawn.sung@mediatek.com>

Add MT8188 Padding to OVL adaptor to probe the driver.

Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 92eeb1005ec3..c922d5dd75bb 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -30,6 +30,7 @@ enum mtk_ovl_adaptor_comp_type {
 	OVL_ADAPTOR_TYPE_ETHDR,
 	OVL_ADAPTOR_TYPE_MDP_RDMA,
 	OVL_ADAPTOR_TYPE_MERGE,
+	OVL_ADAPTOR_TYPE_PADDING,
 	OVL_ADAPTOR_TYPE_NUM,
 };
 
@@ -47,6 +48,14 @@ enum mtk_ovl_adaptor_comp_id {
 	OVL_ADAPTOR_MERGE1,
 	OVL_ADAPTOR_MERGE2,
 	OVL_ADAPTOR_MERGE3,
+	OVL_ADAPTOR_PADDING0,
+	OVL_ADAPTOR_PADDING1,
+	OVL_ADAPTOR_PADDING2,
+	OVL_ADAPTOR_PADDING3,
+	OVL_ADAPTOR_PADDING4,
+	OVL_ADAPTOR_PADDING5,
+	OVL_ADAPTOR_PADDING6,
+	OVL_ADAPTOR_PADDING7,
 	OVL_ADAPTOR_ID_MAX
 };
 
@@ -67,6 +76,7 @@ static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
 	[OVL_ADAPTOR_TYPE_ETHDR]	= "ethdr",
 	[OVL_ADAPTOR_TYPE_MDP_RDMA]	= "vdo1-rdma",
 	[OVL_ADAPTOR_TYPE_MERGE]	= "merge",
+	[OVL_ADAPTOR_TYPE_PADDING]	= "padding",
 };
 
 static const struct mtk_ddp_comp_funcs ethdr = {
@@ -81,6 +91,13 @@ static const struct mtk_ddp_comp_funcs merge = {
 	.clk_disable = mtk_merge_clk_disable,
 };
 
+static const struct mtk_ddp_comp_funcs padding = {
+	.clk_enable = mtk_padding_clk_enable,
+	.clk_disable = mtk_padding_clk_disable,
+	.start = mtk_padding_start,
+	.stop = mtk_padding_stop,
+};
+
 static const struct mtk_ddp_comp_funcs rdma = {
 	.power_on = mtk_mdp_rdma_power_on,
 	.power_off = mtk_mdp_rdma_power_off,
@@ -102,6 +119,14 @@ static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
 	[OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 2, &merge },
 	[OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 3, &merge },
 	[OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 4, &merge },
+	[OVL_ADAPTOR_PADDING0] = { OVL_ADAPTOR_TYPE_PADDING, DDP_COMPONENT_PADDING0, 0, &padding },
+	[OVL_ADAPTOR_PADDING1] = { OVL_ADAPTOR_TYPE_PADDING, DDP_COMPONENT_PADDING1, 1, &padding },
+	[OVL_ADAPTOR_PADDING2] = { OVL_ADAPTOR_TYPE_PADDING, DDP_COMPONENT_PADDING2, 2, &padding },
+	[OVL_ADAPTOR_PADDING3] = { OVL_ADAPTOR_TYPE_PADDING, DDP_COMPONENT_PADDING3, 3, &padding },
+	[OVL_ADAPTOR_PADDING4] = { OVL_ADAPTOR_TYPE_PADDING, DDP_COMPONENT_PADDING4, 4, &padding },
+	[OVL_ADAPTOR_PADDING5] = { OVL_ADAPTOR_TYPE_PADDING, DDP_COMPONENT_PADDING5, 5, &padding },
+	[OVL_ADAPTOR_PADDING6] = { OVL_ADAPTOR_TYPE_PADDING, DDP_COMPONENT_PADDING6, 6, &padding },
+	[OVL_ADAPTOR_PADDING7] = { OVL_ADAPTOR_TYPE_PADDING, DDP_COMPONENT_PADDING7, 7, &padding },
 };
 
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
@@ -437,6 +462,7 @@ static int ovl_adaptor_comp_get_id(struct device *dev, struct device_node *node,
 }
 
 static const struct of_device_id mtk_ovl_adaptor_comp_dt_ids[] = {
+	{ .compatible = "mediatek,mt8188-disp-padding", .data = (void *)OVL_ADAPTOR_TYPE_PADDING },
 	{ .compatible = "mediatek,mt8195-disp-ethdr", .data = (void *)OVL_ADAPTOR_TYPE_ETHDR },
 	{ .compatible = "mediatek,mt8195-disp-merge", .data = (void *)OVL_ADAPTOR_TYPE_MERGE },
 	{ .compatible = "mediatek,mt8195-vdo1-rdma", .data = (void *)OVL_ADAPTOR_TYPE_MDP_RDMA },
-- 
2.18.0



From anup at brainfault.org  Wed Dec 13 22:02:35 2023
From: anup at brainfault.org (Anup Patel)
Date: Thu, 14 Dec 2023 11:32:35 +0530
Subject: [PATCH 15/26] KVM: Move include/kvm/iodev.h to include/linux as kvm_iodev.h
In-Reply-To: <20230916003118.2540661-16-seanjc@google.com>
References: <20230916003118.2540661-1-seanjc@google.com> <20230916003118.2540661-16-seanjc@google.com>
Message-ID: <CAAhSdy2aW0vUsaA_sVKROv8tr9ixuY+RZQt6XFs86bzy++AegA@mail.gmail.com>

On Sat, Sep 16, 2023 at 6:01?AM Sean Christopherson <seanjc at google.com> wrote:
>
> Move iodev.h, the last remaining holdout in include/kvm, to the standard
> include/linux directory as kvm_iodev.h and delete include/kvm.
>
> Signed-off-by: Sean Christopherson <seanjc at google.com>

For KVM RISC-V:
Acked-by: Anup Patel <anup at brainfault.org>

Regards,
Anup

> ---
>  MAINTAINERS                                | 1 -
>  arch/arm64/include/asm/kvm_vgic.h          | 2 +-
>  arch/arm64/kvm/vgic/vgic-mmio-v2.c         | 2 +-
>  arch/arm64/kvm/vgic/vgic-mmio-v3.c         | 2 +-
>  arch/arm64/kvm/vgic/vgic-mmio.c            | 2 +-
>  arch/mips/include/asm/kvm_host.h           | 3 +--
>  arch/powerpc/kvm/mpic.c                    | 2 +-
>  arch/riscv/kvm/aia_aplic.c                 | 2 +-
>  arch/riscv/kvm/aia_imsic.c                 | 2 +-
>  arch/x86/kvm/i8254.h                       | 2 +-
>  arch/x86/kvm/ioapic.h                      | 2 +-
>  arch/x86/kvm/irq.h                         | 2 +-
>  arch/x86/kvm/lapic.h                       | 2 +-
>  include/{kvm/iodev.h => linux/kvm_iodev.h} | 0
>  virt/kvm/coalesced_mmio.c                  | 3 +--
>  virt/kvm/eventfd.c                         | 2 +-
>  virt/kvm/kvm_main.c                        | 3 +--
>  17 files changed, 15 insertions(+), 19 deletions(-)
>  rename include/{kvm/iodev.h => linux/kvm_iodev.h} (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 90f13281d297..ddc8375d536c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11498,7 +11498,6 @@ W:      http://www.linux-kvm.org
>  T:     git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
>  F:     Documentation/virt/kvm/
>  F:     include/asm-generic/kvm*
> -F:     include/kvm/iodev.h
>  F:     include/linux/kvm*
>  F:     include/trace/events/kvm.h
>  F:     include/uapi/asm-generic/kvm*
> diff --git a/arch/arm64/include/asm/kvm_vgic.h b/arch/arm64/include/asm/kvm_vgic.h
> index 5b27f94d4fad..2ca52888bc75 100644
> --- a/arch/arm64/include/asm/kvm_vgic.h
> +++ b/arch/arm64/include/asm/kvm_vgic.h
> @@ -13,7 +13,7 @@
>  #include <linux/spinlock.h>
>  #include <linux/static_key.h>
>  #include <linux/types.h>
> -#include <kvm/iodev.h>
> +#include <linux/kvm_iodev.h>
>  #include <linux/list.h>
>  #include <linux/jump_label.h>
>
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v2.c b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
> index bba0cfeefffe..646053ee892f 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio-v2.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
> @@ -6,9 +6,9 @@
>  #include <linux/irqchip/arm-gic.h>
>  #include <linux/kvm.h>
>  #include <linux/kvm_host.h>
> +#include <linux/kvm_iodev.h>
>  #include <linux/nospec.h>
>
> -#include <kvm/iodev.h>
>  #include <asm/kvm_vgic.h>
>
>  #include "vgic.h"
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> index d54a90beef61..b79a2e860415 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> @@ -7,8 +7,8 @@
>  #include <linux/irqchip/arm-gic-v3.h>
>  #include <linux/kvm.h>
>  #include <linux/kvm_host.h>
> +#include <linux/kvm_iodev.h>
>  #include <linux/interrupt.h>
> -#include <kvm/iodev.h>
>
>  #include <asm/kvm_emulate.h>
>  #include <asm/kvm_arm.h>
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio.c b/arch/arm64/kvm/vgic/vgic-mmio.c
> index 68a3d8062473..4feca3b1d915 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio.c
> @@ -9,7 +9,7 @@
>  #include <linux/irq.h>
>  #include <linux/kvm.h>
>  #include <linux/kvm_host.h>
> -#include <kvm/iodev.h>
> +#include <linux/kvm_iodev.h>
>  #include <asm/kvm_arch_timer.h>
>  #include <asm/kvm_vgic.h>
>
> diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
> index 54a85f1d4f2c..f8f63d0aa399 100644
> --- a/arch/mips/include/asm/kvm_host.h
> +++ b/arch/mips/include/asm/kvm_host.h
> @@ -16,6 +16,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/types.h>
>  #include <linux/kvm.h>
> +#include <linux/kvm_iodev.h>
>  #include <linux/kvm_types.h>
>  #include <linux/threads.h>
>  #include <linux/spinlock.h>
> @@ -24,8 +25,6 @@
>  #include <asm/inst.h>
>  #include <asm/mipsregs.h>
>
> -#include <kvm/iodev.h>
> -
>  /* MIPS KVM register ids */
>  #define MIPS_CP0_32(_R, _S)                                    \
>         (KVM_REG_MIPS_CP0 | KVM_REG_SIZE_U32 | (8 * (_R) + (_S)))
> diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c
> index 23e9c2bd9f27..b25a03251544 100644
> --- a/arch/powerpc/kvm/mpic.c
> +++ b/arch/powerpc/kvm/mpic.c
> @@ -26,6 +26,7 @@
>  #include <linux/slab.h>
>  #include <linux/mutex.h>
>  #include <linux/kvm_host.h>
> +#include <linux/kvm_iodev.h>
>  #include <linux/errno.h>
>  #include <linux/fs.h>
>  #include <linux/anon_inodes.h>
> @@ -33,7 +34,6 @@
>  #include <asm/mpic.h>
>  #include <asm/kvm_para.h>
>  #include <asm/kvm_ppc.h>
> -#include <kvm/iodev.h>
>
>  #define MAX_CPU     32
>  #define MAX_SRC     256
> diff --git a/arch/riscv/kvm/aia_aplic.c b/arch/riscv/kvm/aia_aplic.c
> index 39e72aa016a4..b49e747f2bad 100644
> --- a/arch/riscv/kvm/aia_aplic.c
> +++ b/arch/riscv/kvm/aia_aplic.c
> @@ -11,7 +11,7 @@
>  #include <linux/math.h>
>  #include <linux/spinlock.h>
>  #include <linux/swab.h>
> -#include <kvm/iodev.h>
> +#include <linux/kvm_iodev.h>
>  #include <asm/kvm_aia_aplic.h>
>
>  struct aplic_irq {
> diff --git a/arch/riscv/kvm/aia_imsic.c b/arch/riscv/kvm/aia_imsic.c
> index 6cf23b8adb71..586e466a1c6d 100644
> --- a/arch/riscv/kvm/aia_imsic.c
> +++ b/arch/riscv/kvm/aia_imsic.c
> @@ -10,10 +10,10 @@
>  #include <linux/atomic.h>
>  #include <linux/bitmap.h>
>  #include <linux/kvm_host.h>
> +#include <linux/kvm_iodev.h>
>  #include <linux/math.h>
>  #include <linux/spinlock.h>
>  #include <linux/swab.h>
> -#include <kvm/iodev.h>
>  #include <asm/csr.h>
>  #include <asm/kvm_aia_imsic.h>
>
> diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
> index a768212ba821..4de7a0b88e4f 100644
> --- a/arch/x86/kvm/i8254.h
> +++ b/arch/x86/kvm/i8254.h
> @@ -4,7 +4,7 @@
>
>  #include <linux/kthread.h>
>
> -#include <kvm/iodev.h>
> +#include <linux/kvm_iodev.h>
>
>  struct kvm_kpit_channel_state {
>         u32 count; /* can be 65536 */
> diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
> index 539333ac4b38..2beec2daf1a3 100644
> --- a/arch/x86/kvm/ioapic.h
> +++ b/arch/x86/kvm/ioapic.h
> @@ -3,7 +3,7 @@
>  #define __KVM_IO_APIC_H
>
>  #include <linux/kvm_host.h>
> -#include <kvm/iodev.h>
> +#include <linux/kvm_iodev.h>
>  #include "irq.h"
>
>  struct kvm;
> diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
> index c2d7cfe82d00..f9530e9a66f8 100644
> --- a/arch/x86/kvm/irq.h
> +++ b/arch/x86/kvm/irq.h
> @@ -13,9 +13,9 @@
>  #include <linux/mm_types.h>
>  #include <linux/hrtimer.h>
>  #include <linux/kvm_host.h>
> +#include <linux/kvm_iodev.h>
>  #include <linux/spinlock.h>
>
> -#include <kvm/iodev.h>
>  #include "lapic.h"
>
>  #define PIC_NUM_PINS 16
> diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
> index 0a0ea4b5dd8c..bfd99ad1882e 100644
> --- a/arch/x86/kvm/lapic.h
> +++ b/arch/x86/kvm/lapic.h
> @@ -2,7 +2,7 @@
>  #ifndef __KVM_X86_LAPIC_H
>  #define __KVM_X86_LAPIC_H
>
> -#include <kvm/iodev.h>
> +#include <linux/kvm_iodev.h>
>
>  #include <linux/kvm_host.h>
>
> diff --git a/include/kvm/iodev.h b/include/linux/kvm_iodev.h
> similarity index 100%
> rename from include/kvm/iodev.h
> rename to include/linux/kvm_iodev.h
> diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c
> index 1b90acb6e3fe..cfcb4b84d632 100644
> --- a/virt/kvm/coalesced_mmio.c
> +++ b/virt/kvm/coalesced_mmio.c
> @@ -9,8 +9,7 @@
>   *
>   */
>
> -#include <kvm/iodev.h>
> -
> +#include <linux/kvm_iodev.h>
>  #include <linux/kvm_host.h>
>  #include <linux/slab.h>
>  #include <linux/kvm.h>
> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> index 89912a17f5d5..4d7cfb1095fd 100644
> --- a/virt/kvm/eventfd.c
> +++ b/virt/kvm/eventfd.c
> @@ -26,7 +26,7 @@
>  #include <linux/irqbypass.h>
>  #include <trace/events/kvm.h>
>
> -#include <kvm/iodev.h>
> +#include <linux/kvm_iodev.h>
>
>  #ifdef CONFIG_HAVE_KVM_IRQFD
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 486800a7024b..f585a159b4f5 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -13,9 +13,8 @@
>   *   Yaniv Kamay  <yaniv at qumranet.com>
>   */
>
> -#include <kvm/iodev.h>
> -
>  #include <linux/kvm_host.h>
> +#include <linux/kvm_iodev.h>
>  #include <linux/kvm.h>
>  #include <linux/module.h>
>  #include <linux/errno.h>
> --
> 2.42.0.459.ge4e396fd5e-goog
>


From anup at brainfault.org  Wed Dec 13 22:04:49 2023
From: anup at brainfault.org (Anup Patel)
Date: Thu, 14 Dec 2023 11:34:49 +0530
Subject: [PATCH 19/26] KVM: Standardize include paths across all architectures
In-Reply-To: <20230916003118.2540661-20-seanjc@google.com>
References: <20230916003118.2540661-1-seanjc@google.com> <20230916003118.2540661-20-seanjc@google.com>
Message-ID: <CAAhSdy1bzQ2mxOew0iw-OuLWxzOhk3LtO+908TYw2gw+5yN3RA@mail.gmail.com>

On Sat, Sep 16, 2023 at 6:01?AM Sean Christopherson <seanjc at google.com> wrote:
>
> Standardize KVM's include paths across all architectures by declaring
> the KVM-specific includes in the common Makefile.kvm.  Having common KVM
> "own" the included paths reduces the temptation to unnecessarily add
> virt/kvm to arch include paths, and conversely if allowing arch code to
> grab headers from virt/kvm becomes desirable, virt/kvm can be added to
> all architecture's include path with a single line update.
>
> Having the common KVM makefile append to ccflags also provides a
> convenient location to append other things, e.g. KVM-specific #defines.
>
> Note, this changes the behavior of s390 and PPC, as s390 and PPC
> previously overwrote ccflags-y instead of adding on.  There is no evidence
> that overwriting ccflags-y was necessary or even deliberate, as both s390
> and PPC switched to the overwrite behavior without so much as a passing
> mention when EXTRA_CFLAGS was replaced with ccflags-y (commit c73028a02887
> ("s390: change to new flag variable") and commit 4108d9ba9091
> ("powerpc/Makefiles: Change to new flag variables")).
>
> Signed-off-by: Sean Christopherson <seanjc at google.com>

For KVM RISC-V:
Acked-by: Anup Patel <anup at brainfault.org>

Regards,
Anup

> ---
>  arch/arm64/kvm/Makefile   | 2 --
>  arch/mips/kvm/Makefile    | 2 --
>  arch/powerpc/kvm/Makefile | 2 --
>  arch/riscv/kvm/Makefile   | 2 --
>  arch/s390/kvm/Makefile    | 2 --
>  arch/x86/kvm/Makefile     | 1 -
>  virt/kvm/Makefile.kvm     | 2 ++
>  7 files changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index c0c050e53157..3996489baeef 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -3,8 +3,6 @@
>  # Makefile for Kernel-based Virtual Machine module
>  #
>
> -ccflags-y += -I $(srctree)/$(src)
> -
>  include $(srctree)/virt/kvm/Makefile.kvm
>
>  obj-$(CONFIG_KVM) += kvm.o
> diff --git a/arch/mips/kvm/Makefile b/arch/mips/kvm/Makefile
> index 96a7cd21b140..d198e1addea7 100644
> --- a/arch/mips/kvm/Makefile
> +++ b/arch/mips/kvm/Makefile
> @@ -4,8 +4,6 @@
>
>  include $(srctree)/virt/kvm/Makefile.kvm
>
> -ccflags-y += -Iarch/mips/kvm
> -
>  kvm-$(CONFIG_CPU_HAS_MSA) += msa.o
>
>  kvm-y +=    mips.o emulate.o entry.o \
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index 08a0e53d58c7..d6c6678ddf65 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -3,8 +3,6 @@
>  # Makefile for Kernel-based Virtual Machine module
>  #
>
> -ccflags-y := -Iarch/powerpc/kvm
> -
>  include $(srctree)/virt/kvm/Makefile.kvm
>
>  common-objs-y += powerpc.o emulate_loadstore.o
> diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
> index 4c2067fc59fc..ff7d5f67e229 100644
> --- a/arch/riscv/kvm/Makefile
> +++ b/arch/riscv/kvm/Makefile
> @@ -3,8 +3,6 @@
>  # Makefile for RISC-V KVM support
>  #
>
> -ccflags-y += -I $(srctree)/$(src)
> -
>  include $(srctree)/virt/kvm/Makefile.kvm
>
>  obj-$(CONFIG_KVM) += kvm.o
> diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile
> index f17249ab2a72..f8153189e003 100644
> --- a/arch/s390/kvm/Makefile
> +++ b/arch/s390/kvm/Makefile
> @@ -5,8 +5,6 @@
>
>  include $(srctree)/virt/kvm/Makefile.kvm
>
> -ccflags-y := -Iarch/s390/kvm
> -
>  kvm-y += kvm-s390.o intercept.o interrupt.o priv.o sigp.o
>  kvm-y += diag.o gaccess.o guestdbg.o vsie.o pv.o
>
> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> index 80e3fe184d17..d13f1a7b7b3d 100644
> --- a/arch/x86/kvm/Makefile
> +++ b/arch/x86/kvm/Makefile
> @@ -1,6 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
>
> -ccflags-y += -I $(srctree)/arch/x86/kvm
>  ccflags-$(CONFIG_KVM_WERROR) += -Werror
>
>  ifeq ($(CONFIG_FRAME_POINTER),y)
> diff --git a/virt/kvm/Makefile.kvm b/virt/kvm/Makefile.kvm
> index 29373b59d89a..e85079ad245d 100644
> --- a/virt/kvm/Makefile.kvm
> +++ b/virt/kvm/Makefile.kvm
> @@ -3,6 +3,8 @@
>  # Makefile for Kernel-based Virtual Machine module
>  #
>
> +ccflags-y += -I$(srctree)/$(src)
> +
>  KVM ?= ../../../virt/kvm
>
>  kvm-y := $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/binary_stats.o
> --
> 2.42.0.459.ge4e396fd5e-goog
>


From shawn.sung at mediatek.com  Wed Dec 13 21:58:28 2023
From: shawn.sung at mediatek.com (Hsiao Chien Sung)
Date: Thu, 14 Dec 2023 13:58:28 +0800
Subject: [PATCH v12 04/23] dt-bindings: display: mediatek: padding: Add MT8188
In-Reply-To: <20231214055847.4936-1-shawn.sung@mediatek.com>
References: <20231214055847.4936-1-shawn.sung@mediatek.com>
Message-ID: <20231214055847.4936-5-shawn.sung@mediatek.com>

Padding is a new hardware module on MediaTek MT8188,
add dt-bindings for it.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: CK Hu <ck.hu at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
---
 .../display/mediatek/mediatek,padding.yaml    | 81 +++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
new file mode 100644
index 000000000000..6bad7dc2d69f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,padding.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Display Padding
+
+maintainers:
+  - Chun-Kuang Hu <chunkuang.hu at kernel.org>
+  - Philipp Zabel <p.zabel at pengutronix.de>
+
+description:
+  Padding provides ability to add pixels to width and height of a layer with
+  specified colors. Due to hardware design, Mixer in VDOSYS1 requires
+  width of a layer to be 2-pixel-align, or 4-pixel-align when ETHDR is enabled,
+  we need Padding to deal with odd width.
+  Please notice that even if the Padding is in bypass mode, settings in
+  register must be cleared to 0, or undefined behaviors could happen.
+
+properties:
+  compatible:
+    const: mediatek,mt8188-disp-padding
+
+  reg:
+    maxItems: 1
+
+  power-domains:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: Padding's clocks
+
+  mediatek,gce-client-reg:
+    description:
+      GCE (Global Command Engine) is a multi-core micro processor that helps
+      its clients to execute commands without interrupting CPU. This property
+      describes GCE client's information that is composed by 4 fields.
+      1. Phandle of the GCE (there may be several GCE processors)
+      2. Sub-system ID defined in the dt-binding like a user ID
+         (Please refer to include/dt-bindings/gce/<chip>-gce.h)
+      3. Offset from base address of the subsys you are at
+      4. Size of the register the client needs
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      items:
+        - description: Phandle of the GCE
+        - description: Subsys ID defined in the dt-binding
+        - description: Offset from base address of the subsys
+        - description: Size of register
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - power-domains
+  - clocks
+  - mediatek,gce-client-reg
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/mediatek,mt8188-clk.h>
+    #include <dt-bindings/power/mediatek,mt8188-power.h>
+    #include <dt-bindings/gce/mt8195-gce.h>
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        padding0: padding at 1c11d000 {
+            compatible = "mediatek,mt8188-disp-padding";
+            reg = <0 0x1c11d000 0 0x1000>;
+            clocks = <&vdosys1 CLK_VDO1_PADDING0>;
+            power-domains = <&spm MT8188_POWER_DOMAIN_VDOSYS1>;
+            mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0xd000 0x1000>;
+        };
+    };
-- 
2.18.0



From masahiroy at kernel.org  Wed Dec 13 22:12:07 2023
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Thu, 14 Dec 2023 15:12:07 +0900
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAGXv+5Est3FL-XcEL-vB-6zVNas0mqb2cNYa==Yb7W2SQU9xVQ@mail.gmail.com>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com> <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
 <20231209152946.GC13421@pendragon.ideasonboard.com> <CAMuHMdVMZs6mnwWBgFwktO=8o=QzROv60cfZe085MhD6HxQjpQ@mail.gmail.com>
 <CAGXv+5Est3FL-XcEL-vB-6zVNas0mqb2cNYa==Yb7W2SQU9xVQ@mail.gmail.com>
Message-ID: <CAK7LNATyD-PeNbaLTjJmU9=koqqE+V6QvFe09c2VrXopWvjpcw@mail.gmail.com>

On Thu, Dec 14, 2023 at 1:03?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> On Sun, Dec 10, 2023 at 1:31?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> >
> > Hi Laurent,
> >
> > On Sat, Dec 9, 2023 at 4:29?PM Laurent Pinchart
> > <laurent.pinchart at ideasonboard.com> wrote:
> > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > On Thu, Dec 7, 2023 at 11:38?PM Laurent Pinchart
> > > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > performance.
> > > > > > > >
> > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > >
> > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > filenames or other workarounds.
> > > > > > > >
> > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > >
> > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > >
> > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > $(obj)/image.fit
> > > > > > > >
> > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > >
> > > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > > balance between what makes sense for the kernel and the features that
> > > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > > to delay merging this series.
> > > > > > >
> > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > > to a second question: would you consider merging extensions to this
> > > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > > users who manually invoke the script ? More generally, is the script
> > > > > >
> > > > > > We'd also be interested in some customization, though in a different way.
> > > > > > We imagine having a rule file that says X compatible string should map
> > > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > > carry all the possible second source components, like different display
> > > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > > >
> > > > > Do you envision the "mapping" compatible string mapping to a config
> > > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > > >
> > > > That's exactly the idea. The mapping compatible string could be untied
> > > > from the base board's compatible string if needed (which we probably do).
> > > >
> > > > So something like:
> > > >
> > > > config {
> > > >     config-1 {
> > > >         compatible = "google,krane-sku0";
> > > >         fdt = "krane-baseboard", "krane-sku0-overlay";
> > > >     };
> > > > };
> > > >
> > > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > > between the SKUs, in this case the display panel and MIPI camera (not
> > > > upstreamed) that applies to SKU0 in particular.
> > >
> > > The kernel DT makefiles already contain information on what overlays to
> > > apply to what base boards, in order to test the overlays and produce
> > > "full" DTBs. Maybe that information could be leveraged to create the
> > > configurations in the FIT image ?
> >
> > Although the "full" DTBs created may only be a subset of all possible
> > combinations (I believe Rob just started with creating one "full" DTB
> > for each overlay, cfr. the additions I made in commit a09c3e105a208580
> > ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> > definitely be a start.
> >
> > Now, since the kernel build system already creates "full" DTBs, does
> > that mean that all of the base DTBs, overlays, and "full" DTBs will
> > end up in the FIT image?
>
> I suppose we could add an option to the packing tool to be able to _not_
> add the "full" DTBs if they can also be assembled with a base DTB and
> overlays. Think of it as a firmware compatibility option: if the firmware
> supports overlays, then you almost always want the deconstructed parts,
> not the fully assembled ones. Vice versa.
>
> If we don't we could end up with two configurations that have the same
> compatible string?


Right.

We would end up with such situations because applying
an overlay does not change the compatible string.



With this code in arch/arm64/boot/dts/ti/Makefile:

k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
      k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
      k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo




$ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb
2>/dev/null| head -n15 | tail -n2
    model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
    compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
"ti,am642";


$ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
2>/dev/null| head -n15 | tail -n2
    model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
    compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
"ti,am642";





These two go into image.fit, but one of them is completely dead
since there is no way to distinguish them.


$ fdtdump  arch/arm64/boot/image.fit

        ...

        conf-10 {
            compatible = "tq,am642-tqma6442l-mbax4xxl",
"tq,am642-tqma6442l", "ti,am642";
            description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
            fdt = "fdt-10";
            kernel = "kernel";
        };

        ...

        conf-25 {
            compatible = "tq,am642-tqma6442l-mbax4xxl",
"tq,am642-tqma6442l", "ti,am642";
            description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
            fdt = "fdt-25";
            kernel = "kernel";
        };





I agree with Chen-Yu.

FIT should not include full DTBs.

Bootloaders should assemble the final DTB
from base and overlays on-the-fly.


The FIT spec allows the "fdt" property to list
multiple image nodes.


o config-1
 |- description = "configuration description"
 |- kernel = "kernel sub-node unit name"
 |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
 |- loadables = "loadables sub-node unit-name"
 |- script = "
 |- compatible = "vendor











>
> ChenYu
>
>
> > Gr{oetje,eeting}s,
> >
> >                         Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> >                                 -- Linus Torvalds



--
Best Regards
Masahiro Yamada


From anup at brainfault.org  Wed Dec 13 22:13:50 2023
From: anup at brainfault.org (Anup Patel)
Date: Thu, 14 Dec 2023 11:43:50 +0530
Subject: [PATCH 22/26] entry/kvm: KVM: Move KVM details related to
 signal/-EINTR into KVM proper
In-Reply-To: <20230916003118.2540661-23-seanjc@google.com>
References: <20230916003118.2540661-1-seanjc@google.com> <20230916003118.2540661-23-seanjc@google.com>
Message-ID: <CAAhSdy2N8PmP2+-8sFVpgduED0HU9D3dqg7sk3+R9f2wRgZ7KA@mail.gmail.com>

On Sat, Sep 16, 2023 at 6:02?AM Sean Christopherson <seanjc at google.com> wrote:
>
> Move KVM's morphing of pending signals into exits to userspace into KVM
> proper, and drop the @vcpu param from xfer_to_guest_mode_handle_work().
> How KVM responds to -EINTR is a detail that really belongs in KVM itself,
> and removing the non-KVM call to kvm_handle_signal_exit() will allow
> hiding said API and the definition of "struct kvm_vcpu" from the kernel.
>
> Alternatively, entry/kvm.c could be treated as part of KVM, i.e. be given
> access to KVM internals, but that's not obviously better than having KVM
> react to -EINTR (though it's not obviously worse either).
>
> Signed-off-by: Sean Christopherson <seanjc at google.com>

For KVM RISC-V:
Anup Patel <anup at brainfault.org>

Regards,
Anup

> ---
>  arch/arm64/kvm/arm.c      |  3 +--
>  arch/riscv/kvm/vcpu.c     |  2 +-
>  arch/x86/kvm/vmx/vmx.c    |  1 -
>  arch/x86/kvm/x86.c        |  3 +--
>  include/linux/entry-kvm.h |  3 +--
>  include/linux/kvm_host.h  | 13 ++++++++++++-
>  kernel/entry/kvm.c        | 11 ++++-------
>  7 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 6480628197b4..641df091e46b 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -6,7 +6,6 @@
>
>  #include <linux/bug.h>
>  #include <linux/cpu_pm.h>
> -#include <linux/entry-kvm.h>
>  #include <linux/errno.h>
>  #include <linux/err.h>
>  #include <linux/kvm_host.h>
> @@ -929,7 +928,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>                 /*
>                  * Check conditions before entering the guest
>                  */
> -               ret = xfer_to_guest_mode_handle_work(vcpu);
> +               ret = kvm_xfer_to_guest_mode_handle_work(vcpu);
>                 if (!ret)
>                         ret = 1;
>
> diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
> index 82229db1ce73..c313f4e90e70 100644
> --- a/arch/riscv/kvm/vcpu.c
> +++ b/arch/riscv/kvm/vcpu.c
> @@ -667,7 +667,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>         run->exit_reason = KVM_EXIT_UNKNOWN;
>         while (ret > 0) {
>                 /* Check conditions before entering the guest */
> -               ret = xfer_to_guest_mode_handle_work(vcpu);
> +               ret = kvm_xfer_to_guest_mode_handle_work(vcpu);
>                 if (ret)
>                         continue;
>                 ret = 1;
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index faf0071566ef..43b87ad5fde8 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -28,7 +28,6 @@
>  #include <linux/slab.h>
>  #include <linux/tboot.h>
>  #include <linux/trace_events.h>
> -#include <linux/entry-kvm.h>
>
>  #include <asm/apic.h>
>  #include <asm/asm.h>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 6c9c81e82e65..aab095f89d9e 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -59,7 +59,6 @@
>  #include <linux/sched/stat.h>
>  #include <linux/sched/isolation.h>
>  #include <linux/mem_encrypt.h>
> -#include <linux/entry-kvm.h>
>  #include <linux/suspend.h>
>  #include <linux/smp.h>
>
> @@ -10987,7 +10986,7 @@ static int vcpu_run(struct kvm_vcpu *vcpu)
>
>                 if (__xfer_to_guest_mode_work_pending()) {
>                         kvm_vcpu_srcu_read_unlock(vcpu);
> -                       r = xfer_to_guest_mode_handle_work(vcpu);
> +                       r = kvm_xfer_to_guest_mode_handle_work(vcpu);
>                         kvm_vcpu_srcu_read_lock(vcpu);
>                         if (r)
>                                 return r;
> diff --git a/include/linux/entry-kvm.h b/include/linux/entry-kvm.h
> index e7d90d06e566..e235a91d28fc 100644
> --- a/include/linux/entry-kvm.h
> +++ b/include/linux/entry-kvm.h
> @@ -42,11 +42,10 @@ static inline int arch_xfer_to_guest_mode_handle_work(unsigned long ti_work)
>  /**
>   * xfer_to_guest_mode_handle_work - Check and handle pending work which needs
>   *                                 to be handled before going to guest mode
> - * @vcpu:      Pointer to current's VCPU data
>   *
>   * Returns: 0 or an error code
>   */
> -int xfer_to_guest_mode_handle_work(struct kvm_vcpu *vcpu);
> +int xfer_to_guest_mode_handle_work(void);
>
>  /**
>   * xfer_to_guest_mode_prepare - Perform last minute preparation work that
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index fb6c6109fdca..d520d6801070 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -2,7 +2,7 @@
>  #ifndef __KVM_HOST_H
>  #define __KVM_HOST_H
>
> -
> +#include <linux/entry-kvm.h>
>  #include <linux/types.h>
>  #include <linux/hardirq.h>
>  #include <linux/list.h>
> @@ -2293,6 +2293,17 @@ static inline void kvm_handle_signal_exit(struct kvm_vcpu *vcpu)
>         vcpu->run->exit_reason = KVM_EXIT_INTR;
>         vcpu->stat.signal_exits++;
>  }
> +
> +static inline int kvm_xfer_to_guest_mode_handle_work(struct kvm_vcpu *vcpu)
> +{
> +       int r = xfer_to_guest_mode_handle_work();
> +
> +       if (r) {
> +               WARN_ON_ONCE(r != -EINTR);
> +               kvm_handle_signal_exit(vcpu);
> +       }
> +       return r;
> +}
>  #endif /* CONFIG_KVM_XFER_TO_GUEST_WORK */
>
>  /*
> diff --git a/kernel/entry/kvm.c b/kernel/entry/kvm.c
> index c2fc39824157..872617468b4a 100644
> --- a/kernel/entry/kvm.c
> +++ b/kernel/entry/kvm.c
> @@ -1,17 +1,14 @@
>  // SPDX-License-Identifier: GPL-2.0
>
>  #include <linux/entry-kvm.h>
> -#include <linux/kvm_host.h>
>
> -static int xfer_to_guest_mode_work(struct kvm_vcpu *vcpu, unsigned long ti_work)
> +static int xfer_to_guest_mode_work(unsigned long ti_work)
>  {
>         do {
>                 int ret;
>
> -               if (ti_work & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL)) {
> -                       kvm_handle_signal_exit(vcpu);
> +               if (ti_work & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL))
>                         return -EINTR;
> -               }
>
>                 if (ti_work & _TIF_NEED_RESCHED)
>                         schedule();
> @@ -28,7 +25,7 @@ static int xfer_to_guest_mode_work(struct kvm_vcpu *vcpu, unsigned long ti_work)
>         return 0;
>  }
>
> -int xfer_to_guest_mode_handle_work(struct kvm_vcpu *vcpu)
> +int xfer_to_guest_mode_handle_work(void)
>  {
>         unsigned long ti_work;
>
> @@ -44,6 +41,6 @@ int xfer_to_guest_mode_handle_work(struct kvm_vcpu *vcpu)
>         if (!(ti_work & XFER_TO_GUEST_MODE_WORK))
>                 return 0;
>
> -       return xfer_to_guest_mode_work(vcpu, ti_work);
> +       return xfer_to_guest_mode_work(ti_work);
>  }
>  EXPORT_SYMBOL_GPL(xfer_to_guest_mode_handle_work);
> --
> 2.42.0.459.ge4e396fd5e-goog
>


From anup at brainfault.org  Wed Dec 13 22:20:00 2023
From: anup at brainfault.org (Anup Patel)
Date: Thu, 14 Dec 2023 11:50:00 +0530
Subject: [PATCH 26/26] KVM: Hide KVM internal data structures and values
 from kernel at-large
In-Reply-To: <20230916003118.2540661-27-seanjc@google.com>
References: <20230916003118.2540661-1-seanjc@google.com> <20230916003118.2540661-27-seanjc@google.com>
Message-ID: <CAAhSdy1mxY23+AU99wSmbCcr6yGHrdRGDqAVehzuD-TEJuK_OQ@mail.gmail.com>

On Sat, Sep 16, 2023 at 6:02?AM Sean Christopherson <seanjc at google.com> wrote:
>
> Wrap all KVM internal APIs, data structures, values, etc. in public
> headers with "#ifdef __KVM__" to effectively hide KVM's internal details
> from other subsystems and the kernel at-large.  Hiding KVM details for
> all architectures will, in the very distant future, allow loading a new
> (or old) KVM module without needing to rebuild and reboot the entire
> kernel, or to even allow loading and running multiple versions of KVM
> simultaneously on a single host.
>
> To allow different instances of KVM modules to freely modify KVM data
> structures, enums, #defines, etc., e.g. the struct kvm_vcpu layout, there
> must be exactly zero dereferences of KVM-defined structures/values in
> non-KVM code (excepting code for architectures that don't support such
> shenanigans).  Any such references could lead to latent bugs, e.g. as the
> kernel would think a KVM structure has layout X, but in reality the
> current incarnation of KVM uses layout Y.
>
> In KVM x86, all remaining non-KVM references to KVM details have been now
> eliminated.  To harden KVM against new references being introduced, hide
> KVM's details to ensure that KVM doesn?t create a de facto ABI with the
> rest of the kernel.
>
> Use #ifdeffery to hide KVM details as doing so requires, by far, the least
> amount of churn and impact on architectures that freely share select KVM
> details with the rest of the kernel, e.g. s390, ARM64 and PPC, have
> significant usage of KVM-defined APIs, structures, values, etc.  E.g.
> attempting to extract the "private" chunks into dedicated KVM-internal
> headers would require massive churn, even on x86, and it's not obvious the
> end result would be a net positive (all attempts at moving code around
> failed long before getting anywhere near compiling cleanly).
>
> Another (bad) alternative that would be relative churn-free would be to
> move the KVM headers to a dedicated KVM-specific path while maintaining
> the generic layout, e.g. something like virt/kvm/include/linux.  That
> would allow x86 to simply omit the KVM-specific include path.  But that
> would require modifying the global include path, i.e. would make KVM a
> really special snowflake and set the awful precedent that it's "ok" to
> add subsystem specific directories to the global include path.
>
> Grant exceptions to asm-offsets.c as needed, and to s390's VFIO AP driver.
> Creating a KVM-specific asm-offsets, as was done for x86, adds no value
> (x86 did so to avoid exposing vendor specific headers) and doesn't create
> much of a "slippery slope" risk.  s390's VFIO AP driver on the other hand
> is simply too intertwined with KVM to realistically treat it as anything
> other than KVM code, despite it living in crypto drivers, e.g. the driver
> has some rather crazy lock ordering rules between the device and KVM.
>
> Add a static assert that __KVM__ is defined in trace/events/kvm.h, as that
> is effectively a private KVM header that just happens to live in a public
> path.
>
> Shuffle a few PPC includes and an s390 declaration as needed, and
> opportunistically include kvm_host.h in trace/events.kvm.h instead of
> relying on the parent to provide the right includes.
>
> Cc: Anish Ghulati <aghulati at google.com>
> Cc: Venkatesh Srinivas <venkateshs at chromium.org>
> Cc: Andrew Thornton <andrewth at google.com>
> Signed-off-by: Sean Christopherson <seanjc at google.com>

For KVM RISC-V:
Anup Patel <anup at brainfault.org>

Regards,
Anup

> ---
>  arch/arm64/include/asm/kvm_emulate.h     | 3 +++
>  arch/arm64/include/asm/kvm_host.h        | 2 ++
>  arch/arm64/include/asm/kvm_mmu.h         | 4 ++++
>  arch/arm64/kernel/asm-offsets.c          | 2 ++
>  arch/arm64/kvm/hyp/Makefile              | 2 +-
>  arch/arm64/kvm/hyp/nvhe/Makefile         | 3 ++-
>  arch/arm64/kvm/hyp/vhe/Makefile          | 2 +-
>  arch/mips/include/asm/kvm_host.h         | 2 ++
>  arch/mips/kernel/asm-offsets.c           | 2 ++
>  arch/powerpc/include/asm/kvm_book3s.h    | 3 +++
>  arch/powerpc/include/asm/kvm_book3s_64.h | 2 ++
>  arch/powerpc/include/asm/kvm_booke.h     | 4 ++++
>  arch/powerpc/include/asm/kvm_host.h      | 7 ++++---
>  arch/powerpc/include/asm/kvm_ppc.h       | 2 ++
>  arch/powerpc/kernel/asm-offsets.c        | 1 +
>  arch/riscv/include/asm/kvm_host.h        | 3 +++
>  arch/riscv/kernel/asm-offsets.c          | 1 +
>  arch/s390/include/asm/kvm_host.h         | 7 +++++--
>  arch/s390/kernel/asm-offsets.c           | 1 +
>  arch/x86/include/asm/kvm_host.h          | 3 +++
>  drivers/s390/crypto/vfio_ap_drv.c        | 1 +
>  drivers/s390/crypto/vfio_ap_ops.c        | 2 ++
>  include/linux/kvm_host.h                 | 4 ++++
>  include/linux/kvm_types.h                | 3 +++
>  include/trace/events/kvm.h               | 5 +++++
>  virt/kvm/Makefile.kvm                    | 2 +-
>  26 files changed, 64 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 3d6725ff0bf6..5861fa00763b 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -21,6 +21,8 @@
>  #include <asm/cputype.h>
>  #include <asm/virt.h>
>
> +#ifdef __KVM__
> +
>  #define CURRENT_EL_SP_EL0_VECTOR       0x0
>  #define CURRENT_EL_SP_ELx_VECTOR       0x200
>  #define LOWER_EL_AArch64_VECTOR                0x400
> @@ -615,4 +617,5 @@ static __always_inline void kvm_reset_cptr_el2(struct kvm_vcpu *vcpu)
>
>         kvm_write_cptr_el2(val);
>  }
> +#endif /* __KVM__ */
>  #endif /* __ARM64_KVM_EMULATE_H__ */
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 89b40c34f0af..ba4065db5d5c 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -93,6 +93,7 @@ static inline bool kvm_pmu_counter_deferred(struct perf_event_attr *attr)
>         return (!has_vhe() && attr->exclude_host);
>  }
>
> +#ifdef __KVM__
>  DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
>  extern unsigned int __ro_after_init kvm_sve_max_vl;
> @@ -1149,4 +1150,5 @@ int kvm_trng_call(struct kvm_vcpu *vcpu);
>  void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu);
>  bool kvm_arm_vcpu_stopped(struct kvm_vcpu *vcpu);
>
> +#endif /* __KVM__ */
>  #endif /* __ARM64_KVM_HOST_H__ */
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 96a80e8f6226..9d8c92cda3b6 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -125,6 +125,8 @@ void kvm_update_va_mask(struct alt_instr *alt,
>  void kvm_compute_layout(void);
>  void kvm_apply_hyp_relocations(void);
>
> +#ifdef __KVM__
> +
>  #define __hyp_pa(x) (((phys_addr_t)(x)) + hyp_physvirt_offset)
>
>  static __always_inline unsigned long __kern_hyp_va(unsigned long v)
> @@ -314,5 +316,7 @@ static inline struct kvm *kvm_s2_mmu_to_kvm(struct kvm_s2_mmu *mmu)
>  {
>         return container_of(mmu->arch, struct kvm, arch);
>  }
> +
> +#endif /* __KVM__ */
>  #endif /* __ASSEMBLY__ */
>  #endif /* __ARM64_KVM_MMU_H__ */
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 5ff1942b04fc..dc02ea9a002c 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -7,6 +7,8 @@
>   * Copyright (C) 2012 ARM Ltd.
>   */
>
> +#define __KVM__
> +
>  #include <linux/arm_sdei.h>
>  #include <linux/sched.h>
>  #include <linux/ftrace.h>
> diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
> index 4ce8c86967b5..99982b75671a 100644
> --- a/arch/arm64/kvm/hyp/Makefile
> +++ b/arch/arm64/kvm/hyp/Makefile
> @@ -5,6 +5,6 @@
>
>  incdir := $(srctree)/$(src)/include
>  subdir-asflags-y := -I$(incdir) -I$(srctree)/arch/arm64/kvm
> -subdir-ccflags-y := -I$(incdir) -I$(srctree)/arch/arm64/kvm
> +subdir-ccflags-y := -I$(incdir) -I$(srctree)/arch/arm64/kvm -D__KVM__
>
>  obj-$(CONFIG_KVM) += vhe/ nvhe/ pgtable.o
> diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
> index 2250253a6429..b5f4750fa16e 100644
> --- a/arch/arm64/kvm/hyp/nvhe/Makefile
> +++ b/arch/arm64/kvm/hyp/nvhe/Makefile
> @@ -9,7 +9,8 @@ asflags-y := -D__KVM_NVHE_HYPERVISOR__ -D__DISABLE_EXPORTS
>  # there is no way to execute them and any such MMIO access from nVHE KVM
>  # will explode instantly (Words of Marc Zyngier). So introduce a generic flag
>  # __DISABLE_TRACE_MMIO__ to disable MMIO tracing for nVHE KVM.
> -ccflags-y := -D__KVM_NVHE_HYPERVISOR__ -D__DISABLE_EXPORTS -D__DISABLE_TRACE_MMIO__
> +ccflags-y := -D__KVM_NVHE_HYPERVISOR__ -D__DISABLE_EXPORTS \
> +            -D__DISABLE_TRACE_MMIO__  -D__KVM__
>  ccflags-y += -fno-stack-protector      \
>              -DDISABLE_BRANCH_PROFILING \
>              $(DISABLE_STACKLEAK_PLUGIN)
> diff --git a/arch/arm64/kvm/hyp/vhe/Makefile b/arch/arm64/kvm/hyp/vhe/Makefile
> index 3b9e5464b5b3..54cd3c444102 100644
> --- a/arch/arm64/kvm/hyp/vhe/Makefile
> +++ b/arch/arm64/kvm/hyp/vhe/Makefile
> @@ -4,7 +4,7 @@
>  #
>
>  asflags-y := -D__KVM_VHE_HYPERVISOR__
> -ccflags-y := -D__KVM_VHE_HYPERVISOR__
> +ccflags-y := -D__KVM_VHE_HYPERVISOR__ -D__KVM__
>
>  obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o
>  obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
> diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
> index f8f63d0aa399..6fd7c998d7b9 100644
> --- a/arch/mips/include/asm/kvm_host.h
> +++ b/arch/mips/include/asm/kvm_host.h
> @@ -25,6 +25,7 @@
>  #include <asm/inst.h>
>  #include <asm/mipsregs.h>
>
> +#ifdef __KVM__
>  /* MIPS KVM register ids */
>  #define MIPS_CP0_32(_R, _S)                                    \
>         (KVM_REG_MIPS_CP0 | KVM_REG_SIZE_U32 | (8 * (_R) + (_S)))
> @@ -897,4 +898,5 @@ static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
>
>  #define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS
>
> +#endif /* __KVM__ */
>  #endif /* __MIPS_KVM_HOST_H__ */
> diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c
> index d1b11f66f748..8a233bddfea0 100644
> --- a/arch/mips/kernel/asm-offsets.c
> +++ b/arch/mips/kernel/asm-offsets.c
> @@ -9,6 +9,8 @@
>   * Kevin Kissell, kevink at mips.com and Carsten Langgaard, carstenl at mips.com
>   * Copyright (C) 2000 MIPS Technologies, Inc.
>   */
> +#define __KVM__
> +
>  #include <linux/compat.h>
>  #include <linux/types.h>
>  #include <linux/sched.h>
> diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
> index bbf5e2c5fe09..8880bc7c8a32 100644
> --- a/arch/powerpc/include/asm/kvm_book3s.h
> +++ b/arch/powerpc/include/asm/kvm_book3s.h
> @@ -13,6 +13,8 @@
>  #include <linux/kvm_host.h>
>  #include <asm/kvm_book3s_asm.h>
>
> +#ifdef __KVM__
> +
>  struct kvmppc_bat {
>         u64 raw;
>         u32 bepi;
> @@ -483,4 +485,5 @@ static inline u32 kvmppc_pack_vcpu_id(struct kvm *kvm, u32 id)
>         return packed_id;
>  }
>
> +#endif /* __KVM__ */
>  #endif /* __ASM_KVM_BOOK3S_H__ */
> diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
> index d49065af08e9..a807716ccae6 100644
> --- a/arch/powerpc/include/asm/kvm_book3s_64.h
> +++ b/arch/powerpc/include/asm/kvm_book3s_64.h
> @@ -16,6 +16,7 @@
>  #include <asm/ppc-opcode.h>
>  #include <asm/pte-walk.h>
>
> +#ifdef __KVM__
>  /*
>   * Structure for a nested guest, that is, for a guest that is managed by
>   * one of our guests.
> @@ -679,4 +680,5 @@ extern pte_t *find_kvm_nested_guest_pte(struct kvm *kvm, unsigned long lpid,
>
>  #endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
>
> +#endif /* __KVM__ */
>  #endif /* __ASM_KVM_BOOK3S_64_H__ */
> diff --git a/arch/powerpc/include/asm/kvm_booke.h b/arch/powerpc/include/asm/kvm_booke.h
> index 0c3401b2e19e..85ebc0314539 100644
> --- a/arch/powerpc/include/asm/kvm_booke.h
> +++ b/arch/powerpc/include/asm/kvm_booke.h
> @@ -12,6 +12,8 @@
>  #include <linux/types.h>
>  #include <linux/kvm_host.h>
>
> +#ifdef __KVM__
> +
>  /*
>   * Number of available lpids. Only the low-order 6 bits of LPID rgister are
>   * implemented on e500mc+ cores.
> @@ -105,4 +107,6 @@ static inline bool kvmppc_supports_magic_page(struct kvm_vcpu *vcpu)
>         return false;
>  #endif
>  }
> +
> +#endif /* __KVM__ */
>  #endif /* __ASM_KVM_BOOKE_H__ */
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 14ee0dece853..1e7a008ce085 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -14,6 +14,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/types.h>
>  #include <linux/kvm_types.h>
> +#include <linux/mmu_notifier.h>
>  #include <linux/threads.h>
>  #include <linux/spinlock.h>
>  #include <linux/kvm_para.h>
> @@ -25,13 +26,14 @@
>  #include <asm/cacheflush.h>
>  #include <asm/hvcall.h>
>  #include <asm/mce.h>
> +#include <asm/cputhreads.h>
>
> +#ifdef __KVM__
>  #define __KVM_HAVE_ARCH_VCPU_DEBUGFS
>
>  #define KVM_MAX_VCPUS          NR_CPUS
>  #define KVM_MAX_VCORES         NR_CPUS
>
> -#include <asm/cputhreads.h>
>
>  #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
>  #include <asm/kvm_book3s_asm.h>                /* for MAX_SMT_THREADS */
> @@ -60,8 +62,6 @@
>  #define KVM_REQ_EPR_EXIT       KVM_ARCH_REQ(1)
>  #define KVM_REQ_PENDING_TIMER  KVM_ARCH_REQ(2)
>
> -#include <linux/mmu_notifier.h>
> -
>  #define KVM_ARCH_WANT_MMU_NOTIFIER
>
>  #define HPTEG_CACHE_NUM                        (1 << 15)
> @@ -883,4 +883,5 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
>  static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
>
> +#endif /* __KVM__ */
>  #endif /* __POWERPC_KVM_HOST_H__ */
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index ead2ad892ebc..03d9998d0111 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -183,6 +183,7 @@ static inline void kvmppc_clear_host_ipi(int cpu)
>  static inline bool kvm_hv_mode_active(void)            { return false; }
>  #endif
>
> +#ifdef __KVM__
>  /*
>   * KVMPPC_INST_SW_BREAKPOINT is debug Instruction
>   * for supporting software breakpoint.
> @@ -1076,4 +1077,5 @@ static inline ulong kvmppc_get_ea_indexed(struct kvm_vcpu *vcpu, int ra, int rb)
>         return ea;
>  }
>
> +#endif /* __KVM__ */
>  #endif /* __POWERPC_KVM_PPC_H__ */
> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
> index 9f14d95b8b32..872d44971536 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -8,6 +8,7 @@
>   * compile this file to assembler, and then extract the
>   * #defines from the assembly-language output.
>   */
> +#define __KVM__
>
>  #include <linux/compat.h>
>  #include <linux/signal.h>
> diff --git a/arch/riscv/include/asm/kvm_host.h b/arch/riscv/include/asm/kvm_host.h
> index 1ebf20dfbaa6..a81ae8c4b739 100644
> --- a/arch/riscv/include/asm/kvm_host.h
> +++ b/arch/riscv/include/asm/kvm_host.h
> @@ -22,6 +22,8 @@
>  #include <asm/kvm_vcpu_timer.h>
>  #include <asm/kvm_vcpu_pmu.h>
>
> +#ifdef __KVM__
> +
>  #define KVM_MAX_VCPUS                  1024
>
>  #define KVM_HALT_POLL_NS_DEFAULT       500000
> @@ -354,4 +356,5 @@ bool kvm_riscv_vcpu_has_interrupts(struct kvm_vcpu *vcpu, u64 mask);
>  void kvm_riscv_vcpu_power_off(struct kvm_vcpu *vcpu);
>  void kvm_riscv_vcpu_power_on(struct kvm_vcpu *vcpu);
>
> +#endif /* __KVM__ */
>  #endif /* __RISCV_KVM_HOST_H__ */
> diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
> index d6a75aac1d27..476263e78f39 100644
> --- a/arch/riscv/kernel/asm-offsets.c
> +++ b/arch/riscv/kernel/asm-offsets.c
> @@ -5,6 +5,7 @@
>   */
>
>  #define GENERATING_ASM_OFFSETS
> +#define __KVM__
>
>  #include <linux/kbuild.h>
>  #include <linux/mm.h>
> diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
> index 427f9528a7b6..9153420bb5ac 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -380,6 +380,10 @@ struct sie_page {
>         __u8 reserved700[2304];         /* 0x0700 */
>  };
>
> +extern char sie_exit;
> +
> +#ifdef __KVM__
> +
>  struct kvm_vcpu_stat {
>         struct kvm_vcpu_stat_generic generic;
>         u64 exit_userspace;
> @@ -1028,8 +1032,6 @@ static inline int sie64a(struct kvm_s390_sie_block *sie_block, u64 *rsa)
>         return __sie64a(virt_to_phys(sie_block), sie_block, rsa);
>  }
>
> -extern char sie_exit;
> -
>  bool kvm_s390_pv_is_protected(struct kvm *kvm);
>  bool kvm_s390_pv_cpu_is_protected(struct kvm_vcpu *vcpu);
>
> @@ -1049,6 +1051,7 @@ static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
>
>  #define __KVM_HAVE_ARCH_VM_FREE
>  void kvm_arch_free_vm(struct kvm *kvm);
> +#endif /* __KVM__ */
>
>  struct zpci_kvm_hook {
>         int (*kvm_register)(void *opaque, struct kvm *kvm);
> diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
> index fa5f6885c74a..22ed673871ee 100644
> --- a/arch/s390/kernel/asm-offsets.c
> +++ b/arch/s390/kernel/asm-offsets.c
> @@ -6,6 +6,7 @@
>   */
>
>  #define ASM_OFFSETS_C
> +#define __KVM__
>
>  #include <linux/kbuild.h>
>  #include <linux/kvm_host.h>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 29db870dbaae..eda45a937666 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -37,6 +37,8 @@
>  #include <asm/kvm_vcpu_regs.h>
>  #include <asm/hyperv-tlfs.h>
>
> +#ifdef __KVM__
> +
>  #define __KVM_HAVE_ARCH_VCPU_DEBUGFS
>
>  #define KVM_MAX_VCPUS 1024
> @@ -2229,4 +2231,5 @@ int memslot_rmap_alloc(struct kvm_memory_slot *slot, unsigned long npages);
>   */
>  #define KVM_EXIT_HYPERCALL_MBZ         GENMASK_ULL(31, 1)
>
> +#endif /* __KVM__ */
>  #endif /* _ASM_X86_KVM_HOST_H */
> diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
> index a5ab03e42ff1..55744f0f4758 100644
> --- a/drivers/s390/crypto/vfio_ap_drv.c
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -7,6 +7,7 @@
>   * Author(s): Tony Krowiak <akrowiak at linux.ibm.com>
>   *           Pierre Morel <pmorel at linux.ibm.com>
>   */
> +#define __KVM__
>
>  #include <linux/module.h>
>  #include <linux/mod_devicetable.h>
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 4db538a55192..0dd98f42e9d5 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -8,6 +8,8 @@
>   *           Halil Pasic <pasic at linux.ibm.com>
>   *           Pierre Morel <pmorel at linux.ibm.com>
>   */
> +#define __KVM__
> +
>  #include <linux/string.h>
>  #include <linux/vfio.h>
>  #include <linux/device.h>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d520d6801070..f0afe549c0d6 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -45,6 +45,8 @@
>  #include <asm/kvm_host.h>
>  #include <linux/kvm_dirty_ring.h>
>
> +#ifdef __KVM__
> +
>  #ifndef KVM_MAX_VCPU_IDS
>  #define KVM_MAX_VCPU_IDS KVM_MAX_VCPUS
>  #endif
> @@ -2329,4 +2331,6 @@ static inline void kvm_account_pgtable_pages(void *virt, int nr)
>  /* Max number of entries allowed for each kvm dirty ring */
>  #define  KVM_DIRTY_RING_MAX_ENTRIES  65536
>
> +#endif /* __KVM__ */
> +
>  #endif
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index 6f4737d5046a..4804bce2a655 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@ -48,6 +48,8 @@ typedef u64            hfn_t;
>
>  typedef hfn_t kvm_pfn_t;
>
> +#ifdef __KVM__
> +
>  enum pfn_cache_usage {
>         KVM_GUEST_USES_PFN = BIT(0),
>         KVM_HOST_USES_PFN  = BIT(1),
> @@ -123,4 +125,5 @@ struct kvm_vcpu_stat_generic {
>
>  #define KVM_STATS_NAME_SIZE    48
>
> +#endif /* __KVM__ */
>  #endif /* __KVM_TYPES_H__ */
> diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
> index 3bd31ea23fee..aee85527bb74 100644
> --- a/include/trace/events/kvm.h
> +++ b/include/trace/events/kvm.h
> @@ -2,8 +2,13 @@
>  #if !defined(_TRACE_KVM_MAIN_H) || defined(TRACE_HEADER_MULTI_READ)
>  #define _TRACE_KVM_MAIN_H
>
> +#include <linux/kvm_host.h>
>  #include <linux/tracepoint.h>
>
> +#ifndef __KVM__
> +static_assert(0, "Do not include trace/events/kvm.h from non-KVM code");
> +#endif
> +
>  #undef TRACE_SYSTEM
>  #define TRACE_SYSTEM kvm
>
> diff --git a/virt/kvm/Makefile.kvm b/virt/kvm/Makefile.kvm
> index e85079ad245d..4de10d447ef3 100644
> --- a/virt/kvm/Makefile.kvm
> +++ b/virt/kvm/Makefile.kvm
> @@ -3,7 +3,7 @@
>  # Makefile for Kernel-based Virtual Machine module
>  #
>
> -ccflags-y += -I$(srctree)/$(src)
> +ccflags-y += -I$(srctree)/$(src) -D__KVM__
>
>  KVM ?= ../../../virt/kvm
>
> --
> 2.42.0.459.ge4e396fd5e-goog
>


From sunnanyong at huawei.com  Wed Dec 13 23:39:09 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Thu, 14 Dec 2023 15:39:09 +0800
Subject: [PATCH 0/3] A Solution to Re-enable hugetlb vmemmap optimize on Arm
Message-ID: <20231214073912.1938330-1-sunnanyong@huawei.com>

HVO was previously disabled on arm64 [1] due to the lack of necessary
BBM(break-before-make) logic when changing page tables.
This set of patches fix this by adding necessary BBM sequence when
changing page table, and supporting vmemmap page fault handling to
fixup kernel address fault if vmemmap is concurrently accessed.

[1] commit 060a2c92d1b6 ("arm64: mm: hugetlb: Disable HUGETLB_PAGE_OPTIMIZE_VMEMMAP")

Nanyong Sun (3):
  mm: HVO: introduce helper function to update and flush pgtable
  arm64: mm: HVO: support BBM of vmemmap pgtable safely
  arm64: mm: Re-enable OPTIMIZE_HUGETLB_VMEMMAP

 arch/arm64/Kconfig           |  1 +
 arch/arm64/include/asm/esr.h |  4 ++
 arch/arm64/include/asm/mmu.h | 20 ++++++++
 arch/arm64/mm/fault.c        | 94 ++++++++++++++++++++++++++++++++++++
 arch/arm64/mm/mmu.c          | 28 +++++++++++
 mm/hugetlb_vmemmap.c         | 55 ++++++++++++++++-----
 6 files changed, 190 insertions(+), 12 deletions(-)

-- 
2.25.1



From sunnanyong at huawei.com  Wed Dec 13 23:39:12 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Thu, 14 Dec 2023 15:39:12 +0800
Subject: [PATCH 3/3] arm64: mm: Re-enable OPTIMIZE_HUGETLB_VMEMMAP
In-Reply-To: <20231214073912.1938330-1-sunnanyong@huawei.com>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
Message-ID: <20231214073912.1938330-4-sunnanyong@huawei.com>

Now update of vmemmap page table can follow the rule of
break-before-make safely for arm64 architecture, re-enable
HVO on arm64.

Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..43e3d5576fb2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -103,6 +103,7 @@ config ARM64
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
 	select ARCH_WANT_FRAME_POINTERS
 	select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
+	select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
 	select ARCH_WANT_LD_ORPHAN_WARN
 	select ARCH_WANTS_NO_INSTR
 	select ARCH_WANTS_THP_SWAP if ARM64_4K_PAGES
-- 
2.25.1



From sunnanyong at huawei.com  Wed Dec 13 23:39:10 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Thu, 14 Dec 2023 15:39:10 +0800
Subject: [PATCH 1/3] mm: HVO: introduce helper function to update and flush pgtable
In-Reply-To: <20231214073912.1938330-1-sunnanyong@huawei.com>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
Message-ID: <20231214073912.1938330-2-sunnanyong@huawei.com>

Add pmd/pte update and tlb flush helper function to update page
table. This refactoring patch is designed to facilitate each
architecture to implement its own special logic in preparation
for the arm64 architecture to follow the necessary break-before-make
sequence when updating page tables.

Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
---
 mm/hugetlb_vmemmap.c | 55 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 43 insertions(+), 12 deletions(-)

diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
index 87818ee7f01d..49e8b351def3 100644
--- a/mm/hugetlb_vmemmap.c
+++ b/mm/hugetlb_vmemmap.c
@@ -45,6 +45,37 @@ struct vmemmap_remap_walk {
 	unsigned long		flags;
 };
 
+#ifndef vmemmap_update_pmd
+static inline void vmemmap_update_pmd(unsigned long start,
+				      pmd_t *pmd, pte_t *pgtable)
+{
+	pmd_populate_kernel(&init_mm, pmd, pgtable);
+}
+#endif
+
+#ifndef vmemmap_update_pte
+static inline void vmemmap_update_pte(unsigned long addr,
+				      pte_t *pte, pte_t entry)
+{
+	set_pte_at(&init_mm, addr, pte, entry);
+}
+#endif
+
+#ifndef flush_tlb_vmemmap_all
+static inline void flush_tlb_vmemmap_all(void)
+{
+	flush_tlb_all();
+}
+#endif
+
+#ifndef flush_tlb_vmemmap_range
+static inline void flush_tlb_vmemmap_range(unsigned long start,
+					   unsigned long end)
+{
+	flush_tlb_kernel_range(start, end);
+}
+#endif
+
 static int split_vmemmap_huge_pmd(pmd_t *pmd, unsigned long start, bool flush)
 {
 	pmd_t __pmd;
@@ -87,9 +118,9 @@ static int split_vmemmap_huge_pmd(pmd_t *pmd, unsigned long start, bool flush)
 
 		/* Make pte visible before pmd. See comment in pmd_install(). */
 		smp_wmb();
-		pmd_populate_kernel(&init_mm, pmd, pgtable);
+		vmemmap_update_pmd(start, pmd, pgtable);
 		if (flush)
-			flush_tlb_kernel_range(start, start + PMD_SIZE);
+			flush_tlb_vmemmap_range(start, start + PMD_SIZE);
 	} else {
 		pte_free_kernel(&init_mm, pgtable);
 	}
@@ -217,7 +248,7 @@ static int vmemmap_remap_range(unsigned long start, unsigned long end,
 	} while (pgd++, addr = next, addr != end);
 
 	if (walk->remap_pte && !(walk->flags & VMEMMAP_REMAP_NO_TLB_FLUSH))
-		flush_tlb_kernel_range(start, end);
+		flush_tlb_vmemmap_range(start, end);
 
 	return 0;
 }
@@ -263,15 +294,15 @@ static void vmemmap_remap_pte(pte_t *pte, unsigned long addr,
 
 		/*
 		 * Makes sure that preceding stores to the page contents from
-		 * vmemmap_remap_free() become visible before the set_pte_at()
-		 * write.
+		 * vmemmap_remap_free() become visible before the
+		 * vmemmap_update_pte() write.
 		 */
 		smp_wmb();
 	}
 
 	entry = mk_pte(walk->reuse_page, pgprot);
 	list_add(&page->lru, walk->vmemmap_pages);
-	set_pte_at(&init_mm, addr, pte, entry);
+	vmemmap_update_pte(addr, pte, entry);
 }
 
 /*
@@ -310,10 +341,10 @@ static void vmemmap_restore_pte(pte_t *pte, unsigned long addr,
 
 	/*
 	 * Makes sure that preceding stores to the page contents become visible
-	 * before the set_pte_at() write.
+	 * before the vmemmap_update_pte() write.
 	 */
 	smp_wmb();
-	set_pte_at(&init_mm, addr, pte, mk_pte(page, pgprot));
+	vmemmap_update_pte(addr, pte, mk_pte(page, pgprot));
 }
 
 /**
@@ -576,7 +607,7 @@ long hugetlb_vmemmap_restore_folios(const struct hstate *h,
 	}
 
 	if (restored)
-		flush_tlb_all();
+		flush_tlb_vmemmap_all();
 	if (!ret)
 		ret = restored;
 	return ret;
@@ -744,7 +775,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
 			break;
 	}
 
-	flush_tlb_all();
+	flush_tlb_vmemmap_all();
 
 	list_for_each_entry(folio, folio_list, lru) {
 		int ret = __hugetlb_vmemmap_optimize_folio(h, folio,
@@ -760,7 +791,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
 		 * allowing more vmemmap remaps to occur.
 		 */
 		if (ret == -ENOMEM && !list_empty(&vmemmap_pages)) {
-			flush_tlb_all();
+			flush_tlb_vmemmap_all();
 			free_vmemmap_page_list(&vmemmap_pages);
 			INIT_LIST_HEAD(&vmemmap_pages);
 			__hugetlb_vmemmap_optimize_folio(h, folio,
@@ -769,7 +800,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
 		}
 	}
 
-	flush_tlb_all();
+	flush_tlb_vmemmap_all();
 	free_vmemmap_page_list(&vmemmap_pages);
 }
 
-- 
2.25.1



From sunnanyong at huawei.com  Wed Dec 13 23:39:11 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Thu, 14 Dec 2023 15:39:11 +0800
Subject: [PATCH 2/3] arm64: mm: HVO: support BBM of vmemmap pgtable safely
In-Reply-To: <20231214073912.1938330-1-sunnanyong@huawei.com>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
Message-ID: <20231214073912.1938330-3-sunnanyong@huawei.com>

Implement vmemmap_update_pmd and vmemmap_update_pte on arm64 to do
BBM(break-before-make) logic when change the page table of vmemmap
address, they will under the init_mm.page_table_lock.
If a translation fault of vmemmap address concurrently happened after
pte/pmd cleared, vmemmap page fault handler will acquire the
init_mm.page_table_lock to wait for vmemmap update to complete,
by then the virtual address is valid again, so PF can return and
access can continue.
In other case, do the traditional kernel fault.

Implement flush_tlb_vmemmap_all and flush_tlb_vmemmap_range on arm64
with nothing to do because tlb already flushed in every single BBM.

Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
---
 arch/arm64/include/asm/esr.h |  4 ++
 arch/arm64/include/asm/mmu.h | 20 ++++++++
 arch/arm64/mm/fault.c        | 94 ++++++++++++++++++++++++++++++++++++
 arch/arm64/mm/mmu.c          | 28 +++++++++++
 4 files changed, 146 insertions(+)

diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index ae35939f395b..1c63256efd25 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -116,6 +116,10 @@
 #define ESR_ELx_FSC_SERROR	(0x11)
 #define ESR_ELx_FSC_ACCESS	(0x08)
 #define ESR_ELx_FSC_FAULT	(0x04)
+#define ESR_ELx_FSC_FAULT_L0    (0x04)
+#define ESR_ELx_FSC_FAULT_L1    (0x05)
+#define ESR_ELx_FSC_FAULT_L2    (0x06)
+#define ESR_ELx_FSC_FAULT_L3    (0x07)
 #define ESR_ELx_FSC_PERM	(0x0C)
 #define ESR_ELx_FSC_SEA_TTW0	(0x14)
 #define ESR_ELx_FSC_SEA_TTW1	(0x15)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 2fcf51231d6e..fcec5827f54f 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -76,5 +76,25 @@ extern bool kaslr_requires_kpti(void);
 #define INIT_MM_CONTEXT(name)	\
 	.pgd = init_pg_dir,
 
+#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
+void vmemmap_update_pmd(unsigned long start, pmd_t *pmd, pte_t *pgtable);
+#define vmemmap_update_pmd vmemmap_update_pmd
+void vmemmap_update_pte(unsigned long addr, pte_t *pte, pte_t entry);
+#define vmemmap_update_pte vmemmap_update_pte
+
+static inline void flush_tlb_vmemmap_all(void)
+{
+	/* do nothing, already flushed tlb in every single BBM */
+}
+#define flush_tlb_vmemmap_all flush_tlb_vmemmap_all
+
+static inline void flush_tlb_vmemmap_range(unsigned long start,
+					   unsigned long end)
+{
+	/* do nothing, already flushed tlb in every single BBM */
+}
+#define flush_tlb_vmemmap_range flush_tlb_vmemmap_range
+#endif
+
 #endif	/* !__ASSEMBLY__ */
 #endif
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 460d799e1296..7066a273c1e0 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -368,6 +368,97 @@ static bool is_el1_mte_sync_tag_check_fault(unsigned long esr)
 	return false;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
+static inline bool is_vmemmap_address(unsigned long addr)
+{
+	return (addr >= VMEMMAP_START) && (addr < VMEMMAP_END);
+}
+
+static inline bool vmemmap_fault_may_fixup(unsigned long addr,
+					   unsigned long esr)
+{
+	if (!is_vmemmap_address(addr))
+		return false;
+
+	/*
+	 * Only try to handle translation fault level 2 or level 3,
+	 * because hugetlb vmemmap optimize only clear pmd or pte.
+	 */
+	switch (esr & ESR_ELx_FSC) {
+	case ESR_ELx_FSC_FAULT_L2:
+	case ESR_ELx_FSC_FAULT_L3:
+		return true;
+	default:
+		return false;
+	}
+}
+
+/*
+ * PMD mapped vmemmap should has been split as PTE mapped
+ * by HVO now, here we only check this case, other cases
+ * should fail.
+ * Also should check the addr is healthy enough that will not cause
+ * a level2 or level3 translation fault again after page fault
+ * handled with success, so we need check both bits[1:0] of PMD and
+ * PTE as ARM Spec mentioned below:
+ * A Translation fault is generated if bits[1:0] of a translation
+ * table descriptor identify the descriptor as either a Fault
+ * encoding or a reserved encoding.
+ */
+static inline bool vmemmap_addr_healthy(unsigned long addr)
+{
+	pgd_t *pgdp;
+	p4d_t *p4dp;
+	pud_t *pudp, pud;
+	pmd_t *pmdp, pmd;
+	pte_t *ptep, pte;
+
+	pgdp = pgd_offset_k(addr);
+	if (pgd_none(READ_ONCE(*pgdp)))
+		return false;
+
+	p4dp = p4d_offset(pgdp, addr);
+	if (p4d_none(READ_ONCE(*p4dp)))
+		return false;
+
+	pudp = pud_offset(p4dp, addr);
+	pud = READ_ONCE(*pudp);
+	if (pud_none(pud))
+		return false;
+
+	pmdp = pmd_offset(pudp, addr);
+	pmd = READ_ONCE(*pmdp);
+	if (!pmd_table(pmd))
+		return false;
+
+	ptep = pte_offset_kernel(pmdp, addr);
+	pte = READ_ONCE(*ptep);
+	return (pte_val(pte) & PTE_TYPE_MASK) == PTE_TYPE_PAGE;
+}
+
+static bool vmemmap_handle_page_fault(unsigned long addr,
+				      unsigned long esr)
+{
+	bool ret = false;
+
+	if (likely(!vmemmap_fault_may_fixup(addr, esr)))
+		return false;
+
+	spin_lock(&init_mm.page_table_lock);
+	if (vmemmap_addr_healthy(addr))
+		ret = true;
+	spin_unlock(&init_mm.page_table_lock);
+
+	return ret;
+}
+#else
+static inline bool vmemmap_handle_page_fault(unsigned long addr,
+					     unsigned long esr)
+{
+	return false;
+}
+#endif /*CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP */
+
 static bool is_translation_fault(unsigned long esr)
 {
 	return (esr & ESR_ELx_FSC_TYPE) == ESR_ELx_FSC_FAULT;
@@ -409,6 +500,9 @@ static void __do_kernel_fault(unsigned long addr, unsigned long esr,
 		    kfence_handle_page_fault(addr, esr & ESR_ELx_WNR, regs))
 			return;
 
+		if (vmemmap_handle_page_fault(addr, esr))
+			return;
+
 		msg = "paging request";
 	}
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 15f6347d23b6..81a600ccac7c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1146,6 +1146,34 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node,
 	return 1;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
+/*
+ * In the window between the page table entry is cleared and filled
+ * with a new value, other threads have the opportunity to concurrently
+ * access the vmemmap area then page translation fault occur.
+ * Therefore, we need to ensure that the init_mm.page_table_lock is held
+ * to synchronize the vmemmap page fault handling which will wait for
+ * this lock to be released to ensure that the page table entry has been
+ * refreshed with a new valid value.
+ */
+void vmemmap_update_pmd(unsigned long start, pmd_t *pmd, pte_t *pgtable)
+{
+	lockdep_assert_held(&init_mm.page_table_lock);
+	pmd_clear(pmd);
+	flush_tlb_kernel_range(start, start + PMD_SIZE);
+	pmd_populate_kernel(&init_mm, pmd, pgtable);
+}
+
+void vmemmap_update_pte(unsigned long addr, pte_t *pte, pte_t entry)
+{
+	spin_lock(&init_mm.page_table_lock);
+	pte_clear(&init_mm, addr, pte);
+	flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+	set_pte_at(&init_mm, addr, pte, entry);
+	spin_unlock(&init_mm.page_table_lock);
+}
+#endif
+
 int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
 		struct vmem_altmap *altmap)
 {
-- 
2.25.1



From anup at brainfault.org  Wed Dec 13 22:41:53 2023
From: anup at brainfault.org (Anup Patel)
Date: Thu, 14 Dec 2023 12:11:53 +0530
Subject: [PATCH v4 02/11] KVM: arm64: selftests: Split arch_timer test code
In-Reply-To: <636e8c3bf8b35be089182569621eaff331242d98.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com> <636e8c3bf8b35be089182569621eaff331242d98.1702371136.git.haibo1.xu@intel.com>
Message-ID: <CAAhSdy2=MbAS0evdVH0afB1OqNAH9e8_fLSyCmhAe-4_m4jo7w@mail.gmail.com>

Hi Marc, Hi Oliver,

On Tue, Dec 12, 2023 at 2:49?PM Haibo Xu <haibo1.xu at intel.com> wrote:
>
> Split the arch-neutral test code out of aarch64/arch_timer.c
> and put them into a common arch_timer.c. This is a preparation
> to share timer test codes in riscv.
>
> Suggested-by: Andrew Jones <ajones at ventanamicro.com>
> Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
> Reviewed-by: Andrew Jones <ajones at ventanamicro.com>

Can you please review this patch ?

We want to take this entire series through KVM RISC-V tree.

Regards,
Anup

> ---
>  tools/testing/selftests/kvm/Makefile          |   3 +-
>  .../selftests/kvm/aarch64/arch_timer.c        | 275 +-----------------
>  tools/testing/selftests/kvm/arch_timer.c      | 249 ++++++++++++++++
>  .../testing/selftests/kvm/include/test_util.h |   2 +
>  .../selftests/kvm/include/timer_test.h        |  43 +++
>  5 files changed, 302 insertions(+), 270 deletions(-)
>  create mode 100644 tools/testing/selftests/kvm/arch_timer.c
>  create mode 100644 tools/testing/selftests/kvm/include/timer_test.h
>
> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> index 2200f06b740b..4838ea899bbb 100644
> --- a/tools/testing/selftests/kvm/Makefile
> +++ b/tools/testing/selftests/kvm/Makefile
> @@ -151,7 +151,6 @@ TEST_GEN_PROGS_x86_64 += system_counter_offset_test
>  TEST_GEN_PROGS_EXTENDED_x86_64 += x86_64/nx_huge_pages_test
>
>  TEST_GEN_PROGS_aarch64 += aarch64/aarch32_id_regs
> -TEST_GEN_PROGS_aarch64 += aarch64/arch_timer
>  TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions
>  TEST_GEN_PROGS_aarch64 += aarch64/hypercalls
>  TEST_GEN_PROGS_aarch64 += aarch64/page_fault_test
> @@ -163,6 +162,7 @@ TEST_GEN_PROGS_aarch64 += aarch64/vgic_init
>  TEST_GEN_PROGS_aarch64 += aarch64/vgic_irq
>  TEST_GEN_PROGS_aarch64 += aarch64/vpmu_counter_access
>  TEST_GEN_PROGS_aarch64 += access_tracking_perf_test
> +TEST_GEN_PROGS_aarch64 += arch_timer
>  TEST_GEN_PROGS_aarch64 += demand_paging_test
>  TEST_GEN_PROGS_aarch64 += dirty_log_test
>  TEST_GEN_PROGS_aarch64 += dirty_log_perf_test
> @@ -201,6 +201,7 @@ TEST_GEN_PROGS_riscv += kvm_page_table_test
>  TEST_GEN_PROGS_riscv += set_memory_region_test
>  TEST_GEN_PROGS_riscv += kvm_binary_stats_test
>
> +SPLIT_TESTS += arch_timer
>  SPLIT_TESTS += get-reg-list
>
>  TEST_PROGS += $(TEST_PROGS_$(ARCH_DIR))
> diff --git a/tools/testing/selftests/kvm/aarch64/arch_timer.c b/tools/testing/selftests/kvm/aarch64/arch_timer.c
> index 274b8465b42a..6fb47ba07e5b 100644
> --- a/tools/testing/selftests/kvm/aarch64/arch_timer.c
> +++ b/tools/testing/selftests/kvm/aarch64/arch_timer.c
> @@ -1,64 +1,19 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
> - * arch_timer.c - Tests the aarch64 timer IRQ functionality
> - *
>   * The test validates both the virtual and physical timer IRQs using
> - * CVAL and TVAL registers. This consitutes the four stages in the test.
> - * The guest's main thread configures the timer interrupt for a stage
> - * and waits for it to fire, with a timeout equal to the timer period.
> - * It asserts that the timeout doesn't exceed the timer period.
> - *
> - * On the other hand, upon receipt of an interrupt, the guest's interrupt
> - * handler validates the interrupt by checking if the architectural state
> - * is in compliance with the specifications.
> - *
> - * The test provides command-line options to configure the timer's
> - * period (-p), number of vCPUs (-n), and iterations per stage (-i).
> - * To stress-test the timer stack even more, an option to migrate the
> - * vCPUs across pCPUs (-m), at a particular rate, is also provided.
> + * CVAL and TVAL registers.
>   *
>   * Copyright (c) 2021, Google LLC.
>   */
>  #define _GNU_SOURCE
>
> -#include <stdlib.h>
> -#include <pthread.h>
> -#include <linux/kvm.h>
> -#include <linux/sizes.h>
> -#include <linux/bitmap.h>
> -#include <sys/sysinfo.h>
> -
> -#include "kvm_util.h"
> -#include "processor.h"
> -#include "delay.h"
>  #include "arch_timer.h"
> +#include "delay.h"
>  #include "gic.h"
> +#include "processor.h"
> +#include "timer_test.h"
>  #include "vgic.h"
>
> -#define NR_VCPUS_DEF                   4
> -#define NR_TEST_ITERS_DEF              5
> -#define TIMER_TEST_PERIOD_MS_DEF       10
> -#define TIMER_TEST_ERR_MARGIN_US       100
> -#define TIMER_TEST_MIGRATION_FREQ_MS   2
> -
> -struct test_args {
> -       int nr_vcpus;
> -       int nr_iter;
> -       int timer_period_ms;
> -       int migration_freq_ms;
> -       struct kvm_arm_counter_offset offset;
> -};
> -
> -static struct test_args test_args = {
> -       .nr_vcpus = NR_VCPUS_DEF,
> -       .nr_iter = NR_TEST_ITERS_DEF,
> -       .timer_period_ms = TIMER_TEST_PERIOD_MS_DEF,
> -       .migration_freq_ms = TIMER_TEST_MIGRATION_FREQ_MS,
> -       .offset = { .reserved = 1 },
> -};
> -
> -#define msecs_to_usecs(msec)           ((msec) * 1000LL)
> -
>  #define GICD_BASE_GPA                  0x8000000ULL
>  #define GICR_BASE_GPA                  0x80A0000ULL
>
> @@ -70,22 +25,8 @@ enum guest_stage {
>         GUEST_STAGE_MAX,
>  };
>
> -/* Shared variables between host and guest */
> -struct test_vcpu_shared_data {
> -       int nr_iter;
> -       enum guest_stage guest_stage;
> -       uint64_t xcnt;
> -};
> -
> -static struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
> -static pthread_t pt_vcpu_run[KVM_MAX_VCPUS];
> -static struct test_vcpu_shared_data vcpu_shared_data[KVM_MAX_VCPUS];
> -
>  static int vtimer_irq, ptimer_irq;
>
> -static unsigned long *vcpu_done_map;
> -static pthread_mutex_t vcpu_done_map_lock;
> -
>  static void
>  guest_configure_timer_action(struct test_vcpu_shared_data *shared_data)
>  {
> @@ -222,137 +163,6 @@ static void guest_code(void)
>         GUEST_DONE();
>  }
>
> -static void *test_vcpu_run(void *arg)
> -{
> -       unsigned int vcpu_idx = (unsigned long)arg;
> -       struct ucall uc;
> -       struct kvm_vcpu *vcpu = vcpus[vcpu_idx];
> -       struct kvm_vm *vm = vcpu->vm;
> -       struct test_vcpu_shared_data *shared_data = &vcpu_shared_data[vcpu_idx];
> -
> -       vcpu_run(vcpu);
> -
> -       /* Currently, any exit from guest is an indication of completion */
> -       pthread_mutex_lock(&vcpu_done_map_lock);
> -       __set_bit(vcpu_idx, vcpu_done_map);
> -       pthread_mutex_unlock(&vcpu_done_map_lock);
> -
> -       switch (get_ucall(vcpu, &uc)) {
> -       case UCALL_SYNC:
> -       case UCALL_DONE:
> -               break;
> -       case UCALL_ABORT:
> -               sync_global_from_guest(vm, *shared_data);
> -               fprintf(stderr, "Guest assert failed,  vcpu %u; stage; %u; iter: %u\n",
> -                       vcpu_idx, shared_data->guest_stage, shared_data->nr_iter);
> -               REPORT_GUEST_ASSERT(uc);
> -               break;
> -       default:
> -               TEST_FAIL("Unexpected guest exit\n");
> -       }
> -
> -       return NULL;
> -}
> -
> -static uint32_t test_get_pcpu(void)
> -{
> -       uint32_t pcpu;
> -       unsigned int nproc_conf;
> -       cpu_set_t online_cpuset;
> -
> -       nproc_conf = get_nprocs_conf();
> -       sched_getaffinity(0, sizeof(cpu_set_t), &online_cpuset);
> -
> -       /* Randomly find an available pCPU to place a vCPU on */
> -       do {
> -               pcpu = rand() % nproc_conf;
> -       } while (!CPU_ISSET(pcpu, &online_cpuset));
> -
> -       return pcpu;
> -}
> -
> -static int test_migrate_vcpu(unsigned int vcpu_idx)
> -{
> -       int ret;
> -       cpu_set_t cpuset;
> -       uint32_t new_pcpu = test_get_pcpu();
> -
> -       CPU_ZERO(&cpuset);
> -       CPU_SET(new_pcpu, &cpuset);
> -
> -       pr_debug("Migrating vCPU: %u to pCPU: %u\n", vcpu_idx, new_pcpu);
> -
> -       ret = pthread_setaffinity_np(pt_vcpu_run[vcpu_idx],
> -                                    sizeof(cpuset), &cpuset);
> -
> -       /* Allow the error where the vCPU thread is already finished */
> -       TEST_ASSERT(ret == 0 || ret == ESRCH,
> -                   "Failed to migrate the vCPU:%u to pCPU: %u; ret: %d\n",
> -                   vcpu_idx, new_pcpu, ret);
> -
> -       return ret;
> -}
> -
> -static void *test_vcpu_migration(void *arg)
> -{
> -       unsigned int i, n_done;
> -       bool vcpu_done;
> -
> -       do {
> -               usleep(msecs_to_usecs(test_args.migration_freq_ms));
> -
> -               for (n_done = 0, i = 0; i < test_args.nr_vcpus; i++) {
> -                       pthread_mutex_lock(&vcpu_done_map_lock);
> -                       vcpu_done = test_bit(i, vcpu_done_map);
> -                       pthread_mutex_unlock(&vcpu_done_map_lock);
> -
> -                       if (vcpu_done) {
> -                               n_done++;
> -                               continue;
> -                       }
> -
> -                       test_migrate_vcpu(i);
> -               }
> -       } while (test_args.nr_vcpus != n_done);
> -
> -       return NULL;
> -}
> -
> -static void test_run(struct kvm_vm *vm)
> -{
> -       pthread_t pt_vcpu_migration;
> -       unsigned int i;
> -       int ret;
> -
> -       pthread_mutex_init(&vcpu_done_map_lock, NULL);
> -       vcpu_done_map = bitmap_zalloc(test_args.nr_vcpus);
> -       TEST_ASSERT(vcpu_done_map, "Failed to allocate vcpu done bitmap\n");
> -
> -       for (i = 0; i < (unsigned long)test_args.nr_vcpus; i++) {
> -               ret = pthread_create(&pt_vcpu_run[i], NULL, test_vcpu_run,
> -                                    (void *)(unsigned long)i);
> -               TEST_ASSERT(!ret, "Failed to create vCPU-%d pthread\n", i);
> -       }
> -
> -       /* Spawn a thread to control the vCPU migrations */
> -       if (test_args.migration_freq_ms) {
> -               srand(time(NULL));
> -
> -               ret = pthread_create(&pt_vcpu_migration, NULL,
> -                                       test_vcpu_migration, NULL);
> -               TEST_ASSERT(!ret, "Failed to create the migration pthread\n");
> -       }
> -
> -
> -       for (i = 0; i < test_args.nr_vcpus; i++)
> -               pthread_join(pt_vcpu_run[i], NULL);
> -
> -       if (test_args.migration_freq_ms)
> -               pthread_join(pt_vcpu_migration, NULL);
> -
> -       bitmap_free(vcpu_done_map);
> -}
> -
>  static void test_init_timer_irq(struct kvm_vm *vm)
>  {
>         /* Timer initid should be same for all the vCPUs, so query only vCPU-0 */
> @@ -369,7 +179,7 @@ static void test_init_timer_irq(struct kvm_vm *vm)
>
>  static int gic_fd;
>
> -static struct kvm_vm *test_vm_create(void)
> +struct kvm_vm *test_vm_create(void)
>  {
>         struct kvm_vm *vm;
>         unsigned int i;
> @@ -400,81 +210,8 @@ static struct kvm_vm *test_vm_create(void)
>         return vm;
>  }
>
> -static void test_vm_cleanup(struct kvm_vm *vm)
> +void test_vm_cleanup(struct kvm_vm *vm)
>  {
>         close(gic_fd);
>         kvm_vm_free(vm);
>  }
> -
> -static void test_print_help(char *name)
> -{
> -       pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n",
> -               name);
> -       pr_info("\t-n: Number of vCPUs to configure (default: %u; max: %u)\n",
> -               NR_VCPUS_DEF, KVM_MAX_VCPUS);
> -       pr_info("\t-i: Number of iterations per stage (default: %u)\n",
> -               NR_TEST_ITERS_DEF);
> -       pr_info("\t-p: Periodicity (in ms) of the guest timer (default: %u)\n",
> -               TIMER_TEST_PERIOD_MS_DEF);
> -       pr_info("\t-m: Frequency (in ms) of vCPUs to migrate to different pCPU. 0 to turn off (default: %u)\n",
> -               TIMER_TEST_MIGRATION_FREQ_MS);
> -       pr_info("\t-o: Counter offset (in counter cycles, default: 0)\n");
> -       pr_info("\t-h: print this help screen\n");
> -}
> -
> -static bool parse_args(int argc, char *argv[])
> -{
> -       int opt;
> -
> -       while ((opt = getopt(argc, argv, "hn:i:p:m:o:")) != -1) {
> -               switch (opt) {
> -               case 'n':
> -                       test_args.nr_vcpus = atoi_positive("Number of vCPUs", optarg);
> -                       if (test_args.nr_vcpus > KVM_MAX_VCPUS) {
> -                               pr_info("Max allowed vCPUs: %u\n",
> -                                       KVM_MAX_VCPUS);
> -                               goto err;
> -                       }
> -                       break;
> -               case 'i':
> -                       test_args.nr_iter = atoi_positive("Number of iterations", optarg);
> -                       break;
> -               case 'p':
> -                       test_args.timer_period_ms = atoi_positive("Periodicity", optarg);
> -                       break;
> -               case 'm':
> -                       test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
> -                       break;
> -               case 'o':
> -                       test_args.offset.counter_offset = strtol(optarg, NULL, 0);
> -                       test_args.offset.reserved = 0;
> -                       break;
> -               case 'h':
> -               default:
> -                       goto err;
> -               }
> -       }
> -
> -       return true;
> -
> -err:
> -       test_print_help(argv[0]);
> -       return false;
> -}
> -
> -int main(int argc, char *argv[])
> -{
> -       struct kvm_vm *vm;
> -
> -       if (!parse_args(argc, argv))
> -               exit(KSFT_SKIP);
> -
> -       __TEST_REQUIRE(!test_args.migration_freq_ms || get_nprocs() >= 2,
> -                      "At least two physical CPUs needed for vCPU migration");
> -
> -       vm = test_vm_create();
> -       test_run(vm);
> -       test_vm_cleanup(vm);
> -
> -       return 0;
> -}
> diff --git a/tools/testing/selftests/kvm/arch_timer.c b/tools/testing/selftests/kvm/arch_timer.c
> new file mode 100644
> index 000000000000..6e442dbcfc8b
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/arch_timer.c
> @@ -0,0 +1,249 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * arch_timer.c - Tests the arch timer IRQ functionality
> + *
> + * The guest's main thread configures the timer interrupt and waits
> + * for it to fire, with a timeout equal to the timer period.
> + * It asserts that the timeout doesn't exceed the timer period plus
> + * an error margin of 100us.
> + *
> + * On the other hand, upon receipt of an interrupt, the guest's interrupt
> + * handler validates the interrupt by checking if the architectural state
> + * is in compliance with the specifications.
> + *
> + * The test provides command-line options to configure the timer's
> + * period (-p), number of vCPUs (-n), and iterations per stage (-i).
> + * To stress-test the timer stack even more, an option to migrate the
> + * vCPUs across pCPUs (-m), at a particular rate, is also provided.
> + *
> + * Copyright (c) 2021, Google LLC.
> + */
> +
> +#define _GNU_SOURCE
> +
> +#include <stdlib.h>
> +#include <pthread.h>
> +#include <linux/sizes.h>
> +#include <linux/bitmap.h>
> +#include <sys/sysinfo.h>
> +
> +#include "timer_test.h"
> +
> +struct test_args test_args = {
> +       .nr_vcpus = NR_VCPUS_DEF,
> +       .nr_iter = NR_TEST_ITERS_DEF,
> +       .timer_period_ms = TIMER_TEST_PERIOD_MS_DEF,
> +       .migration_freq_ms = TIMER_TEST_MIGRATION_FREQ_MS,
> +       .offset = { .reserved = 1 },
> +};
> +
> +struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
> +struct test_vcpu_shared_data vcpu_shared_data[KVM_MAX_VCPUS];
> +
> +static pthread_t pt_vcpu_run[KVM_MAX_VCPUS];
> +static unsigned long *vcpu_done_map;
> +static pthread_mutex_t vcpu_done_map_lock;
> +
> +static void *test_vcpu_run(void *arg)
> +{
> +       unsigned int vcpu_idx = (unsigned long)arg;
> +       struct ucall uc;
> +       struct kvm_vcpu *vcpu = vcpus[vcpu_idx];
> +       struct kvm_vm *vm = vcpu->vm;
> +       struct test_vcpu_shared_data *shared_data = &vcpu_shared_data[vcpu_idx];
> +
> +       vcpu_run(vcpu);
> +
> +       /* Currently, any exit from guest is an indication of completion */
> +       pthread_mutex_lock(&vcpu_done_map_lock);
> +       __set_bit(vcpu_idx, vcpu_done_map);
> +       pthread_mutex_unlock(&vcpu_done_map_lock);
> +
> +       switch (get_ucall(vcpu, &uc)) {
> +       case UCALL_SYNC:
> +       case UCALL_DONE:
> +               break;
> +       case UCALL_ABORT:
> +               sync_global_from_guest(vm, *shared_data);
> +               fprintf(stderr, "Guest assert failed,  vcpu %u; stage; %u; iter: %u\n",
> +                       vcpu_idx, shared_data->guest_stage, shared_data->nr_iter);
> +               REPORT_GUEST_ASSERT(uc);
> +               break;
> +       default:
> +               TEST_FAIL("Unexpected guest exit\n");
> +       }
> +
> +       return NULL;
> +}
> +
> +static uint32_t test_get_pcpu(void)
> +{
> +       uint32_t pcpu;
> +       unsigned int nproc_conf;
> +       cpu_set_t online_cpuset;
> +
> +       nproc_conf = get_nprocs_conf();
> +       sched_getaffinity(0, sizeof(cpu_set_t), &online_cpuset);
> +
> +       /* Randomly find an available pCPU to place a vCPU on */
> +       do {
> +               pcpu = rand() % nproc_conf;
> +       } while (!CPU_ISSET(pcpu, &online_cpuset));
> +
> +       return pcpu;
> +}
> +
> +static int test_migrate_vcpu(unsigned int vcpu_idx)
> +{
> +       int ret;
> +       cpu_set_t cpuset;
> +       uint32_t new_pcpu = test_get_pcpu();
> +
> +       CPU_ZERO(&cpuset);
> +       CPU_SET(new_pcpu, &cpuset);
> +
> +       pr_debug("Migrating vCPU: %u to pCPU: %u\n", vcpu_idx, new_pcpu);
> +
> +       ret = pthread_setaffinity_np(pt_vcpu_run[vcpu_idx],
> +                                    sizeof(cpuset), &cpuset);
> +
> +       /* Allow the error where the vCPU thread is already finished */
> +       TEST_ASSERT(ret == 0 || ret == ESRCH,
> +                   "Failed to migrate the vCPU:%u to pCPU: %u; ret: %d\n",
> +                   vcpu_idx, new_pcpu, ret);
> +
> +       return ret;
> +}
> +
> +static void *test_vcpu_migration(void *arg)
> +{
> +       unsigned int i, n_done;
> +       bool vcpu_done;
> +
> +       do {
> +               usleep(msecs_to_usecs(test_args.migration_freq_ms));
> +
> +               for (n_done = 0, i = 0; i < test_args.nr_vcpus; i++) {
> +                       pthread_mutex_lock(&vcpu_done_map_lock);
> +                       vcpu_done = test_bit(i, vcpu_done_map);
> +                       pthread_mutex_unlock(&vcpu_done_map_lock);
> +
> +                       if (vcpu_done) {
> +                               n_done++;
> +                               continue;
> +                       }
> +
> +                       test_migrate_vcpu(i);
> +               }
> +       } while (test_args.nr_vcpus != n_done);
> +
> +       return NULL;
> +}
> +
> +static void test_run(struct kvm_vm *vm)
> +{
> +       pthread_t pt_vcpu_migration;
> +       unsigned int i;
> +       int ret;
> +
> +       pthread_mutex_init(&vcpu_done_map_lock, NULL);
> +       vcpu_done_map = bitmap_zalloc(test_args.nr_vcpus);
> +       TEST_ASSERT(vcpu_done_map, "Failed to allocate vcpu done bitmap\n");
> +
> +       for (i = 0; i < (unsigned long)test_args.nr_vcpus; i++) {
> +               ret = pthread_create(&pt_vcpu_run[i], NULL, test_vcpu_run,
> +                                    (void *)(unsigned long)i);
> +               TEST_ASSERT(!ret, "Failed to create vCPU-%d pthread\n", i);
> +       }
> +
> +       /* Spawn a thread to control the vCPU migrations */
> +       if (test_args.migration_freq_ms) {
> +               srand(time(NULL));
> +
> +               ret = pthread_create(&pt_vcpu_migration, NULL,
> +                                       test_vcpu_migration, NULL);
> +               TEST_ASSERT(!ret, "Failed to create the migration pthread\n");
> +       }
> +
> +
> +       for (i = 0; i < test_args.nr_vcpus; i++)
> +               pthread_join(pt_vcpu_run[i], NULL);
> +
> +       if (test_args.migration_freq_ms)
> +               pthread_join(pt_vcpu_migration, NULL);
> +
> +       bitmap_free(vcpu_done_map);
> +}
> +
> +static void test_print_help(char *name)
> +{
> +       pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n",
> +               name);
> +       pr_info("\t-n: Number of vCPUs to configure (default: %u; max: %u)\n",
> +               NR_VCPUS_DEF, KVM_MAX_VCPUS);
> +       pr_info("\t-i: Number of iterations per stage (default: %u)\n",
> +               NR_TEST_ITERS_DEF);
> +       pr_info("\t-p: Periodicity (in ms) of the guest timer (default: %u)\n",
> +               TIMER_TEST_PERIOD_MS_DEF);
> +       pr_info("\t-m: Frequency (in ms) of vCPUs to migrate to different pCPU. 0 to turn off (default: %u)\n",
> +               TIMER_TEST_MIGRATION_FREQ_MS);
> +       pr_info("\t-o: Counter offset (in counter cycles, default: 0)\n");
> +       pr_info("\t-h: print this help screen\n");
> +}
> +
> +static bool parse_args(int argc, char *argv[])
> +{
> +       int opt;
> +
> +       while ((opt = getopt(argc, argv, "hn:i:p:m:o:")) != -1) {
> +               switch (opt) {
> +               case 'n':
> +                       test_args.nr_vcpus = atoi_positive("Number of vCPUs", optarg);
> +                       if (test_args.nr_vcpus > KVM_MAX_VCPUS) {
> +                               pr_info("Max allowed vCPUs: %u\n",
> +                                       KVM_MAX_VCPUS);
> +                               goto err;
> +                       }
> +                       break;
> +               case 'i':
> +                       test_args.nr_iter = atoi_positive("Number of iterations", optarg);
> +                       break;
> +               case 'p':
> +                       test_args.timer_period_ms = atoi_positive("Periodicity", optarg);
> +                       break;
> +               case 'm':
> +                       test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
> +                       break;
> +               case 'o':
> +                       test_args.offset.counter_offset = strtol(optarg, NULL, 0);
> +                       test_args.offset.reserved = 0;
> +                       break;
> +               case 'h':
> +               default:
> +                       goto err;
> +               }
> +       }
> +
> +       return true;
> +
> +err:
> +       test_print_help(argv[0]);
> +       return false;
> +}
> +
> +int main(int argc, char *argv[])
> +{
> +       struct kvm_vm *vm;
> +
> +       if (!parse_args(argc, argv))
> +               exit(KSFT_SKIP);
> +
> +       __TEST_REQUIRE(!test_args.migration_freq_ms || get_nprocs() >= 2,
> +                      "At least two physical CPUs needed for vCPU migration");
> +
> +       vm = test_vm_create();
> +       test_run(vm);
> +       test_vm_cleanup(vm);
> +
> +       return 0;
> +}
> diff --git a/tools/testing/selftests/kvm/include/test_util.h b/tools/testing/selftests/kvm/include/test_util.h
> index 8e5f413a593d..36387e7ee8b2 100644
> --- a/tools/testing/selftests/kvm/include/test_util.h
> +++ b/tools/testing/selftests/kvm/include/test_util.h
> @@ -20,6 +20,8 @@
>  #include <sys/mman.h>
>  #include "kselftest.h"
>
> +#define msecs_to_usecs(msec)    ((msec) * 1000LL)
> +
>  static inline int _no_printf(const char *format, ...) { return 0; }
>
>  #ifdef DEBUG
> diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
> new file mode 100644
> index 000000000000..2234c513b510
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/include/timer_test.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * timer test specific header
> + *
> + * Copyright (C) 2018, Google LLC
> + */
> +
> +#ifndef SELFTEST_KVM_TIMER_TEST_H
> +#define SELFTEST_KVM_TIMER_TEST_H
> +
> +#include "kvm_util.h"
> +
> +#define NR_VCPUS_DEF            4
> +#define NR_TEST_ITERS_DEF       5
> +#define TIMER_TEST_PERIOD_MS_DEF    10
> +#define TIMER_TEST_ERR_MARGIN_US    100
> +#define TIMER_TEST_MIGRATION_FREQ_MS    2
> +
> +/* Timer test cmdline parameters */
> +struct test_args {
> +       int nr_vcpus;
> +       int nr_iter;
> +       int timer_period_ms;
> +       int migration_freq_ms;
> +       /* TODO: Change arm specific type to a common one */
> +       struct kvm_arm_counter_offset offset;
> +};
> +
> +/* Shared variables between host and guest */
> +struct test_vcpu_shared_data {
> +       int nr_iter;
> +       int guest_stage;
> +       uint64_t xcnt;
> +};
> +
> +extern struct test_args test_args;
> +extern struct kvm_vcpu *vcpus[];
> +extern struct test_vcpu_shared_data vcpu_shared_data[];
> +
> +struct kvm_vm *test_vm_create(void);
> +void test_vm_cleanup(struct kvm_vm *vm);
> +
> +#endif /* SELFTEST_KVM_TIMER_TEST_H */
> --
> 2.34.1
>


From zajec5 at gmail.com  Wed Dec 13 22:43:01 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 14 Dec 2023 07:43:01 +0100
Subject: [PATCH] arm64: dts: mediatek: mt7986: fix reference to PWM in fan
 node
In-Reply-To: <20231116130816.4932-1-zajec5@gmail.com>
References: <20231116130816.4932-1-zajec5@gmail.com>
Message-ID: <a5113b85-e29c-454f-b776-ac7abbca771f@gmail.com>

Hi guys,

On 16.11.2023 14:08, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> This fixes typo and resolves following validation error:
> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm-fan: pwms: [[54, 0, 10000], [0]] is too long
>          from schema $id: http://devicetree.org/schemas/hwmon/pwm-fan.yaml#
> 
> Fixes: c26f779a2295 ("arm64: dts: mt7986: add pwm-fan and cooling-maps to BPI-R3 dts")
> Cc: Daniel Golle <daniel at makrotopia.org>
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

I sent those few trivial fixes weeks ago:
[PATCH] arm64: dts: mediatek: mt7986: fix reference to PWM in fan node
[PATCH 1/2] arm64: dts: mediatek: mt7986: fix SPI bus width properties
[PATCH 2/2] arm64: dts: mediatek: mt7986: fix SPI nodename
[PATCH] arm64: dts: mediatek: mt7986: drop crypto's unneeded/invalid clock name

Could someone pick them up, please?


P.S.
FWIW there is also my Acelink EW-7886CAX work but I can understand if
that needs to sit for another week or so.

> ---
>   arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
> index af4a4309bda4..ba65e3e72bf6 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
> @@ -43,7 +43,7 @@ fan: pwm-fan {
>   		#cooling-cells = <2>;
>   		/* cooling level (0, 1, 2) - pwm inverted */
>   		cooling-levels = <255 96 0>;
> -		pwms = <&pwm 0 10000 0>;
> +		pwms = <&pwm 0 10000>;
>   		status = "okay";
>   	};
>   



From anup at brainfault.org  Wed Dec 13 22:44:22 2023
From: anup at brainfault.org (Anup Patel)
Date: Thu, 14 Dec 2023 12:14:22 +0530
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us
 in arch timer test
In-Reply-To: <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com> <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
Message-ID: <CAAhSdy3hXNvGiSL0VToDp2GbWcaPveg8SoMeGFeGL=MmuCpsCg@mail.gmail.com>

Hi Marc, Hi Oliver,

On Tue, Dec 12, 2023 at 2:52?PM Haibo Xu <haibo1.xu at intel.com> wrote:
>
> There are intermittent failures occured when stressing the
> arch-timer test in a Qemu VM:
>
>  Guest assert failed,  vcpu 0; stage; 4; iter: 3
>  ==== Test Assertion Failure ====
>    aarch64/arch_timer.c:196: config_iter + 1 == irq_iter
>    pid=4048 tid=4049 errno=4 - Interrupted system call
>       1  0x000000000040253b: test_vcpu_run at arch_timer.c:248
>       2  0x0000ffffb60dd5c7: ?? ??:0
>       3  0x0000ffffb6145d1b: ?? ??:0
>    0x3 != 0x2 (config_iter + 1 != irq_iter)e
>
> Further test and debug show that the timeout for an interrupt
> to arrive do have random high fluctuation, espectially when
> testing in an virtual environment.
>
> To alleviate this issue, just expose the timeout value as user
> configurable and print some hint message to increase the value
> when hitting the failure..
>
> Signed-off-by: Haibo Xu <haibo1.xu at intel.com>

Can you please review this patch ?

We want to take this entire series through the KVM RISC-V tree.

Regards,
Anup

> ---
>  .../selftests/kvm/aarch64/arch_timer.c        |  8 +++++--
>  tools/testing/selftests/kvm/arch_timer.c      | 22 +++++++++++++------
>  .../selftests/kvm/include/timer_test.h        |  1 +
>  .../testing/selftests/kvm/riscv/arch_timer.c  |  8 +++++--
>  4 files changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/aarch64/arch_timer.c b/tools/testing/selftests/kvm/aarch64/arch_timer.c
> index 4b421d421c3f..139eecbf77e7 100644
> --- a/tools/testing/selftests/kvm/aarch64/arch_timer.c
> +++ b/tools/testing/selftests/kvm/aarch64/arch_timer.c
> @@ -131,10 +131,14 @@ static void guest_run_stage(struct test_vcpu_shared_data *shared_data,
>
>                 /* Setup a timeout for the interrupt to arrive */
>                 udelay(msecs_to_usecs(test_args.timer_period_ms) +
> -                       TIMER_TEST_ERR_MARGIN_US);
> +                       test_args.timer_err_margin_us);
>
>                 irq_iter = READ_ONCE(shared_data->nr_iter);
> -               GUEST_ASSERT_EQ(config_iter + 1, irq_iter);
> +               __GUEST_ASSERT(config_iter + 1 == irq_iter,
> +                       "config_iter + 1 = 0x%lx, irq_iter = 0x%lx.\n"
> +                       "  Guest timer interrupt was not trigged within the specified\n"
> +                       "  interval, try to increase the error margin by [-e] option.\n",
> +                       config_iter + 1, irq_iter);
>         }
>  }
>
> diff --git a/tools/testing/selftests/kvm/arch_timer.c b/tools/testing/selftests/kvm/arch_timer.c
> index 60963fce16f2..5050022fd345 100644
> --- a/tools/testing/selftests/kvm/arch_timer.c
> +++ b/tools/testing/selftests/kvm/arch_timer.c
> @@ -5,16 +5,17 @@
>   * The guest's main thread configures the timer interrupt and waits
>   * for it to fire, with a timeout equal to the timer period.
>   * It asserts that the timeout doesn't exceed the timer period plus
> - * an error margin of 100us.
> + * an user configurable error margin(default to 100us).
>   *
>   * On the other hand, upon receipt of an interrupt, the guest's interrupt
>   * handler validates the interrupt by checking if the architectural state
>   * is in compliance with the specifications.
>   *
>   * The test provides command-line options to configure the timer's
> - * period (-p), number of vCPUs (-n), and iterations per stage (-i).
> - * To stress-test the timer stack even more, an option to migrate the
> - * vCPUs across pCPUs (-m), at a particular rate, is also provided.
> + * period (-p), number of vCPUs (-n), iterations per stage (-i), and timer
> + * interrupt arrival error margin (-e). To stress-test the timer stack even
> + * more, an option to migrate the vCPUs across pCPUs (-m), at a particular
> + * rate, is also provided.
>   *
>   * Copyright (c) 2021, Google LLC.
>   */
> @@ -34,6 +35,7 @@ struct test_args test_args = {
>         .nr_iter = NR_TEST_ITERS_DEF,
>         .timer_period_ms = TIMER_TEST_PERIOD_MS_DEF,
>         .migration_freq_ms = TIMER_TEST_MIGRATION_FREQ_MS,
> +       .timer_err_margin_us = TIMER_TEST_ERR_MARGIN_US,
>         .reserved = 1,
>  };
>
> @@ -179,8 +181,9 @@ static void test_run(struct kvm_vm *vm)
>
>  static void test_print_help(char *name)
>  {
> -       pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n",
> -               name);
> +       pr_info("Usage: %s [-h] [-n nr_vcpus] [-i iterations] [-p timer_period_ms]\n"
> +               "\t\t    [-m migration_freq_ms] [-o counter_offset]\n"
> +               "\t\t    [-e timer_err_margin_us]\n", name);
>         pr_info("\t-n: Number of vCPUs to configure (default: %u; max: %u)\n",
>                 NR_VCPUS_DEF, KVM_MAX_VCPUS);
>         pr_info("\t-i: Number of iterations per stage (default: %u)\n",
> @@ -190,6 +193,8 @@ static void test_print_help(char *name)
>         pr_info("\t-m: Frequency (in ms) of vCPUs to migrate to different pCPU. 0 to turn off (default: %u)\n",
>                 TIMER_TEST_MIGRATION_FREQ_MS);
>         pr_info("\t-o: Counter offset (in counter cycles, default: 0) [aarch64-only]\n");
> +       pr_info("\t-e: Interrupt arrival error margin(in us) of the guest timer (default: %u)\n",
> +               TIMER_TEST_ERR_MARGIN_US);
>         pr_info("\t-h: print this help screen\n");
>  }
>
> @@ -197,7 +202,7 @@ static bool parse_args(int argc, char *argv[])
>  {
>         int opt;
>
> -       while ((opt = getopt(argc, argv, "hn:i:p:m:o:")) != -1) {
> +       while ((opt = getopt(argc, argv, "hn:i:p:m:o:e:")) != -1) {
>                 switch (opt) {
>                 case 'n':
>                         test_args.nr_vcpus = atoi_positive("Number of vCPUs", optarg);
> @@ -216,6 +221,9 @@ static bool parse_args(int argc, char *argv[])
>                 case 'm':
>                         test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
>                         break;
> +               case 'e':
> +                       test_args.timer_err_margin_us = atoi_non_negative("Error Margin", optarg);
> +                       break;
>                 case 'o':
>                         test_args.counter_offset = strtol(optarg, NULL, 0);
>                         test_args.reserved = 0;
> diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
> index 968257b893a7..b1d405e7157d 100644
> --- a/tools/testing/selftests/kvm/include/timer_test.h
> +++ b/tools/testing/selftests/kvm/include/timer_test.h
> @@ -22,6 +22,7 @@ struct test_args {
>         int nr_iter;
>         int timer_period_ms;
>         int migration_freq_ms;
> +       int timer_err_margin_us;
>         /* Members of struct kvm_arm_counter_offset */
>         uint64_t counter_offset;
>         uint64_t reserved;
> diff --git a/tools/testing/selftests/kvm/riscv/arch_timer.c b/tools/testing/selftests/kvm/riscv/arch_timer.c
> index 13bf184d1ff5..45a139dc7ce3 100644
> --- a/tools/testing/selftests/kvm/riscv/arch_timer.c
> +++ b/tools/testing/selftests/kvm/riscv/arch_timer.c
> @@ -55,10 +55,14 @@ static void guest_run(struct test_vcpu_shared_data *shared_data)
>
>                 /* Setup a timeout for the interrupt to arrive */
>                 udelay(msecs_to_usecs(test_args.timer_period_ms) +
> -                       TIMER_TEST_ERR_MARGIN_US);
> +                       test_args.timer_err_margin_us);
>
>                 irq_iter = READ_ONCE(shared_data->nr_iter);
> -               GUEST_ASSERT_EQ(config_iter + 1, irq_iter);
> +               __GUEST_ASSERT(config_iter + 1 == irq_iter,
> +                       "config_iter + 1 = 0x%lx, irq_iter = 0x%lx.\n"
> +                       "  Guest timer interrupt was not trigged within the specified\n"
> +                       "  interval, try to increase the error margin by [-e] option.\n",
> +                       config_iter + 1, irq_iter);
>         }
>  }
>
> --
> 2.34.1
>


From dsimic at manjaro.org  Wed Dec 13 23:07:48 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Thu, 14 Dec 2023 08:07:48 +0100
Subject: [PATCH v2] arm64: rockchip: dts: rk3328-rock-pi-e: add
 gpio-line-names
In-Reply-To: <20231213160556.14424-1-twoerner@gmail.com>
References: <20231213160556.14424-1-twoerner@gmail.com>
Message-ID: <62a0261fba6aecf5b28c4c55eb38ea51@manjaro.org>

On 2023-12-13 17:05, Trevor Woerner wrote:
> Add names to the pins of the general-purpose expansion header as given
> in the Radxa GPIO page[1] following the conventions in the kernel
> documentation[2] to make it easier for users to correlate the pins with
> functions when using utilities such as 'gpioinfo'.
> 
> Signed-off-by: Trevor Woerner <twoerner at gmail.com>
> ---
> changes in v2:
> - fix subject from "amd64..." to "arm64..."
> ---
>  .../boot/dts/rockchip/rk3328-rock-pi-e.dts    | 53 +++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> index 018a3a5075c7..3169c0854061 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> @@ -388,3 +388,56 @@ &usbdrd3 {
>  &usb_host0_ehci {
>  	status = "okay";
>  };
> +
> +&gpio0 {
> +	gpio-line-names =
> +	/* GPIO0_A0 - A7 */
> +	"", "", "", "", "", "", "", "",
> +	/* GPIO0_B0 - B7 */
> +	"", "", "", "", "", "", "", "",
> +	/* GPIO0_C0 - C7 */
> +	"", "", "", "", "", "", "", "",
> +	/* GPIO0_D0 - D7 */
> +	"", "", "", "pin-15 [GPIO0_D3]", "", "", "", "";
> +};
> +
> +&gpio1 {
> +	gpio-line-names =
> +	/* GPIO1_A0 - A7 */
> +	"", "", "", "", "", "", "", "",
> +	/* GPIO1_B0 - B7 */
> +	"", "", "", "", "", "", "", "",
> +	/* GPIO1_C0 - C7 */
> +	"", "", "", "", "", "", "", "",
> +	/* GPIO1_D0 - D7 */
> +	"", "", "", "", "pin-07 [GPIO1_D4]", "", "", "";
> +};
> +
> +&gpio2 {
> +	gpio-line-names =
> +	/* GPIO2_A0 - A7 */
> +	"pin-08 [GPIO2_A0]", "pin-10 [GPIO2_A1]", "pin-11 [GPIO2_A2]",
> +	"pin-13 [GPIO2-A3]", "pin-27 [GPIO2_A4]", "pin-28 [GPIO2_A5]",
> +	"pin-33 [GPIO2_A6]", "",
> +	/* GPIO2_B0 - B7 */
> +	"", "", "", "", "pin-26 [GPIO2_B4]", "", "", "pin-36 [GPIO2_B7]",
> +	/* GPIO2_C0 - C7 */
> +	"pin-32 [GPIO2_C0]", "pin-35 [GPIO2_C1]", "pin-12 [GPIO2_C2]",
> +	"pin-38 [GPIO2_C3]", "pin-29 [GPIO2_C4]", "pin-31 [GPIO2_C5]",
> +	"pin-37 [GPIO2_C6]", "pin-40 [GPIO2_C7]",
> +	/* GPIO2_D0 - D7 */
> +	"", "", "", "", "", "", "", "";
> +};
> +
> +&gpio3 {
> +	gpio-line-names =
> +	/* GPIO3_A0 - A7 */
> +	"pin-23 [GPIO3_A0]", "pin-19 [GPIO3_A1]", "pin-21 [GPIO3_A2]",
> +	"", "pin-03 [GPIO3_A4]", "", "pin-05 [GPIO3_A6]", "",
> +	/* GPIO3_B0 - B7 */
> +	"pin-24 [GPIO3_B0]", "", "", "", "", "", "", "",
> +	/* GPIO3_C0 - C7 */
> +	"", "", "", "", "", "", "", "",
> +	/* GPIO3_D0 - D7 */
> +	"", "", "", "", "", "", "", "";
> +};

The formatting should be a bit different, i.e. all lines following 
"gpio-line-names =" and providing the value should be indented one tab 
position further.


From krzysztof.kozlowski at linaro.org  Wed Dec 13 23:24:50 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 08:24:50 +0100
Subject: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
In-Reply-To: <edcdcea2-febc-4859-9ccf-b8c59b794f01@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-9-ninad@linux.ibm.com>
 <5b98538a-8ffe-42ec-b020-514dcfcebba3@linaro.org>
 <44abff4a-0a8e-499b-8b98-a4a1680cb431@linux.ibm.com>
 <427fa99c-764c-4d6a-b9f1-cd9089710d5e@linaro.org>
 <edcdcea2-febc-4859-9ccf-b8c59b794f01@linux.ibm.com>
Message-ID: <1c5ace65-2fd8-4503-b22f-e0f564d1c83f@linaro.org>

On 13/12/2023 20:49, Ninad Palsule wrote:
> Hello Krzysztof,
> 
> On 12/13/23 13:37, Krzysztof Kozlowski wrote:
>> On 13/12/2023 20:02, Ninad Palsule wrote:
>>> Hello Krzysztof,
>>>
>>> On 12/12/23 14:26, Krzysztof Kozlowski wrote:
>>>> On 12/12/2023 17:40, Ninad Palsule wrote:
>>>>> This drop adds following devices in the device tree.
>>>>> - EEPROM/VPD
>>>>> - Power supplies
>>>>> - Humidity, pressure and temperature sensors.
>>>>> - Trusted platform module(TPM) chip
>>>>>
>>>>> Tested:
>>>>>       This board is tested using the simics simulator.
>>>>>
>>>>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>>>>> ---
>>>> Don't mix DTS with drivers. DTS and drivers go via different subsystems
>>>> and cannot have dependencies, so why DTS is patch #6, then driver #7 and
>>>> now again DTS #7?
>>> There is a dependency on driver code as patch #8 uses the compatibility
>>> string added in driver patch #7.? I have now moved driver patch at the
>>> start. Is that ok? OR you are suggesting something else?
>> First, there is no dependency. Second, except confusing order anyway DTS
>> will go via separate trees. Third, again, there is no dependency. If
>> there is, your patchset is broken and this needs to be fixed. Although I
>> don't understand how new hardware can depend on driver... it's really odd.
> 
> Thanks for the quick response.
> 
> This board uses the nuvoton TPM device. The tpm devices uses 
> "nuvoton,npct75x" driver hence we added it in the device tree. If the 
> driver doesn't have this compatibility string then it won't load. So if 
> someone tries to use this board then tpm won't work unless the 

... and if there is no board it also fails to load.

> compatibility string is added in the driver. That is the dependency I am 
> talking about.

This is not a dependency! It's unrelated.

Best regards,
Krzysztof



From masahiroy at kernel.org  Wed Dec 13 23:33:38 2023
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Thu, 14 Dec 2023 16:33:38 +0900
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAK7LNATyD-PeNbaLTjJmU9=koqqE+V6QvFe09c2VrXopWvjpcw@mail.gmail.com>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com> <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
 <20231209152946.GC13421@pendragon.ideasonboard.com> <CAMuHMdVMZs6mnwWBgFwktO=8o=QzROv60cfZe085MhD6HxQjpQ@mail.gmail.com>
 <CAGXv+5Est3FL-XcEL-vB-6zVNas0mqb2cNYa==Yb7W2SQU9xVQ@mail.gmail.com> <CAK7LNATyD-PeNbaLTjJmU9=koqqE+V6QvFe09c2VrXopWvjpcw@mail.gmail.com>
Message-ID: <CAK7LNAR7Fm-1yaZmyH78vG5yNbbW2Avjj5F63u+aST6JQoMd5A@mail.gmail.com>

On Thu, Dec 14, 2023 at 3:12?PM Masahiro Yamada <masahiroy at kernel.org> wrote:
>
> On Thu, Dec 14, 2023 at 1:03?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >
> > On Sun, Dec 10, 2023 at 1:31?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > >
> > > Hi Laurent,
> > >
> > > On Sat, Dec 9, 2023 at 4:29?PM Laurent Pinchart
> > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > On Thu, Dec 7, 2023 at 11:38?PM Laurent Pinchart
> > > > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > > performance.
> > > > > > > > >
> > > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > > >
> > > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > > filenames or other workarounds.
> > > > > > > > >
> > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > >
> > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > >
> > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > > $(obj)/image.fit
> > > > > > > > >
> > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > > >
> > > > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > > > balance between what makes sense for the kernel and the features that
> > > > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > > > to delay merging this series.
> > > > > > > >
> > > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > > > to a second question: would you consider merging extensions to this
> > > > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > > > users who manually invoke the script ? More generally, is the script
> > > > > > >
> > > > > > > We'd also be interested in some customization, though in a different way.
> > > > > > > We imagine having a rule file that says X compatible string should map
> > > > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > > > carry all the possible second source components, like different display
> > > > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > > > >
> > > > > > Do you envision the "mapping" compatible string mapping to a config
> > > > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > > > >
> > > > > That's exactly the idea. The mapping compatible string could be untied
> > > > > from the base board's compatible string if needed (which we probably do).
> > > > >
> > > > > So something like:
> > > > >
> > > > > config {
> > > > >     config-1 {
> > > > >         compatible = "google,krane-sku0";
> > > > >         fdt = "krane-baseboard", "krane-sku0-overlay";
> > > > >     };
> > > > > };
> > > > >
> > > > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > > > between the SKUs, in this case the display panel and MIPI camera (not
> > > > > upstreamed) that applies to SKU0 in particular.
> > > >
> > > > The kernel DT makefiles already contain information on what overlays to
> > > > apply to what base boards, in order to test the overlays and produce
> > > > "full" DTBs. Maybe that information could be leveraged to create the
> > > > configurations in the FIT image ?
> > >
> > > Although the "full" DTBs created may only be a subset of all possible
> > > combinations (I believe Rob just started with creating one "full" DTB
> > > for each overlay, cfr. the additions I made in commit a09c3e105a208580
> > > ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> > > definitely be a start.
> > >
> > > Now, since the kernel build system already creates "full" DTBs, does
> > > that mean that all of the base DTBs, overlays, and "full" DTBs will
> > > end up in the FIT image?
> >
> > I suppose we could add an option to the packing tool to be able to _not_
> > add the "full" DTBs if they can also be assembled with a base DTB and
> > overlays. Think of it as a firmware compatibility option: if the firmware
> > supports overlays, then you almost always want the deconstructed parts,
> > not the fully assembled ones. Vice versa.
> >
> > If we don't we could end up with two configurations that have the same
> > compatible string?
>
>
> Right.
>
> We would end up with such situations because applying
> an overlay does not change the compatible string.
>
>
>
> With this code in arch/arm64/boot/dts/ti/Makefile:
>
> k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
>       k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
> k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
>       k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
>
>
>
>
> $ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb
> 2>/dev/null| head -n15 | tail -n2
>     model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
>     compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
> "ti,am642";
>
>
> $ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
> 2>/dev/null| head -n15 | tail -n2
>     model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
>     compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
> "ti,am642";
>
>
>
>
>
> These two go into image.fit, but one of them is completely dead
> since there is no way to distinguish them.
>
>
> $ fdtdump  arch/arm64/boot/image.fit
>
>         ...
>
>         conf-10 {
>             compatible = "tq,am642-tqma6442l-mbax4xxl",
> "tq,am642-tqma6442l", "ti,am642";
>             description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
>             fdt = "fdt-10";
>             kernel = "kernel";
>         };
>
>         ...
>
>         conf-25 {
>             compatible = "tq,am642-tqma6442l-mbax4xxl",
> "tq,am642-tqma6442l", "ti,am642";
>             description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
>             fdt = "fdt-25";
>             kernel = "kernel";
>         };
>
>
>
>
>
> I agree with Chen-Yu.
>
> FIT should not include full DTBs.
>
> Bootloaders should assemble the final DTB
> from base and overlays on-the-fly.
>
>
> The FIT spec allows the "fdt" property to list
> multiple image nodes.
>
>
> o config-1
>  |- description = "configuration description"
>  |- kernel = "kernel sub-node unit name"
>  |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
>  |- loadables = "loadables sub-node unit-name"
>  |- script = "
>  |- compatible = "vendor





This is a question for U-Boot (and barebox).




   images {
          base {
                ...
          };

          addon1 {
                ...
          };

          addon2 {
                ...
          };
    };

    configurations {
          ...
          fdt = "base", "addon1", "addon2";
    };




Is U-Boot's "bootm" command able to dynamically construct
the full DTB from "base" + "addon1" + "addon2"
and pass to the kernel?



When I used overlay from U-Boot command line last time,
I typed complicated commands, following this manual:
https://docs.u-boot.org/en/latest/usage/fdt_overlays.html




One more question to confirm if I can use this
for my practical use-cases.

Is U-Boot able to handle FIT (includes kernel + DTs)
and a separate initrd?

  # bootm  <fit-address>:<conf-name>  <ramdisk-address>


Presumably, it would be difficult to inject initramdisk
into image.fit later, so I am hoping bootm would work like that,
but I did not delve into U-Boot code.



If it works, is it possible to verify the integrity of initrd?
The kernel and DTs inside FIT will be verified, but not sure
if it is possible for ramdisk.





-- 
Best Regards
Masahiro Yamada


From krzysztof.kozlowski at linaro.org  Wed Dec 13 23:36:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 08:36:08 +0100
Subject: [PATCH v3 1/2] dt-bindings: mailbox: zynqmp: extend required list
In-Reply-To: <20231214054224.957336-2-tanmay.shah@amd.com>
References: <20231214054224.957336-1-tanmay.shah@amd.com>
 <20231214054224.957336-2-tanmay.shah@amd.com>
Message-ID: <d7c5af19-dd65-4d60-a414-513a8075897a@linaro.org>

On 14/12/2023 06:42, Tanmay Shah wrote:
> "xlnx,ipi-id" is handled as required property but is
> missing from binding doc required list of mailbox child node.
> Add that to required list. This does not break backward
> compatibility but bug in bindings document.
> 
> Fixes: 4a855a957936 ("dt-bindings: mailbox: zynqmp_ipi: convert to yaml")
> 

No blank lines between tags.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

> Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> ---


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 13 23:37:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 08:37:07 +0100
Subject: [PATCH v3 2/2] dt-bindings: mailbox: add Versal IPI bindings
In-Reply-To: <20231214054224.957336-3-tanmay.shah@amd.com>
References: <20231214054224.957336-1-tanmay.shah@amd.com>
 <20231214054224.957336-3-tanmay.shah@amd.com>
Message-ID: <9f579f6e-b032-4b0c-ba40-a6ef33a3eb45@linaro.org>

On 14/12/2023 06:42, Tanmay Shah wrote:
> Add documentation for AMD-Xilinx Versal platform Inter Processor Interrupt
> controller. Versal IPI controller contains buffer-less IPI which do not
> have buffers for message passing. For such IPI channels message buffers
> are not expected and only notification to/from remote agent is expected.
> 
> Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> ---
> 

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 13 23:42:33 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 08:42:33 +0100
Subject: [PATCH 1/3] dt-bindings: arm: ti: Add bindings for J722S SoCs
In-Reply-To: <20231213124930.3012-2-vaishnav.a@ti.com>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
 <20231213124930.3012-2-vaishnav.a@ti.com>
Message-ID: <f98a5d06-199d-4b3d-bc53-6572a80033e8@linaro.org>

On 13/12/2023 13:49, Vaishnav Achath wrote:
> Add bindings for TI J722S family of devices.
> 
> Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
> ---
>  Documentation/devicetree/bindings/arm/ti/k3.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 13 23:43:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 08:43:12 +0100
Subject: [PATCH v2 1/3] dt-bindings: vendor-prefixes: add Transpeed
In-Reply-To: <20231214015312.17363-2-andre.przywara@arm.com>
References: <20231214015312.17363-1-andre.przywara@arm.com>
 <20231214015312.17363-2-andre.przywara@arm.com>
Message-ID: <6bf12018-6904-451c-8c6d-6643099b2a76@linaro.org>

On 14/12/2023 02:53, Andre Przywara wrote:
> This is a name used by some Chinese TV boxes, add it to the bindings.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From namcao at linutronix.de  Wed Dec 13 23:49:55 2023
From: namcao at linutronix.de (Nam Cao)
Date: Thu, 14 Dec 2023 08:49:55 +0100
Subject: [PATCH v2 2/2] spi: spl022: switch to use default
 spi_transfer_one_message()
In-Reply-To: <CACRpkdZfuKmg8gY1J+prF0L0=S7PSW+0ZuqM3HhNrB1sXcNG5g@mail.gmail.com>
References: <cover.1701274975.git.namcao@linutronix.de>
	<ae1940abd6ff6a9e77b4373cff60007c641a0c6c.1701274975.git.namcao@linutronix.de>
	<CACRpkdZfuKmg8gY1J+prF0L0=S7PSW+0ZuqM3HhNrB1sXcNG5g@mail.gmail.com>
Message-ID: <20231214084955.7245c538@namcao>

On Thu, 14 Dec 2023 01:19:04 +0100 Linus Walleij <linus.walleij at linaro.org> wrote:
> On Wed, Nov 29, 2023 at 5:32?PM Nam Cao <namcao at linutronix.de> wrote:
> > Except for polling mode, this driver's transfer_one_message() makes use
> > of interrupt handler and tasklet. This is problematic because
> > spi_transfer_delay_exec(), who may sleep, is called in interrupt handler
> > and tasklet. This causes the following warning:
> > BUG: sleeping function called from invalid context at drivers/spi/spi.c:1428
> >
> > Switch to use the default spi_transfer_one_message() instead, which
> > calls spi_transfer_delay_exec() appropriately.
> >
> > Signed-off-by: Nam Cao <namcao at linutronix.de>
> > Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> > ---
> > Tested with polling mode and interrupt mode, NOT with DMA mode.
> > Support with testing very appreciated!  
> 
> FWIW I tested this now on a device using DMA for the transfers
> and everything works fine like before.

Thanks for spending time reviewing and testing!

Best regards,
Nam



From krzysztof.kozlowski at linaro.org  Wed Dec 13 23:53:21 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 08:53:21 +0100
Subject: [PATCH 01/11] dt-bindings: display: rockchip,inno-hdmi: Document
 RK3128 compatible
In-Reply-To: <20231213195125.212923-2-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-2-knaerzche@gmail.com>
Message-ID: <c4e394c6-c21f-4102-8c3a-f9530c0ca547@linaro.org>

On 13/12/2023 20:51, Alex Bee wrote:
> Document the compatible for RK3128's HDMI controller block.
> The integration for this SoC is somewhat different here: It needs the PHY's

Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597


> reference clock rate to calculate the ddc bus frequency correctly. This
> clock is part of a power-domain (PD_VIO), so this gets added as an optional
> property too.

If clock is part of power domain, then the power domain must be in the
clock controller, not here. So either you put power domain in wrong
place or you used incorrect reason for a change.

> 
> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> ---
>  .../display/rockchip/rockchip,inno-hdmi.yaml  | 30 +++++++++++++++++--
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> index 96889c86849a..9f00abcbfb38 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> @@ -14,6 +14,7 @@ properties:
>    compatible:
>      enum:
>        - rockchip,rk3036-inno-hdmi
> +      - rockchip,rk3128-inno-hdmi
>  
>    reg:
>      maxItems: 1
> @@ -22,10 +23,21 @@ properties:
>      maxItems: 1
>  
>    clocks:
> -    maxItems: 1
> +    minItems: 1
> +    items:
> +      - description: The HDMI controller main clock
> +      - description: The HDMI PHY reference clock
>  
>    clock-names:
> -    const: pclk
> +    minItems: 1
> +    items:
> +      - const: pclk
> +      - enum:
> +          - pclk
> +          - ref

That's way overcomplicated. Just items listing the names and minItems:
1. See other bindings how this is done.

> +
> +  power-domains:
> +    maxItems: 1

Is it relevant to existing device?

>  
>    ports:
>      $ref: /schemas/graph.yaml#/properties/ports
> @@ -55,6 +67,20 @@ required:
>    - pinctrl-names
>    - ports


Best regards,
Krzysztof



From mripard at kernel.org  Wed Dec 13 23:56:30 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 14 Dec 2023 08:56:30 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <20231213195125.212923-5-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-5-knaerzche@gmail.com>
Message-ID: <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>

Hi Alex,

Thanks for working on this!

On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
> The display controller will always give full range RGB regardless of the
> mode set, but HDMI requires certain modes to be transmitted in limited
> range RGB. This is especially required for HDMI sinks which do not support
> non-standard quantization ranges.
> 
> This enables color space conversion for those modes and sets the
> quantization range accordingly in the AVI infoframe.
> 
> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> ---
>  drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
>  1 file changed, 32 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index 345253e033c5..32626a75723c 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -33,6 +33,7 @@ struct hdmi_data_info {
>  	unsigned int enc_in_format;
>  	unsigned int enc_out_format;
>  	unsigned int colorimetry;
> +	bool rgb_limited_range;
>  };
>  
>  struct inno_hdmi_i2c {
> @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
>  	else
>  		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>  
> +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
> +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> +						   &hdmi->connector, mode,
> +						   hdmi->hdmi_data.rgb_limited_range ?
> +						   HDMI_QUANTIZATION_RANGE_LIMITED :
> +						   HDMI_QUANTIZATION_RANGE_FULL);
> +	} else {
> +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> +		frame.avi.ycc_quantization_range =
> +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> +	}
> +
>  	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
>  }
>  
> @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
>  	if (data->enc_in_format == data->enc_out_format) {
>  		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
>  		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
> -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> -
> -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> -			return 0;
> +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
> +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
> +			    hdmi->hdmi_data.rgb_limited_range) {
> +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
> +				auto_csc = AUTO_CSC_DISABLE;
> +				c0_c2_change = C0_C2_CHANGE_DISABLE;
> +				csc_enable = v_CSC_ENABLE;
> +			} else {
> +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> +				return 0;
> +			}
>  		}
>  	}
>  
> @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>  	else
>  		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
>  
> +	hdmi->hdmi_data.rgb_limited_range =
> +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
> +

This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/

I would appreciate if you could test and merge them into your series.

In particular, there's no need to store the range here: enc_out_format
is always RGB, so you'll always end up calling
drm_hdmi_avi_infoframe_quant_range(), and you'll always have the same csc values.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/cae6a015/attachment.sig>

From n-francis at ti.com  Wed Dec 13 23:56:37 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Thu, 14 Dec 2023 13:26:37 +0530
Subject: [PATCH] arm64: dts: ti: k3-j721e: Add support for DFS in J721E A72
Message-ID: <20231214075637.176586-1-n-francis@ti.com>

Add 2G, 1.5G, 1G, 750M, 500M and 250M as the supported frequencies for
A72. This enables support for Dynamic Frequency Scaling (DFS).

Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
---
Boot logs:
https://gist.github.com/nehamalcom/e3c3d0446f0467e7fd28706f7ffaeea8

J721E SoC has three different speed grade devices (see [1], 7.5
Operating Performance Points) which as of today are indiscernible in
software, users of a different speed grade device must manually change
the DTS to ensure their maximum speed frequency is supported.

[1] https://www.ti.com/lit/gpn/tda4vm

 arch/arm64/boot/dts/ti/k3-j721e.dtsi | 35 ++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721e.dtsi b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
index a200810df54a..fe92879f5812 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
@@ -48,6 +48,9 @@ cpu0: cpu at 0 {
 			d-cache-line-size = <64>;
 			d-cache-sets = <256>;
 			next-level-cache = <&L2_0>;
+			clocks = <&k3_clks 202 2>;
+			clock-names = "cpu";
+			operating-points-v2 = <&cpu0_opp_table>;
 		};
 
 		cpu1: cpu at 1 {
@@ -62,9 +65,41 @@ cpu1: cpu at 1 {
 			d-cache-line-size = <64>;
 			d-cache-sets = <256>;
 			next-level-cache = <&L2_0>;
+			clocks = <&k3_clks 203 0>;
+			clock-names = "cpu";
+			operating-points-v2 = <&cpu0_opp_table>;
 		};
 	};
 
+	cpu0_opp_table: opp-table {
+		compatible = "operating-points-v2";
+
+		opp6-2000000000 {
+			opp-hz = /bits/ 64 <2000000000>;
+		};
+
+		opp5-1500000000 {
+			opp-hz = /bits/ 64 <1500000000>;
+		};
+
+		opp4-1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+		};
+
+		opp3-750000000 {
+			opp-hz = /bits/ 64 <750000000>;
+		};
+
+		opp2-500000000 {
+			opp-hz = /bits/ 64 <500000000>;
+		};
+
+		opp1-250000000 {
+			opp-hz = /bits/ 64 <250000000>;
+		};
+
+	};
+
 	L2_0: l2-cache0 {
 		compatible = "cache";
 		cache-level = <2>;
-- 
2.34.1



From vincent.guittot at linaro.org  Wed Dec 13 23:57:14 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 14 Dec 2023 08:57:14 +0100
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the scheduler
In-Reply-To: <20231214054307.axl33gagxacidjbn@vireshk-i7>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org> <20231214054307.axl33gagxacidjbn@vireshk-i7>
Message-ID: <CAKfTPtDam5eQO1DHxALsCaU53Rtawbfrvswy+z2unnV_eXeVLA@mail.gmail.com>

On Thu, 14 Dec 2023 at 06:43, Viresh Kumar <viresh.kumar at linaro.org> wrote:
>
> On 12-12-23, 15:27, Vincent Guittot wrote:
> > @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
> >       policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
> >       trace_cpu_frequency_limits(policy);
> >
> > +     cpus = policy->related_cpus;
> > +     cpufreq_update_pressure(cpus, policy->max);
> > +
> >       policy->cached_target_freq = UINT_MAX;
>
> One more question, why are you doing this from cpufreq_set_policy ? If
> due to cpufreq cooling or from userspace, we end up limiting the
> maximum possible frequency, will this routine always get called ?

Yes, any update of a FREQ_QOS_MAX ends up calling cpufreq_set_policy()
to update the policy->max


>
> --
> viresh


From geert at linux-m68k.org  Wed Dec 13 23:57:52 2023
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Thu, 14 Dec 2023 08:57:52 +0100
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAK7LNATyD-PeNbaLTjJmU9=koqqE+V6QvFe09c2VrXopWvjpcw@mail.gmail.com>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com> <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
 <20231209152946.GC13421@pendragon.ideasonboard.com> <CAMuHMdVMZs6mnwWBgFwktO=8o=QzROv60cfZe085MhD6HxQjpQ@mail.gmail.com>
 <CAGXv+5Est3FL-XcEL-vB-6zVNas0mqb2cNYa==Yb7W2SQU9xVQ@mail.gmail.com> <CAK7LNATyD-PeNbaLTjJmU9=koqqE+V6QvFe09c2VrXopWvjpcw@mail.gmail.com>
Message-ID: <CAMuHMdXDPSQXNhBH5LCrggfJCWG32v_ZtcRdPfaGRuLj20N+Lg@mail.gmail.com>

Hi Yamada-san,

On Thu, Dec 14, 2023 at 7:12?AM Masahiro Yamada <masahiroy at kernel.org> wrote:
> On Thu, Dec 14, 2023 at 1:03?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> > On Sun, Dec 10, 2023 at 1:31?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > On Sat, Dec 9, 2023 at 4:29?PM Laurent Pinchart
> > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > On Thu, Dec 7, 2023 at 11:38?PM Laurent Pinchart
> > > > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > > performance.
> > > > > > > > >
> > > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > > >
> > > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > > filenames or other workarounds.
> > > > > > > > >
> > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > >
> > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > >
> > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > > $(obj)/image.fit
> > > > > > > > >
> > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > > >
> > > > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > > > balance between what makes sense for the kernel and the features that
> > > > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > > > to delay merging this series.
> > > > > > > >
> > > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > > > to a second question: would you consider merging extensions to this
> > > > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > > > users who manually invoke the script ? More generally, is the script
> > > > > > >
> > > > > > > We'd also be interested in some customization, though in a different way.
> > > > > > > We imagine having a rule file that says X compatible string should map
> > > > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > > > carry all the possible second source components, like different display
> > > > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > > > >
> > > > > > Do you envision the "mapping" compatible string mapping to a config
> > > > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > > > >
> > > > > That's exactly the idea. The mapping compatible string could be untied
> > > > > from the base board's compatible string if needed (which we probably do).
> > > > >
> > > > > So something like:
> > > > >
> > > > > config {
> > > > >     config-1 {
> > > > >         compatible = "google,krane-sku0";
> > > > >         fdt = "krane-baseboard", "krane-sku0-overlay";
> > > > >     };
> > > > > };
> > > > >
> > > > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > > > between the SKUs, in this case the display panel and MIPI camera (not
> > > > > upstreamed) that applies to SKU0 in particular.
> > > >
> > > > The kernel DT makefiles already contain information on what overlays to
> > > > apply to what base boards, in order to test the overlays and produce
> > > > "full" DTBs. Maybe that information could be leveraged to create the
> > > > configurations in the FIT image ?
> > >
> > > Although the "full" DTBs created may only be a subset of all possible
> > > combinations (I believe Rob just started with creating one "full" DTB
> > > for each overlay, cfr. the additions I made in commit a09c3e105a208580
> > > ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> > > definitely be a start.
> > >
> > > Now, since the kernel build system already creates "full" DTBs, does
> > > that mean that all of the base DTBs, overlays, and "full" DTBs will
> > > end up in the FIT image?
> >
> > I suppose we could add an option to the packing tool to be able to _not_
> > add the "full" DTBs if they can also be assembled with a base DTB and
> > overlays. Think of it as a firmware compatibility option: if the firmware
> > supports overlays, then you almost always want the deconstructed parts,
> > not the fully assembled ones. Vice versa.
> >
> > If we don't we could end up with two configurations that have the same
> > compatible string?
>
> Right.
>
> We would end up with such situations because applying
> an overlay does not change the compatible string.

That is correct.  Which is one of the reasons for not using overlays
for this, cfr. the details in my reply in the other thread
"Re: Proposal: FIT support for extension boards / overlays"
https://lore.kernel.org/all/CAMuHMdXQdMeXUOAAw5nDO4+q5_HFvUc86Wi8ykMwjUwPex6wvQ at mail.gmail.com/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From mripard at kernel.org  Thu Dec 14 00:05:58 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 14 Dec 2023 09:05:58 +0100
Subject: [PATCH 07/11] drm/rockchip: inno_hdmi: Add basic mode validation
In-Reply-To: <20231213195125.212923-8-knaerzche@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-8-knaerzche@gmail.com>
Message-ID: <wz4e43ateg3gb7745mz22wwyruwavevvpfbqsdxeynejcjxhzn@qbqldsnkktei>

Hi,

On Wed, Dec 13, 2023 at 08:51:21PM +0100, Alex Bee wrote:
> As per TRM this controller supports pixelclocks starting from 25 MHz. The
> maximum supported pixelclocks are defined by the phy configurations we
> have. Also it can't support modes that require doubled clocks.
> If there is a phy reference clock we can additionally validate against
> VESA DMT's recommendations.
> Those checks are added to the mode_valid hook of the connector and
> encoder's mode_fixup hook.
> 
> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> ---
>  drivers/gpu/drm/rockchip/inno_hdmi.c | 38 ++++++++++++++++++++++++++--
>  1 file changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index f7f0bec725f9..2f839ff31c1c 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -38,6 +38,8 @@ struct inno_hdmi_variant {
>  	struct inno_hdmi_phy_config *default_phy_config;
>  };
>  
> +#define INNO_HDMI_MIN_TMDS_CLOCK  25000000U
> +
>  struct hdmi_data_info {
>  	int vic;
>  	bool sink_has_audio;
> @@ -572,6 +574,34 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>  	return 0;
>  }
>  
> +static enum drm_mode_status inno_hdmi_mode_valid(struct inno_hdmi *hdmi,
> +						 struct drm_display_mode *mode)
> +{

So, mode_valid is only called to filter out the modes retrieved by
get_modes, but it won't be called when userspace programs a mode. That's
atomic_check's job.

So you probably want to create a shared function between atomic_check
and mode_valid, and call it from both places (or call mode_valid from
atomic_check).

> +	/* No support for double-clock modes */
> +	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> +		return MODE_BAD;
> +
> +	unsigned int mpixelclk = mode->clock * 1000;

Variables should be declared at the top of the function.

> +	if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
> +		return MODE_CLOCK_LOW;

You probably want to check the max TMDS clock too?

> +	if (inno_hdmi_find_phy_config(hdmi, mpixelclk) < 0)
> +		return MODE_CLOCK_HIGH;
> +
> +	if (hdmi->refclk) {
> +		long refclk = clk_round_rate(hdmi->refclk, mpixelclk);
> +		unsigned int max_tolerance = mpixelclk / 5000;
> +
> +		/* Vesa DMT standard mentions +/- 0.5% max tolerance */
> +		if (abs(refclk - mpixelclk) > max_tolerance ||
> +		    mpixelclk - refclk > max_tolerance;
> +			return MODE_NOCLOCK;

You should use abs_diff here. abs() will get confused by the unsigned vs
signed comparison.

> +	}
> +
> +	return MODE_OK;
> +}
> +
>  static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
>  				       struct drm_display_mode *mode,
>  				       struct drm_display_mode *adj_mode)
> @@ -602,7 +632,9 @@ static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
>  					 const struct drm_display_mode *mode,
>  					 struct drm_display_mode *adj_mode)
>  {
> -	return true;
> +	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
> +
> +	return inno_hdmi_mode_valid(hdmi, adj_mode) == MODE_OK;
>  }

Why do you call mode_valid in mode_fixup?

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/203c756a/attachment.sig>

From lukasz.luba at arm.com  Thu Dec 14 00:22:10 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Thu, 14 Dec 2023 08:22:10 +0000
Subject: [PATCH 0/5] Rework system pressure interface to the scheduler
In-Reply-To: <20231212142730.998913-1-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
Message-ID: <47b4cbcb-d33d-4699-a148-0108cf734e23@arm.com>

Hi Vincent,

I've been waiting for this feature, thanks!


On 12/12/23 14:27, Vincent Guittot wrote:
> Following the consolidation and cleanup of CPU capacity in [1], this serie
> reworks how the scheduler gets the pressures on CPUs. We need to take into
> account all pressures applied by cpufreq on the compute capacity of a CPU
> for dozens of ms or more and not only cpufreq cooling device or HW
> mitigiations. we split the pressure applied on CPU's capacity in 2 parts:
> - one from cpufreq and freq_qos
> - one from HW high freq mitigiation.
> 
> The next step will be to add a dedicated interface for long standing
> capping of the CPU capacity (i.e. for seconds or more) like the
> scaling_max_freq of cpufreq sysfs. The latter is already taken into
> account by this serie but as a temporary pressure which is not always the
> best choice when we know that it will happen for seconds or more.
> 
> [1] https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot at linaro.org/
> 
> Vincent Guittot (4):
>    cpufreq: Add a cpufreq pressure feedback for the scheduler
>    sched: Take cpufreq feedback into account
>    thermal/cpufreq: Remove arch_update_thermal_pressure()
>    sched: Rename arch_update_thermal_pressure into
>      arch_update_hw_pressure
> 
>   arch/arm/include/asm/topology.h               |  6 +--
>   arch/arm64/include/asm/topology.h             |  6 +--
>   drivers/base/arch_topology.c                  | 26 ++++-----
>   drivers/cpufreq/cpufreq.c                     | 48 +++++++++++++++++
>   drivers/cpufreq/qcom-cpufreq-hw.c             |  4 +-
>   drivers/thermal/cpufreq_cooling.c             |  3 --
>   include/linux/arch_topology.h                 |  8 +--
>   include/linux/cpufreq.h                       | 10 ++++
>   include/linux/sched/topology.h                |  8 +--
>   .../{thermal_pressure.h => hw_pressure.h}     | 14 ++---
>   include/trace/events/sched.h                  |  2 +-
>   init/Kconfig                                  | 12 ++---
>   kernel/sched/core.c                           |  8 +--
>   kernel/sched/fair.c                           | 53 ++++++++++---------
>   kernel/sched/pelt.c                           | 18 +++----
>   kernel/sched/pelt.h                           | 16 +++---
>   kernel/sched/sched.h                          |  4 +-
>   17 files changed, 152 insertions(+), 94 deletions(-)
>   rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
> 

I would like to test it, but something worries me. Why there is 0/5 in
this subject and only 4 patches?

Could you tell me your base branch that I can apply this, please?

Regards,
Lukasz


From dario.binacchi at amarulasolutions.com  Thu Dec 14 00:24:03 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Thu, 14 Dec 2023 09:24:03 +0100
Subject: [PATCH v8 0/3] Add displays support for bsh-smm-s2/pro boards
Message-ID: <20231214082457.18737-1-dario.binacchi@amarulasolutions.com>

The series adds drivers for the displays used by bsh-smm-s2/pro boards.
This required applying some patches to the samsung-dsim driver and the
drm_bridge.c module.

Changes in v8:
- Move the 'status' property to the end of the list of nodes:
  - pwm1
  - lcdif
  - mipi_dsi
- Add a newline between properties and child node (mipi_dsi_out).
- Sort the iomuxc node alphabetically
- Rename pwm1grp to blgrp

Changes in v7:
- Drop [3/4] dt-bindings: display: panel: Add synaptics r63353 panel controller
  because applied.

Changes in v6:
- Drop patches:
  - [06/10] drm/panel: Add Synaptics R63353 panel driver
  - [07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  - [08/10] drm/panel: Add Ilitek ILI9805 panel driver
  - [09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  Because applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)
  Drop patches:
  - [01/10] drm/bridge: Fix bridge disable logic
  - [02/10] drm/bridge: Fix a use case in the bridge disable logic
  Because they are wrong

Changes in v3:
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Dario Binacchi (2):
  drm: bridge: samsung-dsim: enter display mode in the enable() callback
  drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Michael Trimarchi (1):
  arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup

 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++++++++++++++
 drivers/gpu/drm/bridge/samsung-dsim.c         |  14 +-
 3 files changed, 133 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi

-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Thu Dec 14 00:24:06 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Thu, 14 Dec 2023 09:24:06 +0100
Subject: [PATCH v8 3/3] arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup
In-Reply-To: <20231214082457.18737-1-dario.binacchi@amarulasolutions.com>
References: <20231214082457.18737-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231214082457.18737-4-dario.binacchi@amarulasolutions.com>

From: Michael Trimarchi <michael at amarulasolutions.com>

Add the display and nodes required for its operation.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>

---

Changes in v8:
- Move the 'status' property to the end of the list of nodes:
  - pwm1
  - lcdif
  - mipi_dsi
- Add a newline between properties and child node (mipi_dsi_out).
- Sort the iomuxc node alphabetically
- Rename pwm1grp to blgrp

Changes in v7:
- Drop [3/4] dt-bindings: display: panel: Add synaptics r63353 panel controller
  because applied.

Changes in v6:
- Drop patches:
  - [06/10] drm/panel: Add Synaptics R63353 panel driver
  - [07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  - [08/10] drm/panel: Add Ilitek ILI9805 panel driver
  - [09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  Because applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)
  Drop patches:
  - [01/10] drm/bridge: Fix bridge disable logic
  - [02/10] drm/bridge: Fix a use case in the bridge disable logic
  Because they are wrong

Changes in v3:
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++++++++++++++++++
 2 files changed, 122 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
index 22a754d438f1..bbb07c650da9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-common.dtsi
@@ -7,6 +7,7 @@
 /dts-v1/;
 
 #include "imx8mn.dtsi"
+#include "imx8mn-bsh-smm-s2-display.dtsi"
 
 / {
 	chosen {
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
new file mode 100644
index 000000000000..7675583a6b67
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 BSH
+ */
+
+/ {
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm1 0 700000 0>;	/* 700000 ns = 1337Hz */
+		brightness-levels = <0 100>;
+		num-interpolated-steps = <100>;
+		default-brightness-level = <50>;
+		status = "okay";
+	};
+
+	reg_3v3_dvdd: regulator-3v3-O3 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_dvdd>;
+		regulator-name = "3v3-dvdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
+	};
+
+	reg_v3v3_avdd: regulator-3v3-O2 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_avdd>;
+		regulator-name = "3v3-avdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 5 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pwm1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_bl>;
+	status = "okay";
+};
+
+&lcdif {
+	assigned-clocks = <&clk IMX8MN_VIDEO_PLL1>;
+	assigned-clock-rates = <594000000>;
+	status = "okay";
+};
+
+&pgc_dispmix {
+	assigned-clocks = <&clk IMX8MN_CLK_DISP_AXI>, <&clk IMX8MN_CLK_DISP_APB>;
+	assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_1000M>, <&clk IMX8MN_SYS_PLL1_800M>;
+	assigned-clock-rates = <500000000>, <200000000>;
+};
+
+&mipi_dsi {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	samsung,esc-clock-frequency = <20000000>;
+	samsung,pll-clock-frequency = <12000000>;
+	status = "okay";
+
+	panel at 0 {
+		compatible = "sharp,ls068b3sx02", "syna,r63353";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel>;
+		reg = <0>;
+
+		backlight = <&backlight>;
+		dvdd-supply = <&reg_3v3_dvdd>;
+		avdd-supply = <&reg_v3v3_avdd>;
+		reset-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+
+		port {
+			panel_in: endpoint {
+				remote-endpoint = <&mipi_dsi_out>;
+			};
+		};
+
+	};
+
+	ports {
+		port at 1 {
+			reg = <1>;
+
+			mipi_dsi_out: endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+	};
+};
+
+&gpu {
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_avdd: avddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO05_GPIO1_IO5	0x16	/* VDD 3V3_VO2 */
+		>;
+	};
+
+	/* This is for both PWM and voltage regulators for display */
+	pinctrl_bl: blgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO01_PWM1_OUT	0x16
+		>;
+	};
+
+	pinctrl_dvdd: dvddgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x16	/* VDD 3V3_VO3 */
+		>;
+	};
+
+	pinctrl_panel: panelgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_SAI3_RXC_GPIO4_IO29	0x16	/* panel reset */
+		>;
+	};
+};
-- 
2.43.0



From vincent.guittot at linaro.org  Thu Dec 14 00:29:37 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 14 Dec 2023 09:29:37 +0100
Subject: [PATCH 0/5] Rework system pressure interface to the scheduler
In-Reply-To: <47b4cbcb-d33d-4699-a148-0108cf734e23@arm.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org> <47b4cbcb-d33d-4699-a148-0108cf734e23@arm.com>
Message-ID: <CAKfTPtATWSWdk1dhnMvBqTZigtprv7d_0j0zpf48WfVDfMit5g@mail.gmail.com>

On Thu, 14 Dec 2023 at 09:21, Lukasz Luba <lukasz.luba at arm.com> wrote:
>
> Hi Vincent,
>
> I've been waiting for this feature, thanks!
>
>
> On 12/12/23 14:27, Vincent Guittot wrote:
> > Following the consolidation and cleanup of CPU capacity in [1], this serie
> > reworks how the scheduler gets the pressures on CPUs. We need to take into
> > account all pressures applied by cpufreq on the compute capacity of a CPU
> > for dozens of ms or more and not only cpufreq cooling device or HW
> > mitigiations. we split the pressure applied on CPU's capacity in 2 parts:
> > - one from cpufreq and freq_qos
> > - one from HW high freq mitigiation.
> >
> > The next step will be to add a dedicated interface for long standing
> > capping of the CPU capacity (i.e. for seconds or more) like the
> > scaling_max_freq of cpufreq sysfs. The latter is already taken into
> > account by this serie but as a temporary pressure which is not always the
> > best choice when we know that it will happen for seconds or more.
> >
> > [1] https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot at linaro.org/
> >
> > Vincent Guittot (4):
> >    cpufreq: Add a cpufreq pressure feedback for the scheduler
> >    sched: Take cpufreq feedback into account
> >    thermal/cpufreq: Remove arch_update_thermal_pressure()
> >    sched: Rename arch_update_thermal_pressure into
> >      arch_update_hw_pressure
> >
> >   arch/arm/include/asm/topology.h               |  6 +--
> >   arch/arm64/include/asm/topology.h             |  6 +--
> >   drivers/base/arch_topology.c                  | 26 ++++-----
> >   drivers/cpufreq/cpufreq.c                     | 48 +++++++++++++++++
> >   drivers/cpufreq/qcom-cpufreq-hw.c             |  4 +-
> >   drivers/thermal/cpufreq_cooling.c             |  3 --
> >   include/linux/arch_topology.h                 |  8 +--
> >   include/linux/cpufreq.h                       | 10 ++++
> >   include/linux/sched/topology.h                |  8 +--
> >   .../{thermal_pressure.h => hw_pressure.h}     | 14 ++---
> >   include/trace/events/sched.h                  |  2 +-
> >   init/Kconfig                                  | 12 ++---
> >   kernel/sched/core.c                           |  8 +--
> >   kernel/sched/fair.c                           | 53 ++++++++++---------
> >   kernel/sched/pelt.c                           | 18 +++----
> >   kernel/sched/pelt.h                           | 16 +++---
> >   kernel/sched/sched.h                          |  4 +-
> >   17 files changed, 152 insertions(+), 94 deletions(-)
> >   rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
> >
>
> I would like to test it, but something worries me. Why there is 0/5 in
> this subject and only 4 patches?

I removed a patch from the series but copied/pasted the cover letter
subject without noticing the /5 instead of /4

>
> Could you tell me your base branch that I can apply this, please?

It applies on top of tip/sched/core + [1]
and you can find it here:
https://git.linaro.org/people/vincent.guittot/kernel.git/log/?h=sched/system-pressure

>
> Regards,
> Lukasz


From lukasz.luba at arm.com  Thu Dec 14 00:31:19 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Thu, 14 Dec 2023 08:31:19 +0000
Subject: [PATCH 4/4] sched: Rename arch_update_thermal_pressure into
 arch_update_hw_pressure
In-Reply-To: <20231212142730.998913-5-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-5-vincent.guittot@linaro.org>
Message-ID: <274a6562-46c9-4b03-9295-c24e5eb9e6cd@arm.com>


On 12/12/23 14:27, Vincent Guittot wrote:
> Now that cpufreq provides a pressure value to the scheduler, rename
> arch_update_thermal_pressure into hw pressure to reflect that it returns
> a pressure applied by HW with a high frequency and which needs filtering.

I would elaborte this meaning 'filtering' here. Something like:
'... high frequency and which needs filtering to smooth the singal and
get an average value. That reflects available capacity of the CPU in
longer period'

> This pressure is not always related to thermal mitigation but can also be
> generated by max current limitation as an example.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>   arch/arm/include/asm/topology.h               |  6 ++---
>   arch/arm64/include/asm/topology.h             |  6 ++---
>   drivers/base/arch_topology.c                  | 26 +++++++++----------
>   drivers/cpufreq/qcom-cpufreq-hw.c             |  4 +--
>   include/linux/arch_topology.h                 |  8 +++---
>   include/linux/sched/topology.h                |  8 +++---
>   .../{thermal_pressure.h => hw_pressure.h}     | 14 +++++-----
>   include/trace/events/sched.h                  |  2 +-
>   init/Kconfig                                  | 12 ++++-----
>   kernel/sched/core.c                           |  8 +++---
>   kernel/sched/fair.c                           | 12 ++++-----
>   kernel/sched/pelt.c                           | 18 ++++++-------
>   kernel/sched/pelt.h                           | 16 ++++++------
>   kernel/sched/sched.h                          |  4 +--
>   14 files changed, 72 insertions(+), 72 deletions(-)
>   rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
> 
> diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
> index 853c4f81ba4a..e175e8596b5d 100644
> --- a/arch/arm/include/asm/topology.h
> +++ b/arch/arm/include/asm/topology.h
> @@ -22,9 +22,9 @@
>   /* Enable topology flag updates */
>   #define arch_update_cpu_topology topology_update_cpu_topology
>   
> -/* Replace task scheduler's default thermal pressure API */
> -#define arch_scale_thermal_pressure topology_get_thermal_pressure
> -#define arch_update_thermal_pressure	topology_update_thermal_pressure
> +/* Replace task scheduler's default hw pressure API */
> +#define arch_scale_hw_pressure topology_get_hw_pressure
> +#define arch_update_hw_pressure	topology_update_hw_pressure
>   
>   #else
>   
> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> index a323b109b9c4..a427650bdfba 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -35,9 +35,9 @@ void update_freq_counters_refs(void);
>   /* Enable topology flag updates */
>   #define arch_update_cpu_topology topology_update_cpu_topology
>   
> -/* Replace task scheduler's default thermal pressure API */
> -#define arch_scale_thermal_pressure topology_get_thermal_pressure
> -#define arch_update_thermal_pressure	topology_update_thermal_pressure
> +/* Replace task scheduler's default hw pressure API */

s/hw/HW/ ?

> +#define arch_scale_hw_pressure topology_get_hw_pressure
> +#define arch_update_hw_pressure	topology_update_hw_pressure
>   
>   #include <asm-generic/topology.h>
>   
> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> index 0906114963ff..3d8dc9d5c3ad 100644
> --- a/drivers/base/arch_topology.c
> +++ b/drivers/base/arch_topology.c
> @@ -22,7 +22,7 @@
>   #include <linux/units.h>
>   
>   #define CREATE_TRACE_POINTS
> -#include <trace/events/thermal_pressure.h>
> +#include <trace/events/hw_pressure.h>
>   
>   static DEFINE_PER_CPU(struct scale_freq_data __rcu *, sft_data);
>   static struct cpumask scale_freq_counters_mask;
> @@ -160,26 +160,26 @@ void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity)
>   	per_cpu(cpu_scale, cpu) = capacity;
>   }
>   
> -DEFINE_PER_CPU(unsigned long, thermal_pressure);
> +DEFINE_PER_CPU(unsigned long, hw_pressure);
>   
>   /**
> - * topology_update_thermal_pressure() - Update thermal pressure for CPUs
> + * topology_update_hw_pressure() - Update hw pressure for CPUs

same here: HW?

>    * @cpus        : The related CPUs for which capacity has been reduced
>    * @capped_freq : The maximum allowed frequency that CPUs can run at
>    *
> - * Update the value of thermal pressure for all @cpus in the mask. The
> + * Update the value of hw pressure for all @cpus in the mask. The

HW?

>    * cpumask should include all (online+offline) affected CPUs, to avoid
>    * operating on stale data when hot-plug is used for some CPUs. The
>    * @capped_freq reflects the currently allowed max CPUs frequency due to
> - * thermal capping. It might be also a boost frequency value, which is bigger
> + * hw capping. It might be also a boost frequency value, which is bigger

HW?

>    * than the internal 'capacity_freq_ref' max frequency. In such case the
>    * pressure value should simply be removed, since this is an indication that
> - * there is no thermal throttling. The @capped_freq must be provided in kHz.
> + * there is no hw throttling. The @capped_freq must be provided in kHz.

HW?

>    */
> -void topology_update_thermal_pressure(const struct cpumask *cpus,
> +void topology_update_hw_pressure(const struct cpumask *cpus,
>   				      unsigned long capped_freq)
>   {
> -	unsigned long max_capacity, capacity, th_pressure;
> +	unsigned long max_capacity, capacity, hw_pressure;
>   	u32 max_freq;
>   	int cpu;
>   
> @@ -189,21 +189,21 @@ void topology_update_thermal_pressure(const struct cpumask *cpus,
>   
>   	/*
>   	 * Handle properly the boost frequencies, which should simply clean
> -	 * the thermal pressure value.
> +	 * the hw pressure value.

HW?

>   	 */
>   	if (max_freq <= capped_freq)
>   		capacity = max_capacity;
>   	else
>   		capacity = mult_frac(max_capacity, capped_freq, max_freq);
>   
> -	th_pressure = max_capacity - capacity;
> +	hw_pressure = max_capacity - capacity;
>   
> -	trace_thermal_pressure_update(cpu, th_pressure);
> +	trace_hw_pressure_update(cpu, hw_pressure);
>   
>   	for_each_cpu(cpu, cpus)
> -		WRITE_ONCE(per_cpu(thermal_pressure, cpu), th_pressure);
> +		WRITE_ONCE(per_cpu(hw_pressure, cpu), hw_pressure);
>   }
> -EXPORT_SYMBOL_GPL(topology_update_thermal_pressure);
> +EXPORT_SYMBOL_GPL(topology_update_hw_pressure);
>   
>   static ssize_t cpu_capacity_show(struct device *dev,
>   				 struct device_attribute *attr,
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index 70b0f21968a0..a619202ba81d 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -347,8 +347,8 @@ static void qcom_lmh_dcvs_notify(struct qcom_cpufreq_data *data)
>   
>   	throttled_freq = freq_hz / HZ_PER_KHZ;
>   
> -	/* Update thermal pressure (the boost frequencies are accepted) */
> -	arch_update_thermal_pressure(policy->related_cpus, throttled_freq);
> +	/* Update hw pressure (the boost frequencies are accepted) */

HW?

> +	arch_update_hw_pressure(policy->related_cpus, throttled_freq);
>   

[snip]

>   
>   	if (housekeeping_cpu(cpu, HK_TYPE_TICK))
> @@ -5669,8 +5669,8 @@ void scheduler_tick(void)
>   	rq_lock(rq, &rf);
>   
>   	update_rq_clock(rq);
> -	thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
> -	update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure);
> +	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
> +	update_hw_load_avg(rq_clock_task(rq), rq, hw_pressure);

We switch to task clock here, could you tell me why?
Don't we have to maintain the boot command parameter for the shift?

>   	curr->sched_class->task_tick(rq, curr, 0);
>   	if (sched_feat(LATENCY_WARN))
>   		resched_latency = cpu_resched_latency(rq);
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 11d3be829302..07050955d6e0 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4936,7 +4936,7 @@ static inline unsigned long get_actual_cpu_capacity(int cpu)
>   {
>   	unsigned long capacity = arch_scale_cpu_capacity(cpu);
>   
> -	capacity -= max(thermal_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
> +	capacity -= max(hw_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
>   
>   	return capacity;
>   }
> @@ -4968,7 +4968,7 @@ static inline int util_fits_cpu(unsigned long util,
>   	 * Similarly if a task is capped to arch_scale_cpu_capacity(little_cpu), it
>   	 * should fit a little cpu even if there's some pressure.
>   	 *
> -	 * Only exception is for thermal pressure since it has a direct impact
> +	 * Only exception is for hw or cpufreq pressure since it has a direct impact

HW?

>   	 * on available OPP of the system.
>   	 *
>   	 * We honour it for uclamp_min only as a drop in performance level
> @@ -9224,7 +9224,7 @@ static inline bool others_have_blocked(struct rq *rq)
>   	if (READ_ONCE(rq->avg_dl.util_avg))
>   		return true;
>   
> -	if (thermal_load_avg(rq))
> +	if (hw_load_avg(rq))
>   		return true;
>   
>   #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
> @@ -9256,7 +9256,7 @@ static bool __update_blocked_others(struct rq *rq, bool *done)
>   {
>   	const struct sched_class *curr_class;
>   	u64 now = rq_clock_pelt(rq);
> -	unsigned long thermal_pressure;
> +	unsigned long hw_pressure;
>   	bool decayed;
>   
>   	/*
> @@ -9265,11 +9265,11 @@ static bool __update_blocked_others(struct rq *rq, bool *done)
>   	 */
>   	curr_class = rq->curr->sched_class;
>   
> -	thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
> +	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
>   
>   	decayed = update_rt_rq_load_avg(now, rq, curr_class == &rt_sched_class) |
>   		  update_dl_rq_load_avg(now, rq, curr_class == &dl_sched_class) |
> -		  update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure) |
> +		  update_hw_load_avg(now, rq, hw_pressure) |

Here also the rq_clock_thermal() is not used anymore. Shouldn't we
remove the rq_clock_thermal() if not used anymore (I cannot se this in
the patch)?

>   		  update_irq_load_avg(rq, 0);
>   
>   	if (others_have_blocked(rq))

[snip]

> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index e58a54bda77d..7eaf186d071e 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1078,8 +1078,8 @@ struct rq {
>   #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
>   	struct sched_avg	avg_irq;
>   #endif
> -#ifdef CONFIG_SCHED_THERMAL_PRESSURE
> -	struct sched_avg	avg_thermal;
> +#ifdef CONFIG_SCHED_HW_PRESSURE
> +	struct sched_avg	avg_hw;
>   #endif
>   	u64			idle_stamp;
>   	u64			avg_idle;

I don't see that rq_clock_thermal() removal in this header.
Maybe I miss some patch?

BTW, I like the name 'HW pressure' for this information/signal.


From lukasz.luba at arm.com  Thu Dec 14 00:32:38 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Thu, 14 Dec 2023 08:32:38 +0000
Subject: [PATCH 0/5] Rework system pressure interface to the scheduler
In-Reply-To: <CAKfTPtATWSWdk1dhnMvBqTZigtprv7d_0j0zpf48WfVDfMit5g@mail.gmail.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <47b4cbcb-d33d-4699-a148-0108cf734e23@arm.com>
 <CAKfTPtATWSWdk1dhnMvBqTZigtprv7d_0j0zpf48WfVDfMit5g@mail.gmail.com>
Message-ID: <2c2fad2b-89ce-437e-96b3-f06e6f99639f@arm.com>



On 12/14/23 08:29, Vincent Guittot wrote:
> On Thu, 14 Dec 2023 at 09:21, Lukasz Luba <lukasz.luba at arm.com> wrote:
>>
>> Hi Vincent,
>>
>> I've been waiting for this feature, thanks!
>>
>>
>> On 12/12/23 14:27, Vincent Guittot wrote:
>>> Following the consolidation and cleanup of CPU capacity in [1], this serie
>>> reworks how the scheduler gets the pressures on CPUs. We need to take into
>>> account all pressures applied by cpufreq on the compute capacity of a CPU
>>> for dozens of ms or more and not only cpufreq cooling device or HW
>>> mitigiations. we split the pressure applied on CPU's capacity in 2 parts:
>>> - one from cpufreq and freq_qos
>>> - one from HW high freq mitigiation.
>>>
>>> The next step will be to add a dedicated interface for long standing
>>> capping of the CPU capacity (i.e. for seconds or more) like the
>>> scaling_max_freq of cpufreq sysfs. The latter is already taken into
>>> account by this serie but as a temporary pressure which is not always the
>>> best choice when we know that it will happen for seconds or more.
>>>
>>> [1] https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot at linaro.org/
>>>
>>> Vincent Guittot (4):
>>>     cpufreq: Add a cpufreq pressure feedback for the scheduler
>>>     sched: Take cpufreq feedback into account
>>>     thermal/cpufreq: Remove arch_update_thermal_pressure()
>>>     sched: Rename arch_update_thermal_pressure into
>>>       arch_update_hw_pressure
>>>
>>>    arch/arm/include/asm/topology.h               |  6 +--
>>>    arch/arm64/include/asm/topology.h             |  6 +--
>>>    drivers/base/arch_topology.c                  | 26 ++++-----
>>>    drivers/cpufreq/cpufreq.c                     | 48 +++++++++++++++++
>>>    drivers/cpufreq/qcom-cpufreq-hw.c             |  4 +-
>>>    drivers/thermal/cpufreq_cooling.c             |  3 --
>>>    include/linux/arch_topology.h                 |  8 +--
>>>    include/linux/cpufreq.h                       | 10 ++++
>>>    include/linux/sched/topology.h                |  8 +--
>>>    .../{thermal_pressure.h => hw_pressure.h}     | 14 ++---
>>>    include/trace/events/sched.h                  |  2 +-
>>>    init/Kconfig                                  | 12 ++---
>>>    kernel/sched/core.c                           |  8 +--
>>>    kernel/sched/fair.c                           | 53 ++++++++++---------
>>>    kernel/sched/pelt.c                           | 18 +++----
>>>    kernel/sched/pelt.h                           | 16 +++---
>>>    kernel/sched/sched.h                          |  4 +-
>>>    17 files changed, 152 insertions(+), 94 deletions(-)
>>>    rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
>>>
>>
>> I would like to test it, but something worries me. Why there is 0/5 in
>> this subject and only 4 patches?
> 
> I removed a patch from the series but copied/pasted the cover letter
> subject without noticing the /5 instead of /4

OK

> 
>>
>> Could you tell me your base branch that I can apply this, please?
> 
> It applies on top of tip/sched/core + [1]
> and you can find it here:
> https://git.linaro.org/people/vincent.guittot/kernel.git/log/?h=sched/system-pressure

Thanks for the info and handy link.


From vincent.guittot at linaro.org  Thu Dec 14 00:36:00 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 14 Dec 2023 09:36:00 +0100
Subject: [PATCH 4/4] sched: Rename arch_update_thermal_pressure into arch_update_hw_pressure
In-Reply-To: <274a6562-46c9-4b03-9295-c24e5eb9e6cd@arm.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-5-vincent.guittot@linaro.org> <274a6562-46c9-4b03-9295-c24e5eb9e6cd@arm.com>
Message-ID: <CAKfTPtDKRfF7QzwoDwkGKZ_DJS3ewBncifC37LADfNJwtQfiYA@mail.gmail.com>

On Thu, 14 Dec 2023 at 09:30, Lukasz Luba <lukasz.luba at arm.com> wrote:
>
>
> On 12/12/23 14:27, Vincent Guittot wrote:
> > Now that cpufreq provides a pressure value to the scheduler, rename
> > arch_update_thermal_pressure into hw pressure to reflect that it returns
> > a pressure applied by HW with a high frequency and which needs filtering.
>
> I would elaborte this meaning 'filtering' here. Something like:
> '... high frequency and which needs filtering to smooth the singal and
> get an average value. That reflects available capacity of the CPU in
> longer period'

Ok I will update the commit message to provide more details

>
> > This pressure is not always related to thermal mitigation but can also be
> > generated by max current limitation as an example.
> >
> > Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> > ---
> >   arch/arm/include/asm/topology.h               |  6 ++---
> >   arch/arm64/include/asm/topology.h             |  6 ++---
> >   drivers/base/arch_topology.c                  | 26 +++++++++----------
> >   drivers/cpufreq/qcom-cpufreq-hw.c             |  4 +--
> >   include/linux/arch_topology.h                 |  8 +++---
> >   include/linux/sched/topology.h                |  8 +++---
> >   .../{thermal_pressure.h => hw_pressure.h}     | 14 +++++-----
> >   include/trace/events/sched.h                  |  2 +-
> >   init/Kconfig                                  | 12 ++++-----
> >   kernel/sched/core.c                           |  8 +++---
> >   kernel/sched/fair.c                           | 12 ++++-----
> >   kernel/sched/pelt.c                           | 18 ++++++-------
> >   kernel/sched/pelt.h                           | 16 ++++++------
> >   kernel/sched/sched.h                          |  4 +--
> >   14 files changed, 72 insertions(+), 72 deletions(-)
> >   rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
> >
> > diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
> > index 853c4f81ba4a..e175e8596b5d 100644
> > --- a/arch/arm/include/asm/topology.h
> > +++ b/arch/arm/include/asm/topology.h
> > @@ -22,9 +22,9 @@
> >   /* Enable topology flag updates */
> >   #define arch_update_cpu_topology topology_update_cpu_topology
> >
> > -/* Replace task scheduler's default thermal pressure API */
> > -#define arch_scale_thermal_pressure topology_get_thermal_pressure
> > -#define arch_update_thermal_pressure topology_update_thermal_pressure
> > +/* Replace task scheduler's default hw pressure API */
> > +#define arch_scale_hw_pressure topology_get_hw_pressure
> > +#define arch_update_hw_pressure      topology_update_hw_pressure
> >
> >   #else
> >
> > diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> > index a323b109b9c4..a427650bdfba 100644
> > --- a/arch/arm64/include/asm/topology.h
> > +++ b/arch/arm64/include/asm/topology.h
> > @@ -35,9 +35,9 @@ void update_freq_counters_refs(void);
> >   /* Enable topology flag updates */
> >   #define arch_update_cpu_topology topology_update_cpu_topology
> >
> > -/* Replace task scheduler's default thermal pressure API */
> > -#define arch_scale_thermal_pressure topology_get_thermal_pressure
> > -#define arch_update_thermal_pressure topology_update_thermal_pressure
> > +/* Replace task scheduler's default hw pressure API */
>
> s/hw/HW/ ?
>
> > +#define arch_scale_hw_pressure topology_get_hw_pressure
> > +#define arch_update_hw_pressure      topology_update_hw_pressure
> >
> >   #include <asm-generic/topology.h>
> >
> > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> > index 0906114963ff..3d8dc9d5c3ad 100644
> > --- a/drivers/base/arch_topology.c
> > +++ b/drivers/base/arch_topology.c
> > @@ -22,7 +22,7 @@
> >   #include <linux/units.h>
> >
> >   #define CREATE_TRACE_POINTS
> > -#include <trace/events/thermal_pressure.h>
> > +#include <trace/events/hw_pressure.h>
> >
> >   static DEFINE_PER_CPU(struct scale_freq_data __rcu *, sft_data);
> >   static struct cpumask scale_freq_counters_mask;
> > @@ -160,26 +160,26 @@ void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity)
> >       per_cpu(cpu_scale, cpu) = capacity;
> >   }
> >
> > -DEFINE_PER_CPU(unsigned long, thermal_pressure);
> > +DEFINE_PER_CPU(unsigned long, hw_pressure);
> >
> >   /**
> > - * topology_update_thermal_pressure() - Update thermal pressure for CPUs
> > + * topology_update_hw_pressure() - Update hw pressure for CPUs
>
> same here: HW?
>
> >    * @cpus        : The related CPUs for which capacity has been reduced
> >    * @capped_freq : The maximum allowed frequency that CPUs can run at
> >    *
> > - * Update the value of thermal pressure for all @cpus in the mask. The
> > + * Update the value of hw pressure for all @cpus in the mask. The
>
> HW?
>
> >    * cpumask should include all (online+offline) affected CPUs, to avoid
> >    * operating on stale data when hot-plug is used for some CPUs. The
> >    * @capped_freq reflects the currently allowed max CPUs frequency due to
> > - * thermal capping. It might be also a boost frequency value, which is bigger
> > + * hw capping. It might be also a boost frequency value, which is bigger
>
> HW?
>
> >    * than the internal 'capacity_freq_ref' max frequency. In such case the
> >    * pressure value should simply be removed, since this is an indication that
> > - * there is no thermal throttling. The @capped_freq must be provided in kHz.
> > + * there is no hw throttling. The @capped_freq must be provided in kHz.
>
> HW?
>
> >    */
> > -void topology_update_thermal_pressure(const struct cpumask *cpus,
> > +void topology_update_hw_pressure(const struct cpumask *cpus,
> >                                     unsigned long capped_freq)
> >   {
> > -     unsigned long max_capacity, capacity, th_pressure;
> > +     unsigned long max_capacity, capacity, hw_pressure;
> >       u32 max_freq;
> >       int cpu;
> >
> > @@ -189,21 +189,21 @@ void topology_update_thermal_pressure(const struct cpumask *cpus,
> >
> >       /*
> >        * Handle properly the boost frequencies, which should simply clean
> > -      * the thermal pressure value.
> > +      * the hw pressure value.
>
> HW?
>
> >        */
> >       if (max_freq <= capped_freq)
> >               capacity = max_capacity;
> >       else
> >               capacity = mult_frac(max_capacity, capped_freq, max_freq);
> >
> > -     th_pressure = max_capacity - capacity;
> > +     hw_pressure = max_capacity - capacity;
> >
> > -     trace_thermal_pressure_update(cpu, th_pressure);
> > +     trace_hw_pressure_update(cpu, hw_pressure);
> >
> >       for_each_cpu(cpu, cpus)
> > -             WRITE_ONCE(per_cpu(thermal_pressure, cpu), th_pressure);
> > +             WRITE_ONCE(per_cpu(hw_pressure, cpu), hw_pressure);
> >   }
> > -EXPORT_SYMBOL_GPL(topology_update_thermal_pressure);
> > +EXPORT_SYMBOL_GPL(topology_update_hw_pressure);
> >
> >   static ssize_t cpu_capacity_show(struct device *dev,
> >                                struct device_attribute *attr,
> > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> > index 70b0f21968a0..a619202ba81d 100644
> > --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> > @@ -347,8 +347,8 @@ static void qcom_lmh_dcvs_notify(struct qcom_cpufreq_data *data)
> >
> >       throttled_freq = freq_hz / HZ_PER_KHZ;
> >
> > -     /* Update thermal pressure (the boost frequencies are accepted) */
> > -     arch_update_thermal_pressure(policy->related_cpus, throttled_freq);
> > +     /* Update hw pressure (the boost frequencies are accepted) */
>
> HW?
>
> > +     arch_update_hw_pressure(policy->related_cpus, throttled_freq);
> >
>
> [snip]
>
> >
> >       if (housekeeping_cpu(cpu, HK_TYPE_TICK))
> > @@ -5669,8 +5669,8 @@ void scheduler_tick(void)
> >       rq_lock(rq, &rf);
> >
> >       update_rq_clock(rq);
> > -     thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
> > -     update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure);
> > +     hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
> > +     update_hw_load_avg(rq_clock_task(rq), rq, hw_pressure);
>
> We switch to task clock here, could you tell me why?
> Don't we have to maintain the boot command parameter for the shift?

This should have been part of the patch5 that I finally removed. IMO,
the additional time shift with rq_clock_thermal is no more needed now
that we have 2 separates signals

>
> >       curr->sched_class->task_tick(rq, curr, 0);
> >       if (sched_feat(LATENCY_WARN))
> >               resched_latency = cpu_resched_latency(rq);
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 11d3be829302..07050955d6e0 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -4936,7 +4936,7 @@ static inline unsigned long get_actual_cpu_capacity(int cpu)
> >   {
> >       unsigned long capacity = arch_scale_cpu_capacity(cpu);
> >
> > -     capacity -= max(thermal_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
> > +     capacity -= max(hw_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
> >
> >       return capacity;
> >   }
> > @@ -4968,7 +4968,7 @@ static inline int util_fits_cpu(unsigned long util,
> >        * Similarly if a task is capped to arch_scale_cpu_capacity(little_cpu), it
> >        * should fit a little cpu even if there's some pressure.
> >        *
> > -      * Only exception is for thermal pressure since it has a direct impact
> > +      * Only exception is for hw or cpufreq pressure since it has a direct impact
>
> HW?
>
> >        * on available OPP of the system.
> >        *
> >        * We honour it for uclamp_min only as a drop in performance level
> > @@ -9224,7 +9224,7 @@ static inline bool others_have_blocked(struct rq *rq)
> >       if (READ_ONCE(rq->avg_dl.util_avg))
> >               return true;
> >
> > -     if (thermal_load_avg(rq))
> > +     if (hw_load_avg(rq))
> >               return true;
> >
> >   #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
> > @@ -9256,7 +9256,7 @@ static bool __update_blocked_others(struct rq *rq, bool *done)
> >   {
> >       const struct sched_class *curr_class;
> >       u64 now = rq_clock_pelt(rq);
> > -     unsigned long thermal_pressure;
> > +     unsigned long hw_pressure;
> >       bool decayed;
> >
> >       /*
> > @@ -9265,11 +9265,11 @@ static bool __update_blocked_others(struct rq *rq, bool *done)
> >        */
> >       curr_class = rq->curr->sched_class;
> >
> > -     thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
> > +     hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
> >
> >       decayed = update_rt_rq_load_avg(now, rq, curr_class == &rt_sched_class) |
> >                 update_dl_rq_load_avg(now, rq, curr_class == &dl_sched_class) |
> > -               update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure) |
> > +               update_hw_load_avg(now, rq, hw_pressure) |
>
> Here also the rq_clock_thermal() is not used anymore. Shouldn't we
> remove the rq_clock_thermal() if not used anymore (I cannot se this in
> the patch)?
>
> >                 update_irq_load_avg(rq, 0);
> >
> >       if (others_have_blocked(rq))
>
> [snip]
>
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index e58a54bda77d..7eaf186d071e 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -1078,8 +1078,8 @@ struct rq {
> >   #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
> >       struct sched_avg        avg_irq;
> >   #endif
> > -#ifdef CONFIG_SCHED_THERMAL_PRESSURE
> > -     struct sched_avg        avg_thermal;
> > +#ifdef CONFIG_SCHED_HW_PRESSURE
> > +     struct sched_avg        avg_hw;
> >   #endif
> >       u64                     idle_stamp;
> >       u64                     avg_idle;
>
> I don't see that rq_clock_thermal() removal in this header.
> Maybe I miss some patch?
>
> BTW, I like the name 'HW pressure' for this information/signal.


From vaishnav.a at ti.com  Thu Dec 14 00:37:36 2023
From: vaishnav.a at ti.com (Vaishnav Achath)
Date: Thu, 14 Dec 2023 14:07:36 +0530
Subject: [PATCH 2/3] arm64: dts: ti: Introduce J722S family of SoCs
In-Reply-To: <20231213202705.6tspycl5qicb6gwd@germproof>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
 <20231213124930.3012-3-vaishnav.a@ti.com>
 <20231213202705.6tspycl5qicb6gwd@germproof>
Message-ID: <08eccba2-41df-91e7-c1e5-e03190402c23@ti.com>

Hi Nishanth,

On 14/12/23 01:57, Nishanth Menon wrote:
> On 18:19-20231213, Vaishnav Achath wrote:
>> The J722S is a family of  application processors built for Automotive and
>> Linux Application development. Scalable Arm Cortex-A53 performance and
>> embedded features, such as multi high-definition display support,
>> 3D-graphics acceleration, 4K video acceleration, and extensive peripherals
>> make the J722S well-suited for a broad range of automation and industrial
>> application, including automotive digital instrumentation, automotive
>> displays, industrial HMI, and more.
> 
> Trim this down please
>>
>> Some highlights of J722S SoC are:
>>     * Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
>>     * One Device manager Cortext-R5F for system power and resource
>>       management, two Cortex-R5F for Functional Safety or
>>       general-purpose usage and two C7x floating point vector DSPs
>>       with Matrix Multiply Accelerator(MMA) for deep learning.
>>     * One 3D GPU up to 50 GLFOPS
>>     * H.264/H.265, JPEG Video Encode/Decode.
>>     * Display support: 3x display support over OLDI/LVDS (1x OLDI-DL, 1x or
>>       2x OLDI-SL), DSI, or DPI. Up to 3840x1080 at 60fps resolution
>>     * Integrated Giga-bit Ethernet switch supporting up to a total of two
>>       external ports (TSN capable).
>>     * Vision Processing Accelerator (VPAC) with image signal processor
>>       and Depth and Motion Processing Accelerator (DMPAC).
>>     * 7xUARTs, 3xSPI, 5xI2C, 2xUSB2, 2xCAN-FD, 3xMMC and SD, GPMC for
>>       NAND/FPGA connection, OSPI memory controller, 5xMcASP for audio,
>>       4xCSI-RX for Camera, 1 PCIe Gen3 controller, eCAP/eQEP,
>>       ePWM, among other peripherals.
>>     * Dedicated Centralized Hardware Security Module with support for
>>       secure boot, debug security and crypto acceleration and trusted
>>       execution environment.
>>     * One 32-bit DDR Subsystem that supports LPDDR4 memory type.
> 
> Trim this down to what is different from AM62P?
> 

Thanks for the review, I will trim this down in next revision, but the above is
just a summary of the main features of this SoC, pointing to AM62P feature set
here seems confusing to me. why does a new user/developer using J722S need to be
aware of the existence of AM62P to just understand a high level summary about
this device?

>>
>> J722S family of SoCs is a superset of the AM62P SoC family and shares
>> similar memory map, thus the nodes are being reused from AM62P includes
>> instead of duplicating the definitions. Unused nodes with dependencies
>> are kept disabled and will be enabled later when the dependencies are
>> enabled.
>>
>> For those interested, more details about this SoC can be found in the
>> Technical Reference Manual here:
>> 	https://www.ti.com/lit/zip/sprujb3
>>
>> Co-developed-by: Jayesh Choudhary <j-choudhary at ti.com>
>> Signed-off-by: Jayesh Choudhary <j-choudhary at ti.com>
>> Signed-off-by: Vaishnav Achath <vaishnav.a at ti.com>
>> ---
>>
>> checkpatch error is ignored for arch/arm64/boot/dts/ti/k3-pinctrl.h:
>> ERROR: Macros with complex values should be enclosed in parentheses
>>
>> However, we do not need parentheses enclosing the values for this
>> macro as we do intend it to generate two separate values as has been
>> done for other similar platforms.
>>
>> Depends on:
>> https://lore.kernel.org/all/20231211132600.25289-1-vaishnav.a at ti.com/
>> https://lore.kernel.org/all/20231213081318.26203-1-vaishnav.a at ti.com/
>>
>>  arch/arm64/boot/dts/ti/k3-j722s.dtsi | 275 +++++++++++++++++++++++++++
>>  arch/arm64/boot/dts/ti/k3-pinctrl.h  |   3 +
>>  2 files changed, 278 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/ti/k3-j722s.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j722s.dtsi b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
>> new file mode 100644
>> index 000000000000..dbd762bfd779
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
>> @@ -0,0 +1,275 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for J722S SoC Family
>> + *
>> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
>> +
>> +#include "k3-pinctrl.h"
>> +
>> +/ {
>> +	model = "Texas Instruments K3 J722S SoC";
>> +	compatible = "ti,j722s";
>> +	interrupt-parent = <&gic500>;
>> +	#address-cells = <2>;
>> +	#size-cells = <2>;
>> +
>> +	cpus {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		cpu-map {
>> +			cluster0: cluster0 {
>> +				core0 {
>> +					cpu = <&cpu0>;
>> +				};
>> +
>> +				core1 {
>> +					cpu = <&cpu1>;
>> +				};
>> +
>> +				core2 {
>> +					cpu = <&cpu2>;
>> +				};
>> +
>> +				core3 {
>> +					cpu = <&cpu3>;
>> +				};
>> +			};
>> +		};
>> +
>> +		cpu0: cpu at 0 {
>> +			compatible = "arm,cortex-a53";
>> +			reg = <0x000>;
>> +			device_type = "cpu";
>> +			enable-method = "psci";
>> +			i-cache-size = <0x8000>;
>> +			i-cache-line-size = <64>;
>> +			i-cache-sets = <256>;
>> +			d-cache-size = <0x8000>;
>> +			d-cache-line-size = <64>;
>> +			d-cache-sets = <128>;
>> +			next-level-cache = <&l2_0>;
>> +			clocks = <&k3_clks 135 0>;
>> +		};
>> +
>> +		cpu1: cpu at 1 {
>> +			compatible = "arm,cortex-a53";
>> +			reg = <0x001>;
>> +			device_type = "cpu";
>> +			enable-method = "psci";
>> +			i-cache-size = <0x8000>;
>> +			i-cache-line-size = <64>;
>> +			i-cache-sets = <256>;
>> +			d-cache-size = <0x8000>;
>> +			d-cache-line-size = <64>;
>> +			d-cache-sets = <128>;
>> +			next-level-cache = <&l2_0>;
>> +			clocks = <&k3_clks 136 0>;
>> +		};
>> +
>> +		cpu2: cpu at 2 {
>> +			compatible = "arm,cortex-a53";
>> +			reg = <0x002>;
>> +			device_type = "cpu";
>> +			enable-method = "psci";
>> +			i-cache-size = <0x8000>;
>> +			i-cache-line-size = <64>;
>> +			i-cache-sets = <256>;
>> +			d-cache-size = <0x8000>;
>> +			d-cache-line-size = <64>;
>> +			d-cache-sets = <128>;
>> +			next-level-cache = <&l2_0>;
>> +			clocks = <&k3_clks 137 0>;
>> +		};
>> +
>> +		cpu3: cpu at 3 {
>> +			compatible = "arm,cortex-a53";
>> +			reg = <0x003>;
>> +			device_type = "cpu";
>> +			enable-method = "psci";
>> +			i-cache-size = <0x8000>;
>> +			i-cache-line-size = <64>;
>> +			i-cache-sets = <256>;
>> +			d-cache-size = <0x8000>;
>> +			d-cache-line-size = <64>;
>> +			d-cache-sets = <128>;
>> +			next-level-cache = <&l2_0>;
>> +			clocks = <&k3_clks 138 0>;
>> +		};
>> +	};
>> +
>> +	l2_0: l2-cache0 {
>> +		compatible = "cache";
>> +		cache-unified;
>> +		cache-level = <2>;
>> +		cache-size = <0x80000>;
>> +		cache-line-size = <64>;
>> +		cache-sets = <512>;
>> +	};
> 
> ^^ this is a duplication of am62p5.dtsi? what about the spins with
> different CPUs enabled?
> 

Yes it is a duplicate, as of now we are not aware of plan for spins with cores
disabled, so just followed the pattern followed for other Jacinto devices
(J721e, J7200, J721s2, J784s4).

>> +
>> +	firmware {
>> +		optee {
>> +			compatible = "linaro,optee-tz";
>> +			method = "smc";
>> +		};
>> +
>> +		psci: psci {
>> +			compatible = "arm,psci-1.0";
>> +			method = "smc";
>> +		};
>> +	};
>> +
>> +	a53_timer0: timer-cl0-cpu0 {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
>> +			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
>> +			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
>> +			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
>> +	};
>> +
>> +	pmu: pmu {
>> +		compatible = "arm,cortex-a53-pmu";
>> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
>> +	};
>> +
>> +	cbass_main: bus at f0000 {
>> +		compatible = "simple-bus";
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		bootph-all;
> 
> Nope.
> 

Sorry I missed this, will fix here and in all other places (including comments
in patch 3/3).

>> +
>> +		ranges = <0x00 0x000f0000 0x00 0x000f0000 0x00 0x00030000>, /* Main MMRs */
>> +			 <0x00 0x00420000 0x00 0x00420000 0x00 0x00001000>, /* ESM0 */
>> +			 <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
>> +			 <0x00 0x00703000 0x00 0x00703000 0x00 0x00000200>, /* USB0 debug trace */
>> +			 <0x00 0x0070c000 0x00 0x0070c000 0x00 0x00000200>, /* USB1 debug trace */
>> +			 <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
>> +			 <0x00 0x01000000 0x00 0x01000000 0x00 0x01b28400>, /* First peripheral window */
>> +			 <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
>> +			 <0x00 0x0e000000 0x00 0x0e000000 0x00 0x01d20000>, /* Second peripheral window */
>> +			 <0x00 0x0fd80000 0x00 0x0fd80000 0x00 0x00080000>, /* GPU */
>> +			 <0x00 0x0fd20000 0x00 0x0fd20000 0x00 0x00000100>, /* JPEGENC0_CORE */
>> +			 <0x00 0x0fd20200 0x00 0x0fd20200 0x00 0x00000200>, /* JPEGENC0_CORE_MMU */
>> +			 <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
>> +			 <0x00 0x30040000 0x00 0x30040000 0x00 0x00080000>, /* PRUSS-M */
>> +			 <0x00 0x301C0000 0x00 0x301C0000 0x00 0x00001000>, /* DPHY-TX */
>> +			 <0x00 0x30101000 0x00 0x30101000 0x00 0x00080100>, /* CSI window */
>> +			 <0x00 0x30200000 0x00 0x30200000 0x00 0x00010000>, /* DSS */
>> +			 <0x00 0x30210000 0x00 0x30210000 0x00 0x00010000>, /* VPU */
>> +			 <0x00 0x30220000 0x00 0x30220000 0x00 0x00010000>, /* DSS1 */
>> +			 <0x00 0x30270000 0x00 0x30270000 0x00 0x00010000>, /* DSI-base1 */
>> +			 <0x00 0x30500000 0x00 0x30500000 0x00 0x00100000>, /* DSI-base2 */
>> +			 <0x00 0x31000000 0x00 0x31000000 0x00 0x00050000>, /* USB0 DWC3 Core window */
>> +			 <0x00 0x31200000 0x00 0x31200000 0x00 0x00040000>, /* USB1 DWC3 Core window */
>> +			 <0x00 0x40900000 0x00 0x40900000 0x00 0x00030000>, /* SA3UL */
>> +			 <0x00 0x43600000 0x00 0x43600000 0x00 0x00010000>, /* SA3 sproxy data */
>> +			 <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
>> +			 <0x00 0x44860000 0x00 0x44860000 0x00 0x00040000>, /* SA3 sproxy config */
>> +			 <0x00 0x48000000 0x00 0x48000000 0x00 0x06408000>, /* DMSS */
>> +			 <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
>> +			 <0x00 0x70000000 0x00 0x70000000 0x00 0x00040000>, /* OCSRAM */
>> +			 <0x00 0x78400000 0x00 0x78400000 0x00 0x00008000>, /* MAIN R5FSS0 ATCM */
>> +			 <0x00 0x78500000 0x00 0x78500000 0x00 0x00008000>, /* MAIN R5FSS0 BTCM */
>> +			 <0x00 0x7e000000 0x00 0x7e000000 0x00 0x00200000>, /* C7X_0 L2SRAM */
>> +			 <0x00 0x7e200000 0x00 0x7e200000 0x00 0x00200000>, /* C7X_1 L2SRAM */
>> +			 <0x01 0x00000000 0x01 0x00000000 0x00 0x00310000>, /* A53 PERIPHBASE */
>> +			 <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
>> +
>> +			 /* MCU Domain Range */
>> +			 <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>,
>> +			 <0x00 0x79000000 0x00 0x79000000 0x00 0x00008000>,
>> +			 <0x00 0x79020000 0x00 0x79020000 0x00 0x00008000>,
>> +			 <0x00 0x79100000 0x00 0x79100000 0x00 0x00040000>,
>> +			 <0x00 0x79140000 0x00 0x79140000 0x00 0x00040000>,
>> +
>> +			 /* Wakeup Domain Range */
>> +			 <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>,
>> +			 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>,
>> +			 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>,
>> +			 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>,
>> +			 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>;
>> +
>> +		cbass_mcu: bus at 4000000 {
>> +			compatible = "simple-bus";
>> +			#address-cells = <2>;
>> +			#size-cells = <2>;
>> +			ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>, /* Peripheral window */
>> +				 <0x00 0x79000000 0x00 0x79000000 0x00 0x00008000>, /* MCU R5 ATCM */
>> +				 <0x00 0x79020000 0x00 0x79020000 0x00 0x00008000>, /* MCU R5 BTCM */
>> +				 <0x00 0x79100000 0x00 0x79100000 0x00 0x00040000>, /* MCU IRAM0 */
>> +				 <0x00 0x79140000 0x00 0x79140000 0x00 0x00040000>; /* MCU IRAM1 */
>> +			bootph-all;
>> +		};
>> +
>> +		cbass_wakeup: bus at b00000 {
>> +			compatible = "simple-bus";
>> +			#address-cells = <2>;
>> +			#size-cells = <2>;
>> +			ranges = <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
>> +				 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
>> +				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* WKUP CTRL MMR */
>> +				 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
>> +				 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
>> +			bootph-all;
> 
> Not in the bus nodes.. only in the leaf nodes please.
> 
> 
> Also what is wrong with expanding the am62p to include the
> missing bus segments instead of duplicating all of them?
> 

We can do that, but the same would be true for AM625, AM62A and AM62P families
and also for (J721E, J7200), since all these SoCs introduced new dtsi instead of
resuing existing ones, I thought there would be some valid reason to have
separate dtsi and just followed the same pattern, please let know if we need to
reuse from AM62P here also.

>> +		};
>> +	};
>> +
>> +	#include "k3-am62p-thermal.dtsi"
> 
> Is this correct?
> 

I think it would be preferred to have a duplicate for J722S here as users may
want to customize the trip points as per system and doing that without affecting
AM62P would be preferred, but the initial information here would be same for J722S.

>> +};
>> +
>> +/*
>> + * Include peripherals for each bus segment derived
>> + * from AM62P and overrides specific to J722S.
>> + */
>> +#include "k3-am62p-main.dtsi"
>> +#include "k3-am62p-mcu.dtsi"
>> +#include "k3-am62p-wakeup.dtsi"
>> +
>> +/* Main domain overrides */
>> +
>> +&cpsw3g {
>> +	status = "disabled";
> 
> 	here and rest: Why disabled?

These nodes seems to have dependencies that are not merged already and would
throw errors during boot, AM62P SoC dtsi seems to have these enabled by default
without these dependencies met and have errors like below during boot (seen on
AM62P with 6.7.0-rc4-next-20231211).

[   17.869092] platform 8000000.ethernet: deferred probe pending:
am65-cpsw-nuss: Failed to request tx dma channel

>> +};
>> +
>> +&inta_main_dmss {
>> +	ti,interrupt-ranges = <5 69 35>;
>> +};
>> +
>> +&mailbox0_cluster0 {
>> +	status = "disabled";
>> +};
>> +
>> +&mailbox0_cluster1 {
>> +	status = "disabled";
>> +};
>> +
>> +&mailbox0_cluster2 {
>> +	status = "disabled";
>> +};
>> +
>> +&mailbox0_cluster3 {
>> +	status = "disabled";
>> +};
>> +

[    7.198470] omap-mailbox 29020000.mailbox: no available mbox devices found
[    7.210411] omap-mailbox 29030000.mailbox: no available mbox devices found

>> +&oc_sram {
>> +	reg = <0x00 0x70000000 0x00 0x40000>;
>> +	ranges = <0x00 0x00 0x70000000 0x40000>;
>> +};
>> +
>> +/* MCU domain overrides */
>> +
>> +&mcu_r5fss0 {
>> +	status = "disabled";
>> +};

[    7.492406] platform 79000000.r5f: configured R5F for remoteproc mode
[    7.499887] platform 79000000.r5f: device does not have reserved memory
regions, ret = -22
[    7.508271] k3_r5_rproc bus at f0000:bus at 4000000:r5fss at 79000000: reserved memory
init failed, ret = -22
[    7.517549] remoteproc remoteproc0: releasing 79000000.r5f
[    7.523338] k3_r5_rproc bus at f0000:bus at 4000000:r5fss at 79000000:
k3_r5_cluster_rproc_init failed, ret = -22
[    7.532993] k3_r5_rproc: probe of bus at f0000:bus at 4000000:r5fss at 79000000 failed
with error -22

>> +
>> +/* wakeup domain overrides */
>> +
>> +&wkup_r5fss0 {
>> +	status = "disabled";
>> +};

[    7.576576] platform 78000000.r5f: configured R5F for IPC-only mode
[    7.605535] platform 78000000.r5f: device does not have reserved memory
regions, ret = -22
[    7.613942] k3_r5_rproc bus at f0000:bus at b00000:r5fss at 78000000: reserved memory
init failed, ret = -22
[    7.635990] remoteproc remoteproc0: releasing 78000000.r5f
[    7.648639] k3_r5_rproc bus at f0000:bus at b00000:r5fss at 78000000:
k3_r5_cluster_rproc_init failed, ret = -22
[    7.664043] k3_r5_rproc: probe of bus at f0000:bus at b00000:r5fss at 78000000 failed
with error -22

>> diff --git a/arch/arm64/boot/dts/ti/k3-pinctrl.h b/arch/arm64/boot/dts/ti/k3-pinctrl.h
>> index 2a4e0e084d69..591be4489f37 100644
>> --- a/arch/arm64/boot/dts/ti/k3-pinctrl.h
>> +++ b/arch/arm64/boot/dts/ti/k3-pinctrl.h
>> @@ -59,6 +59,9 @@
>>  #define J721S2_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
>>  #define J721S2_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
>>  
>> +#define J722S_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
>> +#define J722S_MCU_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
>> +
>>  #define J784S4_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
>>  #define J784S4_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
>>  
>> -- 
>> 2.17.1
>>

0 - AM62P Boot logs (next-20231211) -
https://gist.github.com/vaishnavachath/7143da253bc708a1e60a13fe081d3914

To avoid these errors I am keeping these disabled, can we add support for these
also as part of the initial support addition series? then there is no need for
disabling these.

Thanks and Regards,
Vaishnav

> 


From mripard at kernel.org  Thu Dec 14 00:48:02 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 14 Dec 2023 09:48:02 +0100
Subject: [PATCH v5 18/44] drm/vc4: hdmi: Create destroy state
 implementation
In-Reply-To: <CAPY8ntBe9RfSjdnd5Smx23La5gQaR9WqY8ehXQyp=4D_11N55Q@mail.gmail.com>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org>
 <20231207-kms-hdmi-connector-state-v5-18-6538e19d634d@kernel.org>
 <CAPY8ntBe9RfSjdnd5Smx23La5gQaR9WqY8ehXQyp=4D_11N55Q@mail.gmail.com>
Message-ID: <rr5wvkunjglkxozfsvf5zvffwzznq6zt5mzvxw5rx2rpyfzecb@kauuy72x43gj>

Hi Dave,

On Tue, Dec 12, 2023 at 11:40:26AM +0000, Dave Stevenson wrote:
> On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
> >
> > Even though we were rolling our own custom state for the vc4 HDMI
> > controller driver, we were still using the generic helper to destroy
> > that state.
> >
> > It was mostly working since the underlying state is the first member of
> > our state so the pointers are probably equal in all relevant cases, but
> > it's still fragile so let's fix this properly.
> >
> > Signed-off-by: Maxime Ripard <mripard at kernel.org>
> 
> Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

Thanks for the review, I've applied that patch now.

Could you also review the framework changes (patches 6 to 16) ?

Thanks!
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/cc4e996a/attachment.sig>

From michal.simek at amd.com  Thu Dec 14 00:47:24 2023
From: michal.simek at amd.com (Michal Simek)
Date: Thu, 14 Dec 2023 09:47:24 +0100
Subject: [PATCH] media: platform: xilinx: Fix Kconfig indentation
Message-ID: <72c40d216769a97973cac9a347e826b943f71d7f.1702543638.git.michal.simek@amd.com>

Use proper indentation for Kconfig fragments - help part.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

 drivers/media/platform/xilinx/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/xilinx/Kconfig b/drivers/media/platform/xilinx/Kconfig
index 93ef78bf62e6..601edd9acd5b 100644
--- a/drivers/media/platform/xilinx/Kconfig
+++ b/drivers/media/platform/xilinx/Kconfig
@@ -26,10 +26,10 @@ config VIDEO_XILINX_TPG
 	depends on VIDEO_XILINX
 	select VIDEO_XILINX_VTC
 	help
-	   Driver for the Xilinx Video Test Pattern Generator
+	  Driver for the Xilinx Video Test Pattern Generator
 
 config VIDEO_XILINX_VTC
 	tristate "Xilinx Video Timing Controller"
 	depends on VIDEO_XILINX
 	help
-	   Driver for the Xilinx Video Timing Controller
+	  Driver for the Xilinx Video Timing Controller
-- 
2.36.1



From lukasz.luba at arm.com  Thu Dec 14 00:54:10 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Thu, 14 Dec 2023 08:54:10 +0000
Subject: [PATCH 4/4] sched: Rename arch_update_thermal_pressure into
 arch_update_hw_pressure
In-Reply-To: <CAKfTPtDKRfF7QzwoDwkGKZ_DJS3ewBncifC37LADfNJwtQfiYA@mail.gmail.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-5-vincent.guittot@linaro.org>
 <274a6562-46c9-4b03-9295-c24e5eb9e6cd@arm.com>
 <CAKfTPtDKRfF7QzwoDwkGKZ_DJS3ewBncifC37LADfNJwtQfiYA@mail.gmail.com>
Message-ID: <e0b1a6a8-0163-4f7d-b876-b7a3e6c74b2e@arm.com>



On 12/14/23 08:36, Vincent Guittot wrote:
> On Thu, 14 Dec 2023 at 09:30, Lukasz Luba <lukasz.luba at arm.com> wrote:
>>
>>
>> On 12/12/23 14:27, Vincent Guittot wrote:

[snip]

>>>        update_rq_clock(rq);
>>> -     thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
>>> -     update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure);
>>> +     hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
>>> +     update_hw_load_avg(rq_clock_task(rq), rq, hw_pressure);
>>
>> We switch to task clock here, could you tell me why?
>> Don't we have to maintain the boot command parameter for the shift?
> 
> This should have been part of the patch5 that I finally removed. IMO,
> the additional time shift with rq_clock_thermal is no more needed now
> that we have 2 separates signals
> 

I didn't like the left-shift which causes the signal to converge slowly.
I rather wanted right-shift to converge (react faster), so you have my
vote for this change. Also, I agree that with the two-signal approach
this shift trick can go away now. I just worry about the dropped boot
parameter.

So, are going to send that patach5 which removes the
'sched_thermal_decay_shift' and documentation bit?


From vincent.guittot at linaro.org  Thu Dec 14 00:54:34 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 14 Dec 2023 09:54:34 +0100
Subject: [PATCH 4/4] sched: Rename arch_update_thermal_pressure into arch_update_hw_pressure
In-Reply-To: <e0b1a6a8-0163-4f7d-b876-b7a3e6c74b2e@arm.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-5-vincent.guittot@linaro.org> <274a6562-46c9-4b03-9295-c24e5eb9e6cd@arm.com>
 <CAKfTPtDKRfF7QzwoDwkGKZ_DJS3ewBncifC37LADfNJwtQfiYA@mail.gmail.com> <e0b1a6a8-0163-4f7d-b876-b7a3e6c74b2e@arm.com>
Message-ID: <CAKfTPtAU2ryefu-4cJ7YSV6Ji8Xofa-6=yAZ+EmUJ+qbsFCfZw@mail.gmail.com>

On Thu, 14 Dec 2023 at 09:53, Lukasz Luba <lukasz.luba at arm.com> wrote:
>
>
>
> On 12/14/23 08:36, Vincent Guittot wrote:
> > On Thu, 14 Dec 2023 at 09:30, Lukasz Luba <lukasz.luba at arm.com> wrote:
> >>
> >>
> >> On 12/12/23 14:27, Vincent Guittot wrote:
>
> [snip]
>
> >>>        update_rq_clock(rq);
> >>> -     thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
> >>> -     update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure);
> >>> +     hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
> >>> +     update_hw_load_avg(rq_clock_task(rq), rq, hw_pressure);
> >>
> >> We switch to task clock here, could you tell me why?
> >> Don't we have to maintain the boot command parameter for the shift?
> >
> > This should have been part of the patch5 that I finally removed. IMO,
> > the additional time shift with rq_clock_thermal is no more needed now
> > that we have 2 separates signals
> >
>
> I didn't like the left-shift which causes the signal to converge slowly.
> I rather wanted right-shift to converge (react faster), so you have my
> vote for this change. Also, I agree that with the two-signal approach
> this shift trick can go away now. I just worry about the dropped boot
> parameter.
>
> So, are going to send that patach5 which removes the
> 'sched_thermal_decay_shift' and documentation bit?

Yes, i will add it back for the next version


From LinoSanfilippo at gmx.de  Thu Dec 14 01:00:00 2023
From: LinoSanfilippo at gmx.de (Lino Sanfilippo)
Date: Thu, 14 Dec 2023 10:00:00 +0100
Subject: [PATCH V5 3/3] tty: serial: uartps: Add rs485 support to uartps
 driver
In-Reply-To: <20231213130023.606486-4-manikanta.guntupalli@amd.com>
References: <20231213130023.606486-1-manikanta.guntupalli@amd.com>
 <20231213130023.606486-4-manikanta.guntupalli@amd.com>
Message-ID: <e8cf9ed3-e2d3-4764-b1c3-87e38e99b4a5@gmx.de>


Hi,

On 13.12.23 14:00, Manikanta Guntupalli wrote:

>
> +/**
> + * cdns_rs485_rx_callback - Timer rx callback handler for rs485.
> + * @t: Handle to the timer list structure
> + */
> +static void cdns_rs485_rx_callback(struct timer_list *t)
> +{
> +	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
> +
> +	/*
> +	 * Default Rx should be setup, because Rx signaling path
> +	 * need to enable to receive data.
> +	 */
> +	cdns_rs485_rx_setup(cdns_uart);
> +}
> +
> +/**
> + * cdns_rs485_tx_callback - Timer tx callback handler for rs485.
> + * @t: Handle to the timer list structure
> + */
> +static void cdns_rs485_tx_callback(struct timer_list *t)
> +{
> +	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
> +
> +	cdns_uart_handle_tx(cdns_uart->port);

This is called without holding the port lock now. Are you sure the lock is not
needed? AFAIK the port lock is needed at least for accessing the circular
buffer.

> +
> +	/* Enable the TX Empty interrupt */
> +	writel(CDNS_UART_IXR_TXEMPTY, cdns_uart->port->membase + CDNS_UART_IER);
> +
> +	if (uart_circ_empty(&cdns_uart->port->state->xmit) ||
> +	    uart_tx_stopped(cdns_uart->port)) {
> +		timer_setup(&cdns_uart->timer, cdns_rs485_rx_callback, 0);
> +		mod_timer(&cdns_uart->timer, jiffies +
> +			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
> +	}
> +}

Regards,
Lino


From lukasz.luba at arm.com  Thu Dec 14 01:08:04 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Thu, 14 Dec 2023 09:08:04 +0000
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the
 scheduler
In-Reply-To: <CAKfTPtDam5eQO1DHxALsCaU53Rtawbfrvswy+z2unnV_eXeVLA@mail.gmail.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org>
 <20231214054307.axl33gagxacidjbn@vireshk-i7>
 <CAKfTPtDam5eQO1DHxALsCaU53Rtawbfrvswy+z2unnV_eXeVLA@mail.gmail.com>
Message-ID: <54f3b98c-1f7d-4205-9e3c-a4a19ad3d941@arm.com>



On 12/14/23 07:57, Vincent Guittot wrote:
> On Thu, 14 Dec 2023 at 06:43, Viresh Kumar <viresh.kumar at linaro.org> wrote:
>>
>> On 12-12-23, 15:27, Vincent Guittot wrote:
>>> @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
>>>        policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
>>>        trace_cpu_frequency_limits(policy);
>>>
>>> +     cpus = policy->related_cpus;
>>> +     cpufreq_update_pressure(cpus, policy->max);
>>> +
>>>        policy->cached_target_freq = UINT_MAX;
>>
>> One more question, why are you doing this from cpufreq_set_policy ? If
>> due to cpufreq cooling or from userspace, we end up limiting the
>> maximum possible frequency, will this routine always get called ?
> 
> Yes, any update of a FREQ_QOS_MAX ends up calling cpufreq_set_policy()
> to update the policy->max
> 

Agree, cpufreq sysfs scaling_max_freq is also important to handle
in this new design. Currently we don't reflect that as reduced CPU
capacity in the scheduler. There was discussion when I proposed to feed
that CPU frequency reduction into thermal_pressure [1].

The same applies for the DTPM which is missing currently the proper
impact to the CPU reduced capacity in the scheduler.

IMHO any limit set into FREQ_QOS_MAX should be visible in this
new design of capacity reduction signaling.

[1] https://lore.kernel.org/lkml/20220930094821.31665-2-lukasz.luba at arm.com/


From festevam at gmail.com  Thu Dec 14 01:16:53 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 14 Dec 2023 06:16:53 -0300
Subject: [PATCH v2] arm64: dts: imx8qxp-mek: Move port under USB connector
Message-ID: <20231214091653.1187117-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per nxp,ptn5110.yaml, 'port' should be placed under 'connector'.

Do as requested to fix the following dt-schema warning:

imx8qxp-mek.dtb: tcpc at 50: connector:ports: 'port at 0' is a required property
        from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
imx8qxp-mek.dtb: tcpc at 50: connector: Unevaluated properties are not allowed ('ports' was unexpected)
        from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
Changes since v1:
- Added a newline between properties and child node. (Shawn)

 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 6c3d8715bc11..9f660f386039 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -152,12 +152,6 @@ ptn5110: tcpc at 50 {
 		interrupt-parent = <&lsio_gpio1>;
 		interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
 
-		port {
-			typec_dr_sw: endpoint {
-				remote-endpoint = <&usb3_drd_sw>;
-			};
-		};
-
 		usb_con1: connector {
 			compatible = "usb-c-connector";
 			label = "USB-C";
@@ -169,8 +163,17 @@ ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
 
+				port at 0 {
+					reg = <0>;
+
+					typec_dr_sw: endpoint {
+						remote-endpoint = <&usb3_drd_sw>;
+					};
+				};
+
 				port at 1 {
 					reg = <1>;
+
 					typec_con_ss: endpoint {
 						remote-endpoint = <&usb3_data_ss>;
 					};
-- 
2.34.1



From lukasz.luba at arm.com  Thu Dec 14 01:21:11 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Thu, 14 Dec 2023 09:21:11 +0000
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the
 scheduler
In-Reply-To: <20231212142730.998913-2-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org>
Message-ID: <af7b67d1-c4a3-44e3-a632-5f0a4ea6eb25@arm.com>



On 12/12/23 14:27, Vincent Guittot wrote:
> Provide to the scheduler a feedback about the temporary max available
> capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
> filtered as the pressure will happen for dozens ms or more.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>   drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++++++++++++++++++++++++
>   include/linux/cpufreq.h   | 10 ++++++++
>   2 files changed, 58 insertions(+)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 44db4f59c4cc..7d5f71be8d29 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2563,6 +2563,50 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
>   }
>   EXPORT_SYMBOL(cpufreq_get_policy);
>   
> +DEFINE_PER_CPU(unsigned long, cpufreq_pressure);
> +EXPORT_PER_CPU_SYMBOL_GPL(cpufreq_pressure);

Why do we export this variable when we have get/update functions?
Do we expect modules would manipulate those per-cpu variables
independently and not like we do per-cpumask in the update func.?


From glider at google.com  Thu Dec 14 01:27:12 2023
From: glider at google.com (Alexander Potapenko)
Date: Thu, 14 Dec 2023 10:27:12 +0100
Subject: [PATCH v9 1/4] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <20231213121605.GB31326@willie-the-truck>
References: <20231113105234.32058-1-glider@google.com> <20231113105234.32058-2-glider@google.com>
 <ZXiVX5FAWZqHfr7m@arm.com> <20231213121605.GB31326@willie-the-truck>
Message-ID: <CAG_fn=X60dDWKAC6Yswr3RCW15Jpd8BOtRCYP-ijCDZZDzo14A@mail.gmail.com>

On Wed, Dec 13, 2023 at 1:16?PM Will Deacon <will at kernel.org> wrote:
>
> On Tue, Dec 12, 2023 at 05:16:15PM +0000, Catalin Marinas wrote:
> > On Mon, Nov 13, 2023 at 11:52:30AM +0100, Alexander Potapenko wrote:
> > > The config implements the algorithm compressing memory tags for ARM MTE
> > > during swapping.
> > >
> > > The algorithm is based on RLE and specifically targets buffers of tags
> > > corresponding to a single page. In many cases a buffer can be compressed
> > > into 63 bits, making it possible to store it without additional memory
> > > allocation.
> > >
> > > Suggested-by: Evgenii Stepanov <eugenis at google.com>
> > > Signed-off-by: Alexander Potapenko <glider at google.com>
> >
> > Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> >
> > > +void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
> > > +                   size_t *out_len)
> > > +{
> > [...]
> > > +}
> > > +EXPORT_SYMBOL_NS(mte_tags_to_ranges, MTECOMP);
> >
> > I may have asked before, what the reason for EXPORT_SYMBOL_NS? Is it for
> > the kunit tests? Otherwise we don't expect those to be accessed from
> > modules.
>
> It looks like it. The Kconfig option for the test is tristate and it calls
> this symbol directly.
>
> Will

What Will said.


From rafael at kernel.org  Thu Dec 14 01:40:28 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Thu, 14 Dec 2023 10:40:28 +0100
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the scheduler
In-Reply-To: <54f3b98c-1f7d-4205-9e3c-a4a19ad3d941@arm.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org> <20231214054307.axl33gagxacidjbn@vireshk-i7>
 <CAKfTPtDam5eQO1DHxALsCaU53Rtawbfrvswy+z2unnV_eXeVLA@mail.gmail.com> <54f3b98c-1f7d-4205-9e3c-a4a19ad3d941@arm.com>
Message-ID: <CAJZ5v0gD-utGhM3vN7JmPia1CVcSQa6RPnk2xMBXXc6asRTn=g@mail.gmail.com>

On Thu, Dec 14, 2023 at 10:07?AM Lukasz Luba <lukasz.luba at arm.com> wrote:
>
> On 12/14/23 07:57, Vincent Guittot wrote:
> > On Thu, 14 Dec 2023 at 06:43, Viresh Kumar <viresh.kumar at linaro.org> wrote:
> >>
> >> On 12-12-23, 15:27, Vincent Guittot wrote:
> >>> @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
> >>>        policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
> >>>        trace_cpu_frequency_limits(policy);
> >>>
> >>> +     cpus = policy->related_cpus;
> >>> +     cpufreq_update_pressure(cpus, policy->max);
> >>> +
> >>>        policy->cached_target_freq = UINT_MAX;
> >>
> >> One more question, why are you doing this from cpufreq_set_policy ? If
> >> due to cpufreq cooling or from userspace, we end up limiting the
> >> maximum possible frequency, will this routine always get called ?
> >
> > Yes, any update of a FREQ_QOS_MAX ends up calling cpufreq_set_policy()
> > to update the policy->max
> >
>
> Agree, cpufreq sysfs scaling_max_freq is also important to handle
> in this new design. Currently we don't reflect that as reduced CPU
> capacity in the scheduler. There was discussion when I proposed to feed
> that CPU frequency reduction into thermal_pressure [1].
>
> The same applies for the DTPM which is missing currently the proper
> impact to the CPU reduced capacity in the scheduler.
>
> IMHO any limit set into FREQ_QOS_MAX should be visible in this
> new design of capacity reduction signaling.
>
> [1] https://lore.kernel.org/lkml/20220930094821.31665-2-lukasz.luba at arm.com/

Actually, freq_qos_read_value(&policy->constraints, FREQ_QOS_MAX) will
return the requisite limit.


From heiko at sntech.de  Thu Dec 14 01:50:26 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Thu, 14 Dec 2023 10:50:26 +0100
Subject: [PATCH v2] dt-bindings: iommu: rockchip: Add Rockchip RK3588
In-Reply-To: <20231212005710.1837066-1-andyshrk@163.com>
References: <20231212005710.1837066-1-andyshrk@163.com>
Message-ID: <14263703.RDIVbhacDa@diego>

Hi Joerg,

Am Dienstag, 12. Dezember 2023, 01:57:10 CET schrieb Andy Yan:
> From: Andy Yan <andy.yan at rock-chips.com>
> 
> Add a Rockchip RK3588 compatible
> 
> I split it from the vop2 patch series as suggested by Heiko[0]
> 
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

could you possibly pick this patch for the iommu tree?


Thanks a lot
Heiko


> [0]https://patchwork.kernel.org/project/dri-devel/patch/20231207080235.652719-1-andyshrk at 163.com/
> 
> ---
> 
> Changes in v2:
> - Add maintainers for the iommu subsystem to cc list
> 
>  .../devicetree/bindings/iommu/rockchip,iommu.yaml     | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> index ba9124f721f1..621dde0e45d8 100644
> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> @@ -19,9 +19,14 @@ description: |+
>  
>  properties:
>    compatible:
> -    enum:
> -      - rockchip,iommu
> -      - rockchip,rk3568-iommu
> +    oneOf:
> +      - enum:
> +          - rockchip,iommu
> +          - rockchip,rk3568-iommu
> +      - items:
> +          - enum:
> +              - rockchip,rk3588-iommu
> +          - const: rockchip,rk3568-iommu
>  
>    reg:
>      items:
> 






From lkp at intel.com  Thu Dec 14 01:56:14 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 14 Dec 2023 17:56:14 +0800
Subject: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx
 platforms.
In-Reply-To: <20231213092850.1706042-2-sherry.sun@nxp.com>
References: <20231213092850.1706042-2-sherry.sun@nxp.com>
Message-ID: <202312141719.j5GCLQry-lkp@intel.com>

Hi Sherry,

kernel test robot noticed the following build warnings:

[auto build test WARNING on pci/next]
[also build test WARNING on pci/for-linus shawnguo/for-next robh/for-next linus/master v6.7-rc5 next-20231214]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Sherry-Sun/PCI-imx6-Add-pci-host-wakeup-support-on-imx-platforms/20231213-173031
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:    https://lore.kernel.org/r/20231213092850.1706042-2-sherry.sun%40nxp.com
patch subject: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx platforms.
config: alpha-randconfig-r112-20231214 (https://download.01.org/0day-ci/archive/20231214/202312141719.j5GCLQry-lkp at intel.com/config)
compiler: alpha-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231214/202312141719.j5GCLQry-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312141719.j5GCLQry-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/pci/controller/dwc/pci-imx6.c:1267:13: sparse: sparse: symbol 'host_wake_irq_handler' was not declared. Should it be static?
   drivers/pci/controller/dwc/pci-imx6.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/umh.h, include/linux/kmod.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false

vim +/host_wake_irq_handler +1267 drivers/pci/controller/dwc/pci-imx6.c

  1266	
> 1267	irqreturn_t host_wake_irq_handler(int irq, void *priv)
  1268	{
  1269		struct imx6_pcie *imx6_pcie = priv;
  1270		struct device *dev = imx6_pcie->pci->dev;
  1271	
  1272		/* Notify PM core we are wakeup source */
  1273		pm_wakeup_event(dev, 0);
  1274		pm_system_wakeup();
  1275	
  1276		return IRQ_HANDLED;
  1277	}
  1278	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From andre.przywara at arm.com  Thu Dec 14 01:59:14 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 09:59:14 +0000
Subject: [PATCH v3 5/6] thermal: sun8i: add support for H616 THS
 controller
In-Reply-To: <CALHCpMjz4YiE_=6Cxq7RqF_3qPaw8UCA=6eLy9ZZuofRhr7mcA@mail.gmail.com>
References: <20231128005849.19044-6-andre.przywara@arm.com>
	<a14fb458-caf0-4a4a-b76b-c2503b0840d2@gmail.com>
	<20231211000528.57cb646c@minigeek.lan>
	<CALHCpMjz4YiE_=6Cxq7RqF_3qPaw8UCA=6eLy9ZZuofRhr7mcA@mail.gmail.com>
Message-ID: <20231214095914.4a98ba8c@donnerap.manchester.arm.com>

On Tue, 12 Dec 2023 21:09:45 +0300
Maxim Kiselev <bigunclemax at gmail.com> wrote:

Hi Maksim,

sorry for the delay.

> ??, 11 ???. 2023??. ? 02:48, Andre Przywara <andre.przywara at arm.com>:
> >
> > On Sat, 9 Dec 2023 13:44:34 +0300
> > Maksim Kiselev <bigunclemax at gmail.com> wrote:
> >
> > Hi Maksim,
> >  
> > > Hi Martin, Andre.
> > >
> > > May I inquire? Why do we need a separate sun50i_h616_ths_calibrate()
> > > function? Why can't we just extend an existing sun50i_h6_ths_calibrate()?
> > >
> > > At my glance the calculations in both functions are the same. We just
> > > need to handle a special case for the 4th sensor.  
> >
> > You seem to be right, they are indeed the same, just written slightly
> > differently. Do you already have any patches that unify that?  
> 
> No, I don't have any patches for that yet. But I can do it if you told
> me where to
> send the patch. Should I put it here as a reply?

Can you make one patch on top of mainline, that prepares the existing
sun50i_h6_ths_calibrate() function to deal with four sensors? I would then
include this patch of yours in the next submission, and put Martin's H616
patch (now probably just the struct ths_thermal_chip) on top then.

Please send this patch just to the list (CC:ing people like Martin and
me), starting a new thread.

Many thanks,
Andre

> > I don't know if Martin or I find time to do it this week, but we could
> > also optimise this later.
> >
> > Cheers,
> > Andre  
> 
> Best regards,
> Maksim



From andre.przywara at arm.com  Thu Dec 14 01:59:50 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 09:59:50 +0000
Subject: [PATCH v3 5/6] thermal: sun8i: add support for H616 THS
 controller
In-Reply-To: <CALHCpMj3+g5MD1vHdtZeYP3=2xBYvXMBH9ai376YwETGJRyeyA@mail.gmail.com>
References: <CALHCpMj3+g5MD1vHdtZeYP3=2xBYvXMBH9ai376YwETGJRyeyA@mail.gmail.com>
Message-ID: <20231214095950.60505c20@donnerap.manchester.arm.com>

On Wed, 13 Dec 2023 12:41:29 +0300
Maxim Kiselev <bigunclemax at gmail.com> wrote:

Hi Maksim,

> Hello, again!
> 
> On 28.11.2023 03:58, Andre Przywara wrote:
> > From: Martin Botka <martin.botka at somainline.org>
> >
> > Add support for the thermal sensor found in H616 SoCs, which slightly
> > resembles the H6 thermal sensor controller, with a few changes like
> > four sensors.
> > Also the registers readings are wrong, unless a bit in the first SYS_CFG
> > register cleared, so set needs_syscon to trigger that code
> >
> > Signed-off-by: Martin Botka <martin.botka at somainline.org>
> > Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> > ---
> > drivers/thermal/sun8i_thermal.c | 73 +++++++++++++++++++++++++++++++++
> > 1 file changed, 73 insertions(+)
> >
> > diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> > index 920e419ce7343..9a404fa9d76a9 100644
> > --- a/drivers/thermal/sun8i_thermal.c
> > +++ b/drivers/thermal/sun8i_thermal.c
> > @@ -280,6 +280,64 @@ static int sun50i_h6_ths_calibrate(struct ths_device *tmdev,
> > return 0;
> > }
> >
> > +static int sun50i_h616_ths_calibrate(struct ths_device *tmdev,
> > + u16 *caldata, int callen)
> > +{
> > + struct device *dev = tmdev->dev;
> > + int i, ft_temp;
> > +
> > + if (!caldata[0])
> > + return -EINVAL;
> > +
> > + /*
> > + * h616 efuse THS calibration data layout:
> > + *
> > + * 0 11 16 27 32 43 48 57
> > + * +----------+-----------+-----------+-----------+
> > + * | temp | |sensor0| |sensor1| |sensor2| |
> > + * +----------+-----------+-----------+-----------+
> > + * ^ ^ ^
> > + * | | |
> > + * | | sensor3[11:8]
> > + * | sensor3[7:4]
> > + * sensor3[3:0]
> > + *
> > + * The calibration data on the H616 is the ambient temperature and
> > + * sensor values that are filled during the factory test stage.
> > + *
> > + * The unit of stored FT temperature is 0.1 degree celsius.
> > + */
> > + ft_temp = caldata[0] & FT_TEMP_MASK;
> > +
> > + for (i = 0; i < tmdev->chip->sensor_num; i++) {
> > + int delta, cdata, offset, reg, temp;
> > +
> > + if (i == 3)
> > + reg = (caldata[1] >> 12)
> > + | ((caldata[2] >> 12) << 4)
> > + | ((caldata[3] >> 12) << 8);
> > + else
> > + reg = (int)caldata[i + 1] & TEMP_CALIB_MASK;
> > +
> > + temp = tmdev->chip->calc_temp(tmdev, i, reg);
> > + delta = ((temp - ft_temp * 100) * 10) / tmdev->chip->scale;
> > + cdata = CALIBRATE_DEFAULT - delta;
> > + if (cdata & ~TEMP_CALIB_MASK) {
> > + dev_warn(dev, "sensor%d is not calibrated.\n", i);
> > +
> > + continue;
> > + }
> > +
> > + offset = (i % 2) * 16;
> > + regmap_update_bits(tmdev->regmap,
> > + SUN50I_H6_THS_TEMP_CALIB + (i / 2 * 4),
> > + TEMP_CALIB_MASK << offset,
> > + cdata << offset);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int sun8i_ths_calibrate(struct ths_device *tmdev)
> > {
> > struct nvmem_cell *calcell;
> > @@ -659,6 +717,20 @@ static const struct ths_thermal_chip sun50i_h6_ths = {
> > .calc_temp = sun8i_ths_calc_temp,
> > };
> >
> > +static const struct ths_thermal_chip sun50i_h616_ths = {
> > + .sensor_num = 4,
> > + .has_bus_clk_reset = true,
> > + .needs_syscon = true,
> > + .ft_deviation = 8000,
> > + .offset = 263655,
> > + .scale = 810,  
> 
> Can I ask you, how did you get the offset and the scale values?
> 
> In the H616 user manual (3.10.3.4. THS Temperature Conversion Formula)
> we can find this formula:
> 
> T = (sensor_data - 3255)/(-12.401)
> 
> I calculated offset and scale values, and this is what I got:
> 
> scale = 1 / 12.401 = 806,38658173 ~ 806
> offset = 3255 / 12.401 = 262478,832352 ~ 262479
> 
> Let me assume that you got offset and scale values from Tina Linux
> Here for example
> https://github.com/Tina-Linux/linux-5.4/blob/ff6b1361f7041be75d4486559141e13134d164ef/drivers/thermal/sunxi_thermal.c#L373
> 
> In Tina Linux the scale is rounded to 81 (that equals to 810 in
> mainline driver).
> And looks like you used this rounded value to recalculate the offset:
> 3255 * 81 = 263655
> 
> I would be glad to know your thoughts about this.

Yes, this submission was based on some BSP code, from there we calculated
the values to match the formula used in mainline, so this would include
the rounding error, as your rightly figured.

I don't know if the manual is any more accurate than the BSP data, but
your calculations above make sense, and would explain the difference.

I will use your new values in the next version.

Thanks,
Andre

> > + .temp_data_base = SUN50I_H6_THS_TEMP_DATA,
> > + .calibrate = sun50i_h616_ths_calibrate,
> > + .init = sun50i_h6_thermal_init,
> > + .irq_ack = sun50i_h6_irq_ack,
> > + .calc_temp = sun8i_ths_calc_temp,
> > +};
> > +
> > static const struct of_device_id of_ths_match[] = {
> > { .compatible = "allwinner,sun8i-a83t-ths", .data = &sun8i_a83t_ths },
> > { .compatible = "allwinner,sun8i-h3-ths", .data = &sun8i_h3_ths },
> > @@ -667,6 +739,7 @@ static const struct of_device_id of_ths_match[] = {
> > { .compatible = "allwinner,sun50i-a100-ths", .data = &sun50i_a100_ths },
> > { .compatible = "allwinner,sun50i-h5-ths", .data = &sun50i_h5_ths },
> > { .compatible = "allwinner,sun50i-h6-ths", .data = &sun50i_h6_ths },
> > + { .compatible = "allwinner,sun50i-h616-ths", .data = &sun50i_h616_ths },
> > { /* sentinel */ },
> > };
> > MODULE_DEVICE_TABLE(of, of_ths_match);  
> 
> Best regards,
> Maksim
> 



From tabba at google.com  Thu Dec 14 02:01:40 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:40 +0000
Subject: [PATCH v3 00/17] KVM: arm64: Fixes to fine grain traps and pKVM traps
Message-ID: <20231214100158.2305400-1-tabba@google.com>

Changes from v2:
- Rebased on arm64/for-next/sysregs, which includes new system
  register definitions (Mark, Joey)
- Explicitly trap unsupported HFGxTR_EL2 features rather than
  relying on its nMASK (Joey)
- Add new system registers to the auto-generated sysreg rather
  than hardcoding them (Mark)
- Drop patch that was meant as RFC
- Added missing system registers, fields, and  system
  instructions
- Split patches that make system register changes
- Fixes to patches defining allowed features for protected VMs
- Other minor fixes and tidying up

Changes from v1:
- Handle HAFGRTR_EL2 in nested virt
- Update the nested virt FGT tables with the added trap bits (Marc)
- Use the generated value for RES0 (Marc)
- Calculate the value of NMASK based on RES0 and MASK

This patch series has fixes, updates, and code for validating
fine grain trap register masks, as well as some fixes to feature
trapping in pKVM.

New fine grain trap (FGT) bits have been defined in the latest
Arm Architecture System Registers xml specification (DDI0601 and
DDI0602 2023-09) [1], so the code is updated to reflect them.
Moreover, some of the already-defined masks overlap with RES0,
which this series fixes.

It also adds FGT register masks that weren't defined earlier,
handling of HAFGRTR_EL2 in nested virt, as well as build time
validation that the bits of the various masks are all accounted
for and without overlap.

Based on arm64/for-next/sysregs (e94e06d8a796), which is composed
of system register updates [2] and is based on Linux 6.7-rc3.

Cheers,
/fuad

[1] https://developer.arm.com/downloads/-/exploration-tools
[2] https://lore.kernel.org/all/20231209-b4-arm64-sysreg-additions-v1-0-45284e538474 at kernel.org/

Fuad Tabba (17):
  arm64/sysreg: Add missing Pauth_LR field definitions to
    ID_AA64ISAR1_EL1
  arm64/sysreg: Add missing ExtTrcBuff field definition to
    ID_AA64DFR0_EL1
  arm64/sysreg: Add missing system register definitions for FGT
  arm64/sysreg: Add missing system instruction definitions for FGT
  KVM: arm64: Explicitly trap unsupported HFGxTR_EL2 features
  KVM: arm64: Add missing HFGxTR_EL2 FGT entries to nested virt
  KVM: arm64: Add missing HFGITR_EL2 FGT entries to nested virt
  KVM: arm64: Add bit masks for HAFGRTR_EL2
  KVM: arm64: Handle HAFGRTR_EL2 trapping in nested virt
  KVM: arm64: Update and fix FGT register masks
  KVM: arm64: Add build validation for FGT trap mask values
  KVM: arm64: Use generated FGT RES0 bits instead of specifying them
  KVM: arm64: Define FGT nMASK bits relative to other fields
  KVM: arm64: Macros for setting/clearing FGT bits
  KVM: arm64: Fix which features are marked as allowed for protected VMs
  KVM: arm64: Mark PAuth as a restricted feature for protected VMs
  KVM: arm64: Trap external trace for protected VMs

 arch/arm64/include/asm/kvm_arm.h              | 61 +++++++++------
 arch/arm64/include/asm/kvm_host.h             |  1 +
 arch/arm64/include/asm/sysreg.h               |  7 ++
 arch/arm64/kvm/emulate-nested.c               | 63 +++++++++++++++
 arch/arm64/kvm/hyp/include/hyp/switch.h       | 77 +++++++++++--------
 .../arm64/kvm/hyp/include/nvhe/fixed_config.h | 22 +++++-
 arch/arm64/kvm/hyp/nvhe/pkvm.c                |  4 +
 arch/arm64/kvm/sys_regs.c                     |  1 +
 arch/arm64/tools/sysreg                       | 50 +++++++++++-
 9 files changed, 225 insertions(+), 61 deletions(-)


base-commit: e94e06d8a7960fd840ea92021ca1bf1362ea67f8
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:41 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:41 +0000
Subject: [PATCH v3 01/17] arm64/sysreg: Add missing Pauth_LR field definitions
 to ID_AA64ISAR1_EL1
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-2-tabba@google.com>

Add the Pauth_LR field definitions to ID_AA64ISAR1_EL1, based on
DDI0601 2023-09.

These fields aren't used yet. Adding them for completeness and
consistency (definition already exists for ID_AA64ISAR2_EL1).

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/tools/sysreg | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 2c4b6665c5bf..d596be2599d1 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1401,6 +1401,7 @@ UnsignedEnum	11:8	API
 	0b0011	PAuth2
 	0b0100	FPAC
 	0b0101	FPACCOMBINE
+	0b0110	PAuth_LR
 EndEnum
 UnsignedEnum	7:4	APA
 	0b0000	NI
@@ -1409,6 +1410,7 @@ UnsignedEnum	7:4	APA
 	0b0011	PAuth2
 	0b0100	FPAC
 	0b0101	FPACCOMBINE
+	0b0110	PAuth_LR
 EndEnum
 UnsignedEnum	3:0	DPB
 	0b0000	NI
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:42 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:42 +0000
Subject: [PATCH v3 02/17] arm64/sysreg: Add missing ExtTrcBuff field
 definition to ID_AA64DFR0_EL1
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-3-tabba@google.com>

Add the ExtTrcBuff field definitions to ID_AA64DFR0_EL1 from
DDI0601 2023-09.

This field isn't used yet. Adding it for completeness and because
it will be used in future patches.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/tools/sysreg | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index d596be2599d1..a8e36640c027 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1189,7 +1189,10 @@ Enum	63:60	HPMN0
 	0b0000	UNPREDICTABLE
 	0b0001	DEF
 EndEnum
-Res0	59:56
+UnsignedEnum	59:56	ExtTrcBuff
+	0b0000	NI
+	0b0001	IMP
+EndEnum
 UnsignedEnum	55:52	BRBE
 	0b0000	NI
 	0b0001	IMP
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:43 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:43 +0000
Subject: [PATCH v3 03/17] arm64/sysreg: Add missing system register
 definitions for FGT
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-4-tabba@google.com>

Add the definitions of missing system registers that are
trappable by fine grain traps. The definitions are based on
DDI0601 2023-09.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/tools/sysreg | 43 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index a8e36640c027..5ceaa1d3630e 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2086,10 +2086,18 @@ Sysreg	CONTEXTIDR_EL1	3	0	13	0	1
 Fields	CONTEXTIDR_ELx
 EndSysreg
 
+Sysreg	RCWSMASK_EL1	3	0	13	0	3
+Field	63:0	RCWSMASK
+EndSysreg
+
 Sysreg	TPIDR_EL1	3	0	13	0	4
 Field	63:0	ThreadID
 EndSysreg
 
+Sysreg	RCWMASK_EL1	3	0	13	0	6
+Field	63:0	RCWMASK
+EndSysreg
+
 Sysreg	SCXTNUM_EL1	3	0	13	0	7
 Field	63:0	SoftwareContextNumber
 EndSysreg
@@ -2714,6 +2722,33 @@ Field	1	PIE
 Field	0	PnCH
 EndSysreg
 
+SysregFields MAIR2_ELx
+Field	63:56	Attr7
+Field	55:48	Attr6
+Field	47:40	Attr5
+Field	39:32	Attr4
+Field	31:24	Attr3
+Field	23:16	Attr2
+Field	15:8	Attr1
+Field	7:0	Attr0
+EndSysregFields
+
+Sysreg	MAIR2_EL1	3	0	10	2	1
+Fields	MAIR2_ELx
+EndSysreg
+
+Sysreg	MAIR2_EL2	3	4	10	1	1
+Fields	MAIR2_ELx
+EndSysreg
+
+Sysreg	AMAIR2_EL1	3	0	10	3	1
+Field	63:0	ImpDef
+EndSysreg
+
+Sysreg	AMAIR2_EL2	3	4	10	3	1
+Field	63:0	ImpDef
+EndSysreg
+
 SysregFields PIRx_ELx
 Field	63:60	Perm15
 Field	59:56	Perm14
@@ -2765,6 +2800,14 @@ Sysreg	POR_EL12	3	5	10	2	4
 Fields	PIRx_ELx
 EndSysreg
 
+Sysreg	S2POR_EL1	3	0	10	2	5
+Fields	PIRx_ELx
+EndSysreg
+
+Sysreg	S2PIR_EL2	3	4	10	2	5
+Fields	PIRx_ELx
+EndSysreg
+
 Sysreg	LORSA_EL1	3	0	10	4	0
 Res0	63:52
 Field	51:16	SA
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:44 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:44 +0000
Subject: [PATCH v3 04/17] arm64/sysreg: Add missing system instruction
 definitions for FGT
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-5-tabba@google.com>

Add the definitions of missing system instructions that are
trappable by fine grain traps. The definitions are based on
DDI0602 2023-09.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/sysreg.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 9c2caf0efdc7..b320fb0de56b 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -645,6 +645,7 @@
 #define OP_AT_S1E0W	sys_insn(AT_Op0, 0, AT_CRn, 8, 3)
 #define OP_AT_S1E1RP	sys_insn(AT_Op0, 0, AT_CRn, 9, 0)
 #define OP_AT_S1E1WP	sys_insn(AT_Op0, 0, AT_CRn, 9, 1)
+#define OP_AT_S1E1A	sys_insn(AT_Op0, 0, AT_CRn, 9, 2)
 #define OP_AT_S1E2R	sys_insn(AT_Op0, 4, AT_CRn, 8, 0)
 #define OP_AT_S1E2W	sys_insn(AT_Op0, 4, AT_CRn, 8, 1)
 #define OP_AT_S12E1R	sys_insn(AT_Op0, 4, AT_CRn, 8, 4)
@@ -781,10 +782,16 @@
 #define OP_TLBI_VMALLS12E1NXS		sys_insn(1, 4, 9, 7, 6)
 
 /* Misc instructions */
+#define OP_GCSPUSHX			sys_insn(1, 0, 7, 7, 4)
+#define OP_GCSPOPCX			sys_insn(1, 0, 7, 7, 5)
+#define OP_GCSPOPX			sys_insn(1, 0, 7, 7, 6)
+#define OP_GCSPUSHM			sys_insn(1, 3, 7, 7, 0)
+
 #define OP_BRB_IALL			sys_insn(1, 1, 7, 2, 4)
 #define OP_BRB_INJ			sys_insn(1, 1, 7, 2, 5)
 #define OP_CFP_RCTX			sys_insn(1, 3, 7, 3, 4)
 #define OP_DVP_RCTX			sys_insn(1, 3, 7, 3, 5)
+#define OP_COSP_RCTX			sys_insn(1, 3, 7, 3, 6)
 #define OP_CPP_RCTX			sys_insn(1, 3, 7, 3, 7)
 
 /* Common SCTLR_ELx flags. */
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:45 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:45 +0000
Subject: [PATCH v3 05/17] KVM: arm64: Explicitly trap unsupported HFGxTR_EL2 features
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-6-tabba@google.com>

Do not rely on the value of __HFGRTR_EL2_nMASK to trap
unsupported features, since the nMASK can (and will) change as
new traps are added and as its value is updated. Instead,
explicitly specify the trap bits.

Suggested-by: Joey Gouly <joey.gouly at arm.com>
Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/include/hyp/switch.h | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index f99d8af0b9af..7b4909dfd1f5 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -110,12 +110,15 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 		compute_clr_set(vcpu, HFGWTR_EL2, w_clr, w_set);
 	}
 
-	/* The default is not to trap anything but ACCDATA_EL1 */
-	r_val = __HFGRTR_EL2_nMASK & ~HFGxTR_EL2_nACCDATA_EL1;
+	/* The default to trap everything not handled or supported in KVM. */
+	tmp = HFGxTR_EL2_nAMAIR2_EL1 | HFGxTR_EL2_nMAIR2_EL1 | HFGxTR_EL2_nS2POR_EL1 |
+	      HFGxTR_EL2_nPOR_EL1 | HFGxTR_EL2_nPOR_EL0 | HFGxTR_EL2_nACCDATA_EL1;
+
+	r_val = __HFGRTR_EL2_nMASK & ~tmp;
 	r_val |= r_set;
 	r_val &= ~r_clr;
 
-	w_val = __HFGWTR_EL2_nMASK & ~HFGxTR_EL2_nACCDATA_EL1;
+	w_val = __HFGWTR_EL2_nMASK & ~tmp;
 	w_val |= w_set;
 	w_val &= ~w_clr;
 
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:46 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:46 +0000
Subject: [PATCH v3 06/17] KVM: arm64: Add missing HFGxTR_EL2 FGT entries to
 nested virt
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-7-tabba@google.com>

Add the missing nested virt FGT table entries HFGxTR_EL2. Based
on DDI0601 2023-09.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/emulate-nested.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index 06185216a297..8b473a1bbc11 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -1042,10 +1042,20 @@ enum fg_filter_id {
 
 static const struct encoding_to_trap_config encoding_to_fgt[] __initconst = {
 	/* HFGRTR_EL2, HFGWTR_EL2 */
+	SR_FGT(SYS_AMAIR2_EL1,		HFGxTR, nAMAIR2_EL1, 0),
+	SR_FGT(SYS_MAIR2_EL1,		HFGxTR, nMAIR2_EL1, 0),
+	SR_FGT(SYS_S2POR_EL1,		HFGxTR, nS2POR_EL1, 0),
+	SR_FGT(SYS_POR_EL1,		HFGxTR, nPOR_EL1, 0),
+	SR_FGT(SYS_POR_EL0,		HFGxTR, nPOR_EL0, 0),
 	SR_FGT(SYS_PIR_EL1,		HFGxTR, nPIR_EL1, 0),
 	SR_FGT(SYS_PIRE0_EL1,		HFGxTR, nPIRE0_EL1, 0),
+	SR_FGT(SYS_RCWMASK_EL1,		HFGxTR, nRCWMASK_EL1, 0),
 	SR_FGT(SYS_TPIDR2_EL0,		HFGxTR, nTPIDR2_EL0, 0),
 	SR_FGT(SYS_SMPRI_EL1,		HFGxTR, nSMPRI_EL1, 0),
+	SR_FGT(SYS_GCSCR_EL1,		HFGxTR, nGCS_EL1, 0),
+	SR_FGT(SYS_GCSPR_EL1,		HFGxTR, nGCS_EL1, 0),
+	SR_FGT(SYS_GCSCRE0_EL1,		HFGxTR, nGCS_EL0, 0),
+	SR_FGT(SYS_GCSPR_EL0,		HFGxTR, nGCS_EL0, 0),
 	SR_FGT(SYS_ACCDATA_EL1,		HFGxTR, nACCDATA_EL1, 0),
 	SR_FGT(SYS_ERXADDR_EL1,		HFGxTR, ERXADDR_EL1, 1),
 	SR_FGT(SYS_ERXPFGCDN_EL1,	HFGxTR, ERXPFGCDN_EL1, 1),
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:47 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:47 +0000
Subject: [PATCH v3 07/17] KVM: arm64: Add missing HFGITR_EL2 FGT entries to
 nested virt
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-8-tabba@google.com>

Add the missing nested virt FGT table entries HFGITR_EL2. Based
on DDI0601 and DDI0602 2023-09.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/emulate-nested.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index 8b473a1bbc11..89901550db34 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -1117,6 +1117,11 @@ static const struct encoding_to_trap_config encoding_to_fgt[] __initconst = {
 	SR_FGT(SYS_AFSR1_EL1, 		HFGxTR, AFSR1_EL1, 1),
 	SR_FGT(SYS_AFSR0_EL1, 		HFGxTR, AFSR0_EL1, 1),
 	/* HFGITR_EL2 */
+	SR_FGT(OP_AT_S1E1A, 		HFGITR, ATS1E1A, 1),
+	SR_FGT(OP_COSP_RCTX, 		HFGITR, COSPRCTX, 1),
+	SR_FGT(OP_GCSPUSHX, 		HFGITR, nGCSEPP, 0),
+	SR_FGT(OP_GCSPOPX, 		HFGITR, nGCSEPP, 0),
+	SR_FGT(OP_GCSPUSHM, 		HFGITR, nGCSPUSHM_EL1, 0),
 	SR_FGT(OP_BRB_IALL, 		HFGITR, nBRBIALL, 0),
 	SR_FGT(OP_BRB_INJ, 		HFGITR, nBRBINJ, 0),
 	SR_FGT(SYS_DC_CVAC, 		HFGITR, DCCVAC, 1),
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:48 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:48 +0000
Subject: [PATCH v3 08/17] KVM: arm64: Add bit masks for HAFGRTR_EL2
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-9-tabba@google.com>

To support HAFGRTR_EL2 supported in nested virt in the following
patch, first add its bitmask definitions based on DDI0601 2023-09.

Reviewed-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index b85f46a73e21..7de0a7062625 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -370,6 +370,10 @@
 #define __HDFGWTR_EL2_MASK	~__HDFGWTR_EL2_nMASK
 #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
 
+#define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
+#define __HAFGRTR_EL2_MASK	(GENMASK(49, 17) | GENMASK(4, 0))
+#define __HAFGRTR_EL2_nMASK	0UL
+
 /* Similar definitions for HCRX_EL2 */
 #define __HCRX_EL2_RES0		(GENMASK(63, 16) | GENMASK(13, 12))
 #define __HCRX_EL2_MASK		(0)
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:49 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:49 +0000
Subject: [PATCH v3 09/17] KVM: arm64: Handle HAFGRTR_EL2 trapping in nested virt
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-10-tabba@google.com>

Add the encodings to fine grain trapping fields for HAFGRTR_EL2
and add the associated handling code in nested virt. Based on
DDI0601 2023-09. Add the missing field definitions as well,
both to generate the correct RES0 mask and to be able to toggle
their FGT bits.

Also add the code for handling FGT trapping, reading of the
register, to nested virt.

Reviewed-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_host.h       |  1 +
 arch/arm64/kvm/emulate-nested.c         | 48 +++++++++++++++++++++++++
 arch/arm64/kvm/hyp/include/hyp/switch.h | 12 +++++++
 arch/arm64/kvm/sys_regs.c               |  1 +
 4 files changed, 62 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 824f29f04916..ba14648e2de2 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -443,6 +443,7 @@ enum vcpu_sysreg {
 	HFGITR_EL2,
 	HDFGRTR_EL2,
 	HDFGWTR_EL2,
+	HAFGRTR_EL2,
 	CNTHP_CTL_EL2,
 	CNTHP_CVAL_EL2,
 	CNTHV_CTL_EL2,
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index 89901550db34..431fd429932d 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -1012,6 +1012,7 @@ enum fgt_group_id {
 	HDFGRTR_GROUP,
 	HDFGWTR_GROUP,
 	HFGITR_GROUP,
+	HAFGRTR_GROUP,
 
 	/* Must be last */
 	__NR_FGT_GROUP_IDS__
@@ -1689,6 +1690,49 @@ static const struct encoding_to_trap_config encoding_to_fgt[] __initconst = {
 	SR_FGT(SYS_PMCR_EL0,		HDFGWTR, PMCR_EL0, 1),
 	SR_FGT(SYS_PMSWINC_EL0,		HDFGWTR, PMSWINC_EL0, 1),
 	SR_FGT(SYS_OSLAR_EL1,		HDFGWTR, OSLAR_EL1, 1),
+	/*
+	 * HAFGRTR_EL2
+	 */
+	SR_FGT(SYS_AMEVTYPER1_EL0(15),	HAFGRTR, AMEVTYPER115_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(14),	HAFGRTR, AMEVTYPER114_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(13),	HAFGRTR, AMEVTYPER113_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(12),	HAFGRTR, AMEVTYPER112_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(11),	HAFGRTR, AMEVTYPER111_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(10),	HAFGRTR, AMEVTYPER110_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(9),	HAFGRTR, AMEVTYPER19_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(8),	HAFGRTR, AMEVTYPER18_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(7),	HAFGRTR, AMEVTYPER17_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(6),	HAFGRTR, AMEVTYPER16_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(5),	HAFGRTR, AMEVTYPER15_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(4),	HAFGRTR, AMEVTYPER14_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(3),	HAFGRTR, AMEVTYPER13_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(2),	HAFGRTR, AMEVTYPER12_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(1),	HAFGRTR, AMEVTYPER11_EL0, 1),
+	SR_FGT(SYS_AMEVTYPER1_EL0(0),	HAFGRTR, AMEVTYPER10_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(15),	HAFGRTR, AMEVCNTR115_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(14),	HAFGRTR, AMEVCNTR114_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(13),	HAFGRTR, AMEVCNTR113_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(12),	HAFGRTR, AMEVCNTR112_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(11),	HAFGRTR, AMEVCNTR111_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(10),	HAFGRTR, AMEVCNTR110_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(9),	HAFGRTR, AMEVCNTR19_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(8),	HAFGRTR, AMEVCNTR18_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(7),	HAFGRTR, AMEVCNTR17_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(6),	HAFGRTR, AMEVCNTR16_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(5),	HAFGRTR, AMEVCNTR15_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(4),	HAFGRTR, AMEVCNTR14_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(3),	HAFGRTR, AMEVCNTR13_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(2),	HAFGRTR, AMEVCNTR12_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(1),	HAFGRTR, AMEVCNTR11_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR1_EL0(0),	HAFGRTR, AMEVCNTR10_EL0, 1),
+	SR_FGT(SYS_AMCNTENCLR1_EL0,	HAFGRTR, AMCNTEN1, 1),
+	SR_FGT(SYS_AMCNTENSET1_EL0,	HAFGRTR, AMCNTEN1, 1),
+	SR_FGT(SYS_AMCNTENCLR0_EL0,	HAFGRTR, AMCNTEN0, 1),
+	SR_FGT(SYS_AMCNTENSET0_EL0,	HAFGRTR, AMCNTEN0, 1),
+	SR_FGT(SYS_AMEVCNTR0_EL0(3),	HAFGRTR, AMEVCNTR03_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR0_EL0(2),	HAFGRTR, AMEVCNTR02_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR0_EL0(1),	HAFGRTR, AMEVCNTR01_EL0, 1),
+	SR_FGT(SYS_AMEVCNTR0_EL0(0),	HAFGRTR, AMEVCNTR00_EL0, 1),
 };
 
 static union trap_config get_trap_config(u32 sysreg)
@@ -1909,6 +1953,10 @@ bool __check_nv_sr_forward(struct kvm_vcpu *vcpu)
 			val = sanitised_sys_reg(vcpu, HDFGWTR_EL2);
 		break;
 
+	case HAFGRTR_GROUP:
+		val = sanitised_sys_reg(vcpu, HAFGRTR_EL2);
+		break;
+
 	case HFGITR_GROUP:
 		val = sanitised_sys_reg(vcpu, HFGITR_EL2);
 		switch (tc.fgf) {
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 7b4909dfd1f5..22f3b916f60c 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -156,6 +156,17 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 
 	write_sysreg_s(r_val, SYS_HDFGRTR_EL2);
 	write_sysreg_s(w_val, SYS_HDFGWTR_EL2);
+
+	ctxt_sys_reg(hctxt, HAFGRTR_EL2) = read_sysreg_s(SYS_HAFGRTR_EL2);
+
+	r_clr = r_set = 0;
+	compute_clr_set(vcpu, HAFGRTR_EL2, r_clr, r_set);
+
+	r_val = __HAFGRTR_EL2_nMASK;
+	r_val |= r_set;
+	r_val &= ~r_clr;
+
+	write_sysreg_s(r_val, SYS_HAFGRTR_EL2);
 }
 
 static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
@@ -174,6 +185,7 @@ static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 	write_sysreg_s(ctxt_sys_reg(hctxt, HFGITR_EL2), SYS_HFGITR_EL2);
 	write_sysreg_s(ctxt_sys_reg(hctxt, HDFGRTR_EL2), SYS_HDFGRTR_EL2);
 	write_sysreg_s(ctxt_sys_reg(hctxt, HDFGWTR_EL2), SYS_HDFGWTR_EL2);
+	write_sysreg_s(ctxt_sys_reg(hctxt, HAFGRTR_EL2), SYS_HAFGRTR_EL2);
 }
 
 static inline void __activate_traps_common(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4735e1b37fb3..8bb297a2df38 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2532,6 +2532,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_DACR32_EL2), trap_undef, reset_unknown, DACR32_EL2 },
 	EL2_REG(HDFGRTR_EL2, access_rw, reset_val, 0),
 	EL2_REG(HDFGWTR_EL2, access_rw, reset_val, 0),
+	EL2_REG(HAFGRTR_EL2, access_rw, reset_val, 0),
 	EL2_REG(SPSR_EL2, access_rw, reset_val, 0),
 	EL2_REG(ELR_EL2, access_rw, reset_val, 0),
 	{ SYS_DESC(SYS_SP_EL1), access_sp_el1},
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:50 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:50 +0000
Subject: [PATCH v3 10/17] KVM: arm64: Update and fix FGT register masks
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-11-tabba@google.com>

New trap bits have been defined since the latest update to this
patch.  Moreover, the existing definitions of some of the mask
and the RES0 bits overlap, which could be wrong, confusing, or
both.

Update the bits based on DDI0601 2023-09, and ensure that the
existing bits are consistent.

Subsequent patches will use the generated RES0 fields instead of
specifying them manually. This patch keeps the manual encoding of
the bits to make it easier to review the series.

Fixes: 0fd76865006d ("KVM: arm64: Add nPIR{E0}_EL1 to HFG traps")
Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 39 ++++++++++++++++++++------------
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 7de0a7062625..b0dc3249d5cd 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -344,30 +344,39 @@
  * Once we get to a point where the two describe the same thing, we'll
  * merge the definitions. One day.
  */
-#define __HFGRTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51))
+#define __HFGRTR_EL2_RES0	BIT(51)
 #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
-#define __HFGRTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
+#define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
 
-#define __HFGWTR_EL2_RES0	(GENMASK(63, 56) | GENMASK(53, 51) |	\
-				 BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
-				 GENMASK(26, 25) | BIT(21) | BIT(18) |	\
+#define __HFGWTR_EL2_RES0	(BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
+				 BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
 				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
-#define __HFGWTR_EL2_MASK	GENMASK(49, 0)
-#define __HFGWTR_EL2_nMASK	(GENMASK(58, 57) | GENMASK(55, 54) | BIT(50))
+#define __HFGWTR_EL2_MASK	(GENMASK(49, 47) | GENMASK(45, 43) | \
+				 BIT(41) | GENMASK(39, 29) | BIT(27) | \
+				 GENMASK(24, 22) | GENMASK(20, 19) | \
+				 GENMASK(17, 16) | GENMASK(13, 11) | \
+				 GENMASK(8, 3) | GENMASK(1, 0))
+#define __HFGWTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
 
-#define __HFGITR_EL2_RES0	GENMASK(63, 57)
-#define __HFGITR_EL2_MASK	GENMASK(54, 0)
-#define __HFGITR_EL2_nMASK	GENMASK(56, 55)
+#define __HFGITR_EL2_RES0	(BIT(63) | BIT(61))
+#define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
+#define __HFGITR_EL2_nMASK	GENMASK(59, 55)
 
 #define __HDFGRTR_EL2_RES0	(BIT(49) | BIT(42) | GENMASK(39, 38) |	\
 				 GENMASK(21, 20) | BIT(8))
-#define __HDFGRTR_EL2_MASK	~__HDFGRTR_EL2_nMASK
+#define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
+				 GENMASK(41, 40) | GENMASK(37, 22) | \
+				 GENMASK(19, 9) | GENMASK(7, 0))
 #define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
 
 #define __HDFGWTR_EL2_RES0	(BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
 				 BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
 				 BIT(22) | BIT(9) | BIT(6))
-#define __HDFGWTR_EL2_MASK	~__HDFGWTR_EL2_nMASK
+#define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
+				 GENMASK(46, 44) | GENMASK(42, 41) | \
+				 GENMASK(37, 35) | GENMASK(33, 31) | \
+				 GENMASK(29, 23) | GENMASK(21, 10) | \
+				 GENMASK(8, 7) | GENMASK(5, 0))
 #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
 
 #define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
@@ -375,9 +384,9 @@
 #define __HAFGRTR_EL2_nMASK	0UL
 
 /* Similar definitions for HCRX_EL2 */
-#define __HCRX_EL2_RES0		(GENMASK(63, 16) | GENMASK(13, 12))
-#define __HCRX_EL2_MASK		(0)
-#define __HCRX_EL2_nMASK	(GENMASK(15, 14) | GENMASK(4, 0))
+#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
+#define __HCRX_EL2_MASK		(BIT(6))
+#define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
 
 /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
 #define HPFAR_MASK	(~UL(0xf))
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:51 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:51 +0000
Subject: [PATCH v3 11/17] KVM: arm64: Add build validation for FGT trap mask values
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-12-tabba@google.com>

These checks help ensure that all the bits are accounted for,
that there hasn't been a transcribing error from the spec nor
from the generated mask values, which will be used in subsequent
patches.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/include/hyp/switch.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 22f3b916f60c..17ce40f5b006 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -79,6 +79,16 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
 		clr |= ~hfg & __ ## reg ## _nMASK; 			\
 	} while(0)
 
+/*
+ * Validate the fine grain trap masks.
+ * Check that the masks do not overlap and that all bits are accounted for.
+ */
+#define CHECK_FGT_MASKS(reg)							\
+	do {									\
+		BUILD_BUG_ON((__ ## reg ## _MASK) & (__ ## reg ## _nMASK));	\
+		BUILD_BUG_ON(~((__ ## reg ## _RES0) ^ (__ ## reg ## _MASK) ^	\
+			       (__ ## reg ## _nMASK)));				\
+	} while(0)
 
 static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 {
@@ -86,6 +96,14 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 	u64 r_clr = 0, w_clr = 0, r_set = 0, w_set = 0, tmp;
 	u64 r_val, w_val;
 
+	CHECK_FGT_MASKS(HFGRTR_EL2);
+	CHECK_FGT_MASKS(HFGWTR_EL2);
+	CHECK_FGT_MASKS(HFGITR_EL2);
+	CHECK_FGT_MASKS(HDFGRTR_EL2);
+	CHECK_FGT_MASKS(HDFGWTR_EL2);
+	CHECK_FGT_MASKS(HAFGRTR_EL2);
+	CHECK_FGT_MASKS(HCRX_EL2);
+
 	if (!cpus_have_final_cap(ARM64_HAS_FGT))
 		return;
 
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:52 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:52 +0000
Subject: [PATCH v3 12/17] KVM: arm64: Use generated FGT RES0 bits instead of
 specifying them
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-13-tabba@google.com>

Now that all FGT fields are accounted for and represented, use
the generated value instead of manually specifying them.

For __HFGWTR_EL2_RES0, however, there is no generated value. Its
fields are subset of HFGRTR_EL2, with the remaining being RES0.
Therefore, add a mask that represents the HFGRTR_EL2 only bits
and define __HFGWTR_EL2_* using those and the __HFGRTR_EL2_*
fields.

No functional change intended.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 34 +++++++++++++++-----------------
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index b0dc3249d5cd..bd20d27f1b33 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -344,34 +344,32 @@
  * Once we get to a point where the two describe the same thing, we'll
  * merge the definitions. One day.
  */
-#define __HFGRTR_EL2_RES0	BIT(51)
+#define __HFGRTR_EL2_RES0	HFGxTR_EL2_RES0
 #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
 #define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
 
-#define __HFGWTR_EL2_RES0	(BIT(51) | BIT(46) | BIT(42) | BIT(40) | \
-				 BIT(28) | GENMASK(26, 25) | BIT(21) | BIT(18) | \
+/*
+ * The HFGWTR bits are a subset of HFGRTR bits. To ensure we don't miss any
+ * future additions, define __HFGWTR* macros relative to __HFGRTR* ones.
+ */
+#define __HFGRTR_ONLY_MASK	(BIT(46) | BIT(42) | BIT(40) | BIT(28) | \
+				 GENMASK(26, 25) | BIT(21) | BIT(18) | \
 				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
-#define __HFGWTR_EL2_MASK	(GENMASK(49, 47) | GENMASK(45, 43) | \
-				 BIT(41) | GENMASK(39, 29) | BIT(27) | \
-				 GENMASK(24, 22) | GENMASK(20, 19) | \
-				 GENMASK(17, 16) | GENMASK(13, 11) | \
-				 GENMASK(8, 3) | GENMASK(1, 0))
-#define __HFGWTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
-
-#define __HFGITR_EL2_RES0	(BIT(63) | BIT(61))
+#define __HFGWTR_EL2_RES0	(__HFGRTR_EL2_RES0 | __HFGRTR_ONLY_MASK)
+#define __HFGWTR_EL2_MASK	(__HFGRTR_EL2_MASK & ~__HFGRTR_ONLY_MASK)
+#define __HFGWTR_EL2_nMASK	(__HFGRTR_EL2_nMASK & ~__HFGRTR_ONLY_MASK)
+
+#define __HFGITR_EL2_RES0	HFGITR_EL2_RES0
 #define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
 #define __HFGITR_EL2_nMASK	GENMASK(59, 55)
 
-#define __HDFGRTR_EL2_RES0	(BIT(49) | BIT(42) | GENMASK(39, 38) |	\
-				 GENMASK(21, 20) | BIT(8))
+#define __HDFGRTR_EL2_RES0	HDFGRTR_EL2_RES0
 #define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
 				 GENMASK(41, 40) | GENMASK(37, 22) | \
 				 GENMASK(19, 9) | GENMASK(7, 0))
 #define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
 
-#define __HDFGWTR_EL2_RES0	(BIT(63) | GENMASK(59, 58) | BIT(51) | BIT(47) | \
-				 BIT(43) | GENMASK(40, 38) | BIT(34) | BIT(30) | \
-				 BIT(22) | BIT(9) | BIT(6))
+#define __HDFGWTR_EL2_RES0	HDFGWTR_EL2_RES0
 #define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
 				 GENMASK(46, 44) | GENMASK(42, 41) | \
 				 GENMASK(37, 35) | GENMASK(33, 31) | \
@@ -379,12 +377,12 @@
 				 GENMASK(8, 7) | GENMASK(5, 0))
 #define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
 
-#define __HAFGRTR_EL2_RES0	(GENMASK(63, 50) | GENMASK(16, 5))
+#define __HAFGRTR_EL2_RES0	HAFGRTR_EL2_RES0
 #define __HAFGRTR_EL2_MASK	(GENMASK(49, 17) | GENMASK(4, 0))
 #define __HAFGRTR_EL2_nMASK	0UL
 
 /* Similar definitions for HCRX_EL2 */
-#define __HCRX_EL2_RES0         (GENMASK(63, 25) | GENMASK(13, 12))
+#define __HCRX_EL2_RES0         HCRX_EL2_RES0
 #define __HCRX_EL2_MASK		(BIT(6))
 #define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
 
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:53 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:53 +0000
Subject: [PATCH v3 13/17] KVM: arm64: Define FGT nMASK bits relative to other fields
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-14-tabba@google.com>

Now that RES0 and MASK have full coverage, no speed to manually
encode nMASK. Calculate it relative to the other fields.

No functional change intended.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/include/asm/kvm_arm.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index bd20d27f1b33..b7a9fe36bb59 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -346,7 +346,7 @@
  */
 #define __HFGRTR_EL2_RES0	HFGxTR_EL2_RES0
 #define __HFGRTR_EL2_MASK	GENMASK(49, 0)
-#define __HFGRTR_EL2_nMASK	(GENMASK(63, 52) | BIT(50))
+#define __HFGRTR_EL2_nMASK	~(__HFGRTR_EL2_RES0 | __HFGRTR_EL2_MASK)
 
 /*
  * The HFGWTR bits are a subset of HFGRTR bits. To ensure we don't miss any
@@ -357,17 +357,17 @@
 				 GENMASK(15, 14) | GENMASK(10, 9) | BIT(2))
 #define __HFGWTR_EL2_RES0	(__HFGRTR_EL2_RES0 | __HFGRTR_ONLY_MASK)
 #define __HFGWTR_EL2_MASK	(__HFGRTR_EL2_MASK & ~__HFGRTR_ONLY_MASK)
-#define __HFGWTR_EL2_nMASK	(__HFGRTR_EL2_nMASK & ~__HFGRTR_ONLY_MASK)
+#define __HFGWTR_EL2_nMASK	~(__HFGWTR_EL2_RES0 | __HFGWTR_EL2_MASK)
 
 #define __HFGITR_EL2_RES0	HFGITR_EL2_RES0
 #define __HFGITR_EL2_MASK	(BIT(62) | BIT(60) | GENMASK(54, 0))
-#define __HFGITR_EL2_nMASK	GENMASK(59, 55)
+#define __HFGITR_EL2_nMASK	~(__HFGITR_EL2_RES0 | __HFGITR_EL2_MASK)
 
 #define __HDFGRTR_EL2_RES0	HDFGRTR_EL2_RES0
 #define __HDFGRTR_EL2_MASK	(BIT(63) | GENMASK(58, 50) | GENMASK(48, 43) | \
 				 GENMASK(41, 40) | GENMASK(37, 22) | \
 				 GENMASK(19, 9) | GENMASK(7, 0))
-#define __HDFGRTR_EL2_nMASK	GENMASK(62, 59)
+#define __HDFGRTR_EL2_nMASK	~(__HDFGRTR_EL2_RES0 | __HDFGRTR_EL2_MASK)
 
 #define __HDFGWTR_EL2_RES0	HDFGWTR_EL2_RES0
 #define __HDFGWTR_EL2_MASK	(GENMASK(57, 52) | GENMASK(50, 48) | \
@@ -375,16 +375,16 @@
 				 GENMASK(37, 35) | GENMASK(33, 31) | \
 				 GENMASK(29, 23) | GENMASK(21, 10) | \
 				 GENMASK(8, 7) | GENMASK(5, 0))
-#define __HDFGWTR_EL2_nMASK	GENMASK(62, 60)
+#define __HDFGWTR_EL2_nMASK	~(__HDFGWTR_EL2_RES0 | __HDFGWTR_EL2_MASK)
 
 #define __HAFGRTR_EL2_RES0	HAFGRTR_EL2_RES0
 #define __HAFGRTR_EL2_MASK	(GENMASK(49, 17) | GENMASK(4, 0))
-#define __HAFGRTR_EL2_nMASK	0UL
+#define __HAFGRTR_EL2_nMASK	~(__HAFGRTR_EL2_RES0 | __HAFGRTR_EL2_MASK)
 
 /* Similar definitions for HCRX_EL2 */
 #define __HCRX_EL2_RES0         HCRX_EL2_RES0
 #define __HCRX_EL2_MASK		(BIT(6))
-#define __HCRX_EL2_nMASK	(GENMASK(24, 14) | GENMASK(11, 7) | GENMASK(5, 0))
+#define __HCRX_EL2_nMASK	~(__HCRX_EL2_RES0 | __HCRX_EL2_MASK)
 
 /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
 #define HPFAR_MASK	(~UL(0xf))
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:54 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:54 +0000
Subject: [PATCH v3 14/17] KVM: arm64: Macros for setting/clearing FGT bits
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-15-tabba@google.com>

There's a lot of boilerplate code for setting and clearing FGT
bits when activating guest traps. Refactor it into macros. These
macros will also be used in future patch series.

No functional change intended.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/include/hyp/switch.h | 60 +++++++++----------------
 1 file changed, 21 insertions(+), 39 deletions(-)

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 17ce40f5b006..e223fc0d5193 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -79,6 +79,23 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
 		clr |= ~hfg & __ ## reg ## _nMASK; 			\
 	} while(0)
 
+#define update_fgt_traps_cs(reg, clr, set)				\
+	do {								\
+		struct kvm_cpu_context *hctxt =				\
+			&this_cpu_ptr(&kvm_host_data)->host_ctxt;	\
+		u64 val, c = 0, s = 0;					\
+									\
+		ctxt_sys_reg(hctxt, reg) = read_sysreg_s(SYS_ ## reg);	\
+		compute_clr_set(vcpu, reg, c, s);			\
+		val = __ ## reg ## _nMASK;				\
+		val |= (s | set);					\
+		val &= ~(c | clr);					\
+		write_sysreg_s(val, SYS_ ## reg);			\
+	} while(0)
+
+#define update_fgt_traps(reg)						\
+	update_fgt_traps_cs(reg, 0, 0)
+
 /*
  * Validate the fine grain trap masks.
  * Check that the masks do not overlap and that all bits are accounted for.
@@ -146,45 +163,10 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 	if (!vcpu_has_nv(vcpu) || is_hyp_ctxt(vcpu))
 		return;
 
-	ctxt_sys_reg(hctxt, HFGITR_EL2) = read_sysreg_s(SYS_HFGITR_EL2);
-
-	r_set = r_clr = 0;
-	compute_clr_set(vcpu, HFGITR_EL2, r_clr, r_set);
-	r_val = __HFGITR_EL2_nMASK;
-	r_val |= r_set;
-	r_val &= ~r_clr;
-
-	write_sysreg_s(r_val, SYS_HFGITR_EL2);
-
-	ctxt_sys_reg(hctxt, HDFGRTR_EL2) = read_sysreg_s(SYS_HDFGRTR_EL2);
-	ctxt_sys_reg(hctxt, HDFGWTR_EL2) = read_sysreg_s(SYS_HDFGWTR_EL2);
-
-	r_clr = r_set = w_clr = w_set = 0;
-
-	compute_clr_set(vcpu, HDFGRTR_EL2, r_clr, r_set);
-	compute_clr_set(vcpu, HDFGWTR_EL2, w_clr, w_set);
-
-	r_val = __HDFGRTR_EL2_nMASK;
-	r_val |= r_set;
-	r_val &= ~r_clr;
-
-	w_val = __HDFGWTR_EL2_nMASK;
-	w_val |= w_set;
-	w_val &= ~w_clr;
-
-	write_sysreg_s(r_val, SYS_HDFGRTR_EL2);
-	write_sysreg_s(w_val, SYS_HDFGWTR_EL2);
-
-	ctxt_sys_reg(hctxt, HAFGRTR_EL2) = read_sysreg_s(SYS_HAFGRTR_EL2);
-
-	r_clr = r_set = 0;
-	compute_clr_set(vcpu, HAFGRTR_EL2, r_clr, r_set);
-
-	r_val = __HAFGRTR_EL2_nMASK;
-	r_val |= r_set;
-	r_val &= ~r_clr;
-
-	write_sysreg_s(r_val, SYS_HAFGRTR_EL2);
+	update_fgt_traps(HFGITR_EL2);
+	update_fgt_traps(HDFGRTR_EL2);
+	update_fgt_traps(HDFGWTR_EL2);
+	update_fgt_traps(HAFGRTR_EL2);
 }
 
 static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:55 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:55 +0000
Subject: [PATCH v3 15/17] KVM: arm64: Fix which features are marked as allowed
 for protected VMs
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-16-tabba@google.com>

Cache maintenance operations are not trapped for protected VMs,
and shouldn't be. Mark them as allowed.

Moreover, features advertised by ID_AA64PFR2 and ID_AA64MMFR3 are
(already) not allowed, mark them as such.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/include/nvhe/fixed_config.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
index e91922daa8ca..8d97dff4bb7b 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
@@ -69,6 +69,8 @@
 	ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_SSBS) \
 	)
 
+#define PVM_ID_AA64PFR2_ALLOW 0ULL
+
 /*
  * Allow for protected VMs:
  * - Mixed-endian
@@ -101,6 +103,7 @@
  * - Privileged Access Never
  * - SError interrupt exceptions from speculative reads
  * - Enhanced Translation Synchronization
+ * - Control for cache maintenance permission
  */
 #define PVM_ID_AA64MMFR1_ALLOW (\
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_HAFDBS) | \
@@ -108,7 +111,8 @@
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_HPDS) | \
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_PAN) | \
 	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_SpecSEI) | \
-	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_ETS) \
+	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_ETS) | \
+	ARM64_FEATURE_MASK(ID_AA64MMFR1_EL1_CMOW) \
 	)
 
 /*
@@ -133,6 +137,8 @@
 	ARM64_FEATURE_MASK(ID_AA64MMFR2_EL1_E0PD) \
 	)
 
+#define PVM_ID_AA64MMFR3_ALLOW (0ULL)
+
 /*
  * No support for Scalable Vectors for protected VMs:
  *	Requires additional support from KVM, e.g., context-switching and
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:56 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:56 +0000
Subject: [PATCH v3 16/17] KVM: arm64: Mark PAuth as a restricted feature for
 protected VMs
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-17-tabba@google.com>

Protected VMs will only support basic PAuth (FEAT_PAuth). Mark it
as restricted to ensure that later versions aren't supported for
protected guests.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/include/nvhe/fixed_config.h | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
index 8d97dff4bb7b..51f043649146 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
@@ -184,10 +184,18 @@
 	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_RNDR) \
 	)
 
+/* Restrict pointer authentication to the basic version. */
+#define PVM_ID_AA64ISAR1_RESTRICT_UNSIGNED (\
+	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_APA), ID_AA64ISAR1_EL1_APA_PAuth) | \
+	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_API), ID_AA64ISAR1_EL1_API_PAuth) \
+	)
+
+#define PVM_ID_AA64ISAR2_RESTRICT_UNSIGNED (\
+	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64ISAR2_EL1_APA3), ID_AA64ISAR2_EL1_APA3_PAuth) \
+	)
+
 #define PVM_ID_AA64ISAR1_ALLOW (\
 	ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_DPB) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_APA) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_API) | \
 	ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_JSCVT) | \
 	ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_FCMA) | \
 	ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_LRCPC) | \
@@ -202,8 +210,8 @@
 	)
 
 #define PVM_ID_AA64ISAR2_ALLOW (\
+	ARM64_FEATURE_MASK(ID_AA64ISAR2_EL1_ATS1A)| \
 	ARM64_FEATURE_MASK(ID_AA64ISAR2_EL1_GPA3) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR2_EL1_APA3) | \
 	ARM64_FEATURE_MASK(ID_AA64ISAR2_EL1_MOPS) \
 	)
 
-- 
2.43.0.472.g3155946c3a-goog



From tabba at google.com  Thu Dec 14 02:01:57 2023
From: tabba at google.com (Fuad Tabba)
Date: Thu, 14 Dec 2023 10:01:57 +0000
Subject: [PATCH v3 17/17] KVM: arm64: Trap external trace for protected VMs
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <20231214100158.2305400-18-tabba@google.com>

pKVM does not support external trace for protected VMs. Trap
external trace, and add the ExtTrcBuff to make it possible to
check for the feature.

Signed-off-by: Fuad Tabba <tabba at google.com>
---
 arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 9d23a51d7f75..84b5c3f387d8 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -136,6 +136,10 @@ static void pvm_init_traps_aa64dfr0(struct kvm_vcpu *vcpu)
 			cptr_set |= CPTR_EL2_TTA;
 	}
 
+	/* Trap External Trace */
+	if (!FIELD_GET(ARM64_FEATURE_MASK(ID_AA64DFR0_EL1_ExtTrcBuff), feature_ids))
+		mdcr_clear |= MDCR_EL2_E2TB_MASK << MDCR_EL2_E2TB_SHIFT;
+
 	vcpu->arch.mdcr_el2 |= mdcr_set;
 	vcpu->arch.mdcr_el2 &= ~mdcr_clear;
 	vcpu->arch.cptr_el2 |= cptr_set;
-- 
2.43.0.472.g3155946c3a-goog



From sherry.sun at nxp.com  Thu Dec 14 02:03:51 2023
From: sherry.sun at nxp.com (Sherry Sun)
Date: Thu, 14 Dec 2023 10:03:51 +0000
Subject: [PATCH V2 0/4] PCI: imx6: Add pci host wakeup support
In-Reply-To: <20231214051328.GD2938@thinkpad>
References: <20231213092850.1706042-1-sherry.sun@nxp.com>
 <20231214051328.GD2938@thinkpad>
Message-ID: <AS8PR04MB84046143C236AEA322BBBAD3928CA@AS8PR04MB8404.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
> Sent: 2023?12?14? 13:13
> To: Sherry Sun <sherry.sun at nxp.com>
> Cc: Hongxing Zhu <hongxing.zhu at nxp.com>; l.stach at pengutronix.de;
> lpieralisi at kernel.org; kw at linux.com; robh at kernel.org;
> bhelgaas at google.com; krzysztof.kozlowski+dt at linaro.org;
> conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de;
> kernel at pengutronix.de; festevam at gmail.com; dl-linux-imx <linux-
> imx at nxp.com>; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH V2 0/4] PCI: imx6: Add pci host wakeup support
>
> On Wed, Dec 13, 2023 at 05:28:46PM +0800, Sherry Sun wrote:
> > Add pci host wakeup feature for imx platforms. The host wake pin is a
> > standard feature in the PCIe bus specification, so we can add this
> > property under PCI dts node to support the host gpio wakeup feature.
> >
> > Example of configuring the corresponding dts property under the PCI node:
> >     wake-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;
> >
>
> As you mentioned, WAKE# is a standard sideband signal defined in the PCI
> spec.
> So the support for handling it has to be in the PCI core layer, not in the host
> controller drivers.
>
> There is already a series floating to add support for WAKE# in PCI core.
> Please take a look:
>
> https://lore.k/
> ernel.org%2Flinux-pci%2F20230208111645.3863534-1-
> mmaddireddy%40nvidia.com%2F&data=05%7C02%7Csherry.sun%40nxp.co
> m%7C0254c001df61498c09d408dbfc636f5c%7C686ea1d3bc2b4c6fa92cd99c5
> c301635%7C0%7C0%7C638381276239824912%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C3000%7C%7C%7C&sdata=IoBAwTy0qeb0J6JrK0WRhI8A4ThUfkVx6mri
> ve%2BK5xs%3D&reserved=0

Hi Manivannan,
I checked the patch set, the implementation of host wake gpio is different from mine, I referred to the mmc bus cd(card detect) pin implementation and I think it is simpler and clearer.
Regarding whether the WAKE# support should be moved to PCI core layer, we may need more research and discussion. Thanks for your suggestions.

Best Regards
Sherry


>
> - Mani
>
> > ---
> > changes in V2:
> > 1. Rename host-wake-gpio property to wake-gpios.
> > 2. Improve the wake-gpios property description in the dt-binding doc
> > to avoid confusion.
> > 3. Remove unnecessary debugging info in host_wake_irq_handler().
> > 4. Remove unnecessary imx6_pcie->host_wake_irq = -1 resetting in error
> paths.
> > 5. Use dev_err_probe() to simplify error path code.
> > ---
> >
> > Sherry Sun (4):
> >   PCI: imx6: Add pci host wakeup support on imx platforms.
> >   dt-bindings: imx6q-pcie: Add wake-gpios property
> >   arm64: dts: imx8mp-evk: add wake-gpios property for pci bus
> >   arm64: dts: imx8mq-evk: add wake-gpios property for pci bus
> >
> >  .../bindings/pci/fsl,imx6q-pcie.yaml          |  6 ++
> >  arch/arm64/boot/dts/freescale/imx8mp-evk.dts  |  2 +
> > arch/arm64/boot/dts/freescale/imx8mq-evk.dts  |  2 +
> >  drivers/pci/controller/dwc/pci-imx6.c         | 60 +++++++++++++++++++
> >  4 files changed, 70 insertions(+)
> >
> > --
> > 2.34.1
> >
> >
>
> --
> ????????? ????????

From lkp at intel.com  Thu Dec 14 02:06:42 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 14 Dec 2023 18:06:42 +0800
Subject: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx
 platforms.
In-Reply-To: <20231213092850.1706042-2-sherry.sun@nxp.com>
References: <20231213092850.1706042-2-sherry.sun@nxp.com>
Message-ID: <202312141726.nPrR7WDt-lkp@intel.com>

Hi Sherry,

kernel test robot noticed the following build warnings:

[auto build test WARNING on pci/next]
[also build test WARNING on pci/for-linus shawnguo/for-next robh/for-next linus/master v6.7-rc5 next-20231214]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Sherry-Sun/PCI-imx6-Add-pci-host-wakeup-support-on-imx-platforms/20231213-173031
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:    https://lore.kernel.org/r/20231213092850.1706042-2-sherry.sun%40nxp.com
patch subject: [PATCH V2 1/4] PCI: imx6: Add pci host wakeup support on imx platforms.
config: arm-randconfig-004-20231213 (https://download.01.org/0day-ci/archive/20231214/202312141726.nPrR7WDt-lkp at intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231214/202312141726.nPrR7WDt-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312141726.nPrR7WDt-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> drivers/pci/controller/dwc/pci-imx6.c:1267:13: warning: no previous prototype for function 'host_wake_irq_handler' [-Wmissing-prototypes]
    1267 | irqreturn_t host_wake_irq_handler(int irq, void *priv)
         |             ^
   drivers/pci/controller/dwc/pci-imx6.c:1267:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
    1267 | irqreturn_t host_wake_irq_handler(int irq, void *priv)
         | ^
         | static 
   1 warning generated.


vim +/host_wake_irq_handler +1267 drivers/pci/controller/dwc/pci-imx6.c

  1266	
> 1267	irqreturn_t host_wake_irq_handler(int irq, void *priv)
  1268	{
  1269		struct imx6_pcie *imx6_pcie = priv;
  1270		struct device *dev = imx6_pcie->pci->dev;
  1271	
  1272		/* Notify PM core we are wakeup source */
  1273		pm_wakeup_event(dev, 0);
  1274		pm_system_wakeup();
  1275	
  1276		return IRQ_HANDLED;
  1277	}
  1278	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From eauger at redhat.com  Thu Dec 14 02:13:38 2023
From: eauger at redhat.com (Eric Auger)
Date: Thu, 14 Dec 2023 11:13:38 +0100
Subject: [PATCH v2 3/5] KVM: selftests: aarch64: Fix the buggy
 [enable|disable]_counter
In-Reply-To: <20231129072712.2667337-4-shahuang@redhat.com>
References: <20231129072712.2667337-1-shahuang@redhat.com>
 <20231129072712.2667337-4-shahuang@redhat.com>
Message-ID: <b3882f12-04e0-4293-9f94-19895b182d2f@redhat.com>

Hi Shaoqin,

On 11/29/23 08:27, Shaoqin Huang wrote:
> In general, the set/clr registers should always be used in their
> write form, never in a RMW form (imagine an interrupt disabling
> a counter between the read and the write...).
> 
> The current implementation of [enable|disable]_counter both use the RMW
> form, fix them by directly write to the set/clr registers.
> 
> At the same time, it also fix the buggy disable_counter() which would
> end up disabling all the counters.
> 
> Signed-off-by: Shaoqin Huang <shahuang at redhat.com>
Reviewed-by: Eric Auger <eric.auger at redhat.com>

Eric

> ---
>  tools/testing/selftests/kvm/include/aarch64/vpmu.h | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/testing/selftests/kvm/include/aarch64/vpmu.h b/tools/testing/selftests/kvm/include/aarch64/vpmu.h
> index e0cc1ca1c4b7..644dae3814b5 100644
> --- a/tools/testing/selftests/kvm/include/aarch64/vpmu.h
> +++ b/tools/testing/selftests/kvm/include/aarch64/vpmu.h
> @@ -78,17 +78,13 @@ static inline void write_sel_evtyper(int sel, unsigned long val)
>  
>  static inline void enable_counter(int idx)
>  {
> -	uint64_t v = read_sysreg(pmcntenset_el0);
> -
> -	write_sysreg(BIT(idx) | v, pmcntenset_el0);
> +	write_sysreg(BIT(idx), pmcntenset_el0);
>  	isb();
>  }
>  
>  static inline void disable_counter(int idx)
>  {
> -	uint64_t v = read_sysreg(pmcntenset_el0);
> -
> -	write_sysreg(BIT(idx) | v, pmcntenclr_el0);
> +	write_sysreg(BIT(idx), pmcntenclr_el0);
>  	isb();
>  }
>  



From manivannan.sadhasivam at linaro.org  Thu Dec 14 02:15:15 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Thu, 14 Dec 2023 15:45:15 +0530
Subject: [PATCH V2 0/4] PCI: imx6: Add pci host wakeup support
In-Reply-To: <AS8PR04MB84046143C236AEA322BBBAD3928CA@AS8PR04MB8404.eurprd04.prod.outlook.com>
References: <20231213092850.1706042-1-sherry.sun@nxp.com>
 <20231214051328.GD2938@thinkpad>
 <AS8PR04MB84046143C236AEA322BBBAD3928CA@AS8PR04MB8404.eurprd04.prod.outlook.com>
Message-ID: <20231214101515.GJ2938@thinkpad>

On Thu, Dec 14, 2023 at 10:03:51AM +0000, Sherry Sun wrote:
> 
> 
> > -----Original Message-----
> > From: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
> > Sent: 2023?12?14? 13:13
> > To: Sherry Sun <sherry.sun at nxp.com>
> > Cc: Hongxing Zhu <hongxing.zhu at nxp.com>; l.stach at pengutronix.de;
> > lpieralisi at kernel.org; kw at linux.com; robh at kernel.org;
> > bhelgaas at google.com; krzysztof.kozlowski+dt at linaro.org;
> > conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de;
> > kernel at pengutronix.de; festevam at gmail.com; dl-linux-imx <linux-
> > imx at nxp.com>; linux-pci at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-
> > kernel at vger.kernel.org
> > Subject: Re: [PATCH V2 0/4] PCI: imx6: Add pci host wakeup support
> >
> > On Wed, Dec 13, 2023 at 05:28:46PM +0800, Sherry Sun wrote:
> > > Add pci host wakeup feature for imx platforms. The host wake pin is a
> > > standard feature in the PCIe bus specification, so we can add this
> > > property under PCI dts node to support the host gpio wakeup feature.
> > >
> > > Example of configuring the corresponding dts property under the PCI node:
> > >     wake-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;
> > >
> >
> > As you mentioned, WAKE# is a standard sideband signal defined in the PCI
> > spec.
> > So the support for handling it has to be in the PCI core layer, not in the host
> > controller drivers.
> >
> > There is already a series floating to add support for WAKE# in PCI core.
> > Please take a look:
> >
> > https://lore.k/
> > ernel.org%2Flinux-pci%2F20230208111645.3863534-1-
> > mmaddireddy%40nvidia.com%2F&data=05%7C02%7Csherry.sun%40nxp.co
> > m%7C0254c001df61498c09d408dbfc636f5c%7C686ea1d3bc2b4c6fa92cd99c5
> > c301635%7C0%7C0%7C638381276239824912%7CUnknown%7CTWFpbGZsb3
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D%7C3000%7C%7C%7C&sdata=IoBAwTy0qeb0J6JrK0WRhI8A4ThUfkVx6mri
> > ve%2BK5xs%3D&reserved=0
> 
> Hi Manivannan,
> I checked the patch set, the implementation of host wake gpio is different from mine, I referred to the mmc bus cd(card detect) pin implementation and I think it is simpler and clearer.

It's not just about simple and clear code, but about scalability. See below.

> Regarding whether the WAKE# support should be moved to PCI core layer, we may need more research and discussion. Thanks for your suggestions.
> 

We can research and come up with a better solution, but the implementation has
to be done in the PCI core layer. Otherwise, host controllers supporting WAKE#
has to duplicate the code which is common.

- Mani

> Best Regards
> Sherry
> 
> 
> >
> > - Mani
> >
> > > ---
> > > changes in V2:
> > > 1. Rename host-wake-gpio property to wake-gpios.
> > > 2. Improve the wake-gpios property description in the dt-binding doc
> > > to avoid confusion.
> > > 3. Remove unnecessary debugging info in host_wake_irq_handler().
> > > 4. Remove unnecessary imx6_pcie->host_wake_irq = -1 resetting in error
> > paths.
> > > 5. Use dev_err_probe() to simplify error path code.
> > > ---
> > >
> > > Sherry Sun (4):
> > >   PCI: imx6: Add pci host wakeup support on imx platforms.
> > >   dt-bindings: imx6q-pcie: Add wake-gpios property
> > >   arm64: dts: imx8mp-evk: add wake-gpios property for pci bus
> > >   arm64: dts: imx8mq-evk: add wake-gpios property for pci bus
> > >
> > >  .../bindings/pci/fsl,imx6q-pcie.yaml          |  6 ++
> > >  arch/arm64/boot/dts/freescale/imx8mp-evk.dts  |  2 +
> > > arch/arm64/boot/dts/freescale/imx8mq-evk.dts  |  2 +
> > >  drivers/pci/controller/dwc/pci-imx6.c         | 60 +++++++++++++++++++
> > >  4 files changed, 70 insertions(+)
> > >
> > > --
> > > 2.34.1
> > >
> > >
> >
> > --
> > ????????? ????????

-- 
????????? ????????


From u.kleine-koenig at pengutronix.de  Thu Dec 14 02:26:45 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Thu, 14 Dec 2023 11:26:45 +0100
Subject: [PATCH v6 36/40] ata: pata_ep93xx: remove legacy pinctrl use
In-Reply-To: <ZXn8lzb953iDiM_m@smile.fi.intel.com>
References: <20231212-ep93xx-v6-0-c307b8ac9aa8@maquefel.me>
 <20231212-ep93xx-v6-36-c307b8ac9aa8@maquefel.me>
 <ZXn0-pHxIztvRFLK@smile.fi.intel.com>
 <20231213183349.hdjoxxszrrc4hqrg@pengutronix.de>
 <ZXn8lzb953iDiM_m@smile.fi.intel.com>
Message-ID: <20231214102645.xrbcbfc5hks6kltv@pengutronix.de>

On Wed, Dec 13, 2023 at 08:48:55PM +0200, Andy Shevchenko wrote:
> On Wed, Dec 13, 2023 at 07:33:49PM +0100, Uwe Kleine-K?nig wrote:
> > On Wed, Dec 13, 2023 at 08:16:26PM +0200, Andy Shevchenko wrote:
> > > On Tue, Dec 12, 2023 at 11:20:53AM +0300, Nikita Shubin wrote:
> > > > Drop legacy acquire/release since we are using pinctrl for this now.
> 
> ...
> 
> > > I think you wanted
> > > 
> > > 	ret = PTR_ERR_OR_ZERO(drv_data->dma_rx_channel);
> > > 	if (ret)
> > > 		return dev_err_probe(dev, ret, "rx DMA setup failed");
> > 
> > How is that different from
> > 
> > 	if (IS_ERR(drv_data->dma_rx_channel))
> > 		return dev_err_probe(dev, PTR_ERR(drv_data->dma_rx_channel), "....");
> > 
> > (which seems to be more idiomatic to me)? While I was involved in
> > creating PTR_ERR_OR_ZERO, I don't particularily like it (today).
> 
> Makes lines shorter, either works for me.

If you want shorter lines, I'd prefer

	if (IS_ERR(drv_data->dma_rx_channel)) {
		ret = PTR_ERR(drv_data->dma_rx_channel);
		return dev_err_probe(dev, ret, "...\n");
	}

over
	ret = PTR_ERR_OR_ZERO(drv_data->dma_rx_channel);
	if (ret)
		return dev_err_probe(dev, ret, "\n");

even though it's one line longer because the if body needs curly braces.
I think it's easier to parse for a human which IMHO matters more than
the additional line. But I'm aware that might be subjective.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/75c11997/attachment.sig>

From angelogioacchino.delregno at collabora.com  Thu Dec 14 02:31:41 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 14 Dec 2023 11:31:41 +0100
Subject: [PATCH v4 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <20231213150435.4134390-7-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
 <20231213150435.4134390-7-wenst@chromium.org>
Message-ID: <13c8ccbc-0eef-43f5-ae37-29ec64d1606b@collabora.com>

Il 13/12/23 16:04, Chen-Yu Tsai ha scritto:
> Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> Krabby design.
> 
> Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> convertible device with touchscreen and stylus.
> 
> Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> device. It does not have a touchscreen or stylus.
> 
> The two devices both have two variants. The difference is a second
> source touchpad controller that shares the same address as the original,
> but is incompatible.
> 
> The extra SKU IDs for the Tentacruel devices map to different sensor
> components attached to the Embedded Controller. These are not visible
> to the main processor.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>
> ---
> Changes since v3:
> - Reorder some properties to conform better to the newly proposed DT
>    style guidelines
> - Drop unused labels
> - Rename bt-sco node name to bt-sco-codec
> - Drop i2s*-share properties from afe node
> - Drop aud_gpio_tdm_{on,off} pinctrl nodes
> - Replace interrupts with interrupts-extended in tpm node
> - Enable adsp device
> 
> Changes since v2:
> - Picked up Conor's ack
> - Rename touchpad to trackpad
> - Drop pinctrl properties from trackpad in tentacruel/tentacool second
>    source trackpad
> 
> Changes since v1:
> - Reorder SKU numbers in descending order.
> - Fixed pinconfig node names
> - Moved pinctrl-* properties after interrupts-*
> - Switched to interrupts-extended for external components
> - Marked ADSP as explicitly disabled, with a comment explaining that it
>    stalls the system
> - Renamed "touchpad" to "trackpad"
> - Dropped bogus "no-laneswap" property from it6505 node
> - Moved "realtek,jd-src" property to after all the regulator supplies
> - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> - Renamed "vgpu" regulator name to allow coupling, with a comment
>    containing the name used in the design
> - Renamed "cr50" node name to "tpm"
> - Moved trackpad_pins reference up to i2c2; workaround for second source
>    component resource sharing.
> - Fix copyright year
> - Fixed touchscreen supply name
> ---
>   arch/arm64/boot/dts/mediatek/Makefile         |    4 +
>   .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
>   .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
>   .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
>   .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
>   .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
>   .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1707 +++++++++++++++++
>   7 files changed, 1991 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> 
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index e6e7592a3645..442af61b1305 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb

..snip..

> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> new file mode 100644
> index 000000000000..447b57b12b41
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2023 Google LLC
> + */
> +
> +#include "mt8186-corsola-tentacruel-sku262144.dts"
> +
> +/ {
> +	compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> +		     "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> +		     "google,tentacruel", "mediatek,mt8186";
> +};
> +
> +/* This variant replaces only the trackpad controller. */
> +&i2c2 {
> +	/delete-node/ trackpad at 15;
> +
> +	trackpad at 15 {
> +		compatible = "hid-over-i2c";
> +		reg = <0x15>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		hid-descr-addr = <0x0001>;
> +		vdd-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> new file mode 100644
> index 000000000000..adbeb0c765d3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> @@ -0,0 +1,1707 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (C) 2022 MediaTek Inc.
> + */
> +/dts-v1/;
> +#include "mt8186.dtsi"
> +#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/input/gpio-keys.h>
> +#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
> +

..snip..

> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	/*
> +	 * Trackpad pin put here to work around second source components
> +	 * sharing the pinmux in steelix designs.
> +	 */
> +	pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
> +	clock-frequency = <400000>;
> +	i2c-scl-internal-delay-ns = <10000>;
> +	status = "okay";
> +
> +	trackpad at 15 {
> +		compatible = "elan,ekth3000";

You forgot to change this one.

Remove compatible from this node and stop using /delete-node/ in device specific
devicetrees.

> +		reg = <0x15>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		vcc-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};


corsola.dtsi (here):

&i2c2 {
	pinctrl-names = "default";
	/*
	 * Trackpad pin put here to work around second source components
	 * sharing the pinmux in steelix designs.
	 */
	pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
	clock-frequency = <400000>;
	i2c-scl-internal-delay-ns = <10000>;
	status = "okay";

	trackpad_i2c2_15: trackpad at 15 {
		/*
		 * Those are common properties for i2c2 trackpad on Corsola boards.
		 * The compatible string is declared in device specific devicetrees
		 */
		reg = <0x15>;
		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
		vcc-supply = <&pp3300_s3>;
		wakeup-source;
		status = "disabled";
	};
};

corsola-some-device.dts:

&trackpad_i2c2_15 {
	compatible = "hid-over-i2c";
	hid-descr-addr = <0x0001>;
	status = "okay";
};

corsola-some-other-device.dts:

&trackpad_i2c2_15 {
	compatible = "elan,ekth3000";
	status = "okay";
};

....everything else looks good.

Cheers,
Angelo


From fusibrandon13 at gmail.com  Thu Dec 14 02:33:37 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 14 Dec 2023 11:33:37 +0100
Subject: [PATCH 0/5] cpufreq support for the D1
Message-ID: <20231214103342.30775-1-fusibrandon13@gmail.com>

This patch series adds support for cpufreq on the D1 SoC, and a new
Kconfig.riscv file to cater to cpufreq drivers that support RISC-V
SoCs.

The changes have been tested on a Lichee RV module.

Brandon Cheo Fusi (5):
  riscv: dts: allwinner: Update opp table to allow CPU frequency scaling
  cpufreq: sun50i: Add D1 support
  cpufreq: dt-platdev: Blocklist allwinner,sun20i-d1 SoC
  cpufreq: Add support for RISC-V CPU Frequency scaling drivers
  cpufreq: Make sun50i h6 cpufreq Kconfig option generic

 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 18 +++++++++++++++---
 drivers/cpufreq/Kconfig                       |  4 ++++
 drivers/cpufreq/Kconfig.arm                   |  4 ++--
 drivers/cpufreq/Kconfig.riscv                 | 16 ++++++++++++++++
 drivers/cpufreq/Makefile                      |  2 +-
 drivers/cpufreq/cpufreq-dt-platdev.c          |  1 +
 drivers/cpufreq/sun50i-cpufreq-nvmem.c        |  1 +
 7 files changed, 40 insertions(+), 6 deletions(-)
 create mode 100644 drivers/cpufreq/Kconfig.riscv

-- 
2.30.2



From angelogioacchino.delregno at collabora.com  Thu Dec 14 02:34:33 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 14 Dec 2023 11:34:33 +0100
Subject: [PATCH v4 7/9] arm64: dts: mediatek: Introduce MT8186 Steelix
In-Reply-To: <20231213150435.4134390-8-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org>
 <20231213150435.4134390-8-wenst@chromium.org>
Message-ID: <8d855e5e-4938-4d4f-a79f-bbf89e30f6ca@collabora.com>

Il 13/12/23 16:04, Chen-Yu Tsai ha scritto:
> The MT8186 Steelix, also known as the Lenovo 300e Yoga Chromebook Gen 4,
> is a convertible device based on a common design of the same name. The
> device comes in different variants. Of them, whether a world facing
> camera is integrated is the only differentiating factor between the
> two device trees added. The different SKU IDs describe this alone.
> 
> The other device difference is the touchpad component used. This is
> simply handled by having both possible components described in the
> device tree, and letting the implementation figure out which one is
> actually available. The system bootloader / firmware does not
> differentiate this in that they share the same SKU IDs.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>
> ---
> Changes since v2:
> - Picked up Conor's ack
> 
> Changes since v1:
> - Removed trackpad_pins reference (moved to i2c2 in corsola dtsi)
> - Fixed copyright year
> - Renamed touchpad to trackpad
> ---
>   arch/arm64/boot/dts/mediatek/Makefile         |   2 +
>   .../mt8186-corsola-steelix-sku131072.dts      |  18 ++
>   .../mt8186-corsola-steelix-sku131073.dts      |  18 ++
>   .../dts/mediatek/mt8186-corsola-steelix.dtsi  | 195 ++++++++++++++++++
>   4 files changed, 233 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
>   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
> 
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index 442af61b1305..7bd9471b89f9 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -43,6 +43,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131072.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131073.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
> new file mode 100644
> index 000000000000..eae17bca8585
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola-steelix.dtsi"
> +
> +/ {
> +	model = "Google Steelix board";
> +	compatible = "google,steelix-sku131072", "google,steelix",
> +		     "mediatek,mt8186";
> +	chassis-type = "convertible";
> +};
> +
> +&mt6366codec {
> +	mediatek,dmic-mode = <0>; /* two-wire */
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
> new file mode 100644
> index 000000000000..a55375b95d0d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola-steelix.dtsi"
> +
> +/ {
> +	model = "Google Steelix board";
> +	compatible = "google,steelix-sku131073", "google,steelix",
> +		     "mediatek,mt8186";
> +	chassis-type = "convertible";
> +};
> +
> +&mt6366codec {
> +	mediatek,dmic-mode = <1>; /* one-wire */
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
> new file mode 100644
> index 000000000000..47262bc499ad
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2022 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8186-corsola.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +
> +/{
> +	pp1000_edpbrdg: regulator-pp1000-edpbrdg {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp1000_edpbrdg";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&en_pp1000_edpbrdg>;
> +		enable-active-high;
> +		regulator-boot-on;
> +		gpio = <&pio 29 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&pp3300_z2>;
> +	};
> +
> +	pp1800_edpbrdg_dx: regulator-pp1800-edpbrdg-dx {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp1800_edpbrdg_dx";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&en_pp1800_edpbrdg>;
> +		enable-active-high;
> +		regulator-boot-on;
> +		gpio = <&pio 30 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&mt6366_vio18_reg>;
> +	};
> +
> +	pp3300_edp_dx: regulator-pp3300-edp-dx {
> +		compatible = "regulator-fixed";
> +		regulator-name = "pp3300_edp_dx";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&en_pp3300_edpbrdg>;
> +		enable-active-high;
> +		regulator-boot-on;
> +		gpio = <&pio 31 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&pp3300_z2>;
> +	};
> +};
> +
> +&dsi_out {
> +	remote-endpoint = <&anx7625_in>;
> +};
> +
> +&i2c0 {
> +	clock-frequency = <400000>;
> +
> +	anx_bridge: anx7625 at 58 {
> +		compatible = "analogix,anx7625";
> +		reg = <0x58>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&anx7625_pins>;
> +		enable-gpios = <&pio 96 GPIO_ACTIVE_HIGH>;
> +		reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>;
> +		vdd10-supply = <&pp1000_edpbrdg>;
> +		vdd18-supply = <&pp1800_edpbrdg_dx>;
> +		vdd33-supply = <&pp3300_edp_dx>;
> +		analogix,lane0-swing = /bits/ 8 <0x70 0x30>;
> +		analogix,lane1-swing = /bits/ 8 <0x70 0x30>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +
> +				anx7625_in: endpoint {
> +					remote-endpoint = <&dsi_out>;
> +					data-lanes = <0 1 2 3>;
> +				};
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +
> +				anx7625_out: endpoint {
> +					remote-endpoint = <&panel_in>;
> +				};
> +			};
> +		};
> +
> +		aux-bus {
> +			panel: panel {
> +				compatible = "edp-panel";
> +				power-supply = <&pp3300_disp_x>;
> +				backlight = <&backlight_lcd0>;
> +
> +				port {
> +					panel_in: endpoint {
> +						remote-endpoint = <&anx7625_out>;
> +					};
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&i2c1 {
> +	touchscreen: touchscreen at 5d {
> +		compatible = "goodix,gt7375p";
> +		reg = <0x5d>;
> +		interrupts-extended = <&pio 12 IRQ_TYPE_EDGE_FALLING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&touchscreen_pins>;
> +		reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>;
> +		vdd-supply = <&pp3300_s3>;
> +		goodix,no-reset-during-suspend;
> +	};
> +};
> +
> +&i2c2 {
> +	i2c-scl-internal-delay-ns = <22000>;
> +
> +	/* second source component */
> +	trackpad at 2c {
> +		compatible = "hid-over-i2c";
> +		reg = <0x2c>;
> +		hid-descr-addr = <0x20>;
> +		interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> +		vdd-supply = <&pp3300_s3>;
> +		wakeup-source;
> +	};
> +};
> +
> +&keyboard_controller {
> +	function-row-physmap = <
> +		MATRIX_KEY(0x00, 0x02, 0)	/* T1 */
> +		MATRIX_KEY(0x03, 0x02, 0)	/* T2 */
> +		MATRIX_KEY(0x02, 0x02, 0)	/* T3 */
> +		MATRIX_KEY(0x01, 0x02, 0)	/* T4 */
> +		MATRIX_KEY(0x03, 0x04, 0)	/* T5 */
> +		MATRIX_KEY(0x02, 0x04, 0)	/* T6 */
> +		MATRIX_KEY(0x01, 0x04, 0)	/* T7 */
> +		MATRIX_KEY(0x02, 0x09, 0)	/* T8 */
> +		MATRIX_KEY(0x01, 0x09, 0)	/* T9 */
> +		MATRIX_KEY(0x00, 0x04, 0)	/* T10 */
> +	>;
> +
> +	linux,keymap = <
> +		MATRIX_KEY(0x00, 0x02, KEY_BACK)
> +		MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> +		MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> +		MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> +		MATRIX_KEY(0x03, 0x04, KEY_BRIGHTNESSDOWN)
> +		MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSUP)
> +		MATRIX_KEY(0x01, 0x04, KEY_MICMUTE)
> +		MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> +		MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> +		MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> +		CROS_STD_MAIN_KEYMAP
> +	>;
> +};
> +
> +&pio {
> +	anx7625_pins: anx7625-pins {
> +		pins1 {

pins-en-rst

> +			pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
> +				 <PINMUX_GPIO98__FUNC_GPIO98>;
> +			output-low;
> +		};
> +
> +		pins2 {

pins-is-this-an-interrupt? :-)

> +			pinmux = <PINMUX_GPIO9__FUNC_GPIO9>;
> +			input-enable;
> +			bias-disable;
> +		};
> +	};
> +
> +	en_pp1000_edpbrdg: pp1000-edpbrdg-en-pins {
> +		pins {

pins-vreg-en like in corsola.dtsi

> +			pinmux = <PINMUX_GPIO29__FUNC_GPIO29>;
> +			output-low;
> +		};
> +	};
> +
> +	en_pp1800_edpbrdg: pp1800-edpbrdg-en-pins {
> +		pins {

same

> +			pinmux = <PINMUX_GPIO30__FUNC_GPIO30>;
> +			output-low;
> +		};
> +	};
> +
> +	en_pp3300_edpbrdg: pp3300-edpbrdg-en-pins {
> +		pins {

ditto

Cheers,
Angelo



From fusibrandon13 at gmail.com  Thu Dec 14 02:33:38 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 14 Dec 2023 11:33:38 +0100
Subject: [PATCH 1/5] riscv: dts: allwinner: Update opp table to allow CPU frequency scaling
In-Reply-To: <20231214103342.30775-1-fusibrandon13@gmail.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
Message-ID: <20231214103342.30775-2-fusibrandon13@gmail.com>

Two OPPs are currently defined for the D1/D1s; one at 408MHz and
another at 1.08GHz. Switching between these can be done with the
"sun50i-cpufreq-nvmem" driver. This patch populates the opp table
appropriately, with inspiration from
https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi

The supply voltages are PWM-controlled, but support for that IP
is still in the works. So stick to a fixed 0.9V vdd-cpu supply,
which seems to be the default on most D1 boards.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
index 64c3c2e6c..e211fe4c7 100644
--- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
+++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
@@ -39,16 +39,22 @@ cpu0_intc: interrupt-controller {
 	};
 
 	opp_table_cpu: opp-table-cpu {
-		compatible = "operating-points-v2";
+		compatible = "allwinner,sun20i-d1-operating-points",
+				 "allwinner,sun50i-h6-operating-points";
+		nvmem-cells = <&cpu_speed_grade>;
+		nvmem-cell-names = "speed";
+		opp-shared;
 
 		opp-408000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <900000 900000 1100000>;
+			opp-microvolt-speed0 = <900000>;
 		};
 
 		opp-1080000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
 			opp-hz = /bits/ 64 <1008000000>;
-			opp-microvolt = <900000 900000 1100000>;
+			opp-microvolt-speed0 = <900000>;
 		};
 	};
 
@@ -115,3 +121,8 @@ pmu {
 			<0x00000000 0x0000000f 0xffffffff 0xffffffff 0x00020000>;
 	};
 };
+
+&sid {
+	cpu_speed_grade: cpu-speed-grade at 0 {
+		reg = <0x00 0x2>;
+	};
+};
-- 
2.30.2



From fusibrandon13 at gmail.com  Thu Dec 14 02:33:39 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 14 Dec 2023 11:33:39 +0100
Subject: [PATCH 2/5] cpufreq: sun50i: Add D1 support
In-Reply-To: <20231214103342.30775-1-fusibrandon13@gmail.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
Message-ID: <20231214103342.30775-3-fusibrandon13@gmail.com>

Add support for D1 based devices to the Allwinner H6 cpufreq
driver

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/sun50i-cpufreq-nvmem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 32a9c88f8..ccf83780f 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -160,6 +160,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
 
 static const struct of_device_id sun50i_cpufreq_match_list[] = {
 	{ .compatible = "allwinner,sun50i-h6" },
+	{ .compatible = "allwinner,sun20i-d1" },
 	{}
 };
 MODULE_DEVICE_TABLE(of, sun50i_cpufreq_match_list);
-- 
2.30.2



From fusibrandon13 at gmail.com  Thu Dec 14 02:33:40 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 14 Dec 2023 11:33:40 +0100
Subject: [PATCH 3/5] cpufreq: dt-platdev: Blocklist allwinner,sun20i-d1 SoC
In-Reply-To: <20231214103342.30775-1-fusibrandon13@gmail.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
Message-ID: <20231214103342.30775-4-fusibrandon13@gmail.com>

The Allwinner D1 uses H6 cpufreq driver. Add it to blocklist
so the "cpufreq-dt" device is not created twice.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index bd1e1357c..2febcfc2c 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -104,6 +104,7 @@ static const struct of_device_id allowlist[] __initconst = {
  */
 static const struct of_device_id blocklist[] __initconst = {
 	{ .compatible = "allwinner,sun50i-h6", },
+	{ .compatible = "allwinner,sun20i-d1", },
 
 	{ .compatible = "apple,arm-platform", },
 
-- 
2.30.2



From fusibrandon13 at gmail.com  Thu Dec 14 02:33:41 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 14 Dec 2023 11:33:41 +0100
Subject: [PATCH 4/5] cpufreq: Add support for RISC-V CPU Frequency scaling drivers
In-Reply-To: <20231214103342.30775-1-fusibrandon13@gmail.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
Message-ID: <20231214103342.30775-5-fusibrandon13@gmail.com>

Add Kconfig file for cpufreq scaling drivers that can handle RISC-V
CPUs. An entry is included for the Allwinner H6 cpufreq driver that
works with D1.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/Kconfig       |  4 ++++
 drivers/cpufreq/Kconfig.riscv | 16 ++++++++++++++++
 2 files changed, 20 insertions(+)
 create mode 100644 drivers/cpufreq/Kconfig.riscv

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 35efb53d5..4bef39fed 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -239,6 +239,10 @@ if PPC32 || PPC64
 source "drivers/cpufreq/Kconfig.powerpc"
 endif
 
+if RISCV
+source "drivers/cpufreq/Kconfig.riscv"
+endif
+
 if MIPS
 config BMIPS_CPUFREQ
 	tristate "BMIPS CPUfreq Driver"
diff --git a/drivers/cpufreq/Kconfig.riscv b/drivers/cpufreq/Kconfig.riscv
new file mode 100644
index 000000000..025c7c439
--- /dev/null
+++ b/drivers/cpufreq/Kconfig.riscv
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# RISC-V CPU Frequency scaling drivers
+#
+
+config ALLWINNER_SUN50I_CPUFREQ_NVMEM
+	tristate "Allwinner nvmem based SUN50I CPUFreq driver"
+	depends on ARCH_SUNXI
+	depends on NVMEM_SUNXI_SID
+	select PM_OPP
+	help
+	  This adds the nvmem based CPUFreq driver for Allwinner
+	  H6/D1 SoCs.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called sun50i-cpufreq-nvmem.
\ No newline at end of file
-- 
2.30.2



From fusibrandon13 at gmail.com  Thu Dec 14 02:33:42 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 14 Dec 2023 11:33:42 +0100
Subject: [PATCH 5/5] cpufreq: Make sun50i h6 cpufreq Kconfig option generic
In-Reply-To: <20231214103342.30775-1-fusibrandon13@gmail.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
Message-ID: <20231214103342.30775-6-fusibrandon13@gmail.com>

Remove the 'ARM_' prefix from the Allwinner SUN50I cpufreq driver
Kconfig.arm option as that driver can support the D1, a RISC-V
chip.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/Kconfig.arm | 4 ++--
 drivers/cpufreq/Makefile    | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index f91160689..510604781 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -29,14 +29,14 @@ config ACPI_CPPC_CPUFREQ_FIE
 
 	  If in doubt, say N.
 
-config ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM
+config ALLWINNER_SUN50I_CPUFREQ_NVMEM
 	tristate "Allwinner nvmem based SUN50I CPUFreq driver"
 	depends on ARCH_SUNXI
 	depends on NVMEM_SUNXI_SID
 	select PM_OPP
 	help
 	  This adds the nvmem based CPUFreq driver for Allwinner
-	  h6 SoC.
+	  H6/D1 SoCs.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called sun50i-cpufreq-nvmem.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d141c71b..110b676d2 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -78,7 +78,7 @@ obj-$(CONFIG_ARM_SCMI_CPUFREQ)		+= scmi-cpufreq.o
 obj-$(CONFIG_ARM_SCPI_CPUFREQ)		+= scpi-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
 obj-$(CONFIG_ARM_STI_CPUFREQ)		+= sti-cpufreq.o
-obj-$(CONFIG_ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM) += sun50i-cpufreq-nvmem.o
+obj-$(CONFIG_ALLWINNER_SUN50I_CPUFREQ_NVMEM) += sun50i-cpufreq-nvmem.o
 obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)	+= tegra20-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)	+= tegra124-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA186_CPUFREQ)	+= tegra186-cpufreq.o
-- 
2.30.2



From fshao at chromium.org  Thu Dec 14 02:39:01 2023
From: fshao at chromium.org (Fei Shao)
Date: Thu, 14 Dec 2023 18:39:01 +0800
Subject: [PATCH v4 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <20231213150435.4134390-7-wenst@chromium.org>
References: <20231213150435.4134390-1-wenst@chromium.org> <20231213150435.4134390-7-wenst@chromium.org>
Message-ID: <CAC=S1niMvoD-EzGWqo-5fEBJLWAVk3FnxW3jq5rSj9fQ_H37gA@mail.gmail.com>

On Wed, Dec 13, 2023 at 11:05?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> Krabby design.
>
> Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> convertible device with touchscreen and stylus.
>
> Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> device. It does not have a touchscreen or stylus.
>
> The two devices both have two variants. The difference is a second
> source touchpad controller that shares the same address as the original,
One nit since you need to resend this anyway...
s/touchpad/trackpad/g

Regards,
Fei

> but is incompatible.
>
> The extra SKU IDs for the Tentacruel devices map to different sensor
> components attached to the Embedded Controller. These are not visible
> to the main processor.
>
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> Acked-by: Conor Dooley <conor.dooley at microchip.com>


From lukasz.luba at arm.com  Thu Dec 14 02:41:05 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Thu, 14 Dec 2023 10:41:05 +0000
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the
 scheduler
In-Reply-To: <CAJZ5v0gD-utGhM3vN7JmPia1CVcSQa6RPnk2xMBXXc6asRTn=g@mail.gmail.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org>
 <20231214054307.axl33gagxacidjbn@vireshk-i7>
 <CAKfTPtDam5eQO1DHxALsCaU53Rtawbfrvswy+z2unnV_eXeVLA@mail.gmail.com>
 <54f3b98c-1f7d-4205-9e3c-a4a19ad3d941@arm.com>
 <CAJZ5v0gD-utGhM3vN7JmPia1CVcSQa6RPnk2xMBXXc6asRTn=g@mail.gmail.com>
Message-ID: <fe8f8d00-1720-4a47-83ae-1aa4c005c4f5@arm.com>



On 12/14/23 09:40, Rafael J. Wysocki wrote:
> On Thu, Dec 14, 2023 at 10:07?AM Lukasz Luba <lukasz.luba at arm.com> wrote:
>>
>> On 12/14/23 07:57, Vincent Guittot wrote:
>>> On Thu, 14 Dec 2023 at 06:43, Viresh Kumar <viresh.kumar at linaro.org> wrote:
>>>>
>>>> On 12-12-23, 15:27, Vincent Guittot wrote:
>>>>> @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
>>>>>         policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
>>>>>         trace_cpu_frequency_limits(policy);
>>>>>
>>>>> +     cpus = policy->related_cpus;
>>>>> +     cpufreq_update_pressure(cpus, policy->max);
>>>>> +
>>>>>         policy->cached_target_freq = UINT_MAX;
>>>>
>>>> One more question, why are you doing this from cpufreq_set_policy ? If
>>>> due to cpufreq cooling or from userspace, we end up limiting the
>>>> maximum possible frequency, will this routine always get called ?
>>>
>>> Yes, any update of a FREQ_QOS_MAX ends up calling cpufreq_set_policy()
>>> to update the policy->max
>>>
>>
>> Agree, cpufreq sysfs scaling_max_freq is also important to handle
>> in this new design. Currently we don't reflect that as reduced CPU
>> capacity in the scheduler. There was discussion when I proposed to feed
>> that CPU frequency reduction into thermal_pressure [1].
>>
>> The same applies for the DTPM which is missing currently the proper
>> impact to the CPU reduced capacity in the scheduler.
>>
>> IMHO any limit set into FREQ_QOS_MAX should be visible in this
>> new design of capacity reduction signaling.
>>
>> [1] https://lore.kernel.org/lkml/20220930094821.31665-2-lukasz.luba at arm.com/
> 
> Actually, freq_qos_read_value(&policy->constraints, FREQ_QOS_MAX) will
> return the requisite limit.

Yes, but we need to translate that information from freq domain
into capacity domain and plumb ii into scheduler as stolen CPU capacity.
Ideally, w/o any 'smoothing' but just instant value.
That's the hope of this patch set re-design.


From broonie at kernel.org  Thu Dec 14 02:42:06 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 14 Dec 2023 10:42:06 +0000
Subject: [PATCH v3 01/17] arm64/sysreg: Add missing Pauth_LR field
 definitions to ID_AA64ISAR1_EL1
In-Reply-To: <20231214100158.2305400-2-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
 <20231214100158.2305400-2-tabba@google.com>
Message-ID: <719d323f-787d-40c3-8fbf-6496411ca6fd@sirena.org.uk>

On Thu, Dec 14, 2023 at 10:01:41AM +0000, Fuad Tabba wrote:
> Add the Pauth_LR field definitions to ID_AA64ISAR1_EL1, based on
> DDI0601 2023-09.
> 
> These fields aren't used yet. Adding them for completeness and
> consistency (definition already exists for ID_AA64ISAR2_EL1).

This is fine in so far as it goes, though it does make life slightly
easier to do the whole register at once.  There's also a new 0b0010
value in SPECRES here, though not worth making it a blocker:

Reviewed-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/d66718b6/attachment.sig>

From will at kernel.org  Thu Dec 14 02:43:28 2023
From: will at kernel.org (Will Deacon)
Date: Thu, 14 Dec 2023 10:43:28 +0000
Subject: [GIT PULL] iommu/arm-smmu: Updates for 6.8
Message-ID: <20231214104327.GA924@willie-the-truck>

Hi Joerg,

Please pull these Arm SMMU updates for 6.8 ahead of the Christmas break.
I'll be disappearing shortly, but I'll keep half an eye on the list in
case any issues crop up.

There's the usual summary of changes in the tag.

Cheers,

Will

--->8

The following changes since commit 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab:

  Linux 6.7-rc3 (2023-11-26 19:59:33 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git tags/arm-smmu-updates

for you to fetch changes up to 1343121f08e6df62b14e6c0a8c193256ac225b0c:

  Merge branch 'for-joerg/arm-smmu/bindings' into for-joerg/arm-smmu/updates (2023-12-13 15:53:02 +0000)

----------------------------------------------------------------
Arm SMMU updates for 6.8

- Device-tree binding updates:
  * Add additional compatible strings for Qualcomm SoCs
  * Document Adreno clocks for Qualcomm's SM8350 SoC

- SMMUv2:
  * Implement support for the ->domain_alloc_paging() callback
  * Ensure Secure context is restored following suspend of Qualcomm SMMU
    implementation

- SMMUv3:
  * Disable stalling mode for the "quiet" context descriptor
  * Minor refactoring and driver cleanups

----------------------------------------------------------------
Jason Gunthorpe (8):
      iommu/arm-smmu-v3: Add a type for the STE
      iommu/arm-smmu-v3: Master cannot be NULL in arm_smmu_write_strtab_ent()
      iommu/arm-smmu-v3: Remove ARM_SMMU_DOMAIN_NESTED
      iommu/arm-smmu: Reorganize arm_smmu_domain_add_master()
      iommu/arm-smmu: Convert to a global static identity domain
      iommu/arm-smmu: Implement IOMMU_DOMAIN_BLOCKED
      iommu/arm-smmu: Pass arm_smmu_domain to internal functions
      iommu/arm-smmu: Convert to domain_alloc_paging()

Konrad Dybcio (2):
      dt-bindings: arm-smmu: Document SM8[45]50 GPU SMMU
      iommu/arm-smmu-qcom: Add QCM2290 MDSS compatible

Krzysztof Kozlowski (1):
      dt-bindings: iommu: arm,smmu: document clocks for the SM8350 GPU SMMU

Neil Armstrong (1):
      dt-bindings: iommu: arm,smmu: document the SM8650 System MMU

Rajendra Nayak (1):
      dt-bindings: arm-smmu: Add compatible for X1E80100 SoC

Rob Clark (1):
      iommu/arm-smmu-qcom: Add missing GMU entry to match table

Vladimir Lypak (1):
      iommu/qcom: restore IOMMU state if needed

Wenkai Lin (1):
      iommu/arm-smmu-v3: disable stall for quiet_cd

Will Deacon (1):
      Merge branch 'for-joerg/arm-smmu/bindings' into for-joerg/arm-smmu/updates

 .../devicetree/bindings/iommu/arm,smmu.yaml        |  77 ++++++++++-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c        |  75 +++++-----
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h        |   8 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c         |   2 +
 drivers/iommu/arm/arm-smmu/arm-smmu.c              | 153 ++++++++++++++-------
 drivers/iommu/arm/arm-smmu/arm-smmu.h              |   1 -
 drivers/iommu/arm/arm-smmu/qcom_iommu.c            |  10 +-
 7 files changed, 226 insertions(+), 100 deletions(-)


From angelogioacchino.delregno at collabora.com  Thu Dec 14 02:44:26 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 14 Dec 2023 11:44:26 +0100
Subject: [PATCH 4/4] arm64: dts: mediatek: mt8186: Add venc node
In-Reply-To: <20231213122017.102100-4-eugen.hristev@collabora.com>
References: <20231213122017.102100-1-eugen.hristev@collabora.com>
 <20231213122017.102100-4-eugen.hristev@collabora.com>
Message-ID: <d20c35e2-cc40-436d-90ca-4cab555874ca@collabora.com>

Il 13/12/23 13:20, Eugen Hristev ha scritto:
> From: Kyrie Wu <kyrie.wu at mediatek.com>
> 
> Add video encoder node.
> 
> Signed-off-by: Kyrie Wu <kyrie.wu at mediatek.com>
> Signed-off-by: Allen-KH Cheng <allen-kh.cheng at mediatek.com>
> Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.org>
> [eugen.hristev at collabora.com: minor cleanup]
> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
> ---
>   arch/arm64/boot/dts/mediatek/mt8186.dtsi | 24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> index 66ead3f23336..8535ff2b44e9 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> @@ -1993,6 +1993,30 @@ larb7: smi at 17010000 {
>   			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
>   		};
>   
> +		venc: venc at 17020000 {
> +			compatible = "mediatek,mt8183-vcodec-enc";
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			reg = <0 0x17020000 0 0x2000>;
> +			interrupts = <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH 0>;
> +			iommus = <&iommu_mm IOMMU_PORT_L7_VENC_RCPU>,
> +				 <&iommu_mm IOMMU_PORT_L7_VENC_REC>,
> +				 <&iommu_mm IOMMU_PORT_L7_VENC_BSDMA>,
> +				 <&iommu_mm IOMMU_PORT_L7_VENC_SV_COMV>,
> +				 <&iommu_mm IOMMU_PORT_L7_VENC_RD_COMV>,
> +				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_LUMA>,
> +				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_CHROMA>,
> +				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_LUMA>,
> +				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_CHROMA>;
> +			dma-ranges = <0x1 0x0 0x1 0x0 0x1 0x0>;
> +			mediatek,scp = <&scp>;
> +			clocks = <&vencsys CLK_VENC_CKE1_VENC>;
> +			clock-names = "MT_CG_VENC";

clock-names = "venc"; (please no underscores and please lower case)

> +			assigned-clocks = <&topckgen CLK_TOP_VENC>;
> +			assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D3>;
> +			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
> +		};


....also:

The following order of properties in device nodes is preferred:

1. "compatible"
2. "reg"
3. "ranges"
4. Standard/common properties (defined by common bindings, e.g. without
    vendor-prefixes)
5. Vendor-specific properties
6. "status" (if applicable)
7. Child nodes, where each node is preceded with a blank line

Documentation/devicetree/bindings/dts-coding-style.rst

Please reorder as per the DTS coding style document, and also please rename the
venc node to use a generic name, such as "video-encoder at xxxx"

Cheers,
Angelo


From angelogioacchino.delregno at collabora.com  Thu Dec 14 02:45:01 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 14 Dec 2023 11:45:01 +0100
Subject: [PATCH 2/4] media: mediatek: vcodec: fix possible unbalanced PM
 counter
In-Reply-To: <20231213122017.102100-2-eugen.hristev@collabora.com>
References: <20231213122017.102100-1-eugen.hristev@collabora.com>
 <20231213122017.102100-2-eugen.hristev@collabora.com>
Message-ID: <23255060-5a75-4cbe-9fde-f185fa958a6a@collabora.com>

Il 13/12/23 13:20, Eugen Hristev ha scritto:
> It is possible that mtk_vcodec_enc_pw_on fails, and in that scenario
> the PM counter is not incremented, and subsequent call to
> mtk_vcodec_enc_pw_off decrements the counter, leading to a PM imbalance.
> Fix by bailing out of venc_if_encode in the case when mtk_vcodec_enc_pw_on
> fails.
> 
> Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno?collabora.com>




From broonie at kernel.org  Thu Dec 14 02:46:20 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 14 Dec 2023 10:46:20 +0000
Subject: [PATCH v3 02/17] arm64/sysreg: Add missing ExtTrcBuff field
 definition to ID_AA64DFR0_EL1
In-Reply-To: <20231214100158.2305400-3-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
 <20231214100158.2305400-3-tabba@google.com>
Message-ID: <bc735ea0-80ae-4c50-8cdb-98db1abd61d3@sirena.org.uk>

On Thu, Dec 14, 2023 at 10:01:42AM +0000, Fuad Tabba wrote:
> Add the ExtTrcBuff field definitions to ID_AA64DFR0_EL1 from
> DDI0601 2023-09.
> 
> This field isn't used yet. Adding it for completeness and because
> it will be used in future patches.

There's also updates for PMSVer, PMUVer and DebugVer, and the addition
of SEBEP and PSSS.  The changes here are fine though

Reviewed-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/34d26688/attachment-0001.sig>

From broonie at kernel.org  Thu Dec 14 02:49:26 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 14 Dec 2023 10:49:26 +0000
Subject: [PATCH v3 01/17] arm64/sysreg: Add missing Pauth_LR field
 definitions to ID_AA64ISAR1_EL1
In-Reply-To: <719d323f-787d-40c3-8fbf-6496411ca6fd@sirena.org.uk>
References: <20231214100158.2305400-1-tabba@google.com>
 <20231214100158.2305400-2-tabba@google.com>
 <719d323f-787d-40c3-8fbf-6496411ca6fd@sirena.org.uk>
Message-ID: <6e14b02c-93a7-482a-9377-3afaa57c2dd0@sirena.org.uk>

On Thu, Dec 14, 2023 at 10:42:12AM +0000, Mark Brown wrote:

> This is fine in so far as it goes, though it does make life slightly
> easier to do the whole register at once.  There's also a new 0b0010
> value in SPECRES here, though not worth making it a blocker:

Sorry, was looking at a draft version there - this is fine as per the
current docs (as is patch 2).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/03467490/attachment.sig>

From patchwork-bot+netdevbpf at kernel.org  Thu Dec 14 02:50:26 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Thu, 14 Dec 2023 10:50:26 +0000
Subject: [PATCH net v4] net: stmmac: dwmac-qcom-ethqos: Fix drops in 10M SGMII
 RX
In-Reply-To: <20231212092208.22393-1-quic_snehshah@quicinc.com>
References: <20231212092208.22393-1-quic_snehshah@quicinc.com>
Message-ID: <170255102695.29358.13778143091773009121.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni at redhat.com>:

On Tue, 12 Dec 2023 14:52:08 +0530 you wrote:
> In 10M SGMII mode all the packets are being dropped due to wrong Rx clock.
> SGMII 10MBPS mode needs RX clock divider programmed to avoid drops in Rx.
> Update configure SGMII function with Rx clk divider programming.
> 
> Fixes: 463120c31c58 ("net: stmmac: dwmac-qcom-ethqos: add support for SGMII")
> Tested-by: Andrew Halaney <ahalaney at redhat.com>
> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> 
> [...]

Here is the summary with links:
  - [net,v4] net: stmmac: dwmac-qcom-ethqos: Fix drops in 10M SGMII RX
    https://git.kernel.org/netdev/net/c/981d947bcd38

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From broonie at kernel.org  Thu Dec 14 02:50:25 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 14 Dec 2023 10:50:25 +0000
Subject: [PATCH v3 03/17] arm64/sysreg: Add missing system register
 definitions for FGT
In-Reply-To: <20231214100158.2305400-4-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
 <20231214100158.2305400-4-tabba@google.com>
Message-ID: <c9a947e9-7bf0-484d-970d-4094d19ed5d5@sirena.org.uk>

On Thu, Dec 14, 2023 at 10:01:43AM +0000, Fuad Tabba wrote:
> Add the definitions of missing system registers that are
> trappable by fine grain traps. The definitions are based on
> DDI0601 2023-09.

Reviewed-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/b99f8358/attachment.sig>

From angelogioacchino.delregno at collabora.com  Thu Dec 14 02:50:46 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 14 Dec 2023 11:50:46 +0100
Subject: [PATCH 4/4] arm64: dts: mediatek: mt8186: Add venc node
In-Reply-To: <d20c35e2-cc40-436d-90ca-4cab555874ca@collabora.com>
References: <20231213122017.102100-1-eugen.hristev@collabora.com>
 <20231213122017.102100-4-eugen.hristev@collabora.com>
 <d20c35e2-cc40-436d-90ca-4cab555874ca@collabora.com>
Message-ID: <ff4f8365-d329-422c-ae04-d39a26f27552@collabora.com>

Il 14/12/23 11:44, AngeloGioacchino Del Regno ha scritto:
> Il 13/12/23 13:20, Eugen Hristev ha scritto:
>> From: Kyrie Wu <kyrie.wu at mediatek.com>
>>
>> Add video encoder node.
>>
>> Signed-off-by: Kyrie Wu <kyrie.wu at mediatek.com>
>> Signed-off-by: Allen-KH Cheng <allen-kh.cheng at mediatek.com>
>> Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.org>
>> [eugen.hristev at collabora.com: minor cleanup]
>> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
>> ---
>> ? arch/arm64/boot/dts/mediatek/mt8186.dtsi | 24 ++++++++++++++++++++++++
>> ? 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi 
>> b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
>> index 66ead3f23336..8535ff2b44e9 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
>> @@ -1993,6 +1993,30 @@ larb7: smi at 17010000 {
>> ????????????? power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
>> ????????? };
>> +??????? venc: venc at 17020000 {
>> +??????????? compatible = "mediatek,mt8183-vcodec-enc";

Sorry for the double email;

I've just noticed: where's mediatek,mt8186-vcodec-enc? :-)

>> +??????????? #address-cells = <2>;
>> +??????????? #size-cells = <2>;
>> +??????????? reg = <0 0x17020000 0 0x2000>;
>> +??????????? interrupts = <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH 0>;
>> +??????????? iommus = <&iommu_mm IOMMU_PORT_L7_VENC_RCPU>,
>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_REC>,
>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_BSDMA>,
>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_SV_COMV>,
>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_RD_COMV>,
>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_CUR_LUMA>,
>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_CUR_CHROMA>,
>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_REF_LUMA>,
>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_REF_CHROMA>;
>> +??????????? dma-ranges = <0x1 0x0 0x1 0x0 0x1 0x0>;
>> +??????????? mediatek,scp = <&scp>;
>> +??????????? clocks = <&vencsys CLK_VENC_CKE1_VENC>;
>> +??????????? clock-names = "MT_CG_VENC";
> 
> clock-names = "venc"; (please no underscores and please lower case)
> 
>> +??????????? assigned-clocks = <&topckgen CLK_TOP_VENC>;
>> +??????????? assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D3>;
>> +??????????? power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
>> +??????? };
> 
> 
> ....also:
> 
> The following order of properties in device nodes is preferred:
> 
> 1. "compatible"
> 2. "reg"
> 3. "ranges"
> 4. Standard/common properties (defined by common bindings, e.g. without
>  ?? vendor-prefixes)
> 5. Vendor-specific properties
> 6. "status" (if applicable)
> 7. Child nodes, where each node is preceded with a blank line
> 
> Documentation/devicetree/bindings/dts-coding-style.rst
> 
> Please reorder as per the DTS coding style document, and also please rename the
> venc node to use a generic name, such as "video-encoder at xxxx"
> 
> Cheers,
> Angelo




From eugen.hristev at collabora.com  Thu Dec 14 02:52:46 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Thu, 14 Dec 2023 12:52:46 +0200
Subject: [PATCH 4/4] arm64: dts: mediatek: mt8186: Add venc node
In-Reply-To: <ff4f8365-d329-422c-ae04-d39a26f27552@collabora.com>
References: <20231213122017.102100-1-eugen.hristev@collabora.com>
 <20231213122017.102100-4-eugen.hristev@collabora.com>
 <d20c35e2-cc40-436d-90ca-4cab555874ca@collabora.com>
 <ff4f8365-d329-422c-ae04-d39a26f27552@collabora.com>
Message-ID: <952a01c3-1ca0-42f8-bdbe-ab8857e27dc4@collabora.com>

On 12/14/23 12:50, AngeloGioacchino Del Regno wrote:
> Il 14/12/23 11:44, AngeloGioacchino Del Regno ha scritto:
>> Il 13/12/23 13:20, Eugen Hristev ha scritto:
>>> From: Kyrie Wu <kyrie.wu at mediatek.com>
>>>
>>> Add video encoder node.
>>>
>>> Signed-off-by: Kyrie Wu <kyrie.wu at mediatek.com>
>>> Signed-off-by: Allen-KH Cheng <allen-kh.cheng at mediatek.com>
>>> Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.org>
>>> [eugen.hristev at collabora.com: minor cleanup]
>>> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
>>> ---
>>> ? arch/arm64/boot/dts/mediatek/mt8186.dtsi | 24 ++++++++++++++++++++++++
>>> ? 1 file changed, 24 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi 
>>> b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
>>> index 66ead3f23336..8535ff2b44e9 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
>>> @@ -1993,6 +1993,30 @@ larb7: smi at 17010000 {
>>> ????????????? power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
>>> ????????? };
>>> +??????? venc: venc at 17020000 {
>>> +??????????? compatible = "mediatek,mt8183-vcodec-enc";
> 
> Sorry for the double email;
> 
> I've just noticed: where's mediatek,mt8186-vcodec-enc? :-)

Hi,

There is none.
This just works exactly as mt8183, thus reusing the same compatible.

Do you want a new dedicated mt8186 compatible as well for the situation *just in
case* some specific difference showing up later ?

Eugen

> 
>>> +??????????? #address-cells = <2>;
>>> +??????????? #size-cells = <2>;
>>> +??????????? reg = <0 0x17020000 0 0x2000>;
>>> +??????????? interrupts = <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH 0>;
>>> +??????????? iommus = <&iommu_mm IOMMU_PORT_L7_VENC_RCPU>,
>>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_REC>,
>>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_BSDMA>,
>>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_SV_COMV>,
>>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_RD_COMV>,
>>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_CUR_LUMA>,
>>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_CUR_CHROMA>,
>>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_REF_LUMA>,
>>> +???????????????? <&iommu_mm IOMMU_PORT_L7_VENC_REF_CHROMA>;
>>> +??????????? dma-ranges = <0x1 0x0 0x1 0x0 0x1 0x0>;
>>> +??????????? mediatek,scp = <&scp>;
>>> +??????????? clocks = <&vencsys CLK_VENC_CKE1_VENC>;
>>> +??????????? clock-names = "MT_CG_VENC";
>>
>> clock-names = "venc"; (please no underscores and please lower case)
>>
>>> +??????????? assigned-clocks = <&topckgen CLK_TOP_VENC>;
>>> +??????????? assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D3>;
>>> +??????????? power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
>>> +??????? };
>>
>>
>> ....also:
>>
>> The following order of properties in device nodes is preferred:
>>
>> 1. "compatible"
>> 2. "reg"
>> 3. "ranges"
>> 4. Standard/common properties (defined by common bindings, e.g. without
>>  ?? vendor-prefixes)
>> 5. Vendor-specific properties
>> 6. "status" (if applicable)
>> 7. Child nodes, where each node is preceded with a blank line
>>
>> Documentation/devicetree/bindings/dts-coding-style.rst
>>
>> Please reorder as per the DTS coding style document, and also please rename the
>> venc node to use a generic name, such as "video-encoder at xxxx"
>>
>> Cheers,
>> Angelo
> 
> 
> _______________________________________________
> Kernel mailing list -- kernel at mailman.collabora.com
> To unsubscribe send an email to kernel-leave at mailman.collabora.com



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:30 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:30 +0000
Subject: [PATCH 00/13] GS101 Oriole: CMU_PERIC0 support and USI updates
Message-ID: <20231214105243.3707730-1-tudor.ambarus@linaro.org>

Add support for PERIC0 clocks. Use them for USI in serial and I2C
configurations. Tested the serial at different baudrates (115200,
1M, 3M) and the I2C with an at24 eeprom, all went fine.

Apart of the DT and defconfig changes, the patch set spans through the tty
and clk subsystems. The expectation is that Krzysztof will apply the whole
series through the Samsung SoC tree. If the tty and clk subsystem
maintainers can give an acked-by or reviewed-by on the relevant patches
that would be most appreciated!

Thanks!
ta

Tudor Ambarus (13):
  dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
  dt-bindings: clock: google,gs101-clock: add PERIC0 clock management
    unit
  dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
  dt-bindings: serial: samsung: gs101: make reg-io-width required
    property
  tty: serial: samsung: add gs101 earlycon support
  clk: samsung: gs101: add support for cmu_peric0
  clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
  arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
  arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
  arm64: dts: exynos: gs101: define USI8 with I2C configuration
  arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
  arm64: defconfig: sync with savedefconfig
  arm64: defconfig: make at24 eeprom builtin

 .../bindings/clock/google,gs101-clock.yaml    |  25 +-
 .../devicetree/bindings/i2c/i2c-exynos5.yaml  |   1 +
 .../bindings/serial/samsung_uart.yaml         |   4 +
 .../boot/dts/exynos/google/gs101-oriole.dts   |  18 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  52 +-
 arch/arm64/configs/defconfig                  | 146 ++--
 drivers/clk/samsung/clk-gs101.c               | 748 ++++++++++++++++--
 drivers/tty/serial/samsung_tty.c              |  11 +
 include/dt-bindings/clock/google,gs101.h      | 230 ++++--
 9 files changed, 980 insertions(+), 255 deletions(-)

-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:31 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:31 +0000
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-2-tudor.ambarus@linaro.org>

The gs101 clock names are derived from the clock register names under
some certain rules. In particular, for the gate clocks the following is
documented and expected in the gs101 clock driver:

  Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
  Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu

  For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC

The CMU TOP gate clock names missed to include the required "CMU"
differentiator which will cause name collisions with the gate clock names
of other clock units. Fix the TOP gate clock names and include "CMU" in
their name.

Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 drivers/clk/samsung/clk-gs101.c          | 167 ++++++++++++-----------
 include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
 2 files changed, 159 insertions(+), 152 deletions(-)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index a3dda97f5eb9..0964bb11657f 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -17,7 +17,7 @@
 #include "clk-exynos-arm64.h"
 
 /* NOTE: Must be equal to the last clock ID increased by one */
-#define CLKS_NR_TOP	(CLK_GOUT_TPU_UART + 1)
+#define CLKS_NR_TOP	(CLK_GOUT_CMU_TPU_UART + 1)
 #define CLKS_NR_APM	(CLK_APM_PLL_DIV16_APM + 1)
 #define CLKS_NR_MISC	(CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
 
@@ -1259,160 +1259,167 @@ static const struct samsung_fixed_factor_clock cmu_top_ffactor[] __initconst = {
 };
 
 static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
-	GATE(CLK_GOUT_BUS0_BOOST, "gout_cmu_bus0_boost",
+	GATE(CLK_GOUT_CMU_BUS0_BOOST, "gout_cmu_bus0_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS0_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_BUS1_BOOST, "gout_cmu_bus1_boost",
+	GATE(CLK_GOUT_CMU_BUS1_BOOST, "gout_cmu_bus1_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS1_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_BUS2_BOOST, "gout_cmu_bus2_boost",
+	GATE(CLK_GOUT_CMU_BUS2_BOOST, "gout_cmu_bus2_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS2_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_CORE_BOOST, "gout_cmu_core_boost",
+	GATE(CLK_GOUT_CMU_CORE_BOOST, "gout_cmu_core_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CORE_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_CPUCL0_BOOST, "gout_cmu_cpucl0_boost",
+	GATE(CLK_GOUT_CMU_CPUCL0_BOOST, "gout_cmu_cpucl0_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL0_BOOST,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CPUCL1_BOOST, "gout_cmu_cpucl1_boost",
+	GATE(CLK_GOUT_CMU_CPUCL1_BOOST, "gout_cmu_cpucl1_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL1_BOOST,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CPUCL2_BOOST, "gout_cmu_cpucl2_boost",
+	GATE(CLK_GOUT_CMU_CPUCL2_BOOST, "gout_cmu_cpucl2_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL2_BOOST,
 	     21, 0, 0),
-	GATE(CLK_GOUT_MIF_BOOST, "gout_cmu_mif_boost",
+	GATE(CLK_GOUT_CMU_MIF_BOOST, "gout_cmu_mif_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_MIF_BOOST,
 	     21, 0, 0),
-	GATE(CLK_GOUT_MIF_SWITCH, "gout_cmu_mif_switch", "mout_cmu_mif_switch",
-	     CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
-	GATE(CLK_GOUT_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
+	GATE(CLK_GOUT_CMU_MIF_SWITCH, "gout_cmu_mif_switch",
+	     "mout_cmu_mif_switch", CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
+	GATE(CLK_GOUT_CMU_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_BO_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
+	GATE(CLK_GOUT_CMU_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
+	GATE(CLK_GOUT_CMU_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
+	GATE(CLK_GOUT_CMU_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK0, "gout_cmu_cis_clk0", "mout_cmu_cis_clk0",
+	GATE(CLK_GOUT_CMU_CIS_CLK0, "gout_cmu_cis_clk0", "mout_cmu_cis_clk0",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK0, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK1, "gout_cmu_cis_clk1", "mout_cmu_cis_clk1",
+	GATE(CLK_GOUT_CMU_CIS_CLK1, "gout_cmu_cis_clk1", "mout_cmu_cis_clk1",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK1, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK2, "gout_cmu_cis_clk2", "mout_cmu_cis_clk2",
+	GATE(CLK_GOUT_CMU_CIS_CLK2, "gout_cmu_cis_clk2", "mout_cmu_cis_clk2",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK2, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK3, "gout_cmu_cis_clk3", "mout_cmu_cis_clk3",
+	GATE(CLK_GOUT_CMU_CIS_CLK3, "gout_cmu_cis_clk3", "mout_cmu_cis_clk3",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK3, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK4, "gout_cmu_cis_clk4", "mout_cmu_cis_clk4",
+	GATE(CLK_GOUT_CMU_CIS_CLK4, "gout_cmu_cis_clk4", "mout_cmu_cis_clk4",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK4, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK5, "gout_cmu_cis_clk5", "mout_cmu_cis_clk5",
+	GATE(CLK_GOUT_CMU_CIS_CLK5, "gout_cmu_cis_clk5", "mout_cmu_cis_clk5",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK5, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK6, "gout_cmu_cis_clk6", "mout_cmu_cis_clk6",
+	GATE(CLK_GOUT_CMU_CIS_CLK6, "gout_cmu_cis_clk6", "mout_cmu_cis_clk6",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK6, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK7, "gout_cmu_cis_clk7", "mout_cmu_cis_clk7",
+	GATE(CLK_GOUT_CMU_CIS_CLK7, "gout_cmu_cis_clk7", "mout_cmu_cis_clk7",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK7, 21, 0, 0),
-	GATE(CLK_GOUT_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_cmu_boost",
+	GATE(CLK_GOUT_CMU_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_cmu_boost",
 	     CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
+	GATE(CLK_GOUT_CMU_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_CORE_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_CPUCL0_DBG, "gout_cmu_cpucl0_dbg", "mout_cmu_cpucl0_dbg",
-	     CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch",
+	GATE(CLK_GOUT_CMU_CPUCL0_DBG, "gout_cmu_cpucl0_dbg",
+	     "mout_cmu_cpucl0_dbg", CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch",
 	     "mout_cmu_cpucl0_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch",
+	GATE(CLK_GOUT_CMU_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch",
 	     "mout_cmu_cpucl1_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch",
+	GATE(CLK_GOUT_CMU_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch",
 	     "mout_cmu_cpucl2_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CSIS_BUS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
+	GATE(CLK_GOUT_CMU_CSIS_BUS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
+	GATE(CLK_GOUT_CMU_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_DISP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
+	GATE(CLK_GOUT_CMU_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_DNS_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
+	GATE(CLK_GOUT_CMU_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_DPU_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
+	GATE(CLK_GOUT_CMU_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_EH_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
+	GATE(CLK_GOUT_CMU_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
 	     CLK_CON_GAT_GATE_CLKCMU_G2D_G2D, 21, 0, 0),
-	GATE(CLK_GOUT_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
+	GATE(CLK_GOUT_CMU_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
 	     CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL, 21, 0, 0),
-	GATE(CLK_GOUT_G3AA_G3AA, "gout_cmu_g3aa_g3aa", "mout_cmu_g3aa_g3aa",
+	GATE(CLK_GOUT_CMU_G3AA_G3AA, "gout_cmu_g3aa_g3aa", "mout_cmu_g3aa_g3aa",
 	     CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 21, 0, 0),
-	GATE(CLK_GOUT_G3D_BUSD, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
+	GATE(CLK_GOUT_CMU_G3D_BUSD, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
 	     CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD, 21, 0, 0),
-	GATE(CLK_GOUT_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
+	GATE(CLK_GOUT_CMU_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
 	     CLK_CON_GAT_GATE_CLKCMU_G3D_GLB, 21, 0, 0),
-	GATE(CLK_GOUT_G3D_SWITCH, "gout_cmu_g3d_switch", "mout_cmu_g3d_switch",
-	     CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH, 21, 0, 0),
-	GATE(CLK_GOUT_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
+	GATE(CLK_GOUT_CMU_G3D_SWITCH, "gout_cmu_g3d_switch",
+	     "mout_cmu_g3d_switch", CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
 	     CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0, 21, 0, 0),
-	GATE(CLK_GOUT_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
+	GATE(CLK_GOUT_CMU_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
 	     CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1, 21, 0, 0),
-	GATE(CLK_GOUT_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
+	GATE(CLK_GOUT_CMU_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
 	     CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC, 21, 0, 0),
 	GATE(CLK_GOUT_CMU_HPM, "gout_cmu_hpm", "mout_cmu_hpm",
 	     CLK_CON_GAT_GATE_CLKCMU_HPM, 21, 0, 0),
-	GATE(CLK_GOUT_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
+	GATE(CLK_GOUT_CMU_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc", "mout_cmu_hsi0_dpgtc",
-	     CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC, 21, 0, 0),
-	GATE(CLK_GOUT_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd",
+	GATE(CLK_GOUT_CMU_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc",
+	     "mout_cmu_hsi0_dpgtc", CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd",
 	     "mout_cmu_hsi0_usb31drd", CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD,
 	     21, 0, 0),
-	GATE(CLK_GOUT_HSI0_USBDPDBG, "gout_cmu_hsi0_usbdpdbg",
+	GATE(CLK_GOUT_CMU_HSI0_USBDPDBG, "gout_cmu_hsi0_usbdpdbg",
 	     "mout_cmu_hsi0_usbdpdbg", CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG,
 	     21, 0, 0),
-	GATE(CLK_GOUT_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
+	GATE(CLK_GOUT_CMU_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
+	GATE(CLK_GOUT_CMU_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE, 21, 0, 0),
-	GATE(CLK_GOUT_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
+	GATE(CLK_GOUT_CMU_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card",
+	GATE(CLK_GOUT_CMU_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card",
 	     "mout_cmu_hsi2_mmc_card", CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD,
 	     21, 0, 0),
-	GATE(CLK_GOUT_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
+	GATE(CLK_GOUT_CMU_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE, 21, 0, 0),
-	GATE(CLK_GOUT_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd",
+	GATE(CLK_GOUT_CMU_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd",
 	     "mout_cmu_hsi2_ufs_embd", CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD,
 	     21, 0, 0),
-	GATE(CLK_GOUT_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
+	GATE(CLK_GOUT_CMU_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_IPP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_ITP_BUS, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
+	GATE(CLK_GOUT_CMU_ITP_BUS, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_ITP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
+	GATE(CLK_GOUT_CMU_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
 	     CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC, 21, 0, 0),
-	GATE(CLK_GOUT_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
+	GATE(CLK_GOUT_CMU_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
 	     CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC, 21, 0, 0),
-	GATE(CLK_GOUT_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
+	GATE(CLK_GOUT_CMU_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
 	     CLK_CON_GAT_GATE_CLKCMU_MFC_MFC, 21, 0, 0),
-	GATE(CLK_GOUT_MIF_BUSP, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
+	GATE(CLK_GOUT_CMU_MIF_BUSP, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
 	     CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP, 21, 0, 0),
-	GATE(CLK_GOUT_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
+	GATE(CLK_GOUT_CMU_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_MISC_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
+	GATE(CLK_GOUT_CMU_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
 	     CLK_CON_GAT_GATE_CLKCMU_MISC_SSS, 21, 0, 0),
-	GATE(CLK_GOUT_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
+	GATE(CLK_GOUT_CMU_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
+	GATE(CLK_GOUT_CMU_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
 	     CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_PERIC0_BUS, "gout_cmu_peric0_bus", "mout_cmu_peric0_bus",
-	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
+	GATE(CLK_GOUT_CMU_PERIC0_BUS, "gout_cmu_peric0_bus",
+	     "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
 	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
-	GATE(CLK_GOUT_PERIC1_BUS, "gout_cmu_peric1_bus", "mout_cmu_peric1_bus",
-	     CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
+	GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
+	     "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
 	     CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP, 21, 0, 0),
-	GATE(CLK_GOUT_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
+	GATE(CLK_GOUT_CMU_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_TNR_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_TOP_CMUREF, "gout_cmu_top_cmuref", "mout_cmu_top_cmuref",
-	     CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF, 21, 0, 0),
-	GATE(CLK_GOUT_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
+	GATE(CLK_GOUT_CMU_TOP_CMUREF, "gout_cmu_top_cmuref",
+	     "mout_cmu_top_cmuref", CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_TPU_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
+	GATE(CLK_GOUT_CMU_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
 	     CLK_CON_GAT_GATE_CLKCMU_TPU_TPU, 21, 0, 0),
-	GATE(CLK_GOUT_TPU_TPUCTL, "gout_cmu_tpu_tpuctl", "mout_cmu_tpu_tpuctl",
-	     CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL, 21, 0, 0),
-	GATE(CLK_GOUT_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
+	GATE(CLK_GOUT_CMU_TPU_TPUCTL, "gout_cmu_tpu_tpuctl",
+	     "mout_cmu_tpu_tpuctl", CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
 	     CLK_CON_GAT_GATE_CLKCMU_TPU_UART, 21, 0, 0),
 };
 
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
index 9761c0b24e66..21adec22387c 100644
--- a/include/dt-bindings/clock/google,gs101.h
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -166,79 +166,79 @@
 #define CLK_DOUT_CMU_SHARED3_DIV2	150
 
 /* CMU_TOP Gates */
-#define CLK_GOUT_BUS0_BOOST		151
-#define CLK_GOUT_BUS1_BOOST		152
-#define CLK_GOUT_BUS2_BOOST		153
-#define CLK_GOUT_CORE_BOOST		154
-#define CLK_GOUT_CPUCL0_BOOST		155
-#define CLK_GOUT_CPUCL1_BOOST		156
-#define CLK_GOUT_CPUCL2_BOOST		157
-#define CLK_GOUT_MIF_BOOST		158
-#define CLK_GOUT_MIF_SWITCH		159
-#define CLK_GOUT_BO_BUS			160
-#define CLK_GOUT_BUS0_BUS		161
-#define CLK_GOUT_BUS1_BUS		162
-#define CLK_GOUT_BUS2_BUS		163
-#define CLK_GOUT_CIS_CLK0		164
-#define CLK_GOUT_CIS_CLK1		165
-#define CLK_GOUT_CIS_CLK2		166
-#define CLK_GOUT_CIS_CLK3		167
-#define CLK_GOUT_CIS_CLK4		168
-#define CLK_GOUT_CIS_CLK5		169
-#define CLK_GOUT_CIS_CLK6		170
-#define CLK_GOUT_CIS_CLK7		171
-#define CLK_GOUT_CMU_BOOST		172
-#define CLK_GOUT_CORE_BUS		173
-#define CLK_GOUT_CPUCL0_DBG		174
-#define CLK_GOUT_CPUCL0_SWITCH		175
-#define CLK_GOUT_CPUCL1_SWITCH		176
-#define CLK_GOUT_CPUCL2_SWITCH		177
-#define CLK_GOUT_CSIS_BUS		178
-#define CLK_GOUT_DISP_BUS		179
-#define CLK_GOUT_DNS_BUS		180
-#define CLK_GOUT_DPU_BUS		181
-#define CLK_GOUT_EH_BUS			182
-#define CLK_GOUT_G2D_G2D		183
-#define CLK_GOUT_G2D_MSCL		184
-#define CLK_GOUT_G3AA_G3AA		185
-#define CLK_GOUT_G3D_BUSD		186
-#define CLK_GOUT_G3D_GLB		187
-#define CLK_GOUT_G3D_SWITCH		188
-#define CLK_GOUT_GDC_GDC0		189
-#define CLK_GOUT_GDC_GDC1		190
-#define CLK_GOUT_GDC_SCSC		191
+#define CLK_GOUT_CMU_BUS0_BOOST		151
+#define CLK_GOUT_CMU_BUS1_BOOST		152
+#define CLK_GOUT_CMU_BUS2_BOOST		153
+#define CLK_GOUT_CMU_CORE_BOOST		154
+#define CLK_GOUT_CMU_CPUCL0_BOOST	155
+#define CLK_GOUT_CMU_CPUCL1_BOOST	156
+#define CLK_GOUT_CMU_CPUCL2_BOOST	157
+#define CLK_GOUT_CMU_MIF_BOOST		158
+#define CLK_GOUT_CMU_MIF_SWITCH		159
+#define CLK_GOUT_CMU_BO_BUS		160
+#define CLK_GOUT_CMU_BUS0_BUS		161
+#define CLK_GOUT_CMU_BUS1_BUS		162
+#define CLK_GOUT_CMU_BUS2_BUS		163
+#define CLK_GOUT_CMU_CIS_CLK0		164
+#define CLK_GOUT_CMU_CIS_CLK1		165
+#define CLK_GOUT_CMU_CIS_CLK2		166
+#define CLK_GOUT_CMU_CIS_CLK3		167
+#define CLK_GOUT_CMU_CIS_CLK4		168
+#define CLK_GOUT_CMU_CIS_CLK5		169
+#define CLK_GOUT_CMU_CIS_CLK6		170
+#define CLK_GOUT_CMU_CIS_CLK7		171
+#define CLK_GOUT_CMU_CMU_BOOST		172
+#define CLK_GOUT_CMU_CORE_BUS		173
+#define CLK_GOUT_CMU_CPUCL0_DBG		174
+#define CLK_GOUT_CMU_CPUCL0_SWITCH	175
+#define CLK_GOUT_CMU_CPUCL1_SWITCH	176
+#define CLK_GOUT_CMU_CPUCL2_SWITCH	177
+#define CLK_GOUT_CMU_CSIS_BUS		178
+#define CLK_GOUT_CMU_DISP_BUS		179
+#define CLK_GOUT_CMU_DNS_BUS		180
+#define CLK_GOUT_CMU_DPU_BUS		181
+#define CLK_GOUT_CMU_EH_BUS		182
+#define CLK_GOUT_CMU_G2D_G2D		183
+#define CLK_GOUT_CMU_G2D_MSCL		184
+#define CLK_GOUT_CMU_G3AA_G3AA		185
+#define CLK_GOUT_CMU_G3D_BUSD		186
+#define CLK_GOUT_CMU_G3D_GLB		187
+#define CLK_GOUT_CMU_G3D_SWITCH		188
+#define CLK_GOUT_CMU_GDC_GDC0		189
+#define CLK_GOUT_CMU_GDC_GDC1		190
+#define CLK_GOUT_CMU_GDC_SCSC		191
 #define CLK_GOUT_CMU_HPM		192
-#define CLK_GOUT_HSI0_BUS		193
-#define CLK_GOUT_HSI0_DPGTC		194
-#define CLK_GOUT_HSI0_USB31DRD		195
-#define CLK_GOUT_HSI0_USBDPDBG		196
-#define CLK_GOUT_HSI1_BUS		197
-#define CLK_GOUT_HSI1_PCIE		198
-#define CLK_GOUT_HSI2_BUS		199
-#define CLK_GOUT_HSI2_MMC_CARD		200
-#define CLK_GOUT_HSI2_PCIE		201
-#define CLK_GOUT_HSI2_UFS_EMBD		202
-#define CLK_GOUT_IPP_BUS		203
-#define CLK_GOUT_ITP_BUS		204
-#define CLK_GOUT_MCSC_ITSC		205
-#define CLK_GOUT_MCSC_MCSC		206
-#define CLK_GOUT_MFC_MFC		207
-#define CLK_GOUT_MIF_BUSP		208
-#define CLK_GOUT_MISC_BUS		209
-#define CLK_GOUT_MISC_SSS		210
-#define CLK_GOUT_PDP_BUS		211
-#define CLK_GOUT_PDP_VRA		212
-#define CLK_GOUT_G3AA			213
-#define CLK_GOUT_PERIC0_BUS		214
-#define CLK_GOUT_PERIC0_IP		215
-#define CLK_GOUT_PERIC1_BUS		216
-#define CLK_GOUT_PERIC1_IP		217
-#define CLK_GOUT_TNR_BUS		218
-#define CLK_GOUT_TOP_CMUREF		219
-#define CLK_GOUT_TPU_BUS		220
-#define CLK_GOUT_TPU_TPU		221
-#define CLK_GOUT_TPU_TPUCTL		222
-#define CLK_GOUT_TPU_UART		223
+#define CLK_GOUT_CMU_HSI0_BUS		193
+#define CLK_GOUT_CMU_HSI0_DPGTC		194
+#define CLK_GOUT_CMU_HSI0_USB31DRD	195
+#define CLK_GOUT_CMU_HSI0_USBDPDBG	196
+#define CLK_GOUT_CMU_HSI1_BUS		197
+#define CLK_GOUT_CMU_HSI1_PCIE		198
+#define CLK_GOUT_CMU_HSI2_BUS		199
+#define CLK_GOUT_CMU_HSI2_MMC_CARD	200
+#define CLK_GOUT_CMU_HSI2_PCIE		201
+#define CLK_GOUT_CMU_HSI2_UFS_EMBD	202
+#define CLK_GOUT_CMU_IPP_BUS		203
+#define CLK_GOUT_CMU_ITP_BUS		204
+#define CLK_GOUT_CMU_MCSC_ITSC		205
+#define CLK_GOUT_CMU_MCSC_MCSC		206
+#define CLK_GOUT_CMU_MFC_MFC		207
+#define CLK_GOUT_CMU_MIF_BUSP		208
+#define CLK_GOUT_CMU_MISC_BUS		209
+#define CLK_GOUT_CMU_MISC_SSS		210
+#define CLK_GOUT_CMU_PDP_BUS		211
+#define CLK_GOUT_CMU_PDP_VRA		212
+#define CLK_GOUT_CMU_G3AA		213
+#define CLK_GOUT_CMU_PERIC0_BUS		214
+#define CLK_GOUT_CMU_PERIC0_IP		215
+#define CLK_GOUT_CMU_PERIC1_BUS		216
+#define CLK_GOUT_CMU_PERIC1_IP		217
+#define CLK_GOUT_CMU_TNR_BUS		218
+#define CLK_GOUT_CMU_TOP_CMUREF		219
+#define CLK_GOUT_CMU_TPU_BUS		220
+#define CLK_GOUT_CMU_TPU_TPU		221
+#define CLK_GOUT_CMU_TPU_TPUCTL		222
+#define CLK_GOUT_CMU_TPU_UART		223
 
 /* CMU_APM */
 #define CLK_MOUT_APM_FUNC				1
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:32 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:32 +0000
Subject: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-3-tudor.ambarus@linaro.org>

Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
clock management unit.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 .../bindings/clock/google,gs101-clock.yaml    | 25 +++++-
 include/dt-bindings/clock/google,gs101.h      | 86 +++++++++++++++++++
 2 files changed, 109 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
index 3eebc03a309b..ba54c13c55bc 100644
--- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -30,14 +30,15 @@ properties:
       - google,gs101-cmu-top
       - google,gs101-cmu-apm
       - google,gs101-cmu-misc
+      - google,gs101-cmu-peric0
 
   clocks:
     minItems: 1
-    maxItems: 2
+    maxItems: 3
 
   clock-names:
     minItems: 1
-    maxItems: 2
+    maxItems: 3
 
   "#clock-cells":
     const: 1
@@ -88,6 +89,26 @@ allOf:
             - const: dout_cmu_misc_bus
             - const: dout_cmu_misc_sss
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-peric0
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+            - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
+            - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
+
+        clock-names:
+          items:
+            - const: oscclk
+            - const: dout_cmu_peric0_bus
+            - const: dout_cmu_peric0_ip
+
 additionalProperties: false
 
 examples:
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
index 21adec22387c..7d7a896416a7 100644
--- a/include/dt-bindings/clock/google,gs101.h
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -389,4 +389,90 @@
 #define CLK_GOUT_MISC_WDT_CLUSTER1_PCLK			73
 #define CLK_GOUT_MISC_XIU_D_MISC_ACLK			74
 
+/* CMU_PERIC0 */
+/* CMU_PERIC0 MUX */
+#define CLK_MOUT_PERIC0_BUS_USER			1
+#define CLK_MOUT_PERIC0_I3C_USER			2
+#define CLK_MOUT_PERIC0_USI0_UART_USER			3
+#define CLK_MOUT_PERIC0_USI14_USI_USER			4
+#define CLK_MOUT_PERIC0_USI1_USI_USER			5
+#define CLK_MOUT_PERIC0_USI2_USI_USER			6
+#define CLK_MOUT_PERIC0_USI3_USI_USER			7
+#define CLK_MOUT_PERIC0_USI4_USI_USER			8
+#define CLK_MOUT_PERIC0_USI5_USI_USER			9
+#define CLK_MOUT_PERIC0_USI6_USI_USER			10
+#define CLK_MOUT_PERIC0_USI7_USI_USER			11
+#define CLK_MOUT_PERIC0_USI8_USI_USER			12
+
+/* CMU_PERIC0 Dividers */
+#define CLK_DOUT_PERIC0_I3C				13
+#define CLK_DOUT_PERIC0_USI0_UART			14
+#define CLK_DOUT_PERIC0_USI14_USI			15
+#define CLK_DOUT_PERIC0_USI1_USI			16
+#define CLK_DOUT_PERIC0_USI2_USI			17
+#define CLK_DOUT_PERIC0_USI3_USI			18
+#define CLK_DOUT_PERIC0_USI4_USI			19
+#define CLK_DOUT_PERIC0_USI5_USI			20
+#define CLK_DOUT_PERIC0_USI6_USI			21
+#define CLK_DOUT_PERIC0_USI7_USI			22
+#define CLK_DOUT_PERIC0_USI8_USI			23
+
+/* CMU_PERIC0 Gates */
+#define CLK_GOUT_PERIC0_IP				24
+#define CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK		25
+#define CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK		26
+#define CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK		27
+#define CLK_GOUT_PERIC0_GPC_PERIC0_PCLK			28
+#define CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK		29
+#define CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK		30
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0		31
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1		32
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10		33
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11		34
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12		35
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13		36
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14		37
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15		38
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2		39
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3		40
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4		41
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5		42
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6		43
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7		44
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8		45
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9		46
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0		47
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1		48
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10		49
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11		50
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12		51
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13		52
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14		53
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15		54
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2		55
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3		56
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4		57
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5		58
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6		59
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7		60
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8		61
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9		62
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0		63
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2		64
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0		65
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2		66
+#define CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK		67
+#define CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK		68
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK	69
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK	70
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK		71
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK		72
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK		73
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK		74
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK		75
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK		76
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK		77
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK		78
+#define CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK		79
+
 #endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:33 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:33 +0000
Subject: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-4-tudor.ambarus@linaro.org>

Add google,gs101-hsi2c dedicated compatible for representing
I2C of Google GS101 SoC.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
index df9c57bca2a8..cc8bba5537b9 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
@@ -33,6 +33,7 @@ properties:
           - const: samsung,exynos7-hsi2c
       - items:
           - enum:
+              - google,gs101-hsi2c
               - samsung,exynos850-hsi2c
           - const: samsung,exynosautov9-hsi2c
       - const: samsung,exynos5-hsi2c    # Exynos5250 and Exynos5420
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:34 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:34 +0000
Subject: [PATCH 04/13] dt-bindings: serial: samsung: gs101: make reg-io-width required property
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-5-tudor.ambarus@linaro.org>

GS101 only allows 32-bit register accesses. When using 8-bit reg
accesses on gs101, a SError Interrupt is raised causing the system
unusable.

Make reg-io-width a required property and expect for it a value of 4.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 Documentation/devicetree/bindings/serial/samsung_uart.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index 133259ed3a34..cc896d7e2a3d 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -143,6 +143,10 @@ allOf:
     then:
       required:
         - samsung,uart-fifosize
+        - reg-io-width
+      properties:
+        reg-io-width:
+          const: 4
 
 unevaluatedProperties: false
 
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:35 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:35 +0000
Subject: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-6-tudor.ambarus@linaro.org>

GS101 only allows 32-bit register accesses. If using 8-bit register
accesses on gs101, a SError Interrupt is raised causing the system
unusable.

Force the reg accesses to MMIO32 regardless of the user's settings.
This is a common practice for such earlycons (bcm2835aux, uniphier,
lpuart32), in order to avoid crashing the kernel with a wrong early
console definition.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 drivers/tty/serial/samsung_tty.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 66bd6c090ace..19cd3e6a9b6e 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2787,6 +2787,17 @@ OF_EARLYCON_DECLARE(exynos4210, "samsung,exynos4210-uart",
 OF_EARLYCON_DECLARE(artpec8, "axis,artpec8-uart",
 			s5pv210_early_console_setup);
 
+static int __init gs101_early_console_setup(struct earlycon_device *device,
+					    const char *opt)
+{
+	/* gs101 always expects MMIO32 register accesses. */
+	device->port.iotype = UPIO_MEM32;
+
+	return s5pv210_early_console_setup(device, opt);
+}
+
+OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);
+
 /* Apple S5L */
 static int __init apple_s5l_early_console_setup(struct earlycon_device *device,
 						const char *opt)
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:37 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:37 +0000
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-8-tudor.ambarus@linaro.org>

Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
which then makes the system hang. To prevent this, mark
CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
accordingly when tested.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 drivers/clk/samsung/clk-gs101.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 3d194520b05e..08d80fca9cd6 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
 	     "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
 	     21, 0, 0),
 	GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
-	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
+	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
 	GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
 	     "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
 	     21, 0, 0),
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:39 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:39 +0000
Subject: [PATCH 09/13] arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-10-tudor.ambarus@linaro.org>

Get rid of the dummy clock and start using the cmu_peric0 clocks
for the usi_uart and serial_0 nodes.

Tested the serial at 115200, 1000000 and 3000000 baudrates,
everthing went fine.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index d0b0ad70c6ba..ffb7b4d89a8c 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -180,14 +180,6 @@ HERA_CPU_SLEEP: cpu-hera-sleep {
 		};
 	};
 
-	/* TODO replace with CCF clock */
-	dummy_clk: clock-3 {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		clock-frequency = <12345>;
-		clock-output-names = "pclk";
-	};
-
 	/* ect node is required to be present by bootloader */
 	ect {
 	};
@@ -369,7 +361,8 @@ usi_uart: usi at 10a000c0 {
 			ranges;
 			#address-cells = <1>;
 			#size-cells = <1>;
-			clocks = <&dummy_clk>, <&dummy_clk>;
+			clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
+				 <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
 			clock-names = "pclk", "ipclk";
 			samsung,sysreg = <&sysreg_peric0 0x1020>;
 			samsung,mode = <USI_V2_UART>;
@@ -381,7 +374,8 @@ serial_0: serial at 10a00000 {
 				reg-io-width = <4>;
 				interrupts = <GIC_SPI 634
 					      IRQ_TYPE_LEVEL_HIGH 0>;
-				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
+				clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
+					 <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
 				clock-names = "uart", "clk_uart_baud0";
 				samsung,uart-fifosize = <256>;
 				status = "disabled";
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:36 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:36 +0000
Subject: [PATCH 06/13] clk: samsung: gs101: add support for cmu_peric0
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-7-tudor.ambarus@linaro.org>

CMU_PERIC0 is the clock management unit used for the peric0 block which
is used for USI and I3C. Add support for cmu_peric0.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 drivers/clk/samsung/clk-gs101.c | 579 ++++++++++++++++++++++++++++++++
 1 file changed, 579 insertions(+)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 0964bb11657f..3d194520b05e 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -20,6 +20,7 @@
 #define CLKS_NR_TOP	(CLK_GOUT_CMU_TPU_UART + 1)
 #define CLKS_NR_APM	(CLK_APM_PLL_DIV16_APM + 1)
 #define CLKS_NR_MISC	(CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
+#define CLKS_NR_PERIC0	(CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK + 1)
 
 /* ---- CMU_TOP ------------------------------------------------------------- */
 
@@ -2478,6 +2479,581 @@ static const struct samsung_cmu_info misc_cmu_info __initconst = {
 	.clk_name		= "dout_cmu_misc_bus",
 };
 
+/* ---- CMU_PERIC0 --------------------------------------------------------- */
+
+/* Register Offset definitions for CMU_PERIC0 (0x10800000) */
+#define PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER		0x0600
+#define PLL_CON1_MUX_CLKCMU_PERIC0_BUS_USER		0x0604
+#define PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER		0x0610
+#define PLL_CON1_MUX_CLKCMU_PERIC0_I3C_USER		0x0614
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER	0x0620
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI0_UART_USER	0x0624
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER	0x0640
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI14_USI_USER	0x0644
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER	0x0650
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI1_USI_USER	0x0654
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER	0x0660
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI2_USI_USER	0x0664
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER	0x0670
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI3_USI_USER	0x0674
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER	0x0680
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI4_USI_USER	0x0684
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER	0x0690
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI5_USI_USER	0x0694
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER	0x06a0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI6_USI_USER	0x06a4
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER	0x06b0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI7_USI_USER	0x06b4
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER	0x06c0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI8_USI_USER	0x06c4
+#define PERIC0_CMU_PERIC0_CONTROLLER_OPTION		0x0800
+#define CLKOUT_CON_BLK_PERIC0_CMU_PERIC0_CLKOUT0	0x0810
+#define CLK_CON_DIV_DIV_CLK_PERIC0_I3C			0x1800
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART		0x1804
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI		0x180c
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI		0x1810
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI		0x1814
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI		0x1820
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI		0x1824
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI		0x1828
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI		0x182c
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI7_USI		0x1830
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI		0x1834
+#define CLK_CON_BUF_CLKBUF_PERIC0_IP			0x2000
+#define CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK			0x2004
+#define CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK		0x2008
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK			0x200c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK			0x2010
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK			0x2014
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK		0x2018
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0			0x201c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1			0x2020
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10			0x2024
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11			0x2028
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12			0x202c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13			0x2030
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14			0x2034
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15			0x2038
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2			0x203c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3			0x2040
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4			0x2044
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5			0x2048
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6			0x204c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7			0x2050
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8			0x2054
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9			0x2058
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0			0x205c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1			0x2060
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10			0x2064
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11			0x2068
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12			0x206c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13			0x2070
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14			0x2074
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15			0x2078
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2			0x207c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3			0x2080
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4			0x2084
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5			0x2088
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6			0x208c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7			0x2090
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8			0x2094
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9			0x2098
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0			0x209c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2			0x20a4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0			0x20a8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2			0x20b0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK		0x20b4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK		0x20b8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK	0x20bc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK	0x20c4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK	0x20c8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK	0x20cc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK	0x20d0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK	0x20d4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK	0x20d8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK	0x20dc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK	0x20e0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK	0x20e4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK			0x20e8
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S1			0x3000
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S2			0x3004
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S3			0x3008
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S4			0x300c
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S5			0x3010
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S6			0x3014
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S7			0x3018
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S8			0x301c
+#define PCH_CON_LHM_AXI_P_PERIC0_PCH			0x3020
+#define QCH_CON_D_TZPC_PERIC0_QCH			0x3024
+#define QCH_CON_GPC_PERIC0_QCH				0x3028
+#define QCH_CON_GPIO_PERIC0_QCH				0x302c
+#define QCH_CON_LHM_AXI_P_PERIC0_QCH			0x3030
+#define QCH_CON_PERIC0_CMU_PERIC0_QCH			0x3034
+#define QCH_CON_PERIC0_TOP0_QCH_I3C1			0x3038
+#define QCH_CON_PERIC0_TOP0_QCH_I3C2			0x303c
+#define QCH_CON_PERIC0_TOP0_QCH_I3C3			0x3040
+#define QCH_CON_PERIC0_TOP0_QCH_I3C4			0x3044
+#define QCH_CON_PERIC0_TOP0_QCH_I3C5			0x3048
+#define QCH_CON_PERIC0_TOP0_QCH_I3C6			0x304c
+#define QCH_CON_PERIC0_TOP0_QCH_I3C7			0x3050
+#define QCH_CON_PERIC0_TOP0_QCH_I3C8			0x3054
+#define QCH_CON_PERIC0_TOP0_QCH_USI1_USI		0x3058
+#define QCH_CON_PERIC0_TOP0_QCH_USI2_USI		0x305c
+#define QCH_CON_PERIC0_TOP0_QCH_USI3_USI		0x3060
+#define QCH_CON_PERIC0_TOP0_QCH_USI4_USI		0x3064
+#define QCH_CON_PERIC0_TOP0_QCH_USI5_USI		0x3068
+#define QCH_CON_PERIC0_TOP0_QCH_USI6_USI		0x306c
+#define QCH_CON_PERIC0_TOP0_QCH_USI7_USI		0x3070
+#define QCH_CON_PERIC0_TOP0_QCH_USI8_USI		0x3074
+#define QCH_CON_PERIC0_TOP1_QCH_USI0_UART		0x3078
+#define QCH_CON_PERIC0_TOP1_QCH_USI14_UART		0x307c
+#define QCH_CON_SYSREG_PERIC0_QCH			0x3080
+#define QUEUE_CTRL_REG_BLK_PERIC0_CMU_PERIC0		0x3c00
+
+static const unsigned long peric0_clk_regs[] __initconst = {
+	PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_BUS_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_I3C_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI0_UART_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI14_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI1_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI2_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI3_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI4_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI5_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI6_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI7_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI8_USI_USER,
+	PERIC0_CMU_PERIC0_CONTROLLER_OPTION,
+	CLKOUT_CON_BLK_PERIC0_CMU_PERIC0_CLKOUT0,
+	CLK_CON_DIV_DIV_CLK_PERIC0_I3C,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI,
+	CLK_CON_BUF_CLKBUF_PERIC0_IP,
+	CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S1,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S2,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S3,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S4,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S5,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S6,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S7,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S8,
+	PCH_CON_LHM_AXI_P_PERIC0_PCH,
+	QCH_CON_D_TZPC_PERIC0_QCH,
+	QCH_CON_GPC_PERIC0_QCH,
+	QCH_CON_GPIO_PERIC0_QCH,
+	QCH_CON_LHM_AXI_P_PERIC0_QCH,
+	QCH_CON_PERIC0_CMU_PERIC0_QCH,
+	QCH_CON_PERIC0_TOP0_QCH_I3C1,
+	QCH_CON_PERIC0_TOP0_QCH_I3C2,
+	QCH_CON_PERIC0_TOP0_QCH_I3C3,
+	QCH_CON_PERIC0_TOP0_QCH_I3C4,
+	QCH_CON_PERIC0_TOP0_QCH_I3C5,
+	QCH_CON_PERIC0_TOP0_QCH_I3C6,
+	QCH_CON_PERIC0_TOP0_QCH_I3C7,
+	QCH_CON_PERIC0_TOP0_QCH_I3C8,
+	QCH_CON_PERIC0_TOP0_QCH_USI1_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI2_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI3_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI4_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI5_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI6_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI7_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI8_USI,
+	QCH_CON_PERIC0_TOP1_QCH_USI0_UART,
+	QCH_CON_PERIC0_TOP1_QCH_USI14_UART,
+	QCH_CON_SYSREG_PERIC0_QCH,
+	QUEUE_CTRL_REG_BLK_PERIC0_CMU_PERIC0,
+};
+
+/* List of parent clocks for Muxes in CMU_PERIC0 */
+PNAME(mout_peric0_bus_user_p)		= { "oscclk", "dout_cmu_peric0_bus" };
+PNAME(mout_peric0_i3c_user_p)		= { "oscclk", "dout_cmu_peric0_ip" };
+PNAME(mout_peric0_usi0_uart_user_p)	= { "oscclk", "dout_cmu_peric0_ip" };
+PNAME(mout_peric0_usi_usi_user_p)	= { "oscclk", "dout_cmu_peric0_ip" };
+
+static const struct samsung_mux_clock peric0_mux_clks[] __initconst = {
+	MUX(CLK_MOUT_PERIC0_BUS_USER, "mout_peric0_bus_user",
+	    mout_peric0_bus_user_p, PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_I3C_USER, "mout_peric0_i3c_user",
+	    mout_peric0_i3c_user_p, PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI0_UART_USER,
+	    "mout_peric0_usi0_uart_user", mout_peric0_usi0_uart_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI14_USI_USER,
+	    "mout_peric0_usi14_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI1_USI_USER,
+	    "mout_peric0_usi1_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI2_USI_USER,
+	    "mout_peric0_usi2_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI3_USI_USER,
+	    "mout_peric0_usi3_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI4_USI_USER,
+	    "mout_peric0_usi4_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI5_USI_USER,
+	    "mout_peric0_usi5_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI6_USI_USER,
+	    "mout_peric0_usi6_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI7_USI_USER,
+	    "mout_peric0_usi7_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI8_USI_USER,
+	    "mout_peric0_usi8_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER, 4, 1),
+};
+
+static const struct samsung_div_clock peric0_div_clks[] __initconst = {
+	DIV(CLK_DOUT_PERIC0_I3C, "dout_peric0_i3c", "mout_peric0_i3c_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_I3C, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI0_UART,
+	    "dout_peric0_usi0_uart", "mout_peric0_usi0_uart_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI14_USI,
+	    "dout_peric0_usi14_usi", "mout_peric0_usi14_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI1_USI,
+	    "dout_peric0_usi1_usi", "mout_peric0_usi1_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI2_USI,
+	    "dout_peric0_usi2_usi", "mout_peric0_usi2_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI3_USI,
+	    "dout_peric0_usi3_usi", "mout_peric0_usi3_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI4_USI,
+	    "dout_peric0_usi4_usi", "mout_peric0_usi4_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI5_USI,
+	    "dout_peric0_usi5_usi", "mout_peric0_usi5_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI6_USI,
+	    "dout_peric0_usi6_usi", "mout_peric0_usi6_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI7_USI,
+	    "dout_peric0_usi7_usi", "mout_peric0_usi7_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI7_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI8_USI,
+	    "dout_peric0_usi8_usi", "mout_peric0_usi8_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI, 0, 3),
+};
+
+static const struct samsung_gate_clock peric0_gate_clks[] __initconst = {
+	GATE(CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK,
+	     "gout_peric0_peric0_cmu_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK,
+	     "gout_peric0_clk_peric0_oscclk_clk", "oscclk",
+	     CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK,
+	     "gout_peric0_d_tzpc_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_GPC_PERIC0_PCLK,
+	     "gout_peric0_gpc_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK,
+	     "gout_peric0_gpio_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK,
+	     "gout_peric0_lhm_axi_p_peric0_i_clk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0,
+	     "gout_peric0_peric0_top0_ipclk_0", "dout_peric0_usi1_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1,
+	     "gout_peric0_peric0_top0_ipclk_1", "dout_peric0_usi2_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10,
+	     "gout_peric0_peric0_top0_ipclk_10", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11,
+	     "gout_peric0_peric0_top0_ipclk_11", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12,
+	     "gout_peric0_peric0_top0_ipclk_12", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13,
+	     "gout_peric0_peric0_top0_ipclk_13", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14,
+	     "gout_peric0_peric0_top0_ipclk_14", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15,
+	     "gout_peric0_peric0_top0_ipclk_15", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2,
+	     "gout_peric0_peric0_top0_ipclk_2", "dout_peric0_usi3_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3,
+	     "gout_peric0_peric0_top0_ipclk_3", "dout_peric0_usi4_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4,
+	     "gout_peric0_peric0_top0_ipclk_4", "dout_peric0_usi5_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5,
+	     "gout_peric0_peric0_top0_ipclk_5", "dout_peric0_usi6_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6,
+	     "gout_peric0_peric0_top0_ipclk_6", "dout_peric0_usi7_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7,
+	     "gout_peric0_peric0_top0_ipclk_7", "dout_peric0_usi8_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8,
+	     "gout_peric0_peric0_top0_ipclk_8", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9,
+	     "gout_peric0_peric0_top0_ipclk_9", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0,
+	     "gout_peric0_peric0_top0_pclk_0", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1,
+	     "gout_peric0_peric0_top0_pclk_1", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10,
+	     "gout_peric0_peric0_top0_pclk_10", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11,
+	     "gout_peric0_peric0_top0_pclk_11", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12,
+	     "gout_peric0_peric0_top0_pclk_12", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13,
+	     "gout_peric0_peric0_top0_pclk_13", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14,
+	     "gout_peric0_peric0_top0_pclk_14", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15,
+	     "gout_peric0_peric0_top0_pclk_15", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2,
+	     "gout_peric0_peric0_top0_pclk_2", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3,
+	     "gout_peric0_peric0_top0_pclk_3", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4,
+	     "gout_peric0_peric0_top0_pclk_4", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5,
+	     "gout_peric0_peric0_top0_pclk_5", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6,
+	     "gout_peric0_peric0_top0_pclk_6", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7,
+	     "gout_peric0_peric0_top0_pclk_7", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8,
+	     "gout_peric0_peric0_top0_pclk_8", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9,
+	     "gout_peric0_peric0_top0_pclk_9", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0,
+	     "gout_peric0_peric0_top1_ipclk_0", "dout_peric0_usi0_uart",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2,
+	     "gout_peric0_peric0_top1_ipclk_2", "dout_peric0_usi14_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0,
+	     "gout_peric0_peric0_top1_pclk_0", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2,
+	     "gout_peric0_peric0_top1_pclk_2", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK,
+	     "gout_peric0_peric0_busp_clk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK,
+	     "gout_peric0_clk_peric0_i3c_clk", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK,
+	     "gout_peric0_clk_peric0_usi0_uart_clk", "dout_peric0_usi0_uart",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK,
+	     "gout_peric0_clk_peric0_usi14_usi_clk", "dout_peric0_usi14_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK,
+	     "gout_peric0_clk_peric0_usi1_usi_clk", "dout_peric0_usi1_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK,
+	     "gout_peric0_clk_peric0_usi2_usi_clk", "dout_peric0_usi2_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK,
+	     "gout_peric0_clk_peric0_usi3_usi_clk", "dout_peric0_usi3_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK,
+	     "gout_peric0_clk_peric0_usi4_usi_clk", "dout_peric0_usi4_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK,
+	     "gout_peric0_clk_peric0_usi5_usi_clk", "dout_peric0_usi5_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK,
+	     "gout_peric0_clk_peric0_usi6_usi_clk", "dout_peric0_usi6_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK,
+	     "gout_peric0_clk_peric0_usi7_usi_clk", "dout_peric0_usi7_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK,
+	     "gout_peric0_clk_peric0_usi8_usi_clk", "dout_peric0_usi8_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK,
+	     "gout_peric0_sysreg_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+};
+
+static const struct samsung_cmu_info peric0_cmu_info __initconst = {
+	.mux_clks		= peric0_mux_clks,
+	.nr_mux_clks		= ARRAY_SIZE(peric0_mux_clks),
+	.div_clks		= peric0_div_clks,
+	.nr_div_clks		= ARRAY_SIZE(peric0_div_clks),
+	.gate_clks		= peric0_gate_clks,
+	.nr_gate_clks		= ARRAY_SIZE(peric0_gate_clks),
+	.nr_clk_ids		= CLKS_NR_PERIC0,
+	.clk_regs		= peric0_clk_regs,
+	.nr_clk_regs		= ARRAY_SIZE(peric0_clk_regs),
+	.clk_name		= "dout_cmu_peric0_bus",
+};
+
 /* ---- platform_driver ----------------------------------------------------- */
 
 static int __init gs101_cmu_probe(struct platform_device *pdev)
@@ -2498,6 +3074,9 @@ static const struct of_device_id gs101_cmu_of_match[] = {
 	}, {
 		.compatible = "google,gs101-cmu-misc",
 		.data = &misc_cmu_info,
+	}, {
+		.compatible = "google,gs101-cmu-peric0",
+		.data = &peric0_cmu_info,
 	}, {
 	},
 };
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:38 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:38 +0000
Subject: [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-9-tudor.ambarus@linaro.org>

Enable the cmu-peric0 clock controller. It feeds USI and I3c.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 9747cb3fa03a..d0b0ad70c6ba 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
 			};
 		};
 
+		cmu_peric0: clock-controller at 10800000 {
+			compatible = "google,gs101-cmu-peric0";
+			reg = <0x10800000 0x4000>;
+			#clock-cells = <1>;
+			clocks = <&ext_24_5m>,
+				 <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
+				 <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
+			clock-names = "oscclk",
+				      "dout_cmu_peric0_bus",
+				      "dout_cmu_peric0_ip";
+		};
+
 		sysreg_peric0: syscon at 10820000 {
 			compatible = "google,gs101-peric0-sysreg", "syscon";
 			reg = <0x10820000 0x10000>;
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:41 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:41 +0000
Subject: [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-12-tudor.ambarus@linaro.org>

Enable the eeprom found on the battery connector.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 .../boot/dts/exynos/google/gs101-oriole.dts    | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
index 4a71f752200d..11b299d21c5d 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
+++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
@@ -63,6 +63,19 @@ &ext_200m {
 	clock-frequency = <200000000>;
 };
 
+&hsi2c_8 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&hsi2c8_bus>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	eeprom: eeprom at 50 {
+		compatible = "atmel,24c08";
+		reg = <0x50>;
+	};
+};
+
 &pinctrl_far_alive {
 	key_voldown: key-voldown-pins {
 		samsung,pins = "gpa7-3";
@@ -99,6 +112,11 @@ &usi_uart {
 	status = "okay";
 };
 
+&usi8 {
+	samsung,mode = <USI_V2_I2C>;
+	status = "okay";
+};
+
 &watchdog_cl0 {
 	timeout-sec = <30>;
 	status = "okay";
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:40 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:40 +0000
Subject: [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C configuration
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-11-tudor.ambarus@linaro.org>

USI8 I2C is used to communicate with an eeprom found on the battery
connector. Define USI8 in I2C configuration.

USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
selection of the protocol is intentionally left for the board dtsi file.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 26 ++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index ffb7b4d89a8c..4ea1b180cd0a 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -354,6 +354,32 @@ pinctrl_peric0: pinctrl at 10840000 {
 			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
 		};
 
+		usi8: usi at 109700c0 {
+			compatible = "google,gs101-usi",
+				     "samsung,exynos850-usi";
+			reg = <0x109700c0 0x20>;
+			ranges;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
+				 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
+			clock-names = "pclk", "ipclk";
+			samsung,sysreg = <&sysreg_peric0 0x101c>;
+			status = "disabled";
+
+			hsi2c_8: i2c at 10970000 {
+				compatible = "google,gs101-hsi2c",
+					     "samsung,exynosautov9-hsi2c";
+				reg = <0x10970000 0xc0>;
+				interrupts = <GIC_SPI 642
+					      IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
+					 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
+				clock-names = "hsi2c", "hsi2c_pclk";
+				status = "disabled";
+			};
+		};
+
 		usi_uart: usi at 10a000c0 {
 			compatible = "google,gs101-usi",
 				     "samsung,exynos850-usi";
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:43 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:43 +0000
Subject: [PATCH 13/13] arm64: defconfig: make at24 eeprom builtin
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-14-tudor.ambarus@linaro.org>

gs101-oriole populates an at24 eeprom on the battery connector.
Make EEPROM_AT24 builtin.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 arch/arm64/configs/defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 09fb467303ba..19c1d61382f6 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -276,7 +276,7 @@ CONFIG_QCOM_COINCELL=m
 CONFIG_QCOM_FASTRPC=m
 CONFIG_SRAM=y
 CONFIG_PCI_ENDPOINT_TEST=m
-CONFIG_EEPROM_AT24=m
+CONFIG_EEPROM_AT24=y
 CONFIG_EEPROM_AT25=m
 CONFIG_UACCE=m
 # CONFIG_SCSI_PROC_FS is not set
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 14 02:52:42 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 10:52:42 +0000
Subject: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
In-Reply-To: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
Message-ID: <20231214105243.3707730-13-tudor.ambarus@linaro.org>

Sync the defconfig with savedefconfig as config options
change/move over time.

Generated with the following commands:
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
cp defconfig arch/arm64/configs/defconfig

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
 1 file changed, 55 insertions(+), 89 deletions(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b60aa1f89343..09fb467303ba 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -30,6 +30,8 @@ CONFIG_SCHED_AUTOGROUP=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_KALLSYMS_ALL=y
 CONFIG_PROFILING=y
+CONFIG_KEXEC_FILE=y
+CONFIG_CRASH_DUMP=y
 CONFIG_ARCH_ACTIONS=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_ALPINE=y
@@ -77,9 +79,6 @@ CONFIG_ARM64_VA_BITS_48=y
 CONFIG_SCHED_MC=y
 CONFIG_SCHED_SMT=y
 CONFIG_NUMA=y
-CONFIG_KEXEC=y
-CONFIG_KEXEC_FILE=y
-CONFIG_CRASH_DUMP=y
 CONFIG_XEN=y
 CONFIG_COMPAT=y
 CONFIG_RANDOMIZE_BASE=y
@@ -119,7 +118,6 @@ CONFIG_KVM=y
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
-CONFIG_IOSCHED_BFQ=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_MEMORY_HOTPLUG=y
@@ -129,8 +127,6 @@ CONFIG_MEMORY_FAILURE=y
 CONFIG_TRANSPARENT_HUGEPAGE=y
 CONFIG_NET=y
 CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
 CONFIG_IP_MULTICAST=y
 CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
@@ -180,8 +176,6 @@ CONFIG_NET_ACT_GATE=m
 CONFIG_QRTR_SMD=m
 CONFIG_QRTR_TUN=m
 CONFIG_CAN=m
-CONFIG_CAN_M_CAN=m
-CONFIG_CAN_M_CAN_PLATFORM=m
 CONFIG_BT=m
 CONFIG_BT_HIDP=m
 # CONFIG_BT_LE is not set
@@ -215,27 +209,27 @@ CONFIG_PCI_PASID=y
 CONFIG_HOTPLUG_PCI=y
 CONFIG_HOTPLUG_PCI_ACPI=y
 CONFIG_PCI_AARDVARK=y
-CONFIG_PCI_TEGRA=y
-CONFIG_PCIE_RCAR_HOST=y
-CONFIG_PCIE_RCAR_EP=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_XGENE=y
 CONFIG_PCIE_ALTERA=y
 CONFIG_PCIE_ALTERA_MSI=y
+CONFIG_PCIE_BRCMSTB=m
 CONFIG_PCI_HOST_THUNDER_PEM=y
 CONFIG_PCI_HOST_THUNDER_ECAM=y
-CONFIG_PCIE_ROCKCHIP_HOST=m
+CONFIG_PCI_HOST_GENERIC=y
 CONFIG_PCIE_MEDIATEK_GEN3=m
-CONFIG_PCIE_BRCMSTB=m
+CONFIG_PCI_TEGRA=y
+CONFIG_PCIE_RCAR_HOST=y
+CONFIG_PCIE_RCAR_EP=y
+CONFIG_PCIE_ROCKCHIP_HOST=m
+CONFIG_PCI_XGENE=y
 CONFIG_PCI_IMX6_HOST=y
 CONFIG_PCI_LAYERSCAPE=y
 CONFIG_PCI_HISI=y
-CONFIG_PCIE_QCOM=y
-CONFIG_PCIE_ARMADA_8K=y
-CONFIG_PCIE_ROCKCHIP_DW_HOST=y
 CONFIG_PCIE_KIRIN=y
 CONFIG_PCIE_HISI_STB=y
+CONFIG_PCIE_ARMADA_8K=y
 CONFIG_PCIE_TEGRA194_HOST=m
+CONFIG_PCIE_QCOM=y
+CONFIG_PCIE_ROCKCHIP_DW_HOST=y
 CONFIG_PCIE_VISCONTI_HOST=y
 CONFIG_PCIE_LAYERSCAPE_GEN4=y
 CONFIG_PCI_ENDPOINT=y
@@ -247,14 +241,12 @@ CONFIG_FW_LOADER_USER_HELPER=y
 CONFIG_HISILICON_LPC=y
 CONFIG_TEGRA_ACONNECT=m
 CONFIG_MHI_BUS_PCI_GENERIC=m
-CONFIG_ARM_SCMI_PROTOCOL=y
 CONFIG_ARM_SCPI_PROTOCOL=y
 CONFIG_RASPBERRYPI_FIRMWARE=y
 CONFIG_INTEL_STRATIX10_SERVICE=y
 CONFIG_INTEL_STRATIX10_RSU=m
 CONFIG_EFI_CAPSULE_LOADER=y
 CONFIG_IMX_SCU=y
-CONFIG_IMX_SCU_PD=y
 CONFIG_GNSS=m
 CONFIG_GNSS_MTK_SERIAL=m
 CONFIG_MTD=y
@@ -276,15 +268,12 @@ CONFIG_MTD_NAND_FSL_IFC=y
 CONFIG_MTD_NAND_QCOM=y
 CONFIG_MTD_SPI_NOR=y
 CONFIG_MTD_UBI=m
-CONFIG_UBIFS_FS=m
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_NBD=m
 CONFIG_VIRTIO_BLK=y
 CONFIG_BLK_DEV_NVME=m
 CONFIG_QCOM_COINCELL=m
 CONFIG_QCOM_FASTRPC=m
-CONFIG_BATTERY_QCOM_BATTMGR=m
-CONFIG_UCSI_PMIC_GLINK=m
 CONFIG_SRAM=y
 CONFIG_PCI_ENDPOINT_TEST=m
 CONFIG_EEPROM_AT24=m
@@ -308,7 +297,6 @@ CONFIG_AHCI_XGENE=y
 CONFIG_AHCI_QORIQ=y
 CONFIG_SATA_SIL24=y
 CONFIG_SATA_RCAR=y
-CONFIG_PATA_PLATFORM=y
 CONFIG_PATA_OF_PLATFORM=y
 CONFIG_MD=y
 CONFIG_BLK_DEV_MD=m
@@ -384,6 +372,8 @@ CONFIG_DP83869_PHY=m
 CONFIG_DP83TD510_PHY=y
 CONFIG_VITESSE_PHY=y
 CONFIG_CAN_FLEXCAN=m
+CONFIG_CAN_M_CAN=m
+CONFIG_CAN_M_CAN_PLATFORM=m
 CONFIG_CAN_RCAR=m
 CONFIG_CAN_RCAR_CANFD=m
 CONFIG_CAN_MCP251XFD=m
@@ -574,9 +564,9 @@ CONFIG_PINCTRL_IMX8DXL=y
 CONFIG_PINCTRL_IMX8ULP=y
 CONFIG_PINCTRL_IMX93=y
 CONFIG_PINCTRL_MSM=y
-CONFIG_PINCTRL_IPQ8074=y
 CONFIG_PINCTRL_IPQ5018=y
 CONFIG_PINCTRL_IPQ5332=y
+CONFIG_PINCTRL_IPQ8074=y
 CONFIG_PINCTRL_IPQ6018=y
 CONFIG_PINCTRL_IPQ9574=y
 CONFIG_PINCTRL_MSM8916=y
@@ -588,34 +578,33 @@ CONFIG_PINCTRL_MSM8998=y
 CONFIG_PINCTRL_QCM2290=y
 CONFIG_PINCTRL_QCS404=y
 CONFIG_PINCTRL_QDF2XXX=y
-CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
 CONFIG_PINCTRL_QDU1000=y
 CONFIG_PINCTRL_SA8775P=y
 CONFIG_PINCTRL_SC7180=y
 CONFIG_PINCTRL_SC7280=y
-CONFIG_PINCTRL_SC7280_LPASS_LPI=m
 CONFIG_PINCTRL_SC8180X=y
 CONFIG_PINCTRL_SC8280XP=y
 CONFIG_PINCTRL_SDM660=y
 CONFIG_PINCTRL_SDM670=y
 CONFIG_PINCTRL_SDM845=y
 CONFIG_PINCTRL_SM6115=y
-CONFIG_PINCTRL_SM6115_LPASS_LPI=m
 CONFIG_PINCTRL_SM6125=y
 CONFIG_PINCTRL_SM6350=y
 CONFIG_PINCTRL_SM6375=y
 CONFIG_PINCTRL_SM8150=y
 CONFIG_PINCTRL_SM8250=y
-CONFIG_PINCTRL_SM8250_LPASS_LPI=m
 CONFIG_PINCTRL_SM8350=y
-CONFIG_PINCTRL_SM8350_LPASS_LPI=m
 CONFIG_PINCTRL_SM8450=y
+CONFIG_PINCTRL_SM8550=y
+CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
+CONFIG_PINCTRL_LPASS_LPI=m
+CONFIG_PINCTRL_SC7280_LPASS_LPI=m
+CONFIG_PINCTRL_SM6115_LPASS_LPI=m
+CONFIG_PINCTRL_SM8250_LPASS_LPI=m
+CONFIG_PINCTRL_SM8350_LPASS_LPI=m
 CONFIG_PINCTRL_SM8450_LPASS_LPI=m
 CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
-CONFIG_PINCTRL_SM8550=y
 CONFIG_PINCTRL_SM8550_LPASS_LPI=m
-CONFIG_PINCTRL_LPASS_LPI=m
-CONFIG_GPIO_AGGREGATOR=m
 CONFIG_GPIO_ALTERA=m
 CONFIG_GPIO_DAVINCI=y
 CONFIG_GPIO_DWAPB=y
@@ -624,6 +613,7 @@ CONFIG_GPIO_MPC8XXX=y
 CONFIG_GPIO_MXC=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_RCAR=y
+CONFIG_GPIO_SYSCON=y
 CONFIG_GPIO_UNIPHIER=y
 CONFIG_GPIO_VISCONTI=y
 CONFIG_GPIO_WCD934X=m
@@ -635,7 +625,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
 CONFIG_GPIO_BD9571MWV=m
 CONFIG_GPIO_MAX77620=y
 CONFIG_GPIO_SL28CPLD=m
-CONFIG_GPIO_SYSCON=y
+CONFIG_GPIO_AGGREGATOR=m
 CONFIG_POWER_RESET_MSM=y
 CONFIG_POWER_RESET_QCOM_PON=m
 CONFIG_POWER_RESET_XGENE=y
@@ -643,6 +633,7 @@ CONFIG_POWER_RESET_SYSCON=y
 CONFIG_POWER_RESET_SYSCON_POWEROFF=y
 CONFIG_SYSCON_REBOOT_MODE=y
 CONFIG_NVMEM_REBOOT_MODE=m
+CONFIG_BATTERY_QCOM_BATTMGR=m
 CONFIG_BATTERY_SBS=m
 CONFIG_BATTERY_BQ27XXX=y
 CONFIG_BATTERY_MAX17042=m
@@ -667,8 +658,8 @@ CONFIG_DEVFREQ_THERMAL=y
 CONFIG_THERMAL_EMULATION=y
 CONFIG_IMX_SC_THERMAL=m
 CONFIG_IMX8MM_THERMAL=m
-CONFIG_QORIQ_THERMAL=m
 CONFIG_K3_THERMAL=m
+CONFIG_QORIQ_THERMAL=m
 CONFIG_SUN8I_THERMAL=y
 CONFIG_ROCKCHIP_THERMAL=m
 CONFIG_RCAR_THERMAL=y
@@ -694,6 +685,7 @@ CONFIG_ARM_SP805_WATCHDOG=y
 CONFIG_ARM_SBSA_WATCHDOG=y
 CONFIG_S3C2410_WATCHDOG=y
 CONFIG_DW_WATCHDOG=y
+CONFIG_K3_RTI_WATCHDOG=m
 CONFIG_SUNXI_WATCHDOG=m
 CONFIG_NPCM7XX_WATCHDOG=y
 CONFIG_IMX2_WDT=y
@@ -709,7 +701,6 @@ CONFIG_UNIPHIER_WATCHDOG=y
 CONFIG_PM8916_WATCHDOG=m
 CONFIG_BCM2835_WDT=y
 CONFIG_BCM7038_WDT=m
-CONFIG_K3_RTI_WATCHDOG=m
 CONFIG_MFD_ALTERA_SYSMGR=y
 CONFIG_MFD_BD9571MWV=y
 CONFIG_MFD_AXP20X_I2C=y
@@ -726,9 +717,9 @@ CONFIG_MFD_RK8XX_SPI=y
 CONFIG_MFD_SEC_CORE=y
 CONFIG_MFD_SL28CPLD=y
 CONFIG_RZ_MTU3=y
+CONFIG_MFD_TI_AM335X_TSCADC=m
 CONFIG_MFD_TPS65219=y
 CONFIG_MFD_TPS6594_I2C=m
-CONFIG_MFD_TI_AM335X_TSCADC=m
 CONFIG_MFD_ROHM_BD718XX=y
 CONFIG_MFD_WCD934X=m
 CONFIG_MFD_KHADAS_MCU=m
@@ -832,12 +823,8 @@ CONFIG_ROCKCHIP_INNO_HDMI=y
 CONFIG_ROCKCHIP_LVDS=y
 CONFIG_DRM_RCAR_DU=m
 CONFIG_DRM_RCAR_DW_HDMI=m
-CONFIG_DRM_RCAR_MIPI_DSI=m
 CONFIG_DRM_RZG2L_MIPI_DSI=m
 CONFIG_DRM_SUN4I=m
-CONFIG_DRM_SUN6I_DSI=m
-CONFIG_DRM_SUN8I_DW_HDMI=m
-CONFIG_DRM_SUN8I_MIXER=m
 CONFIG_DRM_MSM=m
 CONFIG_DRM_TEGRA=m
 CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
@@ -856,7 +843,6 @@ CONFIG_DRM_LONTIUM_LT9611UXC=m
 CONFIG_DRM_ITE_IT66121=m
 CONFIG_DRM_NWL_MIPI_DSI=m
 CONFIG_DRM_PARADE_PS8640=m
-CONFIG_DRM_SAMSUNG_DSIM=m
 CONFIG_DRM_SII902X=m
 CONFIG_DRM_SIMPLE_BRIDGE=m
 CONFIG_DRM_THINE_THC63LVD1024=m
@@ -879,15 +865,15 @@ CONFIG_DRM_HISI_KIRIN=m
 CONFIG_DRM_MEDIATEK=m
 CONFIG_DRM_MEDIATEK_HDMI=m
 CONFIG_DRM_MXSFB=m
-CONFIG_DRM_MESON=m
 CONFIG_DRM_IMX_LCDIF=m
+CONFIG_DRM_MESON=m
 CONFIG_DRM_PL111=m
 CONFIG_DRM_LIMA=m
 CONFIG_DRM_PANFROST=m
 CONFIG_DRM_TIDSS=m
 CONFIG_FB=y
-CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_EFI=y
+CONFIG_FB_MODE_HELPERS=y
 CONFIG_BACKLIGHT_PWM=m
 CONFIG_BACKLIGHT_LP855X=m
 CONFIG_LOGO=y
@@ -949,7 +935,7 @@ CONFIG_SND_SOC_TEGRA210_AMX=m
 CONFIG_SND_SOC_TEGRA210_ADX=m
 CONFIG_SND_SOC_TEGRA210_MIXER=m
 CONFIG_SND_SOC_TEGRA_AUDIO_GRAPH_CARD=m
-CONFIG_SND_SOC_DAVINCI_MCASP=m
+CONFIG_SND_SOC_J721E_EVM=m
 CONFIG_SND_SOC_AK4613=m
 CONFIG_SND_SOC_DA7213=m
 CONFIG_SND_SOC_ES7134=m
@@ -958,10 +944,8 @@ CONFIG_SND_SOC_ES8316=m
 CONFIG_SND_SOC_GTM601=m
 CONFIG_SND_SOC_MSM8916_WCD_ANALOG=m
 CONFIG_SND_SOC_MSM8916_WCD_DIGITAL=m
-CONFIG_SND_SOC_PCM3168A_I2C=m
 CONFIG_SND_SOC_RK817=m
 CONFIG_SND_SOC_RT5640=m
-CONFIG_SND_SOC_J721E_EVM=m
 CONFIG_SND_SOC_RT5659=m
 CONFIG_SND_SOC_SIMPLE_AMPLIFIER=m
 CONFIG_SND_SOC_SIMPLE_MUX=m
@@ -980,8 +964,6 @@ CONFIG_SND_SOC_WSA881X=m
 CONFIG_SND_SOC_NAU8822=m
 CONFIG_SND_SOC_LPASS_WSA_MACRO=m
 CONFIG_SND_SOC_LPASS_VA_MACRO=m
-CONFIG_SND_SOC_LPASS_RX_MACRO=m
-CONFIG_SND_SOC_LPASS_TX_MACRO=m
 CONFIG_SND_SIMPLE_CARD=m
 CONFIG_SND_AUDIO_GRAPH_CARD=m
 CONFIG_SND_AUDIO_GRAPH_CARD2=m
@@ -1047,14 +1029,15 @@ CONFIG_TYPEC=m
 CONFIG_TYPEC_TCPM=m
 CONFIG_TYPEC_TCPCI=m
 CONFIG_TYPEC_FUSB302=m
-CONFIG_TYPEC_TPS6598X=m
-CONFIG_TYPEC_HD3SS3220=m
 CONFIG_TYPEC_QCOM_PMIC=m
 CONFIG_TYPEC_UCSI=m
-CONFIG_TYPEC_MUX_FSA4480=m
-CONFIG_TYPEC_MUX_NB7VPQ904M=m
 CONFIG_UCSI_CCG=m
+CONFIG_UCSI_PMIC_GLINK=m
+CONFIG_TYPEC_TPS6598X=m
+CONFIG_TYPEC_HD3SS3220=m
+CONFIG_TYPEC_MUX_FSA4480=m
 CONFIG_TYPEC_MUX_GPIO_SBU=m
+CONFIG_TYPEC_MUX_NB7VPQ904M=m
 CONFIG_TYPEC_DP_ALTMODE=m
 CONFIG_MMC=y
 CONFIG_MMC_BLOCK_MINORS=32
@@ -1185,7 +1168,6 @@ CONFIG_CROS_EC_RPMSG=m
 CONFIG_CROS_EC_SPI=y
 CONFIG_CROS_EC_CHARDEV=m
 CONFIG_COMMON_CLK_RK808=y
-CONFIG_COMMON_CLK_SCMI=y
 CONFIG_COMMON_CLK_SCPI=y
 CONFIG_COMMON_CLK_CS2000_CP=y
 CONFIG_COMMON_CLK_FSL_SAI=y
@@ -1203,18 +1185,6 @@ CONFIG_CLK_IMX8QXP=y
 CONFIG_CLK_IMX8ULP=y
 CONFIG_CLK_IMX93=y
 CONFIG_TI_SCI_CLK=y
-CONFIG_COMMON_CLK_MT8192_AUDSYS=y
-CONFIG_COMMON_CLK_MT8192_CAMSYS=y
-CONFIG_COMMON_CLK_MT8192_IMGSYS=y
-CONFIG_COMMON_CLK_MT8192_IMP_IIC_WRAP=y
-CONFIG_COMMON_CLK_MT8192_IPESYS=y
-CONFIG_COMMON_CLK_MT8192_MDPSYS=y
-CONFIG_COMMON_CLK_MT8192_MFGCFG=y
-CONFIG_COMMON_CLK_MT8192_MMSYS=y
-CONFIG_COMMON_CLK_MT8192_MSDC=y
-CONFIG_COMMON_CLK_MT8192_SCP_ADSP=y
-CONFIG_COMMON_CLK_MT8192_VDECSYS=y
-CONFIG_COMMON_CLK_MT8192_VENCSYS=y
 CONFIG_COMMON_CLK_QCOM=y
 CONFIG_QCOM_A53PLL=y
 CONFIG_QCOM_CLK_APCS_MSM8916=y
@@ -1222,24 +1192,23 @@ CONFIG_QCOM_CLK_APCC_MSM8996=y
 CONFIG_QCOM_CLK_SMD_RPM=y
 CONFIG_QCOM_CLK_RPMH=y
 CONFIG_IPQ_APSS_6018=y
-CONFIG_IPQ_GCC_5332=y
-CONFIG_IPQ_APSS_5018=y
 CONFIG_IPQ_GCC_5018=y
+CONFIG_IPQ_GCC_5332=y
 CONFIG_IPQ_GCC_6018=y
 CONFIG_IPQ_GCC_8074=y
 CONFIG_IPQ_GCC_9574=y
 CONFIG_MSM_GCC_8916=y
+CONFIG_MSM_MMCC_8994=m
 CONFIG_MSM_GCC_8994=y
 CONFIG_MSM_GCC_8996=y
-CONFIG_MSM_MMCC_8994=m
 CONFIG_MSM_MMCC_8996=m
-CONFIG_MSM_MMCC_8998=m
 CONFIG_MSM_GCC_8998=y
+CONFIG_MSM_MMCC_8998=m
 CONFIG_QCM_GCC_2290=y
 CONFIG_QCM_DISPCC_2290=m
 CONFIG_QCS_GCC_404=y
-CONFIG_SA_GCC_8775P=y
 CONFIG_SC_DISPCC_8280XP=m
+CONFIG_SA_GCC_8775P=y
 CONFIG_SA_GPUCC_8775P=m
 CONFIG_SC_GCC_7180=y
 CONFIG_SC_GCC_7280=y
@@ -1261,10 +1230,10 @@ CONFIG_SM_GCC_6115=y
 CONFIG_SM_GCC_8350=y
 CONFIG_SM_GCC_8450=y
 CONFIG_SM_GCC_8550=y
-CONFIG_SM_TCSRCC_8550=y
 CONFIG_SM_GPUCC_6115=m
 CONFIG_SM_GPUCC_8150=y
 CONFIG_SM_GPUCC_8250=y
+CONFIG_SM_TCSRCC_8550=y
 CONFIG_SM_VIDEOCC_8250=y
 CONFIG_QCOM_HFPLL=y
 CONFIG_CLK_GFM_LPASS_SM8250=m
@@ -1275,7 +1244,6 @@ CONFIG_TEGRA186_TIMER=y
 CONFIG_RENESAS_OSTM=y
 CONFIG_ARM_MHU=y
 CONFIG_IMX_MBOX=y
-CONFIG_OMAP2PLUS_MBOX=m
 CONFIG_PLATFORM_MHU=y
 CONFIG_BCM2835_MBOX=y
 CONFIG_QCOM_APCS_IPC=y
@@ -1288,14 +1256,14 @@ CONFIG_MTK_IOMMU=y
 CONFIG_QCOM_IOMMU=y
 CONFIG_REMOTEPROC=y
 CONFIG_IMX_REMOTEPROC=y
-CONFIG_TI_K3_R5_REMOTEPROC=m
-CONFIG_TI_K3_DSP_REMOTEPROC=m
 CONFIG_MTK_SCP=m
 CONFIG_QCOM_Q6V5_ADSP=m
 CONFIG_QCOM_Q6V5_MSS=m
 CONFIG_QCOM_Q6V5_PAS=m
 CONFIG_QCOM_SYSMON=m
 CONFIG_QCOM_WCNSS_PIL=m
+CONFIG_TI_K3_DSP_REMOTEPROC=m
+CONFIG_TI_K3_R5_REMOTEPROC=m
 CONFIG_RPMSG_CHAR=m
 CONFIG_RPMSG_CTRL=m
 CONFIG_RPMSG_QCOM_GLINK_RPM=y
@@ -1304,8 +1272,6 @@ CONFIG_RPMSG_QCOM_SMD=y
 CONFIG_RPMSG_VIRTIO=y
 CONFIG_SOUNDWIRE=m
 CONFIG_SOUNDWIRE_QCOM=m
-CONFIG_OWL_PM_DOMAINS=y
-CONFIG_RASPBERRYPI_POWER=y
 CONFIG_FSL_DPAA=y
 CONFIG_FSL_MC_DPIO=y
 CONFIG_FSL_RCPM=y
@@ -1315,15 +1281,12 @@ CONFIG_MTK_PMIC_WRAP=y
 CONFIG_MTK_SVS=m
 CONFIG_QCOM_AOSS_QMP=y
 CONFIG_QCOM_COMMAND_DB=y
-CONFIG_QCOM_CPR=y
 CONFIG_QCOM_GENI_SE=y
 CONFIG_QCOM_LLCC=m
 CONFIG_QCOM_OCMEM=m
 CONFIG_QCOM_PMIC_GLINK=m
 CONFIG_QCOM_RMTFS_MEM=m
 CONFIG_QCOM_RPMH=y
-CONFIG_QCOM_RPMHPD=y
-CONFIG_QCOM_RPMPD=y
 CONFIG_QCOM_SMEM=y
 CONFIG_QCOM_SMD_RPM=y
 CONFIG_QCOM_SMP2P=y
@@ -1355,14 +1318,20 @@ CONFIG_ARCH_R9A07G054=y
 CONFIG_ARCH_R9A08G045=y
 CONFIG_ARCH_R9A09G011=y
 CONFIG_ROCKCHIP_IODOMAIN=y
-CONFIG_ROCKCHIP_PM_DOMAINS=y
 CONFIG_ARCH_TEGRA_132_SOC=y
 CONFIG_ARCH_TEGRA_210_SOC=y
 CONFIG_ARCH_TEGRA_186_SOC=y
 CONFIG_ARCH_TEGRA_194_SOC=y
 CONFIG_ARCH_TEGRA_234_SOC=y
-CONFIG_TI_SCI_PM_DOMAINS=y
 CONFIG_TI_PRUSS=m
+CONFIG_OWL_PM_DOMAINS=y
+CONFIG_RASPBERRYPI_POWER=y
+CONFIG_IMX_SCU_PD=y
+CONFIG_QCOM_CPR=y
+CONFIG_QCOM_RPMHPD=y
+CONFIG_QCOM_RPMPD=y
+CONFIG_ROCKCHIP_PM_DOMAINS=y
+CONFIG_TI_SCI_PM_DOMAINS=y
 CONFIG_ARM_IMX_BUS_DEVFREQ=y
 CONFIG_ARM_IMX8M_DDRC_DEVFREQ=m
 CONFIG_ARM_MEDIATEK_CCI_DEVFREQ=m
@@ -1430,17 +1399,17 @@ CONFIG_PHY_HISI_INNO_USB2=y
 CONFIG_PHY_MVEBU_CP110_COMPHY=y
 CONFIG_PHY_MTK_TPHY=y
 CONFIG_PHY_QCOM_EDP=m
-CONFIG_PHY_QCOM_EUSB2_REPEATER=m
 CONFIG_PHY_QCOM_PCIE2=m
 CONFIG_PHY_QCOM_QMP=m
 CONFIG_PHY_QCOM_QUSB2=m
 CONFIG_PHY_QCOM_SNPS_EUSB2=m
+CONFIG_PHY_QCOM_EUSB2_REPEATER=m
+CONFIG_PHY_QCOM_M31_USB=m
 CONFIG_PHY_QCOM_USB_HS=m
 CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2=m
 CONFIG_PHY_QCOM_USB_HS_28NM=m
 CONFIG_PHY_QCOM_USB_SS=m
 CONFIG_PHY_QCOM_SGMII_ETH=m
-CONFIG_PHY_QCOM_M31_USB=m
 CONFIG_PHY_R8A779F0_ETHERNET_SERDES=y
 CONFIG_PHY_RCAR_GEN3_PCIE=y
 CONFIG_PHY_RCAR_GEN3_USB2=y
@@ -1462,7 +1431,6 @@ CONFIG_PHY_J721E_WIZ=m
 CONFIG_ARM_CCI_PMU=m
 CONFIG_ARM_CCN=m
 CONFIG_ARM_CMN=m
-CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
 CONFIG_ARM_SMMU_V3_PMU=m
 CONFIG_ARM_DSU_PMU=m
 CONFIG_FSL_IMX8_DDR_PMU=m
@@ -1471,6 +1439,7 @@ CONFIG_QCOM_L3_PMU=y
 CONFIG_ARM_SPE_PMU=m
 CONFIG_ARM_DMC620_PMU=m
 CONFIG_HISI_PMU=y
+CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
 CONFIG_MESON_DDR_PMU=m
 CONFIG_NVMEM_LAYOUT_SL28_VPD=m
 CONFIG_NVMEM_IMX_OCOTP=y
@@ -1498,10 +1467,8 @@ CONFIG_TEE=y
 CONFIG_OPTEE=y
 CONFIG_MUX_GPIO=m
 CONFIG_MUX_MMIO=y
-CONFIG_SLIMBUS=m
 CONFIG_SLIM_QCOM_CTRL=m
 CONFIG_SLIM_QCOM_NGD_CTRL=m
-CONFIG_INTERCONNECT=y
 CONFIG_INTERCONNECT_IMX=y
 CONFIG_INTERCONNECT_IMX8MM=m
 CONFIG_INTERCONNECT_IMX8MN=m
@@ -1544,8 +1511,8 @@ CONFIG_OVERLAY_FS=m
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS_POSIX_ACL=y
 CONFIG_HUGETLBFS=y
-CONFIG_CONFIGFS_FS=y
 CONFIG_EFIVAR_FS=y
+CONFIG_UBIFS_FS=m
 CONFIG_SQUASHFS=y
 CONFIG_NFS_FS=y
 CONFIG_NFS_V4=y
@@ -1593,7 +1560,6 @@ CONFIG_DEBUG_INFO_REDUCED=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
 # CONFIG_SCHED_DEBUG is not set
-# CONFIG_DEBUG_PREEMPT is not set
 # CONFIG_FTRACE is not set
 CONFIG_CORESIGHT=m
 CONFIG_CORESIGHT_LINK_AND_SINK_TMC=m
-- 
2.43.0.472.g3155946c3a-goog



From ryan.roberts at arm.com  Thu Dec 14 02:54:19 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 14 Dec 2023 10:54:19 +0000
Subject: [PATCH v9 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <cb1fe352-ca47-4c3b-ab51-ecf51a83ce50@moroto.mountain>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207161211.2374093-5-ryan.roberts@arm.com>
 <cb1fe352-ca47-4c3b-ab51-ecf51a83ce50@moroto.mountain>
Message-ID: <43a8bfff-f939-4f2d-a8cd-97306d5e44c9@arm.com>

On 13/12/2023 07:21, Dan Carpenter wrote:
> On Thu, Dec 07, 2023 at 04:12:05PM +0000, Ryan Roberts wrote:
>> @@ -4176,10 +4260,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>  	/* Allocate our own private page. */
>>  	if (unlikely(anon_vma_prepare(vma)))
>>  		goto oom;
>> -	folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
>> +	folio = alloc_anon_folio(vmf);
>> +	if (IS_ERR(folio))
>> +		return 0;
>>  	if (!folio)
>>  		goto oom;
> 
> Returning zero is weird.  I think it should be a vm_fault_t code.

It's the same pattern that the existing code a little further down this function
already implements:

	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
	if (!vmf->pte)
		goto release;

If we fail to map/lock the pte (due to a race), then we return 0 to allow user
space to rerun the faulting instruction and cause the fault to happen again. The
above code ends up calling "return ret;" and ret is 0.

> 
> This mixing of error pointers and NULL is going to cause problems.
> Normally when we have a mix of error pointers and NULL then the NULL is
> not an error but instead means that the feature has been deliberately
> turned off.  I'm unable to figure out what the meaning is here.

There are 3 conditions that the function can return:

 - folio successfully allocated
 - folio failed to be allocated due to OOM
 - fault needs to be tried again due to losing race

Previously only the first 2 conditions were possible and they were indicated by
NULL/not-NULL. The new 3rd condition is only possible when THP is compile-time
enabled. So it keeps the logic simpler to keep the NULL/not-NULL distinction for
the first 2, and use the error code for the final one.

There are IS_ERR() and IS_ERR_OR_NULL() variants so I assume a pattern where you
can have pointer, error or NULL is somewhat common already?

Thanks,
Ryan

> 
> It should return one or the other, or if it's a mix then add a giant
> comment explaining what they mean.
> 
> regards,
> dan carpenter
> 
>>  
>> +	nr_pages = folio_nr_pages(folio);
>> +	addr = ALIGN_DOWN(vmf->address, nr_pages * PAGE_SIZE);
>> +
>>  	if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
>>  		goto oom_free_page;
>>  	folio_throttle_swaprate(folio, GFP_KERNEL);
> 



From angelogioacchino.delregno at collabora.com  Thu Dec 14 02:55:34 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 14 Dec 2023 11:55:34 +0100
Subject: [PATCH v1 2/6] arm: arm64: dts: Enable cros-ec-spi as wake source
In-Reply-To: <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid>
References: <20231213110009.v1.1.Ifd0903f1c351e84376d71dbdadbd43931197f5ea@changeid>
 <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid>
Message-ID: <e5625051-e9e2-4a75-a11a-cf5b40606fa4@collabora.com>

Il 13/12/23 19:00, Mark Hasemeyer ha scritto:
> The cros_ec driver currently assumes that cros-ec-spi compatible device
> nodes are a wakeup-source even though the wakeup-source property is not
> defined.
> 
> Add the wakeup-source property to all cros-ec-spi compatible device
> nodes to match expected behavior.
> 
> Signed-off-by: Mark Hasemeyer <markhas at chromium.org>

I received only patch [2/6] - please send the entire series to the relevant
maintainers, as otherwise it's difficult to understand what's going on.

As for this patch alone:
  1. arch/arm stuff goes to a different commit
  2. I would prefer if you split per-arch and per-SoC.

Regards,
Angelo




From broonie at kernel.org  Thu Dec 14 02:58:54 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 14 Dec 2023 10:58:54 +0000
Subject: [PATCH] spi: stm32: use runtime PM to enable/disable controller
In-Reply-To: <20231204202055.2895125-1-ben.wolsieffer@hefring.com>
References: <20231204202055.2895125-1-ben.wolsieffer@hefring.com>
Message-ID: <58897511-3187-4583-bf29-11871dd4d136@sirena.org.uk>

On Mon, Dec 04, 2023 at 03:20:55PM -0500, Ben Wolsieffer wrote:
> Instead of disabling the SPI controller between each message, do it
> as part of runtime PM.

This doesn't apply against current code, please check and resend.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/ef5c83e1/attachment.sig>

From vincent.guittot at linaro.org  Thu Dec 14 03:06:23 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 14 Dec 2023 12:06:23 +0100
Subject: [PATCH 1/4] cpufreq: Add a cpufreq pressure feedback for the scheduler
In-Reply-To: <af7b67d1-c4a3-44e3-a632-5f0a4ea6eb25@arm.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-2-vincent.guittot@linaro.org> <af7b67d1-c4a3-44e3-a632-5f0a4ea6eb25@arm.com>
Message-ID: <CAKfTPtApsWeEbbV03sx8vQTGc3i+oFsAWRNsLnyHjYCSrRMqhg@mail.gmail.com>

On Thu, 14 Dec 2023 at 10:20, Lukasz Luba <lukasz.luba at arm.com> wrote:
>
>
>
> On 12/12/23 14:27, Vincent Guittot wrote:
> > Provide to the scheduler a feedback about the temporary max available
> > capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
> > filtered as the pressure will happen for dozens ms or more.
> >
> > Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> > ---
> >   drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++++++++++++++++++++++++
> >   include/linux/cpufreq.h   | 10 ++++++++
> >   2 files changed, 58 insertions(+)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 44db4f59c4cc..7d5f71be8d29 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2563,6 +2563,50 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
> >   }
> >   EXPORT_SYMBOL(cpufreq_get_policy);
> >
> > +DEFINE_PER_CPU(unsigned long, cpufreq_pressure);
> > +EXPORT_PER_CPU_SYMBOL_GPL(cpufreq_pressure);
>
> Why do we export this variable when we have get/update functions?
> Do we expect modules would manipulate those per-cpu variables
> independently and not like we do per-cpumask in the update func.?

No, I will remove the EXPORT_PER_CPU_SYMBOL_GPL


From glider at google.com  Thu Dec 14 03:06:32 2023
From: glider at google.com (Alexander Potapenko)
Date: Thu, 14 Dec 2023 12:06:32 +0100
Subject: [PATCH v10-mte 0/7] Implement MTE tag compression for swapped pages
Message-ID: <20231214110639.2294687-1-glider@google.com>

Currently, when MTE pages are swapped out, the tags are kept in the
memory, occupying PAGE_SIZE/32 bytes per page. This is especially
problematic for devices that use zram-backed in-memory swap, because
tags stored uncompressed in the heap effectively reduce the available
amount of swap memory.

The RLE-based algorithm suggested by Evgenii Stepanov and implemented in
this patch series is able to efficiently compress fixed-size tag buffers,
resulting in practical compression ratio of 2x. In many cases it is
possible to store the compressed data in 63-bit Xarray values, resulting
in no extra memory allocations.

To implement compression/decompression, we also extend <linux/bitmap.h>
with methods to read/write bit values at arbitrary places in the map.

This patch series depends on "lib/bitmap: add bitmap_{read,write}()"
(https://lore.kernel.org/linux-arm-kernel/20231030153210.139512-1-glider at google.com/T/)
that is mailed separately.

v10-mte:
 - add the bitmap_read()/bitmap_write() patches
   (https://lore.kernel.org/lkml/20231109151106.2385155-1-glider at google.com/)
   back to this series
 - add Acked-by: tags to MTE patches

v9:
 - split off the stats collection code into a separate patch in the
   series (as suggested by Yury Norov)

v8:
 - split off the bitmap_read()/bitmap_write() series
 - simplified the compression logic (only compress data if it fits into
   a pointer)

v7:
 - fixed comments by Yury Norov, Andy Shevchenko, Rasmus Villemoes
 - added perf tests for bitmap_read()/bitmap_write()
 - more efficient bitmap_write() implementation (meant to be sent in v5)

v6:
 - fixed comments by Yury Norov
 - fixed handling of sizes divisible by MTE_GRANULES_PER_PAGE / 2
   (caught while testing on a real device)

v5:
 - fixed comments by Andy Shevchenko, Catalin Marinas, and Yury Norov
 - added support for 16K- and 64K pages
 - more efficient bitmap_write() implementation

v4:
 - fixed a bunch of comments by Andy Shevchenko and Yury Norov
 - added Documentation/arch/arm64/mte-tag-compression.rst

v3:
 - as suggested by Andy Shevchenko, use
   bitmap_get_value()/bitmap_set_value() written by Syed Nayyar Waris
 - switched to unsigned long to reduce typecasts
 - simplified the compression code

v2:
 - as suggested by Yuri Norov, replace the poorly implemented struct
   bitq with <linux/bitmap.h>


Alexander Potapenko (6):
  lib/test_bitmap: add tests for bitmap_{read,write}()
  lib/test_bitmap: use pr_info() for non-error messages
  arm64: mte: implement CONFIG_ARM64_MTE_COMP
  arm64: mte: add a test for MTE tags compression
  arm64: mte: add compression support to mteswap.c
  arm64: mte: implement CONFIG_ARM64_MTE_SWAP_STATS

Syed Nayyar Waris (1):
  lib/bitmap: add bitmap_{read,write}()

 Documentation/arch/arm64/index.rst            |   1 +
 .../arch/arm64/mte-tag-compression.rst        | 166 ++++++++
 arch/arm64/Kconfig                            |  37 ++
 arch/arm64/include/asm/mtecomp.h              |  39 ++
 arch/arm64/mm/Makefile                        |   2 +
 arch/arm64/mm/mtecomp.c                       | 257 +++++++++++++
 arch/arm64/mm/mtecomp.h                       |  12 +
 arch/arm64/mm/mteswap.c                       | 110 +++++-
 arch/arm64/mm/test_mtecomp.c                  | 364 ++++++++++++++++++
 include/linux/bitmap.h                        |  77 ++++
 lib/test_bitmap.c                             | 185 ++++++++-
 11 files changed, 1237 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/arch/arm64/mte-tag-compression.rst
 create mode 100644 arch/arm64/include/asm/mtecomp.h
 create mode 100644 arch/arm64/mm/mtecomp.c
 create mode 100644 arch/arm64/mm/mtecomp.h
 create mode 100644 arch/arm64/mm/test_mtecomp.c

-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Thu Dec 14 03:06:33 2023
From: glider at google.com (Alexander Potapenko)
Date: Thu, 14 Dec 2023 12:06:33 +0100
Subject: [PATCH v10-mte 1/7] lib/bitmap: add bitmap_{read,write}()
In-Reply-To: <20231214110639.2294687-1-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
Message-ID: <20231214110639.2294687-2-glider@google.com>

From: Syed Nayyar Waris <syednwaris at gmail.com>

The two new functions allow reading/writing values of length up to
BITS_PER_LONG bits at arbitrary position in the bitmap.

The code was taken from "bitops: Introduce the for_each_set_clump macro"
by Syed Nayyar Waris with a number of changes and simplifications:
 - instead of using roundup(), which adds an unnecessary dependency
   on <linux/math.h>, we calculate space as BITS_PER_LONG-offset;
 - indentation is reduced by not using else-clauses (suggested by
   checkpatch for bitmap_get_value());
 - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read()
   and bitmap_write();
 - some redundant computations are omitted.

Cc: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
Signed-off-by: William Breathitt Gray <william.gray at linaro.org>
Link: https://lore.kernel.org/lkml/fe12eedf3666f4af5138de0e70b67a07c7f40338.1592224129.git.syednwaris at gmail.com/
Suggested-by: Yury Norov <yury.norov at gmail.com>
Co-developed-by: Alexander Potapenko <glider at google.com>
Signed-off-by: Alexander Potapenko <glider at google.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

---

v10-mte:
 - send this patch together with the "Implement MTE tag compression for
   swapped pages"

Revisions v8-v12 of bitmap patches were reviewed separately from the
"Implement MTE tag compression for swapped pages" series
(https://lore.kernel.org/lkml/20231109151106.2385155-1-glider at google.com/)

This patch was previously called "lib/bitmap: add
bitmap_{set,get}_value()"
(https://lore.kernel.org/lkml/20230720173956.3674987-2-glider at google.com/)

v11:
 - rearrange whitespace as requested by Andy Shevchenko,
   add Reviewed-by:, update a comment

v10:
 - update comments as requested by Andy Shevchenko

v8:
 - as suggested by Andy Shevchenko, handle reads/writes of more than
   BITS_PER_LONG bits, add a note for 32-bit systems

v7:
 - Address comments by Yury Norov, Andy Shevchenko, Rasmus Villemoes:
   - update code comments;
   - get rid of GENMASK();
   - s/assign_bit/__assign_bit;
   - more vertical whitespace for better readability;
 - more compact code for bitmap_write() (now for real)

v6:
 - As suggested by Yury Norov, do not require bitmap_read(..., 0) to
   return 0.

v5:
 - Address comments by Yury Norov:
   - updated code comments and patch title/description
   - replace GENMASK(nbits - 1, 0) with BITMAP_LAST_WORD_MASK(nbits)
   - more compact bitmap_write() implementation

v4:
 - Address comments by Andy Shevchenko and Yury Norov:
   - prevent passing values >= 64 to GENMASK()
   - fix commit authorship
   - change comments
   - check for unlikely(nbits==0)
   - drop unnecessary const declarations
   - fix kernel-doc comments
   - rename bitmap_{get,set}_value() to bitmap_{read,write}()
---
 include/linux/bitmap.h | 77 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 99451431e4d65..7ca0379be8c13 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -79,6 +79,10 @@ struct device;
  *  bitmap_to_arr64(buf, src, nbits)            Copy nbits from buf to u64[] dst
  *  bitmap_get_value8(map, start)               Get 8bit value from map at start
  *  bitmap_set_value8(map, value, start)        Set 8bit value to map at start
+ *  bitmap_read(map, start, nbits)              Read an nbits-sized value from
+ *                                              map at start
+ *  bitmap_write(map, value, start, nbits)      Write an nbits-sized value to
+ *                                              map at start
  *
  * Note, bitmap_zero() and bitmap_fill() operate over the region of
  * unsigned longs, that is, bits behind bitmap till the unsigned long
@@ -636,6 +640,79 @@ static inline void bitmap_set_value8(unsigned long *map, unsigned long value,
 	map[index] |= value << offset;
 }
 
+/**
+ * bitmap_read - read a value of n-bits from the memory region
+ * @map: address to the bitmap memory region
+ * @start: bit offset of the n-bit value
+ * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG
+ *
+ * Returns: value of @nbits bits located at the @start bit offset within the
+ * @map memory region. For @nbits = 0 and @nbits > BITS_PER_LONG the return
+ * value is undefined.
+ */
+static inline unsigned long bitmap_read(const unsigned long *map,
+					unsigned long start,
+					unsigned long nbits)
+{
+	size_t index = BIT_WORD(start);
+	unsigned long offset = start % BITS_PER_LONG;
+	unsigned long space = BITS_PER_LONG - offset;
+	unsigned long value_low, value_high;
+
+	if (unlikely(!nbits || nbits > BITS_PER_LONG))
+		return 0;
+
+	if (space >= nbits)
+		return (map[index] >> offset) & BITMAP_LAST_WORD_MASK(nbits);
+
+	value_low = map[index] & BITMAP_FIRST_WORD_MASK(start);
+	value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start + nbits);
+	return (value_low >> offset) | (value_high << space);
+}
+
+/**
+ * bitmap_write - write n-bit value within a memory region
+ * @map: address to the bitmap memory region
+ * @value: value to write, clamped to nbits
+ * @start: bit offset of the n-bit value
+ * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG.
+ *
+ * bitmap_write() behaves as-if implemented as @nbits calls of __assign_bit(),
+ * i.e. bits beyond @nbits are ignored:
+ *
+ *   for (bit = 0; bit < nbits; bit++)
+ *           __assign_bit(start + bit, bitmap, val & BIT(bit));
+ *
+ * For @nbits == 0 and @nbits > BITS_PER_LONG no writes are performed.
+ */
+static inline void bitmap_write(unsigned long *map, unsigned long value,
+				unsigned long start, unsigned long nbits)
+{
+	size_t index;
+	unsigned long offset;
+	unsigned long space;
+	unsigned long mask;
+	bool fit;
+
+	if (unlikely(!nbits || nbits > BITS_PER_LONG))
+		return;
+
+	mask = BITMAP_LAST_WORD_MASK(nbits);
+	value &= mask;
+	offset = start % BITS_PER_LONG;
+	space = BITS_PER_LONG - offset;
+	fit = space >= nbits;
+	index = BIT_WORD(start);
+
+	map[index] &= (fit ? (~(mask << offset)) : ~BITMAP_FIRST_WORD_MASK(start));
+	map[index] |= value << offset;
+	if (fit)
+		return;
+
+	map[index + 1] &= BITMAP_FIRST_WORD_MASK(start + nbits);
+	map[index + 1] |= (value >> space);
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __LINUX_BITMAP_H */
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Thu Dec 14 03:06:34 2023
From: glider at google.com (Alexander Potapenko)
Date: Thu, 14 Dec 2023 12:06:34 +0100
Subject: [PATCH v10-mte 2/7] lib/test_bitmap: add tests for bitmap_{read,write}()
In-Reply-To: <20231214110639.2294687-1-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
Message-ID: <20231214110639.2294687-3-glider@google.com>

Add basic tests ensuring that values can be added at arbitrary positions
of the bitmap, including those spanning into the adjacent unsigned
longs.

Two new performance tests, test_bitmap_read_perf() and
test_bitmap_write_perf(), can be used to assess future performance
improvements of bitmap_read() and bitmap_write():

[    0.431119][    T1] test_bitmap: Time spent in test_bitmap_read_perf:	615253
[    0.433197][    T1] test_bitmap: Time spent in test_bitmap_write_perf:	916313

(numbers from a Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz machine running
QEMU).

Signed-off-by: Alexander Potapenko <glider at google.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

---
v10-mte:
 - send this patch together with the "Implement MTE tag compression for
   swapped pages"

Revisions v8-v12 of bitmap patches were reviewed separately from the
"Implement MTE tag compression for swapped pages" series
(https://lore.kernel.org/lkml/20231109151106.2385155-1-glider at google.com/)

This patch was previously called
"lib/test_bitmap: add tests for bitmap_{set,get}_value()"
(https://lore.kernel.org/lkml/20230720173956.3674987-3-glider at google.com/)
and
"lib/test_bitmap: add tests for bitmap_{set,get}_value_unaligned"
(https://lore.kernel.org/lkml/20230713125706.2884502-3-glider at google.com/)

v12:
 - as suggested by Alexander Lobakin, replace expect_eq_uint() with
   expect_eq_ulong() and a cast

v9:
 - use WRITE_ONCE() to prevent optimizations in test_bitmap_read_perf()
 - update patch description

v8:
 - as requested by Andy Shevchenko, add tests for reading/writing
   sizes > BITS_PER_LONG

v7:
 - as requested by Yury Norov, add performance tests for bitmap_read()
   and bitmap_write()

v6:
 - use bitmap API to initialize test bitmaps
 - as requested by Yury Norov, do not check the return value of
   bitmap_read(..., 0)
 - fix a compiler warning on 32-bit systems

v5:
 - update patch title
 - address Yury Norov's comments:
   - rename the test cases
   - factor out test_bitmap_write_helper() to test writing over
     different background patterns;
   - add a test case copying a nontrivial value bit-by-bit;
   - drop volatile

v4:
 - Address comments by Andy Shevchenko: added Reviewed-by: and a link to
   the previous discussion
 - Address comments by Yury Norov:
   - expand the bitmap to catch more corner cases
   - add code testing that bitmap_set_value() does not touch adjacent
     bits
   - add code testing the nbits==0 case
   - rename bitmap_{get,set}_value() to bitmap_{read,write}()

v3:
 - switch to using bitmap_{set,get}_value()
 - change the expected bit pattern in test_set_get_value(),
   as the test was incorrectly assuming 0 is the LSB.
---
 lib/test_bitmap.c | 179 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 172 insertions(+), 7 deletions(-)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 65f22c2578b06..46c0154680772 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -60,18 +60,17 @@ static const unsigned long exp3_1_0[] __initconst = {
 };
 
 static bool __init
-__check_eq_uint(const char *srcfile, unsigned int line,
-		const unsigned int exp_uint, unsigned int x)
+__check_eq_ulong(const char *srcfile, unsigned int line,
+		 const unsigned long exp_ulong, unsigned long x)
 {
-	if (exp_uint != x) {
-		pr_err("[%s:%u] expected %u, got %u\n",
-			srcfile, line, exp_uint, x);
+	if (exp_ulong != x) {
+		pr_err("[%s:%u] expected %lu, got %lu\n",
+			srcfile, line, exp_ulong, x);
 		return false;
 	}
 	return true;
 }
 
-
 static bool __init
 __check_eq_bitmap(const char *srcfile, unsigned int line,
 		  const unsigned long *exp_bmap, const unsigned long *bmap,
@@ -185,7 +184,8 @@ __check_eq_str(const char *srcfile, unsigned int line,
 		result;							\
 	})
 
-#define expect_eq_uint(...)		__expect_eq(uint, ##__VA_ARGS__)
+#define expect_eq_ulong(...)		__expect_eq(ulong, ##__VA_ARGS__)
+#define expect_eq_uint(x, y)		expect_eq_ulong((unsigned int)(x), (unsigned int)(y))
 #define expect_eq_bitmap(...)		__expect_eq(bitmap, ##__VA_ARGS__)
 #define expect_eq_pbl(...)		__expect_eq(pbl, ##__VA_ARGS__)
 #define expect_eq_u32_array(...)	__expect_eq(u32_array, ##__VA_ARGS__)
@@ -1245,6 +1245,168 @@ static void __init test_bitmap_const_eval(void)
 	BUILD_BUG_ON(~var != ~BIT(25));
 }
 
+/*
+ * Test bitmap should be big enough to include the cases when start is not in
+ * the first word, and start+nbits lands in the following word.
+ */
+#define TEST_BIT_LEN (1000)
+
+/*
+ * Helper function to test bitmap_write() overwriting the chosen byte pattern.
+ */
+static void __init test_bitmap_write_helper(const char *pattern)
+{
+	DECLARE_BITMAP(bitmap, TEST_BIT_LEN);
+	DECLARE_BITMAP(exp_bitmap, TEST_BIT_LEN);
+	DECLARE_BITMAP(pat_bitmap, TEST_BIT_LEN);
+	unsigned long w, r, bit;
+	int i, n, nbits;
+
+	/*
+	 * Only parse the pattern once and store the result in the intermediate
+	 * bitmap.
+	 */
+	bitmap_parselist(pattern, pat_bitmap, TEST_BIT_LEN);
+
+	/*
+	 * Check that writing a single bit does not accidentally touch the
+	 * adjacent bits.
+	 */
+	for (i = 0; i < TEST_BIT_LEN; i++) {
+		bitmap_copy(bitmap, pat_bitmap, TEST_BIT_LEN);
+		bitmap_copy(exp_bitmap, pat_bitmap, TEST_BIT_LEN);
+		for (bit = 0; bit <= 1; bit++) {
+			bitmap_write(bitmap, bit, i, 1);
+			__assign_bit(i, exp_bitmap, bit);
+			expect_eq_bitmap(exp_bitmap, bitmap,
+					 TEST_BIT_LEN);
+		}
+	}
+
+	/* Ensure writing 0 bits does not change anything. */
+	bitmap_copy(bitmap, pat_bitmap, TEST_BIT_LEN);
+	bitmap_copy(exp_bitmap, pat_bitmap, TEST_BIT_LEN);
+	for (i = 0; i < TEST_BIT_LEN; i++) {
+		bitmap_write(bitmap, ~0UL, i, 0);
+		expect_eq_bitmap(exp_bitmap, bitmap, TEST_BIT_LEN);
+	}
+
+	for (nbits = BITS_PER_LONG; nbits >= 1; nbits--) {
+		w = IS_ENABLED(CONFIG_64BIT) ? 0xdeadbeefdeadbeefUL
+					     : 0xdeadbeefUL;
+		w >>= (BITS_PER_LONG - nbits);
+		for (i = 0; i <= TEST_BIT_LEN - nbits; i++) {
+			bitmap_copy(bitmap, pat_bitmap, TEST_BIT_LEN);
+			bitmap_copy(exp_bitmap, pat_bitmap, TEST_BIT_LEN);
+			for (n = 0; n < nbits; n++)
+				__assign_bit(i + n, exp_bitmap, w & BIT(n));
+			bitmap_write(bitmap, w, i, nbits);
+			expect_eq_bitmap(exp_bitmap, bitmap, TEST_BIT_LEN);
+			r = bitmap_read(bitmap, i, nbits);
+			expect_eq_ulong(r, w);
+		}
+	}
+}
+
+static void __init test_bitmap_read_write(void)
+{
+	unsigned char *pattern[3] = {"", "all:1/2", "all"};
+	DECLARE_BITMAP(bitmap, TEST_BIT_LEN);
+	unsigned long zero_bits = 0, bits_per_long = BITS_PER_LONG;
+	unsigned long val;
+	int i, pi;
+
+	/*
+	 * Reading/writing zero bits should not crash the kernel.
+	 * READ_ONCE() prevents constant folding.
+	 */
+	bitmap_write(NULL, 0, 0, READ_ONCE(zero_bits));
+	/* Return value of bitmap_read() is undefined here. */
+	bitmap_read(NULL, 0, READ_ONCE(zero_bits));
+
+	/*
+	 * Reading/writing more than BITS_PER_LONG bits should not crash the
+	 * kernel. READ_ONCE() prevents constant folding.
+	 */
+	bitmap_write(NULL, 0, 0, READ_ONCE(bits_per_long) + 1);
+	/* Return value of bitmap_read() is undefined here. */
+	bitmap_read(NULL, 0, READ_ONCE(bits_per_long) + 1);
+
+	/*
+	 * Ensure that bitmap_read() reads the same value that was previously
+	 * written, and two consequent values are correctly merged.
+	 * The resulting bit pattern is asymmetric to rule out possible issues
+	 * with bit numeration order.
+	 */
+	for (i = 0; i < TEST_BIT_LEN - 7; i++) {
+		bitmap_zero(bitmap, TEST_BIT_LEN);
+
+		bitmap_write(bitmap, 0b10101UL, i, 5);
+		val = bitmap_read(bitmap, i, 5);
+		expect_eq_ulong(0b10101UL, val);
+
+		bitmap_write(bitmap, 0b101UL, i + 5, 3);
+		val = bitmap_read(bitmap, i + 5, 3);
+		expect_eq_ulong(0b101UL, val);
+
+		val = bitmap_read(bitmap, i, 8);
+		expect_eq_ulong(0b10110101UL, val);
+	}
+
+	for (pi = 0; pi < ARRAY_SIZE(pattern); pi++)
+		test_bitmap_write_helper(pattern[pi]);
+}
+
+static void __init test_bitmap_read_perf(void)
+{
+	DECLARE_BITMAP(bitmap, TEST_BIT_LEN);
+	unsigned int cnt, nbits, i;
+	unsigned long val;
+	ktime_t time;
+
+	bitmap_fill(bitmap, TEST_BIT_LEN);
+	time = ktime_get();
+	for (cnt = 0; cnt < 5; cnt++) {
+		for (nbits = 1; nbits <= BITS_PER_LONG; nbits++) {
+			for (i = 0; i < TEST_BIT_LEN; i++) {
+				if (i + nbits > TEST_BIT_LEN)
+					break;
+				/*
+				 * Prevent the compiler from optimizing away the
+				 * bitmap_read() by using its value.
+				 */
+				WRITE_ONCE(val, bitmap_read(bitmap, i, nbits));
+			}
+		}
+	}
+	time = ktime_get() - time;
+	pr_err("Time spent in %s:\t%llu\n", __func__, time);
+}
+
+static void __init test_bitmap_write_perf(void)
+{
+	DECLARE_BITMAP(bitmap, TEST_BIT_LEN);
+	unsigned int cnt, nbits, i;
+	unsigned long val = 0xfeedface;
+	ktime_t time;
+
+	bitmap_zero(bitmap, TEST_BIT_LEN);
+	time = ktime_get();
+	for (cnt = 0; cnt < 5; cnt++) {
+		for (nbits = 1; nbits <= BITS_PER_LONG; nbits++) {
+			for (i = 0; i < TEST_BIT_LEN; i++) {
+				if (i + nbits > TEST_BIT_LEN)
+					break;
+				bitmap_write(bitmap, val, i, nbits);
+			}
+		}
+	}
+	time = ktime_get() - time;
+	pr_err("Time spent in %s:\t%llu\n", __func__, time);
+}
+
+#undef TEST_BIT_LEN
+
 static void __init selftest(void)
 {
 	test_zero_clear();
@@ -1261,6 +1423,9 @@ static void __init selftest(void)
 	test_bitmap_cut();
 	test_bitmap_print_buf();
 	test_bitmap_const_eval();
+	test_bitmap_read_write();
+	test_bitmap_read_perf();
+	test_bitmap_write_perf();
 
 	test_find_nth_bit();
 	test_for_each_set_bit();
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Thu Dec 14 03:06:36 2023
From: glider at google.com (Alexander Potapenko)
Date: Thu, 14 Dec 2023 12:06:36 +0100
Subject: [PATCH v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <20231214110639.2294687-1-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
Message-ID: <20231214110639.2294687-5-glider@google.com>

The config implements the algorithm compressing memory tags for ARM MTE
during swapping.

The algorithm is based on RLE and specifically targets buffers of tags
corresponding to a single page. In many cases a buffer can be compressed
into 63 bits, making it possible to store it without additional memory
allocation.

Suggested-by: Evgenii Stepanov <eugenis at google.com>
Signed-off-by: Alexander Potapenko <glider at google.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>

---
 v10-mte:
  - added Catalin's Acked-by:

 v8:
  - As suggested by Catalin Marinas, only compress tags if they can be
    stored inline. This simplifies the code drastically.
  - Update the documentation.
  - Split off patches introducing bitmap_read()/bitmap_write().

 v6:
  - shuffle bits in inline handles so that they can't be confused with
    canonical pointers;
  - use kmem_cache_zalloc() to allocate compressed storage
  - correctly handle range size overflow
  - minor documentation fixes, clarify the special cases

 v5:
  - make code PAGE_SIZE-agnostic, remove hardcoded constants, updated
    the docs
  - implement debugfs interface
  - Address comments by Andy Shevchenko:
    - update description of mtecomp.c
    - remove redundant assignments, simplify mte_tags_to_ranges()
    - various code simplifications
    - introduce mtecomp.h
    - add :export: to Documentation/arch/arm64/mte-tag-compression.rst

 v4:
  - Addressed comments by Andy Shevchenko:
    - expanded "MTE" to "Memory Tagging Extension" in Kconfig
    - fixed kernel-doc comments, moved them to C source
    - changed variables to unsigned where applicable
    - some code simplifications, fewer unnecessary assignments
    - added the mte_largest_idx_bits() helper
    - added namespace prefixes to all functions
    - added missing headers (but removed bits.h)
  - Addressed comments by Yury Norov:
    - removed test-only functions from mtecomp.h
    - dropped the algoritm name (all functions are now prefixed with
      "mte")
    - added more comments
    - got rid of MTE_RANGES_INLINE
    - renamed bitmap_{get,set}_value() to bitmap_{read,write}()
    - moved the big comment explaining the algorithm to
      Documentation/arch/arm64/mte-tag-compression.rst, expanded it,
      add a link to it from Documentation/arch/arm64/index.rst
    - removed hardcoded ranges from mte_alloc_size()/mte_size_to_ranges()

 v3:
  - Addressed comments by Andy Shevchenko:
   - use bitmap_{set,get}_value() writte by Syed Nayyar Waris
   - switched to unsigned long everywhere (fewer casts)
   - simplified the code, removed redundant checks
   - dropped ea0_compress_inline()
 - added bit size constants and helpers to access the bitmap
 - explicitly initialize all compressed sizes in ea0_compress_to_buf()
 - initialize all handle bits

 v2:
  - as suggested by Yury Norov, switched from struct bitq (which is
    not needed anymore) to <linux/bitmap.h>
  - add missing symbol exports
---
 Documentation/arch/arm64/index.rst            |   1 +
 .../arch/arm64/mte-tag-compression.rst        | 154 +++++++++++
 arch/arm64/Kconfig                            |  11 +
 arch/arm64/include/asm/mtecomp.h              |  39 +++
 arch/arm64/mm/Makefile                        |   1 +
 arch/arm64/mm/mtecomp.c                       | 257 ++++++++++++++++++
 arch/arm64/mm/mtecomp.h                       |  12 +
 7 files changed, 475 insertions(+)
 create mode 100644 Documentation/arch/arm64/mte-tag-compression.rst
 create mode 100644 arch/arm64/include/asm/mtecomp.h
 create mode 100644 arch/arm64/mm/mtecomp.c
 create mode 100644 arch/arm64/mm/mtecomp.h

diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
index d08e924204bf1..bf6c1583233a9 100644
--- a/Documentation/arch/arm64/index.rst
+++ b/Documentation/arch/arm64/index.rst
@@ -19,6 +19,7 @@ ARM64 Architecture
     legacy_instructions
     memory
     memory-tagging-extension
+    mte-tag-compression
     perf
     pointer-authentication
     ptdump
diff --git a/Documentation/arch/arm64/mte-tag-compression.rst b/Documentation/arch/arm64/mte-tag-compression.rst
new file mode 100644
index 0000000000000..8fe6b51a9db6d
--- /dev/null
+++ b/Documentation/arch/arm64/mte-tag-compression.rst
@@ -0,0 +1,154 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==================================================
+Tag Compression for Memory Tagging Extension (MTE)
+==================================================
+
+This document describes the algorithm used to compress memory tags used by the
+ARM Memory Tagging Extension (MTE).
+
+Introduction
+============
+
+MTE assigns tags to memory pages: for 4K pages those tags occupy 128 bytes
+(256 4-bit tags each corresponding to a 16-byte MTE granule), for 16K pages -
+512 bytes, for 64K pages - 2048 bytes. By default, MTE carves out 3.125% (1/16)
+of the available physical memory to store the tags.
+
+When MTE pages are saved to swap, their tags need to be stored in the kernel
+memory. If the system swap is used heavily, these tags may take a substantial
+portion of the physical memory. To reduce memory waste, ``CONFIG_ARM64_MTE_COMP``
+allows the kernel to store the tags in compressed form.
+
+Implementation details
+======================
+
+The algorithm attempts to compress an array of ``MTE_PAGE_TAG_STORAGE``
+tag bytes into a byte sequence that can be stored in an 8-byte pointer. If that
+is not possible, the data is stored uncompressed.
+
+Tag manipulation and storage
+----------------------------
+
+Tags for swapped pages are stored in an XArray that maps swap entries to 63-bit
+values (see ``arch/arm64/mm/mteswap.c``). Bit 0 of these values indicates how
+their contents should be treated:
+
+ - 0: value is a pointer to an uncompressed buffer allocated with kmalloc()
+   (always the case if ``CONFIG_ARM64_MTE_COMP=n``) with the highest bit set
+   to 0;
+ - 1: value contains compressed data.
+
+``arch/arm64/include/asm/mtecomp.h`` declares the following functions that
+manipulate with tags:
+
+- mte_compress() - compresses the given ``MTE_PAGE_TAG_STORAGE``-byte ``tags``
+  buffer into a pointer;
+- mte_decompress() - decompresses the tags from a pointer;
+- mte_is_compressed() - returns ``true`` iff the pointer passed to it should be
+  treated as compressed data.
+
+Tag compression
+---------------
+
+The compression algorithm is a variation of RLE (run-length encoding) and works
+as follows (we will be considering 4K pages and 128-byte tag buffers, but the
+same approach scales to 16K and 64K pages):
+
+1. The input array of 128 (``MTE_PAGE_TAG_STORAGE``) bytes is transformed into
+   tag ranges (two arrays: ``r_tags[]`` containing tag values and ``r_sizes[]``
+   containing range lengths) by mte_tags_to_ranges(). Note that
+   ``r_sizes[]`` sums up to 256 (``MTE_GRANULES_PER_PAGE``).
+
+   If ``r_sizes[]`` consists of a single element
+   (``{ MTE_GRANULES_PER_PAGE }``), the corresponding range is split into two
+   halves, i.e.::
+
+     r_sizes_new[2] = { MTE_GRANULES_PER_PAGE/2, MTE_GRANULES_PER_PAGE/2 };
+     r_tags_new[2] = { r_tags[0], r_tags[0] };
+
+2. The number of the largest element of ``r_sizes[]`` is stored in
+   ``largest_idx``. The element itself is thrown away from ``r_sizes[]``,
+   because it can be reconstructed from the sum of the remaining elements. Note
+   that now none of the remaining ``r_sizes[]`` elements exceeds
+   ``MTE_GRANULES_PER_PAGE/2``.
+
+3. If the number ``N`` of ranges does not exceed ``6``, the ranges can be
+   compressed into 64 bits. This is done by storing the following values packed
+   into the pointer (``i<size>`` means a ``<size>``-bit unsigned integer)
+   treated as a bitmap (see ``include/linux/bitmap.h``)::
+
+    bit 0      :      (always 1) : i1
+    bits 1-3   :     largest_idx : i3
+    bits 4-27  :    r_tags[0..5] : i4 x 6
+    bits 28-62 :   r_sizes[0..4] : i7 x 5
+    bit 63     :      (always 0) : i1
+
+   If N is less than 6, ``r_tags`` and ``r_sizes`` are padded up with zero
+   values. The unused bits in the pointer, including bit 63, are also set to 0,
+   so the compressed data can be stored in XArray.
+
+   Range size of ``MTE_GRANULES_PER_PAGE/2`` (at most one) does not fit into
+   i7 and will be written as 0. This case is handled separately by the
+   decompressing procedure.
+
+Tag decompression
+-----------------
+
+The decompression algorithm performs the steps below.
+
+1. Read the lowest bit of the data from the input buffer and check that it is 1,
+   otherwise bail out.
+
+2. Read ``largest_idx``, ``r_tags[]`` and ``r_sizes[]`` from the
+   input buffer.
+
+   If ``largest_idx`` is zero, and all ``r_sizes[]`` are zero, set
+   ``r_sizes[0] = MTE_GRANULES_PER_PAGE/2``.
+
+   Calculate the removed largest element of ``r_sizes[]`` as
+   ``largest = 256 - sum(r_sizes)`` and insert it into ``r_sizes`` at
+   position ``largest_idx``.
+
+6. For each ``r_sizes[i] > 0``, add a 4-bit value ``r_tags[i]`` to the output
+   buffer ``r_sizes[i]`` times.
+
+
+Why these numbers?
+------------------
+
+To be able to reconstruct ``N`` tag ranges from the compressed data, we need to
+store the indicator bit together with ``largest_idx``, ``r_tags[N]``, and
+``r_sizes[N-1]`` in 63 bits.
+Knowing that the sizes do not exceed ``MTE_PAGE_TAG_STORAGE``, each of them can be
+packed into ``S = ilog2(MTE_PAGE_TAG_STORAGE)`` bits, whereas a single tag occupies
+4 bits.
+
+It is evident that the number of ranges that can be stored in 63 bits is
+strictly less than 8, therefore we only need 3 bits to store ``largest_idx``.
+
+The maximum values of ``N`` so that the number ``1 + 3 + N * 4 + (N-1) * S`` of
+storage bits does not exceed 63, are shown in the table below::
+
+ +-----------+-----------------+----+---+-------------------+
+ | Page size | Tag buffer size |  S | N |    Storage bits   |
+ +-----------+-----------------+----+---+-------------------+
+ |      4 KB |           128 B |  7 | 6 | 63 = 1+3+6*4+5*7  |
+ |     16 KB |           512 B |  9 | 5 | 60 = 1+3+5*4+4*9  |
+ |     64 KB |          2048 B | 11 | 4 | 53 = 1+3+4*4+3*11 |
+ +-----------+-----------------+----+---+-------------------+
+
+Note
+----
+
+Tag compression and decompression implicitly rely on the fixed MTE tag size
+(4 bits) and number of tags per page. Should these values change, the algorithm
+may need to be revised.
+
+
+Programming Interface
+=====================
+
+ .. kernel-doc:: arch/arm64/include/asm/mtecomp.h
+ .. kernel-doc:: arch/arm64/mm/mtecomp.c
+   :export:
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d2..5f4d4b49a512e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2078,6 +2078,17 @@ config ARM64_EPAN
 	  if the cpu does not implement the feature.
 endmenu # "ARMv8.7 architectural features"
 
+config ARM64_MTE_COMP
+	bool "Tag compression for ARM64 Memory Tagging Extension"
+	default y
+	depends on ARM64_MTE
+	help
+	  Enable tag compression support for ARM64 Memory Tagging Extension.
+
+	  Tag buffers corresponding to swapped RAM pages are compressed using
+	  RLE to conserve heap memory. In the common case compressed tags
+	  occupy 2.5x less memory.
+
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
diff --git a/arch/arm64/include/asm/mtecomp.h b/arch/arm64/include/asm/mtecomp.h
new file mode 100644
index 0000000000000..b9a3a921a38d4
--- /dev/null
+++ b/arch/arm64/include/asm/mtecomp.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_MTECOMP_H
+#define __ASM_MTECOMP_H
+
+#include <linux/types.h>
+
+/**
+ * mte_is_compressed() - check if the supplied pointer contains compressed tags.
+ * @ptr: pointer returned by kmalloc() or mte_compress().
+ *
+ * Returns: true iff bit 0 of @ptr is 1, which is only possible if @ptr was
+ * returned by mte_is_compressed().
+ */
+static inline bool mte_is_compressed(void *ptr)
+{
+	return ((unsigned long)ptr & 1);
+}
+
+#if defined(CONFIG_ARM64_MTE_COMP)
+
+void *mte_compress(u8 *tags);
+bool mte_decompress(void *handle, u8 *tags);
+
+#else
+
+static inline void *mte_compress(u8 *tags)
+{
+	return NULL;
+}
+
+static inline bool mte_decompress(void *data, u8 *tags)
+{
+	return false;
+}
+
+#endif // CONFIG_ARM64_MTE_COMP
+
+#endif // __ASM_MTECOMP_H
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index dbd1bc95967d0..46778f6dd83c2 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd.o
 obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd-asm.o
 obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o
 obj-$(CONFIG_ARM64_MTE)		+= mteswap.o
+obj-$(CONFIG_ARM64_MTE_COMP)	+= mtecomp.o
 KASAN_SANITIZE_physaddr.o	+= n
 
 obj-$(CONFIG_KASAN)		+= kasan_init.o
diff --git a/arch/arm64/mm/mtecomp.c b/arch/arm64/mm/mtecomp.c
new file mode 100644
index 0000000000000..c948921525030
--- /dev/null
+++ b/arch/arm64/mm/mtecomp.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * MTE tag compression algorithm.
+ * See Documentation/arch/arm64/mte-tag-compression.rst for more details.
+ */
+
+#include <linux/bits.h>
+#include <linux/bitmap.h>
+#include <linux/bitops.h>
+#include <linux/export.h>
+#include <linux/gfp.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+
+#include <asm/mtecomp.h>
+
+#include "mtecomp.h"
+
+#define MTE_BITS_PER_LARGEST_IDX 3
+/* Range size cannot exceed MTE_GRANULES_PER_PAGE / 2. */
+#define MTE_BITS_PER_SIZE (ilog2(MTE_GRANULES_PER_PAGE) - 1)
+
+/*
+ * See Documentation/arch/arm64/mte-tag-compression.rst for details on how the
+ * maximum number of ranges is calculated.
+ */
+#if defined(CONFIG_ARM64_4K_PAGES)
+#define MTE_MAX_RANGES 6
+#elif defined(CONFIG_ARM64_16K_PAGES)
+#define MTE_MAX_RANGES 5
+#else
+#define MTE_MAX_RANGES 4
+#endif
+
+/**
+ * mte_tags_to_ranges() - break @tags into arrays of tag ranges.
+ * @tags: MTE_GRANULES_PER_PAGE-byte array containing MTE tags.
+ * @out_tags: u8 array to store the tag of every range.
+ * @out_sizes: unsigned short array to store the size of every range.
+ * @out_len: length of @out_tags and @out_sizes (output parameter, initially
+ *           equal to lengths of out_tags[] and out_sizes[]).
+ *
+ * This function is exported for testing purposes.
+ */
+void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
+			size_t *out_len)
+{
+	u8 prev_tag = tags[0] / 16; /* First tag in the array. */
+	unsigned int cur_idx = 0, i, j;
+	u8 cur_tag;
+
+	memset(out_tags, 0, array_size(*out_len, sizeof(*out_tags)));
+	memset(out_sizes, 0, array_size(*out_len, sizeof(*out_sizes)));
+
+	out_tags[cur_idx] = prev_tag;
+	for (i = 0; i < MTE_GRANULES_PER_PAGE; i++) {
+		j = i % 2;
+		cur_tag = j ? (tags[i / 2] % 16) : (tags[i / 2] / 16);
+		if (cur_tag == prev_tag) {
+			out_sizes[cur_idx]++;
+		} else {
+			cur_idx++;
+			prev_tag = cur_tag;
+			out_tags[cur_idx] = prev_tag;
+			out_sizes[cur_idx] = 1;
+		}
+	}
+	*out_len = cur_idx + 1;
+}
+EXPORT_SYMBOL_NS(mte_tags_to_ranges, MTECOMP);
+
+/**
+ * mte_ranges_to_tags() - fill @tags using given tag ranges.
+ * @r_tags: u8[] containing the tag of every range.
+ * @r_sizes: unsigned short[] containing the size of every range.
+ * @r_len: length of @r_tags and @r_sizes.
+ * @tags: MTE_GRANULES_PER_PAGE-byte array to write the tags to.
+ *
+ * This function is exported for testing purposes.
+ */
+void mte_ranges_to_tags(u8 *r_tags, unsigned short *r_sizes, size_t r_len,
+			u8 *tags)
+{
+	unsigned int i, j, pos = 0;
+	u8 prev;
+
+	for (i = 0; i < r_len; i++) {
+		for (j = 0; j < r_sizes[i]; j++) {
+			if (pos % 2)
+				tags[pos / 2] = (prev << 4) | r_tags[i];
+			else
+				prev = r_tags[i];
+			pos++;
+		}
+	}
+}
+EXPORT_SYMBOL_NS(mte_ranges_to_tags, MTECOMP);
+
+static void mte_bitmap_write(unsigned long *bitmap, unsigned long value,
+			     unsigned long *pos, unsigned long bits)
+{
+	bitmap_write(bitmap, value, *pos, bits);
+	*pos += bits;
+}
+
+/* Compress ranges into an unsigned long. */
+static void mte_compress_to_ulong(size_t len, u8 *tags, unsigned short *sizes,
+				  unsigned long *result)
+{
+	unsigned long bit_pos = 0;
+	unsigned int largest_idx, i;
+	unsigned short largest = 0;
+
+	for (i = 0; i < len; i++) {
+		if (sizes[i] > largest) {
+			largest = sizes[i];
+			largest_idx = i;
+		}
+	}
+	/* Bit 1 in position 0 indicates compressed data. */
+	mte_bitmap_write(result, 1, &bit_pos, 1);
+	mte_bitmap_write(result, largest_idx, &bit_pos,
+			 MTE_BITS_PER_LARGEST_IDX);
+	for (i = 0; i < len; i++)
+		mte_bitmap_write(result, tags[i], &bit_pos, MTE_TAG_SIZE);
+	if (len == 1) {
+		/*
+		 * We are compressing MTE_GRANULES_PER_PAGE of identical tags.
+		 * Split it into two ranges containing
+		 * MTE_GRANULES_PER_PAGE / 2 tags, so that it falls into the
+		 * special case described below.
+		 */
+		mte_bitmap_write(result, tags[0], &bit_pos, MTE_TAG_SIZE);
+		i = 2;
+	} else {
+		i = len;
+	}
+	for (; i < MTE_MAX_RANGES; i++)
+		mte_bitmap_write(result, 0, &bit_pos, MTE_TAG_SIZE);
+	/*
+	 * Most of the time sizes[i] fits into MTE_BITS_PER_SIZE, apart from a
+	 * special case when:
+	 *   len = 2;
+	 *   sizes = { MTE_GRANULES_PER_PAGE / 2, MTE_GRANULES_PER_PAGE / 2};
+	 * In this case largest_idx will be set to 0, and the size written to
+	 * the bitmap will be also 0.
+	 */
+	for (i = 0; i < len; i++) {
+		if (i != largest_idx)
+			mte_bitmap_write(result, sizes[i], &bit_pos,
+					 MTE_BITS_PER_SIZE);
+	}
+	for (i = len; i < MTE_MAX_RANGES; i++)
+		mte_bitmap_write(result, 0, &bit_pos, MTE_BITS_PER_SIZE);
+}
+
+/**
+ * mte_compress() - compress the given tag array.
+ * @tags: MTE_GRANULES_PER_PAGE-byte array to read the tags from.
+ *
+ * Attempts to compress the user-supplied tag array.
+ *
+ * Returns: compressed data or NULL.
+ */
+void *mte_compress(u8 *tags)
+{
+	unsigned short *r_sizes;
+	void *result = NULL;
+	u8 *r_tags;
+	size_t r_len;
+
+	r_sizes = kmalloc_array(MTE_GRANULES_PER_PAGE, sizeof(unsigned short),
+				GFP_KERNEL);
+	r_tags = kmalloc(MTE_GRANULES_PER_PAGE, GFP_KERNEL);
+	if (!r_sizes || !r_tags)
+		goto ret;
+	r_len = MTE_GRANULES_PER_PAGE;
+	mte_tags_to_ranges(tags, r_tags, r_sizes, &r_len);
+	if (r_len <= MTE_MAX_RANGES)
+		mte_compress_to_ulong(r_len, r_tags, r_sizes,
+				      (unsigned long *)&result);
+ret:
+	kfree(r_tags);
+	kfree(r_sizes);
+	return result;
+}
+EXPORT_SYMBOL_NS(mte_compress, MTECOMP);
+
+static unsigned long mte_bitmap_read(const unsigned long *bitmap,
+				     unsigned long *pos, unsigned long bits)
+{
+	unsigned long start = *pos;
+
+	*pos += bits;
+	return bitmap_read(bitmap, start, bits);
+}
+
+/**
+ * mte_decompress() - decompress the tag array from the given pointer.
+ * @data: pointer returned by @mte_compress()
+ * @tags: MTE_GRANULES_PER_PAGE-byte array to write the tags to.
+ *
+ * Reads the compressed data and writes it into the user-supplied tag array.
+ *
+ * Returns: true on success, false if the passed data is uncompressed.
+ */
+bool mte_decompress(void *data, u8 *tags)
+{
+	unsigned short r_sizes[MTE_MAX_RANGES];
+	u8 r_tags[MTE_MAX_RANGES];
+	unsigned int largest_idx, i;
+	unsigned long bit_pos = 0;
+	unsigned long *bitmap;
+	unsigned short sum;
+	size_t max_ranges;
+
+	if (!mte_is_compressed(data))
+		return false;
+
+	bitmap = (unsigned long *)&data;
+	max_ranges = MTE_MAX_RANGES;
+	/* Skip the leading bit indicating the inline case. */
+	mte_bitmap_read(bitmap, &bit_pos, 1);
+	largest_idx =
+		mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_LARGEST_IDX);
+	if (largest_idx >= MTE_MAX_RANGES)
+		return false;
+
+	for (i = 0; i < max_ranges; i++)
+		r_tags[i] = mte_bitmap_read(bitmap, &bit_pos, MTE_TAG_SIZE);
+	for (i = 0, sum = 0; i < max_ranges; i++) {
+		if (i == largest_idx)
+			continue;
+		r_sizes[i] =
+			mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_SIZE);
+		/*
+		 * Special case: tag array consists of two ranges of
+		 * `MTE_GRANULES_PER_PAGE / 2` tags.
+		 */
+		if ((largest_idx == 0) && (i == 1) && (r_sizes[i] == 0))
+			r_sizes[i] = MTE_GRANULES_PER_PAGE / 2;
+		if (!r_sizes[i]) {
+			max_ranges = i;
+			break;
+		}
+		sum += r_sizes[i];
+	}
+	if (sum >= MTE_GRANULES_PER_PAGE)
+		return false;
+	r_sizes[largest_idx] = MTE_GRANULES_PER_PAGE - sum;
+	mte_ranges_to_tags(r_tags, r_sizes, max_ranges, tags);
+	return true;
+}
+EXPORT_SYMBOL_NS(mte_decompress, MTECOMP);
diff --git a/arch/arm64/mm/mtecomp.h b/arch/arm64/mm/mtecomp.h
new file mode 100644
index 0000000000000..b94cf0384f2af
--- /dev/null
+++ b/arch/arm64/mm/mtecomp.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef ARCH_ARM64_MM_MTECOMP_H_
+#define ARCH_ARM64_MM_MTECOMP_H_
+
+/* Functions exported from mtecomp.c for test_mtecomp.c. */
+void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
+			size_t *out_len);
+void mte_ranges_to_tags(u8 *r_tags, unsigned short *r_sizes, size_t r_len,
+			u8 *tags);
+
+#endif  // ARCH_ARM64_MM_TEST_MTECOMP_H_
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Thu Dec 14 03:06:38 2023
From: glider at google.com (Alexander Potapenko)
Date: Thu, 14 Dec 2023 12:06:38 +0100
Subject: [PATCH v10-mte 6/7] arm64: mte: add compression support to mteswap.c
In-Reply-To: <20231214110639.2294687-1-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
Message-ID: <20231214110639.2294687-7-glider@google.com>

Update mteswap.c to perform inline compression of memory tags when
possible.

If CONFIG_ARM64_MTE_COMP is enabled, mteswap.c will attempt to compress
saved tags for a struct page and store them directly in Xarray entry
instead of wasting heap space.

Soon after booting Android, tag compression saves ~2x memory previously
spent by mteswap.c on tag allocations. On a moderately loaded device with
~20% tagged pages, this leads to saving several megabytes of kernel heap:

  # cat /sys/kernel/debug/mteswap/stats
  8 bytes:	102496 allocations,	67302 deallocations
  128 bytes:	212234 allocations,	178278 deallocations
  uncompressed tag storage size:	8851200
  compressed tag storage size:	4346368

(statistics collection is introduced in the following patch)

Signed-off-by: Alexander Potapenko <glider at google.com>
Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>

---
 v10-mte:
  - added Catalin's Reviewed-by:

 v9:
  - as requested by Yury Norov, split off statistics collection into a
    separate patch
  - minor fixes

 v8:
  - adapt to the new compression API, abandon mteswap_{no,}comp.c
  - move stats collection to mteswap.c

 v5:
  - drop a dead variable from _mte_free_saved_tags() in mteswap_comp.c
  - ensure MTE compression works with arbitrary page sizes
  - update patch description

 v4:
  - minor code simplifications suggested by Andy Shevchenko, added
    missing header dependencies
  - changed compression API names to reflect modifications made to
    memcomp.h (as suggested by Yury Norov)

 v3:
  - Addressed comments by Andy Shevchenko in another patch:
   - fixed includes order
   - replaced u64 with unsigned long
   - added MODULE_IMPORT_NS(MTECOMP)
---
 arch/arm64/mm/mteswap.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
index a31833e3ddc54..70f5c8ecd640d 100644
--- a/arch/arm64/mm/mteswap.c
+++ b/arch/arm64/mm/mteswap.c
@@ -6,6 +6,8 @@
 #include <linux/swap.h>
 #include <linux/swapops.h>
 #include <asm/mte.h>
+#include <asm/mtecomp.h>
+#include "mtecomp.h"
 
 static DEFINE_XARRAY(mte_pages);
 
@@ -17,12 +19,13 @@ void *mte_allocate_tag_storage(void)
 
 void mte_free_tag_storage(char *storage)
 {
-	kfree(storage);
+	if (!mte_is_compressed(storage))
+		kfree(storage);
 }
 
 int mte_save_tags(struct page *page)
 {
-	void *tag_storage, *ret;
+	void *tag_storage, *compressed_storage, *ret;
 
 	if (!page_mte_tagged(page))
 		return 0;
@@ -32,6 +35,11 @@ int mte_save_tags(struct page *page)
 		return -ENOMEM;
 
 	mte_save_page_tags(page_address(page), tag_storage);
+	compressed_storage = mte_compress(tag_storage);
+	if (compressed_storage) {
+		mte_free_tag_storage(tag_storage);
+		tag_storage = compressed_storage;
+	}
 
 	/* lookup the swap entry.val from the page */
 	ret = xa_store(&mte_pages, page_swap_entry(page).val, tag_storage,
@@ -50,13 +58,20 @@ int mte_save_tags(struct page *page)
 void mte_restore_tags(swp_entry_t entry, struct page *page)
 {
 	void *tags = xa_load(&mte_pages, entry.val);
+	void *tag_storage = NULL;
 
 	if (!tags)
 		return;
 
 	if (try_page_mte_tagging(page)) {
+		if (mte_is_compressed(tags)) {
+			tag_storage = mte_allocate_tag_storage();
+			mte_decompress(tags, tag_storage);
+			tags = tag_storage;
+		}
 		mte_restore_page_tags(page_address(page), tags);
 		set_page_mte_tagged(page);
+		mte_free_tag_storage(tag_storage);
 	}
 }
 
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Thu Dec 14 03:06:35 2023
From: glider at google.com (Alexander Potapenko)
Date: Thu, 14 Dec 2023 12:06:35 +0100
Subject: [PATCH v10-mte 3/7] lib/test_bitmap: use pr_info() for non-error messages
In-Reply-To: <20231214110639.2294687-1-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
Message-ID: <20231214110639.2294687-4-glider@google.com>

pr_err() messages may be treated as errors by some log readers, so let
us only use them for test failures. For non-error messages, replace them
with pr_info().

Suggested-by: Alexander Lobakin <aleksander.lobakin at intel.com>
Signed-off-by: Alexander Potapenko <glider at google.com>

---
v10-mte:
 - send this patch together with the "Implement MTE tag compression for
   swapped pages"
---
 lib/test_bitmap.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 46c0154680772..a6e92cf5266af 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -507,7 +507,7 @@ static void __init test_bitmap_parselist(void)
 		}
 
 		if (ptest.flags & PARSE_TIME)
-			pr_err("parselist: %d: input is '%s' OK, Time: %llu\n",
+			pr_info("parselist: %d: input is '%s' OK, Time: %llu\n",
 					i, ptest.in, time);
 
 #undef ptest
@@ -546,7 +546,7 @@ static void __init test_bitmap_printlist(void)
 		goto out;
 	}
 
-	pr_err("bitmap_print_to_pagebuf: input is '%s', Time: %llu\n", buf, time);
+	pr_info("bitmap_print_to_pagebuf: input is '%s', Time: %llu\n", buf, time);
 out:
 	kfree(buf);
 	kfree(bmap);
@@ -624,7 +624,7 @@ static void __init test_bitmap_parse(void)
 		}
 
 		if (test.flags & PARSE_TIME)
-			pr_err("parse: %d: input is '%s' OK, Time: %llu\n",
+			pr_info("parse: %d: input is '%s' OK, Time: %llu\n",
 					i, test.in, time);
 	}
 }
@@ -1380,7 +1380,7 @@ static void __init test_bitmap_read_perf(void)
 		}
 	}
 	time = ktime_get() - time;
-	pr_err("Time spent in %s:\t%llu\n", __func__, time);
+	pr_info("Time spent in %s:\t%llu\n", __func__, time);
 }
 
 static void __init test_bitmap_write_perf(void)
@@ -1402,7 +1402,7 @@ static void __init test_bitmap_write_perf(void)
 		}
 	}
 	time = ktime_get() - time;
-	pr_err("Time spent in %s:\t%llu\n", __func__, time);
+	pr_info("Time spent in %s:\t%llu\n", __func__, time);
 }
 
 #undef TEST_BIT_LEN
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Thu Dec 14 03:06:37 2023
From: glider at google.com (Alexander Potapenko)
Date: Thu, 14 Dec 2023 12:06:37 +0100
Subject: [PATCH v10-mte 5/7] arm64: mte: add a test for MTE tags compression
In-Reply-To: <20231214110639.2294687-1-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
Message-ID: <20231214110639.2294687-6-glider@google.com>

Ensure that tag sequences containing alternating values are compressed
to buffers of expected size and correctly decompressed afterwards.

Signed-off-by: Alexander Potapenko <glider at google.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>

---
 v10-mte:
  - added Catalin's Acked-by:

 v9:
  - minor changes to Kconfig description

 v8:
  - adapt to the simplified compression algorithm

 v6:
  - add test_decompress_invalid() to ensure invalid handles are ignored;
  - add test_upper_bits(), which is a regression test for a case where
    an inline handle looked like an out-of-line one;
  - add test_compress_nonzero() to ensure a full nonzero tag array is
    compressed correctly;
  - add test_two_ranges() to test cases when the input buffer is divided
    into two ranges.

 v5:
  - remove hardcoded constants, added test setup/teardown;
  - support 16- and 64K pages;
  - replace nested if-clauses with expected_size_from_ranges();
  - call mte_release_handle() after tests that perform
    compression/decompression;
  - address comments by Andy Shevchenko:
    - fix include order;
    - use mtecomp.h instead of function prototypes.

 v4:
  - addressed comments by Andy Shevchenko:
    - expanded MTE to "Memory Tagging Extension" in Kconfig
    - changed signed variables to unsigned where applicable
    - added missing header dependencies

  - addressed comments by Yury Norov:
    - moved test-only declarations from mtecomp.h into this test
    - switched to the new "mte"-prefixed function names, dropped the
      mentions of "EA0"
    - added test_tag_to_ranges_n()

 v3:
  - addressed comments by Andy Shevchenko in another patch:
   - switched from u64 to unsigned long
   - added MODULE_IMPORT_NS(MTECOMP)
   - fixed includes order
---
 arch/arm64/Kconfig           |  11 ++
 arch/arm64/mm/Makefile       |   1 +
 arch/arm64/mm/test_mtecomp.c | 364 +++++++++++++++++++++++++++++++++++
 3 files changed, 376 insertions(+)
 create mode 100644 arch/arm64/mm/test_mtecomp.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5f4d4b49a512e..6a1397a96f2f0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2089,6 +2089,17 @@ config ARM64_MTE_COMP
 	  RLE to conserve heap memory. In the common case compressed tags
 	  occupy 2.5x less memory.
 
+config ARM64_MTE_COMP_KUNIT_TEST
+	tristate "Test tag compression for ARM64 Memory Tagging Extension" if !KUNIT_ALL_TESTS
+	default KUNIT_ALL_TESTS
+	depends on KUNIT && ARM64_MTE_COMP
+	help
+	  Test MTE compression algorithm enabled by CONFIG_ARM64_MTE_COMP.
+
+	  Ensure that certain tag sequences containing alternating values can
+	  be compressed into pointer-size values and correctly decompressed
+	  afterwards.
+
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index 46778f6dd83c2..170dc62b010b9 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd-asm.o
 obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o
 obj-$(CONFIG_ARM64_MTE)		+= mteswap.o
 obj-$(CONFIG_ARM64_MTE_COMP)	+= mtecomp.o
+obj-$(CONFIG_ARM64_MTE_COMP_KUNIT_TEST) += test_mtecomp.o
 KASAN_SANITIZE_physaddr.o	+= n
 
 obj-$(CONFIG_KASAN)		+= kasan_init.o
diff --git a/arch/arm64/mm/test_mtecomp.c b/arch/arm64/mm/test_mtecomp.c
new file mode 100644
index 0000000000000..e8aeb7607ff41
--- /dev/null
+++ b/arch/arm64/mm/test_mtecomp.c
@@ -0,0 +1,364 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for MTE tags compression algorithm.
+ */
+
+#include <linux/bits.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+
+#include <kunit/test.h>
+
+#include <asm/mtecomp.h>
+
+#include "mtecomp.h"
+
+/* Per-test storage allocated in mtecomp_test_init(). */
+struct test_data {
+	u8 *tags, *dtags;
+	unsigned short *r_sizes;
+	size_t r_len;
+	u8 *r_tags;
+};
+
+/*
+ * Split td->tags to ranges stored in td->r_tags, td->r_sizes, td->r_len,
+ * then convert those ranges back to tags stored in td->dtags.
+ */
+static void tags_to_ranges_to_tags_helper(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+
+	mte_tags_to_ranges(td->tags, td->r_tags, td->r_sizes, &td->r_len);
+	mte_ranges_to_tags(td->r_tags, td->r_sizes, td->r_len, td->dtags);
+	KUNIT_EXPECT_EQ(test, memcmp(td->tags, td->dtags, MTE_PAGE_TAG_STORAGE),
+			0);
+}
+
+/*
+ * Test that mte_tags_to_ranges() produces a single range for a zero-filled tag
+ * buffer.
+ */
+static void test_tags_to_ranges_zero(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+
+	memset(td->tags, 0, MTE_PAGE_TAG_STORAGE);
+	tags_to_ranges_to_tags_helper(test);
+
+	KUNIT_EXPECT_EQ(test, td->r_len, 1);
+	KUNIT_EXPECT_EQ(test, td->r_tags[0], 0);
+	KUNIT_EXPECT_EQ(test, td->r_sizes[0], MTE_GRANULES_PER_PAGE);
+}
+
+/*
+ * Test that a small number of different tags is correctly transformed into
+ * ranges.
+ */
+static void test_tags_to_ranges_simple(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	const u8 ex_tags[] = { 0xa, 0x0, 0xa, 0xb, 0x0 };
+	const unsigned short ex_sizes[] = { 1, 2, 2, 1,
+					    MTE_GRANULES_PER_PAGE - 6 };
+
+	memset(td->tags, 0, MTE_PAGE_TAG_STORAGE);
+	td->tags[0] = 0xa0;
+	td->tags[1] = 0x0a;
+	td->tags[2] = 0xab;
+	tags_to_ranges_to_tags_helper(test);
+
+	KUNIT_EXPECT_EQ(test, td->r_len, 5);
+	KUNIT_EXPECT_EQ(test, memcmp(td->r_tags, ex_tags, sizeof(ex_tags)), 0);
+	KUNIT_EXPECT_EQ(test, memcmp(td->r_sizes, ex_sizes, sizeof(ex_sizes)),
+			0);
+}
+
+/* Test that repeated 0xa0 byte produces MTE_GRANULES_PER_PAGE ranges of length 1. */
+static void test_tags_to_ranges_repeated(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+
+	memset(td->tags, 0xa0, MTE_PAGE_TAG_STORAGE);
+	tags_to_ranges_to_tags_helper(test);
+
+	KUNIT_EXPECT_EQ(test, td->r_len, MTE_GRANULES_PER_PAGE);
+}
+
+/* Generate a buffer that will contain @nranges of tag ranges. */
+static void gen_tag_range_helper(u8 *tags, int nranges)
+{
+	unsigned int i;
+
+	memset(tags, 0, MTE_PAGE_TAG_STORAGE);
+	if (nranges > 1) {
+		nranges--;
+		for (i = 0; i < nranges / 2; i++)
+			tags[i] = 0xab;
+		if (nranges % 2)
+			tags[nranges / 2] = 0xa0;
+	}
+}
+
+/*
+ * Test that mte_tags_to_ranges()/mte_ranges_to_tags() work for various
+ * r_len values.
+ */
+static void test_tag_to_ranges_n(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	unsigned int i, j, sum;
+
+	for (i = 1; i <= MTE_GRANULES_PER_PAGE; i++) {
+		gen_tag_range_helper(td->tags, i);
+		tags_to_ranges_to_tags_helper(test);
+		sum = 0;
+		for (j = 0; j < td->r_len; j++)
+			sum += td->r_sizes[j];
+		KUNIT_EXPECT_EQ(test, sum, MTE_GRANULES_PER_PAGE);
+	}
+}
+
+/*
+ * Check that the tag buffer in test->priv can be compressed and decompressed
+ * without changes.
+ */
+static void *compress_decompress_helper(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	handle = mte_compress(td->tags);
+	KUNIT_EXPECT_EQ(test, (unsigned long)handle & BIT_ULL(63), 0);
+	if (handle) {
+		KUNIT_EXPECT_TRUE(test, mte_decompress(handle, td->dtags));
+		KUNIT_EXPECT_EQ(test, memcmp(td->tags, td->dtags, MTE_PAGE_TAG_STORAGE),
+				0);
+	}
+	return handle;
+}
+
+/* Test that a zero-filled array is compressed into inline storage. */
+static void test_compress_zero(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	memset(td->tags, 0, MTE_PAGE_TAG_STORAGE);
+	handle = compress_decompress_helper(test);
+	/* Tags are stored inline. */
+	KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+}
+
+/* Test that a 0xaa-filled array is compressed into inline storage. */
+static void test_compress_nonzero(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	memset(td->tags, 0xaa, MTE_PAGE_TAG_STORAGE);
+	handle = compress_decompress_helper(test);
+	/* Tags are stored inline. */
+	KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+}
+
+/*
+ * Test that two tag ranges are compressed into inline storage.
+ *
+ * This also covers a special case where both ranges contain
+ * `MTE_GRANULES_PER_PAGE / 2` tags and overflow the designated range size.
+ */
+static void test_two_ranges(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+	unsigned int i;
+	size_t r_len = 2;
+	unsigned char r_tags[2] = { 0xe, 0x0 };
+	unsigned short r_sizes[2];
+
+	for (i = 1; i < MTE_GRANULES_PER_PAGE; i++) {
+		r_sizes[0] = i;
+		r_sizes[1] = MTE_GRANULES_PER_PAGE - i;
+		mte_ranges_to_tags(r_tags, r_sizes, r_len, td->tags);
+		handle = compress_decompress_helper(test);
+		KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+	}
+}
+
+/*
+ * Test that a very small number of tag ranges ends up compressed into 8 bytes.
+ */
+static void test_compress_simple(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	memset(td->tags, 0, MTE_PAGE_TAG_STORAGE);
+	td->tags[0] = 0xa0;
+	td->tags[1] = 0x0a;
+
+	handle = compress_decompress_helper(test);
+	/* Tags are stored inline. */
+	KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+}
+
+/*
+ * Test that a buffer containing @nranges ranges compresses into @exp_size
+ * bytes and decompresses into the original tag sequence.
+ */
+static void compress_range_helper(struct kunit *test, int nranges,
+				  bool exp_inl)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	gen_tag_range_helper(td->tags, nranges);
+	handle = compress_decompress_helper(test);
+	KUNIT_EXPECT_EQ(test, mte_is_compressed(handle), exp_inl);
+}
+
+static inline size_t max_inline_ranges(void)
+{
+#if defined CONFIG_ARM64_4K_PAGES
+	return 6;
+#elif defined(CONFIG_ARM64_16K_PAGES)
+	return 5;
+#else
+	return 4;
+#endif
+}
+
+/*
+ * Test that every number of tag ranges is correctly compressed and
+ * decompressed.
+ */
+static void test_compress_ranges(struct kunit *test)
+{
+	unsigned int i;
+	bool exp_inl;
+
+	for (i = 1; i <= MTE_GRANULES_PER_PAGE; i++) {
+		exp_inl = i <= max_inline_ranges();
+		compress_range_helper(test, i, exp_inl);
+	}
+}
+
+/*
+ * Test that invalid handles are ignored by mte_decompress().
+ */
+static void test_decompress_invalid(struct kunit *test)
+{
+	void *handle1 = (void *)0xeb0b0b0100804020;
+	void *handle2 = (void *)0x6b0b0b010080402f;
+	struct test_data *td = test->priv;
+
+	/* handle1 has bit 0 set to 1. */
+	KUNIT_EXPECT_FALSE(test, mte_decompress(handle1, td->dtags));
+	/*
+	 * handle2 is an inline handle, but its largest_idx (bits 1..3)
+	 * is out of bounds for the inline storage.
+	 */
+	KUNIT_EXPECT_FALSE(test, mte_decompress(handle2, td->dtags));
+}
+
+/*
+ * Test that compressed inline tags cannot be confused with out-of-line
+ * pointers.
+ *
+ * Compressed values are written from bit 0 to bit 63, so the size of the last
+ * tag range initially ends up in the upper bits of the inline representation.
+ * Make sure mte_compress() rearranges the bits so that the resulting handle does
+ * not have 0b0111 as the upper four bits.
+ */
+static void test_upper_bits(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+	unsigned char r_tags[6] = { 7, 0, 7, 0, 7, 0 };
+	unsigned short r_sizes[6] = { 1, 1, 1, 1, 1, 1 };
+	size_t r_len;
+
+	/* Maximum number of ranges that can be encoded inline. */
+	r_len = max_inline_ranges();
+	/* Maximum range size possible, will be omitted. */
+	r_sizes[0] = MTE_GRANULES_PER_PAGE / 2 - 1;
+	/* A number close to r_sizes[0] that has most of its bits set. */
+	r_sizes[r_len - 1] = MTE_GRANULES_PER_PAGE - r_sizes[0] - r_len + 2;
+
+	mte_ranges_to_tags(r_tags, r_sizes, r_len, td->tags);
+	handle = compress_decompress_helper(test);
+	KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+}
+
+static void mtecomp_dealloc_testdata(struct test_data *td)
+{
+	kfree(td->tags);
+	kfree(td->dtags);
+	kfree(td->r_sizes);
+	kfree(td->r_tags);
+}
+
+static int mtecomp_test_init(struct kunit *test)
+{
+	struct test_data *td;
+
+	td = kmalloc(sizeof(struct test_data), GFP_KERNEL);
+	if (!td)
+		return 1;
+	td->tags = kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
+	if (!td->tags)
+		goto error;
+	td->dtags = kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
+	if (!td->dtags)
+		goto error;
+	td->r_len = MTE_GRANULES_PER_PAGE;
+	td->r_sizes = kmalloc_array(MTE_GRANULES_PER_PAGE,
+				    sizeof(unsigned short), GFP_KERNEL);
+	if (!td->r_sizes)
+		goto error;
+	td->r_tags = kmalloc(MTE_GRANULES_PER_PAGE, GFP_KERNEL);
+	if (!td->r_tags)
+		goto error;
+	test->priv = (void *)td;
+	return 0;
+error:
+	mtecomp_dealloc_testdata(td);
+	return 1;
+}
+
+static void mtecomp_test_exit(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+
+	mtecomp_dealloc_testdata(td);
+}
+
+static struct kunit_case mtecomp_test_cases[] = {
+	KUNIT_CASE(test_tags_to_ranges_zero),
+	KUNIT_CASE(test_tags_to_ranges_simple),
+	KUNIT_CASE(test_tags_to_ranges_repeated),
+	KUNIT_CASE(test_tag_to_ranges_n),
+	KUNIT_CASE(test_compress_zero),
+	KUNIT_CASE(test_compress_nonzero),
+	KUNIT_CASE(test_two_ranges),
+	KUNIT_CASE(test_compress_simple),
+	KUNIT_CASE(test_compress_ranges),
+	KUNIT_CASE(test_decompress_invalid),
+	KUNIT_CASE(test_upper_bits),
+	{}
+};
+
+static struct kunit_suite mtecomp_test_suite = {
+	.name = "mtecomp",
+	.init = mtecomp_test_init,
+	.exit = mtecomp_test_exit,
+	.test_cases = mtecomp_test_cases,
+};
+kunit_test_suites(&mtecomp_test_suite);
+
+MODULE_IMPORT_NS(MTECOMP);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alexander Potapenko <glider at google.com>");
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Thu Dec 14 03:06:39 2023
From: glider at google.com (Alexander Potapenko)
Date: Thu, 14 Dec 2023 12:06:39 +0100
Subject: [PATCH v10-mte 7/7] arm64: mte: implement CONFIG_ARM64_MTE_SWAP_STATS
In-Reply-To: <20231214110639.2294687-1-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
Message-ID: <20231214110639.2294687-8-glider@google.com>

Provide a config to collect the usage statistics for ARM MTE tag
compression. This patch introduces allocation/deallocation counters
for buffers that were stored uncompressed (and thus occupy 128 bytes of
heap plus the Xarray overhead to store a pointer) and those that were
compressed into 8-byte pointers (effectively using 0 bytes of heap in
addition to the Xarray overhead).

The counters are exposed to the userspace via
/sys/kernel/debug/mteswap/stats:

  # cat /sys/kernel/debug/mteswap/stats
  8 bytes:      102496 allocations,     67302 deallocations
  128 bytes:    212234 allocations,     178278 deallocations
  uncompressed tag storage size:        8851200
  compressed tag storage size:  4346368

Suggested-by: Yury Norov <yury.norov at gmail.com>
Signed-off-by: Alexander Potapenko <glider at google.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>

---

This patch was split off from the "arm64: mte: add compression support
to mteswap.c" patch
(https://lore.kernel.org/linux-arm-kernel/ZUVulBKVYK7cq2rJ at yury-ThinkPad/T/#m819ec30beb9de53d5c442f7e3247456f8966d88a)

v10-mte:
 - added Catalin's Acked-by:

v9:
 - add this patch, put the stats behind a separate config,
   mention /sys/kernel/debug/mteswap/stats in the documentation
---
 .../arch/arm64/mte-tag-compression.rst        | 12 +++
 arch/arm64/Kconfig                            | 15 +++
 arch/arm64/mm/mteswap.c                       | 93 ++++++++++++++++++-
 3 files changed, 118 insertions(+), 2 deletions(-)

diff --git a/Documentation/arch/arm64/mte-tag-compression.rst b/Documentation/arch/arm64/mte-tag-compression.rst
index 8fe6b51a9db6d..4c25b96f7d4b5 100644
--- a/Documentation/arch/arm64/mte-tag-compression.rst
+++ b/Documentation/arch/arm64/mte-tag-compression.rst
@@ -145,6 +145,18 @@ Tag compression and decompression implicitly rely on the fixed MTE tag size
 (4 bits) and number of tags per page. Should these values change, the algorithm
 may need to be revised.
 
+Stats
+=====
+
+When `CONFIG_ARM64_MTE_SWAP_STATS` is enabled, `arch/arm64/mm/mteswap.c` exports
+usage statistics for tag compression used when swapping tagged pages. The data
+can be accessed via debugfs::
+
+  # cat /sys/kernel/debug/mteswap/stats
+  8 bytes:        10438 allocations,      10417 deallocations
+  128 bytes:      26180 allocations,      26179 deallocations
+  uncompressed tag storage size:  2816
+  compressed tag storage size:    128
 
 Programming Interface
 =====================
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6a1397a96f2f0..49a786c7edadd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2100,6 +2100,21 @@ config ARM64_MTE_COMP_KUNIT_TEST
 	  be compressed into pointer-size values and correctly decompressed
 	  afterwards.
 
+config ARM64_MTE_SWAP_STATS
+	bool "Collect usage statistics of tag compression for swapped MTE tags"
+	default y
+	depends on ARM64_MTE && ARM64_MTE_COMP
+	help
+	  Collect usage statistics for ARM64 MTE tag compression during swapping.
+
+	  Adds allocation/deallocation counters for buffers that were stored
+	  uncompressed (and thus occupy 128 bytes of heap plus the Xarray
+	  overhead to store a pointer) and those that were compressed into
+	  8-byte pointers (effectively using 0 bytes of heap in addition to
+	  the Xarray overhead).
+	  The counters are exposed to the userspace via
+	  /sys/kernel/debug/mteswap/stats.
+
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
index 70f5c8ecd640d..1c6c78b9a9037 100644
--- a/arch/arm64/mm/mteswap.c
+++ b/arch/arm64/mm/mteswap.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 
+#include <linux/debugfs.h>
 #include <linux/pagemap.h>
 #include <linux/xarray.h>
 #include <linux/slab.h>
@@ -11,16 +12,54 @@
 
 static DEFINE_XARRAY(mte_pages);
 
+enum mteswap_counters {
+	MTESWAP_CTR_INLINE = 0,
+	MTESWAP_CTR_OUTLINE,
+	MTESWAP_CTR_SIZE
+};
+
+#if defined(CONFIG_ARM64_MTE_SWAP_STATS)
+static atomic_long_t alloc_counters[MTESWAP_CTR_SIZE];
+static atomic_long_t dealloc_counters[MTESWAP_CTR_SIZE];
+
+static void inc_alloc_counter(int kind)
+{
+	atomic_long_inc(&alloc_counters[kind]);
+}
+
+static void inc_dealloc_counter(int kind)
+{
+	atomic_long_inc(&dealloc_counters[kind]);
+}
+#else
+static void inc_alloc_counter(int kind)
+{
+}
+
+static void inc_dealloc_counter(int kind)
+{
+}
+#endif
+
 void *mte_allocate_tag_storage(void)
 {
+	void *ret;
+
 	/* tags granule is 16 bytes, 2 tags stored per byte */
-	return kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
+	ret = kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
+	if (ret)
+		inc_alloc_counter(MTESWAP_CTR_OUTLINE);
+	return ret;
 }
 
 void mte_free_tag_storage(char *storage)
 {
-	if (!mte_is_compressed(storage))
+	if (!mte_is_compressed(storage)) {
 		kfree(storage);
+		inc_dealloc_counter(MTESWAP_CTR_OUTLINE);
+	} else {
+		inc_dealloc_counter(MTESWAP_CTR_INLINE);
+	}
 }
 
 int mte_save_tags(struct page *page)
@@ -39,6 +78,7 @@ int mte_save_tags(struct page *page)
 	if (compressed_storage) {
 		mte_free_tag_storage(tag_storage);
 		tag_storage = compressed_storage;
+		inc_alloc_counter(MTESWAP_CTR_INLINE);
 	}
 
 	/* lookup the swap entry.val from the page */
@@ -98,3 +138,52 @@ void mte_invalidate_tags_area(int type)
 	}
 	xa_unlock(&mte_pages);
 }
+
+#if defined(CONFIG_ARM64_MTE_SWAP_STATS)
+/* DebugFS interface. */
+static int stats_show(struct seq_file *seq, void *v)
+{
+	unsigned long total_mem_alloc = 0, total_mem_dealloc = 0;
+	unsigned long total_num_alloc = 0, total_num_dealloc = 0;
+	unsigned long sizes[2] = { 8, MTE_PAGE_TAG_STORAGE };
+	long alloc, dealloc;
+	unsigned long size;
+	int i;
+
+	for (i = 0; i < MTESWAP_CTR_SIZE; i++) {
+		alloc = atomic_long_read(&alloc_counters[i]);
+		dealloc = atomic_long_read(&dealloc_counters[i]);
+		total_num_alloc += alloc;
+		total_num_dealloc += dealloc;
+		size = sizes[i];
+		/*
+		 * Do not count 8-byte buffers towards compressed tag storage
+		 * size.
+		 */
+		if (i) {
+			total_mem_alloc += (size * alloc);
+			total_mem_dealloc += (size * dealloc);
+		}
+		seq_printf(seq,
+			   "%lu bytes:\t%lu allocations,\t%lu deallocations\n",
+			   size, alloc, dealloc);
+	}
+	seq_printf(seq, "uncompressed tag storage size:\t%lu\n",
+		   (total_num_alloc - total_num_dealloc) *
+			   MTE_PAGE_TAG_STORAGE);
+	seq_printf(seq, "compressed tag storage size:\t%lu\n",
+		   total_mem_alloc - total_mem_dealloc);
+	return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(stats);
+
+static int mteswap_init(void)
+{
+	struct dentry *mteswap_dir;
+
+	mteswap_dir = debugfs_create_dir("mteswap", NULL);
+	debugfs_create_file("stats", 0444, mteswap_dir, NULL, &stats_fops);
+	return 0;
+}
+module_init(mteswap_init);
+#endif
-- 
2.43.0.472.g3155946c3a-goog



From b-kapoor at ti.com  Thu Dec 14 03:07:13 2023
From: b-kapoor at ti.com (Bhavya Kapoor)
Date: Thu, 14 Dec 2023 16:37:13 +0530
Subject: [PATCH 0/3] arm64: dts: ti: Add Itap Delay Value For High Speed
 DDR
In-Reply-To: <30baf959-e486-4804-947b-516e53cce6fa@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
 <30baf959-e486-4804-947b-516e53cce6fa@ti.com>
Message-ID: <6230e848-15b8-48ba-8af4-5f90d7e1408c@ti.com>


On 06/12/23 12:01 am, Kumar, Udit wrote:
> Hi Bhavya
>
> On 12/1/2023 1:50 PM, Bhavya Kapoor wrote:
>> This Series adds Itap Delay Value for DDR52 speed mode for eMMC in
>> J7200 and for DDR50 speed mode for MMCSD in J721s2 and J784s4 SoC.
>>
>> Rebased to next-20231201
>>
>> Bhavya Kapoor (3):
>> ?? arm64: dts: ti: k3-j7200-main: Add Itap Delay Value For DDR52 speed
>> ???? mode
>> ?? arm64: dts: ti: k3-j721s2-main: Add Itap Delay Value For DDR50 speed
>> ???? mode
>> ?? arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed
>> ???? mode
>
> Could you confirm, after adding itap values, above modes are working 
> fine apart from
>
> mode detection.
>
> Thanks
>
> Udit

Hi Udit, Below are the links to the test logs

j7200 ddr52 - 
https://gist.github.com/a0498981/f9b7b7d3592eaca591dec3e72de45585

j721s2 ddr50 - 
https://gist.github.com/a0498981/9861e1df3fe0fc7c050db4f7a8cc34b8

j784s4 ddr50 - 
https://gist.github.com/a0498981/7c598dd708424252e2629fe0c7458a6d

Thanks

~B-Kapoor

>
>
>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi? | 1 +
>> ? arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 1 +
>> ? arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 1 +
>> ? 3 files changed, 3 insertions(+)
>>


From patchwork-bot+netdevbpf at kernel.org  Thu Dec 14 03:10:25 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Thu, 14 Dec 2023 11:10:25 +0000
Subject: [PATCH net v2] net: stmmac: Handle disabled MDIO busses from
 devicetree
In-Reply-To: <20231212-b4-stmmac-handle-mdio-enodev-v2-1-600171acf79f@redhat.com>
References: <20231212-b4-stmmac-handle-mdio-enodev-v2-1-600171acf79f@redhat.com>
Message-ID: <170255222519.10804.11119972355205402863.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni at redhat.com>:

On Tue, 12 Dec 2023 16:18:33 -0600 you wrote:
> Many hardware configurations have the MDIO bus disabled, and are instead
> using some other MDIO bus to talk to the MAC's phy.
> 
> of_mdiobus_register() returns -ENODEV in this case. Let's handle it
> gracefully instead of failing to probe the MAC.
> 
> Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.")
> Signed-off-by: Andrew Halaney <ahalaney at redhat.com>
> 
> [...]

Here is the summary with links:
  - [net,v2] net: stmmac: Handle disabled MDIO busses from devicetree
    https://git.kernel.org/netdev/net/c/e23c0d21ce92

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From knaerzche at gmail.com  Thu Dec 14 03:12:08 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 14 Dec 2023 12:12:08 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-5-knaerzche@gmail.com>
 <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
Message-ID: <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com>

Hi Maxime

Am 14.12.23 um 08:56 schrieb Maxime Ripard:
> Hi Alex,
>
> Thanks for working on this!
>
> On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
>> The display controller will always give full range RGB regardless of the
>> mode set, but HDMI requires certain modes to be transmitted in limited
>> range RGB. This is especially required for HDMI sinks which do not support
>> non-standard quantization ranges.
>>
>> This enables color space conversion for those modes and sets the
>> quantization range accordingly in the AVI infoframe.
>>
>> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>> ---
>>   drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
>>   1 file changed, 32 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> index 345253e033c5..32626a75723c 100644
>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> @@ -33,6 +33,7 @@ struct hdmi_data_info {
>>   	unsigned int enc_in_format;
>>   	unsigned int enc_out_format;
>>   	unsigned int colorimetry;
>> +	bool rgb_limited_range;
>>   };
>>   
>>   struct inno_hdmi_i2c {
>> @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
>>   	else
>>   		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>>   
>> +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
>> +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
>> +						   &hdmi->connector, mode,
>> +						   hdmi->hdmi_data.rgb_limited_range ?
>> +						   HDMI_QUANTIZATION_RANGE_LIMITED :
>> +						   HDMI_QUANTIZATION_RANGE_FULL);
>> +	} else {
>> +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
>> +		frame.avi.ycc_quantization_range =
>> +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
>> +	}
>> +
>>   	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
>>   }
>>   
>> @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
>>   	if (data->enc_in_format == data->enc_out_format) {
>>   		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
>>   		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
>> -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>> -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>> -
>> -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>> -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>> -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>> -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>> -			return 0;
>> +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
>> +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
>> +			    hdmi->hdmi_data.rgb_limited_range) {
>> +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
>> +				auto_csc = AUTO_CSC_DISABLE;
>> +				c0_c2_change = C0_C2_CHANGE_DISABLE;
>> +				csc_enable = v_CSC_ENABLE;
>> +			} else {
>> +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>> +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>> +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>> +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>> +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>> +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>> +				return 0;
>> +			}
>>   		}
>>   	}
>>   
>> @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>   	else
>>   		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
>>   
>> +	hdmi->hdmi_data.rgb_limited_range =
>> +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
>> +
> This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
> https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/
I'm aware of that and I mentioned it in the cover letter. Your series is 
not merged yet and it didn't get much feedback so far. What is the 
status there? Especially because you are removing things from inno-hdmi 
driver (which aren't really required to remove there) which will I have 
to reintroduce.

> I would appreciate if you could test and merge them into your series.
>
> In particular, there's no need to store the range here: enc_out_format
rgb_limited_range is currently not only used for csc, but also for for 
infoframe creation. So it makes sense to have this stored? to avoid 
calling drm_default_rgb_quant_range twice.

> is always RGB, so you'll always end up calling
> drm_hdmi_avi_infoframe_quant_range(), and you'll always have the same csc values.

I don't think that's true. Non-VIC modes like 800x600 or 1024x764 want 
full range RGB and csc must not be done in those cases.

Alex

>
> Maxime


From viresh.kumar at linaro.org  Thu Dec 14 03:14:46 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 14 Dec 2023 16:44:46 +0530
Subject: [PATCH 1/5] riscv: dts: allwinner: Update opp table to allow CPU
 frequency scaling
In-Reply-To: <20231214103342.30775-2-fusibrandon13@gmail.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
 <20231214103342.30775-2-fusibrandon13@gmail.com>
Message-ID: <20231214111446.camz2krqanaieybh@vireshk-i7>

On 14-12-23, 11:33, Brandon Cheo Fusi wrote:
> Two OPPs are currently defined for the D1/D1s; one at 408MHz and
> another at 1.08GHz. Switching between these can be done with the
> "sun50i-cpufreq-nvmem" driver. This patch populates the opp table
> appropriately, with inspiration from
> https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi
> 
> The supply voltages are PWM-controlled, but support for that IP
> is still in the works. So stick to a fixed 0.9V vdd-cpu supply,
> which seems to be the default on most D1 boards.
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> index 64c3c2e6c..e211fe4c7 100644
> --- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> @@ -39,16 +39,22 @@ cpu0_intc: interrupt-controller {
>  	};
>  
>  	opp_table_cpu: opp-table-cpu {
> -		compatible = "operating-points-v2";
> +		compatible = "allwinner,sun20i-d1-operating-points",

I don't think you should add a new compatible for every SoC that needs
to be supported by a DT bindings and cpufreq driver. Maybe you should
just reuse "allwinner,sun50i-h6-operating-points" and it will work
fine for you ?

Rob ?

> +				 "allwinner,sun50i-h6-operating-points";
> +		nvmem-cells = <&cpu_speed_grade>;
> +		nvmem-cell-names = "speed";
> +		opp-shared;
>  
>  		opp-408000000 {
> +			clock-latency-ns = <244144>; /* 8 32k periods */
>  			opp-hz = /bits/ 64 <408000000>;
> -			opp-microvolt = <900000 900000 1100000>;
> +			opp-microvolt-speed0 = <900000>;

The separate property name thing was required when you could have
different values for different SoC instances, which can be read from
efuses, like in your case.

But all I see is speed0 here, why don't you always set opp-microvolt
then ?

Also why degrade from min/max/target type to just target ?

>  		};
>  
>  		opp-1080000000 {
> +			clock-latency-ns = <244144>; /* 8 32k periods */
>  			opp-hz = /bits/ 64 <1008000000>;
> -			opp-microvolt = <900000 900000 1100000>;
> +			opp-microvolt-speed0 = <900000>;
>  		};
>  	};
>  
> @@ -115,3 +121,8 @@ pmu {
>  			<0x00000000 0x0000000f 0xffffffff 0xffffffff 0x00020000>;
>  	};
>  };
> +
> +&sid {
> +	cpu_speed_grade: cpu-speed-grade at 0 {
> +		reg = <0x00 0x2>;
> +	};
> +};
> -- 
> 2.30.2

-- 
viresh


From viresh.kumar at linaro.org  Thu Dec 14 03:17:02 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 14 Dec 2023 16:47:02 +0530
Subject: [PATCH 4/5] cpufreq: Add support for RISC-V CPU Frequency
 scaling drivers
In-Reply-To: <20231214103342.30775-5-fusibrandon13@gmail.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
 <20231214103342.30775-5-fusibrandon13@gmail.com>
Message-ID: <20231214111702.xdd7qlcrpqh74i3j@vireshk-i7>

On 14-12-23, 11:33, Brandon Cheo Fusi wrote:
> Add Kconfig file for cpufreq scaling drivers that can handle RISC-V
> CPUs. An entry is included for the Allwinner H6 cpufreq driver that
> works with D1.
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  drivers/cpufreq/Kconfig       |  4 ++++
>  drivers/cpufreq/Kconfig.riscv | 16 ++++++++++++++++
>  2 files changed, 20 insertions(+)
>  create mode 100644 drivers/cpufreq/Kconfig.riscv

We don't have a separate kconfig file for each architecture. Only if
there are too many entries for an architecture, we add a new file.

-- 
viresh


From knaerzche at gmail.com  Thu Dec 14 03:17:39 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 14 Dec 2023 12:17:39 +0100
Subject: [PATCH 07/11] drm/rockchip: inno_hdmi: Add basic mode validation
In-Reply-To: <wz4e43ateg3gb7745mz22wwyruwavevvpfbqsdxeynejcjxhzn@qbqldsnkktei>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-8-knaerzche@gmail.com>
 <wz4e43ateg3gb7745mz22wwyruwavevvpfbqsdxeynejcjxhzn@qbqldsnkktei>
Message-ID: <1b7402b2-ec03-420b-a81b-3e6ea46e402a@gmail.com>

Hi Maxime,

Am 14.12.23 um 09:05 schrieb Maxime Ripard:
> Hi,
>
> On Wed, Dec 13, 2023 at 08:51:21PM +0100, Alex Bee wrote:
>> As per TRM this controller supports pixelclocks starting from 25 MHz. The
>> maximum supported pixelclocks are defined by the phy configurations we
>> have. Also it can't support modes that require doubled clocks.
>> If there is a phy reference clock we can additionally validate against
>> VESA DMT's recommendations.
>> Those checks are added to the mode_valid hook of the connector and
>> encoder's mode_fixup hook.
>>
>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>> ---
>>   drivers/gpu/drm/rockchip/inno_hdmi.c | 38 ++++++++++++++++++++++++++--
>>   1 file changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> index f7f0bec725f9..2f839ff31c1c 100644
>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> @@ -38,6 +38,8 @@ struct inno_hdmi_variant {
>>   	struct inno_hdmi_phy_config *default_phy_config;
>>   };
>>   
>> +#define INNO_HDMI_MIN_TMDS_CLOCK  25000000U
>> +
>>   struct hdmi_data_info {
>>   	int vic;
>>   	bool sink_has_audio;
>> @@ -572,6 +574,34 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>   	return 0;
>>   }
>>   
>> +static enum drm_mode_status inno_hdmi_mode_valid(struct inno_hdmi *hdmi,
>> +						 struct drm_display_mode *mode)
>> +{
> So, mode_valid is only called to filter out the modes retrieved by
> get_modes, but it won't be called when userspace programs a mode. That's
> atomic_check's job.
>
> So you probably want to create a shared function between atomic_check
> and mode_valid, and call it from both places (or call mode_valid from
> atomic_check).
This actually _is_ a shared function called in 
inno_hdmi_connector_mode_valid and inno_hdmi_encoder_mode_fixup. Yes, I? 
probably should use it in atomic_check _also_.
>
>> +	/* No support for double-clock modes */
>> +	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>> +		return MODE_BAD;
>> +
>> +	unsigned int mpixelclk = mode->clock * 1000;
> Variables should be declared at the top of the function.
Oookay ... can move them.
>> +	if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
>> +		return MODE_CLOCK_LOW;
> You probably want to check the max TMDS clock too?
Not sure what you mean here. For the currently supported formats of this 
driver (rgb only) tmds clock and pixel clock are always the same.
>
>> +	if (inno_hdmi_find_phy_config(hdmi, mpixelclk) < 0)
>> +		return MODE_CLOCK_HIGH;
>> +
>> +	if (hdmi->refclk) {
>> +		long refclk = clk_round_rate(hdmi->refclk, mpixelclk);
>> +		unsigned int max_tolerance = mpixelclk / 5000;
>> +
>> +		/* Vesa DMT standard mentions +/- 0.5% max tolerance */
>> +		if (abs(refclk - mpixelclk) > max_tolerance ||
>> +		    mpixelclk - refclk > max_tolerance;
>> +			return MODE_NOCLOCK;
> You should use abs_diff here. abs() will get confused by the unsigned vs
> signed comparison.
Ack.
>
>> +	}
>> +
>> +	return MODE_OK;
>> +}
>> +
>>   static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
>>   				       struct drm_display_mode *mode,
>>   				       struct drm_display_mode *adj_mode)
>> @@ -602,7 +632,9 @@ static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
>>   					 const struct drm_display_mode *mode,
>>   					 struct drm_display_mode *adj_mode)
>>   {
>> -	return true;
>> +	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
>> +
>> +	return inno_hdmi_mode_valid(hdmi, adj_mode) == MODE_OK;
>>   }
> Why do you call mode_valid in mode_fixup?

I'm calling the shared function you asked me to introduce 
(inno_hdmi_connector_mode_valid != inno_mode_valid)

Alex

>
> Maxime


From heiko at sntech.de  Thu Dec 14 03:17:34 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Thu, 14 Dec 2023 12:17:34 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization
 range
In-Reply-To: <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
 <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com>
Message-ID: <3053311.k3LOHGUjKi@diego>

Am Donnerstag, 14. Dezember 2023, 12:12:08 CET schrieb Alex Bee:
> Hi Maxime
> 
> Am 14.12.23 um 08:56 schrieb Maxime Ripard:
> > Hi Alex,
> >
> > Thanks for working on this!
> >
> > On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
> >> The display controller will always give full range RGB regardless of the
> >> mode set, but HDMI requires certain modes to be transmitted in limited
> >> range RGB. This is especially required for HDMI sinks which do not support
> >> non-standard quantization ranges.
> >>
> >> This enables color space conversion for those modes and sets the
> >> quantization range accordingly in the AVI infoframe.
> >>
> >> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> >> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> >> ---
> >>   drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
> >>   1 file changed, 32 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> >> index 345253e033c5..32626a75723c 100644
> >> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> >> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> >> @@ -33,6 +33,7 @@ struct hdmi_data_info {
> >>   	unsigned int enc_in_format;
> >>   	unsigned int enc_out_format;
> >>   	unsigned int colorimetry;
> >> +	bool rgb_limited_range;
> >>   };
> >>   
> >>   struct inno_hdmi_i2c {
> >> @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
> >>   	else
> >>   		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> >>   
> >> +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
> >> +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> >> +						   &hdmi->connector, mode,
> >> +						   hdmi->hdmi_data.rgb_limited_range ?
> >> +						   HDMI_QUANTIZATION_RANGE_LIMITED :
> >> +						   HDMI_QUANTIZATION_RANGE_FULL);
> >> +	} else {
> >> +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> >> +		frame.avi.ycc_quantization_range =
> >> +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> >> +	}
> >> +
> >>   	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
> >>   }
> >>   
> >> @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
> >>   	if (data->enc_in_format == data->enc_out_format) {
> >>   		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
> >>   		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
> >> -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> >> -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> >> -
> >> -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> >> -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> >> -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> >> -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> >> -			return 0;
> >> +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
> >> +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
> >> +			    hdmi->hdmi_data.rgb_limited_range) {
> >> +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
> >> +				auto_csc = AUTO_CSC_DISABLE;
> >> +				c0_c2_change = C0_C2_CHANGE_DISABLE;
> >> +				csc_enable = v_CSC_ENABLE;
> >> +			} else {
> >> +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> >> +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> >> +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> >> +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> >> +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> >> +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> >> +				return 0;
> >> +			}
> >>   		}
> >>   	}
> >>   
> >> @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
> >>   	else
> >>   		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
> >>   
> >> +	hdmi->hdmi_data.rgb_limited_range =
> >> +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
> >> +
> > This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
> > https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/
> I'm aware of that and I mentioned it in the cover letter. Your series is 
> not merged yet and it didn't get much feedback so far. What is the 
> status there? Especially because you are removing things from inno-hdmi 
> driver (which aren't really required to remove there) which will I have 
> to reintroduce.

Sadly I haven't found the time to look closer at Maxime's series so far,
but I got the impression that it separates into multiple cleanup steps
for a number of controllers.

So the sentence below suggests that Maxime wanted you to pick the
appropriate patches from there and incorporate them into your series
(as it looks like you developed a nice working knowledge of the inno-hdmi
driver). So there is no need to first drop and then reintroduce stuff, but
there may be other interesting cleanups there.

> > I would appreciate if you could test and merge them into your series.


Heiko

> > In particular, there's no need to store the range here: enc_out_format
> rgb_limited_range is currently not only used for csc, but also for for 
> infoframe creation. So it makes sense to have this stored  to avoid 
> calling drm_default_rgb_quant_range twice.
> 
> > is always RGB, so you'll always end up calling
> > drm_hdmi_avi_infoframe_quant_range(), and you'll always have the same csc values.
> 
> I don't think that's true. Non-VIC modes like 800x600 or 1024x764 want 
> full range RGB and csc must not be done in those cases.






From xu.yang_2 at nxp.com  Thu Dec 14 03:24:39 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 19:24:39 +0800
Subject: [PATCH 1/4] arm64: dts: imx8ulp: add usb nodes
Message-ID: <20231214112442.2412079-1-xu.yang_2@nxp.com>

Add USB nodes on i.MX8ULP platform which has 2 USB controllers.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 64 ++++++++++++++++++++++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index c4a0082f30d3..ead1f57e08ef 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -28,6 +28,8 @@ aliases {
 		serial1 = &lpuart5;
 		serial2 = &lpuart6;
 		serial3 = &lpuart7;
+		usbphy0 = &usbphy1;
+		usbphy1 = &usbphy2;
 	};
 
 	cpus {
@@ -472,6 +474,68 @@ usdhc2: mmc at 298f0000 {
 				status = "disabled";
 			};
 
+			usbotg1: usb at 29900000 {
+				compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+				reg = <0x29900000 0x200>;
+				interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&pcc4 IMX8ULP_CLK_USB0>;
+				power-domains = <&scmi_devpd IMX8ULP_PD_USB0>;
+				phys = <&usbphy1>;
+				fsl,usbmisc = <&usbmisc1 0>;
+				ahb-burst-config = <0x0>;
+				tx-burst-size-dword = <0x8>;
+				rx-burst-size-dword = <0x8>;
+				status = "disabled";
+			};
+
+			usbmisc1: usbmisc at 29900200 {
+				compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+						"fsl,imx6q-usbmisc";
+				#index-cells = <1>;
+				reg = <0x29900200 0x200>;
+				status = "disabled";
+			};
+
+			usbphy1: usb-phy at 29910000 {
+				compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+				reg = <0x29910000 0x10000>;
+				interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&pcc4 IMX8ULP_CLK_USB0_PHY>;
+				#phy-cells = <0>;
+				status = "disabled";
+			};
+
+			usbotg2: usb at 29920000 {
+				compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+				reg = <0x29920000 0x200>;
+				interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&pcc4 IMX8ULP_CLK_USB1>;
+				power-domains = <&scmi_devpd IMX8ULP_PD_USDHC2_USB1>;
+				phys = <&usbphy2>;
+				fsl,usbmisc = <&usbmisc2 0>;
+				ahb-burst-config = <0x0>;
+				tx-burst-size-dword = <0x8>;
+				rx-burst-size-dword = <0x8>;
+				status = "disabled";
+			};
+
+			usbmisc2: usbmisc at 29920200 {
+				compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+						"fsl,imx6q-usbmisc";
+				#index-cells = <1>;
+				reg = <0x29920200 0x200>;
+				status = "disabled";
+			};
+
+			usbphy2: usb-phy at 29930000 {
+				compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+				reg = <0x29930000 0x10000>;
+				interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&pcc4 IMX8ULP_CLK_USB1_PHY>;
+				#phy-cells = <0>;
+				status = "disabled";
+			};
+
 			fec: ethernet at 29950000 {
 				compatible = "fsl,imx8ulp-fec", "fsl,imx6ul-fec", "fsl,imx6q-fec";
 				reg = <0x29950000 0x10000>;
-- 
2.34.1



From xu.yang_2 at nxp.com  Thu Dec 14 03:24:40 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 19:24:40 +0800
Subject: [PATCH 2/4] arm64: dts: imx8ulp-evk: enable usb nodes
In-Reply-To: <20231214112442.2412079-1-xu.yang_2@nxp.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
Message-ID: <20231214112442.2412079-2-xu.yang_2@nxp.com>

Enable 2 USB nodes on i.MX8ULP evk board.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 54 +++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 69dd8e31027c..08fadfe47785 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -135,6 +135,46 @@ pcal6408: gpio at 21 {
 	};
 };
 
+&usbotg1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_otgid1>;
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	over-current-active-low;
+	status = "okay";
+};
+
+&usbphy1 {
+	status = "okay";
+	fsl,tx-d-cal = <110>;
+};
+
+&usbmisc1 {
+	status = "okay";
+};
+
+&usbotg2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_otgid2>;
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	over-current-active-low;
+	status = "okay";
+};
+
+&usbphy2 {
+	status = "okay";
+	fsl,tx-d-cal = <110>;
+};
+
+&usbmisc2 {
+	status = "okay";
+};
+
 &usdhc0 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
 	pinctrl-0 = <&pinctrl_usdhc0>;
@@ -224,6 +264,20 @@ MX8ULP_PAD_PTE13__LPI2C7_SDA	0x20
 		>;
 	};
 
+	pinctrl_otgid1: usb1grp {
+		fsl,pins = <
+			MX8ULP_PAD_PTF2__USB0_ID	0x10003
+			MX8ULP_PAD_PTF4__USB0_OC	0x10003
+		>;
+	};
+
+	pinctrl_otgid2: usb2grp {
+		fsl,pins = <
+			MX8ULP_PAD_PTD23__USB1_ID	0x10003
+			MX8ULP_PAD_PTF6__USB1_OC	0x10003
+		>;
+	};
+
 	pinctrl_usdhc0: usdhc0grp {
 		fsl,pins = <
 			MX8ULP_PAD_PTD1__SDHC0_CMD	0x3
-- 
2.34.1



From xu.yang_2 at nxp.com  Thu Dec 14 03:24:41 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 19:24:41 +0800
Subject: [PATCH 3/4] arm64: dts: imx93: add usb nodes
In-Reply-To: <20231214112442.2412079-1-xu.yang_2@nxp.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
Message-ID: <20231214112442.2412079-3-xu.yang_2@nxp.com>

There are 2 USB controllers on i.MX93. Add them.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx93.dtsi | 58 ++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi b/arch/arm64/boot/dts/freescale/imx93.dtsi
index 34c0540276d1..bcf4861cfede 100644
--- a/arch/arm64/boot/dts/freescale/imx93.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
@@ -171,6 +171,20 @@ cm33: remoteproc-cm33 {
 		status = "disabled";
 	};
 
+	usbphynop1: usbphynop1 {
+		#phy-cells = <0>;
+		compatible = "usb-nop-xceiv";
+		clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
+		clock-names = "main_clk";
+	};
+
+	usbphynop2: usbphynop2 {
+		#phy-cells = <0>;
+		compatible = "usb-nop-xceiv";
+		clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
+		clock-names = "main_clk";
+	};
+
 	soc at 0 {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -1059,5 +1073,49 @@ ddr-pmu at 4e300dc0 {
 			reg = <0x4e300dc0 0x200>;
 			interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		};
+
+		usbotg1: usb at 4c100000 {
+			compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
+			reg = <0x4c100000 0x200>;
+			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
+				 <&clk IMX93_CLK_HSIO_32K_GATE>;
+			clock-names = "usb_ctrl_root_clk", "usb_wakeup_clk";
+			assigned-clocks = <&clk IMX93_CLK_HSIO>;
+			assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
+			assigned-clock-rates = <133000000>;
+			fsl,usbphy = <&usbphynop1>;
+			fsl,usbmisc = <&usbmisc1 0>;
+			status = "disabled";
+		};
+
+		usbmisc1: usbmisc at 4c100200 {
+			compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
+					"fsl,imx6q-usbmisc";
+			#index-cells = <1>;
+			reg = <0x4c100200 0x200>;
+		};
+
+		usbotg2: usb at 4c200000 {
+			compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
+			reg = <0x4c200000 0x200>;
+			interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
+				 <&clk IMX93_CLK_HSIO_32K_GATE>;
+			clock-names = "usb_ctrl_root_clk", "usb_wakeup_clk";
+			assigned-clocks = <&clk IMX93_CLK_HSIO>;
+			assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
+			assigned-clock-rates = <133000000>;
+			fsl,usbphy = <&usbphynop2>;
+			fsl,usbmisc = <&usbmisc2 0>;
+			status = "disabled";
+		};
+
+		usbmisc2: usbmisc at 4c200200 {
+			compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
+					"fsl,imx6q-usbmisc";
+			#index-cells = <1>;
+			reg = <0x4c200200 0x200>;
+		};
 	};
 };
-- 
2.34.1



From xu.yang_2 at nxp.com  Thu Dec 14 03:24:42 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 19:24:42 +0800
Subject: [PATCH 4/4] arm64: dts: imx93-11x11-evk: enable usb and typec nodes
In-Reply-To: <20231214112442.2412079-1-xu.yang_2@nxp.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
Message-ID: <20231214112442.2412079-4-xu.yang_2@nxp.com>

There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 .../boot/dts/freescale/imx93-11x11-evk.dts    | 108 ++++++++++++++++++
 1 file changed, 108 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
index 2b9d47716f75..42b1ea7d5220 100644
--- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/usb/pd.h>
 #include "imx93.dtsi"
 
 / {
@@ -103,6 +104,70 @@ &mu2 {
 	status = "okay";
 };
 
+&lpi2c3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&pinctrl_lpi2c3>;
+	pinctrl-1 = <&pinctrl_lpi2c3>;
+	status = "okay";
+
+	ptn5110: tcpc at 50 {
+		compatible = "nxp,ptn5110";
+		reg = <0x50>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+		status = "okay";
+
+		port {
+			typec1_dr_sw: endpoint {
+				remote-endpoint = <&usb1_drd_sw>;
+			};
+		};
+
+		typec1_con: connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+			power-role = "dual";
+			data-role = "dual";
+			try-power-role = "sink";
+			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+			sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+				     PDO_VAR(5000, 20000, 3000)>;
+			op-sink-microwatt = <15000000>;
+			self-powered;
+		};
+	};
+
+	ptn5110_2: tcpc at 51 {
+		compatible = "nxp,ptn5110";
+		reg = <0x51>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+		status = "okay";
+
+		port {
+			typec2_dr_sw: endpoint {
+				remote-endpoint = <&usb2_drd_sw>;
+			};
+		};
+
+		typec2_con: connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+			power-role = "dual";
+			data-role = "dual";
+			try-power-role = "sink";
+			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+			sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+				     PDO_VAR(5000, 20000, 3000)>;
+			op-sink-microwatt = <15000000>;
+			self-powered;
+		};
+	};
+};
+
 &eqos {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_eqos>;
@@ -155,6 +220,42 @@ &lpuart5 {
 	status = "okay";
 };
 
+&usbotg1 {
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	usb-role-switch;
+	disable-over-current;
+	samsung,picophy-pre-emp-curr-control = <3>;
+	samsung,picophy-dc-vol-level-adjust = <7>;
+	status = "okay";
+
+	port {
+		usb1_drd_sw: endpoint {
+			remote-endpoint = <&typec1_dr_sw>;
+		};
+	};
+};
+
+&usbotg2 {
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	usb-role-switch;
+	disable-over-current;
+	samsung,picophy-pre-emp-curr-control = <3>;
+	samsung,picophy-dc-vol-level-adjust = <7>;
+	status = "okay";
+
+	port {
+		usb2_drd_sw: endpoint {
+			remote-endpoint = <&typec2_dr_sw>;
+		};
+	};
+};
+
 &usdhc1 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz";
 	pinctrl-0 = <&pinctrl_usdhc1>;
@@ -221,6 +322,13 @@ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL	0x57e
 		>;
 	};
 
+	pinctrl_lpi2c3: lpi2c3grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO28__LPI2C3_SDA			0x40000b9e
+			MX93_PAD_GPIO_IO29__LPI2C3_SCL			0x40000b9e
+		>;
+	};
+
 	pinctrl_uart1: uart1grp {
 		fsl,pins = <
 			MX93_PAD_UART1_RXD__LPUART1_RX			0x31e
-- 
2.34.1



From xu.yang_2 at nxp.com  Thu Dec 14 03:26:20 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 19:26:20 +0800
Subject: [PATCH 1/3] usb: chipidea: ci_hdrc_imx: add wakeup clock and keep it always on
Message-ID: <20231214112622.2412321-1-xu.yang_2@nxp.com>

Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
on without usb driver intervention. And some may need driver to handle
this clock. This patch will get wakeup clock and keep it always on to
make controller work correctlly.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index e28bb2f2612d..4330be8240ff 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -96,6 +96,7 @@ struct ci_hdrc_imx_data {
 	struct usb_phy *phy;
 	struct platform_device *ci_pdev;
 	struct clk *clk;
+	struct clk *clk_wakeup;
 	struct imx_usbmisc_data *usbmisc_data;
 	bool supports_runtime_pm;
 	bool override_phy_control;
@@ -199,7 +200,7 @@ static int imx_get_clks(struct device *dev)
 
 	data->clk_ipg = devm_clk_get(dev, "ipg");
 	if (IS_ERR(data->clk_ipg)) {
-		/* If the platform only needs one clocks */
+		/* If the platform only needs one primary clock */
 		data->clk = devm_clk_get(dev, NULL);
 		if (IS_ERR(data->clk)) {
 			ret = PTR_ERR(data->clk);
@@ -208,6 +209,18 @@ static int imx_get_clks(struct device *dev)
 				PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
 			return ret;
 		}
+		/* Get wakeup clock. Not all of the platforms need to
+		 * handle this clock. So make it optional.
+		 */
+		data->clk_wakeup = devm_clk_get_optional(dev,
+							 "usb_wakeup_clk");
+		if (IS_ERR(data->clk_wakeup)) {
+			ret = PTR_ERR(data->clk_wakeup);
+			dev_err(dev,
+				"Failed to get wakeup clk, err=%ld\n",
+				PTR_ERR(data->clk_wakeup));
+			return ret;
+		}
 		return ret;
 	}
 
@@ -423,6 +436,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 	if (ret)
 		goto disable_hsic_regulator;
 
+	ret = clk_prepare_enable(data->clk_wakeup);
+	if (ret)
+		goto err_wakeup_clk;
+
 	data->phy = devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0);
 	if (IS_ERR(data->phy)) {
 		ret = PTR_ERR(data->phy);
@@ -504,6 +521,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 disable_device:
 	ci_hdrc_remove_device(data->ci_pdev);
 err_clk:
+	clk_disable_unprepare(data->clk_wakeup);
+err_wakeup_clk:
 	imx_disable_unprepare_clks(dev);
 disable_hsic_regulator:
 	if (data->hsic_pad_regulator)
@@ -530,6 +549,7 @@ static void ci_hdrc_imx_remove(struct platform_device *pdev)
 		usb_phy_shutdown(data->phy);
 	if (data->ci_pdev) {
 		imx_disable_unprepare_clks(&pdev->dev);
+		clk_disable_unprepare(data->clk_wakeup);
 		if (data->plat_data->flags & CI_HDRC_PMQOS)
 			cpu_latency_qos_remove_request(&data->pm_qos_req);
 		if (data->hsic_pad_regulator)
-- 
2.34.1



From xu.yang_2 at nxp.com  Thu Dec 14 03:26:21 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 19:26:21 +0800
Subject: [PATCH 2/3] usb: chipidea: wait controller resume finished for wakeup irq
In-Reply-To: <20231214112622.2412321-1-xu.yang_2@nxp.com>
References: <20231214112622.2412321-1-xu.yang_2@nxp.com>
Message-ID: <20231214112622.2412321-2-xu.yang_2@nxp.com>

After the chipidea driver introduce extcon for id and vbus, it's able
to wakeup from another irq source, in case the system with extcon ID
cable, wakeup from usb ID cable and device removal, the usb device
disconnect irq may come firstly before the extcon notifier while system
resume, so we will get 2 "wakeup" irq, one for usb device disconnect;
and one for extcon ID cable change(real wakeup event), current driver
treat them as 2 successive wakeup irq so can't handle it correctly, then
finally the usb irq can't be enabled. This patch adds a check to bypass
further usb events before controller resume finished to fix it.

Fixes: 1f874edcb731 ("usb: chipidea: add runtime power management support")
cc: <stable at vger.kernel.org>
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
Signed-off-by: Li Jun <jun.li at nxp.com>
---
 drivers/usb/chipidea/core.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 7ac39a281b8c..85e9c3ab66e9 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -523,6 +523,13 @@ static irqreturn_t ci_irq_handler(int irq, void *data)
 	u32 otgsc = 0;
 
 	if (ci->in_lpm) {
+		/*
+		 * If we already have a wakeup irq pending there,
+		 * let's just return to wait resume finished firstly.
+		 */
+		if (ci->wakeup_int)
+			return IRQ_HANDLED;
+
 		disable_irq_nosync(irq);
 		ci->wakeup_int = true;
 		pm_runtime_get(ci->dev);
-- 
2.34.1



From xu.yang_2 at nxp.com  Thu Dec 14 03:26:22 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 19:26:22 +0800
Subject: [PATCH 3/3] usb: phy: mxs: remove CONFIG_USB_OTG condition for mxs_phy_is_otg_host()
In-Reply-To: <20231214112622.2412321-1-xu.yang_2@nxp.com>
References: <20231214112622.2412321-1-xu.yang_2@nxp.com>
Message-ID: <20231214112622.2412321-3-xu.yang_2@nxp.com>

When CONFIG_USB_OTG is not set, mxs_phy_is_otg_host() will always return
false. This behaviour is wrong. Since phy.last_event will always be set
for either host or device mode. Therefore, CONFIG_USB_OTG condition
can be removed.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
---
 drivers/usb/phy/phy-mxs-usb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index acd46b72899e..920a32cd094d 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -388,8 +388,7 @@ static void __mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool disconnect)
 
 static bool mxs_phy_is_otg_host(struct mxs_phy *mxs_phy)
 {
-	return IS_ENABLED(CONFIG_USB_OTG) &&
-		mxs_phy->phy.last_event == USB_EVENT_ID;
+	return mxs_phy->phy.last_event == USB_EVENT_ID;
 }
 
 static void mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool on)
-- 
2.34.1



From festevam at gmail.com  Thu Dec 14 03:25:05 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 14 Dec 2023 08:25:05 -0300
Subject: [PATCH 4/4] arm64: dts: imx93-11x11-evk: enable usb and typec nodes
In-Reply-To: <20231214112442.2412079-4-xu.yang_2@nxp.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com> <20231214112442.2412079-4-xu.yang_2@nxp.com>
Message-ID: <CAOMZO5AXB8h6+fqPO3aCsa1=-etRzPMZSLn7Kca6egUmUX822Q@mail.gmail.com>

On Thu, Dec 14, 2023 at 8:19?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
>
> There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.
>
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> ---
>  .../boot/dts/freescale/imx93-11x11-evk.dts    | 108 ++++++++++++++++++
>  1 file changed, 108 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> index 2b9d47716f75..42b1ea7d5220 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> @@ -5,6 +5,7 @@
>
>  /dts-v1/;
>
> +#include <dt-bindings/usb/pd.h>
>  #include "imx93.dtsi"
>
>  / {
> @@ -103,6 +104,70 @@ &mu2 {
>         status = "okay";
>  };
>
> +&lpi2c3 {
> +       #address-cells = <1>;
> +       #size-cells = <0>;
> +       clock-frequency = <400000>;
> +       pinctrl-names = "default", "sleep";
> +       pinctrl-0 = <&pinctrl_lpi2c3>;
> +       pinctrl-1 = <&pinctrl_lpi2c3>;
> +       status = "okay";
> +
> +       ptn5110: tcpc at 50 {
> +               compatible = "nxp,ptn5110";
> +               reg = <0x50>;
> +               interrupt-parent = <&gpio3>;
> +               interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> +               status = "okay";
> +
> +               port {
> +                       typec1_dr_sw: endpoint {
> +                               remote-endpoint = <&usb1_drd_sw>;
> +                       };
> +               };
> +
> +               typec1_con: connector {
> +                       compatible = "usb-c-connector";
> +                       label = "USB-C";
> +                       power-role = "dual";
> +                       data-role = "dual";
> +                       try-power-role = "sink";
> +                       source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> +                       sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
> +                                    PDO_VAR(5000, 20000, 3000)>;
> +                       op-sink-microwatt = <15000000>;
> +                       self-powered;

Your patch introduce dt-schema warnings.

Port should be placed under connector as per nxp,ptn5110.yaml.

Please check:
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next&id=de0bae0b75f288381746bb9f6d6fd1b30f397975


From festevam at gmail.com  Thu Dec 14 03:25:36 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 14 Dec 2023 08:25:36 -0300
Subject: [PATCH 3/3] usb: phy: mxs: remove CONFIG_USB_OTG condition for mxs_phy_is_otg_host()
In-Reply-To: <20231214112622.2412321-3-xu.yang_2@nxp.com>
References: <20231214112622.2412321-1-xu.yang_2@nxp.com> <20231214112622.2412321-3-xu.yang_2@nxp.com>
Message-ID: <CAOMZO5CRj2yry0Hm6wjueX0PQi+aWXNptqnyu=Ai1CYWVJC0nA@mail.gmail.com>

On Thu, Dec 14, 2023 at 8:20?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
>
> When CONFIG_USB_OTG is not set, mxs_phy_is_otg_host() will always return
> false. This behaviour is wrong. Since phy.last_event will always be set
> for either host or device mode. Therefore, CONFIG_USB_OTG condition
> can be removed.
>
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

Fixes tag?


From xueshuai at linux.alibaba.com  Thu Dec 14 03:26:55 2023
From: xueshuai at linux.alibaba.com (Shuai Xue)
Date: Thu, 14 Dec 2023 19:26:55 +0800
Subject: [PATCH v12 0/5] drivers/perf: add Synopsys DesignWare PCIe PMU
 driver support
In-Reply-To: <170247454282.4025634.10934949931800191482.b4-ty@kernel.org>
References: <20231208025652.87192-1-xueshuai@linux.alibaba.com>
 <170247454282.4025634.10934949931800191482.b4-ty@kernel.org>
Message-ID: <e047da91-4a15-4864-bcda-9717170dab7e@linux.alibaba.com>



On 2023/12/14 01:25, Will Deacon wrote:
> On Fri, 8 Dec 2023 10:56:47 +0800, Shuai Xue wrote:
>> Change Log
>> ==========
>> change sinces v11:
>> - Fix uninitialized symbol 'now' (Per Dan and Will)
>> - Pick up Reviewed-and-tested-by tag from Ilkka for Patch 4/5
>>
>> change sinces v10:
>> - Rename to pci_clear_and_set_config_dword() to retain the "config"
>>   information and match the other accessors. (Per Bjorn)
>> - Align pci_clear_and_set_config_dword() and its call site (Per Bjorn)
>> - Polish commit log (Per Bjorn)
>> - Simplify dwc_pcie_pmu_time_based_event_enable() with bool value (Per Ilkka)
>> - Fix dwc_pcie_register_dev() return value (Per Ilkka)
>> - Fix vesc capability discovery by pdev->vendor (Per Ilkka)
>> - pick up Acked-by tag from Bjorn for Patch 3/5
>> - pick up Tested-by tag from Ilkka for all patch set
>>
>> [...]
> 
> Applied to will (for-next/perf), thanks!
> 
> [1/5] docs: perf: Add description for Synopsys DesignWare PCIe PMU driver
>       https://git.kernel.org/will/c/cae40614cdd6
> [2/5] PCI: Add Alibaba Vendor ID to linux/pci_ids.h
>       https://git.kernel.org/will/c/ad6534c626fe
> [3/5] PCI: Move pci_clear_and_set_dword() helper to PCI header
>       https://git.kernel.org/will/c/ac16087134b8
> [4/5] drivers/perf: add DesignWare PCIe PMU driver
>       https://git.kernel.org/will/c/af9597adc2f1
> [5/5] MAINTAINERS: add maintainers for DesignWare PCIe PMU driver
>       https://git.kernel.org/will/c/f56bb3de66bc
> 
> Cheers,

Really a good news for me. Thank you very much:)

And thanks to all patient and nice reviewers.

Cheers,
Shuai


From dan.carpenter at linaro.org  Thu Dec 14 03:30:39 2023
From: dan.carpenter at linaro.org (Dan Carpenter)
Date: Thu, 14 Dec 2023 14:30:39 +0300
Subject: [PATCH v9 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <43a8bfff-f939-4f2d-a8cd-97306d5e44c9@arm.com>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207161211.2374093-5-ryan.roberts@arm.com>
 <cb1fe352-ca47-4c3b-ab51-ecf51a83ce50@moroto.mountain>
 <43a8bfff-f939-4f2d-a8cd-97306d5e44c9@arm.com>
Message-ID: <e2da3c78-85f7-4516-bbab-97fac9629dcc@suswa.mountain>

On Thu, Dec 14, 2023 at 10:54:19AM +0000, Ryan Roberts wrote:
> On 13/12/2023 07:21, Dan Carpenter wrote:
> > On Thu, Dec 07, 2023 at 04:12:05PM +0000, Ryan Roberts wrote:
> >> @@ -4176,10 +4260,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
> >>  	/* Allocate our own private page. */
> >>  	if (unlikely(anon_vma_prepare(vma)))
> >>  		goto oom;
> >> -	folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
> >> +	folio = alloc_anon_folio(vmf);
> >> +	if (IS_ERR(folio))
> >> +		return 0;
> >>  	if (!folio)
> >>  		goto oom;
> > 
> > Returning zero is weird.  I think it should be a vm_fault_t code.
> 
> It's the same pattern that the existing code a little further down this function
> already implements:
> 
> 	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
> 	if (!vmf->pte)
> 		goto release;
> 
> If we fail to map/lock the pte (due to a race), then we return 0 to allow user
> space to rerun the faulting instruction and cause the fault to happen again. The
> above code ends up calling "return ret;" and ret is 0.
> 

Ah, okay.  Thanks!

> > 
> > This mixing of error pointers and NULL is going to cause problems.
> > Normally when we have a mix of error pointers and NULL then the NULL is
> > not an error but instead means that the feature has been deliberately
> > turned off.  I'm unable to figure out what the meaning is here.
> 
> There are 3 conditions that the function can return:
> 
>  - folio successfully allocated
>  - folio failed to be allocated due to OOM
>  - fault needs to be tried again due to losing race
> 
> Previously only the first 2 conditions were possible and they were indicated by
> NULL/not-NULL. The new 3rd condition is only possible when THP is compile-time
> enabled. So it keeps the logic simpler to keep the NULL/not-NULL distinction for
> the first 2, and use the error code for the final one.
> 
> There are IS_ERR() and IS_ERR_OR_NULL() variants so I assume a pattern where you
> can have pointer, error or NULL is somewhat common already?

People are confused by this a lot so I have written a blog about it:

https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/

The IS_ERR_OR_NULL() function should be used like this:

int blink_leds()
{
	led = get_leds();
	if (IS_ERR_OR_NULL(led))
		return PTR_ERR(led);  <-- NULL means zero/success
	return led->blink();
}

In the case of alloc_anon_folio(), I would be tempted to create a
wrapper around it where NULL becomes ERR_PTR(-ENOMEM).  But this is
obviously fast path code and I haven't benchmarked it.

Adding a comment is the other option.

regards,
dan carpenter



From festevam at gmail.com  Thu Dec 14 03:30:33 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 14 Dec 2023 08:30:33 -0300
Subject: [PATCH 2/4] arm64: dts: imx8ulp-evk: enable usb nodes
In-Reply-To: <20231214112442.2412079-2-xu.yang_2@nxp.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com> <20231214112442.2412079-2-xu.yang_2@nxp.com>
Message-ID: <CAOMZO5CgzioWKjWkhmQjL58GGGmDSsm9SD1f6YAX2EyM0DNJtA@mail.gmail.com>

On Thu, Dec 14, 2023 at 8:19?AM Xu Yang <xu.yang_2 at nxp.com> wrote:

> +&usbphy1 {
> +       status = "okay";
> +       fsl,tx-d-cal = <110>;

Place status as the last property.

> +&usbphy2 {
> +       status = "okay";
> +       fsl,tx-d-cal = <110>;

Place status as the last property.

> +};
> +
> +&usbmisc2 {
> +       status = "okay";
> +};
> +
>  &usdhc0 {
>         pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
>         pinctrl-0 = <&pinctrl_usdhc0>;
> @@ -224,6 +264,20 @@ MX8ULP_PAD_PTE13__LPI2C7_SDA       0x20
>                 >;
>         };
>
> +       pinctrl_otgid1: usb1grp {

pinctrl_ubs1: usb1grp

> +               fsl,pins = <
> +                       MX8ULP_PAD_PTF2__USB0_ID        0x10003
> +                       MX8ULP_PAD_PTF4__USB0_OC        0x10003
> +               >;
> +       };
> +
> +       pinctrl_otgid2: usb2grp {

pinctrl_usb2: usb2grp


From mripard at kernel.org  Thu Dec 14 03:33:40 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 14 Dec 2023 12:33:40 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-5-knaerzche@gmail.com>
 <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
 <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com>
Message-ID: <db3kdzy4ogf3o2fd6apr36s44qitcsxksfkfa2oc77s5y6dv2w@kfji4iszthxa>

On Thu, Dec 14, 2023 at 12:12:08PM +0100, Alex Bee wrote:
> Hi Maxime
> 
> Am 14.12.23 um 08:56 schrieb Maxime Ripard:
> > Hi Alex,
> > 
> > Thanks for working on this!
> > 
> > On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
> > > The display controller will always give full range RGB regardless of the
> > > mode set, but HDMI requires certain modes to be transmitted in limited
> > > range RGB. This is especially required for HDMI sinks which do not support
> > > non-standard quantization ranges.
> > > 
> > > This enables color space conversion for those modes and sets the
> > > quantization range accordingly in the AVI infoframe.
> > > 
> > > Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> > > Signed-off-by: Alex Bee <knaerzche at gmail.com>
> > > ---
> > >   drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
> > >   1 file changed, 32 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > index 345253e033c5..32626a75723c 100644
> > > --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > @@ -33,6 +33,7 @@ struct hdmi_data_info {
> > >   	unsigned int enc_in_format;
> > >   	unsigned int enc_out_format;
> > >   	unsigned int colorimetry;
> > > +	bool rgb_limited_range;
> > >   };
> > >   struct inno_hdmi_i2c {
> > > @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
> > >   	else
> > >   		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> > > +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
> > > +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> > > +						   &hdmi->connector, mode,
> > > +						   hdmi->hdmi_data.rgb_limited_range ?
> > > +						   HDMI_QUANTIZATION_RANGE_LIMITED :
> > > +						   HDMI_QUANTIZATION_RANGE_FULL);
> > > +	} else {
> > > +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> > > +		frame.avi.ycc_quantization_range =
> > > +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> > > +	}
> > > +
> > >   	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
> > >   }
> > > @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
> > >   	if (data->enc_in_format == data->enc_out_format) {
> > >   		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
> > >   		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
> > > -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> > > -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> > > -
> > > -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> > > -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> > > -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> > > -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> > > -			return 0;
> > > +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
> > > +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
> > > +			    hdmi->hdmi_data.rgb_limited_range) {
> > > +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
> > > +				auto_csc = AUTO_CSC_DISABLE;
> > > +				c0_c2_change = C0_C2_CHANGE_DISABLE;
> > > +				csc_enable = v_CSC_ENABLE;
> > > +			} else {
> > > +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> > > +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> > > +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> > > +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> > > +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> > > +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> > > +				return 0;
> > > +			}
> > >   		}
> > >   	}
> > > @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
> > >   	else
> > >   		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
> > > +	hdmi->hdmi_data.rgb_limited_range =
> > > +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
> > > +
> > This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
> > https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/
>
> I'm aware of that and I mentioned it in the cover letter.

Sorry, I missed that part.

> Your series is not merged yet and it didn't get much feedback so far.
> What is the status there?

It didn't have much reviews, but I'll hope to change that. For the
patches 22 to 38 though, it doesn't really matter. Those changes are
self-contained and can be applied as is outside of the series.

> Especially because you are removing things from inno-hdmi driver (which
> aren't really required to remove there) which will I have to reintroduce.

I'm not entirely sure which part I remove that are actually going to be
used here.

> > I would appreciate if you could test and merge them into your series.
> > 
> > In particular, there's no need to store the range here: enc_out_format
>
> rgb_limited_range is currently not only used for csc, but also for for
> infoframe creation. So it makes sense to have this stored? to avoid calling
> drm_default_rgb_quant_range twice.

You're right, I missed one. Still, it shouldn't be stored in the
hdmi_data_info structure, it's tied to the mode, and the mode is part of
the state, so it's not a property to a given device, but it's tied to
the connector state.

So if you want to do so, you should really create a custom state
structure and store the range there, just like vc4 is doing for example.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/aea9e524/attachment.sig>

From Jianheng.Zhang at synopsys.com  Thu Dec 14 03:35:07 2023
From: Jianheng.Zhang at synopsys.com (Jianheng Zhang)
Date: Thu, 14 Dec 2023 11:35:07 +0000
Subject: [PATCH v2 net-next] net: stmmac: xgmac3+: add FPE handshaking
 support
In-Reply-To: <20231213004311.nptkcubaxuiineec@skbuf>
References: <CY5PR12MB63727C24923AE855CFF0D425BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com>
 <20231212152347.167007f3@kernel.org> <20231213004311.nptkcubaxuiineec@skbuf>
Message-ID: <CY5PR12MB6372C564179B362B7B41D081BF8CA@CY5PR12MB6372.namprd12.prod.outlook.com>


> -----Original Message-----
> From: Vladimir Oltean <olteanv at gmail.com>
> Sent: Wednesday, December 13, 2023 8:43 AM
> To: Jianheng Zhang <jianheng at synopsys.com>; Jakub Kicinski <kuba at kernel.org>
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>; Jose Abreu <joabreu at synopsys.com>; David S.
> Miller <davem at davemloft.net>; Eric Dumazet <edumazet at google.com>; Paolo Abeni
> <pabeni at redhat.com>; Maxime Coquelin <mcoquelin.stm32 at gmail.com>; James Li
> <lijames at synopsys.com>; Martin McKenny <mmckenny at synopsys.com>; open list:STMMAC ETHERNET
> DRIVER <netdev at vger.kernel.org>; moderated list:ARM/STM32 ARCHITECTURE
> <linux-stm32 at st-md-mailman.stormreply.com>; moderated list:ARM/STM32 ARCHITECTURE
> <linux-arm-kernel at lists.infradead.org>; open list <linux-kernel at vger.kernel.org>
> Subject: Re: [PATCH v2 net-next] net: stmmac: xgmac3+: add FPE handshaking support
> 
> On Tue, Dec 12, 2023 at 03:23:47PM -0800, Jakub Kicinski wrote:
> > On Tue, 12 Dec 2023 14:05:02 +0000 Jianheng Zhang wrote:
> > > Adds the HW specific support for Frame Preemption handshaking on XGMAC3+
> > > cores.
> > >
> > > Signed-off-by: Jianheng Zhang <Jianheng.Zhang at synopsys.com>
> >
> > I defer to Vladimir on whether to trust that the follow up with
> > the ethtool API support will come later (and not require rewrite
> > of existing code); or we should request that it's part of the same
> > series.
> > --
> > pw-bot: needs-ack
> >
> 
> Here's the thing - my understanding of what Synopsys is doing is that
> they use TC_TAPRIO_CMD_SET_AND_HOLD and TC_TAPRIO_CMD_SET_AND_RELEASE
> as implicit hints to the stmmac driver that FPE should be enabled.
> 
> Hold/Release is merely one use case for frame preemption. The "fp"
> argument in the tc framework gives you access to the rest: preemption
> without scheduling, preemption with scheduling but without hold/release.
> 
> And the ethtool-mm framework gives you compatibility with LLDP, so you
> can adjust the minimum fragment sizes according to the link partner.
> Roger Quadros is adding am65-cpsw support for FPE using the generic
> framework, and the TI device has an erratum that the minimum fragment
> size that can be received cannot be lower than 124 bytes. LLDP allows
> link partners to discover that and still interoperate - which is very
> important, because if first-gen TSN hardware, with all its pre-standard
> quirks, does not deliver, there may not be a second-gen.
> 
> By using LLDP, you can also enable the FPE handshake based on user space
> input - when the LLDP daemon gets an LLDPDU with an Additional Ethernet
> Capabilities TLV, rather than during each and every stmmac_mac_link_up(),
> and hoping for someone to respond. Depending on your hardware design,
> this can even lead to power savings, because you can power on your pMAC
> only when LLDP says the link partner is also capable, and it will be required.
> 
> Ethtool also gives you the ability to report standardized stats per eMAC
> and per pMAC, and standardized stats for the MAC Merge layer itself.
> 
> Also, the FPE state machine from the stmmac driver is so chatty and
> spams the kernel log so bad, because it has nowhere else to report its
> current (fragile) state. The ethtool MAC Merge layer gives the driver
> a way to report its verification state ("FPE Handshake" as Synopsys
> calls it) in a standardized enum.
> 
> A small note that the mainline iproute2 does not even expose the
> TC_TAPRIO_CMD_SET_AND_HOLD and TC_TAPRIO_CMD_SET_AND_RELEASE netlink
> attribute values. To quote from the manpage (which is not out of date
> with the code; I checked - again): 'The only supported <command> is "S",
> which means "SetGateStates"'.
> 
> So I can only guess that Synopsys and anyone else who wants to turn on
> FPE on stmmac has to patch their iproute2. A Github code search made me
> land here:
> https://urldefense.com/v3/__https://github.com/altera-opensource/meta-intel-fpga-refdes/blob/7b050c
> a9968f5ff71598e86bb3a10bb8e011439c/recipes-connectivity/iproute2/iproute2/0003-taprio-Add-suppo
> rt-for-the-SetAndHold-and-SetAndRele.patch__;!!A4F2R9G_pg!cj_LK6iKkOj8RlYyKdNK6wv23ddmwT3_3
> ebNC0gb97xaKddBhm2B0uAZMIffG5vxyRHCcbyez2aY-JaDt-tNTg$
> 
> In principle there's nothing wrong with not sharing patches on community
> software with the rest of the world. But I cannot help but get the
> impression that stmmac support for FPE is abandonware / extremely low
> priority / code written to tick the boxes. It's not in the best state
> even in the "good" case where the XGMAC3+ support gets accepted.
> Jianheng, please contradict me by showing what testing is currently
> conducted with this implementation. If none or close to that, let's get
> it to a more "observable" state, where at least others' tests could be
> reused.
> 
> Even this very patch is slightly strange - it is not brand new hardware
> support, but it fills in some more FPE ops in dwxlgmac2_ops - when
> dwxgmac3_fpe_configure() was already there. So this suggests the
> existing support was incomplete. How complete is it now? No way to tell.
> There is a selftest to tell, but we can't run it because the driver
> doesn't integrate with those kernel APIs.
> 
> There are long periods of radio silence from Synopsys engineers in upstream,
> and as maintainers we simply don't know what stmmac's FPE implementation
> does and what it doesn't do. If a future user gets into trouble, having
> a "known good" bisection point, by means of a selftest that passes, is
> going to allow even non-expert maintainers like us provide some help,
> even if Synopsys engineers go radio silent again.
> 
> It may be that Jianheng just needs a little nudge to help the management
> prioritize, by getting a NACK. It's a simple "help us help you" situation:
> the framework is there and it is a gateway for better Linux user space
> support for your platform, you just need to use it. And what better time
> to integrate with new API than with new hardware... :) Because it's not
> as if FPE on XGMAC3+ ever worked in mainline given my reading of the code.
> So why would users not start learning to use it with what is becoming
> the common tool set for everybody else.
> 
> Allow me to change the "needs-ack" into:
> 
> pw-bot: cr

Hi Vladimir,

Your insights into the current state of FPE support in the stmmac driver are 
indeed on point. It's accurate that the existing FPE support of stmmac relies 
on the mentioned patch. Before the emergence of the ethtool-mm framework, some 
users might have been able to use the FP function in this way. But with the 
introduction of the common ethtool-mm framework, it is more important to update 
the existing stmmac FPE implementation to support ethtool. And I now fully 
understand that it would not be appropriate to add xgmac support for FPE based 
on the current implementation. I appreciate you pointing out the problems with 
the current implementation and providing suggestions, they are incredibly 
helpful for the subsequent refactoring of stmmac's FPE functionality.  

Jianheng


From mripard at kernel.org  Thu Dec 14 03:36:05 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 14 Dec 2023 12:36:05 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <3053311.k3LOHGUjKi@diego>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
 <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com>
 <3053311.k3LOHGUjKi@diego>
Message-ID: <qr7if2k76wdqgevdcwqxj2dkcbga72owjqlk3qaazujhejjloo@cnvmuq27qqns>

On Thu, Dec 14, 2023 at 12:17:34PM +0100, Heiko St?bner wrote:
> Am Donnerstag, 14. Dezember 2023, 12:12:08 CET schrieb Alex Bee:
> > Hi Maxime
> > 
> > Am 14.12.23 um 08:56 schrieb Maxime Ripard:
> > > Hi Alex,
> > >
> > > Thanks for working on this!
> > >
> > > On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
> > >> The display controller will always give full range RGB regardless of the
> > >> mode set, but HDMI requires certain modes to be transmitted in limited
> > >> range RGB. This is especially required for HDMI sinks which do not support
> > >> non-standard quantization ranges.
> > >>
> > >> This enables color space conversion for those modes and sets the
> > >> quantization range accordingly in the AVI infoframe.
> > >>
> > >> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> > >> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> > >> ---
> > >>   drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
> > >>   1 file changed, 32 insertions(+), 8 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > >> index 345253e033c5..32626a75723c 100644
> > >> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> > >> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > >> @@ -33,6 +33,7 @@ struct hdmi_data_info {
> > >>   	unsigned int enc_in_format;
> > >>   	unsigned int enc_out_format;
> > >>   	unsigned int colorimetry;
> > >> +	bool rgb_limited_range;
> > >>   };
> > >>   
> > >>   struct inno_hdmi_i2c {
> > >> @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
> > >>   	else
> > >>   		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> > >>   
> > >> +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
> > >> +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> > >> +						   &hdmi->connector, mode,
> > >> +						   hdmi->hdmi_data.rgb_limited_range ?
> > >> +						   HDMI_QUANTIZATION_RANGE_LIMITED :
> > >> +						   HDMI_QUANTIZATION_RANGE_FULL);
> > >> +	} else {
> > >> +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> > >> +		frame.avi.ycc_quantization_range =
> > >> +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> > >> +	}
> > >> +
> > >>   	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
> > >>   }
> > >>   
> > >> @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
> > >>   	if (data->enc_in_format == data->enc_out_format) {
> > >>   		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
> > >>   		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
> > >> -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> > >> -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> > >> -
> > >> -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> > >> -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> > >> -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> > >> -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> > >> -			return 0;
> > >> +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
> > >> +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
> > >> +			    hdmi->hdmi_data.rgb_limited_range) {
> > >> +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
> > >> +				auto_csc = AUTO_CSC_DISABLE;
> > >> +				c0_c2_change = C0_C2_CHANGE_DISABLE;
> > >> +				csc_enable = v_CSC_ENABLE;
> > >> +			} else {
> > >> +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> > >> +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> > >> +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> > >> +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> > >> +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> > >> +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> > >> +				return 0;
> > >> +			}
> > >>   		}
> > >>   	}
> > >>   
> > >> @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
> > >>   	else
> > >>   		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
> > >>   
> > >> +	hdmi->hdmi_data.rgb_limited_range =
> > >> +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
> > >> +
> > > This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
> > > https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/
> > I'm aware of that and I mentioned it in the cover letter. Your series is 
> > not merged yet and it didn't get much feedback so far. What is the 
> > status there? Especially because you are removing things from inno-hdmi 
> > driver (which aren't really required to remove there) which will I have 
> > to reintroduce.
> 
> Sadly I haven't found the time to look closer at Maxime's series so far,
> but I got the impression that it separates into multiple cleanup steps
> for a number of controllers.

Yeah, one of the previous version comment was to support more
controllers than vc4, which is fair. So I ended up reworking and
converting multiple controllers, but most of the clean up changes can be
applied outside of that series just fine.

I just didn't find someone to test / review them yet :)

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/1873aab4/attachment.sig>

From yangyicong at huawei.com  Thu Dec 14 03:39:51 2023
From: yangyicong at huawei.com (Yicong Yang)
Date: Thu, 14 Dec 2023 19:39:51 +0800
Subject: [PATCH v4 0/4] Support SMT control on arm64
In-Reply-To: <20231211131612.GB25681@willie-the-truck>
References: <20231121092602.47792-1-yangyicong@huawei.com>
 <20231211131612.GB25681@willie-the-truck>
Message-ID: <fe03425c-6b9a-f0eb-0e8d-e0f47404a7cb@huawei.com>

Hi Will,

On 2023/12/11 21:16, Will Deacon wrote:
> On Tue, Nov 21, 2023 at 05:25:58PM +0800, Yicong Yang wrote:
>> From: Yicong Yang <yangyicong at hisilicon.com>
>>
>> The core CPU control framework supports runtime SMT control which
>> is not yet supported on arm64. Besides the general vulnerabilities
>> concerns we want this runtime control on our arm64 server for:
>>
>> - better single CPU performance in some cases
>> - saving overall power consumption
>>
>> This patchset implements it in the following aspects:
>>
>> - implements the basic support in arch_topology driver
>> - support retrieve SMT thread number on OF based system
>> - support retrieve SMT thread number on ACPI based system
>> - select HOTPLUG_SMT for arm64
>>
>> Tests has been done on our real ACPI based arm64 server and on
>> ACPI/OF based QEMU VMs.
>>
>> The patchset is based on v6.7-rc1.
>>
>> Change since v3:
>> - Fix some build and kconfig error reported by kernel test robot <lkp at intel.com>
>> Link: https://lore.kernel.org/linux-arm-kernel/20231114040110.54590-1-yangyicong at huawei.com/
>>
>> Change since v2:
>> - Detect SMT thread number at topology build from ACPI/DT, avoid looping CPUs
>> - Split patches into ACPI/OF/arch_topology path and enable the kconfig for arm64
>> Link: https://lore.kernel.org/linux-arm-kernel/20231010115335.13862-1-yangyicong at huawei.com/
>>
>> Yicong Yang (4):
>>   arch_topology: Support basic SMT control for the driver
>>   arch_topology: Support SMT control for OF based system
> 
> Looking at the first two patches you have here, they are incredibly trivial
> and feel like they'd be better off implemented as the default behaviour in
> the core code so that architectures with additional constraints (e.g. x86)
> can override that.
> 

Loop Thomas and Peter in and expect some hint on the SMT HOTPLUG implementation.

Thanks for the comments. I'm a bit uncertain of some points.

Currently the framework requires the architeture provide 2 things to enable HOTPLUG_SMT:
1. In the init stage of the arch code, use cpu_smt_set_num_threads() to tell the framework
   SMT is supported or not and how many threads are within a core.
2. topology_is_primary_thread() to indicate one CPU can be offline or not, when disable SMT.

For the 2nd point, it's possible to provide a weak function in the framework if no special
requirement for the "primary" SMT thread, just make the 1st CPU in a physical core as the
primary thread like what implemented in this patchset for amr64. And let architectures like
x86/powerpc to provides override function for special purpose.

For the 1st point I'm not sure it could/should be done in the framework since we can got this
SMT information only in the init stage after we parsing the topology which is rather architecture
specific. On arm64 we may gain this after parsing the devicetree or ACPI and on x86 they gain
this by CPUID. It's hard to provide a default way for detecting this. So in this patchset the
SMT information is detected separately in the ACPI/OF topology parsing.

Thanks.



From mripard at kernel.org  Thu Dec 14 03:40:16 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 14 Dec 2023 12:40:16 +0100
Subject: [PATCH 07/11] drm/rockchip: inno_hdmi: Add basic mode validation
In-Reply-To: <1b7402b2-ec03-420b-a81b-3e6ea46e402a@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-8-knaerzche@gmail.com>
 <wz4e43ateg3gb7745mz22wwyruwavevvpfbqsdxeynejcjxhzn@qbqldsnkktei>
 <1b7402b2-ec03-420b-a81b-3e6ea46e402a@gmail.com>
Message-ID: <k7ry5xsrmc5bi46pwbkphq4wo3jd5uutnezvttue2eh7sabkby@wvimbjamzg32>

On Thu, Dec 14, 2023 at 12:17:39PM +0100, Alex Bee wrote:
> Hi Maxime,
> 
> Am 14.12.23 um 09:05 schrieb Maxime Ripard:
> > Hi,
> > 
> > On Wed, Dec 13, 2023 at 08:51:21PM +0100, Alex Bee wrote:
> > > As per TRM this controller supports pixelclocks starting from 25 MHz. The
> > > maximum supported pixelclocks are defined by the phy configurations we
> > > have. Also it can't support modes that require doubled clocks.
> > > If there is a phy reference clock we can additionally validate against
> > > VESA DMT's recommendations.
> > > Those checks are added to the mode_valid hook of the connector and
> > > encoder's mode_fixup hook.
> > > 
> > > Signed-off-by: Alex Bee <knaerzche at gmail.com>
> > > ---
> > >   drivers/gpu/drm/rockchip/inno_hdmi.c | 38 ++++++++++++++++++++++++++--
> > >   1 file changed, 36 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > index f7f0bec725f9..2f839ff31c1c 100644
> > > --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > @@ -38,6 +38,8 @@ struct inno_hdmi_variant {
> > >   	struct inno_hdmi_phy_config *default_phy_config;
> > >   };
> > > +#define INNO_HDMI_MIN_TMDS_CLOCK  25000000U
> > > +
> > >   struct hdmi_data_info {
> > >   	int vic;
> > >   	bool sink_has_audio;
> > > @@ -572,6 +574,34 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
> > >   	return 0;
> > >   }
> > > +static enum drm_mode_status inno_hdmi_mode_valid(struct inno_hdmi *hdmi,
> > > +						 struct drm_display_mode *mode)
> > > +{
> > So, mode_valid is only called to filter out the modes retrieved by
> > get_modes, but it won't be called when userspace programs a mode. That's
> > atomic_check's job.
> > 
> > So you probably want to create a shared function between atomic_check
> > and mode_valid, and call it from both places (or call mode_valid from
> > atomic_check).
>
> This actually _is_ a shared function called in
> inno_hdmi_connector_mode_valid and inno_hdmi_encoder_mode_fixup. Yes, I?
> probably should use it in atomic_check _also_.

Yeah, I saw that later and forgot to rephrase.

> > > +	/* No support for double-clock modes */
> > > +	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > > +		return MODE_BAD;
> > > +
> > > +	unsigned int mpixelclk = mode->clock * 1000;
> > Variables should be declared at the top of the function.
> Oookay ... can move them.
> > > +	if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
> > > +		return MODE_CLOCK_LOW;
> > You probably want to check the max TMDS clock too?
>
> Not sure what you mean here. For the currently supported formats of this
> driver (rgb only) tmds clock and pixel clock are always the same.

I mean that your controller has a maximum TMDS rate it supports too
(probably something like 340MHz). You should also filter out the modes
that have a pixel clock higher than the one you can reach.

> > > @@ -602,7 +632,9 @@ static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
> > >   					 const struct drm_display_mode *mode,
> > >   					 struct drm_display_mode *adj_mode)
> > >   {
> > > -	return true;
> > > +	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
> > > +
> > > +	return inno_hdmi_mode_valid(hdmi, adj_mode) == MODE_OK;
> > >   }
> > Why do you call mode_valid in mode_fixup?
> 
> I'm calling the shared function you asked me to introduce
> (inno_hdmi_connector_mode_valid != inno_mode_valid)

That's the mode_fixup part that I'm focused on :)

mode_fixup is the legacy function to adjust the mode to the controller
capabilities. It's optional, and you're not adjusting anything here,
just testing the same thing mode_valid did.

mode_valid has been superseeded by atomic_check anyway, so just drop
mode_valid and use your function in atomic_check like we discussed.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/9c72c6c5/attachment.sig>

From adrian.hunter at intel.com  Thu Dec 14 03:51:02 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Thu, 14 Dec 2023 13:51:02 +0200
Subject: [V3, 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231209165816.39044-2-kamal.dasu@broadcom.com>
References: <20231209165816.39044-1-kamal.dasu@broadcom.com>
 <20231209165816.39044-2-kamal.dasu@broadcom.com>
Message-ID: <e9ef79c4-c769-49d3-813b-0d78d1e4ede1@intel.com>

On 9/12/23 18:58, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> 74165b0 shall use a new sdio controller core version which
> requires a different reset sequence. For core reset we use
> sdhci_reset. For CMD and/or DATA reset added a new function
> to also enable SDCHI clocks SDHCI_CLOCK_CARD_EN

SDCHI -> SDHCI

> SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
> SDHCI_RESET_DATA fields.
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312091608.0VbkRxlh-lkp at intel.com/
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202312091905.UGzltx8A-lkp at intel.com/``````````````

???

> ---
>  drivers/mmc/host/sdhci-brcmstb.c | 69 +++++++++++++++++++++++++++++---
>  1 file changed, 64 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
> index c23251bb95f3..d4bd5b3c0fa4 100644
> --- a/drivers/mmc/host/sdhci-brcmstb.c
> +++ b/drivers/mmc/host/sdhci-brcmstb.c
> @@ -44,8 +44,13 @@ struct brcmstb_match_priv {
>  
>  static inline void enable_clock_gating(struct sdhci_host *host)
>  {
> +	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> +	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
>  	u32 reg;
>  
> +	if (!(priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK))
> +		return;
> +
>  	reg = sdhci_readl(host, SDHCI_VENDOR);
>  	reg |= SDHCI_VENDOR_GATE_SDCLK_EN;
>  	sdhci_writel(host, reg, SDHCI_VENDOR);
> @@ -53,14 +58,54 @@ static inline void enable_clock_gating(struct sdhci_host *host)
>  
>  static void brcmstb_reset(struct sdhci_host *host, u8 mask)
>  {
> -	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> -	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
> -
>  	sdhci_and_cqhci_reset(host, mask);
>  
>  	/* Reset will clear this, so re-enable it */
> -	if (priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK)
> -		enable_clock_gating(host);
> +	enable_clock_gating(host);
> +}
> +
> +static void brcmstb_sdhci_reset_cmd_data(struct sdhci_host *host, u8 mask)
> +{
> +	ktime_t timeout;
> +	u32 reg;
> +	u32 new_mask = (mask &  (SDHCI_RESET_CMD | SDHCI_RESET_DATA)) << 24;
> +
> +	new_mask |= SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN;
> +	reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);

Is it really necessary to write both registers together?  If
so, maybe add a comment.

> +	sdhci_writel(host, reg | new_mask, SDHCI_CLOCK_CONTROL);
> +
> +	/* Wait max 10 ms */
> +	timeout = ktime_add_ms(ktime_get(), 10);
> +
> +	/* hw clears the bit when it's done */
> +	while (1) {
> +		bool timedout = ktime_after(ktime_get(), timeout);
> +
> +		if (!(sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask))
> +			break;
> +		if (timedout) {
> +			pr_err("%s: Reset 0x%x never completed.\n",
> +				mmc_hostname(host->mmc), (int)mask);
> +			sdhci_err_stats_inc(host, CTRL_TIMEOUT);
> +			sdhci_dumpregs(host);
> +			return;
> +		}
> +		udelay(10);
> +	}

For new code we should try to use read_poll_timeout_atomic() or other.

> +}
> +
> +static void brcmstb_reset_74165b0(struct sdhci_host *host, u8 mask)
> +{
> +	/* take care of RESET_ALL as usual */
> +	if (mask & SDHCI_RESET_ALL)
> +		sdhci_and_cqhci_reset(host, SDHCI_RESET_ALL);
> +
> +	/* cmd and/or data treated differently on this core */
> +	if (mask & (SDHCI_RESET_CMD | SDHCI_RESET_DATA))
> +		brcmstb_sdhci_reset_cmd_data(host, mask);
> +
> +	/* Reset will clear this, so re-enable it */
> +	enable_clock_gating(host);
>  }
>  
>  static void sdhci_brcmstb_hs400es(struct mmc_host *mmc, struct mmc_ios *ios)
> @@ -162,6 +207,13 @@ static struct sdhci_ops sdhci_brcmstb_ops_7216 = {
>  	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
>  };
>  
> +static struct sdhci_ops sdhci_brcmstb_ops_74165b0 = {
> +	.set_clock = sdhci_brcmstb_set_clock,
> +	.set_bus_width = sdhci_set_bus_width,
> +	.reset = brcmstb_reset_74165b0,
> +	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
> +};
> +
>  static struct brcmstb_match_priv match_priv_7425 = {
>  	.flags = BRCMSTB_MATCH_FLAGS_NO_64BIT |
>  	BRCMSTB_MATCH_FLAGS_BROKEN_TIMEOUT,
> @@ -179,10 +231,17 @@ static const struct brcmstb_match_priv match_priv_7216 = {
>  	.ops = &sdhci_brcmstb_ops_7216,
>  };
>  
> +static struct brcmstb_match_priv match_priv_74165b0 = {
> +	.flags = BRCMSTB_MATCH_FLAGS_HAS_CLOCK_GATE,
> +	.hs400es = sdhci_brcmstb_hs400es,
> +	.ops = &sdhci_brcmstb_ops_74165b0,
> +};
> +
>  static const struct of_device_id __maybe_unused sdhci_brcm_of_match[] = {
>  	{ .compatible = "brcm,bcm7425-sdhci", .data = &match_priv_7425 },
>  	{ .compatible = "brcm,bcm7445-sdhci", .data = &match_priv_7445 },
>  	{ .compatible = "brcm,bcm7216-sdhci", .data = &match_priv_7216 },
> +	{ .compatible = "brcm,bcm74165b0-sdhci", .data = &match_priv_74165b0 },
>  	{},
>  };
>  



From andyshrk at 163.com  Thu Dec 14 03:50:41 2023
From: andyshrk at 163.com (Andy Yan)
Date: Thu, 14 Dec 2023 19:50:41 +0800 (CST)
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <qr7if2k76wdqgevdcwqxj2dkcbga72owjqlk3qaazujhejjloo@cnvmuq27qqns>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
 <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com> <3053311.k3LOHGUjKi@diego>
 <qr7if2k76wdqgevdcwqxj2dkcbga72owjqlk3qaazujhejjloo@cnvmuq27qqns>
Message-ID: <aba9149.493d.18c682a22bc.Coremail.andyshrk@163.com>


Hi?

? 2023-12-14 19:36:05?"Maxime Ripard" <mripard at kernel.org> ???
>On Thu, Dec 14, 2023 at 12:17:34PM +0100, Heiko St?bner wrote:
>> Am Donnerstag, 14. Dezember 2023, 12:12:08 CET schrieb Alex Bee:
>> > Hi Maxime
>> > 
>> > Am 14.12.23 um 08:56 schrieb Maxime Ripard:
>> > > Hi Alex,
>> > >
>> > > Thanks for working on this!
>> > >
>> > > On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
>> > >> The display controller will always give full range RGB regardless of the
>> > >> mode set, but HDMI requires certain modes to be transmitted in limited
>> > >> range RGB. This is especially required for HDMI sinks which do not support
>> > >> non-standard quantization ranges.
>> > >>
>> > >> This enables color space conversion for those modes and sets the
>> > >> quantization range accordingly in the AVI infoframe.
>> > >>
>> > >> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
>> > >> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>> > >> ---
>> > >>   drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
>> > >>   1 file changed, 32 insertions(+), 8 deletions(-)
>> > >>
>> > >> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> > >> index 345253e033c5..32626a75723c 100644
>> > >> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>> > >> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> > >> @@ -33,6 +33,7 @@ struct hdmi_data_info {
>> > >>   	unsigned int enc_in_format;
>> > >>   	unsigned int enc_out_format;
>> > >>   	unsigned int colorimetry;
>> > >> +	bool rgb_limited_range;
>> > >>   };
>> > >>   
>> > >>   struct inno_hdmi_i2c {
>> > >> @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
>> > >>   	else
>> > >>   		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>> > >>   
>> > >> +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
>> > >> +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
>> > >> +						   &hdmi->connector, mode,
>> > >> +						   hdmi->hdmi_data.rgb_limited_range ?
>> > >> +						   HDMI_QUANTIZATION_RANGE_LIMITED :
>> > >> +						   HDMI_QUANTIZATION_RANGE_FULL);
>> > >> +	} else {
>> > >> +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
>> > >> +		frame.avi.ycc_quantization_range =
>> > >> +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
>> > >> +	}
>> > >> +
>> > >>   	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
>> > >>   }
>> > >>   
>> > >> @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
>> > >>   	if (data->enc_in_format == data->enc_out_format) {
>> > >>   		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
>> > >>   		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
>> > >> -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>> > >> -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>> > >> -
>> > >> -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>> > >> -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>> > >> -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>> > >> -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>> > >> -			return 0;
>> > >> +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
>> > >> +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
>> > >> +			    hdmi->hdmi_data.rgb_limited_range) {
>> > >> +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
>> > >> +				auto_csc = AUTO_CSC_DISABLE;
>> > >> +				c0_c2_change = C0_C2_CHANGE_DISABLE;
>> > >> +				csc_enable = v_CSC_ENABLE;
>> > >> +			} else {
>> > >> +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>> > >> +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>> > >> +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>> > >> +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>> > >> +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>> > >> +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>> > >> +				return 0;
>> > >> +			}
>> > >>   		}
>> > >>   	}
>> > >>   
>> > >> @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>> > >>   	else
>> > >>   		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
>> > >>   
>> > >> +	hdmi->hdmi_data.rgb_limited_range =
>> > >> +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
>> > >> +
>> > > This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
>> > > https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/
>> > I'm aware of that and I mentioned it in the cover letter. Your series is 
>> > not merged yet and it didn't get much feedback so far. What is the 
>> > status there? Especially because you are removing things from inno-hdmi 
>> > driver (which aren't really required to remove there) which will I have 
>> > to reintroduce.
>> 
>> Sadly I haven't found the time to look closer at Maxime's series so far,
>> but I got the impression that it separates into multiple cleanup steps
>> for a number of controllers.
>
>Yeah, one of the previous version comment was to support more
>controllers than vc4, which is fair. So I ended up reworking and
>converting multiple controllers, but most of the clean up changes can be
>applied outside of that series just fine.
>
>I just didn't find someone to test / review them yet :)

I will try to bring up my rk3036 kylin board whith mainline kernel this weekend? then I can do some tests.

>
>Maxime

From konrad.dybcio at linaro.org  Thu Dec 14 03:53:30 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Thu, 14 Dec 2023 12:53:30 +0100
Subject: [PATCH v1 2/6] arm: arm64: dts: Enable cros-ec-spi as wake source
In-Reply-To: <e5625051-e9e2-4a75-a11a-cf5b40606fa4@collabora.com>
References: <20231213110009.v1.1.Ifd0903f1c351e84376d71dbdadbd43931197f5ea@changeid>
 <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid>
 <e5625051-e9e2-4a75-a11a-cf5b40606fa4@collabora.com>
Message-ID: <2890ae71-aed0-451d-a7fb-7db30c30b72b@linaro.org>



On 12/14/23 11:55, AngeloGioacchino Del Regno wrote:
> Il 13/12/23 19:00, Mark Hasemeyer ha scritto:
>> The cros_ec driver currently assumes that cros-ec-spi compatible device
>> nodes are a wakeup-source even though the wakeup-source property is not
>> defined.
>>
>> Add the wakeup-source property to all cros-ec-spi compatible device
>> nodes to match expected behavior.
>>
>> Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
> 
> I received only patch [2/6] - please send the entire series to the relevant
> maintainers, as otherwise it's difficult to understand what's going on.
> 
> As for this patch alone:
>  ?1. arch/arm stuff goes to a different commit
>  ?2. I would prefer if you split per-arch and per-SoC.
+1, otherwise *somebody* will get merge conflicts that - even
if trivial - take additional time to resolve :(

Konrad


From ryan.roberts at arm.com  Thu Dec 14 03:53:52 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 14 Dec 2023 11:53:52 +0000
Subject: [PATCH v3 12/15] arm64/mm: Split __flush_tlb_range() to elide
 trailing DSB
In-Reply-To: <0969c413-bf40-4c46-9f1e-a92101ff2d2e@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-13-ryan.roberts@arm.com>
 <20231212113517.GA28857@willie-the-truck>
 <0969c413-bf40-4c46-9f1e-a92101ff2d2e@arm.com>
Message-ID: <2e6f06d3-6c8e-4b44-b6f2-e55bd5be83d6@arm.com>

Hi Will,

On 12/12/2023 11:47, Ryan Roberts wrote:
> On 12/12/2023 11:35, Will Deacon wrote:
>> On Mon, Dec 04, 2023 at 10:54:37AM +0000, Ryan Roberts wrote:
>>> Split __flush_tlb_range() into __flush_tlb_range_nosync() +
>>> __flush_tlb_range(), in the same way as the existing flush_tlb_page()
>>> arrangement. This allows calling __flush_tlb_range_nosync() to elide the
>>> trailing DSB. Forthcoming "contpte" code will take advantage of this
>>> when clearing the young bit from a contiguous range of ptes.
>>>
>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>> ---
>>>  arch/arm64/include/asm/tlbflush.h | 13 +++++++++++--
>>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
>>> index bb2c2833a987..925ef3bdf9ed 100644
>>> --- a/arch/arm64/include/asm/tlbflush.h
>>> +++ b/arch/arm64/include/asm/tlbflush.h
>>> @@ -399,7 +399,7 @@ do {									\
>>>  #define __flush_s2_tlb_range_op(op, start, pages, stride, tlb_level) \
>>>  	__flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false)
>>>  
>>> -static inline void __flush_tlb_range(struct vm_area_struct *vma,
>>> +static inline void __flush_tlb_range_nosync(struct vm_area_struct *vma,
>>>  				     unsigned long start, unsigned long end,
>>>  				     unsigned long stride, bool last_level,
>>>  				     int tlb_level)
>>> @@ -431,10 +431,19 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
>>>  	else
>>>  		__flush_tlb_range_op(vae1is, start, pages, stride, asid, tlb_level, true);
>>>  
>>> -	dsb(ish);
>>>  	mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, start, end);
>>>  }
>>>  
>>> +static inline void __flush_tlb_range(struct vm_area_struct *vma,
>>> +				     unsigned long start, unsigned long end,
>>> +				     unsigned long stride, bool last_level,
>>> +				     int tlb_level)
>>> +{
>>> +	__flush_tlb_range_nosync(vma, start, end, stride,
>>> +				 last_level, tlb_level);
>>> +	dsb(ish);
>>> +}
>>
>> Hmm, are you sure it's safe to defer the DSB until after the secondary TLB
>> invalidation? It will have a subtle effect on e.g. an SMMU participating
>> in broadcast TLB maintenance, because now the ATC will be invalidated
>> before completion of the TLB invalidation and it's not obviously safe to me.
> 
> I'll be honest; I don't know that it's safe. The notifier calls turned up during
> a rebase and I stared at it for a while, before eventually concluding that I
> should just follow the existing pattern in __flush_tlb_page_nosync(): That one
> calls the mmu notifier without the dsb, then flush_tlb_page() does the dsb
> after. So I assumed it was safe.
> 
> If you think it's not safe, I guess there is a bug to fix in
> __flush_tlb_page_nosync()?

Did you have an opinion on this? I'm just putting together a v4 of this series,
and I'll remove this optimization if you think it's unsound. But in that case, I
guess we have an existing bug to fix too?

Thanks,
Ryan


> 
> 
> 
>>
>> Will
> 



From festevam at gmail.com  Thu Dec 14 03:58:12 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 14 Dec 2023 08:58:12 -0300
Subject: [PATCH 2/4] arm64: dts: imx8ulp-evk: enable usb nodes
In-Reply-To: <20231214112442.2412079-2-xu.yang_2@nxp.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com> <20231214112442.2412079-2-xu.yang_2@nxp.com>
Message-ID: <CAOMZO5DxcLoBYMXQi=EW=-fAqz12ghPm+7PHn=LdhicETKg2pQ@mail.gmail.com>

On Thu, Dec 14, 2023 at 8:19?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
>
> Enable 2 USB nodes on i.MX8ULP evk board.

imx8ulp-evk schematics show two PTN5150 and two USB Type-C connectors.

Why are they not represented in the devicetree?


From gregkh at linuxfoundation.org  Thu Dec 14 04:01:08 2023
From: gregkh at linuxfoundation.org (Greg KH)
Date: Thu, 14 Dec 2023 13:01:08 +0100
Subject: [PATCH 1/3] usb: chipidea: ci_hdrc_imx: add wakeup clock and
 keep it always on
In-Reply-To: <20231214112622.2412321-1-xu.yang_2@nxp.com>
References: <20231214112622.2412321-1-xu.yang_2@nxp.com>
Message-ID: <2023121447-consent-decent-7c69@gregkh>

On Thu, Dec 14, 2023 at 07:26:20PM +0800, Xu Yang wrote:
> Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
> on without usb driver intervention. And some may need driver to handle
> this clock. This patch will get wakeup clock and keep it always on to
> make controller work correctlly.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 

Why do I have 2 different copies of this series?  Please fix up and send
a v2 and describe what changed...

thanks,

greg k-h


From arnd at arndb.de  Thu Dec 14 04:01:21 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 14 Dec 2023 13:01:21 +0100
Subject: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
In-Reply-To: <20231214105243.3707730-6-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-6-tudor.ambarus@linaro.org>
Message-ID: <1938fcf1-eb5d-4723-a6c6-d2fe2c6dd1c0@app.fastmail.com>

On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
> +static int __init gs101_early_console_setup(struct earlycon_device *device,
> +					    const char *opt)
> +{
> +	/* gs101 always expects MMIO32 register accesses. */
> +	device->port.iotype = UPIO_MEM32;
> +
> +	return s5pv210_early_console_setup(device, opt);
> +}
> +
> +OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);

It looks like this is already done by of_setup_earlycon() based on
the reg-io-width property. Any idea why it doesn't work with the
normal s5pv210_early_console_setup() function?

      Arnd


From arnd at arndb.de  Thu Dec 14 04:08:08 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 14 Dec 2023 13:08:08 +0100
Subject: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
In-Reply-To: <20231214105243.3707730-13-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-13-tudor.ambarus@linaro.org>
Message-ID: <1153987b-a818-454a-a292-57f2b3898771@app.fastmail.com>

On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
> Sync the defconfig with savedefconfig as config options
> change/move over time.
>
> Generated with the following commands:
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
> cp defconfig arch/arm64/configs/defconfig
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
>  1 file changed, 55 insertions(+), 89 deletions(-)

I usually ask for defconfig changes to be merged when someone just
adds a single line per patch, but a 144 line change is clearly too
big, please split this up.

> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index b60aa1f89343..09fb467303ba 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -30,6 +30,8 @@ CONFIG_SCHED_AUTOGROUP=y
>  CONFIG_BLK_DEV_INITRD=y
>  CONFIG_KALLSYMS_ALL=y
>  CONFIG_PROFILING=y
> +CONFIG_KEXEC_FILE=y
> +CONFIG_CRASH_DUMP=y
>  CONFIG_ARCH_ACTIONS=y
>  CONFIG_ARCH_SUNXI=y
>  CONFIG_ARCH_ALPINE=y
> @@ -77,9 +79,6 @@ CONFIG_ARM64_VA_BITS_48=y
>  CONFIG_SCHED_MC=y
>  CONFIG_SCHED_SMT=y
>  CONFIG_NUMA=y
> -CONFIG_KEXEC=y
> -CONFIG_KEXEC_FILE=y
> -CONFIG_CRASH_DUMP=y
>  CONFIG_XEN=y
>  CONFIG_COMPAT=y
>  CONFIG_RANDOMIZE_BASE=y

These two hunks seem to go together, but it needs an explanation
why you are removing CONFIG_KEXEC.

> @@ -119,7 +118,6 @@ CONFIG_KVM=y
>  CONFIG_JUMP_LABEL=y
>  CONFIG_MODULES=y
>  CONFIG_MODULE_UNLOAD=y
> -CONFIG_IOSCHED_BFQ=y
>  # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>  # CONFIG_COMPAT_BRK is not set
>  CONFIG_MEMORY_HOTPLUG=y

No, I definitely want CONFIG_IOSCHED_BFQ=y, it is essential
for performance on certain classes of machines. It would
be better to drop the 'imply IOSCHED_BFQ' in two Kconfig
files.

> @@ -129,8 +127,6 @@ CONFIG_MEMORY_FAILURE=y
>  CONFIG_TRANSPARENT_HUGEPAGE=y
>  CONFIG_NET=y
>  CONFIG_PACKET=y
> -CONFIG_UNIX=y
> -CONFIG_INET=y
>  CONFIG_IP_MULTICAST=y
>  CONFIG_IP_PNP=y
>  CONFIG_IP_PNP_DHCP=y

These also seem kind of essential for almost any machine,
I assume you are doing something wrong here.

> @@ -180,8 +176,6 @@ CONFIG_NET_ACT_GATE=m
>  CONFIG_QRTR_SMD=m
>  CONFIG_QRTR_TUN=m
>  CONFIG_CAN=m
> -CONFIG_CAN_M_CAN=m
> -CONFIG_CAN_M_CAN_PLATFORM=m
>  CONFIG_BT=m
>  CONFIG_BT_HIDP=m
>  # CONFIG_BT_LE is not set
> @@ -384,6 +372,8 @@ CONFIG_DP83869_PHY=m
>  CONFIG_DP83TD510_PHY=y
>  CONFIG_VITESSE_PHY=y
>  CONFIG_CAN_FLEXCAN=m
> +CONFIG_CAN_M_CAN=m
> +CONFIG_CAN_M_CAN_PLATFORM=m
>  CONFIG_CAN_RCAR=m
>  CONFIG_CAN_RCAR_CANFD=m
>  CONFIG_CAN_MCP251XFD=m

These just get moved around in the file, please don't
mix those changes with other changes that change the behavior.

> @@ -215,27 +209,27 @@ CONFIG_PCI_PASID=y
>  CONFIG_HOTPLUG_PCI=y
>  CONFIG_HOTPLUG_PCI_ACPI=y
>  CONFIG_PCI_AARDVARK=y
> -CONFIG_PCI_TEGRA=y
> -CONFIG_PCIE_RCAR_HOST=y
> -CONFIG_PCIE_RCAR_EP=y
> -CONFIG_PCI_HOST_GENERIC=y
> -CONFIG_PCI_XGENE=y
>  CONFIG_PCIE_ALTERA=y
>  CONFIG_PCIE_ALTERA_MSI=y
> +CONFIG_PCIE_BRCMSTB=m
>  CONFIG_PCI_HOST_THUNDER_PEM=y
>  CONFIG_PCI_HOST_THUNDER_ECAM=y
> -CONFIG_PCIE_ROCKCHIP_HOST=m
> +CONFIG_PCI_HOST_GENERIC=y
>  CONFIG_PCIE_MEDIATEK_GEN3=m
> -CONFIG_PCIE_BRCMSTB=m
> +CONFIG_PCI_TEGRA=y
> +CONFIG_PCIE_RCAR_HOST=y
> +CONFIG_PCIE_RCAR_EP=y
> +CONFIG_PCIE_ROCKCHIP_HOST=m
> +CONFIG_PCI_XGENE=y
>  CONFIG_PCI_IMX6_HOST=y
>  CONFIG_PCI_LAYERSCAPE=y
>  CONFIG_PCI_HISI=y
> -CONFIG_PCIE_QCOM=y
> -CONFIG_PCIE_ARMADA_8K=y
> -CONFIG_PCIE_ROCKCHIP_DW_HOST=y
>  CONFIG_PCIE_KIRIN=y
>  CONFIG_PCIE_HISI_STB=y
> +CONFIG_PCIE_ARMADA_8K=y
>  CONFIG_PCIE_TEGRA194_HOST=m
> +CONFIG_PCIE_QCOM=y
> +CONFIG_PCIE_ROCKCHIP_DW_HOST=y
>  CONFIG_PCIE_VISCONTI_HOST=y
>  CONFIG_PCIE_LAYERSCAPE_GEN4=y
>  CONFIG_PCI_ENDPOINT=y

Same here

> @@ -247,14 +241,12 @@ CONFIG_FW_LOADER_USER_HELPER=y
>  CONFIG_HISILICON_LPC=y
>  CONFIG_TEGRA_ACONNECT=m
>  CONFIG_MHI_BUS_PCI_GENERIC=m
> -CONFIG_ARM_SCMI_PROTOCOL=y
>  CONFIG_ARM_SCPI_PROTOCOL=y
>  CONFIG_RASPBERRYPI_FIRMWARE=y
>  CONFIG_INTEL_STRATIX10_SERVICE=y
> @@ -1185,7 +1168,6 @@ CONFIG_CROS_EC_RPMSG=m
>  CONFIG_CROS_EC_SPI=y
>  CONFIG_CROS_EC_CHARDEV=m
>  CONFIG_COMMON_CLK_RK808=y
> -CONFIG_COMMON_CLK_SCMI=y
>  CONFIG_COMMON_CLK_SCPI=y
>  CONFIG_COMMON_CLK_CS2000_CP=y
>  CONFIG_COMMON_CLK_FSL_SAI=y

This was caused by commit 9e4e24414cc6 ("arm64:
introduce STM32 family on Armv8 architecture"),
which selects ARM_SCMI_PROTOCOL and COMMON_CLK_SCMI.
I think we should instead revert those and enable
them in the defconfig for consistency with the other
platforms that need the same driver.

>  CONFIG_INTEL_STRATIX10_RSU=m
>  CONFIG_EFI_CAPSULE_LOADER=y
>  CONFIG_IMX_SCU=y
> -CONFIG_IMX_SCU_PD=y
>  CONFIG_GNSS=m
>  CONFIG_GNSS_MTK_SERIAL=m
>  CONFIG_MTD=y
> @@ -276,15 +268,12 @@ CONFIG_MTD_NAND_FSL_IFC=y
>  CONFIG_MTD_NAND_QCOM=y
>  CONFIG_MTD_SPI_NOR=y
>  CONFIG_MTD_UBI=m
> -CONFIG_UBIFS_FS=m
>  CONFIG_BLK_DEV_LOOP=y
>  CONFIG_BLK_DEV_NBD=m
>  CONFIG_VIRTIO_BLK=y
>  CONFIG_BLK_DEV_NVME=m
>  CONFIG_QCOM_COINCELL=m
>  CONFIG_QCOM_FASTRPC=m
> -CONFIG_BATTERY_QCOM_BATTMGR=m
> -CONFIG_UCSI_PMIC_GLINK=m
>  CONFIG_SRAM=y
>  CONFIG_PCI_ENDPOINT_TEST=m
>  CONFIG_EEPROM_AT24=m

Again, just moved around.

> @@ -308,7 +297,6 @@ CONFIG_AHCI_XGENE=y
>  CONFIG_AHCI_QORIQ=y
>  CONFIG_SATA_SIL24=y
>  CONFIG_SATA_RCAR=y
> -CONFIG_PATA_PLATFORM=y
>  CONFIG_PATA_OF_PLATFORM=y
>  CONFIG_MD=y
>  CONFIG_BLK_DEV_MD=m

For the ones that got removed for a good and trivial reason,
you can probably combine the patches and just list what
happened.

> @@ -635,7 +625,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
>  CONFIG_GPIO_BD9571MWV=m
>  CONFIG_GPIO_MAX77620=y
>  CONFIG_GPIO_SL28CPLD=m
> -CONFIG_GPIO_SYSCON=y

Apparently caused by GPIO_SAMA5D2_PIOBU, please change that
to 'depends on'.

> @@ -856,7 +843,6 @@ CONFIG_DRM_LONTIUM_LT9611UXC=m
>  CONFIG_DRM_ITE_IT66121=m
>  CONFIG_DRM_NWL_MIPI_DSI=m
>  CONFIG_DRM_PARADE_PS8640=m
> -CONFIG_DRM_SAMSUNG_DSIM=m
>  CONFIG_DRM_SII902X=m
>  CONFIG_DRM_SIMPLE_BRIDGE=m
>  CONFIG_DRM_THINE_THC63LVD1024=m

DRM_EXYNOS_DSI should probably depend on this rather than
selecting it.

> @@ -1203,18 +1185,6 @@ CONFIG_CLK_IMX8QXP=y
>  CONFIG_CLK_IMX8ULP=y
>  CONFIG_CLK_IMX93=y
>  CONFIG_TI_SCI_CLK=y
> -CONFIG_COMMON_CLK_MT8192_AUDSYS=y
> -CONFIG_COMMON_CLK_MT8192_CAMSYS=y
> -CONFIG_COMMON_CLK_MT8192_IMGSYS=y
> -CONFIG_COMMON_CLK_MT8192_IMP_IIC_WRAP=y
> -CONFIG_COMMON_CLK_MT8192_IPESYS=y
> -CONFIG_COMMON_CLK_MT8192_MDPSYS=y
> -CONFIG_COMMON_CLK_MT8192_MFGCFG=y
> -CONFIG_COMMON_CLK_MT8192_MMSYS=y
> -CONFIG_COMMON_CLK_MT8192_MSDC=y
> -CONFIG_COMMON_CLK_MT8192_SCP_ADSP=y
> -CONFIG_COMMON_CLK_MT8192_VDECSYS=y
> -CONFIG_COMMON_CLK_MT8192_VENCSYS=y
>  CONFIG_COMMON_CLK_QCOM=y
>  CONFIG_QCOM_A53PLL=y
>  CONFIG_QCOM_CLK_APCS_MSM8916=y

These looks legitimate

> @@ -1275,7 +1244,6 @@ CONFIG_TEGRA186_TIMER=y
>  CONFIG_RENESAS_OSTM=y
>  CONFIG_ARM_MHU=y
>  CONFIG_IMX_MBOX=y
> -CONFIG_OMAP2PLUS_MBOX=m
>  CONFIG_PLATFORM_MHU=y
>  CONFIG_BCM2835_MBOX=y
>  CONFIG_QCOM_APCS_IPC=y

Again we have a mix of select and depends:

drivers/remoteproc/Kconfig:     select OMAP2PLUS_MBOX
drivers/remoteproc/Kconfig:     select OMAP2PLUS_MBOX
drivers/remoteproc/Kconfig:     select OMAP2PLUS_MBOX
drivers/soc/ti/Kconfig: depends on OMAP2PLUS_MBOX

We probably want the latter for all of them.

> @@ -1462,7 +1431,6 @@ CONFIG_PHY_J721E_WIZ=m
>  CONFIG_ARM_CCI_PMU=m
>  CONFIG_ARM_CCN=m
>  CONFIG_ARM_CMN=m
> -CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
>  CONFIG_ARM_SMMU_V3_PMU=m
>  CONFIG_ARM_DSU_PMU=m
>  CONFIG_FSL_IMX8_DDR_PMU=m
> @@ -1471,6 +1439,7 @@ CONFIG_QCOM_L3_PMU=y
>  CONFIG_ARM_SPE_PMU=m
>  CONFIG_ARM_DMC620_PMU=m
>  CONFIG_HISI_PMU=y
> +CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
>  CONFIG_MESON_DDR_PMU=m
>  CONFIG_NVMEM_LAYOUT_SL28_VPD=m
>  CONFIG_NVMEM_IMX_OCOTP=y

Just moved

> @@ -1498,10 +1467,8 @@ CONFIG_TEE=y
>  CONFIG_OPTEE=y
>  CONFIG_MUX_GPIO=m
>  CONFIG_MUX_MMIO=y
> -CONFIG_SLIMBUS=m
>  CONFIG_SLIM_QCOM_CTRL=m

Please fix SOUNDWIRE_QCOM to no longer 'imply SLIMBUS'.

>  CONFIG_SLIM_QCOM_NGD_CTRL=m
> -CONFIG_INTERCONNECT=y
>  CONFIG_INTERCONNECT_IMX=y
>  CONFIG_INTERCONNECT_IMX8MM=m
>  CONFIG_INTERCONNECT_IMX8MN=m

I think the problem here are some Tegra device drivers that
incorrectly 'select INTERCONNECT' rather than using the
'depends on' that every other interconnect driver has.
Please fix those instead.

> @@ -1544,8 +1511,8 @@ CONFIG_OVERLAY_FS=m
>  CONFIG_VFAT_FS=y
>  CONFIG_TMPFS_POSIX_ACL=y
>  CONFIG_HUGETLBFS=y
> -CONFIG_CONFIGFS_FS=y
>  CONFIG_EFIVAR_FS=y

For CONFIG_CONFIGFS_FS, we have a mix of 'depends on' and 'select'
in the Kconfig options that use it. Before you remove this here,
let's discuss with all the users which of the two should actually
be used and then change them to be consistent.

> @@ -1593,7 +1560,6 @@ CONFIG_DEBUG_INFO_REDUCED=y
>  CONFIG_MAGIC_SYSRQ=y
>  CONFIG_DEBUG_FS=y
>  # CONFIG_SCHED_DEBUG is not set
> -# CONFIG_DEBUG_PREEMPT is not set
>  # CONFIG_FTRACE is not set
>  CONFIG_CORESIGHT=m
>  CONFIG_CORESIGHT_LINK_AND_SINK_TMC=m

These looks sensible. Can you do the same thing for
arch/arm/configs/* in a combined patch?

      Arnd


From ryan.roberts at arm.com  Thu Dec 14 04:12:05 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 14 Dec 2023 12:12:05 +0000
Subject: [PATCH v9 04/10] mm: thp: Support allocation of anonymous
 multi-size THP
In-Reply-To: <e2da3c78-85f7-4516-bbab-97fac9629dcc@suswa.mountain>
References: <20231207161211.2374093-1-ryan.roberts@arm.com>
 <20231207161211.2374093-5-ryan.roberts@arm.com>
 <cb1fe352-ca47-4c3b-ab51-ecf51a83ce50@moroto.mountain>
 <43a8bfff-f939-4f2d-a8cd-97306d5e44c9@arm.com>
 <e2da3c78-85f7-4516-bbab-97fac9629dcc@suswa.mountain>
Message-ID: <8e2a5b4c-ba3a-4dcd-8aae-e5d3170d048a@arm.com>

On 14/12/2023 11:30, Dan Carpenter wrote:
> On Thu, Dec 14, 2023 at 10:54:19AM +0000, Ryan Roberts wrote:
>> On 13/12/2023 07:21, Dan Carpenter wrote:
>>> On Thu, Dec 07, 2023 at 04:12:05PM +0000, Ryan Roberts wrote:
>>>> @@ -4176,10 +4260,15 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
>>>>  	/* Allocate our own private page. */
>>>>  	if (unlikely(anon_vma_prepare(vma)))
>>>>  		goto oom;
>>>> -	folio = vma_alloc_zeroed_movable_folio(vma, vmf->address);
>>>> +	folio = alloc_anon_folio(vmf);
>>>> +	if (IS_ERR(folio))
>>>> +		return 0;
>>>>  	if (!folio)
>>>>  		goto oom;
>>>
>>> Returning zero is weird.  I think it should be a vm_fault_t code.
>>
>> It's the same pattern that the existing code a little further down this function
>> already implements:
>>
>> 	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
>> 	if (!vmf->pte)
>> 		goto release;
>>
>> If we fail to map/lock the pte (due to a race), then we return 0 to allow user
>> space to rerun the faulting instruction and cause the fault to happen again. The
>> above code ends up calling "return ret;" and ret is 0.
>>
> 
> Ah, okay.  Thanks!
> 
>>>
>>> This mixing of error pointers and NULL is going to cause problems.
>>> Normally when we have a mix of error pointers and NULL then the NULL is
>>> not an error but instead means that the feature has been deliberately
>>> turned off.  I'm unable to figure out what the meaning is here.
>>
>> There are 3 conditions that the function can return:
>>
>>  - folio successfully allocated
>>  - folio failed to be allocated due to OOM
>>  - fault needs to be tried again due to losing race
>>
>> Previously only the first 2 conditions were possible and they were indicated by
>> NULL/not-NULL. The new 3rd condition is only possible when THP is compile-time
>> enabled. So it keeps the logic simpler to keep the NULL/not-NULL distinction for
>> the first 2, and use the error code for the final one.
>>
>> There are IS_ERR() and IS_ERR_OR_NULL() variants so I assume a pattern where you
>> can have pointer, error or NULL is somewhat common already?
> 
> People are confused by this a lot so I have written a blog about it:
> 
> https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/

Nice; thanks for the pointer :)

> 
> The IS_ERR_OR_NULL() function should be used like this:
> 
> int blink_leds()
> {
> 	led = get_leds();
> 	if (IS_ERR_OR_NULL(led))
> 		return PTR_ERR(led);  <-- NULL means zero/success
> 	return led->blink();
> }
> 
> In the case of alloc_anon_folio(), I would be tempted to create a
> wrapper around it where NULL becomes ERR_PTR(-ENOMEM).  But this is
> obviously fast path code and I haven't benchmarked it.
> 
> Adding a comment is the other option.

I'll add a comment; as you say this is a fast path, and I'm actively being
burned in similar places (on another series I'm working on) where an additional
check is regressing performance significantly so not keen on risking it here.

Andrew, I'll fold in the David's suggested ifdef improvement at the same time.
Would you prefer an additional patch to squash in, or a whole new version of the
series to swap out with the existing patches in mm-unstable?

> 
> regards,
> dan carpenter
> 



From will at kernel.org  Thu Dec 14 04:13:36 2023
From: will at kernel.org (Will Deacon)
Date: Thu, 14 Dec 2023 12:13:36 +0000
Subject: [PATCH v3 12/15] arm64/mm: Split __flush_tlb_range() to elide
 trailing DSB
In-Reply-To: <2e6f06d3-6c8e-4b44-b6f2-e55bd5be83d6@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-13-ryan.roberts@arm.com>
 <20231212113517.GA28857@willie-the-truck>
 <0969c413-bf40-4c46-9f1e-a92101ff2d2e@arm.com>
 <2e6f06d3-6c8e-4b44-b6f2-e55bd5be83d6@arm.com>
Message-ID: <20231214121336.GA1015@willie-the-truck>

On Thu, Dec 14, 2023 at 11:53:52AM +0000, Ryan Roberts wrote:
> On 12/12/2023 11:47, Ryan Roberts wrote:
> > On 12/12/2023 11:35, Will Deacon wrote:
> >> On Mon, Dec 04, 2023 at 10:54:37AM +0000, Ryan Roberts wrote:
> >>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> >>> index bb2c2833a987..925ef3bdf9ed 100644
> >>> --- a/arch/arm64/include/asm/tlbflush.h
> >>> +++ b/arch/arm64/include/asm/tlbflush.h
> >>> @@ -399,7 +399,7 @@ do {									\
> >>>  #define __flush_s2_tlb_range_op(op, start, pages, stride, tlb_level) \
> >>>  	__flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false)
> >>>  
> >>> -static inline void __flush_tlb_range(struct vm_area_struct *vma,
> >>> +static inline void __flush_tlb_range_nosync(struct vm_area_struct *vma,
> >>>  				     unsigned long start, unsigned long end,
> >>>  				     unsigned long stride, bool last_level,
> >>>  				     int tlb_level)
> >>> @@ -431,10 +431,19 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
> >>>  	else
> >>>  		__flush_tlb_range_op(vae1is, start, pages, stride, asid, tlb_level, true);
> >>>  
> >>> -	dsb(ish);
> >>>  	mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, start, end);
> >>>  }
> >>>  
> >>> +static inline void __flush_tlb_range(struct vm_area_struct *vma,
> >>> +				     unsigned long start, unsigned long end,
> >>> +				     unsigned long stride, bool last_level,
> >>> +				     int tlb_level)
> >>> +{
> >>> +	__flush_tlb_range_nosync(vma, start, end, stride,
> >>> +				 last_level, tlb_level);
> >>> +	dsb(ish);
> >>> +}
> >>
> >> Hmm, are you sure it's safe to defer the DSB until after the secondary TLB
> >> invalidation? It will have a subtle effect on e.g. an SMMU participating
> >> in broadcast TLB maintenance, because now the ATC will be invalidated
> >> before completion of the TLB invalidation and it's not obviously safe to me.
> > 
> > I'll be honest; I don't know that it's safe. The notifier calls turned up during
> > a rebase and I stared at it for a while, before eventually concluding that I
> > should just follow the existing pattern in __flush_tlb_page_nosync(): That one
> > calls the mmu notifier without the dsb, then flush_tlb_page() does the dsb
> > after. So I assumed it was safe.
> > 
> > If you think it's not safe, I guess there is a bug to fix in
> > __flush_tlb_page_nosync()?
> 
> Did you have an opinion on this? I'm just putting together a v4 of this series,
> and I'll remove this optimization if you think it's unsound. But in that case, I
> guess we have an existing bug to fix too?

Sorry, Ryan, I've not had a chance to look into it in more detail. But as
you rightly point out, you're not introducing the issue (assuming it is
one), so I don't think it needs to hold you up. Your code just makes the
thing more "obvious" to me.

Robin, Jean-Philippe -- do we need to make sure that the SMMU has completed
its TLB invalidation before issuing an ATC invalidate? My half-baked worry
is whether or not an ATS request could refill the ATC before the TLBI
has completed, therefore rendering the ATC invalidation useless.

Will


From jiangkunkun at huawei.com  Thu Dec 14 04:13:57 2023
From: jiangkunkun at huawei.com (Kunkun Jiang)
Date: Thu, 14 Dec 2023 20:13:57 +0800
Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset
Message-ID: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>

Hi list,

We have observed on GICv4.1 systems that, after a guest reset, the
secondary VCPU would receive an IPI_CPU_STOP accidently and failed to
come online eventually.

| Guest User-space
|
| reset (with a vSGI pending in the
| hardware) [0]
|
| disable the distributor (write 0
| into GICD_CTLR) [1]
|
| clear pending status (write 0 into
| GICR_ISPENDR0 for each RD) [2]
|
| disable the distributor (write 0
| into GICD_CTLR) [3]
|
| enable the distributor with ARE,
| Group1 and nASSGIreq [4]

The problem is that even if user-space tries to disable the distributor
and clear pending bits for all SGIs, we don't actually propogate it into
HW (we only record it via vgic_dist->{enabled, nassgireq} and
vgic_irq->pending_latch) and the vSGI remains pending across the guest
reset.

And when we're at [4], all vSGI's vgic_irq->hw are *true* and
vgic_v4_enable_vsgis() becomes a nop.. That's not good.

The following solution can solve the problem. Not sure if this is a good
solution.Sent out early for suggestions or solutions.

diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c 
b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 89117ba2528a..3678ab33f5b9 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -374,6 +374,10 @@ static int vgic_v3_uaccess_write_pending(struct 
kvm_vcpu *vcpu,
 ???? ??? ??? irq->pending_latch = true;
 ???? ??? ??? vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
 ???? ??? } else {
+ ??? ??? ??? if (irq->hw && vgic_irq_is_sgi(irq->intid))
+ ??? ??? ??? ??? irq_set_irqchip_state(irq->host_irq,
+ ??? ??? ??? ??? ??? ??? ???? IRQCHIP_STATE_PENDING,
+ ??? ??? ??? ??? ??? ??? ???? false);
 ???? ??? ??? irq->pending_latch = false;
 ???? ??? ??? raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
 ???? ??? }



From nm at ti.com  Thu Dec 14 04:17:27 2023
From: nm at ti.com (Nishanth Menon)
Date: Thu, 14 Dec 2023 06:17:27 -0600
Subject: [PATCH v2] arm64: dts: ti: k3-am654-icssg2: Enable PHY
 interrupts for ICSSG2
In-Reply-To: <6f1c1a59-cec0-46d1-8ecb-a82d9d444ccf@ti.com>
References: <20231213080216.1710730-1-s-vadapalli@ti.com>
 <20231213123819.tqh3lm2ceir3qjbk@swimmer>
 <6f1c1a59-cec0-46d1-8ecb-a82d9d444ccf@ti.com>
Message-ID: <20231214121727.ayrbqz2nmeb25rpw@striving>

On 11:14-20231214, Siddharth Vadapalli wrote:
> Hello Nishanth,
> 
> On 13/12/23 18:08, Nishanth Menon wrote:
> > On 13:32-20231213, Siddharth Vadapalli wrote:
> >> Enable interrupt mode of operation of the DP83867 Ethernet PHY which is
> >> used by ICSSG2. The DP83867 PHY driver already supports interrupt handling
> >> for interrupts generated by the PHY. Thus, add the necessary device-tree
> >> support to enable it.
> >>
> >> Since the GPIO1_87 line is muxed with EXT_REFCLK1 and SYNC1_OUT, update
> >> the pinmux to select GPIO1_87 for routing the interrupt.
> >>
> >> As the same interrupt line and therefore the same pinmux configuration is
> >> applicable to both Ethernet PHYs used by ICSSG2, allocate the pinmux
> >> resource to the first Ethernet PHY alone.
> 
> ...
> 
> > 
> > https://www.ti.com/lit/ds/symlink/dp83867ir.pdf -> it looks like the
> > interrupt pin is level event. but drivers/gpio/gpio-davinci.c::
> > gpio_irq_type() -> The SoC cannot handle level, only edge.
> > 
> > A bit confused here..  GPIO 87 is shared between two phys. isn't it a
> > case of race?
> > 
> > PHY1 assets low
> > phy1 handler starts, but before the driver it clears the condition:
> > PHY2 asserts low - but since the signal is already low, there is no
> > pulse
> > phy1 handler clears phy1 condition, but signal is still low due to phy2?
> > now phy2 OR phy1 never gets handled since there is never a pulse event
> > ever again.
> 
> Yes, you are right! Edge-Triggered interrupts shouldn't be shared. I missed
> noticing this. Thank you for pointing it out. Since the SoC only supports
> Edge-Triggered interrupts, I believe that the correct decision would be to use
> the interrupt for only one of the two PHYs, while leaving the other PHY in
> polled mode of operation which is the default.
> 
> Kindly let me know if this is acceptable and I shall update this patch accordingly.

Sounds like a bug in board design there (due to an choice of IP
limitation) - I suggest getting it noted in board documentation and
refer to the errata in the second phy (else folks will wonder why we
aren't using interrupts on the second phy.

> 
> > 
> > 
> >>  		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> >>  		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> >>  	};
> >> -- 
> >> 2.34.1
> >>
> > 
> 
> -- 
> Regards,
> Siddharth.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From nm at ti.com  Thu Dec 14 04:27:13 2023
From: nm at ti.com (Nishanth Menon)
Date: Thu, 14 Dec 2023 06:27:13 -0600
Subject: [PATCH 2/3] arm64: dts: ti: Introduce J722S family of SoCs
In-Reply-To: <08eccba2-41df-91e7-c1e5-e03190402c23@ti.com>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
 <20231213124930.3012-3-vaishnav.a@ti.com>
 <20231213202705.6tspycl5qicb6gwd@germproof>
 <08eccba2-41df-91e7-c1e5-e03190402c23@ti.com>
Message-ID: <20231214122713.qx7as6grpvlq3ylw@stoic>

On 14:07-20231214, Vaishnav Achath wrote:
[..]
> > Trim this down to what is different from AM62P?
> > 
> 
> Thanks for the review, I will trim this down in next revision, but the above is
> just a summary of the main features of this SoC, pointing to AM62P feature set
> here seems confusing to me. why does a new user/developer using J722S need to be
> aware of the existence of AM62P to just understand a high level summary about
> this device?

Since this is a reuse device. Helps with review and focus on deltas.

[...]

> >> +	l2_0: l2-cache0 {
> >> +		compatible = "cache";
> >> +		cache-unified;
> >> +		cache-level = <2>;
> >> +		cache-size = <0x80000>;
> >> +		cache-line-size = <64>;
> >> +		cache-sets = <512>;
> >> +	};
> > 
> > ^^ this is a duplication of am62p5.dtsi? what about the spins with
> > different CPUs enabled?
> > 
> 
> Yes it is a duplicate, as of now we are not aware of plan for spins with cores
> disabled, so just followed the pattern followed for other Jacinto devices
> (J721e, J7200, J721s2, J784s4).

None of the devices have been as close a reuse device as this has been.
errata in one carries over to the other etc.. There are definitely some
differences - for example: itap/otap delays for mmc those would be
unique on this device, but overrides with documentation will make
perfect sense there.

[..]
> >> +		cbass_wakeup: bus at b00000 {
> >> +			compatible = "simple-bus";
> >> +			#address-cells = <2>;
> >> +			#size-cells = <2>;
> >> +			ranges = <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
> >> +				 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
> >> +				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* WKUP CTRL MMR */
> >> +				 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
> >> +				 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
> >> +			bootph-all;
> > 
> > Not in the bus nodes.. only in the leaf nodes please.
> > 
> > 
> > Also what is wrong with expanding the am62p to include the
> > missing bus segments instead of duplicating all of them?
> > 
> 
> We can do that, but the same would be true for AM625, AM62A and AM62P families
> and also for (J721E, J7200), since all these SoCs introduced new dtsi instead of
> resuing existing ones, I thought there would be some valid reason to have
> separate dtsi and just followed the same pattern, please let know if we need to
> reuse from AM62P here also.

See above.

[...]

> 
> >> +		};
> >> +	};
> >> +
> >> +	#include "k3-am62p-thermal.dtsi"
> > 
> > Is this correct?
> > 
> 
> I think it would be preferred to have a duplicate for J722S here as users may
> want to customize the trip points as per system and doing that without affecting
> AM62P would be preferred, but the initial information here would be same for J722S.

Please check with your hardware teams if the am62p SoC level thermal
behavior will be similar to j722s or will it be different. If it is
estimated to be different, then you'd prefer to hold off introducing
the trips till the characterization provides you with the data.

> 
> >> +};
> >> +
> >> +/*
> >> + * Include peripherals for each bus segment derived
> >> + * from AM62P and overrides specific to J722S.
> >> + */
> >> +#include "k3-am62p-main.dtsi"
> >> +#include "k3-am62p-mcu.dtsi"
> >> +#include "k3-am62p-wakeup.dtsi"
> >> +
> >> +/* Main domain overrides */
> >> +
> >> +&cpsw3g {
> >> +	status = "disabled";
> > 
> > 	here and rest: Why disabled?
> 
> These nodes seems to have dependencies that are not merged already and would
> throw errors during boot, AM62P SoC dtsi seems to have these enabled by default
> without these dependencies met and have errors like below during boot (seen on
> AM62P with 6.7.0-rc4-next-20231211).
> 
> [   17.869092] platform 8000000.ethernet: deferred probe pending:
> am65-cpsw-nuss: Failed to request tx dma channel

OK - lets get the dependencies sorted out before merging then. I though
all the dependencies were indicated in the cover letter.

> 
> >> +};
> >> +
> >> +&inta_main_dmss {
> >> +	ti,interrupt-ranges = <5 69 35>;
> >> +};
> >> +
> >> +&mailbox0_cluster0 {
> >> +	status = "disabled";
> >> +};
> >> +
> >> +&mailbox0_cluster1 {
> >> +	status = "disabled";
> >> +};
> >> +
> >> +&mailbox0_cluster2 {
> >> +	status = "disabled";
> >> +};
> >> +
> >> +&mailbox0_cluster3 {
> >> +	status = "disabled";
> >> +};
> >> +
> 
> [    7.198470] omap-mailbox 29020000.mailbox: no available mbox devices found
> [    7.210411] omap-mailbox 29030000.mailbox: no available mbox devices found

You might want to dig into why..

> 
> >> +&oc_sram {
> >> +	reg = <0x00 0x70000000 0x00 0x40000>;
> >> +	ranges = <0x00 0x00 0x70000000 0x40000>;
> >> +};
> >> +
> >> +/* MCU domain overrides */
> >> +
> >> +&mcu_r5fss0 {
> >> +	status = "disabled";
> >> +};
> 
> [    7.492406] platform 79000000.r5f: configured R5F for remoteproc mode
> [    7.499887] platform 79000000.r5f: device does not have reserved memory
> regions, ret = -22
> [    7.508271] k3_r5_rproc bus at f0000:bus at 4000000:r5fss at 79000000: reserved memory
> init failed, ret = -22
> [    7.517549] remoteproc remoteproc0: releasing 79000000.r5f
> [    7.523338] k3_r5_rproc bus at f0000:bus at 4000000:r5fss at 79000000:
> k3_r5_cluster_rproc_init failed, ret = -22
> [    7.532993] k3_r5_rproc: probe of bus at f0000:bus at 4000000:r5fss at 79000000 failed
> with error -22

Yes, and the approach should rather be to disable the remote procs in
the board or at the SoC dtsi in a consistent manner. I had previously
suggested to do that SoC level (which means at am62p dtsi) since the remoteprocs have direct
dependency on how the memory layouts are partitioned in board.dts - but
i had asked folks working on remote procs to do that consistently across
SoCs. I don't see that having been done so far.

> 
> >> +
> >> +/* wakeup domain overrides */
> >> +
> >> +&wkup_r5fss0 {
> >> +	status = "disabled";
> >> +};
> 
> [    7.576576] platform 78000000.r5f: configured R5F for IPC-only mode
> [    7.605535] platform 78000000.r5f: device does not have reserved memory
> regions, ret = -22
> [    7.613942] k3_r5_rproc bus at f0000:bus at b00000:r5fss at 78000000: reserved memory
> init failed, ret = -22
> [    7.635990] remoteproc remoteproc0: releasing 78000000.r5f
> [    7.648639] k3_r5_rproc bus at f0000:bus at b00000:r5fss at 78000000:
> k3_r5_cluster_rproc_init failed, ret = -22
> [    7.664043] k3_r5_rproc: probe of bus at f0000:bus at b00000:r5fss at 78000000 failed
> with error -22

See above.

> 
> >> diff --git a/arch/arm64/boot/dts/ti/k3-pinctrl.h b/arch/arm64/boot/dts/ti/k3-pinctrl.h
> >> index 2a4e0e084d69..591be4489f37 100644
> >> --- a/arch/arm64/boot/dts/ti/k3-pinctrl.h
> >> +++ b/arch/arm64/boot/dts/ti/k3-pinctrl.h
> >> @@ -59,6 +59,9 @@
> >>  #define J721S2_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
> >>  #define J721S2_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
> >>  
> >> +#define J722S_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
> >> +#define J722S_MCU_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
> >> +
> >>  #define J784S4_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
> >>  #define J784S4_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
> >>  
> >> -- 
> >> 2.17.1
> >>
> 
> 0 - AM62P Boot logs (next-20231211) -
> https://gist.github.com/vaishnavachath/7143da253bc708a1e60a13fe081d3914
> 
> To avoid these errors I am keeping these disabled, can we add support for these
> also as part of the initial support addition series? then there is no need for
> disabling these.

Fix them, then introduce j722s.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From vahe.grigoryan at theobroma-systems.com  Thu Dec 14 04:27:59 2023
From: vahe.grigoryan at theobroma-systems.com (Vahe Grigoryan)
Date: Thu, 14 Dec 2023 13:27:59 +0100
Subject: [PATCH 1/3] arm64: dts: rockchip: fix misleading comment in rk3399-puma-haikou.dts
Message-ID: <20231214122801.3144180-1-vahe.grigoryan@theobroma-systems.com>

Haikou is an evaluation and development platform for System on
Modules (SOMs).

The GPIO0_B1 is routed to the Wake button instead of BIOS_DISABLE,
update the comment to reflect that.

Signed-off-by: Vahe Grigoryan <vahe.grigoryan at theobroma-systems.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
index 115c14c0a3c6..4f2d4bb12032 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
@@ -177,7 +177,7 @@ haikou_pin_hog: haikou-pin-hog {
 			  <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_up>,
 			  /* SLP_BTN# */
 			  <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_up>,
-			  /* BIOS_DISABLE# */
+			  /* WAKE# */
 			  <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
 		};
 	};
-- 
2.34.1



From vahe.grigoryan at theobroma-systems.com  Thu Dec 14 04:28:00 2023
From: vahe.grigoryan at theobroma-systems.com (Vahe Grigoryan)
Date: Thu, 14 Dec 2023 13:28:00 +0100
Subject: [PATCH 2/3] arm64: dts: rockchip: expose BIOS Disable feedback pin on rk3399-puma
In-Reply-To: <20231214122801.3144180-1-vahe.grigoryan@theobroma-systems.com>
References: <20231214122801.3144180-1-vahe.grigoryan@theobroma-systems.com>
Message-ID: <20231214122801.3144180-2-vahe.grigoryan@theobroma-systems.com>

The Puma SoM allows to select in hardware directly which storage
medium to try for loading the bootloader, either SPI-NOR followed
by eMMC followed by SD card, or SD card only.

This signal is exposed on the Q7 connector and allows carrierboards
to control it however they want.

This feedback pin allows to know in which state the SoM currently
is and provided the current state isn't modified until next reboot,
know from which storage medium the bootloader could be loaded from
next time.

Signed-off-by: Vahe Grigoryan <vahe.grigoryan at theobroma-systems.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 20e3f41efe97..ea9d6ab73df5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -119,6 +119,20 @@ &emmc_phy {
 	drive-impedance-ohm = <33>;
 };
 
+&gpio0 {
+	/*
+	 * The BIOS_DISABLE hog is a feedback pin for the actual status of the
+	 * signal. This usually represents the state of a switch on the baseboard.
+	 * The pin has a 10k pull-up resistor connected, so no pull-up setting is needed.
+	 */
+	bios-disable-hog {
+		gpios = <RK_PB0 GPIO_ACTIVE_HIGH>;
+		gpio-hog;
+		input;
+		line-name = "bios_disable";
+	};
+};
+
 &gmac {
 	assigned-clocks = <&cru SCLK_RMII_SRC>;
 	assigned-clock-parents = <&clkin_gmac>;
-- 
2.34.1



From vahe.grigoryan at theobroma-systems.com  Thu Dec 14 04:28:01 2023
From: vahe.grigoryan at theobroma-systems.com (Vahe Grigoryan)
Date: Thu, 14 Dec 2023 13:28:01 +0100
Subject: [PATCH 3/3] arm64: dts: rockchip: make Haikou buttons compatible with "gpio-keys"
In-Reply-To: <20231214122801.3144180-1-vahe.grigoryan@theobroma-systems.com>
References: <20231214122801.3144180-1-vahe.grigoryan@theobroma-systems.com>
Message-ID: <20231214122801.3144180-3-vahe.grigoryan@theobroma-systems.com>

Haikou is an evaluation and development platform for System on
Modules (SOMs).

Haikou devkit exposes multiple buttons so let's register them as
such so that the input subsystem can generate events when pressed or
switched.

Signed-off-by: Vahe Grigoryan <vahe.grigoryan at theobroma-systems.com>
---
 .../boot/dts/rockchip/rk3399-puma-haikou.dts  | 40 ++++++++++++++++---
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
index 4f2d4bb12032..18a98c4648ea 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 #include "rk3399-puma.dtsi"
+#include <dt-bindings/input/input.h>
 
 / {
 	model = "Theobroma Systems RK3399-Q7 SoM";
@@ -18,6 +19,38 @@ chosen {
 		stdout-path = "serial0:115200n8";
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-0 = <&haikou_keys_pin>;
+		pinctrl-names = "default";
+
+		button-batlow-n {
+			gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+			label = "BATLOW#";
+			linux,code = <KEY_BATTERY>;
+		};
+
+		button-slp-btn-n {
+			gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_LOW>;
+			label = "SLP_BTN#";
+			linux,code = <KEY_SLEEP>;
+		};
+
+		button-wake-n {
+			gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_LOW>;
+			label = "WAKE#";
+			linux,code = <KEY_WAKEUP>;
+			wakeup-source;
+		};
+
+		switch-lid-btn-n {
+			gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+			label = "LID_BTN#";
+			linux,code = <SW_LID>;
+			linux,input-type = <EV_SW>;
+		};
+	};
+
 	leds {
 		pinctrl-0 = <&module_led_pin>, <&sd_card_led_pin>;
 
@@ -165,11 +198,8 @@ &pcie0 {
 };
 
 &pinctrl {
-	pinctrl-names = "default";
-	pinctrl-0 = <&haikou_pin_hog>;
-
-	hog {
-		haikou_pin_hog: haikou-pin-hog {
+	buttons {
+		haikou_keys_pin: haikou-keys-pin {
 			rockchip,pins =
 			  /* LID_BTN */
 			  <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>,
-- 
2.34.1



From robin.murphy at arm.com  Thu Dec 14 04:30:55 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 14 Dec 2023 12:30:55 +0000
Subject: [PATCH v3 12/15] arm64/mm: Split __flush_tlb_range() to elide
 trailing DSB
In-Reply-To: <20231214121336.GA1015@willie-the-truck>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-13-ryan.roberts@arm.com>
 <20231212113517.GA28857@willie-the-truck>
 <0969c413-bf40-4c46-9f1e-a92101ff2d2e@arm.com>
 <2e6f06d3-6c8e-4b44-b6f2-e55bd5be83d6@arm.com>
 <20231214121336.GA1015@willie-the-truck>
Message-ID: <fbcda9e1-0473-4669-a869-d4de351c3197@arm.com>

On 2023-12-14 12:13 pm, Will Deacon wrote:
> On Thu, Dec 14, 2023 at 11:53:52AM +0000, Ryan Roberts wrote:
>> On 12/12/2023 11:47, Ryan Roberts wrote:
>>> On 12/12/2023 11:35, Will Deacon wrote:
>>>> On Mon, Dec 04, 2023 at 10:54:37AM +0000, Ryan Roberts wrote:
>>>>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
>>>>> index bb2c2833a987..925ef3bdf9ed 100644
>>>>> --- a/arch/arm64/include/asm/tlbflush.h
>>>>> +++ b/arch/arm64/include/asm/tlbflush.h
>>>>> @@ -399,7 +399,7 @@ do {									\
>>>>>   #define __flush_s2_tlb_range_op(op, start, pages, stride, tlb_level) \
>>>>>   	__flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false)
>>>>>   
>>>>> -static inline void __flush_tlb_range(struct vm_area_struct *vma,
>>>>> +static inline void __flush_tlb_range_nosync(struct vm_area_struct *vma,
>>>>>   				     unsigned long start, unsigned long end,
>>>>>   				     unsigned long stride, bool last_level,
>>>>>   				     int tlb_level)
>>>>> @@ -431,10 +431,19 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
>>>>>   	else
>>>>>   		__flush_tlb_range_op(vae1is, start, pages, stride, asid, tlb_level, true);
>>>>>   
>>>>> -	dsb(ish);
>>>>>   	mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, start, end);
>>>>>   }
>>>>>   
>>>>> +static inline void __flush_tlb_range(struct vm_area_struct *vma,
>>>>> +				     unsigned long start, unsigned long end,
>>>>> +				     unsigned long stride, bool last_level,
>>>>> +				     int tlb_level)
>>>>> +{
>>>>> +	__flush_tlb_range_nosync(vma, start, end, stride,
>>>>> +				 last_level, tlb_level);
>>>>> +	dsb(ish);
>>>>> +}
>>>>
>>>> Hmm, are you sure it's safe to defer the DSB until after the secondary TLB
>>>> invalidation? It will have a subtle effect on e.g. an SMMU participating
>>>> in broadcast TLB maintenance, because now the ATC will be invalidated
>>>> before completion of the TLB invalidation and it's not obviously safe to me.
>>>
>>> I'll be honest; I don't know that it's safe. The notifier calls turned up during
>>> a rebase and I stared at it for a while, before eventually concluding that I
>>> should just follow the existing pattern in __flush_tlb_page_nosync(): That one
>>> calls the mmu notifier without the dsb, then flush_tlb_page() does the dsb
>>> after. So I assumed it was safe.
>>>
>>> If you think it's not safe, I guess there is a bug to fix in
>>> __flush_tlb_page_nosync()?
>>
>> Did you have an opinion on this? I'm just putting together a v4 of this series,
>> and I'll remove this optimization if you think it's unsound. But in that case, I
>> guess we have an existing bug to fix too?
> 
> Sorry, Ryan, I've not had a chance to look into it in more detail. But as
> you rightly point out, you're not introducing the issue (assuming it is
> one), so I don't think it needs to hold you up. Your code just makes the
> thing more "obvious" to me.
> 
> Robin, Jean-Philippe -- do we need to make sure that the SMMU has completed
> its TLB invalidation before issuing an ATC invalidate? My half-baked worry
> is whether or not an ATS request could refill the ATC before the TLBI
> has completed, therefore rendering the ATC invalidation useless.

I would agree, and the spec for CMD_ATC_INV does call out a 
TLBI->sync->ATCI->sync sequence. At the moment the SVA notifier is 
issuing its own command-based TLBIs anyway so the necessary sync is 
implicit there, but if and when we get BTM support wired up properly it 
would be nice not to have to bodge in an additional sync/DSB.

Cheers,
Robin.


From arnd at kernel.org  Thu Dec 14 04:32:15 2023
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu, 14 Dec 2023 13:32:15 +0100
Subject: [PATCH] drm/exynos: fix accidental on-stack copy of exynos_drm_plane
Message-ID: <20231214123237.1727428-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

gcc rightfully complains about excessive stack usage in the fimd_win_set_pixfmt()
function:

drivers/gpu/drm/exynos/exynos_drm_fimd.c: In function 'fimd_win_set_pixfmt':
drivers/gpu/drm/exynos/exynos_drm_fimd.c:750:1: error: the frame size of 1032 bytes is larger than 1024 byte
drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function 'decon_win_set_pixfmt':
drivers/gpu/drm/exynos/exynos5433_drm_decon.c:381:1: error: the frame size of 1032 bytes is larger than 1024 bytes

There is really no reason to copy the large exynos_drm_plane
structure to the stack before using one of its members, so just
use a pointer instead.

Fixes: 6f8ee5c21722 ("drm/exynos: fimd: Make plane alpha configurable")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c      | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 4d986077738b..bce027552474 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -319,9 +319,9 @@ static void decon_win_set_bldmod(struct decon_context *ctx, unsigned int win,
 static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
 				 struct drm_framebuffer *fb)
 {
-	struct exynos_drm_plane plane = ctx->planes[win];
+	struct exynos_drm_plane *plane = &ctx->planes[win];
 	struct exynos_drm_plane_state *state =
-		to_exynos_plane_state(plane.base.state);
+		to_exynos_plane_state(plane->base.state);
 	unsigned int alpha = state->base.alpha;
 	unsigned int pixel_alpha;
 	unsigned long val;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8dde7b1e9b35..5bdc246f5fad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -661,9 +661,9 @@ static void fimd_win_set_bldmod(struct fimd_context *ctx, unsigned int win,
 static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
 				struct drm_framebuffer *fb, int width)
 {
-	struct exynos_drm_plane plane = ctx->planes[win];
+	struct exynos_drm_plane *plane = &ctx->planes[win];
 	struct exynos_drm_plane_state *state =
-		to_exynos_plane_state(plane.base.state);
+		to_exynos_plane_state(plane->base.state);
 	uint32_t pixel_format = fb->format->format;
 	unsigned int alpha = state->base.alpha;
 	u32 val = WINCONx_ENWIN;
-- 
2.39.2



From tianruidong at linux.alibaba.com  Thu Dec 14 04:33:01 2023
From: tianruidong at linux.alibaba.com (Ruidong Tian)
Date: Thu, 14 Dec 2023 20:33:01 +0800
Subject: [PATCH 0/3] perf scripts python: arm-cs-trace-disasm.py:
Message-ID: <20231214123304.34087-1-tianruidong@linux.alibaba.com>

Now the instruction flow disasmed by arm-cs-trace-disasm.py is
ambiguous and uncorrect, fix them in one patch set. Please refer to
each patch for details.

Ruidong Tian (3):
  perf scripts python: arm-cs-trace-disasm.py: print dso base address
  perf scripts python: arm-cs-trace-disasm.py: set start vm addr of
    exectable file to 0
  perf scripts python: arm-cs-trace-disasm.py: do not ignore disam first
    sample

 .../scripts/python/arm-cs-trace-disasm.py     | 28 +++++++++++--------
 1 file changed, 16 insertions(+), 12 deletions(-)

-- 
2.33.1



From tianruidong at linux.alibaba.com  Thu Dec 14 04:33:02 2023
From: tianruidong at linux.alibaba.com (Ruidong Tian)
Date: Thu, 14 Dec 2023 20:33:02 +0800
Subject: [PATCH 1/3] perf scripts python: arm-cs-trace-disasm.py: print dso base address
In-Reply-To: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
Message-ID: <20231214123304.34087-2-tianruidong@linux.alibaba.com>

arm-cs-trace-disasm just print offset for library dso:

	0000000000002200 <memcpy>:
            2200: d503201f      nop
            2204: 8b020024      add     x4, x1, x2
            2208: 8b020005      add     x5, x0, x2

This print DSO base address to get complete virtual address for
userspace application:

	0000000000002200 <memcpy>: (base address is 0x0000ffffb4c21000)
            2200: d503201f      nop
            2204: 8b020024      add     x4, x1, x2
            2208: 8b020005      add     x5, x0, x2

Signed-off-by: Ruidong Tian <tianruidong at linux.alibaba.com>
---
 tools/perf/scripts/python/arm-cs-trace-disasm.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
index d59ff53f1d94..46bf6b02eea1 100755
--- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
+++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
@@ -108,6 +108,8 @@ def print_disam(dso_fname, dso_start, start_addr, stop_addr):
 			m = disasm_re.search(line)
 			if m is None:
 				continue
+		else:
+			line += " (base address is 0x%016x)" % dso_start
 		print("\t" + line)
 
 def print_sample(sample):
-- 
2.33.1



From tianruidong at linux.alibaba.com  Thu Dec 14 04:33:03 2023
From: tianruidong at linux.alibaba.com (Ruidong Tian)
Date: Thu, 14 Dec 2023 20:33:03 +0800
Subject: [PATCH 2/3] perf scripts python: arm-cs-trace-disasm.py: set start vm addr of exectable file to 0
In-Reply-To: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
Message-ID: <20231214123304.34087-3-tianruidong@linux.alibaba.com>

For exectable ELF file, which e_type is ET_EXEC, dso start address is a
absolute address other than offset. Just set vm_start to zero when dso
start is 0x400000, which means it is a exectable file.

Signed-off-by: Ruidong Tian <tianruidong at linux.alibaba.com>
---
 tools/perf/scripts/python/arm-cs-trace-disasm.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
index 46bf6b02eea1..c9e14af5b58c 100755
--- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
+++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
@@ -260,8 +260,9 @@ def process_event(param_dict):
 
 	if (options.objdump_name != None):
 		# It doesn't need to decrease virtual memory offset for disassembly
-		# for kernel dso, so in this case we set vm_start to zero.
-		if (dso == "[kernel.kallsyms]"):
+		# for kernel dso and executable file dso, so in this case we set
+		# vm_start to zero.
+		if (dso == "[kernel.kallsyms]" or dso_start == 0x400000):
 			dso_vm_start = 0
 		else:
 			dso_vm_start = int(dso_start)
-- 
2.33.1



From tianruidong at linux.alibaba.com  Thu Dec 14 04:33:04 2023
From: tianruidong at linux.alibaba.com (Ruidong Tian)
Date: Thu, 14 Dec 2023 20:33:04 +0800
Subject: [PATCH 3/3] perf scripts python: arm-cs-trace-disasm.py: do not ignore disam first sample
In-Reply-To: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
Message-ID: <20231214123304.34087-4-tianruidong@linux.alibaba.com>

arm-cs-trace-disasm ignore disam the first branch sample, For example as
follow, the instructions beteween 0x0000ffffae878750 and
0x0000ffffae878754 is lose:

  ARM CoreSight Trace Data Assembler Dump
  Event type: branches:uH
  Sample = { cpu: 0000 addr: 0x0000ffffae878750 phys_addr: 0x0000000000000000 ip: 0x0000000000000000 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
  Event type: branches:uH
  Sample = { cpu: 0000 addr: 0x0000000000000000 phys_addr: 0x0000000000000000 ip: 0x0000ffffae878754 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }

Initialize cpu_data earlier to fix it:

  ARM CoreSight Trace Data Assembler Dump
  Event type: branches:uH
  Sample = { cpu: 0000 addr: 0x0000000000000000 phys_addr: 0x0000000000000000 ip: 0x0000ffffae878754 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
        0000000000028740 <ioctl>: (base address is 0x0000ffffae850000)
           28750: b13ffc1f      cmn     x0, #4095
           28754: 54000042      b.hs    0x2875c <ioctl+0x1c>
            test 4003489/4003489 [0000]     26765.151766034  __GI___ioctl+0x14                        /usr/lib64/libc-2.32.so
  Event type: branches:uH
  Sample = { cpu: 0000 addr: 0x0000ffffa67535ac phys_addr: 0x0000000000000000 ip: 0x0000000000000000 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }

Signed-off-by: Ruidong Tian <tianruidong at linux.alibaba.com>
---
 .../scripts/python/arm-cs-trace-disasm.py     | 21 ++++++++++---------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
index c9e14af5b58c..b1eb4293cbef 100755
--- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
+++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
@@ -190,6 +190,17 @@ def process_event(param_dict):
 	dso_end = get_optional(param_dict, "dso_map_end")
 	symbol = get_optional(param_dict, "symbol")
 
+	cpu = sample["cpu"]
+	ip = sample["ip"]
+	addr = sample["addr"]
+
+	# Initialize CPU data if it's empty, and directly return back
+	# if this is the first tracing event for this CPU.
+	if (cpu_data.get(str(cpu) + 'addr') == None):
+		cpu_data[str(cpu) + 'addr'] = addr
+		return
+
+
 	if (options.verbose == True):
 		print("Event type: %s" % name)
 		print_sample(sample)
@@ -211,16 +222,6 @@ def process_event(param_dict):
 	if (name[0:8] != "branches"):
 		return
 
-	cpu = sample["cpu"]
-	ip = sample["ip"]
-	addr = sample["addr"]
-
-	# Initialize CPU data if it's empty, and directly return back
-	# if this is the first tracing event for this CPU.
-	if (cpu_data.get(str(cpu) + 'addr') == None):
-		cpu_data[str(cpu) + 'addr'] = addr
-		return
-
 	# The format for packet is:
 	#
 	#		  +------------+------------+------------+
-- 
2.33.1



From xu.yang_2 at nxp.com  Thu Dec 14 04:33:42 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 12:33:42 +0000
Subject: [EXT] Re: [PATCH 1/3] usb: chipidea: ci_hdrc_imx: add wakeup
 clock and keep it always on
In-Reply-To: <2023121447-consent-decent-7c69@gregkh>
References: <20231214112622.2412321-1-xu.yang_2@nxp.com>
 <2023121447-consent-decent-7c69@gregkh>
Message-ID: <VI1PR04MB5152789243EC6EA15B535B1E8C8CA@VI1PR04MB5152.eurprd04.prod.outlook.com>

Hi Greg,

> 
> On Thu, Dec 14, 2023 at 07:26:20PM +0800, Xu Yang wrote:
> > Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
> > on without usb driver intervention. And some may need driver to handle
> > this clock. This patch will get wakeup clock and keep it always on to
> > make controller work correctlly.
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > ---
> >  drivers/usb/chipidea/ci_hdrc_imx.c | 22 +++++++++++++++++++++-
> >  1 file changed, 21 insertions(+), 1 deletion(-)
> >
> 
> Why do I have 2 different copies of this series?  Please fix up and send
> a v2 and describe what changed...

Sorry for this, I forgot to add some maillists. I should add RESEND in the title.
Will send v2 later.

Thanks,
Xu Yang

> 
> thanks,
> 
> greg k-h


From xu.yang_2 at nxp.com  Thu Dec 14 04:34:48 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 12:34:48 +0000
Subject: [EXT] Re: [PATCH 4/4] arm64: dts: imx93-11x11-evk: enable usb and
 typec nodes
In-Reply-To: <CAOMZO5AXB8h6+fqPO3aCsa1=-etRzPMZSLn7Kca6egUmUX822Q@mail.gmail.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
 <20231214112442.2412079-4-xu.yang_2@nxp.com>
 <CAOMZO5AXB8h6+fqPO3aCsa1=-etRzPMZSLn7Kca6egUmUX822Q@mail.gmail.com>
Message-ID: <VI1PR04MB5152593905C7BE186F72FECB8C8CA@VI1PR04MB5152.eurprd04.prod.outlook.com>

Hi Fabio,

>
> On Thu, Dec 14, 2023 at 8:19?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
> >
> > There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > ---
> >  .../boot/dts/freescale/imx93-11x11-evk.dts    | 108 ++++++++++++++++++
> >  1 file changed, 108 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > index 2b9d47716f75..42b1ea7d5220 100644
> > --- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > @@ -5,6 +5,7 @@
> >
> >  /dts-v1/;
> >
> > +#include <dt-bindings/usb/pd.h>
> >  #include "imx93.dtsi"
> >
> >  / {
> > @@ -103,6 +104,70 @@ &mu2 {
> >         status = "okay";
> >  };
> >
> > +&lpi2c3 {
> > +       #address-cells = <1>;
> > +       #size-cells = <0>;
> > +       clock-frequency = <400000>;
> > +       pinctrl-names = "default", "sleep";
> > +       pinctrl-0 = <&pinctrl_lpi2c3>;
> > +       pinctrl-1 = <&pinctrl_lpi2c3>;
> > +       status = "okay";
> > +
> > +       ptn5110: tcpc at 50 {
> > +               compatible = "nxp,ptn5110";
> > +               reg = <0x50>;
> > +               interrupt-parent = <&gpio3>;
> > +               interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> > +               status = "okay";
> > +
> > +               port {
> > +                       typec1_dr_sw: endpoint {
> > +                               remote-endpoint = <&usb1_drd_sw>;
> > +                       };
> > +               };
> > +
> > +               typec1_con: connector {
> > +                       compatible = "usb-c-connector";
> > +                       label = "USB-C";
> > +                       power-role = "dual";
> > +                       data-role = "dual";
> > +                       try-power-role = "sink";
> > +                       source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> > +                       sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
> > +                                    PDO_VAR(5000, 20000, 3000)>;
> > +                       op-sink-microwatt = <15000000>;
> > +                       self-powered;
>
> Your patch introduce dt-schema warnings.
>
> Port should be placed under connector as per nxp,ptn5110.yaml.

Will fix this in v2.

>
> Please check:
> https://git.kernel.org/pub/scm/linux/kernel/git%25
> 2Fshawnguo%2Flinux.git%2Fcommit%2F%3Fh%3Dfor-
> next%26id%3Dde0bae0b75f288381746bb9f6d6fd1b30f397975&data=05%7C02%7Cxu.yang_2%40nxp.com%7Ce1e0fd394e3c40
> 11339a08dbfc975a81%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638381499208779172%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FoJfshUH
> ngC23vxDSTUfmRVnW%2FKIFMwUw8YZOkR461Y%3D&reserved=0

From xu.yang_2 at nxp.com  Thu Dec 14 04:35:38 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 12:35:38 +0000
Subject: [EXT] Re: [PATCH 3/3] usb: phy: mxs: remove CONFIG_USB_OTG
 condition for mxs_phy_is_otg_host()
In-Reply-To: <CAOMZO5CRj2yry0Hm6wjueX0PQi+aWXNptqnyu=Ai1CYWVJC0nA@mail.gmail.com>
References: <20231214112622.2412321-1-xu.yang_2@nxp.com>
 <20231214112622.2412321-3-xu.yang_2@nxp.com>
 <CAOMZO5CRj2yry0Hm6wjueX0PQi+aWXNptqnyu=Ai1CYWVJC0nA@mail.gmail.com>
Message-ID: <VI1PR04MB5152533DB1BFD0090488CE4A8C8CA@VI1PR04MB5152.eurprd04.prod.outlook.com>

Hi Fabio,

> 
> On Thu, Dec 14, 2023 at 8:20?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
> >
> > When CONFIG_USB_OTG is not set, mxs_phy_is_otg_host() will always return
> > false. This behaviour is wrong. Since phy.last_event will always be set
> > for either host or device mode. Therefore, CONFIG_USB_OTG condition
> > can be removed.
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> Fixes tag?

Sorry, will add tag in v2.

From vigneshr at ti.com  Thu Dec 14 04:36:41 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Thu, 14 Dec 2023 18:06:41 +0530
Subject: [PATCH] arm64: dts: ti: k3-am625-beagleplay: Use pwrseq for TI's
 wl18xx enable.
In-Reply-To: <20231213213219.566369-1-sukrut.bellary@linux.com>
References: <20231213213219.566369-1-sukrut.bellary@linux.com>
Message-ID: <81531cd8-5625-474c-9cdc-0eb63e039cf3@ti.com>

Hi

Thanks for the patch. Few comments

On 14/12/23 03:02, Sukrut Bellary wrote:
> BeaglePlay SBC has Texas Instrument's WL18xx WiFi Chipset.
> 
> BeaglePlay SBC:
> https://www.beagleboard.org/boards/beagleplay
> 
> TI WL18XX:
> https://www.ti.com/lit/ds/symlink/wl1807mod.pdf
> 
> Currently, WLAN_EN is configured as regulator and regulator-always-on.
> During hibernation thaw, WiFi fails to come online.
> During freeze/suspend,
> the WLAN_EN line is not put to low '0' to power down the WiFi.
> So during restore, the WiFi driver tries to load the FW without following
> correct power sequence.
> WLAN_EN => '1'/assert (high) to power-up the chipset.
> WLAN_EN => '0'/deassert (low) to shut-down the chipset.
> 
> thaw failure log below:
> 
> Use mmc-pwrseq-simple to drive TI's WiFi (WL18xx) chipset enable 'WLAN_EN'.
> mmc-pwrseq-simple provides power sequence flexibility with support for
> post power-on and power-off delays.
> 
> ================ thaw failure Log ================
> [  161.418528] ------------[ cut here ]------------
> [  161.418540] WARNING: CPU: 1 PID: 45 at drivers/net/wireless/ti/wlcore/sdio.c:123 wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]

Adding full stack dump is usually noise. This line alone should be
sufficient to point to the location of dump. Besides you have the link
to the full log for anyone looking for more details

> [  161.418576] Modules linked in: br_netfilter bridge stp llc overlay usb_f_mass_storage usb_f_acm u_serial usb_f_ncm usb_f_rndis u_ether libcomposite wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce6[  161.418676] CPU: 1 PID: 45 Comm: kworker/u8:2 Not tainted 6.5.0-rc6+ #2
> [  161.418684] Hardware name: BeagleBoard.org BeaglePlay (DT)
> [  161.418691] Workqueue: events_unbound async_run_entry_fn
> [  161.418711] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [  161.418719] pc : wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]
> [  161.418731] lr : wl12xx_sdio_raw_write+0x94/0x168 [wlcore_sdio]
> [  161.418743] sp : ffff800082b43970
> [  161.418746] x29: ffff800082b43970 x28: ffff800083c5b000 x27: 0000000000000003
> [  161.418757] x26: ffff80007aab3800 x25: ffff800083c53000 x24: 0000000000000000
> [  161.418767] x23: 0000000000004000 x22: ffff00000f938000 x21: ffff000005bd3010
> [  161.418778] x20: 0000000000008000 x19: ffff000005bd2000 x18: 0000000000000000
> [  161.418789] x17: 0000000000000100 x16: 0000000000000000 x15: f44fb9a9e0200014
> [  161.418799] x14: 0000000000000049 x13: 000000000000038f x12: 0000000000000000
> [  161.418809] x11: 0000000000000001 x10: 0000000000000a50 x9 : ffff800082b43550
> [  161.418819] x8 : ffff000000ca2830 x7 : ffff00007fb92f40 x6 : 00000007e5428bd2
> [  161.418829] x5 : 03ffffffffffffff x4 : ffff0000002569c0 x3 : 0000000000000000
> [  161.418839] x2 : 0000000000000001 x1 : ffff000000256810 x0 : 00000000ffffff92
> [  161.418850] Call trace:
> [  161.418856]  wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]
> [  161.418869]  wlcore_raw_write.constprop.0+0x4c/0xac [wlcore]
> [  161.418931]  wlcore_boot_upload_firmware+0x140/0x3c0 [wlcore]
> [  161.418973]  wl18xx_boot+0x574/0x77c [wl18xx]
> [  161.419011]  wl1271_op_add_interface+0x5f0/0xaa8 [wlcore]
> [  161.419052]  drv_add_interface+0x3c/0x88 [mac80211]
> [  161.419228]  ieee80211_reconfig+0x1a8/0xf1c [mac80211]
> [  161.419330]  ieee80211_resume+0x54/0x70 [mac80211]
> [  161.419432]  wiphy_resume+0x84/0xf8 [cfg80211]
> [  161.419562]  device_resume+0x84/0x178
> [  161.419576]  async_resume+0x28/0x74
> [  161.419584]  async_run_entry_fn+0x34/0xe0
> [  161.419596]  process_one_work+0x1e0/0x340
> [  161.419605]  worker_thread+0x68/0x428
> [  161.419613]  kthread+0x114/0x118
> [  161.419620]  ret_from_fork+0x10/0x20
> [  161.419630] ---[ end trace 0000000000000000 ]---
> [  161.419726] wl1271_sdio mmc2:0001:2: sdio write failed (-110)
> [  162.341981] wlcore: using inverted interrupt logic: 2
> [  170.553515] ------------[ cut here ]------------
> 
> [  180.315942] ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume+0x0/0xf8 [cfg80211] returns -110
> [  180.316090] ieee80211 phy0: PM: failed to thaw async: error -110
> ======================================================
> 
> Full thaw failure log -
> https://gist.github.com/sukrutb/8b02a9ffa7bd1cb9fb514220e9af097e
> 
> Suggested-by: Shengyu Qu <wiagn233 at outlook.com>
> Signed-off-by: Sukrut Bellary <sukrut.bellary at linux.com>
> ---
>  .../arm64/boot/dts/ti/k3-am625-beagleplay.dts | 25 ++++++++-----------
>  1 file changed, 10 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
> index eadbdd9ffe37..d388c5e78658 100644
> --- a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
> @@ -83,6 +83,15 @@ wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory at 9db00000 {
>  		};
>  	};
>  
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_en_pins_default>;

> +		post-power-on-delay-ms = <1>;
> +		power-off-delay-us = <80>;

how did you arrive at these delay's. A comment to that order would be
good to add.

> +		reset-gpios = <&main_gpio0 38 GPIO_ACTIVE_LOW>;
> +	};
> +
>  	vsys_5v0: regulator-1 {
>  		bootph-all;
>  		compatible = "regulator-fixed";
> @@ -105,20 +114,6 @@ vdd_3v3: regulator-2 {
>  		regulator-boot-on;
>  	};
>  
> -	wlan_en: regulator-3 {
> -		/* OUTPUT of SN74AVC2T244DQMR */
> -		compatible = "regulator-fixed";
> -		regulator-name = "wlan_en";
> -		regulator-min-microvolt = <1800000>;
> -		regulator-max-microvolt = <1800000>;
> -		enable-active-high;
> -		regulator-always-on;
> -		vin-supply = <&vdd_3v3>;
> -		gpio = <&main_gpio0 38 GPIO_ACTIVE_HIGH>;
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&wifi_en_pins_default>;
> -	};
> -
>  	vdd_3v3_sd: regulator-4 {
>  		/* output of TPS22918DBVR-U21 */
>  		bootph-all;
> @@ -849,7 +844,6 @@ &sdhci1 {
>  };
>  
>  &sdhci2 {
> -	vmmc-supply = <&wlan_en>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&wifi_pins_default>, <&wifi_32k_clk>;
>  	bus-width = <4>;
> @@ -857,6 +851,7 @@ &sdhci2 {
>  	ti,fails-without-test-cd;
>  	cap-power-off-card;
>  	keep-power-in-suspend;
> +	mmc-pwrseq = <&sdio_pwrseq>;
>  	ti,driver-strength-ohm = <50>;
>  	assigned-clocks = <&k3_clks 157 158>;
>  	assigned-clock-parents = <&k3_clks 157 160>;

-- 
Regards
Vignesh


From xu.yang_2 at nxp.com  Thu Dec 14 04:44:35 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 12:44:35 +0000
Subject: [EXT] Re: [PATCH 2/4] arm64: dts: imx8ulp-evk: enable usb nodes
In-Reply-To: <CAOMZO5CgzioWKjWkhmQjL58GGGmDSsm9SD1f6YAX2EyM0DNJtA@mail.gmail.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
 <20231214112442.2412079-2-xu.yang_2@nxp.com>
 <CAOMZO5CgzioWKjWkhmQjL58GGGmDSsm9SD1f6YAX2EyM0DNJtA@mail.gmail.com>
Message-ID: <VI1PR04MB515264C2492276E42BA33F2D8C8CA@VI1PR04MB5152.eurprd04.prod.outlook.com>

Hi Fabio,

> 
> On Thu, Dec 14, 2023 at 8:19?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
> 
> > +&usbphy1 {
> > +       status = "okay";
> > +       fsl,tx-d-cal = <110>;
> 
> Place status as the last property.

Okay.

> 
> > +&usbphy2 {
> > +       status = "okay";
> > +       fsl,tx-d-cal = <110>;
> 
> Place status as the last property.

Okay.

> 
> > +};
> > +
> > +&usbmisc2 {
> > +       status = "okay";
> > +};
> > +
> >  &usdhc0 {
> >         pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> >         pinctrl-0 = <&pinctrl_usdhc0>;
> > @@ -224,6 +264,20 @@ MX8ULP_PAD_PTE13__LPI2C7_SDA       0x20
> >                 >;
> >         };
> >
> > +       pinctrl_otgid1: usb1grp {
> 
> pinctrl_ubs1: usb1grp

Okay.

> 
> > +               fsl,pins = <
> > +                       MX8ULP_PAD_PTF2__USB0_ID        0x10003
> > +                       MX8ULP_PAD_PTF4__USB0_OC        0x10003
> > +               >;
> > +       };
> > +
> > +       pinctrl_otgid2: usb2grp {
> 
> pinctrl_usb2: usb2grp

Okay.


From trini at konsulko.com  Thu Dec 14 04:48:31 2023
From: trini at konsulko.com (Tom Rini)
Date: Thu, 14 Dec 2023 07:48:31 -0500
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAK7LNATyD-PeNbaLTjJmU9=koqqE+V6QvFe09c2VrXopWvjpcw@mail.gmail.com>
References: <20231202035511.487946-1-sjg@chromium.org>
 <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com>
 <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com>
 <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
 <20231209152946.GC13421@pendragon.ideasonboard.com>
 <CAMuHMdVMZs6mnwWBgFwktO=8o=QzROv60cfZe085MhD6HxQjpQ@mail.gmail.com>
 <CAGXv+5Est3FL-XcEL-vB-6zVNas0mqb2cNYa==Yb7W2SQU9xVQ@mail.gmail.com>
 <CAK7LNATyD-PeNbaLTjJmU9=koqqE+V6QvFe09c2VrXopWvjpcw@mail.gmail.com>
Message-ID: <20231214124831.GX2513409@bill-the-cat>

On Thu, Dec 14, 2023 at 03:12:07PM +0900, Masahiro Yamada wrote:
> On Thu, Dec 14, 2023 at 1:03?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> >
> > On Sun, Dec 10, 2023 at 1:31?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > >
> > > Hi Laurent,
> > >
> > > On Sat, Dec 9, 2023 at 4:29?PM Laurent Pinchart
> > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > On Thu, Dec 7, 2023 at 11:38?PM Laurent Pinchart
> > > > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > > performance.
> > > > > > > > >
> > > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > > >
> > > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > > filenames or other workarounds.
> > > > > > > > >
> > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > >
> > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > >
> > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > > $(obj)/image.fit
> > > > > > > > >
> > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > > >
> > > > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > > > balance between what makes sense for the kernel and the features that
> > > > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > > > to delay merging this series.
> > > > > > > >
> > > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > > > to a second question: would you consider merging extensions to this
> > > > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > > > users who manually invoke the script ? More generally, is the script
> > > > > > >
> > > > > > > We'd also be interested in some customization, though in a different way.
> > > > > > > We imagine having a rule file that says X compatible string should map
> > > > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > > > carry all the possible second source components, like different display
> > > > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > > > >
> > > > > > Do you envision the "mapping" compatible string mapping to a config
> > > > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > > > >
> > > > > That's exactly the idea. The mapping compatible string could be untied
> > > > > from the base board's compatible string if needed (which we probably do).
> > > > >
> > > > > So something like:
> > > > >
> > > > > config {
> > > > >     config-1 {
> > > > >         compatible = "google,krane-sku0";
> > > > >         fdt = "krane-baseboard", "krane-sku0-overlay";
> > > > >     };
> > > > > };
> > > > >
> > > > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > > > between the SKUs, in this case the display panel and MIPI camera (not
> > > > > upstreamed) that applies to SKU0 in particular.
> > > >
> > > > The kernel DT makefiles already contain information on what overlays to
> > > > apply to what base boards, in order to test the overlays and produce
> > > > "full" DTBs. Maybe that information could be leveraged to create the
> > > > configurations in the FIT image ?
> > >
> > > Although the "full" DTBs created may only be a subset of all possible
> > > combinations (I believe Rob just started with creating one "full" DTB
> > > for each overlay, cfr. the additions I made in commit a09c3e105a208580
> > > ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> > > definitely be a start.
> > >
> > > Now, since the kernel build system already creates "full" DTBs, does
> > > that mean that all of the base DTBs, overlays, and "full" DTBs will
> > > end up in the FIT image?
> >
> > I suppose we could add an option to the packing tool to be able to _not_
> > add the "full" DTBs if they can also be assembled with a base DTB and
> > overlays. Think of it as a firmware compatibility option: if the firmware
> > supports overlays, then you almost always want the deconstructed parts,
> > not the fully assembled ones. Vice versa.
> >
> > If we don't we could end up with two configurations that have the same
> > compatible string?
> 
> 
> Right.
> 
> We would end up with such situations because applying
> an overlay does not change the compatible string.
> 
> 
> 
> With this code in arch/arm64/boot/dts/ti/Makefile:
> 
> k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
>       k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
> k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
>       k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
> 
> 
> 
> 
> $ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb
> 2>/dev/null| head -n15 | tail -n2
>     model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
>     compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
> "ti,am642";
> 
> 
> $ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
> 2>/dev/null| head -n15 | tail -n2
>     model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
>     compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
> "ti,am642";
> 
> 
> 
> 
> 
> These two go into image.fit, but one of them is completely dead
> since there is no way to distinguish them.

I'd asked Rob about the problem of multiple platforms that don't have a
unique compatible string, and never did quite conclude if the spec needs
to spell out one way or another if they really need to be unique.
There's some valid use cases where you might not, but then there's cases
like the above where that really seems like a dts bug (and those
platforms should have their dts* files reworked to be like other
carrier+som+different peripherals and likely be
tq,am642-tqma6442l-mbax4xxl-wlan and so on).

> 
> 
> $ fdtdump  arch/arm64/boot/image.fit
> 
>         ...
> 
>         conf-10 {
>             compatible = "tq,am642-tqma6442l-mbax4xxl",
> "tq,am642-tqma6442l", "ti,am642";
>             description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
>             fdt = "fdt-10";
>             kernel = "kernel";
>         };
> 
>         ...
> 
>         conf-25 {
>             compatible = "tq,am642-tqma6442l-mbax4xxl",
> "tq,am642-tqma6442l", "ti,am642";
>             description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
>             fdt = "fdt-25";
>             kernel = "kernel";
>         };
> 
> 
> 
> 
> 
> I agree with Chen-Yu.

> FIT should not include full DTBs.
> 
> Bootloaders should assemble the final DTB
> from base and overlays on-the-fly.

I think we need to think about that more because both FIT and UKI try
and solve the problem of a single verifiyable (in the various security /
secure boot meanings of the word) image. So saying "but not DTBs" will I
believe become "let the distribution people worry about it".

Or am I misunderstanding your comment, and this is only in the context
of real or quasi overlays?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/3d8c1db6/attachment-0001.sig>

From xu.yang_2 at nxp.com  Thu Dec 14 04:50:24 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 14 Dec 2023 12:50:24 +0000
Subject: [EXT] Re: [PATCH 2/4] arm64: dts: imx8ulp-evk: enable usb nodes
In-Reply-To: <CAOMZO5DxcLoBYMXQi=EW=-fAqz12ghPm+7PHn=LdhicETKg2pQ@mail.gmail.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
 <20231214112442.2412079-2-xu.yang_2@nxp.com>
 <CAOMZO5DxcLoBYMXQi=EW=-fAqz12ghPm+7PHn=LdhicETKg2pQ@mail.gmail.com>
Message-ID: <VI1PR04MB51523F1EF74EF23B92C6880D8C8CA@VI1PR04MB5152.eurprd04.prod.outlook.com>

Hi Fabio,

> 
> On Thu, Dec 14, 2023 at 8:19?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
> >
> > Enable 2 USB nodes on i.MX8ULP evk board.
> 
> imx8ulp-evk schematics show two PTN5150 and two USB Type-C connectors.
> 
> Why are they not represented in the devicetree?

PTN5150 can work autonomously for most of the basic functions.
I don?t see a need to enable driver for it now.

Thanks,
Xu Yang

From nm at ti.com  Thu Dec 14 04:51:30 2023
From: nm at ti.com (Nishanth Menon)
Date: Thu, 14 Dec 2023 06:51:30 -0600
Subject: [PATCH] arm64: dts: ti: k3-j721e: Add support for DFS in J721E
 A72
In-Reply-To: <20231214075637.176586-1-n-francis@ti.com>
References: <20231214075637.176586-1-n-francis@ti.com>
Message-ID: <20231214125130.zqtq6ioj4c533wha@elbow>

On 13:26-20231214, Neha Malcom Francis wrote:
> Add 2G, 1.5G, 1G, 750M, 500M and 250M as the supported frequencies for
> A72. This enables support for Dynamic Frequency Scaling (DFS).
> 

Just curious, since I picked up the PMIC support... can we do dvfs? if
not, please indicate that in the commit message.

> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
> ---
> Boot logs:
> https://gist.github.com/nehamalcom/e3c3d0446f0467e7fd28706f7ffaeea8
> 
> J721E SoC has three different speed grade devices (see [1], 7.5
> Operating Performance Points) which as of today are indiscernible in
> software, users of a different speed grade device must manually change
> the DTS to ensure their maximum speed frequency is supported.
> 
> [1] https://www.ti.com/lit/gpn/tda4vm
This is critical info in the commit message and in documentation of
source.

I am also concerned if the table should be separated out as a dtsi and
included at board.dts level to prevent downstream users going crazy..

Are you absolutely sure this has no detection logic that can be
implemented? Almost all TI K3 SoCs seem to have a standard scheme to
detect the speed grades till date. /me wonders what the heck happened
here..

> 
>  arch/arm64/boot/dts/ti/k3-j721e.dtsi | 35 ++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e.dtsi b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
> index a200810df54a..fe92879f5812 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
> @@ -48,6 +48,9 @@ cpu0: cpu at 0 {
>  			d-cache-line-size = <64>;
>  			d-cache-sets = <256>;
>  			next-level-cache = <&L2_0>;
> +			clocks = <&k3_clks 202 2>;
> +			clock-names = "cpu";
> +			operating-points-v2 = <&cpu0_opp_table>;
>  		};
>  
>  		cpu1: cpu at 1 {
> @@ -62,9 +65,41 @@ cpu1: cpu at 1 {
>  			d-cache-line-size = <64>;
>  			d-cache-sets = <256>;
>  			next-level-cache = <&L2_0>;
> +			clocks = <&k3_clks 203 0>;
> +			clock-names = "cpu";
> +			operating-points-v2 = <&cpu0_opp_table>;
>  		};
>  	};
>  
> +	cpu0_opp_table: opp-table {
> +		compatible = "operating-points-v2";
Don't you need opp-shared ?
> +
> +		opp6-2000000000 {
> +			opp-hz = /bits/ 64 <2000000000>;
> +		};
> +
> +		opp5-1500000000 {
> +			opp-hz = /bits/ 64 <1500000000>;
> +		};
> +
> +		opp4-1000000000 {
> +			opp-hz = /bits/ 64 <1000000000>;
> +		};
> +
> +		opp3-750000000 {
> +			opp-hz = /bits/ 64 <750000000>;
> +		};
> +
> +		opp2-500000000 {
> +			opp-hz = /bits/ 64 <500000000>;
> +		};
> +
> +		opp1-250000000 {
> +			opp-hz = /bits/ 64 <250000000>;
Could you add clock-latency-ns ?
> +		};
> +
> +	};
> +
>  	L2_0: l2-cache0 {
>  		compatible = "cache";
>  		cache-level = <2>;
> -- 
> 2.34.1
> 


-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From robin.murphy at arm.com  Thu Dec 14 05:02:00 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 14 Dec 2023 13:02:00 +0000
Subject: [PATCH] ARM64: Implement arch_report_meminfo()
In-Reply-To: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org>
References: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org>
Message-ID: <b0d7b928-ecc5-4203-8269-423dee08b1ff@arm.com>

On 2023-12-08 9:11 pm, Christoph Lameter (Ampere) wrote:
> X86 has information in /proc/meminfo showing the use of large mappings
> for the kernel direct map. This has now also become important for
> ARM since the kernel default CONFIG_RODATA_FULL_DEFAULT_ENABLED
> forces 4K PTE use for the direct map and users may not be aware
> of the performance impact of the increased TLB use etc.
> 
> The output of /proc/meminfo on ARM64 is then after this patch:
> 
> 4K page size:
> 
> Hugepagesize:?????? 2048 kB
> Hugetlb:?????????????? 0 kB
> DirectMap4k:????? 155912 kB
> CONT DMap4k:??????? 1176 kB
> DirectMap2M:????? 722944 kB
> CONT DMap2M:?????? 28672 kB
> DirectMap1G:?? 534773760 kB
> 
> 64K page size:
> 
> Hugepagesize:???? 524288 kB
> Hugetlb:?????????????? 0 kB
> DirectMap64k:????? 882624 kB
> CONT DMap64k:?????? 19904 kB
> DirectMap512M:??? 534773760 kB
> CONT DMap512M:?????????? 0 kB
> DirectMap4096G:?????????? 0 kB
> 
> Signed-off-by: Christoph Lameter <cl at linux.com>
> 
> Index: linux/arch/arm64/mm/mmu.c
> ===================================================================
> --- linux.orig/arch/arm64/mm/mmu.c
> +++ linux/arch/arm64/mm/mmu.c
> @@ -66,6 +66,12 @@ u32 __boot_cpu_mode[] = { BOOT_CPU_MODE_
>  ? */
>  ?long __section(".mmuoff.data.write") __early_cpu_boot_status;
> 
> +static atomic_t nr_pte;
> +static atomic_t nr_pmd;
> +static atomic_t nr_pud;
> +static atomic_t nr_pte_cont;
> +static atomic_t nr_pmd_cont;
> +
>  ?/*
>  ? * Empty_zero_page is a special page that is used for zero-initialized 
> data
>  ? * and COW.
> @@ -179,6 +185,7 @@ static void init_pte(pmd_t *pmdp, unsign
>  ???????? pte_t old_pte = READ_ONCE(*ptep);
> 
>  ???????? set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
> +??????? atomic_inc(&nr_pte);
> 
>  ???????? /*
>  ????????? * After the PTE entry has been populated once, we
> @@ -223,8 +230,10 @@ static void alloc_init_cont_pte(pmd_t *p
> 
>  ???????? /* use a contiguous mapping if the range is suitably aligned */
>  ???????? if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
> -??????????? (flags & NO_CONT_MAPPINGS) == 0)
> +??????????? (flags & NO_CONT_MAPPINGS) == 0) {
>  ???????????? __prot = __pgprot(pgprot_val(prot) | PTE_CONT);
> +??????????? atomic_inc(&nr_pte_cont);
> +??????? }
> 
>  ???????? init_pte(pmdp, addr, next, phys, __prot);
> 
> @@ -249,6 +258,7 @@ static void init_pmd(pud_t *pudp, unsign
>  ???????? if (((addr | next | phys) & ~PMD_MASK) == 0 &&
>  ???????????? (flags & NO_BLOCK_MAPPINGS) == 0) {
>  ???????????? pmd_set_huge(pmdp, phys, prot);
> +??????????? atomic_inc(&nr_pmd);
> 
>  ???????????? /*
>  ????????????? * After the PMD entry has been populated once, we
> @@ -301,8 +311,10 @@ static void alloc_init_cont_pmd(pud_t *p
> 
>  ???????? /* use a contiguous mapping if the range is suitably aligned */
>  ???????? if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
> -??????????? (flags & NO_CONT_MAPPINGS) == 0)
> +??????????? (flags & NO_CONT_MAPPINGS) == 0) {
>  ???????????? __prot = __pgprot(pgprot_val(prot) | PTE_CONT);
> +??????????? atomic_inc(&nr_pmd_cont);
> +??????? }
> 
>  ???????? init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
> 
> @@ -346,7 +358,7 @@ static void alloc_init_pud(pgd_t *pgdp,
>  ??????????? ((addr | next | phys) & ~PUD_MASK) == 0 &&
>  ???????????? (flags & NO_BLOCK_MAPPINGS) == 0) {
>  ???????????? pud_set_huge(pudp, phys, prot);
> -
> +??????????? atomic_inc(&nr_pud);

It seems somewhat suspect that these counts only ever increase. It's not 
often that we change or remove parts of the linear map, but it certainly 
can happen.

Thanks,
Robin.

>  ???????????? /*
>  ????????????? * After the PUD entry has been populated once, we
>  ????????????? * only allow updates to the permission attributes.
> @@ -1486,3 +1498,35 @@ void ptep_modify_prot_commit(struct vm_a
>  ?{
>  ???? set_pte_at(vma->vm_mm, addr, ptep, pte);
>  ?}
> +
> +#ifdef CONFIG_PROC_FS
> +void arch_report_meminfo(struct seq_file *m)
> +{
> +??? unsigned long pagesize_in_kb = PAGE_SIZE / 1024;
> +
> +??? seq_printf(m, "DirectMap%luk:??? %8lu kB\n",
> +??????????? pagesize_in_kb,
> +????????????? (unsigned long)atomic_read(&nr_pte) * pagesize_in_kb);
> +
> +??????? seq_printf(m, "CONT DMap%luk:??? %8lu kB\n",
> +??????????? pagesize_in_kb,
> +??????????? (unsigned long)atomic_read(&nr_pte_cont) * pagesize_in_kb);
> +
> +??? pagesize_in_kb = PMD_SIZE / 1024;
> +
> +??????? seq_printf(m, "DirectMap%luM:??? %8lu kB\n",
> +??????????? pagesize_in_kb / 1024,
> +??????????? (unsigned long)atomic_read(&nr_pmd) * pagesize_in_kb);
> +
> +??? seq_printf(m, "CONT DMap%luM:??? %8lu kB\n",
> +??????????? pagesize_in_kb / 1024,
> +??????????? (unsigned long)atomic_read(&nr_pmd_cont) * pagesize_in_kb);
> +
> +??? pagesize_in_kb = PUD_SIZE / 1024;
> +
> +??? seq_printf(m, "DirectMap%luG:? %10lu kB\n",
> +?????????????????? pagesize_in_kb >> 20,
> +??????????????????????? (unsigned long)atomic_read(&nr_pud) * 
> pagesize_in_kb);
> +}
> +#endif
> +
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From knaerzche at gmail.com  Thu Dec 14 05:05:31 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 14 Dec 2023 14:05:31 +0100
Subject: [PATCH 07/11] drm/rockchip: inno_hdmi: Add basic mode validation
In-Reply-To: <k7ry5xsrmc5bi46pwbkphq4wo3jd5uutnezvttue2eh7sabkby@wvimbjamzg32>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-8-knaerzche@gmail.com>
 <wz4e43ateg3gb7745mz22wwyruwavevvpfbqsdxeynejcjxhzn@qbqldsnkktei>
 <1b7402b2-ec03-420b-a81b-3e6ea46e402a@gmail.com>
 <k7ry5xsrmc5bi46pwbkphq4wo3jd5uutnezvttue2eh7sabkby@wvimbjamzg32>
Message-ID: <48498e97-1bdd-4a4e-a5a8-5c196a780319@gmail.com>


Am 14.12.23 um 12:40 schrieb Maxime Ripard:
> On Thu, Dec 14, 2023 at 12:17:39PM +0100, Alex Bee wrote:
>> Hi Maxime,
>>
>> Am 14.12.23 um 09:05 schrieb Maxime Ripard:
>>> Hi,
>>>
>>> On Wed, Dec 13, 2023 at 08:51:21PM +0100, Alex Bee wrote:
>>>> As per TRM this controller supports pixelclocks starting from 25 MHz. The
>>>> maximum supported pixelclocks are defined by the phy configurations we
>>>> have. Also it can't support modes that require doubled clocks.
>>>> If there is a phy reference clock we can additionally validate against
>>>> VESA DMT's recommendations.
>>>> Those checks are added to the mode_valid hook of the connector and
>>>> encoder's mode_fixup hook.
>>>>
>>>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>>>> ---
>>>>    drivers/gpu/drm/rockchip/inno_hdmi.c | 38 ++++++++++++++++++++++++++--
>>>>    1 file changed, 36 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>> index f7f0bec725f9..2f839ff31c1c 100644
>>>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>> @@ -38,6 +38,8 @@ struct inno_hdmi_variant {
>>>>    	struct inno_hdmi_phy_config *default_phy_config;
>>>>    };
>>>> +#define INNO_HDMI_MIN_TMDS_CLOCK  25000000U
>>>> +
>>>>    struct hdmi_data_info {
>>>>    	int vic;
>>>>    	bool sink_has_audio;
>>>> @@ -572,6 +574,34 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>>>    	return 0;
>>>>    }
>>>> +static enum drm_mode_status inno_hdmi_mode_valid(struct inno_hdmi *hdmi,
>>>> +						 struct drm_display_mode *mode)
>>>> +{
>>> So, mode_valid is only called to filter out the modes retrieved by
>>> get_modes, but it won't be called when userspace programs a mode. That's
>>> atomic_check's job.
>>>
>>> So you probably want to create a shared function between atomic_check
>>> and mode_valid, and call it from both places (or call mode_valid from
>>> atomic_check).
>> This actually _is_ a shared function called in
>> inno_hdmi_connector_mode_valid and inno_hdmi_encoder_mode_fixup. Yes, I
>> probably should use it in atomic_check _also_.
> Yeah, I saw that later and forgot to rephrase.
>
>>>> +	/* No support for double-clock modes */
>>>> +	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>>>> +		return MODE_BAD;
>>>> +
>>>> +	unsigned int mpixelclk = mode->clock * 1000;
>>> Variables should be declared at the top of the function.
>> Oookay ... can move them.
>>>> +	if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
>>>> +		return MODE_CLOCK_LOW;
>>> You probably want to check the max TMDS clock too?
>> Not sure what you mean here. For the currently supported formats of this
>> driver (rgb only) tmds clock and pixel clock are always the same.
> I mean that your controller has a maximum TMDS rate it supports too
> (probably something like 340MHz). You should also filter out the modes
> that have a pixel clock higher than the one you can reach.
Yes it does have it and it is defined by the phy configurations that do 
exist. The mode is validated against those exactly below this statement. 
(See commit message, btw.)
>
>>>> @@ -602,7 +632,9 @@ static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
>>>>    					 const struct drm_display_mode *mode,
>>>>    					 struct drm_display_mode *adj_mode)
>>>>    {
>>>> -	return true;
>>>> +	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
>>>> +
>>>> +	return inno_hdmi_mode_valid(hdmi, adj_mode) == MODE_OK;
>>>>    }
>>> Why do you call mode_valid in mode_fixup?
>> I'm calling the shared function you asked me to introduce
>> (inno_hdmi_connector_mode_valid != inno_mode_valid)
> That's the mode_fixup part that I'm focused on :)
>
> mode_fixup is the legacy function to adjust the mode to the controller
> capabilities. It's optional, and you're not adjusting anything here,
> just testing the same thing mode_valid did.
>
> mode_valid has been superseeded by atomic_check anyway, so just drop
> mode_valid and use your function in atomic_check like we discussed.

OK.

I just read that mode_fixup won't be called at all if atomic_check 
exists. I will drop here and call in atomic_check only.

Alex

> Maxime


From wsa at kernel.org  Thu Dec 14 05:06:54 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Thu, 14 Dec 2023 14:06:54 +0100
Subject: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c
 compatible
In-Reply-To: <20231214105243.3707730-4-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-4-tudor.ambarus@linaro.org>
Message-ID: <ZXr97owdnLq3viNc@shikoro>

On Thu, Dec 14, 2023 at 10:52:33AM +0000, Tudor Ambarus wrote:
> Add google,gs101-hsi2c dedicated compatible for representing
> I2C of Google GS101 SoC.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>

Acked-by: Wolfram Sang <wsa at kernel.org>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/be76b7c9/attachment.sig>

From festevam at gmail.com  Thu Dec 14 05:15:03 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 14 Dec 2023 10:15:03 -0300
Subject: [EXT] Re: [PATCH 2/4] arm64: dts: imx8ulp-evk: enable usb nodes
In-Reply-To: <VI1PR04MB51523F1EF74EF23B92C6880D8C8CA@VI1PR04MB5152.eurprd04.prod.outlook.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com> <20231214112442.2412079-2-xu.yang_2@nxp.com>
 <CAOMZO5DxcLoBYMXQi=EW=-fAqz12ghPm+7PHn=LdhicETKg2pQ@mail.gmail.com> <VI1PR04MB51523F1EF74EF23B92C6880D8C8CA@VI1PR04MB5152.eurprd04.prod.outlook.com>
Message-ID: <CAOMZO5DxQGjF5rUs6NMR7LCo11tLVPpnPs9nzH7qh2nCCBXoLQ@mail.gmail.com>

On Thu, Dec 14, 2023 at 9:50?AM Xu Yang <xu.yang_2 at nxp.com> wrote:

> PTN5150 can work autonomously for most of the basic functions.
> I don?t see a need to enable driver for it now.

We are talking about devicetree here, not driver.

If the PTN5150 is present on the board, then just represent it in the
devicetree.


From linus.walleij at linaro.org  Thu Dec 14 05:17:51 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 14 Dec 2023 14:17:51 +0100
Subject: [PATCH linux-next] ARM/dma-mapping: replace kzalloc() and
 vzalloc() with kvzalloc()
In-Reply-To: <20231213143954.2541-1-chenguanxi11234@163.com>
References: <CACRpkdap4LUbMcKv_zi=25A-SZf0DJhXiyR1zn0PfuR+b=3NfA@mail.gmail.com>
 <20231213143954.2541-1-chenguanxi11234@163.com>
Message-ID: <CACRpkdb-pARMSCe_kugLOFriSrwuQVXJ3L+6TnsnmDNedowDRw@mail.gmail.com>

On Wed, Dec 13, 2023 at 3:41?PM <chenguanxi11234 at 163.com> wrote:

> >Looks good to me:
> >Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> >Please put this patch into Russell's patch tracker.
>
> Hello, I would like to ask, do you mean to have
> me CC the patch email to Russell?I don't really
> understand what patch tracker means.Thank you.

This is Russell's patch tracker:
https://www.armlinux.org.uk/developer/patches/

Create an account, read the help text, you can submit patches
using a web interface or through mail.

Yours,
Linus Walleij


From krzysztof.kozlowski at linaro.org  Thu Dec 14 05:19:21 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 14:19:21 +0100
Subject: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
In-Reply-To: <1153987b-a818-454a-a292-57f2b3898771@app.fastmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-13-tudor.ambarus@linaro.org>
 <1153987b-a818-454a-a292-57f2b3898771@app.fastmail.com>
Message-ID: <93969025-606c-4e4c-9cbc-3c8351f95adb@linaro.org>

On 14/12/2023 13:08, Arnd Bergmann wrote:
> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>> Sync the defconfig with savedefconfig as config options
>> change/move over time.
>>
>> Generated with the following commands:
>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
>> cp defconfig arch/arm64/configs/defconfig

These are obvious. You cannot do it differently.

>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>> ---
>>  arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
>>  1 file changed, 55 insertions(+), 89 deletions(-)
> 
> I usually ask for defconfig changes to be merged when someone just
> adds a single line per patch, but a 144 line change is clearly too
> big, please split this up.

Anyway this should not go via my tree, because of possible conflicts.
This commit, so the savedefconfig, must be prepared on linux-next, which
should be mentioned in changelog for example. It also is not related to
this patchset.

> 
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index b60aa1f89343..09fb467303ba 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -30,6 +30,8 @@ CONFIG_SCHED_AUTOGROUP=y
>>  CONFIG_BLK_DEV_INITRD=y
>>  CONFIG_KALLSYMS_ALL=y
>>  CONFIG_PROFILING=y
>> +CONFIG_KEXEC_FILE=y
>> +CONFIG_CRASH_DUMP=y
>>  CONFIG_ARCH_ACTIONS=y
>>  CONFIG_ARCH_SUNXI=y
>>  CONFIG_ARCH_ALPINE=y
>> @@ -77,9 +79,6 @@ CONFIG_ARM64_VA_BITS_48=y
>>  CONFIG_SCHED_MC=y
>>  CONFIG_SCHED_SMT=y
>>  CONFIG_NUMA=y
>> -CONFIG_KEXEC=y
>> -CONFIG_KEXEC_FILE=y
>> -CONFIG_CRASH_DUMP=y
>>  CONFIG_XEN=y
>>  CONFIG_COMPAT=y
>>  CONFIG_RANDOMIZE_BASE=y
> 
> These two hunks seem to go together, but it needs an explanation
> why you are removing CONFIG_KEXEC.
> 
>> @@ -119,7 +118,6 @@ CONFIG_KVM=y
>>  CONFIG_JUMP_LABEL=y
>>  CONFIG_MODULES=y
>>  CONFIG_MODULE_UNLOAD=y
>> -CONFIG_IOSCHED_BFQ=y
>>  # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>>  # CONFIG_COMPAT_BRK is not set
>>  CONFIG_MEMORY_HOTPLUG=y
> 
> No, I definitely want CONFIG_IOSCHED_BFQ=y, it is essential
> for performance on certain classes of machines. It would
> be better to drop the 'imply IOSCHED_BFQ' in two Kconfig
> files.
> 
>> @@ -129,8 +127,6 @@ CONFIG_MEMORY_FAILURE=y
>>  CONFIG_TRANSPARENT_HUGEPAGE=y
>>  CONFIG_NET=y
>>  CONFIG_PACKET=y
>> -CONFIG_UNIX=y
>> -CONFIG_INET=y
>>  CONFIG_IP_MULTICAST=y
>>  CONFIG_IP_PNP=y
>>  CONFIG_IP_PNP_DHCP=y
> 
> These also seem kind of essential for almost any machine,
> I assume you are doing something wrong here.

Yep. I think the folks forget the rule not to remove user-selectable
options :/

> 


...

> 
>>  CONFIG_SLIM_QCOM_NGD_CTRL=m
>> -CONFIG_INTERCONNECT=y
>>  CONFIG_INTERCONNECT_IMX=y
>>  CONFIG_INTERCONNECT_IMX8MM=m
>>  CONFIG_INTERCONNECT_IMX8MN=m
> 
> I think the problem here are some Tegra device drivers that
> incorrectly 'select INTERCONNECT' rather than using the
> 'depends on' that every other interconnect driver has.
> Please fix those instead.

In current setup interconnect is user-selectable, so it must not be removed.

Best regards,
Krzysztof



From alexander.stein at ew.tq-group.com  Thu Dec 14 05:20:00 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 14:20:00 +0100
Subject: [PATCH 1/1] arm64: dts: imx8qxp: Add VPU subsystem file
Message-ID: <20231214132000.1927638-1-alexander.stein@ew.tq-group.com>

imx8qxp re-uses imx8qm VPU subsystem file, but it has different base
addresses. Also imx8qxp has only two VPU cores, delete vpu_vore2 and
mu2_m0 accordingly.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 .../boot/dts/freescale/imx8qxp-ss-vpu.dtsi      | 17 +++++++++++++++++
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi      |  2 +-
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi
new file mode 100644
index 0000000000000..7894a3ab26d6b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR X11)
+/*
+ * Copyright 2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+&vpu_core0 {
+	reg = <0x2d040000 0x10000>;
+};
+
+&vpu_core1 {
+	reg = <0x2d050000 0x10000>;
+};
+
+/delete-node/ &mu2_m0;
+/delete-node/ &vpu_core2;
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index f014d0a764ea4..958267b333403 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -48,7 +48,6 @@ aliases {
 		serial3 = &lpuart3;
 		vpu-core0 = &vpu_core0;
 		vpu-core1 = &vpu_core1;
-		vpu-core2 = &vpu_core2;
 	};
 
 	cpus {
@@ -318,6 +317,7 @@ map0 {
 };
 
 #include "imx8qxp-ss-img.dtsi"
+#include "imx8qxp-ss-vpu.dtsi"
 #include "imx8qxp-ss-adma.dtsi"
 #include "imx8qxp-ss-conn.dtsi"
 #include "imx8qxp-ss-lsio.dtsi"
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Thu Dec 14 05:20:15 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 14:20:15 +0100
Subject: [PATCH 13/13] arm64: defconfig: make at24 eeprom builtin
In-Reply-To: <20231214105243.3707730-14-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-14-tudor.ambarus@linaro.org>
Message-ID: <0f67b29c-e7ff-4ce9-96ce-aa552d6d926c@linaro.org>

On 14/12/2023 11:52, Tudor Ambarus wrote:
> gs101-oriole populates an at24 eeprom on the battery connector.
> Make EEPROM_AT24 builtin.

The first sentence does not explain me the second part. The first
sentence justifies having this enabled in general, but not necessarily
as built-in.



Best regards,
Krzysztof



From festevam at gmail.com  Thu Dec 14 05:31:41 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 14 Dec 2023 10:31:41 -0300
Subject: [PATCH 1/1] arm64: dts: imx8qxp: Add VPU subsystem file
In-Reply-To: <20231214132000.1927638-1-alexander.stein@ew.tq-group.com>
References: <20231214132000.1927638-1-alexander.stein@ew.tq-group.com>
Message-ID: <CAOMZO5CW63xA-ZBkAFahp_e_fKKuwzhDy8rMJ2V3Y71udV6YHw@mail.gmail.com>

On Thu, Dec 14, 2023 at 10:20?AM Alexander Stein
<alexander.stein at ew.tq-group.com> wrote:
>
> imx8qxp re-uses imx8qm VPU subsystem file, but it has different base
> addresses. Also imx8qxp has only two VPU cores, delete vpu_vore2 and
> mu2_m0 accordingly.
>
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

Reviewed-by: Fabio Estevam <festevam at gmail.com>


From alexander.stein at ew.tq-group.com  Thu Dec 14 05:35:57 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 14:35:57 +0100
Subject: [PATCH 3/4] arm64: dts: imx93: add usb nodes
In-Reply-To: <20231214112442.2412079-3-xu.yang_2@nxp.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com> <20231214112442.2412079-3-xu.yang_2@nxp.com>
Message-ID: <8309719.T7Z3S40VBb@steina-w>

Hi,

thanks for the patch.

Am Donnerstag, 14. Dezember 2023, 12:24:41 CET schrieb Xu Yang:
> There are 2 USB controllers on i.MX93. Add them.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx93.dtsi | 58 ++++++++++++++++++++++++
>  1 file changed, 58 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi
> b/arch/arm64/boot/dts/freescale/imx93.dtsi index 34c0540276d1..bcf4861cfede
> 100644
> --- a/arch/arm64/boot/dts/freescale/imx93.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
> @@ -171,6 +171,20 @@ cm33: remoteproc-cm33 {
>  		status = "disabled";
>  	};
> 
> +	usbphynop1: usbphynop1 {
> +		#phy-cells = <0>;
> +		compatible = "usb-nop-xceiv";

compatible first.

> +		clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> +		clock-names = "main_clk";
> +	};
> +
> +	usbphynop2: usbphynop2 {
> +		#phy-cells = <0>;
> +		compatible = "usb-nop-xceiv";

compatible first.

> +		clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> +		clock-names = "main_clk";
> +	};
> +
>  	soc at 0 {
>  		compatible = "simple-bus";
>  		#address-cells = <1>;
> @@ -1059,5 +1073,49 @@ ddr-pmu at 4e300dc0 {
>  			reg = <0x4e300dc0 0x200>;
>  			interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
>  		};
> +
> +		usbotg1: usb at 4c100000 {
> +			compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb", 
"fsl,imx27-usb";
> +			reg = <0x4c100000 0x200>;
> +			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> +				 <&clk IMX93_CLK_HSIO_32K_GATE>;
> +			clock-names = "usb_ctrl_root_clk", 
"usb_wakeup_clk";

drivers/usb/chipidea/ci_hdrc_imx.c uses 3 clocks: "ipg", "ahb" and "per", see 
imx_get_clks(). How is this supposed to work?

> +			assigned-clocks = <&clk IMX93_CLK_HSIO>;
> +			assigned-clock-parents = <&clk 
IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> +			assigned-clock-rates = <133000000>;
> +			fsl,usbphy = <&usbphynop1>;
> +			fsl,usbmisc = <&usbmisc1 0>;
> +			status = "disabled";
> +		};
> +
> +		usbmisc1: usbmisc at 4c100200 {
> +			compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-
usbmisc",
> +					"fsl,imx6q-usbmisc";

This means you are compatible to fsl,imx7d-usbmisc. Which means you use 
register MX7D_USB_OTG_PHY_STATUS in USB misc (USBNC). But i.MX93 RM Rev. 2 
(04/2023) lacks this and other registers.

> +			#index-cells = <1>;
> +			reg = <0x4c100200 0x200>;

reg after compatible.

> +		};
> +
> +		usbotg2: usb at 4c200000 {
> +			compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb", 
"fsl,imx27-usb";
> +			reg = <0x4c200000 0x200>;
> +			interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> +				 <&clk IMX93_CLK_HSIO_32K_GATE>;
> +			clock-names = "usb_ctrl_root_clk", 
"usb_wakeup_clk";

The same as for usbotg1 applies here.

> +			assigned-clocks = <&clk IMX93_CLK_HSIO>;
> +			assigned-clock-parents = <&clk 
IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> +			assigned-clock-rates = <133000000>;
> +			fsl,usbphy = <&usbphynop2>;
> +			fsl,usbmisc = <&usbmisc2 0>;
> +			status = "disabled";
> +		};
> +
> +		usbmisc2: usbmisc at 4c200200 {
> +			compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-
usbmisc",
> +					"fsl,imx6q-usbmisc";
> +			#index-cells = <1>;
> +			reg = <0x4c200200 0x200>;

The same as for usbmisc1 applies here.

> +		};
>  	};
>  };

Best regards,
Alexander

-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From broonie at kernel.org  Thu Dec 14 05:37:30 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 14 Dec 2023 13:37:30 +0000
Subject: [PATCH] spi: atmel: Fix clock issue when using devices with
 different polarities
In-Reply-To: <20231204154903.11607-1-louis.chauvet@bootlin.com>
References: <20231204154903.11607-1-louis.chauvet@bootlin.com>
Message-ID: <170256105093.58838.9858114740206767634.b4-ty@kernel.org>

On Mon, 04 Dec 2023 16:49:03 +0100, Louis Chauvet wrote:
> The current Atmel SPI controller driver (v2) behaves incorrectly when
> using two SPI devices with different clock polarities and GPIO CS.
> 
> When switching from one device to another, the controller driver first
> enables the CS and then applies whatever configuration suits the targeted
> device (typically, the polarities). The side effect of such order is the
> apparition of a spurious clock edge after enabling the CS when the clock
> polarity needs to be inverted wrt. the previous configuration of the
> controller.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: atmel: Fix clock issue when using devices with different polarities
      commit: fc70d643a2f6678cbe0f5c86433c1aeb4d613fcc

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From alexander.stein at ew.tq-group.com  Thu Dec 14 05:40:01 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 14:40:01 +0100
Subject: [PATCH 4/4] arm64: dts: imx93-11x11-evk: enable usb and typec nodes
In-Reply-To: <20231214112442.2412079-4-xu.yang_2@nxp.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com> <20231214112442.2412079-4-xu.yang_2@nxp.com>
Message-ID: <1952554.PYKUYFuaPT@steina-w>

Hi,

thanks for the patch.

Am Donnerstag, 14. Dezember 2023, 12:24:42 CET schrieb Xu Yang:
> There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> ---
>  .../boot/dts/freescale/imx93-11x11-evk.dts    | 108 ++++++++++++++++++
>  1 file changed, 108 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts index
> 2b9d47716f75..42b1ea7d5220 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> @@ -5,6 +5,7 @@
> 
>  /dts-v1/;
> 
> +#include <dt-bindings/usb/pd.h>
>  #include "imx93.dtsi"
> 
>  / {
> @@ -103,6 +104,70 @@ &mu2 {
>  	status = "okay";
>  };
> 
> +&lpi2c3 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default", "sleep";
> +	pinctrl-0 = <&pinctrl_lpi2c3>;
> +	pinctrl-1 = <&pinctrl_lpi2c3>;
> +	status = "okay";
> +
> +	ptn5110: tcpc at 50 {

I do not know if there is already some consent, but personally I do not like 
tcpc for the node name. Maybe change that to usb-typec at 50.

> +		compatible = "nxp,ptn5110";
> +		reg = <0x50>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> +		status = "okay";

status not needed here, "okay" is default and node is added here.

> +
> +		port {
> +			typec1_dr_sw: endpoint {
> +				remote-endpoint = <&usb1_drd_sw>;
> +			};
> +		};
> +
> +		typec1_con: connector {
> +			compatible = "usb-c-connector";
> +			label = "USB-C";
> +			power-role = "dual";
> +			data-role = "dual";
> +			try-power-role = "sink";
> +			source-pdos = <PDO_FIXED(5000, 3000, 
PDO_FIXED_USB_COMM)>;
> +			sink-pdos = <PDO_FIXED(5000, 3000, 
PDO_FIXED_USB_COMM)
> +				     PDO_VAR(5000, 20000, 3000)>;
> +			op-sink-microwatt = <15000000>;
> +			self-powered;
> +		};
> +	};
> +
> +	ptn5110_2: tcpc at 51 {

See above.

> +		compatible = "nxp,ptn5110";
> +		reg = <0x51>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> +		status = "okay";

See above.

Best regards,
Alexander

> +
> +		port {
> +			typec2_dr_sw: endpoint {
> +				remote-endpoint = <&usb2_drd_sw>;
> +			};
> +		};
> +
> +		typec2_con: connector {
> +			compatible = "usb-c-connector";
> +			label = "USB-C";
> +			power-role = "dual";
> +			data-role = "dual";
> +			try-power-role = "sink";
> +			source-pdos = <PDO_FIXED(5000, 3000, 
PDO_FIXED_USB_COMM)>;
> +			sink-pdos = <PDO_FIXED(5000, 3000, 
PDO_FIXED_USB_COMM)
> +				     PDO_VAR(5000, 20000, 3000)>;
> +			op-sink-microwatt = <15000000>;
> +			self-powered;
> +		};
> +	};
> +};
> +
>  &eqos {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_eqos>;
> @@ -155,6 +220,42 @@ &lpuart5 {
>  	status = "okay";
>  };
> 
> +&usbotg1 {
> +	dr_mode = "otg";
> +	hnp-disable;
> +	srp-disable;
> +	adp-disable;
> +	usb-role-switch;
> +	disable-over-current;
> +	samsung,picophy-pre-emp-curr-control = <3>;
> +	samsung,picophy-dc-vol-level-adjust = <7>;
> +	status = "okay";
> +
> +	port {
> +		usb1_drd_sw: endpoint {
> +			remote-endpoint = <&typec1_dr_sw>;
> +		};
> +	};
> +};
> +
> +&usbotg2 {
> +	dr_mode = "otg";
> +	hnp-disable;
> +	srp-disable;
> +	adp-disable;
> +	usb-role-switch;
> +	disable-over-current;
> +	samsung,picophy-pre-emp-curr-control = <3>;
> +	samsung,picophy-dc-vol-level-adjust = <7>;
> +	status = "okay";
> +
> +	port {
> +		usb2_drd_sw: endpoint {
> +			remote-endpoint = <&typec2_dr_sw>;
> +		};
> +	};
> +};
> +
>  &usdhc1 {
>  	pinctrl-names = "default", "state_100mhz", "state_200mhz";
>  	pinctrl-0 = <&pinctrl_usdhc1>;
> @@ -221,6 +322,13 @@ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL	0x57e
> 
>  		>;
> 
>  	};
> 
> +	pinctrl_lpi2c3: lpi2c3grp {
> +		fsl,pins = <
> +			MX93_PAD_GPIO_IO28__LPI2C3_SDA			
0x40000b9e
> +			MX93_PAD_GPIO_IO29__LPI2C3_SCL			
0x40000b9e
> +		>;
> +	};
> +
>  	pinctrl_uart1: uart1grp {
>  		fsl,pins = <
>  			MX93_PAD_UART1_RXD__LPUART1_RX			
0x31e


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From alexander.stein at ew.tq-group.com  Thu Dec 14 05:42:59 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 14:42:59 +0100
Subject: [PATCH 1/1] arm64: dts: freescale: imx8qxp: Disable dsp reserved memory by default
Message-ID: <20231214134259.1933541-1-alexander.stein@ew.tq-group.com>

Even if the 'dsp' node is disabled the memory intended to be used by the
DSP is reserved. This limits the memory range suitable for CMA allocation.
Thus disable the dsp_reserved node. DSP users need to enable it in parallel
to the 'dsp' node.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
Apparently imx8qxp-mek is the only in-kernel user, so it is enabled
again to preserve current state.

 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 ++++
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi    | 1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 6c3d8715bc11e..7888570c15e19 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -50,6 +50,10 @@ &dsp {
 	status = "okay";
 };
 
+&dsp_reserved {
+	status = "okay";
+};
+
 &fec1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_fec1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index c80c85a4b4059..f014d0a764ea4 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -184,6 +184,7 @@ decoder_rpc: decoder-rpc at 92000000 {
 		dsp_reserved: dsp at 92400000 {
 			reg = <0 0x92400000 0 0x2000000>;
 			no-map;
+			status = "disabled";
 		};
 
 		encoder_rpc: encoder-rpc at 94400000 {
-- 
2.34.1



From eauger at redhat.com  Thu Dec 14 05:45:56 2023
From: eauger at redhat.com (Eric Auger)
Date: Thu, 14 Dec 2023 14:45:56 +0100
Subject: [PATCH v2 4/5] KVM: selftests: aarch64: Introduce
 pmu_event_filter_test
In-Reply-To: <20231129072712.2667337-5-shahuang@redhat.com>
References: <20231129072712.2667337-1-shahuang@redhat.com>
 <20231129072712.2667337-5-shahuang@redhat.com>
Message-ID: <72c68db7-3de0-4517-9410-fd19d4564fea@redhat.com>

Hi Shaoqin,

On 11/29/23 08:27, Shaoqin Huang wrote:
> Introduce pmu_event_filter_test for arm64 platforms. The test configures
> PMUv3 for a vCPU, and sets different pmu event filters for the vCPU, and
> check if the guest can use those events which user allow and can't use
> those events which use deny.
> 
> This test refactor the create_vpmu_vm() and make it a wrapper for
> __create_vpmu_vm(), which allows some extra init code before
> KVM_ARM_VCPU_PMU_V3_INIT.
> 
> And this test use the KVM_ARM_VCPU_PMU_V3_FILTER attribute to set the
> pmu event filter in KVM. And choose to filter two common event
> branches_retired and instructions_retired, and let guest use the two
> events in pmu. And check if the result is expected.
> 
> Signed-off-by: Shaoqin Huang <shahuang at redhat.com>
> ---
>  tools/testing/selftests/kvm/Makefile          |   1 +
>  .../kvm/aarch64/pmu_event_filter_test.c       | 231 ++++++++++++++++++
>  .../selftests/kvm/include/aarch64/vpmu.h      |   4 +
>  .../testing/selftests/kvm/lib/aarch64/vpmu.c  |  14 +-
>  4 files changed, 248 insertions(+), 2 deletions(-)
>  create mode 100644 tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
> 
> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> index b60852c222ac..5f126e1a1dbf 100644
> --- a/tools/testing/selftests/kvm/Makefile
> +++ b/tools/testing/selftests/kvm/Makefile
> @@ -155,6 +155,7 @@ TEST_GEN_PROGS_aarch64 += aarch64/arch_timer
>  TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions
>  TEST_GEN_PROGS_aarch64 += aarch64/hypercalls
>  TEST_GEN_PROGS_aarch64 += aarch64/page_fault_test
> +TEST_GEN_PROGS_aarch64 += aarch64/pmu_event_filter_test
>  TEST_GEN_PROGS_aarch64 += aarch64/psci_test
>  TEST_GEN_PROGS_aarch64 += aarch64/set_id_regs
>  TEST_GEN_PROGS_aarch64 += aarch64/smccc_filter
> diff --git a/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c b/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
> new file mode 100644
> index 000000000000..0e652fbdb37a
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
> @@ -0,0 +1,231 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * pmu_event_filter_test - Test user limit pmu event for guest.
> + *
> + * Copyright (c) 2023 Red Hat, Inc.
> + *
> + * This test checks if the guest only see the limited pmu event that userspace
> + * sets, if the guest can use those events which user allow, and if the guest
> + * can't use those events which user deny.
> + * This test runs only when KVM_CAP_ARM_PMU_V3, KVM_ARM_VCPU_PMU_V3_FILTER
> + * is supported on the host.
> + */
> +#include <kvm_util.h>
> +#include <processor.h>
> +#include <vgic.h>
> +#include <vpmu.h>
> +#include <test_util.h>
> +#include <perf/arm_pmuv3.h>
> +
> +struct {
> +	uint64_t branches_retired;
> +	uint64_t instructions_retired;
> +} pmc_results;
> +
> +static struct vpmu_vm *vpmu_vm;
> +static uint64_t pmceid0;
> +
> +#define FILTER_NR 10
> +
> +struct test_desc {
> +	const char *name;
> +	void (*check_result)(void);
> +	struct kvm_pmu_event_filter filter[FILTER_NR];
> +};
> +> +#define __DEFINE_FILTER(base, num, act)		\
> +	((struct kvm_pmu_event_filter) {	\
> +		.base_event	= base,		\
> +		.nevents	= num,		\
> +		.action		= act,		\
> +	})
> +
> +#define DEFINE_FILTER(base, act) __DEFINE_FILTER(base, 1, act)
> +
> +#define EMPTY_FILTER	{ 0 }
> +
> +#define SW_INCR		0x0
> +#define INST_RETIRED	0x8
> +#define BR_RETIRED	0x21
> +
> +#define NUM_BRANCHES	10
> +
> +static void run_and_measure_loop(void)
> +{
> +	asm volatile(
> +		"	mov	x10, %[loop]\n"
> +		"1:	sub	x10, x10, #1\n"
> +		"	cmp	x10, #0x0\n"
> +		"	b.gt	1b\n"
> +		:
> +		: [loop] "r" (NUM_BRANCHES)
> +		: "x10", "cc");
> +}
> +
> +static void guest_code(void)
> +{
> +	uint64_t pmcr = read_sysreg(pmcr_el0);
> +
> +	pmu_disable_reset();
> +
> +	write_pmevtypern(0, BR_RETIRED);
> +	write_pmevtypern(1, INST_RETIRED);
> +	enable_counter(0);
> +	enable_counter(1);
> +	write_sysreg(pmcr | ARMV8_PMU_PMCR_E, pmcr_el0);
> +
> +	run_and_measure_loop();
> +
> +	write_sysreg(pmcr, pmcr_el0);
> +
> +	pmc_results.branches_retired = read_sysreg(pmevcntr0_el0);
> +	pmc_results.instructions_retired = read_sysreg(pmevcntr1_el0);
> +
> +	GUEST_DONE();
> +}
> +
> +static void guest_get_pmceid0(void)
> +{
> +	uint64_t pmceid0 = read_sysreg(pmceid0_el0);
> +
> +	GUEST_PRINTF("%lx\n", pmceid0);
> +
> +	GUEST_DONE();
> +}
> +
> +static void pmu_event_filter_init(struct vpmu_vm *vm, void *arg)
> +{
> +	struct kvm_device_attr attr = {
> +		.group	= KVM_ARM_VCPU_PMU_V3_CTRL,
> +		.attr	= KVM_ARM_VCPU_PMU_V3_FILTER,
> +	};
> +	struct kvm_pmu_event_filter *filter = (struct kvm_pmu_event_filter *)arg;
> +
> +	while (filter && filter->nevents != 0) {
> +		attr.addr = (uint64_t)filter;
> +		vcpu_ioctl(vm->vcpu, KVM_SET_DEVICE_ATTR, &attr);
> +		filter++;
> +	}
> +}
> +
> +static void create_vpmu_vm_with_filter(void *guest_code,
> +				       struct kvm_pmu_event_filter *filter)
> +{
> +	vpmu_vm = __create_vpmu_vm(guest_code, pmu_event_filter_init, filter);
> +}
> +
> +static void run_vcpu(struct kvm_vcpu *vcpu)
> +{
> +	struct ucall uc;
> +
> +	while (1) {
> +		vcpu_run(vcpu);
> +		switch (get_ucall(vcpu, &uc)) {
> +		case UCALL_DONE:
> +			return;
> +		case UCALL_PRINTF:
> +			pmceid0 = strtoll(uc.buffer, NULL, 16);
> +			break;
> +		default:
> +			TEST_FAIL("Unknown ucall %lu", uc.cmd);
> +		}
> +	}
> +}
> +
> +static void check_pmc_counting(void)
> +{
> +	uint64_t br = pmc_results.branches_retired;
> +	uint64_t ir = pmc_results.instructions_retired;
> +
> +	TEST_ASSERT(br && br == NUM_BRANCHES, "Branch instructions retired = "
> +		    "%lu (expected %u)", br, NUM_BRANCHES);
have you tested on several machines? My experience with some events
(MEM_ACCESS for instance) is that you have variance (sometimes
significant) on some event count. I am a little bit scared that having
this br == NUM_BRANCHES check without taking into account some margin
will cause failures on some HW.

in v1 I suggested to read to PMCEID* in a guest code to check if the
event is supported. This method would also have the benefice to allow
testing more complex filter range combinations.
> +	TEST_ASSERT(ir, "Instructions retired = %lu (expected > 0)", ir);
> +}
> +
> +static void check_pmc_not_counting(void)
> +{
> +	uint64_t br = pmc_results.branches_retired;
> +	uint64_t ir = pmc_results.instructions_retired;
> +
> +	TEST_ASSERT(!br, "Branch instructions retired = %lu (expected 0)", br);
> +	TEST_ASSERT(!ir, "Instructions retired = %lu (expected 0)", ir);
> +}
> +
> +static void run_vcpu_and_sync_pmc_results(void)
> +{
> +	memset(&pmc_results, 0, sizeof(pmc_results));
> +	sync_global_to_guest(vpmu_vm->vm, pmc_results);
> +
> +	run_vcpu(vpmu_vm->vcpu);
> +
> +	sync_global_from_guest(vpmu_vm->vm, pmc_results);
> +}
> +
> +static void run_test(struct test_desc *t)
> +{
> +	pr_debug("Test: %s\n", t->name);
> +
> +	create_vpmu_vm_with_filter(guest_code, t->filter);
> +
> +	run_vcpu_and_sync_pmc_results();
> +
> +	t->check_result();
> +
> +	destroy_vpmu_vm(vpmu_vm);
> +}
> +
> +static struct test_desc tests[] = {
> +	{"without_filter", check_pmc_counting, { EMPTY_FILTER }},
> +	{"member_allow_filter", check_pmc_counting,
> +	 {DEFINE_FILTER(SW_INCR, 0), DEFINE_FILTER(INST_RETIRED, 0),
Note the doc says that Event 0 (SW_INCR) is never filtered, as it
doesn't count a hardware event


I would use the defines exposed in the uapi
> +#define KVM_PMU_EVENT_ALLOW	0
> +#define KVM_PMU_EVENT_DENY	1
> +	  DEFINE_FILTER(BR_RETIRED, 0), EMPTY_FILTER}},
> +	{"member_deny_filter", check_pmc_not_counting,
> +	 {DEFINE_FILTER(SW_INCR, 1), DEFINE_FILTER(INST_RETIRED, 1),
what is the purpose of SW_INCR. YOu do not seem to test it anyway?
> +	  DEFINE_FILTER(BR_RETIRED, 1), EMPTY_FILTER}},
> +	{"not_member_deny_filter", check_pmc_counting,
> +	 {DEFINE_FILTER(SW_INCR, 1), EMPTY_FILTER}},
> +	{"not_member_allow_filter", check_pmc_not_counting,
> +	 {DEFINE_FILTER(SW_INCR, 0), EMPTY_FILTER}},
> +	{ 0 }
> +};
> +
> +static void for_each_test(void)
> +{
> +	struct test_desc *t;
> +
> +	for (t = &tests[0]; t->name; t++)
> +		run_test(t);
> +}
> +
> +static bool kvm_supports_pmu_event_filter(void)
> +{
> +	int r;
> +
> +	vpmu_vm = create_vpmu_vm(guest_code);
> +
> +	r = __kvm_has_device_attr(vpmu_vm->vcpu->fd, KVM_ARM_VCPU_PMU_V3_CTRL,
> +				  KVM_ARM_VCPU_PMU_V3_FILTER);
you can use __vcpu_has_device_attr directly
> +
> +	destroy_vpmu_vm(vpmu_vm);
> +	return !r;
> +}
> +
> +static bool host_pmu_supports_events(void)
> +{
> +	vpmu_vm = create_vpmu_vm(guest_get_pmceid0);
> +
> +	run_vcpu(vpmu_vm->vcpu);
> +
> +	destroy_vpmu_vm(vpmu_vm);
> +
> +	return pmceid0 & (BR_RETIRED | INST_RETIRED);
this will return true if either event is supported. I suspect this is
not what you want.
> +}
> +
> +int main(void)
> +{
> +	TEST_REQUIRE(kvm_has_cap(KVM_CAP_ARM_PMU_V3));
> +	TEST_REQUIRE(kvm_supports_pmu_event_filter());
> +	TEST_REQUIRE(host_pmu_supports_events());
> +
> +	for_each_test();
> +}
> diff --git a/tools/testing/selftests/kvm/include/aarch64/vpmu.h b/tools/testing/selftests/kvm/include/aarch64/vpmu.h
> index 644dae3814b5..f103d0824f8a 100644
> --- a/tools/testing/selftests/kvm/include/aarch64/vpmu.h
> +++ b/tools/testing/selftests/kvm/include/aarch64/vpmu.h
> @@ -18,6 +18,10 @@ struct vpmu_vm {
>  	int gic_fd;
>  };
>  
> +struct vpmu_vm *__create_vpmu_vm(void *guest_code,
> +				 void (*init_pmu)(struct vpmu_vm *vm, void *arg),
> +				 void *arg);
> +
>  struct vpmu_vm *create_vpmu_vm(void *guest_code);
>  
>  void destroy_vpmu_vm(struct vpmu_vm *vpmu_vm);
> diff --git a/tools/testing/selftests/kvm/lib/aarch64/vpmu.c b/tools/testing/selftests/kvm/lib/aarch64/vpmu.c
> index b3de8fdc555e..76ea03d607f1 100644
> --- a/tools/testing/selftests/kvm/lib/aarch64/vpmu.c
> +++ b/tools/testing/selftests/kvm/lib/aarch64/vpmu.c
> @@ -7,8 +7,9 @@
>  #include <vpmu.h>
>  #include <perf/arm_pmuv3.h>
>  
> -/* Create a VM that has one vCPU with PMUv3 configured. */
> -struct vpmu_vm *create_vpmu_vm(void *guest_code)
> +struct vpmu_vm *__create_vpmu_vm(void *guest_code,
> +				 void (*init_pmu)(struct vpmu_vm *vm, void *arg),
> +				 void *arg)
>  {
>  	struct kvm_vcpu_init init;
>  	uint8_t pmuver;
> @@ -50,12 +51,21 @@ struct vpmu_vm *create_vpmu_vm(void *guest_code)
>  		    "Unexpected PMUVER (0x%x) on the vCPU with PMUv3", pmuver);
>  
>  	/* Initialize vPMU */
> +	if (init_pmu)
> +		init_pmu(vpmu_vm, arg);
> +
>  	vcpu_ioctl(vpmu_vm->vcpu, KVM_SET_DEVICE_ATTR, &irq_attr);
>  	vcpu_ioctl(vpmu_vm->vcpu, KVM_SET_DEVICE_ATTR, &init_attr);
>  
>  	return vpmu_vm;
>  }
>  
> +/* Create a VM that has one vCPU with PMUv3 configured. */
> +struct vpmu_vm *create_vpmu_vm(void *guest_code)
> +{
> +	return __create_vpmu_vm(guest_code, NULL, NULL);
> +}
> +
>  void destroy_vpmu_vm(struct vpmu_vm *vpmu_vm)
>  {
>  	close(vpmu_vm->gic_fd);

Thanks

Eric



From conor at kernel.org  Thu Dec 14 05:47:14 2023
From: conor at kernel.org (Conor Dooley)
Date: Thu, 14 Dec 2023 13:47:14 +0000
Subject: [PATCH 1/5] riscv: dts: allwinner: Update opp table to allow CPU
 frequency scaling
In-Reply-To: <20231214111446.camz2krqanaieybh@vireshk-i7>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
 <20231214103342.30775-2-fusibrandon13@gmail.com>
 <20231214111446.camz2krqanaieybh@vireshk-i7>
Message-ID: <20231214-junkyard-corset-d35b01bad69f@spud>

On Thu, Dec 14, 2023 at 04:44:46PM +0530, Viresh Kumar wrote:
> On 14-12-23, 11:33, Brandon Cheo Fusi wrote:
> > Two OPPs are currently defined for the D1/D1s; one at 408MHz and
> > another at 1.08GHz. Switching between these can be done with the
> > "sun50i-cpufreq-nvmem" driver. This patch populates the opp table
> > appropriately, with inspiration from
> > https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi
> > 
> > The supply voltages are PWM-controlled, but support for that IP
> > is still in the works. So stick to a fixed 0.9V vdd-cpu supply,
> > which seems to be the default on most D1 boards.
> > 
> > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > ---
> >  arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 18 +++++++++++++++---
> >  1 file changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > index 64c3c2e6c..e211fe4c7 100644
> > --- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > @@ -39,16 +39,22 @@ cpu0_intc: interrupt-controller {
> >  	};
> >  
> >  	opp_table_cpu: opp-table-cpu {
> > -		compatible = "operating-points-v2";
> > +		compatible = "allwinner,sun20i-d1-operating-points",
> 
> I don't think you should add a new compatible for every SoC that needs
> to be supported by a DT bindings and cpufreq driver. Maybe you should
> just reuse "allwinner,sun50i-h6-operating-points" and it will work
> fine for you ?
> 
> Rob ?

The driver can definitely just reuse sun50i-h6, but the binding and
devicetree should have a soc-specific compatible for the sun20i-d1.

That said, the compatible does need to be documented, there's a
dt-bindings patch missing from this series.

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/055caabc/attachment.sig>

From joey.gouly at arm.com  Thu Dec 14 05:47:39 2023
From: joey.gouly at arm.com (Joey Gouly)
Date: Thu, 14 Dec 2023 13:47:39 +0000
Subject: [PATCH v3 14/25] arm64: implement PKEYS support
In-Reply-To: <ZXdZwRcc0BaEq-Uv@arm.com>
References: <20231124163510.1835740-1-joey.gouly@arm.com>
 <20231124163510.1835740-15-joey.gouly@arm.com>
 <ZXdZwRcc0BaEq-Uv@arm.com>
Message-ID: <20231214134739.GB1234025@e124191.cambridge.arm.com>

On Mon, Dec 11, 2023 at 06:49:37PM +0000, Catalin Marinas wrote:
> On Fri, Nov 24, 2023 at 04:34:59PM +0000, Joey Gouly wrote:
> > @@ -211,11 +212,24 @@ init_new_context(struct task_struct *tsk, struct mm_struct *mm)
> >  {
> >  	atomic64_set(&mm->context.id, 0);
> >  	refcount_set(&mm->context.pinned, 0);
> > +
> > +	// pkey 0 is the default, so always reserve it.
> > +	mm->context.pkey_allocation_map = 0x1;
> 
> Nit: use /* */ style comments.
> 
> > @@ -151,7 +170,9 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
> >   * PTE_VALID bit set.
> >   */
> >  #define pte_access_permitted(pte, write) \
> > -	(((pte_val(pte) & (PTE_VALID | PTE_USER)) == (PTE_VALID | PTE_USER)) && (!(write) || pte_write(pte)))
> > +	(((pte_val(pte) & (PTE_VALID | PTE_USER)) == (PTE_VALID | PTE_USER)) && \
> > +	 (!(write) || pte_write(pte)) && \
> > +	 por_el0_allows_pkey(FIELD_GET(PTE_PO_IDX_MASK, pte_val(pte)), write, false))
> 
> Do not change pte_access_permitted(), just let it handle the base
> permissions. This check is about the mm tables, not some current POR_EL0
> setting of the thread.
> 
> As an example, with this change Linux may decide not to clear the MTE
> tags just because the current POR_EL0 says no-access. The thread
> subsequently changes POR_EL0 and it can read the stale tags.
> 
> I haven't checked what x86 and powerpc do here. There may be some
> implications on GUP but I'd rather ignore POE for this case.

There are tests in tools/testing/selftests/mm/protection_keys.c
test_kernel_gup_of_access_disabled_region etc, that explicitly check GUP is
affected by pkeys. So if we didn't modify pte_access_permitted() it would fail
the test and work differently than the other architectures.  For
MTE/__sync_cache_and_tags, I think could add a pte_access_permitted_no_poe().

> 
> >  #define pmd_access_permitted(pmd, write) \
> >  	(pte_access_permitted(pmd_pte(pmd), (write)))
> >  #define pud_access_permitted(pud, write) \
> > diff --git a/arch/arm64/include/asm/pkeys.h b/arch/arm64/include/asm/pkeys.h
> > index 5761fb48fd53..a80c654da93d 100644
> > --- a/arch/arm64/include/asm/pkeys.h
> > +++ b/arch/arm64/include/asm/pkeys.h
> [...]
> >  static inline int execute_only_pkey(struct mm_struct *mm)
> >  {
> > +	// Execute-only mappings are handled by EPAN/FEAT_PAN3.
> > +	WARN_ON_ONCE(!cpus_have_final_cap(ARM64_HAS_EPAN));
> > +
> >  	return -1;
> >  }
> 
> Why the WARN_ON_ONCE() here? It will trigger if the user asks for
> PROT_EXEC and I can't see any subsequent patch that changes the core
> code not to call it. I think we need some arch_has_execute_only_pkey()
> to avoid going on this path. Our arch would support exec-only with any
> pkey.

This would warn if you somehow had a CPU with FEAT_POE but not FEAT_PAN3. So I
don't really need the WARN() here, if the CPU supports FEAT_POE it should also
support FEAT_PAN3. Arm v8.7 made FEAT_PAN3 mandatory. 

> 
> > @@ -1490,6 +1491,38 @@ void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr, pte
> >  #ifdef CONFIG_ARCH_HAS_PKEYS
> >  int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, unsigned long init_val)
> >  {
> > -	return -ENOSPC;
> > +	u64 new_por = POE_RXW;
> > +	u64 old_por;
> > +	u64 pkey_shift;
> > +
> > +	if (!arch_pkeys_enabled())
> > +		return -ENOSPC;
> > +
> > +	/*
> > +	 * This code should only be called with valid 'pkey'
> > +	 * values originating from in-kernel users.  Complain
> > +	 * if a bad value is observed.
> > +	 */
> > +	if (WARN_ON_ONCE(pkey >= arch_max_pkey()))
> > +		return -EINVAL;
> > +
> > +	/* Set the bits we need in POR:  */
> > +	if (init_val & PKEY_DISABLE_ACCESS)
> > +		new_por = POE_X;
> 
> Does PKEY_DISABLE_ACCESS mean allow execute? Or does x86 not have a way
> to disable execution?

As I understand it X86 can either disable Read and Write or disable Write. No
way to disable execution.

The man page says:
        PKEY_DISABLE_ACCESS
              Disable all data access to memory covered by the returned
              protection key.

> 
> > +	else if (init_val & PKEY_DISABLE_WRITE)
> > +		new_por = POE_RX;
> > +
> > +	/* Shift the bits in to the correct place in POR for pkey: */
> > +	pkey_shift = pkey * POR_BITS_PER_PKEY;
> > +	new_por <<= pkey_shift;
> > +
> > +	/* Get old POR and mask off any old bits in place: */
> > +	old_por = read_sysreg_s(SYS_POR_EL0);
> > +	old_por &= ~(POE_MASK << pkey_shift);
> > +
> > +	/* Write old part along with new part: */
> > +	write_sysreg_s(old_por | new_por, SYS_POR_EL0);
> > +
> > +	return 0;
> >  }
> >  #endif

Thanks,
Joey


From acme at kernel.org  Thu Dec 14 05:49:14 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Thu, 14 Dec 2023 10:49:14 -0300
Subject: [PATCH v1 00/14] Clean up libperf cpumap's empty function
In-Reply-To: <84755553-3a79-4693-9396-084e9ae41235@intel.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <ZXifiVytVbebYE3U@kernel.org>
 <84755553-3a79-4693-9396-084e9ae41235@intel.com>
Message-ID: <ZXsH2rragIC7YmCS@kernel.org>

Em Wed, Dec 13, 2023 at 02:48:15PM +0200, Adrian Hunter escreveu:
> On 12/12/23 19:59, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Nov 28, 2023 at 10:01:57PM -0800, Ian Rogers escreveu:
> >> Rename and clean up the use of libperf CPU map functions particularly
> >> focussing on perf_cpu_map__empty that may return true for maps
> >> containing CPUs but also with an "any CPU"/dummy value.
> >>
> >> perf_cpu_map__nr is also troubling in that iterating an empty CPU map
> >> will yield the "any CPU"/dummy value. Reduce the appearance of some
> >> calls to this by using the perf_cpu_map__for_each_cpu macro.
> >>
> >> Ian Rogers (14):
> >>   libperf cpumap: Rename perf_cpu_map__dummy_new
> >>   libperf cpumap: Rename and prefer sysfs for perf_cpu_map__default_new
> >>   libperf cpumap: Rename perf_cpu_map__empty
> >>   libperf cpumap: Replace usage of perf_cpu_map__new(NULL)
> >>   libperf cpumap: Add for_each_cpu that skips the "any CPU" case
> > 
> > Applied 1-6, with James Reviewed-by tags, would be good to have Adrian
> > check the PT and BTS parts, testing the end result if he things its all
> > ok.

Ian,

	1-6 is in perf-tools-next now, can you please consider Adrian's
suggestion to reduce patch size and rebase the remaining patches?

- Arnaldo
 
> Changing the same lines of code twice in the same patch set is not
> really kernel style.
> 
> Some of the churn could be reduced by applying and rebasing on the
> patch below.
> 
> Ideally the patches should be reordered so that the lines only
> change once i.e.
> 
> 	perf_cpu_map__empty -> <replacement>
> 
> instead of
> 
> 	perf_cpu_map__empty -> <rename> -> <replacement>
> 
> If that is too much trouble, please accept my ack instead:
> 
> Acked-by: Adrian Hunter <adrian.hunter at intel.com>


 
> 
> From: Adrian Hunter <adrian.hunter at intel.com>
> 
> Factor out perf_cpu_map__empty() use to reduce the occurrences and make
> the code more readable.
> 
> Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
> ---
>  tools/perf/arch/x86/util/intel-bts.c | 11 ++++++++---
>  tools/perf/arch/x86/util/intel-pt.c  | 21 ++++++++++++---------
>  2 files changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/perf/arch/x86/util/intel-bts.c b/tools/perf/arch/x86/util/intel-bts.c
> index d2c8cac11470..cebe994eb9db 100644
> --- a/tools/perf/arch/x86/util/intel-bts.c
> +++ b/tools/perf/arch/x86/util/intel-bts.c
> @@ -59,6 +59,11 @@ intel_bts_info_priv_size(struct auxtrace_record *itr __maybe_unused,
>  	return INTEL_BTS_AUXTRACE_PRIV_SIZE;
>  }
>  
> +static bool intel_bts_per_cpu(struct evlist *evlist)
> +{
> +	return !perf_cpu_map__empty(evlist->core.user_requested_cpus);
> +}
> +
>  static int intel_bts_info_fill(struct auxtrace_record *itr,
>  			       struct perf_session *session,
>  			       struct perf_record_auxtrace_info *auxtrace_info,
> @@ -109,8 +114,8 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
>  	struct intel_bts_recording *btsr =
>  			container_of(itr, struct intel_bts_recording, itr);
>  	struct perf_pmu *intel_bts_pmu = btsr->intel_bts_pmu;
> +	bool per_cpu_mmaps = intel_bts_per_cpu(evlist);
>  	struct evsel *evsel, *intel_bts_evsel = NULL;
> -	const struct perf_cpu_map *cpus = evlist->core.user_requested_cpus;
>  	bool privileged = perf_event_paranoid_check(-1);
>  
>  	if (opts->auxtrace_sample_mode) {
> @@ -143,7 +148,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
>  	if (!opts->full_auxtrace)
>  		return 0;
>  
> -	if (opts->full_auxtrace && !perf_cpu_map__empty(cpus)) {
> +	if (opts->full_auxtrace && per_cpu_mmaps) {
>  		pr_err(INTEL_BTS_PMU_NAME " does not support per-cpu recording\n");
>  		return -EINVAL;
>  	}
> @@ -224,7 +229,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
>  		 * In the case of per-cpu mmaps, we need the CPU on the
>  		 * AUX event.
>  		 */
> -		if (!perf_cpu_map__empty(cpus))
> +		if (per_cpu_mmaps)
>  			evsel__set_sample_bit(intel_bts_evsel, CPU);
>  	}
>  
> diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c
> index fa0c718b9e72..0ff9147c75da 100644
> --- a/tools/perf/arch/x86/util/intel-pt.c
> +++ b/tools/perf/arch/x86/util/intel-pt.c
> @@ -312,6 +312,11 @@ static void intel_pt_tsc_ctc_ratio(u32 *n, u32 *d)
>  	*d = eax;
>  }
>  
> +static bool intel_pt_per_cpu(struct evlist *evlist)
> +{
> +	return !perf_cpu_map__empty(evlist->core.user_requested_cpus);
> +}
> +
>  static int intel_pt_info_fill(struct auxtrace_record *itr,
>  			      struct perf_session *session,
>  			      struct perf_record_auxtrace_info *auxtrace_info,
> @@ -322,7 +327,8 @@ static int intel_pt_info_fill(struct auxtrace_record *itr,
>  	struct perf_pmu *intel_pt_pmu = ptr->intel_pt_pmu;
>  	struct perf_event_mmap_page *pc;
>  	struct perf_tsc_conversion tc = { .time_mult = 0, };
> -	bool cap_user_time_zero = false, per_cpu_mmaps;
> +	bool per_cpu_mmaps = intel_pt_per_cpu(session->evlist);
> +	bool cap_user_time_zero = false;
>  	u64 tsc_bit, mtc_bit, mtc_freq_bits, cyc_bit, noretcomp_bit;
>  	u32 tsc_ctc_ratio_n, tsc_ctc_ratio_d;
>  	unsigned long max_non_turbo_ratio;
> @@ -369,8 +375,6 @@ static int intel_pt_info_fill(struct auxtrace_record *itr,
>  			ui__warning("Intel Processor Trace: TSC not available\n");
>  	}
>  
> -	per_cpu_mmaps = !perf_cpu_map__empty(session->evlist->core.user_requested_cpus);
> -
>  	auxtrace_info->type = PERF_AUXTRACE_INTEL_PT;
>  	auxtrace_info->priv[INTEL_PT_PMU_TYPE] = intel_pt_pmu->type;
>  	auxtrace_info->priv[INTEL_PT_TIME_SHIFT] = tc.time_shift;
> @@ -604,8 +608,8 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
>  	struct perf_pmu *intel_pt_pmu = ptr->intel_pt_pmu;
>  	bool have_timing_info, need_immediate = false;
>  	struct evsel *evsel, *intel_pt_evsel = NULL;
> -	const struct perf_cpu_map *cpus = evlist->core.user_requested_cpus;
>  	bool privileged = perf_event_paranoid_check(-1);
> +	bool per_cpu_mmaps = intel_pt_per_cpu(evlist);
>  	u64 tsc_bit;
>  	int err;
>  
> @@ -774,8 +778,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
>  	 * Per-cpu recording needs sched_switch events to distinguish different
>  	 * threads.
>  	 */
> -	if (have_timing_info && !perf_cpu_map__empty(cpus) &&
> -	    !record_opts__no_switch_events(opts)) {
> +	if (have_timing_info && per_cpu_mmaps && !record_opts__no_switch_events(opts)) {
>  		if (perf_can_record_switch_events()) {
>  			bool cpu_wide = !target__none(&opts->target) &&
>  					!target__has_task(&opts->target);
> @@ -832,7 +835,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
>  		 * In the case of per-cpu mmaps, we need the CPU on the
>  		 * AUX event.
>  		 */
> -		if (!perf_cpu_map__empty(cpus))
> +		if (per_cpu_mmaps)
>  			evsel__set_sample_bit(intel_pt_evsel, CPU);
>  	}
>  
> @@ -858,7 +861,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
>  			tracking_evsel->immediate = true;
>  
>  		/* In per-cpu case, always need the time of mmap events etc */
> -		if (!perf_cpu_map__empty(cpus)) {
> +		if (per_cpu_mmaps) {
>  			evsel__set_sample_bit(tracking_evsel, TIME);
>  			/* And the CPU for switch events */
>  			evsel__set_sample_bit(tracking_evsel, CPU);
> @@ -870,7 +873,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
>  	 * Warn the user when we do not have enough information to decode i.e.
>  	 * per-cpu with no sched_switch (except workload-only).
>  	 */
> -	if (!ptr->have_sched_switch && !perf_cpu_map__empty(cpus) &&
> +	if (!ptr->have_sched_switch && per_cpu_mmaps &&
>  	    !target__none(&opts->target) &&
>  	    !intel_pt_evsel->core.attr.exclude_user)
>  		ui__warning("Intel Processor Trace decoding will not be possible except for kernel tracing!\n");
> -- 
> 2.34.1
> 
> 
> 

-- 

- Arnaldo


From s-vadapalli at ti.com  Thu Dec 14 05:50:32 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Thu, 14 Dec 2023 19:20:32 +0530
Subject: [PATCH v2] arm64: dts: ti: k3-am654-icssg2: Enable PHY interrupts
 for ICSSG2
In-Reply-To: <20231214121727.ayrbqz2nmeb25rpw@striving>
References: <20231213080216.1710730-1-s-vadapalli@ti.com>
 <20231213123819.tqh3lm2ceir3qjbk@swimmer>
 <6f1c1a59-cec0-46d1-8ecb-a82d9d444ccf@ti.com>
 <20231214121727.ayrbqz2nmeb25rpw@striving>
Message-ID: <0cef8f50-6608-cf3d-ad62-1afd3f5560ea@ti.com>



On 14-12-2023 17:47, Nishanth Menon wrote:

...

>>
>> Yes, you are right! Edge-Triggered interrupts shouldn't be shared. I missed
>> noticing this. Thank you for pointing it out. Since the SoC only supports
>> Edge-Triggered interrupts, I believe that the correct decision would be to use
>> the interrupt for only one of the two PHYs, while leaving the other PHY in
>> polled mode of operation which is the default.
>>
>> Kindly let me know if this is acceptable and I shall update this patch accordingly.
> 
> Sounds like a bug in board design there (due to an choice of IP
> limitation) - I suggest getting it noted in board documentation and
> refer to the errata in the second phy (else folks will wonder why we
> aren't using interrupts on the second phy.

Thank you for your suggestion on the next steps to be taken. I will
ensure that the board documentation is updated. Additionally, in the v3
patch I will add a comment within the "icssg2_phy0" node indicating that
the interrupt mode of operation is only being enabled for "icssg2_phy0"
due to the interrupt being an edge-triggered interrupt which cannot be
shared among both the PHYs. And for that reason "icssg2_phy1" is being
left in the default polled mode of operation.

-- 
Regards,
Siddharth.


From tudor.ambarus at linaro.org  Thu Dec 14 05:52:35 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 13:52:35 +0000
Subject: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
In-Reply-To: <1938fcf1-eb5d-4723-a6c6-d2fe2c6dd1c0@app.fastmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-6-tudor.ambarus@linaro.org>
 <1938fcf1-eb5d-4723-a6c6-d2fe2c6dd1c0@app.fastmail.com>
Message-ID: <8808ceeb-35dc-4094-aec4-f43c7acd6174@linaro.org>



On 12/14/23 12:01, Arnd Bergmann wrote:

Hi, Arnd,

Thanks for the review!

> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>> +					    const char *opt)
>> +{
>> +	/* gs101 always expects MMIO32 register accesses. */
>> +	device->port.iotype = UPIO_MEM32;
>> +
>> +	return s5pv210_early_console_setup(device, opt);
>> +}
>> +
>> +OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);
> 
> It looks like this is already done by of_setup_earlycon() based on
> the reg-io-width property. Any idea why it doesn't work with the
> normal s5pv210_early_console_setup() function?
> 

It works if in device tree one specifies the reg-io-width property and
sets it to 4. If the reg-io-width is not specified, the iotype defaults
to UPIO_MEM causing the SError interrupt on gs101 which makes the system
unusable.

Also, if the earlycon comes specified from the kernel params, the
of_setup_earlycon() is no longer called and the earlycon will be set
solely based on the kernel params buffer, thus allowing users to crash
the kernel on wrong earlycon definitions.

If you think the change is fine, I can amend the commit message with the
description from above.

Cheers,
ta


From eauger at redhat.com  Thu Dec 14 05:52:49 2023
From: eauger at redhat.com (Eric Auger)
Date: Thu, 14 Dec 2023 14:52:49 +0100
Subject: [PATCH v2 5/5] KVM: selftests: aarch64: Add invalid filter test
 in pmu_event_filter_test
In-Reply-To: <20231129072712.2667337-6-shahuang@redhat.com>
References: <20231129072712.2667337-1-shahuang@redhat.com>
 <20231129072712.2667337-6-shahuang@redhat.com>
Message-ID: <7b1c4163-31e8-490e-9f19-3abceeeb2d7d@redhat.com>

Hi Shaoqin

On 11/29/23 08:27, Shaoqin Huang wrote:
> Add the invalid filter test to double check if the KVM_ARM_VCPU_PMU_V3_FILTER
> will return the expected error.
... in which situations? filter beyond the 16b event space or incorrect
action.
> 
> Signed-off-by: Shaoqin Huang <shahuang at redhat.com>
> ---
>  .../kvm/aarch64/pmu_event_filter_test.c       | 36 +++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c b/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
> index 0e652fbdb37a..4c375417b194 100644
> --- a/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
> +++ b/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
> @@ -7,6 +7,7 @@
>   * This test checks if the guest only see the limited pmu event that userspace
>   * sets, if the guest can use those events which user allow, and if the guest
>   * can't use those events which user deny.
> + * It also checks that setting invalid filter ranges return the expected error.
>   * This test runs only when KVM_CAP_ARM_PMU_V3, KVM_ARM_VCPU_PMU_V3_FILTER
>   * is supported on the host.
>   */
> @@ -197,6 +198,39 @@ static void for_each_test(void)
>  		run_test(t);
>  }
>  
> +static void set_invalid_filter(struct vpmu_vm *vm, void *arg)
> +{
> +	struct kvm_pmu_event_filter invalid;
> +	struct kvm_device_attr attr = {
> +		.group	= KVM_ARM_VCPU_PMU_V3_CTRL,
> +		.attr	= KVM_ARM_VCPU_PMU_V3_FILTER,
> +		.addr	= (uint64_t)&invalid,
> +	};
> +	int ret = 0;
> +
> +	/* The max event number is (1 << 16), set a range large than it. */
larger
> +	invalid = __DEFINE_FILTER(BIT(15), BIT(15)+1, 0);
doc says
must fit within the event space defined by the PMU
architecture (10 bits on ARMv8.0, 16 bits from ARMv8.1 onwards).

> +	ret = __vcpu_ioctl(vm->vcpu, KVM_SET_DEVICE_ATTR, &attr);
> +	TEST_ASSERT(ret && errno == EINVAL, "Set Invalid filter range "
> +		    "ret = %d, errno = %d (expected ret = -1, errno = EINVAL)",
> +		    ret, errno);
> +
> +	ret = 0;
> +
> +	/* Set the Invalid action. */
> +	invalid = __DEFINE_FILTER(0, 1, 3);
> +	ret = __vcpu_ioctl(vm->vcpu, KVM_SET_DEVICE_ATTR, &attr);
> +	TEST_ASSERT(ret && errno == EINVAL, "Set Invalid filter action "
> +		    "ret = %d, errno = %d (expected ret = -1, errno = EINVAL)",
> +		    ret, errno);
> +}
> +
> +static void test_invalid_filter(void)
> +{
> +	vpmu_vm = __create_vpmu_vm(guest_code, set_invalid_filter, NULL);
> +	destroy_vpmu_vm(vpmu_vm);
> +}
> +
>  static bool kvm_supports_pmu_event_filter(void)
>  {
>  	int r;
> @@ -228,4 +262,6 @@ int main(void)
>  	TEST_REQUIRE(host_pmu_supports_events());
>  
>  	for_each_test();
> +
> +	test_invalid_filter();
>  }

Eric



From eauger at redhat.com  Thu Dec 14 05:55:24 2023
From: eauger at redhat.com (Eric Auger)
Date: Thu, 14 Dec 2023 14:55:24 +0100
Subject: [PATCH v2 4/5] KVM: selftests: aarch64: Introduce
 pmu_event_filter_test
In-Reply-To: <20231129072712.2667337-5-shahuang@redhat.com>
References: <20231129072712.2667337-1-shahuang@redhat.com>
 <20231129072712.2667337-5-shahuang@redhat.com>
Message-ID: <a34f3596-f4be-4085-8729-3772e2e44343@redhat.com>

Hi Shaoqin,

On 11/29/23 08:27, Shaoqin Huang wrote:
> Introduce pmu_event_filter_test for arm64 platforms. The test configures
> PMUv3 for a vCPU, and sets different pmu event filters for the vCPU, and
> check if the guest can use those events which user allow and can't use
> those events which use deny.
> 
> This test refactor the create_vpmu_vm() and make it a wrapper for
> __create_vpmu_vm(), which allows some extra init code before
> KVM_ARM_VCPU_PMU_V3_INIT.
> 
> And this test use the KVM_ARM_VCPU_PMU_V3_FILTER attribute to set the
> pmu event filter in KVM. And choose to filter two common event
> branches_retired and instructions_retired, and let guest use the two
> events in pmu. And check if the result is expected.
> 
> Signed-off-by: Shaoqin Huang <shahuang at redhat.com>
> ---
>  tools/testing/selftests/kvm/Makefile          |   1 +
>  .../kvm/aarch64/pmu_event_filter_test.c       | 231 ++++++++++++++++++
>  .../selftests/kvm/include/aarch64/vpmu.h      |   4 +
>  .../testing/selftests/kvm/lib/aarch64/vpmu.c  |  14 +-
>  4 files changed, 248 insertions(+), 2 deletions(-)
>  create mode 100644 tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
> 
> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> index b60852c222ac..5f126e1a1dbf 100644
> --- a/tools/testing/selftests/kvm/Makefile
> +++ b/tools/testing/selftests/kvm/Makefile
> @@ -155,6 +155,7 @@ TEST_GEN_PROGS_aarch64 += aarch64/arch_timer
>  TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions
>  TEST_GEN_PROGS_aarch64 += aarch64/hypercalls
>  TEST_GEN_PROGS_aarch64 += aarch64/page_fault_test
> +TEST_GEN_PROGS_aarch64 += aarch64/pmu_event_filter_test
>  TEST_GEN_PROGS_aarch64 += aarch64/psci_test
>  TEST_GEN_PROGS_aarch64 += aarch64/set_id_regs
>  TEST_GEN_PROGS_aarch64 += aarch64/smccc_filter
> diff --git a/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c b/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
> new file mode 100644
> index 000000000000..0e652fbdb37a
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
> @@ -0,0 +1,231 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * pmu_event_filter_test - Test user limit pmu event for guest.
> + *
> + * Copyright (c) 2023 Red Hat, Inc.
> + *
> + * This test checks if the guest only see the limited pmu event that userspace
> + * sets, if the guest can use those events which user allow, and if the guest
> + * can't use those events which user deny.
> + * This test runs only when KVM_CAP_ARM_PMU_V3, KVM_ARM_VCPU_PMU_V3_FILTER
> + * is supported on the host.
> + */
> +#include <kvm_util.h>
> +#include <processor.h>
> +#include <vgic.h>
> +#include <vpmu.h>
> +#include <test_util.h>
> +#include <perf/arm_pmuv3.h>
> +
> +struct {
> +	uint64_t branches_retired;
> +	uint64_t instructions_retired;
> +} pmc_results;
> +
> +static struct vpmu_vm *vpmu_vm;
> +static uint64_t pmceid0;
> +
> +#define FILTER_NR 10
> +
> +struct test_desc {
> +	const char *name;
> +	void (*check_result)(void);
> +	struct kvm_pmu_event_filter filter[FILTER_NR];
> +};
> +
> +#define __DEFINE_FILTER(base, num, act)		\
> +	((struct kvm_pmu_event_filter) {	\
> +		.base_event	= base,		\
> +		.nevents	= num,		\
> +		.action		= act,		\
> +	})
> +
> +#define DEFINE_FILTER(base, act) __DEFINE_FILTER(base, 1, act)
> +
> +#define EMPTY_FILTER	{ 0 }
> +
> +#define SW_INCR		0x0
> +#define INST_RETIRED	0x8
> +#define BR_RETIRED	0x21
> +
> +#define NUM_BRANCHES	10
> +
> +static void run_and_measure_loop(void)
> +{
> +	asm volatile(
> +		"	mov	x10, %[loop]\n"
> +		"1:	sub	x10, x10, #1\n"
> +		"	cmp	x10, #0x0\n"
> +		"	b.gt	1b\n"
> +		:
> +		: [loop] "r" (NUM_BRANCHES)
> +		: "x10", "cc");
> +}
> +
> +static void guest_code(void)
> +{
> +	uint64_t pmcr = read_sysreg(pmcr_el0);
> +
> +	pmu_disable_reset();
> +
> +	write_pmevtypern(0, BR_RETIRED);
> +	write_pmevtypern(1, INST_RETIRED);
> +	enable_counter(0);
> +	enable_counter(1);
> +	write_sysreg(pmcr | ARMV8_PMU_PMCR_E, pmcr_el0);
> +
> +	run_and_measure_loop();
> +
> +	write_sysreg(pmcr, pmcr_el0);
> +
> +	pmc_results.branches_retired = read_sysreg(pmevcntr0_el0);
> +	pmc_results.instructions_retired = read_sysreg(pmevcntr1_el0);
> +
> +	GUEST_DONE();
> +}
> +
> +static void guest_get_pmceid0(void)
> +{
> +	uint64_t pmceid0 = read_sysreg(pmceid0_el0);
> +
> +	GUEST_PRINTF("%lx\n", pmceid0);
> +
> +	GUEST_DONE();
> +}
> +
> +static void pmu_event_filter_init(struct vpmu_vm *vm, void *arg)
> +{
> +	struct kvm_device_attr attr = {
> +		.group	= KVM_ARM_VCPU_PMU_V3_CTRL,
> +		.attr	= KVM_ARM_VCPU_PMU_V3_FILTER,
> +	};
> +	struct kvm_pmu_event_filter *filter = (struct kvm_pmu_event_filter *)arg;
> +
> +	while (filter && filter->nevents != 0) {
> +		attr.addr = (uint64_t)filter;
> +		vcpu_ioctl(vm->vcpu, KVM_SET_DEVICE_ATTR, &attr);
> +		filter++;
> +	}
> +}
> +
> +static void create_vpmu_vm_with_filter(void *guest_code,
> +				       struct kvm_pmu_event_filter *filter)
> +{
> +	vpmu_vm = __create_vpmu_vm(guest_code, pmu_event_filter_init, filter);
> +}
> +
> +static void run_vcpu(struct kvm_vcpu *vcpu)
> +{
> +	struct ucall uc;
> +
> +	while (1) {
> +		vcpu_run(vcpu);
> +		switch (get_ucall(vcpu, &uc)) {
> +		case UCALL_DONE:
> +			return;
> +		case UCALL_PRINTF:
> +			pmceid0 = strtoll(uc.buffer, NULL, 16);
> +			break;
> +		default:
> +			TEST_FAIL("Unknown ucall %lu", uc.cmd);
> +		}
> +	}
> +}
> +
> +static void check_pmc_counting(void)
> +{
> +	uint64_t br = pmc_results.branches_retired;
> +	uint64_t ir = pmc_results.instructions_retired;
> +
> +	TEST_ASSERT(br && br == NUM_BRANCHES, "Branch instructions retired = "
> +		    "%lu (expected %u)", br, NUM_BRANCHES);
> +	TEST_ASSERT(ir, "Instructions retired = %lu (expected > 0)", ir);
> +}
> +
> +static void check_pmc_not_counting(void)
> +{
> +	uint64_t br = pmc_results.branches_retired;
> +	uint64_t ir = pmc_results.instructions_retired;
> +
> +	TEST_ASSERT(!br, "Branch instructions retired = %lu (expected 0)", br);
> +	TEST_ASSERT(!ir, "Instructions retired = %lu (expected 0)", ir);
> +}
> +
> +static void run_vcpu_and_sync_pmc_results(void)
> +{
> +	memset(&pmc_results, 0, sizeof(pmc_results));
> +	sync_global_to_guest(vpmu_vm->vm, pmc_results);
> +
> +	run_vcpu(vpmu_vm->vcpu);
> +
> +	sync_global_from_guest(vpmu_vm->vm, pmc_results);
> +}
> +
> +static void run_test(struct test_desc *t)
> +{
> +	pr_debug("Test: %s\n", t->name);
> +
> +	create_vpmu_vm_with_filter(guest_code, t->filter);
> +
> +	run_vcpu_and_sync_pmc_results();
> +
> +	t->check_result();
> +
> +	destroy_vpmu_vm(vpmu_vm);
> +}
> +
> +static struct test_desc tests[] = {
> +	{"without_filter", check_pmc_counting, { EMPTY_FILTER }},
> +	{"member_allow_filter", check_pmc_counting,
> +	 {DEFINE_FILTER(SW_INCR, 0), DEFINE_FILTER(INST_RETIRED, 0),
> +	  DEFINE_FILTER(BR_RETIRED, 0), EMPTY_FILTER}},
> +	{"member_deny_filter", check_pmc_not_counting,
> +	 {DEFINE_FILTER(SW_INCR, 1), DEFINE_FILTER(INST_RETIRED, 1),
> +	  DEFINE_FILTER(BR_RETIRED, 1), EMPTY_FILTER}},
> +	{"not_member_deny_filter", check_pmc_counting,
> +	 {DEFINE_FILTER(SW_INCR, 1), EMPTY_FILTER}},
> +	{"not_member_allow_filter", check_pmc_not_counting,
> +	 {DEFINE_FILTER(SW_INCR, 0), EMPTY_FILTER}},
> +	{ 0 }
> +};
> +
> +static void for_each_test(void)
> +{
> +	struct test_desc *t;
> +
> +	for (t = &tests[0]; t->name; t++)
> +		run_test(t);
> +}
> +
> +static bool kvm_supports_pmu_event_filter(void)
> +{
> +	int r;
> +
> +	vpmu_vm = create_vpmu_vm(guest_code);
> +
> +	r = __kvm_has_device_attr(vpmu_vm->vcpu->fd, KVM_ARM_VCPU_PMU_V3_CTRL,
> +				  KVM_ARM_VCPU_PMU_V3_FILTER);
> +
> +	destroy_vpmu_vm(vpmu_vm);
> +	return !r;
> +}
> +
> +static bool host_pmu_supports_events(void)
> +{
> +	vpmu_vm = create_vpmu_vm(guest_get_pmceid0);
> +
> +	run_vcpu(vpmu_vm->vcpu);
> +
> +	destroy_vpmu_vm(vpmu_vm);
> +
> +	return pmceid0 & (BR_RETIRED | INST_RETIRED);
> +}
> +
> +int main(void)
> +{
> +	TEST_REQUIRE(kvm_has_cap(KVM_CAP_ARM_PMU_V3));
> +	TEST_REQUIRE(kvm_supports_pmu_event_filter());
> +	TEST_REQUIRE(host_pmu_supports_events());
> +
> +	for_each_test();
> +}
> diff --git a/tools/testing/selftests/kvm/include/aarch64/vpmu.h b/tools/testing/selftests/kvm/include/aarch64/vpmu.h
> index 644dae3814b5..f103d0824f8a 100644
> --- a/tools/testing/selftests/kvm/include/aarch64/vpmu.h
> +++ b/tools/testing/selftests/kvm/include/aarch64/vpmu.h
> @@ -18,6 +18,10 @@ struct vpmu_vm {
>  	int gic_fd;
>  };
>  
> +struct vpmu_vm *__create_vpmu_vm(void *guest_code,
> +				 void (*init_pmu)(struct vpmu_vm *vm, void *arg),
> +				 void *arg);
> +
>  struct vpmu_vm *create_vpmu_vm(void *guest_code);
>  
>  void destroy_vpmu_vm(struct vpmu_vm *vpmu_vm);
> diff --git a/tools/testing/selftests/kvm/lib/aarch64/vpmu.c b/tools/testing/selftests/kvm/lib/aarch64/vpmu.c
> index b3de8fdc555e..76ea03d607f1 100644
> --- a/tools/testing/selftests/kvm/lib/aarch64/vpmu.c
> +++ b/tools/testing/selftests/kvm/lib/aarch64/vpmu.c
> @@ -7,8 +7,9 @@
>  #include <vpmu.h>
>  #include <perf/arm_pmuv3.h>
>  
> -/* Create a VM that has one vCPU with PMUv3 configured. */
> -struct vpmu_vm *create_vpmu_vm(void *guest_code)
> +struct vpmu_vm *__create_vpmu_vm(void *guest_code,
> +				 void (*init_pmu)(struct vpmu_vm *vm, void *arg),
> +				 void *arg)
>  {
>  	struct kvm_vcpu_init init;
>  	uint8_t pmuver;
> @@ -50,12 +51,21 @@ struct vpmu_vm *create_vpmu_vm(void *guest_code)
>  		    "Unexpected PMUVER (0x%x) on the vCPU with PMUv3", pmuver);
>  
>  	/* Initialize vPMU */
> +	if (init_pmu)
> +		init_pmu(vpmu_vm, arg);
> +
>  	vcpu_ioctl(vpmu_vm->vcpu, KVM_SET_DEVICE_ATTR, &irq_attr);
>  	vcpu_ioctl(vpmu_vm->vcpu, KVM_SET_DEVICE_ATTR, &init_attr);
>  
>  	return vpmu_vm;
>  }
>  
> +/* Create a VM that has one vCPU with PMUv3 configured. */
> +struct vpmu_vm *create_vpmu_vm(void *guest_code)
> +{
> +	return __create_vpmu_vm(guest_code, NULL, NULL);
> +}
> +
>  void destroy_vpmu_vm(struct vpmu_vm *vpmu_vm)
>  {
>  	close(vpmu_vm->gic_fd);
While reading the doc again I can see there would be other interesting
scenari to test such as

"Note: "Cancelling" a filter by registering the opposite action for the same
range doesn't change the default action. For example, installing an ALLOW
filter for event range [0:10) as the first filter and then applying a DENY
action for the same range will leave the whole range as disabled."

also filter ranges. Using PMCEID* would simplify your life I think.

However this is more work and maybe goes beyond your original intent. Up
to you ...

Eric




From knaerzche at gmail.com  Thu Dec 14 06:05:59 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 14 Dec 2023 15:05:59 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <db3kdzy4ogf3o2fd6apr36s44qitcsxksfkfa2oc77s5y6dv2w@kfji4iszthxa>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-5-knaerzche@gmail.com>
 <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
 <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com>
 <db3kdzy4ogf3o2fd6apr36s44qitcsxksfkfa2oc77s5y6dv2w@kfji4iszthxa>
Message-ID: <a8f13e19-7bb3-4a7f-a264-1e1ede1864e0@gmail.com>


Am 14.12.23 um 12:33 schrieb Maxime Ripard:
> On Thu, Dec 14, 2023 at 12:12:08PM +0100, Alex Bee wrote:
>> Hi Maxime
>>
>> Am 14.12.23 um 08:56 schrieb Maxime Ripard:
>>> Hi Alex,
>>>
>>> Thanks for working on this!
>>>
>>> On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
>>>> The display controller will always give full range RGB regardless of the
>>>> mode set, but HDMI requires certain modes to be transmitted in limited
>>>> range RGB. This is especially required for HDMI sinks which do not support
>>>> non-standard quantization ranges.
>>>>
>>>> This enables color space conversion for those modes and sets the
>>>> quantization range accordingly in the AVI infoframe.
>>>>
>>>> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
>>>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>>>> ---
>>>>    drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
>>>>    1 file changed, 32 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>> index 345253e033c5..32626a75723c 100644
>>>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>> @@ -33,6 +33,7 @@ struct hdmi_data_info {
>>>>    	unsigned int enc_in_format;
>>>>    	unsigned int enc_out_format;
>>>>    	unsigned int colorimetry;
>>>> +	bool rgb_limited_range;
>>>>    };
>>>>    struct inno_hdmi_i2c {
>>>> @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
>>>>    	else
>>>>    		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>>>> +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
>>>> +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
>>>> +						   &hdmi->connector, mode,
>>>> +						   hdmi->hdmi_data.rgb_limited_range ?
>>>> +						   HDMI_QUANTIZATION_RANGE_LIMITED :
>>>> +						   HDMI_QUANTIZATION_RANGE_FULL);
>>>> +	} else {
>>>> +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
>>>> +		frame.avi.ycc_quantization_range =
>>>> +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
>>>> +	}
>>>> +
>>>>    	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
>>>>    }
>>>> @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
>>>>    	if (data->enc_in_format == data->enc_out_format) {
>>>>    		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
>>>>    		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
>>>> -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>>>> -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>>>> -
>>>> -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>>>> -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>>>> -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>>>> -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>>>> -			return 0;
>>>> +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
>>>> +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
>>>> +			    hdmi->hdmi_data.rgb_limited_range) {
>>>> +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
>>>> +				auto_csc = AUTO_CSC_DISABLE;
>>>> +				c0_c2_change = C0_C2_CHANGE_DISABLE;
>>>> +				csc_enable = v_CSC_ENABLE;
>>>> +			} else {
>>>> +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>>>> +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>>>> +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>>>> +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>>>> +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>>>> +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>>>> +				return 0;
>>>> +			}
>>>>    		}
>>>>    	}
>>>> @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>>>    	else
>>>>    		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
>>>> +	hdmi->hdmi_data.rgb_limited_range =
>>>> +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
>>>> +
>>> This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
>>> https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/
>> I'm aware of that and I mentioned it in the cover letter.
> Sorry, I missed that part.
>
>> Your series is not merged yet and it didn't get much feedback so far.
>> What is the status there?
> It didn't have much reviews, but I'll hope to change that. For the
> patches 22 to 38 though, it doesn't really matter. Those changes are
> self-contained and can be applied as is outside of the series.
>
>> Especially because you are removing things from inno-hdmi driver (which
>> aren't really required to remove there) which will I have to reintroduce.
> I'm not entirely sure which part I remove that are actually going to be
> used here.
I'm refering to [PATCH v5 33/44] which completly removes csc coeffs but 
this series needs the CSC_RGB_0_255_TO_RGB_16_235_8BIT? coeffs and? 
[PATCH v5 29/44] which removes writing csc_coeffs to the hardware.
>
>>> I would appreciate if you could test and merge them into your series.
>>>
>>> In particular, there's no need to store the range here: enc_out_format
>> rgb_limited_range is currently not only used for csc, but also for for
>> infoframe creation. So it makes sense to have this stored? to avoid calling
>> drm_default_rgb_quant_range twice.
> You're right, I missed one. Still, it shouldn't be stored in the
> hdmi_data_info structure, it's tied to the mode, and the mode is part of
> the state, so it's not a property to a given device, but it's tied to
> the connector state.
>
> So if you want to do so, you should really create a custom state
> structure and store the range there, just like vc4 is doing for example.

OK - I'll check.

Alex

>
> Maxime


From tudor.ambarus at linaro.org  Thu Dec 14 06:09:38 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 14:09:38 +0000
Subject: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
In-Reply-To: <93969025-606c-4e4c-9cbc-3c8351f95adb@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-13-tudor.ambarus@linaro.org>
 <1153987b-a818-454a-a292-57f2b3898771@app.fastmail.com>
 <93969025-606c-4e4c-9cbc-3c8351f95adb@linaro.org>
Message-ID: <64e35ae0-a751-40ee-b27f-8034e7817222@linaro.org>



On 12/14/23 13:19, Krzysztof Kozlowski wrote:
> On 14/12/2023 13:08, Arnd Bergmann wrote:

Hi, Arnd, Krzysztof,

Thanks for the review!

>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>> Sync the defconfig with savedefconfig as config options
>>> change/move over time.
>>>
>>> Generated with the following commands:
>>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
>>> cp defconfig arch/arm64/configs/defconfig
> These are obvious. You cannot do it differently.

This was just a prerequisite patch for the next, where I made a config
builtin. Modifying defconfig shall be made in a similar manner, but it
seems it's not the case (144 line change here), and that's why I
considered it is worth specifying how I did it.

> 
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>>> ---
>>>  arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
>>>  1 file changed, 55 insertions(+), 89 deletions(-)
>> I usually ask for defconfig changes to be merged when someone just
>> adds a single line per patch, but a 144 line change is clearly too
>> big, please split this up.

The truth is I didn't think we care what configs get removed after a
savedefconfig. I see now after Arnd's review that we have a higher goal
and savedefconfig shall be used to identify misconfiguration.

> Anyway this should not go via my tree, because of possible conflicts.
> This commit, so the savedefconfig, must be prepared on linux-next, which
> should be mentioned in changelog for example. It also is not related to
> this patchset.

Please ignore this patch. Cheers,
ta


From arnd at arndb.de  Thu Dec 14 06:19:44 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 14 Dec 2023 14:19:44 +0000
Subject: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
In-Reply-To: <8808ceeb-35dc-4094-aec4-f43c7acd6174@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-6-tudor.ambarus@linaro.org>
 <1938fcf1-eb5d-4723-a6c6-d2fe2c6dd1c0@app.fastmail.com>
 <8808ceeb-35dc-4094-aec4-f43c7acd6174@linaro.org>
Message-ID: <6962ac73-2f44-4c9e-8731-152087815454@app.fastmail.com>

On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
> On 12/14/23 12:01, Arnd Bergmann wrote:
>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>> 
>
> It works if in device tree one specifies the reg-io-width property and
> sets it to 4. If the reg-io-width is not specified, the iotype defaults
> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
> unusable.

In the case of incorrect DT data like a missing reg-io-width property,
I would expect it to still fail once the regular console or tty takes
over from earlycon.

> Also, if the earlycon comes specified from the kernel params, the
> of_setup_earlycon() is no longer called and the earlycon will be set
> solely based on the kernel params buffer, thus allowing users to crash
> the kernel on wrong earlycon definitions.

But that in turn is the same as specifying any other incorrect earlycon.

> If you think the change is fine, I can amend the commit message with the
> description from above.

I'm still not convinced we need a special case here when everything else
just requires passing the correct data.

     Arnd


From alexander.stein at ew.tq-group.com  Thu Dec 14 06:23:23 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 15:23:23 +0100
Subject: [PATCH v2 0/4] TQMa8Xx (i.MX8QXP/i.MX8DXP) support
Message-ID: <20231214142327.1962914-1-alexander.stein@ew.tq-group.com>

Hi,

this series adds initial support for the TQ TQMa8Xx series, namely
TQMa8XQP (imx8qxp based) and TQMa8XDP (imx8dxp based).
The device tree is split into generic mba8xx.dtsi and tqma8xx.dtsi which
can be used for both imx8qxp and imx8dxp based hardware.

Changes in v2:
* Rebased to next-20231214
* Add imx8dxp support patch
* Collected Marco's and Conor's R-b
* Added support for TQMa8XDP as well
* Add PWM polarity to PWM consumer
* Add PWM pinctrl settings
* Rename ethphy node names
* Remove obsolete num-cs property for SPI nodes
* Add gpio-line-names for lsio_gpio3
* Add USB host support (usbotg3)
* Add eMMC pinctrl settings for 100 & 200 MHz
* Merged SPI pinctrl groups (SPI lines + CS)
* Enabled USB3 host related driver in defconfig
* Add TODO entries

Alexander Stein (4):
  arm64: dts: imx: add imx8dxp support
  dt-bindings: arm: add TQMa8Xx boards
  arm64: dts: freescale: add initial device tree for TQMa8Xx
  arm64: defconfig: Enable i.MX8QXP device drivers

 .../devicetree/bindings/arm/fsl.yaml          |  16 +
 arch/arm64/boot/dts/freescale/Makefile        |   2 +
 .../dts/freescale/imx8dxp-tqma8xdp-mba8xx.dts |  16 +
 .../boot/dts/freescale/imx8dxp-tqma8xdp.dtsi  |  24 +
 arch/arm64/boot/dts/freescale/imx8dxp.dtsi    |  24 +
 .../dts/freescale/imx8qxp-tqma8xqp-mba8xx.dts |  16 +
 .../boot/dts/freescale/imx8qxp-tqma8xqp.dtsi  |  14 +
 arch/arm64/boot/dts/freescale/mba8xx.dtsi     | 532 ++++++++++++++++++
 arch/arm64/boot/dts/freescale/tqma8xx.dtsi    | 265 +++++++++
 arch/arm64/configs/defconfig                  |   6 +
 10 files changed, 915 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp-mba8xx.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8dxp.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp-mba8xx.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/mba8xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/tqma8xx.dtsi

-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec 14 06:23:25 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 15:23:25 +0100
Subject: [PATCH v2 2/4] dt-bindings: arm: add TQMa8Xx boards
In-Reply-To: <20231214142327.1962914-1-alexander.stein@ew.tq-group.com>
References: <20231214142327.1962914-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214142327.1962914-3-alexander.stein@ew.tq-group.com>

TQMa8Xx is a SOM series featuring NXP i.MX8X SoC.
They are called TQMa8XQP and TQMa8XDP respectively.
MBa8Xx is an evaluation mainboard for this SOM

Signed-off-by: Markus Niebel <Markus.Niebel at tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
Reviewed-by: Marco Felsch <m.felsch at pengutronix.de>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index cd87d1afe7b72..918a19d418922 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1231,6 +1231,22 @@ properties:
           - const: toradex,colibri-imx8x
           - const: fsl,imx8qxp
 
+      - description:
+          TQMa8Xx is a series of SOM featuring NXP i.MX8X system-on-chip
+          variants. It is designed to be clicked on different carrier boards
+          MBa8Xx is the starterkit
+        oneOf:
+          - items:
+              - enum:
+                  - tq,imx8dxp-tqma8xdp-mba8xx # TQ-Systems GmbH TQMa8XDP SOM on MBa8Xx
+              - const: tq,imx8dxp-tqma8xdp     # TQ-Systems GmbH TQMa8XDP SOM (with i.MX8DXP)
+              - const: fsl,imx8dxp
+          - items:
+              - enum:
+                  - tq,imx8qxp-tqma8xqp-mba8xx # TQ-Systems GmbH TQMa8XQP SOM on MBa8Xx
+              - const: tq,imx8qxp-tqma8xqp     # TQ-Systems GmbH TQMa8XQP SOM (with i.MX8QXP)
+              - const: fsl,imx8qxp
+
       - description: i.MX8ULP based Boards
         items:
           - enum:
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec 14 06:23:24 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 15:23:24 +0100
Subject: [PATCH v2 1/4] arm64: dts: imx: add imx8dxp support
In-Reply-To: <20231214142327.1962914-1-alexander.stein@ew.tq-group.com>
References: <20231214142327.1962914-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214142327.1962914-2-alexander.stein@ew.tq-group.com>

i.MX 8DualXPlus is a dual (2x) Cortex-A35 processor with powerful
graphic and multimedia features. This patch adds the SoC dtsi, based on
imx8qxp removing the additional CPU cores. Peripherals are identical.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm64/boot/dts/freescale/imx8dxp.dtsi | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8dxp.dtsi

diff --git a/arch/arm64/boot/dts/freescale/imx8dxp.dtsi b/arch/arm64/boot/dts/freescale/imx8dxp.dtsi
new file mode 100644
index 0000000000000..a8f7352332c05
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8dxp.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2019 NXP
+ */
+
+/dts-v1/;
+
+#include "imx8qxp.dtsi"
+
+/delete-node/ &A35_2;
+/delete-node/ &A35_3;
+
+&thermal_zones {
+	cpu0-thermal {
+		cooling-maps {
+			map0 {
+				cooling-device =
+				<&A35_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+				<&A35_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+			};
+		};
+	};
+};
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec 14 06:23:27 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 15:23:27 +0100
Subject: [PATCH v2 4/4] arm64: defconfig: Enable i.MX8QXP device drivers
In-Reply-To: <20231214142327.1962914-1-alexander.stein@ew.tq-group.com>
References: <20231214142327.1962914-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214142327.1962914-5-alexander.stein@ew.tq-group.com>

These drivers are used on i.MX8QXP based devices.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm64/configs/defconfig | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b2c06fe167a83..9f17b8ebe246d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -787,6 +787,7 @@ CONFIG_USB_VIDEO_CLASS=m
 CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_SDR_PLATFORM_DRIVERS=y
 CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_AMPHION_VPU=m
 CONFIG_VIDEO_CADENCE_CSI2RX=m
 CONFIG_VIDEO_MEDIATEK_JPEG=m
 CONFIG_VIDEO_MEDIATEK_VCODEC=m
@@ -794,6 +795,7 @@ CONFIG_VIDEO_IMX7_CSI=m
 CONFIG_VIDEO_IMX_MIPI_CSIS=m
 CONFIG_VIDEO_IMX8_ISI=m
 CONFIG_VIDEO_IMX8_ISI_M2M=y
+CONFIG_VIDEO_IMX8_JPEG=m
 CONFIG_VIDEO_QCOM_CAMSS=m
 CONFIG_VIDEO_QCOM_VENUS=m
 CONFIG_VIDEO_RCAR_ISP=m
@@ -1017,6 +1019,7 @@ CONFIG_USB_CDNS_SUPPORT=m
 CONFIG_USB_CDNS3=m
 CONFIG_USB_CDNS3_GADGET=y
 CONFIG_USB_CDNS3_HOST=y
+CONFIG_USB_CDNS3_IMX=m
 CONFIG_USB_MTU3=y
 CONFIG_USB_MUSB_HDRC=y
 CONFIG_USB_MUSB_SUNXI=y
@@ -1034,6 +1037,7 @@ CONFIG_USB_QCOM_EUD=m
 CONFIG_USB_HSIC_USB3503=y
 CONFIG_USB_ONBOARD_HUB=m
 CONFIG_NOP_USB_XCEIV=y
+CONFIG_USB_MXS_PHY=m
 CONFIG_USB_GADGET=y
 CONFIG_USB_RENESAS_USBHS_UDC=m
 CONFIG_USB_RZV2M_USB3DRD=y
@@ -1386,6 +1390,7 @@ CONFIG_EXTCON_USBC_CROS_EC=y
 CONFIG_RENESAS_RPCIF=m
 CONFIG_IIO=y
 CONFIG_EXYNOS_ADC=y
+CONFIG_IMX8QXP_ADC=m
 CONFIG_IMX93_ADC=m
 CONFIG_MAX9611=m
 CONFIG_MEDIATEK_MT6577_AUXADC=m
@@ -1437,6 +1442,7 @@ CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_CADENCE_TORRENT=m
 CONFIG_PHY_CADENCE_DPHY_RX=m
 CONFIG_PHY_CADENCE_SIERRA=m
+CONFIG_PHY_CADENCE_SALVO=m
 CONFIG_PHY_MIXEL_MIPI_DPHY=m
 CONFIG_PHY_FSL_IMX8M_PCIE=y
 CONFIG_PHY_HI6220_USB=y
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec 14 06:23:26 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 15:23:26 +0100
Subject: [PATCH v2 3/4] arm64: dts: freescale: add initial device tree for TQMa8Xx
In-Reply-To: <20231214142327.1962914-1-alexander.stein@ew.tq-group.com>
References: <20231214142327.1962914-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214142327.1962914-4-alexander.stein@ew.tq-group.com>

This adds support for TQMa8XQP and TQMa8XDP modules on MBa8Xx board.
As the only difference is the mounted SoC, both module and baseboard
files are shared.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm64/boot/dts/freescale/Makefile        |   2 +
 .../dts/freescale/imx8dxp-tqma8xdp-mba8xx.dts |  16 +
 .../boot/dts/freescale/imx8dxp-tqma8xdp.dtsi  |  24 +
 .../dts/freescale/imx8qxp-tqma8xqp-mba8xx.dts |  16 +
 .../boot/dts/freescale/imx8qxp-tqma8xqp.dtsi  |  14 +
 arch/arm64/boot/dts/freescale/mba8xx.dtsi     | 532 ++++++++++++++++++
 arch/arm64/boot/dts/freescale/tqma8xx.dtsi    | 265 +++++++++
 7 files changed, 869 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp-mba8xx.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp-mba8xx.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/mba8xx.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/tqma8xx.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 85abcb00811a7..8016f92cf130f 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -54,6 +54,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds-899b.dtb
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds-9999.dtb
 
 dtb-$(CONFIG_ARCH_MXC) += imx8dxl-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8dxp-tqma8xdp-mba8xx.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-data-modul-edm-sbc.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
@@ -196,6 +197,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8qxp-colibri-eval-v3.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qxp-colibri-iris.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qxp-colibri-iris-v2.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8qxp-tqma8xqp-mba8xx.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxca.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp-mba8xx.dts b/arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp-mba8xx.dts
new file mode 100644
index 0000000000000..f35514b7b3387
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp-mba8xx.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR X11)
+/*
+ * Copyright 2018-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+/dts-v1/;
+
+#include "imx8dxp-tqma8xdp.dtsi"
+#include "mba8xx.dtsi"
+
+/ {
+	model = "TQ-Systems i.MX8DXP TQMa8XDP on MBa8Xx";
+	compatible = "tq,imx8dxp-tqma8xdp-mba8xx", "tq,imx8dxp-tqma8xdp", "fsl,imx8dxp";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp.dtsi b/arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp.dtsi
new file mode 100644
index 0000000000000..e2de8517aa0ef
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR X11)
+/*
+ * Copyright 2018-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+#include "imx8dxp.dtsi"
+#include "tqma8xx.dtsi"
+
+/ {
+	model = "TQ-Systems i.MX8DXP TQMa8XDP";
+	compatible = "tq,imx8dxp-tqma8xdp", "fsl,imx8dxp";
+};
+
+&pmic_thermal {
+	cooling-maps {
+		map0 {
+			cooling-device =
+				<&A35_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+				<&A35_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp-mba8xx.dts b/arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp-mba8xx.dts
new file mode 100644
index 0000000000000..7d2e98bf8bc55
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp-mba8xx.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR X11)
+/*
+ * Copyright 2018-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+/dts-v1/;
+
+#include "imx8qxp-tqma8xqp.dtsi"
+#include "mba8xx.dtsi"
+
+/ {
+	model = "TQ-Systems i.MX8QXP TQMa8XQP on MBa8Xx";
+	compatible = "tq,imx8qxp-tqma8xqp-mba8xx", "tq,imx8qxp-tqma8xqp", "fsl,imx8qxp";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp.dtsi
new file mode 100644
index 0000000000000..b14040bf4ddd5
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-tqma8xqp.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR X11)
+/*
+ * Copyright 2018-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+#include "imx8qxp.dtsi"
+#include "tqma8xx.dtsi"
+
+/ {
+	model = "TQ-Systems i.MX8QXP TQMa8XQP";
+	compatible = "tq,imx8qxp-tqma8xqp", "fsl,imx8qxp";
+};
diff --git a/arch/arm64/boot/dts/freescale/mba8xx.dtsi b/arch/arm64/boot/dts/freescale/mba8xx.dtsi
new file mode 100644
index 0000000000000..a263c3d008023
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/mba8xx.dtsi
@@ -0,0 +1,532 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR X11)
+/*
+ * Copyright 2018-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/net/ti-dp83867.h>
+
+/ {
+	adc {
+		compatible = "iio-hwmon";
+		io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>;
+	};
+
+	aliases {
+		rtc0 = &pcf85063;
+		rtc1 = &rtc;
+	};
+
+	backlight_lvds: backlight-lvds {
+		compatible = "pwm-backlight";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_bl_lvds>;
+		pwms = <&adma_pwm 0 5000000 0>;
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <7>;
+		power-supply = <&reg_12v0>;
+		enable-gpios = <&lsio_gpio1 30 GPIO_ACTIVE_HIGH>;
+		status = "disabled";
+	};
+
+	chosen {
+		stdout-path = &lpuart1;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpiobuttons>;
+		autorepeat;
+
+		switch-a {
+			label = "switcha";
+			linux,code = <BTN_0>;
+			gpios = <&lsio_gpio1 13 GPIO_ACTIVE_LOW>;
+		};
+
+		switch-b {
+			label = "switchb";
+			linux,code = <BTN_1>;
+			gpios = <&lsio_gpio1 14 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		led1 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&expander 1 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "default-on";
+		};
+
+		led2 {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_HEARTBEAT;
+			gpios = <&expander 2 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	/* TODO LVDS panels */
+
+	reg_12v0: regulator-12v0 {
+		compatible = "regulator-fixed";
+		regulator-name = "V_12V";
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+		gpio = <&expander 6 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reg_pcie_1v5: regulator-pcie-1v5 {
+		compatible = "regulator-fixed";
+		regulator-name = "MBA8XX_PCIE_1V5";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_pcie_1v5>;
+		regulator-min-microvolt = <1500000>;
+		regulator-max-microvolt = <1500000>;
+		gpio = <&lsio_gpio0 30 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <1000>;
+		enable-active-high;
+	};
+
+	reg_pcie_3v3: regulator-pcie-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "MBA8XX_PCIE_3V3";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_pcie_3v3>;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&lsio_gpio0 31 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <1000>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	reg_3v3_mb: regulator-usdhc2-vmmc {
+		compatible = "regulator-fixed";
+		regulator-name = "V_3V3_MB";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
+	/* TODO: Audio */
+};
+
+&adc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc0>;
+	vref-supply = <&reg_1v8>;
+	#io-channel-cells = <1>;
+	status = "okay";
+};
+
+&adma_pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_admapwm>;
+};
+
+&fec1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec1>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&ethphy0>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_ethphy0>;
+			ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+			ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+			ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+			ti,dp83867-rxctrl-strap-quirk;
+			ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+			reset-gpios = <&lsio_gpio3 2 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <500000>;
+			reset-deassert-us = <50000>;
+			enet-phy-lane-no-swap;
+			interrupt-parent = <&lsio_gpio3>;
+			interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+		};
+
+		ethphy3: ethernet-phy at 3 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <3>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_ethphy3>;
+			ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+			ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+			ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+			ti,dp83867-rxctrl-strap-quirk;
+			ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+			reset-gpios = <&lsio_gpio3 3 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <500000>;
+			reset-deassert-us = <50000>;
+			enet-phy-lane-no-swap;
+			interrupt-parent = <&lsio_gpio3>;
+			interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+		};
+	};
+};
+
+&fec2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec2>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&ethphy3>;
+	status = "okay";
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_can0>;
+	xceiver-supply = <&reg_3v3>;
+	status = "okay";
+};
+
+&flexcan2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_can1>;
+	xceiver-supply = <&reg_3v3>;
+	status = "okay";
+};
+
+&i2c1 {
+	/* TODO: Add Audio codec */
+
+	se97b_1c: temperature-sensor at 1c {
+		compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+		reg = <0x1c>;
+	};
+
+	at24c02_54: eeprom at 54 {
+		compatible = "nxp,se97b", "atmel,24c02";
+		reg = <0x54>;
+		pagesize = <16>;
+		vcc-supply = <&reg_3v3>;
+	};
+
+	expander: gpio at 70 {
+		compatible = "nxp,pca9538";
+		reg = <0x70>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9538>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&lsio_gpio4>;
+		interrupts = <19 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-controller;
+		vcc-supply = <&reg_1v8>;
+
+		gpio-line-names = "", "LED_A",
+				  "LED_B", "",
+				  "DSI_EN", "USB_RESET#",
+				  "V_12V_EN", "PCIE_DIS#";
+	};
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c2>;
+	pinctrl-1 = <&pinctrl_lpi2c2gpio>;
+	scl-gpios = <&lsio_gpio1 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&lsio_gpio2 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	status = "okay";
+};
+
+/* TODO LDB */
+
+&lpspi1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spi1>;
+	cs-gpios = <&lsio_gpio0 27 GPIO_ACTIVE_LOW>, <&lsio_gpio0 29 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&lpspi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spi2>;
+	cs-gpios = <&lsio_gpio1 0 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&lpspi3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spi3>;
+	num-cs = <2>;
+	cs-gpios = <&lsio_gpio0 16 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart1>;
+	status = "okay";
+};
+
+&lpuart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart3>;
+	status = "okay";
+};
+
+&lsio_gpio3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lsgpio3>;
+	gpio-line-names = "", "", "", "",
+			  "", "", "", "",
+			  "", "", "", "",
+			  "", "", "", "X4_15",
+			  "", "", "", "",
+			  "", "", "", "",
+			  "", "", "", "",
+			  "", "", "", "";
+};
+
+/* TODO: Mini-PCIe */
+
+/* TODO: SAI1 */
+
+&usbotg1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg1>;
+	srp-disable;
+	hnp-disable;
+	adp-disable;
+	power-active-high;
+	over-current-active-low;
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&usbotg3 {
+	status = "okay";
+};
+
+&usbotg3_cdns3 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usbphy1 {
+	status = "okay";
+};
+
+&usb3_phy {
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+	bus-width = <4>;
+	cd-gpios = <&lsio_gpio4 22 GPIO_ACTIVE_LOW>;
+	wp-gpios = <&lsio_gpio4 21 GPIO_ACTIVE_HIGH>;
+	vmmc-supply = <&reg_3v3_mb>;
+	no-1-8-v;
+	no-sdio;
+	no-mmc;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_adc0: adc0grp {
+		fsl,pins = <IMX8QXP_ADC_IN0_ADMA_ADC_IN0	0x02000060>,
+			   <IMX8QXP_ADC_IN1_ADMA_ADC_IN1	0x02000060>,
+			   <IMX8QXP_ADC_IN2_ADMA_ADC_IN2	0x02000060>,
+			   <IMX8QXP_ADC_IN3_ADMA_ADC_IN3	0x02000060>;
+	};
+
+	pinctrl_admapwm: admapwmgrp {
+		fsl,pins = <IMX8QXP_SPI0_CS1_ADMA_LCD_PWM0_OUT	0x00000021>;
+	};
+
+	pinctrl_bl_lvds: bllvdsgrp {
+		fsl,pins = <IMX8QXP_MIPI_DSI1_I2C0_SDA_LSIO_GPIO1_IO30	0x00000021>;
+	};
+
+	pinctrl_can0: can0grp {
+		fsl,pins = <IMX8QXP_UART0_RX_ADMA_FLEXCAN0_RX		0x00000021>,
+			   <IMX8QXP_UART0_TX_ADMA_FLEXCAN0_TX		0x00000021>;
+	};
+
+	pinctrl_can1: can1grp {
+		fsl,pins = <IMX8QXP_UART2_RX_ADMA_FLEXCAN1_RX		0x00000021>,
+			   <IMX8QXP_UART2_TX_ADMA_FLEXCAN1_TX		0x00000021>;
+	};
+
+	pinctrl_ethphy0: ethphy0grp {
+		fsl,pins = <IMX8QXP_CSI_EN_LSIO_GPIO3_IO02		0x00000040>,
+			   <IMX8QXP_CSI_PCLK_LSIO_GPIO3_IO00		0x00000040>;
+	};
+
+	pinctrl_ethphy3: ethphy3grp {
+		fsl,pins = <IMX8QXP_CSI_RESET_LSIO_GPIO3_IO03		0x00000040>,
+			   <IMX8QXP_CSI_MCLK_LSIO_GPIO3_IO01		0x00000040>;
+	};
+
+	pinctrl_fec1: fec1grp {
+		fsl,pins = <IMX8QXP_ENET0_MDC_CONN_ENET0_MDC			0x06000041>,
+			   <IMX8QXP_ENET0_MDIO_CONN_ENET0_MDIO			0x06000041>,
+			   <IMX8QXP_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_TXC_CONN_ENET0_RGMII_TXC	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_TXD2_CONN_ENET0_RGMII_TXD2	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_TXD3_CONN_ENET0_RGMII_TXD3	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_RXC_CONN_ENET0_RGMII_RXC	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_RXD2_CONN_ENET0_RGMII_RXD2	0x00000040>,
+			   <IMX8QXP_ENET0_RGMII_RXD3_CONN_ENET0_RGMII_RXD3	0x00000040>;
+	};
+
+	pinctrl_fec2: fec2grp {
+		fsl,pins = <IMX8QXP_ESAI0_SCKR_CONN_ENET1_RGMII_TX_CTL		0x00000040>,
+			   <IMX8QXP_ESAI0_FSR_CONN_ENET1_RGMII_TXC		0x00000040>,
+			   <IMX8QXP_ESAI0_TX4_RX1_CONN_ENET1_RGMII_TXD0		0x00000040>,
+			   <IMX8QXP_ESAI0_TX5_RX0_CONN_ENET1_RGMII_TXD1		0x00000040>,
+			   <IMX8QXP_ESAI0_FST_CONN_ENET1_RGMII_TXD2		0x00000040>,
+			   <IMX8QXP_ESAI0_SCKT_CONN_ENET1_RGMII_TXD3		0x00000040>,
+			   <IMX8QXP_ESAI0_TX0_CONN_ENET1_RGMII_RXC		0x00000040>,
+			   <IMX8QXP_SPDIF0_TX_CONN_ENET1_RGMII_RX_CTL		0x00000040>,
+			   <IMX8QXP_SPDIF0_RX_CONN_ENET1_RGMII_RXD0		0x00000040>,
+			   <IMX8QXP_ESAI0_TX3_RX2_CONN_ENET1_RGMII_RXD1		0x00000040>,
+			   <IMX8QXP_ESAI0_TX2_RX3_CONN_ENET1_RGMII_RXD2		0x00000040>,
+			   <IMX8QXP_ESAI0_TX1_CONN_ENET1_RGMII_RXD3		0x00000040>;
+	};
+
+	pinctrl_gpiobuttons: gpiobuttonsgrp {
+		fsl,pins = <IMX8QXP_ADC_IN5_LSIO_GPIO1_IO13	0x00000020>,
+			   <IMX8QXP_ADC_IN4_LSIO_GPIO1_IO14	0x00000020>;
+	};
+
+	pinctrl_lpi2c2: lpi2c2grp {
+		fsl,pins = <IMX8QXP_MIPI_DSI1_GPIO0_00_ADMA_I2C2_SCL	0x06000021>,
+			   <IMX8QXP_MIPI_DSI1_GPIO0_01_ADMA_I2C2_SDA	0x06000021>;
+	};
+
+	pinctrl_lpi2c2gpio: lpi2c2gpiogrp {
+		fsl,pins = <IMX8QXP_MIPI_DSI1_GPIO0_00_LSIO_GPIO1_IO31	0x06000021>,
+			   <IMX8QXP_MIPI_DSI1_GPIO0_01_LSIO_GPIO2_IO00	0x06000021>;
+	};
+
+	pinctrl_lpuart1: lpuart1grp {
+		fsl,pins = <IMX8QXP_UART1_RX_ADMA_UART1_RX	0x06000020>,
+			   <IMX8QXP_UART1_TX_ADMA_UART1_TX	0x06000020>;
+	};
+
+	pinctrl_lpuart3: lpuart3grp {
+		fsl,pins = <IMX8QXP_FLEXCAN2_RX_ADMA_UART3_RX	0x06000020>,
+			   <IMX8QXP_FLEXCAN2_TX_ADMA_UART3_TX	0x06000020>;
+	};
+
+	pinctrl_lsgpio3: lsgpio3grp {
+		fsl,pins = <IMX8QXP_QSPI0A_SS1_B_LSIO_GPIO3_IO15	0x00000021>;
+	};
+
+	pinctrl_pca9538: pca9538grp {
+		fsl,pins = <IMX8QXP_USDHC1_RESET_B_LSIO_GPIO4_IO19	0x00000020>;
+	};
+
+	pinctrl_pcieb: pcieagrp{
+		fsl,pins = <IMX8QXP_PCIE_CTRL0_PERST_B_LSIO_GPIO4_IO00	0x06000041>,
+			   <IMX8QXP_PCIE_CTRL0_CLKREQ_B_LSIO_GPIO4_IO01	0x06000041>,
+			   <IMX8QXP_PCIE_CTRL0_WAKE_B_LSIO_GPIO4_IO02	0x04000041>;
+	};
+
+	pinctrl_reg_pcie_1v5: regpcie1v5grp {
+		fsl,pins = <IMX8QXP_SAI1_RXC_LSIO_GPIO0_IO30	0x00000021>;
+	};
+
+	pinctrl_reg_pcie_3v3: regpcie3v3grp {
+		fsl,pins = <IMX8QXP_SAI1_RXFS_LSIO_GPIO0_IO31	0x00000021>;
+	};
+
+	pinctrl_sai1: sai1grp {
+		fsl,pins = <IMX8QXP_MCLK_OUT0_ADMA_ACM_MCLK_OUT0	0x06000041>,
+			   <IMX8QXP_FLEXCAN0_RX_ADMA_SAI1_TXC		0x06000041>,
+			   <IMX8QXP_FLEXCAN0_TX_ADMA_SAI1_TXFS		0x06000041>,
+			   <IMX8QXP_FLEXCAN1_RX_ADMA_SAI1_TXD		0x06000041>,
+			   <IMX8QXP_FLEXCAN1_TX_ADMA_SAI1_RXD		0x06000041>;
+	};
+
+	pinctrl_spi1: spi1grp {
+		fsl,pins = <IMX8QXP_SAI0_TXC_ADMA_SPI1_SDI	0x00000041>,
+			   <IMX8QXP_SAI0_TXD_ADMA_SPI1_SDO	0x00000041>,
+			   <IMX8QXP_SAI0_TXFS_ADMA_SPI1_SCK	0x00000041>,
+			   <IMX8QXP_SAI0_RXD_LSIO_GPIO0_IO27	0x00000021>,
+			   <IMX8QXP_SAI1_RXD_LSIO_GPIO0_IO29	0x00000021>;
+	};
+
+	pinctrl_spi2: spi2grp {
+		fsl,pins = <IMX8QXP_SPI2_SCK_ADMA_SPI2_SCK	0x00000041>,
+			   <IMX8QXP_SPI2_SDI_ADMA_SPI2_SDI	0x00000041>,
+			   <IMX8QXP_SPI2_SDO_ADMA_SPI2_SDO	0x00000041>,
+			   <IMX8QXP_SPI2_CS0_LSIO_GPIO1_IO00	0x00000021>;
+	};
+
+	pinctrl_spi3: spi3grp {
+		fsl,pins = <IMX8QXP_SPI3_SCK_ADMA_SPI3_SCK	0x00000041>,
+			   <IMX8QXP_SPI3_SDI_ADMA_SPI3_SDI	0x00000041>,
+			   <IMX8QXP_SPI3_SDO_ADMA_SPI3_SDO	0x00000041>,
+			   <IMX8QXP_SPI3_CS0_LSIO_GPIO0_IO16	0x00000021>,
+			   <IMX8QXP_SPI3_CS1_ADMA_SPI3_CS1	0x00000021>;
+	};
+
+	pinctrl_usbotg1: usbotg1grp {
+		fsl,pins = <IMX8QXP_USB_SS3_TC0_CONN_USB_OTG1_PWR	0x00000021>,
+			   <IMX8QXP_USB_SS3_TC2_CONN_USB_OTG1_OC	0x00000021>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+		fsl,pins = <IMX8QXP_USDHC1_WP_LSIO_GPIO4_IO21		0x00000021>,
+			   <IMX8QXP_USDHC1_CD_B_LSIO_GPIO4_IO22		0x00000021>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK		0x06000041>,
+			   <IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD		0x00000021>,
+			   <IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0	0x00000021>,
+			   <IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1	0x00000021>,
+			   <IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2	0x00000021>,
+			   <IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3	0x00000021>,
+			   <IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT	0x00000021>;
+	};
+
+	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+		fsl,pins = <IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK		0x06000040>,
+			   <IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD		0x00000020>,
+			   <IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0	0x00000020>,
+			   <IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1	0x00000020>,
+			   <IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2	0x00000020>,
+			   <IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3	0x00000020>,
+			   <IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT	0x00000020>;
+	};
+
+	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+		fsl,pins = <IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK		0x06000040>,
+			   <IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD		0x00000020>,
+			   <IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0	0x00000020>,
+			   <IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1	0x00000020>,
+			   <IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2	0x00000020>,
+			   <IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3	0x00000020>,
+			   <IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT	0x00000020>;
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/tqma8xx.dtsi b/arch/arm64/boot/dts/freescale/tqma8xx.dtsi
new file mode 100644
index 0000000000000..d98469a7c47cc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/tqma8xx.dtsi
@@ -0,0 +1,265 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR X11)
+/*
+ * Copyright 2018-2023 TQ-Systems GmbH <linux at ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+/ {
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0 0x40000000>;
+	};
+
+	reg_1v8: regulator-1v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "V_1V8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	reg_3v3: regulator-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "V_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/*
+		 * global autoconfigured region for contiguous allocations
+		 * must not exceed memory size and region
+		 */
+		linux,cma {
+			compatible = "shared-dma-pool";
+			reusable;
+			size = <0 0x20000000>;
+			alloc-ranges = <0 0x96000000 0 0x30000000>;
+			linux,cma-default;
+		};
+	};
+};
+
+/* TQMa8Xx only uses industrial grade, reduce trip points accordingly */
+&cpu_alert0 {
+	temperature = <95000>;
+};
+
+&cpu_crit0 {
+	temperature = <100000>;
+};
+/* end of temperature grade adjustments */
+
+&flexspi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexspi0>;
+	status = "okay";
+
+	flash0: flash at 0 {
+		reg = <0>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "jedec,spi-nor";
+		spi-max-frequency = <66000000>;
+		spi-tx-bus-width = <1>;
+		spi-rx-bus-width = <4>;
+	};
+};
+
+/* TODO GPU */
+
+&i2c1 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <100000>;
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c1>;
+	pinctrl-1 = <&pinctrl_lpi2c1gpio>;
+	scl-gpios = <&lsio_gpio1 27 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&lsio_gpio1 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	status = "okay";
+
+	se97: temperature-sensor at 1b {
+		compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+		reg = <0x1b>;
+	};
+
+	pcf85063: rtc at 51 {
+		compatible = "nxp,pcf85063a";
+		reg = <0x51>;
+		quartz-load-femtofarads = <7000>;
+	};
+
+	at24c02: eeprom at 53 {
+		compatible = "nxp,se97b", "atmel,24c02";
+		reg = <0x53>;
+		pagesize = <16>;
+		read-only;
+		vcc-supply = <&reg_3v3>;
+	};
+
+	m24c64: eeprom at 57 {
+		compatible = "atmel,24c64";
+		reg = <0x57>;
+		pagesize = <32>;
+		vcc-supply = <&reg_3v3>;
+	};
+};
+
+&mu_m0 {
+	status = "okay";
+};
+
+&mu1_m0 {
+	status = "okay";
+};
+
+&thermal_zones {
+	pmic_thermal: pmic-thermal {
+		polling-delay-passive = <250>;
+		polling-delay = <2000>;
+		thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
+
+		trips {
+			pmic_alert0: trip0 {
+				temperature = <110000>;
+				hysteresis = <2000>;
+				type = "passive";
+			};
+
+			pmic_crit0: trip1 {
+				temperature = <125000>;
+				hysteresis = <2000>;
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			map0 {
+				trip = <&pmic_alert0>;
+				cooling-device =
+					<&A35_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+					<&A35_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+					<&A35_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+					<&A35_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+			};
+		};
+	};
+};
+
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+	vqmmc-supply = <&reg_1v8>;
+	vmmc-supply = <&reg_3v3>;
+	bus-width = <8>;
+	non-removable;
+	no-sdio;
+	no-sd;
+	status = "okay";
+};
+
+&vpu {
+	compatible = "nxp,imx8qxp-vpu";
+	status = "okay";
+};
+
+&vpu_core0 {
+	memory-region = <&decoder_boot>, <&decoder_rpc>;
+	status = "okay";
+};
+
+&vpu_core1 {
+	memory-region = <&encoder_boot>, <&encoder_rpc>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_flexspi0: flexspi0grp {
+		fsl,pins = <
+			IMX8QXP_QSPI0A_DATA0_LSIO_QSPI0A_DATA0	0x0600004d
+			IMX8QXP_QSPI0A_DATA1_LSIO_QSPI0A_DATA1	0x0600004d
+			IMX8QXP_QSPI0A_DATA2_LSIO_QSPI0A_DATA2	0x0600004d
+			IMX8QXP_QSPI0A_DATA3_LSIO_QSPI0A_DATA3	0x0600004d
+			IMX8QXP_QSPI0A_DQS_LSIO_QSPI0A_DQS	0x0600004d
+			IMX8QXP_QSPI0A_SS0_B_LSIO_QSPI0A_SS0_B	0x0600004d
+			IMX8QXP_QSPI0A_SCLK_LSIO_QSPI0A_SCLK	0x0600004d
+			IMX8QXP_QSPI0B_SCLK_LSIO_QSPI0B_SCLK	0x0600004d
+			IMX8QXP_QSPI0B_DATA0_LSIO_QSPI0B_DATA0	0x0600004d
+			IMX8QXP_QSPI0B_DATA1_LSIO_QSPI0B_DATA1	0x0600004d
+			IMX8QXP_QSPI0B_DATA2_LSIO_QSPI0B_DATA2	0x0600004d
+			IMX8QXP_QSPI0B_DATA3_LSIO_QSPI0B_DATA3	0x0600004d
+			IMX8QXP_QSPI0B_DQS_LSIO_QSPI0B_DQS	0x0600004d
+			IMX8QXP_QSPI0B_SS0_B_LSIO_QSPI0B_SS0_B	0x0600004d
+			IMX8QXP_QSPI0B_SS1_B_LSIO_QSPI0B_SS1_B	0x0600004d
+		>;
+	};
+
+	pinctrl_lpi2c1: lpi2c1grp {
+		fsl,pins = <
+			IMX8QXP_MIPI_DSI0_GPIO0_00_ADMA_I2C1_SCL	0x06000021
+			IMX8QXP_MIPI_DSI0_GPIO0_01_ADMA_I2C1_SDA	0x06000021
+		>;
+	};
+
+	pinctrl_lpi2c1gpio: lpi2c1gpiogrp {
+		fsl,pins = <
+			IMX8QXP_MIPI_DSI0_GPIO0_00_LSIO_GPIO1_IO27	0x06000021
+			IMX8QXP_MIPI_DSI0_GPIO0_01_LSIO_GPIO1_IO28	0x06000021
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK	0x06000041
+			IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD	0x00000021
+			IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0	0x00000021
+			IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1	0x00000021
+			IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2	0x00000021
+			IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3	0x00000021
+			IMX8QXP_EMMC0_DATA4_CONN_EMMC0_DATA4	0x00000021
+			IMX8QXP_EMMC0_DATA5_CONN_EMMC0_DATA5	0x00000021
+			IMX8QXP_EMMC0_DATA6_CONN_EMMC0_DATA6	0x00000021
+			IMX8QXP_EMMC0_DATA7_CONN_EMMC0_DATA7	0x00000021
+			IMX8QXP_EMMC0_STROBE_CONN_EMMC0_STROBE	0x00000041
+		>;
+	};
+
+	pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+		fsl,pins = <
+			IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK	0x06000040
+			IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD	0x00000020
+			IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0	0x00000020
+			IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1	0x00000020
+			IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2	0x00000020
+			IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3	0x00000020
+			IMX8QXP_EMMC0_DATA4_CONN_EMMC0_DATA4	0x00000020
+			IMX8QXP_EMMC0_DATA5_CONN_EMMC0_DATA5	0x00000020
+			IMX8QXP_EMMC0_DATA6_CONN_EMMC0_DATA6	0x00000020
+			IMX8QXP_EMMC0_DATA7_CONN_EMMC0_DATA7	0x00000020
+			IMX8QXP_EMMC0_STROBE_CONN_EMMC0_STROBE	0x00000040
+		>;
+	};
+
+	pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+		fsl,pins = <
+			IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK	0x06000040
+			IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD	0x00000020
+			IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0	0x00000020
+			IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1	0x00000020
+			IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2	0x00000020
+			IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3	0x00000020
+			IMX8QXP_EMMC0_DATA4_CONN_EMMC0_DATA4	0x00000020
+			IMX8QXP_EMMC0_DATA5_CONN_EMMC0_DATA5	0x00000020
+			IMX8QXP_EMMC0_DATA6_CONN_EMMC0_DATA6	0x00000020
+			IMX8QXP_EMMC0_DATA7_CONN_EMMC0_DATA7	0x00000020
+			IMX8QXP_EMMC0_STROBE_CONN_EMMC0_STROBE	0x00000040
+		>;
+	};
+};
-- 
2.34.1



From ninad at linux.ibm.com  Thu Dec 14 06:24:09 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Thu, 14 Dec 2023 08:24:09 -0600
Subject: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
In-Reply-To: <1c5ace65-2fd8-4503-b22f-e0f564d1c83f@linaro.org>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-9-ninad@linux.ibm.com>
 <5b98538a-8ffe-42ec-b020-514dcfcebba3@linaro.org>
 <44abff4a-0a8e-499b-8b98-a4a1680cb431@linux.ibm.com>
 <427fa99c-764c-4d6a-b9f1-cd9089710d5e@linaro.org>
 <edcdcea2-febc-4859-9ccf-b8c59b794f01@linux.ibm.com>
 <1c5ace65-2fd8-4503-b22f-e0f564d1c83f@linaro.org>
Message-ID: <f9f95e8d-02e5-454e-8075-1e4231d385bb@linux.ibm.com>

Hello Krzysztof,


On 12/14/23 01:24, Krzysztof Kozlowski wrote:
> On 13/12/2023 20:49, Ninad Palsule wrote:
>> Hello Krzysztof,
>>
>> On 12/13/23 13:37, Krzysztof Kozlowski wrote:
>>> On 13/12/2023 20:02, Ninad Palsule wrote:
>>>> Hello Krzysztof,
>>>>
>>>> On 12/12/23 14:26, Krzysztof Kozlowski wrote:
>>>>> On 12/12/2023 17:40, Ninad Palsule wrote:
>>>>>> This drop adds following devices in the device tree.
>>>>>> - EEPROM/VPD
>>>>>> - Power supplies
>>>>>> - Humidity, pressure and temperature sensors.
>>>>>> - Trusted platform module(TPM) chip
>>>>>>
>>>>>> Tested:
>>>>>>        This board is tested using the simics simulator.
>>>>>>
>>>>>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>>>>>> ---
>>>>> Don't mix DTS with drivers. DTS and drivers go via different subsystems
>>>>> and cannot have dependencies, so why DTS is patch #6, then driver #7 and
>>>>> now again DTS #7?
>>>> There is a dependency on driver code as patch #8 uses the compatibility
>>>> string added in driver patch #7.? I have now moved driver patch at the
>>>> start. Is that ok? OR you are suggesting something else?
>>> First, there is no dependency. Second, except confusing order anyway DTS
>>> will go via separate trees. Third, again, there is no dependency. If
>>> there is, your patchset is broken and this needs to be fixed. Although I
>>> don't understand how new hardware can depend on driver... it's really odd.
>> Thanks for the quick response.
>>
>> This board uses the nuvoton TPM device. The tpm devices uses
>> "nuvoton,npct75x" driver hence we added it in the device tree. If the
>> driver doesn't have this compatibility string then it won't load. So if
>> someone tries to use this board then tpm won't work unless the
> ... and if there is no board it also fails to load.
>
>> compatibility string is added in the driver. That is the dependency I am
>> talking about.
> This is not a dependency! It's unrelated.

ok, I will send it as a separate patch.

Thanks for the prompt reply.

Regards,

Ninad

>
> Best regards,
> Krzysztof
>


From ryan.roberts at arm.com  Thu Dec 14 06:28:13 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 14 Dec 2023 14:28:13 +0000
Subject: [PATCH v3 12/15] arm64/mm: Split __flush_tlb_range() to elide
 trailing DSB
In-Reply-To: <fbcda9e1-0473-4669-a869-d4de351c3197@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-13-ryan.roberts@arm.com>
 <20231212113517.GA28857@willie-the-truck>
 <0969c413-bf40-4c46-9f1e-a92101ff2d2e@arm.com>
 <2e6f06d3-6c8e-4b44-b6f2-e55bd5be83d6@arm.com>
 <20231214121336.GA1015@willie-the-truck>
 <fbcda9e1-0473-4669-a869-d4de351c3197@arm.com>
Message-ID: <123a58b0-2ea6-4da3-9719-98ca55c8095e@arm.com>

On 14/12/2023 12:30, Robin Murphy wrote:
> On 2023-12-14 12:13 pm, Will Deacon wrote:
>> On Thu, Dec 14, 2023 at 11:53:52AM +0000, Ryan Roberts wrote:
>>> On 12/12/2023 11:47, Ryan Roberts wrote:
>>>> On 12/12/2023 11:35, Will Deacon wrote:
>>>>> On Mon, Dec 04, 2023 at 10:54:37AM +0000, Ryan Roberts wrote:
>>>>>> diff --git a/arch/arm64/include/asm/tlbflush.h
>>>>>> b/arch/arm64/include/asm/tlbflush.h
>>>>>> index bb2c2833a987..925ef3bdf9ed 100644
>>>>>> --- a/arch/arm64/include/asm/tlbflush.h
>>>>>> +++ b/arch/arm64/include/asm/tlbflush.h
>>>>>> @@ -399,7 +399,7 @@ do {??????????????????????????????????? \
>>>>>> ? #define __flush_s2_tlb_range_op(op, start, pages, stride, tlb_level) \
>>>>>> ????? __flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false)
>>>>>> ? -static inline void __flush_tlb_range(struct vm_area_struct *vma,
>>>>>> +static inline void __flush_tlb_range_nosync(struct vm_area_struct *vma,
>>>>>> ?????????????????????? unsigned long start, unsigned long end,
>>>>>> ?????????????????????? unsigned long stride, bool last_level,
>>>>>> ?????????????????????? int tlb_level)
>>>>>> @@ -431,10 +431,19 @@ static inline void __flush_tlb_range(struct
>>>>>> vm_area_struct *vma,
>>>>>> ????? else
>>>>>> ????????? __flush_tlb_range_op(vae1is, start, pages, stride, asid,
>>>>>> tlb_level, true);
>>>>>> ? -??? dsb(ish);
>>>>>> ????? mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, start, end);
>>>>>> ? }
>>>>>> ? +static inline void __flush_tlb_range(struct vm_area_struct *vma,
>>>>>> +???????????????????? unsigned long start, unsigned long end,
>>>>>> +???????????????????? unsigned long stride, bool last_level,
>>>>>> +???????????????????? int tlb_level)
>>>>>> +{
>>>>>> +??? __flush_tlb_range_nosync(vma, start, end, stride,
>>>>>> +???????????????? last_level, tlb_level);
>>>>>> +??? dsb(ish);
>>>>>> +}
>>>>>
>>>>> Hmm, are you sure it's safe to defer the DSB until after the secondary TLB
>>>>> invalidation? It will have a subtle effect on e.g. an SMMU participating
>>>>> in broadcast TLB maintenance, because now the ATC will be invalidated
>>>>> before completion of the TLB invalidation and it's not obviously safe to me.
>>>>
>>>> I'll be honest; I don't know that it's safe. The notifier calls turned up
>>>> during
>>>> a rebase and I stared at it for a while, before eventually concluding that I
>>>> should just follow the existing pattern in __flush_tlb_page_nosync(): That one
>>>> calls the mmu notifier without the dsb, then flush_tlb_page() does the dsb
>>>> after. So I assumed it was safe.
>>>>
>>>> If you think it's not safe, I guess there is a bug to fix in
>>>> __flush_tlb_page_nosync()?
>>>
>>> Did you have an opinion on this? I'm just putting together a v4 of this series,
>>> and I'll remove this optimization if you think it's unsound. But in that case, I
>>> guess we have an existing bug to fix too?
>>
>> Sorry, Ryan, I've not had a chance to look into it in more detail. But as
>> you rightly point out, you're not introducing the issue (assuming it is
>> one), so I don't think it needs to hold you up. Your code just makes the
>> thing more "obvious" to me.

OK thanks. I'll leave my code as is for now then - that makes it easier to do
A/B performance comparison with the existing code. And I can change it if/when
mainline changes (presumably to add the dsb between the tlbi and the mmu
notifier callback).

>>
>> Robin, Jean-Philippe -- do we need to make sure that the SMMU has completed
>> its TLB invalidation before issuing an ATC invalidate? My half-baked worry
>> is whether or not an ATS request could refill the ATC before the TLBI
>> has completed, therefore rendering the ATC invalidation useless.
> 
> I would agree, and the spec for CMD_ATC_INV does call out a
> TLBI->sync->ATCI->sync sequence. At the moment the SVA notifier is issuing its
> own command-based TLBIs anyway so the necessary sync is implicit there, but if
> and when we get BTM support wired up properly it would be nice not to have to
> bodge in an additional sync/DSB.
> 
> Cheers,
> Robin.



From tudor.ambarus at linaro.org  Thu Dec 14 06:31:23 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 14:31:23 +0000
Subject: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
In-Reply-To: <6962ac73-2f44-4c9e-8731-152087815454@app.fastmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-6-tudor.ambarus@linaro.org>
 <1938fcf1-eb5d-4723-a6c6-d2fe2c6dd1c0@app.fastmail.com>
 <8808ceeb-35dc-4094-aec4-f43c7acd6174@linaro.org>
 <6962ac73-2f44-4c9e-8731-152087815454@app.fastmail.com>
Message-ID: <584e036a-2ae7-4b88-a517-8f79c6baed4a@linaro.org>



On 12/14/23 14:19, Arnd Bergmann wrote:
> On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
>> On 12/14/23 12:01, Arnd Bergmann wrote:
>>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>>
>>
>> It works if in device tree one specifies the reg-io-width property and
>> sets it to 4. If the reg-io-width is not specified, the iotype defaults
>> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
>> unusable.
> 
> In the case of incorrect DT data like a missing reg-io-width property,
> I would expect it to still fail once the regular console or tty takes
> over from earlycon.
> 
>> Also, if the earlycon comes specified from the kernel params, the
>> of_setup_earlycon() is no longer called and the earlycon will be set
>> solely based on the kernel params buffer, thus allowing users to crash
>> the kernel on wrong earlycon definitions.
> 
> But that in turn is the same as specifying any other incorrect earlycon.

I don't think you can crash the kernel if you use other earlycon as you
don't make accesses on the 32bit restricted bus. But I agree that if
using the correct earlycon name, and mmio instead mmio32, is equivalent
to not specifying reg-io-width in dt.

> 
>> If you think the change is fine, I can amend the commit message with the
>> description from above.
> 
> I'm still not convinced we need a special case here when everything else
> just requires passing the correct data.
> 

Well, I made this patch because I used a wrong bootargs earlycon
configuration and I ended up crashing the kernel. I couldn't see what
happens as kgdb is not available at that stage. Figuring out what was
going on made me spend some time. I hoped I'll be helpful and spare
others of the same mistakes and wasted time.

I'm ok to drop the patch as well, no pushing here. Please ignore.
Thanks for the review!

Cheers,
ta


From joro at 8bytes.org  Thu Dec 14 06:35:21 2023
From: joro at 8bytes.org (Joerg Roedel)
Date: Thu, 14 Dec 2023 15:35:21 +0100
Subject: [GIT PULL] iommu/arm-smmu: Updates for 6.8
In-Reply-To: <20231214104327.GA924@willie-the-truck>
References: <20231214104327.GA924@willie-the-truck>
Message-ID: <ZXsSqZGxulavBmuw@8bytes.org>

On Thu, Dec 14, 2023 at 10:43:28AM +0000, Will Deacon wrote:
>   git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git tags/arm-smmu-updates

Pulled, thanks Will.


From wenst at chromium.org  Thu Dec 14 06:37:23 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 14 Dec 2023 23:37:23 +0900
Subject: [PATCH v4 6/9] arm64: dts: mediatek: Add MT8186 Krabby platform
 based Tentacruel / Tentacool
In-Reply-To: <13c8ccbc-0eef-43f5-ae37-29ec64d1606b@collabora.com>
References: <20231213150435.4134390-1-wenst@chromium.org> <20231213150435.4134390-7-wenst@chromium.org>
 <13c8ccbc-0eef-43f5-ae37-29ec64d1606b@collabora.com>
Message-ID: <CAGXv+5HO+TW6H9kLv62Dp7cihHW7fs99gzUBMWvAEnzdrNY7mg@mail.gmail.com>

On Thu, Dec 14, 2023 at 7:31?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 13/12/23 16:04, Chen-Yu Tsai ha scritto:
> > Tentacruel and Tentacool are MT8186 based Chromebooks based on the
> > Krabby design.
> >
> > Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a
> > convertible device with touchscreen and stylus.
> >
> > Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop
> > device. It does not have a touchscreen or stylus.
> >
> > The two devices both have two variants. The difference is a second
> > source touchpad controller that shares the same address as the original,
> > but is incompatible.
> >
> > The extra SKU IDs for the Tentacruel devices map to different sensor
> > components attached to the Embedded Controller. These are not visible
> > to the main processor.
> >
> > Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> > Acked-by: Conor Dooley <conor.dooley at microchip.com>
> > ---
> > Changes since v3:
> > - Reorder some properties to conform better to the newly proposed DT
> >    style guidelines
> > - Drop unused labels
> > - Rename bt-sco node name to bt-sco-codec
> > - Drop i2s*-share properties from afe node
> > - Drop aud_gpio_tdm_{on,off} pinctrl nodes
> > - Replace interrupts with interrupts-extended in tpm node
> > - Enable adsp device
> >
> > Changes since v2:
> > - Picked up Conor's ack
> > - Rename touchpad to trackpad
> > - Drop pinctrl properties from trackpad in tentacruel/tentacool second
> >    source trackpad
> >
> > Changes since v1:
> > - Reorder SKU numbers in descending order.
> > - Fixed pinconfig node names
> > - Moved pinctrl-* properties after interrupts-*
> > - Switched to interrupts-extended for external components
> > - Marked ADSP as explicitly disabled, with a comment explaining that it
> >    stalls the system
> > - Renamed "touchpad" to "trackpad"
> > - Dropped bogus "no-laneswap" property from it6505 node
> > - Moved "realtek,jd-src" property to after all the regulator supplies
> > - Switched to macros for MT6366 regulator "regulator-allowed-modes"
> > - Renamed "vgpu" regulator name to allow coupling, with a comment
> >    containing the name used in the design
> > - Renamed "cr50" node name to "tpm"
> > - Moved trackpad_pins reference up to i2c2; workaround for second source
> >    component resource sharing.
> > - Fix copyright year
> > - Fixed touchscreen supply name
> > ---
> >   arch/arm64/boot/dts/mediatek/Makefile         |    4 +
> >   .../dts/mediatek/mt8186-corsola-krabby.dtsi   |  129 ++
> >   .../mt8186-corsola-tentacool-sku327681.dts    |   57 +
> >   .../mt8186-corsola-tentacool-sku327683.dts    |   24 +
> >   .../mt8186-corsola-tentacruel-sku262144.dts   |   44 +
> >   .../mt8186-corsola-tentacruel-sku262148.dts   |   26 +
> >   .../boot/dts/mediatek/mt8186-corsola.dtsi     | 1707 +++++++++++++++++
> >   7 files changed, 1991 insertions(+)
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-krabby.dtsi
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327681.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacool-sku327683.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262144.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> > index e6e7592a3645..442af61b1305 100644
> > --- a/arch/arm64/boot/dts/mediatek/Makefile
> > +++ b/arch/arm64/boot/dts/mediatek/Makefile
> > @@ -43,6 +43,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262148.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-evb.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r1.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-asurada-hayato-r5-sku2.dtb
>
> ..snip..
>
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > new file mode 100644
> > index 000000000000..447b57b12b41
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-tentacruel-sku262148.dts
> > @@ -0,0 +1,26 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2023 Google LLC
> > + */
> > +
> > +#include "mt8186-corsola-tentacruel-sku262144.dts"
> > +
> > +/ {
> > +     compatible = "google,tentacruel-sku262151", "google,tentacruel-sku262150",
> > +                  "google,tentacruel-sku262149", "google,tentacruel-sku262148",
> > +                  "google,tentacruel", "mediatek,mt8186";
> > +};
> > +
> > +/* This variant replaces only the trackpad controller. */
> > +&i2c2 {
> > +     /delete-node/ trackpad at 15;
> > +
> > +     trackpad at 15 {
> > +             compatible = "hid-over-i2c";
> > +             reg = <0x15>;
> > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > +             hid-descr-addr = <0x0001>;
> > +             vdd-supply = <&pp3300_s3>;
> > +             wakeup-source;
> > +     };
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > new file mode 100644
> > index 000000000000..adbeb0c765d3
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
> > @@ -0,0 +1,1707 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (C) 2022 MediaTek Inc.
> > + */
> > +/dts-v1/;
> > +#include "mt8186.dtsi"
> > +#include <dt-bindings/pinctrl/mt8186-pinfunc.h>
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/input/input.h>
> > +#include <dt-bindings/input/gpio-keys.h>
> > +#include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
> > +
>
> ..snip..
>
> > +
> > +&i2c2 {
> > +     pinctrl-names = "default";
> > +     /*
> > +      * Trackpad pin put here to work around second source components
> > +      * sharing the pinmux in steelix designs.
> > +      */
> > +     pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
> > +     clock-frequency = <400000>;
> > +     i2c-scl-internal-delay-ns = <10000>;
> > +     status = "okay";
> > +
> > +     trackpad at 15 {
> > +             compatible = "elan,ekth3000";
>
> You forgot to change this one.
>
> Remove compatible from this node and stop using /delete-node/ in device specific
> devicetrees.

I believe I already replied to the previous version why we can't and shouldn't
do that.

"elan,ekth3000" and "hid-over-i2c" have incompatible bindings, specifically
the former uses "vcc-supply" while the latter uses "vdd-supply".

One has to track down if a property is a "sharable" property or not,
then put it in the correct place, otherwise getting DT binding validation
errors.

To me it seems cleaner to just delete the node wholesale to not have any
remnants of the original node, i.e. start from a clean slate. Trying to
"share" common properties is asking for a headache.

This feels more like a preference thing. I also asked if deleting the node
through the label would be cleaner, but you didn't reply.

Also, "elan,ekth3000" is the one that was designed and tested on the Corsola
reference design, so I think it rightfully belongs there. The Tentacruel
SKU replaced it with another part, so the original part should be disabled,
or in this case, deleted, because otherwise there would be a conflict.


Regards
ChenYu



> > +             reg = <0x15>;
> > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > +             vcc-supply = <&pp3300_s3>;
> > +             wakeup-source;
> > +     };
> > +};
>
>
> corsola.dtsi (here):
>
> &i2c2 {
>         pinctrl-names = "default";
>         /*
>          * Trackpad pin put here to work around second source components
>          * sharing the pinmux in steelix designs.
>          */
>         pinctrl-0 = <&i2c2_pins>, <&trackpad_pin>;
>         clock-frequency = <400000>;
>         i2c-scl-internal-delay-ns = <10000>;
>         status = "okay";
>
>         trackpad_i2c2_15: trackpad at 15 {
>                 /*
>                  * Those are common properties for i2c2 trackpad on Corsola boards.
>                  * The compatible string is declared in device specific devicetrees
>                  */
>                 reg = <0x15>;
>                 interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
>                 vcc-supply = <&pp3300_s3>;
>                 wakeup-source;
>                 status = "disabled";
>         };
> };
>
> corsola-some-device.dts:
>
> &trackpad_i2c2_15 {
>         compatible = "hid-over-i2c";
>         hid-descr-addr = <0x0001>;
>         status = "okay";
> };
>
> corsola-some-other-device.dts:
>
> &trackpad_i2c2_15 {
>         compatible = "elan,ekth3000";
>         status = "okay";
> };
>
> ....everything else looks good.
>
> Cheers,
> Angelo


From dave.stevenson at raspberrypi.com  Thu Dec 14 06:39:51 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 14:39:51 +0000
Subject: [PATCH v5 06/44] drm/connector: Introduce an HDMI connector
 initialization function
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-6-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-6-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntCzdxJ5zyk4eeWV8D+WBdfri61ttoNxVtJUZSAKHoMpGQ@mail.gmail.com>

Hi Maxime

As requested, I'm just going through patches 6-16.
I will say that I've been less thorough in checking the kunit test
code in this series than the core code changes, and I'm trusting that
all the unit tests pass.

I get a build failure on the complete series for arm64 with the
standard defconfig
depmod: ERROR: Cycle detected: drm_display_helper -> drm_kms_helper ->
drm_display_helper
depmod: ERROR: Cycle detected: drm
depmod: ERROR: Found 2 modules in dependency cycles!

I haven't followed it through as to the reason, but obviously that
will need to be addressed.

  Dave

On Thu, 7 Dec 2023 at 15:49, Maxime Ripard <mripard at kernel.org> wrote:
>
> A lot of the various HDMI drivers duplicate some logic that depends on
> the HDMI spec itself and not really a particular hardware
> implementation.
>
> Output BPC or format selection, infoframe generation are good examples
> of such areas.
>
> This creates a lot of boilerplate, with a lot of variations, which makes
> it hard for userspace to rely on, and makes it difficult to get it right
> for drivers.
>
> In the next patches, we'll add a lot of infrastructure around the
> drm_connector and drm_connector_state structures, which will allow to
> abstract away the duplicated logic. This infrastructure comes with a few
> requirements though, and thus we need a new initialization function.
>
> Hopefully, this will make drivers simpler to handle, and their behaviour
> more consistent.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  drivers/gpu/drm/drm_connector.c            |  39 +++++++++
>  drivers/gpu/drm/tests/drm_connector_test.c | 123 +++++++++++++++++++++++++++++
>  include/drm/drm_connector.h                |   5 ++
>  3 files changed, 167 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b0516505f7ae..d9961cce8245 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -452,6 +452,45 @@ int drmm_connector_init(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drmm_connector_init);
>
> +/**
> + * drmm_connector_hdmi_init - Init a preallocated HDMI connector
> + * @dev: DRM device
> + * @connector: A pointer to the HDMI connector to init
> + * @funcs: callbacks for this connector
> + * @connector_type: user visible type of the connector
> + * @ddc: optional pointer to the associated ddc adapter
> + *
> + * Initialises a preallocated HDMI connector. Connectors can be
> + * subclassed as part of driver connector objects.
> + *
> + * Cleanup is automatically handled with a call to
> + * drm_connector_cleanup() in a DRM-managed action.
> + *
> + * The connector structure should be allocated with drmm_kzalloc().
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drmm_connector_hdmi_init(struct drm_device *dev,
> +                            struct drm_connector *connector,
> +                            const struct drm_connector_funcs *funcs,
> +                            int connector_type,
> +                            struct i2c_adapter *ddc)
> +{
> +       int ret;
> +
> +       if (!(connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> +             connector_type == DRM_MODE_CONNECTOR_HDMIB))
> +               return -EINVAL;
> +
> +       ret = drmm_connector_init(dev, connector, funcs, connector_type, ddc);
> +       if (ret)
> +               return ret;
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL(drmm_connector_hdmi_init);
> +
>  /**
>   * drm_connector_attach_edid_property - attach edid property.
>   * @connector: the connector
> diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
> index a268847be8d1..8f070cacab3b 100644
> --- a/drivers/gpu/drm/tests/drm_connector_test.c
> +++ b/drivers/gpu/drm/tests/drm_connector_test.c
> @@ -172,6 +172,128 @@ static struct kunit_suite drmm_connector_init_test_suite = {
>         .test_cases = drmm_connector_init_tests,
>  };
>
> +/*
> + * Test that the registration of a bog standard connector works as
> + * expected and doesn't report any error.
> + */
> +static void drm_test_connector_hdmi_init_valid(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      &priv->ddc);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +}
> +
> +/*
> + * Test that the registration of a connector without a DDC adapter
> + * doesn't report any error.
> + */
> +static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      NULL);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +}
> +
> +/*
> + * Test that the registration of an HDMI connector with an HDMI
> + * connector type succeeds.
> + */
> +static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       unsigned int connector_type = *(unsigned int *)test->param_value;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
> +                                      &dummy_funcs,
> +                                      connector_type,
> +                                      &priv->ddc);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +}
> +
> +static const unsigned int drm_connector_hdmi_init_type_valid_tests[] = {
> +       DRM_MODE_CONNECTOR_HDMIA,
> +       DRM_MODE_CONNECTOR_HDMIB,
> +};
> +
> +static void drm_connector_hdmi_init_type_desc(const unsigned int *type, char *desc)
> +{
> +       sprintf(desc, "%s", drm_get_connector_type_name(*type));
> +}
> +
> +KUNIT_ARRAY_PARAM(drm_connector_hdmi_init_type_valid,
> +                 drm_connector_hdmi_init_type_valid_tests,
> +                 drm_connector_hdmi_init_type_desc);
> +
> +/*
> + * Test that the registration of an HDMI connector with an !HDMI
> + * connector type fails.
> + */
> +static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       unsigned int connector_type = *(unsigned int *)test->param_value;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
> +                                      &dummy_funcs,
> +                                      connector_type,
> +                                      &priv->ddc);
> +       KUNIT_EXPECT_LT(test, ret, 0);
> +}
> +
> +static const unsigned int drm_connector_hdmi_init_type_invalid_tests[] = {
> +       DRM_MODE_CONNECTOR_Unknown,
> +       DRM_MODE_CONNECTOR_VGA,
> +       DRM_MODE_CONNECTOR_DVII,
> +       DRM_MODE_CONNECTOR_DVID,
> +       DRM_MODE_CONNECTOR_DVIA,
> +       DRM_MODE_CONNECTOR_Composite,
> +       DRM_MODE_CONNECTOR_SVIDEO,
> +       DRM_MODE_CONNECTOR_LVDS,
> +       DRM_MODE_CONNECTOR_Component,
> +       DRM_MODE_CONNECTOR_9PinDIN,
> +       DRM_MODE_CONNECTOR_DisplayPort,
> +       DRM_MODE_CONNECTOR_TV,
> +       DRM_MODE_CONNECTOR_eDP,
> +       DRM_MODE_CONNECTOR_VIRTUAL,
> +       DRM_MODE_CONNECTOR_DSI,
> +       DRM_MODE_CONNECTOR_DPI,
> +       DRM_MODE_CONNECTOR_WRITEBACK,
> +       DRM_MODE_CONNECTOR_SPI,
> +       DRM_MODE_CONNECTOR_USB,
> +};
> +
> +KUNIT_ARRAY_PARAM(drm_connector_hdmi_init_type_invalid,
> +                 drm_connector_hdmi_init_type_invalid_tests,
> +                 drm_connector_hdmi_init_type_desc);
> +
> +static struct kunit_case drmm_connector_hdmi_init_tests[] = {
> +       KUNIT_CASE(drm_test_connector_hdmi_init_valid),
> +       KUNIT_CASE(drm_test_connector_hdmi_init_null_ddc),
> +       KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_valid,
> +                        drm_connector_hdmi_init_type_valid_gen_params),
> +       KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_invalid,
> +                        drm_connector_hdmi_init_type_invalid_gen_params),
> +       { }
> +};
> +
> +static struct kunit_suite drmm_connector_hdmi_init_test_suite = {
> +       .name = "drmm_connector_hdmi_init",
> +       .init = drm_test_connector_init,
> +       .test_cases = drmm_connector_hdmi_init_tests,
> +};
> +
>  struct drm_get_tv_mode_from_name_test {
>         const char *name;
>         enum drm_connector_tv_mode expected_mode;
> @@ -236,6 +358,7 @@ static struct kunit_suite drm_get_tv_mode_from_name_test_suite = {
>  };
>
>  kunit_test_suites(
> +       &drmm_connector_hdmi_init_test_suite,
>         &drmm_connector_init_test_suite,
>         &drm_get_tv_mode_from_name_test_suite
>  );
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index fe88d7fc6b8f..4491c4c2fb6e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1904,6 +1904,11 @@ int drmm_connector_init(struct drm_device *dev,
>                         const struct drm_connector_funcs *funcs,
>                         int connector_type,
>                         struct i2c_adapter *ddc);
> +int drmm_connector_hdmi_init(struct drm_device *dev,
> +                            struct drm_connector *connector,
> +                            const struct drm_connector_funcs *funcs,
> +                            int connector_type,
> +                            struct i2c_adapter *ddc);
>  void drm_connector_attach_edid_property(struct drm_connector *connector);
>  int drm_connector_register(struct drm_connector *connector);
>  void drm_connector_unregister(struct drm_connector *connector);
>
> --
> 2.43.0
>


From dave.stevenson at raspberrypi.com  Thu Dec 14 06:40:52 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 14:40:52 +0000
Subject: [PATCH v5 07/44] drm/connector: hdmi: Create an HDMI sub-state
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-7-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-7-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntDT1X-2y7P-FAdw1CsT3SQuxCbfuhG6kPGR=v2KCnoQ8g@mail.gmail.com>

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> The next features we will need to share across drivers will need to
> store some parameters for drivers to use, such as the selected output
> format.
>
> Let's create a new connector sub-state dedicated to HDMI controllers,
> that will eventually store everything we need.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  drivers/gpu/drm/drm_atomic_state_helper.c | 35 +++++++++++++++++++++++++++++++
>  include/drm/drm_atomic_state_helper.h     |  4 ++++
>  include/drm/drm_connector.h               |  7 +++++++
>  3 files changed, 46 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 54975de44a0e..e69c0cc1c6da 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -570,6 +570,22 @@ void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
>
> +/**
> + * __drm_atomic_helper_connector_hdmi_reset() - Initializes all HDMI @drm_connector_state resources
> + * @connector: DRM connector
> + * @new_state: connector state to reset
> + *
> + * Initializes all HDMI resources from a @drm_connector_state without
> + * actually allocating it. This is useful for HDMI drivers, in
> + * combination with __drm_atomic_helper_connector_reset() or
> + * drm_atomic_helper_connector_reset().
> + */
> +void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
> +                                             struct drm_connector_state *new_state)
> +{
> +}
> +EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
> +
>  /**
>   * drm_atomic_helper_connector_tv_check - Validate an analog TV connector state
>   * @connector: DRM Connector
> @@ -619,6 +635,25 @@ int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
>
> +/**
> + * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
> + * @connector: DRM Connector
> + * @state: the DRM State object
> + *
> + * Provides a default connector state check handler for HDMI connectors.
> + * Checks that a desired connector update is valid, and updates various
> + * fields of derived state.
> + *
> + * RETURNS:
> + * Zero on success, or an errno code otherwise.
> + */
> +int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
> +                                          struct drm_atomic_state *state)
> +{
> +       return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_check);
> +
>  /**
>   * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
>   * @connector: connector object
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index b9740edb2658..d59d2b3aef9a 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -71,7 +71,11 @@ void __drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_
>  void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
>                                          struct drm_connector_state *conn_state);
>  void drm_atomic_helper_connector_reset(struct drm_connector *connector);
> +void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
> +                                             struct drm_connector_state *new_state);
>  void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
> +int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
> +                                          struct drm_atomic_state *state);
>  int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
>                                          struct drm_atomic_state *state);
>  void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector);
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 4491c4c2fb6e..000a2a156619 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1031,6 +1031,13 @@ struct drm_connector_state {
>          * DRM blob property for HDR output metadata
>          */
>         struct drm_property_blob *hdr_output_metadata;
> +
> +       /**
> +        * @hdmi: HDMI-related variable and properties. Filled by
> +        * @drm_atomic_helper_connector_hdmi_check().
> +        */
> +       struct {
> +       } hdmi;
>  };
>
>  /**
>
> --
> 2.43.0
>


From dave.stevenson at raspberrypi.com  Thu Dec 14 06:43:37 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 14:43:37 +0000
Subject: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-8-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-8-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntCs9EAYsxwjkscms3kqoC0N8+CcTHoyrG+gFMc0Mh=cwg@mail.gmail.com>

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> The i915 driver has a property to force the RGB range of an HDMI output.
> The vc4 driver then implemented the same property with the same
> semantics. KWin has support for it, and a PR for mutter is also there to
> support it.
>
> Both drivers implementing the same property with the same semantics,
> plus the userspace having support for it, is proof enough that it's
> pretty much a de-facto standard now and we can provide helpers for it.
>
> Let's plumb it into the newly created HDMI connector.

To have such a significant proportion of the patch being kunit tests
when there was no reference to such in the commit text was slightly
unexpected.

> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  Documentation/gpu/kms-properties.csv               |   1 -
>  drivers/gpu/drm/drm_atomic.c                       |   5 +
>  drivers/gpu/drm/drm_atomic_state_helper.c          |  17 +
>  drivers/gpu/drm/drm_atomic_uapi.c                  |   4 +
>  drivers/gpu/drm/drm_connector.c                    |  76 +++++
>  drivers/gpu/drm/tests/Makefile                     |   1 +
>  .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 376 +++++++++++++++++++++
>  drivers/gpu/drm/tests/drm_connector_test.c         | 117 ++++++-
>  drivers/gpu/drm/tests/drm_kunit_edid.h             | 106 ++++++
>  include/drm/drm_connector.h                        |  36 ++
>  10 files changed, 737 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv
> index 0f9590834829..caef14c532d4 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,7 +17,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,De
>  ,Virtual GPU,?suggested X?,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector
>  ,,?suggested Y?,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector
>  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB
> -i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normally in the range 0..1.0 are remapped to the range 16/255..235/255."
>  ,,?audio?,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
>  ,SDVO-TV,?mode?,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD
>  ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c31fc0b48c31..1465a7f09a0b 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1142,6 +1142,11 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
>         drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
>         drm_printf(p, "\tcolorspace=%s\n", drm_get_colorspace_name(state->colorspace));
>
> +       if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> +           connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)
> +               drm_printf(p, "\tbroadcast_rgb=%s\n",
> +                          drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
> +
>         if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
>                 if (state->writeback_job && state->writeback_job->fb)
>                         drm_printf(p, "\tfb=%d\n", state->writeback_job->fb->base.id);
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index e69c0cc1c6da..10d98620a358 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -583,6 +583,7 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
>  void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
>                                               struct drm_connector_state *new_state)
>  {
> +       new_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO;
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
>
> @@ -650,6 +651,22 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
>  int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
>                                            struct drm_atomic_state *state)
>  {
> +       struct drm_connector_state *old_state =
> +               drm_atomic_get_old_connector_state(state, connector);
> +       struct drm_connector_state *new_state =
> +               drm_atomic_get_new_connector_state(state, connector);
> +
> +       if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb) {
> +               struct drm_crtc *crtc = new_state->crtc;
> +               struct drm_crtc_state *crtc_state;
> +
> +               crtc_state = drm_atomic_get_crtc_state(state, crtc);
> +               if (IS_ERR(crtc_state))
> +                       return PTR_ERR(crtc_state);
> +
> +               crtc_state->mode_changed = true;
> +       }
> +
>         return 0;
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_check);
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index aee4a65d4959..3eb4f4bc8b71 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -818,6 +818,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>                 state->max_requested_bpc = val;
>         } else if (property == connector->privacy_screen_sw_state_property) {
>                 state->privacy_screen_sw_state = val;
> +       } else if (property == connector->broadcast_rgb_property) {
> +               state->hdmi.broadcast_rgb = val;
>         } else if (connector->funcs->atomic_set_property) {
>                 return connector->funcs->atomic_set_property(connector,
>                                 state, property, val);
> @@ -901,6 +903,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>                 *val = state->max_requested_bpc;
>         } else if (property == connector->privacy_screen_sw_state_property) {
>                 *val = state->privacy_screen_sw_state;
> +       } else if (property == connector->broadcast_rgb_property) {
> +               *val = state->hdmi.broadcast_rgb;
>         } else if (connector->funcs->atomic_get_property) {
>                 return connector->funcs->atomic_get_property(connector,
>                                 state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index d9961cce8245..929b0a911f62 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1183,6 +1183,29 @@ static const u32 dp_colorspaces =
>         BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
>         BIT(DRM_MODE_COLORIMETRY_BT2020_YCC);
>
> +static const struct drm_prop_enum_list broadcast_rgb_names[] = {
> +       { DRM_HDMI_BROADCAST_RGB_AUTO, "Automatic" },
> +       { DRM_HDMI_BROADCAST_RGB_FULL, "Full" },
> +       { DRM_HDMI_BROADCAST_RGB_LIMITED, "Limited 16:235" },
> +};
> +
> +/*
> + * drm_hdmi_connector_get_broadcast_rgb_name - Return a string for HDMI connector RGB broadcast selection
> + * @broadcast_rgb: Broadcast RGB selection to compute name of
> + *
> + * Returns: the name of the Broadcast RGB selection, or NULL if the type
> + * is not valid.
> + */
> +const char *
> +drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_rgb)
> +{
> +       if (broadcast_rgb > DRM_HDMI_BROADCAST_RGB_LIMITED)
> +               return NULL;
> +
> +       return broadcast_rgb_names[broadcast_rgb].name;
> +}
> +EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name);
> +
>  /**
>   * DOC: standard connector properties
>   *
> @@ -1655,6 +1678,26 @@ EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
>  /**
>   * DOC: HDMI connector properties
>   *
> + * Broadcast RGB
> + *      Indicates the RGB Quantization Range (Full vs Limited) used.
> + *      Infoframes will be generated according to that value.
> + *
> + *      The value of this property can be one of the following:
> + *
> + *      Automatic:
> + *              RGB Range is selected automatically based on the mode
> + *              according to the HDMI specifications.
> + *
> + *      Full:
> + *              Full RGB Range is forced.
> + *
> + *      Limited 16:235:
> + *              Limited RGB Range is forced. Unlike the name suggests,
> + *              this works for any number of bits-per-component.
> + *
> + *      Drivers can set up this property by calling
> + *      drm_connector_attach_broadcast_rgb_property().
> + *
>   * content type (HDMI specific):
>   *     Indicates content type setting to be used in HDMI infoframes to indicate
>   *     content type for the external device, so that it adjusts its display
> @@ -2517,6 +2560,39 @@ int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
>  }
>  EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
>
> +/**
> + * drm_connector_attach_broadcast_rgb_property - attach "Broadcast RGB" property
> + * @connector: connector to attach the property on.
> + *
> + * This is used to add support for forcing the RGB range on a connector
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_broadcast_rgb_property(struct drm_connector *connector)
> +{
> +       struct drm_device *dev = connector->dev;
> +       struct drm_property *prop;
> +
> +       prop = connector->broadcast_rgb_property;
> +       if (!prop) {
> +               prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
> +                                               "Broadcast RGB",
> +                                               broadcast_rgb_names,
> +                                               ARRAY_SIZE(broadcast_rgb_names));
> +               if (!prop)
> +                       return -EINVAL;
> +
> +               connector->broadcast_rgb_property = prop;
> +       }
> +
> +       drm_object_attach_property(&connector->base, prop,
> +                                  DRM_HDMI_BROADCAST_RGB_AUTO);
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_broadcast_rgb_property);
> +
>  /**
>   * drm_connector_attach_colorspace_property - attach "Colorspace" property
>   * @connector: connector to attach the property on.
> diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
> index d6183b3d7688..b29ddfd90596 100644
> --- a/drivers/gpu/drm/tests/Makefile
> +++ b/drivers/gpu/drm/tests/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST_HELPERS) += \
>         drm_kunit_helpers.o
>
>  obj-$(CONFIG_DRM_KUNIT_TEST) += \
> +       drm_atomic_state_helper_test.o \
>         drm_buddy_test.o \
>         drm_cmdline_parser_test.o \
>         drm_connector_test.o \
> diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> new file mode 100644
> index 000000000000..21e6f796ee13
> --- /dev/null
> +++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> @@ -0,0 +1,376 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Kunit test for drm_atomic_state_helper functions
> + */
> +
> +#include <drm/drm_atomic.h>
> +#include <drm/drm_atomic_state_helper.h>
> +#include <drm/drm_atomic_uapi.h>
> +#include <drm/drm_drv.h>
> +#include <drm/drm_edid.h>
> +#include <drm/drm_connector.h>
> +#include <drm/drm_fourcc.h>
> +#include <drm/drm_kunit_helpers.h>
> +#include <drm/drm_managed.h>
> +#include <drm/drm_modeset_helper_vtables.h>
> +#include <drm/drm_probe_helper.h>
> +
> +#include <drm/drm_print.h>
> +#include "../drm_crtc_internal.h"
> +
> +#include <kunit/test.h>
> +
> +#include "drm_kunit_edid.h"
> +
> +struct drm_atomic_helper_connector_hdmi_priv {
> +       struct drm_device drm;
> +       struct drm_plane *plane;
> +       struct drm_crtc *crtc;
> +       struct drm_encoder encoder;
> +       struct drm_connector connector;
> +
> +       const char *current_edid;
> +       size_t current_edid_len;
> +};
> +
> +#define connector_to_priv(c) \
> +       container_of_const(c, struct drm_atomic_helper_connector_hdmi_priv, connector)
> +
> +static struct drm_display_mode *find_preferred_mode(struct drm_connector *connector)
> +{
> +       struct drm_device *drm = connector->dev;
> +       struct drm_display_mode *mode, *preferred;
> +
> +       mutex_lock(&drm->mode_config.mutex);
> +       preferred = list_first_entry(&connector->modes, struct drm_display_mode, head);
> +       list_for_each_entry(mode, &connector->modes, head)
> +               if (mode->type & DRM_MODE_TYPE_PREFERRED)
> +                       preferred = mode;
> +       mutex_unlock(&drm->mode_config.mutex);
> +
> +       return preferred;
> +}
> +
> +static int light_up_connector(struct kunit *test,
> +                             struct drm_device *drm,
> +                             struct drm_crtc *crtc,
> +                             struct drm_connector *connector,
> +                             struct drm_display_mode *mode,
> +                             struct drm_modeset_acquire_ctx *ctx)
> +{
> +       struct drm_atomic_state *state;
> +       struct drm_connector_state *conn_state;
> +       struct drm_crtc_state *crtc_state;
> +       int ret;
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       conn_state = drm_atomic_get_connector_state(state, connector);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       ret = drm_atomic_set_crtc_for_connector(conn_state, crtc);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       crtc_state = drm_atomic_get_crtc_state(state, crtc);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
> +
> +       ret = drm_atomic_set_mode_for_crtc(crtc_state, mode);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       crtc_state->enable = true;
> +       crtc_state->active = true;
> +
> +       ret = drm_atomic_commit(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       return 0;
> +}
> +
> +static int set_connector_edid(struct kunit *test, struct drm_connector *connector,
> +                             const char *edid, size_t edid_len)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv =
> +               connector_to_priv(connector);
> +       struct drm_device *drm = connector->dev;
> +       int ret;
> +
> +       priv->current_edid = edid;
> +       priv->current_edid_len = edid_len;
> +
> +       mutex_lock(&drm->mode_config.mutex);
> +       ret = connector->funcs->fill_modes(connector, 4096, 4096);
> +       mutex_unlock(&drm->mode_config.mutex);
> +       KUNIT_ASSERT_GT(test, ret, 0);
> +
> +       return 0;
> +}
> +
> +static int dummy_connector_get_modes(struct drm_connector *connector)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv =
> +               connector_to_priv(connector);
> +       const struct drm_edid *edid;
> +       unsigned int num_modes;
> +
> +       edid = drm_edid_alloc(priv->current_edid, priv->current_edid_len);
> +       if (!edid)
> +               return -EINVAL;
> +
> +       drm_edid_connector_update(connector, edid);
> +       num_modes = drm_edid_connector_add_modes(connector);
> +
> +       drm_edid_free(edid);
> +
> +       return num_modes;
> +}
> +
> +static const struct drm_connector_helper_funcs dummy_connector_helper_funcs = {
> +       .atomic_check   = drm_atomic_helper_connector_hdmi_check,
> +       .get_modes      = dummy_connector_get_modes,
> +};
> +
> +static void dummy_hdmi_connector_reset(struct drm_connector *connector)
> +{
> +       drm_atomic_helper_connector_reset(connector);
> +       __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
> +}
> +
> +static const struct drm_connector_funcs dummy_connector_funcs = {
> +       .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
> +       .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> +       .fill_modes             = drm_helper_probe_single_connector_modes,
> +       .reset                  = dummy_hdmi_connector_reset,
> +};
> +
> +static
> +struct drm_atomic_helper_connector_hdmi_priv *
> +drm_atomic_helper_connector_hdmi_init(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_connector *conn;
> +       struct drm_encoder *enc;
> +       struct drm_device *drm;
> +       struct device *dev;
> +       int ret;
> +
> +       dev = drm_kunit_helper_alloc_device(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dev);
> +
> +       priv = drm_kunit_helper_alloc_drm_device(test, dev,
> +                                                struct drm_atomic_helper_connector_hdmi_priv, drm,
> +                                                DRIVER_MODESET | DRIVER_ATOMIC);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
> +       test->priv = priv;
> +
> +       drm = &priv->drm;
> +       priv->plane = drm_kunit_helper_create_primary_plane(test, drm,
> +                                                           NULL,
> +                                                           NULL,
> +                                                           NULL, 0,
> +                                                           NULL);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->plane);
> +
> +       priv->crtc = drm_kunit_helper_create_crtc(test, drm,
> +                                                 priv->plane, NULL,
> +                                                 NULL,
> +                                                 NULL);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->crtc);
> +
> +       enc = &priv->encoder;
> +       ret = drmm_encoder_init(drm, enc, NULL, DRM_MODE_ENCODER_TMDS, NULL);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       enc->possible_crtcs = drm_crtc_mask(priv->crtc);
> +
> +       conn = &priv->connector;
> +       ret = drmm_connector_hdmi_init(drm, conn,
> +                                      &dummy_connector_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      NULL);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       drm_connector_helper_add(conn, &dummy_connector_helper_funcs);
> +       drm_connector_attach_encoder(conn, enc);
> +
> +       drm_mode_config_reset(drm);
> +
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_max_200mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_200mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       return priv;
> +}
> +
> +/*
> + * Test that if we change the RGB quantization property to a different
> + * value, we trigger a mode change on the connector's CRTC, which will
> + * in turn disable/enable the connector.
> + */
> +static void drm_test_check_broadcast_rgb_crtc_mode_changed(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *old_conn_state;
> +       struct drm_connector_state *new_conn_state;
> +       struct drm_crtc_state *crtc_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       conn = &priv->connector;
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       new_conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
> +
> +       old_conn_state = drm_atomic_get_old_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
> +
> +       new_conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_FULL;
> +
> +       KUNIT_ASSERT_NE(test,
> +                       old_conn_state->hdmi.broadcast_rgb,
> +                       new_conn_state->hdmi.broadcast_rgb);
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       new_conn_state = drm_atomic_get_new_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
> +       KUNIT_EXPECT_EQ(test, new_conn_state->hdmi.broadcast_rgb, DRM_HDMI_BROADCAST_RGB_FULL);
> +
> +       crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
> +       KUNIT_EXPECT_TRUE(test, crtc_state->mode_changed);
> +}
> +
> +/*
> + * Test that if we set the RGB quantization property to the same value,
> + * we don't trigger a mode change on the connector's CRTC and leave the
> + * connector unaffected.
> + */
> +static void drm_test_check_broadcast_rgb_crtc_mode_not_changed(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *old_conn_state;
> +       struct drm_connector_state *new_conn_state;
> +       struct drm_crtc_state *crtc_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       conn = &priv->connector;
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       new_conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
> +
> +       old_conn_state = drm_atomic_get_old_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
> +
> +       new_conn_state->hdmi.broadcast_rgb = old_conn_state->hdmi.broadcast_rgb;
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       old_conn_state = drm_atomic_get_old_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
> +
> +       new_conn_state = drm_atomic_get_new_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
> +
> +       KUNIT_EXPECT_EQ(test,
> +                       old_conn_state->hdmi.broadcast_rgb,
> +                       new_conn_state->hdmi.broadcast_rgb);
> +
> +       crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
> +       KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
> +}
> +
> +static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
> +       KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
> +       KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
> +       { }
> +};
> +
> +static struct kunit_suite drm_atomic_helper_connector_hdmi_check_test_suite = {
> +       .name           = "drm_atomic_helper_connector_hdmi_check",
> +       .test_cases     = drm_atomic_helper_connector_hdmi_check_tests,
> +};
> +
> +/*
> + * Test that the value of the Broadcast RGB property out of reset is set
> + * to auto.
> + */
> +static void drm_test_check_broadcast_rgb_value(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_connector_state *conn_state;
> +       struct drm_connector *conn;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       conn_state = conn->state;
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.broadcast_rgb, DRM_HDMI_BROADCAST_RGB_AUTO);
> +}
> +
> +static struct kunit_case drm_atomic_helper_connector_hdmi_reset_tests[] = {
> +       KUNIT_CASE(drm_test_check_broadcast_rgb_value),
> +       { }
> +};
> +
> +static struct kunit_suite drm_atomic_helper_connector_hdmi_reset_test_suite = {
> +       .name           = "drm_atomic_helper_connector_hdmi_reset",
> +       .test_cases     = drm_atomic_helper_connector_hdmi_reset_tests,
> +};
> +
> +kunit_test_suites(
> +       &drm_atomic_helper_connector_hdmi_check_test_suite,
> +       &drm_atomic_helper_connector_hdmi_reset_test_suite,
> +);
> +
> +MODULE_AUTHOR("Maxime Ripard <mripard at kernel.org>");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
> index 8f070cacab3b..41d33dea30af 100644
> --- a/drivers/gpu/drm/tests/drm_connector_test.c
> +++ b/drivers/gpu/drm/tests/drm_connector_test.c
> @@ -12,6 +12,8 @@
>
>  #include <kunit/test.h>
>
> +#include "../drm_crtc_internal.h"
> +
>  struct drm_connector_init_priv {
>         struct drm_device drm;
>         struct drm_connector connector;
> @@ -357,10 +359,123 @@ static struct kunit_suite drm_get_tv_mode_from_name_test_suite = {
>         .test_cases = drm_get_tv_mode_from_name_tests,
>  };
>
> +struct drm_hdmi_connector_get_broadcast_rgb_name_test {
> +       unsigned int kind;
> +       const char *expected_name;
> +};
> +
> +#define BROADCAST_RGB_TEST(_kind, _name)       \
> +       {                                       \
> +               .kind = _kind,                  \
> +               .expected_name = _name,         \
> +       }
> +
> +static void drm_test_drm_hdmi_connector_get_broadcast_rgb_name(struct kunit *test)
> +{
> +       const struct drm_hdmi_connector_get_broadcast_rgb_name_test *params =
> +               test->param_value;
> +
> +       KUNIT_EXPECT_STREQ(test,
> +                          drm_hdmi_connector_get_broadcast_rgb_name(params->kind),
> +                          params->expected_name);
> +}
> +
> +static const
> +struct drm_hdmi_connector_get_broadcast_rgb_name_test
> +drm_hdmi_connector_get_broadcast_rgb_name_valid_tests[] = {
> +       BROADCAST_RGB_TEST(DRM_HDMI_BROADCAST_RGB_AUTO, "Automatic"),
> +       BROADCAST_RGB_TEST(DRM_HDMI_BROADCAST_RGB_FULL, "Full"),
> +       BROADCAST_RGB_TEST(DRM_HDMI_BROADCAST_RGB_LIMITED, "Limited 16:235"),
> +};
> +
> +static void
> +drm_hdmi_connector_get_broadcast_rgb_name_valid_desc(const struct drm_hdmi_connector_get_broadcast_rgb_name_test *t,
> +                                                    char *desc)
> +{
> +       sprintf(desc, "%s", t->expected_name);
> +}
> +
> +KUNIT_ARRAY_PARAM(drm_hdmi_connector_get_broadcast_rgb_name_valid,
> +                 drm_hdmi_connector_get_broadcast_rgb_name_valid_tests,
> +                 drm_hdmi_connector_get_broadcast_rgb_name_valid_desc);
> +
> +static void drm_test_drm_hdmi_connector_get_broadcast_rgb_name_invalid(struct kunit *test)
> +{
> +       KUNIT_EXPECT_NULL(test, drm_hdmi_connector_get_broadcast_rgb_name(3));
> +};
> +
> +static struct kunit_case drm_hdmi_connector_get_broadcast_rgb_name_tests[] = {
> +       KUNIT_CASE_PARAM(drm_test_drm_hdmi_connector_get_broadcast_rgb_name,
> +                        drm_hdmi_connector_get_broadcast_rgb_name_valid_gen_params),
> +       KUNIT_CASE(drm_test_drm_hdmi_connector_get_broadcast_rgb_name_invalid),
> +       { }
> +};
> +
> +static struct kunit_suite drm_hdmi_connector_get_broadcast_rgb_name_test_suite = {
> +       .name = "drm_hdmi_connector_get_broadcast_rgb_name",
> +       .test_cases = drm_hdmi_connector_get_broadcast_rgb_name_tests,
> +};
> +
> +static void drm_test_drm_connector_attach_broadcast_rgb_property(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       struct drm_connector *connector = &priv->connector;
> +       struct drm_property *prop;
> +       int ret;
> +
> +       ret = drmm_connector_init(&priv->drm, connector,
> +                                 &dummy_funcs,
> +                                 DRM_MODE_CONNECTOR_HDMIA,
> +                                 &priv->ddc);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       ret = drm_connector_attach_broadcast_rgb_property(connector);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       prop = connector->broadcast_rgb_property;
> +       KUNIT_ASSERT_NOT_NULL(test, prop);
> +       KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
> +}
> +
> +static void drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       struct drm_connector *connector = &priv->connector;
> +       struct drm_property *prop;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      &priv->ddc);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       ret = drm_connector_attach_broadcast_rgb_property(connector);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       prop = connector->broadcast_rgb_property;
> +       KUNIT_ASSERT_NOT_NULL(test, prop);
> +       KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
> +}
> +
> +static struct kunit_case drm_connector_attach_broadcast_rgb_property_tests[] = {
> +       KUNIT_CASE(drm_test_drm_connector_attach_broadcast_rgb_property),
> +       KUNIT_CASE(drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector),
> +       { }
> +};
> +
> +static struct kunit_suite drm_connector_attach_broadcast_rgb_property_test_suite = {
> +       .name = "drm_connector_attach_broadcast_rgb_property",
> +       .init = drm_test_connector_init,
> +       .test_cases = drm_connector_attach_broadcast_rgb_property_tests,
> +};
> +
>  kunit_test_suites(
>         &drmm_connector_hdmi_init_test_suite,
>         &drmm_connector_init_test_suite,
> -       &drm_get_tv_mode_from_name_test_suite
> +       &drm_connector_attach_broadcast_rgb_property_test_suite,
> +       &drm_get_tv_mode_from_name_test_suite,
> +       &drm_hdmi_connector_get_broadcast_rgb_name_test_suite
>  );
>
>  MODULE_AUTHOR("Maxime Ripard <maxime at cerno.tech>");
> diff --git a/drivers/gpu/drm/tests/drm_kunit_edid.h b/drivers/gpu/drm/tests/drm_kunit_edid.h
> new file mode 100644
> index 000000000000..2bba316de064
> --- /dev/null
> +++ b/drivers/gpu/drm/tests/drm_kunit_edid.h
> @@ -0,0 +1,106 @@
> +#ifndef DRM_KUNIT_EDID_H_
> +#define DRM_KUNIT_EDID_H_
> +
> +/*
> + * edid-decode (hex):
> + *
> + * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
> + * 00 21 01 03 81 a0 5a 78 02 00 00 00 00 00 00 00
> + * 00 00 00 20 00 00 01 01 01 01 01 01 01 01 01 01
> + * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
> + * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
> + * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
> + * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 92
> + *
> + * 02 03 1b 81 e3 05 00 20 41 10 e2 00 4a 6d 03 0c
> + * 00 12 34 00 28 20 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0
> + *
> + * ----------------
> + *
> + * Block 0, Base EDID:
> + *   EDID Structure Version & Revision: 1.3
> + *   Vendor & Product Identification:
> + *     Manufacturer: LNX
> + *     Model: 42
> + *     Made in: 2023
> + *   Basic Display Parameters & Features:
> + *     Digital display
> + *     DFP 1.x compatible TMDS
> + *     Maximum image size: 160 cm x 90 cm
> + *     Gamma: 2.20
> + *     Monochrome or grayscale display
> + *     First detailed timing is the preferred timing
> + *   Color Characteristics:
> + *     Red  : 0.0000, 0.0000
> + *     Green: 0.0000, 0.0000
> + *     Blue : 0.0000, 0.0000
> + *     White: 0.0000, 0.0000
> + *   Established Timings I & II:
> + *     DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
> + *   Standard Timings: none
> + *   Detailed Timing Descriptors:
> + *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
> + *                  Hfront   88 Hsync  44 Hback  148 Hpol P
> + *                  Vfront    4 Vsync   5 Vback   36 Vpol P
> + *     Display Product Name: 'Test EDID'
> + *     Display Range Limits:
> + *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
> + *     Dummy Descriptor:
> + *   Extension blocks: 1
> + * Checksum: 0x92
> + *
> + * ----------------
> + *
> + * Block 1, CTA-861 Extension Block:
> + *   Revision: 3
> + *   Underscans IT Video Formats by default
> + *   Native detailed modes: 1
> + *   Colorimetry Data Block:
> + *     sRGB
> + *   Video Data Block:
> + *     VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
> + *   Video Capability Data Block:
> + *     YCbCr quantization: No Data
> + *     RGB quantization: Selectable (via AVI Q)
> + *     PT scan behavior: No Data
> + *     IT scan behavior: Always Underscanned
> + *     CE scan behavior: Always Underscanned
> + *   Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
> + *     Source physical address: 1.2.3.4
> + *     Maximum TMDS clock: 200 MHz
> + *     Extended HDMI video details:
> + * Checksum: 0xd0  Unused space in Extension Block: 100 bytes
> + */
> +const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz[] = {
> +  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
> +  0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20,
> +  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
> +  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
> +  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
> +  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
> +  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
> +  0x46, 0x00, 0x00, 0xc4, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
> +  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x41, 0x02, 0x03, 0x1b, 0x81,
> +  0xe3, 0x05, 0x00, 0x20, 0x41, 0x10, 0xe2, 0x00, 0x4a, 0x6d, 0x03, 0x0c,
> +  0x00, 0x12, 0x34, 0x00, 0x28, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0xd0
> +};
> +
> +#endif // DRM_KUNIT_EDID_H_
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 000a2a156619..3867a4c01b78 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -368,6 +368,30 @@ enum drm_panel_orientation {
>         DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>  };
>
> +/**
> + * enum drm_hdmi_broadcast_rgb - Broadcast RGB Selection for an HDMI @drm_connector
> + */
> +enum drm_hdmi_broadcast_rgb {
> +       /**
> +        * @DRM_HDMI_BROADCAST_RGB_AUTO: The RGB range is selected
> +        * automatically based on the mode.
> +        */
> +       DRM_HDMI_BROADCAST_RGB_AUTO,
> +
> +       /**
> +        * @DRM_HDMI_BROADCAST_RGB_FULL: Full range RGB is forced.
> +        */
> +       DRM_HDMI_BROADCAST_RGB_FULL,
> +
> +       /**
> +        * @DRM_HDMI_BROADCAST_RGB_LIMITED: Limited range RGB is forced.
> +        */
> +       DRM_HDMI_BROADCAST_RGB_LIMITED,
> +};
> +
> +const char *
> +drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_rgb);
> +
>  /**
>   * struct drm_monitor_range_info - Panel's Monitor range in EDID for
>   * &drm_display_info
> @@ -1037,6 +1061,11 @@ struct drm_connector_state {
>          * @drm_atomic_helper_connector_hdmi_check().
>          */
>         struct {
> +               /**
> +                * @broadcast_rgb: Connector property to pass the
> +                * Broadcast RGB selection value.
> +                */
> +               enum drm_hdmi_broadcast_rgb broadcast_rgb;
>         } hdmi;
>  };
>
> @@ -1706,6 +1735,12 @@ struct drm_connector {
>          */
>         struct drm_property *privacy_screen_hw_state_property;
>
> +       /**
> +        * @broadcast_rgb_property: Connector property to set the
> +        * Broadcast RGB selection to output with.
> +        */
> +       struct drm_property *broadcast_rgb_property;
> +
>  #define DRM_CONNECTOR_POLL_HPD (1 << 0)
>  #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
>  #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> @@ -2026,6 +2061,7 @@ int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
>                                                u32 scaling_mode_mask);
>  int drm_connector_attach_vrr_capable_property(
>                 struct drm_connector *connector);
> +int drm_connector_attach_broadcast_rgb_property(struct drm_connector *connector);
>  int drm_connector_attach_colorspace_property(struct drm_connector *connector);
>  int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *connector);
>  bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state *old_state,
>
> --
> 2.43.0
>


From dave.stevenson at raspberrypi.com  Thu Dec 14 06:46:08 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 14:46:08 +0000
Subject: [PATCH v5 09/44] drm/connector: hdmi: Add RGB Quantization Range
 to the connector state
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-9-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-9-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntDZ+M-5Ke4oHaM3gO2BrvUxDnne3ezV6AchxFJRQPd9Cw@mail.gmail.com>

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> HDMI controller drivers will need to figure out the RGB range they need
> to configure based on a mode and property values. Let's expose that in
> the HDMI connector state so drivers can just use that value.

Again a mention that we're also adding unit tests wouldn't be amiss.

> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  drivers/gpu/drm/drm_atomic.c                       |   4 +-
>  drivers/gpu/drm/drm_atomic_state_helper.c          |  44 +++
>  .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 335 +++++++++++++++++++++
>  include/drm/drm_atomic_state_helper.h              |   1 +
>  include/drm/drm_connector.h                        |   6 +
>  5 files changed, 389 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 1465a7f09a0b..e4ad53e64e07 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1143,9 +1143,11 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
>         drm_printf(p, "\tcolorspace=%s\n", drm_get_colorspace_name(state->colorspace));
>
>         if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> -           connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)
> +           connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
>                 drm_printf(p, "\tbroadcast_rgb=%s\n",
>                            drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
> +               drm_printf(p, "\tis_full_range=%c\n", state->hdmi.is_full_range ? 'y' : 'n');
> +       }
>
>         if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
>                 if (state->writeback_job && state->writeback_job->fb)
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 10d98620a358..4a7114978c47 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -31,6 +31,7 @@
>  #include <drm/drm_connector.h>
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_device.h>
> +#include <drm/drm_edid.h>
>  #include <drm/drm_framebuffer.h>
>  #include <drm/drm_plane.h>
>  #include <drm/drm_print.h>
> @@ -636,6 +637,47 @@ int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
>
> +static const struct drm_display_mode *
> +connector_state_get_mode(const struct drm_connector_state *conn_state)
> +{
> +       struct drm_atomic_state *state;
> +       struct drm_crtc_state *crtc_state;
> +       struct drm_crtc *crtc;
> +
> +       state = conn_state->state;
> +       if (!state)
> +               return NULL;
> +
> +       crtc = conn_state->crtc;
> +       if (!crtc)
> +               return NULL;
> +
> +       crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> +       if (!crtc_state)
> +               return NULL;
> +
> +       return &crtc_state->mode;
> +}
> +
> +static bool hdmi_is_full_range(const struct drm_connector *connector,
> +                              const struct drm_connector_state *state)
> +{
> +       const struct drm_display_info *display = &connector->display_info;
> +       const struct drm_display_mode *mode =
> +               connector_state_get_mode(state);
> +
> +       if (state->hdmi.broadcast_rgb == DRM_HDMI_BROADCAST_RGB_FULL)
> +               return true;
> +
> +       if (state->hdmi.broadcast_rgb == DRM_HDMI_BROADCAST_RGB_LIMITED)
> +               return false;
> +
> +       if (!display->is_hdmi)
> +               return true;
> +
> +       return drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_FULL ? true : false;
> +}
> +
>  /**
>   * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
>   * @connector: DRM Connector
> @@ -656,6 +698,8 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
>         struct drm_connector_state *new_state =
>                 drm_atomic_get_new_connector_state(state, connector);
>
> +       new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
> +
>         if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb) {
>                 struct drm_crtc *crtc = new_state->crtc;
>                 struct drm_crtc_state *crtc_state;
> diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> index 21e6f796ee13..7750c3d214a4 100644
> --- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> @@ -328,7 +328,342 @@ static void drm_test_check_broadcast_rgb_crtc_mode_not_changed(struct kunit *tes
>         KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
>  }
>
> +/*
> + * Test that for an HDMI connector, with an HDMI monitor, if the
> + * Broadcast RGB property is set to auto with a mode that isn't the
> + * VIC-1 mode, we will get a limited RGB Quantization Range.
> + */
> +static void drm_test_check_broadcast_rgb_auto_cea_mode(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +       KUNIT_ASSERT_NE(test, drm_match_cea_mode(preferred), 1);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       KUNIT_ASSERT_EQ(test,
> +                       conn_state->hdmi.broadcast_rgb,
> +                       DRM_HDMI_BROADCAST_RGB_AUTO);
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_FALSE(test, conn_state->hdmi.is_full_range);
> +}
> +
> +/*
> + * Test that for an HDMI connector, with an HDMI monitor, if the
> + * Broadcast RGB property is set to auto with a VIC-1 mode, we will get
> + * a full RGB Quantization Range.
> + */
> +static void drm_test_check_broadcast_rgb_auto_cea_mode_vic_1(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *mode;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 1);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, mode, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       KUNIT_ASSERT_EQ(test,
> +                       conn_state->hdmi.broadcast_rgb,
> +                       DRM_HDMI_BROADCAST_RGB_AUTO);
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_TRUE(test, conn_state->hdmi.is_full_range);
> +}
> +
> +/*
> + * Test that for an HDMI connector, with an HDMI monitor, if the
> + * Broadcast RGB property is set to full with a mode that isn't the
> + * VIC-1 mode, we will get a full RGB Quantization Range.
> + */
> +static void drm_test_check_broadcast_rgb_full_cea_mode(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +       KUNIT_ASSERT_NE(test, drm_match_cea_mode(preferred), 1);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_FULL;
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       KUNIT_ASSERT_EQ(test,
> +                       conn_state->hdmi.broadcast_rgb,
> +                       DRM_HDMI_BROADCAST_RGB_FULL);
> +
> +       KUNIT_EXPECT_TRUE(test, conn_state->hdmi.is_full_range);
> +}
> +
> +/*
> + * Test that for an HDMI connector, with an HDMI monitor, if the
> + * Broadcast RGB property is set to full with a VIC-1 mode, we will get
> + * a full RGB Quantization Range.
> + */
> +static void drm_test_check_broadcast_rgb_full_cea_mode_vic_1(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *mode;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 1);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, mode, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_FULL;
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       KUNIT_ASSERT_EQ(test,
> +                       conn_state->hdmi.broadcast_rgb,
> +                       DRM_HDMI_BROADCAST_RGB_FULL);
> +
> +       KUNIT_EXPECT_TRUE(test, conn_state->hdmi.is_full_range);
> +}
> +
> +/*
> + * Test that for an HDMI connector, with an HDMI monitor, if the
> + * Broadcast RGB property is set to limited with a mode that isn't the
> + * VIC-1 mode, we will get a limited RGB Quantization Range.
> + */
> +static void drm_test_check_broadcast_rgb_limited_cea_mode(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +       KUNIT_ASSERT_NE(test, drm_match_cea_mode(preferred), 1);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_LIMITED;
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       KUNIT_ASSERT_EQ(test,
> +                       conn_state->hdmi.broadcast_rgb,
> +                       DRM_HDMI_BROADCAST_RGB_LIMITED);
> +
> +       KUNIT_EXPECT_FALSE(test, conn_state->hdmi.is_full_range);
> +}
> +
> +/*
> + * Test that for an HDMI connector, with an HDMI monitor, if the
> + * Broadcast RGB property is set to limited with a VIC-1 mode, we will
> + * get a limited RGB Quantization Range.
> + */
> +static void drm_test_check_broadcast_rgb_limited_cea_mode_vic_1(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *mode;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       KUNIT_ASSERT_TRUE(test, conn->display_info.is_hdmi);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 1);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, mode, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_LIMITED;
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
> +
> +       KUNIT_ASSERT_EQ(test,
> +                       conn_state->hdmi.broadcast_rgb,
> +                       DRM_HDMI_BROADCAST_RGB_LIMITED);
> +
> +       KUNIT_EXPECT_FALSE(test, conn_state->hdmi.is_full_range);
> +}
> +
>  static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
> +       KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
> +       KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
> +       KUNIT_CASE(drm_test_check_broadcast_rgb_full_cea_mode),
> +       KUNIT_CASE(drm_test_check_broadcast_rgb_full_cea_mode_vic_1),
> +       KUNIT_CASE(drm_test_check_broadcast_rgb_limited_cea_mode),
> +       KUNIT_CASE(drm_test_check_broadcast_rgb_limited_cea_mode_vic_1),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
>         { }
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index d59d2b3aef9a..8072ac18e536 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -88,6 +88,7 @@ void
>  __drm_atomic_helper_connector_destroy_state(struct drm_connector_state *state);
>  void drm_atomic_helper_connector_destroy_state(struct drm_connector *connector,
>                                           struct drm_connector_state *state);
> +
>  void __drm_atomic_helper_private_obj_duplicate_state(struct drm_private_obj *obj,
>                                                      struct drm_private_state *state);
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 3867a4c01b78..76eecd449fb8 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1066,6 +1066,12 @@ struct drm_connector_state {
>                  * Broadcast RGB selection value.
>                  */
>                 enum drm_hdmi_broadcast_rgb broadcast_rgb;
> +
> +               /**
> +                * @is_full_range: Is the output supposed to use a full
> +                * RGB Quantization Range or not?
> +                */
> +               bool is_full_range;
>         } hdmi;
>  };
>
>
> --
> 2.43.0
>


From dave.stevenson at raspberrypi.com  Thu Dec 14 06:48:44 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 14:48:44 +0000
Subject: [PATCH v5 10/44] drm/connector: hdmi: Add output BPC to the
 connector state
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-10-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-10-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntAZY1mULjd82694Qc868iLXOdopu2jf8VPyWnFe0=rK8w@mail.gmail.com>

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> We'll add automatic selection of the output BPC in a following patch,
> but let's add it to the HDMI connector state already.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  drivers/gpu/drm/drm_atomic.c                       |   1 +
>  drivers/gpu/drm/drm_atomic_state_helper.c          |   7 +-
>  drivers/gpu/drm/drm_connector.c                    |  20 +-
>  .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 227 ++++++++++++++++++++-
>  drivers/gpu/drm/tests/drm_connector_test.c         | 153 +++++++++++++-
>  include/drm/drm_connector.h                        |  13 +-
>  6 files changed, 402 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index e4ad53e64e07..76c63ed04af4 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1147,6 +1147,7 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
>                 drm_printf(p, "\tbroadcast_rgb=%s\n",
>                            drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
>                 drm_printf(p, "\tis_full_range=%c\n", state->hdmi.is_full_range ? 'y' : 'n');
> +               drm_printf(p, "\toutput_bpc=%u\n", state->hdmi.output_bpc);
>         }
>
>         if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 4a7114978c47..883bdc0349c0 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -584,6 +584,10 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
>  void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
>                                               struct drm_connector_state *new_state)
>  {
> +       unsigned int max_bpc = connector->max_bpc;
> +
> +       new_state->max_bpc = max_bpc;
> +       new_state->max_requested_bpc = max_bpc;
>         new_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO;
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
> @@ -700,7 +704,8 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
>
>         new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
>
> -       if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb) {
> +       if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb ||
> +           old_state->hdmi.output_bpc != new_state->hdmi.output_bpc) {
>                 struct drm_crtc *crtc = new_state->crtc;
>                 struct drm_crtc_state *crtc_state;
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 929b0a911f62..139ac3d8160c 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -459,6 +459,7 @@ EXPORT_SYMBOL(drmm_connector_init);
>   * @funcs: callbacks for this connector
>   * @connector_type: user visible type of the connector
>   * @ddc: optional pointer to the associated ddc adapter
> + * @max_bpc: Maximum bits per char the HDMI connector supports
>   *
>   * Initialises a preallocated HDMI connector. Connectors can be
>   * subclassed as part of driver connector objects.
> @@ -475,7 +476,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
>                              struct drm_connector *connector,
>                              const struct drm_connector_funcs *funcs,
>                              int connector_type,
> -                            struct i2c_adapter *ddc)
> +                            struct i2c_adapter *ddc,
> +                            unsigned int max_bpc)
>  {
>         int ret;
>
> @@ -483,10 +485,26 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
>               connector_type == DRM_MODE_CONNECTOR_HDMIB))
>                 return -EINVAL;
>
> +       if (!(max_bpc == 8 || max_bpc == 10 || max_bpc == 12))
> +               return -EINVAL;
> +
>         ret = drmm_connector_init(dev, connector, funcs, connector_type, ddc);
>         if (ret)
>                 return ret;
>
> +       /*
> +        * drm_connector_attach_max_bpc_property() requires the
> +        * connector to have a state.
> +        */
> +       if (connector->funcs->reset)
> +               connector->funcs->reset(connector);
> +
> +       drm_connector_attach_max_bpc_property(connector, 8, max_bpc);
> +       connector->max_bpc = max_bpc;
> +
> +       if (max_bpc > 8)
> +               drm_connector_attach_hdr_output_metadata_property(connector);
> +
>         return 0;
>  }
>  EXPORT_SYMBOL(drmm_connector_hdmi_init);
> diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> index 7750c3d214a4..a1b0e6914cf8 100644
> --- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> @@ -146,7 +146,8 @@ static const struct drm_connector_funcs dummy_connector_funcs = {
>
>  static
>  struct drm_atomic_helper_connector_hdmi_priv *
> -drm_atomic_helper_connector_hdmi_init(struct kunit *test)
> +drm_atomic_helper_connector_hdmi_init(struct kunit *test,
> +                                     unsigned int max_bpc)
>  {
>         struct drm_atomic_helper_connector_hdmi_priv *priv;
>         struct drm_connector *conn;
> @@ -188,7 +189,8 @@ drm_atomic_helper_connector_hdmi_init(struct kunit *test)
>         ret = drmm_connector_hdmi_init(drm, conn,
>                                        &dummy_connector_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
> -                                      NULL);
> +                                      NULL,
> +                                      max_bpc);
>         KUNIT_ASSERT_EQ(test, ret, 0);
>
>         drm_connector_helper_add(conn, &dummy_connector_helper_funcs);
> @@ -223,7 +225,7 @@ static void drm_test_check_broadcast_rgb_crtc_mode_changed(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> @@ -284,7 +286,7 @@ static void drm_test_check_broadcast_rgb_crtc_mode_not_changed(struct kunit *tes
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> @@ -345,7 +347,7 @@ static void drm_test_check_broadcast_rgb_auto_cea_mode(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -399,7 +401,7 @@ static void drm_test_check_broadcast_rgb_auto_cea_mode_vic_1(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -452,7 +454,7 @@ static void drm_test_check_broadcast_rgb_full_cea_mode(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -508,7 +510,7 @@ static void drm_test_check_broadcast_rgb_full_cea_mode_vic_1(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -563,7 +565,7 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -619,7 +621,7 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode_vic_1(struct kunit *te
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -657,6 +659,138 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode_vic_1(struct kunit *te
>         KUNIT_EXPECT_FALSE(test, conn_state->hdmi.is_full_range);
>  }
>
> +/*
> + * Test that if we change the maximum bpc property to a different value,
> + * we trigger a mode change on the connector's CRTC, which will in turn
> + * disable/enable the connector.
> + */
> +static void drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *old_conn_state;
> +       struct drm_connector_state *new_conn_state;
> +       struct drm_crtc_state *crtc_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 10);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       conn = &priv->connector;
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       new_conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
> +
> +       old_conn_state = drm_atomic_get_old_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
> +
> +       new_conn_state->hdmi.output_bpc = 8;
> +
> +       KUNIT_ASSERT_NE(test,
> +                       old_conn_state->hdmi.output_bpc,
> +                       new_conn_state->hdmi.output_bpc);
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       old_conn_state = drm_atomic_get_old_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
> +
> +       new_conn_state = drm_atomic_get_new_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
> +
> +       KUNIT_ASSERT_NE(test,
> +                       old_conn_state->hdmi.output_bpc,
> +                       new_conn_state->hdmi.output_bpc);
> +
> +       crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
> +       KUNIT_EXPECT_TRUE(test, crtc_state->mode_changed);
> +}
> +
> +/*
> + * Test that if we set the output bpc property to the same value, we
> + * don't trigger a mode change on the connector's CRTC and leave the
> + * connector unaffected.
> + */
> +static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *old_conn_state;
> +       struct drm_connector_state *new_conn_state;
> +       struct drm_crtc_state *crtc_state;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 10);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       conn = &priv->connector;
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       new_conn_state = drm_atomic_get_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
> +
> +       old_conn_state = drm_atomic_get_old_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
> +
> +       KUNIT_ASSERT_EQ(test,
> +                       new_conn_state->hdmi.output_bpc,
> +                       old_conn_state->hdmi.output_bpc);
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       old_conn_state = drm_atomic_get_old_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
> +
> +       new_conn_state = drm_atomic_get_new_connector_state(state, conn);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, new_conn_state);
> +
> +       KUNIT_EXPECT_EQ(test,
> +                       old_conn_state->hdmi.output_bpc,
> +                       new_conn_state->hdmi.output_bpc);
> +
> +       crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
> +       KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
> +}
> +
>  static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
> @@ -666,6 +800,8 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_limited_cea_mode_vic_1),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
> +       KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
> +       KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
>         { }
>  };
>
> @@ -684,7 +820,7 @@ static void drm_test_check_broadcast_rgb_value(struct kunit *test)
>         struct drm_connector_state *conn_state;
>         struct drm_connector *conn;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test);
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -692,8 +828,77 @@ static void drm_test_check_broadcast_rgb_value(struct kunit *test)
>         KUNIT_EXPECT_EQ(test, conn_state->hdmi.broadcast_rgb, DRM_HDMI_BROADCAST_RGB_AUTO);
>  }
>
> +/*
> + * Test that if the connector was initialised with a maximum bpc of 8,
> + * the value of the max_bpc and max_requested_bpc properties out of
> + * reset are also set to 8, and output_bpc is set to 0 and will be
> + * filled at atomic_check time.
> + */
> +static void drm_test_check_bpc_8_value(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_connector_state *conn_state;
> +       struct drm_connector *conn;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       conn_state = conn->state;
> +       KUNIT_EXPECT_EQ(test, conn_state->max_bpc, 8);
> +       KUNIT_EXPECT_EQ(test, conn_state->max_requested_bpc, 8);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 0);
> +}
> +
> +/*
> + * Test that if the connector was initialised with a maximum bpc of 10,
> + * the value of the max_bpc and max_requested_bpc properties out of
> + * reset are also set to 10, and output_bpc is set to 0 and will be
> + * filled at atomic_check time.
> + */
> +static void drm_test_check_bpc_10_value(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_connector_state *conn_state;
> +       struct drm_connector *conn;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 10);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       conn_state = conn->state;
> +       KUNIT_EXPECT_EQ(test, conn_state->max_bpc, 10);
> +       KUNIT_EXPECT_EQ(test, conn_state->max_requested_bpc, 10);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 0);
> +}
> +
> +/*
> + * Test that if the connector was initialised with a maximum bpc of 12,
> + * the value of the max_bpc and max_requested_bpc properties out of
> + * reset are also set to 12, and output_bpc is set to 0 and will be
> + * filled at atomic_check time.
> + */
> +static void drm_test_check_bpc_12_value(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_connector_state *conn_state;
> +       struct drm_connector *conn;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test, 12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       conn_state = conn->state;
> +       KUNIT_EXPECT_EQ(test, conn_state->max_bpc, 12);
> +       KUNIT_EXPECT_EQ(test, conn_state->max_requested_bpc, 12);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 0);
> +}
> +
>  static struct kunit_case drm_atomic_helper_connector_hdmi_reset_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_value),
> +       KUNIT_CASE(drm_test_check_bpc_8_value),
> +       KUNIT_CASE(drm_test_check_bpc_10_value),
> +       KUNIT_CASE(drm_test_check_bpc_12_value),
>         { }
>  };
>
> diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
> index 41d33dea30af..fef7d53d34d4 100644
> --- a/drivers/gpu/drm/tests/drm_connector_test.c
> +++ b/drivers/gpu/drm/tests/drm_connector_test.c
> @@ -186,7 +186,8 @@ static void drm_test_connector_hdmi_init_valid(struct kunit *test)
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
> -                                      &priv->ddc);
> +                                      &priv->ddc,
> +                                      8);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>  }
>
> @@ -202,10 +203,144 @@ static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
> -                                      NULL);
> +                                      NULL,
> +                                      8);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>  }
>
> +/*
> + * Test that the registration of a connector with an invalid maximum bpc
> + * count fails.
> + */
> +static void drm_test_connector_hdmi_init_bpc_invalid(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      &priv->ddc,
> +                                      9);
> +       KUNIT_EXPECT_LT(test, ret, 0);
> +}
> +
> +/*
> + * Test that the registration of a connector with a null maximum bpc
> + * count fails.
> + */
> +static void drm_test_connector_hdmi_init_bpc_null(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      &priv->ddc,
> +                                      0);
> +       KUNIT_EXPECT_LT(test, ret, 0);
> +}
> +
> +/*
> + * Test that the registration of a connector with a maximum bpc count of
> + * 8 succeeds, registers the max bpc property, but doesn't register the
> + * HDR output metadata one.
> + */
> +static void drm_test_connector_hdmi_init_bpc_8(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       struct drm_connector *connector = &priv->connector;
> +       struct drm_property *prop;
> +       uint64_t val;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      &priv->ddc,
> +                                      8);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       prop = connector->max_bpc_property;
> +       KUNIT_ASSERT_NOT_NULL(test, prop);
> +       KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
> +
> +       ret = drm_object_property_get_value(&connector->base, prop, &val);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +       KUNIT_EXPECT_EQ(test, val, 8);
> +
> +       prop = priv->drm.mode_config.hdr_output_metadata_property;
> +       KUNIT_ASSERT_NOT_NULL(test, prop);
> +       KUNIT_EXPECT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
> +}
> +
> +/*
> + * Test that the registration of a connector with a maximum bpc count of
> + * 10 succeeds and registers the max bpc and HDR output metadata
> + * properties.
> + */
> +static void drm_test_connector_hdmi_init_bpc_10(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       struct drm_connector *connector = &priv->connector;
> +       struct drm_property *prop;
> +       uint64_t val;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      &priv->ddc,
> +                                      10);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       prop = connector->max_bpc_property;
> +       KUNIT_ASSERT_NOT_NULL(test, prop);
> +       KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
> +
> +       ret = drm_object_property_get_value(&connector->base, prop, &val);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +       KUNIT_EXPECT_EQ(test, val, 10);
> +
> +       prop = priv->drm.mode_config.hdr_output_metadata_property;
> +       KUNIT_ASSERT_NOT_NULL(test, prop);
> +       KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
> +}
> +
> +/*
> + * Test that the registration of a connector with a maximum bpc count of
> + * 12 succeeds and registers the max bpc and HDR output metadata
> + * properties.
> + */
> +static void drm_test_connector_hdmi_init_bpc_12(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       struct drm_connector *connector = &priv->connector;
> +       struct drm_property *prop;
> +       uint64_t val;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      &priv->ddc,
> +                                      12);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       prop = connector->max_bpc_property;
> +       KUNIT_ASSERT_NOT_NULL(test, prop);
> +       KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
> +
> +       ret = drm_object_property_get_value(&connector->base, prop, &val);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +       KUNIT_EXPECT_EQ(test, val, 12);
> +
> +       prop = priv->drm.mode_config.hdr_output_metadata_property;
> +       KUNIT_ASSERT_NOT_NULL(test, prop);
> +       KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
> +}
> +
>  /*
>   * Test that the registration of an HDMI connector with an HDMI
>   * connector type succeeds.
> @@ -219,7 +354,8 @@ static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
>                                        connector_type,
> -                                      &priv->ddc);
> +                                      &priv->ddc,
> +                                      8);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>  }
>
> @@ -250,7 +386,8 @@ static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
>                                        connector_type,
> -                                      &priv->ddc);
> +                                      &priv->ddc,
> +                                      8);
>         KUNIT_EXPECT_LT(test, ret, 0);
>  }
>
> @@ -282,6 +419,11 @@ KUNIT_ARRAY_PARAM(drm_connector_hdmi_init_type_invalid,
>
>  static struct kunit_case drmm_connector_hdmi_init_tests[] = {
>         KUNIT_CASE(drm_test_connector_hdmi_init_valid),
> +       KUNIT_CASE(drm_test_connector_hdmi_init_bpc_8),
> +       KUNIT_CASE(drm_test_connector_hdmi_init_bpc_10),
> +       KUNIT_CASE(drm_test_connector_hdmi_init_bpc_12),
> +       KUNIT_CASE(drm_test_connector_hdmi_init_bpc_invalid),
> +       KUNIT_CASE(drm_test_connector_hdmi_init_bpc_null),
>         KUNIT_CASE(drm_test_connector_hdmi_init_null_ddc),
>         KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_valid,
>                          drm_connector_hdmi_init_type_valid_gen_params),
> @@ -447,7 +589,8 @@ static void drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector(
>         ret = drmm_connector_hdmi_init(&priv->drm, connector,
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
> -                                      &priv->ddc);
> +                                      &priv->ddc,
> +                                      8);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>
>         ret = drm_connector_attach_broadcast_rgb_property(connector);
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 76eecd449fb8..1b1b6aed04ee 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1072,6 +1072,11 @@ struct drm_connector_state {
>                  * RGB Quantization Range or not?
>                  */
>                 bool is_full_range;
> +
> +               /**
> +                * @output_bpc: Bits per color channel to output.
> +                */
> +               unsigned int output_bpc;
>         } hdmi;
>  };
>
> @@ -1717,6 +1722,11 @@ struct drm_connector {
>          */
>         struct drm_property_blob *path_blob_ptr;
>
> +       /**
> +        * @max_bpc: Maximum bits per color channel the connector supports.
> +        */
> +       unsigned int max_bpc;
> +
>         /**
>          * @max_bpc_property: Default connector property for the max bpc to be
>          * driven out of the connector.
> @@ -1956,7 +1966,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
>                              struct drm_connector *connector,
>                              const struct drm_connector_funcs *funcs,
>                              int connector_type,
> -                            struct i2c_adapter *ddc);
> +                            struct i2c_adapter *ddc,
> +                            unsigned int max_bpc);
>  void drm_connector_attach_edid_property(struct drm_connector *connector);
>  int drm_connector_register(struct drm_connector *connector);
>  void drm_connector_unregister(struct drm_connector *connector);
>
> --
> 2.43.0
>


From dave.stevenson at raspberrypi.com  Thu Dec 14 06:52:34 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 14:52:34 +0000
Subject: [PATCH v5 11/44] drm/connector: hdmi: Add support for output format
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-11-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-11-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntC_vF3L8LQR2ZTCwWgv8cDYnC8mU_Hn2_duMrDOAj2jrA@mail.gmail.com>

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> Just like BPC, we'll add support for automatic selection of the output
> format for HDMI connectors.
>
> Let's add the needed defaults and fields for now.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  drivers/gpu/drm/drm_atomic.c                       |   2 +
>  drivers/gpu/drm/drm_atomic_state_helper.c          |   3 +-
>  drivers/gpu/drm/drm_connector.c                    |  31 ++++++
>  .../gpu/drm/tests/drm_atomic_state_helper_test.c   |  90 ++++++++++++++---
>  drivers/gpu/drm/tests/drm_connector_test.c         | 109 ++++++++++++++++++++-
>  include/drm/drm_connector.h                        |  19 ++++
>  6 files changed, 238 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 76c63ed04af4..7aaa2a4d70d9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1148,6 +1148,8 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
>                            drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb));
>                 drm_printf(p, "\tis_full_range=%c\n", state->hdmi.is_full_range ? 'y' : 'n');
>                 drm_printf(p, "\toutput_bpc=%u\n", state->hdmi.output_bpc);
> +               drm_printf(p, "\toutput_format=%s\n",
> +                          drm_hdmi_connector_get_output_format_name(state->hdmi.output_format));
>         }
>
>         if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 883bdc0349c0..92e1b087c3d0 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -705,7 +705,8 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
>         new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
>
>         if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb ||
> -           old_state->hdmi.output_bpc != new_state->hdmi.output_bpc) {
> +           old_state->hdmi.output_bpc != new_state->hdmi.output_bpc ||
> +           old_state->hdmi.output_format != new_state->hdmi.output_format) {
>                 struct drm_crtc *crtc = new_state->crtc;
>                 struct drm_crtc_state *crtc_state;
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 139ac3d8160c..a72f38b6dbc8 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -459,6 +459,7 @@ EXPORT_SYMBOL(drmm_connector_init);
>   * @funcs: callbacks for this connector
>   * @connector_type: user visible type of the connector
>   * @ddc: optional pointer to the associated ddc adapter
> + * @supported_formats: Bitmask of @hdmi_colorspace listing supported output formats
>   * @max_bpc: Maximum bits per char the HDMI connector supports
>   *
>   * Initialises a preallocated HDMI connector. Connectors can be
> @@ -477,6 +478,7 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
>                              const struct drm_connector_funcs *funcs,
>                              int connector_type,
>                              struct i2c_adapter *ddc,
> +                            unsigned long supported_formats,
>                              unsigned int max_bpc)
>  {
>         int ret;
> @@ -485,6 +487,9 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
>               connector_type == DRM_MODE_CONNECTOR_HDMIB))
>                 return -EINVAL;
>
> +       if (!supported_formats || !(supported_formats & BIT(HDMI_COLORSPACE_RGB)))
> +               return -EINVAL;
> +
>         if (!(max_bpc == 8 || max_bpc == 10 || max_bpc == 12))
>                 return -EINVAL;
>
> @@ -492,6 +497,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
>         if (ret)
>                 return ret;
>
> +       connector->hdmi.supported_formats = supported_formats;
> +
>         /*
>          * drm_connector_attach_max_bpc_property() requires the
>          * connector to have a state.
> @@ -1224,6 +1231,30 @@ drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_
>  }
>  EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name);
>
> +static const char * const output_format_str[] = {
> +       [HDMI_COLORSPACE_RGB]           = "RGB",
> +       [HDMI_COLORSPACE_YUV420]        = "YUV 4:2:0",
> +       [HDMI_COLORSPACE_YUV422]        = "YUV 4:2:2",
> +       [HDMI_COLORSPACE_YUV444]        = "YUV 4:4:4",
> +};
> +
> +/*
> + * drm_hdmi_connector_get_output_format_name() - Return a string for HDMI connector output format
> + * @fmt: Output format to compute name of
> + *
> + * Returns: the name of the output format, or NULL if the type is not
> + * valid.
> + */
> +const char *
> +drm_hdmi_connector_get_output_format_name(enum hdmi_colorspace fmt)
> +{
> +       if (fmt >= ARRAY_SIZE(output_format_str))
> +               return NULL;
> +
> +       return output_format_str[fmt];
> +}
> +EXPORT_SYMBOL(drm_hdmi_connector_get_output_format_name);
> +
>  /**
>   * DOC: standard connector properties
>   *
> diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> index a1b0e6914cf8..4e2ec436987b 100644
> --- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> @@ -147,6 +147,7 @@ static const struct drm_connector_funcs dummy_connector_funcs = {
>  static
>  struct drm_atomic_helper_connector_hdmi_priv *
>  drm_atomic_helper_connector_hdmi_init(struct kunit *test,
> +                                     unsigned int formats,
>                                       unsigned int max_bpc)
>  {
>         struct drm_atomic_helper_connector_hdmi_priv *priv;
> @@ -190,6 +191,7 @@ drm_atomic_helper_connector_hdmi_init(struct kunit *test,
>                                        &dummy_connector_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        NULL,
> +                                      formats,
>                                        max_bpc);
>         KUNIT_ASSERT_EQ(test, ret, 0);
>
> @@ -225,7 +227,9 @@ static void drm_test_check_broadcast_rgb_crtc_mode_changed(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> @@ -286,7 +290,9 @@ static void drm_test_check_broadcast_rgb_crtc_mode_not_changed(struct kunit *tes
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> @@ -347,7 +353,9 @@ static void drm_test_check_broadcast_rgb_auto_cea_mode(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -401,7 +409,9 @@ static void drm_test_check_broadcast_rgb_auto_cea_mode_vic_1(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -454,7 +464,9 @@ static void drm_test_check_broadcast_rgb_full_cea_mode(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -510,7 +522,9 @@ static void drm_test_check_broadcast_rgb_full_cea_mode_vic_1(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -565,7 +579,9 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -621,7 +637,9 @@ static void drm_test_check_broadcast_rgb_limited_cea_mode_vic_1(struct kunit *te
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -678,7 +696,9 @@ static void drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 10);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    10);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> @@ -745,7 +765,9 @@ static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
>         struct drm_crtc *crtc;
>         int ret;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 10);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    10);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> @@ -802,6 +824,15 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
>         KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
>         KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
> +       /*
> +        * TODO: We should have tests to check that a change in the
> +        * format triggers a CRTC mode change just like we do for the
> +        * RGB Quantization and BPC.
> +        *
> +        * However, we don't have any way to control which format gets
> +        * picked up aside from changing the BPC or mode which would
> +        * already trigger a mode change.
> +        */
>         { }
>  };
>
> @@ -820,7 +851,9 @@ static void drm_test_check_broadcast_rgb_value(struct kunit *test)
>         struct drm_connector_state *conn_state;
>         struct drm_connector *conn;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -840,7 +873,9 @@ static void drm_test_check_bpc_8_value(struct kunit *test)
>         struct drm_connector_state *conn_state;
>         struct drm_connector *conn;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 8);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -862,7 +897,9 @@ static void drm_test_check_bpc_10_value(struct kunit *test)
>         struct drm_connector_state *conn_state;
>         struct drm_connector *conn;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 10);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    10);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -884,7 +921,9 @@ static void drm_test_check_bpc_12_value(struct kunit *test)
>         struct drm_connector_state *conn_state;
>         struct drm_connector *conn;
>
> -       priv = drm_atomic_helper_connector_hdmi_init(test, 12);
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    12);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
>         conn = &priv->connector;
> @@ -894,11 +933,34 @@ static void drm_test_check_bpc_12_value(struct kunit *test)
>         KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 0);
>  }
>
> +/*
> + * Test that the value of the output format property out of reset is set
> + * to RGB, even if the driver supports more than that.
> + */
> +static void drm_test_check_format_value(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_connector_state *conn_state;
> +       struct drm_connector *conn;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB) |
> +                                                    BIT(HDMI_COLORSPACE_YUV422) |
> +                                                    BIT(HDMI_COLORSPACE_YUV444),
> +                                                    8);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       conn_state = conn->state;
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +}
> +
>  static struct kunit_case drm_atomic_helper_connector_hdmi_reset_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_value),
>         KUNIT_CASE(drm_test_check_bpc_8_value),
>         KUNIT_CASE(drm_test_check_bpc_10_value),
>         KUNIT_CASE(drm_test_check_bpc_12_value),
> +       KUNIT_CASE(drm_test_check_format_value),
>         { }
>  };
>
> diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
> index fef7d53d34d4..fa6fe8084107 100644
> --- a/drivers/gpu/drm/tests/drm_connector_test.c
> +++ b/drivers/gpu/drm/tests/drm_connector_test.c
> @@ -187,6 +187,7 @@ static void drm_test_connector_hdmi_init_valid(struct kunit *test)
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        8);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>  }
> @@ -204,6 +205,7 @@ static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        NULL,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        8);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>  }
> @@ -221,6 +223,7 @@ static void drm_test_connector_hdmi_init_bpc_invalid(struct kunit *test)
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        9);
>         KUNIT_EXPECT_LT(test, ret, 0);
>  }
> @@ -238,6 +241,7 @@ static void drm_test_connector_hdmi_init_bpc_null(struct kunit *test)
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        0);
>         KUNIT_EXPECT_LT(test, ret, 0);
>  }
> @@ -259,6 +263,7 @@ static void drm_test_connector_hdmi_init_bpc_8(struct kunit *test)
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        8);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>
> @@ -292,6 +297,7 @@ static void drm_test_connector_hdmi_init_bpc_10(struct kunit *test)
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        10);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>
> @@ -325,6 +331,7 @@ static void drm_test_connector_hdmi_init_bpc_12(struct kunit *test)
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        12);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>
> @@ -341,6 +348,42 @@ static void drm_test_connector_hdmi_init_bpc_12(struct kunit *test)
>         KUNIT_EXPECT_NOT_NULL(test, drm_mode_obj_find_prop_id(&connector->base, prop->base.id));
>  }
>
> +/*
> + * Test that the registration of an HDMI connector with no supported
> + * format fails.
> + */
> +static void drm_test_connector_hdmi_init_formats_empty(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      &priv->ddc,
> +                                      0,
> +                                      8);
> +       KUNIT_EXPECT_LT(test, ret, 0);
> +}
> +
> +/*
> + * Test that the registration of an HDMI connector not listing RGB as a
> + * supported format fails.
> + */
> +static void drm_test_connector_hdmi_init_formats_no_rgb(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       int ret;
> +
> +       ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
> +                                      &dummy_funcs,
> +                                      DRM_MODE_CONNECTOR_HDMIA,
> +                                      &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_YUV422),
> +                                      8);
> +       KUNIT_EXPECT_LT(test, ret, 0);
> +}
> +
>  /*
>   * Test that the registration of an HDMI connector with an HDMI
>   * connector type succeeds.
> @@ -355,6 +398,7 @@ static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
>                                        &dummy_funcs,
>                                        connector_type,
>                                        &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        8);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>  }
> @@ -387,6 +431,7 @@ static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
>                                        &dummy_funcs,
>                                        connector_type,
>                                        &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        8);
>         KUNIT_EXPECT_LT(test, ret, 0);
>  }
> @@ -424,6 +469,8 @@ static struct kunit_case drmm_connector_hdmi_init_tests[] = {
>         KUNIT_CASE(drm_test_connector_hdmi_init_bpc_12),
>         KUNIT_CASE(drm_test_connector_hdmi_init_bpc_invalid),
>         KUNIT_CASE(drm_test_connector_hdmi_init_bpc_null),
> +       KUNIT_CASE(drm_test_connector_hdmi_init_formats_empty),
> +       KUNIT_CASE(drm_test_connector_hdmi_init_formats_no_rgb),
>         KUNIT_CASE(drm_test_connector_hdmi_init_null_ddc),
>         KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_valid,
>                          drm_connector_hdmi_init_type_valid_gen_params),
> @@ -558,6 +605,64 @@ static struct kunit_suite drm_hdmi_connector_get_broadcast_rgb_name_test_suite =
>         .test_cases = drm_hdmi_connector_get_broadcast_rgb_name_tests,
>  };
>
> +struct drm_hdmi_connector_get_output_format_name_test {
> +       unsigned int kind;
> +       const char *expected_name;
> +};
> +
> +#define OUTPUT_FORMAT_TEST(_kind, _name)       \
> +       {                                       \
> +               .kind = _kind,                  \
> +               .expected_name = _name,         \
> +       }
> +
> +static void drm_test_drm_hdmi_connector_get_output_format_name(struct kunit *test)
> +{
> +       const struct drm_hdmi_connector_get_output_format_name_test *params =
> +               test->param_value;
> +
> +       KUNIT_EXPECT_STREQ(test,
> +                          drm_hdmi_connector_get_output_format_name(params->kind),
> +                          params->expected_name);
> +}
> +
> +static const
> +struct drm_hdmi_connector_get_output_format_name_test
> +drm_hdmi_connector_get_output_format_name_valid_tests[] = {
> +       OUTPUT_FORMAT_TEST(HDMI_COLORSPACE_RGB, "RGB"),
> +       OUTPUT_FORMAT_TEST(HDMI_COLORSPACE_YUV420, "YUV 4:2:0"),
> +       OUTPUT_FORMAT_TEST(HDMI_COLORSPACE_YUV422, "YUV 4:2:2"),
> +       OUTPUT_FORMAT_TEST(HDMI_COLORSPACE_YUV444, "YUV 4:4:4"),
> +};
> +
> +static void
> +drm_hdmi_connector_get_output_format_name_valid_desc(const struct drm_hdmi_connector_get_output_format_name_test *t,
> +                                                    char *desc)
> +{
> +       sprintf(desc, "%s", t->expected_name);
> +}
> +
> +KUNIT_ARRAY_PARAM(drm_hdmi_connector_get_output_format_name_valid,
> +                 drm_hdmi_connector_get_output_format_name_valid_tests,
> +                 drm_hdmi_connector_get_output_format_name_valid_desc);
> +
> +static void drm_test_drm_hdmi_connector_get_output_format_name_invalid(struct kunit *test)
> +{
> +       KUNIT_EXPECT_NULL(test, drm_hdmi_connector_get_output_format_name(4));
> +};
> +
> +static struct kunit_case drm_hdmi_connector_get_output_format_name_tests[] = {
> +       KUNIT_CASE_PARAM(drm_test_drm_hdmi_connector_get_output_format_name,
> +                        drm_hdmi_connector_get_output_format_name_valid_gen_params),
> +       KUNIT_CASE(drm_test_drm_hdmi_connector_get_output_format_name_invalid),
> +       { }
> +};
> +
> +static struct kunit_suite drm_hdmi_connector_get_output_format_name_test_suite = {
> +       .name = "drm_hdmi_connector_get_output_format_name",
> +       .test_cases = drm_hdmi_connector_get_output_format_name_tests,
> +};
> +
>  static void drm_test_drm_connector_attach_broadcast_rgb_property(struct kunit *test)
>  {
>         struct drm_connector_init_priv *priv = test->priv;
> @@ -590,6 +695,7 @@ static void drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector(
>                                        &dummy_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
> +                                      BIT(HDMI_COLORSPACE_RGB),
>                                        8);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>
> @@ -618,7 +724,8 @@ kunit_test_suites(
>         &drmm_connector_init_test_suite,
>         &drm_connector_attach_broadcast_rgb_property_test_suite,
>         &drm_get_tv_mode_from_name_test_suite,
> -       &drm_hdmi_connector_get_broadcast_rgb_name_test_suite
> +       &drm_hdmi_connector_get_broadcast_rgb_name_test_suite,
> +       &drm_hdmi_connector_get_output_format_name_test_suite
>  );
>
>  MODULE_AUTHOR("Maxime Ripard <maxime at cerno.tech>");
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 1b1b6aed04ee..74db5ce47e01 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -391,6 +391,8 @@ enum drm_hdmi_broadcast_rgb {
>
>  const char *
>  drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_rgb);
> +const char *
> +drm_hdmi_connector_get_output_format_name(enum hdmi_colorspace fmt);
>
>  /**
>   * struct drm_monitor_range_info - Panel's Monitor range in EDID for
> @@ -1077,6 +1079,11 @@ struct drm_connector_state {
>                  * @output_bpc: Bits per color channel to output.
>                  */
>                 unsigned int output_bpc;
> +
> +               /**
> +                * @output_format: Pixel format to output in.
> +                */
> +               enum hdmi_colorspace output_format;
>         } hdmi;
>  };
>
> @@ -1944,6 +1951,17 @@ struct drm_connector {
>
>         /** @hdr_sink_metadata: HDR Metadata Information read from sink */
>         struct hdr_sink_metadata hdr_sink_metadata;
> +
> +       /**
> +        * @hdmi: HDMI-related variable and properties.
> +        */
> +       struct {
> +               /**
> +                * @supported_formats: Bitmask of @hdmi_colorspace
> +                * supported by the controller.
> +                */
> +               unsigned long supported_formats;
> +       } hdmi;
>  };
>
>  #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> @@ -1967,6 +1985,7 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
>                              const struct drm_connector_funcs *funcs,
>                              int connector_type,
>                              struct i2c_adapter *ddc,
> +                            unsigned long supported_formats,
>                              unsigned int max_bpc);
>  void drm_connector_attach_edid_property(struct drm_connector *connector);
>  int drm_connector_register(struct drm_connector *connector);
>
> --
> 2.43.0
>


From michal.simek at amd.com  Thu Dec 14 06:53:47 2023
From: michal.simek at amd.com (Michal Simek)
Date: Thu, 14 Dec 2023 15:53:47 +0100
Subject: [PATCH 1/2] firmware: xilinx: Remove clock_setrate and clock_getrate api
Message-ID: <6ccbffbafd1f0f48f6574d5a3bf2db6a5603fdb0.1702565618.git.michal.simek@amd.com>

As per the current code base, PM_CLOCK_SETRATE and PM_CLOCK_GETRATE
APIs are not supported for the runtime operations. In the case of
ZynqMP returning an error from TF-A when there is any request to
access these APIs and for Versal also it is returning an error like
NO_ACCESS from the firmware. So, just removing the unused code to
avoid the confusion around these APIs.

Also, there is no issue with the backward compatibility as these APIs
were never used since implemented. Hence no need to bump up the
version of the feature check API as well.

Signed-off-by: Ronak Jain <ronak.jain at amd.com>
Signed-off-by: Michal Simek <michal.simek at amd.com>
---

 drivers/firmware/xilinx/zynqmp.c     | 38 ----------------------------
 include/linux/firmware/xlnx-zynqmp.h | 14 ----------
 2 files changed, 52 deletions(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index caa0952bfc42..2ae9da268215 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -657,44 +657,6 @@ int zynqmp_pm_clock_getdivider(u32 clock_id, u32 *divider)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_clock_getdivider);
 
-/**
- * zynqmp_pm_clock_setrate() - Set the clock rate for given id
- * @clock_id:	ID of the clock
- * @rate:	rate value in hz
- *
- * This function is used by master to set rate for any clock.
- *
- * Return: Returns status, either success or error+reason
- */
-int zynqmp_pm_clock_setrate(u32 clock_id, u64 rate)
-{
-	return zynqmp_pm_invoke_fn(PM_CLOCK_SETRATE, NULL, 3, clock_id, lower_32_bits(rate),
-				   upper_32_bits(rate));
-}
-EXPORT_SYMBOL_GPL(zynqmp_pm_clock_setrate);
-
-/**
- * zynqmp_pm_clock_getrate() - Get the clock rate for given id
- * @clock_id:	ID of the clock
- * @rate:	rate value in hz
- *
- * This function is used by master to get rate
- * for any clock.
- *
- * Return: Returns status, either success or error+reason
- */
-int zynqmp_pm_clock_getrate(u32 clock_id, u64 *rate)
-{
-	u32 ret_payload[PAYLOAD_ARG_CNT];
-	int ret;
-
-	ret = zynqmp_pm_invoke_fn(PM_CLOCK_GETRATE, ret_payload, 1, clock_id);
-	*rate = ((u64)ret_payload[2] << 32) | ret_payload[1];
-
-	return ret;
-}
-EXPORT_SYMBOL_GPL(zynqmp_pm_clock_getrate);
-
 /**
  * zynqmp_pm_clock_setparent() - Set the clock parent for given id
  * @clock_id:	ID of the clock
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 6b48294f3c92..c6a7fb1f980b 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -160,8 +160,6 @@ enum pm_api_id {
 	PM_CLOCK_GETSTATE = 38,
 	PM_CLOCK_SETDIVIDER = 39,
 	PM_CLOCK_GETDIVIDER = 40,
-	PM_CLOCK_SETRATE = 41,
-	PM_CLOCK_GETRATE = 42,
 	PM_CLOCK_SETPARENT = 43,
 	PM_CLOCK_GETPARENT = 44,
 	PM_FPGA_READ = 46,
@@ -533,8 +531,6 @@ int zynqmp_pm_clock_disable(u32 clock_id);
 int zynqmp_pm_clock_getstate(u32 clock_id, u32 *state);
 int zynqmp_pm_clock_setdivider(u32 clock_id, u32 divider);
 int zynqmp_pm_clock_getdivider(u32 clock_id, u32 *divider);
-int zynqmp_pm_clock_setrate(u32 clock_id, u64 rate);
-int zynqmp_pm_clock_getrate(u32 clock_id, u64 *rate);
 int zynqmp_pm_clock_setparent(u32 clock_id, u32 parent_id);
 int zynqmp_pm_clock_getparent(u32 clock_id, u32 *parent_id);
 int zynqmp_pm_set_pll_frac_mode(u32 clk_id, u32 mode);
@@ -639,16 +635,6 @@ static inline int zynqmp_pm_clock_getdivider(u32 clock_id, u32 *divider)
 	return -ENODEV;
 }
 
-static inline int zynqmp_pm_clock_setrate(u32 clock_id, u64 rate)
-{
-	return -ENODEV;
-}
-
-static inline int zynqmp_pm_clock_getrate(u32 clock_id, u64 *rate)
-{
-	return -ENODEV;
-}
-
 static inline int zynqmp_pm_clock_setparent(u32 clock_id, u32 parent_id)
 {
 	return -ENODEV;
-- 
2.36.1



From michal.simek at amd.com  Thu Dec 14 06:53:48 2023
From: michal.simek at amd.com (Michal Simek)
Date: Thu, 14 Dec 2023 15:53:48 +0100
Subject: [PATCH 2/2] firmware: xilinx: Remove zynqmp_pm_pinctrl_get_function()
In-Reply-To: <6ccbffbafd1f0f48f6574d5a3bf2db6a5603fdb0.1702565618.git.michal.simek@amd.com>
References: <6ccbffbafd1f0f48f6574d5a3bf2db6a5603fdb0.1702565618.git.michal.simek@amd.com>
Message-ID: <e52a415a004e28a43e6d08e9e22d9e8fef3737df.1702565618.git.michal.simek@amd.com>

There is no user for this interface that's why remove it.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

 drivers/firmware/xilinx/zynqmp.c     | 24 ------------------------
 include/linux/firmware/xlnx-zynqmp.h |  7 -------
 2 files changed, 31 deletions(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 2ae9da268215..a55dfd9bae6b 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -1060,30 +1060,6 @@ int zynqmp_pm_pinctrl_release(const u32 pin)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_release);
 
-/**
- * zynqmp_pm_pinctrl_get_function - Read function id set for the given pin
- * @pin: Pin number
- * @id: Buffer to store function ID
- *
- * This function provides the function currently set for the given pin.
- *
- * Return: Returns status, either success or error+reason
- */
-int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id)
-{
-	u32 ret_payload[PAYLOAD_ARG_CNT];
-	int ret;
-
-	if (!id)
-		return -EINVAL;
-
-	ret = zynqmp_pm_invoke_fn(PM_PINCTRL_GET_FUNCTION, ret_payload, 1, pin);
-	*id = ret_payload[1];
-
-	return ret;
-}
-EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_function);
-
 /**
  * zynqmp_pm_pinctrl_set_function - Set requested function for the pin
  * @pin: Pin number
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index c6a7fb1f980b..1478f691cc10 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -149,7 +149,6 @@ enum pm_api_id {
 	PM_SECURE_SHA = 26,
 	PM_PINCTRL_REQUEST = 28,
 	PM_PINCTRL_RELEASE = 29,
-	PM_PINCTRL_GET_FUNCTION = 30,
 	PM_PINCTRL_SET_FUNCTION = 31,
 	PM_PINCTRL_CONFIG_PARAM_GET = 32,
 	PM_PINCTRL_CONFIG_PARAM_SET = 33,
@@ -567,7 +566,6 @@ int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
 int zynqmp_pm_set_boot_health_status(u32 value);
 int zynqmp_pm_pinctrl_request(const u32 pin);
 int zynqmp_pm_pinctrl_release(const u32 pin);
-int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id);
 int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id);
 int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
 				 u32 *value);
@@ -804,11 +802,6 @@ static inline int zynqmp_pm_pinctrl_release(const u32 pin)
 	return -ENODEV;
 }
 
-static inline int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id)
-{
-	return -ENODEV;
-}
-
 static inline int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id)
 {
 	return -ENODEV;
-- 
2.36.1



From wenst at chromium.org  Thu Dec 14 06:53:57 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 14 Dec 2023 23:53:57 +0900
Subject: [PATCH v4 7/9] arm64: dts: mediatek: Introduce MT8186 Steelix
In-Reply-To: <8d855e5e-4938-4d4f-a79f-bbf89e30f6ca@collabora.com>
References: <20231213150435.4134390-1-wenst@chromium.org> <20231213150435.4134390-8-wenst@chromium.org>
 <8d855e5e-4938-4d4f-a79f-bbf89e30f6ca@collabora.com>
Message-ID: <CAGXv+5EmVQBNOL6GWaXu_i89WAUeUVtMBSbG8onGh3KHz5rnbA@mail.gmail.com>

On Thu, Dec 14, 2023 at 7:34?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Il 13/12/23 16:04, Chen-Yu Tsai ha scritto:
> > The MT8186 Steelix, also known as the Lenovo 300e Yoga Chromebook Gen 4,
> > is a convertible device based on a common design of the same name. The
> > device comes in different variants. Of them, whether a world facing
> > camera is integrated is the only differentiating factor between the
> > two device trees added. The different SKU IDs describe this alone.
> >
> > The other device difference is the touchpad component used. This is
> > simply handled by having both possible components described in the
> > device tree, and letting the implementation figure out which one is
> > actually available. The system bootloader / firmware does not
> > differentiate this in that they share the same SKU IDs.
> >
> > Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> > Acked-by: Conor Dooley <conor.dooley at microchip.com>
> > ---
> > Changes since v2:
> > - Picked up Conor's ack
> >
> > Changes since v1:
> > - Removed trackpad_pins reference (moved to i2c2 in corsola dtsi)
> > - Fixed copyright year
> > - Renamed touchpad to trackpad
> > ---
> >   arch/arm64/boot/dts/mediatek/Makefile         |   2 +
> >   .../mt8186-corsola-steelix-sku131072.dts      |  18 ++
> >   .../mt8186-corsola-steelix-sku131073.dts      |  18 ++
> >   .../dts/mediatek/mt8186-corsola-steelix.dtsi  | 195 ++++++++++++++++++
> >   4 files changed, 233 insertions(+)
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> > index 442af61b1305..7bd9471b89f9 100644
> > --- a/arch/arm64/boot/dts/mediatek/Makefile
> > +++ b/arch/arm64/boot/dts/mediatek/Makefile
> > @@ -43,6 +43,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku32.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-pumpkin.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131072.dtb
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-steelix-sku131073.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327681.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacool-sku327683.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8186-corsola-tentacruel-sku262144.dtb
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
> > new file mode 100644
> > index 000000000000..eae17bca8585
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131072.dts
> > @@ -0,0 +1,18 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2022 Google LLC
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt8186-corsola-steelix.dtsi"
> > +
> > +/ {
> > +     model = "Google Steelix board";
> > +     compatible = "google,steelix-sku131072", "google,steelix",
> > +                  "mediatek,mt8186";
> > +     chassis-type = "convertible";
> > +};
> > +
> > +&mt6366codec {
> > +     mediatek,dmic-mode = <0>; /* two-wire */
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
> > new file mode 100644
> > index 000000000000..a55375b95d0d
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix-sku131073.dts
> > @@ -0,0 +1,18 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2022 Google LLC
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt8186-corsola-steelix.dtsi"
> > +
> > +/ {
> > +     model = "Google Steelix board";
> > +     compatible = "google,steelix-sku131073", "google,steelix",
> > +                  "mediatek,mt8186";
> > +     chassis-type = "convertible";
> > +};
> > +
> > +&mt6366codec {
> > +     mediatek,dmic-mode = <1>; /* one-wire */
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
> > new file mode 100644
> > index 000000000000..47262bc499ad
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8186-corsola-steelix.dtsi
> > @@ -0,0 +1,195 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2022 Google LLC
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt8186-corsola.dtsi"
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/input/input.h>
> > +
> > +/{
> > +     pp1000_edpbrdg: regulator-pp1000-edpbrdg {
> > +             compatible = "regulator-fixed";
> > +             regulator-name = "pp1000_edpbrdg";
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&en_pp1000_edpbrdg>;
> > +             enable-active-high;
> > +             regulator-boot-on;
> > +             gpio = <&pio 29 GPIO_ACTIVE_HIGH>;
> > +             vin-supply = <&pp3300_z2>;
> > +     };
> > +
> > +     pp1800_edpbrdg_dx: regulator-pp1800-edpbrdg-dx {
> > +             compatible = "regulator-fixed";
> > +             regulator-name = "pp1800_edpbrdg_dx";
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&en_pp1800_edpbrdg>;
> > +             enable-active-high;
> > +             regulator-boot-on;
> > +             gpio = <&pio 30 GPIO_ACTIVE_HIGH>;
> > +             vin-supply = <&mt6366_vio18_reg>;
> > +     };
> > +
> > +     pp3300_edp_dx: regulator-pp3300-edp-dx {
> > +             compatible = "regulator-fixed";
> > +             regulator-name = "pp3300_edp_dx";
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&en_pp3300_edpbrdg>;
> > +             enable-active-high;
> > +             regulator-boot-on;
> > +             gpio = <&pio 31 GPIO_ACTIVE_HIGH>;
> > +             vin-supply = <&pp3300_z2>;
> > +     };
> > +};
> > +
> > +&dsi_out {
> > +     remote-endpoint = <&anx7625_in>;
> > +};
> > +
> > +&i2c0 {
> > +     clock-frequency = <400000>;
> > +
> > +     anx_bridge: anx7625 at 58 {
> > +             compatible = "analogix,anx7625";
> > +             reg = <0x58>;
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&anx7625_pins>;
> > +             enable-gpios = <&pio 96 GPIO_ACTIVE_HIGH>;
> > +             reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>;

BTW, do you think there is anything we can do about this backwards
active level setting?

> > +             vdd10-supply = <&pp1000_edpbrdg>;
> > +             vdd18-supply = <&pp1800_edpbrdg_dx>;
> > +             vdd33-supply = <&pp3300_edp_dx>;
> > +             analogix,lane0-swing = /bits/ 8 <0x70 0x30>;
> > +             analogix,lane1-swing = /bits/ 8 <0x70 0x30>;
> > +
> > +             ports {
> > +                     #address-cells = <1>;
> > +                     #size-cells = <0>;
> > +
> > +                     port at 0 {
> > +                             reg = <0>;
> > +
> > +                             anx7625_in: endpoint {
> > +                                     remote-endpoint = <&dsi_out>;
> > +                                     data-lanes = <0 1 2 3>;
> > +                             };
> > +                     };
> > +
> > +                     port at 1 {
> > +                             reg = <1>;
> > +
> > +                             anx7625_out: endpoint {
> > +                                     remote-endpoint = <&panel_in>;
> > +                             };
> > +                     };
> > +             };
> > +
> > +             aux-bus {
> > +                     panel: panel {
> > +                             compatible = "edp-panel";
> > +                             power-supply = <&pp3300_disp_x>;
> > +                             backlight = <&backlight_lcd0>;
> > +
> > +                             port {
> > +                                     panel_in: endpoint {
> > +                                             remote-endpoint = <&anx7625_out>;
> > +                                     };
> > +                             };
> > +                     };
> > +             };
> > +     };
> > +};
> > +
> > +&i2c1 {
> > +     touchscreen: touchscreen at 5d {
> > +             compatible = "goodix,gt7375p";
> > +             reg = <0x5d>;
> > +             interrupts-extended = <&pio 12 IRQ_TYPE_EDGE_FALLING>;
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&touchscreen_pins>;
> > +             reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>;
> > +             vdd-supply = <&pp3300_s3>;
> > +             goodix,no-reset-during-suspend;
> > +     };
> > +};
> > +
> > +&i2c2 {
> > +     i2c-scl-internal-delay-ns = <22000>;
> > +
> > +     /* second source component */
> > +     trackpad at 2c {
> > +             compatible = "hid-over-i2c";
> > +             reg = <0x2c>;
> > +             hid-descr-addr = <0x20>;
> > +             interrupts-extended = <&pio 11 IRQ_TYPE_LEVEL_LOW>;
> > +             vdd-supply = <&pp3300_s3>;
> > +             wakeup-source;
> > +     };
> > +};
> > +
> > +&keyboard_controller {
> > +     function-row-physmap = <
> > +             MATRIX_KEY(0x00, 0x02, 0)       /* T1 */
> > +             MATRIX_KEY(0x03, 0x02, 0)       /* T2 */
> > +             MATRIX_KEY(0x02, 0x02, 0)       /* T3 */
> > +             MATRIX_KEY(0x01, 0x02, 0)       /* T4 */
> > +             MATRIX_KEY(0x03, 0x04, 0)       /* T5 */
> > +             MATRIX_KEY(0x02, 0x04, 0)       /* T6 */
> > +             MATRIX_KEY(0x01, 0x04, 0)       /* T7 */
> > +             MATRIX_KEY(0x02, 0x09, 0)       /* T8 */
> > +             MATRIX_KEY(0x01, 0x09, 0)       /* T9 */
> > +             MATRIX_KEY(0x00, 0x04, 0)       /* T10 */
> > +     >;
> > +
> > +     linux,keymap = <
> > +             MATRIX_KEY(0x00, 0x02, KEY_BACK)
> > +             MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
> > +             MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
> > +             MATRIX_KEY(0x01, 0x02, KEY_SCALE)
> > +             MATRIX_KEY(0x03, 0x04, KEY_BRIGHTNESSDOWN)
> > +             MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSUP)
> > +             MATRIX_KEY(0x01, 0x04, KEY_MICMUTE)
> > +             MATRIX_KEY(0x02, 0x09, KEY_MUTE)
> > +             MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
> > +             MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
> > +             CROS_STD_MAIN_KEYMAP
> > +     >;
> > +};
> > +
> > +&pio {
> > +     anx7625_pins: anx7625-pins {
> > +             pins1 {
>
> pins-en-rst

Ack. Also I think we can split them so they each get proper names.

> > +                     pinmux = <PINMUX_GPIO96__FUNC_GPIO96>,
> > +                              <PINMUX_GPIO98__FUNC_GPIO98>;
> > +                     output-low;
> > +             };
> > +
> > +             pins2 {
>
> pins-is-this-an-interrupt? :-)

Yes. Will use pins-int.

> > +                     pinmux = <PINMUX_GPIO9__FUNC_GPIO9>;
> > +                     input-enable;
> > +                     bias-disable;
> > +             };
> > +     };
> > +
> > +     en_pp1000_edpbrdg: pp1000-edpbrdg-en-pins {
> > +             pins {
>
> pins-vreg-en like in corsola.dtsi

Ack.

> > +                     pinmux = <PINMUX_GPIO29__FUNC_GPIO29>;
> > +                     output-low;
> > +             };
> > +     };
> > +
> > +     en_pp1800_edpbrdg: pp1800-edpbrdg-en-pins {
> > +             pins {
>
> same

Ack.

> > +                     pinmux = <PINMUX_GPIO30__FUNC_GPIO30>;
> > +                     output-low;
> > +             };
> > +     };
> > +
> > +     en_pp3300_edpbrdg: pp3300-edpbrdg-en-pins {
> > +             pins {

Ack.

ChenYu


From ebiederm at xmission.com  Thu Dec 14 06:58:49 2023
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 14 Dec 2023 08:58:49 -0600
Subject: [PATCH 00/15] kexec: Allow preservation of ftrace buffers
In-Reply-To: <20231213000452.88295-1-graf@amazon.com> (Alexander Graf's
	message of "Wed, 13 Dec 2023 00:04:37 +0000")
References: <20231213000452.88295-1-graf@amazon.com>
Message-ID: <87r0jo7rva.fsf@email.froward.int.ebiederm.org>

Alexander Graf <graf at amazon.com> writes:

> Kexec today considers itself purely a boot loader: When we enter the new
> kernel, any state the previous kernel left behind is irrelevant and the
> new kernel reinitializes the system.
>
> However, there are use cases where this mode of operation is not what we
> actually want. In virtualization hosts for example, we want to use kexec
> to update the host kernel while virtual machine memory stays untouched.
> When we add device assignment to the mix, we also need to ensure that
> IOMMU and VFIO states are untouched. If we add PCIe peer to peer DMA, we
> need to do the same for the PCI subsystem. If we want to kexec while an
> SEV-SNP enabled virtual machine is running, we need to preserve the VM
> context pages and physical memory. See James' and my Linux Plumbers
> Conference 2023 presentation for details:
>
>   https://lpc.events/event/17/contributions/1485/
>
> To start us on the journey to support all the use cases above, this
> patch implements basic infrastructure to allow hand over of kernel state
> across kexec (Kexec HandOver, aka KHO). As example target, we use ftrace:
> With this patch set applied, you can read ftrace records from the
> pre-kexec environment in your post-kexec one. This creates a very powerful
> debugging and performance analysis tool for kexec. It's also slightly
> easier to reason about than full blown VFIO state preservation.
>
> == Alternatives ==
>
> There are alternative approaches to (parts of) the problems above:
>
>   * Memory Pools [1] - preallocated persistent memory region + allocator
>   * PRMEM [2] - resizable persistent memory regions with fixed metadata
>                 pointer on the kernel command line + allocator
>   * Pkernfs [3] - preallocated file system for in-kernel data with fixed
>                   address location on the kernel command line
>   * PKRAM [4] - handover of user space pages using a fixed metadata page
>                 specified via command line
>
> All of the approaches above fundamentally have the same problem: They
> require the administrator to explicitly carve out a physical memory
> location because they have no mechanism outside of the kernel command
> line to pass data (including memory reservations) between kexec'ing
> kernels.
>
> KHO provides that base foundation. We will determine later whether we
> still need any of the approaches above for fast bulk memory handover of for
> example IOMMU page tables. But IMHO they would all be users of KHO, with
> KHO providing the foundational primitive to pass metadata and bulk memory
> reservations as well as provide easy versioning for data.

What you are describe in many ways is the same problem as
kexec-on-panic.  The goal of leaving devices running absolutely requires
carving out memory for the new kernel to live in while it is coming up
so that DMA from a device that was not shutdown down does not stomp the
kernel coming up.

If I understand the virtualization case some of those virtual machines
are going to have virtual NICs that are going to want to DMA memory to
the host system.  Which if I understand things correctly means that
among the devices you explicitly want to keep running there is a not
a way to avoid the chance of DMA coming in while the kernel is being
changed.

There is also a huge maintenance challenge associated with all of this.

If you go with something that is essentially kexec-on-panic and then
add a little bit to help find things in the memory of the previous
kernel while the new kernel is coming up I can see it as a possibility.

As an example I think preserving ftrace data of kexec seems bizarre.
I don't see how that is an interesting use case at all.  Not in
the situation of preserving virtual machines, and not in the situation
of kexec on panic.

If you are doing an orderly shutdown and kernel switch you should be
able to manually change the memory.  If you are not doing an orderly
shutdown then I really don't get it.

I don't hate the capability you are trying to build.

I have not read or looked at most of this so I am probably
missing subtle details.

As you are currently describing things I have the sense you have
completely misframed the problem and are trying to solve the wrong parts
of the problem.

Eric


From u-kumar1 at ti.com  Thu Dec 14 07:00:13 2023
From: u-kumar1 at ti.com (Kumar, Udit)
Date: Thu, 14 Dec 2023 20:30:13 +0530
Subject: [PATCH 0/3] arm64: dts: ti: Add Itap Delay Value For High Speed
 DDR
In-Reply-To: <6230e848-15b8-48ba-8af4-5f90d7e1408c@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
 <30baf959-e486-4804-947b-516e53cce6fa@ti.com>
 <6230e848-15b8-48ba-8af4-5f90d7e1408c@ti.com>
Message-ID: <f77b757c-492a-4a10-8fc1-03c6b3b423e8@ti.com>

On 12/14/2023 4:37 PM, Bhavya Kapoor wrote:
>
> On 06/12/23 12:01 am, Kumar, Udit wrote:
>> Hi Bhavya
>>
>> On 12/1/2023 1:50 PM, Bhavya Kapoor wrote:
>>> This Series adds Itap Delay Value for DDR52 speed mode for eMMC in
>>> J7200 and for DDR50 speed mode for MMCSD in J721s2 and J784s4 SoC.
>>>
>>> Rebased to next-20231201
>>>
>>> Bhavya Kapoor (3):
>>> ?? arm64: dts: ti: k3-j7200-main: Add Itap Delay Value For DDR52 speed
>>> ???? mode
>>> ?? arm64: dts: ti: k3-j721s2-main: Add Itap Delay Value For DDR50 speed
>>> ???? mode
>>> ?? arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed
>>> ???? mode
>>
>> Could you confirm, after adding itap values, above modes are working 
>> fine apart from
>>
>> mode detection.
>>
>> Thanks
>>
>> Udit
>
> Hi Udit, Below are the links to the test logs
>
> j7200 ddr52 - 
> https://gist.github.com/a0498981/f9b7b7d3592eaca591dec3e72de45585
>
> j721s2 ddr50 - 
> https://gist.github.com/a0498981/9861e1df3fe0fc7c050db4f7a8cc34b8
>
> j784s4 ddr50 - 
> https://gist.github.com/a0498981/7c598dd708424252e2629fe0c7458a6d
>
> Thanks
>
> ~B-Kapoor
>

Thanks for logs Bhavya,

With that for series

Reviewed-by: Udit Kumar <u-kumar1 at ti.com>



>>
>>
>>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 1 +
>>> ? arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 1 +
>>> ? arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 1 +
>>> ? 3 files changed, 3 insertions(+)
>>>


From alexander.stein at ew.tq-group.com  Thu Dec 14 07:02:38 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 16:02:38 +0100
Subject: [PATCH 0/5] TQMa8Xx (imx8qxp) audio support
Message-ID: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>

Hi,

this series adds audio support for TQMa8Xx on MBa8Xx.
The first 4 patches add the necessary nodes for providing clocks and SAI,
which are used in the last patch. Patch 5 depends on [1], but right now it is
to show a consumer.

Best regards,
Alexander

[1] https://lore.kernel.org/all/20231214142327.1962914-1-alexander.stein at ew.tq-group.com/

Alexander Stein (5):
  arm64: dts: imx8qxp: Add ACM input clock gates
  arm64: dts: imx8qxp: Add audio clock mux node
  arm64: dts: imx8qxp: Add audio SAI nodes
  arm64: dts: imx8qxp: Add mclkout clock gates
  arm64: dts: imx8qxp: mba8xx: Add analog audio output on MBa8Xx

 .../boot/dts/freescale/imx8-ss-audio.dtsi     | 330 ++++++++++++++++++
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi    |   7 +
 arch/arm64/boot/dts/freescale/mba8xx.dtsi     |  27 +-
 3 files changed, 361 insertions(+), 3 deletions(-)

-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec 14 07:02:39 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 16:02:39 +0100
Subject: [PATCH 1/5] arm64: dts: imx8qxp: Add ACM input clock gates
In-Reply-To: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
References: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214150243.1991532-2-alexander.stein@ew.tq-group.com>

These clock gates provide input clocks for ACM. They can be selected by
IMX_ADMA_ACM_* macros. As SAI driver does not provide Tx/Rx bitclock
clocks yet, add dummy clocks for the unimplemented inputs.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
ACM needs a lot of input clocks, while currently only 4 (aud_rec*_lpcg and
aud_pll_div*_lpcg) do have an actual clock provider. For each unsupported
clock there is a 0Hz fixed-clock added. This should be removed once a proper
clock provider is added.
This is different to the clock-dummy in imx8qxp.dtsi which provides a dummy
clock for an invalid mux settings.

 .../boot/dts/freescale/imx8-ss-audio.dtsi     | 138 ++++++++++++++++++
 1 file changed, 138 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
index f057c6b21b301..f080be75c4219 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
@@ -14,6 +14,104 @@ audio_ipg_clk: clock-audio-ipg {
 	clock-output-names = "audio_ipg_clk";
 };
 
+clk_ext_aud_mclk0: clock-ext-aud-mclk0 {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "ext_aud_mclk0";
+};
+
+clk_ext_aud_mclk1: clock-ext-aud-mclk1 {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "ext_aud_mclk1";
+};
+
+clk_esai0_rx_clk: clock-esai0-rx {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "esai0_rx_clk";
+};
+
+clk_esai0_rx_hf_clk: clock-esai0-rx-hf {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "esai0_rx_hf_clk";
+};
+
+clk_esai0_tx_clk: clock-esai0-tx {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "esai0_tx_clk";
+};
+
+clk_esai0_tx_hf_clk: clock-esai0-tx-hf {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "esai0_tx_hf_clk";
+};
+
+clk_spdif0_rx: clock-spdif0-rx {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "spdif0_rx";
+};
+
+clk_sai0_rx_bclk: clock-sai0-rx-bclk {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "sai0_rx_bclk";
+};
+
+clk_sai0_tx_bclk: clock-sai0-tx-bclk {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "sai0_tx_bclk";
+};
+
+clk_sai1_rx_bclk: clock-sai1-rx-bclk {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "sai1_rx_bclk";
+};
+
+clk_sai1_tx_bclk: clock-sai1-tx-bclk {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "sai1_tx_bclk";
+};
+
+clk_sai2_rx_bclk: clock-sai2-rx-bclk {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "sai2_rx_bclk";
+};
+
+clk_sai3_rx_bclk: clock-sai3-rx-bclk {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "sai3_rx_bclk";
+};
+
+clk_sai4_rx_bclk: clock-sai4-rx-bclk {
+	compatible = "fixed-clock";
+	#clock-cells = <0>;
+	clock-frequency = <0>;
+	clock-output-names = "sai4_rx_bclk";
+};
+
 audio_subsys: bus at 59000000 {
 	compatible = "simple-bus";
 	#address-cells = <1>;
@@ -151,4 +249,44 @@ edma1: dma-controller at 599f0000 {
 				<&pd IMX_SC_R_DMA_1_CH9>,
 				<&pd IMX_SC_R_DMA_1_CH10>;
 	};
+
+	aud_rec0_lpcg: clock-controller at 59d00000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59d00000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>;
+		clock-indices = <IMX_LPCG_CLK_0>;
+		clock-output-names = "aud_rec_clk0_lpcg_clk";
+		power-domains = <&pd IMX_SC_R_AUDIO_PLL_0>;
+	};
+
+	aud_rec1_lpcg: clock-controller at 59d10000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59d10000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>;
+		clock-indices = <IMX_LPCG_CLK_0>;
+		clock-output-names = "aud_rec_clk1_lpcg_clk";
+		power-domains = <&pd IMX_SC_R_AUDIO_PLL_1>;
+	};
+
+	aud_pll_div0_lpcg: clock-controller at 59d20000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59d20000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>;
+		clock-indices = <IMX_LPCG_CLK_0>;
+		clock-output-names = "aud_pll_div_clk0_lpcg_clk";
+		power-domains = <&pd IMX_SC_R_AUDIO_PLL_0>;
+	};
+
+	aud_pll_div1_lpcg: clock-controller at 59d30000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59d30000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>;
+		clock-indices = <IMX_LPCG_CLK_0>;
+		clock-output-names = "aud_pll_div_clk1_lpcg_clk";
+		power-domains = <&pd IMX_SC_R_AUDIO_PLL_1>;
+	};
 };
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec 14 07:02:40 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 16:02:40 +0100
Subject: [PATCH 2/5] arm64: dts: imx8qxp: Add audio clock mux node
In-Reply-To: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
References: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214150243.1991532-3-alexander.stein@ew.tq-group.com>

The audio clock mux (ACM) selects the input clock for each attached
consumer, referenced by clock-cell.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
This node is essentially copied from
Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml.

 .../boot/dts/freescale/imx8-ss-audio.dtsi     | 59 +++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
index f080be75c4219..61ef0272b06e6 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
@@ -289,4 +289,63 @@ aud_pll_div1_lpcg: clock-controller at 59d30000 {
 		clock-output-names = "aud_pll_div_clk1_lpcg_clk";
 		power-domains = <&pd IMX_SC_R_AUDIO_PLL_1>;
 	};
+
+	acm: acm at 59e00000 {
+		compatible = "fsl,imx8qxp-acm";
+		reg = <0x59e00000 0x1d0000>;
+		#clock-cells = <1>;
+		power-domains = <&pd IMX_SC_R_AUDIO_CLK_0>,
+				<&pd IMX_SC_R_AUDIO_CLK_1>,
+				<&pd IMX_SC_R_MCLK_OUT_0>,
+				<&pd IMX_SC_R_MCLK_OUT_1>,
+				<&pd IMX_SC_R_AUDIO_PLL_0>,
+				<&pd IMX_SC_R_AUDIO_PLL_1>,
+				<&pd IMX_SC_R_ASRC_0>,
+				<&pd IMX_SC_R_ASRC_1>,
+				<&pd IMX_SC_R_ESAI_0>,
+				<&pd IMX_SC_R_SAI_0>,
+				<&pd IMX_SC_R_SAI_1>,
+				<&pd IMX_SC_R_SAI_2>,
+				<&pd IMX_SC_R_SAI_3>,
+				<&pd IMX_SC_R_SAI_4>,
+				<&pd IMX_SC_R_SAI_5>,
+				<&pd IMX_SC_R_SPDIF_0>,
+				<&pd IMX_SC_R_MQS_0>;
+		clocks = <&aud_rec0_lpcg IMX_LPCG_CLK_0>,
+			 <&aud_rec1_lpcg IMX_LPCG_CLK_0>,
+			 <&aud_pll_div0_lpcg IMX_LPCG_CLK_0>,
+			 <&aud_pll_div1_lpcg IMX_LPCG_CLK_0>,
+			 <&clk_ext_aud_mclk0>,
+			 <&clk_ext_aud_mclk1>,
+			 <&clk_esai0_rx_clk>,
+			 <&clk_esai0_rx_hf_clk>,
+			 <&clk_esai0_tx_clk>,
+			 <&clk_esai0_tx_hf_clk>,
+			 <&clk_spdif0_rx>,
+			 <&clk_sai0_rx_bclk>,
+			 <&clk_sai0_tx_bclk>,
+			 <&clk_sai1_rx_bclk>,
+			 <&clk_sai1_tx_bclk>,
+			 <&clk_sai2_rx_bclk>,
+			 <&clk_sai3_rx_bclk>,
+			 <&clk_sai4_rx_bclk>;
+		clock-names = "aud_rec_clk0_lpcg_clk",
+			      "aud_rec_clk1_lpcg_clk",
+			      "aud_pll_div_clk0_lpcg_clk",
+			      "aud_pll_div_clk1_lpcg_clk",
+			      "ext_aud_mclk0",
+			      "ext_aud_mclk1",
+			      "esai0_rx_clk",
+			      "esai0_rx_hf_clk",
+			      "esai0_tx_clk",
+			      "esai0_tx_hf_clk",
+			      "spdif0_rx",
+			      "sai0_rx_bclk",
+			      "sai0_tx_bclk",
+			      "sai1_rx_bclk",
+			      "sai1_tx_bclk",
+			      "sai2_rx_bclk",
+			      "sai3_rx_bclk",
+			      "sai4_rx_bclk";
+	};
 };
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec 14 07:02:41 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 16:02:41 +0100
Subject: [PATCH 3/5] arm64: dts: imx8qxp: Add audio SAI nodes
In-Reply-To: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
References: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214150243.1991532-4-alexander.stein@ew.tq-group.com>

This adds the sai nodes attached to aips1 bus. These can be shared with
imx8qm as well. Input clock from ACM is always feed to mclk1 only. Others
are unused and are connected to a dummy clock.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
This SAI list is not complete, but re-usable on imx8qm without any further
change. Adding SAI4/5 needs to be done in a SoC-specific file
imx8qxp-ss-audio.dtsi. They are hard-wired to the internal audio mixer as well.

 .../boot/dts/freescale/imx8-ss-audio.dtsi     | 113 ++++++++++++++++++
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi    |   7 ++
 2 files changed, 120 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
index 61ef0272b06e6..29a7d10f7db3d 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
@@ -4,6 +4,7 @@
  *	Dong Aisheng <aisheng.dong at nxp.com>
  */
 
+#include <dt-bindings/clock/imx8-clock.h>
 #include <dt-bindings/clock/imx8-lpcg.h>
 #include <dt-bindings/firmware/imx/rsrc.h>
 
@@ -118,6 +119,70 @@ audio_subsys: bus at 59000000 {
 	#size-cells = <1>;
 	ranges = <0x59000000 0x0 0x59000000 0x1000000>;
 
+	sai0: sai at 59040000 {
+		compatible = "fsl,imx8qm-sai";
+		reg = <0x59040000 0x10000>;
+		interrupts = <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&sai0_lpcg 1>,
+			 <&clk_dummy>,
+			 <&sai0_lpcg 0>,
+			 <&clk_dummy>,
+			 <&clk_dummy>;
+		clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
+		dma-names = "rx", "tx";
+		dmas = <&edma0 12 0 1>, <&edma0 13 0 0>;
+		power-domains = <&pd IMX_SC_R_SAI_0>;
+		status = "disabled";
+	};
+
+	sai1: sai at 59050000 {
+		compatible = "fsl,imx8qm-sai";
+		reg = <0x59050000 0x10000>;
+		interrupts = <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&sai1_lpcg 1>,
+			 <&clk_dummy>,
+			 <&sai1_lpcg 0>,
+			 <&clk_dummy>,
+			 <&clk_dummy>;
+		clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
+		dma-names = "rx", "tx";
+		dmas = <&edma0 14 0 1>, <&edma0 15 0 0>;
+		power-domains = <&pd IMX_SC_R_SAI_1>;
+		status = "disabled";
+	};
+
+	sai2: sai at 59060000 {
+		compatible = "fsl,imx8qm-sai";
+		reg = <0x59060000 0x10000>;
+		interrupts = <GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&sai2_lpcg 1>,
+			 <&clk_dummy>,
+			 <&sai2_lpcg 0>,
+			 <&clk_dummy>,
+			 <&clk_dummy>;
+		clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
+		dma-names = "rx";
+		dmas = <&edma0 16 0 1>;
+		power-domains = <&pd IMX_SC_R_SAI_2>;
+		status = "disabled";
+	};
+
+	sai3: sai at 59070000 {
+		compatible = "fsl,imx8qm-sai";
+		reg = <0x59070000 0x10000>;
+		interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&sai3_lpcg 1>,
+			 <&clk_dummy>,
+			 <&sai3_lpcg 0>,
+			 <&clk_dummy>,
+			 <&clk_dummy>;
+		clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
+		dma-names = "rx";
+		dmas = <&edma0 17 0 1>;
+		power-domains = <&pd IMX_SC_R_SAI_3>;
+		status = "disabled";
+	};
+
 	edma0: dma-controller at 591f0000 {
 		compatible = "fsl,imx8qm-edma";
 		reg = <0x591f0000 0x190000>;
@@ -174,6 +239,54 @@ edma0: dma-controller at 591f0000 {
 				<&pd IMX_SC_R_DMA_0_CH23>;
 	};
 
+	sai0_lpcg: clock-controller at 59440000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59440000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&acm IMX_ADMA_ACM_SAI0_MCLK_SEL>,
+			 <&audio_ipg_clk>;
+		clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
+		clock-output-names = "sai0_lpcg_mclk",
+				     "sai0_lpcg_ipg_clk";
+		power-domains = <&pd IMX_SC_R_SAI_0>;
+	};
+
+	sai1_lpcg: clock-controller at 59450000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59450000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&acm IMX_ADMA_ACM_SAI1_MCLK_SEL>,
+			 <&audio_ipg_clk>;
+		clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
+		clock-output-names = "sai1_lpcg_mclk",
+				     "sai1_lpcg_ipg_clk";
+		power-domains = <&pd IMX_SC_R_SAI_1>;
+	};
+
+	sai2_lpcg: clock-controller at 59460000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59460000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&acm IMX_ADMA_ACM_SAI2_MCLK_SEL>,
+			 <&audio_ipg_clk>;
+		clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
+		clock-output-names = "sai2_lpcg_mclk",
+				     "sai2_lpcg_ipg_clk";
+		power-domains = <&pd IMX_SC_R_SAI_2>;
+	};
+
+	sai3_lpcg: clock-controller at 59470000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59470000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&acm IMX_ADMA_ACM_SAI3_MCLK_SEL>,
+			 <&audio_ipg_clk>;
+		clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
+		clock-output-names = "sai3_lpcg_mclk",
+				     "sai3_lpcg_ipg_clk";
+		power-domains = <&pd IMX_SC_R_SAI_3>;
+	};
+
 	dsp_lpcg: clock-controller at 59580000 {
 		compatible = "fsl,imx8qxp-lpcg";
 		reg = <0x59580000 0x10000>;
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 958267b333403..fdbb4242b157c 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -260,6 +260,13 @@ timer {
 			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* Hypervisor */
 	};
 
+	clk_dummy: clock-dummy {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <0>;
+		clock-output-names = "clk_dummy";
+	};
+
 	xtal32k: clock-xtal32k {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec 14 07:02:42 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 16:02:42 +0100
Subject: [PATCH 4/5] arm64: dts: imx8qxp: Add mclkout clock gates
In-Reply-To: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
References: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214150243.1991532-5-alexander.stein@ew.tq-group.com>

These clock gates provide a clock output on ACM_MCLK_OUT pads. They are
intended to be used as MCLK for SAI0-3.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 .../boot/dts/freescale/imx8-ss-audio.dtsi     | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
index 29a7d10f7db3d..07afeb78ed564 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
@@ -403,6 +403,26 @@ aud_pll_div1_lpcg: clock-controller at 59d30000 {
 		power-domains = <&pd IMX_SC_R_AUDIO_PLL_1>;
 	};
 
+	mclkout0_lpcg: clock-controller at 59d50000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59d50000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&acm IMX_ADMA_ACM_MCLKOUT0_SEL>;
+		clock-indices = <IMX_LPCG_CLK_0>;
+		clock-output-names = "mclkout0_lpcg_clk";
+		power-domains = <&pd IMX_SC_R_MCLK_OUT_0>;
+	};
+
+	mclkout1_lpcg: clock-controller at 59d60000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x59d60000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&acm IMX_ADMA_ACM_MCLKOUT1_SEL>;
+		clock-indices = <IMX_LPCG_CLK_0>;
+		clock-output-names = "mclkout1_lpcg_clk";
+		power-domains = <&pd IMX_SC_R_MCLK_OUT_1>;
+	};
+
 	acm: acm at 59e00000 {
 		compatible = "fsl,imx8qxp-acm";
 		reg = <0x59e00000 0x1d0000>;
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Thu Dec 14 07:02:43 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Thu, 14 Dec 2023 16:02:43 +0100
Subject: [PATCH 5/5] arm64: dts: imx8qxp: mba8xx: Add analog audio output on MBa8Xx
In-Reply-To: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
References: <20231214150243.1991532-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231214150243.1991532-6-alexander.stein@ew.tq-group.com>

Enable SAI1, add the codec to enable LINE_IN and LINE_OUT support on
MBa8Xx on connectors X9 & X10.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm64/boot/dts/freescale/mba8xx.dtsi | 27 ++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/mba8xx.dtsi b/arch/arm64/boot/dts/freescale/mba8xx.dtsi
index a263c3d008023..6164fefb92184 100644
--- a/arch/arm64/boot/dts/freescale/mba8xx.dtsi
+++ b/arch/arm64/boot/dts/freescale/mba8xx.dtsi
@@ -116,7 +116,12 @@ reg_3v3_mb: regulator-usdhc2-vmmc {
 		regulator-max-microvolt = <3300000>;
 	};
 
-	/* TODO: Audio */
+	sound {
+		compatible = "fsl,imx-audio-tlv320aic32x4";
+		model = "tqm-tlv320aic32";
+		audio-codec = <&tlv320aic3x04>;
+		ssi-controller = <&sai1>;
+	};
 };
 
 &adc0 {
@@ -204,7 +209,14 @@ &flexcan2 {
 };
 
 &i2c1 {
-	/* TODO: Add Audio codec */
+	tlv320aic3x04: audio-codec at 18 {
+		compatible = "ti,tlv320aic32x4";
+		reg = <0x18>;
+		clocks = <&mclkout0_lpcg 0>;
+		clock-names = "mclk";
+		iov-supply = <&reg_1v8>;
+		ldoin-supply = <&reg_3v3>;
+	};
 
 	se97b_1c: temperature-sensor at 1c {
 		compatible = "nxp,se97b", "jedec,jc-42.4-temp";
@@ -298,7 +310,16 @@ &lsio_gpio3 {
 
 /* TODO: Mini-PCIe */
 
-/* TODO: SAI1 */
+&sai1 {
+	assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+			  <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+			  <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+			  <&sai1_lpcg 0>;
+	assigned-clock-rates = <786432000>, <49152000>, <12288000>, <49152000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_sai1>;
+	status = "okay";
+};
 
 &usbotg1 {
 	pinctrl-names = "default";
-- 
2.34.1



From dave.stevenson at raspberrypi.com  Thu Dec 14 07:02:54 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 15:02:54 +0000
Subject: [PATCH v5 12/44] drm/connector: hdmi: Add HDMI compute clock helper
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-12-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-12-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntDdmgc+k17T=kRXBWDAcN_Kww4L=0JRmiuupkKcy6tgzg@mail.gmail.com>

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> A lot of HDMI drivers have some variation of the formula to calculate
> the TMDS character rate from a mode, but few of them actually take all
> parameters into account.
>
> Let's create a helper to provide that rate taking all parameters into
> account.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>
> ---
>  drivers/gpu/drm/drm_connector.c            |  59 ++++++
>  drivers/gpu/drm/tests/drm_connector_test.c | 323 +++++++++++++++++++++++++++++
>  include/drm/drm_connector.h                |   5 +
>  3 files changed, 387 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a72f38b6dbc8..667326b09acc 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2973,6 +2973,65 @@ void drm_connector_update_privacy_screen(const struct drm_connector_state *conne
>  }
>  EXPORT_SYMBOL(drm_connector_update_privacy_screen);
>
> +/**
> + * drm_connector_hdmi_compute_mode_clock() - Computes the TMDS Character Rate
> + * @mode: Display mode to compute the clock for
> + * @bpc: Bits per character
> + * @fmt: Output Pixel Format used
> + *
> + * Returns the TMDS Character Rate for a given mode, bpc count and output format.
> + *
> + * RETURNS:
> + * The TMDS Character Rate, in Hertz, or 0 on error.
> + */
> +unsigned long long
> +drm_connector_hdmi_compute_mode_clock(const struct drm_display_mode *mode,
> +                                     unsigned int bpc,
> +                                     enum hdmi_colorspace fmt)
> +{
> +       unsigned long long clock = mode->clock * 1000ULL;
> +       unsigned int vic = drm_match_cea_mode(mode);
> +
> +       /*
> +        * CTA-861-G Spec, section 5.4 - Color Coding and Quantization
> +        * mandates that VIC 1 always uses 8 bpc.
> +        */
> +       if (vic == 1 && bpc != 8)
> +               return 0;
> +
> +       /*
> +        * HDMI 2.0 Spec, section 7.1 - YCbCr 4:2:0 Pixel Encoding
> +        * specifies that YUV420 encoding is only available for those
> +        * VICs.
> +        */
> +       if (fmt == HDMI_COLORSPACE_YUV420 &&
> +           !(vic == 96 || vic == 97 || vic == 101 ||
> +             vic == 102 || vic == 106 || vic == 107))
> +               return 0;
> +
> +       /*
> +        * HDMI 1.4b Spec, section 6.2.3 - Pixel Encoding Requirements
> +        * specifies that YUV422 is 36-bit only.
> +        */
> +       if (fmt == HDMI_COLORSPACE_YUV422 && bpc != 12)
> +               return 0;
> +
> +       if (fmt == HDMI_COLORSPACE_YUV420)
> +               clock = clock / 2;
> +
> +       if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> +               clock = clock * 2;
> +
> +       if (fmt == HDMI_COLORSPACE_YUV422)
> +               bpc = 8;

Possibly a comment on why we have these munges for 420 and 422 as they
aren't immediately obvious.

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> +
> +       clock = clock * bpc;
> +       do_div(clock, 8);
> +
> +       return clock;
> +}
> +EXPORT_SYMBOL(drm_connector_hdmi_compute_mode_clock);
> +
>  int drm_connector_set_obj_prop(struct drm_mode_object *obj,
>                                     struct drm_property *property,
>                                     uint64_t value)
> diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
> index fa6fe8084107..0a838924a546 100644
> --- a/drivers/gpu/drm/tests/drm_connector_test.c
> +++ b/drivers/gpu/drm/tests/drm_connector_test.c
> @@ -8,7 +8,9 @@
>  #include <drm/drm_atomic_state_helper.h>
>  #include <drm/drm_connector.h>
>  #include <drm/drm_drv.h>
> +#include <drm/drm_edid.h>
>  #include <drm/drm_kunit_helpers.h>
> +#include <drm/drm_modes.h>
>
>  #include <kunit/test.h>
>
> @@ -719,10 +721,331 @@ static struct kunit_suite drm_connector_attach_broadcast_rgb_property_test_suite
>         .test_cases = drm_connector_attach_broadcast_rgb_property_tests,
>  };
>
> +/*
> + * Test that for a given mode, with 8bpc and an RGB output the TMDS
> + * character rate is equal to the mode pixel clock.
> + */
> +static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       unsigned long long rate;
> +       struct drm_device *drm = &priv->drm;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 16);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_GT(test, rate, 0);
> +       KUNIT_EXPECT_EQ(test, mode->clock * 1000ULL, rate);
> +}
> +
> +/*
> + * Test that for a given mode, with 10bpc and an RGB output the TMDS
> + * character rate is equal to 1.25 times the mode pixel clock.
> + */
> +static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_10bpc(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       unsigned long long rate;
> +       struct drm_device *drm = &priv->drm;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 16);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 10, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_GT(test, rate, 0);
> +       KUNIT_EXPECT_EQ(test, mode->clock * 1250, rate);
> +}
> +
> +/*
> + * Test that for the VIC-1 mode, with 10bpc and an RGB output the TMDS
> + * character rate computation fails.
> + */
> +static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_10bpc_vic_1(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       unsigned long long rate;
> +       struct drm_device *drm = &priv->drm;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 1);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 10, HDMI_COLORSPACE_RGB);
> +       KUNIT_EXPECT_EQ(test, rate, 0);
> +}
> +
> +/*
> + * Test that for a given mode, with 12bpc and an RGB output the TMDS
> + * character rate is equal to 1.5 times the mode pixel clock.
> + */
> +static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_12bpc(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       unsigned long long rate;
> +       struct drm_device *drm = &priv->drm;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 16);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 12, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_GT(test, rate, 0);
> +       KUNIT_EXPECT_EQ(test, mode->clock * 1500, rate);
> +}
> +
> +/*
> + * Test that for the VIC-1 mode, with 12bpc and an RGB output the TMDS
> + * character rate computation fails.
> + */
> +static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_12bpc_vic_1(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       unsigned long long rate;
> +       struct drm_device *drm = &priv->drm;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 1);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 12, HDMI_COLORSPACE_RGB);
> +       KUNIT_EXPECT_EQ(test, rate, 0);
> +}
> +
> +/*
> + * Test that for a mode with the pixel repetition flag, the TMDS
> + * character rate is indeed double the mode pixel clock.
> + */
> +static void drm_test_drm_connector_hdmi_compute_mode_clock_rgb_double(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       unsigned long long rate;
> +       struct drm_device *drm = &priv->drm;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 6);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_TRUE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_GT(test, rate, 0);
> +       KUNIT_EXPECT_EQ(test, (mode->clock * 1000ULL) * 2, rate);
> +}
> +
> +/*
> + * Test that the TMDS character rate computation for the VIC modes
> + * explicitly listed in the spec as supporting YUV420 succeed and return
> + * half the mode pixel clock.
> + */
> +static void drm_test_connector_hdmi_compute_mode_clock_yuv420_valid(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       struct drm_device *drm = &priv->drm;
> +       unsigned long long rate;
> +       unsigned int vic = *(unsigned int *)test->param_value;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, vic);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_YUV420);
> +       KUNIT_ASSERT_GT(test, rate, 0);
> +       KUNIT_EXPECT_EQ(test, (mode->clock * 1000ULL) / 2, rate);
> +}
> +
> +static const unsigned int drm_connector_hdmi_compute_mode_clock_yuv420_vic_valid_tests[] = {
> +       96, 97, 101, 102, 106, 107,
> +};
> +
> +static void drm_connector_hdmi_compute_mode_clock_yuv420_vic_desc(const unsigned int *vic, char *desc)
> +{
> +       sprintf(desc, "VIC %u", *vic);
> +}
> +
> +KUNIT_ARRAY_PARAM(drm_connector_hdmi_compute_mode_clock_yuv420_valid,
> +                 drm_connector_hdmi_compute_mode_clock_yuv420_vic_valid_tests,
> +                 drm_connector_hdmi_compute_mode_clock_yuv420_vic_desc);
> +
> +/*
> + * Test that trying to compute the TMDS char rate with the YUV420 format
> + * for a mode that doesn't support the YUV420 encoding returns an error.
> + *
> + * TODO: We should probably test this with all the VIC but the
> + * explicitly supported ones. Since the list of VIC is quite long and
> + * not linear, the best way to support it at the moment would be to
> + * create a custom gen_params function that would only return valid
> + * VICs. At the moment, that function expects to get a pointer back
> + * however, and compilers don't really like casting between integer and
> + * pointers.
> + */
> +static void drm_test_connector_hdmi_compute_mode_clock_yuv420_invalid(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       struct drm_device *drm = &priv->drm;
> +       unsigned long long rate;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 42);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_YUV420);
> +       KUNIT_EXPECT_EQ(test, rate, 0);
> +}
> +
> +/*
> + * Test that for a given mode listed supporting it and an YUV420 output
> + * with 10bpc, the TMDS character rate is equal to 0.625 times the mode
> + * pixel clock.
> + */
> +static void drm_test_connector_hdmi_compute_mode_clock_yuv420_10_bpc(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       struct drm_device *drm = &priv->drm;
> +       unsigned int vic =
> +               drm_connector_hdmi_compute_mode_clock_yuv420_vic_valid_tests[0];
> +       unsigned long long rate;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, vic);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 10, HDMI_COLORSPACE_YUV420);
> +       KUNIT_ASSERT_GT(test, rate, 0);
> +
> +       KUNIT_EXPECT_EQ(test, mode->clock * 625, rate);
> +}
> +
> +/*
> + * Test that for a given mode listed supporting it and an YUV420 output
> + * with 12bpc, the TMDS character rate is equal to 0.75 times the mode
> + * pixel clock.
> + */
> +static void drm_test_connector_hdmi_compute_mode_clock_yuv420_12_bpc(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       struct drm_device *drm = &priv->drm;
> +       unsigned int vic =
> +               drm_connector_hdmi_compute_mode_clock_yuv420_vic_valid_tests[0];
> +       unsigned long long rate;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, vic);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 12, HDMI_COLORSPACE_YUV420);
> +       KUNIT_ASSERT_GT(test, rate, 0);
> +
> +       KUNIT_EXPECT_EQ(test, mode->clock * 750, rate);
> +}
> +
> +/*
> + * Test that for a given mode, the computation of the TMDS character
> + * rate with 8bpc and a YUV422 output fails.
> + */
> +static void drm_test_connector_hdmi_compute_mode_clock_yuv422_8_bpc(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       struct drm_device *drm = &priv->drm;
> +       unsigned long long rate;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 16);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_YUV422);
> +       KUNIT_EXPECT_EQ(test, rate, 0);
> +}
> +
> +/*
> + * Test that for a given mode, the computation of the TMDS character
> + * rate with 10bpc and a YUV422 output fails.
> + */
> +static void drm_test_connector_hdmi_compute_mode_clock_yuv422_10_bpc(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       struct drm_device *drm = &priv->drm;
> +       unsigned long long rate;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 16);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 10, HDMI_COLORSPACE_YUV422);
> +       KUNIT_EXPECT_EQ(test, rate, 0);
> +}
> +
> +/*
> + * Test that for a given mode, the computation of the TMDS character
> + * rate with 12bpc and a YUV422 output succeeds and returns a rate equal
> + * to the mode pixel clock.
> + */
> +static void drm_test_connector_hdmi_compute_mode_clock_yuv422_12_bpc(struct kunit *test)
> +{
> +       struct drm_connector_init_priv *priv = test->priv;
> +       const struct drm_display_mode *mode;
> +       struct drm_device *drm = &priv->drm;
> +       unsigned long long rate;
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 16);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       KUNIT_ASSERT_FALSE(test, mode->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(mode, 12, HDMI_COLORSPACE_YUV422);
> +       KUNIT_ASSERT_GT(test, rate, 0);
> +       KUNIT_EXPECT_EQ(test, mode->clock * 1000, rate);
> +}
> +
> +static struct kunit_case drm_connector_hdmi_compute_mode_clock_tests[] = {
> +       KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb),
> +       KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_10bpc),
> +       KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_10bpc_vic_1),
> +       KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_12bpc),
> +       KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_12bpc_vic_1),
> +       KUNIT_CASE(drm_test_drm_connector_hdmi_compute_mode_clock_rgb_double),
> +       KUNIT_CASE_PARAM(drm_test_connector_hdmi_compute_mode_clock_yuv420_valid,
> +                        drm_connector_hdmi_compute_mode_clock_yuv420_valid_gen_params),
> +       KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv420_invalid),
> +       KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv420_10_bpc),
> +       KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv420_12_bpc),
> +       KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv422_8_bpc),
> +       KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv422_10_bpc),
> +       KUNIT_CASE(drm_test_connector_hdmi_compute_mode_clock_yuv422_12_bpc),
> +       { }
> +};
> +
> +static struct kunit_suite drm_connector_hdmi_compute_mode_clock_test_suite = {
> +       .name = "drm_test_connector_hdmi_compute_mode_clock",
> +       .init = drm_test_connector_init,
> +       .test_cases = drm_connector_hdmi_compute_mode_clock_tests,
> +};
> +
>  kunit_test_suites(
>         &drmm_connector_hdmi_init_test_suite,
>         &drmm_connector_init_test_suite,
>         &drm_connector_attach_broadcast_rgb_property_test_suite,
> +       &drm_connector_hdmi_compute_mode_clock_test_suite,
>         &drm_get_tv_mode_from_name_test_suite,
>         &drm_hdmi_connector_get_broadcast_rgb_name_test_suite,
>         &drm_hdmi_connector_get_output_format_name_test_suite
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 74db5ce47e01..0cc5a8732664 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -38,6 +38,7 @@ struct drm_connector_helper_funcs;
>  struct drm_modeset_acquire_ctx;
>  struct drm_device;
>  struct drm_crtc;
> +struct drm_display_mode;
>  struct drm_encoder;
>  struct drm_panel;
>  struct drm_property;
> @@ -2136,6 +2137,10 @@ void drm_connector_attach_privacy_screen_properties(struct drm_connector *conn);
>  void drm_connector_attach_privacy_screen_provider(
>         struct drm_connector *connector, struct drm_privacy_screen *priv);
>  void drm_connector_update_privacy_screen(const struct drm_connector_state *connector_state);
> +unsigned long long
> +drm_connector_hdmi_compute_mode_clock(const struct drm_display_mode *mode,
> +                                     unsigned int bpc,
> +                                     enum hdmi_colorspace fmt);
>
>  /**
>   * struct drm_tile_group - Tile group metadata
>
> --
> 2.43.0
>


From dave.stevenson at raspberrypi.com  Thu Dec 14 07:04:32 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 15:04:32 +0000
Subject: [PATCH v5 13/44] drm/connector: hdmi: Calculate TMDS character rate
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-13-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-13-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntDzcyLNp=DYesmLcGpaaPgbAhJHWTVsTabdKUARS3V5xA@mail.gmail.com>

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> Most HDMI drivers have some code to calculate the TMDS character rate,
> usually to adjust an internal clock to match what the mode requires.
>
> Since the TMDS character rates mostly depends on the resolution, whether
> we need to repeat pixels or not, the bpc count and the format, we can
> now derive it from the HDMI connector state that stores all those infos
> and remove the duplication from drivers.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  drivers/gpu/drm/drm_atomic.c                       |   1 +
>  drivers/gpu/drm/drm_atomic_state_helper.c          |  44 +++++
>  .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 169 ++++++++++++++++
>  drivers/gpu/drm/tests/drm_kunit_edid.h             | 216 +++++++++++++++++++++
>  include/drm/drm_connector.h                        |   5 +
>  5 files changed, 435 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7aaa2a4d70d9..4f6493f91eed 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1150,6 +1150,7 @@ static void drm_atomic_connector_print_state(struct drm_printer *p,
>                 drm_printf(p, "\toutput_bpc=%u\n", state->hdmi.output_bpc);
>                 drm_printf(p, "\toutput_format=%s\n",
>                            drm_hdmi_connector_get_output_format_name(state->hdmi.output_format));
> +               drm_printf(p, "\ttmds_char_rate=%llu\n", state->hdmi.tmds_char_rate);
>         }
>
>         if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 92e1b087c3d0..74bc3cc53c2d 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -682,6 +682,41 @@ static bool hdmi_is_full_range(const struct drm_connector *connector,
>         return drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_FULL ? true : false;
>  }
>
> +static enum drm_mode_status
> +hdmi_clock_valid(const struct drm_connector *connector,
> +                const struct drm_display_mode *mode,
> +                unsigned long long clock)
> +{
> +       const struct drm_display_info *info = &connector->display_info;
> +
> +       if (info->max_tmds_clock && clock > info->max_tmds_clock * 1000)
> +               return MODE_CLOCK_HIGH;
> +
> +       return MODE_OK;
> +}
> +
> +static int
> +hdmi_compute_clock(const struct drm_connector *connector,
> +                  struct drm_connector_state *state,
> +                  const struct drm_display_mode *mode,
> +                  unsigned int bpc, enum hdmi_colorspace fmt)
> +{
> +       enum drm_mode_status status;
> +       unsigned long long clock;
> +
> +       clock = drm_connector_hdmi_compute_mode_clock(mode, bpc, fmt);
> +       if (!clock)
> +               return -EINVAL;
> +
> +       status = hdmi_clock_valid(connector, mode, clock);
> +       if (status != MODE_OK)
> +               return -EINVAL;
> +
> +       state->hdmi.tmds_char_rate = clock;
> +
> +       return 0;
> +}
> +
>  /**
>   * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
>   * @connector: DRM Connector
> @@ -701,9 +736,18 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
>                 drm_atomic_get_old_connector_state(state, connector);
>         struct drm_connector_state *new_state =
>                 drm_atomic_get_new_connector_state(state, connector);
> +       const struct drm_display_mode *mode =
> +               connector_state_get_mode(new_state);
> +       int ret;
>
>         new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
>
> +       ret = hdmi_compute_clock(connector, new_state, mode,
> +                                new_state->hdmi.output_bpc,
> +                                new_state->hdmi.output_format);
> +       if (ret)
> +               return ret;
> +
>         if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb ||
>             old_state->hdmi.output_bpc != new_state->hdmi.output_bpc ||
>             old_state->hdmi.output_format != new_state->hdmi.output_format) {
> diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> index 4e2ec436987b..d76fafb91025 100644
> --- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> @@ -70,6 +70,9 @@ static int light_up_connector(struct kunit *test,
>         conn_state = drm_atomic_get_connector_state(state, connector);
>         KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
>
> +       conn_state->hdmi.output_bpc = connector->max_bpc;
> +       conn_state->hdmi.output_format = HDMI_COLORSPACE_RGB;
> +
>         ret = drm_atomic_set_crtc_for_connector(conn_state, crtc);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>
> @@ -813,6 +816,146 @@ static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
>         KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
>  }
>
> +/*
> + * Test that when doing a commit which would use RGB 8bpc, the TMDS
> + * clock rate stored in the connector state is equal to the mode clock
> + */
> +static void drm_test_check_tmds_char_rate_rgb_8bpc(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_max_200mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_200mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +       KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_bpc, 8);
> +       KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1000);
> +}
> +
> +/*
> + * Test that when doing a commit which would use RGB 10bpc, the TMDS
> + * clock rate stored in the connector state is equal to 1.25 times the
> + * mode pixel clock
> + */
> +static void drm_test_check_tmds_char_rate_rgb_10bpc(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    10);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +       KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_bpc, 10);
> +       KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1250);
> +}
> +
> +/*
> + * Test that when doing a commit which would use RGB 12bpc, the TMDS
> + * clock rate stored in the connector state is equal to 1.5 times the
> + * mode pixel clock
> + */
> +static void drm_test_check_tmds_char_rate_rgb_12bpc(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +       KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_bpc, 12);
> +       KUNIT_ASSERT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1500);
> +}
> +
>  static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
> @@ -824,6 +967,9 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
>         KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
>         KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
> +       KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_8bpc),
> +       KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_10bpc),
> +       KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_12bpc),
>         /*
>          * TODO: We should have tests to check that a change in the
>          * format triggers a CRTC mode change just like we do for the
> @@ -955,12 +1101,35 @@ static void drm_test_check_format_value(struct kunit *test)
>         KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
>  }
>
> +/*
> + * Test that the value of the output format property out of reset is set
> + * to 0, and will be computed at atomic_check time.
> + */
> +static void drm_test_check_tmds_char_value(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_connector_state *conn_state;
> +       struct drm_connector *conn;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB) |
> +                                                    BIT(HDMI_COLORSPACE_YUV422) |
> +                                                    BIT(HDMI_COLORSPACE_YUV444),
> +                                                    12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       conn_state = conn->state;
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, 0);
> +}
> +
>  static struct kunit_case drm_atomic_helper_connector_hdmi_reset_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_value),
>         KUNIT_CASE(drm_test_check_bpc_8_value),
>         KUNIT_CASE(drm_test_check_bpc_10_value),
>         KUNIT_CASE(drm_test_check_bpc_12_value),
>         KUNIT_CASE(drm_test_check_format_value),
> +       KUNIT_CASE(drm_test_check_tmds_char_value),
>         { }
>  };
>
> diff --git a/drivers/gpu/drm/tests/drm_kunit_edid.h b/drivers/gpu/drm/tests/drm_kunit_edid.h
> index 2bba316de064..24f3377ef0f0 100644
> --- a/drivers/gpu/drm/tests/drm_kunit_edid.h
> +++ b/drivers/gpu/drm/tests/drm_kunit_edid.h
> @@ -103,4 +103,220 @@ const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz[] = {
>    0x00, 0x00, 0x00, 0xd0
>  };
>
> +/*
> + * edid-decode (hex):
> + *
> + * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
> + * 00 21 01 03 81 a0 5a 78 1a 00 00 00 00 00 00 00
> + * 00 00 00 20 00 00 01 01 01 01 01 01 01 01 01 01
> + * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
> + * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
> + * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
> + * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 7a
> + *
> + * 02 03 1b b1 e3 05 00 20 41 10 e2 00 ca 6d 03 0c
> + * 00 12 34 78 28 20 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a8
> + *
> + * ----------------
> + *
> + * Block 0, Base EDID:
> + *   EDID Structure Version & Revision: 1.3
> + *   Vendor & Product Identification:
> + *     Manufacturer: LNX
> + *     Model: 42
> + *     Made in: 2023
> + *   Basic Display Parameters & Features:
> + *     Digital display
> + *     DFP 1.x compatible TMDS
> + *     Maximum image size: 160 cm x 90 cm
> + *     Gamma: 2.20
> + *     Undefined display color type
> + *     First detailed timing is the preferred timing
> + *   Color Characteristics:
> + *     Red  : 0.0000, 0.0000
> + *     Green: 0.0000, 0.0000
> + *     Blue : 0.0000, 0.0000
> + *     White: 0.0000, 0.0000
> + *   Established Timings I & II:
> + *     DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
> + *   Standard Timings: none
> + *   Detailed Timing Descriptors:
> + *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
> + *                  Hfront   88 Hsync  44 Hback  148 Hpol P
> + *                  Vfront    4 Vsync   5 Vback   36 Vpol P
> + *     Display Product Name: 'Test EDID'
> + *     Display Range Limits:
> + *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
> + *     Dummy Descriptor:
> + *   Extension blocks: 1
> + * Checksum: 0x7a
> + *
> + * ----------------
> + *
> + * Block 1, CTA-861 Extension Block:
> + *   Revision: 3
> + *   Underscans IT Video Formats by default
> + *   Supports YCbCr 4:4:4
> + *   Supports YCbCr 4:2:2
> + *   Native detailed modes: 1
> + *   Colorimetry Data Block:
> + *     sRGB
> + *   Video Data Block:
> + *     VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
> + *   Video Capability Data Block:
> + *     YCbCr quantization: Selectable (via AVI YQ)
> + *     RGB quantization: Selectable (via AVI Q)
> + *     PT scan behavior: No Data
> + *     IT scan behavior: Always Underscanned
> + *     CE scan behavior: Always Underscanned
> + *   Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
> + *     Source physical address: 1.2.3.4
> + *     DC_48bit
> + *     DC_36bit
> + *     DC_30bit
> + *     DC_Y444
> + *     Maximum TMDS clock: 200 MHz
> + *     Extended HDMI video details:
> + * Checksum: 0xa8  Unused space in Extension Block: 100 bytes
> + */
> +const unsigned char test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz[] = {
> +  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
> +  0x1a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20,
> +  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
> +  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
> +  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
> +  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
> +  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
> +  0x46, 0x1e, 0x46, 0x0f, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
> +  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x7a, 0x02, 0x03, 0x1b, 0xb1,
> +  0xe3, 0x05, 0x00, 0x20, 0x41, 0x10, 0xe2, 0x00, 0xca, 0x6d, 0x03, 0x0c,
> +  0x00, 0x12, 0x34, 0x78, 0x28, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0xa8
> +};
> +
> +/*
> + * edid-decode (hex):
> + *
> + * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
> + * 00 21 01 03 81 a0 5a 78 0a 00 00 00 00 00 00 00
> + * 00 00 00 20 00 00 01 01 01 01 01 01 01 01 01 01
> + * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
> + * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
> + * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
> + * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 8a
> + *
> + * 02 03 1b b1 e3 05 00 20 41 10 e2 00 ca 6d 03 0c
> + * 00 12 34 78 44 20 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8c
> + *
> + * ----------------
> + *
> + * Block 0, Base EDID:
> + *   EDID Structure Version & Revision: 1.3
> + *   Vendor & Product Identification:
> + *     Manufacturer: LNX
> + *     Model: 42
> + *     Made in: 2023
> + *   Basic Display Parameters & Features:
> + *     Digital display
> + *     DFP 1.x compatible TMDS
> + *     Maximum image size: 160 cm x 90 cm
> + *     Gamma: 2.20
> + *     RGB color display
> + *     First detailed timing is the preferred timing
> + *   Color Characteristics:
> + *     Red  : 0.0000, 0.0000
> + *     Green: 0.0000, 0.0000
> + *     Blue : 0.0000, 0.0000
> + *     White: 0.0000, 0.0000
> + *   Established Timings I & II:
> + *     DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
> + *   Standard Timings: none
> + *   Detailed Timing Descriptors:
> + *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
> + *                  Hfront   88 Hsync  44 Hback  148 Hpol P
> + *                  Vfront    4 Vsync   5 Vback   36 Vpol P
> + *     Display Product Name: 'Test EDID'
> + *     Display Range Limits:
> + *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
> + *     Dummy Descriptor:
> + *   Extension blocks: 1
> + * Checksum: 0x8a
> + *
> + * ----------------
> + *
> + * Block 1, CTA-861 Extension Block:
> + *   Revision: 3
> + *   Underscans IT Video Formats by default
> + *   Supports YCbCr 4:4:4
> + *   Supports YCbCr 4:2:2
> + *   Native detailed modes: 1
> + *   Colorimetry Data Block:
> + *     sRGB
> + *   Video Data Block:
> + *     VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
> + *   Video Capability Data Block:
> + *     YCbCr quantization: Selectable (via AVI YQ)
> + *     RGB quantization: Selectable (via AVI Q)
> + *     PT scan behavior: No Data
> + *     IT scan behavior: Always Underscanned
> + *     CE scan behavior: Always Underscanned
> + *   Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
> + *     Source physical address: 1.2.3.4
> + *     DC_48bit
> + *     DC_36bit
> + *     DC_30bit
> + *     DC_Y444
> + *     Maximum TMDS clock: 340 MHz
> + *     Extended HDMI video details:
> + * Checksum: 0x8c  Unused space in Extension Block: 100 bytes
> + */
> +const unsigned char test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz[] = {
> +  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
> +  0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20,
> +  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
> +  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
> +  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
> +  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
> +  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
> +  0x46, 0x1e, 0x46, 0x0f, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
> +  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x8a, 0x02, 0x03, 0x1b, 0xb1,
> +  0xe3, 0x05, 0x00, 0x20, 0x41, 0x10, 0xe2, 0x00, 0xca, 0x6d, 0x03, 0x0c,
> +  0x00, 0x12, 0x34, 0x78, 0x44, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x8c
> +};
> +
>  #endif // DRM_KUNIT_EDID_H_
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 0cc5a8732664..59016d9c17f5 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1085,6 +1085,11 @@ struct drm_connector_state {
>                  * @output_format: Pixel format to output in.
>                  */
>                 enum hdmi_colorspace output_format;
> +
> +               /**
> +                * @tmds_char_rate: TMDS Character Rate, in Hz.
> +                */
> +               unsigned long long tmds_char_rate;
>         } hdmi;
>  };
>
>
> --
> 2.43.0
>
>


From ninad at linux.ibm.com  Thu Dec 14 07:04:41 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Thu, 14 Dec 2023 09:04:41 -0600
Subject: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
In-Reply-To: <5b98538a-8ffe-42ec-b020-514dcfcebba3@linaro.org>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-9-ninad@linux.ibm.com>
 <5b98538a-8ffe-42ec-b020-514dcfcebba3@linaro.org>
Message-ID: <7b14aa01-24c2-425c-8bf3-48e5b7890b95@linux.ibm.com>

Hello Krzysztof,

On 12/12/23 14:26, Krzysztof Kozlowski wrote:
> On 12/12/2023 17:40, Ninad Palsule wrote:
>> This drop adds following devices in the device tree.
>> - EEPROM/VPD
>> - Power supplies
>> - Humidity, pressure and temperature sensors.
>> - Trusted platform module(TPM) chip
>>
>> Tested:
>>      This board is tested using the simics simulator.
>>
>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>> ---
> Don't mix DTS with drivers. DTS and drivers go via different subsystems
> and cannot have dependencies, so why DTS is patch #6, then driver #7 and
> now again DTS #7?
I have sent a driver patch as a separate patchset and removed it from 
this patchset.
>
>
>>   .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 76 +++++++++++++++++++
>>   1 file changed, 76 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> index 75562aa63701..d960b938fe8d 100644
>> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> @@ -461,6 +461,11 @@ &kcs3 {
>>   &i2c0 {
>>   	status = "okay";
>>   
>> +	eeprom at 50 {
>> +		compatible = "atmel,24c64";
>> +		reg = <0x50>;
>> +	};
>> +
>>   	regulator at 60 {
>>   		compatible = "maxim,max8952";
>>   		reg = <0x60>;
>> @@ -655,6 +660,25 @@ pca0: pca9539 at 74 {
>>   
>>   &i2c2 {
>>   	status = "okay";
>> +
>> +	power-supply at 58 {
>> +		compatible = "ibm,cffps";
>> +		reg = <0x58>;
>> +	};
>> +
>> +	power-supply at 59 {
>> +		compatible = "ibm,cffps";
>> +		reg = <0x59>;
>> +	};
>> +
>> +	power-supply at 5a {
>> +		compatible = "ibm,cffps";
>> +		reg = <0x5a>;
>> +	};
> Missing blank line

Fixed it.

Thanks for the review.

Regards,

Ninad

>
>> +	power-supply at 5b {
>> +		compatible = "ibm,cffps";
>> +		reg = <0x5b>;
>> +	};
>
> Best regards,
> Krzysztof
>


From dave.stevenson at raspberrypi.com  Thu Dec 14 07:06:18 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 15:06:18 +0000
Subject: [PATCH v5 14/44] drm/connector: hdmi: Add custom hook to filter
 TMDS character rate
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-14-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-14-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntB9ngzpTm48+gdf_qGVj-ZCZP8=bucjC25--ye-wBY8fw@mail.gmail.com>

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> Most of the HDMI controllers have an upper TMDS character rate limit
> they can't exceed. On "embedded"-grade display controllers, it will
> typically be lower than what high-grade monitors can provide these days,
> so drivers will filter the TMDS character rate based on the controller
> capabilities.
>
> To make that easier to handle for drivers, let's provide an optional
> hook to be implemented by drivers so they can tell the HDMI controller
> helpers if a given TMDS character rate is reachable for them or not.
>
> This will then be useful to figure out the best format and bpc count for
> a given mode.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  drivers/gpu/drm/drm_atomic_state_helper.c          |  9 +++
>  drivers/gpu/drm/drm_connector.c                    |  4 ++
>  .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 69 ++++++++++++++++++++++
>  drivers/gpu/drm/tests/drm_connector_test.c         | 15 +++++
>  include/drm/drm_connector.h                        | 30 ++++++++++
>  5 files changed, 127 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 74bc3cc53c2d..a36edda590f8 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -687,11 +687,20 @@ hdmi_clock_valid(const struct drm_connector *connector,
>                  const struct drm_display_mode *mode,
>                  unsigned long long clock)
>  {
> +       const struct drm_connector_hdmi_funcs *funcs = connector->hdmi.funcs;
>         const struct drm_display_info *info = &connector->display_info;
>
>         if (info->max_tmds_clock && clock > info->max_tmds_clock * 1000)
>                 return MODE_CLOCK_HIGH;
>
> +       if (funcs && funcs->tmds_char_rate_valid) {
> +               enum drm_mode_status status;
> +
> +               status = funcs->tmds_char_rate_valid(connector, mode, clock);
> +               if (status != MODE_OK)
> +                       return status;
> +       }
> +
>         return MODE_OK;
>  }
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 667326b09acc..9f314fee26ce 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -457,6 +457,7 @@ EXPORT_SYMBOL(drmm_connector_init);
>   * @dev: DRM device
>   * @connector: A pointer to the HDMI connector to init
>   * @funcs: callbacks for this connector
> + * @hdmi_funcs: HDMI-related callbacks for this connector
>   * @connector_type: user visible type of the connector
>   * @ddc: optional pointer to the associated ddc adapter
>   * @supported_formats: Bitmask of @hdmi_colorspace listing supported output formats
> @@ -476,6 +477,7 @@ EXPORT_SYMBOL(drmm_connector_init);
>  int drmm_connector_hdmi_init(struct drm_device *dev,
>                              struct drm_connector *connector,
>                              const struct drm_connector_funcs *funcs,
> +                            const struct drm_connector_hdmi_funcs *hdmi_funcs,
>                              int connector_type,
>                              struct i2c_adapter *ddc,
>                              unsigned long supported_formats,
> @@ -512,6 +514,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
>         if (max_bpc > 8)
>                 drm_connector_attach_hdr_output_metadata_property(connector);
>
> +       connector->hdmi.funcs = hdmi_funcs;
> +
>         return 0;
>  }
>  EXPORT_SYMBOL(drmm_connector_hdmi_init);
> diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> index d76fafb91025..e7dbdd4a4e7f 100644
> --- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> @@ -110,6 +110,21 @@ static int set_connector_edid(struct kunit *test, struct drm_connector *connecto
>         return 0;
>  }
>
> +static const struct drm_connector_hdmi_funcs dummy_connector_hdmi_funcs = {
> +};
> +
> +static enum drm_mode_status
> +reject_connector_tmds_char_rate_valid(const struct drm_connector *connector,
> +                                      const struct drm_display_mode *mode,
> +                                      unsigned long long tmds_rate)
> +{
> +       return MODE_BAD;
> +}
> +
> +static const struct drm_connector_hdmi_funcs reject_connector_hdmi_funcs = {
> +       .tmds_char_rate_valid   = reject_connector_tmds_char_rate_valid,
> +};
> +
>  static int dummy_connector_get_modes(struct drm_connector *connector)
>  {
>         struct drm_atomic_helper_connector_hdmi_priv *priv =
> @@ -192,6 +207,7 @@ drm_atomic_helper_connector_hdmi_init(struct kunit *test,
>         conn = &priv->connector;
>         ret = drmm_connector_hdmi_init(drm, conn,
>                                        &dummy_connector_funcs,
> +                                      &dummy_connector_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        NULL,
>                                        formats,
> @@ -956,6 +972,58 @@ static void drm_test_check_tmds_char_rate_rgb_12bpc(struct kunit *test)
>         KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1500);
>  }
>
> +/*
> + * Test that if we filter a rate through our hook, it's indeed rejected
> + * by the whole atomic_check logic.
> + *
> + * We do so by first doing a commit on the pipeline to make sure that it
> + * works, change the HDMI helpers pointer, and then try the same commit
> + * again to see if it fails as it should.
> + */
> +static void drm_test_check_hdmi_funcs_reject_rate(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_atomic_state *state;
> +       struct drm_display_mode *preferred;
> +       struct drm_crtc_state *crtc_state;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       conn = &priv->connector;
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       /* You shouldn't be doing that at home. */
> +       conn->hdmi.funcs = &reject_connector_hdmi_funcs;
> +
> +       state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
> +
> +       crtc_state = drm_atomic_get_crtc_state(state, crtc);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
> +
> +       crtc_state->connectors_changed = true;
> +
> +       ret = drm_atomic_check_only(state);
> +       KUNIT_EXPECT_LT(test, ret, 0);
> +}
> +
>  static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
> @@ -965,6 +1033,7 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_limited_cea_mode_vic_1),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
> +       KUNIT_CASE(drm_test_check_hdmi_funcs_reject_rate),
>         KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
>         KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
>         KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_8bpc),
> diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
> index 0a838924a546..6a3651b08c81 100644
> --- a/drivers/gpu/drm/tests/drm_connector_test.c
> +++ b/drivers/gpu/drm/tests/drm_connector_test.c
> @@ -22,6 +22,9 @@ struct drm_connector_init_priv {
>         struct i2c_adapter ddc;
>  };
>
> +static const struct drm_connector_hdmi_funcs dummy_hdmi_funcs = {
> +};
> +
>  static const struct drm_connector_funcs dummy_funcs = {
>         .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
>         .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> @@ -187,6 +190,7 @@ static void drm_test_connector_hdmi_init_valid(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_RGB),
> @@ -205,6 +209,7 @@ static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        NULL,
>                                        BIT(HDMI_COLORSPACE_RGB),
> @@ -223,6 +228,7 @@ static void drm_test_connector_hdmi_init_bpc_invalid(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_RGB),
> @@ -241,6 +247,7 @@ static void drm_test_connector_hdmi_init_bpc_null(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_RGB),
> @@ -263,6 +270,7 @@ static void drm_test_connector_hdmi_init_bpc_8(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_RGB),
> @@ -297,6 +305,7 @@ static void drm_test_connector_hdmi_init_bpc_10(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_RGB),
> @@ -331,6 +340,7 @@ static void drm_test_connector_hdmi_init_bpc_12(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_RGB),
> @@ -361,6 +371,7 @@ static void drm_test_connector_hdmi_init_formats_empty(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
>                                        0,
> @@ -379,6 +390,7 @@ static void drm_test_connector_hdmi_init_formats_no_rgb(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_YUV422),
> @@ -398,6 +410,7 @@ static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        connector_type,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_RGB),
> @@ -431,6 +444,7 @@ static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
>
>         ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        connector_type,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_RGB),
> @@ -695,6 +709,7 @@ static void drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector(
>
>         ret = drmm_connector_hdmi_init(&priv->drm, connector,
>                                        &dummy_funcs,
> +                                      &dummy_hdmi_funcs,
>                                        DRM_MODE_CONNECTOR_HDMIA,
>                                        &priv->ddc,
>                                        BIT(HDMI_COLORSPACE_RGB),
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 59016d9c17f5..3eaf4d54364d 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1093,6 +1093,30 @@ struct drm_connector_state {
>         } hdmi;
>  };
>
> +/**
> + * struct drm_connector_hdmi_funcs - drm_hdmi_connector control functions
> + */
> +struct drm_connector_hdmi_funcs {
> +       /**
> +        * @tmds_char_rate_valid:
> +        *
> +        * This callback is invoked at atomic_check time to figure out
> +        * whether a particular TMDS character rate is supported by the
> +        * driver.
> +        *
> +        * The @tmds_char_rate_valid callback is optional.
> +        *
> +        * Returns:
> +        *
> +        * Either &drm_mode_status.MODE_OK or one of the failure reasons
> +        * in &enum drm_mode_status.
> +        */
> +       enum drm_mode_status
> +       (*tmds_char_rate_valid)(const struct drm_connector *connector,
> +                               const struct drm_display_mode *mode,
> +                               unsigned long long tmds_rate);
> +};
> +
>  /**
>   * struct drm_connector_funcs - control connectors on a given device
>   *
> @@ -1967,6 +1991,11 @@ struct drm_connector {
>                  * supported by the controller.
>                  */
>                 unsigned long supported_formats;
> +
> +               /**
> +                * @funcs: HDMI connector Control Functions
> +                */
> +               const struct drm_connector_hdmi_funcs *funcs;
>         } hdmi;
>  };
>
> @@ -1989,6 +2018,7 @@ int drmm_connector_init(struct drm_device *dev,
>  int drmm_connector_hdmi_init(struct drm_device *dev,
>                              struct drm_connector *connector,
>                              const struct drm_connector_funcs *funcs,
> +                            const struct drm_connector_hdmi_funcs *hdmi_funcs,
>                              int connector_type,
>                              struct i2c_adapter *ddc,
>                              unsigned long supported_formats,
>
> --
> 2.43.0
>


From ninad at linux.ibm.com  Thu Dec 14 07:06:54 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Thu, 14 Dec 2023 09:06:54 -0600
Subject: [PATCH v1 3/8] ARM: dts: aspeed: System1: IBM system1 BMC board
In-Reply-To: <81d90c0d-9d7e-43a9-ade8-16b85a242b48@linaro.org>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-4-ninad@linux.ibm.com>
 <81d90c0d-9d7e-43a9-ade8-16b85a242b48@linaro.org>
Message-ID: <e8e4e5fe-5fa6-4098-97fc-7c6a48da9c4e@linux.ibm.com>

Hello Krzysztof,


On 12/12/23 14:20, Krzysztof Kozlowski wrote:
> On 12/12/2023 17:39, Ninad Palsule wrote:
>> From: Andrew Geissler <geissonator at yahoo.com>
>>
>> Add a device tree for IBM system1 BMC board. It uses AST2600 SOC.
>>
>> Tested:
>>      This board is tested using the simics simulator.
>>
>> Signed-off-by: Andrew Geissler <geissonator at yahoo.com>
>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>> ---
>>   arch/arm/boot/dts/aspeed/Makefile             |   1 +
>>   .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 188 ++++++++++++++++++
>>   2 files changed, 189 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>>
>> diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
>> index 3e3e6b96cb79..6f7ed11978ff 100644
>> --- a/arch/arm/boot/dts/aspeed/Makefile
>> +++ b/arch/arm/boot/dts/aspeed/Makefile
>> @@ -35,6 +35,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>>   	aspeed-bmc-ibm-rainier.dtb \
>>   	aspeed-bmc-ibm-rainier-1s4u.dtb \
>>   	aspeed-bmc-ibm-rainier-4u.dtb \
>> +	aspeed-bmc-ibm-system1.dtb \
>>   	aspeed-bmc-intel-s2600wf.dtb \
>>   	aspeed-bmc-inspur-fp5280g2.dtb \
>>   	aspeed-bmc-inspur-nf5280m6.dtb \
>> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> new file mode 100644
>> index 000000000000..01291b407f59
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> @@ -0,0 +1,188 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +// Copyright 2023 IBM Corp.
>> +/dts-v1/;
>> +
>> +#include "aspeed-g6.dtsi"
>> +#include <dt-bindings/gpio/aspeed-gpio.h>
>> +#include <dt-bindings/i2c/i2c.h>
>> +#include <dt-bindings/leds/leds-pca955x.h>
>> +
>> +/ {
>> +	model = "System1";
>> +	compatible = "ibm,system1-bmc", "aspeed,ast2600";
>> +
>> +	chosen {
>> +		stdout-path = &uart5;
>> +		bootargs = "console=ttyS4,115200n8 earlycon";
> Drop early con, debugging feature not release. Then use stdout path
> alone, so drop console as well.
Fixed as per your suggestion.
>
>> +	};
>> +
>> +	memory at 80000000 {
>> +		device_type = "memory";
>> +		reg = <0x80000000 0x40000000>;
>> +	};
>> +
>> +	reserved-memory {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		event_log: tcg_event_log at b3d00000 {
> No underscores in node names.

Fixed.

Thanks for the review.

Regards,

Ninad

>
>
> Best regards,
> Krzysztof
>


From semen.protsenko at linaro.org  Thu Dec 14 07:07:28 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:07:28 -0600
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate
 clock names
In-Reply-To: <20231214105243.3707730-2-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-2-tudor.ambarus@linaro.org>
Message-ID: <CAPLW+4kr=aVjuqGz3ps5f6EzM+QASTFEoB57g+fR7jKH0s+1Zw@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> The gs101 clock names are derived from the clock register names under
> some certain rules. In particular, for the gate clocks the following is
> documented and expected in the gs101 clock driver:
>
>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>
>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>

Doesn't it break existing gs101 device tree?

> The CMU TOP gate clock names missed to include the required "CMU"
> differentiator which will cause name collisions with the gate clock names
> of other clock units. Fix the TOP gate clock names and include "CMU" in
> their name.
>
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---

(snip)


From alexandre.torgue at foss.st.com  Thu Dec 14 07:09:09 2023
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 14 Dec 2023 16:09:09 +0100
Subject: [PATCH v2] ARM: dts: stm32: minor whitespace cleanup around '='
In-Reply-To: <20231127093420.20473-1-krzysztof.kozlowski@linaro.org>
References: <20231127093420.20473-1-krzysztof.kozlowski@linaro.org>
Message-ID: <e0d83b7f-509e-4d9b-8ad8-7baa2889e484@foss.st.com>



On 11/27/23 10:34, Krzysztof Kozlowski wrote:
> The DTS code coding style expects exactly one space before and after '='
> sign.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> ---
> 
> Changes in v2:
> 1. Split previous commit touching entire 'st' directory.

Thanks Krzysztof,

Applied on stm32-next.

Alex

...


From dave.stevenson at raspberrypi.com  Thu Dec 14 07:10:43 2023
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Thu, 14 Dec 2023 15:10:43 +0000
Subject: [PATCH v5 15/44] drm/connector: hdmi: Compute bpc and format automatically
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-15-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org> <20231207-kms-hdmi-connector-state-v5-15-6538e19d634d@kernel.org>
Message-ID: <CAPY8ntBQ+qY9441-rMzq_JAoYAaY_r+E-ADv7Wry0tJNTzKpwg@mail.gmail.com>

Hi Maxime

On Thu, 7 Dec 2023 at 15:50, Maxime Ripard <mripard at kernel.org> wrote:
>
> Now that we have all the infrastructure needed, we can add some code
> that will, for a given connector state and mode, compute the best output
> format and bpc.
>
> The algorithm is the same one than the one already found in i915 and
> vc4.

We seem to have some extra words in this sentence.
"The algorithm is the same as that already found in i915 and vc4."?
Possibly "equivalent to" instead of "the same as", as i915 is slightly
different.

> Signed-off-by: Maxime Ripard <mripard at kernel.org>
> ---
>  drivers/gpu/drm/drm_atomic_state_helper.c          | 183 ++++++-
>  .../gpu/drm/tests/drm_atomic_state_helper_test.c   | 529 ++++++++++++++++++++-
>  drivers/gpu/drm/tests/drm_kunit_edid.h             | 160 +++++++
>  3 files changed, 860 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index a36edda590f8..2442b5a2d94f 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -682,6 +682,96 @@ static bool hdmi_is_full_range(const struct drm_connector *connector,
>         return drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_FULL ? true : false;
>  }
>
> +static bool
> +sink_supports_format_bpc(const struct drm_connector *connector,
> +                        const struct drm_display_info *info,
> +                        const struct drm_display_mode *mode,
> +                        unsigned int format, unsigned int bpc)
> +{
> +       struct drm_device *dev = connector->dev;
> +       u8 vic = drm_match_cea_mode(mode);
> +
> +       if (vic == 1 && bpc != 8) {
> +               drm_dbg(dev, "VIC1 requires a bpc of 8, got %u\n", bpc);
> +               return false;
> +       }
> +
> +       if (!info->is_hdmi &&
> +           (format != HDMI_COLORSPACE_RGB || bpc != 8)) {
> +               drm_dbg(dev, "DVI Monitors require an RGB output at 8 bpc\n");
> +               return false;
> +       }
> +
> +       if (!(connector->hdmi.supported_formats & BIT(format))) {
> +               drm_dbg(dev, "%s format unsupported by the connector.\n",
> +                       drm_hdmi_connector_get_output_format_name(format));
> +               return false;
> +       }
> +
> +       switch (format) {
> +       case HDMI_COLORSPACE_RGB:
> +               drm_dbg(dev, "RGB Format, checking the constraints.\n");
> +
> +               if (!(info->color_formats & DRM_COLOR_FORMAT_RGB444))
> +                       return false;

We've dropped this check from vc4 in our downstream kernel as it stops
you using the prebaked EDIDs (eg drm.edid_firmware=edid/1024x768.bin),
or any other EDID that is defined as an analog monitor.
The EDID parsing bombs out at [1], so info->color_formats gets left at 0.

RGB is mandatory for both DVI and HDMI, so rejecting it seems overly fussy.

I don't see i915 making use of info->color_formats at all. The
equivalent function looks to be intel_hdmi_sink_bpc_possible [2] which
just accepts anything for 8bpc output.

  Dave

PS I'll have to defer looking at patch 16 for another day - it just
needs a bit more analysis than I can fit in today.

[1] https://elixir.free-electrons.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L6533
[2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_hdmi.c#L1909

> +
> +               if (bpc == 10 && !(info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_30)) {
> +                       drm_dbg(dev, "10 BPC but sink doesn't support Deep Color 30.\n");
> +                       return false;
> +               }
> +
> +               if (bpc == 12 && !(info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_36)) {
> +                       drm_dbg(dev, "12 BPC but sink doesn't support Deep Color 36.\n");
> +                       return false;
> +               }
> +
> +               drm_dbg(dev, "RGB format supported in that configuration.\n");
> +
> +               return true;
> +
> +       case HDMI_COLORSPACE_YUV422:
> +               drm_dbg(dev, "YUV422 format, checking the constraints.\n");
> +
> +               if (!(info->color_formats & DRM_COLOR_FORMAT_YCBCR422)) {
> +                       drm_dbg(dev, "Sink doesn't support YUV422.\n");
> +                       return false;
> +               }
> +
> +               if (bpc != 12) {
> +                       drm_dbg(dev, "YUV422 only supports 12 bpc.\n");
> +                       return false;
> +               }
> +
> +               drm_dbg(dev, "YUV422 format supported in that configuration.\n");
> +
> +               return true;
> +
> +       case HDMI_COLORSPACE_YUV444:
> +               drm_dbg(dev, "YUV444 format, checking the constraints.\n");
> +
> +               if (!(info->color_formats & DRM_COLOR_FORMAT_YCBCR444)) {
> +                       drm_dbg(dev, "Sink doesn't support YUV444.\n");
> +                       return false;
> +               }
> +
> +               if (bpc == 10 && !(info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_30)) {
> +                       drm_dbg(dev, "10 BPC but sink doesn't support Deep Color 30.\n");
> +                       return false;
> +               }
> +
> +               if (bpc == 12 && !(info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_36)) {
> +                       drm_dbg(dev, "12 BPC but sink doesn't support Deep Color 36.\n");
> +                       return false;
> +               }
> +
> +               drm_dbg(dev, "YUV444 format supported in that configuration.\n");
> +
> +               return true;
> +       }
> +
> +       return false;
> +}
> +
>  static enum drm_mode_status
>  hdmi_clock_valid(const struct drm_connector *connector,
>                  const struct drm_display_mode *mode,
> @@ -726,6 +816,95 @@ hdmi_compute_clock(const struct drm_connector *connector,
>         return 0;
>  }
>
> +static bool
> +hdmi_try_format_bpc(const struct drm_connector *connector,
> +                   struct drm_connector_state *state,
> +                   const struct drm_display_mode *mode,
> +                   unsigned int bpc, enum hdmi_colorspace fmt)
> +{
> +       const struct drm_display_info *info = &connector->display_info;
> +       struct drm_device *dev = connector->dev;
> +       int ret;
> +
> +       drm_dbg(dev, "Trying %s output format\n",
> +               drm_hdmi_connector_get_output_format_name(fmt));
> +
> +       if (!sink_supports_format_bpc(connector, info, mode, fmt, bpc)) {
> +               drm_dbg(dev, "%s output format not supported with %u bpc\n",
> +                       drm_hdmi_connector_get_output_format_name(fmt), bpc);
> +               return false;
> +       }
> +
> +       ret = hdmi_compute_clock(connector, state, mode, bpc, fmt);
> +       if (ret) {
> +               drm_dbg(dev, "Couldn't compute clock for %s output format and %u bpc\n",
> +                       drm_hdmi_connector_get_output_format_name(fmt), bpc);
> +               return false;
> +       }
> +
> +       drm_dbg(dev, "%s output format supported with %u (TMDS char rate: %llu Hz)\n",
> +               drm_hdmi_connector_get_output_format_name(fmt), bpc, state->hdmi.tmds_char_rate);
> +
> +       return true;
> +}
> +
> +static int
> +hdmi_compute_format(const struct drm_connector *connector,
> +                   struct drm_connector_state *state,
> +                   const struct drm_display_mode *mode,
> +                   unsigned int bpc)
> +{
> +       struct drm_device *dev = connector->dev;
> +
> +       if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_RGB)) {
> +               state->hdmi.output_format = HDMI_COLORSPACE_RGB;
> +               return 0;
> +       }
> +
> +       if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_YUV422)) {
> +               state->hdmi.output_format = HDMI_COLORSPACE_YUV422;
> +               return 0;
> +       }
> +
> +       drm_dbg(dev, "Failed. No Format Supported for that bpc count.\n");
> +
> +       return -EINVAL;
> +}
> +
> +static int
> +hdmi_compute_config(const struct drm_connector *connector,
> +                   struct drm_connector_state *state,
> +                   const struct drm_display_mode *mode)
> +{
> +       struct drm_device *dev = connector->dev;
> +       unsigned int max_bpc = clamp_t(unsigned int,
> +                                      state->max_bpc,
> +                                      8, connector->max_bpc);
> +       unsigned int bpc;
> +       int ret;
> +
> +       for (bpc = max_bpc; bpc >= 8; bpc -= 2) {
> +               drm_dbg(dev, "Trying with a %d bpc output\n", bpc);
> +
> +               ret = hdmi_compute_format(connector, state, mode, bpc);
> +               if (ret)
> +                       continue;
> +
> +               state->hdmi.output_bpc = bpc;
> +
> +               drm_dbg(dev,
> +                       "Mode %ux%u @ %uHz: Found configuration: bpc: %u, fmt: %s, clock: %llu\n",
> +                       mode->hdisplay, mode->vdisplay, drm_mode_vrefresh(mode),
> +                       state->hdmi.output_bpc,
> +                       drm_hdmi_connector_get_output_format_name(state->hdmi.output_format),
> +                       state->hdmi.tmds_char_rate);
> +
> +               return 0;
> +       }
> +
> +       return -EINVAL;
> +}
> +
>  /**
>   * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
>   * @connector: DRM Connector
> @@ -751,9 +930,7 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
>
>         new_state->hdmi.is_full_range = hdmi_is_full_range(connector, new_state);
>
> -       ret = hdmi_compute_clock(connector, new_state, mode,
> -                                new_state->hdmi.output_bpc,
> -                                new_state->hdmi.output_format);
> +       ret = hdmi_compute_config(connector, new_state, mode);
>         if (ret)
>                 return ret;
>
> diff --git a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> index e7dbdd4a4e7f..860e34b00fee 100644
> --- a/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_atomic_state_helper_test.c
> @@ -70,9 +70,6 @@ static int light_up_connector(struct kunit *test,
>         conn_state = drm_atomic_get_connector_state(state, connector);
>         KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
>
> -       conn_state->hdmi.output_bpc = connector->max_bpc;
> -       conn_state->hdmi.output_format = HDMI_COLORSPACE_RGB;
> -
>         ret = drm_atomic_set_crtc_for_connector(conn_state, crtc);
>         KUNIT_EXPECT_EQ(test, ret, 0);
>
> @@ -720,10 +717,15 @@ static void drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
>                                                      10);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
>         ctx = drm_kunit_helper_acquire_ctx_alloc(test);
>         KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
>
> -       conn = &priv->connector;
>         preferred = find_preferred_mode(conn);
>         KUNIT_ASSERT_NOT_NULL(test, preferred);
>
> @@ -741,11 +743,11 @@ static void drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
>         old_conn_state = drm_atomic_get_old_connector_state(state, conn);
>         KUNIT_ASSERT_NOT_ERR_OR_NULL(test, old_conn_state);
>
> -       new_conn_state->hdmi.output_bpc = 8;
> +       new_conn_state->max_requested_bpc = 8;
>
>         KUNIT_ASSERT_NE(test,
> -                       old_conn_state->hdmi.output_bpc,
> -                       new_conn_state->hdmi.output_bpc);
> +                       old_conn_state->max_requested_bpc,
> +                       new_conn_state->max_requested_bpc);
>
>         ret = drm_atomic_check_only(state);
>         KUNIT_ASSERT_EQ(test, ret, 0);
> @@ -789,10 +791,15 @@ static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
>                                                      10);
>         KUNIT_ASSERT_NOT_NULL(test, priv);
>
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
>         ctx = drm_kunit_helper_acquire_ctx_alloc(test);
>         KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
>
> -       conn = &priv->connector;
>         preferred = find_preferred_mode(conn);
>         KUNIT_ASSERT_NOT_NULL(test, preferred);
>
> @@ -832,6 +839,56 @@ static void drm_test_check_output_bpc_crtc_mode_not_changed(struct kunit *test)
>         KUNIT_EXPECT_FALSE(test, crtc_state->mode_changed);
>  }
>
> +/*
> + * Test that if we have an HDMI connector but a !HDMI display, we always
> + * output RGB with 8 bpc.
> + */
> +static void drm_test_check_output_bpc_dvi(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_info *info;
> +       struct drm_display_mode *preferred;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB) |
> +                                                    BIT(HDMI_COLORSPACE_YUV422) |
> +                                                    BIT(HDMI_COLORSPACE_YUV444),
> +                                                    12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_dvi_1080p,
> +                                ARRAY_SIZE(test_edid_dvi_1080p));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       info = &conn->display_info;
> +       KUNIT_ASSERT_FALSE(test, info->is_hdmi);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 8);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +}
> +
>  /*
>   * Test that when doing a commit which would use RGB 8bpc, the TMDS
>   * clock rate stored in the connector state is equal to the mode clock
> @@ -1024,6 +1081,452 @@ static void drm_test_check_hdmi_funcs_reject_rate(struct kunit *test)
>         KUNIT_EXPECT_LT(test, ret, 0);
>  }
>
> +/*
> + * Test that if:
> + * - We have an HDMI connector supporting RGB only
> + * - The chosen mode has a TMDS character rate higher than the display
> + *   supports in RGB/12bpc
> + * - The chosen mode has a TMDS character rate lower than the display
> + *   supports in RGB/10bpc.
> + *
> + * Then we will pick the latter, and the computed TMDS character rate
> + * will be equal to 1.25 times the mode pixel clock.
> + */
> +static void drm_test_check_max_tmds_rate_bpc_fallback(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_info *info;
> +       struct drm_display_mode *preferred;
> +       unsigned long long rate;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       info = &conn->display_info;
> +       KUNIT_ASSERT_TRUE(test, info->is_hdmi);
> +       KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +       KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_GT(test, rate, info->max_tmds_clock * 1000);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 10, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 10);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1250);
> +}
> +
> +/*
> + * Test that if:
> + * - We have an HDMI connector supporting both RGB and YUV422 and up to
> + *   12 bpc
> + * - The chosen mode has a TMDS character rate higher than the display
> + *   supports in RGB/12bpc
> + * - The chosen mode has a TMDS character rate lower than the display
> + *   supports in YUV422/12bpc.
> + *
> + * Then we will pick the latter, and the computed TMDS character rate
> + * will be equal to the mode pixel clock.
> + */
> +static void drm_test_check_max_tmds_rate_format_fallback(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_info *info;
> +       struct drm_display_mode *preferred;
> +       unsigned long long rate;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB) |
> +                                                    BIT(HDMI_COLORSPACE_YUV422) |
> +                                                    BIT(HDMI_COLORSPACE_YUV444),
> +                                                    12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       info = &conn->display_info;
> +       KUNIT_ASSERT_TRUE(test, info->is_hdmi);
> +       KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +       KUNIT_ASSERT_FALSE(test, preferred->flags & DRM_MODE_FLAG_DBLCLK);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_GT(test, rate, info->max_tmds_clock * 1000);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_YUV422);
> +       KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 12);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_YUV422);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate, preferred->clock * 1000);
> +}
> +
> +/*
> + * Test that if a driver and screen supports RGB and YUV formats, and we
> + * try to set the VIC 1 mode, we end up with 8bpc RGB even if we could
> + * have had a higher bpc.
> + */
> +static void drm_test_check_output_bpc_format_vic_1(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_info *info;
> +       struct drm_display_mode *mode;
> +       unsigned long long rate;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB) |
> +                                                    BIT(HDMI_COLORSPACE_YUV422) |
> +                                                    BIT(HDMI_COLORSPACE_YUV444),
> +                                                    12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       info = &conn->display_info;
> +       KUNIT_ASSERT_TRUE(test, info->is_hdmi);
> +       KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       mode = drm_display_mode_from_cea_vic(drm, 1);
> +       KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> +       /*
> +        * NOTE: We can't use drm_connector_hdmi_compute_mode_clock()
> +        * here because we're trying to get the rate of an invalid
> +        * configuration.
> +        *
> +        * Thus, we have to calculate the rate by hand.
> +        */
> +       rate = mode->clock * 1500;
> +       KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, mode, ctx);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 8);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +}
> +
> +/*
> + * Test that if a driver supports only RGB but the screen also supports
> + * YUV formats, we only end up with an RGB format.
> + */
> +static void drm_test_check_output_bpc_format_driver_rgb_only(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_info *info;
> +       struct drm_display_mode *preferred;
> +       unsigned long long rate;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       info = &conn->display_info;
> +       KUNIT_ASSERT_TRUE(test, info->is_hdmi);
> +       KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       /*
> +        * We're making sure that YUV422 would be the preferred option
> +        * here: we're always favouring higher bpc, we can't have RGB
> +        * because the TMDS character rate exceeds the maximum supported
> +        * by the display, and YUV422 works for that display.
> +        *
> +        * But since the driver only supports RGB, we should fallback to
> +        * a lower bpc with RGB.
> +        */
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_GT(test, rate, info->max_tmds_clock * 1000);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_YUV422);
> +       KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_LT(test, conn_state->hdmi.output_bpc, 12);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +}
> +
> +/*
> + * Test that if a screen supports only RGB but the driver also supports
> + * YUV formats, we only end up with an RGB format.
> + */
> +static void drm_test_check_output_bpc_format_display_rgb_only(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_info *info;
> +       struct drm_display_mode *preferred;
> +       unsigned long long rate;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB) |
> +                                                    BIT(HDMI_COLORSPACE_YUV422) |
> +                                                    BIT(HDMI_COLORSPACE_YUV444),
> +                                                    12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_max_200mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_200mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       info = &conn->display_info;
> +       KUNIT_ASSERT_TRUE(test, info->is_hdmi);
> +       KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       /*
> +        * We're making sure that YUV422 would be the preferred option
> +        * here: we're always favouring higher bpc, we can't have RGB
> +        * because the TMDS character rate exceeds the maximum supported
> +        * by the display, and YUV422 works for that display.
> +        *
> +        * But since the display only supports RGB, we should fallback to
> +        * a lower bpc with RGB.
> +        */
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_GT(test, rate, info->max_tmds_clock * 1000);
> +
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_YUV422);
> +       KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_LT(test, conn_state->hdmi.output_bpc, 12);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +}
> +
> +/*
> + * Test that if a display supports higher bpc but the driver only
> + * supports 8 bpc, we only end up with 8 bpc even if we could have had a
> + * higher bpc.
> + */
> +static void drm_test_check_output_bpc_format_driver_8bpc_only(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_info *info;
> +       struct drm_display_mode *preferred;
> +       unsigned long long rate;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB),
> +                                                    8);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       info = &conn->display_info;
> +       KUNIT_ASSERT_TRUE(test, info->is_hdmi);
> +       KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       /*
> +        * We're making sure that we have headroom on the TMDS character
> +        * clock to actually use 12bpc.
> +        */
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 8);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +}
> +
> +/*
> + * Test that if a driver supports higher bpc but the display only
> + * supports 8 bpc, we only end up with 8 bpc even if we could have had a
> + * higher bpc.
> + */
> +static void drm_test_check_output_bpc_format_display_8bpc_only(struct kunit *test)
> +{
> +       struct drm_atomic_helper_connector_hdmi_priv *priv;
> +       struct drm_modeset_acquire_ctx *ctx;
> +       struct drm_connector_state *conn_state;
> +       struct drm_display_info *info;
> +       struct drm_display_mode *preferred;
> +       unsigned long long rate;
> +       struct drm_connector *conn;
> +       struct drm_device *drm;
> +       struct drm_crtc *crtc;
> +       int ret;
> +
> +       priv = drm_atomic_helper_connector_hdmi_init(test,
> +                                                    BIT(HDMI_COLORSPACE_RGB) |
> +                                                    BIT(HDMI_COLORSPACE_YUV422) |
> +                                                    BIT(HDMI_COLORSPACE_YUV444),
> +                                                    12);
> +       KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> +       conn = &priv->connector;
> +       ret = set_connector_edid(test, conn,
> +                                test_edid_hdmi_1080p_rgb_max_340mhz,
> +                                ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_340mhz));
> +       KUNIT_ASSERT_EQ(test, ret, 0);
> +
> +       info = &conn->display_info;
> +       KUNIT_ASSERT_TRUE(test, info->is_hdmi);
> +       KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
> +
> +       ctx = drm_kunit_helper_acquire_ctx_alloc(test);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       preferred = find_preferred_mode(conn);
> +       KUNIT_ASSERT_NOT_NULL(test, preferred);
> +
> +       /*
> +        * We're making sure that we have headroom on the TMDS character
> +        * clock to actually use 12bpc.
> +        */
> +       rate = drm_connector_hdmi_compute_mode_clock(preferred, 12, HDMI_COLORSPACE_RGB);
> +       KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
> +
> +       drm = &priv->drm;
> +       crtc = priv->crtc;
> +       ret = light_up_connector(test, drm, crtc, conn, preferred, ctx);
> +       KUNIT_EXPECT_EQ(test, ret, 0);
> +
> +       conn_state = conn->state;
> +       KUNIT_ASSERT_NOT_NULL(test, conn_state);
> +
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 8);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +}
> +
>  static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_auto_cea_mode_vic_1),
> @@ -1034,8 +1537,16 @@ static struct kunit_case drm_atomic_helper_connector_hdmi_check_tests[] = {
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_changed),
>         KUNIT_CASE(drm_test_check_broadcast_rgb_crtc_mode_not_changed),
>         KUNIT_CASE(drm_test_check_hdmi_funcs_reject_rate),
> +       KUNIT_CASE(drm_test_check_max_tmds_rate_bpc_fallback),
> +       KUNIT_CASE(drm_test_check_max_tmds_rate_format_fallback),
>         KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_changed),
>         KUNIT_CASE(drm_test_check_output_bpc_crtc_mode_not_changed),
> +       KUNIT_CASE(drm_test_check_output_bpc_dvi),
> +       KUNIT_CASE(drm_test_check_output_bpc_format_vic_1),
> +       KUNIT_CASE(drm_test_check_output_bpc_format_display_8bpc_only),
> +       KUNIT_CASE(drm_test_check_output_bpc_format_display_rgb_only),
> +       KUNIT_CASE(drm_test_check_output_bpc_format_driver_8bpc_only),
> +       KUNIT_CASE(drm_test_check_output_bpc_format_driver_rgb_only),
>         KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_8bpc),
>         KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_10bpc),
>         KUNIT_CASE(drm_test_check_tmds_char_rate_rgb_12bpc),
> @@ -1167,7 +1678,7 @@ static void drm_test_check_format_value(struct kunit *test)
>
>         conn = &priv->connector;
>         conn_state = conn->state;
> -       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, HDMI_COLORSPACE_RGB);
> +       KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, 0);
>  }
>
>  /*
> diff --git a/drivers/gpu/drm/tests/drm_kunit_edid.h b/drivers/gpu/drm/tests/drm_kunit_edid.h
> index 24f3377ef0f0..3e3527c58c31 100644
> --- a/drivers/gpu/drm/tests/drm_kunit_edid.h
> +++ b/drivers/gpu/drm/tests/drm_kunit_edid.h
> @@ -1,6 +1,64 @@
>  #ifndef DRM_KUNIT_EDID_H_
>  #define DRM_KUNIT_EDID_H_
>
> +/*
> + * edid-decode (hex):
> + *
> + * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
> + * 00 21 01 03 81 a0 5a 78 0a 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01
> + * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
> + * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
> + * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
> + * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ab
> + *
> + * ----------------
> + *
> + * Block 0, Base EDID:
> + *   EDID Structure Version & Revision: 1.3
> + *   Vendor & Product Identification:
> + *     Manufacturer: LNX
> + *     Model: 42
> + *     Made in: 2023
> + *   Basic Display Parameters & Features:
> + *     Digital display
> + *     DFP 1.x compatible TMDS
> + *     Maximum image size: 160 cm x 90 cm
> + *     Gamma: 2.20
> + *     RGB color display
> + *     First detailed timing is the preferred timing
> + *   Color Characteristics:
> + *     Red  : 0.0000, 0.0000
> + *     Green: 0.0000, 0.0000
> + *     Blue : 0.0000, 0.0000
> + *     White: 0.0000, 0.0000
> + *   Established Timings I & II: none
> + *   Standard Timings: none
> + *   Detailed Timing Descriptors:
> + *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
> + *                  Hfront   88 Hsync  44 Hback  148 Hpol P
> + *                  Vfront    4 Vsync   5 Vback   36 Vpol P
> + *     Display Product Name: 'Test EDID'
> + *     Display Range Limits:
> + *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
> + *     Dummy Descriptor:
> + * Checksum: 0xab
> + */
> +const unsigned char test_edid_dvi_1080p[] = {
> +  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
> +  0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
> +  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
> +  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
> +  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
> +  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
> +  0x46, 0x1e, 0x46, 0x0f, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
> +  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xab
> +};
> +
>  /*
>   * edid-decode (hex):
>   *
> @@ -103,6 +161,108 @@ const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz[] = {
>    0x00, 0x00, 0x00, 0xd0
>  };
>
> +/*
> + * edid-decode (hex):
> + *
> + * 00 ff ff ff ff ff ff 00 31 d8 2a 00 00 00 00 00
> + * 00 21 01 03 81 a0 5a 78 02 00 00 00 00 00 00 00
> + * 00 00 00 20 00 00 01 01 01 01 01 01 01 01 01 01
> + * 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
> + * 45 00 40 84 63 00 00 1e 00 00 00 fc 00 54 65 73
> + * 74 20 45 44 49 44 0a 20 20 20 00 00 00 fd 00 32
> + * 46 1e 46 0f 00 0a 20 20 20 20 20 20 00 00 00 10
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 92
> + *
> + * 02 03 1b 81 e3 05 00 20 41 10 e2 00 4a 6d 03 0c
> + * 00 12 34 00 28 20 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> + * 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0
> + *
> + * ----------------
> + *
> + * Block 0, Base EDID:
> + *   EDID Structure Version & Revision: 1.3
> + *   Vendor & Product Identification:
> + *     Manufacturer: LNX
> + *     Model: 42
> + *     Made in: 2023
> + *   Basic Display Parameters & Features:
> + *     Digital display
> + *     DFP 1.x compatible TMDS
> + *     Maximum image size: 160 cm x 90 cm
> + *     Gamma: 2.20
> + *     Monochrome or grayscale display
> + *     First detailed timing is the preferred timing
> + *   Color Characteristics:
> + *     Red  : 0.0000, 0.0000
> + *     Green: 0.0000, 0.0000
> + *     Blue : 0.0000, 0.0000
> + *     White: 0.0000, 0.0000
> + *   Established Timings I & II:
> + *     DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
> + *   Standard Timings: none
> + *   Detailed Timing Descriptors:
> + *     DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (1600 mm x 900 mm)
> + *                  Hfront   88 Hsync  44 Hback  148 Hpol P
> + *                  Vfront    4 Vsync   5 Vback   36 Vpol P
> + *     Display Product Name: 'Test EDID'
> + *     Display Range Limits:
> + *       Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz
> + *     Dummy Descriptor:
> + *   Extension blocks: 1
> + * Checksum: 0x92
> + *
> + * ----------------
> + *
> + * Block 1, CTA-861 Extension Block:
> + *   Revision: 3
> + *   Underscans IT Video Formats by default
> + *   Native detailed modes: 1
> + *   Colorimetry Data Block:
> + *     sRGB
> + *   Video Data Block:
> + *     VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
> + *   Video Capability Data Block:
> + *     YCbCr quantization: No Data
> + *     RGB quantization: Selectable (via AVI Q)
> + *     PT scan behavior: No Data
> + *     IT scan behavior: Always Underscanned
> + *     CE scan behavior: Always Underscanned
> + *   Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
> + *     Source physical address: 1.2.3.4
> + *     Maximum TMDS clock: 340 MHz
> + *     Extended HDMI video details:
> + * Checksum: 0xd0  Unused space in Extension Block: 100 bytes
> + */
> +const unsigned char test_edid_hdmi_1080p_rgb_max_340mhz[] = {
> +  0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x31, 0xd8, 0x2a, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x21, 0x01, 0x03, 0x81, 0xa0, 0x5a, 0x78,
> +  0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20,
> +  0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
> +  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38,
> +  0x2d, 0x40, 0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e,
> +  0x00, 0x00, 0x00, 0xfc, 0x00, 0x54, 0x65, 0x73, 0x74, 0x20, 0x45, 0x44,
> +  0x49, 0x44, 0x0a, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x32,
> +  0x46, 0x00, 0x00, 0xc4, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
> +  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x41, 0x02, 0x03, 0x1b, 0x81,
> +  0xe3, 0x05, 0x00, 0x20, 0x41, 0x10, 0xe2, 0x00, 0x4a, 0x6d, 0x03, 0x0c,
> +  0x00, 0x12, 0x34, 0x00, 0x44, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0x00, 0x00, 0x00, 0xd0
> +};
> +
>  /*
>   * edid-decode (hex):
>   *
>
> --
> 2.43.0
>


From semen.protsenko at linaro.org  Thu Dec 14 07:12:02 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:12:02 -0600
Subject: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0
 clock management unit
In-Reply-To: <20231214105243.3707730-3-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-3-tudor.ambarus@linaro.org>
Message-ID: <CAPLW+4=3naHwG4co=7bOf4LxmOPKR0qpn_hNGxys_N3AUzfiOA@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
> clock management unit.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  .../bindings/clock/google,gs101-clock.yaml    | 25 +++++-
>  include/dt-bindings/clock/google,gs101.h      | 86 +++++++++++++++++++
>  2 files changed, 109 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> index 3eebc03a309b..ba54c13c55bc 100644
> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> @@ -30,14 +30,15 @@ properties:
>        - google,gs101-cmu-top
>        - google,gs101-cmu-apm
>        - google,gs101-cmu-misc
> +      - google,gs101-cmu-peric0
>
>    clocks:
>      minItems: 1
> -    maxItems: 2
> +    maxItems: 3
>
>    clock-names:
>      minItems: 1
> -    maxItems: 2
> +    maxItems: 3
>
>    "#clock-cells":
>      const: 1
> @@ -88,6 +89,26 @@ allOf:
>              - const: dout_cmu_misc_bus
>              - const: dout_cmu_misc_sss
>
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: google,gs101-cmu-peric0
> +
> +    then:
> +      properties:
> +        clocks:
> +          items:
> +            - description: External reference clock (24.576 MHz)
> +            - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
> +            - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
> +
> +        clock-names:
> +          items:
> +            - const: oscclk
> +            - const: dout_cmu_peric0_bus
> +            - const: dout_cmu_peric0_ip
> +
>  additionalProperties: false
>
>  examples:
> diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
> index 21adec22387c..7d7a896416a7 100644
> --- a/include/dt-bindings/clock/google,gs101.h
> +++ b/include/dt-bindings/clock/google,gs101.h
> @@ -389,4 +389,90 @@
>  #define CLK_GOUT_MISC_WDT_CLUSTER1_PCLK                        73
>  #define CLK_GOUT_MISC_XIU_D_MISC_ACLK                  74
>
> +/* CMU_PERIC0 */

This comments looks off here. Other than than, LGTM:

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

> +/* CMU_PERIC0 MUX */
> +#define CLK_MOUT_PERIC0_BUS_USER                       1
> +#define CLK_MOUT_PERIC0_I3C_USER                       2
> +#define CLK_MOUT_PERIC0_USI0_UART_USER                 3
> +#define CLK_MOUT_PERIC0_USI14_USI_USER                 4
> +#define CLK_MOUT_PERIC0_USI1_USI_USER                  5
> +#define CLK_MOUT_PERIC0_USI2_USI_USER                  6
> +#define CLK_MOUT_PERIC0_USI3_USI_USER                  7
> +#define CLK_MOUT_PERIC0_USI4_USI_USER                  8
> +#define CLK_MOUT_PERIC0_USI5_USI_USER                  9
> +#define CLK_MOUT_PERIC0_USI6_USI_USER                  10
> +#define CLK_MOUT_PERIC0_USI7_USI_USER                  11
> +#define CLK_MOUT_PERIC0_USI8_USI_USER                  12
> +
> +/* CMU_PERIC0 Dividers */
> +#define CLK_DOUT_PERIC0_I3C                            13
> +#define CLK_DOUT_PERIC0_USI0_UART                      14
> +#define CLK_DOUT_PERIC0_USI14_USI                      15
> +#define CLK_DOUT_PERIC0_USI1_USI                       16
> +#define CLK_DOUT_PERIC0_USI2_USI                       17
> +#define CLK_DOUT_PERIC0_USI3_USI                       18
> +#define CLK_DOUT_PERIC0_USI4_USI                       19
> +#define CLK_DOUT_PERIC0_USI5_USI                       20
> +#define CLK_DOUT_PERIC0_USI6_USI                       21
> +#define CLK_DOUT_PERIC0_USI7_USI                       22
> +#define CLK_DOUT_PERIC0_USI8_USI                       23
> +
> +/* CMU_PERIC0 Gates */
> +#define CLK_GOUT_PERIC0_IP                             24
> +#define CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK         25
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK          26
> +#define CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK             27
> +#define CLK_GOUT_PERIC0_GPC_PERIC0_PCLK                        28
> +#define CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK               29
> +#define CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK         30
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0            31
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1            32
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10           33
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11           34
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12           35
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13           36
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14           37
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15           38
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2            39
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3            40
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4            41
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5            42
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6            43
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7            44
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8            45
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9            46
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0             47
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1             48
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10            49
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11            50
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12            51
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13            52
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14            53
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15            54
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2             55
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3             56
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4             57
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5             58
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6             59
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7             60
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8             61
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9             62
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0            63
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2            64
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0             65
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2             66
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK            67
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK             68
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK       69
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK       70
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK                71
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK                72
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK                73
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK                74
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK                75
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK                76
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK                77
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK                78
> +#define CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK             79
> +
>  #endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
> --
> 2.43.0.472.g3155946c3a-goog
>


From semen.protsenko at linaro.org  Thu Dec 14 07:12:58 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:12:58 -0600
Subject: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
In-Reply-To: <20231214105243.3707730-4-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-4-tudor.ambarus@linaro.org>
Message-ID: <CAPLW+4mBN1g0ojYiE_AVt7ZWO_1yEFpx58x4+1U9spxaS=abRA@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> Add google,gs101-hsi2c dedicated compatible for representing
> I2C of Google GS101 SoC.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> index df9c57bca2a8..cc8bba5537b9 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> @@ -33,6 +33,7 @@ properties:
>            - const: samsung,exynos7-hsi2c
>        - items:
>            - enum:
> +              - google,gs101-hsi2c
>                - samsung,exynos850-hsi2c
>            - const: samsung,exynosautov9-hsi2c
>        - const: samsung,exynos5-hsi2c    # Exynos5250 and Exynos5420
> --
> 2.43.0.472.g3155946c3a-goog
>


From semen.protsenko at linaro.org  Thu Dec 14 07:14:25 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:14:25 -0600
Subject: [PATCH 04/13] dt-bindings: serial: samsung: gs101: make
 reg-io-width required property
In-Reply-To: <20231214105243.3707730-5-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-5-tudor.ambarus@linaro.org>
Message-ID: <CAPLW+4kBPj+f+aedr3yq_KTg7V7NFjK3RzFMypeYdQ-eos-NAA@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> GS101 only allows 32-bit register accesses. When using 8-bit reg
> accesses on gs101, a SError Interrupt is raised causing the system
> unusable.
>
> Make reg-io-width a required property and expect for it a value of 4.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 133259ed3a34..cc896d7e2a3d 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -143,6 +143,10 @@ allOf:
>      then:
>        required:
>          - samsung,uart-fifosize
> +        - reg-io-width
> +      properties:
> +        reg-io-width:
> +          const: 4
>
>  unevaluatedProperties: false
>
> --
> 2.43.0.472.g3155946c3a-goog
>


From tudor.ambarus at linaro.org  Thu Dec 14 07:16:26 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 15:16:26 +0000
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate
 clock names
In-Reply-To: <CAPLW+4kr=aVjuqGz3ps5f6EzM+QASTFEoB57g+fR7jKH0s+1Zw@mail.gmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-2-tudor.ambarus@linaro.org>
 <CAPLW+4kr=aVjuqGz3ps5f6EzM+QASTFEoB57g+fR7jKH0s+1Zw@mail.gmail.com>
Message-ID: <0d3ae184-5ded-42ab-97cf-13bbb296083a@linaro.org>



On 12/14/23 15:07, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>
>> The gs101 clock names are derived from the clock register names under
>> some certain rules. In particular, for the gate clocks the following is
>> documented and expected in the gs101 clock driver:
>>
>>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
>>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>
>>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>
> 
> Doesn't it break existing gs101 device tree?

No, compilation went fine at this point. The TOP gates are not used in
the device tree at this point. And since the bindings patch was just
applied I think we should fix it, so that we avoid name clashes as
described below (I found a clash with a gate from PERIC0).

> 
>> The CMU TOP gate clock names missed to include the required "CMU"
>> differentiator which will cause name collisions with the gate clock names
>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>> their name.
>>
>> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>> ---
> 
> (snip)

Thanks for the review!
ta


From jean-philippe at linaro.org  Thu Dec 14 07:22:06 2023
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu, 14 Dec 2023 15:22:06 +0000
Subject: [PATCH v3 12/15] arm64/mm: Split __flush_tlb_range() to elide
 trailing DSB
In-Reply-To: <fbcda9e1-0473-4669-a869-d4de351c3197@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-13-ryan.roberts@arm.com>
 <20231212113517.GA28857@willie-the-truck>
 <0969c413-bf40-4c46-9f1e-a92101ff2d2e@arm.com>
 <2e6f06d3-6c8e-4b44-b6f2-e55bd5be83d6@arm.com>
 <20231214121336.GA1015@willie-the-truck>
 <fbcda9e1-0473-4669-a869-d4de351c3197@arm.com>
Message-ID: <20231214152206.GA3625745@myrica>

On Thu, Dec 14, 2023 at 12:30:55PM +0000, Robin Murphy wrote:
> > Robin, Jean-Philippe -- do we need to make sure that the SMMU has completed
> > its TLB invalidation before issuing an ATC invalidate? My half-baked worry
> > is whether or not an ATS request could refill the ATC before the TLBI
> > has completed, therefore rendering the ATC invalidation useless.
> 
> I would agree, and the spec for CMD_ATC_INV does call out a
> TLBI->sync->ATCI->sync sequence. At the moment the SVA notifier is issuing
> its own command-based TLBIs anyway so the necessary sync is implicit there,
> but if and when we get BTM support wired up properly it would be nice not to
> have to bodge in an additional sync/DSB.

Yes agreed, with BTM the CPU must call the notifier that issues ATC
invalidation after completing the TLBI+DSB instructions.

SMMU IHI0070F.a  3.9.1 ATS Interface

	Software must ensure that the SMMU TLB invalidation is complete before
	initiating the ATC invalidation.

I'm guessing BTM will be enabled in the SMMU driver sometime soon, given
that there already is one implementation in the wild that could use it. I
think we didn't enable it because of the lack of separation between shared
and private VMIDs, but that may now be solvable with the recent rework of
the VMID allocator.

Thanks,
Jean


From semen.protsenko at linaro.org  Thu Dec 14 07:22:40 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:22:40 -0600
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate
 clock names
In-Reply-To: <0d3ae184-5ded-42ab-97cf-13bbb296083a@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-2-tudor.ambarus@linaro.org> <CAPLW+4kr=aVjuqGz3ps5f6EzM+QASTFEoB57g+fR7jKH0s+1Zw@mail.gmail.com>
 <0d3ae184-5ded-42ab-97cf-13bbb296083a@linaro.org>
Message-ID: <CAPLW+4mpV0cy32MPS72-z=WYTZusnS7uTO7fbmOruVjAvcoBeA@mail.gmail.com>

On Thu, Dec 14, 2023 at 9:16?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
>
>
> On 12/14/23 15:07, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>
> >> The gs101 clock names are derived from the clock register names under
> >> some certain rules. In particular, for the gate clocks the following is
> >> documented and expected in the gs101 clock driver:
> >>
> >>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
> >>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
> >>
> >>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
> >>
> >
> > Doesn't it break existing gs101 device tree?
>
> No, compilation went fine at this point. The TOP gates are not used in
> the device tree at this point. And since the bindings patch was just
> applied I think we should fix it, so that we avoid name clashes as
> described below (I found a clash with a gate from PERIC0).
>

Ok, in that case feel free to add:

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

> >
> >> The CMU TOP gate clock names missed to include the required "CMU"
> >> differentiator which will cause name collisions with the gate clock names
> >> of other clock units. Fix the TOP gate clock names and include "CMU" in
> >> their name.
> >>
> >> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> >> ---
> >
> > (snip)
>
> Thanks for the review!
> ta


From knaerzche at gmail.com  Thu Dec 14 07:22:50 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 14 Dec 2023 16:22:50 +0100
Subject: [PATCH 01/11] dt-bindings: display: rockchip,inno-hdmi: Document
 RK3128 compatible
In-Reply-To: <c4e394c6-c21f-4102-8c3a-f9530c0ca547@linaro.org>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-2-knaerzche@gmail.com>
 <c4e394c6-c21f-4102-8c3a-f9530c0ca547@linaro.org>
Message-ID: <288857ab-bebd-4f80-9cdc-9b04fa6c7386@gmail.com>


Am 14.12.23 um 08:53 schrieb Krzysztof Kozlowski:
> On 13/12/2023 20:51, Alex Bee wrote:
>> Document the compatible for RK3128's HDMI controller block.
>> The integration for this SoC is somewhat different here: It needs the PHY's
> Please wrap commit message according to Linux coding style / submission
> process (neither too early nor over the limit):
> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
OK. Not sure why checkpatch --strict? didn't tell me that I'm over the 
limit here.
>
>> reference clock rate to calculate the ddc bus frequency correctly. This
>> clock is part of a power-domain (PD_VIO), so this gets added as an optional
>> property too.
> If clock is part of power domain, then the power domain must be in the
> clock controller, not here. So either you put power domain in wrong
> place or you used incorrect reason for a change.
 ?Rockchip defines it's powerdomains per clock and I was little to much 
in that world when writing this. Actually the controller itself is part 
of the powerdomain. Will rephrase.
>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>> ---
>>   .../display/rockchip/rockchip,inno-hdmi.yaml  | 30 +++++++++++++++++--
>>   1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
>> index 96889c86849a..9f00abcbfb38 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
>> @@ -14,6 +14,7 @@ properties:
>>     compatible:
>>       enum:
>>         - rockchip,rk3036-inno-hdmi
>> +      - rockchip,rk3128-inno-hdmi
>>   
>>     reg:
>>       maxItems: 1
>> @@ -22,10 +23,21 @@ properties:
>>       maxItems: 1
>>   
>>     clocks:
>> -    maxItems: 1
>> +    minItems: 1
>> +    items:
>> +      - description: The HDMI controller main clock
>> +      - description: The HDMI PHY reference clock
>>   
>>     clock-names:
>> -    const: pclk
>> +    minItems: 1
>> +    items:
>> +      - const: pclk
>> +      - enum:
>> +          - pclk
>> +          - ref
> That's way overcomplicated. Just items listing the names and minItems:
> 1. See other bindings how this is done.
OK.
>> +
>> +  power-domains:
>> +    maxItems: 1
> Is it relevant to existing device?

Will move to new variant only.

Alex

>>   
>>     ports:
>>       $ref: /schemas/graph.yaml#/properties/ports
>> @@ -55,6 +67,20 @@ required:
>>     - pinctrl-names
>>     - ports
>
> Best regards,
> Krzysztof
>


From eugen.hristev at collabora.com  Thu Dec 14 07:30:38 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Thu, 14 Dec 2023 17:30:38 +0200
Subject: [PATCH 4/4] arm64: dts: mediatek: mt8186: Add venc node
In-Reply-To: <d20c35e2-cc40-436d-90ca-4cab555874ca@collabora.com>
References: <20231213122017.102100-1-eugen.hristev@collabora.com>
 <20231213122017.102100-4-eugen.hristev@collabora.com>
 <d20c35e2-cc40-436d-90ca-4cab555874ca@collabora.com>
Message-ID: <18406191-1b7c-490a-852b-eed3db23a3c1@collabora.com>

On 12/14/23 12:44, AngeloGioacchino Del Regno wrote:
> Il 13/12/23 13:20, Eugen Hristev ha scritto:
>> From: Kyrie Wu <kyrie.wu at mediatek.com>
>>
>> Add video encoder node.
>>
>> Signed-off-by: Kyrie Wu <kyrie.wu at mediatek.com>
>> Signed-off-by: Allen-KH Cheng <allen-kh.cheng at mediatek.com>
>> Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.org>
>> [eugen.hristev at collabora.com: minor cleanup]
>> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
>> ---
>>   arch/arm64/boot/dts/mediatek/mt8186.dtsi | 24 ++++++++++++++++++++++++
>>   1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
>> index 66ead3f23336..8535ff2b44e9 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
>> @@ -1993,6 +1993,30 @@ larb7: smi at 17010000 {
>>   			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
>>   		};
>>   
>> +		venc: venc at 17020000 {
>> +			compatible = "mediatek,mt8183-vcodec-enc";
>> +			#address-cells = <2>;
>> +			#size-cells = <2>;
>> +			reg = <0 0x17020000 0 0x2000>;
>> +			interrupts = <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH 0>;
>> +			iommus = <&iommu_mm IOMMU_PORT_L7_VENC_RCPU>,
>> +				 <&iommu_mm IOMMU_PORT_L7_VENC_REC>,
>> +				 <&iommu_mm IOMMU_PORT_L7_VENC_BSDMA>,
>> +				 <&iommu_mm IOMMU_PORT_L7_VENC_SV_COMV>,
>> +				 <&iommu_mm IOMMU_PORT_L7_VENC_RD_COMV>,
>> +				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_LUMA>,
>> +				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_CHROMA>,
>> +				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_LUMA>,
>> +				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_CHROMA>;
>> +			dma-ranges = <0x1 0x0 0x1 0x0 0x1 0x0>;
>> +			mediatek,scp = <&scp>;
>> +			clocks = <&vencsys CLK_VENC_CKE1_VENC>;
>> +			clock-names = "MT_CG_VENC";
> 
> clock-names = "venc"; (please no underscores and please lower case)

The clock name must be `venc_sel` (*with* underscores) and it's ABI as defined in
Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml

so I will it change to that.


> 
>> +			assigned-clocks = <&topckgen CLK_TOP_VENC>;
>> +			assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D3>;
>> +			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
>> +		};
> 
> 
> ....also:
> 
> The following order of properties in device nodes is preferred:
> 
> 1. "compatible"
> 2. "reg"
> 3. "ranges"
> 4. Standard/common properties (defined by common bindings, e.g. without
>     vendor-prefixes)
> 5. Vendor-specific properties
> 6. "status" (if applicable)
> 7. Child nodes, where each node is preceded with a blank line
> 
> Documentation/devicetree/bindings/dts-coding-style.rst
> 
> Please reorder as per the DTS coding style document, and also please rename the
> venc node to use a generic name, such as "video-encoder at xxxx"
> 
> Cheers,
> Angelo
> _______________________________________________
> Kernel mailing list -- kernel at mailman.collabora.com
> To unsubscribe send an email to kernel-leave at mailman.collabora.com



From ninad at linux.ibm.com  Thu Dec 14 07:34:39 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Thu, 14 Dec 2023 09:34:39 -0600
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <20231212-amusement-elevation-28e42bcccc35@spud>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-3-ninad@linux.ibm.com>
 <20231212-amusement-elevation-28e42bcccc35@spud>
Message-ID: <d8b5df1c-c732-4cf3-ae28-cc2017d3b0b6@linux.ibm.com>

Hello Conor,

On 12/12/23 11:14, Conor Dooley wrote:
> Hey,
>
> On Tue, Dec 12, 2023 at 10:39:58AM -0600, Ninad Palsule wrote:
>> From: Johannes Holland <johannes.holland at infineon.com>
>>
>> Add a dt schema to support device tree bindings
> "Add bindings for..."
Fixed.
>
>> for the generic I2C
>> physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
>> Specification for TPM 2.0 v1.04 Revision 14.
>>
>> This includes descriptions for the Nuvoton and Infineon devices.
>>
>> OpenBMC-Staging-Count: 3
> I have no idea what this is, but it needs to be removed from the patch.
Removed.
>
>> Signed-off-by: Johannes Holland <johannes.holland at infineon.com>
>> Signed-off-by: Joel Stanley <joel at jms.id.au>
>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>> ---
>>   .../bindings/security/tpm/tpm-tis-i2c.yaml    | 50 +++++++++++++++++++
>>   1 file changed, 50 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>> new file mode 100644
>> index 000000000000..de1e34065748
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>> @@ -0,0 +1,50 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: I2C PTP based TPM Devices
>> +
>> +maintainers:
>> +  - Johannes Holland <johannes.holland at infineon.com>
>> +
>> +description:
>> +  Device Tree Bindings for I2C based Trusted Platform Module (TPM).
> s/Device Tree Bindings for //. Doesn't dt_binding_check now complain if
> you have this in a title or description?
Fixed.
>
>> +properties:
>> +  $nodename:
>> +    pattern: "^tpm(@[0-9a-f]+)?$"
>> +
>> +  compatible:
>> +    oneOf:
>> +      - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
>> +        items:
>> +          - const: infineon,slb9673
>> +          - const: tcg,tpm-tis-i2c
>> +      - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
>> +        items:
>> +          - const: nuvoton,npct75x
>> +          - const: tcg,tpm-tis-i2c
>> +      - const: tcg,tpm-tis-i2c
> IMO this should be removed and this fallback should only be used in
> combination with device specific compatibles, like you have here for the
> infineon and nuvoton devices.

As Guenter mentioned I need to keep it as tacoma board is just using 
this string.

Thanks for the review.

Regards,

Ninad

>
> Cheers,
> Conor.
>
>> +  reg:
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    i2c {
>> +      #address-cells = <1>;
>> +      #size-cells = <0>;
>> +
>> +      tpm at 2e {
>> +        compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
>> +        reg = <0x2e>;
>> +      };
>> +    };
>> +...
>> -- 
>> 2.39.2
>>


From zajec5 at gmail.com  Thu Dec 14 07:36:20 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 14 Dec 2023 16:36:20 +0100
Subject: [PATCH RFC] dt-bindings: nvmem: u-boot,env: add any-name MAC cells compatible
Message-ID: <20231214153620.23998-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

So far we had a property for "ethaddr" NVMEM cell containing base
Ethernet MAC address. The problem is vendors often pick non-standard
names for storing MAC(s) (other than "ethaddr"). A few names were
noticed over years:
1. "wanaddr" (Edimax, ELECOM, EnGenius, I-O DATA, Sitecom)
2. "et1macaddr" (ASUS)
3. "eth1addr" (Buffalo)
4. "athaddr" (EnGenius)
5. "baseMAC" (Netgear)
6. "mac" (Netgear)
7. "mac_addr" (Moxa)
and more ("HW_LAN_MAC", "HW_WAN_MAC", "INIC_MAC_ADDR", "LAN_MAC_ADDR",
"RADIOADDR0", "RADIOADDR1", "WAN_MAC_ADDR", "lan1_mac_addr", "wanmac",
"wmac1", "wmac2").

It doesn't make sense to add property for every possible MAC cell name.
Instead allow specifying cells with "mac" compatible.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
List of devices and their U-Boot MAC variables:
alphanetworks,asl56026) wanmac
asus,rt-ac65p) et1macaddr
asus,rt-ac85p) et1macaddr
belkin,f9k1109v1) HW_WAN_MAC + HW_LAN_MAC 
buffalo,ls220de) eth1addr
buffalo,ls421de) eth1addr
checkpoint,l-50) lan1_mac_addr
dovado,tiny-ac) INIC_MAC_ADDR
dovado,tiny-ac) LAN_MAC_ADDR + WAN_MAC_ADDR
edimax,ra21s) wanaddr
edimax,rg21s) wanaddr
elecom,wrc-2533ghbk-i) wanaddr
elecom,wrc-2533ghbk2-t) wanaddr
engenius,ecb1200) athaddr
engenius,ecb1750) athaddr
engenius,epg5000) wanaddr
engenius,epg600) wanaddr
engenius,esr1200) wanaddr
engenius,esr1750) wanaddr
engenius,esr600) wanaddr
engenius,esr600h) wanaddr
engenius,esr900) wanaddr
enterasys,ws-ap3705i) RADIOADDR0 + RADIOADDR1
iodata,wn-ac1167dgr) wanaddr
iodata,wn-ac1167gr) wanaddr
iodata,wn-ac1600dgr) wanaddr
iodata,wn-ac1600dgr2) wanaddr
iodata,wn-ac733gr3) wanaddr
iodata,wn-ag300dgr) wanaddr
iodata,wnpr2600g) wanaddr
moxa,awk-1137c) mac_addr
netgear,wax220) mac
netgear,wndap620) baseMAC
netgear,wndap660) baseMAC
ocedo,panda) wmac1 + wmac2
sitecom,wlr-7100) wanaddr
sitecom,wlr-8100) wanaddr

 .../devicetree/bindings/nvmem/u-boot,env.yaml | 33 +++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
index 0006f022d0af..68214b96f5c9 100644
--- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
@@ -67,6 +67,34 @@ properties:
         description: The first argument is a MAC address offset.
         const: 1
 
+patternProperties:
+  ".*":
+    allOf:
+      - if:
+          type: object
+        then:
+          properties:
+            compatible:
+              enum:
+                - mac
+      - if:
+          properties:
+            compatible:
+              contains:
+                const: mac
+        then:
+          description:
+            Ethernet interfaces base MAC address.
+
+          properties:
+            compatible: true
+
+            "#nvmem-cell-cells":
+              description: The first argument is a MAC address offset.
+              const: 1
+
+          additionalProperties: false
+
 additionalProperties: false
 
 examples:
@@ -90,6 +118,11 @@ examples:
             mac: ethaddr {
                 #nvmem-cell-cells = <1>;
             };
+
+            wanaddr {
+                compatible = "mac";
+                #nvmem-cell-cells = <1>;
+            };
         };
     };
   - |
-- 
2.35.3



From alexandre.torgue at foss.st.com  Thu Dec 14 07:37:31 2023
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 14 Dec 2023 16:37:31 +0100
Subject: [PATCH 2/2] ARM: dts: stm32: don't mix SCMI and non-SCMI board
 compatibles
In-Reply-To: <20231122185235.2017642-2-a.fatoum@pengutronix.de>
References: <20231122185235.2017642-1-a.fatoum@pengutronix.de>
 <20231122185235.2017642-2-a.fatoum@pengutronix.de>
Message-ID: <8adec7b4-bdd9-4ad0-a302-326ed99ea732@foss.st.com>

Hi Ahmad

On 11/22/23 19:52, Ahmad Fatoum wrote:
> The binding erroneously decreed that the SCMI variants of the ST
> evaluation kits are compatible with the non-SCMI variants.
> 
> This is not correct, as a kernel or bootloader compatible with the non-SCMI
> variant is not necessarily able to function, when direct access
> to resources is replaced by having to talk SCMI to the secure monitor.
> 
> The binding has been adjusted to reflect thus, so synchronize the device
> trees now.
> 
> Fixes: 5b7e58313a77 ("ARM: dts: stm32: Add SCMI version of STM32 boards (DK1/DK2/ED1/EV1)")
> Signed-off-by: Ahmad Fatoum <a.fatoum at pengutronix.de>
> ---

Thanks to have fix my error.

Both patches applied on stm32-next.

Cheers
Alex

>   arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts | 2 +-
>   arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts | 2 +-
>   arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts | 2 +-
>   arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts | 3 +--
>   4 files changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts b/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
> index afcd6285890c..c27963898b5e 100644
> --- a/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
> +++ b/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
> @@ -11,7 +11,7 @@
>   
>   / {
>   	model = "STMicroelectronics STM32MP157A-DK1 SCMI Discovery Board";
> -	compatible = "st,stm32mp157a-dk1-scmi", "st,stm32mp157a-dk1", "st,stm32mp157";
> +	compatible = "st,stm32mp157a-dk1-scmi", "st,stm32mp157";
>   
>   	reserved-memory {
>   		optee at de000000 {
> diff --git a/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts b/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
> index 39358d902000..622618943134 100644
> --- a/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
> +++ b/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
> @@ -11,7 +11,7 @@
>   
>   / {
>   	model = "STMicroelectronics STM32MP157C-DK2 SCMI Discovery Board";
> -	compatible = "st,stm32mp157c-dk2-scmi", "st,stm32mp157c-dk2", "st,stm32mp157";
> +	compatible = "st,stm32mp157c-dk2-scmi", "st,stm32mp157";
>   
>   	reserved-memory {
>   		optee at de000000 {
> diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts b/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
> index 07ea765a4553..c7c4d7e89d61 100644
> --- a/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
> +++ b/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
> @@ -11,7 +11,7 @@
>   
>   / {
>   	model = "STMicroelectronics STM32MP157C-ED1 SCMI eval daughter";
> -	compatible = "st,stm32mp157c-ed1-scmi", "st,stm32mp157c-ed1", "st,stm32mp157";
> +	compatible = "st,stm32mp157c-ed1-scmi", "st,stm32mp157";
>   
>   	reserved-memory {
>   		optee at fe000000 {
> diff --git a/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts b/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
> index 813086ec2489..2ab77e64f1bb 100644
> --- a/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
> +++ b/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
> @@ -11,8 +11,7 @@
>   
>   / {
>   	model = "STMicroelectronics STM32MP157C-EV1 SCMI eval daughter on eval mother";
> -	compatible = "st,stm32mp157c-ev1-scmi", "st,stm32mp157c-ev1", "st,stm32mp157c-ed1",
> -		     "st,stm32mp157";
> +	compatible = "st,stm32mp157c-ev1-scmi", "st,stm32mp157c-ed1", "st,stm32mp157";
>   
>   	reserved-memory {
>   		optee at fe000000 {


From semen.protsenko at linaro.org  Thu Dec 14 07:37:31 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:37:31 -0600
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock
 as critical
In-Reply-To: <20231214105243.3707730-8-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-8-tudor.ambarus@linaro.org>
Message-ID: <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> which then makes the system hang. To prevent this, mark
> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> accordingly when tested.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  drivers/clk/samsung/clk-gs101.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> index 3d194520b05e..08d80fca9cd6 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>              "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>              21, 0, 0),
>         GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> -            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> +            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),

This clock doesn't seem like a leaf clock. It's also not a bus clock.
Leaving it always running makes the whole PERIC0 CMU clocked, which
usually should be avoided. Is it possible that the system freezes
because some other clock (which depends on peric0_ip) gets disabled as
a consequence of disabling peric0_ip? Maybe it's some leaf clock which
is not implemented yet in the clock driver? Just looks weird to me
that the system hangs because of CMU IP clock disablement. It's
usually something much more specific.

>         GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
>              "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
>              21, 0, 0),
> --
> 2.43.0.472.g3155946c3a-goog
>


From ninad at linux.ibm.com  Thu Dec 14 07:37:20 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Thu, 14 Dec 2023 09:37:20 -0600
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <874d4416-86e5-48cc-9c84-97357e4caefe@roeck-us.net>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-3-ninad@linux.ibm.com>
 <20231212-amusement-elevation-28e42bcccc35@spud>
 <874d4416-86e5-48cc-9c84-97357e4caefe@roeck-us.net>
Message-ID: <46fcba11-5766-4c7c-91dd-0dfb5ae0e110@linux.ibm.com>

Hello Guenter,

On 12/12/23 12:20, Guenter Roeck wrote:
> On Tue, Dec 12, 2023 at 05:14:26PM +0000, Conor Dooley wrote:
>> Hey,
>>
>> On Tue, Dec 12, 2023 at 10:39:58AM -0600, Ninad Palsule wrote:
>>> From: Johannes Holland <johannes.holland at infineon.com>
>>>
>>> Add a dt schema to support device tree bindings
>> "Add bindings for..."
>>
>>> for the generic I2C
>>> physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
>>> Specification for TPM 2.0 v1.04 Revision 14.
>>>
>>> This includes descriptions for the Nuvoton and Infineon devices.
>>>
>>> OpenBMC-Staging-Count: 3
>> I have no idea what this is, but it needs to be removed from the patch.
>>
>>> Signed-off-by: Johannes Holland <johannes.holland at infineon.com>
>>> Signed-off-by: Joel Stanley <joel at jms.id.au>
>>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>>> ---
>>>   .../bindings/security/tpm/tpm-tis-i2c.yaml    | 50 +++++++++++++++++++
>>>   1 file changed, 50 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>>> new file mode 100644
>>> index 000000000000..de1e34065748
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>>> @@ -0,0 +1,50 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: I2C PTP based TPM Devices
>>> +
>>> +maintainers:
>>> +  - Johannes Holland <johannes.holland at infineon.com>
>>> +
>>> +description:
>>> +  Device Tree Bindings for I2C based Trusted Platform Module (TPM).
>> s/Device Tree Bindings for //. Doesn't dt_binding_check now complain if
>> you have this in a title or description?
>>
>>> +properties:
>>> +  $nodename:
>>> +    pattern: "^tpm(@[0-9a-f]+)?$"
>>> +
>>> +  compatible:
>>> +    oneOf:
>>> +      - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
>>> +        items:
>>> +          - const: infineon,slb9673
>>> +          - const: tcg,tpm-tis-i2c
>>> +      - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
>>> +        items:
>>> +          - const: nuvoton,npct75x
>>> +          - const: tcg,tpm-tis-i2c
>>> +      - const: tcg,tpm-tis-i2c
>> IMO this should be removed and this fallback should only be used in
>> combination with device specific compatibles, like you have here for the
>> infineon and nuvoton devices.
> As mentioned in my response to the other patch, "only" isn't sufficient
> since the tacoma devicetree file only references the generic entry.
> It would also make support for chips from other vendors unnecessarily
> complex.
>
> Question should in my opinion be if the non-fallback entries are really
> needed.

Thanks for the response. I think generic option is in-case we have a 
chip whose specific driver is not available.

Regards,

Ninad

>
> Thanks,
> Guenter


From semen.protsenko at linaro.org  Thu Dec 14 07:39:35 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:39:35 -0600
Subject: [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
In-Reply-To: <20231214105243.3707730-9-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-9-tudor.ambarus@linaro.org>
Message-ID: <CAPLW+4=bfcemh-dd7r9hOe0RbtC01+sNpj3ZMMfc8rMezKQfNA@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> Enable the cmu-peric0 clock controller. It feeds USI and I3c.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index 9747cb3fa03a..d0b0ad70c6ba 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
>                         };
>                 };
>
> +               cmu_peric0: clock-controller at 10800000 {
> +                       compatible = "google,gs101-cmu-peric0";
> +                       reg = <0x10800000 0x4000>;
> +                       #clock-cells = <1>;
> +                       clocks = <&ext_24_5m>,
> +                                <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
> +                                <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
> +                       clock-names = "oscclk",
> +                                     "dout_cmu_peric0_bus",

I'd pull this line to the above line. Other than that:

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

> +                                     "dout_cmu_peric0_ip";
> +               };
> +
>                 sysreg_peric0: syscon at 10820000 {
>                         compatible = "google,gs101-peric0-sysreg", "syscon";
>                         reg = <0x10820000 0x10000>;
> --
> 2.43.0.472.g3155946c3a-goog
>


From peter.ujfalusi at gmail.com  Thu Dec 14 07:41:37 2023
From: peter.ujfalusi at gmail.com (=?UTF-8?Q?P=C3=A9ter_Ujfalusi?=)
Date: Thu, 14 Dec 2023 17:41:37 +0200
Subject: [PATCH v2 3/4] dmaengine: ti: k3-udma-glue: Add function to
 request TX channel by ID
In-Reply-To: <20231212111011.1401641-4-s-vadapalli@ti.com>
References: <20231212111011.1401641-1-s-vadapalli@ti.com>
 <20231212111011.1401641-4-s-vadapalli@ti.com>
Message-ID: <800ccf2e-65cc-4524-8a42-1657a5906482@gmail.com>



On 12/12/2023 13:10, Siddharth Vadapalli wrote:
> The existing function k3_udma_glue_request_tx_chn() supports requesting
> a TX DMA channel by its name. Add support to request TX channel by ID in
> the form of a new function k3_udma_glue_request_tx_chn_by_id() and export
> it for use by drivers which are probed by alternate methods (non
> device-tree) but still wish to make use of the existing DMA APIs. Such
> drivers could be informed about the TX channel to use by RPMsg for example.
> 
> Since the implementation of k3_udma_glue_request_tx_chn_by_id() reuses
> most of the code in k3_udma_glue_request_tx_chn(), create a new function
> for the common code named as k3_udma_glue_request_tx_chn_common().
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
> ---
> Changes since v1:
> - Updated commit message indicating the use-case for which the patch is
>   being added.
> 
>  drivers/dma/ti/k3-udma-glue.c    | 101 +++++++++++++++++++++++--------
>  include/linux/dma/k3-udma-glue.h |   4 ++
>  2 files changed, 79 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
> index eff1ae3d3efe..ea5119a5e8eb 100644
> --- a/drivers/dma/ti/k3-udma-glue.c
> +++ b/drivers/dma/ti/k3-udma-glue.c
> @@ -274,29 +274,13 @@ static int k3_udma_glue_cfg_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
>  	return tisci_rm->tisci_udmap_ops->tx_ch_cfg(tisci_rm->tisci, &req);
>  }
>  
> -struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
> -		const char *name, struct k3_udma_glue_tx_channel_cfg *cfg)
> +static int
> +k3_udma_glue_request_tx_chn_common(struct device *dev,
> +				   struct k3_udma_glue_tx_channel *tx_chn,
> +				   struct k3_udma_glue_tx_channel_cfg *cfg)
>  {
> -	struct k3_udma_glue_tx_channel *tx_chn;
>  	int ret;
>  
> -	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
> -	if (!tx_chn)
> -		return ERR_PTR(-ENOMEM);
> -
> -	tx_chn->common.dev = dev;
> -	tx_chn->common.swdata_size = cfg->swdata_size;
> -	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
> -	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
> -	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
> -	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
> -
> -	/* parse of udmap channel */
> -	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
> -					&tx_chn->common, true);
> -	if (ret)
> -		goto err;
> -
>  	tx_chn->common.hdesc_size = cppi5_hdesc_calc_size(tx_chn->common.epib,
>  						tx_chn->common.psdata_size,
>  						tx_chn->common.swdata_size);
> @@ -312,7 +296,7 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>  	if (IS_ERR(tx_chn->udma_tchanx)) {
>  		ret = PTR_ERR(tx_chn->udma_tchanx);
>  		dev_err(dev, "UDMAX tchanx get err %d\n", ret);
> -		goto err;
> +		return ret;
>  	}
>  	tx_chn->udma_tchan_id = xudma_tchan_get_id(tx_chn->udma_tchanx);
>  
> @@ -325,7 +309,7 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>  		dev_err(dev, "Channel Device registration failed %d\n", ret);
>  		put_device(&tx_chn->common.chan_dev);
>  		tx_chn->common.chan_dev.parent = NULL;
> -		goto err;
> +		return ret;
>  	}
>  
>  	if (xudma_is_pktdma(tx_chn->common.udmax)) {
> @@ -349,7 +333,7 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>  					     &tx_chn->ringtxcq);
>  	if (ret) {
>  		dev_err(dev, "Failed to get TX/TXCQ rings %d\n", ret);
> -		goto err;
> +		return ret;
>  	}
>  
>  	/* Set the dma_dev for the rings to be configured */
> @@ -365,13 +349,13 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>  	ret = k3_ringacc_ring_cfg(tx_chn->ringtx, &cfg->tx_cfg);
>  	if (ret) {
>  		dev_err(dev, "Failed to cfg ringtx %d\n", ret);
> -		goto err;
> +		return ret;
>  	}
>  
>  	ret = k3_ringacc_ring_cfg(tx_chn->ringtxcq, &cfg->txcq_cfg);
>  	if (ret) {
>  		dev_err(dev, "Failed to cfg ringtx %d\n", ret);
> -		goto err;
> +		return ret;
>  	}
>  
>  	/* request and cfg psi-l */
> @@ -382,11 +366,42 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>  	ret = k3_udma_glue_cfg_tx_chn(tx_chn);
>  	if (ret) {
>  		dev_err(dev, "Failed to cfg tchan %d\n", ret);
> -		goto err;
> +		return ret;
>  	}
>  
>  	k3_udma_glue_dump_tx_chn(tx_chn);
>  
> +	return 0;
> +}
> +
> +struct k3_udma_glue_tx_channel *
> +k3_udma_glue_request_tx_chn(struct device *dev, const char *name,
> +			    struct k3_udma_glue_tx_channel_cfg *cfg)
> +{
> +	struct k3_udma_glue_tx_channel *tx_chn;
> +	int ret;
> +
> +	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
> +	if (!tx_chn)
> +		return ERR_PTR(-ENOMEM);
> +
> +	tx_chn->common.dev = dev;
> +	tx_chn->common.swdata_size = cfg->swdata_size;
> +	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
> +	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
> +	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
> +	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
> +
> +	/* parse of udmap channel */
> +	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
> +					&tx_chn->common, true);
> +	if (ret)
> +		goto err;
> +
> +	ret = k3_udma_glue_request_tx_chn_common(dev, tx_chn, cfg);
> +	if (ret)
> +		goto err;
> +
>  	return tx_chn;
>  
>  err:
> @@ -395,6 +410,40 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>  }
>  EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn);
>  
> +struct k3_udma_glue_tx_channel *
> +k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg,
> +				  struct device_node *udmax_np, u32 thread_id)

udmax_np is not dev->of_node ?

> +{
> +	struct k3_udma_glue_tx_channel *tx_chn;
> +	int ret;
> +
> +	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
> +	if (!tx_chn)
> +		return ERR_PTR(-ENOMEM);
> +
> +	tx_chn->common.dev = dev;
> +	tx_chn->common.swdata_size = cfg->swdata_size;
> +	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
> +	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
> +	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
> +	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
> +
> +	ret = of_k3_udma_glue_parse_chn_by_id(udmax_np, &tx_chn->common, true, thread_id);
> +	if (ret)
> +		goto err;
> +
> +	ret = k3_udma_glue_request_tx_chn_common(dev, tx_chn, cfg);
> +	if (ret)
> +		goto err;
> +
> +	return tx_chn;
> +
> +err:
> +	k3_udma_glue_release_tx_chn(tx_chn);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn_by_id);
> +
>  void k3_udma_glue_release_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
>  {
>  	if (tx_chn->psil_paired) {
> diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h
> index e443be4d3b4b..6205d84430ca 100644
> --- a/include/linux/dma/k3-udma-glue.h
> +++ b/include/linux/dma/k3-udma-glue.h
> @@ -26,6 +26,10 @@ struct k3_udma_glue_tx_channel;
>  struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>  		const char *name, struct k3_udma_glue_tx_channel_cfg *cfg);
>  
> +struct k3_udma_glue_tx_channel *
> +k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg,

I know it is going to be longer, but can the function be named more
precisely?
k3_udma_glue_request_tx_chn_by_thread_id

For TX/RX: a channel is always for one thread, right?
Probably:
k3_udma_glue_request_tx_chn_for_thread_id()

?

Other then this the series looks OK.


> +				  struct device_node *udmax_np, u32 thread_id);
> +
>  void k3_udma_glue_release_tx_chn(struct k3_udma_glue_tx_channel *tx_chn);
>  int k3_udma_glue_push_tx_chn(struct k3_udma_glue_tx_channel *tx_chn,
>  			     struct cppi5_host_desc_t *desc_tx,

-- 
P?ter


From semen.protsenko at linaro.org  Thu Dec 14 07:42:53 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:42:53 -0600
Subject: [PATCH 09/13] arm64: dts: exynos: gs101: update USI UART to use
 peric0 clocks
In-Reply-To: <20231214105243.3707730-10-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-10-tudor.ambarus@linaro.org>
Message-ID: <CAPLW+4kzdsuHiPqFuCbgD+595Kg3+mM8ziXr+D3K0LvEQXF_rQ@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:53?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> Get rid of the dummy clock and start using the cmu_peric0 clocks
> for the usi_uart and serial_0 nodes.
>
> Tested the serial at 115200, 1000000 and 3000000 baudrates,
> everthing went fine.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  arch/arm64/boot/dts/exynos/google/gs101.dtsi | 14 ++++----------
>  1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index d0b0ad70c6ba..ffb7b4d89a8c 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -180,14 +180,6 @@ HERA_CPU_SLEEP: cpu-hera-sleep {
>                 };
>         };
>
> -       /* TODO replace with CCF clock */
> -       dummy_clk: clock-3 {
> -               compatible = "fixed-clock";
> -               #clock-cells = <0>;
> -               clock-frequency = <12345>;
> -               clock-output-names = "pclk";
> -       };
> -
>         /* ect node is required to be present by bootloader */
>         ect {
>         };
> @@ -369,7 +361,8 @@ usi_uart: usi at 10a000c0 {
>                         ranges;
>                         #address-cells = <1>;
>                         #size-cells = <1>;
> -                       clocks = <&dummy_clk>, <&dummy_clk>;
> +                       clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
> +                                <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;

Why using DIV clock here? Usually all leaf clocks are GATE clocks (at
least it's so in Exynos850).

>                         clock-names = "pclk", "ipclk";
>                         samsung,sysreg = <&sysreg_peric0 0x1020>;
>                         samsung,mode = <USI_V2_UART>;
> @@ -381,7 +374,8 @@ serial_0: serial at 10a00000 {
>                                 reg-io-width = <4>;
>                                 interrupts = <GIC_SPI 634
>                                               IRQ_TYPE_LEVEL_HIGH 0>;
> -                               clocks = <&dummy_clk 0>, <&dummy_clk 0>;
> +                               clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
> +                                        <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;

Ditto.

>                                 clock-names = "uart", "clk_uart_baud0";
>                                 samsung,uart-fifosize = <256>;
>                                 status = "disabled";
> --
> 2.43.0.472.g3155946c3a-goog
>


From afd at ti.com  Thu Dec 14 07:43:43 2023
From: afd at ti.com (Andrew Davis)
Date: Thu, 14 Dec 2023 09:43:43 -0600
Subject: [PATCH 2/3] arm64: dts: ti: Introduce J722S family of SoCs
In-Reply-To: <20231214122713.qx7as6grpvlq3ylw@stoic>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
 <20231213124930.3012-3-vaishnav.a@ti.com>
 <20231213202705.6tspycl5qicb6gwd@germproof>
 <08eccba2-41df-91e7-c1e5-e03190402c23@ti.com>
 <20231214122713.qx7as6grpvlq3ylw@stoic>
Message-ID: <f2bc6c68-742a-4a21-956e-91ee0933dd96@ti.com>

On 12/14/23 6:27 AM, Nishanth Menon wrote:
> On 14:07-20231214, Vaishnav Achath wrote:
> [..]
>>> Trim this down to what is different from AM62P?
>>>
>>
>> Thanks for the review, I will trim this down in next revision, but the above is
>> just a summary of the main features of this SoC, pointing to AM62P feature set
>> here seems confusing to me. why does a new user/developer using J722S need to be
>> aware of the existence of AM62P to just understand a high level summary about
>> this device?
> 
> Since this is a reuse device. Helps with review and focus on deltas.
> 
> [...]
> 
>>>> +	l2_0: l2-cache0 {
>>>> +		compatible = "cache";
>>>> +		cache-unified;
>>>> +		cache-level = <2>;
>>>> +		cache-size = <0x80000>;
>>>> +		cache-line-size = <64>;
>>>> +		cache-sets = <512>;
>>>> +	};
>>>
>>> ^^ this is a duplication of am62p5.dtsi? what about the spins with
>>> different CPUs enabled?
>>>
>>
>> Yes it is a duplicate, as of now we are not aware of plan for spins with cores
>> disabled, so just followed the pattern followed for other Jacinto devices
>> (J721e, J7200, J721s2, J784s4).
> 
> None of the devices have been as close a reuse device as this has been.

I'd argue J721e and J7200 are more similar in terms of reuse. It was a
mistake to model them as simple super/subsets of each other, only causes
confusion later. Let's keep at least this top level file, we will end up
using it more as more features/deltas are enabled/found.

> errata in one carries over to the other etc.. There are definitely some
> differences - for example: itap/otap delays for mmc those would be
> unique on this device, but overrides with documentation will make
> perfect sense there.
> 
> [..]
>>>> +		cbass_wakeup: bus at b00000 {
>>>> +			compatible = "simple-bus";
>>>> +			#address-cells = <2>;
>>>> +			#size-cells = <2>;
>>>> +			ranges = <0x00 0x00b00000 0x00 0x00b00000 0x00 0x00002400>, /* VTM */
>>>> +				 <0x00 0x2b000000 0x00 0x2b000000 0x00 0x00300400>, /* Peripheral Window */
>>>> +				 <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* WKUP CTRL MMR */
>>>> +				 <0x00 0x78000000 0x00 0x78000000 0x00 0x00008000>, /* DM R5 ATCM*/
>>>> +				 <0x00 0x78100000 0x00 0x78100000 0x00 0x00008000>; /* DM R5 BTCM*/
>>>> +			bootph-all;
>>>
>>> Not in the bus nodes.. only in the leaf nodes please.
>>>
>>>
>>> Also what is wrong with expanding the am62p to include the
>>> missing bus segments instead of duplicating all of them?
>>>
>>
>> We can do that, but the same would be true for AM625, AM62A and AM62P families
>> and also for (J721E, J7200), since all these SoCs introduced new dtsi instead of
>> resuing existing ones, I thought there would be some valid reason to have
>> separate dtsi and just followed the same pattern, please let know if we need to
>> reuse from AM62P here also.
> 
> See above.
> 
> [...]
> 
>>
>>>> +		};
>>>> +	};
>>>> +
>>>> +	#include "k3-am62p-thermal.dtsi"
>>>
>>> Is this correct?
>>>
>>
>> I think it would be preferred to have a duplicate for J722S here as users may
>> want to customize the trip points as per system and doing that without affecting
>> AM62P would be preferred, but the initial information here would be same for J722S.
> 
> Please check with your hardware teams if the am62p SoC level thermal
> behavior will be similar to j722s or will it be different. If it is
> estimated to be different, then you'd prefer to hold off introducing
> the trips till the characterization provides you with the data.
> 
>>
>>>> +};
>>>> +
>>>> +/*
>>>> + * Include peripherals for each bus segment derived
>>>> + * from AM62P and overrides specific to J722S.
>>>> + */
>>>> +#include "k3-am62p-main.dtsi"
>>>> +#include "k3-am62p-mcu.dtsi"
>>>> +#include "k3-am62p-wakeup.dtsi"
>>>> +
>>>> +/* Main domain overrides */
>>>> +
>>>> +&cpsw3g {
>>>> +	status = "disabled";
>>>
>>> 	here and rest: Why disabled?
>>
>> These nodes seems to have dependencies that are not merged already and would
>> throw errors during boot, AM62P SoC dtsi seems to have these enabled by default
>> without these dependencies met and have errors like below during boot (seen on
>> AM62P with 6.7.0-rc4-next-20231211).
>>
>> [   17.869092] platform 8000000.ethernet: deferred probe pending:
>> am65-cpsw-nuss: Failed to request tx dma channel
> 
> OK - lets get the dependencies sorted out before merging then. I though
> all the dependencies were indicated in the cover letter.
> 
>>
>>>> +};
>>>> +
>>>> +&inta_main_dmss {
>>>> +	ti,interrupt-ranges = <5 69 35>;
>>>> +};
>>>> +
>>>> +&mailbox0_cluster0 {
>>>> +	status = "disabled";
>>>> +};
>>>> +
>>>> +&mailbox0_cluster1 {
>>>> +	status = "disabled";
>>>> +};
>>>> +
>>>> +&mailbox0_cluster2 {
>>>> +	status = "disabled";
>>>> +};
>>>> +
>>>> +&mailbox0_cluster3 {
>>>> +	status = "disabled";
>>>> +};
>>>> +
>>
>> [    7.198470] omap-mailbox 29020000.mailbox: no available mbox devices found
>> [    7.210411] omap-mailbox 29030000.mailbox: no available mbox devices found
> 
> You might want to dig into why..
> 
>>
>>>> +&oc_sram {
>>>> +	reg = <0x00 0x70000000 0x00 0x40000>;
>>>> +	ranges = <0x00 0x00 0x70000000 0x40000>;
>>>> +};
>>>> +
>>>> +/* MCU domain overrides */
>>>> +
>>>> +&mcu_r5fss0 {
>>>> +	status = "disabled";
>>>> +};
>>
>> [    7.492406] platform 79000000.r5f: configured R5F for remoteproc mode
>> [    7.499887] platform 79000000.r5f: device does not have reserved memory
>> regions, ret = -22
>> [    7.508271] k3_r5_rproc bus at f0000:bus at 4000000:r5fss at 79000000: reserved memory
>> init failed, ret = -22
>> [    7.517549] remoteproc remoteproc0: releasing 79000000.r5f
>> [    7.523338] k3_r5_rproc bus at f0000:bus at 4000000:r5fss at 79000000:
>> k3_r5_cluster_rproc_init failed, ret = -22
>> [    7.532993] k3_r5_rproc: probe of bus at f0000:bus at 4000000:r5fss at 79000000 failed
>> with error -22
> 
> Yes, and the approach should rather be to disable the remote procs in
> the board or at the SoC dtsi in a consistent manner. I had previously
> suggested to do that SoC level (which means at am62p dtsi) since the remoteprocs have direct
> dependency on how the memory layouts are partitioned in board.dts - but
> i had asked folks working on remote procs to do that consistently across
> SoCs. I don't see that having been done so far.
> 

I fixed this for a couple SoCs way back last year (7e48b665100ee), seems
folks kept adding mailboxes/rprocs un-disabled in the base .dtbi for
new SoCs anyway :( This needs fixed in AM62p .dtsi first, then these
disables can be removed from here.

Andrew

>>
>>>> +
>>>> +/* wakeup domain overrides */
>>>> +
>>>> +&wkup_r5fss0 {
>>>> +	status = "disabled";
>>>> +};
>>
>> [    7.576576] platform 78000000.r5f: configured R5F for IPC-only mode
>> [    7.605535] platform 78000000.r5f: device does not have reserved memory
>> regions, ret = -22
>> [    7.613942] k3_r5_rproc bus at f0000:bus at b00000:r5fss at 78000000: reserved memory
>> init failed, ret = -22
>> [    7.635990] remoteproc remoteproc0: releasing 78000000.r5f
>> [    7.648639] k3_r5_rproc bus at f0000:bus at b00000:r5fss at 78000000:
>> k3_r5_cluster_rproc_init failed, ret = -22
>> [    7.664043] k3_r5_rproc: probe of bus at f0000:bus at b00000:r5fss at 78000000 failed
>> with error -22
> 
> See above.
> 
>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-pinctrl.h b/arch/arm64/boot/dts/ti/k3-pinctrl.h
>>>> index 2a4e0e084d69..591be4489f37 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-pinctrl.h
>>>> +++ b/arch/arm64/boot/dts/ti/k3-pinctrl.h
>>>> @@ -59,6 +59,9 @@
>>>>   #define J721S2_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
>>>>   #define J721S2_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
>>>>   
>>>> +#define J722S_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
>>>> +#define J722S_MCU_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
>>>> +
>>>>   #define J784S4_IOPAD(pa, val, muxmode)		(((pa) & 0x1fff)) ((val) | (muxmode))
>>>>   #define J784S4_WKUP_IOPAD(pa, val, muxmode)	(((pa) & 0x1fff)) ((val) | (muxmode))
>>>>   
>>>> -- 
>>>> 2.17.1
>>>>
>>
>> 0 - AM62P Boot logs (next-20231211) -
>> https://gist.github.com/vaishnavachath/7143da253bc708a1e60a13fe081d3914
>>
>> To avoid these errors I am keeping these disabled, can we add support for these
>> also as part of the initial support addition series? then there is no need for
>> disabling these.
> 
> Fix them, then introduce j722s.
> 


From alexandru.elisei at arm.com  Thu Dec 14 07:45:25 2023
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Thu, 14 Dec 2023 15:45:25 +0000
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <CAL_JsqLAW0--F8R0oTaajN3YpbK2KgE6Ypn8tk4_pf_s=xC+aw@mail.gmail.com>
References: <20231119165721.9849-12-alexandru.elisei@arm.com>
 <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
 <ZXiMiLz9ZyUdxUP8@raptor>
 <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
 <ZXmr-Kl9L2SO13--@raptor>
 <CAL_JsqL=P1Y6w38LD_xw+vK4CNqt22FW_FE9oi_XTLHVQEne7Q@mail.gmail.com>
 <ZXnE3724jYYSg4o6@raptor>
 <CAL_JsqJgTnuQjo13cKo1Ebm5j9tCRT8GhNavdqu5vwp+fdnTLw@mail.gmail.com>
 <ZXnthcg0BkEd-RgK@raptor>
 <CAL_JsqLAW0--F8R0oTaajN3YpbK2KgE6Ypn8tk4_pf_s=xC+aw@mail.gmail.com>
Message-ID: <ZXsjFYKHkJM_JLCy@raptor>

Hi,

On Wed, Dec 13, 2023 at 02:30:42PM -0600, Rob Herring wrote:
> On Wed, Dec 13, 2023 at 11:44?AM Alexandru Elisei
> <alexandru.elisei at arm.com> wrote:
> >
> > On Wed, Dec 13, 2023 at 11:22:17AM -0600, Rob Herring wrote:
> > > On Wed, Dec 13, 2023 at 8:51?AM Alexandru Elisei
> > > <alexandru.elisei at arm.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> > > > > On Wed, Dec 13, 2023 at 7:05?AM Alexandru Elisei
> > > > > <alexandru.elisei at arm.com> wrote:
> > > > > >
> > > > > > Hi Rob,
> > > > > >
> > > > > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > > > > > On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
> > > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > > >
> > > > > > > > Hi Rob,
> > > > > > > >
> > > > > > > > Thank you so much for the feedback, I'm not very familiar with device tree,
> > > > > > > > and any comments are very useful.
> > > > > > > >
> > > > > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > > > > > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > > > > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > > > > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > > > > > > >
> > > > > > > > > > The DTB node for the tag storage region is defined as:
> > > > > > > > > >
> > > > > > > > > >         tags0: tag-storage at 8f8000000 {
> > > > > > > > > >                 compatible = "arm,mte-tag-storage";
> > > > > > > > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > > > > > > > >                 block-size = <0x1000>;
> > > > > > > > > >                 memory = <&memory0>;    // Associated tagged memory node
> > > > > > > > > >         };
> > > > > > > > >
> > > > > > > > > I skimmed thru the discussion some. If this memory range is within
> > > > > > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > > > > > >
> > > > > > > > Ok, will do that.
> > > > > > > >
> > > > > > > > If you don't mind, why do you say that it definitely belongs in
> > > > > > > > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > > > > > > > motivation.
> > > > > > >
> > > > > > > Simply so that /memory nodes describe all possible memory and
> > > > > > > /reserved-memory is just adding restrictions. It's also because
> > > > > > > /reserved-memory is what gets handled early, and we don't need
> > > > > > > multiple things to handle early.
> > > > > > >
> > > > > > > > Tag storage is not DMA and can live anywhere in memory.
> > > > > > >
> > > > > > > Then why put it in DT at all? The only reason CMA is there is to set
> > > > > > > the size. It's not even clear to me we need CMA in DT either. The
> > > > > > > reasoning long ago was the kernel didn't do a good job of moving and
> > > > > > > reclaiming contiguous space, but that's supposed to be better now (and
> > > > > > > most h/w figured out they need IOMMUs).
> > > > > > >
> > > > > > > But for tag storage you know the size as it is a function of the
> > > > > > > memory size, right? After all, you are validating the size is correct.
> > > > > > > I guess there is still the aspect of whether you want enable MTE or
> > > > > > > not which could be done in a variety of ways.
> > > > > >
> > > > > > Oh, sorry, my bad, I should have been clearer about this. I don't want to
> > > > > > put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.
> > > > >
> > > > > Yes, I understand, but my point remains. Why do you need this in DT?
> > > > > If the location doesn't matter and you can calculate the size from the
> > > > > memory size, what else is there to add to the DT?
> > > >
> > > > I am afraid there has been a misunderstanding. What do you mean by
> > > > "location doesn't matter"?
> > >
> > > You said:
> > > > Tag storage is not DMA and can live anywhere in memory.
> > >
> > > Which I took as the kernel can figure out where to put it. But maybe
> > > you meant the h/w platform can hard code it to be anywhere in memory?
> > > If so, then yes, DT is needed.
> >
> > Ah, I see, sorry for not being clear enough, you are correct: tag storage
> > is a hardware property, and software needs a mechanism (in this case, the
> > dt) to discover its properties.
> >
> > >
> > > > At the very least, Linux needs to know the address and size of a memory
> > > > region to use it. The series is about using the tag storage memory for
> > > > data. Tag storage cannot be described as a regular memory node because it
> > > > cannot be tagged (and normal memory can).
> > >
> > > If the tag storage lives in the middle of memory, then it would be
> > > described in the memory node, but removed by being in reserved-memory
> > > node.
> >
> > I don't follow. Would you mind going into more details?
> 
> It goes back to what I said earlier about /memory nodes describing all
> the memory. There's no reason to reserve memory if you haven't
> described that range as memory to begin with. One could presumably
> just have a memory node for each contiguous chunk and not need
> /reserved-memory (ignoring the need to say what things are reserved
> for). That would become very difficult to adjust. Note that the kernel
> has a hardcoded limit of 64 reserved regions currently and that is not
> enough for some people. Seems like a lot, but I have no idea how they
> are (ab)using /reserved-memory.

Ah, I see what you mean, reserved memory is about marking existing memory
(from a /memory node) as special, not about adding new memory.

After the memblock allocator is initialized, the kernel can use it for its
own allocations. Kernel allocations are not movable.

When a page is allocated as tagged, the associated tag storage cannot be
used for data, otherwise the tags would corrupt that data. To avoid this,
the requirement is that tag storage pages are only used for movable
allocations. When a page is allocated as tagged, the data in the associated
tag storage is migrated and the tag storage is taken from the page
allocator (via alloc_contig_range()).

My understanding is that the memblock allocator can use all the memory from
a /memory node. If the tags storage memory is declared in a /memory node,
there exists the possibility that Linux will use tag storage memory for its
own allocation, which would make that tags storage memory unmovable, and
thus unusable for storing tags.

Looking at early_init_dt_scan_memory(), even if a /memory node if marked at
hotpluggable, memblock will still use it, unless "movable_node" is set on
the kernel command line.

That's the reason why I'm not describing tag storage in a /memory node.  Is
there way to tell the memblock allocator not to use memory from a /memory
node?

> 
> Let me give an example. Presumably using MTE at all is configurable.
> If you boot a kernel with MTE disabled (or older and not supporting
> it), then I'd assume you'd want to use the tag storage for regular
> memory. Well, If tag storage is already part of /memory, then all you
> have to do is ignore the tag reserved-memory region. Tweaking the
> memory nodes would be more work.

Right now, memory is added via memblock_reserve(), and if MTE is disabled
(for example, via the kernel command line), the code calls
free_reserved_page() for each tag storage page. I find that straightfoward
to implement.

Thanks,
Alex

> 
> 
> Also, I should point out that /memory and /reserved-memory nodes are
> not used for UEFI boot.
> 
> Rob
> 


From lpieralisi at kernel.org  Thu Dec 14 07:48:15 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Thu, 14 Dec 2023 16:48:15 +0100
Subject: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for
 vfio pci devices
In-Reply-To: <ZXoOieQN7rBiLL4A@linux.dev>
References: <20231208164709.23101-1-ankita@nvidia.com>
 <20231208164709.23101-3-ankita@nvidia.com>
 <ZXicemDzXm8NShs1@arm.com>
 <20231212181156.GO3014157@nvidia.com>
 <ZXoOieQN7rBiLL4A@linux.dev>
Message-ID: <ZXsjv+svp44YjMmh@lpieralisi>

[+James]

On Wed, Dec 13, 2023 at 08:05:29PM +0000, Oliver Upton wrote:
> Hi,
> 
> Sorry, a bit late to the discussion :)
> 
> On Tue, Dec 12, 2023 at 02:11:56PM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 12, 2023 at 05:46:34PM +0000, Catalin Marinas wrote:
> > > should know the implications. There's also an expectation that the
> > > actual driver (KVM guests) or maybe later DPDK can choose the safe
> > > non-cacheable or write-combine (Linux terminology) attributes for the
> > > BAR.
> > 
> > DPDK won't rely on this interface
> 
> Wait, so what's the expected interface for determining the memory
> attributes at stage-1? I'm somewhat concerned that we're conflating two
> things here:
> 
>  1) KVM needs to know the memory attributes to use at stage-2, which
>     isn't fundamentally different from what's needed for userspace
>     stage-1 mappings.
> 
>  2) KVM additionally needs a hint that the device / VFIO can handle
>     mismatched aliases w/o the machine exploding. This goes beyond
>     supporting Normal-NC mappings at stage-2 and is really a bug
>     with our current scheme (nGnRnE at stage-1, nGnRE at stage-2).
> 
> I was hoping that (1) could be some 'common' plumbing for both userspace
> and KVM mappings. And for (2), any case where a device is intolerant of
> mismatches && KVM cannot force the memory attributes should be rejected.
> 
> AFAICT, the only reason PCI devices can get the blanket treatment of
> Normal-NC at stage-2 is because userspace has a Device-* mapping and can't
> speculatively load from the alias. This feels a bit hacky, and maybe we
> should prioritize an interface for mapping a device into a VM w/o a
> valid userspace mapping.

FWIW - I have tried to summarize the reasoning behind PCIe devices
Normal-NC default stage-2 safety in a document that I have just realized
now it has become this series cover letter, I don't think the PCI blanket
treatment is related *only* to the current user space mappings (ie
BTW, AFAICS it is also *possible* at present to map a prefetchable BAR through
sysfs with Normal-NC memory attributes in the host at the same time a PCI
device is passed-through to a guest with VFIO - and therefore we have a
dev-nGnRnE stage-1 mapping for it. Don't think anyone does that - what for -
but it is possible and KVM would not know about it).

Again, FWIW, we were told (source Arm ARM) mismatched aliases concerning
device-XXX vs Normal-NC are not problematic as long as the transactions
issued for the related mappings are independent (and none of the
mappings is cacheable).

I appreciate this is not enough to give everyone full confidence on
this solution robustness - that's why I wrote that up so that we know
what we are up against and write KVM interfaces accordingly.

> I very much understand that this has been going on for a while, and we
> need to do *something* to get passthrough working well for devices that
> like 'WC'. I just want to make sure we don't paint ourselves into a corner
> that's hard to get out of in the future.

That makes perfect sense, see above, if there is anything we can do
to clarify we will, in whatever shape it is preferred.

Thanks,
Lorenzo


From semen.protsenko at linaro.org  Thu Dec 14 07:51:29 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:51:29 -0600
Subject: [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C configuration
In-Reply-To: <20231214105243.3707730-11-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-11-tudor.ambarus@linaro.org>
Message-ID: <CAPLW+4nKgAN2_dE1-28KbAobR55pr2RzKD1fjA2WN2A-tQ4MpA@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:53?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> USI8 I2C is used to communicate with an eeprom found on the battery
> connector. Define USI8 in I2C configuration.
>
> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
> selection of the protocol is intentionally left for the board dtsi file.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  arch/arm64/boot/dts/exynos/google/gs101.dtsi | 26 ++++++++++++++++++++
>  1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index ffb7b4d89a8c..4ea1b180cd0a 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -354,6 +354,32 @@ pinctrl_peric0: pinctrl at 10840000 {
>                         interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
>                 };
>
> +               usi8: usi at 109700c0 {
> +                       compatible = "google,gs101-usi",
> +                                    "samsung,exynos850-usi";
> +                       reg = <0x109700c0 0x20>;
> +                       ranges;
> +                       #address-cells = <1>;
> +                       #size-cells = <1>;
> +                       clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,

Are you sure this is a leaf clock? Usually it's a GATE clock, not a DIV one.

> +                                <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;

Because of following letter-for-letter the crazy TRM clock namings,
now it's not possible to keep 80 characters length in a sane way :(

> +                       clock-names = "pclk", "ipclk";
> +                       samsung,sysreg = <&sysreg_peric0 0x101c>;

samsung,mode is not needed in this case?

> +                       status = "disabled";
> +
> +                       hsi2c_8: i2c at 10970000 {
> +                               compatible = "google,gs101-hsi2c",
> +                                            "samsung,exynosautov9-hsi2c";
> +                               reg = <0x10970000 0xc0>;
> +                               interrupts = <GIC_SPI 642
> +                                             IRQ_TYPE_LEVEL_HIGH 0>;

IRQ type constant can fit the previous line.

> +                               clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
> +                                        <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
> +                               clock-names = "hsi2c", "hsi2c_pclk";
> +                               status = "disabled";

Pinctrl properties are not needed for this node?

> +                       };
> +               };
> +
>                 usi_uart: usi at 10a000c0 {
>                         compatible = "google,gs101-usi",
>                                      "samsung,exynos850-usi";
> --
> 2.43.0.472.g3155946c3a-goog
>


From semen.protsenko at linaro.org  Thu Dec 14 07:55:03 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 09:55:03 -0600
Subject: [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
In-Reply-To: <20231214105243.3707730-12-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-12-tudor.ambarus@linaro.org>
Message-ID: <CAPLW+4nTgam4jZ+s5m5E05jWO_kfSy=fMS0Ywp3yQEEn-UESbg@mail.gmail.com>

On Thu, Dec 14, 2023 at 4:53?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> Enable the eeprom found on the battery connector.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  .../boot/dts/exynos/google/gs101-oriole.dts    | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> index 4a71f752200d..11b299d21c5d 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> @@ -63,6 +63,19 @@ &ext_200m {
>         clock-frequency = <200000000>;
>  };
>
> +&hsi2c_8 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&hsi2c8_bus>;
> +       #address-cells = <1>;
> +       #size-cells = <0>;

Not sure if those 4 above properties belong in board's dts or in SoC's
dtsi. Krzysztof, what do you think?

Other than that:

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

> +       status = "okay";
> +
> +       eeprom: eeprom at 50 {
> +               compatible = "atmel,24c08";
> +               reg = <0x50>;
> +       };
> +};
> +
>  &pinctrl_far_alive {
>         key_voldown: key-voldown-pins {
>                 samsung,pins = "gpa7-3";
> @@ -99,6 +112,11 @@ &usi_uart {
>         status = "okay";
>  };
>
> +&usi8 {
> +       samsung,mode = <USI_V2_I2C>;
> +       status = "okay";
> +};
> +
>  &watchdog_cl0 {
>         timeout-sec = <30>;
>         status = "okay";
> --
> 2.43.0.472.g3155946c3a-goog
>


From m.szyprowski at samsung.com  Thu Dec 14 07:59:13 2023
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 14 Dec 2023 16:59:13 +0100
Subject: [PATCH] drm/exynos: fix accidental on-stack copy of
 exynos_drm_plane
In-Reply-To: <20231214123237.1727428-1-arnd@kernel.org>
References: <CGME20231214123248eucas1p1577bc2064401fce57a752234e1338f5a@eucas1p1.samsung.com>
	<20231214123237.1727428-1-arnd@kernel.org>
Message-ID: <699636b7-d737-4df4-92e9-43b0f52d4b99@samsung.com>

On 14.12.2023 13:32, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
>
> gcc rightfully complains about excessive stack usage in the fimd_win_set_pixfmt()
> function:
>
> drivers/gpu/drm/exynos/exynos_drm_fimd.c: In function 'fimd_win_set_pixfmt':
> drivers/gpu/drm/exynos/exynos_drm_fimd.c:750:1: error: the frame size of 1032 bytes is larger than 1024 byte
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function 'decon_win_set_pixfmt':
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c:381:1: error: the frame size of 1032 bytes is larger than 1024 bytes
>
> There is really no reason to copy the large exynos_drm_plane
> structure to the stack before using one of its members, so just
> use a pointer instead.
>
> Fixes: 6f8ee5c21722 ("drm/exynos: fimd: Make plane alpha configurable")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>


Reviewed-by: Marek Szyprowski <m.szyprowski at samsung.com>


> ---
>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
>   drivers/gpu/drm/exynos/exynos_drm_fimd.c      | 4 ++--
>   2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 4d986077738b..bce027552474 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -319,9 +319,9 @@ static void decon_win_set_bldmod(struct decon_context *ctx, unsigned int win,
>   static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
>   				 struct drm_framebuffer *fb)
>   {
> -	struct exynos_drm_plane plane = ctx->planes[win];
> +	struct exynos_drm_plane *plane = &ctx->planes[win];
>   	struct exynos_drm_plane_state *state =
> -		to_exynos_plane_state(plane.base.state);
> +		to_exynos_plane_state(plane->base.state);
>   	unsigned int alpha = state->base.alpha;
>   	unsigned int pixel_alpha;
>   	unsigned long val;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 8dde7b1e9b35..5bdc246f5fad 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -661,9 +661,9 @@ static void fimd_win_set_bldmod(struct fimd_context *ctx, unsigned int win,
>   static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
>   				struct drm_framebuffer *fb, int width)
>   {
> -	struct exynos_drm_plane plane = ctx->planes[win];
> +	struct exynos_drm_plane *plane = &ctx->planes[win];
>   	struct exynos_drm_plane_state *state =
> -		to_exynos_plane_state(plane.base.state);
> +		to_exynos_plane_state(plane->base.state);
>   	uint32_t pixel_format = fb->format->format;
>   	unsigned int alpha = state->base.alpha;
>   	u32 val = WINCONx_ENWIN;

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From tudor.ambarus at linaro.org  Thu Dec 14 08:01:18 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 16:01:18 +0000
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock
 as critical
In-Reply-To: <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-8-tudor.ambarus@linaro.org>
 <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>
Message-ID: <f3d61c49-1a46-476c-b7a5-6cc6a06a33ed@linaro.org>



On 12/14/23 15:37, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>
>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>> which then makes the system hang. To prevent this, mark
>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>> accordingly when tested.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>> ---
>>  drivers/clk/samsung/clk-gs101.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>> index 3d194520b05e..08d80fca9cd6 100644
>> --- a/drivers/clk/samsung/clk-gs101.c
>> +++ b/drivers/clk/samsung/clk-gs101.c
>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>              "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>              21, 0, 0),
>>         GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>> -            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>> +            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> 
> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> Leaving it always running makes the whole PERIC0 CMU clocked, which
> usually should be avoided. Is it possible that the system freezes
> because some other clock (which depends on peric0_ip) gets disabled as
> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> is not implemented yet in the clock driver? Just looks weird to me
> that the system hangs because of CMU IP clock disablement. It's
> usually something much more specific.

The system hang happened when I tested USI8 in I2C configuration with an
eeprom. After the eeprom is read the leaf gate clock that gets disabled
is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
disablement which makes the system hang. Either marking the CMU_TOP gate
clock as critical (as I did in this patch) or marking the leaf PERIC0
gate clock as critical, gets rid of the system hang. Did I choose wrong?

Thanks,
ta
> 
>>         GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
>>              "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
>>              21, 0, 0),
>> --
>> 2.43.0.472.g3155946c3a-goog
>>


From ryan.roberts at arm.com  Thu Dec 14 08:02:51 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Thu, 14 Dec 2023 16:02:51 +0000
Subject: [PATCH] mm: Resolve some multi-size THP review nits
In-Reply-To: <e2da3c78-85f7-4516-bbab-97fac9629dcc@suswa.mountain>
References: <e2da3c78-85f7-4516-bbab-97fac9629dcc@suswa.mountain>
Message-ID: <20231214160251.3574571-1-ryan.roberts@arm.com>

Tidy code based on review feedback for final version of multi-size THP:

 - Comment added to explain alloc_anon_folio() error protocol
 - ifdefery simplified for alloc_anon_folio()

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
Hi Andrew,

Hopefully this is the final tweak. Could you please squash this with the
"mm: thp: Support allocation of anonymous multi-size THP" patch in mm-unstable?

Or if you prefer me to re-post the entire series, just let me know.

Thanks,
Ryan


 mm/memory.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 8f0b936b90b5..3c530b639559 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4137,9 +4137,9 @@ static bool pte_range_none(pte_t *pte, int nr_pages)
 	return true;
 }

-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static struct folio *alloc_anon_folio(struct vm_fault *vmf)
 {
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	struct vm_area_struct *vma = vmf->vma;
 	unsigned long orders;
 	struct folio *folio;
@@ -4199,12 +4199,9 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf)
 	}

 fallback:
-	return vma_alloc_zeroed_movable_folio(vma, vmf->address);
-}
-#else
-#define alloc_anon_folio(vmf) \
-		vma_alloc_zeroed_movable_folio((vmf)->vma, (vmf)->address)
 #endif
+	return vma_alloc_zeroed_movable_folio(vmf->vma, vmf->address);
+}

 /*
  * We enter with non-exclusive mmap_lock (to exclude vma changes,
@@ -4260,6 +4257,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
 	/* Allocate our own private page. */
 	if (unlikely(anon_vma_prepare(vma)))
 		goto oom;
+	/* Returns NULL on OOM or ERR_PTR(-EAGAIN) if we must retry the fault */
 	folio = alloc_anon_folio(vmf);
 	if (IS_ERR(folio))
 		return 0;
--
2.25.1



From graf at amazon.com  Thu Dec 14 08:02:40 2023
From: graf at amazon.com (Alexander Graf)
Date: Thu, 14 Dec 2023 17:02:40 +0100
Subject: [PATCH 00/15] kexec: Allow preservation of ftrace buffers
In-Reply-To: <87r0jo7rva.fsf@email.froward.int.ebiederm.org>
References: <20231213000452.88295-1-graf@amazon.com>
 <87r0jo7rva.fsf@email.froward.int.ebiederm.org>
Message-ID: <c0f89d9d-98c3-4b04-9077-d92a863db088@amazon.com>

Hey Eric,

On 14.12.23 15:58, Eric W. Biederman wrote:
> Alexander Graf <graf at amazon.com> writes:
>
>> Kexec today considers itself purely a boot loader: When we enter the new
>> kernel, any state the previous kernel left behind is irrelevant and the
>> new kernel reinitializes the system.
>>
>> However, there are use cases where this mode of operation is not what we
>> actually want. In virtualization hosts for example, we want to use kexec
>> to update the host kernel while virtual machine memory stays untouched.
>> When we add device assignment to the mix, we also need to ensure that
>> IOMMU and VFIO states are untouched. If we add PCIe peer to peer DMA, we
>> need to do the same for the PCI subsystem. If we want to kexec while an
>> SEV-SNP enabled virtual machine is running, we need to preserve the VM
>> context pages and physical memory. See James' and my Linux Plumbers
>> Conference 2023 presentation for details:
>>
>>    https://lpc.events/event/17/contributions/1485/
>>
>> To start us on the journey to support all the use cases above, this
>> patch implements basic infrastructure to allow hand over of kernel state
>> across kexec (Kexec HandOver, aka KHO). As example target, we use ftrace:
>> With this patch set applied, you can read ftrace records from the
>> pre-kexec environment in your post-kexec one. This creates a very powerful
>> debugging and performance analysis tool for kexec. It's also slightly
>> easier to reason about than full blown VFIO state preservation.
>>
>> == Alternatives ==
>>
>> There are alternative approaches to (parts of) the problems above:
>>
>>    * Memory Pools [1] - preallocated persistent memory region + allocator
>>    * PRMEM [2] - resizable persistent memory regions with fixed metadata
>>                  pointer on the kernel command line + allocator
>>    * Pkernfs [3] - preallocated file system for in-kernel data with fixed
>>                    address location on the kernel command line
>>    * PKRAM [4] - handover of user space pages using a fixed metadata page
>>                  specified via command line
>>
>> All of the approaches above fundamentally have the same problem: They
>> require the administrator to explicitly carve out a physical memory
>> location because they have no mechanism outside of the kernel command
>> line to pass data (including memory reservations) between kexec'ing
>> kernels.
>>
>> KHO provides that base foundation. We will determine later whether we
>> still need any of the approaches above for fast bulk memory handover of for
>> example IOMMU page tables. But IMHO they would all be users of KHO, with
>> KHO providing the foundational primitive to pass metadata and bulk memory
>> reservations as well as provide easy versioning for data.
> What you are describe in many ways is the same problem as
> kexec-on-panic.  The goal of leaving devices running absolutely requires
> carving out memory for the new kernel to live in while it is coming up
> so that DMA from a device that was not shutdown down does not stomp the
> kernel coming up.


Yes, part of the problem is similar: We need a safe space to boot from 
that doesn't overwrite existing data. What happens after is different: 
With panics, you're trying to rescue previous state for post-mortem 
analysis. You may even have intrinsic knowledge of the environment you 
came from, so you can optimize that rescuing. Nobody wants to continue 
running the system as if nothing happened after a panic.

With KHO, the kernels establish an ABI between each other to communicate 
any state that needs to get preserved and the rest gets reinitialized. 
After KHO, the new kernel continues executing workloads that were 
running before.

The ABI is important because the next environment may not have a chance 
to know about the previous environment's setup. Think for example of 
roll-out and roll-back scenarios: If I roll back into my previous 
environment because I determined something didn't work as expected after 
update, I'm moving the system into an environment that was built when 
the kexec source environment didn't even exist yet.


> If I understand the virtualization case some of those virtual machines
> are going to have virtual NICs that are going to want to DMA memory to
> the host system.  Which if I understand things correctly means that


No, to the *guest* system. This is about device assignment: The guest is 
in full control of the NICs that do DMA, so we have no chance to quiesce 
them.


> among the devices you explicitly want to keep running there is a not
> a way to avoid the chance of DMA coming in while the kernel is being
> changed.


Correct, because the host doesn't own the driver :).


> There is also a huge maintenance challenge associated with all of this.
>
> If you go with something that is essentially kexec-on-panic and then
> add a little bit to help find things in the memory of the previous
> kernel while the new kernel is coming up I can see it as a possibility.


That's roughly what the patch set is doing, yes. It avoids a static 
allocation ahead of time for next-kernel memory, because I only know the 
size of all components when we're actually doing the kexec. But the 
principle is similar.

The bit where the new kernel finds bits in the old memory is the KHO DT: 
A flattened device tree structure the old kernel passes to the new 
kernel. That contains all memory locations as well as additional 
metadata to "help find things" in a way that doesn't immediately break 
on every kernel change.


> As an example I think preserving ftrace data of kexec seems bizarre.
> I don't see how that is an interesting use case at all.  Not in
> the situation of preserving virtual machines, and not in the situation
> of kexec on panic.


It's super useful as self debugging aid: I already used it to profile 
the kexec path to find a few performance issues :). It's also really 
helpful - even without device assignment support yet - when you use it 
in combination with KVM trace points: You have a VM running backed by a 
DAX pmem device, then serialize its virtual device state, kexec, restore 
from the virtual device state, then the VM misbehaves.

With ftrace handover in place, you get a full trace of the flow which 
simplifies debugging of issues that happen during/because of the 
serialization/deserialization flow of KVM state.

But the main reason I chose ftrace to start with is that all other use 
cases require another concept: fd preservation. All the typical 
"objects" you want to preserve across kexec are anonymous file 
descriptors. So we need to also build a way in Linux that allows user 
space to request the kernel to preserve an fd using the kexec handover 
framework in this patch set. But that is another big discussion I wanted 
to keep separate: Ftrace is from kernel, to kernel and hence "easy".


> If you are doing an orderly shutdown and kernel switch you should be
> able to manually change the memory.  If you are not doing an orderly
> shutdown then I really don't get it.


I don't follow the paragraph above?


> I don't hate the capability you are trying to build.
>
> I have not read or looked at most of this so I am probably
> missing subtle details.
>
> As you are currently describing things I have the sense you have
> completely misframed the problem and are trying to solve the wrong parts
> of the problem.


Very well possible :). I hope the above clarifies it a bit. If not, 
please let me know where exactly it's unclear so I can elaborate.

If you have a few minutes, it would also be great if you could have a 
look at our slides [1] or even video [2] from LPC 2023 which go into 
detail of the end problem. Beware that I'm consciously *not* trying to 
solve the end problem yet: I want to take baby steps towards it. Nobody 
wants to review an 80 patches patch set where everything depends on 
everything else.


Alex


[1] 
https://lpc.events/event/17/contributions/1485/attachments/1296/2650/jgowans-preserving-across-kexec.pdf
[2] https://www.youtube.com/watch?v=cYrlV4bK1Y4




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From peter.griffin at linaro.org  Thu Dec 14 08:04:22 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Thu, 14 Dec 2023 16:04:22 +0000
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate
 clock names
In-Reply-To: <20231214105243.3707730-2-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org> <20231214105243.3707730-2-tudor.ambarus@linaro.org>
Message-ID: <CADrjBPr=j8sjG3gwRQBGjb7G+NQ6EDcxE+XixY6mT1rf06tyeA@mail.gmail.com>

Hi Tudor,

On Thu, 14 Dec 2023 at 10:52, Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> The gs101 clock names are derived from the clock register names under
> some certain rules. In particular, for the gate clocks the following is
> documented and expected in the gs101 clock driver:
>
>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>
>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>
> The CMU TOP gate clock names missed to include the required "CMU"
> differentiator which will cause name collisions with the gate clock names
> of other clock units. Fix the TOP gate clock names and include "CMU" in
> their name.
>
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>

[...]

Thanks for spotting this inconsistency on the cmu_top gates and fixing it!

Reviewed-by: Peter Griffin <peter.griffin at linaro.org>


From krzysztof.kozlowski at linaro.org  Thu Dec 14 08:07:27 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 17:07:27 +0100
Subject: [PATCH 01/11] dt-bindings: display: rockchip,inno-hdmi: Document
 RK3128 compatible
In-Reply-To: <288857ab-bebd-4f80-9cdc-9b04fa6c7386@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-2-knaerzche@gmail.com>
 <c4e394c6-c21f-4102-8c3a-f9530c0ca547@linaro.org>
 <288857ab-bebd-4f80-9cdc-9b04fa6c7386@gmail.com>
Message-ID: <df84a0cc-cb38-431f-864b-012ada7bb0d5@linaro.org>

On 14/12/2023 16:22, Alex Bee wrote:
> 
> Am 14.12.23 um 08:53 schrieb Krzysztof Kozlowski:
>> On 13/12/2023 20:51, Alex Bee wrote:
>>> Document the compatible for RK3128's HDMI controller block.
>>> The integration for this SoC is somewhat different here: It needs the PHY's
>> Please wrap commit message according to Linux coding style / submission
>> process (neither too early nor over the limit):
>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
> OK. Not sure why checkpatch --strict? didn't tell me that I'm over the 
> limit here.
>>
>>> reference clock rate to calculate the ddc bus frequency correctly. This
>>> clock is part of a power-domain (PD_VIO), so this gets added as an optional
>>> property too.
>> If clock is part of power domain, then the power domain must be in the
>> clock controller, not here. So either you put power domain in wrong
>> place or you used incorrect reason for a change.
>  ?Rockchip defines it's powerdomains per clock and I was little to much 
> in that world when writing this. Actually the controller itself is part 
> of the powerdomain. Will rephrase.

Does it mean you have like 200 different power domains in one SoC? Then
how are they different than clock if there is one-to-one mapping?

>>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>>> ---
>>>   .../display/rockchip/rockchip,inno-hdmi.yaml  | 30 +++++++++++++++++--
>>>   1 file changed, 28 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
>>> index 96889c86849a..9f00abcbfb38 100644
>>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
>>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
>>> @@ -14,6 +14,7 @@ properties:
>>>     compatible:
>>>       enum:
>>>         - rockchip,rk3036-inno-hdmi
>>> +      - rockchip,rk3128-inno-hdmi
>>>   
>>>     reg:
>>>       maxItems: 1
>>> @@ -22,10 +23,21 @@ properties:
>>>       maxItems: 1
>>>   
>>>     clocks:
>>> -    maxItems: 1
>>> +    minItems: 1
>>> +    items:
>>> +      - description: The HDMI controller main clock
>>> +      - description: The HDMI PHY reference clock
>>>   
>>>     clock-names:
>>> -    const: pclk
>>> +    minItems: 1
>>> +    items:
>>> +      - const: pclk
>>> +      - enum:
>>> +          - pclk
>>> +          - ref
>> That's way overcomplicated. Just items listing the names and minItems:
>> 1. See other bindings how this is done.
> OK.
>>> +
>>> +  power-domains:
>>> +    maxItems: 1
>> Is it relevant to existing device?
> 
> Will move to new variant only.
> 

Definition should be here, but in if:then: it should be disallowed
(:false) for other variants.

Best regards,
Krzysztof



From semen.protsenko at linaro.org  Thu Dec 14 08:09:42 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 10:09:42 -0600
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock
 as critical
In-Reply-To: <f3d61c49-1a46-476c-b7a5-6cc6a06a33ed@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-8-tudor.ambarus@linaro.org> <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>
 <f3d61c49-1a46-476c-b7a5-6cc6a06a33ed@linaro.org>
Message-ID: <CAPLW+4=tyr8Pcoe6Wm0Wtmkk4udDpuAiOKy7+C+Fwa6mvt3VoQ@mail.gmail.com>

On Thu, Dec 14, 2023 at 10:01?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
>
>
> On 12/14/23 15:37, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>
> >> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >> which then makes the system hang. To prevent this, mark
> >> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >> accordingly when tested.
> >>
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> >> ---
> >>  drivers/clk/samsung/clk-gs101.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >> index 3d194520b05e..08d80fca9cd6 100644
> >> --- a/drivers/clk/samsung/clk-gs101.c
> >> +++ b/drivers/clk/samsung/clk-gs101.c
> >> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>              "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>              21, 0, 0),
> >>         GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >> -            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >> +            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >
> > This clock doesn't seem like a leaf clock. It's also not a bus clock.
> > Leaving it always running makes the whole PERIC0 CMU clocked, which
> > usually should be avoided. Is it possible that the system freezes
> > because some other clock (which depends on peric0_ip) gets disabled as
> > a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> > is not implemented yet in the clock driver? Just looks weird to me
> > that the system hangs because of CMU IP clock disablement. It's
> > usually something much more specific.
>
> The system hang happened when I tested USI8 in I2C configuration with an
> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> disablement which makes the system hang. Either marking the CMU_TOP gate
> clock as critical (as I did in this patch) or marking the leaf PERIC0
> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>

Did you already implement 100% of clocks in CMU_PERIC0? If no, there
is a chance some other leaf clock (which is not implemented yet in
your driver) gets disabled as a result of PERIC0_IP disablement, which
might actually lead to that hang you observe. Usually it's some
meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
and the corresponding comments I left there, maybe it'll give you more
particular idea about what to look for. Yes, making the whole CMU
always running without understanding why (i.e. because of which
particular leaf clock) might not be the best way of handling this
issue. I might be mistaken, but at least please check if you
implemented all clocks for PERIC0 first and if making some meaningful
leaf clock critical makes more sense.

> Thanks,
> ta
> >
> >>         GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
> >>              "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
> >>              21, 0, 0),
> >> --
> >> 2.43.0.472.g3155946c3a-goog
> >>


From alexandre.torgue at foss.st.com  Thu Dec 14 08:14:30 2023
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 14 Dec 2023 17:14:30 +0100
Subject: [PATCH] ARM: dts: stm32mp15x: Consolidate usbh_[eo]hci phy
 properties
In-Reply-To: <20231206084853.q4dfbp5twpe235se@pengutronix.de>
References: <20231206083142.1476340-2-u.kleine-koenig@pengutronix.de>
 <20231206084853.q4dfbp5twpe235se@pengutronix.de>
Message-ID: <31a82fc0-814e-456d-83e2-a4daf111a648@foss.st.com>

Hi Uwe

On 12/6/23 09:48, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Wed, Dec 06, 2023 at 09:31:43AM +0100, Uwe Kleine-K?nig wrote:
>> diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
>> index 511113f2e399..704c0d0cfe5f 100644
>> --- a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
>> +++ b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
>> @@ -680,8 +680,6 @@ &usart3 {
>>   };
>>   
>>   &usbh_ehci {
>> -	phys = <&usbphyc_port0>;
>> -	status = "okay";
> 
> the status property must be kept. I will wait a bit for further review
> and then resend (unless this patch is picked up with this issue fixed
> up).

Applied with the fix. First I had a small doubt about the patch as we 
can also choose usbphyc_port1 for USB host but as usbphyc_port0 remains 
always connected to the USB host then your patch makes completely sens.

Regards
Alex


> Best regards
> Uwe
> 


From tudor.ambarus at linaro.org  Thu Dec 14 08:15:37 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 14 Dec 2023 16:15:37 +0000
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock
 as critical
In-Reply-To: <CAPLW+4=tyr8Pcoe6Wm0Wtmkk4udDpuAiOKy7+C+Fwa6mvt3VoQ@mail.gmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-8-tudor.ambarus@linaro.org>
 <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>
 <f3d61c49-1a46-476c-b7a5-6cc6a06a33ed@linaro.org>
 <CAPLW+4=tyr8Pcoe6Wm0Wtmkk4udDpuAiOKy7+C+Fwa6mvt3VoQ@mail.gmail.com>
Message-ID: <5de5cddd-2bab-4408-b31f-f48bef98f14c@linaro.org>



On 12/14/23 16:09, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 10:01?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>
>>
>>
>> On 12/14/23 15:37, Sam Protsenko wrote:
>>> On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>>>
>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>>>> which then makes the system hang. To prevent this, mark
>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>>>> accordingly when tested.
>>>>
>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>>>> ---
>>>>  drivers/clk/samsung/clk-gs101.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>>>> index 3d194520b05e..08d80fca9cd6 100644
>>>> --- a/drivers/clk/samsung/clk-gs101.c
>>>> +++ b/drivers/clk/samsung/clk-gs101.c
>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>>>              "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>>>              21, 0, 0),
>>>>         GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>>>> -            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>>>> +            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>>>
>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
>>> usually should be avoided. Is it possible that the system freezes
>>> because some other clock (which depends on peric0_ip) gets disabled as
>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
>>> is not implemented yet in the clock driver? Just looks weird to me
>>> that the system hangs because of CMU IP clock disablement. It's
>>> usually something much more specific.
>>
>> The system hang happened when I tested USI8 in I2C configuration with an
>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
>> disablement which makes the system hang. Either marking the CMU_TOP gate
>> clock as critical (as I did in this patch) or marking the leaf PERIC0
>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>>
> 
> Did you already implement 100% of clocks in CMU_PERIC0? If no, there

yes.

> is a chance some other leaf clock (which is not implemented yet in
> your driver) gets disabled as a result of PERIC0_IP disablement, which
> might actually lead to that hang you observe. Usually it's some
> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> and the corresponding comments I left there, maybe it'll give you more
> particular idea about what to look for. Yes, making the whole CMU
> always running without understanding why (i.e. because of which
> particular leaf clock) might not be the best way of handling this

because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK

> issue. I might be mistaken, but at least please check if you
> implemented all clocks for PERIC0 first and if making some meaningful
> leaf clock critical makes more sense.
> 

Thanks,
ta


From josef at toxicpanda.com  Thu Dec 14 08:18:50 2023
From: josef at toxicpanda.com (Josef Bacik)
Date: Thu, 14 Dec 2023 11:18:50 -0500
Subject: [PATCH] arm64: properly install vmlinuz.efi
Message-ID: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>

If you select CONFIG_EFI_ZBOOT, we will generate vmlinuz.efi, and then
when we go to install the kernel we'll install the vmlinux instead
because install.sh only recognizes Image.gz as wanting the compressed
install image.  With CONFIG_EFI_ZBOOT we don't get the proper kernel
installed, which means it doesn't boot, which makes for a very confused
and subsequently angry kernel developer.

Fix this by properly installing our compressed kernel if we've enabled
CONFIG_EFI_ZBOOT.

Signed-off-by: Josef Bacik <josef at toxicpanda.com>
---
 arch/arm64/boot/install.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
index 7399d706967a..9b7a09808a3d 100755
--- a/arch/arm64/boot/install.sh
+++ b/arch/arm64/boot/install.sh
@@ -17,7 +17,8 @@
 #   $3 - kernel map file
 #   $4 - default install path (blank if root directory)
 
-if [ "$(basename $2)" = "Image.gz" ]; then
+if [ "$(basename $2)" = "Image.gz" ] || [ "$(basename $2)" = "vmlinuz.efi" ]
+then
 # Compressed install
   echo "Installing compressed kernel"
   base=vmlinuz
-- 
2.43.0



From heiko at sntech.de  Thu Dec 14 08:20:04 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Thu, 14 Dec 2023 17:20:04 +0100
Subject: [PATCH 01/11] dt-bindings: display: rockchip,inno-hdmi: Document RK3128
 compatible
In-Reply-To: <df84a0cc-cb38-431f-864b-012ada7bb0d5@linaro.org>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <288857ab-bebd-4f80-9cdc-9b04fa6c7386@gmail.com>
 <df84a0cc-cb38-431f-864b-012ada7bb0d5@linaro.org>
Message-ID: <2221612.3VsfAaAtOV@diego>

Am Donnerstag, 14. Dezember 2023, 17:07:27 CET schrieb Krzysztof Kozlowski:
> On 14/12/2023 16:22, Alex Bee wrote:
> > 
> > Am 14.12.23 um 08:53 schrieb Krzysztof Kozlowski:
> >> On 13/12/2023 20:51, Alex Bee wrote:
> >>> Document the compatible for RK3128's HDMI controller block.
> >>> The integration for this SoC is somewhat different here: It needs the PHY's
> >> Please wrap commit message according to Linux coding style / submission
> >> process (neither too early nor over the limit):
> >> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
> > OK. Not sure why checkpatch --strict  didn't tell me that I'm over the 
> > limit here.
> >>
> >>> reference clock rate to calculate the ddc bus frequency correctly. This
> >>> clock is part of a power-domain (PD_VIO), so this gets added as an optional
> >>> property too.
> >> If clock is part of power domain, then the power domain must be in the
> >> clock controller, not here. So either you put power domain in wrong
> >> place or you used incorrect reason for a change.
> >   Rockchip defines it's powerdomains per clock and I was little to much 
> > in that world when writing this. Actually the controller itself is part 
> > of the powerdomain. Will rephrase.
> 
> Does it mean you have like 200 different power domains in one SoC? Then
> how are they different than clock if there is one-to-one mapping?

It's more like the other way around. Controllers and their clocks belong
to specific power-domains. So there are of course more clocks than domains.






From joao.m.martins at oracle.com  Thu Dec 14 08:23:33 2023
From: joao.m.martins at oracle.com (Joao Martins)
Date: Thu, 14 Dec 2023 16:23:33 +0000
Subject: [PATCH 4/5] iommu/arm-smmu-v3: Add set_dirty_tracking() support
In-Reply-To: <20231130125412.GH1389974@nvidia.com>
References: <20231128094940.1344-1-shameerali.kolothum.thodi@huawei.com>
 <20231128094940.1344-5-shameerali.kolothum.thodi@huawei.com>
 <20231129194235.GC436702@nvidia.com>
 <d80cd067b57345609a198aac5780e6af@huawei.com>
 <20231130125412.GH1389974@nvidia.com>
Message-ID: <c9354a08-6aa5-42db-b8b5-44496eefb76f@oracle.com>

On 30/11/2023 12:54, Jason Gunthorpe wrote:
> On Thu, Nov 30, 2023 at 08:56:32AM +0000, Shameerali Kolothum Thodi wrote:
>>> On Tue, Nov 28, 2023 at 09:49:39AM +0000, Shameer Kolothum wrote:
>>>> From: Joao Martins <joao.m.martins at oracle.com>
>>>>
>>>> Dirty tracking will always be enabled with DBM=1 modifier enabled
>>>> by default when HD is supported.
>>>
>>> Is this trying to say that ARM doesn't have a per-table global enable
>>> for dirty tracking but instead pre-sets the DBM bit to avoid the cost?
>>>
>>
>> Yes. SMMUv3 has per-PTE DBM control and I think the initial RFC had
>> it walking the PTEs and setting the DBM on set_dirty_tracking().
> 
> set_dirty_tracking doesn't have access to the necessary locking to
> touch the PTEs.
> 
This is done for free by iopt_clear_dirty_data().

set_dirty_tracking() is mostly a nop, under the assumption that dirty
tracking is always enabled.

>>> So on smmuv3 to enable we have to clear everything and disable
>>> continues to pay a penalty since we don't go and mark all things as
>>> dirty again?
>>
>> Yes we clear everything on enable. Sorry I didn't get the second part.
>> We don't mark dirty on disable. How is that different from Intel/AMD?
> 
> Intel/AMD have a global switch so they just turn off the tracking and
> stop paying the cost.
> 
> This approach on ARM means once the tracking is logically turned off
> the HW will continue to generate memory traffic to set dirty bits on
> DMAs. There is no way to back to the at-start state where their is 0
> memory traffic on DMAs. Not sure that it totally matters, but it is
> worth noting someplace.
> 
> If we do want to solve this then ARM would need iommufd to make a pass
> over the page table to set for disable similar to how we have to clear
> for enable.

The firsts attempt at this had to be dynamic[0].

Like set_dirty_tracking_range would pass over the io pagetable and set the DBM
bit to enable dirty tracking. It was suggested that we switch to an always-on
mode to simplify initial bringup of the feature, and if the always-on was
somehow affecting DMA performance, we would re-attempt at this dynamic mode
post-mortem.

With the current code structure, perhaps having set_dirty_tracking() do the
DBM-enable pass we would need to move iorw_sem section to include the call to
set_dirty_tracking() and smmu op set_dirty_tracking() op would walk the whole
pt, without relying on iopt areas. Or we go back to iterating areas similar to
[0] with a new op.

[0] https://lore.kernel.org/kvm/20220428210933.3583-16-joao.m.martins at oracle.com/


From krzysztof.kozlowski at linaro.org  Thu Dec 14 08:26:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 14 Dec 2023 17:26:32 +0100
Subject: [PATCH 01/11] dt-bindings: display: rockchip,inno-hdmi: Document
 RK3128 compatible
In-Reply-To: <2221612.3VsfAaAtOV@diego>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <288857ab-bebd-4f80-9cdc-9b04fa6c7386@gmail.com>
 <df84a0cc-cb38-431f-864b-012ada7bb0d5@linaro.org> <2221612.3VsfAaAtOV@diego>
Message-ID: <6df9fb93-85cf-4c03-b0cd-781d4f42db30@linaro.org>

On 14/12/2023 17:20, Heiko St?bner wrote:
> Am Donnerstag, 14. Dezember 2023, 17:07:27 CET schrieb Krzysztof Kozlowski:
>> On 14/12/2023 16:22, Alex Bee wrote:
>>>
>>> Am 14.12.23 um 08:53 schrieb Krzysztof Kozlowski:
>>>> On 13/12/2023 20:51, Alex Bee wrote:
>>>>> Document the compatible for RK3128's HDMI controller block.
>>>>> The integration for this SoC is somewhat different here: It needs the PHY's
>>>> Please wrap commit message according to Linux coding style / submission
>>>> process (neither too early nor over the limit):
>>>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>>> OK. Not sure why checkpatch --strict  didn't tell me that I'm over the 
>>> limit here.
>>>>
>>>>> reference clock rate to calculate the ddc bus frequency correctly. This
>>>>> clock is part of a power-domain (PD_VIO), so this gets added as an optional
>>>>> property too.
>>>> If clock is part of power domain, then the power domain must be in the
>>>> clock controller, not here. So either you put power domain in wrong
>>>> place or you used incorrect reason for a change.
>>>   Rockchip defines it's powerdomains per clock and I was little to much 
>>> in that world when writing this. Actually the controller itself is part 
>>> of the powerdomain. Will rephrase.
>>
>> Does it mean you have like 200 different power domains in one SoC? Then
>> how are they different than clock if there is one-to-one mapping?
> 
> It's more like the other way around. Controllers and their clocks belong
> to specific power-domains. So there are of course more clocks than domains.

That's fine and expected. Here the comment was suggested that you need
to add power-domain because clock is in power-domain. That would be
clearly wrong and instead the clock controller should model the power
domain relationship.
> 
> 
> 
> 

Best regards,
Krzysztof



From jernej.skrabec at gmail.com  Thu Dec 14 08:28:55 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Thu, 14 Dec 2023 17:28:55 +0100
Subject: [PATCH v2 3/3] arm64: dts: allwinner: h618: add Transpeed 8K618-T TV box
In-Reply-To: <20231214015312.17363-4-andre.przywara@arm.com>
References: <20231214015312.17363-1-andre.przywara@arm.com>
 <20231214015312.17363-4-andre.przywara@arm.com>
Message-ID: <5897240.MhkbZ0Pkbq@archlinux>

On Thursday, December 14, 2023 2:53:12 AM CET Andre Przywara wrote:
> This is a Chinese TV box, probably very similar if not identical to
> various other cheap TV boxes with the same specs:
>       - Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache)
>       - 2 or 4GiB DDR3L DRAM
>       - 32, 64, or 128 GiB eMMC flash
>       - AXP313a PMIC
>       - 100 Mbit/s Ethernet (using yet unsupported internal PHY)
>       - HDMI port
>       - 2 * USB 2.0 ports
>       - microSD card slot
>       - 3.5mm A/V port
>       - 7-segment display
>       - 5V barrel plug power supply
> 
> The PCB provides holes for soldering a UART header or cable, this is
> connected to the debug UART0. UART1 is used for the Bluetooth chip,
> although this isn't working yet.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>

Best regards,
Jernej




From alexandre.torgue at foss.st.com  Thu Dec 14 08:28:40 2023
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 14 Dec 2023 17:28:40 +0100
Subject: [PATCH 0/4] stm32: add support for STM32MP25 BSEC to control OTP
 data
In-Reply-To: <20231117143338.1173475-1-patrick.delaunay@foss.st.com>
References: <20231117143338.1173475-1-patrick.delaunay@foss.st.com>
Message-ID: <0145e75a-0d4c-4e34-a247-7852796f0552@foss.st.com>

Hi

On 11/17/23 15:33, Patrick Delaunay wrote:
> 
> Non volatile memory area is available on STM32MP25 with OTP in BSEC.
> 
> The 12 Kbits of OTP (effective) for STM32MP25x SoC Family
> are organized into the following regions:
> - lower OTP (OTP0 to OTP127) = 4096 lower OTP bits,
>    bitwise (1-bit) programmable
> - mid OTP (OTP128 to OTP255) = 4096 middle OTP bits,
>    bulk (32-bit) programmable
> - upper OTP (OTP256 to OTP383) = 4096 upper OTP bits,
>    bulk (32-bit) programmable,
>    only accessible when BSEC is in closed state.
> 
> BSEC is only accessible by secure world, so the OTP access is done
> by driver with OP-TEE TA, as on STM32MP13x family.
> 
> 
> 
> Patrick Delaunay (4):
>    dt-bindings: nvmem: add new stm32mp25 compatible for stm32-romem
>    nvmem: stm32: add support for STM32MP25 BSEC to control OTP data
>    arm64: defconfig: enable NVMEM STM32 ROMEM for stm32mp25
>    nvmem: add bsec support to stm32mp25
> 
>   .../bindings/nvmem/st,stm32-romem.yaml           |  1 +
>   arch/arm64/boot/dts/st/stm32mp251.dtsi           | 16 ++++++++++++++++
>   arch/arm64/configs/defconfig                     |  1 +
>   drivers/nvmem/stm32-romem.c                      | 16 ++++++++++++++++
>   4 files changed, 34 insertions(+)
> 


patch[4] (DT) applied on stm32-next.

thanks
Alex


From jernej.skrabec at gmail.com  Thu Dec 14 08:29:30 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Thu, 14 Dec 2023 17:29:30 +0100
Subject: [PATCH 2/5] cpufreq: sun50i: Add D1 support
In-Reply-To: <20231214103342.30775-3-fusibrandon13@gmail.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
 <20231214103342.30775-3-fusibrandon13@gmail.com>
Message-ID: <8351928.NyiUUSuA9g@archlinux>

On Thursday, December 14, 2023 11:33:39 AM CET Brandon Cheo Fusi wrote:
> Add support for D1 based devices to the Allwinner H6 cpufreq
> driver
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> index 32a9c88f8..ccf83780f 100644
> --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> @@ -160,6 +160,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
>  
>  static const struct of_device_id sun50i_cpufreq_match_list[] = {
>  	{ .compatible = "allwinner,sun50i-h6" },
> +	{ .compatible = "allwinner,sun20i-d1" },

This is not needed, as there is no functionality change.

Best regards,
Jernej

>  	{}
>  };
>  MODULE_DEVICE_TABLE(of, sun50i_cpufreq_match_list);
> 






From joao.m.martins at oracle.com  Thu Dec 14 08:29:03 2023
From: joao.m.martins at oracle.com (Joao Martins)
Date: Thu, 14 Dec 2023 16:29:03 +0000
Subject: [PATCH 5/5] iommu/arm-smmu-v3: Enforce dirty tracking in domain
 attach/alloc
In-Reply-To: <20231128094940.1344-6-shameerali.kolothum.thodi@huawei.com>
References: <20231128094940.1344-1-shameerali.kolothum.thodi@huawei.com>
 <20231128094940.1344-6-shameerali.kolothum.thodi@huawei.com>
Message-ID: <b2911a1a-9dc1-477c-b003-cb078563f08e@oracle.com>

On 28/11/2023 09:49, Shameer Kolothum wrote:
> From: Joao Martins <joao.m.martins at oracle.com>
> 
> SMMUv3 implements all requirements of revoking device
> attachment if smmu does not support dirty tracking.
> 
> Finally handle the IOMMU_CAP_DIRTY in iommu_capable for
> IOMMUFD_DEVICE_GET_HW_INFO.
> 
> Signed-off-by: Joao Martins <joao.m.martins at oracle.com>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
> ---
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 22 ++++++++++++++++++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index c5eabdc29ba5..2c100f2136bc 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2244,6 +2244,8 @@ static bool arm_smmu_capable(struct device *dev, enum iommu_cap cap)
>  	case IOMMU_CAP_NOEXEC:
>  	case IOMMU_CAP_DEFERRED_FLUSH:
>  		return true;
> +	case IOMMU_CAP_DIRTY_TRACKING:
> +		return arm_smmu_dbm_capable(master->smmu);
>  	default:
>  		return false;
>  	}
> @@ -2701,6 +2703,9 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
>  	master = dev_iommu_priv_get(dev);
>  	smmu = master->smmu;
>  
> +	if (domain->dirty_ops && !arm_smmu_dbm_capable(smmu))
> +		return -EINVAL;
> +
>  	mutex_lock(&smmu_domain->init_mutex);
>  
>  	if (!smmu_domain->smmu) {
> @@ -3077,7 +3082,9 @@ arm_smmu_domain_alloc_user(struct device *dev, u32 flags,
>  			   const struct iommu_user_data *user_data)
>  {
>  	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> -	const u32 paging_flags = IOMMU_HWPT_ALLOC_NEST_PARENT;
> +	const u32 paging_flags = IOMMU_HWPT_ALLOC_NEST_PARENT |
> +				 IOMMU_HWPT_ALLOC_DIRTY_TRACKING;
> +	bool enforce_dirty = flags & IOMMU_HWPT_ALLOC_DIRTY_TRACKING;
>  	struct arm_smmu_domain *smmu_domain;
>  	int ret;
>  
> @@ -3090,6 +3097,10 @@ arm_smmu_domain_alloc_user(struct device *dev, u32 flags,
>  	if (user_data)
>  		return ERR_PTR(-EINVAL);
>  
> +	if (enforce_dirty &&
> +	    !device_iommu_capable(dev, IOMMU_CAP_DIRTY_TRACKING))
> +		return ERR_PTR(-EOPNOTSUPP);
> +
>  	smmu_domain = arm_smmu_domain_alloc();
>  	if (!smmu_domain)
>  		return ERR_PTR(-ENOMEM);
> @@ -3104,6 +3115,9 @@ arm_smmu_domain_alloc_user(struct device *dev, u32 flags,
>  
>  	smmu_domain->domain.type = IOMMU_DOMAIN_UNMANAGED;
>  	smmu_domain->domain.ops = arm_smmu_ops.default_domain_ops;
> +	if (enforce_dirty)
> +		smmu_domain->domain.dirty_ops = &arm_smmu_dirty_ops;
> +
>  	ret = arm_smmu_domain_finalise(smmu_domain, master->smmu);
>  	if (ret)
>  		goto err_free;

Perhaps it would be better to limit the blast radius of the always-on mode, to
just enable it in the context descriptor depending on passing the
HWPT_ALLOC_DIRTY_TRACKING flag instead of enabling for everybody.
Something like this in arm_smmu_domain_finalise():

	if (arm_smmu_dbm_capable(smmu) && smmu_domain->domain.dirty_ops &&
	    smmu_domain->stage == ARM_SMMU_DOMAIN_S1)
		pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_ARM_HD;


For bisectability perhaps the second patch of this series should be the last,
while bringing the implementation of arm_smmu_dbm_capable() to this patch.


From jernej.skrabec at gmail.com  Thu Dec 14 08:30:15 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Thu, 14 Dec 2023 17:30:15 +0100
Subject: [PATCH 3/5] cpufreq: dt-platdev: Blocklist allwinner,sun20i-d1 SoC
In-Reply-To: <20231214103342.30775-4-fusibrandon13@gmail.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
 <20231214103342.30775-4-fusibrandon13@gmail.com>
Message-ID: <3459481.QJadu78ljV@archlinux>

On Thursday, December 14, 2023 11:33:40 AM CET Brandon Cheo Fusi wrote:
> The Allwinner D1 uses H6 cpufreq driver. Add it to blocklist
> so the "cpufreq-dt" device is not created twice.
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index bd1e1357c..2febcfc2c 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -104,6 +104,7 @@ static const struct of_device_id allowlist[] __initconst = {
>   */
>  static const struct of_device_id blocklist[] __initconst = {
>  	{ .compatible = "allwinner,sun50i-h6", },
> +	{ .compatible = "allwinner,sun20i-d1", },

This should not be needed since you're using H6 variant for a fallback.

Best regards,
Jernej

>  
>  	{ .compatible = "apple,arm-platform", },
>  
> 






From robin.murphy at arm.com  Thu Dec 14 08:31:03 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 14 Dec 2023 16:31:03 +0000
Subject: [PATCH v2 0/5] perf/arm_cspmu: Add devicetree support
Message-ID: <cover.1702571292.git.robin.murphy@arm.com>

v1: https://lore.kernel.org/linux-arm-kernel/cover.1701793996.git.robin.murphy at arm.com/

Hi all, here's v2, with tweaks to the binding per Rob's comments,
and fixing patch #5 to hopefully not break ACPI this time.

Thanks,
Robin.


Robin Murphy (5):
  perf/arm_cspmu: Simplify initialisation
  perf/arm_cspmu: Simplify attribute groups
  perf/arm_cspmu: Simplify counter reset
  dt-bindings/perf: Add Arm CoreSight PMU
  perf/arm_cspmu: Add devicetree support

 .../bindings/perf/arm,coresight-pmu.yaml      |  39 +++++
 drivers/perf/arm_cspmu/arm_cspmu.c            | 149 ++++++++++--------
 drivers/perf/arm_cspmu/arm_cspmu.h            |   1 +
 drivers/perf/arm_cspmu/nvidia_cspmu.c         |   6 -
 4 files changed, 123 insertions(+), 72 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml

-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Thu Dec 14 08:31:04 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 14 Dec 2023 16:31:04 +0000
Subject: [PATCH v2 1/5] perf/arm_cspmu: Simplify initialisation
In-Reply-To: <cover.1702571292.git.robin.murphy@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
Message-ID: <4c23120f3ce1b267fb565f1f9541f9f5026f89ed.1702571292.git.robin.murphy@arm.com>

It's far simpler for implementations to literally override whichever
default ops they want to, by initialising to the default ops first. This
saves all the bother of checking what the impl_init_ops call has or
hasn't touched. Make the same clear distinction for the PMIIDR override
as well, in case we gain more sources for overriding that in future.

Reviewed-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/perf/arm_cspmu/arm_cspmu.c    | 55 +++++++++++----------------
 drivers/perf/arm_cspmu/nvidia_cspmu.c |  6 ---
 2 files changed, 22 insertions(+), 39 deletions(-)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index 2cc35dded007..a3347b1287e6 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -100,13 +100,6 @@
 #define ARM_CSPMU_ACTIVE_CPU_MASK		0x0
 #define ARM_CSPMU_ASSOCIATED_CPU_MASK		0x1
 
-/* Check and use default if implementer doesn't provide attribute callback */
-#define CHECK_DEFAULT_IMPL_OPS(ops, callback)			\
-	do {							\
-		if (!ops->callback)				\
-			ops->callback = arm_cspmu_ ## callback;	\
-	} while (0)
-
 /*
  * Maximum poll count for reading counter value using high-low-high sequence.
  */
@@ -408,21 +401,32 @@ static struct arm_cspmu_impl_match *arm_cspmu_impl_match_get(u32 pmiidr)
 	return NULL;
 }
 
+#define DEFAULT_IMPL_OP(name)	.name = arm_cspmu_##name
+
 static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
 {
 	int ret = 0;
-	struct arm_cspmu_impl_ops *impl_ops = &cspmu->impl.ops;
 	struct acpi_apmt_node *apmt_node = arm_cspmu_apmt_node(cspmu->dev);
 	struct arm_cspmu_impl_match *match;
 
-	/*
-	 * Get PMU implementer and product id from APMT node.
-	 * If APMT node doesn't have implementer/product id, try get it
-	 * from PMIIDR.
-	 */
-	cspmu->impl.pmiidr =
-		(apmt_node->impl_id) ? apmt_node->impl_id :
-				       readl(cspmu->base0 + PMIIDR);
+	/* Start with a default PMU implementation */
+	cspmu->impl.module = THIS_MODULE;
+	cspmu->impl.pmiidr = readl(cspmu->base0 + PMIIDR);
+	cspmu->impl.ops = (struct arm_cspmu_impl_ops) {
+		DEFAULT_IMPL_OP(get_event_attrs),
+		DEFAULT_IMPL_OP(get_format_attrs),
+		DEFAULT_IMPL_OP(get_identifier),
+		DEFAULT_IMPL_OP(get_name),
+		DEFAULT_IMPL_OP(is_cycle_counter_event),
+		DEFAULT_IMPL_OP(event_type),
+		DEFAULT_IMPL_OP(event_filter),
+		DEFAULT_IMPL_OP(set_ev_filter),
+		DEFAULT_IMPL_OP(event_attr_is_visible),
+	};
+
+	/* Firmware may override implementer/product ID from PMIIDR */
+	if (apmt_node->impl_id)
+		cspmu->impl.pmiidr = apmt_node->impl_id;
 
 	/* Find implementer specific attribute ops. */
 	match = arm_cspmu_impl_match_get(cspmu->impl.pmiidr);
@@ -450,24 +454,9 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
 		}
 
 		mutex_unlock(&arm_cspmu_lock);
+	}
 
-		if (ret)
-			return ret;
-	} else
-		cspmu->impl.module = THIS_MODULE;
-
-	/* Use default callbacks if implementer doesn't provide one. */
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_event_attrs);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_format_attrs);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_identifier);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, get_name);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, is_cycle_counter_event);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, event_type);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, event_filter);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, event_attr_is_visible);
-	CHECK_DEFAULT_IMPL_OPS(impl_ops, set_ev_filter);
-
-	return 0;
+	return ret;
 }
 
 static struct attribute_group *
diff --git a/drivers/perf/arm_cspmu/nvidia_cspmu.c b/drivers/perf/arm_cspmu/nvidia_cspmu.c
index 0382b702f092..5b84b701ad62 100644
--- a/drivers/perf/arm_cspmu/nvidia_cspmu.c
+++ b/drivers/perf/arm_cspmu/nvidia_cspmu.c
@@ -388,12 +388,6 @@ static int nv_cspmu_init_ops(struct arm_cspmu *cspmu)
 	impl_ops->get_format_attrs		= nv_cspmu_get_format_attrs;
 	impl_ops->get_name			= nv_cspmu_get_name;
 
-	/* Set others to NULL to use default callback. */
-	impl_ops->event_type			= NULL;
-	impl_ops->event_attr_is_visible		= NULL;
-	impl_ops->get_identifier		= NULL;
-	impl_ops->is_cycle_counter_event	= NULL;
-
 	return 0;
 }
 
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Thu Dec 14 08:31:05 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 14 Dec 2023 16:31:05 +0000
Subject: [PATCH v2 2/5] perf/arm_cspmu: Simplify attribute groups
In-Reply-To: <cover.1702571292.git.robin.murphy@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
Message-ID: <1b02b2a40fda2216b9aef5169d73eaa944ef54f8.1702571292.git.robin.murphy@arm.com>

The attribute group array itself is always the same, so there's no
need to allocate it separately. Storing it directly in our instance
data saves memory and gives us one less point of failure.

Reviewed-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/perf/arm_cspmu/arm_cspmu.c | 26 +++++++++-----------------
 drivers/perf/arm_cspmu/arm_cspmu.h |  1 +
 2 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index a3347b1287e6..f7aa2ac5fd88 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -501,23 +501,16 @@ arm_cspmu_alloc_format_attr_group(struct arm_cspmu *cspmu)
 	return format_group;
 }
 
-static struct attribute_group **
-arm_cspmu_alloc_attr_group(struct arm_cspmu *cspmu)
+static int arm_cspmu_alloc_attr_groups(struct arm_cspmu *cspmu)
 {
-	struct attribute_group **attr_groups = NULL;
-	struct device *dev = cspmu->dev;
+	const struct attribute_group **attr_groups = cspmu->attr_groups;
 	const struct arm_cspmu_impl_ops *impl_ops = &cspmu->impl.ops;
 
 	cspmu->identifier = impl_ops->get_identifier(cspmu);
 	cspmu->name = impl_ops->get_name(cspmu);
 
 	if (!cspmu->identifier || !cspmu->name)
-		return NULL;
-
-	attr_groups = devm_kcalloc(dev, 5, sizeof(struct attribute_group *),
-				   GFP_KERNEL);
-	if (!attr_groups)
-		return NULL;
+		return -ENOMEM;
 
 	attr_groups[0] = arm_cspmu_alloc_event_attr_group(cspmu);
 	attr_groups[1] = arm_cspmu_alloc_format_attr_group(cspmu);
@@ -525,9 +518,9 @@ arm_cspmu_alloc_attr_group(struct arm_cspmu *cspmu)
 	attr_groups[3] = &arm_cspmu_cpumask_attr_group;
 
 	if (!attr_groups[0] || !attr_groups[1])
-		return NULL;
+		return -ENOMEM;
 
-	return attr_groups;
+	return 0;
 }
 
 static inline void arm_cspmu_reset_counters(struct arm_cspmu *cspmu)
@@ -1166,11 +1159,10 @@ static int arm_cspmu_get_cpus(struct arm_cspmu *cspmu)
 static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
 {
 	int ret, capabilities;
-	struct attribute_group **attr_groups;
 
-	attr_groups = arm_cspmu_alloc_attr_group(cspmu);
-	if (!attr_groups)
-		return -ENOMEM;
+	ret = arm_cspmu_alloc_attr_groups(cspmu);
+	if (ret)
+		return ret;
 
 	ret = cpuhp_state_add_instance(arm_cspmu_cpuhp_state,
 				       &cspmu->cpuhp_node);
@@ -1192,7 +1184,7 @@ static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
 		.start		= arm_cspmu_start,
 		.stop		= arm_cspmu_stop,
 		.read		= arm_cspmu_read,
-		.attr_groups	= (const struct attribute_group **)attr_groups,
+		.attr_groups	= cspmu->attr_groups,
 		.capabilities	= capabilities,
 	};
 
diff --git a/drivers/perf/arm_cspmu/arm_cspmu.h b/drivers/perf/arm_cspmu/arm_cspmu.h
index 2fe723555a6b..c9163acfe810 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.h
+++ b/drivers/perf/arm_cspmu/arm_cspmu.h
@@ -157,6 +157,7 @@ struct arm_cspmu {
 	int cycle_counter_logical_idx;
 
 	struct arm_cspmu_hw_events hw_events;
+	const struct attribute_group *attr_groups[5];
 
 	struct arm_cspmu_impl impl;
 };
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Thu Dec 14 08:31:06 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 14 Dec 2023 16:31:06 +0000
Subject: [PATCH v2 3/5] perf/arm_cspmu: Simplify counter reset
In-Reply-To: <cover.1702571292.git.robin.murphy@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
Message-ID: <625b6a5cb808377b070680f8c99a17346b48a5b5.1702571292.git.robin.murphy@arm.com>

arm_cspmu_reset_counters() inherently also stops them since it is
writing 0 to PMCR.E, so there should be no need to do that twice.
Also tidy up the reset routine itself for consistency with the start
and stop routines, and to be clear at first glance that it is simply
writing a constant value.

Reviewed-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/perf/arm_cspmu/arm_cspmu.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index f7aa2ac5fd88..b64de4d800c7 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -525,11 +525,7 @@ static int arm_cspmu_alloc_attr_groups(struct arm_cspmu *cspmu)
 
 static inline void arm_cspmu_reset_counters(struct arm_cspmu *cspmu)
 {
-	u32 pmcr = 0;
-
-	pmcr |= PMCR_P;
-	pmcr |= PMCR_C;
-	writel(pmcr, cspmu->base0 + PMCR);
+	writel(PMCR_C | PMCR_P, cspmu->base0 + PMCR);
 }
 
 static inline void arm_cspmu_start_counters(struct arm_cspmu *cspmu)
@@ -1189,7 +1185,6 @@ static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
 	};
 
 	/* Hardware counter init */
-	arm_cspmu_stop_counters(cspmu);
 	arm_cspmu_reset_counters(cspmu);
 
 	ret = perf_pmu_register(&cspmu->pmu, cspmu->name, -1);
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Thu Dec 14 08:31:07 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 14 Dec 2023 16:31:07 +0000
Subject: [PATCH v2 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <cover.1702571292.git.robin.murphy@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
Message-ID: <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>

Add a binding for implementations of the Arm CoreSight Performance
Monitoring Unit Architecture. Not to be confused with CoreSight debug
and trace, the PMU architecture defines a standard MMIO interface for
event counters following a similar design to the CPU PMU architecture,
where the implementation and most of its features are discoverable
through ID registers.

CC: Rob Herring <robh+dt at kernel.org>
CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
CC: Conor Dooley <conor+dt at kernel.org>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
v2: Use reg-io-width instead of a new property; tweak descriptions
---
 .../bindings/perf/arm,coresight-pmu.yaml      | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml

diff --git a/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
new file mode 100644
index 000000000000..0fcc5bb610f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/arm,coresight-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Coresight Performance Monitoring Unit Architecture
+
+maintainers:
+  - Robin Murphy <robin.murphy at arm.com>
+
+properties:
+  compatible:
+    const: arm,coresight-pmu
+
+  reg:
+    items:
+      - description: Register page 0
+      - description: Register page 1, if the PMU implements the dual-page extension
+    minItems: 1
+
+  interrupts:
+    items:
+      - description: Overflow interrupt
+
+  cpus:
+    description: If the PMU is associated with a particular CPU or subset of CPUs, array of phandles to those CPUs
+
+  reg-io-width:
+    description: Granularity at which PMU register accesses are single-copy atomic
+    default: 4
+    enum: [4, 8]
+
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
-- 
2.39.2.101.g768bb238c484.dirty



From robin.murphy at arm.com  Thu Dec 14 08:31:08 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 14 Dec 2023 16:31:08 +0000
Subject: [PATCH v2 5/5] perf/arm_cspmu: Add devicetree support
In-Reply-To: <cover.1702571292.git.robin.murphy@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
Message-ID: <6858523689a214543224495fee22f9e31be2f767.1702571292.git.robin.murphy@arm.com>

Hook up devicetree probing support. For now let's hope that people
implement PMIIDR properly and we don't need an override property or
match data mechanism.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
v2: Use APMT node to distinguish ACPI; adjust for binding change
---
 drivers/perf/arm_cspmu/arm_cspmu.c | 63 ++++++++++++++++++++++++------
 1 file changed, 52 insertions(+), 11 deletions(-)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index b64de4d800c7..6c76c135a0cf 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -27,6 +27,7 @@
 #include <linux/io-64-nonatomic-lo-hi.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 #include <linux/perf_event.h>
 #include <linux/platform_device.h>
 
@@ -310,6 +311,10 @@ static const char *arm_cspmu_get_name(const struct arm_cspmu *cspmu)
 
 	dev = cspmu->dev;
 	apmt_node = arm_cspmu_apmt_node(dev);
+	if (!apmt_node)
+		return devm_kasprintf(dev, GFP_KERNEL, PMUNAME "_%u",
+				      atomic_fetch_inc(&pmu_idx[0]));
+
 	pmu_type = apmt_node->type;
 
 	if (pmu_type >= ACPI_APMT_NODE_TYPE_COUNT) {
@@ -425,7 +430,7 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
 	};
 
 	/* Firmware may override implementer/product ID from PMIIDR */
-	if (apmt_node->impl_id)
+	if (apmt_node && apmt_node->impl_id)
 		cspmu->impl.pmiidr = apmt_node->impl_id;
 
 	/* Find implementer specific attribute ops. */
@@ -940,7 +945,14 @@ static struct arm_cspmu *arm_cspmu_alloc(struct platform_device *pdev)
 	platform_set_drvdata(pdev, cspmu);
 
 	apmt_node = arm_cspmu_apmt_node(dev);
-	cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
+	if (apmt_node) {
+		cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
+	} else {
+		u32 width = 0;
+
+		device_property_read_u32(dev, "reg-io-width", &width);
+		cspmu->has_atomic_dword = (width == 8);
+	}
 
 	return cspmu;
 }
@@ -1133,11 +1145,6 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
 		}
 	}
 
-	if (cpumask_empty(&cspmu->associated_cpus)) {
-		dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
-		return -ENODEV;
-	}
-
 	return 0;
 }
 #else
@@ -1147,9 +1154,36 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
 }
 #endif
 
+static int arm_cspmu_of_get_cpus(struct arm_cspmu *cspmu)
+{
+	struct of_phandle_iterator it;
+	int ret, cpu;
+
+	of_for_each_phandle(&it, ret, dev_of_node(cspmu->dev), "cpus", NULL, 0) {
+		cpu = of_cpu_node_to_id(it.node);
+		if (cpu < 0)
+			continue;
+		cpumask_set_cpu(cpu, &cspmu->associated_cpus);
+	}
+	return ret;
+}
+
 static int arm_cspmu_get_cpus(struct arm_cspmu *cspmu)
 {
-	return arm_cspmu_acpi_get_cpus(cspmu);
+	int ret = 0;
+
+	if (arm_cspmu_apmt_node(cspmu->dev))
+		ret = arm_cspmu_acpi_get_cpus(cspmu);
+	else if (device_property_present(cspmu->dev, "cpus"))
+		ret = arm_cspmu_of_get_cpus(cspmu);
+	else
+		cpumask_copy(&cspmu->associated_cpus, cpu_possible_mask);
+
+	if (!ret && cpumask_empty(&cspmu->associated_cpus)) {
+		dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
+		ret = -ENODEV;
+	}
+	return ret;
 }
 
 static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
@@ -1246,11 +1280,18 @@ static const struct platform_device_id arm_cspmu_id[] = {
 };
 MODULE_DEVICE_TABLE(platform, arm_cspmu_id);
 
+static const struct of_device_id arm_cspmu_of_match[] = {
+	{ .compatible = "arm,coresight-pmu" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, arm_cspmu_of_match);
+
 static struct platform_driver arm_cspmu_driver = {
 	.driver = {
-			.name = DRVNAME,
-			.suppress_bind_attrs = true,
-		},
+		.name = DRVNAME,
+		.of_match_table = arm_cspmu_of_match,
+		.suppress_bind_attrs = true,
+	},
 	.probe = arm_cspmu_device_probe,
 	.remove = arm_cspmu_device_remove,
 	.id_table = arm_cspmu_id,
-- 
2.39.2.101.g768bb238c484.dirty



From ninad at linux.ibm.com  Thu Dec 14 08:30:55 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Thu, 14 Dec 2023 10:30:55 -0600
Subject: [PATCH v1 5/8] ARM: dts: aspeed: System1: Voltage regulators
In-Reply-To: <6a3d4551-66a2-411a-9d5f-cffb57ee0ce2@linaro.org>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-6-ninad@linux.ibm.com>
 <6a3d4551-66a2-411a-9d5f-cffb57ee0ce2@linaro.org>
Message-ID: <e1ec02cf-072b-4678-8986-336c1cb8ca92@linux.ibm.com>

Hello Krzysztof,

On 12/12/23 14:22, Krzysztof Kozlowski wrote:
> On 12/12/2023 17:40, Ninad Palsule wrote:
>> This commit adds different voltage regulators.
>>
>> Tested:
>>      This board is tested using the simics simulator.
>>
>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>> ---
>>   .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 266 ++++++++++++++++++
> Squash it.
Done.
>
>>   1 file changed, 266 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> index 0557bff9f36a..b8e7e52d4600 100644
>> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> @@ -114,10 +114,127 @@ vga_memory: region at bf000000 {
>>   		};
>>   	};
>>   
>> +	iio-hwmon {
>> +		compatible = "iio-hwmon";
>> +		io-channels = <&p12v_vd 0>, <&p5v_aux_vd 0>,
>> +			<&p5v_bmc_aux_vd 0>, <&p3v3_aux_vd 0>,
>> +			<&p3v3_bmc_aux_vd 0>, <&p1v8_bmc_aux_vd 0>,
>> +			<&adc1 4>, <&adc0 2>, <&adc1 0>,
>> +			<&p2V5_aux_vd 0>, <&adc1 7>;
>> +	};
>> +
>> +	p12v_vd: voltage_divider1 {
> Same comments as in other patches.
Fixed.
>
>> +		compatible = "voltage-divider";
>> +		io-channels = <&adc1 3>;
>> +		#io-channel-cells = <1>;
>> +
>> +		/* Scale the system voltage by 1127/127 to fit the ADC range.
> Use Linux coding style comments. /* and blank line

Fixed.

Thanks for the review.

Regards,

Ninad

>
>
> ....
>
> Best regards,
> Krzysztof
>


From knaerzche at gmail.com  Thu Dec 14 08:34:59 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 14 Dec 2023 17:34:59 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <qr7if2k76wdqgevdcwqxj2dkcbga72owjqlk3qaazujhejjloo@cnvmuq27qqns>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
 <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com> <3053311.k3LOHGUjKi@diego>
 <qr7if2k76wdqgevdcwqxj2dkcbga72owjqlk3qaazujhejjloo@cnvmuq27qqns>
Message-ID: <3f970571-f454-4615-8234-64ea68a3d63c@gmail.com>

Hi Heiko, Hi Maxime,

Am 14.12.23 um 12:36 schrieb Maxime Ripard:
> On Thu, Dec 14, 2023 at 12:17:34PM +0100, Heiko St?bner wrote:
>> Am Donnerstag, 14. Dezember 2023, 12:12:08 CET schrieb Alex Bee:
>>> Hi Maxime
>>>
>>> Am 14.12.23 um 08:56 schrieb Maxime Ripard:
>>>> Hi Alex,
>>>>
>>>> Thanks for working on this!
>>>>
>>>> On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
>>>>> The display controller will always give full range RGB regardless of the
>>>>> mode set, but HDMI requires certain modes to be transmitted in limited
>>>>> range RGB. This is especially required for HDMI sinks which do not support
>>>>> non-standard quantization ranges.
>>>>>
>>>>> This enables color space conversion for those modes and sets the
>>>>> quantization range accordingly in the AVI infoframe.
>>>>>
>>>>> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
>>>>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>>>>> ---
>>>>>    drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
>>>>>    1 file changed, 32 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>>> index 345253e033c5..32626a75723c 100644
>>>>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>>> @@ -33,6 +33,7 @@ struct hdmi_data_info {
>>>>>    	unsigned int enc_in_format;
>>>>>    	unsigned int enc_out_format;
>>>>>    	unsigned int colorimetry;
>>>>> +	bool rgb_limited_range;
>>>>>    };
>>>>>    
>>>>>    struct inno_hdmi_i2c {
>>>>> @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
>>>>>    	else
>>>>>    		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>>>>>    
>>>>> +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
>>>>> +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
>>>>> +						   &hdmi->connector, mode,
>>>>> +						   hdmi->hdmi_data.rgb_limited_range ?
>>>>> +						   HDMI_QUANTIZATION_RANGE_LIMITED :
>>>>> +						   HDMI_QUANTIZATION_RANGE_FULL);
>>>>> +	} else {
>>>>> +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
>>>>> +		frame.avi.ycc_quantization_range =
>>>>> +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
>>>>> +	}
>>>>> +
>>>>>    	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
>>>>>    }
>>>>>    
>>>>> @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
>>>>>    	if (data->enc_in_format == data->enc_out_format) {
>>>>>    		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
>>>>>    		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
>>>>> -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>>>>> -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>>>>> -
>>>>> -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>>>>> -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>>>>> -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>>>>> -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>>>>> -			return 0;
>>>>> +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
>>>>> +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
>>>>> +			    hdmi->hdmi_data.rgb_limited_range) {
>>>>> +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
>>>>> +				auto_csc = AUTO_CSC_DISABLE;
>>>>> +				c0_c2_change = C0_C2_CHANGE_DISABLE;
>>>>> +				csc_enable = v_CSC_ENABLE;
>>>>> +			} else {
>>>>> +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>>>>> +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>>>>> +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>>>>> +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>>>>> +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>>>>> +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>>>>> +				return 0;
>>>>> +			}
>>>>>    		}
>>>>>    	}
>>>>>    
>>>>> @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>>>>    	else
>>>>>    		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
>>>>>    
>>>>> +	hdmi->hdmi_data.rgb_limited_range =
>>>>> +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
>>>>> +
>>>> This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
>>>> https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/
>>> I'm aware of that and I mentioned it in the cover letter. Your series is
>>> not merged yet and it didn't get much feedback so far. What is the
>>> status there? Especially because you are removing things from inno-hdmi
>>> driver (which aren't really required to remove there) which will I have
>>> to reintroduce.
>> Sadly I haven't found the time to look closer at Maxime's series so far,
>> but I got the impression that it separates into multiple cleanup steps
>> for a number of controllers.
> Yeah, one of the previous version comment was to support more
> controllers than vc4, which is fair. So I ended up reworking and
> converting multiple controllers, but most of the clean up changes can be
> applied outside of that series just fine.
>
> I just didn't find someone to test / review them yet :)

I'm not exactly sure how to proceed here. Do you want me to:

- base my patches on top of Maxime's series and reintroduce csc things 
(of course only those which touch inno-hdmi w/o the framwork changes)

- only apply the patches that do not touch csc things and base my 
series? on top of that

- adapt Maxime's patches so that RGB full to RGB limited stays in there

- wait with resend until Maxime's series is merged and reintroduce csc 
after that

- something else

?

Please advise.

Thanks,

Alex

> Maxime


From conor at kernel.org  Thu Dec 14 08:35:27 2023
From: conor at kernel.org (Conor Dooley)
Date: Thu, 14 Dec 2023 16:35:27 +0000
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <d8b5df1c-c732-4cf3-ae28-cc2017d3b0b6@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-3-ninad@linux.ibm.com>
 <20231212-amusement-elevation-28e42bcccc35@spud>
 <d8b5df1c-c732-4cf3-ae28-cc2017d3b0b6@linux.ibm.com>
Message-ID: <20231214-stopper-bounce-ca9002869293@spud>

On Thu, Dec 14, 2023 at 09:34:39AM -0600, Ninad Palsule wrote:
> Hello Conor,
> 
> On 12/12/23 11:14, Conor Dooley wrote:
> > Hey,
> > 
> > On Tue, Dec 12, 2023 at 10:39:58AM -0600, Ninad Palsule wrote:
> > > From: Johannes Holland <johannes.holland at infineon.com>
> > > 
> > > Add a dt schema to support device tree bindings
> > "Add bindings for..."
> Fixed.
> > 
> > > for the generic I2C
> > > physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
> > > Specification for TPM 2.0 v1.04 Revision 14.
> > > 
> > > This includes descriptions for the Nuvoton and Infineon devices.
> > > 
> > > OpenBMC-Staging-Count: 3
> > I have no idea what this is, but it needs to be removed from the patch.
> Removed.
> > 
> > > Signed-off-by: Johannes Holland <johannes.holland at infineon.com>
> > > Signed-off-by: Joel Stanley <joel at jms.id.au>
> > > Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> > > ---
> > >   .../bindings/security/tpm/tpm-tis-i2c.yaml    | 50 +++++++++++++++++++
> > >   1 file changed, 50 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> > > new file mode 100644
> > > index 000000000000..de1e34065748
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> > > @@ -0,0 +1,50 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: I2C PTP based TPM Devices
> > > +
> > > +maintainers:
> > > +  - Johannes Holland <johannes.holland at infineon.com>
> > > +
> > > +description:
> > > +  Device Tree Bindings for I2C based Trusted Platform Module (TPM).
> > s/Device Tree Bindings for //. Doesn't dt_binding_check now complain if
> > you have this in a title or description?
> Fixed.
> > 
> > > +properties:
> > > +  $nodename:
> > > +    pattern: "^tpm(@[0-9a-f]+)?$"
> > > +
> > > +  compatible:
> > > +    oneOf:
> > > +      - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
> > > +        items:
> > > +          - const: infineon,slb9673
> > > +          - const: tcg,tpm-tis-i2c
> > > +      - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
> > > +        items:
> > > +          - const: nuvoton,npct75x
> > > +          - const: tcg,tpm-tis-i2c

Also, another thought - the bus is not usually encoded in the compatible
string, so it would be good to remove that.

> > > +      - const: tcg,tpm-tis-i2c
> > IMO this should be removed and this fallback should only be used in
> > combination with device specific compatibles, like you have here for the
> > infineon and nuvoton devices.
> 
> As Guenter mentioned I need to keep it as tacoma board is just using this
> string.

No, that does not mean that you have to keep this in the binding. I know
Rob had some comments that might invalidate this binding entirely, but
if that does not happen then I think think that the tacoma devicetree
needs to have a device-specific compatible added for the tpm that it has.
You could of course retain the generic fallback compatible however.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231214/913ca573/attachment.sig>

From jernej.skrabec at gmail.com  Thu Dec 14 08:36:59 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Thu, 14 Dec 2023 17:36:59 +0100
Subject: [PATCH 1/5] riscv: dts: allwinner: Update opp table to allow CPU
 frequency scaling
In-Reply-To: <20231214-junkyard-corset-d35b01bad69f@spud>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
 <20231214111446.camz2krqanaieybh@vireshk-i7>
 <20231214-junkyard-corset-d35b01bad69f@spud>
Message-ID: <2177637.Mh6RI2rZIc@archlinux>

On Thursday, December 14, 2023 2:47:14 PM CET Conor Dooley wrote:
> On Thu, Dec 14, 2023 at 04:44:46PM +0530, Viresh Kumar wrote:
> > On 14-12-23, 11:33, Brandon Cheo Fusi wrote:
> > > Two OPPs are currently defined for the D1/D1s; one at 408MHz and
> > > another at 1.08GHz. Switching between these can be done with the
> > > "sun50i-cpufreq-nvmem" driver. This patch populates the opp table
> > > appropriately, with inspiration from
> > > https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi
> > > 
> > > The supply voltages are PWM-controlled, but support for that IP
> > > is still in the works. So stick to a fixed 0.9V vdd-cpu supply,
> > > which seems to be the default on most D1 boards.
> > > 
> > > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > > ---
> > >  arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 18 +++++++++++++++---
> > >  1 file changed, 15 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > > index 64c3c2e6c..e211fe4c7 100644
> > > --- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > > +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > > @@ -39,16 +39,22 @@ cpu0_intc: interrupt-controller {
> > >  	};
> > >  
> > >  	opp_table_cpu: opp-table-cpu {
> > > -		compatible = "operating-points-v2";
> > > +		compatible = "allwinner,sun20i-d1-operating-points",
> > 
> > I don't think you should add a new compatible for every SoC that needs
> > to be supported by a DT bindings and cpufreq driver. Maybe you should
> > just reuse "allwinner,sun50i-h6-operating-points" and it will work
> > fine for you ?
> > 
> > Rob ?
> 
> The driver can definitely just reuse sun50i-h6, but the binding and
> devicetree should have a soc-specific compatible for the sun20i-d1.

Correct. This is to avoid later regrets if it turns out there are some slight
differences or additional functionality.

Best regards,
Jernej

> 
> That said, the compatible does need to be documented, there's a
> dt-bindings patch missing from this series.
> 
> Cheers,
> Conor.






From andre.przywara at arm.com  Thu Dec 14 08:40:10 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 14 Dec 2023 16:40:10 +0000
Subject: [PATCH 2/5] cpufreq: sun50i: Add D1 support
In-Reply-To: <8351928.NyiUUSuA9g@archlinux>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
	<20231214103342.30775-3-fusibrandon13@gmail.com>
	<8351928.NyiUUSuA9g@archlinux>
Message-ID: <20231214164010.0be50a89@donnerap.manchester.arm.com>

On Thu, 14 Dec 2023 17:29:30 +0100
Jernej ?krabec <jernej.skrabec at gmail.com> wrote:

Hi,

> On Thursday, December 14, 2023 11:33:39 AM CET Brandon Cheo Fusi wrote:
> > Add support for D1 based devices to the Allwinner H6 cpufreq
> > driver
> > 
> > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > ---
> >  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > index 32a9c88f8..ccf83780f 100644
> > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > @@ -160,6 +160,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
> >  
> >  static const struct of_device_id sun50i_cpufreq_match_list[] = {
> >  	{ .compatible = "allwinner,sun50i-h6" },
> > +	{ .compatible = "allwinner,sun20i-d1" },  
> 
> This is not needed, as there is no functionality change.

That was my first reflex, too, but this is the *board* (fallback)
compatible, listed in the root node, so you have to list it here for each
SoC, together with the respective blocklist in the next patch.
We are doing the same for the H616, and actually also need that for the
H618. Weird, I know, but last time I check not easy to fix.

Cheers,
Andre


From semen.protsenko at linaro.org  Thu Dec 14 08:43:04 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Thu, 14 Dec 2023 10:43:04 -0600
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock
 as critical
In-Reply-To: <5de5cddd-2bab-4408-b31f-f48bef98f14c@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-8-tudor.ambarus@linaro.org> <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>
 <f3d61c49-1a46-476c-b7a5-6cc6a06a33ed@linaro.org> <CAPLW+4=tyr8Pcoe6Wm0Wtmkk4udDpuAiOKy7+C+Fwa6mvt3VoQ@mail.gmail.com>
 <5de5cddd-2bab-4408-b31f-f48bef98f14c@linaro.org>
Message-ID: <CAPLW+4n-S2jaVPUwKTFC_iabnDd_qDV=ZubMqhz-X9XiZzzJow@mail.gmail.com>

On Thu, Dec 14, 2023 at 10:15?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
>
>
> On 12/14/23 16:09, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 10:01?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>
> >>
> >>
> >> On 12/14/23 15:37, Sam Protsenko wrote:
> >>> On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>>>
> >>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >>>> which then makes the system hang. To prevent this, mark
> >>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >>>> accordingly when tested.
> >>>>
> >>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> >>>> ---
> >>>>  drivers/clk/samsung/clk-gs101.c | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >>>> index 3d194520b05e..08d80fca9cd6 100644
> >>>> --- a/drivers/clk/samsung/clk-gs101.c
> >>>> +++ b/drivers/clk/samsung/clk-gs101.c
> >>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>>>              "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>>>              21, 0, 0),
> >>>>         GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >>>> -            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >>>> +            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >>>
> >>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> >>> Leaving it always running makes the whole PERIC0 CMU clocked, which
> >>> usually should be avoided. Is it possible that the system freezes
> >>> because some other clock (which depends on peric0_ip) gets disabled as
> >>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> >>> is not implemented yet in the clock driver? Just looks weird to me
> >>> that the system hangs because of CMU IP clock disablement. It's
> >>> usually something much more specific.
> >>
> >> The system hang happened when I tested USI8 in I2C configuration with an
> >> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> >> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> >> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> >> disablement which makes the system hang. Either marking the CMU_TOP gate
> >> clock as critical (as I did in this patch) or marking the leaf PERIC0
> >> gate clock as critical, gets rid of the system hang. Did I choose wrong?
> >>
> >
> > Did you already implement 100% of clocks in CMU_PERIC0? If no, there
>
> yes.

Ok. Are there any other CMUs (perhaps not implemented yet) which
consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
clocks derived from it? If so, is there a chance some particular leaf
clock in those CMUs actually renders the system frozen when disabled
as a consequence of disabling PERIC0_IP, and would explain better why
the freeze happens?

For now I think it's ok to have that CLK_IS_CRITICAL flag here,
because as you said you implemented all clocks in this CMU and neither
of those looks like a critical one. But I'd advice to add a TODO
comment saying it's probably a temporary solution before actual leaf
clock which leads to freeze is identified (which probably resides in
some other not implemented yet CMU).

>
> > is a chance some other leaf clock (which is not implemented yet in
> > your driver) gets disabled as a result of PERIC0_IP disablement, which
> > might actually lead to that hang you observe. Usually it's some
> > meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> > clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> > and the corresponding comments I left there, maybe it'll give you more
> > particular idea about what to look for. Yes, making the whole CMU
> > always running without understanding why (i.e. because of which
> > particular leaf clock) might not be the best way of handling this
>
> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK

That's not a root cause here. And I think PERIC0_IP is neither.

>
> > issue. I might be mistaken, but at least please check if you
> > implemented all clocks for PERIC0 first and if making some meaningful
> > leaf clock critical makes more sense.
> >
>
> Thanks,
> ta


From Jonathan.Cameron at Huawei.com  Thu Dec 14 08:45:41 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Thu, 14 Dec 2023 16:45:41 +0000
Subject: [PATCH v3 12/15] arm64/mm: Split __flush_tlb_range() to elide
 trailing DSB
In-Reply-To: <20231214152206.GA3625745@myrica>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
	<20231204105440.61448-13-ryan.roberts@arm.com>
	<20231212113517.GA28857@willie-the-truck>
	<0969c413-bf40-4c46-9f1e-a92101ff2d2e@arm.com>
	<2e6f06d3-6c8e-4b44-b6f2-e55bd5be83d6@arm.com>
	<20231214121336.GA1015@willie-the-truck>
	<fbcda9e1-0473-4669-a869-d4de351c3197@arm.com>
	<20231214152206.GA3625745@myrica>
Message-ID: <20231214164541.000027a1@Huawei.com>

On Thu, 14 Dec 2023 15:22:06 +0000
Jean-Philippe Brucker <jean-philippe at linaro.org> wrote:

> On Thu, Dec 14, 2023 at 12:30:55PM +0000, Robin Murphy wrote:
> > > Robin, Jean-Philippe -- do we need to make sure that the SMMU has completed
> > > its TLB invalidation before issuing an ATC invalidate? My half-baked worry
> > > is whether or not an ATS request could refill the ATC before the TLBI
> > > has completed, therefore rendering the ATC invalidation useless.  
> > 
> > I would agree, and the spec for CMD_ATC_INV does call out a
> > TLBI->sync->ATCI->sync sequence. At the moment the SVA notifier is issuing
> > its own command-based TLBIs anyway so the necessary sync is implicit there,
> > but if and when we get BTM support wired up properly it would be nice not to
> > have to bodge in an additional sync/DSB.  
> 
> Yes agreed, with BTM the CPU must call the notifier that issues ATC
> invalidation after completing the TLBI+DSB instructions.
> 
> SMMU IHI0070F.a  3.9.1 ATS Interface
> 
> 	Software must ensure that the SMMU TLB invalidation is complete before
> 	initiating the ATC invalidation.
> 
> I'm guessing BTM will be enabled in the SMMU driver sometime soon, given
> that there already is one implementation in the wild that could use it. I
> think we didn't enable it because of the lack of separation between shared
> and private VMIDs, but that may now be solvable with the recent rework of
> the VMID allocator.
> 

+CC Shameer.  We'll indeed need to fix this when enabling BTM.

Thanks for the heads up.

Jonathan

> Thanks,
> Jean
> 



From rdunlap at infradead.org  Thu Dec 14 08:46:21 2023
From: rdunlap at infradead.org (Randy Dunlap)
Date: Thu, 14 Dec 2023 08:46:21 -0800
Subject: [PATCH] media: platform: xilinx: Fix Kconfig indentation
In-Reply-To: <72c40d216769a97973cac9a347e826b943f71d7f.1702543638.git.michal.simek@amd.com>
References: <72c40d216769a97973cac9a347e826b943f71d7f.1702543638.git.michal.simek@amd.com>
Message-ID: <f3a196d0-d15b-4929-857d-18ef77f693a3@infradead.org>

Hi,

On 12/14/23 00:47, Michal Simek wrote:
> Use proper indentation for Kconfig fragments - help part.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>

Reviewed-by: Randy Dunlap <rdunlap at infradead.org>
Tested-by: Randy Dunlap <rdunlap at infradead.org>

Thanks.

> ---
> 
>  drivers/media/platform/xilinx/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/xilinx/Kconfig b/drivers/media/platform/xilinx/Kconfig
> index 93ef78bf62e6..601edd9acd5b 100644
> --- a/drivers/media/platform/xilinx/Kconfig
> +++ b/drivers/media/platform/xilinx/Kconfig
> @@ -26,10 +26,10 @@ config VIDEO_XILINX_TPG
>  	depends on VIDEO_XILINX
>  	select VIDEO_XILINX_VTC
>  	help
> -	   Driver for the Xilinx Video Test Pattern Generator
> +	  Driver for the Xilinx Video Test Pattern Generator
>  
>  config VIDEO_XILINX_VTC
>  	tristate "Xilinx Video Timing Controller"
>  	depends on VIDEO_XILINX
>  	help
> -	   Driver for the Xilinx Video Timing Controller
> +	  Driver for the Xilinx Video Timing Controller

-- 
#Randy
https://people.kernel.org/tglx/notes-about-netiquette
https://subspace.kernel.org/etiquette.html


From jean-philippe at linaro.org  Thu Dec 14 08:51:26 2023
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu, 14 Dec 2023 16:51:26 +0000
Subject: [PATCH v2 6/7] iommu/dma: Centralise iommu_setup_dma_ops()
In-Reply-To: <5d89190b35720bf5b66621f46b6d3c85323d8eab.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
 <5d89190b35720bf5b66621f46b6d3c85323d8eab.1702486837.git.robin.murphy@arm.com>
Message-ID: <20231214165126.GA3726750@myrica>

On Wed, Dec 13, 2023 at 05:17:59PM +0000, Robin Murphy wrote:
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 27a167f4cd3e..d808c8dcf5cb 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1724,25 +1724,20 @@ static const struct dma_map_ops iommu_dma_ops = {
>  	.opt_mapping_size	= iommu_dma_opt_mapping_size,
>  };
>  
> -/*
> - * The IOMMU core code allocates the default DMA domain, which the underlying
> - * IOMMU driver needs to support via the dma-iommu layer.
> - */
> -void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
> +void iommu_setup_dma_ops(struct device *dev)
>  {
>  	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
>  
> -	if (!domain)
> -		goto out_err;
> +	if (dev_is_pci(dev))
> +		dev->iommu->pci_32bit_workaround = !iommu_dma_forcedac;
>  
> -	/*
> -	 * The IOMMU core code allocates the default DMA domain, which the
> -	 * underlying IOMMU driver needs to support via the dma-iommu layer.
> -	 */
>  	if (iommu_is_dma_domain(domain)) {

...

> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 824989874dee..43f630d0530e 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -560,10 +560,10 @@ static int __iommu_probe_device(struct device *dev, struct list_head *group_list
>  		if (list_empty(&group->entry))
>  			list_add_tail(&group->entry, group_list);
>  	}
> -	mutex_unlock(&group->mutex);
>  
> -	if (dev_is_pci(dev))
> -		iommu_dma_set_pci_32bit_workaround(dev);
> +	iommu_setup_dma_ops(dev);

With Intel VT-d (QEMU emulation) I get a crash in iommu_setup_dma_ops()
because at this point group->domain and group->default_domain are still
NULL, group_list is non-NULL.

No problem with x86 virtio-iommu, it goes through
iommu_setup_default_domain() earlier in the function. Arm virtio-iommu is
fine too.

Thanks,
Jean



From oliver.upton at linux.dev  Thu Dec 14 08:56:01 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Thu, 14 Dec 2023 16:56:01 +0000
Subject: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for
 vfio pci devices
In-Reply-To: <ZXsjv+svp44YjMmh@lpieralisi>
References: <20231208164709.23101-1-ankita@nvidia.com>
 <20231208164709.23101-3-ankita@nvidia.com>
 <ZXicemDzXm8NShs1@arm.com>
 <20231212181156.GO3014157@nvidia.com>
 <ZXoOieQN7rBiLL4A@linux.dev>
 <ZXsjv+svp44YjMmh@lpieralisi>
Message-ID: <ZXszoQ48pZ7FnQNV@linux.dev>

On Thu, Dec 14, 2023 at 04:48:15PM +0100, Lorenzo Pieralisi wrote:

[...]

> > AFAICT, the only reason PCI devices can get the blanket treatment of
> > Normal-NC at stage-2 is because userspace has a Device-* mapping and can't
> > speculatively load from the alias. This feels a bit hacky, and maybe we
> > should prioritize an interface for mapping a device into a VM w/o a
> > valid userspace mapping.
> 
> FWIW - I have tried to summarize the reasoning behind PCIe devices
> Normal-NC default stage-2 safety in a document that I have just realized
> now it has become this series cover letter, I don't think the PCI blanket
> treatment is related *only* to the current user space mappings (ie
> BTW, AFAICS it is also *possible* at present to map a prefetchable BAR through
> sysfs with Normal-NC memory attributes in the host at the same time a PCI
> device is passed-through to a guest with VFIO - and therefore we have a
> dev-nGnRnE stage-1 mapping for it. Don't think anyone does that - what for -
> but it is possible and KVM would not know about it).
> 
> Again, FWIW, we were told (source Arm ARM) mismatched aliases concerning
> device-XXX vs Normal-NC are not problematic as long as the transactions
> issued for the related mappings are independent (and none of the
> mappings is cacheable).
> 
> I appreciate this is not enough to give everyone full confidence on
> this solution robustness - that's why I wrote that up so that we know
> what we are up against and write KVM interfaces accordingly.

Apologies, I didn't mean to question what's going on here from the
hardware POV. My concern was more from the kernel + user interfaces POV,
this all seems to work (specifically for PCI) by maintaining an
intentional mismatch between the VFIO stage-1 and KVM stage-2 mappings.

If we add more behind-the-scenes tricks to get other MMIO mappings
working in the future then this whole interaction will get even
hairier. At least if we follow the stage-1 attributes (where possible)
then we can document some sort of expected behavior in KVM. The VMM would
need know if the device has read side-effects, as the only way to get a
Normal-NC mapping in the guest would be to have one at stage-1.

Kinda stinks to make the VMM aware of the device, but IMO it is a
fundamental limitation of the way we back memslots right now.

-- 
Thanks,
Oliver


From francesco at dolcini.it  Thu Dec 14 09:01:46 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Thu, 14 Dec 2023 18:01:46 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to size_t
Message-ID: <20231214170146.641783-1-francesco@dolcini.it>

From: Francesco Dolcini <francesco.dolcini at toradex.com>

receive_buf() is called from ttyport_receive_buf() that expects values
">= 0" from serdev_controller_receive_buf(), change its return type from
ssize_t to size_t.

Suggested-by: Jiri Slaby <jirislaby at kernel.org>
Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
---
hello,
patch is based on current linux next.

It has an obvious problem, it touches files from multiple subsystem in a single
patch that is complicated to review and eventually merge, just splitting this
would however not work, it will break bisectability and the build.

I am looking for advise on the best way to move forward.

I see the following options:
 - keep it as it is
 - break it down with a patch with each subsystem, and squash before applying
   from a single (tty?) subsystem
 - go for a multi stage approach, defining a new callback, move to it and in
   the end remove the original one, likewise it was done for i2c lately

---
 drivers/bluetooth/btmtkuart.c              |  4 ++--
 drivers/bluetooth/btnxpuart.c              |  4 ++--
 drivers/bluetooth/hci_serdev.c             |  4 ++--
 drivers/gnss/core.c                        |  6 +++---
 drivers/gnss/serial.c                      |  4 ++--
 drivers/gnss/sirf.c                        |  6 +++---
 drivers/greybus/gb-beagleplay.c            |  6 +++---
 drivers/iio/chemical/pms7003.c             |  4 ++--
 drivers/iio/chemical/scd30_serial.c        |  4 ++--
 drivers/iio/chemical/sps30_serial.c        |  4 ++--
 drivers/iio/imu/bno055/bno055_ser_core.c   |  4 ++--
 drivers/mfd/rave-sp.c                      |  4 ++--
 drivers/net/ethernet/qualcomm/qca_uart.c   |  2 +-
 drivers/nfc/pn533/uart.c                   |  4 ++--
 drivers/nfc/s3fwrn5/uart.c                 |  4 ++--
 drivers/platform/chrome/cros_ec_uart.c     |  4 ++--
 drivers/platform/surface/aggregator/core.c |  4 ++--
 drivers/tty/serdev/serdev-ttyport.c        | 10 ++++------
 include/linux/gnss.h                       |  4 ++--
 include/linux/serdev.h                     |  8 ++++----
 sound/drivers/serial-generic.c             |  4 ++--
 21 files changed, 48 insertions(+), 50 deletions(-)

diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
index 3c84fcbda01a..e6bc4a73c9fc 100644
--- a/drivers/bluetooth/btmtkuart.c
+++ b/drivers/bluetooth/btmtkuart.c
@@ -383,8 +383,8 @@ static void btmtkuart_recv(struct hci_dev *hdev, const u8 *data, size_t count)
 	}
 }
 
-static ssize_t btmtkuart_receive_buf(struct serdev_device *serdev,
-				     const u8 *data, size_t count)
+static size_t btmtkuart_receive_buf(struct serdev_device *serdev,
+				    const u8 *data, size_t count)
 {
 	struct btmtkuart_dev *bdev = serdev_device_get_drvdata(serdev);
 
diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
index 1d592ac413d1..056bef5b2919 100644
--- a/drivers/bluetooth/btnxpuart.c
+++ b/drivers/bluetooth/btnxpuart.c
@@ -1264,8 +1264,8 @@ static const struct h4_recv_pkt nxp_recv_pkts[] = {
 	{ NXP_RECV_FW_REQ_V3,   .recv = nxp_recv_fw_req_v3 },
 };
 
-static ssize_t btnxpuart_receive_buf(struct serdev_device *serdev,
-				     const u8 *data, size_t count)
+static size_t btnxpuart_receive_buf(struct serdev_device *serdev,
+				    const u8 *data, size_t count)
 {
 	struct btnxpuart_dev *nxpdev = serdev_device_get_drvdata(serdev);
 
diff --git a/drivers/bluetooth/hci_serdev.c b/drivers/bluetooth/hci_serdev.c
index 39c8b567da3c..a3c3beb2806d 100644
--- a/drivers/bluetooth/hci_serdev.c
+++ b/drivers/bluetooth/hci_serdev.c
@@ -271,8 +271,8 @@ static void hci_uart_write_wakeup(struct serdev_device *serdev)
  *
  * Return: number of processed bytes
  */
-static ssize_t hci_uart_receive_buf(struct serdev_device *serdev,
-				    const u8 *data, size_t count)
+static size_t hci_uart_receive_buf(struct serdev_device *serdev,
+				   const u8 *data, size_t count)
 {
 	struct hci_uart *hu = serdev_device_get_drvdata(serdev);
 
diff --git a/drivers/gnss/core.c b/drivers/gnss/core.c
index 48f2ee0f78c4..9b8a0605ec76 100644
--- a/drivers/gnss/core.c
+++ b/drivers/gnss/core.c
@@ -317,10 +317,10 @@ EXPORT_SYMBOL_GPL(gnss_deregister_device);
  *
  * Must not be called for a closed device.
  */
-int gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
-				size_t count)
+size_t gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
+		       size_t count)
 {
-	int ret;
+	size_t ret;
 
 	ret = kfifo_in(&gdev->read_fifo, buf, count);
 
diff --git a/drivers/gnss/serial.c b/drivers/gnss/serial.c
index baa956494e79..bf55aa2c1cf0 100644
--- a/drivers/gnss/serial.c
+++ b/drivers/gnss/serial.c
@@ -80,8 +80,8 @@ static const struct gnss_operations gnss_serial_gnss_ops = {
 	.write_raw	= gnss_serial_write_raw,
 };
 
-static ssize_t gnss_serial_receive_buf(struct serdev_device *serdev,
-				       const u8 *buf, size_t count)
+static size_t gnss_serial_receive_buf(struct serdev_device *serdev,
+				      const u8 *buf, size_t count)
 {
 	struct gnss_serial *gserial = serdev_device_get_drvdata(serdev);
 	struct gnss_device *gdev = gserial->gdev;
diff --git a/drivers/gnss/sirf.c b/drivers/gnss/sirf.c
index 6801a8fb2040..2aae3c02156d 100644
--- a/drivers/gnss/sirf.c
+++ b/drivers/gnss/sirf.c
@@ -160,12 +160,12 @@ static const struct gnss_operations sirf_gnss_ops = {
 	.write_raw	= sirf_write_raw,
 };
 
-static ssize_t sirf_receive_buf(struct serdev_device *serdev,
-				const u8 *buf, size_t count)
+static size_t sirf_receive_buf(struct serdev_device *serdev,
+			       const u8 *buf, size_t count)
 {
 	struct sirf_data *data = serdev_device_get_drvdata(serdev);
 	struct gnss_device *gdev = data->gdev;
-	int ret = 0;
+	size_t ret = 0;
 
 	if (!data->wakeup && !data->active) {
 		data->active = true;
diff --git a/drivers/greybus/gb-beagleplay.c b/drivers/greybus/gb-beagleplay.c
index 2da37ff92cf1..26c95efe2fff 100644
--- a/drivers/greybus/gb-beagleplay.c
+++ b/drivers/greybus/gb-beagleplay.c
@@ -257,7 +257,7 @@ static void hdlc_rx_frame(struct gb_beagleplay *bg)
 	}
 }
 
-static ssize_t hdlc_rx(struct gb_beagleplay *bg, const u8 *data, size_t count)
+static size_t hdlc_rx(struct gb_beagleplay *bg, const u8 *data, size_t count)
 {
 	size_t i;
 	u8 c;
@@ -317,8 +317,8 @@ static void hdlc_deinit(struct gb_beagleplay *bg)
 	flush_work(&bg->tx_work);
 }
 
-static ssize_t gb_tty_receive(struct serdev_device *sd, const u8 *data,
-			      size_t count)
+static size_t gb_tty_receive(struct serdev_device *sd, const u8 *data,
+			     size_t count)
 {
 	struct gb_beagleplay *bg = serdev_device_get_drvdata(sd);
 
diff --git a/drivers/iio/chemical/pms7003.c b/drivers/iio/chemical/pms7003.c
index b5cf15a515d2..43025866d5b7 100644
--- a/drivers/iio/chemical/pms7003.c
+++ b/drivers/iio/chemical/pms7003.c
@@ -211,8 +211,8 @@ static bool pms7003_frame_is_okay(struct pms7003_frame *frame)
 	return checksum == pms7003_calc_checksum(frame);
 }
 
-static ssize_t pms7003_receive_buf(struct serdev_device *serdev, const u8 *buf,
-				   size_t size)
+static size_t pms7003_receive_buf(struct serdev_device *serdev, const u8 *buf,
+				  size_t size)
 {
 	struct iio_dev *indio_dev = serdev_device_get_drvdata(serdev);
 	struct pms7003_state *state = iio_priv(indio_dev);
diff --git a/drivers/iio/chemical/scd30_serial.c b/drivers/iio/chemical/scd30_serial.c
index a47654591e55..2adb76dbb020 100644
--- a/drivers/iio/chemical/scd30_serial.c
+++ b/drivers/iio/chemical/scd30_serial.c
@@ -174,8 +174,8 @@ static int scd30_serdev_command(struct scd30_state *state, enum scd30_cmd cmd, u
 	return 0;
 }
 
-static ssize_t scd30_serdev_receive_buf(struct serdev_device *serdev,
-					const u8 *buf, size_t size)
+static size_t scd30_serdev_receive_buf(struct serdev_device *serdev,
+				       const u8 *buf, size_t size)
 {
 	struct iio_dev *indio_dev = serdev_device_get_drvdata(serdev);
 	struct scd30_serdev_priv *priv;
diff --git a/drivers/iio/chemical/sps30_serial.c b/drivers/iio/chemical/sps30_serial.c
index 3afa89f8acc3..a6dfbe28c914 100644
--- a/drivers/iio/chemical/sps30_serial.c
+++ b/drivers/iio/chemical/sps30_serial.c
@@ -210,8 +210,8 @@ static int sps30_serial_command(struct sps30_state *state, unsigned char cmd,
 	return rsp_size;
 }
 
-static ssize_t sps30_serial_receive_buf(struct serdev_device *serdev,
-					const u8 *buf, size_t size)
+static size_t sps30_serial_receive_buf(struct serdev_device *serdev,
+				       const u8 *buf, size_t size)
 {
 	struct iio_dev *indio_dev = dev_get_drvdata(&serdev->dev);
 	struct sps30_serial_priv *priv;
diff --git a/drivers/iio/imu/bno055/bno055_ser_core.c b/drivers/iio/imu/bno055/bno055_ser_core.c
index 5677bdf4f846..694ff14a3aa2 100644
--- a/drivers/iio/imu/bno055/bno055_ser_core.c
+++ b/drivers/iio/imu/bno055/bno055_ser_core.c
@@ -378,8 +378,8 @@ static void bno055_ser_handle_rx(struct bno055_ser_priv *priv, int status)
  * Also, we assume to RX one pkt per time (i.e. the HW doesn't send anything
  * unless we require to AND we don't queue more than one request per time).
  */
-static ssize_t bno055_ser_receive_buf(struct serdev_device *serdev,
-				      const u8 *buf, size_t size)
+static size_t bno055_ser_receive_buf(struct serdev_device *serdev,
+				     const u8 *buf, size_t size)
 {
 	int status;
 	struct bno055_ser_priv *priv = serdev_device_get_drvdata(serdev);
diff --git a/drivers/mfd/rave-sp.c b/drivers/mfd/rave-sp.c
index b1229bb143ee..f517e59e1c01 100644
--- a/drivers/mfd/rave-sp.c
+++ b/drivers/mfd/rave-sp.c
@@ -471,8 +471,8 @@ static void rave_sp_receive_frame(struct rave_sp *sp,
 		rave_sp_receive_reply(sp, data, length);
 }
 
-static ssize_t rave_sp_receive_buf(struct serdev_device *serdev,
-				   const u8 *buf, size_t size)
+static size_t rave_sp_receive_buf(struct serdev_device *serdev,
+				  const u8 *buf, size_t size)
 {
 	struct device *dev = &serdev->dev;
 	struct rave_sp *sp = dev_get_drvdata(dev);
diff --git a/drivers/net/ethernet/qualcomm/qca_uart.c b/drivers/net/ethernet/qualcomm/qca_uart.c
index 223321897b96..20f50bde82ac 100644
--- a/drivers/net/ethernet/qualcomm/qca_uart.c
+++ b/drivers/net/ethernet/qualcomm/qca_uart.c
@@ -58,7 +58,7 @@ struct qcauart {
 	unsigned char *tx_buffer;
 };
 
-static ssize_t
+static size_t
 qca_tty_receive(struct serdev_device *serdev, const u8 *data, size_t count)
 {
 	struct qcauart *qca = serdev_device_get_drvdata(serdev);
diff --git a/drivers/nfc/pn533/uart.c b/drivers/nfc/pn533/uart.c
index 2eb5978bd79e..cfbbe0713317 100644
--- a/drivers/nfc/pn533/uart.c
+++ b/drivers/nfc/pn533/uart.c
@@ -203,8 +203,8 @@ static int pn532_uart_rx_is_frame(struct sk_buff *skb)
 	return 0;
 }
 
-static ssize_t pn532_receive_buf(struct serdev_device *serdev,
-				 const u8 *data, size_t count)
+static size_t pn532_receive_buf(struct serdev_device *serdev,
+				const u8 *data, size_t count)
 {
 	struct pn532_uart_phy *dev = serdev_device_get_drvdata(serdev);
 	size_t i;
diff --git a/drivers/nfc/s3fwrn5/uart.c b/drivers/nfc/s3fwrn5/uart.c
index 456d3947116c..9c09c10c2a46 100644
--- a/drivers/nfc/s3fwrn5/uart.c
+++ b/drivers/nfc/s3fwrn5/uart.c
@@ -51,8 +51,8 @@ static const struct s3fwrn5_phy_ops uart_phy_ops = {
 	.write = s3fwrn82_uart_write,
 };
 
-static ssize_t s3fwrn82_uart_read(struct serdev_device *serdev,
-				  const u8 *data, size_t count)
+static size_t s3fwrn82_uart_read(struct serdev_device *serdev,
+				 const u8 *data, size_t count)
 {
 	struct s3fwrn82_uart_phy *phy = serdev_device_get_drvdata(serdev);
 	size_t i;
diff --git a/drivers/platform/chrome/cros_ec_uart.c b/drivers/platform/chrome/cros_ec_uart.c
index 68d80559fddc..8ea867c2a01a 100644
--- a/drivers/platform/chrome/cros_ec_uart.c
+++ b/drivers/platform/chrome/cros_ec_uart.c
@@ -81,8 +81,8 @@ struct cros_ec_uart {
 	struct response_info response;
 };
 
-static ssize_t cros_ec_uart_rx_bytes(struct serdev_device *serdev,
-				     const u8 *data, size_t count)
+static size_t cros_ec_uart_rx_bytes(struct serdev_device *serdev,
+				    const u8 *data, size_t count)
 {
 	struct ec_host_response *host_response;
 	struct cros_ec_device *ec_dev = serdev_device_get_drvdata(serdev);
diff --git a/drivers/platform/surface/aggregator/core.c b/drivers/platform/surface/aggregator/core.c
index 9591a28bc38a..ba550eaa06fc 100644
--- a/drivers/platform/surface/aggregator/core.c
+++ b/drivers/platform/surface/aggregator/core.c
@@ -227,8 +227,8 @@ EXPORT_SYMBOL_GPL(ssam_client_bind);
 
 /* -- Glue layer (serdev_device -> ssam_controller). ------------------------ */
 
-static ssize_t ssam_receive_buf(struct serdev_device *dev, const u8 *buf,
-				size_t n)
+static size_t ssam_receive_buf(struct serdev_device *dev, const u8 *buf,
+			       size_t n)
 {
 	struct ssam_controller *ctrl;
 	int ret;
diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
index e94e090cf0a1..3d7ae7fa5018 100644
--- a/drivers/tty/serdev/serdev-ttyport.c
+++ b/drivers/tty/serdev/serdev-ttyport.c
@@ -27,19 +27,17 @@ static size_t ttyport_receive_buf(struct tty_port *port, const u8 *cp,
 {
 	struct serdev_controller *ctrl = port->client_data;
 	struct serport *serport = serdev_controller_get_drvdata(ctrl);
-	int ret;
+	size_t ret;
 
 	if (!test_bit(SERPORT_ACTIVE, &serport->flags))
 		return 0;
 
 	ret = serdev_controller_receive_buf(ctrl, cp, count);
 
-	dev_WARN_ONCE(&ctrl->dev, ret < 0 || ret > count,
-				"receive_buf returns %d (count = %zu)\n",
+	dev_WARN_ONCE(&ctrl->dev, ret > count,
+				"receive_buf returns %zu (count = %zu)\n",
 				ret, count);
-	if (ret < 0)
-		return 0;
-	else if (ret > count)
+	if (ret > count)
 		return count;
 
 	return ret;
diff --git a/include/linux/gnss.h b/include/linux/gnss.h
index 36968a0f33e8..9857c4029e65 100644
--- a/include/linux/gnss.h
+++ b/include/linux/gnss.h
@@ -60,8 +60,8 @@ void gnss_put_device(struct gnss_device *gdev);
 int gnss_register_device(struct gnss_device *gdev);
 void gnss_deregister_device(struct gnss_device *gdev);
 
-int gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
-			size_t count);
+size_t gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
+		       size_t count);
 
 static inline void gnss_set_drvdata(struct gnss_device *gdev, void *data)
 {
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 3fab88ba265e..ff78efc1f60d 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -27,7 +27,7 @@ struct serdev_device;
  *			not sleep.
  */
 struct serdev_device_ops {
-	ssize_t (*receive_buf)(struct serdev_device *, const u8 *, size_t);
+	size_t (*receive_buf)(struct serdev_device *, const u8 *, size_t);
 	void (*write_wakeup)(struct serdev_device *);
 };
 
@@ -185,9 +185,9 @@ static inline void serdev_controller_write_wakeup(struct serdev_controller *ctrl
 	serdev->ops->write_wakeup(serdev);
 }
 
-static inline ssize_t serdev_controller_receive_buf(struct serdev_controller *ctrl,
-						    const u8 *data,
-						    size_t count)
+static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl,
+						   const u8 *data,
+						   size_t count)
 {
 	struct serdev_device *serdev = ctrl->serdev;
 
diff --git a/sound/drivers/serial-generic.c b/sound/drivers/serial-generic.c
index d6e5aafd697c..36409a56c675 100644
--- a/sound/drivers/serial-generic.c
+++ b/sound/drivers/serial-generic.c
@@ -100,8 +100,8 @@ static void snd_serial_generic_write_wakeup(struct serdev_device *serdev)
 	snd_serial_generic_tx_wakeup(drvdata);
 }
 
-static ssize_t snd_serial_generic_receive_buf(struct serdev_device *serdev,
-					      const u8 *buf, size_t count)
+static size_t snd_serial_generic_receive_buf(struct serdev_device *serdev,
+					     const u8 *buf, size_t count)
 {
 	int ret;
 	struct snd_serial_generic *drvdata = serdev_device_get_drvdata(serdev);

base-commit: 11651f8cb2e88372d4ed523d909514dc9a613ea3
-- 
2.25.1



From linux at armlinux.org.uk  Thu Dec 14 09:10:54 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Thu, 14 Dec 2023 17:10:54 +0000
Subject: [PATCH linux-next] ARM/dma-mapping: replace kzalloc() and
 vzalloc() with kvzalloc()
In-Reply-To: <CACRpkdb-pARMSCe_kugLOFriSrwuQVXJ3L+6TnsnmDNedowDRw@mail.gmail.com>
References: <CACRpkdap4LUbMcKv_zi=25A-SZf0DJhXiyR1zn0PfuR+b=3NfA@mail.gmail.com>
 <20231213143954.2541-1-chenguanxi11234@163.com>
 <CACRpkdb-pARMSCe_kugLOFriSrwuQVXJ3L+6TnsnmDNedowDRw@mail.gmail.com>
Message-ID: <ZXs3HmwFP9Qb0Jxj@shell.armlinux.org.uk>

On Thu, Dec 14, 2023 at 02:17:51PM +0100, Linus Walleij wrote:
> On Wed, Dec 13, 2023 at 3:41?PM <chenguanxi11234 at 163.com> wrote:
> 
> > >Looks good to me:
> > >Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> > >Please put this patch into Russell's patch tracker.
> >
> > Hello, I would like to ask, do you mean to have
> > me CC the patch email to Russell?I don't really
> > understand what patch tracker means.Thank you.
> 
> This is Russell's patch tracker:
> https://www.armlinux.org.uk/developer/patches/
> 
> Create an account, read the help text, you can submit patches
> using a web interface or through mail.

No need to create an account if submitting by email, that will happen
automatically on the successful receipt of a patch, except of course
with password access blocked until a "forgotten password" thing is
done.

However, well worth reading the bit about adding a KernelVersion: tag
somewhere in the email!

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From antonio.borneo at foss.st.com  Thu Dec 14 09:12:46 2023
From: antonio.borneo at foss.st.com (Antonio Borneo)
Date: Thu, 14 Dec 2023 18:12:46 +0100
Subject: [Linux-stm32] [PATCH 2/2] pinctrl: stm32: fix GPIO level
 interrupts
In-Reply-To: <20231204203357.2897008-3-ben.wolsieffer@hefring.com>
References: <20231204203357.2897008-1-ben.wolsieffer@hefring.com>
	 <20231204203357.2897008-3-ben.wolsieffer@hefring.com>
Message-ID: <72700f397d32f6a81164aafbf6f9d30b510672cf.camel@foss.st.com>

On Mon, 2023-12-04 at 15:33 -0500, Ben Wolsieffer wrote:
> The STM32 doesn't support GPIO level interrupts in hardware, so the
> driver tries to emulate them using edge interrupts, by retriggering the
> interrupt if necessary based on the pin state after the handler
> finishes.
> 
> Currently, this functionality does not work because the irqchip uses
> handle_edge_irq(), which doesn't run the irq_eoi() or irq_unmask()
> callbacks after handling the interrupt. This patch fixes this by using
> handle_level_irq() for level interrupts, which causes irq_unmask() to be
> called to retrigger the interrupt.
> 
> Signed-off-by: Ben Wolsieffer <ben.wolsieffer at hefring.com>
> ---
> ?drivers/pinctrl/stm32/pinctrl-stm32.c | 3 +++
> ?1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
> index 603f900e88c1..fb9532601cbb 100644
> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c
> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
> @@ -348,12 +348,15 @@ static int stm32_gpio_set_type(struct irq_data *d, unsigned int type)
> ????????case IRQ_TYPE_EDGE_RISING:
> ????????case IRQ_TYPE_EDGE_FALLING:
> ????????case IRQ_TYPE_EDGE_BOTH:
> +???????????????irq_set_handler_locked(d, handle_edge_irq);

Hi,
this patch causes a NULL pointer dereference and crashes the kernel boot on STM32 MPU's,
either STM32MP13x, STM32MP15x and the new STM32MP25x.

Please do not merge it as is.

This pinctrl-stm32 driver is shared between STM32 MCUs and MPUs.
In both cases the EXTI is the parent interrupt controller of this pinctrl, but despite
the fact that there is a single file irq-stm32-exti.c, it contains two independent
drivers, one for MCUs and the other for MPUs.
Swapping in this function the irq_desc::handle_irq between handle_edge_irq() and
handle_level_irq() is probably fine for MCU (I have not tested it).
But on MPUs the default handler is handle_fasteoi_irq(); should not be changed here.

Checking quickly ... this function calls irq_chip_set_type_parent() at the very end.
It will in turn call EXTI's irq_set_type(), which has different implementations for MCU
and MPU.
By moving this handler swap in the MCU specific stm32_irq_set_type() it will not impact
MPUs.

Best Regards,
Antonio


> ????????????????parent_type = type;
> ????????????????break;
> ????????case IRQ_TYPE_LEVEL_HIGH:
> +???????????????irq_set_handler_locked(d, handle_level_irq);
> ????????????????parent_type = IRQ_TYPE_EDGE_RISING;
> ????????????????break;
> ????????case IRQ_TYPE_LEVEL_LOW:
> +???????????????irq_set_handler_locked(d, handle_level_irq);
> ????????????????parent_type = IRQ_TYPE_EDGE_FALLING;
> ????????????????break;
> ????????default:



From jernej.skrabec at gmail.com  Thu Dec 14 09:15:01 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Thu, 14 Dec 2023 18:15:01 +0100
Subject: [PATCH 2/5] cpufreq: sun50i: Add D1 support
In-Reply-To: <20231214164010.0be50a89@donnerap.manchester.arm.com>
References: <20231214103342.30775-1-fusibrandon13@gmail.com>
 <8351928.NyiUUSuA9g@archlinux>
 <20231214164010.0be50a89@donnerap.manchester.arm.com>
Message-ID: <1921146.taCxCBeP46@archlinux>

On Thursday, December 14, 2023 5:40:10 PM CET Andre Przywara wrote:
> On Thu, 14 Dec 2023 17:29:30 +0100
> Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> 
> Hi,
> 
> > On Thursday, December 14, 2023 11:33:39 AM CET Brandon Cheo Fusi wrote:
> > > Add support for D1 based devices to the Allwinner H6 cpufreq
> > > driver
> > > 
> > > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > > ---
> > >  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > index 32a9c88f8..ccf83780f 100644
> > > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > @@ -160,6 +160,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
> > >  
> > >  static const struct of_device_id sun50i_cpufreq_match_list[] = {
> > >  	{ .compatible = "allwinner,sun50i-h6" },
> > > +	{ .compatible = "allwinner,sun20i-d1" },  
> > 
> > This is not needed, as there is no functionality change.
> 
> That was my first reflex, too, but this is the *board* (fallback)
> compatible, listed in the root node, so you have to list it here for each
> SoC, together with the respective blocklist in the next patch.
> We are doing the same for the H616, and actually also need that for the
> H618. Weird, I know, but last time I check not easy to fix.

Oh, that's bad. What's the rationale to have so complicated probe method?
Why not using standard, compatible based one?

Best regards,
Jernej





From Jonathan.Cameron at Huawei.com  Thu Dec 14 09:32:41 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Thu, 14 Dec 2023 17:32:41 +0000
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or
 functional) devices
In-Reply-To: <E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>
Message-ID: <20231214173241.0000260f@Huawei.com>

On Wed, 13 Dec 2023 12:49:16 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> Today the ACPI enumeration code 'visits' all devices that are present.
> 
> This is a problem for arm64, where CPUs are always present, but not
> always enabled. When a device-check occurs because the firmware-policy
> has changed and a CPU is now enabled, the following error occurs:
> | acpi ACPI0007:48: Enumeration failure
> 
> This is ultimately because acpi_dev_ready_for_enumeration() returns
> true for a device that is not enabled. The ACPI Processor driver
> will not register such CPUs as they are not 'decoding their resources'.
> 
> Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
> ACPI allows a device to be functional instead of maintaining the
> present and enabled bit. Make this behaviour an explicit check with
> a reference to the spec, and then check the present and enabled bits.
> This is needed to avoid enumerating present && functional devices that
> are not enabled.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> ---
> If this change causes problems on deployed hardware, I suggest an
> arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
> acpi_dev_ready_for_enumeration() to only check the present bit.

My gut feeling (having made ACPI 'fixes' in the past that ran into
horribly broken firmware and had to be reverted) is reduce the blast
radius preemptively from the start. I'd love to live in a world were
that wasn't necessary but I don't trust all the generators of ACPI tables.
I'll leave it to Rafael and other ACPI experts suggest how narrow we should
make it though - arch opt in might be narrow enough.

> 
> Changes since RFC v2:
>  * Incorporate comment suggestion by Gavin Shan.
> Other review comments from Jonathan Cameron not yet addressed.

Looking back, I think this was mainly a suggestion for a minor
possible optimization by ignoring the case of !present && enabled
when designing the logic because that's not allowed by the spec.

You made that change in v3.

Otherwise, comments were trivial comment clarifications that I'm not
that worried about.

One comment typo inline.

With assumption others will comment on when this change should be
chicken bit'd out.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>


> ---
>  drivers/acpi/device_pm.c    |  2 +-
>  drivers/acpi/device_sysfs.c |  2 +-
>  drivers/acpi/internal.h     |  1 -
>  drivers/acpi/property.c     |  2 +-
>  drivers/acpi/scan.c         | 24 ++++++++++++++----------
>  5 files changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
> index 3b4d048c4941..e3c80f3b3b57 100644
> --- a/drivers/acpi/device_pm.c
> +++ b/drivers/acpi/device_pm.c
> @@ -313,7 +313,7 @@ int acpi_bus_init_power(struct acpi_device *device)
>  		return -EINVAL;
>  
>  	device->power.state = ACPI_STATE_UNKNOWN;
> -	if (!acpi_device_is_present(device)) {
> +	if (!acpi_dev_ready_for_enumeration(device)) {
>  		device->flags.initialized = false;
>  		return -ENXIO;
>  	}
> diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
> index 23373faa35ec..a0256d2493a7 100644
> --- a/drivers/acpi/device_sysfs.c
> +++ b/drivers/acpi/device_sysfs.c
> @@ -141,7 +141,7 @@ static int create_pnp_modalias(const struct acpi_device *acpi_dev, char *modalia
>  	struct acpi_hardware_id *id;
>  
>  	/* Avoid unnecessarily loading modules for non present devices. */
> -	if (!acpi_device_is_present(acpi_dev))
> +	if (!acpi_dev_ready_for_enumeration(acpi_dev))
>  		return 0;
>  
>  	/*
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 866c7c4ed233..a1b45e345bcc 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -107,7 +107,6 @@ int acpi_device_setup_files(struct acpi_device *dev);
>  void acpi_device_remove_files(struct acpi_device *dev);
>  void acpi_device_add_finalize(struct acpi_device *device);
>  void acpi_free_pnp_ids(struct acpi_device_pnp *pnp);
> -bool acpi_device_is_present(const struct acpi_device *adev);
>  bool acpi_device_is_battery(struct acpi_device *adev);
>  bool acpi_device_is_first_physical_node(struct acpi_device *adev,
>  					const struct device *dev);
> diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> index 6979a3f9f90a..14d6948fd88a 100644
> --- a/drivers/acpi/property.c
> +++ b/drivers/acpi/property.c
> @@ -1420,7 +1420,7 @@ static bool acpi_fwnode_device_is_available(const struct fwnode_handle *fwnode)
>  	if (!is_acpi_device_node(fwnode))
>  		return false;
>  
> -	return acpi_device_is_present(to_acpi_device_node(fwnode));
> +	return acpi_dev_ready_for_enumeration(to_acpi_device_node(fwnode));
>  }
>  
>  static const void *
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 02bb2cce423f..728649a2a251 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -304,7 +304,7 @@ static int acpi_scan_device_check(struct acpi_device *adev)
>  	int error;
>  
>  	acpi_bus_get_status(adev);
> -	if (acpi_device_is_present(adev)) {
> +	if (acpi_dev_ready_for_enumeration(adev)) {
>  		/*
>  		 * This function is only called for device objects for which
>  		 * matching scan handlers exist.  The only situation in which
> @@ -338,7 +338,7 @@ static int acpi_scan_bus_check(struct acpi_device *adev, void *not_used)
>  	int error;
>  
>  	acpi_bus_get_status(adev);
> -	if (!acpi_device_is_present(adev)) {
> +	if (!acpi_dev_ready_for_enumeration(adev)) {
>  		acpi_scan_device_not_enumerated(adev);
>  		return 0;
>  	}
> @@ -1913,11 +1913,6 @@ static bool acpi_device_should_be_hidden(acpi_handle handle)
>  	return true;
>  }
>  
> -bool acpi_device_is_present(const struct acpi_device *adev)
> -{
> -	return adev->status.present || adev->status.functional;
> -}
> -
>  static bool acpi_scan_handler_matching(struct acpi_scan_handler *handler,
>  				       const char *idstr,
>  				       const struct acpi_device_id **matchid)
> @@ -2381,16 +2376,25 @@ EXPORT_SYMBOL_GPL(acpi_dev_clear_dependencies);
>   * acpi_dev_ready_for_enumeration - Check if the ACPI device is ready for enumeration
>   * @device: Pointer to the &struct acpi_device to check
>   *
> - * Check if the device is present and has no unmet dependencies.
> + * Check if the device is functional or enabled and has no unmet dependencies.
>   *
> - * Return true if the device is ready for enumeratino. Otherwise, return false.
> + * Return true if the device is ready for enumeration. Otherwise, return false.
>   */
>  bool acpi_dev_ready_for_enumeration(const struct acpi_device *device)
>  {
>  	if (device->flags.honor_deps && device->dep_unmet)
>  		return false;
>  
> -	return acpi_device_is_present(device);
> +	/*
> +	 * ACPI 6.5's 6.3.7 "_STA (Device Status)" allows firmware to return
> +	 * (!present && functional) for certain types of devices that should be
> +	 * enumerated. Note that the enabled bit can't be sert until the present

set until

> +	 * bit is set.
> +	 */
> +	if (device->status.present)
> +		return device->status.enabled;
> +	else
> +		return device->status.functional;
>  }
>  EXPORT_SYMBOL_GPL(acpi_dev_ready_for_enumeration);
>  



From Jonathan.Cameron at Huawei.com  Thu Dec 14 09:36:26 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Thu, 14 Dec 2023 17:36:26 +0000
Subject: [PATCH RFC v3 02/21] ACPI: processor: Add support for
 processors described as container packages
In-Reply-To: <E1rDOfx-00Dvje-MS@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOfx-00Dvje-MS@rmk-PC.armlinux.org.uk>
Message-ID: <20231214173626.00005062@Huawei.com>

On Wed, 13 Dec 2023 12:49:21 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> ACPI has two ways of describing processors in the DSDT. From ACPI v6.5,
> 5.2.12:
> 
> "Starting with ACPI Specification 6.3, the use of the Processor() object
> was deprecated. Only legacy systems should continue with this usage. On
> the Itanium architecture only, a _UID is provided for the Processor()
> that is a string object. This usage of _UID is also deprecated since it
> can preclude an OSPM from being able to match a processor to a
> non-enumerable device, such as those defined in the MADT. From ACPI
> Specification 6.3 onward, all processor objects for all architectures
> except Itanium must now use Device() objects with an _HID of ACPI0007,
> and use only integer _UID values."
> 
> Also see https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html#declaring-processors
> 
> Duplicate descriptions are not allowed, the ACPI processor driver already
> parses the UID from both devices and containers. acpi_processor_get_info()
> returns an error if the UID exists twice in the DSDT.
> 
> The missing probe for CPUs described as packages creates a problem for
> moving the cpu_register() calls into the acpi_processor driver, as CPUs
> described like this don't get registered, leading to errors from other
> subsystems when they try to add new sysfs entries to the CPU node.
> (e.g. topology_sysfs_init()'s use of topology_add_dev() via cpuhp)
> 
> To fix this, parse the processor container and call acpi_processor_add()
> for each processor that is discovered like this. The processor container
> handler is added with acpi_scan_add_handler(), so no detach call will
> arrive.
> 
> Qemu TCG describes CPUs using processor devices in a processor container.
> For more information, see build_cpus_aml() in Qemu hw/acpi/cpu.c and
> https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html#processor-container-device
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> ---
> Outstanding comments:
>  https://lore.kernel.org/r/20230914145353.000072e2 at Huawei.com
Looks like you resolved those (were all patch description things).

So I'm happy.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

Thanks,

J
>  https://lore.kernel.org/r/50571c2f-aa3c-baeb-3add-cd59e0eddc02 at redhat.com
> ---
>  drivers/acpi/acpi_processor.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index 4fe2ef54088c..6a542e0ce396 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -626,9 +626,31 @@ static struct acpi_scan_handler processor_handler = {
>  	},
>  };
>  
> +static acpi_status acpi_processor_container_walk(acpi_handle handle,
> +						 u32 lvl,
> +						 void *context,
> +						 void **rv)
> +{
> +	struct acpi_device *adev;
> +	acpi_status status;
> +
> +	adev = acpi_get_acpi_dev(handle);
> +	if (!adev)
> +		return AE_ERROR;
> +
> +	status = acpi_processor_add(adev, &processor_device_ids[0]);
> +	acpi_put_acpi_dev(adev);
> +
> +	return status;
> +}
> +
>  static int acpi_processor_container_attach(struct acpi_device *dev,
>  					   const struct acpi_device_id *id)
>  {
> +	acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle,
> +			    ACPI_UINT32_MAX, acpi_processor_container_walk,
> +			    NULL, NULL, NULL);
> +
>  	return 1;
>  }
>  



From Jonathan.Cameron at Huawei.com  Thu Dec 14 09:38:02 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Thu, 14 Dec 2023 17:38:02 +0000
Subject: [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from
 acpi_processor_get_info()
In-Reply-To: <E1rDOg7-00Dvjq-VZ@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOg7-00Dvjq-VZ@rmk-PC.armlinux.org.uk>
Message-ID: <20231214173802.000001fb@Huawei.com>

On Wed, 13 Dec 2023 12:49:31 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> To allow ACPI to skip the call to arch_register_cpu() when the _STA
> value indicates the CPU can't be brought online right now, move the
> arch_register_cpu() call into acpi_processor_get_info().
> 
> Systems can still be booted with 'acpi=off', or not include an
> ACPI description at all. For these, the CPUs continue to be
> registered by cpu_dev_register_generic().
> 
> This moves the CPU register logic back to a subsys_initcall(),
> while the memory nodes will have been registered earlier.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Reviewed-by: Gavin Shan <gshan at redhat.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
LGTM as well.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>


From francesco at dolcini.it  Thu Dec 14 09:39:44 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Thu, 14 Dec 2023 18:39:44 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <20231214170146.641783-1-francesco@dolcini.it>
References: <20231214170146.641783-1-francesco@dolcini.it>
Message-ID: <ZXs94Mf1eOMCmGpT@francesco-nb.int.toradex.com>

On Thu, Dec 14, 2023 at 06:01:46PM +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> receive_buf() is called from ttyport_receive_buf() that expects values
> ">= 0" from serdev_controller_receive_buf(), change its return type from
> ssize_t to size_t.
> 
> Suggested-by: Jiri Slaby <jirislaby at kernel.org>
> Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
> Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> ---
> hello,
> patch is based on current linux next.
> 
> It has an obvious problem, it touches files from multiple subsystem in a single
> patch that is complicated to review and eventually merge, just splitting this
> would however not work, it will break bisectability and the build.
> 
> I am looking for advise on the best way to move forward.
> 
> I see the following options:
>  - keep it as it is
>  - break it down with a patch with each subsystem, and squash before applying
>    from a single (tty?) subsystem
>  - go for a multi stage approach, defining a new callback, move to it and in
>    the end remove the original one, likewise it was done for i2c lately

whoops. I just noticed Greg applied commit 475fc6e2de6f ("tty: serdev:
convert to u8 and size_t") that touch the exact same files without much
of an issue.

Probably the "keep it as it is" is just the way to go.

> 
> ---
>  drivers/bluetooth/btmtkuart.c              |  4 ++--
>  drivers/bluetooth/btnxpuart.c              |  4 ++--
>  drivers/bluetooth/hci_serdev.c             |  4 ++--
>  drivers/gnss/core.c                        |  6 +++---
>  drivers/gnss/serial.c                      |  4 ++--
>  drivers/gnss/sirf.c                        |  6 +++---
>  drivers/greybus/gb-beagleplay.c            |  6 +++---
>  drivers/iio/chemical/pms7003.c             |  4 ++--
>  drivers/iio/chemical/scd30_serial.c        |  4 ++--
>  drivers/iio/chemical/sps30_serial.c        |  4 ++--
>  drivers/iio/imu/bno055/bno055_ser_core.c   |  4 ++--
>  drivers/mfd/rave-sp.c                      |  4 ++--
>  drivers/net/ethernet/qualcomm/qca_uart.c   |  2 +-
>  drivers/nfc/pn533/uart.c                   |  4 ++--
>  drivers/nfc/s3fwrn5/uart.c                 |  4 ++--
>  drivers/platform/chrome/cros_ec_uart.c     |  4 ++--
>  drivers/platform/surface/aggregator/core.c |  4 ++--
>  drivers/tty/serdev/serdev-ttyport.c        | 10 ++++------
>  include/linux/gnss.h                       |  4 ++--
>  include/linux/serdev.h                     |  8 ++++----
>  sound/drivers/serial-generic.c             |  4 ++--
>  21 files changed, 48 insertions(+), 50 deletions(-)


From Jonathan.Cameron at Huawei.com  Thu Dec 14 09:41:07 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Thu, 14 Dec 2023 17:41:07 +0000
Subject: [PATCH RFC v3 05/21] ACPI: Rename ACPI_HOTPLUG_CPU to include
 'present'
In-Reply-To: <E1rDOgD-00Dvk2-3h@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOgD-00Dvk2-3h@rmk-PC.armlinux.org.uk>
Message-ID: <20231214174107.0000171f@Huawei.com>

On Wed, 13 Dec 2023 12:49:37 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> The code behind ACPI_HOTPLUG_CPU allows a not-present CPU to become
> present. This isn't the only use of HOTPLUG_CPU. On arm64 and riscv
> CPUs can be taken offline as a power saving measure.
> 
> On arm64 an offline CPU may be disabled by firmware, preventing it from
> being brought back online, but it remains present throughout.
> 
> Adding code to prevent user-space trying to online these disabled CPUs
> needs some additional terminology.
> 
> Rename the Kconfig symbol CONFIG_ACPI_HOTPLUG_PRESENT_CPU to reflect
> that it makes possible CPUs present.
> 
> HOTPLUG_CPU is untouched as this is only about the ACPI mechanism.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
Formatting nitpick inline. Either way FWIW:
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 4db54e928b36..36071bc11acd 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h

>  #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
>  int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);
> @@ -629,7 +629,7 @@ static inline u32 acpi_osc_ctx_get_cxl_control(struct acpi_osc_context *context)
>  #define ACPI_GSB_ACCESS_ATTRIB_RAW_PROCESS	0x0000000F
>  
>  /* Enable _OST when all relevant hotplug operations are enabled */
> -#if defined(CONFIG_ACPI_HOTPLUG_CPU) &&			\
> +#if defined(CONFIG_ACPI_HOTPLUG_PRESENT_CPU) &&			\

Trivial but I think there is a tab to many before that \

>  	defined(CONFIG_ACPI_HOTPLUG_MEMORY) &&		\
>  	defined(CONFIG_ACPI_CONTAINER)
>  #define ACPI_HOTPLUG_OST



From Jonathan.Cameron at Huawei.com  Thu Dec 14 09:43:37 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Thu, 14 Dec 2023 17:43:37 +0000
Subject: [PATCH RFC v3 07/21] ACPI: Rename acpi_processor_hotadd_init
 and remove pre-processor guards
In-Reply-To: <E1rDOgN-00DvkE-D8@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOgN-00DvkE-D8@rmk-PC.armlinux.org.uk>
Message-ID: <20231214174337.000042a4@Huawei.com>

On Wed, 13 Dec 2023 12:49:47 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> acpi_processor_hotadd_init() will make a CPU present by mapping it
> based on its hardware id.
> 
> 'hotadd_init' is ambiguous once there are two different behaviours
> for cpu hotplug. This is for toggling the _STA present bit. Subsequent
> patches will add support for toggling the _STA enabled bit, named
> acpi_processor_make_enabled().
> 
> Rename it acpi_processor_make_present() to make it clear this is
> for CPUs that were not previously present.
> 
> Expose the function prototypes it uses to allow the preprocessor
> guards to be removed. The IS_ENABLED() check will let the compiler
> dead-code elimination pass remove this if it isn't going to be
> used.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> ---
> Outstanding comments:
>  https://lore.kernel.org/r/20230914151720.00007105 at Huawei.com

If it's not caused a build warning yet, chances are high this is fine.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

>  https://lore.kernel.org/r/b8f430c1-c30f-191f-18c6-f750fa6ba476 at redhat.com
>   For this comment, we use IS_ENABLED() in multiple places in the kernel in
>   this way, and it isn't a problem.
> ---
>  drivers/acpi/acpi_processor.c | 14 +++++---------
>  include/linux/acpi.h          |  2 --
>  2 files changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index c8e960ff0aca..26e3efb74614 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -183,13 +183,15 @@ static void __init acpi_pcc_cpufreq_init(void) {}
>  #endif /* CONFIG_X86 */
>  
>  /* Initialization */
> -#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
> -static int acpi_processor_hotadd_init(struct acpi_processor *pr)
> +static int acpi_processor_make_present(struct acpi_processor *pr)
>  {
>  	unsigned long long sta;
>  	acpi_status status;
>  	int ret;
>  
> +	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
> +		return -ENODEV;
> +
>  	if (invalid_phys_cpuid(pr->phys_id))
>  		return -ENODEV;
>  
> @@ -223,12 +225,6 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
>  	cpu_maps_update_done();
>  	return ret;
>  }
> -#else
> -static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
> -{
> -	return -ENODEV;
> -}
> -#endif /* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
>  
>  static int acpi_processor_get_info(struct acpi_device *device)
>  {
> @@ -335,7 +331,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
>  	 *  because cpuid <-> apicid mapping is persistent now.
>  	 */
>  	if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
> -		int ret = acpi_processor_hotadd_init(pr);
> +		int ret = acpi_processor_make_present(pr);
>  
>  		if (ret)
>  			return ret;
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 36071bc11acd..19d009ca9e7a 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -301,12 +301,10 @@ static inline int acpi_processor_evaluate_cst(acpi_handle handle, u32 cpu,
>  }
>  #endif
>  
> -#ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU
>  /* Arch dependent functions for cpu hotplug support */
>  int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 acpi_id,
>  		 int *pcpu);
>  int acpi_unmap_cpu(int cpu);
> -#endif /* CONFIG_ACPI_HOTPLUG_PRESENT_CPU */
>  
>  #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
>  int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);



From rafael at kernel.org  Thu Dec 14 09:47:00 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Thu, 14 Dec 2023 18:47:00 +0100
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or functional) devices
In-Reply-To: <20231214173241.0000260f@Huawei.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk> <E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>
 <20231214173241.0000260f@Huawei.com>
Message-ID: <CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>

On Thu, Dec 14, 2023 at 6:32?PM Jonathan Cameron
<Jonathan.Cameron at huawei.com> wrote:
>
> On Wed, 13 Dec 2023 12:49:16 +0000
> Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
>
> > From: James Morse <james.morse at arm.com>
> >
> > Today the ACPI enumeration code 'visits' all devices that are present.
> >
> > This is a problem for arm64, where CPUs are always present, but not
> > always enabled. When a device-check occurs because the firmware-policy
> > has changed and a CPU is now enabled, the following error occurs:
> > | acpi ACPI0007:48: Enumeration failure
> >
> > This is ultimately because acpi_dev_ready_for_enumeration() returns
> > true for a device that is not enabled. The ACPI Processor driver
> > will not register such CPUs as they are not 'decoding their resources'.
> >
> > Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
> > ACPI allows a device to be functional instead of maintaining the
> > present and enabled bit. Make this behaviour an explicit check with
> > a reference to the spec, and then check the present and enabled bits.
> > This is needed to avoid enumerating present && functional devices that
> > are not enabled.
> >
> > Signed-off-by: James Morse <james.morse at arm.com>
> > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > ---
> > If this change causes problems on deployed hardware, I suggest an
> > arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
> > acpi_dev_ready_for_enumeration() to only check the present bit.
>
> My gut feeling (having made ACPI 'fixes' in the past that ran into
> horribly broken firmware and had to be reverted) is reduce the blast
> radius preemptively from the start. I'd love to live in a world were
> that wasn't necessary but I don't trust all the generators of ACPI tables.
> I'll leave it to Rafael and other ACPI experts suggest how narrow we should
> make it though - arch opt in might be narrow enough.

A chicken bit wouldn't help much IMO, especially in the cases when
working setups get broken.

I would very much prefer to limit the scope of it, say to processors
only, in the first place.


From claudiu.beznea at tuxon.dev  Thu Dec 14 09:48:30 2023
From: claudiu.beznea at tuxon.dev (Claudiu Beznea)
Date: Thu, 14 Dec 2023 19:48:30 +0200
Subject: [GIT PULL] Microchip AT91 SoC updates for v6.8
Message-ID: <20231214174830.3045180-1-claudiu.beznea@tuxon.dev>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-soc-6.8

for you to fetch changes up to aa1cfba75b77ca93ab9a0b03c2c9124a16d96479:

  ARM: at91: pm: set soc_pm.data.mode in at91_pm_secure_init() (2023-11-19 11:32:44 +0200)

----------------------------------------------------------------
Microchip AT91 SoC updates for v6.8

It contains:
- one patch for secure mode to set the target power management mode in
  initialization process as at91_pm_begin() is not called on suspend
  path while in secure mode; this is necessary for different drivers to
  know which suspend mode the system is going to switch to and act
  accordingly

----------------------------------------------------------------
Thomas Perrot (1):
      ARM: at91: pm: set soc_pm.data.mode in at91_pm_secure_init()

 arch/arm/mach-at91/pm.c | 3 +++
 1 file changed, 3 insertions(+)


From claudiu.beznea at tuxon.dev  Thu Dec 14 09:49:54 2023
From: claudiu.beznea at tuxon.dev (Claudiu Beznea)
Date: Thu, 14 Dec 2023 19:49:54 +0200
Subject: [GIT PULL] Microchip AT91 DT updates for v6.8
Message-ID: <20231214174954.3045355-1-claudiu.beznea@tuxon.dev>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-dt-6.8

for you to fetch changes up to abe18175269ac8433c9cd52efd72d16b1731d479:

  ARM: dts: microchip: sama5d27_som1_ek: Remove mmc-ddr-3_3v property from sdmmc0 node (2023-12-12 17:52:50 +0200)

----------------------------------------------------------------
Microchip AT91 device tree updates for v6.8

It contains:
- IRQ support for Ethernet PHYs on SAM9X60-EK and SAM9X60-Curiosity
  boards
- removal of the mmc-ddr-3_3v property from SD controllers connected to SD
  slots, for SAMA5D27-WLSOM1-EK and SAMA5D27-SOM1-EK boards, as this
  property is for eMMC devices

----------------------------------------------------------------
Mihai Sain (4):
      ARM: dts: microchip: sam9x60_curiosity: Add IRQ support for ethernet PHY
      ARM: dts: microchip: sam9x60ek: Add IRQ support for ethernet PHY
      ARM: dts: microchip: sama5d27_wlsom1_ek: Remove mmc-ddr-3_3v property from sdmmc0 node
      ARM: dts: microchip: sama5d27_som1_ek: Remove mmc-ddr-3_3v property from sdmmc0 node

 arch/arm/boot/dts/microchip/at91-sam9x60_curiosity.dts  | 3 +++
 arch/arm/boot/dts/microchip/at91-sam9x60ek.dts          | 3 +++
 arch/arm/boot/dts/microchip/at91-sama5d27_som1_ek.dts   | 1 -
 arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts | 1 -
 4 files changed, 6 insertions(+), 2 deletions(-)


From macpaul.lin at mediatek.com  Thu Dec 14 09:54:19 2023
From: macpaul.lin at mediatek.com (Macpaul Lin)
Date: Fri, 15 Dec 2023 01:54:19 +0800
Subject: [PATCH] arm64: mediatek: remove broken pmic interrupt property
In-Reply-To: <bc5dafe4-5487-4794-97f1-f4e4d967a665@collabora.com>
References: <20231212214737.230115-1-arnd@kernel.org>
 <bc5dafe4-5487-4794-97f1-f4e4d967a665@collabora.com>
Message-ID: <1ce43346-3f60-b614-cdcc-7d9db8dec758@mediatek.com>

On 12/13/23 19:09, AngeloGioacchino Del Regno wrote:

> Il 12/12/23 22:47, Arnd Bergmann ha scritto:
>> From: Arnd Bergmann <arnd at arndb.de>
>>
>> The pmic is connected to the GIC, which uses four-cell interrupt 
>> properties,
>> but its interrupt is specified as two-cell that would only make sense 
>> for
>> the GPIO irqchip:
>>
>> arch/arm64/boot/dts/mediatek/mt8195.dtsi:464.4-27: Warning 
>> (interrupts_property): /soc/i2c at 11d01000/pmic at 34:#interrupt-cells: 
>> size is (8), expected multiple of 16
>>
>> Remove the interrupt for now to shut up the warning. When someone 
>> figures out
>> what the correct interrupt and parent are, we can add it back.
>>
>
> Please, can anyone from MediaTek comment on that?

Sorry for late response, I've just stuck in other tasks and didn't 
notice this

patch is for genio-1200-evk. I've tested 6.7-rc1 but I thought it might 
be an issue

in origin mt8195.dtsi and not be related to board dts.

> I see a mt6360_pins on PIO:
> ??????????? pinmux = <PINMUX_GPIO17__FUNC_GPIO17>,
> ???????????????? <PINMUX_GPIO128__FUNC_GPIO128>;
>
> ...and that's GPIO128, which may effectively be the IRQ pin for MT6360.
>
> Still, I'm not sure whether the interrupt is on GIC or PIO, please 
> clarify,
> otherwise we will have to get this commit upstream.
>
I think it could be solved by adding

'interrupt-parent = <&pio>;' to mt6360 node.

But currently I have no much time to verify it.

I'll try to find some time to find out the solution tomorrow.

> Thanks,
> Angelo
>
>> Fixes: f2b543a191b6 ("arm64: dts: mediatek: add device-tree for Genio 
>> 1200 EVK board")
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> ---
>> ? arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts | 2 --
>> ? 1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts 
>> b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
>> index 70b465f7c6a7..a409ef998746 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
>> @@ -238,8 +238,6 @@ &i2c6 {
>> ????? mt6360: pmic at 34 {
>> ????????? compatible = "mediatek,mt6360";
>> ????????? reg = <0x34>;
>> -??????? interrupts = <128 IRQ_TYPE_EDGE_FALLING>;
>> -??????? interrupt-names = "IRQB";
>> ????????? interrupt-controller;
>> ????????? #interrupt-cells = <1>;
>> ????????? pinctrl-0 = <&mt6360_pins>;
>

Thanks for pointing out the issue! Let's see if it could be solved by 
adding 'interrupt-parents'.

Macpaul Lin



From linux at armlinux.org.uk  Thu Dec 14 09:55:14 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Thu, 14 Dec 2023 17:55:14 +0000
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or
 functional) devices
In-Reply-To: <20231214173241.0000260f@Huawei.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>
 <20231214173241.0000260f@Huawei.com>
Message-ID: <ZXtBgtB8FXs8ge0h@shell.armlinux.org.uk>

On Thu, Dec 14, 2023 at 05:32:41PM +0000, Jonathan Cameron wrote:
> On Wed, 13 Dec 2023 12:49:16 +0000
> Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> 
> > From: James Morse <james.morse at arm.com>
> > 
> > Today the ACPI enumeration code 'visits' all devices that are present.
> > 
> > This is a problem for arm64, where CPUs are always present, but not
> > always enabled. When a device-check occurs because the firmware-policy
> > has changed and a CPU is now enabled, the following error occurs:
> > | acpi ACPI0007:48: Enumeration failure
> > 
> > This is ultimately because acpi_dev_ready_for_enumeration() returns
> > true for a device that is not enabled. The ACPI Processor driver
> > will not register such CPUs as they are not 'decoding their resources'.
> > 
> > Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
> > ACPI allows a device to be functional instead of maintaining the
> > present and enabled bit. Make this behaviour an explicit check with
> > a reference to the spec, and then check the present and enabled bits.
> > This is needed to avoid enumerating present && functional devices that
> > are not enabled.
> > 
> > Signed-off-by: James Morse <james.morse at arm.com>
> > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > ---
> > If this change causes problems on deployed hardware, I suggest an
> > arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
> > acpi_dev_ready_for_enumeration() to only check the present bit.
> 
> My gut feeling (having made ACPI 'fixes' in the past that ran into
> horribly broken firmware and had to be reverted) is reduce the blast
> radius preemptively from the start. I'd love to live in a world were
> that wasn't necessary but I don't trust all the generators of ACPI tables.
> I'll leave it to Rafael and other ACPI experts suggest how narrow we should
> make it though - arch opt in might be narrow enough.

Yes, I think an arch opt-in would be the most sensible way forward, if
Rafael concurs with that idea. I notice that what I wrote there was
actually an opt-out. I'll fix that.

> > +	/*
> > +	 * ACPI 6.5's 6.3.7 "_STA (Device Status)" allows firmware to return
> > +	 * (!present && functional) for certain types of devices that should be
> > +	 * enumerated. Note that the enabled bit can't be sert until the present
> 
> set until

Thanks for spotting that, fixed.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From robh at kernel.org  Thu Dec 14 09:55:52 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 14 Dec 2023 11:55:52 -0600
Subject: [PATCH v2 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
 <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
Message-ID: <170257655252.646649.16048051740823218749.robh@kernel.org>


On Thu, 14 Dec 2023 16:31:07 +0000, Robin Murphy wrote:
> Add a binding for implementations of the Arm CoreSight Performance
> Monitoring Unit Architecture. Not to be confused with CoreSight debug
> and trace, the PMU architecture defines a standard MMIO interface for
> event counters following a similar design to the CPU PMU architecture,
> where the implementation and most of its features are discoverable
> through ID registers.
> 
> CC: Rob Herring <robh+dt at kernel.org>
> CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
> CC: Conor Dooley <conor+dt at kernel.org>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
> v2: Use reg-io-width instead of a new property; tweak descriptions
> ---
>  .../bindings/perf/arm,coresight-pmu.yaml      | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml:27:111: [warning] line too long (114 > 110 characters) (line-length)

dtschema/dtc warnings/errors:

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy at arm.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From linux at armlinux.org.uk  Thu Dec 14 09:57:19 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Thu, 14 Dec 2023 17:57:19 +0000
Subject: [PATCH RFC v3 02/21] ACPI: processor: Add support for processors
 described as container packages
In-Reply-To: <20231214173626.00005062@Huawei.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOfx-00Dvje-MS@rmk-PC.armlinux.org.uk>
 <20231214173626.00005062@Huawei.com>
Message-ID: <ZXtB/+2kDtaz1Zf4@shell.armlinux.org.uk>

On Thu, Dec 14, 2023 at 05:36:26PM +0000, Jonathan Cameron wrote:
> On Wed, 13 Dec 2023 12:49:21 +0000
> Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> 
> > From: James Morse <james.morse at arm.com>
> > 
> > ACPI has two ways of describing processors in the DSDT. From ACPI v6.5,
> > 5.2.12:
> > 
> > "Starting with ACPI Specification 6.3, the use of the Processor() object
> > was deprecated. Only legacy systems should continue with this usage. On
> > the Itanium architecture only, a _UID is provided for the Processor()
> > that is a string object. This usage of _UID is also deprecated since it
> > can preclude an OSPM from being able to match a processor to a
> > non-enumerable device, such as those defined in the MADT. From ACPI
> > Specification 6.3 onward, all processor objects for all architectures
> > except Itanium must now use Device() objects with an _HID of ACPI0007,
> > and use only integer _UID values."
> > 
> > Also see https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html#declaring-processors
> > 
> > Duplicate descriptions are not allowed, the ACPI processor driver already
> > parses the UID from both devices and containers. acpi_processor_get_info()
> > returns an error if the UID exists twice in the DSDT.
> > 
> > The missing probe for CPUs described as packages creates a problem for
> > moving the cpu_register() calls into the acpi_processor driver, as CPUs
> > described like this don't get registered, leading to errors from other
> > subsystems when they try to add new sysfs entries to the CPU node.
> > (e.g. topology_sysfs_init()'s use of topology_add_dev() via cpuhp)
> > 
> > To fix this, parse the processor container and call acpi_processor_add()
> > for each processor that is discovered like this. The processor container
> > handler is added with acpi_scan_add_handler(), so no detach call will
> > arrive.
> > 
> > Qemu TCG describes CPUs using processor devices in a processor container.
> > For more information, see build_cpus_aml() in Qemu hw/acpi/cpu.c and
> > https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html#processor-container-device
> > 
> > Signed-off-by: James Morse <james.morse at arm.com>
> > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > ---
> > Outstanding comments:
> >  https://lore.kernel.org/r/20230914145353.000072e2 at Huawei.com
> Looks like you resolved those (were all patch description things).
> 
> So I'm happy.
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

Great, I wasn't sure if I had resolved them to your satisfaction, so I
kept the reference to your original review. I've now removed it and
added your r-b. Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From linux at armlinux.org.uk  Thu Dec 14 10:00:30 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Thu, 14 Dec 2023 18:00:30 +0000
Subject: [PATCH RFC v3 05/21] ACPI: Rename ACPI_HOTPLUG_CPU to include
 'present'
In-Reply-To: <20231214174107.0000171f@Huawei.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOgD-00Dvk2-3h@rmk-PC.armlinux.org.uk>
 <20231214174107.0000171f@Huawei.com>
Message-ID: <ZXtCvstY9eWzUhzX@shell.armlinux.org.uk>

On Thu, Dec 14, 2023 at 05:41:07PM +0000, Jonathan Cameron wrote:
> > Signed-off-by: James Morse <james.morse at arm.com>
> > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> Formatting nitpick inline. Either way FWIW:
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

Thanks, but you're absolutely correct about the nitpick, so I've fixed
that too!

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From linux at armlinux.org.uk  Thu Dec 14 10:03:47 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Thu, 14 Dec 2023 18:03:47 +0000
Subject: [PATCH RFC v3 07/21] ACPI: Rename acpi_processor_hotadd_init and
 remove pre-processor guards
In-Reply-To: <20231214174337.000042a4@Huawei.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOgN-00DvkE-D8@rmk-PC.armlinux.org.uk>
 <20231214174337.000042a4@Huawei.com>
Message-ID: <ZXtDg1TdetEqBA8S@shell.armlinux.org.uk>

On Thu, Dec 14, 2023 at 05:43:37PM +0000, Jonathan Cameron wrote:
> On Wed, 13 Dec 2023 12:49:47 +0000
> Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> 
> > From: James Morse <james.morse at arm.com>
> > 
> > acpi_processor_hotadd_init() will make a CPU present by mapping it
> > based on its hardware id.
> > 
> > 'hotadd_init' is ambiguous once there are two different behaviours
> > for cpu hotplug. This is for toggling the _STA present bit. Subsequent
> > patches will add support for toggling the _STA enabled bit, named
> > acpi_processor_make_enabled().
> > 
> > Rename it acpi_processor_make_present() to make it clear this is
> > for CPUs that were not previously present.
> > 
> > Expose the function prototypes it uses to allow the preprocessor
> > guards to be removed. The IS_ENABLED() check will let the compiler
> > dead-code elimination pass remove this if it isn't going to be
> > used.
> > 
> > Signed-off-by: James Morse <james.morse at arm.com>
> > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > ---
> > Outstanding comments:
> >  https://lore.kernel.org/r/20230914151720.00007105 at Huawei.com
> 
> If it's not caused a build warning yet, chances are high this is fine.
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> 
> >  https://lore.kernel.org/r/b8f430c1-c30f-191f-18c6-f750fa6ba476 at redhat.com
> >   For this comment, we use IS_ENABLED() in multiple places in the kernel in
> >   this way, and it isn't a problem.

Yes, for both of these comments, I think they aren't something that
needs any action - these patches have been published in my tree since
October, and that is subject to the kernel build bot which hasn't found
any issues.

So, I'll add your r-b, add my s-o-b, and remove the "outstanding
comments" from this patch.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From linux at armlinux.org.uk  Thu Dec 14 10:10:13 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Thu, 14 Dec 2023 18:10:13 +0000
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or
 functional) devices
In-Reply-To: <CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>
 <20231214173241.0000260f@Huawei.com>
 <CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>
Message-ID: <ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk>

On Thu, Dec 14, 2023 at 06:47:00PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 14, 2023 at 6:32?PM Jonathan Cameron
> <Jonathan.Cameron at huawei.com> wrote:
> >
> > On Wed, 13 Dec 2023 12:49:16 +0000
> > Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> >
> > > From: James Morse <james.morse at arm.com>
> > >
> > > Today the ACPI enumeration code 'visits' all devices that are present.
> > >
> > > This is a problem for arm64, where CPUs are always present, but not
> > > always enabled. When a device-check occurs because the firmware-policy
> > > has changed and a CPU is now enabled, the following error occurs:
> > > | acpi ACPI0007:48: Enumeration failure
> > >
> > > This is ultimately because acpi_dev_ready_for_enumeration() returns
> > > true for a device that is not enabled. The ACPI Processor driver
> > > will not register such CPUs as they are not 'decoding their resources'.
> > >
> > > Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
> > > ACPI allows a device to be functional instead of maintaining the
> > > present and enabled bit. Make this behaviour an explicit check with
> > > a reference to the spec, and then check the present and enabled bits.
> > > This is needed to avoid enumerating present && functional devices that
> > > are not enabled.
> > >
> > > Signed-off-by: James Morse <james.morse at arm.com>
> > > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > > ---
> > > If this change causes problems on deployed hardware, I suggest an
> > > arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
> > > acpi_dev_ready_for_enumeration() to only check the present bit.
> >
> > My gut feeling (having made ACPI 'fixes' in the past that ran into
> > horribly broken firmware and had to be reverted) is reduce the blast
> > radius preemptively from the start. I'd love to live in a world were
> > that wasn't necessary but I don't trust all the generators of ACPI tables.
> > I'll leave it to Rafael and other ACPI experts suggest how narrow we should
> > make it though - arch opt in might be narrow enough.
> 
> A chicken bit wouldn't help much IMO, especially in the cases when
> working setups get broken.
> 
> I would very much prefer to limit the scope of it, say to processors
> only, in the first place.

Thanks for the feedback and the idea.

I guess we need something like:

	if (device->status.present)
		return device->device_type != ACPI_BUS_TYPE_PROCESSOR ||
		       device->status.enabled;
	else
		return device->status.functional;

so we only check device->status.enabled for processor-type devices?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From lkp at intel.com  Thu Dec 14 10:08:32 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 15 Dec 2023 02:08:32 +0800
Subject: [PATCH 2/3] usb: xhci-mtk: fix a short packet issue of gen1
 isoc-in transfer
In-Reply-To: <20231213063543.12435-2-chunfeng.yun@mediatek.com>
References: <20231213063543.12435-2-chunfeng.yun@mediatek.com>
Message-ID: <202312150146.ffBFCrhf-lkp@intel.com>

Hi Chunfeng,

kernel test robot noticed the following build errors:

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on usb/usb-next usb/usb-linus robh/for-next krzk/for-next linus/master v6.7-rc5 next-20231214]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Chunfeng-Yun/usb-xhci-mtk-fix-a-short-packet-issue-of-gen1-isoc-in-transfer/20231213-143959
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
patch link:    https://lore.kernel.org/r/20231213063543.12435-2-chunfeng.yun%40mediatek.com
patch subject: [PATCH 2/3] usb: xhci-mtk: fix a short packet issue of gen1 isoc-in transfer
config: openrisc-allyesconfig (https://download.01.org/0day-ci/archive/20231215/202312150146.ffBFCrhf-lkp at intel.com/config)
compiler: or1k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231215/202312150146.ffBFCrhf-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312150146.ffBFCrhf-lkp at intel.com/

All errors (new ones prefixed by >>):

   drivers/usb/host/xhci-mtk.c: In function 'xhci_mtk_rxfifo_depth_set':
>> drivers/usb/host/xhci-mtk.c:184:26: error: implicit declaration of function 'FIELD_PREP' [-Werror=implicit-function-declaration]
     184 |                 value |= FIELD_PREP(SCH3_RXFIFO_DEPTH_MASK, 2);
         |                          ^~~~~~~~~~
   cc1: some warnings being treated as errors


vim +/FIELD_PREP +184 drivers/usb/host/xhci-mtk.c

   170	
   171	/*
   172	 * workaround: usb3.2 gen1 isoc rx hw issue
   173	 * host send out unexpected ACK afer device fininsh a burst transfer with
   174	 * a short packet.
   175	 */
   176	static void xhci_mtk_rxfifo_depth_set(struct xhci_hcd_mtk *mtk)
   177	{
   178		struct usb_hcd *hcd = mtk->hcd;
   179		u32 value;
   180	
   181		if (mtk->rxfifo_depth_quirk) {
   182			value = readl(hcd->regs + HSCH_CFG1);
   183			value &= ~SCH3_RXFIFO_DEPTH_MASK;
 > 184			value |= FIELD_PREP(SCH3_RXFIFO_DEPTH_MASK, 2);
   185			writel(value, hcd->regs + HSCH_CFG1);
   186		}
   187	}
   188	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From rafael at kernel.org  Thu Dec 14 10:16:02 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Thu, 14 Dec 2023 19:16:02 +0100
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or functional) devices
In-Reply-To: <ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk> <E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>
 <20231214173241.0000260f@Huawei.com> <CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>
 <ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk>
Message-ID: <CAJZ5v0h2Keyb-gFWFuPsKtwqjXvM2snyGpo6MMfFzaXKbfEpgw@mail.gmail.com>

On Thu, Dec 14, 2023 at 7:10?PM Russell King (Oracle)
<linux at armlinux.org.uk> wrote:
>
> On Thu, Dec 14, 2023 at 06:47:00PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Dec 14, 2023 at 6:32?PM Jonathan Cameron
> > <Jonathan.Cameron at huawei.com> wrote:
> > >
> > > On Wed, 13 Dec 2023 12:49:16 +0000
> > > Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> > >
> > > > From: James Morse <james.morse at arm.com>
> > > >
> > > > Today the ACPI enumeration code 'visits' all devices that are present.
> > > >
> > > > This is a problem for arm64, where CPUs are always present, but not
> > > > always enabled. When a device-check occurs because the firmware-policy
> > > > has changed and a CPU is now enabled, the following error occurs:
> > > > | acpi ACPI0007:48: Enumeration failure
> > > >
> > > > This is ultimately because acpi_dev_ready_for_enumeration() returns
> > > > true for a device that is not enabled. The ACPI Processor driver
> > > > will not register such CPUs as they are not 'decoding their resources'.
> > > >
> > > > Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
> > > > ACPI allows a device to be functional instead of maintaining the
> > > > present and enabled bit. Make this behaviour an explicit check with
> > > > a reference to the spec, and then check the present and enabled bits.
> > > > This is needed to avoid enumerating present && functional devices that
> > > > are not enabled.
> > > >
> > > > Signed-off-by: James Morse <james.morse at arm.com>
> > > > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > > > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > > > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > > > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > > > ---
> > > > If this change causes problems on deployed hardware, I suggest an
> > > > arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
> > > > acpi_dev_ready_for_enumeration() to only check the present bit.
> > >
> > > My gut feeling (having made ACPI 'fixes' in the past that ran into
> > > horribly broken firmware and had to be reverted) is reduce the blast
> > > radius preemptively from the start. I'd love to live in a world were
> > > that wasn't necessary but I don't trust all the generators of ACPI tables.
> > > I'll leave it to Rafael and other ACPI experts suggest how narrow we should
> > > make it though - arch opt in might be narrow enough.
> >
> > A chicken bit wouldn't help much IMO, especially in the cases when
> > working setups get broken.
> >
> > I would very much prefer to limit the scope of it, say to processors
> > only, in the first place.
>
> Thanks for the feedback and the idea.
>
> I guess we need something like:
>
>         if (device->status.present)
>                 return device->device_type != ACPI_BUS_TYPE_PROCESSOR ||
>                        device->status.enabled;
>         else
>                 return device->status.functional;
>
> so we only check device->status.enabled for processor-type devices?

Yes, something like this.


From konrad.dybcio at linaro.org  Thu Dec 14 10:18:19 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Thu, 14 Dec 2023 19:18:19 +0100
Subject: [PATCH v3 7/8] arm64: dts: qcom: ipq5332: add support for the
 NSSCC
In-Reply-To: <8cc2a8ec-632e-4e3b-b13b-d1523a61c136@quicinc.com>
References: <20231211-ipq5332-nsscc-v3-0-ad13bef9b137@quicinc.com>
 <20231211-ipq5332-nsscc-v3-7-ad13bef9b137@quicinc.com>
 <c4034715-53a5-468e-914a-3f19d0618c42@linaro.org>
 <8cc2a8ec-632e-4e3b-b13b-d1523a61c136@quicinc.com>
Message-ID: <92e9039b-a0e3-4f93-aaa8-226ef9e8b613@linaro.org>



On 12/11/23 14:28, Kathiravan Thirumoorthy wrote:
> 
> 
> On 12/11/2023 4:02 PM, Konrad Dybcio wrote:
>> On 11.12.2023 04:37, Kathiravan Thirumoorthy wrote:
>>> Describe the NSS clock controller node and it's relevant external
>>> clocks.
>>>
>>> Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav at quicinc.com>
>>> ---
>>> ? arch/arm64/boot/dts/qcom/ipq5332.dtsi | 28 ++++++++++++++++++++++++++++
>>> ? 1 file changed, 28 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/ipq5332.dtsi b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
>>> index 42e2e48b2bc3..a1504f6c40c1 100644
>>> --- a/arch/arm64/boot/dts/qcom/ipq5332.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/ipq5332.dtsi
>>> @@ -15,6 +15,18 @@ / {
>>> ????? #size-cells = <2>;
>>> ????? clocks {
>>> +??????? cmn_pll_nss_200m_clk: cmn-pll-nss-200m-clk {
>>> +??????????? compatible = "fixed-clock";
>>> +??????????? clock-frequency = <200000000>;
>>> +??????????? #clock-cells = <0>;
>>> +??????? };
>>> +
>>> +??????? cmn_pll_nss_300m_clk: cmn-pll-nss-300m-clk {
>>> +??????????? compatible = "fixed-clock";
>>> +??????????? clock-frequency = <300000000>;
>>> +??????????? #clock-cells = <0>;
>>> +??????? };
>>> +
>>> ????????? sleep_clk: sleep-clk {
>>> ????????????? compatible = "fixed-clock";
>>> ????????????? #clock-cells = <0>;
>>> @@ -473,6 +485,22 @@ frame at b128000 {
>>> ????????????????? status = "disabled";
>>> ????????????? };
>>> ????????? };
>>> +
>>> +??????? nsscc: clock-controller at 39b00000{
>> Missing space between the opening curly brace
> 
> My bad :( will fix it in next spin.
> 
>>
>>> +??????????? compatible = "qcom,ipq5332-nsscc";
>>> +??????????? reg = <0x39b00000 0x80000>;
>> the regmap_config in the clk driver has .max_register = 0x800, is this
>> correct?
> 
> As per the memory map, 512KB is the size of this block. However the last register in that region is at the offset 0x800. Shall I update the max_register also to 512KB to keep it consistency?
No, it's fine, I just wanted to know if it's intentional :)

Thanks!

Konrad


From robin.murphy at arm.com  Thu Dec 14 10:22:49 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 14 Dec 2023 18:22:49 +0000
Subject: [PATCH v2 6/7] iommu/dma: Centralise iommu_setup_dma_ops()
In-Reply-To: <20231214165126.GA3726750@myrica>
References: <cover.1702486837.git.robin.murphy@arm.com>
 <5d89190b35720bf5b66621f46b6d3c85323d8eab.1702486837.git.robin.murphy@arm.com>
 <20231214165126.GA3726750@myrica>
Message-ID: <2d87c1dc-cc95-4d92-968c-9d6e6e6439ff@arm.com>

On 2023-12-14 4:51 pm, Jean-Philippe Brucker wrote:
> On Wed, Dec 13, 2023 at 05:17:59PM +0000, Robin Murphy wrote:
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index 27a167f4cd3e..d808c8dcf5cb 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -1724,25 +1724,20 @@ static const struct dma_map_ops iommu_dma_ops = {
>>   	.opt_mapping_size	= iommu_dma_opt_mapping_size,
>>   };
>>   
>> -/*
>> - * The IOMMU core code allocates the default DMA domain, which the underlying
>> - * IOMMU driver needs to support via the dma-iommu layer.
>> - */
>> -void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
>> +void iommu_setup_dma_ops(struct device *dev)
>>   {
>>   	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
>>   
>> -	if (!domain)
>> -		goto out_err;
>> +	if (dev_is_pci(dev))
>> +		dev->iommu->pci_32bit_workaround = !iommu_dma_forcedac;
>>   
>> -	/*
>> -	 * The IOMMU core code allocates the default DMA domain, which the
>> -	 * underlying IOMMU driver needs to support via the dma-iommu layer.
>> -	 */
>>   	if (iommu_is_dma_domain(domain)) {
> 
> ...
> 
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 824989874dee..43f630d0530e 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -560,10 +560,10 @@ static int __iommu_probe_device(struct device *dev, struct list_head *group_list
>>   		if (list_empty(&group->entry))
>>   			list_add_tail(&group->entry, group_list);
>>   	}
>> -	mutex_unlock(&group->mutex);
>>   
>> -	if (dev_is_pci(dev))
>> -		iommu_dma_set_pci_32bit_workaround(dev);
>> +	iommu_setup_dma_ops(dev);
> 
> With Intel VT-d (QEMU emulation) I get a crash in iommu_setup_dma_ops()
> because at this point group->domain and group->default_domain are still
> NULL, group_list is non-NULL.

Ugh, clearly I'd manage to confuse myself, since what I wrote in the
changelog isn't even right...

Taking yet another look, there's not actually one single place we can do
this right now which will work in a manageable way for all cases. With 2
or 3 more levels of mess unpicked it's going to clean up much further
(it's also becoming clear that iommu-dma wants better separation of its
own per-device and per-domain bits), but for the immediate task in this
series of finally getting out of arch code, I guess that continuing to
echo the current probe_finalize flows is going to be safest. Something
like the diff below (but I'll have a further think about it with a fresh
head tomorrow).

Thanks,
Robin.

----->8-----
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 8972b7f22a9a..ba4cd5251205 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -562,7 +562,8 @@ static int __iommu_probe_device(struct device *dev, struct list_head *group_list
  			list_add_tail(&group->entry, group_list);
  	}
  
-	iommu_setup_dma_ops(dev);
+	if (group->default_domain)
+		iommu_setup_dma_ops(dev);
  
  	mutex_unlock(&group->mutex);
  
@@ -1992,6 +1993,8 @@ int bus_iommu_probe(const struct bus_type *bus)
  			mutex_unlock(&group->mutex);
  			return ret;
  		}
+		for_each_group_device(group, gdev)
+			iommu_setup_dma_ops(gdev->dev);
  		mutex_unlock(&group->mutex);
  
  		/*
@@ -3217,18 +3220,9 @@ static ssize_t iommu_group_store_type(struct iommu_group *group,
  	if (ret)
  		goto out_unlock;
  
-	/*
-	 * Release the mutex here because ops->probe_finalize() call-back of
-	 * some vendor IOMMU drivers calls arm_iommu_attach_device() which
-	 * in-turn might call back into IOMMU core code, where it tries to take
-	 * group->mutex, resulting in a deadlock.
-	 */
-	mutex_unlock(&group->mutex);
-
  	/* Make sure dma_ops is appropriatley set */
  	for_each_group_device(group, gdev)
-		iommu_group_do_probe_finalize(gdev->dev);
-	return count;
+		iommu_setup_dma_ops(gdev->dev);
  
  out_unlock:
  	mutex_unlock(&group->mutex);


From linus.walleij at linaro.org  Thu Dec 14 10:26:31 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 14 Dec 2023 19:26:31 +0100
Subject: [PATCH] mfd: ab8500-sysctrl: Drop ancient charger
Message-ID: <20231214-ab8500-sysctrl-oneliner-v1-1-fd78a15c0b2f@linaro.org>

The sysctrl driver was looking for an instance of the PM2301
charger but this has been deleted from the kernel and is not
used with the U8500 systems any more. Drop the string.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/mfd/ab8500-sysctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
index eeeb62415f53..7ac8248b790a 100644
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -30,7 +30,7 @@ static void ab8500_power_off(void)
 {
 	sigset_t old;
 	sigset_t all;
-	static const char * const pss[] = {"ab8500_ac", "pm2301", "ab8500_usb"};
+	static const char * const pss[] = {"ab8500_ac", "ab8500_usb"};
 	int i;
 	bool charger_present = false;
 	union power_supply_propval val;

---
base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86
change-id: 20231214-ab8500-sysctrl-oneliner-ebd0911464fb

Best regards,
-- 
Linus Walleij <linus.walleij at linaro.org>



From lkp at intel.com  Thu Dec 14 10:29:10 2023
From: lkp at intel.com (kernel test robot)
Date: Fri, 15 Dec 2023 02:29:10 +0800
Subject: [PATCH v2] coresight: Make current W=1 warnings default
In-Reply-To: <20231115162834.355598-1-james.clark@arm.com>
References: <20231115162834.355598-1-james.clark@arm.com>
Message-ID: <202312150201.EizBBCDr-lkp@intel.com>

Hi James,

kernel test robot noticed the following build warnings:

[auto build test WARNING on atorgue-stm32/stm32-next]
[also build test WARNING on soc/for-next linus/master v6.7-rc5 next-20231214]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/James-Clark/coresight-Make-current-W-1-warnings-default/20231116-004818
base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
patch link:    https://lore.kernel.org/r/20231115162834.355598-1-james.clark%40arm.com
patch subject: [PATCH v2] coresight: Make current W=1 warnings default
config: arm-randconfig-r131-20231117 (https://download.01.org/0day-ci/archive/20231215/202312150201.EizBBCDr-lkp at intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231215/202312150201.EizBBCDr-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312150201.EizBBCDr-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/hwtracing/coresight/coresight-tpdm.c:242:17: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-tpdm.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
--
>> drivers/hwtracing/coresight/coresight-etb10.c:840:17: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-etb10.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false
--
>> drivers/hwtracing/coresight/coresight-funnel.c:395:17: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-funnel.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/slab.h, ...):
   include/linux/page-flags.h:242:46: sparse: sparse: self-comparison always evaluates to false

vim +242 drivers/hwtracing/coresight/coresight-tpdm.c

   232	
   233	/*
   234	 * Different TPDM has different periph id.
   235	 * The difference is 0-7 bits' value. So ignore 0-7 bits.
   236	 */
   237	static struct amba_id tpdm_ids[] = {
   238		{
   239			.id = 0x000f0e00,
   240			.mask = 0x000fff00,
   241		},
 > 242		{ 0, 0, 0 },
   243	};
   244	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From nm at ti.com  Thu Dec 14 10:33:56 2023
From: nm at ti.com (Nishanth Menon)
Date: Thu, 14 Dec 2023 12:33:56 -0600
Subject: [PATCH 2/3] arm64: dts: ti: Introduce J722S family of SoCs
In-Reply-To: <f2bc6c68-742a-4a21-956e-91ee0933dd96@ti.com>
References: <20231213124930.3012-1-vaishnav.a@ti.com>
 <20231213124930.3012-3-vaishnav.a@ti.com>
 <20231213202705.6tspycl5qicb6gwd@germproof>
 <08eccba2-41df-91e7-c1e5-e03190402c23@ti.com>
 <20231214122713.qx7as6grpvlq3ylw@stoic>
 <f2bc6c68-742a-4a21-956e-91ee0933dd96@ti.com>
Message-ID: <20231214183356.hi5d6cuqmqltiy6i@footnote>

On 09:43-20231214, Andrew Davis wrote:
> On 12/14/23 6:27 AM, Nishanth Menon wrote:
> > On 14:07-20231214, Vaishnav Achath wrote:
> > [..]
> > > > Trim this down to what is different from AM62P?
> > > > 
> > > 
> > > Thanks for the review, I will trim this down in next revision, but the above is
> > > just a summary of the main features of this SoC, pointing to AM62P feature set
> > > here seems confusing to me. why does a new user/developer using J722S need to be
> > > aware of the existence of AM62P to just understand a high level summary about
> > > this device?
> > 
> > Since this is a reuse device. Helps with review and focus on deltas.
> > 
> > [...]
> > 
> > > > > +	l2_0: l2-cache0 {
> > > > > +		compatible = "cache";
> > > > > +		cache-unified;
> > > > > +		cache-level = <2>;
> > > > > +		cache-size = <0x80000>;
> > > > > +		cache-line-size = <64>;
> > > > > +		cache-sets = <512>;
> > > > > +	};
> > > > 
> > > > ^^ this is a duplication of am62p5.dtsi? what about the spins with
> > > > different CPUs enabled?
> > > > 
> > > 
> > > Yes it is a duplicate, as of now we are not aware of plan for spins with cores
> > > disabled, so just followed the pattern followed for other Jacinto devices
> > > (J721e, J7200, J721s2, J784s4).
> > 
> > None of the devices have been as close a reuse device as this has been.
> 
> I'd argue J721e and J7200 are more similar in terms of reuse. It was a
> mistake to model them as simple super/subsets of each other, only causes
> confusion later. Let's keep at least this top level file, we will end up
> using it more as more features/deltas are enabled/found.
> 

yes, we do need a top level dtsi for the SoC. just minimize the amount
of duplication.

[...]
> > > 
> > > [    7.492406] platform 79000000.r5f: configured R5F for remoteproc mode
> > > [    7.499887] platform 79000000.r5f: device does not have reserved memory
> > > regions, ret = -22
> > > [    7.508271] k3_r5_rproc bus at f0000:bus at 4000000:r5fss at 79000000: reserved memory
> > > init failed, ret = -22
> > > [    7.517549] remoteproc remoteproc0: releasing 79000000.r5f
> > > [    7.523338] k3_r5_rproc bus at f0000:bus at 4000000:r5fss at 79000000:
> > > k3_r5_cluster_rproc_init failed, ret = -22
> > > [    7.532993] k3_r5_rproc: probe of bus at f0000:bus at 4000000:r5fss at 79000000 failed
> > > with error -22
> > 
> > Yes, and the approach should rather be to disable the remote procs in
> > the board or at the SoC dtsi in a consistent manner. I had previously
> > suggested to do that SoC level (which means at am62p dtsi) since the remoteprocs have direct
> > dependency on how the memory layouts are partitioned in board.dts - but
> > i had asked folks working on remote procs to do that consistently across
> > SoCs. I don't see that having been done so far.
> > 
> 
> I fixed this for a couple SoCs way back last year (7e48b665100ee), seems
> folks kept adding mailboxes/rprocs un-disabled in the base .dtbi for
> new SoCs anyway :( This needs fixed in AM62p .dtsi first, then these
> disables can be removed from here.
> 

Yes, hence blocking it from here on. Cleanup, then add.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From ninad at linux.ibm.com  Thu Dec 14 10:34:14 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Thu, 14 Dec 2023 12:34:14 -0600
Subject: [PATCH v1 4/8] ARM: dts: aspeed: System1: Add i2c and muxes
In-Reply-To: <72a749b9-b9be-4496-9bcc-37519044c109@linaro.org>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-5-ninad@linux.ibm.com>
 <72a749b9-b9be-4496-9bcc-37519044c109@linaro.org>
Message-ID: <8cdadff2-055a-48ab-8495-45c8285d3d8f@linux.ibm.com>

Hello Krzysztof,

On 12/12/23 14:21, Krzysztof Kozlowski wrote:
> On 12/12/2023 17:40, Ninad Palsule wrote:
>> This commit adds i2c devices and muxes.
>>
>> Tested:
>>      This board is tested using the simics simulator.
>>
>> Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
>> ---
>>   .../dts/aspeed/aspeed-bmc-ibm-system1.dts     | 577 ++++++++++++++++++
>>   1 file changed, 577 insertions(+)
>>
> Why do you split new submission into multiple chunks? The logical
> feature here is new board, so all your DTS patches adding new board
> should be in one patch.
Oh,ok. I thought it might be easier to review but now I squashed them 
together.
>
>> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> index 01291b407f59..0557bff9f36a 100644
>> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
>> @@ -11,6 +11,65 @@ / {
>>   	model = "System1";
>>   	compatible = "ibm,system1-bmc", "aspeed,ast2600";
>>   
>> +	aliases {
>> +		i2c16 = &i2c8mux1chn0;
>> +		i2c17 = &i2c8mux1chn1;
>> +		i2c18 = &i2c8mux1chn2;
>> +		i2c19 = &i2c8mux1chn3;
>> +		i2c20 = &i2c8mux1chn4;
>> +		i2c21 = &i2c8mux1chn5;
>> +		i2c22 = &i2c8mux1chn6;
>> +		i2c23 = &i2c8mux1chn7;
>> +		i2c24 = &i2c3mux0chn0;
>> +		i2c25 = &i2c3mux0chn1;
>> +		i2c26 = &i2c3mux0chn2;
>> +		i2c27 = &i2c3mux0chn3;
>> +		i2c28 = &i2c3mux0chn4;
>> +		i2c29 = &i2c3mux0chn5;
>> +		i2c30 = &i2c3mux0chn6;
>> +		i2c31 = &i2c3mux0chn7;
>> +		i2c32 = &i2c6mux0chn0;
>> +		i2c33 = &i2c6mux0chn1;
>> +		i2c34 = &i2c6mux0chn2;
>> +		i2c35 = &i2c6mux0chn3;
>> +		i2c36 = &i2c6mux0chn4;
>> +		i2c37 = &i2c6mux0chn5;
>> +		i2c38 = &i2c6mux0chn6;
>> +		i2c39 = &i2c6mux0chn7;
>> +		i2c40 = &i2c7mux0chn0;
>> +		i2c41 = &i2c7mux0chn1;
>> +		i2c42 = &i2c7mux0chn2;
>> +		i2c43 = &i2c7mux0chn3;
>> +		i2c44 = &i2c7mux0chn4;
>> +		i2c45 = &i2c7mux0chn5;
>> +		i2c46 = &i2c7mux0chn6;
>> +		i2c47 = &i2c7mux0chn7;
>> +		i2c48 = &i2c8mux0chn0;
>> +		i2c49 = &i2c8mux0chn1;
>> +		i2c50 = &i2c8mux0chn2;
>> +		i2c51 = &i2c8mux0chn3;
>> +		i2c52 = &i2c8mux0chn4;
>> +		i2c53 = &i2c8mux0chn5;
>> +		i2c54 = &i2c8mux0chn6;
>> +		i2c55 = &i2c8mux0chn7;
>> +		i2c56 = &i2c14mux0chn0;
>> +		i2c57 = &i2c14mux0chn1;
>> +		i2c58 = &i2c14mux0chn2;
>> +		i2c59 = &i2c14mux0chn3;
>> +		i2c60 = &i2c14mux0chn4;
>> +		i2c61 = &i2c14mux0chn5;
>> +		i2c62 = &i2c14mux0chn6;
>> +		i2c63 = &i2c14mux0chn7;
>> +		i2c64 = &i2c15mux0chn0;
>> +		i2c65 = &i2c15mux0chn1;
>> +		i2c66 = &i2c15mux0chn2;
>> +		i2c67 = &i2c15mux0chn3;
>> +		i2c68 = &i2c15mux0chn4;
>> +		i2c69 = &i2c15mux0chn5;
>> +		i2c70 = &i2c15mux0chn6;
>> +		i2c71 = &i2c15mux0chn7;
>> +	};
>> +
>>   	chosen {
>>   		stdout-path = &uart5;
>>   		bootargs = "console=ttyS4,115200n8 earlycon";
>> @@ -54,10 +113,12 @@ vga_memory: region at bf000000 {
>>   			reg = <0xbf000000 0x01000000>;  /* 16M */
>>   		};
>>   	};
>> +
> You need to clean your patchset...
I made changes about the stdout-path, is that what you mean?
>
>
>>   };
>>   
>>   &adc1 {
>>   	status = "okay";
>> +
> Really.
I need to add "status = okay" otherwise its not instantiated.
>
>>   	aspeed,int-vref-microvolt = <2500000>;
>>   	pinctrl-names = "default";
>>   	pinctrl-0 = <&pinctrl_adc8_default
>> @@ -186,3 +247,519 @@ &kcs3 {
>>   	aspeed,lpc-io-reg = <0xca2>;
>>   	aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
>>   };
>> +
>> +&i2c0 {
>> +	status = "okay";
>> +};
>> +
>> +&i2c1 {
>> +	status = "okay";
>> +};
>> +
>> +&i2c2 {
>> +	status = "okay";
>> +};
>> +
>> +&i2c3 {
>> +	status = "okay";
>> +
>> +	i2c-mux at 70 {
>> +		compatible = "nxp,pca9548";
>> +		reg = <0x70>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		status = "okay";
> Drop
Done.
>
>> +		i2c-mux-idle-disconnect;
>> +
>> +		i2c3mux0chn0: i2c at 0 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0>;
>> +		};
>> +
>> +		i2c3mux0chn1: i2c at 1 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <1>;
>> +		};
>> +
>> +		i2c3mux0chn2: i2c at 2 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <2>;
>> +		};
>> +
>> +		i2c3mux0chn3: i2c at 3 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <3>;
>> +		};
>> +
>> +		i2c3mux0chn4: i2c at 4 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <4>;
>> +		};
>> +
>> +		i2c3mux0chn5: i2c at 5 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <5>;
>> +		};
>> +
>> +		i2c3mux0chn6: i2c at 6 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <6>;
>> +		};
>> +
>> +		i2c3mux0chn7: i2c at 7 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <7>;
>> +		};
>> +	};
>> +};
>> +
>> +&i2c4 {
>> +	status = "okay";
>> +};
>> +
>> +&i2c5 {
>> +	status = "okay";
>> +};
>> +
>> +&i2c6 {
>> +	status = "okay";
>> +
>> +	i2c-mux at 70 {
>> +		compatible = "nxp,pca9548";
>> +		reg = <0x70>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		status = "okay";
> Drop

Done

Thanks for the review.

Regards,

Ninad

>
> Other places as well.
>
>
> Best regards,
> Krzysztof
>


From rafael at kernel.org  Thu Dec 14 10:37:10 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Thu, 14 Dec 2023 19:37:10 +0100
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or functional) devices
In-Reply-To: <CAJZ5v0h2Keyb-gFWFuPsKtwqjXvM2snyGpo6MMfFzaXKbfEpgw@mail.gmail.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk> <E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>
 <20231214173241.0000260f@Huawei.com> <CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>
 <ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk> <CAJZ5v0h2Keyb-gFWFuPsKtwqjXvM2snyGpo6MMfFzaXKbfEpgw@mail.gmail.com>
Message-ID: <CAJZ5v0h3WWtvrbxRpaGfq6c756k+L1SzZ1Gv3A14JxXHNcUMKA@mail.gmail.com>

On Thu, Dec 14, 2023 at 7:16?PM Rafael J. Wysocki <rafael at kernel.org> wrote:
>
> On Thu, Dec 14, 2023 at 7:10?PM Russell King (Oracle)
> <linux at armlinux.org.uk> wrote:
> >
> > On Thu, Dec 14, 2023 at 06:47:00PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Dec 14, 2023 at 6:32?PM Jonathan Cameron
> > > <Jonathan.Cameron at huawei.com> wrote:
> > > >
> > > > On Wed, 13 Dec 2023 12:49:16 +0000
> > > > Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> > > >
> > > > > From: James Morse <james.morse at arm.com>
> > > > >
> > > > > Today the ACPI enumeration code 'visits' all devices that are present.
> > > > >
> > > > > This is a problem for arm64, where CPUs are always present, but not
> > > > > always enabled. When a device-check occurs because the firmware-policy
> > > > > has changed and a CPU is now enabled, the following error occurs:
> > > > > | acpi ACPI0007:48: Enumeration failure
> > > > >
> > > > > This is ultimately because acpi_dev_ready_for_enumeration() returns
> > > > > true for a device that is not enabled. The ACPI Processor driver
> > > > > will not register such CPUs as they are not 'decoding their resources'.
> > > > >
> > > > > Change acpi_dev_ready_for_enumeration() to also check the enabled bit.
> > > > > ACPI allows a device to be functional instead of maintaining the
> > > > > present and enabled bit. Make this behaviour an explicit check with
> > > > > a reference to the spec, and then check the present and enabled bits.
> > > > > This is needed to avoid enumerating present && functional devices that
> > > > > are not enabled.
> > > > >
> > > > > Signed-off-by: James Morse <james.morse at arm.com>
> > > > > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > > > > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > > > > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > > > > ---
> > > > > If this change causes problems on deployed hardware, I suggest an
> > > > > arch opt-in: ACPI_IGNORE_STA_ENABLED, that causes
> > > > > acpi_dev_ready_for_enumeration() to only check the present bit.
> > > >
> > > > My gut feeling (having made ACPI 'fixes' in the past that ran into
> > > > horribly broken firmware and had to be reverted) is reduce the blast
> > > > radius preemptively from the start. I'd love to live in a world were
> > > > that wasn't necessary but I don't trust all the generators of ACPI tables.
> > > > I'll leave it to Rafael and other ACPI experts suggest how narrow we should
> > > > make it though - arch opt in might be narrow enough.
> > >
> > > A chicken bit wouldn't help much IMO, especially in the cases when
> > > working setups get broken.
> > >
> > > I would very much prefer to limit the scope of it, say to processors
> > > only, in the first place.
> >
> > Thanks for the feedback and the idea.
> >
> > I guess we need something like:
> >
> >         if (device->status.present)
> >                 return device->device_type != ACPI_BUS_TYPE_PROCESSOR ||
> >                        device->status.enabled;
> >         else
> >                 return device->status.functional;
> >
> > so we only check device->status.enabled for processor-type devices?
>
> Yes, something like this.

However, that is not sufficient, because there are
ACPI_BUS_TYPE_DEVICE devices representing processors.

I'm not sure about a clean way to do it ATM.


From robh at kernel.org  Thu Dec 14 10:55:14 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 14 Dec 2023 12:55:14 -0600
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <ZXsjFYKHkJM_JLCy@raptor>
References: <20231119165721.9849-12-alexandru.elisei@arm.com>
 <CAL_Jsq+k5BeM9+u12AQvWQ0b4Uv5Cy0vPOpK_uLcYtRnunq4iQ@mail.gmail.com>
 <ZXiMiLz9ZyUdxUP8@raptor> <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
 <ZXmr-Kl9L2SO13--@raptor> <CAL_JsqL=P1Y6w38LD_xw+vK4CNqt22FW_FE9oi_XTLHVQEne7Q@mail.gmail.com>
 <ZXnE3724jYYSg4o6@raptor> <CAL_JsqJgTnuQjo13cKo1Ebm5j9tCRT8GhNavdqu5vwp+fdnTLw@mail.gmail.com>
 <ZXnthcg0BkEd-RgK@raptor> <CAL_JsqLAW0--F8R0oTaajN3YpbK2KgE6Ypn8tk4_pf_s=xC+aw@mail.gmail.com>
 <ZXsjFYKHkJM_JLCy@raptor>
Message-ID: <CAL_JsqJF7Bs6nGt0hdP25YTMpzPK8V3h6C5Thkh=PnzPbwFEkQ@mail.gmail.com>

On Thu, Dec 14, 2023 at 9:45?AM Alexandru Elisei
<alexandru.elisei at arm.com> wrote:
>
> Hi,
>
> On Wed, Dec 13, 2023 at 02:30:42PM -0600, Rob Herring wrote:
> > On Wed, Dec 13, 2023 at 11:44?AM Alexandru Elisei
> > <alexandru.elisei at arm.com> wrote:
> > >
> > > On Wed, Dec 13, 2023 at 11:22:17AM -0600, Rob Herring wrote:
> > > > On Wed, Dec 13, 2023 at 8:51?AM Alexandru Elisei
> > > > <alexandru.elisei at arm.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> > > > > > On Wed, Dec 13, 2023 at 7:05?AM Alexandru Elisei
> > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > >
> > > > > > > Hi Rob,
> > > > > > >
> > > > > > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > > > > > > On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
> > > > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Rob,
> > > > > > > > >
> > > > > > > > > Thank you so much for the feedback, I'm not very familiar with device tree,
> > > > > > > > > and any comments are very useful.
> > > > > > > > >
> > > > > > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > > > > > > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > > > > > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > > > > > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > > > > > > > >
> > > > > > > > > > > The DTB node for the tag storage region is defined as:
> > > > > > > > > > >
> > > > > > > > > > >         tags0: tag-storage at 8f8000000 {
> > > > > > > > > > >                 compatible = "arm,mte-tag-storage";
> > > > > > > > > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > > > > > > > > >                 block-size = <0x1000>;
> > > > > > > > > > >                 memory = <&memory0>;    // Associated tagged memory node
> > > > > > > > > > >         };
> > > > > > > > > >
> > > > > > > > > > I skimmed thru the discussion some. If this memory range is within
> > > > > > > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > > > > > > >
> > > > > > > > > Ok, will do that.
> > > > > > > > >
> > > > > > > > > If you don't mind, why do you say that it definitely belongs in
> > > > > > > > > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > > > > > > > > motivation.
> > > > > > > >
> > > > > > > > Simply so that /memory nodes describe all possible memory and
> > > > > > > > /reserved-memory is just adding restrictions. It's also because
> > > > > > > > /reserved-memory is what gets handled early, and we don't need
> > > > > > > > multiple things to handle early.
> > > > > > > >
> > > > > > > > > Tag storage is not DMA and can live anywhere in memory.
> > > > > > > >
> > > > > > > > Then why put it in DT at all? The only reason CMA is there is to set
> > > > > > > > the size. It's not even clear to me we need CMA in DT either. The
> > > > > > > > reasoning long ago was the kernel didn't do a good job of moving and
> > > > > > > > reclaiming contiguous space, but that's supposed to be better now (and
> > > > > > > > most h/w figured out they need IOMMUs).
> > > > > > > >
> > > > > > > > But for tag storage you know the size as it is a function of the
> > > > > > > > memory size, right? After all, you are validating the size is correct.
> > > > > > > > I guess there is still the aspect of whether you want enable MTE or
> > > > > > > > not which could be done in a variety of ways.
> > > > > > >
> > > > > > > Oh, sorry, my bad, I should have been clearer about this. I don't want to
> > > > > > > put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.
> > > > > >
> > > > > > Yes, I understand, but my point remains. Why do you need this in DT?
> > > > > > If the location doesn't matter and you can calculate the size from the
> > > > > > memory size, what else is there to add to the DT?
> > > > >
> > > > > I am afraid there has been a misunderstanding. What do you mean by
> > > > > "location doesn't matter"?
> > > >
> > > > You said:
> > > > > Tag storage is not DMA and can live anywhere in memory.
> > > >
> > > > Which I took as the kernel can figure out where to put it. But maybe
> > > > you meant the h/w platform can hard code it to be anywhere in memory?
> > > > If so, then yes, DT is needed.
> > >
> > > Ah, I see, sorry for not being clear enough, you are correct: tag storage
> > > is a hardware property, and software needs a mechanism (in this case, the
> > > dt) to discover its properties.
> > >
> > > >
> > > > > At the very least, Linux needs to know the address and size of a memory
> > > > > region to use it. The series is about using the tag storage memory for
> > > > > data. Tag storage cannot be described as a regular memory node because it
> > > > > cannot be tagged (and normal memory can).
> > > >
> > > > If the tag storage lives in the middle of memory, then it would be
> > > > described in the memory node, but removed by being in reserved-memory
> > > > node.
> > >
> > > I don't follow. Would you mind going into more details?
> >
> > It goes back to what I said earlier about /memory nodes describing all
> > the memory. There's no reason to reserve memory if you haven't
> > described that range as memory to begin with. One could presumably
> > just have a memory node for each contiguous chunk and not need
> > /reserved-memory (ignoring the need to say what things are reserved
> > for). That would become very difficult to adjust. Note that the kernel
> > has a hardcoded limit of 64 reserved regions currently and that is not
> > enough for some people. Seems like a lot, but I have no idea how they
> > are (ab)using /reserved-memory.
>
> Ah, I see what you mean, reserved memory is about marking existing memory
> (from a /memory node) as special, not about adding new memory.
>
> After the memblock allocator is initialized, the kernel can use it for its
> own allocations. Kernel allocations are not movable.
>
> When a page is allocated as tagged, the associated tag storage cannot be
> used for data, otherwise the tags would corrupt that data. To avoid this,
> the requirement is that tag storage pages are only used for movable
> allocations. When a page is allocated as tagged, the data in the associated
> tag storage is migrated and the tag storage is taken from the page
> allocator (via alloc_contig_range()).
>
> My understanding is that the memblock allocator can use all the memory from
> a /memory node. If the tags storage memory is declared in a /memory node,
> there exists the possibility that Linux will use tag storage memory for its
> own allocation, which would make that tags storage memory unmovable, and
> thus unusable for storing tags.

No, because the tag storage would be reserved in /reserved-memory.

Of course, the arch code could do something between scanning /memory
nodes and /reserved-memory, but that would be broken arch code.
Ideally, there wouldn't be any arch code in between those 2 points,
but it's complicated. It used to mainly be powerpc, but we keep adding
to the complexity on arm64.

> Looking at early_init_dt_scan_memory(), even if a /memory node if marked at
> hotpluggable, memblock will still use it, unless "movable_node" is set on
> the kernel command line.
>
> That's the reason why I'm not describing tag storage in a /memory node.  Is
> there way to tell the memblock allocator not to use memory from a /memory
> node?
>
> >
> > Let me give an example. Presumably using MTE at all is configurable.
> > If you boot a kernel with MTE disabled (or older and not supporting
> > it), then I'd assume you'd want to use the tag storage for regular
> > memory. Well, If tag storage is already part of /memory, then all you
> > have to do is ignore the tag reserved-memory region. Tweaking the
> > memory nodes would be more work.
>
> Right now, memory is added via memblock_reserve(), and if MTE is disabled
> (for example, via the kernel command line), the code calls
> free_reserved_page() for each tag storage page. I find that straightfoward
> to implement.

But better to just not reserve the region in the first place. Also, it
needs to be simple enough to back port.

Also, does free_reserved_page() work on ranges outside of memblock
range (e.g. beyond end_of_DRAM())? If the tag storage happened to live
at the end of DRAM and you shorten the /memory node size to remove tag
storage, is it still going to work?

Rob


From jernej.skrabec at gmail.com  Thu Dec 14 10:56:35 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Thu, 14 Dec 2023 19:56:35 +0100
Subject: [PATCH v2 0/3] arm64: dts: allwinner: Add Transpeed 8K618-T TV box
In-Reply-To: <20231214015312.17363-1-andre.przywara@arm.com>
References: <20231214015312.17363-1-andre.przywara@arm.com>
Message-ID: <46021670.fMDQidcC6G@archlinux>

On Thursday, December 14, 2023 2:53:09 AM CET Andre Przywara wrote:
> A quick update, with the few fixes for issues that reviewers spotted.
> See below for a changelog.
> ================================
> 
> The Transpeed 8K618-T is one example of various cheap Chinese TV boxes
> using the Allwinner H618 SoC. It comes with up to 4GB DRAM and up to
> 128GB eMMC flash, plus the usual HDMI, 100Mbit Ethernet, WiFi/BT and
> dual USB ports, not to forget the mandatory microSD card slot.
> More details: https://linux-sunxi.org/Transpeed_8K618-T
> 
> Ethernet relies on the yet unsupported integrated PHY, and the HDMI
> output is similarly not yet supported, but patches exist that await
> polishing for mainline submission.
> Meanwhile USB and eMMC plus SD card work, so you can hook up an USB
> Ethernet or WiFi adapter to get things going.
> 
> This series is the usual trilogy of DT support patches: adding the vendor
> name in patch 1, the board compatible name in patch 2, and the actual
> .dts file in patch 3.
> 
> Please have a look!

Applied, thanks!

Best regards,
Jernej

> 
> Thanks,
> Andre
> 
> Changelog v1 .. v2:
> - fix alphabetical ordering in vendor-prefixes
> - remove unneeded UART1 alias
> - extend regulator names, drop now redundant comments
> 
> Andre Przywara (3):
>   dt-bindings: vendor-prefixes: add Transpeed
>   dt-bindings: arm: sunxi: document Transpeed 8K618-T board name
>   arm64: dts: allwinner: h618: add Transpeed 8K618-T TV box
> 
>  .../devicetree/bindings/arm/sunxi.yaml        |   5 +
>  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
>  arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>  .../sun50i-h618-transpeed-8k618-t.dts         | 161 ++++++++++++++++++
>  4 files changed, 169 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
> 
> 






From jernej at kernel.org  Thu Dec 14 11:19:44 2023
From: jernej at kernel.org (Jernej Skrabec)
Date: Thu, 14 Dec 2023 20:19:44 +0100
Subject: [GIT PULL] Allwinner fixes for 6.7
Message-ID: <ZXtVUJ0SG2NRpPG4@archlinux>

Hi!

Please pull following DT fixes for 6.7.

Best regards,
Jernej

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-fixes-for-6.7-1

for you to fetch changes up to b9622937d95809ef89904583191571a9fa326402:

  arm64: dts: allwinner: h616: update emac for Orange Pi Zero 3 (2023-11-18 23:24:34 +0100)

----------------------------------------------------------------
- Fix ethernet node for Orange Pi Zero 3 board

----------------------------------------------------------------
Chukun Pan (1):
      arm64: dts: allwinner: h616: update emac for Orange Pi Zero 3

 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero.dtsi | 3 ---
 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts | 3 +++
 arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts | 2 ++
 3 files changed, 5 insertions(+), 3 deletions(-)


From andriy.shevchenko at linux.intel.com  Thu Dec 14 11:21:31 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu, 14 Dec 2023 21:21:31 +0200
Subject: [PATCH v1 1/1] leds: sun50i-a100: Convert to be agnostic to property provider
Message-ID: <20231214192131.1309912-1-andriy.shevchenko@linux.intel.com>

Convert the driver to be agnostic to the property provider.
LEDS subsytem is not dependent on OF, so no need to make drivers
be a such.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/leds/Kconfig            |  2 +-
 drivers/leds/leds-sun50i-a100.c | 46 ++++++++++++++++-----------------
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ef2bdf51ae91..8a1471a0b528 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -304,7 +304,7 @@ config LEDS_COBALT_RAQ
 
 config LEDS_SUN50I_A100
 	tristate "LED support for Allwinner A100 RGB LED controller"
-	depends on LEDS_CLASS_MULTICOLOR && OF
+	depends on LEDS_CLASS_MULTICOLOR
 	depends on ARCH_SUNXI || COMPILE_TEST
 	help
 	  This option enables support for the RGB LED controller found
diff --git a/drivers/leds/leds-sun50i-a100.c b/drivers/leds/leds-sun50i-a100.c
index 171cefd1ea0d..62d21c3a3575 100644
--- a/drivers/leds/leds-sun50i-a100.c
+++ b/drivers/leds/leds-sun50i-a100.c
@@ -15,10 +15,11 @@
 #include <linux/io.h>
 #include <linux/led-class-multicolor.h>
 #include <linux/leds.h>
+#include <linux/mod_devicetable.h>
 #include <linux/module.h>
-#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/pm.h>
+#include <linux/property.h>
 #include <linux/reset.h>
 #include <linux/spinlock.h>
 
@@ -247,13 +248,13 @@ static const char *const sun50i_a100_ledc_formats[] = {
 	"rgb", "rbg", "grb", "gbr", "brg", "bgr",
 };
 
-static int sun50i_a100_ledc_parse_format(const struct device_node *np,
+static int sun50i_a100_ledc_parse_format(struct device *dev,
 					 struct sun50i_a100_ledc *priv)
 {
 	const char *format = "grb";
 	u32 i;
 
-	of_property_read_string(np, "allwinner,pixel-format", &format);
+	device_property_read_string(dev, "allwinner,pixel-format", &format);
 
 	for (i = 0; i < ARRAY_SIZE(sun50i_a100_ledc_formats); i++) {
 		if (!strcmp(format, sun50i_a100_ledc_formats[i])) {
@@ -262,7 +263,7 @@ static int sun50i_a100_ledc_parse_format(const struct device_node *np,
 		}
 	}
 
-	return dev_err_probe(priv->dev, -EINVAL, "Bad pixel format '%s'\n", format);
+	return dev_err_probe(dev, -EINVAL, "Bad pixel format '%s'\n", format);
 }
 
 static void sun50i_a100_ledc_set_format(struct sun50i_a100_ledc *priv)
@@ -283,18 +284,18 @@ static const struct sun50i_a100_ledc_timing sun50i_a100_ledc_default_timing = {
 	.treset_ns = 300000,
 };
 
-static int sun50i_a100_ledc_parse_timing(const struct device_node *np,
+static int sun50i_a100_ledc_parse_timing(struct device *dev,
 					 struct sun50i_a100_ledc *priv)
 {
 	struct sun50i_a100_ledc_timing *timing = &priv->timing;
 
 	*timing = sun50i_a100_ledc_default_timing;
 
-	of_property_read_u32(np, "allwinner,t0h-ns", &timing->t0h_ns);
-	of_property_read_u32(np, "allwinner,t0l-ns", &timing->t0l_ns);
-	of_property_read_u32(np, "allwinner,t1h-ns", &timing->t1h_ns);
-	of_property_read_u32(np, "allwinner,t1l-ns", &timing->t1l_ns);
-	of_property_read_u32(np, "allwinner,treset-ns", &timing->treset_ns);
+	device_property_read_u32(dev, "allwinner,t0h-ns", &timing->t0h_ns);
+	device_property_read_u32(dev, "allwinner,t0l-ns", &timing->t0l_ns);
+	device_property_read_u32(dev, "allwinner,t1h-ns", &timing->t1h_ns);
+	device_property_read_u32(dev, "allwinner,t1l-ns", &timing->t1l_ns);
+	device_property_read_u32(dev, "allwinner,treset-ns", &timing->treset_ns);
 
 	return 0;
 }
@@ -388,13 +389,12 @@ static void sun50i_a100_ledc_dma_cleanup(void *data)
 
 static int sun50i_a100_ledc_probe(struct platform_device *pdev)
 {
-	const struct device_node *np = pdev->dev.of_node;
 	struct dma_slave_config dma_cfg = {};
 	struct led_init_data init_data = {};
 	struct sun50i_a100_ledc_led *led;
 	struct device *dev = &pdev->dev;
 	struct sun50i_a100_ledc *priv;
-	struct device_node *child;
+	struct fwnode_handle *child;
 	struct resource *mem;
 	u32 max_addr = 0;
 	u32 num_leds = 0;
@@ -404,19 +404,19 @@ static int sun50i_a100_ledc_probe(struct platform_device *pdev)
 	 * The maximum LED address must be known in sun50i_a100_ledc_resume() before
 	 * class device registration, so parse and validate the subnodes up front.
 	 */
-	for_each_available_child_of_node(np, child) {
+	device_for_each_child_node(dev, child) {
 		u32 addr, color;
 
-		ret = of_property_read_u32(child, "reg", &addr);
+		ret = fwnode_property_read_u32(child, "reg", &addr);
 		if (ret || addr >= LEDC_MAX_LEDS) {
-			of_node_put(child);
+			fwnode_handle_put(child);
 			return dev_err_probe(dev, -EINVAL, "'reg' must be between 0 and %d\n",
 					     LEDC_MAX_LEDS - 1);
 		}
 
-		ret = of_property_read_u32(child, "color", &color);
+		ret = fwnode_property_read_u32(child, "color", &color);
 		if (ret || color != LED_COLOR_ID_RGB) {
-			of_node_put(child);
+			fwnode_handle_put(child);
 			return dev_err_probe(dev, -EINVAL, "'color' must be LED_COLOR_ID_RGB\n");
 		}
 
@@ -437,11 +437,11 @@ static int sun50i_a100_ledc_probe(struct platform_device *pdev)
 	spin_lock_init(&priv->lock);
 	dev_set_drvdata(dev, priv);
 
-	ret = sun50i_a100_ledc_parse_format(np, priv);
+	ret = sun50i_a100_ledc_parse_format(dev, priv);
 	if (ret)
 		return ret;
 
-	ret = sun50i_a100_ledc_parse_timing(np, priv);
+	ret = sun50i_a100_ledc_parse_timing(dev, priv);
 	if (ret)
 		return ret;
 
@@ -504,11 +504,11 @@ static int sun50i_a100_ledc_probe(struct platform_device *pdev)
 		return ret;
 
 	led = priv->leds;
-	for_each_available_child_of_node(np, child) {
+	device_for_each_child_node(dev, child) {
 		struct led_classdev *cdev;
 
 		/* The node was already validated above. */
-		of_property_read_u32(child, "reg", &led->addr);
+		fwnode_property_read_u32(child, "reg", &led->addr);
 
 		led->subled_info[0].color_index = LED_COLOR_ID_RED;
 		led->subled_info[0].channel = 0;
@@ -524,7 +524,7 @@ static int sun50i_a100_ledc_probe(struct platform_device *pdev)
 		cdev->max_brightness = U8_MAX;
 		cdev->brightness_set = sun50i_a100_ledc_brightness_set;
 
-		init_data.fwnode = of_fwnode_handle(child);
+		init_data.fwnode = child;
 
 		ret = led_classdev_multicolor_register_ext(dev, &led->mc_cdev, &init_data);
 		if (ret) {
@@ -540,7 +540,7 @@ static int sun50i_a100_ledc_probe(struct platform_device *pdev)
 	return 0;
 
 err_put_child:
-	of_node_put(child);
+	fwnode_handle_put(child);
 	while (led-- > priv->leds)
 		led_classdev_multicolor_unregister(&led->mc_cdev);
 	sun50i_a100_ledc_suspend(&pdev->dev);
-- 
2.43.0.rc1.1.gbec44491f096



From jernej at kernel.org  Thu Dec 14 11:23:02 2023
From: jernej at kernel.org (Jernej Skrabec)
Date: Thu, 14 Dec 2023 20:23:02 +0100
Subject: [GIT PULL] Allwinner device tree changes for 6.8
Message-ID: <ZXtWFk-Bne835txP@archlinux>

Hi!

Please pull following DT changes for 6.8.

Best regards,
Jernej

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-for-6.8-1

for you to fetch changes up to 557e5347ba8bb050fec39c488486c4a948f2e4aa:

  arm64: dts: allwinner: h618: add Transpeed 8K618-T TV box (2023-12-14 19:53:04 +0100)

----------------------------------------------------------------
- new boards: Orange Pi Zero 2W, Transpeed 8K618-T

----------------------------------------------------------------
Andre Przywara (5):
      dt-bindings: arm: sunxi: add Orange Pi Zero 2W
      arm64: dts: allwinner: h616: add Orange Pi Zero 2W support
      dt-bindings: vendor-prefixes: add Transpeed
      dt-bindings: arm: sunxi: document Transpeed 8K618-T board name
      arm64: dts: allwinner: h618: add Transpeed 8K618-T TV box

 Documentation/devicetree/bindings/arm/sunxi.yaml   |  10 ++
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 arch/arm64/boot/dts/allwinner/Makefile             |   1 +
 .../dts/allwinner/sun50i-h618-orangepi-zero2w.dts  | 176 +++++++++++++++++++++
 .../allwinner/sun50i-h618-transpeed-8k618-t.dts    | 161 +++++++++++++++++++
 5 files changed, 350 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts


From eauger at redhat.com  Thu Dec 14 11:29:25 2023
From: eauger at redhat.com (Eric Auger)
Date: Thu, 14 Dec 2023 20:29:25 +0100
Subject: [PATCH v2 4/5] KVM: selftests: aarch64: Introduce
 pmu_event_filter_test
In-Reply-To: <72c68db7-3de0-4517-9410-fd19d4564fea@redhat.com>
References: <20231129072712.2667337-1-shahuang@redhat.com>
 <20231129072712.2667337-5-shahuang@redhat.com>
 <72c68db7-3de0-4517-9410-fd19d4564fea@redhat.com>
Message-ID: <e14dcae7-db8c-4a82-a829-b783e754163b@redhat.com>

Hi Shaoqin,

On 12/14/23 14:45, Eric Auger wrote:
> Hi Shaoqin,
> 
> On 11/29/23 08:27, Shaoqin Huang wrote:
>> Introduce pmu_event_filter_test for arm64 platforms. The test configures
>> PMUv3 for a vCPU, and sets different pmu event filters for the vCPU, and
>> check if the guest can use those events which user allow and can't use
>> those events which use deny.
>>
>> This test refactor the create_vpmu_vm() and make it a wrapper for
>> __create_vpmu_vm(), which allows some extra init code before
>> KVM_ARM_VCPU_PMU_V3_INIT.
>>
>> And this test use the KVM_ARM_VCPU_PMU_V3_FILTER attribute to set the
>> pmu event filter in KVM. And choose to filter two common event
>> branches_retired and instructions_retired, and let guest use the two
>> events in pmu. And check if the result is expected.
>>
>> Signed-off-by: Shaoqin Huang <shahuang at redhat.com>
>> ---
>>  tools/testing/selftests/kvm/Makefile          |   1 +
>>  .../kvm/aarch64/pmu_event_filter_test.c       | 231 ++++++++++++++++++
>>  .../selftests/kvm/include/aarch64/vpmu.h      |   4 +
>>  .../testing/selftests/kvm/lib/aarch64/vpmu.c  |  14 +-
>>  4 files changed, 248 insertions(+), 2 deletions(-)
>>  create mode 100644 tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
>>
>> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
>> index b60852c222ac..5f126e1a1dbf 100644
>> --- a/tools/testing/selftests/kvm/Makefile
>> +++ b/tools/testing/selftests/kvm/Makefile
>> @@ -155,6 +155,7 @@ TEST_GEN_PROGS_aarch64 += aarch64/arch_timer
>>  TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions
>>  TEST_GEN_PROGS_aarch64 += aarch64/hypercalls
>>  TEST_GEN_PROGS_aarch64 += aarch64/page_fault_test
>> +TEST_GEN_PROGS_aarch64 += aarch64/pmu_event_filter_test
>>  TEST_GEN_PROGS_aarch64 += aarch64/psci_test
>>  TEST_GEN_PROGS_aarch64 += aarch64/set_id_regs
>>  TEST_GEN_PROGS_aarch64 += aarch64/smccc_filter
>> diff --git a/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c b/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
>> new file mode 100644
>> index 000000000000..0e652fbdb37a
>> --- /dev/null
>> +++ b/tools/testing/selftests/kvm/aarch64/pmu_event_filter_test.c
>> @@ -0,0 +1,231 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * pmu_event_filter_test - Test user limit pmu event for guest.
>> + *
>> + * Copyright (c) 2023 Red Hat, Inc.
>> + *
>> + * This test checks if the guest only see the limited pmu event that userspace
>> + * sets, if the guest can use those events which user allow, and if the guest
>> + * can't use those events which user deny.
>> + * This test runs only when KVM_CAP_ARM_PMU_V3, KVM_ARM_VCPU_PMU_V3_FILTER
>> + * is supported on the host.
>> + */
>> +#include <kvm_util.h>
>> +#include <processor.h>
>> +#include <vgic.h>
>> +#include <vpmu.h>
>> +#include <test_util.h>
>> +#include <perf/arm_pmuv3.h>
>> +
>> +struct {
>> +	uint64_t branches_retired;
>> +	uint64_t instructions_retired;
>> +} pmc_results;
>> +
>> +static struct vpmu_vm *vpmu_vm;
>> +static uint64_t pmceid0;
>> +
>> +#define FILTER_NR 10
>> +
>> +struct test_desc {
>> +	const char *name;
>> +	void (*check_result)(void);
>> +	struct kvm_pmu_event_filter filter[FILTER_NR];
>> +};
>> +> +#define __DEFINE_FILTER(base, num, act)		\
>> +	((struct kvm_pmu_event_filter) {	\
>> +		.base_event	= base,		\
>> +		.nevents	= num,		\
>> +		.action		= act,		\
>> +	})
>> +
>> +#define DEFINE_FILTER(base, act) __DEFINE_FILTER(base, 1, act)
>> +
>> +#define EMPTY_FILTER	{ 0 }
>> +
>> +#define SW_INCR		0x0
>> +#define INST_RETIRED	0x8
>> +#define BR_RETIRED	0x21
>> +
>> +#define NUM_BRANCHES	10
>> +
>> +static void run_and_measure_loop(void)
>> +{
>> +	asm volatile(
>> +		"	mov	x10, %[loop]\n"
>> +		"1:	sub	x10, x10, #1\n"
>> +		"	cmp	x10, #0x0\n"
>> +		"	b.gt	1b\n"
>> +		:
>> +		: [loop] "r" (NUM_BRANCHES)
>> +		: "x10", "cc");
>> +}
>> +
>> +static void guest_code(void)
>> +{
>> +	uint64_t pmcr = read_sysreg(pmcr_el0);
>> +
>> +	pmu_disable_reset();
>> +
>> +	write_pmevtypern(0, BR_RETIRED);
>> +	write_pmevtypern(1, INST_RETIRED);
>> +	enable_counter(0);
>> +	enable_counter(1);
>> +	write_sysreg(pmcr | ARMV8_PMU_PMCR_E, pmcr_el0);
>> +
>> +	run_and_measure_loop();
>> +
>> +	write_sysreg(pmcr, pmcr_el0);
>> +
>> +	pmc_results.branches_retired = read_sysreg(pmevcntr0_el0);
>> +	pmc_results.instructions_retired = read_sysreg(pmevcntr1_el0);
>> +
>> +	GUEST_DONE();
>> +}
>> +
>> +static void guest_get_pmceid0(void)
>> +{
>> +	uint64_t pmceid0 = read_sysreg(pmceid0_el0);
>> +
>> +	GUEST_PRINTF("%lx\n", pmceid0);
>> +
>> +	GUEST_DONE();
>> +}
>> +
>> +static void pmu_event_filter_init(struct vpmu_vm *vm, void *arg)
>> +{
>> +	struct kvm_device_attr attr = {
>> +		.group	= KVM_ARM_VCPU_PMU_V3_CTRL,
>> +		.attr	= KVM_ARM_VCPU_PMU_V3_FILTER,
>> +	};
>> +	struct kvm_pmu_event_filter *filter = (struct kvm_pmu_event_filter *)arg;
>> +
>> +	while (filter && filter->nevents != 0) {
>> +		attr.addr = (uint64_t)filter;
>> +		vcpu_ioctl(vm->vcpu, KVM_SET_DEVICE_ATTR, &attr);
>> +		filter++;
>> +	}
>> +}
>> +
>> +static void create_vpmu_vm_with_filter(void *guest_code,
>> +				       struct kvm_pmu_event_filter *filter)
>> +{
>> +	vpmu_vm = __create_vpmu_vm(guest_code, pmu_event_filter_init, filter);
>> +}
>> +
>> +static void run_vcpu(struct kvm_vcpu *vcpu)
>> +{
>> +	struct ucall uc;
>> +
>> +	while (1) {
>> +		vcpu_run(vcpu);
>> +		switch (get_ucall(vcpu, &uc)) {
>> +		case UCALL_DONE:
>> +			return;
>> +		case UCALL_PRINTF:
>> +			pmceid0 = strtoll(uc.buffer, NULL, 16);
>> +			break;
>> +		default:
>> +			TEST_FAIL("Unknown ucall %lu", uc.cmd);
>> +		}
>> +	}
>> +}
>> +
>> +static void check_pmc_counting(void)
>> +{
>> +	uint64_t br = pmc_results.branches_retired;
>> +	uint64_t ir = pmc_results.instructions_retired;
>> +
>> +	TEST_ASSERT(br && br == NUM_BRANCHES, "Branch instructions retired = "
>> +		    "%lu (expected %u)", br, NUM_BRANCHES);
> have you tested on several machines? My experience with some events
> (MEM_ACCESS for instance) is that you have variance (sometimes
> significant) on some event count. I am a little bit scared that having
> this br == NUM_BRANCHES check without taking into account some margin
> will cause failures on some HW.

I confirm the usual suspect, Amberwing, does not like this check ;-)

augere at qualcomm-amberwing-rep-06:~/UPSTREAM/linux/tools/testing/selftests/kvm/aarch64#
./pmu_event_filter_test
==== Test Assertion Failure ====
  aarch64/pmu_event_filter_test.c:141: br && br == NUM_BRANCHES
  pid=7750 tid=7750 errno=4 - Interrupted system call
     1	0x0000000000401d6b: check_pmc_counting at pmu_event_filter_test.c:141
     2	0x0000000000401967: run_test at pmu_event_filter_test.c:173
     3	 (inlined by) for_each_test at pmu_event_filter_test.c:198
     4	 (inlined by) main at pmu_event_filter_test.c:264
     5	0x0000ffffaaa6c79b: ?? ??:0
     6	0x0000ffffaaa6c86b: ?? ??:0
     7	0x0000000000401aaf: _start at ??:?
  Branch instructions retired = 15 (expected 10)

Eric

> 
> in v1 I suggested to read to PMCEID* in a guest code to check if the
> event is supported. This method would also have the benefice to allow
> testing more complex filter range combinations.
>> +	TEST_ASSERT(ir, "Instructions retired = %lu (expected > 0)", ir);
>> +}
>> +
>> +static void check_pmc_not_counting(void)
>> +{
>> +	uint64_t br = pmc_results.branches_retired;
>> +	uint64_t ir = pmc_results.instructions_retired;
>> +
>> +	TEST_ASSERT(!br, "Branch instructions retired = %lu (expected 0)", br);
>> +	TEST_ASSERT(!ir, "Instructions retired = %lu (expected 0)", ir);
>> +}
>> +
>> +static void run_vcpu_and_sync_pmc_results(void)
>> +{
>> +	memset(&pmc_results, 0, sizeof(pmc_results));
>> +	sync_global_to_guest(vpmu_vm->vm, pmc_results);
>> +
>> +	run_vcpu(vpmu_vm->vcpu);
>> +
>> +	sync_global_from_guest(vpmu_vm->vm, pmc_results);
>> +}
>> +
>> +static void run_test(struct test_desc *t)
>> +{
>> +	pr_debug("Test: %s\n", t->name);
>> +
>> +	create_vpmu_vm_with_filter(guest_code, t->filter);
>> +
>> +	run_vcpu_and_sync_pmc_results();
>> +
>> +	t->check_result();
>> +
>> +	destroy_vpmu_vm(vpmu_vm);
>> +}
>> +
>> +static struct test_desc tests[] = {
>> +	{"without_filter", check_pmc_counting, { EMPTY_FILTER }},
>> +	{"member_allow_filter", check_pmc_counting,
>> +	 {DEFINE_FILTER(SW_INCR, 0), DEFINE_FILTER(INST_RETIRED, 0),
> Note the doc says that Event 0 (SW_INCR) is never filtered, as it
> doesn't count a hardware event
> 
> 
> I would use the defines exposed in the uapi
>> +#define KVM_PMU_EVENT_ALLOW	0
>> +#define KVM_PMU_EVENT_DENY	1
>> +	  DEFINE_FILTER(BR_RETIRED, 0), EMPTY_FILTER}},
>> +	{"member_deny_filter", check_pmc_not_counting,
>> +	 {DEFINE_FILTER(SW_INCR, 1), DEFINE_FILTER(INST_RETIRED, 1),
> what is the purpose of SW_INCR. YOu do not seem to test it anyway?
>> +	  DEFINE_FILTER(BR_RETIRED, 1), EMPTY_FILTER}},
>> +	{"not_member_deny_filter", check_pmc_counting,
>> +	 {DEFINE_FILTER(SW_INCR, 1), EMPTY_FILTER}},
>> +	{"not_member_allow_filter", check_pmc_not_counting,
>> +	 {DEFINE_FILTER(SW_INCR, 0), EMPTY_FILTER}},
>> +	{ 0 }
>> +};
>> +
>> +static void for_each_test(void)
>> +{
>> +	struct test_desc *t;
>> +
>> +	for (t = &tests[0]; t->name; t++)
>> +		run_test(t);
>> +}
>> +
>> +static bool kvm_supports_pmu_event_filter(void)
>> +{
>> +	int r;
>> +
>> +	vpmu_vm = create_vpmu_vm(guest_code);
>> +
>> +	r = __kvm_has_device_attr(vpmu_vm->vcpu->fd, KVM_ARM_VCPU_PMU_V3_CTRL,
>> +				  KVM_ARM_VCPU_PMU_V3_FILTER);
> you can use __vcpu_has_device_attr directly
>> +
>> +	destroy_vpmu_vm(vpmu_vm);
>> +	return !r;
>> +}
>> +
>> +static bool host_pmu_supports_events(void)
>> +{
>> +	vpmu_vm = create_vpmu_vm(guest_get_pmceid0);
>> +
>> +	run_vcpu(vpmu_vm->vcpu);
>> +
>> +	destroy_vpmu_vm(vpmu_vm);
>> +
>> +	return pmceid0 & (BR_RETIRED | INST_RETIRED);
> this will return true if either event is supported. I suspect this is
> not what you want.
>> +}
>> +
>> +int main(void)
>> +{
>> +	TEST_REQUIRE(kvm_has_cap(KVM_CAP_ARM_PMU_V3));
>> +	TEST_REQUIRE(kvm_supports_pmu_event_filter());
>> +	TEST_REQUIRE(host_pmu_supports_events());
>> +
>> +	for_each_test();
>> +}
>> diff --git a/tools/testing/selftests/kvm/include/aarch64/vpmu.h b/tools/testing/selftests/kvm/include/aarch64/vpmu.h
>> index 644dae3814b5..f103d0824f8a 100644
>> --- a/tools/testing/selftests/kvm/include/aarch64/vpmu.h
>> +++ b/tools/testing/selftests/kvm/include/aarch64/vpmu.h
>> @@ -18,6 +18,10 @@ struct vpmu_vm {
>>  	int gic_fd;
>>  };
>>  
>> +struct vpmu_vm *__create_vpmu_vm(void *guest_code,
>> +				 void (*init_pmu)(struct vpmu_vm *vm, void *arg),
>> +				 void *arg);
>> +
>>  struct vpmu_vm *create_vpmu_vm(void *guest_code);
>>  
>>  void destroy_vpmu_vm(struct vpmu_vm *vpmu_vm);
>> diff --git a/tools/testing/selftests/kvm/lib/aarch64/vpmu.c b/tools/testing/selftests/kvm/lib/aarch64/vpmu.c
>> index b3de8fdc555e..76ea03d607f1 100644
>> --- a/tools/testing/selftests/kvm/lib/aarch64/vpmu.c
>> +++ b/tools/testing/selftests/kvm/lib/aarch64/vpmu.c
>> @@ -7,8 +7,9 @@
>>  #include <vpmu.h>
>>  #include <perf/arm_pmuv3.h>
>>  
>> -/* Create a VM that has one vCPU with PMUv3 configured. */
>> -struct vpmu_vm *create_vpmu_vm(void *guest_code)
>> +struct vpmu_vm *__create_vpmu_vm(void *guest_code,
>> +				 void (*init_pmu)(struct vpmu_vm *vm, void *arg),
>> +				 void *arg)
>>  {
>>  	struct kvm_vcpu_init init;
>>  	uint8_t pmuver;
>> @@ -50,12 +51,21 @@ struct vpmu_vm *create_vpmu_vm(void *guest_code)
>>  		    "Unexpected PMUVER (0x%x) on the vCPU with PMUv3", pmuver);
>>  
>>  	/* Initialize vPMU */
>> +	if (init_pmu)
>> +		init_pmu(vpmu_vm, arg);
>> +
>>  	vcpu_ioctl(vpmu_vm->vcpu, KVM_SET_DEVICE_ATTR, &irq_attr);
>>  	vcpu_ioctl(vpmu_vm->vcpu, KVM_SET_DEVICE_ATTR, &init_attr);
>>  
>>  	return vpmu_vm;
>>  }
>>  
>> +/* Create a VM that has one vCPU with PMUv3 configured. */
>> +struct vpmu_vm *create_vpmu_vm(void *guest_code)
>> +{
>> +	return __create_vpmu_vm(guest_code, NULL, NULL);
>> +}
>> +
>>  void destroy_vpmu_vm(struct vpmu_vm *vpmu_vm)
>>  {
>>  	close(vpmu_vm->gic_fd);
> 
> Thanks
> 
> Eric



From rafael at kernel.org  Thu Dec 14 11:31:17 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Thu, 14 Dec 2023 20:31:17 +0100
Subject: [PATCH] cpufreq: CPPC: Resolve the large frequency discrepancy
 from cpuinfo_cur_freq
In-Reply-To: <20231212072617.14756-1-lihuisong@huawei.com>
References: <20231212072617.14756-1-lihuisong@huawei.com>
Message-ID: <CAJZ5v0jwW0=8cNvC-Vu_o+pEHFpN9nrPD4LXCpmSTgQBTHODgg@mail.gmail.com>

On Tue, Dec 12, 2023 at 8:26?AM Huisong Li <lihuisong at huawei.com> wrote:
>
> Many developers found that the cpu current frequency is greater than
> the maximum frequency of the platform, please see [1], [2] and [3].
>
> In the scenarios with high memory access pressure, the patch [1] has
> proved the significant latency of cpc_read() which is used to obtain
> delivered and reference performance counter cause an absurd frequency.
> The sampling interval for this counters is very critical and is expected
> to be equal. However, the different latency of cpc_read() has a direct
> impact on their sampling interval.
>
> This patch adds a interface, cpc_read_arch_counters_on_cpu, to read
> delivered and reference performance counter together. According to my
> test[4], the discrepancy of cpu current frequency in the scenarios with
> high memory access pressure is lower than 0.2% by stress-ng application.
>
> [1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4 at huawei.com/
> [2] https://lore.kernel.org/all/20230328193846.8757-1-yang at os.amperecomputing.com/
> [3] https://lore.kernel.org/all/20230418113459.12860-7-sumitg at nvidia.com/
>
> [4] My local test:
> The testing platform enable SMT and include 128 logical CPU in total,
> and CPU base frequency is 2.7GHz. Reading "cpuinfo_cur_freq" for each
> physical core on platform during the high memory access pressure from
> stress-ng, and the output is as follows:
>   0: 2699133     2: 2699942     4: 2698189     6: 2704347
>   8: 2704009    10: 2696277    12: 2702016    14: 2701388
>  16: 2700358    18: 2696741    20: 2700091    22: 2700122
>  24: 2701713    26: 2702025    28: 2699816    30: 2700121
>  32: 2700000    34: 2699788    36: 2698884    38: 2699109
>  40: 2704494    42: 2698350    44: 2699997    46: 2701023
>  48: 2703448    50: 2699501    52: 2700000    54: 2699999
>  56: 2702645    58: 2696923    60: 2697718    62: 2700547
>  64: 2700313    66: 2700000    68: 2699904    70: 2699259
>  72: 2699511    74: 2700644    76: 2702201    78: 2700000
>  80: 2700776    82: 2700364    84: 2702674    86: 2700255
>  88: 2699886    90: 2700359    92: 2699662    94: 2696188
>  96: 2705454    98: 2699260   100: 2701097   102: 2699630
> 104: 2700463   106: 2698408   108: 2697766   110: 2701181
> 112: 2699166   114: 2701804   116: 2701907   118: 2701973
> 120: 2699584   122: 2700474   124: 2700768   126: 2701963
>
> Signed-off-by: Huisong Li <lihuisong at huawei.com>

First off, please Cc ACPI-related patches to linux-acpi.

> ---
>  arch/arm64/kernel/topology.c | 43 ++++++++++++++++++++++++++++++++++--
>  drivers/acpi/cppc_acpi.c     | 22 +++++++++++++++---
>  include/acpi/cppc_acpi.h     |  5 +++++
>  3 files changed, 65 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 7d37e458e2f5..c3122154d738 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -299,6 +299,11 @@ core_initcall(init_amu_fie);
>  #ifdef CONFIG_ACPI_CPPC_LIB
>  #include <acpi/cppc_acpi.h>
>
> +struct amu_counters {
> +       u64 corecnt;
> +       u64 constcnt;
> +};
> +
>  static void cpu_read_corecnt(void *val)
>  {
>         /*
> @@ -322,8 +327,27 @@ static void cpu_read_constcnt(void *val)
>                       0UL : read_constcnt();
>  }
>
> +static void cpu_read_amu_counters(void *data)
> +{
> +       struct amu_counters *cnt = (struct amu_counters *)data;
> +
> +       /*
> +        * The running time of the this_cpu_has_cap() might have a couple of
> +        * microseconds and is significantly increased to tens of microseconds.
> +        * But AMU core and constant counter need to be read togeter without any
> +        * time interval to reduce the calculation discrepancy using this counters.
> +        */
> +       if (this_cpu_has_cap(ARM64_WORKAROUND_2457168)) {
> +               cnt->corecnt = read_corecnt();

This statement is present in both branches, so can it be moved before the if ()?

> +               cnt->constcnt = 0;
> +       } else {
> +               cnt->corecnt = read_corecnt();
> +               cnt->constcnt = read_constcnt();
> +       }
> +}
> +
>  static inline
> -int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
> +int counters_read_on_cpu(int cpu, smp_call_func_t func, void *data)
>  {
>         /*
>          * Abort call on counterless CPU or when interrupts are
> @@ -335,7 +359,7 @@ int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
>         if (WARN_ON_ONCE(irqs_disabled()))
>                 return -EPERM;
>
> -       smp_call_function_single(cpu, func, val, 1);
> +       smp_call_function_single(cpu, func, data, 1);
>
>         return 0;
>  }
> @@ -364,6 +388,21 @@ bool cpc_ffh_supported(void)
>         return true;
>  }
>
> +int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference)
> +{
> +       struct amu_counters cnts = {0};
> +       int ret;
> +
> +       ret = counters_read_on_cpu(cpu, cpu_read_amu_counters, &cnts);
> +       if (ret)
> +               return ret;
> +
> +       *delivered = cnts.corecnt;
> +       *reference = cnts.constcnt;
> +
> +       return 0;
> +}
> +
>  int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64 *val)
>  {
>         int ret = -EOPNOTSUPP;
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index 7ff269a78c20..f303fabd7cfe 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -1299,6 +1299,11 @@ bool cppc_perf_ctrs_in_pcc(void)
>  }
>  EXPORT_SYMBOL_GPL(cppc_perf_ctrs_in_pcc);
>
> +int __weak cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference)
> +{
> +       return 0;
> +}
> +
>  /**
>   * cppc_get_perf_ctrs - Read a CPU's performance feedback counters.
>   * @cpunum: CPU from which to read counters.
> @@ -1313,7 +1318,8 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
>                 *ref_perf_reg, *ctr_wrap_reg;
>         int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpunum);
>         struct cppc_pcc_data *pcc_ss_data = NULL;
> -       u64 delivered, reference, ref_perf, ctr_wrap_time;
> +       u64 delivered = 0, reference = 0;
> +       u64 ref_perf, ctr_wrap_time;
>         int ret = 0, regs_in_pcc = 0;
>
>         if (!cpc_desc) {
> @@ -1350,8 +1356,18 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
>                 }
>         }
>
> -       cpc_read(cpunum, delivered_reg, &delivered);
> -       cpc_read(cpunum, reference_reg, &reference);
> +       if (cpc_ffh_supported()) {
> +               ret = cpc_read_arch_counters_on_cpu(cpunum, &delivered, &reference);
> +               if (ret) {
> +                       pr_debug("read arch counters failed, ret=%d.\n", ret);
> +                       ret = 0;
> +               }
> +       }

The above is surely not applicable to every platform using CPPC.  Also
it looks like in the ARM64_WORKAROUND_2457168 enabled case it is just
pointless overhead, because "reference" is always going to be 0 here
then.

Please clean that up.

> +       if (!delivered || !reference) {
> +               cpc_read(cpunum, delivered_reg, &delivered);
> +               cpc_read(cpunum, reference_reg, &reference);
> +       }
> +
>         cpc_read(cpunum, ref_perf_reg, &ref_perf);
>
>         /*
> diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
> index 6126c977ece0..07d4fd82d499 100644
> --- a/include/acpi/cppc_acpi.h
> +++ b/include/acpi/cppc_acpi.h
> @@ -152,6 +152,7 @@ extern bool cpc_ffh_supported(void);
>  extern bool cpc_supported_by_cpu(void);
>  extern int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val);
>  extern int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val);
> +extern int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference);
>  extern int cppc_get_epp_perf(int cpunum, u64 *epp_perf);
>  extern int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable);
>  extern int cppc_get_auto_sel_caps(int cpunum, struct cppc_perf_caps *perf_caps);
> @@ -209,6 +210,10 @@ static inline int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val)
>  {
>         return -ENOTSUPP;
>  }
> +static inline int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference)
> +{
> +       return -EOPNOTSUPP;
> +}
>  static inline int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable)
>  {
>         return -ENOTSUPP;
> --


From jernej.skrabec at gmail.com  Thu Dec 14 11:32:09 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Thu, 14 Dec 2023 20:32:09 +0100
Subject: [PATCH v1 1/1] leds: sun50i-a100: Convert to be agnostic to property
 provider
In-Reply-To: <20231214192131.1309912-1-andriy.shevchenko@linux.intel.com>
References: <20231214192131.1309912-1-andriy.shevchenko@linux.intel.com>
Message-ID: <12339724.O9o76ZdvQC@archlinux>

On Thursday, December 14, 2023 8:21:31 PM CET Andy Shevchenko wrote:
> Convert the driver to be agnostic to the property provider.
> LEDS subsytem is not dependent on OF, so no need to make drivers
> be a such.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

Reviewed-by: Jernej Skrabec <jernej.skrabec at gmail.com>

Best regards,
Jernej




From Frank.Li at nxp.com  Thu Dec 14 11:46:54 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu, 14 Dec 2023 14:46:54 -0500
Subject: [PATCH 1/2] arm64: dts: imx8qm: Align edma3 power-domains resources indentation
Message-ID: <20231214194655.608902-1-Frank.Li@nxp.com>

<&pd IMX_SC_R_DMA_1_CH*> is now properly aligned with the previous line
for improved code readability.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
index 69cb8676732ea..453fabfd17b81 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
@@ -98,13 +98,13 @@ &edma2 {
 
 &edma3 {
 	power-domains = <&pd IMX_SC_R_DMA_1_CH0>,
-		     <&pd IMX_SC_R_DMA_1_CH1>,
-		     <&pd IMX_SC_R_DMA_1_CH2>,
-		     <&pd IMX_SC_R_DMA_1_CH3>,
-		     <&pd IMX_SC_R_DMA_1_CH4>,
-		     <&pd IMX_SC_R_DMA_1_CH5>,
-		     <&pd IMX_SC_R_DMA_1_CH6>,
-		     <&pd IMX_SC_R_DMA_1_CH7>;
+			<&pd IMX_SC_R_DMA_1_CH1>,
+			<&pd IMX_SC_R_DMA_1_CH2>,
+			<&pd IMX_SC_R_DMA_1_CH3>,
+			<&pd IMX_SC_R_DMA_1_CH4>,
+			<&pd IMX_SC_R_DMA_1_CH5>,
+			<&pd IMX_SC_R_DMA_1_CH6>,
+			<&pd IMX_SC_R_DMA_1_CH7>;
 };
 
 &flexcan1 {
-- 
2.34.1



From Frank.Li at nxp.com  Thu Dec 14 11:46:55 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Thu, 14 Dec 2023 14:46:55 -0500
Subject: [PATCH 2/2] arm64: dts: imx8qm: Correct edma3 power-domains and interrupt numbers
In-Reply-To: <20231214194655.608902-1-Frank.Li@nxp.com>
References: <20231214194655.608902-1-Frank.Li@nxp.com>
Message-ID: <20231214194655.608902-2-Frank.Li@nxp.com>

It is eDMA1 at QM, which have the same register with eDMA3 at qxp.

The below commit fix panic problem.
commit b37e75bddc35 ("arm64: dts: imx8qm: Add imx8qm's own pm to avoid panic during startup")

This fixes the IRQ and DMA channel numbers. While QM eDMA1 technically has
32 channels, only 10 channels are likely used for I2C. The exact IRQ
numbers for the remaining channels were unclear in the reference manual.

Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]")
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---
 .../arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
index 453fabfd17b81..cafc1383115ab 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
@@ -96,7 +96,20 @@ &edma2 {
 	status = "okay";
 };
 
+/* It is eDMA1 in 8QM RM, but 8QXP it is eDMA3 */
 &edma3 {
+	reg = <0x5a9f0000 0x210000>;
+	dma-channels = <10>;
+	interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 427 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 433 IRQ_TYPE_LEVEL_HIGH>;
 	power-domains = <&pd IMX_SC_R_DMA_1_CH0>,
 			<&pd IMX_SC_R_DMA_1_CH1>,
 			<&pd IMX_SC_R_DMA_1_CH2>,
@@ -104,7 +117,9 @@ &edma3 {
 			<&pd IMX_SC_R_DMA_1_CH4>,
 			<&pd IMX_SC_R_DMA_1_CH5>,
 			<&pd IMX_SC_R_DMA_1_CH6>,
-			<&pd IMX_SC_R_DMA_1_CH7>;
+			<&pd IMX_SC_R_DMA_1_CH7>,
+			<&pd IMX_SC_R_DMA_1_CH8>,
+			<&pd IMX_SC_R_DMA_1_CH9>;
 };
 
 &flexcan1 {
-- 
2.34.1



From yury.norov at gmail.com  Thu Dec 14 11:48:50 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Thu, 14 Dec 2023 11:48:50 -0800
Subject: [PATCH v10-mte 1/7] lib/bitmap: add bitmap_{read,write}()
In-Reply-To: <20231214110639.2294687-2-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
 <20231214110639.2294687-2-glider@google.com>
Message-ID: <ZXtcIqFhh1WMOGbG@yury-ThinkPad>

On Thu, Dec 14, 2023 at 12:06:33PM +0100, Alexander Potapenko wrote:
> From: Syed Nayyar Waris <syednwaris at gmail.com>
> 
> The two new functions allow reading/writing values of length up to
> BITS_PER_LONG bits at arbitrary position in the bitmap.
> 
> The code was taken from "bitops: Introduce the for_each_set_clump macro"
> by Syed Nayyar Waris with a number of changes and simplifications:
>  - instead of using roundup(), which adds an unnecessary dependency
>    on <linux/math.h>, we calculate space as BITS_PER_LONG-offset;
>  - indentation is reduced by not using else-clauses (suggested by
>    checkpatch for bitmap_get_value());
>  - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read()
>    and bitmap_write();
>  - some redundant computations are omitted.
> 
> Cc: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <william.gray at linaro.org>
> Link: https://lore.kernel.org/lkml/fe12eedf3666f4af5138de0e70b67a07c7f40338.1592224129.git.syednwaris at gmail.com/
> Suggested-by: Yury Norov <yury.norov at gmail.com>
> Co-developed-by: Alexander Potapenko <glider at google.com>
> Signed-off-by: Alexander Potapenko <glider at google.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

Acked-by: Yury Norov <yury.norov at gmail.com>


From yury.norov at gmail.com  Thu Dec 14 11:50:33 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Thu, 14 Dec 2023 11:50:33 -0800
Subject: [PATCH v10-mte 2/7] lib/test_bitmap: add tests for
 bitmap_{read,write}()
In-Reply-To: <20231214110639.2294687-3-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
 <20231214110639.2294687-3-glider@google.com>
Message-ID: <ZXtciaxTKFBiui/X@yury-ThinkPad>

On Thu, Dec 14, 2023 at 12:06:34PM +0100, Alexander Potapenko wrote:
> Add basic tests ensuring that values can be added at arbitrary positions
> of the bitmap, including those spanning into the adjacent unsigned
> longs.
> 
> Two new performance tests, test_bitmap_read_perf() and
> test_bitmap_write_perf(), can be used to assess future performance
> improvements of bitmap_read() and bitmap_write():
> 
> [    0.431119][    T1] test_bitmap: Time spent in test_bitmap_read_perf:	615253
> [    0.433197][    T1] test_bitmap: Time spent in test_bitmap_write_perf:	916313
> 
> (numbers from a Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz machine running
> QEMU).
> 
> Signed-off-by: Alexander Potapenko <glider at google.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
 
Acked-by: Yury Norov <yury.norov at gmail.com>


From yury.norov at gmail.com  Thu Dec 14 11:51:38 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Thu, 14 Dec 2023 11:51:38 -0800
Subject: [PATCH v10-mte 3/7] lib/test_bitmap: use pr_info() for non-error
 messages
In-Reply-To: <20231214110639.2294687-4-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
 <20231214110639.2294687-4-glider@google.com>
Message-ID: <ZXtcytNpfG9NSL7z@yury-ThinkPad>

On Thu, Dec 14, 2023 at 12:06:35PM +0100, Alexander Potapenko wrote:
> pr_err() messages may be treated as errors by some log readers, so let
> us only use them for test failures. For non-error messages, replace them
> with pr_info().
> 
> Suggested-by: Alexander Lobakin <aleksander.lobakin at intel.com>
> Signed-off-by: Alexander Potapenko <glider at google.com>

Acked-by: Yury Norov <yury.norov at gmail.com>


From sjg at chromium.org  Thu Dec 14 12:12:13 2023
From: sjg at chromium.org (Simon Glass)
Date: Thu, 14 Dec 2023 13:12:13 -0700
Subject: [PATCH] arm64: properly install vmlinuz.efi
In-Reply-To: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>
References: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>
Message-ID: <CAPnjgZ1ePt1zoPc4NvbHXkgKdG0MQZL2pYArBvCVaNgCqXaEqA@mail.gmail.com>

Hi Josef,

On Thu, 14 Dec 2023 at 09:19, Josef Bacik <josef at toxicpanda.com> wrote:
>
> If you select CONFIG_EFI_ZBOOT, we will generate vmlinuz.efi, and then
> when we go to install the kernel we'll install the vmlinux instead
> because install.sh only recognizes Image.gz as wanting the compressed
> install image.  With CONFIG_EFI_ZBOOT we don't get the proper kernel
> installed, which means it doesn't boot, which makes for a very confused
> and subsequently angry kernel developer.
>
> Fix this by properly installing our compressed kernel if we've enabled
> CONFIG_EFI_ZBOOT.
>
> Signed-off-by: Josef Bacik <josef at toxicpanda.com>
> ---
>  arch/arm64/boot/install.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
> index 7399d706967a..9b7a09808a3d 100755
> --- a/arch/arm64/boot/install.sh
> +++ b/arch/arm64/boot/install.sh
> @@ -17,7 +17,8 @@
>  #   $3 - kernel map file
>  #   $4 - default install path (blank if root directory)
>
> -if [ "$(basename $2)" = "Image.gz" ]; then
> +if [ "$(basename $2)" = "Image.gz" ] || [ "$(basename $2)" = "vmlinuz.efi" ]
> +then
>  # Compressed install
>    echo "Installing compressed kernel"
>    base=vmlinuz

This is a little messy.

There is a KBUILD_IMAGE var which should be usable, although I see
that it is set to $(boot)/Image when 'make install' is invoked.

Could we perhaps make sure that this var is set to the file to be installed?

I also wonder how useful it is to indicate whether the image is
compressed or not, so perhaps we could just say 'Installing kernel' ?

Regards,
Simon


From robh+dt at kernel.org  Thu Dec 14 12:13:04 2023
From: robh+dt at kernel.org (Rob Herring)
Date: Thu, 14 Dec 2023 14:13:04 -0600
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <20231214-stopper-bounce-ca9002869293@spud>
References: <20231212164004.1683589-1-ninad@linux.ibm.com> <20231212164004.1683589-3-ninad@linux.ibm.com>
 <20231212-amusement-elevation-28e42bcccc35@spud> <d8b5df1c-c732-4cf3-ae28-cc2017d3b0b6@linux.ibm.com>
 <20231214-stopper-bounce-ca9002869293@spud>
Message-ID: <CAL_JsqJCbRREnUyKkvkutyWP2GYK2ZqzfC1TS1pwQ=4xY_1J5w@mail.gmail.com>

On Thu, Dec 14, 2023 at 10:35?AM Conor Dooley <conor at kernel.org> wrote:
>
> On Thu, Dec 14, 2023 at 09:34:39AM -0600, Ninad Palsule wrote:
> > Hello Conor,
> >
> > On 12/12/23 11:14, Conor Dooley wrote:
> > > Hey,
> > >
> > > On Tue, Dec 12, 2023 at 10:39:58AM -0600, Ninad Palsule wrote:
> > > > From: Johannes Holland <johannes.holland at infineon.com>
> > > >
> > > > Add a dt schema to support device tree bindings
> > > "Add bindings for..."
> > Fixed.
> > >
> > > > for the generic I2C
> > > > physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
> > > > Specification for TPM 2.0 v1.04 Revision 14.
> > > >
> > > > This includes descriptions for the Nuvoton and Infineon devices.
> > > >
> > > > OpenBMC-Staging-Count: 3
> > > I have no idea what this is, but it needs to be removed from the patch.
> > Removed.
> > >
> > > > Signed-off-by: Johannes Holland <johannes.holland at infineon.com>
> > > > Signed-off-by: Joel Stanley <joel at jms.id.au>
> > > > Signed-off-by: Ninad Palsule <ninad at linux.ibm.com>
> > > > ---
> > > >   .../bindings/security/tpm/tpm-tis-i2c.yaml    | 50 +++++++++++++++++++
> > > >   1 file changed, 50 insertions(+)
> > > >   create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> > > > new file mode 100644
> > > > index 000000000000..de1e34065748
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> > > > @@ -0,0 +1,50 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: I2C PTP based TPM Devices
> > > > +
> > > > +maintainers:
> > > > +  - Johannes Holland <johannes.holland at infineon.com>
> > > > +
> > > > +description:
> > > > +  Device Tree Bindings for I2C based Trusted Platform Module (TPM).
> > > s/Device Tree Bindings for //. Doesn't dt_binding_check now complain if
> > > you have this in a title or description?
> > Fixed.
> > >
> > > > +properties:
> > > > +  $nodename:
> > > > +    pattern: "^tpm(@[0-9a-f]+)?$"
> > > > +
> > > > +  compatible:
> > > > +    oneOf:
> > > > +      - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
> > > > +        items:
> > > > +          - const: infineon,slb9673
> > > > +          - const: tcg,tpm-tis-i2c
> > > > +      - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
> > > > +        items:
> > > > +          - const: nuvoton,npct75x
> > > > +          - const: tcg,tpm-tis-i2c
>
> Also, another thought - the bus is not usually encoded in the compatible
> string, so it would be good to remove that.

True, but we already have 3 different bus variants in this case. So
that ship has sailed.

Rob


From yury.norov at gmail.com  Thu Dec 14 12:16:45 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Thu, 14 Dec 2023 12:16:45 -0800
Subject: [PATCH v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <20231214110639.2294687-5-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
 <20231214110639.2294687-5-glider@google.com>
Message-ID: <ZXtircr4TllpqyeS@yury-ThinkPad>

On Thu, Dec 14, 2023 at 12:06:36PM +0100, Alexander Potapenko wrote:
> The config implements the algorithm compressing memory tags for ARM MTE
> during swapping.
> 
> The algorithm is based on RLE and specifically targets buffers of tags
> corresponding to a single page. In many cases a buffer can be compressed
> into 63 bits, making it possible to store it without additional memory
> allocation.
> 
> Suggested-by: Evgenii Stepanov <eugenis at google.com>
> Signed-off-by: Alexander Potapenko <glider at google.com>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> 
> ---
>  v10-mte:
>   - added Catalin's Acked-by:
> 
>  v8:
>   - As suggested by Catalin Marinas, only compress tags if they can be
>     stored inline. This simplifies the code drastically.
>   - Update the documentation.
>   - Split off patches introducing bitmap_read()/bitmap_write().
> 
>  v6:
>   - shuffle bits in inline handles so that they can't be confused with
>     canonical pointers;
>   - use kmem_cache_zalloc() to allocate compressed storage
>   - correctly handle range size overflow
>   - minor documentation fixes, clarify the special cases
> 
>  v5:
>   - make code PAGE_SIZE-agnostic, remove hardcoded constants, updated
>     the docs
>   - implement debugfs interface
>   - Address comments by Andy Shevchenko:
>     - update description of mtecomp.c
>     - remove redundant assignments, simplify mte_tags_to_ranges()
>     - various code simplifications
>     - introduce mtecomp.h
>     - add :export: to Documentation/arch/arm64/mte-tag-compression.rst
> 
>  v4:
>   - Addressed comments by Andy Shevchenko:
>     - expanded "MTE" to "Memory Tagging Extension" in Kconfig
>     - fixed kernel-doc comments, moved them to C source
>     - changed variables to unsigned where applicable
>     - some code simplifications, fewer unnecessary assignments
>     - added the mte_largest_idx_bits() helper
>     - added namespace prefixes to all functions
>     - added missing headers (but removed bits.h)
>   - Addressed comments by Yury Norov:
>     - removed test-only functions from mtecomp.h
>     - dropped the algoritm name (all functions are now prefixed with
>       "mte")
>     - added more comments
>     - got rid of MTE_RANGES_INLINE
>     - renamed bitmap_{get,set}_value() to bitmap_{read,write}()
>     - moved the big comment explaining the algorithm to
>       Documentation/arch/arm64/mte-tag-compression.rst, expanded it,
>       add a link to it from Documentation/arch/arm64/index.rst
>     - removed hardcoded ranges from mte_alloc_size()/mte_size_to_ranges()
> 
>  v3:
>   - Addressed comments by Andy Shevchenko:
>    - use bitmap_{set,get}_value() writte by Syed Nayyar Waris
>    - switched to unsigned long everywhere (fewer casts)
>    - simplified the code, removed redundant checks
>    - dropped ea0_compress_inline()
>  - added bit size constants and helpers to access the bitmap
>  - explicitly initialize all compressed sizes in ea0_compress_to_buf()
>  - initialize all handle bits
> 
>  v2:
>   - as suggested by Yury Norov, switched from struct bitq (which is
>     not needed anymore) to <linux/bitmap.h>
>   - add missing symbol exports
> ---
>  Documentation/arch/arm64/index.rst            |   1 +
>  .../arch/arm64/mte-tag-compression.rst        | 154 +++++++++++
>  arch/arm64/Kconfig                            |  11 +
>  arch/arm64/include/asm/mtecomp.h              |  39 +++
>  arch/arm64/mm/Makefile                        |   1 +
>  arch/arm64/mm/mtecomp.c                       | 257 ++++++++++++++++++
>  arch/arm64/mm/mtecomp.h                       |  12 +
>  7 files changed, 475 insertions(+)
>  create mode 100644 Documentation/arch/arm64/mte-tag-compression.rst
>  create mode 100644 arch/arm64/include/asm/mtecomp.h
>  create mode 100644 arch/arm64/mm/mtecomp.c
>  create mode 100644 arch/arm64/mm/mtecomp.h
> 
> diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
> index d08e924204bf1..bf6c1583233a9 100644
> --- a/Documentation/arch/arm64/index.rst
> +++ b/Documentation/arch/arm64/index.rst
> @@ -19,6 +19,7 @@ ARM64 Architecture
>      legacy_instructions
>      memory
>      memory-tagging-extension
> +    mte-tag-compression
>      perf
>      pointer-authentication
>      ptdump
> diff --git a/Documentation/arch/arm64/mte-tag-compression.rst b/Documentation/arch/arm64/mte-tag-compression.rst
> new file mode 100644
> index 0000000000000..8fe6b51a9db6d
> --- /dev/null
> +++ b/Documentation/arch/arm64/mte-tag-compression.rst
> @@ -0,0 +1,154 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==================================================
> +Tag Compression for Memory Tagging Extension (MTE)
> +==================================================
> +
> +This document describes the algorithm used to compress memory tags used by the
> +ARM Memory Tagging Extension (MTE).
> +
> +Introduction
> +============
> +
> +MTE assigns tags to memory pages: for 4K pages those tags occupy 128 bytes
> +(256 4-bit tags each corresponding to a 16-byte MTE granule), for 16K pages -
> +512 bytes, for 64K pages - 2048 bytes. By default, MTE carves out 3.125% (1/16)
> +of the available physical memory to store the tags.
> +
> +When MTE pages are saved to swap, their tags need to be stored in the kernel
> +memory. If the system swap is used heavily, these tags may take a substantial
> +portion of the physical memory. To reduce memory waste, ``CONFIG_ARM64_MTE_COMP``
> +allows the kernel to store the tags in compressed form.
> +
> +Implementation details
> +======================
> +
> +The algorithm attempts to compress an array of ``MTE_PAGE_TAG_STORAGE``
> +tag bytes into a byte sequence that can be stored in an 8-byte pointer. If that
> +is not possible, the data is stored uncompressed.
> +
> +Tag manipulation and storage
> +----------------------------
> +
> +Tags for swapped pages are stored in an XArray that maps swap entries to 63-bit
> +values (see ``arch/arm64/mm/mteswap.c``). Bit 0 of these values indicates how
> +their contents should be treated:
> +
> + - 0: value is a pointer to an uncompressed buffer allocated with kmalloc()
> +   (always the case if ``CONFIG_ARM64_MTE_COMP=n``) with the highest bit set
> +   to 0;
> + - 1: value contains compressed data.
> +
> +``arch/arm64/include/asm/mtecomp.h`` declares the following functions that
> +manipulate with tags:
> +
> +- mte_compress() - compresses the given ``MTE_PAGE_TAG_STORAGE``-byte ``tags``
> +  buffer into a pointer;
> +- mte_decompress() - decompresses the tags from a pointer;
> +- mte_is_compressed() - returns ``true`` iff the pointer passed to it should be
> +  treated as compressed data.
> +
> +Tag compression
> +---------------
> +
> +The compression algorithm is a variation of RLE (run-length encoding) and works
> +as follows (we will be considering 4K pages and 128-byte tag buffers, but the
> +same approach scales to 16K and 64K pages):
> +
> +1. The input array of 128 (``MTE_PAGE_TAG_STORAGE``) bytes is transformed into
> +   tag ranges (two arrays: ``r_tags[]`` containing tag values and ``r_sizes[]``
> +   containing range lengths) by mte_tags_to_ranges(). Note that
> +   ``r_sizes[]`` sums up to 256 (``MTE_GRANULES_PER_PAGE``).
> +
> +   If ``r_sizes[]`` consists of a single element
> +   (``{ MTE_GRANULES_PER_PAGE }``), the corresponding range is split into two
> +   halves, i.e.::
> +
> +     r_sizes_new[2] = { MTE_GRANULES_PER_PAGE/2, MTE_GRANULES_PER_PAGE/2 };
> +     r_tags_new[2] = { r_tags[0], r_tags[0] };
> +
> +2. The number of the largest element of ``r_sizes[]`` is stored in
> +   ``largest_idx``. The element itself is thrown away from ``r_sizes[]``,
> +   because it can be reconstructed from the sum of the remaining elements. Note
> +   that now none of the remaining ``r_sizes[]`` elements exceeds
> +   ``MTE_GRANULES_PER_PAGE/2``.
> +
> +3. If the number ``N`` of ranges does not exceed ``6``, the ranges can be
> +   compressed into 64 bits. This is done by storing the following values packed
> +   into the pointer (``i<size>`` means a ``<size>``-bit unsigned integer)
> +   treated as a bitmap (see ``include/linux/bitmap.h``)::
> +
> +    bit 0      :      (always 1) : i1
> +    bits 1-3   :     largest_idx : i3
> +    bits 4-27  :    r_tags[0..5] : i4 x 6
> +    bits 28-62 :   r_sizes[0..4] : i7 x 5
> +    bit 63     :      (always 0) : i1
> +
> +   If N is less than 6, ``r_tags`` and ``r_sizes`` are padded up with zero
> +   values. The unused bits in the pointer, including bit 63, are also set to 0,
> +   so the compressed data can be stored in XArray.
> +
> +   Range size of ``MTE_GRANULES_PER_PAGE/2`` (at most one) does not fit into
> +   i7 and will be written as 0. This case is handled separately by the
> +   decompressing procedure.
> +
> +Tag decompression
> +-----------------
> +
> +The decompression algorithm performs the steps below.
> +
> +1. Read the lowest bit of the data from the input buffer and check that it is 1,
> +   otherwise bail out.
> +
> +2. Read ``largest_idx``, ``r_tags[]`` and ``r_sizes[]`` from the
> +   input buffer.
> +
> +   If ``largest_idx`` is zero, and all ``r_sizes[]`` are zero, set
> +   ``r_sizes[0] = MTE_GRANULES_PER_PAGE/2``.
> +
> +   Calculate the removed largest element of ``r_sizes[]`` as
> +   ``largest = 256 - sum(r_sizes)`` and insert it into ``r_sizes`` at
> +   position ``largest_idx``.
> +
> +6. For each ``r_sizes[i] > 0``, add a 4-bit value ``r_tags[i]`` to the output
> +   buffer ``r_sizes[i]`` times.
> +
> +
> +Why these numbers?
> +------------------
> +
> +To be able to reconstruct ``N`` tag ranges from the compressed data, we need to
> +store the indicator bit together with ``largest_idx``, ``r_tags[N]``, and
> +``r_sizes[N-1]`` in 63 bits.
> +Knowing that the sizes do not exceed ``MTE_PAGE_TAG_STORAGE``, each of them can be
> +packed into ``S = ilog2(MTE_PAGE_TAG_STORAGE)`` bits, whereas a single tag occupies
> +4 bits.
> +
> +It is evident that the number of ranges that can be stored in 63 bits is
> +strictly less than 8, therefore we only need 3 bits to store ``largest_idx``.
> +
> +The maximum values of ``N`` so that the number ``1 + 3 + N * 4 + (N-1) * S`` of
> +storage bits does not exceed 63, are shown in the table below::
> +
> + +-----------+-----------------+----+---+-------------------+
> + | Page size | Tag buffer size |  S | N |    Storage bits   |
> + +-----------+-----------------+----+---+-------------------+
> + |      4 KB |           128 B |  7 | 6 | 63 = 1+3+6*4+5*7  |
> + |     16 KB |           512 B |  9 | 5 | 60 = 1+3+5*4+4*9  |
> + |     64 KB |          2048 B | 11 | 4 | 53 = 1+3+4*4+3*11 |
> + +-----------+-----------------+----+---+-------------------+
> +
> +Note
> +----
> +
> +Tag compression and decompression implicitly rely on the fixed MTE tag size
> +(4 bits) and number of tags per page. Should these values change, the algorithm
> +may need to be revised.
> +
> +
> +Programming Interface
> +=====================
> +
> + .. kernel-doc:: arch/arm64/include/asm/mtecomp.h
> + .. kernel-doc:: arch/arm64/mm/mtecomp.c
> +   :export:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7b071a00425d2..5f4d4b49a512e 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2078,6 +2078,17 @@ config ARM64_EPAN
>  	  if the cpu does not implement the feature.
>  endmenu # "ARMv8.7 architectural features"
>  
> +config ARM64_MTE_COMP
> +	bool "Tag compression for ARM64 Memory Tagging Extension"
> +	default y
> +	depends on ARM64_MTE
> +	help
> +	  Enable tag compression support for ARM64 Memory Tagging Extension.
> +
> +	  Tag buffers corresponding to swapped RAM pages are compressed using
> +	  RLE to conserve heap memory. In the common case compressed tags
> +	  occupy 2.5x less memory.
> +
>  config ARM64_SVE
>  	bool "ARM Scalable Vector Extension support"
>  	default y
> diff --git a/arch/arm64/include/asm/mtecomp.h b/arch/arm64/include/asm/mtecomp.h
> new file mode 100644
> index 0000000000000..b9a3a921a38d4
> --- /dev/null
> +++ b/arch/arm64/include/asm/mtecomp.h
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef __ASM_MTECOMP_H
> +#define __ASM_MTECOMP_H
> +
> +#include <linux/types.h>
> +
> +/**
> + * mte_is_compressed() - check if the supplied pointer contains compressed tags.
> + * @ptr: pointer returned by kmalloc() or mte_compress().
> + *
> + * Returns: true iff bit 0 of @ptr is 1, which is only possible if @ptr was
> + * returned by mte_is_compressed().
> + */
> +static inline bool mte_is_compressed(void *ptr)
> +{
> +	return ((unsigned long)ptr & 1);
> +}
> +
> +#if defined(CONFIG_ARM64_MTE_COMP)
> +
> +void *mte_compress(u8 *tags);
> +bool mte_decompress(void *handle, u8 *tags);
> +
> +#else
> +
> +static inline void *mte_compress(u8 *tags)
> +{
> +	return NULL;
> +}
> +
> +static inline bool mte_decompress(void *data, u8 *tags)
> +{
> +	return false;
> +}
> +
> +#endif // CONFIG_ARM64_MTE_COMP
> +
> +#endif // __ASM_MTECOMP_H
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index dbd1bc95967d0..46778f6dd83c2 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd.o
>  obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd-asm.o
>  obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o
>  obj-$(CONFIG_ARM64_MTE)		+= mteswap.o
> +obj-$(CONFIG_ARM64_MTE_COMP)	+= mtecomp.o
>  KASAN_SANITIZE_physaddr.o	+= n
>  
>  obj-$(CONFIG_KASAN)		+= kasan_init.o
> diff --git a/arch/arm64/mm/mtecomp.c b/arch/arm64/mm/mtecomp.c
> new file mode 100644
> index 0000000000000..c948921525030
> --- /dev/null
> +++ b/arch/arm64/mm/mtecomp.c
> @@ -0,0 +1,257 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +/*
> + * MTE tag compression algorithm.
> + * See Documentation/arch/arm64/mte-tag-compression.rst for more details.
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/bitmap.h>
> +#include <linux/bitops.h>
> +#include <linux/export.h>
> +#include <linux/gfp.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +
> +#include <asm/mtecomp.h>
> +
> +#include "mtecomp.h"
> +
> +#define MTE_BITS_PER_LARGEST_IDX 3
> +/* Range size cannot exceed MTE_GRANULES_PER_PAGE / 2. */
> +#define MTE_BITS_PER_SIZE (ilog2(MTE_GRANULES_PER_PAGE) - 1)
> +
> +/*
> + * See Documentation/arch/arm64/mte-tag-compression.rst for details on how the
> + * maximum number of ranges is calculated.
> + */
> +#if defined(CONFIG_ARM64_4K_PAGES)
> +#define MTE_MAX_RANGES 6
> +#elif defined(CONFIG_ARM64_16K_PAGES)
> +#define MTE_MAX_RANGES 5
> +#else
> +#define MTE_MAX_RANGES 4
> +#endif
> +
> +/**
> + * mte_tags_to_ranges() - break @tags into arrays of tag ranges.
> + * @tags: MTE_GRANULES_PER_PAGE-byte array containing MTE tags.
> + * @out_tags: u8 array to store the tag of every range.
> + * @out_sizes: unsigned short array to store the size of every range.
> + * @out_len: length of @out_tags and @out_sizes (output parameter, initially
> + *           equal to lengths of out_tags[] and out_sizes[]).
> + *
> + * This function is exported for testing purposes.
> + */
> +void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
> +			size_t *out_len)
> +{
> +	u8 prev_tag = tags[0] / 16; /* First tag in the array. */
> +	unsigned int cur_idx = 0, i, j;
> +	u8 cur_tag;
> +
> +	memset(out_tags, 0, array_size(*out_len, sizeof(*out_tags)));
> +	memset(out_sizes, 0, array_size(*out_len, sizeof(*out_sizes)));
> +
> +	out_tags[cur_idx] = prev_tag;
> +	for (i = 0; i < MTE_GRANULES_PER_PAGE; i++) {
> +		j = i % 2;
> +		cur_tag = j ? (tags[i / 2] % 16) : (tags[i / 2] / 16);
> +		if (cur_tag == prev_tag) {
> +			out_sizes[cur_idx]++;
> +		} else {
> +			cur_idx++;
> +			prev_tag = cur_tag;
> +			out_tags[cur_idx] = prev_tag;
> +			out_sizes[cur_idx] = 1;
> +		}
> +	}
> +	*out_len = cur_idx + 1;
> +}
> +EXPORT_SYMBOL_NS(mte_tags_to_ranges, MTECOMP);
> +
> +/**
> + * mte_ranges_to_tags() - fill @tags using given tag ranges.
> + * @r_tags: u8[] containing the tag of every range.
> + * @r_sizes: unsigned short[] containing the size of every range.
> + * @r_len: length of @r_tags and @r_sizes.
> + * @tags: MTE_GRANULES_PER_PAGE-byte array to write the tags to.
> + *
> + * This function is exported for testing purposes.
> + */
> +void mte_ranges_to_tags(u8 *r_tags, unsigned short *r_sizes, size_t r_len,
> +			u8 *tags)
> +{
> +	unsigned int i, j, pos = 0;
> +	u8 prev;
> +
> +	for (i = 0; i < r_len; i++) {
> +		for (j = 0; j < r_sizes[i]; j++) {
> +			if (pos % 2)
> +				tags[pos / 2] = (prev << 4) | r_tags[i];
> +			else
> +				prev = r_tags[i];
> +			pos++;
> +		}
> +	}
> +}
> +EXPORT_SYMBOL_NS(mte_ranges_to_tags, MTECOMP);
> +
> +static void mte_bitmap_write(unsigned long *bitmap, unsigned long value,
> +			     unsigned long *pos, unsigned long bits)
> +{
> +	bitmap_write(bitmap, value, *pos, bits);
> +	*pos += bits;
> +}
> +
> +/* Compress ranges into an unsigned long. */
> +static void mte_compress_to_ulong(size_t len, u8 *tags, unsigned short *sizes,
> +				  unsigned long *result)
> +{
> +	unsigned long bit_pos = 0;
> +	unsigned int largest_idx, i;
> +	unsigned short largest = 0;
> +
> +	for (i = 0; i < len; i++) {
> +		if (sizes[i] > largest) {
> +			largest = sizes[i];
> +			largest_idx = i;
> +		}
> +	}
> +	/* Bit 1 in position 0 indicates compressed data. */
> +	mte_bitmap_write(result, 1, &bit_pos, 1);
> +	mte_bitmap_write(result, largest_idx, &bit_pos,
> +			 MTE_BITS_PER_LARGEST_IDX);
> +	for (i = 0; i < len; i++)
> +		mte_bitmap_write(result, tags[i], &bit_pos, MTE_TAG_SIZE);
> +	if (len == 1) {
> +		/*
> +		 * We are compressing MTE_GRANULES_PER_PAGE of identical tags.
> +		 * Split it into two ranges containing
> +		 * MTE_GRANULES_PER_PAGE / 2 tags, so that it falls into the
> +		 * special case described below.
> +		 */
> +		mte_bitmap_write(result, tags[0], &bit_pos, MTE_TAG_SIZE);
> +		i = 2;
> +	} else {
> +		i = len;
> +	}
> +	for (; i < MTE_MAX_RANGES; i++)
> +		mte_bitmap_write(result, 0, &bit_pos, MTE_TAG_SIZE);
> +	/*
> +	 * Most of the time sizes[i] fits into MTE_BITS_PER_SIZE, apart from a
> +	 * special case when:
> +	 *   len = 2;
> +	 *   sizes = { MTE_GRANULES_PER_PAGE / 2, MTE_GRANULES_PER_PAGE / 2};
> +	 * In this case largest_idx will be set to 0, and the size written to
> +	 * the bitmap will be also 0.
> +	 */
> +	for (i = 0; i < len; i++) {
> +		if (i != largest_idx)
> +			mte_bitmap_write(result, sizes[i], &bit_pos,
> +					 MTE_BITS_PER_SIZE);
> +	}
> +	for (i = len; i < MTE_MAX_RANGES; i++)
> +		mte_bitmap_write(result, 0, &bit_pos, MTE_BITS_PER_SIZE);
> +}
> +
> +/**
> + * mte_compress() - compress the given tag array.
> + * @tags: MTE_GRANULES_PER_PAGE-byte array to read the tags from.
> + *
> + * Attempts to compress the user-supplied tag array.
> + *
> + * Returns: compressed data or NULL.
> + */
> +void *mte_compress(u8 *tags)
> +{
> +	unsigned short *r_sizes;
> +	void *result = NULL;
> +	u8 *r_tags;
> +	size_t r_len;
> +
> +	r_sizes = kmalloc_array(MTE_GRANULES_PER_PAGE, sizeof(unsigned short),
> +				GFP_KERNEL);
> +	r_tags = kmalloc(MTE_GRANULES_PER_PAGE, GFP_KERNEL);
> +	if (!r_sizes || !r_tags)
> +		goto ret;
> +	r_len = MTE_GRANULES_PER_PAGE;
> +	mte_tags_to_ranges(tags, r_tags, r_sizes, &r_len);
> +	if (r_len <= MTE_MAX_RANGES)
> +		mte_compress_to_ulong(r_len, r_tags, r_sizes,
> +				      (unsigned long *)&result);
> +ret:
> +	kfree(r_tags);
> +	kfree(r_sizes);
> +	return result;
> +}
> +EXPORT_SYMBOL_NS(mte_compress, MTECOMP);
> +
> +static unsigned long mte_bitmap_read(const unsigned long *bitmap,
> +				     unsigned long *pos, unsigned long bits)
> +{
> +	unsigned long start = *pos;
> +
> +	*pos += bits;
> +	return bitmap_read(bitmap, start, bits);
> +}
> +
> +/**
> + * mte_decompress() - decompress the tag array from the given pointer.
> + * @data: pointer returned by @mte_compress()
> + * @tags: MTE_GRANULES_PER_PAGE-byte array to write the tags to.
> + *
> + * Reads the compressed data and writes it into the user-supplied tag array.
> + *
> + * Returns: true on success, false if the passed data is uncompressed.
> + */
> +bool mte_decompress(void *data, u8 *tags)
> +{
> +	unsigned short r_sizes[MTE_MAX_RANGES];
> +	u8 r_tags[MTE_MAX_RANGES];
> +	unsigned int largest_idx, i;
> +	unsigned long bit_pos = 0;
> +	unsigned long *bitmap;
> +	unsigned short sum;
> +	size_t max_ranges;
> +
> +	if (!mte_is_compressed(data))
> +		return false;
> +
> +	bitmap = (unsigned long *)&data;

That looks weird... You're casting address of a 'data' to a bitmap
instead of 'data'. At the 1st glance it makes little sense because
'data' is passed as parameter. Moreover, in mte_is_compressed()
you pass 'data', not '&data'. Can you please comment on your
intention?

> +	max_ranges = MTE_MAX_RANGES;
> +	/* Skip the leading bit indicating the inline case. */
> +	mte_bitmap_read(bitmap, &bit_pos, 1);
> +	largest_idx =
> +		mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_LARGEST_IDX);

Nit: really no need to split the line - we're OK with 100-chars per
line now.

> +	if (largest_idx >= MTE_MAX_RANGES)
> +		return false;
> +
> +	for (i = 0; i < max_ranges; i++)
> +		r_tags[i] = mte_bitmap_read(bitmap, &bit_pos, MTE_TAG_SIZE);
> +	for (i = 0, sum = 0; i < max_ranges; i++) {
> +		if (i == largest_idx)
> +			continue;
> +		r_sizes[i] =
> +			mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_SIZE);
> +		/*
> +		 * Special case: tag array consists of two ranges of
> +		 * `MTE_GRANULES_PER_PAGE / 2` tags.
> +		 */
> +		if ((largest_idx == 0) && (i == 1) && (r_sizes[i] == 0))
> +			r_sizes[i] = MTE_GRANULES_PER_PAGE / 2;
> +		if (!r_sizes[i]) {
> +			max_ranges = i;
> +			break;
> +		}
> +		sum += r_sizes[i];
> +	}
> +	if (sum >= MTE_GRANULES_PER_PAGE)
> +		return false;
> +	r_sizes[largest_idx] = MTE_GRANULES_PER_PAGE - sum;
> +	mte_ranges_to_tags(r_tags, r_sizes, max_ranges, tags);
> +	return true;
> +}
> +EXPORT_SYMBOL_NS(mte_decompress, MTECOMP);
> diff --git a/arch/arm64/mm/mtecomp.h b/arch/arm64/mm/mtecomp.h
> new file mode 100644
> index 0000000000000..b94cf0384f2af
> --- /dev/null
> +++ b/arch/arm64/mm/mtecomp.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef ARCH_ARM64_MM_MTECOMP_H_
> +#define ARCH_ARM64_MM_MTECOMP_H_
> +
> +/* Functions exported from mtecomp.c for test_mtecomp.c. */
> +void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
> +			size_t *out_len);
> +void mte_ranges_to_tags(u8 *r_tags, unsigned short *r_sizes, size_t r_len,
> +			u8 *tags);
> +
> +#endif  // ARCH_ARM64_MM_TEST_MTECOMP_H_
> -- 
> 2.43.0.472.g3155946c3a-goog


From yury.norov at gmail.com  Thu Dec 14 12:21:33 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Thu, 14 Dec 2023 12:21:33 -0800
Subject: [PATCH v10-mte 7/7] arm64: mte: implement
 CONFIG_ARM64_MTE_SWAP_STATS
In-Reply-To: <20231214110639.2294687-8-glider@google.com>
References: <20231214110639.2294687-1-glider@google.com>
 <20231214110639.2294687-8-glider@google.com>
Message-ID: <ZXtjzQmnOz+GGPGW@yury-ThinkPad>

On Thu, Dec 14, 2023 at 12:06:39PM +0100, Alexander Potapenko wrote:
> Provide a config to collect the usage statistics for ARM MTE tag
> compression. This patch introduces allocation/deallocation counters
> for buffers that were stored uncompressed (and thus occupy 128 bytes of
> heap plus the Xarray overhead to store a pointer) and those that were
> compressed into 8-byte pointers (effectively using 0 bytes of heap in
> addition to the Xarray overhead).
> 
> The counters are exposed to the userspace via
> /sys/kernel/debug/mteswap/stats:
> 
>   # cat /sys/kernel/debug/mteswap/stats
>   8 bytes:      102496 allocations,     67302 deallocations
>   128 bytes:    212234 allocations,     178278 deallocations
>   uncompressed tag storage size:        8851200
>   compressed tag storage size:  4346368
> 
> Suggested-by: Yury Norov <yury.norov at gmail.com>
> Signed-off-by: Alexander Potapenko <glider at google.com>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>

Reviewed-by: Yury Norov <yury.norov at gmail.com>


From madvenka at linux.microsoft.com  Thu Dec 14 12:49:29 2023
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 14 Dec 2023 14:49:29 -0600
Subject: ARM64 Livepatch based on SFrame
In-Reply-To: <ZByJmnc/XDcqQwoZ@FVFF77S0Q05N.cambridge.arm.com>
References: <0337266cf19f4c98388e3f6d09f590d9de258dc7>
 <20230202074036.507249-1-madvenka@linux.microsoft.com>
 <ZByJmnc/XDcqQwoZ@FVFF77S0Q05N.cambridge.arm.com>
Message-ID: <72364198-b031-4ecc-b337-d07db1b9d0c8@linux.microsoft.com>

Hi Mark,

I attended your presentation in the LPC. You mentioned that you could use some help with some pre-requisites for the Livepatch feature.
I would like to lend a hand.

What would you like me to implement?

I would also like to implement Unwind Hints for the feature. If you want a specific format for the hints, let me know.

Looking forward to help out with the feature.

Madhavan


From markhas at chromium.org  Thu Dec 14 13:04:45 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Thu, 14 Dec 2023 14:04:45 -0700
Subject: [PATCH v1 2/6] arm: arm64: dts: Enable cros-ec-spi as wake source
In-Reply-To: <20231213221124.GB2115075-robh@kernel.org>
References: <20231213110009.v1.1.Ifd0903f1c351e84376d71dbdadbd43931197f5ea@changeid>
 <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid> <20231213221124.GB2115075-robh@kernel.org>
Message-ID: <CANg-bXCG61HFW7JFuAd3k+OrCG_F9F3e8brjM-pmBauS53aobQ@mail.gmail.com>

> If a device knows it is wakeup capable, why do you need a property too?

I'm referencing:
https://www.kernel.org/doc/Documentation/devicetree/bindings/power/wakeup-source.txt
"Nodes that describe devices which has wakeup capability must contain
an "wakeup-source" boolean property."

Currently the driver assumes the device is wake capable without
parsing the device tree, which is an incorrect assumption as wake
capability should not be enabled on some cros_ec systems.

> I haven't looked closely enough, but it smells like after patch 6, these
> properties would be required for wakeup? That would be an ABI break.

Agreed. In this case, the driver is a ChromeOS related driver and DTS
is built from source for each OS update.
For more context, I will make sure to CC you (and everyone else) and
include a cover letter in the next series version.


From ben.levinsky at amd.com  Thu Dec 14 13:13:52 2023
From: ben.levinsky at amd.com (Ben Levinsky)
Date: Thu, 14 Dec 2023 13:13:52 -0800
Subject: [PATCH 1/3] mailbox: zynqmp: Move of_match structure closer to usage
In-Reply-To: <20231214211354.348294-1-ben.levinsky@amd.com>
References: <20231214211354.348294-1-ben.levinsky@amd.com>
Message-ID: <20231214211354.348294-2-ben.levinsky@amd.com>

The of_match structure zynqmp_ipi_of_match is now adjacent to where it
used in the zynqmp_ipi_driver structure for readability.

Signed-off-by: Ben Levinsky <ben.levinsky at amd.com>
---
 drivers/mailbox/zynqmp-ipi-mailbox.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
index 7fa533e80dd9..2c10aa01b3bb 100644
--- a/drivers/mailbox/zynqmp-ipi-mailbox.c
+++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
@@ -416,11 +416,6 @@ static struct mbox_chan *zynqmp_ipi_of_xlate(struct mbox_controller *mbox,
 	return chan;
 }
 
-static const struct of_device_id zynqmp_ipi_of_match[] = {
-	{ .compatible = "xlnx,zynqmp-ipi-mailbox" },
-	{},
-};
-MODULE_DEVICE_TABLE(of, zynqmp_ipi_of_match);
 
 /**
  * zynqmp_ipi_mbox_get_buf_res - Get buffer resource from the IPI dev node
@@ -698,6 +693,12 @@ static int zynqmp_ipi_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id zynqmp_ipi_of_match[] = {
+	{ .compatible = "xlnx,zynqmp-ipi-mailbox" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, zynqmp_ipi_of_match);
+
 static struct platform_driver zynqmp_ipi_driver = {
 	.probe = zynqmp_ipi_probe,
 	.remove = zynqmp_ipi_remove,
-- 
2.25.1



From ben.levinsky at amd.com  Thu Dec 14 13:13:53 2023
From: ben.levinsky at amd.com (Ben Levinsky)
Date: Thu, 14 Dec 2023 13:13:53 -0800
Subject: [PATCH 2/3] mailbox: zynqmp: Move buffered IPI setup to of_match selected routine
In-Reply-To: <20231214211354.348294-1-ben.levinsky@amd.com>
References: <20231214211354.348294-1-ben.levinsky@amd.com>
Message-ID: <20231214211354.348294-3-ben.levinsky@amd.com>

Move routine that initializes the mailboxes for send and receive to
a function pointer that is set based on compatible string.

Signed-off-by: Ben Levinsky <ben.levinsky at amd.com>
---
 drivers/mailbox/zynqmp-ipi-mailbox.c | 124 +++++++++++++++++++--------
 1 file changed, 89 insertions(+), 35 deletions(-)

diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
index 2c10aa01b3bb..edefb80a6e47 100644
--- a/drivers/mailbox/zynqmp-ipi-mailbox.c
+++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
@@ -72,6 +72,10 @@ struct zynqmp_ipi_mchan {
 	unsigned int chan_type;
 };
 
+struct zynqmp_ipi_mbox;
+
+typedef int (*setup_ipi_fn)(struct zynqmp_ipi_mbox *ipi_mbox, struct device_node *node);
+
 /**
  * struct zynqmp_ipi_mbox - Description of a ZynqMP IPI mailbox
  *                          platform data.
@@ -82,6 +86,7 @@ struct zynqmp_ipi_mchan {
  * @mbox:                 mailbox Controller
  * @mchans:               array for channels, tx channel and rx channel.
  * @irq:                  IPI agent interrupt ID
+ * setup_ipi_fn:          Function Pointer to set up IPI Channels
  */
 struct zynqmp_ipi_mbox {
 	struct zynqmp_ipi_pdata *pdata;
@@ -89,6 +94,7 @@ struct zynqmp_ipi_mbox {
 	u32 remote_id;
 	struct mbox_controller mbox;
 	struct zynqmp_ipi_mchan mchans[2];
+	setup_ipi_fn setup_ipi_fn;
 };
 
 /**
@@ -466,12 +472,9 @@ static void zynqmp_ipi_mbox_dev_release(struct device *dev)
 static int zynqmp_ipi_mbox_probe(struct zynqmp_ipi_mbox *ipi_mbox,
 				 struct device_node *node)
 {
-	struct zynqmp_ipi_mchan *mchan;
 	struct mbox_chan *chans;
 	struct mbox_controller *mbox;
-	struct resource res;
 	struct device *dev, *mdev;
-	const char *name;
 	int ret;
 
 	dev = ipi_mbox->pdata->dev;
@@ -491,6 +494,75 @@ static int zynqmp_ipi_mbox_probe(struct zynqmp_ipi_mbox *ipi_mbox,
 	}
 	mdev = &ipi_mbox->dev;
 
+	/* Get the IPI remote agent ID */
+	ret = of_property_read_u32(node, "xlnx,ipi-id", &ipi_mbox->remote_id);
+	if (ret < 0) {
+		dev_err(dev, "No IPI remote ID is specified.\n");
+		return ret;
+	}
+
+	ret = ipi_mbox->setup_ipi_fn(ipi_mbox, node);
+	if (ret) {
+		dev_err(dev, "Failed to set up IPI Buffers.\n");
+		return ret;
+	}
+
+	mbox = &ipi_mbox->mbox;
+	mbox->dev = mdev;
+	mbox->ops = &zynqmp_ipi_chan_ops;
+	mbox->num_chans = 2;
+	mbox->txdone_irq = false;
+	mbox->txdone_poll = true;
+	mbox->txpoll_period = 5;
+	mbox->of_xlate = zynqmp_ipi_of_xlate;
+	chans = devm_kzalloc(mdev, 2 * sizeof(*chans), GFP_KERNEL);
+	if (!chans)
+		return -ENOMEM;
+	mbox->chans = chans;
+	chans[IPI_MB_CHNL_TX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
+	chans[IPI_MB_CHNL_RX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_RX];
+	ipi_mbox->mchans[IPI_MB_CHNL_TX].chan_type = IPI_MB_CHNL_TX;
+	ipi_mbox->mchans[IPI_MB_CHNL_RX].chan_type = IPI_MB_CHNL_RX;
+	ret = devm_mbox_controller_register(mdev, mbox);
+	if (ret)
+		dev_err(mdev,
+			"Failed to register mbox_controller(%d)\n", ret);
+	else
+		dev_info(mdev,
+			 "Registered ZynqMP IPI mbox with TX/RX channels.\n");
+	return ret;
+}
+
+/**
+ * zynqmp_ipi_setup - set up IPI Buffers for classic flow
+ *
+ * @ipi_mbox: pointer to IPI mailbox private data structure
+ * @node: IPI mailbox device node
+ *
+ * This will be used to set up IPI Buffers for ZynqMP SOC if user
+ * wishes to use classic driver usage model on new SOC's with only
+ * buffered IPIs.
+ *
+ * Note that bufferless IPIs and mixed usage of buffered and bufferless
+ * IPIs are not supported with this flow.
+ *
+ * This will be invoked with compatible string "xlnx,zynqmp-ipi-mailbox".
+ *
+ * Return: 0 for success, negative value for failure
+ */
+static int zynqmp_ipi_setup(struct zynqmp_ipi_mbox *ipi_mbox,
+			    struct device_node *node)
+{
+	struct zynqmp_ipi_mchan *mchan;
+	struct device *mdev;
+	struct resource res;
+	struct device *dev;
+	const char *name;
+	int ret;
+
+	mdev = &ipi_mbox->dev;
+	dev = ipi_mbox->pdata->dev;
+
 	mchan = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
 	name = "local_request_region";
 	ret = zynqmp_ipi_mbox_get_buf_res(node, name, &res);
@@ -565,37 +637,7 @@ static int zynqmp_ipi_mbox_probe(struct zynqmp_ipi_mbox *ipi_mbox,
 	if (!mchan->rx_buf)
 		return -ENOMEM;
 
-	/* Get the IPI remote agent ID */
-	ret = of_property_read_u32(node, "xlnx,ipi-id", &ipi_mbox->remote_id);
-	if (ret < 0) {
-		dev_err(dev, "No IPI remote ID is specified.\n");
-		return ret;
-	}
-
-	mbox = &ipi_mbox->mbox;
-	mbox->dev = mdev;
-	mbox->ops = &zynqmp_ipi_chan_ops;
-	mbox->num_chans = 2;
-	mbox->txdone_irq = false;
-	mbox->txdone_poll = true;
-	mbox->txpoll_period = 5;
-	mbox->of_xlate = zynqmp_ipi_of_xlate;
-	chans = devm_kzalloc(mdev, 2 * sizeof(*chans), GFP_KERNEL);
-	if (!chans)
-		return -ENOMEM;
-	mbox->chans = chans;
-	chans[IPI_MB_CHNL_TX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
-	chans[IPI_MB_CHNL_RX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_RX];
-	ipi_mbox->mchans[IPI_MB_CHNL_TX].chan_type = IPI_MB_CHNL_TX;
-	ipi_mbox->mchans[IPI_MB_CHNL_RX].chan_type = IPI_MB_CHNL_RX;
-	ret = devm_mbox_controller_register(mdev, mbox);
-	if (ret)
-		dev_err(mdev,
-			"Failed to register mbox_controller(%d)\n", ret);
-	else
-		dev_info(mdev,
-			 "Registered ZynqMP IPI mbox with TX/RX channels.\n");
-	return ret;
+	return 0;
 }
 
 /**
@@ -626,6 +668,7 @@ static int zynqmp_ipi_probe(struct platform_device *pdev)
 	struct zynqmp_ipi_pdata *pdata;
 	struct zynqmp_ipi_mbox *mbox;
 	int num_mboxes, ret = -EINVAL;
+	setup_ipi_fn ipi_fn;
 
 	num_mboxes = of_get_available_child_count(np);
 	if (num_mboxes == 0) {
@@ -646,9 +689,18 @@ static int zynqmp_ipi_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	ipi_fn = (setup_ipi_fn)device_get_match_data(&pdev->dev);
+	if (!ipi_fn) {
+		dev_err(dev,
+			"Mbox Compatible String is missing IPI Setup fn.\n");
+		return -ENODEV;
+	}
+
 	pdata->num_mboxes = num_mboxes;
 
 	mbox = pdata->ipi_mboxes;
+	mbox->setup_ipi_fn = ipi_fn;
+
 	for_each_available_child_of_node(np, nc) {
 		mbox->pdata = pdata;
 		ret = zynqmp_ipi_mbox_probe(mbox, nc);
@@ -694,7 +746,9 @@ static int zynqmp_ipi_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id zynqmp_ipi_of_match[] = {
-	{ .compatible = "xlnx,zynqmp-ipi-mailbox" },
+	{ .compatible = "xlnx,zynqmp-ipi-mailbox",
+	  .data = &zynqmp_ipi_setup,
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, zynqmp_ipi_of_match);
-- 
2.25.1



From ben.levinsky at amd.com  Thu Dec 14 13:13:54 2023
From: ben.levinsky at amd.com (Ben Levinsky)
Date: Thu, 14 Dec 2023 13:13:54 -0800
Subject: [PATCH 3/3] mailbox: zynqmp: Enable Bufferless IPI usage on Versal-based SOC's
In-Reply-To: <20231214211354.348294-1-ben.levinsky@amd.com>
References: <20231214211354.348294-1-ben.levinsky@amd.com>
Message-ID: <20231214211354.348294-4-ben.levinsky@amd.com>

On Xilinx-AMD Versal and Versal-NET, there exist both
inter-processor-interrupts with corresponding message buffers and without
such buffers.

Add a routine that, if the corresponding DT compatible
string "xlnx,versal-ipi-mailbox" is used then a Versal-based SOC
can use a mailbox Device Tree entry where both host and remote
can use either of the buffered or bufferless interrupts.

Signed-off-by: Ben Levinsky <ben.levinsky at amd.com>
---
Note that the linked patch provides corresponding bindings.
Depends on: https://lore.kernel.org/all/20231214054224.957336-3-tanmay.shah at amd.com/T/
---
 drivers/mailbox/zynqmp-ipi-mailbox.c | 146 +++++++++++++++++++++++++--
 1 file changed, 139 insertions(+), 7 deletions(-)

diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
index edefb80a6e47..316d9406064e 100644
--- a/drivers/mailbox/zynqmp-ipi-mailbox.c
+++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
@@ -52,6 +52,13 @@
 #define IPI_MB_CHNL_TX	0 /* IPI mailbox TX channel */
 #define IPI_MB_CHNL_RX	1 /* IPI mailbox RX channel */
 
+/* IPI Message Buffer Information */
+#define RESP_OFFSET	0x20U
+#define DEST_OFFSET	0x40U
+#define IPI_BUF_SIZE	0x20U
+#define DST_BIT_POS	9U
+#define SRC_BITMASK	GENMASK(11, 8)
+
 /**
  * struct zynqmp_ipi_mchan - Description of a Xilinx ZynqMP IPI mailbox channel
  * @is_opened: indicate if the IPI channel is opened
@@ -170,9 +177,11 @@ static irqreturn_t zynqmp_ipi_interrupt(int irq, void *data)
 		if (ret > 0 && ret & IPI_MB_STATUS_RECV_PENDING) {
 			if (mchan->is_opened) {
 				msg = mchan->rx_buf;
-				msg->len = mchan->req_buf_size;
-				memcpy_fromio(msg->data, mchan->req_buf,
-					      msg->len);
+				if (msg) {
+					msg->len = mchan->req_buf_size;
+					memcpy_fromio(msg->data, mchan->req_buf,
+						      msg->len);
+				}
 				mbox_chan_received_data(chan, (void *)msg);
 				status = IRQ_HANDLED;
 			}
@@ -282,26 +291,26 @@ static int zynqmp_ipi_send_data(struct mbox_chan *chan, void *data)
 
 	if (mchan->chan_type == IPI_MB_CHNL_TX) {
 		/* Send request message */
-		if (msg && msg->len > mchan->req_buf_size) {
+		if (msg && msg->len > mchan->req_buf_size && mchan->req_buf) {
 			dev_err(dev, "channel %d message length %u > max %lu\n",
 				mchan->chan_type, (unsigned int)msg->len,
 				mchan->req_buf_size);
 			return -EINVAL;
 		}
-		if (msg && msg->len)
+		if (msg && msg->len && mchan->req_buf)
 			memcpy_toio(mchan->req_buf, msg->data, msg->len);
 		/* Kick IPI mailbox to send message */
 		arg0 = SMC_IPI_MAILBOX_NOTIFY;
 		zynqmp_ipi_fw_call(ipi_mbox, arg0, 0, &res);
 	} else {
 		/* Send response message */
-		if (msg && msg->len > mchan->resp_buf_size) {
+		if (msg && msg->len > mchan->resp_buf_size && mchan->resp_buf) {
 			dev_err(dev, "channel %d message length %u > max %lu\n",
 				mchan->chan_type, (unsigned int)msg->len,
 				mchan->resp_buf_size);
 			return -EINVAL;
 		}
-		if (msg && msg->len)
+		if (msg && msg->len && mchan->resp_buf)
 			memcpy_toio(mchan->resp_buf, msg->data, msg->len);
 		arg0 = SMC_IPI_MAILBOX_ACK;
 		zynqmp_ipi_fw_call(ipi_mbox, arg0, IPI_SMC_ACK_EIRQ_MASK,
@@ -640,6 +649,126 @@ static int zynqmp_ipi_setup(struct zynqmp_ipi_mbox *ipi_mbox,
 	return 0;
 }
 
+/**
+ * versal_ipi_setup - Set up IPIs to support mixed usage of
+ *				 Buffered and Bufferless IPIs.
+ *
+ * @ipi_mbox: pointer to IPI mailbox private data structure
+ * @node: IPI mailbox device node
+ *
+ * Return: 0 for success, negative value for failure
+ */
+static int versal_ipi_setup(struct zynqmp_ipi_mbox *ipi_mbox,
+			    struct device_node *node)
+{
+	struct zynqmp_ipi_mchan *tx_mchan, *rx_mchan;
+	struct resource host_res, remote_res;
+	struct device_node *parent_node;
+	int host_idx, remote_idx;
+	struct device *mdev, *dev;
+
+	tx_mchan = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
+	rx_mchan = &ipi_mbox->mchans[IPI_MB_CHNL_RX];
+	parent_node = of_get_parent(node);
+	dev = ipi_mbox->pdata->dev;
+	mdev = &ipi_mbox->dev;
+
+	host_idx = zynqmp_ipi_mbox_get_buf_res(parent_node, "msg", &host_res);
+	remote_idx = zynqmp_ipi_mbox_get_buf_res(node, "msg", &remote_res);
+
+	/*
+	 * Only set up buffers if both sides claim to have msg buffers.
+	 * This is because each buffered IPI's corresponding msg buffers
+	 * are reserved for use by other buffered IPI's.
+	 */
+	if (!host_idx && !remote_idx) {
+		u32 host_src, host_dst, remote_src, remote_dst;
+		u32 buff_sz;
+
+		buff_sz = resource_size(&host_res);
+
+		host_src = host_res.start & SRC_BITMASK;
+		remote_src = remote_res.start & SRC_BITMASK;
+
+		host_dst = (host_src >> DST_BIT_POS) * DEST_OFFSET;
+		remote_dst = (remote_src >> DST_BIT_POS) * DEST_OFFSET;
+
+		/* Validate that IPI IDs is within IPI Message buffer space. */
+		if (host_dst >= buff_sz || remote_dst >= buff_sz) {
+			dev_err(mdev,
+				"Invalid IPI Message buffer values: %x %x\n",
+				host_dst, remote_dst);
+			return -EINVAL;
+		}
+
+		tx_mchan->req_buf = devm_ioremap(mdev,
+						 host_res.start | remote_dst,
+						 IPI_BUF_SIZE);
+		if (!tx_mchan->req_buf) {
+			dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
+			return -ENOMEM;
+		}
+
+		tx_mchan->resp_buf = devm_ioremap(mdev,
+						  (remote_res.start | host_dst) +
+						  RESP_OFFSET, IPI_BUF_SIZE);
+		if (!tx_mchan->resp_buf) {
+			dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
+			return -ENOMEM;
+		}
+
+		rx_mchan->req_buf = devm_ioremap(mdev,
+						 remote_res.start | host_dst,
+						 IPI_BUF_SIZE);
+		if (!rx_mchan->req_buf) {
+			dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
+			return -ENOMEM;
+		}
+
+		rx_mchan->resp_buf = devm_ioremap(mdev,
+						  (host_res.start | remote_dst) +
+						  RESP_OFFSET, IPI_BUF_SIZE);
+		if (!rx_mchan->resp_buf) {
+			dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
+			return -ENOMEM;
+		}
+
+		tx_mchan->resp_buf_size = IPI_BUF_SIZE;
+		tx_mchan->req_buf_size = IPI_BUF_SIZE;
+		tx_mchan->rx_buf = devm_kzalloc(mdev, IPI_BUF_SIZE +
+						sizeof(struct zynqmp_ipi_message),
+						GFP_KERNEL);
+		if (!tx_mchan->rx_buf)
+			return -ENOMEM;
+
+		rx_mchan->resp_buf_size = IPI_BUF_SIZE;
+		rx_mchan->req_buf_size = IPI_BUF_SIZE;
+		rx_mchan->rx_buf = devm_kzalloc(mdev, IPI_BUF_SIZE +
+						sizeof(struct zynqmp_ipi_message),
+						GFP_KERNEL);
+		if (!rx_mchan->rx_buf)
+			return -ENOMEM;
+	} else {
+		/*
+		 * If here, then set up Bufferless IPI Channel because
+		 * one or both of the IPI's is bufferless.
+		 */
+		tx_mchan->req_buf = NULL;
+		tx_mchan->resp_buf = NULL;
+		tx_mchan->rx_buf = NULL;
+		tx_mchan->resp_buf_size = 0;
+		tx_mchan->req_buf_size = 0;
+
+		rx_mchan->req_buf = NULL;
+		rx_mchan->resp_buf = NULL;
+		rx_mchan->rx_buf = NULL;
+		rx_mchan->resp_buf_size = 0;
+		rx_mchan->req_buf_size = 0;
+	}
+
+	return 0;
+}
+
 /**
  * zynqmp_ipi_free_mboxes - Free IPI mailboxes devices
  *
@@ -749,6 +878,9 @@ static const struct of_device_id zynqmp_ipi_of_match[] = {
 	{ .compatible = "xlnx,zynqmp-ipi-mailbox",
 	  .data = &zynqmp_ipi_setup,
 	},
+	{ .compatible = "xlnx,versal-ipi-mailbox",
+	  .data = &versal_ipi_setup,
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, zynqmp_ipi_of_match);
-- 
2.25.1



From ben.levinsky at amd.com  Thu Dec 14 13:13:51 2023
From: ben.levinsky at amd.com (Ben Levinsky)
Date: Thu, 14 Dec 2023 13:13:51 -0800
Subject: [PATCH 0/3] mailbox: zynqmp: Enable Bufferless IPIs for Versal based SOCs
Message-ID: <20231214211354.348294-1-ben.levinsky@amd.com>

For Xilinx-AMD Versal and Versal NET SOC's there exist also
inter-processor-interrupts (IPIs) without IPI Message Buffers. For these
enable use of IPI Mailbox driver for send/receive as well.

This is enabled with new compatible string: "xlnx,versal-ipi-mailbox"

Original, buffered usage for ZynqMP based SOC is still supported.

Note that the linked patch provides corresponding bindings.
Depends on: https://lore.kernel.org/all/20231214054224.957336-3-tanmay.shah at amd.com/T/

Ben Levinsky (3):
  mailbox: zynqmp: Move of_match structure closer to usage
  mailbox: zynqmp: Move buffered IPI setup to of_match selected routine
  mailbox: zynqmp: Enable Bufferless IPI usage on Versal-based SOC's

 drivers/mailbox/zynqmp-ipi-mailbox.c | 275 ++++++++++++++++++++++-----
 1 file changed, 231 insertions(+), 44 deletions(-)

-- 
2.25.1



From ilkka at os.amperecomputing.com  Thu Dec 14 13:22:39 2023
From: ilkka at os.amperecomputing.com (Ilkka Koskinen)
Date: Thu, 14 Dec 2023 13:22:39 -0800 (PST)
Subject: [PATCH v2 5/5] perf/arm_cspmu: Add devicetree support
In-Reply-To: <6858523689a214543224495fee22f9e31be2f767.1702571292.git.robin.murphy@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com> <6858523689a214543224495fee22f9e31be2f767.1702571292.git.robin.murphy@arm.com>
Message-ID: <9ab69cc-3354-e592-9b2d-a07cb1e15787@os.amperecomputing.com>


On Thu, 14 Dec 2023, Robin Murphy wrote:
> Hook up devicetree probing support. For now let's hope that people
> implement PMIIDR properly and we don't need an override property or
> match data mechanism.
>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>

Thanks, this version works fine with ACPI.

    Reviewed-by: Ilkka Koskinen <ilkka at os.amperecomputing.com>


Cheers, Ilkka

> ---
> v2: Use APMT node to distinguish ACPI; adjust for binding change
> ---
> drivers/perf/arm_cspmu/arm_cspmu.c | 63 ++++++++++++++++++++++++------
> 1 file changed, 52 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
> index b64de4d800c7..6c76c135a0cf 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> @@ -27,6 +27,7 @@
> #include <linux/io-64-nonatomic-lo-hi.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> +#include <linux/of.h>
> #include <linux/perf_event.h>
> #include <linux/platform_device.h>
>
> @@ -310,6 +311,10 @@ static const char *arm_cspmu_get_name(const struct arm_cspmu *cspmu)
>
> 	dev = cspmu->dev;
> 	apmt_node = arm_cspmu_apmt_node(dev);
> +	if (!apmt_node)
> +		return devm_kasprintf(dev, GFP_KERNEL, PMUNAME "_%u",
> +				      atomic_fetch_inc(&pmu_idx[0]));
> +
> 	pmu_type = apmt_node->type;
>
> 	if (pmu_type >= ACPI_APMT_NODE_TYPE_COUNT) {
> @@ -425,7 +430,7 @@ static int arm_cspmu_init_impl_ops(struct arm_cspmu *cspmu)
> 	};
>
> 	/* Firmware may override implementer/product ID from PMIIDR */
> -	if (apmt_node->impl_id)
> +	if (apmt_node && apmt_node->impl_id)
> 		cspmu->impl.pmiidr = apmt_node->impl_id;
>
> 	/* Find implementer specific attribute ops. */
> @@ -940,7 +945,14 @@ static struct arm_cspmu *arm_cspmu_alloc(struct platform_device *pdev)
> 	platform_set_drvdata(pdev, cspmu);
>
> 	apmt_node = arm_cspmu_apmt_node(dev);
> -	cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
> +	if (apmt_node) {
> +		cspmu->has_atomic_dword = apmt_node->flags & ACPI_APMT_FLAGS_ATOMIC;
> +	} else {
> +		u32 width = 0;
> +
> +		device_property_read_u32(dev, "reg-io-width", &width);
> +		cspmu->has_atomic_dword = (width == 8);
> +	}
>
> 	return cspmu;
> }
> @@ -1133,11 +1145,6 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
> 		}
> 	}
>
> -	if (cpumask_empty(&cspmu->associated_cpus)) {
> -		dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
> -		return -ENODEV;
> -	}
> -
> 	return 0;
> }
> #else
> @@ -1147,9 +1154,36 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
> }
> #endif
>
> +static int arm_cspmu_of_get_cpus(struct arm_cspmu *cspmu)
> +{
> +	struct of_phandle_iterator it;
> +	int ret, cpu;
> +
> +	of_for_each_phandle(&it, ret, dev_of_node(cspmu->dev), "cpus", NULL, 0) {
> +		cpu = of_cpu_node_to_id(it.node);
> +		if (cpu < 0)
> +			continue;
> +		cpumask_set_cpu(cpu, &cspmu->associated_cpus);
> +	}
> +	return ret;
> +}
> +
> static int arm_cspmu_get_cpus(struct arm_cspmu *cspmu)
> {
> -	return arm_cspmu_acpi_get_cpus(cspmu);
> +	int ret = 0;
> +
> +	if (arm_cspmu_apmt_node(cspmu->dev))
> +		ret = arm_cspmu_acpi_get_cpus(cspmu);
> +	else if (device_property_present(cspmu->dev, "cpus"))
> +		ret = arm_cspmu_of_get_cpus(cspmu);
> +	else
> +		cpumask_copy(&cspmu->associated_cpus, cpu_possible_mask);
> +
> +	if (!ret && cpumask_empty(&cspmu->associated_cpus)) {
> +		dev_dbg(cspmu->dev, "No cpu associated with the PMU\n");
> +		ret = -ENODEV;
> +	}
> +	return ret;
> }
>
> static int arm_cspmu_register_pmu(struct arm_cspmu *cspmu)
> @@ -1246,11 +1280,18 @@ static const struct platform_device_id arm_cspmu_id[] = {
> };
> MODULE_DEVICE_TABLE(platform, arm_cspmu_id);
>
> +static const struct of_device_id arm_cspmu_of_match[] = {
> +	{ .compatible = "arm,coresight-pmu" },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, arm_cspmu_of_match);
> +
> static struct platform_driver arm_cspmu_driver = {
> 	.driver = {
> -			.name = DRVNAME,
> -			.suppress_bind_attrs = true,
> -		},
> +		.name = DRVNAME,
> +		.of_match_table = arm_cspmu_of_match,
> +		.suppress_bind_attrs = true,
> +	},
> 	.probe = arm_cspmu_device_probe,
> 	.remove = arm_cspmu_device_remove,
> 	.id_table = arm_cspmu_id,
> -- 
> 2.39.2.101.g768bb238c484.dirty
>
>


From sjg at chromium.org  Thu Dec 14 13:27:12 2023
From: sjg at chromium.org (Simon Glass)
Date: Thu, 14 Dec 2023 14:27:12 -0700
Subject: [PATCH RFC] dt-bindings: nvmem: u-boot, env: add any-name MAC
 cells compatible
In-Reply-To: <20231214153620.23998-1-zajec5@gmail.com>
References: <20231214153620.23998-1-zajec5@gmail.com>
Message-ID: <CAPnjgZ31AAauR876W1RmU4JPzKUD8XAMCZrJDumE+Dr4miqABQ@mail.gmail.com>

Hi Rafa?,

On Thu, 14 Dec 2023 at 08:36, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
>
> From: Rafa? Mi?ecki <rafal at milecki.pl>
>
> So far we had a property for "ethaddr" NVMEM cell containing base
> Ethernet MAC address. The problem is vendors often pick non-standard
> names for storing MAC(s) (other than "ethaddr"). A few names were
> noticed over years:
> 1. "wanaddr" (Edimax, ELECOM, EnGenius, I-O DATA, Sitecom)
> 2. "et1macaddr" (ASUS)
> 3. "eth1addr" (Buffalo)
> 4. "athaddr" (EnGenius)
> 5. "baseMAC" (Netgear)
> 6. "mac" (Netgear)
> 7. "mac_addr" (Moxa)
> and more ("HW_LAN_MAC", "HW_WAN_MAC", "INIC_MAC_ADDR", "LAN_MAC_ADDR",
> "RADIOADDR0", "RADIOADDR1", "WAN_MAC_ADDR", "lan1_mac_addr", "wanmac",
> "wmac1", "wmac2").
>
> It doesn't make sense to add property for every possible MAC cell name.
> Instead allow specifying cells with "mac" compatible.
>
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> ---
> List of devices and their U-Boot MAC variables:
> alphanetworks,asl56026) wanmac
> asus,rt-ac65p) et1macaddr
> asus,rt-ac85p) et1macaddr
> belkin,f9k1109v1) HW_WAN_MAC + HW_LAN_MAC
> buffalo,ls220de) eth1addr
> buffalo,ls421de) eth1addr
> checkpoint,l-50) lan1_mac_addr
> dovado,tiny-ac) INIC_MAC_ADDR
> dovado,tiny-ac) LAN_MAC_ADDR + WAN_MAC_ADDR
> edimax,ra21s) wanaddr
> edimax,rg21s) wanaddr
> elecom,wrc-2533ghbk-i) wanaddr
> elecom,wrc-2533ghbk2-t) wanaddr
> engenius,ecb1200) athaddr
> engenius,ecb1750) athaddr
> engenius,epg5000) wanaddr
> engenius,epg600) wanaddr
> engenius,esr1200) wanaddr
> engenius,esr1750) wanaddr
> engenius,esr600) wanaddr
> engenius,esr600h) wanaddr
> engenius,esr900) wanaddr
> enterasys,ws-ap3705i) RADIOADDR0 + RADIOADDR1
> iodata,wn-ac1167dgr) wanaddr
> iodata,wn-ac1167gr) wanaddr
> iodata,wn-ac1600dgr) wanaddr
> iodata,wn-ac1600dgr2) wanaddr
> iodata,wn-ac733gr3) wanaddr
> iodata,wn-ag300dgr) wanaddr
> iodata,wnpr2600g) wanaddr
> moxa,awk-1137c) mac_addr
> netgear,wax220) mac
> netgear,wndap620) baseMAC
> netgear,wndap660) baseMAC
> ocedo,panda) wmac1 + wmac2
> sitecom,wlr-7100) wanaddr
> sitecom,wlr-8100) wanaddr
>
>  .../devicetree/bindings/nvmem/u-boot,env.yaml | 33 +++++++++++++++++++
>  1 file changed, 33 insertions(+)
>

Are these upstream U-Boots, or just vendor forks?

Regards,
Simon


From cl at linux.com  Thu Dec 14 13:35:51 2023
From: cl at linux.com (Christoph Lameter (Ampere))
Date: Thu, 14 Dec 2023 13:35:51 -0800 (PST)
Subject: [PATCH] ARM64: Implement arch_report_meminfo()
In-Reply-To: <b0d7b928-ecc5-4203-8269-423dee08b1ff@arm.com>
References: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org> <b0d7b928-ecc5-4203-8269-423dee08b1ff@arm.com>
Message-ID: <bc9c1287-6b20-8463-50c1-678b7634cca6@linux.com>

On Thu, 14 Dec 2023, Robin Murphy wrote:

> It seems somewhat suspect that these counts only ever increase. It's not 
> often that we change or remove parts of the linear map, but it certainly can 
> happen.

Well yes in the case of hotplug I guess ... Ok here is V2



>From cl at gentwo.org Fri Dec  8 13:11:58 2023
From: "Christoph Lameter (Ampere)" <cl at gentwo.org>
To: Catalin Marinas <catalin.marinas at arm.com>, Marc Zyngier <maz at kernel.org>, Will Deacon <will at kernel.org>, Ryan Roberts <ryan.roberts at arm.com>, Mark Rutland <mark.rutland at arm.com>, Vishal Moola <vishal.moola at gmail.com>
Cc: linux-arm-kernel at lists.infradead.org, linux-mm at kvack.org
Subject: [PATCH] ARM64: Implement arch_report_meminfo()

V1->V2 hotplug and umapping support

X86 has information in /proc/meminfo showing the use of large mappings
for the kernel direct map. This has now also become important for
ARM since the kernel default CONFIG_RODATA_FULL_DEFAULT_ENABLED
forces 4K PTE use for the direct map and users may not be aware
of the performance impact of the increased TLB use etc.

The output of /proc/meminfo on ARM64 is then after this patch:

4K page size:

Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      155912 kB
CONT DMap4k:        1176 kB
DirectMap2M:      722944 kB
CONT DMap2M:       28672 kB
DirectMap1G:   534773760 kB

64K page size:

Hugepagesize:     524288 kB
Hugetlb:               0 kB
DirectMap64k:      882624 kB
CONT DMap64k:       19904 kB
DirectMap512M:    534773760 kB
CONT DMap512M:           0 kB
DirectMap4096G:           0 kB

Signed-off-by: Christoph Lameter (Ampere) <cl at linux.com>

Index: linux/arch/arm64/mm/mmu.c
===================================================================
--- linux.orig/arch/arm64/mm/mmu.c
+++ linux/arch/arm64/mm/mmu.c
@@ -76,6 +76,13 @@ EXPORT_SYMBOL(empty_zero_page);
  static DEFINE_SPINLOCK(swapper_pgdir_lock);
  static DEFINE_MUTEX(fixmap_lock);

+static atomic_t nr_pte;
+static atomic_t nr_pmd;
+static atomic_t nr_pud;
+static atomic_t nr_pte_cont;
+static atomic_t nr_pmd_cont;
+
+
  void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
  {
  	pgd_t *fixmap_pgdp;
@@ -179,6 +186,7 @@ static void init_pte(pmd_t *pmdp, unsign
  		pte_t old_pte = READ_ONCE(*ptep);

  		set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
+		atomic_inc(&nr_pte);

  		/*
  		 * After the PTE entry has been populated once, we
@@ -223,8 +231,10 @@ static void alloc_init_cont_pte(pmd_t *p

  		/* use a contiguous mapping if the range is suitably aligned */
  		if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
+		    (flags & NO_CONT_MAPPINGS) == 0) {
  			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+			atomic_inc(&nr_pte_cont);
+		}

  		init_pte(pmdp, addr, next, phys, __prot);

@@ -249,6 +259,7 @@ static void init_pmd(pud_t *pudp, unsign
  		if (((addr | next | phys) & ~PMD_MASK) == 0 &&
  		    (flags & NO_BLOCK_MAPPINGS) == 0) {
  			pmd_set_huge(pmdp, phys, prot);
+			atomic_inc(&nr_pmd);

  			/*
  			 * After the PMD entry has been populated once, we
@@ -301,8 +312,10 @@ static void alloc_init_cont_pmd(pud_t *p

  		/* use a contiguous mapping if the range is suitably aligned */
  		if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
+		    (flags & NO_CONT_MAPPINGS) == 0) {
  			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+			atomic_inc(&nr_pmd_cont);
+		}

  		init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);

@@ -346,7 +359,7 @@ static void alloc_init_pud(pgd_t *pgdp,
  		   ((addr | next | phys) & ~PUD_MASK) == 0 &&
  		    (flags & NO_BLOCK_MAPPINGS) == 0) {
  			pud_set_huge(pudp, phys, prot);
-
+			atomic_inc(&nr_pud);
  			/*
  			 * After the PUD entry has been populated once, we
  			 * only allow updates to the permission attributes.
@@ -859,6 +872,11 @@ static void unmap_hotplug_pte_range(pmd_
  			continue;

  		WARN_ON(!pte_present(pte));
+
+		if (pte_cont(pte))
+			atomic_dec(&nr_pte_cont);
+		atomic_dec(&nr_pte);
+
  		pte_clear(&init_mm, addr, ptep);
  		flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
  		if (free_mapped)
@@ -883,6 +901,11 @@ static void unmap_hotplug_pmd_range(pud_

  		WARN_ON(!pmd_present(pmd));
  		if (pmd_sect(pmd)) {
+
+			if (pmd_cont(pmd))
+				atomic_dec(&nr_pmd_cont);
+			atomic_dec(&nr_pmd);
+
  			pmd_clear(pmdp);

  			/*
@@ -916,6 +939,9 @@ static void unmap_hotplug_pud_range(p4d_

  		WARN_ON(!pud_present(pud));
  		if (pud_sect(pud)) {
+
+			atomic_dec(&nr_pud);
+
  			pud_clear(pudp);

  			/*
@@ -1010,6 +1036,7 @@ static void free_empty_pte_table(pmd_t *
  			return;
  	}

+	atomic_dec(&nr_pmd);
  	pmd_clear(pmdp);
  	__flush_tlb_kernel_pgtable(start);
  	free_hotplug_pgtable_page(virt_to_page(ptep));
@@ -1050,6 +1077,7 @@ static void free_empty_pmd_table(pud_t *
  			return;
  	}

+	atomic_dec(&nr_pud);
  	pud_clear(pudp);
  	__flush_tlb_kernel_pgtable(start);
  	free_hotplug_pgtable_page(virt_to_page(pmdp));
@@ -1225,6 +1253,7 @@ int pmd_free_pte_page(pmd_t *pmdp, unsig
  	}

  	table = pte_offset_kernel(pmdp, addr);
+	atomic_dec(&nr_pmd);
  	pmd_clear(pmdp);
  	__flush_tlb_kernel_pgtable(addr);
  	pte_free_kernel(NULL, table);
@@ -1253,6 +1282,7 @@ int pud_free_pmd_page(pud_t *pudp, unsig
  		pmd_free_pte_page(pmdp, next);
  	} while (pmdp++, next += PMD_SIZE, next != end);

+	atomic_dec(&nr_pud);
  	pud_clear(pudp);
  	__flush_tlb_kernel_pgtable(addr);
  	pmd_free(NULL, table);
@@ -1486,3 +1516,36 @@ void ptep_modify_prot_commit(struct vm_a
  {
  	set_pte_at(vma->vm_mm, addr, ptep, pte);
  }
+
+
+#ifdef CONFIG_PROC_FS
+void arch_report_meminfo(struct seq_file *m)
+{
+	unsigned long pagesize_in_kb = PAGE_SIZE / 1024;
+
+	seq_printf(m, "DirectMap%luk:    %8lu kB\n",
+			pagesize_in_kb,
+		  	(unsigned long)atomic_read(&nr_pte) * pagesize_in_kb);
+
+        seq_printf(m, "CONT DMap%luk:    %8lu kB\n",
+			pagesize_in_kb,
+			(unsigned long)atomic_read(&nr_pte_cont) * pagesize_in_kb);
+
+	pagesize_in_kb = PMD_SIZE / 1024;
+
+        seq_printf(m, "DirectMap%luM:    %8lu kB\n",
+			pagesize_in_kb / 1024,
+			(unsigned long)atomic_read(&nr_pmd) * pagesize_in_kb);
+
+	seq_printf(m, "CONT DMap%luM:    %8lu kB\n",
+			pagesize_in_kb / 1024,
+			(unsigned long)atomic_read(&nr_pmd_cont) * pagesize_in_kb);
+
+	pagesize_in_kb = PUD_SIZE / 1024;
+
+	seq_printf(m, "DirectMap%luG:  %10lu kB\n",
+			pagesize_in_kb >> 20,
+			(unsigned long)atomic_read(&nr_pud) * pagesize_in_kb);
+}
+#endif
+


From robh at kernel.org  Thu Dec 14 14:20:27 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 14 Dec 2023 16:20:27 -0600
Subject: [PATCH v1 2/6] arm: arm64: dts: Enable cros-ec-spi as wake source
In-Reply-To: <CANg-bXCG61HFW7JFuAd3k+OrCG_F9F3e8brjM-pmBauS53aobQ@mail.gmail.com>
References: <20231213110009.v1.1.Ifd0903f1c351e84376d71dbdadbd43931197f5ea@changeid>
 <20231213110009.v1.2.I274b2d2255eb539cc9d251c9d65a385cc4014c79@changeid>
 <20231213221124.GB2115075-robh@kernel.org> <CANg-bXCG61HFW7JFuAd3k+OrCG_F9F3e8brjM-pmBauS53aobQ@mail.gmail.com>
Message-ID: <CAL_Jsq+MYwOG40X26cYmO9EkZ9xqWrXDi03MaRfxnV-+VGkXWQ@mail.gmail.com>

On Thu, Dec 14, 2023 at 3:04?PM Mark Hasemeyer <markhas at chromium.org> wrote:
>
> > If a device knows it is wakeup capable, why do you need a property too?
>
> I'm referencing:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/power/wakeup-source.txt
> "Nodes that describe devices which has wakeup capability must contain
> an "wakeup-source" boolean property."

That's probably too strongly worded because wakeup capable devices
existed (and still exist) before this binding was created. Powerpc for
example doesn't use it.

> Currently the driver assumes the device is wake capable without
> parsing the device tree, which is an incorrect assumption as wake
> capability should not be enabled on some cros_ec systems.
>
> > I haven't looked closely enough, but it smells like after patch 6, these
> > properties would be required for wakeup? That would be an ABI break.
>
> Agreed. In this case, the driver is a ChromeOS related driver and DTS
> is built from source for each OS update.
> For more context, I will make sure to CC you (and everyone else) and
> include a cover letter in the next series version.

Please explain in the patches with an ABI break why it doesn't matter.

Rob


From andrew at codeconstruct.com.au  Thu Dec 14 14:21:03 2023
From: andrew at codeconstruct.com.au (Andrew Jeffery)
Date: Fri, 15 Dec 2023 08:51:03 +1030
Subject: [PATCH v4 2/2] i2c: aspeed: Acknowledge Tx done with and
 without ACK irq late
In-Reply-To: <2eab42cde34723a195e7a0287db08b25f8388a3b.camel@codeconstruct.com.au>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
	 <20231211102217.2436294-3-quan@os.amperecomputing.com>
	 <2eab42cde34723a195e7a0287db08b25f8388a3b.camel@codeconstruct.com.au>
Message-ID: <54cba87a0df233b8762e43b742afe8e44a77a60c.camel@codeconstruct.com.au>

> On Mon, 2023-12-11 at 17:22 +0700, Quan Nguyen wrote:
> > Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
> > interrupt handler") acknowledges most interrupts early before the slave
> > irq handler is executed, except for the "Receive Done Interrupt status"
> > which is acknowledged late in the interrupt.
> > However, it has been observed that the early acknowledgment of "Transmit
> > Done Interrupt Status" (with ACK or NACK) often causes the interrupt to
> > be raised in READ REQUEST state, that shows the
> > "Unexpected ACK on read request." complaint messages.
> > 
> > Assuming that the "Transmit Done" interrupt should only be acknowledged
> > once it is truly processed, this commit fixes that issue by acknowledging
> > interrupts for both ACK and NACK cases late in the interrupt handler.
> > 
> > Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
> > Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> 
> Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>

So I just booted this series on v6.7-rc5 under qemu v8.2.0-rc4 and
found this:

```
$ qemu-system-arm \
	-M ast2600-evb \
	-kernel build.aspeed_g5/arch/arm/boot/zImage \
	-dtb build.aspeed_g5/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dtb \
	-initrd ~/src/buildroot.org/buildroot/output/images/rootfs.cpio.xz \
	-nographic 2>&1 \
	| ts -s
...
00:00:03 [    1.089187] Freeing initrd memory: 3308K
00:00:05 smbus: error: Unexpected send start condition in state 1
00:00:05 smbus: error: Unexpected write in state -1
00:00:06 [    3.685731] aspeed-i2c-bus 1e78a400.i2c-bus: i2c bus 7 registered, irq 48
00:00:06 [    3.688918] aspeed-i2c-bus 1e78a480.i2c-bus: i2c bus 8 registered, irq 49
00:00:06 [    3.692326] aspeed-i2c-bus 1e78a500.i2c-bus: i2c bus 9 registered, irq 50
00:00:06 [    3.693757] aspeed-i2c-bus 1e78a680.i2c-bus: i2c bus 12 registered, irq 51
00:00:06 [    3.695070] aspeed-i2c-bus 1e78a700.i2c-bus: i2c bus 13 registered, irq 52
00:00:06 [    3.696184] aspeed-i2c-bus 1e78a780.i2c-bus: i2c bus 14 registered, irq 53
00:00:06 [    3.697144] aspeed-i2c-bus 1e78a800.i2c-bus: i2c bus 15 registered, irq 54
00:00:06 [    3.699061] aspeed-video 1e700000.video: irq 55
00:00:06 [    3.699254] aspeed-video 1e700000.video: assigned reserved memory node video
00:00:06 [    3.702755] aspeed-video 1e700000.video: alloc mem size(24576) at 0xbc000000 for jpeg header
00:00:06 [    3.706139] Driver for 1-wire Dallas network protocol.
00:00:07 smbus: error: Unexpected send start condition in state -1
00:00:07 smbus: error: Unexpected write in state -1
00:00:10 smbus: error: Unexpected send start condition in state -1
00:00:10 smbus: error: Unexpected write in state -1
00:00:12 smbus: error: Unexpected send start condition in state -1
00:00:12 smbus: error: Unexpected write in state -1
00:00:14 smbus: error: Unexpected send start condition in state -1
00:00:14 smbus: error: Unexpected write in state -1
00:00:17 smbus: error: Unexpected send start condition in state -1
00:00:17 smbus: error: Unexpected write in state -1
00:00:18 [   14.080141] adt7475 7-002e: Error configuring attenuator bypass
00:00:19 smbus: error: Unexpected send start condition in state -1
00:00:19 smbus: error: Unexpected write in state -1
00:00:21 smbus: error: Unexpected send start condition in state -1
00:00:21 smbus: error: Unexpected write in state -1
00:00:24 smbus: error: Unexpected send start condition in state -1
00:00:24 smbus: error: Unexpected write in state -1
```

The smbus errors do not occur if I revert this patch.

Can you look into qemu to see if it's a bug in the aspeed i2c
controller model's state machine?

Cheers,

Andrew


From robh at kernel.org  Thu Dec 14 14:22:13 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 14 Dec 2023 16:22:13 -0600
Subject: [PATCH v2 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
 <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
Message-ID: <170259153356.1024552.13737544149896160495.robh@kernel.org>


On Thu, 14 Dec 2023 16:31:07 +0000, Robin Murphy wrote:
> Add a binding for implementations of the Arm CoreSight Performance
> Monitoring Unit Architecture. Not to be confused with CoreSight debug
> and trace, the PMU architecture defines a standard MMIO interface for
> event counters following a similar design to the CPU PMU architecture,
> where the implementation and most of its features are discoverable
> through ID registers.
> 
> CC: Rob Herring <robh+dt at kernel.org>
> CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
> CC: Conor Dooley <conor+dt at kernel.org>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
> v2: Use reg-io-width instead of a new property; tweak descriptions
> ---
>  .../bindings/perf/arm,coresight-pmu.yaml      | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
> 

With the line wrapping fixed:

Reviewed-by: Rob Herring <robh at kernel.org>



From ninad at linux.ibm.com  Thu Dec 14 14:23:35 2023
From: ninad at linux.ibm.com (Ninad Palsule)
Date: Thu, 14 Dec 2023 16:23:35 -0600
Subject: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
In-Reply-To: <20231213161347.GA1204384-robh@kernel.org>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-3-ninad@linux.ibm.com>
 <20231213161347.GA1204384-robh@kernel.org>
Message-ID: <87401432-c9ce-4831-908c-aa3aa922a71b@linux.ibm.com>

Hello Rob,

On 12/13/23 10:13, Rob Herring wrote:
> On Tue, Dec 12, 2023 at 10:39:58AM -0600, Ninad Palsule wrote:
>> From: Johannes Holland <johannes.holland at infineon.com>
>>
>> Add a dt schema to support device tree bindings for the generic I2C
>> physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
>> Specification for TPM 2.0 v1.04 Revision 14.
>>
>> This includes descriptions for the Nuvoton and Infineon devices.
> This is incomplete and conflicts with this series[1]. Please help
> review and make sure it works for the cases you care about.
>
> Rob
>
> [1] https://lore.kernel.org/all/cover.1701093036.git.lukas at wunner.de/

I will take a look at the patchset. How do you want to handle mine? Do 
you want me to send patch as per the new directory structure?

Thanks for the review.

Regards,

Ninad



From linus.walleij at linaro.org  Thu Dec 14 14:29:11 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 14 Dec 2023 23:29:11 +0100
Subject: [PATCH 0/3] Fix HREF520 boot problems
Message-ID: <20231214-ux500-no-turnoff-lowbatt-v1-0-9dcff0783d62@linaro.org>

The HREF520 reference design had the wrong analog baseband
defined causing a boot regression.

Was AB8500, but this board has AB8505.

Rearrange the device trees to make it possible to define
a different AB and slot it in.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Linus Walleij (3):
      ARM: dts: ux500-href: Push AB8500 inclusion to the top
      ARM: dts: ux500-href: Push AB8500 config out
      ARM: dts: ux500-href: Switch HREF520 to AB8505

 arch/arm/boot/dts/st/ste-href-ab8500.dtsi      |  48 +++
 arch/arm/boot/dts/st/ste-href-ab8505.dtsi      | 490 +++++++++++++++++++++++++
 arch/arm/boot/dts/st/ste-href.dtsi             |  55 ---
 arch/arm/boot/dts/st/ste-href520-tvk.dts       |   1 +
 arch/arm/boot/dts/st/ste-hrefprev60-stuib.dts  |   1 +
 arch/arm/boot/dts/st/ste-hrefprev60-tvk.dts    |   1 +
 arch/arm/boot/dts/st/ste-hrefv60plus-stuib.dts |   1 +
 arch/arm/boot/dts/st/ste-hrefv60plus-tvk.dts   |   1 +
 arch/arm/boot/dts/st/ste-hrefv60plus.dtsi      |   1 -
 9 files changed, 543 insertions(+), 56 deletions(-)
---
base-commit: 88035e5694a86a7167d490bb95e9df97a9bb162b
change-id: 20231213-ux500-no-turnoff-lowbatt-9266e7ec44f6

Best regards,
-- 
Linus Walleij <linus.walleij at linaro.org>



From linus.walleij at linaro.org  Thu Dec 14 14:29:12 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 14 Dec 2023 23:29:12 +0100
Subject: [PATCH 1/3] ARM: dts: ux500-href: Push AB8500 inclusion to the top
In-Reply-To: <20231214-ux500-no-turnoff-lowbatt-v1-0-9dcff0783d62@linaro.org>
References: <20231214-ux500-no-turnoff-lowbatt-v1-0-9dcff0783d62@linaro.org>
Message-ID: <20231214-ux500-no-turnoff-lowbatt-v1-1-9dcff0783d62@linaro.org>

On the hardware reference designs, include the AB8500 definitions
on the top level in the DTS files, this is to make it possible to
use the AB8505 in the HREF520.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/st/ste-href520-tvk.dts       | 1 +
 arch/arm/boot/dts/st/ste-hrefprev60-stuib.dts  | 1 +
 arch/arm/boot/dts/st/ste-hrefprev60-tvk.dts    | 1 +
 arch/arm/boot/dts/st/ste-hrefv60plus-stuib.dts | 1 +
 arch/arm/boot/dts/st/ste-hrefv60plus-tvk.dts   | 1 +
 arch/arm/boot/dts/st/ste-hrefv60plus.dtsi      | 1 -
 6 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/st/ste-href520-tvk.dts b/arch/arm/boot/dts/st/ste-href520-tvk.dts
index 7f661f8f13ad..930058a8e0d1 100644
--- a/arch/arm/boot/dts/st/ste-href520-tvk.dts
+++ b/arch/arm/boot/dts/st/ste-href520-tvk.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 #include "ste-db8520.dtsi"
+#include "ste-href-ab8500.dtsi"
 #include "ste-hrefv60plus.dtsi"
 #include "ste-href-tvk1281618-r3.dtsi"
 
diff --git a/arch/arm/boot/dts/st/ste-hrefprev60-stuib.dts b/arch/arm/boot/dts/st/ste-hrefprev60-stuib.dts
index a29e345a43d3..b142bb2d38d8 100644
--- a/arch/arm/boot/dts/st/ste-hrefprev60-stuib.dts
+++ b/arch/arm/boot/dts/st/ste-hrefprev60-stuib.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 #include "ste-db8500.dtsi"
+#include "ste-href-ab8500.dtsi"
 #include "ste-hrefprev60.dtsi"
 #include "ste-href-stuib.dtsi"
 
diff --git a/arch/arm/boot/dts/st/ste-hrefprev60-tvk.dts b/arch/arm/boot/dts/st/ste-hrefprev60-tvk.dts
index 1968bd143114..5da1ff41b00e 100644
--- a/arch/arm/boot/dts/st/ste-hrefprev60-tvk.dts
+++ b/arch/arm/boot/dts/st/ste-hrefprev60-tvk.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 #include "ste-db8500.dtsi"
+#include "ste-href-ab8500.dtsi"
 #include "ste-hrefprev60.dtsi"
 #include "ste-href-tvk1281618-r2.dtsi"
 
diff --git a/arch/arm/boot/dts/st/ste-hrefv60plus-stuib.dts b/arch/arm/boot/dts/st/ste-hrefv60plus-stuib.dts
index 7a5b6aa1db5b..c4abe24a7cd0 100644
--- a/arch/arm/boot/dts/st/ste-hrefv60plus-stuib.dts
+++ b/arch/arm/boot/dts/st/ste-hrefv60plus-stuib.dts
@@ -7,6 +7,7 @@
 
 /dts-v1/;
 #include "ste-db8500.dtsi"
+#include "ste-href-ab8500.dtsi"
 #include "ste-hrefv60plus.dtsi"
 #include "ste-href-stuib.dtsi"
 
diff --git a/arch/arm/boot/dts/st/ste-hrefv60plus-tvk.dts b/arch/arm/boot/dts/st/ste-hrefv60plus-tvk.dts
index d5af3f375161..f55e8de2b516 100644
--- a/arch/arm/boot/dts/st/ste-hrefv60plus-tvk.dts
+++ b/arch/arm/boot/dts/st/ste-hrefv60plus-tvk.dts
@@ -7,6 +7,7 @@
 
 /dts-v1/;
 #include "ste-db8500.dtsi"
+#include "ste-href-ab8500.dtsi"
 #include "ste-hrefv60plus.dtsi"
 #include "ste-href-tvk1281618-r2.dtsi"
 
diff --git a/arch/arm/boot/dts/st/ste-hrefv60plus.dtsi b/arch/arm/boot/dts/st/ste-hrefv60plus.dtsi
index e66fa59c2de6..94927f048151 100644
--- a/arch/arm/boot/dts/st/ste-hrefv60plus.dtsi
+++ b/arch/arm/boot/dts/st/ste-hrefv60plus.dtsi
@@ -3,7 +3,6 @@
  * Copyright 2012 ST-Ericsson AB
  */
 
-#include "ste-href-ab8500.dtsi"
 #include "ste-href.dtsi"
 
 / {

-- 
2.34.1



From linus.walleij at linaro.org  Thu Dec 14 14:29:13 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 14 Dec 2023 23:29:13 +0100
Subject: [PATCH 2/3] ARM: dts: ux500-href: Push AB8500 config out
In-Reply-To: <20231214-ux500-no-turnoff-lowbatt-v1-0-9dcff0783d62@linaro.org>
References: <20231214-ux500-no-turnoff-lowbatt-v1-0-9dcff0783d62@linaro.org>
Message-ID: <20231214-ux500-no-turnoff-lowbatt-v1-2-9dcff0783d62@linaro.org>

Push out some AB8500 setup of regulators and phy out to the
per-AB850x variant file ste-href-ab8500.dtsi so it becomes
self-contained for each AB850x chip.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/st/ste-href-ab8500.dtsi | 48 +++++++++++++++++++++++++++
 arch/arm/boot/dts/st/ste-href.dtsi        | 55 -------------------------------
 2 files changed, 48 insertions(+), 55 deletions(-)

diff --git a/arch/arm/boot/dts/st/ste-href-ab8500.dtsi b/arch/arm/boot/dts/st/ste-href-ab8500.dtsi
index e1de9d389a01..5eeb44c5e932 100644
--- a/arch/arm/boot/dts/st/ste-href-ab8500.dtsi
+++ b/arch/arm/boot/dts/st/ste-href-ab8500.dtsi
@@ -9,6 +9,54 @@ / {
 	soc {
 		prcmu at 80157000 {
 			ab8500 {
+				phy {
+					pinctrl-names = "default", "sleep";
+					pinctrl-0 = <&usb_a_1_default>;
+					pinctrl-1 = <&usb_a_1_sleep>;
+				};
+
+				regulator {
+					ab8500_ldo_aux1_reg: ab8500_ldo_aux1 {
+						regulator-name = "V-DISPLAY";
+					};
+
+					ab8500_ldo_aux2_reg: ab8500_ldo_aux2 {
+						regulator-name = "V-eMMC1";
+					};
+
+					ab8500_ldo_aux3_reg: ab8500_ldo_aux3 {
+						regulator-name = "V-MMC-SD";
+					};
+
+					ab8500_ldo_intcore_reg: ab8500_ldo_intcore {
+						regulator-name = "V-INTCORE";
+					};
+
+					ab8500_ldo_tvout_reg: ab8500_ldo_tvout {
+						regulator-name = "V-TVOUT";
+					};
+
+					ab8500_ldo_audio_reg: ab8500_ldo_audio {
+						regulator-name = "V-AUD";
+					};
+
+					ab8500_ldo_anamic1_reg: ab8500_ldo_anamic1 {
+						regulator-name = "V-AMIC1";
+					};
+
+					ab8500_ldo_anamic2_reg: ab8500_ldo_anamic2 {
+						regulator-name = "V-AMIC2";
+					};
+
+					ab8500_ldo_dmic_reg: ab8500_ldo_dmic {
+						regulator-name = "V-DMIC";
+					};
+
+					ab8500_ldo_ana_reg: ab8500_ldo_ana {
+						regulator-name = "V-CSI/DSI";
+					};
+				};
+
 				gpio {
 					/* Hog a few default settings */
 					pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/st/ste-href.dtsi b/arch/arm/boot/dts/st/ste-href.dtsi
index 13b11dbeba1c..fbf0309e108f 100644
--- a/arch/arm/boot/dts/st/ste-href.dtsi
+++ b/arch/arm/boot/dts/st/ste-href.dtsi
@@ -242,61 +242,6 @@ msp3: msp at 80125000 {
 			status = "okay";
 		};
 
-		prcmu at 80157000 {
-			ab8500 {
-				gpio {
-				};
-
-				phy {
-					pinctrl-names = "default", "sleep";
-					pinctrl-0 = <&usb_a_1_default>;
-					pinctrl-1 = <&usb_a_1_sleep>;
-				};
-
-				regulator {
-					ab8500_ldo_aux1_reg: ab8500_ldo_aux1 {
-						regulator-name = "V-DISPLAY";
-					};
-
-					ab8500_ldo_aux2_reg: ab8500_ldo_aux2 {
-						regulator-name = "V-eMMC1";
-					};
-
-					ab8500_ldo_aux3_reg: ab8500_ldo_aux3 {
-						regulator-name = "V-MMC-SD";
-					};
-
-					ab8500_ldo_intcore_reg: ab8500_ldo_intcore {
-						regulator-name = "V-INTCORE";
-					};
-
-					ab8500_ldo_tvout_reg: ab8500_ldo_tvout {
-						regulator-name = "V-TVOUT";
-					};
-
-					ab8500_ldo_audio_reg: ab8500_ldo_audio {
-						regulator-name = "V-AUD";
-					};
-
-					ab8500_ldo_anamic1_reg: ab8500_ldo_anamic1 {
-						regulator-name = "V-AMIC1";
-					};
-
-					ab8500_ldo_anamic2_reg: ab8500_ldo_anamic2 {
-						regulator-name = "V-AMIC2";
-					};
-
-					ab8500_ldo_dmic_reg: ab8500_ldo_dmic {
-						regulator-name = "V-DMIC";
-					};
-
-					ab8500_ldo_ana_reg: ab8500_ldo_ana {
-						regulator-name = "V-CSI/DSI";
-					};
-				};
-			};
-		};
-
 		pinctrl {
 			sdi0 {
 				sdi0_default_mode: sdi0_default {

-- 
2.34.1



From linus.walleij at linaro.org  Thu Dec 14 14:29:14 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 14 Dec 2023 23:29:14 +0100
Subject: [PATCH 3/3] ARM: dts: ux500-href: Switch HREF520 to AB8505
In-Reply-To: <20231214-ux500-no-turnoff-lowbatt-v1-0-9dcff0783d62@linaro.org>
References: <20231214-ux500-no-turnoff-lowbatt-v1-0-9dcff0783d62@linaro.org>
Message-ID: <20231214-ux500-no-turnoff-lowbatt-v1-3-9dcff0783d62@linaro.org>

After noticing a tendency to misbehave and randomly power down:
switch the HREF520 AB8500 to the AB8505, which is what it has
mounted. After this the board works better.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/st/ste-href-ab8505.dtsi | 490 ++++++++++++++++++++++++++++++
 arch/arm/boot/dts/st/ste-href520-tvk.dts  |   2 +-
 2 files changed, 491 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/st/ste-href-ab8505.dtsi b/arch/arm/boot/dts/st/ste-href-ab8505.dtsi
new file mode 100644
index 000000000000..268db68ccf87
--- /dev/null
+++ b/arch/arm/boot/dts/st/ste-href-ab8505.dtsi
@@ -0,0 +1,490 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2023 Linus Walleij <linus.walleij at linaro.org>
+ */
+
+#include "ste-ab8505.dtsi"
+
+/ {
+	soc {
+		prcmu at 80157000 {
+			ab8505 {
+				phy {
+					pinctrl-names = "default", "sleep";
+					pinctrl-0 = <&usb_a_1_default>;
+					pinctrl-1 = <&usb_a_1_sleep>;
+				};
+
+				regulator {
+					ab8500_ldo_aux1_reg: ab8500_ldo_aux1 {
+						regulator-name = "V-DISPLAY";
+					};
+
+					ab8500_ldo_aux2_reg: ab8500_ldo_aux2 {
+						regulator-name = "V-eMMC1";
+					};
+
+					ab8500_ldo_aux3_reg: ab8500_ldo_aux3 {
+						regulator-name = "V-MMC-SD";
+					};
+
+					ab8500_ldo_intcore_reg: ab8500_ldo_intcore {
+						regulator-name = "V-INTCORE";
+					};
+
+					ab8500_ldo_tvout_reg: ab8500_ldo_tvout {
+						regulator-name = "V-TVOUT";
+					};
+
+					ab8500_ldo_audio_reg: ab8500_ldo_audio {
+						regulator-name = "V-AUD";
+					};
+
+					ab8500_ldo_anamic1_reg: ab8500_ldo_anamic1 {
+						regulator-name = "V-AMIC1";
+					};
+
+					ab8500_ldo_anamic2_reg: ab8500_ldo_anamic2 {
+						regulator-name = "V-AMIC2";
+					};
+
+					ab8500_ldo_dmic_reg: ab8500_ldo_dmic {
+						regulator-name = "V-DMIC";
+					};
+
+					ab8500_ldo_ana_reg: ab8500_ldo_ana {
+						regulator-name = "V-CSI/DSI";
+					};
+				};
+
+				gpio {
+					/* Hog a few default settings */
+					pinctrl-names = "default";
+					pinctrl-0 = <&gpio2_default_mode>,
+						    <&gpio4_default_mode>,
+						    <&gpio10_default_mode>,
+						    <&gpio11_default_mode>,
+						    <&gpio12_default_mode>,
+						    <&gpio13_default_mode>,
+						    <&gpio16_default_mode>,
+						    <&gpio24_default_mode>,
+						    <&gpio25_default_mode>,
+						    <&gpio36_default_mode>,
+						    <&gpio37_default_mode>,
+						    <&gpio38_default_mode>,
+						    <&gpio39_default_mode>,
+						    <&gpio42_default_mode>,
+						    <&gpio26_default_mode>,
+						    <&gpio35_default_mode>,
+						    <&ycbcr_default_mode>,
+						    <&pwm_default_mode>,
+						    <&adi1_default_mode>,
+						    <&usbuicc_default_mode>,
+						    <&dmic_default_mode>,
+						    <&extcpena_default_mode>,
+						    <&modsclsda_default_mode>;
+
+					/*
+					 * Pins 2, 4, 10, 11, 12, 13, 16, 24, 25, 36, 37, 38, 39 and 42
+					 * are muxed in as GPIO, and configured as INPUT PULL DOWN
+					 */
+					gpio2 {
+						gpio2_default_mode: gpio2_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio2_a_1";
+							};
+							default_cfg {
+								pins = "GPIO2_T9";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio4 {
+						gpio4_default_mode: gpio4_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio4_a_1";
+							};
+							default_cfg {
+								pins = "GPIO4_W2";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio10 {
+						gpio10_default_mode: gpio10_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio10_d_1";
+							};
+							default_cfg {
+								pins = "GPIO10_U17";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio11 {
+						gpio11_default_mode: gpio11_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio11_d_1";
+							};
+							default_cfg {
+								pins = "GPIO11_AA18";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio12 {
+						gpio12_default_mode: gpio12_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio12_d_1";
+							};
+							default_cfg {
+								pins = "GPIO12_U16";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio13 {
+						gpio13_default_mode: gpio13_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio13_d_1";
+							};
+							default_cfg {
+								pins = "GPIO13_W17";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio16 {
+						gpio16_default_mode: gpio16_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio16_a_1";
+							};
+							default_cfg {
+								pins = "GPIO16_F15";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio24 {
+						gpio24_default_mode: gpio24_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio24_a_1";
+							};
+							default_cfg {
+								pins = "GPIO24_T14";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio25 {
+						gpio25_default_mode: gpio25_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio25_a_1";
+							};
+							default_cfg {
+								pins = "GPIO25_R16";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio36 {
+						gpio36_default_mode: gpio36_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio36_a_1";
+							};
+							default_cfg {
+								pins = "GPIO36_A17";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio37 {
+						gpio37_default_mode: gpio37_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio37_a_1";
+							};
+							default_cfg {
+								pins = "GPIO37_E15";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio38 {
+						gpio38_default_mode: gpio38_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio38_a_1";
+							};
+							default_cfg {
+								pins = "GPIO38_C17";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio39 {
+						gpio39_default_mode: gpio39_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio39_a_1";
+							};
+							default_cfg {
+								pins = "GPIO39_E16";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					gpio42 {
+						gpio42_default_mode: gpio42_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio42_a_1";
+							};
+							default_cfg {
+								pins = "GPIO42_U2";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					/*
+					 * Pins 26 and 35 muxed in as GPIO, and configured as OUTPUT LOW
+					 */
+					gpio26 {
+						gpio26_default_mode: gpio26_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio26_d_1";
+							};
+							default_cfg {
+								pins = "GPIO26_M16";
+								output-low;
+							};
+						};
+					};
+					gpio35 {
+						gpio35_default_mode: gpio35_default {
+							default_mux {
+								function = "gpio";
+								groups = "gpio35_d_1";
+							};
+							default_cfg {
+								pins = "GPIO35_W15";
+								output-low;
+							};
+						};
+					};
+					/*
+					 * This sets up the YCBCR connector pins, i.e. analog video out.
+					 * Set as input with no bias.
+					 */
+					ycbcr {
+						ycbcr_default_mode: ycbcr_default {
+							default_mux {
+								function = "ycbcr";
+								groups = "ycbcr0123_d_1";
+							};
+							default_cfg {
+								pins = "GPIO6_Y18",
+									 "GPIO7_AA20",
+									 "GPIO8_W18",
+									 "GPIO9_AA19";
+								input-enable;
+								bias-disable;
+							};
+						};
+					};
+					/* This sets up the PWM pins 14 and 15 */
+					pwm {
+						pwm_default_mode: pwm_default {
+							default_mux {
+								function = "pwmout";
+								groups = "pwmout1_d_1", "pwmout2_d_1";
+							};
+							default_cfg {
+								pins = "GPIO14_F14",
+									 "GPIO15_B17";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					/* This sets up audio interface 1 */
+					adi1 {
+						adi1_default_mode: adi1_default {
+							default_mux {
+								function = "adi1";
+								groups = "adi1_d_1";
+							};
+							default_cfg {
+								pins = "GPIO17_P5",
+									 "GPIO18_R5",
+									 "GPIO19_U5",
+									 "GPIO20_T5";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					/* This sets up the USB UICC pins */
+					usbuicc {
+						usbuicc_default_mode: usbuicc_default {
+							default_mux {
+								function = "usbuicc";
+								groups = "usbuicc_d_1";
+							};
+							default_cfg {
+								pins = "GPIO21_H19",
+									 "GPIO22_G20",
+									 "GPIO23_G19";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					/* This sets up the microphone pins */
+					dmic {
+						dmic_default_mode: dmic_default {
+							default_mux {
+								function = "dmic";
+								groups = "dmic12_d_1",
+									 "dmic34_d_1",
+									 "dmic56_d_1";
+							};
+							default_cfg {
+								pins = "GPIO27_J6",
+									 "GPIO28_K6",
+									 "GPIO29_G6",
+									 "GPIO30_H6",
+									 "GPIO31_F5",
+									 "GPIO32_G5";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					extcpena {
+						extcpena_default_mode: extcpena_default {
+							default_mux {
+								function = "extcpena";
+								groups = "extcpena_d_1";
+							};
+							default_cfg {
+								pins = "GPIO34_R17";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					/* Modem I2C setup (SCL and SDA pins) */
+					modsclsda {
+						modsclsda_default_mode: modsclsda_default {
+							default_mux {
+								function = "modsclsda";
+								groups = "modsclsda_d_1";
+							};
+							default_cfg {
+								pins = "GPIO40_T19",
+									"GPIO41_U19";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					/*
+					 * Clock output pins associated with regulators.
+					 */
+					sysclkreq2 {
+						sysclkreq2_default_mode: sysclkreq2_default {
+							default_mux {
+								function = "sysclkreq";
+								groups = "sysclkreq2_d_1";
+							};
+							default_cfg {
+								pins = "GPIO1_T10";
+								input-enable;
+								bias-disable;
+							};
+						};
+						sysclkreq2_sleep_mode: sysclkreq2_sleep {
+							default_mux {
+								function = "gpio";
+								groups = "gpio1_a_1";
+							};
+							default_cfg {
+								pins = "GPIO1_T10";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+					sysclkreq4 {
+						sysclkreq4_default_mode: sysclkreq4_default {
+							default_mux {
+								function = "sysclkreq";
+								groups = "sysclkreq4_d_1";
+							};
+							default_cfg {
+								pins = "GPIO3_U9";
+								input-enable;
+								bias-disable;
+							};
+						};
+						sysclkreq4_sleep_mode: sysclkreq4_sleep {
+							default_mux {
+								function = "gpio";
+								groups = "gpio3_a_1";
+							};
+							default_cfg {
+								pins = "GPIO3_U9";
+								input-enable;
+								bias-pull-down;
+							};
+						};
+					};
+				};
+				/*
+				 * Charging is not working on the HREF unless an actual battery is
+				 * mounted, most HREFs have a DC cable in to the "battery power"
+				 * which means this will only be cofusing. So do not enable charging
+				 * of the HREFs.
+				 */
+				ab8500_fg {
+					status = "disabled";
+				};
+				ab8500_btemp {
+					status = "disabled";
+				};
+				ab8500_charger {
+					status = "disabled";
+				};
+				ab8500_chargalg {
+					status = "disabled";
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/st/ste-href520-tvk.dts b/arch/arm/boot/dts/st/ste-href520-tvk.dts
index 930058a8e0d1..5677df43c3ac 100644
--- a/arch/arm/boot/dts/st/ste-href520-tvk.dts
+++ b/arch/arm/boot/dts/st/ste-href520-tvk.dts
@@ -5,7 +5,7 @@
 
 /dts-v1/;
 #include "ste-db8520.dtsi"
-#include "ste-href-ab8500.dtsi"
+#include "ste-href-ab8505.dtsi"
 #include "ste-hrefv60plus.dtsi"
 #include "ste-href-tvk1281618-r3.dtsi"
 

-- 
2.34.1



From robh at kernel.org  Thu Dec 14 14:36:04 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 14 Dec 2023 16:36:04 -0600
Subject: [PATCH 06/15] arm64: Add KHO support
In-Reply-To: <20231213000452.88295-7-graf@amazon.com>
References: <20231213000452.88295-1-graf@amazon.com>
 <20231213000452.88295-7-graf@amazon.com>
Message-ID: <20231214223604.GA1045434-robh@kernel.org>

On Wed, Dec 13, 2023 at 12:04:43AM +0000, Alexander Graf wrote:
> We now have all bits in place to support KHO kexecs. This patch adds
> awareness of KHO in the kexec file as well as boot path for arm64 and
> adds the respective kconfig option to the architecture so that it can
> use KHO successfully.
> 
> Signed-off-by: Alexander Graf <graf at amazon.com>
> ---
>  arch/arm64/Kconfig        | 12 ++++++++++++
>  arch/arm64/kernel/setup.c |  2 ++
>  arch/arm64/mm/init.c      |  8 ++++++++
>  drivers/of/fdt.c          | 41 +++++++++++++++++++++++++++++++++++++++
>  drivers/of/kexec.c        | 36 ++++++++++++++++++++++++++++++++++
>  5 files changed, 99 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7b071a00425d..1ba338ce7598 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1501,6 +1501,18 @@ config ARCH_SUPPORTS_CRASH_DUMP
>  config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
>  	def_bool CRASH_CORE
>  
> +config KEXEC_KHO
> +	bool "kexec handover"
> +	depends on KEXEC
> +	select MEMBLOCK_SCRATCH
> +	select LIBFDT
> +	select CMA
> +	help
> +	  Allow kexec to hand over state across kernels by generating and
> +	  passing additional metadata to the target kernel. This is useful
> +	  to keep data or state alive across the kexec. For this to work,
> +	  both source and target kernels need to have this option enabled.

Why do we have the same kconfig entry twice? Here and x86.

> +
>  config TRANS_TABLE
>  	def_bool y
>  	depends on HIBERNATION || KEXEC_CORE
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 417a8a86b2db..8035b673d96d 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -346,6 +346,8 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
>  
>  	paging_init();
>  
> +	kho_reserve_mem();
> +
>  	acpi_table_upgrade();
>  
>  	/* Parse the ACPI tables for possible boot-time configuration */
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 74c1db8ce271..254d82f3383a 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -358,6 +358,8 @@ void __init bootmem_init(void)
>  	 */
>  	arch_reserve_crashkernel();
>  
> +	kho_reserve();
> +

reserve what? It is not obvious what the difference between 
kho_reserve_mem() and kho_reserve() are.

>  	memblock_dump_all();
>  }
>  
> @@ -386,6 +388,12 @@ void __init mem_init(void)
>  	/* this will put all unused low memory onto the freelists */
>  	memblock_free_all();
>  
> +	/*
> +	 * Now that all KHO pages are marked as reserved, let's flip them back
> +	 * to normal pages with accurate refcount.
> +	 */
> +	kho_populate_refcount();
> +
>  	/*
>  	 * Check boundaries twice: Some fundamental inconsistencies can be
>  	 * detected at build time already.
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index bf502ba8da95..af95139351ed 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1006,6 +1006,44 @@ void __init early_init_dt_check_for_usable_mem_range(void)
>  		memblock_add(rgn[i].base, rgn[i].size);
>  }
>  
> +/**
> + * early_init_dt_check_kho - Decode info required for kexec handover from DT
> + */
> +void __init early_init_dt_check_kho(void)
> +{
> +#ifdef CONFIG_KEXEC_KHO

if (!IS_ENABLED(CONFIG_KEXEC_KHO))
  return;

You'll need a kho_populate() stub.

> +	unsigned long node = chosen_node_offset;
> +	u64 kho_start, scratch_start, scratch_size, mem_start, mem_size;
> +	const __be32 *p;
> +	int l;
> +
> +	if ((long)node < 0)
> +		return;
> +
> +	p = of_get_flat_dt_prop(node, "linux,kho-dt", &l);
> +	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
> +		return;
> +
> +	kho_start = dt_mem_next_cell(dt_root_addr_cells, &p);
> +
> +	p = of_get_flat_dt_prop(node, "linux,kho-scratch", &l);
> +	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
> +		return;
> +
> +	scratch_start = dt_mem_next_cell(dt_root_addr_cells, &p);
> +	scratch_size = dt_mem_next_cell(dt_root_addr_cells, &p);
> +
> +	p = of_get_flat_dt_prop(node, "linux,kho-mem", &l);
> +	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
> +		return;
> +
> +	mem_start = dt_mem_next_cell(dt_root_addr_cells, &p);
> +	mem_size = dt_mem_next_cell(dt_root_addr_cells, &p);
> +
> +	kho_populate(kho_start, scratch_start, scratch_size, mem_start, mem_size);
> +#endif
> +}
> +
>  #ifdef CONFIG_SERIAL_EARLYCON
>  
>  int __init early_init_dt_scan_chosen_stdout(void)
> @@ -1304,6 +1342,9 @@ void __init early_init_dt_scan_nodes(void)
>  
>  	/* Handle linux,usable-memory-range property */
>  	early_init_dt_check_for_usable_mem_range();
> +
> +	/* Handle kexec handover */
> +	early_init_dt_check_kho();
>  }
>  
>  bool __init early_init_dt_scan(void *params)
> diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
> index 68278340cecf..a612e6bb8c75 100644
> --- a/drivers/of/kexec.c
> +++ b/drivers/of/kexec.c
> @@ -264,6 +264,37 @@ static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
>  }
>  #endif /* CONFIG_IMA_KEXEC */
>  
> +static int kho_add_chosen(const struct kimage *image, void *fdt, int chosen_node)
> +{
> +	int ret = 0;
> +
> +#ifdef CONFIG_KEXEC_KHO

ditto

Though perhaps image->kho is not defined?


> +	if (!image->kho.dt.buffer || !image->kho.mem_cache.buffer)
> +		goto out;
> +
> +	pr_debug("Adding kho metadata to DT");
> +
> +	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-dt",
> +				       image->kho.dt.mem, image->kho.dt.memsz);
> +	if (ret)
> +		goto out;
> +
> +	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-scratch",
> +				       kho_scratch_phys, kho_scratch_len);
> +	if (ret)
> +		goto out;
> +
> +	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-mem",
> +				       image->kho.mem_cache.mem,
> +				       image->kho.mem_cache.bufsz);
> +	if (ret)
> +		goto out;
> +
> +out:
> +#endif
> +	return ret;
> +}
> +
>  /*
>   * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
>   *
> @@ -412,6 +443,11 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
>  		}
>  	}
>  
> +	/* Add kho metadata if this is a KHO image */
> +	ret = kho_add_chosen(image, fdt, chosen_node);
> +	if (ret)
> +		goto out;
> +
>  	/* add bootargs */
>  	if (cmdline) {
>  		ret = fdt_setprop_string(fdt, chosen_node, "bootargs", cmdline);
> -- 
> 2.40.1
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
> 
> 


From robh at kernel.org  Thu Dec 14 14:43:04 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 14 Dec 2023 16:43:04 -0600
Subject: [PATCH 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1
 isoc-in transfer issue
In-Reply-To: <5327b2fd-94c6-46fe-b987-52cfff042033@collabora.com>
References: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
 <c1bc144d-07d6-422c-8294-42be47f83e59@linaro.org>
 <5327b2fd-94c6-46fe-b987-52cfff042033@collabora.com>
Message-ID: <20231214224304.GA1062298-robh@kernel.org>

On Wed, Dec 13, 2023 at 12:17:17PM +0100, AngeloGioacchino Del Regno wrote:
> Il 13/12/23 09:05, Krzysztof Kozlowski ha scritto:
> > On 13/12/2023 07:35, Chunfeng Yun wrote:
> > > For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
> > > still send out unexpected ACK after receiving a short packet in burst
> > > transfer, this will cause an exception on connected device, specially for
> > > a 4k camera.
> > > Add a quirk property "mediatek,rxfifo-depth" to work around this hardware
> > > issue;
> > > The side-effect is that may cause performance drop about 10%, including
> > > bulk transfer.
> > > 
> > > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > > ---
> > >   .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml     | 10 ++++++++++
> > >   1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> > > index e9644e333d78..b8ed68574ba4 100644
> > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> > > @@ -124,6 +124,16 @@ properties:
> > >         defined in the xHCI spec on MTK's controller.
> > >       default: 5000
> > > +  mediatek,rxfifo-depth:
> > > +    description:
> > 
> > The property description and driver patch suggest you configure the
> > depth of FIFO, so this should be not bool, but some uint32. And then,
> > use generic "fifo-depth" property to set desired depth.
> 
> Did you mean "rx-fifo-depth" instead, as used in net?
> This FIFO depth parameter is for RX only.

Or rx-fifo-size. There's so many to choose from.

Rob


From cl at linux.com  Thu Dec 14 16:05:56 2023
From: cl at linux.com (Christoph Lameter (Ampere))
Date: Thu, 14 Dec 2023 16:05:56 -0800 (PST)
Subject: [PATCH] ARM64: Dynamically allocate cpumasks and increase supported
 CPUs to 512
Message-ID: <794a1211-630b-3ee5-55a3-c06f10df1490@linux.com>

Ampere Computing develops high end ARM processor that support an ever
increasing number of processors. The default 256 processors are
not enough for our newer products. The default is used by
distros and therefore our customers cannot use distro kernels because
the number of processors is not supported.

One of the objections against earlier patches to increase the limit
was that the memory use becomes too high. There is a feature called
CPUMASK_OFFSTACK that configures the cpumasks in the kernel to be
dynamically allocated. This was used in the X86 architecture in the
past to enable support for larger CPU configurations up to 8k cpus.

With that is becomes possible to dynamically size the allocation of
the cpu bitmaps depending on the quantity of processors detected on
bootup.

This patch enables that logic if more than 256 processors
are configured and increases the default to 512 processors.

Further increases may be needed if ARM processor vendors start
supporting more processors. Given the current inflationary trends
in core counts from multiple processor manufacturers this may occur.

Signed-off-by: Christoph Lameter (Ampere) <cl at linux.com>

---

This was discussed earlier and this updated patch was proposed at 
https://lore.kernel.org/linux-arm-kernel/6a854175-5f89-c754-17b8-deda18447f1f at gentwo.org/T/


Index: linux/arch/arm64/Kconfig
===================================================================
--- linux.orig/arch/arm64/Kconfig
+++ linux/arch/arm64/Kconfig
@@ -1407,7 +1407,21 @@ config SCHED_SMT
   config NR_CPUS
   	int "Maximum number of CPUs (2-4096)"
   	range 2 4096
-	default "256"
+	default 512
+
+#
+# Determines the placement of cpumasks.
+#
+# With CPUMASK_OFFSTACK the cpumasks are dynamically allocated.
+# Useful for machines with lots of core because it avoids increasing
+# the size of many of the data structures in the kernel.
+#
+# If this is off then the cpumasks have a static sizes and are
+# embedded within data structures.
+#
+config CPUMASK_OFFSTACK
+	def_bool y
+	depends on NR_CPUS > 256

   config HOTPLUG_CPU
   	bool "Support for hot-pluggable CPUs"




From andi.shyti at kernel.org  Thu Dec 14 17:42:48 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Fri, 15 Dec 2023 02:42:48 +0100
Subject: [PATCH v4 1/2] i2c: aspeed: Handle the coalesced stop conditions
 with the start conditions.
In-Reply-To: <20231211102217.2436294-2-quan@os.amperecomputing.com>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
 <20231211102217.2436294-2-quan@os.amperecomputing.com>
Message-ID: <20231215014248.6f7sqh6n4kmhe4js@zenone.zhora.eu>

Hi Quan,

On Mon, Dec 11, 2023 at 05:22:16PM +0700, Quan Nguyen wrote:
> Some masters may drive the transfers with low enough latency between
> the nak/stop phase of the current command and the start/address phase
> of the following command that the interrupts are coalesced by the
> time we process them.
> Handle the stop conditions before processing SLAVE_MATCH to fix the
> complaints that sometimes occur below.
> 
> "aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
> 0x00000086, but was 0x00000084"
> 
> Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
> ---
> v4:
>   + Add an extra empty line before the comment                        [Andrew]
> 
> Note: I'd like to keep adding Reviewed-by Andrew and Andi for this patch
> eventhough there is an extra empty line added before the comment as mentioned
> above. Thanks for the review.

that's OK and you should. You would remove the r-b/a-b only if
you do some major changes. Besides, this change was asked both by
me and Andrew.

Thanks,
Andi


From andi.shyti at kernel.org  Thu Dec 14 17:45:05 2023
From: andi.shyti at kernel.org (Andi Shyti)
Date: Fri, 15 Dec 2023 02:45:05 +0100
Subject: [PATCH v4 2/2] i2c: aspeed: Acknowledge Tx done with and without
 ACK irq late
In-Reply-To: <20231211102217.2436294-3-quan@os.amperecomputing.com>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
 <20231211102217.2436294-3-quan@os.amperecomputing.com>
Message-ID: <20231215014505.he6ozzxd5jnjgvol@zenone.zhora.eu>

Hi Quan,

On Mon, Dec 11, 2023 at 05:22:17PM +0700, Quan Nguyen wrote:
> Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
> interrupt handler") acknowledges most interrupts early before the slave
> irq handler is executed, except for the "Receive Done Interrupt status"
> which is acknowledged late in the interrupt.
> However, it has been observed that the early acknowledgment of "Transmit
> Done Interrupt Status" (with ACK or NACK) often causes the interrupt to
> be raised in READ REQUEST state, that shows the
> "Unexpected ACK on read request." complaint messages.
> 
> Assuming that the "Transmit Done" interrupt should only be acknowledged
> once it is truly processed, this commit fixes that issue by acknowledging
> interrupts for both ACK and NACK cases late in the interrupt handler.
> 
> Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>

Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Thanks,
Andi


From xu.yang_2 at nxp.com  Thu Dec 14 17:56:50 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri, 15 Dec 2023 01:56:50 +0000
Subject: [EXT] Re: [PATCH 2/4] arm64: dts: imx8ulp-evk: enable usb nodes
In-Reply-To: <CAOMZO5DxQGjF5rUs6NMR7LCo11tLVPpnPs9nzH7qh2nCCBXoLQ@mail.gmail.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
 <20231214112442.2412079-2-xu.yang_2@nxp.com>
 <CAOMZO5DxcLoBYMXQi=EW=-fAqz12ghPm+7PHn=LdhicETKg2pQ@mail.gmail.com>
 <VI1PR04MB51523F1EF74EF23B92C6880D8C8CA@VI1PR04MB5152.eurprd04.prod.outlook.com>
 <CAOMZO5DxQGjF5rUs6NMR7LCo11tLVPpnPs9nzH7qh2nCCBXoLQ@mail.gmail.com>
Message-ID: <DB7PR04MB5146E3187D86B808574C56B58C93A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Fabio,

> 
> On Thu, Dec 14, 2023 at 9:50?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
> 
> > PTN5150 can work autonomously for most of the basic functions.
> > I don?t see a need to enable driver for it now.
> 
> We are talking about devicetree here, not driver.
> 
> If the PTN5150 is present on the board, then just represent it in the
> devicetree.

Understood. Will consider this in v2.

Thanks,
Xu Yang

From xu.yang_2 at nxp.com  Thu Dec 14 18:12:43 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri, 15 Dec 2023 02:12:43 +0000
Subject: [EXT] Re: [PATCH 3/4] arm64: dts: imx93: add usb nodes
In-Reply-To: <8309719.T7Z3S40VBb@steina-w>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
 <20231214112442.2412079-3-xu.yang_2@nxp.com> <8309719.T7Z3S40VBb@steina-w>
Message-ID: <DB7PR04MB51462A079F226C6B9FCA9F7C8C93A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Alexander,

>
> Hi,
>
> thanks for the patch.
>
> Am Donnerstag, 14. Dezember 2023, 12:24:41 CET schrieb Xu Yang:
> > There are 2 USB controllers on i.MX93. Add them.
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx93.dtsi | 58 ++++++++++++++++++++++++
> >  1 file changed, 58 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi
> > b/arch/arm64/boot/dts/freescale/imx93.dtsi index 34c0540276d1..bcf4861cfede
> > 100644
> > --- a/arch/arm64/boot/dts/freescale/imx93.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
> > @@ -171,6 +171,20 @@ cm33: remoteproc-cm33 {
> >               status = "disabled";
> >       };
> >
> > +     usbphynop1: usbphynop1 {
> > +             #phy-cells = <0>;
> > +             compatible = "usb-nop-xceiv";
>
> compatible first.

Okay.

>
> > +             clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> > +             clock-names = "main_clk";
> > +     };
> > +
> > +     usbphynop2: usbphynop2 {
> > +             #phy-cells = <0>;
> > +             compatible = "usb-nop-xceiv";
>
> compatible first.

Okay.

>
> > +             clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> > +             clock-names = "main_clk";
> > +     };
> > +
> >       soc at 0 {
> >               compatible = "simple-bus";
> >               #address-cells = <1>;
> > @@ -1059,5 +1073,49 @@ ddr-pmu at 4e300dc0 {
> >                       reg = <0x4e300dc0 0x200>;
> >                       interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
> >               };
> > +
> > +             usbotg1: usb at 4c100000 {
> > +                     compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb",
> "fsl,imx27-usb";
> > +                     reg = <0x4c100000 0x200>;
> > +                     interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
> > +                     clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> > +                              <&clk IMX93_CLK_HSIO_32K_GATE>;
> > +                     clock-names = "usb_ctrl_root_clk",
> "usb_wakeup_clk";
>
> drivers/usb/chipidea/ci_hdrc_imx.c uses 3 clocks: "ipg", "ahb" and "per", see
> imx_get_clks(). How is this supposed to work?

I have sent another patch to get this clock.
https://lore.kernel.org/all/20231214112622.2412321-1-xu.yang_2 at nxp.com/

>
> > +                     assigned-clocks = <&clk IMX93_CLK_HSIO>;
> > +                     assigned-clock-parents = <&clk
> IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> > +                     assigned-clock-rates = <133000000>;
> > +                     fsl,usbphy = <&usbphynop1>;
> > +                     fsl,usbmisc = <&usbmisc1 0>;
> > +                     status = "disabled";
> > +             };
> > +
> > +             usbmisc1: usbmisc at 4c100200 {
> > +                     compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-
> usbmisc",
> > +                                     "fsl,imx6q-usbmisc";
>
> This means you are compatible to fsl,imx7d-usbmisc. Which means you use
> register MX7D_USB_OTG_PHY_STATUS in USB misc (USBNC). But i.MX93 RM Rev. 2
> (04/2023) lacks this and other registers.

Some registers in USBNC are not shown. The internal RM has these registers.

>
> > +                     #index-cells = <1>;
> > +                     reg = <0x4c100200 0x200>;
>
> reg after compatible.

Okay.

>
> > +             };
> > +
> > +             usbotg2: usb at 4c200000 {
> > +                     compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb",
> "fsl,imx27-usb";
> > +                     reg = <0x4c200000 0x200>;
> > +                     interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
> > +                     clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> > +                              <&clk IMX93_CLK_HSIO_32K_GATE>;
> > +                     clock-names = "usb_ctrl_root_clk",
> "usb_wakeup_clk";
>
> The same as for usbotg1 applies here.

Okay.

>
> > +                     assigned-clocks = <&clk IMX93_CLK_HSIO>;
> > +                     assigned-clock-parents = <&clk
> IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> > +                     assigned-clock-rates = <133000000>;
> > +                     fsl,usbphy = <&usbphynop2>;
> > +                     fsl,usbmisc = <&usbmisc2 0>;
> > +                     status = "disabled";
> > +             };
> > +
> > +             usbmisc2: usbmisc at 4c200200 {
> > +                     compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-
> usbmisc",
> > +                                     "fsl,imx6q-usbmisc";
> > +                     #index-cells = <1>;
> > +                     reg = <0x4c200200 0x200>;
>
> The same as for usbmisc1 applies here.

Okay.

>
> > +             };
> >       };
> >  };
>
> Best regards,
> Alexander
>
> --
> TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht M?nchen, HRB 105018
> Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
> http://www.tq-/
> group.com%2F&data=05%7C02%7Cxu.yang_2%40nxp.com%7C10ff5a35f53f4047ae1d08dbfca99c38%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C638381577622080432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VlpRPcnJTmywfSamaGB1Ev8aPN2Hi596VbbRNGXF
> yis%3D&reserved=0
>



From xu.yang_2 at nxp.com  Thu Dec 14 18:21:52 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri, 15 Dec 2023 02:21:52 +0000
Subject: [EXT] Re: [PATCH 4/4] arm64: dts: imx93-11x11-evk: enable usb and
 typec nodes
In-Reply-To: <1952554.PYKUYFuaPT@steina-w>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
 <20231214112442.2412079-4-xu.yang_2@nxp.com> <1952554.PYKUYFuaPT@steina-w>
Message-ID: <DB7PR04MB514686AD6E084BF0466422838C93A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Alexander,

> 
> Hi,
> 
> thanks for the patch.
> 
> Am Donnerstag, 14. Dezember 2023, 12:24:42 CET schrieb Xu Yang:
> > There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > ---
> >  .../boot/dts/freescale/imx93-11x11-evk.dts    | 108 ++++++++++++++++++
> >  1 file changed, 108 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts index
> > 2b9d47716f75..42b1ea7d5220 100644
> > --- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > @@ -5,6 +5,7 @@
> >
> >  /dts-v1/;
> >
> > +#include <dt-bindings/usb/pd.h>
> >  #include "imx93.dtsi"
> >
> >  / {
> > @@ -103,6 +104,70 @@ &mu2 {
> >       status = "okay";
> >  };
> >
> > +&lpi2c3 {
> > +     #address-cells = <1>;
> > +     #size-cells = <0>;
> > +     clock-frequency = <400000>;
> > +     pinctrl-names = "default", "sleep";
> > +     pinctrl-0 = <&pinctrl_lpi2c3>;
> > +     pinctrl-1 = <&pinctrl_lpi2c3>;
> > +     status = "okay";
> > +
> > +     ptn5110: tcpc at 50 {
> 
> I do not know if there is already some consent, but personally I do not like
> tcpc for the node name. Maybe change that to usb-typec at 50.

It really doesn't matter. The connector node will clear say it's a typec port.

> 
> > +             compatible = "nxp,ptn5110";
> > +             reg = <0x50>;
> > +             interrupt-parent = <&gpio3>;
> > +             interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> > +             status = "okay";
> 
> status not needed here, "okay" is default and node is added here.

Yeah. 

> 
> > +
> > +             port {
> > +                     typec1_dr_sw: endpoint {
> > +                             remote-endpoint = <&usb1_drd_sw>;
> > +                     };
> > +             };
> > +
> > +             typec1_con: connector {
> > +                     compatible = "usb-c-connector";
> > +                     label = "USB-C";
> > +                     power-role = "dual";
> > +                     data-role = "dual";
> > +                     try-power-role = "sink";
> > +                     source-pdos = <PDO_FIXED(5000, 3000,
> PDO_FIXED_USB_COMM)>;
> > +                     sink-pdos = <PDO_FIXED(5000, 3000,
> PDO_FIXED_USB_COMM)
> > +                                  PDO_VAR(5000, 20000, 3000)>;
> > +                     op-sink-microwatt = <15000000>;
> > +                     self-powered;
> > +             };
> > +     };
> > +
> > +     ptn5110_2: tcpc at 51 {
> 
> See above.
> 
> > +             compatible = "nxp,ptn5110";
> > +             reg = <0x51>;
> > +             interrupt-parent = <&gpio3>;
> > +             interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> > +             status = "okay";
> 
> See above.

Okay.

Thanks,
Xu Yang

> 
> Best regards,
> Alexander
> 
> > +
> > +             port {
> > +                     typec2_dr_sw: endpoint {
> > +                             remote-endpoint = <&usb2_drd_sw>;
> > +                     };
> > +             };
> > +
> > +             typec2_con: connector {
> > +                     compatible = "usb-c-connector";
> > +                     label = "USB-C";
> > +                     power-role = "dual";
> > +                     data-role = "dual";
> > +                     try-power-role = "sink";
> > +                     source-pdos = <PDO_FIXED(5000, 3000,
> PDO_FIXED_USB_COMM)>;
> > +                     sink-pdos = <PDO_FIXED(5000, 3000,
> PDO_FIXED_USB_COMM)
> > +                                  PDO_VAR(5000, 20000, 3000)>;
> > +                     op-sink-microwatt = <15000000>;
> > +                     self-powered;
> > +             };
> > +     };
> > +};
> > +
> >  &eqos {
> >       pinctrl-names = "default";
> >       pinctrl-0 = <&pinctrl_eqos>;
> > @@ -155,6 +220,42 @@ &lpuart5 {
> >       status = "okay";
> >  };
> >
> > +&usbotg1 {
> > +     dr_mode = "otg";
> > +     hnp-disable;
> > +     srp-disable;
> > +     adp-disable;
> > +     usb-role-switch;
> > +     disable-over-current;
> > +     samsung,picophy-pre-emp-curr-control = <3>;
> > +     samsung,picophy-dc-vol-level-adjust = <7>;
> > +     status = "okay";
> > +
> > +     port {
> > +             usb1_drd_sw: endpoint {
> > +                     remote-endpoint = <&typec1_dr_sw>;
> > +             };
> > +     };
> > +};
> > +
> > +&usbotg2 {
> > +     dr_mode = "otg";
> > +     hnp-disable;
> > +     srp-disable;
> > +     adp-disable;
> > +     usb-role-switch;
> > +     disable-over-current;
> > +     samsung,picophy-pre-emp-curr-control = <3>;
> > +     samsung,picophy-dc-vol-level-adjust = <7>;
> > +     status = "okay";
> > +
> > +     port {
> > +             usb2_drd_sw: endpoint {
> > +                     remote-endpoint = <&typec2_dr_sw>;
> > +             };
> > +     };
> > +};
> > +
> >  &usdhc1 {
> >       pinctrl-names = "default", "state_100mhz", "state_200mhz";
> >       pinctrl-0 = <&pinctrl_usdhc1>;
> > @@ -221,6 +322,13 @@ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL        0x57e
> >
> >               >;
> >
> >       };
> >
> > +     pinctrl_lpi2c3: lpi2c3grp {
> > +             fsl,pins = <
> > +                     MX93_PAD_GPIO_IO28__LPI2C3_SDA
> 0x40000b9e
> > +                     MX93_PAD_GPIO_IO29__LPI2C3_SCL
> 0x40000b9e
> > +             >;
> > +     };
> > +
> >       pinctrl_uart1: uart1grp {
> >               fsl,pins = <
> >                       MX93_PAD_UART1_RXD__LPUART1_RX
> 0x31e
> 
> 



From jason-jh.lin at mediatek.com  Thu Dec 14 18:35:46 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 15 Dec 2023 10:35:46 +0800
Subject: [PATCH 2/2] mailbox: mtk-cmdq: Add CMDQ driver support for mt8188
In-Reply-To: <20231215023546.6594-1-jason-jh.lin@mediatek.com>
References: <20231215023546.6594-1-jason-jh.lin@mediatek.com>
Message-ID: <20231215023546.6594-3-jason-jh.lin@mediatek.com>

Add CMDQ driver support for mt8188 by adding its compatible and
driver data in CMDQ driver.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/mailbox/mtk-cmdq-mailbox.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 76e5f762628c..612b9feb258a 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -749,11 +749,19 @@ static const struct gce_plat gce_plat_v7 = {
 	.gce_num = 1
 };
 
+static const struct gce_plat gce_plat_v8 = {
+	.thread_nr = 32,
+	.shift = 3,
+	.control_by_sw = true,
+	.gce_num = 2
+};
+
 static const struct of_device_id cmdq_of_ids[] = {
 	{.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
 	{.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_v2},
 	{.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_v3},
 	{.compatible = "mediatek,mt8186-gce", .data = (void *)&gce_plat_v7},
+	{.compatible = "mediatek,mt8188-gce", .data = (void *)&gce_plat_v8},
 	{.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_v5},
 	{.compatible = "mediatek,mt8195-gce", .data = (void *)&gce_plat_v6},
 	{}
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 14 18:35:44 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 15 Dec 2023 10:35:44 +0800
Subject: [PATCH 0/2] Add CMDQ driver support for mt8188
Message-ID: <20231215023546.6594-1-jason-jh.lin@mediatek.com>

From: Jason-jh Lin <jason-jh.lin at mediatek.corp-partner.google.com>

Since mt8188 has 32 GCE HW thread, we nedd a new platform data to
support it.

So we sort the platform data in numerical order of compatible names and
add a new mt8188 platform data.

Jason-JH.Lin (2):
  mailbox: mtk-cmdq: Sort cmdq platform data by compatible name
  mailbox: mtk-cmdq: Add CMDQ driver support for mt8188

 drivers/mailbox/mtk-cmdq-mailbox.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 14 18:35:45 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 15 Dec 2023 10:35:45 +0800
Subject: [PATCH 1/2] mailbox: mtk-cmdq: Sort cmdq platform data by compatible name
In-Reply-To: <20231215023546.6594-1-jason-jh.lin@mediatek.com>
References: <20231215023546.6594-1-jason-jh.lin@mediatek.com>
Message-ID: <20231215023546.6594-2-jason-jh.lin@mediatek.com>

Sort cmdq platform data according to the number sequence of
compatible names.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/mailbox/mtk-cmdq-mailbox.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index de862e9137d5..76e5f762628c 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -750,10 +750,10 @@ static const struct gce_plat gce_plat_v7 = {
 };
 
 static const struct of_device_id cmdq_of_ids[] = {
+	{.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
 	{.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_v2},
 	{.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_v3},
 	{.compatible = "mediatek,mt8186-gce", .data = (void *)&gce_plat_v7},
-	{.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
 	{.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_v5},
 	{.compatible = "mediatek,mt8195-gce", .data = (void *)&gce_plat_v6},
 	{}
-- 
2.18.0



From lihuisong at huawei.com  Thu Dec 14 18:41:40 2023
From: lihuisong at huawei.com (lihuisong (C))
Date: Fri, 15 Dec 2023 10:41:40 +0800
Subject: [PATCH] cpufreq: CPPC: Resolve the large frequency discrepancy
 from cpuinfo_cur_freq
In-Reply-To: <CAJZ5v0jwW0=8cNvC-Vu_o+pEHFpN9nrPD4LXCpmSTgQBTHODgg@mail.gmail.com>
References: <20231212072617.14756-1-lihuisong@huawei.com>
 <CAJZ5v0jwW0=8cNvC-Vu_o+pEHFpN9nrPD4LXCpmSTgQBTHODgg@mail.gmail.com>
Message-ID: <486f8563-42b7-a049-97a2-bc0b553926aa@huawei.com>

Hi Rafael,

Thanks for your review.?

? 2023/12/15 3:31, Rafael J. Wysocki ??:
> On Tue, Dec 12, 2023 at 8:26?AM Huisong Li <lihuisong at huawei.com> wrote:
>> Many developers found that the cpu current frequency is greater than
>> the maximum frequency of the platform, please see [1], [2] and [3].
>>
>> In the scenarios with high memory access pressure, the patch [1] has
>> proved the significant latency of cpc_read() which is used to obtain
>> delivered and reference performance counter cause an absurd frequency.
>> The sampling interval for this counters is very critical and is expected
>> to be equal. However, the different latency of cpc_read() has a direct
>> impact on their sampling interval.
>>
>> This patch adds a interface, cpc_read_arch_counters_on_cpu, to read
>> delivered and reference performance counter together. According to my
>> test[4], the discrepancy of cpu current frequency in the scenarios with
>> high memory access pressure is lower than 0.2% by stress-ng application.
>>
>> [1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4 at huawei.com/
>> [2] https://lore.kernel.org/all/20230328193846.8757-1-yang at os.amperecomputing.com/
>> [3] https://lore.kernel.org/all/20230418113459.12860-7-sumitg at nvidia.com/
>>
>> [4] My local test:
>> The testing platform enable SMT and include 128 logical CPU in total,
>> and CPU base frequency is 2.7GHz. Reading "cpuinfo_cur_freq" for each
>> physical core on platform during the high memory access pressure from
>> stress-ng, and the output is as follows:
>>    0: 2699133     2: 2699942     4: 2698189     6: 2704347
>>    8: 2704009    10: 2696277    12: 2702016    14: 2701388
>>   16: 2700358    18: 2696741    20: 2700091    22: 2700122
>>   24: 2701713    26: 2702025    28: 2699816    30: 2700121
>>   32: 2700000    34: 2699788    36: 2698884    38: 2699109
>>   40: 2704494    42: 2698350    44: 2699997    46: 2701023
>>   48: 2703448    50: 2699501    52: 2700000    54: 2699999
>>   56: 2702645    58: 2696923    60: 2697718    62: 2700547
>>   64: 2700313    66: 2700000    68: 2699904    70: 2699259
>>   72: 2699511    74: 2700644    76: 2702201    78: 2700000
>>   80: 2700776    82: 2700364    84: 2702674    86: 2700255
>>   88: 2699886    90: 2700359    92: 2699662    94: 2696188
>>   96: 2705454    98: 2699260   100: 2701097   102: 2699630
>> 104: 2700463   106: 2698408   108: 2697766   110: 2701181
>> 112: 2699166   114: 2701804   116: 2701907   118: 2701973
>> 120: 2699584   122: 2700474   124: 2700768   126: 2701963
>>
>> Signed-off-by: Huisong Li <lihuisong at huawei.com>
> First off, please Cc ACPI-related patches to linux-acpi.

got it.

+linux-acpi at vger.kernel.org

>
>> ---
>>   arch/arm64/kernel/topology.c | 43 ++++++++++++++++++++++++++++++++++--
>>   drivers/acpi/cppc_acpi.c     | 22 +++++++++++++++---
>>   include/acpi/cppc_acpi.h     |  5 +++++
>>   3 files changed, 65 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>> index 7d37e458e2f5..c3122154d738 100644
>> --- a/arch/arm64/kernel/topology.c
>> +++ b/arch/arm64/kernel/topology.c
>> @@ -299,6 +299,11 @@ core_initcall(init_amu_fie);
>>   #ifdef CONFIG_ACPI_CPPC_LIB
>>   #include <acpi/cppc_acpi.h>
>>
>> +struct amu_counters {
>> +       u64 corecnt;
>> +       u64 constcnt;
>> +};
>> +
>>   static void cpu_read_corecnt(void *val)
>>   {
>>          /*
>> @@ -322,8 +327,27 @@ static void cpu_read_constcnt(void *val)
>>                        0UL : read_constcnt();
>>   }
>>
>> +static void cpu_read_amu_counters(void *data)
>> +{
>> +       struct amu_counters *cnt = (struct amu_counters *)data;
>> +
>> +       /*
>> +        * The running time of the this_cpu_has_cap() might have a couple of
>> +        * microseconds and is significantly increased to tens of microseconds.
>> +        * But AMU core and constant counter need to be read togeter without any
>> +        * time interval to reduce the calculation discrepancy using this counters.
>> +        */
>> +       if (this_cpu_has_cap(ARM64_WORKAROUND_2457168)) {
>> +               cnt->corecnt = read_corecnt();
> This statement is present in both branches, so can it be moved before the if ()?
Yes.
Do you mean adding a blank line before if()?
>
>> +               cnt->constcnt = 0;
>> +       } else {
>> +               cnt->corecnt = read_corecnt();
>> +               cnt->constcnt = read_constcnt();
>> +       }
>> +}
>> +
>>   static inline
>> -int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
>> +int counters_read_on_cpu(int cpu, smp_call_func_t func, void *data)
>>   {
>>          /*
>>           * Abort call on counterless CPU or when interrupts are
>> @@ -335,7 +359,7 @@ int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
>>          if (WARN_ON_ONCE(irqs_disabled()))
>>                  return -EPERM;
>>
>> -       smp_call_function_single(cpu, func, val, 1);
>> +       smp_call_function_single(cpu, func, data, 1);
>>
>>          return 0;
>>   }
>> @@ -364,6 +388,21 @@ bool cpc_ffh_supported(void)
>>          return true;
>>   }
>>
>> +int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference)
>> +{
>> +       struct amu_counters cnts = {0};
>> +       int ret;
>> +
>> +       ret = counters_read_on_cpu(cpu, cpu_read_amu_counters, &cnts);
>> +       if (ret)
>> +               return ret;
>> +
>> +       *delivered = cnts.corecnt;
>> +       *reference = cnts.constcnt;
>> +
>> +       return 0;
>> +}
>> +
>>   int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64 *val)
>>   {
>>          int ret = -EOPNOTSUPP;
>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
>> index 7ff269a78c20..f303fabd7cfe 100644
>> --- a/drivers/acpi/cppc_acpi.c
>> +++ b/drivers/acpi/cppc_acpi.c
>> @@ -1299,6 +1299,11 @@ bool cppc_perf_ctrs_in_pcc(void)
>>   }
>>   EXPORT_SYMBOL_GPL(cppc_perf_ctrs_in_pcc);
>>
>> +int __weak cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference)
>> +{
>> +       return 0;
>> +}
>> +
>>   /**
>>    * cppc_get_perf_ctrs - Read a CPU's performance feedback counters.
>>    * @cpunum: CPU from which to read counters.
>> @@ -1313,7 +1318,8 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
>>                  *ref_perf_reg, *ctr_wrap_reg;
>>          int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpunum);
>>          struct cppc_pcc_data *pcc_ss_data = NULL;
>> -       u64 delivered, reference, ref_perf, ctr_wrap_time;
>> +       u64 delivered = 0, reference = 0;
>> +       u64 ref_perf, ctr_wrap_time;
>>          int ret = 0, regs_in_pcc = 0;
>>
>>          if (!cpc_desc) {
>> @@ -1350,8 +1356,18 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
>>                  }
>>          }
>>
>> -       cpc_read(cpunum, delivered_reg, &delivered);
>> -       cpc_read(cpunum, reference_reg, &reference);
>> +       if (cpc_ffh_supported()) {
>> +               ret = cpc_read_arch_counters_on_cpu(cpunum, &delivered, &reference);
>> +               if (ret) {
>> +                       pr_debug("read arch counters failed, ret=%d.\n", ret);
>> +                       ret = 0;
>> +               }
>> +       }
> The above is surely not applicable to every platform using CPPC.  Also

cpc_ffh_supported is aimed to control only the platform supported FFH to enter.
cpc_read_arch_counters_on_cpu is also needed to implemented by each platform according to their require.
Here just implement this interface for arm64.

> it looks like in the ARM64_WORKAROUND_2457168 enabled case it is just
> pointless overhead, because "reference" is always going to be 0 here
> then.
Right, it is always going to be 0 here for the ARM64_WORKAROUND_2457168 
enabled case .
But ARM64_WORKAROUND_2457168 is a macro releated to ARM.
It seems that it is not appropriate for this macro to appear this common 
place for all platform, right?

>
> Please clean that up.
>
>> +       if (!delivered || !reference) {
>> +               cpc_read(cpunum, delivered_reg, &delivered);
>> +               cpc_read(cpunum, reference_reg, &reference);
>> +       }
>> +
>>          cpc_read(cpunum, ref_perf_reg, &ref_perf);
>>
>>          /*
>> diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
>> index 6126c977ece0..07d4fd82d499 100644
>> --- a/include/acpi/cppc_acpi.h
>> +++ b/include/acpi/cppc_acpi.h
>> @@ -152,6 +152,7 @@ extern bool cpc_ffh_supported(void);
>>   extern bool cpc_supported_by_cpu(void);
>>   extern int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val);
>>   extern int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val);
>> +extern int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference);
>>   extern int cppc_get_epp_perf(int cpunum, u64 *epp_perf);
>>   extern int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable);
>>   extern int cppc_get_auto_sel_caps(int cpunum, struct cppc_perf_caps *perf_caps);
>> @@ -209,6 +210,10 @@ static inline int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val)
>>   {
>>          return -ENOTSUPP;
>>   }
>> +static inline int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 *reference)
>> +{
>> +       return -EOPNOTSUPP;
>> +}
>>   static inline int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable)
>>   {
>>          return -ENOTSUPP;
>> --
> .


From ck.hu at mediatek.com  Thu Dec 14 18:47:25 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Fri, 15 Dec 2023 02:47:25 +0000
Subject: [PATCH 2/2] mailbox: mtk-cmdq: Add CMDQ driver support for mt8188
In-Reply-To: <20231215023546.6594-3-jason-jh.lin@mediatek.com>
References: <20231215023546.6594-1-jason-jh.lin@mediatek.com>
	 <20231215023546.6594-3-jason-jh.lin@mediatek.com>
Message-ID: <e2952f5296d57ded1a18a0313bd44412c8e5f6b6.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-15 at 10:35 +0800, Jason-JH.Lin wrote:
> Add CMDQ driver support for mt8188 by adding its compatible and
> driver data in CMDQ driver.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  drivers/mailbox/mtk-cmdq-mailbox.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 76e5f762628c..612b9feb258a 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -749,11 +749,19 @@ static const struct gce_plat gce_plat_v7 = {
>  	.gce_num = 1
>  };
>  
> +static const struct gce_plat gce_plat_v8 = {
> +	.thread_nr = 32,
> +	.shift = 3,
> +	.control_by_sw = true,
> +	.gce_num = 2
> +};
> +
>  static const struct of_device_id cmdq_of_ids[] = {
>  	{.compatible = "mediatek,mt6779-gce", .data = (void
> *)&gce_plat_v4},
>  	{.compatible = "mediatek,mt8173-gce", .data = (void
> *)&gce_plat_v2},
>  	{.compatible = "mediatek,mt8183-gce", .data = (void
> *)&gce_plat_v3},
>  	{.compatible = "mediatek,mt8186-gce", .data = (void
> *)&gce_plat_v7},
> +	{.compatible = "mediatek,mt8188-gce", .data = (void
> *)&gce_plat_v8},

I think 'v8' is not trivial for anyone. Every SoC has each setting, so
I would like the name to directly show the SoC name, such as
'gce_plat_mt8188'. So does other SoC.

Regards,
CK

>  	{.compatible = "mediatek,mt8192-gce", .data = (void
> *)&gce_plat_v5},
>  	{.compatible = "mediatek,mt8195-gce", .data = (void
> *)&gce_plat_v6},
>  	{}

From thiago.bauermann at linaro.org  Thu Dec 14 18:50:11 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Thu, 14 Dec 2023 23:50:11 -0300
Subject: [PATCH v7 34/39] kselftest/arm64: Add a GCS test program built
 with the system libc
In-Reply-To: <20231122-arm64-gcs-v7-34-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-34-201c483bd775@kernel.org>
Message-ID: <875y1089i4.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

> +	/* Same thing via process_vm_readv() */
> +	local_iov.iov_base = &rval;
> +	local_iov.iov_len = sizeof(rval);
> +	remote_iov.iov_base = (void *)gcspr;
> +	remote_iov.iov_len = sizeof(rval);
> +	ret = process_vm_writev(child, &local_iov, 1, &remote_iov, 1, 0);
> +	if (ret == -1)
> +		ksft_print_msg("process_vm_readv() failed: %s (%d)\n",
> +			       strerror(errno), errno);

The comment and the error message say "process_vm_readv()", but the
function actually called is process_vm_writev(). Is this intended?

Also, process_vm_writev() is failing when I run on my Arm FVP:

# #  RUN           global.ptrace_read_write ...
# # Child: 1150
# # Child GCSPR 0xffffa210ffd8, flags 1, locked 0
# # process_vm_readv() failed: Bad address (14)
# # libc-gcs.c:271:ptrace_read_write:Expected ret (-1) == sizeof(rval) (8)
# # libc-gcs.c:272:ptrace_read_write:Expected val (281473401005692) == rval (281473402849248)
# # libc-gcs.c:293:ptrace_read_write:Expected val (281473401005692) == ptrace(PTRACE_PEEKDATA, child, (void *)gcspr, NULL) (0)
# # ptrace_read_write: Test failed at step #1
# #          FAIL  global.ptrace_read_write
# not ok 4 global.ptrace_read_write

If I swap process_vm_readv() and process_vm_writev(), then the read
succeeds but the write fails:

#  RUN           global.ptrace_read_write ...
# Child: 1996
# Child GCSPR 0xffffa7fcffd8, flags 1, locked 0
# process_vm_writev() failed: Bad address (14)
# libc-gcs.c:291:ptrace_read_write:Expected ret (-1) == sizeof(rval) (8)
# libc-gcs.c:293:ptrace_read_write:Expected val (281473500358268) == ptrace(PTRACE_PEEKDATA, child, (void *)gcspr, NULL) (0)
# ptrace_read_write: Test failed at step #1
#          FAIL  global.ptrace_read_write
not ok 4 global.ptrace_read_write

> +/* Put it all together, we can safely switch to and from the stack */
> +TEST_F(map_gcs, stack_switch)
> +{
> +	size_t cap_index;
> +	cap_index = (variant->stack_size / sizeof(unsigned long));
> +	unsigned long *orig_gcspr_el0, *pivot_gcspr_el0;
> +
> +	/* Skip over the stack terminator and point at the cap */
> + switch (variant->flags & (SHADOW_STACK_SET_MARKER | SHADOW_STACK_SET_TOKEN)) {
> +	case SHADOW_STACK_SET_MARKER | SHADOW_STACK_SET_TOKEN:
> +		cap_index -= 2;
> +		break;
> +	case SHADOW_STACK_SET_TOKEN:
> +		cap_index -= 1;
> +		break;
> +	case SHADOW_STACK_SET_MARKER:
> +	case 0:
> +		/* No cap, no test */
> +		return;
> +	}
> +	pivot_gcspr_el0 = &self->stack[cap_index];
> +
> +	/* Pivot to the new GCS */
> +	ksft_print_msg("Pivoting to %p from %p, target has value 0x%lx\n",
> +		       pivot_gcspr_el0, get_gcspr(),
> +		       *pivot_gcspr_el0);
> +	gcsss1(pivot_gcspr_el0);
> +	orig_gcspr_el0 = gcsss2();
> +	ksft_print_msg("Pivoted to %p from %p, target has value 0x%lx\n",
> +		       pivot_gcspr_el0, get_gcspr(),

Not sure about the intent here, but perhaps "get_gcspr()" here should be
"orig_gcspr_el0" instead? Ditto in the equivalent place at the
map_gcs.stack_overflow test below.

Also, it's strange that the tests defined after map_gcs.stack_overflow
don't run when I execute this test program. I'm doing:

$ ./run_kselftest.sh -t arm64:libc-gcs

I.e., these tests aren't being run in my FVP:

> +FIXTURE_VARIANT_ADD(map_invalid_gcs, too_small)
> +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_1)
> +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_2)
> +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_3)
> +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_4)
> +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_5)
> +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_6)
> +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_7)
> +TEST_F(map_invalid_gcs, do_map)
> +FIXTURE_VARIANT_ADD(invalid_mprotect, exec)
> +FIXTURE_VARIANT_ADD(invalid_mprotect, bti)
> +FIXTURE_VARIANT_ADD(invalid_mprotect, exec_bti)
> +TEST_F(invalid_mprotect, do_map)
> +TEST_F(invalid_mprotect, do_map_read)

Finally, one last comment:

> +int main(int argc, char **argv)
> +{
> +	unsigned long gcs_mode;
> +	int ret;
> +
> +	if (!(getauxval(AT_HWCAP2) & HWCAP2_GCS))
> +		ksft_exit_skip("SKIP GCS not supported\n");
> +
> +	/* 
> +	 * Force shadow stacks on, our tests *should* be fine with or
> +	 * without libc support and with or without this having ended
> +	 * up tagged for GCS and enabled by the dynamic linker.  We
> +	 * can't use the libc prctl() function since we can't return
> +	 * from enabling the stack.  Also lock GCS if not already
> +	 * locked so we can test behaviour when it's locked.

This is probably a leftover from a previous version: the test doesn't
lock any GCS flag.

> +	 */
> +	ret = my_syscall2(__NR_prctl, PR_GET_SHADOW_STACK_STATUS, &gcs_mode);
> +	if (ret) {
> +		ksft_print_msg("Failed to read GCS state: %d\n", ret);
> +		return EXIT_FAILURE;
> +	}
> +	
> +	if (!(gcs_mode & PR_SHADOW_STACK_ENABLE)) {
> +		gcs_mode = PR_SHADOW_STACK_ENABLE;
> +		ret = my_syscall2(__NR_prctl, PR_SET_SHADOW_STACK_STATUS,
> +				  gcs_mode);
> +		if (ret) {
> +			ksft_print_msg("Failed to configure GCS: %d\n", ret);
> +			return EXIT_FAILURE;
> +		}
> +	}
> +
> +	/* Avoid returning in case libc doesn't understand GCS */
> +	exit(test_harness_run(argc, argv));
> +}


-- 
Thiago


From ck.hu at mediatek.com  Thu Dec 14 18:47:58 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Fri, 15 Dec 2023 02:47:58 +0000
Subject: [PATCH 1/2] mailbox: mtk-cmdq: Sort cmdq platform data by
 compatible name
In-Reply-To: <20231215023546.6594-2-jason-jh.lin@mediatek.com>
References: <20231215023546.6594-1-jason-jh.lin@mediatek.com>
	 <20231215023546.6594-2-jason-jh.lin@mediatek.com>
Message-ID: <8c66d825d771392718e4acda37ce59a438a4cea8.camel@mediatek.com>

On Fri, 2023-12-15 at 10:35 +0800, Jason-JH.Lin wrote:
> Sort cmdq platform data according to the number sequence of
> compatible names.

Reviewed-by: CK Hu <ck.hu at mediatek.com>

> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  drivers/mailbox/mtk-cmdq-mailbox.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index de862e9137d5..76e5f762628c 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -750,10 +750,10 @@ static const struct gce_plat gce_plat_v7 = {
>  };
>  
>  static const struct of_device_id cmdq_of_ids[] = {
> +	{.compatible = "mediatek,mt6779-gce", .data = (void
> *)&gce_plat_v4},
>  	{.compatible = "mediatek,mt8173-gce", .data = (void
> *)&gce_plat_v2},
>  	{.compatible = "mediatek,mt8183-gce", .data = (void
> *)&gce_plat_v3},
>  	{.compatible = "mediatek,mt8186-gce", .data = (void
> *)&gce_plat_v7},
> -	{.compatible = "mediatek,mt6779-gce", .data = (void
> *)&gce_plat_v4},
>  	{.compatible = "mediatek,mt8192-gce", .data = (void
> *)&gce_plat_v5},
>  	{.compatible = "mediatek,mt8195-gce", .data = (void
> *)&gce_plat_v6},
>  	{}

From Jason-JH.Lin at mediatek.com  Thu Dec 14 19:06:53 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Fri, 15 Dec 2023 03:06:53 +0000
Subject: [PATCH 2/2] mailbox: mtk-cmdq: Add CMDQ driver support for mt8188
In-Reply-To: <e2952f5296d57ded1a18a0313bd44412c8e5f6b6.camel@mediatek.com>
References: <20231215023546.6594-1-jason-jh.lin@mediatek.com>
	 <20231215023546.6594-3-jason-jh.lin@mediatek.com>
	 <e2952f5296d57ded1a18a0313bd44412c8e5f6b6.camel@mediatek.com>
Message-ID: <270eb954c25433da1ae24d2ce219f195e628fdf3.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Fri, 2023-12-15 at 02:47 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Fri, 2023-12-15 at 10:35 +0800, Jason-JH.Lin wrote:
> > Add CMDQ driver support for mt8188 by adding its compatible and
> > driver data in CMDQ driver.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> >  drivers/mailbox/mtk-cmdq-mailbox.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> > b/drivers/mailbox/mtk-cmdq-mailbox.c
> > index 76e5f762628c..612b9feb258a 100644
> > --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> > @@ -749,11 +749,19 @@ static const struct gce_plat gce_plat_v7 = {
> >  	.gce_num = 1
> >  };
> >  
> > +static const struct gce_plat gce_plat_v8 = {
> > +	.thread_nr = 32,
> > +	.shift = 3,
> > +	.control_by_sw = true,
> > +	.gce_num = 2
> > +};
> > +
> >  static const struct of_device_id cmdq_of_ids[] = {
> >  	{.compatible = "mediatek,mt6779-gce", .data = (void
> > *)&gce_plat_v4},
> >  	{.compatible = "mediatek,mt8173-gce", .data = (void
> > *)&gce_plat_v2},
> >  	{.compatible = "mediatek,mt8183-gce", .data = (void
> > *)&gce_plat_v3},
> >  	{.compatible = "mediatek,mt8186-gce", .data = (void
> > *)&gce_plat_v7},
> > +	{.compatible = "mediatek,mt8188-gce", .data = (void
> > *)&gce_plat_v8},
> 
> I think 'v8' is not trivial for anyone. Every SoC has each setting,
> so
> I would like the name to directly show the SoC name, such as
> 'gce_plat_mt8188'. So does other SoC.
> 

OK, I'll add a patch to modify gce_plat postfix from 'v1~v7' to the SoC
names. Then add 'gce_plat_mt8188' for mt8188.

Regards,
Jason-JH.Lin

> Regards,
> CK
> 
> >  	{.compatible = "mediatek,mt8192-gce", .data = (void
> > *)&gce_plat_v5},
> >  	{.compatible = "mediatek,mt8195-gce", .data = (void
> > *)&gce_plat_v6},
> >  	{}

From muchun.song at linux.dev  Thu Dec 14 19:36:05 2023
From: muchun.song at linux.dev (Muchun Song)
Date: Fri, 15 Dec 2023 11:36:05 +0800
Subject: [PATCH 1/3] mm: HVO: introduce helper function to update and
 flush pgtable
In-Reply-To: <20231214073912.1938330-2-sunnanyong@huawei.com>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
 <20231214073912.1938330-2-sunnanyong@huawei.com>
Message-ID: <0100b6c8-24db-fbcf-d45e-763cfccfa0c5@linux.dev>



On 2023/12/14 15:39, Nanyong Sun wrote:
> Add pmd/pte update and tlb flush helper function to update page
> table. This refactoring patch is designed to facilitate each
> architecture to implement its own special logic in preparation
> for the arm64 architecture to follow the necessary break-before-make
> sequence when updating page tables.
>
> Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
> ---
>   mm/hugetlb_vmemmap.c | 55 ++++++++++++++++++++++++++++++++++----------
>   1 file changed, 43 insertions(+), 12 deletions(-)
>
> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index 87818ee7f01d..49e8b351def3 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
> @@ -45,6 +45,37 @@ struct vmemmap_remap_walk {
>   	unsigned long		flags;
>   };
>   
> +#ifndef vmemmap_update_pmd
> +static inline void vmemmap_update_pmd(unsigned long start,
> +				      pmd_t *pmd, pte_t *pgtable)
> +{
> +	pmd_populate_kernel(&init_mm, pmd, pgtable);
> +}
> +#endif
> +
> +#ifndef vmemmap_update_pte
> +static inline void vmemmap_update_pte(unsigned long addr,
> +				      pte_t *pte, pte_t entry)
> +{
> +	set_pte_at(&init_mm, addr, pte, entry);
> +}
> +#endif
> +
> +#ifndef flush_tlb_vmemmap_all
> +static inline void flush_tlb_vmemmap_all(void)
> +{
> +	flush_tlb_all();
> +}
> +#endif
> +
> +#ifndef flush_tlb_vmemmap_range
> +static inline void flush_tlb_vmemmap_range(unsigned long start,
> +					   unsigned long end)
> +{
> +	flush_tlb_kernel_range(start, end);
> +}
> +#endif

I'd like to rename both tlb-flush helpers to vmemmap_flush_tlb_all/range
since other helpers all are prefixed with "vmemmap". It'll be more
consistent for me.

Otherwise LGTM. Thanks.

Reviewed-by: Muchun Song <songmuchun at bytedance.com>

> +
>   static int split_vmemmap_huge_pmd(pmd_t *pmd, unsigned long start, bool flush)
>   {
>   	pmd_t __pmd;
> @@ -87,9 +118,9 @@ static int split_vmemmap_huge_pmd(pmd_t *pmd, unsigned long start, bool flush)
>   
>   		/* Make pte visible before pmd. See comment in pmd_install(). */
>   		smp_wmb();
> -		pmd_populate_kernel(&init_mm, pmd, pgtable);
> +		vmemmap_update_pmd(start, pmd, pgtable);
>   		if (flush)
> -			flush_tlb_kernel_range(start, start + PMD_SIZE);
> +			flush_tlb_vmemmap_range(start, start + PMD_SIZE);
>   	} else {
>   		pte_free_kernel(&init_mm, pgtable);
>   	}
> @@ -217,7 +248,7 @@ static int vmemmap_remap_range(unsigned long start, unsigned long end,
>   	} while (pgd++, addr = next, addr != end);
>   
>   	if (walk->remap_pte && !(walk->flags & VMEMMAP_REMAP_NO_TLB_FLUSH))
> -		flush_tlb_kernel_range(start, end);
> +		flush_tlb_vmemmap_range(start, end);
>   
>   	return 0;
>   }
> @@ -263,15 +294,15 @@ static void vmemmap_remap_pte(pte_t *pte, unsigned long addr,
>   
>   		/*
>   		 * Makes sure that preceding stores to the page contents from
> -		 * vmemmap_remap_free() become visible before the set_pte_at()
> -		 * write.
> +		 * vmemmap_remap_free() become visible before the
> +		 * vmemmap_update_pte() write.
>   		 */
>   		smp_wmb();
>   	}
>   
>   	entry = mk_pte(walk->reuse_page, pgprot);
>   	list_add(&page->lru, walk->vmemmap_pages);
> -	set_pte_at(&init_mm, addr, pte, entry);
> +	vmemmap_update_pte(addr, pte, entry);
>   }
>   
>   /*
> @@ -310,10 +341,10 @@ static void vmemmap_restore_pte(pte_t *pte, unsigned long addr,
>   
>   	/*
>   	 * Makes sure that preceding stores to the page contents become visible
> -	 * before the set_pte_at() write.
> +	 * before the vmemmap_update_pte() write.
>   	 */
>   	smp_wmb();
> -	set_pte_at(&init_mm, addr, pte, mk_pte(page, pgprot));
> +	vmemmap_update_pte(addr, pte, mk_pte(page, pgprot));
>   }
>   
>   /**
> @@ -576,7 +607,7 @@ long hugetlb_vmemmap_restore_folios(const struct hstate *h,
>   	}
>   
>   	if (restored)
> -		flush_tlb_all();
> +		flush_tlb_vmemmap_all();
>   	if (!ret)
>   		ret = restored;
>   	return ret;
> @@ -744,7 +775,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
>   			break;
>   	}
>   
> -	flush_tlb_all();
> +	flush_tlb_vmemmap_all();
>   
>   	list_for_each_entry(folio, folio_list, lru) {
>   		int ret = __hugetlb_vmemmap_optimize_folio(h, folio,
> @@ -760,7 +791,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
>   		 * allowing more vmemmap remaps to occur.
>   		 */
>   		if (ret == -ENOMEM && !list_empty(&vmemmap_pages)) {
> -			flush_tlb_all();
> +			flush_tlb_vmemmap_all();
>   			free_vmemmap_page_list(&vmemmap_pages);
>   			INIT_LIST_HEAD(&vmemmap_pages);
>   			__hugetlb_vmemmap_optimize_folio(h, folio,
> @@ -769,7 +800,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
>   		}
>   	}
>   
> -	flush_tlb_all();
> +	flush_tlb_vmemmap_all();
>   	free_vmemmap_page_list(&vmemmap_pages);
>   }
>   



From n-francis at ti.com  Thu Dec 14 20:35:18 2023
From: n-francis at ti.com (Neha Malcom Francis)
Date: Fri, 15 Dec 2023 10:05:18 +0530
Subject: [PATCH] arm64: dts: ti: k3-j721e: Add support for DFS in J721E
 A72
In-Reply-To: <20231214125130.zqtq6ioj4c533wha@elbow>
References: <20231214075637.176586-1-n-francis@ti.com>
 <20231214125130.zqtq6ioj4c533wha@elbow>
Message-ID: <babed3d7-0daf-4aa0-8bab-627d585ca224@ti.com>

Hi Nishanth

On 14/12/23 18:21, Nishanth Menon wrote:
> On 13:26-20231214, Neha Malcom Francis wrote:
>> Add 2G, 1.5G, 1G, 750M, 500M and 250M as the supported frequencies for
>> A72. This enables support for Dynamic Frequency Scaling (DFS).
>>
> 
> Just curious, since I picked up the PMIC support... can we do dvfs? if
> not, please indicate that in the commit message.
> 

DVFS is not supported on J7 devices, I'll mention that in v2.

>> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
>> ---
>> Boot logs:
>> https://gist.github.com/nehamalcom/e3c3d0446f0467e7fd28706f7ffaeea8
>>
>> J721E SoC has three different speed grade devices (see [1], 7.5
>> Operating Performance Points) which as of today are indiscernible in
>> software, users of a different speed grade device must manually change
>> the DTS to ensure their maximum speed frequency is supported.
>>
>> [1] https://www.ti.com/lit/gpn/tda4vm
> This is critical info in the commit message and in documentation of
> source.
> 

Will put that in the commit message.

> I am also concerned if the table should be separated out as a dtsi and
> included at board.dts level to prevent downstream users going crazy..
> 

Hm... could you elaborate on that more? I don't understand the reasoning of 
including this at a board level for a SoC problem.

> Are you absolutely sure this has no detection logic that can be
> implemented? Almost all TI K3 SoCs seem to have a standard scheme to
> detect the speed grades till date. /me wonders what the heck happened
> here..
> 

Going through the reference manual and data sheet I didn't find anything that 
could differentiate between speed grades, this was confirmed for J7200, I'll do 
the needful to confirm this for J721E as well before v2.

>>
>>   arch/arm64/boot/dts/ti/k3-j721e.dtsi | 35 ++++++++++++++++++++++++++++
>>   1 file changed, 35 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j721e.dtsi b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
>> index a200810df54a..fe92879f5812 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j721e.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
>> @@ -48,6 +48,9 @@ cpu0: cpu at 0 {
>>   			d-cache-line-size = <64>;
>>   			d-cache-sets = <256>;
>>   			next-level-cache = <&L2_0>;
>> +			clocks = <&k3_clks 202 2>;
>> +			clock-names = "cpu";
>> +			operating-points-v2 = <&cpu0_opp_table>;
>>   		};
>>   
>>   		cpu1: cpu at 1 {
>> @@ -62,9 +65,41 @@ cpu1: cpu at 1 {
>>   			d-cache-line-size = <64>;
>>   			d-cache-sets = <256>;
>>   			next-level-cache = <&L2_0>;
>> +			clocks = <&k3_clks 203 0>;
>> +			clock-names = "cpu";
>> +			operating-points-v2 = <&cpu0_opp_table>;
>>   		};
>>   	};
>>   
>> +	cpu0_opp_table: opp-table {
>> +		compatible = "operating-points-v2";
> Don't you need opp-shared ?

opp-shared would imply that the CPUs switch DFS states together... is that 
something we want?

>> +
>> +		opp6-2000000000 {
>> +			opp-hz = /bits/ 64 <2000000000>;
>> +		};
>> +
>> +		opp5-1500000000 {
>> +			opp-hz = /bits/ 64 <1500000000>;
>> +		};
>> +
>> +		opp4-1000000000 {
>> +			opp-hz = /bits/ 64 <1000000000>;
>> +		};
>> +
>> +		opp3-750000000 {
>> +			opp-hz = /bits/ 64 <750000000>;
>> +		};
>> +
>> +		opp2-500000000 {
>> +			opp-hz = /bits/ 64 <500000000>;
>> +		};
>> +
>> +		opp1-250000000 {
>> +			opp-hz = /bits/ 64 <250000000>;
> Could you add clock-latency-ns ?

Will add in v2.

>> +		};
>> +
>> +	};
>> +
>>   	L2_0: l2-cache0 {
>>   		compatible = "cache";
>>   		cache-level = <2>;
>> -- 
>> 2.34.1
>>
> 
> 

Thanks for reviewing!

-- 
Thanking You
Neha Malcom Francis


From apopple at nvidia.com  Thu Dec 14 20:32:22 2023
From: apopple at nvidia.com (Alistair Popple)
Date: Fri, 15 Dec 2023 15:32:22 +1100
Subject: [PATCH v3 14/15] arm64/mm: Implement ptep_set_wrprotects() to
 optimize fork()
In-Reply-To: <ecf129dd-000f-45be-95dc-1e8dad5a8c12@arm.com>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-15-ryan.roberts@arm.com>
 <87cyvha2xd.fsf@nvdebian.thelocal>
 <ecf129dd-000f-45be-95dc-1e8dad5a8c12@arm.com>
Message-ID: <87fs0413rx.fsf@nvdebian.thelocal>


Ryan Roberts <ryan.roberts at arm.com> writes:

> On 08/12/2023 01:37, Alistair Popple wrote:
>> 
>> Ryan Roberts <ryan.roberts at arm.com> writes:
>> 
>>> With the core-mm changes in place to batch-copy ptes during fork, we can
>>> take advantage of this in arm64 to greatly reduce the number of tlbis we
>>> have to issue, and recover the lost fork performance incured when adding
>>> support for transparent contiguous ptes.
>>>
>>> If we are write-protecting a whole contig range, we can apply the
>>> write-protection to the whole range and know that it won't change
>>> whether the range should have the contiguous bit set or not. For ranges
>>> smaller than the contig range, we will still have to unfold, apply the
>>> write-protection, then fold if the change now means the range is
>>> foldable.
>>>
>>> This optimization is possible thanks to the tightening of the Arm ARM in
>>> respect to the definition and behaviour when 'Misprogramming the
>>> Contiguous bit'. See section D21194 at
>>> https://developer.arm.com/documentation/102105/latest/
>>>
>>> Performance tested with the following test written for the will-it-scale
>>> framework:
>>>
>>> -------
>>>
>>> char *testcase_description = "fork and exit";
>>>
>>> void testcase(unsigned long long *iterations, unsigned long nr)
>>> {
>>> 	int pid;
>>> 	char *mem;
>>>
>>> 	mem = malloc(SZ_128M);
>>> 	assert(mem);
>>> 	memset(mem, 1, SZ_128M);
>>>
>>> 	while (1) {
>>> 		pid = fork();
>>> 		assert(pid >= 0);
>>>
>>> 		if (!pid)
>>> 			exit(0);
>>>
>>> 		waitpid(pid, NULL, 0);
>>>
>>> 		(*iterations)++;
>>> 	}
>>> }
>>>
>>> -------
>>>
>>> I see huge performance regression when PTE_CONT support was added, then
>>> the regression is mostly fixed with the addition of this change. The
>>> following shows regression relative to before PTE_CONT was enabled
>>> (bigger negative value is bigger regression):
>>>
>>> |   cpus |   before opt |   after opt |
>>> |-------:|-------------:|------------:|
>>> |      1 |       -10.4% |       -5.2% |
>>> |      8 |       -15.4% |       -3.5% |
>>> |     16 |       -38.7% |       -3.7% |
>>> |     24 |       -57.0% |       -4.4% |
>>> |     32 |       -65.8% |       -5.4% |
>>>
>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>> ---
>>>  arch/arm64/include/asm/pgtable.h | 30 ++++++++++++++++++++---
>>>  arch/arm64/mm/contpte.c          | 42 ++++++++++++++++++++++++++++++++
>>>  2 files changed, 69 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>> index 15bc9cf1eef4..9bd2f57a9e11 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -984,6 +984,16 @@ static inline void __ptep_set_wrprotect(struct mm_struct *mm,
>>>  	} while (pte_val(pte) != pte_val(old_pte));
>>>  }
>>>  
>>> +static inline void __ptep_set_wrprotects(struct mm_struct *mm,
>>> +					unsigned long address, pte_t *ptep,
>>> +					unsigned int nr)
>>> +{
>>> +	unsigned int i;
>>> +
>>> +	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
>>> +		__ptep_set_wrprotect(mm, address, ptep);
>>> +}
>>> +
>>>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>  #define __HAVE_ARCH_PMDP_SET_WRPROTECT
>>>  static inline void pmdp_set_wrprotect(struct mm_struct *mm,
>>> @@ -1139,6 +1149,8 @@ extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>>  				unsigned long addr, pte_t *ptep);
>>>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>>>  				unsigned long addr, pte_t *ptep);
>>> +extern void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
>>> +				pte_t *ptep, unsigned int nr);
>>>  extern int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
>>>  				unsigned long addr, pte_t *ptep,
>>>  				pte_t entry, int dirty);
>>> @@ -1290,13 +1302,25 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
>>>  	return contpte_ptep_clear_flush_young(vma, addr, ptep);
>>>  }
>>>  
>>> +#define ptep_set_wrprotects ptep_set_wrprotects
>>> +static inline void ptep_set_wrprotects(struct mm_struct *mm, unsigned long addr,
>>> +				pte_t *ptep, unsigned int nr)
>>> +{
>>> +	if (!contpte_is_enabled(mm))
>>> +		__ptep_set_wrprotects(mm, addr, ptep, nr);
>>> +	else if (nr == 1) {
>> 
>> Why do we need the special case here? Couldn't we just call
>> contpte_set_wrprotects() with nr == 1?
>
> My intention is for this to be a fast path for ptep_set_wrprotect(). I'm having
> to work hard to prevent regressing the order-0 folios case.

This ends up calling three functions anyway so I'm curious - does
removing the one function call really make that much of difference?

Either way I think a comment justifying the special case (ie. that this
is simply a fast path for nr == 1) would be good.

Thanks.

>> 
>>> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>>> +		__ptep_set_wrprotects(mm, addr, ptep, 1);
>>> +		contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
>>> +	} else
>>> +		contpte_set_wrprotects(mm, addr, ptep, nr);
>>> +}
>>> +
>>>  #define __HAVE_ARCH_PTEP_SET_WRPROTECT
>>>  static inline void ptep_set_wrprotect(struct mm_struct *mm,
>>>  				unsigned long addr, pte_t *ptep)
>>>  {
>>> -	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>>> -	__ptep_set_wrprotect(mm, addr, ptep);
>>> -	contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
>>> +	ptep_set_wrprotects(mm, addr, ptep, 1);
>>>  }
>>>  
>>>  #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
>>> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
>>> index e079ec61d7d1..2a57df16bf58 100644
>>> --- a/arch/arm64/mm/contpte.c
>>> +++ b/arch/arm64/mm/contpte.c
>>> @@ -303,6 +303,48 @@ int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>>>  }
>>>  EXPORT_SYMBOL(contpte_ptep_clear_flush_young);
>>>  
>>> +void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
>>> +					pte_t *ptep, unsigned int nr)
>>> +{
>>> +	unsigned long next;
>>> +	unsigned long end = addr + (nr << PAGE_SHIFT);
>>> +
>>> +	do {
>>> +		next = pte_cont_addr_end(addr, end);
>>> +		nr = (next - addr) >> PAGE_SHIFT;
>>> +
>>> +		/*
>>> +		 * If wrprotecting an entire contig range, we can avoid
>>> +		 * unfolding. Just set wrprotect and wait for the later
>>> +		 * mmu_gather flush to invalidate the tlb. Until the flush, the
>>> +		 * page may or may not be wrprotected. After the flush, it is
>>> +		 * guarranteed wrprotected. If its a partial range though, we
>>> +		 * must unfold, because we can't have a case where CONT_PTE is
>>> +		 * set but wrprotect applies to a subset of the PTEs; this would
>>> +		 * cause it to continue to be unpredictable after the flush.
>>> +		 */
>>> +		if (nr != CONT_PTES)
>>> +			contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>>> +
>>> +		__ptep_set_wrprotects(mm, addr, ptep, nr);
>>> +
>>> +		addr = next;
>>> +		ptep += nr;
>>> +
>>> +		/*
>>> +		 * If applying to a partial contig range, the change could have
>>> +		 * made the range foldable. Use the last pte in the range we
>>> +		 * just set for comparison, since contpte_try_fold() only
>>> +		 * triggers when acting on the last pte in the contig range.
>>> +		 */
>>> +		if (nr != CONT_PTES)
>>> +			contpte_try_fold(mm, addr - PAGE_SIZE, ptep - 1,
>>> +					 __ptep_get(ptep - 1));
>>> +
>>> +	} while (addr != end);
>>> +}
>>> +EXPORT_SYMBOL(contpte_set_wrprotects);
>>> +
>>>  int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
>>>  					unsigned long addr, pte_t *ptep,
>>>  					pte_t entry, int dirty)
>> 



From muchun.song at linux.dev  Thu Dec 14 20:36:57 2023
From: muchun.song at linux.dev (Muchun Song)
Date: Fri, 15 Dec 2023 12:36:57 +0800
Subject: [PATCH 2/3] arm64: mm: HVO: support BBM of vmemmap pgtable safely
In-Reply-To: <20231214073912.1938330-3-sunnanyong@huawei.com>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
 <20231214073912.1938330-3-sunnanyong@huawei.com>
Message-ID: <50f082a8-b805-5d66-45f4-2af58e99a67f@linux.dev>



On 2023/12/14 15:39, Nanyong Sun wrote:
> Implement vmemmap_update_pmd and vmemmap_update_pte on arm64 to do
> BBM(break-before-make) logic when change the page table of vmemmap
> address, they will under the init_mm.page_table_lock.
> If a translation fault of vmemmap address concurrently happened after
> pte/pmd cleared, vmemmap page fault handler will acquire the
> init_mm.page_table_lock to wait for vmemmap update to complete,
> by then the virtual address is valid again, so PF can return and
> access can continue.
> In other case, do the traditional kernel fault.

Yes. BTW, we already use the same scheme to support arm64
in our internal production. So the whole approach LGTM.

> Implement flush_tlb_vmemmap_all and flush_tlb_vmemmap_range on arm64
> with nothing to do because tlb already flushed in every single BBM.
>
> Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
> ---
>   arch/arm64/include/asm/esr.h |  4 ++
>   arch/arm64/include/asm/mmu.h | 20 ++++++++
>   arch/arm64/mm/fault.c        | 94 ++++++++++++++++++++++++++++++++++++
>   arch/arm64/mm/mmu.c          | 28 +++++++++++
>   4 files changed, 146 insertions(+)
>
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index ae35939f395b..1c63256efd25 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -116,6 +116,10 @@
>   #define ESR_ELx_FSC_SERROR	(0x11)
>   #define ESR_ELx_FSC_ACCESS	(0x08)
>   #define ESR_ELx_FSC_FAULT	(0x04)
> +#define ESR_ELx_FSC_FAULT_L0    (0x04)
> +#define ESR_ELx_FSC_FAULT_L1    (0x05)
> +#define ESR_ELx_FSC_FAULT_L2    (0x06)
> +#define ESR_ELx_FSC_FAULT_L3    (0x07)
>   #define ESR_ELx_FSC_PERM	(0x0C)
>   #define ESR_ELx_FSC_SEA_TTW0	(0x14)
>   #define ESR_ELx_FSC_SEA_TTW1	(0x15)
> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
> index 2fcf51231d6e..fcec5827f54f 100644
> --- a/arch/arm64/include/asm/mmu.h
> +++ b/arch/arm64/include/asm/mmu.h
> @@ -76,5 +76,25 @@ extern bool kaslr_requires_kpti(void);
>   #define INIT_MM_CONTEXT(name)	\
>   	.pgd = init_pg_dir,
>   
> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
> +void vmemmap_update_pmd(unsigned long start, pmd_t *pmd, pte_t *pgtable);
> +#define vmemmap_update_pmd vmemmap_update_pmd
> +void vmemmap_update_pte(unsigned long addr, pte_t *pte, pte_t entry);
> +#define vmemmap_update_pte vmemmap_update_pte
> +
> +static inline void flush_tlb_vmemmap_all(void)
> +{
> +	/* do nothing, already flushed tlb in every single BBM */
> +}
> +#define flush_tlb_vmemmap_all flush_tlb_vmemmap_all
> +
> +static inline void flush_tlb_vmemmap_range(unsigned long start,
> +					   unsigned long end)
> +{
> +	/* do nothing, already flushed tlb in every single BBM */
> +}
> +#define flush_tlb_vmemmap_range flush_tlb_vmemmap_range
> +#endif
> +
>   #endif	/* !__ASSEMBLY__ */
>   #endif
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 460d799e1296..7066a273c1e0 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -368,6 +368,97 @@ static bool is_el1_mte_sync_tag_check_fault(unsigned long esr)
>   	return false;
>   }
>   
> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
> +static inline bool is_vmemmap_address(unsigned long addr)
> +{
> +	return (addr >= VMEMMAP_START) && (addr < VMEMMAP_END);
> +}
> +
> +static inline bool vmemmap_fault_may_fixup(unsigned long addr,
> +					   unsigned long esr)
> +{
> +	if (!is_vmemmap_address(addr))
> +		return false;
> +
> +	/*
> +	 * Only try to handle translation fault level 2 or level 3,
> +	 * because hugetlb vmemmap optimize only clear pmd or pte.
> +	 */
> +	switch (esr & ESR_ELx_FSC) {
> +	case ESR_ELx_FSC_FAULT_L2:
> +	case ESR_ELx_FSC_FAULT_L3:
> +		return true;
> +	default:
> +		return false;
> +	}
> +}
> +
> +/*
> + * PMD mapped vmemmap should has been split as PTE mapped
> + * by HVO now, here we only check this case, other cases
> + * should fail.
> + * Also should check the addr is healthy enough that will not cause
> + * a level2 or level3 translation fault again after page fault
> + * handled with success, so we need check both bits[1:0] of PMD and
> + * PTE as ARM Spec mentioned below:
> + * A Translation fault is generated if bits[1:0] of a translation
> + * table descriptor identify the descriptor as either a Fault
> + * encoding or a reserved encoding.
> + */
> +static inline bool vmemmap_addr_healthy(unsigned long addr)
> +{
> +	pgd_t *pgdp;
> +	p4d_t *p4dp;
> +	pud_t *pudp, pud;
> +	pmd_t *pmdp, pmd;
> +	pte_t *ptep, pte;
> +
> +	pgdp = pgd_offset_k(addr);
> +	if (pgd_none(READ_ONCE(*pgdp)))
> +		return false;
> +
> +	p4dp = p4d_offset(pgdp, addr);
> +	if (p4d_none(READ_ONCE(*p4dp)))
> +		return false;
> +
> +	pudp = pud_offset(p4dp, addr);
> +	pud = READ_ONCE(*pudp);
> +	if (pud_none(pud))
> +		return false;
> +
> +	pmdp = pmd_offset(pudp, addr);

We already make sure it is a translation fault of level 2 or 3
here, so we could use pmd_offset_k() macro to simplify the code
a little. Right?

> +	pmd = READ_ONCE(*pmdp);
> +	if (!pmd_table(pmd))
> +		return false;
> +
> +	ptep = pte_offset_kernel(pmdp, addr);
> +	pte = READ_ONCE(*ptep);

Please use ptep_get (which is supposed to do this) to access the
raw pte, see commit c33c794828f21217.

> +	return (pte_val(pte) & PTE_TYPE_MASK) == PTE_TYPE_PAGE;
> +}
> +
> +static bool vmemmap_handle_page_fault(unsigned long addr,
> +				      unsigned long esr)
> +{
> +	bool ret = false;
> +
> +	if (likely(!vmemmap_fault_may_fixup(addr, esr)))
> +		return false;
> +
> +	spin_lock(&init_mm.page_table_lock);
> +	if (vmemmap_addr_healthy(addr))
> +		ret = true;

It is to assign the return value to ret directly. Like:

 ??? ??? ret = vmemmap_addr_healthy(addr);

The the initializetion to ret also can be dropped.

> +	spin_unlock(&init_mm.page_table_lock);
> +
> +	return ret;
> +}
> +#else
> +static inline bool vmemmap_handle_page_fault(unsigned long addr,
> +					     unsigned long esr)
> +{
> +	return false;
> +}
> +#endif /*CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP */
 ????????? ^
Miss a blank between "*" and "C" here.

Thanks.

> +
>   static bool is_translation_fault(unsigned long esr)
>   {
>   	return (esr & ESR_ELx_FSC_TYPE) == ESR_ELx_FSC_FAULT;
> @@ -409,6 +500,9 @@ static void __do_kernel_fault(unsigned long addr, unsigned long esr,
>   		    kfence_handle_page_fault(addr, esr & ESR_ELx_WNR, regs))
>   			return;
>   
> +		if (vmemmap_handle_page_fault(addr, esr))
> +			return;
> +
>   		msg = "paging request";
>   	}
>   
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 15f6347d23b6..81a600ccac7c 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1146,6 +1146,34 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node,
>   	return 1;
>   }
>   
> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
> +/*
> + * In the window between the page table entry is cleared and filled
> + * with a new value, other threads have the opportunity to concurrently
> + * access the vmemmap area then page translation fault occur.
> + * Therefore, we need to ensure that the init_mm.page_table_lock is held
> + * to synchronize the vmemmap page fault handling which will wait for
> + * this lock to be released to ensure that the page table entry has been
> + * refreshed with a new valid value.
> + */
> +void vmemmap_update_pmd(unsigned long start, pmd_t *pmd, pte_t *pgtable)
> +{
> +	lockdep_assert_held(&init_mm.page_table_lock);
> +	pmd_clear(pmd);
> +	flush_tlb_kernel_range(start, start + PMD_SIZE);
> +	pmd_populate_kernel(&init_mm, pmd, pgtable);
> +}
> +
> +void vmemmap_update_pte(unsigned long addr, pte_t *pte, pte_t entry)
> +{
> +	spin_lock(&init_mm.page_table_lock);
> +	pte_clear(&init_mm, addr, pte);
> +	flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> +	set_pte_at(&init_mm, addr, pte, entry);
> +	spin_unlock(&init_mm.page_table_lock);
> +}
> +#endif
> +
>   int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>   		struct vmem_altmap *altmap)
>   {



From muchun.song at linux.dev  Thu Dec 14 20:37:29 2023
From: muchun.song at linux.dev (Muchun Song)
Date: Fri, 15 Dec 2023 12:37:29 +0800
Subject: [PATCH 3/3] arm64: mm: Re-enable OPTIMIZE_HUGETLB_VMEMMAP
In-Reply-To: <20231214073912.1938330-4-sunnanyong@huawei.com>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
 <20231214073912.1938330-4-sunnanyong@huawei.com>
Message-ID: <3D3CFB4D-E3DD-41A5-8FF7-51D61D9F9C73@linux.dev>



> On Dec 14, 2023, at 15:39, Nanyong Sun <sunnanyong at huawei.com> wrote:
> 
> Now update of vmemmap page table can follow the rule of
> break-before-make safely for arm64 architecture, re-enable
> HVO on arm64.
> 
> Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>

Reviewed-by: Muchun Song <songmuchun at bytedance.com>

Thanks.



From dsimic at manjaro.org  Thu Dec 14 21:00:33 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Fri, 15 Dec 2023 06:00:33 +0100
Subject: [PATCH] arm64: dts: rockchip: Add cache information to the SoC dtsi for RK3399
Message-ID: <be3cbcae5c40fa72a52845d30dcc66c847a98cfa.1702616304.git.dsimic@manjaro.org>

Add missing cache information to the Rockchip RK3399 SoC dtsi.  The specified
values were derived by hand from the cache size specifications available from
the RK3399 datasheet;  for future reference, here's a brief summary:

  - Each Cortex-A72 core has 48 KB of L1 instruction cache and
    32 KB of L1 data cache available, four-way set associative
  - Each Cortex-A53 core core has 32 KB of instruction cache and
    32 KB of L1 data cache available, four-way set associative
  - The big (A72) cluster has 1 MB of unified L2 cache available
  - The little (A53) cluster has 512 KB of unified L2 cache available

This patch allows /proc/cpuinfo and lscpu(1) to display proper RK3399 cache
information, and it eliminates the following error in the kernel log:

  cacheinfo: Unable to detect cache hierarchy for CPU 0

While there, add a couple of somewhat useful comments, which may help a bit
anyone going through the RK3399 SoC dtsi.

Co-developed-by: Kyle Copperfield <kmcopper at danwin1210.me>
Signed-off-by: Dragan Simic <dsimic at manjaro.org>
---

Notes:
    It's been a while since Kyle and I worked on this patch, and his email
    address seems to no longer work.  Unfortunately, I have no idea is there
    some other email address that he actually uses now.  However, Kyle needs
    to be mentioned as a co-author of this patch.

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 64 +++++++++++++++++++++++-
 1 file changed, 62 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index da0dfb237f85..f38c27f87cc9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -41,22 +41,22 @@ cpus {
 		#size-cells = <0>;
 
 		cpu-map {
-			cluster0 {
+			cluster0 {	/* Cortex-A53 */
 				core0 {
 					cpu = <&cpu_l0>;
 				};
 				core1 {
 					cpu = <&cpu_l1>;
 				};
 				core2 {
 					cpu = <&cpu_l2>;
 				};
 				core3 {
 					cpu = <&cpu_l3>;
 				};
 			};
 
-			cluster1 {
+			cluster1 {	/* Cortex-A72 */
 				core0 {
 					cpu = <&cpu_b0>;
 				};
@@ -76,54 +76,89 @@ cpu_l0: cpu at 0 {
 			#cooling-cells = <2>; /* min followed by max */
 			dynamic-power-coefficient = <100>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2_cache_l>;
 		};
 
 		cpu_l1: cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53";
 			reg = <0x0 0x1>;
 			enable-method = "psci";
 			capacity-dmips-mhz = <485>;
 			clocks = <&cru ARMCLKL>;
 			#cooling-cells = <2>; /* min followed by max */
 			dynamic-power-coefficient = <100>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2_cache_l>;
 		};
 
 		cpu_l2: cpu at 2 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53";
 			reg = <0x0 0x2>;
 			enable-method = "psci";
 			capacity-dmips-mhz = <485>;
 			clocks = <&cru ARMCLKL>;
 			#cooling-cells = <2>; /* min followed by max */
 			dynamic-power-coefficient = <100>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2_cache_l>;
 		};
 
 		cpu_l3: cpu at 3 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53";
 			reg = <0x0 0x3>;
 			enable-method = "psci";
 			capacity-dmips-mhz = <485>;
 			clocks = <&cru ARMCLKL>;
 			#cooling-cells = <2>; /* min followed by max */
 			dynamic-power-coefficient = <100>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			i-cache-size = <0x8000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <128>;
+			next-level-cache = <&l2_cache_l>;
 		};
 
 		cpu_b0: cpu at 100 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a72";
 			reg = <0x0 0x100>;
 			enable-method = "psci";
 			capacity-dmips-mhz = <1024>;
 			clocks = <&cru ARMCLKB>;
 			#cooling-cells = <2>; /* min followed by max */
 			dynamic-power-coefficient = <436>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			i-cache-size = <0xC000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache_b>;
 
 			thermal-idle {
 				#cooling-cells = <2>;
@@ -142,14 +177,39 @@ cpu_b1: cpu at 101 {
 			#cooling-cells = <2>; /* min followed by max */
 			dynamic-power-coefficient = <436>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			i-cache-size = <0xC000>;
+			i-cache-line-size = <64>;
+			i-cache-sets = <256>;
+			d-cache-size = <0x8000>;
+			d-cache-line-size = <64>;
+			d-cache-sets = <256>;
+			next-level-cache = <&l2_cache_b>;
 
 			thermal-idle {
 				#cooling-cells = <2>;
 				duration-us = <10000>;
 				exit-latency-us = <500>;
 			};
 		};
 
+		l2_cache_l: l2-cache-cluster0 {
+			compatible = "cache";
+			cache-level = <2>;
+			cache-unified;
+			cache-size = <0x80000>;
+			cache-line-size = <64>;
+			cache-sets = <512>;
+		};
+
+		l2_cache_b: l2-cache-cluster1 {
+			compatible = "cache";
+			cache-level = <2>;
+			cache-unified;
+			cache-size = <0x100000>;
+			cache-line-size = <64>;
+			cache-sets = <1024>;
+		};
+
 		idle-states {
 			entry-method = "psci";
 


From s-vadapalli at ti.com  Thu Dec 14 21:47:21 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Fri, 15 Dec 2023 11:17:21 +0530
Subject: [PATCH v3] arm64: dts: ti: k3-am654-icssg2: Enable PHY interrupt for ICSSG2 PHY0
Message-ID: <20231215054721.1975642-1-s-vadapalli@ti.com>

Enable interrupt mode of operation of the DP83867 Ethernet PHY which is
used by ICSSG2. The DP83867 PHY driver already supports interrupt handling
for interrupts generated by the PHY. Thus, add the necessary device-tree
support to enable it.

Since the GPIO1_87 line is muxed with EXT_REFCLK1 and SYNC1_OUT, update
the pinmux to select GPIO1_87 for routing the interrupt.

The GPIO1_87 interrupt line is shared by both the PHYs used by ICSSG2 due
to the board design. Since the SoC only supports Edge-Triggered interrupts
and Edge-Triggered interrupts cannot be shared, enable interrupt mode of
operation for ICSSG2 PHY0 alone while ICSSG2 PHY1 shall continue operating
in polled mode.

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
Reviewed-by: MD Danish Anwar <danishanwar at ti.com>
---
Hello,

This patch is based on linux-next tagged next-20231215.

v2:
https://lore.kernel.org/r/20231213080216.1710730-1-s-vadapalli at ti.com/
Changes since v2:
- Rebased patch on next-20231215.
- As pointed out by Nishanth Menon <nm at ti.com> at:
  https://lore.kernel.org/r/20231213123819.tqh3lm2ceir3qjbk at swimmer/
  the interrupt being shared between both the PHYs is an Edge-Triggered
  interrupt, due to which it shouldn't be shared. Thus, as discussed at:
  https://lore.kernel.org/r/0cef8f50-6608-cf3d-ad62-1afd3f5560ea at ti.com/
  the interrupt shall be dedicated to ICSSG2 PHY0 while ICSSG2 PHY1 shall
  continue operating in polled mode.
- Removed interrupt specific configuration from icssg2_phy1 which was
  present in the v2 patch.
- Added comment above icssg2_phy0 indicating why the interrupt mode of
  operation is only being enabled for icssg2_phy0 and not for icssg2_phy1.
- Updated commit message to match the new implementation.

v1:
https://lore.kernel.org/r/20231120063159.539306-1-s-vadapalli at ti.com/
Changes since v1:
- Rebased patch on next-20231213.
- Collected Reviewed-by tag from
  MD Danish Anwar <danishanwar at ti.com>
- Moved pinctrl from MDIO node to Ethernet PHY node based on feedback from
  Nishanth Menon <nm at ti.com>
- Replaced the hard-coded value 0x2 with IRQ_TYPE_EDGE_FALLING for
  setting the interrupt trigger type and level flag based on feedback from
  Nishanth Menon <nm at ti.com>
- Included dt-bindings/interrupt-controller/irq.h in the overlay.
- Updated commit message with details of the pinmux resource allocation.

Regards,
Siddharth.

 arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso | 23 +++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
index ec8cf20ca3ac..cce3f60904f1 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
+++ b/arch/arm64/boot/dts/ti/k3-am654-icssg2.dtso
@@ -8,6 +8,7 @@
 /dts-v1/;
 /plugin/;
 
+#include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/net/ti-dp83867.h>
 #include "k3-pinctrl.h"
 
@@ -124,6 +125,15 @@ AM65X_IOPAD(0x0088, PIN_INPUT, 2) /* (AG17) PRG2_PRU0_GPO4.PRG2_RGMII1_RX_CTL */
 	};
 };
 
+&main_pmx1 {
+	/* Select GPIO1_87 for ICSSG2 PHY interrupt */
+	icssg2_phy_irq_pins_default: icssg2-phy-irq-default-pins {
+		pinctrl-single,pins = <
+			AM65X_IOPAD(0x0014, PIN_INPUT, 7) /* (A22) EXT_REFCLK1.GPIO1_87 */
+		>;
+	};
+};
+
 &icssg2_mdio {
 	status = "okay";
 	pinctrl-names = "default";
@@ -131,8 +141,21 @@ &icssg2_mdio {
 	#address-cells = <1>;
 	#size-cells = <0>;
 
+	/*
+	 * icssg2_phy0 and icssg2_phy1 share the same interrupt:
+	 * "GPIO1_87" due to the board design.
+	 * Since the SoC only supports Edge-Triggered interrupts and
+	 * Edge-Triggered interrupts cannot be shared, the interrupt will
+	 * be dedicated solely for icssg2_phy0's use while icssg2_phy1
+	 * shall continue operating in polled mode.
+	 */
 	icssg2_phy0: ethernet-phy at 0 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&icssg2_phy_irq_pins_default>;
+
 		reg = <0>;
+		interrupt-parent = <&main_gpio1>;
+		interrupts = <87 IRQ_TYPE_EDGE_FALLING>;
 		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
 		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
 	};
-- 
2.34.1



From s-vadapalli at ti.com  Thu Dec 14 22:08:07 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Fri, 15 Dec 2023 11:38:07 +0530
Subject: [PATCH v2 3/4] dmaengine: ti: k3-udma-glue: Add function to
 request TX channel by ID
In-Reply-To: <800ccf2e-65cc-4524-8a42-1657a5906482@gmail.com>
References: <20231212111011.1401641-1-s-vadapalli@ti.com>
 <20231212111011.1401641-4-s-vadapalli@ti.com>
 <800ccf2e-65cc-4524-8a42-1657a5906482@gmail.com>
Message-ID: <4f13681a-dc13-4de2-a0d5-9f85a4c350d4@ti.com>

Hello P?ter,

On 14/12/23 21:11, P?ter Ujfalusi wrote:
> 
> 
> On 12/12/2023 13:10, Siddharth Vadapalli wrote:
>> The existing function k3_udma_glue_request_tx_chn() supports requesting
>> a TX DMA channel by its name. Add support to request TX channel by ID in
>> the form of a new function k3_udma_glue_request_tx_chn_by_id() and export
>> it for use by drivers which are probed by alternate methods (non
>> device-tree) but still wish to make use of the existing DMA APIs. Such
>> drivers could be informed about the TX channel to use by RPMsg for example.
>>
>> Since the implementation of k3_udma_glue_request_tx_chn_by_id() reuses
>> most of the code in k3_udma_glue_request_tx_chn(), create a new function
>> for the common code named as k3_udma_glue_request_tx_chn_common().
>>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
>> ---
>> Changes since v1:
>> - Updated commit message indicating the use-case for which the patch is
>>   being added.
>>
>>  drivers/dma/ti/k3-udma-glue.c    | 101 +++++++++++++++++++++++--------
>>  include/linux/dma/k3-udma-glue.h |   4 ++
>>  2 files changed, 79 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
>> index eff1ae3d3efe..ea5119a5e8eb 100644
>> --- a/drivers/dma/ti/k3-udma-glue.c
>> +++ b/drivers/dma/ti/k3-udma-glue.c
>> @@ -274,29 +274,13 @@ static int k3_udma_glue_cfg_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
>>  	return tisci_rm->tisci_udmap_ops->tx_ch_cfg(tisci_rm->tisci, &req);
>>  }
>>  

...

>>  
>>  err:
>> @@ -395,6 +410,40 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>>  }
>>  EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn);
>>  
>> +struct k3_udma_glue_tx_channel *
>> +k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg,
>> +				  struct device_node *udmax_np, u32 thread_id)
> 
> udmax_np is not dev->of_node ?

I am not sure I fully understand the question. If you meant to ask if the driver
which uses this API will not have its device's of_node set to udmax_np, then yes
that's correct.

The driver shall be probed over RPMsg-bus, due to which its device's of_node
will not be udmax_np. Additionally, the udmax_np is the device-tree node of one
of the DMA Controllers described in the device-tree. The driver shall obtain the
reference to the udmax_np node using the API:
of_find_compatible_node()
with the compatible to be passed to the above API being a part of the driver's
data. Thus, it is possible to specify which DMA Controller to use by specifying
the compatible in the driver's data. I hope that I have answered your question.
Please let me know otherwise.

> 
>> +{
>> +	struct k3_udma_glue_tx_channel *tx_chn;
>> +	int ret;
>> +
>> +	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
>> +	if (!tx_chn)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	tx_chn->common.dev = dev;
>> +	tx_chn->common.swdata_size = cfg->swdata_size;
>> +	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
>> +	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
>> +	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
>> +	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
>> +
>> +	ret = of_k3_udma_glue_parse_chn_by_id(udmax_np, &tx_chn->common, true, thread_id);
>> +	if (ret)
>> +		goto err;
>> +
>> +	ret = k3_udma_glue_request_tx_chn_common(dev, tx_chn, cfg);
>> +	if (ret)
>> +		goto err;
>> +
>> +	return tx_chn;
>> +
>> +err:
>> +	k3_udma_glue_release_tx_chn(tx_chn);
>> +	return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn_by_id);
>> +
>>  void k3_udma_glue_release_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
>>  {
>>  	if (tx_chn->psil_paired) {
>> diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h
>> index e443be4d3b4b..6205d84430ca 100644
>> --- a/include/linux/dma/k3-udma-glue.h
>> +++ b/include/linux/dma/k3-udma-glue.h
>> @@ -26,6 +26,10 @@ struct k3_udma_glue_tx_channel;
>>  struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>>  		const char *name, struct k3_udma_glue_tx_channel_cfg *cfg);
>>  
>> +struct k3_udma_glue_tx_channel *
>> +k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg,
> 
> I know it is going to be longer, but can the function be named more
> precisely?
> k3_udma_glue_request_tx_chn_by_thread_id
> 
> For TX/RX: a channel is always for one thread, right?
> Probably:
> k3_udma_glue_request_tx_chn_for_thread_id()
> 
> ?

Sure, I will rename it to:
k3_udma_glue_request_tx_chn_for_thread_id()
as suggested by you.

> 
> Other then this the series looks OK.

Thank you for reviewing the series. I will rename the API as mentioned above and
if the question you had above regarding the of_node has been addressed, I will
post the v3 series. Kindly let me know.

-- 
Regards,
Siddharth.


From Jianjun.Wang at mediatek.com  Thu Dec 14 22:08:11 2023
From: Jianjun.Wang at mediatek.com (=?utf-8?B?Smlhbmp1biBXYW5nICjnjovlu7rlhpsp?=)
Date: Fri, 15 Dec 2023 06:08:11 +0000
Subject: [PATCH v2] PCI: mediatek-gen3: Fix translation window
In-Reply-To: <80fc850062017a2ef2091a43759e19f3fcf2666f.camel@mediatek.com>
References: <20231023081423.18559-1-jianjun.wang@mediatek.com>
	 <80fc850062017a2ef2091a43759e19f3fcf2666f.camel@mediatek.com>
Message-ID: <8becf27eac8ee682d10abeac3ed38e006e476078.camel@mediatek.com>

Hi Bjorn, Lorenzo,

Sorry to bother you, but would you mind taking a look at this patch?
Appreciate any suggestions.

Thanks.

On Thu, 2023-11-23 at 01:27 +0000, Jianjun Wang (???) wrote:
> Hi Maintainers,
> 
> Gentle ping for this patch, if there is anything I need to do, please
> let me know.
> 
> Thanks.
> 
> On Mon, 2023-10-23 at 16:14 +0800, Jianjun Wang wrote:
> > The size of translation table should be a power of 2, using fls()
> > cannot get the proper value when the size is not a power of 2. For
> > example, fls(0x3e00000) - 1 = 25, hence the PCIe translation window
> > size will be set to 0x2000000 instead of the expected size
> > 0x3e00000.
> > 
> > Fix translation window by splitting the MMIO space to multiple
> > tables
> > if
> > its size is not a power of 2.
> > 
> > Fixes: d3bf75b579b9 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver
> > for MT8192")
> > Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
> > 
> > ---
> > Changes in v2:
> > Only print warning message when reach the maximum translation table
> > number, the MEM space still works but will be smaller than
> > expected.
> > 
> > Bootup logs on MT8195 Platform:
> > 
> > > Before this patch:
> > 
> > mtk-pcie-gen3 112f0000.pcie: Parsing ranges property...
> > mtk-pcie-gen3 112f0000.pcie:       IO 0x0020000000..0x00201fffff ->
> > 0x0020000000
> > mtk-pcie-gen3 112f0000.pcie:      MEM 0x0020200000..0x0023ffffff ->
> > 0x0020200000
> > mtk-pcie-gen3 112f0000.pcie: set IO trans window[0]: cpu_addr =
> > 0x20000000, pci_addr = 0x20000000, size = 0x200000
> > mtk-pcie-gen3 112f0000.pcie: set MEM trans window[1]: cpu_addr =
> > 0x20200000, pci_addr = 0x20200000, size = 0x3e00000
> > 
> > > We expect the MEM trans window size to be 0x3e00000, but its
> > > actual
> > > available size is 0x2000000.
> > > After applying this patch:
> > 
> > mtk-pcie-gen3 112f0000.pcie: Parsing ranges property...
> > mtk-pcie-gen3 112f0000.pcie:       IO 0x0020000000..0x00201fffff ->
> > 0x0020000000
> > mtk-pcie-gen3 112f0000.pcie:      MEM 0x0020200000..0x0023ffffff ->
> > 0x0020200000
> > mtk-pcie-gen3 112f0000.pcie: set IO trans window[0]: cpu_addr =
> > 0x20000000, pci_addr = 0x20000000, size = 0x200000
> > mtk-pcie-gen3 112f0000.pcie: set MEM trans window[1]: cpu_addr =
> > 0x20200000, pci_addr = 0x20200000, size = 0x200000
> > mtk-pcie-gen3 112f0000.pcie: set MEM trans window[2]: cpu_addr =
> > 0x20400000, pci_addr = 0x20400000, size = 0x400000
> > mtk-pcie-gen3 112f0000.pcie: set MEM trans window[3]: cpu_addr =
> > 0x20800000, pci_addr = 0x20800000, size = 0x800000
> > mtk-pcie-gen3 112f0000.pcie: set MEM trans window[4]: cpu_addr =
> > 0x21000000, pci_addr = 0x21000000, size = 0x1000000
> > mtk-pcie-gen3 112f0000.pcie: set MEM trans window[5]: cpu_addr =
> > 0x22000000, pci_addr = 0x22000000, size = 0x2000000
> > 
> > > Total available size for MEM trans window is 0x3e00000.
> > 
> > ---
> > ---
> >  drivers/pci/controller/pcie-mediatek-gen3.c | 85 ++++++++++++-----
> > --
> > --
> >  1 file changed, 50 insertions(+), 35 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c
> > b/drivers/pci/controller/pcie-mediatek-gen3.c
> > index e0e27645fdf4..975b3024fb08 100644
> > --- a/drivers/pci/controller/pcie-mediatek-gen3.c
> > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> > @@ -245,35 +245,60 @@ static int mtk_pcie_set_trans_table(struct
> > mtk_gen3_pcie *pcie,
> >  				    resource_size_t cpu_addr,
> >  				    resource_size_t pci_addr,
> >  				    resource_size_t size,
> > -				    unsigned long type, int num)
> > +				    unsigned long type, int *num)
> >  {
> > +	resource_size_t remaining = size;
> > +	resource_size_t table_size;
> > +	resource_size_t addr_align;
> > +	const char *range_type;
> >  	void __iomem *table;
> >  	u32 val;
> >  
> > -	if (num >= PCIE_MAX_TRANS_TABLES) {
> > -		dev_err(pcie->dev, "not enough translate table for
> > addr: %#llx, limited to [%d]\n",
> > -			(unsigned long long)cpu_addr,
> > PCIE_MAX_TRANS_TABLES);
> > -		return -ENODEV;
> > -	}
> > +	while (remaining && (*num < PCIE_MAX_TRANS_TABLES)) {
> > +		/* Table size needs to be a power of 2 */
> > +		table_size = BIT(fls(remaining) - 1);
> > +
> > +		if (cpu_addr > 0) {
> > +			addr_align = BIT(ffs(cpu_addr) - 1);
> > +			table_size = min(table_size, addr_align);
> > +		}
> > +
> > +		/* Minimum size of translate table is 4KiB */
> > +		if (table_size < 0x1000) {
> > +			dev_err(pcie->dev, "illegal table size
> > %#llx\n",
> > +				(unsigned long long)table_size);
> > +			return -EINVAL;
> > +		}
> >  
> > -	table = pcie->base + PCIE_TRANS_TABLE_BASE_REG +
> > -		num * PCIE_ATR_TLB_SET_OFFSET;
> > +		table = pcie->base + PCIE_TRANS_TABLE_BASE_REG + *num *
> > PCIE_ATR_TLB_SET_OFFSET;
> > +		writel_relaxed(lower_32_bits(cpu_addr) |
> > PCIE_ATR_SIZE(fls(table_size) - 1), table);
> > +		writel_relaxed(upper_32_bits(cpu_addr), table +
> > PCIE_ATR_SRC_ADDR_MSB_OFFSET);
> > +		writel_relaxed(lower_32_bits(pci_addr), table +
> > PCIE_ATR_TRSL_ADDR_LSB_OFFSET);
> > +		writel_relaxed(upper_32_bits(pci_addr), table +
> > PCIE_ATR_TRSL_ADDR_MSB_OFFSET);
> >  
> > -	writel_relaxed(lower_32_bits(cpu_addr) |
> > PCIE_ATR_SIZE(fls(size) - 1),
> > -		       table);
> > -	writel_relaxed(upper_32_bits(cpu_addr),
> > -		       table + PCIE_ATR_SRC_ADDR_MSB_OFFSET);
> > -	writel_relaxed(lower_32_bits(pci_addr),
> > -		       table + PCIE_ATR_TRSL_ADDR_LSB_OFFSET);
> > -	writel_relaxed(upper_32_bits(pci_addr),
> > -		       table + PCIE_ATR_TRSL_ADDR_MSB_OFFSET);
> > +		if (type == IORESOURCE_IO) {
> > +			val = PCIE_ATR_TYPE_IO | PCIE_ATR_TLP_TYPE_IO;
> > +			range_type = "IO";
> > +		} else {
> > +			val = PCIE_ATR_TYPE_MEM |
> > PCIE_ATR_TLP_TYPE_MEM;
> > +			range_type = "MEM";
> > +		}
> >  
> > -	if (type == IORESOURCE_IO)
> > -		val = PCIE_ATR_TYPE_IO | PCIE_ATR_TLP_TYPE_IO;
> > -	else
> > -		val = PCIE_ATR_TYPE_MEM | PCIE_ATR_TLP_TYPE_MEM;
> > +		writel_relaxed(val, table +
> > PCIE_ATR_TRSL_PARAM_OFFSET);
> >  
> > -	writel_relaxed(val, table + PCIE_ATR_TRSL_PARAM_OFFSET);
> > +		dev_dbg(pcie->dev, "set %s trans window[%d]: cpu_addr =
> > %#llx, pci_addr = %#llx, size = %#llx\n",
> > +			range_type, *num, (unsigned long long)cpu_addr,
> > +			(unsigned long long)pci_addr, (unsigned long
> > long)table_size);
> > +
> > +		cpu_addr += table_size;
> > +		pci_addr += table_size;
> > +		remaining -= table_size;
> > +		(*num)++;
> > +	}
> > +
> > +	if (remaining)
> > +		dev_warn(pcie->dev, "not enough translate table for
> > addr: %#llx, limited to [%d]\n",
> > +			 (unsigned long long)cpu_addr,
> > PCIE_MAX_TRANS_TABLES);
> >  
> >  	return 0;
> >  }
> > @@ -380,30 +405,20 @@ static int mtk_pcie_startup_port(struct
> > mtk_gen3_pcie *pcie)
> >  		resource_size_t cpu_addr;
> >  		resource_size_t pci_addr;
> >  		resource_size_t size;
> > -		const char *range_type;
> >  
> > -		if (type == IORESOURCE_IO) {
> > +		if (type == IORESOURCE_IO)
> >  			cpu_addr = pci_pio_to_address(res->start);
> > -			range_type = "IO";
> > -		} else if (type == IORESOURCE_MEM) {
> > +		else if (type == IORESOURCE_MEM)
> >  			cpu_addr = res->start;
> > -			range_type = "MEM";
> > -		} else {
> > +		else
> >  			continue;
> > -		}
> >  
> >  		pci_addr = res->start - entry->offset;
> >  		size = resource_size(res);
> >  		err = mtk_pcie_set_trans_table(pcie, cpu_addr,
> > pci_addr, size,
> > -					       type, table_index);
> > +					       type, &table_index);
> >  		if (err)
> >  			return err;
> > -
> > -		dev_dbg(pcie->dev, "set %s trans window[%d]: cpu_addr =
> > %#llx, pci_addr = %#llx, size = %#llx\n",
> > -			range_type, table_index, (unsigned long
> > long)cpu_addr,
> > -			(unsigned long long)pci_addr, (unsigned long
> > long)size);
> > -
> > -		table_index++;
> >  	}
> >  
> >  	return 0;

From Chunfeng.Yun at mediatek.com  Thu Dec 14 22:10:27 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Fri, 15 Dec 2023 06:10:27 +0000
Subject: [PATCH 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1
 isoc-in transfer issue
In-Reply-To: <c1bc144d-07d6-422c-8294-42be47f83e59@linaro.org>
References: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
	 <c1bc144d-07d6-422c-8294-42be47f83e59@linaro.org>
Message-ID: <150d776b6a4ab0f0ee1926dd916d6eea3a583ad5.camel@mediatek.com>

On Wed, 2023-12-13 at 09:05 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 13/12/2023 07:35, Chunfeng Yun wrote:
> > For Gen1 isoc-in endpoint on controller before about SSUSB IPM
> v1.6.0, it
> > still send out unexpected ACK after receiving a short packet in
> burst
> > transfer, this will cause an exception on connected device,
> specially for
> > a 4k camera.
> > Add a quirk property "mediatek,rxfifo-depth" to work around this
> hardware
> > issue;
> > The side-effect is that may cause performance drop about 10%,
> including
> > bulk transfer.
> > 
> > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > ---
> >  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml     | 10
> ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> xhci.yaml
> > index e9644e333d78..b8ed68574ba4 100644
> > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> > @@ -124,6 +124,16 @@ properties:
> >        defined in the xHCI spec on MTK's controller.
> >      default: 5000
> >  
> > +  mediatek,rxfifo-depth:
> > +    description:
> 
> The property description and driver patch suggest you configure the
> depth of FIFO, so this should be not bool, but some uint32. And then,
> use generic "fifo-depth" property to set desired depth.
I fix it as 2, it's OK to use a uint32, I'll modify it.

Thanks

> 
> 
> Best regards,
> Krzysztof
> 
> 

From Chunfeng.Yun at mediatek.com  Thu Dec 14 22:14:07 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Fri, 15 Dec 2023 06:14:07 +0000
Subject: [PATCH 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1
 isoc-in transfer issue
In-Reply-To: <5327b2fd-94c6-46fe-b987-52cfff042033@collabora.com>
References: <20231213063543.12435-1-chunfeng.yun@mediatek.com>
	 <c1bc144d-07d6-422c-8294-42be47f83e59@linaro.org>
	 <5327b2fd-94c6-46fe-b987-52cfff042033@collabora.com>
Message-ID: <e2e9644e13a8c0bb6ab7a24011c98c784d3d9cb6.camel@mediatek.com>

On Wed, 2023-12-13 at 12:17 +0100, AngeloGioacchino Del Regno wrote:
> Il 13/12/23 09:05, Krzysztof Kozlowski ha scritto:
> > On 13/12/2023 07:35, Chunfeng Yun wrote:
> > > For Gen1 isoc-in endpoint on controller before about SSUSB IPM
> > > v1.6.0, it
> > > still send out unexpected ACK after receiving a short packet in
> > > burst
> > > transfer, this will cause an exception on connected device,
> > > specially for
> > > a 4k camera.
> > > Add a quirk property "mediatek,rxfifo-depth" to work around this
> > > hardware
> > > issue;
> > > The side-effect is that may cause performance drop about 10%,
> > > including
> > > bulk transfer.
> > > 
> > > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > > ---
> > >   .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml     | 10
> > > ++++++++++
> > >   1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml
> > > index e9644e333d78..b8ed68574ba4 100644
> > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml
> > > @@ -124,6 +124,16 @@ properties:
> > >         defined in the xHCI spec on MTK's controller.
> > >       default: 5000
> > >   
> > > +  mediatek,rxfifo-depth:
> > > +    description:
> > 
> > The property description and driver patch suggest you configure the
> > depth of FIFO, so this should be not bool, but some uint32. And
> > then,
> > use generic "fifo-depth" property to set desired depth.
> 
> Did you mean "rx-fifo-depth" instead, as used in net?
> This FIFO depth parameter is for RX only.
Yes, only for RX

> 
> Cheers,
> Angelo
> 
> 

From wangkefeng.wang at huawei.com  Thu Dec 14 22:16:54 2023
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Fri, 15 Dec 2023 14:16:54 +0800
Subject: [PATCH 1/3] mm: HVO: introduce helper function to update and
 flush pgtable
In-Reply-To: <20231214073912.1938330-2-sunnanyong@huawei.com>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
 <20231214073912.1938330-2-sunnanyong@huawei.com>
Message-ID: <f7950e7c-12b8-44b4-bfa9-fb2cb16944c0@huawei.com>



On 2023/12/14 15:39, Nanyong Sun wrote:
> Add pmd/pte update and tlb flush helper function to update page
> table. This refactoring patch is designed to facilitate each
> architecture to implement its own special logic in preparation
> for the arm64 architecture to follow the necessary break-before-make
> sequence when updating page tables.
> 
> Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
> ---
>   mm/hugetlb_vmemmap.c | 55 ++++++++++++++++++++++++++++++++++----------
>   1 file changed, 43 insertions(+), 12 deletions(-)
> 
> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index 87818ee7f01d..49e8b351def3 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
> @@ -45,6 +45,37 @@ struct vmemmap_remap_walk {
>   	unsigned long		flags;
>   };
>   
> +#ifndef vmemmap_update_pmd
> +static inline void vmemmap_update_pmd(unsigned long start,
> +				      pmd_t *pmd, pte_t *pgtable)

pgtable ->  ptep

> +{
> +	pmd_populate_kernel(&init_mm, pmd, pgtable);
> +}
> +#endif
> +
> +#ifndef vmemmap_update_pte
> +static inline void vmemmap_update_pte(unsigned long addr,
> +				      pte_t *pte, pte_t entry)

pte   -> ptep
entry -> pte

> +{
> +	set_pte_at(&init_mm, addr, pte, entry);
> +}
> +#endif



From wangjinchao at xfusion.com  Thu Dec 14 22:27:23 2023
From: wangjinchao at xfusion.com (Wang Jinchao)
Date: Fri, 15 Dec 2023 14:27:23 +0800
Subject: [PATCH] arm: remove duplicated include
Message-ID: <202312151426+0800-wangjinchao@xfusion.com>

remove duplicated include

Signed-off-by: Wang Jinchao <wangjinchao at xfusion.com>
---
 arch/arm/include/asm/pgtable.h    | 4 ++--
 arch/arm/mach-footbridge/common.c | 1 -
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 16b02f44c7d3..8c0de013f85e 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -19,14 +19,14 @@ extern struct page *empty_zero_page;
 #define ZERO_PAGE(vaddr)	(empty_zero_page)
 #endif
 
+#include <asm-generic/pgtable-nopud.h>
+
 #ifndef CONFIG_MMU
 
-#include <asm-generic/pgtable-nopud.h>
 #include <asm/pgtable-nommu.h>
 
 #else
 
-#include <asm-generic/pgtable-nopud.h>
 #include <asm/page.h>
 #include <asm/pgtable-hwdef.h>
 
diff --git a/arch/arm/mach-footbridge/common.c b/arch/arm/mach-footbridge/common.c
index 85c598708c10..c8f52d52b91b 100644
--- a/arch/arm/mach-footbridge/common.c
+++ b/arch/arm/mach-footbridge/common.c
@@ -30,7 +30,6 @@
 
 #include <mach/hardware.h>
 #include <mach/irqs.h>
-#include <asm/hardware/dec21285.h>
 
 static int dc21285_get_irq(void)
 {
-- 
2.40.0



From alexander.stein at ew.tq-group.com  Thu Dec 14 22:32:27 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Fri, 15 Dec 2023 07:32:27 +0100
Subject: [EXT] Re: [PATCH 3/4] arm64: dts: imx93: add usb nodes
In-Reply-To: <DB7PR04MB51462A079F226C6B9FCA9F7C8C93A@DB7PR04MB5146.eurprd04.prod.outlook.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com> <8309719.T7Z3S40VBb@steina-w> <DB7PR04MB51462A079F226C6B9FCA9F7C8C93A@DB7PR04MB5146.eurprd04.prod.outlook.com>
Message-ID: <3198956.5fSG56mABF@steina-w>

Hi,

Am Freitag, 15. Dezember 2023, 03:12:43 CET schrieb Xu Yang:
> Hi Alexander,
> 
> > Hi,
> > 
> > thanks for the patch.
> > 
> > Am Donnerstag, 14. Dezember 2023, 12:24:41 CET schrieb Xu Yang:
> > > There are 2 USB controllers on i.MX93. Add them.
> > > 
> > > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > > ---
> > > 
> > >  arch/arm64/boot/dts/freescale/imx93.dtsi | 58 ++++++++++++++++++++++++
> > >  1 file changed, 58 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx93.dtsi index
> > > 34c0540276d1..bcf4861cfede
> > > 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx93.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
> > > @@ -171,6 +171,20 @@ cm33: remoteproc-cm33 {
> > > 
> > >               status = "disabled";
> > >       
> > >       };
> > > 
> > > +     usbphynop1: usbphynop1 {
> > > +             #phy-cells = <0>;
> > > +             compatible = "usb-nop-xceiv";
> > 
> > compatible first.
> 
> Okay.
> 
> > > +             clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> > > +             clock-names = "main_clk";
> > > +     };
> > > +
> > > +     usbphynop2: usbphynop2 {
> > > +             #phy-cells = <0>;
> > > +             compatible = "usb-nop-xceiv";
> > 
> > compatible first.
> 
> Okay.
> 
> > > +             clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> > > +             clock-names = "main_clk";
> > > +     };
> > > +
> > > 
> > >       soc at 0 {
> > >       
> > >               compatible = "simple-bus";
> > >               #address-cells = <1>;
> > > 
> > > @@ -1059,5 +1073,49 @@ ddr-pmu at 4e300dc0 {
> > > 
> > >                       reg = <0x4e300dc0 0x200>;
> > >                       interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
> > >               
> > >               };
> > > 
> > > +
> > > +             usbotg1: usb at 4c100000 {
> > > +                     compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb",
> > 
> > "fsl,imx27-usb";
> > 
> > > +                     reg = <0x4c100000 0x200>;
> > > +                     interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
> > > +                     clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> > > +                              <&clk IMX93_CLK_HSIO_32K_GATE>;
> > > +                     clock-names = "usb_ctrl_root_clk",
> > 
> > "usb_wakeup_clk";
> > 
> > drivers/usb/chipidea/ci_hdrc_imx.c uses 3 clocks: "ipg", "ahb" and "per",
> > see imx_get_clks(). How is this supposed to work?
> 
> I have sent another patch to get this clock.
> https://lore.kernel.org/all/20231214112622.2412321-1-xu.yang_2 at nxp.com/

Okay, but that adds another clock which is not mentioned in Documentation/
devicetree/bindings/usb/ci-hdrc-usb2.yaml at all. I guess some compatible-
specific constraints regarding number of clocks should be added.

Best regards,
Alexander

> 
> > > +                     assigned-clocks = <&clk IMX93_CLK_HSIO>;
> > > +                     assigned-clock-parents = <&clk
> > 
> > IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> > 
> > > +                     assigned-clock-rates = <133000000>;
> > > +                     fsl,usbphy = <&usbphynop1>;
> > > +                     fsl,usbmisc = <&usbmisc1 0>;
> > > +                     status = "disabled";
> > > +             };
> > > +
> > > +             usbmisc1: usbmisc at 4c100200 {
> > > +                     compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-
> > 
> > usbmisc",
> > 
> > > +                                     "fsl,imx6q-usbmisc";
> > 
> > This means you are compatible to fsl,imx7d-usbmisc. Which means you use
> > register MX7D_USB_OTG_PHY_STATUS in USB misc (USBNC). But i.MX93 RM Rev. 2
> > (04/2023) lacks this and other registers.
> 
> Some registers in USBNC are not shown. The internal RM has these registers.
> 
> > > +                     #index-cells = <1>;
> > > +                     reg = <0x4c100200 0x200>;
> > 
> > reg after compatible.
> 
> Okay.
> 
> > > +             };
> > > +
> > > +             usbotg2: usb at 4c200000 {
> > > +                     compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb",
> > 
> > "fsl,imx27-usb";
> > 
> > > +                     reg = <0x4c200000 0x200>;
> > > +                     interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
> > > +                     clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> > > +                              <&clk IMX93_CLK_HSIO_32K_GATE>;
> > > +                     clock-names = "usb_ctrl_root_clk",
> > 
> > "usb_wakeup_clk";
> > 
> > The same as for usbotg1 applies here.
> 
> Okay.
> 
> > > +                     assigned-clocks = <&clk IMX93_CLK_HSIO>;
> > > +                     assigned-clock-parents = <&clk
> > 
> > IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> > 
> > > +                     assigned-clock-rates = <133000000>;
> > > +                     fsl,usbphy = <&usbphynop2>;
> > > +                     fsl,usbmisc = <&usbmisc2 0>;
> > > +                     status = "disabled";
> > > +             };
> > > +
> > > +             usbmisc2: usbmisc at 4c200200 {
> > > +                     compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-
> > 
> > usbmisc",
> > 
> > > +                                     "fsl,imx6q-usbmisc";
> > > +                     #index-cells = <1>;
> > > +                     reg = <0x4c200200 0x200>;
> > 
> > The same as for usbmisc1 applies here.
> 
> Okay.
> 
> > > +             };
> > > 
> > >       };
> > >  
> > >  };
> > 
> > Best regards,
> > Alexander
> > 
> > --
> > TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
> > Amtsgericht M?nchen, HRB 105018
> > Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
> > http://www.tq-/
> > group.com%2F&data=05%7C02%7Cxu.yang_2%40nxp.com%7C10ff5a35f53f4047ae1d08db
> > fca99c38%7C686ea1d3bc2b4c6fa
> > 92cd99c5c301635%7C0%7C0%7C638381577622080432%7CUnknown%7CTWFpbGZsb3d8eyJW
> > IjoiMC4wLjAwMDAiLCJQIjoiV2
> > luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VlpRPcnJTmywfS
> > amaGB1Ev8aPN2Hi596VbbRNGXF yis%3D&reserved=0


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From wangkefeng.wang at huawei.com  Thu Dec 14 22:32:20 2023
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Fri, 15 Dec 2023 14:32:20 +0800
Subject: [PATCH 2/3] arm64: mm: HVO: support BBM of vmemmap pgtable safely
In-Reply-To: <50f082a8-b805-5d66-45f4-2af58e99a67f@linux.dev>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
 <20231214073912.1938330-3-sunnanyong@huawei.com>
 <50f082a8-b805-5d66-45f4-2af58e99a67f@linux.dev>
Message-ID: <f914efc0-ea93-4326-853f-8e5a14e7f3da@huawei.com>



On 2023/12/15 12:36, Muchun Song wrote:
> 
> 
> On 2023/12/14 15:39, Nanyong Sun wrote:
>> Implement vmemmap_update_pmd and vmemmap_update_pte on arm64 to do
>> BBM(break-before-make) logic when change the page table of vmemmap
>> address, they will under the init_mm.page_table_lock.
>> If a translation fault of vmemmap address concurrently happened after
>> pte/pmd cleared, vmemmap page fault handler will acquire the
>> init_mm.page_table_lock to wait for vmemmap update to complete,
>> by then the virtual address is valid again, so PF can return and
>> access can continue.
>> In other case, do the traditional kernel fault.
> 
> Yes. BTW, we already use the same scheme to support arm64
> in our internal production. So the whole approach LGTM.
> 
>> Implement flush_tlb_vmemmap_all and flush_tlb_vmemmap_range on arm64
>> with nothing to do because tlb already flushed in every single BBM.
>>
>> Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
>> ---
>> ? arch/arm64/include/asm/esr.h |? 4 ++
>> ? arch/arm64/include/asm/mmu.h | 20 ++++++++
>> ? arch/arm64/mm/fault.c??????? | 94 ++++++++++++++++++++++++++++++++++++
>> ? arch/arm64/mm/mmu.c????????? | 28 +++++++++++
>> ? 4 files changed, 146 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
>> index ae35939f395b..1c63256efd25 100644
>> --- a/arch/arm64/include/asm/esr.h
>> +++ b/arch/arm64/include/asm/esr.h
>> @@ -116,6 +116,10 @@
>> ? #define ESR_ELx_FSC_SERROR??? (0x11)
>> ? #define ESR_ELx_FSC_ACCESS??? (0x08)
>> ? #define ESR_ELx_FSC_FAULT??? (0x04)
>> +#define ESR_ELx_FSC_FAULT_L0??? (0x04)
>> +#define ESR_ELx_FSC_FAULT_L1??? (0x05)
>> +#define ESR_ELx_FSC_FAULT_L2??? (0x06)
>> +#define ESR_ELx_FSC_FAULT_L3??? (0x07)
>> ? #define ESR_ELx_FSC_PERM??? (0x0C)
>> ? #define ESR_ELx_FSC_SEA_TTW0??? (0x14)
>> ? #define ESR_ELx_FSC_SEA_TTW1??? (0x15)
>> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
>> index 2fcf51231d6e..fcec5827f54f 100644
>> --- a/arch/arm64/include/asm/mmu.h
>> +++ b/arch/arm64/include/asm/mmu.h
>> @@ -76,5 +76,25 @@ extern bool kaslr_requires_kpti(void);
>> ? #define INIT_MM_CONTEXT(name)??? \
>> ????? .pgd = init_pg_dir,
>> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
>> +void vmemmap_update_pmd(unsigned long start, pmd_t *pmd, pte_t 
>> *pgtable);
>> +#define vmemmap_update_pmd vmemmap_update_pmd
>> +void vmemmap_update_pte(unsigned long addr, pte_t *pte, pte_t entry);
>> +#define vmemmap_update_pte vmemmap_update_pte
>> +
>> +static inline void flush_tlb_vmemmap_all(void)
>> +{
>> +??? /* do nothing, already flushed tlb in every single BBM */
>> +}
>> +#define flush_tlb_vmemmap_all flush_tlb_vmemmap_all
>> +
>> +static inline void flush_tlb_vmemmap_range(unsigned long start,
>> +?????????????????????? unsigned long end)
>> +{
>> +??? /* do nothing, already flushed tlb in every single BBM */
>> +}
>> +#define flush_tlb_vmemmap_range flush_tlb_vmemmap_range
>> +#endif
>> +
>> ? #endif??? /* !__ASSEMBLY__ */
>> ? #endif
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 460d799e1296..7066a273c1e0 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -368,6 +368,97 @@ static bool 
>> is_el1_mte_sync_tag_check_fault(unsigned long esr)
>> ????? return false;
>> ? }
>> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
>> +static inline bool is_vmemmap_address(unsigned long addr)
>> +{
>> +??? return (addr >= VMEMMAP_START) && (addr < VMEMMAP_END);
>> +}
>> +
>> +static inline bool vmemmap_fault_may_fixup(unsigned long addr,
>> +?????????????????????? unsigned long esr)
>> +{
>> +??? if (!is_vmemmap_address(addr))
>> +??????? return false;
>> +

Squash the vmemmap range check into this function.

>> +??? /*
>> +???? * Only try to handle translation fault level 2 or level 3,
>> +???? * because hugetlb vmemmap optimize only clear pmd or pte.
>> +???? */
>> +??? switch (esr & ESR_ELx_FSC) {
>> +??? case ESR_ELx_FSC_FAULT_L2:
>> +??? case ESR_ELx_FSC_FAULT_L3:
>> +??????? return true;
>> +??? default:
>> +??????? return false;
>> +??? }
>> +}
>> +
>> +/*
>> + * PMD mapped vmemmap should has been split as PTE mapped
>> + * by HVO now, here we only check this case, other cases
>> + * should fail.
>> + * Also should check the addr is healthy enough that will not cause
>> + * a level2 or level3 translation fault again after page fault
>> + * handled with success, so we need check both bits[1:0] of PMD and
>> + * PTE as ARM Spec mentioned below:
>> + * A Translation fault is generated if bits[1:0] of a translation
>> + * table descriptor identify the descriptor as either a Fault
>> + * encoding or a reserved encoding.
>> + */
>> +static inline bool vmemmap_addr_healthy(unsigned long addr)
>> +{
>> +??? pgd_t *pgdp;
>> +??? p4d_t *p4dp;
>> +??? pud_t *pudp, pud;
>> +??? pmd_t *pmdp, pmd;
>> +??? pte_t *ptep, pte;
>> +
>> +??? pgdp = pgd_offset_k(addr);
>> +??? if (pgd_none(READ_ONCE(*pgdp)))
>> +??????? return false;
>> +
>> +??? p4dp = p4d_offset(pgdp, addr);
>> +??? if (p4d_none(READ_ONCE(*p4dp)))
>> +??????? return false;
>> +
>> +??? pudp = pud_offset(p4dp, addr);
>> +??? pud = READ_ONCE(*pudp);
>> +??? if (pud_none(pud))
>> +??????? return false;
>> +
>> +??? pmdp = pmd_offset(pudp, addr);
> 
> We already make sure it is a translation fault of level 2 or 3
> here, so we could use pmd_offset_k() macro to simplify the code
> a little. Right?
> 
>> +??? pmd = READ_ONCE(*pmdp);
>> +??? if (!pmd_table(pmd))
>> +??????? return false;
>> +
>> +??? ptep = pte_offset_kernel(pmdp, addr);
>> +??? pte = READ_ONCE(*ptep);
> 
> Please use ptep_get (which is supposed to do this) to access the
> raw pte, see commit c33c794828f21217.
> 
>> +??? return (pte_val(pte) & PTE_TYPE_MASK) == PTE_TYPE_PAGE;
>> +}
>> +
>> +static bool vmemmap_handle_page_fault(unsigned long addr,
>> +????????????????????? unsigned long esr)
>> +{
>> +??? bool ret = false;
>> +
>> +??? if (likely(!vmemmap_fault_may_fixup(addr, esr)))
>> +??????? return false;
>> +
>> +??? spin_lock(&init_mm.page_table_lock);
>> +??? if (vmemmap_addr_healthy(addr))
>> +??????? ret = true;
> 
> It is to assign the return value to ret directly. Like:
> 
>  ??? ??? ret = vmemmap_addr_healthy(addr);
> 
> The the initializetion to ret also can be dropped.
> 
>> +??? spin_unlock(&init_mm.page_table_lock);
>> +
>> +??? return ret;
>> +}
>> +#else
>> +static inline bool vmemmap_handle_page_fault(unsigned long addr,
>> +???????????????????????? unsigned long esr)
>> +{
>> +??? return false;
>> +}
>> +#endif /*CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP */
>  ????????? ^
> Miss a blank between "*" and "C" here.
> 
> Thanks.
> 
>> +
>> ? static bool is_translation_fault(unsigned long esr)
>> ? {
>> ????? return (esr & ESR_ELx_FSC_TYPE) == ESR_ELx_FSC_FAULT;
>> @@ -409,6 +500,9 @@ static void __do_kernel_fault(unsigned long addr, 
>> unsigned long esr,
>> ????????????? kfence_handle_page_fault(addr, esr & ESR_ELx_WNR, regs))
>> ????????????? return;
>> +??????? if (vmemmap_handle_page_fault(addr, esr))
>> +??????????? return;
>> +

Better to move under is_translation_fault()?

if (is_translation_fault(esr) {
	if (kfence_handle_page_fault())
		return;
	if (vmemmap_handle_page_fault())
		return;
}



>> ????????? msg = "paging request";
>> ????? }
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 15f6347d23b6..81a600ccac7c 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -1146,6 +1146,34 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, 
>> int node,
>> ????? return 1;
>> ? }
>> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
>> +/*
>> + * In the window between the page table entry is cleared and filled
>> + * with a new value, other threads have the opportunity to concurrently
>> + * access the vmemmap area then page translation fault occur.
>> + * Therefore, we need to ensure that the init_mm.page_table_lock is held
>> + * to synchronize the vmemmap page fault handling which will wait for
>> + * this lock to be released to ensure that the page table entry has been
>> + * refreshed with a new valid value.
>> + */
>> +void vmemmap_update_pmd(unsigned long start, pmd_t *pmd, pte_t *pgtable)
>> +{
>> +??? lockdep_assert_held(&init_mm.page_table_lock);
>> +??? pmd_clear(pmd);
>> +??? flush_tlb_kernel_range(start, start + PMD_SIZE);
>> +??? pmd_populate_kernel(&init_mm, pmd, pgtable);
>> +}
>> +
>> +void vmemmap_update_pte(unsigned long addr, pte_t *pte, pte_t entry)
>> +{
>> +??? spin_lock(&init_mm.page_table_lock);
>> +??? pte_clear(&init_mm, addr, pte);
>> +??? flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>> +??? set_pte_at(&init_mm, addr, pte, entry);
>> +??? spin_unlock(&init_mm.page_table_lock);
>> +}
>> +#endif
>> +
>> ? int __meminit vmemmap_populate(unsigned long start, unsigned long 
>> end, int node,
>> ????????? struct vmem_altmap *altmap)
>> ? {
> 


From wangjinchao at xfusion.com  Thu Dec 14 22:40:08 2023
From: wangjinchao at xfusion.com (Wang Jinchao)
Date: Fri, 15 Dec 2023 14:40:08 +0800
Subject: [PATCH] arm64: memory: remove duplicated include
Message-ID: <202312151439+0800-wangjinchao@xfusion.com>

remove duplicated include

Signed-off-by: Wang Jinchao <wangjinchao at xfusion.com>
---
 arch/arm64/include/asm/memory.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index fde4186cc387..27fc302a6d70 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -407,6 +407,5 @@ void dump_mem_limit(void);
 #define INIT_MEMBLOCK_MEMORY_REGIONS	(INIT_MEMBLOCK_REGIONS * 8)
 #endif
 
-#include <asm-generic/memory_model.h>
 
 #endif /* __ASM_MEMORY_H */
-- 
2.40.0



From adrian.hunter at intel.com  Thu Dec 14 22:42:42 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri, 15 Dec 2023 08:42:42 +0200
Subject: [PATCH RFC V3 4/4] coresight: Have a stab at support for pause / resume
In-Reply-To: <20231208172449.35444-5-adrian.hunter@intel.com>
References: <20231208172449.35444-5-adrian.hunter@intel.com>
Message-ID: <20231215064242.36251-1-adrian.hunter@intel.com>

For discussion only, un-tested...

Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
---


Changes in V3:

	'mode' -> 'flags' so it at least compiles


 .../hwtracing/coresight/coresight-etm-perf.c  | 29 ++++++++++++++++---
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 5ca6278baff4..7a69e6417ed4 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -45,6 +45,7 @@ static bool etm_perf_up;
 struct etm_ctxt {
 	struct perf_output_handle handle;
 	struct etm_event_data *event_data;
+	int pr_allowed;
 };
 
 static DEFINE_PER_CPU(struct etm_ctxt, etm_ctxt);
@@ -452,6 +453,13 @@ static void etm_event_start(struct perf_event *event, int flags)
 	struct list_head *path;
 	u64 hw_id;
 
+	if (flags & PERF_EF_RESUME) {
+		if (!READ_ONCE(ctxt->pr_allowed))
+			return;
+	} else if (READ_ONCE(event->aux_paused)) {
+		goto out_pr_allowed;
+	}
+
 	if (!csdev)
 		goto fail;
 
@@ -514,6 +522,8 @@ static void etm_event_start(struct perf_event *event, int flags)
 	event->hw.state = 0;
 	/* Save the event_data for this ETM */
 	ctxt->event_data = event_data;
+out_pr_allowed:
+	WRITE_ONCE(ctxt->pr_allowed, 1);
 	return;
 
 fail_disable_path:
@@ -530,6 +540,7 @@ static void etm_event_start(struct perf_event *event, int flags)
 	}
 fail:
 	event->hw.state = PERF_HES_STOPPED;
+	WRITE_ONCE(ctxt->pr_allowed, 0);
 	return;
 }
 
@@ -543,6 +554,11 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	struct etm_event_data *event_data;
 	struct list_head *path;
 
+	if (mode & PERF_EF_PAUSE && !READ_ONCE(ctxt->pr_allowed))
+		return;
+
+	WRITE_ONCE(ctxt->pr_allowed, 0);
+
 	/*
 	 * If we still have access to the event_data via handle,
 	 * confirm that we haven't messed up the tracking.
@@ -556,7 +572,7 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	ctxt->event_data = NULL;
 
 	if (event->hw.state == PERF_HES_STOPPED)
-		return;
+		goto out_pr_allowed;
 
 	/* We must have a valid event_data for a running event */
 	if (WARN_ON(!event_data))
@@ -627,6 +643,10 @@ static void etm_event_stop(struct perf_event *event, int mode)
 
 	/* Disabling the path make its elements available to other sessions */
 	coresight_disable_path(path);
+
+out_pr_allowed:
+	if (mode & PERF_EF_PAUSE)
+		WRITE_ONCE(ctxt->pr_allowed, 1);
 }
 
 static int etm_event_add(struct perf_event *event, int mode)
@@ -634,7 +654,7 @@ static int etm_event_add(struct perf_event *event, int mode)
 	int ret = 0;
 	struct hw_perf_event *hwc = &event->hw;
 
-	if (mode & PERF_EF_START) {
+	if (mode & PERF_EF_START && !READ_ONCE(event->aux_paused)) {
 		etm_event_start(event, 0);
 		if (hwc->state & PERF_HES_STOPPED)
 			ret = -EINVAL;
@@ -886,8 +906,9 @@ int __init etm_perf_init(void)
 {
 	int ret;
 
-	etm_pmu.capabilities		= (PERF_PMU_CAP_EXCLUSIVE |
-					   PERF_PMU_CAP_ITRACE);
+	etm_pmu.capabilities		= PERF_PMU_CAP_EXCLUSIVE |
+					  PERF_PMU_CAP_ITRACE |
+					  PERF_PMU_CAP_AUX_PAUSE;
 
 	etm_pmu.attr_groups		= etm_pmu_attr_groups;
 	etm_pmu.task_ctx_nr		= perf_sw_context;
-- 
2.34.1



From jiapeng.chong at linux.alibaba.com  Thu Dec 14 22:57:33 2023
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Fri, 15 Dec 2023 14:57:33 +0800
Subject: [PATCH] drm/rockchip: vop2: Remove the unused variable if_dclk_rate
Message-ID: <20231215065733.48895-1-jiapeng.chong@linux.alibaba.com>

Variable if_dclk_rate is not effectively used, so delete it.

drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:1688:16: warning: variable ?if_dclk_rate? set but not used.

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7750
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 44508c2dd614..b4e7cddaf25a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1685,13 +1685,11 @@ static unsigned long rk3588_calc_cru_cfg(struct vop2_video_port *vp, int id,
 	unsigned long dclk_core_rate = v_pixclk >> 2;
 	unsigned long dclk_rate = v_pixclk;
 	unsigned long dclk_out_rate;
-	unsigned long if_dclk_rate;
 	unsigned long if_pixclk_rate;
 	int K = 1;
 
 	if (vop2_output_if_is_hdmi(id)) {
 		/*
-		 * K = 2: dclk_core = if_pixclk_rate > if_dclk_rate
 		 * K = 1: dclk_core = hdmie_edp_dclk > if_pixclk_rate
 		 */
 		if (output_mode == ROCKCHIP_OUT_MODE_YUV420) {
@@ -1700,10 +1698,8 @@ static unsigned long rk3588_calc_cru_cfg(struct vop2_video_port *vp, int id,
 		}
 
 		if_pixclk_rate = (dclk_core_rate << 1) / K;
-		if_dclk_rate = dclk_core_rate / K;
 		/*
 		 * *if_pixclk_div = dclk_rate / if_pixclk_rate;
-		 * *if_dclk_div = dclk_rate / if_dclk_rate;
 		 */
 		 *if_pixclk_div = 2;
 		 *if_dclk_div = 4;
-- 
2.20.1.7.g153144c



From peter.wang at mediatek.com  Thu Dec 14 22:58:52 2023
From: peter.wang at mediatek.com (=?utf-8?B?UGV0ZXIgV2FuZyAo546L5L+h5Y+LKQ==?=)
Date: Fri, 15 Dec 2023 06:58:52 +0000
Subject: [PATCH V5 1/2] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231213124353.16407-2-quic_mnaresh@quicinc.com>
References: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
	 <20231213124353.16407-2-quic_mnaresh@quicinc.com>
Message-ID: <c00aeb47c67599d632cced1017696cf1295d83ea.camel@mediatek.com>

On Wed, 2023-12-13 at 18:13 +0530, Maramaina Naresh wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  Register ufs driver to CPU latency PM QoS framework to improve
> ufs device random io performance.
> 
> PM QoS initialization will insert new QoS request into the CPU
> latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
> value.
> 
> UFS driver will vote for performance mode on scale up and power
> save mode for scale down.
> 
> If clock scaling feature is not enabled then voting will be based
> on clock on or off condition.
> 
> Provided sysfs interface to enable/disable PM QoS feature.
> 
> tiotest benchmark tool io performance results on sm8550 platform:
> 
> 1. Without PM QoS support
> 	Type (Speed in)    | Average of 18 iterations
> 	Random Write(IPOS) | 41065.13
> 	Random Read(IPOS)  | 37101.3
> 
> 2. With PM QoS support
> 	Type (Speed in)    | Average of 18 iterations
> 	Random Write(IPOS) | 46784.9
> 	Random Read(IPOS)  | 42943.4
> (Improvement with PM QoS = ~15%).
> 

Reviewed-by: Peter Wang <peter.wang at mediatek.com>


From peter.wang at mediatek.com  Thu Dec 14 22:59:31 2023
From: peter.wang at mediatek.com (=?utf-8?B?UGV0ZXIgV2FuZyAo546L5L+h5Y+LKQ==?=)
Date: Fri, 15 Dec 2023 06:59:31 +0000
Subject: [PATCH V5 2/2] ufs: ufs-mediatek: Migrate to UFSHCD generic CPU
 latency PM QoS support
In-Reply-To: <20231213124353.16407-3-quic_mnaresh@quicinc.com>
References: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
	 <20231213124353.16407-3-quic_mnaresh@quicinc.com>
Message-ID: <f9085437f5ac76ef796f212e377b53da337d4213.camel@mediatek.com>

On Wed, 2023-12-13 at 18:13 +0530, Maramaina Naresh wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  The PM QoS feature found in the MediaTek UFS driver was moved to the
> UFSHCD
> core. Hence remove it from MediaTek UFS driver as it is redundant
> now.
> 
> 

Reviewed-by: Peter Wang <peter.wang at mediatek.com>


From amit.kumar-mahapatra at amd.com  Thu Dec 14 23:28:01 2023
From: amit.kumar-mahapatra at amd.com (Mahapatra, Amit Kumar)
Date: Fri, 15 Dec 2023 07:28:01 +0000
Subject: [PATCH v11 00/10] spi: Add support for stacked/parallel memories
In-Reply-To: <30ffd8378d3ef1c4fa6dfe4324b18345@walle.cc>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <30ffd8378d3ef1c4fa6dfe4324b18345@walle.cc>
Message-ID: <BN7PR12MB280267F8478681A1ED48A2D1DC93A@BN7PR12MB2802.namprd12.prod.outlook.com>

Hello Michael,

> -----Original Message-----
> From: Michael Walle <michael at walle.cc>
> Sent: Tuesday, December 12, 2023 6:05 PM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>
> Cc: broonie at kernel.org; tudor.ambarus at linaro.org; pratyush at kernel.org;
> miquel.raynal at bootlin.com; richard at nod.at; vigneshr at ti.com;
> sbinding at opensource.cirrus.com; lee at kernel.org;
> james.schulman at cirrus.com; david.rhodes at cirrus.com;
> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com; linux-
> spi at vger.kernel.org; linux-kernel at vger.kernel.org; linux-
> mtd at lists.infradead.org; nicolas.ferre at microchip.com;
> alexandre.belloni at bootlin.com; claudiu.beznea at tuxon.dev; Simek, Michal
> <michal.simek at amd.com>; linux-arm-kernel at lists.infradead.org; alsa-
> devel at alsa-project.org; patches at opensource.cirrus.com; linux-
> sound at vger.kernel.org; git (AMD-Xilinx) <git at amd.com>;
> amitrkcian2002 at gmail.com
> Subject: Re: [PATCH v11 00/10] spi: Add support for stacked/parallel
> memories
> 
> > This patch series updated the spi-nor, spi core and the AMD-Xilinx
> > GQSPI driver to add stacked and parallel memories support.
> 
> Honestly, I'm not thrilled about how this is implemented in the core and what
> the restrictions are.
> First, the pattern "if (n==1) then { old behavior } else { copy old code modify
> for n==2 }" is hard to maintain. There should be no copy and the old code
> shall be adapted to work for both n=1 and n>1.

Stacked mode serves as an extension of single device mode concerning data 
handling and CS line assertion. In both scenarios, the driver only asserts 
one CS line at any given time. The existing code has been expanded to 
determine the CS line to be asserted based on the requested address and 
data length. This modification accommodates both single (legacy) and 
stacked use cases.

In contrast, parallel mode differs from the legacy (single) mode in terms 
of data handling. In parallel mode, each byte of data is stored in both 
devices, with even bits in the lower flash and odd bits in the upper flash. 
During the transfer, multiple CS lines need to be asserted simultaneously. 
Consequently, special handling is necessary for parallel mode.

> 
> But I agree with Tudor, some kind of abstraction (layer) would be nice.

I agree too.

> 
> Also, you hardcode n=2 everywhere. Please generalize that one.
> 
> Are you aware of any other controller supporting such a feature? I've seen

Currently, I am familiar only with the AMD-Xilinx QSPI controllers that 
support parallel/stacked configurations and AMD-Xilinx OSPI controllers, 
which support stacked configuration. However, it's important to highlight 
certain aspects of these configurations. In parallel mode, each byte of 
data is stored in both flash devices, and the QSPI controller 
automatically handles the byte split and the simultaneous 
assertion/de-assertion of multiple CS lines. Hence, it can be stated that 
parallel operation is a controller feature, and other controllers wishing 
to operate flashes in parallel mode should be capable of data splitting 
and asserting multiple CS lines simultaneously. This characteristic might 
be specific to the AMD-Xilinx controller.

In contrast, in stacked mode, only one CS pin is asserted at any given 
time, determined by the memory address and the accessed data length. 
Stacked mode, unlike parallel mode, functions as a software abstraction.
Once implemented, any SPI controller with multiple CS lines or with a 
combination of native-CS and GPIO-CS can operate two or more flashes in 
stacked mode.

> you also need to modify the spi controller and intercept some commands.

Command interception occurs exclusively in parallel mode, not in stacked 
mode. In parallel mode, data must be split during flash memory read/write 
operations. However, during Flash register read/write operations, there 
should be no data split, as the identical data needs to be written to 
(or read from) the register of both flashes. Consequently, the driver has 
to intercept the command before activating the data split feature of the 
controller.

> Can everything be moved there?

In stacked mode, determining which flash device needs to be asserted is 
based on the flash address and the length of the requested data. This 
information is handled by the spi-nor core. If the operation spans across 
multiple flashes, the command, address, dummy (if required), and residual 
data must be issued to multiple flashes. This process should be carried 
out in the spi-nor core layer( or before spi-mem) and not in the driver.

 That is why > 
> I'm not sure we are implementing controller specific things in the core. Hard

As explained earlier the parallel mode of operation can be controller specific,
But the stacked mode is controller independent.

> to judge without seeing other controllers doing a similar thing. I'd like to avoid
> that.
> 
> If we had some kind of abstraction here, that might be easier to adapt in the
> future, but just putting everything into the core will make it really hard to
> maintain. So if everything related to stacked and parallel memory would be in
> drivers/mtd/spi-nor/stacked.c, we'd have at least everything in one place with
> a proper interface between that and the core.

I agree.

Regards
Amit
> 
> -michael


From macpaul.lin at mediatek.com  Thu Dec 14 23:32:52 2023
From: macpaul.lin at mediatek.com (Macpaul Lin)
Date: Fri, 15 Dec 2023 15:32:52 +0800
Subject: [PATCH] arm64: dts: mediatek: mt8395-genio-1200-evk: add interrupt-parent for mt6360
Message-ID: <20231215073252.21586-1-macpaul.lin@mediatek.com>

This patch fix the warning introduced by mt6360 node in
mt8395-genio-1200-evk.dts.

arch/arm64/boot/dts/mediatek/mt8195.dtsi:464.4-27: Warning (interrupts_property): /soc/i2c at 11d01000/pmic at 34:#interrupt-cells: size is (8), expected multiple of 16

Add a missing 'interrupt-parent' to fix this warning.

Fixes: f2b543a191b6 ("arm64: dts: mediatek: add device-tree for Genio 1200 EVK board")
Reported-by: Arnd Bergmann <arnd at arndb.de>
Link: https://lore.kernel.org/linux-devicetree/20231212214737.230115-1-arnd at kernel.org/
Signed-off-by: Macpaul Lin <macpaul.lin at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
index 70b465f7c6a7..00ac59a873e8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
@@ -238,6 +238,7 @@
 	mt6360: pmic at 34 {
 		compatible = "mediatek,mt6360";
 		reg = <0x34>;
+		interrupt-parent = <&pio>;
 		interrupts = <128 IRQ_TYPE_EDGE_FALLING>;
 		interrupt-names = "IRQB";
 		interrupt-controller;
-- 
2.18.0



From chunfeng.yun at mediatek.com  Thu Dec 14 23:34:30 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 15 Dec 2023 15:34:30 +0800
Subject: [PATCH v2 2/3] usb: xhci-mtk: fix a short packet issue of gen1 isoc-in transfer
In-Reply-To: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
References: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
Message-ID: <20231215073431.8512-2-chunfeng.yun@mediatek.com>

For Gen1 isoc-in transfer, host still send out unexpected ACK after device
finish the burst with a short packet, this will cause an exception on the
connected device, such as, a usb 4k camera.
It can be fixed by setting rxfifo depth less than 3, prefer to use 2 here,
the side-effect is that may cause performance drop about 10%, including
bulk transfer.

Fixes: 926d60ae64a6 ("usb: xhci-mtk: modify the SOF/ITP interval for mt8195")
Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2:
use 'rx-fifo-depth' property;
add header file 'linux/bitfield.h' to avoid building error on some ARCH;
---
 drivers/usb/host/xhci-mtk.c | 38 +++++++++++++++++++++++++++++++++++--
 drivers/usb/host/xhci-mtk.h |  2 ++
 2 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bbdf1b0b7be1..dad6c9873d79 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -7,6 +7,7 @@
  *  Chunfeng Yun <chunfeng.yun at mediatek.com>
  */
 
+#include <linux/bitfield.h>
 #include <linux/dma-mapping.h>
 #include <linux/iopoll.h>
 #include <linux/kernel.h>
@@ -73,6 +74,9 @@
 #define FRMCNT_LEV1_RANG	(0x12b << 8)
 #define FRMCNT_LEV1_RANG_MASK	GENMASK(19, 8)
 
+#define HSCH_CFG1		0x960
+#define SCH3_RXFIFO_DEPTH_MASK	GENMASK(21, 20)
+
 #define SS_GEN2_EOF_CFG		0x990
 #define SSG2EOF_OFFSET		0x3c
 
@@ -165,6 +169,34 @@ static void xhci_mtk_set_frame_interval(struct xhci_hcd_mtk *mtk)
 	writel(value, hcd->regs + SS_GEN2_EOF_CFG);
 }
 
+/*
+ * workaround: usb3.2 gen1 isoc rx hw issue
+ * host send out unexpected ACK afer device fininsh a burst transfer with
+ * a short packet.
+ */
+static void xhci_mtk_rxfifo_depth_set(struct xhci_hcd_mtk *mtk)
+{
+	struct usb_hcd *hcd = mtk->hcd;
+	u32 value;
+
+	if (mtk->rxfifo_depth < 0)
+		return;
+
+	value = readl(hcd->regs + HSCH_CFG1);
+	value &= ~SCH3_RXFIFO_DEPTH_MASK;
+	value |= FIELD_PREP(SCH3_RXFIFO_DEPTH_MASK, mtk->rxfifo_depth);
+	writel(value, hcd->regs + HSCH_CFG1);
+}
+
+static void xhci_mtk_init_quirk(struct xhci_hcd_mtk *mtk)
+{
+	/* workaround only for mt8195 */
+	xhci_mtk_set_frame_interval(mtk);
+
+	/* workaround for SoCs using SSUSB about before IPM v1.6.0 */
+	xhci_mtk_rxfifo_depth_set(mtk);
+}
+
 static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
 {
 	struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
@@ -448,8 +480,7 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
 		if (ret)
 			return ret;
 
-		/* workaround only for mt8195 */
-		xhci_mtk_set_frame_interval(mtk);
+		xhci_mtk_init_quirk(mtk);
 	}
 
 	ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
@@ -527,6 +558,9 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	of_property_read_u32(node, "mediatek,u2p-dis-msk",
 			     &mtk->u2p_dis_msk);
 
+	mtk->rxfifo_depth = -1;
+	of_property_read_u32(node, "rx-fifo-depth", &mtk->rxfifo_depth);
+
 	ret = usb_wakeup_of_property_parse(mtk, node);
 	if (ret) {
 		dev_err(dev, "failed to parse uwk property\n");
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 39f7ae7d3087..2d27bb0d3ecb 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -171,6 +171,8 @@ struct xhci_hcd_mtk {
 	struct regmap *uwk;
 	u32 uwk_reg_base;
 	u32 uwk_vers;
+
+	int rxfifo_depth;
 };
 
 static inline struct xhci_hcd_mtk *hcd_to_mtk(struct usb_hcd *hcd)
-- 
2.18.0



From krzysztof.kozlowski at linaro.org  Thu Dec 14 23:35:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 08:35:07 +0100
Subject: [PATCH v1 4/8] ARM: dts: aspeed: System1: Add i2c and muxes
In-Reply-To: <8cdadff2-055a-48ab-8495-45c8285d3d8f@linux.ibm.com>
References: <20231212164004.1683589-1-ninad@linux.ibm.com>
 <20231212164004.1683589-5-ninad@linux.ibm.com>
 <72a749b9-b9be-4496-9bcc-37519044c109@linaro.org>
 <8cdadff2-055a-48ab-8495-45c8285d3d8f@linux.ibm.com>
Message-ID: <66a211d8-de40-4827-9e84-b226545986c6@linaro.org>

On 14/12/2023 19:34, Ninad Palsule wrote:
>>>   	chosen {
>>>   		stdout-path = &uart5;
>>>   		bootargs = "console=ttyS4,115200n8 earlycon";
>>> @@ -54,10 +113,12 @@ vga_memory: region at bf000000 {
>>>   			reg = <0xbf000000 0x01000000>;  /* 16M */
>>>   		};
>>>   	};
>>> +
>> You need to clean your patchset...
> I made changes about the stdout-path, is that what you mean?

No, I meant you made irrelevant changes in this patch.

>>
>>
>>>   };
>>>   
>>>   &adc1 {
>>>   	status = "okay";
>>> +
>> Really.
> I need to add "status = okay" otherwise its not instantiated.

That was about blank line. How is it related to this patch "Add i2c and
muxes"?

Best regards,
Krzysztof



From chunfeng.yun at mediatek.com  Thu Dec 14 23:34:31 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 15 Dec 2023 15:34:31 +0800
Subject: [PATCH v2 3/3] arm64: dts: mediatek: mt8195: Add 'rx-fifo-depth' for cherry
In-Reply-To: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
References: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
Message-ID: <20231215073431.8512-3-chunfeng.yun@mediatek.com>

Add the quirk property "rx-fifo-depth" to work around Gen1 isoc-in
transfer issue which send out unexpected ACK even after device
already finished the burst transfer with a short patcket, specially
for a 4K camera device.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: use 'rx-fifo-depth' property
---
 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index dd5b89b73190..132baeab675e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -1185,6 +1185,7 @@
 
 	vusb33-supply = <&mt6359_vusb_ldo_reg>;
 	vbus-supply = <&usb_vbus>;
+	rx-fifo-depth = <2>;
 };
 
 &xhci1 {
@@ -1192,6 +1193,7 @@
 
 	vusb33-supply = <&mt6359_vusb_ldo_reg>;
 	vbus-supply = <&usb_vbus>;
+	rx-fifo-depth = <2>;
 };
 
 &xhci2 {
-- 
2.18.0



From krzysztof.kozlowski at linaro.org  Thu Dec 14 23:36:45 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 08:36:45 +0100
Subject: [PATCH v2 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
References: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
Message-ID: <d50abf1a-1ee7-4f84-9f53-69dfe9aad103@linaro.org>

On 15/12/2023 08:34, Chunfeng Yun wrote:
> For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
> still send out unexpected ACK after receiving a short packet in burst
> transfer, this will cause an exception on connected device, specially for
> a 4k camera.
> Add a quirk property "rx-fifo-depth" to work around this hardware issue,
> prefer to use 2;
> The side-effect is that may cause performance drop about 10%, including
> bulk transfer.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
> v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
> ---
>  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> index e9644e333d78..e44a71acb5c0 100644
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> @@ -124,6 +124,18 @@ properties:
>        defined in the xHCI spec on MTK's controller.
>      default: 5000
>  
> +  rx-fifo-depth:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      It is a quirk used to work around Gen1 isoc-in endpoint transfer issue
> +      that still send out unexpected ACK after device finish the burst transfer
> +      with a short packet and cause an exception, specially on a 4K camera
> +      device, it happens on controller before about IPM v1.6.0; the side-effect
> +      is that may cause performance drop about 10%, include bulk transfer,
> +      prefer to use 2 here.

What is the meaning of 0-3? bytes? words?

> +    minimum: 0
> +    maximum: 3


Best regards,
Krzysztof



From macpaul.lin at mediatek.com  Thu Dec 14 23:42:08 2023
From: macpaul.lin at mediatek.com (Macpaul Lin)
Date: Fri, 15 Dec 2023 15:42:08 +0800
Subject: [PATCH] arm64: mediatek: remove broken pmic interrupt property
In-Reply-To: <1ce43346-3f60-b614-cdcc-7d9db8dec758@mediatek.com>
References: <20231212214737.230115-1-arnd@kernel.org>
 <bc5dafe4-5487-4794-97f1-f4e4d967a665@collabora.com>
 <1ce43346-3f60-b614-cdcc-7d9db8dec758@mediatek.com>
Message-ID: <6a0bc9c2-a9c6-5842-b66a-f9f020bf3aa3@mediatek.com>

On 12/15/23 01:54, Macpaul Lin wrote:
> On 12/13/23 19:09, AngeloGioacchino Del Regno wrote:
>
>> Il 12/12/23 22:47, Arnd Bergmann ha scritto:
>>> From: Arnd Bergmann <arnd at arndb.de>
>>>
>>> The pmic is connected to the GIC, which uses four-cell interrupt 
>>> properties,
>>> but its interrupt is specified as two-cell that would only make 
>>> sense for
>>> the GPIO irqchip:
>>>
>>> arch/arm64/boot/dts/mediatek/mt8195.dtsi:464.4-27: Warning 
>>> (interrupts_property): /soc/i2c at 11d01000/pmic at 34:#interrupt-cells: 
>>> size is (8), expected multiple of 16
>>>
>>> Remove the interrupt for now to shut up the warning. When someone 
>>> figures out
>>> what the correct interrupt and parent are, we can add it back.
>>>
>>
>> Please, can anyone from MediaTek comment on that?
>
> Sorry for late response, I've just stuck in other tasks and didn't 
> notice this
>
> patch is for genio-1200-evk. I've tested 6.7-rc1 but I thought it 
> might be an issue
>
> in origin mt8195.dtsi and not be related to board dts.
>
>> I see a mt6360_pins on PIO:
>> ??????????? pinmux = <PINMUX_GPIO17__FUNC_GPIO17>,
>> ???????????????? <PINMUX_GPIO128__FUNC_GPIO128>;
>>
>> ...and that's GPIO128, which may effectively be the IRQ pin for MT6360.
>>
>> Still, I'm not sure whether the interrupt is on GIC or PIO, please 
>> clarify,
>> otherwise we will have to get this commit upstream.
>>
> I think it could be solved by adding
>
> 'interrupt-parent = <&pio>;' to mt6360 node.
>
> But currently I have no much time to verify it.
>
> I'll try to find some time to find out the solution tomorrow.
>
>> Thanks,
>> Angelo
>>
>>> Fixes: f2b543a191b6 ("arm64: dts: mediatek: add device-tree for 
>>> Genio 1200 EVK board")
>>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>>> ---
>>> ? arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts | 2 --
>>> ? 1 file changed, 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts 
>>> b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
>>> index 70b465f7c6a7..a409ef998746 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts
>>> @@ -238,8 +238,6 @@ &i2c6 {
>>> ????? mt6360: pmic at 34 {
>>> ????????? compatible = "mediatek,mt6360";
>>> ????????? reg = <0x34>;
>>> -??????? interrupts = <128 IRQ_TYPE_EDGE_FALLING>;
>>> -??????? interrupt-names = "IRQB";
>>> ????????? interrupt-controller;
>>> ????????? #interrupt-cells = <1>;
>>> ????????? pinctrl-0 = <&mt6360_pins>;
>>
>
> Thanks for pointing out the issue! Let's see if it could be solved by 
> adding 'interrupt-parents'.
>
> Macpaul Lin

I've send a patch to add 'interrupt-parent' for mt6360 and tested with 
my local kernel-6.7-rc1.

Link: 
https://lore.kernel.org/linux-devicetree/20231215073252.21586-1-macpaul.lin at mediatek.com/

Thanks for Angelo , Arnd, and Chen-yu's reminding.

Best regards,

Macpaul Lin



From chunfeng.yun at mediatek.com  Thu Dec 14 23:34:29 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 15 Dec 2023 15:34:29 +0800
Subject: [PATCH v2 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1 isoc-in transfer issue
Message-ID: <20231215073431.8512-1-chunfeng.yun@mediatek.com>

For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
still send out unexpected ACK after receiving a short packet in burst
transfer, this will cause an exception on connected device, specially for
a 4k camera.
Add a quirk property "rx-fifo-depth" to work around this hardware issue,
prefer to use 2;
The side-effect is that may cause performance drop about 10%, including
bulk transfer.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
---
 .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index e9644e333d78..e44a71acb5c0 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -124,6 +124,18 @@ properties:
       defined in the xHCI spec on MTK's controller.
     default: 5000
 
+  rx-fifo-depth:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      It is a quirk used to work around Gen1 isoc-in endpoint transfer issue
+      that still send out unexpected ACK after device finish the burst transfer
+      with a short packet and cause an exception, specially on a 4K camera
+      device, it happens on controller before about IPM v1.6.0; the side-effect
+      is that may cause performance drop about 10%, include bulk transfer,
+      prefer to use 2 here.
+    minimum: 0
+    maximum: 3
+
   # the following properties are only used for case 1
   wakeup-source:
     description: enable USB remote wakeup, see power/wakeup-source.txt
-- 
2.18.0



From amit.kumar-mahapatra at amd.com  Thu Dec 14 23:55:25 2023
From: amit.kumar-mahapatra at amd.com (Mahapatra, Amit Kumar)
Date: Fri, 15 Dec 2023 07:55:25 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <c3fa1e04-92ed-48ab-a509-98e43abd5cd6@linaro.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
 <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <c3fa1e04-92ed-48ab-a509-98e43abd5cd6@linaro.org>
Message-ID: <BN7PR12MB2802E87F1A6CD22D904CAEACDC93A@BN7PR12MB2802.namprd12.prod.outlook.com>

Hello Tudor,

> -----Original Message-----
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> Sent: Tuesday, December 12, 2023 8:33 PM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> michael at walle.cc; linux-mtd at lists.infradead.org;
> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
> in spi-nor
> 
> 
> 
> On 12/11/23 13:37, Mahapatra, Amit Kumar wrote:
> 
> Hi!
> 
> cut
> 
> >>>>>>>  drivers/mtd/spi-nor/core.c  | 272
> >>>>>>> +++++++++++++++++++++++++++++-----
> >>>> --
> >>>>>>>  drivers/mtd/spi-nor/core.h  |   4 +
> >>>>>>>  include/linux/mtd/spi-nor.h |  15 +-
> >>>>>>>  3 files changed, 240 insertions(+), 51 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/mtd/spi-nor/core.c
> >>>>>>> b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6
> >>>>>>> 100644
> >>>>>>> --- a/drivers/mtd/spi-nor/core.c
> >>>>>>> +++ b/drivers/mtd/spi-nor/core.c
> >>>>>>
> >>>>>> cut
> >>>>>>
> >>>>>>> @@ -2905,7 +3007,10 @@ static void
> >>>>>>> spi_nor_init_fixup_flags(struct spi_nor *nor)  static int
> >>>>>>> spi_nor_late_init_params(struct spi_nor
> >>>>>>> *nor)  {
> >>>>>>>  	struct spi_nor_flash_parameter *params =
> >>>>>>> spi_nor_get_params(nor,
> >>>>>> 0);
> >>>>>>> -	int ret;
> >>>>>>> +	struct device_node *np = spi_nor_get_flash_node(nor);
> >>>>>>> +	u64 flash_size[SNOR_FLASH_CNT_MAX];
> >>>>>>> +	u32 idx = 0;
> >>>>>>> +	int rc, ret;
> >>>>>>>
> >>>>>>>  	if (nor->manufacturer && nor->manufacturer->fixups &&
> >>>>>>>  	    nor->manufacturer->fixups->late_init) { @@ -2937,6
> >>>>>>> +3042,44 @@ static int spi_nor_late_init_params(struct spi_nor
> *nor)
> >>>>>>>  	if (params->n_banks > 1)
> >>>>>>>  		params->bank_size = div64_u64(params->size,
> params-
> >>>> n_banks);
> >>>>>>>
> >>>>>>> +	nor->num_flash = 0;
> >>>>>>> +
> >>>>>>> +	/*
> >>>>>>> +	 * The flashes that are connected in stacked mode should be
> >> of
> >>>>>>> +same
> >>>>>> make.
> >>>>>>> +	 * Except the flash size all other properties are identical
> >>>>>>> +for all
> >> the
> >>>>>>> +	 * flashes connected in stacked mode.
> >>>>>>> +	 * The flashes that are connected in parallel mode should be
> >> identical.
> >>>>>>> +	 */
> >>>>>>> +	while (idx < SNOR_FLASH_CNT_MAX) {
> >>>>>>> +		rc = of_property_read_u64_index(np, "stacked-
> >> memories",
> >>>>>> idx,
> >>>>>>> +&flash_size[idx]);
> >>>>>>
> >>>>>> This is a little late in my opinion, as we don't have any sanity
> >>>>>> check on the flashes that are stacked on top of the first. We
> >>>>>> shall at least read and compare the ID for all.
> >>>>>
> >>>>> Alright, I will incorporate a sanity check for reading and
> >>>>> comparing the ID of the stacked flash. Subsequently, I believe
> >>>>> this stacked logic should be relocated to spi_nor_get_flash_info()
> >>>>> where we identify the first flash. Please share your thoughts on this.
> >>>>> Additionally, do you
> >>>>
> >>>> I'm wondering whether we can add a layer on top of the flash type
> >>>> to handle
> >>>
> >>> When you mention "on top," are you referring to incorporating it
> >>> into the MTD layer? Initially, Miquel had submitted this patch to
> >>> address
> >>
> >> I mean something above SPI MEM flashes, be it NOR, NANDs or whatever.
> >> Instead of treating the stacked flashes as a monolithic device and
> >> treat in SPI NOR some array of flashes, to have a layer above which
> >> probes the SPI MEM flash driver for each stacked flash. In your case
> >> SPI NOR would be probed twice, as you use 2 SPI NOR flashes.
> >>
> >>> stacked/parallel handling in the MTD layer.
> >>> https://lore.kernel.org/linux-mtd/20200114191052.0a16d116 at xps13/t/
> >>> However, the Device Tree bindings were initially not accepted.
> >>
> >> Okay, thanks for the pointer. I'll take a look.
> 
> haven't yet read the thread from above, but I skimmed over the AMD
> controller datasheet.
> 
> >>
> >>> Following a series of discussions, the below bindings were
> >>> eventually merged.
> >>> https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal at bo
> >>> ot
> >>> lin.com/
> >>
> >> I saw, thanks.
> >>
> >>>
> >>>> the stacked/parallel modes. This way everything will become flash
> >>>> type independent. Would it be possible to stack 2 SPI NANDs? How
> >>>> about a SPI NOR and a SPI NAND?
> >>>>
> >>>> Is the datasheet of the controller public?
> >>>
> >>> Yes,
> >>> https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Contr
> >>> ol
> >>> ler
> >>>
> >>
> >> Wonderful, I'll take a look. I see two clocks there. Does this mean
> >> that the stacked flashes can be operated at different frequencies? Do
> >> you know if we
> >
> > In stacked configuration, both flashes utilize a common clock (single
> > clock line). In a parallel setup, the flashes share the same clock but
> > have distinct clock lines. Please refer the diagrams in the sections
> > below for reference.
> > https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Inter
> > face-Diagrams
> 
> Thanks! Can you share with us what flashes you used for testing in the
> stacked and parallel configurations?

I used SPI-NOR QSPI flashes for testing stacked and parallel.

> 
> >> can combine a SPI NOR with a SPI NAND in stacked configuration?
> >
> > No, Xilinx/AMD QSPI controllers doesn't support this configuration.
> >
> 
> 2 SPI NANDs shall work with the AMD controller, right?

We never tested 2 SPI-NAND with AMD controller.
> 
> I skimmed over the QSPI controller datasheet and wondered why one would
> get complicated with 2 Quad Flashes when we have Octal. But then I saw that
> the same SoC can configure an Octal controller (the Octal and Quad
> controllers seems mutual exclusive) and that the Octal one can operate 2
> octal flashes in stacked mode :).

Thats correct .

Please let me know how you want me to proceed on this.

Regards,
Amit
> 
> Cheers,
> ta

From krzysztof.kozlowski at linaro.org  Thu Dec 14 23:58:42 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 08:58:42 +0100
Subject: [PATCH 04/13] dt-bindings: serial: samsung: gs101: make
 reg-io-width required property
In-Reply-To: <20231214105243.3707730-5-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-5-tudor.ambarus@linaro.org>
Message-ID: <8e3335dc-915c-4db2-8884-e16795e166de@linaro.org>

On 14/12/2023 11:52, Tudor Ambarus wrote:
> GS101 only allows 32-bit register accesses. When using 8-bit reg
> accesses on gs101, a SError Interrupt is raised causing the system
> unusable.
> 
> Make reg-io-width a required property and expect for it a value of 4.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 133259ed3a34..cc896d7e2a3d 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -143,6 +143,10 @@ allOf:
>      then:
>        required:
>          - samsung,uart-fifosize
> +        - reg-io-width
> +      properties:
> +        reg-io-width:
> +          const: 4

If all your ports are like this, then I say this is compatible-specific.
Make it here "reg-io-width: false" and set in the driver proper type in
s3c24xx_serial_init_port_default() (or new function).

Although maybe let's first resolve discussion of next patch.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec 15 00:01:03 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 09:01:03 +0100
Subject: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
In-Reply-To: <584e036a-2ae7-4b88-a517-8f79c6baed4a@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-6-tudor.ambarus@linaro.org>
 <1938fcf1-eb5d-4723-a6c6-d2fe2c6dd1c0@app.fastmail.com>
 <8808ceeb-35dc-4094-aec4-f43c7acd6174@linaro.org>
 <6962ac73-2f44-4c9e-8731-152087815454@app.fastmail.com>
 <584e036a-2ae7-4b88-a517-8f79c6baed4a@linaro.org>
Message-ID: <914b634d-444c-4eae-bc7e-0f20d0629470@linaro.org>

On 14/12/2023 15:31, Tudor Ambarus wrote:
> 
> 
> On 12/14/23 14:19, Arnd Bergmann wrote:
>> On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
>>> On 12/14/23 12:01, Arnd Bergmann wrote:
>>>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>>>
>>>
>>> It works if in device tree one specifies the reg-io-width property and
>>> sets it to 4. If the reg-io-width is not specified, the iotype defaults
>>> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
>>> unusable.
>>
>> In the case of incorrect DT data like a missing reg-io-width property,
>> I would expect it to still fail once the regular console or tty takes
>> over from earlycon.
>>
>>> Also, if the earlycon comes specified from the kernel params, the
>>> of_setup_earlycon() is no longer called and the earlycon will be set
>>> solely based on the kernel params buffer, thus allowing users to crash
>>> the kernel on wrong earlycon definitions.
>>
>> But that in turn is the same as specifying any other incorrect earlycon.
> 
> I don't think you can crash the kernel if you use other earlycon as you
> don't make accesses on the 32bit restricted bus. But I agree that if
> using the correct earlycon name, and mmio instead mmio32, is equivalent
> to not specifying reg-io-width in dt.
> 
>>
>>> If you think the change is fine, I can amend the commit message with the
>>> description from above.
>>
>> I'm still not convinced we need a special case here when everything else
>> just requires passing the correct data.

We shouldn't need any data from DT for this case, because this property
apparently can be inferred from the compatible. IOW, GS101 SoC requires
reg-io-width=4, everywhere, for each node, thus there is no need to
specify this property. It should be deduced from the compatible.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec 15 00:02:54 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 09:02:54 +0100
Subject: [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock
 controller
In-Reply-To: <CAPLW+4=bfcemh-dd7r9hOe0RbtC01+sNpj3ZMMfc8rMezKQfNA@mail.gmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-9-tudor.ambarus@linaro.org>
 <CAPLW+4=bfcemh-dd7r9hOe0RbtC01+sNpj3ZMMfc8rMezKQfNA@mail.gmail.com>
Message-ID: <90bc9243-5890-45e7-8bf5-80383c88980d@linaro.org>

On 14/12/2023 16:39, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>
>> Enable the cmu-peric0 clock controller. It feeds USI and I3c.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>> ---
>>  arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> index 9747cb3fa03a..d0b0ad70c6ba 100644
>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> @@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
>>                         };
>>                 };
>>
>> +               cmu_peric0: clock-controller at 10800000 {
>> +                       compatible = "google,gs101-cmu-peric0";
>> +                       reg = <0x10800000 0x4000>;
>> +                       #clock-cells = <1>;
>> +                       clocks = <&ext_24_5m>,
>> +                                <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
>> +                                <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
>> +                       clock-names = "oscclk",
>> +                                     "dout_cmu_peric0_bus",
> 
> I'd pull this line to the above line. Other than that:
> 

No, it's fine. If clocks span over multiple lines (one clock per line),
the names should follow in general. It's easier to read and match entries.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec 15 00:04:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 09:04:32 +0100
Subject: [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C
 configuration
In-Reply-To: <20231214105243.3707730-11-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-11-tudor.ambarus@linaro.org>
Message-ID: <11b4e79c-3d39-4924-877d-0f741e5904a8@linaro.org>

On 14/12/2023 11:52, Tudor Ambarus wrote:
> USI8 I2C is used to communicate with an eeprom found on the battery
> connector. Define USI8 in I2C configuration.
> 
> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
> selection of the protocol is intentionally left for the board dtsi file.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  arch/arm64/boot/dts/exynos/google/gs101.dtsi | 26 ++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index ffb7b4d89a8c..4ea1b180cd0a 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -354,6 +354,32 @@ pinctrl_peric0: pinctrl at 10840000 {
>  			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
>  		};
>  
> +		usi8: usi at 109700c0 {
> +			compatible = "google,gs101-usi",
> +				     "samsung,exynos850-usi";
> +			reg = <0x109700c0 0x20>;
> +			ranges;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
> +				 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
> +			clock-names = "pclk", "ipclk";
> +			samsung,sysreg = <&sysreg_peric0 0x101c>;
> +			status = "disabled";
> +
> +			hsi2c_8: i2c at 10970000 {
> +				compatible = "google,gs101-hsi2c",
> +					     "samsung,exynosautov9-hsi2c";
> +				reg = <0x10970000 0xc0>;
> +				interrupts = <GIC_SPI 642
> +					      IRQ_TYPE_LEVEL_HIGH 0>;

This can be in one line. Limit of 80 is not a hard-limit. It can be
violated if it improves readability. Especially if is about 1 character
only.



Best regards,
Krzysztof



From joro at 8bytes.org  Fri Dec 15 00:06:09 2023
From: joro at 8bytes.org (Joerg Roedel)
Date: Fri, 15 Dec 2023 09:06:09 +0100
Subject: [PATCH v2] dt-bindings: iommu: rockchip: Add Rockchip RK3588
In-Reply-To: <20231212005710.1837066-1-andyshrk@163.com>
References: <20231212005710.1837066-1-andyshrk@163.com>
Message-ID: <ZXwI8TzrvizvCC0f@8bytes.org>

On Tue, Dec 12, 2023 at 08:57:10AM +0800, Andy Yan wrote:
> Changes in v2:
> - Add maintainers for the iommu subsystem to cc list
> 
>  .../devicetree/bindings/iommu/rockchip,iommu.yaml     | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)

Applied, thanks.


From krzysztof.kozlowski at linaro.org  Fri Dec 15 00:07:36 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 09:07:36 +0100
Subject: [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on
 gs101-oriole
In-Reply-To: <CAPLW+4nTgam4jZ+s5m5E05jWO_kfSy=fMS0Ywp3yQEEn-UESbg@mail.gmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-12-tudor.ambarus@linaro.org>
 <CAPLW+4nTgam4jZ+s5m5E05jWO_kfSy=fMS0Ywp3yQEEn-UESbg@mail.gmail.com>
Message-ID: <c9ea0e9f-05d8-4def-8c68-6604c22763b9@linaro.org>

On 14/12/2023 16:55, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:53?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>
>> Enable the eeprom found on the battery connector.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>> ---
>>  .../boot/dts/exynos/google/gs101-oriole.dts    | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>> index 4a71f752200d..11b299d21c5d 100644
>> --- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>> @@ -63,6 +63,19 @@ &ext_200m {
>>         clock-frequency = <200000000>;
>>  };
>>
>> +&hsi2c_8 {
>> +       pinctrl-names = "default";
>> +       pinctrl-0 = <&hsi2c8_bus>;
>> +       #address-cells = <1>;
>> +       #size-cells = <0>;
> 
> Not sure if those 4 above properties belong in board's dts or in SoC's
> dtsi. Krzysztof, what do you think?

The cells should be in DTSI, because you cannot have an enabled i2c bus
without nodes in normal cases. The not-normal case is incomplete
description, which does not happen here.

The pinctrls I guess as well in DTSI, because you do not customize the
pins in the DTS. IOW, if the pinctrl nodes are coming from shared
pinctrl.DTSI, then pinctrl-0/names stay in DTSI as well.


Best regards,
Krzysztof



From tudor.ambarus at linaro.org  Fri Dec 15 00:09:40 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Fri, 15 Dec 2023 10:09:40 +0200
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <BN7PR12MB2802E87F1A6CD22D904CAEACDC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
 <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <c3fa1e04-92ed-48ab-a509-98e43abd5cd6@linaro.org>
 <BN7PR12MB2802E87F1A6CD22D904CAEACDC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
Message-ID: <b3d3c457-a43b-478a-85b3-52558227d139@linaro.org>



On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
>> Thanks! Can you share with us what flashes you used for testing in the
>> stacked and parallel configurations?
> I used SPI-NOR QSPI flashes for testing stacked and parallel.

I got that, I wanted the flash name or device ID.

What I'm interested is if each flash is in its own package. Are they?

> 
>>>> can combine a SPI NOR with a SPI NAND in stacked configuration?
>>> No, Xilinx/AMD QSPI controllers doesn't support this configuration.
>>>
>> 2 SPI NANDs shall work with the AMD controller, right?
> We never tested 2 SPI-NAND with AMD controller.

I was asking because I think the stacked layer shall be SPI MEM generic,
and not particular to SPI NOR.

>> I skimmed over the QSPI controller datasheet and wondered why one would
>> get complicated with 2 Quad Flashes when we have Octal. But then I saw that
>> the same SoC can configure an Octal controller (the Octal and Quad
>> controllers seems mutual exclusive) and that the Octal one can operate 2
>> octal flashes in stacked mode ?.
> Thats correct .
> 
> Please let me know how you want me to proceed on this.

I got you. Still need to allocate more time on this.

Cheers,
ta


From krzysztof.kozlowski at linaro.org  Fri Dec 15 00:13:05 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 09:13:05 +0100
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate
 clock names
In-Reply-To: <20231214105243.3707730-2-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-2-tudor.ambarus@linaro.org>
Message-ID: <050c3119-0431-4400-9052-7a9c0ec67918@linaro.org>

On 14/12/2023 11:52, Tudor Ambarus wrote:
> The gs101 clock names are derived from the clock register names under
> some certain rules. In particular, for the gate clocks the following is
> documented and expected in the gs101 clock driver:
> 
>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
> 
>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC

I don't understand what it has to do with the bindings.

> 
> The CMU TOP gate clock names missed to include the required "CMU"
> differentiator which will cause name collisions with the gate clock names
> of other clock units. Fix the TOP gate clock names and include "CMU" in
> their name.

Neither here. Clock names are not related to defines.

> 
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  drivers/clk/samsung/clk-gs101.c          | 167 ++++++++++++-----------
>  include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------

I miss the point why bindings must be changed with driver.

Really, guys, we are milling the first GS101 patches for entire cycle.
Almost 3 months. The moment I merge bindings you tell me they are wrong.
Few days after merging them.


Best regards,
Krzysztof



From fabrice.gasnier at foss.st.com  Fri Dec 15 00:23:45 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Fri, 15 Dec 2023 09:23:45 +0100
Subject: [Linux-stm32] [PATCH] ARM: dts: stm32mp15x: Consolidate
 usbh_[eo]hci phy properties
In-Reply-To: <31a82fc0-814e-456d-83e2-a4daf111a648@foss.st.com>
References: <20231206083142.1476340-2-u.kleine-koenig@pengutronix.de>
 <20231206084853.q4dfbp5twpe235se@pengutronix.de>
 <31a82fc0-814e-456d-83e2-a4daf111a648@foss.st.com>
Message-ID: <34e78d6c-5a1e-4507-b827-15f74c02f758@foss.st.com>

On 12/14/23 17:14, Alexandre TORGUE wrote:
> Hi Uwe
> 
> On 12/6/23 09:48, Uwe Kleine-K?nig wrote:
>> Hello,
>>
>> On Wed, Dec 06, 2023 at 09:31:43AM +0100, Uwe Kleine-K?nig wrote:
>>> diff --git a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
>>> b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
>>> index 511113f2e399..704c0d0cfe5f 100644
>>> --- a/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
>>> +++ b/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi
>>> @@ -680,8 +680,6 @@ &usart3 {
>>> ? };
>>> ? ? &usbh_ehci {
>>> -??? phys = <&usbphyc_port0>;
>>> -??? status = "okay";
>>
>> the status property must be kept. I will wait a bit for further review
>> and then resend (unless this patch is picked up with this issue fixed
>> up).
> 
> Applied with the fix. First I had a small doubt about the patch as we
> can also choose usbphyc_port1 for USB host but as usbphyc_port0 remains
> always connected to the USB host then your patch makes completely sens.

Hi UWe, Alex,

I tested it, with the fix, on stm32mp157c-ev1 and stm32mp157c-dk2. You
can add my:
Tested-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>

Best Regards,
Fabrice
> 
> Regards
> Alex
> 
> 
>> Best regards
>> Uwe
>>
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32 at st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32


From devnull+xianwei.zhao.amlogic.com at kernel.org  Fri Dec 15 00:28:00 2023
From: devnull+xianwei.zhao.amlogic.com at kernel.org (Xianwei Zhao via B4 Relay)
Date: Fri, 15 Dec 2023 16:28:00 +0800
Subject: [PATCH] arm64: dts: amlogic: fix format for s4 uart node
Message-ID: <20231215-s4-dts-v1-1-7831ab6972be@amlogic.com>

From: Xianwei Zhao <xianwei.zhao at amlogic.com>

Aliases use lowercase letters and place status in end.

Signed-off-by: Xianwei Zhao <xianwei.zhao at amlogic.com>
---
 arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts | 4 ++--
 arch/arm64/boot/dts/amlogic/meson-s4.dtsi             | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
index 18789242f05f..983caddc409c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
@@ -15,7 +15,7 @@ / {
 	#size-cells = <2>;
 
 	aliases {
-		serial0 = &uart_B;
+		serial0 = &uart_b;
 	};
 
 	memory at 0 {
@@ -36,7 +36,7 @@ secmon_reserved: secmon at 5000000 {
 	};
 };
 
-&uart_B {
+&uart_b {
 	status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
index c6b524e1a1ee..ce90b35686a2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
@@ -455,14 +455,14 @@ nand: nand-controller at 8c800 {
 				status = "disabled";
 			};
 
-			uart_B: serial at 7a000 {
+			uart_b: serial at 7a000 {
 				compatible = "amlogic,meson-s4-uart",
 					     "amlogic,meson-ao-uart";
 				reg = <0x0 0x7a000 0x0 0x18>;
 				interrupts = <GIC_SPI 169 IRQ_TYPE_EDGE_RISING>;
-				status = "disabled";
 				clocks = <&xtal>, <&clkc_periphs CLKID_UART_B>, <&xtal>;
 				clock-names = "xtal", "pclk", "baud";
+				status = "disabled";
 			};
 
 			reset: reset-controller at 2000 {

---
base-commit: 078c5db2a961f674cc27c10f15d15949eece6a49
change-id: 20231211-s4-dts-4a1805bd56f0

Best regards,
-- 
Xianwei Zhao <xianwei.zhao at amlogic.com>



From alexandre.torgue at foss.st.com  Fri Dec 15 00:37:55 2023
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Fri, 15 Dec 2023 09:37:55 +0100
Subject: [PATCH v9 0/5] Add support for DCMIPP camera interface of
 STMicroelectronics STM32 SoC series
In-Reply-To: <20231127170828.1426117-1-alain.volmat@foss.st.com>
References: <20231127170828.1426117-1-alain.volmat@foss.st.com>
Message-ID: <afc15b94-ae98-4dc7-b522-2e69d7b6bb03@foss.st.com>

Hi Alain

On 11/27/23 18:08, Alain Volmat wrote:
> This patchset introduces support for Digital Camera Memory Interface
> Pixel Processor (DCMIPP) of STMicroelectronics STM32 SoC series.
> 
> This initial support implements a single capture pipe
> allowing RGB565, YUV, Y, RAW8 and JPEG capture with
> frame skipping, prescaling and cropping.
> 
> DCMIPP is exposed through 3 subdevices:
> - dcmipp_dump_parallel: parallel interface handling
> - dcmipp_dump_postproc: frame skipping, prescaling and cropping control
> - dcmipp_dump_capture: video device capture node
> 


Patches [4] & [5] applied on stm32-next.

Thanks
Alex


From boris.brezillon at collabora.com  Fri Dec 15 00:43:01 2023
From: boris.brezillon at collabora.com (Boris Brezillon)
Date: Fri, 15 Dec 2023 09:43:01 +0100
Subject: [PATCH v4 1/2] iommu: Allow passing custom allocators to pgtable drivers
Message-ID: <20231215084302.2484163-1-boris.brezillon@collabora.com>

This will be useful for GPU drivers who want to keep page tables in a
pool so they can:

- keep freed page tables in a free pool and speed-up upcoming page
  table allocations
- batch page table allocation instead of allocating one page at a time
- pre-reserve pages for page tables needed for map/unmap operations,
  to ensure map/unmap operations don't try to allocate memory in paths
  they're allowed to block or fail

It might also be valuable for other aspects of GPU and similar
use-cases, like fine-grained memory accounting and resource limiting.

We will extend the Arm LPAE format to support custom allocators in a
separate commit.

Signed-off-by: Boris Brezillon <boris.brezillon at collabora.com>
Reviewed-by: Steven Price <steven.price at arm.com>
Reviewed-by: Robin Murphy <robin.murphy at arm.com>
Reviewed-by: Gaurav Kohli <quic_gkohli at quicinc.com>
Tested-by: Gaurav Kohli <quic_gkohli at quicinc.com>
---
v4:
- Add Gaurav's R-b/T-b
v3:
- Add Robin R-b
- Move caps definition around
- Add extra constraints to the ->alloc() callback documentation
v2:
- Add Steven R-b
- Expand on possible use-cases for custom allocators
- Add a caps fields to io_pgtable_init_fns so we can simplify the
  check_custom_allocator() logic (Robin Murphy)
---
 drivers/iommu/io-pgtable.c | 23 +++++++++++++++++++++++
 include/linux/io-pgtable.h | 34 ++++++++++++++++++++++++++++++++++
 2 files changed, 57 insertions(+)

diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
index b843fcd365d2..8841c1487f00 100644
--- a/drivers/iommu/io-pgtable.c
+++ b/drivers/iommu/io-pgtable.c
@@ -34,6 +34,26 @@ io_pgtable_init_table[IO_PGTABLE_NUM_FMTS] = {
 #endif
 };
 
+static int check_custom_allocator(enum io_pgtable_fmt fmt,
+				  struct io_pgtable_cfg *cfg)
+{
+	/* No custom allocator, no need to check the format. */
+	if (!cfg->alloc && !cfg->free)
+		return 0;
+
+	/* When passing a custom allocator, both the alloc and free
+	 * functions should be provided.
+	 */
+	if (!cfg->alloc || !cfg->free)
+		return -EINVAL;
+
+	/* Make sure the format supports custom allocators. */
+	if (io_pgtable_init_table[fmt]->caps & IO_PGTABLE_CAP_CUSTOM_ALLOCATOR)
+		return 0;
+
+	return -EINVAL;
+}
+
 struct io_pgtable_ops *alloc_io_pgtable_ops(enum io_pgtable_fmt fmt,
 					    struct io_pgtable_cfg *cfg,
 					    void *cookie)
@@ -44,6 +64,9 @@ struct io_pgtable_ops *alloc_io_pgtable_ops(enum io_pgtable_fmt fmt,
 	if (fmt >= IO_PGTABLE_NUM_FMTS)
 		return NULL;
 
+	if (check_custom_allocator(fmt, cfg))
+		return NULL;
+
 	fns = io_pgtable_init_table[fmt];
 	if (!fns)
 		return NULL;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 25142a0e2fc2..86cf1f7ae389 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -100,6 +100,30 @@ struct io_pgtable_cfg {
 	const struct iommu_flush_ops	*tlb;
 	struct device			*iommu_dev;
 
+	/**
+	 * @alloc: Custom page allocator.
+	 *
+	 * Optional hook used to allocate page tables. If this function is NULL,
+	 * @free must be NULL too.
+	 *
+	 * Memory returned should be zeroed and suitable for dma_map_single() and
+	 * virt_to_phys().
+	 *
+	 * Not all formats support custom page allocators. Before considering
+	 * passing a non-NULL value, make sure the chosen page format supports
+	 * this feature.
+	 */
+	void *(*alloc)(void *cookie, size_t size, gfp_t gfp);
+
+	/**
+	 * @free: Custom page de-allocator.
+	 *
+	 * Optional hook used to free page tables allocated with the @alloc
+	 * hook. Must be non-NULL if @alloc is not NULL, must be NULL
+	 * otherwise.
+	 */
+	void (*free)(void *cookie, void *pages, size_t size);
+
 	/* Low-level data specific to the table format */
 	union {
 		struct {
@@ -241,16 +265,26 @@ io_pgtable_tlb_add_page(struct io_pgtable *iop,
 		iop->cfg.tlb->tlb_add_page(gather, iova, granule, iop->cookie);
 }
 
+/**
+ * enum io_pgtable_caps - IO page table backend capabilities.
+ */
+enum io_pgtable_caps {
+	/** @IO_PGTABLE_CAP_CUSTOM_ALLOCATOR: Backend accepts custom page table allocators. */
+	IO_PGTABLE_CAP_CUSTOM_ALLOCATOR = BIT(0),
+};
+
 /**
  * struct io_pgtable_init_fns - Alloc/free a set of page tables for a
  *                              particular format.
  *
  * @alloc: Allocate a set of page tables described by cfg.
  * @free:  Free the page tables associated with iop.
+ * @caps:  Combination of @io_pgtable_caps flags encoding the backend capabilities.
  */
 struct io_pgtable_init_fns {
 	struct io_pgtable *(*alloc)(struct io_pgtable_cfg *cfg, void *cookie);
 	void (*free)(struct io_pgtable *iop);
+	u32 caps;
 };
 
 extern struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s1_init_fns;
-- 
2.43.0



From boris.brezillon at collabora.com  Fri Dec 15 00:43:02 2023
From: boris.brezillon at collabora.com (Boris Brezillon)
Date: Fri, 15 Dec 2023 09:43:02 +0100
Subject: [PATCH v4 2/2] iommu: Extend LPAE page table format to support custom allocators
In-Reply-To: <20231215084302.2484163-1-boris.brezillon@collabora.com>
References: <20231215084302.2484163-1-boris.brezillon@collabora.com>
Message-ID: <20231215084302.2484163-2-boris.brezillon@collabora.com>

We need that in order to implement the VM_BIND ioctl in the GPU driver
targeting new Mali GPUs.

VM_BIND is about executing MMU map/unmap requests asynchronously,
possibly after waiting for external dependencies encoded as dma_fences.
We intend to use the drm_sched framework to automate the dependency
tracking and VM job dequeuing logic, but this comes with its own set
of constraints, one of them being the fact we are not allowed to
allocate memory in the drm_gpu_scheduler_ops::run_job() to avoid this
sort of deadlocks:

- VM_BIND map job needs to allocate a page table to map some memory
  to the VM. No memory available, so kswapd is kicked
- GPU driver shrinker backend ends up waiting on the fence attached to
  the VM map job or any other job fence depending on this VM operation.

With custom allocators, we will be able to pre-reserve enough pages to
guarantee the map/unmap operations we queued will take place without
going through the system allocator. But we can also optimize
allocation/reservation by not free-ing pages immediately, so any
upcoming page table allocation requests can be serviced by some free
page table pool kept at the driver level.

I might also be valuable for other aspects of GPU and similar
use-cases, like fine-grained memory accounting and resource limiting.

Signed-off-by: Boris Brezillon <boris.brezillon at collabora.com>
Reviewed-by: Steven Price <steven.price at arm.com>
Reviewed-by: Robin Murphy <robin.murphy at arm.com>
Reviewed-by: Gaurav Kohli <quic_gkohli at quicinc.com>
Tested-by: Gaurav Kohli <quic_gkohli at quicinc.com>
---
v4:
- Add Gaurav's R-b/T-b
v3:
- Don't pass __GFP_ZERO to the custom ->alloc() hook. Returning zeroed
  mem is partof the agreement between the io-pgtable and its user
- Add Robin R-b
v2:
- Add Steven R-b
- Expand on possible use-cases for custom allocators
---
 drivers/iommu/io-pgtable-arm.c | 55 ++++++++++++++++++++++++----------
 1 file changed, 39 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 72dcdd468cf3..f7828a7aad41 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -188,20 +188,28 @@ static dma_addr_t __arm_lpae_dma_addr(void *pages)
 }
 
 static void *__arm_lpae_alloc_pages(size_t size, gfp_t gfp,
-				    struct io_pgtable_cfg *cfg)
+				    struct io_pgtable_cfg *cfg,
+				    void *cookie)
 {
 	struct device *dev = cfg->iommu_dev;
 	int order = get_order(size);
-	struct page *p;
 	dma_addr_t dma;
 	void *pages;
 
 	VM_BUG_ON((gfp & __GFP_HIGHMEM));
-	p = alloc_pages_node(dev_to_node(dev), gfp | __GFP_ZERO, order);
-	if (!p)
+
+	if (cfg->alloc) {
+		pages = cfg->alloc(cookie, size, gfp);
+	} else {
+		struct page *p;
+
+		p = alloc_pages_node(dev_to_node(dev), gfp | __GFP_ZERO, order);
+		pages = p ? page_address(p) : NULL;
+	}
+
+	if (!pages)
 		return NULL;
 
-	pages = page_address(p);
 	if (!cfg->coherent_walk) {
 		dma = dma_map_single(dev, pages, size, DMA_TO_DEVICE);
 		if (dma_mapping_error(dev, dma))
@@ -220,18 +228,28 @@ static void *__arm_lpae_alloc_pages(size_t size, gfp_t gfp,
 out_unmap:
 	dev_err(dev, "Cannot accommodate DMA translation for IOMMU page tables\n");
 	dma_unmap_single(dev, dma, size, DMA_TO_DEVICE);
+
 out_free:
-	__free_pages(p, order);
+	if (cfg->free)
+		cfg->free(cookie, pages, size);
+	else
+		free_pages((unsigned long)pages, order);
+
 	return NULL;
 }
 
 static void __arm_lpae_free_pages(void *pages, size_t size,
-				  struct io_pgtable_cfg *cfg)
+				  struct io_pgtable_cfg *cfg,
+				  void *cookie)
 {
 	if (!cfg->coherent_walk)
 		dma_unmap_single(cfg->iommu_dev, __arm_lpae_dma_addr(pages),
 				 size, DMA_TO_DEVICE);
-	free_pages((unsigned long)pages, get_order(size));
+
+	if (cfg->free)
+		cfg->free(cookie, pages, size);
+	else
+		free_pages((unsigned long)pages, get_order(size));
 }
 
 static void __arm_lpae_sync_pte(arm_lpae_iopte *ptep, int num_entries,
@@ -373,13 +391,13 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, unsigned long iova,
 	/* Grab a pointer to the next level */
 	pte = READ_ONCE(*ptep);
 	if (!pte) {
-		cptep = __arm_lpae_alloc_pages(tblsz, gfp, cfg);
+		cptep = __arm_lpae_alloc_pages(tblsz, gfp, cfg, data->iop.cookie);
 		if (!cptep)
 			return -ENOMEM;
 
 		pte = arm_lpae_install_table(cptep, ptep, 0, data);
 		if (pte)
-			__arm_lpae_free_pages(cptep, tblsz, cfg);
+			__arm_lpae_free_pages(cptep, tblsz, cfg, data->iop.cookie);
 	} else if (!cfg->coherent_walk && !(pte & ARM_LPAE_PTE_SW_SYNC)) {
 		__arm_lpae_sync_pte(ptep, 1, cfg);
 	}
@@ -524,7 +542,7 @@ static void __arm_lpae_free_pgtable(struct arm_lpae_io_pgtable *data, int lvl,
 		__arm_lpae_free_pgtable(data, lvl + 1, iopte_deref(pte, data));
 	}
 
-	__arm_lpae_free_pages(start, table_size, &data->iop.cfg);
+	__arm_lpae_free_pages(start, table_size, &data->iop.cfg, data->iop.cookie);
 }
 
 static void arm_lpae_free_pgtable(struct io_pgtable *iop)
@@ -552,7 +570,7 @@ static size_t arm_lpae_split_blk_unmap(struct arm_lpae_io_pgtable *data,
 	if (WARN_ON(lvl == ARM_LPAE_MAX_LEVELS))
 		return 0;
 
-	tablep = __arm_lpae_alloc_pages(tablesz, GFP_ATOMIC, cfg);
+	tablep = __arm_lpae_alloc_pages(tablesz, GFP_ATOMIC, cfg, data->iop.cookie);
 	if (!tablep)
 		return 0; /* Bytes unmapped */
 
@@ -575,7 +593,7 @@ static size_t arm_lpae_split_blk_unmap(struct arm_lpae_io_pgtable *data,
 
 	pte = arm_lpae_install_table(tablep, ptep, blk_pte, data);
 	if (pte != blk_pte) {
-		__arm_lpae_free_pages(tablep, tablesz, cfg);
+		__arm_lpae_free_pages(tablep, tablesz, cfg, data->iop.cookie);
 		/*
 		 * We may race against someone unmapping another part of this
 		 * block, but anything else is invalid. We can't misinterpret
@@ -882,7 +900,7 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
 
 	/* Looking good; allocate a pgd */
 	data->pgd = __arm_lpae_alloc_pages(ARM_LPAE_PGD_SIZE(data),
-					   GFP_KERNEL, cfg);
+					   GFP_KERNEL, cfg, cookie);
 	if (!data->pgd)
 		goto out_free_data;
 
@@ -984,7 +1002,7 @@ arm_64_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
 
 	/* Allocate pgd pages */
 	data->pgd = __arm_lpae_alloc_pages(ARM_LPAE_PGD_SIZE(data),
-					   GFP_KERNEL, cfg);
+					   GFP_KERNEL, cfg, cookie);
 	if (!data->pgd)
 		goto out_free_data;
 
@@ -1059,7 +1077,7 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 		 << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_DEV));
 
 	data->pgd = __arm_lpae_alloc_pages(ARM_LPAE_PGD_SIZE(data), GFP_KERNEL,
-					   cfg);
+					   cfg, cookie);
 	if (!data->pgd)
 		goto out_free_data;
 
@@ -1080,26 +1098,31 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 }
 
 struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
+	.caps	= IO_PGTABLE_CAP_CUSTOM_ALLOCATOR,
 	.alloc	= arm_64_lpae_alloc_pgtable_s1,
 	.free	= arm_lpae_free_pgtable,
 };
 
 struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
+	.caps	= IO_PGTABLE_CAP_CUSTOM_ALLOCATOR,
 	.alloc	= arm_64_lpae_alloc_pgtable_s2,
 	.free	= arm_lpae_free_pgtable,
 };
 
 struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s1_init_fns = {
+	.caps	= IO_PGTABLE_CAP_CUSTOM_ALLOCATOR,
 	.alloc	= arm_32_lpae_alloc_pgtable_s1,
 	.free	= arm_lpae_free_pgtable,
 };
 
 struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s2_init_fns = {
+	.caps	= IO_PGTABLE_CAP_CUSTOM_ALLOCATOR,
 	.alloc	= arm_32_lpae_alloc_pgtable_s2,
 	.free	= arm_lpae_free_pgtable,
 };
 
 struct io_pgtable_init_fns io_pgtable_arm_mali_lpae_init_fns = {
+	.caps	= IO_PGTABLE_CAP_CUSTOM_ALLOCATOR,
 	.alloc	= arm_mali_lpae_alloc_pgtable,
 	.free	= arm_lpae_free_pgtable,
 };
-- 
2.43.0



From jason-jh.lin at mediatek.com  Thu Dec 14 23:00:26 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 15 Dec 2023 15:00:26 +0800
Subject: [PATCH v2 3/3] mailbox: mtk-cmdq: Add CMDQ driver support for mt8188
In-Reply-To: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
References: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
Message-ID: <20231215070026.2507-4-jason-jh.lin@mediatek.com>

Add CMDQ driver support for mt8188 by adding its compatible and
driver data in CMDQ driver.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/mailbox/mtk-cmdq-mailbox.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 39bf066d376e..27ff3a3ccf2f 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -735,6 +735,13 @@ static const struct gce_plat gce_plat_mt8186 = {
 	.gce_num = 1
 };
 
+static const struct gce_plat gce_plat_mt8188 = {
+	.thread_nr = 32,
+	.shift = 3,
+	.control_by_sw = true,
+	.gce_num = 2
+};
+
 static const struct gce_plat gce_plat_mt8192 = {
 	.thread_nr = 24,
 	.shift = 3,
@@ -754,6 +761,7 @@ static const struct of_device_id cmdq_of_ids[] = {
 	{.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_mt8173},
 	{.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_mt8183},
 	{.compatible = "mediatek,mt8186-gce", .data = (void *)&gce_plat_mt8186},
+	{.compatible = "mediatek,mt8188-gce", .data = (void *)&gce_plat_mt8188},
 	{.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_mt8192},
 	{.compatible = "mediatek,mt8195-gce", .data = (void *)&gce_plat_mt8195},
 	{}
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 14 23:00:23 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 15 Dec 2023 15:00:23 +0800
Subject: [PATCH v2 0/3] Add CMDQ driver support for mt8188
Message-ID: <20231215070026.2507-1-jason-jh.lin@mediatek.com>

From: Jason-jh Lin <jason-jh.lin at mediatek.corp-partner.google.com>

Since mt8188 has 32 GCE HW thread, we nedd a new platform data to
support it.

So we sort the platform data in numerical order of compatible names and
add a new mt8188 platform data.

Change in v2:
Add a ptach to rename gce_plat variable postfix from 'v1~v7' to SoC names.

Jason-JH.Lin (3):
  mailbox: mtk-cmdq: Rename gce_plat variable with SoC name postfix
  mailbox: mtk-cmdq: Sort cmdq platform data by compatible name
  mailbox: mtk-cmdq: Add CMDQ driver support for mt8188

 drivers/mailbox/mtk-cmdq-mailbox.c | 44 ++++++++++++++++++------------
 1 file changed, 26 insertions(+), 18 deletions(-)

-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 14 23:00:25 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 15 Dec 2023 15:00:25 +0800
Subject: [PATCH v2 2/3] mailbox: mtk-cmdq: Sort cmdq platform data by compatible name
In-Reply-To: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
References: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
Message-ID: <20231215070026.2507-3-jason-jh.lin@mediatek.com>

Sort cmdq platform data according to the number sequence of
compatible names.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/mailbox/mtk-cmdq-mailbox.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 16c504f8d9d5..39bf066d376e 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -706,6 +706,13 @@ static const struct dev_pm_ops cmdq_pm_ops = {
 			   cmdq_runtime_resume, NULL)
 };
 
+static const struct gce_plat gce_plat_mt6779 = {
+	.thread_nr = 24,
+	.shift = 3,
+	.control_by_sw = false,
+	.gce_num = 1
+};
+
 static const struct gce_plat gce_plat_mt8173 = {
 	.thread_nr = 16,
 	.shift = 0,
@@ -720,10 +727,11 @@ static const struct gce_plat gce_plat_mt8183 = {
 	.gce_num = 1
 };
 
-static const struct gce_plat gce_plat_mt6779 = {
+static const struct gce_plat gce_plat_mt8186 = {
 	.thread_nr = 24,
 	.shift = 3,
-	.control_by_sw = false,
+	.control_by_sw = true,
+	.sw_ddr_en = true,
 	.gce_num = 1
 };
 
@@ -741,19 +749,11 @@ static const struct gce_plat gce_plat_mt8195 = {
 	.gce_num = 2
 };
 
-static const struct gce_plat gce_plat_mt8186 = {
-	.thread_nr = 24,
-	.shift = 3,
-	.control_by_sw = true,
-	.sw_ddr_en = true,
-	.gce_num = 1
-};
-
 static const struct of_device_id cmdq_of_ids[] = {
+	{.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_mt6779},
 	{.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_mt8173},
 	{.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_mt8183},
 	{.compatible = "mediatek,mt8186-gce", .data = (void *)&gce_plat_mt8186},
-	{.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_mt6779},
 	{.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_mt8192},
 	{.compatible = "mediatek,mt8195-gce", .data = (void *)&gce_plat_mt8195},
 	{}
-- 
2.18.0



From piotr.firek at financialflows.pl  Fri Dec 15 00:50:36 2023
From: piotr.firek at financialflows.pl (Piotr Firek)
Date: Fri, 15 Dec 2023 08:50:36 GMT
Subject: =?UTF-8?Q?Prosz=C4=99_o_kontakt?=
Message-ID: <20231215074500-0.1.1l.8i4i.0.jw83ecaejj@financialflows.pl>

Dzie? dobry,

Czy jest mo?liwo?? nawi?zania wsp??pracy z Pa?stwem?

Z ch?ci? porozmawiam z osob? zajmuj?c? si? dzia?aniami zwi?zanymi ze sprzeda??.

Pomagamy skutecznie pozyskiwa? nowych klient?w.

Zapraszam do kontaktu.


Pozdrawiam
Piotr Firek


From jbrunet at baylibre.com  Fri Dec 15 00:41:59 2023
From: jbrunet at baylibre.com (Jerome Brunet)
Date: Fri, 15 Dec 2023 09:41:59 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
Message-ID: <1jedfnq1sx.fsf@starbuckisacylon.baylibre.com>


On Wed 13 Dec 2023 at 08:16, Maxime Ripard <mripard at kernel.org> wrote:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
>> Hello,
>> 
>> clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
>> that and don't check the return value. This series fixes the four users
>> that do error checking on the returned value and then makes function
>> return void.
>> 
>> Given that the changes to the drivers are simple and so merge conflicts
>> (if any) should be easy to handle, I suggest to merge this complete
>> series via the clk tree.
>
> I don't think it's the right way to go about it.
>
> clk_rate_exclusive_get() should be expected to fail.

Yes, at some point it might. That is why the API returns an error code.
What CCF (or any other framework) should be no concern to the consummer.

Driver not checking the return are taking there chances, and that is up
to them. It is like regmap. Most calls can return an error code but the
vast majority of driver happily ignore that.

> For example if
> there's another user getting an exclusive rate on the same clock.
>
> If we're not checking for it right now, then it should probably be
> fixed, but the callers checking for the error are right to do so if they
> rely on an exclusive rate. It's the ones that don't that should be
> modified.
>

I'm not sure that would be right. For sure, restricting a to single user
was not my intent when I wrote the thing.

The intent was for a consumer to state that it cannot tolerate a rate
change of the clock it is using. It is fine for several consumers to
state that for a single clock, as long as they 'agree' on the rate. Two
instances of the same device could be a good example of that.

Those consumers should use 'clk_set_rate_exclusive()' to set the rate
and protect it atomically. Calling 'clk_exclusive_get()' then
'clk_set_rate()' is racy as both instance could effectively lock the
rate without actually getting the rate they want :/

Admittingly, the API naming is terrible when it comes to this ...

> Maxime
>
> [[End of PGP Signed Part]]


-- 
Jerome


From jason-jh.lin at mediatek.com  Thu Dec 14 23:00:24 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 15 Dec 2023 15:00:24 +0800
Subject: [PATCH v2 1/3] mailbox: mtk-cmdq: Rename gce_plat variable with SoC name postfix
In-Reply-To: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
References: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
Message-ID: <20231215070026.2507-2-jason-jh.lin@mediatek.com>

Rename gce_plat variable postfix from 'v1~v7' to SoC names.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/mailbox/mtk-cmdq-mailbox.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index de862e9137d5..16c504f8d9d5 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -706,42 +706,42 @@ static const struct dev_pm_ops cmdq_pm_ops = {
 			   cmdq_runtime_resume, NULL)
 };
 
-static const struct gce_plat gce_plat_v2 = {
+static const struct gce_plat gce_plat_mt8173 = {
 	.thread_nr = 16,
 	.shift = 0,
 	.control_by_sw = false,
 	.gce_num = 1
 };
 
-static const struct gce_plat gce_plat_v3 = {
+static const struct gce_plat gce_plat_mt8183 = {
 	.thread_nr = 24,
 	.shift = 0,
 	.control_by_sw = false,
 	.gce_num = 1
 };
 
-static const struct gce_plat gce_plat_v4 = {
+static const struct gce_plat gce_plat_mt6779 = {
 	.thread_nr = 24,
 	.shift = 3,
 	.control_by_sw = false,
 	.gce_num = 1
 };
 
-static const struct gce_plat gce_plat_v5 = {
+static const struct gce_plat gce_plat_mt8192 = {
 	.thread_nr = 24,
 	.shift = 3,
 	.control_by_sw = true,
 	.gce_num = 1
 };
 
-static const struct gce_plat gce_plat_v6 = {
+static const struct gce_plat gce_plat_mt8195 = {
 	.thread_nr = 24,
 	.shift = 3,
 	.control_by_sw = true,
 	.gce_num = 2
 };
 
-static const struct gce_plat gce_plat_v7 = {
+static const struct gce_plat gce_plat_mt8186 = {
 	.thread_nr = 24,
 	.shift = 3,
 	.control_by_sw = true,
@@ -750,12 +750,12 @@ static const struct gce_plat gce_plat_v7 = {
 };
 
 static const struct of_device_id cmdq_of_ids[] = {
-	{.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_v2},
-	{.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_v3},
-	{.compatible = "mediatek,mt8186-gce", .data = (void *)&gce_plat_v7},
-	{.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
-	{.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_v5},
-	{.compatible = "mediatek,mt8195-gce", .data = (void *)&gce_plat_v6},
+	{.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_mt8173},
+	{.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_mt8183},
+	{.compatible = "mediatek,mt8186-gce", .data = (void *)&gce_plat_mt8186},
+	{.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_mt6779},
+	{.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_mt8192},
+	{.compatible = "mediatek,mt8195-gce", .data = (void *)&gce_plat_mt8195},
 	{}
 };
 
-- 
2.18.0



From Avri.Altman at wdc.com  Fri Dec 15 01:05:33 2023
From: Avri.Altman at wdc.com (Avri Altman)
Date: Fri, 15 Dec 2023 09:05:33 +0000
Subject: [PATCH V5 0/2] Add CPU latency QoS support for ufs driver
In-Reply-To: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
References: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
Message-ID: <DM6PR04MB657594F8BFE75A8F68855A2EFC93A@DM6PR04MB6575.namprd04.prod.outlook.com>

> Add CPU latency QoS support for ufs driver. This improves random io
> performance by 15% for ufs.
> 
> tiotest benchmark tool io performance results on sm8550 platform:
Will it possible to provide test results for non-ufs4.0 platforms?
e.g. for SM8250, just to know if it would make sense to backport this to earlier releases.

Thanks,
Avri


From ck.hu at mediatek.com  Fri Dec 15 01:06:59 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Fri, 15 Dec 2023 09:06:59 +0000
Subject: [PATCH v2 2/3] mailbox: mtk-cmdq: Sort cmdq platform data by
 compatible name
In-Reply-To: <20231215070026.2507-3-jason-jh.lin@mediatek.com>
References: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
	 <20231215070026.2507-3-jason-jh.lin@mediatek.com>
Message-ID: <197c7760f889e1a50074afc503c5346454f0c340.camel@mediatek.com>

On Fri, 2023-12-15 at 15:00 +0800, Jason-JH.Lin wrote:
> Sort cmdq platform data according to the number sequence of
> compatible names.

Reviewed-by: CK Hu <ck.hu at mediatek.com>

> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  drivers/mailbox/mtk-cmdq-mailbox.c | 22 +++++++++++-----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 16c504f8d9d5..39bf066d376e 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -706,6 +706,13 @@ static const struct dev_pm_ops cmdq_pm_ops = {
>  			   cmdq_runtime_resume, NULL)
>  };
>  
> +static const struct gce_plat gce_plat_mt6779 = {
> +	.thread_nr = 24,
> +	.shift = 3,
> +	.control_by_sw = false,
> +	.gce_num = 1
> +};
> +
>  static const struct gce_plat gce_plat_mt8173 = {
>  	.thread_nr = 16,
>  	.shift = 0,
> @@ -720,10 +727,11 @@ static const struct gce_plat gce_plat_mt8183 =
> {
>  	.gce_num = 1
>  };
>  
> -static const struct gce_plat gce_plat_mt6779 = {
> +static const struct gce_plat gce_plat_mt8186 = {
>  	.thread_nr = 24,
>  	.shift = 3,
> -	.control_by_sw = false,
> +	.control_by_sw = true,
> +	.sw_ddr_en = true,
>  	.gce_num = 1
>  };
>  
> @@ -741,19 +749,11 @@ static const struct gce_plat gce_plat_mt8195 =
> {
>  	.gce_num = 2
>  };
>  
> -static const struct gce_plat gce_plat_mt8186 = {
> -	.thread_nr = 24,
> -	.shift = 3,
> -	.control_by_sw = true,
> -	.sw_ddr_en = true,
> -	.gce_num = 1
> -};
> -
>  static const struct of_device_id cmdq_of_ids[] = {
> +	{.compatible = "mediatek,mt6779-gce", .data = (void
> *)&gce_plat_mt6779},
>  	{.compatible = "mediatek,mt8173-gce", .data = (void
> *)&gce_plat_mt8173},
>  	{.compatible = "mediatek,mt8183-gce", .data = (void
> *)&gce_plat_mt8183},
>  	{.compatible = "mediatek,mt8186-gce", .data = (void
> *)&gce_plat_mt8186},
> -	{.compatible = "mediatek,mt6779-gce", .data = (void
> *)&gce_plat_mt6779},
>  	{.compatible = "mediatek,mt8192-gce", .data = (void
> *)&gce_plat_mt8192},
>  	{.compatible = "mediatek,mt8195-gce", .data = (void
> *)&gce_plat_mt8195},
>  	{}

From brgl at bgdev.pl  Fri Dec 15 01:09:43 2023
From: brgl at bgdev.pl (Bartosz Golaszewski)
Date: Fri, 15 Dec 2023 10:09:43 +0100
Subject: [PATCH] gpio: xilinx: remove excess kernel doc
Message-ID: <20231215090943.9245-1-brgl@bgdev.pl>

From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>

The irqchip field has been removed from struct xgpio_instance so remove
the doc as well.

Fixes: b4510f8fd5d0 ("gpio: xilinx: Convert to immutable irq_chip")
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312150239.IyuTVvrL-lkp at intel.com/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
---
 drivers/gpio/gpio-xilinx.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 823198368250..7348df385198 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -52,7 +52,6 @@
  * @dir: GPIO direction shadow register
  * @gpio_lock: Lock used for synchronization
  * @irq: IRQ used by GPIO device
- * @irqchip: IRQ chip
  * @enable: GPIO IRQ enable/disable bitfield
  * @rising_edge: GPIO IRQ rising edge enable/disable bitfield
  * @falling_edge: GPIO IRQ falling edge enable/disable bitfield
-- 
2.40.1



From ck.hu at mediatek.com  Fri Dec 15 01:09:55 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Fri, 15 Dec 2023 09:09:55 +0000
Subject: [PATCH v2 3/3] mailbox: mtk-cmdq: Add CMDQ driver support for
 mt8188
In-Reply-To: <20231215070026.2507-4-jason-jh.lin@mediatek.com>
References: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
	 <20231215070026.2507-4-jason-jh.lin@mediatek.com>
Message-ID: <7f2d0d718397c599327e7a76a7b5b638f96133f2.camel@mediatek.com>

On Fri, 2023-12-15 at 15:00 +0800, Jason-JH.Lin wrote:
> Add CMDQ driver support for mt8188 by adding its compatible and
> driver data in CMDQ driver.

Reviewed-by: CK Hu <ck.hu at mediatek.com>

> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  drivers/mailbox/mtk-cmdq-mailbox.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 39bf066d376e..27ff3a3ccf2f 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -735,6 +735,13 @@ static const struct gce_plat gce_plat_mt8186 = {
>  	.gce_num = 1
>  };
>  
> +static const struct gce_plat gce_plat_mt8188 = {
> +	.thread_nr = 32,
> +	.shift = 3,
> +	.control_by_sw = true,
> +	.gce_num = 2
> +};
> +
>  static const struct gce_plat gce_plat_mt8192 = {
>  	.thread_nr = 24,
>  	.shift = 3,
> @@ -754,6 +761,7 @@ static const struct of_device_id cmdq_of_ids[] =
> {
>  	{.compatible = "mediatek,mt8173-gce", .data = (void
> *)&gce_plat_mt8173},
>  	{.compatible = "mediatek,mt8183-gce", .data = (void
> *)&gce_plat_mt8183},
>  	{.compatible = "mediatek,mt8186-gce", .data = (void
> *)&gce_plat_mt8186},
> +	{.compatible = "mediatek,mt8188-gce", .data = (void
> *)&gce_plat_mt8188},
>  	{.compatible = "mediatek,mt8192-gce", .data = (void
> *)&gce_plat_mt8192},
>  	{.compatible = "mediatek,mt8195-gce", .data = (void
> *)&gce_plat_mt8195},
>  	{}

From mripard at kernel.org  Fri Dec 15 01:11:16 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Fri, 15 Dec 2023 10:11:16 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <212239ae-60ab-46f3-a838-39a4d61091fe@linaro.org>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
 <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
 <212239ae-60ab-46f3-a838-39a4d61091fe@linaro.org>
Message-ID: <lpcmyqxmf24tuwt72uxb6vyk7y23ot5d3vtwhwe77uwonhynxu@khe2zzjjq7fg>

Hi Neil,

On Wed, Dec 13, 2023 at 05:44:28PM +0100, Neil Armstrong wrote:
> Le 13/12/2023 ? 09:36, Maxime Ripard a ?crit?:
> > On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
> > > On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > > > On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> > > > > clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> > > > > that and don't check the return value. This series fixes the four users
> > > > > that do error checking on the returned value and then makes function
> > > > > return void.
> > > > > 
> > > > > Given that the changes to the drivers are simple and so merge conflicts
> > > > > (if any) should be easy to handle, I suggest to merge this complete
> > > > > series via the clk tree.
> > > > 
> > > > I don't think it's the right way to go about it.
> > > > 
> > > > clk_rate_exclusive_get() should be expected to fail. For example if
> > > > there's another user getting an exclusive rate on the same clock.
> > > > 
> > > > If we're not checking for it right now, then it should probably be
> > > > fixed, but the callers checking for the error are right to do so if they
> > > > rely on an exclusive rate. It's the ones that don't that should be
> > > > modified.
> > > 
> > > If some other consumer has already "locked" a clock that I call
> > > clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
> > > this function because I don't want the rate to change e.g. because I
> > > setup some registers in the consuming device to provide a fixed UART
> > > baud rate or i2c bus frequency (and that works as expected).
> > 
> > I guess it's a larger conversation, but I don't see how that can
> > possibly work.
> > 
> > The way the API is designed, you have no guarantee (outside of
> > clk_rate_exclusive_*) that the rate is going to change.
> > 
> > And clk_rate_exclusive_get() doesn't allow the rate to change while in
> > the "critical section".
> > 
> > So the only possible thing to do is clk_set_rate() +
> > clk_rate_exclusive_get().
> 
> There's clk_set_rate_exclusive() for this purpose.

Sure. But that assumes you'll never need to change the rate while in the
critical section.

> > So there's a window where the clock can indeed be changed, and the
> > consumer that is about to lock its rate wouldn't be aware of it.
> > 
> > I guess it would work if you don't care about the rate at all, you just
> > want to make sure it doesn't change.
> > 
> > Out of the 7 users of that function, 3 are in that situation, so I guess
> > it's fair.
> > 
> > 3 are open to that race condition I mentioned above.
> > 
> > 1 is calling clk_set_rate while in the critical section, which works if
> > there's a single user but not if there's multiple, so it should be
> > discouraged.
> > 
> > > In this case I won't be able to change the rate of the clock, but that
> > > is signalled by clk_set_rate() failing (iff and when I need awother
> > > rate) which also seems the right place to fail to me.
> > 
> > Which is ignored by like half the callers, including the one odd case I
> > mentioned above.
> > 
> > And that's super confusing still: you can *always* get exclusivity, but
> > not always do whatever you want with the rate when you have it? How are
> > drivers supposed to recover from that? You can handle failing to get
> > exclusivity, but certainly not working around variable guarantees.
> > 
> > > It's like that since clk_rate_exclusive_get() was introduced in 2017
> > > (commit 55e9b8b7b806ec3f9a8817e13596682a5981c19c).
> > 
> > Right, but "it's always been that way" surely can't be an argument,
> > otherwise you wouldn't have done that series in the first place.
> > 
> > > BTW, I just noticed that my assertion "Most users \"know\" that
> > > [clk_rate_exclusive_get() returns zero unconditionally]" is wrong. As of
> > > next-20231213 there are 3 callers ignoring the return value of
> > > clk_rate_exclusive_get() and 4 that handle (imaginary) returned errors.
> > > I expected this function to be used more extensively. (In fact I think
> > > it should be used more as several drivers rely on the clk rate not
> > > changing.)
> > 
> > Yes, but also it's super difficult to use in practice, and most devices
> > don't care.
> > 
> > The current situation is something like this:
> > 
> >    * Only a handful of devices really care about their clock rate, and
> >      often only for one of their clock if they have several. You would
> >      probably get all the devices that create an analog signal somehow
> >      there, so audio, display, i2c, spi, uarts, etc. Plus the ones doing
> >      frequency scaling so CPU and GPUs.
> > 
> >    * CPUs and GPUs are very likely to have a dedicated clock, so we can
> >      rule the "another user is going to mess with my clock" case.
> > 
> >    * UARTs/i2c/etc. are usually taking their clock from the bus interface
> >      directly which is pretty much never going to change (for good
> >      reason). And the rate of the bus is not really likely to change.
> > 
> >    * SPI/NAND/MMC usually have their dedicated clock too, and the bus
> >      rate is not likely to change after the initial setup either.
> > 
> > So, the only affected devices are the ones generating external signals,
> > with the rate changing during the life of the system. Even for audio or
> > video devices, that's fairly unlikely to happen. And you need to have
> > multiple devices sharing the same clock tree for that issue to occur,
> > which is further reducing the chances it happens.
> 
> Well, thanks for HW designers, this exists and some SoCs has less PLLs than
> needed, and they can't be dedicated for some hw blocks.
> 
> > 
> > Realistically speaking, this only occurs with multi-head display outputs
> > where it's somewhat likely to have all the display controllers feeding
> > from the same clock, and the power up of the various output is done in
> > sequence which creates that situation.
> > 
> > And even then, the clk_rate_exclusive_* interface effectively locks the
> > entire clock subtree to its current rate, so the effect on the rest of
> > the devices can be significant.
> > 
> > So... yeah. Even though you're right, it's trying to address a problem
> > that is super unlikely to happen with a pretty big hammer that might be
> > too much for most. So it's not really surprising it's not used more.
> 
> Honestly I tried my best to find a smart way to set the DSI clock tree
> with only 2 endpoints of the tree, but CCF will explore all possibilities
> and since you cannot set constraints, locking a sub-tree is the smartest
> way I found.
> In this case, the PLL is common between the DSI controller and video generator,
> so to keep the expected clock ratio, the smart way is to set the freq on
> one side, lock the subtree and set the rate on the other side.
> An API permitting to set multiple rates to multiple clocks in a single call
> would be the solution, but not sure if we could possibly write such algorithm.

Sure, and it's working great for some SoCs, so it was a good solution
for the problem you had at the time.

For some other SoCs it's not working that well however, so we need to
improve things for those.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/1999e6db/attachment.sig>

From ck.hu at mediatek.com  Fri Dec 15 01:06:20 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Fri, 15 Dec 2023 09:06:20 +0000
Subject: [PATCH v2 1/3] mailbox: mtk-cmdq: Rename gce_plat variable with
 SoC name postfix
In-Reply-To: <20231215070026.2507-2-jason-jh.lin@mediatek.com>
References: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
	 <20231215070026.2507-2-jason-jh.lin@mediatek.com>
Message-ID: <7a5b2c164c0c8dc6b1ac0742c6f3cf2b4a4ca7a6.camel@mediatek.com>

On Fri, 2023-12-15 at 15:00 +0800, Jason-JH.Lin wrote:
> Rename gce_plat variable postfix from 'v1~v7' to SoC names.

Reviewed-by: CK Hu <ck.hu at mediatek.com>

> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  drivers/mailbox/mtk-cmdq-mailbox.c | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index de862e9137d5..16c504f8d9d5 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -706,42 +706,42 @@ static const struct dev_pm_ops cmdq_pm_ops = {
>  			   cmdq_runtime_resume, NULL)
>  };
>  
> -static const struct gce_plat gce_plat_v2 = {
> +static const struct gce_plat gce_plat_mt8173 = {
>  	.thread_nr = 16,
>  	.shift = 0,
>  	.control_by_sw = false,
>  	.gce_num = 1
>  };
>  
> -static const struct gce_plat gce_plat_v3 = {
> +static const struct gce_plat gce_plat_mt8183 = {
>  	.thread_nr = 24,
>  	.shift = 0,
>  	.control_by_sw = false,
>  	.gce_num = 1
>  };
>  
> -static const struct gce_plat gce_plat_v4 = {
> +static const struct gce_plat gce_plat_mt6779 = {
>  	.thread_nr = 24,
>  	.shift = 3,
>  	.control_by_sw = false,
>  	.gce_num = 1
>  };
>  
> -static const struct gce_plat gce_plat_v5 = {
> +static const struct gce_plat gce_plat_mt8192 = {
>  	.thread_nr = 24,
>  	.shift = 3,
>  	.control_by_sw = true,
>  	.gce_num = 1
>  };
>  
> -static const struct gce_plat gce_plat_v6 = {
> +static const struct gce_plat gce_plat_mt8195 = {
>  	.thread_nr = 24,
>  	.shift = 3,
>  	.control_by_sw = true,
>  	.gce_num = 2
>  };
>  
> -static const struct gce_plat gce_plat_v7 = {
> +static const struct gce_plat gce_plat_mt8186 = {
>  	.thread_nr = 24,
>  	.shift = 3,
>  	.control_by_sw = true,
> @@ -750,12 +750,12 @@ static const struct gce_plat gce_plat_v7 = {
>  };
>  
>  static const struct of_device_id cmdq_of_ids[] = {
> -	{.compatible = "mediatek,mt8173-gce", .data = (void
> *)&gce_plat_v2},
> -	{.compatible = "mediatek,mt8183-gce", .data = (void
> *)&gce_plat_v3},
> -	{.compatible = "mediatek,mt8186-gce", .data = (void
> *)&gce_plat_v7},
> -	{.compatible = "mediatek,mt6779-gce", .data = (void
> *)&gce_plat_v4},
> -	{.compatible = "mediatek,mt8192-gce", .data = (void
> *)&gce_plat_v5},
> -	{.compatible = "mediatek,mt8195-gce", .data = (void
> *)&gce_plat_v6},
> +	{.compatible = "mediatek,mt8173-gce", .data = (void
> *)&gce_plat_mt8173},
> +	{.compatible = "mediatek,mt8183-gce", .data = (void
> *)&gce_plat_mt8183},
> +	{.compatible = "mediatek,mt8186-gce", .data = (void
> *)&gce_plat_mt8186},
> +	{.compatible = "mediatek,mt6779-gce", .data = (void
> *)&gce_plat_mt6779},
> +	{.compatible = "mediatek,mt8192-gce", .data = (void
> *)&gce_plat_mt8192},
> +	{.compatible = "mediatek,mt8195-gce", .data = (void
> *)&gce_plat_mt8195},
>  	{}
>  };
>  

From patchwork-bot+netdevbpf at kernel.org  Fri Dec 15 01:40:24 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Fri, 15 Dec 2023 09:40:24 +0000
Subject: [PATCH net-next v4] net: stmmac: don't create a MDIO bus if
 unnecessary
In-Reply-To: <20231212-stmmac-no-mdio-node-v4-1-c121068ccd17@redhat.com>
References: <20231212-stmmac-no-mdio-node-v4-1-c121068ccd17@redhat.com>
Message-ID: <170263322448.1975.8565502940787597440.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (main)
by David S. Miller <davem at davemloft.net>:

On Tue, 12 Dec 2023 16:07:36 -0600 you wrote:
> Currently a MDIO bus is created if the devicetree description is either:
> 
>     1. Not fixed-link
>     2. fixed-link but contains a MDIO bus as well
> 
> The "1" case above isn't always accurate. If there's a phy-handle,
> it could be referencing a phy on another MDIO controller's bus[1]. In
> this case, where the MDIO bus is not described at all, currently
> stmmac will make a MDIO bus and scan its address space to discover
> phys (of which there are none). This process takes time scanning a bus
> that is known to be empty, delaying time to complete probe.
> 
> [...]

Here is the summary with links:
  - [net-next,v4] net: stmmac: don't create a MDIO bus if unnecessary
    https://git.kernel.org/netdev/net-next/c/f3c2caacee82

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From krzysztof.kozlowski at linaro.org  Fri Dec 15 01:44:23 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 10:44:23 +0100
Subject: [PATCH v2 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
 <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
Message-ID: <8f583a00-8e9c-4875-936c-ed196d1dae56@linaro.org>

On 14/12/2023 17:31, Robin Murphy wrote:
> +
> +  reg:
> +    items:
> +      - description: Register page 0
> +      - description: Register page 1, if the PMU implements the dual-page extension
> +    minItems: 1
> +
> +  interrupts:
> +    items:
> +      - description: Overflow interrupt
> +
> +  cpus:
> +    description: If the PMU is associated with a particular CPU or subset of CPUs, array of phandles to those CPUs
> +
> +  reg-io-width:
> +    description: Granularity at which PMU register accesses are single-copy atomic
> +    default: 4
> +    enum: [4, 8]
> +
> +

If there is going to be new posting: just one blank line

> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false

Why no example to validate the binding?

Best regards,
Krzysztof



From jbrunet at baylibre.com  Fri Dec 15 01:46:29 2023
From: jbrunet at baylibre.com (Jerome Brunet)
Date: Fri, 15 Dec 2023 10:46:29 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <212239ae-60ab-46f3-a838-39a4d61091fe@linaro.org>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
 <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
 <212239ae-60ab-46f3-a838-39a4d61091fe@linaro.org>
Message-ID: <1ja5qbpz8o.fsf@starbuckisacylon.baylibre.com>


On Wed 13 Dec 2023 at 17:44, Neil Armstrong <neil.armstrong at linaro.org> wrote:

> Hi Maxime,
>
> Le 13/12/2023 ? 09:36, Maxime Ripard a ?crit?:
>> Hi,
>> On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
>>> On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
>>>> On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
>>>>> clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
>>>>> that and don't check the return value. This series fixes the four users
>>>>> that do error checking on the returned value and then makes function
>>>>> return void.
>>>>>
>>>>> Given that the changes to the drivers are simple and so merge conflicts
>>>>> (if any) should be easy to handle, I suggest to merge this complete
>>>>> series via the clk tree.
>>>>
>>>> I don't think it's the right way to go about it.
>>>>
>>>> clk_rate_exclusive_get() should be expected to fail. For example if
>>>> there's another user getting an exclusive rate on the same clock.
>>>>
>>>> If we're not checking for it right now, then it should probably be
>>>> fixed, but the callers checking for the error are right to do so if they
>>>> rely on an exclusive rate. It's the ones that don't that should be
>>>> modified.
>>>
>>> If some other consumer has already "locked" a clock that I call
>>> clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
>>> this function because I don't want the rate to change e.g. because I
>>> setup some registers in the consuming device to provide a fixed UART
>>> baud rate or i2c bus frequency (and that works as expected).
>> I guess it's a larger conversation, but I don't see how that can
>> possibly work.
>> The way the API is designed, you have no guarantee (outside of
>> clk_rate_exclusive_*) that the rate is going to change.
>> And clk_rate_exclusive_get() doesn't allow the rate to change while in
>> the "critical section".
>> So the only possible thing to do is clk_set_rate() +
>> clk_rate_exclusive_get().
>
> There's clk_set_rate_exclusive() for this purpose.
>
>> So there's a window where the clock can indeed be changed, and the
>> consumer that is about to lock its rate wouldn't be aware of it.
>> I guess it would work if you don't care about the rate at all, you just
>> want to make sure it doesn't change.
>> Out of the 7 users of that function, 3 are in that situation, so I guess
>> it's fair.
>> 3 are open to that race condition I mentioned above.
>> 1 is calling clk_set_rate while in the critical section, which works if
>> there's a single user but not if there's multiple, so it should be
>> discouraged.
>> 
>>> In this case I won't be able to change the rate of the clock, but that
>>> is signalled by clk_set_rate() failing (iff and when I need awother
>>> rate) which also seems the right place to fail to me.
>> Which is ignored by like half the callers, including the one odd case I
>> mentioned above.
>> And that's super confusing still: you can *always* get exclusivity, but
>> not always do whatever you want with the rate when you have it? How are
>> drivers supposed to recover from that? You can handle failing to get
>> exclusivity, but certainly not working around variable guarantees.
>> 
>>> It's like that since clk_rate_exclusive_get() was introduced in 2017
>>> (commit 55e9b8b7b806ec3f9a8817e13596682a5981c19c).
>> Right, but "it's always been that way" surely can't be an argument,
>> otherwise you wouldn't have done that series in the first place.
>> 
>>> BTW, I just noticed that my assertion "Most users \"know\" that
>>> [clk_rate_exclusive_get() returns zero unconditionally]" is wrong. As of
>>> next-20231213 there are 3 callers ignoring the return value of
>>> clk_rate_exclusive_get() and 4 that handle (imaginary) returned errors.
>>> I expected this function to be used more extensively. (In fact I think
>>> it should be used more as several drivers rely on the clk rate not
>>> changing.)
>> Yes, but also it's super difficult to use in practice, and most devices
>> don't care.
>> The current situation is something like this:
>>    * Only a handful of devices really care about their clock rate, and
>>      often only for one of their clock if they have several. You would
>>      probably get all the devices that create an analog signal somehow
>>      there, so audio, display, i2c, spi, uarts, etc. Plus the ones doing
>>      frequency scaling so CPU and GPUs.
>>    * CPUs and GPUs are very likely to have a dedicated clock, so we can
>>      rule the "another user is going to mess with my clock" case.
>>    * UARTs/i2c/etc. are usually taking their clock from the bus interface
>>      directly which is pretty much never going to change (for good
>>      reason). And the rate of the bus is not really likely to change.
>>    * SPI/NAND/MMC usually have their dedicated clock too, and the bus
>>      rate is not likely to change after the initial setup either.
>> So, the only affected devices are the ones generating external signals,
>> with the rate changing during the life of the system. Even for audio or
>> video devices, that's fairly unlikely to happen. And you need to have
>> multiple devices sharing the same clock tree for that issue to occur,
>> which is further reducing the chances it happens.
>
> Well, thanks for HW designers, this exists and some SoCs has less PLLs than
> needed, and they can't be dedicated for some hw blocks.

Indeed. Even if there are enough PLLs, the exclusive API might help.
The idea is to force the second consumer to pick another "free" PLL if
it needs another rate.

If it can work with the rate currently locked by the first consumer,
then CCF may just pick that one, saving a PLL for future use. If it cant,
the protection will force the use of another PLL.

Without the exclusive API, the second consummer may just wreck the PLL of
the first consummer, regardless of the other PLL available.

Of course, if there is enough PLL, the other solution is manual
allocation, using assigned-parent and CLK_NO_REPARENT.

>
>> Realistically speaking, this only occurs with multi-head display outputs
>> where it's somewhat likely to have all the display controllers feeding
>> from the same clock, and the power up of the various output is done in
>> sequence which creates that situation.
>> And even then, the clk_rate_exclusive_* interface effectively locks the
>> entire clock subtree to its current rate, so the effect on the rest of
>> the devices can be significant.
>> So... yeah. Even though you're right, it's trying to address a problem
>> that is super unlikely to happen with a pretty big hammer that might be
>> too much for most. So it's not really surprising it's not used more.
>
> Honestly I tried my best to find a smart way to set the DSI clock tree
> with only 2 endpoints of the tree, but CCF will explore all possibilities
> and since you cannot set constraints, locking a sub-tree is the smartest
> way I found.
> In this case, the PLL is common between the DSI controller and video generator,
> so to keep the expected clock ratio, the smart way is to set the freq on
> one side, lock the subtree and set the rate on the other side.
> An API permitting to set multiple rates to multiple clocks in a single call
> would be the solution, but not sure if we could possibly write such algorithm.
>
>> Maxime
>
> Neil


-- 
Jerome


From herbert at gondor.apana.org.au  Fri Dec 15 01:58:19 2023
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 15 Dec 2023 17:58:19 +0800
Subject: [PATCH 00/12] hwrng: Convert to platform remove callback
 returning
In-Reply-To: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702245873.git.u.kleine-koenig@pengutronix.de>
Message-ID: <ZXwjO8m/Jm6HX+De@gondor.apana.org.au>

On Sun, Dec 10, 2023 at 11:12:15PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> this series converts all hwrng platform drivers to use .remove_new.
> See commit 5c5a7680e67b ("platform: Provide a remove callback that
> returns no value") for details and the eventual goal.
> 
> All driver conversions are trivial as all their remove callbacks return
> 0 (as good drivers should do).
> 
> All patches are pairwise independant. These patches should go in via the
> usual hwrng tree. It's merge window material.
> 
> Best regards
> Uwe
> 
> Uwe Kleine-K?nig (12):
>   hwrng: atmel - Convert to platform remove callback returning void
>   hwrng: cctrng - Convert to platform remove callback returning void
>   hwrng: exynos - Convert to platform remove callback returning void
>   hwrng: ingenic - Convert to platform remove callback returning void
>   hwrng: ks-sa - Convert to platform remove callback returning void
>   hwrng: mxc - Convert to platform remove callback returning void
>   hwrng: n2 - Convert to platform remove callback returning void
>   hwrng: npcm - Convert to platform remove callback returning void
>   hwrng: omap - Convert to platform remove callback returning void
>   hwrng: stm32 - Convert to platform remove callback returning void
>   hwrng: timeriomem - Convert to platform remove callback returning void
>   hwrng: xgene - Convert to platform remove callback returning void
> 
>  drivers/char/hw_random/atmel-rng.c      | 6 ++----
>  drivers/char/hw_random/cctrng.c         | 6 ++----
>  drivers/char/hw_random/exynos-trng.c    | 6 ++----
>  drivers/char/hw_random/ingenic-rng.c    | 6 ++----
>  drivers/char/hw_random/ks-sa-rng.c      | 6 ++----
>  drivers/char/hw_random/mxc-rnga.c       | 6 ++----
>  drivers/char/hw_random/n2-drv.c         | 6 ++----
>  drivers/char/hw_random/npcm-rng.c       | 6 ++----
>  drivers/char/hw_random/omap-rng.c       | 6 ++----
>  drivers/char/hw_random/stm32-rng.c      | 6 ++----
>  drivers/char/hw_random/timeriomem-rng.c | 6 ++----
>  drivers/char/hw_random/xgene-rng.c      | 6 ++----
>  12 files changed, 24 insertions(+), 48 deletions(-)
> 
> 
> base-commit: bc63de6e6ba0b16652c5fb4b9c9916b9e7ca1f23
> -- 
> 2.42.0

All applied.  Thanks.
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From amit.kumar-mahapatra at amd.com  Fri Dec 15 02:02:31 2023
From: amit.kumar-mahapatra at amd.com (Mahapatra, Amit Kumar)
Date: Fri, 15 Dec 2023 10:02:31 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <b3d3c457-a43b-478a-85b3-52558227d139@linaro.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
 <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <c3fa1e04-92ed-48ab-a509-98e43abd5cd6@linaro.org>
 <BN7PR12MB2802E87F1A6CD22D904CAEACDC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
 <b3d3c457-a43b-478a-85b3-52558227d139@linaro.org>
Message-ID: <BN7PR12MB28027E62D66460A374E3CFEADC93A@BN7PR12MB2802.namprd12.prod.outlook.com>

Hello Tudor,

> -----Original Message-----
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> Sent: Friday, December 15, 2023 1:40 PM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> michael at walle.cc; linux-mtd at lists.infradead.org;
> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
> in spi-nor
> 
> 
> 
> On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
> >> Thanks! Can you share with us what flashes you used for testing in
> >> the stacked and parallel configurations?
> > I used SPI-NOR QSPI flashes for testing stacked and parallel.
> 
> I got that, I wanted the flash name or device ID.

N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI flashes on 
which we tested. Additionally, we conducted tests on over 30 different 
QSPI flashes from four distinct vendors (Miron, Winbond, Macronix, and ISSI).

> What I'm interested is if each flash is in its own package. Are they?

I'm sorry, but I don't quite understand what you mean by "if each flash in 
its own package."

> 
> >
> >>>> can combine a SPI NOR with a SPI NAND in stacked configuration?
> >>> No, Xilinx/AMD QSPI controllers doesn't support this configuration.
> >>>
> >> 2 SPI NANDs shall work with the AMD controller, right?
> > We never tested 2 SPI-NAND with AMD controller.
> 
> I was asking because I think the stacked layer shall be SPI MEM generic, and
> not particular to SPI NOR.

Yes, I agree.

> 
> >> I skimmed over the QSPI controller datasheet and wondered why one
> >> would get complicated with 2 Quad Flashes when we have Octal. But
> >> then I saw that the same SoC can configure an Octal controller (the
> >> Octal and Quad controllers seems mutual exclusive) and that the Octal
> >> one can operate 2 octal flashes in stacked mode ?.
> > Thats correct .
> >
> > Please let me know how you want me to proceed on this.
> 
> I got you. Still need to allocate more time on this.

Sure.

Regards,
Amit 
> 
> Cheers,
> ta

From alexandre.torgue at foss.st.com  Fri Dec 15 02:03:47 2023
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Fri, 15 Dec 2023 11:03:47 +0100
Subject: [GIT PULL] STM32 DT changes for v6.8 #1
Message-ID: <9363227b-1c44-4a20-b245-efbbbf9ab1dd@foss.st.com>

Hi ARM SoC maintainers,

Please consider this first round of STM32 DT for v6.8 cycle.

Thanks
Alex


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

   Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git 
tags/stm32-dt-for-v6.8-1

for you to fetch changes up to 2de1bb183a6999521a114d3ed0b17d15b8e75e04:

   ARM: dts: stm32: add dcmipp support to stm32mp135 (2023-12-15 
09:28:06 +0100)

----------------------------------------------------------------
STM32 DT for v6.8, round 1

Highlights:
----------

- MCU:
   -  Add SPI support on STM32F746.
   -  Better describe vcc_3v3 for SD and DSI on stm32f469-disco.

- MPU:
   - STM32MP13:
     - Add DCMIPP (Digital Camera Memory Interface Piwel Processor)  on 
STM32MP135.

   - STMP32MP15:
     - Change "phys" affectation from board to Soc dtsi file for USB 
host as it is hard  linked
       to the port 0 of usbphyc.
     - Fix SCMI and No-SCMI compatible in boards.

   - STM32MP25:
     - Add BSEC support to read the device part number OTP and the 
package data register OTP.

----------------------------------------------------------------
Ahmad Fatoum (2):
       dt-bindings: arm: stm32: don't mix SCMI and non-SCMI board 
compatibles
       ARM: dts: stm32: don't mix SCMI and non-SCMI board compatibles

Ben Wolsieffer (2):
       ARM: dts: stm32: add STM32F746 syscfg clock
       ARM: dts: stm32: add SPI support on STM32F746

Dario Binacchi (1):
       ARM: dts: stm32: use the same 3v3 for SD and DSI nodes on 
stm32f469-disco

Hugues Fruchet (1):
       ARM: dts: stm32: add dcmipp support to stm32mp135

Krzysztof Kozlowski (1):
       ARM: dts: stm32: minor whitespace cleanup around '='

Patrick Delaunay (1):
       arm64: dts: st: add bsec support to stm32mp25

Uwe Kleine-K?nig (1):
       ARM: dts: stm32: Consolidate usbh_[eo]hci phy properties on stm32mp15

  Documentation/devicetree/bindings/arm/stm32/stm32.yaml      | 16 
+++-------------
  arch/arm/boot/dts/st/stm32f469-disco.dts                    | 15 
++++-----------
  arch/arm/boot/dts/st/stm32f746.dtsi                         | 61 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  arch/arm/boot/dts/st/stm32mp135.dtsi                        | 11 
+++++++++++
  arch/arm/boot/dts/st/stm32mp151.dtsi                        |  4 ++++
  arch/arm/boot/dts/st/stm32mp151a-prtt1l.dtsi                |  2 --
  arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts               |  4 ++--
  arch/arm/boot/dts/st/stm32mp157a-stinger96.dtsi             |  2 --
  arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts               |  4 ++--
  arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts               |  4 ++--
  arch/arm/boot/dts/st/stm32mp157c-emstamp-argon.dtsi         |  4 ----
  arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts               |  5 ++---
  arch/arm/boot/dts/st/stm32mp157c-ev1.dts                    |  1 -
  arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts           |  4 ----
  arch/arm/boot/dts/st/stm32mp157c-phycore-stm32mp15-som.dtsi |  4 ----
  arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi               |  3 ---
  arch/arm/boot/dts/st/stm32mp15xx-dhcom-drc02.dtsi           |  1 -
  arch/arm/boot/dts/st/stm32mp15xx-dhcom-pdk2.dtsi            |  1 -
  arch/arm/boot/dts/st/stm32mp15xx-dhcom-picoitx.dtsi         |  2 --
  arch/arm/boot/dts/st/stm32mp15xx-dhcor-avenger96.dtsi       |  2 --
  arch/arm/boot/dts/st/stm32mp15xx-dhcor-drc-compact.dtsi     |  2 --
  arch/arm/boot/dts/st/stm32mp15xx-dhcor-testbench.dtsi       |  2 --
  arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi                   |  1 -
  arch/arm64/boot/dts/st/stm32mp251.dtsi                      | 16 
++++++++++++++++
  24 files changed, 107 insertions(+), 64 deletions(-)


From quic_bibekkum at quicinc.com  Fri Dec 15 02:18:22 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Fri, 15 Dec 2023 15:48:22 +0530
Subject: [PATCH v4 0/5] iommu/arm-smmu: introduction of ACTLR implementation for Qualcomm SoCs
Message-ID: <20231215101827.30549-1-quic_bibekkum@quicinc.com>

This patch series consist of three parts and covers the following:

1. Remove cfg inside qcom_smmu structure and replace it with single
   pointer to qcom_smmu_match_data avoiding replication of multiple
   members from same.

2. Introduce intital set of driver changes to implement ACTLR register
   for custom prefetcher settings in Qualcomm SoCs.

3. Add ACTLR data and implementation operations for SM8550.

4. Add ACTLR data and implementation operations for SC7280.

5. Re-enable context caching for Qualcomm SoCs to retain prefetcher
   settings during reset and runtime suspend.

Changes in v4 from v3:
 New addition:
 - Remove actlrcfg_size and use NULL end element instead to traverse
   the actlr table, as this would be a cleaner approach by removing
   redundancy of actlrcfg_size.
 - Renaming of actlr set function to arm_smmu_qcom based proprietary
   convention.
 - break from loop once sid is found and ACTLR value is initialized
   in qcom_smmu_set_actlr.
 - Modify the GFX prefetch value separating into 2 sensible defines.
 - Modify comments for prefetch defines as per SMMU-500 TRM.
 Changes to incorporate suggestions from Konrad as follows:
 - Use Reverse-Christmas-tree sorting wherever applicable.
 - Pass arguments directly to arm_smmu_set_actlr instead of creating
   duplicate variables.
 - Use array indexing instead of direct pointer addressed by new
   addition of eliminating actlrcfg_size.
 - Switch the HEX value's case from upper to lower case in SC7280
   actlrcfg table.
 Changes to incorporate suggestions from Dmitry as follows:
 - Separate changes not related to ACTLR support to different commit
   with patch 5/5.
 - Using pointer to struct for arguments in smr_is_subset().
 Changes to incorporate suggestions from Bjorn as follows:
 - fix the commit message for patch 2/5 to properly document the
   value space to avoid confusion.
 Fixed build issues reported by kernel test robot [1] for
 arm64-allyesconfig [2].
 [1]: https://lore.kernel.org/all/202312011750.Pwca3TWE-lkp at intel.com/
 [2]: https://download.01.org/0day-ci/archive/20231201/202312011750.Pwca3TWE-lkp at intel.com/config
 Link to v3:
https://lore.kernel.org/all/20231127145412.3981-1-quic_bibekkum at quicinc.com/

Changes in v3 from v2:
 New addition:
 - Include patch 3/4 for adding ACTLR support and data for SC7280.
 - Add driver changes for actlr support in gpu smmu.
 - Add target wise actlr data and implementation ops for gpu smmu.
 Changes to incorporate suggestions from Robin as follows:
 - Match the ACTLR values with individual corresponding SID instead
   of assuming that any SMR will be programmed to match a superset of
   the data.
 - Instead of replicating each elements from qcom_smmu_match_data to
   qcom_smmu structre during smmu device creation, replace the
   replicated members with qcom_smmu_match_data structure inside
   qcom_smmu structre and handle the dereference in places that
   requires them.
 Changes to incorporate suggestions from Dmitry and Konrad as follows:
 - Maintain actlr table inside a single structure instead of
   nested structure.
 - Rename prefetch defines to more appropriately describe their behavior.
 - Remove SM8550 specific implementation ops and roll back to default
   qcom_smmu_500_impl implementation ops.
 - Add back the removed comments which are NAK.
 - Fix commit description for patch 4/4.
 Link to v2:
https://lore.kernel.org/all/20231114135654.30475-1-quic_bibekkum at quicinc.com/

Changes in v2 from v1:
 - Incorporated suggestions on v1 from Dmitry,Konrad,Pratyush.
 - Added defines for ACTLR values.
 - Linked sm8550 implementation structure to corresponding
   compatible string.
 - Repackaged actlr value set implementation to separate function.
 - Fixed indentation errors.
 - Link to v1:
https://lore.kernel.org/all/20231103215124.1095-1-quic_bibekkum at quicinc.com/

Changes in v1 from RFC:
 - Incorporated suggestion form Robin on RFC
 - Moved the actlr data table into driver, instead of maintaining
   it inside soc specific DT and piggybacking on exisiting iommus
   property (iommu = <SID, MASK, ACTLR>) to set this value during
   smmu probe.
 - Link to RFC:
https://lore.kernel.org/all/a01e7e60-6ead-4a9e-ba90-22a8a6bbd03f at quicinc.com/
Bibek Kumar Patro (5):
  iommu/arm-smmu: refactor qcom_smmu structure to include single pointer
  iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings
  iommu/arm-smmu: add ACTLR data and support for SM8550
  iommu/arm-smmu: add ACTLR data and support for SC7280
  iommu/arm-smmu: re-enable context caching in smmu reset operation

 .../iommu/arm/arm-smmu/arm-smmu-qcom-debug.c  |   2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c    | 184 +++++++++++++++++-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h    |   6 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.c         |   5 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.h         |   5 +
 5 files changed, 193 insertions(+), 9 deletions(-)

--
2.17.1



From quic_bibekkum at quicinc.com  Fri Dec 15 02:18:23 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Fri, 15 Dec 2023 15:48:23 +0530
Subject: [PATCH v4 1/5] iommu/arm-smmu: refactor qcom_smmu structure to include single pointer
In-Reply-To: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
Message-ID: <20231215101827.30549-2-quic_bibekkum@quicinc.com>

qcom_smmu_match_data is static and constant so refactor qcom_smmu
to store single pointer to qcom_smmu_match_data instead of
replicating multiple child members of the same and handle the further
dereferences in the places that want them.

Suggested-by: Robin Murphy <robin.murphy at arm.com>
Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c       | 2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h       | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
index bb89d49adf8d..e9798b133cbb 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
@@ -22,7 +22,7 @@ void qcom_smmu_tlb_sync_debug(struct arm_smmu_device *smmu)
 	if (__ratelimit(&rs)) {
 		dev_err(smmu->dev, "TLB sync timed out -- SMMU may be deadlocked\n");

-		cfg = qsmmu->cfg;
+		cfg = qsmmu->data->cfg;
 		if (!cfg)
 			return;

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 549ae4dba3a6..8a7c16a86694 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -465,7 +465,7 @@ static struct arm_smmu_device *qcom_smmu_create(struct arm_smmu_device *smmu,
 		return ERR_PTR(-ENOMEM);

 	qsmmu->smmu.impl = impl;
-	qsmmu->cfg = data->cfg;
+	qsmmu->data = data;

 	return &qsmmu->smmu;
 }
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
index 593910567b88..f3b91963e234 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
@@ -8,7 +8,7 @@

 struct qcom_smmu {
 	struct arm_smmu_device smmu;
-	const struct qcom_smmu_config *cfg;
+	const struct qcom_smmu_match_data *data;
 	bool bypass_quirk;
 	u8 bypass_cbndx;
 	u32 stall_enabled;
--
2.17.1



From quic_bibekkum at quicinc.com  Fri Dec 15 02:18:24 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Fri, 15 Dec 2023 15:48:24 +0530
Subject: [PATCH v4 2/5] iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings
In-Reply-To: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
Message-ID: <20231215101827.30549-3-quic_bibekkum@quicinc.com>

Currently in Qualcomm  SoCs the default prefetch is set to 1 which allows
the TLB to fetch just the next page table. MMU-500 features ACTLR
register which is implementation defined and is used for Qualcomm SoCs
to have a custom prefetch setting enabling TLB to prefetch the next set
of page tables accordingly allowing for faster translations.

ACTLR value is unique for each SMR (Stream matching register) and stored
in a pre-populated table. This value is set to the register during
context bank initialisation.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 45 ++++++++++++++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h |  4 ++
 drivers/iommu/arm/arm-smmu/arm-smmu.c      |  5 ++-
 drivers/iommu/arm/arm-smmu/arm-smmu.h      |  5 +++
 4 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 8a7c16a86694..cb49291f5233 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -14,6 +14,12 @@

 #define QCOM_DUMMY_VAL	-1

+struct actlr_config {
+	u16 sid;
+	u16 mask;
+	u32 actlr;
+};
+
 static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
 {
 	return container_of(smmu, struct qcom_smmu, smmu);
@@ -205,9 +211,38 @@ static bool qcom_adreno_can_do_ttbr1(struct arm_smmu_device *smmu)
 	return true;
 }

+static void qcom_smmu_set_actlr(struct device *dev, struct arm_smmu_device *smmu, int cbndx,
+		const struct actlr_config *actlrcfg)
+{
+	struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
+	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+	struct arm_smmu_smr *smr;
+	u16 mask;
+	int idx;
+	u16 id;
+	int i;
+
+	for (; actlrcfg->sid || actlrcfg->mask || actlrcfg->actlr; actlrcfg++) {
+		id = actlrcfg->sid;
+		mask = actlrcfg->mask;
+
+		for_each_cfg_sme(cfg, fwspec, i, idx) {
+			smr = &smmu->smrs[idx];
+			if (smr_is_subset(smr, id, mask)) {
+				arm_smmu_cb_write(smmu, cbndx, ARM_SMMU_CB_ACTLR,
+						actlrcfg->actlr);
+				break;
+			}
+		}
+	}
+}
+
 static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 		struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
 {
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+	int cbndx = smmu_domain->cfg.cbndx;
 	struct adreno_smmu_priv *priv;

 	smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
@@ -238,6 +273,9 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 	priv->set_stall = qcom_adreno_smmu_set_stall;
 	priv->resume_translation = qcom_adreno_smmu_resume_translation;

+	if (qsmmu->data->actlrcfg_gfx)
+		qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg_gfx);
+
 	return 0;
 }

@@ -264,6 +302,13 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
 static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 		struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
 {
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+	int cbndx = smmu_domain->cfg.cbndx;
+
+	if (qsmmu->data->actlrcfg)
+		qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg);
+
 	smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;

 	return 0;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
index f3b91963e234..448a66b5332f 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
@@ -24,7 +24,11 @@ struct qcom_smmu_config {
 	const u32 *reg_offset;
 };

+struct actlr_config;
+
 struct qcom_smmu_match_data {
+	const struct actlr_config *actlrcfg;
+	const struct actlr_config *actlrcfg_gfx;
 	const struct qcom_smmu_config *cfg;
 	const struct arm_smmu_impl *impl;
 	const struct arm_smmu_impl *adreno_impl;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d6d1a2a55cc0..0c7f700b27dd 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -990,9 +990,10 @@ static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
 		 * expect simply identical entries for this case, but there's
 		 * no harm in accommodating the generalisation.
 		 */
-		if ((mask & smrs[i].mask) == mask &&
-		    !((id ^ smrs[i].id) & ~smrs[i].mask))
+
+		if (smr_is_subset(&smrs[i], id, mask))
 			return i;
+
 		/*
 		 * If the new entry has any other overlap with an existing one,
 		 * though, then there always exists at least one stream ID
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 703fd5817ec1..2e4f65412c6b 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -501,6 +501,11 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
 		writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);
 }

+static inline bool smr_is_subset(struct arm_smmu_smr *smrs, u16 id, u16 mask)
+{
+	return (mask & smrs->mask) == mask && !((id ^ smrs->id) & ~smrs->mask);
+}
+
 #define ARM_SMMU_GR0		0
 #define ARM_SMMU_GR1		1
 #define ARM_SMMU_CB(s, n)	((s)->numpage + (n))
--
2.17.1



From quic_bibekkum at quicinc.com  Fri Dec 15 02:18:25 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Fri, 15 Dec 2023 15:48:25 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for SM8550
In-Reply-To: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
Message-ID: <20231215101827.30549-4-quic_bibekkum@quicinc.com>

Add ACTLR data table for SM8550 along with support for
same including SM8550 specific implementation operations.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 ++++++++++++++++++++++
 1 file changed, 89 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index cb49291f5233..d2006f610243 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -20,6 +20,85 @@ struct actlr_config {
 	u32 actlr;
 };

+/*
+ * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
+ * macro TLB) and BIT(1) as CPRE (Enable context caching in the prefetch
+ * buffer). The remaining bits are implementation defined and vary across
+ * SoCs.
+ */
+
+#define PREFETCH_DEFAULT	0
+#define PREFETCH_SHALLOW	BIT(8)
+#define PREFETCH_MODERATE	BIT(9)
+#define PREFETCH_DEEP		(BIT(9) | BIT(8))
+#define PREFETCH_SWITCH_GFX	(BIT(5) | BIT(3))
+#define CPRE			BIT(1)
+#define CMTLB			BIT(0)
+
+static const struct actlr_config sm8550_apps_actlr_cfg[] = {
+	{ 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x0800, 0x0020, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1800, 0x00c0, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1820, 0x0000, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1860, 0x0000, PREFETCH_DEFAULT | CMTLB },
+	{ 0x0c01, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c02, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c03, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c04, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c05, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c06, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c07, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c08, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c09, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0c, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0d, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0e, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0f, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1961, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1962, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1963, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1964, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1965, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1966, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1967, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1968, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1969, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196c, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196d, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196e, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196f, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c1, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c2, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c3, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c4, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c5, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c6, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c7, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c8, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c9, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19cc, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19cd, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19ce, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19cf, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1c00, 0x0002, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1c01, 0x0000, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1920, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1923, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1924, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1940, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1941, 0x0004, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1943, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1944, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{},
+};
+
+static const struct actlr_config sm8550_gfx_actlr_cfg[] = {
+	{ 0x0000, 0x03ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE | CMTLB },
+	{},
+};
+
 static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
 {
 	return container_of(smmu, struct qcom_smmu, smmu);
@@ -549,6 +628,15 @@ static const struct qcom_smmu_match_data sdm845_smmu_500_data = {
 	/* Also no debug configuration. */
 };

+
+static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
+	.impl = &qcom_smmu_500_impl,
+	.adreno_impl = &qcom_adreno_smmu_500_impl,
+	.cfg = &qcom_smmu_impl0_cfg,
+	.actlrcfg = sm8550_apps_actlr_cfg,
+	.actlrcfg_gfx = sm8550_gfx_actlr_cfg,
+};
+
 static const struct qcom_smmu_match_data qcom_smmu_500_impl0_data = {
 	.impl = &qcom_smmu_500_impl,
 	.adreno_impl = &qcom_adreno_smmu_500_impl,
@@ -583,6 +671,7 @@ static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
 	{ .compatible = "qcom,sm8250-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sm8350-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sm8450-smmu-500", .data = &qcom_smmu_500_impl0_data },
+	{ .compatible = "qcom,sm8550-smmu-500", .data = &sm8550_smmu_500_impl0_data },
 	{ .compatible = "qcom,smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ }
 };
--
2.17.1



From quic_bibekkum at quicinc.com  Fri Dec 15 02:18:26 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Fri, 15 Dec 2023 15:48:26 +0530
Subject: [PATCH v4 4/5] iommu/arm-smmu: add ACTLR data and support for SC7280
In-Reply-To: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
Message-ID: <20231215101827.30549-5-quic_bibekkum@quicinc.com>

Add ACTLR data table for SC7280 along with support for
same including SC7280 specific implementation operations.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 25 +++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d2006f610243..c8f5dd4186b7 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -35,6 +35,22 @@ struct actlr_config {
 #define CPRE			BIT(1)
 #define CMTLB			BIT(0)

+static const struct actlr_config sc7280_apps_actlr_cfg[] = {
+	{ 0x0800, 0x24e1, PREFETCH_DEFAULT | CMTLB },
+	{ 0x2000, 0x0163, PREFETCH_DEFAULT | CMTLB },
+	{ 0x2080, 0x0461, PREFETCH_DEFAULT | CMTLB },
+	{ 0x2100, 0x0161, PREFETCH_DEFAULT | CMTLB },
+	{ 0x0900, 0x0407, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x2180, 0x0027, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1000, 0x07ff, PREFETCH_DEEP | CPRE | CMTLB },
+	{},
+};
+
+static const struct actlr_config sc7280_gfx_actlr_cfg[] = {
+	{ 0x0000, 0x07ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE | CMTLB },
+	{},
+};
+
 static const struct actlr_config sm8550_apps_actlr_cfg[] = {
 	{ 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
 	{ 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
@@ -628,6 +644,13 @@ static const struct qcom_smmu_match_data sdm845_smmu_500_data = {
 	/* Also no debug configuration. */
 };

+static const struct qcom_smmu_match_data sc7280_smmu_500_impl0_data = {
+	.impl = &qcom_smmu_500_impl,
+	.adreno_impl = &qcom_adreno_smmu_500_impl,
+	.cfg = &qcom_smmu_impl0_cfg,
+	.actlrcfg = sc7280_apps_actlr_cfg,
+	.actlrcfg_gfx = sc7280_gfx_actlr_cfg,
+};

 static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
 	.impl = &qcom_smmu_500_impl,
@@ -654,7 +677,7 @@ static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
 	{ .compatible = "qcom,qdu1000-smmu-500", .data = &qcom_smmu_500_impl0_data  },
 	{ .compatible = "qcom,sc7180-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sc7180-smmu-v2", .data = &qcom_smmu_v2_data },
-	{ .compatible = "qcom,sc7280-smmu-500", .data = &qcom_smmu_500_impl0_data },
+	{ .compatible = "qcom,sc7280-smmu-500", .data = &sc7280_smmu_500_impl0_data },
 	{ .compatible = "qcom,sc8180x-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sc8280xp-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sdm630-smmu-v2", .data = &qcom_smmu_v2_data },
--
2.17.1



From quic_bibekkum at quicinc.com  Fri Dec 15 02:18:27 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Fri, 15 Dec 2023 15:48:27 +0530
Subject: [PATCH v4 5/5] iommu/arm-smmu: re-enable context caching in smmu reset operation
In-Reply-To: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
Message-ID: <20231215101827.30549-6-quic_bibekkum@quicinc.com>

Default MMU-500 reset operation disables context caching in
prefetch buffer. It is however expected for context banks using
the ACTLR register to retain their prefetch value during reset
and runtime suspend.

Replace default MMU-500 reset operation with Qualcomm specific reset
operation which envelope the default reset operation and re-enables
context caching in prefetch buffer for Qualcomm SoCs.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 23 +++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index c8f5dd4186b7..70d2a5d43993 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -516,11 +516,28 @@ static int qcom_smmu_def_domain_type(struct device *dev)
 	return match ? IOMMU_DOMAIN_IDENTITY : 0;
 }

+static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
+{
+	int i;
+	u32 reg;
+
+	arm_mmu500_reset(smmu);
+
+	/* arm_mmu500_reset() disables CPRE which is re-enabled here */
+	for (i = 0; i < smmu->num_context_banks; ++i) {
+		reg = arm_smmu_cb_read(smmu, i, ARM_SMMU_CB_ACTLR);
+		reg |= CPRE;
+		arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_ACTLR, reg);
+	}
+
+	return 0;
+}
+
 static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
 {
 	int ret;

-	arm_mmu500_reset(smmu);
+	qcom_smmu500_reset(smmu);

 	/*
 	 * To address performance degradation in non-real time clients,
@@ -547,7 +564,7 @@ static const struct arm_smmu_impl qcom_smmu_500_impl = {
 	.init_context = qcom_smmu_init_context,
 	.cfg_probe = qcom_smmu_cfg_probe,
 	.def_domain_type = qcom_smmu_def_domain_type,
-	.reset = arm_mmu500_reset,
+	.reset = qcom_smmu500_reset,
 	.write_s2cr = qcom_smmu_write_s2cr,
 	.tlb_sync = qcom_smmu_tlb_sync,
 };
@@ -572,7 +589,7 @@ static const struct arm_smmu_impl qcom_adreno_smmu_v2_impl = {
 static const struct arm_smmu_impl qcom_adreno_smmu_500_impl = {
 	.init_context = qcom_adreno_smmu_init_context,
 	.def_domain_type = qcom_smmu_def_domain_type,
-	.reset = arm_mmu500_reset,
+	.reset = qcom_smmu500_reset,
 	.alloc_context_bank = qcom_adreno_smmu_alloc_context_bank,
 	.write_sctlr = qcom_adreno_smmu_write_sctlr,
 	.tlb_sync = qcom_smmu_tlb_sync,
--
2.17.1



From tudor.ambarus at linaro.org  Fri Dec 15 02:23:53 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Fri, 15 Dec 2023 10:23:53 +0000
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate
 clock names
In-Reply-To: <050c3119-0431-4400-9052-7a9c0ec67918@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-2-tudor.ambarus@linaro.org>
 <050c3119-0431-4400-9052-7a9c0ec67918@linaro.org>
Message-ID: <5e454300-f1ef-435c-8c4c-16561502196a@linaro.org>

Hi, Krzysztof,

On 12/15/23 08:13, Krzysztof Kozlowski wrote:
> On 14/12/2023 11:52, Tudor Ambarus wrote:
>> The gs101 clock names are derived from the clock register names under
>> some certain rules. In particular, for the gate clocks the following is
>> documented and expected in the gs101 clock driver:
>>
>>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
>>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>
>>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
> 
> I don't understand what it has to do with the bindings.
> 
>>
>> The CMU TOP gate clock names missed to include the required "CMU"
>> differentiator which will cause name collisions with the gate clock names
>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>> their name.
> 
> Neither here. Clock names are not related to defines.
> 

When saying "clock names" I meant the clock symbolic names that are
defined in the bindings, the _id passed in GATE(_id, ) if you want.

>>
>> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>> ---
>>  drivers/clk/samsung/clk-gs101.c          | 167 ++++++++++++-----------
>>  include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
> 
> I miss the point why bindings must be changed with driver.

The clock symbolic names that are defined in the bindings file are used
as IDs in the clock driver. Having the changes split per file will
result in compilation errors breaking bisect.
> 
> Really, guys, we are milling the first GS101 patches for entire cycle.
> Almost 3 months. The moment I merge bindings you tell me they are wrong.
> Few days after merging them.

I apologize. It happens when we work in parallel. The clock symbolic
names were mangled just in v6. It was considered that the clock names
used in the datasheet are too long and the dt becomes unreadable. I just
recently updated the peric0 clock symbolic names according to the clock
symbolic name mangling strategy, that's why we spot the inconsistency
and the symbolic name collision so late.

Cheers,
ta


From linux at armlinux.org.uk  Fri Dec 15 02:32:18 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Fri, 15 Dec 2023 10:32:18 +0000
Subject: [PATCH] arm: remove duplicated include
In-Reply-To: <202312151426+0800-wangjinchao@xfusion.com>
References: <202312151426+0800-wangjinchao@xfusion.com>
Message-ID: <ZXwrMtFllyGLFl0Y@shell.armlinux.org.uk>

On Fri, Dec 15, 2023 at 02:27:23PM +0800, Wang Jinchao wrote:
> remove duplicated include
> 
> Signed-off-by: Wang Jinchao <wangjinchao at xfusion.com>
> ---

These have been ignored in the past because although they seem correct,
they haven't ended up in my patch system. I guess I'm going to get asked
what that is, despite the link to it being in the footer of every email
I send... (please look at the footer of this email and follow the link!)

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From tudor.ambarus at linaro.org  Fri Dec 15 02:33:00 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Fri, 15 Dec 2023 10:33:00 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <BN7PR12MB28027E62D66460A374E3CFEADC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
 <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <c3fa1e04-92ed-48ab-a509-98e43abd5cd6@linaro.org>
 <BN7PR12MB2802E87F1A6CD22D904CAEACDC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
 <b3d3c457-a43b-478a-85b3-52558227d139@linaro.org>
 <BN7PR12MB28027E62D66460A374E3CFEADC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
Message-ID: <e212f9fa-83c5-4b9e-8636-c8c6183096ab@linaro.org>



On 12/15/23 10:02, Mahapatra, Amit Kumar wrote:
> Hello Tudor,

Hi,

> 
>> -----Original Message-----
>> From: Tudor Ambarus <tudor.ambarus at linaro.org>
>> Sent: Friday, December 15, 2023 1:40 PM
>> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
>> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
>> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
>> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
>> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
>> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
>> michael at walle.cc; linux-mtd at lists.infradead.org;
>> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
>> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
>> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
>> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
>> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
>> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
>> in spi-nor
>>
>>
>>
>> On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
>>>> Thanks! Can you share with us what flashes you used for testing in
>>>> the stacked and parallel configurations?
>>> I used SPI-NOR QSPI flashes for testing stacked and parallel.
>>
>> I got that, I wanted the flash name or device ID.
> 
> N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI flashes on 
> which we tested. Additionally, we conducted tests on over 30 different 
> QSPI flashes from four distinct vendors (Miron, Winbond, Macronix, and ISSI).
> 

Great.

>> What I'm interested is if each flash is in its own package. Are they?
> 
> I'm sorry, but I don't quite understand what you mean by "if each flash in 
> its own package."
> 

There are flashes that are stacked at the physical level. It's a single
flash with multiple dies, that are all under a single physical package.

As I understand, your stacked flash model is at logical level. You have
2 flashes each in its own package. 2 different entities. Is my
understanding correct?

Cheers,
ta


From dmitry.baryshkov at linaro.org  Fri Dec 15 02:44:53 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 15 Dec 2023 12:44:53 +0200
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for SM8550
In-Reply-To: <20231215101827.30549-4-quic_bibekkum@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com> <20231215101827.30549-4-quic_bibekkum@quicinc.com>
Message-ID: <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>

On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
<quic_bibekkum at quicinc.com> wrote:
>
> Add ACTLR data table for SM8550 along with support for
> same including SM8550 specific implementation operations.
>
> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 ++++++++++++++++++++++
>  1 file changed, 89 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index cb49291f5233..d2006f610243 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -20,6 +20,85 @@ struct actlr_config {
>         u32 actlr;
>  };
>
> +/*
> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the prefetch
> + * buffer). The remaining bits are implementation defined and vary across
> + * SoCs.
> + */
> +
> +#define PREFETCH_DEFAULT       0
> +#define PREFETCH_SHALLOW       BIT(8)
> +#define PREFETCH_MODERATE      BIT(9)
> +#define PREFETCH_DEEP          (BIT(9) | BIT(8))

I thin the following might be more correct:

#include <linux/bitfield.h>

#define PREFETCH_MASK GENMASK(9, 8)
#define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
#define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
#define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
#define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)

> +#define PREFETCH_SWITCH_GFX    (BIT(5) | BIT(3))
> +#define CPRE                   BIT(1)
> +#define CMTLB                  BIT(0)
> +
> +static const struct actlr_config sm8550_apps_actlr_cfg[] = {
> +       { 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x0800, 0x0020, PREFETCH_DEFAULT | CMTLB },
> +       { 0x1800, 0x00c0, PREFETCH_DEFAULT | CMTLB },
> +       { 0x1820, 0x0000, PREFETCH_DEFAULT | CMTLB },
> +       { 0x1860, 0x0000, PREFETCH_DEFAULT | CMTLB },
> +       { 0x0c01, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c02, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c03, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c04, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c05, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c06, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c07, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c08, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c09, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c0c, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c0d, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c0e, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x0c0f, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1961, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1962, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1963, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1964, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1965, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1966, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1967, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1968, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1969, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x196c, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x196d, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x196e, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x196f, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19c1, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19c2, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19c3, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19c4, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19c5, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19c6, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19c7, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19c8, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19c9, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19cc, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19cd, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19ce, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x19cf, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
> +       { 0x1c00, 0x0002, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x1c01, 0x0000, PREFETCH_DEFAULT | CMTLB },
> +       { 0x1920, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x1923, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x1924, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x1940, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x1941, 0x0004, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x1943, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x1944, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> +       {},
> +};
> +
> +static const struct actlr_config sm8550_gfx_actlr_cfg[] = {
> +       { 0x0000, 0x03ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE | CMTLB },
> +       {},
> +};
> +
>  static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
>  {
>         return container_of(smmu, struct qcom_smmu, smmu);
> @@ -549,6 +628,15 @@ static const struct qcom_smmu_match_data sdm845_smmu_500_data = {
>         /* Also no debug configuration. */
>  };
>
> +
> +static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
> +       .impl = &qcom_smmu_500_impl,
> +       .adreno_impl = &qcom_adreno_smmu_500_impl,
> +       .cfg = &qcom_smmu_impl0_cfg,
> +       .actlrcfg = sm8550_apps_actlr_cfg,
> +       .actlrcfg_gfx = sm8550_gfx_actlr_cfg,
> +};
> +
>  static const struct qcom_smmu_match_data qcom_smmu_500_impl0_data = {
>         .impl = &qcom_smmu_500_impl,
>         .adreno_impl = &qcom_adreno_smmu_500_impl,
> @@ -583,6 +671,7 @@ static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
>         { .compatible = "qcom,sm8250-smmu-500", .data = &qcom_smmu_500_impl0_data },
>         { .compatible = "qcom,sm8350-smmu-500", .data = &qcom_smmu_500_impl0_data },
>         { .compatible = "qcom,sm8450-smmu-500", .data = &qcom_smmu_500_impl0_data },
> +       { .compatible = "qcom,sm8550-smmu-500", .data = &sm8550_smmu_500_impl0_data },
>         { .compatible = "qcom,smmu-500", .data = &qcom_smmu_500_impl0_data },
>         { }
>  };
> --
> 2.17.1
>


-- 
With best wishes
Dmitry


From eugen.hristev at collabora.com  Fri Dec 15 02:45:47 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Fri, 15 Dec 2023 12:45:47 +0200
Subject: [PATCH v2 3/7] dt-bindings: media: mtk-vcodec-encoder: fix non-vp8 clock name
In-Reply-To: <20231215104551.233679-1-eugen.hristev@collabora.com>
References: <20231215104551.233679-1-eugen.hristev@collabora.com>
Message-ID: <20231215104551.233679-3-eugen.hristev@collabora.com>

Looking at the binding it makes sense that the `-vp8` compatible has
the `venc_lt_sel` while the other bindings have the `venc_sel` as name for
the clock.
This was also mentioned in the txt version of the binding before the
conversion:
 `
 clock-names: avc encoder must contain "venc_sel", vp8 encoder must
 contain "venc_lt_sel", decoder must contain "vcodecpll", "univpll_d2",
 `

So it is easier to check for compatible that includes vp8, since that's
just one, to have the requirement for the clock name property as
`venc_lt_sel`, rather than for all the others, some of which are missing,
thus for them, the requirement is wrongly `venc_lt_sel`.

Reordered the if/then/else to match `-vp8` and have all the rest of
the compatibles using the other clock name (`venc_sel`).

Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
Changes in v2:
- new patch.
 .../bindings/media/mediatek,vcodec-encoder.yaml       | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
index 403530de5624..5166c1c6934e 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
@@ -111,10 +111,7 @@ allOf:
       properties:
         compatible:
           enum:
-            - mediatek,mt8173-vcodec-enc
-            - mediatek,mt8188-vcodec-enc
-            - mediatek,mt8192-vcodec-enc
-            - mediatek,mt8195-vcodec-enc
+            - mediatek,mt8173-vcodec-enc-vp8
 
     then:
       properties:
@@ -124,8 +121,8 @@ allOf:
             maxItems: 1
         clock-names:
           items:
-            - const: venc_sel
-    else:  # for vp8 hw encoder
+            - const: venc_lt_sel
+    else:
       properties:
         clock:
           items:
@@ -133,7 +130,7 @@ allOf:
             maxItems: 1
         clock-names:
           items:
-            - const: venc_lt_sel
+            - const: venc_sel
 
 additionalProperties: false
 
-- 
2.34.1



From eugen.hristev at collabora.com  Fri Dec 15 02:45:48 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Fri, 15 Dec 2023 12:45:48 +0200
Subject: [PATCH v2 4/7] arm64: dts: mediatek: mt8192: fix vencoder clock name
In-Reply-To: <20231215104551.233679-1-eugen.hristev@collabora.com>
References: <20231215104551.233679-1-eugen.hristev@collabora.com>
Message-ID: <20231215104551.233679-4-eugen.hristev@collabora.com>

Clock name should be `venc_sel` as per binding.
Fix the warning message :
arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dtb: vcodec at 17020000: clock-names:0: 'venc_sel' was expected
        from schema $id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml#

Fixes: aa8f3711fc87 ("arm64: dts: mt8192: Add H264 venc device node")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
Changes in v2:
- new patch.
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 69f4cded5dbb..f1fc14e53f8c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -1770,7 +1770,7 @@ vcodec_enc: vcodec at 17020000 {
 			mediatek,scp = <&scp>;
 			power-domains = <&spm MT8192_POWER_DOMAIN_VENC>;
 			clocks = <&vencsys CLK_VENC_SET1_VENC>;
-			clock-names = "venc-set1";
+			clock-names = "venc_sel";
 			assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>;
 			assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D4>;
 		};
-- 
2.34.1



From eugen.hristev at collabora.com  Fri Dec 15 02:45:46 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Fri, 15 Dec 2023 12:45:46 +0200
Subject: [PATCH v2 2/7] dt-bindings: media: mtk-vcodec-encoder: add dma-ranges
In-Reply-To: <20231215104551.233679-1-eugen.hristev@collabora.com>
References: <20231215104551.233679-1-eugen.hristev@collabora.com>
Message-ID: <20231215104551.233679-2-eugen.hristev@collabora.com>

As IOMMUs are supported, dma-ranges is not mentioned but
additionalProperties=false, thus we have an error when adding dma-ranges.
Add dma-ranges as a possible property because this may be present.

Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
Changes in v2:
- none.
 .../devicetree/bindings/media/mediatek,vcodec-encoder.yaml      | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
index a2051b31fa29..403530de5624 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
@@ -38,6 +38,8 @@ properties:
     minItems: 1
     maxItems: 5
 
+  dma-ranges: true
+
   assigned-clocks: true
 
   assigned-clock-parents: true
-- 
2.34.1



From eugen.hristev at collabora.com  Fri Dec 15 02:45:49 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Fri, 15 Dec 2023 12:45:49 +0200
Subject: [PATCH v2 5/7] dt-bindings: media: mtk-vcodec-encoder: add compatible for mt8186
In-Reply-To: <20231215104551.233679-1-eugen.hristev@collabora.com>
References: <20231215104551.233679-1-eugen.hristev@collabora.com>
Message-ID: <20231215104551.233679-5-eugen.hristev@collabora.com>

Add compatible for the mt8186 encoder which currently works in the same
way as mt8183.

Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
Changes in v2:
- new patch.
 .../media/mediatek,vcodec-encoder.yaml        | 20 +++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
index 5166c1c6934e..dfabc2faea6c 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
@@ -16,14 +16,18 @@ description: |+
 
 properties:
   compatible:
-    enum:
-      - mediatek,mt8173-vcodec-enc-vp8
-      - mediatek,mt8173-vcodec-enc
-      - mediatek,mt8183-vcodec-enc
-      - mediatek,mt8188-vcodec-enc
-      - mediatek,mt8192-vcodec-enc
-      - mediatek,mt8195-vcodec-enc
-
+    oneOf:
+      - items:
+          - enum:
+              - mediatek,mt8173-vcodec-enc-vp8
+              - mediatek,mt8173-vcodec-enc
+              - mediatek,mt8183-vcodec-enc
+              - mediatek,mt8188-vcodec-enc
+              - mediatek,mt8192-vcodec-enc
+              - mediatek,mt8195-vcodec-enc
+      - items:
+          - const: mediatek,mt8186-vcodec-enc
+          - const: mediatek,mt8183-vcodec-enc
   reg:
     maxItems: 1
 
-- 
2.34.1



From eugen.hristev at collabora.com  Fri Dec 15 02:45:45 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Fri, 15 Dec 2023 12:45:45 +0200
Subject: [PATCH v2 1/7] media: mediatek: vcodec: fix possible unbalanced PM counter
Message-ID: <20231215104551.233679-1-eugen.hristev@collabora.com>

It is possible that mtk_vcodec_enc_pw_on fails, and in that scenario
the PM counter is not incremented, and subsequent call to
mtk_vcodec_enc_pw_off decrements the counter, leading to a PM imbalance.
Fix by bailing out of venc_if_encode in the case when mtk_vcodec_enc_pw_on
fails.

Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
Changes in v2:
- collect R-b

 .../platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c     | 4 +++-
 .../platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h     | 2 +-
 drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c | 5 ++++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c
index a22b7dfc656e..1a2b14a3e219 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c
@@ -58,13 +58,15 @@ int mtk_vcodec_init_enc_clk(struct mtk_vcodec_enc_dev *mtkdev)
 	return 0;
 }
 
-void mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm)
+int mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm)
 {
 	int ret;
 
 	ret = pm_runtime_resume_and_get(pm->dev);
 	if (ret)
 		dev_err(pm->dev, "pm_runtime_resume_and_get fail: %d", ret);
+
+	return ret;
 }
 
 void mtk_vcodec_enc_pw_off(struct mtk_vcodec_pm *pm)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h
index 157ea08ba9e3..2e28f25e36cc 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h
@@ -10,7 +10,7 @@
 #include "mtk_vcodec_enc_drv.h"
 
 int mtk_vcodec_init_enc_clk(struct mtk_vcodec_enc_dev *dev);
-void mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm);
+int mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm);
 void mtk_vcodec_enc_pw_off(struct mtk_vcodec_pm *pm);
 void mtk_vcodec_enc_clock_on(struct mtk_vcodec_pm *pm);
 void mtk_vcodec_enc_clock_off(struct mtk_vcodec_pm *pm);
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
index c402a686f3cb..e83747b8d69a 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
@@ -64,7 +64,9 @@ int venc_if_encode(struct mtk_vcodec_enc_ctx *ctx,
 	ctx->dev->curr_ctx = ctx;
 	spin_unlock_irqrestore(&ctx->dev->irqlock, flags);
 
-	mtk_vcodec_enc_pw_on(&ctx->dev->pm);
+	ret = mtk_vcodec_enc_pw_on(&ctx->dev->pm);
+	if (ret)
+		goto venc_if_encode_pw_on_err;
 	mtk_vcodec_enc_clock_on(&ctx->dev->pm);
 	ret = ctx->enc_if->encode(ctx->drv_handle, opt, frm_buf,
 				  bs_buf, result);
@@ -75,6 +77,7 @@ int venc_if_encode(struct mtk_vcodec_enc_ctx *ctx,
 	ctx->dev->curr_ctx = NULL;
 	spin_unlock_irqrestore(&ctx->dev->irqlock, flags);
 
+venc_if_encode_pw_on_err:
 	mtk_venc_unlock(ctx);
 	return ret;
 }
-- 
2.34.1



From eugen.hristev at collabora.com  Fri Dec 15 02:45:50 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Fri, 15 Dec 2023 12:45:50 +0200
Subject: [PATCH v2 6/7] arm64: dts: mediatek: mt8186: fix VENC power domain clocks
In-Reply-To: <20231215104551.233679-1-eugen.hristev@collabora.com>
References: <20231215104551.233679-1-eugen.hristev@collabora.com>
Message-ID: <20231215104551.233679-6-eugen.hristev@collabora.com>

The larb clock is in fact a subsys clock, so it must be prefixed by
'subsys-' to be correctly identified in the driver.

Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
Changes in v2:
- none.

 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index df0c04f2ba1d..66ead3f23336 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1061,7 +1061,7 @@ power-domain at MT8186_POWER_DOMAIN_VENC {
 						reg = <MT8186_POWER_DOMAIN_VENC>;
 						clocks = <&topckgen CLK_TOP_VENC>,
 							 <&vencsys CLK_VENC_CKE1_VENC>;
-						clock-names = "venc0", "larb";
+						clock-names = "venc0", "subsys-larb";
 						mediatek,infracfg = <&infracfg_ao>;
 						#power-domain-cells = <0>;
 					};
-- 
2.34.1



From eugen.hristev at collabora.com  Fri Dec 15 02:45:51 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Fri, 15 Dec 2023 12:45:51 +0200
Subject: [PATCH v2 7/7] arm64: dts: mediatek: mt8186: Add venc node
In-Reply-To: <20231215104551.233679-1-eugen.hristev@collabora.com>
References: <20231215104551.233679-1-eugen.hristev@collabora.com>
Message-ID: <20231215104551.233679-7-eugen.hristev@collabora.com>

From: Kyrie Wu <kyrie.wu at mediatek.com>

Add video encoder node.

Signed-off-by: Kyrie Wu <kyrie.wu at mediatek.com>
Signed-off-by: Allen-KH Cheng <allen-kh.cheng at mediatek.com>
Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.org>
[eugen.hristev at collabora.com: minor cleanup]
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
Changes in v2:
- change node name
- change compatible to include 8186
- change props order
- change clock name to cope with binding


 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index 66ead3f23336..ebd07bf3d9d2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1993,6 +1993,30 @@ larb7: smi at 17010000 {
 			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
 		};
 
+		venc: video-encoder at 17020000 {
+			compatible = "mediatek,mt8186-vcodec-enc", "mediatek,mt8183-vcodec-enc";
+			reg = <0 0x17020000 0 0x2000>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			interrupts = <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH 0>;
+			iommus = <&iommu_mm IOMMU_PORT_L7_VENC_RCPU>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_REC>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_BSDMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_SV_COMV>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_RD_COMV>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_LUMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_CHROMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_LUMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_CHROMA>;
+			dma-ranges = <0x1 0x0 0x1 0x0 0x1 0x0>;
+			clocks = <&vencsys CLK_VENC_CKE1_VENC>;
+			clock-names = "venc_sel";
+			assigned-clocks = <&topckgen CLK_TOP_VENC>;
+			assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D3>;
+			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
+			mediatek,scp = <&scp>;
+		};
+
 		camsys: clock-controller at 1a000000 {
 			compatible = "mediatek,mt8186-camsys";
 			reg = <0 0x1a000000 0 0x1000>;
-- 
2.34.1



From miquel.raynal at bootlin.com  Fri Dec 15 02:59:20 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Fri, 15 Dec 2023 11:59:20 +0100
Subject: [PATCH 2/2] mtd: rawnand: rockchip: Add missing title to a kernel doc comment
In-Reply-To: <20231211150704.109138-2-miquel.raynal@bootlin.com>
Message-ID: <20231215105920.499247-1-miquel.raynal@bootlin.com>

On Mon, 2023-12-11 at 15:07:04 UTC, Miquel Raynal wrote:
> All fields of the nfc_cfg structure are documented but the name, which
> leads to a W=1 warning. Add a title.
> 
> Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
> Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.

Miquel


From miquel.raynal at bootlin.com  Fri Dec 15 02:59:26 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Fri, 15 Dec 2023 11:59:26 +0100
Subject: [PATCH 1/2] mtd: rawnand: rockchip: Rename a structure
In-Reply-To: <20231211150704.109138-1-miquel.raynal@bootlin.com>
Message-ID: <20231215105926.499291-1-miquel.raynal@bootlin.com>

On Mon, 2023-12-11 at 15:07:03 UTC, Miquel Raynal wrote:
> Robots are unhappy with the ecc_cnt_status structure because the kernel
> doc says it should be called rk_ecc_cnt_status. In general, it is
> considered a better practice to prefix all symbols in a file with the
> same prexif, and thus it seems more relevant to rename the structure
> rather than changing the kernel doc header.
> 
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312102130.geZ4dqyN-lkp at intel.com/
> Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
> Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.

Miquel


From david at sigma-star.at  Fri Dec 15 03:06:27 2023
From: david at sigma-star.at (David Gstir)
Date: Fri, 15 Dec 2023 12:06:27 +0100
Subject: [PATCH v5 0/6] DCP as trusted keys backend
Message-ID: <20231215110639.45522-1-david@sigma-star.at>

This is a revival of the previous patch set submitted by Richard Weinberger:
https://lore.kernel.org/linux-integrity/20210614201620.30451-1-richard at nod.at/

v4 is here:
https://lore.kernel.org/keyrings/20231024162024.51260-1-david at sigma-star.at/

v4 -> v5:
- Make Kconfig for trust source check scalable as suggested by Jarkko Sakkinen
- Add Acked-By from Herbert Xu to patch #1 - thanks!
v3 -> v4:
- Split changes on MAINTAINERS and documentation into dedicated patches
- Use more concise wording in commit messages as suggested by Jarkko Sakkinen
v2 -> v3:
- Addressed review comments from Jarkko Sakkinen
v1 -> v2:
- Revive and rebase to latest version
- Include review comments from Ahmad Fatoum

The Data CoProcessor (DCP) is an IP core built into many NXP SoCs such
as i.mx6ull.

Similar to the CAAM engine used in more powerful SoCs, DCP can AES-
encrypt/decrypt user data using a unique, never-disclosed,
device-specific key. Unlike CAAM though, it cannot directly wrap and
unwrap blobs in hardware. As DCP offers only the bare minimum feature
set and a blob mechanism needs aid from software. A blob in this case
is a piece of sensitive data (e.g. a key) that is encrypted and
authenticated using the device-specific key so that unwrapping can only
be done on the hardware where the blob was wrapped.

This patch series adds a DCP based, trusted-key backend and is similar
in spirit to the one by Ahmad Fatoum [0] that does the same for CAAM.
It is of interest for similar use cases as the CAAM patch set, but for
lower end devices, where CAAM is not available.

Because constructing and parsing the blob has to happen in software,
we needed to decide on a blob format and chose the following:

struct dcp_blob_fmt {
	__u8 fmt_version;
	__u8 blob_key[AES_KEYSIZE_128];
	__u8 nonce[AES_KEYSIZE_128];
	__le32 payload_len;
	__u8 payload[];
} __packed;

The `fmt_version` is currently 1.

The encrypted key is stored in the payload area. It is AES-128-GCM
encrypted using `blob_key` and `nonce`, GCM auth tag is attached at
the end of the payload (`payload_len` does not include the size of
the auth tag).

The `blob_key` itself is encrypted in AES-128-ECB mode by DCP using
the OTP or UNIQUE device key. A new `blob_key` and `nonce` are generated
randomly, when sealing/exporting the DCP blob.

This patchset was tested with dm-crypt on an i.MX6ULL board.

[0] https://lore.kernel.org/keyrings/20220513145705.2080323-1-a.fatoum at pengutronix.de/

David Gstir (6):
  crypto: mxs-dcp: Add support for hardware-bound keys
  KEYS: trusted: improve scalability of trust source config
  KEYS: trusted: Introduce NXP DCP-backed trusted keys
  MAINTAINERS: add entry for DCP-based trusted keys
  docs: document DCP-backed trusted keys kernel params
  docs: trusted-encrypted: add DCP as new trust source

 .../admin-guide/kernel-parameters.txt         |  13 +
 .../security/keys/trusted-encrypted.rst       |  85 +++++
 MAINTAINERS                                   |   9 +
 drivers/crypto/mxs-dcp.c                      | 104 +++++-
 include/keys/trusted_dcp.h                    |  11 +
 include/soc/fsl/dcp.h                         |  17 +
 security/keys/trusted-keys/Kconfig            |  18 +-
 security/keys/trusted-keys/Makefile           |   2 +
 security/keys/trusted-keys/trusted_core.c     |   6 +-
 security/keys/trusted-keys/trusted_dcp.c      | 311 ++++++++++++++++++
 10 files changed, 562 insertions(+), 14 deletions(-)
 create mode 100644 include/keys/trusted_dcp.h
 create mode 100644 include/soc/fsl/dcp.h
 create mode 100644 security/keys/trusted-keys/trusted_dcp.c

-- 
2.35.3



From david at sigma-star.at  Fri Dec 15 03:06:28 2023
From: david at sigma-star.at (David Gstir)
Date: Fri, 15 Dec 2023 12:06:28 +0100
Subject: [PATCH v5 1/6] crypto: mxs-dcp: Add support for hardware-bound keys
In-Reply-To: <20231215110639.45522-1-david@sigma-star.at>
References: <20231215110639.45522-1-david@sigma-star.at>
Message-ID: <20231215110639.45522-2-david@sigma-star.at>

DCP is capable of performing AES with two hardware-bound keys:

- The one-time programmable (OTP) key which is burnt via on-chip fuses
- The unique key (UK) which is derived from the OTP key

In addition to the two hardware-bound keys, DCP also supports
storing keys in 4 dedicated key slots within its secure memory area
(internal SRAM).

These keys are not stored in main memory and are therefore
not directly accessible by the operating system. To use them
for AES operations, a one-byte key reference has to supplied
with the DCP operation descriptor in the control register.

This adds support for using any of these 6 keys through the crypto API
via their key reference after they have been set up. The main purpose
is to add support for DCP-backed trusted keys. Other use cases are
possible too (see similar existing paes implementations), but these
should carefully be evaluated as e.g. enabling AF_ALG will give
userspace full access to use keys. In scenarios with untrustworthy
userspace, this will enable en-/decryption oracles.

Co-developed-by: Richard Weinberger <richard at nod.at>
Signed-off-by: Richard Weinberger <richard at nod.at>
Co-developed-by: David Oberhollenzer <david.oberhollenzer at sigma-star.at>
Signed-off-by: David Oberhollenzer <david.oberhollenzer at sigma-star.at>
Signed-off-by: David Gstir <david at sigma-star.at>
Acked-by: Herbert Xu <herbert at gondor.apana.org.au>
---
 drivers/crypto/mxs-dcp.c | 104 ++++++++++++++++++++++++++++++++++-----
 include/soc/fsl/dcp.h    |  17 +++++++
 2 files changed, 110 insertions(+), 11 deletions(-)
 create mode 100644 include/soc/fsl/dcp.h

diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index f6b7bce0e656..2dc664fb2faf 100644
--- a/drivers/crypto/mxs-dcp.c
+++ b/drivers/crypto/mxs-dcp.c
@@ -15,6 +15,7 @@
 #include <linux/platform_device.h>
 #include <linux/stmp_device.h>
 #include <linux/clk.h>
+#include <soc/fsl/dcp.h>
 
 #include <crypto/aes.h>
 #include <crypto/sha1.h>
@@ -101,6 +102,7 @@ struct dcp_async_ctx {
 	struct crypto_skcipher		*fallback;
 	unsigned int			key_len;
 	uint8_t				key[AES_KEYSIZE_128];
+	bool				key_referenced;
 };
 
 struct dcp_aes_req_ctx {
@@ -155,6 +157,7 @@ static struct dcp *global_sdcp;
 #define MXS_DCP_CONTROL0_HASH_TERM		(1 << 13)
 #define MXS_DCP_CONTROL0_HASH_INIT		(1 << 12)
 #define MXS_DCP_CONTROL0_PAYLOAD_KEY		(1 << 11)
+#define MXS_DCP_CONTROL0_OTP_KEY		(1 << 10)
 #define MXS_DCP_CONTROL0_CIPHER_ENCRYPT		(1 << 8)
 #define MXS_DCP_CONTROL0_CIPHER_INIT		(1 << 9)
 #define MXS_DCP_CONTROL0_ENABLE_HASH		(1 << 6)
@@ -168,6 +171,8 @@ static struct dcp *global_sdcp;
 #define MXS_DCP_CONTROL1_CIPHER_MODE_ECB	(0 << 4)
 #define MXS_DCP_CONTROL1_CIPHER_SELECT_AES128	(0 << 0)
 
+#define MXS_DCP_CONTROL1_KEY_SELECT_SHIFT	8
+
 static int mxs_dcp_start_dma(struct dcp_async_ctx *actx)
 {
 	int dma_err;
@@ -224,13 +229,16 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
 	struct dcp *sdcp = global_sdcp;
 	struct dcp_dma_desc *desc = &sdcp->coh->desc[actx->chan];
 	struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req);
+	bool key_referenced = actx->key_referenced;
 	int ret;
 
-	key_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_key,
-				  2 * AES_KEYSIZE_128, DMA_TO_DEVICE);
-	ret = dma_mapping_error(sdcp->dev, key_phys);
-	if (ret)
-		return ret;
+	if (!key_referenced) {
+		key_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_key,
+					  2 * AES_KEYSIZE_128, DMA_TO_DEVICE);
+		ret = dma_mapping_error(sdcp->dev, key_phys);
+		if (ret)
+			return ret;
+	}
 
 	src_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_in_buf,
 				  DCP_BUF_SZ, DMA_TO_DEVICE);
@@ -255,8 +263,12 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
 		    MXS_DCP_CONTROL0_INTERRUPT |
 		    MXS_DCP_CONTROL0_ENABLE_CIPHER;
 
-	/* Payload contains the key. */
-	desc->control0 |= MXS_DCP_CONTROL0_PAYLOAD_KEY;
+	if (key_referenced)
+		/* Set OTP key bit to select the key via KEY_SELECT. */
+		desc->control0 |= MXS_DCP_CONTROL0_OTP_KEY;
+	else
+		/* Payload contains the key. */
+		desc->control0 |= MXS_DCP_CONTROL0_PAYLOAD_KEY;
 
 	if (rctx->enc)
 		desc->control0 |= MXS_DCP_CONTROL0_CIPHER_ENCRYPT;
@@ -270,6 +282,9 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
 	else
 		desc->control1 |= MXS_DCP_CONTROL1_CIPHER_MODE_CBC;
 
+	if (key_referenced)
+		desc->control1 |= sdcp->coh->aes_key[0] << MXS_DCP_CONTROL1_KEY_SELECT_SHIFT;
+
 	desc->next_cmd_addr = 0;
 	desc->source = src_phys;
 	desc->destination = dst_phys;
@@ -284,9 +299,9 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
 err_dst:
 	dma_unmap_single(sdcp->dev, src_phys, DCP_BUF_SZ, DMA_TO_DEVICE);
 err_src:
-	dma_unmap_single(sdcp->dev, key_phys, 2 * AES_KEYSIZE_128,
-			 DMA_TO_DEVICE);
-
+	if (!key_referenced)
+		dma_unmap_single(sdcp->dev, key_phys, 2 * AES_KEYSIZE_128,
+				 DMA_TO_DEVICE);
 	return ret;
 }
 
@@ -453,7 +468,7 @@ static int mxs_dcp_aes_enqueue(struct skcipher_request *req, int enc, int ecb)
 	struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req);
 	int ret;
 
-	if (unlikely(actx->key_len != AES_KEYSIZE_128))
+	if (unlikely(actx->key_len != AES_KEYSIZE_128 && !actx->key_referenced))
 		return mxs_dcp_block_fallback(req, enc);
 
 	rctx->enc = enc;
@@ -500,6 +515,7 @@ static int mxs_dcp_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
 	 * there can still be an operation in progress.
 	 */
 	actx->key_len = len;
+	actx->key_referenced = false;
 	if (len == AES_KEYSIZE_128) {
 		memcpy(actx->key, key, len);
 		return 0;
@@ -516,6 +532,32 @@ static int mxs_dcp_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
 	return crypto_skcipher_setkey(actx->fallback, key, len);
 }
 
+static int mxs_dcp_aes_setrefkey(struct crypto_skcipher *tfm, const u8 *key,
+				 unsigned int len)
+{
+	struct dcp_async_ctx *actx = crypto_skcipher_ctx(tfm);
+
+	if (len != DCP_PAES_KEYSIZE)
+		return -EINVAL;
+
+	switch (key[0]) {
+	case DCP_PAES_KEY_SLOT0:
+	case DCP_PAES_KEY_SLOT1:
+	case DCP_PAES_KEY_SLOT2:
+	case DCP_PAES_KEY_SLOT3:
+	case DCP_PAES_KEY_UNIQUE:
+	case DCP_PAES_KEY_OTP:
+		memcpy(actx->key, key, len);
+		actx->key_len = len;
+		actx->key_referenced = true;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 static int mxs_dcp_aes_fallback_init_tfm(struct crypto_skcipher *tfm)
 {
 	const char *name = crypto_tfm_alg_name(crypto_skcipher_tfm(tfm));
@@ -539,6 +581,13 @@ static void mxs_dcp_aes_fallback_exit_tfm(struct crypto_skcipher *tfm)
 	crypto_free_skcipher(actx->fallback);
 }
 
+static int mxs_dcp_paes_init_tfm(struct crypto_skcipher *tfm)
+{
+	crypto_skcipher_set_reqsize(tfm, sizeof(struct dcp_aes_req_ctx));
+
+	return 0;
+}
+
 /*
  * Hashing (SHA1/SHA256)
  */
@@ -889,6 +938,39 @@ static struct skcipher_alg dcp_aes_algs[] = {
 		.ivsize			= AES_BLOCK_SIZE,
 		.init			= mxs_dcp_aes_fallback_init_tfm,
 		.exit			= mxs_dcp_aes_fallback_exit_tfm,
+	}, {
+		.base.cra_name		= "ecb(paes)",
+		.base.cra_driver_name	= "ecb-paes-dcp",
+		.base.cra_priority	= 401,
+		.base.cra_alignmask	= 15,
+		.base.cra_flags		= CRYPTO_ALG_ASYNC | CRYPTO_ALG_INTERNAL,
+		.base.cra_blocksize	= AES_BLOCK_SIZE,
+		.base.cra_ctxsize	= sizeof(struct dcp_async_ctx),
+		.base.cra_module	= THIS_MODULE,
+
+		.min_keysize		= DCP_PAES_KEYSIZE,
+		.max_keysize		= DCP_PAES_KEYSIZE,
+		.setkey			= mxs_dcp_aes_setrefkey,
+		.encrypt		= mxs_dcp_aes_ecb_encrypt,
+		.decrypt		= mxs_dcp_aes_ecb_decrypt,
+		.init			= mxs_dcp_paes_init_tfm,
+	}, {
+		.base.cra_name		= "cbc(paes)",
+		.base.cra_driver_name	= "cbc-paes-dcp",
+		.base.cra_priority	= 401,
+		.base.cra_alignmask	= 15,
+		.base.cra_flags		= CRYPTO_ALG_ASYNC | CRYPTO_ALG_INTERNAL,
+		.base.cra_blocksize	= AES_BLOCK_SIZE,
+		.base.cra_ctxsize	= sizeof(struct dcp_async_ctx),
+		.base.cra_module	= THIS_MODULE,
+
+		.min_keysize		= DCP_PAES_KEYSIZE,
+		.max_keysize		= DCP_PAES_KEYSIZE,
+		.setkey			= mxs_dcp_aes_setrefkey,
+		.encrypt		= mxs_dcp_aes_cbc_encrypt,
+		.decrypt		= mxs_dcp_aes_cbc_decrypt,
+		.ivsize			= AES_BLOCK_SIZE,
+		.init			= mxs_dcp_paes_init_tfm,
 	},
 };
 
diff --git a/include/soc/fsl/dcp.h b/include/soc/fsl/dcp.h
new file mode 100644
index 000000000000..cda89e260c46
--- /dev/null
+++ b/include/soc/fsl/dcp.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2021 sigma star gmbh
+ */
+
+#ifndef MXS_DCP_H
+#define MXS_DCP_H
+
+#define DCP_PAES_KEYSIZE 1
+#define DCP_PAES_KEY_SLOT0 0x00
+#define DCP_PAES_KEY_SLOT1 0x01
+#define DCP_PAES_KEY_SLOT2 0x02
+#define DCP_PAES_KEY_SLOT3 0x03
+#define DCP_PAES_KEY_UNIQUE 0xfe
+#define DCP_PAES_KEY_OTP 0xff
+
+#endif /* MXS_DCP_H */
-- 
2.35.3



From david at sigma-star.at  Fri Dec 15 03:06:29 2023
From: david at sigma-star.at (David Gstir)
Date: Fri, 15 Dec 2023 12:06:29 +0100
Subject: [PATCH v5 2/6] KEYS: trusted: improve scalability of trust source config
In-Reply-To: <20231215110639.45522-1-david@sigma-star.at>
References: <20231215110639.45522-1-david@sigma-star.at>
Message-ID: <20231215110639.45522-3-david@sigma-star.at>

Checking if at least one valid trust source is selected does not scale
and becomes hard to read. This improves this in preparation for the DCP
trust source.

Signed-off-by: David Gstir <david at sigma-star.at>
---
 security/keys/trusted-keys/Kconfig | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
index dbfdd8536468..553dc117f385 100644
--- a/security/keys/trusted-keys/Kconfig
+++ b/security/keys/trusted-keys/Kconfig
@@ -1,3 +1,6 @@
+config HAVE_TRUSTED_KEYS
+	bool
+
 config TRUSTED_KEYS_TPM
 	bool "TPM-based trusted keys"
 	depends on TCG_TPM >= TRUSTED_KEYS
@@ -9,6 +12,7 @@ config TRUSTED_KEYS_TPM
 	select ASN1_ENCODER
 	select OID_REGISTRY
 	select ASN1
+	select HAVE_TRUSTED_KEYS
 	help
 	  Enable use of the Trusted Platform Module (TPM) as trusted key
 	  backend. Trusted keys are random number symmetric keys,
@@ -20,6 +24,7 @@ config TRUSTED_KEYS_TEE
 	bool "TEE-based trusted keys"
 	depends on TEE >= TRUSTED_KEYS
 	default y
+	select HAVE_TRUSTED_KEYS
 	help
 	  Enable use of the Trusted Execution Environment (TEE) as trusted
 	  key backend.
@@ -29,10 +34,11 @@ config TRUSTED_KEYS_CAAM
 	depends on CRYPTO_DEV_FSL_CAAM_JR >= TRUSTED_KEYS
 	select CRYPTO_DEV_FSL_CAAM_BLOB_GEN
 	default y
+	select HAVE_TRUSTED_KEYS
 	help
 	  Enable use of NXP's Cryptographic Accelerator and Assurance Module
 	  (CAAM) as trusted key backend.
 
-if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE && !TRUSTED_KEYS_CAAM
-comment "No trust source selected!"
+if !HAVE_TRUSTED_KEYS
+	comment "No trust source selected!"
 endif
-- 
2.35.3



From david at sigma-star.at  Fri Dec 15 03:06:30 2023
From: david at sigma-star.at (David Gstir)
Date: Fri, 15 Dec 2023 12:06:30 +0100
Subject: [PATCH v5 3/6] KEYS: trusted: Introduce NXP DCP-backed trusted keys
In-Reply-To: <20231215110639.45522-1-david@sigma-star.at>
References: <20231215110639.45522-1-david@sigma-star.at>
Message-ID: <20231215110639.45522-4-david@sigma-star.at>

DCP (Data Co-Processor) is the little brother of NXP's CAAM IP.
Beside of accelerated crypto operations, it also offers support for
hardware-bound keys. Using this feature it is possible to implement a blob
mechanism similar to what CAAM offers. Unlike on CAAM, constructing and
parsing the blob has to happen in software (i.e. the kernel).

The software-based blob format used by DCP trusted keys encrypts
the payload using AES-128-GCM with a freshly generated random key and nonce.
The random key itself is AES-128-ECB encrypted using the DCP unique
or OTP key.

The DCP trusted key blob format is:
/*
 * struct dcp_blob_fmt - DCP BLOB format.
 *
 * @fmt_version: Format version, currently being %1
 * @blob_key: Random AES 128 key which is used to encrypt @payload,
 *            @blob_key itself is encrypted with OTP or UNIQUE device key in
 *            AES-128-ECB mode by DCP.
 * @nonce: Random nonce used for @payload encryption.
 * @payload_len: Length of the plain text @payload.
 * @payload: The payload itself, encrypted using AES-128-GCM and @blob_key,
 *           GCM auth tag of size AES_BLOCK_SIZE is attached at the end of it.
 *
 * The total size of a DCP BLOB is sizeof(struct dcp_blob_fmt) + @payload_len +
 * AES_BLOCK_SIZE.
 */
struct dcp_blob_fmt {
	__u8 fmt_version;
	__u8 blob_key[AES_KEYSIZE_128];
	__u8 nonce[AES_KEYSIZE_128];
	__le32 payload_len;
	__u8 payload[];
} __packed;

By default the unique key is used. It is also possible to use the
OTP key. While the unique key should be unique it is not documented how
this key is derived. Therefore selection the OTP key is supported as
well via the use_otp_key module parameter.

Co-developed-by: Richard Weinberger <richard at nod.at>
Signed-off-by: Richard Weinberger <richard at nod.at>
Co-developed-by: David Oberhollenzer <david.oberhollenzer at sigma-star.at>
Signed-off-by: David Oberhollenzer <david.oberhollenzer at sigma-star.at>
Signed-off-by: David Gstir <david at sigma-star.at>
---
 include/keys/trusted_dcp.h                |  11 +
 security/keys/trusted-keys/Kconfig        |   8 +
 security/keys/trusted-keys/Makefile       |   2 +
 security/keys/trusted-keys/trusted_core.c |   6 +-
 security/keys/trusted-keys/trusted_dcp.c  | 311 ++++++++++++++++++++++
 5 files changed, 337 insertions(+), 1 deletion(-)
 create mode 100644 include/keys/trusted_dcp.h
 create mode 100644 security/keys/trusted-keys/trusted_dcp.c

diff --git a/include/keys/trusted_dcp.h b/include/keys/trusted_dcp.h
new file mode 100644
index 000000000000..9aaa42075b40
--- /dev/null
+++ b/include/keys/trusted_dcp.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2021 sigma star gmbh
+ */
+
+#ifndef TRUSTED_DCP_H
+#define TRUSTED_DCP_H
+
+extern struct trusted_key_ops dcp_trusted_key_ops;
+
+#endif
diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
index 553dc117f385..1fb8aa001995 100644
--- a/security/keys/trusted-keys/Kconfig
+++ b/security/keys/trusted-keys/Kconfig
@@ -39,6 +39,14 @@ config TRUSTED_KEYS_CAAM
 	  Enable use of NXP's Cryptographic Accelerator and Assurance Module
 	  (CAAM) as trusted key backend.
 
+config TRUSTED_KEYS_DCP
+	bool "DCP-based trusted keys"
+	depends on CRYPTO_DEV_MXS_DCP >= TRUSTED_KEYS
+	default y
+	select HAVE_TRUSTED_KEYS
+	help
+	  Enable use of NXP's DCP (Data Co-Processor) as trusted key backend.
+
 if !HAVE_TRUSTED_KEYS
 	comment "No trust source selected!"
 endif
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index 735aa0bc08ef..f0f3b27f688b 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -14,3 +14,5 @@ trusted-$(CONFIG_TRUSTED_KEYS_TPM) += tpm2key.asn1.o
 trusted-$(CONFIG_TRUSTED_KEYS_TEE) += trusted_tee.o
 
 trusted-$(CONFIG_TRUSTED_KEYS_CAAM) += trusted_caam.o
+
+trusted-$(CONFIG_TRUSTED_KEYS_DCP) += trusted_dcp.o
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index c6fc50d67214..8af0988be850 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -10,6 +10,7 @@
 #include <keys/trusted-type.h>
 #include <keys/trusted_tee.h>
 #include <keys/trusted_caam.h>
+#include <keys/trusted_dcp.h>
 #include <keys/trusted_tpm.h>
 #include <linux/capability.h>
 #include <linux/err.h>
@@ -30,7 +31,7 @@ MODULE_PARM_DESC(rng, "Select trusted key RNG");
 
 static char *trusted_key_source;
 module_param_named(source, trusted_key_source, charp, 0);
-MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)");
+MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee, caam or dcp)");
 
 static const struct trusted_key_source trusted_key_sources[] = {
 #if defined(CONFIG_TRUSTED_KEYS_TPM)
@@ -42,6 +43,9 @@ static const struct trusted_key_source trusted_key_sources[] = {
 #if defined(CONFIG_TRUSTED_KEYS_CAAM)
 	{ "caam", &trusted_key_caam_ops },
 #endif
+#if defined(CONFIG_TRUSTED_KEYS_DCP)
+	{ "dcp", &dcp_trusted_key_ops },
+#endif
 };
 
 DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
diff --git a/security/keys/trusted-keys/trusted_dcp.c b/security/keys/trusted-keys/trusted_dcp.c
new file mode 100644
index 000000000000..8d19b92fe976
--- /dev/null
+++ b/security/keys/trusted-keys/trusted_dcp.c
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021 sigma star gmbh
+ */
+
+#include <crypto/aead.h>
+#include <crypto/aes.h>
+#include <crypto/algapi.h>
+#include <crypto/gcm.h>
+#include <crypto/skcipher.h>
+#include <keys/trusted-type.h>
+#include <linux/key-type.h>
+#include <linux/module.h>
+#include <linux/printk.h>
+#include <linux/random.h>
+#include <linux/scatterlist.h>
+#include <soc/fsl/dcp.h>
+
+#define DCP_BLOB_VERSION 1
+#define DCP_BLOB_AUTHLEN 16
+
+/**
+ * struct dcp_blob_fmt - DCP BLOB format.
+ *
+ * @fmt_version: Format version, currently being %1.
+ * @blob_key: Random AES 128 key which is used to encrypt @payload,
+ *            @blob_key itself is encrypted with OTP or UNIQUE device key in
+ *            AES-128-ECB mode by DCP.
+ * @nonce: Random nonce used for @payload encryption.
+ * @payload_len: Length of the plain text @payload.
+ * @payload: The payload itself, encrypted using AES-128-GCM and @blob_key,
+ *           GCM auth tag of size DCP_BLOB_AUTHLEN is attached at the end of it.
+ *
+ * The total size of a DCP BLOB is sizeof(struct dcp_blob_fmt) + @payload_len +
+ * DCP_BLOB_AUTHLEN.
+ */
+struct dcp_blob_fmt {
+	__u8 fmt_version;
+	__u8 blob_key[AES_KEYSIZE_128];
+	__u8 nonce[AES_KEYSIZE_128];
+	__le32 payload_len;
+	__u8 payload[];
+} __packed;
+
+static bool use_otp_key;
+module_param_named(dcp_use_otp_key, use_otp_key, bool, 0);
+MODULE_PARM_DESC(dcp_use_otp_key, "Use OTP instead of UNIQUE key for sealing");
+
+static bool skip_zk_test;
+module_param_named(dcp_skip_zk_test, skip_zk_test, bool, 0);
+MODULE_PARM_DESC(dcp_skip_zk_test, "Don't test whether device keys are zero'ed");
+
+static unsigned int calc_blob_len(unsigned int payload_len)
+{
+	return sizeof(struct dcp_blob_fmt) + payload_len + DCP_BLOB_AUTHLEN;
+}
+
+static int do_dcp_crypto(u8 *in, u8 *out, bool is_encrypt)
+{
+	int res = 0;
+	struct skcipher_request *req = NULL;
+	DECLARE_CRYPTO_WAIT(wait);
+	struct scatterlist src_sg, dst_sg;
+	struct crypto_skcipher *tfm;
+	u8 paes_key[DCP_PAES_KEYSIZE];
+
+	if (use_otp_key)
+		paes_key[0] = DCP_PAES_KEY_OTP;
+	else
+		paes_key[0] = DCP_PAES_KEY_UNIQUE;
+
+	tfm = crypto_alloc_skcipher("ecb-paes-dcp", CRYPTO_ALG_INTERNAL,
+				    CRYPTO_ALG_INTERNAL);
+	if (IS_ERR(tfm)) {
+		res = PTR_ERR(tfm);
+		pr_err("Unable to request DCP pAES-ECB cipher: %i\n", res);
+		tfm = NULL;
+		goto out;
+	}
+
+	req = skcipher_request_alloc(tfm, GFP_NOFS);
+	if (!req) {
+		res = -ENOMEM;
+		goto out;
+	}
+
+	skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG |
+				      CRYPTO_TFM_REQ_MAY_SLEEP,
+				      crypto_req_done, &wait);
+	res = crypto_skcipher_setkey(tfm, paes_key, sizeof(paes_key));
+	if (res < 0)
+		goto out;
+
+	sg_init_one(&src_sg, in, AES_KEYSIZE_128);
+	sg_init_one(&dst_sg, out, AES_KEYSIZE_128);
+	skcipher_request_set_crypt(req, &src_sg, &dst_sg, AES_KEYSIZE_128,
+				   NULL);
+
+	if (is_encrypt)
+		res = crypto_wait_req(crypto_skcipher_encrypt(req), &wait);
+	else
+		res = crypto_wait_req(crypto_skcipher_decrypt(req), &wait);
+
+out:
+	skcipher_request_free(req);
+	crypto_free_skcipher(tfm);
+
+	return res;
+}
+
+static int do_aead_crypto(u8 *in, u8 *out, size_t len, u8 *key, u8 *nonce,
+			  bool is_encrypt)
+{
+	struct aead_request *aead_req = NULL;
+	struct scatterlist src_sg, dst_sg;
+	struct crypto_aead *aead;
+	int ret;
+
+	aead = crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG_ASYNC);
+	if (IS_ERR(aead)) {
+		ret = PTR_ERR(aead);
+		pr_err("Unable to request AES-GCM cipher: %i\n", ret);
+		goto out;
+	}
+
+	ret = crypto_aead_setauthsize(aead, DCP_BLOB_AUTHLEN);
+	if (ret < 0) {
+		pr_err("Can't set crypto auth tag len: %d\n", ret);
+		goto free_aead;
+	}
+
+	aead_req = aead_request_alloc(aead, GFP_KERNEL);
+	if (!aead_req) {
+		ret = -ENOMEM;
+		goto free_aead;
+	}
+
+	sg_init_one(&src_sg, in, len);
+	if (is_encrypt) {
+		/*
+		 * If we encrypt our buffer has extra space for the auth tag.
+		 */
+		sg_init_one(&dst_sg, out, len + DCP_BLOB_AUTHLEN);
+	} else {
+		sg_init_one(&dst_sg, out, len);
+	}
+
+	aead_request_set_crypt(aead_req, &src_sg, &dst_sg, len, nonce);
+	aead_request_set_callback(aead_req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL,
+				  NULL);
+	aead_request_set_ad(aead_req, 0);
+
+	if (crypto_aead_setkey(aead, key, AES_KEYSIZE_128)) {
+		pr_err("Can't set crypto AEAD key\n");
+		ret = -EINVAL;
+		goto free_req;
+	}
+
+	if (is_encrypt)
+		ret = crypto_aead_encrypt(aead_req);
+	else
+		ret = crypto_aead_decrypt(aead_req);
+
+free_req:
+	aead_request_free(aead_req);
+free_aead:
+	crypto_free_aead(aead);
+out:
+	return ret;
+}
+
+static int decrypt_blob_key(u8 *key)
+{
+	return do_dcp_crypto(key, key, false);
+}
+
+static int encrypt_blob_key(u8 *key)
+{
+	return do_dcp_crypto(key, key, true);
+}
+
+static int trusted_dcp_seal(struct trusted_key_payload *p, char *datablob)
+{
+	struct dcp_blob_fmt *b = (struct dcp_blob_fmt *)p->blob;
+	int blen, ret;
+
+	blen = calc_blob_len(p->key_len);
+	if (blen > MAX_BLOB_SIZE)
+		return -E2BIG;
+
+	b->fmt_version = DCP_BLOB_VERSION;
+	get_random_bytes(b->nonce, AES_KEYSIZE_128);
+	get_random_bytes(b->blob_key, AES_KEYSIZE_128);
+
+	ret = do_aead_crypto(p->key, b->payload, p->key_len, b->blob_key,
+			     b->nonce, true);
+	if (ret) {
+		pr_err("Unable to encrypt blob payload: %i\n", ret);
+		return ret;
+	}
+
+	ret = encrypt_blob_key(b->blob_key);
+	if (ret) {
+		pr_err("Unable to encrypt blob key: %i\n", ret);
+		return ret;
+	}
+
+	b->payload_len = get_unaligned_le32(&p->key_len);
+	p->blob_len = blen;
+	return 0;
+}
+
+static int trusted_dcp_unseal(struct trusted_key_payload *p, char *datablob)
+{
+	struct dcp_blob_fmt *b = (struct dcp_blob_fmt *)p->blob;
+	int blen, ret;
+
+	if (b->fmt_version != DCP_BLOB_VERSION) {
+		pr_err("DCP blob has bad version: %i, expected %i\n",
+		       b->fmt_version, DCP_BLOB_VERSION);
+		ret = -EINVAL;
+		goto out;
+	}
+
+	p->key_len = le32_to_cpu(b->payload_len);
+	blen = calc_blob_len(p->key_len);
+	if (blen != p->blob_len) {
+		pr_err("DCP blob has bad length: %i != %i\n", blen,
+		       p->blob_len);
+		ret = -EINVAL;
+		goto out;
+	}
+
+	ret = decrypt_blob_key(b->blob_key);
+	if (ret) {
+		pr_err("Unable to decrypt blob key: %i\n", ret);
+		goto out;
+	}
+
+	ret = do_aead_crypto(b->payload, p->key, p->key_len + DCP_BLOB_AUTHLEN,
+			     b->blob_key, b->nonce, false);
+	if (ret) {
+		pr_err("Unwrap of DCP payload failed: %i\n", ret);
+		goto out;
+	}
+
+	ret = 0;
+out:
+	return ret;
+}
+
+static int test_for_zero_key(void)
+{
+	static const u8 bad[] = {0x9a, 0xda, 0xe0, 0x54, 0xf6, 0x3d, 0xfa, 0xff,
+				 0x5e, 0xa1, 0x8e, 0x45, 0xed, 0xf6, 0xea, 0x6f};
+	void *buf = NULL;
+	int ret = 0;
+
+	if (skip_zk_test)
+		goto out;
+
+	buf = kmalloc(AES_BLOCK_SIZE, GFP_KERNEL);
+	if (!buf) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	memset(buf, 0x55, AES_BLOCK_SIZE);
+
+	ret = do_dcp_crypto(buf, buf, true);
+	if (ret)
+		goto out;
+
+	if (memcmp(buf, bad, AES_BLOCK_SIZE) == 0) {
+		pr_err("Device neither in secure nor trusted mode!\n");
+		ret = -EINVAL;
+	}
+out:
+	kfree(buf);
+	return ret;
+}
+
+static int trusted_dcp_init(void)
+{
+	int ret;
+
+	if (use_otp_key)
+		pr_info("Using DCP OTP key\n");
+
+	ret = test_for_zero_key();
+	if (ret) {
+		pr_err("Test for zero'ed keys failed: %i\n", ret);
+
+		return -EINVAL;
+	}
+
+	return register_key_type(&key_type_trusted);
+}
+
+static void trusted_dcp_exit(void)
+{
+	unregister_key_type(&key_type_trusted);
+}
+
+struct trusted_key_ops dcp_trusted_key_ops = {
+	.exit = trusted_dcp_exit,
+	.init = trusted_dcp_init,
+	.seal = trusted_dcp_seal,
+	.unseal = trusted_dcp_unseal,
+	.migratable = 0,
+};
-- 
2.35.3



From david at sigma-star.at  Fri Dec 15 03:06:31 2023
From: david at sigma-star.at (David Gstir)
Date: Fri, 15 Dec 2023 12:06:31 +0100
Subject: [PATCH v5 4/6] MAINTAINERS: add entry for DCP-based trusted keys
In-Reply-To: <20231215110639.45522-1-david@sigma-star.at>
References: <20231215110639.45522-1-david@sigma-star.at>
Message-ID: <20231215110639.45522-5-david@sigma-star.at>

This covers trusted keys backed by NXP's DCP (Data Co-Processor) chip
found in smaller i.MX SoCs.

Signed-off-by: David Gstir <david at sigma-star.at>
---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 90f13281d297..988d01226131 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11647,6 +11647,15 @@ S:	Maintained
 F:	include/keys/trusted_caam.h
 F:	security/keys/trusted-keys/trusted_caam.c
 
+KEYS-TRUSTED-DCP
+M:	David Gstir <david at sigma-star.at>
+R:	sigma star Kernel Team <upstream+dcp at sigma-star.at>
+L:	linux-integrity at vger.kernel.org
+L:	keyrings at vger.kernel.org
+S:	Supported
+F:	include/keys/trusted_dcp.h
+F:	security/keys/trusted-keys/trusted_dcp.c
+
 KEYS-TRUSTED-TEE
 M:	Sumit Garg <sumit.garg at linaro.org>
 L:	linux-integrity at vger.kernel.org
-- 
2.35.3



From david at sigma-star.at  Fri Dec 15 03:06:32 2023
From: david at sigma-star.at (David Gstir)
Date: Fri, 15 Dec 2023 12:06:32 +0100
Subject: [PATCH v5 5/6] docs: document DCP-backed trusted keys kernel params
In-Reply-To: <20231215110639.45522-1-david@sigma-star.at>
References: <20231215110639.45522-1-david@sigma-star.at>
Message-ID: <20231215110639.45522-6-david@sigma-star.at>

Document the kernel parameters trusted.dcp_use_otp_key
and trusted.dcp_skip_zk_test for DCP-backed trusted keys.

Co-developed-by: Richard Weinberger <richard at nod.at>
Signed-off-by: Richard Weinberger <richard at nod.at>
Co-developed-by: David Oberhollenzer <david.oberhollenzer at sigma-star.at>
Signed-off-by: David Oberhollenzer <david.oberhollenzer at sigma-star.at>
Signed-off-by: David Gstir <david at sigma-star.at>
---
 Documentation/admin-guide/kernel-parameters.txt | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0a1731a0f0ef..c11eda8b38e0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6566,6 +6566,7 @@
 			- "tpm"
 			- "tee"
 			- "caam"
+			- "dcp"
 			If not specified then it defaults to iterating through
 			the trust source list starting with TPM and assigns the
 			first trust source as a backend which is initialized
@@ -6581,6 +6582,18 @@
 			If not specified, "default" is used. In this case,
 			the RNG's choice is left to each individual trust source.
 
+	trusted.dcp_use_otp_key
+			This is intended to be used in combination with
+			trusted.source=dcp and will select the DCP OTP key
+			instead of the DCP UNIQUE key blob encryption.
+
+	trusted.dcp_skip_zk_test
+			This is intended to be used in combination with
+			trusted.source=dcp and will disable the check if all
+			the blob key is zero'ed. This is helpful for situations where
+			having this key zero'ed is acceptable. E.g. in testing
+			scenarios.
+
 	tsc=		Disable clocksource stability checks for TSC.
 			Format: <string>
 			[x86] reliable: mark tsc clocksource as reliable, this
-- 
2.35.3



From david at sigma-star.at  Fri Dec 15 03:06:33 2023
From: david at sigma-star.at (David Gstir)
Date: Fri, 15 Dec 2023 12:06:33 +0100
Subject: [PATCH v5 6/6] docs: trusted-encrypted: add DCP as new trust source
In-Reply-To: <20231215110639.45522-1-david@sigma-star.at>
References: <20231215110639.45522-1-david@sigma-star.at>
Message-ID: <20231215110639.45522-7-david@sigma-star.at>

Update the documentation for trusted and encrypted KEYS with DCP as new
trust source:

- Describe security properties of DCP trust source
- Describe key usage
- Document blob format

Co-developed-by: Richard Weinberger <richard at nod.at>
Signed-off-by: Richard Weinberger <richard at nod.at>
Co-developed-by: David Oberhollenzer <david.oberhollenzer at sigma-star.at>
Signed-off-by: David Oberhollenzer <david.oberhollenzer at sigma-star.at>
Signed-off-by: David Gstir <david at sigma-star.at>
---
 .../security/keys/trusted-encrypted.rst       | 85 +++++++++++++++++++
 1 file changed, 85 insertions(+)

diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 9bc9db8ec651..4452070afbe9 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -42,6 +42,14 @@ safe.
          randomly generated and fused into each SoC at manufacturing time.
          Otherwise, a common fixed test key is used instead.
 
+     (4) DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs)
+
+         Rooted to a one-time programmable key (OTP) that is generally burnt
+         in the on-chip fuses and is accessible to the DCP encryption engine only.
+         DCP provides two keys that can be used as root of trust: the OTP key
+         and the UNIQUE key. Default is to use the UNIQUE key, but selecting
+         the OTP key can be done via a module parameter (dcp_use_otp_key).
+
   *  Execution isolation
 
      (1) TPM
@@ -57,6 +65,12 @@ safe.
 
          Fixed set of operations running in isolated execution environment.
 
+     (4) DCP
+
+         Fixed set of cryptographic operations running in isolated execution
+         environment. Only basic blob key encryption is executed there.
+         The actual key sealing/unsealing is done on main processor/kernel space.
+
   * Optional binding to platform integrity state
 
      (1) TPM
@@ -79,6 +93,11 @@ safe.
          Relies on the High Assurance Boot (HAB) mechanism of NXP SoCs
          for platform integrity.
 
+     (4) DCP
+
+         Relies on Secure/Trusted boot process (called HAB by vendor) for
+         platform integrity.
+
   *  Interfaces and APIs
 
      (1) TPM
@@ -94,6 +113,11 @@ safe.
 
          Interface is specific to silicon vendor.
 
+     (4) DCP
+
+         Vendor-specific API that is implemented as part of the DCP crypto driver in
+         ``drivers/crypto/mxs-dcp.c``.
+
   *  Threat model
 
      The strength and appropriateness of a particular trust source for a given
@@ -129,6 +153,13 @@ selected trust source:
      CAAM HWRNG, enable CRYPTO_DEV_FSL_CAAM_RNG_API and ensure the device
      is probed.
 
+  *  DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs)
+
+     The DCP hardware device itself does not provide a dedicated RNG interface,
+     so the kernel default RNG is used. SoCs with DCP like the i.MX6ULL do have
+     a dedicated hardware RNG that is independent from DCP which can be enabled
+     to back the kernel RNG.
+
 Users may override this by specifying ``trusted.rng=kernel`` on the kernel
 command-line to override the used RNG with the kernel's random number pool.
 
@@ -231,6 +262,19 @@ Usage::
 CAAM-specific format.  The key length for new keys is always in bytes.
 Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
 
+Trusted Keys usage: DCP
+-----------------------
+
+Usage::
+
+    keyctl add trusted name "new keylen" ring
+    keyctl add trusted name "load hex_blob" ring
+    keyctl print keyid
+
+"keyctl print" returns an ASCII hex copy of the sealed key, which is in format
+specific to this DCP key-blob implementation.  The key length for new keys is
+always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
+
 Encrypted Keys usage
 --------------------
 
@@ -426,3 +470,44 @@ string length.
 privkey is the binary representation of TPM2B_PUBLIC excluding the
 initial TPM2B header which can be reconstructed from the ASN.1 octed
 string length.
+
+DCP Blob Format
+---------------
+
+The Data Co-Processor (DCP) provides hardware-bound AES keys using its
+AES encryption engine only. It does not provide direct key sealing/unsealing.
+To make DCP hardware encryption keys usable as trust source, we define
+our own custom format that uses a hardware-bound key to secure the sealing
+key stored in the key blob.
+
+Whenever a new trusted key using DCP is generated, we generate a random 128-bit
+blob encryption key (BEK) and 128-bit nonce. The BEK and nonce are used to
+encrypt the trusted key payload using AES-128-GCM.
+
+The BEK itself is encrypted using the hardware-bound key using the DCP's AES
+encryption engine with AES-128-ECB. The encrypted BEK, generated nonce,
+BEK-encrypted payload and authentication tag make up the blob format together
+with a version number, payload length and authentication tag::
+
+    /*
+     * struct dcp_blob_fmt - DCP BLOB format.
+     *
+     * @fmt_version: Format version, currently being %1
+     * @blob_key: Random AES 128 key which is used to encrypt @payload,
+     *            @blob_key itself is encrypted with OTP or UNIQUE device key in
+     *            AES-128-ECB mode by DCP.
+     * @nonce: Random nonce used for @payload encryption.
+     * @payload_len: Length of the plain text @payload.
+     * @payload: The payload itself, encrypted using AES-128-GCM and @blob_key,
+     *           GCM auth tag of size AES_BLOCK_SIZE is attached at the end of it.
+     *
+     * The total size of a DCP BLOB is sizeof(struct dcp_blob_fmt) + @payload_len +
+     * AES_BLOCK_SIZE.
+     */
+    struct dcp_blob_fmt {
+            __u8 fmt_version;
+            __u8 blob_key[AES_KEYSIZE_128];
+            __u8 nonce[AES_KEYSIZE_128];
+            __le32 payload_len;
+            __u8 payload[];
+    } __packed;
-- 
2.35.3



From michal.simek at amd.com  Fri Dec 15 03:08:58 2023
From: michal.simek at amd.com (Michal Simek)
Date: Fri, 15 Dec 2023 12:08:58 +0100
Subject: [PATCH] gpio: xilinx: remove excess kernel doc
In-Reply-To: <20231215090943.9245-1-brgl@bgdev.pl>
References: <20231215090943.9245-1-brgl@bgdev.pl>
Message-ID: <e9ee989a-aa48-46a7-9035-765cfd7b808b@amd.com>



On 12/15/23 10:09, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> 
> The irqchip field has been removed from struct xgpio_instance so remove
> the doc as well.
> 
> Fixes: b4510f8fd5d0 ("gpio: xilinx: Convert to immutable irq_chip")
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312150239.IyuTVvrL-lkp at intel.com/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> ---
>   drivers/gpio/gpio-xilinx.c | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index 823198368250..7348df385198 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -52,7 +52,6 @@
>    * @dir: GPIO direction shadow register
>    * @gpio_lock: Lock used for synchronization
>    * @irq: IRQ used by GPIO device
> - * @irqchip: IRQ chip
>    * @enable: GPIO IRQ enable/disable bitfield
>    * @rising_edge: GPIO IRQ rising edge enable/disable bitfield
>    * @falling_edge: GPIO IRQ falling edge enable/disable bitfield

Interesting because kernel-doc is not reporting any issue but issue is there.

Reviewed-by: Michal Simek <michal.simek at amd.com>

Thanks,
Michal


From thomas.bourgoin at foss.st.com  Fri Dec 15 03:17:24 2023
From: thomas.bourgoin at foss.st.com (Thomas Bourgoin)
Date: Fri, 15 Dec 2023 12:17:24 +0100
Subject: [PATCH] crypto: stm32/crc32 - fix parsing list of devices
Message-ID: <20231215111724.864051-1-thomas.bourgoin@foss.st.com>

smatch warnings:
drivers/crypto/stm32/stm32-crc32.c:108 stm32_crc_get_next_crc() warn:
can 'crc' even be NULL?

Use list_first_entry_or_null instead of list_first_entry to retrieve
the first device registered.
The function list_first_entry always return a non NULL pointer even if
the list is empty. Hence checking if the pointer returned is NULL does
not tell if the list is empty or not.

Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp at intel.com/
Reported-by: Dan Carpenter <error27 at gmail.com>
Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp at intel.com/
Signed-off-by: Thomas Bourgoin <thomas.bourgoin at foss.st.com>
---
 drivers/crypto/stm32/stm32-crc32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/stm32/stm32-crc32.c b/drivers/crypto/stm32/stm32-crc32.c
index b2d5c8921ab3..b0cf6d2fd352 100644
--- a/drivers/crypto/stm32/stm32-crc32.c
+++ b/drivers/crypto/stm32/stm32-crc32.c
@@ -104,7 +104,7 @@ static struct stm32_crc *stm32_crc_get_next_crc(void)
 	struct stm32_crc *crc;
 
 	spin_lock_bh(&crc_list.lock);
-	crc = list_first_entry(&crc_list.dev_list, struct stm32_crc, list);
+	crc = list_first_entry_or_null(&crc_list.dev_list, struct stm32_crc, list);
 	if (crc)
 		list_move_tail(&crc->list, &crc_list.dev_list);
 	spin_unlock_bh(&crc_list.lock);
-- 
2.25.1



From james.clark at arm.com  Fri Dec 15 03:19:24 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 11:19:24 +0000
Subject: [PATCH v3 1/8] dt-bindings: arm: Add support for CMB element size
In-Reply-To: <1700533494-19276-2-git-send-email-quic_taozha@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-2-git-send-email-quic_taozha@quicinc.com>
Message-ID: <09447d69-e0ce-13e9-95ea-0db475b8bb6e@arm.com>



On 21/11/2023 02:24, Tao Zhang wrote:
> Add property "qcom,cmb-elem-size" to support CMB(Continuous
> Multi-Bit) element for TPDM. The associated aggregator will read
> this size before it is enabled. CMB element size currently only
> supports 32-bit and 64-bit.
> 
> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
> ---
>  .../bindings/arm/qcom,coresight-tpdm.yaml     | 28 +++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
> index 61ddc3b5b247..0d9fe01a8b15 100644
> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
> @@ -52,6 +52,15 @@ properties:
>      $ref: /schemas/types.yaml#/definitions/uint8
>      enum: [32, 64]
>  
> +  qcom,cmb-element-size:
> +    description:
> +      Specifies the CMB(Continuous Multi-Bit) element size supported by
> +      the monitor. The associated aggregator will read this size before it
> +      is enabled. CMB element size currently only supports 8-bit, 32-bit
> +      and 64-bit.
> +    $ref: /schemas/types.yaml#/definitions/uint8
> +    enum: [8, 32, 64]
> +
>    qcom,dsb-msrs-num:
>      description:
>        Specifies the number of DSB(Discrete Single Bit) MSR(mux select register)
> @@ -110,4 +119,23 @@ examples:
>        };
>      };
>  
> +    tpdm at 6c29000 {
> +      compatible = "qcom,coresight-tpdm", "arm,primecell";
> +      reg = <0x06c29000 0x1000>;
> +      reg-names = "tpdm-base";

I think this one gives this error:

 $ make dt_binding_check DT_SCHEMA_FILES=arm/qcom,coresight

 DTC_CHK Documentation/devicetree/bindings/arm/qcom,coresight-
  tpdm.example.dtb
 qcom,coresight-tpdm.example.dtb: tpdm at 6c29000: 'reg-names' does not
  match any of the regexes: 'pinctrl-[0-9]+'
        from schema $id: http://devicetree.org/schemas
        /arm/qcom,coresight-tpdm.yaml#

> +
> +      qcom,cmb-element-size = /bits/ 8 <64>;
> +
> +      clocks = <&aoss_qmp>;
> +      clock-names = "apb_pclk";
> +
> +      out-ports {
> +        port {
> +          tpdm_ipcc_out_funnel_center: endpoint {
> +            remote-endpoint =
> +              <&funnel_center_in_tpdm_ipcc>;
> +          };
> +        };
> +      };
> +    };
>  ...


From james.clark at arm.com  Fri Dec 15 03:20:06 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 11:20:06 +0000
Subject: [PATCH v3 2/8] coresight-tpda: Add support to configure CMB
 element
In-Reply-To: <1700533494-19276-3-git-send-email-quic_taozha@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-3-git-send-email-quic_taozha@quicinc.com>
Message-ID: <080aab87-a910-9ab4-9a33-95a8b51402fe@arm.com>



On 21/11/2023 02:24, Tao Zhang wrote:
> Read the CMB element size from the device tree. Set the register
> bit that controls the CMB element size of the corresponding port.
> 
> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>

Reviewed-by: James Clark <james.clark at arm.com>

> ---
>  drivers/hwtracing/coresight/coresight-tpda.c | 117 +++++++++++--------
>  drivers/hwtracing/coresight/coresight-tpda.h |   6 +
>  2 files changed, 74 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c
> index 5f82737c37bb..e3762f38abb3 100644
> --- a/drivers/hwtracing/coresight/coresight-tpda.c
> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
> @@ -28,24 +28,54 @@ static bool coresight_device_is_tpdm(struct coresight_device *csdev)
>  			CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM);
>  }
>  
> +static void tpdm_clear_element_size(struct coresight_device *csdev)
> +{
> +	struct tpda_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> +
> +	if (drvdata->dsb_esize)
> +		drvdata->dsb_esize = 0;
> +	if (drvdata->cmb_esize)
> +		drvdata->cmb_esize = 0;
> +}
> +
> +static void tpda_set_element_size(struct tpda_drvdata *drvdata, u32 *val)
> +{
> +
> +	if (drvdata->dsb_esize == 64)
> +		*val |= TPDA_Pn_CR_DSBSIZE;
> +	else if (drvdata->dsb_esize == 32)
> +		*val &= ~TPDA_Pn_CR_DSBSIZE;
> +
> +	if (drvdata->cmb_esize == 64)
> +		*val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x2);
> +	else if (drvdata->cmb_esize == 32)
> +		*val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x1);
> +	else if (drvdata->cmb_esize == 8)
> +		*val &= ~TPDA_Pn_CR_CMBSIZE;
> +}
> +
>  /*
> - * Read the DSB element size from the TPDM device
> + * Read the element size from the TPDM device
>   * Returns
> - *    The dsb element size read from the devicetree if available.
> + *    The element size read from the devicetree if available.
>   *    0 - Otherwise, with a warning once.
>   */
> -static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
> +static int tpdm_read_element_size(struct tpda_drvdata *drvdata,
> +				  struct coresight_device *csdev)
>  {
> -	int rc = 0;
> -	u8 size = 0;
> -
> -	rc = fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
> -			"qcom,dsb-element-size", &size);
> +	int rc = -EINVAL;
> +
> +	if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
> +			"qcom,dsb-element-size", &drvdata->dsb_esize))
> +		rc = 0;
> +	if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
> +			"qcom,cmb-element-size", &drvdata->cmb_esize))
> +		rc = 0;
>  	if (rc)
>  		dev_warn_once(&csdev->dev,
> -			"Failed to read TPDM DSB Element size: %d\n", rc);
> +			"Failed to read TPDM Element size: %d\n", rc);
>  
> -	return size;
> +	return rc;
>  }
>  
>  /*
> @@ -56,11 +86,12 @@ static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
>   * Parameter "inport" is used to pass in the input port number
>   * of TPDA, and it is set to -1 in the recursize call.
>   */
> -static int tpda_get_element_size(struct coresight_device *csdev,
> +static int tpda_get_element_size(struct tpda_drvdata *drvdata,
> +				 struct coresight_device *csdev,
>  				 int inport)
>  {
> -	int dsb_size = -ENOENT;
> -	int i, size;
> +	int rc = 0;
> +	int i;
>  	struct coresight_device *in;
>  
>  	for (i = 0; i < csdev->pdata->nr_inconns; i++) {
> @@ -74,25 +105,21 @@ static int tpda_get_element_size(struct coresight_device *csdev,
>  			continue;
>  
>  		if (coresight_device_is_tpdm(in)) {
> -			size = tpdm_read_dsb_element_size(in);
> +			if ((drvdata->dsb_esize) || (drvdata->cmb_esize))
> +				return -EEXIST;
> +			rc = tpdm_read_element_size(drvdata, in);
> +			if (rc)
> +				return rc;
>  		} else {
>  			/* Recurse down the path */
> -			size = tpda_get_element_size(in, -1);
> -		}
> -
> -		if (size < 0)
> -			return size;
> -
> -		if (dsb_size < 0) {
> -			/* Found a size, save it. */
> -			dsb_size = size;
> -		} else {
> -			/* Found duplicate TPDMs */
> -			return -EEXIST;
> +			rc = tpda_get_element_size(drvdata, in, -1);
> +			if (rc)
> +				return rc;
>  		}
>  	}
>  
> -	return dsb_size;
> +
> +	return rc;
>  }
>  
>  /* Settings pre enabling port control register */
> @@ -109,7 +136,7 @@ static void tpda_enable_pre_port(struct tpda_drvdata *drvdata)
>  static int tpda_enable_port(struct tpda_drvdata *drvdata, int port)
>  {
>  	u32 val;
> -	int size;
> +	int rc;
>  
>  	val = readl_relaxed(drvdata->base + TPDA_Pn_CR(port));
>  	/*
> @@ -117,29 +144,21 @@ static int tpda_enable_port(struct tpda_drvdata *drvdata, int port)
>  	 * Set the bit to 0 if the size is 32
>  	 * Set the bit to 1 if the size is 64
>  	 */
> -	size = tpda_get_element_size(drvdata->csdev, port);
> -	switch (size) {
> -	case 32:
> -		val &= ~TPDA_Pn_CR_DSBSIZE;
> -		break;
> -	case 64:
> -		val |= TPDA_Pn_CR_DSBSIZE;
> -		break;
> -	case 0:
> -		return -EEXIST;
> -	case -EEXIST:
> +	tpdm_clear_element_size(drvdata->csdev);
> +	rc = tpda_get_element_size(drvdata, drvdata->csdev, port);
> +	if (!rc && ((drvdata->dsb_esize) || (drvdata->cmb_esize))) {
> +		tpda_set_element_size(drvdata, &val);
> +		/* Enable the port */
> +		val |= TPDA_Pn_CR_ENA;
> +		writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
> +	} else if (rc == -EEXIST)
>  		dev_warn_once(&drvdata->csdev->dev,
> -			"Detected multiple TPDMs on port %d", -EEXIST);
> -		return -EEXIST;
> -	default:
> -		return -EINVAL;
> -	}
> -
> -	/* Enable the port */
> -	val |= TPDA_Pn_CR_ENA;
> -	writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
> +			      "Detected multiple TPDMs on port %d", -EEXIST);
> +	else
> +		dev_warn_once(&drvdata->csdev->dev,
> +			      "Didn't find TPDM elem size");
>  
> -	return 0;
> +	return rc;
>  }
>  
>  static int __tpda_enable(struct tpda_drvdata *drvdata, int port)
> diff --git a/drivers/hwtracing/coresight/coresight-tpda.h b/drivers/hwtracing/coresight/coresight-tpda.h
> index b3b38fd41b64..29164fd9711f 100644
> --- a/drivers/hwtracing/coresight/coresight-tpda.h
> +++ b/drivers/hwtracing/coresight/coresight-tpda.h
> @@ -10,6 +10,8 @@
>  #define TPDA_Pn_CR(n)		(0x004 + (n * 4))
>  /* Aggregator port enable bit */
>  #define TPDA_Pn_CR_ENA		BIT(0)
> +/* Aggregator port CMB data set element size bit */
> +#define TPDA_Pn_CR_CMBSIZE		GENMASK(7, 6)
>  /* Aggregator port DSB data set element size bit */
>  #define TPDA_Pn_CR_DSBSIZE		BIT(8)
>  
> @@ -25,6 +27,8 @@
>   * @csdev:      component vitals needed by the framework.
>   * @spinlock:   lock for the drvdata value.
>   * @enable:     enable status of the component.
> + * @dsb_esize   Record the DSB element size.
> + * @cmb_esize   Record the CMB element size.
>   */
>  struct tpda_drvdata {
>  	void __iomem		*base;
> @@ -32,6 +36,8 @@ struct tpda_drvdata {
>  	struct coresight_device	*csdev;
>  	spinlock_t		spinlock;
>  	u8			atid;
> +	u8			dsb_esize;
> +	u8			cmb_esize;
>  };
>  
>  #endif  /* _CORESIGHT_CORESIGHT_TPDA_H */


From amit.kumar-mahapatra at amd.com  Fri Dec 15 03:20:55 2023
From: amit.kumar-mahapatra at amd.com (Mahapatra, Amit Kumar)
Date: Fri, 15 Dec 2023 11:20:55 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <e212f9fa-83c5-4b9e-8636-c8c6183096ab@linaro.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
 <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <c3fa1e04-92ed-48ab-a509-98e43abd5cd6@linaro.org>
 <BN7PR12MB2802E87F1A6CD22D904CAEACDC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
 <b3d3c457-a43b-478a-85b3-52558227d139@linaro.org>
 <BN7PR12MB28027E62D66460A374E3CFEADC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
 <e212f9fa-83c5-4b9e-8636-c8c6183096ab@linaro.org>
Message-ID: <BN7PR12MB280237CDD7BB148479932874DC93A@BN7PR12MB2802.namprd12.prod.outlook.com>

Hello Tudor,

> -----Original Message-----
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> Sent: Friday, December 15, 2023 4:03 PM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org; michael at walle.cc;
> linux-mtd at lists.infradead.org; nicolas.ferre at microchip.com;
> alexandre.belloni at bootlin.com; claudiu.beznea at tuxon.dev; Simek, Michal
> <michal.simek at amd.com>; linux-arm-kernel at lists.infradead.org; alsa-
> devel at alsa-project.org; patches at opensource.cirrus.com; linux-
> sound at vger.kernel.org; git (AMD-Xilinx) <git at amd.com>;
> amitrkcian2002 at gmail.com
> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
> in spi-nor
> 
> 
> 
> On 12/15/23 10:02, Mahapatra, Amit Kumar wrote:
> > Hello Tudor,
> 
> Hi,
> 
> >
> >> -----Original Message-----
> >> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> >> Sent: Friday, December 15, 2023 1:40 PM
> >> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> >> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> >> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> >> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> >> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> >> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> >> michael at walle.cc; linux-mtd at lists.infradead.org;
> >> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> >> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>;
> >> linux- arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> >> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> >> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> >> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories
> >> support in spi-nor
> >>
> >>
> >>
> >> On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
> >>>> Thanks! Can you share with us what flashes you used for testing in
> >>>> the stacked and parallel configurations?
> >>> I used SPI-NOR QSPI flashes for testing stacked and parallel.
> >>
> >> I got that, I wanted the flash name or device ID.
> >
> > N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI
> flashes
> > on which we tested. Additionally, we conducted tests on over 30
> > different QSPI flashes from four distinct vendors (Miron, Winbond,
> Macronix, and ISSI).
> >
> 
> Great.
> 
> >> What I'm interested is if each flash is in its own package. Are they?
> >
> > I'm sorry, but I don't quite understand what you mean by "if each
> > flash in its own package."
> >
> 
> There are flashes that are stacked at the physical level. It's a single flash with
> multiple dies, that are all under a single physical package.

Got it. The W25H02JV QSPI flash I mentioned earlier is a device with 
with four dies that are stacked at the physical level.

> 
> As I understand, your stacked flash model is at logical level. You have
> 2 flashes each in its own package. 2 different entities. Is my understanding
> correct?

Yes, that?s correct.

I'd like to contribute to your earlier point regarding the placement of 
the stacked layer. As you correctly highlighted, it should be in the 
spi-mem generic layer. For instance, when a read/write operation extends 
across multiple flashes (whether SPI-NOR or SPI-NAND), the stacked layer 
must handle the flash crossover. This requires setting the appropriate CS 
index in mem->spi->cs_index_mask to select the correct slave device and 
updating the data buffer, address & data length in spi_mem_op struct 
variable. Does this align with your understanding?

Regards,
Amit
> 
> Cheers,
> ta

From james.clark at arm.com  Fri Dec 15 03:24:16 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 11:24:16 +0000
Subject: [PATCH v3 8/8] coresight-tpdm: Add msr register support for CMB
In-Reply-To: <1700533494-19276-9-git-send-email-quic_taozha@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-9-git-send-email-quic_taozha@quicinc.com>
Message-ID: <f3b32f5f-edd4-e8ba-ae8f-e84ea698cc64@arm.com>



On 21/11/2023 02:24, Tao Zhang wrote:
> Add the nodes for CMB subunit MSR(mux select register) support.
> CMB MSRs(mux select registers) is to separate mux,arbitration,
> ,interleaving,data packing control from stream filtering control.
> 
> Reviewed-by: James Clark <james.clark at arm.com>
> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
> ---
>  .../testing/sysfs-bus-coresight-devices-tpdm  |  8 ++
>  drivers/hwtracing/coresight/coresight-tpdm.c  | 86 +++++++++++++++++++
>  drivers/hwtracing/coresight/coresight-tpdm.h  | 16 +++-
>  3 files changed, 109 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> index e0b77107be13..914f3fd81525 100644
> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> @@ -249,3 +249,11 @@ Description:
>  		Accepts only one of the 2 values -  0 or 1.
>  		0 : Disable the timestamp of all trace packets.
>  		1 : Enable the timestamp of all trace packets.
> +
> +What:		/sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31]
> +Date:		September 2023
> +KernelVersion	6.7

This probably needs bumping now. Maybe 6.9?


From namcao at linutronix.de  Fri Dec 15 03:33:38 2023
From: namcao at linutronix.de (Nam Cao)
Date: Fri, 15 Dec 2023 12:33:38 +0100
Subject: [PATCH 2/2] spi: pl022: update description of internal_cs_control()
In-Reply-To: <f06a9b6eac184cc648ae7444c480add6da87a84d.1702639801.git.namcao@linutronix.de>
References: <f06a9b6eac184cc648ae7444c480add6da87a84d.1702639801.git.namcao@linutronix.de>
Message-ID: <4036d8d5845c04179f330f83e825a3921aa50c5a.1702639801.git.namcao@linutronix.de>

The arguments of internal_cs_control() was changed, but its description
was not updated. Update the description to match the expected arguments.

Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312151816.munFeE4L-lkp at intel.com/
Signed-off-by: Nam Cao <namcao at linutronix.de>
---
 drivers/spi/spi-pl022.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index bdec67cf45f2..de63cf0557ce 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -419,7 +419,7 @@ struct chip_data {
 /**
  * internal_cs_control - Control chip select signals via SSP_CSR.
  * @pl022: SSP driver private data structure
- * @command: select/delect the chip
+ * @enable: select/delect the chip
  *
  * Used on controller with internal chip select control via SSP_CSR register
  * (vendor extension). Each of the 5 LSB in the register controls one chip
-- 
2.39.2



From namcao at linutronix.de  Fri Dec 15 03:33:37 2023
From: namcao at linutronix.de (Nam Cao)
Date: Fri, 15 Dec 2023 12:33:37 +0100
Subject: [PATCH 1/2] spi: pl022: delete description of cur_msg
In-Reply-To: <202312151816.munFeE4L-lkp@intel.com/>
Message-ID: <f06a9b6eac184cc648ae7444c480add6da87a84d.1702639801.git.namcao@linutronix.de>

The variable cur_msg was removed, but its description is left behind.
Delete this description.

Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312151816.munFeE4L-lkp at intel.com/
Signed-off-by: Nam Cao <namcao at linutronix.de>
---
 drivers/spi/spi-pl022.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 3baf45da01cd..bdec67cf45f2 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -338,7 +338,6 @@ struct vendor_data {
  * @clk: outgoing clock "SPICLK" for the SPI bus
  * @host: SPI framework hookup
  * @host_info: controller-specific data from machine setup
- * @cur_msg: Pointer to current spi_message being processed
  * @cur_transfer: Pointer to current spi_transfer
  * @cur_chip: pointer to current clients chip(assigned from controller_state)
  * @tx: current position in TX buffer to be read
-- 
2.39.2



From peng.fan at oss.nxp.com  Fri Dec 15 03:56:28 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 15 Dec 2023 19:56:28 +0800
Subject: [PATCH 0/7] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol
 basic support
Message-ID: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>

This patchset is a rework from Oleksii's RFC v5 patchset
https://lore.kernel.org/all/cover.1698353854.git.oleksii_moisieiev at epam.com/

This patchset introduces some changes based on RFC v5:
- introduce helper get_max_msg_size
- support compatible string
- iterate the id_table
- Support multiple configs in one command
- Added i.MX support
- Patch 5 firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
  is almost same as RFCv5 expect multiple configs support.
- Patch 4 the dt-bindings includes compatible string to support i.MX
- Rebased on 2023-12-15 linux-next/master

If any comments from RFC v5 are missed, I am sorry in advance.

This PINCTRL Protocol is following Version 3.2 SCMI Spec Beta release.

On ARM-based systems, a separate Cortex-M based System Control Processor
(SCP) provides control on pins, as well as with power, clocks, reset
controllers. So implement the driver to support such cases.

The i.MX95 Example as below:

Configuration:
The scmi-pinctrl driver can be configured using DT bindings.
For example:
/ {
	sram0: sram at 445b1000 {
		compatible = "mmio-sram";
		reg = <0x0 0x445b1000 0x0 0x400>;

		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0x0 0x0 0x445b1000 0x400>;

		scmi_buf0: scmi-sram-section at 0 {
			compatible = "arm,scmi-shmem";
			reg = <0x0 0x80>;
		};

		scmi_buf1: scmi-sram-section at 80 {
			compatible = "arm,scmi-shmem";
			reg = <0x80 0x80>;
		};
	};

	firmware {
		scmi {
			compatible = "arm,scmi";
			mboxes = <&mu2 5 0>, <&mu2 3 0>, <&mu2 3 1>;
			shmem = <&scmi_buf0>, <&scmi_buf1>;
			#address-cells = <1>;
			#size-cells = <0>;

			scmi_iomuxc: protocol at 19 {
				compatible = "fsl,imx95-scmi-pinctrl";
				reg = <0x19>;
			};
		};
	};
};

&scmi_iomuxc {
	pinctrl_tpm3: tpm3grp {
		fsl,pins = <
			IMX95_PAD_GPIO_IO12__TPM3_CH2		0x51e
		>;
	};
};

This patchset has been tested on i.MX95-19x19-EVK board.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
Oleksii Moisieiev (1):
      firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support

Peng Fan (6):
      firmware: arm_scmi: introduce helper get_max_msg_size
      firmware: scmi: support compatible string
      firmware: arm_scmi: bus: iterate the id_table
      dt-bindings: firmware: arm,scmi: support pinctrl protocol
      pinctrl: Implementation of the generic scmi-pinctrl driver
      pinctrl: scmi: implement pinctrl_scmi_imx_dt_node_to_map

 .../devicetree/bindings/firmware/arm,scmi.yaml     |  99 +++
 MAINTAINERS                                        |   7 +
 drivers/firmware/arm_scmi/Makefile                 |   1 +
 drivers/firmware/arm_scmi/bus.c                    |  49 +-
 drivers/firmware/arm_scmi/common.h                 |   2 +-
 drivers/firmware/arm_scmi/driver.c                 |  32 +-
 drivers/firmware/arm_scmi/pinctrl.c                | 927 +++++++++++++++++++++
 drivers/firmware/arm_scmi/protocols.h              |   2 +
 drivers/pinctrl/Kconfig                            |  11 +
 drivers/pinctrl/Makefile                           |   1 +
 drivers/pinctrl/pinctrl-scmi-imx.c                 | 117 +++
 drivers/pinctrl/pinctrl-scmi.c                     | 419 ++++++++++
 drivers/pinctrl/pinctrl-scmi.h                     |  12 +
 include/linux/scmi_protocol.h                      |  48 ++
 14 files changed, 1710 insertions(+), 17 deletions(-)
---
base-commit: 17cb8a20bde66a520a2ca7aad1063e1ce7382240
change-id: 20231215-pinctrl-scmi-4c5b0374f4c6

Best regards,
-- 
Peng Fan <peng.fan at nxp.com>



From peng.fan at oss.nxp.com  Fri Dec 15 03:56:29 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 15 Dec 2023 19:56:29 +0800
Subject: [PATCH 1/7] firmware: arm_scmi: introduce helper get_max_msg_size
In-Reply-To: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
Message-ID: <20231215-pinctrl-scmi-v1-1-0fe35e4611f7@nxp.com>

From: Peng Fan <peng.fan at nxp.com>

When Agent sending data to SCMI server, the Agent driver could check
the size to avoid protocol buffer overflow. So introduce the helper
get_max_msg_size.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/firmware/arm_scmi/driver.c    | 15 +++++++++++++++
 drivers/firmware/arm_scmi/protocols.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index a9f70e6e58ac..b4f8f190351b 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -1481,6 +1481,20 @@ static int scmi_common_extended_name_get(const struct scmi_protocol_handle *ph,
 	return ret;
 }
 
+/**
+ * scmi_common_get_max_msg_size  - Get maximum message size
+ * @ph: A protocol handle reference.
+ *
+ * Return: Maximum message size for the current protocol.
+ */
+static int scmi_common_get_max_msg_size(const struct scmi_protocol_handle *ph)
+{
+	const struct scmi_protocol_instance *pi = ph_to_pi(ph);
+	struct scmi_info *info = handle_to_scmi_info(pi->handle);
+
+	return info->desc->max_msg_size;
+}
+
 /**
  * struct scmi_iterator  - Iterator descriptor
  * @msg: A reference to the message TX buffer; filled by @prepare_message with
@@ -1756,6 +1770,7 @@ static void scmi_common_fastchannel_db_ring(struct scmi_fc_db_info *db)
 
 static const struct scmi_proto_helpers_ops helpers_ops = {
 	.extended_name_get = scmi_common_extended_name_get,
+	.get_max_msg_size = scmi_common_get_max_msg_size,
 	.iter_response_init = scmi_iterator_init,
 	.iter_response_run = scmi_iterator_run,
 	.fastchannel_init = scmi_common_fastchannel_init,
diff --git a/drivers/firmware/arm_scmi/protocols.h b/drivers/firmware/arm_scmi/protocols.h
index e683c26f24eb..08de8dc064c1 100644
--- a/drivers/firmware/arm_scmi/protocols.h
+++ b/drivers/firmware/arm_scmi/protocols.h
@@ -270,6 +270,7 @@ struct scmi_proto_helpers_ops {
 				 void __iomem **p_addr,
 				 struct scmi_fc_db_info **p_db);
 	void (*fastchannel_db_ring)(struct scmi_fc_db_info *db);
+	int (*get_max_msg_size)(const struct scmi_protocol_handle *ph);
 };
 
 /**

-- 
2.37.1



From peng.fan at oss.nxp.com  Fri Dec 15 03:56:30 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 15 Dec 2023 19:56:30 +0800
Subject: [PATCH 2/7] firmware: scmi: support compatible string
In-Reply-To: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
Message-ID: <20231215-pinctrl-scmi-v1-2-0fe35e4611f7@nxp.com>

From: Peng Fan <peng.fan at nxp.com>

i.MX95 use SCMI PINCTRL OEM config type, so it could not reuse
pinctrl-scmi.c which use generic pinconf. Then need introduce
saying pinctrl-imx-scmi.c to support i.MX95, however both
pinctrl-scmi and pinctrl-imx-scmi driver will register a pinctrl device
with the same of_node(protocl at 19). This will introduce an issue, because
the pinctrl subsystem will use of_node to find the exact pinctrl
device. But with two pinctrl devices registered by two drivers, it is
unknown which pinctrl device will be chosen.

So introduce compatible string to support cases that Vendor SCMI
driver which does almost same thing as generic SCMI driver, but
has some specific Vendor settings to do.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/firmware/arm_scmi/bus.c    | 39 ++++++++++++++++++++++++++++++--------
 drivers/firmware/arm_scmi/common.h |  2 +-
 drivers/firmware/arm_scmi/driver.c | 15 ++++++++++-----
 include/linux/scmi_protocol.h      |  2 ++
 4 files changed, 44 insertions(+), 14 deletions(-)

diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index c15928b8c5cc..c999edd18cd3 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -194,13 +194,21 @@ scmi_dev_match_id(struct scmi_device *scmi_dev, struct scmi_driver *scmi_drv)
 	if (!id)
 		return NULL;
 
-	for (; id->protocol_id; id++)
-		if (id->protocol_id == scmi_dev->protocol_id) {
-			if (!id->name)
+	for (; id->protocol_id; id++) {
+		if (id->protocol_id != scmi_dev->protocol_id)
+			continue;
+		if (!id->name)
+			return id;
+
+		if (!strcmp(id->name, scmi_dev->name)) {
+			if (!id->compatible &&
+			    device_property_read_string(&scmi_dev->dev, "compatible", NULL))
 				return id;
-			else if (!strcmp(id->name, scmi_dev->name))
+
+			if (id->compatible && device_is_compatible(&scmi_dev->dev, id->compatible))
 				return id;
 		}
+	}
 
 	return NULL;
 }
@@ -325,11 +333,14 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
 
 static struct scmi_device *
 __scmi_device_create(struct device_node *np, struct device *parent,
-		     int protocol, const char *name)
+		     int protocol, const char *name, const char *compatible)
 {
 	int id, retval;
 	struct scmi_device *scmi_dev;
 
+	if (compatible && !of_device_is_compatible(np, compatible))
+		return NULL;
+
 	/*
 	 * If the same protocol/name device already exist under the same parent
 	 * (i.e. SCMI instance) just return the existent device.
@@ -405,6 +416,7 @@ __scmi_device_create(struct device_node *np, struct device *parent,
  * @name: The requested-name of the device to be created; this is optional
  *	  and if no @name is provided, all the devices currently known to
  *	  be requested on the SCMI bus for @protocol will be created.
+ * @compatible: The compatible string
  *
  * This method can be invoked to create a single well-defined device (like
  * a transport device or a device requested by an SCMI driver loaded after
@@ -421,14 +433,14 @@ __scmi_device_create(struct device_node *np, struct device *parent,
  */
 struct scmi_device *scmi_device_create(struct device_node *np,
 				       struct device *parent, int protocol,
-				       const char *name)
+				       const char *name, const char *compatible)
 {
 	struct list_head *phead;
 	struct scmi_requested_dev *rdev;
 	struct scmi_device *scmi_dev = NULL;
 
 	if (name)
-		return __scmi_device_create(np, parent, protocol, name);
+		return __scmi_device_create(np, parent, protocol, name, compatible);
 
 	mutex_lock(&scmi_requested_devices_mtx);
 	phead = idr_find(&scmi_requested_devices, protocol);
@@ -442,9 +454,20 @@ struct scmi_device *scmi_device_create(struct device_node *np,
 	list_for_each_entry(rdev, phead, node) {
 		struct scmi_device *sdev;
 
+		if (compatible) {
+			if (!rdev->id_table->compatible)
+				continue;
+			if (strcmp(compatible, rdev->id_table->compatible))
+				continue;
+		} else {
+			if (rdev->id_table->compatible)
+				continue;
+		}
+
 		sdev = __scmi_device_create(np, parent,
 					    rdev->id_table->protocol_id,
-					    rdev->id_table->name);
+					    rdev->id_table->name,
+					    rdev->id_table->compatible);
 		/* Report errors and carry on... */
 		if (sdev)
 			scmi_dev = sdev;
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index c46dc5215af7..930a24e0d712 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -149,7 +149,7 @@ extern struct blocking_notifier_head scmi_requested_devices_nh;
 
 struct scmi_device *scmi_device_create(struct device_node *np,
 				       struct device *parent, int protocol,
-				       const char *name);
+				       const char *name, const char *compatible);
 void scmi_device_destroy(struct device *parent, int protocol, const char *name);
 
 int scmi_protocol_acquire(const struct scmi_handle *handle, u8 protocol_id);
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index b4f8f190351b..3174da57d832 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -261,15 +261,17 @@ EXPORT_SYMBOL_GPL(scmi_protocol_unregister);
  * @name: The optional name of the device to be created: if not provided this
  *	  call will lead to the creation of all the devices currently requested
  *	  for the specified protocol.
+ * @compatible: optional, the compatible string
  */
 static void scmi_create_protocol_devices(struct device_node *np,
 					 struct scmi_info *info,
-					 int prot_id, const char *name)
+					 int prot_id, const char *name,
+					 const char *compatible)
 {
 	struct scmi_device *sdev;
 
 	mutex_lock(&info->devreq_mtx);
-	sdev = scmi_device_create(np, info->dev, prot_id, name);
+	sdev = scmi_device_create(np, info->dev, prot_id, name, compatible);
 	if (name && !sdev)
 		dev_err(info->dev,
 			"failed to create device for protocol 0x%X (%s)\n",
@@ -2354,7 +2356,7 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
 	snprintf(name, 32, "__scmi_transport_device_%s_%02X",
 		 idx ? "rx" : "tx", prot_id);
 	/* Create a uniquely named, dedicated transport device for this chan */
-	tdev = scmi_device_create(of_node, info->dev, prot_id, name);
+	tdev = scmi_device_create(of_node, info->dev, prot_id, name, NULL);
 	if (!tdev) {
 		dev_err(info->dev,
 			"failed to create transport device (%s)\n", name);
@@ -2550,7 +2552,7 @@ static int scmi_device_request_notifier(struct notifier_block *nb,
 	switch (action) {
 	case SCMI_BUS_NOTIFY_DEVICE_REQUEST:
 		scmi_create_protocol_devices(np, info, id_table->protocol_id,
-					     id_table->name);
+					     id_table->name, id_table->compatible);
 		break;
 	case SCMI_BUS_NOTIFY_DEVICE_UNREQUEST:
 		scmi_destroy_protocol_devices(info, id_table->protocol_id,
@@ -2802,10 +2804,13 @@ static int scmi_probe(struct platform_device *pdev)
 
 	for_each_available_child_of_node(np, child) {
 		u32 prot_id;
+		const char *s = NULL;
 
 		if (of_property_read_u32(child, "reg", &prot_id))
 			continue;
 
+		of_property_read_string(child, "compatible", &s);
+
 		if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id))
 			dev_err(dev, "Out of range protocol %d\n", prot_id);
 
@@ -2828,7 +2833,7 @@ static int scmi_probe(struct platform_device *pdev)
 		}
 
 		of_node_get(child);
-		scmi_create_protocol_devices(child, info, prot_id, NULL);
+		scmi_create_protocol_devices(child, info, prot_id, NULL, s);
 	}
 
 	return 0;
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index f2f05fb42d28..19a06b872afe 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -839,6 +839,7 @@ struct scmi_device {
 	u32 id;
 	u8 protocol_id;
 	const char *name;
+	const char *compatible; /* Optional */
 	struct device dev;
 	struct scmi_handle *handle;
 };
@@ -848,6 +849,7 @@ struct scmi_device {
 struct scmi_device_id {
 	u8 protocol_id;
 	const char *name;
+	const char *compatible; /* Optional */
 };
 
 struct scmi_driver {

-- 
2.37.1



From peng.fan at oss.nxp.com  Fri Dec 15 03:56:31 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 15 Dec 2023 19:56:31 +0800
Subject: [PATCH 3/7] firmware: arm_scmi: bus: iterate the id_table
In-Reply-To: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
Message-ID: <20231215-pinctrl-scmi-v1-3-0fe35e4611f7@nxp.com>

From: Peng Fan <peng.fan at nxp.com>

There maybe more entries in driver->id_table, just like platform
driver of_match_table. So iterate the id_table, not only use the 1st
entry.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/firmware/arm_scmi/bus.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index c999edd18cd3..aeb7da841b9d 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -282,14 +282,18 @@ EXPORT_SYMBOL_GPL(scmi_bus_type);
 int scmi_driver_register(struct scmi_driver *driver, struct module *owner,
 			 const char *mod_name)
 {
+	const struct scmi_device_id *id_table = driver->id_table;
 	int retval;
 
 	if (!driver->probe)
 		return -EINVAL;
 
-	retval = scmi_protocol_device_request(driver->id_table);
-	if (retval)
-		return retval;
+	while (id_table->name) {
+		retval = scmi_protocol_device_request(id_table);
+		if (retval)
+			return retval;
+		id_table++;
+	}
 
 	driver->driver.bus = &scmi_bus_type;
 	driver->driver.name = driver->name;

-- 
2.37.1



From peng.fan at oss.nxp.com  Fri Dec 15 03:56:32 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 15 Dec 2023 19:56:32 +0800
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
Message-ID: <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add SCMI v3.2 pinctrl protocol bindings and example.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 .../devicetree/bindings/firmware/arm,scmi.yaml     | 99 ++++++++++++++++++++++
 1 file changed, 99 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 4591523b51a0..bfd2b6a89979 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -247,6 +247,85 @@ properties:
       reg:
         const: 0x18
 
+  protocol at 19:
+    type: object
+    allOf:
+      - $ref: '#/$defs/protocol-node'
+      - $ref: /schemas/pinctrl/pinctrl.yaml
+      - if:
+          properties:
+            compatible:
+              const: fsl,imx95-scmi-pinctrl
+        then:
+          patternProperties:
+            "grp$": false
+            "-pins$": true
+        else:
+          patternProperties:
+            "grp$": false
+            "-pins$": true
+    unevaluatedProperties: false
+
+    properties:
+      reg:
+        const: 0x19
+
+      '#pinctrl-cells':
+        const: 0
+
+      compatible:
+        const: fsl,imx95-scmi-pinctrl
+
+    patternProperties:
+      '-pins$':
+        type: object
+        allOf:
+          - $ref: /schemas/pinctrl/pincfg-node.yaml#
+          - $ref: /schemas/pinctrl/pinmux-node.yaml#
+        unevaluatedProperties: false
+
+        description:
+          A pin multiplexing sub-node describe how to configure a
+          set of pins is some desired function.
+          A single sub-node may define several pin configurations.
+          This sub-node is using default pinctrl bindings to configure
+          pin multiplexing and using SCMI protocol to apply specified
+          configuration using SCMI protocol.
+
+      'grp$':
+        type: object
+        description:
+          Pinctrl node's client devices use subnodes for desired pin configuration.
+          Client device subnodes use below standard properties.
+
+        properties:
+          fsl,pins:
+            description:
+              each entry consists of 6 integers and represents the mux and config
+              setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
+              mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
+              be found in <arch/arm64/boot/dts/freescale/imx95-pinfunc.h>. The last
+              integer CONFIG is the pad setting value like pull-up on this pin. Please
+              refer to i.MX95 Plus Reference Manual for detailed CONFIG settings.
+            $ref: /schemas/types.yaml#/definitions/uint32-matrix
+            items:
+              items:
+                - description: |
+                    "mux_reg" indicates the offset of mux register.
+                - description: |
+                    "conf_reg" indicates the offset of pad configuration register.
+                - description: |
+                    "input_reg" indicates the offset of select input register.
+                - description: |
+                    "mux_val" indicates the mux value to be applied.
+                - description: |
+                    "input_val" indicates the select input value to be applied.
+                - description: |
+                    "pad_setting" indicates the pad configuration value to be applied.
+
+    required:
+      - reg
+
 additionalProperties: false
 
 $defs:
@@ -401,6 +480,26 @@ examples:
             scmi_powercap: protocol at 18 {
                 reg = <0x18>;
             };
+
+            scmi_pinctrl: protocol at 19 {
+                reg = <0x19>;
+                #pinctrl-cells = <0>;
+
+                i2c2-pins {
+                    groups = "i2c2_a", "i2c2_b";
+                    function = "i2c2";
+                };
+
+                mdio-pins {
+                    groups = "avb_mdio";
+                    drive-strength = <24>;
+                };
+
+                keys_pins: keys-pins {
+                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
+                    bias-pull-up;
+                };
+            };
         };
     };
 

-- 
2.37.1



From peng.fan at oss.nxp.com  Fri Dec 15 03:56:33 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 15 Dec 2023 19:56:33 +0800
Subject: [PATCH 5/7] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol
 basic support
In-Reply-To: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
Message-ID: <20231215-pinctrl-scmi-v1-5-0fe35e4611f7@nxp.com>

From: Oleksii Moisieiev <Oleksii_Moisieiev at epam.com>

Add basic implementation of the SCMI v3.2 pincontrol protocol.

Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev at epam.com>
Co-developed-by: Peng Fan <peng.fan at nxp.com>
Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 MAINTAINERS                           |   6 +
 drivers/firmware/arm_scmi/Makefile    |   1 +
 drivers/firmware/arm_scmi/driver.c    |   2 +
 drivers/firmware/arm_scmi/pinctrl.c   | 927 ++++++++++++++++++++++++++++++++++
 drivers/firmware/arm_scmi/protocols.h |   1 +
 include/linux/scmi_protocol.h         |  46 ++
 6 files changed, 983 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b589218605b4..8d971adeee22 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21180,6 +21180,12 @@ F:	include/linux/sc[mp]i_protocol.h
 F:	include/trace/events/scmi.h
 F:	include/uapi/linux/virtio_scmi.h
 
+SYSTEM CONTROL MANAGEMENT INTERFACE (SCMI) PINCTRL DRIVER
+M:	Oleksii Moisieiev <oleksii_moisieiev at epam.com>
+L:	linux-arm-kernel at lists.infradead.org
+S:	Maintained
+F:	drivers/firmware/arm_scmi/pinctrl.c
+
 SYSTEM RESET/SHUTDOWN DRIVERS
 M:	Sebastian Reichel <sre at kernel.org>
 L:	linux-pm at vger.kernel.org
diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile
index a7bc4796519c..8e3874ff1544 100644
--- a/drivers/firmware/arm_scmi/Makefile
+++ b/drivers/firmware/arm_scmi/Makefile
@@ -11,6 +11,7 @@ scmi-transport-$(CONFIG_ARM_SCMI_HAVE_MSG) += msg.o
 scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o
 scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o
 scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o system.o voltage.o powercap.o
+scmi-protocols-y += pinctrl.o
 scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y)
 
 obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 3174da57d832..1cf9f5d4f7bd 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -3057,6 +3057,7 @@ static int __init scmi_driver_init(void)
 	scmi_voltage_register();
 	scmi_system_register();
 	scmi_powercap_register();
+	scmi_pinctrl_register();
 
 	return platform_driver_register(&scmi_driver);
 }
@@ -3074,6 +3075,7 @@ static void __exit scmi_driver_exit(void)
 	scmi_voltage_unregister();
 	scmi_system_unregister();
 	scmi_powercap_unregister();
+	scmi_pinctrl_unregister();
 
 	scmi_transports_exit();
 
diff --git a/drivers/firmware/arm_scmi/pinctrl.c b/drivers/firmware/arm_scmi/pinctrl.c
new file mode 100644
index 000000000000..a25c8edcedd2
--- /dev/null
+++ b/drivers/firmware/arm_scmi/pinctrl.c
@@ -0,0 +1,927 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * System Control and Management Interface (SCMI) Pinctrl Protocol
+ *
+ * Copyright (C) 2023 EPAM
+ */
+
+#include <linux/module.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/scmi_protocol.h>
+#include <linux/slab.h>
+
+#include "common.h"
+#include "protocols.h"
+
+/* Updated only after ALL the mandatory features for that version are merged */
+#define SCMI_PROTOCOL_SUPPORTED_VERSION                0x40000
+
+#define REG_TYPE_BITS GENMASK(9, 8)
+#define REG_CONFIG GENMASK(7, 0)
+
+#define GET_GROUPS_NR(x)	le32_get_bits((x), GENMASK(31, 16))
+#define GET_PINS_NR(x)		le32_get_bits((x), GENMASK(15, 0))
+#define GET_FUNCTIONS_NR(x)	le32_get_bits((x), GENMASK(15, 0))
+
+#define EXT_NAME_FLAG(x)	le32_get_bits((x), BIT(31))
+#define NUM_ELEMS(x)		le32_get_bits((x), GENMASK(15, 0))
+
+#define REMAINING(x)		le32_get_bits((x), GENMASK(31, 16))
+#define RETURNED(x)		le32_get_bits((x), GENMASK(11, 0))
+
+enum scmi_pinctrl_protocol_cmd {
+	PINCTRL_ATTRIBUTES = 0x3,
+	PINCTRL_LIST_ASSOCIATIONS = 0x4,
+	PINCTRL_CONFIG_GET = 0x5,
+	PINCTRL_CONFIG_SET = 0x6,
+	PINCTRL_FUNCTION_SELECT = 0x7,
+	PINCTRL_REQUEST = 0x8,
+	PINCTRL_RELEASE = 0x9,
+	PINCTRL_NAME_GET = 0xa,
+	PINCTRL_SET_PERMISSIONS = 0xb
+};
+
+struct scmi_msg_conf_set {
+	__le32 identifier;
+	__le32 attributes;
+	__le32 configs[];
+};
+
+struct scmi_msg_conf_get {
+	__le32 identifier;
+	__le32 attributes;
+};
+
+struct scmi_resp_conf_get {
+	__le32 num_configs;
+	__le32 configs[];
+};
+
+struct scmi_msg_pinctrl_protocol_attributes {
+	__le32 attributes_low;
+	__le32 attributes_high;
+};
+
+struct scmi_msg_pinctrl_attributes {
+	__le32 identifier;
+	__le32 flags;
+};
+
+struct scmi_resp_pinctrl_attributes {
+	__le32 attributes;
+	u8 name[SCMI_SHORT_NAME_MAX_SIZE];
+};
+
+struct scmi_msg_pinctrl_list_assoc {
+	__le32 identifier;
+	__le32 flags;
+	__le32 index;
+};
+
+struct scmi_resp_pinctrl_list_assoc {
+	__le32 flags;
+	__le16 array[];
+};
+
+struct scmi_msg_func_set {
+	__le32 identifier;
+	__le32 function_id;
+	__le32 flags;
+};
+
+struct scmi_msg_request {
+	__le32 identifier;
+	__le32 flags;
+};
+
+struct scmi_group_info {
+	char name[SCMI_MAX_STR_SIZE];
+	bool present;
+	unsigned int *group_pins;
+	unsigned int nr_pins;
+};
+
+struct scmi_function_info {
+	char name[SCMI_MAX_STR_SIZE];
+	bool present;
+	unsigned int *groups;
+	unsigned int nr_groups;
+};
+
+struct scmi_pin_info {
+	char name[SCMI_MAX_STR_SIZE];
+	bool present;
+};
+
+struct scmi_pinctrl_info {
+	u32 version;
+	int nr_groups;
+	int nr_functions;
+	int nr_pins;
+	struct scmi_group_info *groups;
+	struct scmi_function_info *functions;
+	struct scmi_pin_info *pins;
+};
+
+static int scmi_pinctrl_attributes_get(const struct scmi_protocol_handle *ph,
+				       struct scmi_pinctrl_info *pi)
+{
+	int ret;
+	struct scmi_xfer *t;
+	struct scmi_msg_pinctrl_protocol_attributes *attr;
+
+	ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0, sizeof(*attr), &t);
+	if (ret)
+		return ret;
+
+	attr = t->rx.buf;
+
+	ret = ph->xops->do_xfer(ph, t);
+	if (!ret) {
+		pi->nr_functions = GET_FUNCTIONS_NR(attr->attributes_high);
+		pi->nr_groups = GET_GROUPS_NR(attr->attributes_low);
+		pi->nr_pins = GET_PINS_NR(attr->attributes_low);
+	}
+
+	ph->xops->xfer_put(ph, t);
+	return ret;
+}
+
+static int scmi_pinctrl_count_get(const struct scmi_protocol_handle *ph,
+				  enum scmi_pinctrl_selector_type type)
+{
+	struct scmi_pinctrl_info *pi = ph->get_priv(ph);
+
+	switch (type) {
+	case PIN_TYPE:
+		return pi->nr_pins;
+	case GROUP_TYPE:
+		return pi->nr_groups;
+	case FUNCTION_TYPE:
+		return pi->nr_functions;
+	default:
+		return -EINVAL;
+	}
+}
+
+static int scmi_pinctrl_validate_id(const struct scmi_protocol_handle *ph,
+				    u32 identifier,
+				    enum scmi_pinctrl_selector_type type)
+{
+	int value;
+
+	value = scmi_pinctrl_count_get(ph, type);
+	if (value < 0)
+		return value;
+
+	if (identifier >= value)
+		return -EINVAL;
+
+	return 0;
+}
+
+static int scmi_pinctrl_attributes(const struct scmi_protocol_handle *ph,
+				   enum scmi_pinctrl_selector_type type,
+				   u32 selector, char *name,
+				   unsigned int *n_elems)
+{
+	int ret;
+	struct scmi_xfer *t;
+	struct scmi_msg_pinctrl_attributes *tx;
+	struct scmi_resp_pinctrl_attributes *rx;
+
+	if (!name)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_validate_id(ph, selector, type);
+	if (ret)
+		return ret;
+
+	ret = ph->xops->xfer_get_init(ph, PINCTRL_ATTRIBUTES, sizeof(*tx), sizeof(*rx), &t);
+	if (ret)
+		return ret;
+
+	tx = t->tx.buf;
+	rx = t->rx.buf;
+	tx->identifier = cpu_to_le32(selector);
+	tx->flags = cpu_to_le32(type);
+
+	ret = ph->xops->do_xfer(ph, t);
+	if (!ret) {
+		if (n_elems)
+			*n_elems = NUM_ELEMS(rx->attributes);
+
+		strscpy(name, rx->name, SCMI_SHORT_NAME_MAX_SIZE);
+	}
+
+	ph->xops->xfer_put(ph, t);
+
+	/*
+	 * If supported overwrite short name with the extended one;
+	 * on error just carry on and use already provided short name.
+	 */
+	if (!ret && EXT_NAME_FLAG(rx->attributes))
+		ph->hops->extended_name_get(ph, PINCTRL_NAME_GET, selector,
+					    (u32 *)&type, name,
+					    SCMI_MAX_STR_SIZE);
+	return ret;
+}
+
+struct scmi_pinctrl_ipriv {
+	u32 selector;
+	enum scmi_pinctrl_selector_type type;
+	unsigned int *array;
+};
+
+static void iter_pinctrl_assoc_prepare_message(void *message,
+					       unsigned int desc_index,
+					       const void *priv)
+{
+	struct scmi_msg_pinctrl_list_assoc *msg = message;
+	const struct scmi_pinctrl_ipriv *p = priv;
+
+	msg->identifier = cpu_to_le32(p->selector);
+	msg->flags = cpu_to_le32(p->type);
+	/* Set the number of OPPs to be skipped/already read */
+	msg->index = cpu_to_le32(desc_index);
+}
+
+static int iter_pinctrl_assoc_update_state(struct scmi_iterator_state *st,
+					   const void *response, void *priv)
+{
+	const struct scmi_resp_pinctrl_list_assoc *r = response;
+
+	st->num_returned = RETURNED(r->flags);
+	st->num_remaining = REMAINING(r->flags);
+
+	return 0;
+}
+
+static int
+iter_pinctrl_assoc_process_response(const struct scmi_protocol_handle *ph,
+				    const void *response,
+				    struct scmi_iterator_state *st, void *priv)
+{
+	const struct scmi_resp_pinctrl_list_assoc *r = response;
+	struct scmi_pinctrl_ipriv *p = priv;
+
+	p->array[st->desc_index + st->loop_idx] =
+		le16_to_cpu(r->array[st->loop_idx]);
+
+	return 0;
+}
+
+static int scmi_pinctrl_list_associations(const struct scmi_protocol_handle *ph,
+					  u32 selector,
+					  enum scmi_pinctrl_selector_type type,
+					  u16 size, unsigned int *array)
+{
+	int ret;
+	void *iter;
+	struct scmi_iterator_ops ops = {
+		.prepare_message = iter_pinctrl_assoc_prepare_message,
+		.update_state = iter_pinctrl_assoc_update_state,
+		.process_response = iter_pinctrl_assoc_process_response,
+	};
+	struct scmi_pinctrl_ipriv ipriv = {
+		.selector = selector,
+		.type = type,
+		.array = array,
+	};
+
+	if (!array || !size || type == PIN_TYPE)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_validate_id(ph, selector, type);
+	if (ret)
+		return ret;
+
+	iter = ph->hops->iter_response_init(ph, &ops, size,
+					    PINCTRL_LIST_ASSOCIATIONS,
+					    sizeof(struct scmi_msg_pinctrl_list_assoc),
+					    &ipriv);
+
+	if (IS_ERR(iter))
+		return PTR_ERR(iter);
+
+	return ph->hops->iter_response_run(iter);
+}
+
+struct scmi_conf_get_ipriv {
+	u32 selector;
+	enum scmi_pinctrl_selector_type type;
+	u8 all;
+	u8 *config_types;
+	unsigned long *config_values;
+};
+
+static void iter_pinctrl_conf_get_prepare_message(void *message,
+						  unsigned int desc_index,
+						  const void *priv)
+{
+	struct scmi_msg_conf_get *msg = message;
+	const struct scmi_conf_get_ipriv *p = priv;
+	u32 attributes;
+
+	msg->identifier = cpu_to_le32(p->selector);
+	attributes = FIELD_PREP(BIT(18), p->all) |
+		     FIELD_PREP(GENMASK(17, 16), p->type);
+
+	if (p->all)
+		attributes |= FIELD_PREP(GENMASK(15, 8), desc_index);
+	else
+		attributes |= FIELD_PREP(GENMASK(7, 0), p->config_types[0]);
+
+	msg->attributes = cpu_to_le32(attributes);
+	msg->identifier = cpu_to_le32(p->selector);
+}
+
+static int iter_pinctrl_conf_get_update_state(struct scmi_iterator_state *st,
+					      const void *response, void *priv)
+{
+	const struct scmi_resp_conf_get *r = response;
+
+	st->num_returned = le32_get_bits(r->num_configs, GENMASK(7, 0));
+	st->num_remaining = le32_get_bits(r->num_configs, GENMASK(31, 24));
+
+	return 0;
+}
+
+static int iter_pinctrl_conf_get_process_response(const struct scmi_protocol_handle *ph,
+						  const void *response,
+						  struct scmi_iterator_state *st, void *priv)
+{
+	const struct scmi_resp_conf_get *r = response;
+	struct scmi_conf_get_ipriv *p = priv;
+
+	if (!p->all) {
+		if (p->config_types[0] !=
+		    le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0)))
+			return -EINVAL;
+	} else {
+		p->config_types[st->desc_index + st->loop_idx] =
+			le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0));
+	}
+
+	p->config_values[st->desc_index + st->loop_idx] =
+		le32_to_cpu(r->configs[st->loop_idx * 2 + 1]);
+
+	return 0;
+}
+
+static int scmi_pinctrl_config_get(const struct scmi_protocol_handle *ph,
+				   u32 selector,
+				   enum scmi_pinctrl_selector_type type,
+				   u8 config_type, unsigned long *config_value)
+{
+	int ret;
+	void *iter;
+	struct scmi_iterator_ops ops = {
+		.prepare_message = iter_pinctrl_conf_get_prepare_message,
+		.update_state = iter_pinctrl_conf_get_update_state,
+		.process_response = iter_pinctrl_conf_get_process_response,
+	};
+	struct scmi_conf_get_ipriv ipriv = {
+		.selector = selector,
+		.type = type,
+		.all = 0,
+		.config_types = &config_type,
+		.config_values = config_value,
+	};
+
+	if (!config_value || type == FUNCTION_TYPE)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_validate_id(ph, selector, type);
+	if (ret)
+		return ret;
+
+	iter = ph->hops->iter_response_init(ph, &ops, 1, PINCTRL_CONFIG_GET,
+					    sizeof(struct scmi_msg_conf_get),
+					    &ipriv);
+
+	if (IS_ERR(iter))
+		return PTR_ERR(iter);
+
+	return ph->hops->iter_response_run(iter);
+}
+
+static int scmi_pinctrl_config_get_all(const struct scmi_protocol_handle *ph,
+				       u32 selector,
+				       enum scmi_pinctrl_selector_type type,
+				       u16 size, u8 *config_types,
+				       unsigned long *config_values)
+{
+	int ret;
+	void *iter;
+	struct scmi_iterator_ops ops = {
+		.prepare_message = iter_pinctrl_conf_get_prepare_message,
+		.update_state = iter_pinctrl_conf_get_update_state,
+		.process_response = iter_pinctrl_conf_get_process_response,
+	};
+	struct scmi_conf_get_ipriv ipriv = {
+		.selector = selector,
+		.type = type,
+		.all = 1,
+		.config_types = config_types,
+		.config_values = config_values,
+	};
+
+	if (!config_values || !config_types || type == FUNCTION_TYPE)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_validate_id(ph, selector, type);
+	if (ret)
+		return ret;
+
+	iter = ph->hops->iter_response_init(ph, &ops, size, PINCTRL_CONFIG_GET,
+					    sizeof(struct scmi_msg_conf_get),
+					    &ipriv);
+
+	if (IS_ERR(iter))
+		return PTR_ERR(iter);
+
+	return ph->hops->iter_response_run(iter);
+}
+
+static int scmi_pinctrl_config_set(const struct scmi_protocol_handle *ph,
+				   u32 selector,
+				   enum scmi_pinctrl_selector_type type,
+				   unsigned long *configs, unsigned int nr_configs)
+{
+	struct scmi_xfer *t;
+	struct scmi_msg_conf_set *tx;
+	u32 attributes;
+	int ret, i;
+	unsigned int configs_in_chunk, conf_num = 0;
+	unsigned int chunk;
+	int max_msg_size = ph->hops->get_max_msg_size(ph);
+
+	if (!configs || type == FUNCTION_TYPE)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_validate_id(ph, selector, type);
+	if (ret)
+		return ret;
+
+	configs_in_chunk = (max_msg_size - sizeof(*tx)) / (sizeof(unsigned long) * 2);
+	while (conf_num < nr_configs) {
+		chunk = (nr_configs - conf_num > configs_in_chunk) ? configs_in_chunk :
+			nr_configs - conf_num;
+
+		ret = ph->xops->xfer_get_init(ph, PINCTRL_CONFIG_SET,
+					      sizeof(*tx) + chunk * 2 * sizeof(unsigned long),
+					      0, &t);
+		if (ret)
+			return ret;
+
+		tx = t->tx.buf;
+		tx->identifier = cpu_to_le32(selector);
+		attributes = FIELD_PREP(GENMASK(1, 0), type) |
+			FIELD_PREP(GENMASK(9, 2), chunk);
+		tx->attributes = cpu_to_le32(attributes);
+
+		for (i = 0; i < chunk; i++) {
+			tx->configs[i * 2] = cpu_to_le32(pinconf_to_config_param(configs[i]));
+			tx->configs[i * 2 + 1] =
+				cpu_to_le32(pinconf_to_config_argument(configs[i]));
+		}
+
+		ret = ph->xops->do_xfer(ph, t);
+
+		ph->xops->xfer_put(ph, t);
+
+		if (ret)
+			break;
+
+		conf_num += chunk;
+	}
+
+	return ret;
+}
+
+static int scmi_pinctrl_function_select(const struct scmi_protocol_handle *ph,
+					u32 identifier,
+					enum scmi_pinctrl_selector_type type,
+					u32 function_id)
+{
+	int ret;
+	struct scmi_xfer *t;
+	struct scmi_msg_func_set *tx;
+
+	if (type == FUNCTION_TYPE)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_validate_id(ph, identifier, type);
+	if (ret)
+		return ret;
+
+	ret = ph->xops->xfer_get_init(ph, PINCTRL_FUNCTION_SELECT, sizeof(*tx), 0, &t);
+	if (ret)
+		return ret;
+
+	tx = t->tx.buf;
+	tx->identifier = cpu_to_le32(identifier);
+	tx->function_id = cpu_to_le32(function_id);
+	tx->flags = cpu_to_le32(type);
+
+	ret = ph->xops->do_xfer(ph, t);
+	ph->xops->xfer_put(ph, t);
+
+	return ret;
+}
+
+static int scmi_pinctrl_request(const struct scmi_protocol_handle *ph,
+				u32 identifier,
+				enum scmi_pinctrl_selector_type type)
+{
+	int ret;
+	struct scmi_xfer *t;
+	struct scmi_msg_request *tx;
+
+	if (type == FUNCTION_TYPE)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_validate_id(ph, identifier, type);
+	if (ret)
+		return ret;
+
+	ret = ph->xops->xfer_get_init(ph, PINCTRL_REQUEST, sizeof(*tx), 0, &t);
+
+	tx = t->tx.buf;
+	tx->identifier = cpu_to_le32(identifier);
+	tx->flags = cpu_to_le32(type);
+
+	ret = ph->xops->do_xfer(ph, t);
+	ph->xops->xfer_put(ph, t);
+
+	return ret;
+}
+
+static int scmi_pinctrl_pin_request(const struct scmi_protocol_handle *ph,
+				    u32 pin)
+{
+	return scmi_pinctrl_request(ph, pin, PIN_TYPE);
+}
+
+static int scmi_pinctrl_free(const struct scmi_protocol_handle *ph,
+			     u32 identifier,
+			     enum scmi_pinctrl_selector_type type)
+{
+	int ret;
+	struct scmi_xfer *t;
+	struct scmi_msg_request *tx;
+
+	if (type == FUNCTION_TYPE)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_validate_id(ph, identifier, type);
+	if (ret)
+		return ret;
+
+	ret = ph->xops->xfer_get_init(ph, PINCTRL_RELEASE, sizeof(*tx), 0, &t);
+
+	tx = t->tx.buf;
+	tx->identifier = cpu_to_le32(identifier);
+	tx->flags = cpu_to_le32(type);
+
+	ret = ph->xops->do_xfer(ph, t);
+	ph->xops->xfer_put(ph, t);
+
+	return ret;
+}
+
+static int scmi_pinctrl_pin_free(const struct scmi_protocol_handle *ph, u32 pin)
+{
+	return scmi_pinctrl_free(ph, pin, PIN_TYPE);
+}
+
+static int scmi_pinctrl_get_group_info(const struct scmi_protocol_handle *ph,
+				       u32 selector,
+				       struct scmi_group_info *group)
+{
+	int ret;
+
+	if (!group)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_attributes(ph, GROUP_TYPE, selector,
+				      group->name,
+				      &group->nr_pins);
+	if (ret)
+		return ret;
+
+	if (!group->nr_pins) {
+		dev_err(ph->dev, "Group %d has 0 elements", selector);
+		return -ENODATA;
+	}
+
+	group->group_pins = kmalloc_array(group->nr_pins, sizeof(*group->group_pins), GFP_KERNEL);
+	if (!group->group_pins)
+		return -ENOMEM;
+
+	ret = scmi_pinctrl_list_associations(ph, selector, GROUP_TYPE,
+					     group->nr_pins, group->group_pins);
+	if (ret) {
+		kfree(group->group_pins);
+		return ret;
+	}
+
+	group->present = true;
+	return 0;
+}
+
+static int scmi_pinctrl_get_group_name(const struct scmi_protocol_handle *ph,
+				       u32 selector, const char **name)
+{
+	struct scmi_pinctrl_info *pi = ph->get_priv(ph);
+
+	if (!name)
+		return -EINVAL;
+
+	if (selector >= pi->nr_groups)
+		return -EINVAL;
+
+	if (!pi->groups[selector].present) {
+		int ret;
+
+		ret = scmi_pinctrl_get_group_info(ph, selector,
+						  &pi->groups[selector]);
+		if (ret)
+			return ret;
+	}
+
+	*name = pi->groups[selector].name;
+
+	return 0;
+}
+
+static int scmi_pinctrl_group_pins_get(const struct scmi_protocol_handle *ph,
+				       u32 selector, const unsigned int **pins,
+				       unsigned int *nr_pins)
+{
+	struct scmi_pinctrl_info *pi = ph->get_priv(ph);
+
+	if (!pins || !nr_pins)
+		return -EINVAL;
+
+	if (selector >= pi->nr_groups)
+		return -EINVAL;
+
+	if (!pi->groups[selector].present) {
+		int ret;
+
+		ret = scmi_pinctrl_get_group_info(ph, selector,
+						  &pi->groups[selector]);
+		if (ret)
+			return ret;
+	}
+
+	*pins = pi->groups[selector].group_pins;
+	*nr_pins = pi->groups[selector].nr_pins;
+
+	return 0;
+}
+
+static int scmi_pinctrl_get_function_info(const struct scmi_protocol_handle *ph,
+					  u32 selector,
+					  struct scmi_function_info *func)
+{
+	int ret;
+
+	if (!func)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_attributes(ph, FUNCTION_TYPE, selector,
+				      func->name,
+				      &func->nr_groups);
+	if (ret)
+		return ret;
+
+	if (!func->nr_groups) {
+		dev_err(ph->dev, "Function %d has 0 elements", selector);
+		return -ENODATA;
+	}
+
+	func->groups = kmalloc_array(func->nr_groups, sizeof(*func->groups), GFP_KERNEL);
+	if (!func->groups)
+		return -ENOMEM;
+
+	ret = scmi_pinctrl_list_associations(ph, selector, FUNCTION_TYPE,
+					     func->nr_groups, func->groups);
+	if (ret) {
+		kfree(func->groups);
+		return ret;
+	}
+
+	func->present = true;
+	return 0;
+}
+
+static int scmi_pinctrl_get_function_name(const struct scmi_protocol_handle *ph,
+					  u32 selector, const char **name)
+{
+	struct scmi_pinctrl_info *pi = ph->get_priv(ph);
+
+	if (!name)
+		return -EINVAL;
+
+	if (selector >= pi->nr_functions)
+		return -EINVAL;
+
+	if (!pi->functions[selector].present) {
+		int ret;
+
+		ret = scmi_pinctrl_get_function_info(ph, selector,
+						     &pi->functions[selector]);
+		if (ret)
+			return ret;
+	}
+
+	*name = pi->functions[selector].name;
+	return 0;
+}
+
+static int scmi_pinctrl_function_groups_get(const struct scmi_protocol_handle *ph,
+					    u32 selector,
+					    unsigned int *nr_groups,
+					    const unsigned int **groups)
+{
+	struct scmi_pinctrl_info *pi = ph->get_priv(ph);
+
+	if (!groups || !nr_groups)
+		return -EINVAL;
+
+	if (selector >= pi->nr_functions)
+		return -EINVAL;
+
+	if (!pi->functions[selector].present) {
+		int ret;
+
+		ret = scmi_pinctrl_get_function_info(ph, selector,
+						     &pi->functions[selector]);
+		if (ret)
+			return ret;
+	}
+
+	*groups = pi->functions[selector].groups;
+	*nr_groups = pi->functions[selector].nr_groups;
+
+	return 0;
+}
+
+static int scmi_pinctrl_mux_set(const struct scmi_protocol_handle *ph,
+				u32 selector, u32 group)
+{
+	return scmi_pinctrl_function_select(ph, group, GROUP_TYPE,
+					    selector);
+}
+
+static int scmi_pinctrl_get_pin_info(const struct scmi_protocol_handle *ph,
+				     u32 selector, struct scmi_pin_info *pin)
+{
+	int ret;
+
+	if (!pin)
+		return -EINVAL;
+
+	ret = scmi_pinctrl_attributes(ph, PIN_TYPE, selector,
+				      pin->name, NULL);
+	if (ret)
+		return ret;
+
+	pin->present = true;
+	return 0;
+}
+
+static int scmi_pinctrl_get_pin_name(const struct scmi_protocol_handle *ph,
+				     u32 selector, const char **name)
+{
+	struct scmi_pinctrl_info *pi = ph->get_priv(ph);
+
+	if (!name)
+		return -EINVAL;
+
+	if (selector >= pi->nr_pins)
+		return -EINVAL;
+
+	if (!pi->pins[selector].present) {
+		int ret;
+
+		ret = scmi_pinctrl_get_pin_info(ph, selector,
+						&pi->pins[selector]);
+		if (ret)
+			return ret;
+	}
+
+	*name = pi->pins[selector].name;
+
+	return 0;
+}
+
+static int scmi_pinctrl_name_get(const struct scmi_protocol_handle *ph,
+				 u32 selector,
+				 enum scmi_pinctrl_selector_type type,
+				 const char **name)
+{
+	switch (type) {
+	case PIN_TYPE:
+		return scmi_pinctrl_get_pin_name(ph, selector, name);
+	case GROUP_TYPE:
+		return scmi_pinctrl_get_group_name(ph, selector, name);
+	case FUNCTION_TYPE:
+		return scmi_pinctrl_get_function_name(ph, selector, name);
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct scmi_pinctrl_proto_ops pinctrl_proto_ops = {
+	.count_get = scmi_pinctrl_count_get,
+	.name_get = scmi_pinctrl_name_get,
+	.group_pins_get = scmi_pinctrl_group_pins_get,
+	.function_groups_get = scmi_pinctrl_function_groups_get,
+	.mux_set = scmi_pinctrl_mux_set,
+	.config_get = scmi_pinctrl_config_get,
+	.config_get_all = scmi_pinctrl_config_get_all,
+	.config_set = scmi_pinctrl_config_set,
+	.pin_request = scmi_pinctrl_pin_request,
+	.pin_free = scmi_pinctrl_pin_free,
+};
+
+static int scmi_pinctrl_protocol_init(const struct scmi_protocol_handle *ph)
+{
+	int ret;
+	u32 version;
+	struct scmi_pinctrl_info *pinfo;
+
+	ret = ph->xops->version_get(ph, &version);
+	if (ret)
+		return ret;
+
+	dev_dbg(ph->dev, "Pinctrl Version %d.%d\n",
+		PROTOCOL_REV_MAJOR(version), PROTOCOL_REV_MINOR(version));
+
+	pinfo = devm_kzalloc(ph->dev, sizeof(*pinfo), GFP_KERNEL);
+	if (!pinfo)
+		return -ENOMEM;
+
+	ret = scmi_pinctrl_attributes_get(ph, pinfo);
+	if (ret)
+		return ret;
+
+	pinfo->pins = devm_kcalloc(ph->dev, pinfo->nr_pins,
+				   sizeof(*pinfo->pins),
+				   GFP_KERNEL);
+	if (!pinfo->pins)
+		return -ENOMEM;
+
+	pinfo->groups = devm_kcalloc(ph->dev, pinfo->nr_groups,
+				     sizeof(*pinfo->groups),
+				     GFP_KERNEL);
+	if (!pinfo->groups)
+		return -ENOMEM;
+
+	pinfo->functions = devm_kcalloc(ph->dev, pinfo->nr_functions,
+					sizeof(*pinfo->functions),
+					GFP_KERNEL);
+	if (!pinfo->functions)
+		return -ENOMEM;
+
+	pinfo->version = version;
+
+	return ph->set_priv(ph, pinfo, version);
+}
+
+static int scmi_pinctrl_protocol_deinit(const struct scmi_protocol_handle *ph)
+{
+	int i;
+	struct scmi_pinctrl_info *pi = ph->get_priv(ph);
+
+	for (i = 0; i < pi->nr_groups; i++) {
+		if (pi->groups[i].present) {
+			kfree(pi->groups[i].group_pins);
+			pi->groups[i].present = false;
+		}
+	}
+
+	for (i = 0; i < pi->nr_functions; i++) {
+		if (pi->functions[i].present) {
+			kfree(pi->functions[i].groups);
+			pi->functions[i].present = false;
+		}
+	}
+
+	return 0;
+}
+
+static const struct scmi_protocol scmi_pinctrl = {
+	.id = SCMI_PROTOCOL_PINCTRL,
+	.owner = THIS_MODULE,
+	.instance_init = &scmi_pinctrl_protocol_init,
+	.instance_deinit = &scmi_pinctrl_protocol_deinit,
+	.ops = &pinctrl_proto_ops,
+	.supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION,
+};
+
+DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(pinctrl, scmi_pinctrl)
diff --git a/drivers/firmware/arm_scmi/protocols.h b/drivers/firmware/arm_scmi/protocols.h
index 08de8dc064c1..e30f91ce53c8 100644
--- a/drivers/firmware/arm_scmi/protocols.h
+++ b/drivers/firmware/arm_scmi/protocols.h
@@ -347,6 +347,7 @@ void __exit scmi_##name##_unregister(void)			\
 DECLARE_SCMI_REGISTER_UNREGISTER(base);
 DECLARE_SCMI_REGISTER_UNREGISTER(clock);
 DECLARE_SCMI_REGISTER_UNREGISTER(perf);
+DECLARE_SCMI_REGISTER_UNREGISTER(pinctrl);
 DECLARE_SCMI_REGISTER_UNREGISTER(power);
 DECLARE_SCMI_REGISTER_UNREGISTER(reset);
 DECLARE_SCMI_REGISTER_UNREGISTER(sensors);
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 19a06b872afe..516c98252732 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -717,6 +717,51 @@ struct scmi_powercap_proto_ops {
 					  u32 *power_thresh_high);
 };
 
+enum scmi_pinctrl_selector_type {
+	PIN_TYPE = 0,
+	GROUP_TYPE,
+	FUNCTION_TYPE,
+};
+
+/**
+ * struct scmi_pinctrl_proto_ops - represents the various operations provided
+ * by SCMI Pinctrl Protocol
+ *
+ * @count_get: returns count of the registered elements in given type
+ * @name_get: returns name by index of given type
+ * @group_pins_get: returns the set of pins, assigned to the specified group
+ * @function_groups_get: returns the set of groups, assigned to the specified
+ *	function
+ * @mux_set: set muxing function for groups of pins
+ * @config_get: returns configuration parameter for pin or group
+ * @config_set: sets the configuration parameter for pin or group
+ * @pin_request: aquire pin before selecting mux setting
+ * @pin_free: frees pin, acquired by request_pin call
+ */
+struct scmi_pinctrl_proto_ops {
+	int (*count_get)(const struct scmi_protocol_handle *ph,
+			 enum scmi_pinctrl_selector_type type);
+	int (*name_get)(const struct scmi_protocol_handle *ph, u32 selector,
+			enum scmi_pinctrl_selector_type type, const char **name);
+	int (*group_pins_get)(const struct scmi_protocol_handle *ph, u32 selector,
+			      const unsigned int **pins, unsigned int *nr_pins);
+	int (*function_groups_get)(const struct scmi_protocol_handle *ph, u32 selector,
+				   unsigned int *nr_groups, const unsigned int **groups);
+	int (*mux_set)(const struct scmi_protocol_handle *ph, u32 selector, u32 group);
+	int (*config_get)(const struct scmi_protocol_handle *ph, u32 selector,
+			  enum scmi_pinctrl_selector_type type,
+			  u8 config_type, unsigned long *config_value);
+	int (*config_get_all)(const struct scmi_protocol_handle *ph,
+			      u32 selector,
+			      enum scmi_pinctrl_selector_type type, u16 size,
+			      u8 *config_types, unsigned long *config_values);
+	int (*config_set)(const struct scmi_protocol_handle *ph, u32 selector,
+			  enum scmi_pinctrl_selector_type type,
+			  unsigned long *configs, unsigned int nr_configs);
+	int (*pin_request)(const struct scmi_protocol_handle *ph, u32 pin);
+	int (*pin_free)(const struct scmi_protocol_handle *ph, u32 pin);
+};
+
 /**
  * struct scmi_notify_ops  - represents notifications' operations provided by
  * SCMI core
@@ -824,6 +869,7 @@ enum scmi_std_protocol {
 	SCMI_PROTOCOL_RESET = 0x16,
 	SCMI_PROTOCOL_VOLTAGE = 0x17,
 	SCMI_PROTOCOL_POWERCAP = 0x18,
+	SCMI_PROTOCOL_PINCTRL = 0x19,
 };
 
 enum scmi_system_events {

-- 
2.37.1



From peng.fan at oss.nxp.com  Fri Dec 15 03:56:34 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 15 Dec 2023 19:56:34 +0800
Subject: [PATCH 6/7] pinctrl: Implementation of the generic scmi-pinctrl
 driver
In-Reply-To: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
Message-ID: <20231215-pinctrl-scmi-v1-6-0fe35e4611f7@nxp.com>

From: Peng Fan <peng.fan at nxp.com>

scmi-pinctrl driver implements pinctrl driver interface and using
SCMI protocol to redirect messages from pinctrl subsystem SDK to
SCMI platform firmware, which does the changes in HW.

Co-developed-by: Oleksii Moisieiev <oleksii_moisieiev at epam.com>
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev at epam.com>
Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 MAINTAINERS                    |   1 +
 drivers/pinctrl/Kconfig        |  11 ++
 drivers/pinctrl/Makefile       |   1 +
 drivers/pinctrl/pinctrl-scmi.c | 403 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 416 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8d971adeee22..0ca47b9c9f55 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21172,6 +21172,7 @@ F:	drivers/clk/clk-sc[mp]i.c
 F:	drivers/cpufreq/sc[mp]i-cpufreq.c
 F:	drivers/firmware/arm_scmi/
 F:	drivers/firmware/arm_scpi.c
+F:	drivers/pinctrl/pinctrl-scmi.c
 F:	drivers/pmdomain/arm/
 F:	drivers/powercap/arm_scmi_powercap.c
 F:	drivers/regulator/scmi-regulator.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8163a5983166..27b26e428f60 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -432,6 +432,17 @@ config PINCTRL_ROCKCHIP
 	help
           This support pinctrl and GPIO driver for Rockchip SoCs.
 
+config PINCTRL_SCMI
+	tristate "Pinctrl driver using SCMI protocol interface"
+	depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
+	select PINMUX
+	select GENERIC_PINCONF
+	help
+	  This driver provides support for pinctrl which is controlled
+	  by firmware that implements the SCMI interface.
+	  It uses SCMI Message Protocol to interact with the
+	  firmware providing all the pinctrl controls.
+
 config PINCTRL_SINGLE
 	tristate "One-register-per-pin type device tree based pinctrl driver"
 	depends on OF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 1071f301cc70..ba755ed2d46c 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_PINCTRL_PIC32)	+= pinctrl-pic32.o
 obj-$(CONFIG_PINCTRL_PISTACHIO)	+= pinctrl-pistachio.o
 obj-$(CONFIG_PINCTRL_RK805)	+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_ROCKCHIP)	+= pinctrl-rockchip.o
+obj-$(CONFIG_PINCTRL_SCMI)	+= pinctrl-scmi.o
 obj-$(CONFIG_PINCTRL_SINGLE)	+= pinctrl-single.o
 obj-$(CONFIG_PINCTRL_ST) 	+= pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX) 	+= pinctrl-stmfx.o
diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
new file mode 100644
index 000000000000..0710ce9a1b42
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-scmi.c
@@ -0,0 +1,403 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * System Control and Power Interface (SCMI) Protocol based pinctrl driver
+ *
+ * Copyright (C) 2023 EPAM
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/seq_file.h>
+#include <linux/scmi_protocol.h>
+#include <linux/slab.h>
+
+#include <linux/pinctrl/machine.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinmux.h>
+
+#include "pinctrl-utils.h"
+#include "core.h"
+#include "pinconf.h"
+
+#define DRV_NAME "scmi-pinctrl"
+
+static const struct scmi_pinctrl_proto_ops *pinctrl_ops;
+
+struct scmi_pinctrl_funcs {
+	unsigned int num_groups;
+	const char **groups;
+};
+
+struct scmi_pinctrl {
+	struct device *dev;
+	struct scmi_protocol_handle *ph;
+	struct pinctrl_dev *pctldev;
+	struct pinctrl_desc pctl_desc;
+	struct scmi_pinctrl_funcs *functions;
+	unsigned int nr_functions;
+	char **groups;
+	unsigned int nr_groups;
+	struct pinctrl_pin_desc *pins;
+	unsigned int nr_pins;
+};
+
+static int pinctrl_scmi_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	return pinctrl_ops->count_get(pmx->ph, GROUP_TYPE);
+}
+
+static const char *pinctrl_scmi_get_group_name(struct pinctrl_dev *pctldev, unsigned int selector)
+{
+	int ret;
+	const char *name;
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	ret = pinctrl_ops->name_get(pmx->ph, selector, GROUP_TYPE, &name);
+	if (ret) {
+		dev_err(pmx->dev, "get name failed with err %d", ret);
+		return NULL;
+	}
+
+	return name;
+}
+
+static int pinctrl_scmi_get_group_pins(struct pinctrl_dev *pctldev,
+				       unsigned int selector,
+				       const unsigned int **pins,
+				       unsigned int *num_pins)
+{
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	return pinctrl_ops->group_pins_get(pmx->ph, selector, pins, num_pins);
+}
+
+static const struct pinctrl_ops pinctrl_scmi_pinctrl_ops = {
+	.get_groups_count = pinctrl_scmi_get_groups_count,
+	.get_group_name = pinctrl_scmi_get_group_name,
+	.get_group_pins = pinctrl_scmi_get_group_pins,
+#ifdef CONFIG_OF
+	.dt_node_to_map = pinconf_generic_dt_node_to_map_all,
+	.dt_free_map = pinconf_generic_dt_free_map,
+#endif
+};
+
+static int pinctrl_scmi_get_functions_count(struct pinctrl_dev *pctldev)
+{
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	return pinctrl_ops->count_get(pmx->ph, FUNCTION_TYPE);
+}
+
+static const char *pinctrl_scmi_get_function_name(struct pinctrl_dev *pctldev,
+						  unsigned int selector)
+{
+	int ret;
+	const char *name;
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	ret = pinctrl_ops->name_get(pmx->ph, selector, FUNCTION_TYPE, &name);
+	if (ret) {
+		dev_err(pmx->dev, "get name failed with err %d", ret);
+		return NULL;
+	}
+
+	return name;
+}
+
+static int pinctrl_scmi_get_function_groups(struct pinctrl_dev *pctldev,
+					    unsigned int selector,
+					    const char * const **groups,
+					    unsigned int * const num_groups)
+{
+	const unsigned int *group_ids;
+	int ret, i;
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	if (!groups || !num_groups)
+		return -EINVAL;
+
+	if (selector < pmx->nr_functions &&
+	    pmx->functions[selector].num_groups) {
+		*groups = (const char * const *)pmx->functions[selector].groups;
+		*num_groups = pmx->functions[selector].num_groups;
+		return 0;
+	}
+
+	ret = pinctrl_ops->function_groups_get(pmx->ph, selector,
+					       &pmx->functions[selector].num_groups,
+					       &group_ids);
+	if (ret) {
+		dev_err(pmx->dev, "Unable to get function groups, err %d", ret);
+		return ret;
+	}
+
+	*num_groups = pmx->functions[selector].num_groups;
+	if (!*num_groups)
+		return -EINVAL;
+
+	pmx->functions[selector].groups =
+		devm_kcalloc(pmx->dev, *num_groups, sizeof(*pmx->functions[selector].groups),
+			     GFP_KERNEL);
+	if (!pmx->functions[selector].groups)
+		return -ENOMEM;
+
+	for (i = 0; i < *num_groups; i++) {
+		pmx->functions[selector].groups[i] =
+			pinctrl_scmi_get_group_name(pmx->pctldev,
+						    group_ids[i]);
+		if (!pmx->functions[selector].groups[i]) {
+			ret = -ENOMEM;
+			goto err_free;
+		}
+	}
+
+	*groups = (const char * const *)pmx->functions[selector].groups;
+
+	return 0;
+
+err_free:
+	devm_kfree(pmx->dev, pmx->functions[selector].groups);
+
+	return ret;
+}
+
+static int pinctrl_scmi_func_set_mux(struct pinctrl_dev *pctldev, unsigned int selector,
+				     unsigned int group)
+{
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	return pinctrl_ops->mux_set(pmx->ph, selector, group);
+}
+
+static int pinctrl_scmi_request(struct pinctrl_dev *pctldev, unsigned int offset)
+{
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	return pinctrl_ops->pin_request(pmx->ph, offset);
+}
+
+static int pinctrl_scmi_free(struct pinctrl_dev *pctldev, unsigned int offset)
+{
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	return pinctrl_ops->pin_free(pmx->ph, offset);
+}
+
+static const struct pinmux_ops pinctrl_scmi_pinmux_ops = {
+	.request = pinctrl_scmi_request,
+	.free = pinctrl_scmi_free,
+	.get_functions_count = pinctrl_scmi_get_functions_count,
+	.get_function_name = pinctrl_scmi_get_function_name,
+	.get_function_groups = pinctrl_scmi_get_function_groups,
+	.set_mux = pinctrl_scmi_func_set_mux,
+};
+
+static int pinctrl_scmi_pinconf_get(struct pinctrl_dev *pctldev, unsigned int _pin,
+				    unsigned long *config)
+{
+	int ret;
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+	enum pin_config_param config_type;
+	unsigned long config_value;
+
+	if (!config)
+		return -EINVAL;
+
+	config_type = pinconf_to_config_param(*config);
+
+	ret = pinctrl_ops->config_get(pmx->ph, _pin, PIN_TYPE, config_type, &config_value);
+	if (ret)
+		return ret;
+
+	*config = pinconf_to_config_packed(config_type, config_value);
+
+	return 0;
+}
+
+static int pinctrl_scmi_pinconf_set(struct pinctrl_dev *pctldev,
+				    unsigned int _pin,
+				    unsigned long *configs,
+				    unsigned int num_configs)
+{
+	int ret;
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+
+	if (!configs || !num_configs)
+		return -EINVAL;
+
+	ret = pinctrl_ops->config_set(pmx->ph, _pin, PIN_TYPE, configs, num_configs);
+	if (ret)
+		dev_err(pmx->dev, "Error parsing config %d\n", ret);
+
+	return ret;
+}
+
+static int pinctrl_scmi_pinconf_group_set(struct pinctrl_dev *pctldev,
+					  unsigned int group,
+					  unsigned long *configs,
+					  unsigned int num_configs)
+{
+	int ret;
+	struct scmi_pinctrl *pmx =  pinctrl_dev_get_drvdata(pctldev);
+
+	if (!configs || !num_configs)
+		return -EINVAL;
+
+	ret = pinctrl_ops->config_set(pmx->ph, group, GROUP_TYPE, configs, num_configs);
+	if (ret)
+		dev_err(pmx->dev, "Error parsing config %d", ret);
+
+	return ret;
+};
+
+static int pinctrl_scmi_pinconf_group_get(struct pinctrl_dev *pctldev,
+					  unsigned int group,
+					  unsigned long *config)
+{
+	int ret;
+	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+	enum pin_config_param config_type;
+	unsigned long config_value;
+
+	if (!config)
+		return -EINVAL;
+
+	config_type = pinconf_to_config_param(*config);
+
+	ret = pinctrl_ops->config_get(pmx->ph, group, GROUP_TYPE, config_type, &config_value);
+	if (ret)
+		return ret;
+
+	*config = pinconf_to_config_packed(config_type, config_value);
+
+	return 0;
+}
+
+static const struct pinconf_ops pinctrl_scmi_pinconf_ops = {
+	.is_generic = true,
+	.pin_config_get = pinctrl_scmi_pinconf_get,
+	.pin_config_set = pinctrl_scmi_pinconf_set,
+	.pin_config_group_set = pinctrl_scmi_pinconf_group_set,
+	.pin_config_group_get = pinctrl_scmi_pinconf_group_get,
+	.pin_config_config_dbg_show = pinconf_generic_dump_config,
+};
+
+static int pinctrl_scmi_get_pins(struct scmi_pinctrl *pmx,
+				 unsigned int *nr_pins,
+				 const struct pinctrl_pin_desc **pins)
+{
+	int ret, i;
+
+	if (!pins || !nr_pins)
+		return -EINVAL;
+
+	if (pmx->nr_pins) {
+		*pins = pmx->pins;
+		*nr_pins = pmx->nr_pins;
+		return 0;
+	}
+
+	*nr_pins = pinctrl_ops->count_get(pmx->ph, PIN_TYPE);
+
+	pmx->nr_pins = *nr_pins;
+	pmx->pins = devm_kmalloc_array(pmx->dev, *nr_pins, sizeof(*pmx->pins), GFP_KERNEL);
+	if (!pmx->pins)
+		return -ENOMEM;
+
+	for (i = 0; i < *nr_pins; i++) {
+		pmx->pins[i].number = i;
+		ret = pinctrl_ops->name_get(pmx->ph, i, PIN_TYPE, &pmx->pins[i].name);
+		if (ret) {
+			dev_err(pmx->dev, "Can't get name for pin %d: rc %d", i, ret);
+			pmx->nr_pins = 0;
+			return ret;
+		}
+	}
+
+	*pins = pmx->pins;
+	dev_dbg(pmx->dev, "got pins %d", *nr_pins);
+
+	return 0;
+}
+
+static const struct scmi_device_id scmi_id_table[] = {
+	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },
+	{ }
+};
+MODULE_DEVICE_TABLE(scmi, scmi_id_table);
+
+static int scmi_pinctrl_probe(struct scmi_device *sdev)
+{
+	int ret;
+	struct device *dev = &sdev->dev;
+	struct scmi_pinctrl *pmx;
+	const struct scmi_handle *handle;
+	struct scmi_protocol_handle *ph;
+
+	if (!sdev || !sdev->handle)
+		return -EINVAL;
+
+	handle = sdev->handle;
+
+	pinctrl_ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_PINCTRL, &ph);
+	if (IS_ERR(pinctrl_ops))
+		return PTR_ERR(pinctrl_ops);
+
+	pmx = devm_kzalloc(dev, sizeof(*pmx), GFP_KERNEL);
+	if (!pmx)
+		return -ENOMEM;
+
+	pmx->ph = ph;
+
+	pmx->dev = dev;
+	pmx->pctl_desc.name = DRV_NAME;
+	pmx->pctl_desc.owner = THIS_MODULE;
+	pmx->pctl_desc.pctlops = &pinctrl_scmi_pinctrl_ops;
+	pmx->pctl_desc.pmxops = &pinctrl_scmi_pinmux_ops;
+	pmx->pctl_desc.confops = &pinctrl_scmi_pinconf_ops;
+
+	ret = pinctrl_scmi_get_pins(pmx, &pmx->pctl_desc.npins,
+				    &pmx->pctl_desc.pins);
+	if (ret)
+		return ret;
+
+	ret = devm_pinctrl_register_and_init(dev, &pmx->pctl_desc, pmx, &pmx->pctldev);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to register pinctrl\n");
+
+	pmx->nr_functions = pinctrl_scmi_get_functions_count(pmx->pctldev);
+	pmx->nr_groups = pinctrl_scmi_get_groups_count(pmx->pctldev);
+
+	if (pmx->nr_functions) {
+		pmx->functions =
+			devm_kcalloc(dev, pmx->nr_functions, sizeof(*pmx->functions),
+				     GFP_KERNEL);
+		if (!pmx->functions)
+			return -ENOMEM;
+	}
+
+	if (pmx->nr_groups) {
+		pmx->groups =
+			devm_kcalloc(dev, pmx->nr_groups, sizeof(*pmx->groups), GFP_KERNEL);
+		if (!pmx->groups)
+			return -ENOMEM;
+	}
+
+	return pinctrl_enable(pmx->pctldev);
+}
+
+static struct scmi_driver scmi_pinctrl_driver = {
+	.name = DRV_NAME,
+	.probe = scmi_pinctrl_probe,
+	.id_table = scmi_id_table,
+};
+module_scmi_driver(scmi_pinctrl_driver);
+
+MODULE_AUTHOR("Oleksii Moisieiev <oleksii_moisieiev at epam.com>");
+MODULE_DESCRIPTION("ARM SCMI pin controller driver");
+MODULE_LICENSE("GPL");

-- 
2.37.1



From peng.fan at oss.nxp.com  Fri Dec 15 03:56:35 2023
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 15 Dec 2023 19:56:35 +0800
Subject: [PATCH 7/7] pinctrl: scmi: implement
 pinctrl_scmi_imx_dt_node_to_map
In-Reply-To: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
Message-ID: <20231215-pinctrl-scmi-v1-7-0fe35e4611f7@nxp.com>

From: Peng Fan <peng.fan at nxp.com>

i.MX95 System Manager FW supports SCMI PINCTRL protocol, but uses
OEM Pin Configuration type, so need i.MX specific dt_node_to_map.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/pinctrl/Makefile           |   2 +-
 drivers/pinctrl/pinctrl-scmi-imx.c | 117 +++++++++++++++++++++++++++++++++++++
 drivers/pinctrl/pinctrl-scmi.c     |  16 +++++
 drivers/pinctrl/pinctrl-scmi.h     |  12 ++++
 4 files changed, 146 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index ba755ed2d46c..d96b7ede1355 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -44,7 +44,7 @@ obj-$(CONFIG_PINCTRL_PIC32)	+= pinctrl-pic32.o
 obj-$(CONFIG_PINCTRL_PISTACHIO)	+= pinctrl-pistachio.o
 obj-$(CONFIG_PINCTRL_RK805)	+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_ROCKCHIP)	+= pinctrl-rockchip.o
-obj-$(CONFIG_PINCTRL_SCMI)	+= pinctrl-scmi.o
+obj-$(CONFIG_PINCTRL_SCMI)	+= pinctrl-scmi.o pinctrl-scmi-imx.o
 obj-$(CONFIG_PINCTRL_SINGLE)	+= pinctrl-single.o
 obj-$(CONFIG_PINCTRL_ST) 	+= pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX) 	+= pinctrl-stmfx.o
diff --git a/drivers/pinctrl/pinctrl-scmi-imx.c b/drivers/pinctrl/pinctrl-scmi-imx.c
new file mode 100644
index 000000000000..e9d02e4c2cc1
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-scmi-imx.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2023 NXP
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinmux.h>
+
+#include "pinctrl-scmi.h"
+#include "pinctrl-utils.h"
+#include "core.h"
+#include "pinconf.h"
+
+/* SCMI pin control types, aligned with SCMI firmware */
+#define IMX_SCMI_PIN_TYPE_MUX		192
+#define IMX_SCMI_PIN_TYPE_CONFIG	193
+#define IMX_SCMI_PIN_TYPE_DAISY_ID	194
+#define IMX_SCMI_PIN_TYPE_DAISY_CFG	195
+
+#define IMX_SCMI_NO_PAD_CTL		BIT(31)
+#define IMX_SCMI_PAD_SION		BIT(30)
+#define IMX_SCMI_IOMUXC_CONFIG_SION	BIT(4)
+
+#define IMX_SCMI_NUM_CFG	4
+#define IMX_SCMI_PIN_SIZE	24
+
+int pinctrl_scmi_imx_dt_node_to_map(struct pinctrl_dev *pctldev, struct device_node *np,
+				    struct pinctrl_map **map, unsigned int *num_maps)
+{
+	struct pinctrl_map *new_map;
+	const __be32 *list;
+	unsigned long *configs = NULL;
+	unsigned long cfg[IMX_SCMI_NUM_CFG];
+	int map_num, size, pin_size, pin_id, num_pins;
+	int mux_reg, conf_reg, input_reg, mux_val, conf_val, input_val;
+	int i, j;
+	uint32_t ncfg;
+	static uint32_t daisy_off;
+
+	if (!daisy_off) {
+		if (of_machine_is_compatible("fsl,imx95"))
+			daisy_off = 0x408;
+		else
+			dev_err(pctldev->dev, "platform not support scmi pinctrl\n");
+	}
+
+	list = of_get_property(np, "fsl,pins", &size);
+	if (!list) {
+		dev_err(pctldev->dev, "no fsl,pins property in node %pOF\n", np);
+		return -EINVAL;
+	}
+
+	pin_size = IMX_SCMI_PIN_SIZE;
+
+	if (!size || size % pin_size) {
+		dev_err(pctldev->dev, "Invalid fsl,pins or pins property in node %pOF\n", np);
+		return -EINVAL;
+	}
+
+	num_pins = size / pin_size;
+	map_num = num_pins;
+
+	new_map = kmalloc_array(map_num, sizeof(struct pinctrl_map),
+				GFP_KERNEL);
+	if (!new_map)
+		return -ENOMEM;
+
+	*map = new_map;
+	*num_maps = map_num;
+
+	/* create config map */
+	for (i = 0; i < num_pins; i++) {
+		j = 0;
+		ncfg = IMX_SCMI_NUM_CFG;
+		mux_reg = be32_to_cpu(*list++);
+		conf_reg = be32_to_cpu(*list++);
+		input_reg = be32_to_cpu(*list++);
+		mux_val = be32_to_cpu(*list++);
+		input_val = be32_to_cpu(*list++);
+		conf_val = be32_to_cpu(*list++);
+		if (conf_val & IMX_SCMI_PAD_SION)
+			mux_val |= IMX_SCMI_IOMUXC_CONFIG_SION;
+
+		pin_id = mux_reg / 4;
+
+		cfg[j++] = pinconf_to_config_packed(IMX_SCMI_PIN_TYPE_MUX, mux_val);
+
+		if (!conf_reg || (conf_val & IMX_SCMI_NO_PAD_CTL))
+			ncfg--;
+		else
+			cfg[j++] = pinconf_to_config_packed(IMX_SCMI_PIN_TYPE_CONFIG, conf_val);
+
+		if (!input_reg) {
+			ncfg -= 2;
+		} else {
+			cfg[j++] = pinconf_to_config_packed(IMX_SCMI_PIN_TYPE_DAISY_ID,
+							    (input_reg - daisy_off) / 4);
+			cfg[j++] = pinconf_to_config_packed(IMX_SCMI_PIN_TYPE_DAISY_CFG, input_val);
+		}
+
+		configs = kmemdup(cfg, ncfg * sizeof(unsigned long), GFP_KERNEL);
+
+		new_map[i].type = PIN_MAP_TYPE_CONFIGS_PIN;
+		new_map[i].data.configs.group_or_pin = pin_get_name(pctldev, pin_id);
+		new_map[i].data.configs.configs = configs;
+		new_map[i].data.configs.num_configs = ncfg;
+	}
+
+	return 0;
+}
diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
index 0710ce9a1b42..e677e2064ba7 100644
--- a/drivers/pinctrl/pinctrl-scmi.c
+++ b/drivers/pinctrl/pinctrl-scmi.c
@@ -8,6 +8,7 @@
 #include <linux/device.h>
 #include <linux/err.h>
 #include <linux/module.h>
+#include <linux/of.h>
 #include <linux/seq_file.h>
 #include <linux/scmi_protocol.h>
 #include <linux/slab.h>
@@ -18,6 +19,7 @@
 #include <linux/pinctrl/pinctrl.h>
 #include <linux/pinctrl/pinmux.h>
 
+#include "pinctrl-scmi.h"
 #include "pinctrl-utils.h"
 #include "core.h"
 #include "pinconf.h"
@@ -86,6 +88,16 @@ static const struct pinctrl_ops pinctrl_scmi_pinctrl_ops = {
 #endif
 };
 
+static const struct pinctrl_ops pinctrl_scmi_imx_pinctrl_ops = {
+	.get_groups_count = pinctrl_scmi_get_groups_count,
+	.get_group_name = pinctrl_scmi_get_group_name,
+	.get_group_pins = pinctrl_scmi_get_group_pins,
+#ifdef CONFIG_OF
+	.dt_node_to_map = pinctrl_scmi_imx_dt_node_to_map,
+	.dt_free_map = pinconf_generic_dt_free_map,
+#endif
+};
+
 static int pinctrl_scmi_get_functions_count(struct pinctrl_dev *pctldev)
 {
 	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
@@ -327,6 +339,7 @@ static int pinctrl_scmi_get_pins(struct scmi_pinctrl *pmx,
 
 static const struct scmi_device_id scmi_id_table[] = {
 	{ SCMI_PROTOCOL_PINCTRL, "pinctrl" },
+	{ SCMI_PROTOCOL_PINCTRL, "pinctrl-scmi-imx", "fsl,imx95-scmi-pinctrl" },
 	{ }
 };
 MODULE_DEVICE_TABLE(scmi, scmi_id_table);
@@ -361,6 +374,9 @@ static int scmi_pinctrl_probe(struct scmi_device *sdev)
 	pmx->pctl_desc.pmxops = &pinctrl_scmi_pinmux_ops;
 	pmx->pctl_desc.confops = &pinctrl_scmi_pinconf_ops;
 
+	if (device_is_compatible(dev, "fsl,imx95-scmi-pinctrl"))
+		pmx->pctl_desc.pctlops = &pinctrl_scmi_imx_pinctrl_ops;
+
 	ret = pinctrl_scmi_get_pins(pmx, &pmx->pctl_desc.npins,
 				    &pmx->pctl_desc.pins);
 	if (ret)
diff --git a/drivers/pinctrl/pinctrl-scmi.h b/drivers/pinctrl/pinctrl-scmi.h
new file mode 100644
index 000000000000..25863b4428fe
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-scmi.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2023 NXP
+ */
+
+#ifndef __DRIVERS_PINCTRL_SCMI_H
+#define __DRIVERS_PINCTRL_SCMI_H
+
+int pinctrl_scmi_imx_dt_node_to_map(struct pinctrl_dev *pctldev, struct device_node *np,
+				    struct pinctrl_map **map, unsigned int *num_maps);
+
+#endif /* __DRIVERS_PINCTRL_SCMI_H */

-- 
2.37.1



From u.kleine-koenig at pengutronix.de  Fri Dec 15 04:08:17 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 13:08:17 +0100
Subject: [PATCH v7 05/11] arm64: perf: Include threshold control fields
 in PMEVTYPER mask
In-Reply-To: <20231211161331.1277825-6-james.clark@arm.com>
References: <20231211161331.1277825-1-james.clark@arm.com>
 <20231211161331.1277825-6-james.clark@arm.com>
Message-ID: <20231215120817.h2f3akgv72zhrtqo@pengutronix.de>

Hello,

On Mon, Dec 11, 2023 at 04:13:17PM +0000, James Clark wrote:
> FEAT_PMUv3_TH (Armv8.8) adds two new fields to PMEVTYPER, so include
> them in the mask. These aren't writable on 32 bit kernels as they are in
> the high part of the register, so only include them for arm64.
> 
> It would be difficult to do this statically in the asm header files for
> each platform without resulting in circular includes or #ifdefs inline
> in the code. For that reason the ARMV8_PMU_EVTYPE_MASK definition has
> been removed and the mask is constructed programmatically.
> 
> Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
> Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>
> Signed-off-by: James Clark <james.clark at arm.com>

This change is in today's next as commit
3115ee021bfb04efde2e96507bfcc1330261a6a1. this breaks allmodconfig
building on ARCH=arm:

	In file included from include/linux/ratelimit_types.h:5,
			 from include/linux/printk.h:9,
			 from include/asm-generic/bug.h:22,
			 from arch/arm/include/asm/bug.h:60,
			 from include/linux/bug.h:5,
			 from include/linux/mmdebug.h:5,
			 from include/linux/percpu.h:5,
			 from include/asm-generic/irq_regs.h:11,
			 from ./arch/arm/include/generated/asm/irq_regs.h:1,
			 from drivers/perf/arm_pmuv3.c:11:
	drivers/perf/arm_pmuv3.c: In function ?armv8pmu_write_evtype?:
	include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
	   34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \
	      |                             ^~
	include/linux/bits.h:37:38: note: in expansion of macro ?__GENMASK?
	   37 |         (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
	      |                                      ^~~~~~~~~
	include/linux/perf/arm_pmuv3.h:238:33: note: in expansion of macro ?GENMASK?
	  238 | #define ARMV8_PMU_EVTYPE_TC     GENMASK(63, 61)
	      |                                 ^~~~~~~
	drivers/perf/arm_pmuv3.c:567:25: note: in expansion of macro ?ARMV8_PMU_EVTYPE_TC?
	  567 |                 mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
	      |                         ^~~~~~~~~~~~~~~~~~~
	include/linux/bits.h:35:18: error: right shift count is negative [-Werror=shift-count-negative]
	   35 |          (~UL(0) >> (BITS_PER_LONG - 1 - (h))))
	      |                  ^~
	include/linux/bits.h:37:38: note: in expansion of macro ?__GENMASK?
	   37 |         (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
	      |                                      ^~~~~~~~~
	include/linux/perf/arm_pmuv3.h:238:33: note: in expansion of macro ?GENMASK?
	  238 | #define ARMV8_PMU_EVTYPE_TC     GENMASK(63, 61)
	      |                                 ^~~~~~~
	drivers/perf/arm_pmuv3.c:567:25: note: in expansion of macro ?ARMV8_PMU_EVTYPE_TC?
	  567 |                 mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
	      |                         ^~~~~~~~~~~~~~~~~~~
	include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
	   34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \
	      |                             ^~
	include/linux/bits.h:37:38: note: in expansion of macro ?__GENMASK?
	   37 |         (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
	      |                                      ^~~~~~~~~
	include/linux/perf/arm_pmuv3.h:237:33: note: in expansion of macro ?GENMASK?
	  237 | #define ARMV8_PMU_EVTYPE_TH     GENMASK(43, 32)
	      |                                 ^~~~~~~
	drivers/perf/arm_pmuv3.c:567:47: note: in expansion of macro ?ARMV8_PMU_EVTYPE_TH?
	  567 |                 mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
	      |                                               ^~~~~~~~~~~~~~~~~~~
	include/linux/bits.h:35:18: error: right shift count is negative [-Werror=shift-count-negative]
	   35 |          (~UL(0) >> (BITS_PER_LONG - 1 - (h))))
	      |                  ^~
	include/linux/bits.h:37:38: note: in expansion of macro ?__GENMASK?
	   37 |         (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
	      |                                      ^~~~~~~~~
	include/linux/perf/arm_pmuv3.h:237:33: note: in expansion of macro ?GENMASK?
	  237 | #define ARMV8_PMU_EVTYPE_TH     GENMASK(43, 32)
	      |                                 ^~~~~~~
	drivers/perf/arm_pmuv3.c:567:47: note: in expansion of macro ?ARMV8_PMU_EVTYPE_TH?
	  567 |                 mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
	      |                                               ^~~~~~~~~~~~~~~~~~~

I guess that's easy to fix but I didn't look into that.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/60fb475c/attachment.sig>

From linus.walleij at linaro.org  Fri Dec 15 04:10:24 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 15 Dec 2023 13:10:24 +0100
Subject: [PATCH 1/2] spi: pl022: delete description of cur_msg
In-Reply-To: <f06a9b6eac184cc648ae7444c480add6da87a84d.1702639801.git.namcao@linutronix.de>
References: <202312151816.munFeE4L-lkp@intel.com/> <f06a9b6eac184cc648ae7444c480add6da87a84d.1702639801.git.namcao@linutronix.de>
Message-ID: <CACRpkdYtzmMrUAKcLfA=i5qmsddxw6afH9zKtiMS95EtatMsAw@mail.gmail.com>

On Fri, Dec 15, 2023 at 12:33?PM Nam Cao <namcao at linutronix.de> wrote:

> The variable cur_msg was removed, but its description is left behind.
> Delete this description.
>
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312151816.munFeE4L-lkp at intel.com/
> Signed-off-by: Nam Cao <namcao at linutronix.de>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Fri Dec 15 04:11:03 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 15 Dec 2023 13:11:03 +0100
Subject: [PATCH 2/2] spi: pl022: update description of internal_cs_control()
In-Reply-To: <4036d8d5845c04179f330f83e825a3921aa50c5a.1702639801.git.namcao@linutronix.de>
References: <f06a9b6eac184cc648ae7444c480add6da87a84d.1702639801.git.namcao@linutronix.de>
 <4036d8d5845c04179f330f83e825a3921aa50c5a.1702639801.git.namcao@linutronix.de>
Message-ID: <CACRpkdZ2a2cHtNMuShjTvpvPQs6k7YmOE6QeB6ubEu0oGxuvLw@mail.gmail.com>

On Fri, Dec 15, 2023 at 12:33?PM Nam Cao <namcao at linutronix.de> wrote:

> The arguments of internal_cs_control() was changed, but its description
> was not updated. Update the description to match the expected arguments.
>
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312151816.munFeE4L-lkp at intel.com/
> Signed-off-by: Nam Cao <namcao at linutronix.de>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From alain.volmat at foss.st.com  Fri Dec 15 04:12:31 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 13:12:31 +0100
Subject: [PATCH v2 4/7] i2c: stm32f7: add support for stm32mp25 soc
In-Reply-To: <20231209000747.4l6462nlzj3po3sf@zenone.zhora.eu>
References: <20231208164719.3584028-1-alain.volmat@foss.st.com>
 <20231208164719.3584028-5-alain.volmat@foss.st.com>
 <20231209000747.4l6462nlzj3po3sf@zenone.zhora.eu>
Message-ID: <20231215121231.GA3866676@gnbcxd0016.gnb.st.com>

Hi Andi,

thanks for your review.

I'll shortly post a v3 to correct all your comments.

On Sat, Dec 09, 2023 at 01:07:47AM +0100, Andi Shyti wrote:
> Hi Alain,
> 
> On Fri, Dec 08, 2023 at 05:47:13PM +0100, Alain Volmat wrote:
> > The stm32mp25 has only a single interrupt line used for both
> > events and errors. In order to cope with that, reorganise the
> > error handling code so that it can be called either from the
> > common handler (used in case of SoC having only a single IT line)
> > and the error handler for others.
> > The CR1 register also embeds a new FMP bit, necessary when running
> > at Fast Mode Plus frequency. This bit should be used instead of
> > the SYSCFG bit used on other platforms.
> > Add a new compatible to distinguish between the SoCs and two
> > boolean within the setup structure in order to know if the
> > platform has a single/multiple IT lines and if the FMP bit
> > within CR1 is available or not.
> > 
> > Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
> > Signed-off-by: Valentin Caron <valentin.caron at foss.st.com>
> 
> your SoB here should come last because you are the one sending
> the patch.

Fixed.

> 
> > ---
> >  drivers/i2c/busses/i2c-stm32f7.c | 230 ++++++++++++++++++-------------
> >  1 file changed, 133 insertions(+), 97 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
> > index 2a011deec3c5..5634332900fb 100644
> > --- a/drivers/i2c/busses/i2c-stm32f7.c
> > +++ b/drivers/i2c/busses/i2c-stm32f7.c
> > @@ -50,6 +50,7 @@
> >  #define STM32F7_I2C_TXDR			0x28
> >  
> >  /* STM32F7 I2C control 1 */
> > +#define STM32_I2C_CR1_FMP			BIT(24)
> >  #define STM32F7_I2C_CR1_PECEN			BIT(23)
> >  #define STM32F7_I2C_CR1_ALERTEN			BIT(22)
> >  #define STM32F7_I2C_CR1_SMBHEN			BIT(20)
> > @@ -226,6 +227,8 @@ struct stm32f7_i2c_spec {
> >   * @rise_time: Rise time (ns)
> >   * @fall_time: Fall time (ns)
> >   * @fmp_clr_offset: Fast Mode Plus clear register offset from set register
> > + * @single_it_line: Only a single IT line is used for both events/errors
> > + * @fmp_cr1_bit: Fast Mode Plus control is done via a bit in CR1
> 
> Is the Fast Mode Plus an optional feature?

Yes, from what I've seen, it seems an optional feature on some versions
of stm32f7.

> 
> >   */
> >  struct stm32f7_i2c_setup {
> >  	u32 speed_freq;
> > @@ -233,6 +236,8 @@ struct stm32f7_i2c_setup {
> >  	u32 rise_time;
> >  	u32 fall_time;
> >  	u32 fmp_clr_offset;
> > +	bool single_it_line;
> > +	bool fmp_cr1_bit;
> >  };
> 
> [...]
> 
> > -static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev)
> > +static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev, u32 status)
> >  {
> >  	void __iomem *base = i2c_dev->base;
> > -	u32 cr2, status, mask;
> > +	u32 cr2, mask;
> >  	u8 val;
> >  	int ret;
> >  
> > -	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
> > -
> 
> good to see this change here, relates to my comment in patch 1.
> But I think this should go on a different patch.

Agreed. I've split this small change into a dedicated commit done before
this patch.

> 
> >  	/* Slave transmitter mode */
> >  	if (status & STM32F7_I2C_ISR_TXIS) {
> >  		i2c_slave_event(i2c_dev->slave_running,
> > @@ -1494,17 +1504,81 @@ static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev)
> >  	return IRQ_HANDLED;
> >  }
> 
> [...]
> 
> > -	setup = of_device_get_match_data(&pdev->dev);
> > -	if (!setup) {
> > -		dev_err(&pdev->dev, "Can't get device data\n");
> > -		return -ENODEV;
> > +		ret = devm_request_threaded_irq(&pdev->dev, irq_error,
> > +						NULL,
> > +						stm32f7_i2c_isr_error_thread,
> > +						IRQF_ONESHOT,
> > +						pdev->name, i2c_dev);
> > +		if (ret) {
> > +			dev_err(&pdev->dev, "Failed to request irq error %i\n",
> > +				irq_error);
> 
> please use dev_err_probe();

Done as well in a dedicated commit at the very beginning of the serie.

> 
> > +			return ret;
> > +		}
> 
> out of the scope of the patch and just for curiosity: does the
> driver work without being able to signal on the error interrupt
> line?

Sorry, not sure to understand the question.  Just for clarification,
on the MP25 not having a dedicated error line doesn't mean we are not
signaled for errors.  It is simply they just come via the same
interrupt line, hence we need to check for both event and error
within the same handler.
On systems using two interrupts line, the error interrupt irq line
should be handled in order to tackle those errors cases.
Sorry, does this answer your question ?

> 
> Overall the patch looks good to me, though.
> 
> Andi


From festevam at gmail.com  Fri Dec 15 04:14:33 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 15 Dec 2023 09:14:33 -0300
Subject: [PATCH] ARM: dts: imx25: Remove unneeded keypad properties
Message-ID: <20231215121433.176121-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Per imx-keypad.yaml, '#address-cells', '#size-cells', 'clock-names'
are not valid properties.

Remove them to fix the following dt-schema warning:

imx25-pdk.dtb: kpp at 43fa8000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'clock-names' were unexpected)
	from schema $id: http://devicetree.org/schemas/input/imx-keypad.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx25.dtsi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx25.dtsi b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
index db814d7b568d..9cfff2151b7e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
@@ -188,12 +188,9 @@ spi1: spi at 43fa4000 {
 			};
 
 			kpp: kpp at 43fa8000 {
-				#address-cells = <1>;
-				#size-cells = <0>;
 				compatible = "fsl,imx25-kpp", "fsl,imx21-kpp";
 				reg = <0x43fa8000 0x4000>;
 				clocks = <&clks 102>;
-				clock-names = "";
 				interrupts = <24>;
 				status = "disabled";
 			};
-- 
2.34.1



From festevam at gmail.com  Fri Dec 15 04:18:45 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 15 Dec 2023 09:18:45 -0300
Subject: [PATCH] ARM: dts: imx27-phytec-phycore-som: Use 'rtc' as node name
Message-ID: <20231215121845.177096-1-festevam@gmail.com>

From: Fabio Estevam <festevam at denx.de>

Node names should be generic.

Use 'rtc' for the rtc node to fix the following dt-schema warning:

imx27-phytec-phycore-rdk.dtb: pcf8563 at 51: $nodename:0: 'pcf8563 at 51' does not match '^rtc(@.*|-([0-9]|[1-9][0-9]+))?$'
	from schema $id: http://devicetree.org/schemas/rtc/nxp,pcf8563.yaml#

Signed-off-by: Fabio Estevam <festevam at denx.de>
---
 arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
index 0e527d1f9e55..e958d7286ae9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi
@@ -180,7 +180,7 @@ eeprom at 52 {
 		reg = <0x52>;
 	};
 
-	pcf8563 at 51 {
+	rtc at 51 {
 		compatible = "nxp,pcf8563";
 		reg = <0x51>;
 	};
-- 
2.34.1



From quic_bibekkum at quicinc.com  Fri Dec 15 04:20:52 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Fri, 15 Dec 2023 17:50:52 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
Message-ID: <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>



On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
> <quic_bibekkum at quicinc.com> wrote:
>>
>> Add ACTLR data table for SM8550 along with support for
>> same including SM8550 specific implementation operations.
>>
>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>> ---
>>   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 ++++++++++++++++++++++
>>   1 file changed, 89 insertions(+)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> index cb49291f5233..d2006f610243 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> @@ -20,6 +20,85 @@ struct actlr_config {
>>          u32 actlr;
>>   };
>>
>> +/*
>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the prefetch
>> + * buffer). The remaining bits are implementation defined and vary across
>> + * SoCs.
>> + */
>> +
>> +#define PREFETCH_DEFAULT       0
>> +#define PREFETCH_SHALLOW       BIT(8)
>> +#define PREFETCH_MODERATE      BIT(9)
>> +#define PREFETCH_DEEP          (BIT(9) | BIT(8))
> 
> I thin the following might be more correct:
> 
> #include <linux/bitfield.h>
> 
> #define PREFETCH_MASK GENMASK(9, 8)
> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
> 

Ack, thanks for this suggestion. Let me try this out using
GENMASK. Once tested, will take care of this in next version.

Thanks,
Bibek

>> +#define PREFETCH_SWITCH_GFX    (BIT(5) | BIT(3))
>> +#define CPRE                   BIT(1)
>> +#define CMTLB                  BIT(0)
>> +
>> +static const struct actlr_config sm8550_apps_actlr_cfg[] = {
>> +       { 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x0800, 0x0020, PREFETCH_DEFAULT | CMTLB },
>> +       { 0x1800, 0x00c0, PREFETCH_DEFAULT | CMTLB },
>> +       { 0x1820, 0x0000, PREFETCH_DEFAULT | CMTLB },
>> +       { 0x1860, 0x0000, PREFETCH_DEFAULT | CMTLB },
>> +       { 0x0c01, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c02, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c03, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c04, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c05, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c06, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c07, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c08, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c09, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c0c, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c0d, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c0e, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x0c0f, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1961, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1962, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1963, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1964, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1965, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1966, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1967, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1968, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1969, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x196c, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x196d, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x196e, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x196f, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19c1, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19c2, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19c3, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19c4, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19c5, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19c6, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19c7, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19c8, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19c9, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19cc, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19cd, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19ce, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x19cf, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>> +       { 0x1c00, 0x0002, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x1c01, 0x0000, PREFETCH_DEFAULT | CMTLB },
>> +       { 0x1920, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x1923, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x1924, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x1940, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x1941, 0x0004, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x1943, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x1944, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> +       {},
>> +};
>> +
>> +static const struct actlr_config sm8550_gfx_actlr_cfg[] = {
>> +       { 0x0000, 0x03ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE | CMTLB },
>> +       {},
>> +};
>> +
>>   static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
>>   {
>>          return container_of(smmu, struct qcom_smmu, smmu);
>> @@ -549,6 +628,15 @@ static const struct qcom_smmu_match_data sdm845_smmu_500_data = {
>>          /* Also no debug configuration. */
>>   };
>>
>> +
>> +static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
>> +       .impl = &qcom_smmu_500_impl,
>> +       .adreno_impl = &qcom_adreno_smmu_500_impl,
>> +       .cfg = &qcom_smmu_impl0_cfg,
>> +       .actlrcfg = sm8550_apps_actlr_cfg,
>> +       .actlrcfg_gfx = sm8550_gfx_actlr_cfg,
>> +};
>> +
>>   static const struct qcom_smmu_match_data qcom_smmu_500_impl0_data = {
>>          .impl = &qcom_smmu_500_impl,
>>          .adreno_impl = &qcom_adreno_smmu_500_impl,
>> @@ -583,6 +671,7 @@ static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
>>          { .compatible = "qcom,sm8250-smmu-500", .data = &qcom_smmu_500_impl0_data },
>>          { .compatible = "qcom,sm8350-smmu-500", .data = &qcom_smmu_500_impl0_data },
>>          { .compatible = "qcom,sm8450-smmu-500", .data = &qcom_smmu_500_impl0_data },
>> +       { .compatible = "qcom,sm8550-smmu-500", .data = &sm8550_smmu_500_impl0_data },
>>          { .compatible = "qcom,smmu-500", .data = &qcom_smmu_500_impl0_data },
>>          { }
>>   };
>> --
>> 2.17.1
>>
> 
> 


From mripard at kernel.org  Fri Dec 15 04:27:56 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Fri, 15 Dec 2023 13:27:56 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <a8f13e19-7bb3-4a7f-a264-1e1ede1864e0@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <20231213195125.212923-5-knaerzche@gmail.com>
 <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
 <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com>
 <db3kdzy4ogf3o2fd6apr36s44qitcsxksfkfa2oc77s5y6dv2w@kfji4iszthxa>
 <a8f13e19-7bb3-4a7f-a264-1e1ede1864e0@gmail.com>
Message-ID: <76qlgx4astzjjt37eg6ee3ijslm6hvilcgs5yujhqdr7itp4hw@ugtglocx7lq6>

On Thu, Dec 14, 2023 at 03:05:59PM +0100, Alex Bee wrote:
> 
> Am 14.12.23 um 12:33 schrieb Maxime Ripard:
> > On Thu, Dec 14, 2023 at 12:12:08PM +0100, Alex Bee wrote:
> > > Hi Maxime
> > > 
> > > Am 14.12.23 um 08:56 schrieb Maxime Ripard:
> > > > Hi Alex,
> > > > 
> > > > Thanks for working on this!
> > > > 
> > > > On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
> > > > > The display controller will always give full range RGB regardless of the
> > > > > mode set, but HDMI requires certain modes to be transmitted in limited
> > > > > range RGB. This is especially required for HDMI sinks which do not support
> > > > > non-standard quantization ranges.
> > > > > 
> > > > > This enables color space conversion for those modes and sets the
> > > > > quantization range accordingly in the AVI infoframe.
> > > > > 
> > > > > Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> > > > > Signed-off-by: Alex Bee <knaerzche at gmail.com>
> > > > > ---
> > > > >    drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
> > > > >    1 file changed, 32 insertions(+), 8 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > > > index 345253e033c5..32626a75723c 100644
> > > > > --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > > > +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > > > @@ -33,6 +33,7 @@ struct hdmi_data_info {
> > > > >    	unsigned int enc_in_format;
> > > > >    	unsigned int enc_out_format;
> > > > >    	unsigned int colorimetry;
> > > > > +	bool rgb_limited_range;
> > > > >    };
> > > > >    struct inno_hdmi_i2c {
> > > > > @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
> > > > >    	else
> > > > >    		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> > > > > +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
> > > > > +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> > > > > +						   &hdmi->connector, mode,
> > > > > +						   hdmi->hdmi_data.rgb_limited_range ?
> > > > > +						   HDMI_QUANTIZATION_RANGE_LIMITED :
> > > > > +						   HDMI_QUANTIZATION_RANGE_FULL);
> > > > > +	} else {
> > > > > +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> > > > > +		frame.avi.ycc_quantization_range =
> > > > > +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> > > > > +	}
> > > > > +
> > > > >    	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
> > > > >    }
> > > > > @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
> > > > >    	if (data->enc_in_format == data->enc_out_format) {
> > > > >    		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
> > > > >    		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
> > > > > -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> > > > > -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> > > > > -
> > > > > -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> > > > > -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> > > > > -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> > > > > -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> > > > > -			return 0;
> > > > > +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
> > > > > +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
> > > > > +			    hdmi->hdmi_data.rgb_limited_range) {
> > > > > +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
> > > > > +				auto_csc = AUTO_CSC_DISABLE;
> > > > > +				c0_c2_change = C0_C2_CHANGE_DISABLE;
> > > > > +				csc_enable = v_CSC_ENABLE;
> > > > > +			} else {
> > > > > +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> > > > > +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> > > > > +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> > > > > +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> > > > > +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> > > > > +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> > > > > +				return 0;
> > > > > +			}
> > > > >    		}
> > > > >    	}
> > > > > @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
> > > > >    	else
> > > > >    		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
> > > > > +	hdmi->hdmi_data.rgb_limited_range =
> > > > > +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
> > > > > +
> > > > This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
> > > > https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/
> > > I'm aware of that and I mentioned it in the cover letter.
> > Sorry, I missed that part.
> > 
> > > Your series is not merged yet and it didn't get much feedback so far.
> > > What is the status there?
> > It didn't have much reviews, but I'll hope to change that. For the
> > patches 22 to 38 though, it doesn't really matter. Those changes are
> > self-contained and can be applied as is outside of the series.
> > 
> > > Especially because you are removing things from inno-hdmi driver (which
> > > aren't really required to remove there) which will I have to reintroduce.
> > I'm not entirely sure which part I remove that are actually going to be
> > used here.
>
> I'm refering to [PATCH v5 33/44] which completly removes csc coeffs but this
> series needs the CSC_RGB_0_255_TO_RGB_16_235_8BIT? coeffs and? [PATCH v5
> 29/44] which removes writing csc_coeffs to the hardware.

Oh, right, feel free to drop those

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/385982a6/attachment-0001.sig>

From stefan.nagy at ixypsilon.net  Fri Dec 15 04:28:48 2023
From: stefan.nagy at ixypsilon.net (Stefan Nagy)
Date: Fri, 15 Dec 2023 13:28:48 +0100
Subject: [PATCH] arm64: dts: rockchip: Increase maximum frequency of SPI flash for ROCK Pi 4A/B/C
Message-ID: <20231215122848.59534-1-stefan.nagy@ixypsilon.net>

The ROCK Pi 4A/B/C boards come with a 32 Mbit SPI NOR flash chip (XTX Technology Limited XT25F32) which has a maximum clock frequency of 108 MHz. However, the Rockchip SPI controller driver limits the maximum SPI clock frequency to 50 MHz. Use this limit for spi-max-freq.

This patch has been tested on ROCK Pi 4A.

Signed-off-by: Stefan Nagy <stefan.nagy at ixypsilon.net>
---
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts | 2 +-
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts | 2 +-
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
index d5df8939a..30e63e62a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
@@ -19,6 +19,6 @@ &spi1 {
 	flash at 0 {
 		compatible = "jedec,spi-nor";
 		reg = <0>;
-		spi-max-frequency = <10000000>;
+		spi-max-frequency = <50000000>;
 	};
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
index bee6d7588..7122bf6c0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
@@ -37,7 +37,7 @@ &spi1 {
 	flash at 0 {
 		compatible = "jedec,spi-nor";
 		reg = <0>;
-		spi-max-frequency = <10000000>;
+		spi-max-frequency = <50000000>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
index de2ebe4cb..8af75bc7c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
@@ -49,7 +49,7 @@ &spi1 {
 	flash at 0 {
 		compatible = "jedec,spi-nor";
 		reg = <0>;
-		spi-max-frequency = <10000000>;
+		spi-max-frequency = <50000000>;
 	};
 };
 
-- 
2.30.2



From mripard at kernel.org  Fri Dec 15 04:29:00 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Fri, 15 Dec 2023 13:29:00 +0100
Subject: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <3f970571-f454-4615-8234-64ea68a3d63c@gmail.com>
References: <20231213195125.212923-1-knaerzche@gmail.com>
 <w7cj24se5gjomfynp5yindnh3s2pea4p3f46u6y7lcci7hri32@62i6hg26pheb>
 <5f4fc919-681f-44ec-bd44-5788e5b718ca@gmail.com>
 <3053311.k3LOHGUjKi@diego>
 <qr7if2k76wdqgevdcwqxj2dkcbga72owjqlk3qaazujhejjloo@cnvmuq27qqns>
 <3f970571-f454-4615-8234-64ea68a3d63c@gmail.com>
Message-ID: <33rkqgeqduzvxr24dlc4qqvhwh4fscia5v2g5kzkt3hrwdfzei@cz772d33txmh>

On Thu, Dec 14, 2023 at 05:34:59PM +0100, Alex Bee wrote:
> Hi Heiko, Hi Maxime,
> 
> Am 14.12.23 um 12:36 schrieb Maxime Ripard:
> > On Thu, Dec 14, 2023 at 12:17:34PM +0100, Heiko St?bner wrote:
> > > Am Donnerstag, 14. Dezember 2023, 12:12:08 CET schrieb Alex Bee:
> > > > Hi Maxime
> > > > 
> > > > Am 14.12.23 um 08:56 schrieb Maxime Ripard:
> > > > > Hi Alex,
> > > > > 
> > > > > Thanks for working on this!
> > > > > 
> > > > > On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
> > > > > > The display controller will always give full range RGB regardless of the
> > > > > > mode set, but HDMI requires certain modes to be transmitted in limited
> > > > > > range RGB. This is especially required for HDMI sinks which do not support
> > > > > > non-standard quantization ranges.
> > > > > > 
> > > > > > This enables color space conversion for those modes and sets the
> > > > > > quantization range accordingly in the AVI infoframe.
> > > > > > 
> > > > > > Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> > > > > > Signed-off-by: Alex Bee <knaerzche at gmail.com>
> > > > > > ---
> > > > > >    drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
> > > > > >    1 file changed, 32 insertions(+), 8 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > > > > index 345253e033c5..32626a75723c 100644
> > > > > > --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > > > > +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> > > > > > @@ -33,6 +33,7 @@ struct hdmi_data_info {
> > > > > >    	unsigned int enc_in_format;
> > > > > >    	unsigned int enc_out_format;
> > > > > >    	unsigned int colorimetry;
> > > > > > +	bool rgb_limited_range;
> > > > > >    };
> > > > > >    struct inno_hdmi_i2c {
> > > > > > @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
> > > > > >    	else
> > > > > >    		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> > > > > > +	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
> > > > > > +		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> > > > > > +						   &hdmi->connector, mode,
> > > > > > +						   hdmi->hdmi_data.rgb_limited_range ?
> > > > > > +						   HDMI_QUANTIZATION_RANGE_LIMITED :
> > > > > > +						   HDMI_QUANTIZATION_RANGE_FULL);
> > > > > > +	} else {
> > > > > > +		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> > > > > > +		frame.avi.ycc_quantization_range =
> > > > > > +			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> > > > > > +	}
> > > > > > +
> > > > > >    	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
> > > > > >    }
> > > > > > @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
> > > > > >    	if (data->enc_in_format == data->enc_out_format) {
> > > > > >    		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
> > > > > >    		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
> > > > > > -			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> > > > > > -			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> > > > > > -
> > > > > > -			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> > > > > > -				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> > > > > > -				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> > > > > > -				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> > > > > > -			return 0;
> > > > > > +			if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
> > > > > > +			    data->enc_out_format == HDMI_COLORSPACE_RGB &&
> > > > > > +			    hdmi->hdmi_data.rgb_limited_range) {
> > > > > > +				csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
> > > > > > +				auto_csc = AUTO_CSC_DISABLE;
> > > > > > +				c0_c2_change = C0_C2_CHANGE_DISABLE;
> > > > > > +				csc_enable = v_CSC_ENABLE;
> > > > > > +			} else {
> > > > > > +				value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> > > > > > +				hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> > > > > > +				hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> > > > > > +					  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> > > > > > +					  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> > > > > > +					  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> > > > > > +				return 0;
> > > > > > +			}
> > > > > >    		}
> > > > > >    	}
> > > > > > @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
> > > > > >    	else
> > > > > >    		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
> > > > > > +	hdmi->hdmi_data.rgb_limited_range =
> > > > > > +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
> > > > > > +
> > > > > This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
> > > > > https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org/
> > > > I'm aware of that and I mentioned it in the cover letter. Your series is
> > > > not merged yet and it didn't get much feedback so far. What is the
> > > > status there? Especially because you are removing things from inno-hdmi
> > > > driver (which aren't really required to remove there) which will I have
> > > > to reintroduce.
> > > Sadly I haven't found the time to look closer at Maxime's series so far,
> > > but I got the impression that it separates into multiple cleanup steps
> > > for a number of controllers.
> > Yeah, one of the previous version comment was to support more
> > controllers than vc4, which is fair. So I ended up reworking and
> > converting multiple controllers, but most of the clean up changes can be
> > applied outside of that series just fine.
> > 
> > I just didn't find someone to test / review them yet :)
> 
> I'm not exactly sure how to proceed here. Do you want me to:
> 
> - base my patches on top of Maxime's series and reintroduce csc things (of
> course only those which touch inno-hdmi w/o the framwork changes)
> 
> - only apply the patches that do not touch csc things and base my series? on
> top of that
> 
> - adapt Maxime's patches so that RGB full to RGB limited stays in there
> 
> - wait with resend until Maxime's series is merged and reintroduce csc after
> that
> 
> - something else
> 
> ?

2 or 3, at your discretion

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/ea2b5c2b/attachment.sig>

From mripard at kernel.org  Fri Dec 15 04:34:26 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Fri, 15 Dec 2023 13:34:26 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <20231213155252.eq6cdzk2vuwllzdu@pengutronix.de>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
 <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
 <20231213110829.bjaxjjiyy4ug7o67@pengutronix.de>
 <6wnsxbi27xdxjtaqaaaq5wtwwilp4jfw4mg5y2ctdl7xrs44ry@ns6y36pf7hge>
 <20231213155252.eq6cdzk2vuwllzdu@pengutronix.de>
Message-ID: <nsa54fwu4ewmcaehesuqefoo5r7z3tuvj76hjb4ngtkaygxwxx@h73ihjon5gby>

On Wed, Dec 13, 2023 at 04:52:52PM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Dec 13, 2023 at 12:54:14PM +0100, Maxime Ripard wrote:
> > On Wed, Dec 13, 2023 at 12:08:29PM +0100, Uwe Kleine-K?nig wrote:
> > > On Wed, Dec 13, 2023 at 09:36:49AM +0100, Maxime Ripard wrote:
> > > > On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
> > > > > On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > > > > > On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> > > > > > > clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> > > > > > > that and don't check the return value. This series fixes the four users
> > > > > > > that do error checking on the returned value and then makes function
> > > > > > > return void.
> > > > > > > 
> > > > > > > Given that the changes to the drivers are simple and so merge conflicts
> > > > > > > (if any) should be easy to handle, I suggest to merge this complete
> > > > > > > series via the clk tree.
> > > > > > 
> > > > > > I don't think it's the right way to go about it.
> > > > > > 
> > > > > > clk_rate_exclusive_get() should be expected to fail. For example if
> > > > > > there's another user getting an exclusive rate on the same clock.
> > > > > > 
> > > > > > If we're not checking for it right now, then it should probably be
> > > > > > fixed, but the callers checking for the error are right to do so if they
> > > > > > rely on an exclusive rate. It's the ones that don't that should be
> > > > > > modified.
> > > > > 
> > > > > If some other consumer has already "locked" a clock that I call
> > > > > clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
> > > > > this function because I don't want the rate to change e.g. because I
> > > > > setup some registers in the consuming device to provide a fixed UART
> > > > > baud rate or i2c bus frequency (and that works as expected).
> > > > 
> > > > [a long text of mostly right things (Uwe's interpretation) that are
> > > > however totally unrelated to the patches under discussion.]
> > 
> > I'm glad you consider it "mostly" right.
> 
> there was no offense intended. I didn't agree to all points, but didn't
> think it was helpful to discuss that given that I considered them
> orthogonal to my suggested modifications.
>  
> > > The clk API works with and without my patches in exactly the same way.
> > > It just makes more explicit that clk_rate_exclusive_get() cannot fail
> > > today and removes the error handling from consumers that is never used.
> > 
> > Not really, no.
> 
> What exactly do you oppose here? Both of my sentences are correct?!

That the API works in the exact same way.

> > An API is an interface, meant to provide an abstraction. The only
> > relevant thing is whether or not that function, from an abstract point
> > of view, can fail.
> 
> What is the ideal API that you imagine? For me the ideal API is:
> 
> A consumer might call clk_rate_exclusive_get() and after that returns
> all other consumers are prohibited to change the rate of the clock
> (directly and indirectly) until clk_rate_exclusive_put() is called. If
> this ends in a double lock (i.e. two different consumers locked the
> clock), then I cannot change the rate (and neither can anybody else).
> 
> That is fine iff I don't need to change the rate and just want to rely
> on it to keep its current value (which is a valid use case). And if I
> want to change the rate but another consumer prevents that, I handle
> that in the same away as I handle all other failures to set the rate to
> the value I need. I have to prepare for that anyhow even if I have
> ensured that I'm the only one having exclusivity on that clock.
> 
> Letting clk_rate_exclusive_get() fail in the assumption that the
> consumer also wants to modify the rate is wrong. The obvious point where
> to stop such consumers is when they call clk_rate_set(). And those who
> don't modify the rate then continue without interruption even if there
> are two lockers.
> 
> This can easily be implemented without clk_rate_exclusive_get() ever
> failing.
> 
> > Can you fail to get the exclusivity? Yes. On a theoretical basis, you
> > can, and the function was explicitly documented as such.
> 
> Sure, you could modify the clk internals such that
> clk_rate_exclusive_get() needs to allocate memory. Or that it fails if
> another consumer already has called it. At least the latter is a change
> in semantics that requires to review (and maybe fix) all users. Also
> note that calling clk_rate_exclusive_get() essentially locks all parent
> clocks up to the root clock. So if clk_rate_exclusive_get() fails in the
> presence of another locker, you can only have one locker per clock
> hierarchy because it's impossible that both grab the lock on the root
> clock.

We're not discussing the same thing. You're talking about from a
technical point of view, I'm talking about it from an abstraction point
of view. Let's use another example: kmalloc cannot fail. Are we going to
remove every possible check for a null pointer in the kernel?

No, of course we won't, because at some point it might and the error
handling will be valuable.

Same story here.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/56ce49fc/attachment.sig>

From gregkh at linuxfoundation.org  Fri Dec 15 04:39:51 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 15 Dec 2023 13:39:51 +0100
Subject: [PATCH v2 2/3] usb: xhci-mtk: fix a short packet issue of gen1
 isoc-in transfer
In-Reply-To: <20231215073431.8512-2-chunfeng.yun@mediatek.com>
References: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
 <20231215073431.8512-2-chunfeng.yun@mediatek.com>
Message-ID: <2023121539-dowry-ambiance-51e3@gregkh>

On Fri, Dec 15, 2023 at 03:34:30PM +0800, Chunfeng Yun wrote:
> For Gen1 isoc-in transfer, host still send out unexpected ACK after device
> finish the burst with a short packet, this will cause an exception on the
> connected device, such as, a usb 4k camera.
> It can be fixed by setting rxfifo depth less than 3, prefer to use 2 here,
> the side-effect is that may cause performance drop about 10%, including
> bulk transfer.
> 
> Fixes: 926d60ae64a6 ("usb: xhci-mtk: modify the SOF/ITP interval for mt8195")
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
> v2:
> use 'rx-fifo-depth' property;
> add header file 'linux/bitfield.h' to avoid building error on some ARCH;
> ---


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documentation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot


From james.clark at arm.com  Fri Dec 15 04:43:44 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 12:43:44 +0000
Subject: [PATCH v7 05/11] arm64: perf: Include threshold control fields in
 PMEVTYPER mask
In-Reply-To: <20231215120817.h2f3akgv72zhrtqo@pengutronix.de>
References: <20231211161331.1277825-1-james.clark@arm.com>
 <20231211161331.1277825-6-james.clark@arm.com>
 <20231215120817.h2f3akgv72zhrtqo@pengutronix.de>
Message-ID: <732aa152-53cc-1101-4292-0906266a4c01@arm.com>



On 15/12/2023 12:08, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Mon, Dec 11, 2023 at 04:13:17PM +0000, James Clark wrote:
>> FEAT_PMUv3_TH (Armv8.8) adds two new fields to PMEVTYPER, so include
>> them in the mask. These aren't writable on 32 bit kernels as they are in
>> the high part of the register, so only include them for arm64.
>>
>> It would be difficult to do this statically in the asm header files for
>> each platform without resulting in circular includes or #ifdefs inline
>> in the code. For that reason the ARMV8_PMU_EVTYPE_MASK definition has
>> been removed and the mask is constructed programmatically.
>>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> Signed-off-by: James Clark <james.clark at arm.com>
> 
> This change is in today's next as commit
> 3115ee021bfb04efde2e96507bfcc1330261a6a1. this breaks allmodconfig
> building on ARCH=arm:
> 
> 	In file included from include/linux/ratelimit_types.h:5,
> 			 from include/linux/printk.h:9,
> 			 from include/asm-generic/bug.h:22,
> 			 from arch/arm/include/asm/bug.h:60,
> 			 from include/linux/bug.h:5,
> 			 from include/linux/mmdebug.h:5,
> 			 from include/linux/percpu.h:5,
> 			 from include/asm-generic/irq_regs.h:11,
> 			 from ./arch/arm/include/generated/asm/irq_regs.h:1,
> 			 from drivers/perf/arm_pmuv3.c:11:
> 	drivers/perf/arm_pmuv3.c: In function ?armv8pmu_write_evtype?:
> 	include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
> 	   34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \
> 	      |                             ^~
> 	include/linux/bits.h:37:38: note: in expansion of macro ?__GENMASK?
> 	   37 |         (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> 	      |                                      ^~~~~~~~~
> 	include/linux/perf/arm_pmuv3.h:238:33: note: in expansion of macro ?GENMASK?
> 	  238 | #define ARMV8_PMU_EVTYPE_TC     GENMASK(63, 61)
> 	      |                                 ^~~~~~~
> 	drivers/perf/arm_pmuv3.c:567:25: note: in expansion of macro ?ARMV8_PMU_EVTYPE_TC?
> 	  567 |                 mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
> 	      |                         ^~~~~~~~~~~~~~~~~~~
> 	include/linux/bits.h:35:18: error: right shift count is negative [-Werror=shift-count-negative]
> 	   35 |          (~UL(0) >> (BITS_PER_LONG - 1 - (h))))
> 	      |                  ^~
> 	include/linux/bits.h:37:38: note: in expansion of macro ?__GENMASK?
> 	   37 |         (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> 	      |                                      ^~~~~~~~~
> 	include/linux/perf/arm_pmuv3.h:238:33: note: in expansion of macro ?GENMASK?
> 	  238 | #define ARMV8_PMU_EVTYPE_TC     GENMASK(63, 61)
> 	      |                                 ^~~~~~~
> 	drivers/perf/arm_pmuv3.c:567:25: note: in expansion of macro ?ARMV8_PMU_EVTYPE_TC?
> 	  567 |                 mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
> 	      |                         ^~~~~~~~~~~~~~~~~~~
> 	include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
> 	   34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \
> 	      |                             ^~
> 	include/linux/bits.h:37:38: note: in expansion of macro ?__GENMASK?
> 	   37 |         (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> 	      |                                      ^~~~~~~~~
> 	include/linux/perf/arm_pmuv3.h:237:33: note: in expansion of macro ?GENMASK?
> 	  237 | #define ARMV8_PMU_EVTYPE_TH     GENMASK(43, 32)
> 	      |                                 ^~~~~~~
> 	drivers/perf/arm_pmuv3.c:567:47: note: in expansion of macro ?ARMV8_PMU_EVTYPE_TH?
> 	  567 |                 mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
> 	      |                                               ^~~~~~~~~~~~~~~~~~~
> 	include/linux/bits.h:35:18: error: right shift count is negative [-Werror=shift-count-negative]
> 	   35 |          (~UL(0) >> (BITS_PER_LONG - 1 - (h))))
> 	      |                  ^~
> 	include/linux/bits.h:37:38: note: in expansion of macro ?__GENMASK?
> 	   37 |         (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> 	      |                                      ^~~~~~~~~
> 	include/linux/perf/arm_pmuv3.h:237:33: note: in expansion of macro ?GENMASK?
> 	  237 | #define ARMV8_PMU_EVTYPE_TH     GENMASK(43, 32)
> 	      |                                 ^~~~~~~
> 	drivers/perf/arm_pmuv3.c:567:47: note: in expansion of macro ?ARMV8_PMU_EVTYPE_TH?
> 	  567 |                 mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
> 	      |                                               ^~~~~~~~~~~~~~~~~~~
> 
> I guess that's easy to fix but I didn't look into that.
> 
> Best regards
> Uwe
> 

Thanks for the report. I see that the build is only broken with GCC and
is working with LLVM. I will look into a fix.

Worst case the if can be changed to an #ifdef

James


From robin.murphy at arm.com  Fri Dec 15 04:54:41 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 15 Dec 2023 12:54:41 +0000
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
Message-ID: <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>

On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
> 
> 
> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>> <quic_bibekkum at quicinc.com> wrote:
>>>
>>> Add ACTLR data table for SM8550 along with support for
>>> same including SM8550 specific implementation operations.
>>>
>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>> ---
>>> ? drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 ++++++++++++++++++++++
>>> ? 1 file changed, 89 insertions(+)
>>>
>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>> index cb49291f5233..d2006f610243 100644
>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>> ???????? u32 actlr;
>>> ? };
>>>
>>> +/*
>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the 
>>> prefetch
>>> + * buffer). The remaining bits are implementation defined and vary 
>>> across
>>> + * SoCs.
>>> + */
>>> +
>>> +#define PREFETCH_DEFAULT?????? 0
>>> +#define PREFETCH_SHALLOW?????? BIT(8)
>>> +#define PREFETCH_MODERATE????? BIT(9)
>>> +#define PREFETCH_DEEP????????? (BIT(9) | BIT(8))
>>
>> I thin the following might be more correct:
>>
>> #include <linux/bitfield.h>
>>
>> #define PREFETCH_MASK GENMASK(9, 8)
>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>
> 
> Ack, thanks for this suggestion. Let me try this out using
> GENMASK. Once tested, will take care of this in next version.

FWIW the more typical usage would be to just define the named macros for 
the raw field values, then put the FIELD_PREP() at the point of use. 
However in this case that's liable to get pretty verbose, so although 
I'm usually a fan of bitfield.h, the most readable option here might 
actually be to stick with simpler definitions of "(0 << 8)", "(1 << 8)", 
etc. However it's not really a big deal either way, and I defer to 
whatever Dmitry and Konrad prefer, since they're the ones looking after 
arm-smmu-qcom the most :)

Thanks,
Robin.

> 
> Thanks,
> Bibek
> 
>>> +#define PREFETCH_SWITCH_GFX??? (BIT(5) | BIT(3))
>>> +#define CPRE?????????????????? BIT(1)
>>> +#define CMTLB????????????????? BIT(0)
>>> +
>>> +static const struct actlr_config sm8550_apps_actlr_cfg[] = {
>>> +?????? { 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x0800, 0x0020, PREFETCH_DEFAULT | CMTLB },
>>> +?????? { 0x1800, 0x00c0, PREFETCH_DEFAULT | CMTLB },
>>> +?????? { 0x1820, 0x0000, PREFETCH_DEFAULT | CMTLB },
>>> +?????? { 0x1860, 0x0000, PREFETCH_DEFAULT | CMTLB },
>>> +?????? { 0x0c01, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c02, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c03, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c04, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c05, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c06, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c07, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c08, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c09, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c0c, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c0d, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c0e, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x0c0f, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1961, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1962, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1963, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1964, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1965, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1966, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1967, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1968, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1969, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x196c, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x196d, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x196e, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x196f, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19c1, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19c2, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19c3, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19c4, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19c5, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19c6, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19c7, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19c8, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19c9, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19cc, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19cd, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19ce, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x19cf, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>> +?????? { 0x1c00, 0x0002, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x1c01, 0x0000, PREFETCH_DEFAULT | CMTLB },
>>> +?????? { 0x1920, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x1923, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x1924, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x1940, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x1941, 0x0004, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x1943, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x1944, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>> +?????? {},
>>> +};
>>> +
>>> +static const struct actlr_config sm8550_gfx_actlr_cfg[] = {
>>> +?????? { 0x0000, 0x03ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE 
>>> | CMTLB },
>>> +?????? {},
>>> +};
>>> +
>>> ? static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
>>> ? {
>>> ???????? return container_of(smmu, struct qcom_smmu, smmu);
>>> @@ -549,6 +628,15 @@ static const struct qcom_smmu_match_data 
>>> sdm845_smmu_500_data = {
>>> ???????? /* Also no debug configuration. */
>>> ? };
>>>
>>> +
>>> +static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
>>> +?????? .impl = &qcom_smmu_500_impl,
>>> +?????? .adreno_impl = &qcom_adreno_smmu_500_impl,
>>> +?????? .cfg = &qcom_smmu_impl0_cfg,
>>> +?????? .actlrcfg = sm8550_apps_actlr_cfg,
>>> +?????? .actlrcfg_gfx = sm8550_gfx_actlr_cfg,
>>> +};
>>> +
>>> ? static const struct qcom_smmu_match_data qcom_smmu_500_impl0_data = {
>>> ???????? .impl = &qcom_smmu_500_impl,
>>> ???????? .adreno_impl = &qcom_adreno_smmu_500_impl,
>>> @@ -583,6 +671,7 @@ static const struct of_device_id __maybe_unused 
>>> qcom_smmu_impl_of_match[] = {
>>> ???????? { .compatible = "qcom,sm8250-smmu-500", .data = 
>>> &qcom_smmu_500_impl0_data },
>>> ???????? { .compatible = "qcom,sm8350-smmu-500", .data = 
>>> &qcom_smmu_500_impl0_data },
>>> ???????? { .compatible = "qcom,sm8450-smmu-500", .data = 
>>> &qcom_smmu_500_impl0_data },
>>> +?????? { .compatible = "qcom,sm8550-smmu-500", .data = 
>>> &sm8550_smmu_500_impl0_data },
>>> ???????? { .compatible = "qcom,smmu-500", .data = 
>>> &qcom_smmu_500_impl0_data },
>>> ???????? { }
>>> ? };
>>> -- 
>>> 2.17.1
>>>
>>
>>


From manikanta.guntupalli at amd.com  Fri Dec 15 04:56:24 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Fri, 15 Dec 2023 18:26:24 +0530
Subject: [PATCH V6 0/3] Add rs485 support to uartps driver
Message-ID: <20231215125627.1691573-1-manikanta.guntupalli@amd.com>

Add reference to rs485.yaml.
Add rs485 support to uartps driver.
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.
Add support for RTS, delay_rts_before_send and delay_rts_after_send in RS485 mode.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.
Move cdns_uart_tx_empty function to avoid prototype statement.
Remove assignment of struct serial_rs485 to port->rs485 as
serial core performs that.
Switch to native RTS in non GPIO case.
Handle rs485 during stop tx.
Remove explicit calls to configure gpio direction and value,
as devm_gpiod_get_optional performs that by using GPIOD_OUT_LOW argument.
Update implementation to support configuration of GPIO/RTS value
based on user configuration of SER_RS485_RTS_ON_SEND and
SER_RS485_RTS_AFTER_SEND. Move implementation to start_tx from handle_tx.

Changes for V4:
Update rts-gpios description.
Create separate patch for cdns_uart_tx_empty relocation.
Call cdns_rs485_rx_setup() before uart_add_one_port() in probe.
Update gpio descriptor name to gpiod_rts.
Instead of cdns_rs485_config_gpio_rts_high() and
cdns_rs485_config_gpio_rts_low() functions for RTS/GPIO value
configuration implement cdns_rts_gpio_enable().
Disable auto rts and call cdns_uart_stop_tx() from cdns_rs485_config.
Use timer instead of mdelay for delay_rts_before_send and delay_rts_after_send.
Update cdns_uart_set_mctrl to support GPIO/RTS.

Changes for V5:
Remove rts-gpios description.
Update commit message and description.

Changes for V6:
Update commit description.
Disable the TX and RX in cdns_rs485_config() when rs485 disabled.
Hold lock for cdns_uart_handle_tx() in cdns_rs485_tx_callback().

Manikanta Guntupalli (3):
  dt-bindings: Add reference to rs485.yaml
  tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485
  tty: serial: uartps: Add rs485 support to uartps driver

 .../devicetree/bindings/serial/cdns,uart.yaml |   1 +
 drivers/tty/serial/xilinx_uartps.c            | 252 ++++++++++++++++--
 2 files changed, 229 insertions(+), 24 deletions(-)

-- 
2.25.1



From manikanta.guntupalli at amd.com  Fri Dec 15 04:56:25 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Fri, 15 Dec 2023 18:26:25 +0530
Subject: [PATCH V6 1/3] dt-bindings: Add reference to rs485.yaml
In-Reply-To: <20231215125627.1691573-1-manikanta.guntupalli@amd.com>
References: <20231215125627.1691573-1-manikanta.guntupalli@amd.com>
Message-ID: <20231215125627.1691573-2-manikanta.guntupalli@amd.com>

Add rs485 support to uartps driver and Xilinx/AMD Kria SOM KD240
board have rs485 support.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.

Changes for V4:
Update rts-gpios description.

Changes for V5:
Remove rts-gpios description.
Update commit message and description.

Changes for V6:
Update commit description.
---
 Documentation/devicetree/bindings/serial/cdns,uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
index e35ad1109efc..2129247d7c81 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
@@ -55,6 +55,7 @@ required:
 
 allOf:
   - $ref: serial.yaml#
+  - $ref: rs485.yaml#
   - if:
       properties:
         compatible:
-- 
2.25.1



From gregkh at linuxfoundation.org  Fri Dec 15 04:56:38 2023
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Fri, 15 Dec 2023 13:56:38 +0100
Subject: patch "usb: gadget: udc: atmel: Replace snprintf() with the safer" added to usb-testing
Message-ID: <2023121538-polka-speller-f225@gregkh>


This is a note to let you know that I've just added the patch titled

    usb: gadget: udc: atmel: Replace snprintf() with the safer

to my usb git tree which can be found at
    git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-testing branch.

The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)

The patch will be merged to the usb-next branch sometime soon,
after it passes testing, and the merge window is open.

If you have any questions about this process, please let me know.


>From d32dcb0659bcb3b68878a985280024ec92d0db5b Mon Sep 17 00:00:00 2001
From: Lee Jones <lee at kernel.org>
Date: Wed, 13 Dec 2023 16:42:34 +0000
Subject: usb: gadget: udc: atmel: Replace snprintf() with the safer
 scnprintf() variant

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Cristian Birsan <cristian.birsan at microchip.com>
Cc: Nicolas Ferre <nicolas.ferre at microchip.com>
Cc: Alexandre Belloni <alexandre.belloni at bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea at tuxon.dev>
Cc:  <linux-arm-kernel at lists.infradead.org>
Signed-off-by: Lee Jones <lee at kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-6-lee at kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 02b1bef5e22e..b76885d78e8a 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -94,7 +94,7 @@ static ssize_t queue_dbg_read(struct file *file, char __user *buf,
 
 	inode_lock(file_inode(file));
 	list_for_each_entry_safe(req, tmp_req, queue, queue) {
-		len = snprintf(tmpbuf, sizeof(tmpbuf),
+		len = scnprintf(tmpbuf, sizeof(tmpbuf),
 				"%8p %08x %c%c%c %5d %c%c%c\n",
 				req->req.buf, req->req.length,
 				req->req.no_interrupt ? 'i' : 'I',
@@ -104,7 +104,6 @@ static ssize_t queue_dbg_read(struct file *file, char __user *buf,
 				req->submitted ? 'F' : 'f',
 				req->using_dma ? 'D' : 'd',
 				req->last_transaction ? 'L' : 'l');
-		len = min(len, sizeof(tmpbuf));
 		if (len > nbytes)
 			break;
 
-- 
2.43.0




From gregkh at linuxfoundation.org  Fri Dec 15 04:56:40 2023
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Fri, 15 Dec 2023 13:56:40 +0100
Subject: patch "usb: host: max3421-hcd: Replace snprintf() with the safer scnprintf()" added to usb-testing
Message-ID: <2023121539-coerce-federal-430f@gregkh>


This is a note to let you know that I've just added the patch titled

    usb: host: max3421-hcd: Replace snprintf() with the safer scnprintf()

to my usb git tree which can be found at
    git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-testing branch.

The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)

The patch will be merged to the usb-next branch sometime soon,
after it passes testing, and the merge window is open.

If you have any questions about this process, please let me know.


>From a6eef67cdb84e06112fc29176d6c6061d3ea8d79 Mon Sep 17 00:00:00 2001
From: Lee Jones <lee at kernel.org>
Date: Wed, 13 Dec 2023 16:42:36 +0000
Subject: usb: host: max3421-hcd: Replace snprintf() with the safer scnprintf()
 variant

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Cristian Birsan <cristian.birsan at microchip.com>
Cc: Nicolas Ferre <nicolas.ferre at microchip.com>
Cc: Alexandre Belloni <alexandre.belloni at bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea at tuxon.dev>
Cc:  <linux-arm-kernel at lists.infradead.org>
Signed-off-by: Lee Jones <lee at kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-8-lee at kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/usb/host/max3421-hcd.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index d152d72de126..9fe4f48b1898 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1158,12 +1158,12 @@ dump_eps(struct usb_hcd *hcd)
 		end = dp + sizeof(ubuf);
 		*dp = '\0';
 		list_for_each_entry(urb, &ep->urb_list, urb_list) {
-			ret = snprintf(dp, end - dp, " %p(%d.%s %d/%d)", urb,
-				       usb_pipetype(urb->pipe),
-				       usb_urb_dir_in(urb) ? "IN" : "OUT",
-				       urb->actual_length,
-				       urb->transfer_buffer_length);
-			if (ret < 0 || ret >= end - dp)
+			ret = scnprintf(dp, end - dp, " %p(%d.%s %d/%d)", urb,
+					usb_pipetype(urb->pipe),
+					usb_urb_dir_in(urb) ? "IN" : "OUT",
+					urb->actual_length,
+					urb->transfer_buffer_length);
+			if (ret == end - dp - 1)
 				break;	/* error or buffer full */
 			dp += ret;
 		}
@@ -1255,9 +1255,9 @@ max3421_handle_irqs(struct usb_hcd *hcd)
 			end = sbuf + sizeof(sbuf);
 			*dp = '\0';
 			for (i = 0; i < 16; ++i) {
-				int ret = snprintf(dp, end - dp, " %lu",
-						   max3421_hcd->err_stat[i]);
-				if (ret < 0 || ret >= end - dp)
+				int ret = scnprintf(dp, end - dp, " %lu",
+						    max3421_hcd->err_stat[i]);
+				if (ret == end - dp - 1)
 					break;	/* error or buffer full */
 				dp += ret;
 			}
-- 
2.43.0




From manikanta.guntupalli at amd.com  Fri Dec 15 04:56:26 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Fri, 15 Dec 2023 18:26:26 +0530
Subject: [PATCH V6 2/3] tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485
In-Reply-To: <20231215125627.1691573-1-manikanta.guntupalli@amd.com>
References: <20231215125627.1691573-1-manikanta.guntupalli@amd.com>
Message-ID: <20231215125627.1691573-3-manikanta.guntupalli@amd.com>

Relocate cdns_uart_tx_empty function to avoid prototype statement in
rs485 changes.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes since V4:
This patch introduced in V4.

Changes for V5:
None.

Changes for V6:
None.
---
 drivers/tty/serial/xilinx_uartps.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 920762d7b4a4..aafcc2179e0e 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -305,6 +305,21 @@ static void cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus)
 	tty_flip_buffer_push(&port->state->port);
 }
 
+/**
+ * cdns_uart_tx_empty -  Check whether TX is empty
+ * @port: Handle to the uart port structure
+ *
+ * Return: TIOCSER_TEMT on success, 0 otherwise
+ */
+static unsigned int cdns_uart_tx_empty(struct uart_port *port)
+{
+	unsigned int status;
+
+	status = readl(port->membase + CDNS_UART_SR);
+	status &= (CDNS_UART_SR_TXEMPTY | CDNS_UART_SR_TACTIVE);
+	return (status == CDNS_UART_SR_TXEMPTY) ? TIOCSER_TEMT : 0;
+}
+
 /**
  * cdns_uart_handle_tx - Handle the bytes to be Txed.
  * @dev_id: Id of the UART port
@@ -626,21 +641,6 @@ static void cdns_uart_stop_rx(struct uart_port *port)
 	writel(regval, port->membase + CDNS_UART_CR);
 }
 
-/**
- * cdns_uart_tx_empty -  Check whether TX is empty
- * @port: Handle to the uart port structure
- *
- * Return: TIOCSER_TEMT on success, 0 otherwise
- */
-static unsigned int cdns_uart_tx_empty(struct uart_port *port)
-{
-	unsigned int status;
-
-	status = readl(port->membase + CDNS_UART_SR) &
-		       (CDNS_UART_SR_TXEMPTY | CDNS_UART_SR_TACTIVE);
-	return (status == CDNS_UART_SR_TXEMPTY) ? TIOCSER_TEMT : 0;
-}
-
 /**
  * cdns_uart_break_ctl - Based on the input ctl we have to start or stop
  *			transmitting char breaks
-- 
2.25.1



From manikanta.guntupalli at amd.com  Fri Dec 15 04:56:27 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Fri, 15 Dec 2023 18:26:27 +0530
Subject: [PATCH V6 3/3] tty: serial: uartps: Add rs485 support to uartps driver
In-Reply-To: <20231215125627.1691573-1-manikanta.guntupalli@amd.com>
References: <20231215125627.1691573-1-manikanta.guntupalli@amd.com>
Message-ID: <20231215125627.1691573-4-manikanta.guntupalli@amd.com>

Add rs485 support to uartps driver. Use either rts-gpios or RTS
to control RS485 phy as driver or a receiver.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.
Add support for RTS, delay_rts_before_send and delay_rts_after_send in RS485 mode.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.
Move cdns_uart_tx_empty function to avoid prototype statement.
Remove assignment of struct serial_rs485 to port->rs485 as
serial core performs that.
Switch to native RTS in non GPIO case.
Handle rs485 during stop tx.
Remove explicit calls to configure gpio direction and value,
as devm_gpiod_get_optional performs that by using GPIOD_OUT_LOW argument.
Update implementation to support configuration of GPIO/RTS value
based on user configuration of SER_RS485_RTS_ON_SEND and
SER_RS485_RTS_AFTER_SEND. Move implementation to start_tx from handle_tx.

Changes for V4:
Create separate patch for cdns_uart_tx_empty relocation.
Call cdns_rs485_rx_setup() before uart_add_one_port() in probe.
Update gpio descriptor name to gpiod_rts.
Instead of cdns_rs485_config_gpio_rts_high() and
cdns_rs485_config_gpio_rts_low() functions for RTS/GPIO value
configuration implement cdns_rts_gpio_enable().
Disable auto rts and call cdns_uart_stop_tx() from cdns_rs485_config.
Use timer instead of mdelay for delay_rts_before_send and delay_rts_after_send.
Update cdns_uart_set_mctrl to support GPIO/RTS.

Changes for V5:
None.

Changes for V6:
Disable the TX and RX in cdns_rs485_config() when rs485 disabled.
Hold lock for cdns_uart_handle_tx() in cdns_rs485_tx_callback().
---
 drivers/tty/serial/xilinx_uartps.c | 222 +++++++++++++++++++++++++++--
 1 file changed, 213 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index aafcc2179e0e..04cc23deebdf 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -22,7 +22,9 @@
 #include <linux/of.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
-#include <linux/iopoll.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/delay.h>
 
 #define CDNS_UART_TTY_NAME	"ttyPS"
 #define CDNS_UART_NAME		"xuartps"
@@ -193,6 +195,10 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255");
  * @clk_rate_change_nb:	Notifier block for clock changes
  * @quirks:		Flags for RXBS support.
  * @cts_override:	Modem control state override
+ * @gpiod_rts:		Pointer to the gpio descriptor
+ * @rs485_tx_started:	RS485 tx state
+ * @timer:		Timer for tx and rx
+ * @stop_tx_timer:	Timer for stop tx
  */
 struct cdns_uart {
 	struct uart_port	*port;
@@ -203,10 +209,22 @@ struct cdns_uart {
 	struct notifier_block	clk_rate_change_nb;
 	u32			quirks;
 	bool cts_override;
+	struct gpio_desc	*gpiod_rts;
+	bool			rs485_tx_started;
+	struct timer_list	timer;
+	struct timer_list	stop_tx_timer;
 };
 struct cdns_platform_data {
 	u32 quirks;
 };
+
+struct serial_rs485 cdns_rs485_supported = {
+	.flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND |
+		 SER_RS485_RTS_AFTER_SEND,
+	.delay_rts_before_send = 1,
+	.delay_rts_after_send = 1,
+};
+
 #define to_cdns_uart(_nb) container_of(_nb, struct cdns_uart, \
 		clk_rate_change_nb)
 
@@ -305,6 +323,55 @@ static void cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus)
 	tty_flip_buffer_push(&port->state->port);
 }
 
+/**
+ * cdns_rts_gpio_enable - Configure RTS/GPIO to high/low
+ * @cdns_uart: Handle to the cdns_uart
+ * @enable: Value to be set to RTS/GPIO
+ */
+static void cdns_rts_gpio_enable(struct cdns_uart *cdns_uart, bool enable)
+{
+	u32 val;
+
+	if (cdns_uart->gpiod_rts) {
+		gpiod_set_value(cdns_uart->gpiod_rts, enable);
+	} else {
+		val = readl(cdns_uart->port->membase + CDNS_UART_MODEMCR);
+		if (enable)
+			val &= ~CDNS_UART_MODEMCR_RTS;
+		else
+			val |= CDNS_UART_MODEMCR_RTS;
+		writel(val, cdns_uart->port->membase + CDNS_UART_MODEMCR);
+	}
+}
+
+/**
+ * cdns_rs485_tx_setup - Tx setup specific to rs485
+ * @cdns_uart: Handle to the cdns_uart
+ */
+static void cdns_rs485_tx_setup(struct cdns_uart *cdns_uart)
+{
+	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_ON_SEND)
+		cdns_rts_gpio_enable(cdns_uart, 1);
+	else
+		cdns_rts_gpio_enable(cdns_uart, 0);
+
+	cdns_uart->rs485_tx_started = true;
+}
+
+/**
+ * cdns_rs485_rx_setup - Rx setup specific to rs485
+ * @cdns_uart: Handle to the cdns_uart
+ */
+static void cdns_rs485_rx_setup(struct cdns_uart *cdns_uart)
+{
+	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_AFTER_SEND)
+		cdns_rts_gpio_enable(cdns_uart, 1);
+	else
+		cdns_rts_gpio_enable(cdns_uart, 0);
+
+	cdns_uart->rs485_tx_started = false;
+}
+
 /**
  * cdns_uart_tx_empty -  Check whether TX is empty
  * @port: Handle to the uart port structure
@@ -579,6 +646,44 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
 }
 #endif
 
+/**
+ * cdns_rs485_rx_callback - Timer rx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_rx_callback(struct timer_list *t)
+{
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
+
+	/*
+	 * Default Rx should be setup, because Rx signaling path
+	 * need to enable to receive data.
+	 */
+	cdns_rs485_rx_setup(cdns_uart);
+}
+
+/**
+ * cdns_rs485_tx_callback - Timer tx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_tx_callback(struct timer_list *t)
+{
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
+
+	uart_port_lock(cdns_uart->port);
+	cdns_uart_handle_tx(cdns_uart->port);
+
+	/* Enable the TX Empty interrupt */
+	writel(CDNS_UART_IXR_TXEMPTY, cdns_uart->port->membase + CDNS_UART_IER);
+	uart_port_unlock(cdns_uart->port);
+
+	if (uart_circ_empty(&cdns_uart->port->state->xmit) ||
+	    uart_tx_stopped(cdns_uart->port)) {
+		timer_setup(&cdns_uart->timer, cdns_rs485_rx_callback, 0);
+		mod_timer(&cdns_uart->timer, jiffies +
+			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
+	}
+}
+
 /**
  * cdns_uart_start_tx -  Start transmitting bytes
  * @port: Handle to the uart port structure
@@ -586,6 +691,7 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
 static void cdns_uart_start_tx(struct uart_port *port)
 {
 	unsigned int status;
+	struct cdns_uart *cdns_uart = port->private_data;
 
 	if (uart_tx_stopped(port))
 		return;
@@ -604,10 +710,40 @@ static void cdns_uart_start_tx(struct uart_port *port)
 
 	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_ISR);
 
-	cdns_uart_handle_tx(port);
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		if (!cdns_uart->rs485_tx_started) {
+			timer_setup(&cdns_uart->timer,
+				    cdns_rs485_tx_callback, 0);
+			cdns_rs485_tx_setup(cdns_uart);
+			mod_timer(&cdns_uart->timer, jiffies +
+				  msecs_to_jiffies(port->rs485.delay_rts_before_send));
+		} else {
+			if (!timer_pending(&cdns_uart->timer))
+				mod_timer(&cdns_uart->timer, jiffies);
+		}
+	} else {
+		cdns_uart_handle_tx(port);
 
-	/* Enable the TX Empty interrupt */
-	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
+		/* Enable the TX Empty interrupt */
+		writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
+	}
+}
+
+/**
+ * cdns_rs485_stop_tx_callback - Timer stop tx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_stop_tx_callback(struct timer_list *t)
+{
+	unsigned int regval;
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, stop_tx_timer);
+
+	cdns_rs485_rx_setup(cdns_uart);
+
+	regval = readl(cdns_uart->port->membase + CDNS_UART_CR);
+	regval |= CDNS_UART_CR_TX_DIS;
+	/* Disable the transmitter */
+	writel(regval, cdns_uart->port->membase + CDNS_UART_CR);
 }
 
 /**
@@ -617,11 +753,19 @@ static void cdns_uart_start_tx(struct uart_port *port)
 static void cdns_uart_stop_tx(struct uart_port *port)
 {
 	unsigned int regval;
+	struct cdns_uart *cdns_uart = port->private_data;
 
-	regval = readl(port->membase + CDNS_UART_CR);
-	regval |= CDNS_UART_CR_TX_DIS;
-	/* Disable the transmitter */
-	writel(regval, port->membase + CDNS_UART_CR);
+	if ((cdns_uart->port->rs485.flags & SER_RS485_ENABLED) &&
+	    !timer_pending(&cdns_uart->stop_tx_timer) &&
+	    cdns_uart->rs485_tx_started) {
+		mod_timer(&cdns_uart->stop_tx_timer, jiffies +
+			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
+	} else {
+		regval = readl(port->membase + CDNS_UART_CR);
+		regval |= CDNS_UART_CR_TX_DIS;
+		/* Disable the transmitter */
+		writel(regval, port->membase + CDNS_UART_CR);
+	}
 }
 
 /**
@@ -829,6 +973,12 @@ static int cdns_uart_startup(struct uart_port *port)
 		(CDNS_UART_CR_TXRST | CDNS_UART_CR_RXRST))
 		cpu_relax();
 
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		timer_setup(&cdns_uart->stop_tx_timer,
+			    cdns_rs485_stop_tx_callback, 0);
+		cdns_rs485_rx_setup(cdns_uart);
+	}
+
 	/*
 	 * Clear the RX disable bit and then set the RX enable bit to enable
 	 * the receiver.
@@ -888,6 +1038,7 @@ static void cdns_uart_shutdown(struct uart_port *port)
 {
 	int status;
 	unsigned long flags;
+	struct cdns_uart *cdns_uart = port->private_data;
 
 	uart_port_lock_irqsave(port, &flags);
 
@@ -903,6 +1054,11 @@ static void cdns_uart_shutdown(struct uart_port *port)
 	uart_port_unlock_irqrestore(port, flags);
 
 	free_irq(port->irq, port);
+
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		del_timer_sync(&cdns_uart->timer);
+		del_timer_sync(&cdns_uart->stop_tx_timer);
+	}
 }
 
 /**
@@ -1032,7 +1188,7 @@ static void cdns_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
 	mode_reg &= ~CDNS_UART_MR_CHMODE_MASK;
 
 	if (mctrl & TIOCM_RTS)
-		val |= CDNS_UART_MODEMCR_RTS;
+		cdns_rts_gpio_enable(cdns_uart_data, 1);
 	if (mctrl & TIOCM_DTR)
 		val |= CDNS_UART_MODEMCR_DTR;
 	if (mctrl & TIOCM_LOOP)
@@ -1455,6 +1611,37 @@ MODULE_DEVICE_TABLE(of, cdns_uart_of_match);
 /* Temporary variable for storing number of instances */
 static int instances;
 
+/**
+ * cdns_rs485_config - Called when an application calls TIOCSRS485 ioctl.
+ * @port: Pointer to the uart_port structure
+ * @termios: Pointer to the ktermios structure
+ * @rs485: Pointer to the serial_rs485 structure
+ *
+ * Return: 0
+ */
+static int cdns_rs485_config(struct uart_port *port, struct ktermios *termios,
+			     struct serial_rs485 *rs485)
+{
+	u32 val;
+	unsigned int ctrl_reg;
+
+	if (rs485->flags & SER_RS485_ENABLED) {
+		dev_dbg(port->dev, "Setting UART to RS485\n");
+		/* Make sure auto RTS is disabled */
+		val = readl(port->membase + CDNS_UART_MODEMCR);
+		val &= ~CDNS_UART_MODEMCR_FCM;
+		writel(val, port->membase + CDNS_UART_MODEMCR);
+		/* Disable transmitter and make Rx setup*/
+		cdns_uart_stop_tx(port);
+	} else {
+		/* Disable the TX and RX */
+		ctrl_reg = readl(port->membase + CDNS_UART_CR);
+		ctrl_reg |= CDNS_UART_CR_TX_DIS | CDNS_UART_CR_RX_DIS;
+		writel(ctrl_reg, port->membase + CDNS_UART_CR);
+	}
+	return 0;
+}
+
 /**
  * cdns_uart_probe - Platform driver probe
  * @pdev: Pointer to the platform device structure
@@ -1597,9 +1784,23 @@ static int cdns_uart_probe(struct platform_device *pdev)
 	port->private_data = cdns_uart_data;
 	port->read_status_mask = CDNS_UART_IXR_TXEMPTY | CDNS_UART_IXR_RXTRIG |
 			CDNS_UART_IXR_OVERRUN | CDNS_UART_IXR_TOUT;
+	port->rs485_config = cdns_rs485_config;
+	port->rs485_supported = cdns_rs485_supported;
 	cdns_uart_data->port = port;
 	platform_set_drvdata(pdev, port);
 
+	rc = uart_get_rs485_mode(port);
+	if (rc)
+		goto err_out_clk_notifier;
+
+	cdns_uart_data->gpiod_rts = devm_gpiod_get_optional(&pdev->dev, "rts",
+							    GPIOD_OUT_LOW);
+	if (IS_ERR(cdns_uart_data->gpiod_rts)) {
+		rc = PTR_ERR(cdns_uart_data->gpiod_rts);
+		dev_err(port->dev, "xuartps: devm_gpiod_get_optional failed\n");
+		goto err_out_clk_notifier;
+	}
+
 	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_set_autosuspend_delay(&pdev->dev, UART_AUTOSUSPEND_TIMEOUT);
 	pm_runtime_set_active(&pdev->dev);
@@ -1618,6 +1819,8 @@ static int cdns_uart_probe(struct platform_device *pdev)
 		console_port = port;
 	}
 #endif
+	if (cdns_uart_data->port->rs485.flags & SER_RS485_ENABLED)
+		cdns_rs485_rx_setup(cdns_uart_data);
 
 	rc = uart_add_one_port(&cdns_uart_uart_driver, port);
 	if (rc) {
@@ -1646,6 +1849,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
+err_out_clk_notifier:
 #ifdef CONFIG_COMMON_CLK
 	clk_notifier_unregister(cdns_uart_data->uartclk,
 			&cdns_uart_data->clk_rate_change_nb);
-- 
2.25.1



From mark.rutland at arm.com  Fri Dec 15 05:04:35 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 15 Dec 2023 13:04:35 +0000
Subject: ARM64 Livepatch based on SFrame
In-Reply-To: <72364198-b031-4ecc-b337-d07db1b9d0c8@linux.microsoft.com>
References: <0337266cf19f4c98388e3f6d09f590d9de258dc7>
 <20230202074036.507249-1-madvenka@linux.microsoft.com>
 <ZByJmnc/XDcqQwoZ@FVFF77S0Q05N.cambridge.arm.com>
 <72364198-b031-4ecc-b337-d07db1b9d0c8@linux.microsoft.com>
Message-ID: <ZXxO43Xwn5GHsrO8@FVFF77S0Q05N>

On Thu, Dec 14, 2023 at 02:49:29PM -0600, Madhavan T. Venkataraman wrote:
> Hi Mark,

Hi Madhavan,

> I attended your presentation in the LPC. You mentioned that you could use
> some help with some pre-requisites for the Livepatch feature.
> I would like to lend a hand.

Cool!

I've been meaning to send a mail round with a summary of the current state of
things, and what needs to be done going forward, but I haven't had the time
since LPC to put that together (as e.g. that requires learning some more about
SFrame).  I'll be disappearing for the holiday shortly, and I intend to pick
that up in the new year.

> What would you like me to implement?

I'm not currently sure exactly what we need/want to implement, and as above I
think that needs to wait until the new year.

However, one thing that you can do that would be very useful is to write up and
report the GCC DWARF issues that you mentioned in:

  https://lore.kernel.org/linux-arm-kernel/20230202074036.507249-1-madvenka at linux.microsoft.com/

... as (depending on exactly what those are) those could also affect SFrame
generation (and thus we'll need to get those fixed in GCC), and regardless it
would be useful information to know.

I understood that you planned to do that from:

  https://lore.kernel.org/linux-arm-kernel/054ce0d6-70f0-b834-d4e5-1049c8df7492 at linux.microsoft.com/

... but I couldn't spot any relevant mails or issues in the GCC bugzilla, so
either I'm failing to search hard enough, or did that get forgotten about?

> I would also like to implement Unwind Hints for the feature. If you want a
> specific format for the hints, let me know.

I will get back to you on that in the new year; I think the specifics we want
are going to depend on other details above we need to analyse first.

Thanks,
Mark.


From gregkh at linuxfoundation.org  Fri Dec 15 05:26:48 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 15 Dec 2023 14:26:48 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <ZXs94Mf1eOMCmGpT@francesco-nb.int.toradex.com>
References: <20231214170146.641783-1-francesco@dolcini.it>
 <ZXs94Mf1eOMCmGpT@francesco-nb.int.toradex.com>
Message-ID: <2023121535-coveting-destruct-f567@gregkh>

On Thu, Dec 14, 2023 at 06:39:44PM +0100, Francesco Dolcini wrote:
> On Thu, Dec 14, 2023 at 06:01:46PM +0100, Francesco Dolcini wrote:
> > From: Francesco Dolcini <francesco.dolcini at toradex.com>
> > 
> > receive_buf() is called from ttyport_receive_buf() that expects values
> > ">= 0" from serdev_controller_receive_buf(), change its return type from
> > ssize_t to size_t.
> > 
> > Suggested-by: Jiri Slaby <jirislaby at kernel.org>
> > Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
> > Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> > ---
> > hello,
> > patch is based on current linux next.
> > 
> > It has an obvious problem, it touches files from multiple subsystem in a single
> > patch that is complicated to review and eventually merge, just splitting this
> > would however not work, it will break bisectability and the build.
> > 
> > I am looking for advise on the best way to move forward.
> > 
> > I see the following options:
> >  - keep it as it is
> >  - break it down with a patch with each subsystem, and squash before applying
> >    from a single (tty?) subsystem
> >  - go for a multi stage approach, defining a new callback, move to it and in
> >    the end remove the original one, likewise it was done for i2c lately
> 
> whoops. I just noticed Greg applied commit 475fc6e2de6f ("tty: serdev:
> convert to u8 and size_t") that touch the exact same files without much
> of an issue.
> 
> Probably the "keep it as it is" is just the way to go.

Yeah, looks good to me, now queued up, thanks!

greg k-h


From kvalo at kernel.org  Fri Dec 15 05:29:37 2023
From: kvalo at kernel.org (Kalle Valo)
Date: Fri, 15 Dec 2023 13:29:37 +0000 (UTC)
Subject: [PATCH v2][wireless-next/for-next] wifi: mt76: mt7996: Use
 DECLARE_FLEX_ARRAY() and fix -Warray-bounds warnings
In-Reply-To: <ZXiU9ayVCslt3qiI@work>
References: <ZXiU9ayVCslt3qiI@work>
Message-ID: <170264697580.1759617.6397953788753678096.kvalo@kernel.org>

"Gustavo A. R. Silva" <gustavoars at kernel.org> wrote:

> Transform zero-length arrays `rate`, `adm_stat` and `msdu_cnt` into
> proper flexible-array members in anonymous union in `struct
> mt7996_mcu_all_sta_info_event` via the DECLARE_FLEX_ARRAY()
> helper; and fix multiple -Warray-bounds warnings:
> 
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:544:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:551:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:553:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:530:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:538:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:540:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:520:57: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> 
> This results in no differences in binary output, helps with the ongoing
> efforts to globally enable -Warray-bounds.
> 
> Reviewed-by: Kees Cook <keescook at chromium.org>
> Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org>

I'll take this directly wireless-next, ok?

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/ZXiU9ayVCslt3qiI at work/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From festevam at gmail.com  Fri Dec 15 05:31:27 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 15 Dec 2023 10:31:27 -0300
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>
References: <20230920171009.3193296-1-l.stach@pengutronix.de>
 <20230920171009.3193296-2-l.stach@pengutronix.de> <20230920205736.GB7723@pendragon.ideasonboard.com>
 <CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>
Message-ID: <CAOMZO5C7_Rj-Ja0BO0D0Po+gy+XbvyMdQf-wH5YNyhAdMof2vg@mail.gmail.com>

Hi Adam,

On Sun, Dec 10, 2023 at 2:35?PM Adam Ford <aford173 at gmail.com> wrote:

> Lucas,
>
> It's been a few months since there has been any action.  If you want,
> I can help apply the suggestions that Laurent has and re-submit with
> both of our names if you want.  It would be nice to get this
> integrated.

It would be nice if you could re-submit the series.

Thanks


From mripard at kernel.org  Fri Dec 15 05:33:12 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Fri, 15 Dec 2023 14:33:12 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
 <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
 <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>
Message-ID: <oobcl2kfsuph27er7rflfqvt3lu6athufomxv5chf3uctx4emh@x6rzjtlskhbf>

On Thu, Dec 07, 2023 at 11:33:53AM +0100, H. Nikolaus Schaller wrote:
> Hi Maxime,
> 
> > Am 07.12.2023 um 10:20 schrieb Maxime Ripard <mripard at kernel.org>:
> > 
> > On Tue, Dec 05, 2023 at 02:50:08PM +0100, H. Nikolaus Schaller wrote:
> >> Hi,
> >> 
> >>> Am 05.12.2023 um 14:29 schrieb Maxime Ripard <mripard at kernel.org>:
> >>> 
> >>> Hi,
> >>> 
> >>> On Tue, Dec 05, 2023 at 09:18:58AM +0100, H. Nikolaus Schaller wrote:
> >>>>> Am 05.12.2023 um 07:57 schrieb Maxime Ripard <mripard at kernel.org>:
> >>>>> 
> >>>>> On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
> >>>>>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> >>>>>> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
> >>>>>> including register space and interrupts. Clocks, reset, and power domain
> >>>>>> information is SoC specific.
> >>>>>> 
> >>>>>> Signed-off-by: Andrew Davis <afd at ti.com>
> >>>>>> ---
> >>>>>> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +++++++++++++++++--
> >>>>>> 1 file changed, 63 insertions(+), 6 deletions(-)
> >>>>> 
> >>>>> I think it would be best to have a separate file for this, img,sgx.yaml
> >>>>> maybe?
> >>>> 
> >>>> Why?
> >>> 
> >>> Because it's more convenient?
> >> 
> >> Is it?
> > 
> > It's for a separate architecture, with a separate driver, maintained out
> > of tree by a separate community, with a separate set of requirements as
> > evidenced by the other thread. And that's all fine in itself, but
> > there's very little reason to put these two bindings in the same file.
> > 
> > We could also turn this around, why is it important that it's in the
> > same file?
> 
> Same vendor. And enough similarity in architectures, even a logical sequence
> of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
> (SGX and Rogue seem to be just trade names for their architecture development).

Again, none of that matters for *where* the binding is stored.

> AFAIK bindings should describe hardware and not communities or drivers
> or who is currently maintaining it. The latter can change, the first not.

Bindings are supposed to describe hardware indeed. Nothing was ever said
about where those bindings are supposed to be located.

There's hundreds of other YAML bindings describing devices of the same
vendors and different devices from the same generation. If anything
it'll make it easier for you. I'm really not sure why it is
controversial and you're fighting this so hard.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/3ce41231/attachment.sig>

From johan at kernel.org  Fri Dec 15 05:36:31 2023
From: johan at kernel.org (Johan Hovold)
Date: Fri, 15 Dec 2023 14:36:31 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <20231214170146.641783-1-francesco@dolcini.it>
References: <20231214170146.641783-1-francesco@dolcini.it>
Message-ID: <ZXxWX-Fw1InID2ax@hovoldconsulting.com>

On Thu, Dec 14, 2023 at 06:01:46PM +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> receive_buf() is called from ttyport_receive_buf() that expects values
> ">= 0" from serdev_controller_receive_buf(), change its return type from
> ssize_t to size_t.
> 
> Suggested-by: Jiri Slaby <jirislaby at kernel.org>
> Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
> Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> ---
>  drivers/gnss/core.c                        |  6 +++---
>  drivers/gnss/serial.c                      |  4 ++--
>  drivers/gnss/sirf.c                        |  6 +++---

> diff --git a/drivers/gnss/core.c b/drivers/gnss/core.c
> index 48f2ee0f78c4..9b8a0605ec76 100644
> --- a/drivers/gnss/core.c
> +++ b/drivers/gnss/core.c
> @@ -317,10 +317,10 @@ EXPORT_SYMBOL_GPL(gnss_deregister_device);
>   *
>   * Must not be called for a closed device.
>   */
> -int gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> -				size_t count)
> +size_t gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> +		       size_t count)
>  {
> -	int ret;
> +	size_t ret;
>  
>  	ret = kfifo_in(&gdev->read_fifo, buf, count);
>  

Why are you changing this function? This is part of the GNSS interface
and has nothing to do with the rest of this patch.

Greg, please drop this one again until this has been resolved.

Johan


From tabba at google.com  Fri Dec 15 05:43:08 2023
From: tabba at google.com (Fuad Tabba)
Date: Fri, 15 Dec 2023 13:43:08 +0000
Subject: [PATCH v3 09/17] KVM: arm64: Handle HAFGRTR_EL2 trapping in
 nested virt
In-Reply-To: <20231214100158.2305400-10-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com> <20231214100158.2305400-10-tabba@google.com>
Message-ID: <CA+EHjTwrcXjOdo7JG-6fr0YpDq2EtMoTQxngq5H-ELLdjyQG=A@mail.gmail.com>

Hi,

On Thu, Dec 14, 2023 at 10:02?AM Fuad Tabba <tabba at google.com> wrote:
>
> Add the encodings to fine grain trapping fields for HAFGRTR_EL2
> and add the associated handling code in nested virt. Based on
> DDI0601 2023-09. Add the missing field definitions as well,
> both to generate the correct RES0 mask and to be able to toggle
> their FGT bits.

I realized that HAFGRTR_EL2 is present only when both FEAT_AMUv1 and
FEAT_FGT are implemented. Otherwise, direct accesses to it are
UNDEFINED.

I'll fix this when I respin. In the meantime, below is the fix to this
patch. Note that checking for ARM64_HAS_AMU_EXTN is not enough, since,
among other things, it's a weak local cpu feature, i.e., not all cpus
need to have it (and none might).

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h
b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 22f3b916f60c..741d6f0a780a 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -79,6 +79,13 @@ static inline void __activate_traps_fpsimd32(struct
kvm_vcpu *vcpu)
                clr |= ~hfg & __ ## reg ## _nMASK;                      \
        } while(0)

+static inline bool cpu_has_amu(void)
+{
+       u64 pfr0 = read_sysreg_s(SYS_ID_AA64PFR0_EL1);
+
+       return cpuid_feature_extract_unsigned_field(pfr0,
+               ID_AA64PFR0_EL1_AMU_SHIFT);
+}

 static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 {
@@ -157,6 +164,9 @@ static inline void __activate_traps_hfgxtr(struct
kvm_vcpu *vcpu)
        write_sysreg_s(r_val, SYS_HDFGRTR_EL2);
        write_sysreg_s(w_val, SYS_HDFGWTR_EL2);

+       if (!cpu_has_amu())
+               return;
+
        ctxt_sys_reg(hctxt, HAFGRTR_EL2) = read_sysreg_s(SYS_HAFGRTR_EL2);

        r_clr = r_set = 0;
@@ -185,7 +195,9 @@ static inline void
__deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
        write_sysreg_s(ctxt_sys_reg(hctxt, HFGITR_EL2), SYS_HFGITR_EL2);
        write_sysreg_s(ctxt_sys_reg(hctxt, HDFGRTR_EL2), SYS_HDFGRTR_EL2);
        write_sysreg_s(ctxt_sys_reg(hctxt, HDFGWTR_EL2), SYS_HDFGWTR_EL2);
-       write_sysreg_s(ctxt_sys_reg(hctxt, HAFGRTR_EL2), SYS_HAFGRTR_EL2);
+
+       if (cpu_has_amu())
+               write_sysreg_s(ctxt_sys_reg(hctxt, HAFGRTR_EL2),
SYS_HAFGRTR_EL2);
 }

 static inline void __activate_traps_common(struct kvm_vcpu *vcpu)


Cheers,
/fuad





>
> Also add the code for handling FGT trapping, reading of the
> register, to nested virt.
>
> Reviewed-by: Mark Brown <broonie at kernel.org>
> Signed-off-by: Fuad Tabba <tabba at google.com>
> ---
>  arch/arm64/include/asm/kvm_host.h       |  1 +
>  arch/arm64/kvm/emulate-nested.c         | 48 +++++++++++++++++++++++++
>  arch/arm64/kvm/hyp/include/hyp/switch.h | 12 +++++++
>  arch/arm64/kvm/sys_regs.c               |  1 +
>  4 files changed, 62 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 824f29f04916..ba14648e2de2 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -443,6 +443,7 @@ enum vcpu_sysreg {
>         HFGITR_EL2,
>         HDFGRTR_EL2,
>         HDFGWTR_EL2,
> +       HAFGRTR_EL2,
>         CNTHP_CTL_EL2,
>         CNTHP_CVAL_EL2,
>         CNTHV_CTL_EL2,
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index 89901550db34..431fd429932d 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -1012,6 +1012,7 @@ enum fgt_group_id {
>         HDFGRTR_GROUP,
>         HDFGWTR_GROUP,
>         HFGITR_GROUP,
> +       HAFGRTR_GROUP,
>
>         /* Must be last */
>         __NR_FGT_GROUP_IDS__
> @@ -1689,6 +1690,49 @@ static const struct encoding_to_trap_config encoding_to_fgt[] __initconst = {
>         SR_FGT(SYS_PMCR_EL0,            HDFGWTR, PMCR_EL0, 1),
>         SR_FGT(SYS_PMSWINC_EL0,         HDFGWTR, PMSWINC_EL0, 1),
>         SR_FGT(SYS_OSLAR_EL1,           HDFGWTR, OSLAR_EL1, 1),
> +       /*
> +        * HAFGRTR_EL2
> +        */
> +       SR_FGT(SYS_AMEVTYPER1_EL0(15),  HAFGRTR, AMEVTYPER115_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(14),  HAFGRTR, AMEVTYPER114_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(13),  HAFGRTR, AMEVTYPER113_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(12),  HAFGRTR, AMEVTYPER112_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(11),  HAFGRTR, AMEVTYPER111_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(10),  HAFGRTR, AMEVTYPER110_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(9),   HAFGRTR, AMEVTYPER19_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(8),   HAFGRTR, AMEVTYPER18_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(7),   HAFGRTR, AMEVTYPER17_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(6),   HAFGRTR, AMEVTYPER16_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(5),   HAFGRTR, AMEVTYPER15_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(4),   HAFGRTR, AMEVTYPER14_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(3),   HAFGRTR, AMEVTYPER13_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(2),   HAFGRTR, AMEVTYPER12_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(1),   HAFGRTR, AMEVTYPER11_EL0, 1),
> +       SR_FGT(SYS_AMEVTYPER1_EL0(0),   HAFGRTR, AMEVTYPER10_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(15),   HAFGRTR, AMEVCNTR115_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(14),   HAFGRTR, AMEVCNTR114_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(13),   HAFGRTR, AMEVCNTR113_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(12),   HAFGRTR, AMEVCNTR112_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(11),   HAFGRTR, AMEVCNTR111_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(10),   HAFGRTR, AMEVCNTR110_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(9),    HAFGRTR, AMEVCNTR19_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(8),    HAFGRTR, AMEVCNTR18_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(7),    HAFGRTR, AMEVCNTR17_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(6),    HAFGRTR, AMEVCNTR16_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(5),    HAFGRTR, AMEVCNTR15_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(4),    HAFGRTR, AMEVCNTR14_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(3),    HAFGRTR, AMEVCNTR13_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(2),    HAFGRTR, AMEVCNTR12_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(1),    HAFGRTR, AMEVCNTR11_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR1_EL0(0),    HAFGRTR, AMEVCNTR10_EL0, 1),
> +       SR_FGT(SYS_AMCNTENCLR1_EL0,     HAFGRTR, AMCNTEN1, 1),
> +       SR_FGT(SYS_AMCNTENSET1_EL0,     HAFGRTR, AMCNTEN1, 1),
> +       SR_FGT(SYS_AMCNTENCLR0_EL0,     HAFGRTR, AMCNTEN0, 1),
> +       SR_FGT(SYS_AMCNTENSET0_EL0,     HAFGRTR, AMCNTEN0, 1),
> +       SR_FGT(SYS_AMEVCNTR0_EL0(3),    HAFGRTR, AMEVCNTR03_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR0_EL0(2),    HAFGRTR, AMEVCNTR02_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR0_EL0(1),    HAFGRTR, AMEVCNTR01_EL0, 1),
> +       SR_FGT(SYS_AMEVCNTR0_EL0(0),    HAFGRTR, AMEVCNTR00_EL0, 1),
>  };
>
>  static union trap_config get_trap_config(u32 sysreg)
> @@ -1909,6 +1953,10 @@ bool __check_nv_sr_forward(struct kvm_vcpu *vcpu)
>                         val = sanitised_sys_reg(vcpu, HDFGWTR_EL2);
>                 break;
>
> +       case HAFGRTR_GROUP:
> +               val = sanitised_sys_reg(vcpu, HAFGRTR_EL2);
> +               break;
> +
>         case HFGITR_GROUP:
>                 val = sanitised_sys_reg(vcpu, HFGITR_EL2);
>                 switch (tc.fgf) {
> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index 7b4909dfd1f5..22f3b916f60c 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -156,6 +156,17 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
>
>         write_sysreg_s(r_val, SYS_HDFGRTR_EL2);
>         write_sysreg_s(w_val, SYS_HDFGWTR_EL2);
> +
> +       ctxt_sys_reg(hctxt, HAFGRTR_EL2) = read_sysreg_s(SYS_HAFGRTR_EL2);
> +
> +       r_clr = r_set = 0;
> +       compute_clr_set(vcpu, HAFGRTR_EL2, r_clr, r_set);
> +
> +       r_val = __HAFGRTR_EL2_nMASK;
> +       r_val |= r_set;
> +       r_val &= ~r_clr;
> +
> +       write_sysreg_s(r_val, SYS_HAFGRTR_EL2);
>  }
>
>  static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
> @@ -174,6 +185,7 @@ static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
>         write_sysreg_s(ctxt_sys_reg(hctxt, HFGITR_EL2), SYS_HFGITR_EL2);
>         write_sysreg_s(ctxt_sys_reg(hctxt, HDFGRTR_EL2), SYS_HDFGRTR_EL2);
>         write_sysreg_s(ctxt_sys_reg(hctxt, HDFGWTR_EL2), SYS_HDFGWTR_EL2);
> +       write_sysreg_s(ctxt_sys_reg(hctxt, HAFGRTR_EL2), SYS_HAFGRTR_EL2);
>  }
>
>  static inline void __activate_traps_common(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 4735e1b37fb3..8bb297a2df38 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2532,6 +2532,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>         { SYS_DESC(SYS_DACR32_EL2), trap_undef, reset_unknown, DACR32_EL2 },
>         EL2_REG(HDFGRTR_EL2, access_rw, reset_val, 0),
>         EL2_REG(HDFGWTR_EL2, access_rw, reset_val, 0),
> +       EL2_REG(HAFGRTR_EL2, access_rw, reset_val, 0),
>         EL2_REG(SPSR_EL2, access_rw, reset_val, 0),
>         EL2_REG(ELR_EL2, access_rw, reset_val, 0),
>         { SYS_DESC(SYS_SP_EL1), access_sp_el1},
> --
> 2.43.0.472.g3155946c3a-goog
>


From tabba at google.com  Fri Dec 15 05:45:53 2023
From: tabba at google.com (Fuad Tabba)
Date: Fri, 15 Dec 2023 13:45:53 +0000
Subject: [PATCH v3 14/17] KVM: arm64: Macros for setting/clearing FGT bits
In-Reply-To: <20231214100158.2305400-15-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com> <20231214100158.2305400-15-tabba@google.com>
Message-ID: <CA+EHjTw_728zgVqF6_UraP0CwvmvFH0WiYCbyN-gvNMNk8QMBQ@mail.gmail.com>

Hi,

On Thu, Dec 14, 2023 at 10:02?AM Fuad Tabba <tabba at google.com> wrote:
>
> There's a lot of boilerplate code for setting and clearing FGT
> bits when activating guest traps. Refactor it into macros. These
> macros will also be used in future patch series.
>
> No functional change intended.
>
> Signed-off-by: Fuad Tabba <tabba at google.com>

And in relation to my email in "PATCH v3 09/17" [*] on HAFGRTR_EL2
being present only when FEAT_AMUv1 is implemented and FEAT_FGT:

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h
b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 58e450180f68..071d6db299f5 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -174,7 +174,9 @@ static inline void __activate_traps_hfgxtr(struct
kvm_vcpu *vcpu)
        update_fgt_traps(HFGITR_EL2);
        update_fgt_traps(HDFGRTR_EL2);
        update_fgt_traps(HDFGWTR_EL2);
-       update_fgt_traps(HAFGRTR_EL2);
+
+       if (cpu_has_amu())
+               update_fgt_traps(HAFGRTR_EL2);
 }

 static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)

* https://lore.kernel.org/all/CA+EHjTwrcXjOdo7JG-6fr0YpDq2EtMoTQxngq5H-ELLdjyQG=A at mail.gmail.com/

Cheers,
/fuad





> ---
>  arch/arm64/kvm/hyp/include/hyp/switch.h | 60 +++++++++----------------
>  1 file changed, 21 insertions(+), 39 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index 17ce40f5b006..e223fc0d5193 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -79,6 +79,23 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
>                 clr |= ~hfg & __ ## reg ## _nMASK;                      \
>         } while(0)
>
> +#define update_fgt_traps_cs(reg, clr, set)                             \
> +       do {                                                            \
> +               struct kvm_cpu_context *hctxt =                         \
> +                       &this_cpu_ptr(&kvm_host_data)->host_ctxt;       \
> +               u64 val, c = 0, s = 0;                                  \
> +                                                                       \
> +               ctxt_sys_reg(hctxt, reg) = read_sysreg_s(SYS_ ## reg);  \
> +               compute_clr_set(vcpu, reg, c, s);                       \
> +               val = __ ## reg ## _nMASK;                              \
> +               val |= (s | set);                                       \
> +               val &= ~(c | clr);                                      \
> +               write_sysreg_s(val, SYS_ ## reg);                       \
> +       } while(0)
> +
> +#define update_fgt_traps(reg)                                          \
> +       update_fgt_traps_cs(reg, 0, 0)
> +
>  /*
>   * Validate the fine grain trap masks.
>   * Check that the masks do not overlap and that all bits are accounted for.
> @@ -146,45 +163,10 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
>         if (!vcpu_has_nv(vcpu) || is_hyp_ctxt(vcpu))
>                 return;
>
> -       ctxt_sys_reg(hctxt, HFGITR_EL2) = read_sysreg_s(SYS_HFGITR_EL2);
> -
> -       r_set = r_clr = 0;
> -       compute_clr_set(vcpu, HFGITR_EL2, r_clr, r_set);
> -       r_val = __HFGITR_EL2_nMASK;
> -       r_val |= r_set;
> -       r_val &= ~r_clr;
> -
> -       write_sysreg_s(r_val, SYS_HFGITR_EL2);
> -
> -       ctxt_sys_reg(hctxt, HDFGRTR_EL2) = read_sysreg_s(SYS_HDFGRTR_EL2);
> -       ctxt_sys_reg(hctxt, HDFGWTR_EL2) = read_sysreg_s(SYS_HDFGWTR_EL2);
> -
> -       r_clr = r_set = w_clr = w_set = 0;
> -
> -       compute_clr_set(vcpu, HDFGRTR_EL2, r_clr, r_set);
> -       compute_clr_set(vcpu, HDFGWTR_EL2, w_clr, w_set);
> -
> -       r_val = __HDFGRTR_EL2_nMASK;
> -       r_val |= r_set;
> -       r_val &= ~r_clr;
> -
> -       w_val = __HDFGWTR_EL2_nMASK;
> -       w_val |= w_set;
> -       w_val &= ~w_clr;
> -
> -       write_sysreg_s(r_val, SYS_HDFGRTR_EL2);
> -       write_sysreg_s(w_val, SYS_HDFGWTR_EL2);
> -
> -       ctxt_sys_reg(hctxt, HAFGRTR_EL2) = read_sysreg_s(SYS_HAFGRTR_EL2);
> -
> -       r_clr = r_set = 0;
> -       compute_clr_set(vcpu, HAFGRTR_EL2, r_clr, r_set);
> -
> -       r_val = __HAFGRTR_EL2_nMASK;
> -       r_val |= r_set;
> -       r_val &= ~r_clr;
> -
> -       write_sysreg_s(r_val, SYS_HAFGRTR_EL2);
> +       update_fgt_traps(HFGITR_EL2);
> +       update_fgt_traps(HDFGRTR_EL2);
> +       update_fgt_traps(HDFGWTR_EL2);
> +       update_fgt_traps(HAFGRTR_EL2);
>  }
>
>  static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
> --
> 2.43.0.472.g3155946c3a-goog
>


From johan at kernel.org  Fri Dec 15 05:51:09 2023
From: johan at kernel.org (Johan Hovold)
Date: Fri, 15 Dec 2023 14:51:09 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <20231214170146.641783-1-francesco@dolcini.it>
References: <20231214170146.641783-1-francesco@dolcini.it>
Message-ID: <ZXxZzd1iBOCmnczH@hovoldconsulting.com>

On Thu, Dec 14, 2023 at 06:01:46PM +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> receive_buf() is called from ttyport_receive_buf() that expects values
> ">= 0" from serdev_controller_receive_buf(), change its return type from
> ssize_t to size_t.
> 
> Suggested-by: Jiri Slaby <jirislaby at kernel.org>
> Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
> Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> ---
> hello,
> patch is based on current linux next.
> 
> It has an obvious problem, it touches files from multiple subsystem in a single
> patch that is complicated to review and eventually merge, just splitting this
> would however not work, it will break bisectability and the build.
> 
> I am looking for advise on the best way to move forward.
> 
> I see the following options:
>  - keep it as it is
>  - break it down with a patch with each subsystem, and squash before applying
>    from a single (tty?) subsystem
>  - go for a multi stage approach, defining a new callback, move to it and in
>    the end remove the original one, likewise it was done for i2c lately
> 
> ---
>  drivers/bluetooth/btmtkuart.c              |  4 ++--
>  drivers/bluetooth/btnxpuart.c              |  4 ++--

> diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
> index 3c84fcbda01a..e6bc4a73c9fc 100644
> --- a/drivers/bluetooth/btmtkuart.c
> +++ b/drivers/bluetooth/btmtkuart.c
> @@ -383,8 +383,8 @@ static void btmtkuart_recv(struct hci_dev *hdev, const u8 *data, size_t count)
>  	}
>  }
>  
> -static ssize_t btmtkuart_receive_buf(struct serdev_device *serdev,
> -				     const u8 *data, size_t count)
> +static size_t btmtkuart_receive_buf(struct serdev_device *serdev,
> +				    const u8 *data, size_t count)
>  {
>  	struct btmtkuart_dev *bdev = serdev_device_get_drvdata(serdev);
>  
> diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> index 1d592ac413d1..056bef5b2919 100644
> --- a/drivers/bluetooth/btnxpuart.c
> +++ b/drivers/bluetooth/btnxpuart.c
> @@ -1264,8 +1264,8 @@ static const struct h4_recv_pkt nxp_recv_pkts[] = {
>  	{ NXP_RECV_FW_REQ_V3,   .recv = nxp_recv_fw_req_v3 },
>  };
>  
> -static ssize_t btnxpuart_receive_buf(struct serdev_device *serdev,
> -				     const u8 *data, size_t count)
> +static size_t btnxpuart_receive_buf(struct serdev_device *serdev,
> +				    const u8 *data, size_t count)
>  {
>  	struct btnxpuart_dev *nxpdev = serdev_device_get_drvdata(serdev);

A quick check of just the first two functions here shows that they can
return negative values.

> diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
> index e94e090cf0a1..3d7ae7fa5018 100644
> --- a/drivers/tty/serdev/serdev-ttyport.c
> +++ b/drivers/tty/serdev/serdev-ttyport.c
> @@ -27,19 +27,17 @@ static size_t ttyport_receive_buf(struct tty_port *port, const u8 *cp,
>  {
>  	struct serdev_controller *ctrl = port->client_data;
>  	struct serport *serport = serdev_controller_get_drvdata(ctrl);
> -	int ret;
> +	size_t ret;
>  
>  	if (!test_bit(SERPORT_ACTIVE, &serport->flags))
>  		return 0;
>  
>  	ret = serdev_controller_receive_buf(ctrl, cp, count);
>  
> -	dev_WARN_ONCE(&ctrl->dev, ret < 0 || ret > count,
> -				"receive_buf returns %d (count = %zu)\n",
> +	dev_WARN_ONCE(&ctrl->dev, ret > count,
> +				"receive_buf returns %zu (count = %zu)\n",
>  				ret, count);
> -	if (ret < 0)
> -		return 0;
> -	else if (ret > count)
> +	if (ret > count)
>  		return count;
>  
>  	return ret;

So please do not apply this patch until the various implementations have
been fixed.

Johan


From efectn at 6tel.net  Fri Dec 15 05:55:20 2023
From: efectn at 6tel.net (efectn at 6tel.net)
Date: Fri, 15 Dec 2023 16:55:20 +0300
Subject: [PATCH 0/3] Add Support for NanoPi R6S and R6C boards
Message-ID: <cover.1702647349.git.efectn@protonmail.com>

From: Muhammed Efe Cetin <efectn at protonmail.com>

Hi, this series add support for RK3588S based NanoPi R6S and R6C boards.

Muhammed Efe Cetin (3):
  dt-bindings: arm: rockchip: Add NanoPi R6 series boards
  arm64: dts: rockchip: Add support for NanoPi R6S
  arm64: dts: rockchip: Add support for NanoPi R6C

 .../devicetree/bindings/arm/rockchip.yaml     |   7 +
 arch/arm64/boot/dts/rockchip/Makefile         |   2 +
 .../boot/dts/rockchip/rk3588s-nanopi-r6c.dts  |  14 +
 .../boot/dts/rockchip/rk3588s-nanopi-r6s.dts  | 755 ++++++++++++++++++
 4 files changed, 778 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts

-- 
2.43.0



From efectn at 6tel.net  Fri Dec 15 05:55:21 2023
From: efectn at 6tel.net (efectn at 6tel.net)
Date: Fri, 15 Dec 2023 16:55:21 +0300
Subject: [PATCH 1/3] dt-bindings: arm: rockchip: Add NanoPi R6 series boards
In-Reply-To: <cover.1702647349.git.efectn@protonmail.com>
References: <cover.1702647349.git.efectn@protonmail.com>
Message-ID: <b74f5b91693d9b1ec525fb22e06c0a8311c7cf05.1702647349.git.efectn@protonmail.com>

From: Muhammed Efe Cetin <efectn at protonmail.com>

Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ee92f0535..07c4eb828 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -225,6 +225,13 @@ properties:
               - friendlyarm,nanopi-r5s
           - const: rockchip,rk3568
 
+      - description: FriendlyElec NanoPi R6 series boards
+        items:
+          - enum:
+              - friendlyarm,nanopi-r6c
+              - friendlyarm,nanopi-r6s
+          - const: rockchip,rk3588s
+
       - description: FriendlyElec NanoPC T6
         items:
           - const: friendlyarm,nanopc-t6
-- 
2.43.0



From efectn at 6tel.net  Fri Dec 15 05:55:23 2023
From: efectn at 6tel.net (efectn at 6tel.net)
Date: Fri, 15 Dec 2023 16:55:23 +0300
Subject: [PATCH 3/3] arm64: dts: rockchip: Add support for NanoPi R6C
In-Reply-To: <cover.1702647349.git.efectn@protonmail.com>
References: <cover.1702647349.git.efectn@protonmail.com>
Message-ID: <923b4d9bb60fecd080e7c348ec0d4630392eb091.1702647349.git.efectn@protonmail.com>

From: Muhammed Efe Cetin <efectn at protonmail.com>

NanoPi R6C is mostly same as R6S variant. It has M2 port instead of a
NIC port and different led labeling.

Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
---
 arch/arm64/boot/dts/rockchip/Makefile              |  3 ++-
 .../arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts | 14 ++++++++++++++
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index ed2583dcd..261505081 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -114,4 +114,5 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
-dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
\ No newline at end of file
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
new file mode 100644
index 000000000..8031098c3
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588s-nanopi-r6s.dts"
+
+/ {
+	model = "FriendlyElec NanoPi R6C";
+	compatible = "friendlyelec,nanopi-r6c", "rockchip,rk3588s";
+};
+
+&lan2_led {
+	label = "user_led";
+};
-- 
2.43.0



From francesco at dolcini.it  Fri Dec 15 05:55:59 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri, 15 Dec 2023 14:55:59 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <ZXxWX-Fw1InID2ax@hovoldconsulting.com>
References: <20231214170146.641783-1-francesco@dolcini.it>
 <ZXxWX-Fw1InID2ax@hovoldconsulting.com>
Message-ID: <ZXxa7yzKzG6048vw@francesco-nb.int.toradex.com>

Hello Johan,

On Fri, Dec 15, 2023 at 02:36:31PM +0100, Johan Hovold wrote:
> On Thu, Dec 14, 2023 at 06:01:46PM +0100, Francesco Dolcini wrote:
> > From: Francesco Dolcini <francesco.dolcini at toradex.com>
> > 
> > receive_buf() is called from ttyport_receive_buf() that expects values
> > ">= 0" from serdev_controller_receive_buf(), change its return type from
> > ssize_t to size_t.
> > 
> > Suggested-by: Jiri Slaby <jirislaby at kernel.org>
> > Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
> > Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> > ---
> >  drivers/gnss/core.c                        |  6 +++---
> >  drivers/gnss/serial.c                      |  4 ++--
> >  drivers/gnss/sirf.c                        |  6 +++---
> 
> > diff --git a/drivers/gnss/core.c b/drivers/gnss/core.c
> > index 48f2ee0f78c4..9b8a0605ec76 100644
> > --- a/drivers/gnss/core.c
> > +++ b/drivers/gnss/core.c
> > @@ -317,10 +317,10 @@ EXPORT_SYMBOL_GPL(gnss_deregister_device);
> >   *
> >   * Must not be called for a closed device.
> >   */
> > -int gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> > -				size_t count)
> > +size_t gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> > +		       size_t count)
> >  {
> > -	int ret;
> > +	size_t ret;
> >  
> >  	ret = kfifo_in(&gdev->read_fifo, buf, count);
> >  
> 
> Why are you changing this function? This is part of the GNSS interface
> and has nothing to do with the rest of this patch.

good point, thanks for looking into that.

from my understanding kfifo_in() already return an unsigned, both
__kfifo_in and __kfifo_in_r return unsigned.

With that said this is used by 3 drivers:

= drivers/gnss/sirf.c:
= drivers/gnss/serial.c:

The driver just use it into the actual receive_buf callback.

= drivers/gnss/usb.c

This driver does nothing with a negative return value (that is never the
less not possible), it just check that the whole buffer was inserted.

To me the change is correct, with that said probably this should have
been explicitly mentioned in the commit message or a separate
preparation patch.

Francesco



From efectn at 6tel.net  Fri Dec 15 05:55:22 2023
From: efectn at 6tel.net (efectn at 6tel.net)
Date: Fri, 15 Dec 2023 16:55:22 +0300
Subject: [PATCH 2/3] arm64: dts: rockchip: Add support for NanoPi R6S
In-Reply-To: <cover.1702647349.git.efectn@protonmail.com>
References: <cover.1702647349.git.efectn@protonmail.com>
Message-ID: <25d84712ee3765f5f28dfd355a2392f20f388824.1702647349.git.efectn@protonmail.com>

From: Muhammed Efe Cetin <efectn at protonmail.com>

Add basic NanoPi R6S support that comes with USB2, PCIe, SD card, eMMC
support.

Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3588s-nanopi-r6s.dts  | 755 ++++++++++++++++++
 2 files changed, 756 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 600c420bc..ed2583dcd 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -114,3 +114,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
new file mode 100644
index 000000000..e575cc403
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
@@ -0,0 +1,755 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "rk3588s.dtsi"
+
+/ {
+	model = "FriendlyElec NanoPi R6S";
+	compatible = "friendlyelec,nanopi-r6s", "rockchip,rk3588s";
+
+	aliases {
+		ethernet0 = &gmac1;
+		mmc0 = &sdmmc;
+		mmc1 = &sdhci;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-maskrom {
+			label = "Maskrom";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <1800>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&key1_pin>;
+
+		button-user {
+			label = "User";
+			linux,code = <BTN_1>;
+			gpios = <&gpio1 RK_PC0 GPIO_ACTIVE_LOW>;
+			debounce-interval = <50>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		sys_led: led-0 {
+			label = "sys_led";
+			gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+			pinctrl-names = "default";
+			pinctrl-0 = <&sys_led_pin>;
+		};
+
+		wan_led: led-1 {
+			label = "wan_led";
+			gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&wan_led_pin>;
+		};
+
+		lan1_led: led-2 {
+			label = "lan1_led";
+			gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&lan1_led_pin>;
+		};
+
+		lan2_led: led-3 {
+			label = "lan2_led";
+			gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&lan2_led_pin>;
+		};
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+	};
+
+	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_3v3_sd_s0: vcc-3v3-sd-s0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sd_s0_pwr>;
+		regulator-name = "vcc_3v3_sd_s0";
+		regulator-boot-on;
+		regulator-max-microvolt = <3000000>;
+		regulator-min-microvolt = <3000000>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc_3v3_pcie20: vcc3v3-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3_pcie20";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_usb_otg0: vcc5v0-usb-otg0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio1 RK_PD2 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&typec5v_pwren>;
+		regulator-name = "vcc5v0_usb_otg0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usb>;
+	};
+
+	vcc5v0_host_20: vcc5v0-host-20-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host20_en>;
+		regulator-name = "vcc5v0_host_20";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usb>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy1>;
+	phy-mode = "rgmii-rxid";
+	pinctrl-0 = <&gmac1_miim
+		     &gmac1_tx_bus2
+		     &gmac1_rx_bus2
+		     &gmac1_rgmii_clk
+		     &gmac1_rgmii_bus>;
+	pinctrl-names = "default";
+	tx_delay = <0x42>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: rk8602 at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-compatible = "rk860x-reg";
+		regulator-name = "vdd_npu_s0";
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		regulator-boot-on;
+		regulator-always-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c6 {
+	clock-frequency = <200000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c6m0_xfer>;
+	status = "okay";
+
+	hym8563: rtc at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtc_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+		wakeup-source;
+	};
+};
+
+&mdio1 {
+	rgmii_phy1: ethernet-phy at 1 {
+		compatible = "ethernet-phy-id001c.c916";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtl8211f_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pcie2x1l1 {
+	reset-gpios = <&gpio1 RK_PA7 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc_3v3_pcie20>;
+	status = "okay";
+};
+
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc_3v3_pcie20>;
+	status = "okay";
+};
+
+&pinctrl {
+	gpio-key {
+		key1_pin: key1-pin {
+			rockchip,pins = <1 RK_PC0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	gpio-leds {
+		sys_led_pin: sys-led-pin {
+			rockchip,pins =
+				<1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wan_led_pin: wan-led-pin {
+			rockchip,pins =
+				<1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		lan1_led_pin: lan1-led-pin {
+			rockchip,pins =
+				<1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		lan2_led_pin: lan2-led-pin {
+			rockchip,pins =
+				<1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	hym8563 {
+		rtc_int: rtc-int {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sdmmc {
+		sd_s0_pwr: sd-s0-pwr {
+			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb {
+		typec5v_pwren: typec5v-pwren {
+			rockchip,pins = <1 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		vcc5v0_host20_en: vcc5v0-host20-en {
+			rockchip,pins = <4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	rtl8211f {
+		rtl8211f_rst: rtl8211f-rst {
+			rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&saradc {
+	vref-supply = <&avcc_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	mmc-hs200-1_8v;
+	max-frequency = <200000000>;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	disable-wp;
+	max-frequency = <150000000>;
+	no-mmc;
+	no-sdio;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_sd_s0>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	status = "okay";
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	num-cs = <1>;
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		spi-max-frequency = <1000000>;
+		reg = <0x0>;
+
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fudr_moden0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_lit_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_log_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-init-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_vdenc_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vdd2_ddr_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_2v0_pldo_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vddq_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "avcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "avdd_1v2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3_s0: pldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vcc_3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vccio_sd_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "pldo6_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_ddr_pll_s0: nldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_ddr_pll_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "avdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v85_s0: nldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdd_0v85_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_host_20>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:03 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:03 +0100
Subject: [PATCH 03/18] perf: arm-cci: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <70b581d58cfffdccb9fb3ed17bf3220c00f8033f.1702648124.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/arm-cci.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
index 61de861eaf91..6be03f81ae5d 100644
--- a/drivers/perf/arm-cci.c
+++ b/drivers/perf/arm-cci.c
@@ -1697,16 +1697,14 @@ static int cci_pmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int cci_pmu_remove(struct platform_device *pdev)
+static void cci_pmu_remove(struct platform_device *pdev)
 {
 	if (!g_cci_pmu)
-		return 0;
+		return;
 
 	cpuhp_remove_state(CPUHP_AP_PERF_ARM_CCI_ONLINE);
 	perf_pmu_unregister(&g_cci_pmu->pmu);
 	g_cci_pmu = NULL;
-
-	return 0;
 }
 
 static struct platform_driver cci_pmu_driver = {
@@ -1716,7 +1714,7 @@ static struct platform_driver cci_pmu_driver = {
 		   .suppress_bind_attrs = true,
 		  },
 	.probe = cci_pmu_probe,
-	.remove = cci_pmu_remove,
+	.remove_new = cci_pmu_remove,
 };
 
 module_platform_driver(cci_pmu_driver);
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:04 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:04 +0100
Subject: [PATCH 04/18] perf: arm-ccn: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <1cae5f0c4693333c91d28a09388bdb8bfcc25d0b.1702648124.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/arm-ccn.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/arm-ccn.c b/drivers/perf/arm-ccn.c
index 728d13d8e98a..641471bd5eff 100644
--- a/drivers/perf/arm-ccn.c
+++ b/drivers/perf/arm-ccn.c
@@ -1515,13 +1515,11 @@ static int arm_ccn_probe(struct platform_device *pdev)
 	return arm_ccn_pmu_init(ccn);
 }
 
-static int arm_ccn_remove(struct platform_device *pdev)
+static void arm_ccn_remove(struct platform_device *pdev)
 {
 	struct arm_ccn *ccn = platform_get_drvdata(pdev);
 
 	arm_ccn_pmu_cleanup(ccn);
-
-	return 0;
 }
 
 static const struct of_device_id arm_ccn_match[] = {
@@ -1539,7 +1537,7 @@ static struct platform_driver arm_ccn_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = arm_ccn_probe,
-	.remove = arm_ccn_remove,
+	.remove_new = arm_ccn_remove,
 };
 
 static int __init arm_ccn_init(void)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:05 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:05 +0100
Subject: [PATCH 05/18] perf: arm-cmn: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <8698ca612e17292f8a8bbb2d1c0f6be4b2053da7.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/arm-cmn.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index c584165b13ba..ac7a953fe902 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -2504,7 +2504,7 @@ static int arm_cmn_probe(struct platform_device *pdev)
 	return err;
 }
 
-static int arm_cmn_remove(struct platform_device *pdev)
+static void arm_cmn_remove(struct platform_device *pdev)
 {
 	struct arm_cmn *cmn = platform_get_drvdata(pdev);
 
@@ -2513,7 +2513,6 @@ static int arm_cmn_remove(struct platform_device *pdev)
 	perf_pmu_unregister(&cmn->pmu);
 	cpuhp_state_remove_instance_nocalls(arm_cmn_hp_state, &cmn->cpuhp_node);
 	debugfs_remove(cmn->debug);
-	return 0;
 }
 
 #ifdef CONFIG_OF
@@ -2544,7 +2543,7 @@ static struct platform_driver arm_cmn_driver = {
 		.acpi_match_table = ACPI_PTR(arm_cmn_acpi_match),
 	},
 	.probe = arm_cmn_probe,
-	.remove = arm_cmn_remove,
+	.remove_new = arm_cmn_remove,
 };
 
 static int __init arm_cmn_init(void)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:07 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:07 +0100
Subject: [PATCH 07/18] perf: arm_dmc620: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <20cc24ede88f5e000991dfe6f4cf1222b819e337.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/arm_dmc620_pmu.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/arm_dmc620_pmu.c b/drivers/perf/arm_dmc620_pmu.c
index 30cea6859574..8a81be2dd5ec 100644
--- a/drivers/perf/arm_dmc620_pmu.c
+++ b/drivers/perf/arm_dmc620_pmu.c
@@ -724,7 +724,7 @@ static int dmc620_pmu_device_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int dmc620_pmu_device_remove(struct platform_device *pdev)
+static void dmc620_pmu_device_remove(struct platform_device *pdev)
 {
 	struct dmc620_pmu *dmc620_pmu = platform_get_drvdata(pdev);
 
@@ -732,8 +732,6 @@ static int dmc620_pmu_device_remove(struct platform_device *pdev)
 
 	/* perf will synchronise RCU before devres can free dmc620_pmu */
 	perf_pmu_unregister(&dmc620_pmu->pmu);
-
-	return 0;
 }
 
 static const struct acpi_device_id dmc620_acpi_match[] = {
@@ -748,7 +746,7 @@ static struct platform_driver dmc620_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe	= dmc620_pmu_device_probe,
-	.remove	= dmc620_pmu_device_remove,
+	.remove_new = dmc620_pmu_device_remove,
 };
 
 static int __init dmc620_pmu_init(void)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:08 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:08 +0100
Subject: [PATCH 08/18] perf: arm_dsu: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <1eda5e216afcb0e26a50e9be112d4514ffd0844a.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/arm_dsu_pmu.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
index 7ec4498e312f..bae3ca37f846 100644
--- a/drivers/perf/arm_dsu_pmu.c
+++ b/drivers/perf/arm_dsu_pmu.c
@@ -774,14 +774,12 @@ static int dsu_pmu_device_probe(struct platform_device *pdev)
 	return rc;
 }
 
-static int dsu_pmu_device_remove(struct platform_device *pdev)
+static void dsu_pmu_device_remove(struct platform_device *pdev)
 {
 	struct dsu_pmu *dsu_pmu = platform_get_drvdata(pdev);
 
 	perf_pmu_unregister(&dsu_pmu->pmu);
 	cpuhp_state_remove_instance(dsu_pmu_cpuhp_state, &dsu_pmu->cpuhp_node);
-
-	return 0;
 }
 
 static const struct of_device_id dsu_pmu_of_match[] = {
@@ -806,7 +804,7 @@ static struct platform_driver dsu_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = dsu_pmu_device_probe,
-	.remove = dsu_pmu_device_remove,
+	.remove_new = dsu_pmu_device_remove,
 };
 
 static int dsu_pmu_cpu_online(unsigned int cpu, struct hlist_node *node)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:09 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:09 +0100
Subject: [PATCH 09/18] perf: arm_smmuv3: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <23bfd1a73ce819ffce6137c237608684a3cdfda6.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/arm_smmuv3_pmu.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 6303b82566f9..af3ab3eb944e 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -965,14 +965,12 @@ static int smmu_pmu_probe(struct platform_device *pdev)
 	return err;
 }
 
-static int smmu_pmu_remove(struct platform_device *pdev)
+static void smmu_pmu_remove(struct platform_device *pdev)
 {
 	struct smmu_pmu *smmu_pmu = platform_get_drvdata(pdev);
 
 	perf_pmu_unregister(&smmu_pmu->pmu);
 	cpuhp_state_remove_instance_nocalls(cpuhp_state_num, &smmu_pmu->node);
-
-	return 0;
 }
 
 static void smmu_pmu_shutdown(struct platform_device *pdev)
@@ -997,7 +995,7 @@ static struct platform_driver smmu_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = smmu_pmu_probe,
-	.remove = smmu_pmu_remove,
+	.remove_new = smmu_pmu_remove,
 	.shutdown = smmu_pmu_shutdown,
 };
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:10 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:10 +0100
Subject: [PATCH 10/18] perf: arm_spe: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <abfedc224eca7f4960b7ddfb6daedd47a3699ca5.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/arm_spe_pmu.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index b622d75d8c9e..35f0de03416f 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -1263,14 +1263,13 @@ static int arm_spe_pmu_device_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int arm_spe_pmu_device_remove(struct platform_device *pdev)
+static void arm_spe_pmu_device_remove(struct platform_device *pdev)
 {
 	struct arm_spe_pmu *spe_pmu = platform_get_drvdata(pdev);
 
 	arm_spe_pmu_perf_destroy(spe_pmu);
 	arm_spe_pmu_dev_teardown(spe_pmu);
 	free_percpu(spe_pmu->handle);
-	return 0;
 }
 
 static struct platform_driver arm_spe_pmu_driver = {
@@ -1281,7 +1280,7 @@ static struct platform_driver arm_spe_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe	= arm_spe_pmu_device_probe,
-	.remove	= arm_spe_pmu_device_remove,
+	.remove_new = arm_spe_pmu_device_remove,
 };
 
 static int __init arm_spe_pmu_init(void)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:01 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:01 +0100
Subject: [PATCH 01/18] perf: alibaba_uncore_drw: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e6dd47f791ddcc4cc6f7a80efcede245528220e6.1702648124.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/alibaba_uncore_drw_pmu.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_uncore_drw_pmu.c
index 19d459a36be5..a9277dcf90ce 100644
--- a/drivers/perf/alibaba_uncore_drw_pmu.c
+++ b/drivers/perf/alibaba_uncore_drw_pmu.c
@@ -729,7 +729,7 @@ static int ali_drw_pmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int ali_drw_pmu_remove(struct platform_device *pdev)
+static void ali_drw_pmu_remove(struct platform_device *pdev)
 {
 	struct ali_drw_pmu *drw_pmu = platform_get_drvdata(pdev);
 
@@ -739,8 +739,6 @@ static int ali_drw_pmu_remove(struct platform_device *pdev)
 
 	ali_drw_pmu_uninit_irq(drw_pmu);
 	perf_pmu_unregister(&drw_pmu->pmu);
-
-	return 0;
 }
 
 static int ali_drw_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
@@ -795,7 +793,7 @@ static struct platform_driver ali_drw_pmu_driver = {
 		   .acpi_match_table = ali_drw_acpi_match,
 		   },
 	.probe = ali_drw_pmu_probe,
-	.remove = ali_drw_pmu_remove,
+	.remove_new = ali_drw_pmu_remove,
 };
 
 static int __init ali_drw_pmu_init(void)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:14 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:14 +0100
Subject: [PATCH 14/18] perf: marvell_cn10k_ddr: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <79f48409f663f0184f03d34c6a86359ea3aa1291.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/marvell_cn10k_ddr_pmu.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/perf/marvell_cn10k_ddr_pmu.c b/drivers/perf/marvell_cn10k_ddr_pmu.c
index 524ba82bfce2..e2abca188dbe 100644
--- a/drivers/perf/marvell_cn10k_ddr_pmu.c
+++ b/drivers/perf/marvell_cn10k_ddr_pmu.c
@@ -697,7 +697,7 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int cn10k_ddr_perf_remove(struct platform_device *pdev)
+static void cn10k_ddr_perf_remove(struct platform_device *pdev)
 {
 	struct cn10k_ddr_pmu *ddr_pmu = platform_get_drvdata(pdev);
 
@@ -706,7 +706,6 @@ static int cn10k_ddr_perf_remove(struct platform_device *pdev)
 				&ddr_pmu->node);
 
 	perf_pmu_unregister(&ddr_pmu->pmu);
-	return 0;
 }
 
 #ifdef CONFIG_OF
@@ -733,7 +732,7 @@ static struct platform_driver cn10k_ddr_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe		= cn10k_ddr_perf_probe,
-	.remove		= cn10k_ddr_perf_remove,
+	.remove_new	= cn10k_ddr_perf_remove,
 };
 
 static int __init cn10k_ddr_pmu_init(void)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:15 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:15 +0100
Subject: [PATCH 15/18] perf: marvell_cn10k_tad: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <055656e474208b0fb583e249530fa211fa3be57c.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/marvell_cn10k_tad_pmu.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/marvell_cn10k_tad_pmu.c b/drivers/perf/marvell_cn10k_tad_pmu.c
index fec8e82edb95..9e635f355470 100644
--- a/drivers/perf/marvell_cn10k_tad_pmu.c
+++ b/drivers/perf/marvell_cn10k_tad_pmu.c
@@ -351,15 +351,13 @@ static int tad_pmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int tad_pmu_remove(struct platform_device *pdev)
+static void tad_pmu_remove(struct platform_device *pdev)
 {
 	struct tad_pmu *pmu = platform_get_drvdata(pdev);
 
 	cpuhp_state_remove_instance_nocalls(tad_pmu_cpuhp_state,
 						&pmu->node);
 	perf_pmu_unregister(&pmu->pmu);
-
-	return 0;
 }
 
 #ifdef CONFIG_OF
@@ -385,7 +383,7 @@ static struct platform_driver tad_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe          = tad_pmu_probe,
-	.remove         = tad_pmu_remove,
+	.remove_new     = tad_pmu_remove,
 };
 
 static int tad_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:17 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:17 +0100
Subject: [PATCH 17/18] perf: thunderx2: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <7be677dfa13d3a7eab6eef0d808ba8a9855d14ae.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/thunderx2_pmu.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
index 1edb9c03704f..e16d10c763de 100644
--- a/drivers/perf/thunderx2_pmu.c
+++ b/drivers/perf/thunderx2_pmu.c
@@ -993,7 +993,7 @@ static int tx2_uncore_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int tx2_uncore_remove(struct platform_device *pdev)
+static void tx2_uncore_remove(struct platform_device *pdev)
 {
 	struct tx2_uncore_pmu *tx2_pmu, *temp;
 	struct device *dev = &pdev->dev;
@@ -1009,7 +1009,6 @@ static int tx2_uncore_remove(struct platform_device *pdev)
 			}
 		}
 	}
-	return 0;
 }
 
 static struct platform_driver tx2_uncore_driver = {
@@ -1019,7 +1018,7 @@ static struct platform_driver tx2_uncore_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = tx2_uncore_probe,
-	.remove = tx2_uncore_remove,
+	.remove_new = tx2_uncore_remove,
 };
 
 static int __init tx2_uncore_driver_init(void)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:06 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:06 +0100
Subject: [PATCH 06/18] perf: arm_cspmu: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <9ff5a467569dd51b2fc44e11594ad5db7ea15f57.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index 50b89b989ce7..3513bf50fefa 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -1252,14 +1252,12 @@ static int arm_cspmu_device_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int arm_cspmu_device_remove(struct platform_device *pdev)
+static void arm_cspmu_device_remove(struct platform_device *pdev)
 {
 	struct arm_cspmu *cspmu = platform_get_drvdata(pdev);
 
 	perf_pmu_unregister(&cspmu->pmu);
 	cpuhp_state_remove_instance(arm_cspmu_cpuhp_state, &cspmu->cpuhp_node);
-
-	return 0;
 }
 
 static const struct platform_device_id arm_cspmu_id[] = {
@@ -1274,7 +1272,7 @@ static struct platform_driver arm_cspmu_driver = {
 			.suppress_bind_attrs = true,
 		},
 	.probe = arm_cspmu_device_probe,
-	.remove = arm_cspmu_device_remove,
+	.remove_new = arm_cspmu_device_remove,
 	.id_table = arm_cspmu_id,
 };
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:11 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:11 +0100
Subject: [PATCH 11/18] perf: fsl_imx8_ddr: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <c5b76bf352385d8ef6211ee8c43352c74eee064d.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/fsl_imx8_ddr_perf.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index 7dbfaee372c7..4e8fa5a48fcf 100644
--- a/drivers/perf/fsl_imx8_ddr_perf.c
+++ b/drivers/perf/fsl_imx8_ddr_perf.c
@@ -826,7 +826,7 @@ static int ddr_perf_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int ddr_perf_remove(struct platform_device *pdev)
+static void ddr_perf_remove(struct platform_device *pdev)
 {
 	struct ddr_pmu *pmu = platform_get_drvdata(pdev);
 
@@ -836,7 +836,6 @@ static int ddr_perf_remove(struct platform_device *pdev)
 	perf_pmu_unregister(&pmu->pmu);
 
 	ida_free(&ddr_ida, pmu->id);
-	return 0;
 }
 
 static struct platform_driver imx_ddr_pmu_driver = {
@@ -846,7 +845,7 @@ static struct platform_driver imx_ddr_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe          = ddr_perf_probe,
-	.remove         = ddr_perf_remove,
+	.remove_new     = ddr_perf_remove,
 };
 
 module_platform_driver(imx_ddr_pmu_driver);
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:02 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:02 +0100
Subject: [PATCH 02/18] perf: amlogic: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <33dbadf246eb323edd9e09ac744111216c167a55.1702648124.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/amlogic/meson_g12_ddr_pmu.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/amlogic/meson_g12_ddr_pmu.c b/drivers/perf/amlogic/meson_g12_ddr_pmu.c
index 15d52ab3276a..99cc791892bc 100644
--- a/drivers/perf/amlogic/meson_g12_ddr_pmu.c
+++ b/drivers/perf/amlogic/meson_g12_ddr_pmu.c
@@ -355,11 +355,9 @@ static int g12_ddr_pmu_probe(struct platform_device *pdev)
 	return meson_ddr_pmu_create(pdev);
 }
 
-static int g12_ddr_pmu_remove(struct platform_device *pdev)
+static void g12_ddr_pmu_remove(struct platform_device *pdev)
 {
 	meson_ddr_pmu_remove(pdev);
-
-	return 0;
 }
 
 static const struct of_device_id meson_ddr_pmu_dt_match[] = {
@@ -381,7 +379,7 @@ MODULE_DEVICE_TABLE(of, meson_ddr_pmu_dt_match);
 
 static struct platform_driver g12_ddr_pmu_driver = {
 	.probe = g12_ddr_pmu_probe,
-	.remove = g12_ddr_pmu_remove,
+	.remove_new = g12_ddr_pmu_remove,
 
 	.driver = {
 		.name = "meson-g12-ddr-pmu",
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:12 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:12 +0100
Subject: [PATCH 12/18] perf: fsl_imx9_ddr: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <bd12035ca467d7f4cd5edcfd6febda56600caacd.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/fsl_imx9_ddr_perf.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/fsl_imx9_ddr_perf.c b/drivers/perf/fsl_imx9_ddr_perf.c
index 9685645bfe04..72c2d3074cde 100644
--- a/drivers/perf/fsl_imx9_ddr_perf.c
+++ b/drivers/perf/fsl_imx9_ddr_perf.c
@@ -679,7 +679,7 @@ static int ddr_perf_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int ddr_perf_remove(struct platform_device *pdev)
+static void ddr_perf_remove(struct platform_device *pdev)
 {
 	struct ddr_pmu *pmu = platform_get_drvdata(pdev);
 
@@ -689,8 +689,6 @@ static int ddr_perf_remove(struct platform_device *pdev)
 	perf_pmu_unregister(&pmu->pmu);
 
 	ida_free(&ddr_ida, pmu->id);
-
-	return 0;
 }
 
 static struct platform_driver imx_ddr_pmu_driver = {
@@ -700,7 +698,7 @@ static struct platform_driver imx_ddr_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe          = ddr_perf_probe,
-	.remove         = ddr_perf_remove,
+	.remove_new     = ddr_perf_remove,
 };
 module_platform_driver(imx_ddr_pmu_driver);
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:18 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:18 +0100
Subject: [PATCH 18/18] perf: xgene: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <75dda01b2ad6e17f726830094bd38cb8faab5cbe.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/xgene_pmu.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
index 7ce344248dda..0d49343d704b 100644
--- a/drivers/perf/xgene_pmu.c
+++ b/drivers/perf/xgene_pmu.c
@@ -1937,7 +1937,7 @@ xgene_pmu_dev_cleanup(struct xgene_pmu *xgene_pmu, struct list_head *pmus)
 	}
 }
 
-static int xgene_pmu_remove(struct platform_device *pdev)
+static void xgene_pmu_remove(struct platform_device *pdev)
 {
 	struct xgene_pmu *xgene_pmu = dev_get_drvdata(&pdev->dev);
 
@@ -1947,13 +1947,11 @@ static int xgene_pmu_remove(struct platform_device *pdev)
 	xgene_pmu_dev_cleanup(xgene_pmu, &xgene_pmu->mcpmus);
 	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_APM_XGENE_ONLINE,
 				    &xgene_pmu->node);
-
-	return 0;
 }
 
 static struct platform_driver xgene_pmu_driver = {
 	.probe = xgene_pmu_probe,
-	.remove = xgene_pmu_remove,
+	.remove_new = xgene_pmu_remove,
 	.driver = {
 		.name		= "xgene-pmu",
 		.of_match_table = xgene_pmu_of_match,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:16 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:16 +0100
Subject: [PATCH 16/18] perf: qcom_l2: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <a2587688c54834482d68fe2a44f415a649ad6477.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/qcom_l2_pmu.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/perf/qcom_l2_pmu.c b/drivers/perf/qcom_l2_pmu.c
index 3f9a98c17a89..148df5ae8ef8 100644
--- a/drivers/perf/qcom_l2_pmu.c
+++ b/drivers/perf/qcom_l2_pmu.c
@@ -965,7 +965,7 @@ static int l2_cache_pmu_probe(struct platform_device *pdev)
 	return err;
 }
 
-static int l2_cache_pmu_remove(struct platform_device *pdev)
+static void l2_cache_pmu_remove(struct platform_device *pdev)
 {
 	struct l2cache_pmu *l2cache_pmu =
 		to_l2cache_pmu(platform_get_drvdata(pdev));
@@ -973,7 +973,6 @@ static int l2_cache_pmu_remove(struct platform_device *pdev)
 	perf_pmu_unregister(&l2cache_pmu->pmu);
 	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
 				    &l2cache_pmu->node);
-	return 0;
 }
 
 static struct platform_driver l2_cache_pmu_driver = {
@@ -983,7 +982,7 @@ static struct platform_driver l2_cache_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = l2_cache_pmu_probe,
-	.remove = l2_cache_pmu_remove,
+	.remove_new = l2_cache_pmu_remove,
 };
 
 static int __init register_l2_cache_pmu_driver(void)
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:00 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:00 +0100
Subject: [PATCH 00/18] perf: Convert to platform remove callback returning void
Message-ID: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>

Hello,

this series converts all drivers below drivers/perf to use
.remove_new(). See commit 5c5a7680e67b ("platform: Provide a remove
callback that returns no value") for an extended explanation and the
eventual goal. The TL;DR; is to make it harder for driver authors to
leak resources without noticing.

I based the patches on today's next, I had to revert commits 
3115ee021bfb ("arm64: perf: Include threshold control fields in
PMEVTYPER mask") and 816c26754447 ("arm64: perf: Add support for event
counting threshold") to compile test on ARCH=arm (this is a problem in
next, not in my patch series).

This is merge window material. All patches are pairwise independent of
each other so they can be applied individually. Still it would be great
to let them go in all together.

Best regards
Uwe

Uwe Kleine-K?nig (18):
  perf: alibaba_uncore_drw: Convert to platform remove callback
    returning void
  perf: amlogic: Convert to platform remove callback returning void
  perf: arm-cci: Convert to platform remove callback returning void
  perf: arm-ccn: Convert to platform remove callback returning void
  perf: arm-cmn: Convert to platform remove callback returning void
  perf: arm_cspmu: Convert to platform remove callback returning void
  perf: arm_dmc620: Convert to platform remove callback returning void
  perf: arm_dsu: Convert to platform remove callback returning void
  perf: arm_smmuv3: Convert to platform remove callback returning void
  perf: arm_spe: Convert to platform remove callback returning void
  perf: fsl_imx8_ddr: Convert to platform remove callback returning void
  perf: fsl_imx9_ddr: Convert to platform remove callback returning void
  perf: hisilicon: Convert to platform remove callback returning void
  perf: marvell_cn10k_ddr: Convert to platform remove callback returning void
  perf: marvell_cn10k_tad: Convert to platform remove callback returning void
  perf: qcom_l2: Convert to platform remove callback returning void
  perf: thunderx2: Convert to platform remove callback returning void
  perf: xgene: Convert to platform remove callback returning void

 drivers/perf/alibaba_uncore_drw_pmu.c         | 6 ++----
 drivers/perf/amlogic/meson_g12_ddr_pmu.c      | 6 ++----
 drivers/perf/arm-cci.c                        | 8 +++-----
 drivers/perf/arm-ccn.c                        | 6 ++----
 drivers/perf/arm-cmn.c                        | 5 ++---
 drivers/perf/arm_cspmu/arm_cspmu.c            | 6 ++----
 drivers/perf/arm_dmc620_pmu.c                 | 6 ++----
 drivers/perf/arm_dsu_pmu.c                    | 6 ++----
 drivers/perf/arm_smmuv3_pmu.c                 | 6 ++----
 drivers/perf/arm_spe_pmu.c                    | 5 ++---
 drivers/perf/fsl_imx8_ddr_perf.c              | 5 ++---
 drivers/perf/fsl_imx9_ddr_perf.c              | 6 ++----
 drivers/perf/hisilicon/hisi_uncore_cpa_pmu.c  | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c  | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c  | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_pa_pmu.c   | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_sllc_pmu.c | 5 ++---
 drivers/perf/marvell_cn10k_ddr_pmu.c          | 5 ++---
 drivers/perf/marvell_cn10k_tad_pmu.c          | 6 ++----
 drivers/perf/qcom_l2_pmu.c                    | 5 ++---
 drivers/perf/thunderx2_pmu.c                  | 5 ++---
 drivers/perf/xgene_pmu.c                      | 6 ++----
 23 files changed, 47 insertions(+), 81 deletions(-)

base-commit: 17cb8a20bde66a520a2ca7aad1063e1ce7382240
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 15 05:59:13 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 14:59:13 +0100
Subject: [PATCH 13/18] perf: hisilicon: Convert to platform remove callback returning void
In-Reply-To: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
Message-ID: <33a8be0641b9447469fb7f6af0a10fb65efa97a3.1702648125.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert these drivers from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/perf/hisilicon/hisi_uncore_cpa_pmu.c  | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c  | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c  | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_pa_pmu.c   | 5 ++---
 drivers/perf/hisilicon/hisi_uncore_sllc_pmu.c | 5 ++---
 6 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/perf/hisilicon/hisi_uncore_cpa_pmu.c b/drivers/perf/hisilicon/hisi_uncore_cpa_pmu.c
index 40f1bc9f9b91..0e923f94fa5b 100644
--- a/drivers/perf/hisilicon/hisi_uncore_cpa_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_cpa_pmu.c
@@ -341,7 +341,7 @@ static int hisi_cpa_pmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int hisi_cpa_pmu_remove(struct platform_device *pdev)
+static void hisi_cpa_pmu_remove(struct platform_device *pdev)
 {
 	struct hisi_pmu *cpa_pmu = platform_get_drvdata(pdev);
 
@@ -349,7 +349,6 @@ static int hisi_cpa_pmu_remove(struct platform_device *pdev)
 	cpuhp_state_remove_instance_nocalls(CPUHP_AP_PERF_ARM_HISI_CPA_ONLINE,
 					    &cpa_pmu->node);
 	hisi_cpa_pmu_enable_pm(cpa_pmu);
-	return 0;
 }
 
 static struct platform_driver hisi_cpa_pmu_driver = {
@@ -359,7 +358,7 @@ static struct platform_driver hisi_cpa_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = hisi_cpa_pmu_probe,
-	.remove = hisi_cpa_pmu_remove,
+	.remove_new = hisi_cpa_pmu_remove,
 };
 
 static int __init hisi_cpa_pmu_module_init(void)
diff --git a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
index ffb039d05d07..b804e3738113 100644
--- a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
@@ -531,14 +531,13 @@ static int hisi_ddrc_pmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int hisi_ddrc_pmu_remove(struct platform_device *pdev)
+static void hisi_ddrc_pmu_remove(struct platform_device *pdev)
 {
 	struct hisi_pmu *ddrc_pmu = platform_get_drvdata(pdev);
 
 	perf_pmu_unregister(&ddrc_pmu->pmu);
 	cpuhp_state_remove_instance_nocalls(CPUHP_AP_PERF_ARM_HISI_DDRC_ONLINE,
 					    &ddrc_pmu->node);
-	return 0;
 }
 
 static struct platform_driver hisi_ddrc_pmu_driver = {
@@ -548,7 +547,7 @@ static struct platform_driver hisi_ddrc_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = hisi_ddrc_pmu_probe,
-	.remove = hisi_ddrc_pmu_remove,
+	.remove_new = hisi_ddrc_pmu_remove,
 };
 
 static int __init hisi_ddrc_pmu_module_init(void)
diff --git a/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
index 15caf99e1eef..21e69b1cdd4d 100644
--- a/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
@@ -534,14 +534,13 @@ static int hisi_hha_pmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int hisi_hha_pmu_remove(struct platform_device *pdev)
+static void hisi_hha_pmu_remove(struct platform_device *pdev)
 {
 	struct hisi_pmu *hha_pmu = platform_get_drvdata(pdev);
 
 	perf_pmu_unregister(&hha_pmu->pmu);
 	cpuhp_state_remove_instance_nocalls(CPUHP_AP_PERF_ARM_HISI_HHA_ONLINE,
 					    &hha_pmu->node);
-	return 0;
 }
 
 static struct platform_driver hisi_hha_pmu_driver = {
@@ -551,7 +550,7 @@ static struct platform_driver hisi_hha_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = hisi_hha_pmu_probe,
-	.remove = hisi_hha_pmu_remove,
+	.remove_new = hisi_hha_pmu_remove,
 };
 
 static int __init hisi_hha_pmu_module_init(void)
diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c b/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
index 794dbcd19b7a..51ba76871097 100644
--- a/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
@@ -568,14 +568,13 @@ static int hisi_l3c_pmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int hisi_l3c_pmu_remove(struct platform_device *pdev)
+static void hisi_l3c_pmu_remove(struct platform_device *pdev)
 {
 	struct hisi_pmu *l3c_pmu = platform_get_drvdata(pdev);
 
 	perf_pmu_unregister(&l3c_pmu->pmu);
 	cpuhp_state_remove_instance_nocalls(CPUHP_AP_PERF_ARM_HISI_L3_ONLINE,
 					    &l3c_pmu->node);
-	return 0;
 }
 
 static struct platform_driver hisi_l3c_pmu_driver = {
@@ -585,7 +584,7 @@ static struct platform_driver hisi_l3c_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = hisi_l3c_pmu_probe,
-	.remove = hisi_l3c_pmu_remove,
+	.remove_new = hisi_l3c_pmu_remove,
 };
 
 static int __init hisi_l3c_pmu_module_init(void)
diff --git a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c
index 797cf201996a..3cdb35c741f9 100644
--- a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c
@@ -514,14 +514,13 @@ static int hisi_pa_pmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int hisi_pa_pmu_remove(struct platform_device *pdev)
+static void hisi_pa_pmu_remove(struct platform_device *pdev)
 {
 	struct hisi_pmu *pa_pmu = platform_get_drvdata(pdev);
 
 	perf_pmu_unregister(&pa_pmu->pmu);
 	cpuhp_state_remove_instance_nocalls(CPUHP_AP_PERF_ARM_HISI_PA_ONLINE,
 					    &pa_pmu->node);
-	return 0;
 }
 
 static const struct acpi_device_id hisi_pa_pmu_acpi_match[] = {
@@ -539,7 +538,7 @@ static struct platform_driver hisi_pa_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = hisi_pa_pmu_probe,
-	.remove = hisi_pa_pmu_remove,
+	.remove_new = hisi_pa_pmu_remove,
 };
 
 static int __init hisi_pa_pmu_module_init(void)
diff --git a/drivers/perf/hisilicon/hisi_uncore_sllc_pmu.c b/drivers/perf/hisilicon/hisi_uncore_sllc_pmu.c
index e706ca567676..765bbd61db26 100644
--- a/drivers/perf/hisilicon/hisi_uncore_sllc_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_sllc_pmu.c
@@ -460,14 +460,13 @@ static int hisi_sllc_pmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int hisi_sllc_pmu_remove(struct platform_device *pdev)
+static void hisi_sllc_pmu_remove(struct platform_device *pdev)
 {
 	struct hisi_pmu *sllc_pmu = platform_get_drvdata(pdev);
 
 	perf_pmu_unregister(&sllc_pmu->pmu);
 	cpuhp_state_remove_instance_nocalls(CPUHP_AP_PERF_ARM_HISI_SLLC_ONLINE,
 					    &sllc_pmu->node);
-	return 0;
 }
 
 static struct platform_driver hisi_sllc_pmu_driver = {
@@ -477,7 +476,7 @@ static struct platform_driver hisi_sllc_pmu_driver = {
 		.suppress_bind_attrs = true,
 	},
 	.probe = hisi_sllc_pmu_probe,
-	.remove = hisi_sllc_pmu_remove,
+	.remove_new = hisi_sllc_pmu_remove,
 };
 
 static int __init hisi_sllc_pmu_module_init(void)
-- 
2.42.0



From francesco at dolcini.it  Fri Dec 15 05:59:35 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri, 15 Dec 2023 14:59:35 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <ZXxZzd1iBOCmnczH@hovoldconsulting.com>
References: <20231214170146.641783-1-francesco@dolcini.it>
 <ZXxZzd1iBOCmnczH@hovoldconsulting.com>
Message-ID: <ZXxbx+laQk35W56U@francesco-nb.int.toradex.com>

On Fri, Dec 15, 2023 at 02:51:09PM +0100, Johan Hovold wrote:
> On Thu, Dec 14, 2023 at 06:01:46PM +0100, Francesco Dolcini wrote:
> > From: Francesco Dolcini <francesco.dolcini at toradex.com>
> > 
> > receive_buf() is called from ttyport_receive_buf() that expects values
> > ">= 0" from serdev_controller_receive_buf(), change its return type from
> > ssize_t to size_t.
> > 
> > Suggested-by: Jiri Slaby <jirislaby at kernel.org>
> > Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
> > Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> > ---
> > hello,
> > patch is based on current linux next.
> > 
> > It has an obvious problem, it touches files from multiple subsystem in a single
> > patch that is complicated to review and eventually merge, just splitting this
> > would however not work, it will break bisectability and the build.
> > 
> > I am looking for advise on the best way to move forward.
> > 
> > I see the following options:
> >  - keep it as it is
> >  - break it down with a patch with each subsystem, and squash before applying
> >    from a single (tty?) subsystem
> >  - go for a multi stage approach, defining a new callback, move to it and in
> >    the end remove the original one, likewise it was done for i2c lately
> > 
> > ---
> >  drivers/bluetooth/btmtkuart.c              |  4 ++--
> >  drivers/bluetooth/btnxpuart.c              |  4 ++--
> 
> > diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
> > index 3c84fcbda01a..e6bc4a73c9fc 100644
> > --- a/drivers/bluetooth/btmtkuart.c
> > +++ b/drivers/bluetooth/btmtkuart.c
> > @@ -383,8 +383,8 @@ static void btmtkuart_recv(struct hci_dev *hdev, const u8 *data, size_t count)
> >  	}
> >  }
> >  
> > -static ssize_t btmtkuart_receive_buf(struct serdev_device *serdev,
> > -				     const u8 *data, size_t count)
> > +static size_t btmtkuart_receive_buf(struct serdev_device *serdev,
> > +				    const u8 *data, size_t count)
> >  {
> >  	struct btmtkuart_dev *bdev = serdev_device_get_drvdata(serdev);
> >  
> > diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> > index 1d592ac413d1..056bef5b2919 100644
> > --- a/drivers/bluetooth/btnxpuart.c
> > +++ b/drivers/bluetooth/btnxpuart.c
> > @@ -1264,8 +1264,8 @@ static const struct h4_recv_pkt nxp_recv_pkts[] = {
> >  	{ NXP_RECV_FW_REQ_V3,   .recv = nxp_recv_fw_req_v3 },
> >  };
> >  
> > -static ssize_t btnxpuart_receive_buf(struct serdev_device *serdev,
> > -				     const u8 *data, size_t count)
> > +static size_t btnxpuart_receive_buf(struct serdev_device *serdev,
> > +				    const u8 *data, size_t count)
> >  {
> >  	struct btnxpuart_dev *nxpdev = serdev_device_get_drvdata(serdev);
> 
> A quick check of just the first two functions here shows that they can
> return negative values.

This is already fixed. Patches are in next.

There were 3 buggy user of this API.
 - 1 patch was merged a few days ago in mainline
 - 2 patches are in next, the maintainer decided to wait for the next merge window

commit 687d2de93b11 ("Bluetooth: btmtkuart: fix recv_buf() return value")
commit 7954bbcdd7ea ("Bluetooth: btnxpuart: fix recv_buf() return value")
commit c8820c92caf0 ("platform/surface: aggregator: fix recv_buf() return value")


> 
> > diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
> > index e94e090cf0a1..3d7ae7fa5018 100644
> > --- a/drivers/tty/serdev/serdev-ttyport.c
> > +++ b/drivers/tty/serdev/serdev-ttyport.c
> > @@ -27,19 +27,17 @@ static size_t ttyport_receive_buf(struct tty_port *port, const u8 *cp,
> >  {
> >  	struct serdev_controller *ctrl = port->client_data;
> >  	struct serport *serport = serdev_controller_get_drvdata(ctrl);
> > -	int ret;
> > +	size_t ret;
> >  
> >  	if (!test_bit(SERPORT_ACTIVE, &serport->flags))
> >  		return 0;
> >  
> >  	ret = serdev_controller_receive_buf(ctrl, cp, count);
> >  
> > -	dev_WARN_ONCE(&ctrl->dev, ret < 0 || ret > count,
> > -				"receive_buf returns %d (count = %zu)\n",
> > +	dev_WARN_ONCE(&ctrl->dev, ret > count,
> > +				"receive_buf returns %zu (count = %zu)\n",
> >  				ret, count);
> > -	if (ret < 0)
> > -		return 0;
> > -	else if (ret > count)
> > +	if (ret > count)
> >  		return count;
> >  
> >  	return ret;
> 
> So please do not apply this patch until the various implementations have
> been fixed.
> 
> Johan


From ryan.roberts at arm.com  Fri Dec 15 06:05:28 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Fri, 15 Dec 2023 14:05:28 +0000
Subject: [PATCH v3 14/15] arm64/mm: Implement ptep_set_wrprotects() to
 optimize fork()
In-Reply-To: <87fs0413rx.fsf@nvdebian.thelocal>
References: <20231204105440.61448-1-ryan.roberts@arm.com>
 <20231204105440.61448-15-ryan.roberts@arm.com>
 <87cyvha2xd.fsf@nvdebian.thelocal>
 <ecf129dd-000f-45be-95dc-1e8dad5a8c12@arm.com>
 <87fs0413rx.fsf@nvdebian.thelocal>
Message-ID: <f2a3b1f0-0823-4c3a-b0e8-20ac83e855b2@arm.com>

On 15/12/2023 04:32, Alistair Popple wrote:
> 
> Ryan Roberts <ryan.roberts at arm.com> writes:
> 
>> On 08/12/2023 01:37, Alistair Popple wrote:
>>>
>>> Ryan Roberts <ryan.roberts at arm.com> writes:
>>>
>>>> With the core-mm changes in place to batch-copy ptes during fork, we can
>>>> take advantage of this in arm64 to greatly reduce the number of tlbis we
>>>> have to issue, and recover the lost fork performance incured when adding
>>>> support for transparent contiguous ptes.
>>>>
>>>> If we are write-protecting a whole contig range, we can apply the
>>>> write-protection to the whole range and know that it won't change
>>>> whether the range should have the contiguous bit set or not. For ranges
>>>> smaller than the contig range, we will still have to unfold, apply the
>>>> write-protection, then fold if the change now means the range is
>>>> foldable.
>>>>
>>>> This optimization is possible thanks to the tightening of the Arm ARM in
>>>> respect to the definition and behaviour when 'Misprogramming the
>>>> Contiguous bit'. See section D21194 at
>>>> https://developer.arm.com/documentation/102105/latest/
>>>>
>>>> Performance tested with the following test written for the will-it-scale
>>>> framework:
>>>>
>>>> -------
>>>>
>>>> char *testcase_description = "fork and exit";
>>>>
>>>> void testcase(unsigned long long *iterations, unsigned long nr)
>>>> {
>>>> 	int pid;
>>>> 	char *mem;
>>>>
>>>> 	mem = malloc(SZ_128M);
>>>> 	assert(mem);
>>>> 	memset(mem, 1, SZ_128M);
>>>>
>>>> 	while (1) {
>>>> 		pid = fork();
>>>> 		assert(pid >= 0);
>>>>
>>>> 		if (!pid)
>>>> 			exit(0);
>>>>
>>>> 		waitpid(pid, NULL, 0);
>>>>
>>>> 		(*iterations)++;
>>>> 	}
>>>> }
>>>>
>>>> -------
>>>>
>>>> I see huge performance regression when PTE_CONT support was added, then
>>>> the regression is mostly fixed with the addition of this change. The
>>>> following shows regression relative to before PTE_CONT was enabled
>>>> (bigger negative value is bigger regression):
>>>>
>>>> |   cpus |   before opt |   after opt |
>>>> |-------:|-------------:|------------:|
>>>> |      1 |       -10.4% |       -5.2% |
>>>> |      8 |       -15.4% |       -3.5% |
>>>> |     16 |       -38.7% |       -3.7% |
>>>> |     24 |       -57.0% |       -4.4% |
>>>> |     32 |       -65.8% |       -5.4% |
>>>>
>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>> ---
>>>>  arch/arm64/include/asm/pgtable.h | 30 ++++++++++++++++++++---
>>>>  arch/arm64/mm/contpte.c          | 42 ++++++++++++++++++++++++++++++++
>>>>  2 files changed, 69 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>>> index 15bc9cf1eef4..9bd2f57a9e11 100644
>>>> --- a/arch/arm64/include/asm/pgtable.h
>>>> +++ b/arch/arm64/include/asm/pgtable.h
>>>> @@ -984,6 +984,16 @@ static inline void __ptep_set_wrprotect(struct mm_struct *mm,
>>>>  	} while (pte_val(pte) != pte_val(old_pte));
>>>>  }
>>>>  
>>>> +static inline void __ptep_set_wrprotects(struct mm_struct *mm,
>>>> +					unsigned long address, pte_t *ptep,
>>>> +					unsigned int nr)
>>>> +{
>>>> +	unsigned int i;
>>>> +
>>>> +	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
>>>> +		__ptep_set_wrprotect(mm, address, ptep);
>>>> +}
>>>> +
>>>>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>>  #define __HAVE_ARCH_PMDP_SET_WRPROTECT
>>>>  static inline void pmdp_set_wrprotect(struct mm_struct *mm,
>>>> @@ -1139,6 +1149,8 @@ extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>>>  				unsigned long addr, pte_t *ptep);
>>>>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>>>>  				unsigned long addr, pte_t *ptep);
>>>> +extern void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
>>>> +				pte_t *ptep, unsigned int nr);
>>>>  extern int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
>>>>  				unsigned long addr, pte_t *ptep,
>>>>  				pte_t entry, int dirty);
>>>> @@ -1290,13 +1302,25 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
>>>>  	return contpte_ptep_clear_flush_young(vma, addr, ptep);
>>>>  }
>>>>  
>>>> +#define ptep_set_wrprotects ptep_set_wrprotects
>>>> +static inline void ptep_set_wrprotects(struct mm_struct *mm, unsigned long addr,
>>>> +				pte_t *ptep, unsigned int nr)
>>>> +{
>>>> +	if (!contpte_is_enabled(mm))
>>>> +		__ptep_set_wrprotects(mm, addr, ptep, nr);
>>>> +	else if (nr == 1) {
>>>
>>> Why do we need the special case here? Couldn't we just call
>>> contpte_set_wrprotects() with nr == 1?
>>
>> My intention is for this to be a fast path for ptep_set_wrprotect(). I'm having
>> to work hard to prevent regressing the order-0 folios case.
> 
> This ends up calling three functions anyway so I'm curious - does
> removing the one function call really make that much of difference?

Yes; big time. All the functions in the fast path are inlined. The version
regresses a fork() microbenchmark that David gave me by ~30%. I've had to work
quite hard to reduce that to 2%, even from this starting point. There is so
little in the inner loop that even the __ptep_get(ptep) (which is a READ_ONCE())
makes a measurable difference.

Anyway, I'll be posting v4 with these optimizations and all the supporting
benchmark data on Monday.

> 
> Either way I think a comment justifying the special case (ie. that this
> is simply a fast path for nr == 1) would be good.

I've added a comment here in v4.

> 
> Thanks.
> 
>>>
>>>> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>>>> +		__ptep_set_wrprotects(mm, addr, ptep, 1);
>>>> +		contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
>>>> +	} else
>>>> +		contpte_set_wrprotects(mm, addr, ptep, nr);
>>>> +}
>>>> +
>>>>  #define __HAVE_ARCH_PTEP_SET_WRPROTECT
>>>>  static inline void ptep_set_wrprotect(struct mm_struct *mm,
>>>>  				unsigned long addr, pte_t *ptep)
>>>>  {
>>>> -	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>>>> -	__ptep_set_wrprotect(mm, addr, ptep);
>>>> -	contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
>>>> +	ptep_set_wrprotects(mm, addr, ptep, 1);
>>>>  }
>>>>  
>>>>  #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
>>>> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
>>>> index e079ec61d7d1..2a57df16bf58 100644
>>>> --- a/arch/arm64/mm/contpte.c
>>>> +++ b/arch/arm64/mm/contpte.c
>>>> @@ -303,6 +303,48 @@ int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>>>>  }
>>>>  EXPORT_SYMBOL(contpte_ptep_clear_flush_young);
>>>>  
>>>> +void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
>>>> +					pte_t *ptep, unsigned int nr)
>>>> +{
>>>> +	unsigned long next;
>>>> +	unsigned long end = addr + (nr << PAGE_SHIFT);
>>>> +
>>>> +	do {
>>>> +		next = pte_cont_addr_end(addr, end);
>>>> +		nr = (next - addr) >> PAGE_SHIFT;
>>>> +
>>>> +		/*
>>>> +		 * If wrprotecting an entire contig range, we can avoid
>>>> +		 * unfolding. Just set wrprotect and wait for the later
>>>> +		 * mmu_gather flush to invalidate the tlb. Until the flush, the
>>>> +		 * page may or may not be wrprotected. After the flush, it is
>>>> +		 * guarranteed wrprotected. If its a partial range though, we
>>>> +		 * must unfold, because we can't have a case where CONT_PTE is
>>>> +		 * set but wrprotect applies to a subset of the PTEs; this would
>>>> +		 * cause it to continue to be unpredictable after the flush.
>>>> +		 */
>>>> +		if (nr != CONT_PTES)
>>>> +			contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>>>> +
>>>> +		__ptep_set_wrprotects(mm, addr, ptep, nr);
>>>> +
>>>> +		addr = next;
>>>> +		ptep += nr;
>>>> +
>>>> +		/*
>>>> +		 * If applying to a partial contig range, the change could have
>>>> +		 * made the range foldable. Use the last pte in the range we
>>>> +		 * just set for comparison, since contpte_try_fold() only
>>>> +		 * triggers when acting on the last pte in the contig range.
>>>> +		 */
>>>> +		if (nr != CONT_PTES)
>>>> +			contpte_try_fold(mm, addr - PAGE_SIZE, ptep - 1,
>>>> +					 __ptep_get(ptep - 1));
>>>> +
>>>> +	} while (addr != end);
>>>> +}
>>>> +EXPORT_SYMBOL(contpte_set_wrprotects);
>>>> +
>>>>  int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
>>>>  					unsigned long addr, pte_t *ptep,
>>>>  					pte_t entry, int dirty)
>>>
> 



From monstr at monstr.eu  Fri Dec 15 06:10:27 2023
From: monstr at monstr.eu (Michal Simek)
Date: Fri, 15 Dec 2023 15:10:27 +0100
Subject: [GIT PULL] arm64: soc: ZynqMP SoC changes for v6.8
Message-ID: <a41bcab2-1d28-42fd-b5ff-1d6fb5226cf1@monstr.eu>

Hi,

please pull these patches to your tree.

Thanks,
Michal


  The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

    Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

  are available in the Git repository at:

    https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-soc-for-6.8

  for you to fetch changes up to 87fda1acfc3b9048261799817ef749e6deb95724:

    soc: xilinx: Add error message for invalid payload received from IPI 
callback. (2023-12-13 16:55:15 +0100)

  ----------------------------------------------------------------
  arm64: ZynqMP SoC changes for 6.8

  power driver:
  - Move to remove_new hook
  - Report error around unsupported callback
  - Fix long messages

  event driver:
  - Fix cpu_id handling
  - Fix warning message

  ----------------------------------------------------------------
  HariBabu Gattem (1):
        soc: xilinx: Fix for call trace due to the usage of smp_processor_id()

  Michal Simek (1):
        soc: xilinx: fix quoted string split across lines

  Naman Trivedi Manojbhai (1):
        soc: xilinx: Add error message for invalid payload received from IPI 
callback.

  Tanmay Shah (1):
        soc: xilinx: fix unhandled SGI warning message

  Uwe Kleine-K?nig (1):
        soc/xilinx: zynqmp_power: Convert to platform remove callback returning void

   drivers/soc/xilinx/xlnx_event_manager.c |  7 +++++--
   drivers/soc/xilinx/zynqmp_power.c       | 16 ++++++++--------
   2 files changed, 13 insertions(+), 10 deletions(-)

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs



From gregkh at linuxfoundation.org  Fri Dec 15 06:11:53 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 15 Dec 2023 15:11:53 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <ZXxWX-Fw1InID2ax@hovoldconsulting.com>
References: <20231214170146.641783-1-francesco@dolcini.it>
 <ZXxWX-Fw1InID2ax@hovoldconsulting.com>
Message-ID: <2023121544-hastiness-unhinge-b8d3@gregkh>

On Fri, Dec 15, 2023 at 02:36:31PM +0100, Johan Hovold wrote:
> On Thu, Dec 14, 2023 at 06:01:46PM +0100, Francesco Dolcini wrote:
> > From: Francesco Dolcini <francesco.dolcini at toradex.com>
> > 
> > receive_buf() is called from ttyport_receive_buf() that expects values
> > ">= 0" from serdev_controller_receive_buf(), change its return type from
> > ssize_t to size_t.
> > 
> > Suggested-by: Jiri Slaby <jirislaby at kernel.org>
> > Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
> > Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> > ---
> >  drivers/gnss/core.c                        |  6 +++---
> >  drivers/gnss/serial.c                      |  4 ++--
> >  drivers/gnss/sirf.c                        |  6 +++---
> 
> > diff --git a/drivers/gnss/core.c b/drivers/gnss/core.c
> > index 48f2ee0f78c4..9b8a0605ec76 100644
> > --- a/drivers/gnss/core.c
> > +++ b/drivers/gnss/core.c
> > @@ -317,10 +317,10 @@ EXPORT_SYMBOL_GPL(gnss_deregister_device);
> >   *
> >   * Must not be called for a closed device.
> >   */
> > -int gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> > -				size_t count)
> > +size_t gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> > +		       size_t count)
> >  {
> > -	int ret;
> > +	size_t ret;
> >  
> >  	ret = kfifo_in(&gdev->read_fifo, buf, count);
> >  
> 
> Why are you changing this function? This is part of the GNSS interface
> and has nothing to do with the rest of this patch.
> 
> Greg, please drop this one again until this has been resolved.

Now dropped, thanks.


From geert+renesas at glider.be  Fri Dec 15 04:15:20 2023
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri, 15 Dec 2023 13:15:20 +0100
Subject: [GIT PULL 1/2] Renesas driver updates for v6.8
In-Reply-To: <cover.1702642338.git.geert+renesas@glider.be>
References: <cover.1702642338.git.geert+renesas@glider.be>
Message-ID: <cover.1702642340.git.geert+renesas@glider.be>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-drivers-for-v6.8-tag1

for you to fetch changes up to 31b2daea07643d8b83d62c670c76d95acca84f06:

  soc: renesas: Make RZ/Five depend on !DMA_DIRECT_REMAP (2023-12-13 17:23:28 +0100)

----------------------------------------------------------------
Renesas driver updates for v6.8

  - Remove duplicate setup of soc_device_attribute.family,
  - Make RZ/Five depend on !DMA_DIRECT_REMAP.

----------------------------------------------------------------
Conor Dooley (1):
      soc: renesas: Make RZ/Five depend on !DMA_DIRECT_REMAP

Geert Uytterhoeven (1):
      soc: renesas: Remove duplicate setup of soc_device_attribute.family

 drivers/soc/renesas/Kconfig       | 1 +
 drivers/soc/renesas/renesas-soc.c | 4 ----
 2 files changed, 1 insertion(+), 4 deletions(-)


From geert+renesas at glider.be  Fri Dec 15 04:15:19 2023
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri, 15 Dec 2023 13:15:19 +0100
Subject: [GIT PULL 1/2] Renesas SoC updates for v6.8 (take two)
Message-ID: <cover.1702642338.git.geert+renesas@glider.be>

	Hi SoC folks,

This is my second pull request for the inclusion of Renesas SoC updates
for v6.8.

It consists of 2 parts:

  [GIT PULL 1/2] Renesas driver updates for v6.8

    - Remove duplicate setup of soc_device_attribute.family,
    - Make RZ/Five depend on !DMA_DIRECT_REMAP.

  [GIT PULL 2/2] Renesas DTS updates for v6.8 (take two)

    - Add IA55 interrupt controller and Ethernet support for the RZ/G3S
      SoC and the RZ/G3S SMARC SoM,
    - Miscellaneous fixes and improvements.

Thanks for pulling!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From geert+renesas at glider.be  Fri Dec 15 04:15:21 2023
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri, 15 Dec 2023 13:15:21 +0100
Subject: [GIT PULL 2/2] Renesas DTS updates for v6.8 (take two)
In-Reply-To: <cover.1702642338.git.geert+renesas@glider.be>
References: <cover.1702642338.git.geert+renesas@glider.be>
Message-ID: <cover.1702642342.git.geert+renesas@glider.be>

The following changes since commit 95d516f3eb96bac466a6bfec28a1e55b8ed5160b:

  ARM: dts: renesas: r9a06g032: Add missing space in compatible (2023-11-28 10:29:11 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dts-for-v6.8-tag2

for you to fetch changes up to fc67495680f60e88bb8ca43421c1dd628928d581:

  arm64: dts: renesas: white-hawk-cpu: Fix missing serial console pin control (2023-12-13 17:34:54 +0100)

----------------------------------------------------------------
Renesas DTS updates for v6.8 (take two)

  - Add IA55 interrupt controller and Ethernet support for the RZ/G3S
    SoC and the RZ/G3S SMARC SoM,
  - Miscellaneous fixes and improvements.

----------------------------------------------------------------
Claudiu Beznea (4):
      arm64: dts: renesas: r9a08g045: Add IA55 interrupt controller node
      arm64: dts: renesas: r9a08g045: Add Ethernet nodes
      arm64: dts: renesas: rzg3s-smarc-som: Use switches' names to select on-board functionalities
      arm64: dts: renesas: rzg3s-smarc-som: Enable the Ethernet interfaces

Geert Uytterhoeven (1):
      arm64: dts: renesas: white-hawk-cpu: Fix missing serial console pin control

 .../boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi  |   3 +
 arch/arm64/boot/dts/renesas/r9a08g045.dtsi         | 106 +++++++++++++
 arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi   | 173 +++++++++++++++++++--
 3 files changed, 269 insertions(+), 13 deletions(-)


From laurent.pinchart at ideasonboard.com  Fri Dec 15 06:23:08 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 15 Dec 2023 16:23:08 +0200
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <CAOMZO5C7_Rj-Ja0BO0D0Po+gy+XbvyMdQf-wH5YNyhAdMof2vg@mail.gmail.com>
References: <20230920171009.3193296-1-l.stach@pengutronix.de>
 <20230920171009.3193296-2-l.stach@pengutronix.de>
 <20230920205736.GB7723@pendragon.ideasonboard.com>
 <CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>
 <CAOMZO5C7_Rj-Ja0BO0D0Po+gy+XbvyMdQf-wH5YNyhAdMof2vg@mail.gmail.com>
Message-ID: <20231215142308.GL21146@pendragon.ideasonboard.com>

On Fri, Dec 15, 2023 at 10:31:27AM -0300, Fabio Estevam wrote:
> On Sun, Dec 10, 2023 at 2:35?PM Adam Ford wrote:
> 
> > Lucas,
> >
> > It's been a few months since there has been any action.  If you want,
> > I can help apply the suggestions that Laurent has and re-submit with
> > both of our names if you want.  It would be nice to get this
> > integrated.
> 
> It would be nice if you could re-submit the series.

Yes, that would be nice. It shouldn't cause any issue, the patches will
retain Lucas' authorship.

-- 
Regards,

Laurent Pinchart


From monstr at monstr.eu  Fri Dec 15 06:23:26 2023
From: monstr at monstr.eu (Michal Simek)
Date: Fri, 15 Dec 2023 15:23:26 +0100
Subject: [GIT PULL] arm64: dts: ZynqMP DT changes for v6.8
Message-ID: <678c4116-bb16-4d07-b70d-d417405c8266@monstr.eu>

Hi,

please pull these changes to your tree. Most of that patches are related to dt 
schema fixes or solving issues reported by W=1.
FYI: I have rebased the queue this week because Masahiro sent fixes tag Dec 12 
against Rob's aptch and wanted to record it.

Thanks,
Michal

  The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

    Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

  are available in the Git repository at:

    https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-dt-for-6.8

  for you to fetch changes up to a98b6987de7d44cb621294041364f70285b3d2c6:

    arm64: zynqmp: Add missing destination mailbox compatible (2023-12-13 
16:52:47 +0100)

  ----------------------------------------------------------------
  arm64: ZynqMP DT changes for 6.8

  - Fix overlay rules to remove KR260 targets
  - Move ethernet phys to mdio node
  - Fix couple of issues reported by W=1
   - Do not use _ in node names
   - Use lowercase in register address
   - Remove address/size-cells from nodes without child
   - Moved fixed clock to root on KV260
  - Fix issues reported by dt-schema
   - additional compatible string for qspi on SOM
  - Move arm/xilinx.yaml to soc vendor to cover also other archs
  - Describe new Microblaze V qemu platform
  - Add missing mailbox destination compatible string

  ----------------------------------------------------------------
  Michal Simek (11):
        arm64: xilinx: Do not use '_' in DT node names
        arm64: xilinx: Use lower case for partition address
        arm64: xilinx: Remove mt25qu512a compatible string from SOM
        arm64: xilinx: Put ethernet phys to mdio node
        arm64: xilinx: Remove address/size-cells from flash node
        arm64: xilinx: Remove address/size-cells from gem nodes
        dt-bindings: soc: xilinx: Move xilinx.yaml from arm to soc
        dt-bindings: soc: Add new board description for MicroBlaze V
        arm64: zynqmp: Move fixed clock to / for kv260
        arm64: zynqmp: Fix clock node name in kv260 cards
        arm64: zynqmp: Add missing destination mailbox compatible

  Rob Herring (1):
        arm64: dts: xilinx: Apply overlays to base dtbs

   Documentation/devicetree/bindings/{arm => soc/xilinx}/xilinx.yaml |  7 +++-
   MAINTAINERS                                                       |  1 +
   arch/arm64/boot/dts/xilinx/Makefile                               |  9 ++---
   arch/arm64/boot/dts/xilinx/zynqmp-sck-kv-g-revA.dtso              | 40 
+++++++++----------
   arch/arm64/boot/dts/xilinx/zynqmp-sck-kv-g-revB.dtso              | 42 
++++++++++----------
   arch/arm64/boot/dts/xilinx/zynqmp-sm-k26-revA.dts                 |  8 ++--
   arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts            |  8 +++-
   arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts            | 16 +++++---
   arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts            |  8 +++-
   arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts            | 26 
+++++++-----
   arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts            |  8 +++-
   arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts                 |  4 +-
   arch/arm64/boot/dts/xilinx/zynqmp.dtsi                            | 15 ++-----
   13 files changed, 104 insertions(+), 88 deletions(-)
   rename Documentation/devicetree/bindings/{arm => soc/xilinx}/xilinx.yaml (95%)

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs


From neil.armstrong at linaro.org  Fri Dec 15 06:24:20 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Fri, 15 Dec 2023 15:24:20 +0100
Subject: [PATCH] arm64: dts: amlogic: fix format for s4 uart node
In-Reply-To: <20231215-s4-dts-v1-1-7831ab6972be@amlogic.com>
References: <20231215-s4-dts-v1-1-7831ab6972be@amlogic.com>
Message-ID: <a2c851fe-2c94-4121-87f2-a9b6480c4a6e@linaro.org>

On 15/12/2023 09:28, Xianwei Zhao via B4 Relay wrote:
> From: Xianwei Zhao <xianwei.zhao at amlogic.com>
> 
> Aliases use lowercase letters and place status in end.
> 
> Signed-off-by: Xianwei Zhao <xianwei.zhao at amlogic.com>
> ---
>   arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts | 4 ++--
>   arch/arm64/boot/dts/amlogic/meson-s4.dtsi             | 4 ++--
>   2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
> index 18789242f05f..983caddc409c 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s805x2-aq222.dts
> @@ -15,7 +15,7 @@ / {
>   	#size-cells = <2>;
>   
>   	aliases {
> -		serial0 = &uart_B;
> +		serial0 = &uart_b;
>   	};
>   
>   	memory at 0 {
> @@ -36,7 +36,7 @@ secmon_reserved: secmon at 5000000 {
>   	};
>   };
>   
> -&uart_B {
> +&uart_b {
>   	status = "okay";
>   };
>   
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> index c6b524e1a1ee..ce90b35686a2 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> @@ -455,14 +455,14 @@ nand: nand-controller at 8c800 {
>   				status = "disabled";
>   			};
>   
> -			uart_B: serial at 7a000 {
> +			uart_b: serial at 7a000 {
>   				compatible = "amlogic,meson-s4-uart",
>   					     "amlogic,meson-ao-uart";
>   				reg = <0x0 0x7a000 0x0 0x18>;
>   				interrupts = <GIC_SPI 169 IRQ_TYPE_EDGE_RISING>;
> -				status = "disabled";
>   				clocks = <&xtal>, <&clkc_periphs CLKID_UART_B>, <&xtal>;
>   				clock-names = "xtal", "pclk", "baud";
> +				status = "disabled";
>   			};
>   
>   			reset: reset-controller at 2000 {
> 
> ---
> base-commit: 078c5db2a961f674cc27c10f15d15949eece6a49
> change-id: 20231211-s4-dts-4a1805bd56f0
> 
> Best regards,

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>


From josef at toxicpanda.com  Fri Dec 15 06:25:20 2023
From: josef at toxicpanda.com (Josef Bacik)
Date: Fri, 15 Dec 2023 09:25:20 -0500
Subject: [PATCH] arm64: properly install vmlinuz.efi
In-Reply-To: <CAPnjgZ1ePt1zoPc4NvbHXkgKdG0MQZL2pYArBvCVaNgCqXaEqA@mail.gmail.com>
References: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>
 <CAPnjgZ1ePt1zoPc4NvbHXkgKdG0MQZL2pYArBvCVaNgCqXaEqA@mail.gmail.com>
Message-ID: <20231215142520.GA683314@perftesting>

On Thu, Dec 14, 2023 at 01:12:13PM -0700, Simon Glass wrote:
> Hi Josef,
> 
> On Thu, 14 Dec 2023 at 09:19, Josef Bacik <josef at toxicpanda.com> wrote:
> >
> > If you select CONFIG_EFI_ZBOOT, we will generate vmlinuz.efi, and then
> > when we go to install the kernel we'll install the vmlinux instead
> > because install.sh only recognizes Image.gz as wanting the compressed
> > install image.  With CONFIG_EFI_ZBOOT we don't get the proper kernel
> > installed, which means it doesn't boot, which makes for a very confused
> > and subsequently angry kernel developer.
> >
> > Fix this by properly installing our compressed kernel if we've enabled
> > CONFIG_EFI_ZBOOT.
> >
> > Signed-off-by: Josef Bacik <josef at toxicpanda.com>
> > ---
> >  arch/arm64/boot/install.sh | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
> > index 7399d706967a..9b7a09808a3d 100755
> > --- a/arch/arm64/boot/install.sh
> > +++ b/arch/arm64/boot/install.sh
> > @@ -17,7 +17,8 @@
> >  #   $3 - kernel map file
> >  #   $4 - default install path (blank if root directory)
> >
> > -if [ "$(basename $2)" = "Image.gz" ]; then
> > +if [ "$(basename $2)" = "Image.gz" ] || [ "$(basename $2)" = "vmlinuz.efi" ]
> > +then
> >  # Compressed install
> >    echo "Installing compressed kernel"
> >    base=vmlinuz
> 
> This is a little messy.
> 
> There is a KBUILD_IMAGE var which should be usable, although I see
> that it is set to $(boot)/Image when 'make install' is invoked.

Yeah, which is another pain point for me, because really what normal people want
to use is 'make zinstall', and that's not obvious anywhere and is a pretty
drastic departure from literally any other arch.

> 
> Could we perhaps make sure that this var is set to the file to be installed?
> 
> I also wonder how useful it is to indicate whether the image is
> compressed or not, so perhaps we could just say 'Installing kernel' ?
> 

I have no strong opinions here, I'm reticent to be messing with an install
script for an arch I don't maintain.  I need this change to be able to do
aarch64 testing in a VM, and honestly I'm sort of surprised I'm the first person
to run into this since the default stuff straight up doesn't work at all when it
does for other archs.  Thanks,

Josef


From neil.armstrong at linaro.org  Fri Dec 15 06:27:05 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Fri, 15 Dec 2023 15:27:05 +0100
Subject: [PATCH] arm64: dts: amlogic: fix format for s4 uart node
In-Reply-To: <20231215-s4-dts-v1-1-7831ab6972be@amlogic.com>
References: <20231215-s4-dts-v1-1-7831ab6972be@amlogic.com>
Message-ID: <170265042524.3306004.7156643290374411600.b4-ty@linaro.org>

Hi,

On Fri, 15 Dec 2023 16:28:00 +0800, Xianwei Zhao wrote:
> Aliases use lowercase letters and place status in end.
> 
> 

Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.8/arm64-dt)

[1/1] arm64: dts: amlogic: fix format for s4 uart node
      https://git.kernel.org/amlogic/c/f1e2e85bb06b942db86992a8a3187ffe9807939c

These changes has been applied on the intermediate git tree [1].

The v6.8/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.

In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].

The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.

If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

-- 
Neil



From himanshu.bhavani at siliconsignals.io  Fri Dec 15 06:34:57 2023
From: himanshu.bhavani at siliconsignals.io (Himanshu Bhavani)
Date: Fri, 15 Dec 2023 20:04:57 +0530
Subject: [PATCH] usb: dwc3: imx8mp: Fix smatch warning
Message-ID: <20231215143458.158810-1-himanshu.bhavani@siliconsignals.io>

dwc3_imx8mp_pm_resume() warn: 'dwc3_imx->suspend_clk'
from clk_prepare_enable() not released

Signed-off-by: Himanshu Bhavani <himanshu.bhavani at siliconsignals.io>

diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
index a1e15f2fffdb..8ee448068503 100644
--- a/drivers/usb/dwc3/dwc3-imx8mp.c
+++ b/drivers/usb/dwc3/dwc3-imx8mp.c
@@ -363,8 +363,10 @@ static int __maybe_unused dwc3_imx8mp_pm_resume(struct device *dev)
 	}
 
 	ret = clk_prepare_enable(dwc3_imx->hsio_clk);
-	if (ret)
+	if (ret) {
+		clk_disable_unprepare(dwc3_imx->suspend_clk);
 		return ret;
+	}
 
 	ret = dwc3_imx8mp_resume(dwc3_imx, PMSG_RESUME);
 
-- 
2.25.1



From gregory.clement at bootlin.com  Fri Dec 15 06:47:25 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 15 Dec 2023 15:47:25 +0100
Subject: [PATCH v2 0/3] Moxtet bus fixes
In-Reply-To: <20231208161724.5f4f626a@dellmb>
References: <20231128213536.3764212-1-sjoerd@collabora.com>
 <87fs0ceoif.fsf@BL-laptop> <20231208161724.5f4f626a@dellmb>
Message-ID: <87fs03cyki.fsf@BL-laptop>

Marek Beh?n <kabel at kernel.org> writes:

> On Fri, 08 Dec 2023 15:51:20 +0100
> Gregory CLEMENT <gregory.clement at bootlin.com> wrote:
>
>> Hello Marek and Sjoerd,
>> 
>> > It seems the moxtet bus support was broken since 21aad8ba615e ("arm64:
>> > dts: armada-3720-turris-mox: Add missing interrupt for RTC") for two
>> > reasons:
>> > * The moxtet irq isn't marked as shared so the driver fails to load if
>> >   the rtc driver gets set up first.
>> > * The dts change didn't set the IRQ type, so in case the rtc driver got
>> >   probed first irq setup ended up wrong (rising instead of falling edge).
>> >
>> > On top of that the moxtet module isn't auto-loading due to a missing spi
>> > table
>> >
>> > Changes in v2:
>> > - Add cover letter
>> > - Add patch to set the irq type
>> >
>> > Sjoerd Simons (3):
>> >   bus: moxtet: Mark the irq as shared
>> >   bus: moxtet: Add spi device table
>> >   arm64: dts: armada-3720-turris-mox: set irq type for RTC  
>> 
>> I only received the previous patch in my inbox, I plan to apply it. But
>> what about the 2 other patches ? Marek will you do a pull request with
>> these 2 patches or do you expect that I take them also ?
>> 
>> Regards,
>> 
>> Gregory
>
> Gregory, as of yet I've never done a pull request. If you are willing
> to take all 3 patches now, please do. In the future I would like to

OK I applied them on mvebu/driver.

> start doing it for Turris stuff, if you are OK with it.

No pb, just tell me when you are going to doing it.

Gregory

>
> Marek

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Fri Dec 15 06:52:29 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 15 Dec 2023 15:52:29 +0100
Subject: [PATCH v8 0/3] arm64: dts: cn913x: add COM Express boards
In-Reply-To: <20231211171739.4090179-1-enachman@marvell.com>
References: <20231211171739.4090179-1-enachman@marvell.com>
Message-ID: <87cyv7cyc2.fsf@BL-laptop>

Elad Nachman <enachman at marvell.com> writes:

> From: Elad Nachman <enachman at marvell.com>
>
> Add support for CN9130 and CN9131 COM Express Type 7 CPU
> module boards by Marvell.
> Add device tree bindings for this board.
> Define these COM Express CPU modules as dtsi, and
> provide a dtsi file for a carrier board (Marvell AC5X RD
> COM Express type 7 carrier board).
> This Carrier board only utilizes the PCIe link, hence no
> special device / driver support is provided by this dtsi file.
> Finally, add dts file for the combined carrier and CPU module.
>
> v8:
>    1) swap enum for const in dt bindings
>
> v7:
>    1) update MAINTAINERS file to contain all marvell arm64
>       dts file in one line, covering all files
>    2) Add Documentation to carrier dtsi and combined carrier
>       and CPU module dts, explaining the configuration and
>       modes of operations of the carrier and the combined
>       system.
>
> v6:
>    1) Add cn9130 COM Express system
>
>    2) Drop with from compatibility name of COM Express system
>
>    3) Fix indentation issues of dt bindings
>
> v5:
>
>    1) List only carrier compatibility on carrier dtsi
>
>    2) Fix dt_bindings_check warnings using latest yamllint/dtschema
>
>    3) Fix subject lines to remove unnecessary wordings.
>
>    4) Remove dt bindings for standalone CPU modules
>
>    5) Move CN913x dt bindings to A7K dt bindings file
>
>    6) Fix dtbs_check warnings for dtb and bindings,
>       using latest yamllint/dtschema.
>
>    7) Move memory definition to main dts file, as memory
>       is socket based.
>
> v4:
>    1) reorder patches - dt bindings before dts/dtsi files
>
>    2) correct description in dt bindings
>
>    3) separate dt bindings for CPU module, carrier and combination
>
>    4) make carrier board dts into dtsi, make dts for combination of
>       carrier and CPU module
>
>    5) correct compatibility strings and file names to use dashes
>       instead of underscores
>
> v3:
>    1) Remove acronym which creates warnings for checkpatch.pl
>
>    2) Correct compatibility string for ac5x rd board
>
>    3) Add above compatibility string to dt bindings
>
>    4) update MAINTAINERS file with ac5 series dts files
>
>    5) remove memory property from carrier dts
>
>    6) add comment explaining that OOB RGMII ethernet port
>       connector and PHY are both on CPU module
>
> v2:
>    1) add compatibility string for the board
>
>    2) remove unneeded hard-coded PHY LED blinking mode initialization
>
>    3) Split the CPU portion of the carrier board to
>       dtsi files, and define a dts file for the AC5X RD
>       carrier board.
>
> Elad Nachman (3):
>   MAINTAINERS: add ac5 to list of maintained Marvell dts files
>   dt-bindings: arm64: add Marvell COM Express boards
>   arm64: dts: cn913x: add device trees for COM Express boards

Applied on mvebu/dt64

Thanks,

Gregory

>
>  .../bindings/arm/marvell/armada-7k-8k.yaml    |  22 ++++
>  MAINTAINERS                                   |   3 +-
>  arch/arm64/boot/dts/marvell/Makefile          |   1 +
>  .../dts/marvell/ac5x-rd-carrier-cn9131.dts    |  44 +++++++
>  .../boot/dts/marvell/ac5x-rd-carrier.dtsi     |  34 ++++++
>  .../dts/marvell/cn9130-db-comexpress.dtsi     |  96 ++++++++++++++++
>  .../dts/marvell/cn9131-db-comexpress.dtsi     | 108 ++++++++++++++++++
>  7 files changed, 306 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/marvell/ac5x-rd-carrier-cn9131.dts
>  create mode 100644 arch/arm64/boot/dts/marvell/ac5x-rd-carrier.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/cn9130-db-comexpress.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/cn9131-db-comexpress.dtsi
>
> -- 
> 2.25.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From broonie at kernel.org  Fri Dec 15 06:59:51 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 15 Dec 2023 14:59:51 +0000
Subject: [PATCH v7 34/39] kselftest/arm64: Add a GCS test program built
 with the system libc
In-Reply-To: <875y1089i4.fsf@linaro.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-34-201c483bd775@kernel.org>
 <875y1089i4.fsf@linaro.org>
Message-ID: <485b6454-135c-4dd4-b38e-8fb8a02779cd@sirena.org.uk>

On Thu, Dec 14, 2023 at 11:50:11PM -0300, Thiago Jung Bauermann wrote:
> Mark Brown <broonie at kernel.org> writes:

> > +	ret = process_vm_writev(child, &local_iov, 1, &remote_iov, 1, 0);
> > +	if (ret == -1)
> > +		ksft_print_msg("process_vm_readv() failed: %s (%d)\n",
> > +			       strerror(errno), errno);

> The comment and the error message say "process_vm_readv()", but the
> function actually called is process_vm_writev(). Is this intended?

No, that's a rebasing issue.

> If I swap process_vm_readv() and process_vm_writev(), then the read
> succeeds but the write fails:
> 
> #  RUN           global.ptrace_read_write ...
> # Child: 1996
> # Child GCSPR 0xffffa7fcffd8, flags 1, locked 0
> # process_vm_writev() failed: Bad address (14)
> # libc-gcs.c:291:ptrace_read_write:Expected ret (-1) == sizeof(rval) (8)
> # libc-gcs.c:293:ptrace_read_write:Expected val (281473500358268) == ptrace(PTRACE_PEEKDATA, child, (void *)gcspr, NULL) (0)
> # ptrace_read_write: Test failed at step #1
> #          FAIL  global.ptrace_read_write
> not ok 4 global.ptrace_read_write

Yeah, I did notice something had happened with the writes but didn't
investigate yet.

> Also, it's strange that the tests defined after map_gcs.stack_overflow
> don't run when I execute this test program. I'm doing:

> $ ./run_kselftest.sh -t arm64:libc-gcs

> I.e., these tests aren't being run in my FVP:

> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, too_small)
> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_1)
> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_2)
> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_3)
> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_4)
> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_5)
> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_6)
> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_7)
> > +TEST_F(map_invalid_gcs, do_map)
> > +FIXTURE_VARIANT_ADD(invalid_mprotect, exec)
> > +FIXTURE_VARIANT_ADD(invalid_mprotect, bti)
> > +FIXTURE_VARIANT_ADD(invalid_mprotect, exec_bti)
> > +TEST_F(invalid_mprotect, do_map)
> > +TEST_F(invalid_mprotect, do_map_read)

I'm seeing all of those appearing.  I'm not sure what to say there -
that's all kselftest framework stuff, I'd expect the framework to say
something about what it's doing if it decides to skip and I can't think
why it would decide to skip.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/632ebdef/attachment.sig>

From james.clark at arm.com  Fri Dec 15 07:00:37 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 15:00:37 +0000
Subject: [PATCH 0/2] arm: perf: Fix ARCH=arm build with GCC
Message-ID: <20231215150040.3342183-1-james.clark@arm.com>

Two fixes for the broken build withh GCC currently in linux-next
(next-20231214)

James Clark (2):
  arm: perf: Fix ARCH=arm build with GCC in armv8pmu_write_evtype()
  arm: perf: Fix ARCH=arm build with GCC in armv8pmu_set_event_filter()

 drivers/perf/arm_pmuv3.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

-- 
2.34.1



From james.clark at arm.com  Fri Dec 15 07:00:38 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 15:00:38 +0000
Subject: [PATCH 1/2] arm: perf: Fix ARCH=arm build with GCC in armv8pmu_write_evtype()
In-Reply-To: <20231215150040.3342183-1-james.clark@arm.com>
References: <20231215150040.3342183-1-james.clark@arm.com>
Message-ID: <20231215150040.3342183-2-james.clark@arm.com>

LLVM ignores everything inside the if statement and doesn't generate
errors, but GCC doesn't ignore it, resulting in the following error:

  drivers/perf/arm_pmuv3.c: In function ?armv8pmu_write_evtype?:
  include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
  	34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \

Fix it by changing the if to #if.

Fixes: 3115ee021bfb ("arm64: perf: Include threshold control fields in PMEVTYPER mask")
Reported-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Closes: https://lore.kernel.org/linux-arm-kernel/20231215120817.h2f3akgv72zhrtqo at pengutronix.de/
Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/perf/arm_pmuv3.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 23fa6c5da82c..3ed2086cefc3 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -631,8 +631,9 @@ static void armv8pmu_write_evtype(int idx, unsigned long val)
 			     ARMV8_PMU_EXCLUDE_EL0 |
 			     ARMV8_PMU_EXCLUDE_EL1;
 
-	if (IS_ENABLED(CONFIG_ARM64))
-		mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
+#if IS_ENABLED(CONFIG_ARM64)
+	mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
+#endif
 
 	val &= mask;
 	write_pmevtypern(counter, val);
-- 
2.34.1



From james.clark at arm.com  Fri Dec 15 07:00:39 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 15:00:39 +0000
Subject: [PATCH 2/2] arm: perf: Fix ARCH=arm build with GCC in armv8pmu_set_event_filter()
In-Reply-To: <20231215150040.3342183-1-james.clark@arm.com>
References: <20231215150040.3342183-1-james.clark@arm.com>
Message-ID: <20231215150040.3342183-3-james.clark@arm.com>

LLVM ignores everything inside the if statement and doesn't generate
errors, but GCC does, resulting in the following:

  drivers/perf/arm_pmuv3.c: In function armv8pmu_set_event_filter:
  include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
  34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \

Fix it by changing the if to #if. This results in an unused function
warning for armv8pmu_event_threshold_control(), so suppress that too.

Fixes: 816c26754447 ("arm64: perf: Add support for event counting threshold")
Signed-off-by: James Clark <james.clark at arm.com>
---
 drivers/perf/arm_pmuv3.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
index 3ed2086cefc3..8aa23878019a 100644
--- a/drivers/perf/arm_pmuv3.c
+++ b/drivers/perf/arm_pmuv3.c
@@ -338,7 +338,7 @@ static bool armv8pmu_event_want_user_access(struct perf_event *event)
 	return ATTR_CFG_GET_FLD(&event->attr, rdpmc);
 }
 
-static u8 armv8pmu_event_threshold_control(struct perf_event_attr *attr)
+static __maybe_unused u8 armv8pmu_event_threshold_control(struct perf_event_attr *attr)
 {
 	u8 th_compare = ATTR_CFG_GET_FLD(attr, threshold_compare);
 	u8 th_count = ATTR_CFG_GET_FLD(attr, threshold_count);
@@ -1040,11 +1040,13 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 		return -EINVAL;
 	}
 
-	if (IS_ENABLED(CONFIG_ARM64) && th) {
+#if IS_ENABLED(CONFIG_ARM64)
+	if (th) {
 		config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TH, th);
 		config_base |= FIELD_PREP(ARMV8_PMU_EVTYPE_TC,
 					  armv8pmu_event_threshold_control(attr));
 	}
+#endif
 
 	/*
 	 * Install the filter into config_base as this is used to
-- 
2.34.1



From fusibrandon13 at gmail.com  Fri Dec 15 07:12:09 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Fri, 15 Dec 2023 16:12:09 +0100
Subject: [PATCH 1/5] riscv: dts: allwinner: Update opp table to allow CPU frequency scaling
In-Reply-To: <20231214111446.camz2krqanaieybh@vireshk-i7>
References: <20231214111446.camz2krqanaieybh@vireshk-i7>
Message-ID: <20231215151209.46221-1-fusibrandon13@gmail.com>

On Thu, Dec 14, 2023 at 12:14?PM Viresh Kumar <viresh.kumar at linaro.org> wrote:
>
> On 14-12-23, 11:33, Brandon Cheo Fusi wrote:
> > Two OPPs are currently defined for the D1/D1s; one at 408MHz and
> > another at 1.08GHz. Switching between these can be done with the
> > "sun50i-cpufreq-nvmem" driver. This patch populates the opp table
> > appropriately, with inspiration from
> > https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi
> >
> > The supply voltages are PWM-controlled, but support for that IP
> > is still in the works. So stick to a fixed 0.9V vdd-cpu supply,
> > which seems to be the default on most D1 boards.
> >
> > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > ---
> > ?arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 18 +++++++++++++++---
> > ?1 file changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > index 64c3c2e6c..e211fe4c7 100644
> > --- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > @@ -39,16 +39,22 @@ cpu0_intc: interrupt-controller {
> > ? ? ? };
> >
> > ? ? ? opp_table_cpu: opp-table-cpu {
> > - ? ? ? ? ? ? compatible = "operating-points-v2";
> > + ? ? ? ? ? ? compatible = "allwinner,sun20i-d1-operating-points",
>
> I don't think you should add a new compatible for every SoC that needs
> to be supported by a DT bindings and cpufreq driver. Maybe you should
> just reuse "allwinner,sun50i-h6-operating-points" and it will work
> fine for you ?
>
> Rob ?
>
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"allwinner,sun50i-h6-operating-points";
> > + ? ? ? ? ? ? nvmem-cells = <&cpu_speed_grade>;
> > + ? ? ? ? ? ? nvmem-cell-names = "speed";
> > + ? ? ? ? ? ? opp-shared;
> >
> > ? ? ? ? ? ? ? opp-408000000 {
> > + ? ? ? ? ? ? ? ? ? ? clock-latency-ns = <244144>; /* 8 32k periods */
> > ? ? ? ? ? ? ? ? ? ? ? opp-hz = /bits/ 64 <408000000>;
> > - ? ? ? ? ? ? ? ? ? ? opp-microvolt = <900000 900000 1100000>;
> > + ? ? ? ? ? ? ? ? ? ? opp-microvolt-speed0 = <900000>;
>
> The separate property name thing was required when you could have
> different values for different SoC instances, which can be read from
> efuses, like in your case.
>
> But all I see is speed0 here, why don't you always set opp-microvolt
> then ?
>

Setting opp-microvolt would be ok, but opp-microvolt-speed0 was chosen for
consistency with the driver bindings here
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml#L52 

> Also why degrade from min/max/target type to just target ?
>

This is a mistake on my part as I thought requesting non default voltages
was going to be a problem with lack of PWM support. Will be reverted in v2.

> > ? ? ? ? ? ? ? };
> >
> > ? ? ? ? ? ? ? opp-1080000000 {
> > + ? ? ? ? ? ? ? ? ? ? clock-latency-ns = <244144>; /* 8 32k periods */
> > ? ? ? ? ? ? ? ? ? ? ? opp-hz = /bits/ 64 <1008000000>;
> > - ? ? ? ? ? ? ? ? ? ? opp-microvolt = <900000 900000 1100000>;
> > + ? ? ? ? ? ? ? ? ? ? opp-microvolt-speed0 = <900000>;
> > ? ? ? ? ? ? ? };
> > ? ? ? };
> >
> > @@ -115,3 +121,8 @@ pmu {
> > ? ? ? ? ? ? ? ? ? ? ? <0x00000000 0x0000000f 0xffffffff 0xffffffff 0x00020000>;
> > ? ? ? };
> > ?};
> > +
> > +&sid {
> > + ? ? cpu_speed_grade: cpu-speed-grade at 0 {
> > + ? ? ? ? ? ? reg = <0x00 0x2>;
> > + ? ? };
> > +};
> > --
> > 2.30.2
>
> --
> viresh

Thank you for reviewing.
Brandon.


From madvenka at linux.microsoft.com  Fri Dec 15 07:15:52 2023
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Fri, 15 Dec 2023 09:15:52 -0600
Subject: ARM64 Livepatch based on SFrame
In-Reply-To: <ZXxO43Xwn5GHsrO8@FVFF77S0Q05N>
References: <0337266cf19f4c98388e3f6d09f590d9de258dc7>
 <20230202074036.507249-1-madvenka@linux.microsoft.com>
 <ZByJmnc/XDcqQwoZ@FVFF77S0Q05N.cambridge.arm.com>
 <72364198-b031-4ecc-b337-d07db1b9d0c8@linux.microsoft.com>
 <ZXxO43Xwn5GHsrO8@FVFF77S0Q05N>
Message-ID: <8f3d6362-1513-45a9-9f56-f7ec4bff11a2@linux.microsoft.com>



On 12/15/23 07:04, Mark Rutland wrote:
> On Thu, Dec 14, 2023 at 02:49:29PM -0600, Madhavan T. Venkataraman wrote:
>> Hi Mark,
> 
> Hi Madhavan,
> 
>> I attended your presentation in the LPC. You mentioned that you could use
>> some help with some pre-requisites for the Livepatch feature.
>> I would like to lend a hand.
> 
> Cool!
> 
> I've been meaning to send a mail round with a summary of the current state of
> things, and what needs to be done going forward, but I haven't had the time
> since LPC to put that together (as e.g. that requires learning some more about
> SFrame).  I'll be disappearing for the holiday shortly, and I intend to pick
> that up in the new year.
> 
>> What would you like me to implement?
> 
> I'm not currently sure exactly what we need/want to implement, and as above I
> think that needs to wait until the new year.
> 

OK.

> However, one thing that you can do that would be very useful is to write up and
> report the GCC DWARF issues that you mentioned in:
> 
>   https://lore.kernel.org/linux-arm-kernel/20230202074036.507249-1-madvenka at linux.microsoft.com/
> 
> ... as (depending on exactly what those are) those could also affect SFrame
> generation (and thus we'll need to get those fixed in GCC), and regardless it
> would be useful information to know.
> 
> I understood that you planned to do that from:
> 
>   https://lore.kernel.org/linux-arm-kernel/054ce0d6-70f0-b834-d4e5-1049c8df7492 at linux.microsoft.com/
> 
> ... but I couldn't spot any relevant mails or issues in the GCC bugzilla, so
> either I'm failing to search hard enough, or did that get forgotten about?
> 

Yeah. I had notes on that. But I seem to have lost them. I need to reproduce the
problems and analyze them again which is not trivial. So, I have been procrastinating.

I am also disappearing for the rest of this year. I will try to look at it in the
new year.

>> I would also like to implement Unwind Hints for the feature. If you want a
>> specific format for the hints, let me know.
> 
> I will get back to you on that in the new year; I think the specifics we want
> are going to depend on other details above we need to analyse first.
> 

OK.

For now, I will implement something and send it out just for reference. We can revisit
this topic next year sometime.

Thanks.

Madhavan


From u.kleine-koenig at pengutronix.de  Fri Dec 15 07:15:47 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 16:15:47 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <nsa54fwu4ewmcaehesuqefoo5r7z3tuvj76hjb4ngtkaygxwxx@h73ihjon5gby>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
 <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
 <20231213110829.bjaxjjiyy4ug7o67@pengutronix.de>
 <6wnsxbi27xdxjtaqaaaq5wtwwilp4jfw4mg5y2ctdl7xrs44ry@ns6y36pf7hge>
 <20231213155252.eq6cdzk2vuwllzdu@pengutronix.de>
 <nsa54fwu4ewmcaehesuqefoo5r7z3tuvj76hjb4ngtkaygxwxx@h73ihjon5gby>
Message-ID: <20231215151547.y23fgs6hskng5izg@pengutronix.de>

Hello,

On Fri, Dec 15, 2023 at 01:34:26PM +0100, Maxime Ripard wrote:
> On Wed, Dec 13, 2023 at 04:52:52PM +0100, Uwe Kleine-K?nig wrote:
> > On Wed, Dec 13, 2023 at 12:54:14PM +0100, Maxime Ripard wrote:
> > > On Wed, Dec 13, 2023 at 12:08:29PM +0100, Uwe Kleine-K?nig wrote:
> > > > On Wed, Dec 13, 2023 at 09:36:49AM +0100, Maxime Ripard wrote:
> > > > > On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
> > > > > > On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > > > > > > On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> > > > > > > > clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> > > > > > > > that and don't check the return value. This series fixes the four users
> > > > > > > > that do error checking on the returned value and then makes function
> > > > > > > > return void.
> > > > > > > > 
> > > > > > > > Given that the changes to the drivers are simple and so merge conflicts
> > > > > > > > (if any) should be easy to handle, I suggest to merge this complete
> > > > > > > > series via the clk tree.
> > > > > > > 
> > > > > > > I don't think it's the right way to go about it.
> > > > > > > 
> > > > > > > clk_rate_exclusive_get() should be expected to fail. For example if
> > > > > > > there's another user getting an exclusive rate on the same clock.
> > > > > > > 
> > > > > > > If we're not checking for it right now, then it should probably be
> > > > > > > fixed, but the callers checking for the error are right to do so if they
> > > > > > > rely on an exclusive rate. It's the ones that don't that should be
> > > > > > > modified.
> > > > > > 
> > > > > > If some other consumer has already "locked" a clock that I call
> > > > > > clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
> > > > > > this function because I don't want the rate to change e.g. because I
> > > > > > setup some registers in the consuming device to provide a fixed UART
> > > > > > baud rate or i2c bus frequency (and that works as expected).
> > > > > 
> > > > > [a long text of mostly right things (Uwe's interpretation) that are
> > > > > however totally unrelated to the patches under discussion.]
> > > 
> > > I'm glad you consider it "mostly" right.
> > 
> > there was no offense intended. I didn't agree to all points, but didn't
> > think it was helpful to discuss that given that I considered them
> > orthogonal to my suggested modifications.
> >  
> > > > The clk API works with and without my patches in exactly the same way.
> > > > It just makes more explicit that clk_rate_exclusive_get() cannot fail
> > > > today and removes the error handling from consumers that is never used.
> > > 
> > > Not really, no.
> > 
> > What exactly do you oppose here? Both of my sentences are correct?!
> 
> That the API works in the exact same way.

Yeah ok, if you call clk_rate_exclusive_get() and want to check the
return code you always got 0 before and now you get a compiler error. So
there is a difference. What I meant is: Calling clk_rate_exclusive_get()
with my patches has the exact same effects as before (apart from setting
the register used to transport the return value to zero).
 
> > > Can you fail to get the exclusivity? Yes. On a theoretical basis, you
> > > can, and the function was explicitly documented as such.
> > 
> > Sure, you could modify the clk internals such that
> > clk_rate_exclusive_get() needs to allocate memory. Or that it fails if
> > another consumer already has called it. At least the latter is a change
> > in semantics that requires to review (and maybe fix) all users. Also
> > note that calling clk_rate_exclusive_get() essentially locks all parent
> > clocks up to the root clock. So if clk_rate_exclusive_get() fails in the
> > presence of another locker, you can only have one locker per clock
> > hierarchy because it's impossible that both grab the lock on the root
> > clock.
> 
> We're not discussing the same thing. You're talking about from a
> technical point of view, I'm talking about it from an abstraction point
> of view.

In your abstract argumentation clk_rate_exclusive_get() has a
different and stronger semantic than it has today. This stronger
semantic indeed will make this function not succeed in every case. It
should return an error indication and users should check it.

But as your clk_rate_exclusive_get() is a different function than
today's clk_rate_exclusive_get(), I still think our argument isn't
helpful. I want to do something with apples and you're arguing against
that by only talking about oranges.

> Let's use another example: kmalloc cannot fail.

Oh really?

... [a few greps later] ...

While the memory allocation stuff is sufficiently complex that I don't
claim to have grokked it, I think it can (and should) fail. Either I
missed something, or I just burned some more time to convince myself
that kmalloc is just another orange :-\

> Are we going to remove every possible check for a null pointer in the
> kernel?

If you were right with your claim that kmalloc() cannot fail, we should
IMHO consider that. Or maybe better make it robust (in the sense that a
caller of kmalloc() can indeed use the memory returned by it) which
enforces that it might fail at times as even on big machines there is
only a finite amount of memory.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/5d54a0f0/attachment.sig>

From sjoerd at collabora.com  Fri Dec 15 07:16:39 2023
From: sjoerd at collabora.com (Sjoerd Simons)
Date: Fri, 15 Dec 2023 16:16:39 +0100
Subject: [PATCH v2 0/3] Moxtet bus fixes
In-Reply-To: <87fs03cyki.fsf@BL-laptop>
References: <20231128213536.3764212-1-sjoerd@collabora.com>
	 <87fs0ceoif.fsf@BL-laptop> <20231208161724.5f4f626a@dellmb>
	 <87fs03cyki.fsf@BL-laptop>
Message-ID: <67f183ea01430224ce305d7e6267c9b5ef114923.camel@collabora.com>




From fusibrandon13 at gmail.com  Fri Dec 15 07:17:23 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Fri, 15 Dec 2023 16:17:23 +0100
Subject: [PATCH 4/5] cpufreq: Add support for RISC-V CPU Frequency scaling drivers
In-Reply-To: <20231214111702.xdd7qlcrpqh74i3j@vireshk-i7>
References: <20231214111702.xdd7qlcrpqh74i3j@vireshk-i7>
Message-ID: <20231215151723.46409-1-fusibrandon13@gmail.com>

On Thu, Dec 14, 2023 at 12:17?PM Viresh Kumar <viresh.kumar at linaro.org> wrote:
>
> On 14-12-23, 11:33, Brandon Cheo Fusi wrote:
> > Add Kconfig file for cpufreq scaling drivers that can handle RISC-V
> > CPUs. An entry is included for the Allwinner H6 cpufreq driver that
> > works with D1.
> >
> > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > ---
> >  drivers/cpufreq/Kconfig       |  4 ++++
> >  drivers/cpufreq/Kconfig.riscv | 16 ++++++++++++++++
> >  2 files changed, 20 insertions(+)
> >  create mode 100644 drivers/cpufreq/Kconfig.riscv
>
> We don't have a separate kconfig file for each architecture. Only if
> there are too many entries for an architecture, we add a new file.
>
> --
> viresh

The sun50i cpufreq driver is currently only available when CONFIG_ARM or
CONFIG_ARM64 is selected, so this was the only decent way I could think
of making it accessible on either one of CONFIG_(ARM | ARM64 | RISC-V).
Any suggestions for a better workaround ?

Also I think future cpufreq drivers for RISC-V are going to happen, so we
might as well have the Kconfig file.

Kind Regards,
Brandon.


From u.kleine-koenig at pengutronix.de  Fri Dec 15 07:18:51 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 16:18:51 +0100
Subject: [PATCH 1/2] arm: perf: Fix ARCH=arm build with GCC in
 armv8pmu_write_evtype()
In-Reply-To: <20231215150040.3342183-2-james.clark@arm.com>
References: <20231215150040.3342183-1-james.clark@arm.com>
 <20231215150040.3342183-2-james.clark@arm.com>
Message-ID: <20231215151851.24wwciobjy5ritoe@pengutronix.de>

Hello,

On Fri, Dec 15, 2023 at 03:00:38PM +0000, James Clark wrote:
> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index 23fa6c5da82c..3ed2086cefc3 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -631,8 +631,9 @@ static void armv8pmu_write_evtype(int idx, unsigned long val)
>  			     ARMV8_PMU_EXCLUDE_EL0 |
>  			     ARMV8_PMU_EXCLUDE_EL1;
>  
> -	if (IS_ENABLED(CONFIG_ARM64))
> -		mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
> +#if IS_ENABLED(CONFIG_ARM64)
> +	mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
> +#endif

maybe add a comment about why you used an #if here, to prevent the
people sending patches that revert your change?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/a9aa5638/attachment.sig>

From fusibrandon13 at gmail.com  Fri Dec 15 07:18:35 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Fri, 15 Dec 2023 16:18:35 +0100
Subject: [PATCH 1/5] riscv: dts: allwinner: Update opp table to allow CPU frequency scaling
In-Reply-To: <2177637.Mh6RI2rZIc@archlinux>
References: <2177637.Mh6RI2rZIc@archlinux>
Message-ID: <20231215151835.46492-1-fusibrandon13@gmail.com>

On Thu, Dec 14, 2023 at 5:37?PM Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
>
> On Thursday, December 14, 2023 2:47:14 PM CET Conor Dooley wrote:
> > On Thu, Dec 14, 2023 at 04:44:46PM +0530, Viresh Kumar wrote:
> > > On 14-12-23, 11:33, Brandon Cheo Fusi wrote:
> > > > Two OPPs are currently defined for the D1/D1s; one at 408MHz and
> > > > another at 1.08GHz. Switching between these can be done with the
> > > > "sun50i-cpufreq-nvmem" driver. This patch populates the opp table
> > > > appropriately, with inspiration from
> > > > https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi
> > > >
> > > > The supply voltages are PWM-controlled, but support for that IP
> > > > is still in the works. So stick to a fixed 0.9V vdd-cpu supply,
> > > > which seems to be the default on most D1 boards.
> > > >
> > > > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > > > ---
> > > > ?arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 18 +++++++++++++++---
> > > > ?1 file changed, 15 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > > > index 64c3c2e6c..e211fe4c7 100644
> > > > --- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > > > +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> > > > @@ -39,16 +39,22 @@ cpu0_intc: interrupt-controller {
> > > > ? };
> > > >
> > > > ? opp_table_cpu: opp-table-cpu {
> > > > - ? ? ? ? compatible = "operating-points-v2";
> > > > + ? ? ? ? compatible = "allwinner,sun20i-d1-operating-points",
> > >
> > > I don't think you should add a new compatible for every SoC that needs
> > > to be supported by a DT bindings and cpufreq driver. Maybe you should
> > > just reuse "allwinner,sun50i-h6-operating-points" and it will work
> > > fine for you ?
> > >
> > > Rob ?
> >
> > The driver can definitely just reuse sun50i-h6, but the binding and
> > devicetree should have a soc-specific compatible for the sun20i-d1.
>
> Correct. This is to avoid later regrets if it turns out there are some slight
> differences or additional functionality.
>
> Best regards,
> Jernej
>
> >
> > That said, the compatible does need to be documented, there's a
> > dt-bindings patch missing from this series.
> >
> > Cheers,
> > Conor.
>
>
>
>

This dt-bindings patch will be available in v2

Thanks for reviewing.
Brandon.


From glider at google.com  Fri Dec 15 07:19:27 2023
From: glider at google.com (Alexander Potapenko)
Date: Fri, 15 Dec 2023 16:19:27 +0100
Subject: [PATCH v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <ZXtircr4TllpqyeS@yury-ThinkPad>
References: <20231214110639.2294687-1-glider@google.com> <20231214110639.2294687-5-glider@google.com>
 <ZXtircr4TllpqyeS@yury-ThinkPad>
Message-ID: <CAG_fn=WcrNqV4burBRPZZwoBLwgia7kerZ8g2vV5spzWF=houQ@mail.gmail.com>

>
> That looks weird... You're casting address of a 'data' to a bitmap
> instead of 'data'. At the 1st glance it makes little sense because
> 'data' is passed as parameter. Moreover, in mte_is_compressed()
> you pass 'data', not '&data'. Can you please comment on your
> intention?

Although `data` is a void*, it actually contains 64 bits of compressed
data, so we pass &data to mte_bitmap_read() to read its contents.
Perhaps I'd better make `data` an unsigned long to avoid confusion.

>
> > +     max_ranges = MTE_MAX_RANGES;
> > +     /* Skip the leading bit indicating the inline case. */
> > +     mte_bitmap_read(bitmap, &bit_pos, 1);
> > +     largest_idx =
> > +             mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_LARGEST_IDX);
>
> Nit: really no need to split the line - we're OK with 100-chars per
> line now.

That's true, but I am relying on clang-format here (maybe we should
extend the limit in .clang-format?)


From robh at kernel.org  Fri Dec 15 07:22:55 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 15 Dec 2023 09:22:55 -0600
Subject: [PATCH 1/2] dt-bindings: nvmem: add "data-size" property
In-Reply-To: <20231213154721.5037-1-zajec5@gmail.com>
References: <20231213154721.5037-1-zajec5@gmail.com>
Message-ID: <20231215152255.GA3798777-robh@kernel.org>

On Wed, Dec 13, 2023 at 04:47:20PM +0100, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> Allow specifying NVMEM device content size in case it differs from
> device total size.
> 
> Cc: Christian Marangi <ansuelsmth at gmail.com>
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> ---
>  Documentation/devicetree/bindings/nvmem/nvmem.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> index 4fd015d402ce..095aed4250de 100644
> --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> @@ -26,6 +26,13 @@ properties:
>    "#size-cells":
>      const: 1
>  
> +  data-size:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      NVMEM device actual data (content) size. It may be need to be specified
> +      if it differs by design from the total NVMEM device size and it's
> +      impossible to determine it on runtime.

'data-size' is already defined in 
Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml.

That would be fine, but it's defining bits per word. So I think it's 
better if we call this something else. 'total-data-size' or 
'actual-data-size'?

I think Simon had something similar for binman.

Rob


From robh at kernel.org  Fri Dec 15 07:24:56 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 15 Dec 2023 09:24:56 -0600
Subject: [PATCH v2 4/7] dma-mapping: Add helpers for dma_range_map bounds
In-Reply-To: <16d3e9100cd4a4a397641df963f416cc7f70cc4c.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
 <16d3e9100cd4a4a397641df963f416cc7f70cc4c.1702486837.git.robin.murphy@arm.com>
Message-ID: <170265389548.3988948.144759236279201432.robh@kernel.org>


On Wed, 13 Dec 2023 17:17:57 +0000, Robin Murphy wrote:
> Several places want to compute the lower and/or upper bounds of a
> dma_range_map, so let's factor that out into reusable helpers.
> 
> Reviewed-by: Christoph Hellwig <hch at lst.de>
> Reviewed-by: Jason Gunthorpe <jgg at nvidia.com>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
> v2: fix warning for 32-bit builds
> ---
>  arch/loongarch/kernel/dma.c |  9 ++-------
>  drivers/acpi/arm64/dma.c    |  8 +-------
>  drivers/of/device.c         | 11 ++---------
>  include/linux/dma-direct.h  | 18 ++++++++++++++++++
>  4 files changed, 23 insertions(+), 23 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Fri Dec 15 07:25:46 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 15 Dec 2023 09:25:46 -0600
Subject: [PATCH v2 7/7] dma-mapping: Simplify arch_setup_dma_ops()
In-Reply-To: <7e6af148e0df9a10b51cd60234ec6b35f7d4cc20.1702486837.git.robin.murphy@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
 <7e6af148e0df9a10b51cd60234ec6b35f7d4cc20.1702486837.git.robin.murphy@arm.com>
Message-ID: <170265394575.3996198.15248667149121379629.robh@kernel.org>


On Wed, 13 Dec 2023 17:18:00 +0000, Robin Murphy wrote:
> The dma_base, size and iommu arguments are only used by ARM, and can
> now easily be deduced from the device itself, so there's no need to pass
> them through the callchain as well.
> 
> Reviewed-by: Christoph Hellwig <hch at lst.de>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
> v2: Make sure the ARM changes actually build (oops...)
> ---
>  arch/arc/mm/dma.c               |  3 +--
>  arch/arm/mm/dma-mapping-nommu.c |  3 +--
>  arch/arm/mm/dma-mapping.c       | 18 ++++++++++--------
>  arch/arm64/mm/dma-mapping.c     |  3 +--
>  arch/mips/mm/dma-noncoherent.c  |  3 +--
>  arch/riscv/mm/dma-noncoherent.c |  3 +--
>  drivers/acpi/scan.c             |  3 +--
>  drivers/hv/hv_common.c          |  6 +-----
>  drivers/of/device.c             |  4 +---
>  include/linux/dma-map-ops.h     |  6 ++----
>  10 files changed, 20 insertions(+), 32 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>



From linux at armlinux.org.uk  Fri Dec 15 07:31:55 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Fri, 15 Dec 2023 15:31:55 +0000
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or
 functional) devices
In-Reply-To: <CAJZ5v0h3WWtvrbxRpaGfq6c756k+L1SzZ1Gv3A14JxXHNcUMKA@mail.gmail.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>
 <20231214173241.0000260f@Huawei.com>
 <CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>
 <ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk>
 <CAJZ5v0h2Keyb-gFWFuPsKtwqjXvM2snyGpo6MMfFzaXKbfEpgw@mail.gmail.com>
 <CAJZ5v0h3WWtvrbxRpaGfq6c756k+L1SzZ1Gv3A14JxXHNcUMKA@mail.gmail.com>
Message-ID: <ZXxxa+XZjPZtNfJ+@shell.armlinux.org.uk>

On Thu, Dec 14, 2023 at 07:37:10PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 14, 2023 at 7:16?PM Rafael J. Wysocki <rafael at kernel.org> wrote:
> >
> > On Thu, Dec 14, 2023 at 7:10?PM Russell King (Oracle)
> > <linux at armlinux.org.uk> wrote:
> > > I guess we need something like:
> > >
> > >         if (device->status.present)
> > >                 return device->device_type != ACPI_BUS_TYPE_PROCESSOR ||
> > >                        device->status.enabled;
> > >         else
> > >                 return device->status.functional;
> > >
> > > so we only check device->status.enabled for processor-type devices?
> >
> > Yes, something like this.
> 
> However, that is not sufficient, because there are
> ACPI_BUS_TYPE_DEVICE devices representing processors.
> 
> I'm not sure about a clean way to do it ATM.

Ok, how about:

static bool acpi_dev_is_processor(const struct acpi_device *device)
{
	struct acpi_hardware_id *hwid;

	if (device->device_type == ACPI_BUS_TYPE_PROCESSOR)
		return true;

	if (device->device_type != ACPI_BUS_TYPE_DEVICE)
		return false;

	list_for_each_entry(hwid, &device->pnp.ids, list)
		if (!strcmp(ACPI_PROCESSOR_OBJECT_HID, hwid->id) ||
		    !strcmp(ACPI_PROCESSOR_DEVICE_HID, hwid->id))
			return true;

	return false;
}

and then:

	if (device->status.present)
		return !acpi_dev_is_processor(device) || device->status.enabled;
	else
		return device->status.functional;

?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From lukasz.luba at arm.com  Fri Dec 15 07:38:46 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Fri, 15 Dec 2023 15:38:46 +0000
Subject: [PATCH 3/4] thermal/cpufreq: Remove
 arch_update_thermal_pressure()
In-Reply-To: <20231212142730.998913-4-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-4-vincent.guittot@linaro.org>
Message-ID: <e034144d-fff6-490f-889f-1114a2f779c6@arm.com>



On 12/12/23 14:27, Vincent Guittot wrote:
> arch_update_thermal_pressure() aims to update fast changing signal which
> should be averaged using PELT filtering before being provided to the
> scheduler which can't make smart use of fast changing signal.
> cpufreq now provides the maximum freq_qos pressure on the capacity to the
> scheduler, which includes cpufreq cooling device. Remove the call to
> arch_update_thermal_pressure() in cpufreq cooling device as this is
> handled by cpufreq_get_pressure().
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>   drivers/thermal/cpufreq_cooling.c | 3 ---
>   1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/thermal/cpufreq_cooling.c b/drivers/thermal/cpufreq_cooling.c
> index e2cc7bd30862..e77d3b44903e 100644
> --- a/drivers/thermal/cpufreq_cooling.c
> +++ b/drivers/thermal/cpufreq_cooling.c
> @@ -448,7 +448,6 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
>   				 unsigned long state)
>   {
>   	struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
> -	struct cpumask *cpus;
>   	unsigned int frequency;
>   	int ret;
>   
> @@ -465,8 +464,6 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
>   	ret = freq_qos_update_request(&cpufreq_cdev->qos_req, frequency);
>   	if (ret >= 0) {
>   		cpufreq_cdev->cpufreq_state = state;
> -		cpus = cpufreq_cdev->policy->related_cpus;
> -		arch_update_thermal_pressure(cpus, frequency);
>   		ret = 0;
>   	}
>   

Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>


From gregory.clement at bootlin.com  Fri Dec 15 07:37:06 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 15 Dec 2023 16:37:06 +0100
Subject: [PATCH] cpufreq: armada-8k: Fix parameter type warning
Message-ID: <20231215153706.2087883-1-gregory.clement@bootlin.com>

The second parameter of clk_get() is of type 'const char *', so use
NULL instead of the integer 0 to resolve a sparse warning:

drivers/cpufreq/armada-8k-cpufreq.c:60:40: warning: Using plain integer as NULL pointer
drivers/cpufreq/armada-8k-cpufreq.c:168:40: warning: Using plain integer as NULL pointer

Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312141651.lCAXGAZ2-lkp at intel.com/
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
---
 drivers/cpufreq/armada-8k-cpufreq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/armada-8k-cpufreq.c b/drivers/cpufreq/armada-8k-cpufreq.c
index 8afefdea4d80..ce5a5641b6dd 100644
--- a/drivers/cpufreq/armada-8k-cpufreq.c
+++ b/drivers/cpufreq/armada-8k-cpufreq.c
@@ -57,7 +57,7 @@ static void __init armada_8k_get_sharing_cpus(struct clk *cur_clk,
 			continue;
 		}
 
-		clk = clk_get(cpu_dev, 0);
+		clk = clk_get(cpu_dev, NULL);
 		if (IS_ERR(clk)) {
 			pr_warn("Cannot get clock for CPU %d\n", cpu);
 		} else {
@@ -165,7 +165,7 @@ static int __init armada_8k_cpufreq_init(void)
 			continue;
 		}
 
-		clk = clk_get(cpu_dev, 0);
+		clk = clk_get(cpu_dev, NULL);
 
 		if (IS_ERR(clk)) {
 			pr_err("Cannot get clock for CPU %d\n", cpu);
-- 
2.42.0



From andrew at lunn.ch  Fri Dec 15 07:51:42 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 15 Dec 2023 16:51:42 +0100
Subject: [PATCH] cpufreq: armada-8k: Fix parameter type warning
In-Reply-To: <20231215153706.2087883-1-gregory.clement@bootlin.com>
References: <20231215153706.2087883-1-gregory.clement@bootlin.com>
Message-ID: <62f5e43a-a381-4bc0-ad75-e716a98a0ad9@lunn.ch>

On Fri, Dec 15, 2023 at 04:37:06PM +0100, Gregory CLEMENT wrote:
> The second parameter of clk_get() is of type 'const char *', so use
> NULL instead of the integer 0 to resolve a sparse warning:
> 
> drivers/cpufreq/armada-8k-cpufreq.c:60:40: warning: Using plain integer as NULL pointer
> drivers/cpufreq/armada-8k-cpufreq.c:168:40: warning: Using plain integer as NULL pointer
> 
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312141651.lCAXGAZ2-lkp at intel.com/
> Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From lukasz.luba at arm.com  Fri Dec 15 07:54:13 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Fri, 15 Dec 2023 15:54:13 +0000
Subject: [PATCH 0/5] Rework system pressure interface to the scheduler
In-Reply-To: <2c2fad2b-89ce-437e-96b3-f06e6f99639f@arm.com>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <47b4cbcb-d33d-4699-a148-0108cf734e23@arm.com>
 <CAKfTPtATWSWdk1dhnMvBqTZigtprv7d_0j0zpf48WfVDfMit5g@mail.gmail.com>
 <2c2fad2b-89ce-437e-96b3-f06e6f99639f@arm.com>
Message-ID: <2b0524b9-3b54-4548-9054-2ba48eed6b65@arm.com>



On 12/14/23 08:32, Lukasz Luba wrote:
> 
> 
> On 12/14/23 08:29, Vincent Guittot wrote:
>> On Thu, 14 Dec 2023 at 09:21, Lukasz Luba <lukasz.luba at arm.com> wrote:
>>>
>>> Hi Vincent,
>>>
>>> I've been waiting for this feature, thanks!
>>>
>>>
>>> On 12/12/23 14:27, Vincent Guittot wrote:
>>>> Following the consolidation and cleanup of CPU capacity in [1], this 
>>>> serie
>>>> reworks how the scheduler gets the pressures on CPUs. We need to 
>>>> take into
>>>> account all pressures applied by cpufreq on the compute capacity of 
>>>> a CPU
>>>> for dozens of ms or more and not only cpufreq cooling device or HW
>>>> mitigiations. we split the pressure applied on CPU's capacity in 2 
>>>> parts:
>>>> - one from cpufreq and freq_qos
>>>> - one from HW high freq mitigiation.
>>>>
>>>> The next step will be to add a dedicated interface for long standing
>>>> capping of the CPU capacity (i.e. for seconds or more) like the
>>>> scaling_max_freq of cpufreq sysfs. The latter is already taken into
>>>> account by this serie but as a temporary pressure which is not 
>>>> always the
>>>> best choice when we know that it will happen for seconds or more.
>>>>
>>>> [1] 
>>>> https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot at linaro.org/
>>>>
>>>> Vincent Guittot (4):
>>>> ??? cpufreq: Add a cpufreq pressure feedback for the scheduler
>>>> ??? sched: Take cpufreq feedback into account
>>>> ??? thermal/cpufreq: Remove arch_update_thermal_pressure()
>>>> ??? sched: Rename arch_update_thermal_pressure into
>>>> ????? arch_update_hw_pressure
>>>>
>>>> ?? arch/arm/include/asm/topology.h?????????????? |? 6 +--
>>>> ?? arch/arm64/include/asm/topology.h???????????? |? 6 +--
>>>> ?? drivers/base/arch_topology.c????????????????? | 26 ++++-----
>>>> ?? drivers/cpufreq/cpufreq.c???????????????????? | 48 +++++++++++++++++
>>>> ?? drivers/cpufreq/qcom-cpufreq-hw.c???????????? |? 4 +-
>>>> ?? drivers/thermal/cpufreq_cooling.c???????????? |? 3 --
>>>> ?? include/linux/arch_topology.h???????????????? |? 8 +--
>>>> ?? include/linux/cpufreq.h?????????????????????? | 10 ++++
>>>> ?? include/linux/sched/topology.h??????????????? |? 8 +--
>>>> ?? .../{thermal_pressure.h => hw_pressure.h}???? | 14 ++---
>>>> ?? include/trace/events/sched.h????????????????? |? 2 +-
>>>> ?? init/Kconfig????????????????????????????????? | 12 ++---
>>>> ?? kernel/sched/core.c?????????????????????????? |? 8 +--
>>>> ?? kernel/sched/fair.c?????????????????????????? | 53 
>>>> ++++++++++---------
>>>> ?? kernel/sched/pelt.c?????????????????????????? | 18 +++----
>>>> ?? kernel/sched/pelt.h?????????????????????????? | 16 +++---
>>>> ?? kernel/sched/sched.h????????????????????????? |? 4 +-
>>>> ?? 17 files changed, 152 insertions(+), 94 deletions(-)
>>>> ?? rename include/trace/events/{thermal_pressure.h => hw_pressure.h} 
>>>> (55%)
>>>>
>>>
>>> I would like to test it, but something worries me. Why there is 0/5 in
>>> this subject and only 4 patches?
>>
>> I removed a patch from the series but copied/pasted the cover letter
>> subject without noticing the /5 instead of /4
> 
> OK
> 
>>
>>>
>>> Could you tell me your base branch that I can apply this, please?
>>
>> It applies on top of tip/sched/core + [1]
>> and you can find it here:
>> https://git.linaro.org/people/vincent.guittot/kernel.git/log/?h=sched/system-pressure
> 
> Thanks for the info and handy link.
> 

I've tested your patches with: DTPM/PowerCap + thermal gov + cpufreq
sysfs scaling_max_freq. It works fine all my cases (couldn't cause
any issues). If you like to test DTPM you will need 2 fixed pending
in Rafael's tree.

So, I'm looking for a your v2 to continue reviewing it.


From nm at ti.com  Fri Dec 15 08:00:47 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 15 Dec 2023 10:00:47 -0600
Subject: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc
 for wkup_uart0
In-Reply-To: <20231114073209.40756-1-tony@atomide.com>
References: <20231114073209.40756-1-tony@atomide.com>
Message-ID: <20231215160047.uiitnlgmirbudmj5@scored>

On 09:32-20231114, Tony Lindgren wrote:
> The devices in the wkup domain are capable of waking up the system from
> suspend. We can configure the wkup domain devices in a generic way using
> the ti-sysc interconnect target module driver like we have done with the
> earlier TI SoCs.
> 
> As ti-sysc manages the SYSCONFIG related registers independent of the
> child hardware device, the wake-up configuration is also set even if
> wkup_uart0 is reserved by sysfw.
> 
> The wkup_uart0 device has interconnect target module register mapping like
> dra7 wkup uart. There is a 1 MB interconnect target range with one uart IP
> block in the target module. The power domain and clock affects the whole
> interconnect target module.
> 
> Note we change the functional clock name to follow the ti-sysc binding
> and use "fck" instead of "fclk".
> 
> Tested-by: Dhruva Gole <d-gole at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
> 
> Changes since v1:
> 
> - Added Tested-by from Dhruva
> 
> ---
>  arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi | 33 ++++++++++++++++++----
>  1 file changed, 27 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
> --- a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
> @@ -5,6 +5,8 @@
>   * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
>   */
>  
> +#include <dt-bindings/bus/ti-sysc.h>
> +
>  &cbass_wakeup {
>  	wkup_conf: syscon at 43000000 {
>  		bootph-all;
> @@ -21,14 +23,33 @@ chipid: chipid at 14 {
>  		};
>  	};
>  
> -	wkup_uart0: serial at 2b300000 {
> -		compatible = "ti,am64-uart", "ti,am654-uart";
> -		reg = <0x00 0x2b300000 0x00 0x100>;
> -		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> +	target-module at 2b300000 {

should be  target-module at 2b300050 to match up with reg?

> +		compatible = "ti,sysc-omap2", "ti,sysc";
> +		reg = <0 0x2b300050 0 0x4>,
> +		      <0 0x2b300054 0 0x4>,
> +		      <0 0x2b300058 0 0x4>;
> +		reg-names = "rev", "sysc", "syss";
> +		ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
> +				 SYSC_OMAP2_SOFTRESET |
> +				 SYSC_OMAP2_AUTOIDLE)>;
> +		ti,sysc-sidle = <SYSC_IDLE_FORCE>,
> +				<SYSC_IDLE_NO>,
> +				<SYSC_IDLE_SMART>,
> +				<SYSC_IDLE_SMART_WKUP>;
> +		ti,syss-mask = <1>;
>  		power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
>  		clocks = <&k3_clks 114 0>;
> -		clock-names = "fclk";
> -		status = "disabled";
> +		clock-names = "fck";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges = <0 0 0x2b300000 0x100000>;
> +
> +		wkup_uart0: serial at 2b300000 {

serial at 0  to match up with reg?

> +			compatible = "ti,am64-uart", "ti,am654-uart";
> +			reg = <0 0x100>;
> +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +		};
>  	};
>  
>  	wkup_i2c0: i2c at 2b200000 {
> -- 
> 2.42.1

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From lukasz.luba at arm.com  Fri Dec 15 08:03:28 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Fri, 15 Dec 2023 16:03:28 +0000
Subject: [PATCH 2/4] sched: Take cpufreq feedback into account
In-Reply-To: <20231212142730.998913-3-vincent.guittot@linaro.org>
References: <20231212142730.998913-1-vincent.guittot@linaro.org>
 <20231212142730.998913-3-vincent.guittot@linaro.org>
Message-ID: <06412759-659c-4b80-b946-f533775baa02@arm.com>



On 12/12/23 14:27, Vincent Guittot wrote:
> Aggregate the different pressures applied on the capacity of CPUs and
> create a new function that returns the actual capacity of the CPU:
>    get_actual_cpu_capacity()
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>   kernel/sched/fair.c | 43 +++++++++++++++++++++++--------------------
>   1 file changed, 23 insertions(+), 20 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index bcea3d55d95d..11d3be829302 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4932,12 +4932,20 @@ static inline void util_est_update(struct cfs_rq *cfs_rq,
>   	trace_sched_util_est_se_tp(&p->se);
>   }
>   
> +static inline unsigned long get_actual_cpu_capacity(int cpu)
> +{
> +	unsigned long capacity = arch_scale_cpu_capacity(cpu);
> +
> +	capacity -= max(thermal_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
> +
> +	return capacity;
> +}
>   static inline int util_fits_cpu(unsigned long util,
>   				unsigned long uclamp_min,
>   				unsigned long uclamp_max,
>   				int cpu)
>   {
> -	unsigned long capacity_orig, capacity_orig_thermal;
> +	unsigned long capacity_orig;
>   	unsigned long capacity = capacity_of(cpu);
>   	bool fits, uclamp_max_fits;
>   
> @@ -4970,7 +4978,6 @@ static inline int util_fits_cpu(unsigned long util,
>   	 * goal is to cap the task. So it's okay if it's getting less.
>   	 */
>   	capacity_orig = arch_scale_cpu_capacity(cpu);
> -	capacity_orig_thermal = capacity_orig - arch_scale_thermal_pressure(cpu);
>   
>   	/*
>   	 * We want to force a task to fit a cpu as implied by uclamp_max.
> @@ -5045,7 +5052,7 @@ static inline int util_fits_cpu(unsigned long util,
>   	 * handle the case uclamp_min > uclamp_max.
>   	 */
>   	uclamp_min = min(uclamp_min, uclamp_max);
> -	if (fits && (util < uclamp_min) && (uclamp_min > capacity_orig_thermal))
> +	if (fits && (util < uclamp_min) && (uclamp_min > get_actual_cpu_capacity(cpu)))

That's quite long line, I would break it into 2.

>   		return -1;
>   
>   	return fits;
> @@ -7426,7 +7433,7 @@ select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target)
>   		 * Look for the CPU with best capacity.
>   		 */
>   		else if (fits < 0)
> -			cpu_cap = arch_scale_cpu_capacity(cpu) - thermal_load_avg(cpu_rq(cpu));
> +			cpu_cap = get_actual_cpu_capacity(cpu);
>   
>   		/*
>   		 * First, select CPU which fits better (-1 being better than 0).
> @@ -7919,8 +7926,8 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>   	struct root_domain *rd = this_rq()->rd;
>   	int cpu, best_energy_cpu, target = -1;
>   	int prev_fits = -1, best_fits = -1;
> -	unsigned long best_thermal_cap = 0;
> -	unsigned long prev_thermal_cap = 0;
> +	unsigned long best_actual_cap = 0;
> +	unsigned long prev_actual_cap = 0;
>   	struct sched_domain *sd;
>   	struct perf_domain *pd;
>   	struct energy_env eenv;
> @@ -7950,7 +7957,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>   
>   	for (; pd; pd = pd->next) {
>   		unsigned long util_min = p_util_min, util_max = p_util_max;
> -		unsigned long cpu_cap, cpu_thermal_cap, util;
> +		unsigned long cpu_cap, cpu_actual_cap, util;
>   		long prev_spare_cap = -1, max_spare_cap = -1;
>   		unsigned long rq_util_min, rq_util_max;
>   		unsigned long cur_delta, base_energy;
> @@ -7962,18 +7969,17 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>   		if (cpumask_empty(cpus))
>   			continue;
>   
> -		/* Account thermal pressure for the energy estimation */
> +		/* Account external pressure for the energy estimation */
>   		cpu = cpumask_first(cpus);
> -		cpu_thermal_cap = arch_scale_cpu_capacity(cpu);
> -		cpu_thermal_cap -= arch_scale_thermal_pressure(cpu);
> +		cpu_actual_cap = get_actual_cpu_capacity(cpu);
>   
> -		eenv.cpu_cap = cpu_thermal_cap;
> +		eenv.cpu_cap = cpu_actual_cap;
>   		eenv.pd_cap = 0;
>   
>   		for_each_cpu(cpu, cpus) {
>   			struct rq *rq = cpu_rq(cpu);
>   
> -			eenv.pd_cap += cpu_thermal_cap;
> +			eenv.pd_cap += cpu_actual_cap;
>   
>   			if (!cpumask_test_cpu(cpu, sched_domain_span(sd)))
>   				continue;
> @@ -8044,7 +8050,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>   			if (prev_delta < base_energy)
>   				goto unlock;
>   			prev_delta -= base_energy;
> -			prev_thermal_cap = cpu_thermal_cap;
> +			prev_actual_cap = cpu_actual_cap;
>   			best_delta = min(best_delta, prev_delta);
>   		}
>   
> @@ -8059,7 +8065,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>   			 * but best energy cpu has better capacity.
>   			 */
>   			if ((max_fits < 0) &&
> -			    (cpu_thermal_cap <= best_thermal_cap))
> +			    (cpu_actual_cap <= best_actual_cap))
>   				continue;
>   
>   			cur_delta = compute_energy(&eenv, pd, cpus, p,
> @@ -8080,14 +8086,14 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>   			best_delta = cur_delta;
>   			best_energy_cpu = max_spare_cap_cpu;
>   			best_fits = max_fits;
> -			best_thermal_cap = cpu_thermal_cap;
> +			best_actual_cap = cpu_actual_cap;
>   		}
>   	}
>   	rcu_read_unlock();
>   
>   	if ((best_fits > prev_fits) ||
>   	    ((best_fits > 0) && (best_delta < prev_delta)) ||
> -	    ((best_fits < 0) && (best_thermal_cap > prev_thermal_cap)))
> +	    ((best_fits < 0) && (best_actual_cap > prev_actual_cap)))
>   		target = best_energy_cpu;
>   
>   	return target;
> @@ -9466,7 +9472,7 @@ static inline void init_sd_lb_stats(struct sd_lb_stats *sds)
>   static unsigned long scale_rt_capacity(int cpu)
>   {
>   	struct rq *rq = cpu_rq(cpu);
> -	unsigned long max = arch_scale_cpu_capacity(cpu);
> +	unsigned long max = get_actual_cpu_capacity(cpu);

Maybe it's not strictly related to this patch, but I would swap the
2 above lines, so that they will be sorted (from longest to shortest).

>   	unsigned long used, free;
>   	unsigned long irq;
>   
> @@ -9478,12 +9484,9 @@ static unsigned long scale_rt_capacity(int cpu)
>   	/*
>   	 * avg_rt.util_avg and avg_dl.util_avg track binary signals
>   	 * (running and not running) with weights 0 and 1024 respectively.
> -	 * avg_thermal.load_avg tracks thermal pressure and the weighted
> -	 * average uses the actual delta max capacity(load).
>   	 */
>   	used = READ_ONCE(rq->avg_rt.util_avg);
>   	used += READ_ONCE(rq->avg_dl.util_avg);
> -	used += thermal_load_avg(rq);
>   
>   	if (unlikely(used >= max))
>   		return 1;

The rest looks good

Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>


From Jonathan.Cameron at Huawei.com  Fri Dec 15 08:11:57 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 16:11:57 +0000
Subject: [PATCH RFC v3 09/21] ACPI: convert acpi_processor_post_eject()
 to use IS_ENABLED()
In-Reply-To: <E1rDOgX-00DvkQ-Lg@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOgX-00DvkQ-Lg@rmk-PC.armlinux.org.uk>
Message-ID: <20231215161157.00000630@Huawei.com>

On Wed, 13 Dec 2023 12:49:57 +0000
"Russell King (Oracle)" <rmk+kernel at armlinux.org.uk> wrote:

> Rather than ifdef'ing acpi_processor_post_eject() and its use site, use
> IS_ENABLED() to increase compile coverage.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>

Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>


From Jonathan.Cameron at Huawei.com  Fri Dec 15 08:15:39 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 16:15:39 +0000
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or
 functional) devices
In-Reply-To: <ZXxxa+XZjPZtNfJ+@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOfs-00DvjY-HQ@rmk-PC.armlinux.org.uk>
	<20231214173241.0000260f@Huawei.com>
	<CAJZ5v0jymOtZ0y65K9wE8FJk+ZKwP+FoGm4AKHXcYVfQJL9MVw@mail.gmail.com>
	<ZXtFBYJEX2RrFrwj@shell.armlinux.org.uk>
	<CAJZ5v0h2Keyb-gFWFuPsKtwqjXvM2snyGpo6MMfFzaXKbfEpgw@mail.gmail.com>
	<CAJZ5v0h3WWtvrbxRpaGfq6c756k+L1SzZ1Gv3A14JxXHNcUMKA@mail.gmail.com>
	<ZXxxa+XZjPZtNfJ+@shell.armlinux.org.uk>
Message-ID: <20231215161539.00000940@Huawei.com>

On Fri, 15 Dec 2023 15:31:55 +0000
"Russell King (Oracle)" <linux at armlinux.org.uk> wrote:

> On Thu, Dec 14, 2023 at 07:37:10PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Dec 14, 2023 at 7:16?PM Rafael J. Wysocki <rafael at kernel.org> wrote:  
> > >
> > > On Thu, Dec 14, 2023 at 7:10?PM Russell King (Oracle)
> > > <linux at armlinux.org.uk> wrote:  
> > > > I guess we need something like:
> > > >
> > > >         if (device->status.present)
> > > >                 return device->device_type != ACPI_BUS_TYPE_PROCESSOR ||
> > > >                        device->status.enabled;
> > > >         else
> > > >                 return device->status.functional;
> > > >
> > > > so we only check device->status.enabled for processor-type devices?  
> > >
> > > Yes, something like this.  
> > 
> > However, that is not sufficient, because there are
> > ACPI_BUS_TYPE_DEVICE devices representing processors.
> > 
> > I'm not sure about a clean way to do it ATM.  
> 
> Ok, how about:
> 
> static bool acpi_dev_is_processor(const struct acpi_device *device)
> {
> 	struct acpi_hardware_id *hwid;
> 
> 	if (device->device_type == ACPI_BUS_TYPE_PROCESSOR)
> 		return true;
> 
> 	if (device->device_type != ACPI_BUS_TYPE_DEVICE)
> 		return false;
> 
> 	list_for_each_entry(hwid, &device->pnp.ids, list)
> 		if (!strcmp(ACPI_PROCESSOR_OBJECT_HID, hwid->id) ||
> 		    !strcmp(ACPI_PROCESSOR_DEVICE_HID, hwid->id))
> 			return true;
> 
> 	return false;
> }
> 
> and then:
> 
> 	if (device->status.present)
> 		return !acpi_dev_is_processor(device) || device->status.enabled;
> 	else
> 		return device->status.functional;
> 
> ?
> 
Changing it to CPU only for now makes sense to me and I think this code snippet should do the
job.  Nice and simple.


From Jonathan.Cameron at Huawei.com  Fri Dec 15 08:18:03 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 16:18:03 +0000
Subject: [PATCH RFC v3 10/21] ACPI: Check _STA present bit before making
 CPUs not present
In-Reply-To: <E1rDOgc-00DvkW-PZ@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOgc-00DvkW-PZ@rmk-PC.armlinux.org.uk>
Message-ID: <20231215161803.00002d8c@Huawei.com>

On Wed, 13 Dec 2023 12:50:02 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> When called acpi_processor_post_eject() unconditionally make a CPU
> not-present and unregisters it.
> 
> To add support for AML events where the CPU has become disabled, but
> remains present, the _STA method should be checked before calling
> acpi_processor_remove().
> 
> Rename acpi_processor_post_eject() acpi_processor_remove_possible(), and
> check the _STA before calling.
> 
> Adding the function prototype for arch_unregister_cpu() allows the
> preprocessor guards to be removed.
> 
> After this change CPUs will remain registered and visible to
> user-space as offline if buggy firmware triggers an eject-request,
> but doesn't clear the corresponding _STA bits after _EJ0 has been
> called.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
LGTM
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>


From johan at kernel.org  Fri Dec 15 08:18:52 2023
From: johan at kernel.org (Johan Hovold)
Date: Fri, 15 Dec 2023 17:18:52 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <ZXxa7yzKzG6048vw@francesco-nb.int.toradex.com>
References: <20231214170146.641783-1-francesco@dolcini.it>
 <ZXxWX-Fw1InID2ax@hovoldconsulting.com>
 <ZXxa7yzKzG6048vw@francesco-nb.int.toradex.com>
Message-ID: <ZXx8bCVyxJ9Ddvqm@hovoldconsulting.com>

On Fri, Dec 15, 2023 at 02:55:59PM +0100, Francesco Dolcini wrote:
> On Fri, Dec 15, 2023 at 02:36:31PM +0100, Johan Hovold wrote:
> > On Thu, Dec 14, 2023 at 06:01:46PM +0100, Francesco Dolcini wrote:
> > > From: Francesco Dolcini <francesco.dolcini at toradex.com>
> > > 
> > > receive_buf() is called from ttyport_receive_buf() that expects values
> > > ">= 0" from serdev_controller_receive_buf(), change its return type from
> > > ssize_t to size_t.

> > > -int gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> > > -				size_t count)
> > > +size_t gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> > > +		       size_t count)
> > >  {
> > > -	int ret;
> > > +	size_t ret;
> > >  
> > >  	ret = kfifo_in(&gdev->read_fifo, buf, count);
> > >  
> > 
> > Why are you changing this function? This is part of the GNSS interface
> > and has nothing to do with the rest of this patch.
> 
> good point, thanks for looking into that.
> 
> from my understanding kfifo_in() already return an unsigned, both
> __kfifo_in and __kfifo_in_r return unsigned.

Correct.

> With that said this is used by 3 drivers:
> 
> = drivers/gnss/sirf.c:
> = drivers/gnss/serial.c:
> 
> The driver just use it into the actual receive_buf callback.
> 
> = drivers/gnss/usb.c
> 
> This driver does nothing with a negative return value (that is never the
> less not possible), it just check that the whole buffer was inserted.

That driver also knows it will never be negative.

And you forgot about

	drivers/net/ethernet/intel/ice/ice_gnss.c

> To me the change is correct, with that said probably this should have
> been explicitly mentioned in the commit message or a separate
> preparation patch.

It's a separate change and should not be hidden away in a tree-wide
change that goes through a different maintainer.

Please drop this change from this patch and resubmit it separately to me
if you want and I'll review when I have the time.

And when doing tree-wide changes, please try to follow the style of the
driver you are changing (e.g. do not introduce inconsistencies by
changing to open parenthesis alignment of continuation lines in code
that do not use it).

Johan


From mark.rutland at arm.com  Fri Dec 15 08:21:45 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 15 Dec 2023 16:21:45 +0000
Subject: [PATCH 1/2] arm: perf: Fix ARCH=arm build with GCC in
 armv8pmu_write_evtype()
In-Reply-To: <20231215150040.3342183-2-james.clark@arm.com>
References: <20231215150040.3342183-1-james.clark@arm.com>
 <20231215150040.3342183-2-james.clark@arm.com>
Message-ID: <ZXx9GW1onSy4eBEB@FVFF77S0Q05N>

On Fri, Dec 15, 2023 at 03:00:38PM +0000, James Clark wrote:
> LLVM ignores everything inside the if statement and doesn't generate
> errors, but GCC doesn't ignore it, resulting in the following error:
> 
>   drivers/perf/arm_pmuv3.c: In function 'armv8pmu_write_evtype':
>   include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
>   	34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \
> 
> Fix it by changing the if to #if.

I reckon it'd be cleaner to use GENMASK_ULL for the TH and TC fields, in
include/linux/perf/arm_pmu.h have:

| /*
|  * PMXEVTYPER: Event selection reg
|  */
| #define ARMV8_PMU_EVTYPE_EVENT GENMASK(15, 0)          /* Mask for EVENT bits */
| #define ARMV8_PMU_EVTYPE_TH    GENMASK_ULL(43, 32)     /* arm64 only */
| #define ARMV8_PMU_EVTYPE_TC    GENMASK_ULL(63, 61)     /* arm64 only */

IIUC that should silence this warning, and it'd remove the need for the
ifdeffery and other changes in patch 2.

Does that work, or am I missing something?

Thanks,
Mark.

> 
> Fixes: 3115ee021bfb ("arm64: perf: Include threshold control fields in PMEVTYPER mask")
> Reported-by: Uwe Kleine-K"onig <u.kleine-koenig at pengutronix.de>
> Closes: https://lore.kernel.org/linux-arm-kernel/20231215120817.h2f3akgv72zhrtqo at pengutronix.de/
> Signed-off-by: James Clark <james.clark at arm.com>
> ---
>  drivers/perf/arm_pmuv3.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index 23fa6c5da82c..3ed2086cefc3 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -631,8 +631,9 @@ static void armv8pmu_write_evtype(int idx, unsigned long val)
>  			     ARMV8_PMU_EXCLUDE_EL0 |
>  			     ARMV8_PMU_EXCLUDE_EL1;
>  
> -	if (IS_ENABLED(CONFIG_ARM64))
> -		mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
> +#if IS_ENABLED(CONFIG_ARM64)
> +	mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
> +#endif
>  
>  	val &= mask;
>  	write_pmevtypern(counter, val);
> -- 
> 2.34.1
> 


From Jonathan.Cameron at Huawei.com  Fri Dec 15 08:23:22 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 16:23:22 +0000
Subject: [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields
In-Reply-To: <E1rDOgs-00Dvko-6t@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOgs-00Dvko-6t@rmk-PC.armlinux.org.uk>
Message-ID: <20231215162322.00007391@Huawei.com>

On Wed, 13 Dec 2023 12:50:18 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> Add the new flag field to the MADT's GICC structure.
> 
> 'Online Capable' indicates a disabled CPU can be enabled later. See
> ACPI specification 6.5 Tabel 5.37: GICC CPU Interface Flags.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>

I see there is an acpica pull request including this bit but with a different name
For reference.
https://github.com/acpica/acpica/pull/914/commits/453a5f67567786522021d5f6913f561f8b3cabf6

+CC Lorenzo who submitted that.

> ---
> This patch probably needs to go via the upstream acpica project,
> but is included here so the feature can be tested.
> 
> If the ACPICA header files are updated before merging this patch set,
> this patch will need to be dropped.
> 
> Changes since RFC v2:
>  * Add ACPI specification reference.
> ---
>  include/acpi/actbl2.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> index 3751ae69432f..c433a079d8e1 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -1046,6 +1046,7 @@ struct acpi_madt_generic_interrupt {
>  /* ACPI_MADT_ENABLED                    (1)      Processor is usable if set */
>  #define ACPI_MADT_PERFORMANCE_IRQ_MODE  (1<<1)	/* 01: Performance Interrupt Mode */
>  #define ACPI_MADT_VGIC_IRQ_MODE         (1<<2)	/* 02: VGIC Maintenance Interrupt mode */
> +#define ACPI_MADT_GICC_CPU_CAPABLE      (1<<3)	/* 03: CPU is online capable */

ACPI_MADT_GICC_ONLINE_CAPABLE

>  
>  /* 12: Generic Distributor (ACPI 5.0 + ACPI 6.0 changes) */
>  



From broonie at kernel.org  Fri Dec 15 08:26:55 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 15 Dec 2023 16:26:55 +0000
Subject: [PATCH 1/2] spi: pl022: delete description of cur_msg
In-Reply-To: <f06a9b6eac184cc648ae7444c480add6da87a84d.1702639801.git.namcao@linutronix.de>
References: <f06a9b6eac184cc648ae7444c480add6da87a84d.1702639801.git.namcao@linutronix.de>
Message-ID: <170265761567.87261.2454124954064239265.b4-ty@kernel.org>

On Fri, 15 Dec 2023 12:33:37 +0100, Nam Cao wrote:
> The variable cur_msg was removed, but its description is left behind.
> Delete this description.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/2] spi: pl022: delete description of cur_msg
      commit: e695c1fc5a3db1e161abe8061d715a504aff3f9f
[2/2] spi: pl022: update description of internal_cs_control()
      commit: 644f315d12ea29a67bc985d06ab0962452eb3605

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From johan at kernel.org  Fri Dec 15 08:32:27 2023
From: johan at kernel.org (Johan Hovold)
Date: Fri, 15 Dec 2023 17:32:27 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <ZXxbx+laQk35W56U@francesco-nb.int.toradex.com>
References: <20231214170146.641783-1-francesco@dolcini.it>
 <ZXxZzd1iBOCmnczH@hovoldconsulting.com>
 <ZXxbx+laQk35W56U@francesco-nb.int.toradex.com>
Message-ID: <ZXx_m1R0x7omubxE@hovoldconsulting.com>

On Fri, Dec 15, 2023 at 02:59:35PM +0100, Francesco Dolcini wrote:
> On Fri, Dec 15, 2023 at 02:51:09PM +0100, Johan Hovold wrote:
> > On Thu, Dec 14, 2023 at 06:01:46PM +0100, Francesco Dolcini wrote:
> > > From: Francesco Dolcini <francesco.dolcini at toradex.com>
> > > 
> > > receive_buf() is called from ttyport_receive_buf() that expects values
> > > ">= 0" from serdev_controller_receive_buf(), change its return type from
> > > ssize_t to size_t.

> > >  drivers/bluetooth/btmtkuart.c              |  4 ++--
> > >  drivers/bluetooth/btnxpuart.c              |  4 ++--

> > > -static ssize_t btnxpuart_receive_buf(struct serdev_device *serdev,
> > > -				     const u8 *data, size_t count)
> > > +static size_t btnxpuart_receive_buf(struct serdev_device *serdev,
> > > +				    const u8 *data, size_t count)
> > >  {
> > >  	struct btnxpuart_dev *nxpdev = serdev_device_get_drvdata(serdev);
> > 
> > A quick check of just the first two functions here shows that they can
> > return negative values.
> 
> This is already fixed. Patches are in next.
> 
> There were 3 buggy user of this API.
>  - 1 patch was merged a few days ago in mainline
>  - 2 patches are in next, the maintainer decided to wait for the next merge window
> 
> commit 687d2de93b11 ("Bluetooth: btmtkuart: fix recv_buf() return value")
> commit 7954bbcdd7ea ("Bluetooth: btnxpuart: fix recv_buf() return value")
> commit c8820c92caf0 ("platform/surface: aggregator: fix recv_buf() return value")

Then why was that not mentioned in the patch (e.g. below the --- line)?

You are certainly not making it easy for reviewers, but good to see that
you thought about this, and I see now when reviewing the mail archives
that those bugs were the reason for this patch in the first place.

Johan


From Jonathan.Cameron at Huawei.com  Fri Dec 15 08:33:01 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 16:33:01 +0000
Subject: [PATCH RFC v3 14/21] irqchip/gic-v3: Don't return errors from
 gic_acpi_match_gicc()
In-Reply-To: <E1rDOgx-00Dvkv-Bb@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOgx-00Dvkv-Bb@rmk-PC.armlinux.org.uk>
Message-ID: <20231215163301.0000183a@Huawei.com>

On Wed, 13 Dec 2023 12:50:23 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> gic_acpi_match_gicc() is only called via gic_acpi_count_gicr_regions().
> It should only count the number of enabled redistributors, but it
> also tries to sanity check the GICC entry, currently returning an
> error if the Enabled bit is set, but the gicr_base_address is zero.
> 
> Adding support for the online-capable bit to the sanity check
> complicates it, for no benefit. The existing check implicitly
> depends on gic_acpi_count_gicr_regions() previous failing to find
> any GICR regions (as it is valid to have gicr_base_address of zero if
> the redistributors are described via a GICR entry).
> 
> Instead of complicating the check, remove it. Failures that happen
> at this point cause the irqchip not to register, meaning no irqs
> can be requested. The kernel grinds to a panic() pretty quickly.
> 
> Without the check, MADT tables that exhibit this problem are still
> caught by gic_populate_rdist(), which helpfully also prints what
> went wrong:
> | CPU4: mpidr 100 has no re-distributor!
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Reviewed-by: Gavin Shan <gshan at redhat.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> ---
>  drivers/irqchip/irq-gic-v3.c | 18 ++++++------------
>  1 file changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 98b0329b7154..ebecd4546830 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -2420,21 +2420,15 @@ static int __init gic_acpi_match_gicc(union acpi_subtable_headers *header,
>  
>  	/*
>  	 * If GICC is enabled and has valid gicr base address, then it means
> -	 * GICR base is presented via GICC
> +	 * GICR base is presented via GICC. The redistributor is only known to
> +	 * be accessible if the GICC is marked as enabled. If this bit is not
> +	 * set, we'd need to add the redistributor at runtime, which isn't
> +	 * supported.
>  	 */
> -	if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) {
> +	if (gicc->flags & ACPI_MADT_ENABLED && gicc->gicr_base_address)

I was very vague in previous review.  I think the reasons you are switching
from acpi_gicc_is_useable(gicc) to the gicc->flags & ACPI_MADT_ENABLED
needs calling out as I'm fairly sure that this point in the series at least
acpi_gicc_is_usable is same as current upstream:

static inline bool acpi_gicc_is_usable(struct acpi_madt_generic_interrupt *gicc)
{
	return gicc->flags & ACPI_MADT_ENABLED;
}

>  		acpi_data.enabled_rdists++;
> -		return 0;
> -	}
>  
> -	/*
> -	 * It's perfectly valid firmware can pass disabled GICC entry, driver
> -	 * should not treat as errors, skip the entry instead of probe fail.
> -	 */
> -	if (!acpi_gicc_is_usable(gicc))
> -		return 0;
> -
> -	return -ENODEV;
> +	return 0;
>  }
>  
>  static int __init gic_acpi_count_gicr_regions(void)



From yury.norov at gmail.com  Fri Dec 15 08:35:40 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Fri, 15 Dec 2023 08:35:40 -0800
Subject: [PATCH v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <CAG_fn=WcrNqV4burBRPZZwoBLwgia7kerZ8g2vV5spzWF=houQ@mail.gmail.com>
References: <20231214110639.2294687-1-glider@google.com>
 <20231214110639.2294687-5-glider@google.com>
 <ZXtircr4TllpqyeS@yury-ThinkPad>
 <CAG_fn=WcrNqV4burBRPZZwoBLwgia7kerZ8g2vV5spzWF=houQ@mail.gmail.com>
Message-ID: <ZXyAXPxlmq11rp2Y@yury-ThinkPad>

On Fri, Dec 15, 2023 at 04:19:27PM +0100, Alexander Potapenko wrote:
> >
> > That looks weird... You're casting address of a 'data' to a bitmap
> > instead of 'data'. At the 1st glance it makes little sense because
> > 'data' is passed as parameter. Moreover, in mte_is_compressed()
> > you pass 'data', not '&data'. Can you please comment on your
> > intention?
> 
> Although `data` is a void*, it actually contains 64 bits of compressed
> data, so we pass &data to mte_bitmap_read() to read its contents.
> Perhaps I'd better make `data` an unsigned long to avoid confusion.
 
Still don't understand. Let's consider this example:

yury:linux$ cat tst.c
#include <stdio.h>

unsigned long data[1] = {0xabc};

void foo(unsigned long *data)
{
	printf("foo:  *data\t%lx\n", (unsigned long)*data);
	printf("foo:   data\t%lx\n",  (unsigned long)data);
	printf("foo:  &data\t%lx\n", (unsigned long)&data);
}

void bar(unsigned long *data)
{
	volatile unsigned long x[100];

	printf("bar:  *data\t%lx\n", (unsigned long)*data);
	printf("bar:   data\t%lx\n",  (unsigned long)data);
	printf("bar:  &data\t%lx\n", (unsigned long)&data);
}

int main(int argc, char *argv[])
{

	foo(data);
	bar(data);

	printf("main: *data\t%lx\n", (unsigned long)*data);
	printf("main:  data\t%lx\n",  (unsigned long)data);
	printf("main: &data\t%lx\n", (unsigned long)&data);

	return 0;
}
yury:linux$ gcc tst.c -O0
yury:linux$ ./a.out
foo:  *data	abc
foo:   data	555b2cef9010
foo:  &data	7fff39d6e5f8
bar:  *data	abc
bar:   data	555b2cef9010
bar:  &data	7fff39d6e2c8
main: *data	abc
main:  data	555b2cef9010
main: &data	555b2cef9010

Data and *data have their meaning across scope boundary: a pointer and
a content. The &data is pretty much a random number - a pointer to
somewhere on a function's stack. Isn't?

> > > +     max_ranges = MTE_MAX_RANGES;
> > > +     /* Skip the leading bit indicating the inline case. */
> > > +     mte_bitmap_read(bitmap, &bit_pos, 1);
> > > +     largest_idx =
> > > +             mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_LARGEST_IDX);
> >
> > Nit: really no need to split the line - we're OK with 100-chars per
> > line now.
> 
> That's true, but I am relying on clang-format here (maybe we should
> extend the limit in .clang-format?)

If clang-format hurts readability, don't use it.

Thanks,
Yury


From Jonathan.Cameron at Huawei.com  Fri Dec 15 08:38:35 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 16:38:35 +0000
Subject: [PATCH RFC v3 15/21] irqchip/gic-v3: Add support for ACPI's
 disabled but 'online capable' CPUs
In-Reply-To: <E1rDOh2-00Dvl1-H6@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOh2-00Dvl1-H6@rmk-PC.armlinux.org.uk>
Message-ID: <20231215163835.00005d02@Huawei.com>

On Wed, 13 Dec 2023 12:50:28 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> To support virtual CPU hotplug, ACPI has added an 'online capable' bit
> to the MADT GICC entries. This indicates a disabled CPU entry may not
> be possible to online via PSCI until firmware has set enabled bit in
> _STA.
> 
> What about the redistributor in the GICC entry? ACPI doesn't want to say.
> Assume the worst: When a redistributor is described in the GICC entry,
> but the entry is marked as disabled at boot, assume the redistributor
> is inaccessible.
> 
> The GICv3 driver doesn't support late online of redistributors, so this
> means the corresponding CPU can't be brought online either. Clear the
> possible and present bits.
> 
> Systems that want CPU hotplug in a VM can ensure their redistributors
> are always-on, and describe them that way with a GICR entry in the MADT.
> 
> When mapping redistributors found via GICC entries, handle the case
> where the arch code believes the CPU is present and possible, but it
> does not have an accessible redistributor. Print a warning and clear
> the present and possible bits.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>

Seems resonable, but this contains the blob that makes the change I called
out in the previous patch relevant. With a forwards reference in that patch.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

> ----
> Disabled but online-capable CPUs cause this message to be printed
> if their redistributors are described via GICC:
> | GICv3: CPU 3's redistributor is inaccessible: this CPU can't be brought online
> 
> If ACPI's _STA tries to make the cpu present later, this message is printed:
> | Changing CPU present bit is not supported
> 
> Changes since RFC v2:
>  * use gicc->flags & (ACPI_MADT_ENABLED | ACPI_MADT_GICC_CPU_CAPABLE)
> ---
>  drivers/irqchip/irq-gic-v3.c | 14 ++++++++++++++
>  include/linux/acpi.h         |  2 +-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index ebecd4546830..6d0f98d3540e 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -2370,11 +2370,25 @@ gic_acpi_parse_madt_gicc(union acpi_subtable_headers *header,
>  				(struct acpi_madt_generic_interrupt *)header;
>  	u32 reg = readl_relaxed(acpi_data.dist_base + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
>  	u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
> +	int cpu = get_cpu_for_acpi_id(gicc->uid);
>  	void __iomem *redist_base;
>  
>  	if (!acpi_gicc_is_usable(gicc))
>  		return 0;
>  
> +	/*
> +	 * Capable but disabled CPUs can be brought online later. What about
> +	 * the redistributor? ACPI doesn't want to say!
> +	 * Virtual hotplug systems can use the MADT's "always-on" GICR entries.
> +	 * Otherwise, prevent such CPUs from being brought online.
> +	 */
> +	if (!(gicc->flags & ACPI_MADT_ENABLED)) {
> +		pr_warn_once("CPU %u's redistributor is inaccessible: this CPU can't be brought online\n", cpu);
> +		set_cpu_present(cpu, false);
> +		set_cpu_possible(cpu, false);
> +		return 0;
> +	}
> +
>  	redist_base = ioremap(gicc->gicr_base_address, size);
>  	if (!redist_base)
>  		return -ENOMEM;
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 19d009ca9e7a..00be66683505 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -238,7 +238,7 @@ void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
>  
>  static inline bool acpi_gicc_is_usable(struct acpi_madt_generic_interrupt *gicc)
>  {
> -	return gicc->flags & ACPI_MADT_ENABLED;
> +	return gicc->flags & (ACPI_MADT_ENABLED | ACPI_MADT_GICC_CPU_CAPABLE);

This is where the change is made that broke the code path in
the previous patch.  No problem with splitting that across patches but maybe call out
why in the patch intro for previous patch.

>  }
>  
>  /* the following numa functions are architecture-dependent */



From Jonathan.Cameron at Huawei.com  Fri Dec 15 08:40:27 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 16:40:27 +0000
Subject: [PATCH RFC v3 16/21] arm64: psci: Ignore DENIED CPUs
In-Reply-To: <E1rDOh7-00Dvl7-LR@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOh7-00Dvl7-LR@rmk-PC.armlinux.org.uk>
Message-ID: <20231215164027.00003609@Huawei.com>

On Wed, 13 Dec 2023 12:50:33 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: Jean-Philippe Brucker <jean-philippe at linaro.org>
> 
> When a CPU is marked as disabled, but online capable in the MADT, PSCI
> applies some firmware policy to control when it can be brought online.
> PSCI returns DENIED to a CPU_ON request if this is not currently
> permitted. The OS can learn the current policy from the _STA enabled bit.
> 
> Handle the PSCI DENIED return code gracefully instead of printing an
> error.
> 
> See https://developer.arm.com/documentation/den0022/f/?lang=en page 58.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
> [ morse: Rewrote commit message ]
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>


From aford173 at gmail.com  Fri Dec 15 08:40:22 2023
From: aford173 at gmail.com (Adam Ford)
Date: Fri, 15 Dec 2023 10:40:22 -0600
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <20231215142308.GL21146@pendragon.ideasonboard.com>
References: <20230920171009.3193296-1-l.stach@pengutronix.de>
 <20230920171009.3193296-2-l.stach@pengutronix.de> <20230920205736.GB7723@pendragon.ideasonboard.com>
 <CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>
 <CAOMZO5C7_Rj-Ja0BO0D0Po+gy+XbvyMdQf-wH5YNyhAdMof2vg@mail.gmail.com> <20231215142308.GL21146@pendragon.ideasonboard.com>
Message-ID: <CAHCN7xJPg_Nk=o9fKwkZfVTNSB-YL0m7vY6p1O7+i=PHShp7hg@mail.gmail.com>

On Fri, Dec 15, 2023 at 8:23?AM Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>
> On Fri, Dec 15, 2023 at 10:31:27AM -0300, Fabio Estevam wrote:
> > On Sun, Dec 10, 2023 at 2:35?PM Adam Ford wrote:
> >
> > > Lucas,
> > >
> > > It's been a few months since there has been any action.  If you want,
> > > I can help apply the suggestions that Laurent has and re-submit with
> > > both of our names if you want.  It would be nice to get this
> > > integrated.
> >
> > It would be nice if you could re-submit the series.
>
> Yes, that would be nice. It shouldn't cause any issue, the patches will
> retain Lucas' authorship.

I started looking into this today, but there appears to be some
dependencies missing because the PVI is just one small portion of
this. The PVI needs to interact with the hdmi_blk_ctrl and the hdmi
transmitter itself.

It looks like there was at least one attempt to push the hdmi driver,
but we're also missing some hdmi power domain information, and the dri
patchwork lists a bunch of proposed patches for the lcdif driver.  I
haven't looked through them all, so I don't know if they are
necessary.  I found a git repo with Lucas' stuff, but it's based on
the 6.0 kernel, so it's fairly old.  Either way it seems like there is
more to the HDMI than just his one series.

adam
>
> --
> Regards,
>
> Laurent Pinchart


From festevam at gmail.com  Fri Dec 15 08:47:09 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 15 Dec 2023 13:47:09 -0300
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <CAHCN7xJPg_Nk=o9fKwkZfVTNSB-YL0m7vY6p1O7+i=PHShp7hg@mail.gmail.com>
References: <20230920171009.3193296-1-l.stach@pengutronix.de>
 <20230920171009.3193296-2-l.stach@pengutronix.de> <20230920205736.GB7723@pendragon.ideasonboard.com>
 <CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>
 <CAOMZO5C7_Rj-Ja0BO0D0Po+gy+XbvyMdQf-wH5YNyhAdMof2vg@mail.gmail.com>
 <20231215142308.GL21146@pendragon.ideasonboard.com> <CAHCN7xJPg_Nk=o9fKwkZfVTNSB-YL0m7vY6p1O7+i=PHShp7hg@mail.gmail.com>
Message-ID: <CAOMZO5AGAkPpds=5H-iQj53djcQtW5GsRQrzdC_JOOrcENhvvw@mail.gmail.com>

Hi Adam,

On Fri, Dec 15, 2023 at 1:40?PM Adam Ford <aford173 at gmail.com> wrote:

> I started looking into this today, but there appears to be some
> dependencies missing because the PVI is just one small portion of
> this. The PVI needs to interact with the hdmi_blk_ctrl and the hdmi
> transmitter itself.
>
> It looks like there was at least one attempt to push the hdmi driver,
> but we're also missing some hdmi power domain information, and the dri
> patchwork lists a bunch of proposed patches for the lcdif driver.  I
> haven't looked through them all, so I don't know if they are
> necessary.  I found a git repo with Lucas' stuff, but it's based on
> the 6.0 kernel, so it's fairly old.  Either way it seems like there is
> more to the HDMI than just his one series.

Here is the whole patchset that I tested against 6.6:

https://patchwork.freedesktop.org/patch/485391/
https://patchwork.freedesktop.org/patch/485392/
https://patchwork.freedesktop.org/patch/485395/
https://patchwork.freedesktop.org/patch/515299/
https://patchwork.freedesktop.org/patch/515300/
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220406153402.1265474-12-l.stach at pengutronix.de/


From Jonathan.Cameron at Huawei.com  Fri Dec 15 08:50:09 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 16:50:09 +0000
Subject: [PATCH RFC v3 18/21] ACPI: processor: Only call
 arch_unregister_cpu() if HOTPLUG_CPU is selected
In-Reply-To: <E1rDOhH-00DvlO-UP@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOhH-00DvlO-UP@rmk-PC.armlinux.org.uk>
Message-ID: <20231215165009.000035f2@Huawei.com>

On Wed, 13 Dec 2023 12:50:43 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> The kbuild robot points out that configurations without HOTPLUG_CPU
> selected can try to build acpi_processor_post_eject() without success
> as arch_unregister_cpu() is not defined.
> 
> Check this explicitly. This will be merged into:
> | ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
> for any subsequent posting.
> 
> Reported-by: kbuild test robot <lkp at intel.com>
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> ---
> This should probably be squashed into an earlier patch.

Agreed. If not
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>




From linux at armlinux.org.uk  Fri Dec 15 08:53:28 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Fri, 15 Dec 2023 16:53:28 +0000
Subject: [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields
In-Reply-To: <20231215162322.00007391@Huawei.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOgs-00Dvko-6t@rmk-PC.armlinux.org.uk>
 <20231215162322.00007391@Huawei.com>
Message-ID: <ZXyEiHLFBsoUkfNI@shell.armlinux.org.uk>

On Fri, Dec 15, 2023 at 04:23:22PM +0000, Jonathan Cameron wrote:
> On Wed, 13 Dec 2023 12:50:18 +0000
> Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> 
> > From: James Morse <james.morse at arm.com>
> > 
> > Add the new flag field to the MADT's GICC structure.
> > 
> > 'Online Capable' indicates a disabled CPU can be enabled later. See
> > ACPI specification 6.5 Tabel 5.37: GICC CPU Interface Flags.
> > 
> > Signed-off-by: James Morse <james.morse at arm.com>
> > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> 
> I see there is an acpica pull request including this bit but with a different name
> For reference.
> https://github.com/acpica/acpica/pull/914/commits/453a5f67567786522021d5f6913f561f8b3cabf6
> 
> +CC Lorenzo who submitted that.

> > +#define ACPI_MADT_GICC_CPU_CAPABLE      (1<<3)	/* 03: CPU is online capable */
> 
> ACPI_MADT_GICC_ONLINE_CAPABLE

It's somewhat disappointing, but no big deal. It's easy enough to change
"irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs"
to use Lorenzo's name when that patch hits - and it becomes one less
patch in this patch set when Lorenzo's change eventually hits mainline.

Does anyone know how long it may take for Lorenzo's change to get into
mainline? Would it be by the 6.8 merge window or the following one?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From yury.norov at gmail.com  Fri Dec 15 09:01:34 2023
From: yury.norov at gmail.com (Yury Norov)
Date: Fri, 15 Dec 2023 09:01:34 -0800
Subject: [PATCH v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <ZXyAXPxlmq11rp2Y@yury-ThinkPad>
References: <20231214110639.2294687-1-glider@google.com>
 <20231214110639.2294687-5-glider@google.com>
 <ZXtircr4TllpqyeS@yury-ThinkPad>
 <CAG_fn=WcrNqV4burBRPZZwoBLwgia7kerZ8g2vV5spzWF=houQ@mail.gmail.com>
 <ZXyAXPxlmq11rp2Y@yury-ThinkPad>
Message-ID: <ZXyGbhJqzNxbd3ay@yury-ThinkPad>

On Fri, Dec 15, 2023 at 08:35:43AM -0800, Yury Norov wrote:
> On Fri, Dec 15, 2023 at 04:19:27PM +0100, Alexander Potapenko wrote:
> > >
> > > That looks weird... You're casting address of a 'data' to a bitmap
> > > instead of 'data'. At the 1st glance it makes little sense because
> > > 'data' is passed as parameter. Moreover, in mte_is_compressed()
> > > you pass 'data', not '&data'. Can you please comment on your
> > > intention?
> > 
> > Although `data` is a void*, it actually contains 64 bits of compressed
> > data, so we pass &data to mte_bitmap_read() to read its contents.
> > Perhaps I'd better make `data` an unsigned long to avoid confusion.
>  
> Still don't understand. Let's consider this example:
> 
> yury:linux$ cat tst.c
> #include <stdio.h>
> 
> unsigned long data[1] = {0xabc};
> 
> void foo(unsigned long *data)
> {
> 	printf("foo:  *data\t%lx\n", (unsigned long)*data);
> 	printf("foo:   data\t%lx\n",  (unsigned long)data);
> 	printf("foo:  &data\t%lx\n", (unsigned long)&data);
> }
> 
> void bar(unsigned long *data)
> {
> 	volatile unsigned long x[100];
> 
> 	printf("bar:  *data\t%lx\n", (unsigned long)*data);
> 	printf("bar:   data\t%lx\n",  (unsigned long)data);
> 	printf("bar:  &data\t%lx\n", (unsigned long)&data);
> }
> 
> int main(int argc, char *argv[])
> {
> 
> 	foo(data);
> 	bar(data);
> 
> 	printf("main: *data\t%lx\n", (unsigned long)*data);
> 	printf("main:  data\t%lx\n",  (unsigned long)data);
> 	printf("main: &data\t%lx\n", (unsigned long)&data);
> 
> 	return 0;
> }
> yury:linux$ gcc tst.c -O0
> yury:linux$ ./a.out
> foo:  *data	abc
> foo:   data	555b2cef9010
> foo:  &data	7fff39d6e5f8
> bar:  *data	abc
> bar:   data	555b2cef9010
> bar:  &data	7fff39d6e2c8
> main: *data	abc
> main:  data	555b2cef9010
> main: &data	555b2cef9010
> 
> Data and *data have their meaning across scope boundary: a pointer and
> a content. The &data is pretty much a random number - a pointer to
> somewhere on a function's stack. Isn't?

OK, I read now. Your 'void *data' is not a pointer, but an actual data.
Very confusing indeed... Maybe add a comment for that cast?
 


From alain.volmat at foss.st.com  Fri Dec 15 09:02:10 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:02:10 +0100
Subject: [PATCH v3 0/7] i2c: stm32f7: enhancements and support for stm32mp25
Message-ID: <20231215170223.95549-1-alain.volmat@foss.st.com>

This series first perform enhancements in the way interrupt are handled
and cleanup in messages.
Then it adds support for the stm32mp25 which differs in that
it only has a single irq line for both event/error and has a
different handling of the FastModePlus.
Support is then enabled within the stm32mp25 related device-trees.

Changelog:
v3: - addition of 2 commits dealing with readl_relaxed(I2C_ISR) in
      isr handler and a second one to use dev_err_probe during probe
    - correction of SOB in commit

v2: - correct st,stm32-i2c.yaml.  Use if then else scheme to indicate
      number of interrupts / interrupt-names depending on the
      compatible while keeping the description within the common part

    - correct 2 maybe-uninitialized warnings
          * ret in stm32f7_i2c_write_fm_plus_bits
          * irq_error in stm32f7_i2c_probe, move the platform_get_irq
            within the same if block as devm_request_threaded_irq

Alain Volmat (9):
  i2c: stm32f7: use dev_err_probe upon calls of devm_request_irq
  i2c: stm32f7: perform most of irq job in threaded handler
  i2c: stm32f7: simplify status messages in case of errors
  dt-bindings: i2c: document st,stm32mp25-i2c compatible
  i2c: stm32f7: perform I2C_ISR read once at beginning of event isr
  i2c: stm32f7: add support for stm32mp25 soc
  arm64: dts: st: add all 8 i2c nodes on stm32mp251
  arm64: dts: st: add i2c2/i2c8 pins for stm32mp25
  arm64: dts: st: add i2c2 / i2c8 properties on stm32mp257f-ev1

 .../devicetree/bindings/i2c/st,stm32-i2c.yaml |  28 ++
 arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi |  36 ++
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  96 +++++
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |  20 +
 drivers/i2c/busses/i2c-stm32f7.c              | 342 +++++++++---------
 5 files changed, 358 insertions(+), 164 deletions(-)

-- 
2.25.1



From Jonathan.Cameron at Huawei.com  Fri Dec 15 09:04:28 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 17:04:28 +0000
Subject: [PATCH RFC v3 19/21] arm64: document virtual CPU hotplug's
 expectations
In-Reply-To: <E1rDOhN-00DvlU-2e@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOhN-00DvlU-2e@rmk-PC.armlinux.org.uk>
Message-ID: <20231215170428.00000d81@Huawei.com>

On Wed, 13 Dec 2023 12:50:49 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> Add a description of physical and virtual CPU hotplug, explain the
> differences and elaborate on what is required in ACPI for a working
> virtual hotplug system.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> ---
>  Outstanding comment:
>   https://lore.kernel.org/r/20230914174137.00000a62 at Huawei.com

Hmm. This one is the comment that if we allow for a legacy unware guest, we
have no way of indicating that CPUS that were enabled at boot can ever be removed.

Effectively that means that without the cloud being aware of the VM capabilities
before it is booted (and can maybe use the proposed OSC) there is no way of knowing
if a CPU can be removed.  Sounds profitable :)

I'm fine with that.  So as long a people grasp the concern and we make sure that
the QEMU side doesn't change it's legacy behavior (I think we are fine in Salil's
latest set).

Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>


Jonathan


> ---
>  Documentation/arch/arm64/cpu-hotplug.rst | 79 ++++++++++++++++++++++++
>  Documentation/arch/arm64/index.rst       |  1 +
>  2 files changed, 80 insertions(+)
>  create mode 100644 Documentation/arch/arm64/cpu-hotplug.rst
> 
> diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst
> new file mode 100644
> index 000000000000..76ba8d932c72
> --- /dev/null
> +++ b/Documentation/arch/arm64/cpu-hotplug.rst
> @@ -0,0 +1,79 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. _cpuhp_index:
> +
> +====================
> +CPU Hotplug and ACPI
> +====================
> +
> +CPU hotplug in the arm64 world is commonly used to describe the kernel taking
> +CPUs online/offline using PSCI. This document is about ACPI firmware allowing
> +CPUs that were not available during boot to be added to the system later.
> +
> +``possible`` and ``present`` refer to the state of the CPU as seen by linux.
> +
> +
> +CPU Hotplug on physical systems - CPUs not present at boot
> +----------------------------------------------------------
> +
> +Physical systems need to mark a CPU that is ``possible`` but not ``present`` as
> +being ``present``. An example would be a dual socket machine, where the package
> +in one of the sockets can be replaced while the system is running.
> +
> +This is not supported.
> +
> +In the arm64 world CPUs are not a single device but a slice of the system.
> +There are no systems that support the physical addition (or removal) of CPUs
> +while the system is running, and ACPI is not able to sufficiently describe
> +them.
> +
> +e.g. New CPUs come with new caches, but the platform's cache toplogy is
> +described in a static table, the PPTT. How caches are shared between CPUs is
> +not discoverable, and must be described by firmware.
> +
> +e.g. The GIC redistributor for each CPU must be accessed by the driver during
> +boot to discover the system wide supported features. ACPI's MADT GICC
> +structures can describe a redistributor associated with a disabled CPU, but
> +can't describe whether the redistributor is accessible, only that it is not
> +'always on'.
> +
> +arm64's ACPI tables assume that everything described is ``present``.
> +
> +
> +CPU Hotplug on virtual systems - CPUs not enabled at boot
> +---------------------------------------------------------
> +
> +Virtual systems have the advantage that all the properties the system will
> +ever have can be described at boot. There are no power-domain considerations
> +as such devices are emulated.
> +
> +CPU Hotplug on virtual systems is supported. It is distinct from physical
> +CPU Hotplug as all resources are described as ``present``, but CPUs may be
> +marked as disabled by firmware. Only the CPU's online/offline behaviour is
> +influenced by firmware. An example is where a virtual machine boots with a
> +single CPU, and additional CPUs are added once a cloud orchestrator deploys
> +the workload.
> +
> +For a virtual machine, the VMM (e.g. Qemu) plays the part of firmware.
> +
> +Virtual hotplug is implemented as a firmware policy affecting which CPUs can be
> +brought online. Firmware can enforce its policy via PSCI's return codes. e.g.
> +``DENIED``.
> +
> +The ACPI tables must describe all the resources of the virtual machine. CPUs
> +that firmware wishes to disable either from boot (or later) should not be
> +``enabled`` in the MADT GICC structures, but should have the ``online capable``
> +bit set, to indicate they can be enabled later. The boot CPU must be marked as
> +``enabled``.  The 'always on' GICR structure must be used to describe the
> +redistributors.
> +
> +CPUs described as ``online capable`` but not ``enabled`` can be set to enabled
> +by the DSDT's Processor object's _STA method. On virtual systems the _STA method
> +must always report the CPU as ``present``. Changes to the firmware policy can
> +be notified to the OS via device-check or eject-request.
> +
> +CPUs described as ``enabled`` in the static table, should not have their _STA
> +modified dynamically by firmware. Soft-restart features such as kexec will
> +re-read the static properties of the system from these static tables, and
> +may malfunction if these no longer describe the running system. Linux will
> +re-discover the dynamic properties of the system from the _STA method later
> +during boot.
> diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
> index d08e924204bf..78544de0a8a9 100644
> --- a/Documentation/arch/arm64/index.rst
> +++ b/Documentation/arch/arm64/index.rst
> @@ -13,6 +13,7 @@ ARM64 Architecture
>      asymmetric-32bit
>      booting
>      cpu-feature-registers
> +    cpu-hotplug
>      elf_hwcaps
>      hugetlbpage
>      kdump



From alain.volmat at foss.st.com  Fri Dec 15 09:05:10 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:05:10 +0100
Subject: [PATCH v3 0/7] i2c: stm32f7: enhancements and support for
 stm32mp25
In-Reply-To: <20231215170223.95549-1-alain.volmat@foss.st.com>
References: <20231215170223.95549-1-alain.volmat@foss.st.com>
Message-ID: <20231215170510.GA95783@gnbcxd0016.gnb.st.com>

Sorry, please ignore this cover-letter, will send a new one following a
typo in the numbering of this one: 0/7 should have been 0/9

On Fri, Dec 15, 2023 at 06:02:10PM +0100, Alain Volmat wrote:
> This series first perform enhancements in the way interrupt are handled
> and cleanup in messages.
> Then it adds support for the stm32mp25 which differs in that
> it only has a single irq line for both event/error and has a
> different handling of the FastModePlus.
> Support is then enabled within the stm32mp25 related device-trees.
> 
> Changelog:
> v3: - addition of 2 commits dealing with readl_relaxed(I2C_ISR) in
>       isr handler and a second one to use dev_err_probe during probe
>     - correction of SOB in commit
> 
> v2: - correct st,stm32-i2c.yaml.  Use if then else scheme to indicate
>       number of interrupts / interrupt-names depending on the
>       compatible while keeping the description within the common part
> 
>     - correct 2 maybe-uninitialized warnings
>           * ret in stm32f7_i2c_write_fm_plus_bits
>           * irq_error in stm32f7_i2c_probe, move the platform_get_irq
>             within the same if block as devm_request_threaded_irq
> 
> Alain Volmat (9):
>   i2c: stm32f7: use dev_err_probe upon calls of devm_request_irq
>   i2c: stm32f7: perform most of irq job in threaded handler
>   i2c: stm32f7: simplify status messages in case of errors
>   dt-bindings: i2c: document st,stm32mp25-i2c compatible
>   i2c: stm32f7: perform I2C_ISR read once at beginning of event isr
>   i2c: stm32f7: add support for stm32mp25 soc
>   arm64: dts: st: add all 8 i2c nodes on stm32mp251
>   arm64: dts: st: add i2c2/i2c8 pins for stm32mp25
>   arm64: dts: st: add i2c2 / i2c8 properties on stm32mp257f-ev1
> 
>  .../devicetree/bindings/i2c/st,stm32-i2c.yaml |  28 ++
>  arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi |  36 ++
>  arch/arm64/boot/dts/st/stm32mp251.dtsi        |  96 +++++
>  arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |  20 +
>  drivers/i2c/busses/i2c-stm32f7.c              | 342 +++++++++---------
>  5 files changed, 358 insertions(+), 164 deletions(-)
> 
> -- 
> 2.25.1
> 


From alain.volmat at foss.st.com  Fri Dec 15 09:06:04 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:04 +0100
Subject: [PATCH v3 0/9] i2c: stm32f7: enhancements and support for stm32mp25
Message-ID: <20231215170617.95868-1-alain.volmat@foss.st.com>

This series first perform enhancements in the way interrupt are handled
and cleanup in messages.
Then it adds support for the stm32mp25 which differs in that
it only has a single irq line for both event/error and has a
different handling of the FastModePlus.
Support is then enabled within the stm32mp25 related device-trees.

Changelog:
v3: - addition of 2 commits dealing with readl_relaxed(I2C_ISR) in
      isr handler and a second one to use dev_err_probe during probe
    - correction of SOB in commit

v2: - correct st,stm32-i2c.yaml.  Use if then else scheme to indicate
      number of interrupts / interrupt-names depending on the
      compatible while keeping the description within the common part

    - correct 2 maybe-uninitialized warnings
          * ret in stm32f7_i2c_write_fm_plus_bits
          * irq_error in stm32f7_i2c_probe, move the platform_get_irq
            within the same if block as devm_request_threaded_irq

Alain Volmat (9):
  i2c: stm32f7: use dev_err_probe upon calls of devm_request_irq
  i2c: stm32f7: perform most of irq job in threaded handler
  i2c: stm32f7: simplify status messages in case of errors
  dt-bindings: i2c: document st,stm32mp25-i2c compatible
  i2c: stm32f7: perform I2C_ISR read once at beginning of event isr
  i2c: stm32f7: add support for stm32mp25 soc
  arm64: dts: st: add all 8 i2c nodes on stm32mp251
  arm64: dts: st: add i2c2/i2c8 pins for stm32mp25
  arm64: dts: st: add i2c2 / i2c8 properties on stm32mp257f-ev1

 .../devicetree/bindings/i2c/st,stm32-i2c.yaml |  28 ++
 arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi |  36 ++
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  96 +++++
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |  20 +
 drivers/i2c/busses/i2c-stm32f7.c              | 342 +++++++++---------
 5 files changed, 358 insertions(+), 164 deletions(-)

-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec 15 09:06:05 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:05 +0100
Subject: [PATCH v3 1/9] i2c: stm32f7: use dev_err_probe upon calls of devm_request_irq
In-Reply-To: <20231215170617.95868-1-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
Message-ID: <20231215170617.95868-2-alain.volmat@foss.st.com>

Convert error handling upon calls of devm_request_irq functions during
the probe of the driver.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 drivers/i2c/busses/i2c-stm32f7.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 983509936727..d99f152ac727 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -2199,19 +2199,13 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 					stm32f7_i2c_isr_event_thread,
 					IRQF_ONESHOT,
 					pdev->name, i2c_dev);
-	if (ret) {
-		dev_err(&pdev->dev, "Failed to request irq event %i\n",
-			irq_event);
-		return ret;
-	}
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret, "Failed to request irq event\n");
 
 	ret = devm_request_irq(&pdev->dev, irq_error, stm32f7_i2c_isr_error, 0,
 			       pdev->name, i2c_dev);
-	if (ret) {
-		dev_err(&pdev->dev, "Failed to request irq error %i\n",
-			irq_error);
-		return ret;
-	}
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret, "Failed to request irq error\n");
 
 	setup = of_device_get_match_data(&pdev->dev);
 	if (!setup) {
-- 
2.25.1



From francesco at dolcini.it  Fri Dec 15 09:07:33 2023
From: francesco at dolcini.it (Francesco Dolcini)
Date: Fri, 15 Dec 2023 18:07:33 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <ZXx8bCVyxJ9Ddvqm@hovoldconsulting.com>
References: <20231214170146.641783-1-francesco@dolcini.it>
 <ZXxWX-Fw1InID2ax@hovoldconsulting.com>
 <ZXxa7yzKzG6048vw@francesco-nb.int.toradex.com>
 <ZXx8bCVyxJ9Ddvqm@hovoldconsulting.com>
Message-ID: <ZXyH1Zv3Pxd6S3ag@francesco-nb.int.toradex.com>

Hello Johan, Greg

On Fri, Dec 15, 2023 at 05:18:52PM +0100, Johan Hovold wrote:
> On Fri, Dec 15, 2023 at 02:55:59PM +0100, Francesco Dolcini wrote:
> > To me the change is correct, with that said probably this should have
> > been explicitly mentioned in the commit message or a separate
> > preparation patch.
> 
> It's a separate change and should not be hidden away in a tree-wide
> change that goes through a different maintainer.
> 
> Please drop this change from this patch and resubmit it separately to me
> if you want and I'll review when I have the time.

Fine, I agree.

I see those options (let me know if you see other options I have not
mentioned):

1. I add this change (taking into account also intel ice) as a separate
   patch in this series and you may just ack it and Greg could merge
   together with the serdev one.
2. I prepare an independent patch for the GNSS change and only once this
   is merged I'll send a rebased v2 of this one.
3. I update this patch without this GNSS API change, that mean I will
   have to cast away the signed type from a few GNSS drivers.

1 is my preferred option, 2 is fine, but it seems a little bit of overdoing,
3 I would avoid, we are doing this cleanup to be a little bit more
strongly typed and to prevent the kind of bugs that is the original trigger
for this patch.

What would you Greg and Johan prefer?


> And when doing tree-wide changes, please try to follow the style of the
> driver you are changing (e.g. do not introduce inconsistencies by
> changing to open parenthesis alignment of continuation lines in code
> that do not use it).

ack, sorry about that, looking back at the archive is seems a recent
pain point, also Jiri fell in this trap.

Francesco



From alain.volmat at foss.st.com  Fri Dec 15 09:06:06 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:06 +0100
Subject: [PATCH v3 2/9] i2c: stm32f7: perform most of irq job in threaded handler
In-Reply-To: <20231215170617.95868-1-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
Message-ID: <20231215170617.95868-3-alain.volmat@foss.st.com>

The irq handling is currently split between the irq handler
and the threaded irq handler.  Some of the handling (such as
dma related stuffs) done within the irq handler might sleep or
take some time leading to issues if the kernel is built with
realtime constraints.  In order to fix that, perform an overall
rework to perform most of the job within the threaded handler
and only keep fifo access in the non threaded handler.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
---
 drivers/i2c/busses/i2c-stm32f7.c | 126 ++++++++++++++-----------------
 1 file changed, 56 insertions(+), 70 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index d99f152ac727..dde70e7ec722 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -1497,17 +1497,11 @@ static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev)
 static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
-	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
-	struct stm32_i2c_dma *dma = i2c_dev->dma;
-	void __iomem *base = i2c_dev->base;
-	u32 status, mask;
-	int ret = IRQ_HANDLED;
+	u32 status;
 
-	/* Check if the interrupt if for a slave device */
-	if (!i2c_dev->master_mode) {
-		ret = stm32f7_i2c_slave_isr_event(i2c_dev);
-		return ret;
-	}
+	/* Check if the interrupt is for a slave device */
+	if (!i2c_dev->master_mode)
+		return IRQ_WAKE_THREAD;
 
 	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
 
@@ -1519,6 +1513,29 @@ static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 	if (status & STM32F7_I2C_ISR_RXNE)
 		stm32f7_i2c_read_rx_data(i2c_dev);
 
+	/* Wake up the thread if other flags are raised */
+	if (status &
+	    (STM32F7_I2C_ISR_NACKF | STM32F7_I2C_ISR_STOPF |
+	     STM32F7_I2C_ISR_TC | STM32F7_I2C_ISR_TCR))
+		return IRQ_WAKE_THREAD;
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
+{
+	struct stm32f7_i2c_dev *i2c_dev = data;
+	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
+	struct stm32_i2c_dma *dma = i2c_dev->dma;
+	void __iomem *base = i2c_dev->base;
+	u32 status, mask;
+	int ret;
+
+	if (!i2c_dev->master_mode)
+		return stm32f7_i2c_slave_isr_event(i2c_dev);
+
+	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
+
 	/* NACK received */
 	if (status & STM32F7_I2C_ISR_NACKF) {
 		dev_dbg(i2c_dev->dev, "<%s>: Receive NACK (addr %x)\n",
@@ -1531,33 +1548,28 @@ static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 		f7_msg->result = -ENXIO;
 	}
 
-	/* STOP detection flag */
-	if (status & STM32F7_I2C_ISR_STOPF) {
-		/* Disable interrupts */
-		if (stm32f7_i2c_is_slave_registered(i2c_dev))
-			mask = STM32F7_I2C_XFER_IRQ_MASK;
+	if (status & STM32F7_I2C_ISR_TCR) {
+		if (f7_msg->smbus)
+			stm32f7_i2c_smbus_reload(i2c_dev);
 		else
-			mask = STM32F7_I2C_ALL_IRQ_MASK;
-		stm32f7_i2c_disable_irq(i2c_dev, mask);
-
-		/* Clear STOP flag */
-		writel_relaxed(STM32F7_I2C_ICR_STOPCF, base + STM32F7_I2C_ICR);
-
-		if (i2c_dev->use_dma && !f7_msg->result) {
-			ret = IRQ_WAKE_THREAD;
-		} else {
-			i2c_dev->master_mode = false;
-			complete(&i2c_dev->complete);
-		}
+			stm32f7_i2c_reload(i2c_dev);
 	}
 
 	/* Transfer complete */
 	if (status & STM32F7_I2C_ISR_TC) {
+		/* Wait for dma transfer completion before sending next message */
+		if (i2c_dev->use_dma && !f7_msg->result) {
+			ret = wait_for_completion_timeout(&i2c_dev->dma->dma_complete, HZ);
+			if (!ret) {
+				dev_dbg(i2c_dev->dev, "<%s>: Timed out\n", __func__);
+				stm32f7_i2c_disable_dma_req(i2c_dev);
+				dmaengine_terminate_async(dma->chan_using);
+				f7_msg->result = -ETIMEDOUT;
+			}
+		}
 		if (f7_msg->stop) {
 			mask = STM32F7_I2C_CR2_STOP;
 			stm32f7_i2c_set_bits(base + STM32F7_I2C_CR2, mask);
-		} else if (i2c_dev->use_dma && !f7_msg->result) {
-			ret = IRQ_WAKE_THREAD;
 		} else if (f7_msg->smbus) {
 			stm32f7_i2c_smbus_rep_start(i2c_dev);
 		} else {
@@ -1567,47 +1579,18 @@ static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 		}
 	}
 
-	if (status & STM32F7_I2C_ISR_TCR) {
-		if (f7_msg->smbus)
-			stm32f7_i2c_smbus_reload(i2c_dev);
+	/* STOP detection flag */
+	if (status & STM32F7_I2C_ISR_STOPF) {
+		/* Disable interrupts */
+		if (stm32f7_i2c_is_slave_registered(i2c_dev))
+			mask = STM32F7_I2C_XFER_IRQ_MASK;
 		else
-			stm32f7_i2c_reload(i2c_dev);
-	}
-
-	return ret;
-}
-
-static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
-{
-	struct stm32f7_i2c_dev *i2c_dev = data;
-	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
-	struct stm32_i2c_dma *dma = i2c_dev->dma;
-	u32 status;
-	int ret;
-
-	/*
-	 * Wait for dma transfer completion before sending next message or
-	 * notity the end of xfer to the client
-	 */
-	ret = wait_for_completion_timeout(&i2c_dev->dma->dma_complete, HZ);
-	if (!ret) {
-		dev_dbg(i2c_dev->dev, "<%s>: Timed out\n", __func__);
-		stm32f7_i2c_disable_dma_req(i2c_dev);
-		dmaengine_terminate_async(dma->chan_using);
-		f7_msg->result = -ETIMEDOUT;
-	}
+			mask = STM32F7_I2C_ALL_IRQ_MASK;
+		stm32f7_i2c_disable_irq(i2c_dev, mask);
 
-	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
+		/* Clear STOP flag */
+		writel_relaxed(STM32F7_I2C_ICR_STOPCF, base + STM32F7_I2C_ICR);
 
-	if (status & STM32F7_I2C_ISR_TC) {
-		if (f7_msg->smbus) {
-			stm32f7_i2c_smbus_rep_start(i2c_dev);
-		} else {
-			i2c_dev->msg_id++;
-			i2c_dev->msg++;
-			stm32f7_i2c_xfer_msg(i2c_dev, i2c_dev->msg);
-		}
-	} else {
 		i2c_dev->master_mode = false;
 		complete(&i2c_dev->complete);
 	}
@@ -1615,7 +1598,7 @@ static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
-static irqreturn_t stm32f7_i2c_isr_error(int irq, void *data)
+static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
 	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
@@ -2202,8 +2185,11 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 	if (ret)
 		return dev_err_probe(&pdev->dev, ret, "Failed to request irq event\n");
 
-	ret = devm_request_irq(&pdev->dev, irq_error, stm32f7_i2c_isr_error, 0,
-			       pdev->name, i2c_dev);
+	ret = devm_request_threaded_irq(&pdev->dev, irq_error,
+					NULL,
+					stm32f7_i2c_isr_error_thread,
+					IRQF_ONESHOT,
+					pdev->name, i2c_dev);
 	if (ret)
 		return dev_err_probe(&pdev->dev, ret, "Failed to request irq error\n");
 
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec 15 09:06:07 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:07 +0100
Subject: [PATCH v3 3/9] i2c: stm32f7: simplify status messages in case of errors
In-Reply-To: <20231215170617.95868-1-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
Message-ID: <20231215170617.95868-4-alain.volmat@foss.st.com>

Avoid usage of __func__ when reporting an error message
since dev_err/dev_dbg are already providing enough details
to identify the source of the message.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
---
 drivers/i2c/busses/i2c-stm32f7.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index dde70e7ec722..15100fed0a3f 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -1602,6 +1602,7 @@ static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
 	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
+	u16 addr = f7_msg->addr;
 	void __iomem *base = i2c_dev->base;
 	struct device *dev = i2c_dev->dev;
 	struct stm32_i2c_dma *dma = i2c_dev->dma;
@@ -1611,8 +1612,7 @@ static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 
 	/* Bus error */
 	if (status & STM32F7_I2C_ISR_BERR) {
-		dev_err(dev, "<%s>: Bus error accessing addr 0x%x\n",
-			__func__, f7_msg->addr);
+		dev_err(dev, "Bus error accessing addr 0x%x\n", addr);
 		writel_relaxed(STM32F7_I2C_ICR_BERRCF, base + STM32F7_I2C_ICR);
 		stm32f7_i2c_release_bus(&i2c_dev->adap);
 		f7_msg->result = -EIO;
@@ -1620,21 +1620,19 @@ static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 
 	/* Arbitration loss */
 	if (status & STM32F7_I2C_ISR_ARLO) {
-		dev_dbg(dev, "<%s>: Arbitration loss accessing addr 0x%x\n",
-			__func__, f7_msg->addr);
+		dev_dbg(dev, "Arbitration loss accessing addr 0x%x\n", addr);
 		writel_relaxed(STM32F7_I2C_ICR_ARLOCF, base + STM32F7_I2C_ICR);
 		f7_msg->result = -EAGAIN;
 	}
 
 	if (status & STM32F7_I2C_ISR_PECERR) {
-		dev_err(dev, "<%s>: PEC error in reception accessing addr 0x%x\n",
-			__func__, f7_msg->addr);
+		dev_err(dev, "PEC error in reception accessing addr 0x%x\n", addr);
 		writel_relaxed(STM32F7_I2C_ICR_PECCF, base + STM32F7_I2C_ICR);
 		f7_msg->result = -EINVAL;
 	}
 
 	if (status & STM32F7_I2C_ISR_ALERT) {
-		dev_dbg(dev, "<%s>: SMBus alert received\n", __func__);
+		dev_dbg(dev, "SMBus alert received\n");
 		writel_relaxed(STM32F7_I2C_ICR_ALERTCF, base + STM32F7_I2C_ICR);
 		i2c_handle_smbus_alert(i2c_dev->alert->ara);
 		return IRQ_HANDLED;
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec 15 09:06:08 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:08 +0100
Subject: [PATCH v3 4/9] dt-bindings: i2c: document st,stm32mp25-i2c compatible
In-Reply-To: <20231215170617.95868-1-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
Message-ID: <20231215170617.95868-5-alain.volmat@foss.st.com>

Add a new compatible st,stm32mp25-i2c for the STM32MP25 series which
has only one interrupt line for both events and errors and differs in
term of handling of FastModePlus.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
---
 .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
index 94b75d9f66cd..1b31b87c1800 100644
--- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
@@ -19,6 +19,7 @@ allOf:
               - st,stm32f7-i2c
               - st,stm32mp13-i2c
               - st,stm32mp15-i2c
+              - st,stm32mp25-i2c
     then:
       properties:
         i2c-scl-rising-time-ns:
@@ -41,6 +42,30 @@ allOf:
         clock-frequency:
           enum: [100000, 400000]
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - st,stm32f4-i2c
+              - st,stm32f7-i2c
+              - st,stm32mp13-i2c
+              - st,stm32mp15-i2c
+    then:
+      properties:
+        interrupts:
+          minItems: 2
+
+        interrupt-names:
+          minItems: 2
+    else:
+      properties:
+        interrupts:
+          maxItems: 1
+
+        interrupt-names:
+          maxItems: 1
+
 properties:
   compatible:
     enum:
@@ -48,6 +73,7 @@ properties:
       - st,stm32f7-i2c
       - st,stm32mp13-i2c
       - st,stm32mp15-i2c
+      - st,stm32mp25-i2c
 
   reg:
     maxItems: 1
@@ -56,11 +82,13 @@ properties:
     items:
       - description: interrupt ID for I2C event
       - description: interrupt ID for I2C error
+    minItems: 1
 
   interrupt-names:
     items:
       - const: event
       - const: error
+    minItems: 1
 
   resets:
     maxItems: 1
-- 
2.25.1



From rdunlap at infradead.org  Fri Dec 15 09:09:11 2023
From: rdunlap at infradead.org (Randy Dunlap)
Date: Fri, 15 Dec 2023 09:09:11 -0800
Subject: [PATCH] gpio: xilinx: remove excess kernel doc
In-Reply-To: <20231215090943.9245-1-brgl@bgdev.pl>
References: <20231215090943.9245-1-brgl@bgdev.pl>
Message-ID: <f47bba41-a2a6-404d-8bd6-b67bf7d369b2@infradead.org>



On 12/15/23 01:09, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> 
> The irqchip field has been removed from struct xgpio_instance so remove
> the doc as well.
> 
> Fixes: b4510f8fd5d0 ("gpio: xilinx: Convert to immutable irq_chip")
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312150239.IyuTVvrL-lkp at intel.com/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>

Reviewed-by: Randy Dunlap <rdunlap at infradead.org>

Thanks.

> ---
>  drivers/gpio/gpio-xilinx.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index 823198368250..7348df385198 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -52,7 +52,6 @@
>   * @dir: GPIO direction shadow register
>   * @gpio_lock: Lock used for synchronization
>   * @irq: IRQ used by GPIO device
> - * @irqchip: IRQ chip
>   * @enable: GPIO IRQ enable/disable bitfield
>   * @rising_edge: GPIO IRQ rising edge enable/disable bitfield
>   * @falling_edge: GPIO IRQ falling edge enable/disable bitfield

-- 
#Randy
https://people.kernel.org/tglx/notes-about-netiquette
https://subspace.kernel.org/etiquette.html


From alain.volmat at foss.st.com  Fri Dec 15 09:06:09 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:09 +0100
Subject: [PATCH v3 5/9] i2c: stm32f7: perform I2C_ISR read once at beginning of event isr
In-Reply-To: <20231215170617.95868-1-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
Message-ID: <20231215170617.95868-6-alain.volmat@foss.st.com>

Move readl_relaxed of I2C_ISR register at beginning of event isr
so that it done once for both master & slave handling.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 drivers/i2c/busses/i2c-stm32f7.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 15100fed0a3f..f7abf6d3a7b9 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -1419,15 +1419,13 @@ static bool stm32f7_i2c_is_slave_busy(struct stm32f7_i2c_dev *i2c_dev)
 	return i == busy;
 }
 
-static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev)
+static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev, u32 status)
 {
 	void __iomem *base = i2c_dev->base;
-	u32 cr2, status, mask;
+	u32 cr2, mask;
 	u8 val;
 	int ret;
 
-	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
-
 	/* Slave transmitter mode */
 	if (status & STM32F7_I2C_ISR_TXIS) {
 		i2c_slave_event(i2c_dev->slave_running,
@@ -1531,11 +1529,11 @@ static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
 	u32 status, mask;
 	int ret;
 
-	if (!i2c_dev->master_mode)
-		return stm32f7_i2c_slave_isr_event(i2c_dev);
-
 	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
 
+	if (!i2c_dev->master_mode)
+		return stm32f7_i2c_slave_isr_event(i2c_dev, status);
+
 	/* NACK received */
 	if (status & STM32F7_I2C_ISR_NACKF) {
 		dev_dbg(i2c_dev->dev, "<%s>: Receive NACK (addr %x)\n",
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec 15 09:06:10 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:10 +0100
Subject: [PATCH v3 6/9] i2c: stm32f7: add support for stm32mp25 soc
In-Reply-To: <20231215170617.95868-1-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
Message-ID: <20231215170617.95868-7-alain.volmat@foss.st.com>

The stm32mp25 has only a single interrupt line used for both
events and errors. In order to cope with that, reorganise the
error handling code so that it can be called either from the
common handler (used in case of SoC having only a single IT line)
and the error handler for others.
The CR1 register also embeds a new FMP bit, necessary when running
at Fast Mode Plus frequency. This bit should be used instead of
the SYSCFG bit used on other platforms.
Add a new compatible to distinguish between the SoCs and two
boolean within the setup structure in order to know if the
platform has a single/multiple IT lines and if the FMP bit
within CR1 is available or not.

Signed-off-by: Valentin Caron <valentin.caron at foss.st.com>
Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 drivers/i2c/busses/i2c-stm32f7.c | 214 ++++++++++++++++++-------------
 1 file changed, 126 insertions(+), 88 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index f7abf6d3a7b9..01210452216b 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -50,6 +50,7 @@
 #define STM32F7_I2C_TXDR			0x28
 
 /* STM32F7 I2C control 1 */
+#define STM32_I2C_CR1_FMP			BIT(24)
 #define STM32F7_I2C_CR1_PECEN			BIT(23)
 #define STM32F7_I2C_CR1_ALERTEN			BIT(22)
 #define STM32F7_I2C_CR1_SMBHEN			BIT(20)
@@ -226,6 +227,8 @@ struct stm32f7_i2c_spec {
  * @rise_time: Rise time (ns)
  * @fall_time: Fall time (ns)
  * @fmp_clr_offset: Fast Mode Plus clear register offset from set register
+ * @single_it_line: Only a single IT line is used for both events/errors
+ * @fmp_cr1_bit: Fast Mode Plus control is done via a bit in CR1
  */
 struct stm32f7_i2c_setup {
 	u32 speed_freq;
@@ -233,6 +236,8 @@ struct stm32f7_i2c_setup {
 	u32 rise_time;
 	u32 fall_time;
 	u32 fmp_clr_offset;
+	bool single_it_line;
+	bool fmp_cr1_bit;
 };
 
 /**
@@ -418,6 +423,13 @@ static const struct stm32f7_i2c_setup stm32mp13_setup = {
 	.fmp_clr_offset = 0x4,
 };
 
+static const struct stm32f7_i2c_setup stm32mp25_setup = {
+	.rise_time = STM32F7_I2C_RISE_TIME_DEFAULT,
+	.fall_time = STM32F7_I2C_FALL_TIME_DEFAULT,
+	.single_it_line = true,
+	.fmp_cr1_bit = true,
+};
+
 static inline void stm32f7_i2c_set_bits(void __iomem *reg, u32 mask)
 {
 	writel_relaxed(readl_relaxed(reg) | mask, reg);
@@ -1492,17 +1504,81 @@ static irqreturn_t stm32f7_i2c_slave_isr_event(struct stm32f7_i2c_dev *i2c_dev,
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t stm32f7_i2c_handle_isr_errs(struct stm32f7_i2c_dev *i2c_dev, u32 status)
+{
+	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
+	u16 addr = f7_msg->addr;
+	void __iomem *base = i2c_dev->base;
+	struct device *dev = i2c_dev->dev;
+	struct stm32_i2c_dma *dma = i2c_dev->dma;
+
+	/* Bus error */
+	if (status & STM32F7_I2C_ISR_BERR) {
+		dev_err(dev, "Bus error accessing addr 0x%x\n", addr);
+		writel_relaxed(STM32F7_I2C_ICR_BERRCF, base + STM32F7_I2C_ICR);
+		stm32f7_i2c_release_bus(&i2c_dev->adap);
+		f7_msg->result = -EIO;
+	}
+
+	/* Arbitration loss */
+	if (status & STM32F7_I2C_ISR_ARLO) {
+		dev_dbg(dev, "Arbitration loss accessing addr 0x%x\n", addr);
+		writel_relaxed(STM32F7_I2C_ICR_ARLOCF, base + STM32F7_I2C_ICR);
+		f7_msg->result = -EAGAIN;
+	}
+
+	if (status & STM32F7_I2C_ISR_PECERR) {
+		dev_err(dev, "PEC error in reception accessing addr 0x%x\n", addr);
+		writel_relaxed(STM32F7_I2C_ICR_PECCF, base + STM32F7_I2C_ICR);
+		f7_msg->result = -EINVAL;
+	}
+
+	if (status & STM32F7_I2C_ISR_ALERT) {
+		dev_dbg(dev, "SMBus alert received\n");
+		writel_relaxed(STM32F7_I2C_ICR_ALERTCF, base + STM32F7_I2C_ICR);
+		i2c_handle_smbus_alert(i2c_dev->alert->ara);
+		return IRQ_HANDLED;
+	}
+
+	if (!i2c_dev->slave_running) {
+		u32 mask;
+		/* Disable interrupts */
+		if (stm32f7_i2c_is_slave_registered(i2c_dev))
+			mask = STM32F7_I2C_XFER_IRQ_MASK;
+		else
+			mask = STM32F7_I2C_ALL_IRQ_MASK;
+		stm32f7_i2c_disable_irq(i2c_dev, mask);
+	}
+
+	/* Disable dma */
+	if (i2c_dev->use_dma) {
+		stm32f7_i2c_disable_dma_req(i2c_dev);
+		dmaengine_terminate_async(dma->chan_using);
+	}
+
+	i2c_dev->master_mode = false;
+	complete(&i2c_dev->complete);
+
+	return IRQ_HANDLED;
+}
+
+#define STM32F7_ERR_EVENTS (STM32F7_I2C_ISR_BERR | STM32F7_I2C_ISR_ARLO |\
+			    STM32F7_I2C_ISR_PECERR | STM32F7_I2C_ISR_ALERT)
 static irqreturn_t stm32f7_i2c_isr_event(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
 	u32 status;
 
-	/* Check if the interrupt is for a slave device */
-	if (!i2c_dev->master_mode)
-		return IRQ_WAKE_THREAD;
-
 	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
 
+	/*
+	 * Check if the interrupt is for a slave device or related
+	 * to errors flags (in case of single it line mode)
+	 */
+	if (!i2c_dev->master_mode ||
+	    (i2c_dev->setup.single_it_line && (status & STM32F7_ERR_EVENTS)))
+		return IRQ_WAKE_THREAD;
+
 	/* Tx empty */
 	if (status & STM32F7_I2C_ISR_TXIS)
 		stm32f7_i2c_write_tx_data(i2c_dev);
@@ -1534,6 +1610,10 @@ static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
 	if (!i2c_dev->master_mode)
 		return stm32f7_i2c_slave_isr_event(i2c_dev, status);
 
+	/* Handle errors in case of this handler is used for events/errors */
+	if (i2c_dev->setup.single_it_line && (status & STM32F7_ERR_EVENTS))
+		return stm32f7_i2c_handle_isr_errs(i2c_dev, status);
+
 	/* NACK received */
 	if (status & STM32F7_I2C_ISR_NACKF) {
 		dev_dbg(i2c_dev->dev, "<%s>: Receive NACK (addr %x)\n",
@@ -1599,63 +1679,11 @@ static irqreturn_t stm32f7_i2c_isr_event_thread(int irq, void *data)
 static irqreturn_t stm32f7_i2c_isr_error_thread(int irq, void *data)
 {
 	struct stm32f7_i2c_dev *i2c_dev = data;
-	struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
-	u16 addr = f7_msg->addr;
-	void __iomem *base = i2c_dev->base;
-	struct device *dev = i2c_dev->dev;
-	struct stm32_i2c_dma *dma = i2c_dev->dma;
 	u32 status;
 
 	status = readl_relaxed(i2c_dev->base + STM32F7_I2C_ISR);
 
-	/* Bus error */
-	if (status & STM32F7_I2C_ISR_BERR) {
-		dev_err(dev, "Bus error accessing addr 0x%x\n", addr);
-		writel_relaxed(STM32F7_I2C_ICR_BERRCF, base + STM32F7_I2C_ICR);
-		stm32f7_i2c_release_bus(&i2c_dev->adap);
-		f7_msg->result = -EIO;
-	}
-
-	/* Arbitration loss */
-	if (status & STM32F7_I2C_ISR_ARLO) {
-		dev_dbg(dev, "Arbitration loss accessing addr 0x%x\n", addr);
-		writel_relaxed(STM32F7_I2C_ICR_ARLOCF, base + STM32F7_I2C_ICR);
-		f7_msg->result = -EAGAIN;
-	}
-
-	if (status & STM32F7_I2C_ISR_PECERR) {
-		dev_err(dev, "PEC error in reception accessing addr 0x%x\n", addr);
-		writel_relaxed(STM32F7_I2C_ICR_PECCF, base + STM32F7_I2C_ICR);
-		f7_msg->result = -EINVAL;
-	}
-
-	if (status & STM32F7_I2C_ISR_ALERT) {
-		dev_dbg(dev, "SMBus alert received\n");
-		writel_relaxed(STM32F7_I2C_ICR_ALERTCF, base + STM32F7_I2C_ICR);
-		i2c_handle_smbus_alert(i2c_dev->alert->ara);
-		return IRQ_HANDLED;
-	}
-
-	if (!i2c_dev->slave_running) {
-		u32 mask;
-		/* Disable interrupts */
-		if (stm32f7_i2c_is_slave_registered(i2c_dev))
-			mask = STM32F7_I2C_XFER_IRQ_MASK;
-		else
-			mask = STM32F7_I2C_ALL_IRQ_MASK;
-		stm32f7_i2c_disable_irq(i2c_dev, mask);
-	}
-
-	/* Disable dma */
-	if (i2c_dev->use_dma) {
-		stm32f7_i2c_disable_dma_req(i2c_dev);
-		dmaengine_terminate_async(dma->chan_using);
-	}
-
-	i2c_dev->master_mode = false;
-	complete(&i2c_dev->complete);
-
-	return IRQ_HANDLED;
+	return stm32f7_i2c_handle_isr_errs(i2c_dev, status);
 }
 
 static int stm32f7_i2c_wait_polling(struct stm32f7_i2c_dev *i2c_dev)
@@ -1991,23 +2019,27 @@ static int stm32f7_i2c_unreg_slave(struct i2c_client *slave)
 static int stm32f7_i2c_write_fm_plus_bits(struct stm32f7_i2c_dev *i2c_dev,
 					  bool enable)
 {
-	int ret;
+	int ret = 0;
 
 	if (i2c_dev->bus_rate <= I2C_MAX_FAST_MODE_FREQ ||
-	    IS_ERR_OR_NULL(i2c_dev->regmap))
+	    (!i2c_dev->setup.fmp_cr1_bit && IS_ERR_OR_NULL(i2c_dev->regmap)))
 		/* Optional */
 		return 0;
 
-	if (i2c_dev->fmp_sreg == i2c_dev->fmp_creg)
-		ret = regmap_update_bits(i2c_dev->regmap,
-					 i2c_dev->fmp_sreg,
-					 i2c_dev->fmp_mask,
-					 enable ? i2c_dev->fmp_mask : 0);
-	else
-		ret = regmap_write(i2c_dev->regmap,
-				   enable ? i2c_dev->fmp_sreg :
-					    i2c_dev->fmp_creg,
-				   i2c_dev->fmp_mask);
+	if (i2c_dev->setup.fmp_cr1_bit) {
+		if (enable)
+			stm32f7_i2c_set_bits(i2c_dev->base + STM32F7_I2C_CR1, STM32_I2C_CR1_FMP);
+		else
+			stm32f7_i2c_clr_bits(i2c_dev->base + STM32F7_I2C_CR1, STM32_I2C_CR1_FMP);
+	} else {
+		if (i2c_dev->fmp_sreg == i2c_dev->fmp_creg)
+			ret = regmap_update_bits(i2c_dev->regmap, i2c_dev->fmp_sreg,
+						 i2c_dev->fmp_mask, enable ? i2c_dev->fmp_mask : 0);
+		else
+			ret = regmap_write(i2c_dev->regmap,
+					   enable ? i2c_dev->fmp_sreg : i2c_dev->fmp_creg,
+					   i2c_dev->fmp_mask);
+	}
 
 	return ret;
 }
@@ -2141,6 +2173,13 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 	if (!i2c_dev)
 		return -ENOMEM;
 
+	setup = of_device_get_match_data(&pdev->dev);
+	if (!setup) {
+		dev_err(&pdev->dev, "Can't get device data\n");
+		return -ENODEV;
+	}
+	i2c_dev->setup = *setup;
+
 	i2c_dev->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
 	if (IS_ERR(i2c_dev->base))
 		return PTR_ERR(i2c_dev->base);
@@ -2150,10 +2189,6 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 	if (irq_event < 0)
 		return irq_event;
 
-	irq_error = platform_get_irq(pdev, 1);
-	if (irq_error < 0)
-		return irq_error;
-
 	i2c_dev->wakeup_src = of_property_read_bool(pdev->dev.of_node,
 						    "wakeup-source");
 
@@ -2181,20 +2216,19 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 	if (ret)
 		return dev_err_probe(&pdev->dev, ret, "Failed to request irq event\n");
 
-	ret = devm_request_threaded_irq(&pdev->dev, irq_error,
-					NULL,
-					stm32f7_i2c_isr_error_thread,
-					IRQF_ONESHOT,
-					pdev->name, i2c_dev);
-	if (ret)
-		return dev_err_probe(&pdev->dev, ret, "Failed to request irq error\n");
+	if (!i2c_dev->setup.single_it_line) {
+		irq_error = platform_get_irq(pdev, 1);
+		if (irq_error < 0)
+			return irq_error;
 
-	setup = of_device_get_match_data(&pdev->dev);
-	if (!setup) {
-		dev_err(&pdev->dev, "Can't get device data\n");
-		return -ENODEV;
+		ret = devm_request_threaded_irq(&pdev->dev, irq_error,
+						NULL,
+						stm32f7_i2c_isr_error_thread,
+						IRQF_ONESHOT,
+						pdev->name, i2c_dev);
+		if (ret)
+			return dev_err_probe(&pdev->dev, ret, "Failed to request irq error\n");
 	}
-	i2c_dev->setup = *setup;
 
 	ret = stm32f7_i2c_setup_timing(i2c_dev, &i2c_dev->setup);
 	if (ret)
@@ -2202,9 +2236,12 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
 
 	/* Setup Fast mode plus if necessary */
 	if (i2c_dev->bus_rate > I2C_MAX_FAST_MODE_FREQ) {
-		ret = stm32f7_i2c_setup_fm_plus_bits(pdev, i2c_dev);
-		if (ret)
-			return ret;
+		if (!i2c_dev->setup.fmp_cr1_bit) {
+			ret = stm32f7_i2c_setup_fm_plus_bits(pdev, i2c_dev);
+			if (ret)
+				return ret;
+		}
+
 		ret = stm32f7_i2c_write_fm_plus_bits(i2c_dev, true);
 		if (ret)
 			return ret;
@@ -2483,6 +2520,7 @@ static const struct of_device_id stm32f7_i2c_match[] = {
 	{ .compatible = "st,stm32f7-i2c", .data = &stm32f7_setup},
 	{ .compatible = "st,stm32mp15-i2c", .data = &stm32mp15_setup},
 	{ .compatible = "st,stm32mp13-i2c", .data = &stm32mp13_setup},
+	{ .compatible = "st,stm32mp25-i2c", .data = &stm32mp25_setup},
 	{},
 };
 MODULE_DEVICE_TABLE(of, stm32f7_i2c_match);
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec 15 09:06:11 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:11 +0100
Subject: [PATCH v3 7/9] arm64: dts: st: add all 8 i2c nodes on stm32mp251
In-Reply-To: <20231215170617.95868-1-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
Message-ID: <20231215170617.95868-8-alain.volmat@foss.st.com>

Add the 8 nodes for all i2c instances available on the stm32mp251.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 96 ++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index dfbdb3a773e4..93bc8a8908ce 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -116,6 +116,102 @@ usart2: serial at 400e0000 {
 				status = "disabled";
 			};
 
+			i2c1: i2c at 40120000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40120000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C1>;
+				resets = <&rcc I2C1_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c2: i2c at 40130000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40130000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C2>;
+				resets = <&rcc I2C2_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c3: i2c at 40140000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40140000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C3>;
+				resets = <&rcc I2C3_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c4: i2c at 40150000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40150000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C4>;
+				resets = <&rcc I2C4_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c5: i2c at 40160000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40160000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C5>;
+				resets = <&rcc I2C5_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c6: i2c at 40170000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40170000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C6>;
+				resets = <&rcc I2C6_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c7: i2c at 40180000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x40180000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C7>;
+				resets = <&rcc I2C7_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
+			i2c8: i2c at 46040000 {
+				compatible = "st,stm32mp25-i2c";
+				reg = <0x46040000 0x400>;
+				interrupt-names = "event";
+				interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_I2C8>;
+				resets = <&rcc I2C8_R>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				status = "disabled";
+			};
+
 			sdmmc1: mmc at 48220000 {
 				compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
 				arm,primecell-periphid = <0x00353180>;
-- 
2.25.1



From alain.volmat at foss.st.com  Fri Dec 15 09:06:12 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:12 +0100
Subject: [PATCH v3 8/9] arm64: dts: st: add i2c2/i2c8 pins for stm32mp25
In-Reply-To: <20231215170617.95868-1-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
Message-ID: <20231215170617.95868-9-alain.volmat@foss.st.com>

Add the i2c2 and i2c8 pins used on STM32MP257F-EV1 board.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 36 +++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 66791a974f8f..4194807606ce 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -6,6 +6,23 @@
 #include <dt-bindings/pinctrl/stm32-pinfunc.h>
 
 &pinctrl {
+	i2c2_pins_a: i2c2-0 {
+		pins {
+			pinmux = <STM32_PINMUX('B', 5, AF9)>, /* I2C2_SCL */
+				 <STM32_PINMUX('B', 4, AF9)>; /* I2C2_SDA */
+			bias-disable;
+			drive-open-drain;
+			slew-rate = <0>;
+		};
+	};
+
+	i2c2_sleep_pins_a: i2c2-sleep-0 {
+		pins {
+			pinmux = <STM32_PINMUX('B', 5, ANALOG)>, /* I2C2_SCL */
+				 <STM32_PINMUX('B', 4, ANALOG)>; /* I2C2_SDA */
+		};
+	};
+
 	sdmmc1_b4_pins_a: sdmmc1-b4-0 {
 		pins1 {
 			pinmux = <STM32_PINMUX('E', 4, AF10)>, /* SDMMC1_D0 */
@@ -90,3 +107,22 @@ pins {
 		};
 	};
 };
+
+&pinctrl_z {
+	i2c8_pins_a: i2c8-0 {
+		pins {
+			pinmux = <STM32_PINMUX('Z', 4, AF8)>, /* I2C8_SCL */
+				 <STM32_PINMUX('Z', 3, AF8)>; /* I2C8_SDA */
+			bias-disable;
+			drive-open-drain;
+			slew-rate = <0>;
+		};
+	};
+
+	i2c8_sleep_pins_a: i2c8-sleep-0 {
+		pins {
+			pinmux = <STM32_PINMUX('Z', 4, ANALOG)>, /* I2C8_SCL */
+				 <STM32_PINMUX('Z', 3, ANALOG)>; /* I2C8_SDA */
+		};
+	};
+};
-- 
2.25.1



From Jonathan.Cameron at Huawei.com  Fri Dec 15 09:12:27 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 17:12:27 +0000
Subject: [PATCH RFC v3 20/21] ACPI: Add _OSC bits to advertise OS
 support for toggling CPU present/enabled
In-Reply-To: <E1rDOhS-00Dvla-7i@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOhS-00Dvla-7i@rmk-PC.armlinux.org.uk>
Message-ID: <20231215171227.00006550@Huawei.com>

On Wed, 13 Dec 2023 12:50:54 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> Platform firmware can disabled a CPU, or make it not-present by making
> an eject-request notification, then waiting for the os to make it offline
OS

> and call _EJx. After the firmware updates _STA with the new status.
> 
> Not all operating systems support this. For arm64 making CPUs not-present
> has never been supported. For all ACPI architectures, making CPUs disabled
> has recently been added. Firmware can't know what the OS has support for.
> 
> Add two new _OSC bits to advertise whether the OS supports the _STA enabled
> or present bits being toggled for CPUs. This will be important for arm64
> if systems that support physical CPU hotplug ever appear as arm64 linux
> doesn't currently support this, so firmware shouldn't try.
> 
> Advertising this support to firmware is useful for cloud orchestrators
> to know whether they can scale a particular VM by adding CPUs.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>

I'm very much in favor of this _OSC but it hasn't been accepted yet I think...
https://bugzilla.tianocore.org/show_bug.cgi?id=4481

Jose? Github suggests you are the proposer on this.

btw v4 looks ok but v5 in the tianocore github seems to have lost the actual OSC part.

Jonathan

> ---
> I'm assuming Loongarch machines do not support physical CPU hotplug.
> 
> Changes since RFC v3:
>  * Drop ia64 changes
>  * Update James' comment below "---" to remove reference to ia64
> 
> Outstanding comment:
>  https://lore.kernel.org/r/20230914175021.000018fd at Huawei.com



> ---
>  arch/x86/Kconfig              |  1 +
>  drivers/acpi/Kconfig          |  9 +++++++++
>  drivers/acpi/acpi_processor.c | 14 +++++++++++++-
>  drivers/acpi/bus.c            | 16 ++++++++++++++++
>  include/linux/acpi.h          |  4 ++++
>  5 files changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 64fc7c475ab0..33fc4dcd950c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -60,6 +60,7 @@ config X86
>  	select ACPI_LEGACY_TABLES_LOOKUP	if ACPI
>  	select ACPI_SYSTEM_POWER_STATES_SUPPORT	if ACPI
>  	select ACPI_HOTPLUG_PRESENT_CPU		if ACPI_PROCESSOR && HOTPLUG_CPU
> +	select ACPI_HOTPLUG_IGNORE_OSC		if ACPI && HOTPLUG_CPU
>  	select ARCH_32BIT_OFF_T			if X86_32
>  	select ARCH_CLOCKSOURCE_INIT
>  	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 9c5a43d0aff4..020e7c0ab985 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -311,6 +311,15 @@ config ACPI_HOTPLUG_PRESENT_CPU
>  	depends on ACPI_PROCESSOR && HOTPLUG_CPU
>  	select ACPI_CONTAINER
>  
> +config ACPI_HOTPLUG_IGNORE_OSC
> +	bool
> +	depends on ACPI_HOTPLUG_PRESENT_CPU
> +	help
> +	  Ignore whether firmware acknowledged support for toggling the CPU
> +	  present bit in _STA. Some architectures predate the _OSC bits, so
> +	  firmware doesn't know to do this.
> +
> +
>  config ACPI_PROCESSOR_AGGREGATOR
>  	tristate "Processor Aggregator"
>  	depends on ACPI_PROCESSOR
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index ea12e70dfd39..5bb207a7a1dd 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -182,6 +182,18 @@ static void __init acpi_pcc_cpufreq_init(void)
>  static void __init acpi_pcc_cpufreq_init(void) {}
>  #endif /* CONFIG_X86 */
>  
> +static bool acpi_processor_hotplug_present_supported(void)
> +{
> +	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
> +		return false;
> +
> +	/* x86 systems pre-date the _OSC bit */
> +	if (IS_ENABLED(CONFIG_ACPI_HOTPLUG_IGNORE_OSC))
> +		return true;
> +
> +	return osc_sb_hotplug_present_support_acked;
> +}
> +
>  /* Initialization */
>  static int acpi_processor_make_present(struct acpi_processor *pr)
>  {
> @@ -189,7 +201,7 @@ static int acpi_processor_make_present(struct acpi_processor *pr)
>  	acpi_status status;
>  	int ret;
>  
> -	if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU)) {
> +	if (!acpi_processor_hotplug_present_supported()) {
>  		pr_err_once("Changing CPU present bit is not supported\n");
>  		return -ENODEV;
>  	}
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 72e64c0718c9..7122450739d6 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -298,6 +298,13 @@ EXPORT_SYMBOL_GPL(osc_sb_native_usb4_support_confirmed);
>  
>  bool osc_sb_cppc2_support_acked;
>  
> +/*
> + * ACPI 6.? Proposed Operating System Capabilities for modifying CPU
> + * present/enable.
> + */
> +bool osc_sb_hotplug_enabled_support_acked;
> +bool osc_sb_hotplug_present_support_acked;
> +
>  static u8 sb_uuid_str[] = "0811B06E-4A27-44F9-8D60-3CBBC22E7B48";
>  static void acpi_bus_osc_negotiate_platform_control(void)
>  {
> @@ -346,6 +353,11 @@ static void acpi_bus_osc_negotiate_platform_control(void)
>  
>  	if (!ghes_disable)
>  		capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_APEI_SUPPORT;
> +
> +	capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_HOTPLUG_ENABLED_SUPPORT;
> +	if (IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU))
> +		capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_HOTPLUG_PRESENT_SUPPORT;
> +
>  	if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
>  		return;
>  
> @@ -383,6 +395,10 @@ static void acpi_bus_osc_negotiate_platform_control(void)
>  			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT;
>  		osc_cpc_flexible_adr_space_confirmed =
>  			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_CPC_FLEXIBLE_ADR_SPACE;
> +		osc_sb_hotplug_enabled_support_acked =
> +			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_HOTPLUG_ENABLED_SUPPORT;
> +		osc_sb_hotplug_present_support_acked =
> +			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_HOTPLUG_PRESENT_SUPPORT;
>  	}
>  
>  	kfree(context.ret.pointer);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 00be66683505..c572abac803c 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -559,12 +559,16 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
>  #define OSC_SB_NATIVE_USB4_SUPPORT		0x00040000
>  #define OSC_SB_PRM_SUPPORT			0x00200000
>  #define OSC_SB_FFH_OPR_SUPPORT			0x00400000
> +#define OSC_SB_HOTPLUG_ENABLED_SUPPORT		0x00800000
> +#define OSC_SB_HOTPLUG_PRESENT_SUPPORT		0x01000000
>  
>  extern bool osc_sb_apei_support_acked;
>  extern bool osc_pc_lpi_support_confirmed;
>  extern bool osc_sb_native_usb4_support_confirmed;
>  extern bool osc_sb_cppc2_support_acked;
>  extern bool osc_cpc_flexible_adr_space_confirmed;
> +extern bool osc_sb_hotplug_enabled_support_acked;
> +extern bool osc_sb_hotplug_present_support_acked;
>  
>  /* USB4 Capabilities */
>  #define OSC_USB_USB3_TUNNELING			0x00000001



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:25 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:25 +0100
Subject: [PATCH net-next v4 03/13] net: phy: add helpers to handle sfp phy connect/disconnect
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-4-maxime.chevallier@bootlin.com>

There are a few PHY drivers that can handle SFP modules through their
sfp_upstream_ops. Introduce Phylib helpers to keep track of connected
SFP PHYs in a netdevice's namespace, by adding the SFP PHY to the
upstream PHY's netdev's namespace.

By doing so, these SFP PHYs can be enumerated and exposed to users,
which will be able to use their capabilities.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: Rebased the at803x part with the newer version on net-next
V3: Renaming
V2: Renaming

 drivers/net/phy/at803x.c          |  2 ++
 drivers/net/phy/marvell-88x2222.c |  2 ++
 drivers/net/phy/marvell.c         |  2 ++
 drivers/net/phy/marvell10g.c      |  2 ++
 drivers/net/phy/phy_device.c      | 40 +++++++++++++++++++++++++++++++
 include/linux/phy.h               |  2 ++
 6 files changed, 50 insertions(+)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index a7d28848ee93..c3b20fda68f5 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -1452,6 +1452,8 @@ static const struct sfp_upstream_ops at8031_sfp_ops = {
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
 	.module_insert = at8031_sfp_insert,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 };
 
 static int at8031_parse_dt(struct phy_device *phydev)
diff --git a/drivers/net/phy/marvell-88x2222.c b/drivers/net/phy/marvell-88x2222.c
index e3aa30dad2e6..3f77bbc7e04f 100644
--- a/drivers/net/phy/marvell-88x2222.c
+++ b/drivers/net/phy/marvell-88x2222.c
@@ -555,6 +555,8 @@ static const struct sfp_upstream_ops sfp_phy_ops = {
 	.link_down = mv2222_sfp_link_down,
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 };
 
 static int mv2222_probe(struct phy_device *phydev)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index eba652a4c1d8..674e29bce2cc 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -3254,6 +3254,8 @@ static const struct sfp_upstream_ops m88e1510_sfp_ops = {
 	.module_remove = m88e1510_sfp_remove,
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 };
 
 static int m88e1510_probe(struct phy_device *phydev)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index ad43e280930c..6642eb642d4b 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -503,6 +503,8 @@ static int mv3310_sfp_insert(void *upstream, const struct sfp_eeprom_id *id)
 static const struct sfp_upstream_ops mv3310_sfp_ops = {
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 	.module_insert = mv3310_sfp_insert,
 };
 
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 89daaccc9276..0a7fc5fede08 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1363,6 +1363,46 @@ phy_standalone_show(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RO(phy_standalone);
 
+/**
+ * phy_sfp_connect_phy - Connect the SFP module's PHY to the upstream PHY
+ * @upstream: pointer to the upstream phy device
+ * @phy: pointer to the SFP module's phy device
+ *
+ * This helper allows keeping track of PHY devices on the link. It adds the
+ * SFP module's phy to the phy namespace of the upstream phy
+ */
+int phy_sfp_connect_phy(void *upstream, struct phy_device *phy)
+{
+	struct phy_device *phydev = upstream;
+	struct phy_link_topology *topo = phy_get_link_topology(phydev);
+
+	if (topo)
+		return phy_link_topo_add_phy(topo, phy, PHY_UPSTREAM_PHY, phydev);
+
+	return 0;
+}
+EXPORT_SYMBOL(phy_sfp_connect_phy);
+
+/**
+ * phy_sfp_disconnect_phy - Disconnect the SFP module's PHY from the upstream PHY
+ * @upstream: pointer to the upstream phy device
+ * @phy: pointer to the SFP module's phy device
+ *
+ * This helper allows keeping track of PHY devices on the link. It removes the
+ * SFP module's phy to the phy namespace of the upstream phy. As the module phy
+ * will be destroyed, re-inserting the same module will add a new phy with a
+ * new index.
+ */
+void phy_sfp_disconnect_phy(void *upstream, struct phy_device *phy)
+{
+	struct phy_device *phydev = upstream;
+	struct phy_link_topology *topo = phy_get_link_topology(phydev);
+
+	if (topo)
+		phy_link_topo_del_phy(topo, phy);
+}
+EXPORT_SYMBOL(phy_sfp_disconnect_phy);
+
 /**
  * phy_sfp_attach - attach the SFP bus to the PHY upstream network device
  * @upstream: pointer to the phy device
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 12613ad521b4..7237c8caa4af 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1725,6 +1725,8 @@ int phy_suspend(struct phy_device *phydev);
 int phy_resume(struct phy_device *phydev);
 int __phy_resume(struct phy_device *phydev);
 int phy_loopback(struct phy_device *phydev, bool enable);
+int phy_sfp_connect_phy(void *upstream, struct phy_device *phy);
+void phy_sfp_disconnect_phy(void *upstream, struct phy_device *phy);
 void phy_sfp_attach(void *upstream, struct sfp_bus *bus);
 void phy_sfp_detach(void *upstream, struct sfp_bus *bus);
 int phy_sfp_probe(struct phy_device *phydev,
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:22 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:22 +0100
Subject: [PATCH net-next v4 00/13] Introduce PHY listing and link_topology tracking
Message-ID: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>

Hello everyone,

Here's a V4 of the multi-PHY support series. This is mostly bugfixes to
allow building without phylib, but I also removed the RFC flag.

The blurb bellow is a full description of the series, however I realised
that I failed to mentionned why this is called "phy_link_topology". The
end-goal of this struct is not only to track the phy_devices but also
the different front-facing ports across the topology. I'm picking a
pretty generic name to convey the fact that this should be strictly
related to PHYs.

As a remainder, this ongoing work aims ultimately at supporting complex
link topologies that involve multiplexing multiple PHYs/SFPs on a single
netdevice. As a first step, it's required that we are able to enumerate the
PHYs on a given ethernet interface.

By just doing so, we also improve already-existing use-cases, namely the
copper SFP modules support when a media-converter is used (as we have 2
PHYs on the link, but only one is referenced by net_device.phydev, which
is used on a variety of netlink commands).

The series is architectured as follows :

- The first patch adds the notion of phy_link_topology, which tracks
all PHYs attached to a netdevice.

- Patches 2, 3 and 4 adds some plumbing into SFP and phylib to be able
  to connect the dots when building the topology tree, to know which PHY
  is connected to which SFP bus, trying not to be too invasive on phylib.

- Patch 5 allows passing a PHY_INDEX to ethnl commands. I'm uncertain about
  this, as there are at least 4 netlink commands ( 5 with the one introduced
  in patch 7 ) that targets PHYs directly or indirectly, which to me makes
  it worth-it to have a generic way to pass a PHY index to commands, however
  the approach taken may be too generic.

- Patch 6 is the netlink spec update + ethtool-user.c|h autogenerated code
update (the autogenerated code triggers checkpatch warning though)

- Patch 7 introduces a new netlink command set to list PHYs on a netdevice.
It implements a custom DUMP and GET operation to allow filtered dumps,
that lists all PHYs on a given netdevice. I couldn't use most of ethnl's
plumbing though.

- Patch 8 is the netlink spec update + ethtool-user.c|h update for that
new command

- Patch 8,9,10 and 11 updates the PLCA, strset, cable-test and pse netlink
commands to use the user-provided PHY instead of net_device.phydev.

- Finally patch 12 adds some documentation for this whole work.

Examples
========

Here's a short overview of the kind of operations you can have regarding
the PHY topology. These tests were performed on a MacchiatoBin, which
has 3 interfaces :

eth0 and eth1 have the following layout:

MAC - PHY - SFP

eth2 has this more classic topology :

MAC - PHY - RJ45

finally eth3 has the following topology :

MAC - SFP

When performing a dump with all interfaces down, we don't get any
result, as no PHY has been attached to their respective net_device :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get
None

The following output is with eth0, eth2 and eth3 up, but no SFP module
inserted in none of the interfaces :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get
[{'downstream-sfp-name': 'sfp-eth0',
  'drvname': 'mv88x3310',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 0,
  'index': 1,
  'name': 'f212a600.mdio-mii:00',
  'upstream-type': 'mac'},
 {'drvname': 'Marvell 88E1510',
  'header': {'dev-index': 4, 'dev-name': 'eth2'},
  'id': 21040593,
  'index': 1,
  'name': 'f212a200.mdio-mii:00',
  'upstream-type': 'mac'}]


And now is a dump operation with a copper SFP in the eth0 port :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get
[{'downstream-sfp-name': 'sfp-eth0',
  'drvname': 'mv88x3310',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 0,
  'index': 1,
  'name': 'f212a600.mdio-mii:00',
  'upstream-type': 'mac'},
 {'drvname': 'Marvell 88E1111',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 21040322,
  'index': 2,
  'name': 'i2c:sfp-eth0:16',
  'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'},
  'upstream-type': 'phy'},
 {'drvname': 'Marvell 88E1510',
  'header': {'dev-index': 4, 'dev-name': 'eth2'},
  'id': 21040593,
  'index': 1,
  'name': 'f212a200.mdio-mii:00',
  'upstream-type': 'mac'}]

 -- Note that this shouldn't actually work as the 88x3310 PHY doesn't allow
a 1G SFP to be connected to its SFP interface, and I don't have a 10G copper SFP,
so for the sake of the demo I applied the following modification, which
of courses gives a non-functionnal link, but the PHY attach still works,
which is what I want to demonstrate :

@@ -488,7 +488,7 @@ static int mv3310_sfp_insert(void *upstream, const struct sfp_eeprom_id *id)

        if (iface != PHY_INTERFACE_MODE_10GBASER) {
                dev_err(&phydev->mdio.dev, "incompatible SFP module inserted\n");
-               return -EINVAL;
+               //return -EINVAL;
        }
        return 0;
 }

Finally an example of the filtered DUMP operation that Jakub suggested
in V1 :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml \
# --dump phy-get --json '{"header" : {"dev-name" : "eth0"}}'

[{'downstream-sfp-name': 'sfp-eth0',
  'drvname': 'mv88x3310',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 0,
  'index': 1,
  'name': 'f212a600.mdio-mii:00',
  'upstream-type': 'mac'},
 {'drvname': 'Marvell 88E1111',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 21040322,
  'index': 2,
  'name': 'i2c:sfp-eth0:16',
  'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'},
  'upstream-type': 'phy'}]

And a classic GET operation allows querying a single PHY's info :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml \
# --do phy-get --json '{"header" : {"dev-name" : "eth0", "phy-index" : 2}}'

{'drvname': 'Marvell 88E1111',
 'header': {'dev-index': 2, 'dev-name': 'eth0'},
 'id': 21040322,
 'index': 2,
 'name': 'i2c:sfp-eth0:16',
 'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'},
 'upstream-type': 'phy'}

Changes in V4:
- Dropped the RFC flag
- Made the net_device integration independent to having phylib enabled
- Removed the autogenerated ethtool-user code for the YNL specs

Changes in V3:
- Added RTNL assertions where needed
- Fixed issues in the DUMP code for PHY_GET, which crashed when running it
  twice in a row
- Added the documentation, and moved in-source docs around
- renamed link_topology to phy_link_topology

Changes in V2:
- Added the DUMP operation
- Added much more information in the reported data, to be able to reconstruct
  precisely the topology tree
- renamed phy_list to link_topology



Maxime Chevallier (13):
  net: phy: Introduce ethernet link topology representation
  net: sfp: pass the phy_device when disconnecting an sfp module's PHY
  net: phy: add helpers to handle sfp phy connect/disconnect
  net: sfp: Add helper to return the SFP bus name
  net: ethtool: Allow passing a phy index for some commands
  netlink: specs: add phy-index as a header parameter
  net: ethtool: Introduce a command to list PHYs on an interface
  netlink: specs: add ethnl PHY_GET command set
  net: ethtool: plca: Target the command to the requested PHY
  net: ethtool: pse-pd: Target the command to the requested PHY
  net: ethtool: cable-test: Target the command to the requested PHY
  net: ethtool: strset: Allow querying phy stats by index
  Documentation: networking: document phy_link_topology

 Documentation/netlink/specs/ethtool.yaml      |  68 ++++
 Documentation/networking/ethtool-netlink.rst  |  51 +++
 Documentation/networking/index.rst            |   1 +
 .../networking/phy-link-topology.rst          | 121 +++++++
 MAINTAINERS                                   |   2 +
 drivers/net/phy/Makefile                      |   2 +-
 drivers/net/phy/at803x.c                      |   2 +
 drivers/net/phy/marvell-88x2222.c             |   2 +
 drivers/net/phy/marvell.c                     |   2 +
 drivers/net/phy/marvell10g.c                  |   2 +
 drivers/net/phy/phy_device.c                  |  55 ++++
 drivers/net/phy/phy_link_topology.c           |  79 +++++
 drivers/net/phy/phylink.c                     |   3 +-
 drivers/net/phy/sfp-bus.c                     |  15 +-
 include/linux/netdevice.h                     |   4 +-
 include/linux/phy.h                           |   6 +
 include/linux/phy_link_topology.h             |  64 ++++
 include/linux/phy_link_topology_core.h        |  19 ++
 include/linux/sfp.h                           |   8 +-
 include/uapi/linux/ethtool.h                  |  16 +
 include/uapi/linux/ethtool_netlink.h          |  30 ++
 net/core/dev.c                                |   3 +
 net/ethtool/Makefile                          |   2 +-
 net/ethtool/cabletest.c                       |  12 +-
 net/ethtool/netlink.c                         |  33 ++
 net/ethtool/netlink.h                         |  12 +-
 net/ethtool/phy.c                             | 306 ++++++++++++++++++
 net/ethtool/plca.c                            |  13 +-
 net/ethtool/pse-pd.c                          |  14 +-
 net/ethtool/strset.c                          |  15 +-
 30 files changed, 922 insertions(+), 40 deletions(-)
 create mode 100644 Documentation/networking/phy-link-topology.rst
 create mode 100644 drivers/net/phy/phy_link_topology.c
 create mode 100644 include/linux/phy_link_topology.h
 create mode 100644 include/linux/phy_link_topology_core.h
 create mode 100644 net/ethtool/phy.c

-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:23 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:23 +0100
Subject: [PATCH net-next v4 01/13] net: phy: Introduce ethernet link topology representation
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-2-maxime.chevallier@bootlin.com>

Link topologies containing multiple network PHYs attached to the same
net_device can be found when using a PHY as a media converter for use
with an SFP connector, on which an SFP transceiver containing a PHY can
be used.

With the current model, the transceiver's PHY can't be used for
operations such as cable testing, timestamping, macsec offload, etc.

The reason being that most of the logic for these configuration, coming
from either ethtool netlink or ioctls tend to use netdev->phydev, which
in multi-phy systems will reference the PHY closest to the MAC.

Introduce a numbering scheme allowing to enumerate PHY devices that
belong to any netdev, which can in turn allow userspace to take more
precise decisions with regard to each PHY's configuration.

The numbering is maintained per-netdev, in a phy_device_list.
The numbering works similarly to a netdevice's ifindex, with
identifiers that are only recycled once INT_MAX has been reached.

This prevents races that could occur between PHY listing and SFP
transceiver removal/insertion.

The identifiers are assigned at phy_attach time, as the numbering
depends on the netdevice the phy is attached to.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: - Moved the phy_link_topo_init() code to an inline header function
    - Made the code build without phylib

V3: - Renamed to phy_link_topology
    - Added assertions for RTNL
    - Various cleanups of leftover, unused test code
    - Made the PHY index u32

 MAINTAINERS                            |  2 +
 drivers/net/phy/Makefile               |  2 +-
 drivers/net/phy/phy_device.c           | 15 +++++
 drivers/net/phy/phy_link_topology.c    | 79 ++++++++++++++++++++++++++
 include/linux/netdevice.h              |  4 +-
 include/linux/phy.h                    |  4 ++
 include/linux/phy_link_topology.h      | 64 +++++++++++++++++++++
 include/linux/phy_link_topology_core.h | 19 +++++++
 include/uapi/linux/ethtool.h           | 16 ++++++
 net/core/dev.c                         |  3 +
 10 files changed, 206 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/phy/phy_link_topology.c
 create mode 100644 include/linux/phy_link_topology.h
 create mode 100644 include/linux/phy_link_topology_core.h

diff --git a/MAINTAINERS b/MAINTAINERS
index dda78b4ce707..f09b1d4e5487 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7873,6 +7873,8 @@ F:	include/linux/mii.h
 F:	include/linux/of_net.h
 F:	include/linux/phy.h
 F:	include/linux/phy_fixed.h
+F:	include/linux/phy_link_topology.h
+F:	include/linux/phy_link_topology_core.h
 F:	include/linux/phylib_stubs.h
 F:	include/linux/platform_data/mdio-bcm-unimac.h
 F:	include/linux/platform_data/mdio-gpio.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e35ea69d9cb4..a7a9640bfa3a 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -2,7 +2,7 @@
 # Makefile for Linux PHY drivers
 
 libphy-y			:= phy.o phy-c45.o phy-core.o phy_device.o \
-				   linkmode.o
+				   linkmode.o phy_link_topology.o
 mdio-bus-y			+= mdio_bus.o mdio_device.o
 
 ifdef CONFIG_MDIO_DEVICE
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index d8e9335d415c..89daaccc9276 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -29,6 +29,7 @@
 #include <linux/phy.h>
 #include <linux/phylib_stubs.h>
 #include <linux/phy_led_triggers.h>
+#include <linux/phy_link_topology.h>
 #include <linux/pse-pd/pse.h>
 #include <linux/property.h>
 #include <linux/rtnetlink.h>
@@ -265,6 +266,14 @@ static void phy_mdio_device_remove(struct mdio_device *mdiodev)
 
 static struct phy_driver genphy_driver;
 
+static struct phy_link_topology *phy_get_link_topology(struct phy_device *phydev)
+{
+	if (phydev->attached_dev)
+		return &phydev->attached_dev->link_topo;
+
+	return NULL;
+}
+
 static LIST_HEAD(phy_fixup_list);
 static DEFINE_MUTEX(phy_fixup_lock);
 
@@ -1491,6 +1500,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
 
 		if (phydev->sfp_bus_attached)
 			dev->sfp_bus = phydev->sfp_bus;
+
+		err = phy_link_topo_add_phy(&dev->link_topo, phydev,
+					    PHY_UPSTREAM_MAC, dev);
+		if (err)
+			goto error;
 	}
 
 	/* Some Ethernet drivers try to connect to a PHY device before
@@ -1816,6 +1830,7 @@ void phy_detach(struct phy_device *phydev)
 	if (dev) {
 		phydev->attached_dev->phydev = NULL;
 		phydev->attached_dev = NULL;
+		phy_link_topo_del_phy(&dev->link_topo, phydev);
 	}
 	phydev->phylink = NULL;
 
diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
new file mode 100644
index 000000000000..22f6372d002c
--- /dev/null
+++ b/drivers/net/phy/phy_link_topology.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Infrastructure to handle all PHY devices connected to a given netdev,
+ * either directly or indirectly attached.
+ *
+ * Copyright (c) 2023 Maxime Chevallier<maxime.chevallier at bootlin.com>
+ */
+
+#include <linux/phy_link_topology.h>
+#include <linux/netdevice.h>
+#include <linux/phy.h>
+#include <linux/rtnetlink.h>
+#include <linux/xarray.h>
+
+struct phy_device *phy_link_topo_get_phy(struct phy_link_topology *topo,
+					 u32 phyindex)
+{
+	struct phy_device_node *pdn = xa_load(&topo->phys, phyindex);
+
+	if (pdn)
+		return pdn->phy;
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_get_phy);
+
+int phy_link_topo_add_phy(struct phy_link_topology *topo,
+			  struct phy_device *phy,
+			  enum phy_upstream upt, void *upstream)
+{
+	struct phy_device_node *pdn;
+	int ret;
+
+	/* Protects phy and upstream */
+	ASSERT_RTNL();
+
+	pdn = kzalloc(sizeof(*pdn), GFP_KERNEL);
+	if (!pdn)
+		return -ENOMEM;
+
+	pdn->phy = phy;
+	switch (upt) {
+	case PHY_UPSTREAM_MAC:
+		pdn->upstream.netdev = (struct net_device *)upstream;
+		if (phy_on_sfp(phy))
+			pdn->parent_sfp_bus = pdn->upstream.netdev->sfp_bus;
+		break;
+	case PHY_UPSTREAM_PHY:
+		pdn->upstream.phydev = (struct phy_device *)upstream;
+		if (phy_on_sfp(phy))
+			pdn->parent_sfp_bus = pdn->upstream.phydev->sfp_bus;
+		break;
+	default:
+		ret = -EINVAL;
+		goto err;
+	}
+	pdn->upstream_type = upt;
+
+	ret = xa_alloc_cyclic(&topo->phys, &phy->phyindex, pdn, xa_limit_32b,
+			      &topo->next_phy_index, GFP_KERNEL);
+	if (ret)
+		goto err;
+
+	return 0;
+
+err:
+	kfree(pdn);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_add_phy);
+
+void phy_link_topo_del_phy(struct phy_link_topology *topo,
+			   struct phy_device *phy)
+{
+	struct phy_device_node *pdn = xa_erase(&topo->phys, phy->phyindex);
+
+	kfree(pdn);
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_del_phy);
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 1b935ee341b4..17ae81c1e519 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -40,7 +40,6 @@
 #include <net/dcbnl.h>
 #endif
 #include <net/netprio_cgroup.h>
-
 #include <linux/netdev_features.h>
 #include <linux/neighbour.h>
 #include <uapi/linux/netdevice.h>
@@ -52,6 +51,7 @@
 #include <net/net_trackers.h>
 #include <net/net_debug.h>
 #include <net/dropreason-core.h>
+#include <linux/phy_link_topology_core.h>
 
 struct netpoll_info;
 struct device;
@@ -2041,6 +2041,7 @@ enum netdev_stat_type {
  *	@fcoe_ddp_xid:	Max exchange id for FCoE LRO by ddp
  *
  *	@priomap:	XXX: need comments on this one
+ *	@link_topo:	Physical link topology tracking attached PHYs
  *	@phydev:	Physical device may attach itself
  *			for hardware timestamping
  *	@sfp_bus:	attached &struct sfp_bus structure.
@@ -2435,6 +2436,7 @@ struct net_device {
 #if IS_ENABLED(CONFIG_CGROUP_NET_PRIO)
 	struct netprio_map __rcu *priomap;
 #endif
+	struct phy_link_topology	link_topo;
 	struct phy_device	*phydev;
 	struct sfp_bus		*sfp_bus;
 	struct lock_class_key	*qdisc_tx_busylock;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index dbb5e13e3e1b..12613ad521b4 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -543,6 +543,9 @@ struct macsec_ops;
  * @drv: Pointer to the driver for this PHY instance
  * @devlink: Create a link between phy dev and mac dev, if the external phy
  *           used by current mac interface is managed by another mac interface.
+ * @phyindex: Unique id across the phy's parent tree of phys to address the PHY
+ *	      from userspace, similar to ifindex. A zero index means the PHY
+ *	      wasn't assigned an id yet.
  * @phy_id: UID for this device found during discovery
  * @c45_ids: 802.3-c45 Device Identifiers if is_c45.
  * @is_c45:  Set to true if this PHY uses clause 45 addressing.
@@ -642,6 +645,7 @@ struct phy_device {
 
 	struct device_link *devlink;
 
+	u32 phyindex;
 	u32 phy_id;
 
 	struct phy_c45_device_ids c45_ids;
diff --git a/include/linux/phy_link_topology.h b/include/linux/phy_link_topology.h
new file mode 100644
index 000000000000..0d23919e464f
--- /dev/null
+++ b/include/linux/phy_link_topology.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * PHY device list allow maintaining a list of PHY devices that are
+ * part of a netdevice's link topology. PHYs can for example be chained,
+ * as is the case when using a PHY that exposes an SFP module, on which an
+ * SFP transceiver that embeds a PHY is connected.
+ *
+ * This list can then be used by userspace to leverage individual PHY
+ * capabilities.
+ */
+#ifndef __PHY_LINK_TOPOLOGY_H
+#define __PHY_LINK_TOPOLOGY_H
+
+#include <linux/ethtool.h>
+#include <linux/phy_link_topology_core.h>
+
+struct xarray;
+struct phy_device;
+struct net_device;
+struct sfp_bus;
+
+struct phy_device_node {
+	enum phy_upstream upstream_type;
+
+	union {
+		struct net_device	*netdev;
+		struct phy_device	*phydev;
+	} upstream;
+
+	struct sfp_bus *parent_sfp_bus;
+
+	struct phy_device *phy;
+};
+
+#if IS_ENABLED(CONFIG_PHYLIB)
+struct phy_device *phy_link_topo_get_phy(struct phy_link_topology *topo,
+					 u32 phyindex);
+int phy_link_topo_add_phy(struct phy_link_topology *topo,
+			  struct phy_device *phy,
+			  enum phy_upstream upt, void *upstream);
+
+void phy_link_topo_del_phy(struct phy_link_topology *lt, struct phy_device *phy);
+
+#else
+static inline struct phy_device *phy_link_topo_get_phy(struct phy_link_topology *topo,
+						       u32 phyindex)
+{
+	return NULL;
+}
+
+static inline int phy_link_topo_add_phy(struct phy_link_topology *topo,
+					struct phy_device *phy,
+					enum phy_upstream upt, void *upstream)
+{
+	return 0;
+}
+
+static inline void phy_link_topo_del_phy(struct phy_link_topology *topo,
+					 struct phy_device *phy)
+{
+}
+#endif
+
+#endif /* __PHY_LINK_TOPOLOGY_H */
diff --git a/include/linux/phy_link_topology_core.h b/include/linux/phy_link_topology_core.h
new file mode 100644
index 000000000000..78c75f909489
--- /dev/null
+++ b/include/linux/phy_link_topology_core.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PHY_LINK_TOPOLOGY_CORE_H
+#define __PHY_LINK_TOPOLOGY_CORE_H
+
+struct xarray;
+
+struct phy_link_topology {
+	struct xarray phys;
+
+	u32 next_phy_index;
+};
+
+static inline void phy_link_topo_init(struct phy_link_topology *topo)
+{
+	xa_init_flags(&topo->phys, XA_FLAGS_ALLOC1);
+	topo->next_phy_index = 1;
+}
+
+#endif /* __PHY_LINK_TOPOLOGY_CORE_H */
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 0787d561ace0..9cff798c6df9 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -2216,4 +2216,20 @@ struct ethtool_link_settings {
 	 * __u32 map_lp_advertising[link_mode_masks_nwords];
 	 */
 };
+
+/**
+ * enum phy_upstream - Represents the upstream component a given PHY device
+ * is connected to, as in what is on the other end of the MII bus. Most PHYs
+ * will be attached to an Ethernet MAC controller, but in some cases, there's
+ * an intermediate PHY used as a media-converter, which will driver another
+ * MII interface as its output.
+ * @PHY_UPSTREAM_MAC: Upstream component is a MAC (a switch port,
+ *		      or ethernet controller)
+ * @PHY_UPSTREAM_PHY: Upstream component is a PHY (likely a media converter)
+ */
+enum phy_upstream {
+	PHY_UPSTREAM_MAC,
+	PHY_UPSTREAM_PHY,
+};
+
 #endif /* _UAPI_LINUX_ETHTOOL_H */
diff --git a/net/core/dev.c b/net/core/dev.c
index 0432b04cf9b0..a8776fe6be68 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -153,6 +153,7 @@
 #include <linux/prandom.h>
 #include <linux/once_lite.h>
 #include <net/netdev_rx_queue.h>
+#include <linux/phy_link_topology_core.h>
 
 #include "dev.h"
 #include "net-sysfs.h"
@@ -10869,6 +10870,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
 #ifdef CONFIG_NET_SCHED
 	hash_init(dev->qdisc_hash);
 #endif
+	phy_link_topo_init(&dev->link_topo);
+
 	dev->priv_flags = IFF_XMIT_DST_RELEASE | IFF_XMIT_DST_RELEASE_PERM;
 	setup(dev);
 
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:24 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:24 +0100
Subject: [PATCH net-next v4 02/13] net: sfp: pass the phy_device when disconnecting an sfp module's PHY
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-3-maxime.chevallier@bootlin.com>

Pass the phy_device as a parameter to the sfp upstream .disconnect_phy
operation. This is preparatory work to help track phy devices across
a net_device's link.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: No changes
V3: No changes

 drivers/net/phy/phylink.c | 3 ++-
 drivers/net/phy/sfp-bus.c | 4 ++--
 include/linux/sfp.h       | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 48d3bd3e9fc7..0cd77f954a60 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -3380,7 +3380,8 @@ static int phylink_sfp_connect_phy(void *upstream, struct phy_device *phy)
 	return ret;
 }
 
-static void phylink_sfp_disconnect_phy(void *upstream)
+static void phylink_sfp_disconnect_phy(void *upstream,
+				       struct phy_device *phydev)
 {
 	phylink_disconnect_phy(upstream);
 }
diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 6fa679b36290..3a86c41e1235 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -486,7 +486,7 @@ static void sfp_unregister_bus(struct sfp_bus *bus)
 			bus->socket_ops->stop(bus->sfp);
 		bus->socket_ops->detach(bus->sfp);
 		if (bus->phydev && ops && ops->disconnect_phy)
-			ops->disconnect_phy(bus->upstream);
+			ops->disconnect_phy(bus->upstream, bus->phydev);
 	}
 	bus->registered = false;
 }
@@ -742,7 +742,7 @@ void sfp_remove_phy(struct sfp_bus *bus)
 	const struct sfp_upstream_ops *ops = sfp_get_upstream_ops(bus);
 
 	if (ops && ops->disconnect_phy)
-		ops->disconnect_phy(bus->upstream);
+		ops->disconnect_phy(bus->upstream, bus->phydev);
 	bus->phydev = NULL;
 }
 EXPORT_SYMBOL_GPL(sfp_remove_phy);
diff --git a/include/linux/sfp.h b/include/linux/sfp.h
index 9346cd44814d..0573e53b0c11 100644
--- a/include/linux/sfp.h
+++ b/include/linux/sfp.h
@@ -544,7 +544,7 @@ struct sfp_upstream_ops {
 	void (*link_down)(void *priv);
 	void (*link_up)(void *priv);
 	int (*connect_phy)(void *priv, struct phy_device *);
-	void (*disconnect_phy)(void *priv);
+	void (*disconnect_phy)(void *priv, struct phy_device *);
 };
 
 #if IS_ENABLED(CONFIG_SFP)
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:26 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:26 +0100
Subject: [PATCH net-next v4 04/13] net: sfp: Add helper to return the SFP bus name
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-5-maxime.chevallier@bootlin.com>

Knowing the bus name is helpful when we want to expose the link topology
to userspace, add a helper to return the SFP bus name.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: - No changes

V3: - Added RTNL assert
    - Made the stub inline
V2: New patch

 drivers/net/phy/sfp-bus.c | 11 +++++++++++
 include/linux/sfp.h       |  6 ++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 3a86c41e1235..fb1c102714b5 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -859,3 +859,14 @@ void sfp_unregister_socket(struct sfp_bus *bus)
 	sfp_bus_put(bus);
 }
 EXPORT_SYMBOL_GPL(sfp_unregister_socket);
+
+const char *sfp_get_name(struct sfp_bus *bus)
+{
+	ASSERT_RTNL();
+
+	if (bus->sfp_dev)
+		return dev_name(bus->sfp_dev);
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(sfp_get_name);
diff --git a/include/linux/sfp.h b/include/linux/sfp.h
index 0573e53b0c11..55c0ab17c9e2 100644
--- a/include/linux/sfp.h
+++ b/include/linux/sfp.h
@@ -570,6 +570,7 @@ struct sfp_bus *sfp_bus_find_fwnode(const struct fwnode_handle *fwnode);
 int sfp_bus_add_upstream(struct sfp_bus *bus, void *upstream,
 			 const struct sfp_upstream_ops *ops);
 void sfp_bus_del_upstream(struct sfp_bus *bus);
+const char *sfp_get_name(struct sfp_bus *bus);
 #else
 static inline int sfp_parse_port(struct sfp_bus *bus,
 				 const struct sfp_eeprom_id *id,
@@ -648,6 +649,11 @@ static inline int sfp_bus_add_upstream(struct sfp_bus *bus, void *upstream,
 static inline void sfp_bus_del_upstream(struct sfp_bus *bus)
 {
 }
+
+static inline const char *sfp_get_name(struct sfp_bus *bus)
+{
+	return NULL;
+}
 #endif
 
 #endif
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:27 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:27 +0100
Subject: [PATCH net-next v4 05/13] net: ethtool: Allow passing a phy index for some commands
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-6-maxime.chevallier@bootlin.com>

Some netlink commands are target towards ethernet PHYs, to control some
of their features. As there's several such commands, add the ability to
pass a PHY index in the ethnl request, which will populate the generic
ethnl_req_info with the relevant phydev when the command targets a PHY.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: - No Changes
V3: - Fixed the documentation
V2: - New patch

 Documentation/networking/ethtool-netlink.rst |  7 ++++++
 include/uapi/linux/ethtool_netlink.h         |  1 +
 net/ethtool/netlink.c                        | 24 ++++++++++++++++++++
 net/ethtool/netlink.h                        |  7 ++++--
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index d583d9abf2f8..3ca6c21e74af 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst
@@ -57,6 +57,7 @@ Structure of this header is
   ``ETHTOOL_A_HEADER_DEV_INDEX``  u32     device ifindex
   ``ETHTOOL_A_HEADER_DEV_NAME``   string  device name
   ``ETHTOOL_A_HEADER_FLAGS``      u32     flags common for all requests
+  ``ETHTOOL_A_HEADER_PHY_INDEX``  u32     phy device index
   ==============================  ======  =============================
 
 ``ETHTOOL_A_HEADER_DEV_INDEX`` and ``ETHTOOL_A_HEADER_DEV_NAME`` identify the
@@ -81,6 +82,12 @@ the behaviour is backward compatible, i.e. requests from old clients not aware
 of the flag should be interpreted the way the client expects. A client must
 not set flags it does not understand.
 
+``ETHTOOL_A_HEADER_PHY_INDEX`` identify the ethernet PHY the message relates to.
+As there are numerous commands that are related to PHY configuration, and because
+we can have more than one PHY on the link, the PHY index can be passed in the
+request for the commands that needs it. It is however not mandatory, and if it
+is not passed for commands that target a PHY, the net_device.phydev pointer
+is used, as a fallback that keeps the legacy behaviour.
 
 Bit sets
 ========
diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h
index 3f89074aa06c..422e8cfdd98c 100644
--- a/include/uapi/linux/ethtool_netlink.h
+++ b/include/uapi/linux/ethtool_netlink.h
@@ -133,6 +133,7 @@ enum {
 	ETHTOOL_A_HEADER_DEV_INDEX,		/* u32 */
 	ETHTOOL_A_HEADER_DEV_NAME,		/* string */
 	ETHTOOL_A_HEADER_FLAGS,			/* u32 - ETHTOOL_FLAG_* */
+	ETHTOOL_A_HEADER_PHY_INDEX,		/* u32 */
 
 	/* add new constants above here */
 	__ETHTOOL_A_HEADER_CNT,
diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
index fe3553f60bf3..1c26766ce996 100644
--- a/net/ethtool/netlink.c
+++ b/net/ethtool/netlink.c
@@ -4,6 +4,7 @@
 #include <linux/ethtool_netlink.h>
 #include <linux/pm_runtime.h>
 #include "netlink.h"
+#include <linux/phy_link_topology.h>
 
 static struct genl_family ethtool_genl_family;
 
@@ -20,6 +21,7 @@ const struct nla_policy ethnl_header_policy[] = {
 					    .len = ALTIFNAMSIZ - 1 },
 	[ETHTOOL_A_HEADER_FLAGS]	= NLA_POLICY_MASK(NLA_U32,
 							  ETHTOOL_FLAGS_BASIC),
+	[ETHTOOL_A_HEADER_PHY_INDEX]		= NLA_POLICY_MIN(NLA_U32, 1),
 };
 
 const struct nla_policy ethnl_header_policy_stats[] = {
@@ -28,6 +30,7 @@ const struct nla_policy ethnl_header_policy_stats[] = {
 					    .len = ALTIFNAMSIZ - 1 },
 	[ETHTOOL_A_HEADER_FLAGS]	= NLA_POLICY_MASK(NLA_U32,
 							  ETHTOOL_FLAGS_STATS),
+	[ETHTOOL_A_HEADER_PHY_INDEX]		= NLA_POLICY_MIN(NLA_U32, 1),
 };
 
 int ethnl_ops_begin(struct net_device *dev)
@@ -91,6 +94,7 @@ int ethnl_parse_header_dev_get(struct ethnl_req_info *req_info,
 {
 	struct nlattr *tb[ARRAY_SIZE(ethnl_header_policy)];
 	const struct nlattr *devname_attr;
+	struct phy_device *phydev = NULL;
 	struct net_device *dev = NULL;
 	u32 flags = 0;
 	int ret;
@@ -145,6 +149,26 @@ int ethnl_parse_header_dev_get(struct ethnl_req_info *req_info,
 		return -EINVAL;
 	}
 
+	if (dev) {
+		if (tb[ETHTOOL_A_HEADER_PHY_INDEX]) {
+			u32 phy_index = nla_get_u32(tb[ETHTOOL_A_HEADER_PHY_INDEX]);
+
+			phydev = phy_link_topo_get_phy(&dev->link_topo,
+						       phy_index);
+			if (!phydev) {
+				NL_SET_ERR_MSG_ATTR(extack, header,
+						    "no phy matches phy index");
+				return -EINVAL;
+			}
+		} else {
+			/* If we need a PHY but no phy index is specified, fallback
+			 * to dev->phydev
+			 */
+			phydev = dev->phydev;
+		}
+	}
+
+	req_info->phydev = phydev;
 	req_info->dev = dev;
 	req_info->flags = flags;
 	return 0;
diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h
index 9a333a8d04c1..def84e2def9e 100644
--- a/net/ethtool/netlink.h
+++ b/net/ethtool/netlink.h
@@ -250,6 +250,7 @@ static inline unsigned int ethnl_reply_header_size(void)
  * @dev:   network device the request is for (may be null)
  * @dev_tracker: refcount tracker for @dev reference
  * @flags: request flags common for all request types
+ * @phydev: phy_device connected to @dev this request is for (may be null)
  *
  * This is a common base for request specific structures holding data from
  * parsed userspace request. These always embed struct ethnl_req_info at
@@ -259,6 +260,7 @@ struct ethnl_req_info {
 	struct net_device	*dev;
 	netdevice_tracker	dev_tracker;
 	u32			flags;
+	struct phy_device	*phydev;
 };
 
 static inline void ethnl_parse_header_dev_put(struct ethnl_req_info *req_info)
@@ -395,9 +397,10 @@ extern const struct ethnl_request_ops ethnl_rss_request_ops;
 extern const struct ethnl_request_ops ethnl_plca_cfg_request_ops;
 extern const struct ethnl_request_ops ethnl_plca_status_request_ops;
 extern const struct ethnl_request_ops ethnl_mm_request_ops;
+extern const struct ethnl_request_ops ethnl_phy_request_ops;
 
-extern const struct nla_policy ethnl_header_policy[ETHTOOL_A_HEADER_FLAGS + 1];
-extern const struct nla_policy ethnl_header_policy_stats[ETHTOOL_A_HEADER_FLAGS + 1];
+extern const struct nla_policy ethnl_header_policy[ETHTOOL_A_HEADER_PHY_INDEX + 1];
+extern const struct nla_policy ethnl_header_policy_stats[ETHTOOL_A_HEADER_PHY_INDEX + 1];
 extern const struct nla_policy ethnl_strset_get_policy[ETHTOOL_A_STRSET_COUNTS_ONLY + 1];
 extern const struct nla_policy ethnl_linkinfo_get_policy[ETHTOOL_A_LINKINFO_HEADER + 1];
 extern const struct nla_policy ethnl_linkinfo_set_policy[ETHTOOL_A_LINKINFO_TP_MDIX_CTRL + 1];
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:28 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:28 +0100
Subject: [PATCH net-next v4 06/13] netlink: specs: add phy-index as a header parameter
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-7-maxime.chevallier@bootlin.com>

Update the spec to take the newly introduced phy-index as a generic
request parameter.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: Ditch the ethtool-user generated code
V3: New patch

 Documentation/netlink/specs/ethtool.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 197208f419dc..bb6e1dc6d1c5 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -30,6 +30,9 @@ attribute-sets:
       -
         name: flags
         type: u32
+      -
+        name: phy-index
+        type: u32
 
   -
     name: bitset-bit
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:30 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:30 +0100
Subject: [PATCH net-next v4 08/13] netlink: specs: add ethnl PHY_GET command set
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-9-maxime.chevallier@bootlin.com>

The PHY_GET command, supporting both DUMP and GET operations, is used to
retrieve the list of PHYs connected to a netdevice, and get topology
information to know where exactly it sits on the physical link.

Add the netlink specs corresponding to that command.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: Remove the ethtool-user generated code
V3: New patch

 Documentation/netlink/specs/ethtool.yaml | 65 ++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index bb6e1dc6d1c5..7f6fb1f61dd4 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -16,6 +16,11 @@ definitions:
     name: stringset
     type: enum
     entries: []
+  -
+    name: phy-upstream-type
+    enum-name:
+    type: enum
+    entries: [ mac, phy ]
 
 attribute-sets:
   -
@@ -945,6 +950,45 @@ attribute-sets:
       -
         name: burst-tmr
         type: u32
+  -
+    name: phy-upstream
+    attributes:
+      -
+        name: index
+        type: u32
+      -
+        name: sfp-name
+        type: string
+  -
+    name: phy
+    attributes:
+      -
+        name: header
+        type: nest
+        nested-attributes: header
+      -
+        name: index
+        type: u32
+      -
+        name: drvname
+        type: string
+      -
+        name: name
+        type: string
+      -
+        name: upstream-type
+        type: u8
+        enum: phy-upstream-type
+      -
+        name: upstream
+        type: nest
+        nested-attributes: phy-upstream
+      -
+        name: downstream-sfp-name
+        type: string
+      -
+        name: id
+        type: u32
 
 operations:
   enum-model: directional
@@ -1696,3 +1740,24 @@ operations:
       name: mm-ntf
       doc: Notification for change in MAC Merge configuration.
       notify: mm-get
+    -
+      name: phy-get
+      doc: Get PHY devices attached to an interface
+
+      attribute-set: phy
+
+      do: &phy-get-op
+        request:
+          attributes:
+            - header
+        reply:
+          attributes:
+            - header
+            - index
+            - drvname
+            - name
+            - upstream-type
+            - upstream
+            - downstream-sfp-name
+            - id
+      dump: *phy-get-op
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:29 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:29 +0100
Subject: [PATCH net-next v4 07/13] net: ethtool: Introduce a command to list PHYs on an interface
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-8-maxime.chevallier@bootlin.com>

As we have the ability to track the PHYs connected to a net_device
through the link_topology, we can expose this list to userspace. This
allows userspace to use these identifiers for phy-specific commands and
take the decision of which PHY to target by knowing the link topology.

Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list
devices on only one interface.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: - Fixed errors when not having SFP enabled, resulting in null names
      being passed as parameters to strlen.
V3: - Fixed the documentation
    - Fixed the DUMP implementation
V2: New patch


 Documentation/networking/ethtool-netlink.rst |  44 +++
 include/uapi/linux/ethtool_netlink.h         |  29 ++
 net/ethtool/Makefile                         |   2 +-
 net/ethtool/netlink.c                        |   9 +
 net/ethtool/netlink.h                        |   5 +
 net/ethtool/phy.c                            | 306 +++++++++++++++++++
 6 files changed, 394 insertions(+), 1 deletion(-)
 create mode 100644 net/ethtool/phy.c

diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index 3ca6c21e74af..97ff787a7dd8 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst
@@ -2011,6 +2011,49 @@ The attributes are propagated to the driver through the following structure:
 .. kernel-doc:: include/linux/ethtool.h
     :identifiers: ethtool_mm_cfg
 
+PHY_GET
+=======
+
+Retrieve information about a given Ethernet PHY sitting on the link. As there
+can be more than one PHY, the DUMP operation can be used to list the PHYs
+present on a given interface, by passing an interface index or name in
+the dump request
+
+Request contents:
+
+  ====================================  ======  ==========================
+  ``ETHTOOL_A_PHY_HEADER``              nested  request header
+  ====================================  ======  ==========================
+
+Kernel response contents:
+
+  ===================================== ======  ==========================
+  ``ETHTOOL_A_PHY_HEADER``              nested  request header
+  ``ETHTOOL_A_PHY_INDEX``               u32     the phy's unique index, that can
+                                                be used for phy-specific requests
+  ``ETHTOOL_A_PHY_DRVNAME``             string  the phy driver name
+  ``ETHTOOL_A_PHY_NAME``                string  the phy device name
+  ``ETHTOOL_A_PHY_UPSTREAM_TYPE``       u32     the type of device this phy is
+                                                connected to
+  ``ETHTOOL_A_PHY_UPSTREAM_PHY``        nested  if the phy is connected to another
+                                                phy, this nest contains info on
+                                                that connection
+  ``ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME`` string  if the phy controls an sfp bus,
+                                                the name of the sfp bus
+  ``ETHTOOL_A_PHY_ID``                  u32     the phy id if the phy is C22
+  ===================================== ======  ==========================
+
+When ``ETHTOOL_A_PHY_UPSTREAM_TYPE`` is PHY_UPSTREAM_PHY, the PHY's parent is
+another PHY. Information on the parent PHY will be set in the
+``ETHTOOL_A_PHY_UPSTREAM_PHY`` nest, which has the following structure :
+
+  =================================== ======  ==========================
+  ``ETHTOOL_A_PHY_UPSTREAM_INDEX``    u32     the PHY index of the upstream PHY
+  ``ETHTOOL_A_PHY_UPSTREAM_SFP_NAME`` string  if this PHY is connected to it's
+                                                parent PHY through an SFP bus, the
+                                                name of this sfp bus
+  =================================== ======  ==========================
+
 Request translation
 ===================
 
@@ -2117,4 +2160,5 @@ are netlink only.
   n/a                                 ``ETHTOOL_MSG_PLCA_GET_STATUS``
   n/a                                 ``ETHTOOL_MSG_MM_GET``
   n/a                                 ``ETHTOOL_MSG_MM_SET``
+  n/a                                 ``ETHTOOL_MSG_PHY_GET``
   =================================== =====================================
diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h
index 422e8cfdd98c..00cd7ad16709 100644
--- a/include/uapi/linux/ethtool_netlink.h
+++ b/include/uapi/linux/ethtool_netlink.h
@@ -57,6 +57,7 @@ enum {
 	ETHTOOL_MSG_PLCA_GET_STATUS,
 	ETHTOOL_MSG_MM_GET,
 	ETHTOOL_MSG_MM_SET,
+	ETHTOOL_MSG_PHY_GET,
 
 	/* add new constants above here */
 	__ETHTOOL_MSG_USER_CNT,
@@ -109,6 +110,8 @@ enum {
 	ETHTOOL_MSG_PLCA_NTF,
 	ETHTOOL_MSG_MM_GET_REPLY,
 	ETHTOOL_MSG_MM_NTF,
+	ETHTOOL_MSG_PHY_GET_REPLY,
+	ETHTOOL_MSG_PHY_NTF,
 
 	/* add new constants above here */
 	__ETHTOOL_MSG_KERNEL_CNT,
@@ -977,6 +980,32 @@ enum {
 	ETHTOOL_A_MM_MAX = (__ETHTOOL_A_MM_CNT - 1)
 };
 
+enum {
+	ETHTOOL_A_PHY_UPSTREAM_UNSPEC,
+	ETHTOOL_A_PHY_UPSTREAM_INDEX,			/* u32 */
+	ETHTOOL_A_PHY_UPSTREAM_SFP_NAME,		/* string */
+
+	/* add new constants above here */
+	__ETHTOOL_A_PHY_UPSTREAM_CNT,
+	ETHTOOL_A_PHY_UPSTREAM_MAX = (__ETHTOOL_A_PHY_UPSTREAM_CNT - 1)
+};
+
+enum {
+	ETHTOOL_A_PHY_UNSPEC,
+	ETHTOOL_A_PHY_HEADER,			/* nest - _A_HEADER_* */
+	ETHTOOL_A_PHY_INDEX,			/* u32 */
+	ETHTOOL_A_PHY_DRVNAME,			/* string */
+	ETHTOOL_A_PHY_NAME,			/* string */
+	ETHTOOL_A_PHY_UPSTREAM_TYPE,		/* u8 */
+	ETHTOOL_A_PHY_UPSTREAM,			/* nest - _A_PHY_UPSTREAM_* */
+	ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME,	/* string */
+	ETHTOOL_A_PHY_ID,			/* u32 */
+
+	/* add new constants above here */
+	__ETHTOOL_A_PHY_CNT,
+	ETHTOOL_A_PHY_MAX = (__ETHTOOL_A_PHY_CNT - 1)
+};
+
 /* generic netlink info */
 #define ETHTOOL_GENL_NAME "ethtool"
 #define ETHTOOL_GENL_VERSION 1
diff --git a/net/ethtool/Makefile b/net/ethtool/Makefile
index 504f954a1b28..0ccd0e9afd3f 100644
--- a/net/ethtool/Makefile
+++ b/net/ethtool/Makefile
@@ -8,4 +8,4 @@ ethtool_nl-y	:= netlink.o bitset.o strset.o linkinfo.o linkmodes.o rss.o \
 		   linkstate.o debug.o wol.o features.o privflags.o rings.o \
 		   channels.o coalesce.o pause.o eee.o tsinfo.o cabletest.o \
 		   tunnels.o fec.o eeprom.o stats.o phc_vclocks.o mm.o \
-		   module.o pse-pd.o plca.o mm.o
+		   module.o pse-pd.o plca.o mm.o phy.o
diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
index 1c26766ce996..92b0dd8ca046 100644
--- a/net/ethtool/netlink.c
+++ b/net/ethtool/netlink.c
@@ -1153,6 +1153,15 @@ static const struct genl_ops ethtool_genl_ops[] = {
 		.policy = ethnl_mm_set_policy,
 		.maxattr = ARRAY_SIZE(ethnl_mm_set_policy) - 1,
 	},
+	{
+		.cmd	= ETHTOOL_MSG_PHY_GET,
+		.doit	= ethnl_phy_doit,
+		.start	= ethnl_phy_start,
+		.dumpit	= ethnl_phy_dumpit,
+		.done	= ethnl_phy_done,
+		.policy = ethnl_phy_get_policy,
+		.maxattr = ARRAY_SIZE(ethnl_phy_get_policy) - 1,
+	},
 };
 
 static const struct genl_multicast_group ethtool_nl_mcgrps[] = {
diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h
index def84e2def9e..5e6a43e35a09 100644
--- a/net/ethtool/netlink.h
+++ b/net/ethtool/netlink.h
@@ -444,6 +444,7 @@ extern const struct nla_policy ethnl_plca_set_cfg_policy[ETHTOOL_A_PLCA_MAX + 1]
 extern const struct nla_policy ethnl_plca_get_status_policy[ETHTOOL_A_PLCA_HEADER + 1];
 extern const struct nla_policy ethnl_mm_get_policy[ETHTOOL_A_MM_HEADER + 1];
 extern const struct nla_policy ethnl_mm_set_policy[ETHTOOL_A_MM_MAX + 1];
+extern const struct nla_policy ethnl_phy_get_policy[ETHTOOL_A_PHY_HEADER + 1];
 
 int ethnl_set_features(struct sk_buff *skb, struct genl_info *info);
 int ethnl_act_cable_test(struct sk_buff *skb, struct genl_info *info);
@@ -451,6 +452,10 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct genl_info *info);
 int ethnl_tunnel_info_doit(struct sk_buff *skb, struct genl_info *info);
 int ethnl_tunnel_info_start(struct netlink_callback *cb);
 int ethnl_tunnel_info_dumpit(struct sk_buff *skb, struct netlink_callback *cb);
+int ethnl_phy_start(struct netlink_callback *cb);
+int ethnl_phy_doit(struct sk_buff *skb, struct genl_info *info);
+int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb);
+int ethnl_phy_done(struct netlink_callback *cb);
 
 extern const char stats_std_names[__ETHTOOL_STATS_CNT][ETH_GSTRING_LEN];
 extern const char stats_eth_phy_names[__ETHTOOL_A_STATS_ETH_PHY_CNT][ETH_GSTRING_LEN];
diff --git a/net/ethtool/phy.c b/net/ethtool/phy.c
new file mode 100644
index 000000000000..36711eedb132
--- /dev/null
+++ b/net/ethtool/phy.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2023 Bootlin
+ *
+ */
+#include "common.h"
+#include "netlink.h"
+
+#include <linux/phy.h>
+#include <linux/phy_link_topology.h>
+#include <linux/sfp.h>
+
+struct phy_req_info {
+	struct ethnl_req_info		base;
+	struct phy_device_node		pdn;
+};
+
+#define PHY_REQINFO(__req_base) \
+	container_of(__req_base, struct phy_req_info, base)
+
+const struct nla_policy ethnl_phy_get_policy[ETHTOOL_A_PHY_HEADER + 1] = {
+	[ETHTOOL_A_PHY_HEADER] = NLA_POLICY_NESTED(ethnl_header_policy),
+};
+
+/* Caller holds rtnl */
+static ssize_t
+ethnl_phy_reply_size(const struct ethnl_req_info *req_base,
+		     struct netlink_ext_ack *extack)
+{
+	struct phy_link_topology *topo;
+	struct phy_device_node *pdn;
+	struct phy_device *phydev;
+	unsigned long index;
+	size_t size;
+
+	ASSERT_RTNL();
+
+	topo = &req_base->dev->link_topo;
+
+	size = nla_total_size(0);
+
+	xa_for_each(&topo->phys, index, pdn) {
+		phydev = pdn->phy;
+
+		/* ETHTOOL_A_PHY_INDEX */
+		size += nla_total_size(sizeof(u32));
+
+		/* ETHTOOL_A_DRVNAME */
+		size += nla_total_size(strlen(phydev->drv->name) + 1);
+
+		/* ETHTOOL_A_NAME */
+		size += nla_total_size(strlen(dev_name(&phydev->mdio.dev)) + 1);
+
+		/* ETHTOOL_A_PHY_UPSTREAM_TYPE */
+		size += nla_total_size(sizeof(u8));
+
+		/* ETHTOOL_A_PHY_ID */
+		size += nla_total_size(sizeof(u32));
+
+		if (phy_on_sfp(phydev)) {
+			const char *upstream_sfp_name = sfp_get_name(pdn->parent_sfp_bus);
+
+			/* ETHTOOL_A_PHY_UPSTREAM_SFP_NAME */
+			if (upstream_sfp_name)
+				size += nla_total_size(strlen(upstream_sfp_name) + 1);
+
+			/* ETHTOOL_A_PHY_UPSTREAM_INDEX */
+			size += nla_total_size(sizeof(u32));
+		}
+
+		/* ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME */
+		if (phydev->sfp_bus) {
+			const char *sfp_name = sfp_get_name(phydev->sfp_bus);
+
+			if (sfp_name)
+				size += nla_total_size(strlen(sfp_name) + 1);
+		}
+	}
+
+	return size;
+}
+
+static int
+ethnl_phy_fill_reply(const struct ethnl_req_info *req_base, struct sk_buff *skb)
+{
+	struct phy_req_info *req_info = PHY_REQINFO(req_base);
+	struct phy_device_node *pdn = &req_info->pdn;
+	struct phy_device *phydev = pdn->phy;
+	enum phy_upstream ptype;
+	struct nlattr *nest;
+
+	ptype = pdn->upstream_type;
+
+	if (nla_put_u32(skb, ETHTOOL_A_PHY_INDEX, phydev->phyindex) ||
+	    nla_put_string(skb, ETHTOOL_A_PHY_DRVNAME, phydev->drv->name) ||
+	    nla_put_string(skb, ETHTOOL_A_PHY_NAME, dev_name(&phydev->mdio.dev)) ||
+	    nla_put_u8(skb, ETHTOOL_A_PHY_UPSTREAM_TYPE, ptype) ||
+	    nla_put_u32(skb, ETHTOOL_A_PHY_ID, phydev->phy_id))
+		return -EMSGSIZE;
+
+	if (ptype == PHY_UPSTREAM_PHY) {
+		struct phy_device *upstream = pdn->upstream.phydev;
+		const char *sfp_upstream_name;
+
+		nest = nla_nest_start(skb, ETHTOOL_A_PHY_UPSTREAM);
+		if (!nest)
+			return -EMSGSIZE;
+
+		/* Parent index */
+		if (nla_put_u32(skb, ETHTOOL_A_PHY_UPSTREAM_INDEX, upstream->phyindex))
+			return -EMSGSIZE;
+
+		if (pdn->parent_sfp_bus) {
+			sfp_upstream_name = sfp_get_name(pdn->parent_sfp_bus);
+			if (sfp_upstream_name && nla_put_string(skb,
+								ETHTOOL_A_PHY_UPSTREAM_SFP_NAME,
+								sfp_upstream_name))
+				return -EMSGSIZE;
+		}
+
+		nla_nest_end(skb, nest);
+	}
+
+	if (phydev->sfp_bus) {
+		const char *sfp_name = sfp_get_name(phydev->sfp_bus);
+
+		if (sfp_name &&
+		    nla_put_string(skb, ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME,
+				   sfp_name))
+			return -EMSGSIZE;
+	}
+
+	return 0;
+}
+
+static int ethnl_phy_parse_request(struct ethnl_req_info *req_base,
+				   struct nlattr **tb)
+{
+	struct phy_req_info *req_info = PHY_REQINFO(req_base);
+	struct phy_link_topology *topo = &req_base->dev->link_topo;
+	struct phy_device_node *pdn;
+
+	if (!req_base->phydev)
+		return 0;
+
+	pdn = xa_load(&topo->phys, req_base->phydev->phyindex);
+	memcpy(&req_info->pdn, pdn, sizeof(*pdn));
+
+	return 0;
+}
+
+int ethnl_phy_doit(struct sk_buff *skb, struct genl_info *info)
+{
+	struct phy_req_info req_info = {};
+	struct nlattr **tb = info->attrs;
+	struct sk_buff *rskb;
+	void *reply_payload;
+	int reply_len;
+	int ret;
+
+	ret = ethnl_parse_header_dev_get(&req_info.base,
+					 tb[ETHTOOL_A_PHY_HEADER],
+					 genl_info_net(info), info->extack,
+					 true);
+	if (ret < 0)
+		return ret;
+
+	rtnl_lock();
+
+	ret = ethnl_phy_parse_request(&req_info.base, tb);
+	if (ret < 0)
+		goto err_unlock_rtnl;
+
+	/* No PHY, return early */
+	if (!req_info.pdn.phy)
+		goto err_unlock_rtnl;
+
+	ret = ethnl_phy_reply_size(&req_info.base, info->extack);
+	if (ret < 0)
+		goto err_unlock_rtnl;
+	reply_len = ret + ethnl_reply_header_size();
+
+	rskb = ethnl_reply_init(reply_len, req_info.base.dev,
+				ETHTOOL_MSG_PHY_GET_REPLY,
+				ETHTOOL_A_PHY_HEADER,
+				info, &reply_payload);
+	if (!rskb) {
+		ret = -ENOMEM;
+		goto err_unlock_rtnl;
+	}
+
+	ret = ethnl_phy_fill_reply(&req_info.base, rskb);
+	if (ret)
+		goto err_free_msg;
+
+	rtnl_unlock();
+	ethnl_parse_header_dev_put(&req_info.base);
+	genlmsg_end(rskb, reply_payload);
+
+	return genlmsg_reply(rskb, info);
+
+err_free_msg:
+	nlmsg_free(rskb);
+err_unlock_rtnl:
+	rtnl_unlock();
+	ethnl_parse_header_dev_put(&req_info.base);
+	return ret;
+}
+
+struct ethnl_phy_dump_ctx {
+	struct phy_req_info	*phy_req_info;
+};
+
+int ethnl_phy_start(struct netlink_callback *cb)
+{
+	const struct genl_dumpit_info *info = genl_dumpit_info(cb);
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+	struct nlattr **tb = info->info.attrs;
+	int ret;
+
+	BUILD_BUG_ON(sizeof(*ctx) > sizeof(cb->ctx));
+
+	ctx->phy_req_info = kzalloc(sizeof(*ctx->phy_req_info), GFP_KERNEL);
+	if (!ctx->phy_req_info)
+		return -ENOMEM;
+
+	ret = ethnl_parse_header_dev_get(&ctx->phy_req_info->base,
+					 tb[ETHTOOL_A_PHY_HEADER],
+					 sock_net(cb->skb->sk), cb->extack,
+					 false);
+	return ret;
+}
+
+int ethnl_phy_done(struct netlink_callback *cb)
+{
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+
+	kfree(ctx->phy_req_info);
+
+	return 0;
+}
+
+static int ethnl_phy_dump_one_dev(struct sk_buff *skb, struct net_device *dev,
+				  struct netlink_callback *cb)
+{
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+	struct phy_req_info *pri = ctx->phy_req_info;
+	struct phy_device_node *pdn;
+	unsigned long index = 1;
+	void *ehdr;
+	int ret;
+
+	pri->base.dev = dev;
+
+	xa_for_each(&dev->link_topo.phys, index, pdn) {
+		ehdr = ethnl_dump_put(skb, cb,
+				      ETHTOOL_MSG_PHY_GET_REPLY);
+		if (!ehdr) {
+			ret = -EMSGSIZE;
+			break;
+		}
+
+		ret = ethnl_fill_reply_header(skb, dev,
+					      ETHTOOL_A_PHY_HEADER);
+		if (ret < 0) {
+			genlmsg_cancel(skb, ehdr);
+			break;
+		}
+
+		memcpy(&pri->pdn, pdn, sizeof(*pdn));
+		ret = ethnl_phy_fill_reply(&pri->base, skb);
+
+		genlmsg_end(skb, ehdr);
+	}
+
+	return ret;
+}
+
+int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
+{
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+	struct net *net = sock_net(skb->sk);
+	unsigned long ifindex = 1;
+	struct net_device *dev;
+	int ret = 0;
+
+	rtnl_lock();
+
+	if (ctx->phy_req_info->base.dev) {
+		ret = ethnl_phy_dump_one_dev(skb, ctx->phy_req_info->base.dev, cb);
+		ethnl_parse_header_dev_put(&ctx->phy_req_info->base);
+		ctx->phy_req_info->base.dev = NULL;
+	} else {
+		for_each_netdev_dump(net, dev, ifindex) {
+			ret = ethnl_phy_dump_one_dev(skb, dev, cb);
+			if (ret)
+				break;
+		}
+	}
+	rtnl_unlock();
+
+	if (ret == -EMSGSIZE && skb->len)
+		return skb->len;
+	return ret;
+}
+
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:31 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:31 +0100
Subject: [PATCH net-next v4 09/13] net: ethtool: plca: Target the command to the requested PHY
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-10-maxime.chevallier@bootlin.com>

PLCA is a PHY-specific command. Instead of targeting the command
towards dev->phydev, use the request to pick the targeted PHY.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: No changes
V3: No changes
V2: New patch

 net/ethtool/plca.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/net/ethtool/plca.c b/net/ethtool/plca.c
index b1e2e3b5027f..2b3e419f4dc2 100644
--- a/net/ethtool/plca.c
+++ b/net/ethtool/plca.c
@@ -61,7 +61,7 @@ static int plca_get_cfg_prepare_data(const struct ethnl_req_info *req_base,
 	int ret;
 
 	// check that the PHY device is available and connected
-	if (!dev->phydev) {
+	if (!req_base->phydev) {
 		ret = -EOPNOTSUPP;
 		goto out;
 	}
@@ -80,7 +80,7 @@ static int plca_get_cfg_prepare_data(const struct ethnl_req_info *req_base,
 	memset(&data->plca_cfg, 0xff,
 	       sizeof_field(struct plca_reply_data, plca_cfg));
 
-	ret = ops->get_plca_cfg(dev->phydev, &data->plca_cfg);
+	ret = ops->get_plca_cfg(req_base->phydev, &data->plca_cfg);
 	ethnl_ops_complete(dev);
 
 out:
@@ -141,7 +141,6 @@ const struct nla_policy ethnl_plca_set_cfg_policy[] = {
 static int
 ethnl_set_plca(struct ethnl_req_info *req_info, struct genl_info *info)
 {
-	struct net_device *dev = req_info->dev;
 	const struct ethtool_phy_ops *ops;
 	struct nlattr **tb = info->attrs;
 	struct phy_plca_cfg plca_cfg;
@@ -149,7 +148,7 @@ ethnl_set_plca(struct ethnl_req_info *req_info, struct genl_info *info)
 	int ret;
 
 	// check that the PHY device is available and connected
-	if (!dev->phydev)
+	if (!req_info->phydev)
 		return -EOPNOTSUPP;
 
 	ops = ethtool_phy_ops;
@@ -168,7 +167,7 @@ ethnl_set_plca(struct ethnl_req_info *req_info, struct genl_info *info)
 	if (!mod)
 		return 0;
 
-	ret = ops->set_plca_cfg(dev->phydev, &plca_cfg, info->extack);
+	ret = ops->set_plca_cfg(req_info->phydev, &plca_cfg, info->extack);
 	return ret < 0 ? ret : 1;
 }
 
@@ -204,7 +203,7 @@ static int plca_get_status_prepare_data(const struct ethnl_req_info *req_base,
 	int ret;
 
 	// check that the PHY device is available and connected
-	if (!dev->phydev) {
+	if (!req_base->phydev) {
 		ret = -EOPNOTSUPP;
 		goto out;
 	}
@@ -223,7 +222,7 @@ static int plca_get_status_prepare_data(const struct ethnl_req_info *req_base,
 	memset(&data->plca_st, 0xff,
 	       sizeof_field(struct plca_reply_data, plca_st));
 
-	ret = ops->get_plca_status(dev->phydev, &data->plca_st);
+	ret = ops->get_plca_status(req_base->phydev, &data->plca_st);
 	ethnl_ops_complete(dev);
 out:
 	return ret;
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:32 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:32 +0100
Subject: [PATCH net-next v4 10/13] net: ethtool: pse-pd: Target the command to the requested PHY
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-11-maxime.chevallier@bootlin.com>

PSE and PD configuration is a PHY-specific command. Instead of targeting
the command towards dev->phydev, use the request to pick the targeted
PHY device.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: No changes
V3: No changes
V2: New patch

 net/ethtool/pse-pd.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index cc478af77111..0d9cd9c87104 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -31,17 +31,10 @@ const struct nla_policy ethnl_pse_get_policy[ETHTOOL_A_PSE_HEADER + 1] = {
 	[ETHTOOL_A_PSE_HEADER] = NLA_POLICY_NESTED(ethnl_header_policy),
 };
 
-static int pse_get_pse_attributes(struct net_device *dev,
+static int pse_get_pse_attributes(struct phy_device *phydev,
 				  struct netlink_ext_ack *extack,
 				  struct pse_reply_data *data)
 {
-	struct phy_device *phydev = dev->phydev;
-
-	if (!phydev) {
-		NL_SET_ERR_MSG(extack, "No PHY is attached");
-		return -EOPNOTSUPP;
-	}
-
 	if (!phydev->psec) {
 		NL_SET_ERR_MSG(extack, "No PSE is attached");
 		return -EOPNOTSUPP;
@@ -64,7 +57,7 @@ static int pse_prepare_data(const struct ethnl_req_info *req_base,
 	if (ret < 0)
 		return ret;
 
-	ret = pse_get_pse_attributes(dev, info->extack, data);
+	ret = pse_get_pse_attributes(req_base->phydev, info->extack, data);
 
 	ethnl_ops_complete(dev);
 
@@ -124,7 +117,6 @@ ethnl_set_pse_validate(struct ethnl_req_info *req_info, struct genl_info *info)
 static int
 ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 {
-	struct net_device *dev = req_info->dev;
 	struct pse_control_config config = {};
 	struct nlattr **tb = info->attrs;
 	struct phy_device *phydev;
@@ -132,7 +124,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 	/* this values are already validated by the ethnl_pse_set_policy */
 	config.admin_cotrol = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);
 
-	phydev = dev->phydev;
+	phydev = req_info->phydev;
 	if (!phydev) {
 		NL_SET_ERR_MSG(info->extack, "No PHY is attached");
 		return -EOPNOTSUPP;
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:33 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:33 +0100
Subject: [PATCH net-next v4 11/13] net: ethtool: cable-test: Target the command to the requested PHY
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-12-maxime.chevallier@bootlin.com>

Cable testing is a PHY-specific command. Instead of targeting the command
towards dev->phydev, use the request to pick the targeted PHY.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: No changes
V3: No changes
V2: New patch

 net/ethtool/cabletest.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/ethtool/cabletest.c b/net/ethtool/cabletest.c
index 06a151165c31..6b00d0800f23 100644
--- a/net/ethtool/cabletest.c
+++ b/net/ethtool/cabletest.c
@@ -69,7 +69,7 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct genl_info *info)
 		return ret;
 
 	dev = req_info.dev;
-	if (!dev->phydev) {
+	if (!req_info.phydev) {
 		ret = -EOPNOTSUPP;
 		goto out_dev_put;
 	}
@@ -85,12 +85,12 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct genl_info *info)
 	if (ret < 0)
 		goto out_rtnl;
 
-	ret = ops->start_cable_test(dev->phydev, info->extack);
+	ret = ops->start_cable_test(req_info.phydev, info->extack);
 
 	ethnl_ops_complete(dev);
 
 	if (!ret)
-		ethnl_cable_test_started(dev->phydev,
+		ethnl_cable_test_started(req_info.phydev,
 					 ETHTOOL_MSG_CABLE_TEST_NTF);
 
 out_rtnl:
@@ -321,7 +321,7 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct genl_info *info)
 		return ret;
 
 	dev = req_info.dev;
-	if (!dev->phydev) {
+	if (!req_info.phydev) {
 		ret = -EOPNOTSUPP;
 		goto out_dev_put;
 	}
@@ -342,12 +342,12 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct genl_info *info)
 	if (ret < 0)
 		goto out_rtnl;
 
-	ret = ops->start_cable_test_tdr(dev->phydev, info->extack, &cfg);
+	ret = ops->start_cable_test_tdr(req_info.phydev, info->extack, &cfg);
 
 	ethnl_ops_complete(dev);
 
 	if (!ret)
-		ethnl_cable_test_started(dev->phydev,
+		ethnl_cable_test_started(req_info.phydev,
 					 ETHTOOL_MSG_CABLE_TEST_TDR_NTF);
 
 out_rtnl:
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:34 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:34 +0100
Subject: [PATCH net-next v4 12/13] net: ethtool: strset: Allow querying phy stats by index
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-13-maxime.chevallier@bootlin.com>

The ETH_SS_PHY_STATS command gets PHY statistics. Use the phydev pointer
from the ethnl request to allow query phy stats from each PHY on the
link.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: No changes
V3: No changes
V2: New patch

 net/ethtool/strset.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/net/ethtool/strset.c b/net/ethtool/strset.c
index c678b484a079..70c00631c51f 100644
--- a/net/ethtool/strset.c
+++ b/net/ethtool/strset.c
@@ -233,17 +233,18 @@ static void strset_cleanup_data(struct ethnl_reply_data *reply_base)
 }
 
 static int strset_prepare_set(struct strset_info *info, struct net_device *dev,
-			      unsigned int id, bool counts_only)
+			      struct phy_device *phydev, unsigned int id,
+			      bool counts_only)
 {
 	const struct ethtool_phy_ops *phy_ops = ethtool_phy_ops;
 	const struct ethtool_ops *ops = dev->ethtool_ops;
 	void *strings;
 	int count, ret;
 
-	if (id == ETH_SS_PHY_STATS && dev->phydev &&
+	if (id == ETH_SS_PHY_STATS && phydev &&
 	    !ops->get_ethtool_phy_stats && phy_ops &&
 	    phy_ops->get_sset_count)
-		ret = phy_ops->get_sset_count(dev->phydev);
+		ret = phy_ops->get_sset_count(phydev);
 	else if (ops->get_sset_count && ops->get_strings)
 		ret = ops->get_sset_count(dev, id);
 	else
@@ -258,10 +259,10 @@ static int strset_prepare_set(struct strset_info *info, struct net_device *dev,
 		strings = kcalloc(count, ETH_GSTRING_LEN, GFP_KERNEL);
 		if (!strings)
 			return -ENOMEM;
-		if (id == ETH_SS_PHY_STATS && dev->phydev &&
+		if (id == ETH_SS_PHY_STATS && phydev &&
 		    !ops->get_ethtool_phy_stats && phy_ops &&
 		    phy_ops->get_strings)
-			phy_ops->get_strings(dev->phydev, strings);
+			phy_ops->get_strings(phydev, strings);
 		else
 			ops->get_strings(dev, id, strings);
 		info->strings = strings;
@@ -305,8 +306,8 @@ static int strset_prepare_data(const struct ethnl_req_info *req_base,
 		    !data->sets[i].per_dev)
 			continue;
 
-		ret = strset_prepare_set(&data->sets[i], dev, i,
-					 req_info->counts_only);
+		ret = strset_prepare_set(&data->sets[i], dev, req_base->phydev,
+					 i, req_info->counts_only);
 		if (ret < 0)
 			goto err_ops;
 	}
-- 
2.43.0



From maxime.chevallier at bootlin.com  Fri Dec 15 09:12:35 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Fri, 15 Dec 2023 18:12:35 +0100
Subject: [PATCH net-next v4 13/13] Documentation: networking: document phy_link_topology
In-Reply-To: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
Message-ID: <20231215171237.1152563-14-maxime.chevallier@bootlin.com>

The newly introduced phy_link_topology tracks all ethernet PHYs that are
attached to a netdevice. Document the base principle, internal and
external APIs. As the phy_link_topology is expected to be extended, this
documentation will hold any further improvements and additions made
relative to topology handling.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V4: No changes
V3: New patch

 Documentation/networking/index.rst            |   1 +
 .../networking/phy-link-topology.rst          | 121 ++++++++++++++++++
 2 files changed, 122 insertions(+)
 create mode 100644 Documentation/networking/phy-link-topology.rst

diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 69f3d6dcd9fd..a2c45a75a4a6 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -88,6 +88,7 @@ Contents:
    operstates
    packet_mmap
    phonet
+   phy-link-topology
    pktgen
    plip
    ppp_generic
diff --git a/Documentation/networking/phy-link-topology.rst b/Documentation/networking/phy-link-topology.rst
new file mode 100644
index 000000000000..d66ee9711ac1
--- /dev/null
+++ b/Documentation/networking/phy-link-topology.rst
@@ -0,0 +1,121 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+PHY link topology
+=================
+
+Overview
+========
+
+The PHY link topology representation in the networking stack aims at representing
+the hardware layout for any given Ethernet link.
+
+An Ethernet Interface from userspace's poing of view is nothing but a
+:c:type:`struct net_device <net_device>`, which exposes configuration options
+trough the legacy ioctls and the ethool netlink commands. The base assumption
+when designing these configuration channels were that the link looked
+something like this ::
+
+  +-----------------------+        +----------+      +--------------+
+  | Ethernet Controller / |        | Ethernet |      | Connector /  |
+  |       MAC             | ------ |   PHY    | ---- |    Port      | ---... to LP
+  +-----------------------+        +----------+      +--------------+
+  struct net_device               struct phy_device
+
+Commands that needs to configure the PHY will go through the net_device.phydev
+field to reach the PHY and perform the relevant configuration.
+
+This assumption falls appart in more complex topologies that can arise when,
+for example, using SFP transceivers (although that's not the only specific case).
+
+Here, we have 2 basic scenarios. Either the MAC is able to output a serialized
+interface, that can directly be fed to an SFP cage, such as SGMII, 1000BaseX,
+10GBaseR, etc.
+
+The link topology then looks like this (when an SFP module is inserted) ::
+
+  +-----+  SGMII  +------------+
+  | MAC | ------- | SFP Module |
+  +-----+         +------------+
+
+Knowing that some modules embed a PHY, the actual link is more like ::
+
+  +-----+  SGMII   +--------------+
+  | MAC | -------- | PHY (on SFP) |
+  +-----+          +--------------+
+
+In this case, the SFP PHY is handled by phylib, and registered by phylink through
+its SFP upstream ops.
+
+Now some Ethernet controllers aren't able to output a serialized interface, so
+we can't directly connect them to an SFP cage. However, some PHYs can be used
+as media-converters, to translate the non-serialized MAC MII interface to a
+serialized MII interface fed to the SFP ::
+
+  +-----+  RGMII  +-----------------------+  SGMII  +--------------+
+  | MAC | ------- | PHY (media converter) | ------- | PHY (on SFP) |
+  +-----+         +-----------------------+         +--------------+
+
+This is where the model of having a single net_device.phydev pointer shows its
+limitations, as we now have 2 PHYs on the link.
+
+The phy_link topology framework aims at providing a way to keep track of every
+PHY on the link, for use by both kernel drivers and subsystems, but also to
+report the topology to userspace, allowing to target individual PHYs in configuration
+commands.
+
+API
+===
+
+The :c:type:`struct phy_link_topology <phy_link_topology>` is a per-netdevice
+resource, that gets initialized at netdevice creation. Once it's initialized,
+it is then possible to register PHYs to the topology through :
+
+:c:func:`phy_link_topo_add_phy`
+
+Besides registering the PHY to the topology, this call will also assign a unique
+index to the PHY, which can then be reported to userspace to refer to this PHY
+(akin to the ifindex). This index is a u32, ranging from 1 to U32_MAX. The value
+0 is reserved to indicate the PHY doesn't belong to any topology yet.
+
+The PHY can then be removed from the topology through
+
+:c:func:`phy_link_topo_del_phy`
+
+These function are already hooked into the phylib subsystem, so all PHYs that
+are linked to a net_device through :c:func:`phy_attach_direct` will automatically
+join the netdev's topology.
+
+PHYs that are on a SFP module will also be automatically registered IF the SFP
+upstream is phylink (so, no media-converter).
+
+PHY drivers that can be used as SFP upstream need to call :c:func:`phy_sfp_attach_phy`
+and :c:func:`phy_sfp_detach_phy`, which can be used as a
+.attach_phy / .detach_phy implementation for the
+:c:type:`struct sfp_upstream_ops <sfp_upstream_ops>`.
+
+UAPI
+====
+
+There exist a set of netlink commands to query the link topology from userspace,
+see ``Documentation/networking/ethtool-netlink.rst``.
+
+The whole point of having a topology representation is to assign the phyindex
+field in :c:type:`struct phy_device <phy_device>`. This index is reported to
+userspace using the ``ETHTOOL_MSG_PHY_GET`` ethtnl command. Performing a DUMP operation
+will result in all PHYs from all net_device being listed. The DUMP command
+accepts either a ``ETHTOOL_A_HEADER_DEV_INDEX`` or ``ETHTOOL_A_HEADER_DEV_NAME``
+to be passed in the request to filter the DUMP to a single net_device.
+
+The retrieved index can then be passed as a request parameter using the
+``ETHTOOL_A_HEADER_PHY_INDEX`` field in the following ethnl commands :
+
+* ``ETHTOOL_MSG_STRSET_GET`` to get the stats strig set from a given PHY
+* ``ETHTOOL_MSG_CABLE_TEST_ACT`` and ``ETHTOOL_MSG_CABLE_TEST_ACT``, to perform
+  cable testing on a given PHY on the link (most likely the outermost PHY)
+* ``ETHTOOL_MSG_PSE_SET`` and ``ETHTOOL_MSG_PSE_GET`` for PHY-controlled PoE and PSE settings
+* ``ETHTOOL_MSG_PLCA_GET_CFG``, ``ETHTOOL_MSG_PLCA_SET_CFG`` and ``ETHTOOL_MSG_PLCA_GET_STATUS``
+  to set the PLCA (Physical Layer Collision Avoidance) parameters
+
+Note that the PHY index can be passed to other requests, which will silently
+ignore it if present and irrelevant.
-- 
2.43.0



From alain.volmat at foss.st.com  Fri Dec 15 09:06:13 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 18:06:13 +0100
Subject: [PATCH v3 9/9] arm64: dts: st: add i2c2 / i2c8 properties on stm32mp257f-ev1
In-Reply-To: <20231215170617.95868-1-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
Message-ID: <20231215170617.95868-10-alain.volmat@foss.st.com>

Add properties for i2c2 and i2c8 available on the stm32mp257f-ev1.
i2c2 is enabled since several devices are attached to it while
i2c8 is kept disabled since only used via the gpio expansion connector.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index b2d3afb15758..0ea8e69bfb3d 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -55,6 +55,26 @@ &arm_wdt {
 	status = "okay";
 };
 
+&i2c2 {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&i2c2_pins_a>;
+	pinctrl-1 = <&i2c2_sleep_pins_a>;
+	i2c-scl-rising-time-ns = <100>;
+	i2c-scl-falling-time-ns = <13>;
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&i2c8 {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&i2c8_pins_a>;
+	pinctrl-1 = <&i2c8_sleep_pins_a>;
+	i2c-scl-rising-time-ns = <57>;
+	i2c-scl-falling-time-ns = <7>;
+	clock-frequency = <400000>;
+	status = "disabled";
+};
+
 &sdmmc1 {
 	pinctrl-names = "default", "opendrain", "sleep";
 	pinctrl-0 = <&sdmmc1_b4_pins_a>;
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Fri Dec 15 09:13:51 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Fri, 15 Dec 2023 18:13:51 +0100
Subject: [PATCH v2 5/6] counter: stm32-timer-cnt: populate capture
 channels and check encoder
In-Reply-To: <ZSnJR2yfYsBNHu/4@fedora>
References: <20230922143920.3144249-1-fabrice.gasnier@foss.st.com>
 <20230922143920.3144249-6-fabrice.gasnier@foss.st.com>
 <ZSnJR2yfYsBNHu/4@fedora>
Message-ID: <997c056e-c4e1-4bd8-9fcd-9f1b4bd45929@foss.st.com>

On 10/14/23 00:48, William Breathitt Gray wrote:
> On Fri, Sep 22, 2023 at 04:39:19PM +0200, Fabrice Gasnier wrote:
>> This is a precursor patch to support capture channels on all possible
>> channels and stm32 timer types. Original driver was intended to be used
>> only as quadrature encoder and simple counter on internal clock.
>>
>> So, add ch3 and ch4 definition. Also add a check on encoder capability,
>> so the driver may be probed for timer instances without encoder feature.
>> This way, all timers may be used as simple counter on internal clock,
>> starting from here.
> 
> Hi Fabrice,
> 
> Let's split the encoder capability probing code, detect number of
> channels code, and channel introduction code to their own patches in
> order to simplify things.
> 
>> Encoder capability is retrieved by using the timer index (originally in
>> stm32-timer-trigger driver and dt-bindings). The need to keep backward
>> compatibility with existing device tree lead to parse aside trigger node.
>> Add diversity as STM32 timers with capture feature may have either 4, 2,
>> 1 or no cc (capture/compare) channels.
>>
>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
> 
> I think this patch is more complicated than it needs to be.
> 
>> @@ -400,13 +558,47 @@ static int stm32_timer_cnt_probe(struct platform_device *pdev)
>>  	priv->clk = ddata->clk;
>>  	priv->max_arr = ddata->max_arr;
>>  
>> +	ret = stm32_timer_cnt_probe_encoder(pdev, priv);
>> +	if (ret)
>> +		return ret;
>> +
>> +	stm32_timer_cnt_detect_channels(pdev, priv);
>> +
>>  	counter->name = dev_name(dev);
>>  	counter->parent = dev;
>>  	counter->ops = &stm32_timer_cnt_ops;
>> -	counter->counts = &stm32_counts;
>>  	counter->num_counts = 1;
>> -	counter->signals = stm32_signals;
>> -	counter->num_signals = ARRAY_SIZE(stm32_signals);
> 
> Keep this the same.
> 
>> +
>> +	/*
>> +	 * Handle diversity for stm32 timers features. For now encoder is found with
>> +	 * advanced timers or gp timers with 4 channels. Timers with less channels
>> +	 * doesn't support encoder.
>> +	 */
>> +	switch (priv->nchannels) {
>> +	case 4:
>> +		if (priv->has_encoder)
>> +			counter->counts = &stm32_counts_enc_4ch;
>> +		else
>> +			counter->counts = &stm32_counts_4ch;
>> +		counter->signals = stm32_signals;
>> +		counter->num_signals = ARRAY_SIZE(stm32_signals);
>> +		break;
>> +	case 2:
>> +		counter->counts = &stm32_counts_2ch;
>> +		counter->signals = stm32_signals;
>> +		counter->num_signals = 3; /* clock, ch1 and ch2 */
>> +		break;
>> +	case 1:
>> +		counter->counts = &stm32_counts_1ch;
>> +		counter->signals = stm32_signals;
>> +		counter->num_signals = 2; /* clock, ch1 */
>> +		break;
>> +	default:
>> +		counter->counts = &stm32_counts;
>> +		counter->signals = stm32_signals;
>> +		counter->num_signals = 1; /* clock */
>> +		break;
>> +	}
> 
> Rather than adjusting the number of counts and signals, keep the
> configuration static and use a single stm32_counts array. The reason is
> that in the Counter subsystem paradigm Signals do not necessary
> correlate to specific hardware signals but are rather an abstract
> representation of the device behavior at a high level. In other words, a
> Synapse with an action mode set to COUNTER_SYNAPSE_ACTION_NONE can be
> viewed as representing a Signal that does not affect the Count (i.e. in
> this case equivalent to an unconnected line).
> 
> What you'll need to do instead is check priv->nchannels during
> stm32_action_read and stm32_count_function_read calls in order to return
> the correct synapse action and count function for the particular
> channels configuration you have. In stm32_count_function_write you would
> return an -EINVAL (maybe -EOPNOTSUPP would be better?) when the channels
> configuration does not support a particular count function.

Hi William,

Sorry for the long delay to address your comments here. Many thanks for
these guidelines.

I'm preparing a v3, to address these. I'll probably send it soon, so we
can start to review also the capture part of it. Still there are few
things here I'm wondering about (as an anticipation task).

Basically, removing all the diversity here means the most featured timer
model will be represented here (with all possible signals).
When I wrote the various configuration arrays, I'd have been tempted to
allocate them dynamically upon probing to avoid having all these
variants described as const arrays. This may have eased other signals
additions later. But that's not the direction. So, this simplifies the
description here, clearly, to describe the full-featured timer/counter,
and handle the ("unconnected") variants by returning errors.

I still have in mind the replacement of the last IIO_COUNT device [1]
(not addressed in this series), e.g. in
drivers/iio/trigger/stm32-timer-trigger.c. Here, there are
"valids_table" that are used to cascade two timers (one timer output
being the input to another timer). With this table currently, an IIO
user knows the name of the signal it selects (then the driver looks up
the 'valids' table to set SMCR / TS bits, e.g. trigger select). Each
individual timer has a different input mapping, so called peripheral
interconnect in STM32.
What bothers me here is: with an abstracted full-featured timer, without
any diversity on the signal names, I fear the userland has no clue on
which signal would be used. Abstracting the timer this way would mean
the user only knows it selects "Internal Trigger 0" for example, without
knowing which internal signal in the SoC it has selected.

Even if this is out of scope for this series, would you have some clue
so I can anticipate it ? Or if we stick with abstract names? In which
case the userland may need to be aware of the signals mapping (where
currently in IIO_COUNT driver, the signal names are privided). I'd be
glad to get some direction here.

Please advise,
Best Regards,
Fabrice

[1] https://lore.kernel.org/linux-arm-kernel/Y0vzlOmFrVCQVXMq at fedora/

> 
> William Breathitt Gray


From Jonathan.Cameron at Huawei.com  Fri Dec 15 09:18:31 2023
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 15 Dec 2023 17:18:31 +0000
Subject: [PATCH RFC v3 21/21] cpumask: Add enabled cpumask for present
 CPUs that can be brought online
In-Reply-To: <E1rDOhX-00Dvlg-Ci@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
	<E1rDOhX-00Dvlg-Ci@rmk-PC.armlinux.org.uk>
Message-ID: <20231215171831.00004a19@Huawei.com>

On Wed, 13 Dec 2023 12:50:59 +0000
Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:

> From: James Morse <james.morse at arm.com>
> 
> The 'offline' file in sysfs shows all offline CPUs, including those
> that aren't present. User-space is expected to remove not-present CPUs
> from this list to learn which CPUs could be brought online.
> 
> CPUs can be present but not-enabled. These CPUs can't be brought online
> until the firmware policy changes, which comes with an ACPI notification
> that will register the CPUs.
> 
> With only the offline and present files, user-space is unable to
> determine which CPUs it can try to bring online. Add a new CPU mask
> that shows this based on all the registered CPUs.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> ---

Needs docs
Documentation/ABI/testing/sysfs-devices-system-cpu
seems to have the rest of the similar entries.

> Outstanding comment:
>  https://lore.kernel.org/r/20230914175443.000038f6 at Huawei.com
Very fussy reviewer. I'd ignore him on this :)

Code is fine.

Thanks for taking this forwards.  Maybe the end of this saga is
close!

Jonathan

> ---
>  drivers/base/cpu.c      | 10 ++++++++++
>  include/linux/cpumask.h | 25 +++++++++++++++++++++++++
>  kernel/cpu.c            |  3 +++
>  3 files changed, 38 insertions(+)
> 
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index 13d052bf13f4..a6e96a0a92b7 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -95,6 +95,7 @@ void unregister_cpu(struct cpu *cpu)
>  {
>  	int logical_cpu = cpu->dev.id;
>  
> +	set_cpu_enabled(logical_cpu, false);
>  	unregister_cpu_under_node(logical_cpu, cpu_to_node(logical_cpu));
>  
>  	device_unregister(&cpu->dev);
> @@ -273,6 +274,13 @@ static ssize_t print_cpus_offline(struct device *dev,
>  }
>  static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
>  
> +static ssize_t print_cpus_enabled(struct device *dev,
> +				  struct device_attribute *attr, char *buf)
> +{
> +	return sysfs_emit(buf, "%*pbl\n", cpumask_pr_args(cpu_enabled_mask));
> +}
> +static DEVICE_ATTR(enabled, 0444, print_cpus_enabled, NULL);
> +
>  static ssize_t print_cpus_isolated(struct device *dev,
>  				  struct device_attribute *attr, char *buf)
>  {
> @@ -413,6 +421,7 @@ int register_cpu(struct cpu *cpu, int num)
>  	register_cpu_under_node(num, cpu_to_node(num));
>  	dev_pm_qos_expose_latency_limit(&cpu->dev,
>  					PM_QOS_RESUME_LATENCY_NO_CONSTRAINT);
> +	set_cpu_enabled(num, true);
>  
>  	return 0;
>  }
> @@ -494,6 +503,7 @@ static struct attribute *cpu_root_attrs[] = {
>  	&cpu_attrs[2].attr.attr,
>  	&dev_attr_kernel_max.attr,
>  	&dev_attr_offline.attr,
> +	&dev_attr_enabled.attr,
>  	&dev_attr_isolated.attr,
>  #ifdef CONFIG_NO_HZ_FULL
>  	&dev_attr_nohz_full.attr,
> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
> index cfb545841a2c..cc72a0887f04 100644
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -92,6 +92,7 @@ static inline void set_nr_cpu_ids(unsigned int nr)
>   *
>   *     cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
>   *     cpu_present_mask - has bit 'cpu' set iff cpu is populated
> + *     cpu_enabled_mask  - has bit 'cpu' set iff cpu can be brought online
>   *     cpu_online_mask  - has bit 'cpu' set iff cpu available to scheduler
>   *     cpu_active_mask  - has bit 'cpu' set iff cpu available to migration
>   *
> @@ -124,11 +125,13 @@ static inline void set_nr_cpu_ids(unsigned int nr)
>  
>  extern struct cpumask __cpu_possible_mask;
>  extern struct cpumask __cpu_online_mask;
> +extern struct cpumask __cpu_enabled_mask;
>  extern struct cpumask __cpu_present_mask;
>  extern struct cpumask __cpu_active_mask;
>  extern struct cpumask __cpu_dying_mask;
>  #define cpu_possible_mask ((const struct cpumask *)&__cpu_possible_mask)
>  #define cpu_online_mask   ((const struct cpumask *)&__cpu_online_mask)
> +#define cpu_enabled_mask   ((const struct cpumask *)&__cpu_enabled_mask)
>  #define cpu_present_mask  ((const struct cpumask *)&__cpu_present_mask)
>  #define cpu_active_mask   ((const struct cpumask *)&__cpu_active_mask)
>  #define cpu_dying_mask    ((const struct cpumask *)&__cpu_dying_mask)
> @@ -993,6 +996,7 @@ extern const DECLARE_BITMAP(cpu_all_bits, NR_CPUS);
>  #else
>  #define for_each_possible_cpu(cpu) for_each_cpu((cpu), cpu_possible_mask)
>  #define for_each_online_cpu(cpu)   for_each_cpu((cpu), cpu_online_mask)
> +#define for_each_enabled_cpu(cpu)   for_each_cpu((cpu), cpu_enabled_mask)
>  #define for_each_present_cpu(cpu)  for_each_cpu((cpu), cpu_present_mask)
>  #endif
>  
> @@ -1015,6 +1019,15 @@ set_cpu_possible(unsigned int cpu, bool possible)
>  		cpumask_clear_cpu(cpu, &__cpu_possible_mask);
>  }
>  
> +static inline void
> +set_cpu_enabled(unsigned int cpu, bool can_be_onlined)
> +{
> +	if (can_be_onlined)
> +		cpumask_set_cpu(cpu, &__cpu_enabled_mask);
> +	else
> +		cpumask_clear_cpu(cpu, &__cpu_enabled_mask);
> +}
> +
>  static inline void
>  set_cpu_present(unsigned int cpu, bool present)
>  {
> @@ -1096,6 +1109,7 @@ static __always_inline unsigned int num_online_cpus(void)
>  	return raw_atomic_read(&__num_online_cpus);
>  }
>  #define num_possible_cpus()	cpumask_weight(cpu_possible_mask)
> +#define num_enabled_cpus()	cpumask_weight(cpu_enabled_mask)
>  #define num_present_cpus()	cpumask_weight(cpu_present_mask)
>  #define num_active_cpus()	cpumask_weight(cpu_active_mask)
>  
> @@ -1104,6 +1118,11 @@ static inline bool cpu_online(unsigned int cpu)
>  	return cpumask_test_cpu(cpu, cpu_online_mask);
>  }
>  
> +static inline bool cpu_enabled(unsigned int cpu)
> +{
> +	return cpumask_test_cpu(cpu, cpu_enabled_mask);
> +}
> +
>  static inline bool cpu_possible(unsigned int cpu)
>  {
>  	return cpumask_test_cpu(cpu, cpu_possible_mask);
> @@ -1128,6 +1147,7 @@ static inline bool cpu_dying(unsigned int cpu)
>  
>  #define num_online_cpus()	1U
>  #define num_possible_cpus()	1U
> +#define num_enabled_cpus()	1U
>  #define num_present_cpus()	1U
>  #define num_active_cpus()	1U
>  
> @@ -1141,6 +1161,11 @@ static inline bool cpu_possible(unsigned int cpu)
>  	return cpu == 0;
>  }
>  
> +static inline bool cpu_enabled(unsigned int cpu)
> +{
> +	return cpu == 0;
> +}
> +
>  static inline bool cpu_present(unsigned int cpu)
>  {
>  	return cpu == 0;
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index a86972a91991..fe0a5189f8ae 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -3122,6 +3122,9 @@ EXPORT_SYMBOL(__cpu_possible_mask);
>  struct cpumask __cpu_online_mask __read_mostly;
>  EXPORT_SYMBOL(__cpu_online_mask);
>  
> +struct cpumask __cpu_enabled_mask __read_mostly;
> +EXPORT_SYMBOL(__cpu_enabled_mask);
> +
>  struct cpumask __cpu_present_mask __read_mostly;
>  EXPORT_SYMBOL(__cpu_present_mask);
>  



From nm at ti.com  Fri Dec 15 09:20:26 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 15 Dec 2023 11:20:26 -0600
Subject: [PATCH v2 0/3] arm64: dts: ti: k3: Add additioal regs for DMA components
In-Reply-To: <20231213135138.929517-1-vigneshr@ti.com>
References: <20231213135138.929517-1-vigneshr@ti.com>
Message-ID: <170266081594.3490039.10351809799939114334.b4-ty@ti.com>

Hi Vignesh Raghavendra,

On Wed, 13 Dec 2023 19:21:35 +0530, Vignesh Raghavendra wrote:
> This adds additional reg ranges which are not directly used by Linux but
> by other components like U-Boot
> 
> Binding is accepted via dmaengine tree and is in linux-next[0]
> 
> [0] https://lore.kernel.org/dmaengine/170083278148.771517.1841889156174413563.b4-ty at kernel.org/
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/3] arm64: dts: ti: k3-am65: Add additional regs for DMA components
      commit: 0fa8d3a5eb8e737726a3c7376222ee40fae1988d
[2/3] arm64: dts: ti: k3-j7*: Add additional regs for DMA components
      commit: 1b62a3cfddbb5664bc4360b3cb0d76b9b99abdc5
[3/3] arm64: dts: ti: k3-am6*: Add additional regs for DMA components
      commit: 7643f7ebcbc723e682d22c207ac35b41d7248650

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From nm at ti.com  Fri Dec 15 09:21:09 2023
From: nm at ti.com (Nishanth Menon)
Date: Fri, 15 Dec 2023 11:21:09 -0600
Subject: [PATCH 0/3] arm64: dts: ti: Add Itap Delay Value For High Speed DDR
In-Reply-To: <20231201082045.790478-1-b-kapoor@ti.com>
References: <20231201082045.790478-1-b-kapoor@ti.com>
Message-ID: <170266085077.3490141.14935960940418963459.b4-ty@ti.com>

Hi Bhavya Kapoor,

On Fri, 01 Dec 2023 13:50:42 +0530, Bhavya Kapoor wrote:
> This Series adds Itap Delay Value for DDR52 speed mode for eMMC in
> J7200 and for DDR50 speed mode for MMCSD in J721s2 and J784s4 SoC.
> 
> Rebased to next-20231201
> 
> Bhavya Kapoor (3):
>   arm64: dts: ti: k3-j7200-main: Add Itap Delay Value For DDR52 speed
>     mode
>   arm64: dts: ti: k3-j721s2-main: Add Itap Delay Value For DDR50 speed
>     mode
>   arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed
>     mode
> 
> [...]

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/3] arm64: dts: ti: k3-j7200-main: Add Itap Delay Value For DDR52 speed mode
      commit: 908999561b4340089896b89cef51dae07fc001cb
[2/3] arm64: dts: ti: k3-j721s2-main: Add Itap Delay Value For DDR50 speed mode
      commit: 4a52a8208568a85b0d51e5ca81be5925973ef108
[3/3] arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed mode
      commit: 8bbe8a7dbaabb84d93321f116966af73ba6a7233

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From james.clark at arm.com  Fri Dec 15 09:42:50 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 17:42:50 +0000
Subject: [PATCH 1/2] arm: perf: Fix ARCH=arm build with GCC in
 armv8pmu_write_evtype()
In-Reply-To: <ZXx9GW1onSy4eBEB@FVFF77S0Q05N>
References: <20231215150040.3342183-1-james.clark@arm.com>
 <20231215150040.3342183-2-james.clark@arm.com>
 <ZXx9GW1onSy4eBEB@FVFF77S0Q05N>
Message-ID: <d335905e-38bb-1994-57f6-533852b7a560@arm.com>



On 15/12/2023 16:21, Mark Rutland wrote:
> On Fri, Dec 15, 2023 at 03:00:38PM +0000, James Clark wrote:
>> LLVM ignores everything inside the if statement and doesn't generate
>> errors, but GCC doesn't ignore it, resulting in the following error:
>>
>>   drivers/perf/arm_pmuv3.c: In function 'armv8pmu_write_evtype':
>>   include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
>>   	34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \
>>
>> Fix it by changing the if to #if.
> 
> I reckon it'd be cleaner to use GENMASK_ULL for the TH and TC fields, in
> include/linux/perf/arm_pmu.h have:
> 
> | /*
> |  * PMXEVTYPER: Event selection reg
> |  */
> | #define ARMV8_PMU_EVTYPE_EVENT GENMASK(15, 0)          /* Mask for EVENT bits */
> | #define ARMV8_PMU_EVTYPE_TH    GENMASK_ULL(43, 32)     /* arm64 only */
> | #define ARMV8_PMU_EVTYPE_TC    GENMASK_ULL(63, 61)     /* arm64 only */
> 
> IIUC that should silence this warning, and it'd remove the need for the
> ifdeffery and other changes in patch 2.
> 
> Does that work, or am I missing something?
> 
> Thanks,
> Mark.
> 

You're right that does work. For some reason I thought there was some
component of writing it to the mask that was the issue as well.

I'll send another version with that fix instead.

Thanks
James

>>
>> Fixes: 3115ee021bfb ("arm64: perf: Include threshold control fields in PMEVTYPER mask")
>> Reported-by: Uwe Kleine-K"onig <u.kleine-koenig at pengutronix.de>
>> Closes: https://lore.kernel.org/linux-arm-kernel/20231215120817.h2f3akgv72zhrtqo at pengutronix.de/
>> Signed-off-by: James Clark <james.clark at arm.com>
>> ---
>>  drivers/perf/arm_pmuv3.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
>> index 23fa6c5da82c..3ed2086cefc3 100644
>> --- a/drivers/perf/arm_pmuv3.c
>> +++ b/drivers/perf/arm_pmuv3.c
>> @@ -631,8 +631,9 @@ static void armv8pmu_write_evtype(int idx, unsigned long val)
>>  			     ARMV8_PMU_EXCLUDE_EL0 |
>>  			     ARMV8_PMU_EXCLUDE_EL1;
>>  
>> -	if (IS_ENABLED(CONFIG_ARM64))
>> -		mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
>> +#if IS_ENABLED(CONFIG_ARM64)
>> +	mask |= ARMV8_PMU_EVTYPE_TC | ARMV8_PMU_EVTYPE_TH;
>> +#endif
>>  
>>  	val &= mask;
>>  	write_pmevtypern(counter, val);
>> -- 
>> 2.34.1
>>


From sjg at chromium.org  Fri Dec 15 09:49:00 2023
From: sjg at chromium.org (Simon Glass)
Date: Fri, 15 Dec 2023 10:49:00 -0700
Subject: [PATCH] arm64: properly install vmlinuz.efi
In-Reply-To: <20231215142520.GA683314@perftesting>
References: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>
 <CAPnjgZ1ePt1zoPc4NvbHXkgKdG0MQZL2pYArBvCVaNgCqXaEqA@mail.gmail.com> <20231215142520.GA683314@perftesting>
Message-ID: <CAPnjgZ3ffeVLdr=ZnWDhvZaoH4jyjZDHgTi49yx6XsFGXiKQpg@mail.gmail.com>

Hi Josef,

On Fri, 15 Dec 2023 at 07:25, Josef Bacik <josef at toxicpanda.com> wrote:
>
> On Thu, Dec 14, 2023 at 01:12:13PM -0700, Simon Glass wrote:
> > Hi Josef,
> >
> > On Thu, 14 Dec 2023 at 09:19, Josef Bacik <josef at toxicpanda.com> wrote:
> > >
> > > If you select CONFIG_EFI_ZBOOT, we will generate vmlinuz.efi, and then
> > > when we go to install the kernel we'll install the vmlinux instead
> > > because install.sh only recognizes Image.gz as wanting the compressed
> > > install image.  With CONFIG_EFI_ZBOOT we don't get the proper kernel
> > > installed, which means it doesn't boot, which makes for a very confused
> > > and subsequently angry kernel developer.
> > >
> > > Fix this by properly installing our compressed kernel if we've enabled
> > > CONFIG_EFI_ZBOOT.
> > >
> > > Signed-off-by: Josef Bacik <josef at toxicpanda.com>
> > > ---
> > >  arch/arm64/boot/install.sh | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
> > > index 7399d706967a..9b7a09808a3d 100755
> > > --- a/arch/arm64/boot/install.sh
> > > +++ b/arch/arm64/boot/install.sh
> > > @@ -17,7 +17,8 @@
> > >  #   $3 - kernel map file
> > >  #   $4 - default install path (blank if root directory)
> > >
> > > -if [ "$(basename $2)" = "Image.gz" ]; then
> > > +if [ "$(basename $2)" = "Image.gz" ] || [ "$(basename $2)" = "vmlinuz.efi" ]
> > > +then
> > >  # Compressed install
> > >    echo "Installing compressed kernel"
> > >    base=vmlinuz
> >
> > This is a little messy.
> >
> > There is a KBUILD_IMAGE var which should be usable, although I see
> > that it is set to $(boot)/Image when 'make install' is invoked.
>
> Yeah, which is another pain point for me, because really what normal people want
> to use is 'make zinstall', and that's not obvious anywhere and is a pretty
> drastic departure from literally any other arch.
>
> >
> > Could we perhaps make sure that this var is set to the file to be installed?
> >
> > I also wonder how useful it is to indicate whether the image is
> > compressed or not, so perhaps we could just say 'Installing kernel' ?
> >
>
> I have no strong opinions here, I'm reticent to be messing with an install
> script for an arch I don't maintain.  I need this change to be able to do
> aarch64 testing in a VM, and honestly I'm sort of surprised I'm the first person
> to run into this since the default stuff straight up doesn't work at all when it
> does for other archs.  Thanks,

OK, well I don't plan to dig into either, and it fixes what seems to be a bug.

Reviewed-by: Simon Glass <sjg at chromium.org>

Regards,
Simon


From gustavo at embeddedor.com  Fri Dec 15 09:49:07 2023
From: gustavo at embeddedor.com (Gustavo A. R. Silva)
Date: Fri, 15 Dec 2023 11:49:07 -0600
Subject: [PATCH v2][wireless-next/for-next] wifi: mt76: mt7996: Use
 DECLARE_FLEX_ARRAY() and fix -Warray-bounds warnings
In-Reply-To: <170264697580.1759617.6397953788753678096.kvalo@kernel.org>
References: <ZXiU9ayVCslt3qiI@work>
 <170264697580.1759617.6397953788753678096.kvalo@kernel.org>
Message-ID: <6681b643-464d-44d9-b01a-420e543d19d6@embeddedor.com>



On 12/15/23 07:29, Kalle Valo wrote:
> "Gustavo A. R. Silva" <gustavoars at kernel.org> wrote:
> 
>> Transform zero-length arrays `rate`, `adm_stat` and `msdu_cnt` into
>> proper flexible-array members in anonymous union in `struct
>> mt7996_mcu_all_sta_info_event` via the DECLARE_FLEX_ARRAY()
>> helper; and fix multiple -Warray-bounds warnings:

[..]

>>
>> This results in no differences in binary output, helps with the ongoing
>> efforts to globally enable -Warray-bounds.
>>
>> Reviewed-by: Kees Cook <keescook at chromium.org>
>> Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org>
> 
> I'll take this directly wireless-next, ok?
> 

Yep, sounds good.

Thanks!
--
Gustavo


From james.clark at arm.com  Fri Dec 15 09:56:47 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 17:56:47 +0000
Subject: [PATCH v2 0/1] arm: perf: Fix ARCH=arm build with GCC
Message-ID: <20231215175648.3397170-1-james.clark@arm.com>

Changes since V1:

  * Instead of wrapping everything in #if, just use GENMASK_ULL instead
    which fixes both issues in one commit.

A fix for the broken build with GCC currently in linux-next
(next-20231214)


James Clark (1):
  arm: perf: Fix ARCH=arm build with GCC

 include/linux/perf/arm_pmuv3.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.34.1



From james.clark at arm.com  Fri Dec 15 09:56:48 2023
From: james.clark at arm.com (James Clark)
Date: Fri, 15 Dec 2023 17:56:48 +0000
Subject: [PATCH v2 1/1] arm: perf: Fix ARCH=arm build with GCC
In-Reply-To: <20231215175648.3397170-1-james.clark@arm.com>
References: <20231215175648.3397170-1-james.clark@arm.com>
Message-ID: <20231215175648.3397170-2-james.clark@arm.com>

LLVM ignores everything inside the if statement and doesn't generate
errors, but GCC doesn't ignore it, resulting in the following error:

  drivers/perf/arm_pmuv3.c: In function ?armv8pmu_write_evtype?:
  include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
  34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \

Fix it by using GENMASK_ULL which doesn't overflow on arm32 (even though
the value is never used there).

Fixes: 3115ee021bfb ("arm64: perf: Include threshold control fields in PMEVTYPER mask")
Reported-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Closes: https://lore.kernel.org/linux-arm-kernel/20231215120817.h2f3akgv72zhrtqo at pengutronix.de/
Signed-off-by: James Clark <james.clark at arm.com>
---
 include/linux/perf/arm_pmuv3.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
index 0f4d62ef3a9a..46377e134d67 100644
--- a/include/linux/perf/arm_pmuv3.h
+++ b/include/linux/perf/arm_pmuv3.h
@@ -234,8 +234,8 @@
  * PMXEVTYPER: Event selection reg
  */
 #define ARMV8_PMU_EVTYPE_EVENT	GENMASK(15, 0)	/* Mask for EVENT bits */
-#define ARMV8_PMU_EVTYPE_TH	GENMASK(43, 32)
-#define ARMV8_PMU_EVTYPE_TC	GENMASK(63, 61)
+#define ARMV8_PMU_EVTYPE_TH	GENMASK_ULL(43, 32) /* arm64 only */
+#define ARMV8_PMU_EVTYPE_TC	GENMASK_ULL(63, 61) /* arm64 only */
 
 /*
  * Event filters for PMUv3
-- 
2.34.1



From dsimic at manjaro.org  Fri Dec 15 10:15:05 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Fri, 15 Dec 2023 19:15:05 +0100
Subject: [PATCH] arm64: dts: rockchip: Increase maximum frequency of SPI
 flash for ROCK Pi 4A/B/C
In-Reply-To: <20231215122848.59534-1-stefan.nagy@ixypsilon.net>
References: <20231215122848.59534-1-stefan.nagy@ixypsilon.net>
Message-ID: <33e632c38fa57053585c0016652ed8c8@manjaro.org>

On 2023-12-15 13:28, Stefan Nagy wrote:
> The ROCK Pi 4A/B/C boards come with a 32 Mbit SPI NOR flash chip (XTX
> Technology Limited XT25F32) which has a maximum clock frequency of 108
> MHz. However, the Rockchip SPI controller driver limits the maximum
> SPI clock frequency to 50 MHz. Use this limit for spi-max-freq.
> 
> This patch has been tested on ROCK Pi 4A.
> 
> Signed-off-by: Stefan Nagy <stefan.nagy at ixypsilon.net>
> ---
>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts | 2 +-
>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts | 2 +-
>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> index d5df8939a..30e63e62a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> @@ -19,6 +19,6 @@ &spi1 {
>  	flash at 0 {
>  		compatible = "jedec,spi-nor";
>  		reg = <0>;
> -		spi-max-frequency = <10000000>;
> +		spi-max-frequency = <50000000>;
>  	};
>  };
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> index bee6d7588..7122bf6c0 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> @@ -37,7 +37,7 @@ &spi1 {
>  	flash at 0 {
>  		compatible = "jedec,spi-nor";
>  		reg = <0>;
> -		spi-max-frequency = <10000000>;
> +		spi-max-frequency = <50000000>;
>  	};
>  };
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> index de2ebe4cb..8af75bc7c 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> @@ -49,7 +49,7 @@ &spi1 {
>  	flash at 0 {
>  		compatible = "jedec,spi-nor";
>  		reg = <0>;
> -		spi-max-frequency = <10000000>;
> +		spi-max-frequency = <50000000>;
>  	};
>  };

It would be better to upstream these changes to the Linux kernel first, 
and then sync them back to U-Boot.


From u.kleine-koenig at pengutronix.de  Fri Dec 15 10:20:32 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 19:20:32 +0100
Subject: [PATCH v2 1/1] arm: perf: Fix ARCH=arm build with GCC
In-Reply-To: <20231215175648.3397170-2-james.clark@arm.com>
References: <20231215175648.3397170-1-james.clark@arm.com>
 <20231215175648.3397170-2-james.clark@arm.com>
Message-ID: <20231215182032.yainbyffntkqpkye@pengutronix.de>

On Fri, Dec 15, 2023 at 05:56:48PM +0000, James Clark wrote:
> LLVM ignores everything inside the if statement and doesn't generate
> errors, but GCC doesn't ignore it, resulting in the following error:
> 
>   drivers/perf/arm_pmuv3.c: In function ?armv8pmu_write_evtype?:
>   include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
>   34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \
> 
> Fix it by using GENMASK_ULL which doesn't overflow on arm32 (even though
> the value is never used there).
> 
> Fixes: 3115ee021bfb ("arm64: perf: Include threshold control fields in PMEVTYPER mask")
> Reported-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> Closes: https://lore.kernel.org/linux-arm-kernel/20231215120817.h2f3akgv72zhrtqo at pengutronix.de/
> Signed-off-by: James Clark <james.clark at arm.com>
> ---
>  include/linux/perf/arm_pmuv3.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
> index 0f4d62ef3a9a..46377e134d67 100644
> --- a/include/linux/perf/arm_pmuv3.h
> +++ b/include/linux/perf/arm_pmuv3.h
> @@ -234,8 +234,8 @@
>   * PMXEVTYPER: Event selection reg
>   */
>  #define ARMV8_PMU_EVTYPE_EVENT	GENMASK(15, 0)	/* Mask for EVENT bits */
> -#define ARMV8_PMU_EVTYPE_TH	GENMASK(43, 32)
> -#define ARMV8_PMU_EVTYPE_TC	GENMASK(63, 61)
> +#define ARMV8_PMU_EVTYPE_TH	GENMASK_ULL(43, 32) /* arm64 only */
> +#define ARMV8_PMU_EVTYPE_TC	GENMASK_ULL(63, 61) /* arm64 only */

As expected this fixes compilation on my end, too and it's nicer than
v1.

Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/4d68e786/attachment.sig>

From dsimic at manjaro.org  Fri Dec 15 10:20:51 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Fri, 15 Dec 2023 19:20:51 +0100
Subject: [PATCH] arm64: dts: rockchip: Increase maximum frequency of SPI
 flash for ROCK Pi 4A/B/C
In-Reply-To: <33e632c38fa57053585c0016652ed8c8@manjaro.org>
References: <20231215122848.59534-1-stefan.nagy@ixypsilon.net>
 <33e632c38fa57053585c0016652ed8c8@manjaro.org>
Message-ID: <4fce0de996d6cc3056d972cd3fc3fb93@manjaro.org>

On 2023-12-15 19:15, Dragan Simic wrote:
> On 2023-12-15 13:28, Stefan Nagy wrote:
>> The ROCK Pi 4A/B/C boards come with a 32 Mbit SPI NOR flash chip (XTX
>> Technology Limited XT25F32) which has a maximum clock frequency of 108
>> MHz. However, the Rockchip SPI controller driver limits the maximum
>> SPI clock frequency to 50 MHz. Use this limit for spi-max-freq.
>> 
>> This patch has been tested on ROCK Pi 4A.
>> 
>> Signed-off-by: Stefan Nagy <stefan.nagy at ixypsilon.net>
>> ---
>>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts | 2 +-
>>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts | 2 +-
>>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts | 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
>> b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
>> index d5df8939a..30e63e62a 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
>> @@ -19,6 +19,6 @@ &spi1 {
>>  	flash at 0 {
>>  		compatible = "jedec,spi-nor";
>>  		reg = <0>;
>> -		spi-max-frequency = <10000000>;
>> +		spi-max-frequency = <50000000>;
>>  	};
>>  };
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
>> b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
>> index bee6d7588..7122bf6c0 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
>> @@ -37,7 +37,7 @@ &spi1 {
>>  	flash at 0 {
>>  		compatible = "jedec,spi-nor";
>>  		reg = <0>;
>> -		spi-max-frequency = <10000000>;
>> +		spi-max-frequency = <50000000>;
>>  	};
>>  };
>> 
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
>> b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
>> index de2ebe4cb..8af75bc7c 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
>> @@ -49,7 +49,7 @@ &spi1 {
>>  	flash at 0 {
>>  		compatible = "jedec,spi-nor";
>>  		reg = <0>;
>> -		spi-max-frequency = <10000000>;
>> +		spi-max-frequency = <50000000>;
>>  	};
>>  };
> 
> It would be better to upstream these changes to the Linux kernel
> first, and then sync them back to U-Boot.

Oops, my bad, sorry, I got confused with your other patch on the U-Boot 
mailing list.

Regarding the new spi-max-frequency value, it should be better to have 
it set to what the SPI chip actually supports, and let the SPI driver do 
its thing.


From alain.volmat at foss.st.com  Fri Dec 15 10:27:39 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 15 Dec 2023 19:27:39 +0100
Subject: [PATCH] spi: stm32: use runtime PM to enable/disable controller
In-Reply-To: <58897511-3187-4583-bf29-11871dd4d136@sirena.org.uk>
References: <20231204202055.2895125-1-ben.wolsieffer@hefring.com>
 <58897511-3187-4583-bf29-11871dd4d136@sirena.org.uk>
Message-ID: <20231215182739.GA96945@gnbcxd0016.gnb.st.com>

Hi,

sorry for the delay.

On Thu, Dec 14, 2023 at 10:58:54AM +0000, Mark Brown wrote:
> On Mon, Dec 04, 2023 at 03:20:55PM -0500, Ben Wolsieffer wrote:
> > Instead of disabling the SPI controller between each message, do it
> > as part of runtime PM.
> 
> This doesn't apply against current code, please check and resend.

I rapidly gave a try on this patch on top of the spi/for-next branch
(manually fixing the conflict due to the MASTER->HOST renaming).
It turns out that with that applied, transfers on the MP13
(compatible: st,stm32h7-spi) are not working anymore while simply
removing it back it works again.
(test is simply doing loopback spidev_test)

spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 kHz)
TX | 8D D6 73 8B 9D 8B 1C 7D 8D 80 EC 32 F9 0D BA AD 9F 88 A5 9B 3F AA 48 8C 21 35 0D C1 C8 E5 6A 81  |..s....}...2........?.H.!5....j.|
RX | 8D 00 00 00 D6 00 73 00 8B 00 00 00 9D 00 00 8B 1C 00 00 00 7D 00 00 8D F9 00 00 00 BA 00 00 00  |......s.............}...........|

The RX data contains lots of 00 between each byte.  Moreover it seems
that with this patch applied non-dma transfer (when there is no dmas
properties within the node) are now failing.

I'll check that and give more details but could you avoid applying this
patch for the time being ?

Thanks.
Alain


From lkp at intel.com  Fri Dec 15 10:39:00 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 16 Dec 2023 02:39:00 +0800
Subject: [PATCH net-next v3 5/8] net: qualcomm: ipqess: add bridge
 offloading features to the IPQESS driver
In-Reply-To: <20231114105600.1012056-6-romain.gantois@bootlin.com>
References: <20231114105600.1012056-6-romain.gantois@bootlin.com>
Message-ID: <202312160211.TqddYea8-lkp@intel.com>

Hi Romain,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Romain-Gantois/dt-bindings-net-Introduce-the-Qualcomm-IPQESS-Ethernet-switch/20231114-185953
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231114105600.1012056-6-romain.gantois%40bootlin.com
patch subject: [PATCH net-next v3 5/8] net: qualcomm: ipqess: add bridge offloading features to the IPQESS driver
config: arc-randconfig-r112-20231116 (https://download.01.org/0day-ci/archive/20231216/202312160211.TqddYea8-lkp at intel.com/config)
compiler: arc-elf-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231216/202312160211.TqddYea8-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312160211.TqddYea8-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/net/dsa/qca/qca8k-8xxx.c:1982:5: sparse: sparse: symbol 'qca8k_dsa_port_fdb_dump' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:1988:6: sparse: sparse: symbol 'qca8k_dsa_port_stp_state_set' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:1995:6: sparse: sparse: symbol 'qca8k_dsa_port_fast_age' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2000:5: sparse: sparse: symbol 'qca8k_dsa_set_ageing_time' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2005:5: sparse: sparse: symbol 'qca8k_dsa_port_vlan_filtering' was not declared. Should it be static?
>> drivers/net/dsa/qca/qca8k-8xxx.c:2012:5: sparse: sparse: symbol 'qca8k_dsa_vlan_add' was not declared. Should it be static?

vim +/qca8k_dsa_port_fdb_dump +1982 drivers/net/dsa/qca/qca8k-8xxx.c

  1981	
> 1982	int qca8k_dsa_port_fdb_dump(struct dsa_switch *ds, int port,
  1983				    dsa_fdb_dump_cb_t *cb, void *data)
  1984	{
  1985		return qca8k_port_fdb_dump(ds->priv, port, cb, data);
  1986	}
  1987	
> 1988	void qca8k_dsa_port_stp_state_set(struct dsa_switch *ds, int port,
  1989					  u8 state)
  1990	{
  1991		qca8k_port_stp_state_set(ds->priv, port, state,
  1992					 dsa_to_port(ds, port)->learning, true);
  1993	}
  1994	
> 1995	void qca8k_dsa_port_fast_age(struct dsa_switch *ds, int port)
  1996	{
  1997		qca8k_port_fast_age(ds->priv, port);
  1998	}
  1999	
> 2000	int qca8k_dsa_set_ageing_time(struct dsa_switch *ds, unsigned int msecs)
  2001	{
  2002		return qca8k_set_ageing_time(ds->priv, msecs);
  2003	}
  2004	
> 2005	int qca8k_dsa_port_vlan_filtering(struct dsa_switch *ds, int port,
  2006					  bool vlan_filtering,
  2007					  struct netlink_ext_ack *extack)
  2008	{
  2009		return qca8k_port_vlan_filtering(ds->priv, port, vlan_filtering);
  2010	}
  2011	
> 2012	int qca8k_dsa_vlan_add(struct dsa_switch *ds, int port,
  2013			       const struct switchdev_obj_port_vlan *vlan,
  2014			       struct netlink_ext_ack *extack)
  2015	{
  2016		return qca8k_port_vlan_add(ds->priv, port, vlan, extack);
  2017	}
  2018	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From robin.murphy at arm.com  Fri Dec 15 10:39:39 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 15 Dec 2023 18:39:39 +0000
Subject: [PATCH v2 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <8f583a00-8e9c-4875-936c-ed196d1dae56@linaro.org>
References: <cover.1702571292.git.robin.murphy@arm.com>
 <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
 <8f583a00-8e9c-4875-936c-ed196d1dae56@linaro.org>
Message-ID: <2b8414e5-61d5-4c3e-9613-6d9487ae84a8@arm.com>

On 15/12/2023 9:44 am, Krzysztof Kozlowski wrote:
> On 14/12/2023 17:31, Robin Murphy wrote:
>> +
>> +  reg:
>> +    items:
>> +      - description: Register page 0
>> +      - description: Register page 1, if the PMU implements the dual-page extension
>> +    minItems: 1
>> +
>> +  interrupts:
>> +    items:
>> +      - description: Overflow interrupt
>> +
>> +  cpus:
>> +    description: If the PMU is associated with a particular CPU or subset of CPUs, array of phandles to those CPUs
>> +
>> +  reg-io-width:
>> +    description: Granularity at which PMU register accesses are single-copy atomic
>> +    default: 4
>> +    enum: [4, 8]
>> +
>> +
> 
> If there is going to be new posting: just one blank line

Ack, I've fixed that up locally along with the linewrap (since Will's 
already winding down for holidays, I'm assuming I'll resend this for 6.9 
in the new year now).

>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +additionalProperties: false
> 
> Why no example to validate the binding?

IMO for such a trivial binding built out of common properties, an 
equally trivial example isn't going to add any value, since it won't do 
anything more than re-state the individual property definitions above. 
In bindings where we have conditional relationships between properties, 
or complex encodings where a practical example can help explain a 
definition (e.g. a map/mask pair for a set of input values), then 
absolutely, an example can add something more to help the author and/or 
users. But otherwise, the thing I've really grown to like about schema 
is how thoroughly self-describing the definitions themselves can now be.

Thanks,
Robin.


From u.kleine-koenig at pengutronix.de  Fri Dec 15 10:49:26 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 15 Dec 2023 19:49:26 +0100
Subject: [PATCH 0/5] clk: Make clk_rate_exclusive_get() return void
In-Reply-To: <20231215151547.y23fgs6hskng5izg@pengutronix.de>
References: <cover.1702400947.git.u.kleine-koenig@pengutronix.de>
 <ki5n3rz5n4oxj2hhc3rj6xpn3e2tdi7fcp2q7exjbzilrlqflp@przautvhuy4g>
 <20231213074300.4bq7wkfqd4jhhcr4@pengutronix.de>
 <2nvbag657mlniqwq7fbilapc6vfw5qumab3yd6bqul25ot6wcn@wdlkh5az2fgs>
 <20231213110829.bjaxjjiyy4ug7o67@pengutronix.de>
 <6wnsxbi27xdxjtaqaaaq5wtwwilp4jfw4mg5y2ctdl7xrs44ry@ns6y36pf7hge>
 <20231213155252.eq6cdzk2vuwllzdu@pengutronix.de>
 <nsa54fwu4ewmcaehesuqefoo5r7z3tuvj76hjb4ngtkaygxwxx@h73ihjon5gby>
 <20231215151547.y23fgs6hskng5izg@pengutronix.de>
Message-ID: <20231215184926.6l4otbltfxzwy3ep@pengutronix.de>

Hello again,

On Fri, Dec 15, 2023 at 04:15:47PM +0100, Uwe Kleine-K?nig wrote:
> On Fri, Dec 15, 2023 at 01:34:26PM +0100, Maxime Ripard wrote:
> > On Wed, Dec 13, 2023 at 04:52:52PM +0100, Uwe Kleine-K?nig wrote:
> > > On Wed, Dec 13, 2023 at 12:54:14PM +0100, Maxime Ripard wrote:
> > > > On Wed, Dec 13, 2023 at 12:08:29PM +0100, Uwe Kleine-K?nig wrote:
> > > > > On Wed, Dec 13, 2023 at 09:36:49AM +0100, Maxime Ripard wrote:
> > > > > > On Wed, Dec 13, 2023 at 08:43:00AM +0100, Uwe Kleine-K?nig wrote:
> > > > > > > On Wed, Dec 13, 2023 at 08:16:04AM +0100, Maxime Ripard wrote:
> > > > > > > > On Tue, Dec 12, 2023 at 06:26:37PM +0100, Uwe Kleine-K?nig wrote:
> > > > > > > > > clk_rate_exclusive_get() returns zero unconditionally. Most users "know"
> > > > > > > > > that and don't check the return value. This series fixes the four users
> > > > > > > > > that do error checking on the returned value and then makes function
> > > > > > > > > return void.
> > > > > > > > > 
> > > > > > > > > Given that the changes to the drivers are simple and so merge conflicts
> > > > > > > > > (if any) should be easy to handle, I suggest to merge this complete
> > > > > > > > > series via the clk tree.
> > > > > > > > 
> > > > > > > > I don't think it's the right way to go about it.
> > > > > > > > 
> > > > > > > > clk_rate_exclusive_get() should be expected to fail. For example if
> > > > > > > > there's another user getting an exclusive rate on the same clock.
> > > > > > > > 
> > > > > > > > If we're not checking for it right now, then it should probably be
> > > > > > > > fixed, but the callers checking for the error are right to do so if they
> > > > > > > > rely on an exclusive rate. It's the ones that don't that should be
> > > > > > > > modified.
> > > > > > > 
> > > > > > > If some other consumer has already "locked" a clock that I call
> > > > > > > clk_rate_exclusive_get() for, this isn't an error. In my bubble I call
> > > > > > > this function because I don't want the rate to change e.g. because I
> > > > > > > setup some registers in the consuming device to provide a fixed UART
> > > > > > > baud rate or i2c bus frequency (and that works as expected).
> > > > > > 
> > > > > > [a long text of mostly right things (Uwe's interpretation) that are
> > > > > > however totally unrelated to the patches under discussion.]
> > > > 
> > > > I'm glad you consider it "mostly" right.
> > > 
> > > there was no offense intended. I didn't agree to all points, but didn't
> > > think it was helpful to discuss that given that I considered them
> > > orthogonal to my suggested modifications.
> > >  
> > > > > The clk API works with and without my patches in exactly the same way.
> > > > > It just makes more explicit that clk_rate_exclusive_get() cannot fail
> > > > > today and removes the error handling from consumers that is never used.
> > > > 
> > > > Not really, no.
> > > 
> > > What exactly do you oppose here? Both of my sentences are correct?!
> > 
> > That the API works in the exact same way.
> 
> Yeah ok, if you call clk_rate_exclusive_get() and want to check the
> return code you always got 0 before and now you get a compiler error. So
> there is a difference. What I meant is: Calling clk_rate_exclusive_get()
> with my patches has the exact same effects as before (apart from setting
> the register used to transport the return value to zero).
>  
> > > > Can you fail to get the exclusivity? Yes. On a theoretical basis, you
> > > > can, and the function was explicitly documented as such.
> > > 
> > > Sure, you could modify the clk internals such that
> > > clk_rate_exclusive_get() needs to allocate memory. Or that it fails if
> > > another consumer already has called it. At least the latter is a change
> > > in semantics that requires to review (and maybe fix) all users. Also
> > > note that calling clk_rate_exclusive_get() essentially locks all parent
> > > clocks up to the root clock. So if clk_rate_exclusive_get() fails in the
> > > presence of another locker, you can only have one locker per clock
> > > hierarchy because it's impossible that both grab the lock on the root
> > > clock.
> > 
> > We're not discussing the same thing. You're talking about from a
> > technical point of view, I'm talking about it from an abstraction point
> > of view.
> 
> In your abstract argumentation clk_rate_exclusive_get() has a
> different and stronger semantic than it has today. This stronger
> semantic indeed will make this function not succeed in every case. It
> should return an error indication and users should check it.
> 
> But as your clk_rate_exclusive_get() is a different function than
> today's clk_rate_exclusive_get(), I still think our argument isn't
> helpful. I want to do something with apples and you're arguing against
> that by only talking about oranges.
> 
> > Let's use another example: kmalloc cannot fail.
> 
> Oh really?
> 
> ... [a few greps later] ...
> 
> While the memory allocation stuff is sufficiently complex that I don't
> claim to have grokked it, I think it can (and should) fail. Either I
> missed something, or I just burned some more time to convince myself
> that kmalloc is just another orange :-\

A colleague pointed me to https://lwn.net/Articles/627419/ which
suggests that indeed kmalloc doesn't fail in most situations. The
relevant difference to the clk_rate_exclusive_get() function is that
making kmalloc fail would result in a better (more robust) kernel. And
so I'm on your side that removing error codes probably isn't a smart
move even if probably nobody will tackle the obvious improvement to
kmalloc any time soon.

If I understand your plans correctly, you intend to introduce a "give me
exclusive control over the clk rate" function (let's call it
clk_rate_lock_maxime() just to have a name for it). You would implement
clk_rate_lock_maxime() in a way that it would fail for a second caller,
right? And that's because the second caller wouldn't be able to call
clk_set_rate() and/or it would stop the first caller from being able to
change the rate. (Which one? Both?)

What if a consumer installed a clock notifier that refuses any rate
change. Would calling clk_rate_lock_maxime() by another consumer fail?
A "yes" would be hard to implement, because you cannot reliably see for
a given installed notifier if it refuses changing the clock. A "no"
would be inconsistent, because the holder of clk_rate_lock_maxime()
cannot change the rate then.

After that destructive excursion, let me try being more constructive:

Would you consider renaming clk_rate_exclusive_get() to clk_rate_lock()
an improvement? Maybe also make the clk rate readonly for the caller
then. (I wouldn't require that, but a colleague argued that would make
the semantic of that function simpler.) As in my use case I don't want
to modify the clock, that's good enough for me. Also that function can
be implemented in a way that never fails, so it could return void.

Is that a compromise that you would agree on?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231215/f4a6fe2a/attachment.sig>

From aford173 at gmail.com  Fri Dec 15 11:01:39 2023
From: aford173 at gmail.com (Adam Ford)
Date: Fri, 15 Dec 2023 13:01:39 -0600
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <CAOMZO5AGAkPpds=5H-iQj53djcQtW5GsRQrzdC_JOOrcENhvvw@mail.gmail.com>
References: <20230920171009.3193296-1-l.stach@pengutronix.de>
 <20230920171009.3193296-2-l.stach@pengutronix.de> <20230920205736.GB7723@pendragon.ideasonboard.com>
 <CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>
 <CAOMZO5C7_Rj-Ja0BO0D0Po+gy+XbvyMdQf-wH5YNyhAdMof2vg@mail.gmail.com>
 <20231215142308.GL21146@pendragon.ideasonboard.com> <CAHCN7xJPg_Nk=o9fKwkZfVTNSB-YL0m7vY6p1O7+i=PHShp7hg@mail.gmail.com>
 <CAOMZO5AGAkPpds=5H-iQj53djcQtW5GsRQrzdC_JOOrcENhvvw@mail.gmail.com>
Message-ID: <CAHCN7xLHMGcS2-QTneqqpHYU66JwuEG4TyR0j0riFGqO6RC8ug@mail.gmail.com>

On Fri, Dec 15, 2023 at 10:47?AM Fabio Estevam <festevam at gmail.com> wrote:
>
> Hi Adam,
>
> On Fri, Dec 15, 2023 at 1:40?PM Adam Ford <aford173 at gmail.com> wrote:
>
> > I started looking into this today, but there appears to be some
> > dependencies missing because the PVI is just one small portion of
> > this. The PVI needs to interact with the hdmi_blk_ctrl and the hdmi
> > transmitter itself.
> >
> > It looks like there was at least one attempt to push the hdmi driver,
> > but we're also missing some hdmi power domain information, and the dri
> > patchwork lists a bunch of proposed patches for the lcdif driver.  I
> > haven't looked through them all, so I don't know if they are
> > necessary.  I found a git repo with Lucas' stuff, but it's based on
> > the 6.0 kernel, so it's fairly old.  Either way it seems like there is
> > more to the HDMI than just his one series.
>
> Here is the whole patchset that I tested against 6.6:
>
> https://patchwork.freedesktop.org/patch/485391/
> https://patchwork.freedesktop.org/patch/485392/
> https://patchwork.freedesktop.org/patch/485395/
> https://patchwork.freedesktop.org/patch/515299/
> https://patchwork.freedesktop.org/patch/515300/
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220406153402.1265474-12-l.stach at pengutronix.de/

Thanks for the list.  I was able to successfully build the stable 6.6
branch with those patches applied and I have the HDMI working.
Unfortunately, I get build errors on the linux-next, so it's going to
take me a little time to sort through all of this.

I am thinking that it would be better to consolidate all these
together into one series instead of piecemealing it.  However, there
are some items that can be submitted right away without significantly
reworking them against linux-next.  Do people have a preference?

adam


adam


From nmorrisson at phytec.com  Fri Dec 15 11:18:37 2023
From: nmorrisson at phytec.com (Nathan Morrisson)
Date: Fri, 15 Dec 2023 11:18:37 -0800
Subject: [PATCH 1/2] arm64: dts: ti: k3-am62-phycore-som: Add fixed-partitions to NOR Flash
In-Reply-To: <20231215191838.1925082-1-nmorrisson@phytec.com>
References: <20231215191838.1925082-1-nmorrisson@phytec.com>
Message-ID: <20231215191838.1925082-2-nmorrisson@phytec.com>

Provide a fixed-partitions dummy node so bootladers can fixup
paritions.

Signed-off-by: Nathan Morrisson <nmorrisson at phytec.com>
---
 arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi
index aa43e7407eee..681ac03cef40 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi
@@ -311,6 +311,12 @@ serial_flash: flash at 0 {
 		cdns,tchsh-ns = <60>;
 		cdns,tslch-ns = <60>;
 		cdns,read-delay = <0>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+		};
 	};
 };
 
-- 
2.25.1



From nmorrisson at phytec.com  Fri Dec 15 11:18:36 2023
From: nmorrisson at phytec.com (Nathan Morrisson)
Date: Fri, 15 Dec 2023 11:18:36 -0800
Subject: [PATCH 0/2] *** Add fixed-paritions to phyCORE-AM62x and phyCORE-AM64x ***
Message-ID: <20231215191838.1925082-1-nmorrisson@phytec.com>

Add a fixed-partitions node to the NOR flash of the phyCORE-AM62x
and phyCORE-AM64x to enable the bootloader to fixup the partitions
during boot.

Nathan Morrisson (2):
  arm64: dts: ti: k3-am62-phycore-som: Add fixed-partitions to NOR Flash
  arm64: dts: ti: k3-am64-phycore-som: Add fixed-partitions to NOR Flash

 arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi | 6 ++++++
 arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi | 6 ++++++
 2 files changed, 12 insertions(+)

-- 
2.25.1



From nmorrisson at phytec.com  Fri Dec 15 11:18:38 2023
From: nmorrisson at phytec.com (Nathan Morrisson)
Date: Fri, 15 Dec 2023 11:18:38 -0800
Subject: [PATCH 2/2] arm64: dts: ti: k3-am64-phycore-som: Add fixed-partitions to NOR Flash
In-Reply-To: <20231215191838.1925082-1-nmorrisson@phytec.com>
References: <20231215191838.1925082-1-nmorrisson@phytec.com>
Message-ID: <20231215191838.1925082-3-nmorrisson@phytec.com>

Provide a fixed-partitions dummy node so bootladers can fixup
paritions.

Signed-off-by: Nathan Morrisson <nmorrisson at phytec.com>
---
 arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
index f87f09d83c95..a25ff4cf9373 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi
@@ -207,6 +207,12 @@ flash at 0 {
 		cdns,tchsh-ns = <60>;
 		cdns,tslch-ns = <60>;
 		cdns,read-delay = <0>;
+
+		partitions{
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+		};
 	};
 };
 
-- 
2.25.1



From afd at ti.com  Fri Dec 15 11:20:48 2023
From: afd at ti.com (Andrew Davis)
Date: Fri, 15 Dec 2023 13:20:48 -0600
Subject: [PATCH 0/2] *** Add fixed-paritions to phyCORE-AM62x and
 phyCORE-AM64x ***
In-Reply-To: <20231215191838.1925082-1-nmorrisson@phytec.com>
References: <20231215191838.1925082-1-nmorrisson@phytec.com>
Message-ID: <9f86870c-88cc-43ea-800c-3a05482953aa@ti.com>

On 12/15/23 1:18 PM, Nathan Morrisson wrote:
> Add a fixed-partitions node to the NOR flash of the phyCORE-AM62x
> and phyCORE-AM64x to enable the bootloader to fixup the partitions
> during boot.
> 

Why can't your bootloader add these nodes?

Andrew

> Nathan Morrisson (2):
>    arm64: dts: ti: k3-am62-phycore-som: Add fixed-partitions to NOR Flash
>    arm64: dts: ti: k3-am64-phycore-som: Add fixed-partitions to NOR Flash
> 
>   arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi | 6 ++++++
>   arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi | 6 ++++++
>   2 files changed, 12 insertions(+)
> 


From krzysztof.kozlowski at linaro.org  Fri Dec 15 11:24:31 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 20:24:31 +0100
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate
 clock names
In-Reply-To: <5e454300-f1ef-435c-8c4c-16561502196a@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-2-tudor.ambarus@linaro.org>
 <050c3119-0431-4400-9052-7a9c0ec67918@linaro.org>
 <5e454300-f1ef-435c-8c4c-16561502196a@linaro.org>
Message-ID: <9eedae99-cc9a-4c8f-9a09-789b686cd456@linaro.org>

On 15/12/2023 11:23, Tudor Ambarus wrote:
> Hi, Krzysztof,
> 
> On 12/15/23 08:13, Krzysztof Kozlowski wrote:
>> On 14/12/2023 11:52, Tudor Ambarus wrote:
>>> The gs101 clock names are derived from the clock register names under
>>> some certain rules. In particular, for the gate clocks the following is
>>> documented and expected in the gs101 clock driver:
>>>
>>>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
>>>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>
>>>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>
>> I don't understand what it has to do with the bindings.
>>
>>>
>>> The CMU TOP gate clock names missed to include the required "CMU"
>>> differentiator which will cause name collisions with the gate clock names
>>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>>> their name.
>>
>> Neither here. Clock names are not related to defines.
>>
> 
> When saying "clock names" I meant the clock symbolic names that are
> defined in the bindings, the _id passed in GATE(_id, ) if you want.

Please re-phrase the commit message to say that you need to rename the
defines in the bindings headers. If you change anything else, like clock
names, then it should be separate patch.



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec 15 11:25:57 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 15 Dec 2023 20:25:57 +0100
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate
 clock names
In-Reply-To: <9eedae99-cc9a-4c8f-9a09-789b686cd456@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-2-tudor.ambarus@linaro.org>
 <050c3119-0431-4400-9052-7a9c0ec67918@linaro.org>
 <5e454300-f1ef-435c-8c4c-16561502196a@linaro.org>
 <9eedae99-cc9a-4c8f-9a09-789b686cd456@linaro.org>
Message-ID: <7163718b-0a92-4383-b475-aac52354489d@linaro.org>

On 15/12/2023 20:24, Krzysztof Kozlowski wrote:
> On 15/12/2023 11:23, Tudor Ambarus wrote:
>> Hi, Krzysztof,
>>
>> On 12/15/23 08:13, Krzysztof Kozlowski wrote:
>>> On 14/12/2023 11:52, Tudor Ambarus wrote:
>>>> The gs101 clock names are derived from the clock register names under
>>>> some certain rules. In particular, for the gate clocks the following is
>>>> documented and expected in the gs101 clock driver:
>>>>
>>>>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
>>>>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>>
>>>>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>>
>>> I don't understand what it has to do with the bindings.
>>>
>>>>
>>>> The CMU TOP gate clock names missed to include the required "CMU"
>>>> differentiator which will cause name collisions with the gate clock names
>>>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>>>> their name.
>>>
>>> Neither here. Clock names are not related to defines.
>>>
>>
>> When saying "clock names" I meant the clock symbolic names that are
>> defined in the bindings, the _id passed in GATE(_id, ) if you want.
> 
> Please re-phrase the commit message to say that you need to rename the
> defines in the bindings headers. If you change anything else, like clock
> names, then it should be separate patch.

I forgot:
You can also respin this patch separately, as soon as possible, because
it has to go this cycle.

Best regards,
Krzysztof



From tglx at linutronix.de  Fri Dec 15 11:40:28 2023
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 15 Dec 2023 20:40:28 +0100
Subject: [PATCH RFC v3 21/21] cpumask: Add enabled cpumask for present
 CPUs that can be brought online
In-Reply-To: <E1rDOhX-00Dvlg-Ci@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOhX-00Dvlg-Ci@rmk-PC.armlinux.org.uk>
Message-ID: <87le9vmez7.ffs@tglx>

On Wed, Dec 13 2023 at 12:50, Russell King (Oracle) wrote:
> From: James Morse <james.morse at arm.com>
>
> The 'offline' file in sysfs shows all offline CPUs, including those
> that aren't present. User-space is expected to remove not-present CPUs
> from this list to learn which CPUs could be brought online.
>
> CPUs can be present but not-enabled. These CPUs can't be brought online
> until the firmware policy changes, which comes with an ACPI notification
> that will register the CPUs.
>
> With only the offline and present files, user-space is unable to
> determine which CPUs it can try to bring online. Add a new CPU mask
> that shows this based on all the registered CPUs.
>
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>

Acked-by: Thomas Gleixner <tglx at linutronix.de>


From robh at kernel.org  Fri Dec 15 11:42:10 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 15 Dec 2023 13:42:10 -0600
Subject: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c
 compatible
In-Reply-To: <20231214105243.3707730-4-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-4-tudor.ambarus@linaro.org>
Message-ID: <170266933016.271733.6481546184634336779.robh@kernel.org>


On Thu, 14 Dec 2023 10:52:33 +0000, Tudor Ambarus wrote:
> Add google,gs101-hsi2c dedicated compatible for representing
> I2C of Google GS101 SoC.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>



From robin.murphy at arm.com  Fri Dec 15 11:44:47 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 15 Dec 2023 19:44:47 +0000
Subject: [PATCH] ARM64: Implement arch_report_meminfo()
In-Reply-To: <bc9c1287-6b20-8463-50c1-678b7634cca6@linux.com>
References: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org>
 <b0d7b928-ecc5-4203-8269-423dee08b1ff@arm.com>
 <bc9c1287-6b20-8463-50c1-678b7634cca6@linux.com>
Message-ID: <1a8ef5e3-e478-492f-8f4d-05cc16945593@arm.com>

On 14/12/2023 9:35 pm, Christoph Lameter (Ampere) wrote:
> On Thu, 14 Dec 2023, Robin Murphy wrote:
> 
>> It seems somewhat suspect that these counts only ever increase. It's 
>> not often that we change or remove parts of the linear map, but it 
>> certainly can happen.
> 
> Well yes in the case of hotplug I guess ... Ok here is V2

There are also paths where we remove and reinstate parts of the linear 
map via set_memory_valid(), set_direct_map_*(), and possibly others. If 
we're exposing a user ABI that claims to be accounting kernel VA 
mappings, then I think users are within their rights to expect it to 
actually account kernel VA mappings, not just expose numbers whose only 
guaranteed significance is whether they are zero or nonzero.

Looking again, am I also right in thinking that what I assumed were the 
non-contiguous counts here are actually total counts of *either* type of 
mapping at that level, and inclusive of the contiguous counts? If so, 
that seems a bit non-obvious - my intuitive expectation would be for the 
sum of all these numbers to represent the total amount of direct-mapped 
RAM, where either we're intersted in each distinct type of mapping and 
accounting them all separately, or we're simply interested in the 
general shape of the pagetables, and thus would account per-level and 
ignore the contiguous bit since we don't know whether it's actually 
doing anything useful anyweay.

Thanks,
Robin.

>  From cl at gentwo.org Fri Dec? 8 13:11:58 2023
> From: "Christoph Lameter (Ampere)" <cl at gentwo.org>
> To: Catalin Marinas <catalin.marinas at arm.com>, Marc Zyngier 
> <maz at kernel.org>, Will Deacon <will at kernel.org>, Ryan Roberts 
> <ryan.roberts at arm.com>, Mark Rutland <mark.rutland at arm.com>, Vishal 
> Moola <vishal.moola at gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org, linux-mm at kvack.org
> Subject: [PATCH] ARM64: Implement arch_report_meminfo()
> 
> V1->V2 hotplug and umapping support
> 
> X86 has information in /proc/meminfo showing the use of large mappings
> for the kernel direct map. This has now also become important for
> ARM since the kernel default CONFIG_RODATA_FULL_DEFAULT_ENABLED
> forces 4K PTE use for the direct map and users may not be aware
> of the performance impact of the increased TLB use etc.
> 
> The output of /proc/meminfo on ARM64 is then after this patch:
> 
> 4K page size:
> 
> Hugepagesize:?????? 2048 kB
> Hugetlb:?????????????? 0 kB
> DirectMap4k:????? 155912 kB
> CONT DMap4k:??????? 1176 kB
> DirectMap2M:????? 722944 kB
> CONT DMap2M:?????? 28672 kB
> DirectMap1G:?? 534773760 kB
> 
> 64K page size:
> 
> Hugepagesize:???? 524288 kB
> Hugetlb:?????????????? 0 kB
> DirectMap64k:????? 882624 kB
> CONT DMap64k:?????? 19904 kB
> DirectMap512M:??? 534773760 kB
> CONT DMap512M:?????????? 0 kB
> DirectMap4096G:?????????? 0 kB
> 
> Signed-off-by: Christoph Lameter (Ampere) <cl at linux.com>
> 
> Index: linux/arch/arm64/mm/mmu.c
> ===================================================================
> --- linux.orig/arch/arm64/mm/mmu.c
> +++ linux/arch/arm64/mm/mmu.c
> @@ -76,6 +76,13 @@ EXPORT_SYMBOL(empty_zero_page);
>  ?static DEFINE_SPINLOCK(swapper_pgdir_lock);
>  ?static DEFINE_MUTEX(fixmap_lock);
> 
> +static atomic_t nr_pte;
> +static atomic_t nr_pmd;
> +static atomic_t nr_pud;
> +static atomic_t nr_pte_cont;
> +static atomic_t nr_pmd_cont;
> +
> +
>  ?void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
>  ?{
>  ???? pgd_t *fixmap_pgdp;
> @@ -179,6 +186,7 @@ static void init_pte(pmd_t *pmdp, unsign
>  ???????? pte_t old_pte = READ_ONCE(*ptep);
> 
>  ???????? set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
> +??????? atomic_inc(&nr_pte);
> 
>  ???????? /*
>  ????????? * After the PTE entry has been populated once, we
> @@ -223,8 +231,10 @@ static void alloc_init_cont_pte(pmd_t *p
> 
>  ???????? /* use a contiguous mapping if the range is suitably aligned */
>  ???????? if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
> -??????????? (flags & NO_CONT_MAPPINGS) == 0)
> +??????????? (flags & NO_CONT_MAPPINGS) == 0) {
>  ???????????? __prot = __pgprot(pgprot_val(prot) | PTE_CONT);
> +??????????? atomic_inc(&nr_pte_cont);
> +??????? }
> 
>  ???????? init_pte(pmdp, addr, next, phys, __prot);
> 
> @@ -249,6 +259,7 @@ static void init_pmd(pud_t *pudp, unsign
>  ???????? if (((addr | next | phys) & ~PMD_MASK) == 0 &&
>  ???????????? (flags & NO_BLOCK_MAPPINGS) == 0) {
>  ???????????? pmd_set_huge(pmdp, phys, prot);
> +??????????? atomic_inc(&nr_pmd);
> 
>  ???????????? /*
>  ????????????? * After the PMD entry has been populated once, we
> @@ -301,8 +312,10 @@ static void alloc_init_cont_pmd(pud_t *p
> 
>  ???????? /* use a contiguous mapping if the range is suitably aligned */
>  ???????? if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
> -??????????? (flags & NO_CONT_MAPPINGS) == 0)
> +??????????? (flags & NO_CONT_MAPPINGS) == 0) {
>  ???????????? __prot = __pgprot(pgprot_val(prot) | PTE_CONT);
> +??????????? atomic_inc(&nr_pmd_cont);
> +??????? }
> 
>  ???????? init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
> 
> @@ -346,7 +359,7 @@ static void alloc_init_pud(pgd_t *pgdp,
>  ??????????? ((addr | next | phys) & ~PUD_MASK) == 0 &&
>  ???????????? (flags & NO_BLOCK_MAPPINGS) == 0) {
>  ???????????? pud_set_huge(pudp, phys, prot);
> -
> +??????????? atomic_inc(&nr_pud);
>  ???????????? /*
>  ????????????? * After the PUD entry has been populated once, we
>  ????????????? * only allow updates to the permission attributes.
> @@ -859,6 +872,11 @@ static void unmap_hotplug_pte_range(pmd_
>  ???????????? continue;
> 
>  ???????? WARN_ON(!pte_present(pte));
> +
> +??????? if (pte_cont(pte))
> +??????????? atomic_dec(&nr_pte_cont);
> +??????? atomic_dec(&nr_pte);
> +
>  ???????? pte_clear(&init_mm, addr, ptep);
>  ???????? flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>  ???????? if (free_mapped)
> @@ -883,6 +901,11 @@ static void unmap_hotplug_pmd_range(pud_
> 
>  ???????? WARN_ON(!pmd_present(pmd));
>  ???????? if (pmd_sect(pmd)) {
> +
> +??????????? if (pmd_cont(pmd))
> +??????????????? atomic_dec(&nr_pmd_cont);
> +??????????? atomic_dec(&nr_pmd);
> +
>  ???????????? pmd_clear(pmdp);
> 
>  ???????????? /*
> @@ -916,6 +939,9 @@ static void unmap_hotplug_pud_range(p4d_
> 
>  ???????? WARN_ON(!pud_present(pud));
>  ???????? if (pud_sect(pud)) {
> +
> +??????????? atomic_dec(&nr_pud);
> +
>  ???????????? pud_clear(pudp);
> 
>  ???????????? /*
> @@ -1010,6 +1036,7 @@ static void free_empty_pte_table(pmd_t *
>  ???????????? return;
>  ???? }
> 
> +??? atomic_dec(&nr_pmd);
>  ???? pmd_clear(pmdp);
>  ???? __flush_tlb_kernel_pgtable(start);
>  ???? free_hotplug_pgtable_page(virt_to_page(ptep));
> @@ -1050,6 +1077,7 @@ static void free_empty_pmd_table(pud_t *
>  ???????????? return;
>  ???? }
> 
> +??? atomic_dec(&nr_pud);
>  ???? pud_clear(pudp);
>  ???? __flush_tlb_kernel_pgtable(start);
>  ???? free_hotplug_pgtable_page(virt_to_page(pmdp));
> @@ -1225,6 +1253,7 @@ int pmd_free_pte_page(pmd_t *pmdp, unsig
>  ???? }
> 
>  ???? table = pte_offset_kernel(pmdp, addr);
> +??? atomic_dec(&nr_pmd);
>  ???? pmd_clear(pmdp);
>  ???? __flush_tlb_kernel_pgtable(addr);
>  ???? pte_free_kernel(NULL, table);
> @@ -1253,6 +1282,7 @@ int pud_free_pmd_page(pud_t *pudp, unsig
>  ???????? pmd_free_pte_page(pmdp, next);
>  ???? } while (pmdp++, next += PMD_SIZE, next != end);
> 
> +??? atomic_dec(&nr_pud);
>  ???? pud_clear(pudp);
>  ???? __flush_tlb_kernel_pgtable(addr);
>  ???? pmd_free(NULL, table);
> @@ -1486,3 +1516,36 @@ void ptep_modify_prot_commit(struct vm_a
>  ?{
>  ???? set_pte_at(vma->vm_mm, addr, ptep, pte);
>  ?}
> +
> +
> +#ifdef CONFIG_PROC_FS
> +void arch_report_meminfo(struct seq_file *m)
> +{
> +??? unsigned long pagesize_in_kb = PAGE_SIZE / 1024;
> +
> +??? seq_printf(m, "DirectMap%luk:??? %8lu kB\n",
> +??????????? pagesize_in_kb,
> +????????????? (unsigned long)atomic_read(&nr_pte) * pagesize_in_kb);
> +
> +??????? seq_printf(m, "CONT DMap%luk:??? %8lu kB\n",
> +??????????? pagesize_in_kb,
> +??????????? (unsigned long)atomic_read(&nr_pte_cont) * pagesize_in_kb);
> +
> +??? pagesize_in_kb = PMD_SIZE / 1024;
> +
> +??????? seq_printf(m, "DirectMap%luM:??? %8lu kB\n",
> +??????????? pagesize_in_kb / 1024,
> +??????????? (unsigned long)atomic_read(&nr_pmd) * pagesize_in_kb);
> +
> +??? seq_printf(m, "CONT DMap%luM:??? %8lu kB\n",
> +??????????? pagesize_in_kb / 1024,
> +??????????? (unsigned long)atomic_read(&nr_pmd_cont) * pagesize_in_kb);
> +
> +??? pagesize_in_kb = PUD_SIZE / 1024;
> +
> +??? seq_printf(m, "DirectMap%luG:? %10lu kB\n",
> +??????????? pagesize_in_kb >> 20,
> +??????????? (unsigned long)atomic_read(&nr_pud) * pagesize_in_kb);
> +}
> +#endif
> +


From rjw at rjwysocki.net  Fri Dec 15 11:47:31 2023
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Fri, 15 Dec 2023 20:47:31 +0100
Subject: [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or functional) devices
In-Reply-To: <20231215161539.00000940@Huawei.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk> <ZXxxa+XZjPZtNfJ+@shell.armlinux.org.uk> <20231215161539.00000940@Huawei.com>
Message-ID: <5760569.DvuYhMxLoT@kreacher>

On Friday, December 15, 2023 5:15:39 PM CET Jonathan Cameron wrote:
> On Fri, 15 Dec 2023 15:31:55 +0000
> "Russell King (Oracle)" <linux at armlinux.org.uk> wrote:
> 
> > On Thu, Dec 14, 2023 at 07:37:10PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Dec 14, 2023 at 7:16?PM Rafael J. Wysocki <rafael at kernel.org> wrote:  
> > > >
> > > > On Thu, Dec 14, 2023 at 7:10?PM Russell King (Oracle)
> > > > <linux at armlinux.org.uk> wrote:  
> > > > > I guess we need something like:
> > > > >
> > > > >         if (device->status.present)
> > > > >                 return device->device_type != ACPI_BUS_TYPE_PROCESSOR ||
> > > > >                        device->status.enabled;
> > > > >         else
> > > > >                 return device->status.functional;
> > > > >
> > > > > so we only check device->status.enabled for processor-type devices?  
> > > >
> > > > Yes, something like this.  
> > > 
> > > However, that is not sufficient, because there are
> > > ACPI_BUS_TYPE_DEVICE devices representing processors.
> > > 
> > > I'm not sure about a clean way to do it ATM.  
> > 
> > Ok, how about:
> > 
> > static bool acpi_dev_is_processor(const struct acpi_device *device)
> > {
> > 	struct acpi_hardware_id *hwid;
> > 
> > 	if (device->device_type == ACPI_BUS_TYPE_PROCESSOR)
> > 		return true;
> > 
> > 	if (device->device_type != ACPI_BUS_TYPE_DEVICE)
> > 		return false;
> > 
> > 	list_for_each_entry(hwid, &device->pnp.ids, list)
> > 		if (!strcmp(ACPI_PROCESSOR_OBJECT_HID, hwid->id) ||
> > 		    !strcmp(ACPI_PROCESSOR_DEVICE_HID, hwid->id))
> > 			return true;
> > 
> > 	return false;
> > }
> > 
> > and then:
> > 
> > 	if (device->status.present)
> > 		return !acpi_dev_is_processor(device) || device->status.enabled;
> > 	else
> > 		return device->status.functional;
> > 
> > ?
> > 
> Changing it to CPU only for now makes sense to me and I think this code snippet should do the
> job.  Nice and simple.

Well, except that it does checks that are done elsewhere slightly
differently, which from the maintenance POV is not nice.

Maybe something like the appended patch (untested).

---
 drivers/acpi/acpi_processor.c |   11 +++++++++++
 drivers/acpi/internal.h       |    3 +++
 drivers/acpi/scan.c           |   24 +++++++++++++++++++++++-
 3 files changed, 37 insertions(+), 1 deletion(-)

Index: linux-pm/drivers/acpi/acpi_processor.c
===================================================================
--- linux-pm.orig/drivers/acpi/acpi_processor.c
+++ linux-pm/drivers/acpi/acpi_processor.c
@@ -644,6 +644,17 @@ static struct acpi_scan_handler processo
 	},
 };
 
+bool acpi_device_is_processor(const struct acpi_device *adev)
+{
+	if (adev->device_type == ACPI_BUS_TYPE_PROCESSOR)
+		return true;
+
+	if (adev->device_type != ACPI_BUS_TYPE_DEVICE)
+		return false;
+
+	return acpi_scan_check_handler(adev, &processor_handler);
+}
+
 static int acpi_processor_container_attach(struct acpi_device *dev,
 					   const struct acpi_device_id *id)
 {
Index: linux-pm/drivers/acpi/internal.h
===================================================================
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -62,6 +62,8 @@ void acpi_sysfs_add_hotplug_profile(stru
 int acpi_scan_add_handler_with_hotplug(struct acpi_scan_handler *handler,
 				       const char *hotplug_profile_name);
 void acpi_scan_hotplug_enabled(struct acpi_hotplug_profile *hotplug, bool val);
+bool acpi_scan_check_handler(const struct acpi_device *adev,
+			     struct acpi_scan_handler *handler);
 
 #ifdef CONFIG_DEBUG_FS
 extern struct dentry *acpi_debugfs_dir;
@@ -133,6 +135,7 @@ int acpi_bus_register_early_device(int t
 const struct acpi_device *acpi_companion_match(const struct device *dev);
 int __acpi_device_uevent_modalias(const struct acpi_device *adev,
 				  struct kobj_uevent_env *env);
+bool acpi_device_is_processor(const struct acpi_device *adev);
 
 /* --------------------------------------------------------------------------
                                   Power Resource
Index: linux-pm/drivers/acpi/scan.c
===================================================================
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -1938,6 +1938,19 @@ static bool acpi_scan_handler_matching(s
 	return false;
 }
 
+bool acpi_scan_check_handler(const struct acpi_device *adev,
+			     struct acpi_scan_handler *handler)
+{
+	struct acpi_hardware_id *hwid;
+
+	list_for_each_entry(hwid, &adev->pnp.ids, list) {
+		if (acpi_scan_handler_matching(handler, hwid->id, NULL))
+			return true;
+	}
+
+	return false;
+}
+
 static struct acpi_scan_handler *acpi_scan_match_handler(const char *idstr,
 					const struct acpi_device_id **matchid)
 {
@@ -2410,7 +2423,16 @@ bool acpi_dev_ready_for_enumeration(cons
 	if (device->flags.honor_deps && device->dep_unmet)
 		return false;
 
-	return acpi_device_is_present(device);
+	if (device->status.functional)
+		return true;
+
+	if (!device->status.present)
+		return false;
+
+	if (device->status.enabled)
+		return true; /* Fast path. */
+
+	return !acpi_device_is_processor(device);
 }
 EXPORT_SYMBOL_GPL(acpi_dev_ready_for_enumeration);
 





From robh at kernel.org  Fri Dec 15 11:58:53 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 15 Dec 2023 13:58:53 -0600
Subject: [PATCH v2 2/7] dt-bindings: media: mtk-vcodec-encoder: add
 dma-ranges
In-Reply-To: <20231215104551.233679-2-eugen.hristev@collabora.com>
References: <20231215104551.233679-1-eugen.hristev@collabora.com>
 <20231215104551.233679-2-eugen.hristev@collabora.com>
Message-ID: <170267033128.294824.6094667140033672249.robh@kernel.org>


On Fri, 15 Dec 2023 12:45:46 +0200, Eugen Hristev wrote:
> As IOMMUs are supported, dma-ranges is not mentioned but
> additionalProperties=false, thus we have an error when adding dma-ranges.
> Add dma-ranges as a possible property because this may be present.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
> ---
> Changes in v2:
> - none.
>  .../devicetree/bindings/media/mediatek,vcodec-encoder.yaml      | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Fri Dec 15 12:03:01 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 15 Dec 2023 14:03:01 -0600
Subject: [PATCH v2 3/7] dt-bindings: media: mtk-vcodec-encoder: fix
 non-vp8 clock name
In-Reply-To: <20231215104551.233679-3-eugen.hristev@collabora.com>
References: <20231215104551.233679-1-eugen.hristev@collabora.com>
 <20231215104551.233679-3-eugen.hristev@collabora.com>
Message-ID: <170267057932.303365.14773226712594255838.robh@kernel.org>


On Fri, 15 Dec 2023 12:45:47 +0200, Eugen Hristev wrote:
> Looking at the binding it makes sense that the `-vp8` compatible has
> the `venc_lt_sel` while the other bindings have the `venc_sel` as name for
> the clock.
> This was also mentioned in the txt version of the binding before the
> conversion:
>  `
>  clock-names: avc encoder must contain "venc_sel", vp8 encoder must
>  contain "venc_lt_sel", decoder must contain "vcodecpll", "univpll_d2",
>  `
> 
> So it is easier to check for compatible that includes vp8, since that's
> just one, to have the requirement for the clock name property as
> `venc_lt_sel`, rather than for all the others, some of which are missing,
> thus for them, the requirement is wrongly `venc_lt_sel`.
> 
> Reordered the if/then/else to match `-vp8` and have all the rest of
> the compatibles using the other clock name (`venc_sel`).
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
> ---
> Changes in v2:
> - new patch.
>  .../bindings/media/mediatek,vcodec-encoder.yaml       | 11 ++++-------
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 

Reviewed-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Fri Dec 15 12:03:25 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 15 Dec 2023 14:03:25 -0600
Subject: [PATCH v2 5/7] dt-bindings: media: mtk-vcodec-encoder: add
 compatible for mt8186
In-Reply-To: <20231215104551.233679-5-eugen.hristev@collabora.com>
References: <20231215104551.233679-1-eugen.hristev@collabora.com>
 <20231215104551.233679-5-eugen.hristev@collabora.com>
Message-ID: <170267060230.304140.8670744494776319731.robh@kernel.org>


On Fri, 15 Dec 2023 12:45:49 +0200, Eugen Hristev wrote:
> Add compatible for the mt8186 encoder which currently works in the same
> way as mt8183.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
> ---
> Changes in v2:
> - new patch.
>  .../media/mediatek,vcodec-encoder.yaml        | 20 +++++++++++--------
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 

Reviewed-by: Rob Herring <robh at kernel.org>



From catalin.marinas at arm.com  Fri Dec 15 12:03:39 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 15 Dec 2023 20:03:39 +0000
Subject: [PATCH] arm64: properly install vmlinuz.efi
In-Reply-To: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>
References: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>
Message-ID: <ZXyxG9qsASMQ-1Ty@arm.com>

On Thu, Dec 14, 2023 at 11:18:50AM -0500, Josef Bacik wrote:
> If you select CONFIG_EFI_ZBOOT, we will generate vmlinuz.efi, and then
> when we go to install the kernel we'll install the vmlinux instead
> because install.sh only recognizes Image.gz as wanting the compressed
> install image.  With CONFIG_EFI_ZBOOT we don't get the proper kernel
> installed, which means it doesn't boot, which makes for a very confused
> and subsequently angry kernel developer.
> 
> Fix this by properly installing our compressed kernel if we've enabled
> CONFIG_EFI_ZBOOT.
> 
> Signed-off-by: Josef Bacik <josef at toxicpanda.com>
> ---
>  arch/arm64/boot/install.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
> index 7399d706967a..9b7a09808a3d 100755
> --- a/arch/arm64/boot/install.sh
> +++ b/arch/arm64/boot/install.sh
> @@ -17,7 +17,8 @@
>  #   $3 - kernel map file
>  #   $4 - default install path (blank if root directory)
>  
> -if [ "$(basename $2)" = "Image.gz" ]; then
> +if [ "$(basename $2)" = "Image.gz" ] || [ "$(basename $2)" = "vmlinuz.efi" ]
> +then
>  # Compressed install
>    echo "Installing compressed kernel"
>    base=vmlinuz

+ Ard who added the EFI_ZBOOT support.

If we go with this fix we should probably also add:

Fixes: c37b830fef13 ("arm64: efi: enable generic EFI compressed boot")
Cc: <stable at vger.kernel.org> # 6.1.x

But is arm64 the only one with this issue?

-- 
Catalin


From festevam at gmail.com  Fri Dec 15 12:09:41 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 15 Dec 2023 17:09:41 -0300
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <CAHCN7xLHMGcS2-QTneqqpHYU66JwuEG4TyR0j0riFGqO6RC8ug@mail.gmail.com>
References: <20230920171009.3193296-1-l.stach@pengutronix.de>
 <20230920171009.3193296-2-l.stach@pengutronix.de> <20230920205736.GB7723@pendragon.ideasonboard.com>
 <CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>
 <CAOMZO5C7_Rj-Ja0BO0D0Po+gy+XbvyMdQf-wH5YNyhAdMof2vg@mail.gmail.com>
 <20231215142308.GL21146@pendragon.ideasonboard.com> <CAHCN7xJPg_Nk=o9fKwkZfVTNSB-YL0m7vY6p1O7+i=PHShp7hg@mail.gmail.com>
 <CAOMZO5AGAkPpds=5H-iQj53djcQtW5GsRQrzdC_JOOrcENhvvw@mail.gmail.com> <CAHCN7xLHMGcS2-QTneqqpHYU66JwuEG4TyR0j0riFGqO6RC8ug@mail.gmail.com>
Message-ID: <CAOMZO5B2bWVciDEwSh+YQWu6b_Hp5ijk6Jq-bMePPTDRJ-vHFA@mail.gmail.com>

On Fri, Dec 15, 2023 at 4:01?PM Adam Ford <aford173 at gmail.com> wrote:

> Thanks for the list.  I was able to successfully build the stable 6.6
> branch with those patches applied and I have the HDMI working.
> Unfortunately, I get build errors on the linux-next, so it's going to
> take me a little time to sort through all of this.

If you need help to figure this problem out, please let me know.

I haven't tried it against linux-next.

> I am thinking that it would be better to consolidate all these
> together into one series instead of piecemealing it.  However, there
> are some items that can be submitted right away without significantly
> reworking them against linux-next.  Do people have a preference?

I think it makes sense to re-submit the "easy ones" right away.


From robh at kernel.org  Fri Dec 15 12:11:48 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 15 Dec 2023 14:11:48 -0600
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
Message-ID: <20231215201148.GA304363-robh@kernel.org>

On Fri, Dec 15, 2023 at 07:56:32PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Add SCMI v3.2 pinctrl protocol bindings and example.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  .../devicetree/bindings/firmware/arm,scmi.yaml     | 99 ++++++++++++++++++++++
>  1 file changed, 99 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index 4591523b51a0..bfd2b6a89979 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -247,6 +247,85 @@ properties:
>        reg:
>          const: 0x18
>  
> +  protocol at 19:
> +    type: object
> +    allOf:
> +      - $ref: '#/$defs/protocol-node'
> +      - $ref: /schemas/pinctrl/pinctrl.yaml
> +      - if:
> +          properties:
> +            compatible:
> +              const: fsl,imx95-scmi-pinctrl
> +        then:
> +          patternProperties:
> +            "grp$": false
> +            "-pins$": true
> +        else:
> +          patternProperties:
> +            "grp$": false
> +            "-pins$": true
> +    unevaluatedProperties: false

This will not scale if each vendor adds to arm,scmi.yaml. You need to 
move this to its own file. That can have a ref to 
/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node.

Here you can just say compatible is "fsl,imx95-scmi-pinctrl" and 
'additionalProperties: true'.

> +
> +    properties:
> +      reg:
> +        const: 0x19
> +
> +      '#pinctrl-cells':
> +        const: 0

Generally not used if 0.

> +
> +      compatible:
> +        const: fsl,imx95-scmi-pinctrl
> +
> +    patternProperties:
> +      '-pins$':
> +        type: object
> +        allOf:
> +          - $ref: /schemas/pinctrl/pincfg-node.yaml#
> +          - $ref: /schemas/pinctrl/pinmux-node.yaml#
> +        unevaluatedProperties: false
> +
> +        description:
> +          A pin multiplexing sub-node describe how to configure a
> +          set of pins is some desired function.
> +          A single sub-node may define several pin configurations.
> +          This sub-node is using default pinctrl bindings to configure
> +          pin multiplexing and using SCMI protocol to apply specified
> +          configuration using SCMI protocol.
> +
> +      'grp$':
> +        type: object
> +        description:
> +          Pinctrl node's client devices use subnodes for desired pin configuration.
> +          Client device subnodes use below standard properties.
> +
> +        properties:
> +          fsl,pins:
> +            description:
> +              each entry consists of 6 integers and represents the mux and config
> +              setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
> +              mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
> +              be found in <arch/arm64/boot/dts/freescale/imx95-pinfunc.h>. The last
> +              integer CONFIG is the pad setting value like pull-up on this pin. Please
> +              refer to i.MX95 Plus Reference Manual for detailed CONFIG settings.
> +            $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +            items:
> +              items:
> +                - description: |
> +                    "mux_reg" indicates the offset of mux register.
> +                - description: |
> +                    "conf_reg" indicates the offset of pad configuration register.
> +                - description: |
> +                    "input_reg" indicates the offset of select input register.
> +                - description: |
> +                    "mux_val" indicates the mux value to be applied.
> +                - description: |
> +                    "input_val" indicates the select input value to be applied.
> +                - description: |
> +                    "pad_setting" indicates the pad configuration value to be applied.
> +
> +    required:
> +      - reg
> +
>  additionalProperties: false
>  
>  $defs:
> @@ -401,6 +480,26 @@ examples:
>              scmi_powercap: protocol at 18 {
>                  reg = <0x18>;
>              };
> +
> +            scmi_pinctrl: protocol at 19 {
> +                reg = <0x19>;
> +                #pinctrl-cells = <0>;

Missing compatible. Schema should catch that...

> +
> +                i2c2-pins {
> +                    groups = "i2c2_a", "i2c2_b";
> +                    function = "i2c2";
> +                };
> +
> +                mdio-pins {
> +                    groups = "avb_mdio";
> +                    drive-strength = <24>;
> +                };
> +
> +                keys_pins: keys-pins {
> +                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> +                    bias-pull-up;
> +                };
> +            };
>          };
>      };
>  
> 
> -- 
> 2.37.1
> 


From robh at kernel.org  Fri Dec 15 12:13:24 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 15 Dec 2023 14:13:24 -0600
Subject: [PATCH 1/3] dt-bindings: arm: rockchip: Add NanoPi R6 series
 boards
In-Reply-To: <b74f5b91693d9b1ec525fb22e06c0a8311c7cf05.1702647349.git.efectn@protonmail.com>
References: <cover.1702647349.git.efectn@protonmail.com>
 <b74f5b91693d9b1ec525fb22e06c0a8311c7cf05.1702647349.git.efectn@protonmail.com>
Message-ID: <20231215201324.GA315671-robh@kernel.org>

On Fri, Dec 15, 2023 at 04:55:21PM +0300, efectn at 6tel.net wrote:
> From: Muhammed Efe Cetin <efectn at protonmail.com>
> 

Commit message missing. Perhaps some detail on what r6c is vs. r6s.


> Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
> ---
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index ee92f0535..07c4eb828 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -225,6 +225,13 @@ properties:
>                - friendlyarm,nanopi-r5s
>            - const: rockchip,rk3568
>  
> +      - description: FriendlyElec NanoPi R6 series boards
> +        items:
> +          - enum:
> +              - friendlyarm,nanopi-r6c
> +              - friendlyarm,nanopi-r6s
> +          - const: rockchip,rk3588s
> +
>        - description: FriendlyElec NanoPC T6
>          items:
>            - const: friendlyarm,nanopc-t6
> -- 
> 2.43.0
> 


From mshavit at google.com  Fri Dec 15 12:26:48 2023
From: mshavit at google.com (Michael Shavit)
Date: Sat, 16 Dec 2023 04:26:48 +0800
Subject: [PATCH 04/19] iommu/arm-smmu-v3: Make STE programming independent
 of the callers
In-Reply-To: <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
References: <0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com> <CAKHBV24UGZuG6+J4cybadJCTyf9hN+e_VgAC0NVOPotmEur7SQ@mail.gmail.com>
 <20231012121616.GF3952@nvidia.com> <CAKHBV27G1PLZ5gkYkOOCZdD9waZOZypkWqk4_HSR4XXGFT-+LA@mail.gmail.com>
 <20231018130455.GU3952@nvidia.com> <CAKHBV270uJjdj4zeK-NNt+j3TiqoGDdLUQ5uRrLw9PN0ysCDbw@mail.gmail.com>
 <20231020113918.GD3952@nvidia.com> <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
Message-ID: <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com>

On Mon, Oct 23, 2023 at 4:36?PM Michael Shavit <mshavit at google.com> wrote:
>
> On Fri, Oct 20, 2023 at 7:39?PM Jason Gunthorpe <jgg at nvidia.com> wrote:
> >
> > On Fri, Oct 20, 2023 at 04:23:44PM +0800, Michael Shavit wrote:
> > > The comment helps a lot thank you.
> > >
> > > I do still have some final reservations: wouldn't it be clearer with
> > > the loop un-rolled? After all it's only 3 steps in the worst case....
> > > Something like:
> >
> > I thought about that, but a big point for me was to consolidate the
> > algorithm between CD/STE. Inlining everything makes it much more
> > difficult to achieve this. Actually my first sketches were trying to
> > write it unrolled.
> >
> > > +       arm_smmu_get_ste_used(target, &target_used);
> > > +       arm_smmu_get_ste_used(cur, &cur_used);
> > > +       if (!hitless_possible(target, target_used, cur_used, cur_used)) {
> >
> > hitless possible requires the loop of the step function to calcuate
> > it.
>
> Possibly yes. Another option would be to have a list of transitions
> (e.g. IDENTITY -> S1) we expect and want to be hitless and check
> against that list. It defeats some of the purpose of your design, but
> it's also not obvious to me that we really need such flexibility in
> the first place.
>
> >
> > > +               target->data[0] = STRTAB_STE_0_V;
> > > +               arm_smmu_sync_ste_for_sid(smmu, sid);
> >
> > I still like V=0 as I think we do want the event for this case.
>
> Oh yeah sure, I did not think too carefully about this.
>
> >
> > > +               /*
> > > +                * The STE is now in abort where none of the bits except
> > > +                * STRTAB_STE_0_V and STRTAB_STE_0_CFG are accessed. This allows
> > > +                * all other words of the STE to be written without further
> > > +                * disruption.
> > > +                */
> > > +               arm_smmu_get_ste_used(cur, &cur_used);
> > > +       }
> > > +       /* write bits in all positions unused by the STE */
> > > +       for (i = 0; i != ARRAY_SIZE(cur->data); i++) {
> > > +               /* (should probably optimize this away if no write needed) */
> > > +               WRITE_ONCE(cur->data[i], (cur->data[i] & cur_used[i])
> > > | (target->data[i] & ~cur_used[i]));
> > > +       }
> > > +       arm_smmu_sync_ste_for_sid(smmu, sid);
> >
> > Yes, I wanted to avoid all the syncs if they are not required.
>
> Should be easy enough to optimize away in this alternate version as well.
>
> >
> > > +       /*
> > > +        * It should now be possible to make a single qword write to make the
> > > +        * the new configuration take effect.
> > > +        */
> > > +       for (i = 0; i != ARRAY_SIZE(cur->data); i++) {
> > > +               if ((cur->data[i] & target_used[i]) !=
> > > (target->data[i] & target_used[i]))
> > > +                       /*
> > > +                        * TODO:
> > > +                        * WARN_ONCE if this condition hits more than once in
> > > +                        * the loop
> > > +                        */
> > > +                       WRITE_ONCE(cur->data[i], (cur->data[i] &
> > > cur_used[i]) | (target->data[i] & ~cur_used[i]));
> > > +       }
> >
> > > +       arm_smmu_sync_ste_for_sid(smmu, sid);
> >
> > This needs to be optional too
> >
> > And there is another optional 4th pass to set the unused target values
> > to 0.
> >
> > Basically you have captured the core algorithm, but I think if you
> > fill in all the missing bits to get up to the same functionality it
> > will be longer and unsharable with the CD side.
> >
> > You could perhaps take this approach and split it into 4 sharable step
> > functions:
> >
> >  if (step1(target, target_used, cur_used, cur_used, len)) {
> >   arm_smmu_sync_ste_for_sid(smmu, sid);
> >   arm_smmu_get_ste_used(cur, &cur_used);
> >  }
> >
> >  if (step2(target, target_used, cur_used, cur_used, len))
> >   arm_smmu_sync_ste_for_sid(smmu, sid);
> >
> >  if (step3(target, target_used, cur_used, cur_used, len)) {
> >    arm_smmu_sync_ste_for_sid(smmu, sid);
> >    arm_smmu_get_ste_used(cur, &cur_used);
> >   }
> >
> >  if (step4(target, target_used, cur_used, cur_used, len))
> >    arm_smmu_sync_ste_for_sid(smmu, sid);
> >
> > To me this is inelegant as if we only need to do step 3 we have to
> > redundantly scan the array 2 times. The rolled up version just
> > directly goes to step 3.
> >
> > However this does convince me you've thought very carefully about this
> > and have not found a flaw in the design!
>
> Right, it's more of a style/readability question so I'll leave it to
> others to chime in further if needed :) .

Ok, I took a proper stab at trying to unroll the loop on the github
version of this patch (v3+)
As you suspected, it's not easy to re-use the unrolled version for
both STE and CD writing as we'd have to pass in callbacks for syncing
the STE/CD and recomputing arm_smmu_{get_ste/cd}_used. The flow is
still exactly the same in both cases however, and there is room to
extract some of the steps between sync operations into shareable
helpers for re-use between the two (I haven't bothered to do that so
that we can evaluate first before putting in more effort).

I personally find this quite a bit more readable as a sequential
series of steps instead of a loop. It also only requires 3 STE/CD
syncs in the worst case compared to 4 in the loop version since we
determine whether a hitless transition is possible before making any
writes to the STE (where-as the current patch optimistically starts
trying to transition to the target before discovering that it must
nuke the V bit first).
Are those both not worth a bit of code duplication between STE and CD writing?

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 98aa8cc17b58b..1c35599d944d7 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -971,100 +971,6 @@ void arm_smmu_tlb_inv_asid(struct
arm_smmu_device *smmu, u16 asid)
        arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
 }

-/*
- * This algorithm updates any STE/CD to any value without creating a situation
- * where the HW can percieve a corrupted entry. HW is only required
to have a 64
- * bit atomicity with stores from the CPU, while entries are many 64 bit values
- * big.
- *
- * The algorithm works by evolving the entry toward the target in a series of
- * steps. Each step synchronizes with the HW so that the HW can not
see an entry
- * torn across two steps. Upon each call cur/cur_used reflect the current
- * synchronized value seen by the HW.
- *
- * During each step the HW can observe a torn entry that has any combination of
- * the step's old/new 64 bit words. The algorithm objective is for the HW
- * behavior to always be one of current behavior, V=0, or new behavior, during
- * each step, and across all steps.
- *
- * At each step one of three actions is chosen to evolve cur to target:
- *  - Update all unused bits with their target values.
- *    This relies on the IGNORED behavior described in the specification
- *  - Update a single 64-bit value
- *  - Update all unused bits and set V=0
- *
- * The last two actions will cause cur_used to change, which will
then allow the
- * first action on the next step.
- *
- * In the most general case we can make any update in three steps:
- *  - Disrupting the entry (V=0)
- *  - Fill now unused bits, all bits except V
- *  - Make valid (V=1), single 64 bit store
- *
- * However this disrupts the HW while it is happening. There are several
- * interesting cases where a STE/CD can be updated without disturbing the HW
- * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
- * because the used bits don't intersect. We can detect this by calculating how
- * many 64 bit values need update after adjusting the unused bits and skip the
- * V=0 process.
- */
-static bool arm_smmu_write_entry_next(__le64 *cur, const __le64 *cur_used,
-                                     const __le64 *target,
-                                     const __le64 *target_used, __le64 *step,
-                                     __le64 v_bit, unsigned int len)
-{
-       u8 step_used_diff = 0;
-       u8 step_change = 0;
-       unsigned int i;
-
-       /*
-        * Compute a step that has all the bits currently unused by HW set to
-        * their target values.
-        */
-       for (i = 0; i != len; i++) {
-               step[i] = (cur[i] & cur_used[i]) | (target[i] & ~cur_used[i]);
-               if (cur[i] != step[i])
-                       step_change |= 1 << i;
-               /*
-                * Each bit indicates if the step is incorrect compared to the
-                * target, considering only the used bits in the target
-                */
-               if ((step[i] & target_used[i]) != (target[i] & target_used[i]))
-                       step_used_diff |= 1 << i;
-       }
-
-       if (hweight8(step_used_diff) > 1) {
-               /*
-                * More than 1 qword is mismatched, this cannot be done without
-                * a break. Clear the V bit and go again.
-                */
-               step[0] &= ~v_bit;
-       } else if (!step_change && step_used_diff) {
-               /*
-                * Have exactly one critical qword, all the other qwords are set
-                * correctly, so we can set this qword now.
-                */
-               i = ffs(step_used_diff) - 1;
-               step[i] = target[i];
-       } else if (!step_change) {
-               /* cur == target, so all done */
-               if (memcmp(cur, target, len * sizeof(*cur)) == 0)
-                       return true;
-
-               /*
-                * All the used HW bits match, but unused bits are different.
-                * Set them as well. Technically this isn't necessary but it
-                * brings the entry to the full target state, so if there are
-                * bugs in the mask calculation this will obscure them.
-                */
-               memcpy(step, target, len * sizeof(*step));
-       }
-
-       for (i = 0; i != len; i++)
-               WRITE_ONCE(cur[i], step[i]);
-       return false;
-}
-
 static void arm_smmu_sync_cd(struct arm_smmu_master *master,
                             int ssid, bool leaf)
 {
@@ -1398,39 +1304,135 @@ static void arm_smmu_get_ste_used(const
struct arm_smmu_ste *ent,
        }
 }

-static bool arm_smmu_write_ste_next(struct arm_smmu_ste *cur,
-                                   const struct arm_smmu_ste *target,
-                                   const struct arm_smmu_ste *target_used)
+/*
+ * Make bits of the current ste that aren't in use by the hardware equal to the
+ * target's bits.
+ */
+static void arm_smmu_ste_set_unused_bits(
+                                  struct arm_smmu_ste *cur,
+                                  const struct arm_smmu_ste *target)
 {
        struct arm_smmu_ste cur_used;
-       struct arm_smmu_ste step;
+       int i =0;

        arm_smmu_get_ste_used(cur, &cur_used);
-       return arm_smmu_write_entry_next(cur->data, cur_used.data, target->data,
-                                        target_used->data, step.data,
-                                        cpu_to_le64(STRTAB_STE_0_V),
-                                        ARRAY_SIZE(cur->data));
+       for (i = 0; i < ARRAY_SIZE(cur->data); i++)
+               cur->data[i] = (cur->data[i] & cur_used.data[i]) |
+                              (target->data[i] & ~cur_used.data[i]);
 }

+/*
+ * Update the STE to the target configuration. The transition from the current
+ * STE to the target STE takes place over multiple steps that attempts to make
+ * the transition hitless if possible. This function takes care not to create a
+ * situation where the HW can perceive a corrupted entry. HW is only
required to
+ * have a 64 bit atomicity with stores from the CPU, while entries are many 64
+ * bit values big.
+ *
+ * The algorithm works by evolving the entry toward the target in a series of
+ * steps. Each step synchronizes with the HW so that the HW can not
see an entry
+ * torn across two steps. During each step the HW can observe a torn entry that
+ * has any combination of the step's old/new 64 bit words. The algorithm
+ * objective is for the HW behavior to always be one of current behavior, V=0,
+ * or new behavior.
+ *
+ * In the most general case we can make any update in three steps:
+ *  - Disrupting the entry (V=0)
+ *  - Fill now unused bits, all bits except V
+ *  - Make valid (V=1), single 64 bit store
+ *
+ * However this disrupts the HW while it is happening. There are several
+ * interesting cases where a STE/CD can be updated without disturbing the HW
+ * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
+ * because the used bits don't intersect. We can detect this by calculating how
+ * many 64 bit values need update after adjusting the unused bits and skip the
+ * V=0 process. This relies on the IGNORED behavior described in the
+ * specification
+ */
 static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
                               struct arm_smmu_ste *ste,
                               const struct arm_smmu_ste *target)
 {
+       struct arm_smmu_ste staging_ste;
        struct arm_smmu_ste target_used;
-       int i;
+       int writes_required = 0;
+       u8 staging_used_diff = 0;
+       int i = 0;

+       /*
+        * Compute a staging ste that has all the bits currently unused by HW
+        * set to their target values, such that comitting it to the ste table
+        * woudn't disrupt the hardware.
+        */
+       memcpy(&staging_ste, ste, sizeof(staging_ste));
+       arm_smmu_ste_set_unused_bits(&staging_ste, target);
+
+       /*
+        * Determine if it's possible to reach the target configuration from the
+        * staged configured in a single qword write (ignoring bits that are
+        * unused under the target configuration).
+        */
        arm_smmu_get_ste_used(target, &target_used);
-       /* Masks in arm_smmu_get_ste_used() are up to date */
-       for (i = 0; i != ARRAY_SIZE(target->data); i++)
-               WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);
+       /*
+        * But first sanity check that masks in arm_smmu_get_ste_used() are up
+        * to date.
+        */
+       for (i = 0; i != ARRAY_SIZE(target->data); i++) {
+               if (WARN_ON_ONCE(target->data[i] & ~target_used.data[i]))
+                       target_used.data[i] |= target->data[i];
+       }

-       for (i = 0; true; i++) {
-               if (arm_smmu_write_ste_next(ste, target, &target_used))
-                       break;
-               arm_smmu_sync_ste_for_sid(smmu, sid);
-               if (WARN_ON(i == 4))
-                       break;
+       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++) {
+               /*
+                * Each bit of staging_used_diff indicates the index of a qword
+                * within the staged ste that is incorrect compared to the
+                * target, considering only the used bits in the target
+                */
+               if ((staging_ste.data[i] &
+                   target_used.data[i]) != (target->data[i]))
+                       staging_used_diff |= 1 << i;
+       }
+       if (hweight8(staging_used_diff) > 1) {
+               /*
+                * More than 1 qword is mismatched and a hitless transition from
+                * the current ste to the target ste is not possible. Clear the
+                * V bit and recompute the staging STE.
+                * Because the V bit is cleared, the staging STE will be equal
+                * to the target STE except for the first qword.
+                */
+               staging_ste.data[0] &= ~cpu_to_le64(STRTAB_STE_0_V);
+               arm_smmu_ste_set_unused_bits(&staging_ste, target);
+               staging_used_diff = 1;
+       }
+
+       /*
+        * Commit the staging STE.
+        */
+       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++)
+               WRITE_ONCE(ste->data[i], staging_ste.data[i]);
+       arm_smmu_sync_ste_for_sid(smmu, sid);
+
+       /*
+        * It's now possible to switch to the target configuration with a write
+        * to a single qword. Make that switch now.
+        */
+       i = ffs(staging_used_diff) - 1;
+       WRITE_ONCE(ste->data[i], target->data[i]);
+       arm_smmu_sync_ste_for_sid(smmu, sid);
+
+       /*
+        * Some of the bits set under the previous configuration but unused
+        * under the target configuration might still bit set. Clear them as
+        * well. Technically this isn't necessary but it brings the entry to
+        * the full target state, so if there are bugs in the mask calculation
+        * this will obscure them.
+        */
+       for (i = 0; i != ARRAY_SIZE(ste->data); i++) {
+               if (ste->data[i] != target->data[i]) {
+                       WRITE_ONCE(ste->data[i], target->data[i]);
+               }
        }
+       arm_smmu_sync_ste_for_sid(smmu, sid);

        /* It's likely that we'll want to use the new STE soon */
        if (!(smmu->options & ARM_SMMU_OPT_SKIP_PREFETCH)) {


From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:40 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:40 +0200
Subject: [PATCH v3 1/9] dt-bindings: net: starfive,jh7110-dwmac: Drop redundant reset description
In-Reply-To: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231215204050.2296404-2-cristian.ciocaltea@collabora.com>

The reset description items are already provided by the referenced
snps,dwmac.yaml schema, hence replace them with the necessary
{min,max}Items.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../devicetree/bindings/net/starfive,jh7110-dwmac.yaml       | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 5e7cfbbebce6..d90cb82c1424 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -55,9 +55,8 @@ properties:
     maxItems: 3
 
   resets:
-    items:
-      - description: MAC Reset signal.
-      - description: AHB Reset signal.
+    minItems: 2
+    maxItems: 2
 
   reset-names:
     items:
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:39 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:39 +0200
Subject: [PATCH v3 0/9] Enable networking support for StarFive JH7100 SoC
Message-ID: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>

This patch series adds ethernet support for the StarFive JH7100 SoC and makes it
available for the StarFive VisionFive V1 and BeagleV Starlight boards, although
I could only validate on the former SBC.  Thank you Emil and Geert for helping
with tests on BeagleV!

The work is heavily based on the reference implementation [1] and depends the
SiFive Composable Cache controller and non-coherent DMA support provided by Emil
via [2] and [3].

*Update*: as of next-20231214, all dependencies have been merged.

[1] https://github.com/starfive-tech/linux/commits/visionfive
[2] https://lore.kernel.org/all/CAJM55Z_pdoGxRXbmBgJ5GbVWyeM1N6+LHihbNdT26Oo_qA5VYA at mail.gmail.com/
[3] https://lore.kernel.org/all/20231130151932.729708-1-emil.renner.berthing at canonical.com/

Changes in v3:
 - Rebased series onto next-20231214 and dropped the ccache & DMA coherency
   related patches (v2 06-08/12) handled by Emil via [3]
 - Squashed PATCH v2 01/12 into PATCH v3 2/9, per Krzysztof's review
 - Dropped incorrect PATCH v2 02/12
 - Incorporated Emil's feedback; also added his Co-developed-by on all dts
   patches
 - Documented the need of adjusting RX internal delay in PATCH v3 8/9, per
   Andrew's request
 - Added clock fixes from Emil (PATCH v3 8-9/9) required to support 10/100Mb
   link speeds
 - v2:
   https://lore.kernel.org/lkml/20231029042712.520010-1-cristian.ciocaltea at collabora.com/

Changes in v2:
 - Dropped ccache PATCH 01-05 reworked by Emil via [2]
 - Dropped already applied PATCH 06/12
 - Added PATCH v2 01 to prepare snps-dwmac binding for JH7100 support
 - Added PATCH v2 02-03 to provide some jh7110-dwmac binding optimizations
 - Handled JH7110 conflicting work in PATCH 07 via PATCH v2 04
 - Reworked PATCH 8 via PATCH v2 05, adding JH7100 quirk and dropped
   starfive,gtxclk-dlychain DT property; also fixed register naming
 - Added PATCH v2 08 providing DMA coherency related DT changes
 - Updated PATCH 9 commit msg:
   s/OF_DMA_DEFAULT_COHERENT/ARCH_DMA_DEFAULT_COHERENT/
 - Replaced 'uncached-offset' property with 'sifive,cache-ops' in PATCH 10/12
   and dropped 'sideband' reg
 - Add new patch providing coherent DMA memory pool (PATCH v2 10)
 - Updated PATCH 11/12 according to the stmmac glue layer changes in upstream
 - Split PATCH 12/12 into PATCH v2 10-12 to handle individual gmac setup of
   VisionFive v1 and BeagleV boards as they use different PHYs; also switched
   phy-mode from "rgmii-tx" to "rgmii-id" (requires a reduction of
   rx-internal-delay-ps by ~50%)
 - Rebased series onto next-20231024
 - v1:
   https://lore.kernel.org/lkml/20230211031821.976408-1-cristian.ciocaltea at collabora.com/

Cristian Ciocaltea (7):
  dt-bindings: net: starfive,jh7110-dwmac: Drop redundant reset
    description
  dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
  net: stmmac: dwmac-starfive: Add support for JH7100 SoC
  riscv: dts: starfive: jh7100: Add sysmain and gmac DT nodes
  riscv: dts: starfive: jh7100-common: Setup pinmux and enable gmac
  riscv: dts: starfive: visionfive-v1: Setup ethernet phy
  riscv: dts: starfive: beaglev-starlight: Setup phy reset gpio

Emil Renner Berthing (2):
  clk: starfive: Add flags argument to JH71X0__MUX macro
  clk: starfive: jh7100: Add CLK_SET_RATE_PARENT to gmac_tx

 .../devicetree/bindings/net/snps,dwmac.yaml   |  3 +-
 .../bindings/net/starfive,jh7110-dwmac.yaml   | 75 +++++++++++-----
 .../dts/starfive/jh7100-beaglev-starlight.dts |  7 ++
 .../boot/dts/starfive/jh7100-common.dtsi      | 85 +++++++++++++++++++
 .../jh7100-starfive-visionfive-v1.dts         |  7 ++
 arch/riscv/boot/dts/starfive/jh7100.dtsi      | 37 ++++++++
 .../clk/starfive/clk-starfive-jh7100-audio.c  |  2 +-
 drivers/clk/starfive/clk-starfive-jh7100.c    | 32 +++----
 .../clk/starfive/clk-starfive-jh7110-aon.c    |  6 +-
 .../clk/starfive/clk-starfive-jh7110-isp.c    |  2 +-
 .../clk/starfive/clk-starfive-jh7110-sys.c    | 26 +++---
 drivers/clk/starfive/clk-starfive-jh71x0.h    |  4 +-
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 +-
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 ++++++-
 14 files changed, 258 insertions(+), 66 deletions(-)

-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:41 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:41 +0200
Subject: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
In-Reply-To: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>

The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
similar to the newer JH7110, but it requires only two interrupts and a
single reset line, which is 'ahb' instead of the commonly used
'stmmaceth'.

Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
conjunction with 'stmmaceth', extend the logic to also permit exclusive
usage of the 'ahb' reset name.  This ensures the following use cases are
supported:

  JH7110: reset-names = "stmmaceth", "ahb";
  JH7100: reset-names = "ahb";
  other:  reset-names = "stmmaceth";

Also note the need to use a different dwmac fallback, as v5.20 applies
to JH7110 only, while JH7100 relies on v3.7x.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../devicetree/bindings/net/snps,dwmac.yaml   |  3 +-
 .../bindings/net/starfive,jh7110-dwmac.yaml   | 74 +++++++++++++------
 2 files changed, 55 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 5c2769dc689a..c1380ff1c054 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -95,6 +95,7 @@ properties:
         - snps,dwmac-5.20
         - snps,dwxgmac
         - snps,dwxgmac-2.10
+        - starfive,jh7100-dwmac
         - starfive,jh7110-dwmac
 
   reg:
@@ -146,7 +147,7 @@ properties:
   reset-names:
     minItems: 1
     items:
-      - const: stmmaceth
+      - enum: [stmmaceth, ahb]
       - const: ahb
 
   power-domains:
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index d90cb82c1424..b01602738fc3 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -22,10 +22,14 @@ select:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - starfive,jh7110-dwmac
-      - const: snps,dwmac-5.20
+    oneOf:
+      - items:
+          - const: starfive,jh7100-dwmac
+          - const: snps,dwmac
+      - items:
+          - enum:
+              - starfive,jh7110-dwmac
+          - const: snps,dwmac-5.20
 
   reg:
     maxItems: 1
@@ -46,23 +50,6 @@ properties:
       - const: tx
       - const: gtx
 
-  interrupts:
-    minItems: 3
-    maxItems: 3
-
-  interrupt-names:
-    minItems: 3
-    maxItems: 3
-
-  resets:
-    minItems: 2
-    maxItems: 2
-
-  reset-names:
-    items:
-      - const: stmmaceth
-      - const: ahb
-
   starfive,tx-use-rgmii-clk:
     description:
       Tx clock is provided by external rgmii clock.
@@ -93,6 +80,51 @@ required:
 allOf:
   - $ref: snps,dwmac.yaml#
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: starfive,jh7100-dwmac
+    then:
+      properties:
+        interrupts:
+          minItems: 2
+          maxItems: 2
+
+        interrupt-names:
+          minItems: 2
+          maxItems: 2
+
+        resets:
+          maxItems: 1
+
+        reset-names:
+          const: ahb
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: starfive,jh7110-dwmac
+    then:
+      properties:
+        interrupts:
+          minItems: 3
+          maxItems: 3
+
+        interrupt-names:
+          minItems: 3
+          maxItems: 3
+
+        resets:
+          minItems: 2
+          maxItems: 2
+
+        reset-names:
+          items:
+            - const: stmmaceth
+            - const: ahb
+
 unevaluatedProperties: false
 
 examples:
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:42 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:42 +0200
Subject: [PATCH v3 3/9] net: stmmac: dwmac-starfive: Add support for JH7100 SoC
In-Reply-To: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231215204050.2296404-4-cristian.ciocaltea@collabora.com>

Add a missing quirk to enable support for the StarFive JH7100 SoC.

Additionally, for greater flexibility in operation, allow using the
rgmii-rxid and rgmii-txid phy modes.

Co-developed-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 ++--
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 ++++++++++++++++---
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 85dcda51df05..4ec61f1ee71a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -165,9 +165,9 @@ config DWMAC_STARFIVE
 	help
 	  Support for ethernet controllers on StarFive RISC-V SoCs
 
-	  This selects the StarFive platform specific glue layer support for
-	  the stmmac device driver. This driver is used for StarFive JH7110
-	  ethernet controller.
+	  This selects the StarFive platform specific glue layer support
+	  for the stmmac device driver. This driver is used for the
+	  StarFive JH7100 and JH7110 ethernet controllers.
 
 config DWMAC_STI
 	tristate "STi GMAC support"
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 5d630affb4d1..4e1076faee0c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -15,13 +15,20 @@
 
 #include "stmmac_platform.h"
 
-#define STARFIVE_DWMAC_PHY_INFT_RGMII	0x1
-#define STARFIVE_DWMAC_PHY_INFT_RMII	0x4
-#define STARFIVE_DWMAC_PHY_INFT_FIELD	0x7U
+#define STARFIVE_DWMAC_PHY_INFT_RGMII		0x1
+#define STARFIVE_DWMAC_PHY_INFT_RMII		0x4
+#define STARFIVE_DWMAC_PHY_INFT_FIELD		0x7U
+
+#define JH7100_SYSMAIN_REGISTER49_DLYCHAIN	0xc8
+
+struct starfive_dwmac_data {
+	unsigned int gtxclk_dlychain;
+};
 
 struct starfive_dwmac {
 	struct device *dev;
 	struct clk *clk_tx;
+	const struct starfive_dwmac_data *data;
 };
 
 static void starfive_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode)
@@ -67,6 +74,8 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 
 	case PHY_INTERFACE_MODE_RGMII:
 	case PHY_INTERFACE_MODE_RGMII_ID:
+	case PHY_INTERFACE_MODE_RGMII_RXID:
+	case PHY_INTERFACE_MODE_RGMII_TXID:
 		mode = STARFIVE_DWMAC_PHY_INFT_RGMII;
 		break;
 
@@ -89,6 +98,14 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 	if (err)
 		return dev_err_probe(dwmac->dev, err, "error setting phy mode\n");
 
+	if (dwmac->data) {
+		err = regmap_write(regmap, JH7100_SYSMAIN_REGISTER49_DLYCHAIN,
+				   dwmac->data->gtxclk_dlychain);
+		if (err)
+			return dev_err_probe(dwmac->dev, err,
+					     "error selecting gtxclk delay chain\n");
+	}
+
 	return 0;
 }
 
@@ -114,6 +131,8 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	if (!dwmac)
 		return -ENOMEM;
 
+	dwmac->data = device_get_match_data(&pdev->dev);
+
 	dwmac->clk_tx = devm_clk_get_enabled(&pdev->dev, "tx");
 	if (IS_ERR(dwmac->clk_tx))
 		return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_tx),
@@ -144,8 +163,13 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
 }
 
+static const struct starfive_dwmac_data jh7100_data = {
+	.gtxclk_dlychain = 4,
+};
+
 static const struct of_device_id starfive_dwmac_match[] = {
-	{ .compatible = "starfive,jh7110-dwmac"	},
+	{ .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
+	{ .compatible = "starfive,jh7110-dwmac" },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:43 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:43 +0200
Subject: [PATCH v3 4/9] riscv: dts: starfive: jh7100: Add sysmain and gmac DT nodes
In-Reply-To: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231215204050.2296404-5-cristian.ciocaltea@collabora.com>

Provide the sysmain and gmac DT nodes supporting the DWMAC found on the
StarFive JH7100 SoC.

Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 arch/riscv/boot/dts/starfive/jh7100.dtsi | 37 ++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/riscv/boot/dts/starfive/jh7100.dtsi b/arch/riscv/boot/dts/starfive/jh7100.dtsi
index c216aaecac53..985383745e77 100644
--- a/arch/riscv/boot/dts/starfive/jh7100.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7100.dtsi
@@ -204,6 +204,38 @@ sdio1: mmc at 10010000 {
 			status = "disabled";
 		};
 
+		gmac: ethernet at 10020000 {
+			compatible = "starfive,jh7100-dwmac", "snps,dwmac";
+			reg = <0x0 0x10020000 0x0 0x10000>;
+			clocks = <&clkgen JH7100_CLK_GMAC_ROOT_DIV>,
+				 <&clkgen JH7100_CLK_GMAC_AHB>,
+				 <&clkgen JH7100_CLK_GMAC_PTP_REF>,
+				 <&clkgen JH7100_CLK_GMAC_TX_INV>,
+				 <&clkgen JH7100_CLK_GMAC_GTX>;
+			clock-names = "stmmaceth", "pclk", "ptp_ref", "tx", "gtx";
+			resets = <&rstgen JH7100_RSTN_GMAC_AHB>;
+			reset-names = "ahb";
+			interrupts = <6>, <7>;
+			interrupt-names = "macirq", "eth_wake_irq";
+			max-frame-size = <9000>;
+			snps,multicast-filter-bins = <32>;
+			snps,perfect-filter-entries = <128>;
+			starfive,syscon = <&sysmain 0x70 0>;
+			rx-fifo-depth = <32768>;
+			tx-fifo-depth = <16384>;
+			snps,axi-config = <&stmmac_axi_setup>;
+			snps,fixed-burst;
+			snps,force_thresh_dma_mode;
+			snps,no-pbl-x8;
+			status = "disabled";
+
+			stmmac_axi_setup: stmmac-axi-config {
+				snps,wr_osr_lmt = <16>;
+				snps,rd_osr_lmt = <16>;
+				snps,blen = <256 128 64 32 0 0 0>;
+			};
+		};
+
 		clkgen: clock-controller at 11800000 {
 			compatible = "starfive,jh7100-clkgen";
 			reg = <0x0 0x11800000 0x0 0x10000>;
@@ -218,6 +250,11 @@ rstgen: reset-controller at 11840000 {
 			#reset-cells = <1>;
 		};
 
+		sysmain: syscon at 11850000 {
+			compatible = "starfive,jh7100-sysmain", "syscon";
+			reg = <0x0 0x11850000 0x0 0x10000>;
+		};
+
 		i2c0: i2c at 118b0000 {
 			compatible = "snps,designware-i2c";
 			reg = <0x0 0x118b0000 0x0 0x10000>;
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:46 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:46 +0200
Subject: [PATCH v3 7/9] riscv: dts: starfive: beaglev-starlight: Setup phy reset gpio
In-Reply-To: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231215204050.2296404-8-cristian.ciocaltea@collabora.com>

The BeagleV Starlight SBC uses a Microchip KSZ9031RNXCA PHY supporting
RGMII-ID which doesn't require any particular setup, other than defining
a reset gpio, as opposed to VisionFive V1 for which the RX internal
delay had to be adjusted.

Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts b/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
index 7cda3a89020a..5ac9961226fc 100644
--- a/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
+++ b/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
@@ -11,3 +11,10 @@ / {
 	model = "BeagleV Starlight Beta";
 	compatible = "beagle,beaglev-starlight-jh7100-r0", "starfive,jh7100";
 };
+
+&mdio {
+	phy: ethernet-phy at 7 {
+		reg = <7>;
+		reset-gpios = <&gpio 63 GPIO_ACTIVE_LOW>;
+	};
+};
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:45 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:45 +0200
Subject: [PATCH v3 6/9] riscv: dts: starfive: visionfive-v1: Setup ethernet phy
In-Reply-To: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231215204050.2296404-7-cristian.ciocaltea@collabora.com>

The StarFive VisionFive V1 SBC uses a Motorcomm YT8521 PHY supporting
RGMII-ID, but requires manual adjustment of the RX internal delay to
work properly.

The default RX delay provided by the driver is 1.95 ns, which proves to
be too high. Applying a 50% reduction seems to mitigate the issue.

Also note this adjustment is not necessary on BeagleV Starlight SBC,
which uses a Microchip PHY.  Hence, there is no indication of a
miss-behaviour on the GMAC side, but most likely the issue stems from
the Motorcomm PHY.

Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../boot/dts/starfive/jh7100-starfive-visionfive-v1.dts    | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts b/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts
index e82af72f1aaf..ca134b9f11bf 100644
--- a/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts
+++ b/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts
@@ -18,3 +18,10 @@ gpio-restart {
 		priority = <224>;
 	};
 };
+
+&mdio {
+	phy: ethernet-phy at 0 {
+		reg = <0>;
+		rx-internal-delay-ps = <900>;
+	};
+};
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:44 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:44 +0200
Subject: [PATCH v3 5/9] riscv: dts: starfive: jh7100-common: Setup pinmux and enable gmac
In-Reply-To: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231215204050.2296404-6-cristian.ciocaltea@collabora.com>

Add pinmux configuration for DWMAC found on the JH7100 based boards and
enable the related DT node, providing a basic PHY configuration.

Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../boot/dts/starfive/jh7100-common.dtsi      | 85 +++++++++++++++++++
 1 file changed, 85 insertions(+)

diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
index 42fb61c36068..5cafe8f5c2e7 100644
--- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
@@ -72,7 +72,92 @@ wifi_pwrseq: wifi-pwrseq {
 	};
 };
 
+&gmac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac_pins>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&phy>;
+	status = "okay";
+
+	mdio: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+	};
+};
+
 &gpio {
+	gmac_pins: gmac-0 {
+		gtxclk-pins {
+			pins = <PAD_FUNC_SHARE(115)>;
+			bias-pull-up;
+			drive-strength = <35>;
+			input-enable;
+			input-schmitt-enable;
+			slew-rate = <0>;
+		};
+		miitxclk-pins {
+			pins = <PAD_FUNC_SHARE(116)>;
+			bias-pull-up;
+			drive-strength = <14>;
+			input-enable;
+			input-schmitt-disable;
+			slew-rate = <0>;
+		};
+		tx-pins {
+			pins = <PAD_FUNC_SHARE(117)>,
+			       <PAD_FUNC_SHARE(119)>,
+			       <PAD_FUNC_SHARE(120)>,
+			       <PAD_FUNC_SHARE(121)>,
+			       <PAD_FUNC_SHARE(122)>,
+			       <PAD_FUNC_SHARE(123)>,
+			       <PAD_FUNC_SHARE(124)>,
+			       <PAD_FUNC_SHARE(125)>,
+			       <PAD_FUNC_SHARE(126)>;
+			bias-pull-up;
+			drive-strength = <35>;
+			input-disable;
+			input-schmitt-disable;
+			slew-rate = <0>;
+		};
+		rxclk-pins {
+			pins = <PAD_FUNC_SHARE(127)>;
+			bias-pull-up;
+			drive-strength = <14>;
+			input-enable;
+			input-schmitt-disable;
+			slew-rate = <6>;
+		};
+		rxer-pins {
+			pins = <PAD_FUNC_SHARE(129)>;
+			bias-pull-up;
+			drive-strength = <14>;
+			input-enable;
+			input-schmitt-disable;
+			slew-rate = <0>;
+		};
+		rx-pins {
+			pins = <PAD_FUNC_SHARE(128)>,
+			       <PAD_FUNC_SHARE(130)>,
+			       <PAD_FUNC_SHARE(131)>,
+			       <PAD_FUNC_SHARE(132)>,
+			       <PAD_FUNC_SHARE(133)>,
+			       <PAD_FUNC_SHARE(134)>,
+			       <PAD_FUNC_SHARE(135)>,
+			       <PAD_FUNC_SHARE(136)>,
+			       <PAD_FUNC_SHARE(137)>,
+			       <PAD_FUNC_SHARE(138)>,
+			       <PAD_FUNC_SHARE(139)>,
+			       <PAD_FUNC_SHARE(140)>,
+			       <PAD_FUNC_SHARE(141)>;
+			bias-pull-up;
+			drive-strength = <14>;
+			input-enable;
+			input-schmitt-enable;
+			slew-rate = <0>;
+		};
+	};
+
 	i2c0_pins: i2c0-0 {
 		i2c-pins {
 			pinmux = <GPIOMUX(62, GPO_LOW,
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:48 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:48 +0200
Subject: [PATCH v3 9/9] clk: starfive: jh7100: Add CLK_SET_RATE_PARENT to gmac_tx
In-Reply-To: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231215204050.2296404-10-cristian.ciocaltea@collabora.com>

From: Emil Renner Berthing <emil.renner.berthing at canonical.com>

This is needed by the dwmac-starfive ethernet driver to set the clock
for 1000, 100 and 10 Mbps links properly.

Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 drivers/clk/starfive/clk-starfive-jh7100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/starfive/clk-starfive-jh7100.c b/drivers/clk/starfive/clk-starfive-jh7100.c
index d3b260c01d5c..03f6f26a15d8 100644
--- a/drivers/clk/starfive/clk-starfive-jh7100.c
+++ b/drivers/clk/starfive/clk-starfive-jh7100.c
@@ -200,7 +200,7 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0_GDIV(JH7100_CLK_GMAC_GTX, "gmac_gtxclk", 0, 255, JH7100_CLK_GMAC_ROOT_DIV),
 	JH71X0_GDIV(JH7100_CLK_GMAC_RMII_TX, "gmac_rmii_txclk", 0, 8, JH7100_CLK_GMAC_RMII_REF),
 	JH71X0_GDIV(JH7100_CLK_GMAC_RMII_RX, "gmac_rmii_rxclk", 0, 8, JH7100_CLK_GMAC_RMII_REF),
-	JH71X0__MUX(JH7100_CLK_GMAC_TX, "gmac_tx", 0, 3,
+	JH71X0__MUX(JH7100_CLK_GMAC_TX, "gmac_tx", CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT, 3,
 		    JH7100_CLK_GMAC_GTX,
 		    JH7100_CLK_GMAC_TX_INV,
 		    JH7100_CLK_GMAC_RMII_TX),
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:40:47 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:40:47 +0200
Subject: [PATCH v3 8/9] clk: starfive: Add flags argument to JH71X0__MUX macro
In-Reply-To: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231215204050.2296404-9-cristian.ciocaltea@collabora.com>

From: Emil Renner Berthing <emil.renner.berthing at canonical.com>

This flag is needed to add the CLK_SET_RATE_PARENT flag on the gmac_tx
clock on the JH7100, which in turn is needed by the dwmac-starfive
driver to set the clock properly for 1000, 100 and 10 Mbps links.

This change was mostly made using coccinelle:

@ match @
expression idx, name, nparents;
@@
 JH71X0__MUX(
-idx, name, nparents,
+idx, name, 0, nparents,
 ...)

Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../clk/starfive/clk-starfive-jh7100-audio.c  |  2 +-
 drivers/clk/starfive/clk-starfive-jh7100.c    | 32 +++++++++----------
 .../clk/starfive/clk-starfive-jh7110-aon.c    |  6 ++--
 .../clk/starfive/clk-starfive-jh7110-isp.c    |  2 +-
 .../clk/starfive/clk-starfive-jh7110-sys.c    | 26 +++++++--------
 drivers/clk/starfive/clk-starfive-jh71x0.h    |  4 +--
 6 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/clk/starfive/clk-starfive-jh7100-audio.c b/drivers/clk/starfive/clk-starfive-jh7100-audio.c
index ee4bda14a40e..1fcf4e62f347 100644
--- a/drivers/clk/starfive/clk-starfive-jh7100-audio.c
+++ b/drivers/clk/starfive/clk-starfive-jh7100-audio.c
@@ -79,7 +79,7 @@ static const struct jh71x0_clk_data jh7100_audclk_data[] = {
 	JH71X0_GDIV(JH7100_AUDCLK_USB_LPM, "usb_lpm", CLK_IGNORE_UNUSED, 4, JH7100_AUDCLK_USB_APB),
 	JH71X0_GDIV(JH7100_AUDCLK_USB_STB, "usb_stb", CLK_IGNORE_UNUSED, 3, JH7100_AUDCLK_USB_APB),
 	JH71X0__DIV(JH7100_AUDCLK_APB_EN, "apb_en", 8, JH7100_AUDCLK_DOM7AHB_BUS),
-	JH71X0__MUX(JH7100_AUDCLK_VAD_MEM, "vad_mem", 2,
+	JH71X0__MUX(JH7100_AUDCLK_VAD_MEM, "vad_mem", 0, 2,
 		    JH7100_AUDCLK_VAD_INTMEM,
 		    JH7100_AUDCLK_AUDIO_12288),
 };
diff --git a/drivers/clk/starfive/clk-starfive-jh7100.c b/drivers/clk/starfive/clk-starfive-jh7100.c
index 69cc11ea7e33..d3b260c01d5c 100644
--- a/drivers/clk/starfive/clk-starfive-jh7100.c
+++ b/drivers/clk/starfive/clk-starfive-jh7100.c
@@ -24,48 +24,48 @@
 #define JH7100_CLK_GMAC_GR_MII_RX	(JH7100_CLK_END + 3)
 
 static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
-	JH71X0__MUX(JH7100_CLK_CPUNDBUS_ROOT, "cpundbus_root", 4,
+	JH71X0__MUX(JH7100_CLK_CPUNDBUS_ROOT, "cpundbus_root", 0, 4,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_DLA_ROOT, "dla_root", 3,
+	JH71X0__MUX(JH7100_CLK_DLA_ROOT, "dla_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_DSP_ROOT, "dsp_root", 4,
+	JH71X0__MUX(JH7100_CLK_DSP_ROOT, "dsp_root", 0, 4,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_GMACUSB_ROOT, "gmacusb_root", 3,
+	JH71X0__MUX(JH7100_CLK_GMACUSB_ROOT, "gmacusb_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_PERH0_ROOT, "perh0_root", 2,
+	JH71X0__MUX(JH7100_CLK_PERH0_ROOT, "perh0_root", 0, 2,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT),
-	JH71X0__MUX(JH7100_CLK_PERH1_ROOT, "perh1_root", 2,
+	JH71X0__MUX(JH7100_CLK_PERH1_ROOT, "perh1_root", 0, 2,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_VIN_ROOT, "vin_root", 3,
+	JH71X0__MUX(JH7100_CLK_VIN_ROOT, "vin_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_VOUT_ROOT, "vout_root", 3,
+	JH71X0__MUX(JH7100_CLK_VOUT_ROOT, "vout_root", 0, 3,
 		    JH7100_CLK_OSC_AUD,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL2_OUT),
 	JH71X0_GDIV(JH7100_CLK_AUDIO_ROOT, "audio_root", 0, 8, JH7100_CLK_PLL0_OUT),
-	JH71X0__MUX(JH7100_CLK_CDECHIFI4_ROOT, "cdechifi4_root", 3,
+	JH71X0__MUX(JH7100_CLK_CDECHIFI4_ROOT, "cdechifi4_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_CDEC_ROOT, "cdec_root", 3,
+	JH71X0__MUX(JH7100_CLK_CDEC_ROOT, "cdec_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL1_OUT),
-	JH71X0__MUX(JH7100_CLK_VOUTBUS_ROOT, "voutbus_root", 3,
+	JH71X0__MUX(JH7100_CLK_VOUTBUS_ROOT, "voutbus_root", 0, 3,
 		    JH7100_CLK_OSC_AUD,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL2_OUT),
@@ -76,7 +76,7 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0_GDIV(JH7100_CLK_PLL0_TESTOUT, "pll0_testout", 0, 31, JH7100_CLK_PERH0_SRC),
 	JH71X0_GDIV(JH7100_CLK_PLL1_TESTOUT, "pll1_testout", 0, 31, JH7100_CLK_DLA_ROOT),
 	JH71X0_GDIV(JH7100_CLK_PLL2_TESTOUT, "pll2_testout", 0, 31, JH7100_CLK_PERH1_SRC),
-	JH71X0__MUX(JH7100_CLK_PLL2_REF, "pll2_refclk", 2,
+	JH71X0__MUX(JH7100_CLK_PLL2_REF, "pll2_refclk", 0, 2,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_OSC_AUD),
 	JH71X0__DIV(JH7100_CLK_CPU_CORE, "cpu_core", 8, JH7100_CLK_CPUNBUS_ROOT_DIV),
@@ -142,7 +142,7 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0__DIV(JH7100_CLK_NOC_COG, "noc_cog", 8, JH7100_CLK_DLA_ROOT),
 	JH71X0_GATE(JH7100_CLK_NNE_AHB, "nne_ahb", 0, JH7100_CLK_AHB_BUS),
 	JH71X0__DIV(JH7100_CLK_NNEBUS_SRC1, "nnebus_src1", 4, JH7100_CLK_DSP_ROOT),
-	JH71X0__MUX(JH7100_CLK_NNE_BUS, "nne_bus", 2,
+	JH71X0__MUX(JH7100_CLK_NNE_BUS, "nne_bus", 0, 2,
 		    JH7100_CLK_CPU_AXI,
 		    JH7100_CLK_NNEBUS_SRC1),
 	JH71X0_GATE(JH7100_CLK_NNE_AXI, "nne_axi", 0, JH7100_CLK_NNE_BUS),
@@ -166,7 +166,7 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0_GDIV(JH7100_CLK_USBPHY_125M, "usbphy_125m", 0, 8, JH7100_CLK_USBPHY_ROOTDIV),
 	JH71X0_GDIV(JH7100_CLK_USBPHY_PLLDIV25M, "usbphy_plldiv25m", 0, 32,
 		    JH7100_CLK_USBPHY_ROOTDIV),
-	JH71X0__MUX(JH7100_CLK_USBPHY_25M, "usbphy_25m", 2,
+	JH71X0__MUX(JH7100_CLK_USBPHY_25M, "usbphy_25m", 0, 2,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_USBPHY_PLLDIV25M),
 	JH71X0_FDIV(JH7100_CLK_AUDIO_DIV, "audio_div", JH7100_CLK_AUDIO_ROOT),
@@ -200,12 +200,12 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0_GDIV(JH7100_CLK_GMAC_GTX, "gmac_gtxclk", 0, 255, JH7100_CLK_GMAC_ROOT_DIV),
 	JH71X0_GDIV(JH7100_CLK_GMAC_RMII_TX, "gmac_rmii_txclk", 0, 8, JH7100_CLK_GMAC_RMII_REF),
 	JH71X0_GDIV(JH7100_CLK_GMAC_RMII_RX, "gmac_rmii_rxclk", 0, 8, JH7100_CLK_GMAC_RMII_REF),
-	JH71X0__MUX(JH7100_CLK_GMAC_TX, "gmac_tx", 3,
+	JH71X0__MUX(JH7100_CLK_GMAC_TX, "gmac_tx", 0, 3,
 		    JH7100_CLK_GMAC_GTX,
 		    JH7100_CLK_GMAC_TX_INV,
 		    JH7100_CLK_GMAC_RMII_TX),
 	JH71X0__INV(JH7100_CLK_GMAC_TX_INV, "gmac_tx_inv", JH7100_CLK_GMAC_TX),
-	JH71X0__MUX(JH7100_CLK_GMAC_RX_PRE, "gmac_rx_pre", 2,
+	JH71X0__MUX(JH7100_CLK_GMAC_RX_PRE, "gmac_rx_pre", 0, 2,
 		    JH7100_CLK_GMAC_GR_MII_RX,
 		    JH7100_CLK_GMAC_RMII_RX),
 	JH71X0__INV(JH7100_CLK_GMAC_RX_INV, "gmac_rx_inv", JH7100_CLK_GMAC_RX_PRE),
diff --git a/drivers/clk/starfive/clk-starfive-jh7110-aon.c b/drivers/clk/starfive/clk-starfive-jh7110-aon.c
index 62954eb7b50a..418efdad719b 100644
--- a/drivers/clk/starfive/clk-starfive-jh7110-aon.c
+++ b/drivers/clk/starfive/clk-starfive-jh7110-aon.c
@@ -26,7 +26,7 @@
 static const struct jh71x0_clk_data jh7110_aonclk_data[] = {
 	/* source */
 	JH71X0__DIV(JH7110_AONCLK_OSC_DIV4, "osc_div4", 4, JH7110_AONCLK_OSC),
-	JH71X0__MUX(JH7110_AONCLK_APB_FUNC, "apb_func", 2,
+	JH71X0__MUX(JH7110_AONCLK_APB_FUNC, "apb_func", 0, 2,
 		    JH7110_AONCLK_OSC_DIV4,
 		    JH7110_AONCLK_OSC),
 	/* gmac0 */
@@ -39,7 +39,7 @@ static const struct jh71x0_clk_data jh7110_aonclk_data[] = {
 		    JH7110_AONCLK_GMAC0_GTXCLK,
 		    JH7110_AONCLK_GMAC0_RMII_RTX),
 	JH71X0__INV(JH7110_AONCLK_GMAC0_TX_INV, "gmac0_tx_inv", JH7110_AONCLK_GMAC0_TX),
-	JH71X0__MUX(JH7110_AONCLK_GMAC0_RX, "gmac0_rx", 2,
+	JH71X0__MUX(JH7110_AONCLK_GMAC0_RX, "gmac0_rx", 0, 2,
 		    JH7110_AONCLK_GMAC0_RGMII_RXIN,
 		    JH7110_AONCLK_GMAC0_RMII_RTX),
 	JH71X0__INV(JH7110_AONCLK_GMAC0_RX_INV, "gmac0_rx_inv", JH7110_AONCLK_GMAC0_RX),
@@ -48,7 +48,7 @@ static const struct jh71x0_clk_data jh7110_aonclk_data[] = {
 	/* rtc */
 	JH71X0_GATE(JH7110_AONCLK_RTC_APB, "rtc_apb", 0, JH7110_AONCLK_APB_BUS),
 	JH71X0__DIV(JH7110_AONCLK_RTC_INTERNAL, "rtc_internal", 1022, JH7110_AONCLK_OSC),
-	JH71X0__MUX(JH7110_AONCLK_RTC_32K, "rtc_32k", 2,
+	JH71X0__MUX(JH7110_AONCLK_RTC_32K, "rtc_32k", 0, 2,
 		    JH7110_AONCLK_RTC_OSC,
 		    JH7110_AONCLK_RTC_INTERNAL),
 	JH71X0_GATE(JH7110_AONCLK_RTC_CAL, "rtc_cal", 0, JH7110_AONCLK_OSC),
diff --git a/drivers/clk/starfive/clk-starfive-jh7110-isp.c b/drivers/clk/starfive/clk-starfive-jh7110-isp.c
index ce034ed28532..929b8788279e 100644
--- a/drivers/clk/starfive/clk-starfive-jh7110-isp.c
+++ b/drivers/clk/starfive/clk-starfive-jh7110-isp.c
@@ -53,7 +53,7 @@ static const struct jh71x0_clk_data jh7110_ispclk_data[] = {
 		    JH7110_ISPCLK_MIPI_RX0_PXL),
 	JH71X0_GATE(JH7110_ISPCLK_VIN_PIXEL_IF3, "vin_pixel_if3", 0,
 		    JH7110_ISPCLK_MIPI_RX0_PXL),
-	JH71X0__MUX(JH7110_ISPCLK_VIN_P_AXI_WR, "vin_p_axi_wr", 2,
+	JH71X0__MUX(JH7110_ISPCLK_VIN_P_AXI_WR, "vin_p_axi_wr", 0, 2,
 		    JH7110_ISPCLK_MIPI_RX0_PXL,
 		    JH7110_ISPCLK_DVP_INV),
 	/* ispv2_top_wrapper */
diff --git a/drivers/clk/starfive/clk-starfive-jh7110-sys.c b/drivers/clk/starfive/clk-starfive-jh7110-sys.c
index 3884eff9fe93..8f5e5abfa178 100644
--- a/drivers/clk/starfive/clk-starfive-jh7110-sys.c
+++ b/drivers/clk/starfive/clk-starfive-jh7110-sys.c
@@ -36,18 +36,18 @@
 
 static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	/* root */
-	JH71X0__MUX(JH7110_SYSCLK_CPU_ROOT, "cpu_root", 2,
+	JH71X0__MUX(JH7110_SYSCLK_CPU_ROOT, "cpu_root", 0, 2,
 		    JH7110_SYSCLK_OSC,
 		    JH7110_SYSCLK_PLL0_OUT),
 	JH71X0__DIV(JH7110_SYSCLK_CPU_CORE, "cpu_core", 7, JH7110_SYSCLK_CPU_ROOT),
 	JH71X0__DIV(JH7110_SYSCLK_CPU_BUS, "cpu_bus", 2, JH7110_SYSCLK_CPU_CORE),
-	JH71X0__MUX(JH7110_SYSCLK_GPU_ROOT, "gpu_root", 2,
+	JH71X0__MUX(JH7110_SYSCLK_GPU_ROOT, "gpu_root", 0, 2,
 		    JH7110_SYSCLK_PLL2_OUT,
 		    JH7110_SYSCLK_PLL1_OUT),
 	JH71X0_MDIV(JH7110_SYSCLK_PERH_ROOT, "perh_root", 2, 2,
 		    JH7110_SYSCLK_PLL0_OUT,
 		    JH7110_SYSCLK_PLL2_OUT),
-	JH71X0__MUX(JH7110_SYSCLK_BUS_ROOT, "bus_root", 2,
+	JH71X0__MUX(JH7110_SYSCLK_BUS_ROOT, "bus_root", 0, 2,
 		    JH7110_SYSCLK_OSC,
 		    JH7110_SYSCLK_PLL2_OUT),
 	JH71X0__DIV(JH7110_SYSCLK_NOCSTG_BUS, "nocstg_bus", 3, JH7110_SYSCLK_BUS_ROOT),
@@ -62,7 +62,7 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0__DIV(JH7110_SYSCLK_PLL2_DIV2, "pll2_div2", 2, JH7110_SYSCLK_PLL2_OUT),
 	JH71X0__DIV(JH7110_SYSCLK_AUDIO_ROOT, "audio_root", 8, JH7110_SYSCLK_PLL2_OUT),
 	JH71X0__DIV(JH7110_SYSCLK_MCLK_INNER, "mclk_inner", 64, JH7110_SYSCLK_AUDIO_ROOT),
-	JH71X0__MUX(JH7110_SYSCLK_MCLK, "mclk", 2,
+	JH71X0__MUX(JH7110_SYSCLK_MCLK, "mclk", 0, 2,
 		    JH7110_SYSCLK_MCLK_INNER,
 		    JH7110_SYSCLK_MCLK_EXT),
 	JH71X0_GATE(JH7110_SYSCLK_MCLK_OUT, "mclk_out", 0, JH7110_SYSCLK_MCLK_INNER),
@@ -96,7 +96,7 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0__DIV(JH7110_SYSCLK_OSC_DIV2, "osc_div2", 2, JH7110_SYSCLK_OSC),
 	JH71X0__DIV(JH7110_SYSCLK_PLL1_DIV4, "pll1_div4", 2, JH7110_SYSCLK_PLL1_DIV2),
 	JH71X0__DIV(JH7110_SYSCLK_PLL1_DIV8, "pll1_div8", 2, JH7110_SYSCLK_PLL1_DIV4),
-	JH71X0__MUX(JH7110_SYSCLK_DDR_BUS, "ddr_bus", 4,
+	JH71X0__MUX(JH7110_SYSCLK_DDR_BUS, "ddr_bus", 0, 4,
 		    JH7110_SYSCLK_OSC_DIV2,
 		    JH7110_SYSCLK_PLL1_DIV2,
 		    JH7110_SYSCLK_PLL1_DIV4,
@@ -186,7 +186,7 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0__DIV(JH7110_SYSCLK_GMAC1_RMII_RTX, "gmac1_rmii_rtx", 30,
 		    JH7110_SYSCLK_GMAC1_RMII_REFIN),
 	JH71X0_GDIV(JH7110_SYSCLK_GMAC1_PTP, "gmac1_ptp", 0, 31, JH7110_SYSCLK_GMAC_SRC),
-	JH71X0__MUX(JH7110_SYSCLK_GMAC1_RX, "gmac1_rx", 2,
+	JH71X0__MUX(JH7110_SYSCLK_GMAC1_RX, "gmac1_rx", 0, 2,
 		    JH7110_SYSCLK_GMAC1_RGMII_RXIN,
 		    JH7110_SYSCLK_GMAC1_RMII_RTX),
 	JH71X0__INV(JH7110_SYSCLK_GMAC1_RX_INV, "gmac1_rx_inv", JH7110_SYSCLK_GMAC1_RX),
@@ -270,11 +270,11 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0_MDIV(JH7110_SYSCLK_I2STX0_LRCK_MST, "i2stx0_lrck_mst", 64, 2,
 		    JH7110_SYSCLK_I2STX0_BCLK_MST_INV,
 		    JH7110_SYSCLK_I2STX0_BCLK_MST),
-	JH71X0__MUX(JH7110_SYSCLK_I2STX0_BCLK, "i2stx0_bclk",	2,
+	JH71X0__MUX(JH7110_SYSCLK_I2STX0_BCLK, "i2stx0_bclk", 0, 2,
 		    JH7110_SYSCLK_I2STX0_BCLK_MST,
 		    JH7110_SYSCLK_I2STX_BCLK_EXT),
 	JH71X0__INV(JH7110_SYSCLK_I2STX0_BCLK_INV, "i2stx0_bclk_inv", JH7110_SYSCLK_I2STX0_BCLK),
-	JH71X0__MUX(JH7110_SYSCLK_I2STX0_LRCK, "i2stx0_lrck", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2STX0_LRCK, "i2stx0_lrck", 0, 2,
 		    JH7110_SYSCLK_I2STX0_LRCK_MST,
 		    JH7110_SYSCLK_I2STX_LRCK_EXT),
 	/* i2stx1 */
@@ -285,11 +285,11 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0_MDIV(JH7110_SYSCLK_I2STX1_LRCK_MST, "i2stx1_lrck_mst", 64, 2,
 		    JH7110_SYSCLK_I2STX1_BCLK_MST_INV,
 		    JH7110_SYSCLK_I2STX1_BCLK_MST),
-	JH71X0__MUX(JH7110_SYSCLK_I2STX1_BCLK, "i2stx1_bclk", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2STX1_BCLK, "i2stx1_bclk", 0, 2,
 		    JH7110_SYSCLK_I2STX1_BCLK_MST,
 		    JH7110_SYSCLK_I2STX_BCLK_EXT),
 	JH71X0__INV(JH7110_SYSCLK_I2STX1_BCLK_INV, "i2stx1_bclk_inv", JH7110_SYSCLK_I2STX1_BCLK),
-	JH71X0__MUX(JH7110_SYSCLK_I2STX1_LRCK, "i2stx1_lrck", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2STX1_LRCK, "i2stx1_lrck", 0, 2,
 		    JH7110_SYSCLK_I2STX1_LRCK_MST,
 		    JH7110_SYSCLK_I2STX_LRCK_EXT),
 	/* i2srx */
@@ -300,11 +300,11 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0_MDIV(JH7110_SYSCLK_I2SRX_LRCK_MST, "i2srx_lrck_mst", 64, 2,
 		    JH7110_SYSCLK_I2SRX_BCLK_MST_INV,
 		    JH7110_SYSCLK_I2SRX_BCLK_MST),
-	JH71X0__MUX(JH7110_SYSCLK_I2SRX_BCLK, "i2srx_bclk", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2SRX_BCLK, "i2srx_bclk", 0, 2,
 		    JH7110_SYSCLK_I2SRX_BCLK_MST,
 		    JH7110_SYSCLK_I2SRX_BCLK_EXT),
 	JH71X0__INV(JH7110_SYSCLK_I2SRX_BCLK_INV, "i2srx_bclk_inv", JH7110_SYSCLK_I2SRX_BCLK),
-	JH71X0__MUX(JH7110_SYSCLK_I2SRX_LRCK, "i2srx_lrck", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2SRX_LRCK, "i2srx_lrck", 0, 2,
 		    JH7110_SYSCLK_I2SRX_LRCK_MST,
 		    JH7110_SYSCLK_I2SRX_LRCK_EXT),
 	/* pdm */
@@ -314,7 +314,7 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0_GATE(JH7110_SYSCLK_TDM_AHB, "tdm_ahb", 0, JH7110_SYSCLK_AHB0),
 	JH71X0_GATE(JH7110_SYSCLK_TDM_APB, "tdm_apb", 0, JH7110_SYSCLK_APB0),
 	JH71X0_GDIV(JH7110_SYSCLK_TDM_INTERNAL, "tdm_internal", 0, 64, JH7110_SYSCLK_MCLK),
-	JH71X0__MUX(JH7110_SYSCLK_TDM_TDM, "tdm_tdm", 2,
+	JH71X0__MUX(JH7110_SYSCLK_TDM_TDM, "tdm_tdm", 0, 2,
 		    JH7110_SYSCLK_TDM_INTERNAL,
 		    JH7110_SYSCLK_TDM_EXT),
 	JH71X0__INV(JH7110_SYSCLK_TDM_TDM_INV, "tdm_tdm_inv", JH7110_SYSCLK_TDM_TDM),
diff --git a/drivers/clk/starfive/clk-starfive-jh71x0.h b/drivers/clk/starfive/clk-starfive-jh71x0.h
index 34bb11c72eb7..23e052fc1549 100644
--- a/drivers/clk/starfive/clk-starfive-jh71x0.h
+++ b/drivers/clk/starfive/clk-starfive-jh71x0.h
@@ -61,10 +61,10 @@ struct jh71x0_clk_data {
 	.parents = { [0] = _parent },						\
 }
 
-#define JH71X0__MUX(_idx, _name, _nparents, ...)				\
+#define JH71X0__MUX(_idx, _name, _flags, _nparents, ...)			\
 [_idx] = {									\
 	.name = _name,								\
-	.flags = 0,								\
+	.flags = _flags,							\
 	.max = ((_nparents) - 1) << JH71X0_CLK_MUX_SHIFT,			\
 	.parents = { __VA_ARGS__ },						\
 }
-- 
2.43.0



From jrtc27 at jrtc27.com  Fri Dec 15 12:47:58 2023
From: jrtc27 at jrtc27.com (Jessica Clarke)
Date: Fri, 15 Dec 2023 20:47:58 +0000
Subject: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>
Message-ID: <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>

On 15 Dec 2023, at 20:40, Cristian Ciocaltea <cristian.ciocaltea at collabora.com> wrote:
> 
> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
> similar to the newer JH7110, but it requires only two interrupts and a
> single reset line, which is 'ahb' instead of the commonly used
> 'stmmaceth'.
> 
> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
> conjunction with 'stmmaceth', extend the logic to also permit exclusive
> usage of the 'ahb' reset name.  This ensures the following use cases are
> supported:
> 
>  JH7110: reset-names = "stmmaceth", "ahb";
>  JH7100: reset-names = "ahb";
>  other:  reset-names = "stmmaceth";
> 
> Also note the need to use a different dwmac fallback, as v5.20 applies
> to JH7110 only, while JH7100 relies on v3.7x.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
> ---
> .../devicetree/bindings/net/snps,dwmac.yaml   |  3 +-
> .../bindings/net/starfive,jh7110-dwmac.yaml   | 74 +++++++++++++------
> 2 files changed, 55 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 5c2769dc689a..c1380ff1c054 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -95,6 +95,7 @@ properties:
>         - snps,dwmac-5.20
>         - snps,dwxgmac
>         - snps,dwxgmac-2.10
> +        - starfive,jh7100-dwmac
>         - starfive,jh7110-dwmac
> 
>   reg:
> @@ -146,7 +147,7 @@ properties:
>   reset-names:
>     minItems: 1
>     items:
> -      - const: stmmaceth
> +      - enum: [stmmaceth, ahb]
>       - const: ahb

I?m not so well-versed in the YAML bindings, but would this not allow
reset-names = "ahb", "ahb"?

Jess



From cristian.ciocaltea at collabora.com  Fri Dec 15 12:56:54 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 22:56:54 +0200
Subject: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>
 <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>
Message-ID: <491f1a89-aabd-4c38-b33a-a298add1bdb3@collabora.com>

On 12/15/23 22:47, Jessica Clarke wrote:
> On 15 Dec 2023, at 20:40, Cristian Ciocaltea <cristian.ciocaltea at collabora.com> wrote:
>>
>> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
>> similar to the newer JH7110, but it requires only two interrupts and a
>> single reset line, which is 'ahb' instead of the commonly used
>> 'stmmaceth'.
>>
>> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
>> conjunction with 'stmmaceth', extend the logic to also permit exclusive
>> usage of the 'ahb' reset name.  This ensures the following use cases are
>> supported:
>>
>>  JH7110: reset-names = "stmmaceth", "ahb";
>>  JH7100: reset-names = "ahb";
>>  other:  reset-names = "stmmaceth";
>>
>> Also note the need to use a different dwmac fallback, as v5.20 applies
>> to JH7110 only, while JH7100 relies on v3.7x.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>> ---
>> .../devicetree/bindings/net/snps,dwmac.yaml   |  3 +-
>> .../bindings/net/starfive,jh7110-dwmac.yaml   | 74 +++++++++++++------
>> 2 files changed, 55 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> index 5c2769dc689a..c1380ff1c054 100644
>> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> @@ -95,6 +95,7 @@ properties:
>>         - snps,dwmac-5.20
>>         - snps,dwxgmac
>>         - snps,dwxgmac-2.10
>> +        - starfive,jh7100-dwmac
>>         - starfive,jh7110-dwmac
>>
>>   reg:
>> @@ -146,7 +147,7 @@ properties:
>>   reset-names:
>>     minItems: 1
>>     items:
>> -      - const: stmmaceth
>> +      - enum: [stmmaceth, ahb]
>>       - const: ahb
> 
> I?m not so well-versed in the YAML bindings, but would this not allow
> reset-names = "ahb", "ahb"?

Yes, as I already pointed out in [1], I wasn't able to come up with a
proper solution to avoid that.

Thanks,
Cristian

> Jess
> 


From samuel.holland at sifive.com  Fri Dec 15 12:59:17 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Fri, 15 Dec 2023 14:59:17 -0600
Subject: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>
 <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>
Message-ID: <65fd52f1-6861-42b0-9148-266766d054b1@sifive.com>

On 2023-12-15 2:47 PM, Jessica Clarke wrote:
> On 15 Dec 2023, at 20:40, Cristian Ciocaltea <cristian.ciocaltea at collabora.com> wrote:
>>
>> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
>> similar to the newer JH7110, but it requires only two interrupts and a
>> single reset line, which is 'ahb' instead of the commonly used
>> 'stmmaceth'.
>>
>> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
>> conjunction with 'stmmaceth', extend the logic to also permit exclusive
>> usage of the 'ahb' reset name.  This ensures the following use cases are
>> supported:
>>
>>  JH7110: reset-names = "stmmaceth", "ahb";
>>  JH7100: reset-names = "ahb";
>>  other:  reset-names = "stmmaceth";
>>
>> Also note the need to use a different dwmac fallback, as v5.20 applies
>> to JH7110 only, while JH7100 relies on v3.7x.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>> ---
>> .../devicetree/bindings/net/snps,dwmac.yaml   |  3 +-
>> .../bindings/net/starfive,jh7110-dwmac.yaml   | 74 +++++++++++++------
>> 2 files changed, 55 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> index 5c2769dc689a..c1380ff1c054 100644
>> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> @@ -95,6 +95,7 @@ properties:
>>         - snps,dwmac-5.20
>>         - snps,dwxgmac
>>         - snps,dwxgmac-2.10
>> +        - starfive,jh7100-dwmac
>>         - starfive,jh7110-dwmac
>>
>>   reg:
>> @@ -146,7 +147,7 @@ properties:
>>   reset-names:
>>     minItems: 1
>>     items:
>> -      - const: stmmaceth
>> +      - enum: [stmmaceth, ahb]
>>       - const: ahb
> 
> I?m not so well-versed in the YAML bindings, but would this not allow
> reset-names = "ahb", "ahb"?

Yes, it would. You need something like:

reset-names:
  oneOf:
    - enum: [stmmaceth, ahb]
    - items:
        - const: stmmaceth
        - const: ahb

Regards,
Samuel



From cristian.ciocaltea at collabora.com  Fri Dec 15 13:00:00 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 23:00:00 +0200
Subject: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <491f1a89-aabd-4c38-b33a-a298add1bdb3@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>
 <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>
 <491f1a89-aabd-4c38-b33a-a298add1bdb3@collabora.com>
Message-ID: <a9a3a7c5-7ee9-4b28-9abb-f1194054dfef@collabora.com>

On 12/15/23 22:56, Cristian Ciocaltea wrote:
> On 12/15/23 22:47, Jessica Clarke wrote:
>> On 15 Dec 2023, at 20:40, Cristian Ciocaltea <cristian.ciocaltea at collabora.com> wrote:
>>>
>>> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
>>> similar to the newer JH7110, but it requires only two interrupts and a
>>> single reset line, which is 'ahb' instead of the commonly used
>>> 'stmmaceth'.
>>>
>>> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
>>> conjunction with 'stmmaceth', extend the logic to also permit exclusive
>>> usage of the 'ahb' reset name.  This ensures the following use cases are
>>> supported:
>>>
>>>  JH7110: reset-names = "stmmaceth", "ahb";
>>>  JH7100: reset-names = "ahb";
>>>  other:  reset-names = "stmmaceth";
>>>
>>> Also note the need to use a different dwmac fallback, as v5.20 applies
>>> to JH7110 only, while JH7100 relies on v3.7x.
>>>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>>> ---
>>> .../devicetree/bindings/net/snps,dwmac.yaml   |  3 +-
>>> .../bindings/net/starfive,jh7110-dwmac.yaml   | 74 +++++++++++++------
>>> 2 files changed, 55 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>> index 5c2769dc689a..c1380ff1c054 100644
>>> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>> @@ -95,6 +95,7 @@ properties:
>>>         - snps,dwmac-5.20
>>>         - snps,dwxgmac
>>>         - snps,dwxgmac-2.10
>>> +        - starfive,jh7100-dwmac
>>>         - starfive,jh7110-dwmac
>>>
>>>   reg:
>>> @@ -146,7 +147,7 @@ properties:
>>>   reset-names:
>>>     minItems: 1
>>>     items:
>>> -      - const: stmmaceth
>>> +      - enum: [stmmaceth, ahb]
>>>       - const: ahb
>>
>> I?m not so well-versed in the YAML bindings, but would this not allow
>> reset-names = "ahb", "ahb"?
> 
> Yes, as I already pointed out in [1], I wasn't able to come up with a
> proper solution to avoid that.

Sorry, I've sent the previous email too early..

[1]: https://lore.kernel.org/lkml/564503dd-b779-4e9f-851d-f34d9ea5fa65 at collabora.com/

> Thanks,
> Cristian
> 
>> Jess
>>
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


From cristian.ciocaltea at collabora.com  Fri Dec 15 13:03:24 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 23:03:24 +0200
Subject: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <65fd52f1-6861-42b0-9148-266766d054b1@sifive.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>
 <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>
 <65fd52f1-6861-42b0-9148-266766d054b1@sifive.com>
Message-ID: <6c62e3b2-acde-4580-9b67-56683289e45e@collabora.com>

On 12/15/23 22:59, Samuel Holland wrote:
> On 2023-12-15 2:47 PM, Jessica Clarke wrote:
>> On 15 Dec 2023, at 20:40, Cristian Ciocaltea <cristian.ciocaltea at collabora.com> wrote:
>>>
>>> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
>>> similar to the newer JH7110, but it requires only two interrupts and a
>>> single reset line, which is 'ahb' instead of the commonly used
>>> 'stmmaceth'.
>>>
>>> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
>>> conjunction with 'stmmaceth', extend the logic to also permit exclusive
>>> usage of the 'ahb' reset name.  This ensures the following use cases are
>>> supported:
>>>
>>>  JH7110: reset-names = "stmmaceth", "ahb";
>>>  JH7100: reset-names = "ahb";
>>>  other:  reset-names = "stmmaceth";
>>>
>>> Also note the need to use a different dwmac fallback, as v5.20 applies
>>> to JH7110 only, while JH7100 relies on v3.7x.
>>>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>>> ---
>>> .../devicetree/bindings/net/snps,dwmac.yaml   |  3 +-
>>> .../bindings/net/starfive,jh7110-dwmac.yaml   | 74 +++++++++++++------
>>> 2 files changed, 55 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>> index 5c2769dc689a..c1380ff1c054 100644
>>> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>> @@ -95,6 +95,7 @@ properties:
>>>         - snps,dwmac-5.20
>>>         - snps,dwxgmac
>>>         - snps,dwxgmac-2.10
>>> +        - starfive,jh7100-dwmac
>>>         - starfive,jh7110-dwmac
>>>
>>>   reg:
>>> @@ -146,7 +147,7 @@ properties:
>>>   reset-names:
>>>     minItems: 1
>>>     items:
>>> -      - const: stmmaceth
>>> +      - enum: [stmmaceth, ahb]
>>>       - const: ahb
>>
>> I?m not so well-versed in the YAML bindings, but would this not allow
>> reset-names = "ahb", "ahb"?
> 
> Yes, it would. You need something like:
> 
> reset-names:
>   oneOf:
>     - enum: [stmmaceth, ahb]
>     - items:
>         - const: stmmaceth
>         - const: ahb

Oh yes, I always forget about the "oneOf" thing. Thanks!

> Regards,
> Samuel
> 


From samuel at sholland.org  Fri Dec 15 13:09:46 2023
From: samuel at sholland.org (Samuel Holland)
Date: Fri, 15 Dec 2023 15:09:46 -0600
Subject: [PATCH 4/5] cpufreq: Add support for RISC-V CPU Frequency scaling
 drivers
In-Reply-To: <20231215151723.46409-1-fusibrandon13@gmail.com>
References: <20231214111702.xdd7qlcrpqh74i3j@vireshk-i7>
 <20231215151723.46409-1-fusibrandon13@gmail.com>
Message-ID: <11b5aea1-7c6e-4be5-ae01-9c4c869dc98c@sholland.org>

Hi Brandon,

On 12/15/23 09:17, Brandon Cheo Fusi wrote:
> On Thu, Dec 14, 2023 at 12:17?PM Viresh Kumar <viresh.kumar at linaro.org> wrote:
>>
>> On 14-12-23, 11:33, Brandon Cheo Fusi wrote:
>>> Add Kconfig file for cpufreq scaling drivers that can handle RISC-V
>>> CPUs. An entry is included for the Allwinner H6 cpufreq driver that
>>> works with D1.
>>>
>>> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
>>> ---
>>>  drivers/cpufreq/Kconfig       |  4 ++++
>>>  drivers/cpufreq/Kconfig.riscv | 16 ++++++++++++++++
>>>  2 files changed, 20 insertions(+)
>>>  create mode 100644 drivers/cpufreq/Kconfig.riscv
>>
>> We don't have a separate kconfig file for each architecture. Only if
>> there are too many entries for an architecture, we add a new file.
>>
>> --
>> viresh
> 
> The sun50i cpufreq driver is currently only available when CONFIG_ARM or
> CONFIG_ARM64 is selected, so this was the only decent way I could think
> of making it accessible on either one of CONFIG_(ARM | ARM64 | RISC-V).
> Any suggestions for a better workaround ?

Move the option to the main drivers/cpufreq/Kconfig, like QORIQ_CPUFREQ,
which is also used with multiple architectures (PowerPC and ARM, in that
case). We don't want two options for the same driver.

Regards,
Samuel



From heiko at sntech.de  Fri Dec 15 13:10:28 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 15 Dec 2023 22:10:28 +0100
Subject: [PATCH 1/3] arm64: dts: rockchip: fix misleading comment in rk3399-puma-haikou.dts
In-Reply-To: <20231214122801.3144180-1-vahe.grigoryan@theobroma-systems.com>
References: <20231214122801.3144180-1-vahe.grigoryan@theobroma-systems.com>
Message-ID: <170267443961.1167098.4412754848079382518.b4-ty@sntech.de>

On Thu, 14 Dec 2023 13:27:59 +0100, Vahe Grigoryan wrote:
> Haikou is an evaluation and development platform for System on
> Modules (SOMs).
> 
> The GPIO0_B1 is routed to the Wake button instead of BIOS_DISABLE,
> update the comment to reflect that.
> 
> 
> [...]

Applied, thanks!

[1/3] arm64: dts: rockchip: fix misleading comment in rk3399-puma-haikou.dts
      commit: 9050aefab15b2da2c7d65d794ca445919ae4c235
[2/3] arm64: dts: rockchip: expose BIOS Disable feedback pin on rk3399-puma
      commit: 39d95566231d483a1c89e74cbcadc4394bfd53ef
[3/3] arm64: dts: rockchip: make Haikou buttons compatible with "gpio-keys"
      commit: 4a8cd5cb583b99b06d2f3e2acb38c5957dd4e92e

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Fri Dec 15 13:10:25 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 15 Dec 2023 22:10:25 +0100
Subject: [PATCH v4 0/5] Add 2 rk3588 based boards from Cool Pi
In-Reply-To: <20231212124202.1897238-1-andyshrk@163.com>
References: <20231212124202.1897238-1-andyshrk@163.com>
Message-ID: <170267443962.1167098.11212690692568621616.b4-ty@sntech.de>

On Tue, 12 Dec 2023 20:42:02 +0800, Andy Yan wrote:
> This series add support for rk3588s based SBC Cool Pi 4B
> and rk3588 based board Cool Pi CM5 EVB
> 
> Changes in v4:
> - split pi-cm5 as a dtsi
> 
> Changes in v3:
> - drop ununnecessary property status = "okay" for rtc
> - reorder some nodes alphabetical
> - remove disabled node
> - Add compatible "coolpi,pi-cm5" for CM5
> - drop ununnecessary property status = "okay" for backlight
> - reorder some nodes alphabetical
> - drop ununnecessary blank line
> 
> [...]

Applied, thanks!

[1/5] dt-bindings: vendor-prefixes: Add Cool Pi
      commit: 40488a16e455ae6000ae1525bdc7e49fcf71d1a4
[2/5] dt-bindings: arm: rockchip: Add Cool Pi 4B
      commit: 473aa86338489daa332933f158f1bb03dcc2c8ee
[3/5] arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B
      commit: 2d55c73a407a0e5cec0e97273dc1bf7b4d28cc02
[4/5] dt-bindings: arm: rockchip: Add Cool Pi CM5
      commit: 3b79d71c73c35001205556f9360c3afa4ef6d02d
[5/5] arm64: dts: rockchip: Add support for rk3588 based board Cool Pi CM5 EVB
      commit: aba89738bf7d83e47e5b6e5a4c9f452464746bbb

I've updated both board devicetrees somewhat.
Both in terms of sorting of properties and also to make the dtbs-check happy
and the board conformant to the yaml binding.


Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Fri Dec 15 13:10:27 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 15 Dec 2023 22:10:27 +0100
Subject: [PATCH v2] arm64: rockchip: dts: rk3328-rock-pi-e: add gpio-line-names
In-Reply-To: <20231213160556.14424-1-twoerner@gmail.com>
References: <20231213160556.14424-1-twoerner@gmail.com>
Message-ID: <170267443961.1167098.2865099267527144228.b4-ty@sntech.de>

On Wed, 13 Dec 2023 11:05:55 -0500, Trevor Woerner wrote:
> Add names to the pins of the general-purpose expansion header as given
> in the Radxa GPIO page[1] following the conventions in the kernel
> documentation[2] to make it easier for users to correlate the pins with
> functions when using utilities such as 'gpioinfo'.
> 
> 

Applied, thanks!

[1/1] arm64: rockchip: dts: rk3328-rock-pi-e: add gpio-line-names
      commit: 799637dfadb092d1732afacea42f67a6f1621fb4

I've indented the gpio lines by one tab as suggested by Dragan.
And also moved the &gpio {} references to their correct position
in the file.

Please sort phandle-references alphabetically and not just add them
to the bottom of the file.


Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From cristian.ciocaltea at collabora.com  Fri Dec 15 13:13:12 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 15 Dec 2023 23:13:12 +0200
Subject: [PATCH v2 12/12] [UNTESTED] riscv: dts: starfive:
 beaglev-starlight: Enable gmac
In-Reply-To: <2f06ce36-0dc1-495e-b6a6-318951a53e8d@collabora.com>
References: <20231029042712.520010-1-cristian.ciocaltea@collabora.com>
 <20231029042712.520010-13-cristian.ciocaltea@collabora.com>
 <CAJM55Z9e=vjGKNnmURN15mvXo2bVd3igBA-3puF9q7eh5hiP+A@mail.gmail.com>
 <2f06ce36-0dc1-495e-b6a6-318951a53e8d@collabora.com>
Message-ID: <698fbb5d-0750-4f2a-857f-5429e5f589f9@collabora.com>

On 11/28/23 02:40, Cristian Ciocaltea wrote:
> On 11/26/23 23:10, Emil Renner Berthing wrote:
>> Cristian Ciocaltea wrote:
>>> The BeagleV Starlight SBC uses a Microchip KSZ9031RNXCA PHY supporting
>>> RGMII-ID.
>>>

[...]
 
>> You've alse removed the phy reset gpio on the Starlight board:
>>
>>   snps,reset-gpios = <&gpio 63 GPIO_ACTIVE_LOW>
>>
>> Why?
> 
> I missed this in v1 as the gmac handling was done exclusively in
> jh7100-common. Thanks for noticing!

Hi Emil,

I think the reset doesn't actually trigger because "snps,reset-gpios" is
not a valid property, it should have been "snps,reset-gpio" (without the
trailing "s").

However, this seems to be deprecated now, and the recommended approach
would be to define the reset gpio in the phy node, which I did in [1].

Hopefully this won't cause any unexpected behaviour. Otherwise we should
probably simply drop it.

[1]: https://lore.kernel.org/lkml/20231215204050.2296404-8-cristian.ciocaltea at collabora.com/ 


From alexis.lothore at bootlin.com  Fri Dec 15 13:34:24 2023
From: alexis.lothore at bootlin.com (=?utf-8?q?Alexis_Lothor=C3=A9?=)
Date: Fri, 15 Dec 2023 22:34:24 +0100
Subject: [PATCH] pinctrl: at91-pio4: use dedicated lock class for IRQ
Message-ID: <20231215-lockdep_warning-v1-1-8137b2510ed5@bootlin.com>

Trying to suspend to RAM on SAMA5D27 EVK leads to the following lockdep
warning:

 ============================================
 WARNING: possible recursive locking detected
 6.7.0-rc5-wt+ #532 Not tainted
 --------------------------------------------
 sh/92 is trying to acquire lock:
 c3cf306c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100

 but task is already holding lock:
 c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&irq_desc_lock_class);
   lock(&irq_desc_lock_class);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 6 locks held by sh/92:
  #0: c3aa0258 (sb_writers#6){.+.+}-{0:0}, at: ksys_write+0xd8/0x178
  #1: c4c2df44 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x138/0x284
  #2: c32684a0 (kn->active){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x148/0x284
  #3: c232b6d4 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x13c/0x4e8
  #4: c387b088 (&dev->mutex){....}-{3:3}, at: __device_suspend+0x1e8/0x91c
  #5: c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100

 stack backtrace:
 CPU: 0 PID: 92 Comm: sh Not tainted 6.7.0-rc5-wt+ #532
 Hardware name: Atmel SAMA5
  unwind_backtrace from show_stack+0x18/0x1c
  show_stack from dump_stack_lvl+0x34/0x48
  dump_stack_lvl from __lock_acquire+0x19ec/0x3a0c
  __lock_acquire from lock_acquire.part.0+0x124/0x2d0
  lock_acquire.part.0 from _raw_spin_lock_irqsave+0x5c/0x78
  _raw_spin_lock_irqsave from __irq_get_desc_lock+0xe8/0x100
  __irq_get_desc_lock from irq_set_irq_wake+0xa8/0x204
  irq_set_irq_wake from atmel_gpio_irq_set_wake+0x58/0xb4
  atmel_gpio_irq_set_wake from irq_set_irq_wake+0x100/0x204
  irq_set_irq_wake from gpio_keys_suspend+0xec/0x2b8
  gpio_keys_suspend from dpm_run_callback+0xe4/0x248
  dpm_run_callback from __device_suspend+0x234/0x91c
  __device_suspend from dpm_suspend+0x224/0x43c
  dpm_suspend from dpm_suspend_start+0x9c/0xa8
  dpm_suspend_start from suspend_devices_and_enter+0x1e0/0xa84
  suspend_devices_and_enter from pm_suspend+0x460/0x4e8
  pm_suspend from state_store+0x78/0xe4
  state_store from kernfs_fop_write_iter+0x1a0/0x284
  kernfs_fop_write_iter from vfs_write+0x38c/0x6f4
  vfs_write from ksys_write+0xd8/0x178
  ksys_write from ret_fast_syscall+0x0/0x1c
 Exception stack(0xc52b3fa8 to 0xc52b3ff0)
 3fa0:                   00000004 005a0ae8 00000001 005a0ae8 00000004 00000001
 3fc0: 00000004 005a0ae8 00000001 00000004 00000004 b6c616c0 00000020 0059d190
 3fe0: 00000004 b6c61678 aec5a041 aebf1a26

This warning is raised because pinctrl-at91-pio4 uses chained IRQ. Whenever
a wake up source configures an IRQ through irq_set_irq_wake, it will
lock the corresponding IRQ desc, and then call irq_set_irq_wake on "parent"
IRQ which will do the same on its own IRQ desc, but since those two locks
share the same class, lockdep reports this as an issue.

Fix lockdep false positive by setting a different class for parent and
children IRQ

Fixes: 776180848b57 ("pinctrl: introduce driver for Atmel PIO4 controller")
Signed-off-by: Alexis Lothor? <alexis.lothore at bootlin.com>
---
 drivers/pinctrl/pinctrl-at91-pio4.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
index 383309e533c3..a27c01fcbb47 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -1068,6 +1068,13 @@ static const struct of_device_id atmel_pctrl_of_match[] = {
 	}
 };
 
+/*
+ * This lock class allows to tell lockdep that parent IRQ and children IRQ do
+ * not share the same class so it does not raise false positive
+ */
+static struct lock_class_key atmel_lock_key;
+static struct lock_class_key atmel_request_key;
+
 static int atmel_pinctrl_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1214,6 +1221,7 @@ static int atmel_pinctrl_probe(struct platform_device *pdev)
 		irq_set_chip_and_handler(irq, &atmel_gpio_irq_chip,
 					 handle_simple_irq);
 		irq_set_chip_data(irq, atmel_pioctrl);
+		irq_set_lockdep_class(irq, &atmel_lock_key, &atmel_request_key);
 		dev_dbg(dev,
 			"atmel gpio irq domain: hwirq: %d, linux irq: %d\n",
 			i, irq);

---
base-commit: 1a756b6d03605c5a6acf68f6b74e6d56af52737f
change-id: 20231215-lockdep_warning-93649b346892

Best regards,
-- 
Alexis Lothor?, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com



From josef at toxicpanda.com  Fri Dec 15 13:43:14 2023
From: josef at toxicpanda.com (Josef Bacik)
Date: Fri, 15 Dec 2023 16:43:14 -0500
Subject: [PATCH] arm64: properly install vmlinuz.efi
In-Reply-To: <ZXyxG9qsASMQ-1Ty@arm.com>
References: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>
 <ZXyxG9qsASMQ-1Ty@arm.com>
Message-ID: <20231215214314.GA883762@perftesting>

On Fri, Dec 15, 2023 at 08:03:39PM +0000, Catalin Marinas wrote:
> On Thu, Dec 14, 2023 at 11:18:50AM -0500, Josef Bacik wrote:
> > If you select CONFIG_EFI_ZBOOT, we will generate vmlinuz.efi, and then
> > when we go to install the kernel we'll install the vmlinux instead
> > because install.sh only recognizes Image.gz as wanting the compressed
> > install image.  With CONFIG_EFI_ZBOOT we don't get the proper kernel
> > installed, which means it doesn't boot, which makes for a very confused
> > and subsequently angry kernel developer.
> > 
> > Fix this by properly installing our compressed kernel if we've enabled
> > CONFIG_EFI_ZBOOT.
> > 
> > Signed-off-by: Josef Bacik <josef at toxicpanda.com>
> > ---
> >  arch/arm64/boot/install.sh | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
> > index 7399d706967a..9b7a09808a3d 100755
> > --- a/arch/arm64/boot/install.sh
> > +++ b/arch/arm64/boot/install.sh
> > @@ -17,7 +17,8 @@
> >  #   $3 - kernel map file
> >  #   $4 - default install path (blank if root directory)
> >  
> > -if [ "$(basename $2)" = "Image.gz" ]; then
> > +if [ "$(basename $2)" = "Image.gz" ] || [ "$(basename $2)" = "vmlinuz.efi" ]
> > +then
> >  # Compressed install
> >    echo "Installing compressed kernel"
> >    base=vmlinuz
> 
> + Ard who added the EFI_ZBOOT support.
> 
> If we go with this fix we should probably also add:
> 
> Fixes: c37b830fef13 ("arm64: efi: enable generic EFI compressed boot")
> Cc: <stable at vger.kernel.org> # 6.1.x
> 
> But is arm64 the only one with this issue?
> 

I can only speak for x86 and arm, x86 has been working fine using this config, I
only recently started using the same thing for arm on my mac studio and ran into
a variety of fun things.  Thanks,

Josef


From vladimir.oltean at nxp.com  Fri Dec 15 13:45:23 2023
From: vladimir.oltean at nxp.com (Vladimir Oltean)
Date: Fri, 15 Dec 2023 23:45:23 +0200
Subject: [PATCH net-next v4 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <20231215171237.1152563-2-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-2-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-2-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-2-maxime.chevallier@bootlin.com>
Message-ID: <20231215214523.ntk5kec32mb5vqjs@skbuf>

On Fri, Dec 15, 2023 at 06:12:23PM +0100, Maxime Chevallier wrote:
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index d8e9335d415c..89daaccc9276 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1491,6 +1500,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
>  
>  		if (phydev->sfp_bus_attached)
>  			dev->sfp_bus = phydev->sfp_bus;
> +
> +		err = phy_link_topo_add_phy(&dev->link_topo, phydev,
> +					    PHY_UPSTREAM_MAC, dev);
> +		if (err)
> +			goto error;
>  	}
>  
>  	/* Some Ethernet drivers try to connect to a PHY device before
> @@ -1816,6 +1830,7 @@ void phy_detach(struct phy_device *phydev)
>  	if (dev) {
>  		phydev->attached_dev->phydev = NULL;
>  		phydev->attached_dev = NULL;
> +		phy_link_topo_del_phy(&dev->link_topo, phydev);
>  	}
>  	phydev->phylink = NULL;
>  
> diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
> new file mode 100644
> index 000000000000..22f6372d002c
> --- /dev/null
> +++ b/drivers/net/phy/phy_link_topology.c
> +int phy_link_topo_add_phy(struct phy_link_topology *topo,
> +			  struct phy_device *phy,
> +			  enum phy_upstream upt, void *upstream)
> +{
> +	struct phy_device_node *pdn;
> +	int ret;
> +
> +	/* Protects phy and upstream */
> +	ASSERT_RTNL();

Something to think for the PHY library maintainers. This is probably
the first time when the rtnl_lock() requirement is asserted at
phy_attach_direct() time.

I haven't done too much with the patch set yet, so I don't understand
exactly from the comment what this is protecting. But I get the
following assertion failure with DSA:

[    4.157160] ------------[ cut here ]------------
[    4.161805] RTNL: assertion failed at drivers/net/phy/phy_link_topology.c (35)
[    4.169124] WARNING: CPU: 0 PID: 26 at drivers/net/phy/phy_link_topology.c:35 phy_link_topo_add_phy+0x128/0x130
[    4.179263] Modules linked in:
[    4.209232] pc : phy_link_topo_add_phy+0x128/0x130
[    4.214040] lr : phy_link_topo_add_phy+0x128/0x130
[    4.293822] Call trace:
[    4.296271]  phy_link_topo_add_phy+0x128/0x130
[    4.300730]  phy_attach_direct+0xbc/0x3c4
[    4.304752]  phylink_fwnode_phy_connect+0xa8/0xf8
[    4.309473]  phylink_of_phy_connect+0x1c/0x28
[    4.313844]  dsa_user_create+0x318/0x5ac
[    4.317778]  dsa_port_setup+0x100/0x144
[    4.321626]  dsa_register_switch+0xe90/0x11f8
[    4.325997]  sja1105_probe+0x2bc/0x2e4
[    4.329759]  spi_probe+0xa4/0xc4
[    4.332995]  really_probe+0x16c/0x3fc
[    4.336669]  __driver_probe_device+0xa4/0x168
[    4.341041]  driver_probe_device+0x3c/0x220
[    4.345238]  __device_attach_driver+0x128/0x1cc
[    4.349784]  bus_for_each_drv+0xf4/0x14c
[    4.353719]  __device_attach+0xfc/0x1bc
[    4.357567]  device_initial_probe+0x14/0x20
[    4.361764]  bus_probe_device+0x94/0x100
[    4.385371] ---[ end trace 0000000000000000 ]---

Someone please correct me if I'm wrong, but at least up until now, calling
this unlocked has been quite harmless, because we call dsa_user_phy_setup()
before register_netdevice(), and thus, the net_device is pretty much
inaccessible to the world when we attach it to the PHY.

And, while having the phydev->attached_dev pointer populated technically
makes the net_device now accessible from the PHY, this is a moot point,
because no user space command targets the PHY directly. They all target
the netdev, and through that, netdev->phydev. The netdev is still
unregistered, so it's ok to not have rtnl_lock().

It is rather going to be something that concerns those drivers which call
phy_attach_direct() after registering, for example from ndo_open().

Interestingly, phylink_disconnect_phy() has an ASSERT_RTNL() in it
even though the phylink_attach_phy() derivatives do not. I'm unable
to ascertain whether a previous unregister_netdevice() call makes this
requirement redundant or not.

> +
> +	pdn = kzalloc(sizeof(*pdn), GFP_KERNEL);
> +	if (!pdn)
> +		return -ENOMEM;
> +
> +	pdn->phy = phy;
> +	switch (upt) {
> +	case PHY_UPSTREAM_MAC:
> +		pdn->upstream.netdev = (struct net_device *)upstream;
> +		if (phy_on_sfp(phy))
> +			pdn->parent_sfp_bus = pdn->upstream.netdev->sfp_bus;
> +		break;
> +	case PHY_UPSTREAM_PHY:
> +		pdn->upstream.phydev = (struct phy_device *)upstream;
> +		if (phy_on_sfp(phy))
> +			pdn->parent_sfp_bus = pdn->upstream.phydev->sfp_bus;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +	pdn->upstream_type = upt;
> +
> +	ret = xa_alloc_cyclic(&topo->phys, &phy->phyindex, pdn, xa_limit_32b,
> +			      &topo->next_phy_index, GFP_KERNEL);
> +	if (ret)
> +		goto err;
> +
> +	return 0;
> +
> +err:
> +	kfree(pdn);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_link_topo_add_phy);


From peter.hilber at opensynergy.com  Fri Dec 15 14:06:06 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Fri, 15 Dec 2023 23:06:06 +0100
Subject: [RFC PATCH v2 1/7] timekeeping: Add clocksource ID to struct system_counterval_t
In-Reply-To: <20231215220612.173603-1-peter.hilber@opensynergy.com>
References: <20231215220612.173603-1-peter.hilber@opensynergy.com>
Message-ID: <20231215220612.173603-2-peter.hilber@opensynergy.com>

Clocksource pointers can be problematic to obtain for drivers which are not
clocksource drivers themselves. In particular, the RFC virtio_rtc driver
[1] would require a new helper function to obtain a pointer to the Arm
Generic Timer clocksource. The ptp_kvm driver also required a similar
workaround.

Add a clocksource ID member to struct system_counterval_t, which in the
future shall identify the clocksource, and shall replace the struct
clocksource * member. By this, get_device_system_crosststamp() callers
(such as virtio_rtc and ptp_kvm) will be able to supply easily accessible
clocksource ids instead of clocksource pointers.

[1] https://lore.kernel.org/lkml/20230818012014.212155-1-peter.hilber at opensynergy.com/

Signed-off-by: Peter Hilber <peter.hilber at opensynergy.com>
---

Notes:
    v2:
    
    - Refer to clocksource IDs as such in comments (Thomas Gleixner).

 include/linux/timekeeping.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index fe1e467ba046..74dc7c8b036f 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -272,10 +272,15 @@ struct system_device_crosststamp {
  * @cycles:	System counter value
  * @cs:		Clocksource corresponding to system counter value. Used by
  *		timekeeping code to verify comparibility of two cycle values
+ * @cs_id:	Clocksource ID corresponding to system counter value. To be
+ *		used instead of cs in the future.
+ *		The default ID, CSID_GENERIC, does not identify a specific
+ *		clocksource.
  */
 struct system_counterval_t {
 	u64			cycles;
 	struct clocksource	*cs;
+	enum clocksource_ids	cs_id;
 };
 
 /*
-- 
2.40.1



From peter.hilber at opensynergy.com  Fri Dec 15 14:06:08 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Fri, 15 Dec 2023 23:06:08 +0100
Subject: [RFC PATCH v2 3/7] x86/kvm, ptp/kvm: Add clocksource ID, set system_counterval_t.cs_id
In-Reply-To: <20231215220612.173603-1-peter.hilber@opensynergy.com>
References: <20231215220612.173603-1-peter.hilber@opensynergy.com>
Message-ID: <20231215220612.173603-4-peter.hilber@opensynergy.com>

Add a clocksource ID for the x86 kvmclock.

Also, for ptp_kvm, set the recently added struct system_counterval_t member
cs_id to the clocksource ID (x86 kvmclock or Arm Generic Timer). In the
future, this will keep get_device_system_crosststamp() working, when it
will compare the clocksource id in struct system_counterval_t, rather than
the clocksource.

For now, to avoid touching too many subsystems at once, extract the
clocksource ID from the clocksource. The clocksource dereference will be
removed in the following.

Signed-off-by: Peter Hilber <peter.hilber at opensynergy.com>
---

Notes:
    v2:
    
    - Name clock id according to Thomas Gleixner's mockup.

 arch/x86/kernel/kvmclock.c      | 2 ++
 drivers/ptp/ptp_kvm_common.c    | 2 ++
 include/linux/clocksource_ids.h | 1 +
 3 files changed, 5 insertions(+)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index fb8f52149be9..25d6bf743b03 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -4,6 +4,7 @@
 */
 
 #include <linux/clocksource.h>
+#include <linux/clocksource_ids.h>
 #include <linux/kvm_para.h>
 #include <asm/pvclock.h>
 #include <asm/msr.h>
@@ -160,6 +161,7 @@ struct clocksource kvm_clock = {
 	.rating	= 400,
 	.mask	= CLOCKSOURCE_MASK(64),
 	.flags	= CLOCK_SOURCE_IS_CONTINUOUS,
+	.id     = CSID_X86_KVM_CLK,
 	.enable	= kvm_cs_enable,
 };
 EXPORT_SYMBOL_GPL(kvm_clock);
diff --git a/drivers/ptp/ptp_kvm_common.c b/drivers/ptp/ptp_kvm_common.c
index 2418977989be..b0b36f135347 100644
--- a/drivers/ptp/ptp_kvm_common.c
+++ b/drivers/ptp/ptp_kvm_common.c
@@ -4,6 +4,7 @@
  *
  * Copyright (C) 2017 Red Hat Inc.
  */
+#include <linux/clocksource.h>
 #include <linux/device.h>
 #include <linux/err.h>
 #include <linux/init.h>
@@ -47,6 +48,7 @@ static int ptp_kvm_get_time_fn(ktime_t *device_time,
 
 	system_counter->cycles = cycle;
 	system_counter->cs = cs;
+	system_counter->cs_id = cs->id;
 
 	*device_time = timespec64_to_ktime(tspec);
 
diff --git a/include/linux/clocksource_ids.h b/include/linux/clocksource_ids.h
index f8467946e9ee..a4fa3436940c 100644
--- a/include/linux/clocksource_ids.h
+++ b/include/linux/clocksource_ids.h
@@ -8,6 +8,7 @@ enum clocksource_ids {
 	CSID_ARM_ARCH_COUNTER,
 	CSID_X86_TSC_EARLY,
 	CSID_X86_TSC,
+	CSID_X86_KVM_CLK,
 	CSID_MAX,
 };
 
-- 
2.40.1



From peter.hilber at opensynergy.com  Fri Dec 15 14:06:10 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Fri, 15 Dec 2023 23:06:10 +0100
Subject: [RFC PATCH v2 5/7] timekeeping: Evaluate system_counterval_t.cs_id instead of .cs
In-Reply-To: <20231215220612.173603-1-peter.hilber@opensynergy.com>
References: <20231215220612.173603-1-peter.hilber@opensynergy.com>
Message-ID: <20231215220612.173603-6-peter.hilber@opensynergy.com>

Clocksource pointers can be problematic to obtain for drivers which are not
clocksource drivers themselves. In particular, the RFC virtio_rtc driver
[1] would require a new helper function to obtain a pointer to the Arm
Generic Timer clocksource. The ptp_kvm driver also required a similar
workaround.

Address this by evaluating the clocksource ID, rather than the clocksource
pointer, of struct system_counterval_t. By this, setting the clocksource
pointer becomes unneeded, and it will be dropped from struct
system_counterval_t in the future. By this, get_device_system_crosststamp()
callers (such as virtio_rtc and ptp_kvm) will no longer need to supply
clocksource pointers.

This change should not alter any behavior, as the struct
system_counterval_t clocksource ID is already being set wherever the
clocksource pointer is set. get_device_system_crosststamp() will now fail
if the clocksource has id CSID_GENERIC, but all currently relevant
clocksources have a custom clocksource id.

[1] https://lore.kernel.org/lkml/20230818012014.212155-1-peter.hilber at opensynergy.com/

Signed-off-by: Peter Hilber <peter.hilber at opensynergy.com>
---

Notes:
    v2:
    
    - Refer to clocksource IDs as such in comments (Thomas Gleixner).
    
    - Update comments which were still referring to clocksource pointers.

 include/linux/timekeeping.h | 10 +++++-----
 kernel/time/timekeeping.c   |  9 +++++----
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 74dc7c8b036f..75e957171bd5 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -267,13 +267,13 @@ struct system_device_crosststamp {
 };
 
 /**
- * struct system_counterval_t - system counter value with the pointer to the
+ * struct system_counterval_t - system counter value with the ID of the
  *				corresponding clocksource
  * @cycles:	System counter value
- * @cs:		Clocksource corresponding to system counter value. Used by
- *		timekeeping code to verify comparibility of two cycle values
- * @cs_id:	Clocksource ID corresponding to system counter value. To be
- *		used instead of cs in the future.
+ * @cs:		Clocksource corresponding to system counter value. Timekeeping
+ *		code now evaluates cs_id instead.
+ * @cs_id:	Clocksource ID corresponding to system counter value. Used by
+ *		timekeeping code to verify comparability of two cycle values.
  *		The default ID, CSID_GENERIC, does not identify a specific
  *		clocksource.
  */
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 266d02809dbb..0ff065c5d25b 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1232,11 +1232,12 @@ int get_device_system_crosststamp(int (*get_time_fn)
 			return ret;
 
 		/*
-		 * Verify that the clocksource associated with the captured
-		 * system counter value is the same as the currently installed
-		 * timekeeper clocksource
+		 * Verify that the clocksource ID associated with the captured
+		 * system counter value is the same as for the currently
+		 * installed timekeeper clocksource
 		 */
-		if (tk->tkr_mono.clock != system_counterval.cs)
+		if (system_counterval.cs_id == CSID_GENERIC ||
+		    tk->tkr_mono.clock->id != system_counterval.cs_id)
 			return -ENODEV;
 		cycles = system_counterval.cycles;
 
-- 
2.40.1



From peter.hilber at opensynergy.com  Fri Dec 15 14:06:11 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Fri, 15 Dec 2023 23:06:11 +0100
Subject: [RFC PATCH v2 6/7] treewide: Remove system_counterval_t.cs, which is never read
In-Reply-To: <20231215220612.173603-1-peter.hilber@opensynergy.com>
References: <20231215220612.173603-1-peter.hilber@opensynergy.com>
Message-ID: <20231215220612.173603-7-peter.hilber@opensynergy.com>

The clocksource pointer in struct system_counterval_t is not evaluated any
more. Remove the code setting the member, and the member itself.

Signed-off-by: Peter Hilber <peter.hilber at opensynergy.com>
---
 arch/x86/kernel/tsc.c                | 14 ++------------
 drivers/clocksource/arm_arch_timer.c |  3 ---
 drivers/ptp/ptp_kvm_arm.c            |  2 +-
 drivers/ptp/ptp_kvm_common.c         |  4 +---
 drivers/ptp/ptp_kvm_x86.c            |  2 --
 include/linux/ptp_kvm.h              |  4 +---
 include/linux/timekeeping.h          |  3 ---
 7 files changed, 5 insertions(+), 27 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 9367174f7920..868f09966b0f 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -54,7 +54,6 @@ static int __read_mostly tsc_force_recalibrate;
 static u32 art_to_tsc_numerator;
 static u32 art_to_tsc_denominator;
 static u64 art_to_tsc_offset;
-static struct clocksource *art_related_clocksource;
 static bool have_art;
 
 struct cyc2ns {
@@ -1314,7 +1313,6 @@ struct system_counterval_t convert_art_to_tsc(u64 art)
 	res += tmp + art_to_tsc_offset;
 
 	return (struct system_counterval_t) {
-		.cs = art_related_clocksource,
 		.cs_id = have_art ? CSID_X86_TSC : CSID_GENERIC,
 		.cycles = res
 	};
@@ -1337,9 +1335,6 @@ EXPORT_SYMBOL(convert_art_to_tsc);
  * struct system_counterval_t - system counter value with the ID of the
  *	corresponding clocksource
  *	@cycles:	System counter value
- *	@cs:		Clocksource corresponding to system counter value. Used
- *			by timekeeping code to verify comparability of two cycle
- *			values.
  *	@cs_id:		Clocksource ID corresponding to system counter value.
  *			Used by timekeeping code to verify comparability of two
  *			cycle values.
@@ -1358,7 +1353,6 @@ struct system_counterval_t convert_art_ns_to_tsc(u64 art_ns)
 	res += tmp;
 
 	return (struct system_counterval_t) {
-		.cs = art_related_clocksource,
 		.cs_id = have_art ? CSID_X86_TSC : CSID_GENERIC,
 		.cycles = res
 	};
@@ -1467,10 +1461,8 @@ static void tsc_refine_calibration_work(struct work_struct *work)
 	if (tsc_unstable)
 		goto unreg;
 
-	if (boot_cpu_has(X86_FEATURE_ART)) {
-		art_related_clocksource = &clocksource_tsc;
+	if (boot_cpu_has(X86_FEATURE_ART))
 		have_art = true;
-	}
 	clocksource_register_khz(&clocksource_tsc, tsc_khz);
 unreg:
 	clocksource_unregister(&clocksource_tsc_early);
@@ -1495,10 +1487,8 @@ static int __init init_tsc_clocksource(void)
 	 * the refined calibration and directly register it as a clocksource.
 	 */
 	if (boot_cpu_has(X86_FEATURE_TSC_KNOWN_FREQ)) {
-		if (boot_cpu_has(X86_FEATURE_ART)) {
-			art_related_clocksource = &clocksource_tsc;
+		if (boot_cpu_has(X86_FEATURE_ART))
 			have_art = true;
-		}
 		clocksource_register_khz(&clocksource_tsc, tsc_khz);
 		clocksource_unregister(&clocksource_tsc_early);
 
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 45a02872669e..8d4a52056684 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1807,7 +1807,6 @@ TIMER_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
 #endif
 
 int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *ts,
-				 struct clocksource **cs,
 				 enum clocksource_ids *cs_id)
 {
 	struct arm_smccc_res hvc_res;
@@ -1832,8 +1831,6 @@ int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *ts,
 	*ts = ktime_to_timespec64(ktime);
 	if (cycle)
 		*cycle = (u64)hvc_res.a2 << 32 | hvc_res.a3;
-	if (cs)
-		*cs = &clocksource_counter;
 	if (cs_id)
 		*cs_id = CSID_ARM_ARCH_COUNTER;
 
diff --git a/drivers/ptp/ptp_kvm_arm.c b/drivers/ptp/ptp_kvm_arm.c
index 017bb5f03b14..e68e6943167b 100644
--- a/drivers/ptp/ptp_kvm_arm.c
+++ b/drivers/ptp/ptp_kvm_arm.c
@@ -28,5 +28,5 @@ void kvm_arch_ptp_exit(void)
 
 int kvm_arch_ptp_get_clock(struct timespec64 *ts)
 {
-	return kvm_arch_ptp_get_crosststamp(NULL, ts, NULL, NULL);
+	return kvm_arch_ptp_get_crosststamp(NULL, ts, NULL);
 }
diff --git a/drivers/ptp/ptp_kvm_common.c b/drivers/ptp/ptp_kvm_common.c
index f6683ba0ab3c..15ccb7dd2ed0 100644
--- a/drivers/ptp/ptp_kvm_common.c
+++ b/drivers/ptp/ptp_kvm_common.c
@@ -30,14 +30,13 @@ static int ptp_kvm_get_time_fn(ktime_t *device_time,
 {
 	enum clocksource_ids cs_id;
 	struct timespec64 tspec;
-	struct clocksource *cs;
 	u64 cycle;
 	int ret;
 
 	spin_lock(&kvm_ptp_lock);
 
 	preempt_disable_notrace();
-	ret = kvm_arch_ptp_get_crosststamp(&cycle, &tspec, &cs, &cs_id);
+	ret = kvm_arch_ptp_get_crosststamp(&cycle, &tspec, &cs_id);
 	if (ret) {
 		spin_unlock(&kvm_ptp_lock);
 		preempt_enable_notrace();
@@ -47,7 +46,6 @@ static int ptp_kvm_get_time_fn(ktime_t *device_time,
 	preempt_enable_notrace();
 
 	system_counter->cycles = cycle;
-	system_counter->cs = cs;
 	system_counter->cs_id = cs_id;
 
 	*device_time = timespec64_to_ktime(tspec);
diff --git a/drivers/ptp/ptp_kvm_x86.c b/drivers/ptp/ptp_kvm_x86.c
index 2782442922cb..617c8d6706d3 100644
--- a/drivers/ptp/ptp_kvm_x86.c
+++ b/drivers/ptp/ptp_kvm_x86.c
@@ -93,7 +93,6 @@ int kvm_arch_ptp_get_clock(struct timespec64 *ts)
 }
 
 int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *tspec,
-			      struct clocksource **cs,
 			      enum clocksource_ids *cs_id)
 {
 	struct pvclock_vcpu_time_info *src;
@@ -124,7 +123,6 @@ int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *tspec,
 		*cycle = __pvclock_read_cycles(src, clock_pair->tsc);
 	} while (pvclock_read_retry(src, version));
 
-	*cs = &kvm_clock;
 	*cs_id = CSID_X86_KVM_CLK;
 
 	return 0;
diff --git a/include/linux/ptp_kvm.h b/include/linux/ptp_kvm.h
index 95b3d4d0d7dd..e8c74fa3f455 100644
--- a/include/linux/ptp_kvm.h
+++ b/include/linux/ptp_kvm.h
@@ -12,13 +12,11 @@
 #include <linux/types.h>
 
 struct timespec64;
-struct clocksource;
 
 int kvm_arch_ptp_init(void);
 void kvm_arch_ptp_exit(void);
 int kvm_arch_ptp_get_clock(struct timespec64 *ts);
 int kvm_arch_ptp_get_crosststamp(u64 *cycle,
-		struct timespec64 *tspec, struct clocksource **cs,
-		enum clocksource_ids *cs_id);
+		struct timespec64 *tspec, enum clocksource_ids *cs_id);
 
 #endif /* _PTP_KVM_H_ */
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 75e957171bd5..0f00f382bb5d 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -270,8 +270,6 @@ struct system_device_crosststamp {
  * struct system_counterval_t - system counter value with the ID of the
  *				corresponding clocksource
  * @cycles:	System counter value
- * @cs:		Clocksource corresponding to system counter value. Timekeeping
- *		code now evaluates cs_id instead.
  * @cs_id:	Clocksource ID corresponding to system counter value. Used by
  *		timekeeping code to verify comparability of two cycle values.
  *		The default ID, CSID_GENERIC, does not identify a specific
@@ -279,7 +277,6 @@ struct system_device_crosststamp {
  */
 struct system_counterval_t {
 	u64			cycles;
-	struct clocksource	*cs;
 	enum clocksource_ids	cs_id;
 };
 
-- 
2.40.1



From peter.hilber at opensynergy.com  Fri Dec 15 14:06:09 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Fri, 15 Dec 2023 23:06:09 +0100
Subject: [RFC PATCH v2 4/7] ptp/kvm, arm_arch_timer: Set system_counterval_t.cs_id to constant
In-Reply-To: <20231215220612.173603-1-peter.hilber@opensynergy.com>
References: <20231215220612.173603-1-peter.hilber@opensynergy.com>
Message-ID: <20231215220612.173603-5-peter.hilber@opensynergy.com>

Identify the clocksources used by ptp_kvm by setting clocksource ID enum
constants. This avoids dereferencing struct clocksource. Once the
system_counterval_t.cs member will be removed, this will also avoid the
need to obtain clocksource pointers from kvm_arch_ptp_get_crosststamp().

The clocksource IDs are associated to timestamps requested from the KVM
hypervisor, so the proper clocksource ID is known at the ptp_kvm request
site.

While at it, also rectify the ptp_kvm_get_time_fn() ret type.

Signed-off-by: Peter Hilber <peter.hilber at opensynergy.com>
---

Notes:
    v2:
    
    Added in v2.

 drivers/clocksource/arm_arch_timer.c |  5 ++++-
 drivers/ptp/ptp_kvm_arm.c            |  2 +-
 drivers/ptp/ptp_kvm_common.c         | 10 +++++-----
 drivers/ptp/ptp_kvm_x86.c            |  4 +++-
 include/linux/ptp_kvm.h              |  4 +++-
 5 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index e054de92de91..45a02872669e 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1807,7 +1807,8 @@ TIMER_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
 #endif
 
 int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *ts,
-				 struct clocksource **cs)
+				 struct clocksource **cs,
+				 enum clocksource_ids *cs_id)
 {
 	struct arm_smccc_res hvc_res;
 	u32 ptp_counter;
@@ -1833,6 +1834,8 @@ int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *ts,
 		*cycle = (u64)hvc_res.a2 << 32 | hvc_res.a3;
 	if (cs)
 		*cs = &clocksource_counter;
+	if (cs_id)
+		*cs_id = CSID_ARM_ARCH_COUNTER;
 
 	return 0;
 }
diff --git a/drivers/ptp/ptp_kvm_arm.c b/drivers/ptp/ptp_kvm_arm.c
index e68e6943167b..017bb5f03b14 100644
--- a/drivers/ptp/ptp_kvm_arm.c
+++ b/drivers/ptp/ptp_kvm_arm.c
@@ -28,5 +28,5 @@ void kvm_arch_ptp_exit(void)
 
 int kvm_arch_ptp_get_clock(struct timespec64 *ts)
 {
-	return kvm_arch_ptp_get_crosststamp(NULL, ts, NULL);
+	return kvm_arch_ptp_get_crosststamp(NULL, ts, NULL, NULL);
 }
diff --git a/drivers/ptp/ptp_kvm_common.c b/drivers/ptp/ptp_kvm_common.c
index b0b36f135347..f6683ba0ab3c 100644
--- a/drivers/ptp/ptp_kvm_common.c
+++ b/drivers/ptp/ptp_kvm_common.c
@@ -4,7 +4,6 @@
  *
  * Copyright (C) 2017 Red Hat Inc.
  */
-#include <linux/clocksource.h>
 #include <linux/device.h>
 #include <linux/err.h>
 #include <linux/init.h>
@@ -29,15 +28,16 @@ static int ptp_kvm_get_time_fn(ktime_t *device_time,
 			       struct system_counterval_t *system_counter,
 			       void *ctx)
 {
-	long ret;
-	u64 cycle;
+	enum clocksource_ids cs_id;
 	struct timespec64 tspec;
 	struct clocksource *cs;
+	u64 cycle;
+	int ret;
 
 	spin_lock(&kvm_ptp_lock);
 
 	preempt_disable_notrace();
-	ret = kvm_arch_ptp_get_crosststamp(&cycle, &tspec, &cs);
+	ret = kvm_arch_ptp_get_crosststamp(&cycle, &tspec, &cs, &cs_id);
 	if (ret) {
 		spin_unlock(&kvm_ptp_lock);
 		preempt_enable_notrace();
@@ -48,7 +48,7 @@ static int ptp_kvm_get_time_fn(ktime_t *device_time,
 
 	system_counter->cycles = cycle;
 	system_counter->cs = cs;
-	system_counter->cs_id = cs->id;
+	system_counter->cs_id = cs_id;
 
 	*device_time = timespec64_to_ktime(tspec);
 
diff --git a/drivers/ptp/ptp_kvm_x86.c b/drivers/ptp/ptp_kvm_x86.c
index 902844cc1a17..2782442922cb 100644
--- a/drivers/ptp/ptp_kvm_x86.c
+++ b/drivers/ptp/ptp_kvm_x86.c
@@ -93,7 +93,8 @@ int kvm_arch_ptp_get_clock(struct timespec64 *ts)
 }
 
 int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *tspec,
-			      struct clocksource **cs)
+			      struct clocksource **cs,
+			      enum clocksource_ids *cs_id)
 {
 	struct pvclock_vcpu_time_info *src;
 	unsigned int version;
@@ -124,6 +125,7 @@ int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *tspec,
 	} while (pvclock_read_retry(src, version));
 
 	*cs = &kvm_clock;
+	*cs_id = CSID_X86_KVM_CLK;
 
 	return 0;
 }
diff --git a/include/linux/ptp_kvm.h b/include/linux/ptp_kvm.h
index 746fd67c3480..95b3d4d0d7dd 100644
--- a/include/linux/ptp_kvm.h
+++ b/include/linux/ptp_kvm.h
@@ -8,6 +8,7 @@
 #ifndef _PTP_KVM_H_
 #define _PTP_KVM_H_
 
+#include <linux/clocksource_ids.h>
 #include <linux/types.h>
 
 struct timespec64;
@@ -17,6 +18,7 @@ int kvm_arch_ptp_init(void);
 void kvm_arch_ptp_exit(void);
 int kvm_arch_ptp_get_clock(struct timespec64 *ts);
 int kvm_arch_ptp_get_crosststamp(u64 *cycle,
-		struct timespec64 *tspec, struct clocksource **cs);
+		struct timespec64 *tspec, struct clocksource **cs,
+		enum clocksource_ids *cs_id);
 
 #endif /* _PTP_KVM_H_ */
-- 
2.40.1



From peter.hilber at opensynergy.com  Fri Dec 15 14:06:05 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Fri, 15 Dec 2023 23:06:05 +0100
Subject: [RFC PATCH v2 0/7] treewide: Use clocksource id for get_device_system_crosststamp()
Message-ID: <20231215220612.173603-1-peter.hilber@opensynergy.com>

Overview
--------

This patch series changes struct system_counterval_t to identify the
clocksource through enum clocksource_ids, rather than through struct
clocksource *. The net effect of the patch series is that
get_device_system_crosststamp() callers can supply clocksource ids instead
of clocksource pointers. The pointers can be problematic to get hold of.

The series is also available at

	https://github.com/OpenSynergy/linux clocksource-id-for-xtstamp-v2

Motivation
----------

The immediate motivation for this patch series is to enable the virtio_rtc
RFC driver (v2 cf. [1], v3 to be published after this series) to refer to
the Arm Generic Timer clocksource without requiring new helper functions in
the arm_arch_timer driver. Other future get_device_system_crosststamp()
users may profit from this change as well.

Clocksource structs are normally private to clocksource drivers. Therefore,
get_device_system_crosststamp() callers require that clocksource drivers
expose the clocksource of interest in some way.

Drivers such as virtio_rtc could obtain all information for calling
get_device_system_crosststamp() from their bound device, except for
clocksource identification. Often, such drivers' only direct relation with
the clocksource driver is clocksource identification. So using the
clocksource enum, rather than obtaining pointers in a clocksource driver
specific way, would reduce the coupling between the
get_device_system_crosststamp() callers and clocksource drivers.

Affected Code
-------------

This series modifies code which is relevant to
get_device_system_crosststamp(), in timekeeping, ptp/kvm, x86/kvm, and
x86/tsc.

There are two sorts of get_device_system_crosststamp() callers in the
current kernel:

1) On Intel platforms, some PTP hardware clocks, and the HDA controller,
obtain the clocksource pointer for get_device_system_crosststamp() using
convert_art_to_tsc() or convert_art_ns_to_tsc() from arch/x86.

2) The ptp_kvm driver uses kvm_arch_ptp_get_crosststamp(), which is
implemented for platforms with kvm_clock (x86) or arm_arch_timer.
Amongst other things, kvm_arch_ptp_get_crosststamp() returns a clocksource
pointer. The Arm implementation is in the arm_arch_timer driver.

Changes
-------

The series does the following:

- add clocksource id to the get_device_system_crosststamp() param type

- add required clocksource ids and set them in
  get_device_system_crosststamp() users

- evaluate clocksource id in get_device_system_crosststamp(), rather than
  clocksource pointer

- remove now obsolete clocksource pointer field and related code

This series should not alter any behavior. Out of the existing
get_device_system_crosststamp() users, only ptp_kvm has been tested (on
x86-64 and arm64). This series is a prerequisite for the virtio_rtc driver
(of which RFC v3 is to be posted).

v2:

- Align existing changes with sketch [2] by Thomas Gleixner (omitting
  additional clocksource base changes from [2]).

- Add follow-up improvements in ptp_kvm and kvmclock.

- Split patches differently (Thomas Gleixner).

- Refer to clocksource IDs as such in comments (Thomas Gleixner).

- Update comments which were still referring to clocksource pointers.

[1] https://lore.kernel.org/all/20230818012014.212155-1-peter.hilber at opensynergy.com/
[2] https://lore.kernel.org/lkml/87lec15i4b.ffs at tglx/


Peter Hilber (7):
  timekeeping: Add clocksource ID to struct system_counterval_t
  x86/tsc: Add clocksource ID, set system_counterval_t.cs_id
  x86/kvm, ptp/kvm: Add clocksource ID, set system_counterval_t.cs_id
  ptp/kvm, arm_arch_timer: Set system_counterval_t.cs_id to constant
  timekeeping: Evaluate system_counterval_t.cs_id instead of .cs
  treewide: Remove system_counterval_t.cs, which is never read
  kvmclock: Unexport kvmclock clocksource

 arch/x86/include/asm/kvmclock.h      |  2 --
 arch/x86/kernel/kvmclock.c           |  5 +++--
 arch/x86/kernel/tsc.c                | 29 +++++++++++++++++-----------
 drivers/clocksource/arm_arch_timer.c |  6 +++---
 drivers/ptp/ptp_kvm_common.c         | 10 +++++-----
 drivers/ptp/ptp_kvm_x86.c            |  4 ++--
 include/linux/clocksource_ids.h      |  3 +++
 include/linux/ptp_kvm.h              |  4 ++--
 include/linux/timekeeping.h          | 10 ++++++----
 kernel/time/timekeeping.c            |  9 +++++----
 10 files changed, 47 insertions(+), 35 deletions(-)


base-commit: 17cb8a20bde66a520a2ca7aad1063e1ce7382240
-- 
2.40.1



From lkp at intel.com  Fri Dec 15 14:18:12 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 16 Dec 2023 06:18:12 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS
 d73ad797c83b0777407a2200bbefa3cb82759247
Message-ID: <202312160609.hdXuQPA1-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: d73ad797c83b0777407a2200bbefa3cb82759247  Merge tag 'reset-fixes-for-v6.7' of git://git.pengutronix.de/pza/linux into arm/fixes

elapsed time: 1501m

configs tested: 88
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231216   gcc  
arc                   randconfig-002-20231216   gcc  
arm                               allnoconfig   gcc  
arm                                 defconfig   clang
arm                   randconfig-001-20231216   gcc  
arm                   randconfig-002-20231216   gcc  
arm                   randconfig-003-20231216   gcc  
arm                   randconfig-004-20231216   gcc  
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
hexagon                           allnoconfig   clang
hexagon                             defconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231215   clang
i386         buildonly-randconfig-002-20231215   clang
i386         buildonly-randconfig-003-20231215   clang
i386         buildonly-randconfig-004-20231215   clang
i386         buildonly-randconfig-005-20231215   clang
i386         buildonly-randconfig-006-20231215   clang
i386                                defconfig   gcc  
i386                  randconfig-001-20231215   clang
i386                  randconfig-002-20231215   clang
i386                  randconfig-003-20231215   clang
i386                  randconfig-004-20231215   clang
i386                  randconfig-005-20231215   clang
i386                  randconfig-006-20231215   clang
i386                  randconfig-011-20231215   gcc  
i386                  randconfig-012-20231215   gcc  
i386                  randconfig-013-20231215   gcc  
i386                  randconfig-014-20231215   gcc  
i386                  randconfig-015-20231215   gcc  
i386                  randconfig-016-20231215   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                            defconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                              defconfig   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
riscv                             allnoconfig   clang
riscv                               defconfig   gcc  
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64                              defconfig   gcc  
x86_64                          rhel-8.3-rust   clang
xtensa                            allnoconfig   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Fri Dec 15 14:21:23 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 16 Dec 2023 06:21:23 +0800
Subject: [soc:for-next] BUILD SUCCESS
 16bcd9a4a33275a3f35670e06fbaac04950540d1
Message-ID: <202312160620.lt12OhoZ-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 16bcd9a4a33275a3f35670e06fbaac04950540d1  Merge branch 'arm/fixes' into for-next

elapsed time: 1504m

configs tested: 110
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231216   gcc  
arc                   randconfig-002-20231216   gcc  
arm                               allnoconfig   gcc  
arm                         axm55xx_defconfig   gcc  
arm                                 defconfig   clang
arm                        multi_v5_defconfig   clang
arm                        mvebu_v7_defconfig   gcc  
arm                        neponset_defconfig   clang
arm                           omap1_defconfig   clang
arm                   randconfig-001-20231216   gcc  
arm                   randconfig-002-20231216   gcc  
arm                   randconfig-003-20231216   gcc  
arm                   randconfig-004-20231216   gcc  
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231216   gcc  
arm64                 randconfig-002-20231216   gcc  
arm64                 randconfig-003-20231216   gcc  
arm64                 randconfig-004-20231216   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231216   gcc  
csky                  randconfig-002-20231216   gcc  
hexagon                           allnoconfig   clang
hexagon                             defconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231215   clang
i386         buildonly-randconfig-002-20231215   clang
i386         buildonly-randconfig-003-20231215   clang
i386         buildonly-randconfig-004-20231215   clang
i386         buildonly-randconfig-005-20231215   clang
i386         buildonly-randconfig-006-20231215   clang
i386                                defconfig   gcc  
i386                  randconfig-001-20231215   clang
i386                  randconfig-002-20231215   clang
i386                  randconfig-003-20231215   clang
i386                  randconfig-004-20231215   clang
i386                  randconfig-005-20231215   clang
i386                  randconfig-006-20231215   clang
i386                  randconfig-011-20231215   gcc  
i386                  randconfig-012-20231215   gcc  
i386                  randconfig-013-20231215   gcc  
i386                  randconfig-014-20231215   gcc  
i386                  randconfig-015-20231215   gcc  
i386                  randconfig-016-20231215   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                         apollo_defconfig   gcc  
m68k                                defconfig   gcc  
m68k                        stmark2_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
mips                          rb532_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                    ge_imp3a_defconfig   gcc  
riscv                             allnoconfig   clang
riscv                               defconfig   gcc  
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231216   gcc  
x86_64       buildonly-randconfig-002-20231216   gcc  
x86_64       buildonly-randconfig-003-20231216   gcc  
x86_64       buildonly-randconfig-004-20231216   gcc  
x86_64                              defconfig   gcc  
x86_64                          rhel-8.3-rust   clang
xtensa                            allnoconfig   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From ben.wolsieffer at hefring.com  Fri Dec 15 14:22:03 2023
From: ben.wolsieffer at hefring.com (Ben Wolsieffer)
Date: Fri, 15 Dec 2023 17:22:03 -0500
Subject: [PATCH] spi: stm32: use runtime PM to enable/disable controller
In-Reply-To: <20231215182739.GA96945@gnbcxd0016.gnb.st.com>
References: <20231204202055.2895125-1-ben.wolsieffer@hefring.com>
 <58897511-3187-4583-bf29-11871dd4d136@sirena.org.uk>
 <20231215182739.GA96945@gnbcxd0016.gnb.st.com>
Message-ID: <ZXzRi_h2AMqEhMVw@dell-precision-5540>

On Fri, Dec 15, 2023 at 07:27:39PM +0100, Alain Volmat wrote:
> Hi,
> 
> sorry for the delay.
> 
> On Thu, Dec 14, 2023 at 10:58:54AM +0000, Mark Brown wrote:
> > On Mon, Dec 04, 2023 at 03:20:55PM -0500, Ben Wolsieffer wrote:
> > > Instead of disabling the SPI controller between each message, do it
> > > as part of runtime PM.
> > 
> > This doesn't apply against current code, please check and resend.
> 
> I rapidly gave a try on this patch on top of the spi/for-next branch
> (manually fixing the conflict due to the MASTER->HOST renaming).
> It turns out that with that applied, transfers on the MP13
> (compatible: st,stm32h7-spi) are not working anymore while simply
> removing it back it works again.
> (test is simply doing loopback spidev_test)

That's unfortunate; I was worried about something like this because I
only have an STM32F7 to test. If you can't easily determine what's going
wrong, it would be interesting to know if the original version of this
patch has the same problem:
https://lore.kernel.org/lkml/ZWpoKEcM0ZeYAsBa at dell-precision-5540/T/

> 
> spi mode: 0x0
> bits per word: 8
> max speed: 500000 Hz (500 kHz)
> TX | 8D D6 73 8B 9D 8B 1C 7D 8D 80 EC 32 F9 0D BA AD 9F 88 A5 9B 3F AA 48 8C 21 35 0D C1 C8 E5 6A 81  |..s....}...2........?.H.!5....j.|
> RX | 8D 00 00 00 D6 00 73 00 8B 00 00 00 9D 00 00 8B 1C 00 00 00 7D 00 00 8D F9 00 00 00 BA 00 00 00  |......s.............}...........|
> 
> The RX data contains lots of 00 between each byte.  Moreover it seems
> that with this patch applied non-dma transfer (when there is no dmas
> properties within the node) are now failing.
> 
> I'll check that and give more details but could you avoid applying this
> patch for the time being ?
> 
> Thanks.
> Alain


From david at ixit.cz  Fri Dec 15 15:07:35 2023
From: david at ixit.cz (David Heidelberg)
Date: Sat, 16 Dec 2023 00:07:35 +0100
Subject: [RESEND PATCH] arm64: dts: freescale: fix the schema check errors for fsl,tmu-calibration
Message-ID: <20231215230743.86194-1-david@ixit.cz>

fsl,tmu-calibration contains cell pairs (u32-matrix). Mark them as such.

Use matching property syntax and allow correct validation.

No functional changes.

Signed-off-by: David Heidelberg <david at ixit.cz>
---
 .../arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 79 ++++++++---------
 .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 87 ++++++++++---------
 .../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 81 ++++++++---------
 .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 74 ++++++++--------
 .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 74 ++++++++--------
 .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 73 ++++++++--------
 .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi |  4 +-
 7 files changed, 238 insertions(+), 234 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index d0733451d3ce..1e3fe3897b52 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -307,45 +307,46 @@ tmu: tmu at 1f00000 {
 			reg = <0x0 0x1f00000 0x0 0x10000>;
 			interrupts = <0 33 0x4>;
 			fsl,tmu-range = <0xb0000 0x9002a 0x6004c 0x60062>;
-			fsl,tmu-calibration = <0x00000000 0x00000025
-					       0x00000001 0x0000002c
-					       0x00000002 0x00000032
-					       0x00000003 0x00000039
-					       0x00000004 0x0000003f
-					       0x00000005 0x00000046
-					       0x00000006 0x0000004c
-					       0x00000007 0x00000053
-					       0x00000008 0x00000059
-					       0x00000009 0x0000005f
-					       0x0000000a 0x00000066
-					       0x0000000b 0x0000006c
-
-					       0x00010000 0x00000026
-					       0x00010001 0x0000002d
-					       0x00010002 0x00000035
-					       0x00010003 0x0000003d
-					       0x00010004 0x00000045
-					       0x00010005 0x0000004d
-					       0x00010006 0x00000055
-					       0x00010007 0x0000005d
-					       0x00010008 0x00000065
-					       0x00010009 0x0000006d
-
-					       0x00020000 0x00000026
-					       0x00020001 0x00000030
-					       0x00020002 0x0000003a
-					       0x00020003 0x00000044
-					       0x00020004 0x0000004e
-					       0x00020005 0x00000059
-					       0x00020006 0x00000063
-
-					       0x00030000 0x00000014
-					       0x00030001 0x00000021
-					       0x00030002 0x0000002e
-					       0x00030003 0x0000003a
-					       0x00030004 0x00000047
-					       0x00030005 0x00000053
-					       0x00030006 0x00000060>;
+			fsl,tmu-calibration =
+					<0x00000000 0x00000025>,
+					<0x00000001 0x0000002c>,
+					<0x00000002 0x00000032>,
+					<0x00000003 0x00000039>,
+					<0x00000004 0x0000003f>,
+					<0x00000005 0x00000046>,
+					<0x00000006 0x0000004c>,
+					<0x00000007 0x00000053>,
+					<0x00000008 0x00000059>,
+					<0x00000009 0x0000005f>,
+					<0x0000000a 0x00000066>,
+					<0x0000000b 0x0000006c>,
+
+					<0x00010000 0x00000026>,
+					<0x00010001 0x0000002d>,
+					<0x00010002 0x00000035>,
+					<0x00010003 0x0000003d>,
+					<0x00010004 0x00000045>,
+					<0x00010005 0x0000004d>,
+					<0x00010006 0x00000055>,
+					<0x00010007 0x0000005d>,
+					<0x00010008 0x00000065>,
+					<0x00010009 0x0000006d>,
+
+					<0x00020000 0x00000026>,
+					<0x00020001 0x00000030>,
+					<0x00020002 0x0000003a>,
+					<0x00020003 0x00000044>,
+					<0x00020004 0x0000004e>,
+					<0x00020005 0x00000059>,
+					<0x00020006 0x00000063>,
+
+					<0x00030000 0x00000014>,
+					<0x00030001 0x00000021>,
+					<0x00030002 0x0000002e>,
+					<0x00030003 0x0000003a>,
+					<0x00030004 0x00000047>,
+					<0x00030005 0x00000053>,
+					<0x00030006 0x00000060>;
 			#thermal-sensor-cells = <1>;
 		};
 
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index eefe3577d94e..ae534c23b970 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -1026,49 +1026,50 @@ tmu: tmu at 1f80000 {
 			reg = <0x0 0x1f80000 0x0 0x10000>;
 			interrupts = <0 23 0x4>;
 			fsl,tmu-range = <0xb0000 0xa0026 0x80048 0x70061>;
-			fsl,tmu-calibration = <0x00000000 0x00000024
-					       0x00000001 0x0000002b
-					       0x00000002 0x00000031
-					       0x00000003 0x00000038
-					       0x00000004 0x0000003f
-					       0x00000005 0x00000045
-					       0x00000006 0x0000004c
-					       0x00000007 0x00000053
-					       0x00000008 0x00000059
-					       0x00000009 0x00000060
-					       0x0000000a 0x00000066
-					       0x0000000b 0x0000006d
-
-					       0x00010000 0x0000001c
-					       0x00010001 0x00000024
-					       0x00010002 0x0000002c
-					       0x00010003 0x00000035
-					       0x00010004 0x0000003d
-					       0x00010005 0x00000045
-					       0x00010006 0x0000004d
-					       0x00010007 0x00000055
-					       0x00010008 0x0000005e
-					       0x00010009 0x00000066
-					       0x0001000a 0x0000006e
-
-					       0x00020000 0x00000018
-					       0x00020001 0x00000022
-					       0x00020002 0x0000002d
-					       0x00020003 0x00000038
-					       0x00020004 0x00000043
-					       0x00020005 0x0000004d
-					       0x00020006 0x00000058
-					       0x00020007 0x00000063
-					       0x00020008 0x0000006e
-
-					       0x00030000 0x00000010
-					       0x00030001 0x0000001c
-					       0x00030002 0x00000029
-					       0x00030003 0x00000036
-					       0x00030004 0x00000042
-					       0x00030005 0x0000004f
-					       0x00030006 0x0000005b
-					       0x00030007 0x00000068>;
+			fsl,tmu-calibration =
+					<0x00000000 0x00000024>,
+					<0x00000001 0x0000002b>,
+					<0x00000002 0x00000031>,
+					<0x00000003 0x00000038>,
+					<0x00000004 0x0000003f>,
+					<0x00000005 0x00000045>,
+					<0x00000006 0x0000004c>,
+					<0x00000007 0x00000053>,
+					<0x00000008 0x00000059>,
+					<0x00000009 0x00000060>,
+					<0x0000000a 0x00000066>,
+					<0x0000000b 0x0000006d>,
+
+					<0x00010000 0x0000001c>,
+					<0x00010001 0x00000024>,
+					<0x00010002 0x0000002c>,
+					<0x00010003 0x00000035>,
+					<0x00010004 0x0000003d>,
+					<0x00010005 0x00000045>,
+					<0x00010006 0x0000004d>,
+					<0x00010007 0x00000055>,
+					<0x00010008 0x0000005e>,
+					<0x00010009 0x00000066>,
+					<0x0001000a 0x0000006e>,
+
+					<0x00020000 0x00000018>,
+					<0x00020001 0x00000022>,
+					<0x00020002 0x0000002d>,
+					<0x00020003 0x00000038>,
+					<0x00020004 0x00000043>,
+					<0x00020005 0x0000004d>,
+					<0x00020006 0x00000058>,
+					<0x00020007 0x00000063>,
+					<0x00020008 0x0000006e>,
+
+					<0x00030000 0x00000010>,
+					<0x00030001 0x0000001c>,
+					<0x00030002 0x00000029>,
+					<0x00030003 0x00000036>,
+					<0x00030004 0x00000042>,
+					<0x00030005 0x0000004f>,
+					<0x00030006 0x0000005b>,
+					<0x00030007 0x00000068>;
 			little-endian;
 			#thermal-sensor-cells = <1>;
 		};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 229bb4bebe42..d333b773bc45 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -447,46 +447,47 @@ tmu: tmu at 1f00000 {
 			reg = <0x0 0x1f00000 0x0 0x10000>;
 			interrupts = <0 33 0x4>;
 			fsl,tmu-range = <0xb0000 0x9002a 0x6004c 0x70062>;
-			fsl,tmu-calibration = <0x00000000 0x00000023
-					       0x00000001 0x0000002a
-					       0x00000002 0x00000031
-					       0x00000003 0x00000037
-					       0x00000004 0x0000003e
-					       0x00000005 0x00000044
-					       0x00000006 0x0000004b
-					       0x00000007 0x00000051
-					       0x00000008 0x00000058
-					       0x00000009 0x0000005e
-					       0x0000000a 0x00000065
-					       0x0000000b 0x0000006b
-
-					       0x00010000 0x00000023
-					       0x00010001 0x0000002b
-					       0x00010002 0x00000033
-					       0x00010003 0x0000003b
-					       0x00010004 0x00000043
-					       0x00010005 0x0000004b
-					       0x00010006 0x00000054
-					       0x00010007 0x0000005c
-					       0x00010008 0x00000064
-					       0x00010009 0x0000006c
-
-					       0x00020000 0x00000021
-					       0x00020001 0x0000002c
-					       0x00020002 0x00000036
-					       0x00020003 0x00000040
-					       0x00020004 0x0000004b
-					       0x00020005 0x00000055
-					       0x00020006 0x0000005f
-
-					       0x00030000 0x00000013
-					       0x00030001 0x0000001d
-					       0x00030002 0x00000028
-					       0x00030003 0x00000032
-					       0x00030004 0x0000003d
-					       0x00030005 0x00000047
-					       0x00030006 0x00000052
-					       0x00030007 0x0000005c>;
+			fsl,tmu-calibration =
+					<0x00000000 0x00000023>,
+					<0x00000001 0x0000002a>,
+					<0x00000002 0x00000031>,
+					<0x00000003 0x00000037>,
+					<0x00000004 0x0000003e>,
+					<0x00000005 0x00000044>,
+					<0x00000006 0x0000004b>,
+					<0x00000007 0x00000051>,
+					<0x00000008 0x00000058>,
+					<0x00000009 0x0000005e>,
+					<0x0000000a 0x00000065>,
+					<0x0000000b 0x0000006b>,
+
+					<0x00010000 0x00000023>,
+					<0x00010001 0x0000002b>,
+					<0x00010002 0x00000033>,
+					<0x00010003 0x0000003b>,
+					<0x00010004 0x00000043>,
+					<0x00010005 0x0000004b>,
+					<0x00010006 0x00000054>,
+					<0x00010007 0x0000005c>,
+					<0x00010008 0x00000064>,
+					<0x00010009 0x0000006c>,
+
+					<0x00020000 0x00000021>,
+					<0x00020001 0x0000002c>,
+					<0x00020002 0x00000036>,
+					<0x00020003 0x00000040>,
+					<0x00020004 0x0000004b>,
+					<0x00020005 0x00000055>,
+					<0x00020006 0x0000005f>,
+
+					<0x00030000 0x00000013>,
+					<0x00030001 0x0000001d>,
+					<0x00030002 0x00000028>,
+					<0x00030003 0x00000032>,
+					<0x00030004 0x0000003d>,
+					<0x00030005 0x00000047>,
+					<0x00030006 0x00000052>,
+					<0x00030007 0x0000005c>;
 			#thermal-sensor-cells = <1>;
 		};
 
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 50f68ca5a9af..1515cec23147 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -445,46 +445,46 @@ tmu: tmu at 1f00000 {
 			fsl,tmu-range = <0xb0000 0x9002a 0x6004c 0x70062>;
 			fsl,tmu-calibration =
 				/* Calibration data group 1 */
-				<0x00000000 0x00000023
-				0x00000001 0x00000029
-				0x00000002 0x0000002f
-				0x00000003 0x00000036
-				0x00000004 0x0000003c
-				0x00000005 0x00000042
-				0x00000006 0x00000049
-				0x00000007 0x0000004f
-				0x00000008 0x00000055
-				0x00000009 0x0000005c
-				0x0000000a 0x00000062
-				0x0000000b 0x00000068
+				<0x00000000 0x00000023>,
+				<0x00000001 0x00000029>,
+				<0x00000002 0x0000002f>,
+				<0x00000003 0x00000036>,
+				<0x00000004 0x0000003c>,
+				<0x00000005 0x00000042>,
+				<0x00000006 0x00000049>,
+				<0x00000007 0x0000004f>,
+				<0x00000008 0x00000055>,
+				<0x00000009 0x0000005c>,
+				<0x0000000a 0x00000062>,
+				<0x0000000b 0x00000068>,
 				/* Calibration data group 2 */
-				0x00010000 0x00000022
-				0x00010001 0x0000002a
-				0x00010002 0x00000032
-				0x00010003 0x0000003a
-				0x00010004 0x00000042
-				0x00010005 0x0000004a
-				0x00010006 0x00000052
-				0x00010007 0x0000005a
-				0x00010008 0x00000062
-				0x00010009 0x0000006a
+				<0x00010000 0x00000022>,
+				<0x00010001 0x0000002a>,
+				<0x00010002 0x00000032>,
+				<0x00010003 0x0000003a>,
+				<0x00010004 0x00000042>,
+				<0x00010005 0x0000004a>,
+				<0x00010006 0x00000052>,
+				<0x00010007 0x0000005a>,
+				<0x00010008 0x00000062>,
+				<0x00010009 0x0000006a>,
 				/* Calibration data group 3 */
-				0x00020000 0x00000021
-				0x00020001 0x0000002b
-				0x00020002 0x00000035
-				0x00020003 0x0000003e
-				0x00020004 0x00000048
-				0x00020005 0x00000052
-				0x00020006 0x0000005c
+				<0x00020000 0x00000021>,
+				<0x00020001 0x0000002b>,
+				<0x00020002 0x00000035>,
+				<0x00020003 0x0000003e>,
+				<0x00020004 0x00000048>,
+				<0x00020005 0x00000052>,
+				<0x00020006 0x0000005c>,
 				/* Calibration data group 4 */
-				0x00030000 0x00000011
-				0x00030001 0x0000001a
-				0x00030002 0x00000024
-				0x00030003 0x0000002e
-				0x00030004 0x00000038
-				0x00030005 0x00000042
-				0x00030006 0x0000004c
-				0x00030007 0x00000056>;
+				<0x00030000 0x00000011>,
+				<0x00030001 0x0000001a>,
+				<0x00030002 0x00000024>,
+				<0x00030003 0x0000002e>,
+				<0x00030004 0x00000038>,
+				<0x00030005 0x00000042>,
+				<0x00030006 0x0000004c>,
+				<0x00030007 0x00000056>;
 			big-endian;
 			#thermal-sensor-cells = <1>;
 		};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 8f6090a9aef2..8616d5e0c388 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -284,46 +284,46 @@ tmu: tmu at 1f80000 {
 			fsl,tmu-range = <0xb0000 0x9002a 0x6004c 0x70062>;
 			fsl,tmu-calibration =
 				/* Calibration data group 1 */
-				<0x00000000 0x00000023
-				0x00000001 0x0000002a
-				0x00000002 0x00000030
-				0x00000003 0x00000037
-				0x00000004 0x0000003d
-				0x00000005 0x00000044
-				0x00000006 0x0000004a
-				0x00000007 0x00000051
-				0x00000008 0x00000057
-				0x00000009 0x0000005e
-				0x0000000a 0x00000064
-				0x0000000b 0x0000006b
+				<0x00000000 0x00000023>,
+				<0x00000001 0x0000002a>,
+				<0x00000002 0x00000030>,
+				<0x00000003 0x00000037>,
+				<0x00000004 0x0000003d>,
+				<0x00000005 0x00000044>,
+				<0x00000006 0x0000004a>,
+				<0x00000007 0x00000051>,
+				<0x00000008 0x00000057>,
+				<0x00000009 0x0000005e>,
+				<0x0000000a 0x00000064>,
+				<0x0000000b 0x0000006b>,
 				/* Calibration data group 2 */
-				0x00010000 0x00000022
-				0x00010001 0x0000002a
-				0x00010002 0x00000032
-				0x00010003 0x0000003a
-				0x00010004 0x00000042
-				0x00010005 0x0000004a
-				0x00010006 0x00000052
-				0x00010007 0x0000005a
-				0x00010008 0x00000062
-				0x00010009 0x0000006a
+				<0x00010000 0x00000022>,
+				<0x00010001 0x0000002a>,
+				<0x00010002 0x00000032>,
+				<0x00010003 0x0000003a>,
+				<0x00010004 0x00000042>,
+				<0x00010005 0x0000004a>,
+				<0x00010006 0x00000052>,
+				<0x00010007 0x0000005a>,
+				<0x00010008 0x00000062>,
+				<0x00010009 0x0000006a>,
 				/* Calibration data group 3 */
-				0x00020000 0x00000021
-				0x00020001 0x0000002b
-				0x00020002 0x00000035
-				0x00020003 0x00000040
-				0x00020004 0x0000004a
-				0x00020005 0x00000054
-				0x00020006 0x0000005e
+				<0x00020000 0x00000021>,
+				<0x00020001 0x0000002b>,
+				<0x00020002 0x00000035>,
+				<0x00020003 0x00000040>,
+				<0x00020004 0x0000004a>,
+				<0x00020005 0x00000054>,
+				<0x00020006 0x0000005e>,
 				/* Calibration data group 4 */
-				0x00030000 0x00000010
-				0x00030001 0x0000001c
-				0x00030002 0x00000027
-				0x00030003 0x00000032
-				0x00030004 0x0000003e
-				0x00030005 0x00000049
-				0x00030006 0x00000054
-				0x00030007 0x00000060>;
+				<0x00030000 0x00000010>,
+				<0x00030001 0x0000001c>,
+				<0x00030002 0x00000027>,
+				<0x00030003 0x00000032>,
+				<0x00030004 0x0000003e>,
+				<0x00030005 0x00000049>,
+				<0x00030006 0x00000054>,
+				<0x00030007 0x00000060>;
 			little-endian;
 			#thermal-sensor-cells = <1>;
 		};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 717288bbdb8b..0b7292835906 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -321,42 +321,43 @@ tmu: tmu at 1f80000 {
 			reg = <0x0 0x1f80000 0x0 0x10000>;
 			interrupts = <0 23 0x4>;
 			fsl,tmu-range = <0xb0000 0x9002a 0x6004c 0x30062>;
-			fsl,tmu-calibration = <0x00000000 0x00000026
-					       0x00000001 0x0000002d
-					       0x00000002 0x00000032
-					       0x00000003 0x00000039
-					       0x00000004 0x0000003f
-					       0x00000005 0x00000046
-					       0x00000006 0x0000004d
-					       0x00000007 0x00000054
-					       0x00000008 0x0000005a
-					       0x00000009 0x00000061
-					       0x0000000a 0x0000006a
-					       0x0000000b 0x00000071
-
-					       0x00010000 0x00000025
-					       0x00010001 0x0000002c
-					       0x00010002 0x00000035
-					       0x00010003 0x0000003d
-					       0x00010004 0x00000045
-					       0x00010005 0x0000004e
-					       0x00010006 0x00000057
-					       0x00010007 0x00000061
-					       0x00010008 0x0000006b
-					       0x00010009 0x00000076
-
-					       0x00020000 0x00000029
-					       0x00020001 0x00000033
-					       0x00020002 0x0000003d
-					       0x00020003 0x00000049
-					       0x00020004 0x00000056
-					       0x00020005 0x00000061
-					       0x00020006 0x0000006d
-
-					       0x00030000 0x00000021
-					       0x00030001 0x0000002a
-					       0x00030002 0x0000003c
-					       0x00030003 0x0000004e>;
+			fsl,tmu-calibration =
+					<0x00000000 0x00000026>,
+					<0x00000001 0x0000002d>,
+					<0x00000002 0x00000032>,
+					<0x00000003 0x00000039>,
+					<0x00000004 0x0000003f>,
+					<0x00000005 0x00000046>,
+					<0x00000006 0x0000004d>,
+					<0x00000007 0x00000054>,
+					<0x00000008 0x0000005a>,
+					<0x00000009 0x00000061>,
+					<0x0000000a 0x0000006a>,
+					<0x0000000b 0x00000071>,
+
+					<0x00010000 0x00000025>,
+					<0x00010001 0x0000002c>,
+					<0x00010002 0x00000035>,
+					<0x00010003 0x0000003d>,
+					<0x00010004 0x00000045>,
+					<0x00010005 0x0000004e>,
+					<0x00010006 0x00000057>,
+					<0x00010007 0x00000061>,
+					<0x00010008 0x0000006b>,
+					<0x00010009 0x00000076>,
+
+					<0x00020000 0x00000029>,
+					<0x00020001 0x00000033>,
+					<0x00020002 0x0000003d>,
+					<0x00020003 0x00000049>,
+					<0x00020004 0x00000056>,
+					<0x00020005 0x00000061>,
+					<0x00020006 0x0000006d>,
+
+					<0x00030000 0x00000021>,
+					<0x00030001 0x0000002a>,
+					<0x00030002 0x0000003c>,
+					<0x00030003 0x0000004e>;
 			little-endian;
 			#thermal-sensor-cells = <1>;
 		};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index f176ca2e244e..6640b49670ae 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -732,9 +732,9 @@ tmu: tmu at 1f80000 {
 			fsl,tmu-range = <0x800000e6 0x8001017d>;
 			fsl,tmu-calibration =
 				/* Calibration data group 1 */
-				<0x00000000 0x00000035
+				<0x00000000 0x00000035>,
 				/* Calibration data group 2 */
-				0x00000001 0x00000154>;
+				<0x00000001 0x00000154>;
 			little-endian;
 			#thermal-sensor-cells = <1>;
 		};
-- 
2.43.0



From konrad.dybcio at linaro.org  Fri Dec 15 15:30:04 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Sat, 16 Dec 2023 00:30:04 +0100
Subject: [PATCH 16/18] perf: qcom_l2: Convert to platform remove callback
 returning void
In-Reply-To: <a2587688c54834482d68fe2a44f415a649ad6477.1702648125.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702648124.git.u.kleine-koenig@pengutronix.de>
 <a2587688c54834482d68fe2a44f415a649ad6477.1702648125.git.u.kleine-koenig@pengutronix.de>
Message-ID: <37ab347b-2d94-42a9-97d0-274ed8a4c791@linaro.org>

On 15.12.2023 14:59, Uwe Kleine-K?nig wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> 
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio at linaro.org>

Konrad


From konrad.dybcio at linaro.org  Fri Dec 15 15:35:51 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Sat, 16 Dec 2023 00:35:51 +0100
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <20231215101827.30549-4-quic_bibekkum@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
Message-ID: <e4329952-34ac-4458-a63c-1f64e288614c@linaro.org>

On 15.12.2023 11:18, Bibek Kumar Patro wrote:
> Add ACTLR data table for SM8550 along with support for
> same including SM8550 specific implementation operations.
> 
> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
> ---
[...]

> +static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
> +	.impl = &qcom_smmu_500_impl,
> +	.adreno_impl = &qcom_adreno_smmu_500_impl,
> +	.cfg = &qcom_smmu_impl0_cfg,
> +	.actlrcfg = sm8550_apps_actlr_cfg,
> +	.actlrcfg_gfx = sm8550_gfx_actlr_cfg,
There are platforms that feature more than just APPS and Adreno SMMUs,
this implementation seems to assume there's only these two :/

I suppose the only way to solve this would be to introduce new compatibles
for each one of them.. Krzysztof, do you think that's reasonable? E.g.
MSM8996 has at least 5 instances, 8998 has at least 4 etc.

Konrad


From catalin.marinas at arm.com  Fri Dec 15 15:47:20 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 15 Dec 2023 23:47:20 +0000
Subject: [GIT PULL] arm64 fixes for 6.7-rc6
Message-ID: <ZXzliF7K4P32ZSYk@arm.com>

Hi Linus,

Please pull the arm64 fixes below. Thanks.

The following changes since commit f5259997f3e8d6edfcc2daf5b2c0b34f074d7bc0:

  arm64: Avoid enabling KPTI unnecessarily (2023-11-30 19:07:33 +0000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

for you to fetch changes up to 3c0696076aad60a2f04c019761921954579e1b0e:

  arm64: mm: Always make sw-dirty PTEs hw-dirty in pte_modify (2023-12-12 16:25:26 +0000)

----------------------------------------------------------------
arm64 fixes:

- Arm CMN perf: fix the DTC allocation failure path which can end up
  erroneously clearing live counters

- arm64/mm: fix hugetlb handling of the dirty page state leading to a
  continuous fault loop in user on hardware without dirty bit management
  (DBM). That's caused by the dirty+writeable information not being
  properly preserved across a series of mprotect(PROT_NONE),
  mprotect(PROT_READ|PROT_WRITE)

----------------------------------------------------------------
James Houghton (1):
      arm64: mm: Always make sw-dirty PTEs hw-dirty in pte_modify

Robin Murphy (1):
      perf/arm-cmn: Fail DTC counter allocation correctly

 arch/arm64/include/asm/pgtable.h | 6 ++++++
 drivers/perf/arm-cmn.c           | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

-- 
Catalin


From konrad.dybcio at linaro.org  Fri Dec 15 15:54:52 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Sat, 16 Dec 2023 00:54:52 +0100
Subject: [PATCH v4 5/5] iommu/arm-smmu: re-enable context caching in smmu
 reset operation
In-Reply-To: <20231215101827.30549-6-quic_bibekkum@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-6-quic_bibekkum@quicinc.com>
Message-ID: <3c7b8c2c-7174-4ced-8954-5a249f792c1e@linaro.org>

On 15.12.2023 11:18, Bibek Kumar Patro wrote:
> Default MMU-500 reset operation disables context caching in
> prefetch buffer. It is however expected for context banks using
> the ACTLR register to retain their prefetch value during reset
> and runtime suspend.
> 
> Replace default MMU-500 reset operation with Qualcomm specific reset
> operation which envelope the default reset operation and re-enables
> context caching in prefetch buffer for Qualcomm SoCs.
> 
> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
> ---
This probably deserves a fixes tag, but I can't find a good commit for
it, so I guess not having it is fine as well.

Also, since it seems to be independent from the rest of the patches, please
reorder it to become patch 1 in the next spin, so that it can perhaps be
easily picked up independently of the rest.

>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 23 +++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index c8f5dd4186b7..70d2a5d43993 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -516,11 +516,28 @@ static int qcom_smmu_def_domain_type(struct device *dev)
>  	return match ? IOMMU_DOMAIN_IDENTITY : 0;
>  }
> 
> +static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
> +{
> +	int i;
> +	u32 reg;
That's rather nitty/codestyle-y, but:

- reverse Christmas tree would be nice (it's in a week! :D)
- "reg" to me sounds like "register address", "val" is used widely for
  register values

> +
> +	arm_mmu500_reset(smmu);
We should check the return value here, in case the function is modified
some day in a way that makes it return something else than 0

LGTM otherwise!

Konrad


From tanmay.shah at amd.com  Fri Dec 15 15:57:24 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Fri, 15 Dec 2023 15:57:24 -0800
Subject: [PATCH v8 2/3] dts: zynqmp: add properties for TCM in remoteproc
In-Reply-To: <20231215235725.1247350-1-tanmay.shah@amd.com>
References: <20231215235725.1247350-1-tanmay.shah@amd.com>
Message-ID: <20231215235725.1247350-3-tanmay.shah@amd.com>

Add properties as per new bindings in zynqmp remoteproc node
to represent TCM address and size.

This patch also adds alternative remoteproc node to represent
remoteproc cluster in split mode. By default lockstep mode is
enabled and users should disable it before using split mode
dts. Both device-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.

Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
---
 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |  8 +++
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi        | 60 +++++++++++++++++--
 2 files changed, 63 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
index c8f71a1aec89..495ca94b45db 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
@@ -14,6 +14,14 @@ / {
 	compatible = "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102", "xlnx,zynqmp";
 };
 
+&rproc_split {
+	status = "okay";
+};
+
+&rproc_lockstep {
+	status = "disabled";
+};
+
 &eeprom {
 	#address-cells = <1>;
 	#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index b61fc99cd911..602e6aba7ac5 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -247,19 +247,69 @@ fpga_full: fpga-full {
 		ranges;
 	};
 
-	remoteproc {
+	rproc_lockstep: remoteproc at ffe00000 {
 		compatible = "xlnx,zynqmp-r5fss";
 		xlnx,cluster-mode = <1>;
 
-		r5f-0 {
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x20000>,
+			 <0x0 0x20000 0x0 0xffe20000 0x0 0x20000>,
+			 <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
+			 <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
+
+		r5f at 0 {
+			compatible = "xlnx,zynqmp-r5f";
+			reg = <0x0 0x0 0x0 0x20000>, <0x0 0x20000 0x0 0x20000>;
+			reg-names = "atcm", "btcm";
+			power-domains = <&zynqmp_firmware PD_RPU_0>,
+					<&zynqmp_firmware PD_R5_0_ATCM>,
+					<&zynqmp_firmware PD_R5_0_BTCM>;
+			memory-region = <&rproc_0_fw_image>;
+		};
+
+		r5f at 1 {
+			compatible = "xlnx,zynqmp-r5f";
+			reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+			reg-names = "atcm", "btcm";
+			power-domains = <&zynqmp_firmware PD_RPU_1>,
+					<&zynqmp_firmware PD_R5_1_ATCM>,
+					<&zynqmp_firmware PD_R5_1_BTCM>;
+			memory-region = <&rproc_1_fw_image>;
+		};
+	};
+
+	rproc_split: remoteproc-split at ffe00000 {
+		status = "disabled";
+		compatible = "xlnx,zynqmp-r5fss";
+		xlnx,cluster-mode = <0>;
+
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
+			 <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
+			 <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
+			 <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
+
+		r5f at 0 {
 			compatible = "xlnx,zynqmp-r5f";
-			power-domains = <&zynqmp_firmware PD_RPU_0>;
+			reg = <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0x0 0x10000>;
+			reg-names = "atcm", "btcm";
+			power-domains = <&zynqmp_firmware PD_RPU_0>,
+					<&zynqmp_firmware PD_R5_0_ATCM>,
+					<&zynqmp_firmware PD_R5_0_BTCM>;
 			memory-region = <&rproc_0_fw_image>;
 		};
 
-		r5f-1 {
+		r5f at 1 {
 			compatible = "xlnx,zynqmp-r5f";
-			power-domains = <&zynqmp_firmware PD_RPU_1>;
+			reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+			reg-names = "atcm", "btcm";
+			power-domains = <&zynqmp_firmware PD_RPU_1>,
+					<&zynqmp_firmware PD_R5_1_ATCM>,
+					<&zynqmp_firmware PD_R5_1_BTCM>;
 			memory-region = <&rproc_1_fw_image>;
 		};
 	};
-- 
2.25.1



From tanmay.shah at amd.com  Fri Dec 15 15:57:22 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Fri, 15 Dec 2023 15:57:22 -0800
Subject: [PATCH v8 0/3] add zynqmp TCM bindings
Message-ID: <20231215235725.1247350-1-tanmay.shah@amd.com>

Tightly-Coupled Memories(TCMs) are low-latency memory that provides
predictable instruction execution and predictable data load/store
timing. Each Cortex-R5F processor contains exclusive two 64 KB memory
banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
In lockstep mode, both 128KB memory is accessible to the cluster.

As per ZynqMP Ultrascale+ Technical Reference Manual UG1085, following
is address space of TCM memory. The bindings in this patch series
introduces properties to accommodate following address space with
address translation between Linux and Cortex-R5 views.

|     |     |     |
| --- | --- | --- |
|      *Mode*        |   *R5 View* | *Linux view* |  Notes               |
| *Split Mode*       | *start addr*| *start addr* |                      |
| R5_0 ATCM (64 KB)  | 0x0000_0000 | 0xFFE0_0000  |                      |
| R5_0 BTCM (64 KB)  | 0x0002_0000 | 0xFFE2_0000  |                      |
| R5_1 ATCM (64 KB)  | 0x0000_0000 | 0xFFE9_0000  | alias of 0xFFE1_0000 |
| R5_1 BTCM (64 KB)  | 0x0002_0000 | 0xFFEB_0000  | alias of 0xFFE3_0000 |
|  ___               |     ___     |    ___       |                      |
| *Lockstep Mode*    |             |              |                      |
| R5_0 ATCM (128 KB) | 0x0000_0000 | 0xFFE0_0000  |                      |
| R5_0 BTCM (128 KB) | 0x0002_0000 | 0xFFE2_0000  |                      |

References:
UG1085 TCM address space:
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Tightly-Coupled-Memory-Address-Map

Changes in v8:
  - Remove use of pm_domains framework
  - Remove checking of pm_domain_id validation to power on/off tcm
  - Remove spurious change
  - parse power-domains property from device-tree and use EEMI calls
    to power on/off TCM instead of using pm domains framework

Changes in v7:
  - %s/pm_dev1/pm_dev_core0/r
  - %s/pm_dev_link1/pm_dev_core0_link/r
  - %s/pm_dev2/pm_dev_core1/r
  - %s/pm_dev_link2/pm_dev_core1_link/r
  - remove pm_domain_id check to move next patch
  - add comment about how 1st entry in pm domain list is used
  - fix loop when jump to fail_add_pm_domains loop
  - move checking of pm_domain_id from previous patch
  - fix mem_bank_data memory allocation

Changes in v6:
  - Introduce new node entry for r5f cluster split mode dts and
    keep it disabled by default.
  - Keep remoteproc lockstep mode enabled by default to maintian
    back compatibility.
  - Enable split mode only for zcu102 board to demo split mode use
  - Remove spurious change
  - Handle errors in add_pm_domains function
  - Remove redundant code to handle errors from remove_pm_domains
  - Missing . at the end of the commit message
  - remove redundant initialization of variables
  - remove fail_tcm label and relevant code to free memory
    acquired using devm_* API. As this will be freed when device free it
  - add extra check to see if "reg" property is supported or not

Changes in v5:
  - maintain Rob's Ack on bindings patch as no changes in bindings
  - split previous patch into multiple patches
  - Use pm domain framework to turn on/off TCM
  - Add support of parsing TCM information from device-tree
  - maintain backward compatibility with previous bindings without
    TCM information available in device-tree

This patch series continues previous effort to upstream ZynqMP
TCM bindings:
Previous v4 version link:
https://lore.kernel.org/all/20230829181900.2561194-1-tanmay.shah at amd.com/

Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pandey at amd.com/
Radhey Shyam Pandey (1):
  dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings


Radhey Shyam Pandey (1):
  dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings

Tanmay Shah (2):
  dts: zynqmp: add properties for TCM in remoteproc
  remoteproc: zynqmp: parse TCM from device tree

 .../remoteproc/xlnx,zynqmp-r5fss.yaml         | 131 +++++++++++++--
 .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |   8 +
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi        |  60 ++++++-
 drivers/remoteproc/xlnx_r5_remoteproc.c       | 154 +++++++++++++++++-
 4 files changed, 324 insertions(+), 29 deletions(-)


base-commit: 7641890179f913ce73d9dae490b8ab74970fc552
-- 
2.25.1



From tanmay.shah at amd.com  Fri Dec 15 15:57:23 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Fri, 15 Dec 2023 15:57:23 -0800
Subject: [PATCH v8 1/3] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
In-Reply-To: <20231215235725.1247350-1-tanmay.shah@amd.com>
References: <20231215235725.1247350-1-tanmay.shah@amd.com>
Message-ID: <20231215235725.1247350-2-tanmay.shah@amd.com>

From: Radhey Shyam Pandey <radhey.shyam.pandey at amd.com>

Introduce bindings for TCM memory address space on AMD-xilinx Zynq
UltraScale+ platform. It will help in defining TCM in device-tree
and make it's access platform agnostic and data-driven.

Tightly-coupled memories(TCMs) are low-latency memory that provides
predictable instruction execution and predictable data load/store
timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
banks on the ATCM and BTCM ports, for a total of 128 KB of memory.

The TCM resources(reg, reg-names and power-domain) are documented for
each TCM in the R5 node. The reg and reg-names are made as required
properties as we don't want to hardcode TCM addresses for future
platforms and for zu+ legacy implementation will ensure that the
old dts w/o reg/reg-names works and stable ABI is maintained.

It also extends the examples for TCM split and lockstep modes.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at amd.com>
Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../remoteproc/xlnx,zynqmp-r5fss.yaml         | 131 +++++++++++++++---
 1 file changed, 113 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 78aac69f1060..9ecd63ea1b38 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -20,6 +20,17 @@ properties:
   compatible:
     const: xlnx,zynqmp-r5fss
 
+  "#address-cells":
+    const: 2
+
+  "#size-cells":
+    const: 2
+
+  ranges:
+    description: |
+      Standard ranges definition providing address translations for
+      local R5F TCM address spaces to bus addresses.
+
   xlnx,cluster-mode:
     $ref: /schemas/types.yaml#/definitions/uint32
     enum: [0, 1, 2]
@@ -37,7 +48,7 @@ properties:
       2: single cpu mode
 
 patternProperties:
-  "^r5f-[a-f0-9]+$":
+  "^r5f@[0-9a-f]+$":
     type: object
     description: |
       The RPU is located in the Low Power Domain of the Processor Subsystem.
@@ -54,8 +65,19 @@ patternProperties:
       compatible:
         const: xlnx,zynqmp-r5f
 
+      reg:
+        items:
+          - description: ATCM internal memory region
+          - description: BTCM internal memory region
+
+      reg-names:
+        items:
+          - const: atcm
+          - const: btcm
+
       power-domains:
-        maxItems: 1
+        minItems: 1
+        maxItems: 3
 
       mboxes:
         minItems: 1
@@ -102,34 +124,107 @@ patternProperties:
     required:
       - compatible
       - power-domains
+      - reg
+      - reg-names
 
     unevaluatedProperties: false
 
 required:
   - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
 
 additionalProperties: false
 
 examples:
   - |
-    remoteproc {
-        compatible = "xlnx,zynqmp-r5fss";
-        xlnx,cluster-mode = <1>;
-
-        r5f-0 {
-            compatible = "xlnx,zynqmp-r5f";
-            power-domains = <&zynqmp_firmware 0x7>;
-            memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>, <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
-            mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
-            mbox-names = "tx", "rx";
+    #include <dt-bindings/power/xlnx-zynqmp-power.h>
+
+    //Split mode configuration
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        remoteproc at ffe00000 {
+            compatible = "xlnx,zynqmp-r5fss";
+            xlnx,cluster-mode = <0>;
+
+            #address-cells = <2>;
+            #size-cells = <2>;
+            ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
+                     <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
+                     <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
+                     <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
+
+            r5f at 0 {
+                compatible = "xlnx,zynqmp-r5f";
+                reg = <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0x0 0x10000>;
+                reg-names = "atcm", "btcm";
+                power-domains = <&zynqmp_firmware PD_RPU_0>,
+                                <&zynqmp_firmware PD_R5_0_ATCM>,
+                                <&zynqmp_firmware PD_R5_0_BTCM>;
+                memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>,
+                                <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
+                mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
+                mbox-names = "tx", "rx";
+            };
+
+            r5f at 1 {
+                compatible = "xlnx,zynqmp-r5f";
+                reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+                reg-names = "atcm", "btcm";
+                power-domains = <&zynqmp_firmware PD_RPU_1>,
+                                <&zynqmp_firmware PD_R5_1_ATCM>,
+                                <&zynqmp_firmware PD_R5_1_BTCM>;
+                memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>,
+                                <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
+                mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
+                mbox-names = "tx", "rx";
+            };
         };
+    };
 
-        r5f-1 {
-            compatible = "xlnx,zynqmp-r5f";
-            power-domains = <&zynqmp_firmware 0x8>;
-            memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>, <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
-            mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
-            mbox-names = "tx", "rx";
+  - |
+    //Lockstep configuration
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        remoteproc at ffe00000 {
+            compatible = "xlnx,zynqmp-r5fss";
+            xlnx,cluster-mode = <1>;
+
+            #address-cells = <2>;
+            #size-cells = <2>;
+            ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x20000>,
+                     <0x0 0x20000 0x0 0xffe20000 0x0 0x20000>;
+
+            r5f at 0 {
+                compatible = "xlnx,zynqmp-r5f";
+                reg = <0x0 0x0 0x0 0x20000>, <0x0 0x20000 0x0 0x20000>;
+                reg-names = "atcm", "btcm";
+                power-domains = <&zynqmp_firmware PD_RPU_0>,
+                                <&zynqmp_firmware PD_R5_0_ATCM>,
+                                <&zynqmp_firmware PD_R5_0_BTCM>;
+                memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>,
+                                <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
+                mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
+                mbox-names = "tx", "rx";
+            };
+
+            r5f at 1 {
+                compatible = "xlnx,zynqmp-r5f";
+                reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+                reg-names = "atcm", "btcm";
+                power-domains = <&zynqmp_firmware PD_RPU_1>,
+                                <&zynqmp_firmware PD_R5_1_ATCM>,
+                                <&zynqmp_firmware PD_R5_1_BTCM>;
+                memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>,
+                                <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
+                mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
+                mbox-names = "tx", "rx";
+            };
         };
     };
 ...
-- 
2.25.1



From tanmay.shah at amd.com  Fri Dec 15 15:57:25 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Fri, 15 Dec 2023 15:57:25 -0800
Subject: [PATCH v8 3/3] remoteproc: zynqmp: parse TCM from device tree
In-Reply-To: <20231215235725.1247350-1-tanmay.shah@amd.com>
References: <20231215235725.1247350-1-tanmay.shah@amd.com>
Message-ID: <20231215235725.1247350-4-tanmay.shah@amd.com>

ZynqMP TCM information is fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.

Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
---

Changes in v8:
  - parse power-domains property from device-tree and use EEMI calls
    to power on/off TCM instead of using pm domains framework
  - Remove checking of pm_domain_id validation to power on/off tcm
  - Remove spurious change

Changes in v7:
  - move checking of pm_domain_id from previous patch
  - fix mem_bank_data memory allocation

 drivers/remoteproc/xlnx_r5_remoteproc.c | 154 +++++++++++++++++++++++-
 1 file changed, 148 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395edea9a64..36d73dcd93f0 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -74,8 +74,8 @@ struct mbox_info {
 };
 
 /*
- * Hardcoded TCM bank values. This will be removed once TCM bindings are
- * accepted for system-dt specifications and upstreamed in linux kernel
+ * Hardcoded TCM bank values. This will stay in driver to maintain backward
+ * compatibility with device-tree that does not have TCM information.
  */
 static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
 	{0xffe00000UL, 0x0, 0x10000UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each */
@@ -878,6 +878,139 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
 	return ERR_PTR(ret);
 }
 
+static int zynqmp_r5_get_tcm_node_from_dt(struct zynqmp_r5_cluster *cluster)
+{
+	struct of_phandle_args out_args;
+	int tcm_reg_per_r5, tcm_pd_idx;
+	struct zynqmp_r5_core *r5_core;
+	int i, j, tcm_bank_count, ret;
+	struct platform_device *cpdev;
+	struct mem_bank_data *tcm;
+	struct device_node *np;
+	struct resource *res;
+	u64 abs_addr, size;
+	struct device *dev;
+
+	for (i = 0; i < cluster->core_count; i++) {
+		r5_core = cluster->r5_cores[i];
+		dev = r5_core->dev;
+		np = of_node_get(dev_of_node(dev));
+		tcm_pd_idx = 1;
+
+		/* we have address cell 2 and size cell as 2 */
+		tcm_reg_per_r5 = of_property_count_elems_of_size(np, "reg",
+								 4 * sizeof(u32));
+		if (tcm_reg_per_r5 <= 0) {
+			dev_err(dev, "can't get reg property err %d\n", tcm_reg_per_r5);
+			return -EINVAL;
+		}
+
+		/*
+		 * In lockstep mode, r5 core 0 will use r5 core 1 TCM
+		 * power domains as well. so allocate twice of per core TCM
+		 */
+		if (cluster->mode == LOCKSTEP_MODE)
+			tcm_bank_count = tcm_reg_per_r5 * 2;
+		else
+			tcm_bank_count = tcm_reg_per_r5;
+
+		r5_core->tcm_banks = devm_kcalloc(dev, tcm_bank_count,
+						  sizeof(struct mem_bank_data *),
+						  GFP_KERNEL);
+		if (!r5_core->tcm_banks)
+			ret = -ENOMEM;
+
+		r5_core->tcm_bank_count = tcm_bank_count;
+		for (j = 0; j < tcm_bank_count; j++) {
+			tcm = devm_kzalloc(dev, sizeof(struct mem_bank_data),
+					   GFP_KERNEL);
+			if (!tcm)
+				return -ENOMEM;
+
+			r5_core->tcm_banks[j] = tcm;
+
+			/*
+			 * In lockstep mode, get second core's TCM power domains id
+			 * after first core TCM parsing is done as
+			 */
+			if (j == tcm_reg_per_r5) {
+				/* dec first core node */
+				of_node_put(np);
+
+				/* get second core node */
+				np = of_get_next_child(cluster->dev->of_node, np);
+
+				/*
+				 * reset index of power-domains property list
+				 * for second core
+				 */
+				tcm_pd_idx = 1;
+			}
+
+			/* get power-domains id of tcm */
+			ret = of_parse_phandle_with_args(np, "power-domains",
+							 "#power-domain-cells",
+							 tcm_pd_idx,
+							 &out_args);
+			if (ret) {
+				dev_err(r5_core->dev,
+					"failed to get tcm %d pm domain, ret %d\n",
+					j, ret);
+				of_node_put(out_args.np);
+				return ret;
+			}
+			tcm->pm_domain_id = out_args.args[0];
+			of_node_put(out_args.np);
+			tcm_pd_idx++;
+
+			/*
+			 * In lockstep mode, we only need second core's power domain
+			 * ids. Other information from second core isn't needed so
+			 * ignore it. This forms table as zynqmp_tcm_banks_lockstep
+			 */
+			if (j >= tcm_reg_per_r5)
+				continue;
+
+			/* get tcm address without translation */
+			ret = of_property_read_reg(np, j, &abs_addr, &size);
+			if (ret) {
+				of_node_put(np);
+				dev_err(dev, "failed to get reg property\n");
+				return ret;
+			}
+
+			/*
+			 * remote processor can address only 32 bits
+			 * so convert 64-bits into 32-bits. This will discard
+			 * any unwanted upper 32-bits.
+			 */
+			tcm->da = (u32)abs_addr;
+			tcm->size = (u32)size;
+
+			cpdev = to_platform_device(dev);
+			res = platform_get_resource(cpdev, IORESOURCE_MEM, j);
+			if (!res) {
+				of_node_put(np);
+				dev_err(dev, "failed to get tcm resource\n");
+				return -EINVAL;
+			}
+
+			tcm->addr = (u32)res->start;
+			tcm->bank_name = (char *)res->name;
+			res = devm_request_mem_region(dev, tcm->addr, tcm->size,
+						      tcm->bank_name);
+			if (!res) {
+				dev_err(dev, "failed to request tcm resource\n");
+				of_node_put(np);
+				return -EINVAL;
+			}
+		}
+	}
+
+	of_node_put(np);
+	return 0;
+}
+
 /**
  * zynqmp_r5_get_tcm_node()
  * Ideally this function should parse tcm node and store information
@@ -956,10 +1089,19 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
 	struct zynqmp_r5_core *r5_core;
 	int ret, i;
 
-	ret = zynqmp_r5_get_tcm_node(cluster);
-	if (ret < 0) {
-		dev_err(dev, "can't get tcm node, err %d\n", ret);
-		return ret;
+	r5_core = cluster->r5_cores[0];
+	if (of_find_property(r5_core->np, "reg", NULL)) {
+		ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
+		if (ret) {
+			dev_err(dev, "can't get tcm node from dt, err %d\n", ret);
+			return ret;
+		}
+	} else {
+		ret = zynqmp_r5_get_tcm_node(cluster);
+		if (ret < 0) {
+			dev_err(dev, "can't get tcm node, err %d\n", ret);
+			return ret;
+		}
 	}
 
 	for (i = 0; i < cluster->core_count; i++) {
-- 
2.25.1



From konrad.dybcio at linaro.org  Fri Dec 15 16:03:07 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Sat, 16 Dec 2023 01:03:07 +0100
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
Message-ID: <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>

On 15.12.2023 13:54, Robin Murphy wrote:
> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>
>>
>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>> <quic_bibekkum at quicinc.com> wrote:
>>>>
>>>> Add ACTLR data table for SM8550 along with support for
>>>> same including SM8550 specific implementation operations.
>>>>
>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>> ---
>>>> ? drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 ++++++++++++++++++++++
>>>> ? 1 file changed, 89 insertions(+)
>>>>
>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>> index cb49291f5233..d2006f610243 100644
>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>> ???????? u32 actlr;
>>>> ? };
>>>>
>>>> +/*
>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the prefetch
>>>> + * buffer). The remaining bits are implementation defined and vary across
>>>> + * SoCs.
>>>> + */
>>>> +
>>>> +#define PREFETCH_DEFAULT?????? 0
>>>> +#define PREFETCH_SHALLOW?????? BIT(8)
>>>> +#define PREFETCH_MODERATE????? BIT(9)
>>>> +#define PREFETCH_DEEP????????? (BIT(9) | BIT(8))
>>>
>>> I thin the following might be more correct:
>>>
>>> #include <linux/bitfield.h>
>>>
>>> #define PREFETCH_MASK GENMASK(9, 8)
>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>
>>
>> Ack, thanks for this suggestion. Let me try this out using
>> GENMASK. Once tested, will take care of this in next version.
> 
> FWIW the more typical usage would be to just define the named macros for the raw field values, then put the FIELD_PREP() at the point of use. However in this case that's liable to get pretty verbose, so although I'm usually a fan of bitfield.h, the most readable option here might actually be to stick with simpler definitions of "(0 << 8)", "(1 << 8)", etc. However it's not really a big deal either way, and I defer to whatever Dmitry and Konrad prefer, since they're the ones looking after arm-smmu-qcom the most :)
My 5 cents would be to just use the "common" style of doing this, so:

#define ACTRL_PREFETCH	GENMASK(9, 8)
 #define PREFETCH_DEFAULT 0
 #define PREFETCH_SHALLOW 1
 #define PREFETCH_MODERATE 2
 #define PREFETCH_DEEP 3

and then use 

| FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)

it can get verbose, but.. arguably that's good, since you really want
to make sure the right bits are set here

Konrad


From kw at linux.com  Fri Dec 15 16:10:21 2023
From: kw at linux.com (Krzysztof =?utf-8?Q?Wilczy=C5=84ski?=)
Date: Sat, 16 Dec 2023 09:10:21 +0900
Subject: [PATCH] dt-bindings: PCI: dwc: rockchip: document optional pcie
 reference clock input
In-Reply-To: <20231206145041.667900-1-heiko@sntech.de>
References: <20231206145041.667900-1-heiko@sntech.de>
Message-ID: <20231216001021.GD1570493@rocinante>

Hello,

> On some boards the 100MHz PCIe reference clock to both controller and
> devices is controllable. Add that clock to the list of clocks.
> 
> The clock is optional, so the minItems stays the same.

Applied to dt-bindings, thank you!

[1/1] dt-bindings: PCI: dwc: rockchip: Document optional PCIe reference clock input
      https://git.kernel.org/pci/pci/c/639f666cf84e

	Krzysztof


From quic_eberman at quicinc.com  Fri Dec 15 16:20:43 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:43 -0800
Subject: [PATCH RFC v15 02/30] dt-bindings: Add binding for gunyah
 hypervisor
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-2-192a5d872a30@quicinc.com>

The Gunyah Resource Manager applies a devicetree overlay describing the
virtual platform configuration of the guest VM, such as the message
queue capability IDs for communicating with the Resource Manager. This
information is not otherwise discoverable by a VM: the Gunyah hypervisor
core does not provide a direct interface to discover capability IDs nor
a way to communicate with RM without having already known the
corresponding message queue capability ID. Add the DT bindings that
Gunyah adheres for the hypervisor node and message queues.

Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 .../bindings/firmware/gunyah-hypervisor.yaml       | 82 ++++++++++++++++++++++
 1 file changed, 82 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml b/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
new file mode 100644
index 000000000000..cdeb4885a807
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/gunyah-hypervisor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gunyah Hypervisor
+
+maintainers:
+  - Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
+  - Elliot Berman <quic_eberman at quicinc.com>
+
+description: |+
+  Gunyah virtual machines use this information to determine the capability IDs
+  of the message queues used to communicate with the Gunyah Resource Manager.
+  See also: https://github.com/quic/gunyah-resource-manager/blob/develop/src/vm_creation/dto_construct.c
+
+properties:
+  compatible:
+    const: gunyah-hypervisor
+
+  "#address-cells":
+    description: Number of cells needed to represent 64-bit capability IDs.
+    const: 2
+
+  "#size-cells":
+    description: must be 0, because capability IDs are not memory address
+                  ranges and do not have a size.
+    const: 0
+
+patternProperties:
+  "^gunyah-resource-mgr(@.*)?":
+    type: object
+    description:
+      Resource Manager node which is required to communicate to Resource
+      Manager VM using Gunyah Message Queues.
+
+    properties:
+      compatible:
+        const: gunyah-resource-manager
+
+      reg:
+        items:
+          - description: Gunyah capability ID of the TX message queue
+          - description: Gunyah capability ID of the RX message queue
+
+      interrupts:
+        items:
+          - description: Interrupt for the TX message queue
+          - description: Interrupt for the RX message queue
+
+    additionalProperties: false
+
+    required:
+      - compatible
+      - reg
+      - interrupts
+
+additionalProperties: false
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    hypervisor {
+        #address-cells = <2>;
+        #size-cells = <0>;
+        compatible = "gunyah-hypervisor";
+
+        gunyah-resource-mgr at 0 {
+            compatible = "gunyah-resource-manager";
+            interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>, /* TX allowed IRQ */
+                         <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>; /* RX requested IRQ */
+            reg = <0x00000000 0x00000000>, /* TX capability ID */
+                  <0x00000000 0x00000001>; /* RX capability ID */
+        };
+    };

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:45 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:45 -0800
Subject: [PATCH RFC v15 04/30] virt: gunyah: Add hypercalls to identify
 Gunyah
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-4-192a5d872a30@quicinc.com>

Add hypercalls to identify when Linux is running a virtual machine under
Gunyah.

There are two calls to help identify Gunyah:

1. gh_hypercall_get_uid() returns a UID when running under a Gunyah
   hypervisor.
2. gh_hypercall_hyp_identify() returns build information and a set of
   feature flags that are supported by Gunyah.

Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
Reviewed-by: Alex Elder <elder at linaro.org>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 arch/arm64/Kbuild                    |  1 +
 arch/arm64/gunyah/Makefile           |  3 ++
 arch/arm64/gunyah/gunyah_hypercall.c | 62 ++++++++++++++++++++++++++++++++++++
 drivers/virt/Kconfig                 |  2 ++
 drivers/virt/gunyah/Kconfig          | 12 +++++++
 include/linux/gunyah.h               | 38 ++++++++++++++++++++++
 6 files changed, 118 insertions(+)

diff --git a/arch/arm64/Kbuild b/arch/arm64/Kbuild
index 5bfbf7d79c99..e4847ba0e3c9 100644
--- a/arch/arm64/Kbuild
+++ b/arch/arm64/Kbuild
@@ -3,6 +3,7 @@ obj-y			+= kernel/ mm/ net/
 obj-$(CONFIG_KVM)	+= kvm/
 obj-$(CONFIG_XEN)	+= xen/
 obj-$(subst m,y,$(CONFIG_HYPERV))	+= hyperv/
+obj-$(CONFIG_GUNYAH)	+= gunyah/
 obj-$(CONFIG_CRYPTO)	+= crypto/
 
 # for cleaning
diff --git a/arch/arm64/gunyah/Makefile b/arch/arm64/gunyah/Makefile
new file mode 100644
index 000000000000..84f1e38cafb1
--- /dev/null
+++ b/arch/arm64/gunyah/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_GUNYAH) += gunyah_hypercall.o
diff --git a/arch/arm64/gunyah/gunyah_hypercall.c b/arch/arm64/gunyah/gunyah_hypercall.c
new file mode 100644
index 000000000000..739d7f9cef9f
--- /dev/null
+++ b/arch/arm64/gunyah/gunyah_hypercall.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/module.h>
+#include <linux/gunyah.h>
+#include <linux/uuid.h>
+
+/* {c1d58fcd-a453-5fdb-9265-ce36673d5f14} */
+static const uuid_t GUNYAH_UUID = UUID_INIT(0xc1d58fcd, 0xa453, 0x5fdb, 0x92,
+					    0x65, 0xce, 0x36, 0x67, 0x3d, 0x5f,
+					    0x14);
+
+bool arch_is_gunyah_guest(void)
+{
+	struct arm_smccc_res res;
+	uuid_t uuid;
+	u32 *up;
+
+	arm_smccc_1_1_hvc(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res);
+
+	up = (u32 *)&uuid.b[0];
+	up[0] = lower_32_bits(res.a0);
+	up[1] = lower_32_bits(res.a1);
+	up[2] = lower_32_bits(res.a2);
+	up[3] = lower_32_bits(res.a3);
+
+	return uuid_equal(&uuid, &GUNYAH_UUID);
+}
+EXPORT_SYMBOL_GPL(arch_is_gunyah_guest);
+
+#define GUNYAH_HYPERCALL(fn)                                      \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \
+			   ARM_SMCCC_OWNER_VENDOR_HYP, fn)
+
+/* clang-format off */
+#define GUNYAH_HYPERCALL_HYP_IDENTIFY		GUNYAH_HYPERCALL(0x8000)
+/* clang-format on */
+
+/**
+ * gunyah_hypercall_hyp_identify() - Returns build information and feature flags
+ *                               supported by Gunyah.
+ * @hyp_identity: filled by the hypercall with the API info and feature flags.
+ */
+void gunyah_hypercall_hyp_identify(
+	struct gunyah_hypercall_hyp_identify_resp *hyp_identity)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_hvc(GUNYAH_HYPERCALL_HYP_IDENTIFY, &res);
+
+	hyp_identity->api_info = res.a0;
+	hyp_identity->flags[0] = res.a1;
+	hyp_identity->flags[1] = res.a2;
+	hyp_identity->flags[2] = res.a3;
+}
+EXPORT_SYMBOL_GPL(gunyah_hypercall_hyp_identify);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Gunyah Hypervisor Hypercalls");
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
index 40129b6f0eca..172a6a12073c 100644
--- a/drivers/virt/Kconfig
+++ b/drivers/virt/Kconfig
@@ -50,4 +50,6 @@ source "drivers/virt/acrn/Kconfig"
 
 source "drivers/virt/coco/Kconfig"
 
+source "drivers/virt/gunyah/Kconfig"
+
 endif
diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig
new file mode 100644
index 000000000000..6f4c85db80b5
--- /dev/null
+++ b/drivers/virt/gunyah/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config GUNYAH
+	tristate "Gunyah Virtualization drivers"
+	depends on ARM64
+	help
+	  The Gunyah drivers are the helper interfaces that run in a guest VM
+	  such as basic inter-VM IPC and signaling mechanisms, and higher level
+	  services such as memory/device sharing, IRQ sharing, and so on.
+
+	  Say Y/M here to enable the drivers needed to interact in a Gunyah
+	  virtual environment.
diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h
index e1a716d802ee..8cdeaba34aa9 100644
--- a/include/linux/gunyah.h
+++ b/include/linux/gunyah.h
@@ -6,9 +6,11 @@
 #ifndef _LINUX_GUNYAH_H
 #define _LINUX_GUNYAH_H
 
+#include <linux/bitfield.h>
 #include <linux/errno.h>
 #include <linux/interrupt.h>
 #include <linux/limits.h>
+#include <linux/types.h>
 
 /* Matches resource manager's resource types for VM_GET_HYP_RESOURCES RPC */
 enum gunyah_resource_type {
@@ -103,4 +105,40 @@ static inline int gunyah_error_remap(enum gunyah_error gunyah_error)
 	}
 }
 
+enum gunyah_api_feature {
+	/* clang-format off */
+	GUNYAH_FEATURE_DOORBELL		= 1,
+	GUNYAH_FEATURE_MSGQUEUE		= 2,
+	GUNYAH_FEATURE_VCPU		= 5,
+	GUNYAH_FEATURE_MEMEXTENT	= 6,
+	/* clang-format on */
+};
+
+bool arch_is_gunyah_guest(void);
+
+#define GUNYAH_API_V1 1
+
+/* Other bits reserved for future use and will be zero */
+/* clang-format off */
+#define GUNYAH_API_INFO_API_VERSION_MASK	GENMASK_ULL(13, 0)
+#define GUNYAH_API_INFO_BIG_ENDIAN		BIT_ULL(14)
+#define GUNYAH_API_INFO_IS_64BIT		BIT_ULL(15)
+#define GUNYAH_API_INFO_VARIANT_MASK 		GENMASK_ULL(63, 56)
+/* clang-format on */
+
+struct gunyah_hypercall_hyp_identify_resp {
+	u64 api_info;
+	u64 flags[3];
+};
+
+static inline u16
+gunyah_api_version(const struct gunyah_hypercall_hyp_identify_resp *gunyah_api)
+{
+	return FIELD_GET(GUNYAH_API_INFO_API_VERSION_MASK,
+			 gunyah_api->api_info);
+}
+
+void gunyah_hypercall_hyp_identify(
+	struct gunyah_hypercall_hyp_identify_resp *hyp_identity);
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:47 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:47 -0800
Subject: [PATCH RFC v15 06/30] virt: gunyah: msgq: Add hypercalls to send
 and receive messages
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-6-192a5d872a30@quicinc.com>

Add hypercalls to send and receive messages on a Gunyah message queue.

Reviewed-by: Alex Elder <elder at linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 arch/arm64/gunyah/gunyah_hypercall.c | 34 ++++++++++++++++++++++++++++++++++
 include/linux/gunyah.h               |  7 +++++++
 2 files changed, 41 insertions(+)

diff --git a/arch/arm64/gunyah/gunyah_hypercall.c b/arch/arm64/gunyah/gunyah_hypercall.c
index 739d7f9cef9f..cadc512934c4 100644
--- a/arch/arm64/gunyah/gunyah_hypercall.c
+++ b/arch/arm64/gunyah/gunyah_hypercall.c
@@ -37,6 +37,8 @@ EXPORT_SYMBOL_GPL(arch_is_gunyah_guest);
 
 /* clang-format off */
 #define GUNYAH_HYPERCALL_HYP_IDENTIFY		GUNYAH_HYPERCALL(0x8000)
+#define GUNYAH_HYPERCALL_MSGQ_SEND		GUNYAH_HYPERCALL(0x801B)
+#define GUNYAH_HYPERCALL_MSGQ_RECV		GUNYAH_HYPERCALL(0x801C)
 /* clang-format on */
 
 /**
@@ -58,5 +60,37 @@ void gunyah_hypercall_hyp_identify(
 }
 EXPORT_SYMBOL_GPL(gunyah_hypercall_hyp_identify);
 
+enum gunyah_error gunyah_hypercall_msgq_send(u64 capid, size_t size, void *buff,
+					     u64 tx_flags, bool *ready)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_hvc(GUNYAH_HYPERCALL_MSGQ_SEND, capid, size,
+			  (uintptr_t)buff, tx_flags, 0, &res);
+
+	if (res.a0 == GUNYAH_ERROR_OK)
+		*ready = !!res.a1;
+
+	return res.a0;
+}
+EXPORT_SYMBOL_GPL(gunyah_hypercall_msgq_send);
+
+enum gunyah_error gunyah_hypercall_msgq_recv(u64 capid, void *buff, size_t size,
+					     size_t *recv_size, bool *ready)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_hvc(GUNYAH_HYPERCALL_MSGQ_RECV, capid, (uintptr_t)buff,
+			  size, 0, &res);
+
+	if (res.a0 == GUNYAH_ERROR_OK) {
+		*recv_size = res.a1;
+		*ready = !!res.a2;
+	}
+
+	return res.a0;
+}
+EXPORT_SYMBOL_GPL(gunyah_hypercall_msgq_recv);
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Gunyah Hypervisor Hypercalls");
diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h
index 8cdeaba34aa9..ea2c9eecce0e 100644
--- a/include/linux/gunyah.h
+++ b/include/linux/gunyah.h
@@ -141,4 +141,11 @@ gunyah_api_version(const struct gunyah_hypercall_hyp_identify_resp *gunyah_api)
 void gunyah_hypercall_hyp_identify(
 	struct gunyah_hypercall_hyp_identify_resp *hyp_identity);
 
+#define GUNYAH_HYPERCALL_MSGQ_TX_FLAGS_PUSH BIT(0)
+
+enum gunyah_error gunyah_hypercall_msgq_send(u64 capid, size_t size, void *buff,
+					     u64 tx_flags, bool *ready);
+enum gunyah_error gunyah_hypercall_msgq_recv(u64 capid, void *buff, size_t size,
+					     size_t *recv_size, bool *ready);
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:46 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:46 -0800
Subject: [PATCH RFC v15 05/30] virt: gunyah: Add hypervisor driver
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-5-192a5d872a30@quicinc.com>

Add driver to detect when running under Gunyah. It performs basic
identification hypercall and populates the platform bus for resource
manager to probe.

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/Makefile        |  1 +
 drivers/virt/gunyah/Makefile |  3 +++
 drivers/virt/gunyah/gunyah.c | 52 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 56 insertions(+)

diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
index f29901bd7820..ef6a3835d078 100644
--- a/drivers/virt/Makefile
+++ b/drivers/virt/Makefile
@@ -10,3 +10,4 @@ obj-y				+= vboxguest/
 obj-$(CONFIG_NITRO_ENCLAVES)	+= nitro_enclaves/
 obj-$(CONFIG_ACRN_HSM)		+= acrn/
 obj-y				+= coco/
+obj-y				+= gunyah/
diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
new file mode 100644
index 000000000000..34f32110faf9
--- /dev/null
+++ b/drivers/virt/gunyah/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_GUNYAH) += gunyah.o
diff --git a/drivers/virt/gunyah/gunyah.c b/drivers/virt/gunyah/gunyah.c
new file mode 100644
index 000000000000..20bd6029ffc4
--- /dev/null
+++ b/drivers/virt/gunyah/gunyah.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/gunyah.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+static int gunyah_probe(struct platform_device *pdev)
+{
+	struct gunyah_hypercall_hyp_identify_resp gunyah_api;
+
+	if (!arch_is_gunyah_guest())
+		return -ENODEV;
+
+	gunyah_hypercall_hyp_identify(&gunyah_api);
+
+	pr_info("Running under Gunyah hypervisor %llx/v%u\n",
+		FIELD_GET(GUNYAH_API_INFO_VARIANT_MASK, gunyah_api.api_info),
+		gunyah_api_version(&gunyah_api));
+
+	/* Might move this out to individual drivers if there's ever an API version bump */
+	if (gunyah_api_version(&gunyah_api) != GUNYAH_API_V1) {
+		pr_info("Unsupported Gunyah version: %u\n",
+			gunyah_api_version(&gunyah_api));
+		return -ENODEV;
+	}
+
+	return devm_of_platform_populate(&pdev->dev);
+}
+
+static const struct of_device_id gunyah_of_match[] = {
+	{ .compatible = "gunyah-hypervisor" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, gunyah_of_match);
+
+/* clang-format off */
+static struct platform_driver gunyah_driver = {
+	.probe = gunyah_probe,
+	.driver = {
+		.name = "gunyah",
+		.of_match_table = gunyah_of_match,
+	}
+};
+/* clang-format on */
+module_platform_driver(gunyah_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Gunyah Driver");

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:44 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:44 -0800
Subject: [PATCH RFC v15 03/30] gunyah: Common types and error codes for
 Gunyah hypercalls
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-3-192a5d872a30@quicinc.com>

Add architecture-independent standard error codes, types, and macros for
Gunyah hypercalls.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
Reviewed-by: Alex Elder <elder at linaro.org>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 include/linux/gunyah.h | 106 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 106 insertions(+)

diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h
new file mode 100644
index 000000000000..e1a716d802ee
--- /dev/null
+++ b/include/linux/gunyah.h
@@ -0,0 +1,106 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _LINUX_GUNYAH_H
+#define _LINUX_GUNYAH_H
+
+#include <linux/errno.h>
+#include <linux/interrupt.h>
+#include <linux/limits.h>
+
+/* Matches resource manager's resource types for VM_GET_HYP_RESOURCES RPC */
+enum gunyah_resource_type {
+	/* clang-format off */
+	GUNYAH_RESOURCE_TYPE_BELL_TX	= 0,
+	GUNYAH_RESOURCE_TYPE_BELL_RX	= 1,
+	GUNYAH_RESOURCE_TYPE_MSGQ_TX	= 2,
+	GUNYAH_RESOURCE_TYPE_MSGQ_RX	= 3,
+	GUNYAH_RESOURCE_TYPE_VCPU	= 4,
+	GUNYAH_RESOURCE_TYPE_MEM_EXTENT	= 9,
+	GUNYAH_RESOURCE_TYPE_ADDR_SPACE	= 10,
+	/* clang-format on */
+};
+
+struct gunyah_resource {
+	enum gunyah_resource_type type;
+	u64 capid;
+	unsigned int irq;
+};
+
+/******************************************************************************/
+/* Common arch-independent definitions for Gunyah hypercalls                  */
+#define GUNYAH_CAPID_INVAL U64_MAX
+#define GUNYAH_VMID_ROOT_VM 0xff
+
+enum gunyah_error {
+	/* clang-format off */
+	GUNYAH_ERROR_OK				= 0,
+	GUNYAH_ERROR_UNIMPLEMENTED		= -1,
+	GUNYAH_ERROR_RETRY			= -2,
+
+	GUNYAH_ERROR_ARG_INVAL			= 1,
+	GUNYAH_ERROR_ARG_SIZE			= 2,
+	GUNYAH_ERROR_ARG_ALIGN			= 3,
+
+	GUNYAH_ERROR_NOMEM			= 10,
+
+	GUNYAH_ERROR_ADDR_OVFL			= 20,
+	GUNYAH_ERROR_ADDR_UNFL			= 21,
+	GUNYAH_ERROR_ADDR_INVAL			= 22,
+
+	GUNYAH_ERROR_DENIED			= 30,
+	GUNYAH_ERROR_BUSY			= 31,
+	GUNYAH_ERROR_IDLE			= 32,
+
+	GUNYAH_ERROR_IRQ_BOUND			= 40,
+	GUNYAH_ERROR_IRQ_UNBOUND		= 41,
+
+	GUNYAH_ERROR_CSPACE_CAP_NULL		= 50,
+	GUNYAH_ERROR_CSPACE_CAP_REVOKED		= 51,
+	GUNYAH_ERROR_CSPACE_WRONG_OBJ_TYPE	= 52,
+	GUNYAH_ERROR_CSPACE_INSUF_RIGHTS	= 53,
+	GUNYAH_ERROR_CSPACE_FULL		= 54,
+
+	GUNYAH_ERROR_MSGQUEUE_EMPTY		= 60,
+	GUNYAH_ERROR_MSGQUEUE_FULL		= 61,
+	/* clang-format on */
+};
+
+/**
+ * gunyah_error_remap() - Remap Gunyah hypervisor errors into a Linux error code
+ * @gunyah_error: Gunyah hypercall return value
+ */
+static inline int gunyah_error_remap(enum gunyah_error gunyah_error)
+{
+	switch (gunyah_error) {
+	case GUNYAH_ERROR_OK:
+		return 0;
+	case GUNYAH_ERROR_NOMEM:
+		return -ENOMEM;
+	case GUNYAH_ERROR_DENIED:
+	case GUNYAH_ERROR_CSPACE_CAP_NULL:
+	case GUNYAH_ERROR_CSPACE_CAP_REVOKED:
+	case GUNYAH_ERROR_CSPACE_WRONG_OBJ_TYPE:
+	case GUNYAH_ERROR_CSPACE_INSUF_RIGHTS:
+		return -EACCES;
+	case GUNYAH_ERROR_CSPACE_FULL:
+	case GUNYAH_ERROR_BUSY:
+	case GUNYAH_ERROR_IDLE:
+		return -EBUSY;
+	case GUNYAH_ERROR_IRQ_BOUND:
+	case GUNYAH_ERROR_IRQ_UNBOUND:
+	case GUNYAH_ERROR_MSGQUEUE_FULL:
+	case GUNYAH_ERROR_MSGQUEUE_EMPTY:
+		return -EIO;
+	case GUNYAH_ERROR_UNIMPLEMENTED:
+		return -EOPNOTSUPP;
+	case GUNYAH_ERROR_RETRY:
+		return -EAGAIN;
+	default:
+		return -EINVAL;
+	}
+}
+
+#endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:42 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:42 -0800
Subject: [PATCH RFC v15 01/30] docs: gunyah: Introduce Gunyah Hypervisor
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-1-192a5d872a30@quicinc.com>

Gunyah is an open-source Type-1 hypervisor developed by Qualcomm. It
does not depend on any lower-privileged OS/kernel code for its core
functionality. This increases its security and can support a smaller
trusted computing based when compared to Type-2 hypervisors.

Add documentation describing the Gunyah hypervisor and the main
components of the Gunyah hypervisor which are of interest to Linux
virtualization development.

Reviewed-by: Bagas Sanjaya <bagasdotme at gmail.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 Documentation/virt/gunyah/index.rst         | 121 ++++++++++++++++++++++++++++
 Documentation/virt/gunyah/message-queue.rst |  69 ++++++++++++++++
 Documentation/virt/index.rst                |   1 +
 3 files changed, 191 insertions(+)

diff --git a/Documentation/virt/gunyah/index.rst b/Documentation/virt/gunyah/index.rst
new file mode 100644
index 000000000000..fe3f4192b836
--- /dev/null
+++ b/Documentation/virt/gunyah/index.rst
@@ -0,0 +1,121 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+Gunyah Hypervisor
+=================
+
+.. toctree::
+   :maxdepth: 1
+
+   message-queue
+
+Gunyah is a Type-1 hypervisor which is independent of any OS kernel, and runs in
+a higher CPU privilege level. It does not depend on any lower-privileged
+operating system for its core functionality. This increases its security and can
+support a much smaller trusted computing base than a Type-2 hypervisor.
+
+Gunyah is an open source hypervisor. The source repo is available at
+https://github.com/quic/gunyah-hypervisor.
+
+Gunyah provides these following features.
+
+- Scheduling:
+
+  A scheduler for virtual CPUs (vCPUs) on physical CPUs enables time-sharing
+  of the CPUs. Gunyah supports two models of scheduling:
+
+    1. "Behind the back" scheduling in which Gunyah hypervisor schedules vCPUS
+       on its own.
+    2. "Proxy" scheduling in which a delegated VM can donate part of one of its
+       vCPU slice to another VM's vCPU via a hypercall.
+
+- Memory Management:
+
+  APIs handling memory, abstracted as objects, limiting direct use of physical
+  addresses. Memory ownership and usage tracking of all memory under its control.
+  Memory partitioning between VMs is a fundamental security feature.
+
+- Interrupt Virtualization:
+
+  Uses CPU hardware interrupt virtualization capabilities. Interrupts are
+   handled in the hypervisor and routed to the assigned VM.
+
+- Inter-VM Communication:
+
+  There are several different mechanisms provided for communicating between VMs.
+
+- Virtual platform:
+
+  Architectural devices such as interrupt controllers and CPU timers are
+  directly provided by the hypervisor as well as core virtual platform devices
+  and system APIs such as ARM PSCI.
+
+- Device Virtualization:
+
+  Para-virtualization of devices is supported using inter-VM communication.
+
+Architectures supported
+=======================
+AArch64 with a GIC
+
+Resources and Capabilities
+==========================
+
+Services/resources provide by the Gunyah hypervisor are described to a
+virtual machine by capability IDs. For instance, inter-VM communication is
+performed with doorbells and message queues. Gunyah allows access to interact
+with that doorbell via the capability ID. These resources are described in Linux
+as a struct gunyah_resource.
+
+High level management of these resources is performed by the resource manager
+VM. RM informs a guest VM about resources it can access through either the
+device tree or via guest-initiated RPC.
+
+Gunyah tracks all resources and selectively makes them available to some VMs via
+VM-specific capability IDs.
+
+Resource Manager
+================
+
+The resource manager (RM) is a privileged application VM supporting the Gunyah
+Hypervisor. It provides policy enforcement aspects of the virtualization system.
+The resource manager can be treated as an extension of the Hypervisor but is
+separated to its own partition to ensure that the hypervisor layer itself
+remains small and secure and to maintain a separation of policy and mechanism in
+the platform. The resource manager runs at arm64 NS-EL1, similar to other
+virtual machines.
+
+Communication with the resource manager from other virtual machines happens with
+message-queue.rst. Details about the specific messages can be found in
+drivers/virt/gunyah/rsc_mgr.c
+
+::
+
+  +-------+   +--------+   +--------+
+  |  RM   |   |  VM_A  |   |  VM_B  |
+  +-.-.-.-+   +---.----+   +---.----+
+    | |           |            |
+  +-.-.-----------.------------.----+
+  | | \==========/             |    |
+  |  \========================/     |
+  |            Gunyah               |
+  +---------------------------------+
+
+The source for the resource manager is available at
+https://github.com/quic/gunyah-resource-manager.
+
+The resource manager provides the following features:
+
+- VM lifecycle management: allocating a VM, starting VMs, destruction of VMs
+- VM access control policy, including memory sharing and lending
+- Interrupt routing configuration
+- Forwarding of system-level events (e.g. VM shutdown) to owner VM
+- Resource (capability) discovery
+
+Resource manager presently requires the guest virtual machines uses a device
+tree to describe its configuration. The resource manager applies an overlay to
+the/hypervisor node. This node lets guests know they are running as a Gunyah
+guest VM, how to communicate with resource manager, and basic description and
+capabilities of this VM. See
+Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml for a
+description of this node.
diff --git a/Documentation/virt/gunyah/message-queue.rst b/Documentation/virt/gunyah/message-queue.rst
new file mode 100644
index 000000000000..bd9947240c2a
--- /dev/null
+++ b/Documentation/virt/gunyah/message-queue.rst
@@ -0,0 +1,69 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Message Queues
+==============
+Message queue is a simple low-capacity IPC channel between two virtual machines.
+It is intended for sending small control and configuration messages. Each
+message queue is unidirectional, so a full-duplex IPC channel requires a pair of
+queues.
+
+Messages can be up to 240 bytes in length. Longer messages require a further
+protocol on top of the message queue messages themselves. For instance,
+communication with the resource manager adds a header field for sending longer
+messages via multiple message fragments.
+
+The diagram below shows how message queue works. A typical configuration
+involves 2 message queues. Message queue 1 allows VM_A to send messages to VM_B.
+Message queue 2 allows VM_B to send messages to VM_A.
+
+1. VM_A sends a message of up to 240 bytes in length. It raises a hypercall
+   with the message to inform the hypervisor to add the message to
+   message queue 1's queue. The hypervisor copies memory into the internal
+   message queue representation; the memory doesn't need to be shared between
+   VM_A and VM_B.
+
+2. Gunyah raises the corresponding interrupt for VM_B (Rx vIRQ) when any of
+   these happens:
+
+   a. gunyah_msgq_send() has PUSH flag. This is a typical case.
+   b. Explicility with gunyah_msgq_push command from VM_A.
+   c. Message queue has reached a threshold depth. Typically, this threshold
+      depth is the size of the queue (in other words: when queue is full, Rx
+      vIRQ raised).
+
+3. VM_B calls gunyah_msgq_recv() and Gunyah copies message to requested buffer.
+
+4. Gunyah raises the corresponding interrupt for VM_A (Tx vIRQ) when the message
+   queue falls below a watermark depth. Typically, this is the size of the queue
+   (in other words: when the queue is no longer full, Tx vIRQ raised). Note the
+   watermark depth and the threshold depth for the Rx vIRQ are independent
+   values, although they are both typically the size of the queue.
+   Coincidentally, this signal is conceptually similar to Clear-to-Send.
+
+For VM_B to send a message to VM_A, the process is identical, except that
+hypercalls reference message queue 2's capability ID. Each message queue has its
+own independent vIRQ: two TX message queues will have two vIRQs (and two
+capability IDs).
+
+::
+
+      +---------------+         +-----------------+         +---------------+
+      |      VM_A     |         |Gunyah hypervisor|         |      VM_B     |
+      |               |         |                 |         |               |
+      |               |         |                 |         |               |
+      |               |   Tx    |                 |         |               |
+      |               |-------->|                 | Rx vIRQ |               |
+      |gunyah_msgq_send() | Tx vIRQ |Message queue 1  |-------->|gunyah_msgq_recv() |
+      |               |<------- |                 |         |               |
+      |               |         |                 |         |               |
+      | Message Queue |         |                 |         | Message Queue |
+      | driver        |         |                 |         | driver        |
+      |               |         |                 |         |               |
+      |               |         |                 |         |               |
+      |               |         |                 |   Tx    |               |
+      |               | Rx vIRQ |                 |<--------|               |
+      |gunyah_msgq_recv() |<--------|Message queue 2  | Tx vIRQ |gunyah_msgq_send() |
+      |               |         |                 |-------->|               |
+      |               |         |                 |         |               |
+      |               |         |                 |         |               |
+      +---------------+         +-----------------+         +---------------+
diff --git a/Documentation/virt/index.rst b/Documentation/virt/index.rst
index 7fb55ae08598..15869ee059b3 100644
--- a/Documentation/virt/index.rst
+++ b/Documentation/virt/index.rst
@@ -16,6 +16,7 @@ Virtualization Support
    coco/sev-guest
    coco/tdx-guest
    hyperv/index
+   gunyah/index
 
 .. only:: html and subproject
 

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:41 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:41 -0800
Subject: [PATCH RFC v15 00/30] Drivers for Gunyah hypervisor
Message-ID: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>

Hello all,

There is significant architecture change in the latest version to
support demand paging. Demand paging allows Linux to provide memory to
the guest when it wants -- only when guest tries to access the memory.
I wanted to post a version to collect some early feedback.

In particular, our implementation of guestmemfd is similar to KVM's
guest memfd: I'm curious to get community's thoughts on how (if at all)
to refactor both to share the common, generic bits. In particular, the
primary difference I see between KVM and Gunyah's implementation is how
we determine whether a page can be mapped to userspace, so I think there
is strong case here to share at least some of the implementation.

Also, I wanted to get any feedback if how folios are tracked for a
virtual machine seems correct: folios are initially allocated using
the filemap associated with the guest memfd. When guest tries to access
them, I use a maple tree to track folios that have been shares: the
indices are guest frame number and values are folio pointers. The
folio's ->private field is used to note whether the folio is available
to be mapped by Linux.

Some areas that still need testing/work is multi-threading and memory
reclaim while VM is running; the important bits are present in the
implementation and design, but not fully tested. The series is
capable of booting a Linux virtual machine, so while some areas aren't
finished, it is fairly complete.
-

Gunyah is a Type-1 hypervisor independent of any high-level OS kernel,
and runs in a higher CPU privilege level. It does not depend on any
lower-privileged OS kernel/code for its core functionality. This
increases its security and can support a much smaller trusted computing
base than a Type-2 hypervisor. Gunyah is designed for isolated virtual
machine use cases and to support launching trusted+isolated virtual
machines from a relatively less trusted host virtual machine.

Gunyah is an open source hypervisor. The source repo is available at
https://github.com/quic/gunyah-hypervisor.

The diagram below shows the architecture.

::

         VM A                    VM B
     +-----+ +-----+  | +-----+ +-----+ +-----+
     |     | |     |  | |     | |     | |     |
 EL0 | APP | | APP |  | | APP | | APP | | APP |
     |     | |     |  | |     | |     | |     |
     +-----+ +-----+  | +-----+ +-----+ +-----+
 ---------------------|-------------------------
     +--------------+ | +----------------------+
     |              | | |                      |
 EL1 | Linux Kernel | | |Linux kernel/Other OS |   ...
     |              | | |                      |
     +--------------+ | +----------------------+
 --------hvc/smc------|------hvc/smc------------
     +----------------------------------------+
     |                                        |
 EL2 |            Gunyah Hypervisor           |
     |                                        |
     +----------------------------------------+

Gunyah provides these following features.

- Threads and Scheduling: The scheduler schedules virtual CPUs (VCPUs)
  on physical CPUs and enables time-sharing of the CPUs.
- Memory Management: Gunyah tracks memory ownership and use of all
  memory under its control. Memory partitioning between VMs is a
  fundamental security feature.
- Interrupt Virtualization: All interrupts are handled in the hypervisor
   and routed to the assigned VM.
- Inter-VM Communication: There are several different mechanisms
  provided for communicating between VMs.
- Device Virtualization: Para-virtualization of devices is supported
  using inter-VM communication. Low level system features and devices such
  as interrupt controllers are supported with emulation where required.

This series adds the basic framework for detecting that Linux is running
under Gunyah as a virtual machine, communication with the Gunyah
Resource Manager, and a sample virtual machine manager capable of
launching virtual machines.

Changes in v15:
 - First implementation of virtual machines backed by guestmemfd and
using demand paging to provide memory instead of all up front.
 - Use message queue hypercalls directly instead of traversing through
mailbox framework.

Changes in v14: https://lore.kernel.org/all/20230613172054.3959700-1-quic_eberman at quicinc.com/
 - Coding/cosmetic tweaks suggested by Alex
 - Mark IRQs as wake-up capable

Changes in v13:
https://lore.kernel.org/all/20230509204801.2824351-1-quic_eberman at quicinc.com/
 - Tweaks to message queue driver to address race condition between IRQ
and mailbox registration
 - Allow removal of VM functions by function-specific comparison --
specifically to allow
   removing irqfd by label only and not requiring original FD to be
provided.

Changes in v12:
https://lore.kernel.org/all/20230424231558.70911-1-quic_eberman at quicinc.com/
 - Stylistic/cosmetic tweaks suggested by Alex
 - Remove patch "virt: gunyah: Identify hypervisor version" and squash
the
   check that we're running under a reasonable Gunyah hypervisor into RM
driver
 - Refactor platform hooks into a separate module per suggestion from
Srini
 - GFP_KERNEL_ACCOUNT and account_locked_vm() for page pinning
 - enum-ify related constants

Changes in v11:
https://lore.kernel.org/all/20230304010632.2127470-1-quic_eberman at quicinc.com/
 - Rename struct gh_vm_dtb_config:gpa -> guest_phys_addr & overflow
checks for this
 - More docstrings throughout
 - Make resp_buf and resp_buf_size optional
 - Replace deprecated idr with xarray
 - Refconting on misc device instead of RM's platform device
 - Renaming variables, structs, etc. from gunyah_ -> gh_
 - Drop removal of user mem regions
 - Drop mem_lend functionality; to converge with restricted_memfd later

Changes in v10:
https://lore.kernel.org/all/20230214211229.3239350-1-quic_eberman at quicinc.com/
 - Fix bisectability (end result of series is same, --fixups applied to
wrong commits)
 - Convert GH_ERROR_* and GH_RM_ERROR_* to enums
 - Correct race condition between allocating/freeing user memory
 - Replace offsetof with struct_size
 - Series-wide renaming of functions to be more consistent
 - VM shutdown & restart support added in vCPU and VM Manager patches
 - Convert VM function name (string) to type (number)
 - Convert VM function argument to value (which could be a pointer) to
remove memory wastage for arguments
 - Remove defensive checks of hypervisor correctness
 - Clean ups to ioeventfd as suggested by Srivatsa

Changes in v9:
https://lore.kernel.org/all/20230120224627.4053418-1-quic_eberman at quicinc.com/
 - Refactor Gunyah API flags to be exposed as feature flags at kernel
level
 - Move mbox client cleanup into gunyah_msgq_remove()
 - Simplify gh_rm_call return value and response payload
 - Missing clean-up/error handling/little endian fixes as suggested by
Srivatsa and Alex in v8 series

Changes in v8:
https://lore.kernel.org/all/20221219225850.2397345-1-quic_eberman at quicinc.com/
 - Treat VM manager as a library of RM
 - Add patches 21-28 as RFC to support proxy-scheduled vCPUs and
necessary bits to support virtio
   from Gunyah userspace

Changes in v7:
https://lore.kernel.org/all/20221121140009.2353512-1-quic_eberman at quicinc.com/
 - Refactor to remove gunyah RM bus
 - Refactor allow multiple RM device instances
 - Bump UAPI to start at 0x0
 - Refactor QCOM SCM's platform hooks to allow
CONFIG_QCOM_SCM=Y/CONFIG_GUNYAH=M combinations

Changes in v6:
https://lore.kernel.org/all/20221026185846.3983888-1-quic_eberman at quicinc.com/
 - *Replace gunyah-console with gunyah VM Manager*
 - Move include/asm-generic/gunyah.h into include/linux/gunyah.h
 - s/gunyah_msgq/gh_msgq/
 - Minor tweaks and documentation tidying based on comments from Jiri,
Greg, Arnd, Dmitry, and Bagas.

Changes in v5
https://lore.kernel.org/all/20221011000840.289033-1-quic_eberman at quicinc.com/
 - Dropped sysfs nodes
 - Switch from aux bus to Gunyah RM bus for the subdevices
 - Cleaning up RM console

Changes in v4:
https://lore.kernel.org/all/20220928195633.2348848-1-quic_eberman at quicinc.com/
 - Tidied up documentation throughout based on questions/feedback received
 - Switched message queue implementation to use mailboxes
 - Renamed "gunyah_device" as "gunyah_resource"

Changes in v3:
https://lore.kernel.org/all/20220811214107.1074343-1-quic_eberman at quicinc.com/
 - /Maintained/Supported/ in MAINTAINERS
 - Tidied up documentation throughout based on questions/feedback received
 - Moved hypercalls into arch/arm64/gunyah/; following hyper-v's implementation
 - Drop opaque typedefs
 - Move sysfs nodes under /sys/hypervisor/gunyah/
 - Moved Gunyah console driver to drivers/tty/
 - Reworked gh_device design to drop the Gunyah bus.

Changes in v2: https://lore.kernel.org/all/20220801211240.597859-1-quic_eberman at quicinc.com/
 - DT bindings clean up
 - Switch hypercalls to follow SMCCC 

v1: https://lore.kernel.org/all/20220223233729.1571114-1-quic_eberman at quicinc.com/

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
Elliot Berman (30):
      docs: gunyah: Introduce Gunyah Hypervisor
      dt-bindings: Add binding for gunyah hypervisor
      gunyah: Common types and error codes for Gunyah hypercalls
      virt: gunyah: Add hypercalls to identify Gunyah
      virt: gunyah: Add hypervisor driver
      virt: gunyah: msgq: Add hypercalls to send and receive messages
      gunyah: rsc_mgr: Add resource manager RPC core
      gunyah: rsc_mgr: Add VM lifecycle RPC
      gunyah: vm_mgr: Introduce basic VM Manager
      gunyah: vm_mgr: Add ioctls to support basic non-proxy VM boot
      gunyah: vm_mgr: Add framework for VM Functions
      virt: gunyah: Translate gh_rm_hyp_resource into gunyah_resource
      virt: gunyah: Add resource tickets
      virt: gunyah: Add IO handlers
      gunyah: Add hypercalls for demand paging
      virt: gunyah: Add interfaces to map memory into guest address space
      gunyah: rsc_mgr: Add platform ops on mem_lend/mem_reclaim
      virt: gunyah: Add IO handlers
      virt: gunyah: Add proxy-scheduled vCPUs
      virt: gunyah: Implement guestmemfd
      virt: gunyah: Add ioctl to bind guestmem to VMs
      virt: gunyah: guestmem: Initialize RM mem parcels from guestmem
      virt: gunyah: Allow userspace to initialize context of primary vCPU
      virt: gunyah: Share guest VM dtb configuration to Gunyah
      virt: gunyah: Enable demand paging
      virt: gunyah: Add Qualcomm Gunyah platform ops
      virt: gunyah: Add hypercalls for sending doorbell
      virt: gunyah: Add irqfd interface
      virt: gunyah: Add ioeventfd
      MAINTAINERS: Add Gunyah hypervisor drivers section

 .../bindings/firmware/gunyah-hypervisor.yaml       |  82 ++
 Documentation/userspace-api/ioctl/ioctl-number.rst |   1 +
 Documentation/virt/gunyah/index.rst                | 121 +++
 Documentation/virt/gunyah/message-queue.rst        |  69 ++
 Documentation/virt/index.rst                       |   1 +
 MAINTAINERS                                        |  13 +
 arch/arm64/Kbuild                                  |   1 +
 arch/arm64/gunyah/Makefile                         |   3 +
 arch/arm64/gunyah/gunyah_hypercall.c               | 209 +++++
 arch/arm64/include/asm/gunyah.h                    |  57 ++
 drivers/virt/Kconfig                               |   2 +
 drivers/virt/Makefile                              |   1 +
 drivers/virt/gunyah/Kconfig                        |  47 +
 drivers/virt/gunyah/Makefile                       |   9 +
 drivers/virt/gunyah/guest_memfd.c                  | 826 ++++++++++++++++++
 drivers/virt/gunyah/gunyah.c                       |  52 ++
 drivers/virt/gunyah/gunyah_ioeventfd.c             | 132 +++
 drivers/virt/gunyah/gunyah_irqfd.c                 | 191 ++++
 drivers/virt/gunyah/gunyah_platform_hooks.c        | 115 +++
 drivers/virt/gunyah/gunyah_qcom.c                  | 218 +++++
 drivers/virt/gunyah/gunyah_vcpu.c                  | 579 +++++++++++++
 drivers/virt/gunyah/rsc_mgr.c                      | 948 ++++++++++++++++++++
 drivers/virt/gunyah/rsc_mgr.h                      |  28 +
 drivers/virt/gunyah/rsc_mgr_rpc.c                  | 584 +++++++++++++
 drivers/virt/gunyah/vm_mgr.c                       | 963 +++++++++++++++++++++
 drivers/virt/gunyah/vm_mgr.h                       | 104 +++
 drivers/virt/gunyah/vm_mgr_mem.c                   | 326 +++++++
 include/linux/gunyah.h                             | 250 ++++++
 include/linux/gunyah_rsc_mgr.h                     | 208 +++++
 include/linux/gunyah_vm_mgr.h                      | 165 ++++
 include/uapi/linux/gunyah.h                        | 378 ++++++++
 31 files changed, 6683 insertions(+)
---
base-commit: 17cb8a20bde66a520a2ca7aad1063e1ce7382240
change-id: 20231208-gunyah-952aca7668e0

Best regards,
-- 
Elliot Berman <quic_eberman at quicinc.com>



From quic_eberman at quicinc.com  Fri Dec 15 16:20:50 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:50 -0800
Subject: [PATCH RFC v15 09/30] gunyah: vm_mgr: Introduce basic VM Manager
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-9-192a5d872a30@quicinc.com>

Gunyah VM manager is a kernel moduel which exposes an interface to
Gunyah userspace to load, run, and interact with other Gunyah virtual
machines. The interface is a character device at /dev/gunyah.

Add a basic VM manager driver. Upcoming patches will add more ioctls
into this driver.

Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
Reviewed-by: Alex Elder <elder at linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 Documentation/userspace-api/ioctl/ioctl-number.rst |  1 +
 drivers/virt/gunyah/Makefile                       |  2 +-
 drivers/virt/gunyah/rsc_mgr.c                      | 51 ++++++++++++
 drivers/virt/gunyah/vm_mgr.c                       | 94 ++++++++++++++++++++++
 drivers/virt/gunyah/vm_mgr.h                       | 22 +++++
 include/uapi/linux/gunyah.h                        | 23 ++++++
 6 files changed, 192 insertions(+), 1 deletion(-)

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index d8b6cb1a3636..91e01925a41b 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -137,6 +137,7 @@ Code  Seq#    Include File                                           Comments
 'F'   DD     video/sstfb.h                                           conflict!
 'G'   00-3F  drivers/misc/sgi-gru/grulib.h                           conflict!
 'G'   00-0F  xen/gntalloc.h, xen/gntdev.h                            conflict!
+'G'   00-0F  linux/gunyah.h                                          conflict!
 'H'   00-7F  linux/hiddev.h                                          conflict!
 'H'   00-0F  linux/hidraw.h                                          conflict!
 'H'   01     linux/mei.h                                             conflict!
diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index b1bdf3e84155..47f1fae5419b 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o
+gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o vm_mgr.o
 
 obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o
diff --git a/drivers/virt/gunyah/rsc_mgr.c b/drivers/virt/gunyah/rsc_mgr.c
index 2f9afe167aa6..052b3f072a85 100644
--- a/drivers/virt/gunyah/rsc_mgr.c
+++ b/drivers/virt/gunyah/rsc_mgr.c
@@ -15,8 +15,10 @@
 #include <linux/completion.h>
 #include <linux/gunyah_rsc_mgr.h>
 #include <linux/platform_device.h>
+#include <linux/miscdevice.h>
 
 #include "rsc_mgr.h"
+#include "vm_mgr.h"
 
 /* clang-format off */
 #define RM_RPC_API_VERSION_MASK		GENMASK(3, 0)
@@ -126,6 +128,7 @@ struct gunyah_rm_message {
  * @send_lock: synchronization to allow only one request to be sent at a time
  * @send_ready: completion to send messages again
  * @nh: notifier chain for clients interested in RM notification messages
+ * @miscdev: /dev/gunyah
  */
 struct gunyah_rm {
 	struct device *dev;
@@ -142,6 +145,8 @@ struct gunyah_rm {
 	struct mutex send_lock;
 	struct completion send_ready;
 	struct blocking_notifier_head nh;
+
+	struct miscdevice miscdev;
 };
 
 /**
@@ -618,6 +623,36 @@ int gunyah_rm_notifier_unregister(struct gunyah_rm *rm,
 }
 EXPORT_SYMBOL_GPL(gunyah_rm_notifier_unregister);
 
+struct device *gunyah_rm_get(struct gunyah_rm *rm)
+{
+	return get_device(rm->miscdev.this_device);
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_get);
+
+void gunyah_rm_put(struct gunyah_rm *rm)
+{
+	put_device(rm->miscdev.this_device);
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_put);
+
+static long gunyah_dev_ioctl(struct file *filp, unsigned int cmd,
+			     unsigned long arg)
+{
+	struct miscdevice *miscdev = filp->private_data;
+	struct gunyah_rm *rm = container_of(miscdev, struct gunyah_rm, miscdev);
+
+	return gunyah_dev_vm_mgr_ioctl(rm, cmd, arg);
+}
+
+static const struct file_operations gunyah_dev_fops = {
+	/* clang-format off */
+	.owner		= THIS_MODULE,
+	.unlocked_ioctl	= gunyah_dev_ioctl,
+	.compat_ioctl	= compat_ptr_ioctl,
+	.llseek		= noop_llseek,
+	/* clang-format on */
+};
+
 static int gunyah_platform_probe_capability(struct platform_device *pdev,
 					    int idx,
 					    struct gunyah_resource *ghrsc)
@@ -703,9 +738,24 @@ static int gunyah_rm_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	rm->miscdev.name = "gunyah";
+	rm->miscdev.minor = MISC_DYNAMIC_MINOR;
+	rm->miscdev.fops = &gunyah_dev_fops;
+
+	ret = misc_register(&rm->miscdev);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
+static void gunyah_rm_remove(struct platform_device *pdev)
+{
+	struct gunyah_rm *rm = platform_get_drvdata(pdev);
+
+	misc_deregister(&rm->miscdev);
+}
+
 static const struct of_device_id gunyah_rm_of_match[] = {
 	{ .compatible = "gunyah-resource-manager" },
 	{}
@@ -714,6 +764,7 @@ MODULE_DEVICE_TABLE(of, gunyah_rm_of_match);
 
 static struct platform_driver gunyah_rm_driver = {
 	.probe = gunyah_rm_probe,
+	.remove_new = gunyah_rm_remove,
 	.driver = {
 		.name = "gunyah_rsc_mgr",
 		.of_match_table = gunyah_rm_of_match,
diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
new file mode 100644
index 000000000000..b4d44379e5ce
--- /dev/null
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#define pr_fmt(fmt) "gunyah_vm_mgr: " fmt
+
+#include <linux/anon_inodes.h>
+#include <linux/file.h>
+#include <linux/gunyah_rsc_mgr.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+#include <uapi/linux/gunyah.h>
+
+#include "vm_mgr.h"
+
+static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
+{
+	struct gunyah_vm *ghvm;
+
+	ghvm = kzalloc(sizeof(*ghvm), GFP_KERNEL);
+	if (!ghvm)
+		return ERR_PTR(-ENOMEM);
+
+	ghvm->parent = gunyah_rm_get(rm);
+	ghvm->rm = rm;
+
+	return ghvm;
+}
+
+static int gunyah_vm_release(struct inode *inode, struct file *filp)
+{
+	struct gunyah_vm *ghvm = filp->private_data;
+
+	gunyah_rm_put(ghvm->rm);
+	kfree(ghvm);
+	return 0;
+}
+
+static const struct file_operations gunyah_vm_fops = {
+	.owner = THIS_MODULE,
+	.release = gunyah_vm_release,
+	.llseek = noop_llseek,
+};
+
+static long gunyah_dev_ioctl_create_vm(struct gunyah_rm *rm, unsigned long arg)
+{
+	struct gunyah_vm *ghvm;
+	struct file *file;
+	int fd, err;
+
+	/* arg reserved for future use. */
+	if (arg)
+		return -EINVAL;
+
+	ghvm = gunyah_vm_alloc(rm);
+	if (IS_ERR(ghvm))
+		return PTR_ERR(ghvm);
+
+	fd = get_unused_fd_flags(O_CLOEXEC);
+	if (fd < 0) {
+		err = fd;
+		goto err_destroy_vm;
+	}
+
+	file = anon_inode_getfile("gunyah-vm", &gunyah_vm_fops, ghvm, O_RDWR);
+	if (IS_ERR(file)) {
+		err = PTR_ERR(file);
+		goto err_put_fd;
+	}
+
+	fd_install(fd, file);
+
+	return fd;
+
+err_put_fd:
+	put_unused_fd(fd);
+err_destroy_vm:
+	gunyah_rm_put(ghvm->rm);
+	kfree(ghvm);
+	return err;
+}
+
+long gunyah_dev_vm_mgr_ioctl(struct gunyah_rm *rm, unsigned int cmd,
+			     unsigned long arg)
+{
+	switch (cmd) {
+	case GUNYAH_CREATE_VM:
+		return gunyah_dev_ioctl_create_vm(rm, arg);
+	default:
+		return -ENOTTY;
+	}
+}
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
new file mode 100644
index 000000000000..434a510e360f
--- /dev/null
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _GUNYAH_VM_MGR_PRIV_H
+#define _GUNYAH_VM_MGR_PRIV_H
+
+#include <linux/device.h>
+#include <linux/gunyah_rsc_mgr.h>
+
+#include <uapi/linux/gunyah.h>
+
+long gunyah_dev_vm_mgr_ioctl(struct gunyah_rm *rm, unsigned int cmd,
+			     unsigned long arg);
+
+struct gunyah_vm {
+	struct gunyah_rm *rm;
+	struct device *parent;
+};
+
+#endif
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
new file mode 100644
index 000000000000..ac338ec4b85d
--- /dev/null
+++ b/include/uapi/linux/gunyah.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _UAPI_LINUX_GUNYAH_H
+#define _UAPI_LINUX_GUNYAH_H
+
+/*
+ * Userspace interface for /dev/gunyah - gunyah based virtual machine
+ */
+
+#include <linux/types.h>
+#include <linux/ioctl.h>
+
+#define GUNYAH_IOCTL_TYPE 'G'
+
+/*
+ * ioctls for /dev/gunyah fds:
+ */
+#define GUNYAH_CREATE_VM _IO(GUNYAH_IOCTL_TYPE, 0x0) /* Returns a Gunyah VM fd */
+
+#endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:54 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:54 -0800
Subject: [PATCH RFC v15 13/30] virt: gunyah: Add resource tickets
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-13-192a5d872a30@quicinc.com>

Some VM functions need to acquire Gunyah resources. For instance, Gunyah
vCPUs are exposed to the host as a resource. The Gunyah vCPU function
will register a resource ticket and be able to interact with the
hypervisor once the resource ticket is filled.

Resource tickets are the mechanism for functions to acquire ownership of
Gunyah resources. Gunyah functions can be created before the VM's
resources are created and made available to Linux. A resource ticket
identifies a type of resource and a label of a resource which the ticket
holder is interested in.

Resources are created by Gunyah as configured in the VM's devicetree
configuration. Gunyah doesn't process the label and that makes it
possible for userspace to create multiple resources with the same label.
Resource ticket owners need to be prepared for populate to be called
multiple times if userspace created multiple resources with the same
label.

Reviewed-by: Alex Elder <elder at linaro.org>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/vm_mgr.c  | 127 +++++++++++++++++++++++++++++++++++++++++-
 drivers/virt/gunyah/vm_mgr.h  |   3 +
 include/linux/gunyah_vm_mgr.h |  36 ++++++++++++
 3 files changed, 165 insertions(+), 1 deletion(-)

diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index 81bc73047e1e..fb22459b21c8 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -185,6 +185,106 @@ void gunyah_vm_function_unregister(struct gunyah_vm_function *fn)
 }
 EXPORT_SYMBOL_GPL(gunyah_vm_function_unregister);
 
+int gunyah_vm_add_resource_ticket(struct gunyah_vm *ghvm,
+				  struct gunyah_vm_resource_ticket *ticket)
+{
+	struct gunyah_vm_resource_ticket *iter;
+	struct gunyah_resource *ghrsc, *rsc_iter;
+	int ret = 0;
+
+	mutex_lock(&ghvm->resources_lock);
+	list_for_each_entry(iter, &ghvm->resource_tickets, vm_list) {
+		if (iter->resource_type == ticket->resource_type &&
+		    iter->label == ticket->label) {
+			ret = -EEXIST;
+			goto out;
+		}
+	}
+
+	if (!try_module_get(ticket->owner)) {
+		ret = -ENODEV;
+		goto out;
+	}
+
+	list_add(&ticket->vm_list, &ghvm->resource_tickets);
+	INIT_LIST_HEAD(&ticket->resources);
+
+	list_for_each_entry_safe(ghrsc, rsc_iter, &ghvm->resources, list) {
+		if (ghrsc->type == ticket->resource_type &&
+		    ghrsc->rm_label == ticket->label) {
+			if (ticket->populate(ticket, ghrsc))
+				list_move(&ghrsc->list, &ticket->resources);
+		}
+	}
+out:
+	mutex_unlock(&ghvm->resources_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(gunyah_vm_add_resource_ticket);
+
+void gunyah_vm_remove_resource_ticket(struct gunyah_vm *ghvm,
+				      struct gunyah_vm_resource_ticket *ticket)
+{
+	struct gunyah_resource *ghrsc, *iter;
+
+	mutex_lock(&ghvm->resources_lock);
+	list_for_each_entry_safe(ghrsc, iter, &ticket->resources, list) {
+		ticket->unpopulate(ticket, ghrsc);
+		list_move(&ghrsc->list, &ghvm->resources);
+	}
+
+	module_put(ticket->owner);
+	list_del(&ticket->vm_list);
+	mutex_unlock(&ghvm->resources_lock);
+}
+EXPORT_SYMBOL_GPL(gunyah_vm_remove_resource_ticket);
+
+static void gunyah_vm_add_resource(struct gunyah_vm *ghvm,
+				   struct gunyah_resource *ghrsc)
+{
+	struct gunyah_vm_resource_ticket *ticket;
+
+	mutex_lock(&ghvm->resources_lock);
+	list_for_each_entry(ticket, &ghvm->resource_tickets, vm_list) {
+		if (ghrsc->type == ticket->resource_type &&
+		    ghrsc->rm_label == ticket->label) {
+			if (ticket->populate(ticket, ghrsc))
+				list_add(&ghrsc->list, &ticket->resources);
+			else
+				list_add(&ghrsc->list, &ghvm->resources);
+			/* unconditonal -- we prevent multiple identical
+			 * resource tickets so there will not be some other
+			 * ticket elsewhere in the list if populate() failed.
+			 */
+			goto found;
+		}
+	}
+	list_add(&ghrsc->list, &ghvm->resources);
+found:
+	mutex_unlock(&ghvm->resources_lock);
+}
+
+static void gunyah_vm_clean_resources(struct gunyah_vm *ghvm)
+{
+	struct gunyah_vm_resource_ticket *ticket, *titer;
+	struct gunyah_resource *ghrsc, *riter;
+
+	mutex_lock(&ghvm->resources_lock);
+	if (!list_empty(&ghvm->resource_tickets)) {
+		dev_warn(ghvm->parent, "Dangling resource tickets:\n");
+		list_for_each_entry_safe(ticket, titer, &ghvm->resource_tickets,
+					 vm_list) {
+			dev_warn(ghvm->parent, "  %pS\n", ticket->populate);
+			gunyah_vm_remove_resource_ticket(ghvm, ticket);
+		}
+	}
+
+	list_for_each_entry_safe(ghrsc, riter, &ghvm->resources, list) {
+		gunyah_rm_free_resource(ghrsc);
+	}
+	mutex_unlock(&ghvm->resources_lock);
+}
+
 static int gunyah_vm_rm_notification_status(struct gunyah_vm *ghvm, void *data)
 {
 	struct gunyah_rm_vm_status_payload *payload = data;
@@ -263,6 +363,9 @@ static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 	init_waitqueue_head(&ghvm->vm_status_wait);
 	kref_init(&ghvm->kref);
 	ghvm->vm_status = GUNYAH_RM_VM_STATUS_NO_STATE;
+	mutex_init(&ghvm->resources_lock);
+	INIT_LIST_HEAD(&ghvm->resources);
+	INIT_LIST_HEAD(&ghvm->resource_tickets);
 	INIT_LIST_HEAD(&ghvm->functions);
 	mutex_init(&ghvm->fn_lock);
 
@@ -271,7 +374,9 @@ static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 
 static int gunyah_vm_start(struct gunyah_vm *ghvm)
 {
-	int ret;
+	struct gunyah_rm_hyp_resources *resources;
+	struct gunyah_resource *ghrsc;
+	int ret, i, n;
 
 	down_write(&ghvm->status_lock);
 	if (ghvm->vm_status != GUNYAH_RM_VM_STATUS_NO_STATE) {
@@ -307,6 +412,25 @@ static int gunyah_vm_start(struct gunyah_vm *ghvm)
 	}
 	ghvm->vm_status = GUNYAH_RM_VM_STATUS_READY;
 
+	ret = gunyah_rm_get_hyp_resources(ghvm->rm, ghvm->vmid, &resources);
+	if (ret) {
+		dev_warn(ghvm->parent,
+			 "Failed to get hypervisor resources for VM: %d\n",
+			 ret);
+		goto err;
+	}
+
+	for (i = 0, n = le32_to_cpu(resources->n_entries); i < n; i++) {
+		ghrsc = gunyah_rm_alloc_resource(ghvm->rm,
+						 &resources->entries[i]);
+		if (!ghrsc) {
+			ret = -ENOMEM;
+			goto err;
+		}
+
+		gunyah_vm_add_resource(ghvm, ghrsc);
+	}
+
 	ret = gunyah_rm_vm_start(ghvm->rm, ghvm->vmid);
 	if (ret) {
 		dev_warn(ghvm->parent, "Failed to start VM: %d\n", ret);
@@ -404,6 +528,7 @@ static void _gunyah_vm_put(struct kref *kref)
 		gunyah_vm_stop(ghvm);
 
 	gunyah_vm_remove_functions(ghvm);
+	gunyah_vm_clean_resources(ghvm);
 
 	if (ghvm->vm_status != GUNYAH_RM_VM_STATUS_NO_STATE &&
 	    ghvm->vm_status != GUNYAH_RM_VM_STATUS_LOAD &&
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index a9e0eaf212fd..b94f6d16b787 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -34,6 +34,9 @@ struct gunyah_vm {
 	struct kref kref;
 	struct mutex fn_lock;
 	struct list_head functions;
+	struct mutex resources_lock;
+	struct list_head resources;
+	struct list_head resource_tickets;
 };
 
 #endif
diff --git a/include/linux/gunyah_vm_mgr.h b/include/linux/gunyah_vm_mgr.h
index f40e57f32fd8..b02c6e89b207 100644
--- a/include/linux/gunyah_vm_mgr.h
+++ b/include/linux/gunyah_vm_mgr.h
@@ -97,4 +97,40 @@ void gunyah_vm_function_unregister(struct gunyah_vm_function *f);
 	module_gunyah_vm_function(_name);                                   \
 	MODULE_ALIAS_GUNYAH_VM_FUNCTION(_type, _idx)
 
+/**
+ * struct gunyah_vm_resource_ticket - Represents a ticket to reserve access to VM resource(s)
+ * @vm_list: for @gunyah_vm->resource_tickets
+ * @resources: List of resource(s) associated with this ticket
+ *             (members are from @gunyah_resource->list)
+ * @resource_type: Type of resource this ticket reserves
+ * @label: Label of the resource from resource manager this ticket reserves.
+ * @owner: owner of the ticket
+ * @populate: callback provided by the ticket owner and called when a resource is found that
+ *            matches @resource_type and @label. Note that this callback could be called
+ *            multiple times if userspace created mutliple resources with the same type/label.
+ *            This callback may also have significant delay after gunyah_vm_add_resource_ticket()
+ *            since gunyah_vm_add_resource_ticket() could be called before the VM starts.
+ * @unpopulate: callback provided by the ticket owner and called when the ticket owner should no
+ *              longer use the resource provided in the argument. When unpopulate() returns,
+ *              the ticket owner should not be able to use the resource any more as the resource
+ *              might being freed.
+ */
+struct gunyah_vm_resource_ticket {
+	struct list_head vm_list;
+	struct list_head resources;
+	enum gunyah_resource_type resource_type;
+	u32 label;
+
+	struct module *owner;
+	bool (*populate)(struct gunyah_vm_resource_ticket *ticket,
+			 struct gunyah_resource *ghrsc);
+	void (*unpopulate)(struct gunyah_vm_resource_ticket *ticket,
+			   struct gunyah_resource *ghrsc);
+};
+
+int gunyah_vm_add_resource_ticket(struct gunyah_vm *ghvm,
+				  struct gunyah_vm_resource_ticket *ticket);
+void gunyah_vm_remove_resource_ticket(struct gunyah_vm *ghvm,
+				      struct gunyah_vm_resource_ticket *ticket);
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:49 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:49 -0800
Subject: [PATCH RFC v15 08/30] gunyah: rsc_mgr: Add VM lifecycle RPC
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-8-192a5d872a30@quicinc.com>

Add Gunyah Resource Manager RPC to launch an unauthenticated VM.

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/Makefile      |   2 +-
 drivers/virt/gunyah/rsc_mgr_rpc.c | 570 ++++++++++++++++++++++++++++++++++++++
 include/linux/gunyah_rsc_mgr.h    | 144 ++++++++++
 3 files changed, 715 insertions(+), 1 deletion(-)

diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index c2308389f551..b1bdf3e84155 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-gunyah_rsc_mgr-y += rsc_mgr.o
+gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o
 
 obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o
diff --git a/drivers/virt/gunyah/rsc_mgr_rpc.c b/drivers/virt/gunyah/rsc_mgr_rpc.c
new file mode 100644
index 000000000000..9954512dbdde
--- /dev/null
+++ b/drivers/virt/gunyah/rsc_mgr_rpc.c
@@ -0,0 +1,570 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/gunyah_rsc_mgr.h>
+#include "rsc_mgr.h"
+
+/* Message IDs: Memory Management */
+#define GUNYAH_RM_RPC_MEM_LEND 0x51000012
+#define GUNYAH_RM_RPC_MEM_SHARE 0x51000013
+#define GUNYAH_RM_RPC_MEM_RECLAIM 0x51000015
+#define GUNYAH_RM_RPC_MEM_APPEND 0x51000018
+
+/* Message IDs: VM Management */
+/* clang-format off */
+#define GUNYAH_RM_RPC_VM_ALLOC_VMID		0x56000001
+#define GUNYAH_RM_RPC_VM_DEALLOC_VMID		0x56000002
+#define GUNYAH_RM_RPC_VM_START			0x56000004
+#define GUNYAH_RM_RPC_VM_STOP			0x56000005
+#define GUNYAH_RM_RPC_VM_RESET			0x56000006
+#define GUNYAH_RM_RPC_VM_CONFIG_IMAGE		0x56000009
+#define GUNYAH_RM_RPC_VM_INIT			0x5600000B
+#define GUNYAH_RM_RPC_VM_SET_BOOT_CONTEXT	0x5600000C
+#define GUNYAH_RM_RPC_VM_GET_HYP_RESOURCES	0x56000020
+#define GUNYAH_RM_RPC_VM_GET_VMID		0x56000024
+#define GUNYAH_RM_RPC_VM_SET_DEMAND_PAGING	0x56000033
+#define GUNYAH_RM_RPC_VM_SET_ADDRESS_LAYOUT	0x56000034
+/* clang-format on */
+
+/* Message IDs: Miscellaneous */
+/* clang-format off */
+#define GUNYAH_RM_RPC_GET_LOG_ADDRESS		0x56000100
+/* clang-format on */
+
+struct gunyah_rm_vm_common_vmid_req {
+	__le16 vmid;
+	__le16 _padding;
+} __packed;
+
+/* Call: MEM_LEND, MEM_SHARE */
+#define GUNYAH_MEM_SHARE_REQ_FLAGS_APPEND BIT(1)
+
+struct gunyah_rm_mem_share_req_header {
+	u8 mem_type;
+	u8 _padding0;
+	u8 flags;
+	u8 _padding1;
+	__le32 label;
+} __packed;
+
+struct gunyah_rm_mem_share_req_acl_section {
+	__le32 n_entries;
+	struct gunyah_rm_mem_acl_entry entries[];
+} __packed;
+
+struct gunyah_rm_mem_share_req_mem_section {
+	__le16 n_entries;
+	__le16 _padding;
+	struct gunyah_rm_mem_entry entries[];
+} __packed;
+
+/* Call: MEM_RELEASE */
+struct gunyah_rm_mem_release_req {
+	__le32 mem_handle;
+	u8 flags; /* currently not used */
+	u8 _padding0;
+	__le16 _padding1;
+} __packed;
+
+/* Call: MEM_APPEND */
+#define GUNYAH_MEM_APPEND_REQ_FLAGS_END BIT(0)
+
+struct gunyah_rm_mem_append_req_header {
+	__le32 mem_handle;
+	u8 flags;
+	u8 _padding0;
+	__le16 _padding1;
+} __packed;
+
+/* Call: VM_ALLOC */
+struct gunyah_rm_vm_alloc_vmid_resp {
+	__le16 vmid;
+	__le16 _padding;
+} __packed;
+
+/* Call: VM_STOP */
+#define GUNYAH_RM_VM_STOP_FLAG_FORCE_STOP BIT(0)
+
+#define GUNYAH_RM_VM_STOP_REASON_FORCE_STOP 3
+
+struct gunyah_rm_vm_stop_req {
+	__le16 vmid;
+	u8 flags;
+	u8 _padding;
+	__le32 stop_reason;
+} __packed;
+
+/* Call: VM_CONFIG_IMAGE */
+struct gunyah_rm_vm_config_image_req {
+	__le16 vmid;
+	__le16 auth_mech;
+	__le32 mem_handle;
+	__le64 image_offset;
+	__le64 image_size;
+	__le64 dtb_offset;
+	__le64 dtb_size;
+} __packed;
+
+#define GUNYAH_RM_MAX_MEM_ENTRIES 512
+
+/* Call: VM_SET_BOOT_CONTEXT */
+struct gunyah_rm_vm_set_boot_context_req {
+	__le16 vmid;
+	u8 reg_set;
+	u8 reg_index;
+	__le32 _padding;
+	__le64 value;
+} __packed;
+
+/* Call: VM_SET_DEMAND_PAGING */
+struct gunyah_rm_vm_set_demand_paging_req {
+	__le16 vmid;
+	__le16 _padding;
+	__le32 range_count;
+	DECLARE_FLEX_ARRAY(struct gunyah_rm_mem_entry, ranges);
+} __packed;
+
+/* Call: VM_SET_ADDRESS_LAYOUT */
+struct gunyah_rm_vm_set_address_layout_req {
+	__le16 vmid;
+	__le16 _padding;
+	__le32 range_id;
+	__le64 range_base;
+	__le64 range_size;
+} __packed;
+
+/*
+ * Several RM calls take only a VMID as a parameter and give only standard
+ * response back. Deduplicate boilerplate code by using this common call.
+ */
+static int gunyah_rm_common_vmid_call(struct gunyah_rm *rm, u32 message_id,
+				      u16 vmid)
+{
+	struct gunyah_rm_vm_common_vmid_req req_payload = {
+		.vmid = cpu_to_le16(vmid),
+	};
+
+	return gunyah_rm_call(rm, message_id, &req_payload, sizeof(req_payload),
+			      NULL, NULL);
+}
+
+static int gunyah_rm_mem_append(struct gunyah_rm *rm, u32 mem_handle,
+				struct gunyah_rm_mem_entry *entries,
+				size_t n_entries)
+{
+	struct gunyah_rm_mem_append_req_header *req __free(kfree) = NULL;
+	struct gunyah_rm_mem_share_req_mem_section *mem;
+	int ret = 0;
+	size_t n;
+
+	req = kzalloc(sizeof(*req) + struct_size(mem, entries, GUNYAH_RM_MAX_MEM_ENTRIES),
+		      GFP_KERNEL);
+	if (!req)
+		return -ENOMEM;
+
+	req->mem_handle = cpu_to_le32(mem_handle);
+	mem = (void *)(req + 1);
+
+	while (n_entries) {
+		req->flags = 0;
+		if (n_entries > GUNYAH_RM_MAX_MEM_ENTRIES) {
+			n = GUNYAH_RM_MAX_MEM_ENTRIES;
+		} else {
+			req->flags |= GUNYAH_MEM_APPEND_REQ_FLAGS_END;
+			n = n_entries;
+		}
+
+		mem->n_entries = cpu_to_le16(n);
+		memcpy(mem->entries, entries, sizeof(*entries) * n);
+
+		ret = gunyah_rm_call(rm, GUNYAH_RM_RPC_MEM_APPEND, req,
+				     sizeof(*req) + struct_size(mem, entries, n),
+				     NULL, NULL);
+		if (ret)
+			break;
+
+		entries += n;
+		n_entries -= n;
+	}
+
+	return ret;
+}
+
+/**
+ * gunyah_rm_mem_share() - Share memory with other virtual machines.
+ * @rm: Handle to a Gunyah resource manager
+ * @p: Information about the memory to be shared.
+ *
+ * Sharing keeps Linux's access to the memory while the memory parcel is shared.
+ */
+int gunyah_rm_mem_share(struct gunyah_rm *rm, struct gunyah_rm_mem_parcel *p)
+{
+	u32 message_id = p->n_acl_entries == 1 ? GUNYAH_RM_RPC_MEM_LEND :
+						 GUNYAH_RM_RPC_MEM_SHARE;
+	size_t msg_size, initial_mem_entries = p->n_mem_entries, resp_size;
+	struct gunyah_rm_mem_share_req_acl_section *acl;
+	struct gunyah_rm_mem_share_req_mem_section *mem;
+	struct gunyah_rm_mem_share_req_header *req_header;
+	size_t acl_size, mem_size;
+	u32 *attr_section;
+	bool need_append = false;
+	__le32 *resp;
+	void *msg;
+	int ret;
+
+	if (!p->acl_entries || !p->n_acl_entries || !p->mem_entries ||
+	    !p->n_mem_entries || p->n_acl_entries > U8_MAX ||
+	    p->mem_handle != GUNYAH_MEM_HANDLE_INVAL)
+		return -EINVAL;
+
+	if (initial_mem_entries > GUNYAH_RM_MAX_MEM_ENTRIES) {
+		initial_mem_entries = GUNYAH_RM_MAX_MEM_ENTRIES;
+		need_append = true;
+	}
+
+	acl_size = struct_size(acl, entries, p->n_acl_entries);
+	mem_size = struct_size(mem, entries, initial_mem_entries);
+
+	/* The format of the message goes:
+	 * request header
+	 * ACL entries (which VMs get what kind of access to this memory parcel)
+	 * Memory entries (list of memory regions to share)
+	 * Memory attributes (currently unused, we'll hard-code the size to 0)
+	 */
+	msg_size = sizeof(struct gunyah_rm_mem_share_req_header) + acl_size +
+		   mem_size +
+		   sizeof(u32); /* for memory attributes, currently unused */
+
+	msg = kzalloc(msg_size, GFP_KERNEL);
+	if (!msg)
+		return -ENOMEM;
+
+	req_header = msg;
+	acl = (void *)req_header + sizeof(*req_header);
+	mem = (void *)acl + acl_size;
+	attr_section = (void *)mem + mem_size;
+
+	req_header->mem_type = p->mem_type;
+	if (need_append)
+		req_header->flags |= GUNYAH_MEM_SHARE_REQ_FLAGS_APPEND;
+	req_header->label = cpu_to_le32(p->label);
+
+	acl->n_entries = cpu_to_le32(p->n_acl_entries);
+	memcpy(acl->entries, p->acl_entries,
+	       flex_array_size(acl, entries, p->n_acl_entries));
+
+	mem->n_entries = cpu_to_le16(initial_mem_entries);
+	memcpy(mem->entries, p->mem_entries,
+	       flex_array_size(mem, entries, initial_mem_entries));
+
+	/* Set n_entries for memory attribute section to 0 */
+	*attr_section = 0;
+
+	ret = gunyah_rm_call(rm, message_id, msg, msg_size, (void **)&resp,
+			     &resp_size);
+	kfree(msg);
+
+	if (ret)
+		return ret;
+
+	p->mem_handle = le32_to_cpu(*resp);
+	kfree(resp);
+
+	if (need_append) {
+		ret = gunyah_rm_mem_append(
+			rm, p->mem_handle, &p->mem_entries[initial_mem_entries],
+			p->n_mem_entries - initial_mem_entries);
+		if (ret) {
+			gunyah_rm_mem_reclaim(rm, p);
+			p->mem_handle = GUNYAH_MEM_HANDLE_INVAL;
+		}
+	}
+
+	return ret;
+}
+
+/**
+ * gunyah_rm_mem_reclaim() - Reclaim a memory parcel
+ * @rm: Handle to a Gunyah resource manager
+ * @parcel: Information about the memory to be reclaimed.
+ *
+ * RM maps the associated memory back into the stage-2 page tables of the owner VM.
+ */
+int gunyah_rm_mem_reclaim(struct gunyah_rm *rm,
+			  struct gunyah_rm_mem_parcel *parcel)
+{
+	struct gunyah_rm_mem_release_req req = {
+		.mem_handle = cpu_to_le32(parcel->mem_handle),
+	};
+
+	return gunyah_rm_call(rm, GUNYAH_RM_RPC_MEM_RECLAIM, &req, sizeof(req),
+			      NULL, NULL);
+}
+
+/**
+ * gunyah_rm_alloc_vmid() - Allocate a new VM in Gunyah. Returns the VM identifier.
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: Use 0 to dynamically allocate a VM. A reserved VMID can be supplied
+ *        to request allocation of a platform-defined VM.
+ *
+ * Return: the allocated VMID or negative value on error
+ */
+int gunyah_rm_alloc_vmid(struct gunyah_rm *rm, u16 vmid)
+{
+	struct gunyah_rm_vm_common_vmid_req req_payload = {
+		.vmid = cpu_to_le16(vmid),
+	};
+	struct gunyah_rm_vm_alloc_vmid_resp *resp_payload;
+	size_t resp_size;
+	void *resp;
+	int ret;
+
+	ret = gunyah_rm_call(rm, GUNYAH_RM_RPC_VM_ALLOC_VMID, &req_payload,
+			     sizeof(req_payload), &resp, &resp_size);
+	if (ret)
+		return ret;
+
+	if (!vmid) {
+		resp_payload = resp;
+		ret = le16_to_cpu(resp_payload->vmid);
+		kfree(resp);
+	}
+
+	return ret;
+}
+
+/**
+ * gunyah_rm_dealloc_vmid() - Dispose of a VMID
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: VM identifier allocated with gunyah_rm_alloc_vmid
+ */
+int gunyah_rm_dealloc_vmid(struct gunyah_rm *rm, u16 vmid)
+{
+	return gunyah_rm_common_vmid_call(rm, GUNYAH_RM_RPC_VM_DEALLOC_VMID,
+					  vmid);
+}
+
+/**
+ * gunyah_rm_vm_reset() - Reset a VM's resources
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: VM identifier allocated with gunyah_rm_alloc_vmid
+ *
+ * As part of tearing down the VM, request RM to clean up all the VM resources
+ * associated with the VM. Only after this, Linux can clean up all the
+ * references it maintains to resources.
+ */
+int gunyah_rm_vm_reset(struct gunyah_rm *rm, u16 vmid)
+{
+	return gunyah_rm_common_vmid_call(rm, GUNYAH_RM_RPC_VM_RESET, vmid);
+}
+
+/**
+ * gunyah_rm_vm_start() - Move a VM into "ready to run" state
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: VM identifier allocated with gunyah_rm_alloc_vmid
+ *
+ * On VMs which use proxy scheduling, vcpu_run is needed to actually run the VM.
+ * On VMs which use Gunyah's scheduling, the vCPUs start executing in accordance with Gunyah
+ * scheduling policies.
+ */
+int gunyah_rm_vm_start(struct gunyah_rm *rm, u16 vmid)
+{
+	return gunyah_rm_common_vmid_call(rm, GUNYAH_RM_RPC_VM_START, vmid);
+}
+
+/**
+ * gunyah_rm_vm_stop() - Send a request to Resource Manager VM to forcibly stop a VM.
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: VM identifier allocated with gunyah_rm_alloc_vmid
+ */
+int gunyah_rm_vm_stop(struct gunyah_rm *rm, u16 vmid)
+{
+	struct gunyah_rm_vm_stop_req req_payload = {
+		.vmid = cpu_to_le16(vmid),
+		.flags = GUNYAH_RM_VM_STOP_FLAG_FORCE_STOP,
+		.stop_reason = cpu_to_le32(GUNYAH_RM_VM_STOP_REASON_FORCE_STOP),
+	};
+
+	return gunyah_rm_call(rm, GUNYAH_RM_RPC_VM_STOP, &req_payload,
+			      sizeof(req_payload), NULL, NULL);
+}
+
+/**
+ * gunyah_rm_vm_configure() - Prepare a VM to start and provide the common
+ *			  configuration needed by RM to configure a VM
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: VM identifier allocated with gunyah_rm_alloc_vmid
+ * @auth_mechanism: Authentication mechanism used by resource manager to verify
+ *                  the virtual machine
+ * @mem_handle: Handle to a previously shared memparcel that contains all parts
+ *              of the VM image subject to authentication.
+ * @image_offset: Start address of VM image, relative to the start of memparcel
+ * @image_size: Size of the VM image
+ * @dtb_offset: Start address of the devicetree binary with VM configuration,
+ *              relative to start of memparcel.
+ * @dtb_size: Maximum size of devicetree binary.
+ */
+int gunyah_rm_vm_configure(struct gunyah_rm *rm, u16 vmid,
+			   enum gunyah_rm_vm_auth_mechanism auth_mechanism,
+			   u32 mem_handle, u64 image_offset, u64 image_size,
+			   u64 dtb_offset, u64 dtb_size)
+{
+	struct gunyah_rm_vm_config_image_req req_payload = {
+		.vmid = cpu_to_le16(vmid),
+		.auth_mech = cpu_to_le16(auth_mechanism),
+		.mem_handle = cpu_to_le32(mem_handle),
+		.image_offset = cpu_to_le64(image_offset),
+		.image_size = cpu_to_le64(image_size),
+		.dtb_offset = cpu_to_le64(dtb_offset),
+		.dtb_size = cpu_to_le64(dtb_size),
+	};
+
+	return gunyah_rm_call(rm, GUNYAH_RM_RPC_VM_CONFIG_IMAGE, &req_payload,
+			      sizeof(req_payload), NULL, NULL);
+}
+
+/**
+ * gunyah_rm_vm_init() - Move the VM to initialized state.
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: VM identifier
+ *
+ * RM will allocate needed resources for the VM.
+ */
+int gunyah_rm_vm_init(struct gunyah_rm *rm, u16 vmid)
+{
+	return gunyah_rm_common_vmid_call(rm, GUNYAH_RM_RPC_VM_INIT, vmid);
+}
+
+int gunyah_rm_vm_set_boot_context(struct gunyah_rm *rm, u16 vmid, u8 reg_set,
+				  u8 reg_index, u64 value)
+{
+	struct gunyah_rm_vm_set_boot_context_req req_payload = {
+		.vmid = cpu_to_le16(vmid),
+		.reg_set = reg_set,
+		.reg_index = reg_index,
+		.value = cpu_to_le64(value),
+	};
+
+	return gunyah_rm_call(rm, GUNYAH_RM_RPC_VM_SET_BOOT_CONTEXT,
+			      &req_payload, sizeof(req_payload), NULL, NULL);
+}
+
+/**
+ * gunyah_rm_get_hyp_resources() - Retrieve hypervisor resources (capabilities) associated with a VM
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: VMID of the other VM to get the resources of
+ * @resources: Set by gunyah_rm_get_hyp_resources and contains the returned hypervisor resources.
+ *             Caller must free the resources pointer if successful.
+ */
+int gunyah_rm_get_hyp_resources(struct gunyah_rm *rm, u16 vmid,
+				struct gunyah_rm_hyp_resources **resources)
+{
+	struct gunyah_rm_vm_common_vmid_req req_payload = {
+		.vmid = cpu_to_le16(vmid),
+	};
+	struct gunyah_rm_hyp_resources *resp;
+	size_t resp_size;
+	int ret;
+
+	ret = gunyah_rm_call(rm, GUNYAH_RM_RPC_VM_GET_HYP_RESOURCES,
+			     &req_payload, sizeof(req_payload), (void **)&resp,
+			     &resp_size);
+	if (ret)
+		return ret;
+
+	if (!resp_size)
+		return -EBADMSG;
+
+	if (resp_size < struct_size(resp, entries, 0) ||
+	    resp_size !=
+		    struct_size(resp, entries, le32_to_cpu(resp->n_entries))) {
+		kfree(resp);
+		return -EBADMSG;
+	}
+
+	*resources = resp;
+	return 0;
+}
+
+/**
+ * gunyah_rm_get_vmid() - Retrieve VMID of this virtual machine
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: Filled with the VMID of this VM
+ */
+int gunyah_rm_get_vmid(struct gunyah_rm *rm, u16 *vmid)
+{
+	static u16 cached_vmid = GUNYAH_VMID_INVAL;
+	size_t resp_size;
+	__le32 *resp;
+	int ret;
+
+	if (cached_vmid != GUNYAH_VMID_INVAL) {
+		*vmid = cached_vmid;
+		return 0;
+	}
+
+	ret = gunyah_rm_call(rm, GUNYAH_RM_RPC_VM_GET_VMID, NULL, 0,
+			     (void **)&resp, &resp_size);
+	if (ret)
+		return ret;
+
+	*vmid = cached_vmid = lower_16_bits(le32_to_cpu(*resp));
+	kfree(resp);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_get_vmid);
+
+/**
+ * gunyah_rm_vm_set_demand_paging() - Enable demand paging of memory regions
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: VMID of the other VM
+ * @count: Number of demand paged memory regions
+ * @entries: Array of the regions
+ */
+int gunyah_rm_vm_set_demand_paging(struct gunyah_rm *rm, u16 vmid, u32 count,
+				   struct gunyah_rm_mem_entry *entries)
+{
+	struct gunyah_rm_vm_set_demand_paging_req *req __free(kfree) = NULL;
+	size_t req_size;
+
+	req_size = struct_size(req, ranges, count);
+	if (req_size == SIZE_MAX)
+		return -EINVAL;
+
+	req = kzalloc(req_size, GFP_KERNEL);
+	if (!req)
+		return -ENOMEM;
+
+	req->vmid = cpu_to_le16(vmid);
+	req->range_count = cpu_to_le32(count);
+	memcpy(req->ranges, entries, sizeof(*entries) * count);
+
+	return gunyah_rm_call(rm, GUNYAH_RM_RPC_VM_SET_DEMAND_PAGING, req,
+			      req_size, NULL, NULL);
+}
+
+/**
+ * gunyah_rm_vm_set_address_layout() - Set the start address of images
+ * @rm: Handle to a Gunyah resource manager
+ * @vmid: VMID of the other VM
+ * @range_id: Which image to set
+ * @base_address: Base address
+ * @size: Size
+ */
+int gunyah_rm_vm_set_address_layout(struct gunyah_rm *rm, u16 vmid,
+				    enum gunyah_rm_range_id range_id,
+				    u64 base_address, u64 size)
+{
+	struct gunyah_rm_vm_set_address_layout_req req = {
+		.vmid = cpu_to_le16(vmid),
+		.range_id = cpu_to_le32(range_id),
+		.range_base = cpu_to_le64(base_address),
+		.range_size = cpu_to_le64(size),
+	};
+
+	return gunyah_rm_call(rm, GUNYAH_RM_RPC_VM_SET_ADDRESS_LAYOUT, &req,
+			      sizeof(req), NULL, NULL);
+}
diff --git a/include/linux/gunyah_rsc_mgr.h b/include/linux/gunyah_rsc_mgr.h
index e151f66be96e..7bd2bee91f3e 100644
--- a/include/linux/gunyah_rsc_mgr.h
+++ b/include/linux/gunyah_rsc_mgr.h
@@ -10,6 +10,7 @@
 #include <linux/gunyah.h>
 
 #define GUNYAH_VMID_INVAL U16_MAX
+#define GUNYAH_MEM_HANDLE_INVAL U32_MAX
 
 struct gunyah_rm;
 int gunyah_rm_notifier_register(struct gunyah_rm *rm,
@@ -19,4 +20,147 @@ int gunyah_rm_notifier_unregister(struct gunyah_rm *rm,
 struct device *gunyah_rm_get(struct gunyah_rm *rm);
 void gunyah_rm_put(struct gunyah_rm *rm);
 
+struct gunyah_rm_vm_exited_payload {
+	__le16 vmid;
+	__le16 exit_type;
+	__le32 exit_reason_size;
+	u8 exit_reason[];
+} __packed;
+
+enum gunyah_rm_notification_id {
+	/* clang-format off */
+	GUNYAH_RM_NOTIFICATION_VM_EXITED		 = 0x56100001,
+	GUNYAH_RM_NOTIFICATION_VM_STATUS		 = 0x56100008,
+	/* clang-format on */
+};
+
+enum gunyah_rm_vm_status {
+	/* clang-format off */
+	GUNYAH_RM_VM_STATUS_NO_STATE		= 0,
+	GUNYAH_RM_VM_STATUS_INIT		= 1,
+	GUNYAH_RM_VM_STATUS_READY		= 2,
+	GUNYAH_RM_VM_STATUS_RUNNING		= 3,
+	GUNYAH_RM_VM_STATUS_PAUSED		= 4,
+	GUNYAH_RM_VM_STATUS_LOAD		= 5,
+	GUNYAH_RM_VM_STATUS_AUTH		= 6,
+	GUNYAH_RM_VM_STATUS_INIT_FAILED		= 8,
+	GUNYAH_RM_VM_STATUS_EXITED		= 9,
+	GUNYAH_RM_VM_STATUS_RESETTING		= 10,
+	GUNYAH_RM_VM_STATUS_RESET		= 11,
+	/* clang-format on */
+};
+
+struct gunyah_rm_vm_status_payload {
+	__le16 vmid;
+	u16 reserved;
+	u8 vm_status;
+	u8 os_status;
+	__le16 app_status;
+} __packed;
+
+#define GUNYAH_RM_ACL_X BIT(0)
+#define GUNYAH_RM_ACL_W BIT(1)
+#define GUNYAH_RM_ACL_R BIT(2)
+
+struct gunyah_rm_mem_acl_entry {
+	__le16 vmid;
+	u8 perms;
+	u8 reserved;
+} __packed;
+
+struct gunyah_rm_mem_entry {
+	__le64 phys_addr;
+	__le64 size;
+} __packed;
+
+enum gunyah_rm_mem_type {
+	GUNYAH_RM_MEM_TYPE_NORMAL = 0,
+	GUNYAH_RM_MEM_TYPE_IO = 1,
+};
+
+/*
+ * struct gunyah_rm_mem_parcel - Info about memory to be lent/shared/donated/reclaimed
+ * @mem_type: The type of memory: normal (DDR) or IO
+ * @label: An client-specified identifier which can be used by the other VMs to identify the purpose
+ *         of the memory parcel.
+ * @n_acl_entries: Count of the number of entries in the @acl_entries array.
+ * @acl_entries: An array of access control entries. Each entry specifies a VM and what access
+ *               is allowed for the memory parcel.
+ * @n_mem_entries: Count of the number of entries in the @mem_entries array.
+ * @mem_entries: An array of regions to be associated with the memory parcel. Addresses should be
+ *               (intermediate) physical addresses from Linux's perspective.
+ * @mem_handle: On success, filled with memory handle that RM allocates for this memory parcel
+ */
+struct gunyah_rm_mem_parcel {
+	enum gunyah_rm_mem_type mem_type;
+	u32 label;
+	size_t n_acl_entries;
+	struct gunyah_rm_mem_acl_entry *acl_entries;
+	size_t n_mem_entries;
+	struct gunyah_rm_mem_entry *mem_entries;
+	u32 mem_handle;
+};
+
+/* RPC Calls */
+int gunyah_rm_mem_share(struct gunyah_rm *rm,
+			struct gunyah_rm_mem_parcel *parcel);
+int gunyah_rm_mem_reclaim(struct gunyah_rm *rm,
+			  struct gunyah_rm_mem_parcel *parcel);
+
+int gunyah_rm_alloc_vmid(struct gunyah_rm *rm, u16 vmid);
+int gunyah_rm_dealloc_vmid(struct gunyah_rm *rm, u16 vmid);
+int gunyah_rm_vm_reset(struct gunyah_rm *rm, u16 vmid);
+int gunyah_rm_vm_start(struct gunyah_rm *rm, u16 vmid);
+int gunyah_rm_vm_stop(struct gunyah_rm *rm, u16 vmid);
+
+enum gunyah_rm_vm_auth_mechanism {
+	/* clang-format off */
+	GUNYAH_RM_VM_AUTH_NONE			= 0,
+	GUNYAH_RM_VM_AUTH_QCOM_PIL_ELF		= 1,
+	GUNYAH_RM_VM_AUTH_QCOM_ANDROID_PVM	= 2,
+	/* clang-format on */
+};
+
+int gunyah_rm_vm_configure(struct gunyah_rm *rm, u16 vmid,
+			   enum gunyah_rm_vm_auth_mechanism auth_mechanism,
+			   u32 mem_handle, u64 image_offset, u64 image_size,
+			   u64 dtb_offset, u64 dtb_size);
+int gunyah_rm_vm_init(struct gunyah_rm *rm, u16 vmid);
+int gunyah_rm_vm_set_boot_context(struct gunyah_rm *rm, u16 vmid, u8 reg_set,
+				  u8 reg_index, u64 value);
+
+struct gunyah_rm_hyp_resource {
+	u8 type;
+	u8 reserved;
+	__le16 partner_vmid;
+	__le32 resource_handle;
+	__le32 resource_label;
+	__le64 cap_id;
+	__le32 virq_handle;
+	__le32 virq;
+	__le64 base;
+	__le64 size;
+} __packed;
+
+struct gunyah_rm_hyp_resources {
+	__le32 n_entries;
+	struct gunyah_rm_hyp_resource entries[];
+} __packed;
+
+int gunyah_rm_get_hyp_resources(struct gunyah_rm *rm, u16 vmid,
+				struct gunyah_rm_hyp_resources **resources);
+int gunyah_rm_get_vmid(struct gunyah_rm *rm, u16 *vmid);
+
+int gunyah_rm_vm_set_demand_paging(struct gunyah_rm *rm, u16 vmid, u32 count,
+				   struct gunyah_rm_mem_entry *mem_entries);
+
+enum gunyah_rm_range_id {
+	GUNYAH_RM_RANGE_ID_IMAGE = 0,
+	GUNYAH_RM_RANGE_ID_FIRMWARE = 1,
+};
+
+int gunyah_rm_vm_set_address_layout(struct gunyah_rm *rm, u16 vmid,
+				    enum gunyah_rm_range_id range_id,
+				    u64 base_address, u64 size);
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:52 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:52 -0800
Subject: [PATCH RFC v15 11/30] gunyah: vm_mgr: Add framework for VM
 Functions
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-11-192a5d872a30@quicinc.com>

Introduce a framework for Gunyah userspace to install VM functions. VM
functions are optional interfaces to the virtual machine. vCPUs,
ioeventfs, and irqfds are examples of such VM functions and are
implemented in subsequent patches.

A generic framework is implemented instead of individual ioctls to
create vCPUs, irqfds, etc., in order to simplify the VM manager core
implementation and allow dynamic loading of VM function modules.

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/vm_mgr.c  | 217 +++++++++++++++++++++++++++++++++++++++++-
 drivers/virt/gunyah/vm_mgr.h  |   6 ++
 include/linux/gunyah_vm_mgr.h | 100 +++++++++++++++++++
 include/uapi/linux/gunyah.h   |  18 ++++
 4 files changed, 339 insertions(+), 2 deletions(-)

diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index 1b1b26f568af..81bc73047e1e 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -6,15 +6,185 @@
 #define pr_fmt(fmt) "gunyah_vm_mgr: " fmt
 
 #include <linux/anon_inodes.h>
+#include <linux/compat.h>
 #include <linux/file.h>
 #include <linux/gunyah_rsc_mgr.h>
+#include <linux/gunyah_vm_mgr.h>
 #include <linux/miscdevice.h>
 #include <linux/module.h>
+#include <linux/xarray.h>
 
 #include <uapi/linux/gunyah.h>
 
 #include "vm_mgr.h"
 
+static DEFINE_XARRAY(gunyah_vm_functions);
+
+static void gunyah_vm_put_function(struct gunyah_vm_function *fn)
+{
+	module_put(fn->mod);
+}
+
+static struct gunyah_vm_function *gunyah_vm_get_function(u32 type)
+{
+	struct gunyah_vm_function *fn;
+
+	fn = xa_load(&gunyah_vm_functions, type);
+	if (!fn) {
+		request_module("ghfunc:%d", type);
+
+		fn = xa_load(&gunyah_vm_functions, type);
+	}
+
+	if (!fn || !try_module_get(fn->mod))
+		fn = ERR_PTR(-ENOENT);
+
+	return fn;
+}
+
+static void
+gunyah_vm_remove_function_instance(struct gunyah_vm_function_instance *inst)
+	__must_hold(&inst->ghvm->fn_lock)
+{
+	inst->fn->unbind(inst);
+	list_del(&inst->vm_list);
+	gunyah_vm_put_function(inst->fn);
+	kfree(inst->argp);
+	kfree(inst);
+}
+
+static void gunyah_vm_remove_functions(struct gunyah_vm *ghvm)
+{
+	struct gunyah_vm_function_instance *inst, *iiter;
+
+	mutex_lock(&ghvm->fn_lock);
+	list_for_each_entry_safe(inst, iiter, &ghvm->functions, vm_list) {
+		gunyah_vm_remove_function_instance(inst);
+	}
+	mutex_unlock(&ghvm->fn_lock);
+}
+
+static long gunyah_vm_add_function_instance(struct gunyah_vm *ghvm,
+					    struct gunyah_fn_desc *f)
+{
+	struct gunyah_vm_function_instance *inst;
+	void __user *argp;
+	long r = 0;
+
+	if (f->arg_size > GUNYAH_FN_MAX_ARG_SIZE) {
+		dev_err_ratelimited(ghvm->parent, "%s: arg_size > %d\n",
+				    __func__, GUNYAH_FN_MAX_ARG_SIZE);
+		return -EINVAL;
+	}
+
+	inst = kzalloc(sizeof(*inst), GFP_KERNEL);
+	if (!inst)
+		return -ENOMEM;
+
+	inst->arg_size = f->arg_size;
+	if (inst->arg_size) {
+		inst->argp = kzalloc(inst->arg_size, GFP_KERNEL);
+		if (!inst->argp) {
+			r = -ENOMEM;
+			goto free;
+		}
+
+		argp = u64_to_user_ptr(f->arg);
+		if (copy_from_user(inst->argp, argp, f->arg_size)) {
+			r = -EFAULT;
+			goto free_arg;
+		}
+	}
+
+	inst->fn = gunyah_vm_get_function(f->type);
+	if (IS_ERR(inst->fn)) {
+		r = PTR_ERR(inst->fn);
+		goto free_arg;
+	}
+
+	inst->ghvm = ghvm;
+	inst->rm = ghvm->rm;
+
+	mutex_lock(&ghvm->fn_lock);
+	r = inst->fn->bind(inst);
+	if (r < 0) {
+		mutex_unlock(&ghvm->fn_lock);
+		gunyah_vm_put_function(inst->fn);
+		goto free_arg;
+	}
+
+	list_add(&inst->vm_list, &ghvm->functions);
+	mutex_unlock(&ghvm->fn_lock);
+
+	return r;
+free_arg:
+	kfree(inst->argp);
+free:
+	kfree(inst);
+	return r;
+}
+
+static long gunyah_vm_rm_function_instance(struct gunyah_vm *ghvm,
+					   struct gunyah_fn_desc *f)
+{
+	struct gunyah_vm_function_instance *inst, *iter;
+	void __user *user_argp;
+	void *argp;
+	long r = 0;
+
+	r = mutex_lock_interruptible(&ghvm->fn_lock);
+	if (r)
+		return r;
+
+	if (f->arg_size) {
+		argp = kzalloc(f->arg_size, GFP_KERNEL);
+		if (!argp) {
+			r = -ENOMEM;
+			goto out;
+		}
+
+		user_argp = u64_to_user_ptr(f->arg);
+		if (copy_from_user(argp, user_argp, f->arg_size)) {
+			r = -EFAULT;
+			kfree(argp);
+			goto out;
+		}
+
+		r = -ENOENT;
+		list_for_each_entry_safe(inst, iter, &ghvm->functions,
+					 vm_list) {
+			if (inst->fn->type == f->type &&
+			    inst->fn->compare(inst, argp, f->arg_size)) {
+				gunyah_vm_remove_function_instance(inst);
+				r = 0;
+			}
+		}
+
+		kfree(argp);
+	}
+
+out:
+	mutex_unlock(&ghvm->fn_lock);
+	return r;
+}
+
+int gunyah_vm_function_register(struct gunyah_vm_function *fn)
+{
+	if (!fn->bind || !fn->unbind)
+		return -EINVAL;
+
+	return xa_err(xa_store(&gunyah_vm_functions, fn->type, fn, GFP_KERNEL));
+}
+EXPORT_SYMBOL_GPL(gunyah_vm_function_register);
+
+void gunyah_vm_function_unregister(struct gunyah_vm_function *fn)
+{
+	/* Expecting unregister to only come when unloading a module */
+	WARN_ON(fn->mod && module_refcount(fn->mod));
+	xa_erase(&gunyah_vm_functions, fn->type);
+}
+EXPORT_SYMBOL_GPL(gunyah_vm_function_unregister);
+
 static int gunyah_vm_rm_notification_status(struct gunyah_vm *ghvm, void *data)
 {
 	struct gunyah_rm_vm_status_payload *payload = data;
@@ -91,7 +261,10 @@ static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 
 	init_rwsem(&ghvm->status_lock);
 	init_waitqueue_head(&ghvm->vm_status_wait);
+	kref_init(&ghvm->kref);
 	ghvm->vm_status = GUNYAH_RM_VM_STATUS_NO_STATE;
+	INIT_LIST_HEAD(&ghvm->functions);
+	mutex_init(&ghvm->fn_lock);
 
 	return ghvm;
 }
@@ -182,6 +355,7 @@ static long gunyah_vm_ioctl(struct file *filp, unsigned int cmd,
 			    unsigned long arg)
 {
 	struct gunyah_vm *ghvm = filp->private_data;
+	void __user *argp = (void __user *)arg;
 	long r;
 
 	switch (cmd) {
@@ -189,6 +363,24 @@ static long gunyah_vm_ioctl(struct file *filp, unsigned int cmd,
 		r = gunyah_vm_ensure_started(ghvm);
 		break;
 	}
+	case GUNYAH_VM_ADD_FUNCTION: {
+		struct gunyah_fn_desc f;
+
+		if (copy_from_user(&f, argp, sizeof(f)))
+			return -EFAULT;
+
+		r = gunyah_vm_add_function_instance(ghvm, &f);
+		break;
+	}
+	case GUNYAH_VM_REMOVE_FUNCTION: {
+		struct gunyah_fn_desc f;
+
+		if (copy_from_user(&f, argp, sizeof(f)))
+			return -EFAULT;
+
+		r = gunyah_vm_rm_function_instance(ghvm, &f);
+		break;
+	}
 	default:
 		r = -ENOTTY;
 		break;
@@ -197,14 +389,22 @@ static long gunyah_vm_ioctl(struct file *filp, unsigned int cmd,
 	return r;
 }
 
-static int gunyah_vm_release(struct inode *inode, struct file *filp)
+int __must_check gunyah_vm_get(struct gunyah_vm *ghvm)
 {
-	struct gunyah_vm *ghvm = filp->private_data;
+	return kref_get_unless_zero(&ghvm->kref);
+}
+EXPORT_SYMBOL_GPL(gunyah_vm_get);
+
+static void _gunyah_vm_put(struct kref *kref)
+{
+	struct gunyah_vm *ghvm = container_of(kref, struct gunyah_vm, kref);
 	int ret;
 
 	if (ghvm->vm_status == GUNYAH_RM_VM_STATUS_RUNNING)
 		gunyah_vm_stop(ghvm);
 
+	gunyah_vm_remove_functions(ghvm);
+
 	if (ghvm->vm_status != GUNYAH_RM_VM_STATUS_NO_STATE &&
 	    ghvm->vm_status != GUNYAH_RM_VM_STATUS_LOAD &&
 	    ghvm->vm_status != GUNYAH_RM_VM_STATUS_RESET) {
@@ -227,6 +427,19 @@ static int gunyah_vm_release(struct inode *inode, struct file *filp)
 
 	gunyah_rm_put(ghvm->rm);
 	kfree(ghvm);
+}
+
+void gunyah_vm_put(struct gunyah_vm *ghvm)
+{
+	kref_put(&ghvm->kref, _gunyah_vm_put);
+}
+EXPORT_SYMBOL_GPL(gunyah_vm_put);
+
+static int gunyah_vm_release(struct inode *inode, struct file *filp)
+{
+	struct gunyah_vm *ghvm = filp->private_data;
+
+	gunyah_vm_put(ghvm);
 	return 0;
 }
 
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index aa058722c5fe..a9e0eaf212fd 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -9,6 +9,8 @@
 #include <linux/device.h>
 #include <linux/gunyah_rsc_mgr.h>
 #include <linux/kref.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
 #include <linux/notifier.h>
 #include <linux/rwsem.h>
 #include <linux/wait.h>
@@ -28,6 +30,10 @@ struct gunyah_vm {
 	enum gunyah_rm_vm_status vm_status;
 	wait_queue_head_t vm_status_wait;
 	struct rw_semaphore status_lock;
+
+	struct kref kref;
+	struct mutex fn_lock;
+	struct list_head functions;
 };
 
 #endif
diff --git a/include/linux/gunyah_vm_mgr.h b/include/linux/gunyah_vm_mgr.h
new file mode 100644
index 000000000000..f40e57f32fd8
--- /dev/null
+++ b/include/linux/gunyah_vm_mgr.h
@@ -0,0 +1,100 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _GUNYAH_VM_MGR_H
+#define _GUNYAH_VM_MGR_H
+
+#include <linux/compiler_types.h>
+#include <linux/gunyah.h>
+#include <linux/gunyah_rsc_mgr.h>
+#include <linux/list.h>
+#include <linux/mod_devicetable.h>
+#include <linux/notifier.h>
+
+#include <uapi/linux/gunyah.h>
+
+struct gunyah_vm;
+
+int __must_check gunyah_vm_get(struct gunyah_vm *ghvm);
+void gunyah_vm_put(struct gunyah_vm *ghvm);
+
+struct gunyah_vm_function_instance;
+/**
+ * struct gunyah_vm_function - Represents a function type
+ * @type: value from &enum gunyah_fn_type
+ * @name: friendly name for debug purposes
+ * @mod: owner of the function type
+ * @bind: Called when a new function of this type has been allocated.
+ * @unbind: Called when the function instance is being destroyed.
+ * @compare: Compare function instance @f's argument to the provided arg.
+ *           Return true if they are equivalent. Used on GUNYAH_VM_REMOVE_FUNCTION.
+ */
+struct gunyah_vm_function {
+	u32 type;
+	const char *name;
+	struct module *mod;
+	long (*bind)(struct gunyah_vm_function_instance *f);
+	void (*unbind)(struct gunyah_vm_function_instance *f);
+	bool (*compare)(const struct gunyah_vm_function_instance *f,
+			const void *arg, size_t size);
+};
+
+/**
+ * struct gunyah_vm_function_instance - Represents one function instance
+ * @arg_size: size of user argument
+ * @argp: pointer to user argument
+ * @ghvm: Pointer to VM instance
+ * @rm: Pointer to resource manager for the VM instance
+ * @fn: The ops for the function
+ * @data: Private data for function
+ * @vm_list: for gunyah_vm's functions list
+ * @fn_list: for gunyah_vm_function's instances list
+ */
+struct gunyah_vm_function_instance {
+	size_t arg_size;
+	void *argp;
+	struct gunyah_vm *ghvm;
+	struct gunyah_rm *rm;
+	struct gunyah_vm_function *fn;
+	void *data;
+	struct list_head vm_list;
+};
+
+int gunyah_vm_function_register(struct gunyah_vm_function *f);
+void gunyah_vm_function_unregister(struct gunyah_vm_function *f);
+
+/* Since the function identifiers were setup in a uapi header as an
+ * enum and we do no want to change that, the user must supply the expanded
+ * constant as well and the compiler checks they are the same.
+ * See also MODULE_ALIAS_RDMA_NETLINK.
+ */
+#define MODULE_ALIAS_GUNYAH_VM_FUNCTION(_type, _idx)        \
+	static inline void __maybe_unused __chk##_idx(void) \
+	{                                                   \
+		BUILD_BUG_ON(_type != _idx);                \
+	}                                                   \
+	MODULE_ALIAS("ghfunc:" __stringify(_idx))
+
+#define DECLARE_GUNYAH_VM_FUNCTION(_name, _type, _bind, _unbind, _compare) \
+	static struct gunyah_vm_function _name = {                         \
+		.type = _type,                                             \
+		.name = __stringify(_name),                                \
+		.mod = THIS_MODULE,                                        \
+		.bind = _bind,                                             \
+		.unbind = _unbind,                                         \
+		.compare = _compare,                                       \
+	}
+
+#define module_gunyah_vm_function(__gf)                  \
+	module_driver(__gf, gunyah_vm_function_register, \
+		      gunyah_vm_function_unregister)
+
+#define DECLARE_GUNYAH_VM_FUNCTION_INIT(_name, _type, _idx, _bind, _unbind, \
+					_compare)                           \
+	DECLARE_GUNYAH_VM_FUNCTION(_name, _type, _bind, _unbind, _compare); \
+	module_gunyah_vm_function(_name);                                   \
+	MODULE_ALIAS_GUNYAH_VM_FUNCTION(_type, _idx)
+
+#endif
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
index 31e7f79a6c39..1b7cb5fde70a 100644
--- a/include/uapi/linux/gunyah.h
+++ b/include/uapi/linux/gunyah.h
@@ -25,4 +25,22 @@
  */
 #define GUNYAH_VM_START		_IO(GUNYAH_IOCTL_TYPE, 0x3)
 
+#define GUNYAH_FN_MAX_ARG_SIZE		256
+
+/**
+ * struct gunyah_fn_desc - Arguments to create a VM function
+ * @type: Type of the function. See &enum gunyah_fn_type.
+ * @arg_size: Size of argument to pass to the function. arg_size <= GUNYAH_FN_MAX_ARG_SIZE
+ * @arg: Pointer to argument given to the function. See &enum gunyah_fn_type for expected
+ *       arguments for a function type.
+ */
+struct gunyah_fn_desc {
+	__u32 type;
+	__u32 arg_size;
+	__u64 arg;
+};
+
+#define GUNYAH_VM_ADD_FUNCTION	_IOW(GUNYAH_IOCTL_TYPE, 0x4, struct gunyah_fn_desc)
+#define GUNYAH_VM_REMOVE_FUNCTION	_IOW(GUNYAH_IOCTL_TYPE, 0x7, struct gunyah_fn_desc)
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:48 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:48 -0800
Subject: [PATCH RFC v15 07/30] gunyah: rsc_mgr: Add resource manager RPC
 core
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-7-192a5d872a30@quicinc.com>

The resource manager is a special virtual machine which is always
running on a Gunyah system. It provides APIs for creating and destroying
VMs, secure memory management, sharing/lending of memory between VMs,
and setup of inter-VM communication. Calls to the resource manager are
made via message queues.

This patch implements the basic probing and RPC mechanism to make those
API calls. Request/response calls can be made with gh_rm_call.
Drivers can also register to notifications pushed by RM via
gh_rm_register_notifier

Specific API calls that resource manager supports will be implemented in
subsequent patches.

Reviewed-by: Alex Elder <elder at linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/Makefile   |   4 +-
 drivers/virt/gunyah/rsc_mgr.c  | 725 +++++++++++++++++++++++++++++++++++++++++
 drivers/virt/gunyah/rsc_mgr.h  |  18 +
 include/linux/gunyah_rsc_mgr.h |  22 ++
 4 files changed, 768 insertions(+), 1 deletion(-)

diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index 34f32110faf9..c2308389f551 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -1,3 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_GUNYAH) += gunyah.o
+gunyah_rsc_mgr-y += rsc_mgr.o
+
+obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o
diff --git a/drivers/virt/gunyah/rsc_mgr.c b/drivers/virt/gunyah/rsc_mgr.c
new file mode 100644
index 000000000000..2f9afe167aa6
--- /dev/null
+++ b/drivers/virt/gunyah/rsc_mgr.c
@@ -0,0 +1,725 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/of.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/sched.h>
+#include <linux/gunyah.h>
+#include <linux/module.h>
+#include <linux/of_irq.h>
+#include <linux/notifier.h>
+#include <linux/workqueue.h>
+#include <linux/completion.h>
+#include <linux/gunyah_rsc_mgr.h>
+#include <linux/platform_device.h>
+
+#include "rsc_mgr.h"
+
+/* clang-format off */
+#define RM_RPC_API_VERSION_MASK		GENMASK(3, 0)
+#define RM_RPC_HEADER_WORDS_MASK	GENMASK(7, 4)
+#define RM_RPC_API_VERSION		FIELD_PREP(RM_RPC_API_VERSION_MASK, 1)
+#define RM_RPC_HEADER_WORDS		FIELD_PREP(RM_RPC_HEADER_WORDS_MASK, \
+						(sizeof(struct gunyah_rm_rpc_hdr) / sizeof(u32)))
+#define RM_RPC_API			(RM_RPC_API_VERSION | RM_RPC_HEADER_WORDS)
+
+#define RM_RPC_TYPE_CONTINUATION	0x0
+#define RM_RPC_TYPE_REQUEST		0x1
+#define RM_RPC_TYPE_REPLY		0x2
+#define RM_RPC_TYPE_NOTIF		0x3
+#define RM_RPC_TYPE_MASK		GENMASK(1, 0)
+
+#define GUNYAH_RM_MAX_NUM_FRAGMENTS		62
+#define RM_RPC_FRAGMENTS_MASK		GENMASK(7, 2)
+/* clang-format on */
+
+struct gunyah_rm_rpc_hdr {
+	u8 api;
+	u8 type;
+	__le16 seq;
+	__le32 msg_id;
+} __packed;
+
+struct gunyah_rm_rpc_reply_hdr {
+	struct gunyah_rm_rpc_hdr hdr;
+	__le32 err_code; /* GUNYAH_RM_ERROR_* */
+} __packed;
+
+#define GUNYAH_RM_MSGQ_MSG_SIZE 240
+#define GUNYAH_RM_PAYLOAD_SIZE \
+	(GUNYAH_RM_MSGQ_MSG_SIZE - sizeof(struct gunyah_rm_rpc_hdr))
+
+/* RM Error codes */
+enum gunyah_rm_error {
+	/* clang-format off */
+	GUNYAH_RM_ERROR_OK			= 0x0,
+	GUNYAH_RM_ERROR_UNIMPLEMENTED	= 0xFFFFFFFF,
+	GUNYAH_RM_ERROR_NOMEM		= 0x1,
+	GUNYAH_RM_ERROR_NORESOURCE		= 0x2,
+	GUNYAH_RM_ERROR_DENIED		= 0x3,
+	GUNYAH_RM_ERROR_INVALID		= 0x4,
+	GUNYAH_RM_ERROR_BUSY		= 0x5,
+	GUNYAH_RM_ERROR_ARGUMENT_INVALID	= 0x6,
+	GUNYAH_RM_ERROR_HANDLE_INVALID	= 0x7,
+	GUNYAH_RM_ERROR_VALIDATE_FAILED	= 0x8,
+	GUNYAH_RM_ERROR_MAP_FAILED		= 0x9,
+	GUNYAH_RM_ERROR_MEM_INVALID		= 0xA,
+	GUNYAH_RM_ERROR_MEM_INUSE		= 0xB,
+	GUNYAH_RM_ERROR_MEM_RELEASED	= 0xC,
+	GUNYAH_RM_ERROR_VMID_INVALID	= 0xD,
+	GUNYAH_RM_ERROR_LOOKUP_FAILED	= 0xE,
+	GUNYAH_RM_ERROR_IRQ_INVALID		= 0xF,
+	GUNYAH_RM_ERROR_IRQ_INUSE		= 0x10,
+	GUNYAH_RM_ERROR_IRQ_RELEASED	= 0x11,
+	/* clang-format on */
+};
+
+/**
+ * struct gunyah_rm_message - Represents a complete message from resource manager
+ * @payload: Combined payload of all the fragments (msg headers stripped off).
+ * @size: Size of the payload received so far.
+ * @msg_id: Message ID from the header.
+ * @type: RM_RPC_TYPE_REPLY or RM_RPC_TYPE_NOTIF.
+ * @num_fragments: total number of fragments expected to be received.
+ * @fragments_received: fragments received so far.
+ * @reply: Fields used for request/reply sequences
+ */
+struct gunyah_rm_message {
+	void *payload;
+	size_t size;
+	u32 msg_id;
+	u8 type;
+
+	u8 num_fragments;
+	u8 fragments_received;
+
+	/**
+	 * @ret: Linux return code, there was an error processing message
+	 * @seq: Sequence ID for the main message.
+	 * @rm_error: For request/reply sequences with standard replies
+	 * @seq_done: Signals caller that the RM reply has been received
+	 */
+	struct {
+		int ret;
+		u16 seq;
+		enum gunyah_rm_error rm_error;
+		struct completion seq_done;
+	} reply;
+};
+
+/**
+ * struct gunyah_rm - private data for communicating w/Gunyah resource manager
+ * @dev: pointer to RM platform device
+ * @tx_ghrsc: message queue resource to TX to RM
+ * @rx_ghrsc: message queue resource to RX from RM
+ * @msgq: mailbox instance of TX/RX resources above
+ * @msgq_client: mailbox client of above msgq
+ * @active_rx_message: ongoing gunyah_rm_message for which we're receiving fragments
+ * @last_tx_ret: return value of last mailbox tx
+ * @call_xarray: xarray to allocate & lookup sequence IDs for Request/Response flows
+ * @next_seq: next ID to allocate (for xa_alloc_cyclic)
+ * @recv_msg: cached allocation for Rx messages
+ * @send_msg: cached allocation for Tx messages
+ * @send_lock: synchronization to allow only one request to be sent at a time
+ * @send_ready: completion to send messages again
+ * @nh: notifier chain for clients interested in RM notification messages
+ */
+struct gunyah_rm {
+	struct device *dev;
+	struct gunyah_resource tx_ghrsc;
+	struct gunyah_resource rx_ghrsc;
+	struct gunyah_rm_message *active_rx_message;
+	int last_tx_ret;
+
+	struct xarray call_xarray;
+	u32 next_seq;
+
+	unsigned char recv_msg[GUNYAH_RM_MSGQ_MSG_SIZE];
+	unsigned char send_msg[GUNYAH_RM_MSGQ_MSG_SIZE];
+	struct mutex send_lock;
+	struct completion send_ready;
+	struct blocking_notifier_head nh;
+};
+
+/**
+ * gunyah_rm_error_remap() - Remap Gunyah resource manager errors into a Linux error code
+ * @rm_error: "Standard" return value from Gunyah resource manager
+ */
+static inline int gunyah_rm_error_remap(enum gunyah_rm_error rm_error)
+{
+	switch (rm_error) {
+	case GUNYAH_RM_ERROR_OK:
+		return 0;
+	case GUNYAH_RM_ERROR_UNIMPLEMENTED:
+		return -EOPNOTSUPP;
+	case GUNYAH_RM_ERROR_NOMEM:
+		return -ENOMEM;
+	case GUNYAH_RM_ERROR_NORESOURCE:
+		return -ENODEV;
+	case GUNYAH_RM_ERROR_DENIED:
+		return -EPERM;
+	case GUNYAH_RM_ERROR_BUSY:
+		return -EBUSY;
+	case GUNYAH_RM_ERROR_INVALID:
+	case GUNYAH_RM_ERROR_ARGUMENT_INVALID:
+	case GUNYAH_RM_ERROR_HANDLE_INVALID:
+	case GUNYAH_RM_ERROR_VALIDATE_FAILED:
+	case GUNYAH_RM_ERROR_MAP_FAILED:
+	case GUNYAH_RM_ERROR_MEM_INVALID:
+	case GUNYAH_RM_ERROR_MEM_INUSE:
+	case GUNYAH_RM_ERROR_MEM_RELEASED:
+	case GUNYAH_RM_ERROR_VMID_INVALID:
+	case GUNYAH_RM_ERROR_LOOKUP_FAILED:
+	case GUNYAH_RM_ERROR_IRQ_INVALID:
+	case GUNYAH_RM_ERROR_IRQ_INUSE:
+	case GUNYAH_RM_ERROR_IRQ_RELEASED:
+		return -EINVAL;
+	default:
+		return -EBADMSG;
+	}
+}
+
+static int gunyah_rm_init_message_payload(struct gunyah_rm_message *message,
+					  const void *msg, size_t hdr_size,
+					  size_t msg_size)
+{
+	const struct gunyah_rm_rpc_hdr *hdr = msg;
+	size_t max_buf_size, payload_size;
+
+	if (msg_size < hdr_size)
+		return -EINVAL;
+
+	payload_size = msg_size - hdr_size;
+
+	message->num_fragments = FIELD_GET(RM_RPC_FRAGMENTS_MASK, hdr->type);
+	message->fragments_received = 0;
+
+	/* There's not going to be any payload, no need to allocate buffer. */
+	if (!payload_size && !message->num_fragments)
+		return 0;
+
+	if (message->num_fragments > GUNYAH_RM_MAX_NUM_FRAGMENTS)
+		return -EINVAL;
+
+	max_buf_size = payload_size +
+		       (message->num_fragments * GUNYAH_RM_PAYLOAD_SIZE);
+
+	message->payload = kzalloc(max_buf_size, GFP_KERNEL);
+	if (!message->payload)
+		return -ENOMEM;
+
+	memcpy(message->payload, msg + hdr_size, payload_size);
+	message->size = payload_size;
+	return 0;
+}
+
+static void gunyah_rm_abort_message(struct gunyah_rm *rm)
+{
+	switch (rm->active_rx_message->type) {
+	case RM_RPC_TYPE_REPLY:
+		rm->active_rx_message->reply.ret = -EIO;
+		complete(&rm->active_rx_message->reply.seq_done);
+		break;
+	case RM_RPC_TYPE_NOTIF:
+		fallthrough;
+	default:
+		kfree(rm->active_rx_message->payload);
+		kfree(rm->active_rx_message);
+	}
+
+	rm->active_rx_message = NULL;
+}
+
+static inline void gunyah_rm_try_complete_message(struct gunyah_rm *rm)
+{
+	struct gunyah_rm_message *message = rm->active_rx_message;
+
+	if (!message || message->fragments_received != message->num_fragments)
+		return;
+
+	switch (message->type) {
+	case RM_RPC_TYPE_REPLY:
+		complete(&message->reply.seq_done);
+		break;
+	case RM_RPC_TYPE_NOTIF:
+		blocking_notifier_call_chain(&rm->nh, message->msg_id,
+					     message->payload);
+
+		kfree(message->payload);
+		kfree(message);
+		break;
+	default:
+		dev_err_ratelimited(rm->dev,
+				    "Invalid message type (%u) received\n",
+				    message->type);
+		gunyah_rm_abort_message(rm);
+		break;
+	}
+
+	rm->active_rx_message = NULL;
+}
+
+static void gunyah_rm_process_notif(struct gunyah_rm *rm, const void *msg,
+				    size_t msg_size)
+{
+	const struct gunyah_rm_rpc_hdr *hdr = msg;
+	struct gunyah_rm_message *message;
+	int ret;
+
+	if (rm->active_rx_message)
+		gunyah_rm_abort_message(rm);
+
+	message = kzalloc(sizeof(*message), GFP_KERNEL);
+	if (!message)
+		return;
+
+	message->type = RM_RPC_TYPE_NOTIF;
+	message->msg_id = le32_to_cpu(hdr->msg_id);
+
+	ret = gunyah_rm_init_message_payload(message, msg, sizeof(*hdr),
+					     msg_size);
+	if (ret) {
+		dev_err(rm->dev,
+			"Failed to initialize message for notification: %d\n",
+			ret);
+		kfree(message);
+		return;
+	}
+
+	rm->active_rx_message = message;
+
+	gunyah_rm_try_complete_message(rm);
+}
+
+static void gunyah_rm_process_reply(struct gunyah_rm *rm, const void *msg,
+				    size_t msg_size)
+{
+	const struct gunyah_rm_rpc_reply_hdr *reply_hdr = msg;
+	struct gunyah_rm_message *message;
+	u16 seq_id;
+
+	seq_id = le16_to_cpu(reply_hdr->hdr.seq);
+	message = xa_load(&rm->call_xarray, seq_id);
+
+	if (!message || message->msg_id != le32_to_cpu(reply_hdr->hdr.msg_id))
+		return;
+
+	if (rm->active_rx_message)
+		gunyah_rm_abort_message(rm);
+
+	if (gunyah_rm_init_message_payload(message, msg, sizeof(*reply_hdr),
+					   msg_size)) {
+		dev_err(rm->dev,
+			"Failed to alloc message buffer for sequence %d\n",
+			seq_id);
+		/* Send message complete and error the client. */
+		message->reply.ret = -ENOMEM;
+		complete(&message->reply.seq_done);
+		return;
+	}
+
+	message->reply.rm_error = le32_to_cpu(reply_hdr->err_code);
+	rm->active_rx_message = message;
+
+	gunyah_rm_try_complete_message(rm);
+}
+
+static void gunyah_rm_process_cont(struct gunyah_rm *rm,
+				   struct gunyah_rm_message *message,
+				   const void *msg, size_t msg_size)
+{
+	const struct gunyah_rm_rpc_hdr *hdr = msg;
+	size_t payload_size = msg_size - sizeof(*hdr);
+
+	if (!rm->active_rx_message)
+		return;
+
+	/*
+	 * hdr->fragments and hdr->msg_id preserves the value from first reply
+	 * or notif message. To detect mishandling, check it's still intact.
+	 */
+	if (message->msg_id != le32_to_cpu(hdr->msg_id) ||
+	    message->num_fragments !=
+		    FIELD_GET(RM_RPC_FRAGMENTS_MASK, hdr->type)) {
+		gunyah_rm_abort_message(rm);
+		return;
+	}
+
+	memcpy(message->payload + message->size, msg + sizeof(*hdr),
+	       payload_size);
+	message->size += payload_size;
+	message->fragments_received++;
+
+	gunyah_rm_try_complete_message(rm);
+}
+
+static irqreturn_t gunyah_rm_rx(int irq, void *data)
+{
+	enum gunyah_error gunyah_error;
+	struct gunyah_rm_rpc_hdr *hdr;
+	struct gunyah_rm *rm = data;
+	void *msg = &rm->recv_msg[0];
+	size_t len;
+	bool ready;
+
+	do {
+		gunyah_error = gunyah_hypercall_msgq_recv(rm->rx_ghrsc.capid,
+							  msg,
+							  sizeof(rm->recv_msg),
+							  &len, &ready);
+		if (gunyah_error != GUNYAH_ERROR_OK) {
+			if (gunyah_error != GUNYAH_ERROR_MSGQUEUE_EMPTY)
+				dev_warn(rm->dev,
+					 "Failed to receive data: %d\n",
+					 gunyah_error);
+			return IRQ_HANDLED;
+		}
+
+		if (len < sizeof(*hdr)) {
+			dev_err_ratelimited(
+				rm->dev,
+				"Too small message received. size=%ld\n", len);
+			continue;
+		}
+
+		hdr = msg;
+		if (hdr->api != RM_RPC_API) {
+			dev_err(rm->dev, "Unknown RM RPC API version: %x\n",
+				hdr->api);
+			return IRQ_HANDLED;
+		}
+
+		switch (FIELD_GET(RM_RPC_TYPE_MASK, hdr->type)) {
+		case RM_RPC_TYPE_NOTIF:
+			gunyah_rm_process_notif(rm, msg, len);
+			break;
+		case RM_RPC_TYPE_REPLY:
+			gunyah_rm_process_reply(rm, msg, len);
+			break;
+		case RM_RPC_TYPE_CONTINUATION:
+			gunyah_rm_process_cont(rm, rm->active_rx_message, msg,
+					       len);
+			break;
+		default:
+			dev_err(rm->dev,
+				"Invalid message type (%lu) received\n",
+				FIELD_GET(RM_RPC_TYPE_MASK, hdr->type));
+			return IRQ_HANDLED;
+		}
+	} while (ready);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t gunyah_rm_tx(int irq, void *data)
+{
+	struct gunyah_rm *rm = data;
+
+	complete_all(&rm->send_ready);
+
+	return IRQ_HANDLED;
+}
+
+static int gunyah_rm_msgq_send(struct gunyah_rm *rm, size_t size, bool push)
+	__must_hold(&rm->send_lock)
+{
+	const u64 tx_flags = push ? GUNYAH_HYPERCALL_MSGQ_TX_FLAGS_PUSH : 0;
+	enum gunyah_error gunyah_error;
+	void *data = &rm->send_msg[0];
+	bool ready;
+
+again:
+	wait_for_completion(&rm->send_ready);
+	/* reinit completion before hypercall. As soon as hypercall returns, we could get the
+	 * ready interrupt. This might be before we have time to reinit the completion
+	 */
+	reinit_completion(&rm->send_ready);
+	gunyah_error = gunyah_hypercall_msgq_send(rm->tx_ghrsc.capid, size,
+						  data, tx_flags, &ready);
+
+	/* Should never happen because Linux properly tracks the ready-state of the msgq */
+	if (WARN_ON(gunyah_error == GUNYAH_ERROR_MSGQUEUE_FULL))
+		goto again;
+
+	if (ready)
+		complete_all(&rm->send_ready);
+
+	return gunyah_error_remap(gunyah_error);
+}
+
+static int gunyah_rm_send_request(struct gunyah_rm *rm, u32 message_id,
+				  const void *req_buf, size_t req_buf_size,
+				  struct gunyah_rm_message *message)
+{
+	size_t buf_size_remaining = req_buf_size;
+	const void *req_buf_curr = req_buf;
+	struct gunyah_rm_rpc_hdr *hdr =
+		(struct gunyah_rm_rpc_hdr *)&rm->send_msg[0];
+	struct gunyah_rm_rpc_hdr hdr_template;
+	void *payload = hdr + 1;
+	u32 cont_fragments = 0;
+	size_t payload_size;
+	int ret;
+
+	if (req_buf_size >
+	    GUNYAH_RM_MAX_NUM_FRAGMENTS * GUNYAH_RM_PAYLOAD_SIZE) {
+		dev_warn(
+			rm->dev,
+			"Limit (%lu bytes) exceeded for the maximum message size: %lu\n",
+			GUNYAH_RM_MAX_NUM_FRAGMENTS * GUNYAH_RM_PAYLOAD_SIZE,
+			req_buf_size);
+		dump_stack();
+		return -E2BIG;
+	}
+
+	if (req_buf_size)
+		cont_fragments = (req_buf_size - 1) / GUNYAH_RM_PAYLOAD_SIZE;
+
+	hdr_template.api = RM_RPC_API;
+	hdr_template.type = FIELD_PREP(RM_RPC_TYPE_MASK, RM_RPC_TYPE_REQUEST) |
+			    FIELD_PREP(RM_RPC_FRAGMENTS_MASK, cont_fragments);
+	hdr_template.seq = cpu_to_le16(message->reply.seq);
+	hdr_template.msg_id = cpu_to_le32(message_id);
+
+	ret = mutex_lock_interruptible(&rm->send_lock);
+	if (ret)
+		return ret;
+
+	do {
+		*hdr = hdr_template;
+
+		/* Copy payload */
+		payload_size = min(buf_size_remaining, GUNYAH_RM_PAYLOAD_SIZE);
+		memcpy(payload, req_buf_curr, payload_size);
+		req_buf_curr += payload_size;
+		buf_size_remaining -= payload_size;
+
+		/* Force the last fragment to immediately alert the receiver */
+		ret = gunyah_rm_msgq_send(rm, sizeof(*hdr) + payload_size,
+					  !buf_size_remaining);
+		if (ret)
+			break;
+
+		hdr_template.type =
+			FIELD_PREP(RM_RPC_TYPE_MASK, RM_RPC_TYPE_CONTINUATION) |
+			FIELD_PREP(RM_RPC_FRAGMENTS_MASK, cont_fragments);
+	} while (buf_size_remaining);
+
+	mutex_unlock(&rm->send_lock);
+	return ret;
+}
+
+/**
+ * gunyah_rm_call: Achieve request-response type communication with RPC
+ * @rm: Pointer to Gunyah resource manager internal data
+ * @message_id: The RM RPC message-id
+ * @req_buf: Request buffer that contains the payload
+ * @req_buf_size: Total size of the payload
+ * @resp_buf: Pointer to a response buffer
+ * @resp_buf_size: Size of the response buffer
+ *
+ * Make a request to the Resource Manager and wait for reply back. For a successful
+ * response, the function returns the payload. The size of the payload is set in
+ * resp_buf_size. The resp_buf must be freed by the caller when 0 is returned
+ * and resp_buf_size != 0.
+ *
+ * req_buf should be not NULL for req_buf_size >0. If req_buf_size == 0,
+ * req_buf *can* be NULL and no additional payload is sent.
+ *
+ * Context: Process context. Will sleep waiting for reply.
+ * Return: 0 on success. <0 if error.
+ */
+int gunyah_rm_call(struct gunyah_rm *rm, u32 message_id, const void *req_buf,
+		   size_t req_buf_size, void **resp_buf, size_t *resp_buf_size)
+{
+	struct gunyah_rm_message message = { 0 };
+	u32 seq_id;
+	int ret;
+
+	/* message_id 0 is reserved. req_buf_size implies req_buf is not NULL */
+	if (!rm || !message_id || (!req_buf && req_buf_size))
+		return -EINVAL;
+
+	message.type = RM_RPC_TYPE_REPLY;
+	message.msg_id = message_id;
+
+	message.reply.seq_done =
+		COMPLETION_INITIALIZER_ONSTACK(message.reply.seq_done);
+
+	/* Allocate a new seq number for this message */
+	ret = xa_alloc_cyclic(&rm->call_xarray, &seq_id, &message, xa_limit_16b,
+			      &rm->next_seq, GFP_KERNEL);
+	if (ret < 0)
+		return ret;
+	message.reply.seq = lower_16_bits(seq_id);
+
+	/* Send the request to the Resource Manager */
+	ret = gunyah_rm_send_request(rm, message_id, req_buf, req_buf_size,
+				     &message);
+	if (ret < 0) {
+		dev_warn(rm->dev, "Failed to send request. Error: %d\n", ret);
+		goto out;
+	}
+
+	/*
+	 * Wait for response. Uninterruptible because rollback based on what RM did to VM
+	 * requires us to know how RM handled the call.
+	 */
+	wait_for_completion(&message.reply.seq_done);
+
+	/* Check for internal (kernel) error waiting for the response */
+	if (message.reply.ret) {
+		ret = message.reply.ret;
+		if (ret != -ENOMEM)
+			kfree(message.payload);
+		goto out;
+	}
+
+	/* Got a response, did resource manager give us an error? */
+	if (message.reply.rm_error != GUNYAH_RM_ERROR_OK) {
+		dev_warn(rm->dev, "RM rejected message %08x. Error: %d\n",
+			 message_id, message.reply.rm_error);
+		ret = gunyah_rm_error_remap(message.reply.rm_error);
+		kfree(message.payload);
+		goto out;
+	}
+
+	/* Everything looks good, return the payload */
+	if (resp_buf_size)
+		*resp_buf_size = message.size;
+
+	if (message.size && resp_buf) {
+		*resp_buf = message.payload;
+	} else {
+		/* kfree in case RM sent us multiple fragments but never any data in
+		 * those fragments. We would've allocated memory for it, but message.size == 0
+		 */
+		kfree(message.payload);
+	}
+
+out:
+	xa_erase(&rm->call_xarray, message.reply.seq);
+	return ret;
+}
+
+int gunyah_rm_notifier_register(struct gunyah_rm *rm, struct notifier_block *nb)
+{
+	return blocking_notifier_chain_register(&rm->nh, nb);
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_notifier_register);
+
+int gunyah_rm_notifier_unregister(struct gunyah_rm *rm,
+				  struct notifier_block *nb)
+{
+	return blocking_notifier_chain_unregister(&rm->nh, nb);
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_notifier_unregister);
+
+static int gunyah_platform_probe_capability(struct platform_device *pdev,
+					    int idx,
+					    struct gunyah_resource *ghrsc)
+{
+	int ret;
+
+	ghrsc->irq = platform_get_irq(pdev, idx);
+	if (ghrsc->irq < 0) {
+		dev_err(&pdev->dev, "Failed to get %s irq: %d\n",
+			idx ? "rx" : "tx", ghrsc->irq);
+		return ghrsc->irq;
+	}
+
+	ret = of_property_read_u64_index(pdev->dev.of_node, "reg", idx,
+					 &ghrsc->capid);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to get %s capid: %d\n",
+			idx ? "rx" : "tx", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int gunyah_rm_probe_tx_msgq(struct gunyah_rm *rm,
+				   struct platform_device *pdev)
+{
+	int ret;
+
+	rm->tx_ghrsc.type = GUNYAH_RESOURCE_TYPE_MSGQ_TX;
+	ret = gunyah_platform_probe_capability(pdev, 0, &rm->tx_ghrsc);
+	if (ret)
+		return ret;
+
+	enable_irq_wake(rm->tx_ghrsc.irq);
+
+	return devm_request_threaded_irq(rm->dev, rm->tx_ghrsc.irq, NULL,
+					 gunyah_rm_tx, IRQF_ONESHOT,
+					 "gunyah_rm_tx", rm);
+}
+
+static int gunyah_rm_probe_rx_msgq(struct gunyah_rm *rm,
+				   struct platform_device *pdev)
+{
+	int ret;
+
+	rm->rx_ghrsc.type = GUNYAH_RESOURCE_TYPE_MSGQ_RX;
+	ret = gunyah_platform_probe_capability(pdev, 1, &rm->rx_ghrsc);
+	if (ret)
+		return ret;
+
+	enable_irq_wake(rm->rx_ghrsc.irq);
+
+	return devm_request_threaded_irq(rm->dev, rm->rx_ghrsc.irq, NULL,
+					 gunyah_rm_rx, IRQF_ONESHOT,
+					 "gunyah_rm_rx", rm);
+}
+
+static int gunyah_rm_probe(struct platform_device *pdev)
+{
+	struct gunyah_rm *rm;
+	int ret;
+
+	rm = devm_kzalloc(&pdev->dev, sizeof(*rm), GFP_KERNEL);
+	if (!rm)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, rm);
+	rm->dev = &pdev->dev;
+
+	mutex_init(&rm->send_lock);
+	init_completion(&rm->send_ready);
+	BLOCKING_INIT_NOTIFIER_HEAD(&rm->nh);
+	xa_init_flags(&rm->call_xarray, XA_FLAGS_ALLOC);
+
+	ret = gunyah_rm_probe_tx_msgq(rm, pdev);
+	if (ret)
+		return ret;
+	/* assume RM is ready to receive messages from us */
+	complete_all(&rm->send_ready);
+
+	ret = gunyah_rm_probe_rx_msgq(rm, pdev);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static const struct of_device_id gunyah_rm_of_match[] = {
+	{ .compatible = "gunyah-resource-manager" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, gunyah_rm_of_match);
+
+static struct platform_driver gunyah_rm_driver = {
+	.probe = gunyah_rm_probe,
+	.driver = {
+		.name = "gunyah_rsc_mgr",
+		.of_match_table = gunyah_rm_of_match,
+	},
+};
+module_platform_driver(gunyah_rm_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Gunyah Resource Manager Driver");
diff --git a/drivers/virt/gunyah/rsc_mgr.h b/drivers/virt/gunyah/rsc_mgr.h
new file mode 100644
index 000000000000..4ce6ec3668d4
--- /dev/null
+++ b/drivers/virt/gunyah/rsc_mgr.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+#ifndef __GUNYAH_RSC_MGR_PRIV_H
+#define __GUNYAH_RSC_MGR_PRIV_H
+
+#include <linux/gunyah.h>
+#include <linux/gunyah_rsc_mgr.h>
+#include <linux/types.h>
+
+struct gunyah_rm;
+
+int gunyah_rm_call(struct gunyah_rm *rsc_mgr, u32 message_id,
+		   const void *req_buf, size_t req_buf_size, void **resp_buf,
+		   size_t *resp_buf_size);
+
+#endif
diff --git a/include/linux/gunyah_rsc_mgr.h b/include/linux/gunyah_rsc_mgr.h
new file mode 100644
index 000000000000..e151f66be96e
--- /dev/null
+++ b/include/linux/gunyah_rsc_mgr.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _GUNYAH_RSC_MGR_H
+#define _GUNYAH_RSC_MGR_H
+
+#include <linux/notifier.h>
+#include <linux/gunyah.h>
+
+#define GUNYAH_VMID_INVAL U16_MAX
+
+struct gunyah_rm;
+int gunyah_rm_notifier_register(struct gunyah_rm *rm,
+				struct notifier_block *nb);
+int gunyah_rm_notifier_unregister(struct gunyah_rm *rm,
+				  struct notifier_block *nb);
+struct device *gunyah_rm_get(struct gunyah_rm *rm);
+void gunyah_rm_put(struct gunyah_rm *rm);
+
+#endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:51 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:51 -0800
Subject: [PATCH RFC v15 10/30] gunyah: vm_mgr: Add ioctls to support basic
 non-proxy VM boot
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-10-192a5d872a30@quicinc.com>

Add remaining ioctls to support non-proxy VM boot:

 - Gunyah Resource Manager uses the VM's devicetree to configure the
   virtual machine. The location of the devicetree in the guest's
   virtual memory can be declared via the SET_DTB_CONFIG ioctl.
 - Trigger start of the virtual machine with VM_START ioctl.

Reviewed-by: Alex Elder <elder at linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/vm_mgr.c | 194 +++++++++++++++++++++++++++++++++++++++++++
 drivers/virt/gunyah/vm_mgr.h |  11 +++
 include/uapi/linux/gunyah.h  |   5 ++
 3 files changed, 210 insertions(+)

diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index b4d44379e5ce..1b1b26f568af 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -15,6 +15,68 @@
 
 #include "vm_mgr.h"
 
+static int gunyah_vm_rm_notification_status(struct gunyah_vm *ghvm, void *data)
+{
+	struct gunyah_rm_vm_status_payload *payload = data;
+
+	if (le16_to_cpu(payload->vmid) != ghvm->vmid)
+		return NOTIFY_OK;
+
+	/* All other state transitions are synchronous to a corresponding RM call */
+	if (payload->vm_status == GUNYAH_RM_VM_STATUS_RESET) {
+		down_write(&ghvm->status_lock);
+		ghvm->vm_status = payload->vm_status;
+		up_write(&ghvm->status_lock);
+		wake_up(&ghvm->vm_status_wait);
+	}
+
+	return NOTIFY_DONE;
+}
+
+static int gunyah_vm_rm_notification_exited(struct gunyah_vm *ghvm, void *data)
+{
+	struct gunyah_rm_vm_exited_payload *payload = data;
+
+	if (le16_to_cpu(payload->vmid) != ghvm->vmid)
+		return NOTIFY_OK;
+
+	down_write(&ghvm->status_lock);
+	ghvm->vm_status = GUNYAH_RM_VM_STATUS_EXITED;
+	up_write(&ghvm->status_lock);
+	wake_up(&ghvm->vm_status_wait);
+
+	return NOTIFY_DONE;
+}
+
+static int gunyah_vm_rm_notification(struct notifier_block *nb,
+				     unsigned long action, void *data)
+{
+	struct gunyah_vm *ghvm = container_of(nb, struct gunyah_vm, nb);
+
+	switch (action) {
+	case GUNYAH_RM_NOTIFICATION_VM_STATUS:
+		return gunyah_vm_rm_notification_status(ghvm, data);
+	case GUNYAH_RM_NOTIFICATION_VM_EXITED:
+		return gunyah_vm_rm_notification_exited(ghvm, data);
+	default:
+		return NOTIFY_OK;
+	}
+}
+
+static void gunyah_vm_stop(struct gunyah_vm *ghvm)
+{
+	int ret;
+
+	if (ghvm->vm_status == GUNYAH_RM_VM_STATUS_RUNNING) {
+		ret = gunyah_rm_vm_stop(ghvm->rm, ghvm->vmid);
+		if (ret)
+			dev_warn(ghvm->parent, "Failed to stop VM: %d\n", ret);
+	}
+
+	wait_event(ghvm->vm_status_wait,
+		   ghvm->vm_status == GUNYAH_RM_VM_STATUS_EXITED);
+}
+
 static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 {
 	struct gunyah_vm *ghvm;
@@ -24,14 +86,144 @@ static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 		return ERR_PTR(-ENOMEM);
 
 	ghvm->parent = gunyah_rm_get(rm);
+	ghvm->vmid = GUNYAH_VMID_INVAL;
 	ghvm->rm = rm;
 
+	init_rwsem(&ghvm->status_lock);
+	init_waitqueue_head(&ghvm->vm_status_wait);
+	ghvm->vm_status = GUNYAH_RM_VM_STATUS_NO_STATE;
+
 	return ghvm;
 }
 
+static int gunyah_vm_start(struct gunyah_vm *ghvm)
+{
+	int ret;
+
+	down_write(&ghvm->status_lock);
+	if (ghvm->vm_status != GUNYAH_RM_VM_STATUS_NO_STATE) {
+		up_write(&ghvm->status_lock);
+		return 0;
+	}
+
+	ghvm->nb.notifier_call = gunyah_vm_rm_notification;
+	ret = gunyah_rm_notifier_register(ghvm->rm, &ghvm->nb);
+	if (ret)
+		goto err;
+
+	ret = gunyah_rm_alloc_vmid(ghvm->rm, 0);
+	if (ret < 0) {
+		gunyah_rm_notifier_unregister(ghvm->rm, &ghvm->nb);
+		goto err;
+	}
+	ghvm->vmid = ret;
+	ghvm->vm_status = GUNYAH_RM_VM_STATUS_LOAD;
+
+	ret = gunyah_rm_vm_configure(ghvm->rm, ghvm->vmid, ghvm->auth, 0, 0, 0,
+				     0, 0);
+	if (ret) {
+		dev_warn(ghvm->parent, "Failed to configure VM: %d\n", ret);
+		goto err;
+	}
+
+	ret = gunyah_rm_vm_init(ghvm->rm, ghvm->vmid);
+	if (ret) {
+		ghvm->vm_status = GUNYAH_RM_VM_STATUS_INIT_FAILED;
+		dev_warn(ghvm->parent, "Failed to initialize VM: %d\n", ret);
+		goto err;
+	}
+	ghvm->vm_status = GUNYAH_RM_VM_STATUS_READY;
+
+	ret = gunyah_rm_vm_start(ghvm->rm, ghvm->vmid);
+	if (ret) {
+		dev_warn(ghvm->parent, "Failed to start VM: %d\n", ret);
+		goto err;
+	}
+
+	ghvm->vm_status = GUNYAH_RM_VM_STATUS_RUNNING;
+	up_write(&ghvm->status_lock);
+	return ret;
+err:
+	/* gunyah_vm_free will handle releasing resources and reclaiming memory */
+	up_write(&ghvm->status_lock);
+	return ret;
+}
+
+static int gunyah_vm_ensure_started(struct gunyah_vm *ghvm)
+{
+	int ret;
+
+	ret = down_read_interruptible(&ghvm->status_lock);
+	if (ret)
+		return ret;
+
+	/* Unlikely because VM is typically started */
+	if (unlikely(ghvm->vm_status == GUNYAH_RM_VM_STATUS_NO_STATE)) {
+		up_read(&ghvm->status_lock);
+		ret = gunyah_vm_start(ghvm);
+		if (ret)
+			return ret;
+		/** gunyah_vm_start() is guaranteed to bring status out of
+		 * GUNYAH_RM_VM_STATUS_LOAD, thus infinitely recursive call is not
+		 * possible
+		 */
+		return gunyah_vm_ensure_started(ghvm);
+	}
+
+	/* Unlikely because VM is typically running */
+	if (unlikely(ghvm->vm_status != GUNYAH_RM_VM_STATUS_RUNNING))
+		ret = -ENODEV;
+
+	up_read(&ghvm->status_lock);
+	return ret;
+}
+
+static long gunyah_vm_ioctl(struct file *filp, unsigned int cmd,
+			    unsigned long arg)
+{
+	struct gunyah_vm *ghvm = filp->private_data;
+	long r;
+
+	switch (cmd) {
+	case GUNYAH_VM_START: {
+		r = gunyah_vm_ensure_started(ghvm);
+		break;
+	}
+	default:
+		r = -ENOTTY;
+		break;
+	}
+
+	return r;
+}
+
 static int gunyah_vm_release(struct inode *inode, struct file *filp)
 {
 	struct gunyah_vm *ghvm = filp->private_data;
+	int ret;
+
+	if (ghvm->vm_status == GUNYAH_RM_VM_STATUS_RUNNING)
+		gunyah_vm_stop(ghvm);
+
+	if (ghvm->vm_status != GUNYAH_RM_VM_STATUS_NO_STATE &&
+	    ghvm->vm_status != GUNYAH_RM_VM_STATUS_LOAD &&
+	    ghvm->vm_status != GUNYAH_RM_VM_STATUS_RESET) {
+		ret = gunyah_rm_vm_reset(ghvm->rm, ghvm->vmid);
+		if (ret)
+			dev_err(ghvm->parent, "Failed to reset the vm: %d\n",
+				ret);
+		wait_event(ghvm->vm_status_wait,
+			   ghvm->vm_status == GUNYAH_RM_VM_STATUS_RESET);
+	}
+
+	if (ghvm->vm_status > GUNYAH_RM_VM_STATUS_NO_STATE) {
+		gunyah_rm_notifier_unregister(ghvm->rm, &ghvm->nb);
+
+		ret = gunyah_rm_dealloc_vmid(ghvm->rm, ghvm->vmid);
+		if (ret)
+			dev_warn(ghvm->parent,
+				 "Failed to deallocate vmid: %d\n", ret);
+	}
 
 	gunyah_rm_put(ghvm->rm);
 	kfree(ghvm);
@@ -40,6 +232,8 @@ static int gunyah_vm_release(struct inode *inode, struct file *filp)
 
 static const struct file_operations gunyah_vm_fops = {
 	.owner = THIS_MODULE,
+	.unlocked_ioctl = gunyah_vm_ioctl,
+	.compat_ioctl = compat_ptr_ioctl,
 	.release = gunyah_vm_release,
 	.llseek = noop_llseek,
 };
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index 434a510e360f..aa058722c5fe 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -8,6 +8,10 @@
 
 #include <linux/device.h>
 #include <linux/gunyah_rsc_mgr.h>
+#include <linux/kref.h>
+#include <linux/notifier.h>
+#include <linux/rwsem.h>
+#include <linux/wait.h>
 
 #include <uapi/linux/gunyah.h>
 
@@ -15,8 +19,15 @@ long gunyah_dev_vm_mgr_ioctl(struct gunyah_rm *rm, unsigned int cmd,
 			     unsigned long arg);
 
 struct gunyah_vm {
+	u16 vmid;
 	struct gunyah_rm *rm;
 	struct device *parent;
+	enum gunyah_rm_vm_auth_mechanism auth;
+
+	struct notifier_block nb;
+	enum gunyah_rm_vm_status vm_status;
+	wait_queue_head_t vm_status_wait;
+	struct rw_semaphore status_lock;
 };
 
 #endif
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
index ac338ec4b85d..31e7f79a6c39 100644
--- a/include/uapi/linux/gunyah.h
+++ b/include/uapi/linux/gunyah.h
@@ -20,4 +20,9 @@
  */
 #define GUNYAH_CREATE_VM _IO(GUNYAH_IOCTL_TYPE, 0x0) /* Returns a Gunyah VM fd */
 
+/*
+ * ioctls for gunyah-vm fds (returned by GUNYAH_CREATE_VM)
+ */
+#define GUNYAH_VM_START		_IO(GUNYAH_IOCTL_TYPE, 0x3)
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:59 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:59 -0800
Subject: [PATCH RFC v15 18/30] virt: gunyah: Add IO handlers
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-18-192a5d872a30@quicinc.com>

Add framework for VM functions to handle stage-2 write faults from Gunyah
guest virtual machines. IO handlers have a range of addresses which they
apply to. Optionally, they may apply to only when the value written
matches the IO handler's value.

Reviewed-by: Alex Elder <elder at linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/vm_mgr.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index d2f6ac212169..5d1ebce678ad 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -74,4 +74,6 @@ int gunyah_vm_provide_folio(struct gunyah_vm *ghvm, struct folio *folio,
 int gunyah_vm_reclaim_folio(struct gunyah_vm *ghvm, u64 gfn);
 void gunyah_vm_reclaim_memory(struct gunyah_vm *ghvm);
 
+int gunyah_vm_mmio_write(struct gunyah_vm *ghvm, u64 addr, u32 len, u64 data);
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:55 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:55 -0800
Subject: [PATCH RFC v15 14/30] virt: gunyah: Add IO handlers
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-14-192a5d872a30@quicinc.com>

Add framework for VM functions to handle stage-2 write faults from Gunyah
guest virtual machines. IO handlers have a range of addresses which they
apply to. Optionally, they may apply to only when the value written
matches the IO handler's value.

Reviewed-by: Alex Elder <elder at linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/vm_mgr.c  | 114 ++++++++++++++++++++++++++++++++++++++++++
 drivers/virt/gunyah/vm_mgr.h  |   5 ++
 include/linux/gunyah_vm_mgr.h |  29 +++++++++++
 3 files changed, 148 insertions(+)

diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index fb22459b21c8..8feb9302d7d2 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -285,6 +285,118 @@ static void gunyah_vm_clean_resources(struct gunyah_vm *ghvm)
 	mutex_unlock(&ghvm->resources_lock);
 }
 
+static int _gunyah_vm_io_handler_compare(const struct rb_node *node,
+					 const struct rb_node *parent)
+{
+	struct gunyah_vm_io_handler *n =
+		container_of(node, struct gunyah_vm_io_handler, node);
+	struct gunyah_vm_io_handler *p =
+		container_of(parent, struct gunyah_vm_io_handler, node);
+
+	if (n->addr < p->addr)
+		return -1;
+	if (n->addr > p->addr)
+		return 1;
+	if ((n->len && !p->len) || (!n->len && p->len))
+		return 0;
+	if (n->len < p->len)
+		return -1;
+	if (n->len > p->len)
+		return 1;
+	/* one of the io handlers doesn't have datamatch and the other does.
+	 * For purposes of comparison, that makes them identical since the
+	 * one that doesn't have datamatch will cover the same handler that
+	 * does.
+	 */
+	if (n->datamatch != p->datamatch)
+		return 0;
+	if (n->data < p->data)
+		return -1;
+	if (n->data > p->data)
+		return 1;
+	return 0;
+}
+
+static int gunyah_vm_io_handler_compare(struct rb_node *node,
+					const struct rb_node *parent)
+{
+	return _gunyah_vm_io_handler_compare(node, parent);
+}
+
+static int gunyah_vm_io_handler_find(const void *key,
+				     const struct rb_node *node)
+{
+	const struct gunyah_vm_io_handler *k = key;
+
+	return _gunyah_vm_io_handler_compare(&k->node, node);
+}
+
+static struct gunyah_vm_io_handler *
+gunyah_vm_mgr_find_io_hdlr(struct gunyah_vm *ghvm, u64 addr, u64 len, u64 data)
+{
+	struct gunyah_vm_io_handler key = {
+		.addr = addr,
+		.len = len,
+		.datamatch = true,
+		.data = data,
+	};
+	struct rb_node *node;
+
+	node = rb_find(&key, &ghvm->mmio_handler_root,
+		       gunyah_vm_io_handler_find);
+	if (!node)
+		return NULL;
+
+	return container_of(node, struct gunyah_vm_io_handler, node);
+}
+
+int gunyah_vm_mmio_write(struct gunyah_vm *ghvm, u64 addr, u32 len, u64 data)
+{
+	struct gunyah_vm_io_handler *io_hdlr = NULL;
+	int ret;
+
+	down_read(&ghvm->mmio_handler_lock);
+	io_hdlr = gunyah_vm_mgr_find_io_hdlr(ghvm, addr, len, data);
+	if (!io_hdlr || !io_hdlr->ops || !io_hdlr->ops->write) {
+		ret = -ENOENT;
+		goto out;
+	}
+
+	ret = io_hdlr->ops->write(io_hdlr, addr, len, data);
+
+out:
+	up_read(&ghvm->mmio_handler_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(gunyah_vm_mmio_write);
+
+int gunyah_vm_add_io_handler(struct gunyah_vm *ghvm,
+			     struct gunyah_vm_io_handler *io_hdlr)
+{
+	struct rb_node *found;
+
+	if (io_hdlr->datamatch &&
+	    (!io_hdlr->len || io_hdlr->len > sizeof(io_hdlr->data)))
+		return -EINVAL;
+
+	down_write(&ghvm->mmio_handler_lock);
+	found = rb_find_add(&io_hdlr->node, &ghvm->mmio_handler_root,
+			    gunyah_vm_io_handler_compare);
+	up_write(&ghvm->mmio_handler_lock);
+
+	return found ? -EEXIST : 0;
+}
+EXPORT_SYMBOL_GPL(gunyah_vm_add_io_handler);
+
+void gunyah_vm_remove_io_handler(struct gunyah_vm *ghvm,
+				 struct gunyah_vm_io_handler *io_hdlr)
+{
+	down_write(&ghvm->mmio_handler_lock);
+	rb_erase(&io_hdlr->node, &ghvm->mmio_handler_root);
+	up_write(&ghvm->mmio_handler_lock);
+}
+EXPORT_SYMBOL_GPL(gunyah_vm_remove_io_handler);
+
 static int gunyah_vm_rm_notification_status(struct gunyah_vm *ghvm, void *data)
 {
 	struct gunyah_rm_vm_status_payload *payload = data;
@@ -366,6 +478,8 @@ static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 	mutex_init(&ghvm->resources_lock);
 	INIT_LIST_HEAD(&ghvm->resources);
 	INIT_LIST_HEAD(&ghvm->resource_tickets);
+	init_rwsem(&ghvm->mmio_handler_lock);
+	ghvm->mmio_handler_root = RB_ROOT;
 	INIT_LIST_HEAD(&ghvm->functions);
 	mutex_init(&ghvm->fn_lock);
 
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index b94f6d16b787..a26bf81e94fc 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -12,6 +12,7 @@
 #include <linux/list.h>
 #include <linux/mutex.h>
 #include <linux/notifier.h>
+#include <linux/rbtree.h>
 #include <linux/rwsem.h>
 #include <linux/wait.h>
 
@@ -37,6 +38,10 @@ struct gunyah_vm {
 	struct mutex resources_lock;
 	struct list_head resources;
 	struct list_head resource_tickets;
+	struct rb_root mmio_handler_root;
+	struct rw_semaphore mmio_handler_lock;
 };
 
+int gunyah_vm_mmio_write(struct gunyah_vm *ghvm, u64 addr, u32 len, u64 data);
+
 #endif
diff --git a/include/linux/gunyah_vm_mgr.h b/include/linux/gunyah_vm_mgr.h
index b02c6e89b207..635adcbcc7d4 100644
--- a/include/linux/gunyah_vm_mgr.h
+++ b/include/linux/gunyah_vm_mgr.h
@@ -133,4 +133,33 @@ int gunyah_vm_add_resource_ticket(struct gunyah_vm *ghvm,
 void gunyah_vm_remove_resource_ticket(struct gunyah_vm *ghvm,
 				      struct gunyah_vm_resource_ticket *ticket);
 
+/*
+ * gunyah_vm_io_handler contains the info about an io device and its associated
+ * addr and the ops associated with the io device.
+ */
+struct gunyah_vm_io_handler {
+	struct rb_node node;
+	u64 addr;
+
+	bool datamatch;
+	u8 len;
+	u64 data;
+	struct gunyah_vm_io_handler_ops *ops;
+};
+
+/*
+ * gunyah_vm_io_handler_ops contains function pointers associated with an iodevice.
+ */
+struct gunyah_vm_io_handler_ops {
+	int (*read)(struct gunyah_vm_io_handler *io_dev, u64 addr, u32 len,
+		    u64 data);
+	int (*write)(struct gunyah_vm_io_handler *io_dev, u64 addr, u32 len,
+		     u64 data);
+};
+
+int gunyah_vm_add_io_handler(struct gunyah_vm *ghvm,
+			     struct gunyah_vm_io_handler *io_dev);
+void gunyah_vm_remove_io_handler(struct gunyah_vm *ghvm,
+				 struct gunyah_vm_io_handler *io_dev);
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:56 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:56 -0800
Subject: [PATCH RFC v15 15/30] gunyah: Add hypercalls for demand paging
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-15-192a5d872a30@quicinc.com>

Three hypercalls are needed to support demand paging.

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 arch/arm64/gunyah/gunyah_hypercall.c | 60 +++++++++++++++++++++++++++
 arch/arm64/include/asm/gunyah.h      | 21 ++++++++++
 include/linux/gunyah.h               | 79 ++++++++++++++++++++++++++++++++++++
 3 files changed, 160 insertions(+)

diff --git a/arch/arm64/gunyah/gunyah_hypercall.c b/arch/arm64/gunyah/gunyah_hypercall.c
index cadc512934c4..468a5bcb98b1 100644
--- a/arch/arm64/gunyah/gunyah_hypercall.c
+++ b/arch/arm64/gunyah/gunyah_hypercall.c
@@ -39,6 +39,9 @@ EXPORT_SYMBOL_GPL(arch_is_gunyah_guest);
 #define GUNYAH_HYPERCALL_HYP_IDENTIFY		GUNYAH_HYPERCALL(0x8000)
 #define GUNYAH_HYPERCALL_MSGQ_SEND		GUNYAH_HYPERCALL(0x801B)
 #define GUNYAH_HYPERCALL_MSGQ_RECV		GUNYAH_HYPERCALL(0x801C)
+#define GUNYAH_HYPERCALL_ADDRSPACE_MAP		GUNYAH_HYPERCALL(0x802B)
+#define GUNYAH_HYPERCALL_ADDRSPACE_UNMAP		GUNYAH_HYPERCALL(0x802C)
+#define GUNYAH_HYPERCALL_MEMEXTENT_DONATE		GUNYAH_HYPERCALL(0x8061)
 /* clang-format on */
 
 /**
@@ -92,5 +95,62 @@ enum gunyah_error gunyah_hypercall_msgq_recv(u64 capid, void *buff, size_t size,
 }
 EXPORT_SYMBOL_GPL(gunyah_hypercall_msgq_recv);
 
+enum gunyah_error gunyah_hypercall_addrspace_map(u64 capid, u64 extent_capid, u64 vbase,
+					u32 extent_attrs, u32 flags, u64 offset, u64 size)
+{
+	struct arm_smccc_1_2_regs args = {
+		.a0 = GUNYAH_HYPERCALL_ADDRSPACE_MAP,
+		.a1 = capid,
+		.a2 = extent_capid,
+		.a3 = vbase,
+		.a4 = extent_attrs,
+		.a5 = flags,
+		.a6 = offset,
+		.a7 = size,
+		/* C language says this will be implictly zero. Gunyah requires 0, so be explicit */
+		.a8 = 0,
+	};
+	struct arm_smccc_1_2_regs res;
+
+	arm_smccc_1_2_hvc(&args, &res);
+
+	return res.a0;
+}
+EXPORT_SYMBOL_GPL(gunyah_hypercall_addrspace_map);
+
+enum gunyah_error gunyah_hypercall_addrspace_unmap(u64 capid, u64 extent_capid, u64 vbase,
+					u32 flags, u64 offset, u64 size)
+{
+	struct arm_smccc_1_2_regs args = {
+		.a0 = GUNYAH_HYPERCALL_ADDRSPACE_UNMAP,
+		.a1 = capid,
+		.a2 = extent_capid,
+		.a3 = vbase,
+		.a4 = flags,
+		.a5 = offset,
+		.a6 = size,
+		/* C language says this will be implictly zero. Gunyah requires 0, so be explicit */
+		.a7 = 0,
+	};
+	struct arm_smccc_1_2_regs res;
+
+	arm_smccc_1_2_hvc(&args, &res);
+
+	return res.a0;
+}
+EXPORT_SYMBOL_GPL(gunyah_hypercall_addrspace_unmap);
+
+enum gunyah_error gunyah_hypercall_memextent_donate(u32 options, u64 from_capid, u64 to_capid,
+					    u64 offset, u64 size)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_hvc(GUNYAH_HYPERCALL_MEMEXTENT_DONATE, options, from_capid, to_capid,
+				offset, size, 0, &res);
+
+	return res.a0;
+}
+EXPORT_SYMBOL_GPL(gunyah_hypercall_memextent_donate);
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Gunyah Hypervisor Hypercalls");
diff --git a/arch/arm64/include/asm/gunyah.h b/arch/arm64/include/asm/gunyah.h
index 0cd3debe22b6..4adf24977fd1 100644
--- a/arch/arm64/include/asm/gunyah.h
+++ b/arch/arm64/include/asm/gunyah.h
@@ -33,4 +33,25 @@ static inline int arch_gunyah_fill_irq_fwspec_params(u32 virq,
 	return 0;
 }
 
+enum arch_gunyah_memtype {
+	/* clang-format off */
+	GUNYAH_MEMTYPE_DEVICE_nGnRnE	= 0,
+	GUNYAH_DEVICE_nGnRE		= 1,
+	GUNYAH_DEVICE_nGRE		= 2,
+	GUNYAH_DEVICE_GRE		= 3,
+
+	GUNYAH_NORMAL_NC	= 0b0101,
+	GUNYAH_NORMAL_ONC_IWT	= 0b0110,
+	GUNYAH_NORMAL_ONC_IWB	= 0b0111,
+	GUNYAH_NORMAL_OWT_INC	= 0b1001,
+	GUNYAH_NORMAL_WT	= 0b1010,
+	GUNYAH_NORMAL_OWT_IWB	= 0b1011,
+	GUNYAH_NORMAL_OWB_INC	= 0b1101,
+	GUNYAH_NORMAL_OWB_IWT	= 0b1110,
+	GUNYAH_NORMAL_WB	= 0b1111,
+	/* clang-format on */
+};
+
+#define ARCH_GUNYAH_DEFAULT_MEMTYPE	GUNYAH_NORMAL_WB
+
 #endif
diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h
index ecd62d0e36ad..86f48dc1d56d 100644
--- a/include/linux/gunyah.h
+++ b/include/linux/gunyah.h
@@ -151,4 +151,83 @@ enum gunyah_error gunyah_hypercall_msgq_send(u64 capid, size_t size, void *buff,
 enum gunyah_error gunyah_hypercall_msgq_recv(u64 capid, void *buff, size_t size,
 					     size_t *recv_size, bool *ready);
 
+#define GUNYAH_ADDRSPACE_SELF_CAP 0
+
+enum gunyah_pagetable_access {
+	/* clang-format off */
+	GUNYAH_PAGETABLE_ACCESS_NONE		= 0,
+	GUNYAH_PAGETABLE_ACCESS_X		= 1,
+	GUNYAH_PAGETABLE_ACCESS_W		= 2,
+	GUNYAH_PAGETABLE_ACCESS_R		= 4,
+	GUNYAH_PAGETABLE_ACCESS_RX		= 5,
+	GUNYAH_PAGETABLE_ACCESS_RW		= 6,
+	GUNYAH_PAGETABLE_ACCESS_RWX		= 7,
+	/* clang-format on */
+};
+
+/* clang-format off */
+#define GUNYAH_MEMEXTENT_MAPPING_USER_ACCESS		GENMASK_ULL(2, 0)
+#define GUNYAH_MEMEXTENT_MAPPING_KERNEL_ACCESS		GENMASK_ULL(6, 4)
+#define GUNYAH_MEMEXTENT_MAPPING_TYPE			GENMASK_ULL(23, 16)
+/* clang-format on */
+
+enum gunyah_memextent_donate_type {
+	/* clang-format off */
+	GUNYAH_MEMEXTENT_DONATE_TO_CHILD		= 0,
+	GUNYAH_MEMEXTENT_DONATE_TO_PARENT		= 1,
+	GUNYAH_MEMEXTENT_DONATE_TO_SIBLING		= 2,
+	GUNYAH_MEMEXTENT_DONATE_TO_PROTECTED		= 3,
+	GUNYAH_MEMEXTENT_DONATE_FROM_PROTECTED		= 4,
+	/* clang-format on */
+};
+
+enum gunyah_addrspace_map_flag_bits {
+	/* clang-format off */
+	GUNYAH_ADDRSPACE_MAP_FLAG_PARTIAL	= 0,
+	GUNYAH_ADDRSPACE_MAP_FLAG_PRIVATE	= 1,
+	GUNYAH_ADDRSPACE_MAP_FLAG_VMMIO		= 2,
+	GUNYAH_ADDRSPACE_MAP_FLAG_NOSYNC	= 31,
+	/* clang-format on */
+};
+
+enum gunyah_error gunyah_hypercall_addrspace_map(u64 capid, u64 extent_capid,
+						 u64 vbase, u32 extent_attrs,
+						 u32 flags, u64 offset,
+						 u64 size);
+enum gunyah_error gunyah_hypercall_addrspace_unmap(u64 capid, u64 extent_capid,
+						   u64 vbase, u32 flags,
+						   u64 offset, u64 size);
+
+/* clang-format off */
+#define GUNYAH_MEMEXTENT_OPTION_TYPE_MASK	GENMASK_ULL(7, 0)
+#define GUNYAH_MEMEXTENT_OPTION_NOSYNC		BIT(31)
+/* clang-format on */
+
+enum gunyah_error gunyah_hypercall_memextent_donate(u32 options, u64 from_capid,
+						    u64 to_capid, u64 offset,
+						    u64 size);
+
+struct gunyah_hypercall_vcpu_run_resp {
+	union {
+		enum {
+			/* clang-format off */
+			/* VCPU is ready to run */
+			GUNYAH_VCPU_STATE_READY			= 0,
+			/* VCPU is sleeping until an interrupt arrives */
+			GUNYAH_VCPU_STATE_EXPECTS_WAKEUP	= 1,
+			/* VCPU is powered off */
+			GUNYAH_VCPU_STATE_POWERED_OFF		= 2,
+			/* VCPU is blocked in EL2 for unspecified reason */
+			GUNYAH_VCPU_STATE_BLOCKED		= 3,
+			/* VCPU has returned for MMIO READ */
+			GUNYAH_VCPU_ADDRSPACE_VMMIO_READ	= 4,
+			/* VCPU has returned for MMIO WRITE */
+			GUNYAH_VCPU_ADDRSPACE_VMMIO_WRITE	= 5,
+			/* clang-format on */
+		} state;
+		u64 sized_state;
+	};
+	u64 state_data[3];
+};
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:53 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:53 -0800
Subject: [PATCH RFC v15 12/30] virt: gunyah: Translate gh_rm_hyp_resource
 into gunyah_resource
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-12-192a5d872a30@quicinc.com>

When booting a Gunyah virtual machine, the host VM may gain capabilities
to interact with resources for the guest virtual machine. Examples of
such resources are vCPUs or message queues. To use those resources, we
need to translate the RM response into a gunyah_resource structure which
are useful to Linux drivers. Presently, Linux drivers need only to know
the type of resource, the capability ID, and an interrupt.

On ARM64 systems, the interrupt reported by Gunyah is the GIC interrupt
ID number and always a SPI.

Reviewed-by: Alex Elder <elder at linaro.org>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 arch/arm64/include/asm/gunyah.h |  36 +++++++++
 drivers/virt/gunyah/rsc_mgr.c   | 174 +++++++++++++++++++++++++++++++++++++++-
 include/linux/gunyah.h          |   3 +
 include/linux/gunyah_rsc_mgr.h  |   5 ++
 4 files changed, 217 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/gunyah.h b/arch/arm64/include/asm/gunyah.h
new file mode 100644
index 000000000000..0cd3debe22b6
--- /dev/null
+++ b/arch/arm64/include/asm/gunyah.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+#ifndef _ASM_GUNYAH_H
+#define _ASM_GUNYAH_H
+
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+
+static inline int arch_gunyah_fill_irq_fwspec_params(u32 virq,
+						 struct irq_fwspec *fwspec)
+{
+	/* Assume that Gunyah gave us an SPI or ESPI; defensively check it */
+	if (WARN(virq < 32, "Unexpected virq: %d\n", virq)) {
+		return -EINVAL;
+	} else if (virq <= 1019) {
+		fwspec->param_count = 3;
+		fwspec->param[0] = 0; /* GIC_SPI */
+		fwspec->param[1] = virq - 32; /* virq 32 -> SPI 0 */
+		fwspec->param[2] = IRQ_TYPE_EDGE_RISING;
+	} else if (WARN(virq < 4096, "Unexpected virq: %d\n", virq)) {
+		return -EINVAL;
+	} else if (virq < 5120) {
+		fwspec->param_count = 3;
+		fwspec->param[0] = 2; /* GIC_ESPI */
+		fwspec->param[1] = virq - 4096; /* virq 4096 -> ESPI 0 */
+		fwspec->param[2] = IRQ_TYPE_EDGE_RISING;
+	} else {
+		WARN(1, "Unexpected virq: %d\n", virq);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+#endif
diff --git a/drivers/virt/gunyah/rsc_mgr.c b/drivers/virt/gunyah/rsc_mgr.c
index 052b3f072a85..acd772deb950 100644
--- a/drivers/virt/gunyah/rsc_mgr.c
+++ b/drivers/virt/gunyah/rsc_mgr.c
@@ -17,6 +17,8 @@
 #include <linux/platform_device.h>
 #include <linux/miscdevice.h>
 
+#include <asm/gunyah.h>
+
 #include "rsc_mgr.h"
 #include "vm_mgr.h"
 
@@ -129,6 +131,7 @@ struct gunyah_rm_message {
  * @send_ready: completion to send messages again
  * @nh: notifier chain for clients interested in RM notification messages
  * @miscdev: /dev/gunyah
+ * @irq_domain: Domain to translate Gunyah hwirqs to Linux irqs
  */
 struct gunyah_rm {
 	struct device *dev;
@@ -147,6 +150,7 @@ struct gunyah_rm {
 	struct blocking_notifier_head nh;
 
 	struct miscdevice miscdev;
+	struct irq_domain *irq_domain;
 };
 
 /**
@@ -187,6 +191,143 @@ static inline int gunyah_rm_error_remap(enum gunyah_rm_error rm_error)
 	}
 }
 
+struct gunyah_irq_chip_data {
+	u32 gunyah_virq;
+};
+
+static struct irq_chip gunyah_rm_irq_chip = {
+	/* clang-format off */
+	.name			= "Gunyah",
+	.irq_enable		= irq_chip_enable_parent,
+	.irq_disable		= irq_chip_disable_parent,
+	.irq_ack		= irq_chip_ack_parent,
+	.irq_mask		= irq_chip_mask_parent,
+	.irq_mask_ack		= irq_chip_mask_ack_parent,
+	.irq_unmask		= irq_chip_unmask_parent,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= irq_chip_set_affinity_parent,
+	.irq_set_type		= irq_chip_set_type_parent,
+	.irq_set_wake		= irq_chip_set_wake_parent,
+	.irq_set_vcpu_affinity	= irq_chip_set_vcpu_affinity_parent,
+	.irq_retrigger		= irq_chip_retrigger_hierarchy,
+	.irq_get_irqchip_state	= irq_chip_get_parent_state,
+	.irq_set_irqchip_state	= irq_chip_set_parent_state,
+	.flags			= IRQCHIP_SET_TYPE_MASKED |
+				  IRQCHIP_SKIP_SET_WAKE |
+				  IRQCHIP_MASK_ON_SUSPEND,
+	/* clang-format on */
+};
+
+static int gunyah_rm_irq_domain_alloc(struct irq_domain *d, unsigned int virq,
+				      unsigned int nr_irqs, void *arg)
+{
+	struct gunyah_irq_chip_data *chip_data, *spec = arg;
+	struct irq_fwspec parent_fwspec = {};
+	struct gunyah_rm *rm = d->host_data;
+	u32 gunyah_virq = spec->gunyah_virq;
+	int ret;
+
+	if (nr_irqs != 1)
+		return -EINVAL;
+
+	chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
+	if (!chip_data)
+		return -ENOMEM;
+
+	chip_data->gunyah_virq = gunyah_virq;
+
+	ret = irq_domain_set_hwirq_and_chip(d, virq, chip_data->gunyah_virq,
+					    &gunyah_rm_irq_chip, chip_data);
+	if (ret)
+		goto err_free_irq_data;
+
+	parent_fwspec.fwnode = d->parent->fwnode;
+	ret = arch_gunyah_fill_irq_fwspec_params(chip_data->gunyah_virq,
+						 &parent_fwspec);
+	if (ret) {
+		dev_err(rm->dev, "virq translation failed %u: %d\n",
+			chip_data->gunyah_virq, ret);
+		goto err_free_irq_data;
+	}
+
+	ret = irq_domain_alloc_irqs_parent(d, virq, nr_irqs, &parent_fwspec);
+	if (ret)
+		goto err_free_irq_data;
+
+	return ret;
+err_free_irq_data:
+	kfree(chip_data);
+	return ret;
+}
+
+static void gunyah_rm_irq_domain_free_single(struct irq_domain *d,
+					     unsigned int virq)
+{
+	struct irq_data *irq_data;
+
+	irq_data = irq_domain_get_irq_data(d, virq);
+	if (!irq_data)
+		return;
+
+	kfree(irq_data->chip_data);
+	irq_data->chip_data = NULL;
+}
+
+static void gunyah_rm_irq_domain_free(struct irq_domain *d, unsigned int virq,
+				      unsigned int nr_irqs)
+{
+	unsigned int i;
+
+	for (i = 0; i < nr_irqs; i++)
+		gunyah_rm_irq_domain_free_single(d, virq);
+}
+
+static const struct irq_domain_ops gunyah_rm_irq_domain_ops = {
+	.alloc = gunyah_rm_irq_domain_alloc,
+	.free = gunyah_rm_irq_domain_free,
+};
+
+struct gunyah_resource *
+gunyah_rm_alloc_resource(struct gunyah_rm *rm,
+			 struct gunyah_rm_hyp_resource *hyp_resource)
+{
+	struct gunyah_resource *ghrsc;
+	int ret;
+
+	ghrsc = kzalloc(sizeof(*ghrsc), GFP_KERNEL);
+	if (!ghrsc)
+		return NULL;
+
+	ghrsc->type = hyp_resource->type;
+	ghrsc->capid = le64_to_cpu(hyp_resource->cap_id);
+	ghrsc->irq = IRQ_NOTCONNECTED;
+	ghrsc->rm_label = le32_to_cpu(hyp_resource->resource_label);
+	if (hyp_resource->virq) {
+		struct gunyah_irq_chip_data irq_data = {
+			.gunyah_virq = le32_to_cpu(hyp_resource->virq),
+		};
+
+		ret = irq_domain_alloc_irqs(rm->irq_domain, 1, NUMA_NO_NODE,
+					    &irq_data);
+		if (ret < 0) {
+			dev_err(rm->dev,
+				"Failed to allocate interrupt for resource %d label: %d: %d\n",
+				ghrsc->type, ghrsc->rm_label, ret);
+			kfree(ghrsc);
+			return NULL;
+		}
+		ghrsc->irq = ret;
+	}
+
+	return ghrsc;
+}
+
+void gunyah_rm_free_resource(struct gunyah_resource *ghrsc)
+{
+	irq_dispose_mapping(ghrsc->irq);
+	kfree(ghrsc);
+}
+
 static int gunyah_rm_init_message_payload(struct gunyah_rm_message *message,
 					  const void *msg, size_t hdr_size,
 					  size_t msg_size)
@@ -713,6 +854,8 @@ static int gunyah_rm_probe_rx_msgq(struct gunyah_rm *rm,
 
 static int gunyah_rm_probe(struct platform_device *pdev)
 {
+	struct irq_domain *parent_irq_domain;
+	struct device_node *parent_irq_node;
 	struct gunyah_rm *rm;
 	int ret;
 
@@ -738,15 +881,43 @@ static int gunyah_rm_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	parent_irq_node = of_irq_find_parent(pdev->dev.of_node);
+	if (!parent_irq_node) {
+		dev_err(&pdev->dev,
+			"Failed to find interrupt parent of resource manager\n");
+		return -ENODEV;
+	}
+
+	parent_irq_domain = irq_find_host(parent_irq_node);
+	if (!parent_irq_domain) {
+		dev_err(&pdev->dev,
+			"Failed to find interrupt parent domain of resource manager\n");
+		return -ENODEV;
+	}
+
+	rm->irq_domain = irq_domain_add_hierarchy(parent_irq_domain, 0, 0,
+						  pdev->dev.of_node,
+						  &gunyah_rm_irq_domain_ops,
+						  NULL);
+	if (!rm->irq_domain) {
+		dev_err(&pdev->dev, "Failed to add irq domain\n");
+		return -ENODEV;
+	}
+	rm->irq_domain->host_data = rm;
+
+	rm->miscdev.parent = &pdev->dev;
 	rm->miscdev.name = "gunyah";
 	rm->miscdev.minor = MISC_DYNAMIC_MINOR;
 	rm->miscdev.fops = &gunyah_dev_fops;
 
 	ret = misc_register(&rm->miscdev);
 	if (ret)
-		return ret;
+		goto err_irq_domain;
 
 	return 0;
+err_irq_domain:
+	irq_domain_remove(rm->irq_domain);
+	return ret;
 }
 
 static void gunyah_rm_remove(struct platform_device *pdev)
@@ -754,6 +925,7 @@ static void gunyah_rm_remove(struct platform_device *pdev)
 	struct gunyah_rm *rm = platform_get_drvdata(pdev);
 
 	misc_deregister(&rm->miscdev);
+	irq_domain_remove(rm->irq_domain);
 }
 
 static const struct of_device_id gunyah_rm_of_match[] = {
diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h
index ea2c9eecce0e..ecd62d0e36ad 100644
--- a/include/linux/gunyah.h
+++ b/include/linux/gunyah.h
@@ -29,6 +29,9 @@ struct gunyah_resource {
 	enum gunyah_resource_type type;
 	u64 capid;
 	unsigned int irq;
+
+	struct list_head list;
+	u32 rm_label;
 };
 
 /******************************************************************************/
diff --git a/include/linux/gunyah_rsc_mgr.h b/include/linux/gunyah_rsc_mgr.h
index 7bd2bee91f3e..0f61c2b10817 100644
--- a/include/linux/gunyah_rsc_mgr.h
+++ b/include/linux/gunyah_rsc_mgr.h
@@ -163,4 +163,9 @@ int gunyah_rm_vm_set_address_layout(struct gunyah_rm *rm, u16 vmid,
 				    enum gunyah_rm_range_id range_id,
 				    u64 base_address, u64 size);
 
+struct gunyah_resource *
+gunyah_rm_alloc_resource(struct gunyah_rm *rm,
+			 struct gunyah_rm_hyp_resource *hyp_resource);
+void gunyah_rm_free_resource(struct gunyah_resource *ghrsc);
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:57 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:57 -0800
Subject: [PATCH RFC v15 16/30] virt: gunyah: Add interfaces to map memory
 into guest address space
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-16-192a5d872a30@quicinc.com>

Gunyah virtual machines are created with all memory provided upon VM
creation using Resource Manager's memory parcel construct or by enabling
demand paging. Demand paging allows the host to map/unmap contiguous
pages (folios) on its own, typically done when a guest vCPU faults on
those pages. In order to map folios to a guest virtual machine, the
host needs to add the folio to a memory extent that can be mapped into
the guest virtual machine's address space and then map the folio into
the guest address space. Memory extents are Gunyah's mechanism for
access control and provide capability-based modifications to what memory
virtual machines are allowed to access.

When a virtual machine is configured for demand paging, 3 memory
extent and 1 address space capabilities are provided to the host. The
memory extents give the host ability to move memory between "host-only",
"guest-only", and "host-and-guest-shared" extents. The guest address
space can only map memory which is in the "guest-only" or
"host-and-guest-shared" extents. Similarly, the host address space can
only have mapped memory which is in the "host-only" or
"host-and-guest-shared" extents.

Implement two functions which Linux can use to move memory between the
virtual machines: gunyah_provide_folio and gunyah_reclaim_folio. Memory
that has been provided to the guest is tracked in a maple tree to be
reclaimed later. Folios provided to the virtual machine are assumed to
be owned Gunyah stack: the folio's ->private field is used for
bookkeeping about whether page is mapped into virtual machine.

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/Makefile     |   2 +-
 drivers/virt/gunyah/vm_mgr.c     |  60 ++++++++
 drivers/virt/gunyah/vm_mgr.h     |  30 ++++
 drivers/virt/gunyah/vm_mgr_mem.c | 314 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 405 insertions(+), 1 deletion(-)

diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index 47f1fae5419b..ccce90438434 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o vm_mgr.o
+gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o vm_mgr.o vm_mgr_mem.o
 
 obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o
diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index 8feb9302d7d2..a5450dc8cc28 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -18,6 +18,15 @@
 
 #include "vm_mgr.h"
 
+#define GUNYAH_VM_ADDRSPACE_LABEL 0
+// For memory private to guest
+#define GUNYAH_VM_MEM_EXTENT_GUEST_PRIVATE_LABEL 0
+#define GUNYAH_VM_MEM_EXTENT_HOST_SHARED_LABEL 1
+// For memory shared with the guest
+#define GUNYAH_VM_MEM_EXTENT_GUEST_SHARED_LABEL 3
+// Our own mem extent
+#define GUNYAH_VM_MEM_EXTENT_HOST_PRIVATE_LABEL 2
+
 static DEFINE_XARRAY(gunyah_vm_functions);
 
 static void gunyah_vm_put_function(struct gunyah_vm_function *fn)
@@ -185,6 +194,16 @@ void gunyah_vm_function_unregister(struct gunyah_vm_function *fn)
 }
 EXPORT_SYMBOL_GPL(gunyah_vm_function_unregister);
 
+static bool gunyah_vm_resource_ticket_populate_noop(
+	struct gunyah_vm_resource_ticket *ticket, struct gunyah_resource *ghrsc)
+{
+	return true;
+}
+static void gunyah_vm_resource_ticket_unpopulate_noop(
+	struct gunyah_vm_resource_ticket *ticket, struct gunyah_resource *ghrsc)
+{
+}
+
 int gunyah_vm_add_resource_ticket(struct gunyah_vm *ghvm,
 				  struct gunyah_vm_resource_ticket *ticket)
 {
@@ -459,6 +478,17 @@ static void gunyah_vm_stop(struct gunyah_vm *ghvm)
 		   ghvm->vm_status == GUNYAH_RM_VM_STATUS_EXITED);
 }
 
+static inline void setup_extent_ticket(struct gunyah_vm *ghvm,
+				       struct gunyah_vm_resource_ticket *ticket,
+				       u32 label)
+{
+	ticket->resource_type = GUNYAH_RESOURCE_TYPE_MEM_EXTENT;
+	ticket->label = label;
+	ticket->populate = gunyah_vm_resource_ticket_populate_noop;
+	ticket->unpopulate = gunyah_vm_resource_ticket_unpopulate_noop;
+	gunyah_vm_add_resource_ticket(ghvm, ticket);
+}
+
 static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 {
 	struct gunyah_vm *ghvm;
@@ -483,6 +513,25 @@ static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 	INIT_LIST_HEAD(&ghvm->functions);
 	mutex_init(&ghvm->fn_lock);
 
+	mt_init(&ghvm->gm);
+
+	ghvm->addrspace_ticket.resource_type = GUNYAH_RESOURCE_TYPE_ADDR_SPACE;
+	ghvm->addrspace_ticket.label = GUNYAH_VM_ADDRSPACE_LABEL;
+	ghvm->addrspace_ticket.populate =
+		gunyah_vm_resource_ticket_populate_noop;
+	ghvm->addrspace_ticket.unpopulate =
+		gunyah_vm_resource_ticket_unpopulate_noop;
+	gunyah_vm_add_resource_ticket(ghvm, &ghvm->addrspace_ticket);
+
+	setup_extent_ticket(ghvm, &ghvm->host_private_extent_ticket,
+			    GUNYAH_VM_MEM_EXTENT_HOST_PRIVATE_LABEL);
+	setup_extent_ticket(ghvm, &ghvm->host_shared_extent_ticket,
+			    GUNYAH_VM_MEM_EXTENT_HOST_SHARED_LABEL);
+	setup_extent_ticket(ghvm, &ghvm->guest_private_extent_ticket,
+			    GUNYAH_VM_MEM_EXTENT_GUEST_PRIVATE_LABEL);
+	setup_extent_ticket(ghvm, &ghvm->guest_shared_extent_ticket,
+			    GUNYAH_VM_MEM_EXTENT_GUEST_SHARED_LABEL);
+
 	return ghvm;
 }
 
@@ -642,6 +691,15 @@ static void _gunyah_vm_put(struct kref *kref)
 		gunyah_vm_stop(ghvm);
 
 	gunyah_vm_remove_functions(ghvm);
+
+	gunyah_vm_reclaim_memory(ghvm);
+
+	gunyah_vm_remove_resource_ticket(ghvm, &ghvm->addrspace_ticket);
+	gunyah_vm_remove_resource_ticket(ghvm, &ghvm->host_shared_extent_ticket);
+	gunyah_vm_remove_resource_ticket(ghvm, &ghvm->host_private_extent_ticket);
+	gunyah_vm_remove_resource_ticket(ghvm, &ghvm->guest_shared_extent_ticket);
+	gunyah_vm_remove_resource_ticket(ghvm, &ghvm->guest_private_extent_ticket);
+
 	gunyah_vm_clean_resources(ghvm);
 
 	if (ghvm->vm_status != GUNYAH_RM_VM_STATUS_NO_STATE &&
@@ -655,6 +713,8 @@ static void _gunyah_vm_put(struct kref *kref)
 			   ghvm->vm_status == GUNYAH_RM_VM_STATUS_RESET);
 	}
 
+	mtree_destroy(&ghvm->gm);
+
 	if (ghvm->vm_status > GUNYAH_RM_VM_STATUS_NO_STATE) {
 		gunyah_rm_notifier_unregister(ghvm->rm, &ghvm->nb);
 
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index a26bf81e94fc..d2f6ac212169 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -8,8 +8,10 @@
 
 #include <linux/device.h>
 #include <linux/gunyah_rsc_mgr.h>
+#include <linux/gunyah_vm_mgr.h>
 #include <linux/kref.h>
 #include <linux/list.h>
+#include <linux/maple_tree.h>
 #include <linux/mutex.h>
 #include <linux/notifier.h>
 #include <linux/rbtree.h>
@@ -18,11 +20,26 @@
 
 #include <uapi/linux/gunyah.h>
 
+static inline u64 gunyah_gpa_to_gfn(u64 gpa)
+{
+	return gpa >> PAGE_SHIFT;
+}
+
+static inline u64 gunyah_gfn_to_gpa(u64 gfn)
+{
+	return gfn << PAGE_SHIFT;
+}
+
 long gunyah_dev_vm_mgr_ioctl(struct gunyah_rm *rm, unsigned int cmd,
 			     unsigned long arg);
 
 struct gunyah_vm {
 	u16 vmid;
+	struct maple_tree gm;
+	struct gunyah_vm_resource_ticket addrspace_ticket,
+		host_private_extent_ticket, host_shared_extent_ticket,
+		guest_private_extent_ticket, guest_shared_extent_ticket;
+
 	struct gunyah_rm *rm;
 	struct device *parent;
 	enum gunyah_rm_vm_auth_mechanism auth;
@@ -44,4 +61,17 @@ struct gunyah_vm {
 
 int gunyah_vm_mmio_write(struct gunyah_vm *ghvm, u64 addr, u32 len, u64 data);
 
+int gunyah_vm_share_parcel(struct gunyah_vm *ghvm,
+			   struct gunyah_rm_mem_parcel *parcel, u64 gfn,
+			   u64 nr);
+int gunyah_vm_parcel_to_paged(struct gunyah_vm *ghvm,
+			      struct gunyah_rm_mem_parcel *parcel, u64 gfn,
+			      u64 nr);
+int gunyah_vm_reclaim_parcel(struct gunyah_vm *ghvm,
+			     struct gunyah_rm_mem_parcel *parcel, u64 gfn);
+int gunyah_vm_provide_folio(struct gunyah_vm *ghvm, struct folio *folio,
+			    u64 gfn, bool share, bool write);
+int gunyah_vm_reclaim_folio(struct gunyah_vm *ghvm, u64 gfn);
+void gunyah_vm_reclaim_memory(struct gunyah_vm *ghvm);
+
 #endif
diff --git a/drivers/virt/gunyah/vm_mgr_mem.c b/drivers/virt/gunyah/vm_mgr_mem.c
new file mode 100644
index 000000000000..d61fceeeac60
--- /dev/null
+++ b/drivers/virt/gunyah/vm_mgr_mem.c
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#define pr_fmt(fmt) "gunyah_vm_mgr: " fmt
+
+#include <asm/gunyah.h>
+#include <linux/mm.h>
+#include <linux/pagemap.h>
+
+#include "vm_mgr.h"
+
+#define WRITE_TAG (1 << 0)
+#define SHARE_TAG (1 << 1)
+#define MEM_PARCEL_TAG (1 << 2)
+
+static inline struct gunyah_resource *
+__first_resource(struct gunyah_vm_resource_ticket *ticket)
+{
+	return list_first_entry_or_null(&ticket->resources,
+					struct gunyah_resource, list);
+}
+
+int gunyah_vm_share_parcel(struct gunyah_vm *ghvm,
+			   struct gunyah_rm_mem_parcel *parcel, u64 gfn, u64 nr)
+{
+	int ret;
+
+	ret = mtree_insert_range(&ghvm->gm, gfn, gfn + nr - 1,
+				 xa_tag_pointer(parcel, MEM_PARCEL_TAG),
+				 GFP_KERNEL);
+	if (ret)
+		return ret;
+
+	ret = gunyah_rm_mem_share(ghvm->rm, parcel);
+	if (ret)
+		mtree_erase(&ghvm->gm, gfn);
+
+	return ret;
+}
+
+int gunyah_vm_parcel_to_paged(struct gunyah_vm *ghvm,
+			      struct gunyah_rm_mem_parcel *parcel, u64 gfn,
+			      u64 nr)
+{
+	struct gunyah_rm_mem_entry *entry;
+	struct folio *folio;
+	unsigned long g, e, tag = 0;
+	pgoff_t off;
+	int ret;
+
+	if (parcel->n_acl_entries > 1)
+		tag |= SHARE_TAG;
+	if (parcel->acl_entries[0].perms & GUNYAH_RM_ACL_W)
+		tag |= WRITE_TAG;
+
+	for (e = 0, g = gfn; g < gfn + nr && e < parcel->n_mem_entries; e++) {
+		entry = &parcel->mem_entries[e];
+		folio = pfn_folio(PHYS_PFN(entry->phys_addr));
+
+		for (off = 0; off < PHYS_PFN(entry->size);
+		     off += folio_nr_pages(folio)) {
+			ret = mtree_store_range(&ghvm->gm, g + off, g + off - 1,
+						xa_tag_pointer(folio, tag),
+						GFP_KERNEL);
+			if (ret == -ENOMEM)
+				return ret;
+			BUG_ON(ret);
+
+			folio = folio_next(folio);
+		}
+	}
+
+	return 0;
+}
+
+int gunyah_vm_reclaim_parcel(struct gunyah_vm *ghvm,
+			     struct gunyah_rm_mem_parcel *parcel, u64 gfn)
+{
+	int ret;
+
+	ret = gunyah_rm_mem_reclaim(ghvm->rm, parcel);
+	if (ret)
+		return ret;
+
+	mtree_erase(&ghvm->gm, gfn);
+
+	return ret;
+}
+
+static inline u32 donate_flags(bool share)
+{
+	if (share)
+		return FIELD_PREP_CONST(GUNYAH_MEMEXTENT_OPTION_TYPE_MASK,
+					GUNYAH_MEMEXTENT_DONATE_TO_SIBLING);
+	else
+		return FIELD_PREP_CONST(GUNYAH_MEMEXTENT_OPTION_TYPE_MASK,
+					GUNYAH_MEMEXTENT_DONATE_TO_PROTECTED);
+}
+
+static inline u32 reclaim_flags(bool share)
+{
+	if (share)
+		return FIELD_PREP_CONST(GUNYAH_MEMEXTENT_OPTION_TYPE_MASK,
+					GUNYAH_MEMEXTENT_DONATE_TO_SIBLING);
+	else
+		return FIELD_PREP_CONST(GUNYAH_MEMEXTENT_OPTION_TYPE_MASK,
+					GUNYAH_MEMEXTENT_DONATE_FROM_PROTECTED);
+}
+
+int gunyah_vm_provide_folio(struct gunyah_vm *ghvm, struct folio *folio,
+			    u64 gfn, bool share, bool write)
+{
+	struct gunyah_resource *guest_extent, *host_extent, *addrspace;
+	u32 map_flags = BIT(GUNYAH_ADDRSPACE_MAP_FLAG_PARTIAL);
+	u64 extent_attrs, gpa = gunyah_gfn_to_gpa(gfn);
+	phys_addr_t pa = PFN_PHYS(folio_pfn(folio));
+	enum gunyah_pagetable_access access;
+	size_t size = folio_size(folio);
+	enum gunyah_error gunyah_error;
+	unsigned long tag = 0;
+	int ret;
+
+	if (share) {
+		guest_extent = __first_resource(&ghvm->guest_shared_extent_ticket);
+		host_extent = __first_resource(&ghvm->host_shared_extent_ticket);
+	} else {
+		guest_extent = __first_resource(&ghvm->guest_private_extent_ticket);
+		host_extent = __first_resource(&ghvm->host_private_extent_ticket);
+	}
+	addrspace = __first_resource(&ghvm->addrspace_ticket);
+
+	if (!addrspace || !guest_extent || !host_extent)
+		return -ENODEV;
+
+	if (share) {
+		map_flags |= BIT(GUNYAH_ADDRSPACE_MAP_FLAG_VMMIO);
+		tag |= SHARE_TAG;
+	} else {
+		map_flags |= BIT(GUNYAH_ADDRSPACE_MAP_FLAG_PRIVATE);
+	}
+
+	if (write)
+		tag |= WRITE_TAG;
+
+	ret = mtree_insert_range(&ghvm->gm, gfn,
+				 gfn + folio_nr_pages(folio) - 1,
+				 xa_tag_pointer(folio, tag), GFP_KERNEL);
+	if (ret)
+		return ret;
+
+	if (share && write)
+		access = GUNYAH_PAGETABLE_ACCESS_RW;
+	else if (share && !write)
+		access = GUNYAH_PAGETABLE_ACCESS_R;
+	else if (!share && write)
+		access = GUNYAH_PAGETABLE_ACCESS_RWX;
+	else /* !share && !write */
+		access = GUNYAH_PAGETABLE_ACCESS_RX;
+
+	gunyah_error = gunyah_hypercall_memextent_donate(donate_flags(share),
+							 host_extent->capid,
+							 guest_extent->capid,
+							 pa, size);
+	if (gunyah_error != GUNYAH_ERROR_OK) {
+		pr_err("Failed to donate memory for guest address 0x%016llx: %d\n",
+		       gpa, gunyah_error);
+		ret = gunyah_error_remap(gunyah_error);
+		goto remove;
+	}
+
+	extent_attrs =
+		FIELD_PREP_CONST(GUNYAH_MEMEXTENT_MAPPING_TYPE,
+				 ARCH_GUNYAH_DEFAULT_MEMTYPE) |
+		FIELD_PREP(GUNYAH_MEMEXTENT_MAPPING_USER_ACCESS, access) |
+		FIELD_PREP(GUNYAH_MEMEXTENT_MAPPING_KERNEL_ACCESS, access);
+	gunyah_error = gunyah_hypercall_addrspace_map(addrspace->capid,
+						      guest_extent->capid, gpa,
+						      extent_attrs, map_flags,
+						      pa, size);
+	if (gunyah_error != GUNYAH_ERROR_OK) {
+		pr_err("Failed to map guest address 0x%016llx: %d\n", gpa,
+		       gunyah_error);
+		ret = gunyah_error_remap(gunyah_error);
+		goto memextent_reclaim;
+	}
+
+	folio_get(folio);
+	return 0;
+memextent_reclaim:
+	gunyah_error = gunyah_hypercall_memextent_donate(reclaim_flags(share),
+							 guest_extent->capid,
+							 host_extent->capid, pa,
+							 size);
+	if (gunyah_error != GUNYAH_ERROR_OK)
+		pr_err("Failed to reclaim memory donation for guest address 0x%016llx: %d\n",
+		       gpa, gunyah_error);
+remove:
+	mtree_erase(&ghvm->gm, gfn);
+	return ret;
+}
+
+int gunyah_vm_reclaim_folio(struct gunyah_vm *ghvm, u64 gfn)
+{
+	const u32 map_flags = BIT(GUNYAH_ADDRSPACE_MAP_FLAG_PARTIAL);
+	struct gunyah_resource *guest_extent, *host_extent, *addrspace;
+	enum gunyah_pagetable_access access;
+	enum gunyah_error gunyah_error;
+	struct folio *folio;
+	bool write, share;
+	phys_addr_t pa;
+	size_t size;
+	void *entry;
+	int ret;
+
+	addrspace = __first_resource(&ghvm->addrspace_ticket);
+	if (!addrspace)
+		return -ENODEV;
+
+	entry = mtree_load(&ghvm->gm, gfn);
+	if (!entry)
+		return 0;
+
+	share = !!(xa_pointer_tag(entry) & SHARE_TAG);
+	write = !!(xa_pointer_tag(entry) & WRITE_TAG);
+	folio = xa_untag_pointer(entry);
+	folio_lock(folio);
+	if (mtree_load(&ghvm->gm, gfn) != entry) {
+		ret = -EAGAIN;
+		goto err;
+	}
+
+	if (share) {
+		guest_extent = __first_resource(&ghvm->guest_shared_extent_ticket);
+		host_extent = __first_resource(&ghvm->host_shared_extent_ticket);
+	} else {
+		guest_extent = __first_resource(&ghvm->guest_private_extent_ticket);
+		host_extent = __first_resource(&ghvm->host_private_extent_ticket);
+	}
+
+	pa = PFN_PHYS(folio_pfn(folio));
+	size = folio_size(folio);
+
+	gunyah_error = gunyah_hypercall_addrspace_unmap(addrspace->capid,
+							guest_extent->capid,
+							gfn << PAGE_SHIFT,
+							map_flags, pa, size);
+	if (gunyah_error != GUNYAH_ERROR_OK) {
+		ret = gunyah_error_remap(gunyah_error);
+		goto err;
+	}
+
+	gunyah_error = gunyah_hypercall_memextent_donate(reclaim_flags(share),
+							 guest_extent->capid,
+							 host_extent->capid, pa,
+							 size);
+	if (gunyah_error != GUNYAH_ERROR_OK) {
+		pr_err_ratelimited(
+			"Failed to reclaim memory donation for guest address 0x%016llx: %d\n",
+			gunyah_gfn_to_gpa(gfn), gunyah_error);
+		ret = gunyah_error_remap(gunyah_error);
+		goto err;
+	}
+
+	if (share && write)
+		access = GUNYAH_PAGETABLE_ACCESS_RW;
+	else if (share && !write)
+		access = GUNYAH_PAGETABLE_ACCESS_R;
+	else if (!share && write)
+		access = GUNYAH_PAGETABLE_ACCESS_RWX;
+	else /* !share && !write */
+		access = GUNYAH_PAGETABLE_ACCESS_RX;
+
+	gunyah_error = gunyah_hypercall_memextent_donate(donate_flags(share),
+							 guest_extent->capid,
+							 host_extent->capid, pa,
+							 size);
+	if (gunyah_error != GUNYAH_ERROR_OK) {
+		pr_err("Failed to reclaim memory donation for guest address 0x%016llx: %d\n",
+		       gfn << PAGE_SHIFT, gunyah_error);
+		ret = gunyah_error_remap(gunyah_error);
+		goto err;
+	}
+
+	BUG_ON(mtree_erase(&ghvm->gm, gfn) != entry);
+
+	folio_unlock(folio);
+	folio_put(folio);
+	return 0;
+err:
+	folio_unlock(folio);
+	return ret;
+}
+
+void gunyah_vm_reclaim_memory(struct gunyah_vm *ghvm)
+{
+	unsigned long gfn = 0;
+	void *entry;
+	int ret = 0;
+
+	mt_for_each(&ghvm->gm, entry, gfn, ULONG_MAX) {
+		if (xa_pointer_tag(entry) == MEM_PARCEL_TAG) {
+			ret = gunyah_vm_reclaim_parcel(
+				ghvm, xa_untag_pointer(entry), gfn);
+			if (ret)
+				dev_err(ghvm->parent,
+					"Failed to reclaim guest parcel at %lx: %d\n",
+					gfn << PAGE_SHIFT, ret);
+		} else {
+			gunyah_vm_reclaim_folio(ghvm, gfn);
+		}
+	}
+}

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:04 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:04 -0800
Subject: [PATCH RFC v15 23/30] virt: gunyah: Allow userspace to initialize
 context of primary vCPU
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-23-192a5d872a30@quicinc.com>

RM provides APIs to fill boot context the initial registers upon
starting the vCPU.

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/vm_mgr.c | 75 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/virt/gunyah/vm_mgr.h |  1 +
 include/uapi/linux/gunyah.h  | 23 ++++++++++++++
 3 files changed, 99 insertions(+)

diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index 5666070453aa..a31a9f0a642c 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -542,6 +542,66 @@ static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 	return ghvm;
 }
 
+static long gunyah_vm_set_boot_context(struct gunyah_vm *ghvm,
+				       struct gunyah_vm_boot_context *boot_ctx)
+{
+	u8 reg_set, reg_index; /* to check values are reasonable */
+	int ret;
+
+	reg_set = (boot_ctx->reg >> GUNYAH_VM_BOOT_CONTEXT_REG_SHIFT) & 0xff;
+	reg_index = boot_ctx->reg & 0xff;
+
+	switch (reg_set) {
+	case REG_SET_X:
+		if (reg_index > 31)
+			return -EINVAL;
+		break;
+	case REG_SET_PC:
+		if (reg_index)
+			return -EINVAL;
+		break;
+	case REG_SET_SP:
+		if (reg_index > 2)
+			return -EINVAL;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	ret = down_read_interruptible(&ghvm->status_lock);
+	if (ret)
+		return ret;
+
+	if (ghvm->vm_status != GUNYAH_RM_VM_STATUS_NO_STATE) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	ret = xa_err(xa_store(&ghvm->boot_context, boot_ctx->reg,
+			      (void *)boot_ctx->value, GFP_KERNEL));
+out:
+	up_read(&ghvm->status_lock);
+	return ret;
+}
+
+static inline int gunyah_vm_fill_boot_context(struct gunyah_vm *ghvm)
+{
+	unsigned long reg_set, reg_index, id;
+	void *entry;
+	int ret;
+
+	xa_for_each(&ghvm->boot_context, id, entry) {
+		reg_set = (id >> GUNYAH_VM_BOOT_CONTEXT_REG_SHIFT) & 0xff;
+		reg_index = id & 0xff;
+		ret = gunyah_rm_vm_set_boot_context(
+			ghvm->rm, ghvm->vmid, reg_set, reg_index, (u64)entry);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
 static int gunyah_vm_start(struct gunyah_vm *ghvm)
 {
 	struct gunyah_rm_hyp_resources *resources;
@@ -582,6 +642,13 @@ static int gunyah_vm_start(struct gunyah_vm *ghvm)
 	}
 	ghvm->vm_status = GUNYAH_RM_VM_STATUS_READY;
 
+	ret = gunyah_vm_fill_boot_context(ghvm);
+	if (ret) {
+		dev_warn(ghvm->parent, "Failed to setup boot context: %d\n",
+			 ret);
+		goto err;
+	}
+
 	ret = gunyah_rm_get_hyp_resources(ghvm->rm, ghvm->vmid, &resources);
 	if (ret) {
 		dev_warn(ghvm->parent,
@@ -683,6 +750,14 @@ static long gunyah_vm_ioctl(struct file *filp, unsigned int cmd,
 
 		return gunyah_gmem_modify_binding(ghvm, &args);
 	}
+	case GUNYAH_VM_SET_BOOT_CONTEXT: {
+		struct gunyah_vm_boot_context boot_ctx;
+
+		if (copy_from_user(&boot_ctx, argp, sizeof(boot_ctx)))
+			return -EFAULT;
+
+		return gunyah_vm_set_boot_context(ghvm, &boot_ctx);
+	}
 	default:
 		r = -ENOTTY;
 		break;
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index 1cad729b017a..a7fc7c376d1e 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -60,6 +60,7 @@ struct gunyah_vm {
 	struct list_head resource_tickets;
 	struct rb_root mmio_handler_root;
 	struct rw_semaphore mmio_handler_lock;
+	struct xarray boot_context;
 };
 
 int gunyah_vm_mmio_write(struct gunyah_vm *ghvm, u64 addr, u32 len, u64 data);
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
index 1af4c5ae6bc3..a171185191ae 100644
--- a/include/uapi/linux/gunyah.h
+++ b/include/uapi/linux/gunyah.h
@@ -128,6 +128,29 @@ struct gunyah_map_mem_args {
 
 #define GUNYAH_VM_MAP_MEM _IOW(GUNYAH_IOCTL_TYPE, 0x9, struct gunyah_map_mem_args)
 
+enum gunyah_vm_boot_context_reg {
+	REG_SET_X		= 0,
+	REG_SET_PC		= 1,
+	REG_SET_SP		= 2,
+};
+
+#define GUNYAH_VM_BOOT_CONTEXT_REG_SHIFT	8
+#define GUNYAH_VM_BOOT_CONTEXT_REG(reg, idx) (((reg & 0xff) << GUNYAH_VM_BOOT_CONTEXT_REG_SHIFT) |\
+					      (idx & 0xff))
+
+/**
+ * struct gunyah_vm_boot_context - Set an initial register for the VM
+ * @reg: Register to set. See GUNYAH_VM_BOOT_CONTEXT_REG_* macros
+ * @reserved: reserved for alignment
+ * @value: value to fill in the register
+ */
+struct gunyah_vm_boot_context {
+	__u32 reg;
+	__u32 reserved;
+	__u64 value;
+};
+#define GUNYAH_VM_SET_BOOT_CONTEXT	_IOW(GUNYAH_IOCTL_TYPE, 0xa, struct gunyah_vm_boot_context)
+
 /*
  * ioctls for vCPU fds
  */

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:20:58 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:20:58 -0800
Subject: [PATCH RFC v15 17/30] gunyah: rsc_mgr: Add platform ops on
 mem_lend/mem_reclaim
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-17-192a5d872a30@quicinc.com>

On Qualcomm platforms, there is a firmware entity which controls access
to physical pages. In order to share memory with another VM, this entity
needs to be informed that the guest VM should have access to the memory.

Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/Kconfig                 |   4 +
 drivers/virt/gunyah/Makefile                |   1 +
 drivers/virt/gunyah/gunyah_platform_hooks.c | 115 ++++++++++++++++++++++++++++
 drivers/virt/gunyah/rsc_mgr.h               |  10 +++
 drivers/virt/gunyah/rsc_mgr_rpc.c           |  20 ++++-
 drivers/virt/gunyah/vm_mgr_mem.c            |  32 +++++---
 include/linux/gunyah_rsc_mgr.h              |  37 +++++++++
 7 files changed, 206 insertions(+), 13 deletions(-)

diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig
index 6f4c85db80b5..23ba523d25dc 100644
--- a/drivers/virt/gunyah/Kconfig
+++ b/drivers/virt/gunyah/Kconfig
@@ -3,6 +3,7 @@
 config GUNYAH
 	tristate "Gunyah Virtualization drivers"
 	depends on ARM64
+	select GUNYAH_PLATFORM_HOOKS
 	help
 	  The Gunyah drivers are the helper interfaces that run in a guest VM
 	  such as basic inter-VM IPC and signaling mechanisms, and higher level
@@ -10,3 +11,6 @@ config GUNYAH
 
 	  Say Y/M here to enable the drivers needed to interact in a Gunyah
 	  virtual environment.
+
+config GUNYAH_PLATFORM_HOOKS
+	tristate
diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index ccce90438434..09e0fbca33fe 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -3,3 +3,4 @@
 gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o vm_mgr.o vm_mgr_mem.o
 
 obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o
+obj-$(CONFIG_GUNYAH_PLATFORM_HOOKS) += gunyah_platform_hooks.o
diff --git a/drivers/virt/gunyah/gunyah_platform_hooks.c b/drivers/virt/gunyah/gunyah_platform_hooks.c
new file mode 100644
index 000000000000..d2d6df21b784
--- /dev/null
+++ b/drivers/virt/gunyah/gunyah_platform_hooks.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/rwsem.h>
+#include <linux/gunyah_rsc_mgr.h>
+
+#include "rsc_mgr.h"
+
+static const struct gunyah_rm_platform_ops *rm_platform_ops;
+static DECLARE_RWSEM(rm_platform_ops_lock);
+
+int gunyah_rm_platform_pre_mem_share(struct gunyah_rm *rm,
+				     struct gunyah_rm_mem_parcel *mem_parcel)
+{
+	int ret = 0;
+
+	down_read(&rm_platform_ops_lock);
+	if (rm_platform_ops && rm_platform_ops->pre_mem_share)
+		ret = rm_platform_ops->pre_mem_share(rm, mem_parcel);
+	up_read(&rm_platform_ops_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_platform_pre_mem_share);
+
+int gunyah_rm_platform_post_mem_reclaim(struct gunyah_rm *rm,
+					struct gunyah_rm_mem_parcel *mem_parcel)
+{
+	int ret = 0;
+
+	down_read(&rm_platform_ops_lock);
+	if (rm_platform_ops && rm_platform_ops->post_mem_reclaim)
+		ret = rm_platform_ops->post_mem_reclaim(rm, mem_parcel);
+	up_read(&rm_platform_ops_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_platform_post_mem_reclaim);
+
+int gunyah_rm_platform_pre_demand_page(struct gunyah_rm *rm, u16 vmid,
+				       u32 flags, struct folio *folio)
+{
+	int ret = 0;
+
+	down_read(&rm_platform_ops_lock);
+	if (rm_platform_ops && rm_platform_ops->pre_demand_page)
+		ret = rm_platform_ops->pre_demand_page(rm, vmid, flags, folio);
+	up_read(&rm_platform_ops_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_platform_pre_demand_page);
+
+int gunyah_rm_platform_reclaim_demand_page(struct gunyah_rm *rm, u16 vmid,
+					   u32 flags, struct folio *folio)
+{
+	int ret = 0;
+
+	down_read(&rm_platform_ops_lock);
+	if (rm_platform_ops && rm_platform_ops->pre_demand_page)
+		ret = rm_platform_ops->release_demand_page(rm, vmid, flags,
+							   folio);
+	up_read(&rm_platform_ops_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_platform_reclaim_demand_page);
+
+int gunyah_rm_register_platform_ops(
+	const struct gunyah_rm_platform_ops *platform_ops)
+{
+	int ret = 0;
+
+	down_write(&rm_platform_ops_lock);
+	if (!rm_platform_ops)
+		rm_platform_ops = platform_ops;
+	else
+		ret = -EEXIST;
+	up_write(&rm_platform_ops_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_register_platform_ops);
+
+void gunyah_rm_unregister_platform_ops(
+	const struct gunyah_rm_platform_ops *platform_ops)
+{
+	down_write(&rm_platform_ops_lock);
+	if (rm_platform_ops == platform_ops)
+		rm_platform_ops = NULL;
+	up_write(&rm_platform_ops_lock);
+}
+EXPORT_SYMBOL_GPL(gunyah_rm_unregister_platform_ops);
+
+static void _devm_gunyah_rm_unregister_platform_ops(void *data)
+{
+	gunyah_rm_unregister_platform_ops(
+		(const struct gunyah_rm_platform_ops *)data);
+}
+
+int devm_gunyah_rm_register_platform_ops(
+	struct device *dev, const struct gunyah_rm_platform_ops *ops)
+{
+	int ret;
+
+	ret = gunyah_rm_register_platform_ops(ops);
+	if (ret)
+		return ret;
+
+	return devm_add_action(dev, _devm_gunyah_rm_unregister_platform_ops,
+			       (void *)ops);
+}
+EXPORT_SYMBOL_GPL(devm_gunyah_rm_register_platform_ops);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Gunyah Platform Hooks");
diff --git a/drivers/virt/gunyah/rsc_mgr.h b/drivers/virt/gunyah/rsc_mgr.h
index 4ce6ec3668d4..65ffcb63754a 100644
--- a/drivers/virt/gunyah/rsc_mgr.h
+++ b/drivers/virt/gunyah/rsc_mgr.h
@@ -15,4 +15,14 @@ int gunyah_rm_call(struct gunyah_rm *rsc_mgr, u32 message_id,
 		   const void *req_buf, size_t req_buf_size, void **resp_buf,
 		   size_t *resp_buf_size);
 
+int gunyah_rm_platform_pre_mem_share(struct gunyah_rm *rm,
+				     struct gunyah_rm_mem_parcel *mem_parcel);
+int gunyah_rm_platform_post_mem_reclaim(
+	struct gunyah_rm *rm, struct gunyah_rm_mem_parcel *mem_parcel);
+
+int gunyah_rm_platform_pre_demand_page(struct gunyah_rm *rm, u16 vmid,
+				       u32 flags, struct folio *folio);
+int gunyah_rm_platform_reclaim_demand_page(struct gunyah_rm *rm, u16 vmid,
+					   u32 flags, struct folio *folio);
+
 #endif
diff --git a/drivers/virt/gunyah/rsc_mgr_rpc.c b/drivers/virt/gunyah/rsc_mgr_rpc.c
index 9954512dbdde..ce68933f9968 100644
--- a/drivers/virt/gunyah/rsc_mgr_rpc.c
+++ b/drivers/virt/gunyah/rsc_mgr_rpc.c
@@ -241,6 +241,12 @@ int gunyah_rm_mem_share(struct gunyah_rm *rm, struct gunyah_rm_mem_parcel *p)
 	if (!msg)
 		return -ENOMEM;
 
+	ret = gunyah_rm_platform_pre_mem_share(rm, p);
+	if (ret) {
+		kfree(msg);
+		return ret;
+	}
+
 	req_header = msg;
 	acl = (void *)req_header + sizeof(*req_header);
 	mem = (void *)acl + acl_size;
@@ -266,8 +272,10 @@ int gunyah_rm_mem_share(struct gunyah_rm *rm, struct gunyah_rm_mem_parcel *p)
 			     &resp_size);
 	kfree(msg);
 
-	if (ret)
+	if (ret) {
+		gunyah_rm_platform_post_mem_reclaim(rm, p);
 		return ret;
+	}
 
 	p->mem_handle = le32_to_cpu(*resp);
 	kfree(resp);
@@ -298,9 +306,15 @@ int gunyah_rm_mem_reclaim(struct gunyah_rm *rm,
 	struct gunyah_rm_mem_release_req req = {
 		.mem_handle = cpu_to_le32(parcel->mem_handle),
 	};
+	int ret;
 
-	return gunyah_rm_call(rm, GUNYAH_RM_RPC_MEM_RECLAIM, &req, sizeof(req),
-			      NULL, NULL);
+	ret = gunyah_rm_call(rm, GUNYAH_RM_RPC_MEM_RECLAIM, &req, sizeof(req),
+			     NULL, NULL);
+	/* Only call platform mem reclaim hooks if we reclaimed the memory */
+	if (ret)
+		return ret;
+
+	return gunyah_rm_platform_post_mem_reclaim(rm, parcel);
 }
 
 /**
diff --git a/drivers/virt/gunyah/vm_mgr_mem.c b/drivers/virt/gunyah/vm_mgr_mem.c
index d61fceeeac60..e1675633804f 100644
--- a/drivers/virt/gunyah/vm_mgr_mem.c
+++ b/drivers/virt/gunyah/vm_mgr_mem.c
@@ -9,6 +9,7 @@
 #include <linux/mm.h>
 #include <linux/pagemap.h>
 
+#include "rsc_mgr.h"
 #include "vm_mgr.h"
 
 #define WRITE_TAG (1 << 0)
@@ -120,7 +121,7 @@ int gunyah_vm_provide_folio(struct gunyah_vm *ghvm, struct folio *folio,
 	size_t size = folio_size(folio);
 	enum gunyah_error gunyah_error;
 	unsigned long tag = 0;
-	int ret;
+	int ret, tmp;
 
 	if (share) {
 		guest_extent = __first_resource(&ghvm->guest_shared_extent_ticket);
@@ -159,6 +160,11 @@ int gunyah_vm_provide_folio(struct gunyah_vm *ghvm, struct folio *folio,
 	else /* !share && !write */
 		access = GUNYAH_PAGETABLE_ACCESS_RX;
 
+	ret = gunyah_rm_platform_pre_demand_page(ghvm->rm, ghvm->vmid, access,
+						 folio);
+	if (ret)
+		goto remove;
+
 	gunyah_error = gunyah_hypercall_memextent_donate(donate_flags(share),
 							 host_extent->capid,
 							 guest_extent->capid,
@@ -167,7 +173,7 @@ int gunyah_vm_provide_folio(struct gunyah_vm *ghvm, struct folio *folio,
 		pr_err("Failed to donate memory for guest address 0x%016llx: %d\n",
 		       gpa, gunyah_error);
 		ret = gunyah_error_remap(gunyah_error);
-		goto remove;
+		goto platform_release;
 	}
 
 	extent_attrs =
@@ -196,6 +202,14 @@ int gunyah_vm_provide_folio(struct gunyah_vm *ghvm, struct folio *folio,
 	if (gunyah_error != GUNYAH_ERROR_OK)
 		pr_err("Failed to reclaim memory donation for guest address 0x%016llx: %d\n",
 		       gpa, gunyah_error);
+platform_release:
+	tmp = gunyah_rm_platform_reclaim_demand_page(ghvm->rm, ghvm->vmid,
+						     access, folio);
+	if (tmp) {
+		pr_err("Platform failed to reclaim memory for guest address 0x%016llx: %d",
+		       gpa, tmp);
+		return ret;
+	}
 remove:
 	mtree_erase(&ghvm->gm, gfn);
 	return ret;
@@ -272,14 +286,12 @@ int gunyah_vm_reclaim_folio(struct gunyah_vm *ghvm, u64 gfn)
 	else /* !share && !write */
 		access = GUNYAH_PAGETABLE_ACCESS_RX;
 
-	gunyah_error = gunyah_hypercall_memextent_donate(donate_flags(share),
-							 guest_extent->capid,
-							 host_extent->capid, pa,
-							 size);
-	if (gunyah_error != GUNYAH_ERROR_OK) {
-		pr_err("Failed to reclaim memory donation for guest address 0x%016llx: %d\n",
-		       gfn << PAGE_SHIFT, gunyah_error);
-		ret = gunyah_error_remap(gunyah_error);
+	ret = gunyah_rm_platform_reclaim_demand_page(ghvm->rm, ghvm->vmid,
+						     access, folio);
+	if (ret) {
+		pr_err_ratelimited(
+			"Platform failed to reclaim memory for guest address 0x%016llx: %d",
+			gunyah_gfn_to_gpa(gfn), ret);
 		goto err;
 	}
 
diff --git a/include/linux/gunyah_rsc_mgr.h b/include/linux/gunyah_rsc_mgr.h
index 0f61c2b10817..f177f8dbcd4c 100644
--- a/include/linux/gunyah_rsc_mgr.h
+++ b/include/linux/gunyah_rsc_mgr.h
@@ -168,4 +168,41 @@ gunyah_rm_alloc_resource(struct gunyah_rm *rm,
 			 struct gunyah_rm_hyp_resource *hyp_resource);
 void gunyah_rm_free_resource(struct gunyah_resource *ghrsc);
 
+struct gunyah_rm_platform_ops {
+	int (*pre_mem_share)(struct gunyah_rm *rm,
+			     struct gunyah_rm_mem_parcel *mem_parcel);
+	int (*post_mem_reclaim)(struct gunyah_rm *rm,
+				struct gunyah_rm_mem_parcel *mem_parcel);
+
+	int (*pre_demand_page)(struct gunyah_rm *rm, u16 vmid, u32 flags,
+			       struct folio *folio);
+	int (*release_demand_page)(struct gunyah_rm *rm, u16 vmid, u32 flags,
+				   struct folio *folio);
+};
+
+#if IS_ENABLED(CONFIG_GUNYAH_PLATFORM_HOOKS)
+int gunyah_rm_register_platform_ops(
+	const struct gunyah_rm_platform_ops *platform_ops);
+void gunyah_rm_unregister_platform_ops(
+	const struct gunyah_rm_platform_ops *platform_ops);
+int devm_gunyah_rm_register_platform_ops(
+	struct device *dev, const struct gunyah_rm_platform_ops *ops);
+#else
+static inline int gunyah_rm_register_platform_ops(
+	const struct gunyah_rm_platform_ops *platform_ops)
+{
+	return 0;
+}
+static inline void gunyah_rm_unregister_platform_ops(
+	const struct gunyah_rm_platform_ops *platform_ops)
+{
+}
+static inline int
+devm_gunyah_rm_register_platform_ops(struct device *dev,
+				     const struct gunyah_rm_platform_ops *ops)
+{
+	return 0;
+}
+#endif
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:01 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:01 -0800
Subject: [PATCH RFC v15 20/30] virt: gunyah: Implement guestmemfd
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-20-192a5d872a30@quicinc.com>

Memory provided to Gunyah virtual machines are provided by a
Gunyah guestmemfd. Because memory provided to virtual machines may be
unmapped at stage-2 from the host (i.e. in the hypervisor's page tables
for the host), special care needs to be taken to ensure that the kernel
doesn't have a page mapped when it is lent to the guest. Without this
tracking, a kernel panic could be induced  by userspace tricking the
kernel into accessing guest-private memory.

Introduce the basic guestmemfd ops and ioctl. Userspace should be able
to access the memory unless it is provided to the guest virtual machine:
this is necessary to allow userspace to preload binaries such as the
kernel Image prior to running the VM. Subsequent commits will wire up
providing the memory to the guest.

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/Makefile      |   2 +-
 drivers/virt/gunyah/guest_memfd.c | 269 ++++++++++++++++++++++++++++++++++++++
 drivers/virt/gunyah/vm_mgr.c      |   9 ++
 drivers/virt/gunyah/vm_mgr.h      |   2 +
 include/uapi/linux/gunyah.h       |  19 +++
 5 files changed, 300 insertions(+), 1 deletion(-)

diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index ffcde0e0ccfa..9d514b2baa3a 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 
-gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o vm_mgr.o vm_mgr_mem.o
+gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o vm_mgr.o vm_mgr_mem.o guest_memfd.o
 
 obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o gunyah_vcpu.o
 obj-$(CONFIG_GUNYAH_PLATFORM_HOOKS) += gunyah_platform_hooks.o
diff --git a/drivers/virt/gunyah/guest_memfd.c b/drivers/virt/gunyah/guest_memfd.c
new file mode 100644
index 000000000000..709aae9a1f44
--- /dev/null
+++ b/drivers/virt/gunyah/guest_memfd.c
@@ -0,0 +1,269 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#define pr_fmt(fmt) "gunyah_guest_mem: " fmt
+
+#include <linux/anon_inodes.h>
+#include <linux/types.h>
+#include <linux/falloc.h>
+#include <linux/file.h>
+#include <linux/migrate.h>
+#include <linux/pagemap.h>
+
+#include <uapi/linux/gunyah.h>
+
+static struct folio *gunyah_gmem_get_huge_folio(struct inode *inode,
+						pgoff_t index)
+{
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+	unsigned long huge_index = round_down(index, HPAGE_PMD_NR);
+	unsigned long flags = (unsigned long)inode->i_private;
+	struct address_space *mapping = inode->i_mapping;
+	gfp_t gfp = mapping_gfp_mask(mapping);
+	struct folio *folio;
+
+	if (!(flags & GHMF_ALLOW_HUGEPAGE))
+		return NULL;
+
+	if (filemap_range_has_page(mapping, huge_index << PAGE_SHIFT,
+				   (huge_index + HPAGE_PMD_NR - 1)
+					   << PAGE_SHIFT))
+		return NULL;
+
+	folio = filemap_alloc_folio(gfp, HPAGE_PMD_ORDER);
+	if (!folio)
+		return NULL;
+
+	if (filemap_add_folio(mapping, folio, huge_index, gfp)) {
+		folio_put(folio);
+		return NULL;
+	}
+
+	return folio;
+#else
+	return NULL;
+#endif
+}
+
+static struct folio *gunyah_gmem_get_folio(struct inode *inode, pgoff_t index)
+{
+	struct folio *folio;
+
+	folio = gunyah_gmem_get_huge_folio(inode, index);
+	if (!folio) {
+		folio = filemap_grab_folio(inode->i_mapping, index);
+		if (IS_ERR_OR_NULL(folio))
+			return NULL;
+	}
+
+	/*
+	 * Use the up-to-date flag to track whether or not the memory has been
+	 * zeroed before being handed off to the guest.  There is no backing
+	 * storage for the memory, so the folio will remain up-to-date until
+	 * it's removed.
+	 */
+	if (!folio_test_uptodate(folio)) {
+		unsigned long nr_pages = folio_nr_pages(folio);
+		unsigned long i;
+
+		for (i = 0; i < nr_pages; i++)
+			clear_highpage(folio_page(folio, i));
+
+		folio_mark_uptodate(folio);
+	}
+
+	/*
+	 * Ignore accessed, referenced, and dirty flags.  The memory is
+	 * unevictable and there is no storage to write back to.
+	 */
+	return folio;
+}
+
+static vm_fault_t gunyah_gmem_host_fault(struct vm_fault *vmf)
+{
+	struct folio *folio;
+
+	folio = gunyah_gmem_get_folio(file_inode(vmf->vma->vm_file),
+				      vmf->pgoff);
+	if (!folio || folio_test_private(folio)) {
+		folio_unlock(folio);
+		folio_put(folio);
+		return VM_FAULT_SIGBUS;
+	}
+
+	vmf->page = folio_file_page(folio, vmf->pgoff);
+
+	return VM_FAULT_LOCKED;
+}
+
+static const struct vm_operations_struct gunyah_gmem_vm_ops = {
+	.fault = gunyah_gmem_host_fault,
+};
+
+static int gunyah_gmem_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	file_accessed(file);
+	vma->vm_ops = &gunyah_gmem_vm_ops;
+	return 0;
+}
+
+static long gunyah_gmem_punch_hole(struct inode *inode, loff_t offset,
+				   loff_t len)
+{
+	truncate_inode_pages_range(inode->i_mapping, offset, offset + len - 1);
+
+	return 0;
+}
+
+static long gunyah_gmem_allocate(struct inode *inode, loff_t offset, loff_t len)
+{
+	struct address_space *mapping = inode->i_mapping;
+	pgoff_t start, index, end;
+	int r;
+
+	/* Dedicated guest is immutable by default. */
+	if (offset + len > i_size_read(inode))
+		return -EINVAL;
+
+	filemap_invalidate_lock_shared(mapping);
+
+	start = offset >> PAGE_SHIFT;
+	end = (offset + len) >> PAGE_SHIFT;
+
+	r = 0;
+	for (index = start; index < end;) {
+		struct folio *folio;
+
+		if (signal_pending(current)) {
+			r = -EINTR;
+			break;
+		}
+
+		folio = gunyah_gmem_get_folio(inode, index);
+		if (!folio) {
+			r = -ENOMEM;
+			break;
+		}
+
+		index = folio_next_index(folio);
+
+		folio_unlock(folio);
+		folio_put(folio);
+
+		/* 64-bit only, wrapping the index should be impossible. */
+		if (WARN_ON_ONCE(!index))
+			break;
+
+		cond_resched();
+	}
+
+	filemap_invalidate_unlock_shared(mapping);
+
+	return r;
+}
+
+static long gunyah_gmem_fallocate(struct file *file, int mode, loff_t offset,
+				  loff_t len)
+{
+	long ret;
+
+	if (!(mode & FALLOC_FL_KEEP_SIZE))
+		return -EOPNOTSUPP;
+
+	if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
+		     FALLOC_FL_ZERO_RANGE))
+		return -EOPNOTSUPP;
+
+	if (!PAGE_ALIGNED(offset) || !PAGE_ALIGNED(len))
+		return -EINVAL;
+
+	if (mode & FALLOC_FL_PUNCH_HOLE)
+		ret = gunyah_gmem_punch_hole(file_inode(file), offset, len);
+	else
+		ret = gunyah_gmem_allocate(file_inode(file), offset, len);
+
+	if (!ret)
+		file_modified(file);
+	return ret;
+}
+
+static int gunyah_gmem_release(struct inode *inode, struct file *file)
+{
+	gunyah_gmem_punch_hole(inode, 0, U64_MAX);
+
+	return 0;
+}
+
+static const struct file_operations gunyah_gmem_fops = {
+	.owner = THIS_MODULE,
+	.llseek = generic_file_llseek,
+	.mmap = gunyah_gmem_mmap,
+	.open = generic_file_open,
+	.fallocate = gunyah_gmem_fallocate,
+	.release = gunyah_gmem_release,
+};
+
+static const struct address_space_operations gunyah_gmem_aops = {
+	.dirty_folio = noop_dirty_folio,
+	.migrate_folio = migrate_folio,
+	.error_remove_folio = generic_error_remove_folio,
+};
+
+int gunyah_guest_mem_create(struct gunyah_create_mem_args *args)
+{
+	const char *anon_name = "[gh-gmem]";
+	unsigned long fd_flags = 0;
+	struct inode *inode;
+	struct file *file;
+	int fd, err;
+
+	if (!PAGE_ALIGNED(args->size))
+		return -EINVAL;
+
+	if (args->flags & ~(GHMF_CLOEXEC | GHMF_ALLOW_HUGEPAGE))
+		return -EINVAL;
+
+	if (args->flags & GHMF_CLOEXEC)
+		fd_flags |= O_CLOEXEC;
+
+	fd = get_unused_fd_flags(fd_flags);
+	if (fd < 0)
+		return fd;
+
+	/*
+	 * Use the so called "secure" variant, which creates a unique inode
+	 * instead of reusing a single inode.  Each guest_memfd instance needs
+	 * its own inode to track the size, flags, etc.
+	 */
+	file = anon_inode_create_getfile(anon_name, &gunyah_gmem_fops, NULL,
+					 O_RDWR, NULL);
+	if (IS_ERR(file)) {
+		err = PTR_ERR(file);
+		goto err_fd;
+	}
+
+	file->f_flags |= O_LARGEFILE;
+
+	inode = file->f_inode;
+	WARN_ON(file->f_mapping != inode->i_mapping);
+
+	inode->i_private = (void *)(unsigned long)args->flags;
+	inode->i_mapping->a_ops = &gunyah_gmem_aops;
+	inode->i_mode |= S_IFREG;
+	inode->i_size = args->size;
+	mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
+	mapping_set_large_folios(inode->i_mapping);
+	mapping_set_unmovable(inode->i_mapping);
+	// mapping_set_release_always(inode->i_mapping);
+	/* Unmovable mappings are supposed to be marked unevictable as well. */
+	WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping));
+
+	fd_install(fd, file);
+	return fd;
+
+err_fd:
+	put_unused_fd(fd);
+	return err;
+}
diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index 9e402e6ea7fe..cd978d1ce93f 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -799,6 +799,15 @@ long gunyah_dev_vm_mgr_ioctl(struct gunyah_rm *rm, unsigned int cmd,
 	switch (cmd) {
 	case GUNYAH_CREATE_VM:
 		return gunyah_dev_ioctl_create_vm(rm, arg);
+	case GUNYAH_CREATE_GUEST_MEM: {
+		struct gunyah_create_mem_args args;
+
+		if (copy_from_user(&args, (const void __user *)arg,
+				   sizeof(args)))
+			return -EFAULT;
+
+		return gunyah_guest_mem_create(&args);
+	}
 	default:
 		return -ENOTTY;
 	}
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index 348dbeda57ec..d26693d10d22 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -77,4 +77,6 @@ void gunyah_vm_reclaim_memory(struct gunyah_vm *ghvm);
 
 int gunyah_vm_mmio_write(struct gunyah_vm *ghvm, u64 addr, u32 len, u64 data);
 
+int gunyah_guest_mem_create(struct gunyah_create_mem_args *args);
+
 #endif
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
index 46f7d3aa61d0..c5f506350364 100644
--- a/include/uapi/linux/gunyah.h
+++ b/include/uapi/linux/gunyah.h
@@ -20,6 +20,25 @@
  */
 #define GUNYAH_CREATE_VM _IO(GUNYAH_IOCTL_TYPE, 0x0) /* Returns a Gunyah VM fd */
 
+enum gunyah_mem_flags {
+	GHMF_CLOEXEC = (1UL << 0),
+	GHMF_ALLOW_HUGEPAGE = (1UL << 1),
+};
+
+/**
+ * struct gunyah_create_mem_args - Description of guest memory to create
+ * @flags: See GHMF_*.
+ */
+struct gunyah_create_mem_args {
+	__u64 flags;
+	__u64 size;
+	__u64 reserved[6];
+};
+
+#define GUNYAH_CREATE_GUEST_MEM      \
+	_IOW(GUNYAH_IOCTL_TYPE, 0x8, \
+	     struct gunyah_create_mem_args) /* Returns a Gunyah memory fd */
+
 /*
  * ioctls for gunyah-vm fds (returned by GUNYAH_CREATE_VM)
  */

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:02 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:02 -0800
Subject: [PATCH RFC v15 21/30] virt: gunyah: Add ioctl to bind guestmem to
 VMs
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-21-192a5d872a30@quicinc.com>

A maple tree is used to maintain a map from guest address ranges to a
guestmemfd that provides the memory for that range of memory for the
guest. The mapping of guest address range to guestmemfd is called a
binding. Implement an ioctl to add/remove bindings to the virtual
machine. The binding determines whether the memory is shared (host
retains access) or lent (host loses access).

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/guest_memfd.c | 277 ++++++++++++++++++++++++++++++++++++++
 drivers/virt/gunyah/vm_mgr.c      |  15 +++
 drivers/virt/gunyah/vm_mgr.h      |   6 +
 include/uapi/linux/gunyah.h       |  41 ++++++
 4 files changed, 339 insertions(+)

diff --git a/drivers/virt/gunyah/guest_memfd.c b/drivers/virt/gunyah/guest_memfd.c
index 709aae9a1f44..c38380c4dc50 100644
--- a/drivers/virt/gunyah/guest_memfd.c
+++ b/drivers/virt/gunyah/guest_memfd.c
@@ -9,11 +9,61 @@
 #include <linux/types.h>
 #include <linux/falloc.h>
 #include <linux/file.h>
+#include <linux/maple_tree.h>
 #include <linux/migrate.h>
 #include <linux/pagemap.h>
 
 #include <uapi/linux/gunyah.h>
 
+#include "vm_mgr.h"
+
+/**
+ * struct gunyah_gmem_binding - Represents a binding of guestmem to a Gunyah VM
+ * @gfn: Guest address to place acquired folios
+ * @ghvm: Pointer to Gunyah VM in this binding
+ * @mt: Maple tree to track folios which have been provided to the VM
+ * @i_off: offset into the guestmem to grab folios from
+ * @inode: Pointer to guest mem inode
+ * @i_entry: list entry for inode->i_private_list
+ * @flags: Access flags for the binding
+ * @nr: Number of pages covered by this binding
+ */
+struct gunyah_gmem_binding {
+	u64 gfn;
+	struct gunyah_vm *ghvm;
+	struct maple_tree mt;
+
+	pgoff_t i_off;
+	struct inode *inode;
+	struct list_head i_entry;
+
+	u32 flags;
+	unsigned long nr;
+};
+
+static inline pgoff_t gunyah_gfn_to_off(struct gunyah_gmem_binding *b, u64 gfn)
+{
+	return gfn - b->gfn + b->i_off;
+}
+
+static inline u64 gunyah_off_to_gfn(struct gunyah_gmem_binding *b, pgoff_t off)
+{
+	return off - b->i_off + b->gfn;
+}
+
+static inline bool gunyah_guest_mem_is_lend(struct gunyah_vm *ghvm, u32 flags)
+{
+	u8 access = flags & GUNYAH_MEM_ACCESS_MASK;
+
+	if (access == GUNYAH_MEM_FORCE_LEND)
+		return true;
+	else if (access == GUNYAH_MEM_FORCE_SHARE)
+		return false;
+
+	/* RM requires all VMs to be protected (isolated) */
+	return true;
+}
+
 static struct folio *gunyah_gmem_get_huge_folio(struct inode *inode,
 						pgoff_t index)
 {
@@ -191,8 +241,15 @@ static long gunyah_gmem_fallocate(struct file *file, int mode, loff_t offset,
 
 static int gunyah_gmem_release(struct inode *inode, struct file *file)
 {
+	struct gunyah_gmem_binding *b, *n;
+
 	gunyah_gmem_punch_hole(inode, 0, U64_MAX);
 
+	list_for_each_entry_safe(b, n, &inode->i_mapping->i_private_list,
+				 i_entry) {
+		gunyah_gmem_remove_binding(b);
+	}
+
 	return 0;
 }
 
@@ -267,3 +324,223 @@ int gunyah_guest_mem_create(struct gunyah_create_mem_args *args)
 	put_unused_fd(fd);
 	return err;
 }
+
+void gunyah_gmem_remove_binding(struct gunyah_gmem_binding *b)
+{
+	mtree_erase(&b->ghvm->mem_layout, b->gfn);
+	list_del(&b->i_entry);
+	kfree(b);
+}
+
+static inline unsigned long gunyah_gmem_page_mask(struct inode *inode)
+{
+	unsigned long gmem_flags = (unsigned long)inode->i_private;
+
+	if (gmem_flags & GHMF_ALLOW_HUGEPAGE) {
+#if IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)
+		return HPAGE_PMD_MASK;
+#else
+		return ULONG_MAX;
+#endif
+	}
+
+	return PAGE_MASK;
+}
+
+static int gunyah_gmem_init_binding(struct gunyah_vm *ghvm, struct inode *inode,
+				    struct gunyah_map_mem_args *args,
+				    struct gunyah_gmem_binding *binding)
+{
+	const unsigned long page_mask = ~gunyah_gmem_page_mask(inode);
+
+	if (args->flags & ~(GUNYAH_MEM_ALLOW_RWX | GUNYAH_MEM_ACCESS_MASK))
+		return -EINVAL;
+
+	if (args->guest_addr & page_mask)
+		return -EINVAL;
+
+	if (args->offset & page_mask)
+		return -EINVAL;
+
+	if (args->size & page_mask)
+		return -EINVAL;
+
+	binding->gfn = gunyah_gpa_to_gfn(args->guest_addr);
+	binding->ghvm = ghvm;
+	binding->i_off = args->offset >> PAGE_SHIFT;
+	binding->inode = inode;
+	binding->flags = args->flags;
+	binding->nr = args->size >> PAGE_SHIFT;
+
+	return 0;
+}
+
+static int gunyah_gmem_remove_mapping(struct gunyah_vm *ghvm,
+				      struct inode *inode,
+				      struct gunyah_map_mem_args *args)
+{
+	struct gunyah_gmem_binding argb;
+	struct gunyah_gmem_binding *b = NULL;
+	unsigned long start_delta, end_delta;
+	int ret;
+
+	ret = gunyah_gmem_init_binding(ghvm, inode, args, &argb);
+	if (ret)
+		return ret;
+
+	filemap_invalidate_lock(inode->i_mapping);
+	list_for_each_entry(b, &inode->i_mapping->i_private_list, i_entry) {
+		if (b->ghvm != argb.ghvm || b->flags != argb.flags ||
+		    WARN_ON(b->inode != argb.inode))
+			continue;
+		/* Check if argb guest addresses is within b */
+		if (b->gfn > argb.gfn)
+			continue;
+		if (b->gfn + b->nr < argb.gfn + argb.nr)
+			continue;
+		start_delta = argb.gfn - b->gfn;
+		if (argb.i_off - b->i_off != start_delta)
+			continue;
+		end_delta = argb.gfn + argb.nr - b->gfn - b->nr;
+		if (!start_delta && !end_delta) {
+			/* wipe the mapping entirely */
+			gunyah_gmem_remove_binding(b);
+			goto out;
+		} else if (start_delta && !end_delta) {
+			/* shrink the end */
+			down_write(&ghvm->mem_lock);
+			mtree_erase(&b->ghvm->mem_layout, b->gfn);
+			b->nr = start_delta;
+			ret = mtree_insert_range(&ghvm->mem_layout, b->gfn,
+						 b->gfn + b->nr - 1, b,
+						 GFP_KERNEL);
+			up_write(&ghvm->mem_lock);
+			goto out;
+		} else if (!start_delta && end_delta) {
+			/* Shrink the beginning */
+			down_write(&ghvm->mem_lock);
+			mtree_erase(&b->ghvm->mem_layout, b->gfn);
+			b->gfn += argb.nr;
+			b->i_off += argb.nr;
+			b->nr -= argb.nr;
+			ret = mtree_insert_range(&ghvm->mem_layout, b->gfn,
+						 b->gfn + b->nr - 1, b,
+						 GFP_KERNEL);
+			up_write(&ghvm->mem_lock);
+			goto out;
+		} else {
+			/* TODO: split the mapping into 2 */
+			ret = -EINVAL;
+			goto out;
+		}
+	}
+	ret = -ENOENT;
+out:
+	filemap_invalidate_unlock(inode->i_mapping);
+	return ret;
+}
+
+static bool gunyah_gmem_binding_allowed_overlap(struct gunyah_gmem_binding *a,
+						struct gunyah_gmem_binding *b)
+{
+	/* Bindings can't overlap within a VM. Only one guest mem can
+	 * provide for a given guest address
+	 */
+	if (a->ghvm == b->ghvm && a->gfn + a->nr <= b->gfn &&
+	    a->gfn >= b->gfn + b->nr)
+		return false;
+
+	/* Gunyah only guarantees we can share a page with one VM and
+	 * doesn't (currently) allow us to share same page with multiple VMs,
+	 * regardless whether host can also access.
+	 */
+	if (a->inode == b->inode) {
+		if (a->ghvm == b->ghvm) {
+			if (gunyah_guest_mem_is_lend(a->ghvm, a->flags) ||
+			    gunyah_guest_mem_is_lend(b->ghvm, b->flags))
+				return false;
+		} else {
+			if (a->i_off + a->nr < b->i_off)
+				return false;
+			if (a->i_off > b->i_off + b->nr)
+				return false;
+		}
+	}
+
+	return true;
+}
+
+static int gunyah_gmem_add_mapping(struct gunyah_vm *ghvm, struct inode *inode,
+				   struct gunyah_map_mem_args *args)
+{
+	struct gunyah_gmem_binding *b, *tmp = NULL;
+	int ret;
+
+	b = kzalloc(sizeof(*b), GFP_KERNEL);
+	if (!b)
+		return -ENOMEM;
+
+	ret = gunyah_gmem_init_binding(ghvm, inode, args, b);
+	if (ret)
+		return ret;
+
+	filemap_invalidate_lock(inode->i_mapping);
+	list_for_each_entry(tmp, &inode->i_mapping->i_private_list, i_entry) {
+		if (!gunyah_gmem_binding_allowed_overlap(b, tmp)) {
+			ret = -EEXIST;
+			goto unlock;
+		}
+	}
+
+	ret = mtree_insert_range(&ghvm->mem_layout, b->gfn, b->gfn + b->nr - 1,
+				 b, GFP_KERNEL);
+	if (ret)
+		goto unlock;
+
+	list_add(&b->i_entry, &inode->i_mapping->i_private_list);
+
+unlock:
+	filemap_invalidate_unlock(inode->i_mapping);
+	return ret;
+}
+
+int gunyah_gmem_modify_binding(struct gunyah_vm *ghvm,
+			       struct gunyah_map_mem_args *args)
+{
+	u8 access = args->flags & GUNYAH_MEM_ACCESS_MASK;
+	struct file *file;
+	int ret = -EINVAL;
+
+	file = fget(args->guest_mem_fd);
+	if (!file)
+		return -EINVAL;
+
+	if (file->f_op != &gunyah_gmem_fops)
+		goto err_file;
+
+	if (args->flags & ~(GUNYAH_MEM_ALLOW_RWX | GUNYAH_MEM_UNMAP | GUNYAH_MEM_ACCESS_MASK))
+		goto err_file;
+
+	/* VM needs to have some permissions to the memory */
+	if (!(args->flags & GUNYAH_MEM_ALLOW_RWX))
+		goto err_file;
+
+	if (access != GUNYAH_MEM_DEFAULT_ACCESS &&
+	    access != GUNYAH_MEM_FORCE_LEND && access != GUNYAH_MEM_FORCE_SHARE)
+		goto err_file;
+
+	if (!PAGE_ALIGNED(args->guest_addr) || !PAGE_ALIGNED(args->offset) ||
+	    !PAGE_ALIGNED(args->size))
+		goto err_file;
+
+	if (args->flags & GUNYAH_MEM_UNMAP) {
+		args->flags &= ~GUNYAH_MEM_UNMAP;
+		ret = gunyah_gmem_remove_mapping(ghvm, file_inode(file), args);
+	} else {
+		ret = gunyah_gmem_add_mapping(ghvm, file_inode(file), args);
+	}
+
+err_file:
+	fput(file);
+	return ret;
+}
diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index cd978d1ce93f..5666070453aa 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -519,6 +519,8 @@ static __must_check struct gunyah_vm *gunyah_vm_alloc(struct gunyah_rm *rm)
 	mutex_init(&ghvm->fn_lock);
 
 	mt_init(&ghvm->gm);
+	mt_init(&ghvm->mem_layout);
+	init_rwsem(&ghvm->mem_lock);
 
 	ghvm->addrspace_ticket.resource_type = GUNYAH_RESOURCE_TYPE_ADDR_SPACE;
 	ghvm->addrspace_ticket.label = GUNYAH_VM_ADDRSPACE_LABEL;
@@ -673,6 +675,14 @@ static long gunyah_vm_ioctl(struct file *filp, unsigned int cmd,
 		r = gunyah_vm_rm_function_instance(ghvm, &f);
 		break;
 	}
+	case GUNYAH_VM_MAP_MEM: {
+		struct gunyah_map_mem_args args;
+
+		if (copy_from_user(&args, argp, sizeof(args)))
+			return -EFAULT;
+
+		return gunyah_gmem_modify_binding(ghvm, &args);
+	}
 	default:
 		r = -ENOTTY;
 		break;
@@ -690,6 +700,8 @@ EXPORT_SYMBOL_GPL(gunyah_vm_get);
 static void _gunyah_vm_put(struct kref *kref)
 {
 	struct gunyah_vm *ghvm = container_of(kref, struct gunyah_vm, kref);
+	struct gunyah_gmem_binding *b;
+	unsigned long idx = 0;
 	int ret;
 
 	if (ghvm->vm_status == GUNYAH_RM_VM_STATUS_RUNNING)
@@ -697,6 +709,9 @@ static void _gunyah_vm_put(struct kref *kref)
 
 	gunyah_vm_remove_functions(ghvm);
 
+	mt_for_each(&ghvm->mem_layout, b, idx, ULONG_MAX)
+		gunyah_gmem_remove_binding(b);
+	mtree_destroy(&ghvm->mem_layout);
 	gunyah_vm_reclaim_memory(ghvm);
 
 	gunyah_vm_remove_resource_ticket(ghvm, &ghvm->addrspace_ticket);
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index d26693d10d22..8f1c3ade08dd 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -36,6 +36,8 @@ long gunyah_dev_vm_mgr_ioctl(struct gunyah_rm *rm, unsigned int cmd,
 struct gunyah_vm {
 	u16 vmid;
 	struct maple_tree gm;
+	struct maple_tree mem_layout;
+	struct rw_semaphore mem_lock;
 	struct gunyah_vm_resource_ticket addrspace_ticket,
 		host_private_extent_ticket, host_shared_extent_ticket,
 		guest_private_extent_ticket, guest_shared_extent_ticket;
@@ -78,5 +80,9 @@ void gunyah_vm_reclaim_memory(struct gunyah_vm *ghvm);
 int gunyah_vm_mmio_write(struct gunyah_vm *ghvm, u64 addr, u32 len, u64 data);
 
 int gunyah_guest_mem_create(struct gunyah_create_mem_args *args);
+int gunyah_gmem_modify_binding(struct gunyah_vm *ghvm,
+			       struct gunyah_map_mem_args *args);
+struct gunyah_gmem_binding;
+void gunyah_gmem_remove_binding(struct gunyah_gmem_binding *binding);
 
 #endif
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
index c5f506350364..1af4c5ae6bc3 100644
--- a/include/uapi/linux/gunyah.h
+++ b/include/uapi/linux/gunyah.h
@@ -87,6 +87,47 @@ struct gunyah_fn_desc {
 #define GUNYAH_VM_ADD_FUNCTION	_IOW(GUNYAH_IOCTL_TYPE, 0x4, struct gunyah_fn_desc)
 #define GUNYAH_VM_REMOVE_FUNCTION	_IOW(GUNYAH_IOCTL_TYPE, 0x7, struct gunyah_fn_desc)
 
+/**
+ * enum gunyah_map_flags- Possible flags on &struct gunyah_map_mem_args
+ * @GUNYAH_MEM_DEFAULT_SHARE: Use default host access for the VM type
+ * @GUNYAH_MEM_FORCE_LEND: Force unmapping the memory once the guest starts to use
+ * @GUNYAH_MEM_FORCE_SHARE: Allow host to continue accessing memory when guest starts to use
+ * @GUNYAH_MEM_ALLOW_READ: Allow guest to read memory
+ * @GUNYAH_MEM_ALLOW_WRITE: Allow guest to write to the memory
+ * @GUNYAH_MEM_ALLOW_EXEC: Allow guest to execute instructions in the memory
+ */
+enum gunyah_map_flags {
+	GUNYAH_MEM_DEFAULT_ACCESS = 0,
+	GUNYAH_MEM_FORCE_LEND = 1,
+	GUNYAH_MEM_FORCE_SHARE = 2,
+#define GUNYAH_MEM_ACCESS_MASK 0x7
+
+	GUNYAH_MEM_ALLOW_READ = 1UL << 4,
+	GUNYAH_MEM_ALLOW_WRITE = 1UL << 5,
+	GUNYAH_MEM_ALLOW_EXEC = 1UL << 6,
+	GUNYAH_MEM_ALLOW_RWX =
+		(GUNYAH_MEM_ALLOW_READ | GUNYAH_MEM_ALLOW_WRITE | GUNYAH_MEM_ALLOW_EXEC),
+
+	GUNYAH_MEM_UNMAP = 1UL << 8,
+};
+
+/**
+ * struct gunyah_map_mem_args - Description to provide guest memory into a VM
+ * @guest_addr: Location in guest address space to place the memory
+ * @flags: See &enum gunyah_map_flags.
+ * @guest_mem_fd: File descriptor created by GUNYAH_CREATE_GUEST_MEM
+ * @offset: Offset into the guest memory file
+ */
+struct gunyah_map_mem_args {
+	__u64 guest_addr;
+	__u32 flags;
+	__u32 guest_mem_fd;
+	__u64 offset;
+	__u64 size;
+};
+
+#define GUNYAH_VM_MAP_MEM _IOW(GUNYAH_IOCTL_TYPE, 0x9, struct gunyah_map_mem_args)
+
 /*
  * ioctls for vCPU fds
  */

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:03 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:03 -0800
Subject: [PATCH RFC v15 22/30] virt: gunyah: guestmem: Initialize RM mem
 parcels from guestmem
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-22-192a5d872a30@quicinc.com>

Gunyah Resource Manager sets up a virtual machine based on a device
tree which lives in guest memory. Resource manager requires this memory
to be provided as a memory parcel for it to read and manipulate.
Implement a function to construct a memory parcel from a guestmem
binding.

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/guest_memfd.c | 188 ++++++++++++++++++++++++++++++++++++++
 drivers/virt/gunyah/vm_mgr.h      |   6 ++
 2 files changed, 194 insertions(+)

diff --git a/drivers/virt/gunyah/guest_memfd.c b/drivers/virt/gunyah/guest_memfd.c
index c38380c4dc50..419ed617bd0b 100644
--- a/drivers/virt/gunyah/guest_memfd.c
+++ b/drivers/virt/gunyah/guest_memfd.c
@@ -544,3 +544,191 @@ int gunyah_gmem_modify_binding(struct gunyah_vm *ghvm,
 	fput(file);
 	return ret;
 }
+
+int gunyah_gmem_share_parcel(struct gunyah_vm *ghvm, struct gunyah_rm_mem_parcel *parcel,
+			     u64 *gfn, u64 *nr)
+{
+	struct folio *folio, *prev_folio;
+	unsigned long nr_entries, i, j, start, end;
+	struct gunyah_gmem_binding *b;
+	bool lend;
+	u64 size;
+	int ret;
+
+	if (!*nr)
+		return -EINVAL;
+
+	down_read(&ghvm->mem_lock);
+	b = mtree_load(&ghvm->mem_layout, *gfn);
+	if (!b) {
+		ret = -ENOENT;
+		goto unlock;
+	}
+
+	start = *gfn - b->gfn;
+	end = min(*gfn + *nr, b->gfn + b->nr) - b->gfn;
+
+	nr_entries = 0;
+	prev_folio = NULL;
+	for (i = start + b->i_off; i < end + b->i_off;) {
+		folio = gunyah_gmem_get_folio(b->inode, i); /* A */
+		if (!folio) {
+			ret = -ENOMEM;
+			goto out;
+		}
+
+		if (!prev_folio || folio_next(prev_folio) != folio)
+			nr_entries++;
+		i = folio_index(folio) + folio_nr_pages(folio);
+		prev_folio = folio;
+	}
+
+	parcel->mem_entries =
+		kcalloc(nr_entries, sizeof(*parcel->mem_entries), GFP_KERNEL);
+	if (!parcel->mem_entries) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	j = 0;
+	prev_folio = NULL;
+	size = 0;
+	for (i = start + b->i_off; i < end + b->i_off;) {
+		folio = filemap_get_folio(b->inode->i_mapping, i); /* B */
+		if (WARN_ON(IS_ERR(folio))) {
+			ret = PTR_ERR(folio);
+			i = end + b->i_off;
+			goto out;
+		}
+
+		if (!prev_folio || folio_next(prev_folio) != folio) {
+			if (likely(prev_folio)) {
+				parcel->mem_entries[j].size = cpu_to_le64(size);
+				size = 0;
+				j++;
+				BUG_ON(j == nr_entries);
+			}
+			parcel->mem_entries[j].phys_addr = cpu_to_le64(PFN_PHYS(folio_pfn(folio)));
+		}
+		size += folio_size(folio);
+		if (likely(prev_folio))
+			folio_put(prev_folio); /* B */
+		i = folio_index(folio) + folio_nr_pages(folio);
+		prev_folio = folio;
+	}
+	folio_put(prev_folio); /* B */
+	BUG_ON(j + 1 != nr_entries);
+	parcel->mem_entries[j].size = cpu_to_le64(size);
+	parcel->n_mem_entries = nr_entries;
+
+	lend = parcel->n_acl_entries == 1 || gunyah_guest_mem_is_lend(ghvm, b->flags);
+	if (lend)
+		parcel->n_acl_entries = 1;
+
+	parcel->acl_entries = kcalloc(parcel->n_acl_entries,
+				      sizeof(*parcel->acl_entries), GFP_KERNEL);
+	if (!parcel->n_acl_entries) {
+		ret = -ENOMEM;
+		goto free_entries;
+	}
+
+	parcel->acl_entries[0].vmid = cpu_to_le16(ghvm->vmid);
+	if (b->flags & GUNYAH_MEM_ALLOW_READ)
+		parcel->acl_entries[0].perms |= GUNYAH_RM_ACL_R;
+	if (b->flags & GUNYAH_MEM_ALLOW_WRITE)
+		parcel->acl_entries[0].perms |= GUNYAH_RM_ACL_W;
+	if (b->flags & GUNYAH_MEM_ALLOW_EXEC)
+		parcel->acl_entries[0].perms |= GUNYAH_RM_ACL_X;
+
+	if (!lend) {
+		u16 host_vmid;
+
+		ret = gunyah_rm_get_vmid(ghvm->rm, &host_vmid);
+		if (ret)
+			goto free_acl;
+
+		parcel->acl_entries[1].vmid = cpu_to_le16(host_vmid);
+		parcel->acl_entries[1].perms = GUNYAH_RM_ACL_R | GUNYAH_RM_ACL_W | GUNYAH_RM_ACL_X;
+	}
+
+	parcel->mem_handle = GUNYAH_MEM_HANDLE_INVAL;
+	*nr = end;
+	folio = filemap_get_folio(b->inode->i_mapping, start); /* C */
+	*gfn = folio_index(folio) - b->i_off + b->gfn;
+	folio_put(folio); /* C */
+
+	ret = gunyah_rm_mem_share(ghvm->rm, parcel);
+	if (ret)
+		dev_warn(ghvm->parent, "Failed to share parcel for DTB: %d\n",
+			 ret);
+
+	goto out;
+free_acl:
+	kfree(parcel->acl_entries);
+	parcel->acl_entries = NULL;
+free_entries:
+	kfree(parcel->mem_entries);
+	parcel->mem_entries = NULL;
+out:
+	for (j = start + b->i_off; j < i;) {
+		folio = filemap_get_folio(b->inode->i_mapping, j); /* D */
+		if (IS_ERR(folio))
+			continue;
+		j = folio_index(folio) + folio_nr_pages(folio);
+		if (!ret) {
+			folio_set_private(folio);
+			WARN_ON(mtree_insert_range(&b->mt, folio_index(folio),
+						   j - 1, folio, GFP_KERNEL));
+		}
+		folio_unlock(folio); /* A */
+		folio_put(folio); /* D */
+		/* matching folio_put for A is done at
+		 * (1) gunyah_gmem_reclaim_parcel or
+		 * (2) after gunyah_gmem_parcel_to_paged, gunyah_vm_reclaim_folio
+		 */
+	}
+unlock:
+	up_read(&ghvm->mem_lock);
+	return ret;
+}
+
+int gunyah_gmem_reclaim_parcel(struct gunyah_vm *ghvm,
+			       struct gunyah_rm_mem_parcel *parcel, u64 gfn,
+			       u64 nr)
+{
+	struct gunyah_gmem_binding *b;
+	struct folio *folio;
+	unsigned long i;
+	int ret;
+
+	if (parcel->mem_handle != GUNYAH_MEM_HANDLE_INVAL) {
+		ret = gunyah_rm_mem_reclaim(ghvm->rm, parcel);
+		if (ret) {
+			dev_err(ghvm->parent, "Failed to reclaim parcel: %d\n",
+				ret);
+			/* We can't reclaim the pages -- hold onto the pages
+			 * forever because we don't know what state the memory
+			 * is in
+			 */
+			return ret;
+		}
+		parcel->mem_handle = 0;
+		kfree(parcel->mem_entries);
+		kfree(parcel->acl_entries);
+	}
+
+	down_read(&ghvm->mem_lock);
+	b = mtree_load(&ghvm->mem_layout, gfn);
+	if (WARN_ON(!b)) {
+		up_read(&ghvm->mem_lock);
+		return 0;
+	}
+
+	i = gfn - b->gfn + b->i_off;
+	mt_for_each(&b->mt, folio, i, nr + b->i_off) {
+		mtree_erase(&b->mt, i);
+		folio_put(folio); /* A */
+	}
+	up_read(&ghvm->mem_lock);
+	return 0;
+}
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index 8f1c3ade08dd..1cad729b017a 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -84,5 +84,11 @@ int gunyah_gmem_modify_binding(struct gunyah_vm *ghvm,
 			       struct gunyah_map_mem_args *args);
 struct gunyah_gmem_binding;
 void gunyah_gmem_remove_binding(struct gunyah_gmem_binding *binding);
+int gunyah_gmem_share_parcel(struct gunyah_vm *ghvm,
+			     struct gunyah_rm_mem_parcel *parcel, u64 *gfn,
+			     u64 *nr);
+int gunyah_gmem_reclaim_parcel(struct gunyah_vm *ghvm,
+			       struct gunyah_rm_mem_parcel *parcel, u64 gfn,
+			       u64 nr);
 
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:05 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:05 -0800
Subject: [PATCH RFC v15 24/30] virt: gunyah: Share guest VM dtb
 configuration to Gunyah
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-24-192a5d872a30@quicinc.com>

Gunyah Resource Manager sets up a virtual machine based on a device tree
which lives in guest memory. Resource manager requires this memory to be
provided as a memory parcel for it to read and manipulate. Construct a
memory parcel, lend it to the virtual machine, and inform resource
manager about the device tree location (the memory parcel ID and offset
into the memory parcel).

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/vm_mgr.c | 46 ++++++++++++++++++++++++++++++++++++++++++--
 drivers/virt/gunyah/vm_mgr.h |  6 ++++++
 include/uapi/linux/gunyah.h  | 14 ++++++++++++++
 3 files changed, 64 insertions(+), 2 deletions(-)

diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index a31a9f0a642c..8f8d962c9f8c 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -627,8 +627,27 @@ static int gunyah_vm_start(struct gunyah_vm *ghvm)
 	ghvm->vmid = ret;
 	ghvm->vm_status = GUNYAH_RM_VM_STATUS_LOAD;
 
-	ret = gunyah_rm_vm_configure(ghvm->rm, ghvm->vmid, ghvm->auth, 0, 0, 0,
-				     0, 0);
+	ghvm->dtb.parcel_start = ghvm->dtb.config.guest_phys_addr >> PAGE_SHIFT;
+	ghvm->dtb.parcel_pages = ghvm->dtb.config.size >> PAGE_SHIFT;
+	/* RM requires the DTB parcel to be lent to guard against malicious
+	 * modifications while starting VM. Force it so.
+	 */
+	ghvm->dtb.parcel.n_acl_entries = 1;
+	ret = gunyah_gmem_share_parcel(ghvm, &ghvm->dtb.parcel,
+				       &ghvm->dtb.parcel_start,
+				       &ghvm->dtb.parcel_pages);
+	if (ret) {
+		dev_warn(ghvm->parent,
+			 "Failed to allocate parcel for DTB: %d\n", ret);
+		goto err;
+	}
+
+	ret = gunyah_rm_vm_configure(ghvm->rm, ghvm->vmid, ghvm->auth,
+				     ghvm->dtb.parcel.mem_handle, 0, 0,
+				     ghvm->dtb.config.guest_phys_addr -
+					     (ghvm->dtb.parcel_start
+					      << PAGE_SHIFT),
+				     ghvm->dtb.config.size);
 	if (ret) {
 		dev_warn(ghvm->parent, "Failed to configure VM: %d\n", ret);
 		goto err;
@@ -720,6 +739,21 @@ static long gunyah_vm_ioctl(struct file *filp, unsigned int cmd,
 	long r;
 
 	switch (cmd) {
+	case GUNYAH_VM_SET_DTB_CONFIG: {
+		struct gunyah_vm_dtb_config dtb_config;
+
+		if (copy_from_user(&dtb_config, argp, sizeof(dtb_config)))
+			return -EFAULT;
+
+		if (overflows_type(dtb_config.guest_phys_addr + dtb_config.size,
+				   u64))
+			return -EOVERFLOW;
+
+		ghvm->dtb.config = dtb_config;
+
+		r = 0;
+		break;
+	}
 	case GUNYAH_VM_START: {
 		r = gunyah_vm_ensure_started(ghvm);
 		break;
@@ -783,6 +817,14 @@ static void _gunyah_vm_put(struct kref *kref)
 		gunyah_vm_stop(ghvm);
 
 	gunyah_vm_remove_functions(ghvm);
+	if (ghvm->vm_status == GUNYAH_RM_VM_STATUS_LOAD) {
+		ret = gunyah_gmem_reclaim_parcel(ghvm, &ghvm->dtb.parcel,
+						 ghvm->dtb.parcel_start,
+						 ghvm->dtb.parcel_pages);
+		if (ret)
+			dev_err(ghvm->parent,
+				"Failed to reclaim DTB parcel: %d\n", ret);
+	}
 
 	mt_for_each(&ghvm->mem_layout, b, idx, ULONG_MAX)
 		gunyah_gmem_remove_binding(b);
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index a7fc7c376d1e..357414e67d72 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -60,6 +60,12 @@ struct gunyah_vm {
 	struct list_head resource_tickets;
 	struct rb_root mmio_handler_root;
 	struct rw_semaphore mmio_handler_lock;
+
+	struct {
+		struct gunyah_vm_dtb_config config;
+		u64 parcel_start, parcel_pages;
+		struct gunyah_rm_mem_parcel parcel;
+	} dtb;
 	struct xarray boot_context;
 };
 
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
index a171185191ae..574116f54472 100644
--- a/include/uapi/linux/gunyah.h
+++ b/include/uapi/linux/gunyah.h
@@ -42,6 +42,20 @@ struct gunyah_create_mem_args {
 /*
  * ioctls for gunyah-vm fds (returned by GUNYAH_CREATE_VM)
  */
+
+/**
+ * struct gunyah_vm_dtb_config - Set the location of the VM's devicetree blob
+ * @guest_phys_addr: Address of the VM's devicetree in guest memory.
+ * @size: Maximum size of the devicetree including space for overlays.
+ *        Resource manager applies an overlay to the DTB and dtb_size should
+ *        include room for the overlay. A page of memory is typicaly plenty.
+ */
+struct gunyah_vm_dtb_config {
+	__u64 guest_phys_addr;
+	__u64 size;
+};
+#define GUNYAH_VM_SET_DTB_CONFIG	_IOW(GUNYAH_IOCTL_TYPE, 0x2, struct gunyah_vm_dtb_config)
+
 #define GUNYAH_VM_START		_IO(GUNYAH_IOCTL_TYPE, 0x3)
 
 /**

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:00 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:00 -0800
Subject: [PATCH RFC v15 19/30] virt: gunyah: Add proxy-scheduled vCPUs
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-19-192a5d872a30@quicinc.com>

Gunyah allows host virtual machines to schedule guest virtual machines
and handle their MMIO accesses. vCPUs are presented to the host as a
Gunyah resource and represented to userspace as a Gunyah VM function.

Creating the vcpu VM function will create a file descriptor that:
 - can run an ioctl: GH_VCPU_RUN to schedule the guest vCPU until the
   next interrupt occurs on the host or when the guest vCPU can no
   longer be run.
 - can be mmap'd to share a gh_vcpu_run structure which can look up the
   reason why GH_VCPU_RUN returned and provide return values for MMIO
   access.

Acked-by: Alex Elder <elder at linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 arch/arm64/gunyah/gunyah_hypercall.c |  27 ++
 drivers/virt/gunyah/Makefile         |   2 +-
 drivers/virt/gunyah/gunyah_vcpu.c    | 542 +++++++++++++++++++++++++++++++++++
 drivers/virt/gunyah/vm_mgr.c         |   5 +
 drivers/virt/gunyah/vm_mgr.h         |   1 +
 include/linux/gunyah.h               |  10 +
 include/uapi/linux/gunyah.h          | 163 +++++++++++
 7 files changed, 749 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/gunyah/gunyah_hypercall.c b/arch/arm64/gunyah/gunyah_hypercall.c
index 468a5bcb98b1..47926df33876 100644
--- a/arch/arm64/gunyah/gunyah_hypercall.c
+++ b/arch/arm64/gunyah/gunyah_hypercall.c
@@ -42,6 +42,7 @@ EXPORT_SYMBOL_GPL(arch_is_gunyah_guest);
 #define GUNYAH_HYPERCALL_ADDRSPACE_MAP		GUNYAH_HYPERCALL(0x802B)
 #define GUNYAH_HYPERCALL_ADDRSPACE_UNMAP		GUNYAH_HYPERCALL(0x802C)
 #define GUNYAH_HYPERCALL_MEMEXTENT_DONATE		GUNYAH_HYPERCALL(0x8061)
+#define GUNYAH_HYPERCALL_VCPU_RUN		GUNYAH_HYPERCALL(0x8065)
 /* clang-format on */
 
 /**
@@ -152,5 +153,31 @@ enum gunyah_error gunyah_hypercall_memextent_donate(u32 options, u64 from_capid,
 }
 EXPORT_SYMBOL_GPL(gunyah_hypercall_memextent_donate);
 
+enum gunyah_error gunyah_hypercall_vcpu_run(u64 capid, u64 *resume_data,
+					struct gunyah_hypercall_vcpu_run_resp *resp)
+{
+	struct arm_smccc_1_2_regs args = {
+		.a0 = GUNYAH_HYPERCALL_VCPU_RUN,
+		.a1 = capid,
+		.a2 = resume_data[0],
+		.a3 = resume_data[1],
+		.a4 = resume_data[2],
+		/* C language says this will be implictly zero. Gunyah requires 0, so be explicit */
+		.a5 = 0,
+	};
+	struct arm_smccc_1_2_regs res;
+
+	arm_smccc_1_2_hvc(&args, &res);
+	if (res.a0 == GUNYAH_ERROR_OK) {
+		resp->sized_state = res.a1;
+		resp->state_data[0] = res.a2;
+		resp->state_data[1] = res.a3;
+		resp->state_data[2] = res.a4;
+	}
+
+	return res.a0;
+}
+EXPORT_SYMBOL_GPL(gunyah_hypercall_vcpu_run);
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Gunyah Hypervisor Hypercalls");
diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index 09e0fbca33fe..ffcde0e0ccfa 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -2,5 +2,5 @@
 
 gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o vm_mgr.o vm_mgr_mem.o
 
-obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o
+obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o gunyah_vcpu.o
 obj-$(CONFIG_GUNYAH_PLATFORM_HOOKS) += gunyah_platform_hooks.o
diff --git a/drivers/virt/gunyah/gunyah_vcpu.c b/drivers/virt/gunyah/gunyah_vcpu.c
new file mode 100644
index 000000000000..aa40f5977cbf
--- /dev/null
+++ b/drivers/virt/gunyah/gunyah_vcpu.c
@@ -0,0 +1,542 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/anon_inodes.h>
+#include <linux/file.h>
+#include <linux/gunyah.h>
+#include <linux/gunyah_vm_mgr.h>
+#include <linux/interrupt.h>
+#include <linux/kref.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/wait.h>
+
+#include "vm_mgr.h"
+
+#include <uapi/linux/gunyah.h>
+
+#define MAX_VCPU_NAME 20 /* gh-vcpu:strlen(U32::MAX)+NUL */
+
+/**
+ * struct gunyah_vcpu - Track an instance of gunyah vCPU
+ * @f: Function instance (how we get associated with the main VM)
+ * @rsc: Pointer to the Gunyah vCPU resource, will be NULL until VM starts
+ * @run_lock: One userspace thread at a time should run the vCPU
+ * @ghvm: Pointer to the main VM struct; quicker look up than going through
+ *        @f->ghvm
+ * @vcpu_run: Pointer to page shared with userspace to communicate vCPU state
+ * @state: Our copy of the state of the vCPU, since userspace could trick
+ *         kernel to behave incorrectly if we relied on @vcpu_run
+ * @mmio_read_len: Our copy of @vcpu_run->mmio.len; see also @state
+ * @mmio_addr: Our copy of @vcpu_run->mmio.phys_addr; see also @state
+ * @ready: if vCPU goes to sleep, hypervisor reports to us that it's sleeping
+ *         and will signal interrupt (from @rsc) when it's time to wake up.
+ *         This completion signals that we can run vCPU again.
+ * @nb: When VM exits, the status of VM is reported via @vcpu_run->status.
+ *      We need to track overall VM status, and the nb gives us the updates from
+ *      Resource Manager.
+ * @ticket: resource ticket to claim vCPU# for the VM
+ * @kref: Reference counter
+ */
+struct gunyah_vcpu {
+	struct gunyah_vm_function_instance *f;
+	struct gunyah_resource *rsc;
+	struct mutex run_lock;
+	struct gunyah_vm *ghvm;
+
+	struct gunyah_vcpu_run *vcpu_run;
+
+	/**
+	 * Track why vcpu_run left last time around.
+	 * Mirrors the vcpu_run structure given to userspace, except
+	 * kernel shouldn't trust userspace to not modify the state
+	 * reported.
+	 */
+	enum {
+		GUNYAH_VCPU_UNKNOWN = 0,
+		GUNYAH_VCPU_READY,
+		GUNYAH_VCPU_MMIO_READ,
+		GUNYAH_VCPU_MMIO_WRITE,
+		GUNYAH_VCPU_SYSTEM_DOWN,
+	} state;
+	u8 mmio_read_len;
+	u64 mmio_addr;
+
+	struct completion ready;
+
+	struct notifier_block nb;
+	struct gunyah_vm_resource_ticket ticket;
+	struct kref kref;
+};
+
+static void vcpu_release(struct kref *kref)
+{
+	struct gunyah_vcpu *vcpu = container_of(kref, struct gunyah_vcpu, kref);
+
+	free_page((unsigned long)vcpu->vcpu_run);
+	kfree(vcpu);
+}
+
+/*
+ * When hypervisor allows us to schedule vCPU again, it gives us an interrupt
+ */
+static irqreturn_t gunyah_vcpu_irq_handler(int irq, void *data)
+{
+	struct gunyah_vcpu *vcpu = data;
+
+	complete(&vcpu->ready);
+	return IRQ_HANDLED;
+}
+
+static bool
+gunyah_handle_mmio(struct gunyah_vcpu *vcpu, u64 state_data[3],
+		   const struct gunyah_hypercall_vcpu_run_resp *vcpu_run_resp)
+{
+	int ret = 0;
+	u64 addr = vcpu_run_resp->state_data[0],
+	    len = vcpu_run_resp->state_data[1],
+	    data = vcpu_run_resp->state_data[2];
+
+	if (WARN_ON(len > sizeof(u64)))
+		len = sizeof(u64);
+
+	if (vcpu_run_resp->state == GUNYAH_VCPU_ADDRSPACE_VMMIO_READ) {
+		vcpu->vcpu_run->mmio.is_write = 0;
+		/* Record that we need to give vCPU user's supplied value next gunyah_vcpu_run() */
+		vcpu->state = GUNYAH_VCPU_MMIO_READ;
+		vcpu->mmio_read_len = len;
+	} else { /* GUNYAH_VCPU_ADDRSPACE_VMMIO_WRITE */
+		/* Try internal handlers first */
+		ret = gunyah_vm_mmio_write(vcpu->ghvm, addr, len, data);
+		if (!ret)
+			return true;
+
+		/* Give userspace the info */
+		vcpu->vcpu_run->mmio.is_write = 1;
+		memcpy(vcpu->vcpu_run->mmio.data, &data, len);
+		vcpu->state = GUNYAH_VCPU_MMIO_WRITE;
+	}
+
+	vcpu->vcpu_run->mmio.phys_addr = addr;
+	vcpu->vcpu_run->mmio.len = len;
+	vcpu->vcpu_run->exit_reason = GUNYAH_VCPU_EXIT_MMIO;
+
+	return false;
+}
+
+static int gunyah_handle_mmio_resume(struct gunyah_vcpu *vcpu, u64 state_data[3])
+{
+	switch (vcpu->vcpu_run->mmio.resume_action) {
+	case GUNYAH_VCPU_RESUME_HANDLED:
+		if (vcpu->state == GUNYAH_VCPU_MMIO_READ) {
+			if (unlikely(vcpu->mmio_read_len >
+				     sizeof(state_data[0])))
+				vcpu->mmio_read_len = sizeof(state_data[0]);
+			memcpy(&state_data[0], vcpu->vcpu_run->mmio.data,
+			       vcpu->mmio_read_len);
+		}
+		state_data[1] = GUNYAH_ADDRSPACE_VMMIO_ACTION_EMULATE;
+		break;
+	case GUNYAH_VCPU_RESUME_FAULT:
+		state_data[1] = GUNYAH_ADDRSPACE_VMMIO_ACTION_FAULT;
+		break;
+	case GUNYAH_VCPU_RESUME_RETRY:
+		state_data[1] = GUNYAH_ADDRSPACE_VMMIO_ACTION_RETRY;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int gunyah_vcpu_rm_notification(struct notifier_block *nb,
+				       unsigned long action, void *data)
+{
+	struct gunyah_vcpu *vcpu = container_of(nb, struct gunyah_vcpu, nb);
+	struct gunyah_rm_vm_exited_payload *exit_payload = data;
+
+	if (action == GUNYAH_RM_NOTIFICATION_VM_EXITED &&
+	    le16_to_cpu(exit_payload->vmid) == vcpu->ghvm->vmid)
+		complete(&vcpu->ready);
+
+	return NOTIFY_OK;
+}
+
+static inline enum gunyah_vm_status
+remap_vm_status(enum gunyah_rm_vm_status rm_status)
+{
+	switch (rm_status) {
+	case GUNYAH_RM_VM_STATUS_INIT_FAILED:
+		return GUNYAH_VM_STATUS_LOAD_FAILED;
+	case GUNYAH_RM_VM_STATUS_EXITED:
+		return GUNYAH_VM_STATUS_EXITED;
+	default:
+		return GUNYAH_VM_STATUS_CRASHED;
+	}
+}
+
+/**
+ * gunyah_vcpu_check_system() - Check whether VM as a whole is running
+ * @vcpu: Pointer to gunyah_vcpu
+ *
+ * Returns true if the VM is alive.
+ * Returns false if the vCPU is the VM is not alive (can only be that VM is shutting down).
+ */
+static bool gunyah_vcpu_check_system(struct gunyah_vcpu *vcpu)
+	__must_hold(&vcpu->run_lock)
+{
+	bool ret = true;
+
+	down_read(&vcpu->ghvm->status_lock);
+	if (likely(vcpu->ghvm->vm_status == GUNYAH_RM_VM_STATUS_RUNNING))
+		goto out;
+
+	vcpu->vcpu_run->status.status = remap_vm_status(vcpu->ghvm->vm_status);
+	vcpu->vcpu_run->status.exit_info = vcpu->ghvm->exit_info;
+	vcpu->vcpu_run->exit_reason = GUNYAH_VCPU_EXIT_STATUS;
+	vcpu->state = GUNYAH_VCPU_SYSTEM_DOWN;
+	ret = false;
+out:
+	up_read(&vcpu->ghvm->status_lock);
+	return ret;
+}
+
+/**
+ * gunyah_vcpu_run() - Request Gunyah to begin scheduling this vCPU.
+ * @vcpu: The client descriptor that was obtained via gunyah_vcpu_alloc()
+ */
+static int gunyah_vcpu_run(struct gunyah_vcpu *vcpu)
+{
+	struct gunyah_hypercall_vcpu_run_resp vcpu_run_resp;
+	u64 resume_data[3] = { 0 };
+	enum gunyah_error gunyah_error;
+	int ret = 0;
+
+	if (!vcpu->f)
+		return -ENODEV;
+
+	if (mutex_lock_interruptible(&vcpu->run_lock))
+		return -ERESTARTSYS;
+
+	if (!vcpu->rsc) {
+		ret = -ENODEV;
+		goto out;
+	}
+
+	switch (vcpu->state) {
+	case GUNYAH_VCPU_UNKNOWN:
+		if (vcpu->ghvm->vm_status != GUNYAH_RM_VM_STATUS_RUNNING) {
+			/* Check if VM is up. If VM is starting, will block until VM is fully up
+			 * since that thread does down_write.
+			 */
+			if (!gunyah_vcpu_check_system(vcpu))
+				goto out;
+		}
+		vcpu->state = GUNYAH_VCPU_READY;
+		break;
+	case GUNYAH_VCPU_MMIO_READ:
+	case GUNYAH_VCPU_MMIO_WRITE:
+		ret = gunyah_handle_mmio_resume(vcpu, resume_data);
+		if (ret)
+			goto out;
+		vcpu->state = GUNYAH_VCPU_READY;
+		break;
+	case GUNYAH_VCPU_SYSTEM_DOWN:
+		goto out;
+	default:
+		break;
+	}
+
+	while (!ret && !signal_pending(current)) {
+		if (vcpu->vcpu_run->immediate_exit) {
+			ret = -EINTR;
+			goto out;
+		}
+
+		gunyah_error = gunyah_hypercall_vcpu_run(
+			vcpu->rsc->capid, resume_data, &vcpu_run_resp);
+		memset(resume_data, 0, sizeof(resume_data));
+		if (gunyah_error == GUNYAH_ERROR_OK) {
+			switch (vcpu_run_resp.state) {
+			case GUNYAH_VCPU_STATE_READY:
+				if (need_resched())
+					schedule();
+				break;
+			case GUNYAH_VCPU_STATE_POWERED_OFF:
+				/* vcpu might be off because the VM is shut down.
+				 * If so, it won't ever run again: exit back to user
+				 */
+				if (!gunyah_vcpu_check_system(vcpu))
+					goto out;
+				/* Otherwise, another vcpu will turn it on (e.g. by PSCI)
+				 * and hyp sends an interrupt to wake Linux up.
+				 */
+				fallthrough;
+			case GUNYAH_VCPU_STATE_EXPECTS_WAKEUP:
+				ret = wait_for_completion_interruptible(
+					&vcpu->ready);
+				/* reinitialize completion before next hypercall. If we reinitialize
+				 * after the hypercall, interrupt may have already come before
+				 * re-initializing the completion and then end up waiting for
+				 * event that already happened.
+				 */
+				reinit_completion(&vcpu->ready);
+				/* Check system status again. Completion might've
+				 * come from gunyah_vcpu_rm_notification
+				 */
+				if (!ret && !gunyah_vcpu_check_system(vcpu))
+					goto out;
+				break;
+			case GUNYAH_VCPU_STATE_BLOCKED:
+				schedule();
+				break;
+			case GUNYAH_VCPU_ADDRSPACE_VMMIO_READ:
+			case GUNYAH_VCPU_ADDRSPACE_VMMIO_WRITE:
+				if (!gunyah_handle_mmio(vcpu, resume_data,
+							&vcpu_run_resp))
+					goto out;
+				break;
+			default:
+				pr_warn_ratelimited(
+					"Unknown vCPU state: %llx\n",
+					vcpu_run_resp.sized_state);
+				schedule();
+				break;
+			}
+		} else if (gunyah_error == GUNYAH_ERROR_RETRY) {
+			schedule();
+		} else {
+			ret = gunyah_error_remap(gunyah_error);
+		}
+	}
+
+out:
+	mutex_unlock(&vcpu->run_lock);
+
+	if (signal_pending(current))
+		return -ERESTARTSYS;
+
+	return ret;
+}
+
+static long gunyah_vcpu_ioctl(struct file *filp, unsigned int cmd,
+			      unsigned long arg)
+{
+	struct gunyah_vcpu *vcpu = filp->private_data;
+	long ret = -ENOTTY;
+
+	switch (cmd) {
+	case GUNYAH_VCPU_RUN:
+		ret = gunyah_vcpu_run(vcpu);
+		break;
+	case GUNYAH_VCPU_MMAP_SIZE:
+		ret = PAGE_SIZE;
+		break;
+	default:
+		break;
+	}
+	return ret;
+}
+
+static int gunyah_vcpu_release(struct inode *inode, struct file *filp)
+{
+	struct gunyah_vcpu *vcpu = filp->private_data;
+
+	gunyah_vm_put(vcpu->ghvm);
+	kref_put(&vcpu->kref, vcpu_release);
+	return 0;
+}
+
+static vm_fault_t gunyah_vcpu_fault(struct vm_fault *vmf)
+{
+	struct gunyah_vcpu *vcpu = vmf->vma->vm_file->private_data;
+	struct page *page = NULL;
+
+	if (vmf->pgoff == 0)
+		page = virt_to_page(vcpu->vcpu_run);
+
+	get_page(page);
+	vmf->page = page;
+	return 0;
+}
+
+static const struct vm_operations_struct gunyah_vcpu_ops = {
+	.fault = gunyah_vcpu_fault,
+};
+
+static int gunyah_vcpu_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	vma->vm_ops = &gunyah_vcpu_ops;
+	return 0;
+}
+
+static const struct file_operations gunyah_vcpu_fops = {
+	.owner = THIS_MODULE,
+	.unlocked_ioctl = gunyah_vcpu_ioctl,
+	.release = gunyah_vcpu_release,
+	.llseek = noop_llseek,
+	.mmap = gunyah_vcpu_mmap,
+};
+
+static bool gunyah_vcpu_populate(struct gunyah_vm_resource_ticket *ticket,
+				 struct gunyah_resource *ghrsc)
+{
+	struct gunyah_vcpu *vcpu =
+		container_of(ticket, struct gunyah_vcpu, ticket);
+	int ret;
+
+	mutex_lock(&vcpu->run_lock);
+	if (vcpu->rsc) {
+		pr_warn("vcpu%d already got a Gunyah resource. Check if multiple resources with same label were configured.\n",
+			vcpu->ticket.label);
+		ret = -EEXIST;
+		goto out;
+	}
+
+	vcpu->rsc = ghrsc;
+	init_completion(&vcpu->ready);
+
+	ret = request_irq(vcpu->rsc->irq, gunyah_vcpu_irq_handler,
+			  IRQF_TRIGGER_RISING, "gunyah_vcpu", vcpu);
+	if (ret)
+		pr_warn("Failed to request vcpu irq %d: %d", vcpu->rsc->irq,
+			ret);
+
+	enable_irq_wake(vcpu->rsc->irq);
+
+out:
+	mutex_unlock(&vcpu->run_lock);
+	return !ret;
+}
+
+static void gunyah_vcpu_unpopulate(struct gunyah_vm_resource_ticket *ticket,
+				   struct gunyah_resource *ghrsc)
+{
+	struct gunyah_vcpu *vcpu =
+		container_of(ticket, struct gunyah_vcpu, ticket);
+
+	vcpu->vcpu_run->immediate_exit = true;
+	complete_all(&vcpu->ready);
+	mutex_lock(&vcpu->run_lock);
+	free_irq(vcpu->rsc->irq, vcpu);
+	vcpu->rsc = NULL;
+	mutex_unlock(&vcpu->run_lock);
+}
+
+static long gunyah_vcpu_bind(struct gunyah_vm_function_instance *f)
+{
+	struct gunyah_fn_vcpu_arg *arg = f->argp;
+	struct gunyah_vcpu *vcpu;
+	char name[MAX_VCPU_NAME];
+	struct file *file;
+	struct page *page;
+	int fd;
+	long r;
+
+	if (f->arg_size != sizeof(*arg))
+		return -EINVAL;
+
+	vcpu = kzalloc(sizeof(*vcpu), GFP_KERNEL);
+	if (!vcpu)
+		return -ENOMEM;
+
+	vcpu->f = f;
+	f->data = vcpu;
+	mutex_init(&vcpu->run_lock);
+	kref_init(&vcpu->kref);
+
+	page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+	if (!page) {
+		r = -ENOMEM;
+		goto err_destroy_vcpu;
+	}
+	vcpu->vcpu_run = page_address(page);
+
+	vcpu->ticket.resource_type = GUNYAH_RESOURCE_TYPE_VCPU;
+	vcpu->ticket.label = arg->id;
+	vcpu->ticket.owner = THIS_MODULE;
+	vcpu->ticket.populate = gunyah_vcpu_populate;
+	vcpu->ticket.unpopulate = gunyah_vcpu_unpopulate;
+
+	r = gunyah_vm_add_resource_ticket(f->ghvm, &vcpu->ticket);
+	if (r)
+		goto err_destroy_page;
+
+	if (!gunyah_vm_get(f->ghvm)) {
+		r = -ENODEV;
+		goto err_remove_resource_ticket;
+	}
+	vcpu->ghvm = f->ghvm;
+
+	vcpu->nb.notifier_call = gunyah_vcpu_rm_notification;
+	/* Ensure we run after the vm_mgr handles the notification and does
+	 * any necessary state changes. We wake up to check the new state.
+	 */
+	vcpu->nb.priority = -1;
+	r = gunyah_rm_notifier_register(f->rm, &vcpu->nb);
+	if (r)
+		goto err_put_gunyah_vm;
+
+	kref_get(&vcpu->kref);
+
+	fd = get_unused_fd_flags(O_CLOEXEC);
+	if (fd < 0) {
+		r = fd;
+		goto err_notifier;
+	}
+
+	snprintf(name, sizeof(name), "gh-vcpu:%u", vcpu->ticket.label);
+	file = anon_inode_getfile(name, &gunyah_vcpu_fops, vcpu, O_RDWR);
+	if (IS_ERR(file)) {
+		r = PTR_ERR(file);
+		goto err_put_fd;
+	}
+
+	fd_install(fd, file);
+
+	return fd;
+err_put_fd:
+	put_unused_fd(fd);
+err_notifier:
+	gunyah_rm_notifier_unregister(f->rm, &vcpu->nb);
+err_put_gunyah_vm:
+	gunyah_vm_put(vcpu->ghvm);
+err_remove_resource_ticket:
+	gunyah_vm_remove_resource_ticket(f->ghvm, &vcpu->ticket);
+err_destroy_page:
+	free_page((unsigned long)vcpu->vcpu_run);
+err_destroy_vcpu:
+	kfree(vcpu);
+	return r;
+}
+
+static void gunyah_vcpu_unbind(struct gunyah_vm_function_instance *f)
+{
+	struct gunyah_vcpu *vcpu = f->data;
+
+	gunyah_rm_notifier_unregister(f->rm, &vcpu->nb);
+	gunyah_vm_remove_resource_ticket(vcpu->ghvm, &vcpu->ticket);
+	vcpu->f = NULL;
+
+	kref_put(&vcpu->kref, vcpu_release);
+}
+
+static bool gunyah_vcpu_compare(const struct gunyah_vm_function_instance *f,
+				const void *arg, size_t size)
+{
+	const struct gunyah_fn_vcpu_arg *instance = f->argp, *other = arg;
+
+	if (sizeof(*other) != size)
+		return false;
+
+	return instance->id == other->id;
+}
+
+DECLARE_GUNYAH_VM_FUNCTION_INIT(vcpu, GUNYAH_FN_VCPU, 1, gunyah_vcpu_bind,
+				gunyah_vcpu_unbind, gunyah_vcpu_compare);
+MODULE_DESCRIPTION("Gunyah vCPU Function");
+MODULE_LICENSE("GPL");
diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index a5450dc8cc28..9e402e6ea7fe 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -443,6 +443,11 @@ static int gunyah_vm_rm_notification_exited(struct gunyah_vm *ghvm, void *data)
 
 	down_write(&ghvm->status_lock);
 	ghvm->vm_status = GUNYAH_RM_VM_STATUS_EXITED;
+	ghvm->exit_info.type = le16_to_cpu(payload->exit_type);
+	ghvm->exit_info.reason_size = le32_to_cpu(payload->exit_reason_size);
+	memcpy(&ghvm->exit_info.reason, payload->exit_reason,
+	       min(GUNYAH_VM_MAX_EXIT_REASON_SIZE,
+		   ghvm->exit_info.reason_size));
 	up_write(&ghvm->status_lock);
 	wake_up(&ghvm->vm_status_wait);
 
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index 5d1ebce678ad..348dbeda57ec 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -48,6 +48,7 @@ struct gunyah_vm {
 	enum gunyah_rm_vm_status vm_status;
 	wait_queue_head_t vm_status_wait;
 	struct rw_semaphore status_lock;
+	struct gunyah_vm_exit_info exit_info;
 
 	struct kref kref;
 	struct mutex fn_lock;
diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h
index 86f48dc1d56d..ae9be5eef7a9 100644
--- a/include/linux/gunyah.h
+++ b/include/linux/gunyah.h
@@ -230,4 +230,14 @@ struct gunyah_hypercall_vcpu_run_resp {
 	u64 state_data[3];
 };
 
+enum {
+	GUNYAH_ADDRSPACE_VMMIO_ACTION_EMULATE = 0,
+	GUNYAH_ADDRSPACE_VMMIO_ACTION_RETRY = 1,
+	GUNYAH_ADDRSPACE_VMMIO_ACTION_FAULT = 2,
+};
+
+enum gunyah_error
+gunyah_hypercall_vcpu_run(u64 capid, u64 *resume_data,
+			  struct gunyah_hypercall_vcpu_run_resp *resp);
+
 #endif
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
index 1b7cb5fde70a..46f7d3aa61d0 100644
--- a/include/uapi/linux/gunyah.h
+++ b/include/uapi/linux/gunyah.h
@@ -25,8 +25,33 @@
  */
 #define GUNYAH_VM_START		_IO(GUNYAH_IOCTL_TYPE, 0x3)
 
+/**
+ * enum gunyah_fn_type - Valid types of Gunyah VM functions
+ * @GUNYAH_FN_VCPU: create a vCPU instance to control a vCPU
+ *              &struct gunyah_fn_desc.arg is a pointer to &struct gunyah_fn_vcpu_arg
+ *              Return: file descriptor to manipulate the vcpu.
+ */
+enum gunyah_fn_type {
+	GUNYAH_FN_VCPU = 1,
+};
+
 #define GUNYAH_FN_MAX_ARG_SIZE		256
 
+/**
+ * struct gunyah_fn_vcpu_arg - Arguments to create a vCPU.
+ * @id: vcpu id
+ *
+ * Create this function with &GUNYAH_VM_ADD_FUNCTION using type &GUNYAH_FN_VCPU.
+ *
+ * The vcpu type will register with the VM Manager to expect to control
+ * vCPU number `vcpu_id`. It returns a file descriptor allowing interaction with
+ * the vCPU. See the Gunyah vCPU API description sections for interacting with
+ * the Gunyah vCPU file descriptors.
+ */
+struct gunyah_fn_vcpu_arg {
+	__u32 id;
+};
+
 /**
  * struct gunyah_fn_desc - Arguments to create a VM function
  * @type: Type of the function. See &enum gunyah_fn_type.
@@ -43,4 +68,142 @@ struct gunyah_fn_desc {
 #define GUNYAH_VM_ADD_FUNCTION	_IOW(GUNYAH_IOCTL_TYPE, 0x4, struct gunyah_fn_desc)
 #define GUNYAH_VM_REMOVE_FUNCTION	_IOW(GUNYAH_IOCTL_TYPE, 0x7, struct gunyah_fn_desc)
 
+/*
+ * ioctls for vCPU fds
+ */
+
+/**
+ * enum gunyah_vm_status - Stores status reason why VM is not runnable (exited).
+ * @GUNYAH_VM_STATUS_LOAD_FAILED: VM didn't start because it couldn't be loaded.
+ * @GUNYAH_VM_STATUS_EXITED: VM requested shutdown/reboot.
+ *                       Use &struct gunyah_vm_exit_info.reason for further details.
+ * @GUNYAH_VM_STATUS_CRASHED: VM state is unknown and has crashed.
+ */
+enum gunyah_vm_status {
+	GUNYAH_VM_STATUS_LOAD_FAILED	= 1,
+	GUNYAH_VM_STATUS_EXITED		= 2,
+	GUNYAH_VM_STATUS_CRASHED		= 3,
+};
+
+/*
+ * Gunyah presently sends max 4 bytes of exit_reason.
+ * If that changes, this macro can be safely increased without breaking
+ * userspace so long as struct gunyah_vcpu_run < PAGE_SIZE.
+ */
+#define GUNYAH_VM_MAX_EXIT_REASON_SIZE	8u
+
+/**
+ * struct gunyah_vm_exit_info - Reason for VM exit as reported by Gunyah
+ * See Gunyah documentation for values.
+ * @type: Describes how VM exited
+ * @padding: padding bytes
+ * @reason_size: Number of bytes valid for `reason`
+ * @reason: See Gunyah documentation for interpretation. Note: these values are
+ *          not interpreted by Linux and need to be converted from little-endian
+ *          as applicable.
+ */
+struct gunyah_vm_exit_info {
+	__u16 type;
+	__u16 padding;
+	__u32 reason_size;
+	__u8 reason[GUNYAH_VM_MAX_EXIT_REASON_SIZE];
+};
+
+/**
+ * enum gunyah_vcpu_exit - Stores reason why &GUNYAH_VCPU_RUN ioctl recently exited with status 0
+ * @GUNYAH_VCPU_EXIT_UNKNOWN: Not used, status != 0
+ * @GUNYAH_VCPU_EXIT_MMIO: vCPU performed a read or write that could not be handled
+ *                     by hypervisor or Linux. Use @struct gunyah_vcpu_run.mmio for
+ *                     details of the read/write.
+ * @GUNYAH_VCPU_EXIT_STATUS: vCPU not able to run because the VM has exited.
+ *                       Use @struct gunyah_vcpu_run.status for why VM has exited.
+ * @GUNYAH_VCPU_EXIT_PAGE_FAULT: vCPU tried to execute an instruction at an address
+ *                               for which memory hasn't been provided. Use
+ *                               @struct gunyah_vcpu_run.page_fault for details.
+ */
+enum gunyah_vcpu_exit {
+	GUNYAH_VCPU_EXIT_UNKNOWN,
+	GUNYAH_VCPU_EXIT_MMIO,
+	GUNYAH_VCPU_EXIT_STATUS,
+	GUNYAH_VCPU_EXIT_PAGE_FAULT,
+};
+
+/**
+ * enum gunyah_vcpu_resume_action - Provide resume action after an MMIO or page fault
+ * @GUNYAH_VCPU_RESUME_HANDLED: The mmio or page fault has been handled, continue
+ *                              normal operation of vCPU
+ * @GUNYAH_VCPU_RESUME_FAULT: The mmio or page fault could not be satisfied and
+ *                            inject the original fault back to the guest.
+ * @GUNYAH_VCPU_RESUME_RETRY: Retry the faulting instruction. Perhaps you added
+ *                            memory binding to satisfy the request.
+ */
+enum gunyah_vcpu_resume_action {
+	GUNYAH_VCPU_RESUME_HANDLED = 0,
+	GUNYAH_VCPU_RESUME_FAULT,
+	GUNYAH_VCPU_RESUME_RETRY,
+};
+
+/**
+ * struct gunyah_vcpu_run - Application code obtains a pointer to the gunyah_vcpu_run
+ *                      structure by mmap()ing a vcpu fd.
+ * @immediate_exit: polled when scheduling the vcpu. If set, immediately returns -EINTR.
+ * @padding: padding bytes
+ * @exit_reason: Set when GUNYAH_VCPU_RUN returns successfully and gives reason why
+ *               GUNYAH_VCPU_RUN has stopped running the vCPU. See &enum gunyah_vcpu_exit.
+ * @mmio: Used when exit_reason == GUNYAH_VCPU_EXIT_MMIO
+ *        The guest has faulted on an memory-mapped I/O that
+ *        couldn't be satisfied by gunyah.
+ * @mmio.phys_addr: Address guest tried to access
+ * @mmio.data: the value that was written if `is_write == 1`. Filled by
+ *        user for reads (`is_write == 0`).
+ * @mmio.len: Length of write. Only the first `len` bytes of `data`
+ *       are considered by Gunyah.
+ * @mmio.is_write: 1 if VM tried to perform a write, 0 for a read
+ * @mmio.resume_action: See &enum gunyah_vcpu_resume_action
+ * @status: Used when exit_reason == GUNYAH_VCPU_EXIT_STATUS.
+ *          The guest VM is no longer runnable. This struct informs why.
+ * @status.status: See &enum gunyah_vm_status for possible values
+ * @status.exit_info: Used when status == GUNYAH_VM_STATUS_EXITED
+ * @page_fault: Used when EXIT_REASON == GUNYAH_VCPU_EXIT_PAGE_FAULT
+ *              The guest has faulted on a region that can only be provided
+ *              by mapping memory at phys_addr.
+ * @page_fault.phys_addr: Address guest tried to access.
+ * @page_fault.attempt: Error code why Linux wasn't able to handle fault itself
+ *                      Typically, if no memory was mapped: -ENOENT,
+ *                      If permission bits weren't what the VM wanted: -EPERM
+ * @page_fault.resume_action: See &enum gunyah_vcpu_resume_action
+ */
+struct gunyah_vcpu_run {
+	/* in */
+	__u8 immediate_exit;
+	__u8 padding[7];
+
+	/* out */
+	__u32 exit_reason;
+
+	union {
+		struct {
+			__u64 phys_addr;
+			__u8  data[8];
+			__u32 len;
+			__u8  is_write;
+			__u8  resume_action;
+		} mmio;
+
+		struct {
+			enum gunyah_vm_status status;
+			struct gunyah_vm_exit_info exit_info;
+		} status;
+
+		struct {
+			__u64 phys_addr;
+			__s32 attempt;
+			__u8  resume_action;
+		} page_fault;
+	};
+};
+
+#define GUNYAH_VCPU_RUN		_IO(GUNYAH_IOCTL_TYPE, 0x5)
+#define GUNYAH_VCPU_MMAP_SIZE	_IO(GUNYAH_IOCTL_TYPE, 0x6)
+
 #endif

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:08 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:08 -0800
Subject: [PATCH RFC v15 27/30] virt: gunyah: Add hypercalls for sending
 doorbell
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-27-192a5d872a30@quicinc.com>

Gunyah doorbells allow a virtual machine to signal another using
interrupts. Add the hypercalls needed to assert the interrupt.

Reviewed-by: Alex Elder <elder at linaro.org>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 arch/arm64/gunyah/gunyah_hypercall.c | 26 ++++++++++++++++++++++++++
 include/linux/gunyah.h               |  5 +++++
 2 files changed, 31 insertions(+)

diff --git a/arch/arm64/gunyah/gunyah_hypercall.c b/arch/arm64/gunyah/gunyah_hypercall.c
index 47926df33876..ec3c92025b0b 100644
--- a/arch/arm64/gunyah/gunyah_hypercall.c
+++ b/arch/arm64/gunyah/gunyah_hypercall.c
@@ -37,6 +37,8 @@ EXPORT_SYMBOL_GPL(arch_is_gunyah_guest);
 
 /* clang-format off */
 #define GUNYAH_HYPERCALL_HYP_IDENTIFY		GUNYAH_HYPERCALL(0x8000)
+#define GUNYAH_HYPERCALL_BELL_SEND			GUNYAH_HYPERCALL(0x8012)
+#define GUNYAH_HYPERCALL_BELL_SET_MASK		GUNYAH_HYPERCALL(0x8015)
 #define GUNYAH_HYPERCALL_MSGQ_SEND		GUNYAH_HYPERCALL(0x801B)
 #define GUNYAH_HYPERCALL_MSGQ_RECV		GUNYAH_HYPERCALL(0x801C)
 #define GUNYAH_HYPERCALL_ADDRSPACE_MAP		GUNYAH_HYPERCALL(0x802B)
@@ -64,6 +66,30 @@ void gunyah_hypercall_hyp_identify(
 }
 EXPORT_SYMBOL_GPL(gunyah_hypercall_hyp_identify);
 
+enum gunyah_error gunyah_hypercall_bell_send(u64 capid, u64 new_flags, u64 *old_flags)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_hvc(GUNYAH_HYPERCALL_BELL_SEND, capid, new_flags, 0, &res);
+
+	if (res.a0 == GUNYAH_ERROR_OK && old_flags)
+		*old_flags = res.a1;
+
+	return res.a0;
+}
+EXPORT_SYMBOL_GPL(gunyah_hypercall_bell_send);
+
+enum gunyah_error gunyah_hypercall_bell_set_mask(u64 capid, u64 enable_mask, u64 ack_mask)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_hvc(GUNYAH_HYPERCALL_BELL_SET_MASK, capid, enable_mask, ack_mask, 0, &res);
+
+	return res.a0;
+}
+EXPORT_SYMBOL_GPL(gunyah_hypercall_bell_set_mask);
+
+
 enum gunyah_error gunyah_hypercall_msgq_send(u64 capid, size_t size, void *buff,
 					     u64 tx_flags, bool *ready)
 {
diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h
index ed461acb9e1b..dc37c270290b 100644
--- a/include/linux/gunyah.h
+++ b/include/linux/gunyah.h
@@ -144,6 +144,11 @@ gunyah_api_version(const struct gunyah_hypercall_hyp_identify_resp *gunyah_api)
 void gunyah_hypercall_hyp_identify(
 	struct gunyah_hypercall_hyp_identify_resp *hyp_identity);
 
+enum gunyah_error gunyah_hypercall_bell_send(u64 capid, u64 new_flags,
+					     u64 *old_flags);
+enum gunyah_error gunyah_hypercall_bell_set_mask(u64 capid, u64 enable_mask,
+						 u64 ack_mask);
+
 #define GUNYAH_HYPERCALL_MSGQ_TX_FLAGS_PUSH BIT(0)
 
 enum gunyah_error gunyah_hypercall_msgq_send(u64 capid, size_t size, void *buff,

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:07 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:07 -0800
Subject: [PATCH RFC v15 26/30] virt: gunyah: Add Qualcomm Gunyah platform
 ops
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-26-192a5d872a30@quicinc.com>

Qualcomm platforms have a firmware entity which performs access control
to physical pages. Dynamically started Gunyah virtual machines use the
QCOM_SCM_RM_MANAGED_VMID for access. Linux thus needs to assign access
to the memory used by guest VMs. Gunyah doesn't do this operation for us
since it is the current VM (typically VMID_HLOS) delegating the access
and not Gunyah itself. Use the Gunyah platform ops to achieve this so
that only Qualcomm platforms attempt to make the needed SCM calls.

Reviewed-by: Alex Elder <elder at linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/Kconfig       |  13 +++
 drivers/virt/gunyah/Makefile      |   1 +
 drivers/virt/gunyah/gunyah_qcom.c | 218 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 232 insertions(+)

diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig
index 23ba523d25dc..fe2823dc48ba 100644
--- a/drivers/virt/gunyah/Kconfig
+++ b/drivers/virt/gunyah/Kconfig
@@ -4,6 +4,7 @@ config GUNYAH
 	tristate "Gunyah Virtualization drivers"
 	depends on ARM64
 	select GUNYAH_PLATFORM_HOOKS
+	imply GUNYAH_QCOM_PLATFORM if ARCH_QCOM
 	help
 	  The Gunyah drivers are the helper interfaces that run in a guest VM
 	  such as basic inter-VM IPC and signaling mechanisms, and higher level
@@ -14,3 +15,15 @@ config GUNYAH
 
 config GUNYAH_PLATFORM_HOOKS
 	tristate
+
+config GUNYAH_QCOM_PLATFORM
+	tristate "Support for Gunyah on Qualcomm platforms"
+	depends on GUNYAH
+	select GUNYAH_PLATFORM_HOOKS
+	select QCOM_SCM
+	help
+	  Enable support for interacting with Gunyah on Qualcomm
+	  platforms. Interaction with Qualcomm firmware requires
+	  extra platform-specific support.
+
+	  Say Y/M here to use Gunyah on Qualcomm platforms.
diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index 9d514b2baa3a..c4505fce177d 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -4,3 +4,4 @@ gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o vm_mgr.o vm_mgr_mem.o guest_memfd.o
 
 obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o gunyah_vcpu.o
 obj-$(CONFIG_GUNYAH_PLATFORM_HOOKS) += gunyah_platform_hooks.o
+obj-$(CONFIG_GUNYAH_QCOM_PLATFORM) += gunyah_qcom.o
diff --git a/drivers/virt/gunyah/gunyah_qcom.c b/drivers/virt/gunyah/gunyah_qcom.c
new file mode 100644
index 000000000000..58309e40da93
--- /dev/null
+++ b/drivers/virt/gunyah/gunyah_qcom.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/gunyah_rsc_mgr.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/firmware/qcom/qcom_scm.h>
+#include <linux/types.h>
+#include <linux/uuid.h>
+
+#define QCOM_SCM_RM_MANAGED_VMID 0x3A
+#define QCOM_SCM_MAX_MANAGED_VMID 0x3F
+
+static int
+qcom_scm_gunyah_rm_pre_mem_share(struct gunyah_rm *rm,
+				 struct gunyah_rm_mem_parcel *mem_parcel)
+{
+	struct qcom_scm_vmperm *new_perms __free(kfree) = NULL;
+	u64 src, src_cpy;
+	int ret = 0, i, n;
+	u16 vmid;
+
+	new_perms = kcalloc(mem_parcel->n_acl_entries, sizeof(*new_perms),
+			    GFP_KERNEL);
+	if (!new_perms)
+		return -ENOMEM;
+
+	for (n = 0; n < mem_parcel->n_acl_entries; n++) {
+		vmid = le16_to_cpu(mem_parcel->acl_entries[n].vmid);
+		if (vmid <= QCOM_SCM_MAX_MANAGED_VMID)
+			new_perms[n].vmid = vmid;
+		else
+			new_perms[n].vmid = QCOM_SCM_RM_MANAGED_VMID;
+		if (mem_parcel->acl_entries[n].perms & GUNYAH_RM_ACL_X)
+			new_perms[n].perm |= QCOM_SCM_PERM_EXEC;
+		if (mem_parcel->acl_entries[n].perms & GUNYAH_RM_ACL_W)
+			new_perms[n].perm |= QCOM_SCM_PERM_WRITE;
+		if (mem_parcel->acl_entries[n].perms & GUNYAH_RM_ACL_R)
+			new_perms[n].perm |= QCOM_SCM_PERM_READ;
+	}
+
+	src = BIT_ULL(QCOM_SCM_VMID_HLOS);
+
+	for (i = 0; i < mem_parcel->n_mem_entries; i++) {
+		src_cpy = src;
+		ret = qcom_scm_assign_mem(
+			le64_to_cpu(mem_parcel->mem_entries[i].phys_addr),
+			le64_to_cpu(mem_parcel->mem_entries[i].size), &src_cpy,
+			new_perms, mem_parcel->n_acl_entries);
+		if (ret)
+			break;
+	}
+
+	/* Did it work ok? */
+	if (!ret)
+		return 0;
+
+	src = 0;
+	for (n = 0; n < mem_parcel->n_acl_entries; n++) {
+		vmid = le16_to_cpu(mem_parcel->acl_entries[n].vmid);
+		if (vmid <= QCOM_SCM_MAX_MANAGED_VMID)
+			src |= BIT_ULL(vmid);
+		else
+			src |= BIT_ULL(QCOM_SCM_RM_MANAGED_VMID);
+	}
+
+	new_perms[0].vmid = QCOM_SCM_VMID_HLOS;
+
+	for (i--; i >= 0; i--) {
+		src_cpy = src;
+		WARN_ON_ONCE(qcom_scm_assign_mem(
+			le64_to_cpu(mem_parcel->mem_entries[i].phys_addr),
+			le64_to_cpu(mem_parcel->mem_entries[i].size), &src_cpy,
+			new_perms, 1));
+	}
+
+	return ret;
+}
+
+static int
+qcom_scm_gunyah_rm_post_mem_reclaim(struct gunyah_rm *rm,
+				    struct gunyah_rm_mem_parcel *mem_parcel)
+{
+	struct qcom_scm_vmperm new_perms;
+	u64 src = 0, src_cpy;
+	int ret = 0, i, n;
+	u16 vmid;
+
+	new_perms.vmid = QCOM_SCM_VMID_HLOS;
+	new_perms.perm = QCOM_SCM_PERM_EXEC | QCOM_SCM_PERM_WRITE |
+			 QCOM_SCM_PERM_READ;
+
+	for (n = 0; n < mem_parcel->n_acl_entries; n++) {
+		vmid = le16_to_cpu(mem_parcel->acl_entries[n].vmid);
+		if (vmid <= QCOM_SCM_MAX_MANAGED_VMID)
+			src |= (1ull << vmid);
+		else
+			src |= (1ull << QCOM_SCM_RM_MANAGED_VMID);
+	}
+
+	for (i = 0; i < mem_parcel->n_mem_entries; i++) {
+		src_cpy = src;
+		ret = qcom_scm_assign_mem(
+			le64_to_cpu(mem_parcel->mem_entries[i].phys_addr),
+			le64_to_cpu(mem_parcel->mem_entries[i].size), &src_cpy,
+			&new_perms, 1);
+		WARN_ON_ONCE(ret);
+	}
+
+	return ret;
+}
+
+static int
+qcom_scm_gunyah_rm_pre_demand_page(struct gunyah_rm *rm, u16 vmid,
+				   enum gunyah_pagetable_access access,
+				   struct folio *folio)
+{
+	struct qcom_scm_vmperm new_perms[2];
+	unsigned int n = 1;
+	u64 src;
+
+	new_perms[0].vmid = QCOM_SCM_RM_MANAGED_VMID;
+	new_perms[0].perm = QCOM_SCM_PERM_EXEC | QCOM_SCM_PERM_WRITE |
+			    QCOM_SCM_PERM_READ;
+	if (access != GUNYAH_PAGETABLE_ACCESS_X &&
+	    access != GUNYAH_PAGETABLE_ACCESS_RX &&
+	    access != GUNYAH_PAGETABLE_ACCESS_RWX) {
+		new_perms[1].vmid = QCOM_SCM_VMID_HLOS;
+		new_perms[1].perm = QCOM_SCM_PERM_EXEC | QCOM_SCM_PERM_WRITE |
+				    QCOM_SCM_PERM_READ;
+		n++;
+	}
+
+	src = BIT_ULL(QCOM_SCM_VMID_HLOS);
+
+	return qcom_scm_assign_mem(__pfn_to_phys(folio_pfn(folio)),
+				   folio_size(folio), &src, new_perms, n);
+}
+
+static int
+qcom_scm_gunyah_rm_release_demand_page(struct gunyah_rm *rm, u16 vmid,
+				       enum gunyah_pagetable_access access,
+				       struct folio *folio)
+{
+	struct qcom_scm_vmperm new_perms;
+	u64 src;
+
+	new_perms.vmid = QCOM_SCM_VMID_HLOS;
+	new_perms.perm = QCOM_SCM_PERM_EXEC | QCOM_SCM_PERM_WRITE |
+			 QCOM_SCM_PERM_READ;
+
+	src = BIT_ULL(QCOM_SCM_RM_MANAGED_VMID);
+
+	if (access != GUNYAH_PAGETABLE_ACCESS_X &&
+	    access != GUNYAH_PAGETABLE_ACCESS_RX &&
+	    access != GUNYAH_PAGETABLE_ACCESS_RWX)
+		src |= BIT_ULL(QCOM_SCM_VMID_HLOS);
+
+	return qcom_scm_assign_mem(__pfn_to_phys(folio_pfn(folio)),
+				   folio_size(folio), &src, &new_perms, 1);
+}
+
+static struct gunyah_rm_platform_ops qcom_scm_gunyah_rm_platform_ops = {
+	.pre_mem_share = qcom_scm_gunyah_rm_pre_mem_share,
+	.post_mem_reclaim = qcom_scm_gunyah_rm_post_mem_reclaim,
+	.pre_demand_page = qcom_scm_gunyah_rm_pre_demand_page,
+	.release_demand_page = qcom_scm_gunyah_rm_release_demand_page,
+};
+
+/* {19bd54bd-0b37-571b-946f-609b54539de6} */
+static const uuid_t QCOM_EXT_UUID = UUID_INIT(0x19bd54bd, 0x0b37, 0x571b, 0x94,
+					      0x6f, 0x60, 0x9b, 0x54, 0x53,
+					      0x9d, 0xe6);
+
+#define GUNYAH_QCOM_EXT_CALL_UUID_ID                              \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_VENDOR_HYP, 0x3f01)
+
+static bool gunyah_has_qcom_extensions(void)
+{
+	struct arm_smccc_res res;
+	uuid_t uuid;
+	u32 *up;
+
+	arm_smccc_1_1_smc(GUNYAH_QCOM_EXT_CALL_UUID_ID, &res);
+
+	up = (u32 *)&uuid.b[0];
+	up[0] = lower_32_bits(res.a0);
+	up[1] = lower_32_bits(res.a1);
+	up[2] = lower_32_bits(res.a2);
+	up[3] = lower_32_bits(res.a3);
+
+	return uuid_equal(&uuid, &QCOM_EXT_UUID);
+}
+
+static int __init qcom_gunyah_platform_hooks_register(void)
+{
+	if (!gunyah_has_qcom_extensions())
+		return -ENODEV;
+
+	pr_info("Enabling Gunyah hooks for Qualcomm platforms.\n");
+
+	return gunyah_rm_register_platform_ops(
+		&qcom_scm_gunyah_rm_platform_ops);
+}
+
+static void __exit qcom_gunyah_platform_hooks_unregister(void)
+{
+	gunyah_rm_unregister_platform_ops(&qcom_scm_gunyah_rm_platform_ops);
+}
+
+module_init(qcom_gunyah_platform_hooks_register);
+module_exit(qcom_gunyah_platform_hooks_unregister);
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Platform Hooks for Gunyah");
+MODULE_LICENSE("GPL");

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:09 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:09 -0800
Subject: [PATCH RFC v15 28/30] virt: gunyah: Add irqfd interface
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-28-192a5d872a30@quicinc.com>

Enable support for creating irqfds which can raise an interrupt on a
Gunyah virtual machine. irqfds are exposed to userspace as a Gunyah VM
function with the name "irqfd". If the VM devicetree is not configured
to create a doorbell with the corresponding label, userspace will still
be able to assert the eventfd but no interrupt will be raised on the
guest.

Acked-by: Alex Elder <elder at linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/Kconfig        |   9 ++
 drivers/virt/gunyah/Makefile       |   1 +
 drivers/virt/gunyah/gunyah_irqfd.c | 191 +++++++++++++++++++++++++++++++++++++
 include/uapi/linux/gunyah.h        |  35 +++++++
 4 files changed, 236 insertions(+)

diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig
index fe2823dc48ba..1685b75fb77a 100644
--- a/drivers/virt/gunyah/Kconfig
+++ b/drivers/virt/gunyah/Kconfig
@@ -27,3 +27,12 @@ config GUNYAH_QCOM_PLATFORM
 	  extra platform-specific support.
 
 	  Say Y/M here to use Gunyah on Qualcomm platforms.
+
+config GUNYAH_IRQFD
+	tristate "Gunyah irqfd interface"
+	depends on GUNYAH
+	help
+	  Enable kernel support for creating irqfds which can raise an interrupt
+	  on Gunyah virtual machine.
+
+	  Say Y/M here if unsure and you want to support Gunyah VMMs.
diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index c4505fce177d..b41b02792921 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -5,3 +5,4 @@ gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o vm_mgr.o vm_mgr_mem.o guest_memfd.o
 obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o gunyah_vcpu.o
 obj-$(CONFIG_GUNYAH_PLATFORM_HOOKS) += gunyah_platform_hooks.o
 obj-$(CONFIG_GUNYAH_QCOM_PLATFORM) += gunyah_qcom.o
+obj-$(CONFIG_GUNYAH_IRQFD) += gunyah_irqfd.o
diff --git a/drivers/virt/gunyah/gunyah_irqfd.c b/drivers/virt/gunyah/gunyah_irqfd.c
new file mode 100644
index 000000000000..0e377ead3213
--- /dev/null
+++ b/drivers/virt/gunyah/gunyah_irqfd.c
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/eventfd.h>
+#include <linux/device/driver.h>
+#include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/gunyah.h>
+#include <linux/gunyah_vm_mgr.h>
+#include <linux/module.h>
+#include <linux/poll.h>
+#include <linux/printk.h>
+
+#include <uapi/linux/gunyah.h>
+
+struct gunyah_irqfd {
+	struct gunyah_resource *ghrsc;
+	struct gunyah_vm_resource_ticket ticket;
+	struct gunyah_vm_function_instance *f;
+
+	bool level;
+
+	struct eventfd_ctx *ctx;
+	wait_queue_entry_t wait;
+	poll_table pt;
+};
+
+static int irqfd_wakeup(wait_queue_entry_t *wait, unsigned int mode, int sync,
+			void *key)
+{
+	struct gunyah_irqfd *irqfd =
+		container_of(wait, struct gunyah_irqfd, wait);
+	__poll_t flags = key_to_poll(key);
+	int ret = 0;
+
+	if (flags & EPOLLIN) {
+		if (irqfd->ghrsc) {
+			ret = gunyah_hypercall_bell_send(irqfd->ghrsc->capid, 1,
+							 NULL);
+			if (ret)
+				pr_err_ratelimited(
+					"Failed to inject interrupt %d: %d\n",
+					irqfd->ticket.label, ret);
+		} else
+			pr_err_ratelimited(
+				"Premature injection of interrupt\n");
+	}
+
+	return 0;
+}
+
+static void irqfd_ptable_queue_proc(struct file *file, wait_queue_head_t *wqh,
+				    poll_table *pt)
+{
+	struct gunyah_irqfd *irq_ctx =
+		container_of(pt, struct gunyah_irqfd, pt);
+
+	add_wait_queue(wqh, &irq_ctx->wait);
+}
+
+static bool gunyah_irqfd_populate(struct gunyah_vm_resource_ticket *ticket,
+				  struct gunyah_resource *ghrsc)
+{
+	struct gunyah_irqfd *irqfd =
+		container_of(ticket, struct gunyah_irqfd, ticket);
+	int ret;
+
+	if (irqfd->ghrsc) {
+		pr_warn("irqfd%d already got a Gunyah resource. Check if multiple resources with same label were configured.\n",
+			irqfd->ticket.label);
+		return false;
+	}
+
+	irqfd->ghrsc = ghrsc;
+	if (irqfd->level) {
+		/* Configure the bell to trigger when bit 0 is asserted (see
+		 * irq_wakeup) and for bell to automatically clear bit 0 once
+		 * received by the VM (ack_mask).  need to make sure bit 0 is cleared right away,
+		 * otherwise the line will never be deasserted. Emulating edge
+		 * trigger interrupt does not need to set either mask
+		 * because irq is listed only once per gunyah_hypercall_bell_send
+		 */
+		ret = gunyah_hypercall_bell_set_mask(irqfd->ghrsc->capid, 1, 1);
+		if (ret)
+			pr_warn("irq %d couldn't be set as level triggered. Might cause IRQ storm if asserted\n",
+				irqfd->ticket.label);
+	}
+
+	return true;
+}
+
+static void gunyah_irqfd_unpopulate(struct gunyah_vm_resource_ticket *ticket,
+				    struct gunyah_resource *ghrsc)
+{
+	struct gunyah_irqfd *irqfd =
+		container_of(ticket, struct gunyah_irqfd, ticket);
+	u64 cnt;
+
+	eventfd_ctx_remove_wait_queue(irqfd->ctx, &irqfd->wait, &cnt);
+}
+
+static long gunyah_irqfd_bind(struct gunyah_vm_function_instance *f)
+{
+	struct gunyah_fn_irqfd_arg *args = f->argp;
+	struct gunyah_irqfd *irqfd;
+	__poll_t events;
+	struct fd fd;
+	long r;
+
+	if (f->arg_size != sizeof(*args))
+		return -EINVAL;
+
+	/* All other flag bits are reserved for future use */
+	if (args->flags & ~GUNYAH_IRQFD_FLAGS_LEVEL)
+		return -EINVAL;
+
+	irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL);
+	if (!irqfd)
+		return -ENOMEM;
+
+	irqfd->f = f;
+	f->data = irqfd;
+
+	fd = fdget(args->fd);
+	if (!fd.file) {
+		kfree(irqfd);
+		return -EBADF;
+	}
+
+	irqfd->ctx = eventfd_ctx_fileget(fd.file);
+	if (IS_ERR(irqfd->ctx)) {
+		r = PTR_ERR(irqfd->ctx);
+		goto err_fdput;
+	}
+
+	if (args->flags & GUNYAH_IRQFD_FLAGS_LEVEL)
+		irqfd->level = true;
+
+	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
+	init_poll_funcptr(&irqfd->pt, irqfd_ptable_queue_proc);
+
+	irqfd->ticket.resource_type = GUNYAH_RESOURCE_TYPE_BELL_TX;
+	irqfd->ticket.label = args->label;
+	irqfd->ticket.owner = THIS_MODULE;
+	irqfd->ticket.populate = gunyah_irqfd_populate;
+	irqfd->ticket.unpopulate = gunyah_irqfd_unpopulate;
+
+	r = gunyah_vm_add_resource_ticket(f->ghvm, &irqfd->ticket);
+	if (r)
+		goto err_ctx;
+
+	events = vfs_poll(fd.file, &irqfd->pt);
+	if (events & EPOLLIN)
+		pr_warn("Premature injection of interrupt\n");
+	fdput(fd);
+
+	return 0;
+err_ctx:
+	eventfd_ctx_put(irqfd->ctx);
+err_fdput:
+	fdput(fd);
+	kfree(irqfd);
+	return r;
+}
+
+static void gunyah_irqfd_unbind(struct gunyah_vm_function_instance *f)
+{
+	struct gunyah_irqfd *irqfd = f->data;
+
+	gunyah_vm_remove_resource_ticket(irqfd->f->ghvm, &irqfd->ticket);
+	eventfd_ctx_put(irqfd->ctx);
+	kfree(irqfd);
+}
+
+static bool gunyah_irqfd_compare(const struct gunyah_vm_function_instance *f,
+				 const void *arg, size_t size)
+{
+	const struct gunyah_fn_irqfd_arg *instance = f->argp, *other = arg;
+
+	if (sizeof(*other) != size)
+		return false;
+
+	return instance->label == other->label;
+}
+
+DECLARE_GUNYAH_VM_FUNCTION_INIT(irqfd, GUNYAH_FN_IRQFD, 2, gunyah_irqfd_bind,
+				gunyah_irqfd_unbind, gunyah_irqfd_compare);
+MODULE_DESCRIPTION("Gunyah irqfd VM Function");
+MODULE_LICENSE("GPL");
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
index 574116f54472..cb7b0bb9bef3 100644
--- a/include/uapi/linux/gunyah.h
+++ b/include/uapi/linux/gunyah.h
@@ -63,9 +63,12 @@ struct gunyah_vm_dtb_config {
  * @GUNYAH_FN_VCPU: create a vCPU instance to control a vCPU
  *              &struct gunyah_fn_desc.arg is a pointer to &struct gunyah_fn_vcpu_arg
  *              Return: file descriptor to manipulate the vcpu.
+ * @GUNYAH_FN_IRQFD: register eventfd to assert a Gunyah doorbell
+ *               &struct gunyah_fn_desc.arg is a pointer to &struct gunyah_fn_irqfd_arg
  */
 enum gunyah_fn_type {
 	GUNYAH_FN_VCPU = 1,
+	GUNYAH_FN_IRQFD,
 };
 
 #define GUNYAH_FN_MAX_ARG_SIZE		256
@@ -85,6 +88,38 @@ struct gunyah_fn_vcpu_arg {
 	__u32 id;
 };
 
+/**
+ * enum gunyah_irqfd_flags - flags for use in gunyah_fn_irqfd_arg
+ * @GUNYAH_IRQFD_FLAGS_LEVEL: make the interrupt operate like a level triggered
+ *                        interrupt on guest side. Triggering IRQFD before
+ *                        guest handles the interrupt causes interrupt to
+ *                        stay asserted.
+ */
+enum gunyah_irqfd_flags {
+	GUNYAH_IRQFD_FLAGS_LEVEL		= 1UL << 0,
+};
+
+/**
+ * struct gunyah_fn_irqfd_arg - Arguments to create an irqfd function.
+ *
+ * Create this function with &GUNYAH_VM_ADD_FUNCTION using type &GUNYAH_FN_IRQFD.
+ *
+ * Allows setting an eventfd to directly trigger a guest interrupt.
+ * irqfd.fd specifies the file descriptor to use as the eventfd.
+ * irqfd.label corresponds to the doorbell label used in the guest VM's devicetree.
+ *
+ * @fd: an eventfd which when written to will raise a doorbell
+ * @label: Label of the doorbell created on the guest VM
+ * @flags: see &enum gunyah_irqfd_flags
+ * @padding: padding bytes
+ */
+struct gunyah_fn_irqfd_arg {
+	__u32 fd;
+	__u32 label;
+	__u32 flags;
+	__u32 padding;
+};
+
 /**
  * struct gunyah_fn_desc - Arguments to create a VM function
  * @type: Type of the function. See &enum gunyah_fn_type.

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:11 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:11 -0800
Subject: [PATCH RFC v15 30/30] MAINTAINERS: Add Gunyah hypervisor drivers
 section
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-30-192a5d872a30@quicinc.com>

Add myself and Prakruthi as maintainers of Gunyah hypervisor drivers.

Reviewed-by: Alex Elder <elder at linaro.org>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 MAINTAINERS | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b589218605b4..fa2fe28f922f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9251,6 +9251,19 @@ L:	linux-efi at vger.kernel.org
 S:	Maintained
 F:	block/partitions/efi.*
 
+GUNYAH HYPERVISOR DRIVER
+M:	Elliot Berman <quic_eberman at quicinc.com>
+M:	Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
+L:	linux-arm-msm at vger.kernel.org
+S:	Supported
+F:	Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
+F:	Documentation/virt/gunyah/
+F:	arch/arm64/gunyah/
+F:	drivers/mailbox/gunyah-msgq.c
+F:	drivers/virt/gunyah/
+F:	include/linux/gunyah*.h
+F:	samples/gunyah/
+
 HABANALABS PCI DRIVER
 M:	Oded Gabbay <ogabbay at kernel.org>
 L:	dri-devel at lists.freedesktop.org

-- 
2.43.0



From quic_eberman at quicinc.com  Fri Dec 15 16:21:10 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:10 -0800
Subject: [PATCH RFC v15 29/30] virt: gunyah: Add ioeventfd
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-29-192a5d872a30@quicinc.com>

Allow userspace to attach an ioeventfd to an mmio address within the
guest.  Userspace provides a description of the type of write to
"subscribe" to and eventfd to trigger when that type of write is
performed by the guest. This mechanism allows userspace to respond
asynchronously to a guest manipulating a virtualized device and is
similar to KVM's ioeventfd.

Reviewed-by: Alex Elder <elder at linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu at quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/Kconfig            |   9 +++
 drivers/virt/gunyah/Makefile           |   1 +
 drivers/virt/gunyah/gunyah_ioeventfd.c | 132 +++++++++++++++++++++++++++++++++
 include/uapi/linux/gunyah.h            |  37 +++++++++
 4 files changed, 179 insertions(+)

diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig
index 1685b75fb77a..855d41a88b16 100644
--- a/drivers/virt/gunyah/Kconfig
+++ b/drivers/virt/gunyah/Kconfig
@@ -36,3 +36,12 @@ config GUNYAH_IRQFD
 	  on Gunyah virtual machine.
 
 	  Say Y/M here if unsure and you want to support Gunyah VMMs.
+
+config GUNYAH_IOEVENTFD
+	tristate "Gunyah ioeventfd interface"
+	depends on GUNYAH
+	help
+	  Enable kernel support for creating ioeventfds which can alert userspace
+	  when a Gunyah virtual machine accesses a memory address.
+
+	  Say Y/M here if unsure and you want to support Gunyah VMMs.
diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
index b41b02792921..2aec5989402b 100644
--- a/drivers/virt/gunyah/Makefile
+++ b/drivers/virt/gunyah/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_GUNYAH) += gunyah.o gunyah_rsc_mgr.o gunyah_vcpu.o
 obj-$(CONFIG_GUNYAH_PLATFORM_HOOKS) += gunyah_platform_hooks.o
 obj-$(CONFIG_GUNYAH_QCOM_PLATFORM) += gunyah_qcom.o
 obj-$(CONFIG_GUNYAH_IRQFD) += gunyah_irqfd.o
+obj-$(CONFIG_GUNYAH_IOEVENTFD) += gunyah_ioeventfd.o
diff --git a/drivers/virt/gunyah/gunyah_ioeventfd.c b/drivers/virt/gunyah/gunyah_ioeventfd.c
new file mode 100644
index 000000000000..650a156c0102
--- /dev/null
+++ b/drivers/virt/gunyah/gunyah_ioeventfd.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/eventfd.h>
+#include <linux/device/driver.h>
+#include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/gunyah.h>
+#include <linux/gunyah_vm_mgr.h>
+#include <linux/module.h>
+#include <linux/printk.h>
+
+#include <uapi/linux/gunyah.h>
+
+struct gunyah_ioeventfd {
+	struct gunyah_vm_function_instance *f;
+	struct gunyah_vm_io_handler io_handler;
+
+	struct eventfd_ctx *ctx;
+};
+
+static int gunyah_write_ioeventfd(struct gunyah_vm_io_handler *io_dev, u64 addr,
+				  u32 len, u64 data)
+{
+	struct gunyah_ioeventfd *iofd =
+		container_of(io_dev, struct gunyah_ioeventfd, io_handler);
+
+	eventfd_signal(iofd->ctx);
+	return 0;
+}
+
+static struct gunyah_vm_io_handler_ops io_ops = {
+	.write = gunyah_write_ioeventfd,
+};
+
+static long gunyah_ioeventfd_bind(struct gunyah_vm_function_instance *f)
+{
+	const struct gunyah_fn_ioeventfd_arg *args = f->argp;
+	struct gunyah_ioeventfd *iofd;
+	struct eventfd_ctx *ctx;
+	int ret;
+
+	if (f->arg_size != sizeof(*args))
+		return -EINVAL;
+
+	/* All other flag bits are reserved for future use */
+	if (args->flags & ~GUNYAH_IOEVENTFD_FLAGS_DATAMATCH)
+		return -EINVAL;
+
+	/* must be natural-word sized, or 0 to ignore length */
+	switch (args->len) {
+	case 0:
+	case 1:
+	case 2:
+	case 4:
+	case 8:
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	/* check for range overflow */
+	if (overflows_type(args->addr + args->len, u64))
+		return -EINVAL;
+
+	/* ioeventfd with no length can't be combined with DATAMATCH */
+	if (!args->len && (args->flags & GUNYAH_IOEVENTFD_FLAGS_DATAMATCH))
+		return -EINVAL;
+
+	ctx = eventfd_ctx_fdget(args->fd);
+	if (IS_ERR(ctx))
+		return PTR_ERR(ctx);
+
+	iofd = kzalloc(sizeof(*iofd), GFP_KERNEL);
+	if (!iofd) {
+		ret = -ENOMEM;
+		goto err_eventfd;
+	}
+
+	f->data = iofd;
+	iofd->f = f;
+
+	iofd->ctx = ctx;
+
+	if (args->flags & GUNYAH_IOEVENTFD_FLAGS_DATAMATCH) {
+		iofd->io_handler.datamatch = true;
+		iofd->io_handler.len = args->len;
+		iofd->io_handler.data = args->datamatch;
+	}
+	iofd->io_handler.addr = args->addr;
+	iofd->io_handler.ops = &io_ops;
+
+	ret = gunyah_vm_add_io_handler(f->ghvm, &iofd->io_handler);
+	if (ret)
+		goto err_io_dev_add;
+
+	return 0;
+
+err_io_dev_add:
+	kfree(iofd);
+err_eventfd:
+	eventfd_ctx_put(ctx);
+	return ret;
+}
+
+static void gunyah_ioevent_unbind(struct gunyah_vm_function_instance *f)
+{
+	struct gunyah_ioeventfd *iofd = f->data;
+
+	eventfd_ctx_put(iofd->ctx);
+	gunyah_vm_remove_io_handler(iofd->f->ghvm, &iofd->io_handler);
+	kfree(iofd);
+}
+
+static bool gunyah_ioevent_compare(const struct gunyah_vm_function_instance *f,
+				   const void *arg, size_t size)
+{
+	const struct gunyah_fn_ioeventfd_arg *instance = f->argp, *other = arg;
+
+	if (sizeof(*other) != size)
+		return false;
+
+	return instance->addr == other->addr;
+}
+
+DECLARE_GUNYAH_VM_FUNCTION_INIT(ioeventfd, GUNYAH_FN_IOEVENTFD, 3,
+				gunyah_ioeventfd_bind, gunyah_ioevent_unbind,
+				gunyah_ioevent_compare);
+MODULE_DESCRIPTION("Gunyah ioeventfd VM Function");
+MODULE_LICENSE("GPL");
diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
index cb7b0bb9bef3..fd461e2fe8b5 100644
--- a/include/uapi/linux/gunyah.h
+++ b/include/uapi/linux/gunyah.h
@@ -65,10 +65,13 @@ struct gunyah_vm_dtb_config {
  *              Return: file descriptor to manipulate the vcpu.
  * @GUNYAH_FN_IRQFD: register eventfd to assert a Gunyah doorbell
  *               &struct gunyah_fn_desc.arg is a pointer to &struct gunyah_fn_irqfd_arg
+ * @GUNYAH_FN_IOEVENTFD: register ioeventfd to trigger when VM faults on parameter
+ *                   &struct gunyah_fn_desc.arg is a pointer to &struct gunyah_fn_ioeventfd_arg
  */
 enum gunyah_fn_type {
 	GUNYAH_FN_VCPU = 1,
 	GUNYAH_FN_IRQFD,
+	GUNYAH_FN_IOEVENTFD,
 };
 
 #define GUNYAH_FN_MAX_ARG_SIZE		256
@@ -120,6 +123,40 @@ struct gunyah_fn_irqfd_arg {
 	__u32 padding;
 };
 
+/**
+ * enum gunyah_ioeventfd_flags - flags for use in gunyah_fn_ioeventfd_arg
+ * @GUNYAH_IOEVENTFD_FLAGS_DATAMATCH: the event will be signaled only if the
+ *                                written value to the registered address is
+ *                                equal to &struct gunyah_fn_ioeventfd_arg.datamatch
+ */
+enum gunyah_ioeventfd_flags {
+	GUNYAH_IOEVENTFD_FLAGS_DATAMATCH	= 1UL << 0,
+};
+
+/**
+ * struct gunyah_fn_ioeventfd_arg - Arguments to create an ioeventfd function
+ * @datamatch: data used when GUNYAH_IOEVENTFD_DATAMATCH is set
+ * @addr: Address in guest memory
+ * @len: Length of access
+ * @fd: When ioeventfd is matched, this eventfd is written
+ * @flags: See &enum gunyah_ioeventfd_flags
+ * @padding: padding bytes
+ *
+ * Create this function with &GUNYAH_VM_ADD_FUNCTION using type &GUNYAH_FN_IOEVENTFD.
+ *
+ * Attaches an ioeventfd to a legal mmio address within the guest. A guest write
+ * in the registered address will signal the provided event instead of triggering
+ * an exit on the GUNYAH_VCPU_RUN ioctl.
+ */
+struct gunyah_fn_ioeventfd_arg {
+	__u64 datamatch;
+	__u64 addr;        /* legal mmio address */
+	__u32 len;         /* 1, 2, 4, or 8 bytes; or 0 to ignore length */
+	__s32 fd;
+	__u32 flags;
+	__u32 padding;
+};
+
 /**
  * struct gunyah_fn_desc - Arguments to create a VM function
  * @type: Type of the function. See &enum gunyah_fn_type.

-- 
2.43.0



From daniel at makrotopia.org  Fri Dec 15 16:22:19 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 16 Dec 2023 00:22:19 +0000
Subject: [PATCH v6 1/5] dt-bindings: clock: mediatek: add MT7988 clock IDs
Message-ID: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702685864.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add MT7988 clock dt-bindings for topckgen, apmixedsys, infracfg,
ethernet and xfipll subsystem clocks.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
v6: no changes
v5: no changes
v4: no changes
v3: no changes
v2: fix indentation

 .../dt-bindings/clock/mediatek,mt7988-clk.h   | 280 ++++++++++++++++++
 1 file changed, 280 insertions(+)
 create mode 100644 include/dt-bindings/clock/mediatek,mt7988-clk.h

diff --git a/include/dt-bindings/clock/mediatek,mt7988-clk.h b/include/dt-bindings/clock/mediatek,mt7988-clk.h
new file mode 100644
index 0000000000000..63376e40f14d2
--- /dev/null
+++ b/include/dt-bindings/clock/mediatek,mt7988-clk.h
@@ -0,0 +1,280 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#ifndef _DT_BINDINGS_CLK_MT7988_H
+#define _DT_BINDINGS_CLK_MT7988_H
+
+/* APMIXEDSYS */
+
+#define CLK_APMIXED_NETSYSPLL			0
+#define CLK_APMIXED_MPLL			1
+#define CLK_APMIXED_MMPLL			2
+#define CLK_APMIXED_APLL2			3
+#define CLK_APMIXED_NET1PLL			4
+#define CLK_APMIXED_NET2PLL			5
+#define CLK_APMIXED_WEDMCUPLL			6
+#define CLK_APMIXED_SGMPLL			7
+#define CLK_APMIXED_ARM_B			8
+#define CLK_APMIXED_CCIPLL2_B			9
+#define CLK_APMIXED_USXGMIIPLL			10
+#define CLK_APMIXED_MSDCPLL			11
+
+/* TOPCKGEN */
+
+#define CLK_TOP_XTAL				0
+#define CLK_TOP_XTAL_D2				1
+#define CLK_TOP_RTC_32K				2
+#define CLK_TOP_RTC_32P7K			3
+#define CLK_TOP_MPLL_D2				4
+#define CLK_TOP_MPLL_D3_D2			5
+#define CLK_TOP_MPLL_D4				6
+#define CLK_TOP_MPLL_D8				7
+#define CLK_TOP_MPLL_D8_D2			8
+#define CLK_TOP_MMPLL_D2			9
+#define CLK_TOP_MMPLL_D3_D5			10
+#define CLK_TOP_MMPLL_D4			11
+#define CLK_TOP_MMPLL_D6_D2			12
+#define CLK_TOP_MMPLL_D8			13
+#define CLK_TOP_APLL2_D4			14
+#define CLK_TOP_NET1PLL_D4			15
+#define CLK_TOP_NET1PLL_D5			16
+#define CLK_TOP_NET1PLL_D5_D2			17
+#define CLK_TOP_NET1PLL_D5_D4			18
+#define CLK_TOP_NET1PLL_D8			19
+#define CLK_TOP_NET1PLL_D8_D2			20
+#define CLK_TOP_NET1PLL_D8_D4			21
+#define CLK_TOP_NET1PLL_D8_D8			22
+#define CLK_TOP_NET1PLL_D8_D16			23
+#define CLK_TOP_NET2PLL_D2			24
+#define CLK_TOP_NET2PLL_D4			25
+#define CLK_TOP_NET2PLL_D4_D4			26
+#define CLK_TOP_NET2PLL_D4_D8			27
+#define CLK_TOP_NET2PLL_D6			28
+#define CLK_TOP_NET2PLL_D8			29
+#define CLK_TOP_NETSYS_SEL			30
+#define CLK_TOP_NETSYS_500M_SEL			31
+#define CLK_TOP_NETSYS_2X_SEL			32
+#define CLK_TOP_NETSYS_GSW_SEL			33
+#define CLK_TOP_ETH_GMII_SEL			34
+#define CLK_TOP_NETSYS_MCU_SEL			35
+#define CLK_TOP_NETSYS_PAO_2X_SEL		36
+#define CLK_TOP_EIP197_SEL			37
+#define CLK_TOP_AXI_INFRA_SEL			38
+#define CLK_TOP_UART_SEL			39
+#define CLK_TOP_EMMC_250M_SEL			40
+#define CLK_TOP_EMMC_400M_SEL			41
+#define CLK_TOP_SPI_SEL				42
+#define CLK_TOP_SPIM_MST_SEL			43
+#define CLK_TOP_NFI1X_SEL			44
+#define CLK_TOP_SPINFI_SEL			45
+#define CLK_TOP_PWM_SEL				46
+#define CLK_TOP_I2C_SEL				47
+#define CLK_TOP_PCIE_MBIST_250M_SEL		48
+#define CLK_TOP_PEXTP_TL_SEL			49
+#define CLK_TOP_PEXTP_TL_P1_SEL			50
+#define CLK_TOP_PEXTP_TL_P2_SEL			51
+#define CLK_TOP_PEXTP_TL_P3_SEL			52
+#define CLK_TOP_USB_SYS_SEL			53
+#define CLK_TOP_USB_SYS_P1_SEL			54
+#define CLK_TOP_USB_XHCI_SEL			55
+#define CLK_TOP_USB_XHCI_P1_SEL			56
+#define CLK_TOP_USB_FRMCNT_SEL			57
+#define CLK_TOP_USB_FRMCNT_P1_SEL		58
+#define CLK_TOP_AUD_SEL				59
+#define CLK_TOP_A1SYS_SEL			60
+#define CLK_TOP_AUD_L_SEL			61
+#define CLK_TOP_A_TUNER_SEL			62
+#define CLK_TOP_SSPXTP_SEL			63
+#define CLK_TOP_USB_PHY_SEL			64
+#define CLK_TOP_USXGMII_SBUS_0_SEL		65
+#define CLK_TOP_USXGMII_SBUS_1_SEL		66
+#define CLK_TOP_SGM_0_SEL			67
+#define CLK_TOP_SGM_SBUS_0_SEL			68
+#define CLK_TOP_SGM_1_SEL			69
+#define CLK_TOP_SGM_SBUS_1_SEL			70
+#define CLK_TOP_XFI_PHY_0_XTAL_SEL		71
+#define CLK_TOP_XFI_PHY_1_XTAL_SEL		72
+#define CLK_TOP_SYSAXI_SEL			73
+#define CLK_TOP_SYSAPB_SEL			74
+#define CLK_TOP_ETH_REFCK_50M_SEL		75
+#define CLK_TOP_ETH_SYS_200M_SEL		76
+#define CLK_TOP_ETH_SYS_SEL			77
+#define CLK_TOP_ETH_XGMII_SEL			78
+#define CLK_TOP_BUS_TOPS_SEL			79
+#define CLK_TOP_NPU_TOPS_SEL			80
+#define CLK_TOP_DRAMC_SEL			81
+#define CLK_TOP_DRAMC_MD32_SEL			82
+#define CLK_TOP_INFRA_F26M_SEL			83
+#define CLK_TOP_PEXTP_P0_SEL			84
+#define CLK_TOP_PEXTP_P1_SEL			85
+#define CLK_TOP_PEXTP_P2_SEL			86
+#define CLK_TOP_PEXTP_P3_SEL			87
+#define CLK_TOP_DA_XTP_GLB_P0_SEL		88
+#define CLK_TOP_DA_XTP_GLB_P1_SEL		89
+#define CLK_TOP_DA_XTP_GLB_P2_SEL		90
+#define CLK_TOP_DA_XTP_GLB_P3_SEL		91
+#define CLK_TOP_CKM_SEL				92
+#define CLK_TOP_DA_SEL				93
+#define CLK_TOP_PEXTP_SEL			94
+#define CLK_TOP_TOPS_P2_26M_SEL			95
+#define CLK_TOP_MCUSYS_BACKUP_625M_SEL		96
+#define CLK_TOP_NETSYS_SYNC_250M_SEL		97
+#define CLK_TOP_MACSEC_SEL			98
+#define CLK_TOP_NETSYS_TOPS_400M_SEL		99
+#define CLK_TOP_NETSYS_PPEFB_250M_SEL		100
+#define CLK_TOP_NETSYS_WARP_SEL			101
+#define CLK_TOP_ETH_MII_SEL			102
+#define CLK_TOP_NPU_SEL				103
+#define CLK_TOP_AUD_I2S_M			104
+
+/* MCUSYS */
+
+#define CLK_MCU_BUS_DIV_SEL			0
+#define CLK_MCU_ARM_DIV_SEL			1
+
+/* INFRACFG_AO */
+
+#define CLK_INFRA_MUX_UART0_SEL			0
+#define CLK_INFRA_MUX_UART1_SEL			1
+#define CLK_INFRA_MUX_UART2_SEL			2
+#define CLK_INFRA_MUX_SPI0_SEL			3
+#define CLK_INFRA_MUX_SPI1_SEL			4
+#define CLK_INFRA_MUX_SPI2_SEL			5
+#define CLK_INFRA_PWM_SEL			6
+#define CLK_INFRA_PWM_CK1_SEL			7
+#define CLK_INFRA_PWM_CK2_SEL			8
+#define CLK_INFRA_PWM_CK3_SEL			9
+#define CLK_INFRA_PWM_CK4_SEL			10
+#define CLK_INFRA_PWM_CK5_SEL			11
+#define CLK_INFRA_PWM_CK6_SEL			12
+#define CLK_INFRA_PWM_CK7_SEL			13
+#define CLK_INFRA_PWM_CK8_SEL			14
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL	15
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL	16
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL	17
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL	18
+
+/* INFRACFG */
+
+#define CLK_INFRA_PCIE_PERI_26M_CK_P0		19
+#define CLK_INFRA_PCIE_PERI_26M_CK_P1		20
+#define CLK_INFRA_PCIE_PERI_26M_CK_P2		21
+#define CLK_INFRA_PCIE_PERI_26M_CK_P3		22
+#define CLK_INFRA_66M_GPT_BCK			23
+#define CLK_INFRA_66M_PWM_HCK			24
+#define CLK_INFRA_66M_PWM_BCK			25
+#define CLK_INFRA_66M_PWM_CK1			26
+#define CLK_INFRA_66M_PWM_CK2			27
+#define CLK_INFRA_66M_PWM_CK3			28
+#define CLK_INFRA_66M_PWM_CK4			29
+#define CLK_INFRA_66M_PWM_CK5			30
+#define CLK_INFRA_66M_PWM_CK6			31
+#define CLK_INFRA_66M_PWM_CK7			32
+#define CLK_INFRA_66M_PWM_CK8			33
+#define CLK_INFRA_133M_CQDMA_BCK		34
+#define CLK_INFRA_66M_AUD_SLV_BCK		35
+#define CLK_INFRA_AUD_26M			36
+#define CLK_INFRA_AUD_L				37
+#define CLK_INFRA_AUD_AUD			38
+#define CLK_INFRA_AUD_EG2			39
+#define CLK_INFRA_DRAMC_F26M			40
+#define CLK_INFRA_133M_DBG_ACKM			41
+#define CLK_INFRA_66M_AP_DMA_BCK		42
+#define CLK_INFRA_66M_SEJ_BCK			43
+#define CLK_INFRA_PRE_CK_SEJ_F13M		44
+#define CLK_INFRA_26M_THERM_SYSTEM		45
+#define CLK_INFRA_I2C_BCK			46
+#define CLK_INFRA_52M_UART0_CK			47
+#define CLK_INFRA_52M_UART1_CK			48
+#define CLK_INFRA_52M_UART2_CK			49
+#define CLK_INFRA_NFI				50
+#define CLK_INFRA_SPINFI			51
+#define CLK_INFRA_66M_NFI_HCK			52
+#define CLK_INFRA_104M_SPI0			53
+#define CLK_INFRA_104M_SPI1			54
+#define CLK_INFRA_104M_SPI2_BCK			55
+#define CLK_INFRA_66M_SPI0_HCK			56
+#define CLK_INFRA_66M_SPI1_HCK			57
+#define CLK_INFRA_66M_SPI2_HCK			58
+#define CLK_INFRA_66M_FLASHIF_AXI		59
+#define CLK_INFRA_RTC				60
+#define CLK_INFRA_26M_ADC_BCK			61
+#define CLK_INFRA_RC_ADC			62
+#define CLK_INFRA_MSDC400			63
+#define CLK_INFRA_MSDC2_HCK			64
+#define CLK_INFRA_133M_MSDC_0_HCK		65
+#define CLK_INFRA_66M_MSDC_0_HCK		66
+#define CLK_INFRA_133M_CPUM_BCK			67
+#define CLK_INFRA_BIST2FPC			68
+#define CLK_INFRA_I2C_X16W_MCK_CK_P1		69
+#define CLK_INFRA_I2C_X16W_PCK_CK_P1		70
+#define CLK_INFRA_133M_USB_HCK			71
+#define CLK_INFRA_133M_USB_HCK_CK_P1		72
+#define CLK_INFRA_66M_USB_HCK			73
+#define CLK_INFRA_66M_USB_HCK_CK_P1		74
+#define CLK_INFRA_USB_SYS			75
+#define CLK_INFRA_USB_SYS_CK_P1			76
+#define CLK_INFRA_USB_REF			77
+#define CLK_INFRA_USB_CK_P1			78
+#define CLK_INFRA_USB_FRMCNT			79
+#define CLK_INFRA_USB_FRMCNT_CK_P1		80
+#define CLK_INFRA_USB_PIPE			81
+#define CLK_INFRA_USB_PIPE_CK_P1		82
+#define CLK_INFRA_USB_UTMI			83
+#define CLK_INFRA_USB_UTMI_CK_P1		84
+#define CLK_INFRA_USB_XHCI			85
+#define CLK_INFRA_USB_XHCI_CK_P1		86
+#define CLK_INFRA_PCIE_GFMUX_TL_P0		87
+#define CLK_INFRA_PCIE_GFMUX_TL_P1		88
+#define CLK_INFRA_PCIE_GFMUX_TL_P2		89
+#define CLK_INFRA_PCIE_GFMUX_TL_P3		90
+#define CLK_INFRA_PCIE_PIPE_P0			91
+#define CLK_INFRA_PCIE_PIPE_P1			92
+#define CLK_INFRA_PCIE_PIPE_P2			93
+#define CLK_INFRA_PCIE_PIPE_P3			94
+#define CLK_INFRA_133M_PCIE_CK_P0		95
+#define CLK_INFRA_133M_PCIE_CK_P1		96
+#define CLK_INFRA_133M_PCIE_CK_P2		97
+#define CLK_INFRA_133M_PCIE_CK_P3		98
+
+/* ETHDMA */
+
+#define CLK_ETHDMA_XGP1_EN			0
+#define CLK_ETHDMA_XGP2_EN			1
+#define CLK_ETHDMA_XGP3_EN			2
+#define CLK_ETHDMA_FE_EN			3
+#define CLK_ETHDMA_GP2_EN			4
+#define CLK_ETHDMA_GP1_EN			5
+#define CLK_ETHDMA_GP3_EN			6
+#define CLK_ETHDMA_ESW_EN			7
+#define CLK_ETHDMA_CRYPT0_EN			8
+#define CLK_ETHDMA_NR_CLK			9
+
+/* SGMIISYS0 */
+
+#define CLK_SGM0_TX_EN				0
+#define CLK_SGM0_RX_EN				1
+#define CLK_SGMII0_NR_CLK			2
+
+/* SGMIISYS1 */
+
+#define CLK_SGM1_TX_EN				0
+#define CLK_SGM1_RX_EN				1
+#define CLK_SGMII1_NR_CLK			2
+
+/* ETHWARP */
+
+#define CLK_ETHWARP_WOCPU2_EN			0
+#define CLK_ETHWARP_WOCPU1_EN			1
+#define CLK_ETHWARP_WOCPU0_EN			2
+#define CLK_ETHWARP_NR_CLK			3
+
+/* XFIPLL */
+#define CLK_XFIPLL_PLL				0
+#define CLK_XFIPLL_PLL_EN			1
+
+#endif /* _DT_BINDINGS_CLK_MT7988_H */
-- 
2.43.0


From quic_eberman at quicinc.com  Fri Dec 15 16:21:06 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Fri, 15 Dec 2023 16:21:06 -0800
Subject: [PATCH RFC v15 25/30] virt: gunyah: Enable demand paging
In-Reply-To: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
References: <20231215-gunyah-v15-0-192a5d872a30@quicinc.com>
Message-ID: <20231215-gunyah-v15-25-192a5d872a30@quicinc.com>

Tell resource manager to enable demand paging and wire vCPU faults to
provide the backing folio when a guestmemfd is bound to the faulting
access.

Signed-off-by: Elliot Berman <quic_eberman at quicinc.com>
---
 drivers/virt/gunyah/guest_memfd.c | 92 +++++++++++++++++++++++++++++++++++++++
 drivers/virt/gunyah/gunyah_vcpu.c | 39 ++++++++++++++++-
 drivers/virt/gunyah/vm_mgr.c      | 17 ++++++++
 drivers/virt/gunyah/vm_mgr.h      |  3 ++
 include/linux/gunyah.h            |  2 +
 5 files changed, 152 insertions(+), 1 deletion(-)

diff --git a/drivers/virt/gunyah/guest_memfd.c b/drivers/virt/gunyah/guest_memfd.c
index 419ed617bd0b..206ce51c9a7d 100644
--- a/drivers/virt/gunyah/guest_memfd.c
+++ b/drivers/virt/gunyah/guest_memfd.c
@@ -732,3 +732,95 @@ int gunyah_gmem_reclaim_parcel(struct gunyah_vm *ghvm,
 	up_read(&ghvm->mem_lock);
 	return 0;
 }
+
+int gunyah_gmem_setup_demand_paging(struct gunyah_vm *ghvm)
+{
+	struct gunyah_rm_mem_entry *entries;
+	struct gunyah_gmem_binding *b;
+	unsigned long index = 0;
+	u32 count = 0, i;
+	int ret = 0;
+
+	down_read(&ghvm->mem_lock);
+	mt_for_each(&ghvm->mem_layout, b, index, ULONG_MAX)
+		if (gunyah_guest_mem_is_lend(ghvm, b->flags))
+			count++;
+
+	if (!count)
+		goto out;
+
+	entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
+	if (!entries) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	index = i = 0;
+	mt_for_each(&ghvm->mem_layout, b, index, ULONG_MAX) {
+		if (!gunyah_guest_mem_is_lend(ghvm, b->flags))
+			continue;
+		entries[i].phys_addr = cpu_to_le64(gunyah_gfn_to_gpa(b->gfn));
+		entries[i].size = cpu_to_le64(b->nr << PAGE_SHIFT);
+		if (++i == count)
+			break;
+	}
+
+	ret = gunyah_rm_vm_set_demand_paging(ghvm->rm, ghvm->vmid, i, entries);
+	kfree(entries);
+out:
+	up_read(&ghvm->mem_lock);
+	return ret;
+}
+
+int gunyah_gmem_demand_page(struct gunyah_vm *ghvm, u64 gpa, bool write)
+{
+	unsigned long gfn = gunyah_gpa_to_gfn(gpa);
+	struct gunyah_gmem_binding *b;
+	struct folio *folio;
+	int ret;
+
+	down_read(&ghvm->mem_lock);
+	b = mtree_load(&ghvm->mem_layout, gfn);
+	if (!b) {
+		up_read(&ghvm->mem_lock);
+		return -ENOENT;
+	}
+
+	if (write && !(b->flags & GUNYAH_MEM_ALLOW_WRITE))
+		return -EPERM;
+
+	folio = gunyah_gmem_get_folio(b->inode, gunyah_gfn_to_off(b, gfn));
+	if (IS_ERR(folio)) {
+		up_read(&ghvm->mem_lock);
+		pr_err_ratelimited(
+			"Failed to obtain memory for guest addr %016llx: %ld\n",
+			gpa, PTR_ERR(folio));
+		return PTR_ERR(folio);
+	}
+
+	if (gunyah_guest_mem_is_lend(ghvm, b->flags) && folio_mapped(folio)) {
+		ret = -EPERM;
+		goto out;
+	}
+
+	gfn = gunyah_off_to_gfn(b, folio_index(folio));
+
+	ret = gunyah_vm_provide_folio(ghvm, folio, gfn,
+				      !gunyah_guest_mem_is_lend(ghvm, b->flags),
+				      !!(b->flags & GUNYAH_MEM_ALLOW_WRITE));
+	if (ret) {
+		pr_err_ratelimited(
+			"Failed to provide folio for guest addr: %016llx: %d\n",
+			gpa, ret);
+		goto out;
+	}
+
+	if (gunyah_guest_mem_is_lend(ghvm, b->flags))
+		folio_set_private(folio);
+out:
+	folio_unlock(folio);
+	folio_put(folio);
+	up_read(&ghvm->mem_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(gunyah_gmem_demand_page);
diff --git a/drivers/virt/gunyah/gunyah_vcpu.c b/drivers/virt/gunyah/gunyah_vcpu.c
index aa40f5977cbf..1952a1797430 100644
--- a/drivers/virt/gunyah/gunyah_vcpu.c
+++ b/drivers/virt/gunyah/gunyah_vcpu.c
@@ -91,6 +91,29 @@ static irqreturn_t gunyah_vcpu_irq_handler(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
+static bool gunyah_handle_page_fault(
+	struct gunyah_vcpu *vcpu, u64 state_data[3],
+	const struct gunyah_hypercall_vcpu_run_resp *vcpu_run_resp)
+{
+	int ret = 0;
+	u64 addr = vcpu_run_resp->state_data[0];
+	bool write = !!vcpu_run_resp->state_data[1];
+
+	ret = gunyah_gmem_demand_page(vcpu->ghvm, addr, write);
+	if (ret) {
+		if (ret != -ENOENT)
+			pr_warn_ratelimited(
+				"Failed to provide guest address for: %08llx: %d\n",
+				addr, ret);
+
+		vcpu->vcpu_run->page_fault.resume_action = GUNYAH_VCPU_RESUME_FAULT;
+		vcpu->vcpu_run->page_fault.attempt = ret;
+		vcpu->vcpu_run->page_fault.phys_addr = addr;
+		vcpu->vcpu_run->exit_reason = GUNYAH_VCPU_EXIT_PAGE_FAULT;
+	}
+	return !!ret;
+}
+
 static bool
 gunyah_handle_mmio(struct gunyah_vcpu *vcpu, u64 state_data[3],
 		   const struct gunyah_hypercall_vcpu_run_resp *vcpu_run_resp)
@@ -103,6 +126,12 @@ gunyah_handle_mmio(struct gunyah_vcpu *vcpu, u64 state_data[3],
 	if (WARN_ON(len > sizeof(u64)))
 		len = sizeof(u64);
 
+	if (!gunyah_gmem_demand_page(vcpu->ghvm, addr,
+				     vcpu->vcpu_run->mmio.is_write)) {
+		state_data[1] = GUNYAH_ADDRSPACE_VMMIO_ACTION_RETRY;
+		return true;
+	}
+
 	if (vcpu_run_resp->state == GUNYAH_VCPU_ADDRSPACE_VMMIO_READ) {
 		vcpu->vcpu_run->mmio.is_write = 0;
 		/* Record that we need to give vCPU user's supplied value next gunyah_vcpu_run() */
@@ -120,7 +149,8 @@ gunyah_handle_mmio(struct gunyah_vcpu *vcpu, u64 state_data[3],
 		vcpu->state = GUNYAH_VCPU_MMIO_WRITE;
 	}
 
-	vcpu->vcpu_run->mmio.phys_addr = addr;
+	vcpu->vcpu_run->mmio.resume_action = 0;
+	vcpu->mmio_addr = vcpu->vcpu_run->mmio.phys_addr = addr;
 	vcpu->vcpu_run->mmio.len = len;
 	vcpu->vcpu_run->exit_reason = GUNYAH_VCPU_EXIT_MMIO;
 
@@ -144,6 +174,8 @@ static int gunyah_handle_mmio_resume(struct gunyah_vcpu *vcpu, u64 state_data[3]
 		state_data[1] = GUNYAH_ADDRSPACE_VMMIO_ACTION_FAULT;
 		break;
 	case GUNYAH_VCPU_RESUME_RETRY:
+		gunyah_gmem_demand_page(vcpu->ghvm, vcpu->mmio_addr,
+					vcpu->state == GUNYAH_VCPU_MMIO_WRITE);
 		state_data[1] = GUNYAH_ADDRSPACE_VMMIO_ACTION_RETRY;
 		break;
 	default:
@@ -300,6 +332,11 @@ static int gunyah_vcpu_run(struct gunyah_vcpu *vcpu)
 							&vcpu_run_resp))
 					goto out;
 				break;
+			case GUNYAH_VCPU_ADDRSPACE_PAGE_FAULT:
+				if (gunyah_handle_page_fault(vcpu, resume_data,
+							     &vcpu_run_resp))
+					goto out;
+				break;
 			default:
 				pr_warn_ratelimited(
 					"Unknown vCPU state: %llx\n",
diff --git a/drivers/virt/gunyah/vm_mgr.c b/drivers/virt/gunyah/vm_mgr.c
index 8f8d962c9f8c..0bb2b6a461a5 100644
--- a/drivers/virt/gunyah/vm_mgr.c
+++ b/drivers/virt/gunyah/vm_mgr.c
@@ -653,6 +653,23 @@ static int gunyah_vm_start(struct gunyah_vm *ghvm)
 		goto err;
 	}
 
+	ret = gunyah_gmem_setup_demand_paging(ghvm);
+	if (ret) {
+		dev_warn(ghvm->parent,
+			 "Failed to set up gmem demand paging: %d\n", ret);
+		goto err;
+	}
+
+	ret = gunyah_rm_vm_set_address_layout(
+		ghvm->rm, ghvm->vmid, GUNYAH_RM_RANGE_ID_IMAGE,
+		ghvm->dtb.parcel_start << PAGE_SHIFT,
+		ghvm->dtb.parcel_pages << PAGE_SHIFT);
+	if (ret) {
+		dev_warn(ghvm->parent,
+			 "Failed to set location of DTB mem parcel: %d\n", ret);
+		goto err;
+	}
+
 	ret = gunyah_rm_vm_init(ghvm->rm, ghvm->vmid);
 	if (ret) {
 		ghvm->vm_status = GUNYAH_RM_VM_STATUS_INIT_FAILED;
diff --git a/drivers/virt/gunyah/vm_mgr.h b/drivers/virt/gunyah/vm_mgr.h
index 357414e67d72..088ed9c55376 100644
--- a/drivers/virt/gunyah/vm_mgr.h
+++ b/drivers/virt/gunyah/vm_mgr.h
@@ -98,4 +98,7 @@ int gunyah_gmem_reclaim_parcel(struct gunyah_vm *ghvm,
 			       struct gunyah_rm_mem_parcel *parcel, u64 gfn,
 			       u64 nr);
 
+int gunyah_gmem_setup_demand_paging(struct gunyah_vm *ghvm);
+int gunyah_gmem_demand_page(struct gunyah_vm *ghvm, u64 gpa, bool write);
+
 #endif
diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h
index ae9be5eef7a9..ed461acb9e1b 100644
--- a/include/linux/gunyah.h
+++ b/include/linux/gunyah.h
@@ -223,6 +223,8 @@ struct gunyah_hypercall_vcpu_run_resp {
 			GUNYAH_VCPU_ADDRSPACE_VMMIO_READ	= 4,
 			/* VCPU has returned for MMIO WRITE */
 			GUNYAH_VCPU_ADDRSPACE_VMMIO_WRITE	= 5,
+			/* Host needs to satisfy a page fault */
+			GUNYAH_VCPU_ADDRSPACE_PAGE_FAULT	= 7,
 			/* clang-format on */
 		} state;
 		u64 sized_state;

-- 
2.43.0



From daniel at makrotopia.org  Fri Dec 15 16:22:34 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 16 Dec 2023 00:22:34 +0000
Subject: [PATCH v6 2/5] dt-bindings: reset: mediatek: add MT7988 ethwarp
 reset IDs
In-Reply-To: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702685864.git.daniel@makrotopia.org>
References: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702685864.git.daniel@makrotopia.org>
Message-ID: <0c14bbacf471683af67ffa7572bfa1d5c45a0b5d.1702685864.git.daniel@makrotopia.org>

Add reset ID for ethwarp subsystem allowing to reset the built-in
Ethernet switch of the MediaTek MT7988 SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
v6: no changes
v5: add this patch to replace use of ti,syscon-reset in v1~v4

 include/dt-bindings/reset/mediatek,mt7988-resets.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 include/dt-bindings/reset/mediatek,mt7988-resets.h

diff --git a/include/dt-bindings/reset/mediatek,mt7988-resets.h b/include/dt-bindings/reset/mediatek,mt7988-resets.h
new file mode 100644
index 0000000000000..4933019713672
--- /dev/null
+++ b/include/dt-bindings/reset/mediatek,mt7988-resets.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ * Author: Daniel Golle <daniel at makrotopia.org>
+ */
+
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT7988
+#define _DT_BINDINGS_RESET_CONTROLLER_MT7988
+
+/* ETHWARP resets */
+#define MT7988_ETHWARP_RST_SWITCH		0
+
+#endif  /* _DT_BINDINGS_RESET_CONTROLLER_MT7988 */
-- 
2.43.0


From daniel at makrotopia.org  Fri Dec 15 16:23:02 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 16 Dec 2023 00:23:02 +0000
Subject: [PATCH v6 3/5] dt-bindings: clock: mediatek: add clock controllers
 of MT7988
In-Reply-To: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702685864.git.daniel@makrotopia.org>
References: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702685864.git.daniel@makrotopia.org>
Message-ID: <365bd4f704c6bcc39b9deec0539296703126ed39.1702685864.git.daniel@makrotopia.org>

Add various clock controllers found in the MT7988 SoC to existing
bindings (if applicable) and add files for the new ethwarp, mcusys
and xfi-pll clock controllers not previously present in any SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
v6:
 * remove invalid '_' from compatible string
 * drop minItems where uneeded due to listed clock-names
 * fix condition regarding presence of the 'pcs' subnode

v5:
 * drop use of ti,syscon-reset and hence also syscon and simple-mfd
   compatibles from mt7988-ethwarp clock controller which now got the
   clock controller provide the reset(s).

v4:
 * add subnodes for controllers acting as MFD

v3:
 * move clock bindings to clock folder
 * drop ti,syscon-reset from bindings and example
 * merge mcusys with topckgen bindings

v2:
 * dropped unused labels
 * add 'type: object' declaration for reset-controller found in new
   ethwarp controller and represented as ti,syscon-reset
 * rebase on top of
   "dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema"

 .../arm/mediatek/mediatek,infracfg.yaml       |  1 +
 .../bindings/clock/mediatek,apmixedsys.yaml   |  1 +
 .../bindings/clock/mediatek,ethsys.yaml       |  1 +
 .../clock/mediatek,mt7988-ethwarp.yaml        | 52 +++++++++++++++
 .../clock/mediatek,mt7988-xfi-pll.yaml        | 48 ++++++++++++++
 .../bindings/clock/mediatek,topckgen.yaml     |  2 +
 .../bindings/net/pcs/mediatek,sgmiisys.yaml   | 65 ++++++++++++++++---
 7 files changed, 161 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
index ea98043c6ba3d..230b5188a88db 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
@@ -30,6 +30,7 @@ properties:
               - mediatek,mt7629-infracfg
               - mediatek,mt7981-infracfg
               - mediatek,mt7986-infracfg
+              - mediatek,mt7988-infracfg
               - mediatek,mt8135-infracfg
               - mediatek,mt8167-infracfg
               - mediatek,mt8173-infracfg
diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
index 372c1d744bc27..685535846cbb7 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
@@ -22,6 +22,7 @@ properties:
           - mediatek,mt7622-apmixedsys
           - mediatek,mt7981-apmixedsys
           - mediatek,mt7986-apmixedsys
+          - mediatek,mt7988-apmixedsys
           - mediatek,mt8135-apmixedsys
           - mediatek,mt8173-apmixedsys
           - mediatek,mt8516-apmixedsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
index 94d42c8647777..f9cddacc2eae1 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
@@ -22,6 +22,7 @@ properties:
               - mediatek,mt7629-ethsys
               - mediatek,mt7981-ethsys
               - mediatek,mt7986-ethsys
+              - mediatek,mt7988-ethsys
           - const: syscon
       - items:
           - const: mediatek,mt7623-ethsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
new file mode 100644
index 0000000000000..b7f3b42438662
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-ethwarp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 ethwarp Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The Mediatek MT7988 ethwarp controller provides clocks and resets for the
+  Ethernet related subsystems found the MT7988 SoC.
+  The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
+
+properties:
+  compatible:
+    items:
+      - const: mediatek,mt7988-ethwarp
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+  '#reset-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - '#clock-cells'
+  - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/reset/ti-syscon.h>
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        clock-controller at 15031000 {
+            compatible = "mediatek,mt7988-ethwarp";
+            reg = <0 0x15031000 0 0x1000>;
+            #clock-cells = <1>;
+            #reset-cells = <1>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
new file mode 100644
index 0000000000000..fe5e3a70299fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7988-xfi-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 XFI PLL Clock Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The MediaTek XFI PLL controller provides the 156.25MHz clock for the
+  Ethernet SerDes PHY from the 40MHz top_xtal clock.
+
+properties:
+  compatible:
+    const: mediatek,mt7988-xfi-pll
+
+  reg:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - resets
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+        clock-controller at 11f40000 {
+            compatible = "mediatek,mt7988-xfi-pll";
+            reg = <0 0x11f40000 0 0x1000>;
+            resets = <&watchdog 16>;
+            #clock-cells = <1>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
index 6d087ded7437a..bdf3b55bd56fd 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
@@ -37,6 +37,8 @@ properties:
               - mediatek,mt7629-topckgen
               - mediatek,mt7981-topckgen
               - mediatek,mt7986-topckgen
+              - mediatek,mt7988-mcusys
+              - mediatek,mt7988-topckgen
               - mediatek,mt8167-topckgen
               - mediatek,mt8183-topckgen
           - const: syscon
diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
index 66a95191bd776..1bacc0eeff757 100644
--- a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
+++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
@@ -15,15 +15,22 @@ description:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - mediatek,mt7622-sgmiisys
-          - mediatek,mt7629-sgmiisys
-          - mediatek,mt7981-sgmiisys_0
-          - mediatek,mt7981-sgmiisys_1
-          - mediatek,mt7986-sgmiisys_0
-          - mediatek,mt7986-sgmiisys_1
-      - const: syscon
+    oneOf:
+      - items:
+          - enum:
+              - mediatek,mt7622-sgmiisys
+              - mediatek,mt7629-sgmiisys
+              - mediatek,mt7981-sgmiisys_0
+              - mediatek,mt7981-sgmiisys_1
+              - mediatek,mt7986-sgmiisys_0
+              - mediatek,mt7986-sgmiisys_1
+          - const: syscon
+      - items:
+          - enum:
+              - mediatek,mt7988-sgmiisys0
+              - mediatek,mt7988-sgmiisys1
+          - const: simple-mfd
+          - const: syscon
 
   reg:
     maxItems: 1
@@ -35,11 +42,51 @@ properties:
     description: Invert polarity of the SGMII data lanes
     type: boolean
 
+  pcs:
+    type: object
+    description: MediaTek LynxI HSGMII PCS
+    properties:
+      compatible:
+        const: mediatek,mt7988-sgmii
+
+      clocks:
+        maxItems: 3
+
+      clock-names:
+        items:
+          - const: sgmii_sel
+          - const: sgmii_tx
+          - const: sgmii_rx
+
+    required:
+      - compatible
+      - clocks
+      - clock-names
+
+    additionalProperties: false
+
 required:
   - compatible
   - reg
   - '#clock-cells'
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - mediatek,mt7988-sgmiisys0
+              - mediatek,mt7988-sgmiisys1
+
+    then:
+      required:
+        - pcs
+
+    else:
+      properties:
+        pcs: false
+
 additionalProperties: false
 
 examples:
-- 
2.43.0


From daniel at makrotopia.org  Fri Dec 15 16:23:14 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 16 Dec 2023 00:23:14 +0000
Subject: [PATCH v6 4/5] clk: mediatek: add pcw_chg_bit control for PLLs of
 MT7988
In-Reply-To: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702685864.git.daniel@makrotopia.org>
References: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702685864.git.daniel@makrotopia.org>
Message-ID: <384cb034139239e06d1f8091492f47263b66e2e9.1702685864.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Introduce pcw_chg_bit member to struct mtk_pll_data and use it instead
of the previously hardcoded PCW_CHG_MASK macro if set.
This will needed for clocks on the MT7988 SoC.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
v6: no changes
v5: rename to .pcw_chg_bit, use ? operator instead of changing every
    single existing driver. The approach in v4 doesn't work as
    if .pcw_chg_reg is unset/0, pll->pcw_chg_addr will default to
    pll->base_addr + REG_CON1. Hence setting .pcw_chg_bit would be
    required for *all* drivers instead of just those setting
    .pcs_chf_reg. And that seems like an excessive change which can
    easily be avoided by using the ? operator to set the default
    at runtime (and we can easily cope with that overhead).
v4: always set .pcw_chg_shift if .pcw_chg_reg is used instead of
    having an if-expression in mtk_pll_set_rate_regs().
v3: use git --from ...
v2: no changes
 drivers/clk/mediatek/clk-pll.c | 5 +++--
 drivers/clk/mediatek/clk-pll.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index 513ab6b1b3229..ce453e1718e53 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -23,7 +23,7 @@
 #define CON0_BASE_EN		BIT(0)
 #define CON0_PWR_ON		BIT(0)
 #define CON0_ISO_EN		BIT(1)
-#define PCW_CHG_MASK		BIT(31)
+#define PCW_CHG_BIT		31
 
 #define AUDPLL_TUNER_EN		BIT(31)
 
@@ -114,7 +114,8 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll, u32 pcw,
 			pll->data->pcw_shift);
 	val |= pcw << pll->data->pcw_shift;
 	writel(val, pll->pcw_addr);
-	chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
+	chg = readl(pll->pcw_chg_addr) |
+	      BIT(pll->data->pcw_chg_bit ? : PCW_CHG_BIT);
 	writel(chg, pll->pcw_chg_addr);
 	if (pll->tuner_addr)
 		writel(val + 1, pll->tuner_addr);
diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
index f17278ff15d78..285c8db958b39 100644
--- a/drivers/clk/mediatek/clk-pll.h
+++ b/drivers/clk/mediatek/clk-pll.h
@@ -48,6 +48,7 @@ struct mtk_pll_data {
 	const char *parent_name;
 	u32 en_reg;
 	u8 pll_en_bit; /* Assume 0, indicates BIT(0) by default */
+	u8 pcw_chg_bit;
 };
 
 /*
-- 
2.43.0


From daniel at makrotopia.org  Fri Dec 15 16:23:37 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 16 Dec 2023 00:23:37 +0000
Subject: [PATCH v6 5/5] clk: mediatek: add drivers for MT7988 SoC
In-Reply-To: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702685864.git.daniel@makrotopia.org>
References: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702685864.git.daniel@makrotopia.org>
Message-ID: <2f8e7983e51beb973d5639be54a4ea9399c28b13.1702685864.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add APMIXED, ETH, INFRACFG and TOPCKGEN clock drivers which are
typical MediaTek designs.

Also add driver for XFIPLL clock generating the 156.25MHz clock for
the XFI SerDes. It needs an undocumented software workaround and has
an unknown internal design.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
v6: no changes
v5:
 * more nicely format macro defintions
 * register reset controller for ethwarp clock controller
 * drop redundant GATE_SGMII1 which is indentical to GATE_SGMII0
   in favor of single GATE_SGMII macro

v4:
 * make use of existing GATE_MTK_FLAGS macro
 * reformat to max. 100 columns
 * cosmetics

v3: use git --from ...
v2: no changes
 drivers/clk/mediatek/Kconfig               |   9 +
 drivers/clk/mediatek/Makefile              |   5 +
 drivers/clk/mediatek/clk-mt7988-apmixed.c  | 114 ++++++++
 drivers/clk/mediatek/clk-mt7988-eth.c      | 150 ++++++++++
 drivers/clk/mediatek/clk-mt7988-infracfg.c | 274 +++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-topckgen.c | 325 +++++++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-xfipll.c   |  82 ++++++
 7 files changed, 959 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt7988-apmixed.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-eth.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-infracfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-topckgen.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-xfipll.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 48b42d11111cd..70a005e7e1b18 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -423,6 +423,15 @@ config COMMON_CLK_MT7986_ETHSYS
 	  This driver adds support for clocks for Ethernet and SGMII
 	  required on MediaTek MT7986 SoC.
 
+config COMMON_CLK_MT7988
+	tristate "Clock driver for MediaTek MT7988"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	select COMMON_CLK_MEDIATEK
+	default ARCH_MEDIATEK
+	help
+	  This driver supports MediaTek MT7988 basic clocks and clocks
+	  required for various periperals found on this SoC.
+
 config COMMON_CLK_MT8135
 	tristate "Clock driver for MediaTek MT8135"
 	depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index dbeaa5b41177d..eeccfa039896f 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -62,6 +62,11 @@ obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-apmixed.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-topckgen.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-infracfg.o
 obj-$(CONFIG_COMMON_CLK_MT7986_ETHSYS) += clk-mt7986-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-apmixed.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-topckgen.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-infracfg.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-xfipll.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135-apmixedsys.o clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8167) += clk-mt8167-apmixedsys.o clk-mt8167.o
 obj-$(CONFIG_COMMON_CLK_MT8167_AUDSYS) += clk-mt8167-aud.o
diff --git a/drivers/clk/mediatek/clk-mt7988-apmixed.c b/drivers/clk/mediatek/clk-mt7988-apmixed.c
new file mode 100644
index 0000000000000..baf9564351a33
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-apmixed.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include "clk-pll.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+#define MT7988_PLL_FMAX (2500UL * MHZ)
+#define MT7988_PCW_CHG_BIT 2
+
+#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _rst_bar_mask, _pcwbits, _pd_reg,	\
+	    _pd_shift, _tuner_reg, _tuner_en_reg, _tuner_en_bit, _pcw_reg, _pcw_shift,		\
+	    _pcw_chg_reg)									\
+	{											\
+		.id = _id,									\
+		.name = _name,									\
+		.reg = _reg,									\
+		.pwr_reg = _pwr_reg,								\
+		.en_mask = _en_mask,								\
+		.flags = _flags,								\
+		.rst_bar_mask = BIT(_rst_bar_mask),						\
+		.fmax = MT7988_PLL_FMAX,							\
+		.pcwbits = _pcwbits,								\
+		.pd_reg = _pd_reg,								\
+		.pd_shift = _pd_shift,								\
+		.tuner_reg = _tuner_reg,							\
+		.tuner_en_reg = _tuner_en_reg,							\
+		.tuner_en_bit = _tuner_en_bit,							\
+		.pcw_reg = _pcw_reg,								\
+		.pcw_shift = _pcw_shift,							\
+		.pcw_chg_reg = _pcw_chg_reg,							\
+		.pcw_chg_bit = MT7988_PCW_CHG_BIT,						\
+		.parent_name = "clkxtal",							\
+	}
+
+static const struct mtk_pll_data plls[] = {
+	PLL(CLK_APMIXED_NETSYSPLL, "netsyspll", 0x0104, 0x0110, 0x00000001, 0, 0, 32, 0x0104, 4, 0,
+	    0, 0, 0x0108, 0, 0x0104),
+	PLL(CLK_APMIXED_MPLL, "mpll", 0x0114, 0x0120, 0xff000001, HAVE_RST_BAR, 23, 32, 0x0114, 4,
+	    0, 0, 0, 0x0118, 0, 0x0114),
+	PLL(CLK_APMIXED_MMPLL, "mmpll", 0x0124, 0x0130, 0xff000001, HAVE_RST_BAR, 23, 32, 0x0124, 4,
+	    0, 0, 0, 0x0128, 0, 0x0124),
+	PLL(CLK_APMIXED_APLL2, "apll2", 0x0134, 0x0140, 0x00000001, 0, 0, 32, 0x0134, 4, 0x0704,
+	    0x0700, 1, 0x0138, 0, 0x0134),
+	PLL(CLK_APMIXED_NET1PLL, "net1pll", 0x0144, 0x0150, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0144, 4, 0, 0, 0, 0x0148, 0, 0x0144),
+	PLL(CLK_APMIXED_NET2PLL, "net2pll", 0x0154, 0x0160, 0xff000001, (HAVE_RST_BAR | PLL_AO), 23,
+	    32, 0x0154, 4, 0, 0, 0, 0x0158, 0, 0x0154),
+	PLL(CLK_APMIXED_WEDMCUPLL, "wedmcupll", 0x0164, 0x0170, 0x00000001, 0, 0, 32, 0x0164, 4, 0,
+	    0, 0, 0x0168, 0, 0x0164),
+	PLL(CLK_APMIXED_SGMPLL, "sgmpll", 0x0174, 0x0180, 0x00000001, 0, 0, 32, 0x0174, 4, 0, 0, 0,
+	    0x0178, 0, 0x0174),
+	PLL(CLK_APMIXED_ARM_B, "arm_b", 0x0204, 0x0210, 0xff000001, (HAVE_RST_BAR | PLL_AO), 23, 32,
+	    0x0204, 4, 0, 0, 0, 0x0208, 0, 0x0204),
+	PLL(CLK_APMIXED_CCIPLL2_B, "ccipll2_b", 0x0214, 0x0220, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0214, 4, 0, 0, 0, 0x0218, 0, 0x0214),
+	PLL(CLK_APMIXED_USXGMIIPLL, "usxgmiipll", 0x0304, 0x0310, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0304, 4, 0, 0, 0, 0x0308, 0, 0x0304),
+	PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x0314, 0x0320, 0x00000001, 0, 0, 32, 0x0314, 4, 0, 0,
+	    0, 0x0318, 0, 0x0314),
+};
+
+static const struct of_device_id of_match_clk_mt7988_apmixed[] = {
+	{ .compatible = "mediatek,mt7988-apmixedsys" },
+	{ /* sentinel */ }
+};
+
+static int clk_mt7988_apmixed_probe(struct platform_device *pdev)
+{
+	struct clk_hw_onecell_data *clk_data;
+	struct device_node *node = pdev->dev.of_node;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(ARRAY_SIZE(plls));
+	if (!clk_data)
+		return -ENOMEM;
+
+	r = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	if (r)
+		goto free_apmixed_data;
+
+	r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
+	if (r)
+		goto unregister_plls;
+
+	return r;
+
+unregister_plls:
+	mtk_clk_unregister_plls(plls, ARRAY_SIZE(plls), clk_data);
+free_apmixed_data:
+	mtk_free_clk_data(clk_data);
+	return r;
+}
+
+static struct platform_driver clk_mt7988_apmixed_drv = {
+	.probe = clk_mt7988_apmixed_probe,
+	.driver = {
+		.name = "clk-mt7988-apmixed",
+		.of_match_table = of_match_clk_mt7988_apmixed,
+	},
+};
+builtin_platform_driver(clk_mt7988_apmixed_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-eth.c b/drivers/clk/mediatek/clk-mt7988-eth.c
new file mode 100644
index 0000000000000..adf4a9d39b38f
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-eth.c
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "reset.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+#include <dt-bindings/reset/mediatek,mt7988-resets.h>
+
+static const struct mtk_gate_regs ethdma_cg_regs = {
+	.set_ofs = 0x30,
+	.clr_ofs = 0x30,
+	.sta_ofs = 0x30,
+};
+
+#define GATE_ETHDMA(_id, _name, _parent, _shift)		\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &ethdma_cg_regs,			\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_gate ethdma_clks[] = {
+	GATE_ETHDMA(CLK_ETHDMA_XGP1_EN, "ethdma_xgp1_en", "top_xtal", 0),
+	GATE_ETHDMA(CLK_ETHDMA_XGP2_EN, "ethdma_xgp2_en", "top_xtal", 1),
+	GATE_ETHDMA(CLK_ETHDMA_XGP3_EN, "ethdma_xgp3_en", "top_xtal", 2),
+	GATE_ETHDMA(CLK_ETHDMA_FE_EN, "ethdma_fe_en", "netsys_2x_sel", 6),
+	GATE_ETHDMA(CLK_ETHDMA_GP2_EN, "ethdma_gp2_en", "top_xtal", 7),
+	GATE_ETHDMA(CLK_ETHDMA_GP1_EN, "ethdma_gp1_en", "top_xtal", 8),
+	GATE_ETHDMA(CLK_ETHDMA_GP3_EN, "ethdma_gp3_en", "top_xtal", 10),
+	GATE_ETHDMA(CLK_ETHDMA_ESW_EN, "ethdma_esw_en", "netsys_gsw_sel", 16),
+	GATE_ETHDMA(CLK_ETHDMA_CRYPT0_EN, "ethdma_crypt0_en", "eip197_sel", 29),
+};
+
+static const struct mtk_clk_desc ethdma_desc = {
+	.clks = ethdma_clks,
+	.num_clks = ARRAY_SIZE(ethdma_clks),
+};
+
+static const struct mtk_gate_regs sgmii_cg_regs = {
+	.set_ofs = 0xe4,
+	.clr_ofs = 0xe4,
+	.sta_ofs = 0xe4,
+};
+
+#define GATE_SGMII(_id, _name, _parent, _shift)			\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &sgmii_cg_regs,				\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_gate sgmii0_clks[] = {
+	GATE_SGMII(CLK_SGM0_TX_EN, "sgm0_tx_en", "top_xtal", 2),
+	GATE_SGMII(CLK_SGM0_RX_EN, "sgm0_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii0_desc = {
+	.clks = sgmii0_clks,
+	.num_clks = ARRAY_SIZE(sgmii0_clks),
+};
+
+static const struct mtk_gate sgmii1_clks[] = {
+	GATE_SGMII(CLK_SGM1_TX_EN, "sgm1_tx_en", "top_xtal", 2),
+	GATE_SGMII(CLK_SGM1_RX_EN, "sgm1_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii1_desc = {
+	.clks = sgmii1_clks,
+	.num_clks = ARRAY_SIZE(sgmii1_clks),
+};
+
+static const struct mtk_gate_regs ethwarp_cg_regs = {
+	.set_ofs = 0x14,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x14,
+};
+
+#define GATE_ETHWARP(_id, _name, _parent, _shift)		\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &ethwarp_cg_regs,			\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_gate ethwarp_clks[] = {
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU2_EN, "ethwarp_wocpu2_en", "netsys_mcu_sel", 13),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU1_EN, "ethwarp_wocpu1_en", "netsys_mcu_sel", 14),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU0_EN, "ethwarp_wocpu0_en", "netsys_mcu_sel", 15),
+};
+
+static u16 ethwarp_rst_ofs[] = { 0x8 };
+
+static u16 ethwarp_idx_map[] = {
+	[MT7988_ETHWARP_RST_SWITCH] = 9,
+};
+
+static const struct mtk_clk_rst_desc ethwarp_rst_desc = {
+	.version = MTK_RST_SIMPLE,
+	.rst_bank_ofs = ethwarp_rst_ofs,
+	.rst_bank_nr = ARRAY_SIZE(ethwarp_rst_ofs),
+	.rst_idx_map = ethwarp_idx_map,
+	.rst_idx_map_nr = ARRAY_SIZE(ethwarp_idx_map),
+};
+
+static const struct mtk_clk_desc ethwarp_desc = {
+	.clks = ethwarp_clks,
+	.num_clks = ARRAY_SIZE(ethwarp_clks),
+	.rst_desc = &ethwarp_rst_desc,
+};
+
+static const struct of_device_id of_match_clk_mt7988_eth[] = {
+	{ .compatible = "mediatek,mt7988-ethsys", .data = &ethdma_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys0", .data = &sgmii0_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys1", .data = &sgmii1_desc },
+	{ .compatible = "mediatek,mt7988-ethwarp", .data = &ethwarp_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_eth);
+
+static struct platform_driver clk_mt7988_eth_drv = {
+	.driver = {
+		.name = "clk-mt7988-eth",
+		.of_match_table = of_match_clk_mt7988_eth,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_eth_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 Ethernet clocks driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-infracfg.c b/drivers/clk/mediatek/clk-mt7988-infracfg.c
new file mode 100644
index 0000000000000..b7b4f7626d3d6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-infracfg.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const char *const infra_mux_uart0_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_uart1_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_uart2_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_spi0_parents[] __initconst = { "i2c_sel", "spi_sel" };
+
+static const char *const infra_mux_spi1_parents[] __initconst = { "i2c_sel", "spim_mst_sel" };
+
+static const char *const infra_pwm_bck_parents[] __initconst = { "top_rtc_32p7k",
+								 "csw_infra_f26m_sel", "sysaxi_sel",
+								 "pwm_sel" };
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p0_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p1_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p1_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p2_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p2_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p3_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p3_sel"
+};
+
+static const struct mtk_mux infra_muxes[] = {
+	/* MODULE_CLK_SEL_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART0_SEL, "infra_mux_uart0_sel",
+			     infra_mux_uart0_parents, 0x0018, 0x0010, 0x0014, 0, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART1_SEL, "infra_mux_uart1_sel",
+			     infra_mux_uart1_parents, 0x0018, 0x0010, 0x0014, 1, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART2_SEL, "infra_mux_uart2_sel",
+			     infra_mux_uart2_parents, 0x0018, 0x0010, 0x0014, 2, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI0_SEL, "infra_mux_spi0_sel", infra_mux_spi0_parents,
+			     0x0018, 0x0010, 0x0014, 4, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI1_SEL, "infra_mux_spi1_sel", infra_mux_spi1_parents,
+			     0x0018, 0x0010, 0x0014, 5, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI2_SEL, "infra_mux_spi2_sel", infra_mux_spi0_parents,
+			     0x0018, 0x0010, 0x0014, 6, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_SEL, "infra_pwm_sel", infra_pwm_bck_parents, 0x0018,
+			     0x0010, 0x0014, 14, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK1_SEL, "infra_pwm_ck1_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 16, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK2_SEL, "infra_pwm_ck2_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 18, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK3_SEL, "infra_pwm_ck3_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 20, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK4_SEL, "infra_pwm_ck4_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 22, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK5_SEL, "infra_pwm_ck5_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 24, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK6_SEL, "infra_pwm_ck6_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 26, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK7_SEL, "infra_pwm_ck7_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 28, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK8_SEL, "infra_pwm_ck8_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 30, 2, -1, -1, -1),
+	/* MODULE_CLK_SEL_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL, "infra_pcie_gfmux_tl_o_p0_sel",
+			     infra_pcie_gfmux_tl_ck_o_p0_parents, 0x0028, 0x0020, 0x0024, 0, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL, "infra_pcie_gfmux_tl_o_p1_sel",
+			     infra_pcie_gfmux_tl_ck_o_p1_parents, 0x0028, 0x0020, 0x0024, 2, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL, "infra_pcie_gfmux_tl_o_p2_sel",
+			     infra_pcie_gfmux_tl_ck_o_p2_parents, 0x0028, 0x0020, 0x0024, 4, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL, "infra_pcie_gfmux_tl_o_p3_sel",
+			     infra_pcie_gfmux_tl_ck_o_p3_parents, 0x0028, 0x0020, 0x0024, 6, 2, -1,
+			     -1, -1),
+};
+
+static const struct mtk_gate_regs infra0_cg_regs = {
+	.set_ofs = 0x10,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x18,
+};
+
+static const struct mtk_gate_regs infra1_cg_regs = {
+	.set_ofs = 0x40,
+	.clr_ofs = 0x44,
+	.sta_ofs = 0x48,
+};
+
+static const struct mtk_gate_regs infra2_cg_regs = {
+	.set_ofs = 0x50,
+	.clr_ofs = 0x54,
+	.sta_ofs = 0x58,
+};
+
+static const struct mtk_gate_regs infra3_cg_regs = {
+	.set_ofs = 0x60,
+	.clr_ofs = 0x64,
+	.sta_ofs = 0x68,
+};
+
+#define GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra0_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra1_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra2_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra3_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA0(_id, _name, _parent, _shift) GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA1(_id, _name, _parent, _shift) GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA2(_id, _name, _parent, _shift) GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA3(_id, _name, _parent, _shift) GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, 0)
+
+static const struct mtk_gate infra_clks[] = {
+	/* INFRA0 */
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P0, "infra_pcie_peri_ck_26m_ck_p0",
+		    "csw_infra_f26m_sel", 7),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P1, "infra_pcie_peri_ck_26m_ck_p1",
+		    "csw_infra_f26m_sel", 8),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P2, "infra_pcie_peri_ck_26m_ck_p2",
+		    "csw_infra_f26m_sel", 9),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P3, "infra_pcie_peri_ck_26m_ck_p3",
+		    "csw_infra_f26m_sel", 10),
+	/* INFRA1 */
+	GATE_INFRA1(CLK_INFRA_66M_GPT_BCK, "infra_hf_66m_gpt_bck", "sysaxi_sel", 0),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_HCK, "infra_hf_66m_pwm_hck", "sysaxi_sel", 1),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_BCK, "infra_hf_66m_pwm_bck", "infra_pwm_sel", 2),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK1, "infra_hf_66m_pwm_ck1", "infra_pwm_ck1_sel", 3),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK2, "infra_hf_66m_pwm_ck2", "infra_pwm_ck2_sel", 4),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK3, "infra_hf_66m_pwm_ck3", "infra_pwm_ck3_sel", 5),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK4, "infra_hf_66m_pwm_ck4", "infra_pwm_ck4_sel", 6),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK5, "infra_hf_66m_pwm_ck5", "infra_pwm_ck5_sel", 7),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK6, "infra_hf_66m_pwm_ck6", "infra_pwm_ck6_sel", 8),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK7, "infra_hf_66m_pwm_ck7", "infra_pwm_ck7_sel", 9),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK8, "infra_hf_66m_pwm_ck8", "infra_pwm_ck8_sel", 10),
+	GATE_INFRA1(CLK_INFRA_133M_CQDMA_BCK, "infra_hf_133m_cqdma_bck", "sysaxi_sel", 12),
+	GATE_INFRA1(CLK_INFRA_66M_AUD_SLV_BCK, "infra_66m_aud_slv_bck", "sysaxi_sel", 13),
+	GATE_INFRA1(CLK_INFRA_AUD_26M, "infra_f_faud_26m", "csw_infra_f26m_sel", 14),
+	GATE_INFRA1(CLK_INFRA_AUD_L, "infra_f_faud_l", "aud_l_sel", 15),
+	GATE_INFRA1(CLK_INFRA_AUD_AUD, "infra_f_aud_aud", "a1sys_sel", 16),
+	GATE_INFRA1(CLK_INFRA_AUD_EG2, "infra_f_faud_eg2", "a_tuner_sel", 18),
+	GATE_INFRA1_FLAGS(CLK_INFRA_DRAMC_F26M, "infra_dramc_f26m", "csw_infra_f26m_sel", 19,
+			  CLK_IS_CRITICAL),
+	/* JTAG */
+	GATE_INFRA1_FLAGS(CLK_INFRA_133M_DBG_ACKM, "infra_hf_133m_dbg_ackm", "sysaxi_sel", 20,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA1(CLK_INFRA_66M_AP_DMA_BCK, "infra_66m_ap_dma_bck", "sysaxi_sel", 21),
+	GATE_INFRA1(CLK_INFRA_66M_SEJ_BCK, "infra_hf_66m_sej_bck", "sysaxi_sel", 29),
+	GATE_INFRA1(CLK_INFRA_PRE_CK_SEJ_F13M, "infra_pre_ck_sej_f13m", "csw_infra_f26m_sel", 30),
+	/* INFRA2 */
+	GATE_INFRA2(CLK_INFRA_26M_THERM_SYSTEM, "infra_hf_26m_therm_system", "csw_infra_f26m_sel",
+		    0),
+	GATE_INFRA2(CLK_INFRA_I2C_BCK, "infra_i2c_bck", "i2c_sel", 1),
+	GATE_INFRA2(CLK_INFRA_52M_UART0_CK, "infra_f_52m_uart0", "infra_mux_uart0_sel", 3),
+	GATE_INFRA2(CLK_INFRA_52M_UART1_CK, "infra_f_52m_uart1", "infra_mux_uart1_sel", 4),
+	GATE_INFRA2(CLK_INFRA_52M_UART2_CK, "infra_f_52m_uart2", "infra_mux_uart2_sel", 5),
+	GATE_INFRA2(CLK_INFRA_NFI, "infra_f_fnfi", "nfi1x_sel", 9),
+	GATE_INFRA2(CLK_INFRA_SPINFI, "infra_f_fspinfi", "spinfi_sel", 10),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_NFI_HCK, "infra_hf_66m_nfi_hck", "sysaxi_sel", 11,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2_FLAGS(CLK_INFRA_104M_SPI0, "infra_hf_104m_spi0", "infra_mux_spi0_sel", 12,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_104M_SPI1, "infra_hf_104m_spi1", "infra_mux_spi1_sel", 13),
+	GATE_INFRA2(CLK_INFRA_104M_SPI2_BCK, "infra_hf_104m_spi2_bck", "infra_mux_spi2_sel", 14),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_SPI0_HCK, "infra_hf_66m_spi0_hck", "sysaxi_sel", 15,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_66M_SPI1_HCK, "infra_hf_66m_spi1_hck", "sysaxi_sel", 16),
+	GATE_INFRA2(CLK_INFRA_66M_SPI2_HCK, "infra_hf_66m_spi2_hck", "sysaxi_sel", 17),
+	GATE_INFRA2(CLK_INFRA_66M_FLASHIF_AXI, "infra_hf_66m_flashif_axi", "sysaxi_sel", 18),
+	GATE_INFRA2_FLAGS(CLK_INFRA_RTC, "infra_f_frtc", "top_rtc_32k", 19, CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_26M_ADC_BCK, "infra_f_26m_adc_bck", "csw_infra_f26m_sel", 20),
+	GATE_INFRA2(CLK_INFRA_RC_ADC, "infra_f_frc_adc", "infra_f_26m_adc_bck", 21),
+	GATE_INFRA2(CLK_INFRA_MSDC400, "infra_f_fmsdc400", "emmc_400m_sel", 22),
+	GATE_INFRA2(CLK_INFRA_MSDC2_HCK, "infra_f_fmsdc2_hck", "emmc_250m_sel", 23),
+	GATE_INFRA2(CLK_INFRA_133M_MSDC_0_HCK, "infra_hf_133m_msdc_0_hck", "sysaxi_sel", 24),
+	GATE_INFRA2(CLK_INFRA_66M_MSDC_0_HCK, "infra_66m_msdc_0_hck", "sysaxi_sel", 25),
+	GATE_INFRA2(CLK_INFRA_133M_CPUM_BCK, "infra_hf_133m_cpum_bck", "sysaxi_sel", 26),
+	GATE_INFRA2(CLK_INFRA_BIST2FPC, "infra_hf_fbist2fpc", "nfi1x_sel", 27),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_MCK_CK_P1, "infra_hf_i2c_x16w_mck_ck_p1", "sysaxi_sel", 29),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_PCK_CK_P1, "infra_hf_i2c_x16w_pck_ck_p1", "sysaxi_sel", 31),
+	/* INFRA3 */
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK, "infra_133m_usb_hck", "sysaxi_sel", 0),
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK_CK_P1, "infra_133m_usb_hck_ck_p1", "sysaxi_sel", 1),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK, "infra_66m_usb_hck", "sysaxi_sel", 2),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK_CK_P1, "infra_66m_usb_hck_ck_p1", "sysaxi_sel", 3),
+	GATE_INFRA3(CLK_INFRA_USB_SYS, "infra_usb_sys", "usb_sys_sel", 4),
+	GATE_INFRA3(CLK_INFRA_USB_SYS_CK_P1, "infra_usb_sys_ck_p1", "usb_sys_p1_sel", 5),
+	GATE_INFRA3(CLK_INFRA_USB_REF, "infra_usb_ref", "top_xtal", 6),
+	GATE_INFRA3(CLK_INFRA_USB_CK_P1, "infra_usb_ck_p1", "top_xtal", 7),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT, "infra_usb_frmcnt", "usb_frmcnt_sel", 8,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT_CK_P1, "infra_usb_frmcnt_ck_p1", "usb_frmcnt_p1_sel",
+			  9, CLK_IS_CRITICAL),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE, "infra_usb_pipe", "sspxtp_sel", 10),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE_CK_P1, "infra_usb_pipe_ck_p1", "usb_phy_sel", 11),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI, "infra_usb_utmi", "top_xtal", 12),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI_CK_P1, "infra_usb_utmi_ck_p1", "top_xtal", 13),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI, "infra_usb_xhci", "usb_xhci_sel", 14),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI_CK_P1, "infra_usb_xhci_ck_p1", "usb_xhci_p1_sel", 15),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P0, "infra_pcie_gfmux_tl_ck_p0",
+		    "infra_pcie_gfmux_tl_o_p0_sel", 20),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P1, "infra_pcie_gfmux_tl_ck_p1",
+		    "infra_pcie_gfmux_tl_o_p1_sel", 21),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P2, "infra_pcie_gfmux_tl_ck_p2",
+		    "infra_pcie_gfmux_tl_o_p2_sel", 22),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P3, "infra_pcie_gfmux_tl_ck_p3",
+		    "infra_pcie_gfmux_tl_o_p3_sel", 23),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P0, "infra_pcie_pipe_ck_p0", "top_xtal", 24),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P1, "infra_pcie_pipe_ck_p1", "top_xtal", 25),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P2, "infra_pcie_pipe_ck_p2", "top_xtal", 26),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P3, "infra_pcie_pipe_ck_p3", "top_xtal", 27),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P0, "infra_133m_pcie_ck_p0", "sysaxi_sel", 28),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P1, "infra_133m_pcie_ck_p1", "sysaxi_sel", 29),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P2, "infra_133m_pcie_ck_p2", "sysaxi_sel", 30),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P3, "infra_133m_pcie_ck_p3", "sysaxi_sel", 31),
+};
+
+static const struct mtk_clk_desc infra_desc = {
+	.clks = infra_clks,
+	.num_clks = ARRAY_SIZE(infra_clks),
+	.mux_clks = infra_muxes,
+	.num_mux_clks = ARRAY_SIZE(infra_muxes),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const struct of_device_id of_match_clk_mt7988_infracfg[] = {
+	{ .compatible = "mediatek,mt7988-infracfg", .data = &infra_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_infracfg);
+
+static struct platform_driver clk_mt7988_infracfg_drv = {
+	.driver = {
+		.name = "clk-mt7988-infracfg",
+		.of_match_table = of_match_clk_mt7988_infracfg,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_infracfg_drv);
diff --git a/drivers/clk/mediatek/clk-mt7988-topckgen.c b/drivers/clk/mediatek/clk-mt7988-topckgen.c
new file mode 100644
index 0000000000000..760f8e0d2f26a
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-topckgen.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+	FIXED_CLK(CLK_TOP_XTAL, "top_xtal", "clkxtal", 40000000),
+};
+
+static const struct mtk_fixed_factor top_divs[] = {
+	FACTOR(CLK_TOP_XTAL_D2, "top_xtal_d2", "top_xtal", 1, 2),
+	FACTOR(CLK_TOP_RTC_32K, "top_rtc_32k", "top_xtal", 1, 1250),
+	FACTOR(CLK_TOP_RTC_32P7K, "top_rtc_32p7k", "top_xtal", 1, 1220),
+	FACTOR(CLK_TOP_MPLL_D2, "mpll_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D3_D2, "mpll_d3_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D4, "mpll_d4", "mpll", 1, 4),
+	FACTOR(CLK_TOP_MPLL_D8, "mpll_d8", "mpll", 1, 8),
+	FACTOR(CLK_TOP_MPLL_D8_D2, "mpll_d8_d2", "mpll", 1, 16),
+	FACTOR(CLK_TOP_MMPLL_D2, "mmpll_d2", "mmpll", 1, 2),
+	FACTOR(CLK_TOP_MMPLL_D3_D5, "mmpll_d3_d5", "mmpll", 1, 15),
+	FACTOR(CLK_TOP_MMPLL_D4, "mmpll_d4", "mmpll", 1, 4),
+	FACTOR(CLK_TOP_MMPLL_D6_D2, "mmpll_d6_d2", "mmpll", 1, 12),
+	FACTOR(CLK_TOP_MMPLL_D8, "mmpll_d8", "mmpll", 1, 8),
+	FACTOR(CLK_TOP_APLL2_D4, "apll2_d4", "apll2", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D4, "net1pll_d4", "net1pll", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D5, "net1pll_d5", "net1pll", 1, 5),
+	FACTOR(CLK_TOP_NET1PLL_D5_D2, "net1pll_d5_d2", "net1pll", 1, 10),
+	FACTOR(CLK_TOP_NET1PLL_D5_D4, "net1pll_d5_d4", "net1pll", 1, 20),
+	FACTOR(CLK_TOP_NET1PLL_D8, "net1pll_d8", "net1pll", 1, 8),
+	FACTOR(CLK_TOP_NET1PLL_D8_D2, "net1pll_d8_d2", "net1pll", 1, 16),
+	FACTOR(CLK_TOP_NET1PLL_D8_D4, "net1pll_d8_d4", "net1pll", 1, 32),
+	FACTOR(CLK_TOP_NET1PLL_D8_D8, "net1pll_d8_d8", "net1pll", 1, 64),
+	FACTOR(CLK_TOP_NET1PLL_D8_D16, "net1pll_d8_d16", "net1pll", 1, 128),
+	FACTOR(CLK_TOP_NET2PLL_D2, "net2pll_d2", "net2pll", 1, 2),
+	FACTOR(CLK_TOP_NET2PLL_D4, "net2pll_d4", "net2pll", 1, 4),
+	FACTOR(CLK_TOP_NET2PLL_D4_D4, "net2pll_d4_d4", "net2pll", 1, 16),
+	FACTOR(CLK_TOP_NET2PLL_D4_D8, "net2pll_d4_d8", "net2pll", 1, 32),
+	FACTOR(CLK_TOP_NET2PLL_D6, "net2pll_d6", "net2pll", 1, 6),
+	FACTOR(CLK_TOP_NET2PLL_D8, "net2pll_d8", "net2pll", 1, 8),
+};
+
+static const char *const netsys_parents[] = { "top_xtal", "net2pll_d2", "mmpll_d2" };
+static const char *const netsys_500m_parents[] = { "top_xtal", "net1pll_d5", "net1pll_d5_d2" };
+static const char *const netsys_2x_parents[] = { "top_xtal", "net2pll", "mmpll" };
+static const char *const netsys_gsw_parents[] = { "top_xtal", "net1pll_d4", "net1pll_d5" };
+static const char *const eth_gmii_parents[] = { "top_xtal", "net1pll_d5_d4" };
+static const char *const netsys_mcu_parents[] = { "top_xtal",	"net2pll",    "mmpll",
+						  "net1pll_d4", "net1pll_d5", "mpll" };
+static const char *const eip197_parents[] = { "top_xtal", "netsyspll",	"net2pll",
+					      "mmpll",	  "net1pll_d4", "net1pll_d5" };
+static const char *const axi_infra_parents[] = { "top_xtal", "net1pll_d8_d2" };
+static const char *const uart_parents[] = { "top_xtal", "mpll_d8", "mpll_d8_d2" };
+static const char *const emmc_250m_parents[] = { "top_xtal", "net1pll_d5_d2", "mmpll_d4" };
+static const char *const emmc_400m_parents[] = { "top_xtal", "msdcpll",	 "mmpll_d2",
+						 "mpll_d2",  "mmpll_d4", "net1pll_d8_d2" };
+static const char *const spi_parents[] = { "top_xtal",	    "mpll_d2",	    "mmpll_d4",
+					   "net1pll_d8_d2", "net2pll_d6",   "net1pll_d5_d4",
+					   "mpll_d4",	    "net1pll_d8_d4" };
+static const char *const nfi1x_parents[] = { "top_xtal", "mmpll_d4", "net1pll_d8_d2", "net2pll_d6",
+					     "mpll_d4",	 "mmpll_d8", "net1pll_d8_d4", "mpll_d8" };
+static const char *const spinfi_parents[] = { "top_xtal_d2", "top_xtal", "net1pll_d5_d4",
+					      "mpll_d4",     "mmpll_d8", "net1pll_d8_d4",
+					      "mmpll_d6_d2", "mpll_d8" };
+static const char *const pwm_parents[] = { "top_xtal", "net1pll_d8_d2", "net1pll_d5_d4",
+					   "mpll_d4",  "mpll_d8_d2",	"top_rtc_32k" };
+static const char *const i2c_parents[] = { "top_xtal", "net1pll_d5_d4", "mpll_d4",
+					   "net1pll_d8_d4" };
+static const char *const pcie_mbist_250m_parents[] = { "top_xtal", "net1pll_d5_d2" };
+static const char *const pextp_tl_ck_parents[] = { "top_xtal", "net2pll_d6", "mmpll_d8",
+						   "mpll_d8_d2", "top_rtc_32k" };
+static const char *const usb_frmcnt_parents[] = { "top_xtal", "mmpll_d3_d5" };
+static const char *const aud_parents[] = { "top_xtal", "apll2" };
+static const char *const a1sys_parents[] = { "top_xtal", "apll2_d4" };
+static const char *const aud_l_parents[] = { "top_xtal", "apll2", "mpll_d8_d2" };
+static const char *const sspxtp_parents[] = { "top_xtal_d2", "mpll_d8_d2" };
+static const char *const usxgmii_sbus_0_parents[] = { "top_xtal", "net1pll_d8_d4" };
+static const char *const sgm_0_parents[] = { "top_xtal", "sgmpll" };
+static const char *const sysapb_parents[] = { "top_xtal", "mpll_d3_d2" };
+static const char *const eth_refck_50m_parents[] = { "top_xtal", "net2pll_d4_d4" };
+static const char *const eth_sys_200m_parents[] = { "top_xtal", "net2pll_d4" };
+static const char *const eth_xgmii_parents[] = { "top_xtal_d2", "net1pll_d8_d8", "net1pll_d8_d16" };
+static const char *const bus_tops_parents[] = { "top_xtal", "net1pll_d5", "net2pll_d2" };
+static const char *const npu_tops_parents[] = { "top_xtal", "net2pll" };
+static const char *const dramc_md32_parents[] = { "top_xtal", "mpll_d2", "wedmcupll" };
+static const char *const da_xtp_glb_p0_parents[] = { "top_xtal", "net2pll_d8" };
+static const char *const mcusys_backup_625m_parents[] = { "top_xtal", "net1pll_d4" };
+static const char *const macsec_parents[] = { "top_xtal", "sgmpll", "net1pll_d8" };
+static const char *const netsys_tops_400m_parents[] = { "top_xtal", "net2pll_d2" };
+static const char *const eth_mii_parents[] = { "top_xtal_d2", "net2pll_d4_d8" };
+
+static const struct mtk_mux top_muxes[] = {
+	/* CLK_CFG_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SEL, "netsys_sel", netsys_parents, 0x000, 0x004, 0x008,
+			     0, 2, 7, 0x1c0, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_500M_SEL, "netsys_500m_sel", netsys_500m_parents, 0x000,
+			     0x004, 0x008, 8, 2, 15, 0x1C0, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_2X_SEL, "netsys_2x_sel", netsys_2x_parents, 0x000,
+			     0x004, 0x008, 16, 2, 23, 0x1C0, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_GSW_SEL, "netsys_gsw_sel", netsys_gsw_parents, 0x000,
+			     0x004, 0x008, 24, 2, 31, 0x1C0, 3),
+	/* CLK_CFG_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_GMII_SEL, "eth_gmii_sel", eth_gmii_parents, 0x010, 0x014,
+			     0x018, 0, 1, 7, 0x1C0, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_MCU_SEL, "netsys_mcu_sel", netsys_mcu_parents, 0x010,
+			     0x014, 0x018, 8, 3, 15, 0x1C0, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PAO_2X_SEL, "netsys_pao_2x_sel", netsys_mcu_parents,
+			     0x010, 0x014, 0x018, 16, 3, 23, 0x1C0, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EIP197_SEL, "eip197_sel", eip197_parents, 0x010, 0x014, 0x018,
+			     24, 3, 31, 0x1c0, 7),
+	/* CLK_CFG_2 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_AXI_INFRA_SEL, "axi_infra_sel", axi_infra_parents, 0x020,
+				   0x024, 0x028, 0, 1, 7, 0x1C0, 8, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_UART_SEL, "uart_sel", uart_parents, 0x020, 0x024, 0x028, 8, 2,
+			     15, 0x1c0, 9),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_250M_SEL, "emmc_250m_sel", emmc_250m_parents, 0x020,
+			     0x024, 0x028, 16, 2, 23, 0x1C0, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_400M_SEL, "emmc_400m_sel", emmc_400m_parents, 0x020,
+			     0x024, 0x028, 24, 3, 31, 0x1C0, 11),
+	/* CLK_CFG_3 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPI_SEL, "spi_sel", spi_parents, 0x030, 0x034, 0x038, 0, 3, 7,
+			     0x1c0, 12),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPIM_MST_SEL, "spim_mst_sel", spi_parents, 0x030, 0x034, 0x038,
+			     8, 3, 15, 0x1c0, 13),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NFI1X_SEL, "nfi1x_sel", nfi1x_parents, 0x030, 0x034, 0x038, 16,
+			     3, 23, 0x1c0, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPINFI_SEL, "spinfi_sel", spinfi_parents, 0x030, 0x034, 0x038,
+			     24, 3, 31, 0x1c0, 15),
+	/* CLK_CFG_4 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PWM_SEL, "pwm_sel", pwm_parents, 0x040, 0x044, 0x048, 0, 3, 7,
+			     0x1c0, 16),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_I2C_SEL, "i2c_sel", i2c_parents, 0x040, 0x044, 0x048, 8, 2, 15,
+			     0x1c0, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PCIE_MBIST_250M_SEL, "pcie_mbist_250m_sel",
+			     pcie_mbist_250m_parents, 0x040, 0x044, 0x048, 16, 1, 23, 0x1C0, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_SEL, "pextp_tl_sel", pextp_tl_ck_parents, 0x040,
+			     0x044, 0x048, 24, 3, 31, 0x1C0, 19),
+	/* CLK_CFG_5 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P1_SEL, "pextp_tl_p1_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 0, 3, 7, 0x1C0, 20),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P2_SEL, "pextp_tl_p2_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 8, 3, 15, 0x1C0, 21),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P3_SEL, "pextp_tl_p3_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 16, 3, 23, 0x1C0, 22),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_SEL, "usb_sys_sel", eth_gmii_parents, 0x050, 0x054,
+			     0x058, 24, 1, 31, 0x1C0, 23),
+	/* CLK_CFG_6 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_P1_SEL, "usb_sys_p1_sel", eth_gmii_parents, 0x060,
+			     0x064, 0x068, 0, 1, 7, 0x1C0, 24),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_SEL, "usb_xhci_sel", eth_gmii_parents, 0x060, 0x064,
+			     0x068, 8, 1, 15, 0x1C0, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_P1_SEL, "usb_xhci_p1_sel", eth_gmii_parents, 0x060,
+			     0x064, 0x068, 16, 1, 23, 0x1C0, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_SEL, "usb_frmcnt_sel", usb_frmcnt_parents, 0x060,
+			     0x064, 0x068, 24, 1, 31, 0x1C0, 27),
+	/* CLK_CFG_7 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_P1_SEL, "usb_frmcnt_p1_sel", usb_frmcnt_parents,
+			     0x070, 0x074, 0x078, 0, 1, 7, 0x1C0, 28),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_SEL, "aud_sel", aud_parents, 0x070, 0x074, 0x078, 8, 1, 15,
+			     0x1c0, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A1SYS_SEL, "a1sys_sel", a1sys_parents, 0x070, 0x074, 0x078, 16,
+			     1, 23, 0x1c0, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_L_SEL, "aud_l_sel", aud_l_parents, 0x070, 0x074, 0x078, 24,
+			     2, 31, 0x1c4, 0),
+	/* CLK_CFG_8 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A_TUNER_SEL, "a_tuner_sel", a1sys_parents, 0x080, 0x084, 0x088,
+			     0, 1, 7, 0x1c4, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SSPXTP_SEL, "sspxtp_sel", sspxtp_parents, 0x080, 0x084, 0x088,
+			     8, 1, 15, 0x1c4, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_PHY_SEL, "usb_phy_sel", sspxtp_parents, 0x080, 0x084,
+			     0x088, 16, 1, 23, 0x1c4, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_0_SEL, "usxgmii_sbus_0_sel",
+			     usxgmii_sbus_0_parents, 0x080, 0x084, 0x088, 24, 1, 31, 0x1C4, 4),
+	/* CLK_CFG_9 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_1_SEL, "usxgmii_sbus_1_sel",
+			     usxgmii_sbus_0_parents, 0x090, 0x094, 0x098, 0, 1, 7, 0x1C4, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_0_SEL, "sgm_0_sel", sgm_0_parents, 0x090, 0x094, 0x098, 8,
+			     1, 15, 0x1c4, 6),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_0_SEL, "sgm_sbus_0_sel", usxgmii_sbus_0_parents,
+				   0x090, 0x094, 0x098, 16, 1, 23, 0x1C4, 7, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_1_SEL, "sgm_1_sel", sgm_0_parents, 0x090, 0x094, 0x098, 24,
+			     1, 31, 0x1c4, 8),
+	/* CLK_CFG_10 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_1_SEL, "sgm_sbus_1_sel", usxgmii_sbus_0_parents,
+				   0x0a0, 0x0a4, 0x0a8, 0, 1, 7, 0x1C4, 9, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_0_XTAL_SEL, "xfi_phy_0_xtal_sel", sspxtp_parents,
+			     0x0a0, 0x0a4, 0x0a8, 8, 1, 15, 0x1C4, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_1_XTAL_SEL, "xfi_phy_1_xtal_sel", sspxtp_parents,
+			     0x0a0, 0x0a4, 0x0a8, 16, 1, 23, 0x1C4, 11),
+	/* CLK_CFG_11 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAXI_SEL, "sysaxi_sel", axi_infra_parents, 0x0a0,
+				   0x0a4, 0x0a8, 24, 1, 31, 0x1C4, 12, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAPB_SEL, "sysapb_sel", sysapb_parents, 0x0b0, 0x0b4,
+				   0x0b8, 0, 1, 7, 0x1c4, 13, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_REFCK_50M_SEL, "eth_refck_50m_sel", eth_refck_50m_parents,
+			     0x0b0, 0x0b4, 0x0b8, 8, 1, 15, 0x1C4, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_200M_SEL, "eth_sys_200m_sel", eth_sys_200m_parents,
+			     0x0b0, 0x0b4, 0x0b8, 16, 1, 23, 0x1C4, 15),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_SEL, "eth_sys_sel", pcie_mbist_250m_parents, 0x0b0,
+			     0x0b4, 0x0b8, 24, 1, 31, 0x1C4, 16),
+	/* CLK_CFG_12 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_XGMII_SEL, "eth_xgmii_sel", eth_xgmii_parents, 0x0c0,
+			     0x0c4, 0x0c8, 0, 2, 7, 0x1C4, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_BUS_TOPS_SEL, "bus_tops_sel", bus_tops_parents, 0x0c0, 0x0c4,
+			     0x0c8, 8, 2, 15, 0x1C4, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_TOPS_SEL, "npu_tops_sel", npu_tops_parents, 0x0c0, 0x0c4,
+			     0x0c8, 16, 1, 23, 0x1C4, 19),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_SEL, "dramc_sel", sspxtp_parents, 0x0c0, 0x0c4,
+				   0x0c8, 24, 1, 31, 0x1C4, 20, CLK_IS_CRITICAL),
+	/* CLK_CFG_13 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_MD32_SEL, "dramc_md32_sel", dramc_md32_parents,
+				   0x0d0, 0x0d4, 0x0d8, 0, 2, 7, 0x1C4, 21, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_INFRA_F26M_SEL, "csw_infra_f26m_sel", sspxtp_parents,
+				   0x0d0, 0x0d4, 0x0d8, 8, 1, 15, 0x1C4, 22, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P0_SEL, "pextp_p0_sel", sspxtp_parents, 0x0d0, 0x0d4,
+			     0x0d8, 16, 1, 23, 0x1C4, 23),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P1_SEL, "pextp_p1_sel", sspxtp_parents, 0x0d0, 0x0d4,
+			     0x0d8, 24, 1, 31, 0x1C4, 24),
+	/* CLK_CFG_14 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P2_SEL, "pextp_p2_sel", sspxtp_parents, 0x0e0, 0x0e4,
+			     0x0e8, 0, 1, 7, 0x1C4, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P3_SEL, "pextp_p3_sel", sspxtp_parents, 0x0e0, 0x0e4,
+			     0x0e8, 8, 1, 15, 0x1C4, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P0_SEL, "da_xtp_glb_p0_sel", da_xtp_glb_p0_parents,
+			     0x0e0, 0x0e4, 0x0e8, 16, 1, 23, 0x1C4, 27),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P1_SEL, "da_xtp_glb_p1_sel", da_xtp_glb_p0_parents,
+			     0x0e0, 0x0e4, 0x0e8, 24, 1, 31, 0x1C4, 28),
+	/* CLK_CFG_15 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P2_SEL, "da_xtp_glb_p2_sel", da_xtp_glb_p0_parents,
+			     0x0f0, 0x0f4, 0x0f8, 0, 1, 7, 0x1C4, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P3_SEL, "da_xtp_glb_p3_sel", da_xtp_glb_p0_parents,
+			     0x0f0, 0x0f4, 0x0f8, 8, 1, 15, 0x1C4, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_CKM_SEL, "ckm_sel", sspxtp_parents, 0x0F0, 0x0f4, 0x0f8, 16, 1,
+			     23, 0x1c8, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_SEL, "da_sel", sspxtp_parents, 0x0f0, 0x0f4, 0x0f8, 24, 1,
+			     31, 0x1C8, 1),
+	/* CLK_CFG_16 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_SEL, "pextp_sel", sspxtp_parents, 0x0100, 0x104, 0x108,
+			     0, 1, 7, 0x1c8, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_TOPS_P2_26M_SEL, "tops_p2_26m_sel", sspxtp_parents, 0x0100,
+			     0x104, 0x108, 8, 1, 15, 0x1C8, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MCUSYS_BACKUP_625M_SEL, "mcusys_backup_625m_sel",
+			     mcusys_backup_625m_parents, 0x0100, 0x104, 0x108, 16, 1, 23, 0x1C8, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SYNC_250M_SEL, "netsys_sync_250m_sel",
+			     pcie_mbist_250m_parents, 0x0100, 0x104, 0x108, 24, 1, 31, 0x1c8, 5),
+	/* CLK_CFG_17 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MACSEC_SEL, "macsec_sel", macsec_parents, 0x0110, 0x114, 0x118,
+			     0, 2, 7, 0x1c8, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_TOPS_400M_SEL, "netsys_tops_400m_sel",
+			     netsys_tops_400m_parents, 0x0110, 0x114, 0x118, 8, 1, 15, 0x1c8, 7),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PPEFB_250M_SEL, "netsys_ppefb_250m_sel",
+			     pcie_mbist_250m_parents, 0x0110, 0x114, 0x118, 16, 1, 23, 0x1c8, 8),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_WARP_SEL, "netsys_warp_sel", netsys_parents, 0x0110,
+			     0x114, 0x118, 24, 2, 31, 0x1C8, 9),
+	/* CLK_CFG_18 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_MII_SEL, "eth_mii_sel", eth_mii_parents, 0x0120, 0x124,
+			     0x128, 0, 1, 7, 0x1c8, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_SEL, "ck_npu_sel", netsys_2x_parents, 0x0120, 0x124, 0x128,
+			     8, 2, 15, 0x1c8, 11),
+};
+
+static const struct mtk_composite top_aud_divs[] = {
+	DIV_GATE(CLK_TOP_AUD_I2S_M, "aud_i2s_m", "aud_sel", 0x0420, 0, 0x0420, 8, 8),
+};
+
+static const struct mtk_clk_desc topck_desc = {
+	.fixed_clks = top_fixed_clks,
+	.num_fixed_clks = ARRAY_SIZE(top_fixed_clks),
+	.factor_clks = top_divs,
+	.num_factor_clks = ARRAY_SIZE(top_divs),
+	.mux_clks = top_muxes,
+	.num_mux_clks = ARRAY_SIZE(top_muxes),
+	.composite_clks = top_aud_divs,
+	.num_composite_clks = ARRAY_SIZE(top_aud_divs),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const char *const mcu_bus_div_parents[] = { "top_xtal", "ccipll2_b", "net1pll_d4" };
+
+static const char *const mcu_arm_div_parents[] = { "top_xtal", "arm_b", "net1pll_d4" };
+
+static struct mtk_composite mcu_muxes[] = {
+	/* bus_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_BUS_DIV_SEL, "mcu_bus_div_sel", mcu_bus_div_parents, 0x7C0, 9, 2, -1,
+		       CLK_IS_CRITICAL),
+	/* mp2_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_ARM_DIV_SEL, "mcu_arm_div_sel", mcu_arm_div_parents, 0x7A8, 9, 2, -1,
+		       CLK_IS_CRITICAL),
+};
+
+static const struct mtk_clk_desc mcusys_desc = {
+	.composite_clks = mcu_muxes,
+	.num_composite_clks = ARRAY_SIZE(mcu_muxes),
+};
+
+static const struct of_device_id of_match_clk_mt7988_topckgen[] = {
+	{ .compatible = "mediatek,mt7988-topckgen", .data = &topck_desc },
+	{ .compatible = "mediatek,mt7988-mcusys", .data = &mcusys_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_topckgen);
+
+static struct platform_driver clk_mt7988_topckgen_drv = {
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+	.driver = {
+		.name = "clk-mt7988-topckgen",
+		.of_match_table = of_match_clk_mt7988_topckgen,
+	},
+};
+module_platform_driver(clk_mt7988_topckgen_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-xfipll.c b/drivers/clk/mediatek/clk-mt7988-xfipll.c
new file mode 100644
index 0000000000000..9b9ca5471158b
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-xfipll.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+/* Register to control USXGMII XFI PLL analog */
+#define XFI_PLL_ANA_GLB8		0x108
+#define RG_XFI_PLL_ANA_SWWA		0x02283248
+
+static const struct mtk_gate_regs xfipll_cg_regs = {
+	.set_ofs = 0x8,
+	.clr_ofs = 0x8,
+	.sta_ofs = 0x8,
+};
+
+#define GATE_XFIPLL(_id, _name, _parent, _shift)		\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &xfipll_cg_regs,			\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_fixed_factor xfipll_divs[] = {
+	FACTOR(CLK_XFIPLL_PLL, "xfipll_pll", "top_xtal", 125, 32),
+};
+
+static const struct mtk_gate xfipll_clks[] = {
+	GATE_XFIPLL(CLK_XFIPLL_PLL_EN, "xfipll_pll_en", "xfipll_pll", 31),
+};
+
+static const struct mtk_clk_desc xfipll_desc = {
+	.clks = xfipll_clks,
+	.num_clks = ARRAY_SIZE(xfipll_clks),
+	.factor_clks = xfipll_divs,
+	.num_factor_clks = ARRAY_SIZE(xfipll_divs),
+};
+
+static int clk_mt7988_xfipll_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	void __iomem *base = of_iomap(node, 0);
+
+	if (!base)
+		return -ENOMEM;
+
+	/* Apply software workaround for USXGMII PLL TCL issue */
+	writel(RG_XFI_PLL_ANA_SWWA, base + XFI_PLL_ANA_GLB8);
+	iounmap(base);
+
+	return mtk_clk_simple_probe(pdev);
+};
+
+static const struct of_device_id of_match_clk_mt7988_xfipll[] = {
+	{ .compatible = "mediatek,mt7988-xfi-pll", .data = &xfipll_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_xfipll);
+
+static struct platform_driver clk_mt7988_xfipll_drv = {
+	.driver = {
+		.name = "clk-mt7988-xfipll",
+		.of_match_table = of_match_clk_mt7988_xfipll,
+	},
+	.probe = clk_mt7988_xfipll_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_xfipll_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 XFI PLL clock driver");
+MODULE_LICENSE("GPL");
-- 
2.43.0


From rdunlap at infradead.org  Fri Dec 15 16:41:56 2023
From: rdunlap at infradead.org (Randy Dunlap)
Date: Fri, 15 Dec 2023 16:41:56 -0800
Subject: [PATCH] mailbox: zynqmp-ipi: fix an Excess struct member kernel-doc warning
Message-ID: <20231216004156.26967-1-rdunlap@infradead.org>

kernel test robot reports 2 Excess struct member warnings:

zynqmp-ipi-mailbox.c:92: warning: Excess struct member 'irq' description in 'zynqmp_ipi_mbox'
zynqmp-ipi-mailbox.c:112: warning: Excess struct member 'ipi_mboxes' description in 'zynqmp_ipi_pdata'

The second one is a false positive that is caused by the
__counted_by() attribute. Kees has posted a patch for that, so just
fix the first one.

Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312150705.glrQ4ypv-lkp at intel.com/
Cc: Jassi Brar <jassisinghbrar at gmail.com>
Cc: Michal Simek <michal.simek at amd.com>
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/mailbox/zynqmp-ipi-mailbox.c |    1 -
 1 file changed, 1 deletion(-)

diff -- a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
--- a/drivers/mailbox/zynqmp-ipi-mailbox.c
+++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
@@ -81,7 +81,6 @@ struct zynqmp_ipi_mchan {
  * @remote_id:            remote IPI agent ID
  * @mbox:                 mailbox Controller
  * @mchans:               array for channels, tx channel and rx channel.
- * @irq:                  IPI agent interrupt ID
  */
 struct zynqmp_ipi_mbox {
 	struct zynqmp_ipi_pdata *pdata;


From kw at linux.com  Fri Dec 15 16:44:34 2023
From: kw at linux.com (Krzysztof =?utf-8?Q?Wilczy=C5=84ski?=)
Date: Sat, 16 Dec 2023 09:44:34 +0900
Subject: [PATCH 0/3] PCI: Convert to platform remove callback returning
 void (part II)
In-Reply-To: <cover.1701682617.git.u.kleine-koenig@pengutronix.de>
References: <cover.1701682617.git.u.kleine-koenig@pengutronix.de>
Message-ID: <20231216004434.GG1570493@rocinante>

Hello,

> back in March I sent a series[1] with the intention to convert all of
> drivers/pci to .remove_new(). I missed these three drivers because my
> coccinelle script didn't handle __exit_p. (The drivers don't use
> __exit_p in the mean time since the follwing commits:
> 
> 	200bddbb3f52 ("PCI: keystone: Don't discard .remove() callback")
> 	3064ef2e88c1 ("PCI: kirin: Don't discard .remove() callback")
> 	83a939f0fdc2 ("PCI: exynos: Don't discard .remove() callback")
> 
> .)
> 
> There are no interdependencies between these patches.
> 
> See commit 5c5a7680e67b ("platform: Provide a remove callback that
> returns no value") for an extended explanation and the eventual goal.

Applied to controller/remove-void-return, thank you!

[01/03] PCI: exynos: Convert to platform remove callback returning void
        https://git.kernel.org/pci/pci/c/4fbd8b788258
[02/03] PCI: keystone: Convert to platform remove callback returning void
        https://git.kernel.org/pci/pci/c/93d61d3aa996
[03/03] PCI: kirin: Convert to platform remove callback returning void
        https://git.kernel.org/pci/pci/c/a5eee68931fc

	Krzysztof


From daniel at makrotopia.org  Fri Dec 15 17:16:51 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 16 Dec 2023 01:16:51 +0000
Subject: [RFC PATCH net-next v3 1/8] dt-bindings: phy:
 mediatek,xfi-pextp: add new bindings
In-Reply-To: <c9605d38-e4b8-477d-84d8-de7b4dedd1f1@lunn.ch>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <b875f693f6d4367a610a12ef324584f3bf3a1c1c.1702352117.git.daniel@makrotopia.org>
 <20231212-renderer-strobe-2b46652cd6e7@spud>
 <ZXiNhSYDbowUiNvy@makrotopia.org>
 <c9605d38-e4b8-477d-84d8-de7b4dedd1f1@lunn.ch>
Message-ID: <ZXz6g0Su-kNPA3rX@makrotopia.org>

On Wed, Dec 13, 2023 at 02:20:45PM +0100, Andrew Lunn wrote:
> > Because it is only present in one of the two SerDes channels.
> > Channel 0 needs the work-around, Channel 1 doesn't.
> 
> Does the channel know its own number?

As far as I know we can't infer the channel number by any of the
registers default values.

We could infer it from the base address, and that would kinda defy the
purpose of having Device Tree to begin with in my feeling at least,
but it would be possible, of course.


From shawnguo at kernel.org  Fri Dec 15 17:36:36 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 09:36:36 +0800
Subject: [PATCH v8 3/3] arm64: dts: imx8mn-bsh-smm-s2/pro: add display
 setup
In-Reply-To: <20231214082457.18737-4-dario.binacchi@amarulasolutions.com>
References: <20231214082457.18737-1-dario.binacchi@amarulasolutions.com>
 <20231214082457.18737-4-dario.binacchi@amarulasolutions.com>
Message-ID: <20231216013636.GI270430@dragon>

On Thu, Dec 14, 2023 at 09:24:06AM +0100, Dario Binacchi wrote:
> From: Michael Trimarchi <michael at amarulasolutions.com>
> 
> Add the display and nodes required for its operation.
> 
> Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
> Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>

Applied, thanks!


From shawnguo at kernel.org  Fri Dec 15 17:38:02 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 09:38:02 +0800
Subject: [PATCH v2] arm64: dts: imx8qxp-mek: Move port under USB connector
In-Reply-To: <20231214091653.1187117-1-festevam@gmail.com>
References: <20231214091653.1187117-1-festevam@gmail.com>
Message-ID: <20231216013802.GJ270430@dragon>

On Thu, Dec 14, 2023 at 06:16:53AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per nxp,ptn5110.yaml, 'port' should be placed under 'connector'.
> 
> Do as requested to fix the following dt-schema warning:
> 
> imx8qxp-mek.dtb: tcpc at 50: connector:ports: 'port at 0' is a required property
>         from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
> imx8qxp-mek.dtb: tcpc at 50: connector: Unevaluated properties are not allowed ('ports' was unexpected)
>         from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Fri Dec 15 17:43:27 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 09:43:27 +0800
Subject: [PATCH 1/1] arm64: dts: imx8qxp: Add VPU subsystem file
In-Reply-To: <20231214132000.1927638-1-alexander.stein@ew.tq-group.com>
References: <20231214132000.1927638-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231216014327.GK270430@dragon>

On Thu, Dec 14, 2023 at 02:20:00PM +0100, Alexander Stein wrote:
> imx8qxp re-uses imx8qm VPU subsystem file, but it has different base
> addresses. Also imx8qxp has only two VPU cores, delete vpu_vore2 and
> mu2_m0 accordingly.
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

Applied, thanks!


From shawnguo at kernel.org  Fri Dec 15 17:44:52 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 09:44:52 +0800
Subject: [PATCH 1/1] arm64: dts: freescale: imx8qxp: Disable dsp reserved
 memory by default
In-Reply-To: <20231214134259.1933541-1-alexander.stein@ew.tq-group.com>
References: <20231214134259.1933541-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231216014452.GL270430@dragon>

On Thu, Dec 14, 2023 at 02:42:59PM +0100, Alexander Stein wrote:
> Even if the 'dsp' node is disabled the memory intended to be used by the
> DSP is reserved. This limits the memory range suitable for CMA allocation.
> Thus disable the dsp_reserved node. DSP users need to enable it in parallel
> to the 'dsp' node.
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

Applied, thanks!


From shawnguo at kernel.org  Fri Dec 15 17:47:14 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 09:47:14 +0800
Subject: [PATCH] ARM: dts: imx25: Remove unneeded keypad properties
In-Reply-To: <20231215121433.176121-1-festevam@gmail.com>
References: <20231215121433.176121-1-festevam@gmail.com>
Message-ID: <20231216014714.GM270430@dragon>

On Fri, Dec 15, 2023 at 09:14:33AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Per imx-keypad.yaml, '#address-cells', '#size-cells', 'clock-names'
> are not valid properties.
> 
> Remove them to fix the following dt-schema warning:
> 
> imx25-pdk.dtb: kpp at 43fa8000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'clock-names' were unexpected)
> 	from schema $id: http://devicetree.org/schemas/input/imx-keypad.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Fri Dec 15 17:47:35 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 09:47:35 +0800
Subject: [PATCH] ARM: dts: imx27-phytec-phycore-som: Use 'rtc' as node
 name
In-Reply-To: <20231215121845.177096-1-festevam@gmail.com>
References: <20231215121845.177096-1-festevam@gmail.com>
Message-ID: <20231216014735.GN270430@dragon>

On Fri, Dec 15, 2023 at 09:18:45AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam at denx.de>
> 
> Node names should be generic.
> 
> Use 'rtc' for the rtc node to fix the following dt-schema warning:
> 
> imx27-phytec-phycore-rdk.dtb: pcf8563 at 51: $nodename:0: 'pcf8563 at 51' does not match '^rtc(@.*|-([0-9]|[1-9][0-9]+))?$'
> 	from schema $id: http://devicetree.org/schemas/rtc/nxp,pcf8563.yaml#
> 
> Signed-off-by: Fabio Estevam <festevam at denx.de>

Applied, thanks!


From shawnguo at kernel.org  Fri Dec 15 17:58:02 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 09:58:02 +0800
Subject: [RESEND PATCH] arm64: dts: freescale: fix the schema check
 errors for fsl,tmu-calibration
In-Reply-To: <20231215230743.86194-1-david@ixit.cz>
References: <20231215230743.86194-1-david@ixit.cz>
Message-ID: <20231216015802.GO270430@dragon>

On Sat, Dec 16, 2023 at 12:07:35AM +0100, David Heidelberg wrote:
> fsl,tmu-calibration contains cell pairs (u32-matrix). Mark them as such.
> 
> Use matching property syntax and allow correct validation.
> 
> No functional changes.
> 
> Signed-off-by: David Heidelberg <david at ixit.cz>

Applied, thanks!


From cfsworks at gmail.com  Fri Dec 15 18:10:19 2023
From: cfsworks at gmail.com (Sam Edwards)
Date: Fri, 15 Dec 2023 19:10:19 -0700
Subject: [PATCH] arm64: dts: rockchip: rk3588: Fix USB PD clocks
Message-ID: <20231216021019.1543811-1-CFSworks@gmail.com>

The QoS blocks saved/restored when toggling the PD_USB power domain are
clocked by ACLK_USB. Attempting to access these memory regions without
that clock running will result in an indefinite CPU stall.

The PD_USB node wasn't specifying this clock dependency, resulting in
hangs when trying to toggle the power domain (either on or off), unless
we get "lucky" and have ACLK_USB running for another reason at the time.
This "luck" can result from the bootloader leaving USB powered/clocked,
and if no built-in driver wants USB, Linux will disable the unused
PD+CLK on boot when {pd,clk}_ignore_unused aren't given. This can also
be unlucky because the two cleanup tasks run in parallel and race: if
the CLK is disabled first, the PD deactivation stalls the boot. In any
case, the PD cannot then be reenabled (if e.g. the driver loads later)
once the clock has been stopped.

Fix this by specifying a dependency on ACLK_USB, instead of only
ACLK_USB_ROOT. The child-parent relationship means the former implies
the latter anyway. By the same token, remove the redundant HCLK_USB_ROOT
reference, since that's also implied by its HCLK_HOST* grandchildren.

Fixes: c9211fa2602b8 ("arm64: dts: rockchip: Add base DT for rk3588 SoC")
Signed-off-by: Sam Edwards <CFSworks at gmail.com>
---

Hi list,

Feel free to tell me to knock the HCLK_USB_ROOT change out of there, since it's
not strictly necessary for this fix. It was a "while I'm at it, let's remove
this redundant reference" thing. :)

I also do not know quite enough about debugfs to know how to manually request
clocks and PDs, but if such a mechanism exists, it would be a good way to
confirm the correctness of this fix: ensure ACLK_USB is stopped, then try to
toggle PD_USB a few times.

Cheers,
Sam

---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index fd1b5d02ba16..32d7e49f03d3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -1341,8 +1341,7 @@ power-domain at RK3588_PD_RGA31 {
 			power-domain at RK3588_PD_USB {
 				reg = <RK3588_PD_USB>;
 				clocks = <&cru PCLK_PHP_ROOT>,
-					 <&cru ACLK_USB_ROOT>,
-					 <&cru HCLK_USB_ROOT>,
+					 <&cru ACLK_USB>,
 					 <&cru HCLK_HOST0>,
 					 <&cru HCLK_HOST_ARB0>,
 					 <&cru HCLK_HOST1>,
-- 
2.41.0



From leo.yan at linaro.org  Fri Dec 15 19:29:52 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 16 Dec 2023 11:29:52 +0800
Subject: [PATCH V3 0/7] Clean up perf mem
In-Reply-To: <20231213195154.1085945-1-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
Message-ID: <20231216032952.GI86143@leoy-huanghe.lan>

On Wed, Dec 13, 2023 at 11:51:47AM -0800, kan.liang at linux.intel.com wrote:

[...]

> Introduce generic functions perf_mem_events__ptr(),
> perf_mem_events__name() ,and is_mem_loads_aux_event() to replace the
> ARCH specific ones.
> Simplify the perf_mem_event__supported().
> 
> Only keeps the ARCH-specific perf_mem_events array in the corresponding
> mem-events.c for each ARCH.
> 
> There is no functional change.
> 
> The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
> etc. But I can only test it on two Intel platforms.
> Please give it try, if you have machines with other ARCHs.

This patch series is fine for me:

Reviewed-by: Leo Yan <leo.yan at linaro.org>

I only compiled successfully it on my Arm64 machine but don't test
it due to I have no chance to access a machine with Arm SPE.

James, could you test it?  Thanks a lot!

> Here are the test results:
> Intel hybrid machine:
> 
> $perf mem record -e list
> ldlat-loads  : available
> ldlat-stores : available
> 
> $perf mem record -e ldlat-loads -v --ldlat 50
> calling: record -e cpu_atom/mem-loads,ldlat=50/P -e cpu_core/mem-loads,ldlat=50/P
> 
> $perf mem record -v
> calling: record -e cpu_atom/mem-loads,ldlat=30/P -e cpu_atom/mem-stores/P -e cpu_core/mem-loads,ldlat=30/P -e cpu_core/mem-stores/P
> 
> $perf mem record -t store -v
> calling: record -e cpu_atom/mem-stores/P -e cpu_core/mem-stores/P
> 
> 
> Intel SPR:
> $perf mem record -e list
> ldlat-loads  : available
> ldlat-stores : available
> 
> $perf mem record -e ldlat-loads -v --ldlat 50
> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=50/}:P
> 
> $perf mem record -v
> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=30/}:P -e cpu/mem-stores/P
> 
> $perf mem record -t store -v
> calling: record -e cpu/mem-stores/P


From cnsztl at gmail.com  Fri Dec 15 20:07:23 2023
From: cnsztl at gmail.com (Tianling Shen)
Date: Sat, 16 Dec 2023 12:07:23 +0800
Subject: [PATCH] arm64: dts: rockchip: configure pad driver strength for orangepi r1 plus lts
Message-ID: <20231216040723.17864-1-cnsztl@gmail.com>

The default strength is not enough to provide stable connection
under 3.3v LDO voltage.

Fixes: 387b3bbac5ea ("arm64: dts: rockchip: Add Xunlong OrangePi R1 Plus LTS")

Cc: stable at vger.kernel.org # 6.6+
Signed-off-by: Tianling Shen <cnsztl at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts
index 5d7d567283e5..4237f2ee8fee 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts
@@ -26,9 +26,11 @@ yt8531c: ethernet-phy at 0 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			reg = <0>;
 
+			motorcomm,auto-sleep-disabled;
 			motorcomm,clk-out-frequency-hz = <125000000>;
 			motorcomm,keep-pll-enabled;
-			motorcomm,auto-sleep-disabled;
+			motorcomm,rx-clk-drv-microamp = <5020>;
+			motorcomm,rx-data-drv-microamp = <5020>;
 
 			pinctrl-0 = <&eth_phy_reset_pin>;
 			pinctrl-names = "default";
-- 
2.43.0



From pr-tracker-bot at kernel.org  Fri Dec 15 20:07:21 2023
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Sat, 16 Dec 2023 04:07:21 +0000
Subject: [GIT PULL] arm64 fixes for 6.7-rc6
In-Reply-To: <ZXzliF7K4P32ZSYk@arm.com>
References: <ZXzliF7K4P32ZSYk@arm.com>
Message-ID: <170269964170.27029.1461953363063526027.pr-tracker-bot@kernel.org>

The pull request you sent on Fri, 15 Dec 2023 23:47:20 +0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c8e97fc6b4c057a350a9e9a1ad625e10cc9c39ee

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From renjunw0 at foxmail.com  Fri Dec 15 20:18:05 2023
From: renjunw0 at foxmail.com (renjun wang)
Date: Sat, 16 Dec 2023 12:18:05 +0800
Subject: [PATCH] media: verisilicon: Fix some typos
Message-ID: <tencent_4AE0AD70494AB08166266B6493F4C507CE08@qq.com>

Function hantro_g1_h264_dec_prepare_table() does not exist,
should be replaced with hantro_h264_dec_init().

The register name av1_ulticore_tile_col confused sometimes,
although not be used corrently. The correct name should be
av1_multicore_tile_col.

Signed-off-by: renjun wang <renjunw0 at foxmail.com>
---
 drivers/media/platform/verisilicon/hantro_g1_h264_dec.c        | 2 +-
 drivers/media/platform/verisilicon/rockchip_vpu2_hw_h264_dec.c | 2 +-
 drivers/media/platform/verisilicon/rockchip_vpu981_regs.h      | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/verisilicon/hantro_g1_h264_dec.c b/drivers/media/platform/verisilicon/hantro_g1_h264_dec.c
index 9de7f05eff2a..ad5c1a6634f5 100644
--- a/drivers/media/platform/verisilicon/hantro_g1_h264_dec.c
+++ b/drivers/media/platform/verisilicon/hantro_g1_h264_dec.c
@@ -243,7 +243,7 @@ static void set_buffers(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
 		vdpu_write_relaxed(vpu, dst_dma + offset, G1_REG_ADDR_DIR_MV);
 	}
 
-	/* Auxiliary buffer prepared in hantro_g1_h264_dec_prepare_table(). */
+	/* Auxiliary buffer prepared in hantro_h264_dec_init(). */
 	vdpu_write_relaxed(vpu, ctx->h264_dec.priv.dma, G1_REG_ADDR_QTABLE);
 }
 
diff --git a/drivers/media/platform/verisilicon/rockchip_vpu2_hw_h264_dec.c b/drivers/media/platform/verisilicon/rockchip_vpu2_hw_h264_dec.c
index 46c1a83bcc4e..6da87f5184bc 100644
--- a/drivers/media/platform/verisilicon/rockchip_vpu2_hw_h264_dec.c
+++ b/drivers/media/platform/verisilicon/rockchip_vpu2_hw_h264_dec.c
@@ -460,7 +460,7 @@ static void set_buffers(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
 		vdpu_write_relaxed(vpu, dst_dma + offset, VDPU_REG_DIR_MV_BASE);
 	}
 
-	/* Auxiliary buffer prepared in hantro_g1_h264_dec_prepare_table(). */
+	/* Auxiliary buffer prepared in hantro_h264_dec_init(). */
 	vdpu_write_relaxed(vpu, ctx->h264_dec.priv.dma, VDPU_REG_QTABLE_BASE);
 }
 
diff --git a/drivers/media/platform/verisilicon/rockchip_vpu981_regs.h b/drivers/media/platform/verisilicon/rockchip_vpu981_regs.h
index 182e6c830ff6..850ff0f84424 100644
--- a/drivers/media/platform/verisilicon/rockchip_vpu981_regs.h
+++ b/drivers/media/platform/verisilicon/rockchip_vpu981_regs.h
@@ -118,7 +118,7 @@
 #define av1_mcomp_filt_type		AV1_DEC_REG(11, 8, 0x7)
 #define av1_multicore_expect_context_update	AV1_DEC_REG(11, 11, 0x1)
 #define av1_multicore_sbx_offset	AV1_DEC_REG(11, 12, 0x7f)
-#define av1_ulticore_tile_col		AV1_DEC_REG(11, 19, 0x7f)
+#define av1_multicore_tile_col		AV1_DEC_REG(11, 19, 0x7f)
 #define av1_transform_mode		AV1_DEC_REG(11, 27, 0x7)
 #define av1_dec_tile_size_mag		AV1_DEC_REG(11, 30, 0x3)
 
-- 
2.39.2



From rdunlap at infradead.org  Fri Dec 15 20:41:46 2023
From: rdunlap at infradead.org (Randy Dunlap)
Date: Fri, 15 Dec 2023 20:41:46 -0800
Subject: [PATCH] mtd: rawnand: fix Excess struct member description kernel-doc warnings
Message-ID: <20231216044146.18645-1-rdunlap@infradead.org>

Delete 2 lines to prevent warnings from scripts/kernel-doc:

s3c2410.c:117: warning: Excess struct member 'mtd' description in 's3c2410_nand_mtd'
s3c2410.c:168: warning: Excess struct member 'freq_transition' description in 's3c2410_nand_info'


Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312150611.EZBAQYqf-lkp at intel.com/
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Miquel Raynal <miquel.raynal at bootlin.com>
Cc: Richard Weinberger <richard at nod.at>
Cc: Vignesh Raghavendra <vigneshr at ti.com>
Cc: linux-mtd at lists.infradead.org
Cc: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Cc: Alim Akhtar <alim.akhtar at samsung.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
---
 drivers/mtd/nand/raw/s3c2410.c |    2 --
 1 file changed, 2 deletions(-)

diff -- a/drivers/mtd/nand/raw/s3c2410.c b/drivers/mtd/nand/raw/s3c2410.c
--- a/drivers/mtd/nand/raw/s3c2410.c
+++ b/drivers/mtd/nand/raw/s3c2410.c
@@ -105,7 +105,6 @@ struct s3c2410_nand_info;
 
 /**
  * struct s3c2410_nand_mtd - driver MTD structure
- * @mtd: The MTD instance to pass to the MTD layer.
  * @chip: The NAND chip information.
  * @set: The platform information supplied for this set of NAND chips.
  * @info: Link back to the hardware information.
@@ -145,7 +144,6 @@ enum s3c_nand_clk_state {
  * @clk_rate: The clock rate from @clk.
  * @clk_state: The current clock state.
  * @cpu_type: The exact type of this controller.
- * @freq_transition: CPUFreq notifier block
  */
 struct s3c2410_nand_info {
 	/* mtd info */


From peng.fan at nxp.com  Fri Dec 15 20:44:38 2023
From: peng.fan at nxp.com (Peng Fan)
Date: Sat, 16 Dec 2023 04:44:38 +0000
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <20231215201148.GA304363-robh@kernel.org>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
 <20231215201148.GA304363-robh@kernel.org>
Message-ID: <DU0PR04MB94177607820C463B904173DF8892A@DU0PR04MB9417.eurprd04.prod.outlook.com>

Hi Rob,

> Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
> protocol
> 
> On Fri, Dec 15, 2023 at 07:56:32PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan at nxp.com>
> >
> > Add SCMI v3.2 pinctrl protocol bindings and example.
> >
> > Signed-off-by: Peng Fan <peng.fan at nxp.com>
> > ---
> >  .../devicetree/bindings/firmware/arm,scmi.yaml     | 99
> ++++++++++++++++++++++
> >  1 file changed, 99 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > index 4591523b51a0..bfd2b6a89979 100644
> > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > @@ -247,6 +247,85 @@ properties:
> >        reg:
> >          const: 0x18
> >
> > +  protocol at 19:
> > +    type: object
> > +    allOf:
> > +      - $ref: '#/$defs/protocol-node'
> > +      - $ref: /schemas/pinctrl/pinctrl.yaml
> > +      - if:
> > +          properties:
> > +            compatible:
> > +              const: fsl,imx95-scmi-pinctrl
> > +        then:
> > +          patternProperties:
> > +            "grp$": false
> > +            "-pins$": true
> > +        else:
> > +          patternProperties:
> > +            "grp$": false
> > +            "-pins$": true
> > +    unevaluatedProperties: false
> 
> This will not scale if each vendor adds to arm,scmi.yaml. You need to move
> this to its own file. That can have a ref to
> /schemas/firmware/arm,scmi.yaml#/$defs/protocol-node.
> 
> Here you can just say compatible is "fsl,imx95-scmi-pinctrl" and
> 'additionalProperties: true'.

Do you have an example for this? I am not able write a correct
one to pass the dt check.
      - if:                                                                                         
          properties:                                                                               
            compatible:                                                                             
              const: fsl,imx95-scmi-pinctrl                                                         
        then:                                                                                       
          properties:                                                                               
            additionalProperties: true

.......
      compatible: true

And in fsl,imx95-scmi-pinctrl.yaml

allOf:                                                                                              
  - $ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node'                                    
                                                                                                    
properties:                                                                                         
  reg:                                                                                              
    const: 0x19                                                                                     
                                                                                                    
  compatible:                                                                                       
    const: fsl,imx95-scmi-pinctrl                                                                   
                                                                                                    
patternProperties:                                                                                  
  'grp$':                                                                                           
    type: object                                                                                    
    description:                                                                                    
      Pinctrl node's client devices use subnodes for desired pin configuration.                     
      Client device subnodes use below standard properties.                                         
                                                                                                    
    properties:                                                                                     
      fsl,pins:                                                                                     
        description:      

.....
> 
> > +
> > +    properties:
> > +      reg:
> > +        const: 0x19
> > +
> > +      '#pinctrl-cells':
> > +        const: 0
> 
> Generally not used if 0.

Will drop this property.

> 
> > +
> > +      compatible:
> > +        const: fsl,imx95-scmi-pinctrl
> > +
> > +    patternProperties:
> > +      '-pins$':
> > +        type: object
> > +        allOf:
> > +          - $ref: /schemas/pinctrl/pincfg-node.yaml#
> > +          - $ref: /schemas/pinctrl/pinmux-node.yaml#
> > +        unevaluatedProperties: false
> > +
> > +        description:
> > +          A pin multiplexing sub-node describe how to configure a
> > +          set of pins is some desired function.
> > +          A single sub-node may define several pin configurations.
> > +          This sub-node is using default pinctrl bindings to configure
> > +          pin multiplexing and using SCMI protocol to apply specified
> > +          configuration using SCMI protocol.
> > +
> > +      'grp$':
> > +        type: object
> > +        description:
> > +          Pinctrl node's client devices use subnodes for desired pin
> configuration.
> > +          Client device subnodes use below standard properties.
> > +
> > +        properties:
> > +          fsl,pins:
> > +            description:
> > +              each entry consists of 6 integers and represents the mux and
> config
> > +              setting for one pin. The first 5 integers <mux_reg conf_reg
> input_reg
> > +              mux_val input_val> are specified using a PIN_FUNC_ID macro,
> which can
> > +              be found in <arch/arm64/boot/dts/freescale/imx95-pinfunc.h>.
> The last
> > +              integer CONFIG is the pad setting value like pull-up on this pin.
> Please
> > +              refer to i.MX95 Plus Reference Manual for detailed CONFIG
> settings.
> > +            $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +            items:
> > +              items:
> > +                - description: |
> > +                    "mux_reg" indicates the offset of mux register.
> > +                - description: |
> > +                    "conf_reg" indicates the offset of pad configuration register.
> > +                - description: |
> > +                    "input_reg" indicates the offset of select input register.
> > +                - description: |
> > +                    "mux_val" indicates the mux value to be applied.
> > +                - description: |
> > +                    "input_val" indicates the select input value to be applied.
> > +                - description: |
> > +                    "pad_setting" indicates the pad configuration value to be
> applied.
> > +
> > +    required:
> > +      - reg
> > +
> >  additionalProperties: false
> >
> >  $defs:
> > @@ -401,6 +480,26 @@ examples:
> >              scmi_powercap: protocol at 18 {
> >                  reg = <0x18>;
> >              };
> > +
> > +            scmi_pinctrl: protocol at 19 {
> > +                reg = <0x19>;
> > +                #pinctrl-cells = <0>;
> 
> Missing compatible. Schema should catch that...

Only i.MX need compatible here.

Thanks,
Peng.

> 
> > +
> > +                i2c2-pins {
> > +                    groups = "i2c2_a", "i2c2_b";
> > +                    function = "i2c2";
> > +                };
> > +
> > +                mdio-pins {
> > +                    groups = "avb_mdio";
> > +                    drive-strength = <24>;
> > +                };
> > +
> > +                keys_pins: keys-pins {
> > +                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> > +                    bias-pull-up;
> > +                };
> > +            };
> >          };
> >      };
> >
> >
> > --
> > 2.37.1
> >


From andersson at kernel.org  Fri Dec 15 21:11:22 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Fri, 15 Dec 2023 23:11:22 -0600
Subject: [PATCH] arm64: defconfig: enable GPU clock controller for
 SM8[45]50
In-Reply-To: <20231204-topic-sm8x50-upstream-gpucc-defconfig-v1-1-e615df0c4af9@linaro.org>
References: <20231204-topic-sm8x50-upstream-gpucc-defconfig-v1-1-e615df0c4af9@linaro.org>
Message-ID: <5kkk7j6425wshf2bmmhrh26jwc3rstcrm6kgxyyzowq2qqrfw2@u2mgm6qefxvk>

On Mon, Dec 04, 2023 at 02:01:47PM +0100, Neil Armstrong wrote:
> Enable GPU Clock Controller for SM8450 and SM8550 to allow using
> Adreno GPU on these SoCs.
> 
> Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
> ---
>  arch/arm64/configs/defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 5ad2b841aafc..56aebbdcdd40 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -1266,6 +1266,8 @@ CONFIG_SM_TCSRCC_8550=y
>  CONFIG_SM_GPUCC_6115=m
>  CONFIG_SM_GPUCC_8150=y
>  CONFIG_SM_GPUCC_8250=y
> +CONFIG_SM_GPUCC_8450=y
> +CONFIG_SM_GPUCC_8550=y

I don't think these needs to be builtin, and if they do I'd like to see
the reason captured in the commit message.

Regards,
Bjorn

>  CONFIG_SM_VIDEOCC_8250=y
>  CONFIG_QCOM_HFPLL=y
>  CONFIG_CLK_GFM_LPASS_SM8250=m
> 
> ---
> base-commit: 9046d05c6ad632a271fc4173624e26f396975a80
> change-id: 20231204-topic-sm8x50-upstream-gpucc-defconfig-3e3dc264be08
> 
> Best regards,
> -- 
> Neil Armstrong <neil.armstrong at linaro.org>
> 


From lkp at intel.com  Fri Dec 15 21:17:00 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 16 Dec 2023 13:17:00 +0800
Subject: [linux-next:master] BUILD REGRESSION
 17cb8a20bde66a520a2ca7aad1063e1ce7382240
Message-ID: <202312161352.wMZ6kGnT-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 17cb8a20bde66a520a2ca7aad1063e1ce7382240  Add linux-next specific files for 20231215

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202312151816.munFeE4L-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312151854.4k8dhWf6-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312160153.ovUEsxo6-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312160433.Oz8VJHH3-lkp at intel.com
https://lore.kernel.org/oe-kbuild-all/202312161324.nZN1zCQT-lkp at intel.com

Error/Warning: (recently discovered and may have been fixed)

arch/arm/include/asm/cmpxchg.h:111:(.text+0xf6c): undefined reference to `__bad_xchg'
callback.c:(.rodata.cst4+0x18): undefined reference to `__xchg_called_with_bad_pointer'
callback.c:(.text+0x114): undefined reference to `__xchg_called_with_bad_pointer'
drivers/net/ethernet/intel/ice/ice_base.c:525:16: error: variable 'desc' has initializer but incomplete type
drivers/net/ethernet/intel/ice/ice_base.c:525:28: error: storage size of 'desc' isn't known
drivers/net/ethernet/intel/ice/ice_base.c:525:28: warning: unused variable 'desc' [-Wunused-variable]
fs/bcachefs/btree_iter.c:3090:36: sparse:    struct btree_path *
fs/bcachefs/btree_iter.c:3090:36: sparse:    struct btree_path [noderef] __rcu *
fs/bcachefs/btree_locking.c:309:36: sparse:    struct btree_path *
fs/bcachefs/btree_locking.c:309:36: sparse:    struct btree_path [noderef] __rcu *
include/asm-generic/cmpxchg.h:76:(.text+0x1d0): relocation truncated to fit: R_NIOS2_CALL26 against `__generic_xchg_called_with_bad_pointer'
include/linux/compiler_types.h:435:45: error: call to '__compiletime_assert_38' declared with attribute error: Unsupported size for __xchg_relaxed
io.c:(.text+0x6): relocation truncated to fit: R_CKCORE_PCREL_IMM16BY4 against `__jump_table'
m68k-linux-ld: callback.c:(.text+0x228): undefined reference to `__invalid_xchg_size'
mm/ksm.c:344:13: warning: 'set_advisor_defaults' defined but not used [-Wunused-function]
rotate.c:(.rodata.cst4+0x30): undefined reference to `__xchg_called_with_bad_pointer'
scripts/kernel-doc: drivers/spi/spi-pl022.c:397: warning: Excess struct member 'cur_msg' description in 'pl022'
scripts/kernel-doc: drivers/spi/spi-pl022.c:437: warning: Excess function parameter 'command' description in 'internal_cs_control'
scripts/kernel-doc: drivers/spi/spi-pl022.c:437: warning: Function parameter or struct member 'enable' not described in 'internal_cs_control'

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- arc-randconfig-002-20231215
|   |-- drivers-net-ethernet-intel-ice-ice_base.c:error:storage-size-of-desc-isn-t-known
|   |-- drivers-net-ethernet-intel-ice-ice_base.c:error:variable-desc-has-initializer-but-incomplete-type
|   `-- drivers-net-ethernet-intel-ice-ice_base.c:warning:unused-variable-desc
|-- arc-randconfig-r132-20231215
|   |-- drivers-hwmon-max31827.c:sparse:sparse:dubious:x-y
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- arm-buildonly-randconfig-r002-20220918
|   `-- arch-arm-include-asm-cmpxchg.h:(.text):undefined-reference-to-__bad_xchg
|-- arm-lpc18xx_defconfig
|   |-- scripts-kernel-doc:drivers-spi-spi-pl022.c:warning:Excess-function-parameter-command-description-in-internal_cs_control
|   |-- scripts-kernel-doc:drivers-spi-spi-pl022.c:warning:Excess-struct-member-cur_msg-description-in-pl022
|   `-- scripts-kernel-doc:drivers-spi-spi-pl022.c:warning:Function-parameter-or-struct-member-enable-not-described-in-internal_cs_control
|-- csky-randconfig-001-20231215
|   `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|-- csky-randconfig-r016-20220425
|   `-- io.c:(.text):relocation-truncated-to-fit:R_CKCORE_PCREL_IMM16BY4-against-__jump_table
|-- csky-randconfig-r113-20231215
|   |-- arch-csky-kernel-vdso-vgettimeofday.c:sparse:sparse:function-__vdso_clock_gettime-with-external-linkage-has-definition
|   |-- fs-bcachefs-btree_iter.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-address-spaces):
|   |-- fs-bcachefs-btree_iter.c:sparse:struct-btree_path
|   |-- fs-bcachefs-btree_iter.c:sparse:struct-btree_path-noderef-__rcu
|   |-- fs-bcachefs-btree_locking.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-address-spaces):
|   |-- fs-bcachefs-btree_locking.c:sparse:struct-btree_path
|   |-- fs-bcachefs-btree_locking.c:sparse:struct-btree_path-noderef-__rcu
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- i386-randconfig-013-20231215
|   `-- drivers-hid-hid-nintendo.c:error:initializer-element-is-not-constant
|-- loongarch-defconfig
|   `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-hwss-dcn35-dcn35_hwseq.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
|-- loongarch-randconfig-001-20231215
|   `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-hwss-dcn35-dcn35_hwseq.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
|-- loongarch-randconfig-002-20231215
|   `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-hwss-dcn35-dcn35_hwseq.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
|-- m68k-randconfig-r012-20211002
|   `-- m68k-linux-ld:callback.c:(.text):undefined-reference-to-__invalid_xchg_size
|-- microblaze-randconfig-r121-20231215
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- microblaze-randconfig-r122-20231215
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-opcode-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-owner-got-int
|   |-- drivers-soc-qcom-pmic_pdcharger_ulog.c:sparse:sparse:incorrect-type-in-initializer-(different-base-types)-expected-restricted-__le32-usertype-type-got-int
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- mips-decstation_64_defconfig
|   `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|-- mips-fuloong2e_defconfig
|   |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-base-regmap-regmap-mmio.o
|   `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|-- mips-jazz_defconfig
|   |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|   `-- cache.c:(.text):undefined-reference-to-r3k_cache_init
|-- nios2-allyesconfig
|   |-- callback.c:(.text):relocation-truncated-to-fit:R_NIOS2_CALL26-against-__generic_xchg_called_with_bad_pointer
|   `-- rotate.c:(.text):relocation-truncated-to-fit:R_NIOS2_CALL26-against-__generic_xchg_called_with_bad_pointer
|-- nios2-randconfig-r035-20230329
|   `-- include-asm-generic-cmpxchg.h:(.text):relocation-truncated-to-fit:R_NIOS2_CALL26-against-__generic_xchg_called_with_bad_pointer
|-- openrisc-randconfig-r016-20230621
|   `-- mm-ksm.c:warning:set_advisor_defaults-defined-but-not-used
|-- openrisc-randconfig-r111-20231215
|   |-- drivers-hwmon-max31827.c:sparse:sparse:dubious:x-y
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- parisc-randconfig-001-20231215
|   `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|-- parisc-randconfig-r015-20220820
|   |-- callback.c:(.rodata.cst4):undefined-reference-to-__xchg_called_with_bad_pointer
|   `-- rotate.c:(.rodata.cst4):undefined-reference-to-__xchg_called_with_bad_pointer
|-- powerpc-randconfig-c003-20220424
|   `-- include-linux-compiler_types.h:error:call-to-__compiletime_assert_NNN-declared-with-attribute-error:Unsupported-size-for-__xchg_relaxed
|-- s390-randconfig-r133-20231215
|   |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|   |-- drivers-hwmon-max31827.c:sparse:sparse:dubious:x-y
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- sparc-allmodconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc-allnoconfig
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-defconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-randconfig-001-20231215
|   |-- (.head.text):relocation-truncated-to-fit:R_SPARC_WDISP22-against-init.text
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   `-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|-- sparc-randconfig-002-20231215
|   |-- (.head.text):relocation-truncated-to-fit:R_SPARC_WDISP22-against-init.text
|   |-- arch-sparc-mm-leon_mm.c:warning:variable-paddrbase-set-but-not-used
|   |-- arch-sparc-mm-srmmu.c:warning:variable-clear-set-but-not-used
|   |-- parport_pc.c:(.text):undefined-reference-to-ebus_dma_enable
|   |-- parport_pc.c:(.text):undefined-reference-to-ebus_dma_irq_enable
|   |-- parport_pc.c:(.text):undefined-reference-to-ebus_dma_register
|   |-- sparc-linux-ld:parport_pc.c:(.text):undefined-reference-to-ebus_dma_enable
|   |-- sparc-linux-ld:parport_pc.c:(.text):undefined-reference-to-ebus_dma_irq_enable
|   |-- sparc-linux-ld:parport_pc.c:(.text):undefined-reference-to-ebus_dma_prepare
|   |-- sparc-linux-ld:parport_pc.c:(.text):undefined-reference-to-ebus_dma_request
|   |-- sparc-linux-ld:parport_pc.c:(.text):undefined-reference-to-ebus_dma_residue
|   `-- sparc-linux-ld:parport_pc.c:(.text):undefined-reference-to-ebus_dma_unregister
|-- sparc64-allmodconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-allyesconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-defconfig
|   |-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-randconfig-001-20231215
|   `-- arch-sparc-mm-init_64.c:warning:variable-hv_pgsz_idx-set-but-not-used
|-- sparc64-randconfig-002-20231215
|   `-- arch-sparc-mm-init_64.c:warning:variable-pagecv_flag-set-but-not-used
|-- sparc64-randconfig-r062-20231215
|   `-- arch-sparc-kernel-module.c:warning:variable-strtab-set-but-not-used
|-- x86_64-allnoconfig
|   `-- Warning:MAINTAINERS-references-a-file-that-doesn-t-exist:Documentation-devicetree-bindings-display-panel-synaptics-r63353.yaml
|-- x86_64-randconfig-001-20231215
|   `-- drivers-hid-hid-nintendo.c:error:initializer-element-is-not-constant
|-- x86_64-randconfig-r131-20231215
|   |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-hwss-dcn35-dcn35_hwseq.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
|   `-- drivers-hwmon-max31827.c:sparse:sparse:dubious:x-y
`-- xtensa-randconfig-c024-20220216
    `-- callback.c:(.text):undefined-reference-to-__xchg_called_with_bad_pointer
clang_recent_errors
|-- arm-defconfig
|   |-- WARNING:modpost:vmlinux:section-mismatch-in-reference:at91_poweroff_probe-(section:.text)-at91_wakeup_status-(section:.init.text)
|   `-- WARNING:modpost:vmlinux:section-mismatch-in-reference:at91_shdwc_probe-(section:.text)-at91_wakeup_status-(section:.init.text)
|-- arm64-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- arm64-allyesconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- hexagon-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- hexagon-allyesconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- i386-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- i386-buildonly-randconfig-006-20231215
|   |-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-drivers-base-regmap-regmap-mmio.o
|   `-- WARNING:modpost:missing-MODULE_DESCRIPTION()-in-lib-zlib_inflate-zlib_inflate.o
|-- i386-randconfig-063-20231215
|   |-- fs-afs-main.c:sparse:sparse:cast-removes-address-space-__rcu-of-expression
|   |-- fs-afs-main.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-struct-callback_head-head-got-struct-callback_head-noderef-__rcu
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- powerpc-allmodconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- powerpc-allyesconfig
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- riscv-randconfig-r112-20231215
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- s390-randconfig-r123-20231215
|   |-- drivers-hwmon-max31827.c:sparse:sparse:dubious:x-y
|   `-- lib-zstd-compress-zstd_fast.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
|-- x86_64-allmodconfig
|   |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-hwss-dcn35-dcn35_hwseq.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
|-- x86_64-allyesconfig
|   |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-hwss-dcn35-dcn35_hwseq.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst
|   `-- drivers-leds-leds-max5970.c:warning:variable-num_leds-set-but-not-used
`-- x86_64-randconfig-161-20231215
    |-- lib-zstd-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
    |-- lib-zstd-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
    |-- lib-zstd-compress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
    |-- lib-zstd-compress-..-common-bits.h-ZSTD_countLeadingZeros64()-warn:inconsistent-indenting
    |-- lib-zstd-compress-..-common-bits.h-ZSTD_countTrailingZeros32()-warn:inconsistent-indenting
    |-- lib-zstd-compress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting
    |-- lib-zstd-decompress-..-common-bits.h-ZSTD_countLeadingZeros32()-warn:inconsistent-indenting
    `-- lib-zstd-decompress-..-common-bits.h-ZSTD_countTrailingZeros64()-warn:inconsistent-indenting

elapsed time: 1467m

configs tested: 166
configs skipped: 2

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                                 defconfig   gcc  
arc                            hsdk_defconfig   gcc  
arc                   randconfig-001-20231215   gcc  
arc                   randconfig-002-20231215   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   gcc  
arm                              allyesconfig   gcc  
arm                     am200epdkit_defconfig   clang
arm                                 defconfig   clang
arm                            dove_defconfig   clang
arm                            hisi_defconfig   gcc  
arm                            mmp2_defconfig   clang
arm                          pxa168_defconfig   clang
arm                          pxa3xx_defconfig   gcc  
arm                   randconfig-001-20231215   clang
arm                   randconfig-002-20231215   clang
arm                   randconfig-003-20231215   clang
arm                   randconfig-004-20231215   clang
arm                           stm32_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231215   clang
arm64                 randconfig-002-20231215   clang
arm64                 randconfig-003-20231215   clang
arm64                 randconfig-004-20231215   clang
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231215   gcc  
csky                  randconfig-002-20231215   gcc  
hexagon                          allmodconfig   clang
hexagon                           allnoconfig   clang
hexagon                          allyesconfig   clang
hexagon                             defconfig   clang
hexagon               randconfig-001-20231215   clang
hexagon               randconfig-002-20231215   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231215   clang
i386         buildonly-randconfig-002-20231215   clang
i386         buildonly-randconfig-003-20231215   clang
i386         buildonly-randconfig-004-20231215   clang
i386         buildonly-randconfig-005-20231215   clang
i386         buildonly-randconfig-006-20231215   clang
i386                                defconfig   gcc  
i386                  randconfig-001-20231215   clang
i386                  randconfig-002-20231215   clang
i386                  randconfig-003-20231215   clang
i386                  randconfig-004-20231215   clang
i386                  randconfig-005-20231215   clang
i386                  randconfig-006-20231215   clang
i386                  randconfig-011-20231215   gcc  
i386                  randconfig-012-20231215   gcc  
i386                  randconfig-013-20231215   gcc  
i386                  randconfig-014-20231215   gcc  
i386                  randconfig-015-20231215   gcc  
i386                  randconfig-016-20231215   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231215   gcc  
loongarch             randconfig-002-20231215   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                          atari_defconfig   gcc  
m68k                                defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                              allnoconfig   clang
mips                             allyesconfig   gcc  
mips                  decstation_64_defconfig   gcc  
mips                      fuloong2e_defconfig   gcc  
mips                           jazz_defconfig   gcc  
mips                      malta_kvm_defconfig   clang
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231215   gcc  
nios2                 randconfig-002-20231215   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
openrisc                  or1klitex_defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231215   gcc  
parisc                randconfig-002-20231215   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                  mpc885_ads_defconfig   clang
powerpc               randconfig-001-20231215   clang
powerpc               randconfig-002-20231215   clang
powerpc               randconfig-003-20231215   clang
powerpc64             randconfig-001-20231215   clang
powerpc64             randconfig-002-20231215   clang
powerpc64             randconfig-003-20231215   clang
riscv                            allmodconfig   gcc  
riscv                             allnoconfig   clang
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231215   clang
riscv                 randconfig-002-20231215   clang
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231215   gcc  
s390                  randconfig-002-20231215   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                         ecovec24_defconfig   gcc  
sh                          lboxre2_defconfig   gcc  
sh                    randconfig-001-20231215   gcc  
sh                    randconfig-002-20231215   gcc  
sh                           se7721_defconfig   gcc  
sh                           se7750_defconfig   gcc  
sh                            shmin_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231215   gcc  
sparc64               randconfig-002-20231215   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231215   clang
um                    randconfig-002-20231215   clang
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231215   clang
x86_64       buildonly-randconfig-003-20231215   clang
x86_64       buildonly-randconfig-005-20231215   clang
x86_64                              defconfig   gcc  
x86_64                randconfig-001-20231215   gcc  
x86_64                randconfig-003-20231215   gcc  
x86_64                randconfig-004-20231215   gcc  
x86_64                randconfig-005-20231215   gcc  
x86_64                randconfig-006-20231215   gcc  
x86_64                          rhel-8.3-rust   clang
xtensa                            allnoconfig   gcc  
xtensa                randconfig-001-20231215   gcc  
xtensa                randconfig-002-20231215   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From andersson at kernel.org  Fri Dec 15 21:26:37 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Fri, 15 Dec 2023 23:26:37 -0600
Subject: [PATCH 3/3] ARM: qcom: merge remaining subplatforms into
 sensible Kconfig entry
In-Reply-To: <20231207125500.3322229-4-dmitry.baryshkov@linaro.org>
References: <20231207125500.3322229-1-dmitry.baryshkov@linaro.org>
 <20231207125500.3322229-4-dmitry.baryshkov@linaro.org>
Message-ID: <hhaf3ocpnejsxpkg6mfodwnkbjttyb2h5p3qsifbyukosvsavj@rwdpgzsovwak>

On Thu, Dec 07, 2023 at 03:55:00PM +0300, Dmitry Baryshkov wrote:
> Three remaining Qualcomm platforms have special handling of the
> TEXT_OFFSET to reserve the memory at the beginnig of the system RAM, see
> the commit 9e775ad19f52 ("ARM: 7012/1: Set proper TEXT_OFFSET for newer
> MSMs"). This is required for older platforms like IPQ40xx, MSM8x60,
> MSM8960 and APQ8064 and is compatible with other 32-bit Qualcomm
> platforms.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> ---
>  arch/arm/Makefile          |  4 +---
>  arch/arm/mach-qcom/Kconfig | 13 +++++--------
>  2 files changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 5ba42f69f8ce..45fa8ac001c5 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -158,9 +158,7 @@ textofs-$(CONFIG_ARCH_REALTEK)  := 0x00108000
>  ifeq ($(CONFIG_ARCH_SA1100),y)
>  textofs-$(CONFIG_SA1111) := 0x00208000
>  endif
> -textofs-$(CONFIG_ARCH_IPQ40XX) := 0x00208000
> -textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> -textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> +textofs-$(CONFIG_ARCH_QCOM_SMEM) := 0x00208000
>  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
>  
> diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
> index 27d5ca0043be..0c99d0a746d4 100644
> --- a/arch/arm/mach-qcom/Kconfig
> +++ b/arch/arm/mach-qcom/Kconfig
> @@ -15,13 +15,10 @@ menuconfig ARCH_QCOM
>  
>  if ARCH_QCOM
>  
> -config ARCH_IPQ40XX
> -	bool "Enable support for IPQ40XX"
> -
> -config ARCH_MSM8X60
> -	bool "Enable support for MSM8X60"
> -
> -config ARCH_MSM8960
> -	bool "Enable support for MSM8960"
> +config ARCH_QCOM_SMEM

How about expanding this to ARCH_QCOM_RESERVE_SMEM or similar, to make
it more descriptive and less similar to the existing QCOM_SMEM option?

Regards,
Bjorn


> +	bool "Reserve SMEM at the beginning of RAM"
> +	help
> +	  Reserve 2MB at the beginning of the System RAM for shared mem.
> +	  This is required on IPQ40xx, MSM8x60 and MSM8960 platforms.
>  
>  endif
> -- 
> 2.39.2
> 


From shawnguo at kernel.org  Fri Dec 15 22:46:01 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 14:46:01 +0800
Subject: [GIT PULL 1/5] i.MX drivers change for 6.8
Message-ID: <20231216064605.876196-1-shawnguo@kernel.org>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-drivers-6.8

for you to fetch changes up to fcefbb49ebb7ad9f06ecee33ae87e4d7075728ff:

  bus: imx-weim: Use device_get_match_data() (2023-11-27 11:05:30 +0800)

----------------------------------------------------------------
i.MX drivers change for 6.8:

- Change imx-weim bus driver to use device_get_match_data()

----------------------------------------------------------------
Rob Herring (1):
      bus: imx-weim: Use device_get_match_data()

 drivers/bus/imx-weim.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)


From shawnguo at kernel.org  Fri Dec 15 22:46:02 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 14:46:02 +0800
Subject: [GIT PULL 2/5] i.MX SoC change for 6.8
In-Reply-To: <20231216064605.876196-1-shawnguo@kernel.org>
References: <20231216064605.876196-1-shawnguo@kernel.org>
Message-ID: <20231216064605.876196-2-shawnguo@kernel.org>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-soc-6.8

for you to fetch changes up to c8705471b94d0d869e2e3ac80c0d960f0215474f:

  ARM: mxs: Do not search for "fsl,clkctrl" (2023-12-06 11:21:43 +0800)

----------------------------------------------------------------
i.MX SoC change for 6.8:

- Update mach-imx MMDC driver to use device_get_match_data().
- Drop the use of "fsl,clkctrl" from mach-mxs platform code, as it's
  an undocumented compatible.

----------------------------------------------------------------
Fabio Estevam (1):
      ARM: mxs: Do not search for "fsl,clkctrl"

Rob Herring (1):
      ARM: imx: Use device_get_match_data()

 arch/arm/mach-imx/mmdc.c     | 9 ++++-----
 arch/arm/mach-mxs/mach-mxs.c | 4 +++-
 2 files changed, 7 insertions(+), 6 deletions(-)


From shawnguo at kernel.org  Fri Dec 15 22:46:03 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 14:46:03 +0800
Subject: [GIT PULL 3/5] i.MX DT bindings for 6.8
In-Reply-To: <20231216064605.876196-1-shawnguo@kernel.org>
References: <20231216064605.876196-1-shawnguo@kernel.org>
Message-ID: <20231216064605.876196-3-shawnguo@kernel.org>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-bindgins-6.8

for you to fetch changes up to 6cbac23b309cc6454779703a741392df4e80455f:

  dt-bindings: arm: fsl: add Dimonoff gateway EVK board (2023-12-14 10:49:21 +0800)

----------------------------------------------------------------
i.MX DT bindings for 6.8:

- New vendor prefix for Dimonoff and echarge V?hicule ?lectrique (RVE).
- New board compatible for TQ-Systems LX2160A, RVE gateway, Dimonoff
  gateway EVK, i.MX8M Mallow and SKOV i.MX8MP RevB board.

----------------------------------------------------------------
Gregor Herburger (1):
      dt-bindings: arm: fsl: Add TQ-Systems LX2160A based boards

Hugo Villeneuve (4):
      dt-bindings: vendor-prefixes: add rve
      dt-bindings: arm: fsl: add RVE gateway board
      dt-bindings: vendor-prefixes: add dimonoff
      dt-bindings: arm: fsl: add Dimonoff gateway EVK board

Joao Paulo Goncalves (2):
      dt-bindings: arm: fsl: add verdin imx8mm mallow board
      dt-bindings: arm: fsl: add verdin imx8mp mallow board

Oleksij Rempel (1):
      dt-bindings: arm: Add compatible for SKOV i.MX8MP RevB board

 Documentation/devicetree/bindings/arm/fsl.yaml     | 22 +++++++++++++++++++++-
 .../devicetree/bindings/vendor-prefixes.yaml       |  4 ++++
 2 files changed, 25 insertions(+), 1 deletion(-)


From shawnguo at kernel.org  Fri Dec 15 22:46:04 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 14:46:04 +0800
Subject: [GIT PULL 4/5] i.MX ARM device tree for 6.8
In-Reply-To: <20231216064605.876196-1-shawnguo@kernel.org>
References: <20231216064605.876196-1-shawnguo@kernel.org>
Message-ID: <20231216064605.876196-4-shawnguo@kernel.org>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt-6.8

for you to fetch changes up to 47360e40dcb92c09f417ccbe956e646bd95a09b6:

  ARM: dts: imx27-phytec-phycore-som: Use 'rtc' as node name (2023-12-16 09:46:40 +0800)

----------------------------------------------------------------
i.MX ARM device tree for 6.8:

- A bunch of changes from Fabio Estevam cleaning up dt-schema warnings.
- A number of i.MX7 related small fixes and peripheral addition from
  Alexander Stein.
- A set of changes from Hiago De Franco adding usdhc aliases for Apalis
  and Colibri boards.
- A white-space cleanup from Krzysztof Kozlowski.
- A change from Linus Walleij to correct errors in the Marvell MV88E6xxx
  switch descriptions.
- Fix a couple of typo in comment for MBA6 and MBA6ULX board.
- Add on-chip memory and enable MIPI-DSI support for i.MX7.
- Add LM75A sensor for TQMA7 board.

----------------------------------------------------------------
Alexander Stein (5):
      ARM: dts: imx7d: Fix coresight funnel ports
      ARM: dts: imx7s: Fix lcdif compatible
      ARM: dts: imx7s: Fix nand-controller #size-cells
      ARM: dts: imx7s: Add missing #thermal-sensor-cells
      ARM: dts: imx7s: Add DMA channels for CSPI peripherals

Andrejs Cainikovs (1):
      ARM: dts: imx6q-apalis: add can power-up delay on ixora board

Fabio Estevam (24):
      ARM: dts: imx28-tx28: Pass #sound-dai-cells
      ARM: dts: imx23/28: Remove unneeded "fsl,mxs-gpio"
      ARM: dts: imx28-lwe: Pass device_type to the memory node
      ARM: dts: imx23/28: Remove undocumented "fsl,clkctrl"
      ARM: dts: imx25: Pass I2C clock-names property
      ARM: dts: imx25-pdk: Pass #sound-dai-cells
      ARM: dts: imx25/27-eukrea: Fix RTC node name
      ARM: dts: imx: Use flash at 0,0 pattern
      ARM: dts: imx27: Fix sram node
      ARM: dts: imx1: Fix sram node
      ARM: dts: imx27-phytec-phycore-som: Use the mux- prefix
      ARM: dts: imx27: Use 'bus' for AIPI bus
      ARM: dts: imx27: Use 'bus' for EMI bus
      ARM: dts: imx27-pdk: Move usbphy0 out of simple-bus
      ARM: dts: imx27-phytec-phycore-rdk: Move usbphy nodes out of simple-bus
      ARM: dts: imx1: Use 'bus' for AIPI bus
      ARM: dts: imx25: Move usbphy nodes out of simple-bus
      ARM: dts: imx25: Fix the iim compatible string
      ARM: dts: imx25/27: Pass timing0
      ARM: dts: imx27-apf27dev: Fix LED name
      ARM: dts: imx23-sansa: Use preferred i2c-gpios properties
      ARM: dts: imx23/28: Fix the DMA controller node name
      ARM: dts: imx25: Remove unneeded keypad properties
      ARM: dts: imx27-phytec-phycore-som: Use 'rtc' as node name

Hiago De Franco (3):
      ARM: dts: imx6qdl-apalis: Add usdhc aliases
      ARM: dts: imx6qdl-colibri: Add usdhc aliases
      ARM: dts: imx7d-colibri-emmc: Add usdhc aliases

Jo?o Rodrigues (1):
      ARM: dts: imx: tqma7: add lm75a sensor (rev. 01xxx)

Krzysztof Kozlowski (1):
      ARM: dts: nxp: minor whitespace cleanup around '='

Lech Perczak (1):
      ARM: dts: nxp: imx7d-pico: add cpu-supply nodes

Linus Walleij (1):
      ARM: dts: nxp: Fix some common switch mistakes

Marco Felsch (1):
      ARM: dts: imx7: add MIPI-DSI support

Markus Niebel (2):
      ARM: dts: imx6qdl: mba6: fix typo in comments
      ARM: dts: imx6ul: mba6ulx: fix typo in comments

Philipp Zabel (1):
      ARM: dts: imx7s: Add on-chip memory

 arch/arm/boot/dts/nxp/imx/imx1-ads.dts             |  2 +-
 arch/arm/boot/dts/nxp/imx/imx1-apf9328.dts         |  2 +-
 arch/arm/boot/dts/nxp/imx/imx1.dtsi                |  9 ++-
 .../boot/dts/nxp/imx/imx25-eukrea-cpuimx25.dtsi    |  2 +-
 .../imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts  |  2 +-
 .../imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts  |  2 +-
 .../imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts   |  2 +-
 arch/arm/boot/dts/nxp/imx/imx25-pdk.dts            |  3 +-
 arch/arm/boot/dts/nxp/imx/imx25.dtsi               | 41 +++++-------
 arch/arm/boot/dts/nxp/imx/imx27-apf27dev.dts       |  4 +-
 .../boot/dts/nxp/imx/imx27-eukrea-cpuimx27.dtsi    |  4 +-
 .../nxp/imx/imx27-eukrea-mbimxsd27-baseboard.dts   |  2 +-
 arch/arm/boot/dts/nxp/imx/imx27-pdk.dts            | 18 ++----
 .../dts/nxp/imx/imx27-phytec-phycard-s-rdk.dts     |  2 +-
 .../boot/dts/nxp/imx/imx27-phytec-phycore-rdk.dts  | 17 ++---
 .../boot/dts/nxp/imx/imx27-phytec-phycore-som.dtsi | 28 ++++----
 arch/arm/boot/dts/nxp/imx/imx27.dtsi               |  7 +-
 arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts         |  2 +-
 arch/arm/boot/dts/nxp/imx/imx6dl-b105pv2.dts       |  2 +-
 arch/arm/boot/dts/nxp/imx/imx6dl-b105v2.dts        |  2 +-
 arch/arm/boot/dts/nxp/imx/imx6dl-b125pv2.dts       |  2 +-
 arch/arm/boot/dts/nxp/imx/imx6dl-b125v2.dts        |  2 +-
 arch/arm/boot/dts/nxp/imx/imx6dl-b155v2.dts        |  2 +-
 .../boot/dts/nxp/imx/imx6q-apalis-ixora-v1.2.dts   |  2 +
 .../boot/dts/nxp/imx/imx6q-var-mx6customboard.dts  |  4 +-
 arch/arm/boot/dts/nxp/imx/imx6qdl-apalis.dtsi      |  9 ++-
 arch/arm/boot/dts/nxp/imx/imx6qdl-colibri.dtsi     |  7 ++
 arch/arm/boot/dts/nxp/imx/imx6qdl-emcon-avari.dtsi |  2 +-
 arch/arm/boot/dts/nxp/imx/imx6qdl-mba6.dtsi        |  6 +-
 .../boot/dts/nxp/imx/imx6qdl-skov-cpu-revc.dtsi    |  2 +-
 arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi             |  2 +-
 arch/arm/boot/dts/nxp/imx/imx6sx.dtsi              |  8 +--
 arch/arm/boot/dts/nxp/imx/imx6ul.dtsi              |  2 +-
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi          |  9 ++-
 arch/arm/boot/dts/nxp/imx/imx7d-colibri-emmc.dtsi  |  4 ++
 arch/arm/boot/dts/nxp/imx/imx7d-meerkat96.dts      |  2 +-
 arch/arm/boot/dts/nxp/imx/imx7d-pico.dtsi          |  8 +++
 arch/arm/boot/dts/nxp/imx/imx7d-smegw01.dts        |  2 +-
 arch/arm/boot/dts/nxp/imx/imx7d.dtsi               |  3 -
 arch/arm/boot/dts/nxp/imx/imx7s.dtsi               | 74 +++++++++++++++++++++-
 arch/arm/boot/dts/nxp/imx/mba6ulx.dtsi             |  2 +-
 arch/arm/boot/dts/nxp/lpc/lpc18xx.dtsi             |  2 +-
 arch/arm/boot/dts/nxp/ls/ls1021a.dtsi              |  2 +-
 arch/arm/boot/dts/nxp/mxs/imx23-sansa.dts          | 12 ++--
 arch/arm/boot/dts/nxp/mxs/imx23.dtsi               | 10 +--
 arch/arm/boot/dts/nxp/mxs/imx28-lwe.dtsi           |  1 +
 arch/arm/boot/dts/nxp/mxs/imx28-tx28.dts           |  1 +
 arch/arm/boot/dts/nxp/mxs/imx28.dtsi               | 14 ++--
 arch/arm/boot/dts/nxp/vf/vf-colibri-eval-v3.dtsi   |  2 +-
 arch/arm/boot/dts/nxp/vf/vf610-bk4.dts             |  4 +-
 arch/arm/boot/dts/nxp/vf/vf610-zii-cfu1.dts        | 14 ++--
 arch/arm/boot/dts/nxp/vf/vf610-zii-dev-rev-b.dts   |  6 +-
 arch/arm/boot/dts/nxp/vf/vf610-zii-scu4-aib.dts    | 70 ++++++++++----------
 arch/arm/boot/dts/nxp/vf/vf610-zii-spb4.dts        | 18 +++---
 arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-dtu.dts    | 20 +++---
 arch/arm/boot/dts/nxp/vf/vf610-zii-ssmb-spu3.dts   | 18 +++---
 56 files changed, 289 insertions(+), 212 deletions(-)


From shawnguo at kernel.org  Fri Dec 15 22:46:05 2023
From: shawnguo at kernel.org (Shawn Guo)
Date: Sat, 16 Dec 2023 14:46:05 +0800
Subject: [GIT PULL 5/5] i.MX arm64 device tree for 6.8
In-Reply-To: <20231216064605.876196-1-shawnguo@kernel.org>
References: <20231216064605.876196-1-shawnguo@kernel.org>
Message-ID: <20231216064605.876196-5-shawnguo@kernel.org>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt64-6.8

for you to fetch changes up to f43c3a62e7d57e5da8d5f0c50d7254808af15920:

  arm64: dts: freescale: fix the schema check errors for fsl,tmu-calibration (2023-12-16 09:48:35 +0800)

----------------------------------------------------------------
i.MX arm64 device tree for 6.8:

- New board support: MBa93xxCA starter kit, LX2160A based MBLX2160A,
  Dimonoff Gateway EVK, Verdin i.MX8M based Mallow, and SKOV i.MX8MP revB.
- A set of changes from Adam Ford to enable MIPI_DSI, overdrive mode and
  NPU support for Beacon i.MX8M boards.
- A number of changes from Alexander Stein to add CCM interrupts for
  CCM, 'chassis-type' property, and enable VPU and LVDS display for
  TQ-Systems boards.
- i.MX93 update for AUDIO, I3C, ANATOP and uSDHC.
- A couple of changes from David Heidelberg to correct dt-schema check
  errors for 'fsl,tmu-calibration' and 'gpio-fan,speed-map'.
- A bunch of nice dt-schema check fix-ups from Fabio Estevam.
- A couple of debix-som update from Kieran Bingham adding heartbeat LED
  and CSI power regulators.
- White-space cleanup from Krzysztof Kozlowski.
- Add display support for imx8mn-bsh-smm-s2/pro board.
- A series from Tim Harvey to add TPM support for i.MX8M Venice devices.

----------------------------------------------------------------
Adam Ford (10):
      arm64: dts: imx8mp-beacon-kit: Enable DSI to HDMI Bridge
      arm64: dts: imx8mp: Add NPU Node
      arm64: dts: imx8mm: Simplify mipi_dsi clocks
      arm64: dts: imx8mm: Remove video_pll1 clock rate from clk node
      arm64: dts: imx8mm: Slow default video_pll1 clock rate
      arm64: dts: imx8mm: Reduce GPU to nominal speed
      arm64: dts: imx8mm: Add optional overdrive DTSI
      arm64: dts: imx8mm-beacon: Enable overdrive mode
      arm64: dts: imx8mn: Enable Overdrive mode
      arm64: dts: imx8mn-beacon: Support overdrive mode

Alexander Stein (11):
      arm64: dts: freescale: tqma9352-mba93xxla: add 'chassis-type' property
      arm64: dts: freescale: add initial device tree for MBa93xxCA starter kit
      arm64: dts: imx8mp: Add CCM interrupts
      arm64: dts: imx8mn: Add CCM interrupts
      arm64: dts: imx8mm: Add CCM interrupts
      arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxL
      arm64: dts: imx8mp: Disable dsp reserved memory by default
      arm64: dts: tqma8mpql: Remove invalid/unused property
      arm64: dts: imx8m*-tqma8m*: Add chassis-type
      arm64: dts: imx8qxp: Add VPU subsystem file
      arm64: dts: freescale: imx8qxp: Disable dsp reserved memory by default

Andrejs Cainikovs (1):
      arm64: dts: imx8-apalis: add can power-up delay on ixora board

Chancel Liu (2):
      arm64: dts: imx93: Add audio device nodes
      arm64: dts: imx93: Configure clock rate for audio PLL

David Heidelberg (2):
      arm64: dts: imx8mq-phanbell: make dts use gpio-fan matrix instead of array
      arm64: dts: freescale: fix the schema check errors for fsl,tmu-calibration

Fabio Estevam (21):
      arm64: dts: imx8mm-venice-gw7: Fix pci sub-nodes
      arm64: dts: imx8qm-ss-dma: Pass lpuart dma-names
      arm64: dts: imx8mm-emcon-avari: Fix gpio-cells
      arm64: dts: imx8dxl-ss-conn: Fix Ethernet interrupt-names order
      arm64: dts: imx8mm-nitrogen-r2: Fix I2C mux subnode name
      arm64: dts: imx8mp-debix-model-a: Use phy-mode
      arm64: dts: imx8qxp-mek: Fix gpio-sbu-mux compatible
      arm64: dts: imx93: Remove unexistent 'shared-interrupt'
      arm64: dts: imx8-ss-audio: Remove unexistent'shared-interrupt'
      arm64: dts: imx8mm-venice-gw7: Adjust PCI Ethernet nodes
      arm64: dts: ls1012a: Remove big-endian from thermal
      arm64: dts: imx93: Fix the micfil clock-names entries
      arm64: dts: imx8mm-evk: Move port under USB connector
      arm64: dts: imx8mn-evk: Move port under USB connector
      arm64: dts: imx8dxl-ss-conn: Move clk_dummy out of USB node
      arm64: dts: imx8mp-verdin: Fix USB connector description
      arm64: dts: imx8mp-venice: Fix USB connector description
      arm64: dts: imx8mp-tqma8mpql-mba8mpxl: Fix USB connector description
      arm64: dts: imx8mn-var-som-symphony: Describe the USB-C connector
      arm64: dts: imx8mp-dhcom-pdk3: Describe the USB-C connector
      arm64: dts: imx8qxp-mek: Move port under USB connector

Frank Li (1):
      arm64: dts: freescale: imx93: add i3c1 and i3c2

Gregor Herburger (1):
      arm64: dts: freescale: add fsl-lx2160a-mblx2160a board

Haibo Chen (3):
      arm64: dts: imx93-11x11-evk: set SION for cmd and data pad of USDHC
      arm64: dts: imx93: change tuning start to get a large scan range for standard tuning
      arm64: dts: imx93-11x11-evk: add 12 ms delay to make sure the VDD_SD power off

Hugo Villeneuve (4):
      arm64: dts: imx8mn-var-som: add fixed 3.3V regulator for EEPROM
      arm64: dts: freescale: introduce rve-gateway board
      arm64: dts: imx8mn-var-som-symphony: add vcc supply for PCA9534
      arm64: dts: freescale: introduce dimonoff-gateway-evk board

Joao Paulo Goncalves (2):
      arm64: dts: freescale: verdin-imx8mm: add support to mallow board
      arm64: dts: freescale: verdin-imx8mp: add support to mallow board

Kieran Bingham (2):
      arm64: dts: freescale: debix-som: Add heartbeat LED
      arm64: dts: freescale: debix-som-a-bmb-08: Add CSI Power Regulators

Krzysztof Kozlowski (1):
      arm64: dts: freescale: minor whitespace cleanup around '='

Marek Vasut (1):
      arm64: dts: imx8mp: Describe M24C32-D write-lockable page in DH i.MX8MP DHCOM DT

Michael Trimarchi (1):
      arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup

Oleksij Rempel (1):
      arm64: dts: freescale: Add SKOV IMX8MP CPU revB board

Peng Fan (1):
      arm64: dts: imx93: update anatop node

Tim Harvey (3):
      arm64: dts: imx8mm-venice-gw72xx: add TPM device
      arm64: dts: imx8mp-venice-gw72xx: add TPM device
      arm64: dts: imx8mp-venice-gw74xx: remove unecessary propreties in tpm node

Xu Yang (1):
      arm64: dts: imx8dxl-ss-ddr: change ddr_pmu0 compatible

 arch/arm64/boot/dts/freescale/Makefile             |  38 ++
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi     |  80 +--
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi     |  87 +--
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi     |  81 +--
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi     |  74 +--
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi     |  74 +--
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi     |  73 +--
 .../freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 338 ++++++++++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtso   |  29 +
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtso   |  17 +
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso   |  49 ++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso    |  55 ++
 .../fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtso    |  47 ++
 .../boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi |  97 +++
 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi     |   4 +-
 .../boot/dts/freescale/imx8-apalis-ixora-v1.2.dtsi |   2 +
 arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi   |   2 -
 arch/arm64/boot/dts/freescale/imx8dxl-ss-conn.dtsi |  16 +-
 arch/arm64/boot/dts/freescale/imx8dxl-ss-ddr.dtsi  |   2 +-
 .../boot/dts/freescale/imx8mm-beacon-som.dtsi      |   2 +
 .../boot/dts/freescale/imx8mm-emcon-avari.dtsi     |   2 +-
 arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi      |  12 +-
 .../boot/dts/freescale/imx8mm-nitrogen-r2.dts      |   2 +-
 .../arm64/boot/dts/freescale/imx8mm-overdrive.dtsi |  29 +
 .../boot/dts/freescale/imx8mm-tqma8mqml-mba8mx.dts |   1 +
 .../boot/dts/freescale/imx8mm-venice-gw72xx.dtsi   |  39 +-
 .../boot/dts/freescale/imx8mm-venice-gw73xx.dtsi   |  29 +-
 .../boot/dts/freescale/imx8mm-venice-gw7902.dts    |  13 +-
 .../boot/dts/freescale/imx8mm-verdin-mallow.dtsi   | 173 +++++
 .../dts/freescale/imx8mm-verdin-nonwifi-mallow.dts |  18 +
 .../dts/freescale/imx8mm-verdin-wifi-mallow.dts    |  18 +
 arch/arm64/boot/dts/freescale/imx8mm.dtsi          |  18 +-
 .../boot/dts/freescale/imx8mn-beacon-som.dtsi      |   2 +
 .../dts/freescale/imx8mn-bsh-smm-s2-common.dtsi    |   1 +
 .../dts/freescale/imx8mn-bsh-smm-s2-display.dtsi   | 121 ++++
 .../dts/freescale/imx8mn-dimonoff-gateway-evk.dts  | 160 +++++
 arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi      |  12 +-
 .../arm64/boot/dts/freescale/imx8mn-overdrive.dtsi |  18 +
 .../boot/dts/freescale/imx8mn-rve-gateway.dts      | 285 +++++++++
 .../boot/dts/freescale/imx8mn-tqma8mqnl-mba8mx.dts |   1 +
 .../boot/dts/freescale/imx8mn-var-som-symphony.dts |  21 +-
 arch/arm64/boot/dts/freescale/imx8mn-var-som.dtsi  |   9 +
 arch/arm64/boot/dts/freescale/imx8mn.dtsi          |   2 +
 .../arm64/boot/dts/freescale/imx8mp-beacon-kit.dts |  92 +++
 .../boot/dts/freescale/imx8mp-debix-model-a.dts    |   2 +-
 .../dts/freescale/imx8mp-debix-som-a-bmb-08.dts    |  56 ++
 .../boot/dts/freescale/imx8mp-debix-som-a.dtsi     |  22 +
 .../arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts |  12 +-
 .../arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi |  12 +
 .../boot/dts/freescale/imx8mp-msc-sm2s-ep1.dts     |   4 +-
 .../arm64/boot/dts/freescale/imx8mp-skov-reva.dtsi | 711 +++++++++++++++++++++
 .../boot/dts/freescale/imx8mp-skov-revb-hdmi.dts   |  20 +
 .../boot/dts/freescale/imx8mp-skov-revb-lt6.dts    | 101 +++
 .../freescale/imx8mp-skov-revb-mi1010ait-1cp1.dts  | 100 +++
 .../imx8mp-tqma8mpql-mba8mpxl-lvds-g133han01.dtso  |  77 +++
 .../dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts    |  28 +-
 .../boot/dts/freescale/imx8mp-venice-gw71xx.dtsi   |  26 +-
 .../boot/dts/freescale/imx8mp-venice-gw72xx.dtsi   |  36 +-
 .../boot/dts/freescale/imx8mp-venice-gw73xx.dtsi   |  26 +-
 .../boot/dts/freescale/imx8mp-venice-gw74xx.dts    |  28 +-
 .../boot/dts/freescale/imx8mp-verdin-mallow.dtsi   | 199 ++++++
 .../dts/freescale/imx8mp-verdin-nonwifi-mallow.dts |  18 +
 .../dts/freescale/imx8mp-verdin-wifi-mallow.dts    |  18 +
 arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi   |  30 +-
 arch/arm64/boot/dts/freescale/imx8mp.dtsi          |  28 +-
 arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts  |   2 +-
 .../boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts   |   1 +
 arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi   |   4 +
 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts      |  21 +-
 arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi  |  17 +
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi         |   3 +-
 arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts  |  31 +-
 .../dts/freescale/imx93-tqma9352-mba93xxca.dts     | 709 ++++++++++++++++++++
 .../dts/freescale/imx93-tqma9352-mba93xxla.dts     |   1 +
 arch/arm64/boot/dts/freescale/imx93.dtsi           | 127 +++-
 75 files changed, 4326 insertions(+), 389 deletions(-)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_14_x_x.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_8_x.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-overdrive.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-dimonoff-gateway-evk.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-overdrive.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-rve-gateway.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-skov-reva.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-skov-revb-hdmi.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-skov-revb-lt6.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-skov-revb-mi1010ait-1cp1.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl-lvds-g133han01.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ss-vpu.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-tqma9352-mba93xxca.dts


From sebastian.fricke at collabora.com  Fri Dec 15 22:47:03 2023
From: sebastian.fricke at collabora.com (Sebastian Fricke)
Date: Sat, 16 Dec 2023 07:47:03 +0100
Subject: [PATCH v8 00/12] add support MDP3 on MT8195 platform
In-Reply-To: <20231030100626.12564-1-moudy.ho@mediatek.com>
References: <20231030100626.12564-1-moudy.ho@mediatek.com>
Message-ID: <20231216064703.tb7vf3m2ohrbz6px@basti-XPS-13-9310>

Hey Moudy Ho,

just as a quick note, as this series is based on linux-next, we will
wait for the patches, that this series is depending on, to be merged into
the media_stage repository (https://git.linuxtv.org/media_stage.git/),
before we merge this series into the media subsystem.

Greetings,
Sebastian

On 30.10.2023 18:06, Moudy Ho wrote:
>Changes since v7:
>- Rebase on linux-next.
>- Dependent dtsi files:
>  https://patchwork.kernel.org/project/linux-mediatek/list/?series=797543
>- Dependent bindings:
>  https://patchwork.kernel.org/project/linux-mediatek/list/?series=797555
>- Patch [9/12] has made corresponding adjustments in response to the changes in
>  the compatible name of the PAD component in DTSI and binding.
>- Adding WROT compatible name in the MDP driver's of_match_table in [9/12] to
>  avoid deactivating 'pm_runtime_*' functions.
>
>Changes since v6:
>- Rebase on v6.6-rc5.
>- Dependent dtsi files:
>  https://patchwork.kernel.org/project/linux-mediatek/list/?series=792079
>- Dependent bindings:
>  https://patchwork.kernel.org/project/linux-mediatek/list/?series=792477
>- Move the patch that fixes compile warnings from this series and
>  create a separate standalone patch.
>
>Changes since v5:
>- Rebase on v6.6-rc2.
>- Dependent dtsi files:
>  https://patchwork.kernel.org/project/linux-mediatek/list/?series=786511
>- Dependent bindings:
>  https://patchwork.kernel.org/project/linux-mediatek/list/?series=786520
>- Integrate MMSY/MUTEX structure in "mdp_probe".
>- Fix the build warnings that were detected by the linux-media
>  build scripts tool.
>
>Changes since v4:
>- Rebase on v6.6-rc1
>- Remove any unnecessary DTS settings.
>- Adjust the usage of MOD and clock in blending components.
>
>Changes since v3:
>- Depend on :
>  [1] https://patchwork.kernel.org/project/linux-media/list/?series=719841
>- Suggested by Krzysztof, integrating all newly added bindings for
>  the mt8195 MDP3 into the file "mediatek,mt8195-mdp3.yaml".
>- Revise MDP3 nodes with generic names.
>
>Changes since v2:
>- Depend on :
>  [1] MMSYS/MUTEX: https://patchwork.kernel.org/project/linux-mediatek/list/?series=711592
>  [2] MDP3: https://patchwork.kernel.org/project/linux-mediatek/list/?series=711618
>- Suggested by Rob to revise MDP3 bindings to pass dtbs check
>- Add parallel paths feature.
>- Add blended components settings.
>
>Changes since v1:
>- Depend on :
>  [1] MDP3 : https://patchwork.kernel.org/project/linux-mediatek/list/?series=698872
>  [2] MMSYS/MUTEX: https://patchwork.kernel.org/project/linux-mediatek/list/?series=684959
>- Fix compilation failure due to use of undeclared identifier in file "mtk-mdp3-cmdq.c"
>
>Hello,
>
>This patch is used to add support for MDP3 on the MT8195 platform that
>contains more picture quality components, and can arrange more pipelines
>through two sets of MMSYS and MUTEX respectively.
>
>Moudy Ho (12):
>  media: platform: mtk-mdp3: add support second sets of MMSYS
>  media: platform: mtk-mdp3: add support second sets of MUTEX
>  media: platform: mtk-mdp3: introduce more pipelines from MT8195
>  media: platform: mtk-mdp3: introduce more MDP3 components
>  media: platform: mtk-mdp3: add checks for dummy components
>  media: platform: mtk-mdp3: avoid multiple driver registrations
>  media: platform: mtk-mdp3: extend GCE event waiting in RDMA and WROT
>  media: platform: mtk-mdp3: add support for blending multiple
>    components
>  media: platform: mtk-mdp3: add mt8195 platform configuration
>  media: platform: mtk-mdp3: add mt8195 shared memory configurations
>  media: platform: mtk-mdp3: add mt8195 MDP3 component settings
>  media: platform: mtk-mdp3: add support for parallel pipe to improve
>    FPS
>
> .../platform/mediatek/mdp3/mdp_cfg_data.c     | 729 +++++++++++++-
> .../platform/mediatek/mdp3/mdp_reg_aal.h      |  25 +
> .../platform/mediatek/mdp3/mdp_reg_color.h    |  31 +
> .../media/platform/mediatek/mdp3/mdp_reg_fg.h |  23 +
> .../platform/mediatek/mdp3/mdp_reg_hdr.h      |  31 +
> .../platform/mediatek/mdp3/mdp_reg_merge.h    |  25 +
> .../platform/mediatek/mdp3/mdp_reg_ovl.h      |  25 +
> .../platform/mediatek/mdp3/mdp_reg_pad.h      |  21 +
> .../platform/mediatek/mdp3/mdp_reg_rdma.h     |  24 +
> .../platform/mediatek/mdp3/mdp_reg_rsz.h      |   2 +
> .../platform/mediatek/mdp3/mdp_reg_tdshp.h    |  34 +
> .../platform/mediatek/mdp3/mdp_reg_wrot.h     |   8 +
> .../platform/mediatek/mdp3/mdp_sm_mt8195.h    | 283 ++++++
> .../platform/mediatek/mdp3/mtk-img-ipi.h      |   4 +
> .../platform/mediatek/mdp3/mtk-mdp3-cfg.h     |   2 +
> .../platform/mediatek/mdp3/mtk-mdp3-cmdq.c    | 440 +++++++--
> .../platform/mediatek/mdp3/mtk-mdp3-cmdq.h    |   1 +
> .../platform/mediatek/mdp3/mtk-mdp3-comp.c    | 895 +++++++++++++++++-
> .../platform/mediatek/mdp3/mtk-mdp3-comp.h    |  93 +-
> .../platform/mediatek/mdp3/mtk-mdp3-core.c    | 139 ++-
> .../platform/mediatek/mdp3/mtk-mdp3-core.h    |  50 +-
> .../platform/mediatek/mdp3/mtk-mdp3-m2m.c     |  15 +
> .../platform/mediatek/mdp3/mtk-mdp3-regs.c    |  18 +
> .../platform/mediatek/mdp3/mtk-mdp3-regs.h    |   1 +
> .../platform/mediatek/mdp3/mtk-mdp3-vpu.c     |   3 +-
> 25 files changed, 2744 insertions(+), 178 deletions(-)
> create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h
> create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_color.h
> create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h
> create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_hdr.h
> create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_merge.h
> create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_ovl.h
> create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_pad.h
> create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_tdshp.h
> create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h
>
>-- 
>2.18.0
>


From lkp at intel.com  Sat Dec 16 03:48:12 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 16 Dec 2023 19:48:12 +0800
Subject: [PATCH net-next v4 05/13] net: ethtool: Allow passing a phy
 index for some commands
In-Reply-To: <20231215171237.1152563-6-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-6-maxime.chevallier@bootlin.com>
Message-ID: <202312161945.RaGyJll9-lkp@intel.com>

Hi Maxime,

kernel test robot noticed the following build errors:

[auto build test ERROR on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Maxime-Chevallier/net-phy-Introduce-ethernet-link-topology-representation/20231216-012641
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231215171237.1152563-6-maxime.chevallier%40bootlin.com
patch subject: [PATCH net-next v4 05/13] net: ethtool: Allow passing a phy index for some commands
config: nios2-randconfig-001-20231216 (https://download.01.org/0day-ci/archive/20231216/202312161945.RaGyJll9-lkp at intel.com/config)
compiler: nios2-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231216/202312161945.RaGyJll9-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312161945.RaGyJll9-lkp at intel.com/

All errors (new ones prefixed by >>):

   nios2-linux-ld: net/ethtool/netlink.o: in function `ethnl_parse_header_dev_get':
   netlink.c:(.text+0x2e8): undefined reference to `phy_link_topo_get_phy'
>> netlink.c:(.text+0x2e8): relocation truncated to fit: R_NIOS2_CALL26 against `phy_link_topo_get_phy'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From conor at kernel.org  Sat Dec 16 04:37:59 2023
From: conor at kernel.org (Conor Dooley)
Date: Sat, 16 Dec 2023 12:37:59 +0000
Subject: [PATCH V6 1/3] dt-bindings: Add reference to rs485.yaml
In-Reply-To: <20231215125627.1691573-2-manikanta.guntupalli@amd.com>
References: <20231215125627.1691573-1-manikanta.guntupalli@amd.com>
 <20231215125627.1691573-2-manikanta.guntupalli@amd.com>
Message-ID: <20231216-unbalance-ferry-50fa828a4d48@spud>

On Fri, Dec 15, 2023 at 06:26:25PM +0530, Manikanta Guntupalli wrote:
> Add rs485 support to uartps driver and Xilinx/AMD Kria SOM KD240
> board have rs485 support.

Please remove mention of drivers from commit messages for bindings.
Otherwise,
Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> 
> Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
> ---
> Changes for V2:
> Modify optional gpio name to xlnx,phy-ctrl-gpios.
> Update commit description.
> 
> Changes for V3:
> Modify optional gpio name to rts-gpios.
> Update commit description.
> 
> Changes for V4:
> Update rts-gpios description.
> 
> Changes for V5:
> Remove rts-gpios description.
> Update commit message and description.
> 
> Changes for V6:
> Update commit description.
> ---
>  Documentation/devicetree/bindings/serial/cdns,uart.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
> index e35ad1109efc..2129247d7c81 100644
> --- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
> @@ -55,6 +55,7 @@ required:
>  
>  allOf:
>    - $ref: serial.yaml#
> +  - $ref: rs485.yaml#
>    - if:
>        properties:
>          compatible:
> -- 
> 2.25.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231216/f819d343/attachment.sig>

From mark.rutland at arm.com  Sat Dec 16 04:44:33 2023
From: mark.rutland at arm.com (Mark Rutland)
Date: Sat, 16 Dec 2023 12:44:33 +0000
Subject: [PATCH v2 1/1] arm: perf: Fix ARCH=arm build with GCC
In-Reply-To: <20231215175648.3397170-2-james.clark@arm.com>
References: <20231215175648.3397170-1-james.clark@arm.com>
 <20231215175648.3397170-2-james.clark@arm.com>
Message-ID: <ZX2bsYEdWVxTCiTi@FVFF77S0Q05N>

On Fri, Dec 15, 2023 at 05:56:48PM +0000, James Clark wrote:
> LLVM ignores everything inside the if statement and doesn't generate
> errors, but GCC doesn't ignore it, resulting in the following error:
> 
>   drivers/perf/arm_pmuv3.c: In function 'armv8pmu_write_evtype':
>   include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
>   34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \
> 
> Fix it by using GENMASK_ULL which doesn't overflow on arm32 (even though
> the value is never used there).

It would be nice if this could explain the overflow problem, i.e.

| The GENMASK() macro creates masks of type unsigned long, and we use this to
| geenrate the ARMV8_PMU_EVTYPE_TH and ARMV8_PMU_EVTYPE_TC constants. These
| include bits above bit 31, and generating these requires shifting more than the
| size of unsigned long on 32-bit ARM.
| 
| Consequently when building for 32-bit arm, GCC warns about their use:
| 
|   drivers/perf/arm_pmuv3.c: In function 'armv8pmu_write_evtype':
|   include/linux/bits.h:34:29: error: left shift count >= width of type [-Werror=shift-count-overflow]
|   34 |         (((~UL(0)) - (UL(1) << (l)) + 1) & \
| 
| ... though LLVM does not warn as the actual usage is not reachable on 32-bit
| ARM due to `if (IS_ENABLED(...)` checks.
| 
| Avoid the warning by using GENMACK_ULL(), which doesn't overflow on 32-bit arm.

> Fixes: 3115ee021bfb ("arm64: perf: Include threshold control fields in PMEVTYPER mask")
> Reported-by: Uwe Kleine-K"onig <u.kleine-koenig at pengutronix.de>
> Closes: https://lore.kernel.org/linux-arm-kernel/20231215120817.h2f3akgv72zhrtqo at pengutronix.de/
> Signed-off-by: James Clark <james.clark at arm.com>

Thanks for this!

Acked-by: Mark Rutland <mark.rutland at arm.com>

Will, Catalin, the broken commit is queued in the arm64 for-next/perf branch
(and merged into for-next/core); is this something we can easily fold in?

Mark.

> ---
>  include/linux/perf/arm_pmuv3.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/perf/arm_pmuv3.h b/include/linux/perf/arm_pmuv3.h
> index 0f4d62ef3a9a..46377e134d67 100644
> --- a/include/linux/perf/arm_pmuv3.h
> +++ b/include/linux/perf/arm_pmuv3.h
> @@ -234,8 +234,8 @@
>   * PMXEVTYPER: Event selection reg
>   */
>  #define ARMV8_PMU_EVTYPE_EVENT	GENMASK(15, 0)	/* Mask for EVENT bits */
> -#define ARMV8_PMU_EVTYPE_TH	GENMASK(43, 32)
> -#define ARMV8_PMU_EVTYPE_TC	GENMASK(63, 61)
> +#define ARMV8_PMU_EVTYPE_TH	GENMASK_ULL(43, 32) /* arm64 only */
> +#define ARMV8_PMU_EVTYPE_TC	GENMASK_ULL(63, 61) /* arm64 only */
>  
>  /*
>   * Event filters for PMUv3
> -- 
> 2.34.1
> 


From jernej.skrabec at gmail.com  Sat Dec 16 05:09:25 2023
From: jernej.skrabec at gmail.com (Jernej Skrabec)
Date: Sat, 16 Dec 2023 14:09:25 +0100
Subject: [PATCH] media: cedrus: h265: Fix configuring bitstream size
Message-ID: <20231216130925.2533395-1-jernej.skrabec@gmail.com>

bit_size field holds size of slice, not slice + header. Because of HW
quirks, driver can't program in just slice, but also preceding header.
But that means that currently used bit_size is wrong (too small).
Instead, just use size of whole buffer. There is no harm in doing this.

Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support")
Suggested-by: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec at gmail.com>
---
 drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
index fc9297232456..16c822637dc6 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
@@ -427,11 +427,11 @@ static int cedrus_h265_setup(struct cedrus_ctx *ctx, struct cedrus_run *run)
 	unsigned int ctb_addr_x, ctb_addr_y;
 	struct cedrus_buffer *cedrus_buf;
 	dma_addr_t src_buf_addr;
-	dma_addr_t src_buf_end_addr;
 	u32 chroma_log2_weight_denom;
 	u32 num_entry_point_offsets;
 	u32 output_pic_list_index;
 	u32 pic_order_cnt[2];
+	size_t slice_bytes;
 	u8 padding;
 	int count;
 	u32 reg;
@@ -443,6 +443,7 @@ static int cedrus_h265_setup(struct cedrus_ctx *ctx, struct cedrus_run *run)
 	pred_weight_table = &slice_params->pred_weight_table;
 	num_entry_point_offsets = slice_params->num_entry_point_offsets;
 	cedrus_buf = vb2_to_cedrus_buffer(&run->dst->vb2_buf);
+	slice_bytes = vb2_get_plane_payload(&run->src->vb2_buf, 0);
 
 	/*
 	 * If entry points offsets are present, we should get them
@@ -490,7 +491,7 @@ static int cedrus_h265_setup(struct cedrus_ctx *ctx, struct cedrus_run *run)
 
 	cedrus_write(dev, VE_DEC_H265_BITS_OFFSET, 0);
 
-	reg = slice_params->bit_size;
+	reg = slice_bytes * 8;
 	cedrus_write(dev, VE_DEC_H265_BITS_LEN, reg);
 
 	/* Source beginning and end addresses. */
@@ -504,10 +505,7 @@ static int cedrus_h265_setup(struct cedrus_ctx *ctx, struct cedrus_run *run)
 
 	cedrus_write(dev, VE_DEC_H265_BITS_ADDR, reg);
 
-	src_buf_end_addr = src_buf_addr +
-			   DIV_ROUND_UP(slice_params->bit_size, 8);
-
-	reg = VE_DEC_H265_BITS_END_ADDR_BASE(src_buf_end_addr);
+	reg = VE_DEC_H265_BITS_END_ADDR_BASE(src_buf_addr + slice_bytes);
 	cedrus_write(dev, VE_DEC_H265_BITS_END_ADDR, reg);
 
 	/* Coding tree block address */
-- 
2.43.0



From jernej.skrabec at gmail.com  Sat Dec 16 05:34:19 2023
From: jernej.skrabec at gmail.com (Jernej Skrabec)
Date: Sat, 16 Dec 2023 14:34:19 +0100
Subject: [PATCH 0/3] media: sun8i-di: several fixes
Message-ID: <20231216133422.2534674-1-jernej.skrabec@gmail.com>

This series fixes 3 issues, which were discovered during examination of
occasionally non-working deinterlacing on A64 SoC.

Please take a look.

Best regards,
Jernej

Jernej Skrabec (3):
  media: sun8i-di: Fix coefficient writes
  media: sun8i-di: Fix power on/off sequences
  media: sun8i-di: Fix chroma difference threshold

 .../media/platform/sunxi/sun8i-di/sun8i-di.c  | 69 ++++++++++---------
 1 file changed, 35 insertions(+), 34 deletions(-)

-- 
2.43.0



From jernej.skrabec at gmail.com  Sat Dec 16 05:34:20 2023
From: jernej.skrabec at gmail.com (Jernej Skrabec)
Date: Sat, 16 Dec 2023 14:34:20 +0100
Subject: [PATCH 1/3] media: sun8i-di: Fix coefficient writes
In-Reply-To: <20231216133422.2534674-1-jernej.skrabec@gmail.com>
References: <20231216133422.2534674-1-jernej.skrabec@gmail.com>
Message-ID: <20231216133422.2534674-2-jernej.skrabec@gmail.com>

Currently coefficients are applied only once, since they don't change.
However, this is done before enable bit is set and thus it doesn't get
applied properly.

Fix that by applying coefficients after enable bit is set. While this
means that it will be done evey time, it doesn't bring much time
penalty.

Fixes: a4260ea49547 ("media: sun4i: Add H3 deinterlace driver")
Signed-off-by: Jernej Skrabec <jernej.skrabec at gmail.com>
---
 .../media/platform/sunxi/sun8i-di/sun8i-di.c  | 42 +++++++++----------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
index 90ab1d77b6a5..34e099939284 100644
--- a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
+++ b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
@@ -66,6 +66,7 @@ static void deinterlace_device_run(void *priv)
 	struct vb2_v4l2_buffer *src, *dst;
 	unsigned int hstep, vstep;
 	dma_addr_t addr;
+	int i;
 
 	src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
 	dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -160,6 +161,26 @@ static void deinterlace_device_run(void *priv)
 	deinterlace_write(dev, DEINTERLACE_CH1_HORZ_FACT, hstep);
 	deinterlace_write(dev, DEINTERLACE_CH1_VERT_FACT, vstep);
 
+	/* neutral filter coefficients */
+	deinterlace_set_bits(dev, DEINTERLACE_FRM_CTRL,
+			     DEINTERLACE_FRM_CTRL_COEF_ACCESS);
+	readl_poll_timeout(dev->base + DEINTERLACE_STATUS, val,
+			   val & DEINTERLACE_STATUS_COEF_STATUS, 2, 40);
+
+	for (i = 0; i < 32; i++) {
+		deinterlace_write(dev, DEINTERLACE_CH0_HORZ_COEF0 + i * 4,
+				  DEINTERLACE_IDENTITY_COEF);
+		deinterlace_write(dev, DEINTERLACE_CH0_VERT_COEF + i * 4,
+				  DEINTERLACE_IDENTITY_COEF);
+		deinterlace_write(dev, DEINTERLACE_CH1_HORZ_COEF0 + i * 4,
+				  DEINTERLACE_IDENTITY_COEF);
+		deinterlace_write(dev, DEINTERLACE_CH1_VERT_COEF + i * 4,
+				  DEINTERLACE_IDENTITY_COEF);
+	}
+
+	deinterlace_clr_set_bits(dev, DEINTERLACE_FRM_CTRL,
+				 DEINTERLACE_FRM_CTRL_COEF_ACCESS, 0);
+
 	deinterlace_clr_set_bits(dev, DEINTERLACE_FIELD_CTRL,
 				 DEINTERLACE_FIELD_CTRL_FIELD_CNT_MSK,
 				 DEINTERLACE_FIELD_CTRL_FIELD_CNT(ctx->field));
@@ -248,7 +269,6 @@ static irqreturn_t deinterlace_irq(int irq, void *data)
 static void deinterlace_init(struct deinterlace_dev *dev)
 {
 	u32 val;
-	int i;
 
 	deinterlace_write(dev, DEINTERLACE_BYPASS,
 			  DEINTERLACE_BYPASS_CSC);
@@ -285,26 +305,6 @@ static void deinterlace_init(struct deinterlace_dev *dev)
 	deinterlace_clr_set_bits(dev, DEINTERLACE_CHROMA_DIFF,
 				 DEINTERLACE_CHROMA_DIFF_TH_MSK,
 				 DEINTERLACE_CHROMA_DIFF_TH(5));
-
-	/* neutral filter coefficients */
-	deinterlace_set_bits(dev, DEINTERLACE_FRM_CTRL,
-			     DEINTERLACE_FRM_CTRL_COEF_ACCESS);
-	readl_poll_timeout(dev->base + DEINTERLACE_STATUS, val,
-			   val & DEINTERLACE_STATUS_COEF_STATUS, 2, 40);
-
-	for (i = 0; i < 32; i++) {
-		deinterlace_write(dev, DEINTERLACE_CH0_HORZ_COEF0 + i * 4,
-				  DEINTERLACE_IDENTITY_COEF);
-		deinterlace_write(dev, DEINTERLACE_CH0_VERT_COEF + i * 4,
-				  DEINTERLACE_IDENTITY_COEF);
-		deinterlace_write(dev, DEINTERLACE_CH1_HORZ_COEF0 + i * 4,
-				  DEINTERLACE_IDENTITY_COEF);
-		deinterlace_write(dev, DEINTERLACE_CH1_VERT_COEF + i * 4,
-				  DEINTERLACE_IDENTITY_COEF);
-	}
-
-	deinterlace_clr_set_bits(dev, DEINTERLACE_FRM_CTRL,
-				 DEINTERLACE_FRM_CTRL_COEF_ACCESS, 0);
 }
 
 static inline struct deinterlace_ctx *deinterlace_file2ctx(struct file *file)
-- 
2.43.0



From jernej.skrabec at gmail.com  Sat Dec 16 05:34:21 2023
From: jernej.skrabec at gmail.com (Jernej Skrabec)
Date: Sat, 16 Dec 2023 14:34:21 +0100
Subject: [PATCH 2/3] media: sun8i-di: Fix power on/off sequences
In-Reply-To: <20231216133422.2534674-1-jernej.skrabec@gmail.com>
References: <20231216133422.2534674-1-jernej.skrabec@gmail.com>
Message-ID: <20231216133422.2534674-3-jernej.skrabec@gmail.com>

According to user manual, reset line should be deasserted before clocks
are enabled. Also fix power down sequence to be reverse of that.

Fixes: a4260ea49547 ("media: sun4i: Add H3 deinterlace driver")
Signed-off-by: Jernej Skrabec <jernej.skrabec at gmail.com>
---
 .../media/platform/sunxi/sun8i-di/sun8i-di.c  | 25 ++++++++++---------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
index 34e099939284..f253a40cc04f 100644
--- a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
+++ b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
@@ -929,11 +929,18 @@ static int deinterlace_runtime_resume(struct device *device)
 		return ret;
 	}
 
+	ret = reset_control_deassert(dev->rstc);
+	if (ret) {
+		dev_err(dev->dev, "Failed to apply reset\n");
+
+		goto err_exclusive_rate;
+	}
+
 	ret = clk_prepare_enable(dev->bus_clk);
 	if (ret) {
 		dev_err(dev->dev, "Failed to enable bus clock\n");
 
-		goto err_exclusive_rate;
+		goto err_rst;
 	}
 
 	ret = clk_prepare_enable(dev->mod_clk);
@@ -950,23 +957,16 @@ static int deinterlace_runtime_resume(struct device *device)
 		goto err_mod_clk;
 	}
 
-	ret = reset_control_deassert(dev->rstc);
-	if (ret) {
-		dev_err(dev->dev, "Failed to apply reset\n");
-
-		goto err_ram_clk;
-	}
-
 	deinterlace_init(dev);
 
 	return 0;
 
-err_ram_clk:
-	clk_disable_unprepare(dev->ram_clk);
 err_mod_clk:
 	clk_disable_unprepare(dev->mod_clk);
 err_bus_clk:
 	clk_disable_unprepare(dev->bus_clk);
+err_rst:
+	reset_control_assert(dev->rstc);
 err_exclusive_rate:
 	clk_rate_exclusive_put(dev->mod_clk);
 
@@ -977,11 +977,12 @@ static int deinterlace_runtime_suspend(struct device *device)
 {
 	struct deinterlace_dev *dev = dev_get_drvdata(device);
 
-	reset_control_assert(dev->rstc);
-
 	clk_disable_unprepare(dev->ram_clk);
 	clk_disable_unprepare(dev->mod_clk);
 	clk_disable_unprepare(dev->bus_clk);
+
+	reset_control_assert(dev->rstc);
+
 	clk_rate_exclusive_put(dev->mod_clk);
 
 	return 0;
-- 
2.43.0



From jernej.skrabec at gmail.com  Sat Dec 16 05:34:22 2023
From: jernej.skrabec at gmail.com (Jernej Skrabec)
Date: Sat, 16 Dec 2023 14:34:22 +0100
Subject: [PATCH 3/3] media: sun8i-di: Fix chroma difference threshold
In-Reply-To: <20231216133422.2534674-1-jernej.skrabec@gmail.com>
References: <20231216133422.2534674-1-jernej.skrabec@gmail.com>
Message-ID: <20231216133422.2534674-4-jernej.skrabec@gmail.com>

While there is no good explanation what this value does, vendor driver
uses value 31 for it. Align driver with it.

Fixes: a4260ea49547 ("media: sun4i: Add H3 deinterlace driver")
Signed-off-by: Jernej Skrabec <jernej.skrabec at gmail.com>
---
 drivers/media/platform/sunxi/sun8i-di/sun8i-di.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
index f253a40cc04f..f7ff0937828c 100644
--- a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
+++ b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
@@ -304,7 +304,7 @@ static void deinterlace_init(struct deinterlace_dev *dev)
 
 	deinterlace_clr_set_bits(dev, DEINTERLACE_CHROMA_DIFF,
 				 DEINTERLACE_CHROMA_DIFF_TH_MSK,
-				 DEINTERLACE_CHROMA_DIFF_TH(5));
+				 DEINTERLACE_CHROMA_DIFF_TH(31));
 }
 
 static inline struct deinterlace_ctx *deinterlace_file2ctx(struct file *file)
-- 
2.43.0



From monstr at monstr.eu  Sat Dec 16 06:10:31 2023
From: monstr at monstr.eu (Michal Simek)
Date: Sat, 16 Dec 2023 15:10:31 +0100
Subject: [GIT PULL RESEND] arm64: soc: ZynqMP SoC changes for v6.8
Message-ID: <CAHTX3dJp_dztRCOn+-_OCeb-L6He7Pi2t-K0QeTDACaMs-xfTA@mail.gmail.com>

Hi,

please pull these patches to your tree. I am sending it again because
I see origin email in lore here
https://lore.kernel.org/soc/a41bcab2-1d28-42fd-b5ff-1d6fb5226cf1 at monstr.eu/T/#u
but I can't see it in patchwork.

Thanks,
Michal


 The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

   Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

 are available in the Git repository at:

   https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-soc-for-6.8

 for you to fetch changes up to 87fda1acfc3b9048261799817ef749e6deb95724:

   soc: xilinx: Add error message for invalid payload received from
IPI callback. (2023-12-13 16:55:15 +0100)

 ----------------------------------------------------------------
 arm64: ZynqMP SoC changes for 6.8

 power driver:
 - Move to remove_new hook
 - Report error around unsupported callback
 - Fix long messages

 event driver:
 - Fix cpu_id handling
 - Fix warning message

 ----------------------------------------------------------------
 HariBabu Gattem (1):
       soc: xilinx: Fix for call trace due to the usage of smp_processor_id()

 Michal Simek (1):
       soc: xilinx: fix quoted string split across lines

 Naman Trivedi Manojbhai (1):
       soc: xilinx: Add error message for invalid payload received
from IPI callback.

 Tanmay Shah (1):
       soc: xilinx: fix unhandled SGI warning message

 Uwe Kleine-K?nig (1):
       soc/xilinx: zynqmp_power: Convert to platform remove callback
returning void

  drivers/soc/xilinx/xlnx_event_manager.c |  7 +++++--
  drivers/soc/xilinx/zynqmp_power.c       | 16 ++++++++--------
  2 files changed, 13 insertions(+), 10 deletions(-)

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs


From dmitry.baryshkov at linaro.org  Sat Dec 16 08:15:31 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sat, 16 Dec 2023 18:15:31 +0200
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
Message-ID: <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>

On 16/12/2023 02:03, Konrad Dybcio wrote:
> On 15.12.2023 13:54, Robin Murphy wrote:
>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>>
>>>
>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>>> <quic_bibekkum at quicinc.com> wrote:
>>>>>
>>>>> Add ACTLR data table for SM8550 along with support for
>>>>> same including SM8550 specific implementation operations.
>>>>>
>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>>> ---
>>>>>  ? drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 ++++++++++++++++++++++
>>>>>  ? 1 file changed, 89 insertions(+)
>>>>>
>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>> index cb49291f5233..d2006f610243 100644
>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>>>  ???????? u32 actlr;
>>>>>  ? };
>>>>>
>>>>> +/*
>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the prefetch
>>>>> + * buffer). The remaining bits are implementation defined and vary across
>>>>> + * SoCs.
>>>>> + */
>>>>> +
>>>>> +#define PREFETCH_DEFAULT?????? 0
>>>>> +#define PREFETCH_SHALLOW?????? BIT(8)
>>>>> +#define PREFETCH_MODERATE????? BIT(9)
>>>>> +#define PREFETCH_DEEP????????? (BIT(9) | BIT(8))
>>>>
>>>> I thin the following might be more correct:
>>>>
>>>> #include <linux/bitfield.h>
>>>>
>>>> #define PREFETCH_MASK GENMASK(9, 8)
>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>>
>>>
>>> Ack, thanks for this suggestion. Let me try this out using
>>> GENMASK. Once tested, will take care of this in next version.
>>
>> FWIW the more typical usage would be to just define the named macros for the raw field values, then put the FIELD_PREP() at the point of use. However in this case that's liable to get pretty verbose, so although I'm usually a fan of bitfield.h, the most readable option here might actually be to stick with simpler definitions of "(0 << 8)", "(1 << 8)", etc. However it's not really a big deal either way, and I defer to whatever Dmitry and Konrad prefer, since they're the ones looking after arm-smmu-qcom the most :)
> My 5 cents would be to just use the "common" style of doing this, so:
> 
> #define ACTRL_PREFETCH	GENMASK(9, 8)
>   #define PREFETCH_DEFAULT 0
>   #define PREFETCH_SHALLOW 1
>   #define PREFETCH_MODERATE 2
>   #define PREFETCH_DEEP 3
> 
> and then use
> 
> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
> 
> it can get verbose, but.. arguably that's good, since you really want
> to make sure the right bits are set here

Sounds good to me.


-- 
With best wishes
Dmitry



From dmitry.baryshkov at linaro.org  Sat Dec 16 08:16:45 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sat, 16 Dec 2023 18:16:45 +0200
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <e4329952-34ac-4458-a63c-1f64e288614c@linaro.org>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <e4329952-34ac-4458-a63c-1f64e288614c@linaro.org>
Message-ID: <4fba10fa-2f46-4d64-aba3-67afe2ddd680@linaro.org>

On 16/12/2023 01:35, Konrad Dybcio wrote:
> On 15.12.2023 11:18, Bibek Kumar Patro wrote:
>> Add ACTLR data table for SM8550 along with support for
>> same including SM8550 specific implementation operations.
>>
>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>> ---
> [...]
> 
>> +static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
>> +	.impl = &qcom_smmu_500_impl,
>> +	.adreno_impl = &qcom_adreno_smmu_500_impl,
>> +	.cfg = &qcom_smmu_impl0_cfg,
>> +	.actlrcfg = sm8550_apps_actlr_cfg,
>> +	.actlrcfg_gfx = sm8550_gfx_actlr_cfg,
> There are platforms that feature more than just APPS and Adreno SMMUs,
> this implementation seems to assume there's only these two :/
> 
> I suppose the only way to solve this would be to introduce new compatibles
> for each one of them.. Krzysztof, do you think that's reasonable? E.g.
> MSM8996 has at least 5 instances, 8998 has at least 4 etc.

Ugh. I don't think compatibles will make sense here. I think we have to 
resolve to the hated solution of putting identifying the instance via 
the IO address.

-- 
With best wishes
Dmitry



From dmitry.baryshkov at linaro.org  Sat Dec 16 08:26:58 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sat, 16 Dec 2023 18:26:58 +0200
Subject: [PATCH v2 1/3] iommu/msm-iommu: don't limit the driver too much
In-Reply-To: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>
References: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>
Message-ID: <20231216162700.863456-2-dmitry.baryshkov@linaro.org>

In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
driver just to those machines. Allow it to be built for any 32-bit
Qualcomm platform (ARCH_QCOM).

Acked-by: Robin Murphy <robin.murphy at arm.com>
Acked-by: Joerg Roedel <jroedel at suse.de>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 9a29d742617e..0d6095290b6a 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -179,7 +179,7 @@ config FSL_PAMU
 config MSM_IOMMU
 	bool "MSM IOMMU Support"
 	depends on ARM
-	depends on ARCH_MSM8X60 || ARCH_MSM8960 || COMPILE_TEST
+	depends on ARCH_QCOM || COMPILE_TEST
 	select IOMMU_API
 	select IOMMU_IO_PGTABLE_ARMV7S
 	help
-- 
2.39.2



From dmitry.baryshkov at linaro.org  Sat Dec 16 08:26:57 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sat, 16 Dec 2023 18:26:57 +0200
Subject: [PATCH v2 0/3] ARM: qcom: drop 32-bit machine Kconfig entries
Message-ID: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>

The Kconfig for 32-bit Qualcomm arch predates DT and multi-machine
support. It still defines ARCH_MSM* types for some (but not all) 32-bit
Qualcomm machines. The MSM_IOMMU driver has a strict dependency on one
of such kinds.

With the DT support in place, this has become obsolete quite a while
ago. Replace all 32-bit Qualcomm ARCH kinds with the single Kconfig
entry for the workaround required to be enabled for some of those 32-bit
platforms.

Changes since v1:
- Renamed ARCH_QCOM_SMEM to ARCH_QCOM_RESERVE_SMEM (Bjorn)

Dmitry Baryshkov (3):
  iommu/msm-iommu: don't limit the driver too much
  ARM: qcom: drop most of 32-bit ARCH_QCOM subtypes
  ARM: qcom: merge remaining subplatforms into sensible Kconfig entry

 arch/arm/Makefile          |  4 +---
 arch/arm/mach-qcom/Kconfig | 41 ++++++++------------------------------
 drivers/iommu/Kconfig      |  2 +-
 3 files changed, 10 insertions(+), 37 deletions(-)

-- 
2.39.2



From dmitry.baryshkov at linaro.org  Sat Dec 16 08:26:59 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sat, 16 Dec 2023 18:26:59 +0200
Subject: [PATCH v2 2/3] ARM: qcom: drop most of 32-bit ARCH_QCOM subtypes
In-Reply-To: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>
References: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>
Message-ID: <20231216162700.863456-3-dmitry.baryshkov@linaro.org>

Historically we had several subtypes of 32-bit Qualcomm platforms.
Nowadays they became just useless symbols in Kconfig. Drop them and pull
corresponding clocksource entries towards top-level ARCH_QCOM entry.

Note, I've left ARCH_IPQ40XX, ARCH_MSM8x60 and ARCH_MSM8960 in place,
since they have special TEXT_OFFSET handling, which can be sorted out
separately.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 arch/arm/mach-qcom/Kconfig | 30 ++++--------------------------
 1 file changed, 4 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
index 12a812e61c16..27d5ca0043be 100644
--- a/arch/arm/mach-qcom/Kconfig
+++ b/arch/arm/mach-qcom/Kconfig
@@ -4,46 +4,24 @@ menuconfig ARCH_QCOM
 	depends on ARCH_MULTI_V7
 	select ARM_GIC
 	select ARM_AMBA
+	select CLKSRC_QCOM
+	select HAVE_ARM_ARCH_TIMER
 	select PINCTRL
 	select QCOM_SCM if SMP
 	help
 	  Support for Qualcomm's devicetree based systems.
+	  This includes support for a few devices with ARM64 SoC, that have
+	  ARM32 signed firmware that does not allow booting ARM64 kernels.
 
 if ARCH_QCOM
 
 config ARCH_IPQ40XX
 	bool "Enable support for IPQ40XX"
-	select CLKSRC_QCOM
-	select HAVE_ARM_ARCH_TIMER
 
 config ARCH_MSM8X60
 	bool "Enable support for MSM8X60"
-	select CLKSRC_QCOM
-
-config ARCH_MSM8909
-	bool "Enable support for MSM8909"
-	select HAVE_ARM_ARCH_TIMER
-
-config ARCH_MSM8916
-	bool "Enable support for MSM8916"
-	select HAVE_ARM_ARCH_TIMER
-	help
-	  Enable support for the Qualcomm Snapdragon 410 (MSM8916/APQ8016).
-
-	  Note that ARM64 is the main supported architecture for MSM8916.
-	  The ARM32 option is intended for a few devices with signed firmware
-	  that does not allow booting ARM64 kernels.
 
 config ARCH_MSM8960
 	bool "Enable support for MSM8960"
-	select CLKSRC_QCOM
-
-config ARCH_MSM8974
-	bool "Enable support for MSM8974"
-	select HAVE_ARM_ARCH_TIMER
-
-config ARCH_MDM9615
-	bool "Enable support for MDM9615"
-	select CLKSRC_QCOM
 
 endif
-- 
2.39.2



From dmitry.baryshkov at linaro.org  Sat Dec 16 08:27:00 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sat, 16 Dec 2023 18:27:00 +0200
Subject: [PATCH v2 3/3] ARM: qcom: merge remaining subplatforms into sensible Kconfig entry
In-Reply-To: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>
References: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>
Message-ID: <20231216162700.863456-4-dmitry.baryshkov@linaro.org>

Three remaining Qualcomm platforms have special handling of the
TEXT_OFFSET to reserve the memory at the beginnig of the system RAM, see
the commit 9e775ad19f52 ("ARM: 7012/1: Set proper TEXT_OFFSET for newer
MSMs"). This is required for older platforms like IPQ40xx, MSM8x60,
MSM8960 and APQ8064 and is compatible with other 32-bit Qualcomm
platforms.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 arch/arm/Makefile          |  4 +---
 arch/arm/mach-qcom/Kconfig | 13 +++++--------
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5ba42f69f8ce..95216a508d80 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -158,9 +158,7 @@ textofs-$(CONFIG_ARCH_REALTEK)  := 0x00108000
 ifeq ($(CONFIG_ARCH_SA1100),y)
 textofs-$(CONFIG_SA1111) := 0x00208000
 endif
-textofs-$(CONFIG_ARCH_IPQ40XX) := 0x00208000
-textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
-textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_ARCH_QCOM_RESERVE_SMEM) := 0x00208000
 textofs-$(CONFIG_ARCH_MESON) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 
diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
index 27d5ca0043be..f4765be1b2a0 100644
--- a/arch/arm/mach-qcom/Kconfig
+++ b/arch/arm/mach-qcom/Kconfig
@@ -15,13 +15,10 @@ menuconfig ARCH_QCOM
 
 if ARCH_QCOM
 
-config ARCH_IPQ40XX
-	bool "Enable support for IPQ40XX"
-
-config ARCH_MSM8X60
-	bool "Enable support for MSM8X60"
-
-config ARCH_MSM8960
-	bool "Enable support for MSM8960"
+config ARCH_QCOM_RESERVE_SMEM
+	bool "Reserve SMEM at the beginning of RAM"
+	help
+	  Reserve 2MB at the beginning of the System RAM for shared mem.
+	  This is required on IPQ40xx, MSM8x60 and MSM8960 platforms.
 
 endif
-- 
2.39.2



From knaerzche at gmail.com  Sat Dec 16 08:26:15 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:15 +0100
Subject: [PATCH v2 04/27] drm/rockchip: inno_hdmi: Remove useless mode_fixup
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-5-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The mode_fixup implementation doesn't do anything, so we can simply
remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 345253e033c5..0b1740b38c7b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -517,13 +517,6 @@ static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
 	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
 }
 
-static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
-					 const struct drm_display_mode *mode,
-					 struct drm_display_mode *adj_mode)
-{
-	return true;
-}
-
 static int
 inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 			       struct drm_crtc_state *crtc_state,
@@ -540,7 +533,6 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
 	.enable     = inno_hdmi_encoder_enable,
 	.disable    = inno_hdmi_encoder_disable,
-	.mode_fixup = inno_hdmi_encoder_mode_fixup,
 	.mode_set   = inno_hdmi_encoder_mode_set,
 	.atomic_check = inno_hdmi_encoder_atomic_check,
 };
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:11 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:11 +0100
Subject: [PATCH v2 00/27] Add HDMI support for RK3128
Message-ID: <20231216162639.125215-1-knaerzche@gmail.com>

This is version 2 of my series that aims to add support for the display
controller (VOP) and the HDMI controller block of RK3128 (which is very
similar to the one found in RK3036).

The VOP part is very simple -  everything we need for HDMI support is
already there. I only needed to split the output selection registers from
RK3036. The VOP has an IOMMU attached, but it has a serious silicon bug:
Registers can only be written, but not be read. As it's not possible to use
it with the IOMMU driver in it's current state I'm not adding it here and
we have to live with CMA for now - which works fine also. I got response
from the vendor, that there is no possibility to read the registers and an
workaround must be implemented in software in order to use it.

The inno-hdmi driver currently gets a lot of attention [0-2] and I'm
hooking in now also. As requested I incorporated some of Maxime's series
[0] (and tested them).
I have intentionally not removed any code dealing with output format
conversion in this series. In contrast to the input format, which is always
RGB on this platform and certainly can be dropped, that can be implemented
later. And secondly I need the conversion for RGB full range to RGB limited
range for this series.

I did also some smaller driver cleanups from my side and implemented a
custom connector state which now holds the data that belongs there and it
is not longer in the device structure and, of course, addressed the
feedback from v1 [3].
Please see individual patches for changelog.

Note: Patches are based and tested on next-20231213.

[0] https://lore.kernel.org/all/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org
[1] https://lore.kernel.org/all/20231204123315.28456-1-keith.zhao at starfivetech.com
[2] https://lore.kernel.org/all/2601b669-c570-f39d-8cf9-bff56c939912 at gmail.com
[3] https://lore.kernel.org/all/20231213195125.212923-1-knaerzche at gmail.com/

Alex Bee (16):
  dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible
  drm/rockchip: vop: Add output selection registers for RK312x
  drm/rockchip: inno_hdmi: Fix video timing
  drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents
  drm/rockchip: inno_hdmi: Drop irq struct member
  drm/rockchip: inno_hdmi: Remove useless include
  drm/rockchip: inno_hdmi: Subclass connector state
  drm/rockchip: inno_hdmi: Move tmds rate to connector state subclass
  drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
  drm/rockchip: inno_hdmi: Add variant support
  drm/rockchip: inno_hdmi: Add RK3128 support
  drm/rockchip: inno_hdmi: Add basic mode validation
  drm/rockchip: inno_hdmi: Drop custom fill_modes hook
  ARM: dts: rockchip: Add display subsystem for RK3128
  ARM: dts: rockchip: Add HDMI node for RK3128
  ARM: dts: rockchip: Enable HDMI output for XPI-3128

Maxime Ripard (11):
  drm/rockchip: inno_hdmi: Remove useless mode_fixup
  drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
  drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
  drm/rockchip: inno_hdmi: Get rid of mode_set
  drm/rockchip: inno_hdmi: no need to store vic
  drm/rockchip: inno_hdmi: Remove unneeded has audio flag
  drm/rockchip: inno_hdmi: Remove useless input format
  drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support
  drm/rockchip: inno_hdmi: Move infoframe disable to separate function
  drm/rockchip: inno_hdmi: Switch to infoframe type
  drm/rockchip: inno_hdmi: Remove unused drm device pointer

 .../display/rockchip/rockchip,inno-hdmi.yaml  |  40 +-
 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts |  29 ++
 arch/arm/boot/dts/rockchip/rk3128.dtsi        |  60 +++
 drivers/gpu/drm/rockchip/inno_hdmi.c          | 482 +++++++++++-------
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c   |  13 +-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h   |   3 +
 6 files changed, 448 insertions(+), 179 deletions(-)


base-commit: 48e8992e33abf054bcc0bb2e77b2d43bb899212e
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:12 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:12 +0100
Subject: [PATCH v2 01/27] dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-2-knaerzche@gmail.com>

The integration for this SoC is different from the currently existing: It
needs it's PHY's reference clock rate to calculate the DDC bus frequency
correctly. The controller is also part of a powerdomain, so this gets added
as an mandatory property for this variant.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - clarify that the controller itself is part of the powerdomain
 - simplify clock-names
 - made power-domains property only allowed (and required) for new variant
 
 .../display/rockchip/rockchip,inno-hdmi.yaml  | 40 ++++++++++++++++++-
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
index 96889c86849a..be78dcfa1c76 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
@@ -14,6 +14,7 @@ properties:
   compatible:
     enum:
       - rockchip,rk3036-inno-hdmi
+      - rockchip,rk3128-inno-hdmi
 
   reg:
     maxItems: 1
@@ -22,10 +23,19 @@ properties:
     maxItems: 1
 
   clocks:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: The HDMI controller main clock
+      - description: The HDMI PHY reference clock
 
   clock-names:
-    const: pclk
+    minItems: 1
+    items:
+      - const: pclk
+      - const: ref
+
+  power-domains:
+    maxItems: 1
 
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
@@ -55,6 +65,32 @@ required:
   - pinctrl-names
   - ports
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: rockchip,rk3036-inno-hdmi
+
+    then:
+      properties:
+        power-domains: false
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: rockchip,rk3128-inno-hdmi
+
+    then:
+      properties:
+        clocks:
+          minItems: 2
+        clock-names:
+          minItems: 2
+      required:
+        - power-domains
+
 additionalProperties: false
 
 examples:
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:13 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:13 +0100
Subject: [PATCH v2 02/27] drm/rockchip: vop: Add output selection registers for RK312x
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-3-knaerzche@gmail.com>

In contrast to RK3036, RK312x SoCs have multiple output channels such as
RGB (i.e. LVDS TTL), LVDS, DSI and HDMI.

In order to support that, this splits output from RK3036 and defines an
separate one for RK3126 with the registers required to enable the
appropriate output and setup the correct polarity.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - rephrase commit message

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 ++++++++++++-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  3 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index c51ca82320cb..b9ee02061d5b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -227,11 +227,22 @@ static const struct vop_win_data rk3126_vop_win_data[] = {
 	  .type = DRM_PLANE_TYPE_CURSOR },
 };
 
+static const struct vop_output rk3126_output = {
+	.pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+	.hdmi_pin_pol = VOP_REG(RK3126_INT_SCALER, 0x7, 4),
+	.hdmi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 22),
+	.hdmi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 23),
+	.rgb_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 24),
+	.rgb_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 25),
+	.mipi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 28),
+	.mipi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 29),
+};
+
 static const struct vop_data rk3126_vop = {
 	.intr = &rk3036_intr,
 	.common = &rk3036_common,
 	.modeset = &rk3036_modeset,
-	.output = &rk3036_output,
+	.output = &rk3126_output,
 	.win = rk3126_vop_win_data,
 	.win_size = ARRAY_SIZE(rk3126_vop_win_data),
 	.max_output = { 1920, 1080 },
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 406e981c75bd..fbf1bcc68625 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -872,6 +872,9 @@
 /* rk3036 register definition end */
 
 /* rk3126 register definition */
+#define RK3126_INT_SCALER		0x0c
+
+/* win1 register */
 #define RK3126_WIN1_MST			0x4c
 #define RK3126_WIN1_DSP_INFO		0x50
 #define RK3126_WIN1_DSP_ST		0x54
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:17 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:17 +0100
Subject: [PATCH v2 06/27] drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-7-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The inno_hdmi encoder still uses the !atomic variants of enable, disable
and modeset. Convert to their atomic equivalents.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 14d2ba92a606..48c4f010b260 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -491,22 +491,25 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 }
 
 static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-				       struct drm_display_mode *mode,
-				       struct drm_display_mode *adj_mode)
+				       struct drm_crtc_state *crtc_state,
+				       struct drm_connector_state *conn_state)
 {
+	struct drm_display_mode *adj_mode = &crtc_state->adjusted_mode;
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_setup(hdmi, adj_mode);
 }
 
-static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
+				     struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
+				      struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
@@ -527,10 +530,10 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 }
 
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
-	.enable     = inno_hdmi_encoder_enable,
-	.disable    = inno_hdmi_encoder_disable,
-	.mode_set   = inno_hdmi_encoder_mode_set,
-	.atomic_check = inno_hdmi_encoder_atomic_check,
+	.atomic_check	= inno_hdmi_encoder_atomic_check,
+	.atomic_enable	= inno_hdmi_encoder_enable,
+	.atomic_disable	= inno_hdmi_encoder_disable,
+	.atomic_mode_set	= inno_hdmi_encoder_mode_set,
 };
 
 static enum drm_connector_status
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:16 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:16 +0100
Subject: [PATCH v2 05/27] drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-6-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The driver maintains a copy of the adjusted mode but doesn't use it
anywhere. Remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 0b1740b38c7b..14d2ba92a606 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -62,7 +62,6 @@ struct inno_hdmi {
 	unsigned int tmds_rate;
 
 	struct hdmi_data_info	hdmi_data;
-	struct drm_display_mode previous_mode;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -498,9 +497,6 @@ static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_setup(hdmi, adj_mode);
-
-	/* Store the display mode for plugin/DPMS poweron events */
-	drm_mode_copy(&hdmi->previous_mode, adj_mode);
 }
 
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:14 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:14 +0100
Subject: [PATCH v2 03/27] drm/rockchip: inno_hdmi: Fix video timing
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-4-knaerzche@gmail.com>

The controller wants the difference between *total and *sync_start in the
HDMI_VIDEO_EXT_*DELAY registers. Otherwise the signal is very unstable for
certain non-VIC modes. See downstream commit [0].

[0] https://github.com/rockchip-linux/kernel/commit/8eb559f2502c

Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Co-developed-by: Zheng Yang <zhengyang at rock-chips.com>
Signed-off-by: Zheng Yang <zhengyang at rock-chips.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - none
 
 drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 6e5b922a121e..345253e033c5 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -412,7 +412,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_L, value & 0xFF);
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_H, (value >> 8) & 0xFF);
 
-	value = mode->hsync_start - mode->hdisplay;
+	value = mode->htotal - mode->hsync_start;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_L, value & 0xFF);
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_H, (value >> 8) & 0xFF);
 
@@ -427,7 +427,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
 	value = mode->vtotal - mode->vdisplay;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VBLANK, value & 0xFF);
 
-	value = mode->vsync_start - mode->vdisplay;
+	value = mode->vtotal - mode->vsync_start;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VDELAY, value & 0xFF);
 
 	value = mode->vsync_end - mode->vsync_start;
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:18 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:18 +0100
Subject: [PATCH v2 07/27] drm/rockchip: inno_hdmi: Get rid of mode_set
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-8-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 48c4f010b260..299770e481b7 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -490,21 +490,22 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	return 0;
 }
 
-static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-				       struct drm_crtc_state *crtc_state,
-				       struct drm_connector_state *conn_state)
-{
-	struct drm_display_mode *adj_mode = &crtc_state->adjusted_mode;
-	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
-
-	inno_hdmi_setup(hdmi, adj_mode);
-}
-
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 				     struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
+	struct drm_connector_state *conn_state;
+	struct drm_crtc_state *crtc_state;
+
+	conn_state = drm_atomic_get_new_connector_state(state, &hdmi->connector);
+	if (WARN_ON(!conn_state))
+		return;
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+	if (WARN_ON(!crtc_state))
+		return;
 
+	inno_hdmi_setup(hdmi, &crtc_state->adjusted_mode);
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
@@ -533,7 +534,6 @@ static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
 	.atomic_check	= inno_hdmi_encoder_atomic_check,
 	.atomic_enable	= inno_hdmi_encoder_enable,
 	.atomic_disable	= inno_hdmi_encoder_disable,
-	.atomic_mode_set	= inno_hdmi_encoder_mode_set,
 };
 
 static enum drm_connector_status
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:19 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:19 +0100
Subject: [PATCH v2 08/27] drm/rockchip: inno_hdmi: no need to store vic
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-9-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The mode's VIC is only ever used in the inno_hdmi_setup() function so
there's no need to store it in the main structure.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
[made checkpatch happy]
Signed-off-by: Alex Bee <knaerzche at gmail.com>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 299770e481b7..d99896f1a73a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	int vic;
 	bool sink_has_audio;
 	unsigned int enc_in_format;
 	unsigned int enc_out_format;
@@ -443,16 +442,15 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 			   struct drm_display_mode *mode)
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
-
-	hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
+	u8 vic = drm_match_cea_mode(mode);
 
 	hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
 	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
 
-	if ((hdmi->hdmi_data.vic == 6) || (hdmi->hdmi_data.vic == 7) ||
-	    (hdmi->hdmi_data.vic == 21) || (hdmi->hdmi_data.vic == 22) ||
-	    (hdmi->hdmi_data.vic == 2) || (hdmi->hdmi_data.vic == 3) ||
-	    (hdmi->hdmi_data.vic == 17) || (hdmi->hdmi_data.vic == 18))
+	if (vic == 6 || vic == 7 ||
+	    vic == 21 || vic == 22 ||
+	    vic == 2 || vic == 3 ||
+	    vic == 17 || vic == 18)
 		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
 	else
 		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:20 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:20 +0100
Subject: [PATCH v2 09/27] drm/rockchip: inno_hdmi: Remove unneeded has audio flag
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-10-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The sink_has_audio flag is not used anywhere in the driver so let's get
rid of it. It's redundant with drm_display_info.has_audio anyway.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index d99896f1a73a..58aff7a9c09a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	bool sink_has_audio;
 	unsigned int enc_in_format;
 	unsigned int enc_out_format;
 	unsigned int colorimetry;
@@ -554,7 +553,6 @@ static int inno_hdmi_connector_get_modes(struct drm_connector *connector)
 
 	edid = drm_get_edid(connector, hdmi->ddc);
 	if (edid) {
-		hdmi->hdmi_data.sink_has_audio = drm_detect_monitor_audio(edid);
 		drm_connector_update_edid_property(connector, edid);
 		ret = drm_add_edid_modes(connector, edid);
 		kfree(edid);
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:23 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:23 +0100
Subject: [PATCH v2 12/27] drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-13-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The HDMI vendor infoframe is only meant to be sent with 4k60 modes and
higher, but the controller doesn't support them. Let's drop them from
the kernel.

Suggested-by: Johan Jonker <jbx6244 at gmail.com>
Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 35 ++++++++--------------------
 1 file changed, 10 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 04344ee1265d..1dd757845547 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -208,11 +208,15 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 }
 
 static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
-				  union hdmi_infoframe *frame, u32 frame_index,
-				  u32 mask, u32 disable, u32 enable)
+				  union hdmi_infoframe *frame, u32 frame_index)
 {
-	if (mask)
-		hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, disable);
+	struct drm_connector *connector = &hdmi->connector;
+
+	if (frame_index != INFOFRAME_AVI) {
+		drm_err(connector->dev,
+			"Unsupported infoframe type: %u\n", frame_index);
+		return 0;
+	}
 
 	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
 
@@ -228,28 +232,11 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
 		for (i = 0; i < rc; i++)
 			hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
 				    packed_frame[i]);
-
-		if (mask)
-			hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, enable);
 	}
 
 	return setup_rc;
 }
 
-static int inno_hdmi_config_video_vsi(struct inno_hdmi *hdmi,
-				      struct drm_display_mode *mode)
-{
-	union hdmi_infoframe frame;
-	int rc;
-
-	rc = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
-							 &hdmi->connector,
-							 mode);
-
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_VSI,
-		m_PACKET_VSI_EN, v_PACKET_VSI_EN(0), v_PACKET_VSI_EN(1));
-}
-
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 				      struct drm_display_mode *mode)
 {
@@ -267,7 +254,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
+	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
@@ -410,10 +397,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 
 	inno_hdmi_config_video_csc(hdmi);
 
-	if (display->is_hdmi) {
+	if (display->is_hdmi)
 		inno_hdmi_config_video_avi(hdmi, mode);
-		inno_hdmi_config_video_vsi(hdmi, mode);
-	}
 
 	/*
 	 * When IP controller have configured to an accurate video
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:24 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:24 +0100
Subject: [PATCH v2 13/27] drm/rockchip: inno_hdmi: Move infoframe disable to separate function
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-14-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The code to upload infoframes to the controller uses a weird construct
which, based on the previous function call return code, will either
disable or enable that infoframe.

In order to get rid of that argument, let's split the function to
disable the infoframe into a separate function and make it obvious what
we are doing in the error path.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 46 ++++++++++++++++++----------
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 1dd757845547..6354949bfd8e 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -207,34 +207,44 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
-				  union hdmi_infoframe *frame, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
 {
 	struct drm_connector *connector = &hdmi->connector;
 
 	if (frame_index != INFOFRAME_AVI) {
 		drm_err(connector->dev,
 			"Unsupported infoframe type: %u\n", frame_index);
-		return 0;
+		return;
 	}
 
 	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+}
 
-	if (setup_rc >= 0) {
-		u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
-		ssize_t rc, i;
-
-		rc = hdmi_infoframe_pack(frame, packed_frame,
-					 sizeof(packed_frame));
-		if (rc < 0)
-			return rc;
+static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
+				  union hdmi_infoframe *frame, u32 frame_index)
+{
+	struct drm_connector *connector = &hdmi->connector;
+	u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
+	ssize_t rc, i;
 
-		for (i = 0; i < rc; i++)
-			hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
-				    packed_frame[i]);
+	if (frame_index != INFOFRAME_AVI) {
+		drm_err(connector->dev,
+			"Unsupported infoframe type: %u\n", frame_index);
+		return 0;
 	}
 
-	return setup_rc;
+	inno_hdmi_disable_frame(hdmi, frame_index);
+
+	rc = hdmi_infoframe_pack(frame, packed_frame,
+				 sizeof(packed_frame));
+	if (rc < 0)
+		return rc;
+
+	for (i = 0; i < rc; i++)
+		hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
+			    packed_frame[i]);
+
+	return 0;
 }
 
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
@@ -246,6 +256,10 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
 						      &hdmi->connector,
 						      mode);
+	if (rc) {
+		inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+		return rc;
+	}
 
 	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
 		frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
@@ -254,7 +268,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI);
+	return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:22 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:22 +0100
Subject: [PATCH v2 11/27] drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-12-knaerzche@gmail.com>

Now that the unneeded support for YUV based input formats is gone, the csc
coefficients for those formats can be dropped as well.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - new patch
	
 drivers/gpu/drm/rockchip/inno_hdmi.c | 37 ----------------------------
 1 file changed, 37 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 7c75feedacad..04344ee1265d 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -74,49 +74,12 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct drm_connector *connector)
 }
 
 enum {
-	CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
-	CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
-	CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
 	CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
 	CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
 	CSC_RGB_0_255_TO_RGB_16_235_8BIT,
 };
 
 static const char coeff_csc[][24] = {
-	/*
-	 * YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
-	 *   R = 1.164*Y + 1.596*V - 204
-	 *   G = 1.164*Y - 0.391*U - 0.813*V + 154
-	 *   B = 1.164*Y + 2.018*U - 258
-	 */
-	{
-		0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
-		0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
-		0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
-	},
-	/*
-	 * YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
-	 *   R = Y + 1.402*V - 248
-	 *   G = Y - 0.344*U - 0.714*V + 135
-	 *   B = Y + 1.772*U - 227
-	 */
-	{
-		0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 0xf8,
-		0x04, 0x00, 0x11, 0x60, 0x12, 0xdb, 0x00, 0x87,
-		0x04, 0x00, 0x07, 0x16, 0x00, 0x00, 0x02, 0xe3
-	},
-	/*
-	 * YUV2RGB:709 HD mode(Y[16:235],UV[16:240],RGB[0:255]):
-	 *   R = 1.164*Y + 1.793*V - 248
-	 *   G = 1.164*Y - 0.213*U - 0.534*V + 77
-	 *   B = 1.164*Y + 2.115*U - 289
-	 */
-	{
-		0x04, 0xa7, 0x00, 0x00, 0x07, 0x2c, 0x02, 0xf8,
-		0x04, 0xa7, 0x10, 0xda, 0x12, 0x22, 0x00, 0x4d,
-		0x04, 0xa7, 0x08, 0x74, 0x00, 0x00, 0x03, 0x21
-	},
-
 	/*
 	 * RGB2YUV:601 SD mode:
 	 *   Cb = -0.291G - 0.148R + 0.439B + 128
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:28 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:28 +0100
Subject: [PATCH v2 17/27] drm/rockchip: inno_hdmi: Remove useless include
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-18-knaerzche@gmail.com>

The inclusion syscon.h isn't used anywhere. Remove it.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - new patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index d9eb8cdc0148..62c7e2275246 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -10,7 +10,6 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/hdmi.h>
-#include <linux/mfd/syscon.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:26 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:26 +0100
Subject: [PATCH v2 15/27] drm/rockchip: inno_hdmi: Remove unused drm device pointer
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-16-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index b6b34f4b8cda..e37023d8fa39 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -44,7 +44,6 @@ struct inno_hdmi_i2c {
 
 struct inno_hdmi {
 	struct device *dev;
-	struct drm_device *drm_dev;
 
 	int irq;
 	struct clk *pclk;
@@ -760,7 +759,6 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		return -ENOMEM;
 
 	hdmi->dev = dev;
-	hdmi->drm_dev = drm;
 
 	hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hdmi->regs))
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:27 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:27 +0100
Subject: [PATCH v2 16/27] drm/rockchip: inno_hdmi: Drop irq struct member
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-17-knaerzche@gmail.com>

The struct member irq isn't used anywhere. Drop it.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - new patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e37023d8fa39..d9eb8cdc0148 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -45,7 +45,6 @@ struct inno_hdmi_i2c {
 struct inno_hdmi {
 	struct device *dev;
 
-	int irq;
 	struct clk *pclk;
 	void __iomem *regs;
 
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:30 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:30 +0100
Subject: [PATCH v2 19/27] drm/rockchip: inno_hdmi: Move tmds rate to connector state subclass
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-20-knaerzche@gmail.com>

Similar to the othter members of inno_hdmi_connector_state the tmds_rate is
not a property of the device, but of the connector state. Move it to
inno_hdmi_connector_state and make it a long to comply with the clock
framework. To get arround the issue of not having the connector state when
inno_hdmi_i2c_init is called in the bind path, getting the tmds rate is
wrapped in function which returns the fallback rate if the connector
doesn't have a state yet.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - new patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 36 +++++++++++++++++++---------
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f9bfae1e97a2..6799d24501b8 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -47,14 +47,13 @@ struct inno_hdmi {
 
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
-
-	unsigned int tmds_rate;
 };
 
 struct inno_hdmi_connector_state {
 	struct drm_connector_state	base;
 	unsigned int			enc_out_format;
 	unsigned int			colorimetry;
+	unsigned long			tmds_rate;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -133,11 +132,33 @@ static inline void hdmi_modb(struct inno_hdmi *hdmi, u16 offset,
 	hdmi_writeb(hdmi, offset, temp);
 }
 
+static unsigned long inno_hdmi_tmds_rate(struct inno_hdmi *hdmi)
+{
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_connector_state *conn_state =  connector->state;
+	struct inno_hdmi_connector_state *inno_conn_state;
+
+	if (conn_state) {
+		inno_conn_state = to_inno_hdmi_conn_state(conn_state);
+		return inno_conn_state->tmds_rate;
+	}
+
+	/*
+	 * When IP controller haven't configured to an accurate video
+	 * timing, then the TMDS clock source would be switched to
+	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
+	 * and reconfigure the DDC clock.
+	 */
+
+	return clk_get_rate(hdmi->pclk);
+}
+
 static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
 {
 	int ddc_bus_freq;
+	unsigned long tmds_rate = inno_hdmi_tmds_rate(hdmi);
 
-	ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE;
+	ddc_bus_freq = (tmds_rate >> 2) / HDMI_SCL_RATE;
 
 	hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
 	hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
@@ -431,7 +452,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
 	 * clock rate, and reconfigure the DDC clock.
 	 */
-	hdmi->tmds_rate = mode->clock * 1000;
+	inno_conn_state->tmds_rate = mode->clock * 1000;
 	inno_hdmi_i2c_init(hdmi);
 
 	/* Unmute video and audio output */
@@ -823,13 +844,6 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		goto err_disable_clk;
 	}
 
-	/*
-	 * When IP controller haven't configured to an accurate video
-	 * timing, then the TMDS clock source would be switched to
-	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
-	 * and reconfigure the DDC clock.
-	 */
-	hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
 	inno_hdmi_i2c_init(hdmi);
 
 	ret = inno_hdmi_register(drm, hdmi);
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:31 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:31 +0100
Subject: [PATCH v2 20/27] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-21-knaerzche@gmail.com>

The display controller will always give full range RGB regardless of the
mode set, but HDMI requires certain modes to be transmitted in limited
range RGB. This is especially required for HDMI sinks which do not support
non-standard quantization ranges.

This enables color space conversion for those modes and sets the
quantization range accordingly in the AVI infoframe.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - made rgb_limited_range part of the new custom connector state

 drivers/gpu/drm/rockchip/inno_hdmi.c | 60 +++++++++++++++++++---------
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 6799d24501b8..9f27a5faf12d 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -54,6 +54,7 @@ struct inno_hdmi_connector_state {
 	unsigned int			enc_out_format;
 	unsigned int			colorimetry;
 	unsigned long			tmds_rate;
+	bool				rgb_limited_range;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -293,6 +294,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
+	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
+		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
+						   connector, mode,
+						   inno_conn_state->rgb_limited_range ?
+						   HDMI_QUANTIZATION_RANGE_LIMITED :
+						   HDMI_QUANTIZATION_RANGE_FULL);
+	} else {
+		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
+		frame.avi.ycc_quantization_range =
+			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
+	}
+
 	return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI);
 }
 
@@ -320,29 +333,37 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
 	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
-		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
-		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
-		hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
-			  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
-			  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
-			  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
-		return 0;
-	}
-
-	if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
-			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
+		if (inno_conn_state->rgb_limited_range) {
+			csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
+
+		} else {
+			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+
+			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+			return 0;
 		}
 	} else {
-		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
-			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
-			auto_csc = AUTO_CSC_DISABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_ENABLE;
+		if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
+			if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
+				csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
+				auto_csc = AUTO_CSC_DISABLE;
+				c0_c2_change = C0_C2_CHANGE_DISABLE;
+				csc_enable = v_CSC_ENABLE;
+			}
+		} else {
+			if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
+				csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
+				auto_csc = AUTO_CSC_DISABLE;
+				c0_c2_change = C0_C2_CHANGE_DISABLE;
+				csc_enable = v_CSC_ENABLE;
+			}
 		}
 	}
 
@@ -431,6 +452,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	else
 		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
 
+	inno_conn_state->rgb_limited_range =
+		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
+
 	/* Mute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
 		  v_AUDIO_MUTE(1) | v_VIDEO_MUTE(1));
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:21 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:21 +0100
Subject: [PATCH v2 10/27] drm/rockchip: inno_hdmi: Remove useless input format
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-11-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The driver has a lot of logic to deal with multiple input formats, but
hardcodes it to RGB. This means that most of that code has been dead
code, so let's get rid of it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
[made checkpatch happy]
Signed-off-by: Alex Bee <knaerzche at gmail.com>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 41 ++++++++--------------------
 1 file changed, 11 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 58aff7a9c09a..7c75feedacad 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	unsigned int enc_in_format;
 	unsigned int enc_out_format;
 	unsigned int colorimetry;
 };
@@ -328,47 +327,30 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		v_VIDEO_INPUT_CSP(0);
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
-	if (data->enc_in_format == data->enc_out_format) {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
-		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
-			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
-			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
-			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
-				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
-				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
-				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
-			return 0;
-		}
+	if (data->enc_out_format == HDMI_COLORSPACE_RGB) {
+		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+
+		hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+			  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+			  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+			  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+		return 0;
 	}
 
 	if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
-		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
-		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
-			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
-			csc_mode = CSC_ITU601_16_235_TO_RGB_0_255_8BIT;
-			auto_csc = AUTO_CSC_ENABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_DISABLE;
 		}
 	} else {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
-		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
-		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
-			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
-			csc_mode = CSC_ITU709_16_235_TO_RGB_0_255_8BIT;
-			auto_csc = AUTO_CSC_ENABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_DISABLE;
 		}
 	}
 
@@ -443,7 +425,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	struct drm_display_info *display = &hdmi->connector.display_info;
 	u8 vic = drm_match_cea_mode(mode);
 
-	hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
 	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
 
 	if (vic == 6 || vic == 7 ||
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:25 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:25 +0100
Subject: [PATCH v2 14/27] drm/rockchip: inno_hdmi: Switch to infoframe type
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-15-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The inno_hdmi driver relies on its own internal infoframe type matching
the hardware.

This works fine, but in order to make further reworks easier, let's
switch to the HDMI spec definition of those types.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch
 
 drivers/gpu/drm/rockchip/inno_hdmi.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 6354949bfd8e..b6b34f4b8cda 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -207,33 +207,34 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
+				    enum hdmi_infoframe_type type)
 {
 	struct drm_connector *connector = &hdmi->connector;
 
-	if (frame_index != INFOFRAME_AVI) {
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
-			"Unsupported infoframe type: %u\n", frame_index);
+			"Unsupported infoframe type: %u\n", type);
 		return;
 	}
 
-	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
-				  union hdmi_infoframe *frame, u32 frame_index)
+				  union hdmi_infoframe *frame, enum hdmi_infoframe_type type)
 {
 	struct drm_connector *connector = &hdmi->connector;
 	u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
 	ssize_t rc, i;
 
-	if (frame_index != INFOFRAME_AVI) {
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
-			"Unsupported infoframe type: %u\n", frame_index);
+			"Unsupported infoframe type: %u\n", type);
 		return 0;
 	}
 
-	inno_hdmi_disable_frame(hdmi, frame_index);
+	inno_hdmi_disable_frame(hdmi, type);
 
 	rc = hdmi_infoframe_pack(frame, packed_frame,
 				 sizeof(packed_frame));
@@ -257,7 +258,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 						      &hdmi->connector,
 						      mode);
 	if (rc) {
-		inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+		inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI);
 		return rc;
 	}
 
@@ -268,7 +269,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI);
+	return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:29 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:29 +0100
Subject: [PATCH v2 18/27] drm/rockchip: inno_hdmi: Subclass connector state
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-19-knaerzche@gmail.com>

The data which is currently hold in hdmi_data should not be part of device
itself but of the connector state.
Introduce a connector state subclass and move the data from hdmi_data in
there.

Suggested-by: Maxime Ripard <mripard at kernel.org>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - new patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 67 +++++++++++++++++++++-------
 1 file changed, 50 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 62c7e2275246..f9bfae1e97a2 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,11 +26,6 @@
 
 #include "inno_hdmi.h"
 
-struct hdmi_data_info {
-	unsigned int enc_out_format;
-	unsigned int colorimetry;
-};
-
 struct inno_hdmi_i2c {
 	struct i2c_adapter adap;
 
@@ -54,8 +49,12 @@ struct inno_hdmi {
 	struct i2c_adapter *ddc;
 
 	unsigned int tmds_rate;
+};
 
-	struct hdmi_data_info	hdmi_data;
+struct inno_hdmi_connector_state {
+	struct drm_connector_state	base;
+	unsigned int			enc_out_format;
+	unsigned int			colorimetry;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -70,6 +69,9 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct drm_connector *connector)
 	return container_of(connector, struct inno_hdmi, connector);
 }
 
+#define to_inno_hdmi_conn_state(_state) \
+	container_of_const(_state, struct inno_hdmi_connector_state, base)
+
 enum {
 	CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
 	CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
@@ -248,6 +250,10 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 				      struct drm_display_mode *mode)
 {
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_connector_state *conn_state = connector->state;
+	struct inno_hdmi_connector_state *inno_conn_state =
+					to_inno_hdmi_conn_state(conn_state);
 	union hdmi_infoframe frame;
 	int rc;
 
@@ -259,9 +265,9 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 		return rc;
 	}
 
-	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
+	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444)
 		frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
-	else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
+	else if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV422)
 		frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
@@ -271,7 +277,10 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 {
-	struct hdmi_data_info *data = &hdmi->hdmi_data;
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_connector_state *conn_state = connector->state;
+	struct inno_hdmi_connector_state *inno_conn_state =
+					to_inno_hdmi_conn_state(conn_state);
 	int c0_c2_change = 0;
 	int csc_enable = 0;
 	int csc_mode = 0;
@@ -289,7 +298,7 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		v_VIDEO_INPUT_CSP(0);
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
-	if (data->enc_out_format == HDMI_COLORSPACE_RGB) {
+	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
 		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
 		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
 
@@ -300,15 +309,15 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		return 0;
 	}
 
-	if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
+	if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
+		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
 		}
 	} else {
-		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
+		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
@@ -386,16 +395,20 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
 	u8 vic = drm_match_cea_mode(mode);
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_connector_state *conn_state = connector->state;
+	struct inno_hdmi_connector_state *inno_conn_state =
+					to_inno_hdmi_conn_state(conn_state);
 
-	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
+	inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB;
 
 	if (vic == 6 || vic == 7 ||
 	    vic == 21 || vic == 22 ||
 	    vic == 2 || vic == 3 ||
 	    vic == 17 || vic == 18)
-		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
+		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_601;
 	else
-		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
+		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
 
 	/* Mute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -522,12 +535,32 @@ static void inno_hdmi_connector_destroy(struct drm_connector *connector)
 	drm_connector_cleanup(connector);
 }
 
+static struct drm_connector_state *
+inno_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+	struct inno_hdmi_connector_state *inno_conn_state;
+
+	if (WARN_ON(!connector->state))
+		return NULL;
+
+	inno_conn_state = kmemdup(to_inno_hdmi_conn_state(connector->state),
+				  sizeof(*inno_conn_state), GFP_KERNEL);
+
+	if (!inno_conn_state)
+		return NULL;
+
+	__drm_atomic_helper_connector_duplicate_state(connector,
+						      &inno_conn_state->base);
+
+	return &inno_conn_state->base;
+}
+
 static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
 	.fill_modes = inno_hdmi_probe_single_connector_modes,
 	.detect = inno_hdmi_connector_detect,
 	.destroy = inno_hdmi_connector_destroy,
 	.reset = drm_atomic_helper_connector_reset,
-	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_duplicate_state = inno_hdmi_connector_duplicate_state,
 	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:35 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:35 +0100
Subject: [PATCH v2 24/27] drm/rockchip: inno_hdmi: Drop custom fill_modes hook
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-25-knaerzche@gmail.com>

Now that we have proper pixelclock-based mode validation we can drop the
custom fill_modes hook.
CRTC size validation for the display controller has been added with
Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
hardware capabilities")

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

 drivers/gpu/drm/rockchip/inno_hdmi.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 14473ca96e0f..d477d2872195 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -667,13 +667,6 @@ inno_hdmi_connector_mode_valid(struct drm_connector *connector,
 	return  inno_hdmi_display_mode_valid(hdmi, mode);
 }
 
-static int
-inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
-				       uint32_t maxX, uint32_t maxY)
-{
-	return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
-}
-
 static void inno_hdmi_connector_destroy(struct drm_connector *connector)
 {
 	drm_connector_unregister(connector);
@@ -701,7 +694,7 @@ inno_hdmi_connector_duplicate_state(struct drm_connector *connector)
 }
 
 static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
-	.fill_modes = inno_hdmi_probe_single_connector_modes,
+	.fill_modes = drm_helper_probe_single_connector_modes,
 	.detect = inno_hdmi_connector_detect,
 	.destroy = inno_hdmi_connector_destroy,
 	.reset = drm_atomic_helper_connector_reset,
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:32 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:32 +0100
Subject: [PATCH v2 21/27] drm/rockchip: inno_hdmi: Add variant support
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-22-knaerzche@gmail.com>

In preparation to support RK3128's integration of the controller, this
patch adds a simple variant implementation. They mainly differ in the phy
configuration required, so those are part of the match_data. The values
have been taken from downstream. The pixelclocks in there are meant to be
max-inclusive.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes
 
 drivers/gpu/drm/rockchip/inno_hdmi.c | 69 +++++++++++++++++++++++++++-
 1 file changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 9f27a5faf12d..579baba6a61b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,6 +26,17 @@
 
 #include "inno_hdmi.h"
 
+struct inno_hdmi_phy_config {
+	unsigned long pixelclock;
+	u8 pre_emphasis;
+	u8 voltage_level_control;
+};
+
+struct inno_hdmi_variant {
+	struct inno_hdmi_phy_config *phy_configs;
+	struct inno_hdmi_phy_config *default_phy_config;
+};
+
 struct inno_hdmi_i2c {
 	struct i2c_adapter adap;
 
@@ -47,6 +58,8 @@ struct inno_hdmi {
 
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
+
+	const struct inno_hdmi_variant *variant;
 };
 
 struct inno_hdmi_connector_state {
@@ -114,6 +127,30 @@ static const char coeff_csc[][24] = {
 	},
 };
 
+static struct inno_hdmi_phy_config rk3036_hdmi_phy_configs[] = {
+	{  74250000, 0x3f, 0xbb },
+	{ 165000000, 0x6f, 0xbb },
+	{      ~0UL, 0x00, 0x00 }
+};
+
+static int inno_hdmi_find_phy_config(struct inno_hdmi *hdmi,
+				     unsigned long pixelclk)
+{
+	const struct inno_hdmi_phy_config *phy_configs =
+						hdmi->variant->phy_configs;
+	int i;
+
+	for (i = 0; phy_configs[i].pixelclock != ~0UL; i++) {
+		if (pixelclk <= phy_configs[i].pixelclock)
+			return i;
+	}
+
+	DRM_DEV_DEBUG(hdmi->dev, "No phy configuration for pixelclock %lu\n",
+		      pixelclk);
+
+	return -EINVAL;
+}
+
 static inline u8 hdmi_readb(struct inno_hdmi *hdmi, u16 offset)
 {
 	return readl_relaxed(hdmi->regs + (offset) * 0x04);
@@ -179,12 +216,26 @@ static void inno_hdmi_sys_power(struct inno_hdmi *hdmi, bool enable)
 
 static void inno_hdmi_set_pwr_mode(struct inno_hdmi *hdmi, int mode)
 {
+	struct inno_hdmi_phy_config *phy_config;
+	int ret;
+	unsigned long tmds_rate;
+
 	switch (mode) {
 	case NORMAL:
 		inno_hdmi_sys_power(hdmi, false);
+		tmds_rate = inno_hdmi_tmds_rate(hdmi);
+		ret = inno_hdmi_find_phy_config(hdmi, tmds_rate);
+		if (ret < 0) {
+			phy_config = hdmi->variant->default_phy_config;
+			DRM_DEV_ERROR(hdmi->dev,
+				      "Using default phy configuration for TMDS rate %lu",
+				      tmds_rate);
+		} else {
+			phy_config = &hdmi->variant->phy_configs[ret];
+		}
 
-		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
-		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
+		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, phy_config->pre_emphasis);
+		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, phy_config->voltage_level_control);
 
 		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
 		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
@@ -827,6 +878,8 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	struct platform_device *pdev = to_platform_device(dev);
 	struct drm_device *drm = data;
 	struct inno_hdmi *hdmi;
+	const struct inno_hdmi_variant *variant;
+
 	int irq;
 	int ret;
 
@@ -836,6 +889,12 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 
 	hdmi->dev = dev;
 
+	variant = of_device_get_match_data(hdmi->dev);
+	if (!variant)
+		return -EINVAL;
+
+	hdmi->variant = variant;
+
 	hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hdmi->regs))
 		return PTR_ERR(hdmi->regs);
@@ -923,8 +982,14 @@ static void inno_hdmi_remove(struct platform_device *pdev)
 	component_del(&pdev->dev, &inno_hdmi_ops);
 }
 
+static const struct inno_hdmi_variant rk3036_inno_hdmi_variant = {
+	.phy_configs = rk3036_hdmi_phy_configs,
+	.default_phy_config = &rk3036_hdmi_phy_configs[1],
+};
+
 static const struct of_device_id inno_hdmi_dt_ids[] = {
 	{ .compatible = "rockchip,rk3036-inno-hdmi",
+	  .data = &rk3036_inno_hdmi_variant,
 	},
 	{},
 };
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:33 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:33 +0100
Subject: [PATCH v2 22/27] drm/rockchip: inno_hdmi: Add RK3128 support
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-23-knaerzche@gmail.com>

This variant requires the phy reference clock to be enabled before the DDC
block can work and the (initial) DDC bus frequency is calculated based on
the rate of this clock. Besides the only difference is phy configuration
required to make the driver working for this variant as well.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

 drivers/gpu/drm/rockchip/inno_hdmi.c | 46 +++++++++++++++++++++++++---
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 579baba6a61b..792e5fad09bf 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -51,6 +51,7 @@ struct inno_hdmi {
 	struct device *dev;
 
 	struct clk *pclk;
+	struct clk *refclk;
 	void __iomem *regs;
 
 	struct drm_connector	connector;
@@ -133,6 +134,12 @@ static struct inno_hdmi_phy_config rk3036_hdmi_phy_configs[] = {
 	{      ~0UL, 0x00, 0x00 }
 };
 
+static struct inno_hdmi_phy_config rk3128_hdmi_phy_configs[] = {
+	{  74250000, 0x3f, 0xaa },
+	{ 165000000, 0x5f, 0xaa },
+	{      ~0UL, 0x00, 0x00 }
+};
+
 static int inno_hdmi_find_phy_config(struct inno_hdmi *hdmi,
 				     unsigned long pixelclk)
 {
@@ -182,13 +189,17 @@ static unsigned long inno_hdmi_tmds_rate(struct inno_hdmi *hdmi)
 	}
 
 	/*
-	 * When IP controller haven't configured to an accurate video
-	 * timing, then the TMDS clock source would be switched to
-	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
-	 * and reconfigure the DDC clock.
+	 * When IP controller isn't configured to an accurate
+	 * video timing and there is no reference clock available,
+	 * then the TMDS clock source would be switched to PCLK_HDMI,
+	 * so we need to init the TMDS rate to PCLK rate, and
+	 * reconfigure the DDC clock.
 	 */
 
-	return clk_get_rate(hdmi->pclk);
+	if (hdmi->refclk)
+		return clk_get_rate(hdmi->refclk);
+	else
+		return clk_get_rate(hdmi->pclk);
 }
 
 static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
@@ -912,6 +923,20 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		return ret;
 	}
 
+	hdmi->refclk = devm_clk_get_optional(hdmi->dev, "ref");
+	if (IS_ERR(hdmi->refclk)) {
+		DRM_DEV_ERROR(hdmi->dev, "Unable to get HDMI reference clock\n");
+		ret = PTR_ERR(hdmi->refclk);
+		goto err_disable_pclk;
+	}
+
+	ret = clk_prepare_enable(hdmi->refclk);
+	if (ret) {
+		DRM_DEV_ERROR(hdmi->dev,
+			      "Cannot enable HDMI reference clock: %d\n", ret);
+		goto err_disable_pclk;
+	}
+
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		ret = irq;
@@ -951,6 +976,8 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 err_put_adapter:
 	i2c_put_adapter(hdmi->ddc);
 err_disable_clk:
+	clk_disable_unprepare(hdmi->refclk);
+err_disable_pclk:
 	clk_disable_unprepare(hdmi->pclk);
 	return ret;
 }
@@ -964,6 +991,7 @@ static void inno_hdmi_unbind(struct device *dev, struct device *master,
 	hdmi->encoder.encoder.funcs->destroy(&hdmi->encoder.encoder);
 
 	i2c_put_adapter(hdmi->ddc);
+	clk_disable_unprepare(hdmi->refclk);
 	clk_disable_unprepare(hdmi->pclk);
 }
 
@@ -987,10 +1015,18 @@ static const struct inno_hdmi_variant rk3036_inno_hdmi_variant = {
 	.default_phy_config = &rk3036_hdmi_phy_configs[1],
 };
 
+static const struct inno_hdmi_variant rk3128_inno_hdmi_variant = {
+	.phy_configs = rk3128_hdmi_phy_configs,
+	.default_phy_config = &rk3128_hdmi_phy_configs[1],
+};
+
 static const struct of_device_id inno_hdmi_dt_ids[] = {
 	{ .compatible = "rockchip,rk3036-inno-hdmi",
 	  .data = &rk3036_inno_hdmi_variant,
 	},
+	{ .compatible = "rockchip,rk3128-inno-hdmi",
+	  .data = &rk3128_inno_hdmi_variant,
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, inno_hdmi_dt_ids);
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:37 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:37 +0100
Subject: [PATCH v2 26/27] ARM: dts: rockchip: Add HDMI node for RK3128
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-27-knaerzche@gmail.com>

RK3128 has Innosilicon based HDMI TX controller similar to the one found in
RK3036.
Add it and the respective port nodes to the SoC device tree.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

 arch/arm/boot/dts/rockchip/rk3128.dtsi | 33 ++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 1a3bc8b2bc6e..fb98873fd94e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -270,6 +270,11 @@ vop: vop at 1010e000 {
 		vop_out: port {
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			vop_out_hdmi: endpoint at 0 {
+				reg = <0>;
+				remote-endpoint = <&hdmi_in_vop>;
+			};
 		};
 	};
 
@@ -463,6 +468,34 @@ usb2phy_otg: otg-port {
 		};
 	};
 
+	hdmi: hdmi at 20034000 {
+		compatible = "rockchip,rk3128-inno-hdmi";
+		reg = <0x20034000 0x4000>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru PCLK_HDMI>, <&cru DCLK_VOP>;
+		clock-names = "pclk", "ref";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hdmii2c_xfer &hdmi_hpd &hdmi_cec>;
+		power-domains = <&power RK3128_PD_VIO>;
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			hdmi_in: port at 0 {
+				reg = <0>;
+				hdmi_in_vop: endpoint {
+					remote-endpoint = <&vop_out_hdmi>;
+				};
+			};
+
+			hdmi_out: port at 1 {
+				reg = <1>;
+			};
+		};
+	};
+
 	timer0: timer at 20044000 {
 		compatible = "rockchip,rk3128-timer", "rockchip,rk3288-timer";
 		reg = <0x20044000 0x20>;
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:34 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:34 +0100
Subject: [PATCH v2 23/27] drm/rockchip: inno_hdmi: Add basic mode validation
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-24-knaerzche@gmail.com>

As per TRM this controller supports pixelclocks starting from 25 MHz. The
maximum supported pixelclocks are defined by the phy configurations we
have. Also it can't support modes that require doubled clocks. If the
variant has a phy reference clock we can additionally validate against VESA
DMT'srecommendations.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - rename inno_mode_valid -> inno_hdmi_display_mode_valid
 - fixed max_tolerance calculation
 - use abs_diff() instead of abs()
 - call in inno_hdmi_display_mode_valid in atomic_check

 drivers/gpu/drm/rockchip/inno_hdmi.c | 42 ++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 792e5fad09bf..14473ca96e0f 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,6 +26,8 @@
 
 #include "inno_hdmi.h"
 
+#define INNO_HDMI_MIN_TMDS_CLOCK  25000000U
+
 struct inno_hdmi_phy_config {
 	unsigned long pixelclock;
 	u8 pre_emphasis;
@@ -548,6 +550,38 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	return 0;
 }
 
+static enum drm_mode_status inno_hdmi_display_mode_valid(struct inno_hdmi *hdmi,
+							 struct drm_display_mode *mode)
+{
+	unsigned long mpixelclk, max_tolerance;
+	long rounded_refclk;
+
+	/* No support for double-clock modes */
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+		return MODE_BAD;
+
+	mpixelclk = mode->clock * 1000;
+
+	if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
+		return MODE_CLOCK_LOW;
+
+	if (inno_hdmi_find_phy_config(hdmi, mpixelclk) < 0)
+		return MODE_CLOCK_HIGH;
+
+	if (hdmi->refclk) {
+		rounded_refclk = clk_round_rate(hdmi->refclk, mpixelclk);
+		if (rounded_refclk < 0)
+			return MODE_BAD;
+
+		/* Vesa DMT standard mentions +/- 0.5% max tolerance */
+		max_tolerance = mpixelclk / 200;
+		if (abs_diff((unsigned long)rounded_refclk, mpixelclk) > max_tolerance)
+			return MODE_NOCLOCK;
+	}
+
+	return MODE_OK;
+}
+
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 				     struct drm_atomic_state *state)
 {
@@ -581,11 +615,13 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 			       struct drm_connector_state *conn_state)
 {
 	struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	s->output_mode = ROCKCHIP_OUT_MODE_P888;
 	s->output_type = DRM_MODE_CONNECTOR_HDMIA;
 
-	return 0;
+	return  inno_hdmi_display_mode_valid(hdmi,
+				&crtc_state->adjusted_mode) == MODE_OK ? 0 : -EINVAL;
 }
 
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
@@ -626,7 +662,9 @@ static enum drm_mode_status
 inno_hdmi_connector_mode_valid(struct drm_connector *connector,
 			       struct drm_display_mode *mode)
 {
-	return MODE_OK;
+	struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
+
+	return  inno_hdmi_display_mode_valid(hdmi, mode);
 }
 
 static int
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:38 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:38 +0100
Subject: [PATCH v2 27/27] ARM: dts: rockchip: Enable HDMI output for XPI-3128
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-28-knaerzche@gmail.com>

Add an hdmi-connector node and enable the hdmi, display-subsystem and vop
nodes.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index 03a97881519a..21c1678f4e91 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -47,6 +47,17 @@ dc_5v: dc-5v-regulator {
 		regulator-boot-on;
 	};
 
+	hdmi-connnector {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_connector_in: endpoint {
+				remote-endpoint = <&hdmi_connector_out>;
+			};
+		};
+	};
+
 	/*
 	 * This is a vbus-supply, which also supplies the GL852G usb hub,
 	 * thus has to be always-on
@@ -239,6 +250,10 @@ &cpu0 {
 	cpu-supply = <&vdd_arm>;
 };
 
+&display_subsystem {
+	status = "okay";
+};
+
 &emmc {
 	bus-width = <8>;
 	vmmc-supply = <&vcc_io>;
@@ -328,6 +343,16 @@ &gpu {
 	status = "okay";
 };
 
+&hdmi {
+	status = "okay";
+};
+
+&hdmi_out {
+	hdmi_connector_out: endpoint {
+		remote-endpoint = <&hdmi_connector_in>;
+	};
+};
+
 &mdio {
 	phy0: ethernet-phy at 1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
@@ -423,3 +448,7 @@ &usb2phy_host {
 &usb2phy_otg {
 	status = "okay";
 };
+
+&vop {
+	status = "okay";
+};
-- 
2.43.0



From knaerzche at gmail.com  Sat Dec 16 08:26:36 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 16 Dec 2023 17:26:36 +0100
Subject: [PATCH v2 25/27] ARM: dts: rockchip: Add display subsystem for RK3128
In-Reply-To: <20231216162639.125215-1-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
Message-ID: <20231216162639.125215-26-knaerzche@gmail.com>

Add vop and display-subsystem nodes to RK3128's device tree.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

 arch/arm/boot/dts/rockchip/rk3128.dtsi | 27 ++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index e2264c40b924..1a3bc8b2bc6e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -115,6 +115,12 @@ opp-1200000000 {
 		};
 	};
 
+	display_subsystem: display-subsystem {
+		compatible = "rockchip,display-subsystem";
+		ports = <&vop_out>;
+		status = "disabled";
+	};
+
 	gpu_opp_table: opp-table-1 {
 		compatible = "operating-points-v2";
 
@@ -246,6 +252,27 @@ power-domain at RK3128_PD_GPU {
 		};
 	};
 
+	vop: vop at 1010e000 {
+		compatible = "rockchip,rk3126-vop";
+		reg = <0x1010e000 0x300>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru ACLK_LCDC0>, <&cru DCLK_VOP>,
+			 <&cru HCLK_LCDC0>;
+		clock-names = "aclk_vop", "dclk_vop",
+			      "hclk_vop";
+		resets = <&cru SRST_VOP_A>, <&cru SRST_VOP_H>,
+			 <&cru SRST_VOP_D>;
+		reset-names = "axi", "ahb",
+			      "dclk";
+		power-domains = <&power RK3128_PD_VIO>;
+		status = "disabled";
+
+		vop_out: port {
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	qos_gpu: qos at 1012d000 {
 		compatible = "rockchip,rk3128-qos", "syscon";
 		reg = <0x1012d000 0x20>;
-- 
2.43.0



From konrad.dybcio at linaro.org  Sat Dec 16 10:39:55 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Sat, 16 Dec 2023 19:39:55 +0100
Subject: [PATCH v2 1/3] iommu/msm-iommu: don't limit the driver too much
In-Reply-To: <20231216162700.863456-2-dmitry.baryshkov@linaro.org>
References: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>
 <20231216162700.863456-2-dmitry.baryshkov@linaro.org>
Message-ID: <3160e0b5-7209-46ea-8ff5-48daefcd2d89@linaro.org>

On 16.12.2023 17:26, Dmitry Baryshkov wrote:
> In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
> driver just to those machines. Allow it to be built for any 32-bit
> Qualcomm platform (ARCH_QCOM).
> 
> Acked-by: Robin Murphy <robin.murphy at arm.com>
> Acked-by: Joerg Roedel <jroedel at suse.de>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio at linaro.org>

Konrad


From quic_omprsing at quicinc.com  Sat Dec 16 10:59:56 2023
From: quic_omprsing at quicinc.com (Om Prakash Singh)
Date: Sun, 17 Dec 2023 00:29:56 +0530
Subject: [PATCH v6 02/13] firmware: qcom: add a dedicated TrustZone buffer
 allocator
In-Reply-To: <20231127141600.20929-3-brgl@bgdev.pl>
References: <20231127141600.20929-1-brgl@bgdev.pl>
 <20231127141600.20929-3-brgl@bgdev.pl>
Message-ID: <aec86af5-1170-4fc4-9986-879c61fc8633@quicinc.com>



On 11/27/2023 7:45 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> 
> We have several SCM calls that require passing buffers to the TrustZone
> on top of the SMC core which allocates memory for calls that require
> more than 4 arguments.
> 
> Currently every user does their own thing which leads to code
> duplication. Many users call dma_alloc_coherent() for every call which
> is terribly unperformant (speed- and size-wise).
> 
> Provide a set of library functions for creating and managing pool of
> memory which is suitable for sharing with the TrustZone, that is:
> page-aligned, contiguous and non-cachable as well as provides a way of
> mapping of kernel virtual addresses to physical space.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> Reviewed-by: Andrew Halaney <ahalaney at redhat.com>
> Tested-by: Andrew Halaney <ahalaney at redhat.com> # sc8280xp-lenovo-thinkpad-x13s
> ---
>   drivers/firmware/qcom/Kconfig            |  19 ++
>   drivers/firmware/qcom/Makefile           |   1 +
>   drivers/firmware/qcom/qcom_tzmem.c       | 302 +++++++++++++++++++++++
>   drivers/firmware/qcom/qcom_tzmem.h       |  13 +
>   include/linux/firmware/qcom/qcom_tzmem.h |  28 +++
>   5 files changed, 363 insertions(+)
>   create mode 100644 drivers/firmware/qcom/qcom_tzmem.c
>   create mode 100644 drivers/firmware/qcom/qcom_tzmem.h
>   create mode 100644 include/linux/firmware/qcom/qcom_tzmem.h
> 
> diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
> index 3f05d9854ddf..b80269a28224 100644
> --- a/drivers/firmware/qcom/Kconfig
> +++ b/drivers/firmware/qcom/Kconfig
> @@ -9,6 +9,25 @@ menu "Qualcomm firmware drivers"
>   config QCOM_SCM
>   	tristate
>   
> +config QCOM_TZMEM
> +	tristate
> +
> +choice
> +	prompt "TrustZone interface memory allocator mode"
> +	default QCOM_TZMEM_MODE_DEFAULT
> +	help
> +	  Selects the mode of the memory allocator providing memory buffers of
> +	  suitable format for sharing with the TrustZone. If in doubt, select
> +	  'Default'.
> +
> +config QCOM_TZMEM_MODE_DEFAULT
> +	bool "Default"
> +	help
> +	  Use the default allocator mode. The memory is page-aligned, non-cachable
> +	  and contiguous.
> +
> +endchoice
> +
>   config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
>   	bool "Qualcomm download mode enabled by default"
>   	depends on QCOM_SCM
> diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qcom/Makefile
> index c9f12ee8224a..0be40a1abc13 100644
> --- a/drivers/firmware/qcom/Makefile
> +++ b/drivers/firmware/qcom/Makefile
> @@ -5,5 +5,6 @@
>   
>   obj-$(CONFIG_QCOM_SCM)		+= qcom-scm.o
>   qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
> +obj-$(CONFIG_QCOM_TZMEM)	+= qcom_tzmem.o
>   obj-$(CONFIG_QCOM_QSEECOM)	+= qcom_qseecom.o
>   obj-$(CONFIG_QCOM_QSEECOM_UEFISECAPP) += qcom_qseecom_uefisecapp.o
> diff --git a/drivers/firmware/qcom/qcom_tzmem.c b/drivers/firmware/qcom/qcom_tzmem.c
> new file mode 100644
> index 000000000000..44a062f2abd4
> --- /dev/null
> +++ b/drivers/firmware/qcom/qcom_tzmem.c
> @@ -0,0 +1,302 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Memory allocator for buffers shared with the TrustZone.
> + *
> + * Copyright (C) 2023 Linaro Ltd.
> + */
> +
> +#include <linux/bug.h>
> +#include <linux/cleanup.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/err.h>
> +#include <linux/firmware/qcom/qcom_tzmem.h>
> +#include <linux/genalloc.h>
> +#include <linux/gfp.h>
> +#include <linux/mm.h>
> +#include <linux/radix-tree.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>
> +
> +#include "qcom_tzmem.h"
> +
> +struct qcom_tzmem_pool {
> +	void *vbase;
> +	dma_addr_t pbase;
> +	size_t size;
> +	struct gen_pool *pool;
> +	void *priv;
priv is not being using any where.
> +};
> +
> +struct qcom_tzmem_chunk {
> +	phys_addr_t paddr;
> +	size_t size;
> +	struct qcom_tzmem_pool *owner;
Is it okay to use "pool" for this data member?
> +};
> +
> +static struct device *qcom_tzmem_dev;
> +static RADIX_TREE(qcom_tzmem_chunks, GFP_ATOMIC);
> +static DEFINE_SPINLOCK(qcom_tzmem_chunks_lock);
> +
> +#if IS_ENABLED(CONFIG_QCOM_TZMEM_MODE_DEFAULT)
> +
> +static int qcom_tzmem_init(void)
> +{
> +	return 0;
> +}
> +
> +static int qcom_tzmem_init_pool(struct qcom_tzmem_pool *pool)
> +{
> +	return 0;
> +}
> +
> +static void qcom_tzmem_cleanup_pool(struct qcom_tzmem_pool *pool)
> +{
> +
> +}
> +
> +#endif /* CONFIG_QCOM_TZMEM_MODE_DEFAULT */
> +
> +/**
> + * qcom_tzmem_pool_new() - Create a new TZ memory pool.
> + * @size: Size of the new pool in bytes.
> + *
> + * Create a new pool of memory suitable for sharing with the TrustZone.
> + *
> + * Must not be used in atomic context.
> + *
> + * Returns:
> + * New memory pool address or ERR_PTR() on error.
> + */
> +struct qcom_tzmem_pool *qcom_tzmem_pool_new(size_t size)
> +{
> +	struct qcom_tzmem_pool *pool;
> +	int ret = -ENOMEM;
> +
> +	if (!size)
> +		return ERR_PTR(-EINVAL);
> +
> +	size = PAGE_ALIGN(size);
> +
> +	pool = kzalloc(sizeof(*pool), GFP_KERNEL);
> +	if (!pool)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pool->size = size;
> +
> +	pool->vbase = dma_alloc_coherent(qcom_tzmem_dev, size, &pool->pbase,
> +					 GFP_KERNEL);
> +	if (!pool->vbase)
> +		goto err_kfree_pool;
> +
> +	pool->pool = gen_pool_create(PAGE_SHIFT, -1);
> +	if (!pool)
> +		goto err_dma_free;
> +
> +	gen_pool_set_algo(pool->pool, gen_pool_best_fit, NULL);
> +
> +	ret = gen_pool_add_virt(pool->pool, (unsigned long)pool->vbase,
> +				(phys_addr_t)pool->pbase, size, -1);
> +	if (ret)
> +		goto err_destroy_genpool;
> +
> +	ret = qcom_tzmem_init_pool(pool);
> +	if (ret)
> +		goto err_destroy_genpool;
> +
> +	return pool;
> +
> +err_destroy_genpool:
> +	gen_pool_destroy(pool->pool);
> +err_dma_free:
> +	dma_free_coherent(qcom_tzmem_dev, size, pool->vbase, pool->pbase);
> +err_kfree_pool:
> +	kfree(pool);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(qcom_tzmem_pool_new);
> +
> +/**
> + * qcom_tzmem_pool_free() - Destroy a TZ memory pool and free all resources.
> + * @pool: Memory pool to free.
> + *
> + * Must not be called if any of the allocated chunks has not been freed.
> + * Must not be used in atomic context.
> + */
> +void qcom_tzmem_pool_free(struct qcom_tzmem_pool *pool)
> +{
> +	struct qcom_tzmem_chunk *chunk;
> +	struct radix_tree_iter iter;
> +	bool non_empty = false;
> +	void __rcu **slot;
> +
> +	if (!pool)
> +		return;
> +
> +	qcom_tzmem_cleanup_pool(pool);
> +
> +	scoped_guard(spinlock_irqsave, &qcom_tzmem_chunks_lock) {
> +		radix_tree_for_each_slot(slot, &qcom_tzmem_chunks, &iter, 0) {
> +			chunk = radix_tree_deref_slot_protected(slot,
> +						&qcom_tzmem_chunks_lock);
> +
> +			if (chunk->owner == pool)
> +				non_empty = true;
> +		}
> +	}
> +
> +	WARN(non_empty, "Freeing TZ memory pool with memory still allocated");
> +
> +	gen_pool_destroy(pool->pool);
> +	dma_free_coherent(qcom_tzmem_dev, pool->size, pool->vbase, pool->pbase);
> +	kfree(pool);
> +}
> +EXPORT_SYMBOL_GPL(qcom_tzmem_pool_free);
> +
> +static void devm_qcom_tzmem_pool_free(void *data)
> +{
> +	struct qcom_tzmem_pool *pool = data;
> +
> +	qcom_tzmem_pool_free(pool);
> +}
> +
> +/**
> + * devm_qcom_tzmem_pool_new() - Managed variant of qcom_tzmem_pool_new().
> + * @dev: Device managing this resource.
> + * @size: Size of the pool in bytes.
> + *
> + * Must not be used in atomic context.
> + *
> + * Returns:
> + * Address of the managed pool or ERR_PTR() on failure.
> + */
> +struct qcom_tzmem_pool *
> +devm_qcom_tzmem_pool_new(struct device *dev, size_t size)
> +{
> +	struct qcom_tzmem_pool *pool;
> +	int ret;
> +
> +	pool = qcom_tzmem_pool_new(size);
> +	if (IS_ERR(pool))
> +		return pool;
> +
> +	ret = devm_add_action_or_reset(dev, devm_qcom_tzmem_pool_free, pool);
> +	if (ret)
> +		return ERR_PTR(ret);
> +
> +	return pool;
> +}
> +
> +/**
> + * qcom_tzmem_alloc() - Allocate a memory chunk suitable for sharing with TZ.
> + * @pool: TZ memory pool from which to allocate memory.
> + * @size: Number of bytes to allocate.
> + * @gfp: GFP flags.
> + *
> + * Can be used in any context.
> + *
> + * Returns:
> + * Address of the allocated buffer or NULL if no more memory can be allocated.
> + * The buffer must be released using qcom_tzmem_free().
> + */
> +void *qcom_tzmem_alloc(struct qcom_tzmem_pool *pool, size_t size, gfp_t gfp)
> +{
> +	struct qcom_tzmem_chunk *chunk;
> +	unsigned long vaddr;
> +	int ret;
> +
> +	if (!size)
> +		return NULL;
> +
> +	size = PAGE_ALIGN(size);
> +
> +	chunk = kzalloc(sizeof(*chunk), gfp);
> +	if (!chunk)
> +		return NULL;
> +
> +	vaddr = gen_pool_alloc(pool->pool, size);
> +	if (!vaddr) {
> +		kfree(chunk);
> +		return NULL;
> +	}
> +
> +	chunk->paddr = gen_pool_virt_to_phys(pool->pool, vaddr);
> +	chunk->size = size;
> +	chunk->owner = pool;
> +
> +	scoped_guard(spinlock_irqsave, &qcom_tzmem_chunks_lock) {
> +		ret = radix_tree_insert(&qcom_tzmem_chunks, vaddr, chunk);
> +		if (ret) {
> +			gen_pool_free(pool->pool, vaddr, size);
> +			kfree(chunk);
> +			return NULL;
> +		}
> +	}
> +
> +	return (void *)vaddr;
> +}
> +EXPORT_SYMBOL_GPL(qcom_tzmem_alloc);
> +
> +/**
> + * qcom_tzmem_free() - Release a buffer allocated from a TZ memory pool.
> + * @vaddr: Virtual address of the buffer.
> + *
> + * Can be used in any context.
> + */
> +void qcom_tzmem_free(void *vaddr)
> +{
> +	struct qcom_tzmem_chunk *chunk;
> +
> +	scoped_guard(spinlock_irqsave, &qcom_tzmem_chunks_lock)
> +		chunk = radix_tree_delete_item(&qcom_tzmem_chunks,
> +					       (unsigned long)vaddr, NULL);
> +
> +	if (!chunk) {
> +		WARN(1, "Virtual address %p not owned by TZ memory allocator",
> +		     vaddr);
> +		return;
> +	}
> +
> +	gen_pool_free(chunk->owner->pool, (unsigned long)vaddr, chunk->size);
> +	kfree(chunk);
> +}
> +EXPORT_SYMBOL_GPL(qcom_tzmem_free);
> +
> +/**
> + * qcom_tzmem_to_phys() - Map the virtual address of a TZ buffer to physical.
> + * @vaddr: Virtual address of the buffer allocated from a TZ memory pool.
> + *
> + * Can be used in any context. The address must have been returned by a call
> + * to qcom_tzmem_alloc().
> + *
> + * Returns:
> + * Physical address of the buffer.
> + */
> +phys_addr_t qcom_tzmem_to_phys(void *vaddr)
> +{
> +	struct qcom_tzmem_chunk *chunk;
> +
> +	guard(spinlock_irqsave)(&qcom_tzmem_chunks_lock);
> +
> +	chunk = radix_tree_lookup(&qcom_tzmem_chunks, (unsigned long)vaddr);
> +	if (!chunk)
> +		return 0;
> +
> +	return chunk->paddr;
> +}
> +EXPORT_SYMBOL_GPL(qcom_tzmem_to_phys);
> +
> +int qcom_tzmem_enable(struct device *dev)
> +{
> +	if (qcom_tzmem_dev)
> +		return -EBUSY;
> +
> +	qcom_tzmem_dev = dev;
> +
> +	return qcom_tzmem_init();
> +}
> +EXPORT_SYMBOL_GPL(qcom_tzmem_enable);
> +
> +MODULE_DESCRIPTION("TrustZone memory allocator for Qualcomm firmware drivers");
> +MODULE_AUTHOR("Bartosz Golaszewski <bartosz.golaszewski at linaro.org>");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/firmware/qcom/qcom_tzmem.h b/drivers/firmware/qcom/qcom_tzmem.h
> new file mode 100644
> index 000000000000..f82f5dc5b7b1
> --- /dev/null
> +++ b/drivers/firmware/qcom/qcom_tzmem.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + */
> +
> +#ifndef __QCOM_TZMEM_PRIV_H
> +#define __QCOM_TZMEM_PRIV_H
> +
> +struct device;
> +
> +int qcom_tzmem_enable(struct device *dev);
> +
> +#endif /* __QCOM_TZMEM_PRIV_H */
> diff --git a/include/linux/firmware/qcom/qcom_tzmem.h b/include/linux/firmware/qcom/qcom_tzmem.h
> new file mode 100644
> index 000000000000..8e7fddab8cb4
> --- /dev/null
> +++ b/include/linux/firmware/qcom/qcom_tzmem.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + */
> +
> +#ifndef __QCOM_TZMEM_H
> +#define __QCOM_TZMEM_H
> +
> +#include <linux/cleanup.h>
> +#include <linux/gfp.h>
> +#include <linux/types.h>
> +
> +struct device;
> +struct qcom_tzmem_pool;
qcom_tzmem_pool stucture definition should be moved to header file.
> +
> +struct qcom_tzmem_pool *qcom_tzmem_pool_new(size_t size);
> +void qcom_tzmem_pool_free(struct qcom_tzmem_pool *pool);
> +struct qcom_tzmem_pool *
> +devm_qcom_tzmem_pool_new(struct device *dev, size_t size);
> +
> +void *qcom_tzmem_alloc(struct qcom_tzmem_pool *pool, size_t size, gfp_t gfp);
> +void qcom_tzmem_free(void *ptr);
> +
> +DEFINE_FREE(qcom_tzmem, void *, if (_T) qcom_tzmem_free(_T));
> +
> +phys_addr_t qcom_tzmem_to_phys(void *ptr);
> +
> +#endif /* __QCOM_TZMEM */


From emil.renner.berthing at canonical.com  Sat Dec 16 11:24:40 2023
From: emil.renner.berthing at canonical.com (Emil Renner Berthing)
Date: Sat, 16 Dec 2023 11:24:40 -0800
Subject: [PATCH v2 12/12] [UNTESTED] riscv: dts: starfive:
 beaglev-starlight: Enable gmac
In-Reply-To: <698fbb5d-0750-4f2a-857f-5429e5f589f9@collabora.com>
References: <20231029042712.520010-1-cristian.ciocaltea@collabora.com>
 <20231029042712.520010-13-cristian.ciocaltea@collabora.com>
 <CAJM55Z9e=vjGKNnmURN15mvXo2bVd3igBA-3puF9q7eh5hiP+A@mail.gmail.com>
 <2f06ce36-0dc1-495e-b6a6-318951a53e8d@collabora.com> <698fbb5d-0750-4f2a-857f-5429e5f589f9@collabora.com>
Message-ID: <CAJM55Z-e8mkjac-nCF9_w6EmMVbL9ued0mAcjwTMF=pKDLkMsA@mail.gmail.com>

Cristian Ciocaltea wrote:
> On 11/28/23 02:40, Cristian Ciocaltea wrote:
> > On 11/26/23 23:10, Emil Renner Berthing wrote:
> >> Cristian Ciocaltea wrote:
> >>> The BeagleV Starlight SBC uses a Microchip KSZ9031RNXCA PHY supporting
> >>> RGMII-ID.
> >>>
>
> [...]
>
> >> You've alse removed the phy reset gpio on the Starlight board:
> >>
> >>   snps,reset-gpios = <&gpio 63 GPIO_ACTIVE_LOW>
> >>
> >> Why?
> >
> > I missed this in v1 as the gmac handling was done exclusively in
> > jh7100-common. Thanks for noticing!
>
> Hi Emil,
>
> I think the reset doesn't actually trigger because "snps,reset-gpios" is
> not a valid property, it should have been "snps,reset-gpio" (without the
> trailing "s").
>
> However, this seems to be deprecated now, and the recommended approach
> would be to define the reset gpio in the phy node, which I did in [1].
>
> Hopefully this won't cause any unexpected behaviour. Otherwise we should
> probably simply drop it.
>
> [1]: https://lore.kernel.org/lkml/20231215204050.2296404-8-cristian.ciocaltea at collabora.com/

Oh, nice catch! With your v3 patches the Starlight board still works fine and
GPIO63 is correctly grabbed and used for "PHY reset".

/Emil


From emil.renner.berthing at canonical.com  Sat Dec 16 11:38:53 2023
From: emil.renner.berthing at canonical.com (Emil Renner Berthing)
Date: Sat, 16 Dec 2023 11:38:53 -0800
Subject: [PATCH v3 5/9] riscv: dts: starfive: jh7100-common: Setup pinmux
 and enable gmac
In-Reply-To: <20231215204050.2296404-6-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com> <20231215204050.2296404-6-cristian.ciocaltea@collabora.com>
Message-ID: <CAJM55Z-bg0EGPaLHtxcu2AzqN59zfuiT0eE7oCShrx7dG_QK1g@mail.gmail.com>

Cristian Ciocaltea wrote:
> Add pinmux configuration for DWMAC found on the JH7100 based boards and
> enable the related DT node, providing a basic PHY configuration.
>
> Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
> Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
> ---
>  .../boot/dts/starfive/jh7100-common.dtsi      | 85 +++++++++++++++++++
>  1 file changed, 85 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> index 42fb61c36068..5cafe8f5c2e7 100644
> --- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> @@ -72,7 +72,92 @@ wifi_pwrseq: wifi-pwrseq {
>  	};
>  };
>
> +&gmac {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&gmac_pins>;
> +	phy-mode = "rgmii-id";
> +	phy-handle = <&phy>;

I'm not sure if it's a generic policy or not, but I don't really like adding a
reference to a non-existant node here. I'd move this property to the board
files where the phy node is actually defined.

/Emil


From sigmaris at gmail.com  Sat Dec 16 13:21:34 2023
From: sigmaris at gmail.com (Hugh Cole-Baker)
Date: Sat, 16 Dec 2023 21:21:34 +0000
Subject: [PATCH] arm64: dts: rockchip: Support poweroff on NanoPC-T6
Message-ID: <20231216212134.23314-1-sigmaris@gmail.com>

The RK806 on the NanoPC-T6 can be used to power on/off the whole board.
Mark it as the system power controller.

Signed-off-by: Hugh Cole-Baker <sigmaris at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
index 612107615e66..0fc48fb0d34d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
@@ -569,6 +569,8 @@ pmic at 0 {
 		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
 			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
 
+		system-power-controller;
+
 		vcc1-supply = <&vcc4v0_sys>;
 		vcc2-supply = <&vcc4v0_sys>;
 		vcc3-supply = <&vcc4v0_sys>;
-- 
2.39.3 (Apple Git-145)



From kw at linux.com  Sat Dec 16 13:31:21 2023
From: kw at linux.com (Krzysztof =?utf-8?Q?Wilczy=C5=84ski?=)
Date: Sun, 17 Dec 2023 06:31:21 +0900
Subject: [PATCH v5 RESEND 0/4] increase ecam size value to discover 256
 buses during
In-Reply-To: <20231016051102.1180432-1-thippeswamy.havalige@amd.com>
References: <20231016051102.1180432-1-thippeswamy.havalige@amd.com>
Message-ID: <20231216213121.GB3302836@rocinante>

Hello,

> Current driver is supports up to 16 buses. The following code fixes 
> to support up to 256 buses.
> 
> update "NWL_ECAM_VALUE_DEFAULT " to 16  can access up to 256MB ECAM
> region to detect 256 buses.
> 
> Update ecam size to 256MB in device tree binding example.
> 
> Remove unwanted code.

Applied to controller/xilinx-ecam, thank you!

[01/04] PCI: xilinx-nwl: Remove redundant code that sets Type 1 header fields
        https://git.kernel.org/pci/pci/c/a2492ff1fcb9
[02/04] dt-bindings: PCI: xilinx-nwl: Modify ECAM size in the DT example
        https://git.kernel.org/pci/pci/c/22f38a244273
[03/04] PCI: xilinx-nwl: Rename the NWL_ECAM_VALUE_DEFAULT macro
        https://git.kernel.org/pci/pci/c/177692115f6f
[04/04] PCI: xilinx-nwl: Modify ECAM size to enable support for 256 buses
        https://git.kernel.org/pci/pci/c/2fccd11518f1

	Krzysztof


From kw at linux.com  Sat Dec 16 13:32:34 2023
From: kw at linux.com (Krzysztof =?utf-8?Q?Wilczy=C5=84ski?=)
Date: Sun, 17 Dec 2023 06:32:34 +0900
Subject: [PATCH v7 RESEND 0/3] Add support for Xilinx XDMA Soft IP as
 Root Port.
In-Reply-To: <20231003173453.938190-1-thippeswamy.havalige@amd.com>
References: <20231003173453.938190-1-thippeswamy.havalige@amd.com>
Message-ID: <20231216213234.GC3302836@rocinante>

Hello,

> This series of patch add support for Xilinx XDMA Soft IP as Root Port.
> 
> The Xilinx XDMA Soft IP support's 32 bit and 64bit BAR's.
> As Root Port it supports MSI and legacy interrupts.
> 
> For code reusability existing CPM4 error interrupt bits are moved to
> common header.

Applied to controller/xilinx-xdma, thank you!

[01/03] PCI: xilinx-cpm: Move IRQ definitions to a common header
        https://git.kernel.org/pci/pci/c/a977ee945e94
[02/03] dt-bindings: PCI: xilinx-xdma: Add schemas for Xilinx XDMA PCIe Root Port Bridge
        https://git.kernel.org/pci/pci/c/4ae1cd7d4be2
[03/03] PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver
        https://git.kernel.org/pci/pci/c/8d786149d78c

	Krzysztof


From sboyd at kernel.org  Sat Dec 16 17:21:08 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Sat, 16 Dec 2023 17:21:08 -0800
Subject: [PATCH RESEND v2 2/2] drivers: clk: zynqmp: update divider round rate logic
In-Reply-To: <20231129112916.23125-3-jay.buddhabhatti@amd.com>
References: <20231129112916.23125-1-jay.buddhabhatti@amd.com> <20231129112916.23125-3-jay.buddhabhatti@amd.com>
Message-ID: <752b98e31a2b9e4cf0aec860f158c53c.sboyd@kernel.org>

Quoting Jay Buddhabhatti (2023-11-29 03:29:16)
> Currently zynqmp divider round rate is considering single parent and
> calculating rate and parent rate accordingly. But if divider clock flag
> is set to SET_RATE_PARENT then its not trying to traverse through all
> parent rate and not selecting best parent rate from that. So use common
> divider_round_rate() which is traversing through all clock parents and
> its rate and calculating proper parent rate.
> 
> Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti at amd.com>
> ---

Applied to clk-next


From sboyd at kernel.org  Sat Dec 16 17:21:19 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Sat, 16 Dec 2023 17:21:19 -0800
Subject: [PATCH RESEND v2 1/2] drivers: clk: zynqmp: calculate closest mux rate
In-Reply-To: <20231129112916.23125-2-jay.buddhabhatti@amd.com>
References: <20231129112916.23125-1-jay.buddhabhatti@amd.com> <20231129112916.23125-2-jay.buddhabhatti@amd.com>
Message-ID: <3ddba76f5f44a7b32c5852094667d189.sboyd@kernel.org>

Quoting Jay Buddhabhatti (2023-11-29 03:29:15)
> Currently zynqmp clock driver is not calculating closest mux rate and
> because of that Linux is not setting proper frequency for CPU and
> not able to set given frequency for dynamic frequency scaling.
> 
> E.g., In current logic initial acpu clock parent and frequency as below
> apll1                  0    0    0  2199999978    0     0  50000      Y
>     acpu0_mux          0    0    0  2199999978    0     0  50000      Y
>         acpu0_idiv1    0    0    0  2199999978    0     0  50000      Y
>             acpu0      0    0    0  2199999978    0     0  50000      Y
> 
> After changing acpu frequency to 549999994 Hz using CPU freq scaling its
> selecting incorrect parent which is not closest frequency.
> rpll_to_xpd            0    0    0  1599999984    0     0  50000      Y
>     acpu0_mux          0    0    0  1599999984    0     0  50000      Y
>         acpu0_div1     0    0    0   533333328    0     0  50000      Y
>             acpu0      0    0    0   533333328    0     0  50000      Y
> 
> Parent should remain same since 549999994 = 2199999978 / 4.
> 
> So use __clk_mux_determine_rate_closest() generic function to calculate
> closest rate for mux clock. After this change its selecting correct
> parent and correct clock rate.
> apll1                  0    0    0  2199999978    0     0  50000      Y
>     acpu0_mux          0    0    0  2199999978    0     0  50000      Y
>         acpu0_div1     0    0    0   549999995    0     0  50000      Y
>             acpu0      0    0    0   549999995    0     0  50000      Y
> 
> Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti at amd.com>
> ---

Applied to clk-next


From thiago.bauermann at linaro.org  Sat Dec 16 18:12:37 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Sat, 16 Dec 2023 23:12:37 -0300
Subject: [PATCH v7 36/39] selftests/arm64: Add GCS signal tests
In-Reply-To: <20231122-arm64-gcs-v7-36-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-36-201c483bd775@kernel.org>
Message-ID: <875y0x7f1m.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

> diff --git a/tools/testing/selftests/arm64/signal/testcases/gcs_exception_fault.c b/tools/testing/selftests/arm64/signal/testcases/gcs_exception_fault.c
> new file mode 100644
> index 000000000000..532d533592a1
> --- /dev/null
> +++ b/tools/testing/selftests/arm64/signal/testcases/gcs_exception_fault.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 ARM Limited
> + */
> +
> +#include <errno.h>
> +#include <signal.h>
> +#include <unistd.h>
> +
> +#include <sys/mman.h>
> +#include <sys/prctl.h>
> +
> +#include "test_signals_utils.h"
> +#include "testcases.h"
> +
> +/* This should be includable from some standard header, but which? */
> +#ifndef SEGV_CPERR
> +#define SEGV_CPERR 10
> +#endif

One suggestion is include/uapi/asm-generic/siginfo.h. It already has
SEGV_MTEAERR and SEGV_MTESERR, as well as si_codes specific to other
arches.

>From there, it should find its way to glibc's
sysdeps/unix/sysv/linux/bits/siginfo-consts.h.

> +static int gcs_regs(struct tdescr *td, siginfo_t *si, ucontext_t *uc)
> +{
> +	size_t offset;
> +	struct _aarch64_ctx *head = GET_BUF_RESV_HEAD(context);
> +	struct gcs_context *gcs;
> +	unsigned long expected, gcspr;
> +	int ret;
> +
> +	ret = prctl(PR_GET_SHADOW_STACK_STATUS, &expected, 0, 0, 0);
> +	if (ret != 0) {
> +		fprintf(stderr, "Unable to query GCS status\n");
> +		return 1;
> +	}
> +
> +	/* We expect a cap to be added to the GCS in the signal frame */
> +	gcspr = get_gcspr_el0();
> +	gcspr -= 8;
> +	fprintf(stderr, "Expecting GCSPR_EL0 %lx\n", gcspr);
> +
> +	if (!get_current_context(td, &context.uc, sizeof(context))) {
> +		fprintf(stderr, "Failed getting context\n");
> +		return 1;
> +	}

At this point, before any function call is made, can the test check that
*(gcspr + 8) == 0? This would detect the issue I mentioned in
patch 24 of gcs_restore_signal() not zeroing the location of the cap.

> +	fprintf(stderr, "Got context\n");
> +
> +	head = get_header(head, GCS_MAGIC, GET_BUF_RESV_SIZE(context),
> +			  &offset);
> +	if (!head) {
> +		fprintf(stderr, "No GCS context\n");
> +		return 1;
> +	}
> +
> +	gcs = (struct gcs_context *)head;
> +
> +	/* Basic size validation is done in get_current_context() */
> +
> +	if (gcs->features_enabled != expected) {
> +		fprintf(stderr, "Features enabled %llx but expected %lx\n",
> +			gcs->features_enabled, expected);
> +		return 1;
> +	}
> +
> +	if (gcs->gcspr != gcspr) {
> +		fprintf(stderr, "Got GCSPR %llx but expected %lx\n",
> +			gcs->gcspr, gcspr);
> +		return 1;
> +	}

I suggest adding a new check here to ensure that gcs->reserved == 0.

> +	fprintf(stderr, "GCS context validated\n");
> +	td->pass = 1;
> +
> +	return 0;
> +}
> +
> +struct tdescr tde = {
> +	.name = "GCS basics",
> +	.descr = "Validate a GCS signal context",
> +	.feats_required = FEAT_GCS,
> +	.timeout = 3,
> +	.run = gcs_regs,
> +};
> diff --git a/tools/testing/selftests/arm64/signal/testcases/gcs_write_fault.c b/tools/testing/selftests/arm64/signal/testcases/gcs_write_fault.c
> new file mode 100644
> index 000000000000..126b1a294a29
> --- /dev/null
> +++ b/tools/testing/selftests/arm64/signal/testcases/gcs_write_fault.c
> @@ -0,0 +1,67 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 ARM Limited
> + */
> +
> +#include <errno.h>
> +#include <signal.h>
> +#include <unistd.h>
> +
> +#include <sys/mman.h>
> +#include <sys/prctl.h>
> +
> +#include "test_signals_utils.h"
> +#include "testcases.h"
> +
> +static uint64_t *gcs_page;
> +
> +#ifndef __NR_map_shadow_stack
> +#define __NR_map_shadow_stack 452
> +#endif
> +
> +static bool alloc_gcs(struct tdescr *td)
> +{
> +	long page_size = sysconf(_SC_PAGE_SIZE);
> +
> +	gcs_page = (void *)syscall(__NR_map_shadow_stack, 0,
> +				   page_size, 0);
> +	if (gcs_page == MAP_FAILED) {
> +		fprintf(stderr, "Failed to map %ld byte GCS: %d\n",
> +			page_size, errno);

This call is failing with EINVAL for me:

# timeout set to 45
# selftests: arm64/signal: gcs_write_fault
# # GCS write fault :: Normal writes to a GCS segfault
# Registered handlers for all signals.
# Detected MINSTKSIGSZ:4720
# Required Features: [ GCS ] supported
# Incompatible Features: [] absent
# Failed to map 4096 byte GCS: 22
# FAILED Testcase initialization.
# ==>> completed. FAIL(0)
not ok 11 selftests: arm64/signal: gcs_write_fault # exit=1

> +		return false;
> +	}
> +
> +	return true;
> +}

-- 
Thiago


From thiago.bauermann at linaro.org  Sat Dec 16 18:18:13 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Sat, 16 Dec 2023 23:18:13 -0300
Subject: [PATCH v7 34/39] kselftest/arm64: Add a GCS test program built
 with the system libc
In-Reply-To: <485b6454-135c-4dd4-b38e-8fb8a02779cd@sirena.org.uk>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
 <20231122-arm64-gcs-v7-34-201c483bd775@kernel.org>
 <875y1089i4.fsf@linaro.org>
 <485b6454-135c-4dd4-b38e-8fb8a02779cd@sirena.org.uk>
Message-ID: <871qbl7esa.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

>> Also, it's strange that the tests defined after map_gcs.stack_overflow
>> don't run when I execute this test program. I'm doing:
>
>> $ ./run_kselftest.sh -t arm64:libc-gcs
>
>> I.e., these tests aren't being run in my FVP:
>
>> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, too_small)
>> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_1)
>> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_2)
>> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_3)
>> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_4)
>> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_5)
>> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_6)
>> > +FIXTURE_VARIANT_ADD(map_invalid_gcs, unligned_7)
>> > +TEST_F(map_invalid_gcs, do_map)
>> > +FIXTURE_VARIANT_ADD(invalid_mprotect, exec)
>> > +FIXTURE_VARIANT_ADD(invalid_mprotect, bti)
>> > +FIXTURE_VARIANT_ADD(invalid_mprotect, exec_bti)
>> > +TEST_F(invalid_mprotect, do_map)
>> > +TEST_F(invalid_mprotect, do_map_read)
>
> I'm seeing all of those appearing.  I'm not sure what to say there -
> that's all kselftest framework stuff, I'd expect the framework to say
> something about what it's doing if it decides to skip and I can't think
> why it would decide to skip.

Thanks. I'll poke some more to see if I can figure out what's going on.

-- 
Thiago


From Frank.Li at nxp.com  Sat Dec 16 21:11:55 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:11:55 -0500
Subject: [PATCH v4 00/15] PCI: imx6: Clean up and add imx95 pci support
Message-ID: <20231217051210.754832-1-Frank.Li@nxp.com>

first 6 patches use drvdata: flags to simplify some switch-case code.
Improve maintaince and easy to read code.

Then add imx95 basic pci host function.

follow two patch do endpoint code clean up.
Then add imx95 basic endpont function.

Compared with v2, added EP function support and some fixes,  please change
notes at each patches.

dt-binding pass pcie node:

pcie0: pcie at 4c300000 {
                        compatible = "fsl,imx95-pcie";
                        reg = <0 0x4c300000 0 0x40000>,
                                <0 0x4c360000 0 0x10000>,
                                <0 0x4c340000 0 0x20000>,
                                <0 0x60100000 0 0xfe00000>;
                        reg-names = "dbi", "atu", "app", "config";
                        #address-cells = <3>;
                        #size-cells = <2>;
                        device_type = "pci";
                        linux,pci-domain = <0>;
                        bus-range = <0x00 0xff>;
                        ranges = <0x81000000 0x0 0x00000000 0x0 0x6ff00000 0 0x00100000>,
                                 <0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000>;
                        num-lanes = <1>;
                        num-viewport = <8>;
                        interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
                        interrupt-names = "msi";
                        #interrupt-cells = <1>;
                        interrupt-map-mask = <0 0 0 0x7>;
                        interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 2 &gic 0 0 GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 3 &gic 0 0 GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 4 &gic 0 0 GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
                        fsl,max-link-speed = <3>;
                        clocks = <&scmi_clk IMX95_CLK_HSIO>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                 <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux";
                        assigned-clocks =<&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                         <&scmi_clk IMX95_CLK_HSIOPLL>,
                                         <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        assigned-clock-rates = <3600000000>, <100000000>, <10000000>;
                        assigned-clock-parents = <0>, <0>,
                                                 <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
                        power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
                        /* 0x30~0x37 stream id for pci0 */
                        /*
                         * iommu-map = <0x000 &apps_smmu 0x30 0x1>,
                         * <0x100 &apps_smmu 0x31 0x1>;
                         */
                        status = "disabled";
                };

pcie1: pcie-ep at 4c380000 {
                        compatible = "fsl,imx95-pcie-ep";
                        reg = <0 0x4c380000 0 0x20000>,
                              <0 0x4c3e0000 0 0x1000>,
                              <0 0x4c3a0000 0 0x1000>,
                              <0 0x4c3c0000 0 0x10000>,
                              <0 0x4c3f0000 0 0x10000>,
                              <0xa 0 1 0>;
                        reg-names = "dbi", "atu", "dbi2", "app", "dma", "addr_space";
                        interrupts = <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>;
                        interrupt-names = "dma";
                        fsl,max-link-speed = <3>;
                        clocks = <&scmi_clk IMX95_CLK_HSIO>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                 <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux";
                        assigned-clocks =<&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                         <&scmi_clk IMX95_CLK_HSIOPLL>,
                                         <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        assigned-clock-rates = <3600000000>, <100000000>, <10000000>;
                        assigned-clock-parents = <0>, <0>,
                                                 <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
                        power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
                        status = "disabled";
                };

Frank Li (14):
  PCI: imx6: Simplify clock handling by using bulk_clk_*() function
  PCI: imx6: Simplify phy handling by using by using
    IMX6_PCIE_FLAG_HAS_PHY
  PCI: imx6: Simplify reset handling by using by using
    *_FLAG_HAS_*_RESET
  PCI: imx6: Using "linux,pci-domain" as slot ID
  PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
  PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
  PCI: imx6: Simplify switch-case logic by involve init_phy callback
  dt-bindings: imx6q-pcie: Clean up irrationality clocks check
  dt-bindings: imx6q-pcie: remove reg and reg-name
  PCI: imx6: Add iMX95 PCIe support
  PCI: imx6: Clean up get addr_space code
  PCI: imx6: Add epc_features in imx6_pcie_drvdata
  dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
  PCI: imx6: Add iMX95 Endpoint (EP) function support

Richard Zhu (1):
  dt-bindings: imx6q-pcie: Add imx95 pcie compatible string

 .../bindings/pci/fsl,imx6q-pcie-common.yaml   |  17 +-
 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       |  52 +-
 .../bindings/pci/fsl,imx6q-pcie.yaml          |  28 +-
 drivers/pci/controller/dwc/pci-imx6.c         | 628 ++++++++++--------
 4 files changed, 415 insertions(+), 310 deletions(-)

-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:11:56 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:11:56 -0500
Subject: [PATCH v4 01/15] PCI: imx6: Simplify clock handling by using bulk_clk_*() function
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-2-Frank.Li@nxp.com>

Refactors the clock handling logic in the imx6 PCI driver by adding
clk_names[] define in drvdata . Simplifies the code and makes it more
maintainable, as future additions of SOC support will only require
straightforward changes.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v3 to v4
    - using clk_bulk_*() API
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 128 ++++++++------------------
 1 file changed, 38 insertions(+), 90 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 74703362aeec7..2086214345e9a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -61,12 +61,15 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 
+#define IMX6_PCIE_MAX_CLKS       6
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
 	u32 flags;
 	int dbi_length;
 	const char *gpr;
+	const char *clk_names[IMX6_PCIE_MAX_CLKS];
 };
 
 struct imx6_pcie {
@@ -74,11 +77,8 @@ struct imx6_pcie {
 	int			reset_gpio;
 	bool			gpio_active_high;
 	bool			link_is_up;
-	struct clk		*pcie_bus;
-	struct clk		*pcie_phy;
-	struct clk		*pcie_inbound_axi;
-	struct clk		*pcie;
-	struct clk		*pcie_aux;
+	struct clk_bulk_data	clks[IMX6_PCIE_MAX_CLKS];
+	u32			clks_cnt;
 	struct regmap		*iomuxc_gpr;
 	u16			msi_ctrl;
 	u32			controller_id;
@@ -407,13 +407,18 @@ static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
 
 static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
 {
-	unsigned long phy_rate = clk_get_rate(imx6_pcie->pcie_phy);
+	unsigned long phy_rate = 0;
 	int mult, div;
 	u16 val;
+	int i;
 
 	if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
 		return 0;
 
+	for (i = 0; i < imx6_pcie->clks_cnt; i++)
+		if (strncmp(imx6_pcie->clks[i].id, "pcie_phy", 8) == 0)
+			phy_rate = clk_get_rate(imx6_pcie->clks[i].clk);
+
 	switch (phy_rate) {
 	case 125000000:
 		/*
@@ -550,19 +555,11 @@ static int imx6_pcie_attach_pd(struct device *dev)
 
 static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	struct dw_pcie *pci = imx6_pcie->pci;
-	struct device *dev = pci->dev;
 	unsigned int offset;
 	int ret = 0;
 
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX6SX:
-		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_axi clock\n");
-			break;
-		}
-
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
 		break;
@@ -589,12 +586,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_aux clock\n");
-			break;
-		}
-
 		offset = imx6_pcie_grp_offset(imx6_pcie);
 		/*
 		 * Set the over ride low and enabled
@@ -615,9 +606,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		clk_disable_unprepare(imx6_pcie->pcie_inbound_axi);
-		break;
 	case IMX6QP:
 	case IMX6Q:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
@@ -631,14 +619,6 @@ static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		clk_disable_unprepare(imx6_pcie->pcie_aux);
-		break;
 	default:
 		break;
 	}
@@ -650,23 +630,9 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 	struct device *dev = pci->dev;
 	int ret;
 
-	ret = clk_prepare_enable(imx6_pcie->pcie_phy);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie_phy clock\n");
+	ret =  clk_bulk_prepare_enable(imx6_pcie->clks_cnt, imx6_pcie->clks);
+	if (ret)
 		return ret;
-	}
-
-	ret = clk_prepare_enable(imx6_pcie->pcie_bus);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie_bus clock\n");
-		goto err_pcie_bus;
-	}
-
-	ret = clk_prepare_enable(imx6_pcie->pcie);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie clock\n");
-		goto err_pcie;
-	}
 
 	ret = imx6_pcie_enable_ref_clk(imx6_pcie);
 	if (ret) {
@@ -679,11 +645,7 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 	return 0;
 
 err_ref_clk:
-	clk_disable_unprepare(imx6_pcie->pcie);
-err_pcie:
-	clk_disable_unprepare(imx6_pcie->pcie_bus);
-err_pcie_bus:
-	clk_disable_unprepare(imx6_pcie->pcie_phy);
+	clk_bulk_disable_unprepare(imx6_pcie->clks_cnt, imx6_pcie->clks);
 
 	return ret;
 }
@@ -691,9 +653,7 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 {
 	imx6_pcie_disable_ref_clk(imx6_pcie);
-	clk_disable_unprepare(imx6_pcie->pcie);
-	clk_disable_unprepare(imx6_pcie->pcie_bus);
-	clk_disable_unprepare(imx6_pcie->pcie_phy);
+	clk_bulk_disable_unprepare(imx6_pcie->clks_cnt, imx6_pcie->clks);
 }
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
@@ -1305,32 +1265,19 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return imx6_pcie->reset_gpio;
 	}
 
-	/* Fetch clocks */
-	imx6_pcie->pcie_bus = devm_clk_get(dev, "pcie_bus");
-	if (IS_ERR(imx6_pcie->pcie_bus))
-		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_bus),
-				     "pcie_bus clock source missing or invalid\n");
+	while (imx6_pcie->drvdata->clk_names[imx6_pcie->clks_cnt]) {
+		int i = imx6_pcie->clks_cnt;
 
-	imx6_pcie->pcie = devm_clk_get(dev, "pcie");
-	if (IS_ERR(imx6_pcie->pcie))
-		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
-				     "pcie clock source missing or invalid\n");
+		imx6_pcie->clks[i].id = imx6_pcie->drvdata->clk_names[i];
+		imx6_pcie->clks_cnt++;
+	}
+
+	/* Fetch clocks */
+	ret = devm_clk_bulk_get(dev, imx6_pcie->clks_cnt, imx6_pcie->clks);
+	if (ret)
+		return ret;
 
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
-							   "pcie_inbound_axi");
-		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
-					     "pcie_inbound_axi clock missing or invalid\n");
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
-		fallthrough;
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
 			imx6_pcie->controller_id = 1;
@@ -1353,10 +1300,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	case IMX8MM_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
 		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
 									 "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
@@ -1372,14 +1315,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	default:
 		break;
 	}
-	/* Don't fetch the pcie_phy clock, if it has abstract PHY driver */
-	if (imx6_pcie->phy == NULL) {
-		imx6_pcie->pcie_phy = devm_clk_get(dev, "pcie_phy");
-		if (IS_ERR(imx6_pcie->pcie_phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_phy),
-					     "pcie_phy clock source missing or invalid\n");
-	}
-
 
 	/* Grab turnoff reset */
 	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
@@ -1470,6 +1405,9 @@ static void imx6_pcie_shutdown(struct platform_device *pdev)
 	imx6_pcie_assert_core_reset(imx6_pcie);
 }
 
+#define IMX6_CLKS_COMMON "pcie_bus", "pcie"
+#define IMX6_CLKS_NO_PHYDRV IMX6_CLKS_COMMON, "pcie_phy"
+
 static const struct imx6_pcie_drvdata drvdata[] = {
 	[IMX6Q] = {
 		.variant = IMX6Q,
@@ -1477,6 +1415,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_NO_PHYDRV},
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1484,6 +1423,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_inbound_axi"},
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1492,40 +1432,48 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_NO_PHYDRV},
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_NO_PHYDRV},
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_aux"},
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_aux"},
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:11:57 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:11:57 -0500
Subject: [PATCH v4 02/15] PCI: imx6: Simplify phy handling by using by using IMX6_PCIE_FLAG_HAS_PHY
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-3-Frank.Li@nxp.com>

Refactors the phy handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_PHY bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling phy.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3:
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 2086214345e9a..91ba26a4b4c3d 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -60,6 +60,9 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
+#define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
+
+#define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
 #define IMX6_PCIE_MAX_CLKS       6
 
@@ -1277,6 +1280,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY)) {
+		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+		if (IS_ERR(imx6_pcie->phy))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
+					     "failed to get pcie phy\n");
+	}
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
@@ -1306,11 +1316,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
 
-		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
-		if (IS_ERR(imx6_pcie->phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
-					     "failed to get pcie phy\n");
-
 		break;
 	default:
 		break;
@@ -1447,13 +1452,15 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 	},
@@ -1465,12 +1472,14 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:11:58 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:11:58 -0500
Subject: [PATCH v4 03/15] PCI: imx6: Simplify reset handling by using by using *_FLAG_HAS_*_RESET
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-4-Frank.Li@nxp.com>

Refactors the reset handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling reset.

Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v2 to v3:
    - add Philipp's Reviewed-by tag
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.
    
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.

 drivers/pci/controller/dwc/pci-imx6.c | 108 ++++++++++----------------
 1 file changed, 41 insertions(+), 67 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 91ba26a4b4c3d..c1fb38a2ebeb6 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -61,6 +61,8 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
+#define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
+#define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -661,18 +663,10 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 {
+	reset_control_assert(imx6_pcie->pciephy_reset);
+	reset_control_assert(imx6_pcie->apps_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_assert(imx6_pcie->pciephy_reset);
-		fallthrough;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
-		break;
 	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
@@ -693,6 +687,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
 		break;
+	default:
+		break;
 	}
 
 	/* Some boards don't have PCIe reset GPIO. */
@@ -706,14 +702,10 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
 
+	reset_control_deassert(imx6_pcie->pciephy_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-		break;
 	case IMX7D:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
 		 * Corrector" and other mysterious undocumented things.
@@ -745,11 +737,7 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 
 		usleep_range(200, 500);
 		break;
-	case IMX6Q:		/* Nothing to do */
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
+	default:
 		break;
 	}
 
@@ -796,16 +784,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2,
 				   IMX6Q_GPR12_PCIE_CTL_2);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_deassert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_deassert(imx6_pcie->apps_reset);
 }
 
 static void imx6_pcie_ltssm_disable(struct device *dev)
@@ -819,16 +802,11 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_assert(imx6_pcie->apps_reset);
 }
 
 static int imx6_pcie_start_link(struct dw_pcie *pci)
@@ -1287,36 +1265,24 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "failed to get pcie phy\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-
-		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
-									    "pciephy");
-		if (IS_ERR(imx6_pcie->pciephy_reset)) {
-			dev_err(dev, "Failed to get PCIEPHY reset control\n");
-			return PTR_ERR(imx6_pcie->pciephy_reset);
-		}
-
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
-		if (IS_ERR(imx6_pcie->apps_reset)) {
-			dev_err(dev, "Failed to get PCIE APPS reset control\n");
-			return PTR_ERR(imx6_pcie->apps_reset);
-		}
-		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET)) {
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev, "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
+	}
 
-		break;
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET)) {
+		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev, "pciephy");
+		if (IS_ERR(imx6_pcie->pciephy_reset))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pciephy_reset),
+					     "Failed to get PCIEPHY reset control\n");
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX7D:
+		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
+			imx6_pcie->controller_id = 1;
 	default:
 		break;
 	}
@@ -1441,31 +1407,39 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_NO_PHYDRV},
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
+		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_aux"},
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_aux"},
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:11:59 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:11:59 -0500
Subject: [PATCH v4 04/15] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-5-Frank.Li@nxp.com>

Avoid use get slot id by compared with register physical address. If there
are more than 2 slots, compared logic will become complex.

"linux,pci-domain" already exist at dts since first commit:
	commit (9e65987b9584d arm64: dts: imx8mp: Add iMX8MP PCIe support).

So it is safe to remove compare basic address code:
	...
	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
		imx6_pcie->controller_id = 1;
	...

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v3 to v4
    - remove compare basic address logic
    Change from v2 to v3
    - none
    Change from v1 to v2
    - fix of_get_pci_domain_nr return value check logic

 drivers/pci/controller/dwc/pci-imx6.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index c1fb38a2ebeb6..7145947e21d92 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -33,6 +33,7 @@
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
+#include "../../pci.h"
 #include "pcie-designware.h"
 
 #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
@@ -40,7 +41,6 @@
 #define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE	BIT(11)
 #define IMX8MQ_GPR_PCIE_VREG_BYPASS		BIT(12)
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
-#define IMX8MQ_PCIE2_BASE_ADDR			0x33c00000
 
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
@@ -1279,13 +1279,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "Failed to get PCIEPHY reset control\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-	default:
-		break;
-	}
+	/* Using linux,pci-domain as PCI slot id */
+	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
+	/* If there are not "linux,pci-domain" in dts file, means only 1 controller */
+	if (imx6_pcie->controller_id < 0)
+		imx6_pcie->controller_id = 0;
 
 	/* Grab turnoff reset */
 	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:00 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:00 -0500
Subject: [PATCH v4 05/15] PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-6-Frank.Li@nxp.com>

Add drvdata::ltssm_off and drvdata::ltssm_mask to simple
imx6_pcie_ltssm_enable(disable)() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 37 ++++++++++++---------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 7145947e21d92..79d892836a24d 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,8 @@ struct imx6_pcie_drvdata {
 	int dbi_length;
 	const char *gpr;
 	const char *clk_names[IMX6_PCIE_MAX_CLKS];
+	const u32 ltssm_off;
+	const u32 ltssm_mask;
 };
 
 struct imx6_pcie {
@@ -775,18 +777,11 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_ltssm_enable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2,
-				   IMX6Q_GPR12_PCIE_CTL_2);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off, drvdata->ltssm_mask,
+				   drvdata->ltssm_mask);
 
 	reset_control_deassert(imx6_pcie->apps_reset);
 }
@@ -794,17 +789,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 static void imx6_pcie_ltssm_disable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2, 0);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off,
+				   drvdata->ltssm_mask, 0);
 
 	reset_control_assert(imx6_pcie->apps_reset);
 }
@@ -1385,6 +1374,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_NO_PHYDRV},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1393,6 +1384,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_inbound_axi"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1402,6 +1395,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_NO_PHYDRV},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:01 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:01 -0500
Subject: [PATCH v4 06/15] PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-7-Frank.Li@nxp.com>

Add drvdata::mode_off and drvdata::mode_mask to simple
imx6_pcie_configure_type() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v2 to v3
    - none
    Change from v1 to v2
    - use ffs() to fixe build error.

 drivers/pci/controller/dwc/pci-imx6.c | 60 ++++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 79d892836a24d..49b98593326f9 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -68,6 +68,7 @@ enum imx6_pcie_variants {
 
 #define IMX6_PCIE_MAX_CLKS       6
 
+#define IMX6_PCIE_MAX_INSTANCES			2
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -77,6 +78,8 @@ struct imx6_pcie_drvdata {
 	const char *clk_names[IMX6_PCIE_MAX_CLKS];
 	const u32 ltssm_off;
 	const u32 ltssm_mask;
+	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
+	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
 };
 
 struct imx6_pcie {
@@ -174,32 +177,25 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
-	unsigned int mask, val, mode;
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
+	unsigned int mask, val, mode, id;
 
-	if (imx6_pcie->drvdata->mode == DW_PCIE_EP_TYPE)
+	if (drvdata->mode == DW_PCIE_EP_TYPE)
 		mode = PCI_EXP_TYPE_ENDPOINT;
 	else
 		mode = PCI_EXP_TYPE_ROOT_PORT;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		if (imx6_pcie->controller_id == 1) {
-			mask = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
-					  mode);
-		} else {
-			mask = IMX6Q_GPR12_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		}
-		break;
-	default:
-		mask = IMX6Q_GPR12_DEVICE_TYPE;
-		val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		break;
-	}
+	id = imx6_pcie->controller_id;
+
+	/* If mode_mask[id] is zero, means each controller have its individual gpr */
+	if (!drvdata->mode_mask[id])
+		id = 0;
+
+	mask = drvdata->mode_mask[id];
+	/* FIELD_PREP mask have been constant */
+	val = mode << (ffs(mask) - 1);
 
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, mask, val);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->mode_off[id], mask, val);
 }
 
 static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
@@ -1376,6 +1372,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {IMX6_CLKS_NO_PHYDRV},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1386,6 +1384,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_inbound_axi"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1397,6 +1397,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {IMX6_CLKS_NO_PHYDRV},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1405,6 +1407,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_NO_PHYDRV},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1412,6 +1416,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1420,6 +1428,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
@@ -1428,6 +1438,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
@@ -1436,6 +1448,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
@@ -1443,6 +1459,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
@@ -1450,6 +1468,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:02 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:02 -0500
Subject: [PATCH v4 07/15] PCI: imx6: Simplify switch-case logic by involve init_phy callback
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-8-Frank.Li@nxp.com>

Add drvdata::init_phy() callback function, so difference SOC choose
difference callback function to simple switch-case logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    change from v1 to v4:
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 135 ++++++++++++++------------
 1 file changed, 71 insertions(+), 64 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 49b98593326f9..02da650aa55ee 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -69,6 +69,9 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_MAX_CLKS       6
 
 #define IMX6_PCIE_MAX_INSTANCES			2
+
+struct imx6_pcie;
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -80,6 +83,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
 struct imx6_pcie {
@@ -323,76 +327,69 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
 	return 0;
 }
 
-static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+static int imx8mq_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		/*
-		 * The PHY initialization had been done in the PHY
-		 * driver, break here directly.
-		 */
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		/*
-		 * TODO: Currently this code assumes external
-		 * oscillator is being used
-		 */
+	/*
+	 * TODO: Currently this code assumes external
+	 * oscillator is being used
+	 */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   imx6_pcie_grp_offset(imx6_pcie),
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD,
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD);
+	/*
+	 * Regarding the datasheet, the PCIE_VPH is suggested
+	 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
+	 * VREG_BYPASS should be cleared to zero.
+	 */
+	if (imx6_pcie->vph && regulator_get_voltage(imx6_pcie->vph) > 3000000)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr,
 				   imx6_pcie_grp_offset(imx6_pcie),
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD,
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD);
-		/*
-		 * Regarding the datasheet, the PCIE_VPH is suggested
-		 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
-		 * VREG_BYPASS should be cleared to zero.
-		 */
-		if (imx6_pcie->vph &&
-		    regulator_get_voltage(imx6_pcie->vph) > 3000000)
-			regmap_update_bits(imx6_pcie->iomuxc_gpr,
-					   imx6_pcie_grp_offset(imx6_pcie),
-					   IMX8MQ_GPR_PCIE_VREG_BYPASS,
-					   0);
-		break;
-	case IMX7D:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX8MQ_GPR_PCIE_VREG_BYPASS,
+				   0);
+
+	return 0;
+}
+
+static int imx7d_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	return	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
-		break;
-	case IMX6SX:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6SX_GPR12_PCIE_RX_EQ_MASK,
-				   IMX6SX_GPR12_PCIE_RX_EQ_2);
-		fallthrough;
-	default:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+}
+
+static int imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 
-		/* configure constant input signal to the pcie ctrl and phy */
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
-
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN1,
-				   imx6_pcie->tx_deemph_gen1 << 0);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
-				   imx6_pcie->tx_deemph_gen2_3p5db << 6);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
-				   imx6_pcie->tx_deemph_gen2_6db << 12);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_FULL,
-				   imx6_pcie->tx_swing_full << 18);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_LOW,
-				   imx6_pcie->tx_swing_low << 25);
-		break;
-	}
+	/* configure constant input signal to the pcie ctrl and phy */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN1,
+			   imx6_pcie->tx_deemph_gen1 << 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
+			   imx6_pcie->tx_deemph_gen2_3p5db << 6);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
+			   imx6_pcie->tx_deemph_gen2_6db << 12);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_FULL,
+			   imx6_pcie->tx_swing_full << 18);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_LOW,
+			   imx6_pcie->tx_swing_low << 25);
+	return 0;
+}
 
-	imx6_pcie_configure_type(imx6_pcie);
+static int imx6sx_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6SX_GPR12_PCIE_RX_EQ_MASK, IMX6SX_GPR12_PCIE_RX_EQ_2);
+
+	return imx6_pcie_init_phy(imx6_pcie);
 }
 
 static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
@@ -903,7 +900,11 @@ static int imx6_pcie_host_init(struct dw_pcie_rp *pp)
 	}
 
 	imx6_pcie_assert_core_reset(imx6_pcie);
-	imx6_pcie_init_phy(imx6_pcie);
+
+	if (imx6_pcie->drvdata->init_phy)
+		imx6_pcie->drvdata->init_phy(imx6_pcie);
+
+	imx6_pcie_configure_type(imx6_pcie);
 
 	ret = imx6_pcie_clk_enable(imx6_pcie);
 	if (ret) {
@@ -1374,6 +1375,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1386,6 +1388,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6sx_pcie_init_phy,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1399,6 +1402,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1409,6 +1413,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {IMX6_CLKS_NO_PHYDRV},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx7d_pcie_init_phy,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1420,6 +1425,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1452,6 +1458,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:03 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:03 -0500
Subject: [PATCH v4 08/15] dt-bindings: imx6q-pcie: Clean up irrationality clocks check
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-9-Frank.Li@nxp.com>

There are clocks and clock-names restriction for difference compatible
string. So needn't irrationality check again for clock's miniItems and
maxItems.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v4
    - new patch at v4

 .../bindings/pci/fsl,imx6q-pcie-common.yaml      | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index d91b639ae7ae7..0c50487a3866d 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -150,22 +150,6 @@ allOf:
             - {}
             - const: pcie_phy
             - const: pcie_aux
-  - if:
-      properties:
-        compatible:
-          not:
-            contains:
-              enum:
-                - fsl,imx6sx-pcie
-                - fsl,imx8mq-pcie
-                - fsl,imx6sx-pcie-ep
-                - fsl,imx8mq-pcie-ep
-    then:
-      properties:
-        clocks:
-          maxItems: 3
-        clock-names:
-          maxItems: 3
 
   - if:
       properties:
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:04 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:04 -0500
Subject: [PATCH v4 09/15] dt-bindings: imx6q-pcie: remove reg and reg-name
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-10-Frank.Li@nxp.com>

snps,dw-pcie.yaml already have reg and reg-name information. Needn't
duplciate here.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v4:
    - new patch at v4

 .../devicetree/bindings/pci/fsl,imx6q-pcie.yaml        | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 81bbb8728f0f9..f20d4f0e3cb6c 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -30,16 +30,6 @@ properties:
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
 
-  reg:
-    items:
-      - description: Data Bus Interface (DBI) registers.
-      - description: PCIe configuration space region.
-
-  reg-names:
-    items:
-      - const: dbi
-      - const: config
-
   clocks:
     minItems: 3
     items:
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:05 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:05 -0500
Subject: [PATCH v4 10/15] dt-bindings: imx6q-pcie: Add imx95 pcie compatible string
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-11-Frank.Li@nxp.com>

From: Richard Zhu <hongxing.zhu at nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
Add "atu" and "app" to reg-names.

Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
---

Notes:
    Change from v2 to v3
    - Remove krzy's ACK tag
    - Add condition check for imx95, which required more reg-names then old
    platform, so need Krzy review again,
    
    Change from v1 to v2
    - add Krzy's ACK tag

 .../bindings/pci/fsl,imx6q-pcie-common.yaml    |  1 +
 .../bindings/pci/fsl,imx6q-pcie.yaml           | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index 0c50487a3866d..a8b34f58f8f49 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -207,6 +207,7 @@ allOf:
                 - fsl,imx6sx-pcie
                 - fsl,imx6q-pcie
                 - fsl,imx6qp-pcie
+                - fsl,imx95-pcie
                 - fsl,imx6sx-pcie-ep
                 - fsl,imx6q-pcie-ep
                 - fsl,imx6qp-pcie-ep
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index f20d4f0e3cb6c..8633c622bd178 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -29,6 +29,7 @@ properties:
       - fsl,imx8mq-pcie
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
+      - fsl,imx95-pcie
 
   clocks:
     minItems: 3
@@ -80,6 +81,22 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie
+    then:
+      properties:
+        reg:
+          minItems: 4
+        reg-names:
+          items:
+            - const: dbi
+            - const: atu
+            - const: app
+            - const: config
+
   - if:
       properties:
         compatible:
@@ -101,6 +118,7 @@ allOf:
         compatible:
           enum:
             - fsl,imx8mq-pcie
+            - fsl,imx95-pcie
     then:
       properties:
         clocks:
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:06 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:06 -0500
Subject: [PATCH v4 11/15] PCI: imx6: Add iMX95 PCIe support
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-12-Frank.Li@nxp.com>

Add iMX95 PCIe basic root complex function support.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 90 +++++++++++++++++++++++++--
 1 file changed, 85 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 02da650aa55ee..324c62cecfa5f 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -42,6 +42,25 @@
 #define IMX8MQ_GPR_PCIE_VREG_BYPASS		BIT(12)
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
 
+#define IMX95_PCIE_PHY_GEN_CTRL			0x0
+#define IMX95_PCIE_REF_USE_PAD			BIT(17)
+
+#define IMX95_PCIE_PHY_MPLLA_CTRL		0x10
+#define IMX95_PCIE_PHY_MPLL_STATE		BIT(30)
+
+#define IMX95_PCIE_SS_RW_REG_0			0xf0
+#define IMX95_PCIE_REF_CLKEN			BIT(23)
+#define IMX95_PCIE_PHY_CR_PARA_SEL		BIT(9)
+
+#define IMX95_PE0_GEN_CTRL_1			0x1050
+#define IMX95_PCIE_DEVICE_TYPE			GENMASK(3, 0)
+
+#define IMX95_PE0_GEN_CTRL_3			0x1058
+#define IMX95_PCIE_LTSSM_EN			BIT(0)
+
+#define IMX95_PE0_PM_STS			0x1064
+#define IMX95_PCIE_PM_LINKST_IN_L2		BIT(14)
+
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -52,6 +71,7 @@ enum imx6_pcie_variants {
 	IMX8MQ,
 	IMX8MM,
 	IMX8MP,
+	IMX95,
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
@@ -63,6 +83,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
+#define IMX6_PCIE_FLAG_HAS_SERDES		BIT(6)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -179,6 +200,24 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
+static int imx95_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			IMX95_PCIE_SS_RW_REG_0,
+			IMX95_PCIE_PHY_CR_PARA_SEL,
+			IMX95_PCIE_PHY_CR_PARA_SEL);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_PHY_GEN_CTRL,
+			   IMX95_PCIE_REF_USE_PAD, 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_SS_RW_REG_0,
+			   IMX95_PCIE_REF_CLKEN,
+			   IMX95_PCIE_REF_CLKEN);
+
+	return 0;
+}
+
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
 	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
@@ -579,6 +618,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
 		break;
 	case IMX7D:
+	case IMX95:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -696,10 +736,19 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 {
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
+	u32 val;
 
 	reset_control_deassert(imx6_pcie->pciephy_reset);
 
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX95:
+		/* Polling the MPLL_STATE */
+		if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+					IMX95_PCIE_PHY_MPLLA_CTRL, val,
+					val & IMX95_PCIE_PHY_MPLL_STATE,
+					10, 10000))
+			dev_err(dev, "PCIe PLL lock timeout\n");
+		break;
 	case IMX7D:
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
@@ -1278,12 +1327,32 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(imx6_pcie->turnoff_reset);
 	}
 
+	if (imx6_pcie->drvdata->gpr) {
 	/* Grab GPR config register range */
-	imx6_pcie->iomuxc_gpr =
-		 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
-	if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
-		dev_err(dev, "unable to find iomuxc registers\n");
-		return PTR_ERR(imx6_pcie->iomuxc_gpr);
+		imx6_pcie->iomuxc_gpr =
+			 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
+	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_SERDES)) {
+		void __iomem *off = devm_platform_ioremap_resource_byname(pdev, "app");
+
+		if (IS_ERR(off))
+			return dev_err_probe(dev, PTR_ERR(off),
+					     "unable to find serdes registers\n");
+
+		static struct regmap_config regmap_config = {
+			.reg_bits = 32,
+			.val_bits = 32,
+			.reg_stride = 4,
+		};
+
+		imx6_pcie->iomuxc_gpr = devm_regmap_init_mmio(dev, off, &regmap_config);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
 	}
 
 	/* Grab PCIe PHY Tx Settings */
@@ -1447,6 +1516,16 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
+	[IMX95] = {
+		.variant = IMX95,
+		.flags = IMX6_PCIE_FLAG_HAS_SERDES,
+		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_aux"},
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_PHY |
@@ -1488,6 +1567,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
 	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{ .compatible = "fsl,imx8mp-pcie", .data = &drvdata[IMX8MP], },
+	{ .compatible = "fsl,imx95-pcie", .data = &drvdata[IMX95], },
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:07 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:07 -0500
Subject: [PATCH v4 12/15] PCI: imx6: Clean up get addr_space code
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-13-Frank.Li@nxp.com>

The common dw_pcie_ep_init() already do the same thing. Needn't platform
driver do it again.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches

 drivers/pci/controller/dwc/pci-imx6.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 324c62cecfa5f..54b90f8576915 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1080,7 +1080,6 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 	int ret;
 	unsigned int pcie_dbi2_offset;
 	struct dw_pcie_ep *ep;
-	struct resource *res;
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct dw_pcie_rp *pp = &pci->pp;
 	struct device *dev = pci->dev;
@@ -1099,14 +1098,8 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 		pcie_dbi2_offset = SZ_4K;
 		break;
 	}
-	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
-	if (!res)
-		return -EINVAL;
 
-	ep->phys_base = res->start;
-	ep->addr_size = resource_size(res);
-	ep->page_size = SZ_64K;
+	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:08 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:08 -0500
Subject: [PATCH v4 13/15] PCI: imx6: Add epc_features in imx6_pcie_drvdata
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-14-Frank.Li@nxp.com>

The i.MX EP exhibits variations in epc_features among different EP
configurations. This introduces the addition of epc_features in
imx6_pcie_drvdata to accommodate these differences. It's important to note
that there are no functional changes in this commit; instead, it lays the
groundwork for supporting i.MX95 EP functions.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patch at v3

 drivers/pci/controller/dwc/pci-imx6.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 54b90f8576915..8f7b1533e2869 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -104,6 +104,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	const struct pci_epc_features *epc_features;
 	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
@@ -1065,7 +1066,10 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
-	return &imx8m_pcie_epc_features;
+	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pci);
+
+	return imx6_pcie->drvdata->epc_features;
 }
 
 static const struct dw_pcie_ep_ops pcie_ep_ops = {
@@ -1530,6 +1534,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
@@ -1540,6 +1545,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
@@ -1549,6 +1555,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:09 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:09 -0500
Subject: [PATCH v4 14/15] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-15-Frank.Li@nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
Add reg-name: "atu", "dbi2", "dma" and "serdes".

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches at v3

 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 52 ++++++++++++++++---
 1 file changed, 44 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
index ee155ed5f1811..be9ea77ce8548 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
@@ -22,14 +22,7 @@ properties:
       - fsl,imx8mm-pcie-ep
       - fsl,imx8mq-pcie-ep
       - fsl,imx8mp-pcie-ep
-
-  reg:
-    minItems: 2
-
-  reg-names:
-    items:
-      - const: dbi
-      - const: addr_space
+      - fsl,imx95-pcie-ep
 
   clocks:
     minItems: 3
@@ -62,11 +55,46 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx8mm-pcie-ep
+            - fsl,imx8mq-pcie-ep
+            - fsl,imx8mp-pcie-ep
+    then:
+      properties:
+        reg:
+          minItems: 2
+        reg-names:
+          items:
+            - const: dbi
+            - const: addr_space
+
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie-ep
+    then:
+      properties:
+        reg:
+          minItems: 6
+        reg-names:
+          items:
+            - const: dbi
+            - const: atu
+            - const: dbi2
+            - const: app
+            - const: dma
+            - const: addr_space
+
   - if:
       properties:
         compatible:
           enum:
             - fsl,imx8mq-pcie-ep
+            - fsl,imx95-pcie-ep
     then:
       properties:
         clocks:
@@ -87,6 +115,14 @@ allOf:
             - const: pcie_bus
             - const: pcie_aux
 
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie-ep
+    then:
+      properties:
+        linux,pci-domain: true
 
 unevaluatedProperties: false
 
-- 
2.34.1



From Frank.Li at nxp.com  Sat Dec 16 21:12:10 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 17 Dec 2023 00:12:10 -0500
Subject: [PATCH v4 15/15] PCI: imx6: Add iMX95 Endpoint (EP) function support
In-Reply-To: <20231217051210.754832-1-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
Message-ID: <20231217051210.754832-16-Frank.Li@nxp.com>

Add iMX95 EP function support and add 64bit address support. Internal bus
bridge for PCI support 64bit dma address in iMX95. So set call
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)).

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v3 to v4
    - change align to 4k for imx95
    Change from v1 to v3
    - new patches at v3

 drivers/pci/controller/dwc/pci-imx6.c | 45 +++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 8f7b1533e2869..5518c1b0d4fc1 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,7 @@ enum imx6_pcie_variants {
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
+	IMX95_EP,
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
@@ -84,6 +85,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
 #define IMX6_PCIE_FLAG_HAS_SERDES		BIT(6)
+#define IMX6_PCIE_FLAG_SUPPORT_64BIT		BIT(7)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -620,6 +622,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 		break;
 	case IMX7D:
 	case IMX95:
+	case IMX95_EP:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -1063,6 +1066,23 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 	.align = SZ_64K,
 };
 
+/*
+ * BAR#	| Default BAR enable	| Default BAR Type	| Default BAR Size	| BAR Sizing Scheme
+ * ================================================================================================
+ * BAR0	| Enable		| 64-bit		| 1 MB			| Programmable Size
+ * BAR1	| Disable		| 32-bit		| 64 KB			| Fixed Size
+ *	| (BAR0 is 64-bit)	| if BAR0 is 32-bit	|			| As Bar0 is 64bit
+ * BAR2	| Enable		| 32-bit		| 1 MB			| Programmable Size
+ * BAR3	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ * BAR4	| Enable		| 32-bit		| 1M			| Programmable Size
+ * BAR5	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ */
+static const struct pci_epc_features imx95_pcie_epc_features = {
+	.msi_capable = true,
+	.bar_fixed_size[1] = SZ_64K,
+	.align = SZ_4K,
+};
+
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
@@ -1105,6 +1125,14 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 
 	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
+	/*
+	 * db2 information should fetch from dtb file. dw_pcie_ep_init() can get dbi_base2 from
+	 * "dbi2" if pci->dbi_base2 is NULL. All code related pcie_dbi2_offset should be removed
+	 * after all dts added "dbi2" reg.
+	 */
+	if (imx6_pcie->drvdata->variant == IMX95_EP)
+		pci->dbi_base2 = NULL;
+
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
 		dev_err(dev, "failed to initialize endpoint\n");
@@ -1352,6 +1380,9 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "unable to find iomuxc registers\n");
 	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_SUPPORT_64BIT))
+		dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+
 	/* Grab PCIe PHY Tx Settings */
 	if (of_property_read_u32(node, "fsl,tx-deemph-gen1",
 				 &imx6_pcie->tx_deemph_gen1))
@@ -1557,6 +1588,19 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.epc_features = &imx8m_pcie_epc_features,
 	},
+	[IMX95_EP] = {
+		.variant = IMX95_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_SERDES |
+			 IMX6_PCIE_FLAG_SUPPORT_64BIT,
+		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_aux"},
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+		.epc_features = &imx95_pcie_epc_features,
+		.mode = DW_PCIE_EP_TYPE,
+	},
 };
 
 static const struct of_device_id imx6_pcie_of_match[] = {
@@ -1571,6 +1615,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
+	{ .compatible = "fsl,imx95-pcie-ep", .data = &drvdata[IMX95_EP], },
 	{},
 };
 
-- 
2.34.1



From andyshrk at 163.com  Sun Dec 17 00:44:15 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 17 Dec 2023 16:44:15 +0800
Subject: [PATCH] drm/rockchip: vop2: Avoid use regmap_reinit_cache at runtime
Message-ID: <20231217084415.2373043-1-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>

Marek Report a possible irq lock inversion dependency warning when
commit 81a06f1d02e5 ("Revert "drm/rockchip: vop2: Use regcache_sync()
to fix suspend/resume"") lands linux-next.

I can reproduce this warning with:
CONFIG_PROVE_LOCKING=y
CONFIG_DEBUG_LOCKDEP=y

It seems than when use regmap_reinit_cache at runtime whith Mark's
commit 3d59c22bbb8d ("drm/rockchip: vop2: Convert to use maple tree
register cache"), it will trigger a possible irq lock inversion dependency
warning.

One solution is switch back to REGCACHE_RBTREE, but it seems that
REGCACHE_MAPLE is the future, so I avoid ues regmap_reinit_cache,
and drop all the regcache when vop is disabled, then we get a fresh
start at next enbable time.

[    8.425923] dwmmc_rockchip fe2b0000.mmc: IDMAC supports 32-bit address mode.
[    8.427020] dwmmc_rockchip fe2b0000.mmc: Using internal DMA controller.
[    8.428013] dwmmc_rockchip fe2b0000.mmc: Version ID is 270a
[    8.429088] dwmmc_rockchip fe2b0000.mmc: DW MMC controller at irq 78,32 bit host data width,256 deep fifo
[    8.454219] mmc_host mmc0: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0)
[    8.465446] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_component_ops)
[    8.475586] dwhdmi-rockchip fe0a0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY)
[    8.484326] dwhdmi-rockchip fe0a0000.hdmi: registered DesignWare HDMI I2C bus driver
[    8.490505] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops dw_hdmi_rockchip_ops)
[    8.501151] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0
[    8.895456]
[    8.895473] ========================================================
[    8.895480] WARNING: possible irq lock inversion dependency detected
[    8.895486] 6.7.0-rc5-next-20231215 #514 Not tainted
[    8.895496] --------------------------------------------------------
[    8.895501] swapper/0/0 just changed the state of lock:
[    8.895510] ffff0000070b6018 (rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock){-...}-{2:2}, at: regmap_lock_spinlock
+0x14/0x24
[    8.895560] but this lock took another, HARDIRQ-unsafe lock in the past:
[    8.895566]  (&mt->ma_lock){+.+.}-{2:2}
[    8.895580]
[    8.895580]
[    8.895580] and interrupts could create inverse lock ordering between them.
[    8.895580]
[    8.895585]
[    8.895585] other info that might help us debug this:
[    8.895590]  Possible interrupt unsafe locking scenario:
[    8.895590]
[    8.895594]        CPU0                    CPU1
[    8.895598]        ----                    ----
[    8.895602]   lock(&mt->ma_lock);
[    8.895614]                                local_irq_disable();
[    8.895617]                                lock(rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock);
[    8.895629]                                lock(&mt->ma_lock);
[    8.895641]   <Interrupt>
[    8.895644]   lock(rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock);
[    8.895655]
[    8.895655]  *** DEADLOCK ***
[    8.895655]
[    8.895659] no locks held by swapper/0/0.
[    8.895664]
[    8.895664] the shortest dependencies between 2nd lock and 1st lock:
[    8.895672]  -> (&mt->ma_lock){+.+.}-{2:2} ops: 12 {
[    8.895704]     HARDIRQ-ON-W at:
[    8.895713]                       lock_acquire+0x238/0x354
[    8.895732]                       _raw_spin_lock+0x3c/0x50
[    8.895749]                       regcache_maple_exit+0x64/0xc4
[    8.895766]                       regcache_exit+0x48/0xac
[    8.895780]                       regmap_reinit_cache+0x18/0x98
[    8.895793]	                     vop2_crtc_atomic_enable+0xefc/0x1074
[    8.895810]                       drm_atomic_helper_commit_modeset_enables+0xac/0x264
[    8.895826]                       drm_atomic_helper_commit_tail_rpm+0x2c/0x78
[    8.895841]                       commit_tail+0x9c/0x178
[    8.895855]                       drm_atomic_helper_commit+0x17c/0x1ac
[    8.895869]                       drm_atomic_commit+0xac/0xec
[    8.895885]                       drm_client_modeset_commit_atomic+0x230/0x290
[    8.895896]                       drm_client_modeset_commit_locked+0x54/0x1c4
[    8.895907]                       drm_client_modeset_commit+0x2c/0x50
[    8.895917]                       __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
[    8.895934]                       drm_fb_helper_set_par+0x30/0x48
[    8.895948]                       fbcon_init+0x40c/0x498
[    8.895961]                       visual_init+0xb0/0x108
[    8.895972]                       do_bind_con_driver+0x1b8/0x38c
[    8.895983]                       do_take_over_console+0x148/0x1d4
[    8.895993]                       do_fbcon_takeover+0x6c/0xe0
[    8.896003]                       fbcon_fb_registered+0x1f8/0x1fc
[    8.896014]                       register_framebuffer+0x158/0x228
[    8.896029]                       __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
[    8.896045]                       drm_fb_helper_initial_config+0x3c/0x48
[    8.896060]                       drm_fbdev_generic_client_hotplug+0xb8/0xd8
[    8.896074]                       drm_client_register+0x58/0xa0
[    8.896085]                       drm_fbdev_generic_setup+0xbc/0x144
[    8.896098]                       rockchip_drm_bind+0x1ec/0x1f8
[    8.896110]                       try_to_bring_up_aggregate_device+0x278/0x2d8
[    8.896127]                       __component_add+0xac/0x198
[    8.896139]                       component_add+0x10/0x18
[    8.896151]                       dw_hdmi_rockchip_probe+0x1c/0x24
[    8.896163]                       platform_probe+0x90/0xd8
[    8.896179]                       really_probe+0x114/0x3c0
[    8.896192]                       __driver_probe_device+0x7c/0x17c
[    8.896204]                       driver_probe_device+0x38/0x11c
[    8.896218]                       __device_attach_driver+0xb4/0x164
[    8.896230]                       bus_for_each_drv+0x78/0xdc
[    8.896241]                       __device_attach+0xfc/0x1ac
[    8.896253]                       device_initial_probe+0x10/0x18
[    8.896266]                       bus_probe_device+0xa8/0xac
[    8.896277]                       deferred_probe_work_func+0x98/0xe8
[    8.896290]                       process_scheduled_works+0x23c/0x5b8
[    8.896306]                       worker_thread+0x188/0x374
[    8.896319]                       kthread+0xe4/0x10c
[    8.896332]                       ret_from_fork+0x10/0x20
[    8.896345]     SOFTIRQ-ON-W at:
[    8.896355]                       lock_acquire+0x238/0x354
[    8.896370]                       _raw_spin_lock+0x3c/0x50
[    8.896384]                       regcache_maple_exit+0x64/0xc4
[    8.896399]                       regcache_exit+0x48/0xac
[    8.896411]                       regmap_reinit_cache+0x18/0x98
[    8.896423]                       vop2_crtc_atomic_enable+0xefc/0x1074
[    8.896437]                       drm_atomic_helper_commit_modeset_enables+0xac/0x264
[    8.896453]                       drm_atomic_helper_commit_tail_rpm+0x2c/0x78
[    8.896467]                       commit_tail+0x9c/0x178
[    8.896480]                       drm_atomic_helper_commit+0x17c/0x1ac
[    8.896494]                       drm_atomic_commit+0xac/0xec
[    8.896509]                       drm_client_modeset_commit_atomic+0x230/0x290
[    8.896520]                       drm_client_modeset_commit_locked+0x54/0x1c4
[    8.896530]                       drm_client_modeset_commit+0x2c/0x50
[    8.896540]                       __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
[    8.896558]                       drm_fb_helper_set_par+0x30/0x48
[    8.896572]                       fbcon_init+0x40c/0x498
[    8.896582]                       visual_init+0xb0/0x108
[    8.896591]                       do_bind_con_driver+0x1b8/0x38c
[    8.896601]                       do_take_over_console+0x148/0x1d4
[    8.896611]                       do_fbcon_takeover+0x6c/0xe0
[    8.896620]                       fbcon_fb_registered+0x1f8/0x1fc
[    8.896630]                       register_framebuffer+0x158/0x228
[    8.896645]                       __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
[    8.896660]                       drm_fb_helper_initial_config+0x3c/0x48
[    8.896674]                       drm_fbdev_generic_client_hotplug+0xb8/0xd8
[    8.896688]                       drm_client_register+0x58/0xa0
[    8.896698]                       drm_fbdev_generic_setup+0xbc/0x144
[    8.896711]                       rockchip_drm_bind+0x1ec/0x1f8
[    8.896724]                       try_to_bring_up_aggregate_device+0x278/0x2d8
[    8.896738]                       __component_add+0xac/0x198
[    8.896751]                       component_add+0x10/0x18
[    8.896763]                       dw_hdmi_rockchip_probe+0x1c/0x24
[    8.896773]                       platform_probe+0x90/0xd8
[    8.896789]                       really_probe+0x114/0x3c0
[    8.896801]                       __driver_probe_device+0x7c/0x17c
[    8.896814]                       driver_probe_device+0x38/0x11c
[    8.896827]                       __device_attach_driver+0xb4/0x164
[    8.896839]                       bus_for_each_drv+0x78/0xdc
[    8.896850]                       __device_attach+0xfc/0x1ac
[    8.896862]                       device_initial_probe+0x10/0x18
[    8.896875]                       bus_probe_device+0xa8/0xac
[    8.896886]                       deferred_probe_work_func+0x98/0xe8
[    8.896897]                       process_scheduled_works+0x23c/0x5b8
[    8.896911]                       worker_thread+0x188/0x374
[    8.896924]                       kthread+0xe4/0x10c
[    8.896935]                       ret_from_fork+0x10/0x20
[    8.896947]     INITIAL USE at:
[    8.896955]                      lock_acquire+0x238/0x354
[    8.896971]                      _raw_spin_lock+0x3c/0x50
[    8.896985]                      regcache_maple_exit+0x64/0xc4
[    8.896999]                      regcache_exit+0x48/0xac
[    8.897011]                      regmap_reinit_cache+0x18/0x98
[    8.897022]                      vop2_crtc_atomic_enable+0xefc/0x1074
[    8.897036]                      drm_atomic_helper_commit_modeset_enables+0xac/0x264
[    8.897051]                      drm_atomic_helper_commit_tail_rpm+0x2c/0x78
[    8.897065]                      commit_tail+0x9c/0x178
[    8.897079]                      drm_atomic_helper_commit+0x17c/0x1ac
[    8.897093]                      drm_atomic_commit+0xac/0xec
[    8.897107]                      drm_client_modeset_commit_atomic+0x230/0x290
[    8.897118]                      drm_client_modeset_commit_locked+0x54/0x1c4
[    8.897128]                      drm_client_modeset_commit+0x2c/0x50
[    8.897138]                      __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
[    8.897154]                      drm_fb_helper_set_par+0x30/0x48
[    8.897168]                      fbcon_init+0x40c/0x498
[    8.897179]                      visual_init+0xb0/0x108
[    8.897188]                      do_bind_con_driver+0x1b8/0x38c
[    8.897198]                      do_take_over_console+0x148/0x1d4
[    8.897208]                      do_fbcon_takeover+0x6c/0xe0
[    8.897218]                      fbcon_fb_registered+0x1f8/0x1fc
[    8.897228]                      register_framebuffer+0x158/0x228
[    8.897241]                      __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
[    8.897257]                      drm_fb_helper_initial_config+0x3c/0x48
[    8.897272]                      drm_fbdev_generic_client_hotplug+0xb8/0xd8
[    8.897286]                      drm_client_register+0x58/0xa0
[    8.897296]                      drm_fbdev_generic_setup+0xbc/0x144
[    8.897309]                      rockchip_drm_bind+0x1ec/0x1f8
[    8.897321]                      try_to_bring_up_aggregate_device+0x278/0x2d8
[    8.897336]                      __component_add+0xac/0x198
[    8.897348]                      component_add+0x10/0x18
[    8.897360]                      dw_hdmi_rockchip_probe+0x1c/0x24
[    8.897370]                      platform_probe+0x90/0xd8
[    8.897385]                      really_probe+0x114/0x3c0
[    8.897397]                      __driver_probe_device+0x7c/0x17c
[    8.897410]                      driver_probe_device+0x38/0x11c
[    8.897422]                      __device_attach_driver+0xb4/0x164
[    8.897434]                      bus_for_each_drv+0x78/0xdc
[    8.897445]                      __device_attach+0xfc/0x1ac
[    8.897456]                      device_initial_probe+0x10/0x18
[    8.897469]                      bus_probe_device+0xa8/0xac
[    8.897480]                      deferred_probe_work_func+0x98/0xe8
[    8.897492]                      process_scheduled_works+0x23c/0x5b8
[    8.897506]                      worker_thread+0x188/0x374
[    8.897518]                      kthread+0xe4/0x10c
[    8.897529]                      ret_from_fork+0x10/0x20
[    8.897541]   }
[    8.897545]   ... key      at: [<ffff800082efc820>]__key.20703+0x0/0x10
[    8.897561]   ... acquired at:
[    8.897566]    _raw_spin_lock+0x3c/0x50
[    8.897580]    regcache_maple_write+0x268/0x314
[    8.897595]    regcache_write+0x68/0x84
[    8.897607]    _regmap_read+0xd0/0x1f4
[    8.897619]    _regmap_update_bits+0xe0/0x140
[    8.897631]    regmap_update_bits_base+0x60/0x8c
[    8.897643]    regmap_field_update_bits_base+0x30/0x38
[    8.897656]    vop2_plane_atomic_update+0x8b0/0x1400
[    8.897669]    drm_atomic_helper_commit_planes+0xdc/0x2a0
[    8.897683]    drm_atomic_helper_commit_tail_rpm+0x3c/0x78
[    8.897697]    commit_tail+0x9c/0x178
[    8.897709]    drm_atomic_helper_commit+0x17c/0x1ac
[    8.897722]    drm_atomic_commit+0xac/0xec
[    8.897735]    drm_client_modeset_commit_atomic+0x230/0x290
[    8.897746]    drm_client_modeset_commit_locked+0x54/0x1c4
[    8.897758]    drm_client_modeset_commit+0x2c/0x50
[    8.897767]    __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
[    8.897784]    drm_fb_helper_set_par+0x30/0x48
[    8.897797]    fbcon_init+0x40c/0x498
[    8.897807]    visual_init+0xb0/0x108
[    8.897816]    do_bind_con_driver+0x1b8/0x38c
[    8.897825]    do_take_over_console+0x148/0x1d4
[    8.897835]    do_fbcon_takeover+0x6c/0xe0
[    8.897844]    fbcon_fb_registered+0x1f8/0x1fc
[    8.897854]    register_framebuffer+0x158/0x228
[    8.897866]    __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
[    8.897882]    drm_fb_helper_initial_config+0x3c/0x48
[    8.897895]    drm_fbdev_generic_client_hotplug+0xb8/0xd8
[    8.897908]    drm_client_register+0x58/0xa0
[    8.897917]    drm_fbdev_generic_setup+0xbc/0x144
[    8.897929]    rockchip_drm_bind+0x1ec/0x1f8
[    8.897941]    try_to_bring_up_aggregate_device+0x278/0x2d8
[    8.897956]    __component_add+0xac/0x198
[    8.897967]    component_add+0x10/0x18
[    8.897979]    dw_hdmi_rockchip_probe+0x1c/0x24
[    8.897988]    platform_probe+0x90/0xd8
[    8.898002]    really_probe+0x114/0x3c0
[    8.898013]    __driver_probe_device+0x7c/0x17c
[    8.898026]    driver_probe_device+0x38/0x11c
[    8.898038]    __device_attach_driver+0xb4/0x164
[    8.898049]    bus_for_each_drv+0x78/0xdc
[    8.898059]    __device_attach+0xfc/0x1ac
[    8.898070]    device_initial_probe+0x10/0x18
[    8.898082]    bus_probe_device+0xa8/0xac
[    8.898093]    deferred_probe_work_func+0x98/0xe8
[    8.898105]    process_scheduled_works+0x23c/0x5b8
[    8.898118]    worker_thread+0x188/0x374
[    8.898131]    kthread+0xe4/0x10c
[    8.898142]    ret_from_fork+0x10/0x20
[    8.898153]
[    8.898157] ->(rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock){-...}-{2:2} ops: 74
{
[    8.898185]    IN-HARDIRQ-W at:
[    8.898194]                     lock_acquire+0x238/0x354
[    8.898211]                     _raw_spin_lock_irqsave+0x50/0x6c
[    8.898227]                     regmap_lock_spinlock+0x14/0x24
[    8.898238]                     regmap_read+0x38/0x70
[    8.898250]                     vop2_isr+0x88/0x2ac
[    8.898263]                     __handle_irq_event_percpu+0xa4/0x2bc
[    8.898277]                     handle_irq_event_percpu+0x14/0x44
[    8.898290]                     handle_irq_event+0x44/0x90
[    8.898300]                     handle_fasteoi_irq+0xf8/0x1d4
[    8.898314]                     generic_handle_domain_irq+0x28/0x3c
[    8.898324]                     gic_handle_irq+0xb0/0x130
[    8.898334]                     call_on_irq_stack+0x24/0x34
[    8.898345]                     do_interrupt_handler+0xc4/0xdc
[    8.898359]                     el1_interrupt+0x3c/0x70
[    8.898375]                     el1h_64_irq_handler+0x14/0x1c
[    8.898390]                     el1h_64_irq+0x64/0x68
[    8.898398]                     default_idle_call+0xec/0x118
[    8.898409]                     do_idle+0x1c8/0x254
[    8.898420]                     cpu_startup_entry+0x30/0x38
[    8.898430]                     rest_init+0x13c/0x1cc
[    8.898440]                     arch_post_acpi_subsys_init+0x0/0x8
[    8.898455]                     start_kernel+0x7c0/0x968
[    8.898465]                     __primary_switched+0xb0/0xbc
[    8.898481]    INITIAL USE at:
[    8.898492]                    lock_acquire+0x238/0x354
[    8.898506]                    _raw_spin_lock_irqsave+0x50/0x6c
[    8.898520]                    regmap_lock_spinlock+0x14/0x24
[    8.898531]                    regmap_write+0x38/0x70
[    8.898544]                    vop2_crtc_atomic_enable+0xf64/0x1074
[    8.898560]                    drm_atomic_helper_commit_modeset_enables+0xac/0x264
[    8.898575]                    drm_atomic_helper_commit_tail_rpm+0x2c/0x78
[    8.898589]                    commit_tail+0x9c/0x178
[    8.898601]                    drm_atomic_helper_commit+0x17c/0x1ac
[    8.898615]                    drm_atomic_commit+0xac/0xec
[    8.898628]                    drm_client_modeset_commit_atomic+0x230/0x290
[    8.898639]                    drm_client_modeset_commit_locked+0x54/0x1c4
[    8.898649]                    drm_client_modeset_commit+0x2c/0x50
[    8.898660]                    __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
[    8.898675]                    drm_fb_helper_set_par+0x30/0x48
[    8.898689]                    fbcon_init+0x40c/0x498
[    8.898699]                    visual_init+0xb0/0x108
[    8.898709]                    do_bind_con_driver+0x1b8/0x38c
[    8.898719]                    do_take_over_console+0x148/0x1d4
[    8.898730]                    do_fbcon_takeover+0x6c/0xe0
[    8.898740]                    fbcon_fb_registered+0x1f8/0x1fc
[    8.898750]                    register_framebuffer+0x158/0x228
[    8.898763]                    __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
[    8.898779]                    drm_fb_helper_initial_config+0x3c/0x48
[    8.898793]                    drm_fbdev_generic_client_hotplug+0xb8/0xd8
[    8.898806]                    drm_client_register+0x58/0xa0
[    8.898815]                    drm_fbdev_generic_setup+0xbc/0x144
[    8.898830]                    rockchip_drm_bind+0x1ec/0x1f8
[    8.898842]                    try_to_bring_up_aggregate_device+0x278/0x2d8
[    8.898858]                    __component_add+0xac/0x198
[    8.898871]                    component_add+0x10/0x18
[    8.898885]                    dw_hdmi_rockchip_probe+0x1c/0x24
[    8.898894]                    platform_probe+0x90/0xd8
[    8.898909]                    really_probe+0x114/0x3c0
[    8.898921]                    __driver_probe_device+0x7c/0x17c
[    8.898933]                    driver_probe_device+0x38/0x11c
[    8.898945]                    __device_attach_driver+0xb4/0x164
[    8.898958]                    bus_for_each_drv+0x78/0xdc
[    8.898969]                    __device_attach+0xfc/0x1ac
[    8.898980]                    device_initial_probe+0x10/0x18
[    8.898993]                    bus_probe_device+0xa8/0xac
[    8.899004]                    deferred_probe_work_func+0x98/0xe8
[    8.899015]                    process_scheduled_works+0x23c/0x5b8
[    8.899029]                    worker_thread+0x188/0x374
[    8.899042]                    kthread+0xe4/0x10c
[    8.899053]                    ret_from_fork+0x10/0x20
[    8.899064]  }
[    8.899069]  ... key      at: [<ffff800082efbe90>]_key.73979+0x0/0x10
[    8.899086]  ... acquired at:
[    8.899091]    __lock_acquire+0x9d8/0x1950
[    8.899104]    lock_acquire+0x238/0x354
[    8.899117]    _raw_spin_lock_irqsave+0x50/0x6c
[    8.899131]    regmap_lock_spinlock+0x14/0x24
[    8.899142]    regmap_read+0x38/0x70
[    8.899154]    vop2_isr+0x88/0x2ac
[    8.899166]    __handle_irq_event_percpu+0xa4/0x2bc
[    8.899178]    handle_irq_event_percpu+0x14/0x44
[    8.899188]    handle_irq_event+0x44/0x90
[    8.899198]    handle_fasteoi_irq+0xf8/0x1d4
[    8.899211]    generic_handle_domain_irq+0x28/0x3c
[    8.899221]    gic_handle_irq+0xb0/0x130
[    8.899230]    call_on_irq_stack+0x24/0x34
[    8.899243]    do_interrupt_handler+0xc4/0xdc
[    8.899256]    el1_interrupt+0x3c/0x70
[    8.899270]    el1h_64_irq_handler+0x14/0x1c
[    8.899285]    el1h_64_irq+0x64/0x68
[    8.899293]    default_idle_call+0xec/0x118
[    8.899304]    do_idle+0x1c8/0x254
[    8.899313]    cpu_startup_entry+0x30/0x38
[    8.899321]    rest_init+0x13c/0x1cc
[    8.899331]    arch_post_acpi_subsys_init+0x0/0x8
[    8.899342]    start_kernel+0x7c0/0x968
[    8.899351]    __primary_switched+0xb0/0xbc
[    8.899365]
[    8.899368]
[    8.899368] stack backtrace:
[    8.899376] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-rc5-next-20231215 #514
[    8.899386] Hardware name: EmbedFire LubanCat 2 (DT)
[    8.899394] Call trace:
[    8.899399]  dump_backtrace+0xe4/0x124
[    8.899410]  show_stack+0x14/0x1c
[    8.899419]  dump_stack_lvl+0x78/0xd4
[    8.899430]  dump_stack+0x14/0x1c
[    8.899438]  print_irq_inversion_bug+0x28c/0x304
[    8.899453]  mark_lock.part.43+0x2c0/0x448
[    8.899466]  __lock_acquire+0x9d8/0x1950
[    8.899479]  lock_acquire+0x238/0x354
[    8.899492]  _raw_spin_lock_irqsave+0x50/0x6c
[    8.899507]  regmap_lock_spinlock+0x14/0x24
[    8.899517]  regmap_read+0x38/0x70
[    8.899528]  vop2_isr+0x88/0x2ac
[    8.899540]  __handle_irq_event_percpu+0xa4/0x2bc
[    8.899553]  handle_irq_event_percpu+0x14/0x44
[    8.899565]  handle_irq_event+0x44/0x90
[    8.899575]  handle_fasteoi_irq+0xf8/0x1d4
[    8.899589]  generic_handle_domain_irq+0x28/0x3c
[    8.899599]  gic_handle_irq+0xb0/0x130
[    8.899608]  call_on_irq_stack+0x24/0x34
[    8.899619]  do_interrupt_handler+0xc4/0xdc
[    8.899631]  el1_interrupt+0x3c/0x70
[    8.899645]  el1h_64_irq_handler+0x14/0x1c
[    8.899659]  el1h_64_irq+0x64/0x68
[    8.899669]  default_idle_call+0xec/0x118
[    8.899679]  do_idle+0x1c8/0x254
[    8.899689]  cpu_startup_entry+0x30/0x38
[    8.899698]  rest_init+0x13c/0x1cc
[    8.899708]  arch_post_acpi_subsys_init+0x0/0x8
[    8.899720]  start_kernel+0x7c0/0x968
[    8.899731]  __primary_switched+0xb0/0xbc
[    8.946839] Console: switching to colour frame buffer device 240x67
[   10.230883] rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device

Fixes: 81a06f1d02e5 ("Revert "drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume"")
Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
Closes: https://lore.kernel.org/all/98a9f15d-30ac-47bf-9b93-3aa2c9900f7b at samsung.com/
Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
---

 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 4beb04c83752..f2edaebfcaf9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -993,12 +993,6 @@ static void vop2_enable(struct vop2 *vop2)
 		return;
 	}
 
-	ret = regmap_reinit_cache(vop2->map, &vop2_regmap_config);
-	if (ret) {
-		drm_err(vop2->drm, "failed to reinit cache: %d\n", ret);
-		return;
-	}
-
 	if (vop2->data->soc_id == 3566)
 		vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
 
@@ -1030,6 +1024,8 @@ static void vop2_disable(struct vop2 *vop2)
 
 	pm_runtime_put_sync(vop2->dev);
 
+	regcache_drop_region(vop2->map, 0, vop2_regmap_config.max_register);
+
 	clk_disable_unprepare(vop2->pclk);
 	clk_disable_unprepare(vop2->aclk);
 	clk_disable_unprepare(vop2->hclk);
-- 
2.34.1



From stefan.nagy at ixypsilon.net  Sun Dec 17 02:10:08 2023
From: stefan.nagy at ixypsilon.net (Stefan Nagy)
Date: Sun, 17 Dec 2023 11:10:08 +0100
Subject: [PATCH] arm64: dts: rockchip: Increase maximum frequency of SPI
 flash for ROCK Pi 4A/B/C
In-Reply-To: <4fce0de996d6cc3056d972cd3fc3fb93@manjaro.org>
References: <20231215122848.59534-1-stefan.nagy@ixypsilon.net>
	 <33e632c38fa57053585c0016652ed8c8@manjaro.org>
	 <4fce0de996d6cc3056d972cd3fc3fb93@manjaro.org>
Message-ID: <2f5e3bacaedb979748417dff77364530f3fb7a62.camel@ixypsilon.net>

Am Freitag, dem 15.12.2023 um 19:20 +0100 schrieb Dragan Simic:
> On 2023-12-15 19:15, Dragan Simic wrote:
> > On 2023-12-15 13:28, Stefan Nagy wrote:
> > > The ROCK Pi 4A/B/C boards come with a 32 Mbit SPI NOR flash chip
> > > (XTX Technology Limited XT25F32) which has a maximum clock
> > > frequency of 108 MHz. However, the Rockchip SPI controller driver
> > > limits the maximum SPI clock frequency to 50 MHz. Use this limit
> > > for spi-max-freq.
> > > 
> > > This patch has been tested on ROCK Pi 4A.
> > > 
> > > Signed-off-by: Stefan Nagy <stefan.nagy at ixypsilon.net>
> > > ---
> > > ?arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts | 2 +-
> > > ?arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts | 2 +-
> > > ?arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts | 2 +-
> > > ?3 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> > > b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> > > index d5df8939a..30e63e62a 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> > > @@ -19,6 +19,6 @@ &spi1 {
> > > ????????flash at 0 {
> > > ????????????????compatible = "jedec,spi-nor";
> > > ????????????????reg = <0>;
> > > -???????????????spi-max-frequency = <10000000>;
> > > +???????????????spi-max-frequency = <50000000>;
> > > ????????};
> > > ?};
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> > > b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> > > index bee6d7588..7122bf6c0 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> > > @@ -37,7 +37,7 @@ &spi1 {
> > > ????????flash at 0 {
> > > ????????????????compatible = "jedec,spi-nor";
> > > ????????????????reg = <0>;
> > > -???????????????spi-max-frequency = <10000000>;
> > > +???????????????spi-max-frequency = <50000000>;
> > > ????????};
> > > ?};
> > > 
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> > > b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> > > index de2ebe4cb..8af75bc7c 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> > > @@ -49,7 +49,7 @@ &spi1 {
> > > ????????flash at 0 {
> > > ????????????????compatible = "jedec,spi-nor";
> > > ????????????????reg = <0>;
> > > -???????????????spi-max-frequency = <10000000>;
> > > +???????????????spi-max-frequency = <50000000>;
> > > ????????};
> > > ?};
> > 
> > It would be better to upstream these changes to the Linux kernel
> > first, and then sync them back to U-Boot.
> 
> Oops, my bad, sorry, I got confused with your other patch on the U-
> Boot mailing list.
> 
> Regarding the new spi-max-frequency value, it should be better to
> have it set to what the SPI chip actually supports, and let the SPI
> driver do its thing.

OK, I agree. I'll send a v2 of this patch with a new spi-max-frequency
of 108 MHz.



From andyshrk at 163.com  Sun Dec 17 02:39:58 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 17 Dec 2023 18:39:58 +0800
Subject: [PATCH 1/2] arm: dts: rockchip: Add psci for rk3036
Message-ID: <20231217103959.2380661-1-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>

The system will hang at bringup secondary CPUs
without psci node.

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
---

 arch/arm/boot/dts/rockchip/rk3036.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
index 78686fc72ce6..5344803442a1 100644
--- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
@@ -67,6 +67,11 @@ display-subsystem {
 		ports = <&vop_out>;
 	};
 
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		arm,cpu-registers-not-fw-configured;
-- 
2.34.1



From andyshrk at 163.com  Sun Dec 17 02:39:59 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 17 Dec 2023 18:39:59 +0800
Subject: [PATCH 2/2] arm: dts: rockchip: Add stdout-patch for rk3036 kylin
In-Reply-To: <20231217103959.2380661-1-andyshrk@163.com>
References: <20231217103959.2380661-1-andyshrk@163.com>
Message-ID: <20231217103959.2380661-2-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>

Add stdout-patch to get a uart console when system boot.

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
---

 arch/arm/boot/dts/rockchip/rk3036-kylin.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
index 67e1e04139e7..f12fa3831bbf 100644
--- a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
@@ -8,6 +8,10 @@ / {
 	model = "Rockchip RK3036 KylinBoard";
 	compatible = "rockchip,rk3036-kylin", "rockchip,rk3036";
 
+	chosen {
+		stdout-path = "serial2:115200n8";
+	};
+
 	memory at 60000000 {
 		device_type = "memory";
 		reg = <0x60000000 0x20000000>;
-- 
2.34.1



From kvalo at kernel.org  Sun Dec 17 03:17:16 2023
From: kvalo at kernel.org (Kalle Valo)
Date: Sun, 17 Dec 2023 11:17:16 +0000 (UTC)
Subject: [PATCH v2][wireless-next/for-next] wifi: mt76: mt7996: Use
 DECLARE_FLEX_ARRAY() and fix -Warray-bounds warnings
In-Reply-To: <ZXiU9ayVCslt3qiI@work>
References: <ZXiU9ayVCslt3qiI@work>
Message-ID: <170281183364.2255653.11348778745254559115.kvalo@kernel.org>

"Gustavo A. R. Silva" <gustavoars at kernel.org> wrote:

> Transform zero-length arrays `rate`, `adm_stat` and `msdu_cnt` into
> proper flexible-array members in anonymous union in `struct
> mt7996_mcu_all_sta_info_event` via the DECLARE_FLEX_ARRAY()
> helper; and fix multiple -Warray-bounds warnings:
> 
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:544:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:551:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:553:58: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:530:61: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:538:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:540:66: warning: array subscript <unknown> is outside array bounds of 'struct <anonymous>[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:520:57: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:526:76: warning: array subscript <unknown> is outside array bounds of 'struct all_sta_trx_rate[0]' [-Warray-bounds=]
> 
> This results in no differences in binary output, helps with the ongoing
> efforts to globally enable -Warray-bounds.
> 
> Reviewed-by: Kees Cook <keescook at chromium.org>
> Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org>

Patch applied to wireless-next.git, thanks.

40d51f70f082 wifi: mt76: mt7996: Use DECLARE_FLEX_ARRAY() and fix -Warray-bounds warnings

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/ZXiU9ayVCslt3qiI at work/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From peter.ujfalusi at gmail.com  Sun Dec 17 03:18:59 2023
From: peter.ujfalusi at gmail.com (=?UTF-8?Q?P=C3=A9ter_Ujfalusi?=)
Date: Sun, 17 Dec 2023 13:18:59 +0200
Subject: [PATCH v2 3/4] dmaengine: ti: k3-udma-glue: Add function to
 request TX channel by ID
In-Reply-To: <4f13681a-dc13-4de2-a0d5-9f85a4c350d4@ti.com>
References: <20231212111011.1401641-1-s-vadapalli@ti.com>
 <20231212111011.1401641-4-s-vadapalli@ti.com>
 <800ccf2e-65cc-4524-8a42-1657a5906482@gmail.com>
 <4f13681a-dc13-4de2-a0d5-9f85a4c350d4@ti.com>
Message-ID: <604657b5-0b88-4108-afd3-8cc88e10b16c@gmail.com>



On 15/12/2023 08:08, Siddharth Vadapalli wrote:
>>>  err:
>>> @@ -395,6 +410,40 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>>>  }
>>>  EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn);
>>>  
>>> +struct k3_udma_glue_tx_channel *
>>> +k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg,
>>> +				  struct device_node *udmax_np, u32 thread_id)
>>
>> udmax_np is not dev->of_node ?
> 
> I am not sure I fully understand the question. If you meant to ask if the driver
> which uses this API will not have its device's of_node set to udmax_np, then yes
> that's correct.
> 
> The driver shall be probed over RPMsg-bus, due to which its device's of_node
> will not be udmax_np. Additionally, the udmax_np is the device-tree node of one
> of the DMA Controllers described in the device-tree. The driver shall obtain the
> reference to the udmax_np node using the API:
> of_find_compatible_node()
> with the compatible to be passed to the above API being a part of the driver's
> data. Thus, it is possible to specify which DMA Controller to use by specifying
> the compatible in the driver's data. I hope that I have answered your question.
> Please let me know otherwise.

I see, thank you for the detailed explanation!

> Thank you for reviewing the series. I will rename the API as mentioned above and
> if the question you had above regarding the of_node has been addressed, I will
> post the v3 series. Kindly let me know.

I don't have other open issues, thanks for the updates

-- 
P?ter


From maz at kernel.org  Sun Dec 17 03:26:15 2023
From: maz at kernel.org (Marc Zyngier)
Date: Sun, 17 Dec 2023 11:26:15 +0000
Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset
In-Reply-To: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
Message-ID: <87a5q983zc.wl-maz@kernel.org>

On Thu, 14 Dec 2023 12:13:57 +0000,
Kunkun Jiang <jiangkunkun at huawei.com> wrote:
> 
> Hi list,
> 
> We have observed on GICv4.1 systems that, after a guest reset, the
> secondary VCPU would receive an IPI_CPU_STOP accidently and failed to
> come online eventually.
> 
> | Guest User-space

Guest userspace????

> |
> | reset (with a vSGI pending in the
> | hardware) [0]
> |
> | disable the distributor (write 0
> | into GICD_CTLR) [1]
> |
> | clear pending status (write 0 into
> | GICR_ISPENDR0 for each RD) [2]

This cannot clear the pending bits. Writing 0 to any of the
ISPEND/ICPEND registers is effectively a NOP.

If you want to remove the pending SGIs, you need to write a bunch of
1s to ICPENDR0.

> |
> | disable the distributor (write 0
> | into GICD_CTLR) [3]
> |
> | enable the distributor with ARE,
> | Group1 and nASSGIreq [4]
> 
> The problem is that even if user-space tries to disable the distributor

I don't understand what userspace does here. Why is it significant
that it is an EL0 access? I don't know of any SW doing that, but even
if it existed, this should make no difference.

> and clear pending bits for all SGIs, we don't actually propogate it into
> HW (we only record it via vgic_dist->{enabled, nassgireq} and
> vgic_irq->pending_latch) and the vSGI remains pending across the guest
> reset.
>
> And when we're at [4], all vSGI's vgic_irq->hw are *true* and
> vgic_v4_enable_vsgis() becomes a nop.. That's not good.
> 
> The following solution can solve the problem. Not sure if this is a good
> solution.Sent out early for suggestions or solutions.
> 
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> index 89117ba2528a..3678ab33f5b9 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> @@ -374,6 +374,10 @@ static int vgic_v3_uaccess_write_pending(struct
> kvm_vcpu *vcpu,
> ???? ??? ??? irq->pending_latch = true;
> ???? ??? ??? vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> ???? ??? } else {
> + ??? ??? ??? if (irq->hw && vgic_irq_is_sgi(irq->intid))
> + ??? ??? ??? ??? irq_set_irqchip_state(irq->host_irq,
> + ??? ??? ??? ??? ??? ??? ???? IRQCHIP_STATE_PENDING,
> + ??? ??? ??? ??? ??? ??? ???? false);
> ???? ??? ??? irq->pending_latch = false;
> ???? ??? ??? raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
> ???? ??? }
> 

But this has *nothing* to do with the guest. This is the *host*
userspace performing a write to the redistributor view, which has
different semantics. Which is why your earlier description made no
sense to me.

I think the problem is slightly larger than what you describe. A write
to ISPENDR0 should be propagated to the ITS for any values of the
latch, just like this happens on enabling HW-backed SGIs.

Can you please give this a go?

Thanks,

	M.

From 9932d74392d969057e84bc3c18bd15f1769b6211 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <maz at kernel.org>
Date: Sun, 17 Dec 2023 11:15:09 +0000
Subject: [PATCH] KVM: arm64: vgic-v4: Restore pending state on host userspace
 write

When the VMM writes to ISPENDR0 to set the state pending state of
an SGI, we fail to convey this to the HW if this SGI is already
backed by a GICv4.1 vSGI.

This is a bit of a corner case, as this would only occur if the
vgic state is changed on an already running VM, but this can
apparently happen across a guest reset driven by the VMM.

Fix this by always writing out the pending_latch value to the
HW, and reseting it to false.

Reported-by: Kunkun Jiang <jiangkunkun at huawei.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32 at huawei.com
---
 arch/arm64/kvm/vgic/vgic-mmio-v3.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index a764b0ab8bf9..2533f264b954 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -365,19 +365,26 @@ static int vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
 		struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
 
 		raw_spin_lock_irqsave(&irq->irq_lock, flags);
-		if (test_bit(i, &val)) {
-			/*
-			 * pending_latch is set irrespective of irq type
-			 * (level or edge) to avoid dependency that VM should
-			 * restore irq config before pending info.
-			 */
-			irq->pending_latch = true;
-			vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
-		} else {
+
+		/*
+		 * pending_latch is set irrespective of irq type
+		 * (level or edge) to avoid dependency that VM should
+		 * restore irq config before pending info.
+		 */
+		irq->pending_latch = test_bit(i, &val);
+
+		if (irq->hw && vgic_irq_is_sgi(irq->intid)) {
+			irq_set_irqchip_state(irq->host_irq,
+					      IRQCHIP_STATE_PENDING,
+					      irq->pending_latch);
 			irq->pending_latch = false;
-			raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
 		}
 
+		if (irq->pending_latch)
+			vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
+		else
+			raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
+
 		vgic_put_irq(vcpu->kvm, irq);
 	}
 
-- 
2.39.2


-- 
Without deviation from the norm, progress is not possible.


From stefan.nagy at ixypsilon.net  Sun Dec 17 03:32:08 2023
From: stefan.nagy at ixypsilon.net (Stefan Nagy)
Date: Sun, 17 Dec 2023 12:32:08 +0100
Subject: [PATCH v2] arm64: dts: rockchip: Increase maximum frequency of SPI flash for ROCK Pi 4A/B/C
Message-ID: <20231217113208.64056-1-stefan.nagy@ixypsilon.net>

The ROCK Pi 4A/B/C boards come with a 32 Mbit SPI NOR flash chip (XTX
Technology Limited XT25F32) with a maximum clock frequency of 108 MHz.
Use this value for the device node's spi-max-frequency property.

This patch has been tested on ROCK Pi 4A.

Signed-off-by: Stefan Nagy <stefan.nagy at ixypsilon.net>
---
Changes from v1:
- Use the maximum clock frequency the SPI chip actually supports
  instead of the SPI clock frequency limit of 50 MHz set by the
  Rockchip SPI driver.
---
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts | 2 +-
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts | 2 +-
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
index d5df8939a..c68f45849 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
@@ -19,6 +19,6 @@ &spi1 {
 	flash at 0 {
 		compatible = "jedec,spi-nor";
 		reg = <0>;
-		spi-max-frequency = <10000000>;
+		spi-max-frequency = <108000000>;
 	};
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
index bee6d7588..6ea3180e5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
@@ -37,7 +37,7 @@ &spi1 {
 	flash at 0 {
 		compatible = "jedec,spi-nor";
 		reg = <0>;
-		spi-max-frequency = <10000000>;
+		spi-max-frequency = <108000000>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
index de2ebe4cb..5274938bf 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
@@ -49,7 +49,7 @@ &spi1 {
 	flash at 0 {
 		compatible = "jedec,spi-nor";
 		reg = <0>;
-		spi-max-frequency = <10000000>;
+		spi-max-frequency = <108000000>;
 	};
 };
 
-- 
2.30.2



From arinc.unal at arinc9.com  Sun Dec 17 03:39:46 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Sun, 17 Dec 2023 14:39:46 +0300
Subject: [PATCH net-next 01/15] net: dsa: mt7530: always trap frames to
 active CPU port on MT7530
In-Reply-To: <20231207174829.jccyws7myhxbgr5k@skbuf>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-2-arinc.unal@arinc9.com>
 <ZVjLj6/iCL/muzmH@shell.armlinux.org.uk>
 <ffaa26b3-eb25-47cc-8891-fe3cbcc724da@arinc9.com>
 <20231207174829.jccyws7myhxbgr5k@skbuf>
Message-ID: <f830ac10-8ab3-4660-8e9f-762bb41aca78@arinc9.com>

On 7.12.2023 20:48, Vladimir Oltean wrote:
> On Sat, Dec 02, 2023 at 11:29:18AM +0300, Ar?n? ?NAL wrote:
>>>>    struct mt7530_priv {
>>>>    	struct device		*dev;
>>>> @@ -786,6 +787,7 @@ struct mt7530_priv {
>>>>    	struct irq_domain *irq_domain;
>>>>    	u32 irq_enable;
>>>>    	int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii);
>>>> +	unsigned long active_cpu_ports;
>>>
>>> So this will be 32 or 64 bit in size. Presumably you know how many CPU
>>> ports there can be, which looking at this code must be less than 8 as
>>> CPU_PORT_MASK is only 3 bits in size. So, maybe use a u8, and check
>>> that cpu_dp->index <= 7 ?
> 
> We picked "unsigned long" as storage because that's also the size of the
> argument that __ffs() takes. But admittedly, we could have also stored a
> smaller variable and promote it to unsigned long when we pass it to __ffs().
> 
>> Aren't there other mechanisms to check that cpu_dp->index is a valid port?
> 
> cpu_dp->index is guaranteed by DSA to be valid (according to the "reg"
> value from the device tree and smaller than ds->num_ports). It's just a
> question of balancing this kind of optimization with the possibility
> that a future switch appears which has more than MT7530_NUM_PORTS (7) ports.

If this was to happen - as unlikely as I find it - I would suggest adding a
new MTXXXX_NUM_PORTS and set priv->ds->num_ports to it after checking
priv->id. I'm a maintainer here so I'll keep an eye out.

> 
>>
>> 	mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val);
>> }
>>
>> struct mt7530_priv {
>> 	[...]
>> 	u8 active_cpu_ports;
>> };
> 
> Actually, looking at the code now, I don't understand why we even keep
> track of the active_cpu_ports mask in the driver. We could read the
> MT7530_MFC register in mt753x_conduit_state_change(), flip the bit
> corresponding just to cpu_dp->index (rather than rmw all of CPU_PORT_MASK),
> and write back the result. And to address Russell's concern, we could test
> whether the resulting CPU_PORT_MASK portion of what we're going to write
> back is all-zeroes or not, and if it is, clear the CPU_EN bit, otherwise
> set it.

Correct me if I'm wrong, we introduced priv->active_cpu_ports because
CPU_PORT_MASK from the MT7530_MFC register is a 3-bit mask, meant to keep a
single port number ranging from 0 to 7. There's no single bit corresponding
to cpu_dp->index on the MT7530_MFC register. So I don't see how what you
suggest here would work.

This is what I've got right now:

static void
mt753x_conduit_state_change(struct dsa_switch *ds,
			    const struct net_device *conduit,
			    bool operational)
{
	struct dsa_port *cpu_dp = conduit->dsa_ptr;
	struct mt7530_priv *priv = ds->priv;
	u8 mask;
	int val = 0;

	/* Set the CPU port to trap frames to for MT7530. Trapped frames will be
	 * forwarded to the numerically smallest CPU port which the DSA conduit
	 * interface its affine to is up.
	 */
	if (priv->id != ID_MT7530 && priv->id != ID_MT7621)
		return;

	mask = BIT(cpu_dp->index);

	if (operational)
		priv->active_cpu_ports |= mask;
	else
		priv->active_cpu_ports &= ~mask;

	if (priv->active_cpu_ports)
		val =
		    CPU_EN |
		    CPU_PORT(__ffs((unsigned long)priv->active_cpu_ports));

	mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val);
}

> 
>>
>>>
>>> I would also suggest moving irq_enable after create_sgmii, to avoid
>>> holes in the struct.
>>
>> Sorry, I've got no idea about this. Could you explain why would there
>> possibly be holes in the struct with the current ordering of the members of
>> the mt7530_priv structure?
>>
>> Ar?n?
> 
> FWIW:
> 
> $ pahole -C mt7530_priv $KBUILD_OUTPUT/drivers/net/dsa/mt7530.o
> struct mt7530_priv {
>          struct device *            dev;                  /*     0     8 */
>          struct dsa_switch *        ds;                   /*     8     8 */
>          struct mii_bus *           bus;                  /*    16     8 */
>          struct regmap *            regmap;               /*    24     8 */
>          struct reset_control *     rstc;                 /*    32     8 */
>          struct regulator *         core_pwr;             /*    40     8 */
>          struct regulator *         io_pwr;               /*    48     8 */
>          struct gpio_desc *         reset;                /*    56     8 */
>          /* --- cacheline 1 boundary (64 bytes) --- */
>          const struct mt753x_info  * info;                /*    64     8 */
>          unsigned int               id;                   /*    72     4 */
>          bool                       mcm;                  /*    76     1 */
> 
>          /* XXX 3 bytes hole, try to pack */
> 
>          phy_interface_t            p6_interface;         /*    80     4 */
>          phy_interface_t            p5_interface;         /*    84     4 */
>          unsigned int               p5_intf_sel;          /*    88     4 */
>          u8                         mirror_rx;            /*    92     1 */
>          u8                         mirror_tx;            /*    93     1 */
> 
>          /* XXX 2 bytes hole, try to pack */
> 
>          struct mt7530_port         ports[7];             /*    96   168 */
>          /* --- cacheline 4 boundary (256 bytes) was 8 bytes ago --- */
>          struct mt753x_pcs          pcs[7];               /*   264   280 */
>          /* --- cacheline 8 boundary (512 bytes) was 32 bytes ago --- */
>          struct mutex               reg_mutex;            /*   544    32 */
>          /* --- cacheline 9 boundary (576 bytes) --- */
>          int                        irq;                  /*   576     4 */
> 
>          /* XXX 4 bytes hole, try to pack */
> 
>          struct irq_domain *        irq_domain;           /*   584     8 */
>          u32                        irq_enable;           /*   592     4 */
> 
>          /* XXX 4 bytes hole, try to pack */
> 
>          int                        (*create_sgmii)(struct mt7530_priv *, bool); /*   600     8 */
>          unsigned long              active_cpu_ports;     /*   608     8 */
> 
>          /* size: 616, cachelines: 10, members: 24 */
>          /* sum members: 603, holes: 4, sum holes: 13 */
>          /* last cacheline: 40 bytes */
> };
> 
> It's not like this makes any practical difference, as struct mt7530_priv
> isn't used from hot paths, but tidying it up is a good sign of clean,
> careful development, and of understanding memory alignment.

Got it, thanks. I've got a few patches that introduce changes to the
mt7530_priv structure. I'll make sure that, in the end, mt7530_priv won't
have any holes.

Ar?n?


From arinc.unal at arinc9.com  Sun Dec 17 04:01:02 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Sun, 17 Dec 2023 15:01:02 +0300
Subject: [PATCH net-next 05/15] net: dsa: mt7530: improve code path for
 setting up port 5
In-Reply-To: <20231207180332.ugfp33xcdkw3elrw@skbuf>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-6-arinc.unal@arinc9.com>
 <ZVjNJ0nf7Mp0kHzH@shell.armlinux.org.uk>
 <5e95a436-189f-412e-b409-89a003003292@arinc9.com>
 <20231207180332.ugfp33xcdkw3elrw@skbuf>
Message-ID: <968d0374-2584-42dd-9ec4-c30fb01c5202@arinc9.com>

On 7.12.2023 21:03, Vladimir Oltean wrote:
> On Sat, Dec 02, 2023 at 11:36:03AM +0300, Ar?n? ?NAL wrote:
>> On 18.11.2023 17:41, Russell King (Oracle) wrote:
>>>> For the cases of PHY muxing or the port being disabled, call
>>>> mt7530_setup_port5() from mt7530_setup(). mt7530_setup_port5() from
>>>> mt753x_phylink_mac_config() won't run when port 5 is disabled or used for
>>>> PHY muxing as port 5 won't be defined on the devicetree.
>>>
>>> ... and this should state why this needs to happen - in other words,
>>> the commit message should state why is it critical that port 5 is
>>> always setup.
>>
>> Actually, port 5 must not always be setup. With patch 7, I explain this
>> while preventing mt7530_setup_port5() from running if port 5 is disabled.
>>
>> Ar?n?
> 
> Then change that last paragraph. You could say something like this:
> 
> To keep the cases where port 5 isn't controlled by phylink working as
> before, we need to preserve the mt7530_setup_port5() call from mt7530_setup().
> 
> I think it's a case of saying too much, which sparks too many unresolved
> questions in the reader's mind, which are irrelevant for the purpose of
> this specific change: eliminating the overlap between DSA's setup() time
> and phylink.

Will do, thanks.


From arinc.unal at arinc9.com  Sun Dec 17 04:22:27 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Sun, 17 Dec 2023 15:22:27 +0300
Subject: [PATCH net-next 07/15] net: dsa: mt7530: do not run
 mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <20231208184652.k2max4kf7r3fgksg@skbuf>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-8-arinc.unal@arinc9.com>
 <20231121185358.GA16629@kernel.org>
 <a2826485-70a6-4ba7-89e1-59e68e622901@arinc9.com>
 <90fde560-054e-4188-b15c-df2e082d3e33@moroto.mountain>
 <20231207184015.u7uoyfhdxiyuw6hh@skbuf>
 <9b729dab-aebc-4c0c-a5e1-164845cd0948@suswa.mountain>
 <20231208184652.k2max4kf7r3fgksg@skbuf>
Message-ID: <c3a0fc6a-825c-4de3-b5cf-b454a6d4d3cf@arinc9.com>

On 8.12.2023 21:46, Vladimir Oltean wrote:
> Hmm, maybe the problem, all along, was that we let the -ENODEV return
> code from of_get_phy_mode() pass through? "interface" will really be
> uninitialized in that case. It's not a false positive.
> 
> Instead of:
> 
> 	ret = of_get_phy_mode(mac_np, &interface);
> 	if (ret && ret != -ENODEV) {
> 		...
> 		return ret;
> 	}
> 
> it should have been like this, to not complain:
> 
> 	ret = of_get_phy_mode(mac_np, &interface);
> 	if (ret) {
> 		...
> 		return ret;
> 	}
> 

I just tried this, smatch still reports "interface" as uninitialised.

$ export ARCH=mips CROSS_COMPILE=mips-linux-gnu-
$ ../smatch/smatch_scripts/kchecker --spammy drivers/net/dsa/mt7530.c

   UPD     include/config/kernel.release
   UPD     include/generated/utsrelease.h
   CHECK   scripts/mod/empty.c
   CALL    scripts/checksyscalls.sh
   CC      drivers/net/dsa/mt7530.o
   CHECK   drivers/net/dsa/mt7530.c
drivers/net/dsa/mt7530.c:217 mt7530_mii_read() warn: call of 'warn_slowpath_fmt' with non-constant format argument
drivers/net/dsa/mt7530.c:454 mt7530_setup_port6() error: uninitialized symbol 'ncpo1'.
drivers/net/dsa/mt7530.c:868 mt7530_set_ageing_time() error: uninitialized symbol 'age_count'.
drivers/net/dsa/mt7530.c:868 mt7530_set_ageing_time() error: uninitialized symbol 'age_unit'.
drivers/net/dsa/mt7530.c:2324 mt7530_setup() error: uninitialized symbol 'interface'.

Ar?n?


From jic23 at kernel.org  Sun Dec 17 04:37:17 2023
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sun, 17 Dec 2023 12:37:17 +0000
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type
 to size_t
In-Reply-To: <20231214170146.641783-1-francesco@dolcini.it>
References: <20231214170146.641783-1-francesco@dolcini.it>
Message-ID: <20231217123717.4e162b70@jic23-huawei>

On Thu, 14 Dec 2023 18:01:46 +0100
Francesco Dolcini <francesco at dolcini.it> wrote:

> From: Francesco Dolcini <francesco.dolcini at toradex.com>
> 
> receive_buf() is called from ttyport_receive_buf() that expects values
> ">= 0" from serdev_controller_receive_buf(), change its return type from  
> ssize_t to size_t.
> 
> Suggested-by: Jiri Slaby <jirislaby at kernel.org>
> Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc at kernel.org/
> Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>

IIO ones look fine to me so for next version

Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com> #for-iio
> ---
> hello,
> patch is based on current linux next.
> 
> It has an obvious problem, it touches files from multiple subsystem in a single
> patch that is complicated to review and eventually merge, just splitting this
> would however not work, it will break bisectability and the build.
> 
> I am looking for advise on the best way to move forward.
> 
> I see the following options:
>  - keep it as it is
>  - break it down with a patch with each subsystem, and squash before applying
>    from a single (tty?) subsystem
>  - go for a multi stage approach, defining a new callback, move to it and in
>    the end remove the original one, likewise it was done for i2c lately
> 
> ---
>  drivers/bluetooth/btmtkuart.c              |  4 ++--
>  drivers/bluetooth/btnxpuart.c              |  4 ++--
>  drivers/bluetooth/hci_serdev.c             |  4 ++--
>  drivers/gnss/core.c                        |  6 +++---
>  drivers/gnss/serial.c                      |  4 ++--
>  drivers/gnss/sirf.c                        |  6 +++---
>  drivers/greybus/gb-beagleplay.c            |  6 +++---
>  drivers/iio/chemical/pms7003.c             |  4 ++--
>  drivers/iio/chemical/scd30_serial.c        |  4 ++--
>  drivers/iio/chemical/sps30_serial.c        |  4 ++--
>  drivers/iio/imu/bno055/bno055_ser_core.c   |  4 ++--
>  drivers/mfd/rave-sp.c                      |  4 ++--
>  drivers/net/ethernet/qualcomm/qca_uart.c   |  2 +-
>  drivers/nfc/pn533/uart.c                   |  4 ++--
>  drivers/nfc/s3fwrn5/uart.c                 |  4 ++--
>  drivers/platform/chrome/cros_ec_uart.c     |  4 ++--
>  drivers/platform/surface/aggregator/core.c |  4 ++--
>  drivers/tty/serdev/serdev-ttyport.c        | 10 ++++------
>  include/linux/gnss.h                       |  4 ++--
>  include/linux/serdev.h                     |  8 ++++----
>  sound/drivers/serial-generic.c             |  4 ++--
>  21 files changed, 48 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
> index 3c84fcbda01a..e6bc4a73c9fc 100644
> --- a/drivers/bluetooth/btmtkuart.c
> +++ b/drivers/bluetooth/btmtkuart.c
> @@ -383,8 +383,8 @@ static void btmtkuart_recv(struct hci_dev *hdev, const u8 *data, size_t count)
>  	}
>  }
>  
> -static ssize_t btmtkuart_receive_buf(struct serdev_device *serdev,
> -				     const u8 *data, size_t count)
> +static size_t btmtkuart_receive_buf(struct serdev_device *serdev,
> +				    const u8 *data, size_t count)
>  {
>  	struct btmtkuart_dev *bdev = serdev_device_get_drvdata(serdev);
>  
> diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> index 1d592ac413d1..056bef5b2919 100644
> --- a/drivers/bluetooth/btnxpuart.c
> +++ b/drivers/bluetooth/btnxpuart.c
> @@ -1264,8 +1264,8 @@ static const struct h4_recv_pkt nxp_recv_pkts[] = {
>  	{ NXP_RECV_FW_REQ_V3,   .recv = nxp_recv_fw_req_v3 },
>  };
>  
> -static ssize_t btnxpuart_receive_buf(struct serdev_device *serdev,
> -				     const u8 *data, size_t count)
> +static size_t btnxpuart_receive_buf(struct serdev_device *serdev,
> +				    const u8 *data, size_t count)
>  {
>  	struct btnxpuart_dev *nxpdev = serdev_device_get_drvdata(serdev);
>  
> diff --git a/drivers/bluetooth/hci_serdev.c b/drivers/bluetooth/hci_serdev.c
> index 39c8b567da3c..a3c3beb2806d 100644
> --- a/drivers/bluetooth/hci_serdev.c
> +++ b/drivers/bluetooth/hci_serdev.c
> @@ -271,8 +271,8 @@ static void hci_uart_write_wakeup(struct serdev_device *serdev)
>   *
>   * Return: number of processed bytes
>   */
> -static ssize_t hci_uart_receive_buf(struct serdev_device *serdev,
> -				    const u8 *data, size_t count)
> +static size_t hci_uart_receive_buf(struct serdev_device *serdev,
> +				   const u8 *data, size_t count)
>  {
>  	struct hci_uart *hu = serdev_device_get_drvdata(serdev);
>  
> diff --git a/drivers/gnss/core.c b/drivers/gnss/core.c
> index 48f2ee0f78c4..9b8a0605ec76 100644
> --- a/drivers/gnss/core.c
> +++ b/drivers/gnss/core.c
> @@ -317,10 +317,10 @@ EXPORT_SYMBOL_GPL(gnss_deregister_device);
>   *
>   * Must not be called for a closed device.
>   */
> -int gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> -				size_t count)
> +size_t gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> +		       size_t count)
>  {
> -	int ret;
> +	size_t ret;
>  
>  	ret = kfifo_in(&gdev->read_fifo, buf, count);
>  
> diff --git a/drivers/gnss/serial.c b/drivers/gnss/serial.c
> index baa956494e79..bf55aa2c1cf0 100644
> --- a/drivers/gnss/serial.c
> +++ b/drivers/gnss/serial.c
> @@ -80,8 +80,8 @@ static const struct gnss_operations gnss_serial_gnss_ops = {
>  	.write_raw	= gnss_serial_write_raw,
>  };
>  
> -static ssize_t gnss_serial_receive_buf(struct serdev_device *serdev,
> -				       const u8 *buf, size_t count)
> +static size_t gnss_serial_receive_buf(struct serdev_device *serdev,
> +				      const u8 *buf, size_t count)
>  {
>  	struct gnss_serial *gserial = serdev_device_get_drvdata(serdev);
>  	struct gnss_device *gdev = gserial->gdev;
> diff --git a/drivers/gnss/sirf.c b/drivers/gnss/sirf.c
> index 6801a8fb2040..2aae3c02156d 100644
> --- a/drivers/gnss/sirf.c
> +++ b/drivers/gnss/sirf.c
> @@ -160,12 +160,12 @@ static const struct gnss_operations sirf_gnss_ops = {
>  	.write_raw	= sirf_write_raw,
>  };
>  
> -static ssize_t sirf_receive_buf(struct serdev_device *serdev,
> -				const u8 *buf, size_t count)
> +static size_t sirf_receive_buf(struct serdev_device *serdev,
> +			       const u8 *buf, size_t count)
>  {
>  	struct sirf_data *data = serdev_device_get_drvdata(serdev);
>  	struct gnss_device *gdev = data->gdev;
> -	int ret = 0;
> +	size_t ret = 0;
>  
>  	if (!data->wakeup && !data->active) {
>  		data->active = true;
> diff --git a/drivers/greybus/gb-beagleplay.c b/drivers/greybus/gb-beagleplay.c
> index 2da37ff92cf1..26c95efe2fff 100644
> --- a/drivers/greybus/gb-beagleplay.c
> +++ b/drivers/greybus/gb-beagleplay.c
> @@ -257,7 +257,7 @@ static void hdlc_rx_frame(struct gb_beagleplay *bg)
>  	}
>  }
>  
> -static ssize_t hdlc_rx(struct gb_beagleplay *bg, const u8 *data, size_t count)
> +static size_t hdlc_rx(struct gb_beagleplay *bg, const u8 *data, size_t count)
>  {
>  	size_t i;
>  	u8 c;
> @@ -317,8 +317,8 @@ static void hdlc_deinit(struct gb_beagleplay *bg)
>  	flush_work(&bg->tx_work);
>  }
>  
> -static ssize_t gb_tty_receive(struct serdev_device *sd, const u8 *data,
> -			      size_t count)
> +static size_t gb_tty_receive(struct serdev_device *sd, const u8 *data,
> +			     size_t count)
>  {
>  	struct gb_beagleplay *bg = serdev_device_get_drvdata(sd);
>  
> diff --git a/drivers/iio/chemical/pms7003.c b/drivers/iio/chemical/pms7003.c
> index b5cf15a515d2..43025866d5b7 100644
> --- a/drivers/iio/chemical/pms7003.c
> +++ b/drivers/iio/chemical/pms7003.c
> @@ -211,8 +211,8 @@ static bool pms7003_frame_is_okay(struct pms7003_frame *frame)
>  	return checksum == pms7003_calc_checksum(frame);
>  }
>  
> -static ssize_t pms7003_receive_buf(struct serdev_device *serdev, const u8 *buf,
> -				   size_t size)
> +static size_t pms7003_receive_buf(struct serdev_device *serdev, const u8 *buf,
> +				  size_t size)
>  {
>  	struct iio_dev *indio_dev = serdev_device_get_drvdata(serdev);
>  	struct pms7003_state *state = iio_priv(indio_dev);
> diff --git a/drivers/iio/chemical/scd30_serial.c b/drivers/iio/chemical/scd30_serial.c
> index a47654591e55..2adb76dbb020 100644
> --- a/drivers/iio/chemical/scd30_serial.c
> +++ b/drivers/iio/chemical/scd30_serial.c
> @@ -174,8 +174,8 @@ static int scd30_serdev_command(struct scd30_state *state, enum scd30_cmd cmd, u
>  	return 0;
>  }
>  
> -static ssize_t scd30_serdev_receive_buf(struct serdev_device *serdev,
> -					const u8 *buf, size_t size)
> +static size_t scd30_serdev_receive_buf(struct serdev_device *serdev,
> +				       const u8 *buf, size_t size)
>  {
>  	struct iio_dev *indio_dev = serdev_device_get_drvdata(serdev);
>  	struct scd30_serdev_priv *priv;
> diff --git a/drivers/iio/chemical/sps30_serial.c b/drivers/iio/chemical/sps30_serial.c
> index 3afa89f8acc3..a6dfbe28c914 100644
> --- a/drivers/iio/chemical/sps30_serial.c
> +++ b/drivers/iio/chemical/sps30_serial.c
> @@ -210,8 +210,8 @@ static int sps30_serial_command(struct sps30_state *state, unsigned char cmd,
>  	return rsp_size;
>  }
>  
> -static ssize_t sps30_serial_receive_buf(struct serdev_device *serdev,
> -					const u8 *buf, size_t size)
> +static size_t sps30_serial_receive_buf(struct serdev_device *serdev,
> +				       const u8 *buf, size_t size)
>  {
>  	struct iio_dev *indio_dev = dev_get_drvdata(&serdev->dev);
>  	struct sps30_serial_priv *priv;
> diff --git a/drivers/iio/imu/bno055/bno055_ser_core.c b/drivers/iio/imu/bno055/bno055_ser_core.c
> index 5677bdf4f846..694ff14a3aa2 100644
> --- a/drivers/iio/imu/bno055/bno055_ser_core.c
> +++ b/drivers/iio/imu/bno055/bno055_ser_core.c
> @@ -378,8 +378,8 @@ static void bno055_ser_handle_rx(struct bno055_ser_priv *priv, int status)
>   * Also, we assume to RX one pkt per time (i.e. the HW doesn't send anything
>   * unless we require to AND we don't queue more than one request per time).
>   */
> -static ssize_t bno055_ser_receive_buf(struct serdev_device *serdev,
> -				      const u8 *buf, size_t size)
> +static size_t bno055_ser_receive_buf(struct serdev_device *serdev,
> +				     const u8 *buf, size_t size)
>  {
>  	int status;
>  	struct bno055_ser_priv *priv = serdev_device_get_drvdata(serdev);
> diff --git a/drivers/mfd/rave-sp.c b/drivers/mfd/rave-sp.c
> index b1229bb143ee..f517e59e1c01 100644
> --- a/drivers/mfd/rave-sp.c
> +++ b/drivers/mfd/rave-sp.c
> @@ -471,8 +471,8 @@ static void rave_sp_receive_frame(struct rave_sp *sp,
>  		rave_sp_receive_reply(sp, data, length);
>  }
>  
> -static ssize_t rave_sp_receive_buf(struct serdev_device *serdev,
> -				   const u8 *buf, size_t size)
> +static size_t rave_sp_receive_buf(struct serdev_device *serdev,
> +				  const u8 *buf, size_t size)
>  {
>  	struct device *dev = &serdev->dev;
>  	struct rave_sp *sp = dev_get_drvdata(dev);
> diff --git a/drivers/net/ethernet/qualcomm/qca_uart.c b/drivers/net/ethernet/qualcomm/qca_uart.c
> index 223321897b96..20f50bde82ac 100644
> --- a/drivers/net/ethernet/qualcomm/qca_uart.c
> +++ b/drivers/net/ethernet/qualcomm/qca_uart.c
> @@ -58,7 +58,7 @@ struct qcauart {
>  	unsigned char *tx_buffer;
>  };
>  
> -static ssize_t
> +static size_t
>  qca_tty_receive(struct serdev_device *serdev, const u8 *data, size_t count)
>  {
>  	struct qcauart *qca = serdev_device_get_drvdata(serdev);
> diff --git a/drivers/nfc/pn533/uart.c b/drivers/nfc/pn533/uart.c
> index 2eb5978bd79e..cfbbe0713317 100644
> --- a/drivers/nfc/pn533/uart.c
> +++ b/drivers/nfc/pn533/uart.c
> @@ -203,8 +203,8 @@ static int pn532_uart_rx_is_frame(struct sk_buff *skb)
>  	return 0;
>  }
>  
> -static ssize_t pn532_receive_buf(struct serdev_device *serdev,
> -				 const u8 *data, size_t count)
> +static size_t pn532_receive_buf(struct serdev_device *serdev,
> +				const u8 *data, size_t count)
>  {
>  	struct pn532_uart_phy *dev = serdev_device_get_drvdata(serdev);
>  	size_t i;
> diff --git a/drivers/nfc/s3fwrn5/uart.c b/drivers/nfc/s3fwrn5/uart.c
> index 456d3947116c..9c09c10c2a46 100644
> --- a/drivers/nfc/s3fwrn5/uart.c
> +++ b/drivers/nfc/s3fwrn5/uart.c
> @@ -51,8 +51,8 @@ static const struct s3fwrn5_phy_ops uart_phy_ops = {
>  	.write = s3fwrn82_uart_write,
>  };
>  
> -static ssize_t s3fwrn82_uart_read(struct serdev_device *serdev,
> -				  const u8 *data, size_t count)
> +static size_t s3fwrn82_uart_read(struct serdev_device *serdev,
> +				 const u8 *data, size_t count)
>  {
>  	struct s3fwrn82_uart_phy *phy = serdev_device_get_drvdata(serdev);
>  	size_t i;
> diff --git a/drivers/platform/chrome/cros_ec_uart.c b/drivers/platform/chrome/cros_ec_uart.c
> index 68d80559fddc..8ea867c2a01a 100644
> --- a/drivers/platform/chrome/cros_ec_uart.c
> +++ b/drivers/platform/chrome/cros_ec_uart.c
> @@ -81,8 +81,8 @@ struct cros_ec_uart {
>  	struct response_info response;
>  };
>  
> -static ssize_t cros_ec_uart_rx_bytes(struct serdev_device *serdev,
> -				     const u8 *data, size_t count)
> +static size_t cros_ec_uart_rx_bytes(struct serdev_device *serdev,
> +				    const u8 *data, size_t count)
>  {
>  	struct ec_host_response *host_response;
>  	struct cros_ec_device *ec_dev = serdev_device_get_drvdata(serdev);
> diff --git a/drivers/platform/surface/aggregator/core.c b/drivers/platform/surface/aggregator/core.c
> index 9591a28bc38a..ba550eaa06fc 100644
> --- a/drivers/platform/surface/aggregator/core.c
> +++ b/drivers/platform/surface/aggregator/core.c
> @@ -227,8 +227,8 @@ EXPORT_SYMBOL_GPL(ssam_client_bind);
>  
>  /* -- Glue layer (serdev_device -> ssam_controller). ------------------------ */
>  
> -static ssize_t ssam_receive_buf(struct serdev_device *dev, const u8 *buf,
> -				size_t n)
> +static size_t ssam_receive_buf(struct serdev_device *dev, const u8 *buf,
> +			       size_t n)
>  {
>  	struct ssam_controller *ctrl;
>  	int ret;
> diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
> index e94e090cf0a1..3d7ae7fa5018 100644
> --- a/drivers/tty/serdev/serdev-ttyport.c
> +++ b/drivers/tty/serdev/serdev-ttyport.c
> @@ -27,19 +27,17 @@ static size_t ttyport_receive_buf(struct tty_port *port, const u8 *cp,
>  {
>  	struct serdev_controller *ctrl = port->client_data;
>  	struct serport *serport = serdev_controller_get_drvdata(ctrl);
> -	int ret;
> +	size_t ret;
>  
>  	if (!test_bit(SERPORT_ACTIVE, &serport->flags))
>  		return 0;
>  
>  	ret = serdev_controller_receive_buf(ctrl, cp, count);
>  
> -	dev_WARN_ONCE(&ctrl->dev, ret < 0 || ret > count,
> -				"receive_buf returns %d (count = %zu)\n",
> +	dev_WARN_ONCE(&ctrl->dev, ret > count,
> +				"receive_buf returns %zu (count = %zu)\n",
>  				ret, count);
> -	if (ret < 0)
> -		return 0;
> -	else if (ret > count)
> +	if (ret > count)
>  		return count;
>  
>  	return ret;
> diff --git a/include/linux/gnss.h b/include/linux/gnss.h
> index 36968a0f33e8..9857c4029e65 100644
> --- a/include/linux/gnss.h
> +++ b/include/linux/gnss.h
> @@ -60,8 +60,8 @@ void gnss_put_device(struct gnss_device *gdev);
>  int gnss_register_device(struct gnss_device *gdev);
>  void gnss_deregister_device(struct gnss_device *gdev);
>  
> -int gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> -			size_t count);
> +size_t gnss_insert_raw(struct gnss_device *gdev, const unsigned char *buf,
> +		       size_t count);
>  
>  static inline void gnss_set_drvdata(struct gnss_device *gdev, void *data)
>  {
> diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> index 3fab88ba265e..ff78efc1f60d 100644
> --- a/include/linux/serdev.h
> +++ b/include/linux/serdev.h
> @@ -27,7 +27,7 @@ struct serdev_device;
>   *			not sleep.
>   */
>  struct serdev_device_ops {
> -	ssize_t (*receive_buf)(struct serdev_device *, const u8 *, size_t);
> +	size_t (*receive_buf)(struct serdev_device *, const u8 *, size_t);
>  	void (*write_wakeup)(struct serdev_device *);
>  };
>  
> @@ -185,9 +185,9 @@ static inline void serdev_controller_write_wakeup(struct serdev_controller *ctrl
>  	serdev->ops->write_wakeup(serdev);
>  }
>  
> -static inline ssize_t serdev_controller_receive_buf(struct serdev_controller *ctrl,
> -						    const u8 *data,
> -						    size_t count)
> +static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl,
> +						   const u8 *data,
> +						   size_t count)
>  {
>  	struct serdev_device *serdev = ctrl->serdev;
>  
> diff --git a/sound/drivers/serial-generic.c b/sound/drivers/serial-generic.c
> index d6e5aafd697c..36409a56c675 100644
> --- a/sound/drivers/serial-generic.c
> +++ b/sound/drivers/serial-generic.c
> @@ -100,8 +100,8 @@ static void snd_serial_generic_write_wakeup(struct serdev_device *serdev)
>  	snd_serial_generic_tx_wakeup(drvdata);
>  }
>  
> -static ssize_t snd_serial_generic_receive_buf(struct serdev_device *serdev,
> -					      const u8 *buf, size_t count)
> +static size_t snd_serial_generic_receive_buf(struct serdev_device *serdev,
> +					     const u8 *buf, size_t count)
>  {
>  	int ret;
>  	struct snd_serial_generic *drvdata = serdev_device_get_drvdata(serdev);
> 
> base-commit: 11651f8cb2e88372d4ed523d909514dc9a613ea3



From arinc.unal at arinc9.com  Sun Dec 17 04:42:34 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Sun, 17 Dec 2023 15:42:34 +0300
Subject: [PATCH net-next 06/15] net: dsa: mt7530: do not set
 priv->p5_interface on mt7530_setup_port5()
In-Reply-To: <20231207181858.ojbgt5pwyqq3tzjk@skbuf>
References: <20231118123205.266819-1-arinc.unal@arinc9.com>
 <20231118123205.266819-7-arinc.unal@arinc9.com>
 <20231207181858.ojbgt5pwyqq3tzjk@skbuf>
Message-ID: <a01fa1eb-be77-4da1-bfa5-3e3c20bc08a7@arinc9.com>

On 7.12.2023 21:18, Vladimir Oltean wrote:
> On Sat, Nov 18, 2023 at 03:31:56PM +0300, Ar?n? ?NAL wrote:
>> Do not set priv->p5_interface on mt7530_setup_port5(). There isn't a case
>> where mt753x_phylink_mac_config() runs after mt7530_setup_port5() which
>> setting priv->p5_interface would prevent mt7530_setup_port5() from running
>> more than once.
>>
>> Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
>> ---
>>   drivers/net/dsa/mt7530.c | 2 --
>>   1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
>> index 069b3dfca6fa..fc87ec817672 100644
>> --- a/drivers/net/dsa/mt7530.c
>> +++ b/drivers/net/dsa/mt7530.c
>> @@ -978,8 +978,6 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
>>   	dev_dbg(ds->dev, "Setup P5, HWTRAP=0x%x, intf_sel=%s, phy-mode=%s\n",
>>   		val, p5_intf_modes(priv->p5_intf_sel), phy_modes(interface));
>>   
>> -	priv->p5_interface = interface;
>> -
>>   unlock_exit:
>>   	mutex_unlock(&priv->reg_mutex);
>>   }
>> -- 
>> 2.40.1
>>
> 
> Purely as a matter of theory, mt753x_phylink_mac_config() itself could
> be called more than once, at any time there is a phylink_major_config() -
> first during initial one, then upon any change of the phy_interface_t.
> With the port being fixed and internal, maybe that is unlikely.
> 
> Destroying and re-creating the phylink instance could also make the
> driver see more than 1 mt753x_phylink_mac_config() call. During periods
> of -EPROBE_DEFER, maybe this could even happen.
> 
> I think what we need to see is a description of what the priv->p5_interface
> test is really protecting against, because it certainly is uncommon in other
> drivers to have this much logic to avoid mt753x_mac_config() being
> called twice.
> 
> If there's nothing wrong with calling it twice and it's just an optimization,
> I think that's enough of a justification for removing that extra protection.
> At the same time, the optimization (and simplification) that we should
> pursue is that we should remove the overlap between phylink and the
> initial port setup made by the driver.

priv->p5_interface and priv->p6_interface were actually intended to apply
only for MT7531. It prevents the CPU ports to be configured again. CPU
ports are unnecessarily configured before phylink. I intend to address that
with the patch below. I'll submit it after the current patches here go
through. There's a lot to clean up in this driver.

https://github.com/arinc9/linux/commit/80efcb1870530ef5526d7feda625374b8f308369

If you can recall, this is where me and Russell mostly left off on my 30
patch series. I was supposed to run some debug info prints to make sure
that the MT7531 CPU ports are still configured as they were with
priv->info->cpu_port_config().

https://lore.kernel.org/netdev/ZHy2jQLesdYFMQtO at shell.armlinux.org.uk/

For this patch, I can change the patch log to state that priv->p5_interface
and priv->p6_interface are intended for use on the MT7531 switch.

Ar?n?


From jgg at nvidia.com  Sun Dec 17 05:03:55 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Sun, 17 Dec 2023 09:03:55 -0400
Subject: [PATCH 04/19] iommu/arm-smmu-v3: Make STE programming
 independent of the callers
In-Reply-To: <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com>
References: <0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com>
 <CAKHBV24UGZuG6+J4cybadJCTyf9hN+e_VgAC0NVOPotmEur7SQ@mail.gmail.com>
 <20231012121616.GF3952@nvidia.com>
 <CAKHBV27G1PLZ5gkYkOOCZdD9waZOZypkWqk4_HSR4XXGFT-+LA@mail.gmail.com>
 <20231018130455.GU3952@nvidia.com>
 <CAKHBV270uJjdj4zeK-NNt+j3TiqoGDdLUQ5uRrLw9PN0ysCDbw@mail.gmail.com>
 <20231020113918.GD3952@nvidia.com>
 <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
 <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com>
Message-ID: <ZX7xu8jN/rBZ4A/d@nvidia.com>

On Sat, Dec 16, 2023 at 04:26:48AM +0800, Michael Shavit wrote:

> Ok, I took a proper stab at trying to unroll the loop on the github
> version of this patch (v3+)
> As you suspected, it's not easy to re-use the unrolled version for
> both STE and CD writing as we'd have to pass in callbacks for syncing
> the STE/CD and recomputing arm_smmu_{get_ste/cd}_used. 

Yes, that is why I structured it as an iterator
> I personally find this quite a bit more readable as a sequential
> series of steps instead of a loop. It also only requires 3 STE/CD
> syncs in the worst case compared to 4 in the loop version since we

The existing version is max 3 as well, it works the same by
checking the number of critical qwords after computing the first step
in the hitless flow.

However, what you have below has the same problem as the first sketch,
it always does 3 syncs. The existing version fully minimizes the
syncs. It is why it is so complex to unroll it as you have to check
before every sync if the sync is needed at all.

This could probably be organized like this so one shared function
computes the "plan" and then a cd/ste copy executes the plan. It
avoids the loop but all the code is still basically the same, there is
just more of it.

I'm fine with any of these ways

Jason

>  static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
>                                struct arm_smmu_ste *ste,
>                                const struct arm_smmu_ste *target)
>  {
> +       struct arm_smmu_ste staging_ste;
>         struct arm_smmu_ste target_used;
> +       int writes_required = 0;
> +       u8 staging_used_diff = 0;
> +       int i = 0;
> 
> +       /*
> +        * Compute a staging ste that has all the bits currently unused by HW
> +        * set to their target values, such that comitting it to the ste table
> +        * woudn't disrupt the hardware.
> +        */
> +       memcpy(&staging_ste, ste, sizeof(staging_ste));
> +       arm_smmu_ste_set_unused_bits(&staging_ste, target);
> +
> +       /*
> +        * Determine if it's possible to reach the target configuration from the
> +        * staged configured in a single qword write (ignoring bits that are
> +        * unused under the target configuration).
> +        */
>         arm_smmu_get_ste_used(target, &target_used);
> -               WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);
> +       /*
> +        * But first sanity check that masks in arm_smmu_get_ste_used() are up
> +        * to date.
> +        */
> +       for (i = 0; i != ARRAY_SIZE(target->data); i++) {
> +               if (WARN_ON_ONCE(target->data[i] & ~target_used.data[i]))
> +                       target_used.data[i] |= target->data[i];
> +       }
> 
> +       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++) {
> +               /*
> +                * Each bit of staging_used_diff indicates the index of a qword
> +                * within the staged ste that is incorrect compared to the
> +                * target, considering only the used bits in the target
> +                */
> +               if ((staging_ste.data[i] &
> +                   target_used.data[i]) != (target->data[i]))
> +                       staging_used_diff |= 1 << i;
> +       }
> +       if (hweight8(staging_used_diff) > 1) {
> +               /*
> +                * More than 1 qword is mismatched and a hitless transition from
> +                * the current ste to the target ste is not possible. Clear the
> +                * V bit and recompute the staging STE.
> +                * Because the V bit is cleared, the staging STE will be equal
> +                * to the target STE except for the first qword.
> +                */
> +               staging_ste.data[0] &= ~cpu_to_le64(STRTAB_STE_0_V);
> +               arm_smmu_ste_set_unused_bits(&staging_ste, target);
> +               staging_used_diff = 1;
> +       }
> +
> +       /*
> +        * Commit the staging STE.
> +        */
> +       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++)
> +               WRITE_ONCE(ste->data[i], staging_ste.data[i]);
> +       arm_smmu_sync_ste_for_sid(smmu, sid);
> +
> +       /*
> +        * It's now possible to switch to the target configuration with a write
> +        * to a single qword. Make that switch now.
> +        */
> +       i = ffs(staging_used_diff) - 1;
> +       WRITE_ONCE(ste->data[i], target->data[i]);
> +       arm_smmu_sync_ste_for_sid(smmu, sid);

The non hitless flow doesn't look right to me, it should set v=0 then
load all qwords but 0 then load 0, in exactly that sequence. If the
goal is clarity then the two programming flows should be explicitly
spelled out.

Jason


From jgg at ziepe.ca  Sun Dec 17 05:06:51 2023
From: jgg at ziepe.ca (Jason Gunthorpe)
Date: Sun, 17 Dec 2023 09:06:51 -0400
Subject: [PATCH v2 6/7] iommu/dma: Centralise iommu_setup_dma_ops()
In-Reply-To: <2d87c1dc-cc95-4d92-968c-9d6e6e6439ff@arm.com>
References: <cover.1702486837.git.robin.murphy@arm.com>
 <5d89190b35720bf5b66621f46b6d3c85323d8eab.1702486837.git.robin.murphy@arm.com>
 <20231214165126.GA3726750@myrica>
 <2d87c1dc-cc95-4d92-968c-9d6e6e6439ff@arm.com>
Message-ID: <ZX7ya38NBluYyrOK@ziepe.ca>

On Thu, Dec 14, 2023 at 06:22:49PM +0000, Robin Murphy wrote:

> Taking yet another look, there's not actually one single place we can do
> this right now which will work in a manageable way for all cases.

The dma ops should be set after changing the translation and there is
only one place that attachs the domain? What prevents putting it
there?

> @@ -3217,18 +3220,9 @@ static ssize_t iommu_group_store_type(struct iommu_group *group,
>  	if (ret)
>  		goto out_unlock;
> -	/*
> -	 * Release the mutex here because ops->probe_finalize() call-back of
> -	 * some vendor IOMMU drivers calls arm_iommu_attach_device() which
> -	 * in-turn might call back into IOMMU core code, where it tries to take
> -	 * group->mutex, resulting in a deadlock.
> -	 */
> -	mutex_unlock(&group->mutex);
> -
>  	/* Make sure dma_ops is appropriatley set */
>  	for_each_group_device(group, gdev)
> -		iommu_group_do_probe_finalize(gdev->dev);
> -	return count;

If we are turning this into something that only works for the ARM DMA
then the remaining caller should be guarded by an IS_ENABLED

Jason


From gregkh at linuxfoundation.org  Sun Dec 17 05:27:32 2023
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Sun, 17 Dec 2023 14:27:32 +0100
Subject: patch "usb: gadget: udc: atmel: Replace snprintf() with the safer" added to usb-next
Message-ID: <2023121732-bacteria-ladybug-c5c9@gregkh>


This is a note to let you know that I've just added the patch titled

    usb: gadget: udc: atmel: Replace snprintf() with the safer

to my usb git tree which can be found at
    git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.

The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)

The patch will also be merged in the next major kernel release
during the merge window.

If you have any questions about this process, please let me know.


>From d32dcb0659bcb3b68878a985280024ec92d0db5b Mon Sep 17 00:00:00 2001
From: Lee Jones <lee at kernel.org>
Date: Wed, 13 Dec 2023 16:42:34 +0000
Subject: usb: gadget: udc: atmel: Replace snprintf() with the safer
 scnprintf() variant

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Cristian Birsan <cristian.birsan at microchip.com>
Cc: Nicolas Ferre <nicolas.ferre at microchip.com>
Cc: Alexandre Belloni <alexandre.belloni at bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea at tuxon.dev>
Cc:  <linux-arm-kernel at lists.infradead.org>
Signed-off-by: Lee Jones <lee at kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-6-lee at kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 02b1bef5e22e..b76885d78e8a 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -94,7 +94,7 @@ static ssize_t queue_dbg_read(struct file *file, char __user *buf,
 
 	inode_lock(file_inode(file));
 	list_for_each_entry_safe(req, tmp_req, queue, queue) {
-		len = snprintf(tmpbuf, sizeof(tmpbuf),
+		len = scnprintf(tmpbuf, sizeof(tmpbuf),
 				"%8p %08x %c%c%c %5d %c%c%c\n",
 				req->req.buf, req->req.length,
 				req->req.no_interrupt ? 'i' : 'I',
@@ -104,7 +104,6 @@ static ssize_t queue_dbg_read(struct file *file, char __user *buf,
 				req->submitted ? 'F' : 'f',
 				req->using_dma ? 'D' : 'd',
 				req->last_transaction ? 'L' : 'l');
-		len = min(len, sizeof(tmpbuf));
 		if (len > nbytes)
 			break;
 
-- 
2.43.0




From gregkh at linuxfoundation.org  Sun Dec 17 05:27:34 2023
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Sun, 17 Dec 2023 14:27:34 +0100
Subject: patch "usb: host: max3421-hcd: Replace snprintf() with the safer scnprintf()" added to usb-next
Message-ID: <2023121733-gerbil-sincerity-820c@gregkh>


This is a note to let you know that I've just added the patch titled

    usb: host: max3421-hcd: Replace snprintf() with the safer scnprintf()

to my usb git tree which can be found at
    git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.

The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)

The patch will also be merged in the next major kernel release
during the merge window.

If you have any questions about this process, please let me know.


>From a6eef67cdb84e06112fc29176d6c6061d3ea8d79 Mon Sep 17 00:00:00 2001
From: Lee Jones <lee at kernel.org>
Date: Wed, 13 Dec 2023 16:42:36 +0000
Subject: usb: host: max3421-hcd: Replace snprintf() with the safer scnprintf()
 variant

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Cristian Birsan <cristian.birsan at microchip.com>
Cc: Nicolas Ferre <nicolas.ferre at microchip.com>
Cc: Alexandre Belloni <alexandre.belloni at bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea at tuxon.dev>
Cc:  <linux-arm-kernel at lists.infradead.org>
Signed-off-by: Lee Jones <lee at kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-8-lee at kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/usb/host/max3421-hcd.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index d152d72de126..9fe4f48b1898 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1158,12 +1158,12 @@ dump_eps(struct usb_hcd *hcd)
 		end = dp + sizeof(ubuf);
 		*dp = '\0';
 		list_for_each_entry(urb, &ep->urb_list, urb_list) {
-			ret = snprintf(dp, end - dp, " %p(%d.%s %d/%d)", urb,
-				       usb_pipetype(urb->pipe),
-				       usb_urb_dir_in(urb) ? "IN" : "OUT",
-				       urb->actual_length,
-				       urb->transfer_buffer_length);
-			if (ret < 0 || ret >= end - dp)
+			ret = scnprintf(dp, end - dp, " %p(%d.%s %d/%d)", urb,
+					usb_pipetype(urb->pipe),
+					usb_urb_dir_in(urb) ? "IN" : "OUT",
+					urb->actual_length,
+					urb->transfer_buffer_length);
+			if (ret == end - dp - 1)
 				break;	/* error or buffer full */
 			dp += ret;
 		}
@@ -1255,9 +1255,9 @@ max3421_handle_irqs(struct usb_hcd *hcd)
 			end = sbuf + sizeof(sbuf);
 			*dp = '\0';
 			for (i = 0; i < 16; ++i) {
-				int ret = snprintf(dp, end - dp, " %lu",
-						   max3421_hcd->err_stat[i]);
-				if (ret < 0 || ret >= end - dp)
+				int ret = scnprintf(dp, end - dp, " %lu",
+						    max3421_hcd->err_stat[i]);
+				if (ret == end - dp - 1)
 					break;	/* error or buffer full */
 				dp += ret;
 			}
-- 
2.43.0




From will at kernel.org  Sun Dec 17 05:41:05 2023
From: will at kernel.org (Will Deacon)
Date: Sun, 17 Dec 2023 13:41:05 +0000
Subject: [PATCH v2 0/1] arm: perf: Fix ARCH=arm build with GCC
In-Reply-To: <20231215175648.3397170-1-james.clark@arm.com>
References: <20231215175648.3397170-1-james.clark@arm.com>
Message-ID: <170281440108.359132.7914631025593499836.b4-ty@kernel.org>

On Fri, 15 Dec 2023 17:56:47 +0000, James Clark wrote:
> Changes since V1:
> 
>   * Instead of wrapping everything in #if, just use GENMASK_ULL instead
>     which fixes both issues in one commit.
> 
> A fix for the broken build with GCC currently in linux-next
> (next-20231214)
> 
> [...]

Applied to will (for-next/perf), thanks!

[1/1] arm: perf: Fix ARCH=arm build with GCC
      https://git.kernel.org/will/c/bb339db4d363

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Sun Dec 17 05:41:06 2023
From: will at kernel.org (Will Deacon)
Date: Sun, 17 Dec 2023 13:41:06 +0000
Subject: [PATCH] arm64: properly install vmlinuz.efi
In-Reply-To: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>
References: <6edb1402769c2c14c4fbef8f7eaedb3167558789.1702570674.git.josef@toxicpanda.com>
Message-ID: <170281463264.359691.7224946919884459343.b4-ty@kernel.org>

On Thu, 14 Dec 2023 11:18:50 -0500, Josef Bacik wrote:
> If you select CONFIG_EFI_ZBOOT, we will generate vmlinuz.efi, and then
> when we go to install the kernel we'll install the vmlinux instead
> because install.sh only recognizes Image.gz as wanting the compressed
> install image.  With CONFIG_EFI_ZBOOT we don't get the proper kernel
> installed, which means it doesn't boot, which makes for a very confused
> and subsequently angry kernel developer.
> 
> [...]

Applied to arm64 (for-next/kbuild), thanks!

[1/1] arm64: properly install vmlinuz.efi
      https://git.kernel.org/arm64/c/7b21ed7d119d

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Sun Dec 17 05:41:07 2023
From: will at kernel.org (Will Deacon)
Date: Sun, 17 Dec 2023 13:41:07 +0000
Subject: [PATCH v3 00/17] KVM: arm64: Fixes to fine grain traps and pKVM traps
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <170281508473.360576.14128850250144458309.b4-ty@kernel.org>

On Thu, 14 Dec 2023 10:01:40 +0000, Fuad Tabba wrote:
> Changes from v2:
> - Rebased on arm64/for-next/sysregs, which includes new system
>   register definitions (Mark, Joey)
> - Explicitly trap unsupported HFGxTR_EL2 features rather than
>   relying on its nMASK (Joey)
> - Add new system registers to the auto-generated sysreg rather
>   than hardcoding them (Mark)
> - Drop patch that was meant as RFC
> - Added missing system registers, fields, and  system
>   instructions
> - Split patches that make system register changes
> - Fixes to patches defining allowed features for protected VMs
> - Other minor fixes and tidying up
> 
> [...]

Applied the first four sysreg patches to arm64 (for-next/sysregs), thanks!

[01/17] arm64/sysreg: Add missing Pauth_LR field definitions to ID_AA64ISAR1_EL1
        https://git.kernel.org/arm64/c/3b077ad8cb25
[02/17] arm64/sysreg: Add missing ExtTrcBuff field definition to ID_AA64DFR0_EL1
        https://git.kernel.org/arm64/c/4f101cdcb578
[03/17] arm64/sysreg: Add missing system register definitions for FGT
        https://git.kernel.org/arm64/c/885c6d8e2885
[04/17] arm64/sysreg: Add missing system instruction definitions for FGT
        https://git.kernel.org/arm64/c/4ebee8cebdf6

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Sun Dec 17 05:41:08 2023
From: will at kernel.org (Will Deacon)
Date: Sun, 17 Dec 2023 13:41:08 +0000
Subject: [PATCH] arm64: memory: remove duplicated include
In-Reply-To: <202312151439+0800-wangjinchao@xfusion.com>
References: <202312151439+0800-wangjinchao@xfusion.com>
Message-ID: <170281487405.360120.10807980277347263499.b4-ty@kernel.org>

On Fri, 15 Dec 2023 14:40:08 +0800, Wang Jinchao wrote:
> remove duplicated include
> 
> 

Applied to arm64 (for-next/misc), thanks!

[1/1] arm64: memory: remove duplicated include
      https://git.kernel.org/arm64/c/5cc5ed7a668d

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From bigunclemax at gmail.com  Sun Dec 17 05:36:36 2023
From: bigunclemax at gmail.com (Maksim Kiselev)
Date: Sun, 17 Dec 2023 16:36:36 +0300
Subject: [PATCH v1] thermal: sun8i: extend H6 calibration function to support 4 sensors
Message-ID: <20231217133637.54773-1-bigunclemax@gmail.com>

The H616 SoC resembles the H6 thermal sensor controller, with a few
changes like four sensors.

Extend sun50i_h6_ths_calibrate() function to support calibration of
these sensors.

Signed-off-by: Martin Botka <martin.botka at somainline.org>
Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Signed-off-by: Maksim Kiselev <bigunclemax at gmail.com>
---
 drivers/thermal/sun8i_thermal.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
index f989b55a8aa8..9af95b4785be 100644
--- a/drivers/thermal/sun8i_thermal.c
+++ b/drivers/thermal/sun8i_thermal.c
@@ -221,16 +221,21 @@ static int sun50i_h6_ths_calibrate(struct ths_device *tmdev,
 	struct device *dev = tmdev->dev;
 	int i, ft_temp;
 
-	if (!caldata[0] || callen < 2 + 2 * tmdev->chip->sensor_num)
+	if (!caldata[0])
 		return -EINVAL;
 
 	/*
 	 * efuse layout:
 	 *
-	 *	0   11  16	 32
-	 *	+-------+-------+-------+
-	 *	|temp|  |sensor0|sensor1|
-	 *	+-------+-------+-------+
+	 * 0      11  16     27   32     43   48    57
+	 * +----------+-----------+-----------+-----------+
+	 * |  temp |  |sensor0|   |sensor1|   |sensor2|   |
+	 * +----------+-----------+-----------+-----------+
+	 *                      ^           ^           ^
+	 *                      |           |           |
+	 *                      |           |           sensor3[11:8]
+	 *                      |           sensor3[7:4]
+	 *                      sensor3[3:0]
 	 *
 	 * The calibration data on the H6 is the ambient temperature and
 	 * sensor values that are filled during the factory test stage.
@@ -243,9 +248,16 @@ static int sun50i_h6_ths_calibrate(struct ths_device *tmdev,
 	ft_temp = (caldata[0] & FT_TEMP_MASK) * 100;
 
 	for (i = 0; i < tmdev->chip->sensor_num; i++) {
-		int sensor_reg = caldata[i + 1] & TEMP_CALIB_MASK;
-		int cdata, offset;
-		int sensor_temp = tmdev->chip->calc_temp(tmdev, i, sensor_reg);
+		int sensor_reg, sensor_temp, cdata, offset;
+
+		if (i == 3)
+			sensor_reg = (caldata[1] >> 12)
+				     | ((caldata[2] >> 12) << 4)
+				     | ((caldata[3] >> 12) << 8);
+		else
+			sensor_reg = caldata[i + 1] & TEMP_CALIB_MASK;
+
+		sensor_temp = tmdev->chip->calc_temp(tmdev, i, sensor_reg);
 
 		/*
 		 * Calibration data is CALIBRATE_DEFAULT - (calculated
-- 
2.40.1



From bigunclemax at gmail.com  Sun Dec 17 06:16:23 2023
From: bigunclemax at gmail.com (Maxim Kiselev)
Date: Sun, 17 Dec 2023 18:16:23 +0400
Subject: [PATCH v3 5/6] thermal: sun8i: add support for H616 THS controller
In-Reply-To: <20231214095914.4a98ba8c@donnerap.manchester.arm.com>
References: <20231128005849.19044-6-andre.przywara@arm.com>
 <a14fb458-caf0-4a4a-b76b-c2503b0840d2@gmail.com> <20231211000528.57cb646c@minigeek.lan>
 <CALHCpMjz4YiE_=6Cxq7RqF_3qPaw8UCA=6eLy9ZZuofRhr7mcA@mail.gmail.com> <20231214095914.4a98ba8c@donnerap.manchester.arm.com>
Message-ID: <CALHCpMj6+J7xDO0EGut=hmJxXONXrgQoHTQ3vVzdk_97g6BzkA@mail.gmail.com>

Hi Andre,

??, 14 ???. 2023??. ? 13:59, Andre Przywara <andre.przywara at arm.com>:
>
> On Tue, 12 Dec 2023 21:09:45 +0300
> Maxim Kiselev <bigunclemax at gmail.com> wrote:
>
> Hi Maksim,
>
> sorry for the delay.

Now it's my turn to apologize for the delay :)

>
> > ??, 11 ???. 2023??. ? 02:48, Andre Przywara <andre.przywara at arm.com>:
> > >
> > > On Sat, 9 Dec 2023 13:44:34 +0300
> > > Maksim Kiselev <bigunclemax at gmail.com> wrote:
> > >
> > > Hi Maksim,
> > >
> > > > Hi Martin, Andre.
> > > >
> > > > May I inquire? Why do we need a separate sun50i_h616_ths_calibrate()
> > > > function? Why can't we just extend an existing sun50i_h6_ths_calibrate()?
> > > >
> > > > At my glance the calculations in both functions are the same. We just
> > > > need to handle a special case for the 4th sensor.
> > >
> > > You seem to be right, they are indeed the same, just written slightly
> > > differently. Do you already have any patches that unify that?
> >
> > No, I don't have any patches for that yet. But I can do it if you told
> > me where to
> > send the patch. Should I put it here as a reply?
>
> Can you make one patch on top of mainline, that prepares the existing
> sun50i_h6_ths_calibrate() function to deal with four sensors? I would then
> include this patch of yours in the next submission, and put Martin's H616
> patch (now probably just the struct ths_thermal_chip) on top then.
>
> Please send this patch just to the list (CC:ing people like Martin and
> me), starting a new thread.

You can find my patch here:
https://lore.kernel.org/all/20231217133637.54773-1-bigunclemax at gmail.com/

Best regards,
Maksim

> Many thanks,
> Andre
>
> > > I don't know if Martin or I find time to do it this week, but we could
> > > also optimise this later.
> > >
> > > Cheers,
> > > Andre
> >
> > Best regards,
> > Maksim
>


From u.kleine-koenig at pengutronix.de  Sun Dec 17 06:29:27 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 17 Dec 2023 15:29:27 +0100
Subject: [PATCH 01/15] memory: brcmstb_dpfe: Convert to platform remove callback returning void
In-Reply-To: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
Message-ID: <94780e5a414b20b6effa1e87208c14620c854e88.1702822744.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/memory/brcmstb_dpfe.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index a7ab3d377206..5028467b2dc9 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -909,13 +909,11 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int brcmstb_dpfe_remove(struct platform_device *pdev)
+static void brcmstb_dpfe_remove(struct platform_device *pdev)
 {
 	struct brcmstb_dpfe_priv *priv = dev_get_drvdata(&pdev->dev);
 
 	sysfs_remove_groups(&pdev->dev.kobj, priv->dpfe_api->sysfs_attrs);
-
-	return 0;
 }
 
 static const struct of_device_id brcmstb_dpfe_of_match[] = {
@@ -936,7 +934,7 @@ static struct platform_driver brcmstb_dpfe_driver = {
 		.of_match_table = brcmstb_dpfe_of_match,
 	},
 	.probe = brcmstb_dpfe_probe,
-	.remove	= brcmstb_dpfe_remove,
+	.remove_new = brcmstb_dpfe_remove,
 	.resume = brcmstb_dpfe_resume,
 };
 
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Sun Dec 17 06:29:26 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 17 Dec 2023 15:29:26 +0100
Subject: [PATCH 00/15] memory: Convert to platform remove callback returning void
Message-ID: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>

Hello,

this series converts the platform drivers below drivers/memory to make
use of .remove_new. See commit 5c5a7680e67b ("platform: Provide a remove
callback that returns no value") for an extended explanation and the
eventual goal. The TL;DR; is to make it harder for driver authors to
leak resources without noticing.

This is merge window material. All patches are pairwise independent of
each other so they can be applied individually. Still it would be great
to let them go in all together.

Best regards
Uwe

Uwe Kleine-K?nig (15):
  memory: brcmstb_dpfe: Convert to platform remove callback returning void
  memory: brcmstb_memc: Convert to platform remove callback returning void
  memory: emif: Convert to platform remove callback returning void
  memory: fsl-corenet-cf: Convert to platform remove callback returning void
  memory: fsl_ifc: Convert to platform remove callback returning void
  memory: jz4780-nemc: Convert to platform remove callback returning void
  memory: mtk-smi: Convert to platform remove callback returning void
  memory: omap-gpmc: Convert to platform remove callback returning void
  memory: renesas-rpc-if: Convert to platform remove callback returning void
  memory: exynos5422-dmc: Convert to platform remove callback returning void
  memory: stm32-fmc2-ebi: Convert to platform remove callback returning void
  memory: tegra186-emc: Convert to platform remove callback returning void
  memory: tegra210-emc: Convert to platform remove callback returning void
  memory: ti-aemif: Convert to platform remove callback returning void
  memory: ti-emif-pm: Convert to platform remove callback returning void

 drivers/memory/brcmstb_dpfe.c            |  6 ++----
 drivers/memory/brcmstb_memc.c            |  6 ++----
 drivers/memory/emif.c                    |  6 ++----
 drivers/memory/fsl-corenet-cf.c          |  6 ++----
 drivers/memory/fsl_ifc.c                 |  6 ++----
 drivers/memory/jz4780-nemc.c             |  5 ++---
 drivers/memory/mtk-smi.c                 | 10 ++++------
 drivers/memory/omap-gpmc.c               |  6 ++----
 drivers/memory/renesas-rpc-if.c          |  6 ++----
 drivers/memory/samsung/exynos5422-dmc.c  |  6 ++----
 drivers/memory/stm32-fmc2-ebi.c          |  6 ++----
 drivers/memory/tegra/tegra186-emc.c      |  6 ++----
 drivers/memory/tegra/tegra210-emc-core.c |  6 ++----
 drivers/memory/ti-aemif.c                |  5 ++---
 drivers/memory/ti-emif-pm.c              |  6 ++----
 15 files changed, 32 insertions(+), 60 deletions(-)

base-commit: 17cb8a20bde66a520a2ca7aad1063e1ce7382240
-- 
2.42.0


From u.kleine-koenig at pengutronix.de  Sun Dec 17 06:29:28 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 17 Dec 2023 15:29:28 +0100
Subject: [PATCH 02/15] memory: brcmstb_memc: Convert to platform remove callback returning void
In-Reply-To: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e4f3c86270161ce231cd0e4f3be9c632578e17a2.1702822744.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/memory/brcmstb_memc.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/brcmstb_memc.c b/drivers/memory/brcmstb_memc.c
index a6ea51996522..ea9213f7152e 100644
--- a/drivers/memory/brcmstb_memc.c
+++ b/drivers/memory/brcmstb_memc.c
@@ -152,13 +152,11 @@ static int brcmstb_memc_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int brcmstb_memc_remove(struct platform_device *pdev)
+static void brcmstb_memc_remove(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 
 	sysfs_remove_group(&dev->kobj, &dev_attr_group);
-
-	return 0;
 }
 
 enum brcmstb_memc_hwtype {
@@ -284,7 +282,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(brcmstb_memc_pm_ops, brcmstb_memc_suspend,
 
 static struct platform_driver brcmstb_memc_driver = {
 	.probe = brcmstb_memc_probe,
-	.remove = brcmstb_memc_remove,
+	.remove_new = brcmstb_memc_remove,
 	.driver = {
 		.name		= "brcmstb_memc",
 		.of_match_table	= brcmstb_memc_of_match,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Sun Dec 17 06:29:37 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 17 Dec 2023 15:29:37 +0100
Subject: [PATCH 11/15] memory: stm32-fmc2-ebi: Convert to platform remove callback returning void
In-Reply-To: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
Message-ID: <fa74d4ae3cbf337dcae66db8479125fec8078153.1702822744.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/memory/stm32-fmc2-ebi.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/stm32-fmc2-ebi.c b/drivers/memory/stm32-fmc2-ebi.c
index 9015e8277dc8..47d0ea5f1616 100644
--- a/drivers/memory/stm32-fmc2-ebi.c
+++ b/drivers/memory/stm32-fmc2-ebi.c
@@ -1146,7 +1146,7 @@ static int stm32_fmc2_ebi_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int stm32_fmc2_ebi_remove(struct platform_device *pdev)
+static void stm32_fmc2_ebi_remove(struct platform_device *pdev)
 {
 	struct stm32_fmc2_ebi *ebi = platform_get_drvdata(pdev);
 
@@ -1154,8 +1154,6 @@ static int stm32_fmc2_ebi_remove(struct platform_device *pdev)
 	stm32_fmc2_ebi_disable_banks(ebi);
 	stm32_fmc2_ebi_disable(ebi);
 	clk_disable_unprepare(ebi->clk);
-
-	return 0;
 }
 
 static int __maybe_unused stm32_fmc2_ebi_suspend(struct device *dev)
@@ -1197,7 +1195,7 @@ MODULE_DEVICE_TABLE(of, stm32_fmc2_ebi_match);
 
 static struct platform_driver stm32_fmc2_ebi_driver = {
 	.probe	= stm32_fmc2_ebi_probe,
-	.remove	= stm32_fmc2_ebi_remove,
+	.remove_new = stm32_fmc2_ebi_remove,
 	.driver	= {
 		.name = "stm32_fmc2_ebi",
 		.of_match_table = stm32_fmc2_ebi_match,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Sun Dec 17 06:29:33 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 17 Dec 2023 15:29:33 +0100
Subject: [PATCH 07/15] memory: mtk-smi: Convert to platform remove callback returning void
In-Reply-To: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
Message-ID: <5c35a33cfdc359842e034ddd2e9358f10e91fa1f.1702822744.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/memory/mtk-smi.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 6523cb510518..572c7fbdcfd3 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -566,14 +566,13 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int mtk_smi_larb_remove(struct platform_device *pdev)
+static void mtk_smi_larb_remove(struct platform_device *pdev)
 {
 	struct mtk_smi_larb *larb = platform_get_drvdata(pdev);
 
 	device_link_remove(&pdev->dev, larb->smi_common_dev);
 	pm_runtime_disable(&pdev->dev);
 	component_del(&pdev->dev, &mtk_smi_larb_component_ops);
-	return 0;
 }
 
 static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
@@ -616,7 +615,7 @@ static const struct dev_pm_ops smi_larb_pm_ops = {
 
 static struct platform_driver mtk_smi_larb_driver = {
 	.probe	= mtk_smi_larb_probe,
-	.remove	= mtk_smi_larb_remove,
+	.remove_new = mtk_smi_larb_remove,
 	.driver	= {
 		.name = "mtk-smi-larb",
 		.of_match_table = mtk_smi_larb_of_ids,
@@ -795,14 +794,13 @@ static int mtk_smi_common_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int mtk_smi_common_remove(struct platform_device *pdev)
+static void mtk_smi_common_remove(struct platform_device *pdev)
 {
 	struct mtk_smi *common = dev_get_drvdata(&pdev->dev);
 
 	if (common->plat->type == MTK_SMI_GEN2_SUB_COMM)
 		device_link_remove(&pdev->dev, common->smi_common_dev);
 	pm_runtime_disable(&pdev->dev);
-	return 0;
 }
 
 static int __maybe_unused mtk_smi_common_resume(struct device *dev)
@@ -842,7 +840,7 @@ static const struct dev_pm_ops smi_common_pm_ops = {
 
 static struct platform_driver mtk_smi_common_driver = {
 	.probe	= mtk_smi_common_probe,
-	.remove = mtk_smi_common_remove,
+	.remove_new = mtk_smi_common_remove,
 	.driver	= {
 		.name = "mtk-smi-common",
 		.of_match_table = mtk_smi_common_of_ids,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Sun Dec 17 06:29:36 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 17 Dec 2023 15:29:36 +0100
Subject: [PATCH 10/15] memory: exynos5422-dmc: Convert to platform remove callback returning void
In-Reply-To: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
Message-ID: <167dbda286584eafec07da8c11673da07ba72362.1702822744.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/memory/samsung/exynos5422-dmc.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/samsung/exynos5422-dmc.c b/drivers/memory/samsung/exynos5422-dmc.c
index 6d019dbd721c..da7ecd921c72 100644
--- a/drivers/memory/samsung/exynos5422-dmc.c
+++ b/drivers/memory/samsung/exynos5422-dmc.c
@@ -1558,7 +1558,7 @@ static int exynos5_dmc_probe(struct platform_device *pdev)
  * clean the device's resources. It just calls explicitly disable function for
  * the performance counters.
  */
-static int exynos5_dmc_remove(struct platform_device *pdev)
+static void exynos5_dmc_remove(struct platform_device *pdev)
 {
 	struct exynos5_dmc *dmc = dev_get_drvdata(&pdev->dev);
 
@@ -1569,8 +1569,6 @@ static int exynos5_dmc_remove(struct platform_device *pdev)
 
 	clk_disable_unprepare(dmc->mout_bpll);
 	clk_disable_unprepare(dmc->fout_bpll);
-
-	return 0;
 }
 
 static const struct of_device_id exynos5_dmc_of_match[] = {
@@ -1581,7 +1579,7 @@ MODULE_DEVICE_TABLE(of, exynos5_dmc_of_match);
 
 static struct platform_driver exynos5_dmc_platdrv = {
 	.probe	= exynos5_dmc_probe,
-	.remove = exynos5_dmc_remove,
+	.remove_new = exynos5_dmc_remove,
 	.driver = {
 		.name	= "exynos5-dmc",
 		.of_match_table = exynos5_dmc_of_match,
-- 
2.42.0



From paul at crapouillou.net  Sun Dec 17 06:43:24 2023
From: paul at crapouillou.net (Paul Cercueil)
Date: Sun, 17 Dec 2023 15:43:24 +0100
Subject: [PATCH v5 03/13] pinctrl: ingenic: Use C99 initializers in
 PINCTRL_PIN_GROUP()
In-Reply-To: <ZXmv81bJRMqB1GLY@smile.fi.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
	 <20231211190321.307330-4-andriy.shevchenko@linux.intel.com>
	 <fb29c3bca8d245e3f7496539b7293aa4fc4bccd0.camel@crapouillou.net>
	 <ZXmv81bJRMqB1GLY@smile.fi.intel.com>
Message-ID: <9cbaf60cd6cf1a581e7587088f71ca7cf6b6ff37.camel@crapouillou.net>

Hi Andy,

Le mercredi 13 d?cembre 2023 ? 15:21 +0200, Andy Shevchenko a ?crit?:
> On Wed, Dec 13, 2023 at 10:55:46AM +0100, Paul Cercueil wrote:
> > Le lundi 11 d?cembre 2023 ? 20:57 +0200, Andy Shevchenko a ?crit?:
> 
> ...
> 
> > > -#define INGENIC_PIN_GROUP(name, id, func)		\
> > > -	INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
> > > +#define INGENIC_PIN_GROUP(_name_, id,
> > > func)						\
> > > +	{							
> > > 			\
> > > +		.name =
> > > _name_,								\
> > > +		.pins =
> > > id##_pins,							\
> > > +		.num_pins =
> > > ARRAY_SIZE(id##_pins),					\
> > > +		.data = (void
> > > *)func,							\
> > > +	}
> > 
> > This INGENIC_PIN_GROUP() macro doesn't need to be modified, does
> > it?
> 
> We can go either way. I prefer to go this way as it reduces level of
> indirections in the macros. It makes code easier to read and
> understand.
> But if you insist, I can drop that change in next version.
> 

I like the patches to be minimal. But I understand your point of view
as well.

If you have to issue a v6, maybe state the reason why you also modify
INGENIC_PIN_GROUP() then. But I don't care enough to request a v6 just
for that.

So:
Acked-by: Paul Cercueil <paul at crapouillou.net>

Cheers,
-Paul


From bot at kernelci.org  Sun Dec 17 07:05:54 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Sun, 17 Dec 2023 07:05:54 -0800 (PST)
Subject: arm64/for-kernelci build: 1 build: 0 failed,
 1 passed (v6.7-rc5-90-g0bcda4cd6851f)
Message-ID: <657f0e52.170a0220.5ce35.4e97@mx.google.com>

arm64/for-kernelci build: 1 build: 0 failed, 1 passed (v6.7-rc5-90-g0bcda4cd6851f)

Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v6.7-rc5-90-g0bcda4cd6851f/

Tree: arm64
Branch: for-kernelci
Git Describe: v6.7-rc5-90-g0bcda4cd6851f
Git Commit: 0bcda4cd6851fe0868be5a0207a12718604d5e2b
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Built: 1 unique architecture

================================================================================

Detailed per-defconfig build reports:

--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) ? PASS, 0 errors, 0 warnings, 0 section mismatches

---
For more info write to <info at kernelci.org>


From dsimic at manjaro.org  Sun Dec 17 07:18:22 2023
From: dsimic at manjaro.org (Dragan Simic)
Date: Sun, 17 Dec 2023 16:18:22 +0100
Subject: [PATCH v2] arm64: dts: rockchip: Increase maximum frequency of
 SPI flash for ROCK Pi 4A/B/C
In-Reply-To: <20231217113208.64056-1-stefan.nagy@ixypsilon.net>
References: <20231217113208.64056-1-stefan.nagy@ixypsilon.net>
Message-ID: <edda17071180a91658ced910bdb54be7@manjaro.org>

On 2023-12-17 12:32, Stefan Nagy wrote:
> The ROCK Pi 4A/B/C boards come with a 32 Mbit SPI NOR flash chip (XTX
> Technology Limited XT25F32) with a maximum clock frequency of 108 MHz.
> Use this value for the device node's spi-max-frequency property.
> 
> This patch has been tested on ROCK Pi 4A.
> 
> Signed-off-by: Stefan Nagy <stefan.nagy at ixypsilon.net>

Looks good to me.  It would be nice, if you have time, to include some 
SPI benchmark results before and after the change in the commit message.

Otherwise,

Reviewed-by: Dragan Simic <dsimic at manjaro.org>

> ---
> Changes from v1:
> - Use the maximum clock frequency the SPI chip actually supports
>   instead of the SPI clock frequency limit of 50 MHz set by the
>   Rockchip SPI driver.
> ---
>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts | 2 +-
>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts | 2 +-
>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> index d5df8939a..c68f45849 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts
> @@ -19,6 +19,6 @@ &spi1 {
>  	flash at 0 {
>  		compatible = "jedec,spi-nor";
>  		reg = <0>;
> -		spi-max-frequency = <10000000>;
> +		spi-max-frequency = <108000000>;
>  	};
>  };
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> index bee6d7588..6ea3180e5 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
> @@ -37,7 +37,7 @@ &spi1 {
>  	flash at 0 {
>  		compatible = "jedec,spi-nor";
>  		reg = <0>;
> -		spi-max-frequency = <10000000>;
> +		spi-max-frequency = <108000000>;
>  	};
>  };
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> index de2ebe4cb..5274938bf 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts
> @@ -49,7 +49,7 @@ &spi1 {
>  	flash at 0 {
>  		compatible = "jedec,spi-nor";
>  		reg = <0>;
> -		spi-max-frequency = <10000000>;
> +		spi-max-frequency = <108000000>;
>  	};
>  };


From wim at linux-watchdog.org  Sun Dec 17 07:34:48 2023
From: wim at linux-watchdog.org (Wim Van Sebroeck)
Date: Sun, 17 Dec 2023 16:34:48 +0100
Subject: [PATCH] watchdog: bcm2835_wdt: Fix WDIOC_SETTIMEOUT handling
In-Reply-To: <f0354dc4-e6f1-41c5-9a99-9847c96a15c2@gmx.net>
References: <20231112173251.4827-1-wahrenst@gmx.net>
 <cce852fd-618c-44f5-aa86-1cd33bd97351@roeck-us.net>
 <f0354dc4-e6f1-41c5-9a99-9847c96a15c2@gmx.net>
Message-ID: <20231217153448.GB6196@www.linux-watchdog.org>

Hi Stefan,

> Hi,
> 
> Am 13.11.23 um 15:31 schrieb Guenter Roeck:
> >On Sun, Nov 12, 2023 at 06:32:51PM +0100, Stefan Wahren wrote:
> >>Users report about the unexpected behavior for setting timeouts above
> >>15 sec on Raspberry Pi. According to watchdog-api.rst the ioctl
> >>WDIOC_SETTIMEOUT shouldn't fail because of hardware limitations.
> >>But looking at the code shows that max_timeout based on the
> >>register value PM_WDOG_TIME_SET, which is the maximum.
> >>
> >>Since 664a39236e71 ("watchdog: Introduce hardware maximum heartbeat
> >>in watchdog core") the watchdog core is able to handle this problem.
> >>
> >>This fix has been tested with watchdog-test from selftests.
> >>
> >>Link: https://bugzilla.kernel.org/show_bug.cgi?id=217374
> >>Fixes: 664a39236e71 ("watchdog: Introduce hardware maximum heartbeat in watchdog core")
> >>Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
> >Reviewed-by: Guenter Roeck <linux at roeck-us.net>
> who takes care of this patch?

I did.

Kind regards,
Wim.



From andrew at lunn.ch  Sun Dec 17 08:57:10 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 17 Dec 2023 17:57:10 +0100
Subject: [PATCH net-next v4 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <20231215214523.ntk5kec32mb5vqjs@skbuf>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-2-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-2-maxime.chevallier@bootlin.com>
 <20231215214523.ntk5kec32mb5vqjs@skbuf>
Message-ID: <ede222d4-11da-4b95-a685-17cb480694dd@lunn.ch>

On Fri, Dec 15, 2023 at 11:45:23PM +0200, Vladimir Oltean wrote:
> On Fri, Dec 15, 2023 at 06:12:23PM +0100, Maxime Chevallier wrote:
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > index d8e9335d415c..89daaccc9276 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -1491,6 +1500,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> >  
> >  		if (phydev->sfp_bus_attached)
> >  			dev->sfp_bus = phydev->sfp_bus;
> > +
> > +		err = phy_link_topo_add_phy(&dev->link_topo, phydev,
> > +					    PHY_UPSTREAM_MAC, dev);
> > +		if (err)
> > +			goto error;
> >  	}
> >  
> >  	/* Some Ethernet drivers try to connect to a PHY device before
> > @@ -1816,6 +1830,7 @@ void phy_detach(struct phy_device *phydev)
> >  	if (dev) {
> >  		phydev->attached_dev->phydev = NULL;
> >  		phydev->attached_dev = NULL;
> > +		phy_link_topo_del_phy(&dev->link_topo, phydev);
> >  	}
> >  	phydev->phylink = NULL;
> >  
> > diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
> > new file mode 100644
> > index 000000000000..22f6372d002c
> > --- /dev/null
> > +++ b/drivers/net/phy/phy_link_topology.c
> > +int phy_link_topo_add_phy(struct phy_link_topology *topo,
> > +			  struct phy_device *phy,
> > +			  enum phy_upstream upt, void *upstream)
> > +{
> > +	struct phy_device_node *pdn;
> > +	int ret;
> > +
> > +	/* Protects phy and upstream */
> > +	ASSERT_RTNL();
> 
> Something to think for the PHY library maintainers. This is probably
> the first time when the rtnl_lock() requirement is asserted at
> phy_attach_direct() time.

There are two use cases here for plain MAC drivers.

1) phy_attach_direct() is called from probe. RTNL is normally not
held, the driver would have to take it before making the call.

2) phy_attach_direct() is called from ndo_open. In that case,
__dev_open() has a ASSERT_RTNL() so we can assume RTNL has been taken.

So i don't think we can assume RTNL is held, but it might be held.

We need a better understanding what is being protected here.

   Andrew


From quic_mnaresh at quicinc.com  Sun Dec 17 09:03:20 2023
From: quic_mnaresh at quicinc.com (Naresh Maramaina)
Date: Sun, 17 Dec 2023 22:33:20 +0530
Subject: [PATCH V5 0/2] Add CPU latency QoS support for ufs driver
In-Reply-To: <DM6PR04MB657594F8BFE75A8F68855A2EFC93A@DM6PR04MB6575.namprd04.prod.outlook.com>
References: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
 <DM6PR04MB657594F8BFE75A8F68855A2EFC93A@DM6PR04MB6575.namprd04.prod.outlook.com>
Message-ID: <0debdc71-2ee2-4a0d-9789-5aea4191a305@quicinc.com>

On 12/15/2023 2:35 PM, Avri Altman wrote:
>> Add CPU latency QoS support for ufs driver. This improves random io
>> performance by 15% for ufs.
>>
>> tiotest benchmark tool io performance results on sm8550 platform:
> Will it possible to provide test results for non-ufs4.0 platforms?
> e.g. for SM8250, just to know if it would make sense to backport this to earlier releases.
> 

Hi Avri,

Performed tiotest benchmark tool io performance test on SM8450 platform 
and see good improvement there as well.

> Thanks,
> Avri

Thanks,
Naresh.


From manivannan.sadhasivam at linaro.org  Sun Dec 17 09:06:55 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Sun, 17 Dec 2023 22:36:55 +0530
Subject: [PATCH v4 01/15] PCI: imx6: Simplify clock handling by using
 bulk_clk_*() function
In-Reply-To: <20231217051210.754832-2-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
 <20231217051210.754832-2-Frank.Li@nxp.com>
Message-ID: <20231217170655.GC6748@thinkpad>

On Sun, Dec 17, 2023 at 12:11:56AM -0500, Frank Li wrote:
> Refactors the clock handling logic in the imx6 PCI driver by adding
> clk_names[] define in drvdata . Simplifies the code and makes it more
> maintainable, as future additions of SOC support will only require
> straightforward changes.
> 

Commit description should be in imperative mood as per
Documentation/process/submitting-patches.rst:

"Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour."

> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> 
> Notes:
>     Change from v3 to v4
>     - using clk_bulk_*() API
>     Change from v1 to v3
>     - none
> 
>  drivers/pci/controller/dwc/pci-imx6.c | 128 ++++++++------------------
>  1 file changed, 38 insertions(+), 90 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 74703362aeec7..2086214345e9a 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c

[...]

>  static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
> @@ -1305,32 +1265,19 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  		return imx6_pcie->reset_gpio;
>  	}
>  
> -	/* Fetch clocks */
> -	imx6_pcie->pcie_bus = devm_clk_get(dev, "pcie_bus");
> -	if (IS_ERR(imx6_pcie->pcie_bus))
> -		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_bus),
> -				     "pcie_bus clock source missing or invalid\n");
> +	while (imx6_pcie->drvdata->clk_names[imx6_pcie->clks_cnt]) {
> +		int i = imx6_pcie->clks_cnt;
>  
> -	imx6_pcie->pcie = devm_clk_get(dev, "pcie");
> -	if (IS_ERR(imx6_pcie->pcie))
> -		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
> -				     "pcie clock source missing or invalid\n");
> +		imx6_pcie->clks[i].id = imx6_pcie->drvdata->clk_names[i];
> +		imx6_pcie->clks_cnt++;

You can just initialize clks_cnt in drv_data with sizeof() of clk_names.

> +	}
> +
> +	/* Fetch clocks */
> +	ret = devm_clk_bulk_get(dev, imx6_pcie->clks_cnt, imx6_pcie->clks);
> +	if (ret)
> +		return ret;
>  
>  	switch (imx6_pcie->drvdata->variant) {
> -	case IMX6SX:
> -		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
> -							   "pcie_inbound_axi");
> -		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
> -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
> -					     "pcie_inbound_axi clock missing or invalid\n");
> -		break;
> -	case IMX8MQ:
> -	case IMX8MQ_EP:
> -		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> -		if (IS_ERR(imx6_pcie->pcie_aux))
> -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> -					     "pcie_aux clock source missing or invalid\n");
> -		fallthrough;
>  	case IMX7D:
>  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
>  			imx6_pcie->controller_id = 1;
> @@ -1353,10 +1300,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	case IMX8MM_EP:
>  	case IMX8MP:
>  	case IMX8MP_EP:
> -		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> -		if (IS_ERR(imx6_pcie->pcie_aux))
> -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> -					     "pcie_aux clock source missing or invalid\n");
>  		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
>  									 "apps");
>  		if (IS_ERR(imx6_pcie->apps_reset))
> @@ -1372,14 +1315,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	default:
>  		break;
>  	}
> -	/* Don't fetch the pcie_phy clock, if it has abstract PHY driver */
> -	if (imx6_pcie->phy == NULL) {
> -		imx6_pcie->pcie_phy = devm_clk_get(dev, "pcie_phy");
> -		if (IS_ERR(imx6_pcie->pcie_phy))
> -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_phy),
> -					     "pcie_phy clock source missing or invalid\n");
> -	}
> -
>  
>  	/* Grab turnoff reset */
>  	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
> @@ -1470,6 +1405,9 @@ static void imx6_pcie_shutdown(struct platform_device *pdev)
>  	imx6_pcie_assert_core_reset(imx6_pcie);
>  }
>  
> +#define IMX6_CLKS_COMMON "pcie_bus", "pcie"
> +#define IMX6_CLKS_NO_PHYDRV IMX6_CLKS_COMMON, "pcie_phy"
> +

Just use the clock names directly instead of definitions. It makes the code more
readable.

Rest LGTM!

- Mani

-- 
????????? ????????


From andrew at lunn.ch  Sun Dec 17 09:07:46 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 17 Dec 2023 18:07:46 +0100
Subject: [PATCH net-next v4 04/13] net: sfp: Add helper to return the SFP
 bus name
In-Reply-To: <20231215171237.1152563-5-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-5-maxime.chevallier@bootlin.com>
Message-ID: <5a5f9350-806d-4b14-a89c-8ffe838891d1@lunn.ch>

On Fri, Dec 15, 2023 at 06:12:26PM +0100, Maxime Chevallier wrote:
> Knowing the bus name is helpful when we want to expose the link topology
> to userspace, add a helper to return the SFP bus name.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From andrew at lunn.ch  Sun Dec 17 09:11:25 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 17 Dec 2023 18:11:25 +0100
Subject: [PATCH net-next v4 05/13] net: ethtool: Allow passing a phy
 index for some commands
In-Reply-To: <20231215171237.1152563-6-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-6-maxime.chevallier@bootlin.com>
Message-ID: <86b10dd4-8eb5-4c48-9a0d-d912f4b15575@lunn.ch>

On Fri, Dec 15, 2023 at 06:12:27PM +0100, Maxime Chevallier wrote:
> Some netlink commands are target towards ethernet PHYs, to control some
> of their features. As there's several such commands, add the ability to
> pass a PHY index in the ethnl request, which will populate the generic
> ethnl_req_info with the relevant phydev when the command targets a PHY.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From andrew at lunn.ch  Sun Dec 17 09:11:47 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 17 Dec 2023 18:11:47 +0100
Subject: [PATCH net-next v4 06/13] netlink: specs: add phy-index as a
 header parameter
In-Reply-To: <20231215171237.1152563-7-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-7-maxime.chevallier@bootlin.com>
Message-ID: <670d095e-4878-4050-9997-75aef648a975@lunn.ch>

On Fri, Dec 15, 2023 at 06:12:28PM +0100, Maxime Chevallier wrote:
> Update the spec to take the newly introduced phy-index as a generic
> request parameter.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From manivannan.sadhasivam at linaro.org  Sun Dec 17 09:18:11 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Sun, 17 Dec 2023 22:48:11 +0530
Subject: [PATCH v4 02/15] PCI: imx6: Simplify phy handling by using by
 using IMX6_PCIE_FLAG_HAS_PHY
In-Reply-To: <20231217051210.754832-3-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
 <20231217051210.754832-3-Frank.Li@nxp.com>
Message-ID: <20231217171811.GD6748@thinkpad>

On Sun, Dec 17, 2023 at 12:11:57AM -0500, Frank Li wrote:
> Refactors the phy handling logic in the imx6 PCI driver by adding
> IMX6_PCIE_FLAG_HAS_PHY bitmask define for drvdata::flags.
> 
> The drvdata::flags and a bitmask ensures a cleaner and more scalable
> switch-case structure for handling phy.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> 
> Notes:
>     Change from v1 to v3:
>     - none
> 
>  drivers/pci/controller/dwc/pci-imx6.c | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 2086214345e9a..91ba26a4b4c3d 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -60,6 +60,9 @@ enum imx6_pcie_variants {
>  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
>  #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
>  #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
> +#define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
> +
> +#define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
>  
>  #define IMX6_PCIE_MAX_CLKS       6
>  
> @@ -1277,6 +1280,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
>  
> +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY)) {
> +		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");

Can't you use devm_phy_optional_get()? This will return NULL if the PHY is not
defined in DT. So you can use IS_ERR() to catch error if there are issues in
acquiring PHY if defined and NULL can be safely passed to other PHY APIs like
phy_init() as well.

With this, you won't need a flag in drv_data and can also get rid of the
condition around PHY APIs.

- Mani

> +		if (IS_ERR(imx6_pcie->phy))
> +			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
> +					     "failed to get pcie phy\n");
> +	}
> +
>  	switch (imx6_pcie->drvdata->variant) {
>  	case IMX7D:
>  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> @@ -1306,11 +1316,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
>  					     "failed to get pcie apps reset control\n");
>  
> -		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
> -		if (IS_ERR(imx6_pcie->phy))
> -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
> -					     "failed to get pcie phy\n");
> -
>  		break;
>  	default:
>  		break;
> @@ -1447,13 +1452,15 @@ static const struct imx6_pcie_drvdata drvdata[] = {
>  	},
>  	[IMX8MM] = {
>  		.variant = IMX8MM,
> -		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> +			 IMX6_PCIE_FLAG_HAS_PHY,
>  		.gpr = "fsl,imx8mm-iomuxc-gpr",
>  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
>  	},
>  	[IMX8MP] = {
>  		.variant = IMX8MP,
> -		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> +			 IMX6_PCIE_FLAG_HAS_PHY,
>  		.gpr = "fsl,imx8mp-iomuxc-gpr",
>  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
>  	},
> @@ -1465,12 +1472,14 @@ static const struct imx6_pcie_drvdata drvdata[] = {
>  	},
>  	[IMX8MM_EP] = {
>  		.variant = IMX8MM_EP,
> +		.flags = IMX6_PCIE_FLAG_HAS_PHY,
>  		.mode = DW_PCIE_EP_TYPE,
>  		.gpr = "fsl,imx8mm-iomuxc-gpr",
>  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
>  	},
>  	[IMX8MP_EP] = {
>  		.variant = IMX8MP_EP,
> +		.flags = IMX6_PCIE_FLAG_HAS_PHY,
>  		.mode = DW_PCIE_EP_TYPE,
>  		.gpr = "fsl,imx8mp-iomuxc-gpr",
>  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
> -- 
> 2.34.1
> 

-- 
????????? ????????


From andersson at kernel.org  Sun Dec 17 09:21:12 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Sun, 17 Dec 2023 11:21:12 -0600
Subject: (subset) [PATCH v2 0/6] SM8450 / SM8550 Adreno
In-Reply-To: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
References: <20231127-topic-a7xx_dt-v2-0-2a437588e563@linaro.org>
Message-ID: <170283349413.66089.744756231960843910.b4-ty@kernel.org>


On Mon, 04 Dec 2023 13:55:19 +0100, Konrad Dybcio wrote:
> Following the merging of related bindings, driver and mesa changes, enable
> the GPU on both of these platforms.
> 
> P1 for Will/iommu, rest for qcom
> 
> 

Applied, thanks!

[2/6] arm64: dts: qcom: sm8450: Add GPU nodes
      commit: 9810647a043678638f3b98ab48ee030bc00c8270
[3/6] arm64: dts: qcom: sm8550: Add GPU nodes
      commit: ef19923ae103b527e6762a63024dc7f0b1055546
[4/6] arm64: dts: qcom: sm8550-qrd: Enable the A740 GPU
      commit: c9f785d7d546c3f38c2e0308fa91e27ae7ec3fda
[5/6] arm64: dts: qcom: sm8550-mtp: Enable the A740 GPU
      commit: e877f075a52c485742cfd170f5557fc49972979e
[6/6] arm64: dts: qcom: sm8450-hdk: Enable the A730 GPU
      commit: 0f6f5a220543d1239dc7fc04c9f8f8885fa05637

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From oliver.upton at linux.dev  Sun Dec 17 09:33:10 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Sun, 17 Dec 2023 17:33:10 +0000
Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset
In-Reply-To: <87a5q983zc.wl-maz@kernel.org>
References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
 <87a5q983zc.wl-maz@kernel.org>
Message-ID: <ZX8w1vfQzeXP5klL@linux.dev>

On Sun, Dec 17, 2023 at 11:26:15AM +0000, Marc Zyngier wrote:

[...]

> But this has *nothing* to do with the guest. This is the *host*
> userspace performing a write to the redistributor view, which has
> different semantics. Which is why your earlier description made no
> sense to me.
> 
> I think the problem is slightly larger than what you describe. A write
> to ISPENDR0 should be propagated to the ITS for any values of the
> latch, just like this happens on enabling HW-backed SGIs.
> 
> Can you please give this a go?

What do you think about using this as an opportunity for a bit of
cleanup? It'd be nice unify the various MMIO and uaccess handlers for
SPENDING + CPENDING while being careful about the arch_timer interrupt.

	clear = ~val;
	vgic_uaccess_write_spending(val);
	vgic_uaccess_write_cpending(clear);

Happy to take your fix too, especially in case I missed something
obvious :)

[*] https://git.kernel.org/pub/scm/linux/kernel/git/oupton/linux.git/log/?h=kvm-arm64/vsgi-spending-fixes

-- 
Thanks,
Oliver


From oliver.upton at linux.dev  Sun Dec 17 09:34:38 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Sun, 17 Dec 2023 17:34:38 +0000
Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset
In-Reply-To: <ZX8w1vfQzeXP5klL@linux.dev>
References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
 <87a5q983zc.wl-maz@kernel.org>
 <ZX8w1vfQzeXP5klL@linux.dev>
Message-ID: <ZX8xLhFFqTXRFQtd@linux.dev>

On Sun, Dec 17, 2023 at 05:33:16PM +0000, Oliver Upton wrote:
> On Sun, Dec 17, 2023 at 11:26:15AM +0000, Marc Zyngier wrote:
> 
> [...]
> 
> > But this has *nothing* to do with the guest. This is the *host*
> > userspace performing a write to the redistributor view, which has
> > different semantics. Which is why your earlier description made no
> > sense to me.
> > 
> > I think the problem is slightly larger than what you describe. A write
> > to ISPENDR0 should be propagated to the ITS for any values of the
> > latch, just like this happens on enabling HW-backed SGIs.
> > 
> > Can you please give this a go?
> 
> What do you think about using this as an opportunity for a bit of
> cleanup? It'd be nice unify the various MMIO and uaccess handlers for
> SPENDING + CPENDING while being careful about the arch_timer interrupt.

Cut myself off... Meant to say that user writes to SPENDING for GICv3
can then be treated as:

> 	clear = ~val;
> 	vgic_uaccess_write_spending(val);
> 	vgic_uaccess_write_cpending(clear);

-- 
Thanks,
Oliver


From manivannan.sadhasivam at linaro.org  Sun Dec 17 09:34:49 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Sun, 17 Dec 2023 23:04:49 +0530
Subject: [PATCH v4 03/15] PCI: imx6: Simplify reset handling by using by
 using *_FLAG_HAS_*_RESET
In-Reply-To: <20231217051210.754832-4-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
 <20231217051210.754832-4-Frank.Li@nxp.com>
Message-ID: <20231217173449.GE6748@thinkpad>

On Sun, Dec 17, 2023 at 12:11:58AM -0500, Frank Li wrote:
> Refactors the reset handling logic in the imx6 PCI driver by adding
> IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.
> 
> The drvdata::flags and a bitmask ensures a cleaner and more scalable
> switch-case structure for handling reset.
> 
> Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> Signed-off-by: Frank Li <Frank.Li at nxp.com>

One nitpick below. With that fixed,

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>

> ---
> 
> Notes:
>     Change from v2 to v3:
>     - add Philipp's Reviewed-by tag
>     Change from v1 to v2:
>     - remove condition check before reset_control_(de)assert() because it is
>       none ops if a NULL pointer pass down.
>     - still keep condition check at probe to help identify dts file mismatch
>       problem.
>     
>     Change from v1 to v2:
>     - remove condition check before reset_control_(de)assert() because it is
>       none ops if a NULL pointer pass down.
>     - still keep condition check at probe to help identify dts file mismatch
>       problem.
> 
>  drivers/pci/controller/dwc/pci-imx6.c | 108 ++++++++++----------------
>  1 file changed, 41 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 91ba26a4b4c3d..c1fb38a2ebeb6 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c

[...]

> @@ -1441,31 +1407,39 @@ static const struct imx6_pcie_drvdata drvdata[] = {
>  	},
>  	[IMX7D] = {
>  		.variant = IMX7D,
> -		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> +			 IMX6_PCIE_FLAG_HAS_APP_RESET |
> +			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
>  		.gpr = "fsl,imx7d-iomuxc-gpr",
>  		.clk_names = {IMX6_CLKS_NO_PHYDRV},
>  	},
>  	[IMX8MQ] = {
>  		.variant = IMX8MQ,
> +		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
> +			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
>  		.gpr = "fsl,imx8mq-iomuxc-gpr",
>  		.clk_names = {IMX6_CLKS_NO_PHYDRV, "pcie_aux"},
>  	},
>  	[IMX8MM] = {
>  		.variant = IMX8MM,
>  		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> -			 IMX6_PCIE_FLAG_HAS_PHY,
> +			 IMX6_PCIE_FLAG_HAS_PHY |
> +			 IMX6_PCIE_FLAG_HAS_APP_RESET,
>  		.gpr = "fsl,imx8mm-iomuxc-gpr",
>  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
>  	},
>  	[IMX8MP] = {
>  		.variant = IMX8MP,
>  		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> -			 IMX6_PCIE_FLAG_HAS_PHY,
> +			 IMX6_PCIE_FLAG_HAS_PHY |
> +			 IMX6_PCIE_FLAG_HAS_APP_RESET,
>  		.gpr = "fsl,imx8mp-iomuxc-gpr",
>  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
>  	},
>  	[IMX8MQ_EP] = {
>  		.variant = IMX8MQ_EP,
> +		.flags = IMX6_PCIE_FLAG_HAS_PHY |

This change is not part of this patch.

- Mani

-- 
????????? ????????


From andrew at lunn.ch  Sun Dec 17 09:44:27 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 17 Dec 2023 18:44:27 +0100
Subject: [PATCH v2] arm64: dts: ti: k3-am654-icssg2: Enable PHY
 interrupts for ICSSG2
In-Reply-To: <6f1c1a59-cec0-46d1-8ecb-a82d9d444ccf@ti.com>
References: <20231213080216.1710730-1-s-vadapalli@ti.com>
 <20231213123819.tqh3lm2ceir3qjbk@swimmer>
 <6f1c1a59-cec0-46d1-8ecb-a82d9d444ccf@ti.com>
Message-ID: <b0ecbd1f-354a-443a-849b-b00d2f1554d5@lunn.ch>

> Yes, you are right! Edge-Triggered interrupts shouldn't be shared. I missed
> noticing this. Thank you for pointing it out. Since the SoC only supports
> Edge-Triggered interrupts, I believe that the correct decision would be to use
> the interrupt for only one of the two PHYs, while leaving the other PHY in
> polled mode of operation which is the default.

No, if the PHY is using level interrupts, you need the SoC to use
level interrupts. Otherwise you are going to miss interrupts.

The board design is just broken and you cannot use interrupts at all.

    Andrew


From manivannan.sadhasivam at linaro.org  Sun Dec 17 09:51:58 2023
From: manivannan.sadhasivam at linaro.org (Manivannan Sadhasivam)
Date: Sun, 17 Dec 2023 23:21:58 +0530
Subject: [PATCH v4 04/15] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231217051210.754832-5-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
 <20231217051210.754832-5-Frank.Li@nxp.com>
Message-ID: <20231217175158.GF6748@thinkpad>

On Sun, Dec 17, 2023 at 12:11:59AM -0500, Frank Li wrote:
> Avoid use get slot id by compared with register physical address. If there
> are more than 2 slots, compared logic will become complex.
> 
> "linux,pci-domain" already exist at dts since first commit:
> 	commit (9e65987b9584d arm64: dts: imx8mp: Add iMX8MP PCIe support).
> 
> So it is safe to remove compare basic address code:

You should mark this property as "required" in the binding. Otherwise, drivers
cannot make assumptions.

> 	...
> 	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> 		imx6_pcie->controller_id = 1;
> 	...
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> 
> Notes:
>     Change from v3 to v4
>     - remove compare basic address logic
>     Change from v2 to v3
>     - none
>     Change from v1 to v2
>     - fix of_get_pci_domain_nr return value check logic
> 
>  drivers/pci/controller/dwc/pci-imx6.c | 14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index c1fb38a2ebeb6..7145947e21d92 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -33,6 +33,7 @@
>  #include <linux/pm_domain.h>
>  #include <linux/pm_runtime.h>
>  
> +#include "../../pci.h"
>  #include "pcie-designware.h"
>  
>  #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
> @@ -40,7 +41,6 @@
>  #define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE	BIT(11)
>  #define IMX8MQ_GPR_PCIE_VREG_BYPASS		BIT(12)
>  #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
> -#define IMX8MQ_PCIE2_BASE_ADDR			0x33c00000
>  
>  #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
>  
> @@ -1279,13 +1279,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  					     "Failed to get PCIEPHY reset control\n");
>  	}
>  
> -	switch (imx6_pcie->drvdata->variant) {
> -	case IMX7D:
> -		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> -			imx6_pcie->controller_id = 1;
> -	default:
> -		break;
> -	}
> +	/* Using linux,pci-domain as PCI slot id */
> +	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
> +	/* If there are not "linux,pci-domain" in dts file, means only 1 controller */

Only -EINVAL means the property is not present, other error codes means property
is present, but is not in good shape.

- Mani

> +	if (imx6_pcie->controller_id < 0)
> +		imx6_pcie->controller_id = 0;
>  
>  	/* Grab turnoff reset */
>  	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
> -- 
> 2.34.1
> 

-- 
????????? ????????


From andrew at lunn.ch  Sun Dec 17 09:55:10 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 17 Dec 2023 18:55:10 +0100
Subject: [PATCH v3 6/9] riscv: dts: starfive: visionfive-v1: Setup
 ethernet phy
In-Reply-To: <20231215204050.2296404-7-cristian.ciocaltea@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-7-cristian.ciocaltea@collabora.com>
Message-ID: <f8f9d454-6155-4b1c-b4b2-daf98267be14@lunn.ch>

On Fri, Dec 15, 2023 at 10:40:45PM +0200, Cristian Ciocaltea wrote:
> The StarFive VisionFive V1 SBC uses a Motorcomm YT8521 PHY supporting
> RGMII-ID, but requires manual adjustment of the RX internal delay to
> work properly.
> 
> The default RX delay provided by the driver is 1.95 ns, which proves to
> be too high. Applying a 50% reduction seems to mitigate the issue.
> 
> Also note this adjustment is not necessary on BeagleV Starlight SBC,
> which uses a Microchip PHY.  Hence, there is no indication of a
> miss-behaviour on the GMAC side, but most likely the issue stems from
> the Motorcomm PHY.

I suggest you make a similar comment in the .dts file, just to explain
the odd setting.

	Andrew


From maz at kernel.org  Sun Dec 17 10:52:55 2023
From: maz at kernel.org (Marc Zyngier)
Date: Sun, 17 Dec 2023 18:52:55 +0000
Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset
In-Reply-To: <ZX8xLhFFqTXRFQtd@linux.dev>
References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
	<87a5q983zc.wl-maz@kernel.org>
	<ZX8w1vfQzeXP5klL@linux.dev>
	<ZX8xLhFFqTXRFQtd@linux.dev>
Message-ID: <878r5s8xvc.wl-maz@kernel.org>

On Sun, 17 Dec 2023 17:34:38 +0000,
Oliver Upton <oliver.upton at linux.dev> wrote:
> 
> On Sun, Dec 17, 2023 at 05:33:16PM +0000, Oliver Upton wrote:
> > On Sun, Dec 17, 2023 at 11:26:15AM +0000, Marc Zyngier wrote:
> > 
> > [...]
> > 
> > > But this has *nothing* to do with the guest. This is the *host*
> > > userspace performing a write to the redistributor view, which has
> > > different semantics. Which is why your earlier description made no
> > > sense to me.
> > > 
> > > I think the problem is slightly larger than what you describe. A write
> > > to ISPENDR0 should be propagated to the ITS for any values of the
> > > latch, just like this happens on enabling HW-backed SGIs.
> > > 
> > > Can you please give this a go?
> > 
> > What do you think about using this as an opportunity for a bit of
> > cleanup? It'd be nice unify the various MMIO and uaccess handlers for
> > SPENDING + CPENDING while being careful about the arch_timer interrupt.

What is special about the timer interrupt?

> Cut myself off... Meant to say that user writes to SPENDING for GICv3
> can then be treated as:
> 
> > 	clear = ~val;
> > 	vgic_uaccess_write_spending(val);
> > 	vgic_uaccess_write_cpending(clear);

Could be. But I'd rather have separate fixes from more invasive
reworks.  Specially given that we have had multiple ugly bugs around
this code in the past, which is why we ended up splitting userspace
from guest accessors.

	M.

-- 
Without deviation from the norm, progress is not possible.


From conor at kernel.org  Sun Dec 17 13:00:49 2023
From: conor at kernel.org (Conor Dooley)
Date: Sun, 17 Dec 2023 21:00:49 +0000
Subject: [PATCH v2 01/27] dt-bindings: display: rockchip,inno-hdmi:
 Document RK3128 compatible
In-Reply-To: <20231216162639.125215-2-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-2-knaerzche@gmail.com>
Message-ID: <20231217-anime-ammonia-0c21d756aa9f@spud>

On Sat, Dec 16, 2023 at 05:26:12PM +0100, Alex Bee wrote:
> The integration for this SoC is different from the currently existing: It
> needs it's PHY's reference clock rate to calculate the DDC bus frequency
> correctly. The controller is also part of a powerdomain, so this gets added
> as an mandatory property for this variant.

Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231217/f864d5da/attachment.sig>

From conor at kernel.org  Sun Dec 17 13:03:36 2023
From: conor at kernel.org (Conor Dooley)
Date: Sun, 17 Dec 2023 21:03:36 +0000
Subject: [PATCH v3 5/9] riscv: dts: starfive: jh7100-common: Setup pinmux
 and enable gmac
In-Reply-To: <CAJM55Z-bg0EGPaLHtxcu2AzqN59zfuiT0eE7oCShrx7dG_QK1g@mail.gmail.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-6-cristian.ciocaltea@collabora.com>
 <CAJM55Z-bg0EGPaLHtxcu2AzqN59zfuiT0eE7oCShrx7dG_QK1g@mail.gmail.com>
Message-ID: <20231217-rippling-galleria-904152e41f95@spud>

On Sat, Dec 16, 2023 at 11:38:53AM -0800, Emil Renner Berthing wrote:
> Cristian Ciocaltea wrote:
> > Add pinmux configuration for DWMAC found on the JH7100 based boards and
> > enable the related DT node, providing a basic PHY configuration.
> >
> > Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
> > Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
> > ---
> >  .../boot/dts/starfive/jh7100-common.dtsi      | 85 +++++++++++++++++++
> >  1 file changed, 85 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > index 42fb61c36068..5cafe8f5c2e7 100644
> > --- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > +++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
> > @@ -72,7 +72,92 @@ wifi_pwrseq: wifi-pwrseq {
> >  	};
> >  };
> >
> > +&gmac {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&gmac_pins>;
> > +	phy-mode = "rgmii-id";
> > +	phy-handle = <&phy>;
> 
> I'm not sure if it's a generic policy or not, but I don't really like adding a
> reference to a non-existant node here. I'd move this property to the board
> files where the phy node is actually defined.

FWIW, I don't like the reference-in-the-wrong-place thing either.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231217/951b1f51/attachment.sig>

From andersson at kernel.org  Sun Dec 17 13:06:05 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Sun, 17 Dec 2023 15:06:05 -0600
Subject: [PATCH 0/2] arm64: defconfig: enable drivers for the Lenovo ThinkPad X13s
In-Reply-To: <20231012080157.4616-1-johan+linaro@kernel.org>
References: <20231012080157.4616-1-johan+linaro@kernel.org>
Message-ID: <170284716296.78529.6640577574918372135.b4-ty@kernel.org>


On Thu, 12 Oct 2023 10:01:55 +0200, Johan Hovold wrote:
> Enable some more drivers for Qualcomm sc8280xp based machines like the
> Lenovo ThinkPad X13s so that sound and EFI variables work with the
> defconfig.
> 
> Johan
> 
> 
> [...]

Applied, thanks!

[1/2] arm64: defconfig: enable Qualcomm sc8280xp sound drivers
      commit: 223e8af324985de9e0b5b4cda2ec29783410f13f
[2/2] arm64: defconfig: enable Qualcomm UEFI Secure App driver
      commit: 48490899007ae98faf8a0071a602174502b8eefc

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From bigunclemax at gmail.com  Sun Dec 17 13:06:21 2023
From: bigunclemax at gmail.com (Maksim Kiselev)
Date: Mon, 18 Dec 2023 00:06:21 +0300
Subject: [PATCH v6 0/3] Add D1/T113s thermal sensor controller support
Message-ID: <20231217210629.131486-1-bigunclemax@gmail.com>

This series adds support for Allwinner D1/T113s thermal sensor controller.
THIS controller is similar to the one on H6, but with only one sensor and
uses a different scale and offset values.

v6:
- Rebased onto 6.7.0-rc5

v5:
- Dropeed 'thermal-zones' node from sunxi-d1s-t113.dtsi

v4:
- Dropeed DT bindings example

v3:
- Fixed SoB tag again

v2:
- Fixed SoB tag
- Moved binding patch before driver changes

v1:
- Initial version

Maxim Kiselev (3):
  dt-bindings: thermal: sun8i: Add binding for D1/T113s THS controller
  thermal: sun8i: Add D1/T113s THS controller support
  riscv: dts: allwinner: d1: Add thermal sensor

 .../thermal/allwinner,sun8i-a83t-ths.yaml       |  7 ++++++-
 .../boot/dts/allwinner/sunxi-d1s-t113.dtsi      | 17 +++++++++++++++++
 drivers/thermal/sun8i_thermal.c                 | 13 +++++++++++++
 3 files changed, 36 insertions(+), 1 deletion(-)

-- 
2.40.1



From bigunclemax at gmail.com  Sun Dec 17 13:06:22 2023
From: bigunclemax at gmail.com (Maksim Kiselev)
Date: Mon, 18 Dec 2023 00:06:22 +0300
Subject: [PATCH v6 1/3] dt-bindings: thermal: sun8i: Add binding for D1/T113s THS controller
In-Reply-To: <20231217210629.131486-1-bigunclemax@gmail.com>
References: <20231217210629.131486-1-bigunclemax@gmail.com>
Message-ID: <20231217210629.131486-2-bigunclemax@gmail.com>

From: Maxim Kiselev <bigunclemax at gmail.com>

Add a binding for D1/T113s thermal sensor controller.

Signed-off-by: Maxim Kiselev <bigunclemax at gmail.com>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
---
 .../bindings/thermal/allwinner,sun8i-a83t-ths.yaml         | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml
index fbd4212285e2..9b2272a9ec15 100644
--- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml
+++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml
@@ -16,6 +16,7 @@ properties:
       - allwinner,sun8i-a83t-ths
       - allwinner,sun8i-h3-ths
       - allwinner,sun8i-r40-ths
+      - allwinner,sun20i-d1-ths
       - allwinner,sun50i-a64-ths
       - allwinner,sun50i-a100-ths
       - allwinner,sun50i-h5-ths
@@ -61,6 +62,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - allwinner,sun20i-d1-ths
               - allwinner,sun50i-a100-ths
               - allwinner,sun50i-h6-ths
 
@@ -84,7 +86,9 @@ allOf:
       properties:
         compatible:
           contains:
-            const: allwinner,sun8i-h3-ths
+            enum:
+              - allwinner,sun8i-h3-ths
+              - allwinner,sun20i-d1-ths
 
     then:
       properties:
@@ -103,6 +107,7 @@ allOf:
             enum:
               - allwinner,sun8i-h3-ths
               - allwinner,sun8i-r40-ths
+              - allwinner,sun20i-d1-ths
               - allwinner,sun50i-a64-ths
               - allwinner,sun50i-a100-ths
               - allwinner,sun50i-h5-ths
-- 
2.40.1



From bigunclemax at gmail.com  Sun Dec 17 13:06:23 2023
From: bigunclemax at gmail.com (Maksim Kiselev)
Date: Mon, 18 Dec 2023 00:06:23 +0300
Subject: [PATCH v6 2/3] thermal: sun8i: Add D1/T113s THS controller support
In-Reply-To: <20231217210629.131486-1-bigunclemax@gmail.com>
References: <20231217210629.131486-1-bigunclemax@gmail.com>
Message-ID: <20231217210629.131486-3-bigunclemax@gmail.com>

From: Maxim Kiselev <bigunclemax at gmail.com>

This patch adds a thermal sensor controller support for the D1/T113s,
which is similar to the one on H6, but with only one sensor and
different scale and offset values.

Signed-off-by: Maxim Kiselev <bigunclemax at gmail.com>
---
 drivers/thermal/sun8i_thermal.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
index f989b55a8aa8..6a8e386dbc8d 100644
--- a/drivers/thermal/sun8i_thermal.c
+++ b/drivers/thermal/sun8i_thermal.c
@@ -606,6 +606,18 @@ static const struct ths_thermal_chip sun50i_h6_ths = {
 	.calc_temp = sun8i_ths_calc_temp,
 };
 
+static const struct ths_thermal_chip sun20i_d1_ths = {
+	.sensor_num = 1,
+	.has_bus_clk_reset = true,
+	.offset = 188552,
+	.scale = 673,
+	.temp_data_base = SUN50I_H6_THS_TEMP_DATA,
+	.calibrate = sun50i_h6_ths_calibrate,
+	.init = sun50i_h6_thermal_init,
+	.irq_ack = sun50i_h6_irq_ack,
+	.calc_temp = sun8i_ths_calc_temp,
+};
+
 static const struct of_device_id of_ths_match[] = {
 	{ .compatible = "allwinner,sun8i-a83t-ths", .data = &sun8i_a83t_ths },
 	{ .compatible = "allwinner,sun8i-h3-ths", .data = &sun8i_h3_ths },
@@ -614,6 +626,7 @@ static const struct of_device_id of_ths_match[] = {
 	{ .compatible = "allwinner,sun50i-a100-ths", .data = &sun50i_a100_ths },
 	{ .compatible = "allwinner,sun50i-h5-ths", .data = &sun50i_h5_ths },
 	{ .compatible = "allwinner,sun50i-h6-ths", .data = &sun50i_h6_ths },
+	{ .compatible = "allwinner,sun20i-d1-ths", .data = &sun20i_d1_ths },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, of_ths_match);
-- 
2.40.1



From bigunclemax at gmail.com  Sun Dec 17 13:06:24 2023
From: bigunclemax at gmail.com (Maksim Kiselev)
Date: Mon, 18 Dec 2023 00:06:24 +0300
Subject: [PATCH v6 3/3] riscv: dts: allwinner: d1: Add thermal sensor
In-Reply-To: <20231217210629.131486-1-bigunclemax@gmail.com>
References: <20231217210629.131486-1-bigunclemax@gmail.com>
Message-ID: <20231217210629.131486-4-bigunclemax@gmail.com>

From: Maxim Kiselev <bigunclemax at gmail.com>

This patch adds a thermal sensor controller node for the D1/T113s.
Also it adds a THS calibration data cell to efuse node.

Signed-off-by: Maxim Kiselev <bigunclemax at gmail.com>
---
 .../boot/dts/allwinner/sunxi-d1s-t113.dtsi      | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
index 5a9d7f5a75b4..6f5427d9cfbf 100644
--- a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
+++ b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
@@ -166,6 +166,19 @@ gpadc: adc at 2009000 {
 			#io-channel-cells = <1>;
 		};
 
+		ths: thermal-sensor at 2009400 {
+			compatible = "allwinner,sun20i-d1-ths";
+			reg = <0x02009400 0x400>;
+			interrupts = <SOC_PERIPHERAL_IRQ(58) IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_THS>;
+			clock-names = "bus";
+			resets = <&ccu RST_BUS_THS>;
+			nvmem-cells = <&ths_calibration>;
+			nvmem-cell-names = "calibration";
+			status = "disabled";
+			#thermal-sensor-cells = <0>;
+		};
+
 		dmic: dmic at 2031000 {
 			compatible = "allwinner,sun20i-d1-dmic",
 				     "allwinner,sun50i-h6-dmic";
@@ -415,6 +428,10 @@ sid: efuse at 3006000 {
 			reg = <0x3006000 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+
+			ths_calibration: thermal-sensor-calibration at 14 {
+				reg = <0x14 0x4>;
+			};
 		};
 
 		crypto: crypto at 3040000 {
-- 
2.40.1



From conor at kernel.org  Sun Dec 17 13:09:40 2023
From: conor at kernel.org (Conor Dooley)
Date: Sun, 17 Dec 2023 21:09:40 +0000
Subject: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <6c62e3b2-acde-4580-9b67-56683289e45e@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>
 <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>
 <65fd52f1-6861-42b0-9148-266766d054b1@sifive.com>
 <6c62e3b2-acde-4580-9b67-56683289e45e@collabora.com>
Message-ID: <20231217-spray-livestock-a59d630b751e@spud>

On Fri, Dec 15, 2023 at 11:03:24PM +0200, Cristian Ciocaltea wrote:
> On 12/15/23 22:59, Samuel Holland wrote:
> > On 2023-12-15 2:47 PM, Jessica Clarke wrote:
> >> On 15 Dec 2023, at 20:40, Cristian Ciocaltea <cristian.ciocaltea at collabora.com> wrote:
> >>>
> >>> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
> >>> similar to the newer JH7110, but it requires only two interrupts and a
> >>> single reset line, which is 'ahb' instead of the commonly used
> >>> 'stmmaceth'.
> >>>
> >>> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
> >>> conjunction with 'stmmaceth', extend the logic to also permit exclusive
> >>> usage of the 'ahb' reset name.  This ensures the following use cases are
> >>> supported:
> >>>
> >>>  JH7110: reset-names = "stmmaceth", "ahb";
> >>>  JH7100: reset-names = "ahb";
> >>>  other:  reset-names = "stmmaceth";
> >>>
> >>> Also note the need to use a different dwmac fallback, as v5.20 applies
> >>> to JH7110 only, while JH7100 relies on v3.7x.
> >>>
> >>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
> >>> ---
> >>> .../devicetree/bindings/net/snps,dwmac.yaml   |  3 +-
> >>> .../bindings/net/starfive,jh7110-dwmac.yaml   | 74 +++++++++++++------
> >>> 2 files changed, 55 insertions(+), 22 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> >>> index 5c2769dc689a..c1380ff1c054 100644
> >>> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> >>> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> >>> @@ -95,6 +95,7 @@ properties:
> >>>         - snps,dwmac-5.20
> >>>         - snps,dwxgmac
> >>>         - snps,dwxgmac-2.10
> >>> +        - starfive,jh7100-dwmac
> >>>         - starfive,jh7110-dwmac
> >>>
> >>>   reg:
> >>> @@ -146,7 +147,7 @@ properties:
> >>>   reset-names:
> >>>     minItems: 1
> >>>     items:
> >>> -      - const: stmmaceth
> >>> +      - enum: [stmmaceth, ahb]
> >>>       - const: ahb
> >>
> >> I?m not so well-versed in the YAML bindings, but would this not allow
> >> reset-names = "ahb", "ahb"?
> > 
> > Yes, it would. You need something like:
> > 
> > reset-names:
> >   oneOf:
> >     - enum: [stmmaceth, ahb]
> >     - items:
> >         - const: stmmaceth
> >         - const: ahb
> 
> Oh yes, I always forget about the "oneOf" thing. Thanks!

Won't this also relax the naming for all devices that allow a single
reset, but expect the stmmaceth one? I'm not sure that that actually
matters, I think the consumer bindings have constraints themselves.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231217/2d710f51/attachment.sig>

From daniel at makrotopia.org  Sun Dec 17 13:49:45 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sun, 17 Dec 2023 21:49:45 +0000
Subject: [PATCH v7 2/5] dt-bindings: reset: mediatek: add MT7988 ethwarp
 reset IDs
In-Reply-To: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>
References: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>
Message-ID: <0c14bbacf471683af67ffa7572bfa1d5c45a0b5d.1702849494.git.daniel@makrotopia.org>

Add reset ID for ethwarp subsystem allowing to reset the built-in
Ethernet switch of the MediaTek MT7988 SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
v7: no changes
v6: no changes
v5: add this patch to replace use of ti,syscon-reset in v1~v4

 include/dt-bindings/reset/mediatek,mt7988-resets.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 include/dt-bindings/reset/mediatek,mt7988-resets.h

diff --git a/include/dt-bindings/reset/mediatek,mt7988-resets.h b/include/dt-bindings/reset/mediatek,mt7988-resets.h
new file mode 100644
index 0000000000000..4933019713672
--- /dev/null
+++ b/include/dt-bindings/reset/mediatek,mt7988-resets.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ * Author: Daniel Golle <daniel at makrotopia.org>
+ */
+
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT7988
+#define _DT_BINDINGS_RESET_CONTROLLER_MT7988
+
+/* ETHWARP resets */
+#define MT7988_ETHWARP_RST_SWITCH		0
+
+#endif  /* _DT_BINDINGS_RESET_CONTROLLER_MT7988 */
-- 
2.43.0


From daniel at makrotopia.org  Sun Dec 17 13:49:33 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sun, 17 Dec 2023 21:49:33 +0000
Subject: [PATCH v7 1/5] dt-bindings: clock: mediatek: add MT7988 clock IDs
Message-ID: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add MT7988 clock dt-bindings for topckgen, apmixedsys, infracfg,
ethernet and xfipll subsystem clocks.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
v7: no changes
v6: no changes
v5: no changes
v4: no changes
v3: no changes
v2: fix indentation

 .../dt-bindings/clock/mediatek,mt7988-clk.h   | 280 ++++++++++++++++++
 1 file changed, 280 insertions(+)
 create mode 100644 include/dt-bindings/clock/mediatek,mt7988-clk.h

diff --git a/include/dt-bindings/clock/mediatek,mt7988-clk.h b/include/dt-bindings/clock/mediatek,mt7988-clk.h
new file mode 100644
index 0000000000000..63376e40f14d2
--- /dev/null
+++ b/include/dt-bindings/clock/mediatek,mt7988-clk.h
@@ -0,0 +1,280 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#ifndef _DT_BINDINGS_CLK_MT7988_H
+#define _DT_BINDINGS_CLK_MT7988_H
+
+/* APMIXEDSYS */
+
+#define CLK_APMIXED_NETSYSPLL			0
+#define CLK_APMIXED_MPLL			1
+#define CLK_APMIXED_MMPLL			2
+#define CLK_APMIXED_APLL2			3
+#define CLK_APMIXED_NET1PLL			4
+#define CLK_APMIXED_NET2PLL			5
+#define CLK_APMIXED_WEDMCUPLL			6
+#define CLK_APMIXED_SGMPLL			7
+#define CLK_APMIXED_ARM_B			8
+#define CLK_APMIXED_CCIPLL2_B			9
+#define CLK_APMIXED_USXGMIIPLL			10
+#define CLK_APMIXED_MSDCPLL			11
+
+/* TOPCKGEN */
+
+#define CLK_TOP_XTAL				0
+#define CLK_TOP_XTAL_D2				1
+#define CLK_TOP_RTC_32K				2
+#define CLK_TOP_RTC_32P7K			3
+#define CLK_TOP_MPLL_D2				4
+#define CLK_TOP_MPLL_D3_D2			5
+#define CLK_TOP_MPLL_D4				6
+#define CLK_TOP_MPLL_D8				7
+#define CLK_TOP_MPLL_D8_D2			8
+#define CLK_TOP_MMPLL_D2			9
+#define CLK_TOP_MMPLL_D3_D5			10
+#define CLK_TOP_MMPLL_D4			11
+#define CLK_TOP_MMPLL_D6_D2			12
+#define CLK_TOP_MMPLL_D8			13
+#define CLK_TOP_APLL2_D4			14
+#define CLK_TOP_NET1PLL_D4			15
+#define CLK_TOP_NET1PLL_D5			16
+#define CLK_TOP_NET1PLL_D5_D2			17
+#define CLK_TOP_NET1PLL_D5_D4			18
+#define CLK_TOP_NET1PLL_D8			19
+#define CLK_TOP_NET1PLL_D8_D2			20
+#define CLK_TOP_NET1PLL_D8_D4			21
+#define CLK_TOP_NET1PLL_D8_D8			22
+#define CLK_TOP_NET1PLL_D8_D16			23
+#define CLK_TOP_NET2PLL_D2			24
+#define CLK_TOP_NET2PLL_D4			25
+#define CLK_TOP_NET2PLL_D4_D4			26
+#define CLK_TOP_NET2PLL_D4_D8			27
+#define CLK_TOP_NET2PLL_D6			28
+#define CLK_TOP_NET2PLL_D8			29
+#define CLK_TOP_NETSYS_SEL			30
+#define CLK_TOP_NETSYS_500M_SEL			31
+#define CLK_TOP_NETSYS_2X_SEL			32
+#define CLK_TOP_NETSYS_GSW_SEL			33
+#define CLK_TOP_ETH_GMII_SEL			34
+#define CLK_TOP_NETSYS_MCU_SEL			35
+#define CLK_TOP_NETSYS_PAO_2X_SEL		36
+#define CLK_TOP_EIP197_SEL			37
+#define CLK_TOP_AXI_INFRA_SEL			38
+#define CLK_TOP_UART_SEL			39
+#define CLK_TOP_EMMC_250M_SEL			40
+#define CLK_TOP_EMMC_400M_SEL			41
+#define CLK_TOP_SPI_SEL				42
+#define CLK_TOP_SPIM_MST_SEL			43
+#define CLK_TOP_NFI1X_SEL			44
+#define CLK_TOP_SPINFI_SEL			45
+#define CLK_TOP_PWM_SEL				46
+#define CLK_TOP_I2C_SEL				47
+#define CLK_TOP_PCIE_MBIST_250M_SEL		48
+#define CLK_TOP_PEXTP_TL_SEL			49
+#define CLK_TOP_PEXTP_TL_P1_SEL			50
+#define CLK_TOP_PEXTP_TL_P2_SEL			51
+#define CLK_TOP_PEXTP_TL_P3_SEL			52
+#define CLK_TOP_USB_SYS_SEL			53
+#define CLK_TOP_USB_SYS_P1_SEL			54
+#define CLK_TOP_USB_XHCI_SEL			55
+#define CLK_TOP_USB_XHCI_P1_SEL			56
+#define CLK_TOP_USB_FRMCNT_SEL			57
+#define CLK_TOP_USB_FRMCNT_P1_SEL		58
+#define CLK_TOP_AUD_SEL				59
+#define CLK_TOP_A1SYS_SEL			60
+#define CLK_TOP_AUD_L_SEL			61
+#define CLK_TOP_A_TUNER_SEL			62
+#define CLK_TOP_SSPXTP_SEL			63
+#define CLK_TOP_USB_PHY_SEL			64
+#define CLK_TOP_USXGMII_SBUS_0_SEL		65
+#define CLK_TOP_USXGMII_SBUS_1_SEL		66
+#define CLK_TOP_SGM_0_SEL			67
+#define CLK_TOP_SGM_SBUS_0_SEL			68
+#define CLK_TOP_SGM_1_SEL			69
+#define CLK_TOP_SGM_SBUS_1_SEL			70
+#define CLK_TOP_XFI_PHY_0_XTAL_SEL		71
+#define CLK_TOP_XFI_PHY_1_XTAL_SEL		72
+#define CLK_TOP_SYSAXI_SEL			73
+#define CLK_TOP_SYSAPB_SEL			74
+#define CLK_TOP_ETH_REFCK_50M_SEL		75
+#define CLK_TOP_ETH_SYS_200M_SEL		76
+#define CLK_TOP_ETH_SYS_SEL			77
+#define CLK_TOP_ETH_XGMII_SEL			78
+#define CLK_TOP_BUS_TOPS_SEL			79
+#define CLK_TOP_NPU_TOPS_SEL			80
+#define CLK_TOP_DRAMC_SEL			81
+#define CLK_TOP_DRAMC_MD32_SEL			82
+#define CLK_TOP_INFRA_F26M_SEL			83
+#define CLK_TOP_PEXTP_P0_SEL			84
+#define CLK_TOP_PEXTP_P1_SEL			85
+#define CLK_TOP_PEXTP_P2_SEL			86
+#define CLK_TOP_PEXTP_P3_SEL			87
+#define CLK_TOP_DA_XTP_GLB_P0_SEL		88
+#define CLK_TOP_DA_XTP_GLB_P1_SEL		89
+#define CLK_TOP_DA_XTP_GLB_P2_SEL		90
+#define CLK_TOP_DA_XTP_GLB_P3_SEL		91
+#define CLK_TOP_CKM_SEL				92
+#define CLK_TOP_DA_SEL				93
+#define CLK_TOP_PEXTP_SEL			94
+#define CLK_TOP_TOPS_P2_26M_SEL			95
+#define CLK_TOP_MCUSYS_BACKUP_625M_SEL		96
+#define CLK_TOP_NETSYS_SYNC_250M_SEL		97
+#define CLK_TOP_MACSEC_SEL			98
+#define CLK_TOP_NETSYS_TOPS_400M_SEL		99
+#define CLK_TOP_NETSYS_PPEFB_250M_SEL		100
+#define CLK_TOP_NETSYS_WARP_SEL			101
+#define CLK_TOP_ETH_MII_SEL			102
+#define CLK_TOP_NPU_SEL				103
+#define CLK_TOP_AUD_I2S_M			104
+
+/* MCUSYS */
+
+#define CLK_MCU_BUS_DIV_SEL			0
+#define CLK_MCU_ARM_DIV_SEL			1
+
+/* INFRACFG_AO */
+
+#define CLK_INFRA_MUX_UART0_SEL			0
+#define CLK_INFRA_MUX_UART1_SEL			1
+#define CLK_INFRA_MUX_UART2_SEL			2
+#define CLK_INFRA_MUX_SPI0_SEL			3
+#define CLK_INFRA_MUX_SPI1_SEL			4
+#define CLK_INFRA_MUX_SPI2_SEL			5
+#define CLK_INFRA_PWM_SEL			6
+#define CLK_INFRA_PWM_CK1_SEL			7
+#define CLK_INFRA_PWM_CK2_SEL			8
+#define CLK_INFRA_PWM_CK3_SEL			9
+#define CLK_INFRA_PWM_CK4_SEL			10
+#define CLK_INFRA_PWM_CK5_SEL			11
+#define CLK_INFRA_PWM_CK6_SEL			12
+#define CLK_INFRA_PWM_CK7_SEL			13
+#define CLK_INFRA_PWM_CK8_SEL			14
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL	15
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL	16
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL	17
+#define CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL	18
+
+/* INFRACFG */
+
+#define CLK_INFRA_PCIE_PERI_26M_CK_P0		19
+#define CLK_INFRA_PCIE_PERI_26M_CK_P1		20
+#define CLK_INFRA_PCIE_PERI_26M_CK_P2		21
+#define CLK_INFRA_PCIE_PERI_26M_CK_P3		22
+#define CLK_INFRA_66M_GPT_BCK			23
+#define CLK_INFRA_66M_PWM_HCK			24
+#define CLK_INFRA_66M_PWM_BCK			25
+#define CLK_INFRA_66M_PWM_CK1			26
+#define CLK_INFRA_66M_PWM_CK2			27
+#define CLK_INFRA_66M_PWM_CK3			28
+#define CLK_INFRA_66M_PWM_CK4			29
+#define CLK_INFRA_66M_PWM_CK5			30
+#define CLK_INFRA_66M_PWM_CK6			31
+#define CLK_INFRA_66M_PWM_CK7			32
+#define CLK_INFRA_66M_PWM_CK8			33
+#define CLK_INFRA_133M_CQDMA_BCK		34
+#define CLK_INFRA_66M_AUD_SLV_BCK		35
+#define CLK_INFRA_AUD_26M			36
+#define CLK_INFRA_AUD_L				37
+#define CLK_INFRA_AUD_AUD			38
+#define CLK_INFRA_AUD_EG2			39
+#define CLK_INFRA_DRAMC_F26M			40
+#define CLK_INFRA_133M_DBG_ACKM			41
+#define CLK_INFRA_66M_AP_DMA_BCK		42
+#define CLK_INFRA_66M_SEJ_BCK			43
+#define CLK_INFRA_PRE_CK_SEJ_F13M		44
+#define CLK_INFRA_26M_THERM_SYSTEM		45
+#define CLK_INFRA_I2C_BCK			46
+#define CLK_INFRA_52M_UART0_CK			47
+#define CLK_INFRA_52M_UART1_CK			48
+#define CLK_INFRA_52M_UART2_CK			49
+#define CLK_INFRA_NFI				50
+#define CLK_INFRA_SPINFI			51
+#define CLK_INFRA_66M_NFI_HCK			52
+#define CLK_INFRA_104M_SPI0			53
+#define CLK_INFRA_104M_SPI1			54
+#define CLK_INFRA_104M_SPI2_BCK			55
+#define CLK_INFRA_66M_SPI0_HCK			56
+#define CLK_INFRA_66M_SPI1_HCK			57
+#define CLK_INFRA_66M_SPI2_HCK			58
+#define CLK_INFRA_66M_FLASHIF_AXI		59
+#define CLK_INFRA_RTC				60
+#define CLK_INFRA_26M_ADC_BCK			61
+#define CLK_INFRA_RC_ADC			62
+#define CLK_INFRA_MSDC400			63
+#define CLK_INFRA_MSDC2_HCK			64
+#define CLK_INFRA_133M_MSDC_0_HCK		65
+#define CLK_INFRA_66M_MSDC_0_HCK		66
+#define CLK_INFRA_133M_CPUM_BCK			67
+#define CLK_INFRA_BIST2FPC			68
+#define CLK_INFRA_I2C_X16W_MCK_CK_P1		69
+#define CLK_INFRA_I2C_X16W_PCK_CK_P1		70
+#define CLK_INFRA_133M_USB_HCK			71
+#define CLK_INFRA_133M_USB_HCK_CK_P1		72
+#define CLK_INFRA_66M_USB_HCK			73
+#define CLK_INFRA_66M_USB_HCK_CK_P1		74
+#define CLK_INFRA_USB_SYS			75
+#define CLK_INFRA_USB_SYS_CK_P1			76
+#define CLK_INFRA_USB_REF			77
+#define CLK_INFRA_USB_CK_P1			78
+#define CLK_INFRA_USB_FRMCNT			79
+#define CLK_INFRA_USB_FRMCNT_CK_P1		80
+#define CLK_INFRA_USB_PIPE			81
+#define CLK_INFRA_USB_PIPE_CK_P1		82
+#define CLK_INFRA_USB_UTMI			83
+#define CLK_INFRA_USB_UTMI_CK_P1		84
+#define CLK_INFRA_USB_XHCI			85
+#define CLK_INFRA_USB_XHCI_CK_P1		86
+#define CLK_INFRA_PCIE_GFMUX_TL_P0		87
+#define CLK_INFRA_PCIE_GFMUX_TL_P1		88
+#define CLK_INFRA_PCIE_GFMUX_TL_P2		89
+#define CLK_INFRA_PCIE_GFMUX_TL_P3		90
+#define CLK_INFRA_PCIE_PIPE_P0			91
+#define CLK_INFRA_PCIE_PIPE_P1			92
+#define CLK_INFRA_PCIE_PIPE_P2			93
+#define CLK_INFRA_PCIE_PIPE_P3			94
+#define CLK_INFRA_133M_PCIE_CK_P0		95
+#define CLK_INFRA_133M_PCIE_CK_P1		96
+#define CLK_INFRA_133M_PCIE_CK_P2		97
+#define CLK_INFRA_133M_PCIE_CK_P3		98
+
+/* ETHDMA */
+
+#define CLK_ETHDMA_XGP1_EN			0
+#define CLK_ETHDMA_XGP2_EN			1
+#define CLK_ETHDMA_XGP3_EN			2
+#define CLK_ETHDMA_FE_EN			3
+#define CLK_ETHDMA_GP2_EN			4
+#define CLK_ETHDMA_GP1_EN			5
+#define CLK_ETHDMA_GP3_EN			6
+#define CLK_ETHDMA_ESW_EN			7
+#define CLK_ETHDMA_CRYPT0_EN			8
+#define CLK_ETHDMA_NR_CLK			9
+
+/* SGMIISYS_0 */
+
+#define CLK_SGM0_TX_EN				0
+#define CLK_SGM0_RX_EN				1
+#define CLK_SGMII0_NR_CLK			2
+
+/* SGMIISYS_1 */
+
+#define CLK_SGM1_TX_EN				0
+#define CLK_SGM1_RX_EN				1
+#define CLK_SGMII1_NR_CLK			2
+
+/* ETHWARP */
+
+#define CLK_ETHWARP_WOCPU2_EN			0
+#define CLK_ETHWARP_WOCPU1_EN			1
+#define CLK_ETHWARP_WOCPU0_EN			2
+#define CLK_ETHWARP_NR_CLK			3
+
+/* XFIPLL */
+#define CLK_XFIPLL_PLL				0
+#define CLK_XFIPLL_PLL_EN			1
+
+#endif /* _DT_BINDINGS_CLK_MT7988_H */
-- 
2.43.0


From daniel at makrotopia.org  Sun Dec 17 13:49:55 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sun, 17 Dec 2023 21:49:55 +0000
Subject: [PATCH v7 3/5] dt-bindings: clock: mediatek: add clock controllers
 of MT7988
In-Reply-To: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>
References: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>
Message-ID: <07e76a544ce4392bcb88e34d5480e99bb7994618.1702849494.git.daniel@makrotopia.org>

Add various clock controllers found in the MT7988 SoC to existing
bindings (if applicable) and add files for the new ethwarp, mcusys
and xfi-pll clock controllers not previously present in any SoC.

Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
v7:
 * fix wrong path in $id of mediatek,mt7988-xfi-pll.yaml and
   mediatek,mt7988-ethwarp.yaml

v6:
 * remove invalid '_' from compatible string
 * drop minItems where uneeded due to listed clock-names
 * fix condition regarding presence of the 'pcs' subnode

v5:
 * drop use of ti,syscon-reset and hence also syscon and simple-mfd
   compatibles from mt7988-ethwarp clock controller which now got the
   clock controller provide the reset(s).

v4:
 * add subnodes for controllers acting as MFD

v3:
 * move clock bindings to clock folder
 * drop ti,syscon-reset from bindings and example
 * merge mcusys with topckgen bindings

v2:
 * dropped unused labels
 * add 'type: object' declaration for reset-controller found in new
   ethwarp controller and represented as ti,syscon-reset
 * rebase on top of
   "dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema"

 .../arm/mediatek/mediatek,infracfg.yaml       |  1 +
 .../bindings/clock/mediatek,apmixedsys.yaml   |  1 +
 .../bindings/clock/mediatek,ethsys.yaml       |  1 +
 .../clock/mediatek,mt7988-ethwarp.yaml        | 52 +++++++++++++++
 .../clock/mediatek,mt7988-xfi-pll.yaml        | 48 ++++++++++++++
 .../bindings/clock/mediatek,topckgen.yaml     |  2 +
 .../bindings/net/pcs/mediatek,sgmiisys.yaml   | 65 ++++++++++++++++---
 7 files changed, 161 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
index ea98043c6ba3d..230b5188a88db 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
@@ -30,6 +30,7 @@ properties:
               - mediatek,mt7629-infracfg
               - mediatek,mt7981-infracfg
               - mediatek,mt7986-infracfg
+              - mediatek,mt7988-infracfg
               - mediatek,mt8135-infracfg
               - mediatek,mt8167-infracfg
               - mediatek,mt8173-infracfg
diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
index 372c1d744bc27..685535846cbb7 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
@@ -22,6 +22,7 @@ properties:
           - mediatek,mt7622-apmixedsys
           - mediatek,mt7981-apmixedsys
           - mediatek,mt7986-apmixedsys
+          - mediatek,mt7988-apmixedsys
           - mediatek,mt8135-apmixedsys
           - mediatek,mt8173-apmixedsys
           - mediatek,mt8516-apmixedsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
index 94d42c8647777..f9cddacc2eae1 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
@@ -22,6 +22,7 @@ properties:
               - mediatek,mt7629-ethsys
               - mediatek,mt7981-ethsys
               - mediatek,mt7986-ethsys
+              - mediatek,mt7988-ethsys
           - const: syscon
       - items:
           - const: mediatek,mt7623-ethsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
new file mode 100644
index 0000000000000..e32a0251ff6ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7988-ethwarp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 ethwarp Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The Mediatek MT7988 ethwarp controller provides clocks and resets for the
+  Ethernet related subsystems found the MT7988 SoC.
+  The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
+
+properties:
+  compatible:
+    items:
+      - const: mediatek,mt7988-ethwarp
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+  '#reset-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - '#clock-cells'
+  - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/reset/ti-syscon.h>
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        clock-controller at 15031000 {
+            compatible = "mediatek,mt7988-ethwarp";
+            reg = <0 0x15031000 0 0x1000>;
+            #clock-cells = <1>;
+            #reset-cells = <1>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
new file mode 100644
index 0000000000000..192f1451f0afc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7988-xfi-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 XFI PLL Clock Controller
+
+maintainers:
+  - Daniel Golle <daniel at makrotopia.org>
+
+description:
+  The MediaTek XFI PLL controller provides the 156.25MHz clock for the
+  Ethernet SerDes PHY from the 40MHz top_xtal clock.
+
+properties:
+  compatible:
+    const: mediatek,mt7988-xfi-pll
+
+  reg:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - resets
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+        clock-controller at 11f40000 {
+            compatible = "mediatek,mt7988-xfi-pll";
+            reg = <0 0x11f40000 0 0x1000>;
+            resets = <&watchdog 16>;
+            #clock-cells = <1>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
index 6d087ded7437a..bdf3b55bd56fd 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
@@ -37,6 +37,8 @@ properties:
               - mediatek,mt7629-topckgen
               - mediatek,mt7981-topckgen
               - mediatek,mt7986-topckgen
+              - mediatek,mt7988-mcusys
+              - mediatek,mt7988-topckgen
               - mediatek,mt8167-topckgen
               - mediatek,mt8183-topckgen
           - const: syscon
diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
index 66a95191bd776..1bacc0eeff757 100644
--- a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
+++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
@@ -15,15 +15,22 @@ description:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - mediatek,mt7622-sgmiisys
-          - mediatek,mt7629-sgmiisys
-          - mediatek,mt7981-sgmiisys_0
-          - mediatek,mt7981-sgmiisys_1
-          - mediatek,mt7986-sgmiisys_0
-          - mediatek,mt7986-sgmiisys_1
-      - const: syscon
+    oneOf:
+      - items:
+          - enum:
+              - mediatek,mt7622-sgmiisys
+              - mediatek,mt7629-sgmiisys
+              - mediatek,mt7981-sgmiisys_0
+              - mediatek,mt7981-sgmiisys_1
+              - mediatek,mt7986-sgmiisys_0
+              - mediatek,mt7986-sgmiisys_1
+          - const: syscon
+      - items:
+          - enum:
+              - mediatek,mt7988-sgmiisys0
+              - mediatek,mt7988-sgmiisys1
+          - const: simple-mfd
+          - const: syscon
 
   reg:
     maxItems: 1
@@ -35,11 +42,51 @@ properties:
     description: Invert polarity of the SGMII data lanes
     type: boolean
 
+  pcs:
+    type: object
+    description: MediaTek LynxI HSGMII PCS
+    properties:
+      compatible:
+        const: mediatek,mt7988-sgmii
+
+      clocks:
+        maxItems: 3
+
+      clock-names:
+        items:
+          - const: sgmii_sel
+          - const: sgmii_tx
+          - const: sgmii_rx
+
+    required:
+      - compatible
+      - clocks
+      - clock-names
+
+    additionalProperties: false
+
 required:
   - compatible
   - reg
   - '#clock-cells'
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - mediatek,mt7988-sgmiisys0
+              - mediatek,mt7988-sgmiisys1
+
+    then:
+      required:
+        - pcs
+
+    else:
+      properties:
+        pcs: false
+
 additionalProperties: false
 
 examples:
-- 
2.43.0


From daniel at makrotopia.org  Sun Dec 17 13:50:07 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sun, 17 Dec 2023 21:50:07 +0000
Subject: [PATCH v7 4/5] clk: mediatek: add pcw_chg_bit control for PLLs of
 MT7988
In-Reply-To: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>
References: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>
Message-ID: <3b9c65ddb08c8bedf790aacf29871af026b6f0b7.1702849494.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Introduce pcw_chg_bit member to struct mtk_pll_data and use it instead
of the previously hardcoded PCW_CHG_MASK macro if set.
This will needed for clocks on the MT7988 SoC.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
v7: no changes
v6: no changes
v5: rename to .pcw_chg_bit, use ? operator instead of changing every
    single existing driver. The approach in v4 doesn't work as
    if .pcw_chg_reg is unset/0, pll->pcw_chg_addr will default to
    pll->base_addr + REG_CON1. Hence setting .pcw_chg_bit would be
    required for *all* drivers instead of just those setting
    .pcs_chf_reg. And that seems like an excessive change which can
    easily be avoided by using the ? operator to set the default
    at runtime (and we can easily cope with that overhead).
v4: always set .pcw_chg_shift if .pcw_chg_reg is used instead of
    having an if-expression in mtk_pll_set_rate_regs().
v3: use git --from ...
v2: no changes

 drivers/clk/mediatek/clk-pll.c | 5 +++--
 drivers/clk/mediatek/clk-pll.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index 513ab6b1b3229..ce453e1718e53 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -23,7 +23,7 @@
 #define CON0_BASE_EN		BIT(0)
 #define CON0_PWR_ON		BIT(0)
 #define CON0_ISO_EN		BIT(1)
-#define PCW_CHG_MASK		BIT(31)
+#define PCW_CHG_BIT		31
 
 #define AUDPLL_TUNER_EN		BIT(31)
 
@@ -114,7 +114,8 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll, u32 pcw,
 			pll->data->pcw_shift);
 	val |= pcw << pll->data->pcw_shift;
 	writel(val, pll->pcw_addr);
-	chg = readl(pll->pcw_chg_addr) | PCW_CHG_MASK;
+	chg = readl(pll->pcw_chg_addr) |
+	      BIT(pll->data->pcw_chg_bit ? : PCW_CHG_BIT);
 	writel(chg, pll->pcw_chg_addr);
 	if (pll->tuner_addr)
 		writel(val + 1, pll->tuner_addr);
diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
index f17278ff15d78..285c8db958b39 100644
--- a/drivers/clk/mediatek/clk-pll.h
+++ b/drivers/clk/mediatek/clk-pll.h
@@ -48,6 +48,7 @@ struct mtk_pll_data {
 	const char *parent_name;
 	u32 en_reg;
 	u8 pll_en_bit; /* Assume 0, indicates BIT(0) by default */
+	u8 pcw_chg_bit;
 };
 
 /*
-- 
2.43.0


From daniel at makrotopia.org  Sun Dec 17 13:50:15 2023
From: daniel at makrotopia.org (Daniel Golle)
Date: Sun, 17 Dec 2023 21:50:15 +0000
Subject: [PATCH v7 5/5] clk: mediatek: add drivers for MT7988 SoC
In-Reply-To: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>
References: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>
Message-ID: <c7574d808e2da1a530182f0fd790c1337c336e1b.1702849494.git.daniel@makrotopia.org>

From: Sam Shih <sam.shih at mediatek.com>

Add APMIXED, ETH, INFRACFG and TOPCKGEN clock drivers which are
typical MediaTek designs.

Also add driver for XFIPLL clock generating the 156.25MHz clock for
the XFI SerDes. It needs an undocumented software workaround and has
an unknown internal design.

Signed-off-by: Sam Shih <sam.shih at mediatek.com>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
v7: no changes
v6: no changes
v5:
 * more nicely format macro defintions
 * register reset controller for ethwarp clock controller
 * drop redundant GATE_SGMII1 which is indentical to GATE_SGMII0
   in favor of single GATE_SGMII macro

v4:
 * make use of existing GATE_MTK_FLAGS macro
 * reformat to max. 100 columns
 * cosmetics

 drivers/clk/mediatek/Kconfig               |   9 +
 drivers/clk/mediatek/Makefile              |   5 +
 drivers/clk/mediatek/clk-mt7988-apmixed.c  | 114 ++++++++
 drivers/clk/mediatek/clk-mt7988-eth.c      | 150 ++++++++++
 drivers/clk/mediatek/clk-mt7988-infracfg.c | 274 +++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-topckgen.c | 325 +++++++++++++++++++++
 drivers/clk/mediatek/clk-mt7988-xfipll.c   |  82 ++++++
 7 files changed, 959 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt7988-apmixed.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-eth.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-infracfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-topckgen.c
 create mode 100644 drivers/clk/mediatek/clk-mt7988-xfipll.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 48b42d11111cd..70a005e7e1b18 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -423,6 +423,15 @@ config COMMON_CLK_MT7986_ETHSYS
 	  This driver adds support for clocks for Ethernet and SGMII
 	  required on MediaTek MT7986 SoC.
 
+config COMMON_CLK_MT7988
+	tristate "Clock driver for MediaTek MT7988"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	select COMMON_CLK_MEDIATEK
+	default ARCH_MEDIATEK
+	help
+	  This driver supports MediaTek MT7988 basic clocks and clocks
+	  required for various periperals found on this SoC.
+
 config COMMON_CLK_MT8135
 	tristate "Clock driver for MediaTek MT8135"
 	depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index dbeaa5b41177d..eeccfa039896f 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -62,6 +62,11 @@ obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-apmixed.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-topckgen.o
 obj-$(CONFIG_COMMON_CLK_MT7986) += clk-mt7986-infracfg.o
 obj-$(CONFIG_COMMON_CLK_MT7986_ETHSYS) += clk-mt7986-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-apmixed.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-topckgen.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-infracfg.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-eth.o
+obj-$(CONFIG_COMMON_CLK_MT7988) += clk-mt7988-xfipll.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135-apmixedsys.o clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8167) += clk-mt8167-apmixedsys.o clk-mt8167.o
 obj-$(CONFIG_COMMON_CLK_MT8167_AUDSYS) += clk-mt8167-aud.o
diff --git a/drivers/clk/mediatek/clk-mt7988-apmixed.c b/drivers/clk/mediatek/clk-mt7988-apmixed.c
new file mode 100644
index 0000000000000..baf9564351a33
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-apmixed.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include "clk-pll.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+#define MT7988_PLL_FMAX (2500UL * MHZ)
+#define MT7988_PCW_CHG_BIT 2
+
+#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _rst_bar_mask, _pcwbits, _pd_reg,	\
+	    _pd_shift, _tuner_reg, _tuner_en_reg, _tuner_en_bit, _pcw_reg, _pcw_shift,		\
+	    _pcw_chg_reg)									\
+	{											\
+		.id = _id,									\
+		.name = _name,									\
+		.reg = _reg,									\
+		.pwr_reg = _pwr_reg,								\
+		.en_mask = _en_mask,								\
+		.flags = _flags,								\
+		.rst_bar_mask = BIT(_rst_bar_mask),						\
+		.fmax = MT7988_PLL_FMAX,							\
+		.pcwbits = _pcwbits,								\
+		.pd_reg = _pd_reg,								\
+		.pd_shift = _pd_shift,								\
+		.tuner_reg = _tuner_reg,							\
+		.tuner_en_reg = _tuner_en_reg,							\
+		.tuner_en_bit = _tuner_en_bit,							\
+		.pcw_reg = _pcw_reg,								\
+		.pcw_shift = _pcw_shift,							\
+		.pcw_chg_reg = _pcw_chg_reg,							\
+		.pcw_chg_bit = MT7988_PCW_CHG_BIT,						\
+		.parent_name = "clkxtal",							\
+	}
+
+static const struct mtk_pll_data plls[] = {
+	PLL(CLK_APMIXED_NETSYSPLL, "netsyspll", 0x0104, 0x0110, 0x00000001, 0, 0, 32, 0x0104, 4, 0,
+	    0, 0, 0x0108, 0, 0x0104),
+	PLL(CLK_APMIXED_MPLL, "mpll", 0x0114, 0x0120, 0xff000001, HAVE_RST_BAR, 23, 32, 0x0114, 4,
+	    0, 0, 0, 0x0118, 0, 0x0114),
+	PLL(CLK_APMIXED_MMPLL, "mmpll", 0x0124, 0x0130, 0xff000001, HAVE_RST_BAR, 23, 32, 0x0124, 4,
+	    0, 0, 0, 0x0128, 0, 0x0124),
+	PLL(CLK_APMIXED_APLL2, "apll2", 0x0134, 0x0140, 0x00000001, 0, 0, 32, 0x0134, 4, 0x0704,
+	    0x0700, 1, 0x0138, 0, 0x0134),
+	PLL(CLK_APMIXED_NET1PLL, "net1pll", 0x0144, 0x0150, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0144, 4, 0, 0, 0, 0x0148, 0, 0x0144),
+	PLL(CLK_APMIXED_NET2PLL, "net2pll", 0x0154, 0x0160, 0xff000001, (HAVE_RST_BAR | PLL_AO), 23,
+	    32, 0x0154, 4, 0, 0, 0, 0x0158, 0, 0x0154),
+	PLL(CLK_APMIXED_WEDMCUPLL, "wedmcupll", 0x0164, 0x0170, 0x00000001, 0, 0, 32, 0x0164, 4, 0,
+	    0, 0, 0x0168, 0, 0x0164),
+	PLL(CLK_APMIXED_SGMPLL, "sgmpll", 0x0174, 0x0180, 0x00000001, 0, 0, 32, 0x0174, 4, 0, 0, 0,
+	    0x0178, 0, 0x0174),
+	PLL(CLK_APMIXED_ARM_B, "arm_b", 0x0204, 0x0210, 0xff000001, (HAVE_RST_BAR | PLL_AO), 23, 32,
+	    0x0204, 4, 0, 0, 0, 0x0208, 0, 0x0204),
+	PLL(CLK_APMIXED_CCIPLL2_B, "ccipll2_b", 0x0214, 0x0220, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0214, 4, 0, 0, 0, 0x0218, 0, 0x0214),
+	PLL(CLK_APMIXED_USXGMIIPLL, "usxgmiipll", 0x0304, 0x0310, 0xff000001, HAVE_RST_BAR, 23, 32,
+	    0x0304, 4, 0, 0, 0, 0x0308, 0, 0x0304),
+	PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x0314, 0x0320, 0x00000001, 0, 0, 32, 0x0314, 4, 0, 0,
+	    0, 0x0318, 0, 0x0314),
+};
+
+static const struct of_device_id of_match_clk_mt7988_apmixed[] = {
+	{ .compatible = "mediatek,mt7988-apmixedsys" },
+	{ /* sentinel */ }
+};
+
+static int clk_mt7988_apmixed_probe(struct platform_device *pdev)
+{
+	struct clk_hw_onecell_data *clk_data;
+	struct device_node *node = pdev->dev.of_node;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(ARRAY_SIZE(plls));
+	if (!clk_data)
+		return -ENOMEM;
+
+	r = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	if (r)
+		goto free_apmixed_data;
+
+	r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
+	if (r)
+		goto unregister_plls;
+
+	return r;
+
+unregister_plls:
+	mtk_clk_unregister_plls(plls, ARRAY_SIZE(plls), clk_data);
+free_apmixed_data:
+	mtk_free_clk_data(clk_data);
+	return r;
+}
+
+static struct platform_driver clk_mt7988_apmixed_drv = {
+	.probe = clk_mt7988_apmixed_probe,
+	.driver = {
+		.name = "clk-mt7988-apmixed",
+		.of_match_table = of_match_clk_mt7988_apmixed,
+	},
+};
+builtin_platform_driver(clk_mt7988_apmixed_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-eth.c b/drivers/clk/mediatek/clk-mt7988-eth.c
new file mode 100644
index 0000000000000..adf4a9d39b38f
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-eth.c
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "reset.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+#include <dt-bindings/reset/mediatek,mt7988-resets.h>
+
+static const struct mtk_gate_regs ethdma_cg_regs = {
+	.set_ofs = 0x30,
+	.clr_ofs = 0x30,
+	.sta_ofs = 0x30,
+};
+
+#define GATE_ETHDMA(_id, _name, _parent, _shift)		\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &ethdma_cg_regs,			\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_gate ethdma_clks[] = {
+	GATE_ETHDMA(CLK_ETHDMA_XGP1_EN, "ethdma_xgp1_en", "top_xtal", 0),
+	GATE_ETHDMA(CLK_ETHDMA_XGP2_EN, "ethdma_xgp2_en", "top_xtal", 1),
+	GATE_ETHDMA(CLK_ETHDMA_XGP3_EN, "ethdma_xgp3_en", "top_xtal", 2),
+	GATE_ETHDMA(CLK_ETHDMA_FE_EN, "ethdma_fe_en", "netsys_2x_sel", 6),
+	GATE_ETHDMA(CLK_ETHDMA_GP2_EN, "ethdma_gp2_en", "top_xtal", 7),
+	GATE_ETHDMA(CLK_ETHDMA_GP1_EN, "ethdma_gp1_en", "top_xtal", 8),
+	GATE_ETHDMA(CLK_ETHDMA_GP3_EN, "ethdma_gp3_en", "top_xtal", 10),
+	GATE_ETHDMA(CLK_ETHDMA_ESW_EN, "ethdma_esw_en", "netsys_gsw_sel", 16),
+	GATE_ETHDMA(CLK_ETHDMA_CRYPT0_EN, "ethdma_crypt0_en", "eip197_sel", 29),
+};
+
+static const struct mtk_clk_desc ethdma_desc = {
+	.clks = ethdma_clks,
+	.num_clks = ARRAY_SIZE(ethdma_clks),
+};
+
+static const struct mtk_gate_regs sgmii_cg_regs = {
+	.set_ofs = 0xe4,
+	.clr_ofs = 0xe4,
+	.sta_ofs = 0xe4,
+};
+
+#define GATE_SGMII(_id, _name, _parent, _shift)			\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &sgmii_cg_regs,				\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_gate sgmii0_clks[] = {
+	GATE_SGMII(CLK_SGM0_TX_EN, "sgm0_tx_en", "top_xtal", 2),
+	GATE_SGMII(CLK_SGM0_RX_EN, "sgm0_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii0_desc = {
+	.clks = sgmii0_clks,
+	.num_clks = ARRAY_SIZE(sgmii0_clks),
+};
+
+static const struct mtk_gate sgmii1_clks[] = {
+	GATE_SGMII(CLK_SGM1_TX_EN, "sgm1_tx_en", "top_xtal", 2),
+	GATE_SGMII(CLK_SGM1_RX_EN, "sgm1_rx_en", "top_xtal", 3),
+};
+
+static const struct mtk_clk_desc sgmii1_desc = {
+	.clks = sgmii1_clks,
+	.num_clks = ARRAY_SIZE(sgmii1_clks),
+};
+
+static const struct mtk_gate_regs ethwarp_cg_regs = {
+	.set_ofs = 0x14,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x14,
+};
+
+#define GATE_ETHWARP(_id, _name, _parent, _shift)		\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &ethwarp_cg_regs,			\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_gate ethwarp_clks[] = {
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU2_EN, "ethwarp_wocpu2_en", "netsys_mcu_sel", 13),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU1_EN, "ethwarp_wocpu1_en", "netsys_mcu_sel", 14),
+	GATE_ETHWARP(CLK_ETHWARP_WOCPU0_EN, "ethwarp_wocpu0_en", "netsys_mcu_sel", 15),
+};
+
+static u16 ethwarp_rst_ofs[] = { 0x8 };
+
+static u16 ethwarp_idx_map[] = {
+	[MT7988_ETHWARP_RST_SWITCH] = 9,
+};
+
+static const struct mtk_clk_rst_desc ethwarp_rst_desc = {
+	.version = MTK_RST_SIMPLE,
+	.rst_bank_ofs = ethwarp_rst_ofs,
+	.rst_bank_nr = ARRAY_SIZE(ethwarp_rst_ofs),
+	.rst_idx_map = ethwarp_idx_map,
+	.rst_idx_map_nr = ARRAY_SIZE(ethwarp_idx_map),
+};
+
+static const struct mtk_clk_desc ethwarp_desc = {
+	.clks = ethwarp_clks,
+	.num_clks = ARRAY_SIZE(ethwarp_clks),
+	.rst_desc = &ethwarp_rst_desc,
+};
+
+static const struct of_device_id of_match_clk_mt7988_eth[] = {
+	{ .compatible = "mediatek,mt7988-ethsys", .data = &ethdma_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys0", .data = &sgmii0_desc },
+	{ .compatible = "mediatek,mt7988-sgmiisys1", .data = &sgmii1_desc },
+	{ .compatible = "mediatek,mt7988-ethwarp", .data = &ethwarp_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_eth);
+
+static struct platform_driver clk_mt7988_eth_drv = {
+	.driver = {
+		.name = "clk-mt7988-eth",
+		.of_match_table = of_match_clk_mt7988_eth,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_eth_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 Ethernet clocks driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-infracfg.c b/drivers/clk/mediatek/clk-mt7988-infracfg.c
new file mode 100644
index 0000000000000..b7b4f7626d3d6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-infracfg.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const char *const infra_mux_uart0_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_uart1_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_uart2_parents[] __initconst = { "csw_infra_f26m_sel",
+								   "uart_sel" };
+
+static const char *const infra_mux_spi0_parents[] __initconst = { "i2c_sel", "spi_sel" };
+
+static const char *const infra_mux_spi1_parents[] __initconst = { "i2c_sel", "spim_mst_sel" };
+
+static const char *const infra_pwm_bck_parents[] __initconst = { "top_rtc_32p7k",
+								 "csw_infra_f26m_sel", "sysaxi_sel",
+								 "pwm_sel" };
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p0_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p1_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p1_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p2_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p2_sel"
+};
+
+static const char *const infra_pcie_gfmux_tl_ck_o_p3_parents[] __initconst = {
+	"top_rtc_32p7k", "csw_infra_f26m_sel", "csw_infra_f26m_sel", "pextp_tl_p3_sel"
+};
+
+static const struct mtk_mux infra_muxes[] = {
+	/* MODULE_CLK_SEL_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART0_SEL, "infra_mux_uart0_sel",
+			     infra_mux_uart0_parents, 0x0018, 0x0010, 0x0014, 0, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART1_SEL, "infra_mux_uart1_sel",
+			     infra_mux_uart1_parents, 0x0018, 0x0010, 0x0014, 1, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART2_SEL, "infra_mux_uart2_sel",
+			     infra_mux_uart2_parents, 0x0018, 0x0010, 0x0014, 2, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI0_SEL, "infra_mux_spi0_sel", infra_mux_spi0_parents,
+			     0x0018, 0x0010, 0x0014, 4, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI1_SEL, "infra_mux_spi1_sel", infra_mux_spi1_parents,
+			     0x0018, 0x0010, 0x0014, 5, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI2_SEL, "infra_mux_spi2_sel", infra_mux_spi0_parents,
+			     0x0018, 0x0010, 0x0014, 6, 1, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_SEL, "infra_pwm_sel", infra_pwm_bck_parents, 0x0018,
+			     0x0010, 0x0014, 14, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK1_SEL, "infra_pwm_ck1_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 16, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK2_SEL, "infra_pwm_ck2_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 18, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK3_SEL, "infra_pwm_ck3_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 20, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK4_SEL, "infra_pwm_ck4_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 22, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK5_SEL, "infra_pwm_ck5_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 24, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK6_SEL, "infra_pwm_ck6_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 26, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK7_SEL, "infra_pwm_ck7_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 28, 2, -1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK8_SEL, "infra_pwm_ck8_sel", infra_pwm_bck_parents,
+			     0x0018, 0x0010, 0x0014, 30, 2, -1, -1, -1),
+	/* MODULE_CLK_SEL_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL, "infra_pcie_gfmux_tl_o_p0_sel",
+			     infra_pcie_gfmux_tl_ck_o_p0_parents, 0x0028, 0x0020, 0x0024, 0, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL, "infra_pcie_gfmux_tl_o_p1_sel",
+			     infra_pcie_gfmux_tl_ck_o_p1_parents, 0x0028, 0x0020, 0x0024, 2, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL, "infra_pcie_gfmux_tl_o_p2_sel",
+			     infra_pcie_gfmux_tl_ck_o_p2_parents, 0x0028, 0x0020, 0x0024, 4, 2, -1,
+			     -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL, "infra_pcie_gfmux_tl_o_p3_sel",
+			     infra_pcie_gfmux_tl_ck_o_p3_parents, 0x0028, 0x0020, 0x0024, 6, 2, -1,
+			     -1, -1),
+};
+
+static const struct mtk_gate_regs infra0_cg_regs = {
+	.set_ofs = 0x10,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x18,
+};
+
+static const struct mtk_gate_regs infra1_cg_regs = {
+	.set_ofs = 0x40,
+	.clr_ofs = 0x44,
+	.sta_ofs = 0x48,
+};
+
+static const struct mtk_gate_regs infra2_cg_regs = {
+	.set_ofs = 0x50,
+	.clr_ofs = 0x54,
+	.sta_ofs = 0x58,
+};
+
+static const struct mtk_gate_regs infra3_cg_regs = {
+	.set_ofs = 0x60,
+	.clr_ofs = 0x64,
+	.sta_ofs = 0x68,
+};
+
+#define GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra0_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra1_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra2_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, _flags)                                 \
+	GATE_MTK_FLAGS(_id, _name, _parent, &infra3_cg_regs, _shift, &mtk_clk_gate_ops_setclr, \
+		       _flags)
+
+#define GATE_INFRA0(_id, _name, _parent, _shift) GATE_INFRA0_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA1(_id, _name, _parent, _shift) GATE_INFRA1_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA2(_id, _name, _parent, _shift) GATE_INFRA2_FLAGS(_id, _name, _parent, _shift, 0)
+
+#define GATE_INFRA3(_id, _name, _parent, _shift) GATE_INFRA3_FLAGS(_id, _name, _parent, _shift, 0)
+
+static const struct mtk_gate infra_clks[] = {
+	/* INFRA0 */
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P0, "infra_pcie_peri_ck_26m_ck_p0",
+		    "csw_infra_f26m_sel", 7),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P1, "infra_pcie_peri_ck_26m_ck_p1",
+		    "csw_infra_f26m_sel", 8),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P2, "infra_pcie_peri_ck_26m_ck_p2",
+		    "csw_infra_f26m_sel", 9),
+	GATE_INFRA0(CLK_INFRA_PCIE_PERI_26M_CK_P3, "infra_pcie_peri_ck_26m_ck_p3",
+		    "csw_infra_f26m_sel", 10),
+	/* INFRA1 */
+	GATE_INFRA1(CLK_INFRA_66M_GPT_BCK, "infra_hf_66m_gpt_bck", "sysaxi_sel", 0),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_HCK, "infra_hf_66m_pwm_hck", "sysaxi_sel", 1),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_BCK, "infra_hf_66m_pwm_bck", "infra_pwm_sel", 2),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK1, "infra_hf_66m_pwm_ck1", "infra_pwm_ck1_sel", 3),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK2, "infra_hf_66m_pwm_ck2", "infra_pwm_ck2_sel", 4),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK3, "infra_hf_66m_pwm_ck3", "infra_pwm_ck3_sel", 5),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK4, "infra_hf_66m_pwm_ck4", "infra_pwm_ck4_sel", 6),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK5, "infra_hf_66m_pwm_ck5", "infra_pwm_ck5_sel", 7),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK6, "infra_hf_66m_pwm_ck6", "infra_pwm_ck6_sel", 8),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK7, "infra_hf_66m_pwm_ck7", "infra_pwm_ck7_sel", 9),
+	GATE_INFRA1(CLK_INFRA_66M_PWM_CK8, "infra_hf_66m_pwm_ck8", "infra_pwm_ck8_sel", 10),
+	GATE_INFRA1(CLK_INFRA_133M_CQDMA_BCK, "infra_hf_133m_cqdma_bck", "sysaxi_sel", 12),
+	GATE_INFRA1(CLK_INFRA_66M_AUD_SLV_BCK, "infra_66m_aud_slv_bck", "sysaxi_sel", 13),
+	GATE_INFRA1(CLK_INFRA_AUD_26M, "infra_f_faud_26m", "csw_infra_f26m_sel", 14),
+	GATE_INFRA1(CLK_INFRA_AUD_L, "infra_f_faud_l", "aud_l_sel", 15),
+	GATE_INFRA1(CLK_INFRA_AUD_AUD, "infra_f_aud_aud", "a1sys_sel", 16),
+	GATE_INFRA1(CLK_INFRA_AUD_EG2, "infra_f_faud_eg2", "a_tuner_sel", 18),
+	GATE_INFRA1_FLAGS(CLK_INFRA_DRAMC_F26M, "infra_dramc_f26m", "csw_infra_f26m_sel", 19,
+			  CLK_IS_CRITICAL),
+	/* JTAG */
+	GATE_INFRA1_FLAGS(CLK_INFRA_133M_DBG_ACKM, "infra_hf_133m_dbg_ackm", "sysaxi_sel", 20,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA1(CLK_INFRA_66M_AP_DMA_BCK, "infra_66m_ap_dma_bck", "sysaxi_sel", 21),
+	GATE_INFRA1(CLK_INFRA_66M_SEJ_BCK, "infra_hf_66m_sej_bck", "sysaxi_sel", 29),
+	GATE_INFRA1(CLK_INFRA_PRE_CK_SEJ_F13M, "infra_pre_ck_sej_f13m", "csw_infra_f26m_sel", 30),
+	/* INFRA2 */
+	GATE_INFRA2(CLK_INFRA_26M_THERM_SYSTEM, "infra_hf_26m_therm_system", "csw_infra_f26m_sel",
+		    0),
+	GATE_INFRA2(CLK_INFRA_I2C_BCK, "infra_i2c_bck", "i2c_sel", 1),
+	GATE_INFRA2(CLK_INFRA_52M_UART0_CK, "infra_f_52m_uart0", "infra_mux_uart0_sel", 3),
+	GATE_INFRA2(CLK_INFRA_52M_UART1_CK, "infra_f_52m_uart1", "infra_mux_uart1_sel", 4),
+	GATE_INFRA2(CLK_INFRA_52M_UART2_CK, "infra_f_52m_uart2", "infra_mux_uart2_sel", 5),
+	GATE_INFRA2(CLK_INFRA_NFI, "infra_f_fnfi", "nfi1x_sel", 9),
+	GATE_INFRA2(CLK_INFRA_SPINFI, "infra_f_fspinfi", "spinfi_sel", 10),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_NFI_HCK, "infra_hf_66m_nfi_hck", "sysaxi_sel", 11,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2_FLAGS(CLK_INFRA_104M_SPI0, "infra_hf_104m_spi0", "infra_mux_spi0_sel", 12,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_104M_SPI1, "infra_hf_104m_spi1", "infra_mux_spi1_sel", 13),
+	GATE_INFRA2(CLK_INFRA_104M_SPI2_BCK, "infra_hf_104m_spi2_bck", "infra_mux_spi2_sel", 14),
+	GATE_INFRA2_FLAGS(CLK_INFRA_66M_SPI0_HCK, "infra_hf_66m_spi0_hck", "sysaxi_sel", 15,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_66M_SPI1_HCK, "infra_hf_66m_spi1_hck", "sysaxi_sel", 16),
+	GATE_INFRA2(CLK_INFRA_66M_SPI2_HCK, "infra_hf_66m_spi2_hck", "sysaxi_sel", 17),
+	GATE_INFRA2(CLK_INFRA_66M_FLASHIF_AXI, "infra_hf_66m_flashif_axi", "sysaxi_sel", 18),
+	GATE_INFRA2_FLAGS(CLK_INFRA_RTC, "infra_f_frtc", "top_rtc_32k", 19, CLK_IS_CRITICAL),
+	GATE_INFRA2(CLK_INFRA_26M_ADC_BCK, "infra_f_26m_adc_bck", "csw_infra_f26m_sel", 20),
+	GATE_INFRA2(CLK_INFRA_RC_ADC, "infra_f_frc_adc", "infra_f_26m_adc_bck", 21),
+	GATE_INFRA2(CLK_INFRA_MSDC400, "infra_f_fmsdc400", "emmc_400m_sel", 22),
+	GATE_INFRA2(CLK_INFRA_MSDC2_HCK, "infra_f_fmsdc2_hck", "emmc_250m_sel", 23),
+	GATE_INFRA2(CLK_INFRA_133M_MSDC_0_HCK, "infra_hf_133m_msdc_0_hck", "sysaxi_sel", 24),
+	GATE_INFRA2(CLK_INFRA_66M_MSDC_0_HCK, "infra_66m_msdc_0_hck", "sysaxi_sel", 25),
+	GATE_INFRA2(CLK_INFRA_133M_CPUM_BCK, "infra_hf_133m_cpum_bck", "sysaxi_sel", 26),
+	GATE_INFRA2(CLK_INFRA_BIST2FPC, "infra_hf_fbist2fpc", "nfi1x_sel", 27),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_MCK_CK_P1, "infra_hf_i2c_x16w_mck_ck_p1", "sysaxi_sel", 29),
+	GATE_INFRA2(CLK_INFRA_I2C_X16W_PCK_CK_P1, "infra_hf_i2c_x16w_pck_ck_p1", "sysaxi_sel", 31),
+	/* INFRA3 */
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK, "infra_133m_usb_hck", "sysaxi_sel", 0),
+	GATE_INFRA3(CLK_INFRA_133M_USB_HCK_CK_P1, "infra_133m_usb_hck_ck_p1", "sysaxi_sel", 1),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK, "infra_66m_usb_hck", "sysaxi_sel", 2),
+	GATE_INFRA3(CLK_INFRA_66M_USB_HCK_CK_P1, "infra_66m_usb_hck_ck_p1", "sysaxi_sel", 3),
+	GATE_INFRA3(CLK_INFRA_USB_SYS, "infra_usb_sys", "usb_sys_sel", 4),
+	GATE_INFRA3(CLK_INFRA_USB_SYS_CK_P1, "infra_usb_sys_ck_p1", "usb_sys_p1_sel", 5),
+	GATE_INFRA3(CLK_INFRA_USB_REF, "infra_usb_ref", "top_xtal", 6),
+	GATE_INFRA3(CLK_INFRA_USB_CK_P1, "infra_usb_ck_p1", "top_xtal", 7),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT, "infra_usb_frmcnt", "usb_frmcnt_sel", 8,
+			  CLK_IS_CRITICAL),
+	GATE_INFRA3_FLAGS(CLK_INFRA_USB_FRMCNT_CK_P1, "infra_usb_frmcnt_ck_p1", "usb_frmcnt_p1_sel",
+			  9, CLK_IS_CRITICAL),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE, "infra_usb_pipe", "sspxtp_sel", 10),
+	GATE_INFRA3(CLK_INFRA_USB_PIPE_CK_P1, "infra_usb_pipe_ck_p1", "usb_phy_sel", 11),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI, "infra_usb_utmi", "top_xtal", 12),
+	GATE_INFRA3(CLK_INFRA_USB_UTMI_CK_P1, "infra_usb_utmi_ck_p1", "top_xtal", 13),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI, "infra_usb_xhci", "usb_xhci_sel", 14),
+	GATE_INFRA3(CLK_INFRA_USB_XHCI_CK_P1, "infra_usb_xhci_ck_p1", "usb_xhci_p1_sel", 15),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P0, "infra_pcie_gfmux_tl_ck_p0",
+		    "infra_pcie_gfmux_tl_o_p0_sel", 20),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P1, "infra_pcie_gfmux_tl_ck_p1",
+		    "infra_pcie_gfmux_tl_o_p1_sel", 21),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P2, "infra_pcie_gfmux_tl_ck_p2",
+		    "infra_pcie_gfmux_tl_o_p2_sel", 22),
+	GATE_INFRA3(CLK_INFRA_PCIE_GFMUX_TL_P3, "infra_pcie_gfmux_tl_ck_p3",
+		    "infra_pcie_gfmux_tl_o_p3_sel", 23),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P0, "infra_pcie_pipe_ck_p0", "top_xtal", 24),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P1, "infra_pcie_pipe_ck_p1", "top_xtal", 25),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P2, "infra_pcie_pipe_ck_p2", "top_xtal", 26),
+	GATE_INFRA3(CLK_INFRA_PCIE_PIPE_P3, "infra_pcie_pipe_ck_p3", "top_xtal", 27),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P0, "infra_133m_pcie_ck_p0", "sysaxi_sel", 28),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P1, "infra_133m_pcie_ck_p1", "sysaxi_sel", 29),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P2, "infra_133m_pcie_ck_p2", "sysaxi_sel", 30),
+	GATE_INFRA3(CLK_INFRA_133M_PCIE_CK_P3, "infra_133m_pcie_ck_p3", "sysaxi_sel", 31),
+};
+
+static const struct mtk_clk_desc infra_desc = {
+	.clks = infra_clks,
+	.num_clks = ARRAY_SIZE(infra_clks),
+	.mux_clks = infra_muxes,
+	.num_mux_clks = ARRAY_SIZE(infra_muxes),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const struct of_device_id of_match_clk_mt7988_infracfg[] = {
+	{ .compatible = "mediatek,mt7988-infracfg", .data = &infra_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_infracfg);
+
+static struct platform_driver clk_mt7988_infracfg_drv = {
+	.driver = {
+		.name = "clk-mt7988-infracfg",
+		.of_match_table = of_match_clk_mt7988_infracfg,
+	},
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_infracfg_drv);
diff --git a/drivers/clk/mediatek/clk-mt7988-topckgen.c b/drivers/clk/mediatek/clk-mt7988-topckgen.c
new file mode 100644
index 0000000000000..760f8e0d2f26a
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-topckgen.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Sam Shih <sam.shih at mediatek.com>
+ * Author: Xiufeng Li <Xiufeng.Li at mediatek.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include "clk-mux.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+static DEFINE_SPINLOCK(mt7988_clk_lock);
+
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+	FIXED_CLK(CLK_TOP_XTAL, "top_xtal", "clkxtal", 40000000),
+};
+
+static const struct mtk_fixed_factor top_divs[] = {
+	FACTOR(CLK_TOP_XTAL_D2, "top_xtal_d2", "top_xtal", 1, 2),
+	FACTOR(CLK_TOP_RTC_32K, "top_rtc_32k", "top_xtal", 1, 1250),
+	FACTOR(CLK_TOP_RTC_32P7K, "top_rtc_32p7k", "top_xtal", 1, 1220),
+	FACTOR(CLK_TOP_MPLL_D2, "mpll_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D3_D2, "mpll_d3_d2", "mpll", 1, 2),
+	FACTOR(CLK_TOP_MPLL_D4, "mpll_d4", "mpll", 1, 4),
+	FACTOR(CLK_TOP_MPLL_D8, "mpll_d8", "mpll", 1, 8),
+	FACTOR(CLK_TOP_MPLL_D8_D2, "mpll_d8_d2", "mpll", 1, 16),
+	FACTOR(CLK_TOP_MMPLL_D2, "mmpll_d2", "mmpll", 1, 2),
+	FACTOR(CLK_TOP_MMPLL_D3_D5, "mmpll_d3_d5", "mmpll", 1, 15),
+	FACTOR(CLK_TOP_MMPLL_D4, "mmpll_d4", "mmpll", 1, 4),
+	FACTOR(CLK_TOP_MMPLL_D6_D2, "mmpll_d6_d2", "mmpll", 1, 12),
+	FACTOR(CLK_TOP_MMPLL_D8, "mmpll_d8", "mmpll", 1, 8),
+	FACTOR(CLK_TOP_APLL2_D4, "apll2_d4", "apll2", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D4, "net1pll_d4", "net1pll", 1, 4),
+	FACTOR(CLK_TOP_NET1PLL_D5, "net1pll_d5", "net1pll", 1, 5),
+	FACTOR(CLK_TOP_NET1PLL_D5_D2, "net1pll_d5_d2", "net1pll", 1, 10),
+	FACTOR(CLK_TOP_NET1PLL_D5_D4, "net1pll_d5_d4", "net1pll", 1, 20),
+	FACTOR(CLK_TOP_NET1PLL_D8, "net1pll_d8", "net1pll", 1, 8),
+	FACTOR(CLK_TOP_NET1PLL_D8_D2, "net1pll_d8_d2", "net1pll", 1, 16),
+	FACTOR(CLK_TOP_NET1PLL_D8_D4, "net1pll_d8_d4", "net1pll", 1, 32),
+	FACTOR(CLK_TOP_NET1PLL_D8_D8, "net1pll_d8_d8", "net1pll", 1, 64),
+	FACTOR(CLK_TOP_NET1PLL_D8_D16, "net1pll_d8_d16", "net1pll", 1, 128),
+	FACTOR(CLK_TOP_NET2PLL_D2, "net2pll_d2", "net2pll", 1, 2),
+	FACTOR(CLK_TOP_NET2PLL_D4, "net2pll_d4", "net2pll", 1, 4),
+	FACTOR(CLK_TOP_NET2PLL_D4_D4, "net2pll_d4_d4", "net2pll", 1, 16),
+	FACTOR(CLK_TOP_NET2PLL_D4_D8, "net2pll_d4_d8", "net2pll", 1, 32),
+	FACTOR(CLK_TOP_NET2PLL_D6, "net2pll_d6", "net2pll", 1, 6),
+	FACTOR(CLK_TOP_NET2PLL_D8, "net2pll_d8", "net2pll", 1, 8),
+};
+
+static const char *const netsys_parents[] = { "top_xtal", "net2pll_d2", "mmpll_d2" };
+static const char *const netsys_500m_parents[] = { "top_xtal", "net1pll_d5", "net1pll_d5_d2" };
+static const char *const netsys_2x_parents[] = { "top_xtal", "net2pll", "mmpll" };
+static const char *const netsys_gsw_parents[] = { "top_xtal", "net1pll_d4", "net1pll_d5" };
+static const char *const eth_gmii_parents[] = { "top_xtal", "net1pll_d5_d4" };
+static const char *const netsys_mcu_parents[] = { "top_xtal",	"net2pll",    "mmpll",
+						  "net1pll_d4", "net1pll_d5", "mpll" };
+static const char *const eip197_parents[] = { "top_xtal", "netsyspll",	"net2pll",
+					      "mmpll",	  "net1pll_d4", "net1pll_d5" };
+static const char *const axi_infra_parents[] = { "top_xtal", "net1pll_d8_d2" };
+static const char *const uart_parents[] = { "top_xtal", "mpll_d8", "mpll_d8_d2" };
+static const char *const emmc_250m_parents[] = { "top_xtal", "net1pll_d5_d2", "mmpll_d4" };
+static const char *const emmc_400m_parents[] = { "top_xtal", "msdcpll",	 "mmpll_d2",
+						 "mpll_d2",  "mmpll_d4", "net1pll_d8_d2" };
+static const char *const spi_parents[] = { "top_xtal",	    "mpll_d2",	    "mmpll_d4",
+					   "net1pll_d8_d2", "net2pll_d6",   "net1pll_d5_d4",
+					   "mpll_d4",	    "net1pll_d8_d4" };
+static const char *const nfi1x_parents[] = { "top_xtal", "mmpll_d4", "net1pll_d8_d2", "net2pll_d6",
+					     "mpll_d4",	 "mmpll_d8", "net1pll_d8_d4", "mpll_d8" };
+static const char *const spinfi_parents[] = { "top_xtal_d2", "top_xtal", "net1pll_d5_d4",
+					      "mpll_d4",     "mmpll_d8", "net1pll_d8_d4",
+					      "mmpll_d6_d2", "mpll_d8" };
+static const char *const pwm_parents[] = { "top_xtal", "net1pll_d8_d2", "net1pll_d5_d4",
+					   "mpll_d4",  "mpll_d8_d2",	"top_rtc_32k" };
+static const char *const i2c_parents[] = { "top_xtal", "net1pll_d5_d4", "mpll_d4",
+					   "net1pll_d8_d4" };
+static const char *const pcie_mbist_250m_parents[] = { "top_xtal", "net1pll_d5_d2" };
+static const char *const pextp_tl_ck_parents[] = { "top_xtal", "net2pll_d6", "mmpll_d8",
+						   "mpll_d8_d2", "top_rtc_32k" };
+static const char *const usb_frmcnt_parents[] = { "top_xtal", "mmpll_d3_d5" };
+static const char *const aud_parents[] = { "top_xtal", "apll2" };
+static const char *const a1sys_parents[] = { "top_xtal", "apll2_d4" };
+static const char *const aud_l_parents[] = { "top_xtal", "apll2", "mpll_d8_d2" };
+static const char *const sspxtp_parents[] = { "top_xtal_d2", "mpll_d8_d2" };
+static const char *const usxgmii_sbus_0_parents[] = { "top_xtal", "net1pll_d8_d4" };
+static const char *const sgm_0_parents[] = { "top_xtal", "sgmpll" };
+static const char *const sysapb_parents[] = { "top_xtal", "mpll_d3_d2" };
+static const char *const eth_refck_50m_parents[] = { "top_xtal", "net2pll_d4_d4" };
+static const char *const eth_sys_200m_parents[] = { "top_xtal", "net2pll_d4" };
+static const char *const eth_xgmii_parents[] = { "top_xtal_d2", "net1pll_d8_d8", "net1pll_d8_d16" };
+static const char *const bus_tops_parents[] = { "top_xtal", "net1pll_d5", "net2pll_d2" };
+static const char *const npu_tops_parents[] = { "top_xtal", "net2pll" };
+static const char *const dramc_md32_parents[] = { "top_xtal", "mpll_d2", "wedmcupll" };
+static const char *const da_xtp_glb_p0_parents[] = { "top_xtal", "net2pll_d8" };
+static const char *const mcusys_backup_625m_parents[] = { "top_xtal", "net1pll_d4" };
+static const char *const macsec_parents[] = { "top_xtal", "sgmpll", "net1pll_d8" };
+static const char *const netsys_tops_400m_parents[] = { "top_xtal", "net2pll_d2" };
+static const char *const eth_mii_parents[] = { "top_xtal_d2", "net2pll_d4_d8" };
+
+static const struct mtk_mux top_muxes[] = {
+	/* CLK_CFG_0 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SEL, "netsys_sel", netsys_parents, 0x000, 0x004, 0x008,
+			     0, 2, 7, 0x1c0, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_500M_SEL, "netsys_500m_sel", netsys_500m_parents, 0x000,
+			     0x004, 0x008, 8, 2, 15, 0x1C0, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_2X_SEL, "netsys_2x_sel", netsys_2x_parents, 0x000,
+			     0x004, 0x008, 16, 2, 23, 0x1C0, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_GSW_SEL, "netsys_gsw_sel", netsys_gsw_parents, 0x000,
+			     0x004, 0x008, 24, 2, 31, 0x1C0, 3),
+	/* CLK_CFG_1 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_GMII_SEL, "eth_gmii_sel", eth_gmii_parents, 0x010, 0x014,
+			     0x018, 0, 1, 7, 0x1C0, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_MCU_SEL, "netsys_mcu_sel", netsys_mcu_parents, 0x010,
+			     0x014, 0x018, 8, 3, 15, 0x1C0, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PAO_2X_SEL, "netsys_pao_2x_sel", netsys_mcu_parents,
+			     0x010, 0x014, 0x018, 16, 3, 23, 0x1C0, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EIP197_SEL, "eip197_sel", eip197_parents, 0x010, 0x014, 0x018,
+			     24, 3, 31, 0x1c0, 7),
+	/* CLK_CFG_2 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_AXI_INFRA_SEL, "axi_infra_sel", axi_infra_parents, 0x020,
+				   0x024, 0x028, 0, 1, 7, 0x1C0, 8, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_UART_SEL, "uart_sel", uart_parents, 0x020, 0x024, 0x028, 8, 2,
+			     15, 0x1c0, 9),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_250M_SEL, "emmc_250m_sel", emmc_250m_parents, 0x020,
+			     0x024, 0x028, 16, 2, 23, 0x1C0, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_EMMC_400M_SEL, "emmc_400m_sel", emmc_400m_parents, 0x020,
+			     0x024, 0x028, 24, 3, 31, 0x1C0, 11),
+	/* CLK_CFG_3 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPI_SEL, "spi_sel", spi_parents, 0x030, 0x034, 0x038, 0, 3, 7,
+			     0x1c0, 12),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPIM_MST_SEL, "spim_mst_sel", spi_parents, 0x030, 0x034, 0x038,
+			     8, 3, 15, 0x1c0, 13),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NFI1X_SEL, "nfi1x_sel", nfi1x_parents, 0x030, 0x034, 0x038, 16,
+			     3, 23, 0x1c0, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SPINFI_SEL, "spinfi_sel", spinfi_parents, 0x030, 0x034, 0x038,
+			     24, 3, 31, 0x1c0, 15),
+	/* CLK_CFG_4 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PWM_SEL, "pwm_sel", pwm_parents, 0x040, 0x044, 0x048, 0, 3, 7,
+			     0x1c0, 16),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_I2C_SEL, "i2c_sel", i2c_parents, 0x040, 0x044, 0x048, 8, 2, 15,
+			     0x1c0, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PCIE_MBIST_250M_SEL, "pcie_mbist_250m_sel",
+			     pcie_mbist_250m_parents, 0x040, 0x044, 0x048, 16, 1, 23, 0x1C0, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_SEL, "pextp_tl_sel", pextp_tl_ck_parents, 0x040,
+			     0x044, 0x048, 24, 3, 31, 0x1C0, 19),
+	/* CLK_CFG_5 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P1_SEL, "pextp_tl_p1_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 0, 3, 7, 0x1C0, 20),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P2_SEL, "pextp_tl_p2_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 8, 3, 15, 0x1C0, 21),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_TL_P3_SEL, "pextp_tl_p3_sel", pextp_tl_ck_parents, 0x050,
+			     0x054, 0x058, 16, 3, 23, 0x1C0, 22),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_SEL, "usb_sys_sel", eth_gmii_parents, 0x050, 0x054,
+			     0x058, 24, 1, 31, 0x1C0, 23),
+	/* CLK_CFG_6 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_SYS_P1_SEL, "usb_sys_p1_sel", eth_gmii_parents, 0x060,
+			     0x064, 0x068, 0, 1, 7, 0x1C0, 24),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_SEL, "usb_xhci_sel", eth_gmii_parents, 0x060, 0x064,
+			     0x068, 8, 1, 15, 0x1C0, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_XHCI_P1_SEL, "usb_xhci_p1_sel", eth_gmii_parents, 0x060,
+			     0x064, 0x068, 16, 1, 23, 0x1C0, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_SEL, "usb_frmcnt_sel", usb_frmcnt_parents, 0x060,
+			     0x064, 0x068, 24, 1, 31, 0x1C0, 27),
+	/* CLK_CFG_7 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_FRMCNT_P1_SEL, "usb_frmcnt_p1_sel", usb_frmcnt_parents,
+			     0x070, 0x074, 0x078, 0, 1, 7, 0x1C0, 28),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_SEL, "aud_sel", aud_parents, 0x070, 0x074, 0x078, 8, 1, 15,
+			     0x1c0, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A1SYS_SEL, "a1sys_sel", a1sys_parents, 0x070, 0x074, 0x078, 16,
+			     1, 23, 0x1c0, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_AUD_L_SEL, "aud_l_sel", aud_l_parents, 0x070, 0x074, 0x078, 24,
+			     2, 31, 0x1c4, 0),
+	/* CLK_CFG_8 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_A_TUNER_SEL, "a_tuner_sel", a1sys_parents, 0x080, 0x084, 0x088,
+			     0, 1, 7, 0x1c4, 1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SSPXTP_SEL, "sspxtp_sel", sspxtp_parents, 0x080, 0x084, 0x088,
+			     8, 1, 15, 0x1c4, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USB_PHY_SEL, "usb_phy_sel", sspxtp_parents, 0x080, 0x084,
+			     0x088, 16, 1, 23, 0x1c4, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_0_SEL, "usxgmii_sbus_0_sel",
+			     usxgmii_sbus_0_parents, 0x080, 0x084, 0x088, 24, 1, 31, 0x1C4, 4),
+	/* CLK_CFG_9 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_USXGMII_SBUS_1_SEL, "usxgmii_sbus_1_sel",
+			     usxgmii_sbus_0_parents, 0x090, 0x094, 0x098, 0, 1, 7, 0x1C4, 5),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_0_SEL, "sgm_0_sel", sgm_0_parents, 0x090, 0x094, 0x098, 8,
+			     1, 15, 0x1c4, 6),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_0_SEL, "sgm_sbus_0_sel", usxgmii_sbus_0_parents,
+				   0x090, 0x094, 0x098, 16, 1, 23, 0x1C4, 7, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_SGM_1_SEL, "sgm_1_sel", sgm_0_parents, 0x090, 0x094, 0x098, 24,
+			     1, 31, 0x1c4, 8),
+	/* CLK_CFG_10 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SGM_SBUS_1_SEL, "sgm_sbus_1_sel", usxgmii_sbus_0_parents,
+				   0x0a0, 0x0a4, 0x0a8, 0, 1, 7, 0x1C4, 9, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_0_XTAL_SEL, "xfi_phy_0_xtal_sel", sspxtp_parents,
+			     0x0a0, 0x0a4, 0x0a8, 8, 1, 15, 0x1C4, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_XFI_PHY_1_XTAL_SEL, "xfi_phy_1_xtal_sel", sspxtp_parents,
+			     0x0a0, 0x0a4, 0x0a8, 16, 1, 23, 0x1C4, 11),
+	/* CLK_CFG_11 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAXI_SEL, "sysaxi_sel", axi_infra_parents, 0x0a0,
+				   0x0a4, 0x0a8, 24, 1, 31, 0x1C4, 12, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_SYSAPB_SEL, "sysapb_sel", sysapb_parents, 0x0b0, 0x0b4,
+				   0x0b8, 0, 1, 7, 0x1c4, 13, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_REFCK_50M_SEL, "eth_refck_50m_sel", eth_refck_50m_parents,
+			     0x0b0, 0x0b4, 0x0b8, 8, 1, 15, 0x1C4, 14),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_200M_SEL, "eth_sys_200m_sel", eth_sys_200m_parents,
+			     0x0b0, 0x0b4, 0x0b8, 16, 1, 23, 0x1C4, 15),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_SYS_SEL, "eth_sys_sel", pcie_mbist_250m_parents, 0x0b0,
+			     0x0b4, 0x0b8, 24, 1, 31, 0x1C4, 16),
+	/* CLK_CFG_12 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_XGMII_SEL, "eth_xgmii_sel", eth_xgmii_parents, 0x0c0,
+			     0x0c4, 0x0c8, 0, 2, 7, 0x1C4, 17),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_BUS_TOPS_SEL, "bus_tops_sel", bus_tops_parents, 0x0c0, 0x0c4,
+			     0x0c8, 8, 2, 15, 0x1C4, 18),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_TOPS_SEL, "npu_tops_sel", npu_tops_parents, 0x0c0, 0x0c4,
+			     0x0c8, 16, 1, 23, 0x1C4, 19),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_SEL, "dramc_sel", sspxtp_parents, 0x0c0, 0x0c4,
+				   0x0c8, 24, 1, 31, 0x1C4, 20, CLK_IS_CRITICAL),
+	/* CLK_CFG_13 */
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_DRAMC_MD32_SEL, "dramc_md32_sel", dramc_md32_parents,
+				   0x0d0, 0x0d4, 0x0d8, 0, 2, 7, 0x1C4, 21, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD_FLAGS(CLK_TOP_INFRA_F26M_SEL, "csw_infra_f26m_sel", sspxtp_parents,
+				   0x0d0, 0x0d4, 0x0d8, 8, 1, 15, 0x1C4, 22, CLK_IS_CRITICAL),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P0_SEL, "pextp_p0_sel", sspxtp_parents, 0x0d0, 0x0d4,
+			     0x0d8, 16, 1, 23, 0x1C4, 23),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P1_SEL, "pextp_p1_sel", sspxtp_parents, 0x0d0, 0x0d4,
+			     0x0d8, 24, 1, 31, 0x1C4, 24),
+	/* CLK_CFG_14 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P2_SEL, "pextp_p2_sel", sspxtp_parents, 0x0e0, 0x0e4,
+			     0x0e8, 0, 1, 7, 0x1C4, 25),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_P3_SEL, "pextp_p3_sel", sspxtp_parents, 0x0e0, 0x0e4,
+			     0x0e8, 8, 1, 15, 0x1C4, 26),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P0_SEL, "da_xtp_glb_p0_sel", da_xtp_glb_p0_parents,
+			     0x0e0, 0x0e4, 0x0e8, 16, 1, 23, 0x1C4, 27),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P1_SEL, "da_xtp_glb_p1_sel", da_xtp_glb_p0_parents,
+			     0x0e0, 0x0e4, 0x0e8, 24, 1, 31, 0x1C4, 28),
+	/* CLK_CFG_15 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P2_SEL, "da_xtp_glb_p2_sel", da_xtp_glb_p0_parents,
+			     0x0f0, 0x0f4, 0x0f8, 0, 1, 7, 0x1C4, 29),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_XTP_GLB_P3_SEL, "da_xtp_glb_p3_sel", da_xtp_glb_p0_parents,
+			     0x0f0, 0x0f4, 0x0f8, 8, 1, 15, 0x1C4, 30),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_CKM_SEL, "ckm_sel", sspxtp_parents, 0x0F0, 0x0f4, 0x0f8, 16, 1,
+			     23, 0x1c8, 0),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DA_SEL, "da_sel", sspxtp_parents, 0x0f0, 0x0f4, 0x0f8, 24, 1,
+			     31, 0x1C8, 1),
+	/* CLK_CFG_16 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_PEXTP_SEL, "pextp_sel", sspxtp_parents, 0x0100, 0x104, 0x108,
+			     0, 1, 7, 0x1c8, 2),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_TOPS_P2_26M_SEL, "tops_p2_26m_sel", sspxtp_parents, 0x0100,
+			     0x104, 0x108, 8, 1, 15, 0x1C8, 3),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MCUSYS_BACKUP_625M_SEL, "mcusys_backup_625m_sel",
+			     mcusys_backup_625m_parents, 0x0100, 0x104, 0x108, 16, 1, 23, 0x1C8, 4),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_SYNC_250M_SEL, "netsys_sync_250m_sel",
+			     pcie_mbist_250m_parents, 0x0100, 0x104, 0x108, 24, 1, 31, 0x1c8, 5),
+	/* CLK_CFG_17 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_MACSEC_SEL, "macsec_sel", macsec_parents, 0x0110, 0x114, 0x118,
+			     0, 2, 7, 0x1c8, 6),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_TOPS_400M_SEL, "netsys_tops_400m_sel",
+			     netsys_tops_400m_parents, 0x0110, 0x114, 0x118, 8, 1, 15, 0x1c8, 7),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_PPEFB_250M_SEL, "netsys_ppefb_250m_sel",
+			     pcie_mbist_250m_parents, 0x0110, 0x114, 0x118, 16, 1, 23, 0x1c8, 8),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NETSYS_WARP_SEL, "netsys_warp_sel", netsys_parents, 0x0110,
+			     0x114, 0x118, 24, 2, 31, 0x1C8, 9),
+	/* CLK_CFG_18 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_ETH_MII_SEL, "eth_mii_sel", eth_mii_parents, 0x0120, 0x124,
+			     0x128, 0, 1, 7, 0x1c8, 10),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_NPU_SEL, "ck_npu_sel", netsys_2x_parents, 0x0120, 0x124, 0x128,
+			     8, 2, 15, 0x1c8, 11),
+};
+
+static const struct mtk_composite top_aud_divs[] = {
+	DIV_GATE(CLK_TOP_AUD_I2S_M, "aud_i2s_m", "aud_sel", 0x0420, 0, 0x0420, 8, 8),
+};
+
+static const struct mtk_clk_desc topck_desc = {
+	.fixed_clks = top_fixed_clks,
+	.num_fixed_clks = ARRAY_SIZE(top_fixed_clks),
+	.factor_clks = top_divs,
+	.num_factor_clks = ARRAY_SIZE(top_divs),
+	.mux_clks = top_muxes,
+	.num_mux_clks = ARRAY_SIZE(top_muxes),
+	.composite_clks = top_aud_divs,
+	.num_composite_clks = ARRAY_SIZE(top_aud_divs),
+	.clk_lock = &mt7988_clk_lock,
+};
+
+static const char *const mcu_bus_div_parents[] = { "top_xtal", "ccipll2_b", "net1pll_d4" };
+
+static const char *const mcu_arm_div_parents[] = { "top_xtal", "arm_b", "net1pll_d4" };
+
+static struct mtk_composite mcu_muxes[] = {
+	/* bus_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_BUS_DIV_SEL, "mcu_bus_div_sel", mcu_bus_div_parents, 0x7C0, 9, 2, -1,
+		       CLK_IS_CRITICAL),
+	/* mp2_pll_divider_cfg */
+	MUX_GATE_FLAGS(CLK_MCU_ARM_DIV_SEL, "mcu_arm_div_sel", mcu_arm_div_parents, 0x7A8, 9, 2, -1,
+		       CLK_IS_CRITICAL),
+};
+
+static const struct mtk_clk_desc mcusys_desc = {
+	.composite_clks = mcu_muxes,
+	.num_composite_clks = ARRAY_SIZE(mcu_muxes),
+};
+
+static const struct of_device_id of_match_clk_mt7988_topckgen[] = {
+	{ .compatible = "mediatek,mt7988-topckgen", .data = &topck_desc },
+	{ .compatible = "mediatek,mt7988-mcusys", .data = &mcusys_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_topckgen);
+
+static struct platform_driver clk_mt7988_topckgen_drv = {
+	.probe = mtk_clk_simple_probe,
+	.remove_new = mtk_clk_simple_remove,
+	.driver = {
+		.name = "clk-mt7988-topckgen",
+		.of_match_table = of_match_clk_mt7988_topckgen,
+	},
+};
+module_platform_driver(clk_mt7988_topckgen_drv);
+MODULE_LICENSE("GPL");
diff --git a/drivers/clk/mediatek/clk-mt7988-xfipll.c b/drivers/clk/mediatek/clk-mt7988-xfipll.c
new file mode 100644
index 0000000000000..9b9ca5471158b
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7988-xfipll.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include "clk-mtk.h"
+#include "clk-gate.h"
+#include <dt-bindings/clock/mediatek,mt7988-clk.h>
+
+/* Register to control USXGMII XFI PLL analog */
+#define XFI_PLL_ANA_GLB8		0x108
+#define RG_XFI_PLL_ANA_SWWA		0x02283248
+
+static const struct mtk_gate_regs xfipll_cg_regs = {
+	.set_ofs = 0x8,
+	.clr_ofs = 0x8,
+	.sta_ofs = 0x8,
+};
+
+#define GATE_XFIPLL(_id, _name, _parent, _shift)		\
+	{							\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.regs = &xfipll_cg_regs,			\
+		.shift = _shift,				\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,		\
+	}
+
+static const struct mtk_fixed_factor xfipll_divs[] = {
+	FACTOR(CLK_XFIPLL_PLL, "xfipll_pll", "top_xtal", 125, 32),
+};
+
+static const struct mtk_gate xfipll_clks[] = {
+	GATE_XFIPLL(CLK_XFIPLL_PLL_EN, "xfipll_pll_en", "xfipll_pll", 31),
+};
+
+static const struct mtk_clk_desc xfipll_desc = {
+	.clks = xfipll_clks,
+	.num_clks = ARRAY_SIZE(xfipll_clks),
+	.factor_clks = xfipll_divs,
+	.num_factor_clks = ARRAY_SIZE(xfipll_divs),
+};
+
+static int clk_mt7988_xfipll_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	void __iomem *base = of_iomap(node, 0);
+
+	if (!base)
+		return -ENOMEM;
+
+	/* Apply software workaround for USXGMII PLL TCL issue */
+	writel(RG_XFI_PLL_ANA_SWWA, base + XFI_PLL_ANA_GLB8);
+	iounmap(base);
+
+	return mtk_clk_simple_probe(pdev);
+};
+
+static const struct of_device_id of_match_clk_mt7988_xfipll[] = {
+	{ .compatible = "mediatek,mt7988-xfi-pll", .data = &xfipll_desc },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt7988_xfipll);
+
+static struct platform_driver clk_mt7988_xfipll_drv = {
+	.driver = {
+		.name = "clk-mt7988-xfipll",
+		.of_match_table = of_match_clk_mt7988_xfipll,
+	},
+	.probe = clk_mt7988_xfipll_probe,
+	.remove_new = mtk_clk_simple_remove,
+};
+module_platform_driver(clk_mt7988_xfipll_drv);
+
+MODULE_DESCRIPTION("MediaTek MT7988 XFI PLL clock driver");
+MODULE_LICENSE("GPL");
-- 
2.43.0


From alexandre.belloni at bootlin.com  Sun Dec 17 14:43:52 2023
From: alexandre.belloni at bootlin.com (Alexandre Belloni)
Date: Sun, 17 Dec 2023 23:43:52 +0100
Subject: (subset) [PATCH v4 0/3] Add support for Nuvoton ma35d1 rtc
 controller
In-Reply-To: <20230925070251.28-1-ychuang570808@gmail.com>
References: <20230925070251.28-1-ychuang570808@gmail.com>
Message-ID: <170285301016.27693.9578027782544960763.b4-ty@bootlin.com>


On Mon, 25 Sep 2023 07:02:48 +0000, Jacky Huang wrote:
> From: Jacky Huang <ychuang3 at nuvoton.com>
> 
> This patch series adds the rtc driver for the nuvoton ma35d1 ARMv8 SoC.
> It includes DT binding documentation, the ma35d1 rtc driver, and device
> tree updates.
> 
> The ma35d1 rtc controller provides real-time and calendar messaging
> capabilities. It supports programmable time tick and alarm match
> interrupts. The time and calendar messages are expressed in BCD format.
> 
> [...]

Applied, thanks!

[1/3] dt-bindings: rtc: Add Nuvoton ma35d1 rtc
      commit: 3767bba698707d7bad5099371b797d0fd6d39709
[3/3] rtc: Add driver for Nuvoton ma35d1 rtc controller
      commit: dc0684adf3b6be6b20fec9295027980021d30353

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From alexandre.belloni at bootlin.com  Sun Dec 17 14:58:31 2023
From: alexandre.belloni at bootlin.com (alexandre.belloni at bootlin.com)
Date: Sun, 17 Dec 2023 23:58:31 +0100
Subject: [PATCH] rtc: ma35d1: remove hardcoded UIE support
Message-ID: <20231217225831.48581-1-alexandre.belloni@bootlin.com>

From: Alexandre Belloni <alexandre.belloni at bootlin.com>

Let the core handle UIE instead of enabling it forcefully at probe which
means the RTC will generate an interrupt every second even when nobody
cares.

Signed-off-by: Alexandre Belloni <alexandre.belloni at bootlin.com>
---
 drivers/rtc/rtc-ma35d1.c | 20 --------------------
 1 file changed, 20 deletions(-)

diff --git a/drivers/rtc/rtc-ma35d1.c b/drivers/rtc/rtc-ma35d1.c
index 07c9a083a9d5..cfcfc28060f6 100644
--- a/drivers/rtc/rtc-ma35d1.c
+++ b/drivers/rtc/rtc-ma35d1.c
@@ -79,11 +79,6 @@ static irqreturn_t ma35d1_rtc_interrupt(int irq, void *data)
 		events |= RTC_AF | RTC_IRQF;
 	}
 
-	if (rtc_irq & RTC_INTSTS_UIF) {
-		rtc_reg_write(rtc, MA35_REG_RTC_INTSTS, RTC_INTSTS_UIF);
-		events |= RTC_UF | RTC_IRQF;
-	}
-
 	rtc_update_irq(rtc->rtcdev, 1, events);
 
 	return IRQ_HANDLED;
@@ -216,7 +211,6 @@ static int ma35d1_rtc_probe(struct platform_device *pdev)
 {
 	struct ma35_rtc *rtc;
 	struct clk *clk;
-	u32 regval;
 	int ret;
 
 	rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
@@ -264,40 +258,26 @@ static int ma35d1_rtc_probe(struct platform_device *pdev)
 	if (ret)
 		return dev_err_probe(&pdev->dev, ret, "Failed to register rtc device\n");
 
-	regval = rtc_reg_read(rtc, MA35_REG_RTC_INTEN);
-	regval |= RTC_INTEN_UIEN;
-	rtc_reg_write(rtc, MA35_REG_RTC_INTEN, regval);
-
 	return 0;
 }
 
 static int ma35d1_rtc_suspend(struct platform_device *pdev, pm_message_t state)
 {
 	struct ma35_rtc *rtc = platform_get_drvdata(pdev);
-	u32 regval;
 
 	if (device_may_wakeup(&pdev->dev))
 		enable_irq_wake(rtc->irq_num);
 
-	regval = rtc_reg_read(rtc, MA35_REG_RTC_INTEN);
-	regval &= ~RTC_INTEN_UIEN;
-	rtc_reg_write(rtc, MA35_REG_RTC_INTEN, regval);
-
 	return 0;
 }
 
 static int ma35d1_rtc_resume(struct platform_device *pdev)
 {
 	struct ma35_rtc *rtc = platform_get_drvdata(pdev);
-	u32 regval;
 
 	if (device_may_wakeup(&pdev->dev))
 		disable_irq_wake(rtc->irq_num);
 
-	regval = rtc_reg_read(rtc, MA35_REG_RTC_INTEN);
-	regval |= RTC_INTEN_UIEN;
-	rtc_reg_write(rtc, MA35_REG_RTC_INTEN, regval);
-
 	return 0;
 }
 
-- 
2.43.0



From sboyd at kernel.org  Sun Dec 17 15:05:01 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Sun, 17 Dec 2023 15:05:01 -0800
Subject: [PATCH 1/2] clk: stm32: initialize syscon after clocks are registered
In-Reply-To: <20231002180854.1603452-2-ben.wolsieffer@hefring.com>
References: <20231002180854.1603452-1-ben.wolsieffer@hefring.com> <20231002180854.1603452-2-ben.wolsieffer@hefring.com>
Message-ID: <883a61872f94c972cc410da84eaf7b97.sboyd@kernel.org>

Quoting Ben Wolsieffer (2023-10-02 11:08:53)
> The stm32-power-config syscon (PWR peripheral) is used in this driver
> and the STM32 RTC driver to enable write access to backup domain
> registers. The syscon's clock has a gate controlled by this clock
> driver, but this clock is currently not registered in the device tree.
> This only happens to work currently because all relevant clock setup and
> RTC initialization happens before clk_disabled_unused(). After this
> point, all syscon register writes are ignored.

Seems like we should mark those clks as CLK_IGNORE_UNUSED and add a
comment to that fact.

> 
> If we simply add the syscon clock in the device tree, we end up with a
> circular dependency because the clock has not been registered at the
> point this driver requests the syscon.
> 
> This patch avoids this circular dependency by moving the syscon lookup
> after the clocks are registered. This does appear to create a possible
> race condition where someone could attempt to perform an operation on a
> backup domain clock before the syscon has been initialized. This would
> result in the operation having no effect because backup domain writes
> could not be enabled. I'm not sure if this is a problem or if there is
> a way to avoid it.

There's no comment in the code that says the regmap must be set there
instead of earlier. What's to stop someone from tripping over this
problem later? At the least, please add a comment.


From sboyd at kernel.org  Sun Dec 17 15:22:40 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Sun, 17 Dec 2023 15:22:40 -0800
Subject: [PATCH V2] dt-bindings: arm: mediatek: move ethsys controller & convert to DT schema
In-Reply-To: <20231119212416.2682-1-zajec5@gmail.com>
References: <20231119212416.2682-1-zajec5@gmail.com>
Message-ID: <30b8c150ea929063614990c8a1bd3a87.sboyd@kernel.org>

Quoting Rafa? Mi?ecki (2023-11-19 13:24:16)
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> DT schema helps validating DTS files. Binding was moved to clock/ as
> this hardware is a clock provider. Example required a small fix for
> "reg" value (1 address cell + 1 size cell).
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> Reviewed-by: Rob Herring <robh at kernel.org>
> ---

Applied to clk-next


From andre.przywara at arm.com  Sun Dec 17 15:24:04 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Sun, 17 Dec 2023 23:24:04 +0000
Subject: [PATCH 1/2] dt-bindings: arm: sunxi: document BananaPi M4 Berry board name
In-Reply-To: <20231217232405.302-1-andre.przywara@arm.com>
References: <20231217232405.302-1-andre.przywara@arm.com>
Message-ID: <20231217232405.302-2-andre.przywara@arm.com>

The Bananapi M4 Berry is a development board with the Allwinner H618 SoC.

Add the board/SoC compatible string pair to the list of known boards.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 5e91110cc9eb8..b659e03550315 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -136,6 +136,11 @@ properties:
           - const: sinovoip,bpi-m3
           - const: allwinner,sun8i-a83t
 
+      - description: BananaPi M4 Berry
+        items:
+          - const: sinovoip,bananapi-m4-berry
+          - const: allwinner,sun50i-h618
+
       - description: BananaPi M64
         items:
           - const: sinovoip,bananapi-m64
-- 
2.35.8



From andre.przywara at arm.com  Sun Dec 17 15:24:05 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Sun, 17 Dec 2023 23:24:05 +0000
Subject: [PATCH 2/2] arm64: dts: allwinner: h618: add BananaPi M4 Berry board
In-Reply-To: <20231217232405.302-1-andre.przywara@arm.com>
References: <20231217232405.302-1-andre.przywara@arm.com>
Message-ID: <20231217232405.302-3-andre.przywara@arm.com>

The BananaPi M4 Berry is a development board using the Allwinner H618
SoC. It comes with the following specs:
	- Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache)
	- 2 GiB LPDDR4 DRAM
	- 8 GiB eMMC flash
	- AXP313a PMIC
	- Gigabit Ethernet, using RTL8211 PHY
	- RTL8821CU USB WiFi chip
	- HDMI port
	- 4 * USB 2.0 ports, via an on-board hub chip
	- microSD card slot
	- 3.5mm A/V port
	- power supply and USB-OTG via USB-C connector

Add a devicetree file describing the components that we already have
bindings for, that excludes audio and video at the moment.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../sun50i-h618-bananapi-m4-berry.dts         | 229 ++++++++++++++++++
 2 files changed, 230 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 91d505b385de5..ed016688bb56f 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -42,5 +42,6 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-bananapi-m4-berry.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero3.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-transpeed-8k618-t.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts
new file mode 100644
index 0000000000000..11d893a767d4e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts
@@ -0,0 +1,229 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2023 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "BananaPi M4 Berry";
+	compatible = "sinovoip,bananapi-m4-berry", "allwinner,sun50i-h618";
+
+	aliases {
+		ethernet0 = &emac0;
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			function = LED_FUNCTION_STATUS;
+			color = <LED_COLOR_ID_GREEN>;
+			gpios = <&pio 2 12 GPIO_ACTIVE_LOW>; /* PC12 */
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		key-sw4 {
+			label = "sw3";
+			linux,code = <BTN_0>;
+			gpios = <&pio 2 7 GPIO_ACTIVE_LOW>;	/* PC7 */
+		};
+	};
+
+	reg_vcc5v: vcc5v {
+		/* board wide 5V supply directly from the USB-C socket */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-5v";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	reg_usb_vbus: regulator-usb-vbus {
+		/* separate discrete regulator for the USB ports */
+		compatible = "regulator-fixed";
+		regulator-name = "usb-vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&reg_vcc5v>;
+	};
+
+	reg_3v3: regulator-3v3 {
+		/* separate discrete regulator for WiFi and Ethernet PHY */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&reg_vcc5v>;
+	};
+};
+
+&cpu0 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+/* Connected to an on-board RTL8821CU USB WiFi chip. */
+&ehci1 {
+	status = "okay";
+};
+
+/* on unpopulated pins */
+&ehci2 {
+	status = "disabled";
+};
+
+/* Connected to an on-board FE1.1s USB hub chip, supplying 4 USB-A ports. */
+&ehci3 {
+	status = "okay";
+};
+
+&emac0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ext_rgmii_pins>;
+	phy-mode = "rgmii";
+	phy-handle = <&ext_rgmii_phy>;
+	phy-supply = <&reg_3v3>;
+	allwinner,rx-delay-ps = <3100>;
+	allwinner,tx-delay-ps = <700>;
+	status = "okay";
+};
+
+&ir {
+	status = "okay";
+};
+
+&mdio0 {
+	ext_rgmii_phy: ethernet-phy at 1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+		reset-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>;	/* PI16 */
+	};
+};
+
+&mmc0 {
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;	/* PF6 */
+	vmmc-supply = <&reg_dldo1>;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&mmc2 {
+	vmmc-supply = <&reg_dldo1>;
+	vqmmc-supply = <&reg_aldo1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	mmc-ddr-1_8v;
+	mmc-hs200-1_8v;
+	status = "okay";
+};
+
+/* USB ports 1 and 3 connect to onboard devices that are high-speed only. */
+
+/* on unpopulated pins */
+&ohci2 {
+	status = "disabled";
+};
+
+&pio {
+	vcc-pc-supply = <&reg_aldo1>;
+	vcc-pf-supply = <&reg_dldo1>;
+	vcc-pg-supply = <&reg_dldo1>;
+	vcc-ph-supply = <&reg_dldo1>;
+	vcc-pi-supply = <&reg_dldo1>;
+};
+
+&r_i2c {
+	status = "okay";
+
+	axp313: pmic at 36 {
+		compatible = "x-powers,axp313a";
+		reg = <0x36>;
+		#interrupt-cells = <1>;
+		interrupt-controller;
+		interrupt-parent = <&pio>;
+
+		vin1-supply = <&reg_vcc5v>;
+		vin2-supply = <&reg_vcc5v>;
+		vin3-supply = <&reg_vcc5v>;
+
+		regulators {
+			reg_aldo1: aldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc-1v8-pll";
+			};
+
+			reg_dldo1: dldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc-3v3-io";
+			};
+
+			reg_dcdc1: dcdc1 {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <990000>;
+				regulator-name = "vdd-gpu-sys";
+			};
+
+			reg_dcdc2: dcdc2 {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-cpu";
+			};
+
+			reg_dcdc3: dcdc3 {
+				regulator-always-on;
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-dram";
+			};
+		};
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_ph_pins>;
+	status = "okay";
+};
+
+&usbotg {
+	/*
+	 * PHY0 pins are connected to a USB-C socket, but a role switch is not
+	 * implemented: both CC pins are pulled to GND via a 5.1K resistor.
+	 * The VBUS pins power the device, so a fixed peripheral mode
+	 * is the best choice.
+	 * The board can be powered via GPIOs, in this case port0 *can*
+	 * act as a host (with a cable/adapter ignoring CC), as VBUS is
+	 * then provided by the GPIOs. Any user of this setup would
+	 * need to adjust the DT accordingly: dr_mode set to "host",
+	 * enabling OHCI0 and EHCI0.
+	 */
+	dr_mode = "peripheral";
+	status = "okay";
+};
+
+&usbphy {
+	usb3_vbus-supply = <&reg_usb_vbus>;
+	status = "okay";
+};
-- 
2.35.8



From andre.przywara at arm.com  Sun Dec 17 15:24:03 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Sun, 17 Dec 2023 23:24:03 +0000
Subject: [PATCH 0/2] arm64: dts: allwinner: Add BananaPi M4 Berry
Message-ID: <20231217232405.302-1-andre.przywara@arm.com>

The BananaPi M4 Berry is a development board with the Allwinner H618
SoC. It comes with 2GB DRAM and 8GB eMMC flash, with the usual suspects
like HDMI, SD card, GPIO headers. There are four USB ports connected
via an on-board hub chip, and a Gigabit Ethernet socket. Also there is
a USB WiFi chip soldered on the board.
More details: https://linux-sunxi.org/Sinovoip_Banana_Pi_M4_Berry

I don't have this board, so this is a "call for testing".
One thing to consider:
- The USB WiFi chip has a CHIP_EN pin, which can turn the chip off.
  It is pulled up by a resistor, so works out of the box, but is also
  connected to a GPIO (PC2), so the chip can be disabled or reset via
  this pin. Since this is a USB device, we don't have a DT node to
  announce this pin. Any ideas how this should be handled? At the moment
  I ignore it, but it could also be modelled as a USB VBUS regulator for
  USB port 1, to which it is connected.

When testing this, please have a look at:
- Does the eMMC work in HS200 mode? The vendor DT described that as a
  3.3V controlled eMMC only, but clearly the schematic uses 1.8V, which
  allows faster transfer modes. "hdparm -t" should suffice for a quick
  test.
- Do USB full-speed (aka USB v1.1) peripherals like keyboard or mouse
  work on the USB ports? I disabled the OHCI node, since the hub should
  not need this, but it would be good to double check.
- Similarly the USB WiFi chip probably doesn't need USB 1.1 modes, so
  please check this still works.

Apart from the missing audio and video support (which are due to missing
bindings for the H616/H618 SoC), most of the peripherals are supported.

Patch 1/2 adds the board compatible string to the bindings, patch 2/2
adds the actual .dts file.

Please have a look!

Thanks,
Andre

Andre Przywara (2):
  dt-bindings: arm: sunxi: document BananaPi M4 Berry board name
  arm64: dts: allwinner: h618: add BananaPi M4 Berry board

 .../devicetree/bindings/arm/sunxi.yaml        |   5 +
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../sun50i-h618-bananapi-m4-berry.dts         | 229 ++++++++++++++++++
 3 files changed, 235 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts

-- 
2.35.8



From sboyd at kernel.org  Sun Dec 17 15:52:17 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Sun, 17 Dec 2023 15:52:17 -0800
Subject: [PATCH v6 4/5] clk: stm32: introduce clocks for STM32MP257 platform
In-Reply-To: <20231208143700.354785-5-gabriel.fernandez@foss.st.com>
References: <20231208143700.354785-1-gabriel.fernandez@foss.st.com> <20231208143700.354785-5-gabriel.fernandez@foss.st.com>
Message-ID: <e8124f2cad7afbb4e9fbd777dda992f4.sboyd@kernel.org>

Quoting gabriel.fernandez at foss.st.com (2023-12-08 06:36:59)
> diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
> new file mode 100644
> index 000000000000..36321fd6142e
> --- /dev/null
> +++ b/drivers/clk/stm32/clk-stm32mp25.c
> @@ -0,0 +1,1125 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
> + * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/delay.h>

Is this include used?

> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>

Is this include used?

> +
> +#include "clk-stm32-core.h"
> +#include "reset-stm32.h"
> +
> +#include <dt-bindings/clock/st,stm32mp25-rcc.h>
> +#include <dt-bindings/reset/st,stm32mp25-rcc.h>
> +
> +#include "stm32mp25_rcc.h"
> +
> +static const char * const adc12_src[] = {
> +       "ck_flexgen_46", "ck_icn_ls_mcu"

Can we please migrate to struct clk_parent_data?

> +};
> +
> +static const char * const adc3_src[] = {
> +       "ck_flexgen_47", "ck_icn_ls_mcu", "ck_flexgen_46"
> +};
> +
> +static const char * const usb2phy1_src[] = {
> +       "ck_flexgen_57", "hse_div2_ck"
> +};
[...]
> +       GATE_TIM4,
> +       GATE_TIM5,
> +       GATE_TIM6,
> +       GATE_TIM7,
> +       GATE_TIM8,
> +       GATE_UART4,
> +       GATE_UART5,
> +       GATE_UART7,
> +       GATE_UART8,
> +       GATE_UART9,
> +       GATE_USART1,
> +       GATE_USART2,
> +       GATE_USART3,
> +       GATE_USART6,
> +       GATE_USB2,
> +       GATE_USB2PHY1,
> +       GATE_USB2PHY2,
> +       GATE_USB3DR,
> +       GATE_USB3PCIEPHY,
> +       GATE_USBTC,
> +       GATE_VDEC,
> +       GATE_VENC,
> +       GATE_VREF,
> +       GATE_WWDG1,
> +       GATE_WWDG2,
> +       GATE_NB
> +};
> +
> +#define GATE_CFG(id, _offset, _bit_idx, _offset_clr)\
> +       [id] = {\

Please move these slashes out and align them.

> +               .offset         = (_offset),\
> +               .bit_idx        = (_bit_idx),\
> +               .set_clr        = (_offset_clr),\
> +       }
> +
> +static const struct stm32_gate_cfg stm32mp25_gates[GATE_NB] = {
> +       GATE_CFG(GATE_ADC12,            RCC_ADC12CFGR,          1,      0),
> +       GATE_CFG(GATE_ADC3,             RCC_ADC3CFGR,           1,      0),
> +       GATE_CFG(GATE_ADF1,             RCC_ADF1CFGR,           1,      0),
> +       GATE_CFG(GATE_CCI,              RCC_CCICFGR,            1,      0),
> +       GATE_CFG(GATE_CRC,              RCC_CRCCFGR,            1,      0),
> +       GATE_CFG(GATE_CRYP1,            RCC_CRYP1CFGR,          1,      0),
[....]
> +
> +static struct clk_stm32_clock_data stm32mp25_clock_data = {
> +       .gate_cpt       = stm32mp25_cpt_gate,
> +       .gates          = stm32mp25_gates,
> +       .muxes          = stm32mp25_muxes,
> +};
> +
> +static struct clk_stm32_reset_data stm32mp25_reset_data = {
> +       .reset_lines    = stm32mp25_reset_cfg,
> +       .nr_lines       = ARRAY_SIZE(stm32mp25_reset_cfg),
> +};
> +
> +static struct stm32_rcc_match_data stm32mp25_data = {

const

> +       .tab_clocks     = stm32mp25_clock_cfg,
> +       .num_clocks     = ARRAY_SIZE(stm32mp25_clock_cfg),
> +       .maxbinding     = STM32MP25_LAST_CLK,
> +       .clock_data     = &stm32mp25_clock_data,
> +       .reset_data     = &stm32mp25_reset_data,
> +};
> +
> +static const struct of_device_id stm32mp25_match_data[] = {
> +       {
> +               .compatible = "st,stm32mp25-rcc",
> +               .data = &stm32mp25_data,
> +       },
> +       { }
> +};
> +MODULE_DEVICE_TABLE(of, stm32mp25_match_data);
> +
> +static int stm32mp25_rcc_init(struct device *dev)

Please inline this function in the one call site.

> +{
> +       void __iomem *base;
> +       int ret;
> +
> +       base = of_iomap(dev_of_node(dev), 0);

Use platform device APIs instead of OF specific ones.

> +       if (!base) {
> +               dev_err(dev, "%pOFn: unable to map resource", dev_of_node(dev));

Missing newline.

> +               ret = -ENOMEM;
> +               goto out;
> +       }
> +
> +       ret = stm32_rcc_init(dev, stm32mp25_match_data, base);
> +
> +out:
> +       if (ret) {
> +               if (base)
> +                       iounmap(base);
> +
> +               of_node_put(dev_of_node(dev));

When did we get the node?

> +       }
> +
> +       return ret;
> +}
> +
> +static int get_clock_deps(struct device *dev)
> +{
> +       static const char * const clock_deps_name[] = {
> +               "hsi", "hse", "msi", "lsi", "lse",
> +       };
> +       size_t deps_size = sizeof(struct clk *) * ARRAY_SIZE(clock_deps_name);
> +       struct clk **clk_deps;
> +       int i;
> +
> +       clk_deps = devm_kzalloc(dev, deps_size, GFP_KERNEL);
> +       if (!clk_deps)
> +               return -ENOMEM;
> +
> +       for (i = 0; i < ARRAY_SIZE(clock_deps_name); i++) {
> +               struct clk *clk;
> +
> +               clk = of_clk_get_by_name(dev_of_node(dev), clock_deps_name[i]);
> +
> +               if (IS_ERR(clk)) {
> +                       if (PTR_ERR(clk) != -EINVAL && PTR_ERR(clk) != -ENOENT)
> +                               return PTR_ERR(clk);
> +               } else {
> +                       /* Device gets a reference count on the clock */
> +                       clk_deps[i] = devm_clk_get(dev, __clk_get_name(clk));

Is something using this clk_deps array?

> +                       clk_put(clk);
> +               }
> +       }
> +
> +       return 0;
> +}
> +
> +static int stm32mp25_rcc_clocks_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       int ret = get_clock_deps(dev);
> +
> +       if (!ret)
> +               ret = stm32mp25_rcc_init(dev);
> +
> +       return ret;
> +}
> +


From sboyd at kernel.org  Sun Dec 17 15:53:20 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Sun, 17 Dec 2023 15:53:20 -0800
Subject: [PATCH v6 1/5] clk: stm32mp1: move stm32mp1 clock driver into stm32 directory
In-Reply-To: <20231208143700.354785-2-gabriel.fernandez@foss.st.com>
References: <20231208143700.354785-1-gabriel.fernandez@foss.st.com> <20231208143700.354785-2-gabriel.fernandez@foss.st.com>
Message-ID: <67c89fcb076df1ba5332c8840eb01dfc.sboyd@kernel.org>

Quoting gabriel.fernandez at foss.st.com (2023-12-08 06:36:56)
> From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> 
> Move all STM32MP clock drivers into same directory (stm32).
> 
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> ---

Applied to clk-next


From sboyd at kernel.org  Sun Dec 17 15:53:32 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Sun, 17 Dec 2023 15:53:32 -0800
Subject: [PATCH v6 2/5] clk: stm32mp1: use stm32mp13 reset driver
In-Reply-To: <20231208143700.354785-3-gabriel.fernandez@foss.st.com>
References: <20231208143700.354785-1-gabriel.fernandez@foss.st.com> <20231208143700.354785-3-gabriel.fernandez@foss.st.com>
Message-ID: <b4151a2bb19f18fbeb83dc872b3f1deb.sboyd@kernel.org>

Quoting gabriel.fernandez at foss.st.com (2023-12-08 06:36:57)
> From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> 
> STM32MP15 is now using the same reset driver as STM32MP13 as they
> have the same binding requirement.
> 
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> ---

Applied to clk-next


From sboyd at kernel.org  Sun Dec 17 15:54:33 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Sun, 17 Dec 2023 15:54:33 -0800
Subject: [PATCH v6 3/5] dt-bindings: stm32: add clocks and reset binding for stm32mp25 platform
In-Reply-To: <20231208143700.354785-4-gabriel.fernandez@foss.st.com>
References: <20231208143700.354785-1-gabriel.fernandez@foss.st.com> <20231208143700.354785-4-gabriel.fernandez@foss.st.com>
Message-ID: <d833e349ad841b1a3389ba475833e903.sboyd@kernel.org>

Quoting gabriel.fernandez at foss.st.com (2023-12-08 06:36:58)
> From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> 
> Adds clock and reset binding entries for STM32MP25 SoC family
> 
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---

Applied to clk-next


From sboyd at kernel.org  Sun Dec 17 16:17:41 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Sun, 17 Dec 2023 16:17:41 -0800
Subject: [PATCH 1/2] clk: Add a devm variant of clk_rate_exclusive_get()
In-Reply-To: <744a6371f94fe96f527eea6e52a600914e6fb6b5.1702403904.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702403904.git.u.kleine-koenig@pengutronix.de> <744a6371f94fe96f527eea6e52a600914e6fb6b5.1702403904.git.u.kleine-koenig@pengutronix.de>
Message-ID: <5391068cdc86b6117920d31a524d934b.sboyd@kernel.org>

Quoting Uwe Kleine-K?nig (2023-12-12 10:09:42)
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index af2011c2a93b..78249ca2341c 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -937,6 +937,21 @@ void clk_rate_exclusive_get(struct clk *clk)
>  }
>  EXPORT_SYMBOL_GPL(clk_rate_exclusive_get);
>  
> +static void devm_clk_rate_exclusive_put(void *data)
> +{
> +       struct clk *clk = data;
> +
> +       clk_rate_exclusive_put(clk);
> +}
> +
> +int devm_clk_rate_exclusive_get(struct device *dev, struct clk *clk)
> +{
> +       clk_rate_exclusive_get(clk);

It seems the other thread wants this to return an error value.

> +
> +       return devm_add_action_or_reset(dev, devm_clk_rate_exclusive_put, clk);
> +}
> +EXPORT_SYMBOL_GPL(devm_clk_rate_exclusive_get);
> +
>  static void clk_core_unprepare(struct clk_core *core)
>  {
>         lockdep_assert_held(&prepare_lock);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index f88c407925f8..5a749459c3a3 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -199,6 +199,18 @@ bool clk_is_match(const struct clk *p, const struct clk *q);
>   */
>  void clk_rate_exclusive_get(struct clk *clk);
>  
> +/**
> + * devm_clk_rate_exclusive_get - devm variant of clk_rate_exclusive_get
> + * @dev: device the exclusivity is bound to
> + * @clk: clock source
> + *
> + * Calls clk_rate_exclusive_get() on @clk and registers a devm cleanup handler
> + * on @dev to cal clk_rate_exclusive_put().

call

> + *
> + * Must not be called from within atomic context.
> + */
> +int devm_clk_rate_exclusive_get(struct device *dev, struct clk *clk);
> +
>  /**
>   * clk_rate_exclusive_put - release exclusivity over the rate control of a
>   *                          producer


From inindev at gmail.com  Sun Dec 17 16:25:43 2023
From: inindev at gmail.com (John Clark)
Date: Sun, 17 Dec 2023 19:25:43 -0500
Subject: [PATCH 2/3] arm64: dts: rockchip: Add support for NanoPi R6S
In-Reply-To: <25d84712ee3765f5f28dfd355a2392f20f388824.1702647349.git.efectn@protonmail.com>
References: <cover.1702647349.git.efectn@protonmail.com>
 <25d84712ee3765f5f28dfd355a2392f20f388824.1702647349.git.efectn@protonmail.com>
Message-ID: <9a6dd3ac-acb1-2222-918a-d325c56bbded@gmail.com>

On 12/15/23 8:55 AM, efectn at 6tel.net wrote:

> From: Muhammed Efe Cetin <efectn at protonmail.com>
>
> Add basic NanoPi R6S support that comes with USB2, PCIe, SD card, eMMC
> support.
>
> Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
> ---
>   arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>   .../boot/dts/rockchip/rk3588s-nanopi-r6s.dts  | 755 ++++++++++++++++++
>   2 files changed, 756 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 600c420bc..ed2583dcd 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -114,3 +114,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
> \ No newline at end of file
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
> new file mode 100644
> index 000000000..e575cc403
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
> @@ -0,0 +1,755 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "rk3588s.dtsi"
> +
> +/ {
> +	model = "FriendlyElec NanoPi R6S";
> +	compatible = "friendlyelec,nanopi-r6s", "rockchip,rk3588s";
> +
> +	aliases {
> +		ethernet0 = &gmac1;
> +		mmc0 = &sdmmc;
> +		mmc1 = &sdhci;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial2:1500000n8";
> +	};
> +
> +	adc-keys {
> +		compatible = "adc-keys";
> +		io-channels = <&saradc 0>;
> +		io-channel-names = "buttons";
> +		keyup-threshold-microvolt = <1800000>;
> +		poll-interval = <100>;
> +
> +		button-maskrom {
> +			label = "Maskrom";
> +			linux,code = <KEY_VENDOR>;
> +			press-threshold-microvolt = <1800>;
> +		};
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&key1_pin>;
> +
> +		button-user {
> +			label = "User";
> +			linux,code = <BTN_1>;
> +			gpios = <&gpio1 RK_PC0 GPIO_ACTIVE_LOW>;
> +			debounce-interval = <50>;
> +		};
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		sys_led: led-0 {
> +			label = "sys_led";
> +			gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
> +			linux,default-trigger = "heartbeat";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&sys_led_pin>;
> +		};
> +
> +		wan_led: led-1 {
> +			label = "wan_led";
> +			gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&wan_led_pin>;
> +		};
> +
> +		lan1_led: led-2 {
> +			label = "lan1_led";
> +			gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&lan1_led_pin>;
> +		};
> +
> +		lan2_led: led-3 {
> +			label = "lan2_led";
> +			gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&lan2_led_pin>;
> +		};
> +	};
> +
> +	vcc5v0_sys: vcc5v0-sys-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc5v0_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +	};
> +
> +	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_1v1_nldo_s3";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <1100000>;
> +		regulator-max-microvolt = <1100000>;
> +		vin-supply = <&vcc5v0_sys>;
> +	};
> +
> +	vcc_3v3_sd_s0: vcc-3v3-sd-s0-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&sd_s0_pwr>;
> +		regulator-name = "vcc_3v3_sd_s0";
> +		regulator-boot-on;
> +		regulator-max-microvolt = <3000000>;
> +		regulator-min-microvolt = <3000000>;
> +		vin-supply = <&vcc_3v3_s3>;
> +	};
> +
> +	vcc_3v3_pcie20: vcc3v3-pcie20-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_3v3_pcie20";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc_3v3_s3>;
> +	};
> +
> +	vcc5v0_usb: vcc5v0-usb-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc5v0_usb";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v0_sys>;
> +	};
> +
> +	vcc5v0_usb_otg0: vcc5v0-usb-otg0-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpios = <&gpio1 RK_PD2 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&typec5v_pwren>;
> +		regulator-name = "vcc5v0_usb_otg0";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v0_usb>;
> +	};
> +
> +	vcc5v0_host_20: vcc5v0-host-20-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_host20_en>;
> +		regulator-name = "vcc5v0_host_20";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v0_usb>;
> +	};
> +};
> +
> +&combphy0_ps {
> +	status = "okay";
> +};
> +
> +&combphy2_psu {
> +	status = "okay";
> +};
> +
> +&cpu_b0 {
> +	cpu-supply = <&vdd_cpu_big0_s0>;
> +};
> +
> +&cpu_b1 {
> +	cpu-supply = <&vdd_cpu_big0_s0>;
> +};
> +
> +&cpu_b2 {
> +	cpu-supply = <&vdd_cpu_big1_s0>;
> +};
> +
> +&cpu_b3 {
> +	cpu-supply = <&vdd_cpu_big1_s0>;
> +};
> +
> +&cpu_l0 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l1 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l2 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l3 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&gmac1 {
> +	clock_in_out = "output";
> +	phy-handle = <&rgmii_phy1>;
> +	phy-mode = "rgmii-rxid";
> +	pinctrl-0 = <&gmac1_miim
> +		     &gmac1_tx_bus2
> +		     &gmac1_rx_bus2
> +		     &gmac1_rgmii_clk
> +		     &gmac1_rgmii_bus>;
> +	pinctrl-names = "default";
> +	tx_delay = <0x42>;
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c0m2_xfer>;
> +	status = "okay";
> +
> +	vdd_cpu_big0_s0: regulator at 42 {
> +		compatible = "rockchip,rk8602";
> +		reg = <0x42>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu_big0_s0";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <1050000>;
> +		regulator-ramp-delay = <2300>;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vdd_cpu_big1_s0: regulator at 43 {
> +		compatible = "rockchip,rk8603", "rockchip,rk8602";
> +		reg = <0x43>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu_big1_s0";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <1050000>;
> +		regulator-ramp-delay = <2300>;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&i2c2 {
> +	status = "okay";
> +
> +	vdd_npu_s0: rk8602 at 42 {
> +		compatible = "rockchip,rk8602";
> +		reg = <0x42>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-compatible = "rk860x-reg";
> +		regulator-name = "vdd_npu_s0";
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <950000>;
> +		regulator-ramp-delay = <2300>;
> +		regulator-boot-on;
> +		regulator-always-on;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&i2c6 {
> +	clock-frequency = <200000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c6m0_xfer>;
> +	status = "okay";
> +
> +	hym8563: rtc at 51 {
> +		compatible = "haoyu,hym8563";
> +		reg = <0x51>;
> +		#clock-cells = <0>;
> +		clock-output-names = "hym8563";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&rtc_int>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
> +		wakeup-source;
> +	};
> +};
> +
> +&mdio1 {
> +	rgmii_phy1: ethernet-phy at 1 {
> +		compatible = "ethernet-phy-id001c.c916";
> +		reg = <0x1>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&rtl8211f_rst>;
> +		reset-assert-us = <20000>;
> +		reset-deassert-us = <100000>;
> +		reset-gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> +	};
> +};
> +
> +&pcie2x1l1 {
> +	reset-gpios = <&gpio1 RK_PA7 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc_3v3_pcie20>;
> +	status = "okay";
> +};
> +
> +&pcie2x1l2 {
> +	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc_3v3_pcie20>;
> +	status = "okay";
> +};
> +
> +&pinctrl {
> +	gpio-key {
> +		key1_pin: key1-pin {
> +			rockchip,pins = <1 RK_PC0 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	gpio-leds {
> +		sys_led_pin: sys-led-pin {
> +			rockchip,pins =
> +				<1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		wan_led_pin: wan-led-pin {
> +			rockchip,pins =
> +				<1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		lan1_led_pin: lan1-led-pin {
> +			rockchip,pins =
> +				<1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		lan2_led_pin: lan2-led-pin {
> +			rockchip,pins =
> +				<1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	hym8563 {
> +		rtc_int: rtc-int {
> +			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	sdmmc {
> +		sd_s0_pwr: sd-s0-pwr {
> +			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	usb {
> +		typec5v_pwren: typec5v-pwren {
> +			rockchip,pins = <1 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		vcc5v0_host20_en: vcc5v0-host20-en {
> +			rockchip,pins = <4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	rtl8211f {
> +		rtl8211f_rst: rtl8211f-rst {
> +			rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&saradc {
> +	vref-supply = <&avcc_1v8_s0>;
> +	status = "okay";
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	no-sdio;
> +	no-sd;
> +	non-removable;
> +	mmc-hs200-1_8v;
> +	max-frequency = <200000000>;
> +	status = "okay";
> +};
> +
> +&sdmmc {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	disable-wp;
> +	max-frequency = <150000000>;
> +	no-mmc;
> +	no-sdio;
> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc_3v3_sd_s0>;
> +	vqmmc-supply = <&vccio_sd_s0>;
> +	status = "okay";
> +};
> +
> +&spi2 {
> +	status = "okay";
> +	assigned-clocks = <&cru CLK_SPI2>;
> +	assigned-clock-rates = <200000000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
> +	num-cs = <1>;
> +
> +	pmic at 0 {
> +		compatible = "rockchip,rk806";
> +		spi-max-frequency = <1000000>;
> +		reg = <0x0>;
> +
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
> +			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
> +
> +		vcc1-supply = <&vcc5v0_sys>;
> +		vcc2-supply = <&vcc5v0_sys>;
> +		vcc3-supply = <&vcc5v0_sys>;
> +		vcc4-supply = <&vcc5v0_sys>;
> +		vcc5-supply = <&vcc5v0_sys>;
> +		vcc6-supply = <&vcc5v0_sys>;
> +		vcc7-supply = <&vcc5v0_sys>;
> +		vcc8-supply = <&vcc5v0_sys>;
> +		vcc9-supply = <&vcc5v0_sys>;
> +		vcc10-supply = <&vcc5v0_sys>;
> +		vcc11-supply = <&vcc_2v0_pldo_s3>;
> +		vcc12-supply = <&vcc5v0_sys>;
> +		vcc13-supply = <&vcc_1v1_nldo_s3>;
> +		vcc14-supply = <&vcc_1v1_nldo_s3>;
> +		vcca-supply = <&vcc5v0_sys>;
> +
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +		rk806_dvs1_null: dvs1-null-pins {
> +			pins = "gpio_pwrctrl2";
> +			function = "pin_fun0";
> +		};
> +
> +		rk806_dvs2_null: dvs2-null-pins {
> +			pins = "gpio_pwrctrl2";
> +			function = "pin_fudr_moden0";
> +		};
> +
> +		rk806_dvs3_null: dvs3-null-pins {
> +			pins = "gpio_pwrctrl3";
> +			function = "pin_fun0";
> +		};
> +
> +		regulators {
> +			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
> +				regulator-boot-on;
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_gpu_s0";
> +				regulator-enable-ramp-delay = <400>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_cpu_lit_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_log_s0: dcdc-reg3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <675000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_log_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <750000>;
> +				};
> +			};
> +
> +			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <550000>;
> +				regulator-max-microvolt = <950000>;
> +				regulator-init-microvolt = <750000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_vdenc_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_ddr_s0: dcdc-reg5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <675000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_ddr_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <850000>;
> +				};
> +			};
> +
> +			vdd2_ddr_s3: dcdc-reg6 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-name = "vdd2_ddr_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc_2v0_pldo_s3: dcdc-reg7 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <2000000>;
> +				regulator-max-microvolt = <2000000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vdd_2v0_pldo_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <2000000>;
> +				};
> +			};
> +
> +			vcc_3v3_s3: dcdc-reg8 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vcc_3v3_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3300000>;
> +				};
> +			};
> +
> +			vddq_ddr_s0: dcdc-reg9 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-name = "vddq_ddr_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8_s3: dcdc-reg10 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc_1v8_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			avcc_1v8_s0: pldo-reg1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "avcc_1v8_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vcc_1v8_s0: pldo-reg2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc_1v8_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			avdd_1v2_s0: pldo-reg3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1200000>;
> +				regulator-max-microvolt = <1200000>;
> +				regulator-name = "avdd_1v2_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_3v3_s0: pldo-reg4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vcc_3v3_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};

The device located at pldo-reg4 is named vcc_3v3_s0

Page 2 of the schematic identifies pldo-reg4 as VCCA_3V3_S0

Therefore, the pldo-reg4 device should be named avcc_3v3_s0 and a 
separate definition for vcc_3v3_s0 should be created.

vcc_3v3_s0 is defined on page 18 as SY6280AAC and is supplied by vcc_3v3_s3

this would be a fixed regulator like:

vcc_3v3_s0: vcc-3v3-s0 {
 ??????? compatible = "regulator-fixed";
 ??????? regulator-always-on;
 ??????? regulator-boot-on;
 ??????? regulator-min-microvolt = <3300000>;
 ??????? regulator-max-microvolt = <3300000>;
 ??????? regulator-name = "vcc_3v3_s0";
 ??????? vin-supply = <&vcc_3v3_s3>;
};

schematic: 
https://wiki.friendlyelec.com/wiki/images/f/f7/NanoPi_R6C_2302_SCH.PDF

> +
> +			vccio_sd_s0: pldo-reg5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-ramp-delay = <12500>;
> +				regulator-name = "vccio_sd_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			pldo6_s3: pldo-reg6 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "pldo6_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vdd_0v75_s3: nldo-reg1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-name = "vdd_0v75_s3";
> +
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <750000>;
> +				};
> +			};
> +
> +			vdd_ddr_pll_s0: nldo-reg2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-name = "vdd_ddr_pll_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +					regulator-suspend-microvolt = <850000>;
> +				};
> +			};

similar, see page 2 of schematic: vdd_ddr_pll_s0: nldo-reg2 -> 
avdd_ddr_pll_s0


> +
> +			avdd_0v75_s0: nldo-reg3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-name = "avdd_0v75_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_0v85_s0: nldo-reg4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-name = "vdd_0v85_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};

similar, see page 2 of schematic: vdd_0v85_s0: nldo-reg4 -> avdd_0v85_s0


> +
> +			vdd_0v75_s0: nldo-reg5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <750000>;
> +				regulator-name = "vdd_0v75_s0";
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&tsadc {
> +	status = "okay";
> +};
> +
> +&u2phy2 {
> +	status = "okay";
> +};
> +
> +&u2phy2_host {
> +	phy-supply = <&vcc5v0_host_20>;
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	pinctrl-0 = <&uart2m0_xfer>;
> +	status = "okay";
> +};
> +
> +&usb_host0_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host0_ohci {
> +	status = "okay";
> +};


From andre.przywara at arm.com  Sun Dec 17 16:57:30 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 18 Dec 2023 00:57:30 +0000
Subject: [PATCH v6 2/3] thermal: sun8i: Add D1/T113s THS controller
 support
In-Reply-To: <20231217210629.131486-3-bigunclemax@gmail.com>
References: <20231217210629.131486-1-bigunclemax@gmail.com>
	<20231217210629.131486-3-bigunclemax@gmail.com>
Message-ID: <20231218005730.59227952@minigeek.lan>

On Mon, 18 Dec 2023 00:06:23 +0300
Maksim Kiselev <bigunclemax at gmail.com> wrote:

Hi Maksim,

> From: Maxim Kiselev <bigunclemax at gmail.com>
> 
> This patch adds a thermal sensor controller support for the D1/T113s,
> which is similar to the one on H6, but with only one sensor and
> different scale and offset values.

That looks alright to me, the offset and scale values match the
converted values in the manual, and the rest looks indeed the same as
used on the H6.

> Signed-off-by: Maxim Kiselev <bigunclemax at gmail.com>

Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Thanks,
Andre

> ---
>  drivers/thermal/sun8i_thermal.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> index f989b55a8aa8..6a8e386dbc8d 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -606,6 +606,18 @@ static const struct ths_thermal_chip sun50i_h6_ths = {
>  	.calc_temp = sun8i_ths_calc_temp,
>  };
>  
> +static const struct ths_thermal_chip sun20i_d1_ths = {
> +	.sensor_num = 1,
> +	.has_bus_clk_reset = true,
> +	.offset = 188552,
> +	.scale = 673,
> +	.temp_data_base = SUN50I_H6_THS_TEMP_DATA,
> +	.calibrate = sun50i_h6_ths_calibrate,
> +	.init = sun50i_h6_thermal_init,
> +	.irq_ack = sun50i_h6_irq_ack,
> +	.calc_temp = sun8i_ths_calc_temp,
> +};
> +
>  static const struct of_device_id of_ths_match[] = {
>  	{ .compatible = "allwinner,sun8i-a83t-ths", .data = &sun8i_a83t_ths },
>  	{ .compatible = "allwinner,sun8i-h3-ths", .data = &sun8i_h3_ths },
> @@ -614,6 +626,7 @@ static const struct of_device_id of_ths_match[] = {
>  	{ .compatible = "allwinner,sun50i-a100-ths", .data = &sun50i_a100_ths },
>  	{ .compatible = "allwinner,sun50i-h5-ths", .data = &sun50i_h5_ths },
>  	{ .compatible = "allwinner,sun50i-h6-ths", .data = &sun50i_h6_ths },
> +	{ .compatible = "allwinner,sun20i-d1-ths", .data = &sun20i_d1_ths },
>  	{ /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, of_ths_match);



From andre.przywara at arm.com  Sun Dec 17 17:09:26 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 18 Dec 2023 01:09:26 +0000
Subject: [PATCH v6 3/3] riscv: dts: allwinner: d1: Add thermal sensor
In-Reply-To: <20231217210629.131486-4-bigunclemax@gmail.com>
References: <20231217210629.131486-1-bigunclemax@gmail.com>
	<20231217210629.131486-4-bigunclemax@gmail.com>
Message-ID: <20231218010926.10e15c57@minigeek.lan>

On Mon, 18 Dec 2023 00:06:24 +0300
Maksim Kiselev <bigunclemax at gmail.com> wrote:

Hi,

> From: Maxim Kiselev <bigunclemax at gmail.com>
> 
> This patch adds a thermal sensor controller node for the D1/T113s.
> Also it adds a THS calibration data cell to efuse node.
> 
> Signed-off-by: Maxim Kiselev <bigunclemax at gmail.com>
> ---
>  .../boot/dts/allwinner/sunxi-d1s-t113.dtsi      | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
> index 5a9d7f5a75b4..6f5427d9cfbf 100644
> --- a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
> +++ b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
> @@ -166,6 +166,19 @@ gpadc: adc at 2009000 {
>  			#io-channel-cells = <1>;
>  		};
>  
> +		ths: thermal-sensor at 2009400 {
> +			compatible = "allwinner,sun20i-d1-ths";
> +			reg = <0x02009400 0x400>;
> +			interrupts = <SOC_PERIPHERAL_IRQ(58) IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_BUS_THS>;
> +			clock-names = "bus";
> +			resets = <&ccu RST_BUS_THS>;
> +			nvmem-cells = <&ths_calibration>;
> +			nvmem-cell-names = "calibration";
> +			status = "disabled";

Any reason this is disabled? We typically don't disable those internal
devices in the SoC .dtsi, the THS is one example (check the instances
in other SoCs' .dtsi files).

The rest looks alright, compared to the manual, so with this line
removed:

Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Cheers,
Andre

> +			#thermal-sensor-cells = <0>;
> +		};
> +
>  		dmic: dmic at 2031000 {
>  			compatible = "allwinner,sun20i-d1-dmic",
>  				     "allwinner,sun50i-h6-dmic";
> @@ -415,6 +428,10 @@ sid: efuse at 3006000 {
>  			reg = <0x3006000 0x1000>;
>  			#address-cells = <1>;
>  			#size-cells = <1>;
> +
> +			ths_calibration: thermal-sensor-calibration at 14 {
> +				reg = <0x14 0x4>;
> +			};
>  		};
>  
>  		crypto: crypto at 3040000 {



From lihuisong at huawei.com  Sun Dec 17 18:15:41 2023
From: lihuisong at huawei.com (lihuisong (C))
Date: Mon, 18 Dec 2023 10:15:41 +0800
Subject: [PATCH] cpufreq: CPPC: Resolve the large frequency discrepancy
 from cpuinfo_cur_freq
In-Reply-To: <486f8563-42b7-a049-97a2-bc0b553926aa@huawei.com>
References: <20231212072617.14756-1-lihuisong@huawei.com>
 <CAJZ5v0jwW0=8cNvC-Vu_o+pEHFpN9nrPD4LXCpmSTgQBTHODgg@mail.gmail.com>
 <486f8563-42b7-a049-97a2-bc0b553926aa@huawei.com>
Message-ID: <26ba9fa9-7871-27c3-0de5-62f61071dacd@huawei.com>


? 2023/12/15 10:41, lihuisong (C) ??:
> Hi Rafael,
>
> Thanks for your review.?
>
> ? 2023/12/15 3:31, Rafael J. Wysocki ??:
>> On Tue, Dec 12, 2023 at 8:26?AM Huisong Li <lihuisong at huawei.com> wrote:
>>> Many developers found that the cpu current frequency is greater than
>>> the maximum frequency of the platform, please see [1], [2] and [3].
>>>
>>> In the scenarios with high memory access pressure, the patch [1] has
>>> proved the significant latency of cpc_read() which is used to obtain
>>> delivered and reference performance counter cause an absurd frequency.
>>> The sampling interval for this counters is very critical and is 
>>> expected
>>> to be equal. However, the different latency of cpc_read() has a direct
>>> impact on their sampling interval.
>>>
>>> This patch adds a interface, cpc_read_arch_counters_on_cpu, to read
>>> delivered and reference performance counter together. According to my
>>> test[4], the discrepancy of cpu current frequency in the scenarios with
>>> high memory access pressure is lower than 0.2% by stress-ng 
>>> application.
>>>
>>> [1] 
>>> https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4 at huawei.com/
>>> [2] 
>>> https://lore.kernel.org/all/20230328193846.8757-1-yang at os.amperecomputing.com/
>>> [3] 
>>> https://lore.kernel.org/all/20230418113459.12860-7-sumitg at nvidia.com/
>>>
>>> [4] My local test:
>>> The testing platform enable SMT and include 128 logical CPU in total,
>>> and CPU base frequency is 2.7GHz. Reading "cpuinfo_cur_freq" for each
>>> physical core on platform during the high memory access pressure from
>>> stress-ng, and the output is as follows:
>>> ?? 0: 2699133???? 2: 2699942???? 4: 2698189???? 6: 2704347
>>> ?? 8: 2704009??? 10: 2696277??? 12: 2702016??? 14: 2701388
>>> ? 16: 2700358??? 18: 2696741??? 20: 2700091??? 22: 2700122
>>> ? 24: 2701713??? 26: 2702025??? 28: 2699816??? 30: 2700121
>>> ? 32: 2700000??? 34: 2699788??? 36: 2698884??? 38: 2699109
>>> ? 40: 2704494??? 42: 2698350??? 44: 2699997??? 46: 2701023
>>> ? 48: 2703448??? 50: 2699501??? 52: 2700000??? 54: 2699999
>>> ? 56: 2702645??? 58: 2696923??? 60: 2697718??? 62: 2700547
>>> ? 64: 2700313??? 66: 2700000??? 68: 2699904??? 70: 2699259
>>> ? 72: 2699511??? 74: 2700644??? 76: 2702201??? 78: 2700000
>>> ? 80: 2700776??? 82: 2700364??? 84: 2702674??? 86: 2700255
>>> ? 88: 2699886??? 90: 2700359??? 92: 2699662??? 94: 2696188
>>> ? 96: 2705454??? 98: 2699260?? 100: 2701097?? 102: 2699630
>>> 104: 2700463?? 106: 2698408?? 108: 2697766?? 110: 2701181
>>> 112: 2699166?? 114: 2701804?? 116: 2701907?? 118: 2701973
>>> 120: 2699584?? 122: 2700474?? 124: 2700768?? 126: 2701963
>>>
>>> Signed-off-by: Huisong Li <lihuisong at huawei.com>
>> First off, please Cc ACPI-related patches to linux-acpi.
>
> got it.
>
> +linux-acpi at vger.kernel.org
>
>>
>>> ---
>>> ? arch/arm64/kernel/topology.c | 43 
>>> ++++++++++++++++++++++++++++++++++--
>>> ? drivers/acpi/cppc_acpi.c???? | 22 +++++++++++++++---
>>> ? include/acpi/cppc_acpi.h???? |? 5 +++++
>>> ? 3 files changed, 65 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm64/kernel/topology.c 
>>> b/arch/arm64/kernel/topology.c
>>> index 7d37e458e2f5..c3122154d738 100644
>>> --- a/arch/arm64/kernel/topology.c
>>> +++ b/arch/arm64/kernel/topology.c
>>> @@ -299,6 +299,11 @@ core_initcall(init_amu_fie);
>>> ? #ifdef CONFIG_ACPI_CPPC_LIB
>>> ? #include <acpi/cppc_acpi.h>
>>>
>>> +struct amu_counters {
>>> +?????? u64 corecnt;
>>> +?????? u64 constcnt;
>>> +};
>>> +
>>> ? static void cpu_read_corecnt(void *val)
>>> ? {
>>> ???????? /*
>>> @@ -322,8 +327,27 @@ static void cpu_read_constcnt(void *val)
>>> ?????????????????????? 0UL : read_constcnt();
>>> ? }
>>>
>>> +static void cpu_read_amu_counters(void *data)
>>> +{
>>> +?????? struct amu_counters *cnt = (struct amu_counters *)data;
>>> +
>>> +?????? /*
>>> +??????? * The running time of the this_cpu_has_cap() might have a 
>>> couple of
>>> +??????? * microseconds and is significantly increased to tens of 
>>> microseconds.
>>> +??????? * But AMU core and constant counter need to be read togeter 
>>> without any
>>> +??????? * time interval to reduce the calculation discrepancy using 
>>> this counters.
>>> +??????? */
>>> +?????? if (this_cpu_has_cap(ARM64_WORKAROUND_2457168)) {
>>> +?????????????? cnt->corecnt = read_corecnt();
>> This statement is present in both branches, so can it be moved before 
>> the if ()?
> Yes.
> Do you mean adding a blank line before if()?
Sorry, I misunderstood you.
The statement "cnt->corecnt = read_corecnt();" cannot be moved before 
the if().
The AMU core and constant counter need to be read togeter without any 
time interval as described in code comments.
The this_cpu_has_cap() is time-consuming.
That is why I don't use the cpu_read_constcnt() to read constant counter.
>>
>>> +?????????????? cnt->constcnt = 0;
>>> +?????? } else {
>>> +?????????????? cnt->corecnt = read_corecnt();
>>> +?????????????? cnt->constcnt = read_constcnt();
>>> +?????? }
>>> +}
>>> +
>>> ? static inline
>>> -int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
>>> +int counters_read_on_cpu(int cpu, smp_call_func_t func, void *data)
>>> ? {
>>> ???????? /*
>>> ????????? * Abort call on counterless CPU or when interrupts are
>>> @@ -335,7 +359,7 @@ int counters_read_on_cpu(int cpu, 
>>> smp_call_func_t func, u64 *val)
>>> ???????? if (WARN_ON_ONCE(irqs_disabled()))
>>> ???????????????? return -EPERM;
>>>
>>> -?????? smp_call_function_single(cpu, func, val, 1);
>>> +?????? smp_call_function_single(cpu, func, data, 1);
>>>
>>> ???????? return 0;
>>> ? }
>>> @@ -364,6 +388,21 @@ bool cpc_ffh_supported(void)
>>> ???????? return true;
>>> ? }
>>>
>>> +int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, u64 
>>> *reference)
>>> +{
>>> +?????? struct amu_counters cnts = {0};
>>> +?????? int ret;
>>> +
>>> +?????? ret = counters_read_on_cpu(cpu, cpu_read_amu_counters, &cnts);
>>> +?????? if (ret)
>>> +?????????????? return ret;
>>> +
>>> +?????? *delivered = cnts.corecnt;
>>> +?????? *reference = cnts.constcnt;
>>> +
>>> +?????? return 0;
>>> +}
>>> +
>>> ? int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64 *val)
>>> ? {
>>> ???????? int ret = -EOPNOTSUPP;
>>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
>>> index 7ff269a78c20..f303fabd7cfe 100644
>>> --- a/drivers/acpi/cppc_acpi.c
>>> +++ b/drivers/acpi/cppc_acpi.c
>>> @@ -1299,6 +1299,11 @@ bool cppc_perf_ctrs_in_pcc(void)
>>> ? }
>>> ? EXPORT_SYMBOL_GPL(cppc_perf_ctrs_in_pcc);
>>>
>>> +int __weak cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, 
>>> u64 *reference)
>>> +{
>>> +?????? return 0;
>>> +}
>>> +
>>> ? /**
>>> ?? * cppc_get_perf_ctrs - Read a CPU's performance feedback counters.
>>> ?? * @cpunum: CPU from which to read counters.
>>> @@ -1313,7 +1318,8 @@ int cppc_get_perf_ctrs(int cpunum, struct 
>>> cppc_perf_fb_ctrs *perf_fb_ctrs)
>>> ???????????????? *ref_perf_reg, *ctr_wrap_reg;
>>> ???????? int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpunum);
>>> ???????? struct cppc_pcc_data *pcc_ss_data = NULL;
>>> -?????? u64 delivered, reference, ref_perf, ctr_wrap_time;
>>> +?????? u64 delivered = 0, reference = 0;
>>> +?????? u64 ref_perf, ctr_wrap_time;
>>> ???????? int ret = 0, regs_in_pcc = 0;
>>>
>>> ???????? if (!cpc_desc) {
>>> @@ -1350,8 +1356,18 @@ int cppc_get_perf_ctrs(int cpunum, struct 
>>> cppc_perf_fb_ctrs *perf_fb_ctrs)
>>> ???????????????? }
>>> ???????? }
>>>
>>> -?????? cpc_read(cpunum, delivered_reg, &delivered);
>>> -?????? cpc_read(cpunum, reference_reg, &reference);
>>> +?????? if (cpc_ffh_supported()) {
>>> +?????????????? ret = cpc_read_arch_counters_on_cpu(cpunum, 
>>> &delivered, &reference);
>>> +?????????????? if (ret) {
>>> +?????????????????????? pr_debug("read arch counters failed, 
>>> ret=%d.\n", ret);
>>> +?????????????????????? ret = 0;
>>> +?????????????? }
>>> +?????? }
>> The above is surely not applicable to every platform using CPPC.? Also
>
> cpc_ffh_supported is aimed to control only the platform supported FFH 
> to enter.
> cpc_read_arch_counters_on_cpu is also needed to implemented by each 
> platform according to their require.
> Here just implement this interface for arm64.
>
>> it looks like in the ARM64_WORKAROUND_2457168 enabled case it is just
>> pointless overhead, because "reference" is always going to be 0 here
>> then.
> Right, it is always going to be 0 here for the 
> ARM64_WORKAROUND_2457168 enabled case .
> But ARM64_WORKAROUND_2457168 is a macro releated to ARM.
> It seems that it is not appropriate for this macro to appear this 
> common place for all platform, right?
>
>>
>> Please clean that up.
>>
>>> +?????? if (!delivered || !reference) {
>>> +?????????????? cpc_read(cpunum, delivered_reg, &delivered);
>>> +?????????????? cpc_read(cpunum, reference_reg, &reference);
>>> +?????? }
>>> +
>>> ???????? cpc_read(cpunum, ref_perf_reg, &ref_perf);
>>>
>>> ???????? /*
>>> diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
>>> index 6126c977ece0..07d4fd82d499 100644
>>> --- a/include/acpi/cppc_acpi.h
>>> +++ b/include/acpi/cppc_acpi.h
>>> @@ -152,6 +152,7 @@ extern bool cpc_ffh_supported(void);
>>> ? extern bool cpc_supported_by_cpu(void);
>>> ? extern int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val);
>>> ? extern int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val);
>>> +extern int cpc_read_arch_counters_on_cpu(int cpu, u64 *delivered, 
>>> u64 *reference);
>>> ? extern int cppc_get_epp_perf(int cpunum, u64 *epp_perf);
>>> ? extern int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls 
>>> *perf_ctrls, bool enable);
>>> ? extern int cppc_get_auto_sel_caps(int cpunum, struct 
>>> cppc_perf_caps *perf_caps);
>>> @@ -209,6 +210,10 @@ static inline int cpc_write_ffh(int cpunum, 
>>> struct cpc_reg *reg, u64 val)
>>> ? {
>>> ???????? return -ENOTSUPP;
>>> ? }
>>> +static inline int cpc_read_arch_counters_on_cpu(int cpu, u64 
>>> *delivered, u64 *reference)
>>> +{
>>> +?????? return -EOPNOTSUPP;
>>> +}
>>> ? static inline int cppc_set_epp_perf(int cpu, struct 
>>> cppc_perf_ctrls *perf_ctrls, bool enable)
>>> ? {
>>> ???????? return -ENOTSUPP;
>>> -- 
>> .
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From kw at linux.com  Sun Dec 17 18:23:19 2023
From: kw at linux.com (Krzysztof =?utf-8?Q?Wilczy=C5=84ski?=)
Date: Mon, 18 Dec 2023 11:23:19 +0900
Subject: [PATCH -next] PCI: xilinx-xdma: Remove redundant dev_err()
In-Reply-To: <20231030061242.51475-1-yang.lee@linux.alibaba.com>
References: <20231030061242.51475-1-yang.lee@linux.alibaba.com>
Message-ID: <20231218022319.GC88933@rocinante>

Hello,

> There is no need to call the dev_err() function directly to print a
> custom message when handling an error from either the platform_get_irq()
> or platform_get_irq_byname() functions as both are going to display an
> appropriate error message in case of a failure.
> 
> ./drivers/pci/controller/pcie-xilinx-dma-pl.c:688:2-9: line 688 is redundant because platform_get_irq() already prints an error
> ./drivers/pci/controller/pcie-xilinx-dma-pl.c:702:2-9: line 702 is redundant because platform_get_irq() already prints an error

Applied to controller/xilinx, thank you!

[1/1] PCI: xilinx-xdma: Remove redundant dev_err()
      https://git.kernel.org/pci/pci/c/b642e081f46c

	Krzysztof


From xu.yang_2 at nxp.com  Sun Dec 17 18:16:58 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 18 Dec 2023 02:16:58 +0000
Subject: [EXT] Re: [PATCH 3/4] arm64: dts: imx93: add usb nodes
In-Reply-To: <3198956.5fSG56mABF@steina-w>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
 <8309719.T7Z3S40VBb@steina-w>
 <DB7PR04MB51462A079F226C6B9FCA9F7C8C93A@DB7PR04MB5146.eurprd04.prod.outlook.com>
 <3198956.5fSG56mABF@steina-w>
Message-ID: <DB7PR04MB51466B73F7D753BB1C662FA98C90A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Alexander,

>
> Hi,
>
> Am Freitag, 15. Dezember 2023, 03:12:43 CET schrieb Xu Yang:
> > Hi Alexander,
> >
> > > Hi,
> > >
> > > thanks for the patch.
> > >
> > > Am Donnerstag, 14. Dezember 2023, 12:24:41 CET schrieb Xu Yang:
> > > > There are 2 USB controllers on i.MX93. Add them.
> > > >
> > > > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> > > > ---
> > > >
> > > >  arch/arm64/boot/dts/freescale/imx93.dtsi | 58 ++++++++++++++++++++++++
> > > >  1 file changed, 58 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi
> > > > b/arch/arm64/boot/dts/freescale/imx93.dtsi index
> > > > 34c0540276d1..bcf4861cfede
> > > > 100644
> > > > --- a/arch/arm64/boot/dts/freescale/imx93.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
> > > > @@ -171,6 +171,20 @@ cm33: remoteproc-cm33 {
> > > >
> > > >               status = "disabled";
> > > >
> > > >       };
> > > >
> > > > +     usbphynop1: usbphynop1 {
> > > > +             #phy-cells = <0>;
> > > > +             compatible = "usb-nop-xceiv";
> > >
> > > compatible first.
> >
> > Okay.
> >
> > > > +             clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> > > > +             clock-names = "main_clk";
> > > > +     };
> > > > +
> > > > +     usbphynop2: usbphynop2 {
> > > > +             #phy-cells = <0>;
> > > > +             compatible = "usb-nop-xceiv";
> > >
> > > compatible first.
> >
> > Okay.
> >
> > > > +             clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> > > > +             clock-names = "main_clk";
> > > > +     };
> > > > +
> > > >
> > > >       soc at 0 {
> > > >
> > > >               compatible = "simple-bus";
> > > >               #address-cells = <1>;
> > > >
> > > > @@ -1059,5 +1073,49 @@ ddr-pmu at 4e300dc0 {
> > > >
> > > >                       reg = <0x4e300dc0 0x200>;
> > > >                       interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
> > > >
> > > >               };
> > > >
> > > > +
> > > > +             usbotg1: usb at 4c100000 {
> > > > +                     compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb",
> > >
> > > "fsl,imx27-usb";
> > >
> > > > +                     reg = <0x4c100000 0x200>;
> > > > +                     interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
> > > > +                     clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> > > > +                              <&clk IMX93_CLK_HSIO_32K_GATE>;
> > > > +                     clock-names = "usb_ctrl_root_clk",
> > >
> > > "usb_wakeup_clk";
> > >
> > > drivers/usb/chipidea/ci_hdrc_imx.c uses 3 clocks: "ipg", "ahb" and "per",
> > > see imx_get_clks(). How is this supposed to work?
> >
> > I have sent another patch to get this clock.
> >
> https://lore.kernel.org/all/20231214112622.2412321-
> 1-
> xu.yang_2%40nxp.com%2F&data=05%7C02%7Cxu.yang_2%40nxp.com%7Cbdf207787e9f448553f808dbfd379cda%7C686ea1
> d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638382187526271036%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FkQ5Cf4iYfCPj79ZnR5XxshIdkWeLOyV
> 8tmWYWnh2GU%3D&reserved=0
>
> Okay, but that adds another clock which is not mentioned in Documentation/
> devicetree/bindings/usb/ci-hdrc-usb2.yaml at all. I guess some compatible-
> specific constraints regarding number of clocks should be added.

Right, will try to add such info.

Thanks,
Xu Yang

>
> Best regards,
> Alexander
>
> >
> > > > +                     assigned-clocks = <&clk IMX93_CLK_HSIO>;
> > > > +                     assigned-clock-parents = <&clk
> > >
> > > IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> > >
> > > > +                     assigned-clock-rates = <133000000>;
> > > > +                     fsl,usbphy = <&usbphynop1>;
> > > > +                     fsl,usbmisc = <&usbmisc1 0>;
> > > > +                     status = "disabled";
> > > > +             };
> > > > +
> > > > +             usbmisc1: usbmisc at 4c100200 {
> > > > +                     compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-
> > >
> > > usbmisc",
> > >
> > > > +                                     "fsl,imx6q-usbmisc";
> > >
> > > This means you are compatible to fsl,imx7d-usbmisc. Which means you use
> > > register MX7D_USB_OTG_PHY_STATUS in USB misc (USBNC). But i.MX93 RM Rev. 2
> > > (04/2023) lacks this and other registers.
> >
> > Some registers in USBNC are not shown. The internal RM has these registers.
> >
> > > > +                     #index-cells = <1>;
> > > > +                     reg = <0x4c100200 0x200>;
> > >
> > > reg after compatible.
> >
> > Okay.
> >
> > > > +             };
> > > > +
> > > > +             usbotg2: usb at 4c200000 {
> > > > +                     compatible = "fsl,imx8mm-usb", "fsl,imx7d-usb",
> > >
> > > "fsl,imx27-usb";
> > >
> > > > +                     reg = <0x4c200000 0x200>;
> > > > +                     interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
> > > > +                     clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> > > > +                              <&clk IMX93_CLK_HSIO_32K_GATE>;
> > > > +                     clock-names = "usb_ctrl_root_clk",
> > >
> > > "usb_wakeup_clk";
> > >
> > > The same as for usbotg1 applies here.
> >
> > Okay.
> >
> > > > +                     assigned-clocks = <&clk IMX93_CLK_HSIO>;
> > > > +                     assigned-clock-parents = <&clk
> > >
> > > IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> > >
> > > > +                     assigned-clock-rates = <133000000>;
> > > > +                     fsl,usbphy = <&usbphynop2>;
> > > > +                     fsl,usbmisc = <&usbmisc2 0>;
> > > > +                     status = "disabled";
> > > > +             };
> > > > +
> > > > +             usbmisc2: usbmisc at 4c200200 {
> > > > +                     compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-
> > >
> > > usbmisc",
> > >
> > > > +                                     "fsl,imx6q-usbmisc";
> > > > +                     #index-cells = <1>;
> > > > +                     reg = <0x4c200200 0x200>;
> > >
> > > The same as for usbmisc1 applies here.
> >
> > Okay.
> >
> > > > +             };
> > > >
> > > >       };
> > > >
> > > >  };
> > >
> > > Best regards,
> > > Alexander
> > >
> > > --
> > > TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
> > > Amtsgericht M?nchen, HRB 105018
> > > Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
> > > http://www.tq-/
> %2F&data=05%7C02%7Cxu.yang_2%40nxp.com%7Cbdf207787e9f448553f808dbfd379cda%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C638382187526271036%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UywLIIbPswQULh%2FLuAJ7xdVbGCGSDjeOSW%2B%2B%2F
> 2M2qgM%3D&reserved=0
> > > group.com%2F&data=05%7C02%7Cxu.yang_2%40nxp.com%7C10ff5a35f53f4047ae1d08db
> > > fca99c38%7C686ea1d3bc2b4c6fa
> > > 92cd99c5c301635%7C0%7C0%7C638381577622080432%7CUnknown%7CTWFpbGZsb3d8eyJW
> > > IjoiMC4wLjAwMDAiLCJQIjoiV2
> > > luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VlpRPcnJTmywfS
> > > amaGB1Ev8aPN2Hi596VbbRNGXF yis%3D&reserved=0
>
>
> --
> TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht M?nchen, HRB 105018
> Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
> http://www.tq-/
> group.com%2F&data=05%7C02%7Cxu.yang_2%40nxp.com%7Cbdf207787e9f448553f808dbfd379cda%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C638382187526271036%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BhTDWMHhsHOxFkAyQh%2FtsuGV523FFNPeKi
> FZ7b0APnc%3D&reserved=0
>



From laurent.pinchart at ideasonboard.com  Sun Dec 17 18:36:55 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 18 Dec 2023 04:36:55 +0200
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <CAOMZO5B2bWVciDEwSh+YQWu6b_Hp5ijk6Jq-bMePPTDRJ-vHFA@mail.gmail.com>
References: <20230920171009.3193296-1-l.stach@pengutronix.de>
 <20230920171009.3193296-2-l.stach@pengutronix.de>
 <20230920205736.GB7723@pendragon.ideasonboard.com>
 <CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>
 <CAOMZO5C7_Rj-Ja0BO0D0Po+gy+XbvyMdQf-wH5YNyhAdMof2vg@mail.gmail.com>
 <20231215142308.GL21146@pendragon.ideasonboard.com>
 <CAHCN7xJPg_Nk=o9fKwkZfVTNSB-YL0m7vY6p1O7+i=PHShp7hg@mail.gmail.com>
 <CAOMZO5AGAkPpds=5H-iQj53djcQtW5GsRQrzdC_JOOrcENhvvw@mail.gmail.com>
 <CAHCN7xLHMGcS2-QTneqqpHYU66JwuEG4TyR0j0riFGqO6RC8ug@mail.gmail.com>
 <CAOMZO5B2bWVciDEwSh+YQWu6b_Hp5ijk6Jq-bMePPTDRJ-vHFA@mail.gmail.com>
Message-ID: <20231218023655.GG5290@pendragon.ideasonboard.com>

On Fri, Dec 15, 2023 at 05:09:41PM -0300, Fabio Estevam wrote:
> On Fri, Dec 15, 2023 at 4:01?PM Adam Ford <aford173 at gmail.com> wrote:
> 
> > Thanks for the list.  I was able to successfully build the stable 6.6
> > branch with those patches applied and I have the HDMI working.
> > Unfortunately, I get build errors on the linux-next, so it's going to
> > take me a little time to sort through all of this.
> 
> If you need help to figure this problem out, please let me know.
> 
> I haven't tried it against linux-next.
> 
> > I am thinking that it would be better to consolidate all these
> > together into one series instead of piecemealing it.  However, there
> > are some items that can be submitted right away without significantly
> > reworking them against linux-next.  Do people have a preference?
> 
> I think it makes sense to re-submit the "easy ones" right away.

Agreed. The more we can merge quickly, the easier it will become to
rebase and upstream the rest.

-- 
Regards,

Laurent Pinchart


From yoong.siang.song at intel.com  Sun Dec 17 18:54:11 2023
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Mon, 18 Dec 2023 02:54:11 +0000
Subject: [xdp-hints] Re: [PATCH bpf-next v3 2/3] net: stmmac: add Launch
 Time support to XDP ZC
In-Reply-To: <ZXDGHThTynXbSTJG@google.com>
References: <20231203165129.1740512-1-yoong.siang.song@intel.com>
 <20231203165129.1740512-3-yoong.siang.song@intel.com>
 <43b01013-e78b-417e-b169-91909c7309b1@kernel.org>
 <656de830e8d70_2e983e294ca@willemb.c.googlers.com.notmuch>
 <PH0PR11MB583000826591093B98BA841DD885A@PH0PR11MB5830.namprd11.prod.outlook.com>
 <5a0faf8cc9ec3ab0d5082c66b909c582c8f1eae6.camel@siemens.com>
 <CAKH8qBuXL8bOYtfKKPS8y=KJqouDptyciCjr0wNKVHtNj6BmqA@mail.gmail.com>
 <656f66023f7bd_3dd6422942a@willemb.c.googlers.com.notmuch>
 <ZW98UW033wCy9vI-@google.com>
 <CAJ8uoz3_XqavGt1DyFoQAuKS8Faa1Lc85b2t+whc-f6GN1Pvzw@mail.gmail.com>
 <ZXDGHThTynXbSTJG@google.com>
Message-ID: <PH0PR11MB58304128E1F6FCE3A2F0D0C2D890A@PH0PR11MB5830.namprd11.prod.outlook.com>

Hi all,

Fyi, I submitted a patch [1] to enable tx metadata for igc driver as a preparation to add launch time to it.
After the patch is accepted, I will include igc driver in next version of launch time patch set.

[1] https://patchwork.kernel.org/project/netdevbpf/patch/20231215162158.951925-1-yoong.siang.song at intel.com/

Thanks & Regards
Siang

From leo.yan at linaro.org  Sun Dec 17 19:21:01 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 18 Dec 2023 11:21:01 +0800
Subject: [PATCH V2 3/5] perf mem: Clean up perf_mem_events__name()
In-Reply-To: <CAP-5=fVGoQbaUmDqr8CmoRT3Wx=Pp7TtmWuwvXrvEeGw5eannA@mail.gmail.com>
References: <20231207192338.400336-1-kan.liang@linux.intel.com>
 <20231207192338.400336-4-kan.liang@linux.intel.com>
 <20231209054809.GB2116834@leoy-yangtze.lan>
 <3b67c2de-741d-4d5e-8c8f-87b8b9e08825@linux.intel.com>
 <20231213133336.GA3895246@leoy-yangtze.lan>
 <CAP-5=fVGoQbaUmDqr8CmoRT3Wx=Pp7TtmWuwvXrvEeGw5eannA@mail.gmail.com>
Message-ID: <20231218032101.GA18177@leoy-huanghe.lan>

Hi Ian,

On Wed, Dec 13, 2023 at 09:33:24AM -0800, Ian Rogers wrote:

Sorry for late response due to I took a leave at end of last week.

[...]

> > > The purpose of this cleanup patch set is to remove the unnecessary
> > > __weak functions, and try to make the code more generic.
> >
> > I understand weak functions are not very good practice.  The point is
> > weak functions are used for some archs have implemented a feature but
> > other archs have not.
> >
> > I can think a potential case to use a central place to maintain the
> > code for all archs - when we want to support cross analysis.  But this
> > patch series is for supporting cross analysis, to be honest, I still
> > don't see benefit for this series, though I know you might try to
> > support hybrid modes.
> 
> So thanks to Kan for doing this series and trying to clean the code
> up. My complaint about the code is that it was overly hard wired.
> Heck, we have event strings to parse that hard code PMU and event
> names. In fixing hybrid my complaint was that we were adding yet more
> complexity and as a lot of this was resting on printf format strings
> it was hard to check that these were being used correctly. The
> direction of this patch series I agree with.

I agreed as well ;)

> Imo we should avoid weak definitions. Weak definitions are outside of
> the C specification and have introduced bugs into the code base -
> specifically a weak const array was having its size propagated into
> code but then the linker later replaced that weak array. An
> architecture #ifdef is better than a weak definition as the behavior
> is defined and things blow up early rather than suffering from subtle
> corruptions.

Thanks a lot for sharing.

> The Linux kernel device driver is abstracting what the hardware is
> doing and since the more recent changes the PMU abstraction in the
> perf tool is trying to match that. If we need to interface with PMUs
> differently on each architecture then something is wrong. It happens
> that things are wrong and we need to work with that. For example, on
> intel there are topdown events that introduce ordering issues. We have
> default initialization functions for different PMUs. The perf_pmu
> struct is created in perf_pmu__lookup and that always calls an
> perf_pmu__arch_init where the name of the PMU is already set. In the
> weak perf_pmu__arch_init we tweak the perf_pmu struct so that it will
> behave correctly elsewhere in the code. These changes are paralleling
> that. That said, the Intel perf_pmu__arch_init does strcmps against
> "intel_pt" and "intel_bts", does it really need to be arch specific
> given it is already PMU specific?

To be clear, I don't object refactoring, I am just wandering if have
better approach.

Your above question is a good point. I admit the implementation in
arch's perf_pmu__arch_init() is not a good practice, IIUC, you are
seeking an general approach for dynamically probing PMU (and the
associated events).

What I can think about is using the static linked PMU descriptor +
init callback function, which is widely used in Linux kernel for
machine's initialization (refer to [1]).

Likewise, we can define a descriptor for every PMU and link the
descriptor into a data section, e.g.:

  static const struct perf_pmu __intel_pt_pmu
  __section(".pmu.info.init") = {
        .name = "intel_pt",
        .auxtrace = true,
        .selectable = true,
        .perf_event_attr_init_default = intel_pt_pmu_default_config,
        .mem_events = NULL,
        ...
  }

As a result, perf_pmu__lookup() just iterates the descriptor array
stored in the data section ".pmu.info.init".  To support more complex
case, we even can add a callback pointer in the structure perf_pmu to
invoke PMU specific initialization.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/include/asm/mach/arch.h#n78

> A situation we see in testing is
> people trying to run user space ISA emulators like qemu, say ARM on
> x86, should the PMU set up for intel_pt and intel_bts be broken in
> this environment?

This is a good case, also is a complex case.

> I think that as the names are very specific I'd
> prefer if the code were outside of the tools/perf/arch directory.

I am not sure if understand your meaning.

Anyway, let me extend a bit with this patch series. For instance,
perf_pmu__mem_events_name() function as a central place generates memory
event naming for different archs (and even with different attributes).
This leads to architecture specific things are maintained in perf core
layer.

Rather than adding a data pointer '.mem_events' in to struct perf_pmu,
I'd like to add a new callback (say .mem_event_init()) into struct
perf_pmu, this function can return back the memory event string.

In the end, we can de-couple the perf core layer with arch specific
codes - and if we really want to support cross runtime case (e.g. Arm
binary on x86 machine), we can connect with linked descriptor as
mentioned above.

> There are cases with PMU names like "cpu" where we're probably going
> to need ifdefs or runtime is_intel() calls.
> 
> Anyway, my point is that I think we should be moving away from arch
> specific stuff, as this patch series tries, and that way we have the
> best chance of changes benefitting users regardless of hardware.

To be clear, I agree it's great if we can build in all archs into single
perf binary for support cross runtime.

On the other hand, I don't think it's a good idea to totally remove arch
folders.

> It may be that to make all of this work properly we need to modify PMUs,
> but that all seems good, such as adding the extended type support for
> legacy events on ARM PMUs so that legacy events can work without a
> fixed CPU. We haven't got core PMUs working properly, see the recent
> perf top hybrid problem. There are obviously issues with uncore as,
> for example, most memory controllers are replicated PMUs but some
> kernel perf drivers select a memory controller via a config value. We
> either need to change the drivers for some kind of uniformity or do
> some kind of abstracting in the perf tool. I think we'll probably need
> to do it in the tool and when doing that we really shouldn't be doing
> it in an arch specific or weak function way.

Thanks for bringing up.  Now I understand a bit your concerns.

Leo


From s-vadapalli at ti.com  Sun Dec 17 20:30:34 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 18 Dec 2023 10:00:34 +0530
Subject: [PATCH v2 3/4] dmaengine: ti: k3-udma-glue: Add function to
 request TX channel by ID
In-Reply-To: <604657b5-0b88-4108-afd3-8cc88e10b16c@gmail.com>
References: <20231212111011.1401641-1-s-vadapalli@ti.com>
 <20231212111011.1401641-4-s-vadapalli@ti.com>
 <800ccf2e-65cc-4524-8a42-1657a5906482@gmail.com>
 <4f13681a-dc13-4de2-a0d5-9f85a4c350d4@ti.com>
 <604657b5-0b88-4108-afd3-8cc88e10b16c@gmail.com>
Message-ID: <cb93763e-28d3-402a-a5fa-34936646bc0a@ti.com>



On 17/12/23 16:48, P?ter Ujfalusi wrote:
> 
> 
> On 15/12/2023 08:08, Siddharth Vadapalli wrote:
>>>>  err:
>>>> @@ -395,6 +410,40 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
>>>>  }
>>>>  EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn);
>>>>  
>>>> +struct k3_udma_glue_tx_channel *
>>>> +k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg,
>>>> +				  struct device_node *udmax_np, u32 thread_id)
>>>
>>> udmax_np is not dev->of_node ?
>>
>> I am not sure I fully understand the question. If you meant to ask if the driver
>> which uses this API will not have its device's of_node set to udmax_np, then yes
>> that's correct.
>>
>> The driver shall be probed over RPMsg-bus, due to which its device's of_node
>> will not be udmax_np. Additionally, the udmax_np is the device-tree node of one
>> of the DMA Controllers described in the device-tree. The driver shall obtain the
>> reference to the udmax_np node using the API:
>> of_find_compatible_node()
>> with the compatible to be passed to the above API being a part of the driver's
>> data. Thus, it is possible to specify which DMA Controller to use by specifying
>> the compatible in the driver's data. I hope that I have answered your question.
>> Please let me know otherwise.
> 
> I see, thank you for the detailed explanation!
> 
>> Thank you for reviewing the series. I will rename the API as mentioned above and
>> if the question you had above regarding the of_node has been addressed, I will
>> post the v3 series. Kindly let me know.
> 
> I don't have other open issues, thanks for the updates
> 

Thank you for the confirmation. I will implement your suggestions and post the
v3 series.

-- 
Regards,
Siddharth.


From quic_bibekkum at quicinc.com  Sun Dec 17 21:36:27 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Mon, 18 Dec 2023 11:06:27 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
Message-ID: <6dc509ac-8f3b-40c2-bc1d-a86b76efde76@quicinc.com>



On 12/15/2023 6:24 PM, Robin Murphy wrote:
> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>
>>
>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>> <quic_bibekkum at quicinc.com> wrote:
>>>>
>>>> Add ACTLR data table for SM8550 along with support for
>>>> same including SM8550 specific implementation operations.
>>>>
>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>> ---
>>>> ? drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 
>>>> ++++++++++++++++++++++
>>>> ? 1 file changed, 89 insertions(+)
>>>>
>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
>>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>> index cb49291f5233..d2006f610243 100644
>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>> ???????? u32 actlr;
>>>> ? };
>>>>
>>>> +/*
>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the 
>>>> prefetch
>>>> + * buffer). The remaining bits are implementation defined and vary 
>>>> across
>>>> + * SoCs.
>>>> + */
>>>> +
>>>> +#define PREFETCH_DEFAULT?????? 0
>>>> +#define PREFETCH_SHALLOW?????? BIT(8)
>>>> +#define PREFETCH_MODERATE????? BIT(9)
>>>> +#define PREFETCH_DEEP????????? (BIT(9) | BIT(8))
>>>
>>> I thin the following might be more correct:
>>>
>>> #include <linux/bitfield.h>
>>>
>>> #define PREFETCH_MASK GENMASK(9, 8)
>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>
>>
>> Ack, thanks for this suggestion. Let me try this out using
>> GENMASK. Once tested, will take care of this in next version.
> 
> FWIW the more typical usage would be to just define the named macros for 
> the raw field values, then put the FIELD_PREP() at the point of use. 
> However in this case that's liable to get pretty verbose, so although 
> I'm usually a fan of bitfield.h, the most readable option here might 
> actually be to stick with simpler definitions of "(0 << 8)", "(1 << 8)", 
> etc. However it's not really a big deal either way, and I defer to 
> whatever Dmitry and Konrad prefer, since they're the ones looking after 
> arm-smmu-qcom the most :)
> 

Agree, surely simple macros would be easy to understand the bits we are
setting/resetting, but to get good verbosity bitfield would surely be
helpful as you rightly pointed. I can see some improved suggestions form
Konrad as well in the latest reply, the way it'd be better in arm-smmu-
qcom. Will try to incorporate these inputs in next version.

Thanks,
Bibek

> Thanks,
> Robin.
> 
>>
>> Thanks,
>> Bibek
>>
>>>> +#define PREFETCH_SWITCH_GFX??? (BIT(5) | BIT(3))
>>>> +#define CPRE?????????????????? BIT(1)
>>>> +#define CMTLB????????????????? BIT(0)
>>>> +
>>>> +static const struct actlr_config sm8550_apps_actlr_cfg[] = {
>>>> +?????? { 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x0800, 0x0020, PREFETCH_DEFAULT | CMTLB },
>>>> +?????? { 0x1800, 0x00c0, PREFETCH_DEFAULT | CMTLB },
>>>> +?????? { 0x1820, 0x0000, PREFETCH_DEFAULT | CMTLB },
>>>> +?????? { 0x1860, 0x0000, PREFETCH_DEFAULT | CMTLB },
>>>> +?????? { 0x0c01, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c02, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c03, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c04, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c05, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c06, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c07, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c08, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c09, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c0c, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c0d, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c0e, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x0c0f, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1961, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1962, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1963, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1964, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1965, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1966, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1967, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1968, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1969, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x196c, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x196d, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x196e, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x196f, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19c1, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19c2, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19c3, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19c4, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19c5, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19c6, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19c7, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19c8, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19c9, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19cc, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19cd, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19ce, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x19cf, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
>>>> +?????? { 0x1c00, 0x0002, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x1c01, 0x0000, PREFETCH_DEFAULT | CMTLB },
>>>> +?????? { 0x1920, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x1923, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x1924, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x1940, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x1941, 0x0004, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x1943, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x1944, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>> +?????? {},
>>>> +};
>>>> +
>>>> +static const struct actlr_config sm8550_gfx_actlr_cfg[] = {
>>>> +?????? { 0x0000, 0x03ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE 
>>>> | CMTLB },
>>>> +?????? {},
>>>> +};
>>>> +
>>>> ? static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
>>>> ? {
>>>> ???????? return container_of(smmu, struct qcom_smmu, smmu);
>>>> @@ -549,6 +628,15 @@ static const struct qcom_smmu_match_data 
>>>> sdm845_smmu_500_data = {
>>>> ???????? /* Also no debug configuration. */
>>>> ? };
>>>>
>>>> +
>>>> +static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data 
>>>> = {
>>>> +?????? .impl = &qcom_smmu_500_impl,
>>>> +?????? .adreno_impl = &qcom_adreno_smmu_500_impl,
>>>> +?????? .cfg = &qcom_smmu_impl0_cfg,
>>>> +?????? .actlrcfg = sm8550_apps_actlr_cfg,
>>>> +?????? .actlrcfg_gfx = sm8550_gfx_actlr_cfg,
>>>> +};
>>>> +
>>>> ? static const struct qcom_smmu_match_data qcom_smmu_500_impl0_data = {
>>>> ???????? .impl = &qcom_smmu_500_impl,
>>>> ???????? .adreno_impl = &qcom_adreno_smmu_500_impl,
>>>> @@ -583,6 +671,7 @@ static const struct of_device_id __maybe_unused 
>>>> qcom_smmu_impl_of_match[] = {
>>>> ???????? { .compatible = "qcom,sm8250-smmu-500", .data = 
>>>> &qcom_smmu_500_impl0_data },
>>>> ???????? { .compatible = "qcom,sm8350-smmu-500", .data = 
>>>> &qcom_smmu_500_impl0_data },
>>>> ???????? { .compatible = "qcom,sm8450-smmu-500", .data = 
>>>> &qcom_smmu_500_impl0_data },
>>>> +?????? { .compatible = "qcom,sm8550-smmu-500", .data = 
>>>> &sm8550_smmu_500_impl0_data },
>>>> ???????? { .compatible = "qcom,smmu-500", .data = 
>>>> &qcom_smmu_500_impl0_data },
>>>> ???????? { }
>>>> ? };
>>>> -- 
>>>> 2.17.1
>>>>
>>>
>>>


From wens at csie.org  Sun Dec 17 21:47:33 2023
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 18 Dec 2023 13:47:33 +0800
Subject: [PATCH 0/2] arm64: dts: allwinner: Add BananaPi M4 Berry
In-Reply-To: <20231217232405.302-1-andre.przywara@arm.com>
References: <20231217232405.302-1-andre.przywara@arm.com>
Message-ID: <CAGb2v67hmuHTQmGCWuop1xag7PJRd5+aTDJb8pHAhTh3V-Cy7w@mail.gmail.com>

On Mon, Dec 18, 2023 at 7:24?AM Andre Przywara <andre.przywara at arm.com> wrote:
>
> The BananaPi M4 Berry is a development board with the Allwinner H618
> SoC. It comes with 2GB DRAM and 8GB eMMC flash, with the usual suspects
> like HDMI, SD card, GPIO headers. There are four USB ports connected
> via an on-board hub chip, and a Gigabit Ethernet socket. Also there is
> a USB WiFi chip soldered on the board.
> More details: https://linux-sunxi.org/Sinovoip_Banana_Pi_M4_Berry
>
> I don't have this board, so this is a "call for testing".
> One thing to consider:
> - The USB WiFi chip has a CHIP_EN pin, which can turn the chip off.
>   It is pulled up by a resistor, so works out of the box, but is also
>   connected to a GPIO (PC2), so the chip can be disabled or reset via
>   this pin. Since this is a USB device, we don't have a DT node to
>   announce this pin. Any ideas how this should be handled? At the moment
>   I ignore it, but it could also be modelled as a USB VBUS regulator for
>   USB port 1, to which it is connected.

There was a talk on this topic at Plumbers:

https://lpc.events/event/17/contributions/1507/

So I'd say a proper solution is being worked on.

ChenYu

> When testing this, please have a look at:
> - Does the eMMC work in HS200 mode? The vendor DT described that as a
>   3.3V controlled eMMC only, but clearly the schematic uses 1.8V, which
>   allows faster transfer modes. "hdparm -t" should suffice for a quick
>   test.
> - Do USB full-speed (aka USB v1.1) peripherals like keyboard or mouse
>   work on the USB ports? I disabled the OHCI node, since the hub should
>   not need this, but it would be good to double check.
> - Similarly the USB WiFi chip probably doesn't need USB 1.1 modes, so
>   please check this still works.
>
> Apart from the missing audio and video support (which are due to missing
> bindings for the H616/H618 SoC), most of the peripherals are supported.
>
> Patch 1/2 adds the board compatible string to the bindings, patch 2/2
> adds the actual .dts file.
>
> Please have a look!
>
> Thanks,
> Andre
>
> Andre Przywara (2):
>   dt-bindings: arm: sunxi: document BananaPi M4 Berry board name
>   arm64: dts: allwinner: h618: add BananaPi M4 Berry board
>
>  .../devicetree/bindings/arm/sunxi.yaml        |   5 +
>  arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>  .../sun50i-h618-bananapi-m4-berry.dts         | 229 ++++++++++++++++++
>  3 files changed, 235 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts
>
> --
> 2.35.8
>


From viresh.kumar at linaro.org  Sun Dec 17 21:53:14 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 18 Dec 2023 11:23:14 +0530
Subject: [PATCH] cpufreq: armada-8k: Fix parameter type warning
In-Reply-To: <20231215153706.2087883-1-gregory.clement@bootlin.com>
References: <20231215153706.2087883-1-gregory.clement@bootlin.com>
Message-ID: <20231218055314.452spnbph2he3xoq@vireshk-i7>

On 15-12-23, 16:37, Gregory CLEMENT wrote:
> The second parameter of clk_get() is of type 'const char *', so use
> NULL instead of the integer 0 to resolve a sparse warning:
> 
> drivers/cpufreq/armada-8k-cpufreq.c:60:40: warning: Using plain integer as NULL pointer
> drivers/cpufreq/armada-8k-cpufreq.c:168:40: warning: Using plain integer as NULL pointer
> 
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312141651.lCAXGAZ2-lkp at intel.com/
> Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
> ---
>  drivers/cpufreq/armada-8k-cpufreq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied. Thanks.

-- 
viresh


From lkp at intel.com  Sun Dec 17 22:04:09 2023
From: lkp at intel.com (kernel test robot)
Date: Mon, 18 Dec 2023 14:04:09 +0800
Subject: [PATCH net-next v4 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <20231215171237.1152563-2-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-2-maxime.chevallier@bootlin.com>
Message-ID: <202312181303.RTKMlnzl-lkp@intel.com>

Hi Maxime,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Maxime-Chevallier/net-phy-Introduce-ethernet-link-topology-representation/20231216-012641
base:   net-next/main
patch link:    https://lore.kernel.org/r/20231215171237.1152563-2-maxime.chevallier%40bootlin.com
patch subject: [PATCH net-next v4 01/13] net: phy: Introduce ethernet link topology representation
config: i386-randconfig-054-20231216 (https://download.01.org/0day-ci/archive/20231218/202312181303.RTKMlnzl-lkp at intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231218/202312181303.RTKMlnzl-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312181303.RTKMlnzl-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> drivers/net/phy/phy_device.c:269:34: warning: 'phy_get_link_topology' defined but not used [-Wunused-function]
     269 | static struct phy_link_topology *phy_get_link_topology(struct phy_device *phydev)
         |                                  ^~~~~~~~~~~~~~~~~~~~~


vim +/phy_get_link_topology +269 drivers/net/phy/phy_device.c

   268	
 > 269	static struct phy_link_topology *phy_get_link_topology(struct phy_device *phydev)
   270	{
   271		if (phydev->attached_dev)
   272			return &phydev->attached_dev->link_topo;
   273	
   274		return NULL;
   275	}
   276	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From rdunlap at infradead.org  Sun Dec 17 22:08:34 2023
From: rdunlap at infradead.org (Randy Dunlap)
Date: Sun, 17 Dec 2023 22:08:34 -0800
Subject: [PATCH] dmaengine: std_dma40: fix kernel-doc warnings and spelling
Message-ID: <20231218060834.19222-1-rdunlap@infradead.org>

Correct kernel-doc warnings as reported by kernel test robot:

ste_dma40.c:57: warning: Excess struct member 'dev_tx' description in 'stedma40_platform_data'
ste_dma40.c:57: warning: Excess struct member 'dev_rx' description in 'stedma40_platform_data'

Correct spellos as reported by codespell.

Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312171417.izbQThoU-lkp at intel.com/
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Vinod Koul <vkoul at kernel.org>
Cc: dmaengine at vger.kernel.org
---
 drivers/dma/ste_dma40.c |   12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff -- a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -31,13 +31,11 @@
 /**
  * struct stedma40_platform_data - Configuration struct for the dma device.
  *
- * @dev_tx: mapping between destination event line and io address
- * @dev_rx: mapping between source event line and io address
  * @disabled_channels: A vector, ending with -1, that marks physical channels
  * that are for different reasons not available for the driver.
  * @soft_lli_chans: A vector, that marks physical channels will use LLI by SW
  * which avoids HW bug that exists in some versions of the controller.
- * SoftLLI introduces relink overhead that could impact performace for
+ * SoftLLI introduces relink overhead that could impact performance for
  * certain use cases.
  * @num_of_soft_lli_chans: The number of channels that needs to be configured
  * to use SoftLLI.
@@ -184,7 +182,7 @@ static __maybe_unused u32 d40_backup_reg
 
 /*
  * since 9540 and 8540 has the same HW revision
- * use v4a for 9540 or ealier
+ * use v4a for 9540 or earlier
  * use v4b for 8540 or later
  * HW revision:
  * DB8500ed has revision 0
@@ -411,7 +409,7 @@ struct d40_desc {
  *
  * @base: The virtual address of LCLA. 18 bit aligned.
  * @dma_addr: DMA address, if mapped
- * @base_unaligned: The orignal kmalloc pointer, if kmalloc is used.
+ * @base_unaligned: The original kmalloc pointer, if kmalloc is used.
  * This pointer is only there for clean-up on error.
  * @pages: The number of pages needed for all physical channels.
  * Only used later for clean-up on error
@@ -1655,7 +1653,7 @@ static void dma_tasklet(struct tasklet_s
 
 	return;
  check_pending_tx:
-	/* Rescue manouver if receiving double interrupts */
+	/* Rescue maneuver if receiving double interrupts */
 	if (d40c->pending_tx > 0)
 		d40c->pending_tx--;
 	spin_unlock_irqrestore(&d40c->lock, flags);
@@ -3412,7 +3410,7 @@ static int __init d40_lcla_allocate(stru
 		base->lcla_pool.base = (void *)page_list[i];
 	} else {
 		/*
-		 * After many attempts and no succees with finding the correct
+		 * After many attempts and no success with finding the correct
 		 * alignment, try with allocating a big buffer.
 		 */
 		dev_warn(base->dev,


From xu.yang_2 at nxp.com  Sun Dec 17 22:14:18 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 18 Dec 2023 14:14:18 +0800
Subject: [PATCH v2 1/3] usb: chipidea: ci_hdrc_imx: add wakeup clock and keep it always on
Message-ID: <20231218061420.3460145-1-xu.yang_2@nxp.com>

Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
on without usb driver intervention. And some may need driver to handle
this clock. For now only i.MX93 needs this wakeup clock. This patch will
get wakeup clock and keep it always on to make controller work properly.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - modify commit msg to make it clear
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index e28bb2f2612d..4330be8240ff 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -96,6 +96,7 @@ struct ci_hdrc_imx_data {
 	struct usb_phy *phy;
 	struct platform_device *ci_pdev;
 	struct clk *clk;
+	struct clk *clk_wakeup;
 	struct imx_usbmisc_data *usbmisc_data;
 	bool supports_runtime_pm;
 	bool override_phy_control;
@@ -199,7 +200,7 @@ static int imx_get_clks(struct device *dev)
 
 	data->clk_ipg = devm_clk_get(dev, "ipg");
 	if (IS_ERR(data->clk_ipg)) {
-		/* If the platform only needs one clocks */
+		/* If the platform only needs one primary clock */
 		data->clk = devm_clk_get(dev, NULL);
 		if (IS_ERR(data->clk)) {
 			ret = PTR_ERR(data->clk);
@@ -208,6 +209,18 @@ static int imx_get_clks(struct device *dev)
 				PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
 			return ret;
 		}
+		/* Get wakeup clock. Not all of the platforms need to
+		 * handle this clock. So make it optional.
+		 */
+		data->clk_wakeup = devm_clk_get_optional(dev,
+							 "usb_wakeup_clk");
+		if (IS_ERR(data->clk_wakeup)) {
+			ret = PTR_ERR(data->clk_wakeup);
+			dev_err(dev,
+				"Failed to get wakeup clk, err=%ld\n",
+				PTR_ERR(data->clk_wakeup));
+			return ret;
+		}
 		return ret;
 	}
 
@@ -423,6 +436,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 	if (ret)
 		goto disable_hsic_regulator;
 
+	ret = clk_prepare_enable(data->clk_wakeup);
+	if (ret)
+		goto err_wakeup_clk;
+
 	data->phy = devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0);
 	if (IS_ERR(data->phy)) {
 		ret = PTR_ERR(data->phy);
@@ -504,6 +521,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 disable_device:
 	ci_hdrc_remove_device(data->ci_pdev);
 err_clk:
+	clk_disable_unprepare(data->clk_wakeup);
+err_wakeup_clk:
 	imx_disable_unprepare_clks(dev);
 disable_hsic_regulator:
 	if (data->hsic_pad_regulator)
@@ -530,6 +549,7 @@ static void ci_hdrc_imx_remove(struct platform_device *pdev)
 		usb_phy_shutdown(data->phy);
 	if (data->ci_pdev) {
 		imx_disable_unprepare_clks(&pdev->dev);
+		clk_disable_unprepare(data->clk_wakeup);
 		if (data->plat_data->flags & CI_HDRC_PMQOS)
 			cpu_latency_qos_remove_request(&data->pm_qos_req);
 		if (data->hsic_pad_regulator)
-- 
2.34.1



From xu.yang_2 at nxp.com  Sun Dec 17 22:14:19 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 18 Dec 2023 14:14:19 +0800
Subject: [PATCH v2 2/3] usb: chipidea: wait controller resume finished for wakeup irq
In-Reply-To: <20231218061420.3460145-1-xu.yang_2@nxp.com>
References: <20231218061420.3460145-1-xu.yang_2@nxp.com>
Message-ID: <20231218061420.3460145-2-xu.yang_2@nxp.com>

After the chipidea driver introduce extcon for id and vbus, it's able
to wakeup from another irq source, in case the system with extcon ID
cable, wakeup from usb ID cable and device removal, the usb device
disconnect irq may come firstly before the extcon notifier while system
resume, so we will get 2 "wakeup" irq, one for usb device disconnect;
and one for extcon ID cable change(real wakeup event), current driver
treat them as 2 successive wakeup irq so can't handle it correctly, then
finally the usb irq can't be enabled. This patch adds a check to bypass
further usb events before controller resume finished to fix it.

Fixes: 1f874edcb731 ("usb: chipidea: add runtime power management support")
cc: <stable at vger.kernel.org>
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
Signed-off-by: Li Jun <jun.li at nxp.com>

---
Changes in v2:
 - no changes
---
 drivers/usb/chipidea/core.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 7ac39a281b8c..85e9c3ab66e9 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -523,6 +523,13 @@ static irqreturn_t ci_irq_handler(int irq, void *data)
 	u32 otgsc = 0;
 
 	if (ci->in_lpm) {
+		/*
+		 * If we already have a wakeup irq pending there,
+		 * let's just return to wait resume finished firstly.
+		 */
+		if (ci->wakeup_int)
+			return IRQ_HANDLED;
+
 		disable_irq_nosync(irq);
 		ci->wakeup_int = true;
 		pm_runtime_get(ci->dev);
-- 
2.34.1



From xu.yang_2 at nxp.com  Sun Dec 17 22:14:20 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 18 Dec 2023 14:14:20 +0800
Subject: [PATCH v2 3/3] usb: phy: mxs: remove CONFIG_USB_OTG condition for mxs_phy_is_otg_host()
In-Reply-To: <20231218061420.3460145-1-xu.yang_2@nxp.com>
References: <20231218061420.3460145-1-xu.yang_2@nxp.com>
Message-ID: <20231218061420.3460145-3-xu.yang_2@nxp.com>

When CONFIG_USB_OTG is not set, mxs_phy_is_otg_host() will always return
false. This behaviour is wrong. Since phy.last_event will always be set
for either host or device mode. Therefore, CONFIG_USB_OTG condition
can be removed.

Fixes: 5eda42aebb76 ("usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host()")
cc: <stable at vger.kernel.org>
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - add fix tag and stable maillist
---
 drivers/usb/phy/phy-mxs-usb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index acd46b72899e..920a32cd094d 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -388,8 +388,7 @@ static void __mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool disconnect)
 
 static bool mxs_phy_is_otg_host(struct mxs_phy *mxs_phy)
 {
-	return IS_ENABLED(CONFIG_USB_OTG) &&
-		mxs_phy->phy.last_event == USB_EVENT_ID;
+	return mxs_phy->phy.last_event == USB_EVENT_ID;
 }
 
 static void mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool on)
-- 
2.34.1



From viresh.kumar at linaro.org  Sun Dec 17 22:09:51 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 18 Dec 2023 11:39:51 +0530
Subject: [PATCH 4/5] cpufreq: Add support for RISC-V CPU Frequency
 scaling drivers
In-Reply-To: <11b5aea1-7c6e-4be5-ae01-9c4c869dc98c@sholland.org>
References: <20231214111702.xdd7qlcrpqh74i3j@vireshk-i7>
 <20231215151723.46409-1-fusibrandon13@gmail.com>
 <11b5aea1-7c6e-4be5-ae01-9c4c869dc98c@sholland.org>
Message-ID: <20231218060951.yhhyini4neyusyxv@vireshk-i7>

On 15-12-23, 15:09, Samuel Holland wrote:
> Move the option to the main drivers/cpufreq/Kconfig, like QORIQ_CPUFREQ,
> which is also used with multiple architectures (PowerPC and ARM, in that
> case). We don't want two options for the same driver.

+1

-- 
viresh


From quic_bibekkum at quicinc.com  Sun Dec 17 22:13:42 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Mon, 18 Dec 2023 11:43:42 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
 <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
Message-ID: <9d507505-e2f4-4916-a98c-9ba67a771d77@quicinc.com>



On 12/16/2023 9:45 PM, Dmitry Baryshkov wrote:
> On 16/12/2023 02:03, Konrad Dybcio wrote:
>> On 15.12.2023 13:54, Robin Murphy wrote:
>>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>>>
>>>>
>>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>>>> <quic_bibekkum at quicinc.com> wrote:
>>>>>>
>>>>>> Add ACTLR data table for SM8550 along with support for
>>>>>> same including SM8550 specific implementation operations.
>>>>>>
>>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>>>> ---
>>>>>> ?? drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 
>>>>>> ++++++++++++++++++++++
>>>>>> ?? 1 file changed, 89 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
>>>>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>> index cb49291f5233..d2006f610243 100644
>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>>>> ????????? u32 actlr;
>>>>>> ?? };
>>>>>>
>>>>>> +/*
>>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching 
>>>>>> in the
>>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the 
>>>>>> prefetch
>>>>>> + * buffer). The remaining bits are implementation defined and 
>>>>>> vary across
>>>>>> + * SoCs.
>>>>>> + */
>>>>>> +
>>>>>> +#define PREFETCH_DEFAULT?????? 0
>>>>>> +#define PREFETCH_SHALLOW?????? BIT(8)
>>>>>> +#define PREFETCH_MODERATE????? BIT(9)
>>>>>> +#define PREFETCH_DEEP????????? (BIT(9) | BIT(8))
>>>>>
>>>>> I thin the following might be more correct:
>>>>>
>>>>> #include <linux/bitfield.h>
>>>>>
>>>>> #define PREFETCH_MASK GENMASK(9, 8)
>>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>>>
>>>>
>>>> Ack, thanks for this suggestion. Let me try this out using
>>>> GENMASK. Once tested, will take care of this in next version.
>>>
>>> FWIW the more typical usage would be to just define the named macros 
>>> for the raw field values, then put the FIELD_PREP() at the point of 
>>> use. However in this case that's liable to get pretty verbose, so 
>>> although I'm usually a fan of bitfield.h, the most readable option 
>>> here might actually be to stick with simpler definitions of "(0 << 
>>> 8)", "(1 << 8)", etc. However it's not really a big deal either way, 
>>> and I defer to whatever Dmitry and Konrad prefer, since they're the 
>>> ones looking after arm-smmu-qcom the most :)
>> My 5 cents would be to just use the "common" style of doing this, so:
>>
>> #define ACTRL_PREFETCH??? GENMASK(9, 8)
>> ? #define PREFETCH_DEFAULT 0
>> ? #define PREFETCH_SHALLOW 1
>> ? #define PREFETCH_MODERATE 2
>> ? #define PREFETCH_DEEP 3
>>
>> and then use
>>
>> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
>>
>> it can get verbose, but.. arguably that's good, since you really want
>> to make sure the right bits are set here
> 
> Sounds good to me.
> 

Acked.


From quic_bibekkum at quicinc.com  Sun Dec 17 22:17:30 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Mon, 18 Dec 2023 11:47:30 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
Message-ID: <7caf4e99-49fd-4a81-9a97-4d67675a5c66@quicinc.com>



On 12/16/2023 5:33 AM, Konrad Dybcio wrote:
> On 15.12.2023 13:54, Robin Murphy wrote:
>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>>
>>>
>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>>> <quic_bibekkum at quicinc.com> wrote:
>>>>>
>>>>> Add ACTLR data table for SM8550 along with support for
>>>>> same including SM8550 specific implementation operations.
>>>>>
>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>>> ---
>>>>>  ? drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 ++++++++++++++++++++++
>>>>>  ? 1 file changed, 89 insertions(+)
>>>>>
>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>> index cb49291f5233..d2006f610243 100644
>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>>>  ???????? u32 actlr;
>>>>>  ? };
>>>>>
>>>>> +/*
>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the prefetch
>>>>> + * buffer). The remaining bits are implementation defined and vary across
>>>>> + * SoCs.
>>>>> + */
>>>>> +
>>>>> +#define PREFETCH_DEFAULT?????? 0
>>>>> +#define PREFETCH_SHALLOW?????? BIT(8)
>>>>> +#define PREFETCH_MODERATE????? BIT(9)
>>>>> +#define PREFETCH_DEEP????????? (BIT(9) | BIT(8))
>>>>
>>>> I thin the following might be more correct:
>>>>
>>>> #include <linux/bitfield.h>
>>>>
>>>> #define PREFETCH_MASK GENMASK(9, 8)
>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>>
>>>
>>> Ack, thanks for this suggestion. Let me try this out using
>>> GENMASK. Once tested, will take care of this in next version.
>>
>> FWIW the more typical usage would be to just define the named macros for the raw field values, then put the FIELD_PREP() at the point of use. However in this case that's liable to get pretty verbose, so although I'm usually a fan of bitfield.h, the most readable option here might actually be to stick with simpler definitions of "(0 << 8)", "(1 << 8)", etc. However it's not really a big deal either way, and I defer to whatever Dmitry and Konrad prefer, since they're the ones looking after arm-smmu-qcom the most :)
> My 5 cents would be to just use the "common" style of doing this, so:
> 
> #define ACTRL_PREFETCH	GENMASK(9, 8)
>   #define PREFETCH_DEFAULT 0
>   #define PREFETCH_SHALLOW 1
>   #define PREFETCH_MODERATE 2
>   #define PREFETCH_DEEP 3
> 
> and then use
> 
> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
> 
> it can get verbose, but.. arguably that's good, since you really want
> to make sure the right bits are set here
> 

Thanks for the suggestion with these mods.
Let me try out the suggested way and once tested will post this in next
version.

Thanks,
Bibek

> Konrad


From s-vadapalli at ti.com  Sun Dec 17 22:26:37 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 18 Dec 2023 11:56:37 +0530
Subject: [PATCH v3 1/4] dmaengine: ti: k3-udma-glue: Add function to parse channel by ID
In-Reply-To: <20231218062640.2338453-1-s-vadapalli@ti.com>
References: <20231218062640.2338453-1-s-vadapalli@ti.com>
Message-ID: <20231218062640.2338453-2-s-vadapalli@ti.com>

The existing helper function of_k3_udma_glue_parse() fetches the DMA
Channel thread ID from the device-tree node. This makes it necessary to
have a device-tree node with the Channel thread IDs populated. However,
in the case where the thread ID is known by alternate methods (an
example being that of Firmware running on remote core sharing details of
the thread IDs), there is no equivalent function to implement the
functionality of the existing of_k3_udma_glue_parse() function. In such
cases, the driver utilizing the DMA APIs might not even have a
device-tree node to begin with, since it could be probed with other
methods (RPMsg-Bus for example).

Add the of_k3_udma_glue_parse_chn_by_id() helper function which accepts
the thread ID as an argument, thereby making it unnecessary to have a
device-tree node for obtaining the thread ID.

Since of_k3_udma_glue_parse() and of_k3_udma_glue_parse_chn_by_id()
share a lot of code in common, create a new function to handle the
common code which is named as of_k3_udma_glue_parse_chn_common().

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---
Changes since v2:
- None.

Changes since v1:
- Updated commit message indicating that this patch is helpful for cases
  where the driver utilizing the DMA APIs might not be probed by a
  device-tree node.
- Removed unnecessary return value check within
  "of_k3_udma_glue_parse_chn()" function since it will fall through to
  "out_put_spec" anyway.
- Removed unnecessary return value check within
  "of_k3_udma_glue_parse_chn_by_id()" function since it will fall through
  to "out_put_spec" anyway.

 drivers/dma/ti/k3-udma-glue.c | 79 ++++++++++++++++++++++-------------
 1 file changed, 51 insertions(+), 28 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index c278d5facf7d..d8781625034b 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -111,6 +111,35 @@ static int of_k3_udma_glue_parse(struct device_node *udmax_np,
 	return 0;
 }
 
+static int of_k3_udma_glue_parse_chn_common(struct k3_udma_glue_common *common, u32 thread_id,
+					    bool tx_chn)
+{
+	if (tx_chn && !(thread_id & K3_PSIL_DST_THREAD_ID_OFFSET))
+		return -EINVAL;
+
+	if (!tx_chn && (thread_id & K3_PSIL_DST_THREAD_ID_OFFSET))
+		return -EINVAL;
+
+	/* get psil endpoint config */
+	common->ep_config = psil_get_ep_config(thread_id);
+	if (IS_ERR(common->ep_config)) {
+		dev_err(common->dev,
+			"No configuration for psi-l thread 0x%04x\n",
+			thread_id);
+		return PTR_ERR(common->ep_config);
+	}
+
+	common->epib = common->ep_config->needs_epib;
+	common->psdata_size = common->ep_config->psd_size;
+
+	if (tx_chn)
+		common->dst_thread = thread_id;
+	else
+		common->src_thread = thread_id;
+
+	return 0;
+}
+
 static int of_k3_udma_glue_parse_chn(struct device_node *chn_np,
 		const char *name, struct k3_udma_glue_common *common,
 		bool tx_chn)
@@ -153,38 +182,32 @@ static int of_k3_udma_glue_parse_chn(struct device_node *chn_np,
 		common->atype_asel = dma_spec.args[1];
 	}
 
-	if (tx_chn && !(thread_id & K3_PSIL_DST_THREAD_ID_OFFSET)) {
-		ret = -EINVAL;
-		goto out_put_spec;
-	}
-
-	if (!tx_chn && (thread_id & K3_PSIL_DST_THREAD_ID_OFFSET)) {
-		ret = -EINVAL;
-		goto out_put_spec;
-	}
-
-	/* get psil endpoint config */
-	common->ep_config = psil_get_ep_config(thread_id);
-	if (IS_ERR(common->ep_config)) {
-		dev_err(common->dev,
-			"No configuration for psi-l thread 0x%04x\n",
-			thread_id);
-		ret = PTR_ERR(common->ep_config);
-		goto out_put_spec;
-	}
-
-	common->epib = common->ep_config->needs_epib;
-	common->psdata_size = common->ep_config->psd_size;
-
-	if (tx_chn)
-		common->dst_thread = thread_id;
-	else
-		common->src_thread = thread_id;
+	ret = of_k3_udma_glue_parse_chn_common(common, thread_id, tx_chn);
 
 out_put_spec:
 	of_node_put(dma_spec.np);
 	return ret;
-};
+}
+
+static int
+of_k3_udma_glue_parse_chn_by_id(struct device_node *udmax_np, struct k3_udma_glue_common *common,
+				bool tx_chn, u32 thread_id)
+{
+	int ret = 0;
+
+	if (unlikely(!udmax_np))
+		return -EINVAL;
+
+	ret = of_k3_udma_glue_parse(udmax_np, common);
+	if (ret)
+		goto out_put_spec;
+
+	ret = of_k3_udma_glue_parse_chn_common(common, thread_id, tx_chn);
+
+out_put_spec:
+	of_node_put(udmax_np);
+	return ret;
+}
 
 static void k3_udma_glue_dump_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
 {
-- 
2.34.1



From s-vadapalli at ti.com  Sun Dec 17 22:26:36 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 18 Dec 2023 11:56:36 +0530
Subject: [PATCH v3 0/4] Add APIs to request TX/RX DMA channels for thread ID
Message-ID: <20231218062640.2338453-1-s-vadapalli@ti.com>

The existing APIs for requesting TX and RX DMA channels rely on parsing
a device-tree node to obtain the Channel/Thread IDs from their names.
However, it is possible to know the thread IDs by alternative means such
as being informed by Firmware on a remote core via RPMsg regarding the
allocated TX/RX DMA channel thread IDs. In such cases, the driver can be
probed by non device-tree methods such as RPMsg-bus, due to which it is not
necessary that the device using the DMA has a device-tree node
corresponding to it. Thus, add APIs to enable the driver to make use of
the existing DMA APIs even when there's no device-tree node.

Additionally, since the name of the device for the remote RX channel is
being set purely on the basis of the RX channel ID itself, it can result
in duplicate names when multiple flows are used on the same channel.
Avoid name duplication by including the flow in the name.

Series is based on linux-next tagged next-20231215.

v2:
https://lore.kernel.org/r/20231212111011.1401641-1-s-vadapalli at ti.com/
Changes since v2:
- Rebased series on linux-next tagged next-20231215.
- Renamed the function "k3_udma_glue_request_tx_chn_by_id()" to
  "k3_udma_glue_request_tx_chn_for_thread_id()" as suggested by:
  P?ter Ujfalusi <peter.ujfalusi at gmail.com>
- Similar to the above change, I have also renamed the function
  "k3_udma_glue_request_remote_rx_chn_by_id()" to
  "k3_udma_glue_request_remote_rx_chn_for_thread_id()".
- Updated the function prototypes in include/linux/dma/k3-udma-glue.h
  accordingly.
- Updated the commit messages for patches 3/4 and 4/4 to match the
  changes made to the function names.

v1:
https://lore.kernel.org/r/20231114083906.3143548-1-s-vadapalli at ti.com/
Changes since v1:
- Rebased series on linux-next tagged next-20231212.
- Updated commit messages with details regarding the use-case for which
  the newly added APIs will be required.
- Removed unnecessary return value check within
  "of_k3_udma_glue_parse_chn()" function in patch 1, since it will fall
  through to "out_put_spec" anyway.
- Removed unnecessary return value check within
  "of_k3_udma_glue_parse_chn_by_id()" function in patch 1, since it will
  fall through to "out_put_spec" anyway.
- Moved patch 4 of v1 series to patch 2 of current series.

RFC Series:
https://lore.kernel.org/r/20231111121555.2656760-1-s-vadapalli at ti.com/
Changes since RFC Series:
- Rebased patches 1, 2 and 3 on linux-next tagged next-20231114.
- Added patch 4 to the series.

Regards,
Siddharth.

Siddharth Vadapalli (4):
  dmaengine: ti: k3-udma-glue: Add function to parse channel by ID
  dmaengine: ti: k3-udma-glue: Update name for remote RX channel device
  dmaengine: ti: k3-udma-glue: Add function to request TX chan for
    thread ID
  dmaengine: ti: k3-udma-glue: Add function to request RX chan for
    thread ID

 drivers/dma/ti/k3-udma-glue.c    | 306 ++++++++++++++++++++++---------
 include/linux/dma/k3-udma-glue.h |  10 +
 2 files changed, 229 insertions(+), 87 deletions(-)

-- 
2.34.1



From s-vadapalli at ti.com  Sun Dec 17 22:26:39 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 18 Dec 2023 11:56:39 +0530
Subject: [PATCH v3 3/4] dmaengine: ti: k3-udma-glue: Add function to request TX chan for thread ID
In-Reply-To: <20231218062640.2338453-1-s-vadapalli@ti.com>
References: <20231218062640.2338453-1-s-vadapalli@ti.com>
Message-ID: <20231218062640.2338453-4-s-vadapalli@ti.com>

The existing function k3_udma_glue_request_tx_chn() supports requesting
a TX DMA channel by its name. Add a new function to request TX DMA channel
for a given thread ID, named k3_udma_glue_request_tx_chn_for_thread_id().
Also, export it for use by drivers which are probed by alternate methods
(non device-tree) but still wish to make use of the existing DMA APIs. Such
drivers could be informed about the thread ID corresponding to the TX DMA
channel by RPMsg for example.

Since the new function k3_udma_glue_request_tx_chn_for_thread_id() reuses
most of the code in k3_udma_glue_request_tx_chn(), create a new function
for the common code, named k3_udma_glue_request_tx_chn_common().

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---
Changes since v2:
- Renamed function "k3_udma_glue_request_tx_chn_by_id()" to
  "k3_udma_glue_request_tx_chn_for_thread_id()".
- Updated commit message to reflect function renaming.

Changes since v1:
- Updated commit message indicating the use-case for which the patch is
  being added.

 drivers/dma/ti/k3-udma-glue.c    | 102 +++++++++++++++++++++++--------
 include/linux/dma/k3-udma-glue.h |   5 ++
 2 files changed, 81 insertions(+), 26 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index eff1ae3d3efe..a475bbea35ee 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -274,29 +274,13 @@ static int k3_udma_glue_cfg_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
 	return tisci_rm->tisci_udmap_ops->tx_ch_cfg(tisci_rm->tisci, &req);
 }
 
-struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
-		const char *name, struct k3_udma_glue_tx_channel_cfg *cfg)
+static int
+k3_udma_glue_request_tx_chn_common(struct device *dev,
+				   struct k3_udma_glue_tx_channel *tx_chn,
+				   struct k3_udma_glue_tx_channel_cfg *cfg)
 {
-	struct k3_udma_glue_tx_channel *tx_chn;
 	int ret;
 
-	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
-	if (!tx_chn)
-		return ERR_PTR(-ENOMEM);
-
-	tx_chn->common.dev = dev;
-	tx_chn->common.swdata_size = cfg->swdata_size;
-	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
-	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
-	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
-	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
-
-	/* parse of udmap channel */
-	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
-					&tx_chn->common, true);
-	if (ret)
-		goto err;
-
 	tx_chn->common.hdesc_size = cppi5_hdesc_calc_size(tx_chn->common.epib,
 						tx_chn->common.psdata_size,
 						tx_chn->common.swdata_size);
@@ -312,7 +296,7 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 	if (IS_ERR(tx_chn->udma_tchanx)) {
 		ret = PTR_ERR(tx_chn->udma_tchanx);
 		dev_err(dev, "UDMAX tchanx get err %d\n", ret);
-		goto err;
+		return ret;
 	}
 	tx_chn->udma_tchan_id = xudma_tchan_get_id(tx_chn->udma_tchanx);
 
@@ -325,7 +309,7 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 		dev_err(dev, "Channel Device registration failed %d\n", ret);
 		put_device(&tx_chn->common.chan_dev);
 		tx_chn->common.chan_dev.parent = NULL;
-		goto err;
+		return ret;
 	}
 
 	if (xudma_is_pktdma(tx_chn->common.udmax)) {
@@ -349,7 +333,7 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 					     &tx_chn->ringtxcq);
 	if (ret) {
 		dev_err(dev, "Failed to get TX/TXCQ rings %d\n", ret);
-		goto err;
+		return ret;
 	}
 
 	/* Set the dma_dev for the rings to be configured */
@@ -365,13 +349,13 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 	ret = k3_ringacc_ring_cfg(tx_chn->ringtx, &cfg->tx_cfg);
 	if (ret) {
 		dev_err(dev, "Failed to cfg ringtx %d\n", ret);
-		goto err;
+		return ret;
 	}
 
 	ret = k3_ringacc_ring_cfg(tx_chn->ringtxcq, &cfg->txcq_cfg);
 	if (ret) {
 		dev_err(dev, "Failed to cfg ringtx %d\n", ret);
-		goto err;
+		return ret;
 	}
 
 	/* request and cfg psi-l */
@@ -382,11 +366,42 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 	ret = k3_udma_glue_cfg_tx_chn(tx_chn);
 	if (ret) {
 		dev_err(dev, "Failed to cfg tchan %d\n", ret);
-		goto err;
+		return ret;
 	}
 
 	k3_udma_glue_dump_tx_chn(tx_chn);
 
+	return 0;
+}
+
+struct k3_udma_glue_tx_channel *
+k3_udma_glue_request_tx_chn(struct device *dev, const char *name,
+			    struct k3_udma_glue_tx_channel_cfg *cfg)
+{
+	struct k3_udma_glue_tx_channel *tx_chn;
+	int ret;
+
+	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
+	if (!tx_chn)
+		return ERR_PTR(-ENOMEM);
+
+	tx_chn->common.dev = dev;
+	tx_chn->common.swdata_size = cfg->swdata_size;
+	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
+	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
+	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
+	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
+
+	/* parse of udmap channel */
+	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
+					&tx_chn->common, true);
+	if (ret)
+		goto err;
+
+	ret = k3_udma_glue_request_tx_chn_common(dev, tx_chn, cfg);
+	if (ret)
+		goto err;
+
 	return tx_chn;
 
 err:
@@ -395,6 +410,41 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn);
 
+struct k3_udma_glue_tx_channel *
+k3_udma_glue_request_tx_chn_for_thread_id(struct device *dev,
+					  struct k3_udma_glue_tx_channel_cfg *cfg,
+					  struct device_node *udmax_np, u32 thread_id)
+{
+	struct k3_udma_glue_tx_channel *tx_chn;
+	int ret;
+
+	tx_chn = devm_kzalloc(dev, sizeof(*tx_chn), GFP_KERNEL);
+	if (!tx_chn)
+		return ERR_PTR(-ENOMEM);
+
+	tx_chn->common.dev = dev;
+	tx_chn->common.swdata_size = cfg->swdata_size;
+	tx_chn->tx_pause_on_err = cfg->tx_pause_on_err;
+	tx_chn->tx_filt_einfo = cfg->tx_filt_einfo;
+	tx_chn->tx_filt_pswords = cfg->tx_filt_pswords;
+	tx_chn->tx_supr_tdpkt = cfg->tx_supr_tdpkt;
+
+	ret = of_k3_udma_glue_parse_chn_by_id(udmax_np, &tx_chn->common, true, thread_id);
+	if (ret)
+		goto err;
+
+	ret = k3_udma_glue_request_tx_chn_common(dev, tx_chn, cfg);
+	if (ret)
+		goto err;
+
+	return tx_chn;
+
+err:
+	k3_udma_glue_release_tx_chn(tx_chn);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn_for_thread_id);
+
 void k3_udma_glue_release_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
 {
 	if (tx_chn->psil_paired) {
diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h
index e443be4d3b4b..c81386ceb1c1 100644
--- a/include/linux/dma/k3-udma-glue.h
+++ b/include/linux/dma/k3-udma-glue.h
@@ -26,6 +26,11 @@ struct k3_udma_glue_tx_channel;
 struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev,
 		const char *name, struct k3_udma_glue_tx_channel_cfg *cfg);
 
+struct k3_udma_glue_tx_channel *
+k3_udma_glue_request_tx_chn_for_thread_id(struct device *dev,
+					  struct k3_udma_glue_tx_channel_cfg *cfg,
+					  struct device_node *udmax_np, u32 thread_id);
+
 void k3_udma_glue_release_tx_chn(struct k3_udma_glue_tx_channel *tx_chn);
 int k3_udma_glue_push_tx_chn(struct k3_udma_glue_tx_channel *tx_chn,
 			     struct cppi5_host_desc_t *desc_tx,
-- 
2.34.1



From s-vadapalli at ti.com  Sun Dec 17 22:26:40 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 18 Dec 2023 11:56:40 +0530
Subject: [PATCH v3 4/4] dmaengine: ti: k3-udma-glue: Add function to request RX chan for thread ID
In-Reply-To: <20231218062640.2338453-1-s-vadapalli@ti.com>
References: <20231218062640.2338453-1-s-vadapalli@ti.com>
Message-ID: <20231218062640.2338453-5-s-vadapalli@ti.com>

The existing function k3_udma_glue_request_remote_rx_chn() supports
requesting an RX DMA channel and flow by the name of the RX DMA channel.
Add support to request RX DMA channel for a given thread ID in the form of
a new function named k3_udma_glue_request_remote_rx_chn_for_thread_id().
Also, export it for use by drivers which are probed by alternate methods
(non device-tree) but still wish to make use of the existing DMA APIs. Such
drivers could be informed about the thread ID corresponding to the RX DMA
channel by RPMsg for example.

Since the new function k3_udma_glue_request_remote_rx_chn_for_thread_id()
reuses most of the code in k3_udma_glue_request_remote_rx_chn(), create a
new function named k3_udma_glue_request_remote_rx_chn_common() for the
common code.

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---
Changes since v2:
- Renamed function "k3_udma_glue_request_remote_rx_chn_by_id()" to
  "k3_udma_glue_request_remote_rx_chn_for_thread_id()".
- Updated commit message to reflect function renaming.

Changes since v1:
- Updated commit message indicating the use-case for which the patch is
  being added.

 drivers/dma/ti/k3-udma-glue.c    | 137 ++++++++++++++++++++++---------
 include/linux/dma/k3-udma-glue.h |   5 ++
 2 files changed, 103 insertions(+), 39 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index a475bbea35ee..c9b93055dc9d 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -1073,52 +1073,21 @@ k3_udma_glue_request_rx_chn_priv(struct device *dev, const char *name,
 	return ERR_PTR(ret);
 }
 
-static struct k3_udma_glue_rx_channel *
-k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
-				   struct k3_udma_glue_rx_channel_cfg *cfg)
+static int
+k3_udma_glue_request_remote_rx_chn_common(struct k3_udma_glue_rx_channel *rx_chn,
+					  struct k3_udma_glue_rx_channel_cfg *cfg,
+					  struct device *dev)
 {
-	struct k3_udma_glue_rx_channel *rx_chn;
 	int ret, i;
 
-	if (cfg->flow_id_num <= 0 ||
-	    cfg->flow_id_use_rxchan_id ||
-	    cfg->def_flow_cfg ||
-	    cfg->flow_id_base < 0)
-		return ERR_PTR(-EINVAL);
-
-	/*
-	 * Remote RX channel is under control of Remote CPU core, so
-	 * Linux can only request and manipulate by dedicated RX flows
-	 */
-
-	rx_chn = devm_kzalloc(dev, sizeof(*rx_chn), GFP_KERNEL);
-	if (!rx_chn)
-		return ERR_PTR(-ENOMEM);
-
-	rx_chn->common.dev = dev;
-	rx_chn->common.swdata_size = cfg->swdata_size;
-	rx_chn->remote = true;
-	rx_chn->udma_rchan_id = -1;
-	rx_chn->flow_num = cfg->flow_id_num;
-	rx_chn->flow_id_base = cfg->flow_id_base;
-	rx_chn->psil_paired = false;
-
-	/* parse of udmap channel */
-	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
-					&rx_chn->common, false);
-	if (ret)
-		goto err;
-
 	rx_chn->common.hdesc_size = cppi5_hdesc_calc_size(rx_chn->common.epib,
 						rx_chn->common.psdata_size,
 						rx_chn->common.swdata_size);
 
 	rx_chn->flows = devm_kcalloc(dev, rx_chn->flow_num,
 				     sizeof(*rx_chn->flows), GFP_KERNEL);
-	if (!rx_chn->flows) {
-		ret = -ENOMEM;
-		goto err;
-	}
+	if (!rx_chn->flows)
+		return -ENOMEM;
 
 	rx_chn->common.chan_dev.class = &k3_udma_glue_devclass;
 	rx_chn->common.chan_dev.parent = xudma_get_device(rx_chn->common.udmax);
@@ -1129,7 +1098,7 @@ k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
 		dev_err(dev, "Channel Device registration failed %d\n", ret);
 		put_device(&rx_chn->common.chan_dev);
 		rx_chn->common.chan_dev.parent = NULL;
-		goto err;
+		return ret;
 	}
 
 	if (xudma_is_pktdma(rx_chn->common.udmax)) {
@@ -1141,19 +1110,109 @@ k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
 
 	ret = k3_udma_glue_allocate_rx_flows(rx_chn, cfg);
 	if (ret)
-		goto err;
+		return ret;
 
 	for (i = 0; i < rx_chn->flow_num; i++)
 		rx_chn->flows[i].udma_rflow_id = rx_chn->flow_id_base + i;
 
 	k3_udma_glue_dump_rx_chn(rx_chn);
 
+	return 0;
+}
+
+static struct k3_udma_glue_rx_channel *
+k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
+				   struct k3_udma_glue_rx_channel_cfg *cfg)
+{
+	struct k3_udma_glue_rx_channel *rx_chn;
+	int ret;
+
+	if (cfg->flow_id_num <= 0 ||
+	    cfg->flow_id_use_rxchan_id ||
+	    cfg->def_flow_cfg ||
+	    cfg->flow_id_base < 0)
+		return ERR_PTR(-EINVAL);
+
+	/*
+	 * Remote RX channel is under control of Remote CPU core, so
+	 * Linux can only request and manipulate by dedicated RX flows
+	 */
+
+	rx_chn = devm_kzalloc(dev, sizeof(*rx_chn), GFP_KERNEL);
+	if (!rx_chn)
+		return ERR_PTR(-ENOMEM);
+
+	rx_chn->common.dev = dev;
+	rx_chn->common.swdata_size = cfg->swdata_size;
+	rx_chn->remote = true;
+	rx_chn->udma_rchan_id = -1;
+	rx_chn->flow_num = cfg->flow_id_num;
+	rx_chn->flow_id_base = cfg->flow_id_base;
+	rx_chn->psil_paired = false;
+
+	/* parse of udmap channel */
+	ret = of_k3_udma_glue_parse_chn(dev->of_node, name,
+					&rx_chn->common, false);
+	if (ret)
+		goto err;
+
+	ret = k3_udma_glue_request_remote_rx_chn_common(rx_chn, cfg, dev);
+	if (ret)
+		goto err;
+
+	return rx_chn;
+
+err:
+	k3_udma_glue_release_rx_chn(rx_chn);
+	return ERR_PTR(ret);
+}
+
+struct k3_udma_glue_rx_channel *
+k3_udma_glue_request_remote_rx_chn_for_thread_id(struct device *dev,
+						 struct k3_udma_glue_rx_channel_cfg *cfg,
+						 struct device_node *udmax_np, u32 thread_id)
+{
+	struct k3_udma_glue_rx_channel *rx_chn;
+	int ret;
+
+	if (cfg->flow_id_num <= 0 ||
+	    cfg->flow_id_use_rxchan_id ||
+	    cfg->def_flow_cfg ||
+	    cfg->flow_id_base < 0)
+		return ERR_PTR(-EINVAL);
+
+	/*
+	 * Remote RX channel is under control of Remote CPU core, so
+	 * Linux can only request and manipulate by dedicated RX flows
+	 */
+
+	rx_chn = devm_kzalloc(dev, sizeof(*rx_chn), GFP_KERNEL);
+	if (!rx_chn)
+		return ERR_PTR(-ENOMEM);
+
+	rx_chn->common.dev = dev;
+	rx_chn->common.swdata_size = cfg->swdata_size;
+	rx_chn->remote = true;
+	rx_chn->udma_rchan_id = -1;
+	rx_chn->flow_num = cfg->flow_id_num;
+	rx_chn->flow_id_base = cfg->flow_id_base;
+	rx_chn->psil_paired = false;
+
+	ret = of_k3_udma_glue_parse_chn_by_id(udmax_np, &rx_chn->common, false, thread_id);
+	if (ret)
+		goto err;
+
+	ret = k3_udma_glue_request_remote_rx_chn_common(rx_chn, cfg, dev);
+	if (ret)
+		goto err;
+
 	return rx_chn;
 
 err:
 	k3_udma_glue_release_rx_chn(rx_chn);
 	return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(k3_udma_glue_request_remote_rx_chn_for_thread_id);
 
 struct k3_udma_glue_rx_channel *
 k3_udma_glue_request_rx_chn(struct device *dev, const char *name,
diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h
index c81386ceb1c1..1e491c5dcac2 100644
--- a/include/linux/dma/k3-udma-glue.h
+++ b/include/linux/dma/k3-udma-glue.h
@@ -114,6 +114,11 @@ struct k3_udma_glue_rx_channel *k3_udma_glue_request_rx_chn(
 		const char *name,
 		struct k3_udma_glue_rx_channel_cfg *cfg);
 
+struct k3_udma_glue_rx_channel *
+k3_udma_glue_request_remote_rx_chn_for_thread_id(struct device *dev,
+						 struct k3_udma_glue_rx_channel_cfg *cfg,
+						 struct device_node *udmax_np, u32 thread_id);
+
 void k3_udma_glue_release_rx_chn(struct k3_udma_glue_rx_channel *rx_chn);
 int k3_udma_glue_enable_rx_chn(struct k3_udma_glue_rx_channel *rx_chn);
 void k3_udma_glue_disable_rx_chn(struct k3_udma_glue_rx_channel *rx_chn);
-- 
2.34.1



From s-vadapalli at ti.com  Sun Dec 17 22:26:38 2023
From: s-vadapalli at ti.com (Siddharth Vadapalli)
Date: Mon, 18 Dec 2023 11:56:38 +0530
Subject: [PATCH v3 2/4] dmaengine: ti: k3-udma-glue: Update name for remote RX channel device
In-Reply-To: <20231218062640.2338453-1-s-vadapalli@ti.com>
References: <20231218062640.2338453-1-s-vadapalli@ti.com>
Message-ID: <20231218062640.2338453-3-s-vadapalli@ti.com>

A single RX Channel can have multiple flows. It is possible that a
single device requests multiple flows on the same RX Channel. In such
cases, the existing implementation of naming the device on the basis of
the RX Channel can result in duplicate names. The existing implementation
only uses the RX Channel source thread when naming, which implies duplicate
names when different flows are being requested on the same RX Channel.

In order to avoid duplicate names, include the RX flow as well in the name.

Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
---
Changes since v2:
- None.

Changes since v1:
- None.

 drivers/dma/ti/k3-udma-glue.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index d8781625034b..eff1ae3d3efe 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -1072,8 +1072,8 @@ k3_udma_glue_request_remote_rx_chn(struct device *dev, const char *name,
 
 	rx_chn->common.chan_dev.class = &k3_udma_glue_devclass;
 	rx_chn->common.chan_dev.parent = xudma_get_device(rx_chn->common.udmax);
-	dev_set_name(&rx_chn->common.chan_dev, "rchan_remote-0x%04x",
-		     rx_chn->common.src_thread);
+	dev_set_name(&rx_chn->common.chan_dev, "rchan_remote-0x%04x-0x%02x",
+		     rx_chn->common.src_thread, rx_chn->flow_id_base);
 	ret = device_register(&rx_chn->common.chan_dev);
 	if (ret) {
 		dev_err(dev, "Channel Device registration failed %d\n", ret);
-- 
2.34.1



From quic_bibekkum at quicinc.com  Sun Dec 17 22:37:30 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Mon, 18 Dec 2023 12:07:30 +0530
Subject: [PATCH v4 5/5] iommu/arm-smmu: re-enable context caching in smmu
 reset operation
In-Reply-To: <3c7b8c2c-7174-4ced-8954-5a249f792c1e@linaro.org>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-6-quic_bibekkum@quicinc.com>
 <3c7b8c2c-7174-4ced-8954-5a249f792c1e@linaro.org>
Message-ID: <2ef44a36-7895-4562-bac6-703e5fb9c17a@quicinc.com>



On 12/16/2023 5:24 AM, Konrad Dybcio wrote:
> On 15.12.2023 11:18, Bibek Kumar Patro wrote:
>> Default MMU-500 reset operation disables context caching in
>> prefetch buffer. It is however expected for context banks using
>> the ACTLR register to retain their prefetch value during reset
>> and runtime suspend.
>>
>> Replace default MMU-500 reset operation with Qualcomm specific reset
>> operation which envelope the default reset operation and re-enables
>> context caching in prefetch buffer for Qualcomm SoCs.
>>
>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>> ---
> This probably deserves a fixes tag, but I can't find a good commit for
> it, so I guess not having it is fine as well.
> 

I was also trying to find any suitable commit, but this default reset
implementation didn't have a separate commit, so did not add any fixes
tag here.

> Also, since it seems to be independent from the rest of the patches, please
> reorder it to become patch 1 in the next spin, so that it can perhaps be
> easily picked up independently of the rest.
> 

Sure, agree on the same. Will keep this as 1st patch, and start the rest
of the patches on top of it.

>>   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 23 +++++++++++++++++++---
>>   1 file changed, 20 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> index c8f5dd4186b7..70d2a5d43993 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> @@ -516,11 +516,28 @@ static int qcom_smmu_def_domain_type(struct device *dev)
>>   	return match ? IOMMU_DOMAIN_IDENTITY : 0;
>>   }
>>
>> +static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
>> +{
>> +	int i;
>> +	u32 reg;
> That's rather nitty/codestyle-y, but:
> 
> - reverse Christmas tree would be nice (it's in a week! :D)
> - "reg" to me sounds like "register address", "val" is used widely for
>    register values
> 

Thanks for pointing to this, will take care of this val name and
sorting in next version.(Will try to post the reserse xmas tree sorted
patch asap for the xmas celebration! :) )

>> +
>> +	arm_mmu500_reset(smmu);
> We should check the return value here, in case the function is modified
> some day in a way that makes it return something else than 0
> 
> LGTM otherwise!
>

Thanks,
Bibek

> Konrad


From tudor.ambarus at linaro.org  Sun Dec 17 22:43:33 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Mon, 18 Dec 2023 06:43:33 +0000
Subject: [PATCH v2] dt-bindings: clock: google,gs101: rename CMU_TOP gate defines
Message-ID: <20231218064333.479885-1-tudor.ambarus@linaro.org>

The gs101 clock defines from the bindings header are derived from the
clock register names found in the datasheet under some certain rules.

The CMU TOP gate clock defines missed to include the required "CMU"
differentiator which will cause collisions with the gate clock defines
of other clock units. Rename the TOP gate clock defines to include "CMU".

Update the clock driver to use the new defines in order to not break
compilation and bisect-ability. There are no device trees that use the
previous defines.

Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Reviewed-by: Peter Griffin <peter.griffin at linaro.org>
---
v2:
- update commit's subject and message. First version sent at:
  - https://lore.kernel.org/linux-arm-kernel/20231214105243.3707730-2-tudor.ambarus at linaro.org/
- add Sam's and Peter's R-b tags even if I updated the commit subject
  and message after I got them.

 drivers/clk/samsung/clk-gs101.c          | 167 ++++++++++++-----------
 include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
 2 files changed, 159 insertions(+), 152 deletions(-)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index a3dda97f5eb9..0964bb11657f 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -17,7 +17,7 @@
 #include "clk-exynos-arm64.h"
 
 /* NOTE: Must be equal to the last clock ID increased by one */
-#define CLKS_NR_TOP	(CLK_GOUT_TPU_UART + 1)
+#define CLKS_NR_TOP	(CLK_GOUT_CMU_TPU_UART + 1)
 #define CLKS_NR_APM	(CLK_APM_PLL_DIV16_APM + 1)
 #define CLKS_NR_MISC	(CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
 
@@ -1259,160 +1259,167 @@ static const struct samsung_fixed_factor_clock cmu_top_ffactor[] __initconst = {
 };
 
 static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
-	GATE(CLK_GOUT_BUS0_BOOST, "gout_cmu_bus0_boost",
+	GATE(CLK_GOUT_CMU_BUS0_BOOST, "gout_cmu_bus0_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS0_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_BUS1_BOOST, "gout_cmu_bus1_boost",
+	GATE(CLK_GOUT_CMU_BUS1_BOOST, "gout_cmu_bus1_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS1_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_BUS2_BOOST, "gout_cmu_bus2_boost",
+	GATE(CLK_GOUT_CMU_BUS2_BOOST, "gout_cmu_bus2_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS2_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_CORE_BOOST, "gout_cmu_core_boost",
+	GATE(CLK_GOUT_CMU_CORE_BOOST, "gout_cmu_core_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CORE_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_CPUCL0_BOOST, "gout_cmu_cpucl0_boost",
+	GATE(CLK_GOUT_CMU_CPUCL0_BOOST, "gout_cmu_cpucl0_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL0_BOOST,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CPUCL1_BOOST, "gout_cmu_cpucl1_boost",
+	GATE(CLK_GOUT_CMU_CPUCL1_BOOST, "gout_cmu_cpucl1_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL1_BOOST,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CPUCL2_BOOST, "gout_cmu_cpucl2_boost",
+	GATE(CLK_GOUT_CMU_CPUCL2_BOOST, "gout_cmu_cpucl2_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL2_BOOST,
 	     21, 0, 0),
-	GATE(CLK_GOUT_MIF_BOOST, "gout_cmu_mif_boost",
+	GATE(CLK_GOUT_CMU_MIF_BOOST, "gout_cmu_mif_boost",
 	     "mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_MIF_BOOST,
 	     21, 0, 0),
-	GATE(CLK_GOUT_MIF_SWITCH, "gout_cmu_mif_switch", "mout_cmu_mif_switch",
-	     CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
-	GATE(CLK_GOUT_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
+	GATE(CLK_GOUT_CMU_MIF_SWITCH, "gout_cmu_mif_switch",
+	     "mout_cmu_mif_switch", CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
+	GATE(CLK_GOUT_CMU_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_BO_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
+	GATE(CLK_GOUT_CMU_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
+	GATE(CLK_GOUT_CMU_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
+	GATE(CLK_GOUT_CMU_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK0, "gout_cmu_cis_clk0", "mout_cmu_cis_clk0",
+	GATE(CLK_GOUT_CMU_CIS_CLK0, "gout_cmu_cis_clk0", "mout_cmu_cis_clk0",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK0, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK1, "gout_cmu_cis_clk1", "mout_cmu_cis_clk1",
+	GATE(CLK_GOUT_CMU_CIS_CLK1, "gout_cmu_cis_clk1", "mout_cmu_cis_clk1",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK1, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK2, "gout_cmu_cis_clk2", "mout_cmu_cis_clk2",
+	GATE(CLK_GOUT_CMU_CIS_CLK2, "gout_cmu_cis_clk2", "mout_cmu_cis_clk2",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK2, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK3, "gout_cmu_cis_clk3", "mout_cmu_cis_clk3",
+	GATE(CLK_GOUT_CMU_CIS_CLK3, "gout_cmu_cis_clk3", "mout_cmu_cis_clk3",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK3, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK4, "gout_cmu_cis_clk4", "mout_cmu_cis_clk4",
+	GATE(CLK_GOUT_CMU_CIS_CLK4, "gout_cmu_cis_clk4", "mout_cmu_cis_clk4",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK4, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK5, "gout_cmu_cis_clk5", "mout_cmu_cis_clk5",
+	GATE(CLK_GOUT_CMU_CIS_CLK5, "gout_cmu_cis_clk5", "mout_cmu_cis_clk5",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK5, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK6, "gout_cmu_cis_clk6", "mout_cmu_cis_clk6",
+	GATE(CLK_GOUT_CMU_CIS_CLK6, "gout_cmu_cis_clk6", "mout_cmu_cis_clk6",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK6, 21, 0, 0),
-	GATE(CLK_GOUT_CIS_CLK7, "gout_cmu_cis_clk7", "mout_cmu_cis_clk7",
+	GATE(CLK_GOUT_CMU_CIS_CLK7, "gout_cmu_cis_clk7", "mout_cmu_cis_clk7",
 	     CLK_CON_GAT_GATE_CLKCMU_CIS_CLK7, 21, 0, 0),
-	GATE(CLK_GOUT_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_cmu_boost",
+	GATE(CLK_GOUT_CMU_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_cmu_boost",
 	     CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST, 21, 0, 0),
-	GATE(CLK_GOUT_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
+	GATE(CLK_GOUT_CMU_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_CORE_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_CPUCL0_DBG, "gout_cmu_cpucl0_dbg", "mout_cmu_cpucl0_dbg",
-	     CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch",
+	GATE(CLK_GOUT_CMU_CPUCL0_DBG, "gout_cmu_cpucl0_dbg",
+	     "mout_cmu_cpucl0_dbg", CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch",
 	     "mout_cmu_cpucl0_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch",
+	GATE(CLK_GOUT_CMU_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch",
 	     "mout_cmu_cpucl1_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch",
+	GATE(CLK_GOUT_CMU_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch",
 	     "mout_cmu_cpucl2_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH,
 	     21, 0, 0),
-	GATE(CLK_GOUT_CSIS_BUS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
+	GATE(CLK_GOUT_CMU_CSIS_BUS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
+	GATE(CLK_GOUT_CMU_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_DISP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
+	GATE(CLK_GOUT_CMU_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_DNS_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
+	GATE(CLK_GOUT_CMU_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_DPU_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
+	GATE(CLK_GOUT_CMU_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_EH_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
+	GATE(CLK_GOUT_CMU_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
 	     CLK_CON_GAT_GATE_CLKCMU_G2D_G2D, 21, 0, 0),
-	GATE(CLK_GOUT_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
+	GATE(CLK_GOUT_CMU_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
 	     CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL, 21, 0, 0),
-	GATE(CLK_GOUT_G3AA_G3AA, "gout_cmu_g3aa_g3aa", "mout_cmu_g3aa_g3aa",
+	GATE(CLK_GOUT_CMU_G3AA_G3AA, "gout_cmu_g3aa_g3aa", "mout_cmu_g3aa_g3aa",
 	     CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 21, 0, 0),
-	GATE(CLK_GOUT_G3D_BUSD, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
+	GATE(CLK_GOUT_CMU_G3D_BUSD, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
 	     CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD, 21, 0, 0),
-	GATE(CLK_GOUT_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
+	GATE(CLK_GOUT_CMU_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
 	     CLK_CON_GAT_GATE_CLKCMU_G3D_GLB, 21, 0, 0),
-	GATE(CLK_GOUT_G3D_SWITCH, "gout_cmu_g3d_switch", "mout_cmu_g3d_switch",
-	     CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH, 21, 0, 0),
-	GATE(CLK_GOUT_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
+	GATE(CLK_GOUT_CMU_G3D_SWITCH, "gout_cmu_g3d_switch",
+	     "mout_cmu_g3d_switch", CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
 	     CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0, 21, 0, 0),
-	GATE(CLK_GOUT_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
+	GATE(CLK_GOUT_CMU_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
 	     CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1, 21, 0, 0),
-	GATE(CLK_GOUT_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
+	GATE(CLK_GOUT_CMU_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
 	     CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC, 21, 0, 0),
 	GATE(CLK_GOUT_CMU_HPM, "gout_cmu_hpm", "mout_cmu_hpm",
 	     CLK_CON_GAT_GATE_CLKCMU_HPM, 21, 0, 0),
-	GATE(CLK_GOUT_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
+	GATE(CLK_GOUT_CMU_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc", "mout_cmu_hsi0_dpgtc",
-	     CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC, 21, 0, 0),
-	GATE(CLK_GOUT_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd",
+	GATE(CLK_GOUT_CMU_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc",
+	     "mout_cmu_hsi0_dpgtc", CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd",
 	     "mout_cmu_hsi0_usb31drd", CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD,
 	     21, 0, 0),
-	GATE(CLK_GOUT_HSI0_USBDPDBG, "gout_cmu_hsi0_usbdpdbg",
+	GATE(CLK_GOUT_CMU_HSI0_USBDPDBG, "gout_cmu_hsi0_usbdpdbg",
 	     "mout_cmu_hsi0_usbdpdbg", CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG,
 	     21, 0, 0),
-	GATE(CLK_GOUT_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
+	GATE(CLK_GOUT_CMU_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
+	GATE(CLK_GOUT_CMU_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE, 21, 0, 0),
-	GATE(CLK_GOUT_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
+	GATE(CLK_GOUT_CMU_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card",
+	GATE(CLK_GOUT_CMU_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card",
 	     "mout_cmu_hsi2_mmc_card", CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD,
 	     21, 0, 0),
-	GATE(CLK_GOUT_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
+	GATE(CLK_GOUT_CMU_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
 	     CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE, 21, 0, 0),
-	GATE(CLK_GOUT_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd",
+	GATE(CLK_GOUT_CMU_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd",
 	     "mout_cmu_hsi2_ufs_embd", CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD,
 	     21, 0, 0),
-	GATE(CLK_GOUT_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
+	GATE(CLK_GOUT_CMU_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_IPP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_ITP_BUS, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
+	GATE(CLK_GOUT_CMU_ITP_BUS, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_ITP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
+	GATE(CLK_GOUT_CMU_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
 	     CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC, 21, 0, 0),
-	GATE(CLK_GOUT_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
+	GATE(CLK_GOUT_CMU_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
 	     CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC, 21, 0, 0),
-	GATE(CLK_GOUT_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
+	GATE(CLK_GOUT_CMU_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
 	     CLK_CON_GAT_GATE_CLKCMU_MFC_MFC, 21, 0, 0),
-	GATE(CLK_GOUT_MIF_BUSP, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
+	GATE(CLK_GOUT_CMU_MIF_BUSP, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
 	     CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP, 21, 0, 0),
-	GATE(CLK_GOUT_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
+	GATE(CLK_GOUT_CMU_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_MISC_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
+	GATE(CLK_GOUT_CMU_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
 	     CLK_CON_GAT_GATE_CLKCMU_MISC_SSS, 21, 0, 0),
-	GATE(CLK_GOUT_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
+	GATE(CLK_GOUT_CMU_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
+	GATE(CLK_GOUT_CMU_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
 	     CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_PERIC0_BUS, "gout_cmu_peric0_bus", "mout_cmu_peric0_bus",
-	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
+	GATE(CLK_GOUT_CMU_PERIC0_BUS, "gout_cmu_peric0_bus",
+	     "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
 	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
-	GATE(CLK_GOUT_PERIC1_BUS, "gout_cmu_peric1_bus", "mout_cmu_peric1_bus",
-	     CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
+	GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
+	     "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
 	     CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP, 21, 0, 0),
-	GATE(CLK_GOUT_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
+	GATE(CLK_GOUT_CMU_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_TNR_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_TOP_CMUREF, "gout_cmu_top_cmuref", "mout_cmu_top_cmuref",
-	     CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF, 21, 0, 0),
-	GATE(CLK_GOUT_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
+	GATE(CLK_GOUT_CMU_TOP_CMUREF, "gout_cmu_top_cmuref",
+	     "mout_cmu_top_cmuref", CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
 	     CLK_CON_GAT_GATE_CLKCMU_TPU_BUS, 21, 0, 0),
-	GATE(CLK_GOUT_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
+	GATE(CLK_GOUT_CMU_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
 	     CLK_CON_GAT_GATE_CLKCMU_TPU_TPU, 21, 0, 0),
-	GATE(CLK_GOUT_TPU_TPUCTL, "gout_cmu_tpu_tpuctl", "mout_cmu_tpu_tpuctl",
-	     CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL, 21, 0, 0),
-	GATE(CLK_GOUT_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
+	GATE(CLK_GOUT_CMU_TPU_TPUCTL, "gout_cmu_tpu_tpuctl",
+	     "mout_cmu_tpu_tpuctl", CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL,
+	     21, 0, 0),
+	GATE(CLK_GOUT_CMU_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
 	     CLK_CON_GAT_GATE_CLKCMU_TPU_UART, 21, 0, 0),
 };
 
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
index 9761c0b24e66..21adec22387c 100644
--- a/include/dt-bindings/clock/google,gs101.h
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -166,79 +166,79 @@
 #define CLK_DOUT_CMU_SHARED3_DIV2	150
 
 /* CMU_TOP Gates */
-#define CLK_GOUT_BUS0_BOOST		151
-#define CLK_GOUT_BUS1_BOOST		152
-#define CLK_GOUT_BUS2_BOOST		153
-#define CLK_GOUT_CORE_BOOST		154
-#define CLK_GOUT_CPUCL0_BOOST		155
-#define CLK_GOUT_CPUCL1_BOOST		156
-#define CLK_GOUT_CPUCL2_BOOST		157
-#define CLK_GOUT_MIF_BOOST		158
-#define CLK_GOUT_MIF_SWITCH		159
-#define CLK_GOUT_BO_BUS			160
-#define CLK_GOUT_BUS0_BUS		161
-#define CLK_GOUT_BUS1_BUS		162
-#define CLK_GOUT_BUS2_BUS		163
-#define CLK_GOUT_CIS_CLK0		164
-#define CLK_GOUT_CIS_CLK1		165
-#define CLK_GOUT_CIS_CLK2		166
-#define CLK_GOUT_CIS_CLK3		167
-#define CLK_GOUT_CIS_CLK4		168
-#define CLK_GOUT_CIS_CLK5		169
-#define CLK_GOUT_CIS_CLK6		170
-#define CLK_GOUT_CIS_CLK7		171
-#define CLK_GOUT_CMU_BOOST		172
-#define CLK_GOUT_CORE_BUS		173
-#define CLK_GOUT_CPUCL0_DBG		174
-#define CLK_GOUT_CPUCL0_SWITCH		175
-#define CLK_GOUT_CPUCL1_SWITCH		176
-#define CLK_GOUT_CPUCL2_SWITCH		177
-#define CLK_GOUT_CSIS_BUS		178
-#define CLK_GOUT_DISP_BUS		179
-#define CLK_GOUT_DNS_BUS		180
-#define CLK_GOUT_DPU_BUS		181
-#define CLK_GOUT_EH_BUS			182
-#define CLK_GOUT_G2D_G2D		183
-#define CLK_GOUT_G2D_MSCL		184
-#define CLK_GOUT_G3AA_G3AA		185
-#define CLK_GOUT_G3D_BUSD		186
-#define CLK_GOUT_G3D_GLB		187
-#define CLK_GOUT_G3D_SWITCH		188
-#define CLK_GOUT_GDC_GDC0		189
-#define CLK_GOUT_GDC_GDC1		190
-#define CLK_GOUT_GDC_SCSC		191
+#define CLK_GOUT_CMU_BUS0_BOOST		151
+#define CLK_GOUT_CMU_BUS1_BOOST		152
+#define CLK_GOUT_CMU_BUS2_BOOST		153
+#define CLK_GOUT_CMU_CORE_BOOST		154
+#define CLK_GOUT_CMU_CPUCL0_BOOST	155
+#define CLK_GOUT_CMU_CPUCL1_BOOST	156
+#define CLK_GOUT_CMU_CPUCL2_BOOST	157
+#define CLK_GOUT_CMU_MIF_BOOST		158
+#define CLK_GOUT_CMU_MIF_SWITCH		159
+#define CLK_GOUT_CMU_BO_BUS		160
+#define CLK_GOUT_CMU_BUS0_BUS		161
+#define CLK_GOUT_CMU_BUS1_BUS		162
+#define CLK_GOUT_CMU_BUS2_BUS		163
+#define CLK_GOUT_CMU_CIS_CLK0		164
+#define CLK_GOUT_CMU_CIS_CLK1		165
+#define CLK_GOUT_CMU_CIS_CLK2		166
+#define CLK_GOUT_CMU_CIS_CLK3		167
+#define CLK_GOUT_CMU_CIS_CLK4		168
+#define CLK_GOUT_CMU_CIS_CLK5		169
+#define CLK_GOUT_CMU_CIS_CLK6		170
+#define CLK_GOUT_CMU_CIS_CLK7		171
+#define CLK_GOUT_CMU_CMU_BOOST		172
+#define CLK_GOUT_CMU_CORE_BUS		173
+#define CLK_GOUT_CMU_CPUCL0_DBG		174
+#define CLK_GOUT_CMU_CPUCL0_SWITCH	175
+#define CLK_GOUT_CMU_CPUCL1_SWITCH	176
+#define CLK_GOUT_CMU_CPUCL2_SWITCH	177
+#define CLK_GOUT_CMU_CSIS_BUS		178
+#define CLK_GOUT_CMU_DISP_BUS		179
+#define CLK_GOUT_CMU_DNS_BUS		180
+#define CLK_GOUT_CMU_DPU_BUS		181
+#define CLK_GOUT_CMU_EH_BUS		182
+#define CLK_GOUT_CMU_G2D_G2D		183
+#define CLK_GOUT_CMU_G2D_MSCL		184
+#define CLK_GOUT_CMU_G3AA_G3AA		185
+#define CLK_GOUT_CMU_G3D_BUSD		186
+#define CLK_GOUT_CMU_G3D_GLB		187
+#define CLK_GOUT_CMU_G3D_SWITCH		188
+#define CLK_GOUT_CMU_GDC_GDC0		189
+#define CLK_GOUT_CMU_GDC_GDC1		190
+#define CLK_GOUT_CMU_GDC_SCSC		191
 #define CLK_GOUT_CMU_HPM		192
-#define CLK_GOUT_HSI0_BUS		193
-#define CLK_GOUT_HSI0_DPGTC		194
-#define CLK_GOUT_HSI0_USB31DRD		195
-#define CLK_GOUT_HSI0_USBDPDBG		196
-#define CLK_GOUT_HSI1_BUS		197
-#define CLK_GOUT_HSI1_PCIE		198
-#define CLK_GOUT_HSI2_BUS		199
-#define CLK_GOUT_HSI2_MMC_CARD		200
-#define CLK_GOUT_HSI2_PCIE		201
-#define CLK_GOUT_HSI2_UFS_EMBD		202
-#define CLK_GOUT_IPP_BUS		203
-#define CLK_GOUT_ITP_BUS		204
-#define CLK_GOUT_MCSC_ITSC		205
-#define CLK_GOUT_MCSC_MCSC		206
-#define CLK_GOUT_MFC_MFC		207
-#define CLK_GOUT_MIF_BUSP		208
-#define CLK_GOUT_MISC_BUS		209
-#define CLK_GOUT_MISC_SSS		210
-#define CLK_GOUT_PDP_BUS		211
-#define CLK_GOUT_PDP_VRA		212
-#define CLK_GOUT_G3AA			213
-#define CLK_GOUT_PERIC0_BUS		214
-#define CLK_GOUT_PERIC0_IP		215
-#define CLK_GOUT_PERIC1_BUS		216
-#define CLK_GOUT_PERIC1_IP		217
-#define CLK_GOUT_TNR_BUS		218
-#define CLK_GOUT_TOP_CMUREF		219
-#define CLK_GOUT_TPU_BUS		220
-#define CLK_GOUT_TPU_TPU		221
-#define CLK_GOUT_TPU_TPUCTL		222
-#define CLK_GOUT_TPU_UART		223
+#define CLK_GOUT_CMU_HSI0_BUS		193
+#define CLK_GOUT_CMU_HSI0_DPGTC		194
+#define CLK_GOUT_CMU_HSI0_USB31DRD	195
+#define CLK_GOUT_CMU_HSI0_USBDPDBG	196
+#define CLK_GOUT_CMU_HSI1_BUS		197
+#define CLK_GOUT_CMU_HSI1_PCIE		198
+#define CLK_GOUT_CMU_HSI2_BUS		199
+#define CLK_GOUT_CMU_HSI2_MMC_CARD	200
+#define CLK_GOUT_CMU_HSI2_PCIE		201
+#define CLK_GOUT_CMU_HSI2_UFS_EMBD	202
+#define CLK_GOUT_CMU_IPP_BUS		203
+#define CLK_GOUT_CMU_ITP_BUS		204
+#define CLK_GOUT_CMU_MCSC_ITSC		205
+#define CLK_GOUT_CMU_MCSC_MCSC		206
+#define CLK_GOUT_CMU_MFC_MFC		207
+#define CLK_GOUT_CMU_MIF_BUSP		208
+#define CLK_GOUT_CMU_MISC_BUS		209
+#define CLK_GOUT_CMU_MISC_SSS		210
+#define CLK_GOUT_CMU_PDP_BUS		211
+#define CLK_GOUT_CMU_PDP_VRA		212
+#define CLK_GOUT_CMU_G3AA		213
+#define CLK_GOUT_CMU_PERIC0_BUS		214
+#define CLK_GOUT_CMU_PERIC0_IP		215
+#define CLK_GOUT_CMU_PERIC1_BUS		216
+#define CLK_GOUT_CMU_PERIC1_IP		217
+#define CLK_GOUT_CMU_TNR_BUS		218
+#define CLK_GOUT_CMU_TOP_CMUREF		219
+#define CLK_GOUT_CMU_TPU_BUS		220
+#define CLK_GOUT_CMU_TPU_TPU		221
+#define CLK_GOUT_CMU_TPU_TPUCTL		222
+#define CLK_GOUT_CMU_TPU_UART		223
 
 /* CMU_APM */
 #define CLK_MOUT_APM_FUNC				1
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Sun Dec 17 22:50:11 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Mon, 18 Dec 2023 06:50:11 +0000
Subject: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate
 clock names
In-Reply-To: <7163718b-0a92-4383-b475-aac52354489d@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-2-tudor.ambarus@linaro.org>
 <050c3119-0431-4400-9052-7a9c0ec67918@linaro.org>
 <5e454300-f1ef-435c-8c4c-16561502196a@linaro.org>
 <9eedae99-cc9a-4c8f-9a09-789b686cd456@linaro.org>
 <7163718b-0a92-4383-b475-aac52354489d@linaro.org>
Message-ID: <877ea38d-a227-43b0-8e91-7e0f1f2059b3@linaro.org>



On 12/15/23 19:25, Krzysztof Kozlowski wrote:
> On 15/12/2023 20:24, Krzysztof Kozlowski wrote:
>> On 15/12/2023 11:23, Tudor Ambarus wrote:
>>> Hi, Krzysztof,
>>>
>>> On 12/15/23 08:13, Krzysztof Kozlowski wrote:
>>>> On 14/12/2023 11:52, Tudor Ambarus wrote:
>>>>> The gs101 clock names are derived from the clock register names under
>>>>> some certain rules. In particular, for the gate clocks the following is
>>>>> documented and expected in the gs101 clock driver:
>>>>>
>>>>>   Replace CLK_CON_GAT_CLKCMU      with CLK_GOUT_CMU and gout_cmu
>>>>>   Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>>>
>>>>>   For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>>>
>>>> I don't understand what it has to do with the bindings.
>>>>
>>>>>
>>>>> The CMU TOP gate clock names missed to include the required "CMU"
>>>>> differentiator which will cause name collisions with the gate clock names
>>>>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>>>>> their name.
>>>>
>>>> Neither here. Clock names are not related to defines.
>>>>
>>>
>>> When saying "clock names" I meant the clock symbolic names that are
>>> defined in the bindings, the _id passed in GATE(_id, ) if you want.
>>
>> Please re-phrase the commit message to say that you need to rename the
>> defines in the bindings headers. If you change anything else, like clock
>> names, then it should be separate patch.
> 
> I forgot:
> You can also respin this patch separately, as soon as possible, because
> it has to go this cycle.
> 
Sent here:
https://lore.kernel.org/linux-arm-kernel/20231218064333.479885-1-tudor.ambarus at linaro.org/

Thanks,
ta


From mmayer at broadcom.com  Sun Dec 17 22:56:32 2023
From: mmayer at broadcom.com (Markus Mayer)
Date: Sun, 17 Dec 2023 22:56:32 -0800
Subject: [PATCH 01/15] memory: brcmstb_dpfe: Convert to platform remove
 callback returning void
In-Reply-To: <94780e5a414b20b6effa1e87208c14620c854e88.1702822744.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702822744.git.u.kleine-koenig@pengutronix.de> <94780e5a414b20b6effa1e87208c14620c854e88.1702822744.git.u.kleine-koenig@pengutronix.de>
Message-ID: <CAGt4E5uvRGq9Cw74T1kWNT0nyPt_R5aGvt9EE1XRkVQGH1tPJw@mail.gmail.com>

On Sun, 17 Dec 2023 at 06:30, Uwe Kleine-K?nig
<u.kleine-koenig at pengutronix.de> wrote:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
>
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  drivers/memory/brcmstb_dpfe.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> index a7ab3d377206..5028467b2dc9 100644
> --- a/drivers/memory/brcmstb_dpfe.c
> +++ b/drivers/memory/brcmstb_dpfe.c
> @@ -909,13 +909,11 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
>         return ret;
>  }
>
> -static int brcmstb_dpfe_remove(struct platform_device *pdev)
> +static void brcmstb_dpfe_remove(struct platform_device *pdev)
>  {
>         struct brcmstb_dpfe_priv *priv = dev_get_drvdata(&pdev->dev);
>
>         sysfs_remove_groups(&pdev->dev.kobj, priv->dpfe_api->sysfs_attrs);
> -
> -       return 0;
>  }
>
>  static const struct of_device_id brcmstb_dpfe_of_match[] = {
> @@ -936,7 +934,7 @@ static struct platform_driver brcmstb_dpfe_driver = {
>                 .of_match_table = brcmstb_dpfe_of_match,
>         },
>         .probe = brcmstb_dpfe_probe,
> -       .remove = brcmstb_dpfe_remove,
> +       .remove_new = brcmstb_dpfe_remove,
>         .resume = brcmstb_dpfe_resume,
>  };

Acked-by: Markus Mayer <mmayer at broadcom.com>


From krzysztof.kozlowski at linaro.org  Sun Dec 17 23:03:52 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 08:03:52 +0100
Subject: [PATCH v2 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <2b8414e5-61d5-4c3e-9613-6d9487ae84a8@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
 <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
 <8f583a00-8e9c-4875-936c-ed196d1dae56@linaro.org>
 <2b8414e5-61d5-4c3e-9613-6d9487ae84a8@arm.com>
Message-ID: <4c78e6f2-d6fb-4da7-9c54-ca6a686f2b58@linaro.org>

On 15/12/2023 19:39, Robin Murphy wrote:
>>> +required:
>>> +  - compatible
>>> +  - reg
>>> +
>>> +additionalProperties: false
>>
>> Why no example to validate the binding?
> 
> IMO for such a trivial binding built out of common properties, an 
> equally trivial example isn't going to add any value, since it won't do 
> anything more than re-state the individual property definitions above. 
> In bindings where we have conditional relationships between properties, 
> or complex encodings where a practical example can help explain a 
> definition (e.g. a map/mask pair for a set of input values), then 
> absolutely, an example can add something more to help the author and/or 
> users. But otherwise, the thing I've really grown to like about schema 
> is how thoroughly self-describing the definitions themselves can now be.

The example is used to validate the schema.

Best regards,
Krzysztof



From michal.simek at amd.com  Sun Dec 17 23:04:05 2023
From: michal.simek at amd.com (Michal Simek)
Date: Mon, 18 Dec 2023 08:04:05 +0100
Subject: [PATCH] mailbox: zynqmp-ipi: fix an Excess struct member
 kernel-doc warning
In-Reply-To: <20231216004156.26967-1-rdunlap@infradead.org>
References: <20231216004156.26967-1-rdunlap@infradead.org>
Message-ID: <7f8e8ddd-f7b6-4c62-b8ff-9549b2edff46@amd.com>



On 12/16/23 01:41, Randy Dunlap wrote:
> kernel test robot reports 2 Excess struct member warnings:
> 
> zynqmp-ipi-mailbox.c:92: warning: Excess struct member 'irq' description in 'zynqmp_ipi_mbox'
> zynqmp-ipi-mailbox.c:112: warning: Excess struct member 'ipi_mboxes' description in 'zynqmp_ipi_pdata'
> 
> The second one is a false positive that is caused by the
> __counted_by() attribute. Kees has posted a patch for that, so just
> fix the first one.
> 
> Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312150705.glrQ4ypv-lkp at intel.com/
> Cc: Jassi Brar <jassisinghbrar at gmail.com>
> Cc: Michal Simek <michal.simek at amd.com>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>   drivers/mailbox/zynqmp-ipi-mailbox.c |    1 -
>   1 file changed, 1 deletion(-)
> 
> diff -- a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
> --- a/drivers/mailbox/zynqmp-ipi-mailbox.c
> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
> @@ -81,7 +81,6 @@ struct zynqmp_ipi_mchan {
>    * @remote_id:            remote IPI agent ID
>    * @mbox:                 mailbox Controller
>    * @mchans:               array for channels, tx channel and rx channel.
> - * @irq:                  IPI agent interrupt ID
>    */
>   struct zynqmp_ipi_mbox {
>   	struct zynqmp_ipi_pdata *pdata;

Reviewed-by: Michal Simek <michal.simek at amd.com>

Thanks,
Michal


From jun.ann.lai at intel.com  Sun Dec 17 23:06:41 2023
From: jun.ann.lai at intel.com (Lai Peter Jun Ann)
Date: Mon, 18 Dec 2023 15:06:41 +0800
Subject: [PATCH net 1/1] net: stmmac: fix incorrect flag check in timestamp interrupt
Message-ID: <1702883201-29632-1-git-send-email-jun.ann.lai@intel.com>

The driver should continue get the timestamp if STMMAC_FLAG_EXT_SNAPSHOT_EN
flag is set.

Signed-off-by: Song Yoong Siang <yoong.siang.song at intel.com>
Signed-off-by: Lai Peter Jun Ann <jun.ann.lai at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 540f6a4..f05bd75 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -237,7 +237,7 @@ static void timestamp_interrupt(struct stmmac_priv *priv)
 	 */
 	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
 
-	if (priv->plat->flags & STMMAC_FLAG_EXT_SNAPSHOT_EN)
+	if (!(priv->plat->flags & STMMAC_FLAG_EXT_SNAPSHOT_EN))
 		return;
 
 	num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
-- 
1.9.1



From quic_snehshah at quicinc.com  Sun Dec 17 23:11:18 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Mon, 18 Dec 2023 12:41:18 +0530
Subject: [PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support for 2.5G SGMII
Message-ID: <20231218071118.21879-1-quic_snehshah@quicinc.com>

Serdes phy needs to operate at 2500 mode for 2.5G speed and 1000
mode for 1G/100M/10M speed.
Added changes to configure serdes phy and mac based on link speed.

Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
---
 .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 31 +++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index d3bf42d0fceb..b3a28dc19161 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -21,6 +21,7 @@
 #define RGMII_IO_MACRO_CONFIG2		0x1C
 #define RGMII_IO_MACRO_DEBUG1		0x20
 #define EMAC_SYSTEM_LOW_POWER_DEBUG	0x28
+#define ETHQOS_MAC_AN_CTRL		0xE0
 
 /* RGMII_IO_MACRO_CONFIG fields */
 #define RGMII_CONFIG_FUNC_CLK_EN		BIT(30)
@@ -78,6 +79,10 @@
 #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
 #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
 
+/*ETHQOS_MAC_AN_CTRL bits */
+#define ETHQOS_MAC_AN_CTRL_RAN			BIT(9)
+#define ETHQOS_MAC_AN_CTRL_ANE			BIT(12)
+
 struct ethqos_emac_por {
 	unsigned int offset;
 	unsigned int value;
@@ -109,6 +114,7 @@ struct qcom_ethqos {
 	unsigned int num_por;
 	bool rgmii_config_loopback_en;
 	bool has_emac_ge_3;
+	unsigned int serdes_speed;
 };
 
 static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
@@ -600,27 +606,47 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
 
 static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
 {
-	int val;
-
+	int val, mac_an_value;
 	val = readl(ethqos->mac_base + MAC_CTRL_REG);
+	mac_an_value = readl(ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
 
 	switch (ethqos->speed) {
+	case SPEED_2500:
+		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
+		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
+			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
+			      RGMII_IO_MACRO_CONFIG2);
+		if (ethqos->serdes_speed != SPEED_2500)
+			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
+		mac_an_value &= ~ETHQOS_MAC_AN_CTRL_ANE;
+		break;
 	case SPEED_1000:
 		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
 		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
 			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
 			      RGMII_IO_MACRO_CONFIG2);
+		if (ethqos->serdes_speed != SPEED_1000)
+			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
+		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
 		break;
 	case SPEED_100:
 		val |= ETHQOS_MAC_CTRL_PORT_SEL | ETHQOS_MAC_CTRL_SPEED_MODE;
+		if (ethqos->serdes_speed != SPEED_1000)
+			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
+		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
 		break;
 	case SPEED_10:
 		val |= ETHQOS_MAC_CTRL_PORT_SEL;
 		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
+		if (ethqos->serdes_speed != SPEED_1000)
+			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
+		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
 		break;
 	}
 
 	writel(val, ethqos->mac_base + MAC_CTRL_REG);
+	writel(mac_an_value, ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
+	ethqos->serdes_speed = ethqos->speed;
 
 	return val;
 }
@@ -789,6 +815,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
 				     "Failed to get serdes phy\n");
 
 	ethqos->speed = SPEED_1000;
+	ethqos->serdes_speed = SPEED_1000;
 	ethqos_update_link_clk(ethqos, SPEED_1000);
 	ethqos_set_func_clk_en(ethqos);
 
-- 
2.17.1



From krzysztof.kozlowski at linaro.org  Sun Dec 17 23:20:45 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 08:20:45 +0100
Subject: [PATCH 1/2] dt-bindings: arm: sunxi: document BananaPi M4 Berry
 board name
In-Reply-To: <20231217232405.302-2-andre.przywara@arm.com>
References: <20231217232405.302-1-andre.przywara@arm.com>
 <20231217232405.302-2-andre.przywara@arm.com>
Message-ID: <520ef9c7-1a12-4662-99c7-0be9762ce7bb@linaro.org>

On 18/12/2023 00:24, Andre Przywara wrote:
> The Bananapi M4 Berry is a development board with the Allwinner H618 SoC.
> 
> Add the board/SoC compatible string pair to the list of known boards.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 17 23:21:36 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 08:21:36 +0100
Subject: [PATCH 2/2] arm64: dts: allwinner: h618: add BananaPi M4 Berry
 board
In-Reply-To: <20231217232405.302-3-andre.przywara@arm.com>
References: <20231217232405.302-1-andre.przywara@arm.com>
 <20231217232405.302-3-andre.przywara@arm.com>
Message-ID: <60c4e8b9-17b5-44e9-b971-abf147735334@linaro.org>

On 18/12/2023 00:24, Andre Przywara wrote:
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		key-sw4 {
> +			label = "sw3";
> +			linux,code = <BTN_0>;
> +			gpios = <&pio 2 7 GPIO_ACTIVE_LOW>;	/* PC7 */
> +		};
> +	};
> +
> +	reg_vcc5v: vcc5v {

regulator prefix to the node name (others have it).

> +		/* board wide 5V supply directly from the USB-C socket */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-5v";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-always-on;
> +	};
> +
> +	reg_usb_vbus: regulator-usb-vbus {
> +		/* separate discrete regulator for the USB ports */
> +		compatible = "regulator-fixed";
> +		regulator-name = "usb-vbus";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&reg_vcc5v>;
> +	};
> +
> +	reg_3v3: regulator-3v3 {
> +		/* separate discrete regulator for WiFi and Ethernet PHY */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-3v3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&reg_vcc5v>;
> +	};
> +};
> +

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 17 23:24:16 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 08:24:16 +0100
Subject: [PATCH 2/3] arm64: dts: rockchip: Add support for NanoPi R6S
In-Reply-To: <25d84712ee3765f5f28dfd355a2392f20f388824.1702647349.git.efectn@protonmail.com>
References: <cover.1702647349.git.efectn@protonmail.com>
 <25d84712ee3765f5f28dfd355a2392f20f388824.1702647349.git.efectn@protonmail.com>
Message-ID: <e1b86dd9-833d-4545-aeb0-b394702dc6dc@linaro.org>

On 15/12/2023 14:55, efectn at 6tel.net wrote:
> From: Muhammed Efe Cetin <efectn at protonmail.com>
> 
> Add basic NanoPi R6S support that comes with USB2, PCIe, SD card, eMMC
> support.
> 
> Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
> ---
>  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>  .../boot/dts/rockchip/rk3588s-nanopi-r6s.dts  | 755 ++++++++++++++++++
>  2 files changed, 756 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
> 
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 600c420bc..ed2583dcd 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -114,3 +114,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
> \ No newline at end of file

You have warning here.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
> new file mode 100644
> index 000000000..e575cc403
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
> @@ -0,0 +1,755 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;

...

> +
> +&i2c2 {
> +	status = "okay";
> +
> +	vdd_npu_s0: rk8602 at 42 {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation


> +		compatible = "rockchip,rk8602";
> +		reg = <0x42>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-compatible = "rk860x-reg";
> +		regulator-name = "vdd_npu_s0";
> +		regulator-min-microvolt = <550000>;
> +		regulator-max-microvolt = <950000>;
> +		regulator-ramp-delay = <2300>;
> +		regulator-boot-on;
> +		regulator-always-on;
> +		vin-supply = <&vcc5v0_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&i2c6 {
> +	clock-frequency = <200000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c6m0_xfer>;
> +	status = "okay";
> +
> +	hym8563: rtc at 51 {
> +		compatible = "haoyu,hym8563";
> +		reg = <0x51>;
> +		#clock-cells = <0>;
> +		clock-output-names = "hym8563";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&rtc_int>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
> +		wakeup-source;
> +	};
> +};
> +
> +&mdio1 {
> +	rgmii_phy1: ethernet-phy at 1 {
> +		compatible = "ethernet-phy-id001c.c916";
> +		reg = <0x1>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&rtl8211f_rst>;
> +		reset-assert-us = <20000>;
> +		reset-deassert-us = <100000>;
> +		reset-gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> +	};
> +};
> +
> +&pcie2x1l1 {
> +	reset-gpios = <&gpio1 RK_PA7 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc_3v3_pcie20>;
> +	status = "okay";
> +};
> +
> +&pcie2x1l2 {
> +	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc_3v3_pcie20>;
> +	status = "okay";
> +};
> +
> +&pinctrl {
> +	gpio-key {
> +		key1_pin: key1-pin {
> +			rockchip,pins = <1 RK_PC0 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	gpio-leds {
> +		sys_led_pin: sys-led-pin {
> +			rockchip,pins =
> +				<1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		wan_led_pin: wan-led-pin {
> +			rockchip,pins =
> +				<1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		lan1_led_pin: lan1-led-pin {
> +			rockchip,pins =
> +				<1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		lan2_led_pin: lan2-led-pin {
> +			rockchip,pins =
> +				<1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	hym8563 {
> +		rtc_int: rtc-int {
> +			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	sdmmc {
> +		sd_s0_pwr: sd-s0-pwr {
> +			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	usb {
> +		typec5v_pwren: typec5v-pwren {
> +			rockchip,pins = <1 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		vcc5v0_host20_en: vcc5v0-host20-en {
> +			rockchip,pins = <4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	rtl8211f {
> +		rtl8211f_rst: rtl8211f-rst {
> +			rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&saradc {
> +	vref-supply = <&avcc_1v8_s0>;
> +	status = "okay";
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	no-sdio;
> +	no-sd;
> +	non-removable;
> +	mmc-hs200-1_8v;
> +	max-frequency = <200000000>;
> +	status = "okay";
> +};
> +
> +&sdmmc {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	disable-wp;
> +	max-frequency = <150000000>;
> +	no-mmc;
> +	no-sdio;
> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc_3v3_sd_s0>;
> +	vqmmc-supply = <&vccio_sd_s0>;
> +	status = "okay";
> +};
> +
> +&spi2 {
> +	status = "okay";
> +	assigned-clocks = <&cru CLK_SPI2>;
> +	assigned-clock-rates = <200000000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
> +	num-cs = <1>;
> +
> +	pmic at 0 {
> +		compatible = "rockchip,rk806";
> +		spi-max-frequency = <1000000>;
> +		reg = <0x0>;

reg should be second property.



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 17 23:24:56 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 08:24:56 +0100
Subject: [PATCH 3/3] arm64: dts: rockchip: Add support for NanoPi R6C
In-Reply-To: <923b4d9bb60fecd080e7c348ec0d4630392eb091.1702647349.git.efectn@protonmail.com>
References: <cover.1702647349.git.efectn@protonmail.com>
 <923b4d9bb60fecd080e7c348ec0d4630392eb091.1702647349.git.efectn@protonmail.com>
Message-ID: <93e07033-6596-44a2-97bf-22425dfaee42@linaro.org>

On 15/12/2023 14:55, efectn at 6tel.net wrote:
> From: Muhammed Efe Cetin <efectn at protonmail.com>
> 
> NanoPi R6C is mostly same as R6S variant. It has M2 port instead of a
> NIC port and different led labeling.
> 
> Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
> ---
>  arch/arm64/boot/dts/rockchip/Makefile              |  3 ++-
>  .../arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts | 14 ++++++++++++++
>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
> 
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index ed2583dcd..261505081 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -114,4 +114,5 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
> -dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
> \ No newline at end of file
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
> \ No newline at end of file

Still warnings...

> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
> new file mode 100644
> index 000000000..8031098c3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3588s-nanopi-r6s.dts"
> +
> +/ {
> +	model = "FriendlyElec NanoPi R6C";
> +	compatible = "friendlyelec,nanopi-r6c", "rockchip,rk3588s";

It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 17 23:24:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 08:24:53 +0100
Subject: [PATCH 2/3] arm64: dts: rockchip: Add support for NanoPi R6S
In-Reply-To: <25d84712ee3765f5f28dfd355a2392f20f388824.1702647349.git.efectn@protonmail.com>
References: <cover.1702647349.git.efectn@protonmail.com>
 <25d84712ee3765f5f28dfd355a2392f20f388824.1702647349.git.efectn@protonmail.com>
Message-ID: <45a37621-596d-4e63-b7fa-6b8dc54602c8@linaro.org>

On 15/12/2023 14:55, efectn at 6tel.net wrote:
> From: Muhammed Efe Cetin <efectn at protonmail.com>
> 
> Add basic NanoPi R6S support that comes with USB2, PCIe, SD card, eMMC
> support.
> 
> Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
> ---
>  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>  .../boot/dts/rockchip/rk3588s-nanopi-r6s.dts  | 755 ++++++++++++++++++
>  2 files changed, 756 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
> 
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 600c420bc..ed2583dcd 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -114,3 +114,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
> \ No newline at end of file
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
> new file mode 100644
> index 000000000..e575cc403
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
> @@ -0,0 +1,755 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "rk3588s.dtsi"
> +
> +/ {
> +	model = "FriendlyElec NanoPi R6S";
> +	compatible = "friendlyelec,nanopi-r6s", "rockchip,rk3588s";

It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).

Best regards,
Krzysztof



From tony at atomide.com  Sun Dec 17 23:28:31 2023
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 18 Dec 2023 09:28:31 +0200
Subject: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc
 for wkup_uart0
In-Reply-To: <20231215160047.uiitnlgmirbudmj5@scored>
References: <20231114073209.40756-1-tony@atomide.com>
 <20231215160047.uiitnlgmirbudmj5@scored>
Message-ID: <20231218072831.GX5169@atomide.com>

* Nishanth Menon <nm at ti.com> [231215 16:00]:
> On 09:32-20231114, Tony Lindgren wrote:
> > -	wkup_uart0: serial at 2b300000 {
> > -		compatible = "ti,am64-uart", "ti,am654-uart";
> > -		reg = <0x00 0x2b300000 0x00 0x100>;
> > -		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> > +	target-module at 2b300000 {
> 
> should be  target-module at 2b300050 to match up with reg?

It's best to use the target-module IO range here, not the first reg.
The first reg may be tossed anywhere in the target module address
space depending on the device.

Ideally of course there would be just a standardized range of target
module related registers at the end of the IO space..

> > +		wkup_uart0: serial at 2b300000 {
> 
> serial at 0  to match up with reg?

Yes thanks for catching this. The 8250 IP is at the beginning of the
target module IO space. Will post an updated patch.

Regards,

Tony


From tony at atomide.com  Sun Dec 17 23:38:14 2023
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 18 Dec 2023 09:38:14 +0200
Subject: [PATCH] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0
Message-ID: <20231218073816.32241-1-tony@atomide.com>

The devices in the wkup domain are capable of waking up the system from
suspend. We can configure the wkup domain devices in a generic way using
the ti-sysc interconnect target module driver like we have done with the
earlier TI SoCs.

As ti-sysc manages the SYSCONFIG related registers independent of the
child hardware device, the wake-up configuration is also set even if
wkup_uart0 is reserved by sysfw.

The wkup_uart0 device has interconnect target module register mapping like
dra7 wkup uart. There is a 1 MB interconnect target range with one uart IP
block in the target module. The power domain and clock affects the whole
interconnect target module.

Note we change the functional clock name to follow the ti-sysc binding
and use "fck" instead of "fclk".

Tested-by: Dhruva Gole <d-gole at ti.com>
Reviewed-by: Kevin Hilman <khilman at baylibre.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---

Changes since v2:

- Fix node name for 8250 IP, it's at offset 0 from the target module

- Added Kevin's Reviewed-by from v2 as the node name change is mostly
  cosmetic

---
 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi | 33 ++++++++++++++++++----
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
--- a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
@@ -5,6 +5,8 @@
  * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
  */
 
+#include <dt-bindings/bus/ti-sysc.h>
+
 &cbass_wakeup {
 	wkup_conf: syscon at 43000000 {
 		bootph-all;
@@ -21,14 +23,33 @@ chipid: chipid at 14 {
 		};
 	};
 
-	wkup_uart0: serial at 2b300000 {
-		compatible = "ti,am64-uart", "ti,am654-uart";
-		reg = <0x00 0x2b300000 0x00 0x100>;
-		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+	target-module at 2b300000 {
+		compatible = "ti,sysc-omap2", "ti,sysc";
+		reg = <0 0x2b300050 0 0x4>,
+		      <0 0x2b300054 0 0x4>,
+		      <0 0x2b300058 0 0x4>;
+		reg-names = "rev", "sysc", "syss";
+		ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
+				 SYSC_OMAP2_SOFTRESET |
+				 SYSC_OMAP2_AUTOIDLE)>;
+		ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+				<SYSC_IDLE_NO>,
+				<SYSC_IDLE_SMART>,
+				<SYSC_IDLE_SMART_WKUP>;
+		ti,syss-mask = <1>;
 		power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
 		clocks = <&k3_clks 114 0>;
-		clock-names = "fclk";
-		status = "disabled";
+		clock-names = "fck";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0 0x2b300000 0x100000>;
+
+		wkup_uart0: serial at 0 {
+			compatible = "ti,am64-uart", "ti,am654-uart";
+			reg = <0 0x100>;
+			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
 	};
 
 	wkup_i2c0: i2c at 2b200000 {
-- 
2.43.0


From peter.hilber at opensynergy.com  Sun Dec 17 23:38:38 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Mon, 18 Dec 2023 08:38:38 +0100
Subject: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes
Message-ID: <20231218073849.35294-1-peter.hilber@opensynergy.com>

RFC v3 updates
--------------

This series implements a driver for a virtio-rtc device conforming to spec
RFC v3 [1]. It now includes an RTC class driver with alarm, in addition to
the PTP clock driver already present before.

This patch series depends on the patch series "treewide: Use clocksource id
for get_device_system_crosststamp()" [3]. Pull [4] to get the combined
series on top of mainline.

Overview
--------

This patch series adds the virtio_rtc module, and related bugfixes. The
virtio_rtc module implements a driver compatible with the proposed Virtio
RTC device specification [1]. The Virtio RTC (Real Time Clock) device
provides information about current time. The device can provide different
clocks, e.g. for the UTC or TAI time standards, or for physical time
elapsed since some past epoch. The driver can read the clocks with simple
or more accurate methods. Optionally, the driver can set an alarm.

The series first fixes some bugs in the get_device_system_crosststamp()
interpolation code, which is required for reliable virtio_rtc operation.
Then, add the virtio_rtc implementation.

For the Virtio RTC device, there is currently a proprietary implementation,
which has been used for provisional testing.

PTP clock interface
-------------------

virtio_rtc exposes clocks as PTP clocks to userspace, similar to ptp_kvm.
If both the Virtio RTC device and this driver have special support for the
current clocksource, time synchronization programs can use
cross-timestamping using ioctl PTP_SYS_OFFSET_PRECISE2 aka
PTP_SYS_OFFSET_PRECISE. Similar to ptp_kvm, system time synchronization
with single-digit ns precision is possible with a quiescent reference clock
(from the Virtio RTC device). This works even when the Virtio device
response is slow compared to ptp_kvm hypercalls.

The following illustrates a test using PTP_SYS_OFFSET_PRECISE, with
interspersed strace log and chrony [2] refclocks log, on arm64. In the
example, chrony tracks a virtio_rtc PTP clock ("PHCV", /dev/ptp0). The raw
offset between the virtio_rtc clock and CLOCK_REALTIME is 0 to 1 ns. At the
device side, the Virtio RTC device artificially delays both the clock read
request, and the response, by 50 ms. Cross-timestamp interpolation still
works with this delay. chrony also monitors a ptp_kvm clock ("PHCK",
/dev/ptp3) for comparison, which yields a similar offset.

	ioctl(5</dev/ptp3>, PTP_SYS_OFFSET_PRECISE, 0xffffe86691c8) = 0 <0.000329>
	===============================================================================
	   Date (UTC) Time         Refid  DP L P  Raw offset   Cooked offset      Disp.
	===============================================================================
	2023-06-29 18:49:55.595742 PHCK    0 N 0  1.000000e-09  8.717931e-10  5.500e-08
	2023-06-29 18:49:55.595742 PHCK    - N -       -        8.717931e-10  5.500e-08
	ioctl(6</dev/ptp0>, PTP_SYS_OFFSET_PRECISE, 0xffffe86691c8) = 0 <0.101545>
	2023-06-29 18:49:56.147766 PHCV    0 N 0  1.000000e-09  8.801870e-10  5.500e-08
	2023-06-29 18:49:56.147766 PHCV    - N -       -        8.801870e-10  5.500e-08
	ioctl(5</dev/ptp3>, PTP_SYS_OFFSET_PRECISE, 0xffffe86691c8) = 0 <0.000195>
	2023-06-29 18:49:56.202446 PHCK    0 N 0  1.000000e-09  7.364180e-10  5.500e-08
	2023-06-29 18:49:56.202446 PHCK    - N -       -        7.364180e-10  5.500e-08
	ioctl(6</dev/ptp0>, PTP_SYS_OFFSET_PRECISE, 0xffffe86691c8) = 0 <0.101484>
	2023-06-29 18:49:56.754641 PHCV    0 N 0  0.000000e+00 -2.617368e-10  5.500e-08
	2023-06-29 18:49:56.754641 PHCV    - N -       -       -2.617368e-10  5.500e-08
	ioctl(5</dev/ptp3>, PTP_SYS_OFFSET_PRECISE, 0xffffe86691c8) = 0 <0.000270>
	2023-06-29 18:49:56.809282 PHCK    0 N 0  1.000000e-09  7.779321e-10  5.500e-08
	2023-06-29 18:49:56.809282 PHCK    - N -       -        7.779321e-10  5.500e-08
	ioctl(6</dev/ptp0>, PTP_SYS_OFFSET_PRECISE, 0xffffe86691c8) = 0 <0.101510>
	2023-06-29 18:49:57.361376 PHCV    0 N 0  0.000000e+00 -2.198794e-10  5.500e-08
	2023-06-29 18:49:57.361376 PHCV    - N -       -       -2.198794e-10  5.500e-08

This patch series only adds special support for the Arm Generic Timer
clocksource. At the driver side, it should be easy to support more
clocksources.

Fallback PTP clock interface
----------------------------

Without special support for the current clocksource, time synchronization
programs can still use ioctl PTP_SYS_OFFSET_EXTENDED2 aka
PTP_SYS_OFFSET_EXTENDED. In this case, precision will generally be worse
and will depend on the Virtio device response characteristics.

The following illustrates a test using PTP_SYS_OFFSET_EXTENDED, with
interspersed strace log and chrony refclocks log, on x86-64 (with `ts'
values omitted):

	ioctl(5, PTP_SYS_OFFSET_EXTENDED, {n_samples=10, ts=OMITTED}) = 0
	===============================================================================
	   Date (UTC) Time         Refid  DP L P  Raw offset   Cooked offset      Disp.
	===============================================================================
	2023-06-28 14:11:26.697782 PHCV    0 N 0  3.318200e-05  3.450891e-05  4.611e-06
	2023-06-28 14:11:26.697782 PHCV    - N -       -        3.450891e-05  4.611e-06
	ioctl(5, PTP_SYS_OFFSET_EXTENDED, {n_samples=10, ts=OMITTED}) = 0
	2023-06-28 14:11:27.208763 PHCV    0 N 0 -3.792800e-05 -4.023965e-05  4.611e-06
	2023-06-28 14:11:27.208763 PHCV    - N -       -       -4.023965e-05  4.611e-06
	ioctl(5, PTP_SYS_OFFSET_EXTENDED, {n_samples=10, ts=OMITTED}) = 0
	2023-06-28 14:11:27.722818 PHCV    0 N 0 -3.328600e-05 -3.134404e-05  4.611e-06
	2023-06-28 14:11:27.722818 PHCV    - N -       -       -3.134404e-05  4.611e-06
	ioctl(5, PTP_SYS_OFFSET_EXTENDED, {n_samples=10, ts=OMITTED}) = 0
	2023-06-28 14:11:28.233572 PHCV    0 N 0 -4.966900e-05 -4.584331e-05  4.611e-06
	2023-06-28 14:11:28.233572 PHCV    - N -       -       -4.584331e-05  4.611e-06
	ioctl(5, PTP_SYS_OFFSET_EXTENDED, {n_samples=10, ts=OMITTED}) = 0
	2023-06-28 14:11:28.742737 PHCV    0 N 0  4.902700e-05  5.361388e-05  4.611e-06
	2023-06-28 14:11:28.742737 PHCV    - N -       -        5.361388e-05  4.611e-06

PTP clock setup
---------------

The following udev rule can be used to get a symlink /dev/ptp_virtio to the
UTC clock:

	SUBSYSTEM=="ptp", ATTR{clock_name}=="Virtio PTP UTC", SYMLINK += "ptp_virtio"

The following chrony configuration directive can then be added in
/etc/chrony/chrony.conf to synchronize to the Virtio UTC clock:

	refclock PHC /dev/ptp_virtio refid PHCV poll -1 dpoll -1

RTC interface
-------------

This patch series adds virtio_rtc as a generic Virtio driver, including
both a PTP clock driver and an RTC class driver.

Feedback is greatly appreciated.

[1] https://lore.kernel.org/virtio-comment/20231218064253.9734-1-peter.hilber at opensynergy.com/
[2] https://chrony.tuxfamily.org/
[3] https://lore.kernel.org/lkml/20231215220612.173603-1-peter.hilber at opensynergy.com/
[4] https://github.com/OpenSynergy/linux.git virtio-rtc-v3-on-master

v3:

- Update to conform to virtio spec RFC v3 (no significant behavioral
  changes).

- Add RTC class driver with alarm according to virtio spec RFC v3.

- For cross-timestamp corner case fix, switch back to v1 style closed
  interval test (Thomas Gleixner).

v2:

- Depend on patch series "treewide: Use clocksource id for
  get_device_system_crosststamp()" to avoid requiring a clocksource pointer
  with get_device_system_crosststamp().

- Assume Arm Generic Timer will use CP15 virtual counter. Drop
  arm_arch_timer helper functions (Marc Zyngier).

- Improve cross-timestamp fixes problem description and implementation
  (John Stultz).


Peter Hilber (7):
  timekeeping: Fix cross-timestamp interpolation on counter wrap
  timekeeping: Fix cross-timestamp interpolation corner case decision
  timekeeping: Fix cross-timestamp interpolation for non-x86
  virtio_rtc: Add module and driver core
  virtio_rtc: Add PTP clocks
  virtio_rtc: Add Arm Generic Timer cross-timestamping
  virtio_rtc: Add RTC class driver

 MAINTAINERS                          |    7 +
 drivers/virtio/Kconfig               |   62 ++
 drivers/virtio/Makefile              |    5 +
 drivers/virtio/virtio_rtc_arm.c      |   22 +
 drivers/virtio/virtio_rtc_class.c    |  269 +++++
 drivers/virtio/virtio_rtc_driver.c   | 1357 ++++++++++++++++++++++++++
 drivers/virtio/virtio_rtc_internal.h |  122 +++
 drivers/virtio/virtio_rtc_ptp.c      |  342 +++++++
 include/uapi/linux/virtio_rtc.h      |  230 +++++
 kernel/time/timekeeping.c            |   24 +-
 10 files changed, 2428 insertions(+), 12 deletions(-)
 create mode 100644 drivers/virtio/virtio_rtc_arm.c
 create mode 100644 drivers/virtio/virtio_rtc_class.c
 create mode 100644 drivers/virtio/virtio_rtc_driver.c
 create mode 100644 drivers/virtio/virtio_rtc_internal.h
 create mode 100644 drivers/virtio/virtio_rtc_ptp.c
 create mode 100644 include/uapi/linux/virtio_rtc.h


base-commit: 2c41b211d72c1eb350c7629a8c85234fef0d12c1
-- 
2.40.1



From peter.hilber at opensynergy.com  Sun Dec 17 23:38:44 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Mon, 18 Dec 2023 08:38:44 +0100
Subject: [RFC PATCH v3 6/7] virtio_rtc: Add Arm Generic Timer cross-timestamping
In-Reply-To: <20231218073849.35294-1-peter.hilber@opensynergy.com>
References: <20231218073849.35294-1-peter.hilber@opensynergy.com>
Message-ID: <20231218073849.35294-7-peter.hilber@opensynergy.com>

Add PTP_SYS_OFFSET_PRECISE2 support on platforms using the Arm Generic
Timer.

Always report the CP15 virtual counter as the HW counter in use by
arm_arch_timer, since the Linux kernel's usage of the Arm Generic Timer
should always be compatible with this.

Signed-off-by: Peter Hilber <peter.hilber at opensynergy.com>
---

Notes:
    v2:
    
    - Depend on prerequisite patch series "treewide: Use clocksource id for
      get_device_system_crosststamp()".
    
    - Return clocksource id instead of calling dropped arm_arch_timer helpers.
    
    - Always report the CP15 virtual counter to be in use by arm_arch_timer,
      since distinction of Arm physical and virtual counter appears unneeded
      after discussion with Marc Zyngier.

 drivers/virtio/Kconfig          | 13 +++++++++++++
 drivers/virtio/Makefile         |  1 +
 drivers/virtio/virtio_rtc_arm.c | 22 ++++++++++++++++++++++
 3 files changed, 36 insertions(+)
 create mode 100644 drivers/virtio/virtio_rtc_arm.c

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 8542b2f20201..d35c728778d2 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -205,6 +205,19 @@ config VIRTIO_RTC_PTP
 
 	 If unsure, say Y.
 
+config VIRTIO_RTC_ARM
+	bool "Virtio RTC cross-timestamping using Arm Generic Timer"
+	default y
+	depends on VIRTIO_RTC_PTP && ARM_ARCH_TIMER
+	help
+	 This enables Virtio RTC cross-timestamping using the Arm Generic Timer.
+	 It only has an effect if the Virtio RTC device also supports this. The
+	 cross-timestamp is available through the PTP clock driver precise
+	 cross-timestamp ioctl (PTP_SYS_OFFSET_PRECISE2 or
+	 PTP_SYS_OFFSET_PRECISE).
+
+	 If unsure, say Y.
+
 endif # VIRTIO_RTC
 
 endif # VIRTIO_MENU
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 4d48cbcae6bb..781dff9f8822 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o
 obj-$(CONFIG_VIRTIO_RTC) += virtio_rtc.o
 virtio_rtc-y := virtio_rtc_driver.o
 virtio_rtc-$(CONFIG_VIRTIO_RTC_PTP) += virtio_rtc_ptp.o
+virtio_rtc-$(CONFIG_VIRTIO_RTC_ARM) += virtio_rtc_arm.o
diff --git a/drivers/virtio/virtio_rtc_arm.c b/drivers/virtio/virtio_rtc_arm.c
new file mode 100644
index 000000000000..5185b130b3f1
--- /dev/null
+++ b/drivers/virtio/virtio_rtc_arm.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Provides cross-timestamp params for Arm.
+ *
+ * Copyright (C) 2022-2023 OpenSynergy GmbH
+ */
+
+#include <linux/clocksource_ids.h>
+
+#include <uapi/linux/virtio_rtc.h>
+
+#include "virtio_rtc_internal.h"
+
+/* see header for doc */
+
+int viortc_hw_xtstamp_params(u16 *hw_counter, enum clocksource_ids *cs_id)
+{
+	*hw_counter = VIRTIO_RTC_COUNTER_ARM_VIRT;
+	*cs_id = CSID_ARM_ARCH_COUNTER;
+
+	return 0;
+}
-- 
2.40.1



From peter.hilber at opensynergy.com  Sun Dec 17 23:38:43 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Mon, 18 Dec 2023 08:38:43 +0100
Subject: [RFC PATCH v3 5/7] virtio_rtc: Add PTP clocks
In-Reply-To: <20231218073849.35294-1-peter.hilber@opensynergy.com>
References: <20231218073849.35294-1-peter.hilber@opensynergy.com>
Message-ID: <20231218073849.35294-6-peter.hilber@opensynergy.com>

Expose the virtio_rtc clocks as PTP clocks to userspace, similar to
ptp_kvm. virtio_rtc can expose multiple clocks, e.g. a UTC clock and a
monotonic clock. Userspace should distinguish different clocks through the
name assigned by the driver. A udev rule such as the following can be used
to get a symlink /dev/ptp_virtio to the UTC clock:

	SUBSYSTEM=="ptp", ATTR{clock_name}=="Virtio PTP UTC", SYMLINK += "ptp_virtio"

The preferred PTP clock reading method is ioctl PTP_SYS_OFFSET_PRECISE2,
through the ptp_clock_info.getcrosststamp() op. For now,
PTP_SYS_OFFSET_PRECISE2 will return -EOPNOTSUPP through a weak function.
PTP_SYS_OFFSET_PRECISE2 requires cross-timestamping support for specific
clocksources, which will be added in the following. If the clocksource
specific code is enabled, check that the Virtio RTC device supports the
respective HW counter before obtaining an actual cross-timestamp from the
Virtio device.

The Virtio RTC device response time may be higher than the timekeeper
seqcount increment interval. Therefore, obtain the cross-timestamp before
calling get_device_system_crosststamp().

As a fallback, support the ioctl PTP_SYS_OFFSET_EXTENDED2 for all
platforms.

Assume that concurrency issues during PTP clock removal are avoided by the
posix_clock framework.

Kconfig recursive dependencies prevent virtio_rtc from implicitly enabling
PTP_1588_CLOCK, therefore just warn the user if PTP_1588_CLOCK is not
available. Since virtio_rtc should in the future also expose clocks as RTC
class devices, do not have VIRTIO_RTC depend on PTP_1588_CLOCK.

Signed-off-by: Peter Hilber <peter.hilber at opensynergy.com>
---

Notes:
    v3:
    
    - don't guard cross-timestamping with feature bit (spec v3)
    
    - reduce clock id to 16 bits (spec v3)
    
    v2:
    
    - Depend on prerequisite patch series "treewide: Use clocksource id for
      get_device_system_crosststamp()".
    
    - Check clocksource id before sending crosststamp message to device.
    
    - Do not support multiple hardware counters at runtime any more, since
      distinction of Arm physical and virtual counter appears unneeded after
      discussion with Marc Zyngier.

 drivers/virtio/Kconfig               |  23 +-
 drivers/virtio/Makefile              |   1 +
 drivers/virtio/virtio_rtc_driver.c   | 131 +++++++++-
 drivers/virtio/virtio_rtc_internal.h |  46 ++++
 drivers/virtio/virtio_rtc_ptp.c      | 342 +++++++++++++++++++++++++++
 5 files changed, 539 insertions(+), 4 deletions(-)
 create mode 100644 drivers/virtio/virtio_rtc_ptp.c

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 834dd14bc070..8542b2f20201 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -179,11 +179,32 @@ config VIRTIO_RTC
 	depends on PTP_1588_CLOCK_OPTIONAL
 	help
 	 This driver provides current time from a Virtio RTC device. The driver
-	 provides the time through one or more clocks.
+	 provides the time through one or more clocks. The Virtio RTC PTP
+	 clocks must be enabled to expose the clocks to userspace.
 
 	 To compile this code as a module, choose M here: the module will be
 	 called virtio_rtc.
 
 	 If unsure, say M.
 
+if VIRTIO_RTC
+
+comment "WARNING: Consider enabling VIRTIO_RTC_PTP."
+	depends on !VIRTIO_RTC_PTP
+
+comment "Enable PTP_1588_CLOCK in order to enable VIRTIO_RTC_PTP."
+	depends on PTP_1588_CLOCK=n
+
+config VIRTIO_RTC_PTP
+	bool "Virtio RTC PTP clocks"
+	default y
+	depends on PTP_1588_CLOCK
+	help
+	 This exposes any Virtio RTC clocks as PTP Hardware Clocks (PHCs) to
+	 userspace.
+
+	 If unsure, say Y.
+
+endif # VIRTIO_RTC
+
 endif # VIRTIO_MENU
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index f760414ed6ab..4d48cbcae6bb 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o
 obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o
 obj-$(CONFIG_VIRTIO_RTC) += virtio_rtc.o
 virtio_rtc-y := virtio_rtc_driver.o
+virtio_rtc-$(CONFIG_VIRTIO_RTC_PTP) += virtio_rtc_ptp.o
diff --git a/drivers/virtio/virtio_rtc_driver.c b/drivers/virtio/virtio_rtc_driver.c
index ef1ea14b3bec..c331b7383285 100644
--- a/drivers/virtio/virtio_rtc_driver.c
+++ b/drivers/virtio/virtio_rtc_driver.c
@@ -35,11 +35,16 @@ struct viortc_vq {
  * struct viortc_dev - virtio_rtc device data
  * @vdev: virtio device
  * @vqs: virtqueues
+ * @clocks_to_unregister: Clock references, which are only used during device
+ *                        removal.
+ *			  For other uses, there would be a race between device
+ *			  creation and setting the pointers here.
  * @num_clocks: # of virtio_rtc clocks
  */
 struct viortc_dev {
 	struct virtio_device *vdev;
 	struct viortc_vq vqs[VIORTC_MAX_NR_QUEUES];
+	struct viortc_ptp_clock **clocks_to_unregister;
 	u16 num_clocks;
 };
 
@@ -626,6 +631,109 @@ int viortc_cross_cap(struct viortc_dev *viortc, u16 vio_clk_id, u16 hw_counter,
  * init, deinit
  */
 
+/**
+ * viortc_init_ptp_clock() - init and register PTP clock
+ * @viortc: device data
+ * @vio_clk_id: virtio_rtc clock id
+ * @clock_type: virtio_rtc clock type
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_init_ptp_clock(struct viortc_dev *viortc, u16 vio_clk_id,
+				 u16 clock_type)
+{
+	struct device *dev = &viortc->vdev->dev;
+	char ptp_clock_name[PTP_CLOCK_NAME_LEN];
+	const char *type_name;
+	/* fit prefix + u16 in decimal */
+	char type_name_buf[5 + 5 + 1];
+	struct viortc_ptp_clock *vio_ptp;
+
+	switch (clock_type) {
+	case VIRTIO_RTC_CLOCK_UTC:
+		type_name = "UTC";
+		break;
+	case VIRTIO_RTC_CLOCK_TAI:
+		type_name = "TAI";
+		break;
+	case VIRTIO_RTC_CLOCK_MONO:
+		type_name = "monotonic";
+		break;
+	default:
+		snprintf(type_name_buf, sizeof(type_name_buf), "type %hu",
+			 clock_type);
+		type_name = type_name_buf;
+	}
+
+	snprintf(ptp_clock_name, PTP_CLOCK_NAME_LEN, "Virtio PTP %s",
+		 type_name);
+
+	vio_ptp = viortc_ptp_register(viortc, dev, vio_clk_id, ptp_clock_name);
+	if (IS_ERR(vio_ptp)) {
+		dev_err(dev, "failed to register PTP clock '%s'\n",
+			ptp_clock_name);
+		return PTR_ERR(vio_ptp);
+	}
+
+	viortc->clocks_to_unregister[vio_clk_id] = vio_ptp;
+
+	if (!vio_ptp)
+		dev_warn(dev, "clock %d is not exposed to userspace\n",
+			 vio_clk_id);
+
+	return 0;
+}
+
+/**
+ * viortc_init_clock() - init local representation of virtio_rtc clock
+ * @viortc: device data
+ * @vio_clk_id: virtio_rtc clock id
+ *
+ * Initializes PHC and/or RTC class device to represent virtio_rtc clock.
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_init_clock(struct viortc_dev *viortc, u16 vio_clk_id)
+{
+	u16 clock_type;
+	int ret;
+
+	ret = viortc_clock_cap(viortc, vio_clk_id, &clock_type);
+	if (ret)
+		return ret;
+
+	if (IS_ENABLED(CONFIG_VIRTIO_RTC_PTP)) {
+		ret = viortc_init_ptp_clock(viortc, vio_clk_id, clock_type);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * viortc_clocks_exit() - unregister PHCs
+ * @viortc: device data
+ */
+static void viortc_clocks_exit(struct viortc_dev *viortc)
+{
+	unsigned int i;
+	struct viortc_ptp_clock *vio_ptp;
+
+	for (i = 0; i < viortc->num_clocks; i++) {
+		vio_ptp = viortc->clocks_to_unregister[i];
+
+		if (!vio_ptp)
+			continue;
+
+		viortc->clocks_to_unregister[i] = NULL;
+
+		WARN_ON(viortc_ptp_unregister(vio_ptp, &viortc->vdev->dev));
+	}
+}
+
 /**
  * viortc_clocks_init() - init local representations of virtio_rtc clocks
  * @viortc: device data
@@ -637,6 +745,7 @@ static int viortc_clocks_init(struct viortc_dev *viortc)
 {
 	int ret;
 	u16 num_clocks;
+	unsigned int i;
 
 	ret = viortc_cfg(viortc, &num_clocks);
 	if (ret)
@@ -649,8 +758,22 @@ static int viortc_clocks_init(struct viortc_dev *viortc)
 
 	viortc->num_clocks = num_clocks;
 
-	/* In the future, PTP clocks will be initialized here. */
-	(void)viortc_clock_cap;
+	viortc->clocks_to_unregister =
+		devm_kcalloc(&viortc->vdev->dev, num_clocks,
+			     sizeof(*viortc->clocks_to_unregister), GFP_KERNEL);
+	if (!viortc->clocks_to_unregister)
+		return -ENOMEM;
+
+	for (i = 0; i < num_clocks; i++) {
+		ret = viortc_init_clock(viortc, i);
+		if (ret)
+			goto err_free_clocks;
+	}
+
+	return 0;
+
+err_free_clocks:
+	viortc_clocks_exit(viortc);
 
 	return ret;
 }
@@ -734,7 +857,9 @@ static int viortc_probe(struct virtio_device *vdev)
  */
 static void viortc_remove(struct virtio_device *vdev)
 {
-	/* In the future, PTP clocks will be deinitialized here. */
+	struct viortc_dev *viortc = vdev->priv;
+
+	viortc_clocks_exit(viortc);
 
 	virtio_reset_device(vdev);
 	vdev->config->del_vqs(vdev);
diff --git a/drivers/virtio/virtio_rtc_internal.h b/drivers/virtio/virtio_rtc_internal.h
index 9267661b8030..0dedced4aeae 100644
--- a/drivers/virtio/virtio_rtc_internal.h
+++ b/drivers/virtio/virtio_rtc_internal.h
@@ -9,6 +9,7 @@
 #define _VIRTIO_RTC_INTERNAL_H_
 
 #include <linux/types.h>
+#include <linux/ptp_clock_kernel.h>
 
 /* driver core IFs */
 
@@ -20,4 +21,49 @@ int viortc_read_cross(struct viortc_dev *viortc, u16 vio_clk_id, u16 hw_counter,
 int viortc_cross_cap(struct viortc_dev *viortc, u16 vio_clk_id, u16 hw_counter,
 		     bool *supported);
 
+/* PTP IFs */
+
+struct viortc_ptp_clock;
+
+#if IS_ENABLED(CONFIG_VIRTIO_RTC_PTP)
+
+struct viortc_ptp_clock *viortc_ptp_register(struct viortc_dev *viortc,
+					     struct device *parent_dev,
+					     u16 vio_clk_id,
+					     const char *ptp_clock_name);
+int viortc_ptp_unregister(struct viortc_ptp_clock *vio_ptp,
+			  struct device *parent_dev);
+
+#else
+
+static inline struct viortc_ptp_clock *
+viortc_ptp_register(struct viortc_dev *viortc, struct device *parent_dev,
+		    u16 vio_clk_id, const char *ptp_clock_name)
+{
+	return NULL;
+}
+
+static inline int viortc_ptp_unregister(struct viortc_ptp_clock *vio_ptp,
+					struct device *parent_dev)
+{
+	return -ENODEV;
+}
+
+#endif
+
+/* HW counter IFs */
+
+/**
+ * viortc_hw_xtstamp_params() - get HW-specific xtstamp params
+ * @hw_counter: virtio_rtc HW counter type
+ * @cs_id: clocksource id corresponding to hw_counter
+ *
+ * Gets the HW-specific xtstamp params. Returns an error if the driver cannot
+ * support xtstamp.
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+int viortc_hw_xtstamp_params(u16 *hw_counter, enum clocksource_ids *cs_id);
+
 #endif /* _VIRTIO_RTC_INTERNAL_H_ */
diff --git a/drivers/virtio/virtio_rtc_ptp.c b/drivers/virtio/virtio_rtc_ptp.c
new file mode 100644
index 000000000000..4592cd070772
--- /dev/null
+++ b/drivers/virtio/virtio_rtc_ptp.c
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Expose virtio_rtc clocks as PTP clocks.
+ *
+ * Copyright (C) 2022-2023 OpenSynergy GmbH
+ *
+ * Derived from ptp_kvm_common.c, virtual PTP 1588 clock for use with KVM
+ * guests.
+ *
+ * Copyright (C) 2017 Red Hat Inc.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/ptp_clock_kernel.h>
+
+#include <uapi/linux/virtio_rtc.h>
+
+#include "virtio_rtc_internal.h"
+
+/**
+ * struct viortc_ptp_clock - PTP clock abstraction
+ * @ptp_clock: PTP clock handle
+ * @viortc: virtio_rtc device data
+ * @ptp_info: PTP clock description
+ * @vio_clk_id: virtio_rtc clock id
+ * @have_cross: device supports crosststamp with available HW counter
+ */
+struct viortc_ptp_clock {
+	struct ptp_clock *ptp_clock;
+	struct viortc_dev *viortc;
+	struct ptp_clock_info ptp_info;
+	u16 vio_clk_id;
+	bool have_cross;
+};
+
+/**
+ * struct viortc_ptp_cross_ctx - context for get_device_system_crosststamp()
+ * @device_time: device clock reading
+ * @system_counterval: HW counter value at device_time
+ *
+ * Provides the already obtained crosststamp to get_device_system_crosststamp().
+ */
+struct viortc_ptp_cross_ctx {
+	ktime_t device_time;
+	struct system_counterval_t system_counterval;
+};
+
+/* Weak function in case get_device_system_crosststamp() is not supported */
+int __weak viortc_hw_xtstamp_params(u16 *hw_counter,
+				    enum clocksource_ids *cs_id)
+{
+	return -EOPNOTSUPP;
+}
+
+/**
+ * viortc_ptp_get_time_fn() - callback for get_device_system_crosststamp()
+ * @device_time: device clock reading
+ * @system_counterval: HW counter value at device_time
+ * @ctx: context with already obtained crosststamp
+ *
+ * Return: zero (success).
+ */
+static int viortc_ptp_get_time_fn(ktime_t *device_time,
+				  struct system_counterval_t *system_counterval,
+				  void *ctx)
+{
+	struct viortc_ptp_cross_ctx *vio_ctx = ctx;
+
+	*device_time = vio_ctx->device_time;
+	*system_counterval = vio_ctx->system_counterval;
+
+	return 0;
+}
+
+/**
+ * viortc_ptp_do_xtstamp() - get crosststamp from device
+ * @vio_ptp: virtio_rtc PTP clock
+ * @ctx: context for get_device_system_crosststamp()
+ * @hw_counter: virtio_rtc HW counter type
+ * @cs_id: clocksource id corresponding to hw_counter
+ *
+ * Reads HW-specific crosststamp from device.
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_ptp_do_xtstamp(struct viortc_ptp_clock *vio_ptp,
+				 struct viortc_ptp_cross_ctx *ctx,
+				 u16 hw_counter, enum clocksource_ids cs_id)
+{
+	u64 ns;
+	u64 max_ns;
+	int ret;
+
+	ctx->system_counterval.cs_id = cs_id;
+
+	ret = viortc_read_cross(vio_ptp->viortc, vio_ptp->vio_clk_id,
+				hw_counter, &ns,
+				&ctx->system_counterval.cycles);
+	if (ret)
+		return ret;
+
+	max_ns = (u64)ktime_to_ns(KTIME_MAX);
+	if (ns > max_ns)
+		return -EINVAL;
+
+	ctx->device_time = ns_to_ktime(ns);
+
+	return 0;
+}
+
+/*
+ * PTP clock operations
+ */
+
+/**
+ * viortc_ptp_getcrosststamp() - PTP clock getcrosststamp op
+ * @vio_ptp: virtio_rtc PTP clock
+ * @xtstamp: crosststamp
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_ptp_getcrosststamp(struct ptp_clock_info *ptp,
+				     struct system_device_crosststamp *xtstamp)
+{
+	struct viortc_ptp_clock *vio_ptp =
+		container_of(ptp, struct viortc_ptp_clock, ptp_info);
+	int ret;
+	struct system_time_snapshot history_begin;
+	struct viortc_ptp_cross_ctx ctx;
+	enum clocksource_ids cs_id;
+	u16 hw_counter;
+
+	if (!vio_ptp->have_cross)
+		return -EOPNOTSUPP;
+
+	ret = viortc_hw_xtstamp_params(&hw_counter, &cs_id);
+	if (ret)
+		return ret;
+
+	ktime_get_snapshot(&history_begin);
+	if (history_begin.cs_id != cs_id)
+		return -EOPNOTSUPP;
+
+	/*
+	 * Getting the timestamp can take many milliseconds with a slow Virtio
+	 * device. This is too long for viortc_ptp_get_time_fn() passed to
+	 * get_device_system_crosststamp(), which has to usually return before
+	 * the timekeeper seqcount increases (every tick or so).
+	 *
+	 * So, get the actual cross-timestamp first.
+	 */
+	ret = viortc_ptp_do_xtstamp(vio_ptp, &ctx, hw_counter, cs_id);
+	if (ret)
+		return ret;
+
+	ret = get_device_system_crosststamp(viortc_ptp_get_time_fn, &ctx,
+					    &history_begin, xtstamp);
+	if (ret)
+		pr_debug("%s: get_device_system_crosststamp() returned %d\n",
+			 __func__, ret);
+
+	return ret;
+}
+
+/** viortc_ptp_adjfine() - unsupported PTP clock adjfine op */
+static int viortc_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
+{
+	return -EOPNOTSUPP;
+}
+
+/** viortc_ptp_adjtime() - unsupported PTP clock adjtime op */
+static int viortc_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
+{
+	return -EOPNOTSUPP;
+}
+
+/** viortc_ptp_settime64() - unsupported PTP clock settime64 op */
+static int viortc_ptp_settime64(struct ptp_clock_info *ptp,
+				const struct timespec64 *ts)
+{
+	return -EOPNOTSUPP;
+}
+
+/**
+ * viortc_ptp_gettimex64() - PTP clock gettimex64 op
+ *
+ * Context: Process context.
+ */
+static int viortc_ptp_gettimex64(struct ptp_clock_info *ptp,
+				 struct timespec64 *ts,
+				 struct ptp_system_timestamp *sts)
+{
+	struct viortc_ptp_clock *vio_ptp =
+		container_of(ptp, struct viortc_ptp_clock, ptp_info);
+	u64 ns;
+	int ret;
+
+	ptp_read_system_prets(sts);
+	ret = viortc_read(vio_ptp->viortc, vio_ptp->vio_clk_id, &ns);
+	ptp_read_system_postts(sts);
+
+	if (ret)
+		return ret;
+
+	if (ns > (u64)S64_MAX)
+		return -EINVAL;
+
+	*ts = ns_to_timespec64((s64)ns);
+
+	return 0;
+}
+
+/** viortc_ptp_enable() - unsupported PTP clock enable op */
+static int viortc_ptp_enable(struct ptp_clock_info *ptp,
+			     struct ptp_clock_request *rq, int on)
+{
+	return -EOPNOTSUPP;
+}
+
+/**
+ * viortc_ptp_info_template - ptp_clock_info template
+ *
+ * The .name member will be set for individual virtio_rtc PTP clocks.
+ */
+static const struct ptp_clock_info viortc_ptp_info_template = {
+	.owner = THIS_MODULE,
+	/* .name is set according to clock type */
+	.adjfine = viortc_ptp_adjfine,
+	.adjtime = viortc_ptp_adjtime,
+	.gettimex64 = viortc_ptp_gettimex64,
+	.settime64 = viortc_ptp_settime64,
+	.enable = viortc_ptp_enable,
+	.getcrosststamp = viortc_ptp_getcrosststamp,
+};
+
+/**
+ * viortc_ptp_unregister() - PTP clock unregistering wrapper
+ * @vio_ptp: virtio_rtc PTP clock
+ * @parent_dev: parent device of PTP clock
+ *
+ * Return: Zero on success, negative error code otherwise.
+ */
+int viortc_ptp_unregister(struct viortc_ptp_clock *vio_ptp,
+			  struct device *parent_dev)
+{
+	int ret = ptp_clock_unregister(vio_ptp->ptp_clock);
+
+	if (!ret)
+		devm_kfree(parent_dev, vio_ptp);
+
+	return ret;
+}
+
+/**
+ * viortc_ptp_get_cross_cap() - get xtstamp support info from device
+ * @viortc: virtio_rtc device data
+ * @vio_ptp: virtio_rtc PTP clock abstraction
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_ptp_get_cross_cap(struct viortc_dev *viortc,
+				    struct viortc_ptp_clock *vio_ptp)
+{
+	int ret;
+	enum clocksource_ids cs_id;
+	u16 hw_counter;
+	bool xtstamp_supported;
+
+	ret = viortc_hw_xtstamp_params(&hw_counter, &cs_id);
+	if (ret) {
+		vio_ptp->have_cross = false;
+		return 0;
+	}
+
+	ret = viortc_cross_cap(viortc, vio_ptp->vio_clk_id, hw_counter,
+			       &xtstamp_supported);
+	if (ret)
+		return ret;
+
+	vio_ptp->have_cross = xtstamp_supported;
+
+	return 0;
+}
+
+/**
+ * viortc_ptp_register() - prepare and register PTP clock
+ * @viortc: virtio_rtc device data
+ * @parent_dev: parent device for PTP clock
+ * @vio_clk_id: id of virtio_rtc clock which backs PTP clock
+ * @ptp_clock_name: PTP clock name
+ *
+ * Context: Process context.
+ * Return: Pointer on success, ERR_PTR() otherwise; NULL if PTP clock support
+ *         not available.
+ */
+struct viortc_ptp_clock *viortc_ptp_register(struct viortc_dev *viortc,
+					     struct device *parent_dev,
+					     u16 vio_clk_id,
+					     const char *ptp_clock_name)
+{
+	struct viortc_ptp_clock *vio_ptp;
+	struct ptp_clock *ptp_clock;
+	ssize_t len;
+	int ret;
+
+	vio_ptp = devm_kzalloc(parent_dev, sizeof(*vio_ptp), GFP_KERNEL);
+	if (!vio_ptp)
+		return ERR_PTR(-ENOMEM);
+
+	vio_ptp->viortc = viortc;
+	vio_ptp->vio_clk_id = vio_clk_id;
+	vio_ptp->ptp_info = viortc_ptp_info_template;
+	len = strscpy(vio_ptp->ptp_info.name, ptp_clock_name,
+		      sizeof(vio_ptp->ptp_info.name));
+	if (len < 0) {
+		ret = len;
+		goto err_free_dev;
+	}
+
+	ret = viortc_ptp_get_cross_cap(viortc, vio_ptp);
+	if (ret)
+		goto err_free_dev;
+
+	ptp_clock = ptp_clock_register(&vio_ptp->ptp_info, parent_dev);
+	if (IS_ERR(ptp_clock))
+		goto err_on_register;
+
+	vio_ptp->ptp_clock = ptp_clock;
+
+	return vio_ptp;
+
+err_on_register:
+	ret = PTR_ERR(ptp_clock);
+
+err_free_dev:
+	devm_kfree(parent_dev, vio_ptp);
+	return ERR_PTR(ret);
+}
-- 
2.40.1



From peter.hilber at opensynergy.com  Sun Dec 17 23:38:42 2023
From: peter.hilber at opensynergy.com (Peter Hilber)
Date: Mon, 18 Dec 2023 08:38:42 +0100
Subject: [RFC PATCH v3 4/7] virtio_rtc: Add module and driver core
In-Reply-To: <20231218073849.35294-1-peter.hilber@opensynergy.com>
References: <20231218073849.35294-1-peter.hilber@opensynergy.com>
Message-ID: <20231218073849.35294-5-peter.hilber@opensynergy.com>

Add the virtio_rtc module and driver core. The virtio_rtc module implements
a driver compatible with the proposed Virtio RTC device specification.
The Virtio RTC (Real Time Clock) device provides information about current
time. The device can provide different clocks, e.g. for the UTC or TAI time
standards, or for physical time elapsed since some past epoch. The driver
can read the clocks with simple or more accurate methods.

Implement the core, which interacts with the Virtio RTC device. Apart from
this, the core does not expose functionality outside of the virtio_rtc
module. A follow-up patch will expose PTP clocks.

Provide synchronous messaging, which is enough for the expected time
synchronization use cases through PTP clocks (similar to ptp_kvm) or RTC
Class driver.

Signed-off-by: Peter Hilber <peter.hilber at opensynergy.com>
---

Notes:
    v3:
    
    - merge readq and controlq into a single requestq (spec v3)
    
    - don't guard cross-timestamping with feature bit (spec v3)
    
    - pad message headers to 64 bits (spec v3)
    
    - reduce clock id to 16 bits (spec v3)
    
    - change Virtio status codes (spec v3)
    
    - use 'VIRTIO_RTC_REQ_' prefix for request messages (spec v3)

 MAINTAINERS                          |   7 +
 drivers/virtio/Kconfig               |  13 +
 drivers/virtio/Makefile              |   2 +
 drivers/virtio/virtio_rtc_driver.c   | 761 +++++++++++++++++++++++++++
 drivers/virtio/virtio_rtc_internal.h |  23 +
 include/uapi/linux/virtio_rtc.h      | 144 +++++
 6 files changed, 950 insertions(+)
 create mode 100644 drivers/virtio/virtio_rtc_driver.c
 create mode 100644 drivers/virtio/virtio_rtc_internal.h
 create mode 100644 include/uapi/linux/virtio_rtc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b589218605b4..0c157a19bbfd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23200,6 +23200,13 @@ S:	Maintained
 F:	drivers/nvdimm/nd_virtio.c
 F:	drivers/nvdimm/virtio_pmem.c
 
+VIRTIO RTC DRIVER
+M:	Peter Hilber <peter.hilber at opensynergy.com>
+L:	virtualization at lists.linux.dev
+S:	Maintained
+F:	drivers/virtio/virtio_rtc_*
+F:	include/uapi/linux/virtio_rtc.h
+
 VIRTIO SOUND DRIVER
 M:	Anton Yakovlev <anton.yakovlev at opensynergy.com>
 M:	"Michael S. Tsirkin" <mst at redhat.com>
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 0a53a61231c2..834dd14bc070 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -173,4 +173,17 @@ config VIRTIO_DMA_SHARED_BUFFER
 	 This option adds a flavor of dma buffers that are backed by
 	 virtio resources.
 
+config VIRTIO_RTC
+	tristate "Virtio RTC driver"
+	depends on VIRTIO
+	depends on PTP_1588_CLOCK_OPTIONAL
+	help
+	 This driver provides current time from a Virtio RTC device. The driver
+	 provides the time through one or more clocks.
+
+	 To compile this code as a module, choose M here: the module will be
+	 called virtio_rtc.
+
+	 If unsure, say M.
+
 endif # VIRTIO_MENU
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 8e98d24917cc..f760414ed6ab 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -12,3 +12,5 @@ obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
 obj-$(CONFIG_VIRTIO_VDPA) += virtio_vdpa.o
 obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o
 obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o
+obj-$(CONFIG_VIRTIO_RTC) += virtio_rtc.o
+virtio_rtc-y := virtio_rtc_driver.o
diff --git a/drivers/virtio/virtio_rtc_driver.c b/drivers/virtio/virtio_rtc_driver.c
new file mode 100644
index 000000000000..ef1ea14b3bec
--- /dev/null
+++ b/drivers/virtio/virtio_rtc_driver.c
@@ -0,0 +1,761 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * virtio_rtc driver core
+ *
+ * Copyright (C) 2022-2023 OpenSynergy GmbH
+ */
+
+#include <linux/completion.h>
+#include <linux/virtio.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_config.h>
+#include <linux/module.h>
+
+#include <uapi/linux/virtio_rtc.h>
+
+#include "virtio_rtc_internal.h"
+
+/* virtqueue order */
+enum {
+	VIORTC_REQUESTQ,
+	VIORTC_MAX_NR_QUEUES,
+};
+
+/**
+ * struct viortc_vq - virtqueue abstraction
+ * @vq: virtqueue
+ * @lock: protects access to vq
+ */
+struct viortc_vq {
+	struct virtqueue *vq;
+	spinlock_t lock;
+};
+
+/**
+ * struct viortc_dev - virtio_rtc device data
+ * @vdev: virtio device
+ * @vqs: virtqueues
+ * @num_clocks: # of virtio_rtc clocks
+ */
+struct viortc_dev {
+	struct virtio_device *vdev;
+	struct viortc_vq vqs[VIORTC_MAX_NR_QUEUES];
+	u16 num_clocks;
+};
+
+/**
+ * struct viortc_msg - Message requested by driver, responded by device.
+ * @viortc: device data
+ * @req: request buffer
+ * @resp: response buffer
+ * @responded: vqueue callback signals response reception
+ * @refcnt: Message reference count, message and buffers will be deallocated
+ *	    once 0. refcnt is decremented in the vqueue callback and in the
+ *	    thread waiting on the responded completion.
+ *          If a message response wait function times out, the message will be
+ *          freed upon late reception (refcnt will reach 0 in the callback), or
+ *          device removal.
+ * @req_size: size of request in bytes
+ * @resp_cap: maximum size of response in bytes
+ * @resp_actual_size: actual size of response
+ */
+struct viortc_msg {
+	struct viortc_dev *viortc;
+	void *req;
+	void *resp;
+	struct completion responded;
+	refcount_t refcnt;
+	unsigned int req_size;
+	unsigned int resp_cap;
+	unsigned int resp_actual_size;
+};
+
+/**
+ * viortc_msg_init() - Allocate and initialize requestq message.
+ * @viortc: device data
+ * @msg_type: virtio_rtc message type
+ * @req_size: size of request buffer to be allocated
+ * @resp_cap: size of response buffer to be allocated
+ *
+ * Initializes the message refcnt to 2. The refcnt will be decremented once in
+ * the virtqueue callback, and once in the thread waiting on the message (on
+ * completion or timeout).
+ *
+ * Context: Process context.
+ * Return: non-NULL on success.
+ */
+static struct viortc_msg *viortc_msg_init(struct viortc_dev *viortc,
+					  u16 msg_type, unsigned int req_size,
+					  unsigned int resp_cap)
+{
+	struct viortc_msg *msg;
+	struct device *dev = &viortc->vdev->dev;
+	struct virtio_rtc_req_head *req_head;
+
+	msg = devm_kzalloc(dev, sizeof(*msg), GFP_KERNEL);
+	if (!msg)
+		return NULL;
+
+	init_completion(&msg->responded);
+
+	msg->req = devm_kzalloc(dev, req_size, GFP_KERNEL);
+	if (!msg->req)
+		goto err_free_msg;
+
+	req_head = msg->req;
+
+	msg->resp = devm_kzalloc(dev, resp_cap, GFP_KERNEL);
+	if (!msg->resp)
+		goto err_free_msg_req;
+
+	msg->viortc = viortc;
+	msg->req_size = req_size;
+	msg->resp_cap = resp_cap;
+
+	refcount_set(&msg->refcnt, 2);
+
+	req_head->msg_type = virtio_cpu_to_le(msg_type, req_head->msg_type);
+
+	return msg;
+
+err_free_msg_req:
+	devm_kfree(dev, msg->req);
+
+err_free_msg:
+	devm_kfree(dev, msg);
+
+	return NULL;
+}
+
+/**
+ * viortc_msg_release() - Decrement message refcnt, potentially free message.
+ * @msg: message requested by driver
+ *
+ * Context: Any context.
+ */
+static void viortc_msg_release(struct viortc_msg *msg)
+{
+	if (refcount_dec_and_test(&msg->refcnt)) {
+		struct device *dev = &msg->viortc->vdev->dev;
+
+		devm_kfree(dev, msg->req);
+		devm_kfree(dev, msg->resp);
+		devm_kfree(dev, msg);
+	}
+}
+
+/**
+ * viortc_do_cb() - generic virtqueue callback logic
+ * @vq: virtqueue
+ * @handle_buf: function to process a used buffer
+ *
+ * Context: virtqueue callback, typically interrupt. Takes and releases vq lock.
+ */
+static void viortc_do_cb(struct virtqueue *vq,
+			 void (*handle_buf)(void *token, unsigned int len,
+					    struct virtqueue *vq,
+					    struct viortc_vq *viortc_vq,
+					    struct viortc_dev *viortc))
+{
+	struct viortc_dev *viortc = vq->vdev->priv;
+	struct viortc_vq *viortc_vq;
+	bool cb_enabled = true;
+	unsigned long flags;
+	spinlock_t *lock;
+	unsigned int len;
+	void *token;
+
+	viortc_vq = &viortc->vqs[vq->index];
+	lock = &viortc_vq->lock;
+
+	for (;;) {
+		spin_lock_irqsave(lock, flags);
+
+		if (cb_enabled) {
+			virtqueue_disable_cb(vq);
+			cb_enabled = false;
+		}
+
+		token = virtqueue_get_buf(vq, &len);
+		if (!token) {
+			if (virtqueue_enable_cb(vq)) {
+				spin_unlock_irqrestore(lock, flags);
+				return;
+			}
+			cb_enabled = true;
+		}
+
+		spin_unlock_irqrestore(lock, flags);
+
+		if (token)
+			handle_buf(token, len, vq, viortc_vq, viortc);
+	}
+}
+
+/**
+ * viortc_requestq_hdlr() - process a requestq used buffer
+ * @token: token identifying the buffer
+ * @len: bytes written by device
+ * @vq: virtqueue
+ * @viortc_vq: device specific data for virtqueue
+ * @viortc: device data
+ *
+ * Signals completion for each received message.
+ *
+ * Context: virtqueue callback
+ */
+static void viortc_requestq_hdlr(void *token, unsigned int len,
+				 struct virtqueue *vq,
+				 struct viortc_vq *viortc_vq,
+				 struct viortc_dev *viortc)
+{
+	struct viortc_msg *msg = token;
+
+	msg->resp_actual_size = len;
+
+	/*
+	 * completion waiter must see our msg metadata, but complete() does not
+	 * guarantee a memory barrier
+	 */
+	smp_wmb();
+
+	complete(&msg->responded);
+	viortc_msg_release(msg);
+}
+
+/**
+ * viortc_cb_requestq() - callback for requestq
+ * @vq: virtqueue
+ *
+ * Context: virtqueue callback
+ */
+static void viortc_cb_requestq(struct virtqueue *vq)
+{
+	viortc_do_cb(vq, viortc_requestq_hdlr);
+}
+
+/**
+ * viortc_get_resp_errno() - converts virtio_rtc errnos to system errnos
+ * @resp_head: message response header
+ *
+ * Return: negative system errno, or 0
+ */
+static int viortc_get_resp_errno(struct virtio_rtc_resp_head *resp_head)
+{
+	switch (virtio_le_to_cpu(resp_head->status)) {
+	case VIRTIO_RTC_S_OK:
+		return 0;
+	case VIRTIO_RTC_S_EOPNOTSUPP:
+		return -EOPNOTSUPP;
+	case VIRTIO_RTC_S_EINVAL:
+		return -EINVAL;
+	case VIRTIO_RTC_S_ENODEV:
+		return -ENODEV;
+	case VIRTIO_RTC_S_EIO:
+	default:
+		return -EIO;
+	}
+}
+
+/**
+ * viortc_msg_xfer() - send message request, wait until message response
+ * @vq: virtqueue
+ * @msg: message with driver request
+ * @timeout_jiffies: message response timeout, 0 for no timeout
+ *
+ * Context: Process context. Takes and releases vq.lock. May sleep.
+ */
+static int viortc_msg_xfer(struct viortc_vq *vq, struct viortc_msg *msg,
+			   unsigned long timeout_jiffies)
+{
+	int ret;
+	unsigned long flags;
+	struct scatterlist out_sg[1];
+	struct scatterlist in_sg[1];
+	struct scatterlist *sgs[2] = { out_sg, in_sg };
+	bool notify;
+
+	sg_init_one(out_sg, msg->req, msg->req_size);
+	sg_init_one(in_sg, msg->resp, msg->resp_cap);
+
+	spin_lock_irqsave(&vq->lock, flags);
+
+	ret = virtqueue_add_sgs(vq->vq, sgs, 1, 1, msg, GFP_ATOMIC);
+	if (ret) {
+		spin_unlock_irqrestore(&vq->lock, flags);
+		/*
+		 * Release in place of the response callback, which will never
+		 * come.
+		 */
+		viortc_msg_release(msg);
+		return ret;
+	}
+
+	notify = virtqueue_kick_prepare(vq->vq);
+
+	spin_unlock_irqrestore(&vq->lock, flags);
+
+	if (notify)
+		virtqueue_notify(vq->vq);
+
+	if (timeout_jiffies) {
+		long timeout_ret;
+
+		timeout_ret = wait_for_completion_interruptible_timeout(
+			&msg->responded, timeout_jiffies);
+
+		if (!timeout_ret)
+			return -ETIMEDOUT;
+		else if (timeout_ret < 0)
+			return (int)timeout_ret;
+	} else {
+		ret = wait_for_completion_interruptible(&msg->responded);
+		if (ret)
+			return ret;
+	}
+
+	/*
+	 * Ensure we can read message metadata written in the virtqueue
+	 * callback.
+	 */
+	smp_rmb();
+
+	/*
+	 * There is not yet a case where returning a short message would make
+	 * sense, so consider any deviation an error.
+	 */
+	if (msg->resp_actual_size != msg->resp_cap)
+		return -EINVAL;
+
+	return viortc_get_resp_errno(msg->resp);
+}
+
+/*
+ * common message handle macros for messages of different types
+ */
+
+/**
+ * VIORTC_DECLARE_MSG_HDL_ONSTACK() - declare message handle on stack
+ * @hdl: message handle name
+ * @msg_suf_lowerc: message type suffix in lowercase
+ * @msg_suf_upperc: message type suffix in uppercase
+ */
+#define VIORTC_DECLARE_MSG_HDL_ONSTACK(hdl, msg_suf_lowerc, msg_suf_upperc) \
+	struct {                                                            \
+		struct viortc_msg *msg;                                     \
+		struct virtio_rtc_req_##msg_suf_lowerc *req;                \
+		struct virtio_rtc_resp_##msg_suf_lowerc *resp;              \
+		unsigned int req_size;                                      \
+		unsigned int resp_cap;                                      \
+		u16 msg_type;                                               \
+	} hdl = {                                                           \
+		NULL,                                                       \
+		NULL,                                                       \
+		NULL,                                                       \
+		sizeof(struct virtio_rtc_req_##msg_suf_lowerc),             \
+		sizeof(struct virtio_rtc_resp_##msg_suf_lowerc),            \
+		VIRTIO_RTC_REQ_##msg_suf_upperc,                            \
+	}
+
+/**
+ * VIORTC_MSG() - extract message from message handle
+ *
+ * Return: struct viortc_msg
+ */
+#define VIORTC_MSG(hdl) ((hdl).msg)
+
+/**
+ * VIORTC_MSG_INIT() - initialize message handle
+ * @hdl: message handle
+ * @viortc: device data (struct viortc_dev *)
+ *
+ * Context: Process context.
+ * Return: 0 on success, -ENOMEM otherwise.
+ */
+#define VIORTC_MSG_INIT(hdl, viortc)                                         \
+	({                                                                   \
+		typeof(hdl) *_hdl = &(hdl);                                  \
+									     \
+		_hdl->msg = viortc_msg_init((viortc), _hdl->msg_type,        \
+					    _hdl->req_size, _hdl->resp_cap); \
+		if (_hdl->msg) {                                             \
+			_hdl->req = _hdl->msg->req;                          \
+			_hdl->resp = _hdl->msg->resp;                        \
+		}                                                            \
+		_hdl->msg ? 0 : -ENOMEM;                                     \
+	})
+
+/**
+ * VIORTC_MSG_WRITE() - write a request message field
+ * @hdl: message handle
+ * @dest_member: request message field name
+ * @src_ptr: pointer to data of compatible type
+ *
+ * Writes the field in little-endian format.
+ */
+#define VIORTC_MSG_WRITE(hdl, dest_member, src_ptr)                         \
+	do {                                                                \
+		typeof(hdl) _hdl = (hdl);                                   \
+		typeof(src_ptr) _src_ptr = (src_ptr);                       \
+									    \
+		/* Sanity check: must match the member's type */            \
+		typecheck(typeof(_hdl.req->dest_member), *_src_ptr);        \
+									    \
+		_hdl.req->dest_member =                                     \
+			virtio_cpu_to_le(*_src_ptr, _hdl.req->dest_member); \
+	} while (0)
+
+/**
+ * VIORTC_MSG_READ() - read from a response message field
+ * @hdl: message handle
+ * @src_member: response message field name
+ * @dest_ptr: pointer to data of compatible type
+ *
+ * Converts from little-endian format and writes to dest_ptr.
+ */
+#define VIORTC_MSG_READ(hdl, src_member, dest_ptr)                     \
+	do {                                                           \
+		typeof(dest_ptr) _dest_ptr = (dest_ptr);               \
+								       \
+		/* Sanity check: must match the member's type */       \
+		typecheck(typeof((hdl).resp->src_member), *_dest_ptr); \
+								       \
+		*_dest_ptr = virtio_le_to_cpu((hdl).resp->src_member); \
+	} while (0)
+
+/*
+ * read requests
+ */
+
+/** timeout for clock readings, where timeouts are considered non-fatal */
+#define VIORTC_MSG_READ_TIMEOUT (msecs_to_jiffies(60 * 1000))
+
+/**
+ * viortc_read() - VIRTIO_RTC_REQ_READ wrapper
+ * @viortc: device data
+ * @vio_clk_id: virtio_rtc clock id
+ * @reading: clock reading [ns]
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+int viortc_read(struct viortc_dev *viortc, u16 vio_clk_id, u64 *reading)
+{
+	int ret;
+	VIORTC_DECLARE_MSG_HDL_ONSTACK(hdl, read, READ);
+
+	ret = VIORTC_MSG_INIT(hdl, viortc);
+	if (ret)
+		return ret;
+
+	VIORTC_MSG_WRITE(hdl, clock_id, &vio_clk_id);
+
+	ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
+			      VIORTC_MSG_READ_TIMEOUT);
+	if (ret) {
+		dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
+			ret);
+		goto out_release;
+	}
+
+	VIORTC_MSG_READ(hdl, clock_reading, reading);
+
+out_release:
+	viortc_msg_release(VIORTC_MSG(hdl));
+
+	return ret;
+}
+
+/**
+ * viortc_read_cross() - VIRTIO_RTC_REQ_READ_CROSS wrapper
+ * @viortc: device data
+ * @vio_clk_id: virtio_rtc clock id
+ * @hw_counter: virtio_rtc HW counter type
+ * @reading: clock reading [ns]
+ * @cycles: HW counter cycles during clock reading
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+int viortc_read_cross(struct viortc_dev *viortc, u16 vio_clk_id, u16 hw_counter,
+		      u64 *reading, u64 *cycles)
+{
+	int ret;
+	VIORTC_DECLARE_MSG_HDL_ONSTACK(hdl, read_cross, READ_CROSS);
+
+	ret = VIORTC_MSG_INIT(hdl, viortc);
+	if (ret)
+		return ret;
+
+	VIORTC_MSG_WRITE(hdl, clock_id, &vio_clk_id);
+	VIORTC_MSG_WRITE(hdl, hw_counter, &hw_counter);
+
+	ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
+			      VIORTC_MSG_READ_TIMEOUT);
+	if (ret) {
+		dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
+			ret);
+		goto out_release;
+	}
+
+	VIORTC_MSG_READ(hdl, clock_reading, reading);
+	VIORTC_MSG_READ(hdl, counter_cycles, cycles);
+
+out_release:
+	viortc_msg_release(VIORTC_MSG(hdl));
+
+	return ret;
+}
+
+/*
+ * control requests
+ */
+
+/**
+ * viortc_cfg() - VIRTIO_RTC_REQ_CFG wrapper
+ * @viortc: device data
+ * @num_clocks: # of virtio_rtc clocks
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_cfg(struct viortc_dev *viortc, u16 *num_clocks)
+{
+	int ret;
+	VIORTC_DECLARE_MSG_HDL_ONSTACK(hdl, cfg, CFG);
+
+	ret = VIORTC_MSG_INIT(hdl, viortc);
+	if (ret)
+		return ret;
+
+	ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
+			      0);
+	if (ret) {
+		dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
+			ret);
+		goto out_release;
+	}
+
+	VIORTC_MSG_READ(hdl, num_clocks, num_clocks);
+
+out_release:
+	viortc_msg_release(VIORTC_MSG(hdl));
+
+	return ret;
+}
+
+/**
+ * viortc_clock_cap() - VIRTIO_RTC_REQ_CLOCK_CAP wrapper
+ * @viortc: device data
+ * @vio_clk_id: virtio_rtc clock id
+ * @type: virtio_rtc clock type
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_clock_cap(struct viortc_dev *viortc, u16 vio_clk_id,
+			    u16 *type)
+{
+	int ret;
+	VIORTC_DECLARE_MSG_HDL_ONSTACK(hdl, clock_cap, CLOCK_CAP);
+
+	ret = VIORTC_MSG_INIT(hdl, viortc);
+	if (ret)
+		return ret;
+
+	VIORTC_MSG_WRITE(hdl, clock_id, &vio_clk_id);
+
+	ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
+			      0);
+	if (ret) {
+		dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
+			ret);
+		goto out_release;
+	}
+
+	VIORTC_MSG_READ(hdl, type, type);
+
+out_release:
+	viortc_msg_release(VIORTC_MSG(hdl));
+
+	return ret;
+}
+
+/**
+ * viortc_cross_cap() - VIRTIO_RTC_REQ_CROSS_CAP wrapper
+ * @viortc: device data
+ * @vio_clk_id: virtio_rtc clock id
+ * @hw_counter: virtio_rtc HW counter type
+ * @supported: xtstamping is supported for the vio_clk_id/hw_counter pair
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+int viortc_cross_cap(struct viortc_dev *viortc, u16 vio_clk_id, u16 hw_counter,
+		     bool *supported)
+{
+	int ret;
+	VIORTC_DECLARE_MSG_HDL_ONSTACK(hdl, cross_cap, CROSS_CAP);
+	u8 flags;
+
+	ret = VIORTC_MSG_INIT(hdl, viortc);
+	if (ret)
+		return ret;
+
+	VIORTC_MSG_WRITE(hdl, clock_id, &vio_clk_id);
+	VIORTC_MSG_WRITE(hdl, hw_counter, &hw_counter);
+
+	ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
+			      0);
+	if (ret) {
+		dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
+			ret);
+		goto out_release;
+	}
+
+	VIORTC_MSG_READ(hdl, flags, &flags);
+	*supported = !!(flags & VIRTIO_RTC_FLAG_CROSS_CAP);
+
+out_release:
+	viortc_msg_release(VIORTC_MSG(hdl));
+
+	return ret;
+}
+
+/*
+ * init, deinit
+ */
+
+/**
+ * viortc_clocks_init() - init local representations of virtio_rtc clocks
+ * @viortc: device data
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_clocks_init(struct viortc_dev *viortc)
+{
+	int ret;
+	u16 num_clocks;
+
+	ret = viortc_cfg(viortc, &num_clocks);
+	if (ret)
+		return ret;
+
+	if (num_clocks < 1) {
+		dev_err(&viortc->vdev->dev, "device reported 0 clocks\n");
+		return -ENODEV;
+	}
+
+	viortc->num_clocks = num_clocks;
+
+	/* In the future, PTP clocks will be initialized here. */
+	(void)viortc_clock_cap;
+
+	return ret;
+}
+
+/**
+ * viortc_init_vqs() - init virtqueues
+ * @viortc: device data
+ *
+ * Inits virtqueues and associated data.
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_init_vqs(struct viortc_dev *viortc)
+{
+	int ret;
+	struct virtio_device *vdev = viortc->vdev;
+	const char *names[VIORTC_MAX_NR_QUEUES];
+	vq_callback_t *callbacks[VIORTC_MAX_NR_QUEUES];
+	struct virtqueue *vqs[VIORTC_MAX_NR_QUEUES];
+	int nr_queues;
+
+	nr_queues = VIORTC_REQUESTQ + 1;
+	names[VIORTC_REQUESTQ] = "requestq";
+	callbacks[VIORTC_REQUESTQ] = viortc_cb_requestq;
+
+	ret = virtio_find_vqs(vdev, nr_queues, vqs, callbacks, names, NULL);
+	if (ret)
+		return ret;
+
+	viortc->vqs[VIORTC_REQUESTQ].vq = vqs[VIORTC_REQUESTQ];
+	spin_lock_init(&viortc->vqs[VIORTC_REQUESTQ].lock);
+
+	return 0;
+}
+
+/**
+ * viortc_probe() - probe a virtio_rtc virtio device
+ * @vdev: virtio device
+ *
+ * Context: Process context.
+ * Return: Zero on success, negative error code otherwise.
+ */
+static int viortc_probe(struct virtio_device *vdev)
+{
+	struct viortc_dev *viortc;
+	int ret;
+
+	viortc = devm_kzalloc(&vdev->dev, sizeof(*viortc), GFP_KERNEL);
+	if (!viortc)
+		return -ENOMEM;
+
+	vdev->priv = viortc;
+	viortc->vdev = vdev;
+
+	ret = viortc_init_vqs(viortc);
+	if (ret)
+		return ret;
+
+	virtio_device_ready(vdev);
+
+	/* Ready vdev for use by frontend devices initialized next. */
+	smp_wmb();
+
+	ret = viortc_clocks_init(viortc);
+	if (ret)
+		goto err_reset_vdev;
+
+	return 0;
+
+err_reset_vdev:
+	virtio_reset_device(vdev);
+	vdev->config->del_vqs(vdev);
+
+	return ret;
+}
+
+/**
+ * viortc_remove() - remove a virtio_rtc virtio device
+ * @vdev: virtio device
+ */
+static void viortc_remove(struct virtio_device *vdev)
+{
+	/* In the future, PTP clocks will be deinitialized here. */
+
+	virtio_reset_device(vdev);
+	vdev->config->del_vqs(vdev);
+}
+
+static struct virtio_device_id id_table[] = {
+	{ VIRTIO_ID_CLOCK, VIRTIO_DEV_ANY_ID },
+	{ 0 },
+};
+MODULE_DEVICE_TABLE(virtio, id_table);
+
+static struct virtio_driver virtio_rtc_drv = {
+	.driver.name = KBUILD_MODNAME,
+	.driver.owner = THIS_MODULE,
+	.id_table = id_table,
+	.probe = viortc_probe,
+	.remove = viortc_remove,
+};
+
+module_virtio_driver(virtio_rtc_drv);
+
+MODULE_DESCRIPTION("Virtio RTC driver");
+MODULE_AUTHOR("OpenSynergy GmbH");
+MODULE_LICENSE("GPL");
diff --git a/drivers/virtio/virtio_rtc_internal.h b/drivers/virtio/virtio_rtc_internal.h
new file mode 100644
index 000000000000..9267661b8030
--- /dev/null
+++ b/drivers/virtio/virtio_rtc_internal.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * virtio_rtc internal interfaces
+ *
+ * Copyright (C) 2022-2023 OpenSynergy GmbH
+ */
+
+#ifndef _VIRTIO_RTC_INTERNAL_H_
+#define _VIRTIO_RTC_INTERNAL_H_
+
+#include <linux/types.h>
+
+/* driver core IFs */
+
+struct viortc_dev;
+
+int viortc_read(struct viortc_dev *viortc, u16 vio_clk_id, u64 *reading);
+int viortc_read_cross(struct viortc_dev *viortc, u16 vio_clk_id, u16 hw_counter,
+		      u64 *reading, u64 *cycles);
+int viortc_cross_cap(struct viortc_dev *viortc, u16 vio_clk_id, u16 hw_counter,
+		     bool *supported);
+
+#endif /* _VIRTIO_RTC_INTERNAL_H_ */
diff --git a/include/uapi/linux/virtio_rtc.h b/include/uapi/linux/virtio_rtc.h
new file mode 100644
index 000000000000..f469276562d7
--- /dev/null
+++ b/include/uapi/linux/virtio_rtc.h
@@ -0,0 +1,144 @@
+/* SPDX-License-Identifier: ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) */
+/*
+ * Copyright (C) 2022-2023 OpenSynergy GmbH
+ */
+
+#ifndef _LINUX_VIRTIO_RTC_H
+#define _LINUX_VIRTIO_RTC_H
+
+#include <linux/types.h>
+
+/* read request message types */
+
+#define VIRTIO_RTC_REQ_READ 0x0001
+#define VIRTIO_RTC_REQ_READ_CROSS 0x0002
+
+/* control request message types */
+
+#define VIRTIO_RTC_REQ_CFG 0x1000
+#define VIRTIO_RTC_REQ_CLOCK_CAP 0x1001
+#define VIRTIO_RTC_REQ_CROSS_CAP 0x1002
+
+/* Message headers */
+
+/** common request header */
+struct virtio_rtc_req_head {
+	__le16 msg_type;
+	__u8 reserved[6];
+};
+
+/** common response header */
+struct virtio_rtc_resp_head {
+#define VIRTIO_RTC_S_OK 0
+#define VIRTIO_RTC_S_EOPNOTSUPP 2
+#define VIRTIO_RTC_S_ENODEV 3
+#define VIRTIO_RTC_S_EINVAL 4
+#define VIRTIO_RTC_S_EIO 5
+	__u8 status;
+	__u8 reserved[7];
+};
+
+/* read requests */
+
+/* VIRTIO_RTC_REQ_READ message */
+
+struct virtio_rtc_req_read {
+	struct virtio_rtc_req_head head;
+	__le16 clock_id;
+	__u8 reserved[6];
+};
+
+struct virtio_rtc_resp_read {
+	struct virtio_rtc_resp_head head;
+	__le64 clock_reading;
+};
+
+/* VIRTIO_RTC_REQ_READ_CROSS message */
+
+struct virtio_rtc_req_read_cross {
+	struct virtio_rtc_req_head head;
+	__le16 clock_id;
+/** Arm Generic Timer Virtual Count */
+#define VIRTIO_RTC_COUNTER_ARM_VIRT 0
+/** Arm Generic Timer Physical Count */
+#define VIRTIO_RTC_COUNTER_ARM_PHYS 1
+/** x86 Time Stamp Counter */
+#define VIRTIO_RTC_COUNTER_X86_TSC 2
+	__le16 hw_counter;
+	__u8 reserved[4];
+};
+
+struct virtio_rtc_resp_read_cross {
+	struct virtio_rtc_resp_head head;
+	__le64 clock_reading;
+	__le64 counter_cycles;
+};
+
+/* control requests */
+
+/* VIRTIO_RTC_REQ_CFG message */
+
+struct virtio_rtc_req_cfg {
+	struct virtio_rtc_req_head head;
+	/* no request params */
+};
+
+struct virtio_rtc_resp_cfg {
+	struct virtio_rtc_resp_head head;
+	/** # of clocks -> clock ids < num_clocks are valid */
+	__le16 num_clocks;
+	__u8 reserved[6];
+};
+
+/* VIRTIO_RTC_REQ_CLOCK_CAP message */
+
+struct virtio_rtc_req_clock_cap {
+	struct virtio_rtc_req_head head;
+	__le16 clock_id;
+	__u8 reserved[6];
+};
+
+struct virtio_rtc_resp_clock_cap {
+	struct virtio_rtc_resp_head head;
+#define VIRTIO_RTC_CLOCK_UTC 0
+#define VIRTIO_RTC_CLOCK_TAI 1
+#define VIRTIO_RTC_CLOCK_MONO 2
+	__le16 type;
+	__u8 reserved[6];
+};
+
+/* VIRTIO_RTC_REQ_CROSS_CAP message */
+
+struct virtio_rtc_req_cross_cap {
+	struct virtio_rtc_req_head head;
+	__le16 clock_id;
+	__le16 hw_counter;
+	__u8 reserved[4];
+};
+
+struct virtio_rtc_resp_cross_cap {
+	struct virtio_rtc_resp_head head;
+#define VIRTIO_RTC_FLAG_CROSS_CAP (1 << 0)
+	__u8 flags;
+	__u8 reserved[7];
+};
+
+/** Union of request types for requestq */
+union virtio_rtc_req_requestq {
+	struct virtio_rtc_req_read read;
+	struct virtio_rtc_req_read_cross read_cross;
+	struct virtio_rtc_req_cfg cfg;
+	struct virtio_rtc_req_clock_cap clock_cap;
+	struct virtio_rtc_req_cross_cap cross_cap;
+};
+
+/** Union of response types for requestq */
+union virtio_rtc_resp_requestq {
+	struct virtio_rtc_resp_read read;
+	struct virtio_rtc_resp_read_cross read_cross;
+	struct virtio_rtc_resp_cfg cfg;
+	struct virtio_rtc_resp_clock_cap clock_cap;
+	struct virtio_rtc_resp_cross_cap cross_cap;
+};
+
+#endif /* _LINUX_VIRTIO_RTC_H */
-- 
2.40.1



From krzysztof.kozlowski at linaro.org  Sun Dec 17 23:48:54 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 08:48:54 +0100
Subject: [PATCH v7 3/5] dt-bindings: clock: mediatek: add clock
 controllers of MT7988
In-Reply-To: <07e76a544ce4392bcb88e34d5480e99bb7994618.1702849494.git.daniel@makrotopia.org>
References: <27f99db432e9ccc804cc5b6501d7d17d72cae879.1702849494.git.daniel@makrotopia.org>
 <07e76a544ce4392bcb88e34d5480e99bb7994618.1702849494.git.daniel@makrotopia.org>
Message-ID: <8dbb703f-f40c-49b6-8a8c-094ce1ac7ccb@linaro.org>

On 17/12/2023 22:49, Daniel Golle wrote:
> Add various clock controllers found in the MT7988 SoC to existing
> bindings (if applicable) and add files for the new ethwarp, mcusys
> and xfi-pll clock controllers not previously present in any SoC.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> ---
> v7:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From jun.ann.lai at intel.com  Sun Dec 17 23:51:32 2023
From: jun.ann.lai at intel.com (Lai Peter Jun Ann)
Date: Mon, 18 Dec 2023 15:51:32 +0800
Subject: [PATCH net v2 1/1] net: stmmac: fix incorrect flag check in timestamp interrupt
Message-ID: <1702885892-30369-1-git-send-email-jun.ann.lai@intel.com>

The driver should continue get the timestamp if STMMAC_FLAG_EXT_SNAPSHOT_EN
flag is set.

Fixes: aa5513f5d95f ("net: stmmac: replace the ext_snapshot_en field with a flag")
Cc: <stable at vger.kernel.org> # 6.6
Signed-off-by: Song Yoong Siang <yoong.siang.song at intel.com>
Signed-off-by: Lai Peter Jun Ann <jun.ann.lai at intel.com>
---
v2 changelog:
 - Add fix tag and stable at vger.kernel.org in email cc list.
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 540f6a4..f05bd75 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -237,7 +237,7 @@ static void timestamp_interrupt(struct stmmac_priv *priv)
 	 */
 	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
 
-	if (priv->plat->flags & STMMAC_FLAG_EXT_SNAPSHOT_EN)
+	if (!(priv->plat->flags & STMMAC_FLAG_EXT_SNAPSHOT_EN))
 		return;
 
 	num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
-- 
1.9.1



From tomi.valkeinen at ideasonboard.com  Sun Dec 17 23:53:59 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Mon, 18 Dec 2023 09:53:59 +0200
Subject: [PATCH 0/2] media: rkisp1: Fix shared interrupt handling
Message-ID: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>

First revert the commit that dropped IRQF_SHARED, as it is required
after all. Then fix the driver to handle shared irqs.

 Tomi

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
Tomi Valkeinen (2):
      Revert "media: rkisp1: Drop IRQF_SHARED"
      media: rkisp1: Fix IRQ handling due to shared interrupts

 .../platform/rockchip/rkisp1/rkisp1-capture.c      |  3 +++
 .../media/platform/rockchip/rkisp1/rkisp1-common.h |  2 ++
 .../media/platform/rockchip/rkisp1/rkisp1-csi.c    |  3 +++
 .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 24 +++++++++++++++++++++-
 .../media/platform/rockchip/rkisp1/rkisp1-isp.c    |  3 +++
 5 files changed, 34 insertions(+), 1 deletion(-)
---
base-commit: 02d4e62ae2452c83e4a3e279b8e4cb4dcbad4b31
change-id: 20231218-rkisp-shirq-fix-6c9ed3b42855

Best regards,
-- 
Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>



From tomi.valkeinen at ideasonboard.com  Sun Dec 17 23:54:01 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Mon, 18 Dec 2023 09:54:01 +0200
Subject: [PATCH 2/2] media: rkisp1: Fix IRQ handling due to shared
 interrupts
In-Reply-To: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>
References: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>
Message-ID: <20231218-rkisp-shirq-fix-v1-2-173007628248@ideasonboard.com>

The driver requests the interrupts as IRQF_SHARED, so the interrupt
handlers can be called at any time. If such a call happens while the ISP
is powered down, the SoC will hang as the driver tries to access the
ISP registers.

This can be reproduced even without the platform sharing the IRQ line:
Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will
hang.

Fix this by adding a new field, 'irqs_enabled', which is used to bail
out from the interrupt handler when the ISP is not operational.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 .../platform/rockchip/rkisp1/rkisp1-capture.c      |  3 +++
 .../media/platform/rockchip/rkisp1/rkisp1-common.h |  2 ++
 .../media/platform/rockchip/rkisp1/rkisp1-csi.c    |  3 +++
 .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 22 ++++++++++++++++++++++
 .../media/platform/rockchip/rkisp1/rkisp1-isp.c    |  3 +++
 5 files changed, 33 insertions(+)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index aebd3c12020b..c381c22135a2 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -725,6 +725,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
 	unsigned int i;
 	u32 status;
 
+	if (!rkisp1->irqs_enabled)
+		return IRQ_NONE;
+
 	status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
 	if (!status)
 		return IRQ_NONE;
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
index 4b6b28c05b89..b757f75edecf 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
@@ -450,6 +450,7 @@ struct rkisp1_debug {
  * @debug:	   debug params to be exposed on debugfs
  * @info:	   version-specific ISP information
  * @irqs:          IRQ line numbers
+ * @irqs_enabled:  the hardware is enabled and can cause interrupts
  */
 struct rkisp1_device {
 	void __iomem *base_addr;
@@ -471,6 +472,7 @@ struct rkisp1_device {
 	struct rkisp1_debug debug;
 	const struct rkisp1_info *info;
 	int irqs[RKISP1_NUM_IRQS];
+	bool irqs_enabled;
 };
 
 /*
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
index b6e47e2f1b94..4202642e0523 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
@@ -196,6 +196,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
 	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
 	u32 val, status;
 
+	if (!rkisp1->irqs_enabled)
+		return IRQ_NONE;
+
 	status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
 	if (!status)
 		return IRQ_NONE;
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index acc559652d6e..73cf08a74011 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -305,6 +305,24 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
 {
 	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
 
+	rkisp1->irqs_enabled = false;
+	/* Make sure the IRQ handler will see the above */
+	mb();
+
+	/*
+	 * Wait until any running IRQ handler has returned. The IRQ handler
+	 * may get called even after this (as it's a shared interrupt line)
+	 * but the 'irqs_enabled' flag will make the handler return immediately.
+	 */
+	for (unsigned int il = 0; il < ARRAY_SIZE(rkisp1->irqs); ++il) {
+		if (rkisp1->irqs[il] == -1)
+			continue;
+
+		/* Skip if the irq line is the same as previous */
+		if (il == 0 || rkisp1->irqs[il - 1] != rkisp1->irqs[il])
+			synchronize_irq(rkisp1->irqs[il]);
+	}
+
 	clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
 	return pinctrl_pm_select_sleep_state(dev);
 }
@@ -321,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
 	if (ret)
 		return ret;
 
+	rkisp1->irqs_enabled = true;
+	/* Make sure the IRQ handler will see the above */
+	mb();
+
 	return 0;
 }
 
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
index f00873d31c42..78a1f7a1499b 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
@@ -976,6 +976,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
 	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
 	u32 status, isp_err;
 
+	if (!rkisp1->irqs_enabled)
+		return IRQ_NONE;
+
 	status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
 	if (!status)
 		return IRQ_NONE;

-- 
2.34.1



From tomi.valkeinen at ideasonboard.com  Sun Dec 17 23:54:00 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Mon, 18 Dec 2023 09:54:00 +0200
Subject: [PATCH 1/2] Revert "media: rkisp1: Drop IRQF_SHARED"
In-Reply-To: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>
References: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>
Message-ID: <20231218-rkisp-shirq-fix-v1-1-173007628248@ideasonboard.com>

This reverts commit 85d2a31fe4d9be1555f621ead7a520d8791e0f74.

The rkisp1 does share interrupt lines on some platforms, after all. Thus
we need to revert this, and implement a fix for the rkisp1 shared irq
handling in a follow-up patch.

Reported-by: Mikhail Rudenko <mike.rudenko at gmail.com>
Closes: https://lore.kernel.org/all/87o7eo8vym.fsf at gmail.com/
Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
index f96f821a7b50..acc559652d6e 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
@@ -559,7 +559,7 @@ static int rkisp1_probe(struct platform_device *pdev)
 				rkisp1->irqs[il] = irq;
 		}
 
-		ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0,
+		ret = devm_request_irq(dev, irq, info->isrs[i].isr, IRQF_SHARED,
 				       dev_driver_string(dev), dev);
 		if (ret) {
 			dev_err(dev, "request irq failed: %d\n", ret);

-- 
2.34.1



From masahiroy at kernel.org  Mon Dec 18 00:01:27 2023
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Mon, 18 Dec 2023 17:01:27 +0900
Subject: [PATCH] efi/libstub: zboot: do not use $(shell ...) in cmd_copy_and_pad
Message-ID: <20231218080127.907460-1-masahiroy@kernel.org>

You do not need to use $(shell ...) in recipe lines, as they are already
executed in a shell. An alternative solution is $$(...), which is an
escaped sequence of the shell's command substituion, $(...).

For this case, there is a reason to avoid $(shell ...).

Kbuild detects command changes by using the if_changed macro, which
compares the previous command recorded in .*.cmd with the current
command from Makefile. If they differ, Kbuild re-runs the build rule.

To diff the commands, Make must expand $(shell ...) first. It means that
hexdump is executed every time, even when nothing needs rebuilding. If
Kbuild determines that vmlinux.bin needs rebuilding, hexdump will be
executed again to evaluate the 'cmd' macro, one more time to really
build vmlinux.bin, and finally yet again to record the expanded command
into .*.cmd.

Replace $(shell ...) with $$(...) to avoid multiple, unnecessay shell
evaluations. Since Make is agnostic about the shell code, $(...), the
if_changed macro compares the string "$(hexdump -s16 -n4 ...)" verbatim,
so hexdump is run only for building vmlinux.bin.

For the same reason, $(shell ...) in EFI_ZBOOT_OBJCOPY_FLAGS should be
eliminated.

While I was here, I replaced '&&' with ';' because a command for
if_changed is executed with 'set -e'.

Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>
---

 arch/arm64/boot/Makefile                    | 2 +-
 drivers/firmware/efi/libstub/Makefile.zboot | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
index 1761f5972443..a5a787371117 100644
--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
@@ -44,7 +44,7 @@ EFI_ZBOOT_BFD_TARGET	:= elf64-littleaarch64
 EFI_ZBOOT_MACH_TYPE	:= ARM64
 EFI_ZBOOT_FORWARD_CFI	:= $(CONFIG_ARM64_BTI_KERNEL)
 
-EFI_ZBOOT_OBJCOPY_FLAGS	= --add-symbol zboot_code_size=0x$(shell \
+EFI_ZBOOT_OBJCOPY_FLAGS	= --add-symbol zboot_code_size=0x$$( \
 				$(NM) vmlinux|grep _kernel_codesize|cut -d' ' -f1)
 
 include $(srctree)/drivers/firmware/efi/libstub/Makefile.zboot
diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot
index 2c489627a807..65ffd0b760b2 100644
--- a/drivers/firmware/efi/libstub/Makefile.zboot
+++ b/drivers/firmware/efi/libstub/Makefile.zboot
@@ -5,8 +5,8 @@
 # EFI_ZBOOT_FORWARD_CFI
 
 quiet_cmd_copy_and_pad = PAD     $@
-      cmd_copy_and_pad = cp $< $@ && \
-			 truncate -s $(shell hexdump -s16 -n4 -e '"%u"' $<) $@
+      cmd_copy_and_pad = cp $< $@; \
+			 truncate -s $$(hexdump -s16 -n4 -e '"%u"' $<) $@
 
 # Pad the file to the size of the uncompressed image in memory, including BSS
 $(obj)/vmlinux.bin: $(obj)/$(EFI_ZBOOT_PAYLOAD) FORCE
-- 
2.40.1



From monstr at monstr.eu  Mon Dec 18 00:09:03 2023
From: monstr at monstr.eu (Michal Simek)
Date: Mon, 18 Dec 2023 09:09:03 +0100
Subject: [GIT PULL RESEND] arm64: dts: ZynqMP DT changes for v6.8
Message-ID: <CAHTX3dLyA1Y9guLKSNJTChFVvkspMfTa0odULyAdcuFUSiSH3A@mail.gmail.com>

Hi,

please pull these changes to your tree. Most of those patches are related to dt
schema fixes or solving issues reported by W=1.
FYI: I have rebased the queue this week because Masahiro sent fixes tag Dec 12
against Rob's patch and wanted to record it.

I see origin email in lore here
https://lore.kernel.org/soc/678c4116-bb16-4d07-b70d-d417405c8266 at monstr.eu/T/#u
but I can't see it in patchwork that's why sending it again and see if
that goes through.

Thanks,
Michal


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-dt-for-6.8

for you to fetch changes up to a98b6987de7d44cb621294041364f70285b3d2c6:

  arm64: zynqmp: Add missing destination mailbox compatible
(2023-12-13 16:52:47 +0100)

----------------------------------------------------------------
arm64: ZynqMP DT changes for 6.8

- Fix overlay rules to remove KR260 targets
- Move ethernet phys to mdio node
- Fix couple of issues reported by W=1
 - Do not use _ in node names
 - Use lowercase in register address
 - Remove address/size-cells from nodes without child
 - Moved fixed clock to root on KV260
- Fix issues reported by dt-schema
 - additional compatible string for qspi on SOM
- Move arm/xilinx.yaml to soc vendor to cover also other archs
- Describe new Microblaze V qemu platform
- Add missing mailbox destination compatible string

----------------------------------------------------------------
Michal Simek (11):
      arm64: xilinx: Do not use '_' in DT node names
      arm64: xilinx: Use lower case for partition address
      arm64: xilinx: Remove mt25qu512a compatible string from SOM
      arm64: xilinx: Put ethernet phys to mdio node
      arm64: xilinx: Remove address/size-cells from flash node
      arm64: xilinx: Remove address/size-cells from gem nodes
      dt-bindings: soc: xilinx: Move xilinx.yaml from arm to soc
      dt-bindings: soc: Add new board description for MicroBlaze V
      arm64: zynqmp: Move fixed clock to / for kv260
      arm64: zynqmp: Fix clock node name in kv260 cards
      arm64: zynqmp: Add missing destination mailbox compatible

Rob Herring (1):
      arm64: dts: xilinx: Apply overlays to base dtbs

 Documentation/devicetree/bindings/{arm => soc/xilinx}/xilinx.yaml |  7 +++-
 MAINTAINERS                                                       |  1 +
 arch/arm64/boot/dts/xilinx/Makefile                               |  9 ++---
 arch/arm64/boot/dts/xilinx/zynqmp-sck-kv-g-revA.dtso              |
40 +++++++++----------
 arch/arm64/boot/dts/xilinx/zynqmp-sck-kv-g-revB.dtso              |
42 ++++++++++----------
 arch/arm64/boot/dts/xilinx/zynqmp-sm-k26-revA.dts                 |  8 ++--
 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts            |  8 +++-
 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts            | 16 +++++---
 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts            |  8 +++-
 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts            |
26 +++++++-----
 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts            |  8 +++-
 arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts                 |  4 +-
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi                            | 15 ++-----
 13 files changed, 104 insertions(+), 88 deletions(-)
 rename Documentation/devicetree/bindings/{arm => soc/xilinx}/xilinx.yaml (95%)

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs


From oliver.sang at intel.com  Mon Dec 18 00:10:49 2023
From: oliver.sang at intel.com (kernel test robot)
Date: Mon, 18 Dec 2023 16:10:49 +0800
Subject: [PATCH net-next v4 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <20231215171237.1152563-2-maxime.chevallier@bootlin.com>
Message-ID: <202312181512.79005cd3-oliver.sang@intel.com>



Hello,

kernel test robot noticed "assertion_failed" on:

commit: 78b410e5a385c625b85bdfec9acdee79b20f4907 ("[PATCH net-next v4 01/13] net: phy: Introduce ethernet link topology representation")
url: https://github.com/intel-lab-lkp/linux/commits/Maxime-Chevallier/net-phy-Introduce-ethernet-link-topology-representation/20231216-012641
base: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git e91db1614abae0cca248040c78b2c25f8dd97872
patch link: https://lore.kernel.org/all/20231215171237.1152563-2-maxime.chevallier at bootlin.com/
patch subject: [PATCH net-next v4 01/13] net: phy: Introduce ethernet link topology representation

in testcase: boot

compiler: gcc-9
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G

(please refer to attached dmesg/kmsg for entire log/backtrace)


+------------------------------------------------------------------------------+------------+------------+
|                                                                              | e91db1614a | 78b410e5a3 |
+------------------------------------------------------------------------------+------------+------------+
| assertion_failed                                                             | 0          | 8          |
| WARNING:at_drivers/net/phy/phy_link_topology.c:#phy_link_topo_add_phy        | 0          | 8          |
| EIP:phy_link_topo_add_phy                                                    | 0          | 8          |
+------------------------------------------------------------------------------+------------+------------+


If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang at intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202312181512.79005cd3-oliver.sang at intel.com


[   48.548859][   T36] ------------[ cut here ]------------
[   48.550106][   T36] RTNL: assertion failed at drivers/net/phy/phy_link_topology.c (35)
[ 48.552023][ T36] WARNING: CPU: 1 PID: 36 at drivers/net/phy/phy_link_topology.c:35 phy_link_topo_add_phy (drivers/net/phy/phy_link_topology.c:35 (discriminator 3)) 
[   48.554496][   T36] Modules linked in:
[   48.555406][   T36] CPU: 1 PID: 36 Comm: kworker/u4:1 Not tainted 6.7.0-rc5-01059-g78b410e5a385 #1 4e624fcd33c509a5c53c7f4349cb3dc9014b8795
[   48.558523][   T36] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[   48.560890][   T36] Workqueue: events_unbound deferred_probe_work_func
[ 48.562460][ T36] EIP: phy_link_topo_add_phy (drivers/net/phy/phy_link_topology.c:35 (discriminator 3)) 
[ 48.563694][ T36] Code: 26 00 00 00 00 80 3d 39 c7 19 d6 00 0f 85 f0 fe ff ff 6a 23 68 18 3d 99 d5 68 b0 96 88 d5 c6 05 39 c7 19 d6 01 e8 13 1a 3e ff <0f> 0b 83 c4 0c e9 ce fe ff ff bb f4 ff ff ff e9 fe fe ff ff cc cc
All code
========
   0:	26 00 00             	add    %al,%es:(%rax)
   3:	00 00                	add    %al,(%rax)
   5:	80 3d 39 c7 19 d6 00 	cmpb   $0x0,-0x29e638c7(%rip)        # 0xffffffffd619c745
   c:	0f 85 f0 fe ff ff    	jne    0xffffffffffffff02
  12:	6a 23                	pushq  $0x23
  14:	68 18 3d 99 d5       	pushq  $0xffffffffd5993d18
  19:	68 b0 96 88 d5       	pushq  $0xffffffffd58896b0
  1e:	c6 05 39 c7 19 d6 01 	movb   $0x1,-0x29e638c7(%rip)        # 0xffffffffd619c75e
  25:	e8 13 1a 3e ff       	callq  0xffffffffff3e1a3d
  2a:*	0f 0b                	ud2    		<-- trapping instruction
  2c:	83 c4 0c             	add    $0xc,%esp
  2f:	e9 ce fe ff ff       	jmpq   0xffffffffffffff02
  34:	bb f4 ff ff ff       	mov    $0xfffffff4,%ebx
  39:	e9 fe fe ff ff       	jmpq   0xffffffffffffff3c
  3e:	cc                   	int3   
  3f:	cc                   	int3   

Code starting with the faulting instruction
===========================================
   0:	0f 0b                	ud2    
   2:	83 c4 0c             	add    $0xc,%esp
   5:	e9 ce fe ff ff       	jmpq   0xfffffffffffffed8
   a:	bb f4 ff ff ff       	mov    $0xfffffff4,%ebx
   f:	e9 fe fe ff ff       	jmpq   0xffffffffffffff12
  14:	cc                   	int3   
  15:	cc                   	int3   
[   48.568132][   T36] EAX: 00000042 EBX: edf5a000 ECX: 00000000 EDX: d5eb634c
[   48.569726][   T36] ESI: c38c96b8 EDI: 00000000 EBP: c0cf7d0c ESP: c0cf7cf0
[   48.571374][   T36] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010286
[   48.573237][   T36] CR0: 80050033 CR2: b7d88778 CR3: 16543000 CR4: 00040690
[   48.574846][   T36] Call Trace:
[ 48.575546][ T36] ? show_regs (arch/x86/kernel/dumpstack.c:479) 
[ 48.576634][ T36] ? phy_link_topo_add_phy (drivers/net/phy/phy_link_topology.c:35 (discriminator 3)) 
[ 48.577915][ T36] ? __warn (kernel/panic.c:677) 
[ 48.578810][ T36] ? phy_link_topo_add_phy (drivers/net/phy/phy_link_topology.c:35 (discriminator 3)) 
[ 48.580194][ T36] ? report_bug (lib/bug.c:201 lib/bug.c:219) 
[ 48.581234][ T36] ? exc_overflow (arch/x86/kernel/traps.c:250) 
[ 48.582213][ T36] ? handle_bug (arch/x86/kernel/traps.c:216) 
[ 48.583120][ T36] ? exc_invalid_op (arch/x86/kernel/traps.c:258 (discriminator 1)) 
[ 48.584185][ T36] ? handle_exception (arch/x86/entry/entry_32.S:1049) 
[ 48.585295][ T36] ? exc_overflow (arch/x86/kernel/traps.c:250) 
[ 48.586339][ T36] ? phy_link_topo_add_phy (drivers/net/phy/phy_link_topology.c:35 (discriminator 3)) 
[ 48.587595][ T36] ? exc_overflow (arch/x86/kernel/traps.c:250) 
[ 48.588689][ T36] ? phy_link_topo_add_phy (drivers/net/phy/phy_link_topology.c:35 (discriminator 3)) 
[ 48.589870][ T36] phy_attach_direct (drivers/net/phy/phy_device.c:1504) 
[ 48.590857][ T36] phylink_connect_phy (drivers/net/phy/phylink.c:1958) 
[ 48.591949][ T36] dsa_user_create (net/dsa/user.c:2495 net/dsa/user.c:2530 net/dsa/user.c:2668) 
[ 48.592985][ T36] dsa_port_setup (net/dsa/dsa.c:524) 
[ 48.593974][ T36] dsa_tree_setup (net/dsa/dsa.c:764 net/dsa/dsa.c:893) 
[ 48.595049][ T36] dsa_register_switch (net/dsa/dsa.c:1530 net/dsa/dsa.c:1544) 
[ 48.596350][ T36] dsa_loop_drv_probe (drivers/net/dsa/dsa_loop.c:344) 
[ 48.597483][ T36] mdio_probe (drivers/net/phy/mdio_device.c:165) 
[ 48.598357][ T36] really_probe (drivers/base/dd.c:579 drivers/base/dd.c:658) 
[ 48.599353][ T36] __driver_probe_device (drivers/base/dd.c:800) 
[ 48.600558][ T36] driver_probe_device (drivers/base/dd.c:830) 
[ 48.601690][ T36] __device_attach_driver (drivers/base/dd.c:959) 
[ 48.602883][ T36] bus_for_each_drv (drivers/base/bus.c:457) 
[ 48.604077][ T36] __device_attach (drivers/base/dd.c:1030) 
[ 48.605140][ T36] ? driver_probe_device (drivers/base/dd.c:922) 
[ 48.606221][ T36] device_initial_probe (drivers/base/dd.c:1080) 
[ 48.607390][ T36] bus_probe_device (drivers/base/bus.c:532) 
[ 48.608551][ T36] deferred_probe_work_func (drivers/base/dd.c:124) 
[ 48.609781][ T36] process_one_work (include/linux/jump_label.h:207 include/linux/jump_label.h:207 include/trace/events/workqueue.h:108 kernel/workqueue.c:2632) 
[ 48.611053][ T36] process_scheduled_works (kernel/workqueue.c:2694) 
[ 48.612380][ T36] worker_thread (kernel/workqueue.c:2781) 
[ 48.613437][ T36] kthread (kernel/kthread.c:388) 
[ 48.614365][ T36] ? rescuer_thread (kernel/workqueue.c:2727) 
[ 48.616138][ T36] ? kthread_complete_and_exit (kernel/kthread.c:341) 
[ 48.617344][ T36] ret_from_fork (arch/x86/kernel/process.c:153) 
[ 48.618342][ T36] ? kthread_complete_and_exit (kernel/kthread.c:341) 
[ 48.619647][ T36] ret_from_fork_asm (arch/x86/entry/entry_32.S:741) 
[ 48.620892][ T36] entry_INT80_32 (arch/x86/entry/entry_32.S:947) 
[   48.622004][   T36] irq event stamp: 35465
[ 48.622981][ T36] hardirqs last enabled at (35473): console_unlock (arch/x86/include/asm/irqflags.h:42 arch/x86/include/asm/irqflags.h:77 arch/x86/include/asm/irqflags.h:135 kernel/printk/printk.c:341 kernel/printk/printk.c:2706 kernel/printk/printk.c:3038) 
[ 48.625036][ T36] hardirqs last disabled at (35482): console_unlock (kernel/printk/printk.c:339 kernel/printk/printk.c:2706 kernel/printk/printk.c:3038) 
[ 48.626997][ T36] softirqs last enabled at (35420): __do_softirq (arch/x86/include/asm/preempt.h:27 kernel/softirq.c:400 kernel/softirq.c:582) 
[ 48.628965][ T36] softirqs last disabled at (35415): do_softirq_own_stack (arch/x86/kernel/irq_32.c:57 arch/x86/kernel/irq_32.c:147) 
[   48.631005][   T36] ---[ end trace 0000000000000000 ]---
[   48.632508][   T36] dsa-loop fixed-0:1f lan1 (uninitialized): PHY [dsa-0.0:00] driver [Generic PHY] (irq=POLL)
[   48.637526][   T36] dsa-loop fixed-0:1f lan2 (uninitialized): PHY [dsa-0.0:01] driver [Generic PHY] (irq=POLL)
[   48.654535][   T36] dsa-loop fixed-0:1f lan3 (uninitialized): PHY [dsa-0.0:02] driver [Generic PHY] (irq=POLL)
[   48.659100][   T36] dsa-loop fixed-0:1f lan4 (uninitialized): PHY [dsa-0.0:03] driver [Generic PHY] (irq=POLL)
[   48.663920][   T36] DSA: tree 0 setup
[   48.664854][   T36] dsa-loop fixed-0:1f: DSA mockup driver: 0x1f



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20231218/202312181512.79005cd3-oliver.sang at intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki



From johan at kernel.org  Mon Dec 18 00:35:04 2023
From: johan at kernel.org (Johan Hovold)
Date: Mon, 18 Dec 2023 09:35:04 +0100
Subject: [PATCH v1] treewide, serdev: change receive_buf() return type to
 size_t
In-Reply-To: <ZXyH1Zv3Pxd6S3ag@francesco-nb.int.toradex.com>
References: <20231214170146.641783-1-francesco@dolcini.it>
 <ZXxWX-Fw1InID2ax@hovoldconsulting.com>
 <ZXxa7yzKzG6048vw@francesco-nb.int.toradex.com>
 <ZXx8bCVyxJ9Ddvqm@hovoldconsulting.com>
 <ZXyH1Zv3Pxd6S3ag@francesco-nb.int.toradex.com>
Message-ID: <ZYAEOCMwZGMNvpNX@hovoldconsulting.com>

On Fri, Dec 15, 2023 at 06:07:33PM +0100, Francesco Dolcini wrote:

> On Fri, Dec 15, 2023 at 05:18:52PM +0100, Johan Hovold wrote:
> > On Fri, Dec 15, 2023 at 02:55:59PM +0100, Francesco Dolcini wrote:
> > > To me the change is correct, with that said probably this should have
> > > been explicitly mentioned in the commit message or a separate
> > > preparation patch.
> > 
> > It's a separate change and should not be hidden away in a tree-wide
> > change that goes through a different maintainer.
> > 
> > Please drop this change from this patch and resubmit it separately to me
> > if you want and I'll review when I have the time.
> 
> Fine, I agree.
> 
> I see those options (let me know if you see other options I have not
> mentioned):
> 
> 1. I add this change (taking into account also intel ice) as a separate
>    patch in this series and you may just ack it and Greg could merge
>    together with the serdev one.
> 2. I prepare an independent patch for the GNSS change and only once this
>    is merged I'll send a rebased v2 of this one.
> 3. I update this patch without this GNSS API change, that mean I will
>    have to cast away the signed type from a few GNSS drivers.
> 
> 1 is my preferred option, 2 is fine, but it seems a little bit of overdoing,
> 3 I would avoid, we are doing this cleanup to be a little bit more
> strongly typed and to prevent the kind of bugs that is the original trigger
> for this patch.

Changing the return type of gnss_insert_raw() is going to be a bit more
involved and should be done in a separate patch (e.g. you need to look
at gnss_usb_rx_complete() and ice_gnss_read() to avoid introducing new
warnings there).

And both option 2 and 3 will introduce conversion warnings (W=3, which
we have plenty of anyway) unless you add casts.

I suggest you go with 3, unless you insist on 2.

Johan


From jason-jh.lin at mediatek.com  Mon Dec 18 00:36:02 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Mon, 18 Dec 2023 16:36:02 +0800
Subject: [PATCH 1/3] dt-bindings: mailbox: mediatek,gce-mailbox: Add mediatek,gce-events definition
In-Reply-To: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
Message-ID: <20231218083604.7327-2-jason-jh.lin@mediatek.com>

Since mediatek,gce-events property is a HW event signal from GCE,
it should be defined in mediatek,gce-mailbox.yaml and change the
description of mediatek,gce-events property in other bindings to
reference mediatek,gce-mailbox.yaml.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 .../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml  | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
index cef9d7601398..e4da0a58c943 100644
--- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
@@ -49,6 +49,13 @@ properties:
     items:
       - const: gce
 
+  mediatek,gce-events:
+    description:
+      The event id which is mapping to the specific hardware event signal
+      to gce. The event id is defined in the gce header
+      include/dt-bindings/gce/<chip>-gce.h of each chips.
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
 required:
   - compatible
   - "#mbox-cells"
-- 
2.18.0



From jason-jh.lin at mediatek.com  Mon Dec 18 00:36:01 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Mon, 18 Dec 2023 16:36:01 +0800
Subject: [PATCH 0/3] Add mediatek,gce-events definition to mediatek,gce-mailbox bindings
Message-ID: <20231218083604.7327-1-jason-jh.lin@mediatek.com>

From: Jason-jh Lin <jason-jh.lin at mediatek.corp-partner.google.com>

Since mediatek,gce-events property is a HW event signal from GCE,
it should be defined in mediatek,gce-mailbox.yaml.

Change the description of mediatek,gce-events property existed in
other bindings to reference mediatek,gce-mailbox.yaml.

Jason-JH.Lin (3):
  dt-bindings: mailbox: mediatek,gce-mailbox: Add mediatek,gce-events
    definition
  dt-bindings: media: mediatek-mdp: Change the description of gce-events
  dt-bindings: soc: mediatek: Change the description of gce-events

 .../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml  | 7 +++++++
 .../devicetree/bindings/media/mediatek,mdp3-rdma.yaml      | 5 +----
 .../devicetree/bindings/media/mediatek,mdp3-rsz.yaml       | 5 +----
 .../devicetree/bindings/media/mediatek,mdp3-wrot.yaml      | 5 +----
 .../devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml   | 5 +----
 .../devicetree/bindings/soc/mediatek/mediatek,mutex.yaml   | 5 +----
 .../devicetree/bindings/soc/mediatek/mediatek,wdma.yaml    | 5 +----
 7 files changed, 13 insertions(+), 24 deletions(-)

-- 
2.18.0



From jason-jh.lin at mediatek.com  Mon Dec 18 00:36:03 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Mon, 18 Dec 2023 16:36:03 +0800
Subject: [PATCH 2/3] dt-bindings: media: mediatek-mdp: Change the description of gce-events
In-Reply-To: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
Message-ID: <20231218083604.7327-3-jason-jh.lin@mediatek.com>

Change the description of mediatek,gce-events property to reference
mediatek,gce-mailbox.yaml.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 .../devicetree/bindings/media/mediatek,mdp3-rdma.yaml        | 5 +----
 .../devicetree/bindings/media/mediatek,mdp3-rsz.yaml         | 5 +----
 .../devicetree/bindings/media/mediatek,mdp3-wrot.yaml        | 5 +----
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index 7032c7e15039..adb3df4731f6 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -40,10 +40,7 @@ properties:
 
   mediatek,gce-events:
     description:
-      The event id which is mapping to the specific hardware event signal
-      to gce. The event id is defined in the gce header
-      include/dt-bindings/gce/<chip>-gce.h of each chips.
-    $ref: /schemas/types.yaml#/definitions/uint32-array
+      Reference to Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml.
 
   power-domains:
     maxItems: 1
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
index 78f9de6192ef..ddf66e3d5ad7 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
@@ -36,10 +36,7 @@ properties:
 
   mediatek,gce-events:
     description:
-      The event id which is mapping to the specific hardware event signal
-      to gce. The event id is defined in the gce header
-      include/dt-bindings/gce/<chip>-gce.h of each chips.
-    $ref: /schemas/types.yaml#/definitions/uint32-array
+      Reference to Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml.
 
   clocks:
     minItems: 1
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
index 0baa77198fa2..ca37b45e24b4 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
@@ -36,10 +36,7 @@ properties:
 
   mediatek,gce-events:
     description:
-      The event id which is mapping to the specific hardware event signal
-      to gce. The event id is defined in the gce header
-      include/dt-bindings/gce/<chip>-gce.h of each chips.
-    $ref: /schemas/types.yaml#/definitions/uint32-array
+      Reference to Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml.
 
   power-domains:
     maxItems: 1
-- 
2.18.0



From mripard at kernel.org  Mon Dec 18 00:38:33 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 09:38:33 +0100
Subject: [PATCH v2 04/27] drm/rockchip: inno_hdmi: Remove useless
 mode_fixup
In-Reply-To: <20231216162639.125215-5-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-5-knaerzche@gmail.com>
Message-ID: <2dzoew242wpbmxx6bnhoe27rugtcgwz4xxcsytsshkcotmyry5@5voq5jrwxww7>

Hi,

On Sat, Dec 16, 2023 at 05:26:15PM +0100, Alex Bee wrote:
> From: Maxime Ripard <mripard at kernel.org>
> 
> The mode_fixup implementation doesn't do anything, so we can simply
> remove it.
> 
> Signed-off-by: Maxime Ripard <mripard at kernel.org>
> Tested-by: Alex Bee <knaerzche at gmail.com>

Generally speaking, when you're sending patches you should always have
your SoB. That is true for the commit you authored, but also for the
commits you applied and are sending on the author's behalf.

This applies to all the other patches

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/be31989c/attachment-0001.sig>

From jason-jh.lin at mediatek.com  Mon Dec 18 00:36:04 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Mon, 18 Dec 2023 16:36:04 +0800
Subject: [PATCH 3/3] dt-bindings: soc: mediatek: Change the description of gce-events
In-Reply-To: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
Message-ID: <20231218083604.7327-4-jason-jh.lin@mediatek.com>

Change the description of mediatek,gce-events property to reference
mediatek,gce-mailbox yaml.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 .../devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml     | 5 +----
 .../devicetree/bindings/soc/mediatek/mediatek,mutex.yaml     | 5 +----
 .../devicetree/bindings/soc/mediatek/mediatek,wdma.yaml      | 5 +----
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
index 4380b98b0dfe..64c0f99fcbce 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
@@ -36,10 +36,7 @@ properties:
 
   mediatek,gce-events:
     description:
-      The event id which is mapping to the specific hardware event signal
-      to gce. The event id is defined in the gce header
-      include/dt-bindings/gce/<chip>-gce.h of each chips.
-    $ref: /schemas/types.yaml#/definitions/uint32-array
+      Reference to Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml.
 
   clocks:
     minItems: 1
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
index ba2014a8725c..34b313154534 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
@@ -55,10 +55,7 @@ properties:
 
   mediatek,gce-events:
     description:
-      The event id which is mapping to the specific hardware event signal
-      to gce. The event id is defined in the gce header
-      include/dt-bindings/gce/<chip>-gce.h of each chips.
-    $ref: /schemas/types.yaml#/definitions/uint32-array
+      Reference to Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml.
 
   mediatek,gce-client-reg:
     $ref: /schemas/types.yaml#/definitions/phandle-array
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
index 69afb329e5f4..ff515cf8394b 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
@@ -37,10 +37,7 @@ properties:
 
   mediatek,gce-events:
     description:
-      The event id which is mapping to the specific hardware event signal
-      to gce. The event id is defined in the gce header
-      include/dt-bindings/gce/<chip>-gce.h of each chips.
-    $ref: /schemas/types.yaml#/definitions/uint32-array
+      Reference to Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml.
 
   power-domains:
     maxItems: 1
-- 
2.18.0



From quan at os.amperecomputing.com  Mon Dec 18 00:45:56 2023
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Mon, 18 Dec 2023 15:45:56 +0700
Subject: [PATCH v4 2/2] i2c: aspeed: Acknowledge Tx done with and without
 ACK irq late
In-Reply-To: <54cba87a0df233b8762e43b742afe8e44a77a60c.camel@codeconstruct.com.au>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
 <20231211102217.2436294-3-quan@os.amperecomputing.com>
 <2eab42cde34723a195e7a0287db08b25f8388a3b.camel@codeconstruct.com.au>
 <54cba87a0df233b8762e43b742afe8e44a77a60c.camel@codeconstruct.com.au>
Message-ID: <7dfc99e5-4c76-413b-aabc-81b26e26249e@os.amperecomputing.com>



On 15/12/2023 05:21, Andrew Jeffery wrote:
>> On Mon, 2023-12-11 at 17:22 +0700, Quan Nguyen wrote:
>>> Commit 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in
>>> interrupt handler") acknowledges most interrupts early before the slave
>>> irq handler is executed, except for the "Receive Done Interrupt status"
>>> which is acknowledged late in the interrupt.
>>> However, it has been observed that the early acknowledgment of "Transmit
>>> Done Interrupt Status" (with ACK or NACK) often causes the interrupt to
>>> be raised in READ REQUEST state, that shows the
>>> "Unexpected ACK on read request." complaint messages.
>>>
>>> Assuming that the "Transmit Done" interrupt should only be acknowledged
>>> once it is truly processed, this commit fixes that issue by acknowledging
>>> interrupts for both ACK and NACK cases late in the interrupt handler.
>>>
>>> Fixes: 2be6b47211e1 ("i2c: aspeed: Acknowledge most interrupts early in interrupt handler")
>>> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
>>
>> Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>
> 
> So I just booted this series on v6.7-rc5 under qemu v8.2.0-rc4 and
> found this:
> 
> ```
> $ qemu-system-arm \
> 	-M ast2600-evb \
> 	-kernel build.aspeed_g5/arch/arm/boot/zImage \
> 	-dtb build.aspeed_g5/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dtb \
> 	-initrd ~/src/buildroot.org/buildroot/output/images/rootfs.cpio.xz \
> 	-nographic 2>&1 \
> 	| ts -s
> ...
> 00:00:03 [    1.089187] Freeing initrd memory: 3308K
> 00:00:05 smbus: error: Unexpected send start condition in state 1
> 00:00:05 smbus: error: Unexpected write in state -1
> 00:00:06 [    3.685731] aspeed-i2c-bus 1e78a400.i2c-bus: i2c bus 7 registered, irq 48
> 00:00:06 [    3.688918] aspeed-i2c-bus 1e78a480.i2c-bus: i2c bus 8 registered, irq 49
> 00:00:06 [    3.692326] aspeed-i2c-bus 1e78a500.i2c-bus: i2c bus 9 registered, irq 50
> 00:00:06 [    3.693757] aspeed-i2c-bus 1e78a680.i2c-bus: i2c bus 12 registered, irq 51
> 00:00:06 [    3.695070] aspeed-i2c-bus 1e78a700.i2c-bus: i2c bus 13 registered, irq 52
> 00:00:06 [    3.696184] aspeed-i2c-bus 1e78a780.i2c-bus: i2c bus 14 registered, irq 53
> 00:00:06 [    3.697144] aspeed-i2c-bus 1e78a800.i2c-bus: i2c bus 15 registered, irq 54
> 00:00:06 [    3.699061] aspeed-video 1e700000.video: irq 55
> 00:00:06 [    3.699254] aspeed-video 1e700000.video: assigned reserved memory node video
> 00:00:06 [    3.702755] aspeed-video 1e700000.video: alloc mem size(24576) at 0xbc000000 for jpeg header
> 00:00:06 [    3.706139] Driver for 1-wire Dallas network protocol.
> 00:00:07 smbus: error: Unexpected send start condition in state -1
> 00:00:07 smbus: error: Unexpected write in state -1
> 00:00:10 smbus: error: Unexpected send start condition in state -1
> 00:00:10 smbus: error: Unexpected write in state -1
> 00:00:12 smbus: error: Unexpected send start condition in state -1
> 00:00:12 smbus: error: Unexpected write in state -1
> 00:00:14 smbus: error: Unexpected send start condition in state -1
> 00:00:14 smbus: error: Unexpected write in state -1
> 00:00:17 smbus: error: Unexpected send start condition in state -1
> 00:00:17 smbus: error: Unexpected write in state -1
> 00:00:18 [   14.080141] adt7475 7-002e: Error configuring attenuator bypass
> 00:00:19 smbus: error: Unexpected send start condition in state -1
> 00:00:19 smbus: error: Unexpected write in state -1
> 00:00:21 smbus: error: Unexpected send start condition in state -1
> 00:00:21 smbus: error: Unexpected write in state -1
> 00:00:24 smbus: error: Unexpected send start condition in state -1
> 00:00:24 smbus: error: Unexpected write in state -1
> ```
> 
> The smbus errors do not occur if I revert this patch.
> 
> Can you look into qemu to see if it's a bug in the aspeed i2c
> controller model's state machine?
> 

Thanks, Andrew, for testing these patches on qemu.

I'll try to look into it to see if anything can be improved, but I have 
to admit that I'm not so familiar with it. This is my first time trying 
it on qemu. Just did these tests on real HW with waveform captured 
sometimes.

So far I could be able to reproduce the issue and start playing around 
trying to understand the model.

Thanks,
- Quan


From luca.ceresoli at bootlin.com  Mon Dec 18 00:48:49 2023
From: luca.ceresoli at bootlin.com (Luca Ceresoli)
Date: Mon, 18 Dec 2023 09:48:49 +0100
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel
 Video Interface
In-Reply-To: <20231218023655.GG5290@pendragon.ideasonboard.com>
References: <20230920171009.3193296-1-l.stach@pengutronix.de>
	<20230920171009.3193296-2-l.stach@pengutronix.de>
	<20230920205736.GB7723@pendragon.ideasonboard.com>
	<CAHCN7xJz=rEH_8wHaBCVOUzP0kO6cM_c=zLf6ocjW8bt1FaCBw@mail.gmail.com>
	<CAOMZO5C7_Rj-Ja0BO0D0Po+gy+XbvyMdQf-wH5YNyhAdMof2vg@mail.gmail.com>
	<20231215142308.GL21146@pendragon.ideasonboard.com>
	<CAHCN7xJPg_Nk=o9fKwkZfVTNSB-YL0m7vY6p1O7+i=PHShp7hg@mail.gmail.com>
	<CAOMZO5AGAkPpds=5H-iQj53djcQtW5GsRQrzdC_JOOrcENhvvw@mail.gmail.com>
	<CAHCN7xLHMGcS2-QTneqqpHYU66JwuEG4TyR0j0riFGqO6RC8ug@mail.gmail.com>
	<CAOMZO5B2bWVciDEwSh+YQWu6b_Hp5ijk6Jq-bMePPTDRJ-vHFA@mail.gmail.com>
	<20231218023655.GG5290@pendragon.ideasonboard.com>
Message-ID: <20231218094849.4aa15a97@booty>

Hi,

On Mon, 18 Dec 2023 04:36:55 +0200
Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote:

> On Fri, Dec 15, 2023 at 05:09:41PM -0300, Fabio Estevam wrote:
> > On Fri, Dec 15, 2023 at 4:01?PM Adam Ford <aford173 at gmail.com> wrote:
> >   
> > > Thanks for the list.  I was able to successfully build the stable 6.6
> > > branch with those patches applied and I have the HDMI working.
> > > Unfortunately, I get build errors on the linux-next, so it's going to
> > > take me a little time to sort through all of this.  
> > 
> > If you need help to figure this problem out, please let me know.
> > 
> > I haven't tried it against linux-next.
> >   
> > > I am thinking that it would be better to consolidate all these
> > > together into one series instead of piecemealing it.  However, there
> > > are some items that can be submitted right away without significantly
> > > reworking them against linux-next.  Do people have a preference?  
> > 
> > I think it makes sense to re-submit the "easy ones" right away.  
> 
> Agreed. The more we can merge quickly, the easier it will become to
> rebase and upstream the rest.

I agree as well, "release early, release often". These patches are
around since a long time and lots of people are using them already, and
tracking all of them from different threads is time-consuming. I will
happily test them early as soon as they are sent.

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From xu.yang_2 at nxp.com  Mon Dec 18 00:54:52 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 18 Dec 2023 16:54:52 +0800
Subject: [PATCH v2 1/5] arm64: dts: imx8ulp: add usb nodes
Message-ID: <20231218085456.3962720-1-xu.yang_2@nxp.com>

Add USB nodes on i.MX8ULP platform which has 2 USB controllers.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - no changes
---
 arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 64 ++++++++++++++++++++++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index c4a0082f30d3..ead1f57e08ef 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -28,6 +28,8 @@ aliases {
 		serial1 = &lpuart5;
 		serial2 = &lpuart6;
 		serial3 = &lpuart7;
+		usbphy0 = &usbphy1;
+		usbphy1 = &usbphy2;
 	};
 
 	cpus {
@@ -472,6 +474,68 @@ usdhc2: mmc at 298f0000 {
 				status = "disabled";
 			};
 
+			usbotg1: usb at 29900000 {
+				compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+				reg = <0x29900000 0x200>;
+				interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&pcc4 IMX8ULP_CLK_USB0>;
+				power-domains = <&scmi_devpd IMX8ULP_PD_USB0>;
+				phys = <&usbphy1>;
+				fsl,usbmisc = <&usbmisc1 0>;
+				ahb-burst-config = <0x0>;
+				tx-burst-size-dword = <0x8>;
+				rx-burst-size-dword = <0x8>;
+				status = "disabled";
+			};
+
+			usbmisc1: usbmisc at 29900200 {
+				compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+						"fsl,imx6q-usbmisc";
+				#index-cells = <1>;
+				reg = <0x29900200 0x200>;
+				status = "disabled";
+			};
+
+			usbphy1: usb-phy at 29910000 {
+				compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+				reg = <0x29910000 0x10000>;
+				interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&pcc4 IMX8ULP_CLK_USB0_PHY>;
+				#phy-cells = <0>;
+				status = "disabled";
+			};
+
+			usbotg2: usb at 29920000 {
+				compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+				reg = <0x29920000 0x200>;
+				interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&pcc4 IMX8ULP_CLK_USB1>;
+				power-domains = <&scmi_devpd IMX8ULP_PD_USDHC2_USB1>;
+				phys = <&usbphy2>;
+				fsl,usbmisc = <&usbmisc2 0>;
+				ahb-burst-config = <0x0>;
+				tx-burst-size-dword = <0x8>;
+				rx-burst-size-dword = <0x8>;
+				status = "disabled";
+			};
+
+			usbmisc2: usbmisc at 29920200 {
+				compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+						"fsl,imx6q-usbmisc";
+				#index-cells = <1>;
+				reg = <0x29920200 0x200>;
+				status = "disabled";
+			};
+
+			usbphy2: usb-phy at 29930000 {
+				compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+				reg = <0x29930000 0x10000>;
+				interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&pcc4 IMX8ULP_CLK_USB1_PHY>;
+				#phy-cells = <0>;
+				status = "disabled";
+			};
+
 			fec: ethernet at 29950000 {
 				compatible = "fsl,imx8ulp-fec", "fsl,imx6ul-fec", "fsl,imx6q-fec";
 				reg = <0x29950000 0x10000>;
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Dec 18 00:54:53 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 18 Dec 2023 16:54:53 +0800
Subject: [PATCH v2 2/5] arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes
In-Reply-To: <20231218085456.3962720-1-xu.yang_2@nxp.com>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com>
Message-ID: <20231218085456.3962720-2-xu.yang_2@nxp.com>

Enable 2 USB nodes and add 2 PTN5150 nodes on i.MX8ULP evk board.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - fix format as suggusted by Fabio
 - add PTN5150 nodes
---
 arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 84 +++++++++++++++++++
 1 file changed, 84 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 69dd8e31027c..bf418af31039 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -133,6 +133,64 @@ pcal6408: gpio at 21 {
 		gpio-controller;
 		#gpio-cells = <2>;
 	};
+
+	ptn5150_1: typec at 1d {
+		compatible = "nxp,ptn5150";
+		reg = <0x1d>;
+		int-gpios = <&gpiof 3 IRQ_TYPE_EDGE_FALLING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_typec1>;
+		status = "disabled";
+	};
+
+	ptn5150_2: typec at 3d {
+		compatible = "nxp,ptn5150";
+		reg = <0x3d>;
+		int-gpios = <&gpiof 5 IRQ_TYPE_EDGE_FALLING>;
+			pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_typec2>;
+		status = "disabled";
+	};
+};
+
+&usbotg1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb1>;
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	over-current-active-low;
+	status = "okay";
+};
+
+&usbphy1 {
+	fsl,tx-d-cal = <110>;
+	status = "okay";
+};
+
+&usbmisc1 {
+	status = "okay";
+};
+
+&usbotg2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb2>;
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	over-current-active-low;
+	status = "okay";
+};
+
+&usbphy2 {
+	fsl,tx-d-cal = <110>;
+	status = "okay";
+};
+
+&usbmisc2 {
+	status = "okay";
 };
 
 &usdhc0 {
@@ -224,6 +282,32 @@ MX8ULP_PAD_PTE13__LPI2C7_SDA	0x20
 		>;
 	};
 
+	pinctrl_typec1: typec1grp {
+		fsl,pins = <
+			MX8ULP_PAD_PTF3__PTF3           0x3
+		>;
+	};
+
+	pinctrl_typec2: typec2grp {
+		fsl,pins = <
+			MX8ULP_PAD_PTF5__PTF5           0x3
+		>;
+	};
+
+	pinctrl_usb1: usb1grp {
+		fsl,pins = <
+			MX8ULP_PAD_PTF2__USB0_ID	0x10003
+			MX8ULP_PAD_PTF4__USB0_OC	0x10003
+		>;
+	};
+
+	pinctrl_usb2: usb2grp {
+		fsl,pins = <
+			MX8ULP_PAD_PTD23__USB1_ID	0x10003
+			MX8ULP_PAD_PTF6__USB1_OC	0x10003
+		>;
+	};
+
 	pinctrl_usdhc0: usdhc0grp {
 		fsl,pins = <
 			MX8ULP_PAD_PTD1__SDHC0_CMD	0x3
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Dec 18 00:54:54 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 18 Dec 2023 16:54:54 +0800
Subject: [PATCH v2 3/5] dt-bindings: usb: ci-hdrc-usb2: add compatible and clock-names restriction for imx93
In-Reply-To: <20231218085456.3962720-1-xu.yang_2@nxp.com>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com>
Message-ID: <20231218085456.3962720-3-xu.yang_2@nxp.com>

The i.MX93 needs a wakup clock to work properly. This will add compatible
and restriction for i.MX93 platform.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - no changes
---
 .../devicetree/bindings/usb/ci-hdrc-usb2.yaml        | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
index b7e664f7395b..4e22b369e43f 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
@@ -57,6 +57,7 @@ properties:
           - enum:
               - fsl,imx8mm-usb
               - fsl,imx8mn-usb
+              - fsl,imx93-usb
           - const: fsl,imx7d-usb
           - const: fsl,imx27-usb
       - items:
@@ -411,6 +412,17 @@ allOf:
         external-vbus-divider: false
         samsung,picophy-pre-emp-curr-control: false
         samsung,picophy-dc-vol-level-adjust: false
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: fsl,imx93-usb
+    then:
+      properties:
+        clock-names:
+          items:
+            - const: usb_ctrl_root_clk
+            - const: usb_wakeup_clk
 
 unevaluatedProperties: false
 
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Dec 18 00:54:55 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 18 Dec 2023 16:54:55 +0800
Subject: [PATCH v2 4/5] arm64: dts: imx93: add usb nodes
In-Reply-To: <20231218085456.3962720-1-xu.yang_2@nxp.com>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com>
Message-ID: <20231218085456.3962720-4-xu.yang_2@nxp.com>

There are 2 USB controllers on i.MX93. Add them.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - fix format as suggested by Alexander
 - change compatible from fsl,imx8mm-usb to fsl,imx93-usb
---
 arch/arm64/boot/dts/freescale/imx93.dtsi | 58 ++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi b/arch/arm64/boot/dts/freescale/imx93.dtsi
index 34c0540276d1..043ec8dc9aca 100644
--- a/arch/arm64/boot/dts/freescale/imx93.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
@@ -171,6 +171,20 @@ cm33: remoteproc-cm33 {
 		status = "disabled";
 	};
 
+	usbphynop1: usbphynop1 {
+		compatible = "usb-nop-xceiv";
+		#phy-cells = <0>;
+		clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
+		clock-names = "main_clk";
+	};
+
+	usbphynop2: usbphynop2 {
+		compatible = "usb-nop-xceiv";
+		#phy-cells = <0>;
+		clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
+		clock-names = "main_clk";
+	};
+
 	soc at 0 {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -1059,5 +1073,49 @@ ddr-pmu at 4e300dc0 {
 			reg = <0x4e300dc0 0x200>;
 			interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		};
+
+		usbotg1: usb at 4c100000 {
+			compatible = "fsl,imx93-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
+			reg = <0x4c100000 0x200>;
+			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
+				 <&clk IMX93_CLK_HSIO_32K_GATE>;
+			clock-names = "usb_ctrl_root_clk", "usb_wakeup_clk";
+			assigned-clocks = <&clk IMX93_CLK_HSIO>;
+			assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
+			assigned-clock-rates = <133000000>;
+			fsl,usbphy = <&usbphynop1>;
+			fsl,usbmisc = <&usbmisc1 0>;
+			status = "disabled";
+		};
+
+		usbmisc1: usbmisc at 4c100200 {
+			compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
+					"fsl,imx6q-usbmisc";
+			reg = <0x4c100200 0x200>;
+			#index-cells = <1>;
+		};
+
+		usbotg2: usb at 4c200000 {
+			compatible = "fsl,imx93-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
+			reg = <0x4c200000 0x200>;
+			interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
+				 <&clk IMX93_CLK_HSIO_32K_GATE>;
+			clock-names = "usb_ctrl_root_clk", "usb_wakeup_clk";
+			assigned-clocks = <&clk IMX93_CLK_HSIO>;
+			assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
+			assigned-clock-rates = <133000000>;
+			fsl,usbphy = <&usbphynop2>;
+			fsl,usbmisc = <&usbmisc2 0>;
+			status = "disabled";
+		};
+
+		usbmisc2: usbmisc at 4c200200 {
+			compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
+					"fsl,imx6q-usbmisc";
+			reg = <0x4c200200 0x200>;
+			#index-cells = <1>;
+		};
 	};
 };
-- 
2.34.1



From xu.yang_2 at nxp.com  Mon Dec 18 00:54:56 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 18 Dec 2023 16:54:56 +0800
Subject: [PATCH v2 5/5] arm64: dts: imx93-11x11-evk: enable usb and typec nodes
In-Reply-To: <20231218085456.3962720-1-xu.yang_2@nxp.com>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com>
Message-ID: <20231218085456.3962720-5-xu.yang_2@nxp.com>

There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - remove status property in ptn5110 nodes
 - fix dt-schema warnings
---
 .../boot/dts/freescale/imx93-11x11-evk.dts    | 118 ++++++++++++++++++
 1 file changed, 118 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
index 2b9d47716f75..87c7cfacdc7b 100644
--- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/usb/pd.h>
 #include "imx93.dtsi"
 
 / {
@@ -103,6 +104,80 @@ &mu2 {
 	status = "okay";
 };
 
+&lpi2c3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&pinctrl_lpi2c3>;
+	pinctrl-1 = <&pinctrl_lpi2c3>;
+	status = "okay";
+
+	ptn5110: tcpc at 50 {
+		compatible = "nxp,ptn5110";
+		reg = <0x50>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+
+		typec1_con: connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+			power-role = "dual";
+			data-role = "dual";
+			try-power-role = "sink";
+			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+			sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+				     PDO_VAR(5000, 20000, 3000)>;
+			op-sink-microwatt = <15000000>;
+			self-powered;
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port at 0 {
+					reg = <0>;
+					typec1_dr_sw: endpoint {
+						remote-endpoint = <&usb1_drd_sw>;
+					};
+				};
+			};
+		};
+	};
+
+	ptn5110_2: tcpc at 51 {
+		compatible = "nxp,ptn5110";
+		reg = <0x51>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+
+		typec2_con: connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+			power-role = "dual";
+			data-role = "dual";
+			try-power-role = "sink";
+			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+			sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+				     PDO_VAR(5000, 20000, 3000)>;
+			op-sink-microwatt = <15000000>;
+			self-powered;
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port at 0 {
+					reg = <0>;
+					typec2_dr_sw: endpoint {
+						remote-endpoint = <&usb2_drd_sw>;
+					};
+				};
+			};
+		};
+	};
+};
+
 &eqos {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_eqos>;
@@ -155,6 +230,42 @@ &lpuart5 {
 	status = "okay";
 };
 
+&usbotg1 {
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	usb-role-switch;
+	disable-over-current;
+	samsung,picophy-pre-emp-curr-control = <3>;
+	samsung,picophy-dc-vol-level-adjust = <7>;
+	status = "okay";
+
+	port {
+		usb1_drd_sw: endpoint {
+			remote-endpoint = <&typec1_dr_sw>;
+		};
+	};
+};
+
+&usbotg2 {
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	usb-role-switch;
+	disable-over-current;
+	samsung,picophy-pre-emp-curr-control = <3>;
+	samsung,picophy-dc-vol-level-adjust = <7>;
+	status = "okay";
+
+	port {
+		usb2_drd_sw: endpoint {
+			remote-endpoint = <&typec2_dr_sw>;
+		};
+	};
+};
+
 &usdhc1 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz";
 	pinctrl-0 = <&pinctrl_usdhc1>;
@@ -221,6 +332,13 @@ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL	0x57e
 		>;
 	};
 
+	pinctrl_lpi2c3: lpi2c3grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO28__LPI2C3_SDA			0x40000b9e
+			MX93_PAD_GPIO_IO29__LPI2C3_SCL			0x40000b9e
+		>;
+	};
+
 	pinctrl_uart1: uart1grp {
 		fsl,pins = <
 			MX93_PAD_UART1_RXD__LPUART1_RX			0x31e
-- 
2.34.1



From maxime.chevallier at bootlin.com  Mon Dec 18 00:49:56 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Mon, 18 Dec 2023 09:49:56 +0100
Subject: [PATCH net-next v4 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <ede222d4-11da-4b95-a685-17cb480694dd@lunn.ch>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
	<20231215171237.1152563-1-maxime.chevallier@bootlin.com>
	<20231215171237.1152563-2-maxime.chevallier@bootlin.com>
	<20231215171237.1152563-2-maxime.chevallier@bootlin.com>
	<20231215214523.ntk5kec32mb5vqjs@skbuf>
	<ede222d4-11da-4b95-a685-17cb480694dd@lunn.ch>
Message-ID: <20231218094956.676e7ed0@device-28.home>

Hello Andrew,

Thanks for the review,

On Sun, 17 Dec 2023 17:57:10 +0100
Andrew Lunn <andrew at lunn.ch> wrote:

> On Fri, Dec 15, 2023 at 11:45:23PM +0200, Vladimir Oltean wrote:
> > On Fri, Dec 15, 2023 at 06:12:23PM +0100, Maxime Chevallier wrote:  
> > > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > > index d8e9335d415c..89daaccc9276 100644
> > > --- a/drivers/net/phy/phy_device.c
> > > +++ b/drivers/net/phy/phy_device.c
> > > @@ -1491,6 +1500,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> > >  
> > >  		if (phydev->sfp_bus_attached)
> > >  			dev->sfp_bus = phydev->sfp_bus;
> > > +
> > > +		err = phy_link_topo_add_phy(&dev->link_topo, phydev,
> > > +					    PHY_UPSTREAM_MAC, dev);
> > > +		if (err)
> > > +			goto error;
> > >  	}
> > >  
> > >  	/* Some Ethernet drivers try to connect to a PHY device before
> > > @@ -1816,6 +1830,7 @@ void phy_detach(struct phy_device *phydev)
> > >  	if (dev) {
> > >  		phydev->attached_dev->phydev = NULL;
> > >  		phydev->attached_dev = NULL;
> > > +		phy_link_topo_del_phy(&dev->link_topo, phydev);
> > >  	}
> > >  	phydev->phylink = NULL;
> > >  
> > > diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
> > > new file mode 100644
> > > index 000000000000..22f6372d002c
> > > --- /dev/null
> > > +++ b/drivers/net/phy/phy_link_topology.c
> > > +int phy_link_topo_add_phy(struct phy_link_topology *topo,
> > > +			  struct phy_device *phy,
> > > +			  enum phy_upstream upt, void *upstream)
> > > +{
> > > +	struct phy_device_node *pdn;
> > > +	int ret;
> > > +
> > > +	/* Protects phy and upstream */
> > > +	ASSERT_RTNL();  
> > 
> > Something to think for the PHY library maintainers. This is probably
> > the first time when the rtnl_lock() requirement is asserted at
> > phy_attach_direct() time.  
> 
> There are two use cases here for plain MAC drivers.
> 
> 1) phy_attach_direct() is called from probe. RTNL is normally not
> held, the driver would have to take it before making the call.
> 
> 2) phy_attach_direct() is called from ndo_open. In that case,
> __dev_open() has a ASSERT_RTNL() so we can assume RTNL has been taken.
> 
> So i don't think we can assume RTNL is held, but it might be held.
> 
> We need a better understanding what is being protected here.

I'm protecting the struct phy_device and the *upstream pointer (which
can be a net_device or a struct phy_device as well). In particular, I'm
protecting the phy_device->phyindex field. While I don't see any case
where we would concurrently write to it, given the weird topologies
that might be implemented in the future, I guess better safe than sorry.

For the rest, the actual phy list and the next_index pointer from the
topology should be already protected by the xarray mechanism.

Thanks,

Maxime



From brgl at bgdev.pl  Mon Dec 18 00:51:09 2023
From: brgl at bgdev.pl (Bartosz Golaszewski)
Date: Mon, 18 Dec 2023 09:51:09 +0100
Subject: [PATCH v6 02/13] firmware: qcom: add a dedicated TrustZone buffer allocator
In-Reply-To: <aec86af5-1170-4fc4-9986-879c61fc8633@quicinc.com>
References: <20231127141600.20929-1-brgl@bgdev.pl> <20231127141600.20929-3-brgl@bgdev.pl>
 <aec86af5-1170-4fc4-9986-879c61fc8633@quicinc.com>
Message-ID: <CAMRc=MfWtepi6m2xLdg7BhWSLp2=EY7z5KjxkFJFr9LC1Y4ALA@mail.gmail.com>

On Sat, Dec 16, 2023 at 8:00?PM Om Prakash Singh
<quic_omprsing at quicinc.com> wrote:
>
>
>
> On 11/27/2023 7:45 PM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> >
> > We have several SCM calls that require passing buffers to the TrustZone
> > on top of the SMC core which allocates memory for calls that require
> > more than 4 arguments.
> >
> > Currently every user does their own thing which leads to code
> > duplication. Many users call dma_alloc_coherent() for every call which
> > is terribly unperformant (speed- and size-wise).
> >
> > Provide a set of library functions for creating and managing pool of
> > memory which is suitable for sharing with the TrustZone, that is:
> > page-aligned, contiguous and non-cachable as well as provides a way of
> > mapping of kernel virtual addresses to physical space.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> > Reviewed-by: Andrew Halaney <ahalaney at redhat.com>
> > Tested-by: Andrew Halaney <ahalaney at redhat.com> # sc8280xp-lenovo-thinkpad-x13s
> > ---

[snip]

> > +
> > +#include "qcom_tzmem.h"
> > +
> > +struct qcom_tzmem_pool {
> > +     void *vbase;
> > +     dma_addr_t pbase;
> > +     size_t size;
> > +     struct gen_pool *pool;
> > +     void *priv;
> priv is not being using any where.

It's here for other implementations of the TZMem pools to store
private data under. SHM Bridge uses it in one of the later patches in
this series but it makes more logical sense to put it here.

[snip]

> > diff --git a/include/linux/firmware/qcom/qcom_tzmem.h b/include/linux/firmware/qcom/qcom_tzmem.h
> > new file mode 100644
> > index 000000000000..8e7fddab8cb4
> > --- /dev/null
> > +++ b/include/linux/firmware/qcom/qcom_tzmem.h
> > @@ -0,0 +1,28 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/*
> > + * Copyright (C) 2023 Linaro Ltd.
> > + */
> > +
> > +#ifndef __QCOM_TZMEM_H
> > +#define __QCOM_TZMEM_H
> > +
> > +#include <linux/cleanup.h>
> > +#include <linux/gfp.h>
> > +#include <linux/types.h>
> > +
> > +struct device;
> > +struct qcom_tzmem_pool;
> qcom_tzmem_pool stucture definition should be moved to header file.

No, why would you do this?

Bart

[snip]


From brgl at bgdev.pl  Mon Dec 18 00:57:04 2023
From: brgl at bgdev.pl (Bartosz Golaszewski)
Date: Mon, 18 Dec 2023 09:57:04 +0100
Subject: [PATCH] gpio: xilinx: remove excess kernel doc
In-Reply-To: <20231215090943.9245-1-brgl@bgdev.pl>
References: <20231215090943.9245-1-brgl@bgdev.pl>
Message-ID: <CAMRc=Mcc3+c7mfEPd+_SsS4OSeOHeYh8RKK8oOLxcrhRvnBTOA@mail.gmail.com>

On Fri, Dec 15, 2023 at 10:09?AM Bartosz Golaszewski <brgl at bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
>
> The irqchip field has been removed from struct xgpio_instance so remove
> the doc as well.
>
> Fixes: b4510f8fd5d0 ("gpio: xilinx: Convert to immutable irq_chip")
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312150239.IyuTVvrL-lkp at intel.com/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> ---
>  drivers/gpio/gpio-xilinx.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index 823198368250..7348df385198 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -52,7 +52,6 @@
>   * @dir: GPIO direction shadow register
>   * @gpio_lock: Lock used for synchronization
>   * @irq: IRQ used by GPIO device
> - * @irqchip: IRQ chip
>   * @enable: GPIO IRQ enable/disable bitfield
>   * @rising_edge: GPIO IRQ rising edge enable/disable bitfield
>   * @falling_edge: GPIO IRQ falling edge enable/disable bitfield
> --
> 2.40.1
>

Patch applied.

Bart


From alexander.stein at ew.tq-group.com  Mon Dec 18 00:59:15 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 09:59:15 +0100
Subject: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
In-Reply-To: <20231218094849.4aa15a97@booty>
References: <20230920171009.3193296-1-l.stach@pengutronix.de> <20231218023655.GG5290@pendragon.ideasonboard.com> <20231218094849.4aa15a97@booty>
Message-ID: <12346986.O9o76ZdvQC@steina-w>

Hi everybody,

Am Montag, 18. Dezember 2023, 09:48:49 CET schrieb Luca Ceresoli:
> Hi,
> 
> On Mon, 18 Dec 2023 04:36:55 +0200
> 
> Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote:
> > On Fri, Dec 15, 2023 at 05:09:41PM -0300, Fabio Estevam wrote:
> > > On Fri, Dec 15, 2023 at 4:01?PM Adam Ford <aford173 at gmail.com> wrote:
> > > > Thanks for the list.  I was able to successfully build the stable 6.6
> > > > branch with those patches applied and I have the HDMI working.
> > > > Unfortunately, I get build errors on the linux-next, so it's going to
> > > > take me a little time to sort through all of this.
> > > 
> > > If you need help to figure this problem out, please let me know.
> > > 
> > > I haven't tried it against linux-next.
> > > 
> > > > I am thinking that it would be better to consolidate all these
> > > > together into one series instead of piecemealing it.  However, there
> > > > are some items that can be submitted right away without significantly
> > > > reworking them against linux-next.  Do people have a preference?
> > > 
> > > I think it makes sense to re-submit the "easy ones" right away.
> > 
> > Agreed. The more we can merge quickly, the easier it will become to
> > rebase and upstream the rest.
> 
> I agree as well, "release early, release often". These patches are
> around since a long time and lots of people are using them already, and
> tracking all of them from different threads is time-consuming. I will
> happily test them early as soon as they are sent.

I lost track of the series well, but I do remember I had to adjust the 
original series to get it running on linux-next.
Please keep me on CC so I can add my local changes if necessary.
I have a proof of concept for HDMI audio, which is based on the base HDMI 
support. I can continue on that after merge, but I'm lacking an idea how to 
add some kind of "bridge" into the audio pipeline.

Best regards
Alexander
-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From mripard at kernel.org  Mon Dec 18 01:00:22 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 09:00:22 +0000
Subject: [PATCH v2 16/27] drm/rockchip: inno_hdmi: Drop irq struct
 member
In-Reply-To: <20231216162639.125215-17-knaerzche@gmail.com>
References: <20231216162639.125215-17-knaerzche@gmail.com>
Message-ID: <df0576baf95d8130b5034c4ef80e8d18@kernel.org>

On Sat, 16 Dec 2023 17:26:27 +0100, Alex Bee wrote:
> The struct member irq isn't used anywhere. Drop it.
> 
> Signed-off-by: Alex Bee <knaerzche at gmail.com>

Reviewed-by: Maxime Ripard <mripard at kernel.org>

Thanks!
Maxime


From mripard at kernel.org  Mon Dec 18 01:00:32 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 09:00:32 +0000
Subject: [PATCH v2 17/27] drm/rockchip: inno_hdmi: Remove useless
 include
In-Reply-To: <20231216162639.125215-18-knaerzche@gmail.com>
References: <20231216162639.125215-18-knaerzche@gmail.com>
Message-ID: <3cc54ae7f4c9970090d60fcbeab144c6@kernel.org>

On Sat, 16 Dec 2023 17:26:28 +0100, Alex Bee wrote:
> The inclusion syscon.h isn't used anywhere. Remove it.
> 
> Signed-off-by: Alex Bee <knaerzche at gmail.com>

Reviewed-by: Maxime Ripard <mripard at kernel.org>

Thanks!
Maxime


From sean at mess.org  Mon Dec 18 01:02:05 2023
From: sean at mess.org (Sean Young)
Date: Mon, 18 Dec 2023 09:02:05 +0000
Subject: [PATCH v8 5/6] pwm: bcm2835: Allow PWM driver to be used in
 atomic context
In-Reply-To: <20231212181444.mw5kxff5ijz676qh@pengutronix.de>
References: <cover.1702369869.git.sean@mess.org>
 <e9e32c9789da3c90b5a2aa7d5a093120b76421fb.1702369869.git.sean@mess.org>
 <20231212160838.k4z4csy455a7qnje@pengutronix.de>
 <20231212181444.mw5kxff5ijz676qh@pengutronix.de>
Message-ID: <ZYAKjTdr64GlCnxU@gofer.mess.org>

On Tue, Dec 12, 2023 at 07:14:44PM +0100, Uwe Kleine-K?nig wrote:
> Hello Sean,
> 
> On Tue, Dec 12, 2023 at 05:08:38PM +0100, Uwe Kleine-K?nig wrote:
> > On Tue, Dec 12, 2023 at 08:34:04AM +0000, Sean Young wrote:
> > > @@ -169,6 +179,7 @@ static int bcm2835_pwm_suspend(struct device *dev)
> > >  {
> > >  	struct bcm2835_pwm *pc = dev_get_drvdata(dev);
> > >  
> > > +	clk_rate_exclusive_put(pc->clk);
> > >  	clk_disable_unprepare(pc->clk);
> > 
> > I thought this was the remove function, but that's suspend. Adding
> > clk_rate_exclusive_put() there is wrong.
> 
> https://lore.kernel.org/linux-clk/744a6371f94fe96f527eea6e52a600914e6fb6b5.1702403904.git.u.kleine-koenig at pengutronix.de/
> might be useful to fix this.

That does look useful, I suppose I can only use it once it's merged in
pwm-next though. Leaving out for v9.

Thanks,
Sean


From mripard at kernel.org  Mon Dec 18 01:02:25 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 10:02:25 +0100
Subject: [PATCH v2 18/27] drm/rockchip: inno_hdmi: Subclass connector
 state
In-Reply-To: <20231216162639.125215-19-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-19-knaerzche@gmail.com>
Message-ID: <rvovzl6rqkaa2hvml75if5bjasqnyh2r354jdjpa5gckfpcxv4@wlknpt7lhncq>

Hi,

Thanks for working on that, it's much better now.

On Sat, Dec 16, 2023 at 05:26:29PM +0100, Alex Bee wrote:
> +static struct drm_connector_state *
> +inno_hdmi_connector_duplicate_state(struct drm_connector *connector)
> +{
> +	struct inno_hdmi_connector_state *inno_conn_state;
> +
> +	if (WARN_ON(!connector->state))
> +		return NULL;
> +
> +	inno_conn_state = kmemdup(to_inno_hdmi_conn_state(connector->state),
> +				  sizeof(*inno_conn_state), GFP_KERNEL);
> +
> +	if (!inno_conn_state)
> +		return NULL;
> +
> +	__drm_atomic_helper_connector_duplicate_state(connector,
> +						      &inno_conn_state->base);
> +
> +	return &inno_conn_state->base;
> +}
> +
>  static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
>  	.fill_modes = inno_hdmi_probe_single_connector_modes,
>  	.detect = inno_hdmi_connector_detect,
>  	.destroy = inno_hdmi_connector_destroy,
>  	.reset = drm_atomic_helper_connector_reset,
> -	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> +	.atomic_duplicate_state = inno_hdmi_connector_duplicate_state,
>  	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>  };

You also need a custom reset and atomic_destroy_state implementations

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/5975f336/attachment.sig>

From sean at mess.org  Mon Dec 18 01:02:29 2023
From: sean at mess.org (Sean Young)
Date: Mon, 18 Dec 2023 09:02:29 +0000
Subject: [PATCH v8 5/6] pwm: bcm2835: Allow PWM driver to be used in
 atomic context
In-Reply-To: <20231212160838.k4z4csy455a7qnje@pengutronix.de>
References: <cover.1702369869.git.sean@mess.org>
 <e9e32c9789da3c90b5a2aa7d5a093120b76421fb.1702369869.git.sean@mess.org>
 <20231212160838.k4z4csy455a7qnje@pengutronix.de>
Message-ID: <ZYAKpXOgF1j03KPF@gofer.mess.org>

On Tue, Dec 12, 2023 at 05:08:38PM +0100, Uwe Kleine-K?nig wrote:
> Hello Sean,
> 
> On Tue, Dec 12, 2023 at 08:34:04AM +0000, Sean Young wrote:
> > @@ -169,6 +179,7 @@ static int bcm2835_pwm_suspend(struct device *dev)
> >  {
> >  	struct bcm2835_pwm *pc = dev_get_drvdata(dev);
> >  
> > +	clk_rate_exclusive_put(pc->clk);
> >  	clk_disable_unprepare(pc->clk);
> 
> I thought this was the remove function, but that's suspend. Adding
> clk_rate_exclusive_put() there is wrong.

Nice catch - fixed in v9.


Sean


From krzysztof.kozlowski at linaro.org  Mon Dec 18 01:02:50 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 10:02:50 +0100
Subject: [PATCH v2] dt-bindings: clock: google,gs101: rename CMU_TOP
 gate defines
In-Reply-To: <20231218064333.479885-1-tudor.ambarus@linaro.org>
References: <20231218064333.479885-1-tudor.ambarus@linaro.org>
Message-ID: <170289017091.18651.1346933339464153967.b4-ty@linaro.org>


On Mon, 18 Dec 2023 06:43:33 +0000, Tudor Ambarus wrote:
> The gs101 clock defines from the bindings header are derived from the
> clock register names found in the datasheet under some certain rules.
> 
> The CMU TOP gate clock defines missed to include the required "CMU"
> differentiator which will cause collisions with the gate clock defines
> of other clock units. Rename the TOP gate clock defines to include "CMU".
> 
> [...]

Applied, thanks!

[1/1] dt-bindings: clock: google,gs101: rename CMU_TOP gate defines
      https://git.kernel.org/krzk/linux/c/35f32e39b4d9b436354c2a37623c393a2ac7cf87

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From mripard at kernel.org  Mon Dec 18 01:05:07 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 10:05:07 +0100
Subject: [PATCH v2 20/27] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <20231216162639.125215-21-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-21-knaerzche@gmail.com>
Message-ID: <rrtknir3vizvcyamp3kfy47r6uppn3wwevb6a5gln2k533t52z@otm6vum6pg43>

On Sat, Dec 16, 2023 at 05:26:31PM +0100, Alex Bee wrote:
> @@ -431,6 +452,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>  	else
>  		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
>  
> +	inno_conn_state->rgb_limited_range =
> +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
> +
>  	/* Mute video and audio output */
>  	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
>  		  v_AUDIO_MUTE(1) | v_VIDEO_MUTE(1));

This needs to be done at atomic_check time: the expectation is that by
the time you commit the state, everything is prepared for it.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/b7d109bb/attachment.sig>

From mripard at kernel.org  Mon Dec 18 01:06:15 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 09:06:15 +0000
Subject: [PATCH v2 23/27] drm/rockchip: inno_hdmi: Add basic mode
 validation
In-Reply-To: <20231216162639.125215-24-knaerzche@gmail.com>
References: <20231216162639.125215-24-knaerzche@gmail.com>
Message-ID: <c272ee2efed850089ea05abaa8dcef94@kernel.org>

On Sat, 16 Dec 2023 17:26:34 +0100, Alex Bee wrote:
> As per TRM this controller supports pixelclocks starting from 25 MHz. The
> maximum supported pixelclocks are defined by the phy configurations we
> have. Also it can't support modes that require doubled clocks. If the
> variant has a phy reference clock we can additionally validate against VESA
> DMT'srecommendations.
> 
> [ ... ]

Reviewed-by: Maxime Ripard <mripard at kernel.org>

Thanks!
Maxime


From mripard at kernel.org  Mon Dec 18 01:06:30 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 09:06:30 +0000
Subject: [PATCH v2 24/27] drm/rockchip: inno_hdmi: Drop custom
 fill_modes hook
In-Reply-To: <20231216162639.125215-25-knaerzche@gmail.com>
References: <20231216162639.125215-25-knaerzche@gmail.com>
Message-ID: <2fe240249b744ecdddc31c8e23c7616b@kernel.org>

On Sat, 16 Dec 2023 17:26:35 +0100, Alex Bee wrote:
> Now that we have proper pixelclock-based mode validation we can drop the
> custom fill_modes hook.
> CRTC size validation for the display controller has been added with
> Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
> hardware capabilities")
> 
> [ ... ]

Reviewed-by: Maxime Ripard <mripard at kernel.org>

Thanks!
Maxime


From maz at kernel.org  Mon Dec 18 01:07:08 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 18 Dec 2023 09:07:08 +0000
Subject: [PATCH v3 13/17] KVM: arm64: Define FGT nMASK bits relative to other fields
In-Reply-To: <20231214100158.2305400-14-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
	<20231214100158.2305400-14-tabba@google.com>
Message-ID: <86y1drangj.wl-maz@kernel.org>

On Thu, 14 Dec 2023 10:01:53 +0000,
Fuad Tabba <tabba at google.com> wrote:
> 
> Now that RES0 and MASK have full coverage, no speed to manually
> encode nMASK. Calculate it relative to the other fields.

s/speed/need/ ?

	M.

-- 
Without deviation from the norm, progress is not possible.


From sean at mess.org  Mon Dec 18 01:06:42 2023
From: sean at mess.org (Sean Young)
Date: Mon, 18 Dec 2023 09:06:42 +0000
Subject: [PATCH v9 1/6] pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
In-Reply-To: <cover.1702890244.git.sean@mess.org>
References: <cover.1702890244.git.sean@mess.org>
Message-ID: <b1137f99565ff3d8980fda6e2219c8a06c82129b.1702890244.git.sean@mess.org>

In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:

	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
	int pwm_apply_atomic(struct pwm *, struct pwm_state *);

This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.

Acked-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Acked-by: Guenter Roeck <linux at roeck-us.net>
Acked-by: Mark Brown <broonie at kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov at gmail.com> # for input
Acked-by: Hans de Goede <hdegoede at redhat.com>
Acked-by: Jani Nikula <jani.nikula at intel.com>
Acked-by: Lee Jones <lee at kernel.org>
Signed-off-by: Sean Young <sean at mess.org>
---
 Documentation/driver-api/pwm.rst              |  8 +++---
 MAINTAINERS                                   |  2 +-
 .../gpu/drm/i915/display/intel_backlight.c    |  6 ++--
 drivers/gpu/drm/solomon/ssd130x.c             |  2 +-
 drivers/hwmon/pwm-fan.c                       |  8 +++---
 drivers/input/misc/da7280.c                   |  4 +--
 drivers/input/misc/pwm-beeper.c               |  4 +--
 drivers/input/misc/pwm-vibra.c                |  8 +++---
 drivers/leds/leds-pwm.c                       |  2 +-
 drivers/leds/rgb/leds-pwm-multicolor.c        |  4 +--
 drivers/media/rc/pwm-ir-tx.c                  |  4 +--
 drivers/platform/x86/lenovo-yogabook.c        |  2 +-
 drivers/pwm/core.c                            | 18 ++++++------
 drivers/pwm/pwm-twl-led.c                     |  2 +-
 drivers/pwm/pwm-vt8500.c                      |  2 +-
 drivers/pwm/sysfs.c                           | 10 +++----
 drivers/regulator/pwm-regulator.c             |  4 +--
 drivers/video/backlight/lm3630a_bl.c          |  2 +-
 drivers/video/backlight/lp855x_bl.c           |  2 +-
 drivers/video/backlight/pwm_bl.c              | 12 ++++----
 drivers/video/fbdev/ssd1307fb.c               |  2 +-
 include/linux/pwm.h                           | 28 +++++++++----------
 22 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index bb264490a87a..f1d8197c8c43 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -41,7 +41,7 @@ the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also exist.
 
 After being requested, a PWM has to be configured using::
 
-	int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
+	int pwm_apply_might_sleep(struct pwm_device *pwm, struct pwm_state *state);
 
 This API controls both the PWM period/duty_cycle config and the
 enable/disable state.
@@ -57,13 +57,13 @@ If supported by the driver, the signal can be optimized, for example to improve
 EMI by phase shifting the individual channels of a chip.
 
 The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
-around pwm_apply_state() and should not be used if the user wants to change
+around pwm_apply_might_sleep() and should not be used if the user wants to change
 several parameter at once. For example, if you see pwm_config() and
 pwm_{enable,disable}() calls in the same function, this probably means you
-should switch to pwm_apply_state().
+should switch to pwm_apply_might_sleep().
 
 The PWM user API also allows one to query the PWM state that was passed to the
-last invocation of pwm_apply_state() using pwm_get_state(). Note this is
+last invocation of pwm_apply_might_sleep() using pwm_get_state(). Note this is
 different to what the driver has actually implemented if the request cannot be
 satisfied exactly with the hardware in use. There is currently no way for
 consumers to get the actually implemented settings.
diff --git a/MAINTAINERS b/MAINTAINERS
index 97f51d5ec1cf..c58480595220 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17576,7 +17576,7 @@ F:	drivers/video/backlight/pwm_bl.c
 F:	include/dt-bindings/pwm/
 F:	include/linux/pwm.h
 F:	include/linux/pwm_backlight.h
-K:	pwm_(config|apply_state|ops)
+K:	pwm_(config|apply_might_sleep|ops)
 
 PXA GPIO DRIVER
 M:	Robert Jarzmik <robert.jarzmik at free.fr>
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c b/drivers/gpu/drm/i915/display/intel_backlight.c
index 2e8f17c04522..ff9b9918b0a1 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -274,7 +274,7 @@ static void ext_pwm_set_backlight(const struct drm_connector_state *conn_state,
 	struct intel_panel *panel = &to_intel_connector(conn_state->connector)->panel;
 
 	pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 static void
@@ -427,7 +427,7 @@ static void ext_pwm_disable_backlight(const struct drm_connector_state *old_conn
 	intel_backlight_set_pwm_level(old_conn_state, level);
 
 	panel->backlight.pwm_state.enabled = false;
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 void intel_backlight_disable(const struct drm_connector_state *old_conn_state)
@@ -749,7 +749,7 @@ static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
 
 	pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
 	panel->backlight.pwm_state.enabled = true;
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 static void __intel_backlight_enable(const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c
index e0174f82e353..cce043a4a1dc 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -319,7 +319,7 @@ static int ssd130x_pwm_enable(struct ssd130x_device *ssd130x)
 
 	pwm_init_state(ssd130x->pwm, &pwmstate);
 	pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
-	pwm_apply_state(ssd130x->pwm, &pwmstate);
+	pwm_apply_might_sleep(ssd130x->pwm, &pwmstate);
 
 	/* Enable the PWM */
 	pwm_enable(ssd130x->pwm);
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 6e4516c2ab89..b67bc9e833c0 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -151,7 +151,7 @@ static int pwm_fan_power_on(struct pwm_fan_ctx *ctx)
 	}
 
 	state->enabled = true;
-	ret = pwm_apply_state(ctx->pwm, state);
+	ret = pwm_apply_might_sleep(ctx->pwm, state);
 	if (ret) {
 		dev_err(ctx->dev, "failed to enable PWM\n");
 		goto disable_regulator;
@@ -181,7 +181,7 @@ static int pwm_fan_power_off(struct pwm_fan_ctx *ctx)
 
 	state->enabled = false;
 	state->duty_cycle = 0;
-	ret = pwm_apply_state(ctx->pwm, state);
+	ret = pwm_apply_might_sleep(ctx->pwm, state);
 	if (ret) {
 		dev_err(ctx->dev, "failed to disable PWM\n");
 		return ret;
@@ -207,7 +207,7 @@ static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
 
 		period = state->period;
 		state->duty_cycle = DIV_ROUND_UP(pwm * (period - 1), MAX_PWM);
-		ret = pwm_apply_state(ctx->pwm, state);
+		ret = pwm_apply_might_sleep(ctx->pwm, state);
 		if (ret)
 			return ret;
 		ret = pwm_fan_power_on(ctx);
@@ -278,7 +278,7 @@ static int pwm_fan_update_enable(struct pwm_fan_ctx *ctx, long val)
 						    state,
 						    &enable_regulator);
 
-			pwm_apply_state(ctx->pwm, state);
+			pwm_apply_might_sleep(ctx->pwm, state);
 			pwm_fan_switch_power(ctx, enable_regulator);
 			pwm_fan_update_state(ctx, 0);
 		}
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
index ce82548916bb..c1fa75c0f970 100644
--- a/drivers/input/misc/da7280.c
+++ b/drivers/input/misc/da7280.c
@@ -352,7 +352,7 @@ static int da7280_haptic_set_pwm(struct da7280_haptic *haptics, bool enabled)
 		state.duty_cycle = period_mag_multi;
 	}
 
-	error = pwm_apply_state(haptics->pwm_dev, &state);
+	error = pwm_apply_might_sleep(haptics->pwm_dev, &state);
 	if (error)
 		dev_err(haptics->dev, "Failed to apply pwm state: %d\n", error);
 
@@ -1175,7 +1175,7 @@ static int da7280_probe(struct i2c_client *client)
 		/* Sync up PWM state and ensure it is off. */
 		pwm_init_state(haptics->pwm_dev, &state);
 		state.enabled = false;
-		error = pwm_apply_state(haptics->pwm_dev, &state);
+		error = pwm_apply_might_sleep(haptics->pwm_dev, &state);
 		if (error) {
 			dev_err(dev, "Failed to apply PWM state: %d\n", error);
 			return error;
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 1e731d8397c6..5b9aedf4362f 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -39,7 +39,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
 	state.period = period;
 	pwm_set_relative_duty_cycle(&state, 50, 100);
 
-	error = pwm_apply_state(beeper->pwm, &state);
+	error = pwm_apply_might_sleep(beeper->pwm, &state);
 	if (error)
 		return error;
 
@@ -138,7 +138,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
 	/* Sync up PWM state and ensure it is off. */
 	pwm_init_state(beeper->pwm, &state);
 	state.enabled = false;
-	error = pwm_apply_state(beeper->pwm, &state);
+	error = pwm_apply_might_sleep(beeper->pwm, &state);
 	if (error) {
 		dev_err(dev, "failed to apply initial PWM state: %d\n",
 			error);
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index acac79c488aa..3e5ed685ed8f 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -56,7 +56,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 	pwm_set_relative_duty_cycle(&state, vibrator->level, 0xffff);
 	state.enabled = true;
 
-	err = pwm_apply_state(vibrator->pwm, &state);
+	err = pwm_apply_might_sleep(vibrator->pwm, &state);
 	if (err) {
 		dev_err(pdev, "failed to apply pwm state: %d\n", err);
 		return err;
@@ -67,7 +67,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 		state.duty_cycle = vibrator->direction_duty_cycle;
 		state.enabled = true;
 
-		err = pwm_apply_state(vibrator->pwm_dir, &state);
+		err = pwm_apply_might_sleep(vibrator->pwm_dir, &state);
 		if (err) {
 			dev_err(pdev, "failed to apply dir-pwm state: %d\n", err);
 			pwm_disable(vibrator->pwm);
@@ -160,7 +160,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
 	/* Sync up PWM state and ensure it is off. */
 	pwm_init_state(vibrator->pwm, &state);
 	state.enabled = false;
-	err = pwm_apply_state(vibrator->pwm, &state);
+	err = pwm_apply_might_sleep(vibrator->pwm, &state);
 	if (err) {
 		dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 			err);
@@ -174,7 +174,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
 		/* Sync up PWM state and ensure it is off. */
 		pwm_init_state(vibrator->pwm_dir, &state);
 		state.enabled = false;
-		err = pwm_apply_state(vibrator->pwm_dir, &state);
+		err = pwm_apply_might_sleep(vibrator->pwm_dir, &state);
 		if (err) {
 			dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 				err);
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 2b3bf1353b70..4e3936a39d0e 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -54,7 +54,7 @@ static int led_pwm_set(struct led_classdev *led_cdev,
 
 	led_dat->pwmstate.duty_cycle = duty;
 	led_dat->pwmstate.enabled = true;
-	return pwm_apply_state(led_dat->pwm, &led_dat->pwmstate);
+	return pwm_apply_might_sleep(led_dat->pwm, &led_dat->pwmstate);
 }
 
 __attribute__((nonnull))
diff --git a/drivers/leds/rgb/leds-pwm-multicolor.c b/drivers/leds/rgb/leds-pwm-multicolor.c
index 46cd062b8b24..e1a81e0109e8 100644
--- a/drivers/leds/rgb/leds-pwm-multicolor.c
+++ b/drivers/leds/rgb/leds-pwm-multicolor.c
@@ -51,8 +51,8 @@ static int led_pwm_mc_set(struct led_classdev *cdev,
 
 		priv->leds[i].state.duty_cycle = duty;
 		priv->leds[i].state.enabled = duty > 0;
-		ret = pwm_apply_state(priv->leds[i].pwm,
-				      &priv->leds[i].state);
+		ret = pwm_apply_might_sleep(priv->leds[i].pwm,
+					    &priv->leds[i].state);
 		if (ret)
 			break;
 	}
diff --git a/drivers/media/rc/pwm-ir-tx.c b/drivers/media/rc/pwm-ir-tx.c
index c5f37c03af9c..cf51e2760975 100644
--- a/drivers/media/rc/pwm-ir-tx.c
+++ b/drivers/media/rc/pwm-ir-tx.c
@@ -68,7 +68,7 @@ static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
 
 	for (i = 0; i < count; i++) {
 		state.enabled = !(i % 2);
-		pwm_apply_state(pwm, &state);
+		pwm_apply_might_sleep(pwm, &state);
 
 		edge = ktime_add_us(edge, txbuf[i]);
 		delta = ktime_us_delta(edge, ktime_get());
@@ -77,7 +77,7 @@ static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
 	}
 
 	state.enabled = false;
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 
 	return count;
 }
diff --git a/drivers/platform/x86/lenovo-yogabook.c b/drivers/platform/x86/lenovo-yogabook.c
index b8d0239192cb..fd62bf746ebd 100644
--- a/drivers/platform/x86/lenovo-yogabook.c
+++ b/drivers/platform/x86/lenovo-yogabook.c
@@ -435,7 +435,7 @@ static int yogabook_pdev_set_kbd_backlight(struct yogabook_data *data, u8 level)
 		.enabled = level,
 	};
 
-	pwm_apply_state(data->kbd_bl_pwm, &state);
+	pwm_apply_might_sleep(data->kbd_bl_pwm, &state);
 	gpiod_set_value(data->kbd_bl_led_enable, level ? 1 : 0);
 	return 0;
 }
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f60b715abe62..c2d78136625d 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -326,8 +326,8 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
 }
 EXPORT_SYMBOL_GPL(pwm_request_from_chip);
 
-static void pwm_apply_state_debug(struct pwm_device *pwm,
-				  const struct pwm_state *state)
+static void pwm_apply_debug(struct pwm_device *pwm,
+			    const struct pwm_state *state)
 {
 	struct pwm_state *last = &pwm->last;
 	struct pwm_chip *chip = pwm->chip;
@@ -433,11 +433,11 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
 }
 
 /**
- * pwm_apply_state() - atomically apply a new state to a PWM device
+ * pwm_apply_might_sleep() - atomically apply a new state to a PWM device
  * @pwm: PWM device
  * @state: new state to apply
  */
-int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
+int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state)
 {
 	struct pwm_chip *chip;
 	int err;
@@ -445,7 +445,7 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	/*
 	 * Some lowlevel driver's implementations of .apply() make use of
 	 * mutexes, also with some drivers only returning when the new
-	 * configuration is active calling pwm_apply_state() from atomic context
+	 * configuration is active calling pwm_apply_might_sleep() from atomic context
 	 * is a bad idea. So make it explicit that calling this function might
 	 * sleep.
 	 */
@@ -475,11 +475,11 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	 * only do this after pwm->state was applied as some
 	 * implementations of .get_state depend on this
 	 */
-	pwm_apply_state_debug(pwm, state);
+	pwm_apply_debug(pwm, state);
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(pwm_apply_state);
+EXPORT_SYMBOL_GPL(pwm_apply_might_sleep);
 
 /**
  * pwm_capture() - capture and report a PWM signal
@@ -537,7 +537,7 @@ int pwm_adjust_config(struct pwm_device *pwm)
 		state.period = pargs.period;
 		state.polarity = pargs.polarity;
 
-		return pwm_apply_state(pwm, &state);
+		return pwm_apply_might_sleep(pwm, &state);
 	}
 
 	/*
@@ -560,7 +560,7 @@ int pwm_adjust_config(struct pwm_device *pwm)
 		state.duty_cycle = state.period - state.duty_cycle;
 	}
 
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 EXPORT_SYMBOL_GPL(pwm_adjust_config);
 
diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
index 8a870d0db3c6..c670ccb81653 100644
--- a/drivers/pwm/pwm-twl-led.c
+++ b/drivers/pwm/pwm-twl-led.c
@@ -172,7 +172,7 @@ static int twl4030_pwmled_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * We cannot skip calling ->config even if state->period ==
 	 * pwm->state.period && state->duty_cycle == pwm->state.duty_cycle
 	 * because we might have exited early in the last call to
-	 * pwm_apply_state because of !state->enabled and so the two values in
+	 * pwm_apply_might_sleep because of !state->enabled and so the two values in
 	 * pwm->state might not be configured in hardware.
 	 */
 	ret = twl4030_pwmled_config(chip, pwm,
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index bdea60389487..7bfeacee05d0 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -206,7 +206,7 @@ static int vt8500_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * We cannot skip calling ->config even if state->period ==
 	 * pwm->state.period && state->duty_cycle == pwm->state.duty_cycle
 	 * because we might have exited early in the last call to
-	 * pwm_apply_state because of !state->enabled and so the two values in
+	 * pwm_apply_might_sleep because of !state->enabled and so the two values in
 	 * pwm->state might not be configured in hardware.
 	 */
 	err = vt8500_pwm_config(chip, pwm, state->duty_cycle, state->period);
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 4edb994fa2e1..1698609d91c8 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -62,7 +62,7 @@ static ssize_t period_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.period = val;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -97,7 +97,7 @@ static ssize_t duty_cycle_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.duty_cycle = val;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -144,7 +144,7 @@ static ssize_t enable_store(struct device *child,
 		goto unlock;
 	}
 
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 
 unlock:
 	mutex_unlock(&export->lock);
@@ -194,7 +194,7 @@ static ssize_t polarity_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.polarity = polarity;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -401,7 +401,7 @@ static int pwm_class_apply_state(struct pwm_export *export,
 				 struct pwm_device *pwm,
 				 struct pwm_state *state)
 {
-	int ret = pwm_apply_state(pwm, state);
+	int ret = pwm_apply_might_sleep(pwm, state);
 
 	/* release lock taken in pwm_class_get_state */
 	mutex_unlock(&export->lock);
diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
index 2aff6db748e2..698c420e0869 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -90,7 +90,7 @@ static int pwm_regulator_set_voltage_sel(struct regulator_dev *rdev,
 	pwm_set_relative_duty_cycle(&pstate,
 			drvdata->duty_cycle_table[selector].dutycycle, 100);
 
-	ret = pwm_apply_state(drvdata->pwm, &pstate);
+	ret = pwm_apply_might_sleep(drvdata->pwm, &pstate);
 	if (ret) {
 		dev_err(&rdev->dev, "Failed to configure PWM: %d\n", ret);
 		return ret;
@@ -216,7 +216,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
 
 	pwm_set_relative_duty_cycle(&pstate, dutycycle, duty_unit);
 
-	ret = pwm_apply_state(drvdata->pwm, &pstate);
+	ret = pwm_apply_might_sleep(drvdata->pwm, &pstate);
 	if (ret) {
 		dev_err(&rdev->dev, "Failed to configure PWM: %d\n", ret);
 		return ret;
diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
index 8fcb62be597b..a3412c936ca2 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -180,7 +180,7 @@ static int lm3630a_pwm_ctrl(struct lm3630a_chip *pchip, int br, int br_max)
 
 	pchip->pwmd_state.enabled = pchip->pwmd_state.duty_cycle ? true : false;
 
-	return pwm_apply_state(pchip->pwmd, &pchip->pwmd_state);
+	return pwm_apply_might_sleep(pchip->pwmd, &pchip->pwmd_state);
 }
 
 /* update and get brightness */
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
index da1f124db69c..7075bfab59c4 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -234,7 +234,7 @@ static int lp855x_pwm_ctrl(struct lp855x *lp, int br, int max_br)
 	state.duty_cycle = div_u64(br * state.period, max_br);
 	state.enabled = state.duty_cycle;
 
-	return pwm_apply_state(lp->pwm, &state);
+	return pwm_apply_might_sleep(lp->pwm, &state);
 }
 
 static int lp855x_bl_update_status(struct backlight_device *bl)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 289bd9ce4d36..35c716e9043c 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -103,7 +103,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		pwm_get_state(pb->pwm, &state);
 		state.duty_cycle = compute_duty_cycle(pb, brightness, &state);
 		state.enabled = true;
-		pwm_apply_state(pb->pwm, &state);
+		pwm_apply_might_sleep(pb->pwm, &state);
 
 		pwm_backlight_power_on(pb);
 	} else {
@@ -120,7 +120,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		 * inactive output.
 		 */
 		state.enabled = !pb->power_supply && !pb->enable_gpio;
-		pwm_apply_state(pb->pwm, &state);
+		pwm_apply_might_sleep(pb->pwm, &state);
 	}
 
 	if (pb->notify_after)
@@ -528,7 +528,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 	if (!state.period && (data->pwm_period_ns > 0))
 		state.period = data->pwm_period_ns;
 
-	ret = pwm_apply_state(pb->pwm, &state);
+	ret = pwm_apply_might_sleep(pb->pwm, &state);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 			ret);
@@ -633,7 +633,7 @@ static void pwm_backlight_remove(struct platform_device *pdev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 
 	if (pb->exit)
 		pb->exit(&pdev->dev);
@@ -649,7 +649,7 @@ static void pwm_backlight_shutdown(struct platform_device *pdev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -673,7 +673,7 @@ static int pwm_backlight_suspend(struct device *dev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 
 	if (pb->notify_after)
 		pb->notify_after(pb->dev, 0);
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 5ae48e36fccb..1a4f90ea7d5a 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -347,7 +347,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
 
 		pwm_init_state(par->pwm, &pwmstate);
 		pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
-		pwm_apply_state(par->pwm, &pwmstate);
+		pwm_apply_might_sleep(par->pwm, &pwmstate);
 
 		/* Enable the PWM */
 		pwm_enable(par->pwm);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index f87655c06c82..b64b8a82415c 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -92,8 +92,8 @@ struct pwm_device {
  * @state: state to fill with the current PWM state
  *
  * The returned PWM state represents the state that was applied by a previous call to
- * pwm_apply_state(). Drivers may have to slightly tweak that state before programming it to
- * hardware. If pwm_apply_state() was never called, this returns either the current hardware
+ * pwm_apply_might_sleep(). Drivers may have to slightly tweak that state before programming it to
+ * hardware. If pwm_apply_might_sleep() was never called, this returns either the current hardware
  * state (if supported) or the default settings.
  */
 static inline void pwm_get_state(const struct pwm_device *pwm,
@@ -157,20 +157,20 @@ static inline void pwm_get_args(const struct pwm_device *pwm,
 }
 
 /**
- * pwm_init_state() - prepare a new state to be applied with pwm_apply_state()
+ * pwm_init_state() - prepare a new state to be applied with pwm_apply_might_sleep()
  * @pwm: PWM device
  * @state: state to fill with the prepared PWM state
  *
  * This functions prepares a state that can later be tweaked and applied
- * to the PWM device with pwm_apply_state(). This is a convenient function
+ * to the PWM device with pwm_apply_might_sleep(). This is a convenient function
  * that first retrieves the current PWM state and the replaces the period
  * and polarity fields with the reference values defined in pwm->args.
  * Once the function returns, you can adjust the ->enabled and ->duty_cycle
- * fields according to your needs before calling pwm_apply_state().
+ * fields according to your needs before calling pwm_apply_might_sleep().
  *
  * ->duty_cycle is initially set to zero to avoid cases where the current
  * ->duty_cycle value exceed the pwm_args->period one, which would trigger
- * an error if the user calls pwm_apply_state() without adjusting ->duty_cycle
+ * an error if the user calls pwm_apply_might_sleep() without adjusting ->duty_cycle
  * first.
  */
 static inline void pwm_init_state(const struct pwm_device *pwm,
@@ -226,7 +226,7 @@ pwm_get_relative_duty_cycle(const struct pwm_state *state, unsigned int scale)
  *
  * pwm_init_state(pwm, &state);
  * pwm_set_relative_duty_cycle(&state, 50, 100);
- * pwm_apply_state(pwm, &state);
+ * pwm_apply_might_sleep(pwm, &state);
  *
  * This functions returns -EINVAL if @duty_cycle and/or @scale are
  * inconsistent (@scale == 0 or @duty_cycle > @scale).
@@ -304,7 +304,7 @@ struct pwm_chip {
 
 #if IS_ENABLED(CONFIG_PWM)
 /* PWM user APIs */
-int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state);
+int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state);
 int pwm_adjust_config(struct pwm_device *pwm);
 
 /**
@@ -332,7 +332,7 @@ static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
 
 	state.duty_cycle = duty_ns;
 	state.period = period_ns;
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 
 /**
@@ -353,7 +353,7 @@ static inline int pwm_enable(struct pwm_device *pwm)
 		return 0;
 
 	state.enabled = true;
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 
 /**
@@ -372,7 +372,7 @@ static inline void pwm_disable(struct pwm_device *pwm)
 		return;
 
 	state.enabled = false;
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 }
 
 /* PWM provider APIs */
@@ -403,8 +403,8 @@ struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
 				       struct fwnode_handle *fwnode,
 				       const char *con_id);
 #else
-static inline int pwm_apply_state(struct pwm_device *pwm,
-				  const struct pwm_state *state)
+static inline int pwm_apply_might_sleep(struct pwm_device *pwm,
+					const struct pwm_state *state)
 {
 	might_sleep();
 	return -ENOTSUPP;
@@ -521,7 +521,7 @@ static inline void pwm_apply_args(struct pwm_device *pwm)
 	state.period = pwm->args.period;
 	state.usage_power = false;
 
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 }
 
 struct pwm_lookup {
-- 
2.43.0



From sean at mess.org  Mon Dec 18 01:06:46 2023
From: sean at mess.org (Sean Young)
Date: Mon, 18 Dec 2023 09:06:46 +0000
Subject: [PATCH v9 5/6] pwm: bcm2835: Allow PWM driver to be used in atomic context
In-Reply-To: <cover.1702890244.git.sean@mess.org>
References: <cover.1702890244.git.sean@mess.org>
Message-ID: <5249bb5d6c067692e4cd09573ced2df58966693b.1702890244.git.sean@mess.org>

clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
rate changes using clk_rate_exclusive_get().

Signed-off-by: Sean Young <sean at mess.org>
Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
---
 drivers/pwm/pwm-bcm2835.c | 40 +++++++++++++++++++++++++++++----------
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index ab30667f4f95..e556ae300c82 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -28,6 +28,7 @@ struct bcm2835_pwm {
 	struct device *dev;
 	void __iomem *base;
 	struct clk *clk;
+	unsigned long rate;
 };
 
 static inline struct bcm2835_pwm *to_bcm2835_pwm(struct pwm_chip *chip)
@@ -63,17 +64,11 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 {
 
 	struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
-	unsigned long rate = clk_get_rate(pc->clk);
 	unsigned long long period_cycles;
 	u64 max_period;
 
 	u32 val;
 
-	if (!rate) {
-		dev_err(pc->dev, "failed to get clock rate\n");
-		return -EINVAL;
-	}
-
 	/*
 	 * period_cycles must be a 32 bit value, so period * rate / NSEC_PER_SEC
 	 * must be <= U32_MAX. As U32_MAX * NSEC_PER_SEC < U64_MAX the
@@ -88,13 +83,13 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * <=> period < ((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate
 	 * <=> period <= ceil((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate) - 1
 	 */
-	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, rate) - 1;
+	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, pc->rate) - 1;
 
 	if (state->period > max_period)
 		return -EINVAL;
 
 	/* set period */
-	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * rate, NSEC_PER_SEC);
+	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * pc->rate, NSEC_PER_SEC);
 
 	/* don't accept a period that is too small */
 	if (period_cycles < PERIOD_MIN)
@@ -103,7 +98,7 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	writel(period_cycles, pc->base + PERIOD(pwm->hwpwm));
 
 	/* set duty cycle */
-	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * rate, NSEC_PER_SEC);
+	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * pc->rate, NSEC_PER_SEC);
 	writel(val, pc->base + DUTY(pwm->hwpwm));
 
 	/* set polarity */
@@ -151,16 +146,40 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
 				     "clock not found\n");
 
+	ret = clk_rate_exclusive_get(pc->clk);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret,
+				     "fail to get exclusive rate\n");
+
+	pc->rate = clk_get_rate(pc->clk);
+	if (!pc->rate) {
+		clk_rate_exclusive_put(pc->clk);
+		return dev_err_probe(&pdev->dev, -EINVAL,
+				     "failed to get clock rate\n");
+	}
+
 	pc->chip.dev = &pdev->dev;
 	pc->chip.ops = &bcm2835_pwm_ops;
+	pc->chip.atomic = true;
 	pc->chip.npwm = 2;
 
 	platform_set_drvdata(pdev, pc);
 
 	ret = devm_pwmchip_add(&pdev->dev, &pc->chip);
-	if (ret < 0)
+	if (ret < 0) {
+		clk_rate_exclusive_put(pc->clk);
 		return dev_err_probe(&pdev->dev, ret,
 				     "failed to add pwmchip\n");
+	}
+
+	return 0;
+}
+
+static int bcm2835_pwm_remove(struct platform_device *pdev)
+{
+	struct bcm2835_pwm *pc = platform_get_drvdata(pdev);
+
+	clk_rate_exclusive_put(pc->clk);
 
 	return 0;
 }
@@ -197,6 +216,7 @@ static struct platform_driver bcm2835_pwm_driver = {
 		.pm = pm_ptr(&bcm2835_pwm_pm_ops),
 	},
 	.probe = bcm2835_pwm_probe,
+	.remove = bcm2835_pwm_remove,
 };
 module_platform_driver(bcm2835_pwm_driver);
 
-- 
2.43.0



From ankita at nvidia.com  Mon Dec 18 01:07:16 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Mon, 18 Dec 2023 14:37:16 +0530
Subject: [PATCH v4 0/3] kvm: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
Message-ID: <20231218090719.22250-1-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

Currently, KVM for ARM64 maps at stage 2 memory that is considered device
(i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting
overrides (as per the ARM architecture [1]) any device MMIO mapping
present at stage 1, resulting in a set-up whereby a guest operating
system cannot determine device MMIO mapping memory attributes on its
own but it is always overridden by the KVM stage 2 default.

This set-up does not allow guest operating systems to select device
memory attributes independently from KVM stage-2 mappings
(refer to [1], "Combining stage 1 and stage 2 memory type attributes"),
which turns out to be an issue in that guest operating systems
(e.g. Linux) may request to map devices MMIO regions with memory
attributes that guarantee better performance (e.g. gathering
attribute - that for some devices can generate larger PCIe memory
writes TLPs) and specific operations (e.g. unaligned transactions)
such as the NormalNC memory type.

The default device stage 2 mapping was chosen in KVM for ARM64 since
it was considered safer (i.e. it would not allow guests to trigger
uncontained failures ultimately crashing the machine) but this
turned out to be asynchronous (SError) defeating the purpose.

Failures containability is a property of the platform and is independent
from the memory type used for MMIO device memory mappings.

Actually, DEVICE_nGnRE memory type is even more problematic than
Normal-NC memory type in terms of faults containability in that e.g.
aborts triggered on DEVICE_nGnRE loads cannot be made, architecturally,
synchronous (i.e. that would imply that the processor should issue at
most 1 load transaction at a time - it cannot pipeline them - otherwise
the synchronous abort semantics would break the no-speculation attribute
attached to DEVICE_XXX memory).

This means that regardless of the combined stage1+stage2 mappings a
platform is safe if and only if device transactions cannot trigger
uncontained failures and that in turn relies on platform capabilities
and the device type being assigned (i.e. PCIe AER/DPC error containment
and RAS architecture[3]); therefore the default KVM device stage 2
memory attributes play no role in making device assignment safer
for a given platform (if the platform design adheres to design
guidelines outlined in [3]) and therefore can be relaxed.

For all these reasons, relax the KVM stage 2 device memory attributes
from DEVICE_nGnRE to Normal-NC.

The NormalNC was chosen over a different Normal memory type default
at stage-2 (e.g. Normal Write-through) to avoid cache allocation/snooping.

Relaxing S2 KVM device MMIO mappings to Normal-NC is not expected to
trigger any issue on guest device reclaim use cases either (i.e. device
MMIO unmap followed by a device reset) at least for PCIe devices, in that
in PCIe a device reset is architected and carried out through PCI config
space transactions that are naturally ordered with respect to MMIO
transactions according to the PCI ordering rules.

Having Normal-NC S2 default puts guests in control (thanks to
stage1+stage2 combined memory attributes rules [1]) of device MMIO
regions memory mappings, according to the rules described in [1]
and summarized here ([(S1) - stage1], [(S2) - stage 2]):

S1           |  S2           | Result
NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>

It is worth noting that currently, to map devices MMIO space to user
space in a device pass-through use case the VFIO framework applies memory
attributes derived from pgprot_noncached() settings applied to VMAs, which
result in device-nGnRnE memory attributes for the stage-1 VMM mappings.

This means that a userspace mapping for device MMIO space carried
out with the current VFIO framework and a guest OS mapping for the same
MMIO space may result in a mismatched alias as described in [2].

Defaulting KVM device stage-2 mappings to Normal-NC attributes does not
change anything in this respect, in that the mismatched aliases would
only affect (refer to [2] for a detailed explanation) ordering between
the userspace and GuestOS mappings resulting stream of transactions
(i.e. it does not cause loss of property for either stream of
transactions on its own), which is harmless given that the userspace
and GuestOS access to the device is carried out through independent
transactions streams.

Generalizing to other devices may be problematic. E.g. GICv2 VCPU
interface, which is effectively a shared peripheral, can allow a
guest to affect another guest's interrupt distribution. Hence
limit the change to VFIO PCI as caution. This is achieved by
making the VFIO PCI core module set a flag that is tested by KVM
to activate the code. This could be extended to other devices in
the future once that is deemed safe.

[1] section D8.5 - DDI0487J_a_a-profile_architecture_reference_manual.pdf
[2] section B2.8 - DDI0487J_a_a-profile_architecture_reference_manual.pdf
[3] sections 1.7.7.3/1.8.5.2/appendix C - DEN0029H_SBSA_7.1.pdf

Applied over next-20231211

History
=======
v3 -> v4
- Moved the vfio-pci change to use the VM_VFIO_ALLOW_WC into
  separate patch.
- Added check to warn on the case NORMAL_NC and DEVICE are
  set simultaneously.
- Fixed miscellaneous nitpicks suggested in v3.

v2 -> v3
- Added a new patch (and converted to patch series) suggested by
  Catalin Marinas to ensure the code changes are restricted to
  VFIO PCI devices.
- Introduced VM_VFIO_ALLOW_WC flag for VFIO PCI to communicate
  with VMM.
- Reverted GIC mapping to DEVICE.

v1 -> v2
- Updated commit log to the one posted by
  Lorenzo Pieralisi <lpieralisi at kernel.org> (Thanks!)
- Added new flag to represent the NORMAL_NC setting. Updated
  stage2_set_prot_attr() to handle new flag.

v3 Link:
https://lore.kernel.org/all/20231208164709.23101-1-ankita at nvidia.com/

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>

Ankit Agrawal (3):
  kvm: arm64: introduce new flag for non-cacheable IO memory
  kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices
  vfio: convey kvm that the vfio-pci device is wc safe

 arch/arm64/include/asm/kvm_pgtable.h |  2 ++
 arch/arm64/include/asm/memory.h      |  2 ++
 arch/arm64/kvm/hyp/pgtable.c         | 13 +++++++++++--
 arch/arm64/kvm/mmu.c                 | 18 ++++++++++++++----
 drivers/vfio/pci/vfio_pci_core.c     |  3 ++-
 include/linux/mm.h                   | 13 +++++++++++++
 6 files changed, 44 insertions(+), 7 deletions(-)

-- 
2.17.1



From ankita at nvidia.com  Mon Dec 18 01:07:17 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Mon, 18 Dec 2023 14:37:17 +0530
Subject: [PATCH v4 1/3] kvm: arm64: introduce new flag for non-cacheable IO memory
In-Reply-To: <20231218090719.22250-1-ankita@nvidia.com>
References: <20231218090719.22250-1-ankita@nvidia.com>
Message-ID: <20231218090719.22250-2-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

For various reasons described in the cover letter, and primarily to
allow VM get IO memory with NORMALNC properties, it is desired
to relax the KVM stage 2 device memory attributes from DEVICE_nGnRE
to NormalNC. So set S2 PTE for IO memory as NORMAL_NC.

A Normal-NC flag is not present today. So add a new kvm_pgtable_prot
(KVM_PGTABLE_PROT_NORMAL_NC) flag for it, along with its
corresponding PTE value 0x5 (0b101) determined from [1].

Lastly, adapt the stage2 PTE property setter function
(stage2_set_prot_attr) to handle the NormalNC attribute.

[1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>
---
 arch/arm64/include/asm/kvm_pgtable.h |  2 ++
 arch/arm64/include/asm/memory.h      |  2 ++
 arch/arm64/kvm/hyp/pgtable.c         | 13 +++++++++++--
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index cfdf40f734b1..19278dfe7978 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -197,6 +197,7 @@ enum kvm_pgtable_stage2_flags {
  * @KVM_PGTABLE_PROT_W:		Write permission.
  * @KVM_PGTABLE_PROT_R:		Read permission.
  * @KVM_PGTABLE_PROT_DEVICE:	Device attributes.
+ * @KVM_PGTABLE_PROT_NORMAL_NC:	Normal noncacheable attributes.
  * @KVM_PGTABLE_PROT_SW0:	Software bit 0.
  * @KVM_PGTABLE_PROT_SW1:	Software bit 1.
  * @KVM_PGTABLE_PROT_SW2:	Software bit 2.
@@ -208,6 +209,7 @@ enum kvm_pgtable_prot {
 	KVM_PGTABLE_PROT_R			= BIT(2),
 
 	KVM_PGTABLE_PROT_DEVICE			= BIT(3),
+	KVM_PGTABLE_PROT_NORMAL_NC		= BIT(4),
 
 	KVM_PGTABLE_PROT_SW0			= BIT(55),
 	KVM_PGTABLE_PROT_SW1			= BIT(56),
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index fde4186cc387..c247e5f29d5a 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -147,6 +147,7 @@
  * Memory types for Stage-2 translation
  */
 #define MT_S2_NORMAL		0xf
+#define MT_S2_NORMAL_NC		0x5
 #define MT_S2_DEVICE_nGnRE	0x1
 
 /*
@@ -154,6 +155,7 @@
  * Stage-2 enforces Normal-WB and Device-nGnRE
  */
 #define MT_S2_FWB_NORMAL	6
+#define MT_S2_FWB_NORMAL_NC	5
 #define MT_S2_FWB_DEVICE_nGnRE	1
 
 #ifdef CONFIG_ARM64_4K_PAGES
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index c651df904fe3..0fff079a0ef3 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -718,10 +718,19 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
 				kvm_pte_t *ptep)
 {
 	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
-	kvm_pte_t attr = device ? KVM_S2_MEMATTR(pgt, DEVICE_nGnRE) :
-			    KVM_S2_MEMATTR(pgt, NORMAL);
+	bool normal_nc = prot & KVM_PGTABLE_PROT_NORMAL_NC;
+	kvm_pte_t attr;
 	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
 
+	WARN_ON_ONCE(device && normal_nc);
+
+	if (device)
+		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
+	else if (normal_nc)
+		attr = KVM_S2_MEMATTR(pgt, NORMAL_NC);
+	else
+		attr = KVM_S2_MEMATTR(pgt, NORMAL);
+
 	if (!(prot & KVM_PGTABLE_PROT_X))
 		attr |= KVM_PTE_LEAF_ATTR_HI_S2_XN;
 	else if (device)
-- 
2.17.1



From ankita at nvidia.com  Mon Dec 18 01:07:18 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Mon, 18 Dec 2023 14:37:18 +0530
Subject: [PATCH v4 2/3] kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices
In-Reply-To: <20231218090719.22250-1-ankita@nvidia.com>
References: <20231218090719.22250-1-ankita@nvidia.com>
Message-ID: <20231218090719.22250-3-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

To provide VM with the ability to get device IO memory with NormalNC
property, map device MMIO in KVM for ARM64 at stage2 as NormalNC.
Having NormalNC S2 default puts guests in control (based on [1],
"Combining stage 1 and stage 2 memory type attributes") of device
MMIO regions memory mappings. The rules are summarized below:
([(S1) - stage1], [(S2) - stage 2])

S1           |  S2           | Result
NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>

Generalizing this to non PCI devices may be problematic. E.g. GICv2
vCPU interface, which is effectively a shared peripheral, can allow
a guest to affect another guest's interrupt distribution. The issue
may be solved by limiting the relaxation to mappings that have a user
VMA. Still There is insufficient information and uncertainity in the
behavior of non PCI driver. Hence caution is maintained and the change
is restricted to the VFIO-PCI devices. PCIe on the other hand is safe
because the PCI bridge does not generate errors, and thus do not cause
uncontained failures.

A new flag VM_VFIO_ALLOW_WC to indicate KVM that the device is WC capable.
KVM use this flag to activate the code.

This could be extended to other devices in the future once that
is deemed safe.

[1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Jason Gunthorpe <jgg at nvidia.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>
---
 arch/arm64/kvm/mmu.c | 18 ++++++++++++++----
 include/linux/mm.h   | 13 +++++++++++++
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index d14504821b79..e1e6847a793b 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1381,7 +1381,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	int ret = 0;
 	bool write_fault, writable, force_pte = false;
 	bool exec_fault, mte_allowed;
-	bool device = false;
+	bool device = false, vfio_allow_wc = false;
 	unsigned long mmu_seq;
 	struct kvm *kvm = vcpu->kvm;
 	struct kvm_mmu_memory_cache *memcache = &vcpu->arch.mmu_page_cache;
@@ -1472,6 +1472,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	gfn = fault_ipa >> PAGE_SHIFT;
 	mte_allowed = kvm_vma_mte_allowed(vma);
 
+	vfio_allow_wc = (vma->vm_flags & VM_VFIO_ALLOW_WC);
+
 	/* Don't use the VMA after the unlock -- it may have vanished */
 	vma = NULL;
 
@@ -1557,10 +1559,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	if (exec_fault)
 		prot |= KVM_PGTABLE_PROT_X;
 
-	if (device)
-		prot |= KVM_PGTABLE_PROT_DEVICE;
-	else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
+	if (device) {
+		/*
+		 * To provide VM with the ability to get device IO memory
+		 * with NormalNC property, map device MMIO as NormalNC in S2.
+		 */
+		if (vfio_allow_wc)
+			prot |= KVM_PGTABLE_PROT_NORMAL_NC;
+		else
+			prot |= KVM_PGTABLE_PROT_DEVICE;
+	} else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
 		prot |= KVM_PGTABLE_PROT_X;
+	}
 
 	/*
 	 * Under the premise of getting a FSC_PERM fault, we just need to relax
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2bea89dc0bdf..d2f0f969875c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -391,6 +391,19 @@ extern unsigned int kobjsize(const void *objp);
 # define VM_UFFD_MINOR		VM_NONE
 #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
 
+/* This flag is used to connect VFIO to arch specific KVM code. It
+ * indicates that the memory under this VMA is safe for use with any
+ * non-cachable memory type inside KVM. Some VFIO devices, on some
+ * platforms, are thought to be unsafe and can cause machine crashes if
+ * KVM does not lock down the memory type.
+ */
+#ifdef CONFIG_64BIT
+#define VM_VFIO_ALLOW_WC_BIT	39
+#define VM_VFIO_ALLOW_WC	BIT(VM_VFIO_ALLOW_WC_BIT)
+#else
+#define VM_VFIO_ALLOW_WC	VM_NONE
+#endif
+
 /* Bits set in the VMA until the stack is in its final location */
 #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
 
-- 
2.17.1



From ankita at nvidia.com  Mon Dec 18 01:07:19 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Mon, 18 Dec 2023 14:37:19 +0530
Subject: [PATCH v4 3/3] vfio: convey kvm that the vfio-pci device is wc safe
In-Reply-To: <20231218090719.22250-1-ankita@nvidia.com>
References: <20231218090719.22250-1-ankita@nvidia.com>
Message-ID: <20231218090719.22250-4-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

The code to map the MMIO in S2 as NormalNC is enabled when conveyed
that the device is WC safe using a new flag VM_VFIO_ALLOW_WC.

Make vfio-pci set the VM_VFIO_ALLOW_WC flag.

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Jason Gunthorpe <jgg at nvidia.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>
---
 drivers/vfio/pci/vfio_pci_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 1cbc990d42e0..c3f95ec7fc3a 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1863,7 +1863,8 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
 	 * See remap_pfn_range(), called from vfio_pci_fault() but we can't
 	 * change vm_flags within the fault handler.  Set them now.
 	 */
-	vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
+	vm_flags_set(vma, VM_VFIO_ALLOW_WC | VM_IO | VM_PFNMAP |
+			VM_DONTEXPAND | VM_DONTDUMP);
 	vma->vm_ops = &vfio_pci_mmap_ops;
 
 	return 0;
-- 
2.17.1



From maxime.chevallier at bootlin.com  Mon Dec 18 01:11:31 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Mon, 18 Dec 2023 10:11:31 +0100
Subject: [PATCH net-next v4 01/13] net: phy: Introduce ethernet link
 topology representation
In-Reply-To: <20231215214523.ntk5kec32mb5vqjs@skbuf>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
	<20231215171237.1152563-1-maxime.chevallier@bootlin.com>
	<20231215171237.1152563-2-maxime.chevallier@bootlin.com>
	<20231215171237.1152563-2-maxime.chevallier@bootlin.com>
	<20231215214523.ntk5kec32mb5vqjs@skbuf>
Message-ID: <20231218101131.04160623@device-28.home>

Hello Vlad, PHy maintainers,

On Fri, 15 Dec 2023 23:45:23 +0200
Vladimir Oltean <vladimir.oltean at nxp.com> wrote:

> On Fri, Dec 15, 2023 at 06:12:23PM +0100, Maxime Chevallier wrote:
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > index d8e9335d415c..89daaccc9276 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -1491,6 +1500,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> >  
> >  		if (phydev->sfp_bus_attached)
> >  			dev->sfp_bus = phydev->sfp_bus;
> > +
> > +		err = phy_link_topo_add_phy(&dev->link_topo, phydev,
> > +					    PHY_UPSTREAM_MAC, dev);
> > +		if (err)
> > +			goto error;
> >  	}
> >  
> >  	/* Some Ethernet drivers try to connect to a PHY device before
> > @@ -1816,6 +1830,7 @@ void phy_detach(struct phy_device *phydev)
> >  	if (dev) {
> >  		phydev->attached_dev->phydev = NULL;
> >  		phydev->attached_dev = NULL;
> > +		phy_link_topo_del_phy(&dev->link_topo, phydev);
> >  	}
> >  	phydev->phylink = NULL;
> >  
> > diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
> > new file mode 100644
> > index 000000000000..22f6372d002c
> > --- /dev/null
> > +++ b/drivers/net/phy/phy_link_topology.c
> > +int phy_link_topo_add_phy(struct phy_link_topology *topo,
> > +			  struct phy_device *phy,
> > +			  enum phy_upstream upt, void *upstream)
> > +{
> > +	struct phy_device_node *pdn;
> > +	int ret;
> > +
> > +	/* Protects phy and upstream */
> > +	ASSERT_RTNL();  
> 
> Something to think for the PHY library maintainers. This is probably
> the first time when the rtnl_lock() requirement is asserted at
> phy_attach_direct() time.
> 
> I haven't done too much with the patch set yet, so I don't understand
> exactly from the comment what this is protecting. But I get the
> following assertion failure with DSA:
> 
> [    4.157160] ------------[ cut here ]------------
> [    4.161805] RTNL: assertion failed at drivers/net/phy/phy_link_topology.c (35)
> [    4.169124] WARNING: CPU: 0 PID: 26 at drivers/net/phy/phy_link_topology.c:35 phy_link_topo_add_phy+0x128/0x130
> [    4.179263] Modules linked in:
> [    4.209232] pc : phy_link_topo_add_phy+0x128/0x130
> [    4.214040] lr : phy_link_topo_add_phy+0x128/0x130
> [    4.293822] Call trace:
> [    4.296271]  phy_link_topo_add_phy+0x128/0x130
> [    4.300730]  phy_attach_direct+0xbc/0x3c4
> [    4.304752]  phylink_fwnode_phy_connect+0xa8/0xf8
> [    4.309473]  phylink_of_phy_connect+0x1c/0x28
> [    4.313844]  dsa_user_create+0x318/0x5ac
> [    4.317778]  dsa_port_setup+0x100/0x144
> [    4.321626]  dsa_register_switch+0xe90/0x11f8
> [    4.325997]  sja1105_probe+0x2bc/0x2e4
> [    4.329759]  spi_probe+0xa4/0xc4
> [    4.332995]  really_probe+0x16c/0x3fc
> [    4.336669]  __driver_probe_device+0xa4/0x168
> [    4.341041]  driver_probe_device+0x3c/0x220
> [    4.345238]  __device_attach_driver+0x128/0x1cc
> [    4.349784]  bus_for_each_drv+0xf4/0x14c
> [    4.353719]  __device_attach+0xfc/0x1bc
> [    4.357567]  device_initial_probe+0x14/0x20
> [    4.361764]  bus_probe_device+0x94/0x100
> [    4.385371] ---[ end trace 0000000000000000 ]---
> 
> Someone please correct me if I'm wrong, but at least up until now, calling
> this unlocked has been quite harmless, because we call dsa_user_phy_setup()
> before register_netdevice(), and thus, the net_device is pretty much
> inaccessible to the world when we attach it to the PHY.

Ok so I'll give it more thought on that part, and analyze better the
access paths that ca be problematic. I'll update the doc accordingly,
as this is non-trivial. I haven't been able to test it on a DSA setup,
nor on a !phylink mac, so thanks a lot for testing :)
> 
> And, while having the phydev->attached_dev pointer populated technically
> makes the net_device now accessible from the PHY, this is a moot point,
> because no user space command targets the PHY directly. They all target
> the netdev, and through that, netdev->phydev. The netdev is still
> unregistered, so it's ok to not have rtnl_lock().
> 
> It is rather going to be something that concerns those drivers which call
> phy_attach_direct() after registering, for example from ndo_open().

In that case this is fine, right ? As ndo_open runs with rtnl held,
phy-targetting netlink commands (that indeed goes through the netdev)
will be also serialized ? I might be missing the point though :(

> Interestingly, phylink_disconnect_phy() has an ASSERT_RTNL() in it
> even though the phylink_attach_phy() derivatives do not. I'm unable
> to ascertain whether a previous unregister_netdevice() call makes this
> requirement redundant or not.
> 
> > +
> > +	pdn = kzalloc(sizeof(*pdn), GFP_KERNEL);
> > +	if (!pdn)
> > +		return -ENOMEM;
> > +
> > +	pdn->phy = phy;
> > +	switch (upt) {
> > +	case PHY_UPSTREAM_MAC:
> > +		pdn->upstream.netdev = (struct net_device *)upstream;
> > +		if (phy_on_sfp(phy))
> > +			pdn->parent_sfp_bus = pdn->upstream.netdev->sfp_bus;
> > +		break;
> > +	case PHY_UPSTREAM_PHY:
> > +		pdn->upstream.phydev = (struct phy_device *)upstream;
> > +		if (phy_on_sfp(phy))
> > +			pdn->parent_sfp_bus = pdn->upstream.phydev->sfp_bus;
> > +		break;
> > +	default:
> > +		ret = -EINVAL;
> > +		goto err;
> > +	}
> > +	pdn->upstream_type = upt;
> > +
> > +	ret = xa_alloc_cyclic(&topo->phys, &phy->phyindex, pdn, xa_limit_32b,
> > +			      &topo->next_phy_index, GFP_KERNEL);
> > +	if (ret)
> > +		goto err;
> > +
> > +	return 0;
> > +
> > +err:
> > +	kfree(pdn);
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(phy_link_topo_add_phy);  



From laurent.pinchart at ideasonboard.com  Mon Dec 18 01:16:27 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 18 Dec 2023 11:16:27 +0200
Subject: [PATCH 1/2] Revert "media: rkisp1: Drop IRQF_SHARED"
In-Reply-To: <20231218-rkisp-shirq-fix-v1-1-173007628248@ideasonboard.com>
References: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>
 <20231218-rkisp-shirq-fix-v1-1-173007628248@ideasonboard.com>
Message-ID: <20231218091627.GA26540@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Mon, Dec 18, 2023 at 09:54:00AM +0200, Tomi Valkeinen wrote:
> This reverts commit 85d2a31fe4d9be1555f621ead7a520d8791e0f74.
> 
> The rkisp1 does share interrupt lines on some platforms, after all. Thus
> we need to revert this, and implement a fix for the rkisp1 shared irq
> handling in a follow-up patch.
> 
> Reported-by: Mikhail Rudenko <mike.rudenko at gmail.com>
> Closes: https://lore.kernel.org/all/87o7eo8vym.fsf at gmail.com/
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
>  drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index f96f821a7b50..acc559652d6e 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -559,7 +559,7 @@ static int rkisp1_probe(struct platform_device *pdev)
>  				rkisp1->irqs[il] = irq;
>  		}
>  
> -		ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0,
> +		ret = devm_request_irq(dev, irq, info->isrs[i].isr, IRQF_SHARED,
>  				       dev_driver_string(dev), dev);
>  		if (ret) {
>  			dev_err(dev, "request irq failed: %d\n", ret);

-- 
Regards,

Laurent Pinchart


From tabba at google.com  Mon Dec 18 01:16:36 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 18 Dec 2023 09:16:36 +0000
Subject: [PATCH v3 13/17] KVM: arm64: Define FGT nMASK bits relative to
 other fields
In-Reply-To: <86y1drangj.wl-maz@kernel.org>
References: <20231214100158.2305400-1-tabba@google.com> <20231214100158.2305400-14-tabba@google.com>
 <86y1drangj.wl-maz@kernel.org>
Message-ID: <CA+EHjTyxKA5hhCWg4nsT_D=Lu-MKzB4+M4QzvBQFO7DPrghNGg@mail.gmail.com>

On Mon, Dec 18, 2023 at 9:07?AM Marc Zyngier <maz at kernel.org> wrote:
>
> On Thu, 14 Dec 2023 10:01:53 +0000,
> Fuad Tabba <tabba at google.com> wrote:
> >
> > Now that RES0 and MASK have full coverage, no speed to manually
> > encode nMASK. Calculate it relative to the other fields.
>
> s/speed/need/ ?

I might have been in a hurry when I wrote this ;)
/fuad

>         M.
>
> --
> Without deviation from the norm, progress is not possible.


From quic_taozha at quicinc.com  Mon Dec 18 01:21:33 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Mon, 18 Dec 2023 17:21:33 +0800
Subject: [PATCH v3 1/8] dt-bindings: arm: Add support for CMB element size
In-Reply-To: <09447d69-e0ce-13e9-95ea-0db475b8bb6e@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-2-git-send-email-quic_taozha@quicinc.com>
 <09447d69-e0ce-13e9-95ea-0db475b8bb6e@arm.com>
Message-ID: <7d906e89-827f-49c7-96a2-004919218a26@quicinc.com>


On 12/15/2023 7:19 PM, James Clark wrote:
>
> On 21/11/2023 02:24, Tao Zhang wrote:
>> Add property "qcom,cmb-elem-size" to support CMB(Continuous
>> Multi-Bit) element for TPDM. The associated aggregator will read
>> this size before it is enabled. CMB element size currently only
>> supports 32-bit and 64-bit.
>>
>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>> ---
>>   .../bindings/arm/qcom,coresight-tpdm.yaml     | 28 +++++++++++++++++++
>>   1 file changed, 28 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
>> index 61ddc3b5b247..0d9fe01a8b15 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
>> @@ -52,6 +52,15 @@ properties:
>>       $ref: /schemas/types.yaml#/definitions/uint8
>>       enum: [32, 64]
>>   
>> +  qcom,cmb-element-size:
>> +    description:
>> +      Specifies the CMB(Continuous Multi-Bit) element size supported by
>> +      the monitor. The associated aggregator will read this size before it
>> +      is enabled. CMB element size currently only supports 8-bit, 32-bit
>> +      and 64-bit.
>> +    $ref: /schemas/types.yaml#/definitions/uint8
>> +    enum: [8, 32, 64]
>> +
>>     qcom,dsb-msrs-num:
>>       description:
>>         Specifies the number of DSB(Discrete Single Bit) MSR(mux select register)
>> @@ -110,4 +119,23 @@ examples:
>>         };
>>       };
>>   
>> +    tpdm at 6c29000 {
>> +      compatible = "qcom,coresight-tpdm", "arm,primecell";
>> +      reg = <0x06c29000 0x1000>;
>> +      reg-names = "tpdm-base";
> I think this one gives this error:
>
>   $ make dt_binding_check DT_SCHEMA_FILES=arm/qcom,coresight
>
>   DTC_CHK Documentation/devicetree/bindings/arm/qcom,coresight-
>    tpdm.example.dtb
>   qcom,coresight-tpdm.example.dtb: tpdm at 6c29000: 'reg-names' does not
>    match any of the regexes: 'pinctrl-[0-9]+'
>          from schema $id: http://devicetree.org/schemas
>          /arm/qcom,coresight-tpdm.yaml#

I will fix this in the next patch series.


Best,

Tao

>> +
>> +      qcom,cmb-element-size = /bits/ 8 <64>;
>> +
>> +      clocks = <&aoss_qmp>;
>> +      clock-names = "apb_pclk";
>> +
>> +      out-ports {
>> +        port {
>> +          tpdm_ipcc_out_funnel_center: endpoint {
>> +            remote-endpoint =
>> +              <&funnel_center_in_tpdm_ipcc>;
>> +          };
>> +        };
>> +      };
>> +    };
>>   ...


From laurent.pinchart at ideasonboard.com  Mon Dec 18 01:22:40 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 18 Dec 2023 11:22:40 +0200
Subject: [PATCH 2/2] media: rkisp1: Fix IRQ handling due to shared
 interrupts
In-Reply-To: <20231218-rkisp-shirq-fix-v1-2-173007628248@ideasonboard.com>
References: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>
 <20231218-rkisp-shirq-fix-v1-2-173007628248@ideasonboard.com>
Message-ID: <20231218092240.GB26540@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Mon, Dec 18, 2023 at 09:54:01AM +0200, Tomi Valkeinen wrote:
> The driver requests the interrupts as IRQF_SHARED, so the interrupt
> handlers can be called at any time. If such a call happens while the ISP
> is powered down, the SoC will hang as the driver tries to access the
> ISP registers.
> 
> This can be reproduced even without the platform sharing the IRQ line:
> Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will
> hang.
> 
> Fix this by adding a new field, 'irqs_enabled', which is used to bail
> out from the interrupt handler when the ISP is not operational.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
>  .../platform/rockchip/rkisp1/rkisp1-capture.c      |  3 +++
>  .../media/platform/rockchip/rkisp1/rkisp1-common.h |  2 ++
>  .../media/platform/rockchip/rkisp1/rkisp1-csi.c    |  3 +++
>  .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 22 ++++++++++++++++++++++
>  .../media/platform/rockchip/rkisp1/rkisp1-isp.c    |  3 +++
>  5 files changed, 33 insertions(+)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> index aebd3c12020b..c381c22135a2 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> @@ -725,6 +725,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
>  	unsigned int i;
>  	u32 status;
>  
> +	if (!rkisp1->irqs_enabled)
> +		return IRQ_NONE;

Given that this is something all drivers that use shared IRQs have to
do, would it make sense to use a standard helper here, such as
pm_runtime_suspended() for instance ? I haven't looked at which one
would be the most appropriate (if any), there's also
pm_runtime_active() and pm_runtime_status_suspended(). That would
simplify this patch.

> +
>  	status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
>  	if (!status)
>  		return IRQ_NONE;
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> index 4b6b28c05b89..b757f75edecf 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> @@ -450,6 +450,7 @@ struct rkisp1_debug {
>   * @debug:	   debug params to be exposed on debugfs
>   * @info:	   version-specific ISP information
>   * @irqs:          IRQ line numbers
> + * @irqs_enabled:  the hardware is enabled and can cause interrupts
>   */
>  struct rkisp1_device {
>  	void __iomem *base_addr;
> @@ -471,6 +472,7 @@ struct rkisp1_device {
>  	struct rkisp1_debug debug;
>  	const struct rkisp1_info *info;
>  	int irqs[RKISP1_NUM_IRQS];
> +	bool irqs_enabled;
>  };
>  
>  /*
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> index b6e47e2f1b94..4202642e0523 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> @@ -196,6 +196,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
>  	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>  	u32 val, status;
>  
> +	if (!rkisp1->irqs_enabled)
> +		return IRQ_NONE;
> +
>  	status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
>  	if (!status)
>  		return IRQ_NONE;
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index acc559652d6e..73cf08a74011 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -305,6 +305,24 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
>  {
>  	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>  
> +	rkisp1->irqs_enabled = false;
> +	/* Make sure the IRQ handler will see the above */
> +	mb();
> +
> +	/*
> +	 * Wait until any running IRQ handler has returned. The IRQ handler
> +	 * may get called even after this (as it's a shared interrupt line)
> +	 * but the 'irqs_enabled' flag will make the handler return immediately.
> +	 */
> +	for (unsigned int il = 0; il < ARRAY_SIZE(rkisp1->irqs); ++il) {
> +		if (rkisp1->irqs[il] == -1)
> +			continue;
> +
> +		/* Skip if the irq line is the same as previous */
> +		if (il == 0 || rkisp1->irqs[il - 1] != rkisp1->irqs[il])
> +			synchronize_irq(rkisp1->irqs[il]);
> +	}
> +
>  	clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
>  	return pinctrl_pm_select_sleep_state(dev);
>  }
> @@ -321,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
>  	if (ret)
>  		return ret;
>  
> +	rkisp1->irqs_enabled = true;
> +	/* Make sure the IRQ handler will see the above */
> +	mb();
> +
>  	return 0;
>  }
>  
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> index f00873d31c42..78a1f7a1499b 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> @@ -976,6 +976,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
>  	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>  	u32 status, isp_err;
>  
> +	if (!rkisp1->irqs_enabled)
> +		return IRQ_NONE;
> +
>  	status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
>  	if (!status)
>  		return IRQ_NONE;

-- 
Regards,

Laurent Pinchart


From lpieralisi at kernel.org  Mon Dec 18 01:23:18 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Mon, 18 Dec 2023 10:23:18 +0100
Subject: [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields
In-Reply-To: <ZXyEiHLFBsoUkfNI@shell.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOgs-00Dvko-6t@rmk-PC.armlinux.org.uk>
 <20231215162322.00007391@Huawei.com>
 <ZXyEiHLFBsoUkfNI@shell.armlinux.org.uk>
Message-ID: <ZYAPhlwPUT/7dN4n@lpieralisi>

On Fri, Dec 15, 2023 at 04:53:28PM +0000, Russell King (Oracle) wrote:
> On Fri, Dec 15, 2023 at 04:23:22PM +0000, Jonathan Cameron wrote:
> > On Wed, 13 Dec 2023 12:50:18 +0000
> > Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> > 
> > > From: James Morse <james.morse at arm.com>
> > > 
> > > Add the new flag field to the MADT's GICC structure.
> > > 
> > > 'Online Capable' indicates a disabled CPU can be enabled later. See
> > > ACPI specification 6.5 Tabel 5.37: GICC CPU Interface Flags.
> > > 
> > > Signed-off-by: James Morse <james.morse at arm.com>
> > > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > 
> > I see there is an acpica pull request including this bit but with a different name
> > For reference.
> > https://github.com/acpica/acpica/pull/914/commits/453a5f67567786522021d5f6913f561f8b3cabf6
> > 
> > +CC Lorenzo who submitted that.
> 
> > > +#define ACPI_MADT_GICC_CPU_CAPABLE      (1<<3)	/* 03: CPU is online capable */
> > 
> > ACPI_MADT_GICC_ONLINE_CAPABLE
> 
> It's somewhat disappointing, but no big deal. It's easy enough to change
> "irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs"
> to use Lorenzo's name when that patch hits - and it becomes one less
> patch in this patch set when Lorenzo's change eventually hits mainline.
> 
> Does anyone know how long it may take for Lorenzo's change to get into
> mainline? Would it be by the 6.8 merge window or the following one?

I wish I knew. I submitted ACPICA changes for the online capable bit
since I had to add additional flags on top (ie DMA coherent) and it
would not make sense to submit the latter without the former.

I'd be great if the ACPICA headers can make it into Linux for the upcoming
merge window, not sure what I can do to fasttrack the process though
(I shall ping the maintainers).

Lorenzo

> Thanks.
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From hns at goldelico.com  Mon Dec 18 01:28:09 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Mon, 18 Dec 2023 10:28:09 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <oobcl2kfsuph27er7rflfqvt3lu6athufomxv5chf3uctx4emh@x6rzjtlskhbf>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
 <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
 <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>
 <oobcl2kfsuph27er7rflfqvt3lu6athufomxv5chf3uctx4emh@x6rzjtlskhbf>
Message-ID: <F58855EC-D87D-4747-A363-0E7AA5DB1AEC@goldelico.com>

Hi Maxime,

> Am 15.12.2023 um 14:33 schrieb Maxime Ripard <mripard at kernel.org>:
> 
>>> 
>>> It's for a separate architecture, with a separate driver, maintained out
>>> of tree by a separate community, with a separate set of requirements as
>>> evidenced by the other thread. And that's all fine in itself, but
>>> there's very little reason to put these two bindings in the same file.
>>> 
>>> We could also turn this around, why is it important that it's in the
>>> same file?
>> 
>> Same vendor. And enough similarity in architectures, even a logical sequence
>> of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
>> (SGX and Rogue seem to be just trade names for their architecture development).
> 
> Again, none of that matters for *where* the binding is stored.

So what then speaks against extending the existing bindings file as proposed
here?

> 
>> AFAIK bindings should describe hardware and not communities or drivers
>> or who is currently maintaining it. The latter can change, the first not.
> 
> Bindings are supposed to describe hardware indeed. Nothing was ever said
> about where those bindings are supposed to be located.
> 
> There's hundreds of other YAML bindings describing devices of the same
> vendors and different devices from the same generation.

Usually SoC seem to be split over multiple files by subsystem. Not by versions
or generations. If the subsystems are similar enough they share the same bindings
doc instead of having one for each generation duplicating a lot of code.

Here is a comparable example that combines multiple vendors and generations:

Documentation/devicetree/bindings/usb/generic-ehci.yaml

> If anything it'll make it easier for you. I'm really not sure why it is
> controversial and you're fighting this so hard.

Well, you made it controversial by proposing to split what IMHO belongs together.

I feel that the original patch is good enough for its purpose and follows
some design pattern that can be deduced from other binding docs.

BR,
Nikolaus



From u.kleine-koenig at pengutronix.de  Mon Dec 18 01:31:36 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 18 Dec 2023 10:31:36 +0100
Subject: [PATCH v9 5/6] pwm: bcm2835: Allow PWM driver to be used in
 atomic context
In-Reply-To: <5249bb5d6c067692e4cd09573ced2df58966693b.1702890244.git.sean@mess.org>
References: <cover.1702890244.git.sean@mess.org>
 <5249bb5d6c067692e4cd09573ced2df58966693b.1702890244.git.sean@mess.org>
Message-ID: <eicw7ppqj5dubskhmeh7iwdaoixv27qw2zqaljkddt2rwosogt@6aftnwt6p5ek>

Hello Sean,

On Mon, Dec 18, 2023 at 09:06:46AM +0000, Sean Young wrote:
> @@ -151,16 +146,40 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
>  		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
>  				     "clock not found\n");
>  
> +	ret = clk_rate_exclusive_get(pc->clk);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "fail to get exclusive rate\n");

If Maxime didn't object to my series at
https://lore.kernel.org/linux-clk/cover.1702400947.git.u.kleine-koenig at pengutronix.de/,
I'd ask you to not do error checking here. With the objection I hesitate
to ask for that and just mention it.

> +	pc->rate = clk_get_rate(pc->clk);
> +	if (!pc->rate) {
> +		clk_rate_exclusive_put(pc->clk);
> +		return dev_err_probe(&pdev->dev, -EINVAL,
> +				     "failed to get clock rate\n");
> +	}
> +
>  	pc->chip.dev = &pdev->dev;
>  	pc->chip.ops = &bcm2835_pwm_ops;
> +	pc->chip.atomic = true;
>  	pc->chip.npwm = 2;
>  
>  	platform_set_drvdata(pdev, pc);
>  
>  	ret = devm_pwmchip_add(&pdev->dev, &pc->chip);
> -	if (ret < 0)
> +	if (ret < 0) {
> +		clk_rate_exclusive_put(pc->clk);
>  		return dev_err_probe(&pdev->dev, ret,
>  				     "failed to add pwmchip\n");
> +	}
> +
> +	return 0;
> +}
> +
> +static int bcm2835_pwm_remove(struct platform_device *pdev)
> +{
> +	struct bcm2835_pwm *pc = platform_get_drvdata(pdev);
> +
> +	clk_rate_exclusive_put(pc->clk);

The ugly thing here is that now clk_rate_exclusive_put() happens before
pwmchip_remove(). Maybe register a devm cleanup which also gets rid of
the two clk_rate_exclusive_put() in probe's error path?

>  	return 0;
>  }
> @@ -197,6 +216,7 @@ static struct platform_driver bcm2835_pwm_driver = {
>  		.pm = pm_ptr(&bcm2835_pwm_pm_ops),
>  	},
>  	.probe = bcm2835_pwm_probe,
> +	.remove = bcm2835_pwm_remove,

Please use .remove_new

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/9f7ac316/attachment.sig>

From neil.armstrong at linaro.org  Mon Dec 18 01:39:28 2023
From: neil.armstrong at linaro.org (neil.armstrong at linaro.org)
Date: Mon, 18 Dec 2023 10:39:28 +0100
Subject: [PATCH v9 08/12] clk: meson: g12a: make VCLK2 and ENCL clock path
 configurable by CCF
In-Reply-To: <1jjzq3zhaw.fsf@starbuckisacylon.baylibre.com>
References: <20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed139e6@linaro.org>
 <20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-8-95256ed139e6@linaro.org>
 <1jbkbjdxk8.fsf@starbuckisacylon.baylibre.com>
 <b23ddc3b-d995-4cd6-91f2-3efa59d345a5@linaro.org>
 <1j34wvdtux.fsf@starbuckisacylon.baylibre.com>
 <41a1246e-c885-460a-8208-16844e95e1ae@linaro.org>
 <1jjzq3zhaw.fsf@starbuckisacylon.baylibre.com>
Message-ID: <db90068a-8eac-458e-bc22-aceb59870f5d@linaro.org>

Hi,

On 27/11/2023 09:38, Jerome Brunet wrote:
> 
>>>
>>>>
>>>> I suspect mipi_dsi_pxclk_div was added to achieve fractional vclk/bitclk ratios,
>>>> since it doesn't exist on AXG. Not sure we would ever need it... and none
>>>> of the other upstream DSI drivers supports such setups.
>>>>
>>>> The main reasons I set only mipi_dsi_pxclk in DT is because :
>>>> 1) the DSI controller requires a bitclk to respond, pclk is not enough
>>>> 2) GP0 is disabled with an invalid config at cold boot, thus we cannot
>>>> rely on a default/safe rate on an initial prepare_enable().
>>>> This permits setting initial valid state for the DSI controller, while
>>>> the actual bitclk and vclk are calculated dynamically with panel/bridge
>>>> runtime parameters.
>>> Nothing against setting rate in DT when it is static. Setting it then
>>> overriding it is not easy to follow.
>>
>> Yup, would be simpler to only have parenting set in DT, since it must
>> stay static, I'm fine trying to move rate setup to code.
>>
>>> To work around GP0 not being set, assuming you want to keep rate
>>> propagation as it is, you could call clk_set_rate() on cts_encl (possibly w/o
>>> enabling it) to force a setup on gp0 then clk_prepare_enable() on
>>> pxclk. You'd get a your safe rate on GP0 and the clock you need on pxclk.
>>> It is a bit hackish. Might be better to claim gp0 in your driver to
>>> manage it directly, cutting rate propagation above it to control each
>>> branch of the subtree as you need. It seems you need to have control over
>>> that anyway and it would be clear GP0 is expected to belong to DSI.
>>
>> Controlling the PLL from the DSI controller seems violating too much layers,
>> DSI controller driver is not feed directly by the PLL so it's a non-sense
>> regarding DT properties.
> 
> Not sure what you mean by this. You have shown in your the commit
> message that the DSI clocks make significant subtree. I don't see a
> problem if you need to manage the root of that subtree. I'd be great if
> you didn't need to, but it is what it is ...

I really think the choice of PLL should not be done by the DSI controller,
but by the Video pipeline driver or statically until we can do this.

My point is that we should only define the clocks that are related to each
hardware, for example the whole VCLK/VCLK2 clocks should be defined for the
VPU HW, then only the few endpoint clocks should be defined for the HDMI
or DSI controllers, PHY clock and ENCI/ENCP for HDMI, DSI and ENCL for DSI.

The big plan is to entirely switch to CCF for VPU, but first I want to have
DSI working, and since DSI needs GP0, we need CCF for that so the intermediate
plan is to have partial CCF handling only for DSI with fixed clock tree in DT,
then in the future the Meson DRM driver would set up the appropriate clock
tree for HDMI, DSI, Composite and perhaps DP for T7 SoCs then the controller
bridge will call the clk_set_rate() in the same design I did for DSI.

Here's the tracked item: https://gitlab.com/amlogic-foss/mainline-linux-issues-tracker/-/issues/9

CCF clock control is a mandatory item to solved dual-head display: https://gitlab.com/amlogic-foss/mainline-linux-issues-tracker/-/issues/6

> 
>>
>> Setting a safe clock from the DSI controller probe is an idea, but again I
>> don't know which value I should use...
> 
> You mentionned that the problem comes DSI bridges that needs to change
> at runtime. I don't know much about those TBH, but is there
> anyway you can come up with a static GP0 rate that would then be able to
> divide to serve all the rates bridge would need in your use case ?

No, there's no such things in the DSI world, MIPI only specifies the electrical
and transport layer, everything else is custom per vendor.

> 
> GP0 can go a lot higher than ~100MHz and there are dividers unused in the
> tree it seems.
> 
> I suppose there is a finite number of required rate for each use case ?
> If there are not too many and there is a common divider that allows a
> common rate GP0 can do, it would solve your problem. It's a lot of if
> but It is worth checking.
> 
> This is how audio works and DT assigned rate is a good match in this case.

Yeah I know, but I would love it but no...

> 
>>
>> I'll review the clk parenting flags and try to hack something.
>>
>> Thanks,
>> Neil
>>
>>

Thanks,
Neil



From maz at kernel.org  Mon Dec 18 01:40:18 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 18 Dec 2023 09:40:18 +0000
Subject: [PATCH v3 14/17] KVM: arm64: Macros for setting/clearing FGT bits
In-Reply-To: <20231214100158.2305400-15-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
	<20231214100158.2305400-15-tabba@google.com>
Message-ID: <86wmtbalx9.wl-maz@kernel.org>

On Thu, 14 Dec 2023 10:01:54 +0000,
Fuad Tabba <tabba at google.com> wrote:
> 
> There's a lot of boilerplate code for setting and clearing FGT
> bits when activating guest traps. Refactor it into macros. These
> macros will also be used in future patch series.
> 
> No functional change intended.
> 
> Signed-off-by: Fuad Tabba <tabba at google.com>
> ---
>  arch/arm64/kvm/hyp/include/hyp/switch.h | 60 +++++++++----------------
>  1 file changed, 21 insertions(+), 39 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index 17ce40f5b006..e223fc0d5193 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -79,6 +79,23 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
>  		clr |= ~hfg & __ ## reg ## _nMASK; 			\
>  	} while(0)
>  
> +#define update_fgt_traps_cs(reg, clr, set)				\
> +	do {								\
> +		struct kvm_cpu_context *hctxt =				\
> +			&this_cpu_ptr(&kvm_host_data)->host_ctxt;	\
> +		u64 val, c = 0, s = 0;					\
> +									\
> +		ctxt_sys_reg(hctxt, reg) = read_sysreg_s(SYS_ ## reg);	\
> +		compute_clr_set(vcpu, reg, c, s);			\

You are referring to a variable name that is in the scope of the macro
user, and not the macro itself. It is so fragile it isn't funny.

Why don't you simply pass the vcpu as a parameter to the function?

Another thing is that this read/write can be expensive. How about not
doing anything when there is no change to the value of the sysreg?

I'll see if I can come up with something.

	M.

-- 
Without deviation from the norm, progress is not possible.


From jay.buddhabhatti at amd.com  Mon Dec 18 01:40:07 2023
From: jay.buddhabhatti at amd.com (Jay Buddhabhatti)
Date: Mon, 18 Dec 2023 01:40:07 -0800
Subject: [PATCH 0/2] add platform check in event manager driver
Message-ID: <20231218094009.13528-1-jay.buddhabhatti@amd.com>

Some error event IDs for Versal and Versal NET are different.
Both the platforms should access their respective error event
IDs so use sub_family_code to check for Versal or Versal NET
platform and check error IDs for respective platforms.

Jay Buddhabhatti (2):
  firmware: xilinx: Export function to use in other module
  drivers: soc: xilinx: add check for platform

 drivers/firmware/xilinx/zynqmp.c        |  3 ++-
 drivers/soc/xilinx/xlnx_event_manager.c | 25 ++++++++++++++++++++-----
 include/linux/firmware/xlnx-zynqmp.h    | 22 ++++++++++++++++++----
 3 files changed, 40 insertions(+), 10 deletions(-)

-- 
2.17.1



From jay.buddhabhatti at amd.com  Mon Dec 18 01:40:09 2023
From: jay.buddhabhatti at amd.com (Jay Buddhabhatti)
Date: Mon, 18 Dec 2023 01:40:09 -0800
Subject: [PATCH 2/2] drivers: soc: xilinx: add check for platform
In-Reply-To: <20231218094009.13528-1-jay.buddhabhatti@amd.com>
References: <20231218094009.13528-1-jay.buddhabhatti@amd.com>
Message-ID: <20231218094009.13528-3-jay.buddhabhatti@amd.com>

Some error event IDs for Versal and Versal NET are different.
Both the platforms should access their respective error event
IDs so use sub_family_code to check for Versal or Versal NET
platform and check error IDs for respective platforms.

Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti at amd.com>
---
 drivers/soc/xilinx/xlnx_event_manager.c | 25 ++++++++++++++++++++-----
 include/linux/firmware/xlnx-zynqmp.h    | 16 ++++++++++++----
 2 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/xilinx/xlnx_event_manager.c b/drivers/soc/xilinx/xlnx_event_manager.c
index 86a048a10a13..78f9a3c6ae11 100644
--- a/drivers/soc/xilinx/xlnx_event_manager.c
+++ b/drivers/soc/xilinx/xlnx_event_manager.c
@@ -77,11 +77,26 @@ struct registered_event_data {
 
 static bool xlnx_is_error_event(const u32 node_id)
 {
-	if (node_id == EVENT_ERROR_PMC_ERR1 ||
-	    node_id == EVENT_ERROR_PMC_ERR2 ||
-	    node_id == EVENT_ERROR_PSM_ERR1 ||
-	    node_id == EVENT_ERROR_PSM_ERR2)
-		return true;
+	u32 pm_family_code, pm_sub_family_code;
+
+	zynqmp_pm_get_family_info(&pm_family_code, &pm_sub_family_code);
+
+	if (pm_sub_family_code == VERSAL_SUB_FAMILY_CODE) {
+		if (node_id == VERSAL_EVENT_ERROR_PMC_ERR1 ||
+		    node_id == VERSAL_EVENT_ERROR_PMC_ERR2 ||
+		    node_id == VERSAL_EVENT_ERROR_PSM_ERR1 ||
+		    node_id == VERSAL_EVENT_ERROR_PSM_ERR2)
+			return true;
+	} else {
+		if (node_id == VERSAL_NET_EVENT_ERROR_PMC_ERR1 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PMC_ERR2 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PMC_ERR3 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PSM_ERR1 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PSM_ERR2 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PSM_ERR3 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PSM_ERR4)
+			return true;
+	}
 
 	return false;
 }
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 2375ce9b38df..2cfd78f232dc 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -91,10 +91,18 @@
 /*
  * Node IDs for the Error Events.
  */
-#define EVENT_ERROR_PMC_ERR1	(0x28100000U)
-#define EVENT_ERROR_PMC_ERR2	(0x28104000U)
-#define EVENT_ERROR_PSM_ERR1	(0x28108000U)
-#define EVENT_ERROR_PSM_ERR2	(0x2810C000U)
+#define VERSAL_EVENT_ERROR_PMC_ERR1	(0x28100000U)
+#define VERSAL_EVENT_ERROR_PMC_ERR2	(0x28104000U)
+#define VERSAL_EVENT_ERROR_PSM_ERR1	(0x28108000U)
+#define VERSAL_EVENT_ERROR_PSM_ERR2	(0x2810C000U)
+
+#define VERSAL_NET_EVENT_ERROR_PMC_ERR1	(0x28100000U)
+#define VERSAL_NET_EVENT_ERROR_PMC_ERR2	(0x28104000U)
+#define VERSAL_NET_EVENT_ERROR_PMC_ERR3	(0x28108000U)
+#define VERSAL_NET_EVENT_ERROR_PSM_ERR1	(0x2810C000U)
+#define VERSAL_NET_EVENT_ERROR_PSM_ERR2	(0x28110000U)
+#define VERSAL_NET_EVENT_ERROR_PSM_ERR3	(0x28114000U)
+#define VERSAL_NET_EVENT_ERROR_PSM_ERR4	(0x28118000U)
 
 /* ZynqMP SD tap delay tuning */
 #define SD_ITAPDLY	0xFF180314
-- 
2.17.1



From jay.buddhabhatti at amd.com  Mon Dec 18 01:40:08 2023
From: jay.buddhabhatti at amd.com (Jay Buddhabhatti)
Date: Mon, 18 Dec 2023 01:40:08 -0800
Subject: [PATCH 1/2] firmware: xilinx: Export function to use in other module
In-Reply-To: <20231218094009.13528-1-jay.buddhabhatti@amd.com>
References: <20231218094009.13528-1-jay.buddhabhatti@amd.com>
Message-ID: <20231218094009.13528-2-jay.buddhabhatti@amd.com>

Export zynqmp_pm_get_family_info() to access and find family information
in other module.

Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti at amd.com>
---
 drivers/firmware/xilinx/zynqmp.c     | 3 ++-
 include/linux/firmware/xlnx-zynqmp.h | 6 ++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index b0d22d4455d9..313965f79dd7 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -414,7 +414,7 @@ EXPORT_SYMBOL_GPL(zynqmp_pm_get_chipid);
  *
  * Return: Returns status, either success or error+reason
  */
-static int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily)
+int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily)
 {
 	u32 ret_payload[PAYLOAD_ARG_CNT];
 	u32 idcode;
@@ -439,6 +439,7 @@ static int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_family_info);
 
 /**
  * zynqmp_pm_get_trustzone_version() - Get secure trustzone firmware version
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index d1ea3898564c..2375ce9b38df 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -515,6 +515,7 @@ int zynqmp_pm_invoke_fn(u32 pm_api_id, u32 arg0, u32 arg1,
 #if IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE)
 int zynqmp_pm_get_api_version(u32 *version);
 int zynqmp_pm_get_chipid(u32 *idcode, u32 *version);
+int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily);
 int zynqmp_pm_query_data(struct zynqmp_pm_query_data qdata, u32 *out);
 int zynqmp_pm_clock_enable(u32 clock_id);
 int zynqmp_pm_clock_disable(u32 clock_id);
@@ -596,6 +597,11 @@ static inline int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
 	return -ENODEV;
 }
 
+static inline int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily)
+{
+	return -ENODEV;
+}
+
 static inline int zynqmp_pm_query_data(struct zynqmp_pm_query_data qdata,
 				       u32 *out)
 {
-- 
2.17.1



From manikanta.guntupalli at amd.com  Mon Dec 18 01:44:12 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Mon, 18 Dec 2023 15:14:12 +0530
Subject: [PATCH V7 0/3] Add rs485 support to uartps driver
Message-ID: <20231218094415.2503672-1-manikanta.guntupalli@amd.com>

Add reference to rs485.yaml.
Add rs485 support to uartps driver.
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.
Add support for RTS, delay_rts_before_send and delay_rts_after_send in RS485 mode.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.
Move cdns_uart_tx_empty function to avoid prototype statement.
Remove assignment of struct serial_rs485 to port->rs485 as
serial core performs that.
Switch to native RTS in non GPIO case.
Handle rs485 during stop tx.
Remove explicit calls to configure gpio direction and value,
as devm_gpiod_get_optional performs that by using GPIOD_OUT_LOW argument.
Update implementation to support configuration of GPIO/RTS value
based on user configuration of SER_RS485_RTS_ON_SEND and
SER_RS485_RTS_AFTER_SEND. Move implementation to start_tx from handle_tx.

Changes for V4:
Update rts-gpios description.
Create separate patch for cdns_uart_tx_empty relocation.
Call cdns_rs485_rx_setup() before uart_add_one_port() in probe.
Update gpio descriptor name to gpiod_rts.
Instead of cdns_rs485_config_gpio_rts_high() and
cdns_rs485_config_gpio_rts_low() functions for RTS/GPIO value
configuration implement cdns_rts_gpio_enable().
Disable auto rts and call cdns_uart_stop_tx() from cdns_rs485_config.
Use timer instead of mdelay for delay_rts_before_send and delay_rts_after_send.
Update cdns_uart_set_mctrl to support GPIO/RTS.

Changes for V5:
Remove rts-gpios description.
Update commit message and description.

Changes for V6:
Update commit description.
Disable the TX and RX in cdns_rs485_config() when rs485 disabled.
Hold lock for cdns_uart_handle_tx() in cdns_rs485_tx_callback().

Changes for V7:
Update commit description.

Manikanta Guntupalli (3):
  dt-bindings: Add reference to rs485.yaml
  tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485
  tty: serial: uartps: Add rs485 support to uartps driver

 .../devicetree/bindings/serial/cdns,uart.yaml |   1 +
 drivers/tty/serial/xilinx_uartps.c            | 252 ++++++++++++++++--
 2 files changed, 229 insertions(+), 24 deletions(-)

-- 
2.25.1



From manikanta.guntupalli at amd.com  Mon Dec 18 01:44:13 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Mon, 18 Dec 2023 15:14:13 +0530
Subject: [PATCH V7 1/3] dt-bindings: Add reference to rs485.yaml
In-Reply-To: <20231218094415.2503672-1-manikanta.guntupalli@amd.com>
References: <20231218094415.2503672-1-manikanta.guntupalli@amd.com>
Message-ID: <20231218094415.2503672-2-manikanta.guntupalli@amd.com>

Xilinx/AMD Kria SOM KD240 board has a rs485 compatible peripheral.
Update the binding to have rs485 support.

Acked-by: Conor Dooley <conor.dooley at microchip.com>
Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.

Changes for V4:
Update rts-gpios description.

Changes for V5:
Remove rts-gpios description.
Update commit message and description.

Changes for V6:
Update commit description.

Changes for V7:
Update commit description.
---
 Documentation/devicetree/bindings/serial/cdns,uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
index e35ad1109efc..2129247d7c81 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
@@ -55,6 +55,7 @@ required:
 
 allOf:
   - $ref: serial.yaml#
+  - $ref: rs485.yaml#
   - if:
       properties:
         compatible:
-- 
2.25.1



From manikanta.guntupalli at amd.com  Mon Dec 18 01:44:14 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Mon, 18 Dec 2023 15:14:14 +0530
Subject: [PATCH V7 2/3] tty: serial: uartps: Relocate cdns_uart_tx_empty to facilitate rs485
In-Reply-To: <20231218094415.2503672-1-manikanta.guntupalli@amd.com>
References: <20231218094415.2503672-1-manikanta.guntupalli@amd.com>
Message-ID: <20231218094415.2503672-3-manikanta.guntupalli@amd.com>

Relocate cdns_uart_tx_empty function to avoid prototype statement in
rs485 changes.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes since V4:
This patch introduced in V4.

Changes for V5:
None.

Changes for V6:
None.

Changes for V7:
None.
---
 drivers/tty/serial/xilinx_uartps.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 920762d7b4a4..aafcc2179e0e 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -305,6 +305,21 @@ static void cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus)
 	tty_flip_buffer_push(&port->state->port);
 }
 
+/**
+ * cdns_uart_tx_empty -  Check whether TX is empty
+ * @port: Handle to the uart port structure
+ *
+ * Return: TIOCSER_TEMT on success, 0 otherwise
+ */
+static unsigned int cdns_uart_tx_empty(struct uart_port *port)
+{
+	unsigned int status;
+
+	status = readl(port->membase + CDNS_UART_SR);
+	status &= (CDNS_UART_SR_TXEMPTY | CDNS_UART_SR_TACTIVE);
+	return (status == CDNS_UART_SR_TXEMPTY) ? TIOCSER_TEMT : 0;
+}
+
 /**
  * cdns_uart_handle_tx - Handle the bytes to be Txed.
  * @dev_id: Id of the UART port
@@ -626,21 +641,6 @@ static void cdns_uart_stop_rx(struct uart_port *port)
 	writel(regval, port->membase + CDNS_UART_CR);
 }
 
-/**
- * cdns_uart_tx_empty -  Check whether TX is empty
- * @port: Handle to the uart port structure
- *
- * Return: TIOCSER_TEMT on success, 0 otherwise
- */
-static unsigned int cdns_uart_tx_empty(struct uart_port *port)
-{
-	unsigned int status;
-
-	status = readl(port->membase + CDNS_UART_SR) &
-		       (CDNS_UART_SR_TXEMPTY | CDNS_UART_SR_TACTIVE);
-	return (status == CDNS_UART_SR_TXEMPTY) ? TIOCSER_TEMT : 0;
-}
-
 /**
  * cdns_uart_break_ctl - Based on the input ctl we have to start or stop
  *			transmitting char breaks
-- 
2.25.1



From manikanta.guntupalli at amd.com  Mon Dec 18 01:44:15 2023
From: manikanta.guntupalli at amd.com (Manikanta Guntupalli)
Date: Mon, 18 Dec 2023 15:14:15 +0530
Subject: [PATCH V7 3/3] tty: serial: uartps: Add rs485 support to uartps driver
In-Reply-To: <20231218094415.2503672-1-manikanta.guntupalli@amd.com>
References: <20231218094415.2503672-1-manikanta.guntupalli@amd.com>
Message-ID: <20231218094415.2503672-4-manikanta.guntupalli@amd.com>

Add rs485 support to uartps driver. Use either rts-gpios or RTS
to control RS485 phy as driver or a receiver.

Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli at amd.com>
---
Changes for V2:
Modify optional gpio name to xlnx,phy-ctrl-gpios.
Update commit description.
Add support for RTS, delay_rts_before_send and delay_rts_after_send in RS485 mode.

Changes for V3:
Modify optional gpio name to rts-gpios.
Update commit description.
Move cdns_uart_tx_empty function to avoid prototype statement.
Remove assignment of struct serial_rs485 to port->rs485 as
serial core performs that.
Switch to native RTS in non GPIO case.
Handle rs485 during stop tx.
Remove explicit calls to configure gpio direction and value,
as devm_gpiod_get_optional performs that by using GPIOD_OUT_LOW argument.
Update implementation to support configuration of GPIO/RTS value
based on user configuration of SER_RS485_RTS_ON_SEND and
SER_RS485_RTS_AFTER_SEND. Move implementation to start_tx from handle_tx.

Changes for V4:
Create separate patch for cdns_uart_tx_empty relocation.
Call cdns_rs485_rx_setup() before uart_add_one_port() in probe.
Update gpio descriptor name to gpiod_rts.
Instead of cdns_rs485_config_gpio_rts_high() and
cdns_rs485_config_gpio_rts_low() functions for RTS/GPIO value
configuration implement cdns_rts_gpio_enable().
Disable auto rts and call cdns_uart_stop_tx() from cdns_rs485_config.
Use timer instead of mdelay for delay_rts_before_send and delay_rts_after_send.
Update cdns_uart_set_mctrl to support GPIO/RTS.

Changes for V5:
None.

Changes for V6:
Disable the TX and RX in cdns_rs485_config() when rs485 disabled.
Hold lock for cdns_uart_handle_tx() in cdns_rs485_tx_callback().

Changes for V7:
None.
---
 drivers/tty/serial/xilinx_uartps.c | 222 +++++++++++++++++++++++++++--
 1 file changed, 213 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index aafcc2179e0e..04cc23deebdf 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -22,7 +22,9 @@
 #include <linux/of.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
-#include <linux/iopoll.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/delay.h>
 
 #define CDNS_UART_TTY_NAME	"ttyPS"
 #define CDNS_UART_NAME		"xuartps"
@@ -193,6 +195,10 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255");
  * @clk_rate_change_nb:	Notifier block for clock changes
  * @quirks:		Flags for RXBS support.
  * @cts_override:	Modem control state override
+ * @gpiod_rts:		Pointer to the gpio descriptor
+ * @rs485_tx_started:	RS485 tx state
+ * @timer:		Timer for tx and rx
+ * @stop_tx_timer:	Timer for stop tx
  */
 struct cdns_uart {
 	struct uart_port	*port;
@@ -203,10 +209,22 @@ struct cdns_uart {
 	struct notifier_block	clk_rate_change_nb;
 	u32			quirks;
 	bool cts_override;
+	struct gpio_desc	*gpiod_rts;
+	bool			rs485_tx_started;
+	struct timer_list	timer;
+	struct timer_list	stop_tx_timer;
 };
 struct cdns_platform_data {
 	u32 quirks;
 };
+
+struct serial_rs485 cdns_rs485_supported = {
+	.flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND |
+		 SER_RS485_RTS_AFTER_SEND,
+	.delay_rts_before_send = 1,
+	.delay_rts_after_send = 1,
+};
+
 #define to_cdns_uart(_nb) container_of(_nb, struct cdns_uart, \
 		clk_rate_change_nb)
 
@@ -305,6 +323,55 @@ static void cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus)
 	tty_flip_buffer_push(&port->state->port);
 }
 
+/**
+ * cdns_rts_gpio_enable - Configure RTS/GPIO to high/low
+ * @cdns_uart: Handle to the cdns_uart
+ * @enable: Value to be set to RTS/GPIO
+ */
+static void cdns_rts_gpio_enable(struct cdns_uart *cdns_uart, bool enable)
+{
+	u32 val;
+
+	if (cdns_uart->gpiod_rts) {
+		gpiod_set_value(cdns_uart->gpiod_rts, enable);
+	} else {
+		val = readl(cdns_uart->port->membase + CDNS_UART_MODEMCR);
+		if (enable)
+			val &= ~CDNS_UART_MODEMCR_RTS;
+		else
+			val |= CDNS_UART_MODEMCR_RTS;
+		writel(val, cdns_uart->port->membase + CDNS_UART_MODEMCR);
+	}
+}
+
+/**
+ * cdns_rs485_tx_setup - Tx setup specific to rs485
+ * @cdns_uart: Handle to the cdns_uart
+ */
+static void cdns_rs485_tx_setup(struct cdns_uart *cdns_uart)
+{
+	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_ON_SEND)
+		cdns_rts_gpio_enable(cdns_uart, 1);
+	else
+		cdns_rts_gpio_enable(cdns_uart, 0);
+
+	cdns_uart->rs485_tx_started = true;
+}
+
+/**
+ * cdns_rs485_rx_setup - Rx setup specific to rs485
+ * @cdns_uart: Handle to the cdns_uart
+ */
+static void cdns_rs485_rx_setup(struct cdns_uart *cdns_uart)
+{
+	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_AFTER_SEND)
+		cdns_rts_gpio_enable(cdns_uart, 1);
+	else
+		cdns_rts_gpio_enable(cdns_uart, 0);
+
+	cdns_uart->rs485_tx_started = false;
+}
+
 /**
  * cdns_uart_tx_empty -  Check whether TX is empty
  * @port: Handle to the uart port structure
@@ -579,6 +646,44 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
 }
 #endif
 
+/**
+ * cdns_rs485_rx_callback - Timer rx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_rx_callback(struct timer_list *t)
+{
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
+
+	/*
+	 * Default Rx should be setup, because Rx signaling path
+	 * need to enable to receive data.
+	 */
+	cdns_rs485_rx_setup(cdns_uart);
+}
+
+/**
+ * cdns_rs485_tx_callback - Timer tx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_tx_callback(struct timer_list *t)
+{
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
+
+	uart_port_lock(cdns_uart->port);
+	cdns_uart_handle_tx(cdns_uart->port);
+
+	/* Enable the TX Empty interrupt */
+	writel(CDNS_UART_IXR_TXEMPTY, cdns_uart->port->membase + CDNS_UART_IER);
+	uart_port_unlock(cdns_uart->port);
+
+	if (uart_circ_empty(&cdns_uart->port->state->xmit) ||
+	    uart_tx_stopped(cdns_uart->port)) {
+		timer_setup(&cdns_uart->timer, cdns_rs485_rx_callback, 0);
+		mod_timer(&cdns_uart->timer, jiffies +
+			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
+	}
+}
+
 /**
  * cdns_uart_start_tx -  Start transmitting bytes
  * @port: Handle to the uart port structure
@@ -586,6 +691,7 @@ static int cdns_uart_clk_notifier_cb(struct notifier_block *nb,
 static void cdns_uart_start_tx(struct uart_port *port)
 {
 	unsigned int status;
+	struct cdns_uart *cdns_uart = port->private_data;
 
 	if (uart_tx_stopped(port))
 		return;
@@ -604,10 +710,40 @@ static void cdns_uart_start_tx(struct uart_port *port)
 
 	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_ISR);
 
-	cdns_uart_handle_tx(port);
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		if (!cdns_uart->rs485_tx_started) {
+			timer_setup(&cdns_uart->timer,
+				    cdns_rs485_tx_callback, 0);
+			cdns_rs485_tx_setup(cdns_uart);
+			mod_timer(&cdns_uart->timer, jiffies +
+				  msecs_to_jiffies(port->rs485.delay_rts_before_send));
+		} else {
+			if (!timer_pending(&cdns_uart->timer))
+				mod_timer(&cdns_uart->timer, jiffies);
+		}
+	} else {
+		cdns_uart_handle_tx(port);
 
-	/* Enable the TX Empty interrupt */
-	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
+		/* Enable the TX Empty interrupt */
+		writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
+	}
+}
+
+/**
+ * cdns_rs485_stop_tx_callback - Timer stop tx callback handler for rs485.
+ * @t: Handle to the timer list structure
+ */
+static void cdns_rs485_stop_tx_callback(struct timer_list *t)
+{
+	unsigned int regval;
+	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, stop_tx_timer);
+
+	cdns_rs485_rx_setup(cdns_uart);
+
+	regval = readl(cdns_uart->port->membase + CDNS_UART_CR);
+	regval |= CDNS_UART_CR_TX_DIS;
+	/* Disable the transmitter */
+	writel(regval, cdns_uart->port->membase + CDNS_UART_CR);
 }
 
 /**
@@ -617,11 +753,19 @@ static void cdns_uart_start_tx(struct uart_port *port)
 static void cdns_uart_stop_tx(struct uart_port *port)
 {
 	unsigned int regval;
+	struct cdns_uart *cdns_uart = port->private_data;
 
-	regval = readl(port->membase + CDNS_UART_CR);
-	regval |= CDNS_UART_CR_TX_DIS;
-	/* Disable the transmitter */
-	writel(regval, port->membase + CDNS_UART_CR);
+	if ((cdns_uart->port->rs485.flags & SER_RS485_ENABLED) &&
+	    !timer_pending(&cdns_uart->stop_tx_timer) &&
+	    cdns_uart->rs485_tx_started) {
+		mod_timer(&cdns_uart->stop_tx_timer, jiffies +
+			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
+	} else {
+		regval = readl(port->membase + CDNS_UART_CR);
+		regval |= CDNS_UART_CR_TX_DIS;
+		/* Disable the transmitter */
+		writel(regval, port->membase + CDNS_UART_CR);
+	}
 }
 
 /**
@@ -829,6 +973,12 @@ static int cdns_uart_startup(struct uart_port *port)
 		(CDNS_UART_CR_TXRST | CDNS_UART_CR_RXRST))
 		cpu_relax();
 
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		timer_setup(&cdns_uart->stop_tx_timer,
+			    cdns_rs485_stop_tx_callback, 0);
+		cdns_rs485_rx_setup(cdns_uart);
+	}
+
 	/*
 	 * Clear the RX disable bit and then set the RX enable bit to enable
 	 * the receiver.
@@ -888,6 +1038,7 @@ static void cdns_uart_shutdown(struct uart_port *port)
 {
 	int status;
 	unsigned long flags;
+	struct cdns_uart *cdns_uart = port->private_data;
 
 	uart_port_lock_irqsave(port, &flags);
 
@@ -903,6 +1054,11 @@ static void cdns_uart_shutdown(struct uart_port *port)
 	uart_port_unlock_irqrestore(port, flags);
 
 	free_irq(port->irq, port);
+
+	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
+		del_timer_sync(&cdns_uart->timer);
+		del_timer_sync(&cdns_uart->stop_tx_timer);
+	}
 }
 
 /**
@@ -1032,7 +1188,7 @@ static void cdns_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
 	mode_reg &= ~CDNS_UART_MR_CHMODE_MASK;
 
 	if (mctrl & TIOCM_RTS)
-		val |= CDNS_UART_MODEMCR_RTS;
+		cdns_rts_gpio_enable(cdns_uart_data, 1);
 	if (mctrl & TIOCM_DTR)
 		val |= CDNS_UART_MODEMCR_DTR;
 	if (mctrl & TIOCM_LOOP)
@@ -1455,6 +1611,37 @@ MODULE_DEVICE_TABLE(of, cdns_uart_of_match);
 /* Temporary variable for storing number of instances */
 static int instances;
 
+/**
+ * cdns_rs485_config - Called when an application calls TIOCSRS485 ioctl.
+ * @port: Pointer to the uart_port structure
+ * @termios: Pointer to the ktermios structure
+ * @rs485: Pointer to the serial_rs485 structure
+ *
+ * Return: 0
+ */
+static int cdns_rs485_config(struct uart_port *port, struct ktermios *termios,
+			     struct serial_rs485 *rs485)
+{
+	u32 val;
+	unsigned int ctrl_reg;
+
+	if (rs485->flags & SER_RS485_ENABLED) {
+		dev_dbg(port->dev, "Setting UART to RS485\n");
+		/* Make sure auto RTS is disabled */
+		val = readl(port->membase + CDNS_UART_MODEMCR);
+		val &= ~CDNS_UART_MODEMCR_FCM;
+		writel(val, port->membase + CDNS_UART_MODEMCR);
+		/* Disable transmitter and make Rx setup*/
+		cdns_uart_stop_tx(port);
+	} else {
+		/* Disable the TX and RX */
+		ctrl_reg = readl(port->membase + CDNS_UART_CR);
+		ctrl_reg |= CDNS_UART_CR_TX_DIS | CDNS_UART_CR_RX_DIS;
+		writel(ctrl_reg, port->membase + CDNS_UART_CR);
+	}
+	return 0;
+}
+
 /**
  * cdns_uart_probe - Platform driver probe
  * @pdev: Pointer to the platform device structure
@@ -1597,9 +1784,23 @@ static int cdns_uart_probe(struct platform_device *pdev)
 	port->private_data = cdns_uart_data;
 	port->read_status_mask = CDNS_UART_IXR_TXEMPTY | CDNS_UART_IXR_RXTRIG |
 			CDNS_UART_IXR_OVERRUN | CDNS_UART_IXR_TOUT;
+	port->rs485_config = cdns_rs485_config;
+	port->rs485_supported = cdns_rs485_supported;
 	cdns_uart_data->port = port;
 	platform_set_drvdata(pdev, port);
 
+	rc = uart_get_rs485_mode(port);
+	if (rc)
+		goto err_out_clk_notifier;
+
+	cdns_uart_data->gpiod_rts = devm_gpiod_get_optional(&pdev->dev, "rts",
+							    GPIOD_OUT_LOW);
+	if (IS_ERR(cdns_uart_data->gpiod_rts)) {
+		rc = PTR_ERR(cdns_uart_data->gpiod_rts);
+		dev_err(port->dev, "xuartps: devm_gpiod_get_optional failed\n");
+		goto err_out_clk_notifier;
+	}
+
 	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_set_autosuspend_delay(&pdev->dev, UART_AUTOSUSPEND_TIMEOUT);
 	pm_runtime_set_active(&pdev->dev);
@@ -1618,6 +1819,8 @@ static int cdns_uart_probe(struct platform_device *pdev)
 		console_port = port;
 	}
 #endif
+	if (cdns_uart_data->port->rs485.flags & SER_RS485_ENABLED)
+		cdns_rs485_rx_setup(cdns_uart_data);
 
 	rc = uart_add_one_port(&cdns_uart_uart_driver, port);
 	if (rc) {
@@ -1646,6 +1849,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
+err_out_clk_notifier:
 #ifdef CONFIG_COMMON_CLK
 	clk_notifier_unregister(cdns_uart_data->uartclk,
 			&cdns_uart_data->clk_rate_change_nb);
-- 
2.25.1



From krzysztof.kozlowski at linaro.org  Mon Dec 18 01:45:48 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 10:45:48 +0100
Subject: [GIT PULL] pinctrl: samsung: drivers for v6.8
Message-ID: <20231218094548.37105-1-krzysztof.kozlowski@linaro.org>

Hi Linus,

Google and Samsung SoC pinctrl changes for v6.8.

Best regards,
Krzysztof


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git tags/samsung-pinctrl-6.8

for you to fetch changes up to 6cf96df77338c6a7e753229fe6d330ab60e28cda:

  pinctrl: samsung: add exynosautov920 pinctrl (2023-12-13 08:49:33 +0100)

----------------------------------------------------------------
Samsung pinctrl drivers changes for v6.8

1. New hardware: Add pin controllers for Samsung ExynosAutov920 and
   Google Tensor GS101.

2. Few DT bindings cleanups: add specific compatibles for each device
   using generic compatible as fallback.  This affects only DTS, no
   driver changes are needed.

3. Allow setting affinity on non wake-up external GPIO interrupts.

----------------------------------------------------------------
Jaewon Kim (3):
      dt-bindings: pinctrl: samsung: add exynosautov920
      pinctrl: samsung: support ExynosAuto GPIO structure
      pinctrl: samsung: add exynosautov920 pinctrl

Krzysztof Kozlowski (3):
      dt-bindings: pinctrl: samsung: add specific compatibles for existing SoC
      dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers
      dt-bindings: pinctrl: samsung: correct ExynosAutov920 wake-up compatibles

Peter Griffin (3):
      dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
      dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
      pinctrl: samsung: Add gs101 SoC pinctrl configuration

Petr Vorel (1):
      MAINTAINERS: Remove snawrocki's git tree

Youngmin Nam (1):
      pinctrl: samsung: add irq_set_affinity() for non wake up external gpio interrupt

 .../pinctrl/samsung,pinctrl-wakeup-interrupt.yaml  |  45 ++--
 .../bindings/pinctrl/samsung,pinctrl.yaml          |   5 +-
 MAINTAINERS                                        |   1 -
 drivers/pinctrl/samsung/pinctrl-exynos-arm64.c     | 280 +++++++++++++++++++++
 drivers/pinctrl/samsung/pinctrl-exynos.c           | 109 +++++++-
 drivers/pinctrl/samsung/pinctrl-exynos.h           |  25 ++
 drivers/pinctrl/samsung/pinctrl-samsung.c          |   7 +
 drivers/pinctrl/samsung/pinctrl-samsung.h          |  14 ++
 8 files changed, 460 insertions(+), 26 deletions(-)


From sunnanyong at huawei.com  Mon Dec 18 01:53:53 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Mon, 18 Dec 2023 17:53:53 +0800
Subject: [PATCH 1/3] mm: HVO: introduce helper function to update and
 flush pgtable
In-Reply-To: <0100b6c8-24db-fbcf-d45e-763cfccfa0c5@linux.dev>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
 <20231214073912.1938330-2-sunnanyong@huawei.com>
 <0100b6c8-24db-fbcf-d45e-763cfccfa0c5@linux.dev>
Message-ID: <1bc0d2d8-567e-9fc1-39a5-ed498ad1d2d2@huawei.com>


On 2023/12/15 11:36, Muchun Song wrote:
>
>
> On 2023/12/14 15:39, Nanyong Sun wrote:
>> Add pmd/pte update and tlb flush helper function to update page
>> table. This refactoring patch is designed to facilitate each
>> architecture to implement its own special logic in preparation
>> for the arm64 architecture to follow the necessary break-before-make
>> sequence when updating page tables.
>>
>> Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
>> ---
>> ? mm/hugetlb_vmemmap.c | 55 ++++++++++++++++++++++++++++++++++----------
>> ? 1 file changed, 43 insertions(+), 12 deletions(-)
>>
>> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
>> index 87818ee7f01d..49e8b351def3 100644
>> --- a/mm/hugetlb_vmemmap.c
>> +++ b/mm/hugetlb_vmemmap.c
>> @@ -45,6 +45,37 @@ struct vmemmap_remap_walk {
>> ????? unsigned long??????? flags;
>> ? };
>> ? +#ifndef vmemmap_update_pmd
>> +static inline void vmemmap_update_pmd(unsigned long start,
>> +????????????????????? pmd_t *pmd, pte_t *pgtable)
>> +{
>> +??? pmd_populate_kernel(&init_mm, pmd, pgtable);
>> +}
>> +#endif
>> +
>> +#ifndef vmemmap_update_pte
>> +static inline void vmemmap_update_pte(unsigned long addr,
>> +????????????????????? pte_t *pte, pte_t entry)
>> +{
>> +??? set_pte_at(&init_mm, addr, pte, entry);
>> +}
>> +#endif
>> +
>> +#ifndef flush_tlb_vmemmap_all
>> +static inline void flush_tlb_vmemmap_all(void)
>> +{
>> +??? flush_tlb_all();
>> +}
>> +#endif
>> +
>> +#ifndef flush_tlb_vmemmap_range
>> +static inline void flush_tlb_vmemmap_range(unsigned long start,
>> +?????????????????????? unsigned long end)
>> +{
>> +??? flush_tlb_kernel_range(start, end);
>> +}
>> +#endif
>
> I'd like to rename both tlb-flush helpers to vmemmap_flush_tlb_all/range
> since other helpers all are prefixed with "vmemmap". It'll be more
> consistent for me.
>
> Otherwise LGTM. Thanks.
>
> Reviewed-by: Muchun Song <songmuchun at bytedance.com>

Hi Muchun?

Thank you for your review on this patch set, I'll fix them and send out 
the v2 version later.

>
>> +
>> ? static int split_vmemmap_huge_pmd(pmd_t *pmd, unsigned long start, 
>> bool flush)
>> ? {
>> ????? pmd_t __pmd;
>> @@ -87,9 +118,9 @@ static int split_vmemmap_huge_pmd(pmd_t *pmd, 
>> unsigned long start, bool flush)
>> ? ????????? /* Make pte visible before pmd. See comment in 
>> pmd_install(). */
>> ????????? smp_wmb();
>> -??????? pmd_populate_kernel(&init_mm, pmd, pgtable);
>> +??????? vmemmap_update_pmd(start, pmd, pgtable);
>> ????????? if (flush)
>> -??????????? flush_tlb_kernel_range(start, start + PMD_SIZE);
>> +??????????? flush_tlb_vmemmap_range(start, start + PMD_SIZE);
>> ????? } else {
>> ????????? pte_free_kernel(&init_mm, pgtable);
>> ????? }
>> @@ -217,7 +248,7 @@ static int vmemmap_remap_range(unsigned long 
>> start, unsigned long end,
>> ????? } while (pgd++, addr = next, addr != end);
>> ? ????? if (walk->remap_pte && !(walk->flags & 
>> VMEMMAP_REMAP_NO_TLB_FLUSH))
>> -??????? flush_tlb_kernel_range(start, end);
>> +??????? flush_tlb_vmemmap_range(start, end);
>> ? ????? return 0;
>> ? }
>> @@ -263,15 +294,15 @@ static void vmemmap_remap_pte(pte_t *pte, 
>> unsigned long addr,
>> ? ????????? /*
>> ?????????? * Makes sure that preceding stores to the page contents from
>> -???????? * vmemmap_remap_free() become visible before the set_pte_at()
>> -???????? * write.
>> +???????? * vmemmap_remap_free() become visible before the
>> +???????? * vmemmap_update_pte() write.
>> ?????????? */
>> ????????? smp_wmb();
>> ????? }
>> ? ????? entry = mk_pte(walk->reuse_page, pgprot);
>> ????? list_add(&page->lru, walk->vmemmap_pages);
>> -??? set_pte_at(&init_mm, addr, pte, entry);
>> +??? vmemmap_update_pte(addr, pte, entry);
>> ? }
>> ? ? /*
>> @@ -310,10 +341,10 @@ static void vmemmap_restore_pte(pte_t *pte, 
>> unsigned long addr,
>> ? ????? /*
>> ?????? * Makes sure that preceding stores to the page contents become 
>> visible
>> -???? * before the set_pte_at() write.
>> +???? * before the vmemmap_update_pte() write.
>> ?????? */
>> ????? smp_wmb();
>> -??? set_pte_at(&init_mm, addr, pte, mk_pte(page, pgprot));
>> +??? vmemmap_update_pte(addr, pte, mk_pte(page, pgprot));
>> ? }
>> ? ? /**
>> @@ -576,7 +607,7 @@ long hugetlb_vmemmap_restore_folios(const struct 
>> hstate *h,
>> ????? }
>> ? ????? if (restored)
>> -??????? flush_tlb_all();
>> +??????? flush_tlb_vmemmap_all();
>> ????? if (!ret)
>> ????????? ret = restored;
>> ????? return ret;
>> @@ -744,7 +775,7 @@ void hugetlb_vmemmap_optimize_folios(struct 
>> hstate *h, struct list_head *folio_l
>> ????????????? break;
>> ????? }
>> ? -??? flush_tlb_all();
>> +??? flush_tlb_vmemmap_all();
>> ? ????? list_for_each_entry(folio, folio_list, lru) {
>> ????????? int ret = __hugetlb_vmemmap_optimize_folio(h, folio,
>> @@ -760,7 +791,7 @@ void hugetlb_vmemmap_optimize_folios(struct 
>> hstate *h, struct list_head *folio_l
>> ?????????? * allowing more vmemmap remaps to occur.
>> ?????????? */
>> ????????? if (ret == -ENOMEM && !list_empty(&vmemmap_pages)) {
>> -??????????? flush_tlb_all();
>> +??????????? flush_tlb_vmemmap_all();
>> ????????????? free_vmemmap_page_list(&vmemmap_pages);
>> ????????????? INIT_LIST_HEAD(&vmemmap_pages);
>> ????????????? __hugetlb_vmemmap_optimize_folio(h, folio,
>> @@ -769,7 +800,7 @@ void hugetlb_vmemmap_optimize_folios(struct 
>> hstate *h, struct list_head *folio_l
>> ????????? }
>> ????? }
>> ? -??? flush_tlb_all();
>> +??? flush_tlb_vmemmap_all();
>> ????? free_vmemmap_page_list(&vmemmap_pages);
>> ? }
>
> .


From sunnanyong at huawei.com  Mon Dec 18 01:54:42 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Mon, 18 Dec 2023 17:54:42 +0800
Subject: [PATCH 1/3] mm: HVO: introduce helper function to update and
 flush pgtable
In-Reply-To: <f7950e7c-12b8-44b4-bfa9-fb2cb16944c0@huawei.com>
References: <20231214073912.1938330-1-sunnanyong@huawei.com>
 <20231214073912.1938330-2-sunnanyong@huawei.com>
 <f7950e7c-12b8-44b4-bfa9-fb2cb16944c0@huawei.com>
Message-ID: <7a86f31d-475a-133e-fb79-3a1d6147372a@huawei.com>


On 2023/12/15 14:16, Kefeng Wang wrote:
>
>
> On 2023/12/14 15:39, Nanyong Sun wrote:
>> Add pmd/pte update and tlb flush helper function to update page
>> table. This refactoring patch is designed to facilitate each
>> architecture to implement its own special logic in preparation
>> for the arm64 architecture to follow the necessary break-before-make
>> sequence when updating page tables.
>>
>> Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
>> ---
>> ? mm/hugetlb_vmemmap.c | 55 ++++++++++++++++++++++++++++++++++----------
>> ? 1 file changed, 43 insertions(+), 12 deletions(-)
>>
>> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
>> index 87818ee7f01d..49e8b351def3 100644
>> --- a/mm/hugetlb_vmemmap.c
>> +++ b/mm/hugetlb_vmemmap.c
>> @@ -45,6 +45,37 @@ struct vmemmap_remap_walk {
>> ????? unsigned long??????? flags;
>> ? };
>> ? +#ifndef vmemmap_update_pmd
>> +static inline void vmemmap_update_pmd(unsigned long start,
>> +????????????????????? pmd_t *pmd, pte_t *pgtable)
>
> pgtable ->? ptep
Hi Kefeng?

Thank you for your review on this patch set, I'll fix them and send out 
the v2 version later.

>
>> +{
>> +??? pmd_populate_kernel(&init_mm, pmd, pgtable);
>> +}
>> +#endif
>> +
>> +#ifndef vmemmap_update_pte
>> +static inline void vmemmap_update_pte(unsigned long addr,
>> +????????????????????? pte_t *pte, pte_t entry)
>
> pte?? -> ptep
> entry -> pte
>
>> +{
>> +??? set_pte_at(&init_mm, addr, pte, entry);
>> +}
>> +#endif
>
> .


From andrew at lunn.ch  Mon Dec 18 01:55:06 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 18 Dec 2023 10:55:06 +0100
Subject: [PATCH net-next v4 09/13] net: ethtool: plca: Target the command
 to the requested PHY
In-Reply-To: <20231215171237.1152563-10-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-10-maxime.chevallier@bootlin.com>
Message-ID: <5d32abef-3035-4301-9f09-744864baec16@lunn.ch>

On Fri, Dec 15, 2023 at 06:12:31PM +0100, Maxime Chevallier wrote:
> PLCA is a PHY-specific command. Instead of targeting the command
> towards dev->phydev, use the request to pick the targeted PHY.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From tabba at google.com  Mon Dec 18 01:56:32 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 18 Dec 2023 09:56:32 +0000
Subject: [PATCH v3 14/17] KVM: arm64: Macros for setting/clearing FGT bits
In-Reply-To: <86wmtbalx9.wl-maz@kernel.org>
References: <20231214100158.2305400-1-tabba@google.com> <20231214100158.2305400-15-tabba@google.com>
 <86wmtbalx9.wl-maz@kernel.org>
Message-ID: <CA+EHjTxZmc2bAaDbFLjWxx-LzCX7Jwy+EH60JgFBvWYh68U=xg@mail.gmail.com>

Hi Marc,

On Mon, Dec 18, 2023 at 9:40?AM Marc Zyngier <maz at kernel.org> wrote:
>
> On Thu, 14 Dec 2023 10:01:54 +0000,
> Fuad Tabba <tabba at google.com> wrote:
> >
> > There's a lot of boilerplate code for setting and clearing FGT
> > bits when activating guest traps. Refactor it into macros. These
> > macros will also be used in future patch series.
> >
> > No functional change intended.
> >
> > Signed-off-by: Fuad Tabba <tabba at google.com>
> > ---
> >  arch/arm64/kvm/hyp/include/hyp/switch.h | 60 +++++++++----------------
> >  1 file changed, 21 insertions(+), 39 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > index 17ce40f5b006..e223fc0d5193 100644
> > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > @@ -79,6 +79,23 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
> >               clr |= ~hfg & __ ## reg ## _nMASK;                      \
> >       } while(0)
> >
> > +#define update_fgt_traps_cs(reg, clr, set)                           \
> > +     do {                                                            \
> > +             struct kvm_cpu_context *hctxt =                         \
> > +                     &this_cpu_ptr(&kvm_host_data)->host_ctxt;       \
> > +             u64 val, c = 0, s = 0;                                  \
> > +                                                                     \
> > +             ctxt_sys_reg(hctxt, reg) = read_sysreg_s(SYS_ ## reg);  \
> > +             compute_clr_set(vcpu, reg, c, s);                       \
>
> You are referring to a variable name that is in the scope of the macro
> user, and not the macro itself. It is so fragile it isn't funny.
>
> Why don't you simply pass the vcpu as a parameter to the function?
>
> Another thing is that this read/write can be expensive. How about not
> doing anything when there is no change to the value of the sysreg?

What do you think of this (spacing will be fixed):

#define update_fgt_traps_cs(vcpu, reg, clr, set)                         \
    do {
                           \
        struct kvm_cpu_context *hctxt =
         \
            &this_cpu_ptr(&kvm_host_data)->host_ctxt;                  \
        u64 val, c = 0, s = 0;
                  \

                             \
        ctxt_sys_reg(hctxt, reg) = read_sysreg_s(SYS_ ## reg);   \
        compute_clr_set(vcpu, reg, c, s);
          \
        val = __ ## reg ## _nMASK;
          \
        val |= (s | set);
                        \
        val &= ~(c | clr);
                       \
        if (ctxt_sys_reg(hctxt, reg) != val)
              \
            write_sysreg_s(val, SYS_ ## reg);
           \
    } while(0)

If it looks good to you, I'll fix it on the respin.

Thanks,
/fuad

>
> I'll see if I can come up with something.
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.


From andrew at lunn.ch  Mon Dec 18 01:58:30 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 18 Dec 2023 10:58:30 +0100
Subject: [PATCH net-next v4 10/13] net: ethtool: pse-pd: Target the
 command to the requested PHY
In-Reply-To: <20231215171237.1152563-11-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-11-maxime.chevallier@bootlin.com>
Message-ID: <5f3a74fe-11e4-4c6e-a77d-f9c4f6fab156@lunn.ch>

On Fri, Dec 15, 2023 at 06:12:32PM +0100, Maxime Chevallier wrote:
> PSE and PD configuration is a PHY-specific command. Instead of targeting
> the command towards dev->phydev, use the request to pick the targeted
> PHY device.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
> ---
> V4: No changes
> V3: No changes
> V2: New patch
> 
>  net/ethtool/pse-pd.c | 14 +++-----------
>  1 file changed, 3 insertions(+), 11 deletions(-)
> 
> diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
> index cc478af77111..0d9cd9c87104 100644
> --- a/net/ethtool/pse-pd.c
> +++ b/net/ethtool/pse-pd.c
> @@ -31,17 +31,10 @@ const struct nla_policy ethnl_pse_get_policy[ETHTOOL_A_PSE_HEADER + 1] = {
>  	[ETHTOOL_A_PSE_HEADER] = NLA_POLICY_NESTED(ethnl_header_policy),
>  };
>  
> -static int pse_get_pse_attributes(struct net_device *dev,
> +static int pse_get_pse_attributes(struct phy_device *phydev,
>  				  struct netlink_ext_ack *extack,
>  				  struct pse_reply_data *data)
>  {
> -	struct phy_device *phydev = dev->phydev;
> -
> -	if (!phydev) {
> -		NL_SET_ERR_MSG(extack, "No PHY is attached");
> -		return -EOPNOTSUPP;
> -	}
> -

It would be good to say in the commit message why it is safe to remove
this.

> @@ -132,7 +124,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
>  	/* this values are already validated by the ethnl_pse_set_policy */
>  	config.admin_cotrol = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);
>  
> -	phydev = dev->phydev;
> +	phydev = req_info->phydev;
>  	if (!phydev) {
>  		NL_SET_ERR_MSG(info->extack, "No PHY is attached");
>  		return -EOPNOTSUPP;

So you removed one test, but this one stays?

   Andrew


From andrew at lunn.ch  Mon Dec 18 01:58:52 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 18 Dec 2023 10:58:52 +0100
Subject: [PATCH net-next v4 11/13] net: ethtool: cable-test: Target the
 command to the requested PHY
In-Reply-To: <20231215171237.1152563-12-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-12-maxime.chevallier@bootlin.com>
Message-ID: <c2aeb5a1-aaa8-4f11-bb0a-cccc3baffbf6@lunn.ch>

On Fri, Dec 15, 2023 at 06:12:33PM +0100, Maxime Chevallier wrote:
> Cable testing is a PHY-specific command. Instead of targeting the command
> towards dev->phydev, use the request to pick the targeted PHY.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From andrew at lunn.ch  Mon Dec 18 02:00:08 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 18 Dec 2023 11:00:08 +0100
Subject: [PATCH net-next v4 12/13] net: ethtool: strset: Allow querying
 phy stats by index
In-Reply-To: <20231215171237.1152563-13-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-13-maxime.chevallier@bootlin.com>
Message-ID: <ae1304c4-3e6a-4de8-9a5f-b93ba8640d55@lunn.ch>

On Fri, Dec 15, 2023 at 06:12:34PM +0100, Maxime Chevallier wrote:
> The ETH_SS_PHY_STATS command gets PHY statistics. Use the phydev pointer
> from the ethnl request to allow query phy stats from each PHY on the
> link.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From mripard at kernel.org  Mon Dec 18 02:06:40 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 11:06:40 +0100
Subject: [PATCH v2 19/27] drm/rockchip: inno_hdmi: Move tmds rate to
 connector state subclass
In-Reply-To: <20231216162639.125215-20-knaerzche@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-20-knaerzche@gmail.com>
Message-ID: <xte5vjc3o77wnlozz6sy5yysiezdxbzvbwdblhbqb5s2nwnnv5@xxknftdeo6uk>

Hi,

On Sat, Dec 16, 2023 at 05:26:30PM +0100, Alex Bee wrote:
> Similar to the othter members of inno_hdmi_connector_state the tmds_rate is
> not a property of the device, but of the connector state. Move it to
> inno_hdmi_connector_state and make it a long to comply with the clock
> framework. To get arround the issue of not having the connector state when
> inno_hdmi_i2c_init is called in the bind path, getting the tmds rate is
> wrapped in function which returns the fallback rate if the connector
> doesn't have a state yet.
> 
> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> ---
> changes in v2:
>  - new patch
> 
>  drivers/gpu/drm/rockchip/inno_hdmi.c | 36 +++++++++++++++++++---------
>  1 file changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index f9bfae1e97a2..6799d24501b8 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -47,14 +47,13 @@ struct inno_hdmi {
>  
>  	struct inno_hdmi_i2c *i2c;
>  	struct i2c_adapter *ddc;
> -
> -	unsigned int tmds_rate;
>  };
>  
>  struct inno_hdmi_connector_state {
>  	struct drm_connector_state	base;
>  	unsigned int			enc_out_format;
>  	unsigned int			colorimetry;
> +	unsigned long			tmds_rate;
>  };
>  
>  static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
> @@ -133,11 +132,33 @@ static inline void hdmi_modb(struct inno_hdmi *hdmi, u16 offset,
>  	hdmi_writeb(hdmi, offset, temp);
>  }
>  
> +static unsigned long inno_hdmi_tmds_rate(struct inno_hdmi *hdmi)
> +{
> +	struct drm_connector *connector = &hdmi->connector;
> +	struct drm_connector_state *conn_state =  connector->state;
> +	struct inno_hdmi_connector_state *inno_conn_state;
> +
> +	if (conn_state) {
> +		inno_conn_state = to_inno_hdmi_conn_state(conn_state);
> +		return inno_conn_state->tmds_rate;
> +	}
> +
> +	/*
> +	 * When IP controller haven't configured to an accurate video
> +	 * timing, then the TMDS clock source would be switched to
> +	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
> +	 * and reconfigure the DDC clock.
> +	 */
> +
> +	return clk_get_rate(hdmi->pclk);
> +}
> +
>  static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
>  {
>  	int ddc_bus_freq;
> +	unsigned long tmds_rate = inno_hdmi_tmds_rate(hdmi);
>  
> -	ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE;
> +	ddc_bus_freq = (tmds_rate >> 2) / HDMI_SCL_RATE;
>  
>  	hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
>  	hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
> @@ -431,7 +452,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>  	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
>  	 * clock rate, and reconfigure the DDC clock.
>  	 */
> -	hdmi->tmds_rate = mode->clock * 1000;
> +	inno_conn_state->tmds_rate = mode->clock * 1000;
>  	inno_hdmi_i2c_init(hdmi);
>  
>  	/* Unmute video and audio output */
> @@ -823,13 +844,6 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
>  		goto err_disable_clk;
>  	}
>  
> -	/*
> -	 * When IP controller haven't configured to an accurate video
> -	 * timing, then the TMDS clock source would be switched to
> -	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
> -	 * and reconfigure the DDC clock.
> -	 */
> -	hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
>  	inno_hdmi_i2c_init(hdmi);

I still think my patch is better there.

There's two places that use the inno_hdmi.tmds_rate field: the two
callers of inno_hdmi_i2c_init(). One is at bind time and needs to
initialise it with a sane default since we don't have a mode set yet,
the other is to update the internal clock rate while we have a mode set.

Since there's a single "modeset" user, there's no need to store it in
the state structure at all: it can be a local variable.

And in the bind function, you're not going to use the state structure
either since there's no state, and it's just a default that has no
relation to the modeset code at all.

Your function on the other end tries to reconcile and handle the two.
But there's no reason to, it just makes the code harder to follow. Just
pass the parent rate you want to init with as an argument and it's easy
to read and maintain.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/8aff4f91/attachment.sig>

From neil.armstrong at linaro.org  Mon Dec 18 02:09:55 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 18 Dec 2023 11:09:55 +0100
Subject: [PATCH] arm64: defconfig: enable GPU clock controller for
 SM8[45]50
In-Reply-To: <5kkk7j6425wshf2bmmhrh26jwc3rstcrm6kgxyyzowq2qqrfw2@u2mgm6qefxvk>
References: <20231204-topic-sm8x50-upstream-gpucc-defconfig-v1-1-e615df0c4af9@linaro.org>
 <5kkk7j6425wshf2bmmhrh26jwc3rstcrm6kgxyyzowq2qqrfw2@u2mgm6qefxvk>
Message-ID: <34b07b10-a70c-4599-8ae2-304e386fe9b2@linaro.org>

On 16/12/2023 06:11, Bjorn Andersson wrote:
> On Mon, Dec 04, 2023 at 02:01:47PM +0100, Neil Armstrong wrote:
>> Enable GPU Clock Controller for SM8450 and SM8550 to allow using
>> Adreno GPU on these SoCs.
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
>> ---
>>   arch/arm64/configs/defconfig | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index 5ad2b841aafc..56aebbdcdd40 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -1266,6 +1266,8 @@ CONFIG_SM_TCSRCC_8550=y
>>   CONFIG_SM_GPUCC_6115=m
>>   CONFIG_SM_GPUCC_8150=y
>>   CONFIG_SM_GPUCC_8250=y
>> +CONFIG_SM_GPUCC_8450=y
>> +CONFIG_SM_GPUCC_8550=y
> 
> I don't think these needs to be builtin, and if they do I'd like to see
> the reason captured in the commit message.

I don't have any good reasons... I'll resend with modules
since in my tests it worked fine as modules.

Neil

> 
> Regards,
> Bjorn
> 
>>   CONFIG_SM_VIDEOCC_8250=y
>>   CONFIG_QCOM_HFPLL=y
>>   CONFIG_CLK_GFM_LPASS_SM8250=m
>>
>> ---
>> base-commit: 9046d05c6ad632a271fc4173624e26f396975a80
>> change-id: 20231204-topic-sm8x50-upstream-gpucc-defconfig-3e3dc264be08
>>
>> Best regards,
>> -- 
>> Neil Armstrong <neil.armstrong at linaro.org>
>>



From andrew at lunn.ch  Mon Dec 18 02:10:29 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 18 Dec 2023 11:10:29 +0100
Subject: [PATCH net-next v4 13/13] Documentation: networking: document
 phy_link_topology
In-Reply-To: <20231215171237.1152563-14-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-14-maxime.chevallier@bootlin.com>
Message-ID: <32461e61-b518-4ecc-bf51-7d22f8580212@lunn.ch>

> +An Ethernet Interface from userspace's poing of view is nothing but a

point

> +:c:type:`struct net_device <net_device>`, which exposes configuration options
> +trough the legacy ioctls and the ethool netlink commands. The base assumption

through 

> +when designing these configuration channels were that the link looked
> +something like this ::
> +
> +  +-----------------------+        +----------+      +--------------+
> +  | Ethernet Controller / |        | Ethernet |      | Connector /  |
> +  |       MAC             | ------ |   PHY    | ---- |    Port      | ---... to LP
> +  +-----------------------+        +----------+      +--------------+
> +  struct net_device               struct phy_device
> +
> +Commands that needs to configure the PHY will go through the net_device.phydev
> +field to reach the PHY and perform the relevant configuration.
> +
> +This assumption falls appart in more complex topologies that can arise when,

apart.

	Andrew


From monstr at monstr.eu  Mon Dec 18 02:10:48 2023
From: monstr at monstr.eu (Michal Simek)
Date: Mon, 18 Dec 2023 11:10:48 +0100
Subject: [GIT PULL RESEND v2] arm64: soc: ZynqMP SoC changes for v6.8
Message-ID: <CAHTX3dJ=6y=vEgmH7Qqe=6TJZT=D-egKDmLLER4fS0=OHJRGZA@mail.gmail.com>

Hi,

please pull these patches to your tree. I am sending it again as v2 because
I see origin email in lore here
https://lore.kernel.org/soc/CAHTX3dJp_dztRCOn+-_OCeb-L6He7Pi2t-K0QeTDACaMs-xfTA at mail.gmail.com/T/#u
but I can't see it in patchwork.
I have "patched" Uwe's surname to remove no ascii char and see if that
goes through. That should be the only
difference between previous RESEND pull request.

Thanks,
Michal


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-soc-for-6.8

for you to fetch changes up to 87fda1acfc3b9048261799817ef749e6deb95724:

  soc: xilinx: Add error message for invalid payload received from IPI
callback. (2023-12-13 16:55:15 +0100)

----------------------------------------------------------------
arm64: ZynqMP SoC changes for 6.8

power driver:
- Move to remove_new hook
- Report error around unsupported callback
- Fix long messages

event driver:
- Fix cpu_id handling
- Fix warning message

----------------------------------------------------------------
HariBabu Gattem (1):
      soc: xilinx: Fix for call trace due to the usage of smp_processor_id()

Michal Simek (1):
      soc: xilinx: fix quoted string split across lines

Naman Trivedi Manojbhai (1):
      soc: xilinx: Add error message for invalid payload received from
IPI callback.

Tanmay Shah (1):
      soc: xilinx: fix unhandled SGI warning message

Uwe Kleine-Konig (1):
      soc/xilinx: zynqmp_power: Convert to platform remove callback
returning void

 drivers/soc/xilinx/xlnx_event_manager.c |  7 +++++--
 drivers/soc/xilinx/zynqmp_power.c       | 16 ++++++++--------
 2 files changed, 13 insertions(+), 10 deletions(-)


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs


From lukas.bulwahn at gmail.com  Mon Dec 18 02:12:25 2023
From: lukas.bulwahn at gmail.com (Lukas Bulwahn)
Date: Mon, 18 Dec 2023 11:12:25 +0100
Subject: [PATCH] MAINTAINERS: adjust file entry in GOOGLE TENSOR SoC SUPPORT
Message-ID: <20231218101225.27637-1-lukas.bulwahn@gmail.com>

Commit 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock
management unit bindings") adds the file google,gs101.h in
include/dt-bindings/clock/. However, commit 9d71df3e6eb7 ("MAINTAINERS:
add entry for Google Tensor SoC") wrongly refers to the file
google,clk-gs101.h in that directory.

Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a
broken reference.

Adjust the file entry to the actual file in GOOGLE TENSOR SoC SUPPORT.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn at gmail.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index d984bd745e93..d05c81acd849 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9034,7 +9034,7 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 F:	arch/arm64/boot/dts/exynos/google/
 F:	drivers/clk/samsung/clk-gs101.c
-F:	include/dt-bindings/clock/google,clk-gs101.h
+F:	include/dt-bindings/clock/google,gs101.h
 
 GPD POCKET FAN DRIVER
 M:	Hans de Goede <hdegoede at redhat.com>
-- 
2.34.1



From mripard at kernel.org  Mon Dec 18 02:14:24 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 11:14:24 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <F58855EC-D87D-4747-A363-0E7AA5DB1AEC@goldelico.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
 <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
 <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>
 <oobcl2kfsuph27er7rflfqvt3lu6athufomxv5chf3uctx4emh@x6rzjtlskhbf>
 <F58855EC-D87D-4747-A363-0E7AA5DB1AEC@goldelico.com>
Message-ID: <22cny5aumc5wafsrjd3j55zcjbjf2viip64kfbjiqis2grtd6t@wg5dxeuzil6l>

On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
> Hi Maxime,
> 
> > Am 15.12.2023 um 14:33 schrieb Maxime Ripard <mripard at kernel.org>:
> > 
> >>> 
> >>> It's for a separate architecture, with a separate driver, maintained out
> >>> of tree by a separate community, with a separate set of requirements as
> >>> evidenced by the other thread. And that's all fine in itself, but
> >>> there's very little reason to put these two bindings in the same file.
> >>> 
> >>> We could also turn this around, why is it important that it's in the
> >>> same file?
> >> 
> >> Same vendor. And enough similarity in architectures, even a logical sequence
> >> of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
> >> (SGX and Rogue seem to be just trade names for their architecture development).
> > 
> > Again, none of that matters for *where* the binding is stored.
> 
> So what then speaks against extending the existing bindings file as proposed
> here?

I mean, apart from everything you quoted, then sure, nothing speaks
against it.

> >> AFAIK bindings should describe hardware and not communities or drivers
> >> or who is currently maintaining it. The latter can change, the first not.
> > 
> > Bindings are supposed to describe hardware indeed. Nothing was ever said
> > about where those bindings are supposed to be located.
> > 
> > There's hundreds of other YAML bindings describing devices of the same
> > vendors and different devices from the same generation.
> 
> Usually SoC seem to be split over multiple files by subsystem. Not by versions
> or generations. If the subsystems are similar enough they share the same bindings
> doc instead of having one for each generation duplicating a lot of code.
> 
> Here is a comparable example that combines multiple vendors and generations:
> 
> Documentation/devicetree/bindings/usb/generic-ehci.yaml

EHCI is a single interface for USB2.0 controllers. It's a standard API,
and is made of a single driver that requires minor modifications to deal
with multiple devices.

We're very far from the same situation here.

> > If anything it'll make it easier for you. I'm really not sure why it is
> > controversial and you're fighting this so hard.
> 
> Well, you made it controversial by proposing to split what IMHO belongs together.

No, reviews aren't controversial. The controversy started when you chose
to oppose it while you could have just rolled with it.

> I feel that the original patch is good enough for its purpose and follows
> some design pattern that can be deduced from other binding docs.

[citation needed]

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/2349605a/attachment.sig>

From krzysztof.kozlowski at linaro.org  Mon Dec 18 02:16:24 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 11:16:24 +0100
Subject: [PATCH] MAINTAINERS: adjust file entry in GOOGLE TENSOR SoC
 SUPPORT
In-Reply-To: <20231218101225.27637-1-lukas.bulwahn@gmail.com>
References: <20231218101225.27637-1-lukas.bulwahn@gmail.com>
Message-ID: <170289458489.40214.4044639674573718307.b4-ty@linaro.org>


On Mon, 18 Dec 2023 11:12:25 +0100, Lukas Bulwahn wrote:
> Commit 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock
> management unit bindings") adds the file google,gs101.h in
> include/dt-bindings/clock/. However, commit 9d71df3e6eb7 ("MAINTAINERS:
> add entry for Google Tensor SoC") wrongly refers to the file
> google,clk-gs101.h in that directory.
> 
> Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a
> broken reference.
> 
> [...]

Applied, thanks!

[1/1] MAINTAINERS: adjust file entry in GOOGLE TENSOR SoC SUPPORT
      https://git.kernel.org/krzk/linux/c/d0da0de31e1d50ff905eb8f095628eea666f8c67

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From festevam at gmail.com  Mon Dec 18 02:16:46 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 18 Dec 2023 07:16:46 -0300
Subject: [PATCH v2 2/5] arm64: dts: imx8ulp-evk: enable usb nodes and add
 ptn5150 nodes
In-Reply-To: <20231218085456.3962720-2-xu.yang_2@nxp.com>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com> <20231218085456.3962720-2-xu.yang_2@nxp.com>
Message-ID: <CAOMZO5AZ6oLgeqvwf5_u9YhrFvwgRSiNjGq+wVMjXYsq7t3MxA@mail.gmail.com>

On Mon, Dec 18, 2023 at 5:49?AM Xu Yang <xu.yang_2 at nxp.com> wrote:

> +
> +       ptn5150_1: typec at 1d {
> +               compatible = "nxp,ptn5150";
> +               reg = <0x1d>;
> +               int-gpios = <&gpiof 3 IRQ_TYPE_EDGE_FALLING>;
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_typec1>;
> +               status = "disabled";

Why disabled?

No connector and no port properties. Please run dt-schema check
against linux-next.

> +       };
> +
> +       ptn5150_2: typec at 3d {
> +               compatible = "nxp,ptn5150";
> +               reg = <0x3d>;
> +               int-gpios = <&gpiof 5 IRQ_TYPE_EDGE_FALLING>;
> +                       pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_typec2>;
> +               status = "disabled";

Same here.


From sjoerd at collabora.com  Mon Dec 18 02:19:57 2023
From: sjoerd at collabora.com (Sjoerd Simons)
Date: Mon, 18 Dec 2023 11:19:57 +0100
Subject: [PATCH v2 0/3] Moxtet bus fixes
In-Reply-To: <87fs03cyki.fsf@BL-laptop>
References: <20231128213536.3764212-1-sjoerd@collabora.com>
	 <87fs0ceoif.fsf@BL-laptop> <20231208161724.5f4f626a@dellmb>
	 <87fs03cyki.fsf@BL-laptop>
Message-ID: <6c93241c35153cfb718db1d81e99e01bfb6dede5.camel@collabora.com>

On Fri, 2023-12-15 at 15:47 +0100, Gregory CLEMENT wrote:
> Marek Beh?n <kabel at kernel.org> writes:
> 
> > On Fri, 08 Dec 2023 15:51:20 +0100
> > Gregory CLEMENT <gregory.clement at bootlin.com> wrote:
> > 
> > Gregory, as of yet I've never done a pull request. If you are
> > willing
> > to take all 3 patches now, please do. In the future I would like to
> 
> OK I applied them on mvebu/driver.

Thanks both for moving this patches forward; Gregory looks like you
only applied two of the three patches (missing the dt patch), are you
expect that to flow through a different tree or ?


Regards,
-- 
Sjoerd Simons
Collabora Ltd.


From andriy.shevchenko at linux.intel.com  Mon Dec 18 02:23:32 2023
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 18 Dec 2023 12:23:32 +0200
Subject: [RFC PATCH v2 3/7] x86/kvm, ptp/kvm: Add clocksource ID, set
 system_counterval_t.cs_id
In-Reply-To: <20231215220612.173603-4-peter.hilber@opensynergy.com>
References: <20231215220612.173603-1-peter.hilber@opensynergy.com>
 <20231215220612.173603-4-peter.hilber@opensynergy.com>
Message-ID: <ZYAdpPfFa2jlmZ44@smile.fi.intel.com>

On Fri, Dec 15, 2023 at 11:06:08PM +0100, Peter Hilber wrote:
> Add a clocksource ID for the x86 kvmclock.
> 
> Also, for ptp_kvm, set the recently added struct system_counterval_t member
> cs_id to the clocksource ID (x86 kvmclock or Arm Generic Timer). In the
> future, this will keep get_device_system_crosststamp() working, when it
> will compare the clocksource id in struct system_counterval_t, rather than
> the clocksource.
> 
> For now, to avoid touching too many subsystems at once, extract the
> clocksource ID from the clocksource. The clocksource dereference will be
> removed in the following.

...

>  #include <linux/clocksource.h>
> +#include <linux/clocksource_ids.h>

It's the second file that includes both.

I'm just wondering if it makes sense to always (?) include the latter into
the former.

-- 
With Best Regards,
Andy Shevchenko




From m.szyprowski at samsung.com  Mon Dec 18 02:25:38 2023
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Mon, 18 Dec 2023 11:25:38 +0100
Subject: [PATCH] drm/rockchip: vop2: Avoid use regmap_reinit_cache at
 runtime
In-Reply-To: <20231217084415.2373043-1-andyshrk@163.com>
References: <CGME20231217084551eucas1p22664cbb28e576c394376df61bd1b5569@eucas1p2.samsung.com>
	<20231217084415.2373043-1-andyshrk@163.com>
Message-ID: <3838492a-a2da-40f3-82a9-a8f88839e0d9@samsung.com>

On 17.12.2023 09:44, Andy Yan wrote:
> From: Andy Yan <andy.yan at rock-chips.com>
>
> Marek Report a possible irq lock inversion dependency warning when
> commit 81a06f1d02e5 ("Revert "drm/rockchip: vop2: Use regcache_sync()
> to fix suspend/resume"") lands linux-next.
>
> I can reproduce this warning with:
> CONFIG_PROVE_LOCKING=y
> CONFIG_DEBUG_LOCKDEP=y
>
> It seems than when use regmap_reinit_cache at runtime whith Mark's
> commit 3d59c22bbb8d ("drm/rockchip: vop2: Convert to use maple tree
> register cache"), it will trigger a possible irq lock inversion dependency
> warning.
>
> One solution is switch back to REGCACHE_RBTREE, but it seems that
> REGCACHE_MAPLE is the future, so I avoid ues regmap_reinit_cache,
> and drop all the regcache when vop is disabled, then we get a fresh
> start at next enbable time.
>
> [    8.425923] dwmmc_rockchip fe2b0000.mmc: IDMAC supports 32-bit address mode.
> [    8.427020] dwmmc_rockchip fe2b0000.mmc: Using internal DMA controller.
> [    8.428013] dwmmc_rockchip fe2b0000.mmc: Version ID is 270a
> [    8.429088] dwmmc_rockchip fe2b0000.mmc: DW MMC controller at irq 78,32 bit host data width,256 deep fifo
> [    8.454219] mmc_host mmc0: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0)
> [    8.465446] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_component_ops)
> [    8.475586] dwhdmi-rockchip fe0a0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY)
> [    8.484326] dwhdmi-rockchip fe0a0000.hdmi: registered DesignWare HDMI I2C bus driver
> [    8.490505] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops dw_hdmi_rockchip_ops)
> [    8.501151] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0
> [    8.895456]
> [    8.895473] ========================================================
> [    8.895480] WARNING: possible irq lock inversion dependency detected
> [    8.895486] 6.7.0-rc5-next-20231215 #514 Not tainted
> [    8.895496] --------------------------------------------------------
> [    8.895501] swapper/0/0 just changed the state of lock:
> [    8.895510] ffff0000070b6018 (rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock){-...}-{2:2}, at: regmap_lock_spinlock
> +0x14/0x24
> [    8.895560] but this lock took another, HARDIRQ-unsafe lock in the past:
> [    8.895566]  (&mt->ma_lock){+.+.}-{2:2}
> [    8.895580]
> [    8.895580]
> [    8.895580] and interrupts could create inverse lock ordering between them.
> [    8.895580]
> [    8.895585]
> [    8.895585] other info that might help us debug this:
> [    8.895590]  Possible interrupt unsafe locking scenario:
> [    8.895590]
> [    8.895594]        CPU0                    CPU1
> [    8.895598]        ----                    ----
> [    8.895602]   lock(&mt->ma_lock);
> [    8.895614]                                local_irq_disable();
> [    8.895617]                                lock(rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock);
> [    8.895629]                                lock(&mt->ma_lock);
> [    8.895641]   <Interrupt>
> [    8.895644]   lock(rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock);
> [    8.895655]
> [    8.895655]  *** DEADLOCK ***
> [    8.895655]
> [    8.895659] no locks held by swapper/0/0.
> [    8.895664]
> [    8.895664] the shortest dependencies between 2nd lock and 1st lock:
> [    8.895672]  -> (&mt->ma_lock){+.+.}-{2:2} ops: 12 {
> [    8.895704]     HARDIRQ-ON-W at:
> [    8.895713]                       lock_acquire+0x238/0x354
> [    8.895732]                       _raw_spin_lock+0x3c/0x50
> [    8.895749]                       regcache_maple_exit+0x64/0xc4
> [    8.895766]                       regcache_exit+0x48/0xac
> [    8.895780]                       regmap_reinit_cache+0x18/0x98
> [    8.895793]	                     vop2_crtc_atomic_enable+0xefc/0x1074
> [    8.895810]                       drm_atomic_helper_commit_modeset_enables+0xac/0x264
> [    8.895826]                       drm_atomic_helper_commit_tail_rpm+0x2c/0x78
> [    8.895841]                       commit_tail+0x9c/0x178
> [    8.895855]                       drm_atomic_helper_commit+0x17c/0x1ac
> [    8.895869]                       drm_atomic_commit+0xac/0xec
> [    8.895885]                       drm_client_modeset_commit_atomic+0x230/0x290
> [    8.895896]                       drm_client_modeset_commit_locked+0x54/0x1c4
> [    8.895907]                       drm_client_modeset_commit+0x2c/0x50
> [    8.895917]                       __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
> [    8.895934]                       drm_fb_helper_set_par+0x30/0x48
> [    8.895948]                       fbcon_init+0x40c/0x498
> [    8.895961]                       visual_init+0xb0/0x108
> [    8.895972]                       do_bind_con_driver+0x1b8/0x38c
> [    8.895983]                       do_take_over_console+0x148/0x1d4
> [    8.895993]                       do_fbcon_takeover+0x6c/0xe0
> [    8.896003]                       fbcon_fb_registered+0x1f8/0x1fc
> [    8.896014]                       register_framebuffer+0x158/0x228
> [    8.896029]                       __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
> [    8.896045]                       drm_fb_helper_initial_config+0x3c/0x48
> [    8.896060]                       drm_fbdev_generic_client_hotplug+0xb8/0xd8
> [    8.896074]                       drm_client_register+0x58/0xa0
> [    8.896085]                       drm_fbdev_generic_setup+0xbc/0x144
> [    8.896098]                       rockchip_drm_bind+0x1ec/0x1f8
> [    8.896110]                       try_to_bring_up_aggregate_device+0x278/0x2d8
> [    8.896127]                       __component_add+0xac/0x198
> [    8.896139]                       component_add+0x10/0x18
> [    8.896151]                       dw_hdmi_rockchip_probe+0x1c/0x24
> [    8.896163]                       platform_probe+0x90/0xd8
> [    8.896179]                       really_probe+0x114/0x3c0
> [    8.896192]                       __driver_probe_device+0x7c/0x17c
> [    8.896204]                       driver_probe_device+0x38/0x11c
> [    8.896218]                       __device_attach_driver+0xb4/0x164
> [    8.896230]                       bus_for_each_drv+0x78/0xdc
> [    8.896241]                       __device_attach+0xfc/0x1ac
> [    8.896253]                       device_initial_probe+0x10/0x18
> [    8.896266]                       bus_probe_device+0xa8/0xac
> [    8.896277]                       deferred_probe_work_func+0x98/0xe8
> [    8.896290]                       process_scheduled_works+0x23c/0x5b8
> [    8.896306]                       worker_thread+0x188/0x374
> [    8.896319]                       kthread+0xe4/0x10c
> [    8.896332]                       ret_from_fork+0x10/0x20
> [    8.896345]     SOFTIRQ-ON-W at:
> [    8.896355]                       lock_acquire+0x238/0x354
> [    8.896370]                       _raw_spin_lock+0x3c/0x50
> [    8.896384]                       regcache_maple_exit+0x64/0xc4
> [    8.896399]                       regcache_exit+0x48/0xac
> [    8.896411]                       regmap_reinit_cache+0x18/0x98
> [    8.896423]                       vop2_crtc_atomic_enable+0xefc/0x1074
> [    8.896437]                       drm_atomic_helper_commit_modeset_enables+0xac/0x264
> [    8.896453]                       drm_atomic_helper_commit_tail_rpm+0x2c/0x78
> [    8.896467]                       commit_tail+0x9c/0x178
> [    8.896480]                       drm_atomic_helper_commit+0x17c/0x1ac
> [    8.896494]                       drm_atomic_commit+0xac/0xec
> [    8.896509]                       drm_client_modeset_commit_atomic+0x230/0x290
> [    8.896520]                       drm_client_modeset_commit_locked+0x54/0x1c4
> [    8.896530]                       drm_client_modeset_commit+0x2c/0x50
> [    8.896540]                       __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
> [    8.896558]                       drm_fb_helper_set_par+0x30/0x48
> [    8.896572]                       fbcon_init+0x40c/0x498
> [    8.896582]                       visual_init+0xb0/0x108
> [    8.896591]                       do_bind_con_driver+0x1b8/0x38c
> [    8.896601]                       do_take_over_console+0x148/0x1d4
> [    8.896611]                       do_fbcon_takeover+0x6c/0xe0
> [    8.896620]                       fbcon_fb_registered+0x1f8/0x1fc
> [    8.896630]                       register_framebuffer+0x158/0x228
> [    8.896645]                       __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
> [    8.896660]                       drm_fb_helper_initial_config+0x3c/0x48
> [    8.896674]                       drm_fbdev_generic_client_hotplug+0xb8/0xd8
> [    8.896688]                       drm_client_register+0x58/0xa0
> [    8.896698]                       drm_fbdev_generic_setup+0xbc/0x144
> [    8.896711]                       rockchip_drm_bind+0x1ec/0x1f8
> [    8.896724]                       try_to_bring_up_aggregate_device+0x278/0x2d8
> [    8.896738]                       __component_add+0xac/0x198
> [    8.896751]                       component_add+0x10/0x18
> [    8.896763]                       dw_hdmi_rockchip_probe+0x1c/0x24
> [    8.896773]                       platform_probe+0x90/0xd8
> [    8.896789]                       really_probe+0x114/0x3c0
> [    8.896801]                       __driver_probe_device+0x7c/0x17c
> [    8.896814]                       driver_probe_device+0x38/0x11c
> [    8.896827]                       __device_attach_driver+0xb4/0x164
> [    8.896839]                       bus_for_each_drv+0x78/0xdc
> [    8.896850]                       __device_attach+0xfc/0x1ac
> [    8.896862]                       device_initial_probe+0x10/0x18
> [    8.896875]                       bus_probe_device+0xa8/0xac
> [    8.896886]                       deferred_probe_work_func+0x98/0xe8
> [    8.896897]                       process_scheduled_works+0x23c/0x5b8
> [    8.896911]                       worker_thread+0x188/0x374
> [    8.896924]                       kthread+0xe4/0x10c
> [    8.896935]                       ret_from_fork+0x10/0x20
> [    8.896947]     INITIAL USE at:
> [    8.896955]                      lock_acquire+0x238/0x354
> [    8.896971]                      _raw_spin_lock+0x3c/0x50
> [    8.896985]                      regcache_maple_exit+0x64/0xc4
> [    8.896999]                      regcache_exit+0x48/0xac
> [    8.897011]                      regmap_reinit_cache+0x18/0x98
> [    8.897022]                      vop2_crtc_atomic_enable+0xefc/0x1074
> [    8.897036]                      drm_atomic_helper_commit_modeset_enables+0xac/0x264
> [    8.897051]                      drm_atomic_helper_commit_tail_rpm+0x2c/0x78
> [    8.897065]                      commit_tail+0x9c/0x178
> [    8.897079]                      drm_atomic_helper_commit+0x17c/0x1ac
> [    8.897093]                      drm_atomic_commit+0xac/0xec
> [    8.897107]                      drm_client_modeset_commit_atomic+0x230/0x290
> [    8.897118]                      drm_client_modeset_commit_locked+0x54/0x1c4
> [    8.897128]                      drm_client_modeset_commit+0x2c/0x50
> [    8.897138]                      __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
> [    8.897154]                      drm_fb_helper_set_par+0x30/0x48
> [    8.897168]                      fbcon_init+0x40c/0x498
> [    8.897179]                      visual_init+0xb0/0x108
> [    8.897188]                      do_bind_con_driver+0x1b8/0x38c
> [    8.897198]                      do_take_over_console+0x148/0x1d4
> [    8.897208]                      do_fbcon_takeover+0x6c/0xe0
> [    8.897218]                      fbcon_fb_registered+0x1f8/0x1fc
> [    8.897228]                      register_framebuffer+0x158/0x228
> [    8.897241]                      __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
> [    8.897257]                      drm_fb_helper_initial_config+0x3c/0x48
> [    8.897272]                      drm_fbdev_generic_client_hotplug+0xb8/0xd8
> [    8.897286]                      drm_client_register+0x58/0xa0
> [    8.897296]                      drm_fbdev_generic_setup+0xbc/0x144
> [    8.897309]                      rockchip_drm_bind+0x1ec/0x1f8
> [    8.897321]                      try_to_bring_up_aggregate_device+0x278/0x2d8
> [    8.897336]                      __component_add+0xac/0x198
> [    8.897348]                      component_add+0x10/0x18
> [    8.897360]                      dw_hdmi_rockchip_probe+0x1c/0x24
> [    8.897370]                      platform_probe+0x90/0xd8
> [    8.897385]                      really_probe+0x114/0x3c0
> [    8.897397]                      __driver_probe_device+0x7c/0x17c
> [    8.897410]                      driver_probe_device+0x38/0x11c
> [    8.897422]                      __device_attach_driver+0xb4/0x164
> [    8.897434]                      bus_for_each_drv+0x78/0xdc
> [    8.897445]                      __device_attach+0xfc/0x1ac
> [    8.897456]                      device_initial_probe+0x10/0x18
> [    8.897469]                      bus_probe_device+0xa8/0xac
> [    8.897480]                      deferred_probe_work_func+0x98/0xe8
> [    8.897492]                      process_scheduled_works+0x23c/0x5b8
> [    8.897506]                      worker_thread+0x188/0x374
> [    8.897518]                      kthread+0xe4/0x10c
> [    8.897529]                      ret_from_fork+0x10/0x20
> [    8.897541]   }
> [    8.897545]   ... key      at: [<ffff800082efc820>]__key.20703+0x0/0x10
> [    8.897561]   ... acquired at:
> [    8.897566]    _raw_spin_lock+0x3c/0x50
> [    8.897580]    regcache_maple_write+0x268/0x314
> [    8.897595]    regcache_write+0x68/0x84
> [    8.897607]    _regmap_read+0xd0/0x1f4
> [    8.897619]    _regmap_update_bits+0xe0/0x140
> [    8.897631]    regmap_update_bits_base+0x60/0x8c
> [    8.897643]    regmap_field_update_bits_base+0x30/0x38
> [    8.897656]    vop2_plane_atomic_update+0x8b0/0x1400
> [    8.897669]    drm_atomic_helper_commit_planes+0xdc/0x2a0
> [    8.897683]    drm_atomic_helper_commit_tail_rpm+0x3c/0x78
> [    8.897697]    commit_tail+0x9c/0x178
> [    8.897709]    drm_atomic_helper_commit+0x17c/0x1ac
> [    8.897722]    drm_atomic_commit+0xac/0xec
> [    8.897735]    drm_client_modeset_commit_atomic+0x230/0x290
> [    8.897746]    drm_client_modeset_commit_locked+0x54/0x1c4
> [    8.897758]    drm_client_modeset_commit+0x2c/0x50
> [    8.897767]    __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
> [    8.897784]    drm_fb_helper_set_par+0x30/0x48
> [    8.897797]    fbcon_init+0x40c/0x498
> [    8.897807]    visual_init+0xb0/0x108
> [    8.897816]    do_bind_con_driver+0x1b8/0x38c
> [    8.897825]    do_take_over_console+0x148/0x1d4
> [    8.897835]    do_fbcon_takeover+0x6c/0xe0
> [    8.897844]    fbcon_fb_registered+0x1f8/0x1fc
> [    8.897854]    register_framebuffer+0x158/0x228
> [    8.897866]    __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
> [    8.897882]    drm_fb_helper_initial_config+0x3c/0x48
> [    8.897895]    drm_fbdev_generic_client_hotplug+0xb8/0xd8
> [    8.897908]    drm_client_register+0x58/0xa0
> [    8.897917]    drm_fbdev_generic_setup+0xbc/0x144
> [    8.897929]    rockchip_drm_bind+0x1ec/0x1f8
> [    8.897941]    try_to_bring_up_aggregate_device+0x278/0x2d8
> [    8.897956]    __component_add+0xac/0x198
> [    8.897967]    component_add+0x10/0x18
> [    8.897979]    dw_hdmi_rockchip_probe+0x1c/0x24
> [    8.897988]    platform_probe+0x90/0xd8
> [    8.898002]    really_probe+0x114/0x3c0
> [    8.898013]    __driver_probe_device+0x7c/0x17c
> [    8.898026]    driver_probe_device+0x38/0x11c
> [    8.898038]    __device_attach_driver+0xb4/0x164
> [    8.898049]    bus_for_each_drv+0x78/0xdc
> [    8.898059]    __device_attach+0xfc/0x1ac
> [    8.898070]    device_initial_probe+0x10/0x18
> [    8.898082]    bus_probe_device+0xa8/0xac
> [    8.898093]    deferred_probe_work_func+0x98/0xe8
> [    8.898105]    process_scheduled_works+0x23c/0x5b8
> [    8.898118]    worker_thread+0x188/0x374
> [    8.898131]    kthread+0xe4/0x10c
> [    8.898142]    ret_from_fork+0x10/0x20
> [    8.898153]
> [    8.898157] ->(rockchip_drm_vop2:3116:(&vop2_regmap_config)->lock){-...}-{2:2} ops: 74
> {
> [    8.898185]    IN-HARDIRQ-W at:
> [    8.898194]                     lock_acquire+0x238/0x354
> [    8.898211]                     _raw_spin_lock_irqsave+0x50/0x6c
> [    8.898227]                     regmap_lock_spinlock+0x14/0x24
> [    8.898238]                     regmap_read+0x38/0x70
> [    8.898250]                     vop2_isr+0x88/0x2ac
> [    8.898263]                     __handle_irq_event_percpu+0xa4/0x2bc
> [    8.898277]                     handle_irq_event_percpu+0x14/0x44
> [    8.898290]                     handle_irq_event+0x44/0x90
> [    8.898300]                     handle_fasteoi_irq+0xf8/0x1d4
> [    8.898314]                     generic_handle_domain_irq+0x28/0x3c
> [    8.898324]                     gic_handle_irq+0xb0/0x130
> [    8.898334]                     call_on_irq_stack+0x24/0x34
> [    8.898345]                     do_interrupt_handler+0xc4/0xdc
> [    8.898359]                     el1_interrupt+0x3c/0x70
> [    8.898375]                     el1h_64_irq_handler+0x14/0x1c
> [    8.898390]                     el1h_64_irq+0x64/0x68
> [    8.898398]                     default_idle_call+0xec/0x118
> [    8.898409]                     do_idle+0x1c8/0x254
> [    8.898420]                     cpu_startup_entry+0x30/0x38
> [    8.898430]                     rest_init+0x13c/0x1cc
> [    8.898440]                     arch_post_acpi_subsys_init+0x0/0x8
> [    8.898455]                     start_kernel+0x7c0/0x968
> [    8.898465]                     __primary_switched+0xb0/0xbc
> [    8.898481]    INITIAL USE at:
> [    8.898492]                    lock_acquire+0x238/0x354
> [    8.898506]                    _raw_spin_lock_irqsave+0x50/0x6c
> [    8.898520]                    regmap_lock_spinlock+0x14/0x24
> [    8.898531]                    regmap_write+0x38/0x70
> [    8.898544]                    vop2_crtc_atomic_enable+0xf64/0x1074
> [    8.898560]                    drm_atomic_helper_commit_modeset_enables+0xac/0x264
> [    8.898575]                    drm_atomic_helper_commit_tail_rpm+0x2c/0x78
> [    8.898589]                    commit_tail+0x9c/0x178
> [    8.898601]                    drm_atomic_helper_commit+0x17c/0x1ac
> [    8.898615]                    drm_atomic_commit+0xac/0xec
> [    8.898628]                    drm_client_modeset_commit_atomic+0x230/0x290
> [    8.898639]                    drm_client_modeset_commit_locked+0x54/0x1c4
> [    8.898649]                    drm_client_modeset_commit+0x2c/0x50
> [    8.898660]                    __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
> [    8.898675]                    drm_fb_helper_set_par+0x30/0x48
> [    8.898689]                    fbcon_init+0x40c/0x498
> [    8.898699]                    visual_init+0xb0/0x108
> [    8.898709]                    do_bind_con_driver+0x1b8/0x38c
> [    8.898719]                    do_take_over_console+0x148/0x1d4
> [    8.898730]                    do_fbcon_takeover+0x6c/0xe0
> [    8.898740]                    fbcon_fb_registered+0x1f8/0x1fc
> [    8.898750]                    register_framebuffer+0x158/0x228
> [    8.898763]                    __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
> [    8.898779]                    drm_fb_helper_initial_config+0x3c/0x48
> [    8.898793]                    drm_fbdev_generic_client_hotplug+0xb8/0xd8
> [    8.898806]                    drm_client_register+0x58/0xa0
> [    8.898815]                    drm_fbdev_generic_setup+0xbc/0x144
> [    8.898830]                    rockchip_drm_bind+0x1ec/0x1f8
> [    8.898842]                    try_to_bring_up_aggregate_device+0x278/0x2d8
> [    8.898858]                    __component_add+0xac/0x198
> [    8.898871]                    component_add+0x10/0x18
> [    8.898885]                    dw_hdmi_rockchip_probe+0x1c/0x24
> [    8.898894]                    platform_probe+0x90/0xd8
> [    8.898909]                    really_probe+0x114/0x3c0
> [    8.898921]                    __driver_probe_device+0x7c/0x17c
> [    8.898933]                    driver_probe_device+0x38/0x11c
> [    8.898945]                    __device_attach_driver+0xb4/0x164
> [    8.898958]                    bus_for_each_drv+0x78/0xdc
> [    8.898969]                    __device_attach+0xfc/0x1ac
> [    8.898980]                    device_initial_probe+0x10/0x18
> [    8.898993]                    bus_probe_device+0xa8/0xac
> [    8.899004]                    deferred_probe_work_func+0x98/0xe8
> [    8.899015]                    process_scheduled_works+0x23c/0x5b8
> [    8.899029]                    worker_thread+0x188/0x374
> [    8.899042]                    kthread+0xe4/0x10c
> [    8.899053]                    ret_from_fork+0x10/0x20
> [    8.899064]  }
> [    8.899069]  ... key      at: [<ffff800082efbe90>]_key.73979+0x0/0x10
> [    8.899086]  ... acquired at:
> [    8.899091]    __lock_acquire+0x9d8/0x1950
> [    8.899104]    lock_acquire+0x238/0x354
> [    8.899117]    _raw_spin_lock_irqsave+0x50/0x6c
> [    8.899131]    regmap_lock_spinlock+0x14/0x24
> [    8.899142]    regmap_read+0x38/0x70
> [    8.899154]    vop2_isr+0x88/0x2ac
> [    8.899166]    __handle_irq_event_percpu+0xa4/0x2bc
> [    8.899178]    handle_irq_event_percpu+0x14/0x44
> [    8.899188]    handle_irq_event+0x44/0x90
> [    8.899198]    handle_fasteoi_irq+0xf8/0x1d4
> [    8.899211]    generic_handle_domain_irq+0x28/0x3c
> [    8.899221]    gic_handle_irq+0xb0/0x130
> [    8.899230]    call_on_irq_stack+0x24/0x34
> [    8.899243]    do_interrupt_handler+0xc4/0xdc
> [    8.899256]    el1_interrupt+0x3c/0x70
> [    8.899270]    el1h_64_irq_handler+0x14/0x1c
> [    8.899285]    el1h_64_irq+0x64/0x68
> [    8.899293]    default_idle_call+0xec/0x118
> [    8.899304]    do_idle+0x1c8/0x254
> [    8.899313]    cpu_startup_entry+0x30/0x38
> [    8.899321]    rest_init+0x13c/0x1cc
> [    8.899331]    arch_post_acpi_subsys_init+0x0/0x8
> [    8.899342]    start_kernel+0x7c0/0x968
> [    8.899351]    __primary_switched+0xb0/0xbc
> [    8.899365]
> [    8.899368]
> [    8.899368] stack backtrace:
> [    8.899376] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-rc5-next-20231215 #514
> [    8.899386] Hardware name: EmbedFire LubanCat 2 (DT)
> [    8.899394] Call trace:
> [    8.899399]  dump_backtrace+0xe4/0x124
> [    8.899410]  show_stack+0x14/0x1c
> [    8.899419]  dump_stack_lvl+0x78/0xd4
> [    8.899430]  dump_stack+0x14/0x1c
> [    8.899438]  print_irq_inversion_bug+0x28c/0x304
> [    8.899453]  mark_lock.part.43+0x2c0/0x448
> [    8.899466]  __lock_acquire+0x9d8/0x1950
> [    8.899479]  lock_acquire+0x238/0x354
> [    8.899492]  _raw_spin_lock_irqsave+0x50/0x6c
> [    8.899507]  regmap_lock_spinlock+0x14/0x24
> [    8.899517]  regmap_read+0x38/0x70
> [    8.899528]  vop2_isr+0x88/0x2ac
> [    8.899540]  __handle_irq_event_percpu+0xa4/0x2bc
> [    8.899553]  handle_irq_event_percpu+0x14/0x44
> [    8.899565]  handle_irq_event+0x44/0x90
> [    8.899575]  handle_fasteoi_irq+0xf8/0x1d4
> [    8.899589]  generic_handle_domain_irq+0x28/0x3c
> [    8.899599]  gic_handle_irq+0xb0/0x130
> [    8.899608]  call_on_irq_stack+0x24/0x34
> [    8.899619]  do_interrupt_handler+0xc4/0xdc
> [    8.899631]  el1_interrupt+0x3c/0x70
> [    8.899645]  el1h_64_irq_handler+0x14/0x1c
> [    8.899659]  el1h_64_irq+0x64/0x68
> [    8.899669]  default_idle_call+0xec/0x118
> [    8.899679]  do_idle+0x1c8/0x254
> [    8.899689]  cpu_startup_entry+0x30/0x38
> [    8.899698]  rest_init+0x13c/0x1cc
> [    8.899708]  arch_post_acpi_subsys_init+0x0/0x8
> [    8.899720]  start_kernel+0x7c0/0x968
> [    8.899731]  __primary_switched+0xb0/0xbc
> [    8.946839] Console: switching to colour frame buffer device 240x67
> [   10.230883] rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device
>
> Fixes: 81a06f1d02e5 ("Revert "drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume"")
> Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Closes: https://lore.kernel.org/all/98a9f15d-30ac-47bf-9b93-3aa2c9900f7b at samsung.com/
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> ---
>
>   drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8 ++------
>   1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 4beb04c83752..f2edaebfcaf9 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -993,12 +993,6 @@ static void vop2_enable(struct vop2 *vop2)
>   		return;
>   	}
>   
> -	ret = regmap_reinit_cache(vop2->map, &vop2_regmap_config);
> -	if (ret) {
> -		drm_err(vop2->drm, "failed to reinit cache: %d\n", ret);
> -		return;
> -	}
> -
>   	if (vop2->data->soc_id == 3566)
>   		vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
>   
> @@ -1030,6 +1024,8 @@ static void vop2_disable(struct vop2 *vop2)
>   
>   	pm_runtime_put_sync(vop2->dev);
>   
> +	regcache_drop_region(vop2->map, 0, vop2_regmap_config.max_register);
> +
>   	clk_disable_unprepare(vop2->pclk);
>   	clk_disable_unprepare(vop2->aclk);
>   	clk_disable_unprepare(vop2->hclk);

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From neil.armstrong at linaro.org  Mon Dec 18 02:26:24 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 18 Dec 2023 11:26:24 +0100
Subject: [PATCH 1/2] arm64: dts: qcom: sm8650-qrd: add USB-C Altmode
 Support
In-Reply-To: <20231218-topic-sm8650-upstream-altmode-v1-0-7900660693cf@linaro.org>
References: <20231218-topic-sm8650-upstream-altmode-v1-0-7900660693cf@linaro.org>
Message-ID: <20231218-topic-sm8650-upstream-altmode-v1-1-7900660693cf@linaro.org>

Add the necessary nodes to support the USB-C Altmode path by
adding the following
- WCD939x USBSS Mux I2C device
- nb7vpq904m Redriver I2C device
- Port/Endpoint graph links bettween PMIC-Glink, Mux, Redriver and USB PHY nodes.

WCD939x USBSS port 2 Path to Codec will be added later when Audio support
is added.

Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 104 +++++++++++++++++++++++++++++++-
 1 file changed, 102 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
index 592a67a47c78..121fbbb5d015 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
@@ -77,9 +77,17 @@ port at 1 {
 					reg = <1>;
 
 					pmic_glink_ss_in: endpoint {
-						remote-endpoint = <&usb_1_dwc3_ss>;
+						remote-endpoint = <&redriver_ss_out>;
 					};
 				};
+
+				port at 2 {
+					reg = <2>;
+
+					pmic_glink_sbu: endpoint {
+						remote-endpoint = <&wcd_usbss_sbu_mux>;
+				    };
+				};
 			};
 		};
 	};
@@ -446,6 +454,70 @@ &gpi_dma1 {
 	status = "okay";
 };
 
+&i2c3 {
+       status = "ok";
+
+       wcd_usbss: typec-mux at e {
+		compatible = "qcom,wcd9395-usbss", "qcom,wcd9390-usbss";
+		reg = <0xe>;
+
+		vdd-supply = <&vreg_l15b_1p8>;
+		reset-gpios = <&tlmm 152 GPIO_ACTIVE_HIGH>;
+
+		mode-switch;
+		orientation-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				wcd_usbss_sbu_mux: endpoint {
+					remote-endpoint = <&pmic_glink_sbu>;
+				};
+			};
+		};
+       };
+};
+
+&i2c6 {
+	status = "ok";
+
+	typec-mux at 1c {
+		compatible = "onnn,nb7vpq904m";
+		reg = <0x1c>;
+
+		vcc-supply = <&vreg_l15b_1p8>;
+
+		retimer-switch;
+		orientation-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				redriver_ss_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss_in>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+
+				redriver_ss_in: endpoint {
+					data-lanes = <3 2 1 0>;
+					remote-endpoint = <&usb_dp_qmpphy_out>;
+				};
+			};
+		};
+	};
+};
+
 &ipa {
 	qcom,gsi-loader = "self";
 	memory-region = <&ipa_fw_mem>;
@@ -495,6 +567,15 @@ &mdss_dsi0_phy {
 	status = "okay";
 };
 
+&mdss_dp0 {
+	status = "okay";
+};
+
+&mdss_dp0_out {
+	data-lanes = <0 1>;
+	remote-endpoint = <&usb_dp_qmpphy_dp_in>;
+};
+
 &mdss_mdp {
 	status = "okay";
 };
@@ -600,6 +681,11 @@ &pmk8550_rtc {
 	status = "okay";
 };
 
+&qup_i2c3_data_clk {
+	/* Use internal I2C pull-up */
+	bias-pull-up = <2200>;
+};
+
 &qupv3_id_0 {
 	status = "okay";
 };
@@ -787,7 +873,7 @@ &usb_1_dwc3_hs {
 };
 
 &usb_1_dwc3_ss {
-	remote-endpoint = <&pmic_glink_ss_in>;
+	remote-endpoint = <&usb_dp_qmpphy_usb_ss_in>;
 };
 
 &usb_1_hsphy {
@@ -803,9 +889,23 @@ &usb_dp_qmpphy {
 	vdda-phy-supply = <&vreg_l3i_1p2>;
 	vdda-pll-supply = <&vreg_l3g_0p91>;
 
+	orientation-switch;
+
 	status = "okay";
 };
 
+&usb_dp_qmpphy_dp_in {
+	remote-endpoint = <&mdss_dp0_out>;
+};
+
+&usb_dp_qmpphy_out {
+	remote-endpoint = <&redriver_ss_in>;
+};
+
+&usb_dp_qmpphy_usb_ss_in {
+	remote-endpoint = <&usb_1_dwc3_ss>;
+};
+
 &xo_board {
 	clock-frequency = <76800000>;
 };

-- 
2.34.1



From neil.armstrong at linaro.org  Mon Dec 18 02:26:25 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 18 Dec 2023 11:26:25 +0100
Subject: [PATCH 2/2] arm64: defconfig: enable WCD939x USBSS driver as
 module
In-Reply-To: <20231218-topic-sm8650-upstream-altmode-v1-0-7900660693cf@linaro.org>
References: <20231218-topic-sm8650-upstream-altmode-v1-0-7900660693cf@linaro.org>
Message-ID: <20231218-topic-sm8650-upstream-altmode-v1-2-7900660693cf@linaro.org>

Enable the Qualcomm WCD939x USBSS Type-C mux as module as
is now used on the SM8650 QRD platform.

Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e67a4849b91..c9ba75f1b248 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1067,6 +1067,7 @@ CONFIG_TYPEC_QCOM_PMIC=m
 CONFIG_TYPEC_UCSI=m
 CONFIG_TYPEC_MUX_FSA4480=m
 CONFIG_TYPEC_MUX_NB7VPQ904M=m
+CONFIG_TYPEC_MUX_WCD939X_USBSS=m
 CONFIG_UCSI_CCG=m
 CONFIG_TYPEC_MUX_GPIO_SBU=m
 CONFIG_TYPEC_DP_ALTMODE=m

-- 
2.34.1



From neil.armstrong at linaro.org  Mon Dec 18 02:26:23 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 18 Dec 2023 11:26:23 +0100
Subject: [PATCH 0/2] arm64: qcom: sm8650: add support for USB-C Altmode
Message-ID: <20231218-topic-sm8650-upstream-altmode-v1-0-7900660693cf@linaro.org>

This adds the missing bits to support Display Port external
display over the USB-C Altmode support using the Redriver/Retimer
and WCD939x USBSS Mux/Switch to provide the correct switching.

Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
---
Neil Armstrong (2):
      arm64: dts: qcom: sm8650-qrd: add USB-C Altmode Support
      arm64: defconfig: enable WCD939x USBSS driver as module

 arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 104 +++++++++++++++++++++++++++++++-
 arch/arm64/configs/defconfig            |   1 +
 2 files changed, 103 insertions(+), 2 deletions(-)
---
base-commit: ceb2fe0d438644e1de06b9a6468a1fb8e2199c70
change-id: 20231218-topic-sm8650-upstream-altmode-3ee141fdccff

Best regards,
-- 
Neil Armstrong <neil.armstrong at linaro.org>



From suzuki.poulose at arm.com  Mon Dec 18 02:27:43 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 18 Dec 2023 10:27:43 +0000
Subject: [PATCH v3 2/8] coresight-tpda: Add support to configure CMB
 element
In-Reply-To: <1700533494-19276-3-git-send-email-quic_taozha@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-3-git-send-email-quic_taozha@quicinc.com>
Message-ID: <88e51407-344e-4584-8711-29cc014c782b@arm.com>

On 21/11/2023 02:24, Tao Zhang wrote:
> Read the CMB element size from the device tree. Set the register
> bit that controls the CMB element size of the corresponding port.
> 
> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
> ---
>   drivers/hwtracing/coresight/coresight-tpda.c | 117 +++++++++++--------
>   drivers/hwtracing/coresight/coresight-tpda.h |   6 +
>   2 files changed, 74 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c
> index 5f82737c37bb..e3762f38abb3 100644
> --- a/drivers/hwtracing/coresight/coresight-tpda.c
> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
> @@ -28,24 +28,54 @@ static bool coresight_device_is_tpdm(struct coresight_device *csdev)
>   			CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM);
>   }
>   
> +static void tpdm_clear_element_size(struct coresight_device *csdev)
> +{
> +	struct tpda_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> +
> +	if (drvdata->dsb_esize)
> +		drvdata->dsb_esize = 0;
> +	if (drvdata->cmb_esize)
> +		drvdata->cmb_esize = 0;

Why do we need the if (...) check here ?

> +}
> +
> +static void tpda_set_element_size(struct tpda_drvdata *drvdata, u32 *val)
> +{
> +
> +	if (drvdata->dsb_esize == 64)
> +		*val |= TPDA_Pn_CR_DSBSIZE;
> +	else if (drvdata->dsb_esize == 32)
> +		*val &= ~TPDA_Pn_CR_DSBSIZE;
> +
> +	if (drvdata->cmb_esize == 64)
> +		*val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x2);
> +	else if (drvdata->cmb_esize == 32)
> +		*val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x1);
> +	else if (drvdata->cmb_esize == 8)
> +		*val &= ~TPDA_Pn_CR_CMBSIZE;
> +}
> +


>   /*
> - * Read the DSB element size from the TPDM device
> + * Read the element size from the TPDM device
>    * Returns
> - *    The dsb element size read from the devicetree if available.
> + *    The element size read from the devicetree if available.
>    *    0 - Otherwise, with a warning once.

This doesn't match the function ? It return 0 on success and
error (-EINVAL) on failure ?

>    */
> -static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
> +static int tpdm_read_element_size(struct tpda_drvdata *drvdata,
> +				  struct coresight_device *csdev)
>   {
> -	int rc = 0;
> -	u8 size = 0;
> -
> -	rc = fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
> -			"qcom,dsb-element-size", &size);
> +	int rc = -EINVAL;
> +
> +	if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
> +			"qcom,dsb-element-size", &drvdata->dsb_esize))
> +		rc = 0;
> +	if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
> +			"qcom,cmb-element-size", &drvdata->cmb_esize))
> +		rc = 0;

Are we not silently resetting the error if the former failed ?

Could we not :

	rc |= fwnode_...

	rc |= fwnode_...

instead ?

Also what is the expectation here ? Are these properties a MUST for
TPDM ?

>   	if (rc)
>   		dev_warn_once(&csdev->dev,
> -			"Failed to read TPDM DSB Element size: %d\n", rc);
> +			"Failed to read TPDM Element size: %d\n", rc);
>   
> -	return size;
> +	return rc;
>   }
>   
>   /*
> @@ -56,11 +86,12 @@ static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
>    * Parameter "inport" is used to pass in the input port number
>    * of TPDA, and it is set to -1 in the recursize call.
>    */
> -static int tpda_get_element_size(struct coresight_device *csdev,
> +static int tpda_get_element_size(struct tpda_drvdata *drvdata,
> +				 struct coresight_device *csdev,
>   				 int inport)
>   {
> -	int dsb_size = -ENOENT;
> -	int i, size;
> +	int rc = 0;
> +	int i;
>   	struct coresight_device *in;
>   
>   	for (i = 0; i < csdev->pdata->nr_inconns; i++) {
> @@ -74,25 +105,21 @@ static int tpda_get_element_size(struct coresight_device *csdev,
>   			continue;
>   
>   		if (coresight_device_is_tpdm(in)) {
> -			size = tpdm_read_dsb_element_size(in);
> +			if ((drvdata->dsb_esize) || (drvdata->cmb_esize))
> +				return -EEXIST;
> +			rc = tpdm_read_element_size(drvdata, in);
> +			if (rc)
> +				return rc;
>   		} else {
>   			/* Recurse down the path */
> -			size = tpda_get_element_size(in, -1);
> -		}
> -
> -		if (size < 0)
> -			return size;
> -
> -		if (dsb_size < 0) {
> -			/* Found a size, save it. */
> -			dsb_size = size;
> -		} else {
> -			/* Found duplicate TPDMs */
> -			return -EEXIST;
> +			rc = tpda_get_element_size(drvdata, in, -1);
> +			if (rc)
> +				return rc;
>   		}
>   	}
>   
> -	return dsb_size;
> +
> +	return rc;
>   }
>   
>   /* Settings pre enabling port control register */
> @@ -109,7 +136,7 @@ static void tpda_enable_pre_port(struct tpda_drvdata *drvdata)
>   static int tpda_enable_port(struct tpda_drvdata *drvdata, int port)
>   {
>   	u32 val;
> -	int size;
> +	int rc;
>   
>   	val = readl_relaxed(drvdata->base + TPDA_Pn_CR(port));
>   	/*
> @@ -117,29 +144,21 @@ static int tpda_enable_port(struct tpda_drvdata *drvdata, int port)
>   	 * Set the bit to 0 if the size is 32
>   	 * Set the bit to 1 if the size is 64
>   	 */
> -	size = tpda_get_element_size(drvdata->csdev, port);
> -	switch (size) {
> -	case 32:
> -		val &= ~TPDA_Pn_CR_DSBSIZE;
> -		break;
> -	case 64:
> -		val |= TPDA_Pn_CR_DSBSIZE;
> -		break;
> -	case 0:
> -		return -EEXIST;
> -	case -EEXIST:
> +	tpdm_clear_element_size(drvdata->csdev);
> +	rc = tpda_get_element_size(drvdata, drvdata->csdev, port);
> +	if (!rc && ((drvdata->dsb_esize) || (drvdata->cmb_esize))) {
> +		tpda_set_element_size(drvdata, &val);
> +		/* Enable the port */
> +		val |= TPDA_Pn_CR_ENA;
> +		writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
> +	} else if (rc == -EEXIST)
>   		dev_warn_once(&drvdata->csdev->dev,
> -			"Detected multiple TPDMs on port %d", -EEXIST);
> -		return -EEXIST;
> -	default:
> -		return -EINVAL;
> -	}
> -
> -	/* Enable the port */
> -	val |= TPDA_Pn_CR_ENA;
> -	writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
> +			      "Detected multiple TPDMs on port %d", -EEXIST);
> +	else
> +		dev_warn_once(&drvdata->csdev->dev,
> +			      "Didn't find TPDM elem size");

"element size"

>   
> -	return 0;
> +	return rc;
>   }
>   
>   static int __tpda_enable(struct tpda_drvdata *drvdata, int port)
> diff --git a/drivers/hwtracing/coresight/coresight-tpda.h b/drivers/hwtracing/coresight/coresight-tpda.h
> index b3b38fd41b64..29164fd9711f 100644
> --- a/drivers/hwtracing/coresight/coresight-tpda.h
> +++ b/drivers/hwtracing/coresight/coresight-tpda.h
> @@ -10,6 +10,8 @@
>   #define TPDA_Pn_CR(n)		(0x004 + (n * 4))
>   /* Aggregator port enable bit */
>   #define TPDA_Pn_CR_ENA		BIT(0)
> +/* Aggregator port CMB data set element size bit */
> +#define TPDA_Pn_CR_CMBSIZE		GENMASK(7, 6)
>   /* Aggregator port DSB data set element size bit */
>   #define TPDA_Pn_CR_DSBSIZE		BIT(8)
>   
> @@ -25,6 +27,8 @@
>    * @csdev:      component vitals needed by the framework.
>    * @spinlock:   lock for the drvdata value.
>    * @enable:     enable status of the component.
> + * @dsb_esize   Record the DSB element size.
> + * @cmb_esize   Record the CMB element size.
>    */
>   struct tpda_drvdata {
>   	void __iomem		*base;
> @@ -32,6 +36,8 @@ struct tpda_drvdata {
>   	struct coresight_device	*csdev;
>   	spinlock_t		spinlock;
>   	u8			atid;
> +	u8			dsb_esize;
> +	u8			cmb_esize;
>   };
>   
>   #endif  /* _CORESIGHT_CORESIGHT_TPDA_H */

Suzuki




From neil.armstrong at linaro.org  Mon Dec 18 02:30:23 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Mon, 18 Dec 2023 11:30:23 +0100
Subject: [PATCH v2] arm64: defconfig: enable GPU clock controller for
 SM8[45]50
Message-ID: <20231218-topic-sm8x50-upstream-gpucc-defconfig-v2-1-e5892470a10b@linaro.org>

Enable GPU Clock Controller for SM8450 and SM8550 to allow using
Adreno GPU on these SoCs.

Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
---
Changes in v2:
- Switched to =m since there's no reason to keep them built-in
- Link to v1: https://lore.kernel.org/r/20231204-topic-sm8x50-upstream-gpucc-defconfig-v1-1-e615df0c4af9 at linaro.org
---
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5ad2b841aafc..fd59c9ba5983 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1266,6 +1266,8 @@ CONFIG_SM_TCSRCC_8550=y
 CONFIG_SM_GPUCC_6115=m
 CONFIG_SM_GPUCC_8150=y
 CONFIG_SM_GPUCC_8250=y
+CONFIG_SM_GPUCC_8450=m
+CONFIG_SM_GPUCC_8550=m
 CONFIG_SM_VIDEOCC_8250=y
 CONFIG_QCOM_HFPLL=y
 CONFIG_CLK_GFM_LPASS_SM8250=m

---
base-commit: 9046d05c6ad632a271fc4173624e26f396975a80
change-id: 20231204-topic-sm8x50-upstream-gpucc-defconfig-3e3dc264be08

Best regards,
-- 
Neil Armstrong <neil.armstrong at linaro.org>



From suzuki.poulose at arm.com  Mon Dec 18 02:34:26 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 18 Dec 2023 10:34:26 +0000
Subject: [PATCH v3 3/8] coresight-tpdm: Add CMB dataset support
In-Reply-To: <1700533494-19276-4-git-send-email-quic_taozha@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-4-git-send-email-quic_taozha@quicinc.com>
Message-ID: <f4ed3577-f78b-4b78-b306-8284ccb96043@arm.com>

On 21/11/2023 02:24, Tao Zhang wrote:
> CMB (continuous multi-bit) is one of TPDM's dataset type. CMB subunit
> can be enabled for data collection by writing 1 to the first bit of
> CMB_CR register. This change is to add enable/disable function for
> CMB dataset by writing CMB_CR register.
> 
> Reviewed-by: James Clark <james.clark at arm.com>
> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
> ---
>   drivers/hwtracing/coresight/coresight-tpdm.c | 31 ++++++++++++++++++++
>   drivers/hwtracing/coresight/coresight-tpdm.h |  8 +++++
>   2 files changed, 39 insertions(+)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index 97654aa4b772..c8bb38822e08 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -131,6 +131,11 @@ static bool tpdm_has_dsb_dataset(struct tpdm_drvdata *drvdata)
>   	return (drvdata->datasets & TPDM_PIDR0_DS_DSB);
>   }
>   
> +static bool tpdm_has_cmb_dataset(struct tpdm_drvdata *drvdata)
> +{
> +	return (drvdata->datasets & TPDM_PIDR0_DS_CMB);
> +}
> +
>   static umode_t tpdm_dsb_is_visible(struct kobject *kobj,
>   				   struct attribute *attr, int n)
>   {
> @@ -267,6 +272,17 @@ static void tpdm_enable_dsb(struct tpdm_drvdata *drvdata)
>   	writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>   }
>   
> +static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
> +{
> +	u32 val;
> +
> +	val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
> +	val |= TPDM_CMB_CR_ENA;
> +
> +	/* Set the enable bit of CMB control register to 1 */
> +	writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
> +}
> +
>   /*
>    * TPDM enable operations
>    * The TPDM or Monitor serves as data collection component for various
> @@ -281,6 +297,8 @@ static void __tpdm_enable(struct tpdm_drvdata *drvdata)
>   
>   	if (tpdm_has_dsb_dataset(drvdata))
>   		tpdm_enable_dsb(drvdata);
> +	if (tpdm_has_cmb_dataset(drvdata))
> +		tpdm_enable_cmb(drvdata);
>   

Don't we need to add this check in the "property read" section ?
Otherwise, we could generate warnings unnecessarily ?

i.e, if (tpdm_has_cmb_..())
	  rc |= fwnode_..read_property(cmb-elem-size...)

Similarly for DSB.

>   	CS_LOCK(drvdata->base);
>   }
> @@ -314,6 +332,17 @@ static void tpdm_disable_dsb(struct tpdm_drvdata *drvdata)
>   	writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>   }
>   
> +static void tpdm_disable_cmb(struct tpdm_drvdata *drvdata)
> +{
> +	u32 val;
> +
> +	val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
> +	val &= ~TPDM_CMB_CR_ENA;
> +
> +	/* Set the enable bit of CMB control register to 0 */
> +	writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
> +}
> +
>   /* TPDM disable operations */
>   static void __tpdm_disable(struct tpdm_drvdata *drvdata)
>   {
> @@ -321,6 +350,8 @@ static void __tpdm_disable(struct tpdm_drvdata *drvdata)
>   
>   	if (tpdm_has_dsb_dataset(drvdata))
>   		tpdm_disable_dsb(drvdata);
> +	if (tpdm_has_cmb_dataset(drvdata))
> +		tpdm_disable_cmb(drvdata);

minor nit: Instead of having these :

	if (tpdm_has_XY_()
		tpdm_{enable/disable}_XY_()
I prefer :

	tpdm_{enable/disable}_XY_

and the helper take care of returning early if the feature is
not present.


Suzuki


>   
>   	CS_LOCK(drvdata->base);
>   }
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
> index 4115b2a17b8d..0098c58dfdd6 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
> @@ -9,6 +9,12 @@
>   /* The max number of the datasets that TPDM supports */
>   #define TPDM_DATASETS       7
>   
> +/* CMB Subunit Registers */
> +#define TPDM_CMB_CR		(0xA00)
> +
> +/* Enable bit for CMB subunit */
> +#define TPDM_CMB_CR_ENA		BIT(0)
> +
>   /* DSB Subunit Registers */
>   #define TPDM_DSB_CR		(0x780)
>   #define TPDM_DSB_TIER		(0x784)
> @@ -79,10 +85,12 @@
>    *
>    * PERIPHIDR0[0] : Fix to 1 if ImplDef subunit present, else 0
>    * PERIPHIDR0[1] : Fix to 1 if DSB subunit present, else 0
> + * PERIPHIDR0[2] : Fix to 1 if CMB subunit present, else 0
>    */
>   
>   #define TPDM_PIDR0_DS_IMPDEF	BIT(0)
>   #define TPDM_PIDR0_DS_DSB	BIT(1)
> +#define TPDM_PIDR0_DS_CMB	BIT(2)
>   
>   #define TPDM_DSB_MAX_LINES	256
>   /* MAX number of EDCR registers */



From suzuki.poulose at arm.com  Mon Dec 18 02:46:18 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 18 Dec 2023 10:46:18 +0000
Subject: [PATCH v3 6/8] coresight-tpdm: Add timestamp control register
 support for the CMB
In-Reply-To: <1700533494-19276-7-git-send-email-quic_taozha@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-7-git-send-email-quic_taozha@quicinc.com>
Message-ID: <ebd7e310-d1b4-4b2e-a915-6241e04763d4@arm.com>

On 21/11/2023 02:24, Tao Zhang wrote:
> CMB_TIER register is CMB subunit timestamp insertion enable register.
> Bit 0 is PATT_TSENAB bit. Set this bit to 1 to request a timestamp
> following a CMB interface pattern match. Bit 1 is XTRIG_TSENAB bit.
> Set this bit to 1 to request a timestamp following a CMB CTI timestamp
> request. Bit 2 is TS_ALL bit. Set this bit to 1 to request timestamp
> for all packets.
> 
> Reviewed-by: James Clark <james.clark at arm.com>
> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
> ---
>   .../testing/sysfs-bus-coresight-devices-tpdm  |  35 ++++++
>   drivers/hwtracing/coresight/coresight-tpdm.c  | 116 +++++++++++++++++-
>   drivers/hwtracing/coresight/coresight-tpdm.h  |  14 +++
>   3 files changed, 162 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> index 53662ce7c2d0..e0b77107be13 100644
> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> @@ -214,3 +214,38 @@ KernelVersion	6.7
>   Contact:	Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang (QUIC) <quic_taozha at quicinc.com>
>   Description:
>   		(RW) Set/Get the mask of the pattern for the CMB subunit TPDM.
> +
> +What:		/sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
> +Date:		September 2023
> +KernelVersion	6.7
> +Contact:	Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang (QUIC) <quic_taozha at quicinc.com>
> +Description:
> +		(Write) Set the pattern timestamp of CMB tpdm. Read
> +		the pattern timestamp of CMB tpdm.
> +
> +		Accepts only one of the 2 values -  0 or 1.
> +		0 : Disable CMB pattern timestamp.
> +		1 : Enable CMB pattern timestamp.
> +
> +What:		/sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
> +Date:		September 2023
> +KernelVersion	6.7
> +Contact:	Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang (QUIC) <quic_taozha at quicinc.com>
> +Description:
> +		(RW) Set/Get the trigger timestamp of the CMB for tpdm.
> +
> +		Accepts only one of the 2 values -  0 or 1.
> +		0 : Set the CMB trigger type to false
> +		1 : Set the CMB trigger type to true
> +
> +What:		/sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
> +Date:		September 2023
> +KernelVersion	6.7
> +Contact:	Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang (QUIC) <quic_taozha at quicinc.com>
> +Description:
> +		(RW) Read or write the status of timestamp upon all interface.
> +		Only value 0 and 1  can be written to this node. Set this node to 1 to requeset
> +		timestamp to all trace packet.
> +		Accepts only one of the 2 values -  0 or 1.
> +		0 : Disable the timestamp of all trace packets.
> +		1 : Enable the timestamp of all trace packets.
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index 894d4309f1c7..f6cda5616e84 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -331,6 +331,36 @@ static void tpdm_enable_dsb(struct tpdm_drvdata *drvdata)
>   	writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>   }
>   
> +static void set_cmb_tier(struct tpdm_drvdata *drvdata)
> +{
> +	u32 val;
> +
> +	val = readl_relaxed(drvdata->base + TPDM_CMB_TIER);
> +
> +	/* Clear all relevant fields */
> +	val &= ~(TPDM_CMB_TIER_PATT_TSENAB | TPDM_CMB_TIER_TS_ALL |
> +		 TPDM_CMB_TIER_XTRIG_TSENAB);
> +
> +	/* Set pattern timestamp type and enablement */
> +	if (drvdata->cmb->patt_ts)
> +		val |= TPDM_CMB_TIER_PATT_TSENAB;

  -- cut --
> +	else
> +		val &= ~TPDM_CMB_TIER_PATT_TSENAB;


All the else cases in this function are superfluous. Please remove all
of them.

> +
> +	/* Set trigger timestamp */
> +	if (drvdata->cmb->trig_ts)
> +		val |= TPDM_CMB_TIER_XTRIG_TSENAB;
> +	else
> +		val &= ~TPDM_CMB_TIER_XTRIG_TSENAB;
> +
> +	/* Set all timestamp enablement*/
> +	if (drvdata->cmb->ts_all)
> +		val |= TPDM_CMB_TIER_TS_ALL;
> +	else
> +		val &= ~TPDM_CMB_TIER_TS_ALL;
> +	writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
> +}
> +
>   static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>   {
>   	u32 val, i;
> @@ -347,6 +377,8 @@ static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>   			    drvdata->base + TPDM_CMB_XPMR(i));
>   	}
>   
> +	set_cmb_tier(drvdata);
> +
>   	val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>   	/*
>   	 * Set to 0 for continuous CMB collection mode,
> @@ -695,9 +727,17 @@ static ssize_t enable_ts_show(struct device *dev,
>   			      char *buf)
>   {
>   	struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +	ssize_t size = 0;
>   
> -	return sysfs_emit(buf, "%u\n",
> -			 (unsigned int)drvdata->dsb->patt_ts);
> +	if (tpdm_has_dsb_dataset(drvdata))
> +		size = sysfs_emit(buf, "%u\n",
> +				 (unsigned int)drvdata->dsb->patt_ts);
> +
> +	if (tpdm_has_cmb_dataset(drvdata))
> +		size = sysfs_emit(buf, "%u\n",
> +				 (unsigned int)drvdata->cmb->patt_ts);

Why does this need to show two values ? This must only show ONE value.
How you deduce that might be based on the availability of the feature
set. Or store the TS value in the drvdata and use that instead for
controlling CMB/DSB.

Also, the sysfs documentation needs update, if this is going to
control the CMB.

Suzuki


> +
> +	return size;
>   }
>   
>   /*
> @@ -715,8 +755,13 @@ static ssize_t enable_ts_store(struct device *dev,
>   		return -EINVAL;
>   
>   	spin_lock(&drvdata->spinlock);
> -	drvdata->dsb->patt_ts = !!val;
> +	if (tpdm_has_dsb_dataset(drvdata))
> +		drvdata->dsb->patt_ts = !!val;
> +
> +	if (tpdm_has_cmb_dataset(drvdata))
> +		drvdata->cmb->patt_ts = !!val;
>   	spin_unlock(&drvdata->spinlock);
> +
>   	return size;
>   }
>   static DEVICE_ATTR_RW(enable_ts);
> @@ -851,6 +896,68 @@ static ssize_t cmb_mode_store(struct device *dev,
>   }
>   static DEVICE_ATTR_RW(cmb_mode);
>   
> +static ssize_t cmb_ts_all_show(struct device *dev,
> +			       struct device_attribute *attr,
> +			       char *buf)
> +{
> +	struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> +	return sysfs_emit(buf, "%u\n",
> +			  (unsigned int)drvdata->cmb->ts_all);
> +}
> +
> +static ssize_t cmb_ts_all_store(struct device *dev,
> +				struct device_attribute *attr,
> +				const char *buf,
> +				size_t size)
> +{
> +	struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +	unsigned long val;
> +
> +	if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
> +		return -EINVAL;
> +
> +	spin_lock(&drvdata->spinlock);
> +	if (val)
> +		drvdata->cmb->ts_all = true;
> +	else
> +		drvdata->cmb->ts_all = false;
> +	spin_unlock(&drvdata->spinlock);
> +	return size;
> +}
> +static DEVICE_ATTR_RW(cmb_ts_all);
> +
> +static ssize_t cmb_trig_ts_show(struct device *dev,
> +				struct device_attribute *attr,
> +				char *buf)
> +{
> +	struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> +	return sysfs_emit(buf, "%u\n",
> +			  (unsigned int)drvdata->cmb->trig_ts);
> +}
> +
> +static ssize_t cmb_trig_ts_store(struct device *dev,
> +				 struct device_attribute *attr,
> +				 const char *buf,
> +				 size_t size)
> +{
> +	struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +	unsigned long val;
> +
> +	if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
> +		return -EINVAL;
> +
> +	spin_lock(&drvdata->spinlock);
> +	if (val)
> +		drvdata->cmb->trig_ts = true;
> +	else
> +		drvdata->cmb->trig_ts = false;
> +	spin_unlock(&drvdata->spinlock);
> +	return size;
> +}
> +static DEVICE_ATTR_RW(cmb_trig_ts);
> +
>   static struct attribute *tpdm_dsb_edge_attrs[] = {
>   	&dev_attr_ctrl_idx.attr,
>   	&dev_attr_ctrl_val.attr,
> @@ -973,6 +1080,7 @@ static struct attribute *tpdm_cmb_patt_attrs[] = {
>   	CMB_PATT_ATTR(1),
>   	CMB_PATT_MASK_ATTR(0),
>   	CMB_PATT_MASK_ATTR(1),
> +	&dev_attr_enable_ts.attr,
>   	NULL,
>   };
>   
> @@ -985,6 +1093,8 @@ static struct attribute *tpdm_dsb_attrs[] = {
>   
>   static struct attribute *tpdm_cmb_attrs[] = {
>   	&dev_attr_cmb_mode.attr,
> +	&dev_attr_cmb_ts_all.attr,
> +	&dev_attr_cmb_trig_ts.attr,
>   	NULL,
>   };
>   
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
> index e90d008c1cb2..65b7ca6c4077 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
> @@ -11,6 +11,8 @@
>   
>   /* CMB Subunit Registers */
>   #define TPDM_CMB_CR		(0xA00)
> +/*CMB subunit timestamp insertion enable register*/
> +#define TPDM_CMB_TIER		(0xA04)
>   /*CMB subunit timestamp pattern registers*/
>   #define TPDM_CMB_TPR(n)		(0xA08 + (n * 4))
>   /*CMB subunit timestamp pattern mask registers*/
> @@ -24,6 +26,12 @@
>   #define TPDM_CMB_CR_ENA		BIT(0)
>   /* Trace collection mode for CMB subunit */
>   #define TPDM_CMB_CR_MODE	BIT(1)
> +/* Timestamp control for pattern match */
> +#define TPDM_CMB_TIER_PATT_TSENAB	BIT(0)
> +/* CMB CTI timestamp request */
> +#define TPDM_CMB_TIER_XTRIG_TSENAB	BIT(1)
> +/* For timestamp fo all trace */
> +#define TPDM_CMB_TIER_TS_ALL		BIT(2)
>   
>   /*Patten register number*/
>   #define TPDM_CMB_MAX_PATT		2
> @@ -217,6 +225,9 @@ struct dsb_dataset {
>    * @patt_mask:        Save value for pattern mask
>    * @trig_patt:        Save value for trigger pattern
>    * @trig_patt_mask:   Save value for trigger pattern mask
> + * @patt_ts:          Indicates if pattern match for timestamp is enabled.
> + * @trig_ts:          Indicates if CTI trigger for timestamp is enabled.
> + * @ts_all:           Indicates if timestamp is enabled for all packets.
>    */
>   struct cmb_dataset {
>   	u32			trace_mode;
> @@ -224,6 +235,9 @@ struct cmb_dataset {
>   	u32			patt_mask[TPDM_CMB_MAX_PATT];
>   	u32			trig_patt[TPDM_CMB_MAX_PATT];
>   	u32			trig_patt_mask[TPDM_CMB_MAX_PATT];
> +	bool			patt_ts;
> +	bool			trig_ts;
> +	bool			ts_all;
>   };
>   
>   /**



From suzuki.poulose at arm.com  Mon Dec 18 02:47:23 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 18 Dec 2023 10:47:23 +0000
Subject: [PATCH v3 7/8] dt-bindings: arm: Add support for TPDM CMB MSR
 register
In-Reply-To: <e5fbbfab-02bf-4eda-8353-87c54c307af1@linaro.org>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-8-git-send-email-quic_taozha@quicinc.com>
 <e5fbbfab-02bf-4eda-8353-87c54c307af1@linaro.org>
Message-ID: <1d57590d-2ecf-4bf6-9c8f-2a9d1ba08aaa@arm.com>

Tao Zhang,

On 21/11/2023 07:24, Krzysztof Kozlowski wrote:
> On 21/11/2023 03:24, Tao Zhang wrote:
>> Add property "qcom,cmb_msr_num" to support CMB MSR(mux select register)
>> for TPDM. It specifies the number of CMB MSR registers supported by
>> the TDPM.
>>
>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>> ---
> 
> I prefer not to take any new Qualcomm Coresight bindings or Qualcomm SoC
> DTS nodes with Coresight till we fix all existing warnings. I don't know
> how to fix them, so I need help with them. No such fixing happened so
> far from Qcom, so pushback is my only way to get any attention.
> 
> I already commented on this in other email thread.

Are you addressing this ?

Suzuki

> 
> Best regards,
> Krzysztof
> 



From ryan.roberts at arm.com  Mon Dec 18 02:50:44 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:44 +0000
Subject: [PATCH v4 00/16] Transparent Contiguous PTEs for User Mappings
Message-ID: <20231218105100.172635-1-ryan.roberts@arm.com>

Hi All,

This is a series to opportunistically and transparently use contpte mappings
(set the contiguous bit in ptes) for user memory when those mappings meet the
requirements. It is part of a wider effort to improve performance by allocating
and mapping variable-sized blocks of memory (folios). One aim is for the 4K
kernel to approach the performance of the 16K kernel, but without breaking
compatibility and without the associated increase in memory. Another aim is to
benefit the 16K and 64K kernels by enabling 2M THP, since this is the contpte
size for those kernels. We have good performance data that demonstrates both
aims are being met (see below).

Of course this is only one half of the change. We require the mapped physical
memory to be the correct size and alignment for this to actually be useful (i.e.
64K for 4K pages, or 2M for 16K/64K pages). Fortunately folios are solving this
problem for us. Filesystems that support it (XFS, AFS, EROFS, tmpfs, ...) will
allocate large folios up to the PMD size today, and more filesystems are coming.
And the other half of my work, to enable "multi-size THP" (large folios) for
anonymous memory, makes contpte sized folios prevalent for anonymous memory too
[4].

Note that the first 3 patchs are for core-mm and provides the refactoring to
make some crucial optimizations possible - which are then implemented in patches
15 and 16. The remaining patches are arm64-specific.


Testing
=======

I've tested this series together with multi-size THP [4] on both Ampere Altra
(bare metal) and Apple M2 (VM):
  - mm selftests (inc new tests written for multi-size THP); no regressions
  - Speedometer Java script benchmark in Chromium web browser; no issues
  - Kernel compilation; no issues
  - Various tests under high memory pressure with swap enabled; no issues


Performance
===========

High Level Use Cases
~~~~~~~~~~~~~~~~~~~~

First some high level use cases (kernel compilation and speedometer JavaScript
benchmarks). These are running on Ampere Altra (I've seen similar improvements
on Android/Pixel 6).

baseline:                  mm-unstable (inc mTHP but switched off)
mTHP:                      enable 16K, 32K, 64K mTHP sizes "always"
mTHP + contpte:            + this series
mTHP + contpte + exefolio: + poc patch to always read executable memory from
                           file into 64K folio to enable contpte-mapping the
			   text

Kernel Compilation with -j8 (negative is faster):

| kernel                    | real-time | kern-time | user-time |
|---------------------------|-----------|-----------|-----------|
| baseline                  |      0.0% |      0.0% |      0.0% |
| mTHP                      |     -4.6% |    -38.0% |     -0.4% |
| mTHP + contpte            |     -5.4% |    -37.7% |     -1.3% |
| mTHP + contpte + exefolio |     -7.4% |    -39.5% |     -3.5% |

Kernel Compilation with -j80 (negative is faster):

| kernel                    | real-time | kern-time | user-time |
|---------------------------|-----------|-----------|-----------|
| baseline                  |      0.0% |      0.0% |      0.0% |
| mTHP                      |     -4.9% |    -36.1% |     -0.2% |
| mTHP + contpte            |     -5.8% |    -36.0% |     -1.2% |
| mTHP + contpte + exefolio |     -6.8% |    -37.0% |     -3.1% |

Speedometer (positive is faster):

| kernel                    | runs_per_min |
|:--------------------------|--------------|
| baseline                  |         0.0% |
| mTHP                      |         1.5% |
| mTHP + contpte            |         3.7% |
| mTHP + contpte + exefolio |         4.9% |

Micro Benchmarks
~~~~~~~~~~~~~~~~

Additionally for this version, I've done a significant amount of
microbenchmarking (and fixes!) to ensure the performance of fork(),
madvise(DONTNEED) and munmap() do not regress. Thanks to David for sharing his
benchmarks.

baseline:                  mm-unstable (inc mTHP but switched off)
contpte-dis:               + this series with ARM64_CONTPTE disabled at
                           compile-time (to show impact of the core-mm changes)
contpte-ena:               + ARM64_CONTPTE enabled at compile-time (to show
                           impact of arm64-specific changes)

I'm showing the collated results summary here. See individual patch commit logs
for commentary:

| Apple M2 VM   |       fork        |      dontneed     |       munmap      |
| order-0       |-------------------|-------------------|-------------------|
| (pte-map)     |    mean |   stdev |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|---------|---------|
| baseline      |    0.0% |    1.1% |    0.0% |    7.5% |    0.0% |    3.8% |
| contpte-dis   |   -1.0% |    2.0% |   -9.6% |    3.1% |   -1.9% |    0.2% |
| contpte-ena   |    2.6% |    1.7% |  -10.2% |    1.6% |    1.9% |    0.7% |

| Apple M2 VM   |       fork        |      dontneed     |       munmap      |
| order-9       |-------------------|-------------------|-------------------|
| (pte-map)     |    mean |   stdev |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|---------|---------|
| baseline      |    0.0% |    1.2% |    0.0% |    7.9% |    0.0% |    6.4% |
| contpte-dis   |   -0.1% |    1.1% |   -4.9% |    8.1% |   -4.7% |    0.8% |
| contpte-ena   |  -25.4% |    1.9% |   -9.9% |    0.9% |   -6.0% |    1.4% |

| Ampere Altra  |       fork        |      dontneed     |       munmap      |
| order-0       |-------------------|-------------------|-------------------|
| (pte-map)     |    mean |   stdev |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|---------|---------|
| baseline      |    0.0% |    1.0% |    0.0% |    0.1% |    0.0% |    0.9% |
| contpte-dis   |   -0.1% |    1.2% |   -0.2% |    0.1% |   -0.2% |    0.6% |
| contpte-ena   |    1.8% |    0.7% |    1.3% |    0.0% |    2.0% |    0.4% |

| Ampere Altra  |       fork        |      dontneed     |       munmap      |
| order-9       |-------------------|-------------------|-------------------|
| (pte-map)     |    mean |   stdev |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|---------|---------|
| baseline      |    0.0% |    0.1% |    0.0% |    0.0% |    0.0% |    0.1% |
| contpte-dis   |   -0.1% |    0.1% |   -0.1% |    0.0% |   -3.2% |    0.2% |
| contpte-ena   |   -6.7% |    0.1% |   14.1% |    0.0% |   -0.6% |    0.2% |

Misc
~~~~

John Hubbard at Nvidia has indicated dramatic 10x performance improvements for
some workloads at [5], when using 64K base page kernel.

---
All dependencies listed against v1 are now resolved; This series applies cleanly
against v6.7-rc1 and against mm-unstable as of a few days ago (3ecae30dda24).

Changes since v3 [3]
====================

  - Added v3#1 to batch set_ptes() when splitting a huge pmd to ptes; avoids
    need to fold contpte blocks for perf improvement
  - Separated the clear_ptes() fast path into its own inline function (Alistair)
  - Reworked core-mm changes to copy_present_ptes() and zap_pte_range() to
    remove overhead when memory is all order-0 folios (for arm64 and !arm64)
  - Significant optimization of arm64 backend fork operations (set_ptes_full()
    and set_wrprotects()) to ensure no regression when memory is order-0 folios.
  - fixed local variable declarations to be reverse xmas tree. - Added
    documentation for the new backend APIs (pte_batch_remaining(),
    set_ptes_full(), clear_ptes(), ptep_set_wrprotects())
  - Renamed tlb_get_guaranteed_space() -> tlb_reserve_space() and pass requested
    number of slots. Avoids allocating memory when not needed; perf improvement.


Changes since v2 [2]
====================

  - Removed contpte_ptep_get_and_clear_full() optimisation for exit() (v2#14),
    and replaced with a batch-clearing approach using a new arch helper,
    clear_ptes() (v3#2 and v3#15) (Alistair and Barry)
  - (v2#1 / v3#1)
      - Fixed folio refcounting so that refcount >= mapcount always (DavidH)
      - Reworked batch demarcation to avoid pte_pgprot() (DavidH)
      - Reverted return semantic of copy_present_page() and instead fix it up in
        copy_present_ptes() (Alistair)
      - Removed page_cont_mapped_vaddr() and replaced with simpler logic
        (Alistair)
      - Made batch accounting clearer in copy_pte_range() (Alistair)
  - (v2#12 / v3#13)
      - Renamed contpte_fold() -> contpte_convert() and hoisted setting/
        clearing CONT_PTE bit to higher level (Alistair)


Changes since v1 [1]
====================

  - Export contpte_* symbols so that modules can continue to call inline
    functions (e.g. ptep_get) which may now call the contpte_* functions (thanks
    to JohnH)
  - Use pte_valid() instead of pte_present() where sensible (thanks to Catalin)
  - Factor out (pte_valid() && pte_cont()) into new pte_valid_cont() helper
    (thanks to Catalin)
  - Fixed bug in contpte_ptep_set_access_flags() where TLBIs were missed (thanks
    to Catalin)
  - Added ARM64_CONTPTE expert Kconfig (enabled by default) (thanks to Anshuman)
  - Simplified contpte_ptep_get_and_clear_full()
  - Improved various code comments


[1] https://lore.kernel.org/linux-arm-kernel/20230622144210.2623299-1-ryan.roberts at arm.com/
[2] https://lore.kernel.org/linux-arm-kernel/20231115163018.1303287-1-ryan.roberts at arm.com/
[3] https://lore.kernel.org/linux-arm-kernel/20231204105440.61448-1-ryan.roberts at arm.com/
[4] https://lore.kernel.org/linux-arm-kernel/20231204102027.57185-1-ryan.roberts at arm.com/
[5] https://lore.kernel.org/linux-mm/c507308d-bdd4-5f9e-d4ff-e96e4520be85 at nvidia.com/


Thanks,
Ryan

Ryan Roberts (16):
  mm: thp: Batch-collapse PMD with set_ptes()
  mm: Batch-copy PTE ranges during fork()
  mm: Batch-clear PTE ranges during zap_pte_range()
  arm64/mm: set_pte(): New layer to manage contig bit
  arm64/mm: set_ptes()/set_pte_at(): New layer to manage contig bit
  arm64/mm: pte_clear(): New layer to manage contig bit
  arm64/mm: ptep_get_and_clear(): New layer to manage contig bit
  arm64/mm: ptep_test_and_clear_young(): New layer to manage contig bit
  arm64/mm: ptep_clear_flush_young(): New layer to manage contig bit
  arm64/mm: ptep_set_wrprotect(): New layer to manage contig bit
  arm64/mm: ptep_set_access_flags(): New layer to manage contig bit
  arm64/mm: ptep_get(): New layer to manage contig bit
  arm64/mm: Split __flush_tlb_range() to elide trailing DSB
  arm64/mm: Wire up PTE_CONT for user mappings
  arm64/mm: Implement new helpers to optimize fork()
  arm64/mm: Implement clear_ptes() to optimize exit, munmap, dontneed

 arch/arm64/Kconfig                |  10 +-
 arch/arm64/include/asm/pgtable.h  | 384 +++++++++++++++++++++---
 arch/arm64/include/asm/tlbflush.h |  13 +-
 arch/arm64/kernel/efi.c           |   4 +-
 arch/arm64/kernel/mte.c           |   2 +-
 arch/arm64/kvm/guest.c            |   2 +-
 arch/arm64/mm/Makefile            |   1 +
 arch/arm64/mm/contpte.c           | 480 ++++++++++++++++++++++++++++++
 arch/arm64/mm/fault.c             |  12 +-
 arch/arm64/mm/fixmap.c            |   4 +-
 arch/arm64/mm/hugetlbpage.c       |  40 +--
 arch/arm64/mm/kasan_init.c        |   6 +-
 arch/arm64/mm/mmu.c               |  16 +-
 arch/arm64/mm/pageattr.c          |   6 +-
 arch/arm64/mm/trans_pgd.c         |   6 +-
 include/asm-generic/tlb.h         |  11 +
 include/linux/pgtable.h           | 123 ++++++++
 mm/huge_memory.c                  |  59 ++--
 mm/memory.c                       | 156 ++++++----
 mm/mmu_gather.c                   |  15 +
 20 files changed, 1182 insertions(+), 168 deletions(-)
 create mode 100644 arch/arm64/mm/contpte.c

--
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:45 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:45 +0000
Subject: [PATCH v4 01/16] mm: thp: Batch-collapse PMD with set_ptes()
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-2-ryan.roberts@arm.com>

Refactor __split_huge_pmd_locked() so that a present PMD can be
collapsed to PTEs in a single batch using set_ptes(). It also provides a
future opportunity to batch-add the folio to the rmap using David's new
batched rmap APIs.

This should improve performance a little bit, but the real motivation is
to remove the need for the arm64 backend to have to fold the contpte
entries. Instead, since the ptes are set as a batch, the contpte blocks
can be initially set up pre-folded (once the arm64 contpte support is
added in the next few patches). This leads to noticeable performance
improvement during split.

Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 mm/huge_memory.c | 59 ++++++++++++++++++++++++++++--------------------
 1 file changed, 34 insertions(+), 25 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 6be1a380a298..fbf7e95ea983 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2535,15 +2535,16 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
 
 	pte = pte_offset_map(&_pmd, haddr);
 	VM_BUG_ON(!pte);
-	for (i = 0, addr = haddr; i < HPAGE_PMD_NR; i++, addr += PAGE_SIZE) {
-		pte_t entry;
-		/*
-		 * Note that NUMA hinting access restrictions are not
-		 * transferred to avoid any possibility of altering
-		 * permissions across VMAs.
-		 */
-		if (freeze || pmd_migration) {
+
+	/*
+	 * Note that NUMA hinting access restrictions are not transferred to
+	 * avoid any possibility of altering permissions across VMAs.
+	 */
+	if (freeze || pmd_migration) {
+		for (i = 0, addr = haddr; i < HPAGE_PMD_NR; i++, addr += PAGE_SIZE) {
+			pte_t entry;
 			swp_entry_t swp_entry;
+
 			if (write)
 				swp_entry = make_writable_migration_entry(
 							page_to_pfn(page + i));
@@ -2562,28 +2563,36 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
 				entry = pte_swp_mksoft_dirty(entry);
 			if (uffd_wp)
 				entry = pte_swp_mkuffd_wp(entry);
-		} else {
-			entry = mk_pte(page + i, READ_ONCE(vma->vm_page_prot));
-			if (write)
-				entry = pte_mkwrite(entry, vma);
+
+			VM_WARN_ON(!pte_none(ptep_get(pte + i)));
+			set_pte_at(mm, addr, pte + i, entry);
+		}
+	} else {
+		pte_t entry;
+
+		entry = mk_pte(page, READ_ONCE(vma->vm_page_prot));
+		if (write)
+			entry = pte_mkwrite(entry, vma);
+		if (!young)
+			entry = pte_mkold(entry);
+		/* NOTE: this may set soft-dirty too on some archs */
+		if (dirty)
+			entry = pte_mkdirty(entry);
+		if (soft_dirty)
+			entry = pte_mksoft_dirty(entry);
+		if (uffd_wp)
+			entry = pte_mkuffd_wp(entry);
+
+		for (i = 0, addr = haddr; i < HPAGE_PMD_NR; i++, addr += PAGE_SIZE) {
 			if (anon_exclusive)
 				SetPageAnonExclusive(page + i);
-			if (!young)
-				entry = pte_mkold(entry);
-			/* NOTE: this may set soft-dirty too on some archs */
-			if (dirty)
-				entry = pte_mkdirty(entry);
-			if (soft_dirty)
-				entry = pte_mksoft_dirty(entry);
-			if (uffd_wp)
-				entry = pte_mkuffd_wp(entry);
 			page_add_anon_rmap(page + i, vma, addr, RMAP_NONE);
+			VM_WARN_ON(!pte_none(ptep_get(pte + i)));
 		}
-		VM_BUG_ON(!pte_none(ptep_get(pte)));
-		set_pte_at(mm, addr, pte, entry);
-		pte++;
+
+		set_ptes(mm, haddr, pte, entry, HPAGE_PMD_NR);
 	}
-	pte_unmap(pte - 1);
+	pte_unmap(pte);
 
 	if (!pmd_migration)
 		page_remove_rmap(page, vma, true);
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:46 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:46 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-3-ryan.roberts@arm.com>

Convert copy_pte_range() to copy a batch of ptes in one go. A given
batch is determined by the architecture with the new helper,
pte_batch_remaining(), and maps a physically contiguous block of memory,
all belonging to the same folio. A pte batch is then write-protected in
one go in the parent using the new helper, ptep_set_wrprotects() and is
set in one go in the child using the new helper, set_ptes_full().

The primary motivation for this change is to reduce the number of tlb
maintenance operations that the arm64 backend has to perform during
fork, as it is about to add transparent support for the "contiguous bit"
in its ptes. By write-protecting the parent using the new
ptep_set_wrprotects() (note the 's' at the end) function, the backend
can avoid having to unfold contig ranges of PTEs, which is expensive,
when all ptes in the range are being write-protected. Similarly, by
using set_ptes_full() rather than set_pte_at() to set up ptes in the
child, the backend does not need to fold a contiguous range once they
are all populated - they can be initially populated as a contiguous
range in the first place.

This code is very performance sensitive, and a significant amount of
effort has been put into not regressing performance for the order-0
folio case. By default, pte_batch_remaining() is compile constant 1,
which enables the compiler to simplify the extra loops that are added
for batching and produce code that is equivalent (and equally
performant) as the previous implementation.

This change addresses the core-mm refactoring only and a separate change
will implement pte_batch_remaining(), ptep_set_wrprotects() and
set_ptes_full() in the arm64 backend to realize the performance
improvement as part of the work to enable contpte mappings.

To ensure the arm64 is performant once implemented, this change is very
careful to only call ptep_get() once per pte batch.

The following microbenchmark results demonstate that there is no
significant performance change after this patch. Fork is called in a
tight loop in a process with 1G of populated memory and the time for the
function to execute is measured. 100 iterations per run, 8 runs
performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
performed for case where 1G memory is comprised of order-0 folios and
case where comprised of pte-mapped order-9 folios. Negative is faster,
positive is slower, compared to baseline upon which the series is based:

| Apple M2 VM   | order-0 (pte-map) | order-9 (pte-map) |
| fork          |-------------------|-------------------|
| microbench    |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|
| baseline      |    0.0% |    1.1% |    0.0% |    1.2% |
| after-change  |   -1.0% |    2.0% |   -0.1% |    1.1% |

| Ampere Altra  | order-0 (pte-map) | order-9 (pte-map) |
| fork          |-------------------|-------------------|
| microbench    |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|
| baseline      |    0.0% |    1.0% |    0.0% |    0.1% |
| after-change  |   -0.1% |    1.2% |   -0.1% |    0.1% |

Tested-by: John Hubbard <jhubbard at nvidia.com>
Reviewed-by: Alistair Popple <apopple at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
 mm/memory.c             | 92 ++++++++++++++++++++++++++---------------
 2 files changed, 139 insertions(+), 33 deletions(-)

diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index af7639c3b0a3..db93fb81465a 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
 #define arch_flush_lazy_mmu_mode()	do {} while (0)
 #endif
 
+#ifndef pte_batch_remaining
+/**
+ * pte_batch_remaining - Number of pages from addr to next batch boundary.
+ * @pte: Page table entry for the first page.
+ * @addr: Address of the first page.
+ * @end: Batch ceiling (e.g. end of vma).
+ *
+ * Some architectures (arm64) can efficiently modify a contiguous batch of ptes.
+ * In such cases, this function returns the remaining number of pages to the end
+ * of the current batch, as defined by addr. This can be useful when iterating
+ * over ptes.
+ *
+ * May be overridden by the architecture, else batch size is always 1.
+ */
+static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long addr,
+						unsigned long end)
+{
+	return 1;
+}
+#endif
+
 #ifndef set_ptes
 
 #ifndef pte_next_pfn
@@ -246,6 +267,34 @@ static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
 #endif
 #define set_pte_at(mm, addr, ptep, pte) set_ptes(mm, addr, ptep, pte, 1)
 
+#ifndef set_ptes_full
+/**
+ * set_ptes_full - Map consecutive pages to a contiguous range of addresses.
+ * @mm: Address space to map the pages into.
+ * @addr: Address to map the first page at.
+ * @ptep: Page table pointer for the first entry.
+ * @pte: Page table entry for the first page.
+ * @nr: Number of pages to map.
+ * @full: True if systematically setting all ptes and their previous values
+ *        were known to be none (e.g. part of fork).
+ *
+ * Some architectures (arm64) can optimize the implementation if copying ptes
+ * batach-by-batch from the parent, where a batch is defined by
+ * pte_batch_remaining().
+ *
+ * May be overridden by the architecture, else full is ignored and call is
+ * forwarded to set_ptes().
+ *
+ * Context: The caller holds the page table lock.  The pages all belong to the
+ * same folio.  The PTEs are all in the same PMD.
+ */
+static inline void set_ptes_full(struct mm_struct *mm, unsigned long addr,
+		pte_t *ptep, pte_t pte, unsigned int nr, int full)
+{
+	set_ptes(mm, addr, ptep, pte, nr);
+}
+#endif
+
 #ifndef __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 extern int ptep_set_access_flags(struct vm_area_struct *vma,
 				 unsigned long address, pte_t *ptep,
@@ -622,6 +671,37 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres
 }
 #endif
 
+#ifndef ptep_set_wrprotects
+struct mm_struct;
+/**
+ * ptep_set_wrprotects - Write protect a consecutive set of pages.
+ * @mm: Address space that the pages are mapped into.
+ * @address: Address of first page to write protect.
+ * @ptep: Page table pointer for the first entry.
+ * @nr: Number of pages to write protect.
+ * @full: True if systematically wite protecting all ptes (e.g. part of fork).
+ *
+ * Some architectures (arm64) can optimize the implementation if
+ * write-protecting ptes batach-by-batch, where a batch is defined by
+ * pte_batch_remaining().
+ *
+ * May be overridden by the architecture, else implemented as a loop over
+ * ptep_set_wrprotect().
+ *
+ * Context: The caller holds the page table lock. The PTEs are all in the same
+ * PMD.
+ */
+static inline void ptep_set_wrprotects(struct mm_struct *mm,
+				unsigned long address, pte_t *ptep,
+				unsigned int nr, int full)
+{
+	unsigned int i;
+
+	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
+		ptep_set_wrprotect(mm, address, ptep);
+}
+#endif
+
 /*
  * On some architectures hardware does not set page access bit when accessing
  * memory page, it is responsibility of software setting this bit. It brings
diff --git a/mm/memory.c b/mm/memory.c
index 809746555827..111f8feeb56e 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -929,42 +929,60 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
 }
 
 /*
- * Copy one pte.  Returns 0 if succeeded, or -EAGAIN if one preallocated page
- * is required to copy this pte.
+ * Copy set of contiguous ptes.  Returns number of ptes copied if succeeded
+ * (always gte 1), or -EAGAIN if one preallocated page is required to copy the
+ * first pte.
  */
 static inline int
-copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
-		 pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
-		 struct folio **prealloc)
+copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
+		  pte_t *dst_pte, pte_t *src_pte, pte_t pte,
+		  unsigned long addr, unsigned long end,
+		  int *rss, struct folio **prealloc)
 {
 	struct mm_struct *src_mm = src_vma->vm_mm;
 	unsigned long vm_flags = src_vma->vm_flags;
-	pte_t pte = ptep_get(src_pte);
 	struct page *page;
 	struct folio *folio;
+	int nr, i, ret;
+
+	nr = pte_batch_remaining(pte, addr, end);
 
 	page = vm_normal_page(src_vma, addr, pte);
-	if (page)
+	if (page) {
 		folio = page_folio(page);
+		folio_ref_add(folio, nr);
+	}
 	if (page && folio_test_anon(folio)) {
-		/*
-		 * If this page may have been pinned by the parent process,
-		 * copy the page immediately for the child so that we'll always
-		 * guarantee the pinned page won't be randomly replaced in the
-		 * future.
-		 */
-		folio_get(folio);
-		if (unlikely(page_try_dup_anon_rmap(page, false, src_vma))) {
-			/* Page may be pinned, we have to copy. */
-			folio_put(folio);
-			return copy_present_page(dst_vma, src_vma, dst_pte, src_pte,
-						 addr, rss, prealloc, page);
+		for (i = 0; i < nr; i++, page++) {
+			/*
+			 * If this page may have been pinned by the parent
+			 * process, copy the page immediately for the child so
+			 * that we'll always guarantee the pinned page won't be
+			 * randomly replaced in the future.
+			 */
+			if (unlikely(page_try_dup_anon_rmap(page, false, src_vma))) {
+				if (i != 0)
+					break;
+				/* Page may be pinned, we have to copy. */
+				folio_ref_sub(folio, nr);
+				ret = copy_present_page(dst_vma, src_vma,
+							dst_pte, src_pte, addr,
+							rss, prealloc, page);
+				return ret == 0 ? 1 : ret;
+			}
+			VM_BUG_ON(PageAnonExclusive(page));
 		}
-		rss[MM_ANONPAGES]++;
+
+		if (unlikely(i < nr)) {
+			folio_ref_sub(folio, nr - i);
+			nr = i;
+		}
+
+		rss[MM_ANONPAGES] += nr;
 	} else if (page) {
-		folio_get(folio);
-		page_dup_file_rmap(page, false);
-		rss[mm_counter_file(page)]++;
+		for (i = 0; i < nr; i++)
+			page_dup_file_rmap(page + i, false);
+		rss[mm_counter_file(page)] += nr;
 	}
 
 	/*
@@ -972,10 +990,9 @@ copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	 * in the parent and the child
 	 */
 	if (is_cow_mapping(vm_flags) && pte_write(pte)) {
-		ptep_set_wrprotect(src_mm, addr, src_pte);
+		ptep_set_wrprotects(src_mm, addr, src_pte, nr, true);
 		pte = pte_wrprotect(pte);
 	}
-	VM_BUG_ON(page && folio_test_anon(folio) && PageAnonExclusive(page));
 
 	/*
 	 * If it's a shared mapping, mark it clean in
@@ -988,8 +1005,8 @@ copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	if (!userfaultfd_wp(dst_vma))
 		pte = pte_clear_uffd_wp(pte);
 
-	set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte);
-	return 0;
+	set_ptes_full(dst_vma->vm_mm, addr, dst_pte, pte, nr, true);
+	return nr;
 }
 
 static inline struct folio *folio_prealloc(struct mm_struct *src_mm,
@@ -1030,6 +1047,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	int rss[NR_MM_COUNTERS];
 	swp_entry_t entry = (swp_entry_t){0};
 	struct folio *prealloc = NULL;
+	int nr_ptes;
 
 again:
 	progress = 0;
@@ -1060,6 +1078,8 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 	arch_enter_lazy_mmu_mode();
 
 	do {
+		nr_ptes = 1;
+
 		/*
 		 * We are holding two locks at this point - either of them
 		 * could generate latencies in another task on another CPU.
@@ -1095,16 +1115,21 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 			 * the now present pte.
 			 */
 			WARN_ON_ONCE(ret != -ENOENT);
+			ret = 0;
 		}
-		/* copy_present_pte() will clear `*prealloc' if consumed */
-		ret = copy_present_pte(dst_vma, src_vma, dst_pte, src_pte,
-				       addr, rss, &prealloc);
+		/* copy_present_ptes() will clear `*prealloc' if consumed */
+		nr_ptes = copy_present_ptes(dst_vma, src_vma, dst_pte, src_pte,
+					    ptent, addr, end, rss, &prealloc);
+
 		/*
 		 * If we need a pre-allocated page for this pte, drop the
 		 * locks, allocate, and try again.
 		 */
-		if (unlikely(ret == -EAGAIN))
+		if (unlikely(nr_ptes == -EAGAIN)) {
+			ret = -EAGAIN;
 			break;
+		}
+
 		if (unlikely(prealloc)) {
 			/*
 			 * pre-alloc page cannot be reused by next time so as
@@ -1115,8 +1140,9 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 			folio_put(prealloc);
 			prealloc = NULL;
 		}
-		progress += 8;
-	} while (dst_pte++, src_pte++, addr += PAGE_SIZE, addr != end);
+		progress += 8 * nr_ptes;
+	} while (dst_pte += nr_ptes, src_pte += nr_ptes,
+		 addr += PAGE_SIZE * nr_ptes, addr != end);
 
 	arch_leave_lazy_mmu_mode();
 	pte_unmap_unlock(orig_src_pte, src_ptl);
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:47 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:47 +0000
Subject: [PATCH v4 03/16] mm: Batch-clear PTE ranges during zap_pte_range()
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-4-ryan.roberts@arm.com>

Convert zap_pte_range() to copy a batch of ptes in one go. A given batch
is determined by the architecture (see pte_batch_remaining()), and maps
a physically contiguous block of memory, all belonging to the same
folio. A pte batch is cleared using the new helper, clear_ptes().

The primary motivation for this change is to reduce the number of tlb
maintenance operations that the arm64 backend has to perform during exit
and other syscalls that cause zap_pte_range() (e.g. munmap,
madvise(DONTNEED), etc.), as it is about to add transparent support for
the "contiguous bit" in its ptes. By clearing ptes using the new
clear_ptes() API, the backend doesn't have to perform an expensive
unfold operation when a PTE being cleared is part of a contpte block.
Instead it can just clear the whole block immediately.

This code is very performance sensitive, and a significant amount of
effort has been put into not regressing performance for the order-0
folio case. By default, pte_batch_remaining() always returns 1, which
enables the compiler to simplify the extra loops that are added for
batching and produce code that is equivalent (and equally performant) as
the previous implementation.

This change addresses the core-mm refactoring only, and introduces
clear_ptes() with a default implementation that calls
ptep_get_and_clear_full() for each pte in the range. Note that this API
returns the pte at the beginning of the batch, but with the dirty and
young bits set if ANY of the ptes in the cleared batch had those bits
set; this information is applied to the folio by the core-mm. Given the
batch is guaranteed to cover only a single folio, collapsing this state
does not lose any useful information.

A separate change will implement clear_ptes() in the arm64 backend to
realize the performance improvement as part of the work to enable
contpte mappings.

The following microbenchmark results demonstate that there is no
madvise(dontneed) performance regression (and actually an improvement in
some cases) after this patch. madvise(dontneed) is called for each page
of a 1G populated mapping and the total time is measured. 100 iterations
per run, 8 runs performed on both Apple M2 (VM) and Ampere Altra (bare
metal). Tests performed for case where 1G memory is comprised of order-0
folios and case where comprised of pte-mapped order-9 folios. Negative
is faster, positive is slower, compared to baseline upon which the
series is based:

| Apple M2 VM   | order-0 (pte-map) | order-9 (pte-map) |
| dontneed      |-------------------|-------------------|
| microbench    |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|
| baseline      |    0.0% |    7.5% |    0.0% |    7.9% |
| after-change  |   -9.6% |    3.1% |   -4.9% |    8.1% |

| Ampere Altra  | order-0 (pte-map) | order-9 (pte-map) |
| dontneed      |-------------------|-------------------|
| microbench    |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|
| baseline      |    0.0% |    0.1% |    0.0% |    0.0% |
| after-change  |   -0.2% |    0.1% |   -0.1% |    0.0% |

The following microbenchmark results demonstate that there is no munmap
performance regression (and actually an improvement in some cases) after
this patch. munmap is called for a 1G populated mapping and the time to
execute the function is measured. 100 iterations per run, 8 runs
performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
performed for case where 1G memory is comprised of order-0 folios and
case where comprised of pte-mapped order-9 folios. Negative is faster,
positive is slower, compared to baseline upon which the series is based:

| Apple M2 VM   | order-0 (pte-map) | order-9 (pte-map) |
| munmap        |-------------------|-------------------|
| microbench    |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|
| baseline      |    0.0% |    3.8% |    0.0% |    6.4% |
| after-change  |   -1.9% |    0.2% |   -4.7% |    0.8% |

| Ampere Altra  | order-0 (pte-map) | order-9 (pte-map) |
| munmap        |-------------------|-------------------|
| microbench    |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|
| baseline      |    0.0% |    0.9% |    0.0% |    0.1% |
| after-change  |   -0.2% |    0.6% |   -3.2% |    0.2% |

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 include/asm-generic/tlb.h | 11 +++++++
 include/linux/pgtable.h   | 43 ++++++++++++++++++++++++++
 mm/memory.c               | 64 ++++++++++++++++++++++++++++-----------
 mm/mmu_gather.c           | 15 +++++++++
 4 files changed, 115 insertions(+), 18 deletions(-)

diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 129a3a759976..1b25929d2000 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -75,6 +75,10 @@
  *    boolean indicating if the queue is (now) full and a call to
  *    tlb_flush_mmu() is required.
  *
+ *    tlb_reserve_space() attempts to preallocate space for nr pages and returns
+ *    the minimum garanteed number of pages that can be queued without overflow,
+ *    which may be more or less than requested.
+ *
  *    tlb_remove_page() and tlb_remove_page_size() imply the call to
  *    tlb_flush_mmu() when required and has no return value.
  *
@@ -263,6 +267,7 @@ struct mmu_gather_batch {
 extern bool __tlb_remove_page_size(struct mmu_gather *tlb,
 				   struct encoded_page *page,
 				   int page_size);
+extern unsigned int tlb_reserve_space(struct mmu_gather *tlb, unsigned int nr);
 
 #ifdef CONFIG_SMP
 /*
@@ -273,6 +278,12 @@ extern bool __tlb_remove_page_size(struct mmu_gather *tlb,
 extern void tlb_flush_rmaps(struct mmu_gather *tlb, struct vm_area_struct *vma);
 #endif
 
+#else
+static inline unsigned int tlb_reserve_space(struct mmu_gather *tlb,
+					     unsigned int nr)
+{
+	return 1;
+}
 #endif
 
 /*
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index db93fb81465a..170925379534 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -601,6 +601,49 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,
 }
 #endif
 
+#ifndef clear_ptes
+struct mm_struct;
+/**
+ * clear_ptes - Clear a consecutive range of ptes and return the previous value.
+ * @mm: Address space that the ptes map.
+ * @address: Address corresponding to the first pte to clear.
+ * @ptep: Page table pointer for the first entry.
+ * @nr: Number of ptes to clear.
+ * @full: True if systematically clearing all ptes for the address space.
+ *
+ * A batched version of ptep_get_and_clear_full(), which returns the old pte
+ * value for the first pte in the range, but with young and/or dirty set if any
+ * of the ptes in the range were young or dirty.
+ *
+ * May be overridden by the architecture, else implemented as a loop over
+ * ptep_get_and_clear_full().
+ *
+ * Context: The caller holds the page table lock. The PTEs are all in the same
+ * PMD.
+ */
+static inline pte_t clear_ptes(struct mm_struct *mm,
+				unsigned long address, pte_t *ptep,
+				unsigned int nr, int full)
+{
+	unsigned int i;
+	pte_t pte;
+	pte_t orig_pte = ptep_get_and_clear_full(mm, address, ptep, full);
+
+	for (i = 1; i < nr; i++) {
+		address += PAGE_SIZE;
+		ptep++;
+		pte = ptep_get_and_clear_full(mm, address, ptep, full);
+
+		if (pte_dirty(pte))
+			orig_pte = pte_mkdirty(orig_pte);
+
+		if (pte_young(pte))
+			orig_pte = pte_mkyoung(orig_pte);
+	}
+
+	return orig_pte;
+}
+#endif
 
 /*
  * If two threads concurrently fault at the same page, the thread that
diff --git a/mm/memory.c b/mm/memory.c
index 111f8feeb56e..81b023cf3182 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1447,6 +1447,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 	pte_t *start_pte;
 	pte_t *pte;
 	swp_entry_t entry;
+	int nr;
 
 	tlb_change_page_size(tlb, PAGE_SIZE);
 	init_rss_vec(rss);
@@ -1459,6 +1460,9 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 	do {
 		pte_t ptent = ptep_get(pte);
 		struct page *page;
+		int i;
+
+		nr = 1;
 
 		if (pte_none(ptent))
 			continue;
@@ -1467,43 +1471,67 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 			break;
 
 		if (pte_present(ptent)) {
-			unsigned int delay_rmap;
+			unsigned int delay_rmap = 0;
+			struct folio *folio;
+			bool full = false;
+
+			/*
+			 * tlb_gather always has at least one slot so avoid call
+			 * to tlb_reserve_space() when pte_batch_remaining() is
+			 * a compile-time constant 1 (default).
+			 */
+			nr = pte_batch_remaining(ptent, addr, end);
+			if (unlikely(nr > 1))
+				nr = min_t(int, nr, tlb_reserve_space(tlb, nr));
 
 			page = vm_normal_page(vma, addr, ptent);
 			if (unlikely(!should_zap_page(details, page)))
 				continue;
-			ptent = ptep_get_and_clear_full(mm, addr, pte,
-							tlb->fullmm);
+			ptent = clear_ptes(mm, addr, pte, nr, tlb->fullmm);
 			arch_check_zapped_pte(vma, ptent);
-			tlb_remove_tlb_entry(tlb, pte, addr);
-			zap_install_uffd_wp_if_needed(vma, addr, pte, details,
-						      ptent);
+
+			for (i = 0; i < nr; i++) {
+				unsigned long subaddr = addr + PAGE_SIZE * i;
+
+				tlb_remove_tlb_entry(tlb, &pte[i], subaddr);
+				zap_install_uffd_wp_if_needed(vma, subaddr,
+						&pte[i], details, ptent);
+			}
 			if (unlikely(!page)) {
 				ksm_might_unmap_zero_page(mm, ptent);
 				continue;
 			}
 
-			delay_rmap = 0;
-			if (!PageAnon(page)) {
+			folio = page_folio(page);
+			if (!folio_test_anon(folio)) {
 				if (pte_dirty(ptent)) {
-					set_page_dirty(page);
+					folio_mark_dirty(folio);
 					if (tlb_delay_rmap(tlb)) {
 						delay_rmap = 1;
 						force_flush = 1;
 					}
 				}
 				if (pte_young(ptent) && likely(vma_has_recency(vma)))
-					mark_page_accessed(page);
+					folio_mark_accessed(folio);
 			}
-			rss[mm_counter(page)]--;
-			if (!delay_rmap) {
-				page_remove_rmap(page, vma, false);
-				if (unlikely(page_mapcount(page) < 0))
-					print_bad_pte(vma, addr, ptent, page);
+			rss[mm_counter(page)] -= nr;
+			for (i = 0; i < nr; i++, page++) {
+				if (!delay_rmap) {
+					page_remove_rmap(page, vma, false);
+					if (unlikely(page_mapcount(page) < 0))
+						print_bad_pte(vma, addr, ptent, page);
+				}
+
+				/*
+				 * nr calculated based on available space, so
+				 * can only be full on final iteration.
+				 */
+				VM_WARN_ON(full);
+				full = __tlb_remove_page(tlb, page, delay_rmap);
 			}
-			if (unlikely(__tlb_remove_page(tlb, page, delay_rmap))) {
+			if (unlikely(full)) {
 				force_flush = 1;
-				addr += PAGE_SIZE;
+				addr += PAGE_SIZE * nr;
 				break;
 			}
 			continue;
@@ -1557,7 +1585,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 		}
 		pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
 		zap_install_uffd_wp_if_needed(vma, addr, pte, details, ptent);
-	} while (pte++, addr += PAGE_SIZE, addr != end);
+	} while (pte += nr, addr += PAGE_SIZE * nr, addr != end);
 
 	add_mm_rss_vec(mm, rss);
 	arch_leave_lazy_mmu_mode();
diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
index 4f559f4ddd21..39725756e6bf 100644
--- a/mm/mmu_gather.c
+++ b/mm/mmu_gather.c
@@ -47,6 +47,21 @@ static bool tlb_next_batch(struct mmu_gather *tlb)
 	return true;
 }
 
+unsigned int tlb_reserve_space(struct mmu_gather *tlb, unsigned int nr)
+{
+	struct mmu_gather_batch *batch = tlb->active;
+	unsigned int nr_alloc = batch->max - batch->nr;
+
+	while (nr_alloc < nr) {
+		if (!tlb_next_batch(tlb))
+			break;
+		nr_alloc += tlb->active->max;
+	}
+
+	tlb->active = batch;
+	return nr_alloc;
+}
+
 #ifdef CONFIG_SMP
 static void tlb_flush_rmap_batch(struct mmu_gather_batch *batch, struct vm_area_struct *vma)
 {
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:48 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:48 +0000
Subject: [PATCH v4 04/16] arm64/mm: set_pte(): New layer to manage contig bit
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-5-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 12 ++++++++----
 arch/arm64/kernel/efi.c          |  2 +-
 arch/arm64/mm/fixmap.c           |  2 +-
 arch/arm64/mm/kasan_init.c       |  4 ++--
 arch/arm64/mm/mmu.c              |  2 +-
 arch/arm64/mm/pageattr.c         |  2 +-
 arch/arm64/mm/trans_pgd.c        |  4 ++--
 7 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b19a8aee684c..650d4f4bb6dc 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -93,7 +93,8 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
 	__pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
 
 #define pte_none(pte)		(!pte_val(pte))
-#define pte_clear(mm,addr,ptep)	set_pte(ptep, __pte(0))
+#define pte_clear(mm, addr, ptep) \
+				__set_pte(ptep, __pte(0))
 #define pte_page(pte)		(pfn_to_page(pte_pfn(pte)))
 
 /*
@@ -261,7 +262,7 @@ static inline pte_t pte_mkdevmap(pte_t pte)
 	return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
 }
 
-static inline void set_pte(pte_t *ptep, pte_t pte)
+static inline void __set_pte(pte_t *ptep, pte_t pte)
 {
 	WRITE_ONCE(*ptep, pte);
 
@@ -350,7 +351,7 @@ static inline void set_ptes(struct mm_struct *mm,
 
 	for (;;) {
 		__check_safe_pte_update(mm, ptep, pte);
-		set_pte(ptep, pte);
+		__set_pte(ptep, pte);
 		if (--nr == 0)
 			break;
 		ptep++;
@@ -534,7 +535,7 @@ static inline void __set_pte_at(struct mm_struct *mm,
 {
 	__sync_cache_and_tags(pte, nr);
 	__check_safe_pte_update(mm, ptep, pte);
-	set_pte(ptep, pte);
+	__set_pte(ptep, pte);
 }
 
 static inline void set_pmd_at(struct mm_struct *mm, unsigned long addr,
@@ -1118,6 +1119,9 @@ extern pte_t ptep_modify_prot_start(struct vm_area_struct *vma,
 extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 				    unsigned long addr, pte_t *ptep,
 				    pte_t old_pte, pte_t new_pte);
+
+#define set_pte					__set_pte
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_H */
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 0228001347be..44288a12fc6c 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -111,7 +111,7 @@ static int __init set_permissions(pte_t *ptep, unsigned long addr, void *data)
 		pte = set_pte_bit(pte, __pgprot(PTE_PXN));
 	else if (system_supports_bti_kernel() && spd->has_bti)
 		pte = set_pte_bit(pte, __pgprot(PTE_GP));
-	set_pte(ptep, pte);
+	__set_pte(ptep, pte);
 	return 0;
 }
 
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index c0a3301203bd..51cd4501816d 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -121,7 +121,7 @@ void __set_fixmap(enum fixed_addresses idx,
 	ptep = fixmap_pte(addr);
 
 	if (pgprot_val(flags)) {
-		set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, flags));
+		__set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, flags));
 	} else {
 		pte_clear(&init_mm, addr, ptep);
 		flush_tlb_kernel_range(addr, addr+PAGE_SIZE);
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 555285ebd5af..5eade712e9e5 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -112,7 +112,7 @@ static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
 		if (!early)
 			memset(__va(page_phys), KASAN_SHADOW_INIT, PAGE_SIZE);
 		next = addr + PAGE_SIZE;
-		set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
+		__set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
 	} while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep)));
 }
 
@@ -266,7 +266,7 @@ static void __init kasan_init_shadow(void)
 	 * so we should make sure that it maps the zero page read-only.
 	 */
 	for (i = 0; i < PTRS_PER_PTE; i++)
-		set_pte(&kasan_early_shadow_pte[i],
+		__set_pte(&kasan_early_shadow_pte[i],
 			pfn_pte(sym_to_pfn(kasan_early_shadow_page),
 				PAGE_KERNEL_RO));
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 15f6347d23b6..e884279b268e 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -178,7 +178,7 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 	do {
 		pte_t old_pte = READ_ONCE(*ptep);
 
-		set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
+		__set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
 
 		/*
 		 * After the PTE entry has been populated once, we
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 924843f1f661..a7996d8edf0a 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -41,7 +41,7 @@ static int change_page_range(pte_t *ptep, unsigned long addr, void *data)
 	pte = clear_pte_bit(pte, cdata->clear_mask);
 	pte = set_pte_bit(pte, cdata->set_mask);
 
-	set_pte(ptep, pte);
+	__set_pte(ptep, pte);
 	return 0;
 }
 
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 7b14df3c6477..230b607cf881 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -41,7 +41,7 @@ static void _copy_pte(pte_t *dst_ptep, pte_t *src_ptep, unsigned long addr)
 		 * read only (code, rodata). Clear the RDONLY bit from
 		 * the temporary mappings we use during restore.
 		 */
-		set_pte(dst_ptep, pte_mkwrite_novma(pte));
+		__set_pte(dst_ptep, pte_mkwrite_novma(pte));
 	} else if ((debug_pagealloc_enabled() ||
 		   is_kfence_address((void *)addr)) && !pte_none(pte)) {
 		/*
@@ -55,7 +55,7 @@ static void _copy_pte(pte_t *dst_ptep, pte_t *src_ptep, unsigned long addr)
 		 */
 		BUG_ON(!pfn_valid(pte_pfn(pte)));
 
-		set_pte(dst_ptep, pte_mkpresent(pte_mkwrite_novma(pte)));
+		__set_pte(dst_ptep, pte_mkpresent(pte_mkwrite_novma(pte)));
 	}
 }
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:49 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:49 +0000
Subject: [PATCH v4 05/16] arm64/mm: set_ptes()/set_pte_at(): New layer to manage contig bit
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-6-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

set_pte_at() is a core macro that forwards to set_ptes() (with nr=1).
Instead of creating a __set_pte_at() internal macro, convert all arch
users to use set_ptes()/__set_ptes() directly, as appropriate. Callers
in hugetlb may benefit from calling __set_ptes() once for their whole
range rather than managing their own loop. This is left for future
improvement.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 10 +++++-----
 arch/arm64/kernel/mte.c          |  2 +-
 arch/arm64/kvm/guest.c           |  2 +-
 arch/arm64/mm/fault.c            |  2 +-
 arch/arm64/mm/hugetlbpage.c      | 10 +++++-----
 5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 650d4f4bb6dc..323ec91add60 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -342,9 +342,9 @@ static inline void __sync_cache_and_tags(pte_t pte, unsigned int nr_pages)
 		mte_sync_tags(pte, nr_pages);
 }
 
-static inline void set_ptes(struct mm_struct *mm,
-			    unsigned long __always_unused addr,
-			    pte_t *ptep, pte_t pte, unsigned int nr)
+static inline void __set_ptes(struct mm_struct *mm,
+			      unsigned long __always_unused addr,
+			      pte_t *ptep, pte_t pte, unsigned int nr)
 {
 	page_table_check_ptes_set(mm, ptep, pte, nr);
 	__sync_cache_and_tags(pte, nr);
@@ -358,7 +358,6 @@ static inline void set_ptes(struct mm_struct *mm,
 		pte_val(pte) += PAGE_SIZE;
 	}
 }
-#define set_ptes set_ptes
 
 /*
  * Huge pte definitions.
@@ -1067,7 +1066,7 @@ static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
 #endif /* CONFIG_ARM64_MTE */
 
 /*
- * On AArch64, the cache coherency is handled via the set_pte_at() function.
+ * On AArch64, the cache coherency is handled via the __set_ptes() function.
  */
 static inline void update_mmu_cache_range(struct vm_fault *vmf,
 		struct vm_area_struct *vma, unsigned long addr, pte_t *ptep,
@@ -1121,6 +1120,7 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 				    pte_t old_pte, pte_t new_pte);
 
 #define set_pte					__set_pte
+#define set_ptes				__set_ptes
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index a41ef3213e1e..dcdcccd40891 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -67,7 +67,7 @@ int memcmp_pages(struct page *page1, struct page *page2)
 	/*
 	 * If the page content is identical but at least one of the pages is
 	 * tagged, return non-zero to avoid KSM merging. If only one of the
-	 * pages is tagged, set_pte_at() may zero or change the tags of the
+	 * pages is tagged, __set_ptes() may zero or change the tags of the
 	 * other page via mte_sync_tags().
 	 */
 	if (page_mte_tagged(page1) || page_mte_tagged(page2))
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index aaf1d4939739..629145fd3161 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -1072,7 +1072,7 @@ int kvm_vm_ioctl_mte_copy_tags(struct kvm *kvm,
 		} else {
 			/*
 			 * Only locking to serialise with a concurrent
-			 * set_pte_at() in the VMM but still overriding the
+			 * __set_ptes() in the VMM but still overriding the
 			 * tags, hence ignoring the return value.
 			 */
 			try_page_mte_tagging(page);
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 460d799e1296..a287c1dea871 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -205,7 +205,7 @@ static void show_pte(unsigned long addr)
  *
  * It needs to cope with hardware update of the accessed/dirty state by other
  * agents in the system and can safely skip the __sync_icache_dcache() call as,
- * like set_pte_at(), the PTE is never changed from no-exec to exec here.
+ * like __set_ptes(), the PTE is never changed from no-exec to exec here.
  *
  * Returns whether or not the PTE actually changed.
  */
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index f5aae342632c..741cb53672fd 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -254,12 +254,12 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
 
 	if (!pte_present(pte)) {
 		for (i = 0; i < ncontig; i++, ptep++, addr += pgsize)
-			set_pte_at(mm, addr, ptep, pte);
+			__set_ptes(mm, addr, ptep, pte, 1);
 		return;
 	}
 
 	if (!pte_cont(pte)) {
-		set_pte_at(mm, addr, ptep, pte);
+		__set_ptes(mm, addr, ptep, pte, 1);
 		return;
 	}
 
@@ -270,7 +270,7 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
 	clear_flush(mm, addr, ptep, pgsize, ncontig);
 
 	for (i = 0; i < ncontig; i++, ptep++, addr += pgsize, pfn += dpfn)
-		set_pte_at(mm, addr, ptep, pfn_pte(pfn, hugeprot));
+		__set_ptes(mm, addr, ptep, pfn_pte(pfn, hugeprot), 1);
 }
 
 pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
@@ -478,7 +478,7 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
 
 	hugeprot = pte_pgprot(pte);
 	for (i = 0; i < ncontig; i++, ptep++, addr += pgsize, pfn += dpfn)
-		set_pte_at(mm, addr, ptep, pfn_pte(pfn, hugeprot));
+		__set_ptes(mm, addr, ptep, pfn_pte(pfn, hugeprot), 1);
 
 	return 1;
 }
@@ -507,7 +507,7 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
 	pfn = pte_pfn(pte);
 
 	for (i = 0; i < ncontig; i++, ptep++, addr += pgsize, pfn += dpfn)
-		set_pte_at(mm, addr, ptep, pfn_pte(pfn, hugeprot));
+		__set_ptes(mm, addr, ptep, pfn_pte(pfn, hugeprot), 1);
 }
 
 pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:50 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:50 +0000
Subject: [PATCH v4 06/16] arm64/mm: pte_clear(): New layer to manage contig bit
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-7-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 3 ++-
 arch/arm64/mm/fixmap.c           | 2 +-
 arch/arm64/mm/hugetlbpage.c      | 2 +-
 arch/arm64/mm/mmu.c              | 2 +-
 4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 323ec91add60..1464e990580a 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -93,7 +93,7 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
 	__pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
 
 #define pte_none(pte)		(!pte_val(pte))
-#define pte_clear(mm, addr, ptep) \
+#define __pte_clear(mm, addr, ptep) \
 				__set_pte(ptep, __pte(0))
 #define pte_page(pte)		(pfn_to_page(pte_pfn(pte)))
 
@@ -1121,6 +1121,7 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 
 #define set_pte					__set_pte
 #define set_ptes				__set_ptes
+#define pte_clear				__pte_clear
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index 51cd4501816d..bfc02568805a 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -123,7 +123,7 @@ void __set_fixmap(enum fixed_addresses idx,
 	if (pgprot_val(flags)) {
 		__set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, flags));
 	} else {
-		pte_clear(&init_mm, addr, ptep);
+		__pte_clear(&init_mm, addr, ptep);
 		flush_tlb_kernel_range(addr, addr+PAGE_SIZE);
 	}
 }
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 741cb53672fd..510b2d4b89a9 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -400,7 +400,7 @@ void huge_pte_clear(struct mm_struct *mm, unsigned long addr,
 	ncontig = num_contig_ptes(sz, &pgsize);
 
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++)
-		pte_clear(mm, addr, ptep);
+		__pte_clear(mm, addr, ptep);
 }
 
 pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index e884279b268e..080e9b50f595 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -859,7 +859,7 @@ static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
 			continue;
 
 		WARN_ON(!pte_present(pte));
-		pte_clear(&init_mm, addr, ptep);
+		__pte_clear(&init_mm, addr, ptep);
 		flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
 		if (free_mapped)
 			free_hotplug_page_range(pte_page(pte),
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:51 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:51 +0000
Subject: [PATCH v4 07/16] arm64/mm: ptep_get_and_clear(): New layer to manage contig bit
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-8-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 5 +++--
 arch/arm64/mm/hugetlbpage.c      | 6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 1464e990580a..994597a0bb0f 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -941,8 +941,7 @@ static inline int pmdp_test_and_clear_young(struct vm_area_struct *vma,
 }
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
-#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
-static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
+static inline pte_t __ptep_get_and_clear(struct mm_struct *mm,
 				       unsigned long address, pte_t *ptep)
 {
 	pte_t pte = __pte(xchg_relaxed(&pte_val(*ptep), 0));
@@ -1122,6 +1121,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define set_pte					__set_pte
 #define set_ptes				__set_ptes
 #define pte_clear				__pte_clear
+#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
+#define ptep_get_and_clear			__ptep_get_and_clear
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 510b2d4b89a9..c2a753541d13 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -188,7 +188,7 @@ static pte_t get_clear_contig(struct mm_struct *mm,
 	unsigned long i;
 
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++) {
-		pte_t pte = ptep_get_and_clear(mm, addr, ptep);
+		pte_t pte = __ptep_get_and_clear(mm, addr, ptep);
 
 		/*
 		 * If HW_AFDBM is enabled, then the HW could turn on
@@ -236,7 +236,7 @@ static void clear_flush(struct mm_struct *mm,
 	unsigned long i, saddr = addr;
 
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++)
-		ptep_clear(mm, addr, ptep);
+		__ptep_get_and_clear(mm, addr, ptep);
 
 	flush_tlb_range(&vma, saddr, addr);
 }
@@ -411,7 +411,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
 	pte_t orig_pte = ptep_get(ptep);
 
 	if (!pte_cont(orig_pte))
-		return ptep_get_and_clear(mm, addr, ptep);
+		return __ptep_get_and_clear(mm, addr, ptep);
 
 	ncontig = find_num_contig(mm, addr, ptep, &pgsize);
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:52 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:52 +0000
Subject: [PATCH v4 08/16] arm64/mm: ptep_test_and_clear_young(): New layer to manage contig bit
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-9-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 994597a0bb0f..9b4a9909fd5b 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -887,8 +887,9 @@ static inline bool pud_user_accessible_page(pud_t pud)
 /*
  * Atomic pte/pmd modifications.
  */
-#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
-static inline int __ptep_test_and_clear_young(pte_t *ptep)
+static inline int __ptep_test_and_clear_young(struct vm_area_struct *vma,
+					      unsigned long address,
+					      pte_t *ptep)
 {
 	pte_t old_pte, pte;
 
@@ -903,18 +904,11 @@ static inline int __ptep_test_and_clear_young(pte_t *ptep)
 	return pte_young(pte);
 }
 
-static inline int ptep_test_and_clear_young(struct vm_area_struct *vma,
-					    unsigned long address,
-					    pte_t *ptep)
-{
-	return __ptep_test_and_clear_young(ptep);
-}
-
 #define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
 static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
 					 unsigned long address, pte_t *ptep)
 {
-	int young = ptep_test_and_clear_young(vma, address, ptep);
+	int young = __ptep_test_and_clear_young(vma, address, ptep);
 
 	if (young) {
 		/*
@@ -937,7 +931,7 @@ static inline int pmdp_test_and_clear_young(struct vm_area_struct *vma,
 					    unsigned long address,
 					    pmd_t *pmdp)
 {
-	return ptep_test_and_clear_young(vma, address, (pte_t *)pmdp);
+	return __ptep_test_and_clear_young(vma, address, (pte_t *)pmdp);
 }
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
@@ -1123,6 +1117,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define pte_clear				__pte_clear
 #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
 #define ptep_get_and_clear			__ptep_get_and_clear
+#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
+#define ptep_test_and_clear_young		__ptep_test_and_clear_young
 
 #endif /* !__ASSEMBLY__ */
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:53 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:53 +0000
Subject: [PATCH v4 09/16] arm64/mm: ptep_clear_flush_young(): New layer to manage contig bit
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-10-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 9b4a9909fd5b..fc1005222ee4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -138,7 +138,7 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
  * so that we don't erroneously return false for pages that have been
  * remapped as PROT_NONE but are yet to be flushed from the TLB.
  * Note that we can't make any assumptions based on the state of the access
- * flag, since ptep_clear_flush_young() elides a DSB when invalidating the
+ * flag, since __ptep_clear_flush_young() elides a DSB when invalidating the
  * TLB.
  */
 #define pte_accessible(mm, pte)	\
@@ -904,8 +904,7 @@ static inline int __ptep_test_and_clear_young(struct vm_area_struct *vma,
 	return pte_young(pte);
 }
 
-#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
-static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
+static inline int __ptep_clear_flush_young(struct vm_area_struct *vma,
 					 unsigned long address, pte_t *ptep)
 {
 	int young = __ptep_test_and_clear_young(vma, address, ptep);
@@ -1119,6 +1118,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define ptep_get_and_clear			__ptep_get_and_clear
 #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
 #define ptep_test_and_clear_young		__ptep_test_and_clear_young
+#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
+#define ptep_clear_flush_young			__ptep_clear_flush_young
 
 #endif /* !__ASSEMBLY__ */
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:54 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:54 +0000
Subject: [PATCH v4 10/16] arm64/mm: ptep_set_wrprotect(): New layer to manage contig bit
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-11-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 10 ++++++----
 arch/arm64/mm/hugetlbpage.c      |  2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index fc1005222ee4..423cc32b2777 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -958,11 +958,11 @@ static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
 /*
- * ptep_set_wrprotect - mark read-only while trasferring potential hardware
+ * __ptep_set_wrprotect - mark read-only while trasferring potential hardware
  * dirty status (PTE_DBM && !PTE_RDONLY) to the software PTE_DIRTY bit.
  */
-#define __HAVE_ARCH_PTEP_SET_WRPROTECT
-static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, pte_t *ptep)
+static inline void __ptep_set_wrprotect(struct mm_struct *mm,
+					unsigned long address, pte_t *ptep)
 {
 	pte_t old_pte, pte;
 
@@ -980,7 +980,7 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres
 static inline void pmdp_set_wrprotect(struct mm_struct *mm,
 				      unsigned long address, pmd_t *pmdp)
 {
-	ptep_set_wrprotect(mm, address, (pte_t *)pmdp);
+	__ptep_set_wrprotect(mm, address, (pte_t *)pmdp);
 }
 
 #define pmdp_establish pmdp_establish
@@ -1120,6 +1120,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define ptep_test_and_clear_young		__ptep_test_and_clear_young
 #define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
 #define ptep_clear_flush_young			__ptep_clear_flush_young
+#define __HAVE_ARCH_PTEP_SET_WRPROTECT
+#define ptep_set_wrprotect			__ptep_set_wrprotect
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index c2a753541d13..952462820d9d 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -493,7 +493,7 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
 	pte_t pte;
 
 	if (!pte_cont(READ_ONCE(*ptep))) {
-		ptep_set_wrprotect(mm, addr, ptep);
+		__ptep_set_wrprotect(mm, addr, ptep);
 		return;
 	}
 
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:55 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:55 +0000
Subject: [PATCH v4 11/16] arm64/mm: ptep_set_access_flags(): New layer to manage contig bit
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-12-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 10 ++++++----
 arch/arm64/mm/fault.c            |  6 +++---
 arch/arm64/mm/hugetlbpage.c      |  2 +-
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 423cc32b2777..85010c2d4dfa 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -312,7 +312,7 @@ static inline void __check_safe_pte_update(struct mm_struct *mm, pte_t *ptep,
 
 	/*
 	 * Check for potential race with hardware updates of the pte
-	 * (ptep_set_access_flags safely changes valid ptes without going
+	 * (__ptep_set_access_flags safely changes valid ptes without going
 	 * through an invalid entry).
 	 */
 	VM_WARN_ONCE(!pte_young(pte),
@@ -842,8 +842,7 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
 	return pte_pmd(pte_modify(pmd_pte(pmd), newprot));
 }
 
-#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
-extern int ptep_set_access_flags(struct vm_area_struct *vma,
+extern int __ptep_set_access_flags(struct vm_area_struct *vma,
 				 unsigned long address, pte_t *ptep,
 				 pte_t entry, int dirty);
 
@@ -853,7 +852,8 @@ static inline int pmdp_set_access_flags(struct vm_area_struct *vma,
 					unsigned long address, pmd_t *pmdp,
 					pmd_t entry, int dirty)
 {
-	return ptep_set_access_flags(vma, address, (pte_t *)pmdp, pmd_pte(entry), dirty);
+	return __ptep_set_access_flags(vma, address, (pte_t *)pmdp,
+							pmd_pte(entry), dirty);
 }
 
 static inline int pud_devmap(pud_t pud)
@@ -1122,6 +1122,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define ptep_clear_flush_young			__ptep_clear_flush_young
 #define __HAVE_ARCH_PTEP_SET_WRPROTECT
 #define ptep_set_wrprotect			__ptep_set_wrprotect
+#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
+#define ptep_set_access_flags			__ptep_set_access_flags
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a287c1dea871..7cebd9847aae 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -209,9 +209,9 @@ static void show_pte(unsigned long addr)
  *
  * Returns whether or not the PTE actually changed.
  */
-int ptep_set_access_flags(struct vm_area_struct *vma,
-			  unsigned long address, pte_t *ptep,
-			  pte_t entry, int dirty)
+int __ptep_set_access_flags(struct vm_area_struct *vma,
+			    unsigned long address, pte_t *ptep,
+			    pte_t entry, int dirty)
 {
 	pteval_t old_pteval, pteval;
 	pte_t pte = READ_ONCE(*ptep);
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 952462820d9d..627a9717e98c 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -459,7 +459,7 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
 	pte_t orig_pte;
 
 	if (!pte_cont(pte))
-		return ptep_set_access_flags(vma, addr, ptep, pte, dirty);
+		return __ptep_set_access_flags(vma, addr, ptep, pte, dirty);
 
 	ncontig = find_num_contig(mm, addr, ptep, &pgsize);
 	dpfn = pgsize >> PAGE_SHIFT;
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:56 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:56 +0000
Subject: [PATCH v4 12/16] arm64/mm: ptep_get(): New layer to manage contig bit
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-13-ryan.roberts@arm.com>

Create a new layer for the in-table PTE manipulation APIs. For now, The
existing API is prefixed with double underscore to become the
arch-private API and the public API is just a simple wrapper that calls
the private API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate. But since there are
already some contig-aware users (e.g. hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

arm64 did not previously define an arch-specific ptep_get(), so override
the default version in the arch code, and also define the private
__ptep_get() version. Currently they both do the same thing that the
default version does (READ_ONCE()). Some arch users (hugetlb) were
already using ptep_get() so convert those to the private API. While
other callsites were doing direct READ_ONCE(), so convert those to use
the appropriate (public/private) API too.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 12 +++++++++---
 arch/arm64/kernel/efi.c          |  2 +-
 arch/arm64/mm/fault.c            |  4 ++--
 arch/arm64/mm/hugetlbpage.c      | 18 +++++++++---------
 arch/arm64/mm/kasan_init.c       |  2 +-
 arch/arm64/mm/mmu.c              | 12 ++++++------
 arch/arm64/mm/pageattr.c         |  4 ++--
 arch/arm64/mm/trans_pgd.c        |  2 +-
 8 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 85010c2d4dfa..6930c14f062f 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -276,6 +276,11 @@ static inline void __set_pte(pte_t *ptep, pte_t pte)
 	}
 }
 
+static inline pte_t __ptep_get(pte_t *ptep)
+{
+	return READ_ONCE(*ptep);
+}
+
 extern void __sync_icache_dcache(pte_t pteval);
 bool pgattr_change_is_safe(u64 old, u64 new);
 
@@ -303,7 +308,7 @@ static inline void __check_safe_pte_update(struct mm_struct *mm, pte_t *ptep,
 	if (!IS_ENABLED(CONFIG_DEBUG_VM))
 		return;
 
-	old_pte = READ_ONCE(*ptep);
+	old_pte = __ptep_get(ptep);
 
 	if (!pte_valid(old_pte) || !pte_valid(pte))
 		return;
@@ -893,7 +898,7 @@ static inline int __ptep_test_and_clear_young(struct vm_area_struct *vma,
 {
 	pte_t old_pte, pte;
 
-	pte = READ_ONCE(*ptep);
+	pte = __ptep_get(ptep);
 	do {
 		old_pte = pte;
 		pte = pte_mkold(pte);
@@ -966,7 +971,7 @@ static inline void __ptep_set_wrprotect(struct mm_struct *mm,
 {
 	pte_t old_pte, pte;
 
-	pte = READ_ONCE(*ptep);
+	pte = __ptep_get(ptep);
 	do {
 		old_pte = pte;
 		pte = pte_wrprotect(pte);
@@ -1111,6 +1116,7 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 				    unsigned long addr, pte_t *ptep,
 				    pte_t old_pte, pte_t new_pte);
 
+#define ptep_get				__ptep_get
 #define set_pte					__set_pte
 #define set_ptes				__set_ptes
 #define pte_clear				__pte_clear
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 44288a12fc6c..9afcc690fe73 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -103,7 +103,7 @@ static int __init set_permissions(pte_t *ptep, unsigned long addr, void *data)
 {
 	struct set_perm_data *spd = data;
 	const efi_memory_desc_t *md = spd->md;
-	pte_t pte = READ_ONCE(*ptep);
+	pte_t pte = __ptep_get(ptep);
 
 	if (md->attribute & EFI_MEMORY_RO)
 		pte = set_pte_bit(pte, __pgprot(PTE_RDONLY));
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 7cebd9847aae..d63f3a0a7251 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -191,7 +191,7 @@ static void show_pte(unsigned long addr)
 		if (!ptep)
 			break;
 
-		pte = READ_ONCE(*ptep);
+		pte = __ptep_get(ptep);
 		pr_cont(", pte=%016llx", pte_val(pte));
 		pte_unmap(ptep);
 	} while(0);
@@ -214,7 +214,7 @@ int __ptep_set_access_flags(struct vm_area_struct *vma,
 			    pte_t entry, int dirty)
 {
 	pteval_t old_pteval, pteval;
-	pte_t pte = READ_ONCE(*ptep);
+	pte_t pte = __ptep_get(ptep);
 
 	if (pte_same(pte, entry))
 		return 0;
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 627a9717e98c..52fb767607e0 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -152,14 +152,14 @@ pte_t huge_ptep_get(pte_t *ptep)
 {
 	int ncontig, i;
 	size_t pgsize;
-	pte_t orig_pte = ptep_get(ptep);
+	pte_t orig_pte = __ptep_get(ptep);
 
 	if (!pte_present(orig_pte) || !pte_cont(orig_pte))
 		return orig_pte;
 
 	ncontig = num_contig_ptes(page_size(pte_page(orig_pte)), &pgsize);
 	for (i = 0; i < ncontig; i++, ptep++) {
-		pte_t pte = ptep_get(ptep);
+		pte_t pte = __ptep_get(ptep);
 
 		if (pte_dirty(pte))
 			orig_pte = pte_mkdirty(orig_pte);
@@ -184,7 +184,7 @@ static pte_t get_clear_contig(struct mm_struct *mm,
 			     unsigned long pgsize,
 			     unsigned long ncontig)
 {
-	pte_t orig_pte = ptep_get(ptep);
+	pte_t orig_pte = __ptep_get(ptep);
 	unsigned long i;
 
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++) {
@@ -408,7 +408,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
 {
 	int ncontig;
 	size_t pgsize;
-	pte_t orig_pte = ptep_get(ptep);
+	pte_t orig_pte = __ptep_get(ptep);
 
 	if (!pte_cont(orig_pte))
 		return __ptep_get_and_clear(mm, addr, ptep);
@@ -431,11 +431,11 @@ static int __cont_access_flags_changed(pte_t *ptep, pte_t pte, int ncontig)
 {
 	int i;
 
-	if (pte_write(pte) != pte_write(ptep_get(ptep)))
+	if (pte_write(pte) != pte_write(__ptep_get(ptep)))
 		return 1;
 
 	for (i = 0; i < ncontig; i++) {
-		pte_t orig_pte = ptep_get(ptep + i);
+		pte_t orig_pte = __ptep_get(ptep + i);
 
 		if (pte_dirty(pte) != pte_dirty(orig_pte))
 			return 1;
@@ -492,7 +492,7 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
 	size_t pgsize;
 	pte_t pte;
 
-	if (!pte_cont(READ_ONCE(*ptep))) {
+	if (!pte_cont(__ptep_get(ptep))) {
 		__ptep_set_wrprotect(mm, addr, ptep);
 		return;
 	}
@@ -517,7 +517,7 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
 	size_t pgsize;
 	int ncontig;
 
-	if (!pte_cont(READ_ONCE(*ptep)))
+	if (!pte_cont(__ptep_get(ptep)))
 		return ptep_clear_flush(vma, addr, ptep);
 
 	ncontig = find_num_contig(mm, addr, ptep, &pgsize);
@@ -550,7 +550,7 @@ pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr
 		 * when the permission changes from executable to non-executable
 		 * in cases where cpu is affected with errata #2645198.
 		 */
-		if (pte_user_exec(READ_ONCE(*ptep)))
+		if (pte_user_exec(__ptep_get(ptep)))
 			return huge_ptep_clear_flush(vma, addr, ptep);
 	}
 	return huge_ptep_get_and_clear(vma->vm_mm, addr, ptep);
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 5eade712e9e5..5274c317d775 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -113,7 +113,7 @@ static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
 			memset(__va(page_phys), KASAN_SHADOW_INIT, PAGE_SIZE);
 		next = addr + PAGE_SIZE;
 		__set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
-	} while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep)));
+	} while (ptep++, addr = next, addr != end && pte_none(__ptep_get(ptep)));
 }
 
 static void __init kasan_pmd_populate(pud_t *pudp, unsigned long addr,
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 080e9b50f595..784f1e312447 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -176,7 +176,7 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 
 	ptep = pte_set_fixmap_offset(pmdp, addr);
 	do {
-		pte_t old_pte = READ_ONCE(*ptep);
+		pte_t old_pte = __ptep_get(ptep);
 
 		__set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
 
@@ -185,7 +185,7 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 		 * only allow updates to the permission attributes.
 		 */
 		BUG_ON(!pgattr_change_is_safe(pte_val(old_pte),
-					      READ_ONCE(pte_val(*ptep))));
+					      pte_val(__ptep_get(ptep))));
 
 		phys += PAGE_SIZE;
 	} while (ptep++, addr += PAGE_SIZE, addr != end);
@@ -854,7 +854,7 @@ static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
 
 	do {
 		ptep = pte_offset_kernel(pmdp, addr);
-		pte = READ_ONCE(*ptep);
+		pte = __ptep_get(ptep);
 		if (pte_none(pte))
 			continue;
 
@@ -987,7 +987,7 @@ static void free_empty_pte_table(pmd_t *pmdp, unsigned long addr,
 
 	do {
 		ptep = pte_offset_kernel(pmdp, addr);
-		pte = READ_ONCE(*ptep);
+		pte = __ptep_get(ptep);
 
 		/*
 		 * This is just a sanity check here which verifies that
@@ -1006,7 +1006,7 @@ static void free_empty_pte_table(pmd_t *pmdp, unsigned long addr,
 	 */
 	ptep = pte_offset_kernel(pmdp, 0UL);
 	for (i = 0; i < PTRS_PER_PTE; i++) {
-		if (!pte_none(READ_ONCE(ptep[i])))
+		if (!pte_none(__ptep_get(&ptep[i])))
 			return;
 	}
 
@@ -1475,7 +1475,7 @@ pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr, pte
 		 * when the permission changes from executable to non-executable
 		 * in cases where cpu is affected with errata #2645198.
 		 */
-		if (pte_user_exec(READ_ONCE(*ptep)))
+		if (pte_user_exec(ptep_get(ptep)))
 			return ptep_clear_flush(vma, addr, ptep);
 	}
 	return ptep_get_and_clear(vma->vm_mm, addr, ptep);
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index a7996d8edf0a..0c4e3ecf989d 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -36,7 +36,7 @@ bool can_set_direct_map(void)
 static int change_page_range(pte_t *ptep, unsigned long addr, void *data)
 {
 	struct page_change_data *cdata = data;
-	pte_t pte = READ_ONCE(*ptep);
+	pte_t pte = __ptep_get(ptep);
 
 	pte = clear_pte_bit(pte, cdata->clear_mask);
 	pte = set_pte_bit(pte, cdata->set_mask);
@@ -245,5 +245,5 @@ bool kernel_page_present(struct page *page)
 		return true;
 
 	ptep = pte_offset_kernel(pmdp, addr);
-	return pte_valid(READ_ONCE(*ptep));
+	return pte_valid(__ptep_get(ptep));
 }
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 230b607cf881..5139a28130c0 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -33,7 +33,7 @@ static void *trans_alloc(struct trans_pgd_info *info)
 
 static void _copy_pte(pte_t *dst_ptep, pte_t *src_ptep, unsigned long addr)
 {
-	pte_t pte = READ_ONCE(*src_ptep);
+	pte_t pte = __ptep_get(src_ptep);
 
 	if (pte_valid(pte)) {
 		/*
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:57 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:57 +0000
Subject: [PATCH v4 13/16] arm64/mm: Split __flush_tlb_range() to elide trailing DSB
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-14-ryan.roberts@arm.com>

Split __flush_tlb_range() into __flush_tlb_range_nosync() +
__flush_tlb_range(), in the same way as the existing flush_tlb_page()
arrangement. This allows calling __flush_tlb_range_nosync() to elide the
trailing DSB. Forthcoming "contpte" code will take advantage of this
when clearing the young bit from a contiguous range of ptes.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/tlbflush.h | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index bb2c2833a987..925ef3bdf9ed 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -399,7 +399,7 @@ do {									\
 #define __flush_s2_tlb_range_op(op, start, pages, stride, tlb_level) \
 	__flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false)
 
-static inline void __flush_tlb_range(struct vm_area_struct *vma,
+static inline void __flush_tlb_range_nosync(struct vm_area_struct *vma,
 				     unsigned long start, unsigned long end,
 				     unsigned long stride, bool last_level,
 				     int tlb_level)
@@ -431,10 +431,19 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
 	else
 		__flush_tlb_range_op(vae1is, start, pages, stride, asid, tlb_level, true);
 
-	dsb(ish);
 	mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, start, end);
 }
 
+static inline void __flush_tlb_range(struct vm_area_struct *vma,
+				     unsigned long start, unsigned long end,
+				     unsigned long stride, bool last_level,
+				     int tlb_level)
+{
+	__flush_tlb_range_nosync(vma, start, end, stride,
+				 last_level, tlb_level);
+	dsb(ish);
+}
+
 static inline void flush_tlb_range(struct vm_area_struct *vma,
 				   unsigned long start, unsigned long end)
 {
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:58 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:58 +0000
Subject: [PATCH v4 14/16] arm64/mm: Wire up PTE_CONT for user mappings
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-15-ryan.roberts@arm.com>

With the ptep API sufficiently refactored, we can now introduce a new
"contpte" API layer, which transparently manages the PTE_CONT bit for
user mappings. Whenever it detects a set of PTEs that meet the
requirements for a contiguous range, the PTEs are re-painted with the
PTE_CONT bit. Use of contpte mappings is intended to be transparent to
the core-mm, which continues to interact with individual ptes.

Since a contpte block only has a single access and dirty bit, the
semantic here changes slightly; when getting a pte (e.g. ptep_get())
that is part of a contpte mapping, the access and dirty information are
pulled from the block (so all ptes in the block return the same
access/dirty info). When changing the access/dirty info on a pte (e.g.
ptep_set_access_flags()) that is part of a contpte mapping, this change
will affect the whole contpte block. This is works fine in practice
since we guarantee that only a single folio is mapped by a contpte
block, and the core-mm tracks access/dirty information per folio.

This initial change provides a baseline that can be optimized in future
commits. That said, fold/unfold operations (which imply tlb
invalidation) are avoided where possible with a few tricks for
access/dirty bit management. Write-protect modifications for contpte
mappings are currently non-optimal, and incure a regression in fork()
performance. This will be addressed in follow-up changes.

In order for the public functions, which used to be pure inline, to
continue to be callable by modules, export all the contpte_* symbols
that are now called by those public inline functions.

The feature is enabled/disabled with the ARM64_CONTPTE Kconfig parameter
at build time. It defaults to enabled as long as its dependency,
TRANSPARENT_HUGEPAGE is also enabled. The core-mm depends upon
TRANSPARENT_HUGEPAGE to be able to allocate large folios, so if its not
enabled, then there is no chance of meeting the physical contiguity
requirement for contpte mappings.

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/Kconfig               |  10 +-
 arch/arm64/include/asm/pgtable.h | 184 +++++++++++++++
 arch/arm64/mm/Makefile           |   1 +
 arch/arm64/mm/contpte.c          | 388 +++++++++++++++++++++++++++++++
 4 files changed, 582 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/mm/contpte.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..de76e484ff3a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2209,6 +2209,15 @@ config UNWIND_PATCH_PAC_INTO_SCS
 	select UNWIND_TABLES
 	select DYNAMIC_SCS
 
+config ARM64_CONTPTE
+	bool "Contiguous PTE mappings for user memory" if EXPERT
+	depends on TRANSPARENT_HUGEPAGE
+	default y
+	help
+	  When enabled, user mappings are configured using the PTE contiguous
+	  bit, for any mappings that meet the size and alignment requirements.
+	  This reduces TLB pressure and improves performance.
+
 endmenu # "Kernel Features"
 
 menu "Boot options"
@@ -2318,4 +2327,3 @@ endmenu # "CPU Power Management"
 source "drivers/acpi/Kconfig"
 
 source "arch/arm64/kvm/Kconfig"
-
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 6930c14f062f..e64120452301 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -133,6 +133,10 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
  */
 #define pte_valid_not_user(pte) \
 	((pte_val(pte) & (PTE_VALID | PTE_USER | PTE_UXN)) == (PTE_VALID | PTE_UXN))
+/*
+ * Returns true if the pte is valid and has the contiguous bit set.
+ */
+#define pte_valid_cont(pte)	(pte_valid(pte) && pte_cont(pte))
 /*
  * Could the pte be present in the TLB? We must check mm_tlb_flush_pending
  * so that we don't erroneously return false for pages that have been
@@ -1116,6 +1120,184 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 				    unsigned long addr, pte_t *ptep,
 				    pte_t old_pte, pte_t new_pte);
 
+#ifdef CONFIG_ARM64_CONTPTE
+
+/*
+ * The contpte APIs are used to transparently manage the contiguous bit in ptes
+ * where it is possible and makes sense to do so. The PTE_CONT bit is considered
+ * a private implementation detail of the public ptep API (see below).
+ */
+extern void __contpte_try_fold(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte);
+extern void __contpte_try_unfold(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte);
+extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
+extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
+extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte, unsigned int nr);
+extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep);
+extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep);
+extern int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep,
+				pte_t entry, int dirty);
+
+static inline void contpte_try_fold(struct mm_struct *mm, unsigned long addr,
+					pte_t *ptep, pte_t pte)
+{
+	/*
+	 * Only bother trying if both the virtual and physical addresses are
+	 * aligned and correspond to the last entry in a contig range. The core
+	 * code mostly modifies ranges from low to high, so this is the likely
+	 * the last modification in the contig range, so a good time to fold.
+	 * We can't fold special mappings, because there is no associated folio.
+	 */
+
+	const unsigned long contmask = CONT_PTES - 1;
+	bool valign = (((unsigned long)ptep >> 3) & contmask) == contmask;
+	bool palign = (pte_pfn(pte) & contmask) == contmask;
+
+	if (valign && palign &&
+	    pte_valid(pte) && !pte_cont(pte) && !pte_special(pte))
+		__contpte_try_fold(mm, addr, ptep, pte);
+}
+
+static inline void contpte_try_unfold(struct mm_struct *mm, unsigned long addr,
+					pte_t *ptep, pte_t pte)
+{
+	if (pte_valid_cont(pte))
+		__contpte_try_unfold(mm, addr, ptep, pte);
+}
+
+/*
+ * The below functions constitute the public API that arm64 presents to the
+ * core-mm to manipulate PTE entries within their page tables (or at least this
+ * is the subset of the API that arm64 needs to implement). These public
+ * versions will automatically and transparently apply the contiguous bit where
+ * it makes sense to do so. Therefore any users that are contig-aware (e.g.
+ * hugetlb, kernel mapper) should NOT use these APIs, but instead use the
+ * private versions, which are prefixed with double underscore. All of these
+ * APIs except for ptep_get_lockless() are expected to be called with the PTL
+ * held.
+ */
+
+#define ptep_get ptep_get
+static inline pte_t ptep_get(pte_t *ptep)
+{
+	pte_t pte = __ptep_get(ptep);
+
+	if (!pte_valid_cont(pte))
+		return pte;
+
+	return contpte_ptep_get(ptep, pte);
+}
+
+#define ptep_get_lockless ptep_get_lockless
+static inline pte_t ptep_get_lockless(pte_t *ptep)
+{
+	pte_t pte = __ptep_get(ptep);
+
+	if (!pte_valid_cont(pte))
+		return pte;
+
+	return contpte_ptep_get_lockless(ptep);
+}
+
+static inline void set_pte(pte_t *ptep, pte_t pte)
+{
+	/*
+	 * We don't have the mm or vaddr so cannot unfold or fold contig entries
+	 * (since it requires tlb maintenance). set_pte() is not used in core
+	 * code, so this should never even be called. Regardless do our best to
+	 * service any call and emit a warning if there is any attempt to set a
+	 * pte on top of an existing contig range.
+	 */
+	pte_t orig_pte = __ptep_get(ptep);
+
+	WARN_ON_ONCE(pte_valid_cont(orig_pte));
+	__set_pte(ptep, pte_mknoncont(pte));
+}
+
+#define set_ptes set_ptes
+static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte, unsigned int nr)
+{
+	pte = pte_mknoncont(pte);
+
+	if (nr == 1) {
+		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+		__set_ptes(mm, addr, ptep, pte, 1);
+		contpte_try_fold(mm, addr, ptep, pte);
+	} else
+		contpte_set_ptes(mm, addr, ptep, pte, nr);
+}
+
+static inline void pte_clear(struct mm_struct *mm,
+				unsigned long addr, pte_t *ptep)
+{
+	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+	__pte_clear(mm, addr, ptep);
+}
+
+#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
+static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
+				unsigned long addr, pte_t *ptep)
+{
+	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+	return __ptep_get_and_clear(mm, addr, ptep);
+}
+
+#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
+static inline int ptep_test_and_clear_young(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep)
+{
+	pte_t orig_pte = __ptep_get(ptep);
+
+	if (!pte_valid_cont(orig_pte))
+		return __ptep_test_and_clear_young(vma, addr, ptep);
+
+	return contpte_ptep_test_and_clear_young(vma, addr, ptep);
+}
+
+#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
+static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep)
+{
+	pte_t orig_pte = __ptep_get(ptep);
+
+	if (!pte_valid_cont(orig_pte))
+		return __ptep_clear_flush_young(vma, addr, ptep);
+
+	return contpte_ptep_clear_flush_young(vma, addr, ptep);
+}
+
+#define __HAVE_ARCH_PTEP_SET_WRPROTECT
+static inline void ptep_set_wrprotect(struct mm_struct *mm,
+				unsigned long addr, pte_t *ptep)
+{
+	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+	__ptep_set_wrprotect(mm, addr, ptep);
+	contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
+}
+
+#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
+static inline int ptep_set_access_flags(struct vm_area_struct *vma,
+				unsigned long addr, pte_t *ptep,
+				pte_t entry, int dirty)
+{
+	pte_t orig_pte = __ptep_get(ptep);
+
+	entry = pte_mknoncont(entry);
+
+	if (!pte_valid_cont(orig_pte))
+		return __ptep_set_access_flags(vma, addr, ptep, entry, dirty);
+
+	return contpte_ptep_set_access_flags(vma, addr, ptep, entry, dirty);
+}
+
+#else /* CONFIG_ARM64_CONTPTE */
+
 #define ptep_get				__ptep_get
 #define set_pte					__set_pte
 #define set_ptes				__set_ptes
@@ -1131,6 +1313,8 @@ extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 #define ptep_set_access_flags			__ptep_set_access_flags
 
+#endif /* CONFIG_ARM64_CONTPTE */
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_H */
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index dbd1bc95967d..60454256945b 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -3,6 +3,7 @@ obj-y				:= dma-mapping.o extable.o fault.o init.o \
 				   cache.o copypage.o flush.o \
 				   ioremap.o mmap.o pgd.o mmu.o \
 				   context.o proc.o pageattr.o fixmap.o
+obj-$(CONFIG_ARM64_CONTPTE)	+= contpte.o
 obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
 obj-$(CONFIG_PTDUMP_CORE)	+= ptdump.o
 obj-$(CONFIG_PTDUMP_DEBUGFS)	+= ptdump_debugfs.o
diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
new file mode 100644
index 000000000000..69c36749dd98
--- /dev/null
+++ b/arch/arm64/mm/contpte.c
@@ -0,0 +1,388 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 ARM Ltd.
+ */
+
+#include <linux/mm.h>
+#include <linux/export.h>
+#include <asm/tlbflush.h>
+
+static inline bool mm_is_user(struct mm_struct *mm)
+{
+	/*
+	 * Don't attempt to apply the contig bit to kernel mappings, because
+	 * dynamically adding/removing the contig bit can cause page faults.
+	 * These racing faults are ok for user space, since they get serialized
+	 * on the PTL. But kernel mappings can't tolerate faults.
+	 */
+	return mm != &init_mm;
+}
+
+static inline pte_t *contpte_align_down(pte_t *ptep)
+{
+	return (pte_t *)(ALIGN_DOWN((unsigned long)ptep >> 3, CONT_PTES) << 3);
+}
+
+static void ptep_clear_flush_range(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, int nr)
+{
+	struct vm_area_struct vma = TLB_FLUSH_VMA(mm, 0);
+	unsigned long start_addr = addr;
+	int i;
+
+	for (i = 0; i < nr; i++, ptep++, addr += PAGE_SIZE)
+		__pte_clear(mm, addr, ptep);
+
+	__flush_tlb_range(&vma, start_addr, addr, PAGE_SIZE, true, 3);
+}
+
+static bool ptep_any_valid(pte_t *ptep, int nr)
+{
+	int i;
+
+	for (i = 0; i < nr; i++, ptep++) {
+		if (pte_valid(__ptep_get(ptep)))
+			return true;
+	}
+
+	return false;
+}
+
+static void contpte_convert(struct mm_struct *mm, unsigned long addr,
+			    pte_t *ptep, pte_t pte)
+{
+	struct vm_area_struct vma = TLB_FLUSH_VMA(mm, 0);
+	unsigned long start_addr;
+	pte_t *start_ptep;
+	int i;
+
+	start_ptep = ptep = contpte_align_down(ptep);
+	start_addr = addr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+	pte = pfn_pte(ALIGN_DOWN(pte_pfn(pte), CONT_PTES), pte_pgprot(pte));
+
+	for (i = 0; i < CONT_PTES; i++, ptep++, addr += PAGE_SIZE) {
+		pte_t ptent = __ptep_get_and_clear(mm, addr, ptep);
+
+		if (pte_dirty(ptent))
+			pte = pte_mkdirty(pte);
+
+		if (pte_young(ptent))
+			pte = pte_mkyoung(pte);
+	}
+
+	__flush_tlb_range(&vma, start_addr, addr, PAGE_SIZE, true, 3);
+
+	__set_ptes(mm, start_addr, start_ptep, pte, CONT_PTES);
+}
+
+void __contpte_try_fold(struct mm_struct *mm, unsigned long addr,
+			pte_t *ptep, pte_t pte)
+{
+	/*
+	 * We have already checked that the virtual and pysical addresses are
+	 * correctly aligned for a contpte mapping in contpte_try_fold() so the
+	 * remaining checks are to ensure that the contpte range is fully
+	 * covered by a single folio, and ensure that all the ptes are valid
+	 * with contiguous PFNs and matching prots. We ignore the state of the
+	 * access and dirty bits for the purpose of deciding if its a contiguous
+	 * range; the folding process will generate a single contpte entry which
+	 * has a single access and dirty bit. Those 2 bits are the logical OR of
+	 * their respective bits in the constituent pte entries. In order to
+	 * ensure the contpte range is covered by a single folio, we must
+	 * recover the folio from the pfn, but special mappings don't have a
+	 * folio backing them. Fortunately contpte_try_fold() already checked
+	 * that the pte is not special - we never try to fold special mappings.
+	 * Note we can't use vm_normal_page() for this since we don't have the
+	 * vma.
+	 */
+
+	unsigned long folio_saddr;
+	unsigned long folio_eaddr;
+	unsigned long cont_saddr;
+	unsigned long cont_eaddr;
+	struct folio *folio;
+	struct page *page;
+	unsigned long pfn;
+	pte_t *orig_ptep;
+	pgprot_t prot;
+	pte_t subpte;
+	int i;
+
+	if (!mm_is_user(mm))
+		return;
+
+	page = pte_page(pte);
+	folio = page_folio(page);
+	folio_saddr = addr - (page - &folio->page) * PAGE_SIZE;
+	folio_eaddr = folio_saddr + folio_nr_pages(folio) * PAGE_SIZE;
+	cont_saddr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+	cont_eaddr = cont_saddr + CONT_PTE_SIZE;
+
+	if (folio_saddr > cont_saddr || folio_eaddr < cont_eaddr)
+		return;
+
+	pfn = pte_pfn(pte) - ((addr - cont_saddr) >> PAGE_SHIFT);
+	prot = pte_pgprot(pte_mkold(pte_mkclean(pte)));
+	orig_ptep = ptep;
+	ptep = contpte_align_down(ptep);
+
+	for (i = 0; i < CONT_PTES; i++, ptep++, pfn++) {
+		subpte = __ptep_get(ptep);
+		subpte = pte_mkold(pte_mkclean(subpte));
+
+		if (!pte_valid(subpte) ||
+		    pte_pfn(subpte) != pfn ||
+		    pgprot_val(pte_pgprot(subpte)) != pgprot_val(prot))
+			return;
+	}
+
+	pte = pte_mkcont(pte);
+	contpte_convert(mm, addr, orig_ptep, pte);
+}
+EXPORT_SYMBOL(__contpte_try_fold);
+
+void __contpte_try_unfold(struct mm_struct *mm, unsigned long addr,
+			pte_t *ptep, pte_t pte)
+{
+	/*
+	 * We have already checked that the ptes are contiguous in
+	 * contpte_try_unfold(), so just check that the mm is user space.
+	 */
+
+	if (!mm_is_user(mm))
+		return;
+
+	pte = pte_mknoncont(pte);
+	contpte_convert(mm, addr, ptep, pte);
+}
+EXPORT_SYMBOL(__contpte_try_unfold);
+
+pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte)
+{
+	/*
+	 * Gather access/dirty bits, which may be populated in any of the ptes
+	 * of the contig range. We are guarranteed to be holding the PTL, so any
+	 * contiguous range cannot be unfolded or otherwise modified under our
+	 * feet.
+	 */
+
+	pte_t pte;
+	int i;
+
+	ptep = contpte_align_down(ptep);
+
+	for (i = 0; i < CONT_PTES; i++, ptep++) {
+		pte = __ptep_get(ptep);
+
+		if (pte_dirty(pte))
+			orig_pte = pte_mkdirty(orig_pte);
+
+		if (pte_young(pte))
+			orig_pte = pte_mkyoung(orig_pte);
+	}
+
+	return orig_pte;
+}
+EXPORT_SYMBOL(contpte_ptep_get);
+
+pte_t contpte_ptep_get_lockless(pte_t *orig_ptep)
+{
+	/*
+	 * Gather access/dirty bits, which may be populated in any of the ptes
+	 * of the contig range. We may not be holding the PTL, so any contiguous
+	 * range may be unfolded/modified/refolded under our feet. Therefore we
+	 * ensure we read a _consistent_ contpte range by checking that all ptes
+	 * in the range are valid and have CONT_PTE set, that all pfns are
+	 * contiguous and that all pgprots are the same (ignoring access/dirty).
+	 * If we find a pte that is not consistent, then we must be racing with
+	 * an update so start again. If the target pte does not have CONT_PTE
+	 * set then that is considered consistent on its own because it is not
+	 * part of a contpte range.
+	 */
+
+	pgprot_t orig_prot;
+	unsigned long pfn;
+	pte_t orig_pte;
+	pgprot_t prot;
+	pte_t *ptep;
+	pte_t pte;
+	int i;
+
+retry:
+	orig_pte = __ptep_get(orig_ptep);
+
+	if (!pte_valid_cont(orig_pte))
+		return orig_pte;
+
+	orig_prot = pte_pgprot(pte_mkold(pte_mkclean(orig_pte)));
+	ptep = contpte_align_down(orig_ptep);
+	pfn = pte_pfn(orig_pte) - (orig_ptep - ptep);
+
+	for (i = 0; i < CONT_PTES; i++, ptep++, pfn++) {
+		pte = __ptep_get(ptep);
+		prot = pte_pgprot(pte_mkold(pte_mkclean(pte)));
+
+		if (!pte_valid_cont(pte) ||
+		   pte_pfn(pte) != pfn ||
+		   pgprot_val(prot) != pgprot_val(orig_prot))
+			goto retry;
+
+		if (pte_dirty(pte))
+			orig_pte = pte_mkdirty(orig_pte);
+
+		if (pte_young(pte))
+			orig_pte = pte_mkyoung(orig_pte);
+	}
+
+	return orig_pte;
+}
+EXPORT_SYMBOL(contpte_ptep_get_lockless);
+
+void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
+					pte_t *ptep, pte_t pte, unsigned int nr)
+{
+	unsigned long next;
+	unsigned long end;
+	unsigned long pfn;
+	pgprot_t prot;
+	pte_t orig_pte;
+
+	if (!mm_is_user(mm))
+		return __set_ptes(mm, addr, ptep, pte, nr);
+
+	end = addr + (nr << PAGE_SHIFT);
+	pfn = pte_pfn(pte);
+	prot = pte_pgprot(pte);
+
+	do {
+		next = pte_cont_addr_end(addr, end);
+		nr = (next - addr) >> PAGE_SHIFT;
+		pte = pfn_pte(pfn, prot);
+
+		if (((addr | next | (pfn << PAGE_SHIFT)) & ~CONT_PTE_MASK) == 0)
+			pte = pte_mkcont(pte);
+		else
+			pte = pte_mknoncont(pte);
+
+		/*
+		 * If operating on a partial contiguous range then we must first
+		 * unfold the contiguous range if it was previously folded.
+		 * Otherwise we could end up with overlapping tlb entries.
+		 */
+		if (nr != CONT_PTES)
+			contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+
+		/*
+		 * If we are replacing ptes that were contiguous or if the new
+		 * ptes are contiguous and any of the ptes being replaced are
+		 * valid, we need to clear and flush the range to prevent
+		 * overlapping tlb entries.
+		 */
+		orig_pte = __ptep_get(ptep);
+		if (pte_valid_cont(orig_pte) ||
+		    (pte_cont(pte) && ptep_any_valid(ptep, nr)))
+			ptep_clear_flush_range(mm, addr, ptep, nr);
+
+		__set_ptes(mm, addr, ptep, pte, nr);
+
+		addr = next;
+		ptep += nr;
+		pfn += nr;
+
+	} while (addr != end);
+}
+EXPORT_SYMBOL(contpte_set_ptes);
+
+int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
+					unsigned long addr, pte_t *ptep)
+{
+	/*
+	 * ptep_clear_flush_young() technically requires us to clear the access
+	 * flag for a _single_ pte. However, the core-mm code actually tracks
+	 * access/dirty per folio, not per page. And since we only create a
+	 * contig range when the range is covered by a single folio, we can get
+	 * away with clearing young for the whole contig range here, so we avoid
+	 * having to unfold.
+	 */
+
+	int young = 0;
+	int i;
+
+	ptep = contpte_align_down(ptep);
+	addr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+
+	for (i = 0; i < CONT_PTES; i++, ptep++, addr += PAGE_SIZE)
+		young |= __ptep_test_and_clear_young(vma, addr, ptep);
+
+	return young;
+}
+EXPORT_SYMBOL(contpte_ptep_test_and_clear_young);
+
+int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
+					unsigned long addr, pte_t *ptep)
+{
+	int young;
+
+	young = contpte_ptep_test_and_clear_young(vma, addr, ptep);
+
+	if (young) {
+		/*
+		 * See comment in __ptep_clear_flush_young(); same rationale for
+		 * eliding the trailing DSB applies here.
+		 */
+		addr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+		__flush_tlb_range_nosync(vma, addr, addr + CONT_PTE_SIZE,
+					 PAGE_SIZE, true, 3);
+	}
+
+	return young;
+}
+EXPORT_SYMBOL(contpte_ptep_clear_flush_young);
+
+int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
+					unsigned long addr, pte_t *ptep,
+					pte_t entry, int dirty)
+{
+	unsigned long start_addr;
+	pte_t orig_pte;
+	int i;
+
+	/*
+	 * Gather the access/dirty bits for the contiguous range. If nothing has
+	 * changed, its a noop.
+	 */
+	orig_pte = pte_mknoncont(ptep_get(ptep));
+	if (pte_val(orig_pte) == pte_val(entry))
+		return 0;
+
+	/*
+	 * We can fix up access/dirty bits without having to unfold/fold the
+	 * contig range. But if the write bit is changing, we need to go through
+	 * the full unfold/fold cycle.
+	 */
+	if (pte_write(orig_pte) == pte_write(entry)) {
+		/*
+		 * For HW access management, we technically only need to update
+		 * the flag on a single pte in the range. But for SW access
+		 * management, we need to update all the ptes to prevent extra
+		 * faults. Avoid per-page tlb flush in __ptep_set_access_flags()
+		 * and instead flush the whole range at the end.
+		 */
+		ptep = contpte_align_down(ptep);
+		start_addr = addr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
+
+		for (i = 0; i < CONT_PTES; i++, ptep++, addr += PAGE_SIZE)
+			__ptep_set_access_flags(vma, addr, ptep, entry, 0);
+
+		if (dirty)
+			__flush_tlb_range(vma, start_addr, addr,
+							PAGE_SIZE, true, 3);
+	} else {
+		__contpte_try_unfold(vma->vm_mm, addr, ptep, orig_pte);
+		__ptep_set_access_flags(vma, addr, ptep, entry, dirty);
+		contpte_try_fold(vma->vm_mm, addr, ptep, entry);
+	}
+
+	return 1;
+}
+EXPORT_SYMBOL(contpte_ptep_set_access_flags);
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:50:59 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:50:59 +0000
Subject: [PATCH v4 15/16] arm64/mm: Implement new helpers to optimize fork()
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-16-ryan.roberts@arm.com>

With the core-mm changes in place to batch-copy ptes during fork, we can
take advantage of this in arm64 to greatly reduce the number of tlbis we
have to issue, and recover the lost fork performance incured when adding
support for transparent contiguous ptes.

This optimization covers 2 cases:

2) The memory being CoWed is contpte-sized (or bigger) folios. We set
   wrprotect in the parent and set the ptes in the child for a whole
   contpte block in one hit. This means we can operate on the whole
   block and don't need to unfold/fold.

1) The memory being CoWed is all order-0 folios. No folding or unfolding
   occurs here, but the added cost of checking if we need to fold on
   every pte adds up. Given we are forking, we are just copying the ptes
   already in the parent, so we should be maintaining the single/contpte
   state into the child anyway, and any check for folding will always be
   false. Therefore, we can elide the fold check in set_ptes_full() and
   ptep_set_wrprotects() when full=1.

The optimization to wrprotect a whole contpte block without unfolding is
possible thanks to the tightening of the Arm ARM in respect to the
definition and behaviour when 'Misprogramming the Contiguous bit'. See
section D21194 at https://developer.arm.com/documentation/102105/latest/

The following microbenchmark results demonstate the recovered (and
overall improved) fork performance for large pte-mapped folios once this
patch is applied. Fork is called in a tight loop in a process with 1G of
populated memory and the time for the function to execute is measured.
100 iterations per run, 8 runs performed on both Apple M2 (VM) and
Ampere Altra (bare metal). Tests performed for case where 1G memory is
comprised of pte-mapped order-9 folios. Negative is faster, positive is
slower, compared to baseline upon which the series is based:

| fork          |    Apple M2 VM    |    Ampere Altra   |
| order-9       |-------------------|-------------------|
| (pte-map)     |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|
| baseline      |    0.0% |    1.2% |    0.0% |    0.1% |
| before-change |  541.5% |    2.8% | 3654.4% |    0.0% |
| after-change  |  -25.4% |    1.9% |   -6.7% |    0.1% |

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 97 ++++++++++++++++++++++++++------
 arch/arm64/mm/contpte.c          | 47 ++++++++++++++++
 2 files changed, 128 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e64120452301..d4805f73b9db 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -966,16 +966,12 @@ static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
 }
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
-/*
- * __ptep_set_wrprotect - mark read-only while trasferring potential hardware
- * dirty status (PTE_DBM && !PTE_RDONLY) to the software PTE_DIRTY bit.
- */
-static inline void __ptep_set_wrprotect(struct mm_struct *mm,
-					unsigned long address, pte_t *ptep)
+static inline void ___ptep_set_wrprotect(struct mm_struct *mm,
+					unsigned long address, pte_t *ptep,
+					pte_t pte)
 {
-	pte_t old_pte, pte;
+	pte_t old_pte;
 
-	pte = __ptep_get(ptep);
 	do {
 		old_pte = pte;
 		pte = pte_wrprotect(pte);
@@ -984,6 +980,26 @@ static inline void __ptep_set_wrprotect(struct mm_struct *mm,
 	} while (pte_val(pte) != pte_val(old_pte));
 }
 
+/*
+ * __ptep_set_wrprotect - mark read-only while trasferring potential hardware
+ * dirty status (PTE_DBM && !PTE_RDONLY) to the software PTE_DIRTY bit.
+ */
+static inline void __ptep_set_wrprotect(struct mm_struct *mm,
+					unsigned long address, pte_t *ptep)
+{
+	___ptep_set_wrprotect(mm, address, ptep, __ptep_get(ptep));
+}
+
+static inline void __ptep_set_wrprotects(struct mm_struct *mm,
+					unsigned long address, pte_t *ptep,
+					unsigned int nr, int full)
+{
+	unsigned int i;
+
+	for (i = 0; i < nr; i++, address += PAGE_SIZE, ptep++)
+		__ptep_set_wrprotect(mm, address, ptep);
+}
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 #define __HAVE_ARCH_PMDP_SET_WRPROTECT
 static inline void pmdp_set_wrprotect(struct mm_struct *mm,
@@ -1139,6 +1155,8 @@ extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
 				unsigned long addr, pte_t *ptep);
 extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
 				unsigned long addr, pte_t *ptep);
+extern void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, unsigned int nr, int full);
 extern int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
 				unsigned long addr, pte_t *ptep,
 				pte_t entry, int dirty);
@@ -1170,6 +1188,17 @@ static inline void contpte_try_unfold(struct mm_struct *mm, unsigned long addr,
 		__contpte_try_unfold(mm, addr, ptep, pte);
 }
 
+#define pte_batch_remaining pte_batch_remaining
+static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long addr,
+					unsigned long end)
+{
+	if (!pte_valid_cont(pte))
+		return 1;
+
+	return min(CONT_PTES - ((addr >> PAGE_SHIFT) & (CONT_PTES - 1)),
+		   (end - addr) >> PAGE_SHIFT);
+}
+
 /*
  * The below functions constitute the public API that arm64 presents to the
  * core-mm to manipulate PTE entries within their page tables (or at least this
@@ -1219,20 +1248,30 @@ static inline void set_pte(pte_t *ptep, pte_t pte)
 	__set_pte(ptep, pte_mknoncont(pte));
 }
 
-#define set_ptes set_ptes
-static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
-				pte_t *ptep, pte_t pte, unsigned int nr)
+#define set_ptes_full set_ptes_full
+static inline void set_ptes_full(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte, unsigned int nr,
+				int full)
 {
 	pte = pte_mknoncont(pte);
 
 	if (nr == 1) {
-		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+		if (!full)
+			contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
 		__set_ptes(mm, addr, ptep, pte, 1);
-		contpte_try_fold(mm, addr, ptep, pte);
+		if (!full)
+			contpte_try_fold(mm, addr, ptep, pte);
 	} else
 		contpte_set_ptes(mm, addr, ptep, pte, nr);
 }
 
+#define set_ptes set_ptes
+static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, pte_t pte, unsigned int nr)
+{
+	set_ptes_full(mm, addr, ptep, pte, nr, false);
+}
+
 static inline void pte_clear(struct mm_struct *mm,
 				unsigned long addr, pte_t *ptep)
 {
@@ -1272,13 +1311,38 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
 	return contpte_ptep_clear_flush_young(vma, addr, ptep);
 }
 
+#define ptep_set_wrprotects ptep_set_wrprotects
+static inline void ptep_set_wrprotects(struct mm_struct *mm,
+				unsigned long addr, pte_t *ptep,
+				unsigned int nr, int full)
+{
+	if (nr == 1) {
+		/*
+		 * Optimization: ptep_set_wrprotects() can only be called for
+		 * present ptes so we only need to check contig bit as condition
+		 * for unfold, and we can remove the contig bit from the pte we
+		 * read to avoid re-reading. This speeds up fork() with is very
+		 * sensitive for order-0 folios. Should be equivalent to
+		 * contpte_try_unfold() for this case.
+		 */
+		pte_t orig_pte = __ptep_get(ptep);
+
+		if (unlikely(pte_cont(orig_pte))) {
+			__contpte_try_unfold(mm, addr, ptep, orig_pte);
+			orig_pte = pte_mknoncont(orig_pte);
+		}
+		___ptep_set_wrprotect(mm, addr, ptep, orig_pte);
+		if (!full)
+			contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
+	} else
+		contpte_set_wrprotects(mm, addr, ptep, nr, full);
+}
+
 #define __HAVE_ARCH_PTEP_SET_WRPROTECT
 static inline void ptep_set_wrprotect(struct mm_struct *mm,
 				unsigned long addr, pte_t *ptep)
 {
-	contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
-	__ptep_set_wrprotect(mm, addr, ptep);
-	contpte_try_fold(mm, addr, ptep, __ptep_get(ptep));
+	ptep_set_wrprotects(mm, addr, ptep, 1, false);
 }
 
 #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
@@ -1310,6 +1374,7 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma,
 #define ptep_clear_flush_young			__ptep_clear_flush_young
 #define __HAVE_ARCH_PTEP_SET_WRPROTECT
 #define ptep_set_wrprotect			__ptep_set_wrprotect
+#define ptep_set_wrprotects			__ptep_set_wrprotects
 #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 #define ptep_set_access_flags			__ptep_set_access_flags
 
diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
index 69c36749dd98..72e672024785 100644
--- a/arch/arm64/mm/contpte.c
+++ b/arch/arm64/mm/contpte.c
@@ -339,6 +339,53 @@ int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL(contpte_ptep_clear_flush_young);
 
+void contpte_set_wrprotects(struct mm_struct *mm, unsigned long addr,
+					pte_t *ptep, unsigned int nr, int full)
+{
+	unsigned long next;
+	unsigned long end;
+
+	if (!mm_is_user(mm))
+		return __ptep_set_wrprotects(mm, addr, ptep, nr, full);
+
+	end = addr + (nr << PAGE_SHIFT);
+
+	do {
+		next = pte_cont_addr_end(addr, end);
+		nr = (next - addr) >> PAGE_SHIFT;
+
+		/*
+		 * If wrprotecting an entire contig range, we can avoid
+		 * unfolding. Just set wrprotect and wait for the later
+		 * mmu_gather flush to invalidate the tlb. Until the flush, the
+		 * page may or may not be wrprotected. After the flush, it is
+		 * guarranteed wrprotected. If its a partial range though, we
+		 * must unfold, because we can't have a case where CONT_PTE is
+		 * set but wrprotect applies to a subset of the PTEs; this would
+		 * cause it to continue to be unpredictable after the flush.
+		 */
+		if (nr != CONT_PTES)
+			contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+
+		__ptep_set_wrprotects(mm, addr, ptep, nr, full);
+
+		addr = next;
+		ptep += nr;
+
+		/*
+		 * If applying to a partial contig range, the change could have
+		 * made the range foldable. Use the last pte in the range we
+		 * just set for comparison, since contpte_try_fold() only
+		 * triggers when acting on the last pte in the contig range.
+		 */
+		if (nr != CONT_PTES)
+			contpte_try_fold(mm, addr - PAGE_SIZE, ptep - 1,
+					 __ptep_get(ptep - 1));
+
+	} while (addr != end);
+}
+EXPORT_SYMBOL(contpte_set_wrprotects);
+
 int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
 					unsigned long addr, pte_t *ptep,
 					pte_t entry, int dirty)
-- 
2.25.1



From ryan.roberts at arm.com  Mon Dec 18 02:51:00 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Mon, 18 Dec 2023 10:51:00 +0000
Subject: [PATCH v4 16/16] arm64/mm: Implement clear_ptes() to optimize exit, munmap, dontneed
In-Reply-To: <20231218105100.172635-1-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
Message-ID: <20231218105100.172635-17-ryan.roberts@arm.com>

With the core-mm changes in place to batch-clear ptes during
zap_pte_range(), we can take advantage of this in arm64 to greatly
reduce the number of tlbis we have to issue, and recover the lost
performance in exit, munmap and madvise(DONTNEED) incured when adding
support for transparent contiguous ptes.

If we are clearing a whole contpte range, we can elide first unfolding
that range and save the tlbis. We just clear the whole range.

The following microbenchmark results demonstate the effect of this
change on madvise(DONTNEED) performance for large pte-mapped folios.
madvise(dontneed) is called for each page of a 1G populated mapping and
the total time is measured. 100 iterations per run, 8 runs performed on
both Apple M2 (VM) and Ampere Altra (bare metal). Tests performed for
case where 1G memory is comprised of pte-mapped order-9 folios. Negative
is faster, positive is slower, compared to baseline upon which the
series is based:

| dontneed      |    Apple M2 VM    |    Ampere Altra   |
| order-9       |-------------------|-------------------|
| (pte-map)     |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|
| baseline      |    0.0% |    7.9% |    0.0% |    0.0% |
| before-change |   -1.3% |    7.0% |   13.0% |    0.0% |
| after-change  |   -9.9% |    0.9% |   14.1% |    0.0% |

The memory is initially all contpte-mapped and has to be unfolded (which
requires tlbi for the whole block) when the first page is touched (since
the test is madvise-ing 1 page at a time). Ampere Altra has high cost
for tlbi; this is why cost increases there.

The following microbenchmark results demonstate the recovery (and
overall improvement) of munmap performance for large pte-mapped folios.
munmap is called for a 1G populated mapping and the function runtime is
measured. 100 iterations per run, 8 runs performed on both Apple M2 (VM)
and Ampere Altra (bare metal). Tests performed for case where 1G memory
is comprised of pte-mapped order-9 folios. Negative is faster, positive
is slower, compared to baseline upon which the series is based:

| munmap        |    Apple M2 VM    |    Ampere Altra   |
| order-9       |-------------------|-------------------|
| (pte-map)     |    mean |   stdev |    mean |   stdev |
|---------------|---------|---------|---------|---------|
| baseline      |    0.0% |    6.4% |    0.0% |    0.1% |
| before-change |   43.3% |    1.9% |  375.2% |    0.0% |
| after-change  |   -6.0% |    1.4% |   -0.6% |    0.2% |

Tested-by: John Hubbard <jhubbard at nvidia.com>
Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
---
 arch/arm64/include/asm/pgtable.h | 42 +++++++++++++++++++++++++++++
 arch/arm64/mm/contpte.c          | 45 ++++++++++++++++++++++++++++++++
 2 files changed, 87 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index d4805f73b9db..f5bf059291c3 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -953,6 +953,29 @@ static inline pte_t __ptep_get_and_clear(struct mm_struct *mm,
 	return pte;
 }
 
+static inline pte_t __clear_ptes(struct mm_struct *mm,
+				 unsigned long address, pte_t *ptep,
+				 unsigned int nr, int full)
+{
+	pte_t orig_pte = __ptep_get_and_clear(mm, address, ptep);
+	unsigned int i;
+	pte_t pte;
+
+	for (i = 1; i < nr; i++) {
+		address += PAGE_SIZE;
+		ptep++;
+		pte = __ptep_get_and_clear(mm, address, ptep);
+
+		if (pte_dirty(pte))
+			orig_pte = pte_mkdirty(orig_pte);
+
+		if (pte_young(pte))
+			orig_pte = pte_mkyoung(orig_pte);
+	}
+
+	return orig_pte;
+}
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 #define __HAVE_ARCH_PMDP_HUGE_GET_AND_CLEAR
 static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
@@ -1151,6 +1174,8 @@ extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
 extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
 extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
 				pte_t *ptep, pte_t pte, unsigned int nr);
+extern pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr,
+				pte_t *ptep, unsigned int nr, int full);
 extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
 				unsigned long addr, pte_t *ptep);
 extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
@@ -1279,6 +1304,22 @@ static inline void pte_clear(struct mm_struct *mm,
 	__pte_clear(mm, addr, ptep);
 }
 
+#define clear_ptes clear_ptes
+static inline pte_t clear_ptes(struct mm_struct *mm,
+				unsigned long addr, pte_t *ptep,
+				unsigned int nr, int full)
+{
+	pte_t pte;
+
+	if (nr == 1) {
+		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+		pte = __ptep_get_and_clear(mm, addr, ptep);
+	} else
+		pte = contpte_clear_ptes(mm, addr, ptep, nr, full);
+
+	return pte;
+}
+
 #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
 static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
 				unsigned long addr, pte_t *ptep)
@@ -1366,6 +1407,7 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma,
 #define set_pte					__set_pte
 #define set_ptes				__set_ptes
 #define pte_clear				__pte_clear
+#define clear_ptes				__clear_ptes
 #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
 #define ptep_get_and_clear			__ptep_get_and_clear
 #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
index 72e672024785..6f2a15ac5163 100644
--- a/arch/arm64/mm/contpte.c
+++ b/arch/arm64/mm/contpte.c
@@ -293,6 +293,51 @@ void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
 }
 EXPORT_SYMBOL(contpte_set_ptes);
 
+pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
+					unsigned int nr, int full)
+{
+	/*
+	 * If we cover a partial contpte block at the beginning or end of the
+	 * batch, unfold if currently folded. This makes it safe to clear some
+	 * of the entries while keeping others. contpte blocks in the middle of
+	 * the range, which are fully covered don't need to be unfolded because
+	 * we will clear the full block.
+	 */
+
+	unsigned int i;
+	pte_t pte;
+	pte_t tail;
+
+	if (!mm_is_user(mm))
+		return __clear_ptes(mm, addr, ptep, nr, full);
+
+	if (ptep != contpte_align_down(ptep) || nr < CONT_PTES)
+		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
+
+	if (ptep + nr != contpte_align_down(ptep + nr))
+		contpte_try_unfold(mm, addr + PAGE_SIZE * (nr - 1),
+				   ptep + nr - 1,
+				   __ptep_get(ptep + nr - 1));
+
+	pte = __ptep_get_and_clear(mm, addr, ptep);
+
+	for (i = 1; i < nr; i++) {
+		addr += PAGE_SIZE;
+		ptep++;
+
+		tail = __ptep_get_and_clear(mm, addr, ptep);
+
+		if (pte_dirty(tail))
+			pte = pte_mkdirty(pte);
+
+		if (pte_young(tail))
+			pte = pte_mkyoung(pte);
+	}
+
+	return pte;
+}
+EXPORT_SYMBOL(contpte_clear_ptes);
+
 int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
 					unsigned long addr, pte_t *ptep)
 {
-- 
2.25.1



From hns at goldelico.com  Mon Dec 18 02:54:47 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Mon, 18 Dec 2023 11:54:47 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <22cny5aumc5wafsrjd3j55zcjbjf2viip64kfbjiqis2grtd6t@wg5dxeuzil6l>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
 <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
 <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>
 <oobcl2kfsuph27er7rflfqvt3lu6athufomxv5chf3uctx4emh@x6rzjtlskhbf>
 <F58855EC-D87D-4747-A363-0E7AA5DB1AEC@goldelico.com>
 <22cny5aumc5wafsrjd3j55zcjbjf2viip64kfbjiqis2grtd6t@wg5dxeuzil6l>
Message-ID: <3E03E913-48E1-49EC-A6C9-EAC1612E65E7@goldelico.com>



> Am 18.12.2023 um 11:14 schrieb Maxime Ripard <mripard at kernel.org>:
> 
> On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
>> Hi Maxime,
>> 
>>> Am 15.12.2023 um 14:33 schrieb Maxime Ripard <mripard at kernel.org>:
>>> 
>>>>> 
>>>>> It's for a separate architecture, with a separate driver, maintained out
>>>>> of tree by a separate community, with a separate set of requirements as
>>>>> evidenced by the other thread. And that's all fine in itself, but
>>>>> there's very little reason to put these two bindings in the same file.
>>>>> 
>>>>> We could also turn this around, why is it important that it's in the
>>>>> same file?
>>>> 
>>>> Same vendor. And enough similarity in architectures, even a logical sequence
>>>> of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
>>>> (SGX and Rogue seem to be just trade names for their architecture development).
>>> 
>>> Again, none of that matters for *where* the binding is stored.
>> 
>> So what then speaks against extending the existing bindings file as proposed
>> here?
> 
> I mean, apart from everything you quoted, then sure, nothing speaks
> against it.
> 
>>>> AFAIK bindings should describe hardware and not communities or drivers
>>>> or who is currently maintaining it. The latter can change, the first not.
>>> 
>>> Bindings are supposed to describe hardware indeed. Nothing was ever said
>>> about where those bindings are supposed to be located.
>>> 
>>> There's hundreds of other YAML bindings describing devices of the same
>>> vendors and different devices from the same generation.
>> 
>> Usually SoC seem to be split over multiple files by subsystem. Not by versions
>> or generations. If the subsystems are similar enough they share the same bindings
>> doc instead of having one for each generation duplicating a lot of code.
>> 
>> Here is a comparable example that combines multiple vendors and generations:
>> 
>> Documentation/devicetree/bindings/usb/generic-ehci.yaml
> 
> EHCI is a single interface for USB2.0 controllers. It's a standard API,
> and is made of a single driver that requires minor modifications to deal
> with multiple devices.
> 
> We're very far from the same situation here.

How far are we really? And, it is the purpose of the driver to handle different cases.

That there are currently two drivers is just a matter of history and not a necessity.

> 
>>> If anything it'll make it easier for you. I'm really not sure why it is
>>> controversial and you're fighting this so hard.
>> 
>> Well, you made it controversial by proposing to split what IMHO belongs together.
> 
> No, reviews aren't controversial.
> The controversy started when you chose
> to oppose it while you could have just rolled with it.

Well, you asked

"I think it would be best to have a separate file for this, img,sgx.yaml
maybe?"

and

"Because it's more convenient?"

I understood that as an invitation for discussing the pros and cons and working out the
most convenient solution. And that involves playing the devil's advocate which of course
is controversial by principle.

Now, IMHO all the pros and cons are on the table and the question is who makes a decision
how to go.

> 
>> I feel that the original patch is good enough for its purpose and follows
>> some design pattern that can be deduced from other binding docs.
> 
> [citation needed]

Joke: Documentation/devicetree/bindings/* - I am not aware of a formal analysis of course.

But see my example for ehci. It follows the pattern I mean. If clocks, regs, interrupts,
resets, and more properties are (almost) the same, then group them and just differentiate
by different compatible strings. If necessary use some - if: clauses.

It is the task of drivers to handle the details.

As my other (maybe more important) comment to this patch did indicate we IMHO can easily
live with something like

+      - items:
+          - enum:
+              - ti,am62-gpu # IMG AXE GPU model/revision is fully discoverable
+              - ti,omap3430-gpu # sgx530 Rev 121
+              - ti,omap3630-gpu # sgx530 Rev 125
+              - ingenic,jz4780-gpu # sgx540 Rev 130
+              - ti,omap4430-gpu # sgx540 Rev 120
+              - allwinner,sun6i-a31-gpu # sgx544 MP2 Rev 115
+              - ti,omap4470-gpu # sgx544 MP1 Rev 112
+              - ti,omap5432-gpu # sgx544 MP2 Rev 105
+              - ti,am5728-gpu # sgx544 MP2 Rev 116
+              - ti,am6548-gpu # sgx544 MP1 Rev 117

And leave it to drivers using a table to deduce the generation and
revision or read it out from the chip. And there can even be different
drivers handling only a subset of the potential compatibles.

Then the currently-out-of-tree driver for the sgx5 can be reworked in
less than half an hour without loosing functionality.

BR,
Nikolaus



From andyshrk at 163.com  Mon Dec 18 02:55:20 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 18 Dec 2023 18:55:20 +0800
Subject: [PATCH v2 0/3] Fix mainline support for rk3036 kylin board
Message-ID: <20231218105523.2478315-1-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>


When I want to test some patch of inno hdmi driver on
mainline, I found the support of rk3036 kylin board
was broken by somehow:

PATCH 1 is add psci dt node, as we switch to psci for
cpu on/off for many yeas.
PATCH 2 add stdou-path for uart boot console.
PATCH 3 fix the emmc per board rockchip,default-sample-phase property
issue.

Changes in v2:
- Fix typo s/patch/path/
- Change subjet s/arm/ARM/

Andy Yan (3):
  ARM: dts: rockchip: Add psci for rk3036
  ARM: dts: rockchip: Add stdout-path for rk3036 kylin
  ARM: dts: rockchip: Remove rockchip,default-sample-phase from
    rk3036.dtsi

 arch/arm/boot/dts/rockchip/rk3036-kylin.dts | 4 ++++
 arch/arm/boot/dts/rockchip/rk3036.dtsi      | 6 +++++-
 2 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.34.1



From andyshrk at 163.com  Mon Dec 18 02:55:21 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 18 Dec 2023 18:55:21 +0800
Subject: [PATCH v2 1/3] ARM: dts: rockchip: Add psci for rk3036
In-Reply-To: <20231218105523.2478315-1-andyshrk@163.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
Message-ID: <20231218105523.2478315-2-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>

The system will hang at bringup secondary CPUs
without psci node.

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>

---

(no changes since v1)

 arch/arm/boot/dts/rockchip/rk3036.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
index 78686fc72ce6..5344803442a1 100644
--- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
@@ -67,6 +67,11 @@ display-subsystem {
 		ports = <&vop_out>;
 	};
 
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		arm,cpu-registers-not-fw-configured;
-- 
2.34.1



From andyshrk at 163.com  Mon Dec 18 02:55:23 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 18 Dec 2023 18:55:23 +0800
Subject: [PATCH v2 3/3] ARM: dts: rockchip: Remove rockchip,default-sample-phase from rk3036.dtsi
In-Reply-To: <20231218105523.2478315-1-andyshrk@163.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
Message-ID: <20231218105523.2478315-4-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>

This should be a per board property, should not be put in
a soc core dtsi.

And when this property convert from default-sample-phase
in linux-5.7 by commit 8a385eb57296 ("ARM: dts: rockchip: fix
rockchip,default-sample-phase property names"), the emmc
on rk3036 kylin board get a initialising error:

[    4.512797] Freeing unused kernel memory: 8192K
[    4.519500] mmc_host mmc1: Bus speed (slot 0) = 37125000Hz (slot req 37500000Hz, actual 37125000HZ div = 0)
[    4.530971] mmc1: error -84 whilst initialising MMC card
[    4.537277] Run /init as init process
[    4.550932] mmc_host mmc1: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
[    4.664717] mmc_host mmc1: Bus speed (slot 0) = 37125000Hz (slot req 37500000Hz, actual 37125000HZ div = 0)
[    4.676156] mmc1: error -84 whilst initialising MMC card

I think the reason why the emmc on rk3036 kylin board was able
to work before linux-5.7 was that the illegal property was not
correctly identified by the rockchip dw_mmc driver.

Fixes: faea098e1808 ("ARM: dts: rockchip: add core rk3036 dtsi")
Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
---

(no changes since v1)

 arch/arm/boot/dts/rockchip/rk3036.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
index 5344803442a1..466952bf9db4 100644
--- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
@@ -287,7 +287,6 @@ emmc: mmc at 1021c000 {
 		clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
 			 <&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
 		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
-		rockchip,default-sample-phase = <158>;
 		disable-wp;
 		dmas = <&pdma 12>;
 		dma-names = "rx-tx";
-- 
2.34.1



From andyshrk at 163.com  Mon Dec 18 02:55:22 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 18 Dec 2023 18:55:22 +0800
Subject: [PATCH v2 2/3] ARM: dts: rockchip: Add stdout-path for rk3036 kylin
In-Reply-To: <20231218105523.2478315-1-andyshrk@163.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
Message-ID: <20231218105523.2478315-3-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>

Add stdout-path to get a uart console when system boot.

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>

---

Changes in v2:
- Fix typo s/patch/path/
- Change subjet s/arm/ARM/

 arch/arm/boot/dts/rockchip/rk3036-kylin.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
index 67e1e04139e7..f12fa3831bbf 100644
--- a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
@@ -8,6 +8,10 @@ / {
 	model = "Rockchip RK3036 KylinBoard";
 	compatible = "rockchip,rk3036-kylin", "rockchip,rk3036";
 
+	chosen {
+		stdout-path = "serial2:115200n8";
+	};
+
 	memory at 60000000 {
 		device_type = "memory";
 		reg = <0x60000000 0x20000000>;
-- 
2.34.1



From michal.simek at amd.com  Mon Dec 18 02:56:43 2023
From: michal.simek at amd.com (Michal Simek)
Date: Mon, 18 Dec 2023 11:56:43 +0100
Subject: [PATCH 0/2] add platform check in event manager driver
In-Reply-To: <20231218094009.13528-1-jay.buddhabhatti@amd.com>
References: <20231218094009.13528-1-jay.buddhabhatti@amd.com>
Message-ID: <d07b5884-c7c1-482a-a911-a0b7a75100d3@amd.com>



On 12/18/23 10:40, Jay Buddhabhatti wrote:
> Some error event IDs for Versal and Versal NET are different.
> Both the platforms should access their respective error event
> IDs so use sub_family_code to check for Versal or Versal NET
> platform and check error IDs for respective platforms.
> 
> Jay Buddhabhatti (2):
>    firmware: xilinx: Export function to use in other module
>    drivers: soc: xilinx: add check for platform
> 
>   drivers/firmware/xilinx/zynqmp.c        |  3 ++-
>   drivers/soc/xilinx/xlnx_event_manager.c | 25 ++++++++++++++++++++-----
>   include/linux/firmware/xlnx-zynqmp.h    | 22 ++++++++++++++++++----
>   3 files changed, 40 insertions(+), 10 deletions(-)
> 

Acked-by: Michal Simek <michal.simek at amd.com>

Thanks,
Michal


From alexander.stein at ew.tq-group.com  Mon Dec 18 02:57:12 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 11:57:12 +0100
Subject: [PATCH 0/6] dev_err_probe usage for imx8qxp DPU pipeline
Message-ID: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>

Hi everyone,

while working on i.MX8QXP DPU/LVDS output I come across these fixes simplifying
the code and improving debugging, while also creating less noise.
It touches several files as the output pipeline is rather complex.

Best regards,
Alexander

Alexander Stein (6):
  drm/bridge: imx8qxp-pxl2dpi: Use dev_err_probe
  drm/bridge: imx: imx8qxp-ldb: Use dev_err_probe
  drm/bridge: imx: imx-ldb-helper: Use dev_err_probe
  drm/bridge: imx8qxp-pixel-link: Use dev_err_probe
  drm/bridge: dpu-dprc: Use dev_err_probe
  drm/bridge: dpu-core: Don't print error on -EPROBE_DEFER

 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c   | 13 ++-----
 drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c      | 37 ++++++-------------
 .../gpu/drm/bridge/imx/imx8qxp-pixel-link.c   | 19 +++-------
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c  | 26 ++++---------
 drivers/gpu/drm/imx/dpu/dpu-core.c            |  7 ++--
 drivers/gpu/drm/imx/dpu/dpu-dprc.c            | 12 +++---
 6 files changed, 39 insertions(+), 75 deletions(-)

-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 02:57:13 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 11:57:13 +0100
Subject: [PATCH 1/6] drm/bridge: imx8qxp-pxl2dpi: Use dev_err_probe
In-Reply-To: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
References: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218105718.2445136-2-alexander.stein@ew.tq-group.com>

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 26 ++++++--------------
 1 file changed, 7 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
index 4a886cb808ca..3a1d5795d002 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -403,20 +403,12 @@ static int imx8qxp_pxl2dpi_bridge_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	p2d->regmap = syscon_node_to_regmap(np->parent);
-	if (IS_ERR(p2d->regmap)) {
-		ret = PTR_ERR(p2d->regmap);
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dev, "failed to get regmap: %d\n", ret);
-		return ret;
-	}
+	if (IS_ERR(p2d->regmap))
+		return dev_err_probe(dev, ret, "failed to get regmap\n");
 
 	ret = imx_scu_get_handle(&p2d->ipc_handle);
-	if (ret) {
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dev, "failed to get SCU ipc handle: %d\n",
-				      ret);
-		return ret;
-	}
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to get SCU ipc handle\n");
 
 	p2d->dev = dev;
 
@@ -427,13 +419,9 @@ static int imx8qxp_pxl2dpi_bridge_probe(struct platform_device *pdev)
 	}
 
 	p2d->next_bridge = imx8qxp_pxl2dpi_find_next_bridge(p2d);
-	if (IS_ERR(p2d->next_bridge)) {
-		ret = PTR_ERR(p2d->next_bridge);
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dev, "failed to find next bridge: %d\n",
-				      ret);
-		return ret;
-	}
+	if (IS_ERR(p2d->next_bridge))
+		return dev_err_probe(dev, PTR_ERR(p2d->next_bridge),
+				     "failed to find next bridge\n");
 
 	ret = imx8qxp_pxl2dpi_set_pixel_link_sel(p2d);
 	if (ret)
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 02:57:14 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 11:57:14 +0100
Subject: [PATCH 2/6] drm/bridge: imx: imx8qxp-ldb: Use dev_err_probe
In-Reply-To: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
References: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218105718.2445136-3-alexander.stein@ew.tq-group.com>

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c | 37 ++++++++----------------
 1 file changed, 12 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
index 7984da9c0a35..423196d2204d 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
@@ -557,10 +557,8 @@ static int imx8qxp_ldb_parse_dt_companion(struct imx8qxp_ldb *imx8qxp_ldb)
 
 	imx8qxp_ldb->companion = of_drm_find_bridge(companion_port);
 	if (!imx8qxp_ldb->companion) {
-		ret = -EPROBE_DEFER;
-		DRM_DEV_DEBUG_DRIVER(dev,
-				     "failed to find bridge for companion bridge: %d\n",
-				     ret);
+		ret = dev_err_probe(dev, -EPROBE_DEFER,
+				    "failed to find bridge for companion bridge\n");
 		goto out;
 	}
 
@@ -590,22 +588,14 @@ static int imx8qxp_ldb_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	imx8qxp_ldb->clk_pixel = devm_clk_get(dev, "pixel");
-	if (IS_ERR(imx8qxp_ldb->clk_pixel)) {
-		ret = PTR_ERR(imx8qxp_ldb->clk_pixel);
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dev,
-				      "failed to get pixel clock: %d\n", ret);
-		return ret;
-	}
+	if (IS_ERR(imx8qxp_ldb->clk_pixel))
+		return dev_err_probe(dev, PTR_ERR(imx8qxp_ldb->clk_pixel),
+				     "failed to get pixel clock\n");
 
 	imx8qxp_ldb->clk_bypass = devm_clk_get(dev, "bypass");
-	if (IS_ERR(imx8qxp_ldb->clk_bypass)) {
-		ret = PTR_ERR(imx8qxp_ldb->clk_bypass);
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dev,
-				      "failed to get bypass clock: %d\n", ret);
-		return ret;
-	}
+	if (IS_ERR(imx8qxp_ldb->clk_bypass))
+		return dev_err_probe(dev, PTR_ERR(imx8qxp_ldb->clk_bypass),
+				     "failed to get bypass clock\n");
 
 	imx8qxp_ldb->dev = dev;
 
@@ -640,13 +630,10 @@ static int imx8qxp_ldb_probe(struct platform_device *pdev)
 	}
 
 	imx8qxp_ldb_ch->phy = devm_of_phy_get(dev, ldb_ch->np, "lvds_phy");
-	if (IS_ERR(imx8qxp_ldb_ch->phy)) {
-		ret = PTR_ERR(imx8qxp_ldb_ch->phy);
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dev, "failed to get channel%d PHY: %d\n",
-				      imx8qxp_ldb->active_chno, ret);
-		return ret;
-	}
+	if (IS_ERR(imx8qxp_ldb_ch->phy))
+		return dev_err_probe(dev, PTR_ERR(imx8qxp_ldb_ch->phy),
+				     "failed to get channel%d PHY\n",
+				     imx8qxp_ldb->active_chno);
 
 	ret = ldb_find_next_bridge_helper(ldb);
 	if (ret)
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 02:57:15 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 11:57:15 +0100
Subject: [PATCH 3/6] drm/bridge: imx: imx-ldb-helper: Use dev_err_probe
In-Reply-To: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
References: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218105718.2445136-4-alexander.stein@ew.tq-group.com>

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
index 6967325cd8ee..9b872cfb849c 100644
--- a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
+++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
@@ -172,7 +172,7 @@ int ldb_find_next_bridge_helper(struct ldb *ldb)
 {
 	struct device *dev = ldb->dev;
 	struct ldb_channel *ldb_ch;
-	int ret, i;
+	int i;
 
 	for (i = 0; i < MAX_LDB_CHAN_NUM; i++) {
 		ldb_ch = ldb->channel[i];
@@ -182,14 +182,9 @@ int ldb_find_next_bridge_helper(struct ldb *ldb)
 
 		ldb_ch->next_bridge = devm_drm_of_get_bridge(dev, ldb_ch->np,
 							     1, 0);
-		if (IS_ERR(ldb_ch->next_bridge)) {
-			ret = PTR_ERR(ldb_ch->next_bridge);
-			if (ret != -EPROBE_DEFER)
-				DRM_DEV_ERROR(dev,
-					      "failed to get next bridge: %d\n",
-					      ret);
-			return ret;
-		}
+		if (IS_ERR(ldb_ch->next_bridge))
+			return dev_err_probe(dev, PTR_ERR(ldb_ch->next_bridge),
+					     "failed to find next bridge\n");
 	}
 
 	return 0;
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 02:57:16 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 11:57:16 +0100
Subject: [PATCH 4/6] drm/bridge: imx8qxp-pixel-link: Use dev_err_probe
In-Reply-To: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
References: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218105718.2445136-5-alexander.stein@ew.tq-group.com>

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 .../gpu/drm/bridge/imx/imx8qxp-pixel-link.c   | 19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
index ed8b7a4e0e11..b8cc1df3e572 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -338,12 +338,9 @@ static int imx8qxp_pixel_link_bridge_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	ret = imx_scu_get_handle(&pl->ipc_handle);
-	if (ret) {
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dev, "failed to get SCU ipc handle: %d\n",
-				      ret);
-		return ret;
-	}
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "failed to get SCU ipc handle\n");
 
 	ret = of_property_read_u8(np, "fsl,dc-id", &pl->dc_id);
 	if (ret) {
@@ -379,13 +376,9 @@ static int imx8qxp_pixel_link_bridge_probe(struct platform_device *pdev)
 		return ret;
 
 	pl->next_bridge = imx8qxp_pixel_link_find_next_bridge(pl);
-	if (IS_ERR(pl->next_bridge)) {
-		ret = PTR_ERR(pl->next_bridge);
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dev, "failed to find next bridge: %d\n",
-				      ret);
-		return ret;
-	}
+	if (IS_ERR(pl->next_bridge))
+		return dev_err_probe(dev, PTR_ERR(pl->next_bridge),
+				     "failed to find next bridge\n");
 
 	platform_set_drvdata(pdev, pl);
 
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 02:57:17 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 11:57:17 +0100
Subject: [PATCH 5/6] drm/bridge: dpu-dprc: Use dev_err_probe
In-Reply-To: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
References: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218105718.2445136-6-alexander.stein@ew.tq-group.com>

This simplifies the code and gives additional information upon deferral.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 drivers/gpu/drm/imx/dpu/dpu-dprc.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/dpu/dpu-dprc.c b/drivers/gpu/drm/imx/dpu/dpu-dprc.c
index 261c9566721e..6467ad960080 100644
--- a/drivers/gpu/drm/imx/dpu/dpu-dprc.c
+++ b/drivers/gpu/drm/imx/dpu/dpu-dprc.c
@@ -612,7 +612,8 @@ static int dpu_dprc_probe(struct platform_device *pdev)
 
 		dprc->prgs[i] = dpu_prg_lookup_by_phandle(dev, "fsl,prgs", i);
 		if (!dprc->prgs[i])
-			return -EPROBE_DEFER;
+			return dev_err_probe(dev, -EPROBE_DEFER,
+					     "Failed to lookup fsl,prgs\n");
 
 		if (i == 1)
 			dpu_prg_set_auxiliary(dprc->prgs[i]);
@@ -623,11 +624,10 @@ static int dpu_dprc_probe(struct platform_device *pdev)
 
 	ret = devm_request_irq(dev, wrap_irq, dpu_dprc_wrap_irq_handler,
 			       IRQF_SHARED, dev_name(dev), dprc);
-	if (ret < 0) {
-		dev_err(dev, "failed to request dpr_wrap irq(%u): %d\n",
-			wrap_irq, ret);
-		return ret;
-	}
+	if (ret < 0)
+		return dev_err_probe(dev, ret,
+				     "failed to request dpr_wrap irq(%u)\n",
+				     wrap_irq);
 
 	platform_set_drvdata(pdev, dprc);
 
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 02:57:18 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 11:57:18 +0100
Subject: [PATCH 6/6] drm/bridge: dpu-core: Don't print error on -EPROBE_DEFER
In-Reply-To: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
References: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218105718.2445136-7-alexander.stein@ew.tq-group.com>

-517 errors are just annoying. dev_err_probe can't be used here either
as this would hide the error message already set in us->init.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 drivers/gpu/drm/imx/dpu/dpu-core.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/dpu/dpu-core.c b/drivers/gpu/drm/imx/dpu/dpu-core.c
index d6116b3e4ed7..ea2558a14a6c 100644
--- a/drivers/gpu/drm/imx/dpu/dpu-core.c
+++ b/drivers/gpu/drm/imx/dpu/dpu-core.c
@@ -592,9 +592,10 @@ static int dpu_submodules_init(struct dpu_soc *dpu, unsigned long dpu_base)
 			ret = us->init(dpu, j, us->ids[j], us->types[j],
 				       pec_ofs, dpu_base + us->ofss[j]);
 			if (ret) {
-				dev_err(dpu->dev,
-					"failed to initialize %s%d: %d\n",
-						us->name, us->ids[j], ret);
+				if (ret != -EPROBE_DEFER)
+					dev_err(dpu->dev,
+						"failed to initialize %s%d: %d\n",
+							us->name, us->ids[j], ret);
 				return ret;
 			}
 		}
-- 
2.34.1



From alexandru.elisei at arm.com  Mon Dec 18 02:59:26 2023
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Mon, 18 Dec 2023 10:59:26 +0000
Subject: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
In-Reply-To: <CAL_JsqJF7Bs6nGt0hdP25YTMpzPK8V3h6C5Thkh=PnzPbwFEkQ@mail.gmail.com>
References: <ZXiMiLz9ZyUdxUP8@raptor>
 <CAL_Jsq+U_GR=mOK3-phnd4jeJKf79aOmhPwDOSj+f=s-7fZZWQ@mail.gmail.com>
 <ZXmr-Kl9L2SO13--@raptor>
 <CAL_JsqL=P1Y6w38LD_xw+vK4CNqt22FW_FE9oi_XTLHVQEne7Q@mail.gmail.com>
 <ZXnE3724jYYSg4o6@raptor>
 <CAL_JsqJgTnuQjo13cKo1Ebm5j9tCRT8GhNavdqu5vwp+fdnTLw@mail.gmail.com>
 <ZXnthcg0BkEd-RgK@raptor>
 <CAL_JsqLAW0--F8R0oTaajN3YpbK2KgE6Ypn8tk4_pf_s=xC+aw@mail.gmail.com>
 <ZXsjFYKHkJM_JLCy@raptor>
 <CAL_JsqJF7Bs6nGt0hdP25YTMpzPK8V3h6C5Thkh=PnzPbwFEkQ@mail.gmail.com>
Message-ID: <ZYAmDkz5NplbVGyd@raptor>

Hi,

On Thu, Dec 14, 2023 at 12:55:14PM -0600, Rob Herring wrote:
> On Thu, Dec 14, 2023 at 9:45?AM Alexandru Elisei
> <alexandru.elisei at arm.com> wrote:
> >
> > Hi,
> >
> > On Wed, Dec 13, 2023 at 02:30:42PM -0600, Rob Herring wrote:
> > > On Wed, Dec 13, 2023 at 11:44?AM Alexandru Elisei
> > > <alexandru.elisei at arm.com> wrote:
> > > >
> > > > On Wed, Dec 13, 2023 at 11:22:17AM -0600, Rob Herring wrote:
> > > > > On Wed, Dec 13, 2023 at 8:51?AM Alexandru Elisei
> > > > > <alexandru.elisei at arm.com> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> > > > > > > On Wed, Dec 13, 2023 at 7:05?AM Alexandru Elisei
> > > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > > >
> > > > > > > > Hi Rob,
> > > > > > > >
> > > > > > > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > > > > > > > On Tue, Dec 12, 2023 at 10:38?AM Alexandru Elisei
> > > > > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Rob,
> > > > > > > > > >
> > > > > > > > > > Thank you so much for the feedback, I'm not very familiar with device tree,
> > > > > > > > > > and any comments are very useful.
> > > > > > > > > >
> > > > > > > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > > > > > > > On Sun, Nov 19, 2023 at 10:59?AM Alexandru Elisei
> > > > > > > > > > > <alexandru.elisei at arm.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > > > > > > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > > > > > > > > >
> > > > > > > > > > > > The DTB node for the tag storage region is defined as:
> > > > > > > > > > > >
> > > > > > > > > > > >         tags0: tag-storage at 8f8000000 {
> > > > > > > > > > > >                 compatible = "arm,mte-tag-storage";
> > > > > > > > > > > >                 reg = <0x08 0xf8000000 0x00 0x4000000>;
> > > > > > > > > > > >                 block-size = <0x1000>;
> > > > > > > > > > > >                 memory = <&memory0>;    // Associated tagged memory node
> > > > > > > > > > > >         };
> > > > > > > > > > >
> > > > > > > > > > > I skimmed thru the discussion some. If this memory range is within
> > > > > > > > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > > > > > > > >
> > > > > > > > > > Ok, will do that.
> > > > > > > > > >
> > > > > > > > > > If you don't mind, why do you say that it definitely belongs in
> > > > > > > > > > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > > > > > > > > > motivation.
> > > > > > > > >
> > > > > > > > > Simply so that /memory nodes describe all possible memory and
> > > > > > > > > /reserved-memory is just adding restrictions. It's also because
> > > > > > > > > /reserved-memory is what gets handled early, and we don't need
> > > > > > > > > multiple things to handle early.
> > > > > > > > >
> > > > > > > > > > Tag storage is not DMA and can live anywhere in memory.
> > > > > > > > >
> > > > > > > > > Then why put it in DT at all? The only reason CMA is there is to set
> > > > > > > > > the size. It's not even clear to me we need CMA in DT either. The
> > > > > > > > > reasoning long ago was the kernel didn't do a good job of moving and
> > > > > > > > > reclaiming contiguous space, but that's supposed to be better now (and
> > > > > > > > > most h/w figured out they need IOMMUs).
> > > > > > > > >
> > > > > > > > > But for tag storage you know the size as it is a function of the
> > > > > > > > > memory size, right? After all, you are validating the size is correct.
> > > > > > > > > I guess there is still the aspect of whether you want enable MTE or
> > > > > > > > > not which could be done in a variety of ways.
> > > > > > > >
> > > > > > > > Oh, sorry, my bad, I should have been clearer about this. I don't want to
> > > > > > > > put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.
> > > > > > >
> > > > > > > Yes, I understand, but my point remains. Why do you need this in DT?
> > > > > > > If the location doesn't matter and you can calculate the size from the
> > > > > > > memory size, what else is there to add to the DT?
> > > > > >
> > > > > > I am afraid there has been a misunderstanding. What do you mean by
> > > > > > "location doesn't matter"?
> > > > >
> > > > > You said:
> > > > > > Tag storage is not DMA and can live anywhere in memory.
> > > > >
> > > > > Which I took as the kernel can figure out where to put it. But maybe
> > > > > you meant the h/w platform can hard code it to be anywhere in memory?
> > > > > If so, then yes, DT is needed.
> > > >
> > > > Ah, I see, sorry for not being clear enough, you are correct: tag storage
> > > > is a hardware property, and software needs a mechanism (in this case, the
> > > > dt) to discover its properties.
> > > >
> > > > >
> > > > > > At the very least, Linux needs to know the address and size of a memory
> > > > > > region to use it. The series is about using the tag storage memory for
> > > > > > data. Tag storage cannot be described as a regular memory node because it
> > > > > > cannot be tagged (and normal memory can).
> > > > >
> > > > > If the tag storage lives in the middle of memory, then it would be
> > > > > described in the memory node, but removed by being in reserved-memory
> > > > > node.
> > > >
> > > > I don't follow. Would you mind going into more details?
> > >
> > > It goes back to what I said earlier about /memory nodes describing all
> > > the memory. There's no reason to reserve memory if you haven't
> > > described that range as memory to begin with. One could presumably
> > > just have a memory node for each contiguous chunk and not need
> > > /reserved-memory (ignoring the need to say what things are reserved
> > > for). That would become very difficult to adjust. Note that the kernel
> > > has a hardcoded limit of 64 reserved regions currently and that is not
> > > enough for some people. Seems like a lot, but I have no idea how they
> > > are (ab)using /reserved-memory.
> >
> > Ah, I see what you mean, reserved memory is about marking existing memory
> > (from a /memory node) as special, not about adding new memory.
> >
> > After the memblock allocator is initialized, the kernel can use it for its
> > own allocations. Kernel allocations are not movable.
> >
> > When a page is allocated as tagged, the associated tag storage cannot be
> > used for data, otherwise the tags would corrupt that data. To avoid this,
> > the requirement is that tag storage pages are only used for movable
> > allocations. When a page is allocated as tagged, the data in the associated
> > tag storage is migrated and the tag storage is taken from the page
> > allocator (via alloc_contig_range()).
> >
> > My understanding is that the memblock allocator can use all the memory from
> > a /memory node. If the tags storage memory is declared in a /memory node,
> > there exists the possibility that Linux will use tag storage memory for its
> > own allocation, which would make that tags storage memory unmovable, and
> > thus unusable for storing tags.
> 
> No, because the tag storage would be reserved in /reserved-memory.
> 
> Of course, the arch code could do something between scanning /memory
> nodes and /reserved-memory, but that would be broken arch code.
> Ideally, there wouldn't be any arch code in between those 2 points,
> but it's complicated. It used to mainly be powerpc, but we keep adding
> to the complexity on arm64.

Ah, yes, thats what I was referring to, the fact that the memory nodes are
parsed in setup_arch -> setup_machine_fdt -> early_init_dt_scan, and the
reserved memory is parsed later in setup_arch -> arm64_memblock_init.

If the rule is that no memblock allocations can take place between
setup_machine_fdt() and arm64_memblock_init(), then putting tag storage in
a /memory node will work, thank you for the clarification.

> 
> > Looking at early_init_dt_scan_memory(), even if a /memory node if marked at
> > hotpluggable, memblock will still use it, unless "movable_node" is set on
> > the kernel command line.
> >
> > That's the reason why I'm not describing tag storage in a /memory node.  Is
> > there way to tell the memblock allocator not to use memory from a /memory
> > node?
> >
> > >
> > > Let me give an example. Presumably using MTE at all is configurable.
> > > If you boot a kernel with MTE disabled (or older and not supporting
> > > it), then I'd assume you'd want to use the tag storage for regular
> > > memory. Well, If tag storage is already part of /memory, then all you
> > > have to do is ignore the tag reserved-memory region. Tweaking the
> > > memory nodes would be more work.
> >
> > Right now, memory is added via memblock_reserve(), and if MTE is disabled
> > (for example, via the kernel command line), the code calls
> > free_reserved_page() for each tag storage page. I find that straightfoward
> > to implement.
> 
> But better to just not reserve the region in the first place. Also, it
> needs to be simple enough to back port.

I don't think that works - reserved memory is parsed in setup_arch ->
arm64_memblock_init, and the cpu capabilities are initialized later, in
smp_prepare_boot_cpu.

> 
> Also, does free_reserved_page() work on ranges outside of memblock
> range (e.g. beyond end_of_DRAM())? If the tag storage happened to live
> at the end of DRAM and you shorten the /memory node size to remove tag
> storage, is it still going to work?

Tag storage memory is discovered in 2 staged: first it is added to memblock
with memblock_add(), then reserved with memblock_reserve().  This is
performed in setup_arch(), after setup_machine_fdt(), and before
arm64_memblock_init(). The tag torage code keeps an array of the discovered
tag regions. This is implemented in this patch.

The next patch [1] adds an arch_initcall that checks if
memblock_end_of_DRAM() is less than the upper address of a tag storage
region. If that is the case, then tag storage memory is kept as reserved
and remains unused by the kernel.

The next check is for mte enabled: if it is disabled, then the pages are
unreserved by doing free_reserved_page().

And finally, if all the checks pass, the tag storage pages are put on the
MIGRATE_CMA lists with init_cma_reserved_pageblock().

[1] https://lore.kernel.org/all/20231119165721.9849-12-alexandru.elisei at arm.com/

Thanks,
Alex

> 
> Rob


From suzuki.poulose at arm.com  Mon Dec 18 03:02:46 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 18 Dec 2023 11:02:46 +0000
Subject: [PATCH v3 8/8] coresight-tpdm: Add msr register support for CMB
In-Reply-To: <1700533494-19276-9-git-send-email-quic_taozha@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-9-git-send-email-quic_taozha@quicinc.com>
Message-ID: <185b23e7-a42f-4a12-85ba-8a093bc5ea58@arm.com>

On 21/11/2023 02:24, Tao Zhang wrote:
> Add the nodes for CMB subunit MSR(mux select register) support.
> CMB MSRs(mux select registers) is to separate mux,arbitration,
> ,interleaving,data packing control from stream filtering control.
> 
> Reviewed-by: James Clark <james.clark at arm.com>
> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
> ---
>   .../testing/sysfs-bus-coresight-devices-tpdm  |  8 ++
>   drivers/hwtracing/coresight/coresight-tpdm.c  | 86 +++++++++++++++++++
>   drivers/hwtracing/coresight/coresight-tpdm.h  | 16 +++-
>   3 files changed, 109 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> index e0b77107be13..914f3fd81525 100644
> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> @@ -249,3 +249,11 @@ Description:
>   		Accepts only one of the 2 values -  0 or 1.
>   		0 : Disable the timestamp of all trace packets.
>   		1 : Enable the timestamp of all trace packets.
> +
> +What:		/sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31]
> +Date:		September 2023
> +KernelVersion	6.7
> +Contact:	Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang (QUIC) <quic_taozha at quicinc.com>
> +Description:
> +		(RW) Set/Get the MSR(mux select register) for the CMB subunit
> +		TPDM.
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index f6cda5616e84..7e331ea436cc 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -86,6 +86,11 @@ static ssize_t tpdm_simple_dataset_show(struct device *dev,
>   			return -EINVAL;
>   		return sysfs_emit(buf, "0x%x\n",
>   			drvdata->cmb->patt_mask[tpdm_attr->idx]);
> +	case CMB_MSR:
> +		if (tpdm_attr->idx >= drvdata->cmb_msr_num)
> +			return -EINVAL;
> +		return sysfs_emit(buf, "0x%x\n",
> +				drvdata->cmb->msr[tpdm_attr->idx]);
>   	}
>   	return -EINVAL;
>   }
> @@ -162,6 +167,12 @@ static ssize_t tpdm_simple_dataset_store(struct device *dev,
>   		else
>   			ret = -EINVAL;
>   		break;
> +	case CMB_MSR:
> +		if (tpdm_attr->idx < drvdata->cmb_msr_num)
> +			drvdata->cmb->msr[tpdm_attr->idx] = val;
> +		else
> +			ret = -EINVAL;


minor nit: Could we not break from here instead of adding return -EINVAL
for each case ? (I understand it has been done for the existing cases.
But I think we should clean up all of that, including the ones you added
in Patch 5. Similarly for the dataset_show()


Suzuki


> +		break;
>   	default:
>   		ret = -EINVAL;
>   	}
> @@ -220,6 +231,23 @@ static umode_t tpdm_dsb_msr_is_visible(struct kobject *kobj,
>   	return 0;
>   }
>   
> +static umode_t tpdm_cmb_msr_is_visible(struct kobject *kobj,
> +				       struct attribute *attr, int n)
> +{
> +	struct device *dev = kobj_to_dev(kobj);
> +	struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> +	struct device_attribute *dev_attr =
> +		container_of(attr, struct device_attribute, attr);
> +	struct tpdm_dataset_attribute *tpdm_attr =
> +		container_of(dev_attr, struct tpdm_dataset_attribute, attr);
> +
> +	if (tpdm_attr->idx < drvdata->cmb_msr_num)
> +		return attr->mode;
> +
> +	return 0;
> +}
> +
>   static void tpdm_reset_datasets(struct tpdm_drvdata *drvdata)
>   {
>   	if (tpdm_has_dsb_dataset(drvdata)) {
> @@ -361,6 +389,15 @@ static void set_cmb_tier(struct tpdm_drvdata *drvdata)
>   	writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>   }
>   
> +static void set_cmb_msr(struct tpdm_drvdata *drvdata)
> +{
> +	int i;
> +
> +	for (i = 0; i < drvdata->cmb_msr_num; i++)
> +		writel_relaxed(drvdata->cmb->msr[i],
> +			   drvdata->base + TPDM_CMB_MSR(i));
> +}
> +
>   static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>   {
>   	u32 val, i;
> @@ -379,6 +416,8 @@ static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>   
>   	set_cmb_tier(drvdata);
>   
> +	set_cmb_msr(drvdata);
> +
>   	val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>   	/*
>   	 * Set to 0 for continuous CMB collection mode,
> @@ -1084,6 +1123,42 @@ static struct attribute *tpdm_cmb_patt_attrs[] = {
>   	NULL,
>   };
>   
> +static struct attribute *tpdm_cmb_msr_attrs[] = {
> +	CMB_MSR_ATTR(0),
> +	CMB_MSR_ATTR(1),
> +	CMB_MSR_ATTR(2),
> +	CMB_MSR_ATTR(3),
> +	CMB_MSR_ATTR(4),
> +	CMB_MSR_ATTR(5),
> +	CMB_MSR_ATTR(6),
> +	CMB_MSR_ATTR(7),
> +	CMB_MSR_ATTR(8),
> +	CMB_MSR_ATTR(9),
> +	CMB_MSR_ATTR(10),
> +	CMB_MSR_ATTR(11),
> +	CMB_MSR_ATTR(12),
> +	CMB_MSR_ATTR(13),
> +	CMB_MSR_ATTR(14),
> +	CMB_MSR_ATTR(15),
> +	CMB_MSR_ATTR(16),
> +	CMB_MSR_ATTR(17),
> +	CMB_MSR_ATTR(18),
> +	CMB_MSR_ATTR(19),
> +	CMB_MSR_ATTR(20),
> +	CMB_MSR_ATTR(21),
> +	CMB_MSR_ATTR(22),
> +	CMB_MSR_ATTR(23),
> +	CMB_MSR_ATTR(24),
> +	CMB_MSR_ATTR(25),
> +	CMB_MSR_ATTR(26),
> +	CMB_MSR_ATTR(27),
> +	CMB_MSR_ATTR(28),
> +	CMB_MSR_ATTR(29),
> +	CMB_MSR_ATTR(30),
> +	CMB_MSR_ATTR(31),
> +	NULL,
> +};
> +
>   static struct attribute *tpdm_dsb_attrs[] = {
>   	&dev_attr_dsb_mode.attr,
>   	&dev_attr_dsb_trig_ts.attr,
> @@ -1144,6 +1219,12 @@ static struct attribute_group tpdm_cmb_patt_grp = {
>   	.name = "cmb_patt",
>   };
>   
> +static struct attribute_group tpdm_cmb_msr_grp = {
> +	.attrs = tpdm_cmb_msr_attrs,
> +	.is_visible = tpdm_cmb_msr_is_visible,
> +	.name = "cmb_msr",
> +};
> +
>   static const struct attribute_group *tpdm_attr_grps[] = {
>   	&tpdm_attr_grp,
>   	&tpdm_dsb_attr_grp,
> @@ -1154,6 +1235,7 @@ static const struct attribute_group *tpdm_attr_grps[] = {
>   	&tpdm_cmb_attr_grp,
>   	&tpdm_cmb_trig_patt_grp,
>   	&tpdm_cmb_patt_grp,
> +	&tpdm_cmb_msr_grp,
>   	NULL,
>   };
>   
> @@ -1192,6 +1274,10 @@ static int tpdm_probe(struct amba_device *adev, const struct amba_id *id)
>   		of_property_read_u32(drvdata->dev->of_node,
>   			   "qcom,dsb-msrs-num", &drvdata->dsb_msr_num);
>   
> +	if (drvdata && tpdm_has_cmb_dataset(drvdata))
> +		of_property_read_u32(drvdata->dev->of_node,
> +			   "qcom,cmb-msrs-num", &drvdata->cmb_msr_num);
> +
>   	/* Set up coresight component description */
>   	desc.name = coresight_alloc_device_name(&tpdm_devs, dev);
>   	if (!desc.name)
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
> index 65b7ca6c4077..255104d024ab 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
> @@ -21,6 +21,8 @@
>   #define TPDM_CMB_XPR(n)		(0xA18 + (n * 4))
>   /*CMB subunit trigger pattern mask registers*/
>   #define TPDM_CMB_XPMR(n)	(0xA20 + (n * 4))
> +/* CMB MSR register */
> +#define TPDM_CMB_MSR(n)		(0xA80 + (n * 4))
>   
>   /* Enable bit for CMB subunit */
>   #define TPDM_CMB_CR_ENA		BIT(0)
> @@ -36,6 +38,9 @@
>   /*Patten register number*/
>   #define TPDM_CMB_MAX_PATT		2
>   
> +/* MAX number of DSB MSR */
> +#define TPDM_CMB_MAX_MSR 32
> +
>   /* DSB Subunit Registers */
>   #define TPDM_DSB_CR		(0x780)
>   #define TPDM_DSB_TIER		(0x784)
> @@ -186,6 +191,10 @@
>   		tpdm_simple_dataset_rw(tpmr##nr,		\
>   		CMB_PATT_MASK, nr)
>   
> +#define CMB_MSR_ATTR(nr)					\
> +		tpdm_simple_dataset_rw(msr##nr,			\
> +		CMB_MSR, nr)
> +
>   /**
>    * struct dsb_dataset - specifics associated to dsb dataset
>    * @mode:             DSB programming mode
> @@ -225,6 +234,7 @@ struct dsb_dataset {
>    * @patt_mask:        Save value for pattern mask
>    * @trig_patt:        Save value for trigger pattern
>    * @trig_patt_mask:   Save value for trigger pattern mask
> + * @msr               Save value for MSR
>    * @patt_ts:          Indicates if pattern match for timestamp is enabled.
>    * @trig_ts:          Indicates if CTI trigger for timestamp is enabled.
>    * @ts_all:           Indicates if timestamp is enabled for all packets.
> @@ -235,6 +245,7 @@ struct cmb_dataset {
>   	u32			patt_mask[TPDM_CMB_MAX_PATT];
>   	u32			trig_patt[TPDM_CMB_MAX_PATT];
>   	u32			trig_patt_mask[TPDM_CMB_MAX_PATT];
> +	u32			msr[TPDM_CMB_MAX_MSR];
>   	bool			patt_ts;
>   	bool			trig_ts;
>   	bool			ts_all;
> @@ -251,6 +262,7 @@ struct cmb_dataset {
>    * @dsb         Specifics associated to TPDM DSB.
>    * @cmb         Specifics associated to TPDM CMB.
>    * @dsb_msr_num Number of MSR supported by DSB TPDM
> + * @cmb_msr_num Number of MSR supported by CMB TPDM
>    */
>   
>   struct tpdm_drvdata {
> @@ -263,6 +275,7 @@ struct tpdm_drvdata {
>   	struct dsb_dataset	*dsb;
>   	struct cmb_dataset	*cmb;
>   	u32			dsb_msr_num;
> +	u32			cmb_msr_num;
>   };
>   
>   /* Enumerate members of various datasets */
> @@ -277,7 +290,8 @@ enum dataset_mem {
>   	CMB_TRIG_PATT,
>   	CMB_TRIG_PATT_MASK,
>   	CMB_PATT,
> -	CMB_PATT_MASK
> +	CMB_PATT_MASK,
> +	CMB_MSR
>   };
>   
>   /**



From angelogioacchino.delregno at collabora.com  Mon Dec 18 03:05:24 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 18 Dec 2023 12:05:24 +0100
Subject: [PATCH v2 3/3] mailbox: mtk-cmdq: Add CMDQ driver support for
 mt8188
In-Reply-To: <20231215070026.2507-4-jason-jh.lin@mediatek.com>
References: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
 <20231215070026.2507-4-jason-jh.lin@mediatek.com>
Message-ID: <2e16d209-8b19-4f6b-8406-bbe93ab05124@collabora.com>

Il 15/12/23 08:00, Jason-JH.Lin ha scritto:
> Add CMDQ driver support for mt8188 by adding its compatible and
> driver data in CMDQ driver.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>



From angelogioacchino.delregno at collabora.com  Mon Dec 18 03:05:25 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 18 Dec 2023 12:05:25 +0100
Subject: [PATCH v2 2/3] mailbox: mtk-cmdq: Sort cmdq platform data by
 compatible name
In-Reply-To: <20231215070026.2507-3-jason-jh.lin@mediatek.com>
References: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
 <20231215070026.2507-3-jason-jh.lin@mediatek.com>
Message-ID: <0ff37f8a-5531-46cc-b078-60843bb753a2@collabora.com>

Il 15/12/23 08:00, Jason-JH.Lin ha scritto:
> Sort cmdq platform data according to the number sequence of
> compatible names.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Mon Dec 18 03:05:27 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Mon, 18 Dec 2023 12:05:27 +0100
Subject: [PATCH v2 1/3] mailbox: mtk-cmdq: Rename gce_plat variable with
 SoC name postfix
In-Reply-To: <20231215070026.2507-2-jason-jh.lin@mediatek.com>
References: <20231215070026.2507-1-jason-jh.lin@mediatek.com>
 <20231215070026.2507-2-jason-jh.lin@mediatek.com>
Message-ID: <10fd4fef-e71a-44bc-b80a-a4801e730039@collabora.com>

Il 15/12/23 08:00, Jason-JH.Lin ha scritto:
> Rename gce_plat variable postfix from 'v1~v7' to SoC names.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From fusibrandon13 at gmail.com  Mon Dec 18 03:05:38 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Mon, 18 Dec 2023 12:05:38 +0100
Subject: [PATCH v2 0/5] cpufreq support for the D1
Message-ID: <20231218110543.64044-1-fusibrandon13@gmail.com>

This patch series adds support for cpufreq on the D1 SoC, and has been
tested on a Lichee RV module.

Changes in v2:
- Revert opp-microvolt-speed0 property to <target min max>
- Add dt-bindings for "allwinner,sun50i-h6-operating-points"
- Enable sun50i h6 cpufreq multiarch support by moving Kconfig option
  to drivers/cpufreq/Kconfig instead of creating
  drivers/cpufreq/Kconfig.riscv

Brandon Cheo Fusi (5):
  riscv: dts: allwinner: Update opp table to allow CPU frequency scaling
  dt-bindings: opp: sun50i: Add binding for D1 CPUs
  cpufreq: sun50i: Add D1 support
  cpufreq: dt-platdev: Blocklist allwinner,sun20i-d1 SoC
  cpufreq: Make sun50i h6 cpufreq Kconfig option arch generic

 .../allwinner,sun50i-h6-operating-points.yaml  |  4 +++-
 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi  | 18 +++++++++++++++---
 drivers/cpufreq/Kconfig                        | 12 ++++++++++++
 drivers/cpufreq/Kconfig.arm                    | 12 ------------
 drivers/cpufreq/Makefile                       |  2 +-
 drivers/cpufreq/cpufreq-dt-platdev.c           |  1 +
 drivers/cpufreq/sun50i-cpufreq-nvmem.c         |  1 +
 7 files changed, 33 insertions(+), 17 deletions(-)

-- 
2.30.2



From fusibrandon13 at gmail.com  Mon Dec 18 03:05:39 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Mon, 18 Dec 2023 12:05:39 +0100
Subject: [PATCH v2 1/5] riscv: dts: allwinner: Update opp table to allow CPU frequency scaling
In-Reply-To: <20231218110543.64044-1-fusibrandon13@gmail.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
Message-ID: <20231218110543.64044-2-fusibrandon13@gmail.com>

Two OPPs are currently defined for the D1/D1s; one at 408MHz and
another at 1.08GHz. Switching between these can be done with the
"sun50i-cpufreq-nvmem" driver. This patch populates the opp table
appropriately, inspired by
https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi

The supply voltages are PWM-controlled, but support for that IP
is still in the works. So stick to a target vdd-cpu supply of 0.9V,
which seems to be the default on most D1 boards.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
index 64c3c2e6c..2f1771c19 100644
--- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
+++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
@@ -39,16 +39,22 @@ cpu0_intc: interrupt-controller {
 	};
 
 	opp_table_cpu: opp-table-cpu {
-		compatible = "operating-points-v2";
+		compatible = "allwinner,sun20i-d1-operating-points",
+				 "allwinner,sun50i-h6-operating-points";
+		nvmem-cells = <&cpu_speed_grade>;
+		nvmem-cell-names = "speed";
+		opp-shared;
 
 		opp-408000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <900000 900000 1100000>;
+			opp-microvolt-speed0 = <900000 900000 1100000>;
 		};
 
 		opp-1080000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
 			opp-hz = /bits/ 64 <1008000000>;
-			opp-microvolt = <900000 900000 1100000>;
+			opp-microvolt-speed0 = <900000 900000 1100000>;
 		};
 	};
 
@@ -115,3 +121,9 @@ pmu {
 			<0x00000000 0x0000000f 0xffffffff 0xffffffff 0x00020000>;
 	};
 };
+
+&sid {
+	cpu_speed_grade: cpu-speed-grade at 0 {
+		reg = <0x00 0x2>;
+	};
+};
-- 
2.30.2



From fusibrandon13 at gmail.com  Mon Dec 18 03:05:40 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Mon, 18 Dec 2023 12:05:40 +0100
Subject: [PATCH v2 2/5] dt-bindings: opp: sun50i: Add binding for D1 CPUs
In-Reply-To: <20231218110543.64044-1-fusibrandon13@gmail.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
Message-ID: <20231218110543.64044-3-fusibrandon13@gmail.com>

Add binding for D1 CPU OPPs.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 .../bindings/opp/allwinner,sun50i-h6-operating-points.yaml    | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
index 51f62c3ae..fddaa3216 100644
--- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
+++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
@@ -23,7 +23,9 @@ allOf:
 
 properties:
   compatible:
-    const: allwinner,sun50i-h6-operating-points
+    enum:
+      - allwinner,sun50i-h6-operating-points
+      - allwinner,sun20i-d1-operating-points
 
   nvmem-cells:
     description: |
-- 
2.30.2



From fusibrandon13 at gmail.com  Mon Dec 18 03:05:41 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Mon, 18 Dec 2023 12:05:41 +0100
Subject: [PATCH v2 3/5] cpufreq: sun50i: Add D1 support
In-Reply-To: <20231218110543.64044-1-fusibrandon13@gmail.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
Message-ID: <20231218110543.64044-4-fusibrandon13@gmail.com>

Add support for D1 based devices to the Allwinner H6 cpufreq
driver

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/sun50i-cpufreq-nvmem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 32a9c88f8..ccf83780f 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -160,6 +160,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
 
 static const struct of_device_id sun50i_cpufreq_match_list[] = {
 	{ .compatible = "allwinner,sun50i-h6" },
+	{ .compatible = "allwinner,sun20i-d1" },
 	{}
 };
 MODULE_DEVICE_TABLE(of, sun50i_cpufreq_match_list);
-- 
2.30.2



From fusibrandon13 at gmail.com  Mon Dec 18 03:05:42 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Mon, 18 Dec 2023 12:05:42 +0100
Subject: [PATCH v2 4/5] cpufreq: dt-platdev: Blocklist allwinner,sun20i-d1 SoC
In-Reply-To: <20231218110543.64044-1-fusibrandon13@gmail.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
Message-ID: <20231218110543.64044-5-fusibrandon13@gmail.com>

The Allwinner D1 uses H6 cpufreq driver. Add it to blocklist
so the "cpufreq-dt" device is not created twice.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index bd1e1357c..2febcfc2c 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -104,6 +104,7 @@ static const struct of_device_id allowlist[] __initconst = {
  */
 static const struct of_device_id blocklist[] __initconst = {
 	{ .compatible = "allwinner,sun50i-h6", },
+	{ .compatible = "allwinner,sun20i-d1", },
 
 	{ .compatible = "apple,arm-platform", },
 
-- 
2.30.2



From fusibrandon13 at gmail.com  Mon Dec 18 03:05:43 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Mon, 18 Dec 2023 12:05:43 +0100
Subject: [PATCH v2 5/5] cpufreq: Make sun50i h6 cpufreq Kconfig option arch generic
In-Reply-To: <20231218110543.64044-1-fusibrandon13@gmail.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
Message-ID: <20231218110543.64044-6-fusibrandon13@gmail.com>

Move the Allwinner SUN50I cpufreq driver from Kconfig.arm to the
main Kconfig file so it supports other architectures, like RISC-V
in our case, and drop the 'ARM_' prefix.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/Kconfig     | 12 ++++++++++++
 drivers/cpufreq/Kconfig.arm | 12 ------------
 drivers/cpufreq/Makefile    |  2 +-
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 35efb53d5..50aa66cfc 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -301,5 +301,17 @@ config QORIQ_CPUFREQ
 	  This adds the CPUFreq driver support for Freescale QorIQ SoCs
 	  which are capable of changing the CPU's frequency dynamically.
 
+config ALLWINNER_SUN50I_CPUFREQ_NVMEM
+	tristate "Allwinner nvmem based SUN50I CPUFreq driver"
+	depends on ARCH_SUNXI
+	depends on NVMEM_SUNXI_SID
+	select PM_OPP
+	help
+	  This adds the nvmem based CPUFreq driver for Allwinner
+	  h6/D1 SoCs.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called sun50i-cpufreq-nvmem.
+
 endif
 endmenu
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index f91160689..98b8e6eef 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -29,18 +29,6 @@ config ACPI_CPPC_CPUFREQ_FIE
 
 	  If in doubt, say N.
 
-config ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM
-	tristate "Allwinner nvmem based SUN50I CPUFreq driver"
-	depends on ARCH_SUNXI
-	depends on NVMEM_SUNXI_SID
-	select PM_OPP
-	help
-	  This adds the nvmem based CPUFreq driver for Allwinner
-	  h6 SoC.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called sun50i-cpufreq-nvmem.
-
 config ARM_APPLE_SOC_CPUFREQ
 	tristate "Apple Silicon SoC CPUFreq support"
 	depends on ARCH_APPLE || (COMPILE_TEST && 64BIT)
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d141c71b..110b676d2 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -78,7 +78,7 @@ obj-$(CONFIG_ARM_SCMI_CPUFREQ)		+= scmi-cpufreq.o
 obj-$(CONFIG_ARM_SCPI_CPUFREQ)		+= scpi-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
 obj-$(CONFIG_ARM_STI_CPUFREQ)		+= sti-cpufreq.o
-obj-$(CONFIG_ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM) += sun50i-cpufreq-nvmem.o
+obj-$(CONFIG_ALLWINNER_SUN50I_CPUFREQ_NVMEM) += sun50i-cpufreq-nvmem.o
 obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)	+= tegra20-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)	+= tegra124-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA186_CPUFREQ)	+= tegra186-cpufreq.o
-- 
2.30.2



From maz at kernel.org  Mon Dec 18 03:12:43 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 18 Dec 2023 11:12:43 +0000
Subject: [PATCH v3 14/17] KVM: arm64: Macros for setting/clearing FGT bits
In-Reply-To: <CA+EHjTxZmc2bAaDbFLjWxx-LzCX7Jwy+EH60JgFBvWYh68U=xg@mail.gmail.com>
References: <20231214100158.2305400-1-tabba@google.com>
	<20231214100158.2305400-15-tabba@google.com>
	<86wmtbalx9.wl-maz@kernel.org>
	<CA+EHjTxZmc2bAaDbFLjWxx-LzCX7Jwy+EH60JgFBvWYh68U=xg@mail.gmail.com>
Message-ID: <86v88vahn8.wl-maz@kernel.org>

On Mon, 18 Dec 2023 09:56:32 +0000,
Fuad Tabba <tabba at google.com> wrote:
> 
> Hi Marc,
> 
> On Mon, Dec 18, 2023 at 9:40?AM Marc Zyngier <maz at kernel.org> wrote:
> >
> > On Thu, 14 Dec 2023 10:01:54 +0000,
> > Fuad Tabba <tabba at google.com> wrote:
> > >
> > > There's a lot of boilerplate code for setting and clearing FGT
> > > bits when activating guest traps. Refactor it into macros. These
> > > macros will also be used in future patch series.
> > >
> > > No functional change intended.
> > >
> > > Signed-off-by: Fuad Tabba <tabba at google.com>
> > > ---
> > >  arch/arm64/kvm/hyp/include/hyp/switch.h | 60 +++++++++----------------
> > >  1 file changed, 21 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > > index 17ce40f5b006..e223fc0d5193 100644
> > > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> > > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > > @@ -79,6 +79,23 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
> > >               clr |= ~hfg & __ ## reg ## _nMASK;                      \
> > >       } while(0)
> > >
> > > +#define update_fgt_traps_cs(reg, clr, set)                           \
> > > +     do {                                                            \
> > > +             struct kvm_cpu_context *hctxt =                         \
> > > +                     &this_cpu_ptr(&kvm_host_data)->host_ctxt;       \
> > > +             u64 val, c = 0, s = 0;                                  \
> > > +                                                                     \
> > > +             ctxt_sys_reg(hctxt, reg) = read_sysreg_s(SYS_ ## reg);  \
> > > +             compute_clr_set(vcpu, reg, c, s);                       \
> >
> > You are referring to a variable name that is in the scope of the macro
> > user, and not the macro itself. It is so fragile it isn't funny.
> >
> > Why don't you simply pass the vcpu as a parameter to the function?
> >
> > Another thing is that this read/write can be expensive. How about not
> > doing anything when there is no change to the value of the sysreg?
> 
> What do you think of this (spacing will be fixed):
> 
> #define update_fgt_traps_cs(vcpu, reg, clr, set)                         \
>     do {
>                            \
>         struct kvm_cpu_context *hctxt =
>          \
>             &this_cpu_ptr(&kvm_host_data)->host_ctxt;                  \
>         u64 val, c = 0, s = 0;
>                   \
> 
>                              \
>         ctxt_sys_reg(hctxt, reg) = read_sysreg_s(SYS_ ## reg);   \
>         compute_clr_set(vcpu, reg, c, s);
>           \
>         val = __ ## reg ## _nMASK;
>           \
>         val |= (s | set);
>                         \
>         val &= ~(c | clr);
>                        \
>         if (ctxt_sys_reg(hctxt, reg) != val)
>               \
>             write_sysreg_s(val, SYS_ ## reg);
>            \
>     } while(0)
> 
> If it looks good to you, I'll fix it on the respin.

This is what I have on top at the moment:

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 27077e1f7de2..d56fef44dc31 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -79,22 +79,26 @@ static inline void __activate_traps_fpsimd32(struct kvm_vcpu *vcpu)
 		clr |= ~hfg & __ ## reg ## _nMASK; 			\
 	} while(0)
 
-#define update_fgt_traps_cs(reg, clr, set)				\
+#define update_fgt_traps_cs(vcpu, reg, clr, set)			\
 	do {								\
 		struct kvm_cpu_context *hctxt =				\
 			&this_cpu_ptr(&kvm_host_data)->host_ctxt;	\
-		u64 val, c = 0, s = 0;					\
+		u64 c = 0, s = 0;					\
 									\
 		ctxt_sys_reg(hctxt, reg) = read_sysreg_s(SYS_ ## reg);	\
 		compute_clr_set(vcpu, reg, c, s);			\
-		val = __ ## reg ## _nMASK;				\
-		val |= (s | set);					\
-		val &= ~(c | clr);					\
-		write_sysreg_s(val, SYS_ ## reg);			\
+		s |= set;						\
+		c |= clr;						\
+		if (c || s) {						\
+			u64 val = __ ## reg ## _nMASK;			\
+			val |= s;					\
+			val &= ~c;					\
+			write_sysreg_s(val, SYS_ ## reg);		\
+		}							\
 	} while(0)
 
-#define update_fgt_traps(reg)						\
-	update_fgt_traps_cs(reg, 0, 0)
+#define update_fgt_traps(vcpu, reg)		\
+	update_fgt_traps_cs(vcpu, reg, 0, 0)
 
 /*
  * Validate the fine grain trap masks.
@@ -171,9 +175,9 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 	if (!vcpu_has_nv(vcpu) || is_hyp_ctxt(vcpu))
 		return;
 
-	update_fgt_traps(HFGITR_EL2);
-	update_fgt_traps(HDFGRTR_EL2);
-	update_fgt_traps(HDFGWTR_EL2);
+	update_fgt_traps(vcpu, HFGITR_EL2);
+	update_fgt_traps(vcpu, HDFGRTR_EL2);
+	update_fgt_traps(vcpu, HDFGWTR_EL2);
 
 	if (cpu_has_amu())
 		update_fgt_traps(vcpu, HAFGRTR_EL2);

If that seems sensible to you, I'll fold it in, as I'd like to do
without a respin if we can avoid it.

`	M.

-- 
Without deviation from the norm, progress is not possible.


From andre.przywara at arm.com  Mon Dec 18 03:14:04 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 18 Dec 2023 11:14:04 +0000
Subject: [PATCH v1] thermal: sun8i: extend H6 calibration function to
 support 4 sensors
In-Reply-To: <20231217133637.54773-1-bigunclemax@gmail.com>
References: <20231217133637.54773-1-bigunclemax@gmail.com>
Message-ID: <20231218111404.5f08a4c4@donnerap.manchester.arm.com>

On Sun, 17 Dec 2023 16:36:36 +0300
Maksim Kiselev <bigunclemax at gmail.com> wrote:

Hi Maksim,

many thanks for sending this!

> The H616 SoC resembles the H6 thermal sensor controller, with a few
> changes like four sensors.
> 
> Extend sun50i_h6_ths_calibrate() function to support calibration of
> these sensors.

Oh wow, I didn't expect that, but it's indeed that simple: we just need to
cater for the 4th sensor's data to be cramped into the other bits, the
rest is exactly the same! Well spotted!

> Signed-off-by: Martin Botka <martin.botka at somainline.org>
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

I don't think the Signed-off-by:s are accurate here. Please replace those
two with just:
Co-developed-by: Martin Botka <martin.botka at somainline.org>
(I didn't really do anything in those parts)

> Signed-off-by: Maksim Kiselev <bigunclemax at gmail.com>

I compared the two routines and came to the same solution as you, so:

Reviewed-by: Andre Przywara <andre.przywara at arm.com>

I will incorporate this patch into the next submission of the H616 THS
series, so there is no need to merge this patch as is.

Cheers,
Andre

> ---
>  drivers/thermal/sun8i_thermal.c | 28 ++++++++++++++++++++--------
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> index f989b55a8aa8..9af95b4785be 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -221,16 +221,21 @@ static int sun50i_h6_ths_calibrate(struct ths_device *tmdev,
>  	struct device *dev = tmdev->dev;
>  	int i, ft_temp;
>  
> -	if (!caldata[0] || callen < 2 + 2 * tmdev->chip->sensor_num)
> +	if (!caldata[0])
>  		return -EINVAL;
>  
>  	/*
>  	 * efuse layout:
>  	 *
> -	 *	0   11  16	 32
> -	 *	+-------+-------+-------+
> -	 *	|temp|  |sensor0|sensor1|
> -	 *	+-------+-------+-------+
> +	 * 0      11  16     27   32     43   48    57
> +	 * +----------+-----------+-----------+-----------+
> +	 * |  temp |  |sensor0|   |sensor1|   |sensor2|   |
> +	 * +----------+-----------+-----------+-----------+
> +	 *                      ^           ^           ^
> +	 *                      |           |           |
> +	 *                      |           |           sensor3[11:8]
> +	 *                      |           sensor3[7:4]
> +	 *                      sensor3[3:0]
>  	 *
>  	 * The calibration data on the H6 is the ambient temperature and
>  	 * sensor values that are filled during the factory test stage.
> @@ -243,9 +248,16 @@ static int sun50i_h6_ths_calibrate(struct ths_device *tmdev,
>  	ft_temp = (caldata[0] & FT_TEMP_MASK) * 100;
>  
>  	for (i = 0; i < tmdev->chip->sensor_num; i++) {
> -		int sensor_reg = caldata[i + 1] & TEMP_CALIB_MASK;
> -		int cdata, offset;
> -		int sensor_temp = tmdev->chip->calc_temp(tmdev, i, sensor_reg);
> +		int sensor_reg, sensor_temp, cdata, offset;
> +
> +		if (i == 3)
> +			sensor_reg = (caldata[1] >> 12)
> +				     | ((caldata[2] >> 12) << 4)
> +				     | ((caldata[3] >> 12) << 8);
> +		else
> +			sensor_reg = caldata[i + 1] & TEMP_CALIB_MASK;
> +
> +		sensor_temp = tmdev->chip->calc_temp(tmdev, i, sensor_reg);
>  
>  		/*
>  		 * Calibration data is CALIBRATE_DEFAULT - (calculated



From tabba at google.com  Mon Dec 18 03:17:55 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 18 Dec 2023 11:17:55 +0000
Subject: [PATCH v3 14/17] KVM: arm64: Macros for setting/clearing FGT bits
In-Reply-To: <86v88vahn8.wl-maz@kernel.org>
References: <20231214100158.2305400-1-tabba@google.com> <20231214100158.2305400-15-tabba@google.com>
 <86wmtbalx9.wl-maz@kernel.org> <CA+EHjTxZmc2bAaDbFLjWxx-LzCX7Jwy+EH60JgFBvWYh68U=xg@mail.gmail.com>
 <86v88vahn8.wl-maz@kernel.org>
Message-ID: <CA+EHjTyPS-3PX+JGV32oTTMYJPk3Dijbcj3oAENg3v7sAdw7wA@mail.gmail.com>

Hi Marc,

On Mon, Dec 18, 2023 at 11:12?AM Marc Zyngier <maz at kernel.org> wrote:
...
>         if (cpu_has_amu())
>                 update_fgt_traps(vcpu, HAFGRTR_EL2);
>
> If that seems sensible to you, I'll fold it in, as I'd like to do
> without a respin if we can avoid it.

Looks good to me. Thanks Marc!
/fuad

>
> `       M.
>
> --
> Without deviation from the norm, progress is not possible.


From quic_bibekkum at quicinc.com  Mon Dec 18 03:23:04 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Mon, 18 Dec 2023 16:53:04 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
 <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
Message-ID: <aa8b2ccd-33da-404b-9a93-3d88cf63ec77@quicinc.com>



On 12/16/2023 9:45 PM, Dmitry Baryshkov wrote:
> On 16/12/2023 02:03, Konrad Dybcio wrote:
>> On 15.12.2023 13:54, Robin Murphy wrote:
>>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>>>
>>>>
>>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>>>> <quic_bibekkum at quicinc.com> wrote:
>>>>>>
>>>>>> Add ACTLR data table for SM8550 along with support for
>>>>>> same including SM8550 specific implementation operations.
>>>>>>
>>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>>>> ---
>>>>>> ?? drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 
>>>>>> ++++++++++++++++++++++
>>>>>> ?? 1 file changed, 89 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
>>>>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>> index cb49291f5233..d2006f610243 100644
>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>>>> ????????? u32 actlr;
>>>>>> ?? };
>>>>>>
>>>>>> +/*
>>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching 
>>>>>> in the
>>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the 
>>>>>> prefetch
>>>>>> + * buffer). The remaining bits are implementation defined and 
>>>>>> vary across
>>>>>> + * SoCs.
>>>>>> + */
>>>>>> +
>>>>>> +#define PREFETCH_DEFAULT?????? 0
>>>>>> +#define PREFETCH_SHALLOW?????? BIT(8)
>>>>>> +#define PREFETCH_MODERATE????? BIT(9)
>>>>>> +#define PREFETCH_DEEP????????? (BIT(9) | BIT(8))
>>>>>
>>>>> I thin the following might be more correct:
>>>>>
>>>>> #include <linux/bitfield.h>
>>>>>
>>>>> #define PREFETCH_MASK GENMASK(9, 8)
>>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>>>
>>>>
>>>> Ack, thanks for this suggestion. Let me try this out using
>>>> GENMASK. Once tested, will take care of this in next version.
>>>
>>> FWIW the more typical usage would be to just define the named macros 
>>> for the raw field values, then put the FIELD_PREP() at the point of 
>>> use. However in this case that's liable to get pretty verbose, so 
>>> although I'm usually a fan of bitfield.h, the most readable option 
>>> here might actually be to stick with simpler definitions of "(0 << 
>>> 8)", "(1 << 8)", etc. However it's not really a big deal either way, 
>>> and I defer to whatever Dmitry and Konrad prefer, since they're the 
>>> ones looking after arm-smmu-qcom the most :)
>> My 5 cents would be to just use the "common" style of doing this, so:
>>
>> #define ACTRL_PREFETCH??? GENMASK(9, 8)
>> ? #define PREFETCH_DEFAULT 0
>> ? #define PREFETCH_SHALLOW 1
>> ? #define PREFETCH_MODERATE 2
>> ? #define PREFETCH_DEEP 3
>>
>> and then use
>>
>> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
>>
>> it can get verbose, but.. arguably that's good, since you really want
>> to make sure the right bits are set here
> 
> Sounds good to me.
> 

Konrad, Dimitry, just checked FIELD_PREP() implementation

#define FIELD_FIT(_mask, _val)
({                                                              \
                  __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");  \
                  ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
})

since it is defined as a block, it won't be possible to use FIELD_PREP
in macro or as a structure value, and can only be used inside a 
block/function. Orelse would show compilation errors as following

kernel/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c:94:20: note: in 
expansion of macro 'PREFETCH_SHALLOW'
   { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
                     ^
kernel/include/linux/bitfield.h:113:2: error: braced-group within 
expression allowed only inside a function
   ({        \
   ^

So as per my understanding I think, we might need to go ahead with the
generic implementation only. Let me know if I missed something.

Thanks,
Bibek




From quic_tingweiz at quicinc.com  Mon Dec 18 03:23:37 2023
From: quic_tingweiz at quicinc.com (Tingwei Zhang)
Date: Mon, 18 Dec 2023 19:23:37 +0800
Subject: [PATCH v3 7/8] dt-bindings: arm: Add support for TPDM CMB MSR
 register
In-Reply-To: <1d57590d-2ecf-4bf6-9c8f-2a9d1ba08aaa@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-8-git-send-email-quic_taozha@quicinc.com>
 <e5fbbfab-02bf-4eda-8353-87c54c307af1@linaro.org>
 <1d57590d-2ecf-4bf6-9c8f-2a9d1ba08aaa@arm.com>
Message-ID: <caa424d3-7af0-43e6-8e13-e87cde0c4f67@quicinc.com>

On 12/18/2023 6:47 PM, Suzuki K Poulose wrote:
> Tao Zhang,
> 
> On 21/11/2023 07:24, Krzysztof Kozlowski wrote:
>> On 21/11/2023 03:24, Tao Zhang wrote:
>>> Add property "qcom,cmb_msr_num" to support CMB MSR(mux select register)
>>> for TPDM. It specifies the number of CMB MSR registers supported by
>>> the TDPM.
>>>
>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>>> ---
>>
>> I prefer not to take any new Qualcomm Coresight bindings or Qualcomm SoC
>> DTS nodes with Coresight till we fix all existing warnings. I don't know
>> how to fix them, so I need help with them. No such fixing happened so
>> far from Qcom, so pushback is my only way to get any attention.
>>
>> I already commented on this in other email thread.
> 
> Are you addressing this ?
The DT warning is fixed in 
https://lore.kernel.org/linux-arm-msm/20231210072633.4243-1-quic_jinlmao at quicinc.com/.
It's applied to linux-arm-msm yesterday.
> 
> Suzuki
> 
>>
>> Best regards,
>> Krzysztof
>>
> 

-- 
Thanks,
Tingwei



From cristian.ciocaltea at collabora.com  Mon Dec 18 03:38:10 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 13:38:10 +0200
Subject: [PATCH v2 12/12] [UNTESTED] riscv: dts: starfive:
 beaglev-starlight: Enable gmac
In-Reply-To: <CAJM55Z-e8mkjac-nCF9_w6EmMVbL9ued0mAcjwTMF=pKDLkMsA@mail.gmail.com>
References: <20231029042712.520010-1-cristian.ciocaltea@collabora.com>
 <20231029042712.520010-13-cristian.ciocaltea@collabora.com>
 <CAJM55Z9e=vjGKNnmURN15mvXo2bVd3igBA-3puF9q7eh5hiP+A@mail.gmail.com>
 <2f06ce36-0dc1-495e-b6a6-318951a53e8d@collabora.com>
 <698fbb5d-0750-4f2a-857f-5429e5f589f9@collabora.com>
 <CAJM55Z-e8mkjac-nCF9_w6EmMVbL9ued0mAcjwTMF=pKDLkMsA@mail.gmail.com>
Message-ID: <a06aaab5-b433-44a6-89a4-bdf713d5e1a9@collabora.com>

On 12/16/23 21:24, Emil Renner Berthing wrote:
> Cristian Ciocaltea wrote:
>> On 11/28/23 02:40, Cristian Ciocaltea wrote:
>>> On 11/26/23 23:10, Emil Renner Berthing wrote:
>>>> Cristian Ciocaltea wrote:
>>>>> The BeagleV Starlight SBC uses a Microchip KSZ9031RNXCA PHY supporting
>>>>> RGMII-ID.
>>>>>
>>
>> [...]
>>
>>>> You've alse removed the phy reset gpio on the Starlight board:
>>>>
>>>>   snps,reset-gpios = <&gpio 63 GPIO_ACTIVE_LOW>
>>>>
>>>> Why?
>>>
>>> I missed this in v1 as the gmac handling was done exclusively in
>>> jh7100-common. Thanks for noticing!
>>
>> Hi Emil,
>>
>> I think the reset doesn't actually trigger because "snps,reset-gpios" is
>> not a valid property, it should have been "snps,reset-gpio" (without the
>> trailing "s").
>>
>> However, this seems to be deprecated now, and the recommended approach
>> would be to define the reset gpio in the phy node, which I did in [1].
>>
>> Hopefully this won't cause any unexpected behaviour. Otherwise we should
>> probably simply drop it.
>>
>> [1]: https://lore.kernel.org/lkml/20231215204050.2296404-8-cristian.ciocaltea at collabora.com/
> 
> Oh, nice catch! With your v3 patches the Starlight board still works fine and
> GPIO63 is correctly grabbed and used for "PHY reset".

Great, thanks a lot for retesting this!


From sumang at marvell.com  Mon Dec 18 03:39:16 2023
From: sumang at marvell.com (Suman Ghosh)
Date: Mon, 18 Dec 2023 11:39:16 +0000
Subject: [EXT] [PATCH net 1/1] net: stmmac: fix incorrect flag check in
 timestamp interrupt
In-Reply-To: <1702883201-29632-1-git-send-email-jun.ann.lai@intel.com>
References: <1702883201-29632-1-git-send-email-jun.ann.lai@intel.com>
Message-ID: <SJ0PR18MB52162CA0724044E15A9E0FD8DB90A@SJ0PR18MB5216.namprd18.prod.outlook.com>

>----------------------------------------------------------------------
>The driver should continue get the timestamp if
>STMMAC_FLAG_EXT_SNAPSHOT_EN flag is set.
>
[Suman] Hi Lai,
Please ad the "fixes" tag

>Signed-off-by: Song Yoong Siang <yoong.siang.song at intel.com>
>Signed-off-by: Lai Peter Jun Ann <jun.ann.lai at intel.com>


From quic_bibekkum at quicinc.com  Mon Dec 18 03:40:33 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Mon, 18 Dec 2023 17:10:33 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <e4329952-34ac-4458-a63c-1f64e288614c@linaro.org>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <e4329952-34ac-4458-a63c-1f64e288614c@linaro.org>
Message-ID: <281a46c1-ce2a-4986-8562-878c7267efd0@quicinc.com>



On 12/16/2023 5:05 AM, Konrad Dybcio wrote:
> On 15.12.2023 11:18, Bibek Kumar Patro wrote:
>> Add ACTLR data table for SM8550 along with support for
>> same including SM8550 specific implementation operations.
>>
>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>> ---
> [...]
> 
>> +static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
>> +	.impl = &qcom_smmu_500_impl,
>> +	.adreno_impl = &qcom_adreno_smmu_500_impl,
>> +	.cfg = &qcom_smmu_impl0_cfg,
>> +	.actlrcfg = sm8550_apps_actlr_cfg,
>> +	.actlrcfg_gfx = sm8550_gfx_actlr_cfg,
> There are platforms that feature more than just APPS and Adreno SMMUs,
> this implementation seems to assume there's only these two :/
> 

Yes, some platforms can feature additional SMMUs as well including APPS 
and Adreno. In that case there would be a corresponding compatible 
string and an additional field in qcom_smmu_match_data might be needed.

Thanks,
Bibek

> I suppose the only way to solve this would be to introduce new compatibles
> for each one of them.. Krzysztof, do you think that's reasonable? E.g.
> MSM8996 has at least 5 instances, 8998 has at least 4 etc.
> 
> Konrad


From cristian.ciocaltea at collabora.com  Mon Dec 18 03:41:53 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 13:41:53 +0200
Subject: [PATCH v3 5/9] riscv: dts: starfive: jh7100-common: Setup pinmux
 and enable gmac
In-Reply-To: <CAJM55Z-bg0EGPaLHtxcu2AzqN59zfuiT0eE7oCShrx7dG_QK1g@mail.gmail.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-6-cristian.ciocaltea@collabora.com>
 <CAJM55Z-bg0EGPaLHtxcu2AzqN59zfuiT0eE7oCShrx7dG_QK1g@mail.gmail.com>
Message-ID: <cb18617d-e34a-4c3e-a37a-1b051587f8b5@collabora.com>

On 12/16/23 21:38, Emil Renner Berthing wrote:
> Cristian Ciocaltea wrote:
>> Add pinmux configuration for DWMAC found on the JH7100 based boards and
>> enable the related DT node, providing a basic PHY configuration.
>>
>> Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
>> Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>> ---
>>  .../boot/dts/starfive/jh7100-common.dtsi      | 85 +++++++++++++++++++
>>  1 file changed, 85 insertions(+)
>>
>> diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
>> index 42fb61c36068..5cafe8f5c2e7 100644
>> --- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
>> +++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
>> @@ -72,7 +72,92 @@ wifi_pwrseq: wifi-pwrseq {
>>  	};
>>  };
>>
>> +&gmac {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&gmac_pins>;
>> +	phy-mode = "rgmii-id";
>> +	phy-handle = <&phy>;
> 
> I'm not sure if it's a generic policy or not, but I don't really like adding a
> reference to a non-existant node here. I'd move this property to the board
> files where the phy node is actually defined.

Totally agree, I simply went too far while dropping duplicated code and
didn't realize the mistake.  Thanks for noticing!


From glider at google.com  Mon Dec 18 03:42:32 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 12:42:32 +0100
Subject: [PATCH v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <ZXyGbhJqzNxbd3ay@yury-ThinkPad>
References: <20231214110639.2294687-1-glider@google.com> <20231214110639.2294687-5-glider@google.com>
 <ZXtircr4TllpqyeS@yury-ThinkPad> <CAG_fn=WcrNqV4burBRPZZwoBLwgia7kerZ8g2vV5spzWF=houQ@mail.gmail.com>
 <ZXyAXPxlmq11rp2Y@yury-ThinkPad> <ZXyGbhJqzNxbd3ay@yury-ThinkPad>
Message-ID: <CAG_fn=UXhBYNoiSOO8mAjo4FA0Q3hD8FsPgf8F6Z3cCe7pNkVw@mail.gmail.com>

> > Data and *data have their meaning across scope boundary: a pointer and
> > a content. The &data is pretty much a random number - a pointer to
> > somewhere on a function's stack. Isn't?
>
> OK, I read now. Your 'void *data' is not a pointer, but an actual data.
> Very confusing indeed... Maybe add a comment for that cast?
>
Sure, will do.


From paul at crapouillou.net  Mon Dec 18 03:43:28 2023
From: paul at crapouillou.net (Paul Cercueil)
Date: Mon, 18 Dec 2023 12:43:28 +0100
Subject: [PATCH v5 03/13] pinctrl: ingenic: Use C99 initializers in
 PINCTRL_PIN_GROUP()
In-Reply-To: <ZYAhyWxh5sEyK1RC@smile.fi.intel.com>
References: <20231211190321.307330-1-andriy.shevchenko@linux.intel.com>
	 <20231211190321.307330-4-andriy.shevchenko@linux.intel.com>
	 <fb29c3bca8d245e3f7496539b7293aa4fc4bccd0.camel@crapouillou.net>
	 <ZXmv81bJRMqB1GLY@smile.fi.intel.com>
	 <9cbaf60cd6cf1a581e7587088f71ca7cf6b6ff37.camel@crapouillou.net>
	 <ZYAhyWxh5sEyK1RC@smile.fi.intel.com>
Message-ID: <5b127bcdd11ebb6857c9ecd70b946a5add7a93e9.camel@crapouillou.net>

Hi Andy,

Le lundi 18 d?cembre 2023 ? 12:41 +0200, Andy Shevchenko a ?crit?:
> On Sun, Dec 17, 2023 at 03:43:24PM +0100, Paul Cercueil wrote:
> > Le mercredi 13 d?cembre 2023 ? 15:21 +0200, Andy Shevchenko a
> > ?crit?:
> > > On Wed, Dec 13, 2023 at 10:55:46AM +0100, Paul Cercueil wrote:
> > > > Le lundi 11 d?cembre 2023 ? 20:57 +0200, Andy Shevchenko a
> > > > ?crit?:
> 
> ...
> 
> > > > > -#define INGENIC_PIN_GROUP(name, id, func)		\
> > > > > -	INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
> > > > > +#define INGENIC_PIN_GROUP(_name_, id,
> > > > > func)						\
> > > > > +	{						
> > > > > 	
> > > > > 			\
> > > > > +		.name =
> > > > > _name_,							
> > > > > 	\
> > > > > +		.pins =
> > > > > id##_pins,						
> > > > > 	\
> > > > > +		.num_pins =
> > > > > ARRAY_SIZE(id##_pins),					\
> > > > > +		.data = (void
> > > > > *)func,							\
> > > > > +	}
> > > > 
> > > > This INGENIC_PIN_GROUP() macro doesn't need to be modified,
> > > > does
> > > > it?
> > > 
> > > We can go either way. I prefer to go this way as it reduces level
> > > of
> > > indirections in the macros. It makes code easier to read and
> > > understand.
> > > But if you insist, I can drop that change in next version.
> > 
> > I like the patches to be minimal. But I understand your point of
> > view
> > as well.
> > 
> > If you have to issue a v6, maybe state the reason why you also
> > modify
> > INGENIC_PIN_GROUP() then. But I don't care enough to request a v6
> > just
> > for that.
> > 
> > So:
> > Acked-by: Paul Cercueil <paul at crapouillou.net>
> 
> Thank you!
> 
> But as I already noted, the series had been applied (by Linus W.)
> and this does not seem to be a critical to fix, do you agree?
> 

Well I only suggested to change the commit message - so no, it is not
critical to fix.

Cheers,
-Paul


From cristian.ciocaltea at collabora.com  Mon Dec 18 03:43:52 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 13:43:52 +0200
Subject: [PATCH v3 6/9] riscv: dts: starfive: visionfive-v1: Setup
 ethernet phy
In-Reply-To: <f8f9d454-6155-4b1c-b4b2-daf98267be14@lunn.ch>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-7-cristian.ciocaltea@collabora.com>
 <f8f9d454-6155-4b1c-b4b2-daf98267be14@lunn.ch>
Message-ID: <b65393f1-1c36-40e5-96f6-1e7f978cc185@collabora.com>

On 12/17/23 19:55, Andrew Lunn wrote:
> On Fri, Dec 15, 2023 at 10:40:45PM +0200, Cristian Ciocaltea wrote:
>> The StarFive VisionFive V1 SBC uses a Motorcomm YT8521 PHY supporting
>> RGMII-ID, but requires manual adjustment of the RX internal delay to
>> work properly.
>>
>> The default RX delay provided by the driver is 1.95 ns, which proves to
>> be too high. Applying a 50% reduction seems to mitigate the issue.
>>
>> Also note this adjustment is not necessary on BeagleV Starlight SBC,
>> which uses a Microchip PHY.  Hence, there is no indication of a
>> miss-behaviour on the GMAC side, but most likely the issue stems from
>> the Motorcomm PHY.
> 
> I suggest you make a similar comment in the .dts file, just to explain
> the odd setting.

Sure, will do, we need a v4 anyway.

Thanks,
Cristian


From glider at google.com  Mon Dec 18 03:45:34 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 12:45:34 +0100
Subject: [PATCH v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <ZXyAXPxlmq11rp2Y@yury-ThinkPad>
References: <20231214110639.2294687-1-glider@google.com> <20231214110639.2294687-5-glider@google.com>
 <ZXtircr4TllpqyeS@yury-ThinkPad> <CAG_fn=WcrNqV4burBRPZZwoBLwgia7kerZ8g2vV5spzWF=houQ@mail.gmail.com>
 <ZXyAXPxlmq11rp2Y@yury-ThinkPad>
Message-ID: <CAG_fn=U5f-T95u+r5ok8ptA2sLdzqKPNxGia+NRo1hnGs15DoA@mail.gmail.com>

> > > Nit: really no need to split the line - we're OK with 100-chars per
> > > line now.
> >
> > That's true, but I am relying on clang-format here (maybe we should
> > extend the limit in .clang-format?)
>
> If clang-format hurts readability, don't use it.
>
There's an old discussion on clang-format column limit being
inconsistent with what checkpatch mandates:
https://lore.kernel.org/lkml/20200610125147.2782142-1-christian.brauner at ubuntu.com/
I changed the name of the variable in this case to avoid hitting the
column limit.


From cristian.ciocaltea at collabora.com  Mon Dec 18 03:48:21 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 13:48:21 +0200
Subject: [PATCH v3 5/9] riscv: dts: starfive: jh7100-common: Setup pinmux
 and enable gmac
In-Reply-To: <20231217-rippling-galleria-904152e41f95@spud>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-6-cristian.ciocaltea@collabora.com>
 <CAJM55Z-bg0EGPaLHtxcu2AzqN59zfuiT0eE7oCShrx7dG_QK1g@mail.gmail.com>
 <20231217-rippling-galleria-904152e41f95@spud>
Message-ID: <11f7fbee-4795-4d5f-a5f8-901bc17683eb@collabora.com>

On 12/17/23 23:03, Conor Dooley wrote:
> On Sat, Dec 16, 2023 at 11:38:53AM -0800, Emil Renner Berthing wrote:
>> Cristian Ciocaltea wrote:
>>> Add pinmux configuration for DWMAC found on the JH7100 based boards and
>>> enable the related DT node, providing a basic PHY configuration.
>>>
>>> Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
>>> Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>>> ---
>>>  .../boot/dts/starfive/jh7100-common.dtsi      | 85 +++++++++++++++++++
>>>  1 file changed, 85 insertions(+)
>>>
>>> diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
>>> index 42fb61c36068..5cafe8f5c2e7 100644
>>> --- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
>>> +++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
>>> @@ -72,7 +72,92 @@ wifi_pwrseq: wifi-pwrseq {
>>>  	};
>>>  };
>>>
>>> +&gmac {
>>> +	pinctrl-names = "default";
>>> +	pinctrl-0 = <&gmac_pins>;
>>> +	phy-mode = "rgmii-id";
>>> +	phy-handle = <&phy>;
>>
>> I'm not sure if it's a generic policy or not, but I don't really like adding a
>> reference to a non-existant node here. I'd move this property to the board
>> files where the phy node is actually defined.
> 
> FWIW, I don't like the reference-in-the-wrong-place thing either.

Yeah, as I already mentioned this was unintentional, will fix in v4.

Thanks,
Cristian


From suzuki.poulose at arm.com  Mon Dec 18 03:56:17 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 18 Dec 2023 11:56:17 +0000
Subject: [PATCH v3 7/8] dt-bindings: arm: Add support for TPDM CMB MSR
 register
In-Reply-To: <caa424d3-7af0-43e6-8e13-e87cde0c4f67@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-8-git-send-email-quic_taozha@quicinc.com>
 <e5fbbfab-02bf-4eda-8353-87c54c307af1@linaro.org>
 <1d57590d-2ecf-4bf6-9c8f-2a9d1ba08aaa@arm.com>
 <caa424d3-7af0-43e6-8e13-e87cde0c4f67@quicinc.com>
Message-ID: <ca624e71-c487-4004-abc4-126442b92f33@arm.com>

Hi Tingwei Zhang

On 18/12/2023 11:23, Tingwei Zhang wrote:
> On 12/18/2023 6:47 PM, Suzuki K Poulose wrote:
>> Tao Zhang,
>>
>> On 21/11/2023 07:24, Krzysztof Kozlowski wrote:
>>> On 21/11/2023 03:24, Tao Zhang wrote:
>>>> Add property "qcom,cmb_msr_num" to support CMB MSR(mux select register)
>>>> for TPDM. It specifies the number of CMB MSR registers supported by
>>>> the TDPM.
>>>>
>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>>>> ---
>>>
>>> I prefer not to take any new Qualcomm Coresight bindings or Qualcomm SoC
>>> DTS nodes with Coresight till we fix all existing warnings. I don't know
>>> how to fix them, so I need help with them. No such fixing happened so
>>> far from Qcom, so pushback is my only way to get any attention.
>>>
>>> I already commented on this in other email thread.
>>
>> Are you addressing this ?
> The DT warning is fixed in 
> https://lore.kernel.org/linux-arm-msm/20231210072633.4243-1-quic_jinlmao at quicinc.com/.
> It's applied to linux-arm-msm yesterday.

How are you supporting remote-etm ? We haven't merged the support for it 
in drivers ? We haven't even reviewed the remote-etm support patches ? 
Why weren't the coresight maintainers Cc ed on the "new" binding support ?

Suzuki



>>
>> Suzuki
>>
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
> 



From jun.li at nxp.com  Mon Dec 18 03:56:29 2023
From: jun.li at nxp.com (Jun Li)
Date: Mon, 18 Dec 2023 11:56:29 +0000
Subject: =?utf-8?B?5Zue5aSNOiBbRVhUXSBSZTogW1BBVENIIDIvNF0gYXJtNjQ6IGR0czogaW14?=
 =?utf-8?Q?8ulp-evk:_enable_usb_nodes?=
In-Reply-To: <CAOMZO5DxQGjF5rUs6NMR7LCo11tLVPpnPs9nzH7qh2nCCBXoLQ@mail.gmail.com>
References: <20231214112442.2412079-1-xu.yang_2@nxp.com>
 <20231214112442.2412079-2-xu.yang_2@nxp.com>
 <CAOMZO5DxcLoBYMXQi=EW=-fAqz12ghPm+7PHn=LdhicETKg2pQ@mail.gmail.com>
 <VI1PR04MB51523F1EF74EF23B92C6880D8C8CA@VI1PR04MB5152.eurprd04.prod.outlook.com>
 <CAOMZO5DxQGjF5rUs6NMR7LCo11tLVPpnPs9nzH7qh2nCCBXoLQ@mail.gmail.com>
Message-ID: <PA4PR04MB96402073596E882CFBC925398990A@PA4PR04MB9640.eurprd04.prod.outlook.com>

Hi Fabio,

> -----????-----
> ???: Fabio Estevam <festevam at gmail.com>
> ????: 2023?12?14? 21:15
> ???: Xu Yang <xu.yang_2 at nxp.com>
> ??: robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de;
> kernel at pengutronix.de; dl-linux-imx <linux-imx at nxp.com>;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> ??: Re: [EXT] Re: [PATCH 2/4] arm64: dts: imx8ulp-evk: enable usb nodes
> 
> On Thu, Dec 14, 2023 at 9:50?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
> 
> > PTN5150 can work autonomously for most of the basic functions.
> > I don?t see a need to enable driver for it now.
> 
> We are talking about devicetree here, not driver.
> 
> If the PTN5150 is present on the board, then just represent it in the
> devicetree.

If we do not need its driver(either SW control or pass any information) for
PTN5150, what's the point to present it in device tree? Another reason
is current PTN5150 driver is through extcon, not type-c, so enable it can
not get benefit of type-C subsystem.

Thanks
Li Jun

From cristian.ciocaltea at collabora.com  Mon Dec 18 04:02:06 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 14:02:06 +0200
Subject: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <20231217-spray-livestock-a59d630b751e@spud>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>
 <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>
 <65fd52f1-6861-42b0-9148-266766d054b1@sifive.com>
 <6c62e3b2-acde-4580-9b67-56683289e45e@collabora.com>
 <20231217-spray-livestock-a59d630b751e@spud>
Message-ID: <fa4b9c1d-6033-4b35-b03c-e03419edb5dc@collabora.com>

On 12/17/23 23:09, Conor Dooley wrote:
> On Fri, Dec 15, 2023 at 11:03:24PM +0200, Cristian Ciocaltea wrote:
>> On 12/15/23 22:59, Samuel Holland wrote:
>>> On 2023-12-15 2:47 PM, Jessica Clarke wrote:
>>>> On 15 Dec 2023, at 20:40, Cristian Ciocaltea <cristian.ciocaltea at collabora.com> wrote:
>>>>>
>>>>> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
>>>>> similar to the newer JH7110, but it requires only two interrupts and a
>>>>> single reset line, which is 'ahb' instead of the commonly used
>>>>> 'stmmaceth'.
>>>>>
>>>>> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
>>>>> conjunction with 'stmmaceth', extend the logic to also permit exclusive
>>>>> usage of the 'ahb' reset name.  This ensures the following use cases are
>>>>> supported:
>>>>>
>>>>>  JH7110: reset-names = "stmmaceth", "ahb";
>>>>>  JH7100: reset-names = "ahb";
>>>>>  other:  reset-names = "stmmaceth";
>>>>>
>>>>> Also note the need to use a different dwmac fallback, as v5.20 applies
>>>>> to JH7110 only, while JH7100 relies on v3.7x.
>>>>>
>>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>>>>> ---
>>>>> .../devicetree/bindings/net/snps,dwmac.yaml   |  3 +-
>>>>> .../bindings/net/starfive,jh7110-dwmac.yaml   | 74 +++++++++++++------
>>>>> 2 files changed, 55 insertions(+), 22 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>>>> index 5c2769dc689a..c1380ff1c054 100644
>>>>> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>>>> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>>>> @@ -95,6 +95,7 @@ properties:
>>>>>         - snps,dwmac-5.20
>>>>>         - snps,dwxgmac
>>>>>         - snps,dwxgmac-2.10
>>>>> +        - starfive,jh7100-dwmac
>>>>>         - starfive,jh7110-dwmac
>>>>>
>>>>>   reg:
>>>>> @@ -146,7 +147,7 @@ properties:
>>>>>   reset-names:
>>>>>     minItems: 1
>>>>>     items:
>>>>> -      - const: stmmaceth
>>>>> +      - enum: [stmmaceth, ahb]
>>>>>       - const: ahb
>>>>
>>>> I?m not so well-versed in the YAML bindings, but would this not allow
>>>> reset-names = "ahb", "ahb"?
>>>
>>> Yes, it would. You need something like:
>>>
>>> reset-names:
>>>   oneOf:
>>>     - enum: [stmmaceth, ahb]
>>>     - items:
>>>         - const: stmmaceth
>>>         - const: ahb
>>
>> Oh yes, I always forget about the "oneOf" thing. Thanks!
> 
> Won't this also relax the naming for all devices that allow a single
> reset, but expect the stmmaceth one? I'm not sure that that actually
> matters, I think the consumer bindings have constraints themselves.

Before commit 843f603762a5 ("dt-bindings: net: snps,dwmac: Add 'ahb'
reset/reset-name"), the 'stmmaceth' was the only possible option, hence
there was no need for any constraints on the consumer bindings.  But
afterwards it was allowed to use both resets, hence I think the bindings
should have been updated at that time by adding 'maxItems: 1' to prevent
using the 2nd reset.

I could fix this in a separate series, if it's not something mandatory
to be handled here.

Thanks for reviewing,
Cristian


From alexander.stein at ew.tq-group.com  Mon Dec 18 04:03:12 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:03:12 +0100
Subject: [PATCH 5/6] drm/bridge: dpu-dprc: Use dev_err_probe
In-Reply-To: <20231218105718.2445136-6-alexander.stein@ew.tq-group.com>
References: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com> <20231218105718.2445136-6-alexander.stein@ew.tq-group.com>
Message-ID: <6003334.lOV4Wx5bFT@steina-w>

Am Montag, 18. Dezember 2023, 11:57:17 CET schrieb Alexander Stein:
> This simplifies the code and gives additional information upon deferral.

Please ignore. I just noticed this file is added in a locally applied series.

Thanks
Alexander

> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> ---
>  drivers/gpu/drm/imx/dpu/dpu-dprc.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/dpu/dpu-dprc.c
> b/drivers/gpu/drm/imx/dpu/dpu-dprc.c index 261c9566721e..6467ad960080
> 100644
> --- a/drivers/gpu/drm/imx/dpu/dpu-dprc.c
> +++ b/drivers/gpu/drm/imx/dpu/dpu-dprc.c
> @@ -612,7 +612,8 @@ static int dpu_dprc_probe(struct platform_device *pdev)
> 
>  		dprc->prgs[i] = dpu_prg_lookup_by_phandle(dev, "fsl,prgs", 
i);
>  		if (!dprc->prgs[i])
> -			return -EPROBE_DEFER;
> +			return dev_err_probe(dev, -EPROBE_DEFER,
> +					     "Failed to lookup 
fsl,prgs\n");
> 
>  		if (i == 1)
>  			dpu_prg_set_auxiliary(dprc->prgs[i]);
> @@ -623,11 +624,10 @@ static int dpu_dprc_probe(struct platform_device
> *pdev)
> 
>  	ret = devm_request_irq(dev, wrap_irq, dpu_dprc_wrap_irq_handler,
>  			       IRQF_SHARED, dev_name(dev), dprc);
> -	if (ret < 0) {
> -		dev_err(dev, "failed to request dpr_wrap irq(%u): %d\n",
> -			wrap_irq, ret);
> -		return ret;
> -	}
> +	if (ret < 0)
> +		return dev_err_probe(dev, ret,
> +				     "failed to request dpr_wrap 
irq(%u)\n",
> +				     wrap_irq);
> 
>  	platform_set_drvdata(pdev, dprc);


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From alexander.stein at ew.tq-group.com  Mon Dec 18 04:03:20 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:03:20 +0100
Subject: [PATCH 6/6] drm/bridge: dpu-core: Don't print error on -EPROBE_DEFER
In-Reply-To: <20231218105718.2445136-7-alexander.stein@ew.tq-group.com>
References: <20231218105718.2445136-1-alexander.stein@ew.tq-group.com> <20231218105718.2445136-7-alexander.stein@ew.tq-group.com>
Message-ID: <4536196.LvFx2qVVIh@steina-w>

Am Montag, 18. Dezember 2023, 11:57:18 CET schrieb Alexander Stein:
> -517 errors are just annoying. dev_err_probe can't be used here either
> as this would hide the error message already set in us->init.

Please ignore. I just noticed this file is added in a locally applied series.

Thanks
Alexander

> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> ---
>  drivers/gpu/drm/imx/dpu/dpu-core.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/dpu/dpu-core.c
> b/drivers/gpu/drm/imx/dpu/dpu-core.c index d6116b3e4ed7..ea2558a14a6c
> 100644
> --- a/drivers/gpu/drm/imx/dpu/dpu-core.c
> +++ b/drivers/gpu/drm/imx/dpu/dpu-core.c
> @@ -592,9 +592,10 @@ static int dpu_submodules_init(struct dpu_soc *dpu,
> unsigned long dpu_base) ret = us->init(dpu, j, us->ids[j], us->types[j],
>  				       pec_ofs, dpu_base + us-
>ofss[j]);
>  			if (ret) {
> -				dev_err(dpu->dev,
> -					"failed to initialize %s%d: 
%d\n",
> -						us->name, us-
>ids[j], ret);
> +				if (ret != -EPROBE_DEFER)
> +					dev_err(dpu->dev,
> +						"failed to 
initialize %s%d: %d\n",
> +							us-
>name, us->ids[j], ret);
>  				return ret;
>  			}
>  		}


-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From linux at armlinux.org.uk  Mon Dec 18 04:14:14 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Mon, 18 Dec 2023 12:14:14 +0000
Subject: [PATCH RFC v3 21/21] cpumask: Add enabled cpumask for present
 CPUs that can be brought online
In-Reply-To: <20231215171831.00004a19@Huawei.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOhX-00Dvlg-Ci@rmk-PC.armlinux.org.uk>
 <20231215171831.00004a19@Huawei.com>
Message-ID: <ZYA3lmPOwIOJq/iY@shell.armlinux.org.uk>

On Fri, Dec 15, 2023 at 05:18:31PM +0000, Jonathan Cameron wrote:
> On Wed, 13 Dec 2023 12:50:59 +0000
> Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> 
> > From: James Morse <james.morse at arm.com>
> > 
> > The 'offline' file in sysfs shows all offline CPUs, including those
> > that aren't present. User-space is expected to remove not-present CPUs
> > from this list to learn which CPUs could be brought online.
> > 
> > CPUs can be present but not-enabled. These CPUs can't be brought online
> > until the firmware policy changes, which comes with an ACPI notification
> > that will register the CPUs.
> > 
> > With only the offline and present files, user-space is unable to
> > determine which CPUs it can try to bring online. Add a new CPU mask
> > that shows this based on all the registered CPUs.
> > 
> > Signed-off-by: James Morse <james.morse at arm.com>
> > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > ---
> 
> Needs docs
> Documentation/ABI/testing/sysfs-devices-system-cpu
> seems to have the rest of the similar entries.

Any ideas what I put in there as "Date" ? It seems to me that we have
little idea when this might be merged.. I could use the date of the
commit (Nov 2022).

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From quic_jinlmao at quicinc.com  Mon Dec 18 04:17:46 2023
From: quic_jinlmao at quicinc.com (Jinlong Mao)
Date: Mon, 18 Dec 2023 20:17:46 +0800
Subject: [PATCH v3 7/8] dt-bindings: arm: Add support for TPDM CMB MSR
 register
In-Reply-To: <ca624e71-c487-4004-abc4-126442b92f33@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-8-git-send-email-quic_taozha@quicinc.com>
 <e5fbbfab-02bf-4eda-8353-87c54c307af1@linaro.org>
 <1d57590d-2ecf-4bf6-9c8f-2a9d1ba08aaa@arm.com>
 <caa424d3-7af0-43e6-8e13-e87cde0c4f67@quicinc.com>
 <ca624e71-c487-4004-abc4-126442b92f33@arm.com>
Message-ID: <8051b5ab-4f7f-4a8c-9c4f-fe1f46bb1951@quicinc.com>



On 12/18/2023 7:56 PM, Suzuki K Poulose wrote:
> Hi Tingwei Zhang
> 
> On 18/12/2023 11:23, Tingwei Zhang wrote:
>> On 12/18/2023 6:47 PM, Suzuki K Poulose wrote:
>>> Tao Zhang,
>>>
>>> On 21/11/2023 07:24, Krzysztof Kozlowski wrote:
>>>> On 21/11/2023 03:24, Tao Zhang wrote:
>>>>> Add property "qcom,cmb_msr_num" to support CMB MSR(mux select 
>>>>> register)
>>>>> for TPDM. It specifies the number of CMB MSR registers supported by
>>>>> the TDPM.
>>>>>
>>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>>>>> ---
>>>>
>>>> I prefer not to take any new Qualcomm Coresight bindings or Qualcomm 
>>>> SoC
>>>> DTS nodes with Coresight till we fix all existing warnings. I don't 
>>>> know
>>>> how to fix them, so I need help with them. No such fixing happened so
>>>> far from Qcom, so pushback is my only way to get any attention.
>>>>
>>>> I already commented on this in other email thread.
>>>
>>> Are you addressing this ?
>> The DT warning is fixed in 
>> https://lore.kernel.org/linux-arm-msm/20231210072633.4243-1-quic_jinlmao at quicinc.com/.
>> It's applied to linux-arm-msm yesterday.
> 
> How are you supporting remote-etm ? We haven't merged the support for it 
> in drivers ? We haven't even reviewed the remote-etm support patches ? 
> Why weren't the coresight maintainers Cc ed on the "new" binding support ?
> 
> Suzuki
> 
> 
Hi Suzuki,

Sorry for missing coresight maintainers in the remote-etm binding patch.
 From the comments, we can add binding for the connected hardware first.

https://lkml.org/lkml/2023/11/30/539

Thanks
Jinlong Mao

> 
>>>
>>> Suzuki
>>>
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>
> 


From alexander.stein at ew.tq-group.com  Mon Dec 18 04:24:07 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:24:07 +0100
Subject: [PATCH 1/1] clk: imx: clk-imx8qxp: fix LVDS bypass, pixel and phy clocks
Message-ID: <20231218122407.2757175-1-alexander.stein@ew.tq-group.com>

To be compatibel with SCU firmware based on 1.15 a different clock
routing for LVDS is needed.

Signed-off-by: Oliver F. Brown <oliver.brown at oss.nxp.com>
Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan at nxp.com>
Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
This patch originates from the downstream kernel squashing patches [1] and [2]
as suggested by the commit message.
I adjusted the commit so that the name stays the same as before.

I am somewhat unsure about the From: tag, as both commits have different
authors.

Best regards,
Alexander

[1] https://github.com/Freescale/linux-fslc/commit/05b5fd0eebd0
[2] https://github.com/Freescale/linux-fslc/commit/0a202c564e5f
 drivers/clk/imx/clk-imx8qxp.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
index 41f0a45aa162..7d8883916cac 100644
--- a/drivers/clk/imx/clk-imx8qxp.c
+++ b/drivers/clk/imx/clk-imx8qxp.c
@@ -66,6 +66,22 @@ static const char * const lcd_pxl_sels[] = {
 	"lcd_pxl_bypass_div_clk",
 };
 
+static const char *const lvds0_sels[] = {
+	"clk_dummy",
+	"clk_dummy",
+	"clk_dummy",
+	"clk_dummy",
+	"mipi0_lvds_bypass_clk",
+};
+
+static const char *const lvds1_sels[] = {
+	"clk_dummy",
+	"clk_dummy",
+	"clk_dummy",
+	"clk_dummy",
+	"mipi1_lvds_bypass_clk",
+};
+
 static const char * const mipi_sels[] = {
 	"clk_dummy",
 	"clk_dummy",
@@ -207,9 +223,9 @@ static int imx8qxp_clk_probe(struct platform_device *pdev)
 	/* MIPI-LVDS SS */
 	imx_clk_scu("mipi0_bypass_clk", IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_BYPASS);
 	imx_clk_scu("mipi0_pixel_clk", IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_PER);
-	imx_clk_scu("mipi0_lvds_pixel_clk", IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC2);
 	imx_clk_scu("mipi0_lvds_bypass_clk", IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_BYPASS);
-	imx_clk_scu("mipi0_lvds_phy_clk", IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC3);
+	imx_clk_scu2("mipi0_lvds_pixel_clk", lvds0_sels, ARRAY_SIZE(lvds0_sels), IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC2);
+	imx_clk_scu2("mipi0_lvds_phy_clk", lvds0_sels, ARRAY_SIZE(lvds0_sels), IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC3);
 	imx_clk_scu2("mipi0_dsi_tx_esc_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_MST_BUS);
 	imx_clk_scu2("mipi0_dsi_rx_esc_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_SLV_BUS);
 	imx_clk_scu2("mipi0_dsi_phy_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_PHY);
@@ -219,9 +235,9 @@ static int imx8qxp_clk_probe(struct platform_device *pdev)
 
 	imx_clk_scu("mipi1_bypass_clk", IMX_SC_R_MIPI_1, IMX_SC_PM_CLK_BYPASS);
 	imx_clk_scu("mipi1_pixel_clk", IMX_SC_R_MIPI_1, IMX_SC_PM_CLK_PER);
-	imx_clk_scu("mipi1_lvds_pixel_clk", IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC2);
 	imx_clk_scu("mipi1_lvds_bypass_clk", IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_BYPASS);
-	imx_clk_scu("mipi1_lvds_phy_clk", IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC3);
+	imx_clk_scu2("mipi1_lvds_pixel_clk", lvds1_sels, ARRAY_SIZE(lvds1_sels), IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC2);
+	imx_clk_scu2("mipi1_lvds_phy_clk", lvds1_sels, ARRAY_SIZE(lvds1_sels), IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC3);
 
 	imx_clk_scu2("mipi1_dsi_tx_esc_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_1, IMX_SC_PM_CLK_MST_BUS);
 	imx_clk_scu2("mipi1_dsi_rx_esc_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_1, IMX_SC_PM_CLK_SLV_BUS);
-- 
2.34.1



From maz at kernel.org  Mon Dec 18 04:25:49 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 18 Dec 2023 12:25:49 +0000
Subject: [PATCH v3 14/17] KVM: arm64: Macros for setting/clearing FGT bits
In-Reply-To: <CA+EHjTyPS-3PX+JGV32oTTMYJPk3Dijbcj3oAENg3v7sAdw7wA@mail.gmail.com>
References: <20231214100158.2305400-1-tabba@google.com>
	<20231214100158.2305400-15-tabba@google.com>
	<86wmtbalx9.wl-maz@kernel.org>
	<CA+EHjTxZmc2bAaDbFLjWxx-LzCX7Jwy+EH60JgFBvWYh68U=xg@mail.gmail.com>
	<86v88vahn8.wl-maz@kernel.org>
	<CA+EHjTyPS-3PX+JGV32oTTMYJPk3Dijbcj3oAENg3v7sAdw7wA@mail.gmail.com>
Message-ID: <86ttofae9e.wl-maz@kernel.org>

On Mon, 18 Dec 2023 11:17:55 +0000,
Fuad Tabba <tabba at google.com> wrote:
> 
> Hi Marc,
> 
> On Mon, Dec 18, 2023 at 11:12?AM Marc Zyngier <maz at kernel.org> wrote:
> ...
> >         if (cpu_has_amu())
> >                 update_fgt_traps(vcpu, HAFGRTR_EL2);
> >
> > If that seems sensible to you, I'll fold it in, as I'd like to do
> > without a respin if we can avoid it.
> 
> Looks good to me. Thanks Marc!

Please have a look at [1] to see what I have done (AMU fixes and my
suggestion for the FGT macros), and let me know if that's OK with you.

I've given it a go on my M2 with NV (only a couple of minor conflicts)
and nothing caught fire.

Thanks,

	M.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/fgt-rework

-- 
Without deviation from the norm, progress is not possible.


From tabba at google.com  Mon Dec 18 04:30:14 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 18 Dec 2023 12:30:14 +0000
Subject: [PATCH v3 14/17] KVM: arm64: Macros for setting/clearing FGT bits
In-Reply-To: <86ttofae9e.wl-maz@kernel.org>
References: <20231214100158.2305400-1-tabba@google.com> <20231214100158.2305400-15-tabba@google.com>
 <86wmtbalx9.wl-maz@kernel.org> <CA+EHjTxZmc2bAaDbFLjWxx-LzCX7Jwy+EH60JgFBvWYh68U=xg@mail.gmail.com>
 <86v88vahn8.wl-maz@kernel.org> <CA+EHjTyPS-3PX+JGV32oTTMYJPk3Dijbcj3oAENg3v7sAdw7wA@mail.gmail.com>
 <86ttofae9e.wl-maz@kernel.org>
Message-ID: <CA+EHjTx5JYc2Ez1uorOJwE1YRX1AkNeqxEK5SHSCf5Bdj3Vp7A@mail.gmail.com>

Hi Marc,

On Mon, Dec 18, 2023 at 12:25?PM Marc Zyngier <maz at kernel.org> wrote:
>
> On Mon, 18 Dec 2023 11:17:55 +0000,
> Fuad Tabba <tabba at google.com> wrote:
> >
> > Hi Marc,
> >
> > On Mon, Dec 18, 2023 at 11:12?AM Marc Zyngier <maz at kernel.org> wrote:
> > ...
> > >         if (cpu_has_amu())
> > >                 update_fgt_traps(vcpu, HAFGRTR_EL2);
> > >
> > > If that seems sensible to you, I'll fold it in, as I'd like to do
> > > without a respin if we can avoid it.
> >
> > Looks good to me. Thanks Marc!
>
> Please have a look at [1] to see what I have done (AMU fixes and my
> suggestion for the FGT macros), and let me know if that's OK with you.
>
> I've given it a go on my M2 with NV (only a couple of minor conflicts)
> and nothing caught fire.

Both the AMU fixes and the FGT macros look good to me. Thanks for this!

Cheers,
/fuad

>
> Thanks,
>
>         M.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/fgt-rework
>
> --
> Without deviation from the norm, progress is not possible.


From knaerzche at gmail.com  Mon Dec 18 04:32:56 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon, 18 Dec 2023 13:32:56 +0100
Subject: [PATCH v2 18/27] drm/rockchip: inno_hdmi: Subclass connector
 state
In-Reply-To: <rvovzl6rqkaa2hvml75if5bjasqnyh2r354jdjpa5gckfpcxv4@wlknpt7lhncq>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-19-knaerzche@gmail.com>
 <rvovzl6rqkaa2hvml75if5bjasqnyh2r354jdjpa5gckfpcxv4@wlknpt7lhncq>
Message-ID: <2de65f47-6512-400d-82c9-ae2ba9fdaa12@gmail.com>

Hi,

Am 18.12.23 um 10:02 schrieb Maxime Ripard:
> Hi,
>
> Thanks for working on that, it's much better now.
>
> On Sat, Dec 16, 2023 at 05:26:29PM +0100, Alex Bee wrote:
>> +static struct drm_connector_state *
>> +inno_hdmi_connector_duplicate_state(struct drm_connector *connector)
>> +{
>> +	struct inno_hdmi_connector_state *inno_conn_state;
>> +
>> +	if (WARN_ON(!connector->state))
>> +		return NULL;
>> +
>> +	inno_conn_state = kmemdup(to_inno_hdmi_conn_state(connector->state),
>> +				  sizeof(*inno_conn_state), GFP_KERNEL);
>> +
>> +	if (!inno_conn_state)
>> +		return NULL;
>> +
>> +	__drm_atomic_helper_connector_duplicate_state(connector,
>> +						      &inno_conn_state->base);
>> +
>> +	return &inno_conn_state->base;
>> +}
>> +
>>   static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
>>   	.fill_modes = inno_hdmi_probe_single_connector_modes,
>>   	.detect = inno_hdmi_connector_detect,
>>   	.destroy = inno_hdmi_connector_destroy,
>>   	.reset = drm_atomic_helper_connector_reset,
>> -	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>> +	.atomic_duplicate_state = inno_hdmi_connector_duplicate_state,
>>   	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>   };
> You also need a custom reset and atomic_destroy_state implementations
Yea sure - thanks for the heads up.
I had this in multiple commits locally and thought I squashed them into
this one. Well, I obviously didn't :)

Alex
> Maxime


From mshavit at google.com  Mon Dec 18 04:35:30 2023
From: mshavit at google.com (Michael Shavit)
Date: Mon, 18 Dec 2023 20:35:30 +0800
Subject: [PATCH 04/19] iommu/arm-smmu-v3: Make STE programming independent
 of the callers
In-Reply-To: <ZX7xu8jN/rBZ4A/d@nvidia.com>
References: <0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com> <CAKHBV24UGZuG6+J4cybadJCTyf9hN+e_VgAC0NVOPotmEur7SQ@mail.gmail.com>
 <20231012121616.GF3952@nvidia.com> <CAKHBV27G1PLZ5gkYkOOCZdD9waZOZypkWqk4_HSR4XXGFT-+LA@mail.gmail.com>
 <20231018130455.GU3952@nvidia.com> <CAKHBV270uJjdj4zeK-NNt+j3TiqoGDdLUQ5uRrLw9PN0ysCDbw@mail.gmail.com>
 <20231020113918.GD3952@nvidia.com> <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
 <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com> <ZX7xu8jN/rBZ4A/d@nvidia.com>
Message-ID: <CAKHBV26CRC8eWMuOk6EZYMHOZoR2FauP=NBazzOiWCmQYEa1vg@mail.gmail.com>

On Sun, Dec 17, 2023 at 9:03?PM Jason Gunthorpe <jgg at nvidia.com> wrote:
>
> On Sat, Dec 16, 2023 at 04:26:48AM +0800, Michael Shavit wrote:
>
> > Ok, I took a proper stab at trying to unroll the loop on the github
> > version of this patch (v3+)
> > As you suspected, it's not easy to re-use the unrolled version for
> > both STE and CD writing as we'd have to pass in callbacks for syncing
> > the STE/CD and recomputing arm_smmu_{get_ste/cd}_used.
>
> Yes, that is why I structured it as an iterator

On second thought, perhaps defining a helper class implementing
entry_sync() and entry_get_used_bits() might not be so bad?
It's a little bit more verbose, but avoids deduplication of the
complicated parts.

> > I personally find this quite a bit more readable as a sequential
> > series of steps instead of a loop. It also only requires 3 STE/CD
> > syncs in the worst case compared to 4 in the loop version since we
>
> The existing version is max 3 as well, it works the same by
> checking the number of critical qwords after computing the first step
> in the hitless flow.

Gotcha. I was being lazy and assuming it was 4 based on the warning
added to the github version :).

>
> However, what you have below has the same problem as the first sketch,
> it always does 3 syncs. The existing version fully minimizes the
> syncs. It is why it is so complex to unroll it as you have to check
> before every sync if the sync is needed at all.

Hmmmm, AFAICT there are two optimizations I was missing:
1. The final clean-up loop may be a nop, in which case a sync isn't required.
2. We may be able to directly transition to the target state with a
single qword write from the very beginning, without going through any
intermediate STEs.

Both of these seem pretty easy to address in this version as well
however; or am I still overlooking a scenario?

>
> This could probably be organized like this so one shared function
> computes the "plan" and then a cd/ste copy executes the plan. It
> avoids the loop but all the code is still basically the same, there is
> just more of it.
>
> I'm fine with any of these ways
>
> Jason
>
> >  static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
> >                                struct arm_smmu_ste *ste,
> >                                const struct arm_smmu_ste *target)
> >  {
> > +       struct arm_smmu_ste staging_ste;
> >         struct arm_smmu_ste target_used;
> > +       int writes_required = 0;
> > +       u8 staging_used_diff = 0;
> > +       int i = 0;
> >
> > +       /*
> > +        * Compute a staging ste that has all the bits currently unused by HW
> > +        * set to their target values, such that comitting it to the ste table
> > +        * woudn't disrupt the hardware.
> > +        */
> > +       memcpy(&staging_ste, ste, sizeof(staging_ste));
> > +       arm_smmu_ste_set_unused_bits(&staging_ste, target);
> > +
> > +       /*
> > +        * Determine if it's possible to reach the target configuration from the
> > +        * staged configured in a single qword write (ignoring bits that are
> > +        * unused under the target configuration).
> > +        */
> >         arm_smmu_get_ste_used(target, &target_used);
> > -               WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);
> > +       /*
> > +        * But first sanity check that masks in arm_smmu_get_ste_used() are up
> > +        * to date.
> > +        */
> > +       for (i = 0; i != ARRAY_SIZE(target->data); i++) {
> > +               if (WARN_ON_ONCE(target->data[i] & ~target_used.data[i]))
> > +                       target_used.data[i] |= target->data[i];
> > +       }
> >
> > +       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++) {
> > +               /*
> > +                * Each bit of staging_used_diff indicates the index of a qword
> > +                * within the staged ste that is incorrect compared to the
> > +                * target, considering only the used bits in the target
> > +                */
> > +               if ((staging_ste.data[i] &
> > +                   target_used.data[i]) != (target->data[i]))
> > +                       staging_used_diff |= 1 << i;
> > +       }
> > +       if (hweight8(staging_used_diff) > 1) {
> > +               /*
> > +                * More than 1 qword is mismatched and a hitless transition from
> > +                * the current ste to the target ste is not possible. Clear the
> > +                * V bit and recompute the staging STE.
> > +                * Because the V bit is cleared, the staging STE will be equal
> > +                * to the target STE except for the first qword.
> > +                */
> > +               staging_ste.data[0] &= ~cpu_to_le64(STRTAB_STE_0_V);
> > +               arm_smmu_ste_set_unused_bits(&staging_ste, target);
> > +               staging_used_diff = 1;
> > +       }
> > +
> > +       /*
> > +        * Commit the staging STE.
> > +        */
> > +       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++)
> > +               WRITE_ONCE(ste->data[i], staging_ste.data[i]);
> > +       arm_smmu_sync_ste_for_sid(smmu, sid);
> > +
> > +       /*
> > +        * It's now possible to switch to the target configuration with a write
> > +        * to a single qword. Make that switch now.
> > +        */
> > +       i = ffs(staging_used_diff) - 1;
> > +       WRITE_ONCE(ste->data[i], target->data[i]);
> > +       arm_smmu_sync_ste_for_sid(smmu, sid);
>
> The non hitless flow doesn't look right to me, it should set v=0 then
> load all qwords but 0 then load 0, in exactly that sequence. If the
> goal is clarity then the two programming flows should be explicitly
> spelled out.

Ah yeah you're right. I forgot to set the other qwords in the staging
STE to have their final values in the non-hitless case.

The following should address the bug and optimization you pointed out
with minimal adjustments:

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 98aa8cc17b58b..1c35599d944d7 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -971,100 +971,6 @@ void arm_smmu_tlb_inv_asid(struct
arm_smmu_device *smmu, u16 asid)
        arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
 }

-/*
- * This algorithm updates any STE/CD to any value without creating a situation
- * where the HW can percieve a corrupted entry. HW is only required
to have a 64
- * bit atomicity with stores from the CPU, while entries are many 64 bit values
- * big.
- *
- * The algorithm works by evolving the entry toward the target in a series of
- * steps. Each step synchronizes with the HW so that the HW can not
see an entry
- * torn across two steps. Upon each call cur/cur_used reflect the current
- * synchronized value seen by the HW.
- *
- * During each step the HW can observe a torn entry that has any combination of
- * the step's old/new 64 bit words. The algorithm objective is for the HW
- * behavior to always be one of current behavior, V=0, or new behavior, during
- * each step, and across all steps.
- *
- * At each step one of three actions is chosen to evolve cur to target:
- *  - Update all unused bits with their target values.
- *    This relies on the IGNORED behavior described in the specification
- *  - Update a single 64-bit value
- *  - Update all unused bits and set V=0
- *
- * The last two actions will cause cur_used to change, which will
then allow the
- * first action on the next step.
- *
- * In the most general case we can make any update in three steps:
- *  - Disrupting the entry (V=0)
- *  - Fill now unused bits, all bits except V
- *  - Make valid (V=1), single 64 bit store
- *
- * However this disrupts the HW while it is happening. There are several
- * interesting cases where a STE/CD can be updated without disturbing the HW
- * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
- * because the used bits don't intersect. We can detect this by calculating how
- * many 64 bit values need update after adjusting the unused bits and skip the
- * V=0 process.
- */
-static bool arm_smmu_write_entry_next(__le64 *cur, const __le64 *cur_used,
-                                     const __le64 *target,
-                                     const __le64 *target_used, __le64 *step,
-                                     __le64 v_bit, unsigned int len)
-{
-       u8 step_used_diff = 0;
-       u8 step_change = 0;
-       unsigned int i;
-
-       /*
-        * Compute a step that has all the bits currently unused by HW set to
-        * their target values.
-        */
-       for (i = 0; i != len; i++) {
-               step[i] = (cur[i] & cur_used[i]) | (target[i] & ~cur_used[i]);
-               if (cur[i] != step[i])
-                       step_change |= 1 << i;
-               /*
-                * Each bit indicates if the step is incorrect compared to the
-                * target, considering only the used bits in the target
-                */
-               if ((step[i] & target_used[i]) != (target[i] & target_used[i]))
-                       step_used_diff |= 1 << i;
-       }
-
-       if (hweight8(step_used_diff) > 1) {
-               /*
-                * More than 1 qword is mismatched, this cannot be done without
-                * a break. Clear the V bit and go again.
-                */
-               step[0] &= ~v_bit;
-       } else if (!step_change && step_used_diff) {
-               /*
-                * Have exactly one critical qword, all the other qwords are set
-                * correctly, so we can set this qword now.
-                */
-               i = ffs(step_used_diff) - 1;
-               step[i] = target[i];
-       } else if (!step_change) {
-               /* cur == target, so all done */
-               if (memcmp(cur, target, len * sizeof(*cur)) == 0)
-                       return true;
-
-               /*
-                * All the used HW bits match, but unused bits are different.
-                * Set them as well. Technically this isn't necessary but it
-                * brings the entry to the full target state, so if there are
-                * bugs in the mask calculation this will obscure them.
-                */
-               memcpy(step, target, len * sizeof(*step));
-       }
-
-       for (i = 0; i != len; i++)
-               WRITE_ONCE(cur[i], step[i]);
-       return false;
-}
-
 static void arm_smmu_sync_cd(struct arm_smmu_master *master,
                             int ssid, bool leaf)
 {
@@ -1398,39 +1304,135 @@ static void arm_smmu_get_ste_used(const
struct arm_smmu_ste *ent,
        }
 }

-static bool arm_smmu_write_ste_next(struct arm_smmu_ste *cur,
-                                   const struct arm_smmu_ste *target,
-                                   const struct arm_smmu_ste *target_used)
+/*
+ * Make bits of the current ste that aren't in use by the hardware equal to the
+ * target's bits.
+ */
+static void arm_smmu_ste_set_unused_bits(
+                                  struct arm_smmu_ste *cur,
+                                  const struct arm_smmu_ste *target)
 {
        struct arm_smmu_ste cur_used;
-       struct arm_smmu_ste step;
+       int i =0;

        arm_smmu_get_ste_used(cur, &cur_used);
-       return arm_smmu_write_entry_next(cur->data, cur_used.data, target->data,
-                                        target_used->data, step.data,
-                                        cpu_to_le64(STRTAB_STE_0_V),
-                                        ARRAY_SIZE(cur->data));
+       for (i = 0; i < ARRAY_SIZE(cur->data); i++)
+               cur->data[i] = (cur->data[i] & cur_used.data[i]) |
+                              (target->data[i] & ~cur_used.data[i]);
 }

+/*
+ * Update the STE to the target configuration. The transition from the current
+ * STE to the target STE takes place over multiple steps that attempts to make
+ * the transition hitless if possible. This function takes care not to create a
+ * situation where the HW can perceive a corrupted entry. HW is only
required to
+ * have a 64 bit atomicity with stores from the CPU, while entries are many 64
+ * bit values big.
+ *
+ * The algorithm works by evolving the entry toward the target in a series of
+ * steps. Each step synchronizes with the HW so that the HW can not
see an entry
+ * torn across two steps. During each step the HW can observe a torn entry that
+ * has any combination of the step's old/new 64 bit words. The algorithm
+ * objective is for the HW behavior to always be one of current behavior, V=0,
+ * or new behavior.
+ *
+ * In the most general case we can make any update in three steps:
+ *  - Disrupting the entry (V=0)
+ *  - Fill now unused bits, all bits except V
+ *  - Make valid (V=1), single 64 bit store
+ *
+ * However this disrupts the HW while it is happening. There are several
+ * interesting cases where a STE/CD can be updated without disturbing the HW
+ * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
+ * because the used bits don't intersect. We can detect this by calculating how
+ * many 64 bit values need update after adjusting the unused bits and skip the
+ * V=0 process. This relies on the IGNORED behavior described in the
+ * specification
+ */
 static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
                               struct arm_smmu_ste *ste,
                               const struct arm_smmu_ste *target)
 {
+       struct arm_smmu_ste staging_ste;
        struct arm_smmu_ste target_used;
-       int i;
+       int writes_required = 0;
+       u8 staging_used_diff = 0;
+       int i = 0;

+       /*
+        * Compute a staging ste that has all the bits currently unused by HW
+        * set to their target values, such that comitting it to the ste table
+        * woudn't disrupt the hardware.
+        */
+       memcpy(&staging_ste, ste, sizeof(staging_ste));
+       arm_smmu_ste_set_unused_bits(&staging_ste, target);
+
+       /*
+        * Determine if it's possible to reach the target configuration from the
+        * staged configured in a single qword write (ignoring bits that are
+        * unused under the target configuration).
+        */
        arm_smmu_get_ste_used(target, &target_used);
-       /* Masks in arm_smmu_get_ste_used() are up to date */
-       for (i = 0; i != ARRAY_SIZE(target->data); i++)
-               WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);
+       /*
+        * But first sanity check that masks in arm_smmu_get_ste_used() are up
+        * to date.
+        */
+       for (i = 0; i != ARRAY_SIZE(target->data); i++) {
+               if (WARN_ON_ONCE(target->data[i] & ~target_used.data[i]))
+                       target_used.data[i] |= target->data[i];
+       }

-       for (i = 0; true; i++) {
-               if (arm_smmu_write_ste_next(ste, target, &target_used))
-                       break;
-               arm_smmu_sync_ste_for_sid(smmu, sid);
-               if (WARN_ON(i == 4))
-                       break;
+       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++) {
+               /*
+                * Each bit of staging_used_diff indicates the index of a qword
+                * within the staged ste that is incorrect compared to the
+                * target, considering only the used bits in the target
+                */
+               if ((staging_ste.data[i] &
+                   target_used.data[i]) != (target->data[i]))
+                       staging_used_diff |= 1 << i;
+       }
+       if (hweight8(staging_used_diff) > 1) {
+               /*
+                * More than 1 qword is mismatched and a hitless transition from
+                * the current ste to the target ste is not possible. Clear the
+                * V bit and recompute the staging STE.
+                * Because the V bit is cleared, the staging STE will be equal
+                * to the target STE except for the first qword.
+                */
+               staging_ste.data[0] &= ~cpu_to_le64(STRTAB_STE_0_V);
+               arm_smmu_ste_set_unused_bits(&staging_ste, target);
+               staging_used_diff = 1;
+       }
+
+       /*
+        * Commit the staging STE.
+        */
+       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++)
+               WRITE_ONCE(ste->data[i], staging_ste.data[i]);
+       arm_smmu_sync_ste_for_sid(smmu, sid);
+
+       /*
+        * It's now possible to switch to the target configuration with a write
+        * to a single qword. Make that switch now.
+        */
+       i = ffs(staging_used_diff) - 1;
+       WRITE_ONCE(ste->data[i], target->data[i]);
+       arm_smmu_sync_ste_for_sid(smmu, sid);
+
+       /*
+        * Some of the bits set under the previous configuration but unused
+        * under the target configuration might still bit set. Clear them as
+        * well. Technically this isn't necessary but it brings the entry to
+        * the full target state, so if there are bugs in the mask calculation
+        * this will obscure them.
+        */
+       for (i = 0; i != ARRAY_SIZE(ste->data); i++) {
+               if (ste->data[i] != target->data[i]) {
+                       WRITE_ONCE(ste->data[i], target->data[i]);
+               }
        }
+       arm_smmu_sync_ste_for_sid(smmu, sid);

        /* It's likely that we'll want to use the new STE soon */
        if (!(smmu->options & ARM_SMMU_OPT_SKIP_PREFETCH)) {


From knaerzche at gmail.com  Mon Dec 18 04:37:47 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon, 18 Dec 2023 13:37:47 +0100
Subject: [PATCH v2 20/27] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <rrtknir3vizvcyamp3kfy47r6uppn3wwevb6a5gln2k533t52z@otm6vum6pg43>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-21-knaerzche@gmail.com>
 <rrtknir3vizvcyamp3kfy47r6uppn3wwevb6a5gln2k533t52z@otm6vum6pg43>
Message-ID: <c58b97ca-3faa-4bf2-8d7c-7ff34e0428ca@gmail.com>


Am 18.12.23 um 10:05 schrieb Maxime Ripard:
> On Sat, Dec 16, 2023 at 05:26:31PM +0100, Alex Bee wrote:
>> @@ -431,6 +452,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>   	else
>>   		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
>>   
>> +	inno_conn_state->rgb_limited_range =
>> +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
>> +
>>   	/* Mute video and audio output */
>>   	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
>>   		  v_AUDIO_MUTE(1) | v_VIDEO_MUTE(1));
> This needs to be done at atomic_check time: the expectation is that by
> the time you commit the state, everything is prepared for it.
OK. I guess that also applies to the other members of
inno_hdmi_connector_state (former hdmi_data) and was wrong all the time.

Alex
> Maxime


From maz at kernel.org  Mon Dec 18 04:39:26 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 18 Dec 2023 12:39:26 +0000
Subject: [PATCH v11 00/43] KVM: arm64: Nested Virtualization support (FEAT_NV2 only)
In-Reply-To: <20231120131027.854038-1-maz@kernel.org>
References: <20231120131027.854038-1-maz@kernel.org>
Message-ID: <86sf3zadmp.wl-maz@kernel.org>

On Mon, 20 Nov 2023 13:09:44 +0000,
Marc Zyngier <maz at kernel.org> wrote:
> 
> This is the 5th drop of NV support on arm64 for this year, and most
> probably the last one for this side of Christmas.

Unless someone objects, I'm planning to take the first 10 patches of
this series into 6.8 (with the dependency on ID_AA64MMFR4_EL1.NV_frac
in patch #1 removed).

	M.

-- 
Without deviation from the norm, progress is not possible.


From glider at google.com  Mon Dec 18 04:40:26 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 13:40:26 +0100
Subject: [PATCH v10-mte 0/7] Implement MTE tag compression for swapped pages
Message-ID: <20231218124033.551770-1-glider@google.com>

Currently, when MTE pages are swapped out, the tags are kept in the
memory, occupying PAGE_SIZE/32 bytes per page. This is especially
problematic for devices that use zram-backed in-memory swap, because
tags stored uncompressed in the heap effectively reduce the available
amount of swap memory.

The RLE-based algorithm suggested by Evgenii Stepanov and implemented in
this patch series is able to efficiently compress fixed-size tag buffers,
resulting in practical compression ratio of 2x. In many cases it is
possible to store the compressed data in 63-bit Xarray values, resulting
in no extra memory allocations.

To implement compression/decompression, we also extend <linux/bitmap.h>
with methods to read/write bit values at arbitrary places in the map.

This patch series depends on "lib/bitmap: add bitmap_{read,write}()"
(https://lore.kernel.org/linux-arm-kernel/20231030153210.139512-1-glider at google.com/T/)
that is mailed separately.

v11-mte:
 - address Yury's comments

v10-mte:
 - add the bitmap_read()/bitmap_write() patches
   (https://lore.kernel.org/lkml/20231109151106.2385155-1-glider at google.com/)
   back to this series
 - add Acked-by: tags to MTE patches

v9:
 - split off the stats collection code into a separate patch in the
   series (as suggested by Yury Norov)

v8:
 - split off the bitmap_read()/bitmap_write() series
 - simplified the compression logic (only compress data if it fits into
   a pointer)

v7:
 - fixed comments by Yury Norov, Andy Shevchenko, Rasmus Villemoes
 - added perf tests for bitmap_read()/bitmap_write()
 - more efficient bitmap_write() implementation (meant to be sent in v5)

v6:
 - fixed comments by Yury Norov
 - fixed handling of sizes divisible by MTE_GRANULES_PER_PAGE / 2
   (caught while testing on a real device)

v5:
 - fixed comments by Andy Shevchenko, Catalin Marinas, and Yury Norov
 - added support for 16K- and 64K pages
 - more efficient bitmap_write() implementation

v4:
 - fixed a bunch of comments by Andy Shevchenko and Yury Norov
 - added Documentation/arch/arm64/mte-tag-compression.rst

v3:
 - as suggested by Andy Shevchenko, use
   bitmap_get_value()/bitmap_set_value() written by Syed Nayyar Waris
 - switched to unsigned long to reduce typecasts
 - simplified the compression code

v2:
 - as suggested by Yuri Norov, replace the poorly implemented struct
   bitq with <linux/bitmap.h>


Alexander Potapenko (6):
  lib/test_bitmap: add tests for bitmap_{read,write}()
  lib/test_bitmap: use pr_info() for non-error messages
  arm64: mte: implement CONFIG_ARM64_MTE_COMP
  arm64: mte: add a test for MTE tags compression
  arm64: mte: add compression support to mteswap.c
  arm64: mte: implement CONFIG_ARM64_MTE_SWAP_STATS

Syed Nayyar Waris (1):
  lib/bitmap: add bitmap_{read,write}()

 Documentation/arch/arm64/index.rst            |   1 +
 .../arch/arm64/mte-tag-compression.rst        | 166 ++++++++
 arch/arm64/Kconfig                            |  37 ++
 arch/arm64/include/asm/mtecomp.h              |  39 ++
 arch/arm64/mm/Makefile                        |   2 +
 arch/arm64/mm/mtecomp.c                       | 260 +++++++++++++
 arch/arm64/mm/mtecomp.h                       |  12 +
 arch/arm64/mm/mteswap.c                       | 110 +++++-
 arch/arm64/mm/test_mtecomp.c                  | 364 ++++++++++++++++++
 include/linux/bitmap.h                        |  77 ++++
 lib/test_bitmap.c                             | 185 ++++++++-
 11 files changed, 1240 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/arch/arm64/mte-tag-compression.rst
 create mode 100644 arch/arm64/include/asm/mtecomp.h
 create mode 100644 arch/arm64/mm/mtecomp.c
 create mode 100644 arch/arm64/mm/mtecomp.h
 create mode 100644 arch/arm64/mm/test_mtecomp.c

-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Mon Dec 18 04:40:27 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 13:40:27 +0100
Subject: [PATCH v11-mte 1/7] lib/bitmap: add bitmap_{read,write}()
In-Reply-To: <20231218124033.551770-1-glider@google.com>
References: <20231218124033.551770-1-glider@google.com>
Message-ID: <20231218124033.551770-2-glider@google.com>

From: Syed Nayyar Waris <syednwaris at gmail.com>

The two new functions allow reading/writing values of length up to
BITS_PER_LONG bits at arbitrary position in the bitmap.

The code was taken from "bitops: Introduce the for_each_set_clump macro"
by Syed Nayyar Waris with a number of changes and simplifications:
 - instead of using roundup(), which adds an unnecessary dependency
   on <linux/math.h>, we calculate space as BITS_PER_LONG-offset;
 - indentation is reduced by not using else-clauses (suggested by
   checkpatch for bitmap_get_value());
 - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read()
   and bitmap_write();
 - some redundant computations are omitted.

Cc: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
Signed-off-by: William Breathitt Gray <william.gray at linaro.org>
Link: https://lore.kernel.org/lkml/fe12eedf3666f4af5138de0e70b67a07c7f40338.1592224129.git.syednwaris at gmail.com/
Suggested-by: Yury Norov <yury.norov at gmail.com>
Co-developed-by: Alexander Potapenko <glider at google.com>
Signed-off-by: Alexander Potapenko <glider at google.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Acked-by: Yury Norov <yury.norov at gmail.com>

---
v11-mte:
 - add Yury's Acked-by:

v10-mte:
 - send this patch together with the "Implement MTE tag compression for
   swapped pages"

Revisions v8-v12 of bitmap patches were reviewed separately from the
"Implement MTE tag compression for swapped pages" series
(https://lore.kernel.org/lkml/20231109151106.2385155-1-glider at google.com/)

This patch was previously called "lib/bitmap: add
bitmap_{set,get}_value()"
(https://lore.kernel.org/lkml/20230720173956.3674987-2-glider at google.com/)

v11:
 - rearrange whitespace as requested by Andy Shevchenko,
   add Reviewed-by:, update a comment

v10:
 - update comments as requested by Andy Shevchenko

v8:
 - as suggested by Andy Shevchenko, handle reads/writes of more than
   BITS_PER_LONG bits, add a note for 32-bit systems

v7:
 - Address comments by Yury Norov, Andy Shevchenko, Rasmus Villemoes:
   - update code comments;
   - get rid of GENMASK();
   - s/assign_bit/__assign_bit;
   - more vertical whitespace for better readability;
 - more compact code for bitmap_write() (now for real)

v6:
 - As suggested by Yury Norov, do not require bitmap_read(..., 0) to
   return 0.

v5:
 - Address comments by Yury Norov:
   - updated code comments and patch title/description
   - replace GENMASK(nbits - 1, 0) with BITMAP_LAST_WORD_MASK(nbits)
   - more compact bitmap_write() implementation

v4:
 - Address comments by Andy Shevchenko and Yury Norov:
   - prevent passing values >= 64 to GENMASK()
   - fix commit authorship
   - change comments
   - check for unlikely(nbits==0)
   - drop unnecessary const declarations
   - fix kernel-doc comments
   - rename bitmap_{get,set}_value() to bitmap_{read,write}()
---
 include/linux/bitmap.h | 77 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 99451431e4d65..7ca0379be8c13 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -79,6 +79,10 @@ struct device;
  *  bitmap_to_arr64(buf, src, nbits)            Copy nbits from buf to u64[] dst
  *  bitmap_get_value8(map, start)               Get 8bit value from map at start
  *  bitmap_set_value8(map, value, start)        Set 8bit value to map at start
+ *  bitmap_read(map, start, nbits)              Read an nbits-sized value from
+ *                                              map at start
+ *  bitmap_write(map, value, start, nbits)      Write an nbits-sized value to
+ *                                              map at start
  *
  * Note, bitmap_zero() and bitmap_fill() operate over the region of
  * unsigned longs, that is, bits behind bitmap till the unsigned long
@@ -636,6 +640,79 @@ static inline void bitmap_set_value8(unsigned long *map, unsigned long value,
 	map[index] |= value << offset;
 }
 
+/**
+ * bitmap_read - read a value of n-bits from the memory region
+ * @map: address to the bitmap memory region
+ * @start: bit offset of the n-bit value
+ * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG
+ *
+ * Returns: value of @nbits bits located at the @start bit offset within the
+ * @map memory region. For @nbits = 0 and @nbits > BITS_PER_LONG the return
+ * value is undefined.
+ */
+static inline unsigned long bitmap_read(const unsigned long *map,
+					unsigned long start,
+					unsigned long nbits)
+{
+	size_t index = BIT_WORD(start);
+	unsigned long offset = start % BITS_PER_LONG;
+	unsigned long space = BITS_PER_LONG - offset;
+	unsigned long value_low, value_high;
+
+	if (unlikely(!nbits || nbits > BITS_PER_LONG))
+		return 0;
+
+	if (space >= nbits)
+		return (map[index] >> offset) & BITMAP_LAST_WORD_MASK(nbits);
+
+	value_low = map[index] & BITMAP_FIRST_WORD_MASK(start);
+	value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start + nbits);
+	return (value_low >> offset) | (value_high << space);
+}
+
+/**
+ * bitmap_write - write n-bit value within a memory region
+ * @map: address to the bitmap memory region
+ * @value: value to write, clamped to nbits
+ * @start: bit offset of the n-bit value
+ * @nbits: size of value in bits, nonzero, up to BITS_PER_LONG.
+ *
+ * bitmap_write() behaves as-if implemented as @nbits calls of __assign_bit(),
+ * i.e. bits beyond @nbits are ignored:
+ *
+ *   for (bit = 0; bit < nbits; bit++)
+ *           __assign_bit(start + bit, bitmap, val & BIT(bit));
+ *
+ * For @nbits == 0 and @nbits > BITS_PER_LONG no writes are performed.
+ */
+static inline void bitmap_write(unsigned long *map, unsigned long value,
+				unsigned long start, unsigned long nbits)
+{
+	size_t index;
+	unsigned long offset;
+	unsigned long space;
+	unsigned long mask;
+	bool fit;
+
+	if (unlikely(!nbits || nbits > BITS_PER_LONG))
+		return;
+
+	mask = BITMAP_LAST_WORD_MASK(nbits);
+	value &= mask;
+	offset = start % BITS_PER_LONG;
+	space = BITS_PER_LONG - offset;
+	fit = space >= nbits;
+	index = BIT_WORD(start);
+
+	map[index] &= (fit ? (~(mask << offset)) : ~BITMAP_FIRST_WORD_MASK(start));
+	map[index] |= value << offset;
+	if (fit)
+		return;
+
+	map[index + 1] &= BITMAP_FIRST_WORD_MASK(start + nbits);
+	map[index + 1] |= (value >> space);
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __LINUX_BITMAP_H */
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Mon Dec 18 04:40:28 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 13:40:28 +0100
Subject: [PATCH v11-mte 2/7] lib/test_bitmap: add tests for bitmap_{read,write}()
In-Reply-To: <20231218124033.551770-1-glider@google.com>
References: <20231218124033.551770-1-glider@google.com>
Message-ID: <20231218124033.551770-3-glider@google.com>

Add basic tests ensuring that values can be added at arbitrary positions
of the bitmap, including those spanning into the adjacent unsigned
longs.

Two new performance tests, test_bitmap_read_perf() and
test_bitmap_write_perf(), can be used to assess future performance
improvements of bitmap_read() and bitmap_write():

[    0.431119][    T1] test_bitmap: Time spent in test_bitmap_read_perf:	615253
[    0.433197][    T1] test_bitmap: Time spent in test_bitmap_write_perf:	916313

(numbers from a Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz machine running
QEMU).

Signed-off-by: Alexander Potapenko <glider at google.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Acked-by: Yury Norov <yury.norov at gmail.com>

---
v11-mte:
 - add Yury's Acked-by:

v10-mte:
 - send this patch together with the "Implement MTE tag compression for
   swapped pages"

Revisions v8-v12 of bitmap patches were reviewed separately from the
"Implement MTE tag compression for swapped pages" series
(https://lore.kernel.org/lkml/20231109151106.2385155-1-glider at google.com/)

This patch was previously called
"lib/test_bitmap: add tests for bitmap_{set,get}_value()"
(https://lore.kernel.org/lkml/20230720173956.3674987-3-glider at google.com/)
and
"lib/test_bitmap: add tests for bitmap_{set,get}_value_unaligned"
(https://lore.kernel.org/lkml/20230713125706.2884502-3-glider at google.com/)

v12:
 - as suggested by Alexander Lobakin, replace expect_eq_uint() with
   expect_eq_ulong() and a cast

v9:
 - use WRITE_ONCE() to prevent optimizations in test_bitmap_read_perf()
 - update patch description

v8:
 - as requested by Andy Shevchenko, add tests for reading/writing
   sizes > BITS_PER_LONG

v7:
 - as requested by Yury Norov, add performance tests for bitmap_read()
   and bitmap_write()

v6:
 - use bitmap API to initialize test bitmaps
 - as requested by Yury Norov, do not check the return value of
   bitmap_read(..., 0)
 - fix a compiler warning on 32-bit systems

v5:
 - update patch title
 - address Yury Norov's comments:
   - rename the test cases
   - factor out test_bitmap_write_helper() to test writing over
     different background patterns;
   - add a test case copying a nontrivial value bit-by-bit;
   - drop volatile

v4:
 - Address comments by Andy Shevchenko: added Reviewed-by: and a link to
   the previous discussion
 - Address comments by Yury Norov:
   - expand the bitmap to catch more corner cases
   - add code testing that bitmap_set_value() does not touch adjacent
     bits
   - add code testing the nbits==0 case
   - rename bitmap_{get,set}_value() to bitmap_{read,write}()

v3:
 - switch to using bitmap_{set,get}_value()
 - change the expected bit pattern in test_set_get_value(),
   as the test was incorrectly assuming 0 is the LSB.
---
 lib/test_bitmap.c | 179 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 172 insertions(+), 7 deletions(-)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 65f22c2578b06..46c0154680772 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -60,18 +60,17 @@ static const unsigned long exp3_1_0[] __initconst = {
 };
 
 static bool __init
-__check_eq_uint(const char *srcfile, unsigned int line,
-		const unsigned int exp_uint, unsigned int x)
+__check_eq_ulong(const char *srcfile, unsigned int line,
+		 const unsigned long exp_ulong, unsigned long x)
 {
-	if (exp_uint != x) {
-		pr_err("[%s:%u] expected %u, got %u\n",
-			srcfile, line, exp_uint, x);
+	if (exp_ulong != x) {
+		pr_err("[%s:%u] expected %lu, got %lu\n",
+			srcfile, line, exp_ulong, x);
 		return false;
 	}
 	return true;
 }
 
-
 static bool __init
 __check_eq_bitmap(const char *srcfile, unsigned int line,
 		  const unsigned long *exp_bmap, const unsigned long *bmap,
@@ -185,7 +184,8 @@ __check_eq_str(const char *srcfile, unsigned int line,
 		result;							\
 	})
 
-#define expect_eq_uint(...)		__expect_eq(uint, ##__VA_ARGS__)
+#define expect_eq_ulong(...)		__expect_eq(ulong, ##__VA_ARGS__)
+#define expect_eq_uint(x, y)		expect_eq_ulong((unsigned int)(x), (unsigned int)(y))
 #define expect_eq_bitmap(...)		__expect_eq(bitmap, ##__VA_ARGS__)
 #define expect_eq_pbl(...)		__expect_eq(pbl, ##__VA_ARGS__)
 #define expect_eq_u32_array(...)	__expect_eq(u32_array, ##__VA_ARGS__)
@@ -1245,6 +1245,168 @@ static void __init test_bitmap_const_eval(void)
 	BUILD_BUG_ON(~var != ~BIT(25));
 }
 
+/*
+ * Test bitmap should be big enough to include the cases when start is not in
+ * the first word, and start+nbits lands in the following word.
+ */
+#define TEST_BIT_LEN (1000)
+
+/*
+ * Helper function to test bitmap_write() overwriting the chosen byte pattern.
+ */
+static void __init test_bitmap_write_helper(const char *pattern)
+{
+	DECLARE_BITMAP(bitmap, TEST_BIT_LEN);
+	DECLARE_BITMAP(exp_bitmap, TEST_BIT_LEN);
+	DECLARE_BITMAP(pat_bitmap, TEST_BIT_LEN);
+	unsigned long w, r, bit;
+	int i, n, nbits;
+
+	/*
+	 * Only parse the pattern once and store the result in the intermediate
+	 * bitmap.
+	 */
+	bitmap_parselist(pattern, pat_bitmap, TEST_BIT_LEN);
+
+	/*
+	 * Check that writing a single bit does not accidentally touch the
+	 * adjacent bits.
+	 */
+	for (i = 0; i < TEST_BIT_LEN; i++) {
+		bitmap_copy(bitmap, pat_bitmap, TEST_BIT_LEN);
+		bitmap_copy(exp_bitmap, pat_bitmap, TEST_BIT_LEN);
+		for (bit = 0; bit <= 1; bit++) {
+			bitmap_write(bitmap, bit, i, 1);
+			__assign_bit(i, exp_bitmap, bit);
+			expect_eq_bitmap(exp_bitmap, bitmap,
+					 TEST_BIT_LEN);
+		}
+	}
+
+	/* Ensure writing 0 bits does not change anything. */
+	bitmap_copy(bitmap, pat_bitmap, TEST_BIT_LEN);
+	bitmap_copy(exp_bitmap, pat_bitmap, TEST_BIT_LEN);
+	for (i = 0; i < TEST_BIT_LEN; i++) {
+		bitmap_write(bitmap, ~0UL, i, 0);
+		expect_eq_bitmap(exp_bitmap, bitmap, TEST_BIT_LEN);
+	}
+
+	for (nbits = BITS_PER_LONG; nbits >= 1; nbits--) {
+		w = IS_ENABLED(CONFIG_64BIT) ? 0xdeadbeefdeadbeefUL
+					     : 0xdeadbeefUL;
+		w >>= (BITS_PER_LONG - nbits);
+		for (i = 0; i <= TEST_BIT_LEN - nbits; i++) {
+			bitmap_copy(bitmap, pat_bitmap, TEST_BIT_LEN);
+			bitmap_copy(exp_bitmap, pat_bitmap, TEST_BIT_LEN);
+			for (n = 0; n < nbits; n++)
+				__assign_bit(i + n, exp_bitmap, w & BIT(n));
+			bitmap_write(bitmap, w, i, nbits);
+			expect_eq_bitmap(exp_bitmap, bitmap, TEST_BIT_LEN);
+			r = bitmap_read(bitmap, i, nbits);
+			expect_eq_ulong(r, w);
+		}
+	}
+}
+
+static void __init test_bitmap_read_write(void)
+{
+	unsigned char *pattern[3] = {"", "all:1/2", "all"};
+	DECLARE_BITMAP(bitmap, TEST_BIT_LEN);
+	unsigned long zero_bits = 0, bits_per_long = BITS_PER_LONG;
+	unsigned long val;
+	int i, pi;
+
+	/*
+	 * Reading/writing zero bits should not crash the kernel.
+	 * READ_ONCE() prevents constant folding.
+	 */
+	bitmap_write(NULL, 0, 0, READ_ONCE(zero_bits));
+	/* Return value of bitmap_read() is undefined here. */
+	bitmap_read(NULL, 0, READ_ONCE(zero_bits));
+
+	/*
+	 * Reading/writing more than BITS_PER_LONG bits should not crash the
+	 * kernel. READ_ONCE() prevents constant folding.
+	 */
+	bitmap_write(NULL, 0, 0, READ_ONCE(bits_per_long) + 1);
+	/* Return value of bitmap_read() is undefined here. */
+	bitmap_read(NULL, 0, READ_ONCE(bits_per_long) + 1);
+
+	/*
+	 * Ensure that bitmap_read() reads the same value that was previously
+	 * written, and two consequent values are correctly merged.
+	 * The resulting bit pattern is asymmetric to rule out possible issues
+	 * with bit numeration order.
+	 */
+	for (i = 0; i < TEST_BIT_LEN - 7; i++) {
+		bitmap_zero(bitmap, TEST_BIT_LEN);
+
+		bitmap_write(bitmap, 0b10101UL, i, 5);
+		val = bitmap_read(bitmap, i, 5);
+		expect_eq_ulong(0b10101UL, val);
+
+		bitmap_write(bitmap, 0b101UL, i + 5, 3);
+		val = bitmap_read(bitmap, i + 5, 3);
+		expect_eq_ulong(0b101UL, val);
+
+		val = bitmap_read(bitmap, i, 8);
+		expect_eq_ulong(0b10110101UL, val);
+	}
+
+	for (pi = 0; pi < ARRAY_SIZE(pattern); pi++)
+		test_bitmap_write_helper(pattern[pi]);
+}
+
+static void __init test_bitmap_read_perf(void)
+{
+	DECLARE_BITMAP(bitmap, TEST_BIT_LEN);
+	unsigned int cnt, nbits, i;
+	unsigned long val;
+	ktime_t time;
+
+	bitmap_fill(bitmap, TEST_BIT_LEN);
+	time = ktime_get();
+	for (cnt = 0; cnt < 5; cnt++) {
+		for (nbits = 1; nbits <= BITS_PER_LONG; nbits++) {
+			for (i = 0; i < TEST_BIT_LEN; i++) {
+				if (i + nbits > TEST_BIT_LEN)
+					break;
+				/*
+				 * Prevent the compiler from optimizing away the
+				 * bitmap_read() by using its value.
+				 */
+				WRITE_ONCE(val, bitmap_read(bitmap, i, nbits));
+			}
+		}
+	}
+	time = ktime_get() - time;
+	pr_err("Time spent in %s:\t%llu\n", __func__, time);
+}
+
+static void __init test_bitmap_write_perf(void)
+{
+	DECLARE_BITMAP(bitmap, TEST_BIT_LEN);
+	unsigned int cnt, nbits, i;
+	unsigned long val = 0xfeedface;
+	ktime_t time;
+
+	bitmap_zero(bitmap, TEST_BIT_LEN);
+	time = ktime_get();
+	for (cnt = 0; cnt < 5; cnt++) {
+		for (nbits = 1; nbits <= BITS_PER_LONG; nbits++) {
+			for (i = 0; i < TEST_BIT_LEN; i++) {
+				if (i + nbits > TEST_BIT_LEN)
+					break;
+				bitmap_write(bitmap, val, i, nbits);
+			}
+		}
+	}
+	time = ktime_get() - time;
+	pr_err("Time spent in %s:\t%llu\n", __func__, time);
+}
+
+#undef TEST_BIT_LEN
+
 static void __init selftest(void)
 {
 	test_zero_clear();
@@ -1261,6 +1423,9 @@ static void __init selftest(void)
 	test_bitmap_cut();
 	test_bitmap_print_buf();
 	test_bitmap_const_eval();
+	test_bitmap_read_write();
+	test_bitmap_read_perf();
+	test_bitmap_write_perf();
 
 	test_find_nth_bit();
 	test_for_each_set_bit();
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Mon Dec 18 04:40:29 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 13:40:29 +0100
Subject: [PATCH v11-mte 3/7] lib/test_bitmap: use pr_info() for non-error messages
In-Reply-To: <20231218124033.551770-1-glider@google.com>
References: <20231218124033.551770-1-glider@google.com>
Message-ID: <20231218124033.551770-4-glider@google.com>

pr_err() messages may be treated as errors by some log readers, so let
us only use them for test failures. For non-error messages, replace them
with pr_info().

Suggested-by: Alexander Lobakin <aleksander.lobakin at intel.com>
Signed-off-by: Alexander Potapenko <glider at google.com>
Acked-by: Yury Norov <yury.norov at gmail.com>

---
v11-mte:
 - add Yury's Acked-by:

v10-mte:
 - send this patch together with the "Implement MTE tag compression for
   swapped pages"
---
 lib/test_bitmap.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 46c0154680772..a6e92cf5266af 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -507,7 +507,7 @@ static void __init test_bitmap_parselist(void)
 		}
 
 		if (ptest.flags & PARSE_TIME)
-			pr_err("parselist: %d: input is '%s' OK, Time: %llu\n",
+			pr_info("parselist: %d: input is '%s' OK, Time: %llu\n",
 					i, ptest.in, time);
 
 #undef ptest
@@ -546,7 +546,7 @@ static void __init test_bitmap_printlist(void)
 		goto out;
 	}
 
-	pr_err("bitmap_print_to_pagebuf: input is '%s', Time: %llu\n", buf, time);
+	pr_info("bitmap_print_to_pagebuf: input is '%s', Time: %llu\n", buf, time);
 out:
 	kfree(buf);
 	kfree(bmap);
@@ -624,7 +624,7 @@ static void __init test_bitmap_parse(void)
 		}
 
 		if (test.flags & PARSE_TIME)
-			pr_err("parse: %d: input is '%s' OK, Time: %llu\n",
+			pr_info("parse: %d: input is '%s' OK, Time: %llu\n",
 					i, test.in, time);
 	}
 }
@@ -1380,7 +1380,7 @@ static void __init test_bitmap_read_perf(void)
 		}
 	}
 	time = ktime_get() - time;
-	pr_err("Time spent in %s:\t%llu\n", __func__, time);
+	pr_info("Time spent in %s:\t%llu\n", __func__, time);
 }
 
 static void __init test_bitmap_write_perf(void)
@@ -1402,7 +1402,7 @@ static void __init test_bitmap_write_perf(void)
 		}
 	}
 	time = ktime_get() - time;
-	pr_err("Time spent in %s:\t%llu\n", __func__, time);
+	pr_info("Time spent in %s:\t%llu\n", __func__, time);
 }
 
 #undef TEST_BIT_LEN
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Mon Dec 18 04:40:30 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 13:40:30 +0100
Subject: [PATCH v11-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP
In-Reply-To: <20231218124033.551770-1-glider@google.com>
References: <20231218124033.551770-1-glider@google.com>
Message-ID: <20231218124033.551770-5-glider@google.com>

The config implements the algorithm compressing memory tags for ARM MTE
during swapping.

The algorithm is based on RLE and specifically targets buffers of tags
corresponding to a single page. In many cases a buffer can be compressed
into 63 bits, making it possible to store it without additional memory
allocation.

Suggested-by: Evgenii Stepanov <eugenis at google.com>
Signed-off-by: Alexander Potapenko <glider at google.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>

---
 v11-mte:
  - Address Yury's comments: change variable name to reflow the code,
    add a comment

 v10-mte:
  - added Catalin's Acked-by:

 v8:
  - As suggested by Catalin Marinas, only compress tags if they can be
    stored inline. This simplifies the code drastically.
  - Update the documentation.
  - Split off patches introducing bitmap_read()/bitmap_write().

 v6:
  - shuffle bits in inline handles so that they can't be confused with
    canonical pointers;
  - use kmem_cache_zalloc() to allocate compressed storage
  - correctly handle range size overflow
  - minor documentation fixes, clarify the special cases

 v5:
  - make code PAGE_SIZE-agnostic, remove hardcoded constants, updated
    the docs
  - implement debugfs interface
  - Address comments by Andy Shevchenko:
    - update description of mtecomp.c
    - remove redundant assignments, simplify mte_tags_to_ranges()
    - various code simplifications
    - introduce mtecomp.h
    - add :export: to Documentation/arch/arm64/mte-tag-compression.rst

 v4:
  - Addressed comments by Andy Shevchenko:
    - expanded "MTE" to "Memory Tagging Extension" in Kconfig
    - fixed kernel-doc comments, moved them to C source
    - changed variables to unsigned where applicable
    - some code simplifications, fewer unnecessary assignments
    - added the mte_largest_idx_bits() helper
    - added namespace prefixes to all functions
    - added missing headers (but removed bits.h)
  - Addressed comments by Yury Norov:
    - removed test-only functions from mtecomp.h
    - dropped the algoritm name (all functions are now prefixed with
      "mte")
    - added more comments
    - got rid of MTE_RANGES_INLINE
    - renamed bitmap_{get,set}_value() to bitmap_{read,write}()
    - moved the big comment explaining the algorithm to
      Documentation/arch/arm64/mte-tag-compression.rst, expanded it,
      add a link to it from Documentation/arch/arm64/index.rst
    - removed hardcoded ranges from mte_alloc_size()/mte_size_to_ranges()

 v3:
  - Addressed comments by Andy Shevchenko:
   - use bitmap_{set,get}_value() writte by Syed Nayyar Waris
   - switched to unsigned long everywhere (fewer casts)
   - simplified the code, removed redundant checks
   - dropped ea0_compress_inline()
 - added bit size constants and helpers to access the bitmap
 - explicitly initialize all compressed sizes in ea0_compress_to_buf()
 - initialize all handle bits

 v2:
  - as suggested by Yury Norov, switched from struct bitq (which is
    not needed anymore) to <linux/bitmap.h>
  - add missing symbol exports

fixup CONFIG_ARM64_MTE_COMP
---
 Documentation/arch/arm64/index.rst            |   1 +
 .../arch/arm64/mte-tag-compression.rst        | 154 +++++++++++
 arch/arm64/Kconfig                            |  11 +
 arch/arm64/include/asm/mtecomp.h              |  39 +++
 arch/arm64/mm/Makefile                        |   1 +
 arch/arm64/mm/mtecomp.c                       | 260 ++++++++++++++++++
 arch/arm64/mm/mtecomp.h                       |  12 +
 7 files changed, 478 insertions(+)
 create mode 100644 Documentation/arch/arm64/mte-tag-compression.rst
 create mode 100644 arch/arm64/include/asm/mtecomp.h
 create mode 100644 arch/arm64/mm/mtecomp.c
 create mode 100644 arch/arm64/mm/mtecomp.h

diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
index d08e924204bf1..bf6c1583233a9 100644
--- a/Documentation/arch/arm64/index.rst
+++ b/Documentation/arch/arm64/index.rst
@@ -19,6 +19,7 @@ ARM64 Architecture
     legacy_instructions
     memory
     memory-tagging-extension
+    mte-tag-compression
     perf
     pointer-authentication
     ptdump
diff --git a/Documentation/arch/arm64/mte-tag-compression.rst b/Documentation/arch/arm64/mte-tag-compression.rst
new file mode 100644
index 0000000000000..8fe6b51a9db6d
--- /dev/null
+++ b/Documentation/arch/arm64/mte-tag-compression.rst
@@ -0,0 +1,154 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==================================================
+Tag Compression for Memory Tagging Extension (MTE)
+==================================================
+
+This document describes the algorithm used to compress memory tags used by the
+ARM Memory Tagging Extension (MTE).
+
+Introduction
+============
+
+MTE assigns tags to memory pages: for 4K pages those tags occupy 128 bytes
+(256 4-bit tags each corresponding to a 16-byte MTE granule), for 16K pages -
+512 bytes, for 64K pages - 2048 bytes. By default, MTE carves out 3.125% (1/16)
+of the available physical memory to store the tags.
+
+When MTE pages are saved to swap, their tags need to be stored in the kernel
+memory. If the system swap is used heavily, these tags may take a substantial
+portion of the physical memory. To reduce memory waste, ``CONFIG_ARM64_MTE_COMP``
+allows the kernel to store the tags in compressed form.
+
+Implementation details
+======================
+
+The algorithm attempts to compress an array of ``MTE_PAGE_TAG_STORAGE``
+tag bytes into a byte sequence that can be stored in an 8-byte pointer. If that
+is not possible, the data is stored uncompressed.
+
+Tag manipulation and storage
+----------------------------
+
+Tags for swapped pages are stored in an XArray that maps swap entries to 63-bit
+values (see ``arch/arm64/mm/mteswap.c``). Bit 0 of these values indicates how
+their contents should be treated:
+
+ - 0: value is a pointer to an uncompressed buffer allocated with kmalloc()
+   (always the case if ``CONFIG_ARM64_MTE_COMP=n``) with the highest bit set
+   to 0;
+ - 1: value contains compressed data.
+
+``arch/arm64/include/asm/mtecomp.h`` declares the following functions that
+manipulate with tags:
+
+- mte_compress() - compresses the given ``MTE_PAGE_TAG_STORAGE``-byte ``tags``
+  buffer into a pointer;
+- mte_decompress() - decompresses the tags from a pointer;
+- mte_is_compressed() - returns ``true`` iff the pointer passed to it should be
+  treated as compressed data.
+
+Tag compression
+---------------
+
+The compression algorithm is a variation of RLE (run-length encoding) and works
+as follows (we will be considering 4K pages and 128-byte tag buffers, but the
+same approach scales to 16K and 64K pages):
+
+1. The input array of 128 (``MTE_PAGE_TAG_STORAGE``) bytes is transformed into
+   tag ranges (two arrays: ``r_tags[]`` containing tag values and ``r_sizes[]``
+   containing range lengths) by mte_tags_to_ranges(). Note that
+   ``r_sizes[]`` sums up to 256 (``MTE_GRANULES_PER_PAGE``).
+
+   If ``r_sizes[]`` consists of a single element
+   (``{ MTE_GRANULES_PER_PAGE }``), the corresponding range is split into two
+   halves, i.e.::
+
+     r_sizes_new[2] = { MTE_GRANULES_PER_PAGE/2, MTE_GRANULES_PER_PAGE/2 };
+     r_tags_new[2] = { r_tags[0], r_tags[0] };
+
+2. The number of the largest element of ``r_sizes[]`` is stored in
+   ``largest_idx``. The element itself is thrown away from ``r_sizes[]``,
+   because it can be reconstructed from the sum of the remaining elements. Note
+   that now none of the remaining ``r_sizes[]`` elements exceeds
+   ``MTE_GRANULES_PER_PAGE/2``.
+
+3. If the number ``N`` of ranges does not exceed ``6``, the ranges can be
+   compressed into 64 bits. This is done by storing the following values packed
+   into the pointer (``i<size>`` means a ``<size>``-bit unsigned integer)
+   treated as a bitmap (see ``include/linux/bitmap.h``)::
+
+    bit 0      :      (always 1) : i1
+    bits 1-3   :     largest_idx : i3
+    bits 4-27  :    r_tags[0..5] : i4 x 6
+    bits 28-62 :   r_sizes[0..4] : i7 x 5
+    bit 63     :      (always 0) : i1
+
+   If N is less than 6, ``r_tags`` and ``r_sizes`` are padded up with zero
+   values. The unused bits in the pointer, including bit 63, are also set to 0,
+   so the compressed data can be stored in XArray.
+
+   Range size of ``MTE_GRANULES_PER_PAGE/2`` (at most one) does not fit into
+   i7 and will be written as 0. This case is handled separately by the
+   decompressing procedure.
+
+Tag decompression
+-----------------
+
+The decompression algorithm performs the steps below.
+
+1. Read the lowest bit of the data from the input buffer and check that it is 1,
+   otherwise bail out.
+
+2. Read ``largest_idx``, ``r_tags[]`` and ``r_sizes[]`` from the
+   input buffer.
+
+   If ``largest_idx`` is zero, and all ``r_sizes[]`` are zero, set
+   ``r_sizes[0] = MTE_GRANULES_PER_PAGE/2``.
+
+   Calculate the removed largest element of ``r_sizes[]`` as
+   ``largest = 256 - sum(r_sizes)`` and insert it into ``r_sizes`` at
+   position ``largest_idx``.
+
+6. For each ``r_sizes[i] > 0``, add a 4-bit value ``r_tags[i]`` to the output
+   buffer ``r_sizes[i]`` times.
+
+
+Why these numbers?
+------------------
+
+To be able to reconstruct ``N`` tag ranges from the compressed data, we need to
+store the indicator bit together with ``largest_idx``, ``r_tags[N]``, and
+``r_sizes[N-1]`` in 63 bits.
+Knowing that the sizes do not exceed ``MTE_PAGE_TAG_STORAGE``, each of them can be
+packed into ``S = ilog2(MTE_PAGE_TAG_STORAGE)`` bits, whereas a single tag occupies
+4 bits.
+
+It is evident that the number of ranges that can be stored in 63 bits is
+strictly less than 8, therefore we only need 3 bits to store ``largest_idx``.
+
+The maximum values of ``N`` so that the number ``1 + 3 + N * 4 + (N-1) * S`` of
+storage bits does not exceed 63, are shown in the table below::
+
+ +-----------+-----------------+----+---+-------------------+
+ | Page size | Tag buffer size |  S | N |    Storage bits   |
+ +-----------+-----------------+----+---+-------------------+
+ |      4 KB |           128 B |  7 | 6 | 63 = 1+3+6*4+5*7  |
+ |     16 KB |           512 B |  9 | 5 | 60 = 1+3+5*4+4*9  |
+ |     64 KB |          2048 B | 11 | 4 | 53 = 1+3+4*4+3*11 |
+ +-----------+-----------------+----+---+-------------------+
+
+Note
+----
+
+Tag compression and decompression implicitly rely on the fixed MTE tag size
+(4 bits) and number of tags per page. Should these values change, the algorithm
+may need to be revised.
+
+
+Programming Interface
+=====================
+
+ .. kernel-doc:: arch/arm64/include/asm/mtecomp.h
+ .. kernel-doc:: arch/arm64/mm/mtecomp.c
+   :export:
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d2..5f4d4b49a512e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2078,6 +2078,17 @@ config ARM64_EPAN
 	  if the cpu does not implement the feature.
 endmenu # "ARMv8.7 architectural features"
 
+config ARM64_MTE_COMP
+	bool "Tag compression for ARM64 Memory Tagging Extension"
+	default y
+	depends on ARM64_MTE
+	help
+	  Enable tag compression support for ARM64 Memory Tagging Extension.
+
+	  Tag buffers corresponding to swapped RAM pages are compressed using
+	  RLE to conserve heap memory. In the common case compressed tags
+	  occupy 2.5x less memory.
+
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
diff --git a/arch/arm64/include/asm/mtecomp.h b/arch/arm64/include/asm/mtecomp.h
new file mode 100644
index 0000000000000..b9a3a921a38d4
--- /dev/null
+++ b/arch/arm64/include/asm/mtecomp.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_MTECOMP_H
+#define __ASM_MTECOMP_H
+
+#include <linux/types.h>
+
+/**
+ * mte_is_compressed() - check if the supplied pointer contains compressed tags.
+ * @ptr: pointer returned by kmalloc() or mte_compress().
+ *
+ * Returns: true iff bit 0 of @ptr is 1, which is only possible if @ptr was
+ * returned by mte_is_compressed().
+ */
+static inline bool mte_is_compressed(void *ptr)
+{
+	return ((unsigned long)ptr & 1);
+}
+
+#if defined(CONFIG_ARM64_MTE_COMP)
+
+void *mte_compress(u8 *tags);
+bool mte_decompress(void *handle, u8 *tags);
+
+#else
+
+static inline void *mte_compress(u8 *tags)
+{
+	return NULL;
+}
+
+static inline bool mte_decompress(void *data, u8 *tags)
+{
+	return false;
+}
+
+#endif // CONFIG_ARM64_MTE_COMP
+
+#endif // __ASM_MTECOMP_H
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index dbd1bc95967d0..46778f6dd83c2 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd.o
 obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd-asm.o
 obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o
 obj-$(CONFIG_ARM64_MTE)		+= mteswap.o
+obj-$(CONFIG_ARM64_MTE_COMP)	+= mtecomp.o
 KASAN_SANITIZE_physaddr.o	+= n
 
 obj-$(CONFIG_KASAN)		+= kasan_init.o
diff --git a/arch/arm64/mm/mtecomp.c b/arch/arm64/mm/mtecomp.c
new file mode 100644
index 0000000000000..bb5cbd3edb5ba
--- /dev/null
+++ b/arch/arm64/mm/mtecomp.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * MTE tag compression algorithm.
+ * See Documentation/arch/arm64/mte-tag-compression.rst for more details.
+ */
+
+#include <linux/bits.h>
+#include <linux/bitmap.h>
+#include <linux/bitops.h>
+#include <linux/export.h>
+#include <linux/gfp.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+
+#include <asm/mtecomp.h>
+
+#include "mtecomp.h"
+
+#define MTE_BITS_PER_LARGEST_IDX 3
+/* Range size cannot exceed MTE_GRANULES_PER_PAGE / 2. */
+#define MTE_BITS_PER_SIZE (ilog2(MTE_GRANULES_PER_PAGE) - 1)
+
+/*
+ * See Documentation/arch/arm64/mte-tag-compression.rst for details on how the
+ * maximum number of ranges is calculated.
+ */
+#if defined(CONFIG_ARM64_4K_PAGES)
+#define MTE_MAX_RANGES 6
+#elif defined(CONFIG_ARM64_16K_PAGES)
+#define MTE_MAX_RANGES 5
+#else
+#define MTE_MAX_RANGES 4
+#endif
+
+/**
+ * mte_tags_to_ranges() - break @tags into arrays of tag ranges.
+ * @tags: MTE_GRANULES_PER_PAGE-byte array containing MTE tags.
+ * @out_tags: u8 array to store the tag of every range.
+ * @out_sizes: unsigned short array to store the size of every range.
+ * @out_len: length of @out_tags and @out_sizes (output parameter, initially
+ *           equal to lengths of out_tags[] and out_sizes[]).
+ *
+ * This function is exported for testing purposes.
+ */
+void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
+			size_t *out_len)
+{
+	u8 prev_tag = tags[0] / 16; /* First tag in the array. */
+	unsigned int cur_idx = 0, i, j;
+	u8 cur_tag;
+
+	memset(out_tags, 0, array_size(*out_len, sizeof(*out_tags)));
+	memset(out_sizes, 0, array_size(*out_len, sizeof(*out_sizes)));
+
+	out_tags[cur_idx] = prev_tag;
+	for (i = 0; i < MTE_GRANULES_PER_PAGE; i++) {
+		j = i % 2;
+		cur_tag = j ? (tags[i / 2] % 16) : (tags[i / 2] / 16);
+		if (cur_tag == prev_tag) {
+			out_sizes[cur_idx]++;
+		} else {
+			cur_idx++;
+			prev_tag = cur_tag;
+			out_tags[cur_idx] = prev_tag;
+			out_sizes[cur_idx] = 1;
+		}
+	}
+	*out_len = cur_idx + 1;
+}
+EXPORT_SYMBOL_NS(mte_tags_to_ranges, MTECOMP);
+
+/**
+ * mte_ranges_to_tags() - fill @tags using given tag ranges.
+ * @r_tags: u8[] containing the tag of every range.
+ * @r_sizes: unsigned short[] containing the size of every range.
+ * @r_len: length of @r_tags and @r_sizes.
+ * @tags: MTE_GRANULES_PER_PAGE-byte array to write the tags to.
+ *
+ * This function is exported for testing purposes.
+ */
+void mte_ranges_to_tags(u8 *r_tags, unsigned short *r_sizes, size_t r_len,
+			u8 *tags)
+{
+	unsigned int i, j, pos = 0;
+	u8 prev;
+
+	for (i = 0; i < r_len; i++) {
+		for (j = 0; j < r_sizes[i]; j++) {
+			if (pos % 2)
+				tags[pos / 2] = (prev << 4) | r_tags[i];
+			else
+				prev = r_tags[i];
+			pos++;
+		}
+	}
+}
+EXPORT_SYMBOL_NS(mte_ranges_to_tags, MTECOMP);
+
+static void mte_bitmap_write(unsigned long *bitmap, unsigned long value,
+			     unsigned long *pos, unsigned long bits)
+{
+	bitmap_write(bitmap, value, *pos, bits);
+	*pos += bits;
+}
+
+/* Compress ranges into an unsigned long. */
+static void mte_compress_to_ulong(size_t len, u8 *tags, unsigned short *sizes,
+				  unsigned long *result)
+{
+	unsigned long bit_pos = 0;
+	unsigned int largest_idx, i;
+	unsigned short largest = 0;
+
+	for (i = 0; i < len; i++) {
+		if (sizes[i] > largest) {
+			largest = sizes[i];
+			largest_idx = i;
+		}
+	}
+	/* Bit 1 in position 0 indicates compressed data. */
+	mte_bitmap_write(result, 1, &bit_pos, 1);
+	mte_bitmap_write(result, largest_idx, &bit_pos,
+			 MTE_BITS_PER_LARGEST_IDX);
+	for (i = 0; i < len; i++)
+		mte_bitmap_write(result, tags[i], &bit_pos, MTE_TAG_SIZE);
+	if (len == 1) {
+		/*
+		 * We are compressing MTE_GRANULES_PER_PAGE of identical tags.
+		 * Split it into two ranges containing
+		 * MTE_GRANULES_PER_PAGE / 2 tags, so that it falls into the
+		 * special case described below.
+		 */
+		mte_bitmap_write(result, tags[0], &bit_pos, MTE_TAG_SIZE);
+		i = 2;
+	} else {
+		i = len;
+	}
+	for (; i < MTE_MAX_RANGES; i++)
+		mte_bitmap_write(result, 0, &bit_pos, MTE_TAG_SIZE);
+	/*
+	 * Most of the time sizes[i] fits into MTE_BITS_PER_SIZE, apart from a
+	 * special case when:
+	 *   len = 2;
+	 *   sizes = { MTE_GRANULES_PER_PAGE / 2, MTE_GRANULES_PER_PAGE / 2};
+	 * In this case largest_idx will be set to 0, and the size written to
+	 * the bitmap will be also 0.
+	 */
+	for (i = 0; i < len; i++) {
+		if (i != largest_idx)
+			mte_bitmap_write(result, sizes[i], &bit_pos,
+					 MTE_BITS_PER_SIZE);
+	}
+	for (i = len; i < MTE_MAX_RANGES; i++)
+		mte_bitmap_write(result, 0, &bit_pos, MTE_BITS_PER_SIZE);
+}
+
+/**
+ * mte_compress() - compress the given tag array.
+ * @tags: MTE_GRANULES_PER_PAGE-byte array to read the tags from.
+ *
+ * Attempts to compress the user-supplied tag array.
+ *
+ * Returns: compressed data or NULL.
+ */
+void *mte_compress(u8 *tags)
+{
+	unsigned short *r_sizes;
+	void *result = NULL;
+	u8 *r_tags;
+	size_t r_len;
+
+	r_sizes = kmalloc_array(MTE_GRANULES_PER_PAGE, sizeof(unsigned short),
+				GFP_KERNEL);
+	r_tags = kmalloc(MTE_GRANULES_PER_PAGE, GFP_KERNEL);
+	if (!r_sizes || !r_tags)
+		goto ret;
+	r_len = MTE_GRANULES_PER_PAGE;
+	mte_tags_to_ranges(tags, r_tags, r_sizes, &r_len);
+	if (r_len <= MTE_MAX_RANGES)
+		mte_compress_to_ulong(r_len, r_tags, r_sizes,
+				      (unsigned long *)&result);
+ret:
+	kfree(r_tags);
+	kfree(r_sizes);
+	return result;
+}
+EXPORT_SYMBOL_NS(mte_compress, MTECOMP);
+
+static unsigned long mte_bitmap_read(const unsigned long *bitmap,
+				     unsigned long *pos, unsigned long bits)
+{
+	unsigned long start = *pos;
+
+	*pos += bits;
+	return bitmap_read(bitmap, start, bits);
+}
+
+/**
+ * mte_decompress() - decompress the tag array from the given pointer.
+ * @data: pointer returned by @mte_compress()
+ * @tags: MTE_GRANULES_PER_PAGE-byte array to write the tags to.
+ *
+ * Reads the compressed data and writes it into the user-supplied tag array.
+ *
+ * Returns: true on success, false if the passed data is uncompressed.
+ */
+bool mte_decompress(void *data, u8 *tags)
+{
+	unsigned short r_sizes[MTE_MAX_RANGES];
+	u8 r_tags[MTE_MAX_RANGES];
+	unsigned int largest, i;
+	unsigned long bit_pos = 0;
+	unsigned long *bitmap;
+	unsigned short sum;
+	size_t max_ranges;
+
+	if (!mte_is_compressed(data))
+		return false;
+
+	/*
+	 * @data contains compressed data encoded in the pointer iteself.
+	 * Treat its contents as a bitmap.
+	 */
+	bitmap = (unsigned long *)&data;
+	max_ranges = MTE_MAX_RANGES;
+	/* Skip the leading bit indicating the inline case. */
+	mte_bitmap_read(bitmap, &bit_pos, 1);
+	largest = mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_LARGEST_IDX);
+	if (largest >= MTE_MAX_RANGES)
+		return false;
+
+	for (i = 0; i < max_ranges; i++)
+		r_tags[i] = mte_bitmap_read(bitmap, &bit_pos, MTE_TAG_SIZE);
+	for (i = 0, sum = 0; i < max_ranges; i++) {
+		if (i == largest)
+			continue;
+		r_sizes[i] =
+			mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_SIZE);
+		/*
+		 * Special case: tag array consists of two ranges of
+		 * `MTE_GRANULES_PER_PAGE / 2` tags.
+		 */
+		if ((largest == 0) && (i == 1) && (r_sizes[i] == 0))
+			r_sizes[i] = MTE_GRANULES_PER_PAGE / 2;
+		if (!r_sizes[i]) {
+			max_ranges = i;
+			break;
+		}
+		sum += r_sizes[i];
+	}
+	if (sum >= MTE_GRANULES_PER_PAGE)
+		return false;
+	r_sizes[largest] = MTE_GRANULES_PER_PAGE - sum;
+	mte_ranges_to_tags(r_tags, r_sizes, max_ranges, tags);
+	return true;
+}
+EXPORT_SYMBOL_NS(mte_decompress, MTECOMP);
diff --git a/arch/arm64/mm/mtecomp.h b/arch/arm64/mm/mtecomp.h
new file mode 100644
index 0000000000000..b94cf0384f2af
--- /dev/null
+++ b/arch/arm64/mm/mtecomp.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef ARCH_ARM64_MM_MTECOMP_H_
+#define ARCH_ARM64_MM_MTECOMP_H_
+
+/* Functions exported from mtecomp.c for test_mtecomp.c. */
+void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
+			size_t *out_len);
+void mte_ranges_to_tags(u8 *r_tags, unsigned short *r_sizes, size_t r_len,
+			u8 *tags);
+
+#endif  // ARCH_ARM64_MM_TEST_MTECOMP_H_
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Mon Dec 18 04:40:31 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 13:40:31 +0100
Subject: [PATCH v11-mte 5/7] arm64: mte: add a test for MTE tags compression
In-Reply-To: <20231218124033.551770-1-glider@google.com>
References: <20231218124033.551770-1-glider@google.com>
Message-ID: <20231218124033.551770-6-glider@google.com>

Ensure that tag sequences containing alternating values are compressed
to buffers of expected size and correctly decompressed afterwards.

Signed-off-by: Alexander Potapenko <glider at google.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>

---
 v10-mte:
  - added Catalin's Acked-by:

 v9:
  - minor changes to Kconfig description

 v8:
  - adapt to the simplified compression algorithm

 v6:
  - add test_decompress_invalid() to ensure invalid handles are ignored;
  - add test_upper_bits(), which is a regression test for a case where
    an inline handle looked like an out-of-line one;
  - add test_compress_nonzero() to ensure a full nonzero tag array is
    compressed correctly;
  - add test_two_ranges() to test cases when the input buffer is divided
    into two ranges.

 v5:
  - remove hardcoded constants, added test setup/teardown;
  - support 16- and 64K pages;
  - replace nested if-clauses with expected_size_from_ranges();
  - call mte_release_handle() after tests that perform
    compression/decompression;
  - address comments by Andy Shevchenko:
    - fix include order;
    - use mtecomp.h instead of function prototypes.

 v4:
  - addressed comments by Andy Shevchenko:
    - expanded MTE to "Memory Tagging Extension" in Kconfig
    - changed signed variables to unsigned where applicable
    - added missing header dependencies

  - addressed comments by Yury Norov:
    - moved test-only declarations from mtecomp.h into this test
    - switched to the new "mte"-prefixed function names, dropped the
      mentions of "EA0"
    - added test_tag_to_ranges_n()

 v3:
  - addressed comments by Andy Shevchenko in another patch:
   - switched from u64 to unsigned long
   - added MODULE_IMPORT_NS(MTECOMP)
   - fixed includes order
---
 arch/arm64/Kconfig           |  11 ++
 arch/arm64/mm/Makefile       |   1 +
 arch/arm64/mm/test_mtecomp.c | 364 +++++++++++++++++++++++++++++++++++
 3 files changed, 376 insertions(+)
 create mode 100644 arch/arm64/mm/test_mtecomp.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5f4d4b49a512e..6a1397a96f2f0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2089,6 +2089,17 @@ config ARM64_MTE_COMP
 	  RLE to conserve heap memory. In the common case compressed tags
 	  occupy 2.5x less memory.
 
+config ARM64_MTE_COMP_KUNIT_TEST
+	tristate "Test tag compression for ARM64 Memory Tagging Extension" if !KUNIT_ALL_TESTS
+	default KUNIT_ALL_TESTS
+	depends on KUNIT && ARM64_MTE_COMP
+	help
+	  Test MTE compression algorithm enabled by CONFIG_ARM64_MTE_COMP.
+
+	  Ensure that certain tag sequences containing alternating values can
+	  be compressed into pointer-size values and correctly decompressed
+	  afterwards.
+
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index 46778f6dd83c2..170dc62b010b9 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_TRANS_TABLE)	+= trans_pgd-asm.o
 obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o
 obj-$(CONFIG_ARM64_MTE)		+= mteswap.o
 obj-$(CONFIG_ARM64_MTE_COMP)	+= mtecomp.o
+obj-$(CONFIG_ARM64_MTE_COMP_KUNIT_TEST) += test_mtecomp.o
 KASAN_SANITIZE_physaddr.o	+= n
 
 obj-$(CONFIG_KASAN)		+= kasan_init.o
diff --git a/arch/arm64/mm/test_mtecomp.c b/arch/arm64/mm/test_mtecomp.c
new file mode 100644
index 0000000000000..e8aeb7607ff41
--- /dev/null
+++ b/arch/arm64/mm/test_mtecomp.c
@@ -0,0 +1,364 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for MTE tags compression algorithm.
+ */
+
+#include <linux/bits.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+
+#include <kunit/test.h>
+
+#include <asm/mtecomp.h>
+
+#include "mtecomp.h"
+
+/* Per-test storage allocated in mtecomp_test_init(). */
+struct test_data {
+	u8 *tags, *dtags;
+	unsigned short *r_sizes;
+	size_t r_len;
+	u8 *r_tags;
+};
+
+/*
+ * Split td->tags to ranges stored in td->r_tags, td->r_sizes, td->r_len,
+ * then convert those ranges back to tags stored in td->dtags.
+ */
+static void tags_to_ranges_to_tags_helper(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+
+	mte_tags_to_ranges(td->tags, td->r_tags, td->r_sizes, &td->r_len);
+	mte_ranges_to_tags(td->r_tags, td->r_sizes, td->r_len, td->dtags);
+	KUNIT_EXPECT_EQ(test, memcmp(td->tags, td->dtags, MTE_PAGE_TAG_STORAGE),
+			0);
+}
+
+/*
+ * Test that mte_tags_to_ranges() produces a single range for a zero-filled tag
+ * buffer.
+ */
+static void test_tags_to_ranges_zero(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+
+	memset(td->tags, 0, MTE_PAGE_TAG_STORAGE);
+	tags_to_ranges_to_tags_helper(test);
+
+	KUNIT_EXPECT_EQ(test, td->r_len, 1);
+	KUNIT_EXPECT_EQ(test, td->r_tags[0], 0);
+	KUNIT_EXPECT_EQ(test, td->r_sizes[0], MTE_GRANULES_PER_PAGE);
+}
+
+/*
+ * Test that a small number of different tags is correctly transformed into
+ * ranges.
+ */
+static void test_tags_to_ranges_simple(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	const u8 ex_tags[] = { 0xa, 0x0, 0xa, 0xb, 0x0 };
+	const unsigned short ex_sizes[] = { 1, 2, 2, 1,
+					    MTE_GRANULES_PER_PAGE - 6 };
+
+	memset(td->tags, 0, MTE_PAGE_TAG_STORAGE);
+	td->tags[0] = 0xa0;
+	td->tags[1] = 0x0a;
+	td->tags[2] = 0xab;
+	tags_to_ranges_to_tags_helper(test);
+
+	KUNIT_EXPECT_EQ(test, td->r_len, 5);
+	KUNIT_EXPECT_EQ(test, memcmp(td->r_tags, ex_tags, sizeof(ex_tags)), 0);
+	KUNIT_EXPECT_EQ(test, memcmp(td->r_sizes, ex_sizes, sizeof(ex_sizes)),
+			0);
+}
+
+/* Test that repeated 0xa0 byte produces MTE_GRANULES_PER_PAGE ranges of length 1. */
+static void test_tags_to_ranges_repeated(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+
+	memset(td->tags, 0xa0, MTE_PAGE_TAG_STORAGE);
+	tags_to_ranges_to_tags_helper(test);
+
+	KUNIT_EXPECT_EQ(test, td->r_len, MTE_GRANULES_PER_PAGE);
+}
+
+/* Generate a buffer that will contain @nranges of tag ranges. */
+static void gen_tag_range_helper(u8 *tags, int nranges)
+{
+	unsigned int i;
+
+	memset(tags, 0, MTE_PAGE_TAG_STORAGE);
+	if (nranges > 1) {
+		nranges--;
+		for (i = 0; i < nranges / 2; i++)
+			tags[i] = 0xab;
+		if (nranges % 2)
+			tags[nranges / 2] = 0xa0;
+	}
+}
+
+/*
+ * Test that mte_tags_to_ranges()/mte_ranges_to_tags() work for various
+ * r_len values.
+ */
+static void test_tag_to_ranges_n(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	unsigned int i, j, sum;
+
+	for (i = 1; i <= MTE_GRANULES_PER_PAGE; i++) {
+		gen_tag_range_helper(td->tags, i);
+		tags_to_ranges_to_tags_helper(test);
+		sum = 0;
+		for (j = 0; j < td->r_len; j++)
+			sum += td->r_sizes[j];
+		KUNIT_EXPECT_EQ(test, sum, MTE_GRANULES_PER_PAGE);
+	}
+}
+
+/*
+ * Check that the tag buffer in test->priv can be compressed and decompressed
+ * without changes.
+ */
+static void *compress_decompress_helper(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	handle = mte_compress(td->tags);
+	KUNIT_EXPECT_EQ(test, (unsigned long)handle & BIT_ULL(63), 0);
+	if (handle) {
+		KUNIT_EXPECT_TRUE(test, mte_decompress(handle, td->dtags));
+		KUNIT_EXPECT_EQ(test, memcmp(td->tags, td->dtags, MTE_PAGE_TAG_STORAGE),
+				0);
+	}
+	return handle;
+}
+
+/* Test that a zero-filled array is compressed into inline storage. */
+static void test_compress_zero(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	memset(td->tags, 0, MTE_PAGE_TAG_STORAGE);
+	handle = compress_decompress_helper(test);
+	/* Tags are stored inline. */
+	KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+}
+
+/* Test that a 0xaa-filled array is compressed into inline storage. */
+static void test_compress_nonzero(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	memset(td->tags, 0xaa, MTE_PAGE_TAG_STORAGE);
+	handle = compress_decompress_helper(test);
+	/* Tags are stored inline. */
+	KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+}
+
+/*
+ * Test that two tag ranges are compressed into inline storage.
+ *
+ * This also covers a special case where both ranges contain
+ * `MTE_GRANULES_PER_PAGE / 2` tags and overflow the designated range size.
+ */
+static void test_two_ranges(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+	unsigned int i;
+	size_t r_len = 2;
+	unsigned char r_tags[2] = { 0xe, 0x0 };
+	unsigned short r_sizes[2];
+
+	for (i = 1; i < MTE_GRANULES_PER_PAGE; i++) {
+		r_sizes[0] = i;
+		r_sizes[1] = MTE_GRANULES_PER_PAGE - i;
+		mte_ranges_to_tags(r_tags, r_sizes, r_len, td->tags);
+		handle = compress_decompress_helper(test);
+		KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+	}
+}
+
+/*
+ * Test that a very small number of tag ranges ends up compressed into 8 bytes.
+ */
+static void test_compress_simple(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	memset(td->tags, 0, MTE_PAGE_TAG_STORAGE);
+	td->tags[0] = 0xa0;
+	td->tags[1] = 0x0a;
+
+	handle = compress_decompress_helper(test);
+	/* Tags are stored inline. */
+	KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+}
+
+/*
+ * Test that a buffer containing @nranges ranges compresses into @exp_size
+ * bytes and decompresses into the original tag sequence.
+ */
+static void compress_range_helper(struct kunit *test, int nranges,
+				  bool exp_inl)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+
+	gen_tag_range_helper(td->tags, nranges);
+	handle = compress_decompress_helper(test);
+	KUNIT_EXPECT_EQ(test, mte_is_compressed(handle), exp_inl);
+}
+
+static inline size_t max_inline_ranges(void)
+{
+#if defined CONFIG_ARM64_4K_PAGES
+	return 6;
+#elif defined(CONFIG_ARM64_16K_PAGES)
+	return 5;
+#else
+	return 4;
+#endif
+}
+
+/*
+ * Test that every number of tag ranges is correctly compressed and
+ * decompressed.
+ */
+static void test_compress_ranges(struct kunit *test)
+{
+	unsigned int i;
+	bool exp_inl;
+
+	for (i = 1; i <= MTE_GRANULES_PER_PAGE; i++) {
+		exp_inl = i <= max_inline_ranges();
+		compress_range_helper(test, i, exp_inl);
+	}
+}
+
+/*
+ * Test that invalid handles are ignored by mte_decompress().
+ */
+static void test_decompress_invalid(struct kunit *test)
+{
+	void *handle1 = (void *)0xeb0b0b0100804020;
+	void *handle2 = (void *)0x6b0b0b010080402f;
+	struct test_data *td = test->priv;
+
+	/* handle1 has bit 0 set to 1. */
+	KUNIT_EXPECT_FALSE(test, mte_decompress(handle1, td->dtags));
+	/*
+	 * handle2 is an inline handle, but its largest_idx (bits 1..3)
+	 * is out of bounds for the inline storage.
+	 */
+	KUNIT_EXPECT_FALSE(test, mte_decompress(handle2, td->dtags));
+}
+
+/*
+ * Test that compressed inline tags cannot be confused with out-of-line
+ * pointers.
+ *
+ * Compressed values are written from bit 0 to bit 63, so the size of the last
+ * tag range initially ends up in the upper bits of the inline representation.
+ * Make sure mte_compress() rearranges the bits so that the resulting handle does
+ * not have 0b0111 as the upper four bits.
+ */
+static void test_upper_bits(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+	void *handle;
+	unsigned char r_tags[6] = { 7, 0, 7, 0, 7, 0 };
+	unsigned short r_sizes[6] = { 1, 1, 1, 1, 1, 1 };
+	size_t r_len;
+
+	/* Maximum number of ranges that can be encoded inline. */
+	r_len = max_inline_ranges();
+	/* Maximum range size possible, will be omitted. */
+	r_sizes[0] = MTE_GRANULES_PER_PAGE / 2 - 1;
+	/* A number close to r_sizes[0] that has most of its bits set. */
+	r_sizes[r_len - 1] = MTE_GRANULES_PER_PAGE - r_sizes[0] - r_len + 2;
+
+	mte_ranges_to_tags(r_tags, r_sizes, r_len, td->tags);
+	handle = compress_decompress_helper(test);
+	KUNIT_EXPECT_TRUE(test, mte_is_compressed(handle));
+}
+
+static void mtecomp_dealloc_testdata(struct test_data *td)
+{
+	kfree(td->tags);
+	kfree(td->dtags);
+	kfree(td->r_sizes);
+	kfree(td->r_tags);
+}
+
+static int mtecomp_test_init(struct kunit *test)
+{
+	struct test_data *td;
+
+	td = kmalloc(sizeof(struct test_data), GFP_KERNEL);
+	if (!td)
+		return 1;
+	td->tags = kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
+	if (!td->tags)
+		goto error;
+	td->dtags = kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
+	if (!td->dtags)
+		goto error;
+	td->r_len = MTE_GRANULES_PER_PAGE;
+	td->r_sizes = kmalloc_array(MTE_GRANULES_PER_PAGE,
+				    sizeof(unsigned short), GFP_KERNEL);
+	if (!td->r_sizes)
+		goto error;
+	td->r_tags = kmalloc(MTE_GRANULES_PER_PAGE, GFP_KERNEL);
+	if (!td->r_tags)
+		goto error;
+	test->priv = (void *)td;
+	return 0;
+error:
+	mtecomp_dealloc_testdata(td);
+	return 1;
+}
+
+static void mtecomp_test_exit(struct kunit *test)
+{
+	struct test_data *td = test->priv;
+
+	mtecomp_dealloc_testdata(td);
+}
+
+static struct kunit_case mtecomp_test_cases[] = {
+	KUNIT_CASE(test_tags_to_ranges_zero),
+	KUNIT_CASE(test_tags_to_ranges_simple),
+	KUNIT_CASE(test_tags_to_ranges_repeated),
+	KUNIT_CASE(test_tag_to_ranges_n),
+	KUNIT_CASE(test_compress_zero),
+	KUNIT_CASE(test_compress_nonzero),
+	KUNIT_CASE(test_two_ranges),
+	KUNIT_CASE(test_compress_simple),
+	KUNIT_CASE(test_compress_ranges),
+	KUNIT_CASE(test_decompress_invalid),
+	KUNIT_CASE(test_upper_bits),
+	{}
+};
+
+static struct kunit_suite mtecomp_test_suite = {
+	.name = "mtecomp",
+	.init = mtecomp_test_init,
+	.exit = mtecomp_test_exit,
+	.test_cases = mtecomp_test_cases,
+};
+kunit_test_suites(&mtecomp_test_suite);
+
+MODULE_IMPORT_NS(MTECOMP);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alexander Potapenko <glider at google.com>");
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Mon Dec 18 04:40:32 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 13:40:32 +0100
Subject: [PATCH v11-mte 6/7] arm64: mte: add compression support to mteswap.c
In-Reply-To: <20231218124033.551770-1-glider@google.com>
References: <20231218124033.551770-1-glider@google.com>
Message-ID: <20231218124033.551770-7-glider@google.com>

Update mteswap.c to perform inline compression of memory tags when
possible.

If CONFIG_ARM64_MTE_COMP is enabled, mteswap.c will attempt to compress
saved tags for a struct page and store them directly in Xarray entry
instead of wasting heap space.

Soon after booting Android, tag compression saves ~2x memory previously
spent by mteswap.c on tag allocations. On a moderately loaded device with
~20% tagged pages, this leads to saving several megabytes of kernel heap:

  # cat /sys/kernel/debug/mteswap/stats
  8 bytes:	102496 allocations,	67302 deallocations
  128 bytes:	212234 allocations,	178278 deallocations
  uncompressed tag storage size:	8851200
  compressed tag storage size:	4346368

(statistics collection is introduced in the following patch)

Signed-off-by: Alexander Potapenko <glider at google.com>
Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>

---
 v10-mte:
  - added Catalin's Reviewed-by:

 v9:
  - as requested by Yury Norov, split off statistics collection into a
    separate patch
  - minor fixes

 v8:
  - adapt to the new compression API, abandon mteswap_{no,}comp.c
  - move stats collection to mteswap.c

 v5:
  - drop a dead variable from _mte_free_saved_tags() in mteswap_comp.c
  - ensure MTE compression works with arbitrary page sizes
  - update patch description

 v4:
  - minor code simplifications suggested by Andy Shevchenko, added
    missing header dependencies
  - changed compression API names to reflect modifications made to
    memcomp.h (as suggested by Yury Norov)

 v3:
  - Addressed comments by Andy Shevchenko in another patch:
   - fixed includes order
   - replaced u64 with unsigned long
   - added MODULE_IMPORT_NS(MTECOMP)
---
 arch/arm64/mm/mteswap.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
index a31833e3ddc54..70f5c8ecd640d 100644
--- a/arch/arm64/mm/mteswap.c
+++ b/arch/arm64/mm/mteswap.c
@@ -6,6 +6,8 @@
 #include <linux/swap.h>
 #include <linux/swapops.h>
 #include <asm/mte.h>
+#include <asm/mtecomp.h>
+#include "mtecomp.h"
 
 static DEFINE_XARRAY(mte_pages);
 
@@ -17,12 +19,13 @@ void *mte_allocate_tag_storage(void)
 
 void mte_free_tag_storage(char *storage)
 {
-	kfree(storage);
+	if (!mte_is_compressed(storage))
+		kfree(storage);
 }
 
 int mte_save_tags(struct page *page)
 {
-	void *tag_storage, *ret;
+	void *tag_storage, *compressed_storage, *ret;
 
 	if (!page_mte_tagged(page))
 		return 0;
@@ -32,6 +35,11 @@ int mte_save_tags(struct page *page)
 		return -ENOMEM;
 
 	mte_save_page_tags(page_address(page), tag_storage);
+	compressed_storage = mte_compress(tag_storage);
+	if (compressed_storage) {
+		mte_free_tag_storage(tag_storage);
+		tag_storage = compressed_storage;
+	}
 
 	/* lookup the swap entry.val from the page */
 	ret = xa_store(&mte_pages, page_swap_entry(page).val, tag_storage,
@@ -50,13 +58,20 @@ int mte_save_tags(struct page *page)
 void mte_restore_tags(swp_entry_t entry, struct page *page)
 {
 	void *tags = xa_load(&mte_pages, entry.val);
+	void *tag_storage = NULL;
 
 	if (!tags)
 		return;
 
 	if (try_page_mte_tagging(page)) {
+		if (mte_is_compressed(tags)) {
+			tag_storage = mte_allocate_tag_storage();
+			mte_decompress(tags, tag_storage);
+			tags = tag_storage;
+		}
 		mte_restore_page_tags(page_address(page), tags);
 		set_page_mte_tagged(page);
+		mte_free_tag_storage(tag_storage);
 	}
 }
 
-- 
2.43.0.472.g3155946c3a-goog



From glider at google.com  Mon Dec 18 04:40:33 2023
From: glider at google.com (Alexander Potapenko)
Date: Mon, 18 Dec 2023 13:40:33 +0100
Subject: [PATCH v11-mte 7/7] arm64: mte: implement CONFIG_ARM64_MTE_SWAP_STATS
In-Reply-To: <20231218124033.551770-1-glider@google.com>
References: <20231218124033.551770-1-glider@google.com>
Message-ID: <20231218124033.551770-8-glider@google.com>

Provide a config to collect the usage statistics for ARM MTE tag
compression. This patch introduces allocation/deallocation counters
for buffers that were stored uncompressed (and thus occupy 128 bytes of
heap plus the Xarray overhead to store a pointer) and those that were
compressed into 8-byte pointers (effectively using 0 bytes of heap in
addition to the Xarray overhead).

The counters are exposed to the userspace via
/sys/kernel/debug/mteswap/stats:

  # cat /sys/kernel/debug/mteswap/stats
  8 bytes:      102496 allocations,     67302 deallocations
  128 bytes:    212234 allocations,     178278 deallocations
  uncompressed tag storage size:        8851200
  compressed tag storage size:  4346368

Suggested-by: Yury Norov <yury.norov at gmail.com>
Signed-off-by: Alexander Potapenko <glider at google.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Reviewed-by: Yury Norov <yury.norov at gmail.com>

---

This patch was split off from the "arm64: mte: add compression support
to mteswap.c" patch
(https://lore.kernel.org/linux-arm-kernel/ZUVulBKVYK7cq2rJ at yury-ThinkPad/T/#m819ec30beb9de53d5c442f7e3247456f8966d88a)

v11-mte:
 - add Yury's Reviewed-by:

v10-mte:
 - added Catalin's Acked-by:

v9:
 - add this patch, put the stats behind a separate config,
   mention /sys/kernel/debug/mteswap/stats in the documentation
---
 .../arch/arm64/mte-tag-compression.rst        | 12 +++
 arch/arm64/Kconfig                            | 15 +++
 arch/arm64/mm/mteswap.c                       | 93 ++++++++++++++++++-
 3 files changed, 118 insertions(+), 2 deletions(-)

diff --git a/Documentation/arch/arm64/mte-tag-compression.rst b/Documentation/arch/arm64/mte-tag-compression.rst
index 8fe6b51a9db6d..4c25b96f7d4b5 100644
--- a/Documentation/arch/arm64/mte-tag-compression.rst
+++ b/Documentation/arch/arm64/mte-tag-compression.rst
@@ -145,6 +145,18 @@ Tag compression and decompression implicitly rely on the fixed MTE tag size
 (4 bits) and number of tags per page. Should these values change, the algorithm
 may need to be revised.
 
+Stats
+=====
+
+When `CONFIG_ARM64_MTE_SWAP_STATS` is enabled, `arch/arm64/mm/mteswap.c` exports
+usage statistics for tag compression used when swapping tagged pages. The data
+can be accessed via debugfs::
+
+  # cat /sys/kernel/debug/mteswap/stats
+  8 bytes:        10438 allocations,      10417 deallocations
+  128 bytes:      26180 allocations,      26179 deallocations
+  uncompressed tag storage size:  2816
+  compressed tag storage size:    128
 
 Programming Interface
 =====================
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6a1397a96f2f0..49a786c7edadd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2100,6 +2100,21 @@ config ARM64_MTE_COMP_KUNIT_TEST
 	  be compressed into pointer-size values and correctly decompressed
 	  afterwards.
 
+config ARM64_MTE_SWAP_STATS
+	bool "Collect usage statistics of tag compression for swapped MTE tags"
+	default y
+	depends on ARM64_MTE && ARM64_MTE_COMP
+	help
+	  Collect usage statistics for ARM64 MTE tag compression during swapping.
+
+	  Adds allocation/deallocation counters for buffers that were stored
+	  uncompressed (and thus occupy 128 bytes of heap plus the Xarray
+	  overhead to store a pointer) and those that were compressed into
+	  8-byte pointers (effectively using 0 bytes of heap in addition to
+	  the Xarray overhead).
+	  The counters are exposed to the userspace via
+	  /sys/kernel/debug/mteswap/stats.
+
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
index 70f5c8ecd640d..1c6c78b9a9037 100644
--- a/arch/arm64/mm/mteswap.c
+++ b/arch/arm64/mm/mteswap.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 
+#include <linux/debugfs.h>
 #include <linux/pagemap.h>
 #include <linux/xarray.h>
 #include <linux/slab.h>
@@ -11,16 +12,54 @@
 
 static DEFINE_XARRAY(mte_pages);
 
+enum mteswap_counters {
+	MTESWAP_CTR_INLINE = 0,
+	MTESWAP_CTR_OUTLINE,
+	MTESWAP_CTR_SIZE
+};
+
+#if defined(CONFIG_ARM64_MTE_SWAP_STATS)
+static atomic_long_t alloc_counters[MTESWAP_CTR_SIZE];
+static atomic_long_t dealloc_counters[MTESWAP_CTR_SIZE];
+
+static void inc_alloc_counter(int kind)
+{
+	atomic_long_inc(&alloc_counters[kind]);
+}
+
+static void inc_dealloc_counter(int kind)
+{
+	atomic_long_inc(&dealloc_counters[kind]);
+}
+#else
+static void inc_alloc_counter(int kind)
+{
+}
+
+static void inc_dealloc_counter(int kind)
+{
+}
+#endif
+
 void *mte_allocate_tag_storage(void)
 {
+	void *ret;
+
 	/* tags granule is 16 bytes, 2 tags stored per byte */
-	return kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
+	ret = kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
+	if (ret)
+		inc_alloc_counter(MTESWAP_CTR_OUTLINE);
+	return ret;
 }
 
 void mte_free_tag_storage(char *storage)
 {
-	if (!mte_is_compressed(storage))
+	if (!mte_is_compressed(storage)) {
 		kfree(storage);
+		inc_dealloc_counter(MTESWAP_CTR_OUTLINE);
+	} else {
+		inc_dealloc_counter(MTESWAP_CTR_INLINE);
+	}
 }
 
 int mte_save_tags(struct page *page)
@@ -39,6 +78,7 @@ int mte_save_tags(struct page *page)
 	if (compressed_storage) {
 		mte_free_tag_storage(tag_storage);
 		tag_storage = compressed_storage;
+		inc_alloc_counter(MTESWAP_CTR_INLINE);
 	}
 
 	/* lookup the swap entry.val from the page */
@@ -98,3 +138,52 @@ void mte_invalidate_tags_area(int type)
 	}
 	xa_unlock(&mte_pages);
 }
+
+#if defined(CONFIG_ARM64_MTE_SWAP_STATS)
+/* DebugFS interface. */
+static int stats_show(struct seq_file *seq, void *v)
+{
+	unsigned long total_mem_alloc = 0, total_mem_dealloc = 0;
+	unsigned long total_num_alloc = 0, total_num_dealloc = 0;
+	unsigned long sizes[2] = { 8, MTE_PAGE_TAG_STORAGE };
+	long alloc, dealloc;
+	unsigned long size;
+	int i;
+
+	for (i = 0; i < MTESWAP_CTR_SIZE; i++) {
+		alloc = atomic_long_read(&alloc_counters[i]);
+		dealloc = atomic_long_read(&dealloc_counters[i]);
+		total_num_alloc += alloc;
+		total_num_dealloc += dealloc;
+		size = sizes[i];
+		/*
+		 * Do not count 8-byte buffers towards compressed tag storage
+		 * size.
+		 */
+		if (i) {
+			total_mem_alloc += (size * alloc);
+			total_mem_dealloc += (size * dealloc);
+		}
+		seq_printf(seq,
+			   "%lu bytes:\t%lu allocations,\t%lu deallocations\n",
+			   size, alloc, dealloc);
+	}
+	seq_printf(seq, "uncompressed tag storage size:\t%lu\n",
+		   (total_num_alloc - total_num_dealloc) *
+			   MTE_PAGE_TAG_STORAGE);
+	seq_printf(seq, "compressed tag storage size:\t%lu\n",
+		   total_mem_alloc - total_mem_dealloc);
+	return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(stats);
+
+static int mteswap_init(void)
+{
+	struct dentry *mteswap_dir;
+
+	mteswap_dir = debugfs_create_dir("mteswap", NULL);
+	debugfs_create_file("stats", 0444, mteswap_dir, NULL, &stats_fops);
+	return 0;
+}
+module_init(mteswap_init);
+#endif
-- 
2.43.0.472.g3155946c3a-goog



From mshavit at google.com  Mon Dec 18 04:42:35 2023
From: mshavit at google.com (Michael Shavit)
Date: Mon, 18 Dec 2023 20:42:35 +0800
Subject: [PATCH 04/19] iommu/arm-smmu-v3: Make STE programming independent
 of the callers
In-Reply-To: <CAKHBV26CRC8eWMuOk6EZYMHOZoR2FauP=NBazzOiWCmQYEa1vg@mail.gmail.com>
References: <0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com> <CAKHBV24UGZuG6+J4cybadJCTyf9hN+e_VgAC0NVOPotmEur7SQ@mail.gmail.com>
 <20231012121616.GF3952@nvidia.com> <CAKHBV27G1PLZ5gkYkOOCZdD9waZOZypkWqk4_HSR4XXGFT-+LA@mail.gmail.com>
 <20231018130455.GU3952@nvidia.com> <CAKHBV270uJjdj4zeK-NNt+j3TiqoGDdLUQ5uRrLw9PN0ysCDbw@mail.gmail.com>
 <20231020113918.GD3952@nvidia.com> <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
 <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com>
 <ZX7xu8jN/rBZ4A/d@nvidia.com> <CAKHBV26CRC8eWMuOk6EZYMHOZoR2FauP=NBazzOiWCmQYEa1vg@mail.gmail.com>
Message-ID: <CAKHBV25b-=ctUz8uSuzMYDXTrn2fDm-FUQUFaFfw-OjgQ6kn9g@mail.gmail.com>

On Mon, Dec 18, 2023 at 8:35?PM Michael Shavit <mshavit at google.com> wrote:
> The following should address the bug and optimization you pointed out
> with minimal adjustments:
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 98aa8cc17b58b..1c35599d944d7 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -971,100 +971,6 @@ void arm_smmu_tlb_inv_asid(struct
> arm_smmu_device *smmu, u16 asid)
>         arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
>  }
>
> -/*
> - * This algorithm updates any STE/CD to any value without creating a situation
> - * where the HW can percieve a corrupted entry. HW is only required
> to have a 64
> - * bit atomicity with stores from the CPU, while entries are many 64 bit values
> - * big.
> - *
> - * The algorithm works by evolving the entry toward the target in a series of
> - * steps. Each step synchronizes with the HW so that the HW can not
> see an entry
> - * torn across two steps. Upon each call cur/cur_used reflect the current
> - * synchronized value seen by the HW.
> - *
> - * During each step the HW can observe a torn entry that has any combination of
> - * the step's old/new 64 bit words. The algorithm objective is for the HW
> - * behavior to always be one of current behavior, V=0, or new behavior, during
> - * each step, and across all steps.
> - *
> - * At each step one of three actions is chosen to evolve cur to target:
> - *  - Update all unused bits with their target values.
> - *    This relies on the IGNORED behavior described in the specification
> - *  - Update a single 64-bit value
> - *  - Update all unused bits and set V=0
> - *
> - * The last two actions will cause cur_used to change, which will
> then allow the
> - * first action on the next step.
> - *
> - * In the most general case we can make any update in three steps:
> - *  - Disrupting the entry (V=0)
> - *  - Fill now unused bits, all bits except V
> - *  - Make valid (V=1), single 64 bit store
> - *
> - * However this disrupts the HW while it is happening. There are several
> - * interesting cases where a STE/CD can be updated without disturbing the HW
> - * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
> - * because the used bits don't intersect. We can detect this by calculating how
> - * many 64 bit values need update after adjusting the unused bits and skip the
> - * V=0 process.
> - */
> -static bool arm_smmu_write_entry_next(__le64 *cur, const __le64 *cur_used,
> -                                     const __le64 *target,
> -                                     const __le64 *target_used, __le64 *step,
> -                                     __le64 v_bit, unsigned int len)
> -{
> -       u8 step_used_diff = 0;
> -       u8 step_change = 0;
> -       unsigned int i;
> -
> -       /*
> -        * Compute a step that has all the bits currently unused by HW set to
> -        * their target values.
> -        */
> -       for (i = 0; i != len; i++) {
> -               step[i] = (cur[i] & cur_used[i]) | (target[i] & ~cur_used[i]);
> -               if (cur[i] != step[i])
> -                       step_change |= 1 << i;
> -               /*
> -                * Each bit indicates if the step is incorrect compared to the
> -                * target, considering only the used bits in the target
> -                */
> -               if ((step[i] & target_used[i]) != (target[i] & target_used[i]))
> -                       step_used_diff |= 1 << i;
> -       }
> -
> -       if (hweight8(step_used_diff) > 1) {
> -               /*
> -                * More than 1 qword is mismatched, this cannot be done without
> -                * a break. Clear the V bit and go again.
> -                */
> -               step[0] &= ~v_bit;
> -       } else if (!step_change && step_used_diff) {
> -               /*
> -                * Have exactly one critical qword, all the other qwords are set
> -                * correctly, so we can set this qword now.
> -                */
> -               i = ffs(step_used_diff) - 1;
> -               step[i] = target[i];
> -       } else if (!step_change) {
> -               /* cur == target, so all done */
> -               if (memcmp(cur, target, len * sizeof(*cur)) == 0)
> -                       return true;
> -
> -               /*
> -                * All the used HW bits match, but unused bits are different.
> -                * Set them as well. Technically this isn't necessary but it
> -                * brings the entry to the full target state, so if there are
> -                * bugs in the mask calculation this will obscure them.
> -                */
> -               memcpy(step, target, len * sizeof(*step));
> -       }
> -
> -       for (i = 0; i != len; i++)
> -               WRITE_ONCE(cur[i], step[i]);
> -       return false;
> -}
> -
>  static void arm_smmu_sync_cd(struct arm_smmu_master *master,
>                              int ssid, bool leaf)
>  {
> @@ -1398,39 +1304,135 @@ static void arm_smmu_get_ste_used(const
> struct arm_smmu_ste *ent,
>         }
>  }
>
> -static bool arm_smmu_write_ste_next(struct arm_smmu_ste *cur,
> -                                   const struct arm_smmu_ste *target,
> -                                   const struct arm_smmu_ste *target_used)
> +/*
> + * Make bits of the current ste that aren't in use by the hardware equal to the
> + * target's bits.
> + */
> +static void arm_smmu_ste_set_unused_bits(
> +                                  struct arm_smmu_ste *cur,
> +                                  const struct arm_smmu_ste *target)
>  {
>         struct arm_smmu_ste cur_used;
> -       struct arm_smmu_ste step;
> +       int i =0;
>
>         arm_smmu_get_ste_used(cur, &cur_used);
> -       return arm_smmu_write_entry_next(cur->data, cur_used.data, target->data,
> -                                        target_used->data, step.data,
> -                                        cpu_to_le64(STRTAB_STE_0_V),
> -                                        ARRAY_SIZE(cur->data));
> +       for (i = 0; i < ARRAY_SIZE(cur->data); i++)
> +               cur->data[i] = (cur->data[i] & cur_used.data[i]) |
> +                              (target->data[i] & ~cur_used.data[i]);
>  }
>
> +/*
> + * Update the STE to the target configuration. The transition from the current
> + * STE to the target STE takes place over multiple steps that attempts to make
> + * the transition hitless if possible. This function takes care not to create a
> + * situation where the HW can perceive a corrupted entry. HW is only
> required to
> + * have a 64 bit atomicity with stores from the CPU, while entries are many 64
> + * bit values big.
> + *
> + * The algorithm works by evolving the entry toward the target in a series of
> + * steps. Each step synchronizes with the HW so that the HW can not
> see an entry
> + * torn across two steps. During each step the HW can observe a torn entry that
> + * has any combination of the step's old/new 64 bit words. The algorithm
> + * objective is for the HW behavior to always be one of current behavior, V=0,
> + * or new behavior.
> + *
> + * In the most general case we can make any update in three steps:
> + *  - Disrupting the entry (V=0)
> + *  - Fill now unused bits, all bits except V
> + *  - Make valid (V=1), single 64 bit store
> + *
> + * However this disrupts the HW while it is happening. There are several
> + * interesting cases where a STE/CD can be updated without disturbing the HW
> + * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
> + * because the used bits don't intersect. We can detect this by calculating how
> + * many 64 bit values need update after adjusting the unused bits and skip the
> + * V=0 process. This relies on the IGNORED behavior described in the
> + * specification
> + */
>  static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
>                                struct arm_smmu_ste *ste,
>                                const struct arm_smmu_ste *target)
>  {
> +       struct arm_smmu_ste staging_ste;
>         struct arm_smmu_ste target_used;
> -       int i;
> +       int writes_required = 0;
> +       u8 staging_used_diff = 0;
> +       int i = 0;
>
> +       /*
> +        * Compute a staging ste that has all the bits currently unused by HW
> +        * set to their target values, such that comitting it to the ste table
> +        * woudn't disrupt the hardware.
> +        */
> +       memcpy(&staging_ste, ste, sizeof(staging_ste));
> +       arm_smmu_ste_set_unused_bits(&staging_ste, target);
> +
> +       /*
> +        * Determine if it's possible to reach the target configuration from the
> +        * staged configured in a single qword write (ignoring bits that are
> +        * unused under the target configuration).
> +        */
>         arm_smmu_get_ste_used(target, &target_used);
> -       /* Masks in arm_smmu_get_ste_used() are up to date */
> -       for (i = 0; i != ARRAY_SIZE(target->data); i++)
> -               WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);
> +       /*
> +        * But first sanity check that masks in arm_smmu_get_ste_used() are up
> +        * to date.
> +        */
> +       for (i = 0; i != ARRAY_SIZE(target->data); i++) {
> +               if (WARN_ON_ONCE(target->data[i] & ~target_used.data[i]))
> +                       target_used.data[i] |= target->data[i];
> +       }
>
> -       for (i = 0; true; i++) {
> -               if (arm_smmu_write_ste_next(ste, target, &target_used))
> -                       break;
> -               arm_smmu_sync_ste_for_sid(smmu, sid);
> -               if (WARN_ON(i == 4))
> -                       break;
> +       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++) {
> +               /*
> +                * Each bit of staging_used_diff indicates the index of a qword
> +                * within the staged ste that is incorrect compared to the
> +                * target, considering only the used bits in the target
> +                */
> +               if ((staging_ste.data[i] &
> +                   target_used.data[i]) != (target->data[i]))
> +                       staging_used_diff |= 1 << i;
> +       }
> +       if (hweight8(staging_used_diff) > 1) {
> +               /*
> +                * More than 1 qword is mismatched and a hitless transition from
> +                * the current ste to the target ste is not possible. Clear the
> +                * V bit and recompute the staging STE.
> +                * Because the V bit is cleared, the staging STE will be equal
> +                * to the target STE except for the first qword.
> +                */
> +               staging_ste.data[0] &= ~cpu_to_le64(STRTAB_STE_0_V);
> +               arm_smmu_ste_set_unused_bits(&staging_ste, target);
> +               staging_used_diff = 1;
> +       }
> +
> +       /*
> +        * Commit the staging STE.
> +        */
> +       for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++)
> +               WRITE_ONCE(ste->data[i], staging_ste.data[i]);
> +       arm_smmu_sync_ste_for_sid(smmu, sid);
> +
> +       /*
> +        * It's now possible to switch to the target configuration with a write
> +        * to a single qword. Make that switch now.
> +        */
> +       i = ffs(staging_used_diff) - 1;
> +       WRITE_ONCE(ste->data[i], target->data[i]);
> +       arm_smmu_sync_ste_for_sid(smmu, sid);
> +
> +       /*
> +        * Some of the bits set under the previous configuration but unused
> +        * under the target configuration might still bit set. Clear them as
> +        * well. Technically this isn't necessary but it brings the entry to
> +        * the full target state, so if there are bugs in the mask calculation
> +        * this will obscure them.
> +        */
> +       for (i = 0; i != ARRAY_SIZE(ste->data); i++) {
> +               if (ste->data[i] != target->data[i]) {
> +                       WRITE_ONCE(ste->data[i], target->data[i]);
> +               }
>         }
> +       arm_smmu_sync_ste_for_sid(smmu, sid);
>
>         /* It's likely that we'll want to use the new STE soon */
>         if (!(smmu->options & ARM_SMMU_OPT_SKIP_PREFETCH)) {

Sorry, that was the old patch. Here's the new one:

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 98aa8cc17b58b..de2e7d9e5919c 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -971,100 +971,6 @@ void arm_smmu_tlb_inv_asid(struct
arm_smmu_device *smmu, u16 asid)
 	arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
 }

-/*
- * This algorithm updates any STE/CD to any value without creating a situation
- * where the HW can percieve a corrupted entry. HW is only required
to have a 64
- * bit atomicity with stores from the CPU, while entries are many 64 bit values
- * big.
- *
- * The algorithm works by evolving the entry toward the target in a series of
- * steps. Each step synchronizes with the HW so that the HW can not
see an entry
- * torn across two steps. Upon each call cur/cur_used reflect the current
- * synchronized value seen by the HW.
- *
- * During each step the HW can observe a torn entry that has any combination of
- * the step's old/new 64 bit words. The algorithm objective is for the HW
- * behavior to always be one of current behavior, V=0, or new behavior, during
- * each step, and across all steps.
- *
- * At each step one of three actions is chosen to evolve cur to target:
- *  - Update all unused bits with their target values.
- *    This relies on the IGNORED behavior described in the specification
- *  - Update a single 64-bit value
- *  - Update all unused bits and set V=0
- *
- * The last two actions will cause cur_used to change, which will
then allow the
- * first action on the next step.
- *
- * In the most general case we can make any update in three steps:
- *  - Disrupting the entry (V=0)
- *  - Fill now unused bits, all bits except V
- *  - Make valid (V=1), single 64 bit store
- *
- * However this disrupts the HW while it is happening. There are several
- * interesting cases where a STE/CD can be updated without disturbing the HW
- * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
- * because the used bits don't intersect. We can detect this by calculating how
- * many 64 bit values need update after adjusting the unused bits and skip the
- * V=0 process.
- */
-static bool arm_smmu_write_entry_next(__le64 *cur, const __le64 *cur_used,
-				      const __le64 *target,
-				      const __le64 *target_used, __le64 *step,
-				      __le64 v_bit, unsigned int len)
-{
-	u8 step_used_diff = 0;
-	u8 step_change = 0;
-	unsigned int i;
-
-	/*
-	 * Compute a step that has all the bits currently unused by HW set to
-	 * their target values.
-	 */
-	for (i = 0; i != len; i++) {
-		step[i] = (cur[i] & cur_used[i]) | (target[i] & ~cur_used[i]);
-		if (cur[i] != step[i])
-			step_change |= 1 << i;
-		/*
-		 * Each bit indicates if the step is incorrect compared to the
-		 * target, considering only the used bits in the target
-		 */
-		if ((step[i] & target_used[i]) != (target[i] & target_used[i]))
-			step_used_diff |= 1 << i;
-	}
-
-	if (hweight8(step_used_diff) > 1) {
-		/*
-		 * More than 1 qword is mismatched, this cannot be done without
-		 * a break. Clear the V bit and go again.
-		 */
-		step[0] &= ~v_bit;
-	} else if (!step_change && step_used_diff) {
-		/*
-		 * Have exactly one critical qword, all the other qwords are set
-		 * correctly, so we can set this qword now.
-		 */
-		i = ffs(step_used_diff) - 1;
-		step[i] = target[i];
-	} else if (!step_change) {
-		/* cur == target, so all done */
-		if (memcmp(cur, target, len * sizeof(*cur)) == 0)
-			return true;
-
-		/*
-		 * All the used HW bits match, but unused bits are different.
-		 * Set them as well. Technically this isn't necessary but it
-		 * brings the entry to the full target state, so if there are
-		 * bugs in the mask calculation this will obscure them.
-		 */
-		memcpy(step, target, len * sizeof(*step));
-	}
-
-	for (i = 0; i != len; i++)
-		WRITE_ONCE(cur[i], step[i]);
-	return false;
-}
-
 static void arm_smmu_sync_cd(struct arm_smmu_master *master,
 			     int ssid, bool leaf)
 {
@@ -1398,40 +1304,160 @@ static void arm_smmu_get_ste_used(const
struct arm_smmu_ste *ent,
 	}
 }

-static bool arm_smmu_write_ste_next(struct arm_smmu_ste *cur,
-				    const struct arm_smmu_ste *target,
-				    const struct arm_smmu_ste *target_used)
+/*
+ * Make bits of the current ste that aren't in use by the hardware equal to the
+ * target's bits.
+ */
+static void arm_smmu_ste_set_unused_bits(
+			           struct arm_smmu_ste *cur,
+			           const struct arm_smmu_ste *target)
 {
 	struct arm_smmu_ste cur_used;
-	struct arm_smmu_ste step;
+	int i =0;

 	arm_smmu_get_ste_used(cur, &cur_used);
-	return arm_smmu_write_entry_next(cur->data, cur_used.data, target->data,
-					 target_used->data, step.data,
-					 cpu_to_le64(STRTAB_STE_0_V),
-					 ARRAY_SIZE(cur->data));
+	for (i = 0; i < ARRAY_SIZE(cur->data); i++)
+		cur->data[i] = (cur->data[i] & cur_used.data[i]) |
+			       (target->data[i] & ~cur_used.data[i]);
 }

+/*
+ * Each bit of the return value indicates the index of a qword within the ste
+ * that is incorrect compared to the target, considering only the used bits in
+ * the target
+ */
+static u8 arm_smmu_ste_used_qword_diff_indexes(const struct arm_smmu_ste *ste,
+					       const struct arm_smmu_ste *target)
+{
+	struct arm_smmu_ste target_used;
+	u8 qword_diff_indexes = 0;
+	int i = 0;
+
+	arm_smmu_get_ste_used(target, &target_used);
+	for (i = 0; i < ARRAY_SIZE(ste->data); i++) {
+		if ((ste->data[i] & target_used.data[i]) !=
+		    (target->data[i] & target_used.data[i]))
+			qword_diff_indexes |= 1 << i;
+	}
+	return qword_diff_indexes;
+}
+
+/*
+ * Update the STE to the target configuration. The transition from the current
+ * STE to the target STE takes place over multiple steps that attempts to make
+ * the transition hitless if possible. This function takes care not to create a
+ * situation where the HW can perceive a corrupted entry. HW is only
required to
+ * have a 64 bit atomicity with stores from the CPU, while entries are many 64
+ * bit values big.
+ *
+ * The algorithm works by evolving the entry toward the target in a series of
+ * steps. Each step synchronizes with the HW so that the HW can not
see an entry
+ * torn across two steps. During each step the HW can observe a torn entry that
+ * has any combination of the step's old/new 64 bit words. The algorithm
+ * objective is for the HW behavior to always be one of current behavior, V=0,
+ * or new behavior.
+ *
+ * In the most general case we can make any update in three steps:
+ *  - Disrupting the entry (V=0)
+ *  - Fill now unused bits, all bits except V
+ *  - Make valid (V=1), single 64 bit store
+ *
+ * However this disrupts the HW while it is happening. There are several
+ * interesting cases where a STE/CD can be updated without disturbing the HW
+ * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
+ * because the used bits don't intersect. We can detect this by calculating how
+ * many 64 bit values need update after adjusting the unused bits and skip the
+ * V=0 process. This relies on the IGNORED behavior described in the
+ * specification
+ */
 static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
 			       struct arm_smmu_ste *ste,
 			       const struct arm_smmu_ste *target)
 {
-	struct arm_smmu_ste target_used;
-	int i;
+	bool cleanup_sync_required = false;
+	struct arm_smmu_ste staging_ste;
+	u8 ste_qwords_used_diff = 0;
+	int i = 0;

-	arm_smmu_get_ste_used(target, &target_used);
-	/* Masks in arm_smmu_get_ste_used() are up to date */
-	for (i = 0; i != ARRAY_SIZE(target->data); i++)
-		WARN_ON_ONCE(target->data[i] & ~target_used.data[i]);
+	ste_qwords_used_diff = arm_smmu_ste_used_qword_diff_indexes(ste, target);
+	if (WARN_ON_ONCE(ste_qwords_used_diff == 0))
+		return;

-	for (i = 0; true; i++) {
-		if (arm_smmu_write_ste_next(ste, target, &target_used))
-			break;
+	if (hweight8(ste_qwords_used_diff) > 1) {
+		/*
+		 * If transitioning to the target STE with a single qword write
+		 * isn't possible, then we must first transition to an
+		 * intermediate STE. The intermediate STE may either be an STE
+		 * that melds bits of the target STE into the current STE
+		 * without affecting bits used by the hardware under the current
+		 * configuration; or a breaking STE if a hitless transition to
+		 * the target isn't possible.
+		 */
+
+		/*
+		 * Compute a staging ste that has all the bits currently unused
+		 * by HW set to their target values, such that comitting it to
+		 * the ste table woudn't disrupt the hardware.
+		 */
+		memcpy(&staging_ste, ste, sizeof(staging_ste));
+		arm_smmu_ste_set_unused_bits(&staging_ste, target);
+
+		ste_qwords_used_diff = arm_smmu_ste_used_qword_diff_indexes(ste,
+									    target);
+		if (hweight8(ste_qwords_used_diff) > 1) {
+			/*
+			 * More than 1 qword is mismatched between the staging
+			 * and target STE. A hitless transition to the target
+			 * ste is not possible. Set the staging STE to be equal
+			 * to the target STE, apart from the V bit's qword. As
+			 * long as the V bit is cleared first then writes to the
+			 * subsequent qwords will not further disrupt the
+			 * hardware.
+			 */
+			memcpy(&staging_ste, ste, sizeof(staging_ste));
+			staging_ste.data[0] &= ~cpu_to_le64(STRTAB_STE_0_V);
+			arm_smmu_ste_set_unused_bits(&staging_ste, target);
+			/*
+			 * After comitting the staging STE, only the 0th qword
+			 * will differ from the target.
+			 */
+			ste_qwords_used_diff = 1;
+		}
+
+		/*
+		 * Commit the staging STE. Note that the iteration order
+		 * matters, as we may be comitting a breaking STE in the
+		 * non-hitless case.
+		 */
+		for (i = 0; i != ARRAY_SIZE(staging_ste.data); i++)
+			WRITE_ONCE(ste->data[i], staging_ste.data[i]);
 		arm_smmu_sync_ste_for_sid(smmu, sid);
-		if (WARN_ON(i == 4))
-			break;
 	}

+	/*
+	 * It's now possible to switch to the target configuration with a write
+	 * to a single qword. Make that switch now.
+	 */
+	i = ffs(ste_qwords_used_diff) - 1;
+	WRITE_ONCE(ste->data[i], target->data[i]);
+	arm_smmu_sync_ste_for_sid(smmu, sid);
+
+	/*
+	 * Some of the bits set under the previous configuration but unused
+	 * under the target configuration might still bit set. Clear them as
+	 * well. Technically this isn't necessary but it brings the entry to
+	 * the full target state, so if there are bugs in the mask calculation
+	 * this will obscure them.
+	 */
+	for (i = 0; i != ARRAY_SIZE(ste->data); i++) {
+		if (ste->data[i] != target->data[i]) {
+			WRITE_ONCE(ste->data[i], target->data[i]);
+			cleanup_sync_required = true;
+		}
+	}
+	if (cleanup_sync_required)
+		arm_smmu_sync_ste_for_sid(smmu, sid);
+
 	/* It's likely that we'll want to use the new STE soon */
 	if (!(smmu->options & ARM_SMMU_OPT_SKIP_PREFETCH)) {
 		struct arm_smmu_cmdq_ent


From sashal at kernel.org  Mon Dec 18 04:43:35 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:43:35 -0500
Subject: [PATCH AUTOSEL 6.6 01/18] clk: rockchip: rk3568: Add PLL rate for 292.5MHz
Message-ID: <20231218124415.1379060-1-sashal@kernel.org>

From: Chris Morgan <macromorgan at hotmail.com>

[ Upstream commit 1af27671f62ce919f1fb76082ed81f71cb090989 ]

Add support for a PLL rate of 292.5MHz so that the Powkiddy RGB30 panel
can run at a requested 60hz (59.96, close enough).

I have confirmed this rate fits with all the constraints
listed in the TRM for the VPLL (as an integer PLL) in Part 1 "Chapter
2 Clock & Reset Unit (CRU)."

Signed-off-by: Chris Morgan <macromorgan at hotmail.com>
Link: https://lore.kernel.org/r/20231018153357.343142-2-macroalpha82 at gmail.com
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/clk/rockchip/clk-rk3568.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
index 16dabe2b9c47f..db713e1526cdc 100644
--- a/drivers/clk/rockchip/clk-rk3568.c
+++ b/drivers/clk/rockchip/clk-rk3568.c
@@ -72,6 +72,7 @@ static struct rockchip_pll_rate_table rk3568_pll_rates[] = {
 	RK3036_PLL_RATE(408000000, 1, 68, 2, 2, 1, 0),
 	RK3036_PLL_RATE(312000000, 1, 78, 6, 1, 1, 0),
 	RK3036_PLL_RATE(297000000, 2, 99, 4, 1, 1, 0),
+	RK3036_PLL_RATE(292500000, 1, 195, 4, 4, 1, 0),
 	RK3036_PLL_RATE(241500000, 2, 161, 4, 2, 1, 0),
 	RK3036_PLL_RATE(216000000, 1, 72, 4, 2, 1, 0),
 	RK3036_PLL_RATE(200000000, 1, 100, 3, 4, 1, 0),
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:43:36 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:43:36 -0500
Subject: [PATCH AUTOSEL 6.6 02/18] clk: rockchip: rk3128: Fix HCLK_OTG gate register
In-Reply-To: <20231218124415.1379060-1-sashal@kernel.org>
References: <20231218124415.1379060-1-sashal@kernel.org>
Message-ID: <20231218124415.1379060-2-sashal@kernel.org>

From: Weihao Li <cn.liweihao at gmail.com>

[ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ]

The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON.

Signed-off-by: Weihao Li <cn.liweihao at gmail.com>
Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao at gmail.com
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/clk/rockchip/clk-rk3128.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3128.c b/drivers/clk/rockchip/clk-rk3128.c
index aa53797dbfc14..7782785a86e69 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -490,7 +490,7 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = {
 	GATE(HCLK_I2S_2CH, "hclk_i2s_2ch", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, GFLAGS),
 	GATE(0, "hclk_usb_peri", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 13, GFLAGS),
 	GATE(HCLK_HOST2, "hclk_host2", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 3, GFLAGS),
-	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 13, GFLAGS),
+	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(5), 13, GFLAGS),
 	GATE(0, "hclk_peri_ahb", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 14, GFLAGS),
 	GATE(HCLK_SPDIF, "hclk_spdif", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 9, GFLAGS),
 	GATE(HCLK_TSP, "hclk_tsp", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 12, GFLAGS),
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:43:49 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:43:49 -0500
Subject: [PATCH AUTOSEL 6.6 15/18] stmmac: dwmac-loongson: drop useless check for compatible fallback
In-Reply-To: <20231218124415.1379060-1-sashal@kernel.org>
References: <20231218124415.1379060-1-sashal@kernel.org>
Message-ID: <20231218124415.1379060-15-sashal@kernel.org>

From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

[ Upstream commit 31fea092c6f9f8fb2c40a08137907f5fbeae55dd ]

Device binds to proper PCI ID (LOONGSON, 0x7a03), already listed in DTS,
so checking for some other compatible does not make sense.  It cannot be
bound to unsupported platform.

Drop useless, incorrect (space in between) and undocumented compatible.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Yanteng Si <siyanteng at loongson.cn>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
Acked-by: Jiaxun Yang <jiaxun.yang at flygoat.com>
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 2cd6fce5c9934..b508b68157c77 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -59,11 +59,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		return -ENODEV;
 	}
 
-	if (!of_device_is_compatible(np, "loongson, pci-gmac")) {
-		pr_info("dwmac_loongson_pci: Incompatible OF node\n");
-		return -ENODEV;
-	}
-
 	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
 	if (!plat)
 		return -ENOMEM;
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:44:48 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:44:48 -0500
Subject: [PATCH AUTOSEL 6.1 01/15] clk: rockchip: rk3568: Add PLL rate for 292.5MHz
Message-ID: <20231218124513.1380056-1-sashal@kernel.org>

From: Chris Morgan <macromorgan at hotmail.com>

[ Upstream commit 1af27671f62ce919f1fb76082ed81f71cb090989 ]

Add support for a PLL rate of 292.5MHz so that the Powkiddy RGB30 panel
can run at a requested 60hz (59.96, close enough).

I have confirmed this rate fits with all the constraints
listed in the TRM for the VPLL (as an integer PLL) in Part 1 "Chapter
2 Clock & Reset Unit (CRU)."

Signed-off-by: Chris Morgan <macromorgan at hotmail.com>
Link: https://lore.kernel.org/r/20231018153357.343142-2-macroalpha82 at gmail.com
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/clk/rockchip/clk-rk3568.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
index 2f54f630c8b65..1ffb755feea4f 100644
--- a/drivers/clk/rockchip/clk-rk3568.c
+++ b/drivers/clk/rockchip/clk-rk3568.c
@@ -72,6 +72,7 @@ static struct rockchip_pll_rate_table rk3568_pll_rates[] = {
 	RK3036_PLL_RATE(408000000, 1, 68, 2, 2, 1, 0),
 	RK3036_PLL_RATE(312000000, 1, 78, 6, 1, 1, 0),
 	RK3036_PLL_RATE(297000000, 2, 99, 4, 1, 1, 0),
+	RK3036_PLL_RATE(292500000, 1, 195, 4, 4, 1, 0),
 	RK3036_PLL_RATE(241500000, 2, 161, 4, 2, 1, 0),
 	RK3036_PLL_RATE(216000000, 1, 72, 4, 2, 1, 0),
 	RK3036_PLL_RATE(200000000, 1, 100, 3, 4, 1, 0),
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:44:49 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:44:49 -0500
Subject: [PATCH AUTOSEL 6.1 02/15] clk: rockchip: rk3128: Fix HCLK_OTG gate register
In-Reply-To: <20231218124513.1380056-1-sashal@kernel.org>
References: <20231218124513.1380056-1-sashal@kernel.org>
Message-ID: <20231218124513.1380056-2-sashal@kernel.org>

From: Weihao Li <cn.liweihao at gmail.com>

[ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ]

The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON.

Signed-off-by: Weihao Li <cn.liweihao at gmail.com>
Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao at gmail.com
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/clk/rockchip/clk-rk3128.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3128.c b/drivers/clk/rockchip/clk-rk3128.c
index aa53797dbfc14..7782785a86e69 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -490,7 +490,7 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = {
 	GATE(HCLK_I2S_2CH, "hclk_i2s_2ch", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, GFLAGS),
 	GATE(0, "hclk_usb_peri", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 13, GFLAGS),
 	GATE(HCLK_HOST2, "hclk_host2", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 3, GFLAGS),
-	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 13, GFLAGS),
+	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(5), 13, GFLAGS),
 	GATE(0, "hclk_peri_ahb", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 14, GFLAGS),
 	GATE(HCLK_SPDIF, "hclk_spdif", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 9, GFLAGS),
 	GATE(HCLK_TSP, "hclk_tsp", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 12, GFLAGS),
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:44:59 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:44:59 -0500
Subject: [PATCH AUTOSEL 6.1 12/15] stmmac: dwmac-loongson: drop useless check for compatible fallback
In-Reply-To: <20231218124513.1380056-1-sashal@kernel.org>
References: <20231218124513.1380056-1-sashal@kernel.org>
Message-ID: <20231218124513.1380056-12-sashal@kernel.org>

From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

[ Upstream commit 31fea092c6f9f8fb2c40a08137907f5fbeae55dd ]

Device binds to proper PCI ID (LOONGSON, 0x7a03), already listed in DTS,
so checking for some other compatible does not make sense.  It cannot be
bound to unsupported platform.

Drop useless, incorrect (space in between) and undocumented compatible.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Yanteng Si <siyanteng at loongson.cn>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
Acked-by: Jiaxun Yang <jiaxun.yang at flygoat.com>
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index a25c187d31853..900972521b599 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -59,11 +59,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		return -ENODEV;
 	}
 
-	if (!of_device_is_compatible(np, "loongson, pci-gmac")) {
-		pr_info("dwmac_loongson_pci: Incompatible OF node\n");
-		return -ENODEV;
-	}
-
 	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
 	if (!plat)
 		return -ENOMEM;
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:45:34 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:45:34 -0500
Subject: [PATCH AUTOSEL 5.15 01/13] clk: rockchip: rk3128: Fix HCLK_OTG gate register
Message-ID: <20231218124557.1380724-1-sashal@kernel.org>

From: Weihao Li <cn.liweihao at gmail.com>

[ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ]

The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON.

Signed-off-by: Weihao Li <cn.liweihao at gmail.com>
Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao at gmail.com
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/clk/rockchip/clk-rk3128.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3128.c b/drivers/clk/rockchip/clk-rk3128.c
index aa53797dbfc14..7782785a86e69 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -490,7 +490,7 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = {
 	GATE(HCLK_I2S_2CH, "hclk_i2s_2ch", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, GFLAGS),
 	GATE(0, "hclk_usb_peri", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 13, GFLAGS),
 	GATE(HCLK_HOST2, "hclk_host2", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 3, GFLAGS),
-	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 13, GFLAGS),
+	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(5), 13, GFLAGS),
 	GATE(0, "hclk_peri_ahb", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 14, GFLAGS),
 	GATE(HCLK_SPDIF, "hclk_spdif", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 9, GFLAGS),
 	GATE(HCLK_TSP, "hclk_tsp", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 12, GFLAGS),
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:45:43 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:45:43 -0500
Subject: [PATCH AUTOSEL 5.15 10/13] stmmac: dwmac-loongson: drop useless check for compatible fallback
In-Reply-To: <20231218124557.1380724-1-sashal@kernel.org>
References: <20231218124557.1380724-1-sashal@kernel.org>
Message-ID: <20231218124557.1380724-10-sashal@kernel.org>

From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

[ Upstream commit 31fea092c6f9f8fb2c40a08137907f5fbeae55dd ]

Device binds to proper PCI ID (LOONGSON, 0x7a03), already listed in DTS,
so checking for some other compatible does not make sense.  It cannot be
bound to unsupported platform.

Drop useless, incorrect (space in between) and undocumented compatible.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Yanteng Si <siyanteng at loongson.cn>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
Acked-by: Jiaxun Yang <jiaxun.yang at flygoat.com>
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 2ae59f94afe1d..a896fadb96b0e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -59,11 +59,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
 		return -ENODEV;
 	}
 
-	if (!of_device_is_compatible(np, "loongson, pci-gmac")) {
-		pr_info("dwmac_loongson_pci: Incompatible OF node\n");
-		return -ENODEV;
-	}
-
 	plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
 	if (!plat)
 		return -ENOMEM;
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:46:22 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:46:22 -0500
Subject: [PATCH AUTOSEL 5.10 1/8] clk: rockchip: rk3128: Fix HCLK_OTG gate register
Message-ID: <20231218124635.1381482-1-sashal@kernel.org>

From: Weihao Li <cn.liweihao at gmail.com>

[ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ]

The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON.

Signed-off-by: Weihao Li <cn.liweihao at gmail.com>
Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao at gmail.com
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/clk/rockchip/clk-rk3128.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3128.c b/drivers/clk/rockchip/clk-rk3128.c
index 4b1122e98e167..ddfe1c402e80b 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -489,7 +489,7 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = {
 	GATE(HCLK_I2S_2CH, "hclk_i2s_2ch", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, GFLAGS),
 	GATE(0, "hclk_usb_peri", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 13, GFLAGS),
 	GATE(HCLK_HOST2, "hclk_host2", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 3, GFLAGS),
-	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 13, GFLAGS),
+	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(5), 13, GFLAGS),
 	GATE(0, "hclk_peri_ahb", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 14, GFLAGS),
 	GATE(HCLK_SPDIF, "hclk_spdif", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 9, GFLAGS),
 	GATE(HCLK_TSP, "hclk_tsp", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 12, GFLAGS),
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:46:46 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:46:46 -0500
Subject: [PATCH AUTOSEL 5.4 1/7] clk: rockchip: rk3128: Fix HCLK_OTG gate register
Message-ID: <20231218124656.1381949-1-sashal@kernel.org>

From: Weihao Li <cn.liweihao at gmail.com>

[ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ]

The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON.

Signed-off-by: Weihao Li <cn.liweihao at gmail.com>
Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao at gmail.com
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/clk/rockchip/clk-rk3128.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3128.c b/drivers/clk/rockchip/clk-rk3128.c
index 4b1122e98e167..ddfe1c402e80b 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -489,7 +489,7 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = {
 	GATE(HCLK_I2S_2CH, "hclk_i2s_2ch", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, GFLAGS),
 	GATE(0, "hclk_usb_peri", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 13, GFLAGS),
 	GATE(HCLK_HOST2, "hclk_host2", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 3, GFLAGS),
-	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 13, GFLAGS),
+	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(5), 13, GFLAGS),
 	GATE(0, "hclk_peri_ahb", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 14, GFLAGS),
 	GATE(HCLK_SPDIF, "hclk_spdif", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 9, GFLAGS),
 	GATE(HCLK_TSP, "hclk_tsp", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 12, GFLAGS),
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:47:06 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:47:06 -0500
Subject: [PATCH AUTOSEL 4.19 1/6] clk: rockchip: rk3128: Fix HCLK_OTG gate register
Message-ID: <20231218124713.1382373-1-sashal@kernel.org>

From: Weihao Li <cn.liweihao at gmail.com>

[ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ]

The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON.

Signed-off-by: Weihao Li <cn.liweihao at gmail.com>
Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao at gmail.com
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/clk/rockchip/clk-rk3128.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3128.c b/drivers/clk/rockchip/clk-rk3128.c
index 5970a50671b9a..83c7eb18321f4 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -497,7 +497,7 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = {
 	GATE(HCLK_I2S_2CH, "hclk_i2s_2ch", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, GFLAGS),
 	GATE(0, "hclk_usb_peri", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 13, GFLAGS),
 	GATE(HCLK_HOST2, "hclk_host2", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 3, GFLAGS),
-	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 13, GFLAGS),
+	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(5), 13, GFLAGS),
 	GATE(0, "hclk_peri_ahb", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 14, GFLAGS),
 	GATE(HCLK_SPDIF, "hclk_spdif", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 9, GFLAGS),
 	GATE(HCLK_TSP, "hclk_tsp", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 12, GFLAGS),
-- 
2.43.0



From sashal at kernel.org  Mon Dec 18 04:47:18 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 18 Dec 2023 07:47:18 -0500
Subject: [PATCH AUTOSEL 4.14 1/6] clk: rockchip: rk3128: Fix HCLK_OTG gate register
Message-ID: <20231218124725.1382738-1-sashal@kernel.org>

From: Weihao Li <cn.liweihao at gmail.com>

[ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ]

The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON.

Signed-off-by: Weihao Li <cn.liweihao at gmail.com>
Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao at gmail.com
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/clk/rockchip/clk-rk3128.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3128.c b/drivers/clk/rockchip/clk-rk3128.c
index 5970a50671b9a..83c7eb18321f4 100644
--- a/drivers/clk/rockchip/clk-rk3128.c
+++ b/drivers/clk/rockchip/clk-rk3128.c
@@ -497,7 +497,7 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = {
 	GATE(HCLK_I2S_2CH, "hclk_i2s_2ch", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, GFLAGS),
 	GATE(0, "hclk_usb_peri", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 13, GFLAGS),
 	GATE(HCLK_HOST2, "hclk_host2", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 3, GFLAGS),
-	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 13, GFLAGS),
+	GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(5), 13, GFLAGS),
 	GATE(0, "hclk_peri_ahb", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 14, GFLAGS),
 	GATE(HCLK_SPDIF, "hclk_spdif", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 9, GFLAGS),
 	GATE(HCLK_TSP, "hclk_tsp", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 12, GFLAGS),
-- 
2.43.0



From knaerzche at gmail.com  Mon Dec 18 04:49:52 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Mon, 18 Dec 2023 13:49:52 +0100
Subject: [PATCH v2 19/27] drm/rockchip: inno_hdmi: Move tmds rate to
 connector state subclass
In-Reply-To: <xte5vjc3o77wnlozz6sy5yysiezdxbzvbwdblhbqb5s2nwnnv5@xxknftdeo6uk>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-20-knaerzche@gmail.com>
 <xte5vjc3o77wnlozz6sy5yysiezdxbzvbwdblhbqb5s2nwnnv5@xxknftdeo6uk>
Message-ID: <cbb7866c-5e72-4656-966e-9c2244afedbd@gmail.com>


Am 18.12.23 um 11:06 schrieb Maxime Ripard:
> Hi,
>
> On Sat, Dec 16, 2023 at 05:26:30PM +0100, Alex Bee wrote:
>> Similar to the othter members of inno_hdmi_connector_state the tmds_rate is
>> not a property of the device, but of the connector state. Move it to
>> inno_hdmi_connector_state and make it a long to comply with the clock
>> framework. To get arround the issue of not having the connector state when
>> inno_hdmi_i2c_init is called in the bind path, getting the tmds rate is
>> wrapped in function which returns the fallback rate if the connector
>> doesn't have a state yet.
>>
>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>> ---
>> changes in v2:
>>   - new patch
>>
>>   drivers/gpu/drm/rockchip/inno_hdmi.c | 36 +++++++++++++++++++---------
>>   1 file changed, 25 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> index f9bfae1e97a2..6799d24501b8 100644
>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> @@ -47,14 +47,13 @@ struct inno_hdmi {
>>   
>>   	struct inno_hdmi_i2c *i2c;
>>   	struct i2c_adapter *ddc;
>> -
>> -	unsigned int tmds_rate;
>>   };
>>   
>>   struct inno_hdmi_connector_state {
>>   	struct drm_connector_state	base;
>>   	unsigned int			enc_out_format;
>>   	unsigned int			colorimetry;
>> +	unsigned long			tmds_rate;
>>   };
>>   
>>   static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
>> @@ -133,11 +132,33 @@ static inline void hdmi_modb(struct inno_hdmi *hdmi, u16 offset,
>>   	hdmi_writeb(hdmi, offset, temp);
>>   }
>>   
>> +static unsigned long inno_hdmi_tmds_rate(struct inno_hdmi *hdmi)
>> +{
>> +	struct drm_connector *connector = &hdmi->connector;
>> +	struct drm_connector_state *conn_state =  connector->state;
>> +	struct inno_hdmi_connector_state *inno_conn_state;
>> +
>> +	if (conn_state) {
>> +		inno_conn_state = to_inno_hdmi_conn_state(conn_state);
>> +		return inno_conn_state->tmds_rate;
>> +	}
>> +
>> +	/*
>> +	 * When IP controller haven't configured to an accurate video
>> +	 * timing, then the TMDS clock source would be switched to
>> +	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
>> +	 * and reconfigure the DDC clock.
>> +	 */
>> +
>> +	return clk_get_rate(hdmi->pclk);
>> +}
>> +
>>   static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
>>   {
>>   	int ddc_bus_freq;
>> +	unsigned long tmds_rate = inno_hdmi_tmds_rate(hdmi);
>>   
>> -	ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE;
>> +	ddc_bus_freq = (tmds_rate >> 2) / HDMI_SCL_RATE;
>>   
>>   	hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
>>   	hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
>> @@ -431,7 +452,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>   	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
>>   	 * clock rate, and reconfigure the DDC clock.
>>   	 */
>> -	hdmi->tmds_rate = mode->clock * 1000;
>> +	inno_conn_state->tmds_rate = mode->clock * 1000;
>>   	inno_hdmi_i2c_init(hdmi);
>>   
>>   	/* Unmute video and audio output */
>> @@ -823,13 +844,6 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
>>   		goto err_disable_clk;
>>   	}
>>   
>> -	/*
>> -	 * When IP controller haven't configured to an accurate video
>> -	 * timing, then the TMDS clock source would be switched to
>> -	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
>> -	 * and reconfigure the DDC clock.
>> -	 */
>> -	hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
>>   	inno_hdmi_i2c_init(hdmi);
> I still think my patch is better there.
>
> There's two places that use the inno_hdmi.tmds_rate field: the two
> callers of inno_hdmi_i2c_init(). One is at bind time and needs to
> initialise it with a sane default since we don't have a mode set yet,
> the other is to update the internal clock rate while we have a mode set.
That?s, unfortunately, not fully true: inno_hdmi_set_pwr_mode not only
called at mode_set-time, but also in inno_hdmi_reset which is called in the
bind path (where we do not have a mode). That?s the point why I thought
extracting this in function makes sense. Otherwise I would have to pass the
tmds_rate to inno_hdmi_set_pwr_mode (also for the LOWER_PWR-case where I
don't need it) or do that whole fallback-if-no-mode thing in
inno_hdmi_set_pwr_mode directly. Neither would make the code easier to
follow. Being able to use it in inno_hdmi_i2c_init also is a nice gimmick.
I agree, having it in the custom connector state is not strictly required,
but I'd really like to keep the wrapping function.

Alex

> Since there's a single "modeset" user, there's no need to store it in
> the state structure at all: it can be a local variable.
>
> And in the bind function, you're not going to use the state structure
> either since there's no state, and it's just a default that has no
> relation to the modeset code at all.
>
> Your function on the other end tries to reconcile and handle the two.
> But there's no reason to, it just makes the code harder to follow. Just
> pass the parent rate you want to init with as an argument and it's easy
> to read and maintain.
>
> Maxime


From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:36 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:36 +0100
Subject: [PATCH 00/23] TQMa7x/MBa7x DT fixes
Message-ID: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>

Hi,

this series fixes several issues on TQMa7x DT files in various aspects.
Probably most notabe one is disabling PCIe due to missing support for internal
PHY refclock.

Best regards,
Alexander

Alexander Stein (23):
  ARM: dts: imx7-tqma7/mba7: convert fsl,pins to uint32-matrix
  ARM: dts: imx7[d]-mba7: Move ethernet PHY reset into PHY node
  ARM: dts: imx7[d]-mba7: disable USB OC on USB host and USB OTG2
  ARM: dts: imx7[d]-mba7: disable PCIe interface
  ARM: dts: imx7[d]-mba7: hog Mini PCIe signals
  ARM: dts: imx7-mba7: Mark gpio-buttons as wakeup-source
  ARM: dts: imx7-mba7: Enable SNVS power key
  ARM: dts: imx7-mba7: Add RTC aliases
  ARM: dts: imx7-mba7: Add SPI1_SS0 as chip select 3
  ARM: dts: imx7-tqma7: Add i2c bus recovery
  ARM: dts: imx7-mba7: Add i2c bus recovery
  ARM: dts: imx7-tqma7: fix EEPROM compatible for SE97BTP
  ARM: dts: imx7-mba7: Fix iomuxc node names
  ARM: dts: imx7-tqma7: Fix iomuxc node names
  ARM: dts: imx7-mba7: restrict usdhc interface modes
  ARM: dts: imx7-tqma7: restrict usdhc interface modes
  ARM: dts: imx7-tqma7: remove superfluous status property
  ARM: dts: imx7-tqma7: mark system data eeprom as read-only
  ARM: dts: imx7-tqma7: rename node for SE97BTP
  ARM: dts: imx7d-mba7: Remove USB OTG related properties on USB node
  ARM: dts: imx7-tqma7: Add missing vcc supply to i2c eeproms
  ARM: dts: imx7-mba7: Add missing vcc supply to i2c devices
  ARM: dts: imx7-tqma7: Fix PMIC v33 rail voltage range

 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi  | 325 ++++++++++++----------
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 144 +++++-----
 arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts  |  94 ++++---
 3 files changed, 312 insertions(+), 251 deletions(-)

-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:38 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:38 +0100
Subject: [PATCH 02/23] ARM: dts: imx7[d]-mba7: Move ethernet PHY reset into PHY node
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-3-alexander.stein@ew.tq-group.com>

Split pinctrl as well. 'reset-deassert-us' is added with a small safe
margin.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 13 ++++++++++---
 arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts | 13 ++++++++++---
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index 2e406cc7d292..c2be1a75f70d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -214,8 +214,6 @@ &fec1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_enet1>;
 	phy-mode = "rgmii-id";
-	phy-reset-gpios = <&gpio7 15 GPIO_ACTIVE_LOW>;
-	phy-reset-duration = <1>;
 	phy-supply = <&reg_fec1_pwdn>;
 	phy-handle = <&ethphy1_0>;
 	fsl,magic-packet;
@@ -228,10 +226,15 @@ mdio {
 		ethphy1_0: ethernet-phy at 0 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			reg = <0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_enet1_phy>;
 			ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
 			ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
 			ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
 			ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+			reset-gpios = <&gpio7 15 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <1000>;
+			reset-deassert-us = <500>;
 		};
 	};
 };
@@ -366,7 +369,11 @@ pinctrl_enet1: enet1grp {
 			<MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1		0x79>,
 			<MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2		0x79>,
 			<MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3		0x79>,
-			<MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL	0x79>,
+			<MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL	0x79>;
+	};
+
+	pinctrl_enet1_phy: enet1phygrp {
+		fsl,pins =
 			/* Reset: SION, 100kPU, SRE_FAST, DSE_X1 */
 			<MX7D_PAD_ENET1_COL__GPIO7_IO15				0x40000070>,
 			/* INT/PWDN: SION, 100kPU, HYS, SRE_FAST, DSE_X1 */
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
index 79a6d82b453a..4ea1801a7aed 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
@@ -21,8 +21,6 @@ &fec2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_enet2>;
 	phy-mode = "rgmii-id";
-	phy-reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>;
-	phy-reset-duration = <1>;
 	phy-supply = <&reg_fec2_pwdn>;
 	phy-handle = <&ethphy2_0>;
 	fsl,magic-packet;
@@ -35,10 +33,15 @@ mdio {
 		ethphy2_0: ethernet-phy at 0 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			reg = <0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_enet2_phy>;
 			ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
 			ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
 			ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
 			ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+			reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <1000>;
+			reset-deassert-us = <500>;
 		};
 	};
 };
@@ -62,7 +65,11 @@ pinctrl_enet2: enet2grp {
 			<MX7D_PAD_EPDC_SDLE__ENET2_RGMII_RD1		0x79>,
 			<MX7D_PAD_EPDC_SDOE__ENET2_RGMII_RD2		0x79>,
 			<MX7D_PAD_EPDC_SDSHR__ENET2_RGMII_RD3		0x79>,
-			<MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL	0x79>,
+			<MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL	0x79>;
+	};
+
+	pinctrl_enet2_phy: enet2phygrp {
+		fsl,pins =
 			/* Reset: SION, 100kPU, SRE_FAST, DSE_X1 */
 			<MX7D_PAD_EPDC_BDR0__GPIO2_IO28		0x40000070>,
 			/* INT/PWDN: SION, 100kPU, HYS, SRE_FAST, DSE_X1 */
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:37 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:37 +0100
Subject: [PATCH 01/23] ARM: dts: imx7-tqma7/mba7: convert fsl,pins to uint32-matrix
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-2-alexander.stein@ew.tq-group.com>

make dtbs_check does not warn about this anymore, but bindings mandate
a uint32-matrix.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi  | 242 ++++++++++------------
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 114 +++++-----
 arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts  |  51 +++--
 3 files changed, 187 insertions(+), 220 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index 3df6dff7734a..2e406cc7d292 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -334,213 +334,191 @@ &iomuxc {
 	pinctrl-0 = <&pinctrl_hog_mba7_1>;
 
 	pinctrl_ecspi1: ecspi1grp {
-		fsl,pins = <
-			MX7D_PAD_ECSPI1_MISO__ECSPI1_MISO		0x7c
-			MX7D_PAD_ECSPI1_MOSI__ECSPI1_MOSI		0x74
-			MX7D_PAD_ECSPI1_SCLK__ECSPI1_SCLK		0x74
-			MX7D_PAD_UART1_RX_DATA__GPIO4_IO0		0x74
-			MX7D_PAD_UART1_TX_DATA__GPIO4_IO1		0x74
-			MX7D_PAD_UART2_RX_DATA__GPIO4_IO2		0x74
-		>;
+		fsl,pins =
+			<MX7D_PAD_ECSPI1_MISO__ECSPI1_MISO		0x7c>,
+			<MX7D_PAD_ECSPI1_MOSI__ECSPI1_MOSI		0x74>,
+			<MX7D_PAD_ECSPI1_SCLK__ECSPI1_SCLK		0x74>,
+			<MX7D_PAD_UART1_RX_DATA__GPIO4_IO0		0x74>,
+			<MX7D_PAD_UART1_TX_DATA__GPIO4_IO1		0x74>,
+			<MX7D_PAD_UART2_RX_DATA__GPIO4_IO2		0x74>;
 	};
 
 	pinctrl_ecspi2: ecspi2grp {
-		fsl,pins = <
-			MX7D_PAD_ECSPI2_MISO__ECSPI2_MISO		0x7c
-			MX7D_PAD_ECSPI2_MOSI__ECSPI2_MOSI		0x74
-			MX7D_PAD_ECSPI2_SCLK__ECSPI2_SCLK		0x74
-			MX7D_PAD_ECSPI2_SS0__ECSPI2_SS0			0x74
-		>;
+		fsl,pins =
+			<MX7D_PAD_ECSPI2_MISO__ECSPI2_MISO		0x7c>,
+			<MX7D_PAD_ECSPI2_MOSI__ECSPI2_MOSI		0x74>,
+			<MX7D_PAD_ECSPI2_SCLK__ECSPI2_SCLK		0x74>,
+			<MX7D_PAD_ECSPI2_SS0__ECSPI2_SS0		0x74>;
 	};
 
 	pinctrl_enet1: enet1grp {
-		fsl,pins = <
-			MX7D_PAD_GPIO1_IO10__ENET1_MDIO			0x02
-			MX7D_PAD_GPIO1_IO11__ENET1_MDC			0x00
-			MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC	0x71
-			MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0	0x71
-			MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1	0x71
-			MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2	0x71
-			MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3	0x71
-			MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL	0x71
-			MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC	0x79
-			MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0	0x79
-			MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1	0x79
-			MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2	0x79
-			MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3	0x79
-			MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL	0x79
+		fsl,pins =
+			<MX7D_PAD_GPIO1_IO10__ENET1_MDIO			0x02>,
+			<MX7D_PAD_GPIO1_IO11__ENET1_MDC				0x00>,
+			<MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC		0x71>,
+			<MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0		0x71>,
+			<MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1		0x71>,
+			<MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2		0x71>,
+			<MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3		0x71>,
+			<MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL	0x71>,
+			<MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC		0x79>,
+			<MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0		0x79>,
+			<MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1		0x79>,
+			<MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2		0x79>,
+			<MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3		0x79>,
+			<MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL	0x79>,
 			/* Reset: SION, 100kPU, SRE_FAST, DSE_X1 */
-			MX7D_PAD_ENET1_COL__GPIO7_IO15		0x40000070
+			<MX7D_PAD_ENET1_COL__GPIO7_IO15				0x40000070>,
 			/* INT/PWDN: SION, 100kPU, HYS, SRE_FAST, DSE_X1 */
-			MX7D_PAD_GPIO1_IO09__GPIO1_IO9		0x40000078
-		>;
+			<MX7D_PAD_GPIO1_IO09__GPIO1_IO9				0x40000078>;
 	};
 
 	pinctrl_flexcan1: flexcan1grp {
-		fsl,pins = <
-			MX7D_PAD_GPIO1_IO12__FLEXCAN1_RX	0x5a
-			MX7D_PAD_GPIO1_IO13__FLEXCAN1_TX	0x52
-		>;
+		fsl,pins =
+			<MX7D_PAD_GPIO1_IO12__FLEXCAN1_RX	0x5a>,
+			<MX7D_PAD_GPIO1_IO13__FLEXCAN1_TX	0x52>;
 	};
 
 	pinctrl_flexcan2: flexcan2grp {
-		fsl,pins = <
-			MX7D_PAD_GPIO1_IO14__FLEXCAN2_RX	0x5a
-			MX7D_PAD_GPIO1_IO15__FLEXCAN2_TX	0x52
-		>;
+		fsl,pins =
+			<MX7D_PAD_GPIO1_IO14__FLEXCAN2_RX	0x5a>,
+			<MX7D_PAD_GPIO1_IO15__FLEXCAN2_TX	0x52>;
 	};
 
 	pinctrl_hog_mba7_1: hogmba71grp {
-		fsl,pins = <
+		fsl,pins =
 			/* Limitation: WDOG2_B / WDOG2_RESET not usable */
-			MX7D_PAD_ENET1_RX_CLK__GPIO7_IO13	0x4000007c
-			MX7D_PAD_ENET1_CRS__GPIO7_IO14		0x40000074
+			<MX7D_PAD_ENET1_RX_CLK__GPIO7_IO13	0x4000007c>,
+			<MX7D_PAD_ENET1_CRS__GPIO7_IO14		0x40000074>,
 			/* #BOOT_EN */
-			MX7D_PAD_UART2_TX_DATA__GPIO4_IO3	0x40000010
-		>;
+			<MX7D_PAD_UART2_TX_DATA__GPIO4_IO3	0x40000010>;
 	};
 
 	pinctrl_i2c2: i2c2grp {
-		fsl,pins = <
-			MX7D_PAD_I2C2_SCL__I2C2_SCL		0x40000078
-			MX7D_PAD_I2C2_SDA__I2C2_SDA		0x40000078
-		>;
+		fsl,pins =
+			<MX7D_PAD_I2C2_SCL__I2C2_SCL		0x40000078>,
+			<MX7D_PAD_I2C2_SDA__I2C2_SDA		0x40000078>;
 	};
 
 	pinctrl_i2c3: i2c3grp {
-		fsl,pins = <
-			MX7D_PAD_I2C3_SCL__I2C3_SCL		0x40000078
-			MX7D_PAD_I2C3_SDA__I2C3_SDA		0x40000078
-		>;
+		fsl,pins =
+			<MX7D_PAD_I2C3_SCL__I2C3_SCL		0x40000078>,
+			<MX7D_PAD_I2C3_SDA__I2C3_SDA		0x40000078>;
 	};
 
 	pinctrl_pca9555: pca95550grp {
-		fsl,pins = <
-			MX7D_PAD_ENET1_TX_CLK__GPIO7_IO12	0x78
-		>;
+		fsl,pins =
+			<MX7D_PAD_ENET1_TX_CLK__GPIO7_IO12	0x78>;
 	};
 
 	pinctrl_sai1: sai1grp {
-		fsl,pins = <
-			MX7D_PAD_SAI1_MCLK__SAI1_MCLK		0x11
-			MX7D_PAD_SAI1_RX_BCLK__SAI1_RX_BCLK	0x1c
-			MX7D_PAD_SAI1_RX_DATA__SAI1_RX_DATA0	0x1c
-			MX7D_PAD_SAI1_RX_SYNC__SAI2_RX_SYNC	0x1c
+		fsl,pins =
+			<MX7D_PAD_SAI1_MCLK__SAI1_MCLK		0x11>,
+			<MX7D_PAD_SAI1_RX_BCLK__SAI1_RX_BCLK	0x1c>,
+			<MX7D_PAD_SAI1_RX_DATA__SAI1_RX_DATA0	0x1c>,
+			<MX7D_PAD_SAI1_RX_SYNC__SAI2_RX_SYNC	0x1c>,
 
-			MX7D_PAD_SAI1_TX_BCLK__SAI1_TX_BCLK	0x1c
-			MX7D_PAD_SAI1_TX_DATA__SAI1_TX_DATA0	0x14
-			MX7D_PAD_SAI1_TX_SYNC__SAI1_TX_SYNC	0x14
-		>;
+			<MX7D_PAD_SAI1_TX_BCLK__SAI1_TX_BCLK	0x1c>,
+			<MX7D_PAD_SAI1_TX_DATA__SAI1_TX_DATA0	0x14>,
+			<MX7D_PAD_SAI1_TX_SYNC__SAI1_TX_SYNC	0x14>;
 	};
 
 	pinctrl_uart3: uart3grp {
-		fsl,pins = <
-			MX7D_PAD_UART3_RX_DATA__UART3_DCE_RX	0x7e
-			MX7D_PAD_UART3_TX_DATA__UART3_DCE_TX	0x76
-			MX7D_PAD_UART3_CTS_B__UART3_DCE_CTS	0x76
-			MX7D_PAD_UART3_RTS_B__UART3_DCE_RTS	0x7e
-		>;
+		fsl,pins =
+			<MX7D_PAD_UART3_RX_DATA__UART3_DCE_RX	0x7e>,
+			<MX7D_PAD_UART3_TX_DATA__UART3_DCE_TX	0x76>,
+			<MX7D_PAD_UART3_CTS_B__UART3_DCE_CTS	0x76>,
+			<MX7D_PAD_UART3_RTS_B__UART3_DCE_RTS	0x7e>;
 	};
 
 	pinctrl_uart4: uart4grp {
-		fsl,pins = <
-			MX7D_PAD_SAI2_TX_SYNC__UART4_DCE_RX	0x7e
-			MX7D_PAD_SAI2_TX_BCLK__UART4_DCE_TX	0x76
-			MX7D_PAD_SAI2_RX_DATA__UART4_DCE_CTS	0x76
-			MX7D_PAD_SAI2_TX_DATA__UART4_DCE_RTS	0x7e
-		>;
+		fsl,pins =
+			<MX7D_PAD_SAI2_TX_SYNC__UART4_DCE_RX	0x7e>,
+			<MX7D_PAD_SAI2_TX_BCLK__UART4_DCE_TX	0x76>,
+			<MX7D_PAD_SAI2_RX_DATA__UART4_DCE_CTS	0x76>,
+			<MX7D_PAD_SAI2_TX_DATA__UART4_DCE_RTS	0x7e>;
 	};
 
 	pinctrl_uart5: uart5grp {
-		fsl,pins = <
-			MX7D_PAD_I2C4_SCL__UART5_DCE_RX		0x7e
-			MX7D_PAD_I2C4_SDA__UART5_DCE_TX		0x76
-		>;
+		fsl,pins =
+			<MX7D_PAD_I2C4_SCL__UART5_DCE_RX	0x7e>,
+			<MX7D_PAD_I2C4_SDA__UART5_DCE_TX	0x76>;
 	};
 
 	pinctrl_uart6: uart6grp {
-		fsl,pins = <
-			MX7D_PAD_EPDC_DATA08__UART6_DCE_RX	0x7d
-			MX7D_PAD_EPDC_DATA09__UART6_DCE_TX	0x75
-			MX7D_PAD_EPDC_DATA11__UART6_DCE_CTS	0x75
-			MX7D_PAD_EPDC_DATA10__UART6_DCE_RTS	0x7d
-		>;
+		fsl,pins =
+			<MX7D_PAD_EPDC_DATA08__UART6_DCE_RX	0x7d>,
+			<MX7D_PAD_EPDC_DATA09__UART6_DCE_TX	0x75>,
+			<MX7D_PAD_EPDC_DATA11__UART6_DCE_CTS	0x75>,
+			<MX7D_PAD_EPDC_DATA10__UART6_DCE_RTS	0x7d>;
 	};
 
 	pinctrl_uart7: uart7grp {
-		fsl,pins = <
-			MX7D_PAD_EPDC_DATA12__UART7_DCE_RX	0x7e
-			MX7D_PAD_EPDC_DATA13__UART7_DCE_TX	0x76
-			MX7D_PAD_EPDC_DATA15__UART7_DCE_CTS	0x76
+		fsl,pins =
+			<MX7D_PAD_EPDC_DATA12__UART7_DCE_RX	0x7e>,
+			<MX7D_PAD_EPDC_DATA13__UART7_DCE_TX	0x76>,
+			<MX7D_PAD_EPDC_DATA15__UART7_DCE_CTS	0x76>,
 			/* Limitation: RTS is not connected */
-			MX7D_PAD_EPDC_DATA14__UART7_DCE_RTS	0x7e
-		>;
+			<MX7D_PAD_EPDC_DATA14__UART7_DCE_RTS	0x7e>;
 	};
 
 	pinctrl_usdhc1_gpio: usdhc1grp_gpio {
-		fsl,pins = <
+		fsl,pins =
 			/* WP */
-			MX7D_PAD_SD1_WP__GPIO5_IO1		0x7c
+			<MX7D_PAD_SD1_WP__GPIO5_IO1		0x7c>,
 			/* CD */
-			MX7D_PAD_SD1_CD_B__GPIO5_IO0		0x7c
+			<MX7D_PAD_SD1_CD_B__GPIO5_IO0		0x7c>,
 			/* VSELECT */
-			MX7D_PAD_GPIO1_IO08__SD1_VSELECT	0x59
-		>;
+			<MX7D_PAD_GPIO1_IO08__SD1_VSELECT	0x59>;
 	};
 
 	pinctrl_usdhc1: usdhc1grp {
-		fsl,pins = <
-			MX7D_PAD_SD1_CMD__SD1_CMD		0x5e
-			MX7D_PAD_SD1_CLK__SD1_CLK		0x57
-			MX7D_PAD_SD1_DATA0__SD1_DATA0		0x5e
-			MX7D_PAD_SD1_DATA1__SD1_DATA1		0x5e
-			MX7D_PAD_SD1_DATA2__SD1_DATA2		0x5e
-			MX7D_PAD_SD1_DATA3__SD1_DATA3		0x5e
-		>;
+		fsl,pins =
+			<MX7D_PAD_SD1_CMD__SD1_CMD		0x5e>,
+			<MX7D_PAD_SD1_CLK__SD1_CLK		0x57>,
+			<MX7D_PAD_SD1_DATA0__SD1_DATA0		0x5e>,
+			<MX7D_PAD_SD1_DATA1__SD1_DATA1		0x5e>,
+			<MX7D_PAD_SD1_DATA2__SD1_DATA2		0x5e>,
+			<MX7D_PAD_SD1_DATA3__SD1_DATA3		0x5e>;
 	};
 
 	pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
-		fsl,pins = <
-			MX7D_PAD_SD1_CMD__SD1_CMD		0x5a
-			MX7D_PAD_SD1_CLK__SD1_CLK		0x57
-			MX7D_PAD_SD1_DATA0__SD1_DATA0		0x5a
-			MX7D_PAD_SD1_DATA1__SD1_DATA1		0x5a
-			MX7D_PAD_SD1_DATA2__SD1_DATA2		0x5a
-			MX7D_PAD_SD1_DATA3__SD1_DATA3		0x5a
-		>;
+		fsl,pins =
+			<MX7D_PAD_SD1_CMD__SD1_CMD		0x5a>,
+			<MX7D_PAD_SD1_CLK__SD1_CLK		0x57>,
+			<MX7D_PAD_SD1_DATA0__SD1_DATA0		0x5a>,
+			<MX7D_PAD_SD1_DATA1__SD1_DATA1		0x5a>,
+			<MX7D_PAD_SD1_DATA2__SD1_DATA2		0x5a>,
+			<MX7D_PAD_SD1_DATA3__SD1_DATA3		0x5a>;
 	};
 
 	pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
-		fsl,pins = <
-			MX7D_PAD_SD1_CMD__SD1_CMD		0x5b
-			MX7D_PAD_SD1_CLK__SD1_CLK		0x57
-			MX7D_PAD_SD1_DATA0__SD1_DATA0		0x5b
-			MX7D_PAD_SD1_DATA1__SD1_DATA1		0x5b
-			MX7D_PAD_SD1_DATA2__SD1_DATA2		0x5b
-			MX7D_PAD_SD1_DATA3__SD1_DATA3		0x5b
-		>;
+		fsl,pins =
+			<MX7D_PAD_SD1_CMD__SD1_CMD		0x5b>,
+			<MX7D_PAD_SD1_CLK__SD1_CLK		0x57>,
+			<MX7D_PAD_SD1_DATA0__SD1_DATA0		0x5b>,
+			<MX7D_PAD_SD1_DATA1__SD1_DATA1		0x5b>,
+			<MX7D_PAD_SD1_DATA2__SD1_DATA2		0x5b>,
+			<MX7D_PAD_SD1_DATA3__SD1_DATA3		0x5b>;
 	};
 };
 
 &iomuxc_lpsr {
 	pinctrl_pwm1: pwm1grp {
-		fsl,pins = <
+		fsl,pins =
 			/* LCD_CONTRAST */
-			MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT	0x50
-		>;
+			<MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT	0x50>;
 	};
 
 	pinctrl_usbotg1: usbotg1grp {
-		fsl,pins = <
-			MX7D_PAD_LPSR_GPIO1_IO04__USB_OTG1_OC	0x5c
-			MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5	0x59
-		>;
+		fsl,pins =
+			<MX7D_PAD_LPSR_GPIO1_IO04__USB_OTG1_OC	0x5c>,
+			<MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5	0x59>;
 	};
 
 	pinctrl_wdog1: wdog1grp {
-		fsl,pins = <
-			MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B	0x30
-		>;
+		fsl,pins =
+			<MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B	0x30>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index 3fc3130f9def..e6e40747d5b9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -163,91 +163,83 @@ ds1339: rtc at 68 {
 
 &iomuxc {
 	pinctrl_i2c1: i2c1grp {
-		fsl,pins = <
-			MX7D_PAD_I2C1_SDA__I2C1_SDA	0x40000078
-			MX7D_PAD_I2C1_SCL__I2C1_SCL	0x40000078
-		>;
+		fsl,pins =
+			<MX7D_PAD_I2C1_SDA__I2C1_SDA	0x40000078>,
+			<MX7D_PAD_I2C1_SCL__I2C1_SCL	0x40000078>;
 	};
 
 	pinctrl_pmic1: pmic1grp {
-		fsl,pins = <
-			MX7D_PAD_SD2_RESET_B__GPIO5_IO11	0x4000005C
-		>;
+		fsl,pins =
+			<MX7D_PAD_SD2_RESET_B__GPIO5_IO11	0x4000005C>;
 	};
 
 	pinctrl_qspi: qspigrp {
-		fsl,pins = <
-			MX7D_PAD_EPDC_DATA00__QSPI_A_DATA0	0x5A
-			MX7D_PAD_EPDC_DATA01__QSPI_A_DATA1	0x5A
-			MX7D_PAD_EPDC_DATA02__QSPI_A_DATA2	0x5A
-			MX7D_PAD_EPDC_DATA03__QSPI_A_DATA3	0x5A
-			MX7D_PAD_EPDC_DATA05__QSPI_A_SCLK	0x11
-			MX7D_PAD_EPDC_DATA06__QSPI_A_SS0_B	0x54
-			MX7D_PAD_EPDC_DATA07__QSPI_A_SS1_B	0x54
-		>;
+		fsl,pins =
+			<MX7D_PAD_EPDC_DATA00__QSPI_A_DATA0	0x5A>,
+			<MX7D_PAD_EPDC_DATA01__QSPI_A_DATA1	0x5A>,
+			<MX7D_PAD_EPDC_DATA02__QSPI_A_DATA2	0x5A>,
+			<MX7D_PAD_EPDC_DATA03__QSPI_A_DATA3	0x5A>,
+			<MX7D_PAD_EPDC_DATA05__QSPI_A_SCLK	0x11>,
+			<MX7D_PAD_EPDC_DATA06__QSPI_A_SS0_B	0x54>,
+			<MX7D_PAD_EPDC_DATA07__QSPI_A_SS1_B	0x54>;
 	};
 
 	pinctrl_qspi_reset: qspi_resetgrp {
-		fsl,pins = <
+		fsl,pins =
 			/* #QSPI_RESET */
-			MX7D_PAD_EPDC_DATA04__GPIO2_IO4		0x52
-		>;
+			<MX7D_PAD_EPDC_DATA04__GPIO2_IO4	0x52>;
 	};
 
 	pinctrl_usdhc3: usdhc3grp {
-		fsl,pins = <
-			MX7D_PAD_SD3_CMD__SD3_CMD		0x59
-			MX7D_PAD_SD3_CLK__SD3_CLK		0x56
-			MX7D_PAD_SD3_DATA0__SD3_DATA0		0x59
-			MX7D_PAD_SD3_DATA1__SD3_DATA1		0x59
-			MX7D_PAD_SD3_DATA2__SD3_DATA2		0x59
-			MX7D_PAD_SD3_DATA3__SD3_DATA3		0x59
-			MX7D_PAD_SD3_DATA4__SD3_DATA4		0x59
-			MX7D_PAD_SD3_DATA5__SD3_DATA5		0x59
-			MX7D_PAD_SD3_DATA6__SD3_DATA6		0x59
-			MX7D_PAD_SD3_DATA7__SD3_DATA7		0x59
-			MX7D_PAD_SD3_STROBE__SD3_STROBE		0x19
-		>;
+		fsl,pins =
+			<MX7D_PAD_SD3_CMD__SD3_CMD		0x59>,
+			<MX7D_PAD_SD3_CLK__SD3_CLK		0x56>,
+			<MX7D_PAD_SD3_DATA0__SD3_DATA0		0x59>,
+			<MX7D_PAD_SD3_DATA1__SD3_DATA1		0x59>,
+			<MX7D_PAD_SD3_DATA2__SD3_DATA2		0x59>,
+			<MX7D_PAD_SD3_DATA3__SD3_DATA3		0x59>,
+			<MX7D_PAD_SD3_DATA4__SD3_DATA4		0x59>,
+			<MX7D_PAD_SD3_DATA5__SD3_DATA5		0x59>,
+			<MX7D_PAD_SD3_DATA6__SD3_DATA6		0x59>,
+			<MX7D_PAD_SD3_DATA7__SD3_DATA7		0x59>,
+			<MX7D_PAD_SD3_STROBE__SD3_STROBE	0x19>;
 	};
 
 	pinctrl_usdhc3_100mhz: usdhc3grp_100mhz {
-		fsl,pins = <
-			MX7D_PAD_SD3_CMD__SD3_CMD               0x5a
-			MX7D_PAD_SD3_CLK__SD3_CLK               0x51
-			MX7D_PAD_SD3_DATA0__SD3_DATA0           0x5a
-			MX7D_PAD_SD3_DATA1__SD3_DATA1           0x5a
-			MX7D_PAD_SD3_DATA2__SD3_DATA2           0x5a
-			MX7D_PAD_SD3_DATA3__SD3_DATA3           0x5a
-			MX7D_PAD_SD3_DATA4__SD3_DATA4           0x5a
-			MX7D_PAD_SD3_DATA5__SD3_DATA5           0x5a
-			MX7D_PAD_SD3_DATA6__SD3_DATA6           0x5a
-			MX7D_PAD_SD3_DATA7__SD3_DATA7           0x5a
-			MX7D_PAD_SD3_STROBE__SD3_STROBE         0x1a
-		>;
+		fsl,pins =
+			<MX7D_PAD_SD3_CMD__SD3_CMD               0x5a>,
+			<MX7D_PAD_SD3_CLK__SD3_CLK               0x51>,
+			<MX7D_PAD_SD3_DATA0__SD3_DATA0           0x5a>,
+			<MX7D_PAD_SD3_DATA1__SD3_DATA1           0x5a>,
+			<MX7D_PAD_SD3_DATA2__SD3_DATA2           0x5a>,
+			<MX7D_PAD_SD3_DATA3__SD3_DATA3           0x5a>,
+			<MX7D_PAD_SD3_DATA4__SD3_DATA4           0x5a>,
+			<MX7D_PAD_SD3_DATA5__SD3_DATA5           0x5a>,
+			<MX7D_PAD_SD3_DATA6__SD3_DATA6           0x5a>,
+			<MX7D_PAD_SD3_DATA7__SD3_DATA7           0x5a>,
+			<MX7D_PAD_SD3_STROBE__SD3_STROBE         0x1a>;
 	};
 
 	pinctrl_usdhc3_200mhz: usdhc3grp_200mhz {
-		fsl,pins = <
-			MX7D_PAD_SD3_CMD__SD3_CMD               0x5b
-			MX7D_PAD_SD3_CLK__SD3_CLK               0x51
-			MX7D_PAD_SD3_DATA0__SD3_DATA0           0x5b
-			MX7D_PAD_SD3_DATA1__SD3_DATA1           0x5b
-			MX7D_PAD_SD3_DATA2__SD3_DATA2           0x5b
-			MX7D_PAD_SD3_DATA3__SD3_DATA3           0x5b
-			MX7D_PAD_SD3_DATA4__SD3_DATA4           0x5b
-			MX7D_PAD_SD3_DATA5__SD3_DATA5           0x5b
-			MX7D_PAD_SD3_DATA6__SD3_DATA6           0x5b
-			MX7D_PAD_SD3_DATA7__SD3_DATA7           0x5b
-			MX7D_PAD_SD3_STROBE__SD3_STROBE         0x1b
-		>;
+		fsl,pins =
+			<MX7D_PAD_SD3_CMD__SD3_CMD               0x5b>,
+			<MX7D_PAD_SD3_CLK__SD3_CLK               0x51>,
+			<MX7D_PAD_SD3_DATA0__SD3_DATA0           0x5b>,
+			<MX7D_PAD_SD3_DATA1__SD3_DATA1           0x5b>,
+			<MX7D_PAD_SD3_DATA2__SD3_DATA2           0x5b>,
+			<MX7D_PAD_SD3_DATA3__SD3_DATA3           0x5b>,
+			<MX7D_PAD_SD3_DATA4__SD3_DATA4           0x5b>,
+			<MX7D_PAD_SD3_DATA5__SD3_DATA5           0x5b>,
+			<MX7D_PAD_SD3_DATA6__SD3_DATA6           0x5b>,
+			<MX7D_PAD_SD3_DATA7__SD3_DATA7           0x5b>,
+			<MX7D_PAD_SD3_STROBE__SD3_STROBE         0x1b>;
 	};
 };
 
 &iomuxc_lpsr {
 	pinctrl_wdog1: wdog1grp {
-		fsl,pins = <
-			MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B	0x30
-		>;
+		fsl,pins =
+			<MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B	0x30>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
index 32bf9fa9d00e..79a6d82b453a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
@@ -48,46 +48,43 @@ &iomuxc {
 	pinctrl-0 = <&pinctrl_hog_mba7_1>;
 
 	pinctrl_enet2: enet2grp {
-		fsl,pins = <
-			MX7D_PAD_SD2_CD_B__ENET2_MDIO			0x02
-			MX7D_PAD_SD2_WP__ENET2_MDC			0x00
-			MX7D_PAD_EPDC_GDSP__ENET2_RGMII_TXC		0x71
-			MX7D_PAD_EPDC_SDCE2__ENET2_RGMII_TD0		0x71
-			MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1		0x71
-			MX7D_PAD_EPDC_GDCLK__ENET2_RGMII_TD2		0x71
-			MX7D_PAD_EPDC_GDOE__ENET2_RGMII_TD3		0x71
-			MX7D_PAD_EPDC_GDRL__ENET2_RGMII_TX_CTL		0x71
-			MX7D_PAD_EPDC_SDCE1__ENET2_RGMII_RXC		0x79
-			MX7D_PAD_EPDC_SDCLK__ENET2_RGMII_RD0		0x79
-			MX7D_PAD_EPDC_SDLE__ENET2_RGMII_RD1		0x79
-			MX7D_PAD_EPDC_SDOE__ENET2_RGMII_RD2		0x79
-			MX7D_PAD_EPDC_SDSHR__ENET2_RGMII_RD3		0x79
-			MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL		0x79
+		fsl,pins =
+			<MX7D_PAD_SD2_CD_B__ENET2_MDIO			0x02>,
+			<MX7D_PAD_SD2_WP__ENET2_MDC			0x00>,
+			<MX7D_PAD_EPDC_GDSP__ENET2_RGMII_TXC		0x71>,
+			<MX7D_PAD_EPDC_SDCE2__ENET2_RGMII_TD0		0x71>,
+			<MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1		0x71>,
+			<MX7D_PAD_EPDC_GDCLK__ENET2_RGMII_TD2		0x71>,
+			<MX7D_PAD_EPDC_GDOE__ENET2_RGMII_TD3		0x71>,
+			<MX7D_PAD_EPDC_GDRL__ENET2_RGMII_TX_CTL		0x71>,
+			<MX7D_PAD_EPDC_SDCE1__ENET2_RGMII_RXC		0x79>,
+			<MX7D_PAD_EPDC_SDCLK__ENET2_RGMII_RD0		0x79>,
+			<MX7D_PAD_EPDC_SDLE__ENET2_RGMII_RD1		0x79>,
+			<MX7D_PAD_EPDC_SDOE__ENET2_RGMII_RD2		0x79>,
+			<MX7D_PAD_EPDC_SDSHR__ENET2_RGMII_RD3		0x79>,
+			<MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL	0x79>,
 			/* Reset: SION, 100kPU, SRE_FAST, DSE_X1 */
-			MX7D_PAD_EPDC_BDR0__GPIO2_IO28		0x40000070
+			<MX7D_PAD_EPDC_BDR0__GPIO2_IO28		0x40000070>,
 			/* INT/PWDN: SION, 100kPU, HYS, SRE_FAST, DSE_X1 */
-			MX7D_PAD_EPDC_PWR_STAT__GPIO2_IO31	0x40000078
-		>;
+			<MX7D_PAD_EPDC_PWR_STAT__GPIO2_IO31	0x40000078>;
 	};
 
 	pinctrl_pcie: pciegrp {
-		fsl,pins = <
+		fsl,pins =
 			/* #pcie_wake */
-			MX7D_PAD_EPDC_PWR_COM__GPIO2_IO30		0x70
+			<MX7D_PAD_EPDC_PWR_COM__GPIO2_IO30		0x70>,
 			/* #pcie_rst */
-			MX7D_PAD_SD2_CLK__GPIO5_IO12			0x70
+			<MX7D_PAD_SD2_CLK__GPIO5_IO12			0x70>,
 			/* #pcie_dis */
-			MX7D_PAD_EPDC_BDR1__GPIO2_IO29			0x70
-		>;
+			<MX7D_PAD_EPDC_BDR1__GPIO2_IO29			0x70>;
 	};
 };
 
 &iomuxc_lpsr {
 	pinctrl_usbotg2: usbotg2grp {
-		fsl,pins = <
-			MX7D_PAD_LPSR_GPIO1_IO06__USB_OTG2_OC	0x5c
-			MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7	0x59
-		>;
+		fsl,pins =
+			<MX7D_PAD_LPSR_GPIO1_IO06__USB_OTG2_OC	0x5c>,
+			<MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7	0x59>;
 	};
 };
 
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:39 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:39 +0100
Subject: [PATCH 03/23] ARM: dts: imx7[d]-mba7: disable USB OC on USB host and USB OTG2
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-4-alexander.stein@ew.tq-group.com>

USB host is an HSIC interface directly connected to a USB hub. USB OTG2
is a direct connection to Mini PCIe interface without any OC signaling.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 1 +
 arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index c2be1a75f70d..2aef830cf1f2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -590,6 +590,7 @@ &uart7 {
 };
 
 &usbh {
+	disable-over-current;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
index 4ea1801a7aed..d3a6b81fb1dc 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
@@ -112,6 +112,7 @@ &usbotg2 {
 	srp-disable;
 	hnp-disable;
 	adp-disable;
+	disable-over-current;
 	dr_mode = "host";
 	status = "okay";
 };
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:40 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:40 +0100
Subject: [PATCH 04/23] ARM: dts: imx7[d]-mba7: disable PCIe interface
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-5-alexander.stein@ew.tq-group.com>

Using internal PHY refclk is not supported yet.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
index d3a6b81fb1dc..34adf76b713e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
@@ -102,7 +102,7 @@ &pcie {
 	/* probe deferral not supported */
 	/* pcie-bus-supply = <&reg_mpcie_1v5>; */
 	reset-gpio = <&gpio5 12 GPIO_ACTIVE_LOW>;
-	status = "okay";
+	status = "disabled";
 };
 
 &usbotg2 {
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:41 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:41 +0100
Subject: [PATCH 05/23] ARM: dts: imx7[d]-mba7: hog Mini PCIe signals
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-6-alexander.stein@ew.tq-group.com>

PCIE_DIS & PCIE_RST (correctly named W_DISABLE# & PERST#) affect USB
devices as well. So hog them to make USB devices attached to Mini PCIe
connector available, despite PCIe being disabled.
Supply voltages are enabled unconditionally.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts | 28 ++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
index 34adf76b713e..8f2f3898d9d1 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
@@ -46,9 +46,25 @@ ethphy2_0: ethernet-phy at 0 {
 	};
 };
 
+&gpio2 {
+	pcie-dis-hog {
+		gpio-hog;
+		gpios = <29 GPIO_ACTIVE_HIGH>;
+		output-high;
+		line-name = "pcie-dis";
+	};
+
+	pcie-rst-hog {
+		gpio-hog;
+		gpios = <12 GPIO_ACTIVE_HIGH>;
+		output-high;
+		line-name = "pcie-rst";
+	};
+};
+
 &iomuxc {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hog_mba7_1>;
+	pinctrl-0 = <&pinctrl_hog_mba7_1>, <&pinctrl_hog_pcie>;
 
 	pinctrl_enet2: enet2grp {
 		fsl,pins =
@@ -76,15 +92,19 @@ pinctrl_enet2_phy: enet2phygrp {
 			<MX7D_PAD_EPDC_PWR_STAT__GPIO2_IO31	0x40000078>;
 	};
 
-	pinctrl_pcie: pciegrp {
+	pinctrl_hog_pcie: hogpciegrp {
 		fsl,pins =
-			/* #pcie_wake */
-			<MX7D_PAD_EPDC_PWR_COM__GPIO2_IO30		0x70>,
 			/* #pcie_rst */
 			<MX7D_PAD_SD2_CLK__GPIO5_IO12			0x70>,
 			/* #pcie_dis */
 			<MX7D_PAD_EPDC_BDR1__GPIO2_IO29			0x70>;
 	};
+
+	pinctrl_pcie: pciegrp {
+		fsl,pins =
+			/* #pcie_wake */
+			<MX7D_PAD_EPDC_PWR_COM__GPIO2_IO30		0x70>;
+	};
 };
 
 &iomuxc_lpsr {
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:42 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:42 +0100
Subject: [PATCH 06/23] ARM: dts: imx7-mba7: Mark gpio-buttons as wakeup-source
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-7-alexander.stein@ew.tq-group.com>

I2C expander is capable of generating an IRQ during powersave, so the
attached buttons can be used for waking up the system.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index 2aef830cf1f2..bc5d2e4f0eb1 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -32,11 +32,18 @@ chosen {
 	gpio_buttons: gpio-keys {
 		compatible = "gpio-keys";
 
+		/*
+		 * NOTE: These buttons are attached to a GPIO-expander.
+		 * Enabling wakeup-source, enables wakeup on all inputs.
+		 * If PE_GPIO[3..6] are used as inputs, they cause a
+		 * wakeup as well.
+		 */
 		button-0 {
 			/* #SWITCH_A */
 			label = "S11";
 			linux,code = <KEY_1>;
 			gpios = <&pca9555 13 GPIO_ACTIVE_LOW>;
+			wakeup-source;
 		};
 
 		button-1 {
@@ -44,6 +51,7 @@ button-1 {
 			label = "S12";
 			linux,code = <KEY_2>;
 			gpios = <&pca9555 14 GPIO_ACTIVE_LOW>;
+			wakeup-source;
 		};
 
 		button-2 {
@@ -51,6 +59,7 @@ button-2 {
 			label = "S13";
 			linux,code = <KEY_3>;
 			gpios = <&pca9555 15 GPIO_ACTIVE_LOW>;
+			wakeup-source;
 		};
 	};
 
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:43 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:43 +0100
Subject: [PATCH 07/23] ARM: dts: imx7-mba7: Enable SNVS power key
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-8-alexander.stein@ew.tq-group.com>

This allows using S10 for power down / shutdown.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index bc5d2e4f0eb1..a66414098176 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -554,6 +554,10 @@ &sai1 {
 	status = "okay";
 };
 
+&snvs_pwrkey {
+	status = "okay";
+};
+
 &uart3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart3>;
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:44 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:44 +0100
Subject: [PATCH 08/23] ARM: dts: imx7-mba7: Add RTC aliases
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-9-alexander.stein@ew.tq-group.com>

Ensure the RTC devices are numbered correctly.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index a66414098176..7b7bc86265fc 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -18,6 +18,8 @@ aliases {
 		mmc0 = &usdhc3;
 		mmc1 = &usdhc1;
 		/delete-property/ mmc2;
+		rtc0 = &ds1339;
+		rtc1 = &snvs_rtc;
 	};
 
 	beeper {
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:45 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:45 +0100
Subject: [PATCH 09/23] ARM: dts: imx7-mba7: Add SPI1_SS0 as chip select 3
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-10-alexander.stein@ew.tq-group.com>

ECSPI1.SS0 was missing in the list.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index 7b7bc86265fc..e887889816c7 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -209,9 +209,9 @@ &adc2 {
 
 &ecspi1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_ecspi1>;
+	pinctrl-0 = <&pinctrl_ecspi1>, <&pinctrl_ecspi1_ss0>;
 	cs-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>, <&gpio4 1 GPIO_ACTIVE_LOW>,
-		   <&gpio4 2 GPIO_ACTIVE_LOW>;
+		   <&gpio4 2 GPIO_ACTIVE_LOW>, <&gpio4 19 GPIO_ACTIVE_LOW>;
 	status = "okay";
 };
 
@@ -357,6 +357,12 @@ pinctrl_ecspi1: ecspi1grp {
 			<MX7D_PAD_UART2_RX_DATA__GPIO4_IO2		0x74>;
 	};
 
+	pinctrl_ecspi1_ss0: ecspi1ss0grp {
+		fsl,pins = <
+			MX7D_PAD_ECSPI1_SS0__GPIO4_IO19			0x74
+		>;
+	};
+
 	pinctrl_ecspi2: ecspi2grp {
 		fsl,pins =
 			<MX7D_PAD_ECSPI2_MISO__ECSPI2_MISO		0x7c>,
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:48 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:48 +0100
Subject: [PATCH 12/23] ARM: dts: imx7-tqma7: fix EEPROM compatible for SE97BTP
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-13-alexander.stein@ew.tq-group.com>

0x56 is the EEPROM component of SE97BTP.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index a68f567010f2..c67f73b0ed5e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -152,7 +152,7 @@ m24c64: eeprom at 50 {
 	};
 
 	at24c02: eeprom at 56 {
-		compatible = "atmel,24c02";
+		compatible = "nxp,se97b", "atmel,24c02";
 		reg = <0x56>;
 		pagesize = <16>;
 		status = "okay";
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:49 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:49 +0100
Subject: [PATCH 13/23] ARM: dts: imx7-mba7: Fix iomuxc node names
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-14-alexander.stein@ew.tq-group.com>

The node name must end with 'grp'

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index f72fd912e1a6..ac905615ee03 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -504,7 +504,7 @@ pinctrl_uart7: uart7grp {
 			<MX7D_PAD_EPDC_DATA14__UART7_DCE_RTS	0x7e>;
 	};
 
-	pinctrl_usdhc1_gpio: usdhc1grp_gpio {
+	pinctrl_usdhc1_gpio: usdhc1_gpiogrp {
 		fsl,pins =
 			/* WP */
 			<MX7D_PAD_SD1_WP__GPIO5_IO1		0x7c>,
@@ -524,7 +524,7 @@ pinctrl_usdhc1: usdhc1grp {
 			<MX7D_PAD_SD1_DATA3__SD1_DATA3		0x5e>;
 	};
 
-	pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
+	pinctrl_usdhc1_100mhz: usdhc1_100mhzgrp {
 		fsl,pins =
 			<MX7D_PAD_SD1_CMD__SD1_CMD		0x5a>,
 			<MX7D_PAD_SD1_CLK__SD1_CLK		0x57>,
@@ -534,7 +534,7 @@ pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
 			<MX7D_PAD_SD1_DATA3__SD1_DATA3		0x5a>;
 	};
 
-	pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
+	pinctrl_usdhc1_200mhz: usdhc1_200mhzgrp {
 		fsl,pins =
 			<MX7D_PAD_SD1_CMD__SD1_CMD		0x5b>,
 			<MX7D_PAD_SD1_CLK__SD1_CLK		0x57>,
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:50 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:50 +0100
Subject: [PATCH 14/23] ARM: dts: imx7-tqma7: Fix iomuxc node names
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-15-alexander.stein@ew.tq-group.com>

The node name must end with 'grp'

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index c67f73b0ed5e..53c84393200c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -214,7 +214,7 @@ pinctrl_usdhc3: usdhc3grp {
 			<MX7D_PAD_SD3_STROBE__SD3_STROBE	0x19>;
 	};
 
-	pinctrl_usdhc3_100mhz: usdhc3grp_100mhz {
+	pinctrl_usdhc3_100mhz: usdhc3_100mhzgrp {
 		fsl,pins =
 			<MX7D_PAD_SD3_CMD__SD3_CMD               0x5a>,
 			<MX7D_PAD_SD3_CLK__SD3_CLK               0x51>,
@@ -229,7 +229,7 @@ pinctrl_usdhc3_100mhz: usdhc3grp_100mhz {
 			<MX7D_PAD_SD3_STROBE__SD3_STROBE         0x1a>;
 	};
 
-	pinctrl_usdhc3_200mhz: usdhc3grp_200mhz {
+	pinctrl_usdhc3_200mhz: usdhc3_200mhzgrp {
 		fsl,pins =
 			<MX7D_PAD_SD3_CMD__SD3_CMD               0x5b>,
 			<MX7D_PAD_SD3_CLK__SD3_CLK               0x51>,
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:51 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:51 +0100
Subject: [PATCH 15/23] ARM: dts: imx7-mba7: restrict usdhc interface modes
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-16-alexander.stein@ew.tq-group.com>

USDHC1 is directly connected to an SD card, so disable other interface modes.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index ac905615ee03..1b1eac33a70f 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -655,6 +655,8 @@ &usdhc1 {
 	vmmc-supply = <&reg_sd1_vmmc>;
 	bus-width = <4>;
 	no-1-8-v;
+	no-sdio;
+	no-emmc;
 	status = "okay";
 };
 
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:46 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:46 +0100
Subject: [PATCH 10/23] ARM: dts: imx7-tqma7: Add i2c bus recovery
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-11-alexander.stein@ew.tq-group.com>

Add the pin muxing and GPIO settings for SCL/SDA for i2c1.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index e6e40747d5b9..a68f567010f2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -30,8 +30,11 @@ qspi-reset-hog {
 };
 
 &i2c1 {
-	pinctrl-names = "default";
+	pinctrl-names = "default", "gpio";
 	pinctrl-0 = <&pinctrl_i2c1>;
+	pinctrl-1 = <&pinctrl_i2c1_recovery>;
+	scl-gpios = <&gpio4 8 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&gpio4 9 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
 	clock-frequency = <100000>;
 	status = "okay";
 
@@ -168,6 +171,12 @@ pinctrl_i2c1: i2c1grp {
 			<MX7D_PAD_I2C1_SCL__I2C1_SCL	0x40000078>;
 	};
 
+	pinctrl_i2c1_recovery: i2c1recoverygrp {
+		fsl,pins =
+			<MX7D_PAD_I2C1_SDA__GPIO4_IO9	0x40000078>,
+			<MX7D_PAD_I2C1_SCL__GPIO4_IO8	0x40000078>;
+	};
+
 	pinctrl_pmic1: pmic1grp {
 		fsl,pins =
 			<MX7D_PAD_SD2_RESET_B__GPIO5_IO11	0x4000005C>;
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:47 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:47 +0100
Subject: [PATCH 11/23] ARM: dts: imx7-mba7: Add i2c bus recovery
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-12-alexander.stein@ew.tq-group.com>

Add the pin muxing and GPIO settings for SCL/SDA for i2c2 & i2c3.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index e887889816c7..f72fd912e1a6 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -309,8 +309,11 @@ lm75: temperature-sensor at 49 {
 
 &i2c2 {
 	clock-frequency = <100000>;
-	pinctrl-names = "default";
+	pinctrl-names = "default", "gpio";
 	pinctrl-0 = <&pinctrl_i2c2>;
+	pinctrl-1 = <&pinctrl_i2c2_recovery>;
+	scl-gpios = <&gpio4 10 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&gpio4 11 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
 	status = "okay";
 
 	tlv320aic32x4: audio-codec at 18 {
@@ -338,8 +341,11 @@ pca9555: gpio-expander at 20 {
 
 &i2c3 {
 	clock-frequency = <100000>;
-	pinctrl-names = "default";
+	pinctrl-names = "default", "gpio";
 	pinctrl-0 = <&pinctrl_i2c3>;
+	pinctrl-1 = <&pinctrl_i2c3_recovery>;
+	scl-gpios = <&gpio4 12 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&gpio4 13 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
 	status = "okay";
 };
 
@@ -424,12 +430,24 @@ pinctrl_i2c2: i2c2grp {
 			<MX7D_PAD_I2C2_SDA__I2C2_SDA		0x40000078>;
 	};
 
+	pinctrl_i2c2_recovery: i2c2recoverygrp {
+		fsl,pins =
+			<MX7D_PAD_I2C2_SCL__GPIO4_IO10		0x40000078>,
+			<MX7D_PAD_I2C2_SDA__GPIO4_IO11		0x40000078>;
+	};
+
 	pinctrl_i2c3: i2c3grp {
 		fsl,pins =
 			<MX7D_PAD_I2C3_SCL__I2C3_SCL		0x40000078>,
 			<MX7D_PAD_I2C3_SDA__I2C3_SDA		0x40000078>;
 	};
 
+	pinctrl_i2c3_recovery: i2c3recoverygrp {
+		fsl,pins =
+			<MX7D_PAD_I2C3_SCL__GPIO4_IO12		0x40000078>,
+			<MX7D_PAD_I2C3_SDA__GPIO4_IO13		0x40000078>;
+	};
+
 	pinctrl_pca9555: pca95550grp {
 		fsl,pins =
 			<MX7D_PAD_ENET1_TX_CLK__GPIO7_IO12	0x78>;
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:52 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:52 +0100
Subject: [PATCH 16/23] ARM: dts: imx7-tqma7: restrict usdhc interface modes
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-17-alexander.stein@ew.tq-group.com>

USDHC3 is directly connected to an eMMC, so disable other interface modes.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index 53c84393200c..95c0f3139441 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -279,6 +279,8 @@ &usdhc3 {
 	assigned-clock-rates = <400000000>;
 	bus-width = <8>;
 	non-removable;
+	no-sd;
+	no-sdio;
 	vmmc-supply = <&vgen4_reg>;
 	vqmmc-supply = <&sw2_reg>;
 	status = "okay";
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:53 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:53 +0100
Subject: [PATCH 17/23] ARM: dts: imx7-tqma7: remove superfluous status property
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-18-alexander.stein@ew.tq-group.com>

SDMA is enabled by default, so remove the status property.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index 95c0f3139441..f774d74ea20f 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -266,10 +266,6 @@ flash0: flash at 0 {
 	};
 };
 
-&sdma {
-	status = "okay";
-};
-
 &usdhc3 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz";
 	pinctrl-0 = <&pinctrl_usdhc3>;
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:54 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:54 +0100
Subject: [PATCH 18/23] ARM: dts: imx7-tqma7: mark system data eeprom as read-only
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-19-alexander.stein@ew.tq-group.com>

This is manufacturer data and shall not be modified.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index f774d74ea20f..cc02b795b495 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -146,6 +146,7 @@ se97b: temperature-sensor-eeprom at 1e {
 	/* ST M24C64 */
 	m24c64: eeprom at 50 {
 		compatible = "atmel,24c64";
+		read-only;
 		reg = <0x50>;
 		pagesize = <32>;
 		status = "okay";
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:55 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:55 +0100
Subject: [PATCH 19/23] ARM: dts: imx7-tqma7: rename node for SE97BTP
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-20-alexander.stein@ew.tq-group.com>

temperature-sensor is the recommended node name and its main purpose.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index cc02b795b495..14fd9455c162 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -138,7 +138,7 @@ lm75a: temperature-sensor at 48 {
 	};
 
 	/* NXP SE97BTP with temperature sensor + eeprom, TQMa7x 02xx */
-	se97b: temperature-sensor-eeprom at 1e {
+	se97b: temperature-sensor at 1e {
 		compatible = "nxp,se97b", "jedec,jc-42.4-temp";
 		reg = <0x1e>;
 	};
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:56 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:56 +0100
Subject: [PATCH 20/23] ARM: dts: imx7d-mba7: Remove USB OTG related properties on USB node
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-21-alexander.stein@ew.tq-group.com>

These properties are only used on USB OTG/DR devices, remove them from
a host only device.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
index 8f2f3898d9d1..0443faa3dfae 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-mba7.dts
@@ -129,9 +129,6 @@ &usbotg2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usbotg2>;
 	vbus-supply = <&reg_usb_otg2_vbus>;
-	srp-disable;
-	hnp-disable;
-	adp-disable;
 	disable-over-current;
 	dr_mode = "host";
 	status = "okay";
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:57 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:57 +0100
Subject: [PATCH 21/23] ARM: dts: imx7-tqma7: Add missing vcc supply to i2c eeproms
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-22-alexander.stein@ew.tq-group.com>

Fixes the warnings:
at24 0-0050: supply vcc not found, using dummy regulator
at24 0-0056: supply vcc not found, using dummy regulator

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index 14fd9455c162..0cf0304a8db6 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -149,6 +149,7 @@ m24c64: eeprom at 50 {
 		read-only;
 		reg = <0x50>;
 		pagesize = <32>;
+		vcc-supply = <&vgen4_reg>;
 		status = "okay";
 	};
 
@@ -156,6 +157,7 @@ at24c02: eeprom at 56 {
 		compatible = "nxp,se97b", "atmel,24c02";
 		reg = <0x56>;
 		pagesize = <16>;
+		vcc-supply = <&vgen4_reg>;
 		status = "okay";
 	};
 
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:58 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:58 +0100
Subject: [PATCH 22/23] ARM: dts: imx7-mba7: Add missing vcc supply to i2c devices
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-23-alexander.stein@ew.tq-group.com>

Fixes the warnings:
pca953x 1-0020: supply vcc not found, using dummy regulator
lm75 0-0049: supply vs not found, using dummy regulator

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
index 1b1eac33a70f..1235a71c6abe 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-mba7.dtsi
@@ -182,6 +182,14 @@ reg_audio_3v3: regulator-audio-3v3 {
 		regulator-always-on;
 	};
 
+	reg_vcc_3v3: regulator-vcc-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "VCC3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
 	sound {
 		compatible = "fsl,imx-audio-tlv320aic32x4";
 		model = "imx-audio-tlv320aic32x4";
@@ -304,6 +312,7 @@ &i2c1 {
 	lm75: temperature-sensor at 49 {
 		compatible = "national,lm75";
 		reg = <0x49>;
+		vs-supply = <&reg_vcc_3v3>;
 	};
 };
 
@@ -336,6 +345,7 @@ pca9555: gpio-expander at 20 {
 		interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
 		interrupt-controller;
 		#interrupt-cells = <2>;
+		vcc-supply = <&reg_vcc_3v3>;
 	};
 };
 
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Mon Dec 18 04:54:59 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 13:54:59 +0100
Subject: [PATCH 23/23] ARM: dts: imx7-tqma7: Fix PMIC v33 rail voltage range
In-Reply-To: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
References: <20231218125459.2769733-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231218125459.2769733-24-alexander.stein@ew.tq-group.com>

regulator-*-microvolt is not the range the regulator supports, but the
range which the regulator is allowed to configure. Limit v33 rail to
3.3V only.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
index 0cf0304a8db6..028961eb7108 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi
@@ -112,7 +112,7 @@ vgen3_reg: vccsd {
 			};
 
 			vgen4_reg: v33 {
-				regulator-min-microvolt = <2850000>;
+				regulator-min-microvolt = <3300000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-always-on;
 			};
-- 
2.34.1



From linux at armlinux.org.uk  Mon Dec 18 04:58:07 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Mon, 18 Dec 2023 12:58:07 +0000
Subject: [PATCH RFC v3 18/21] ACPI: processor: Only call
 arch_unregister_cpu() if HOTPLUG_CPU is selected
In-Reply-To: <20231215165009.000035f2@Huawei.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOhH-00DvlO-UP@rmk-PC.armlinux.org.uk>
 <20231215165009.000035f2@Huawei.com>
Message-ID: <ZYBB32fMWB6of7Jb@shell.armlinux.org.uk>

On Fri, Dec 15, 2023 at 04:50:09PM +0000, Jonathan Cameron wrote:
> On Wed, 13 Dec 2023 12:50:43 +0000
> Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> 
> > From: James Morse <james.morse at arm.com>
> > 
> > The kbuild robot points out that configurations without HOTPLUG_CPU
> > selected can try to build acpi_processor_post_eject() without success
> > as arch_unregister_cpu() is not defined.
> > 
> > Check this explicitly. This will be merged into:
> > | ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
> > for any subsequent posting.
> > 
> > Reported-by: kbuild test robot <lkp at intel.com>
> > Signed-off-by: James Morse <james.morse at arm.com>
> > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > ---
> > This should probably be squashed into an earlier patch.
> 
> Agreed. If not
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

I'm not convinced that "ACPI: Add post_eject to struct acpi_scan_handler
for cpu hotplug" is the correct commit to squash this into.

As far as acpi_processor.c is concerned, This commit merely renames
acpi_processor_remove() to be acpi_processor_post_eject(). The function
references arch_unregister_cpu() before and after this change, and its
build is dependent on CONFIG_ACPI_HOTPLUG_PRESENT_CPU being defined.

Commit "ACPI: convert acpi_processor_post_eject() to use IS_ENABLED()"
removed the ifdef CONFIG_ACPI_HOTPLUG_PRESENT_CPU surrounding
acpi_processor_post_eject, and that symbol depends on
CONFIG_HOTPLUG_CPU, so I think this commit is also fine.

Commit "ACPI: Check _STA present bit before making CPUs not present"
rewrites the function - the original body gets called
acpi_processor_make_not_present() and a new acpi_processor_post_eject()
is created. At this point, it doesn't reference arch_unregister_cpu().

Commit "ACPI: add support to register CPUs based on the _STA enabled
bit" adds a reference to arch_unregister_cpu() in this new
acpi_processor_post_eject() - so I think this is the correct commit
this change should be merged into.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From u.kleine-koenig at pengutronix.de  Mon Dec 18 05:01:41 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 18 Dec 2023 14:01:41 +0100
Subject: [PATCH 1/2] clk: Add a devm variant of clk_rate_exclusive_get()
In-Reply-To: <5391068cdc86b6117920d31a524d934b.sboyd@kernel.org>
References: <cover.1702403904.git.u.kleine-koenig@pengutronix.de>
 <744a6371f94fe96f527eea6e52a600914e6fb6b5.1702403904.git.u.kleine-koenig@pengutronix.de>
 <5391068cdc86b6117920d31a524d934b.sboyd@kernel.org>
Message-ID: <3fhgutm42b6sy6gdydcvflnsjuc2ozjetjbeyoxjvnl2t5q7za@4og2x6gqz5y2>

[Cc += Maxime]

Hello Stephen,

On Sun, Dec 17, 2023 at 04:17:41PM -0800, Stephen Boyd wrote:
> Quoting Uwe Kleine-K?nig (2023-12-12 10:09:42)
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index af2011c2a93b..78249ca2341c 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -937,6 +937,21 @@ void clk_rate_exclusive_get(struct clk *clk)
> >  }
> >  EXPORT_SYMBOL_GPL(clk_rate_exclusive_get);
> >  
> > +static void devm_clk_rate_exclusive_put(void *data)
> > +{
> > +       struct clk *clk = data;
> > +
> > +       clk_rate_exclusive_put(clk);
> > +}
> > +
> > +int devm_clk_rate_exclusive_get(struct device *dev, struct clk *clk)
> > +{
> > +       clk_rate_exclusive_get(clk);
> 
> It seems the other thread wants this to return an error value.

The status quo is that clk_rate_exclusive_get() always returns zero.
Some users do error handling (which is dead code until Maxime reworks
the call that it might return something non-zero), others just call it
without checking.

If you don't require to add something like:

	ret = clk_rate_exclusive_get(clk);
	if (ret)
		return ret;

where we currently have just

	clk_rate_exclusive_get(clk);

the patch can just be applied (using git am -3) not even hitting a merge
conflict without that other series.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/aaf6ba73/attachment-0001.sig>

From linux at armlinux.org.uk  Mon Dec 18 05:03:32 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Mon, 18 Dec 2023 13:03:32 +0000
Subject: [PATCH RFC v3 17/21] ACPI: add support to register CPUs based on
 the _STA enabled bit
In-Reply-To: <E1rDOhC-00DvlI-Pp@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOhC-00DvlI-Pp@rmk-PC.armlinux.org.uk>
Message-ID: <ZYBDJG1g7SH7AiM1@shell.armlinux.org.uk>

On Wed, Dec 13, 2023 at 12:50:38PM +0000, Russell King wrote:
> From: James Morse <james.morse at arm.com>
> 
> acpi_processor_get_info() registers all present CPUs. Registering a
> CPU is what creates the sysfs entries and triggers the udev
> notifications.
> 
> arm64 virtual machines that support 'virtual cpu hotplug' use the
> enabled bit to indicate whether the CPU can be brought online, as
> the existing ACPI tables require all hardware to be described and
> present.
> 
> If firmware describes a CPU as present, but disabled, skip the
> registration. Such CPUs are present, but can't be brought online for
> whatever reason. (e.g. firmware/hypervisor policy).
> 
> Once firmware sets the enabled bit, the CPU can be registered and
> brought online by user-space. Online CPUs, or CPUs that are missing
> an _STA method must always be registered.

...

> @@ -526,6 +552,9 @@ static void acpi_processor_post_eject(struct acpi_device *device)
>  		acpi_processor_make_not_present(device);
>  		return;
>  	}
> +
> +	if (cpu_present(pr->id) && !(sta & ACPI_STA_DEVICE_ENABLED))
> +		arch_unregister_cpu(pr->id);

This change isn't described in the commit log, but seems to be the cause
of the build error identified by the kernel build bot that is fixed
later in this series. I'm wondering whether this should be in a
different patch, maybe "ACPI: Check _STA present bit before making CPUs
not present" ?

Or maybe my brain isn't working properly (due to being Covid positive.)
Any thoughts, Jonathan?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From wahrenst at gmx.net  Mon Dec 18 05:06:55 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Mon, 18 Dec 2023 14:06:55 +0100
Subject: [PATCH 1/2] dt-bindings: mtd: partitions: u-boot: Fix typo
Message-ID: <20231218130656.9020-1-wahrenst@gmx.net>

The initial description contained a typo.

Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
 Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml b/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml
index 3c56efe48efd..327fa872c001 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: U-Boot bootloader partition

 description: |
-  U-Boot is a bootlodaer commonly used in embedded devices. It's almost always
+  U-Boot is a bootloader commonly used in embedded devices. It's almost always
   located on some kind of flash device.

   Device configuration is stored as a set of environment variables that are
--
2.34.1



From wahrenst at gmx.net  Mon Dec 18 05:06:56 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Mon, 18 Dec 2023 14:06:56 +0100
Subject: [PATCH RFT 2/2] ARM: dts: mxs: imx28: Fix NAND hierarchy description
In-Reply-To: <20231218130656.9020-1-wahrenst@gmx.net>
References: <20231218130656.9020-1-wahrenst@gmx.net>
Message-ID: <20231218130656.9020-2-wahrenst@gmx.net>

The size-cells for GPMI are wrong in imx28.dtsi, which causes the
following warning:

    nand-controller at 8000c000: #size-cells:0:0: 0 was expected

The reason for this is the definition of the partitions directly
below the nand controller node. According to nand-controller.yaml
the NAND chip must be defined as a child of the controller. Even
the fixed partitions must be kept in a partitions container.

Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---

Hi,
unfortunately i don't have access to MSR M28CU3 or an Armadeus Systems APF28
so it would be nice if someone can give a try.

 arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts  | 64 +++++++++++++---------
 arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi   |  2 -
 arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts | 28 ++++++----
 arch/arm/boot/dts/nxp/mxs/imx28.dtsi       |  2 +-
 4 files changed, 56 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts b/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts
index 98672932e41b..10bfac31f672 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts
+++ b/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts
@@ -27,39 +27,49 @@ &gpmi {
 	pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
 	status = "okay";

-	partition at 0 {
-		label = "u-boot";
-		reg = <0x0 0x300000>;
-	};
+	nand at 0 {
+		reg = <0>;

-	partition at 300000 {
-		label = "env";
-		reg = <0x300000 0x80000>;
-	};
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;

-	partition at 380000 {
-		label = "env2";
-		reg = <0x380000 0x80000>;
-	};
+			partition at 0 {
+				label = "u-boot";
+				reg = <0x0 0x300000>;
+			};

-	partition at 400000 {
-		label = "dtb";
-		reg = <0x400000 0x80000>;
-	};
+			partition at 300000 {
+				label = "env";
+				reg = <0x300000 0x80000>;
+			};

-	partition at 480000 {
-		label = "splash";
-		reg = <0x480000 0x80000>;
-	};
+			partition at 380000 {
+				label = "env2";
+				reg = <0x380000 0x80000>;
+			};

-	partition at 500000 {
-		label = "kernel";
-		reg = <0x500000 0x800000>;
-	};
+			partition at 400000 {
+				label = "dtb";
+				reg = <0x400000 0x80000>;
+			};
+
+			partition at 480000 {
+				label = "splash";
+				reg = <0x480000 0x80000>;
+			};
+
+			partition at 500000 {
+				label = "kernel";
+				reg = <0x500000 0x800000>;
+			};

-	partition at d00000 {
-		label = "rootfs";
-		reg = <0xd00000 0xf300000>;
+			partition at d00000 {
+				label = "rootfs";
+				reg = <0xd00000 0xf300000>;
+			};
+		};
 	};
 };

diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi b/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi
index 66facef10ba9..54b0f715f091 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi
+++ b/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi
@@ -24,8 +24,6 @@ reg_3p3v: regulator-0 {
 };

 &gpmi {
-	#address-cells = <1>;
-	#size-cells = <1>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts b/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts
index 34b4d3246db1..d069ac907490 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts
+++ b/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts
@@ -93,21 +93,29 @@ &duart {
 };

 &gpmi {
-	#address-cells = <1>;
-	#size-cells = <1>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
 	status = "okay";

-	partition at 0 {
-		label = "gpmi-nfc-0-boot";
-		reg = <0x00000000 0x01400000>;
-		read-only;
-	};
+	nand at 0 {
+		reg = <0>;

-	partition at 1 {
-		label = "gpmi-nfc-general-use";
-		reg = <0x01400000 0x0ec00000>;
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition at 0 {
+				label = "gpmi-nfc-0-boot";
+				reg = <0x00000000 0x01400000>;
+				read-only;
+			};
+
+			partition at 1 {
+				label = "gpmi-nfc-general-use";
+				reg = <0x01400000 0x0ec00000>;
+			};
+		};
 	};
 };

diff --git a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
index 4817fba2d938..9655403b7f90 100644
--- a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
+++ b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
@@ -99,7 +99,7 @@ perfmon: perfmon at 80006000 {
 			gpmi: nand-controller at 8000c000 {
 				compatible = "fsl,imx28-gpmi-nand";
 				#address-cells = <1>;
-				#size-cells = <1>;
+				#size-cells = <0>;
 				reg = <0x8000c000 0x2000>, <0x8000a000 0x2000>;
 				reg-names = "gpmi-nand", "bch";
 				interrupts = <41>;
--
2.34.1



From mripard at kernel.org  Mon Dec 18 05:13:06 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Mon, 18 Dec 2023 14:13:06 +0100
Subject: [PATCH v2 20/27] drm/rockchip: inno_hdmi: Correctly setup HDMI
 quantization range
In-Reply-To: <c58b97ca-3faa-4bf2-8d7c-7ff34e0428ca@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-21-knaerzche@gmail.com>
 <rrtknir3vizvcyamp3kfy47r6uppn3wwevb6a5gln2k533t52z@otm6vum6pg43>
 <c58b97ca-3faa-4bf2-8d7c-7ff34e0428ca@gmail.com>
Message-ID: <tceu6ks2twjowohui3tpik7fhgplua6zv22je4ikihugccqb7w@whq7zgvbh3tl>

On Mon, Dec 18, 2023 at 01:37:47PM +0100, Alex Bee wrote:
> 
> Am 18.12.23 um 10:05 schrieb Maxime Ripard:
> > On Sat, Dec 16, 2023 at 05:26:31PM +0100, Alex Bee wrote:
> > > @@ -431,6 +452,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
> > >   	else
> > >   		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
> > > +	inno_conn_state->rgb_limited_range =
> > > +		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
> > > +
> > >   	/* Mute video and audio output */
> > >   	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
> > >   		  v_AUDIO_MUTE(1) | v_VIDEO_MUTE(1));
> > This needs to be done at atomic_check time: the expectation is that by
> > the time you commit the state, everything is prepared for it.
> OK. I guess that also applies to the other members of
> inno_hdmi_connector_state (former hdmi_data) and was wrong all the time.

Yeah, this will apply to all the members of inno_hdmi_connector_state indeed

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/4d9a4639/attachment-0001.sig>

From rafael at kernel.org  Mon Dec 18 05:14:30 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 18 Dec 2023 14:14:30 +0100
Subject: [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields
In-Reply-To: <ZYAPhlwPUT/7dN4n@lpieralisi>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk> <E1rDOgs-00Dvko-6t@rmk-PC.armlinux.org.uk>
 <20231215162322.00007391@Huawei.com> <ZXyEiHLFBsoUkfNI@shell.armlinux.org.uk> <ZYAPhlwPUT/7dN4n@lpieralisi>
Message-ID: <CAJZ5v0hyUqJspPbGTgTMSVHVBe=wHR6swPx-O3UcsH5dXDFpTA@mail.gmail.com>

On Mon, Dec 18, 2023 at 10:23?AM Lorenzo Pieralisi
<lpieralisi at kernel.org> wrote:
>
> On Fri, Dec 15, 2023 at 04:53:28PM +0000, Russell King (Oracle) wrote:
> > On Fri, Dec 15, 2023 at 04:23:22PM +0000, Jonathan Cameron wrote:
> > > On Wed, 13 Dec 2023 12:50:18 +0000
> > > Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> > >
> > > > From: James Morse <james.morse at arm.com>
> > > >
> > > > Add the new flag field to the MADT's GICC structure.
> > > >
> > > > 'Online Capable' indicates a disabled CPU can be enabled later. See
> > > > ACPI specification 6.5 Tabel 5.37: GICC CPU Interface Flags.
> > > >
> > > > Signed-off-by: James Morse <james.morse at arm.com>
> > > > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > > > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > > > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > > > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > >
> > > I see there is an acpica pull request including this bit but with a different name
> > > For reference.
> > > https://github.com/acpica/acpica/pull/914/commits/453a5f67567786522021d5f6913f561f8b3cabf6
> > >
> > > +CC Lorenzo who submitted that.
> >
> > > > +#define ACPI_MADT_GICC_CPU_CAPABLE      (1<<3)   /* 03: CPU is online capable */
> > >
> > > ACPI_MADT_GICC_ONLINE_CAPABLE
> >
> > It's somewhat disappointing, but no big deal. It's easy enough to change
> > "irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs"
> > to use Lorenzo's name when that patch hits - and it becomes one less
> > patch in this patch set when Lorenzo's change eventually hits mainline.
> >
> > Does anyone know how long it may take for Lorenzo's change to get into
> > mainline? Would it be by the 6.8 merge window or the following one?
>
> I wish I knew. I submitted ACPICA changes for the online capable bit
> since I had to add additional flags on top (ie DMA coherent) and it
> would not make sense to submit the latter without the former.
>
> I'd be great if the ACPICA headers can make it into Linux for the upcoming
> merge window, not sure what I can do to fasttrack the process though
> (I shall ping the maintainers).

If your upstream pull request has been merged, I can pick up Linux
patches carrying Link: tags pointing to the upstream ACPICA commits in
that pull request.

Thanks!


From frank at oltmanns.dev  Mon Dec 18 05:35:19 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Mon, 18 Dec 2023 14:35:19 +0100
Subject: [PATCH 1/5] clk: sunxi-ng: nkm: Support constraints on m/n ratio
 and parent rate
In-Reply-To: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
Message-ID: <20231218-pinephone-pll-fixes-v1-1-e238b6ed6dc1@oltmanns.dev>

The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
 - M/N >= 3
 - (PLL_VIDEO0)/M >= 24MHz

The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
these constraints.

Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
---
 drivers/clk/sunxi-ng/ccu_nkm.c | 23 +++++++++++++++++++++++
 drivers/clk/sunxi-ng/ccu_nkm.h |  8 ++++++++
 2 files changed, 31 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
index eed64547ad42..2af5c1ebd527 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.c
+++ b/drivers/clk/sunxi-ng/ccu_nkm.c
@@ -16,6 +16,20 @@ struct _ccu_nkm {
 	unsigned long	m, min_m, max_m;
 };
 
+static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long parent,
+				  unsigned long n, unsigned long m)
+{
+	struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
+
+	if (nkm->max_mn_ratio && (m > nkm->max_mn_ratio * n))
+		return false;
+
+	if (nkm->parent_wo_nk && (parent < nkm->parent_wo_nk * m))
+		return false;
+
+	return true;
+}
+
 static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common,
 						       struct clk_hw *parent_hw,
 						       unsigned long *parent, unsigned long rate,
@@ -32,6 +46,9 @@ static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
 
 				tmp_parent = clk_hw_round_rate(parent_hw, rate * _m / (_n * _k));
 
+				if (!ccu_nkm_is_valid_rate(common, tmp_parent, _n, _m))
+					continue;
+
 				tmp_rate = tmp_parent * _n * _k / _m;
 
 				if (ccu_is_better_rate(common, rate, tmp_rate, best_rate) ||
@@ -65,6 +82,12 @@ static unsigned long ccu_nkm_find_best(unsigned long parent, unsigned long rate,
 	for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
 		for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
 			for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
+				if ((common->reg == 0x040) && (_m > 3 * _n))
+					break;
+
+				if ((common->reg == 0x040) && (parent < 24000000 * _m))
+					continue;
+
 				unsigned long tmp_rate;
 
 				tmp_rate = parent * _n * _k / _m;
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
index 6601defb3f38..d3d3eaf55faf 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.h
+++ b/drivers/clk/sunxi-ng/ccu_nkm.h
@@ -16,6 +16,12 @@
  * struct ccu_nkm - Definition of an N-K-M clock
  *
  * Clocks based on the formula parent * N * K / M
+ *
+ * @max_mn_ratio:	Maximum value for M / N.
+ * @parent_wo_nk:	The minimum rate the parent must provide after applying the divisor,
+ *			but without applying the multipliers, i.e. the contstraint
+ *			   (parent rate)/M >= parent_wo_nk
+ *			must be fulfilled.
  */
 struct ccu_nkm {
 	u32			enable;
@@ -27,6 +33,8 @@ struct ccu_nkm {
 	struct ccu_mux_internal	mux;
 
 	unsigned int		fixed_post_div;
+	unsigned long		max_mn_ratio;
+	unsigned long           parent_wo_nk;
 
 	struct ccu_common	common;
 };

-- 
2.43.0



From frank at oltmanns.dev  Mon Dec 18 05:35:21 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Mon, 18 Dec 2023 14:35:21 +0100
Subject: [PATCH 3/5] clk: sunxi-ng: nm: Support constraints on n/m ratio
 and parent rate
In-Reply-To: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
Message-ID: <20231218-pinephone-pll-fixes-v1-3-e238b6ed6dc1@oltmanns.dev>

The Allwinner A64 manual lists the following constraint for the
PLL-VIDEO0 clock: 8 <= N/M <= 25

The PLL-MIPI clock is implemented as ccu_nm. Therefore, add support for
this constraint.

Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
---
 drivers/clk/sunxi-ng/ccu_nm.c | 21 +++++++++++++++++++--
 drivers/clk/sunxi-ng/ccu_nm.h | 34 ++++++++++++++++++++++++++++++++--
 2 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
index ffac3deb89d6..cfc6981e398b 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.c
+++ b/drivers/clk/sunxi-ng/ccu_nm.c
@@ -27,6 +27,19 @@ static unsigned long ccu_nm_calc_rate(unsigned long parent,
 	return rate;
 }
 
+static bool ccu_nm_is_valid_rate(struct ccu_common *common, unsigned long n, unsigned long m)
+{
+	struct ccu_nm *nm = container_of(common, struct ccu_nm, common);
+
+	if (nm->max_nm_ratio && (n > nm->max_nm_ratio * m))
+		return false;
+
+	if (nm->min_nm_ratio && (n < nm->min_nm_ratio * m))
+		return false;
+
+	return true;
+}
+
 static unsigned long ccu_nm_find_best(struct ccu_common *common, unsigned long parent,
 				      unsigned long rate, struct _ccu_nm *nm)
 {
@@ -36,8 +49,12 @@ static unsigned long ccu_nm_find_best(struct ccu_common *common, unsigned long p
 
 	for (_n = nm->min_n; _n <= nm->max_n; _n++) {
 		for (_m = nm->min_m; _m <= nm->max_m; _m++) {
-			unsigned long tmp_rate = ccu_nm_calc_rate(parent,
-								  _n, _m);
+			unsigned long tmp_rate;
+
+			if (!ccu_nm_is_valid_rate(common, _n, _m))
+				continue;
+
+			tmp_rate = ccu_nm_calc_rate(parent, _n, _m);
 
 			if (ccu_is_better_rate(common, rate, tmp_rate, best_rate)) {
 				best_rate = tmp_rate;
diff --git a/drivers/clk/sunxi-ng/ccu_nm.h b/drivers/clk/sunxi-ng/ccu_nm.h
index 93c11693574f..0075df6d9697 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.h
+++ b/drivers/clk/sunxi-ng/ccu_nm.h
@@ -31,6 +31,8 @@ struct ccu_nm {
 	unsigned int		fixed_post_div;
 	unsigned int		min_rate;
 	unsigned int		max_rate;
+	unsigned long		min_nm_ratio; /* minimum value for m/n */
+	unsigned long		max_nm_ratio; /* maximum value for m/n */
 
 	struct ccu_common	common;
 };
@@ -108,7 +110,8 @@ struct ccu_nm {
 		},							\
 	}
 
-#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT(_struct, _name,	\
+#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(		\
+						 _struct, _name,	\
 						 _parent, _reg,		\
 						 _min_rate, _max_rate,	\
 						 _nshift, _nwidth,	\
@@ -117,7 +120,9 @@ struct ccu_nm {
 						 _frac_rate_0,		\
 						 _frac_rate_1,		\
 						 _gate, _lock, _flags,	\
-						 _features)		\
+						 _features,		\
+						 _min_nm_ratio,		\
+						 _max_nm_ratio)		\
 	struct ccu_nm _struct = {					\
 		.enable		= _gate,				\
 		.lock		= _lock,				\
@@ -128,6 +133,8 @@ struct ccu_nm {
 						  _frac_rate_1),	\
 		.min_rate	= _min_rate,				\
 		.max_rate	= _max_rate,				\
+		.min_nm_ratio	= _min_nm_ratio,			\
+		.max_nm_ratio	= _max_nm_ratio,			\
 		.common		= {					\
 			.reg		= _reg,				\
 			.features	= _features,			\
@@ -138,6 +145,29 @@ struct ccu_nm {
 		},							\
 	}
 
+#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT(_struct, _name,	\
+						 _parent, _reg,		\
+						 _min_rate, _max_rate,	\
+						 _nshift, _nwidth,	\
+						 _mshift, _mwidth,	\
+						 _frac_en, _frac_sel,	\
+						 _frac_rate_0,		\
+						 _frac_rate_1,		\
+						 _gate, _lock, _flags,	\
+						 _features)		\
+	SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(		\
+						_struct, _name,		\
+						_parent, _reg,		\
+						_min_rate, _max_rate,	\
+						_nshift, _nwidth,	\
+						_mshift, _mwidth,	\
+						_frac_en, _frac_sel,	\
+						_frac_rate_0,		\
+						_frac_rate_1,		\
+						_gate, _lock, _flags,	\
+						_features,		\
+						0, 0)
+
 #define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX(_struct, _name,	\
 						 _parent, _reg,		\
 						 _min_rate, _max_rate,	\

-- 
2.43.0



From frank at oltmanns.dev  Mon Dec 18 05:35:18 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Mon, 18 Dec 2023 14:35:18 +0100
Subject: [PATCH 0/5] Pinephone video out fixes (flipping between two
 frames)
Message-ID: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>

On some pinephones the video output sometimes freezes (flips between two
frames) [1]. It seems to be that the reason for this behaviour is that
PLL-MIPI and PLL-VIDEO0 are operating outside there specified limits.

The changes I propose in this patch series consists of two major parts:
  1. sunxi-ng: Adhere to the following constraints given in the
     Allwinner A64 Manual:
      a. PLL-MIPI:
          * M/N >= 3
          * (PLL_VIDEO0)/M >= 24MHz
      b. PLL-VIDEO0:
          * 8 <= N/M <= 25

  2. Choose a higher clock rate for the ST7703 based XDB599 panel, so
     that the panel functions with the Allwinner A64 SOC. PLL-MIPI
     must run between 500 MHz and 1.4 GHz. As PLL-MIPI runs at 6 times
     the panel's clock rate, we need its clock to be at least 83.333
     MHz.

So far, I've tested the patches only on my pinephone. Before the patches
it would freeze at least every other day. With the patches it has not
shown this behavior in over a week.

I very much appreciate your feedback!

[1] https://gitlab.com/postmarketOS/pmaports/-/issues/805

Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
---
Frank Oltmanns (5):
      clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate
      clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent rate
      clk: sunxi-ng: nm: Support constraints on n/m ratio and parent rate
      clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's n/m ratio
      drm/panel: st7703: Drive XBD599 panel at higher clock rate

 drivers/clk/sunxi-ng/ccu-sun50i-a64.c         | 10 ++++++--
 drivers/clk/sunxi-ng/ccu_nkm.c                | 23 ++++++++++++++++++
 drivers/clk/sunxi-ng/ccu_nkm.h                |  8 +++++++
 drivers/clk/sunxi-ng/ccu_nm.c                 | 21 +++++++++++++++--
 drivers/clk/sunxi-ng/ccu_nm.h                 | 34 +++++++++++++++++++++++++--
 drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++------
 6 files changed, 97 insertions(+), 13 deletions(-)
---
base-commit: d0ac5722dae5f4302bb4ef6df10d0afa718df80b
change-id: 20231218-pinephone-pll-fixes-0ccdfde273e4

Best regards,
-- 
Frank Oltmanns <frank at oltmanns.dev>



From frank at oltmanns.dev  Mon Dec 18 05:35:22 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Mon, 18 Dec 2023 14:35:22 +0100
Subject: [PATCH 4/5] clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's
 n/m ratio
In-Reply-To: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
Message-ID: <20231218-pinephone-pll-fixes-v1-4-e238b6ed6dc1@oltmanns.dev>

The Allwinner A64 manual lists the following constraint for the
PLL-VIDEO0 clock: 8 <= N/M <= 25

Use this constraint.

Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index c034ac027d1c..75d839da446c 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -68,7 +68,8 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
 				       BIT(28),	/* lock */
 				       CLK_SET_RATE_UNGATE);
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-video0",
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(pll_video0_clk,
+						"pll-video0",
 						"osc24M", 0x010,
 						192000000,	/* Minimum rate */
 						1008000000,	/* Maximum rate */
@@ -80,7 +81,10 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-vid
 						297000000,	/* frac rate 1 */
 						BIT(31),	/* gate */
 						BIT(28),	/* lock */
-						CLK_SET_RATE_UNGATE);
+						CLK_SET_RATE_UNGATE,
+						CCU_FEATURE_FRACTIONAL |
+						CCU_FEATURE_CLOSEST_RATE,
+						8, 25);		/* min/max nm ratio */
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
 					"osc24M", 0x018,

-- 
2.43.0



From frank at oltmanns.dev  Mon Dec 18 05:35:20 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Mon, 18 Dec 2023 14:35:20 +0100
Subject: [PATCH 2/5] clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m
 ratio and parent rate
In-Reply-To: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
Message-ID: <20231218-pinephone-pll-fixes-v1-2-e238b6ed6dc1@oltmanns.dev>

The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
 - M/N >= 3
 - (PLL_VIDEO0)/M >= 24MHz

Use these constraints.

Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 8951ffc14ff5..c034ac027d1c 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -176,6 +176,8 @@ static struct ccu_nkm pll_mipi_clk = {
 	.n		= _SUNXI_CCU_MULT(8, 4),
 	.k		= _SUNXI_CCU_MULT_MIN(4, 2, 2),
 	.m		= _SUNXI_CCU_DIV(0, 4),
+	.max_mn_ratio	= 3,
+	.parent_wo_nk	= 24000000,
 	.common		= {
 		.reg		= 0x040,
 		.hw.init	= CLK_HW_INIT("pll-mipi", "pll-video0",

-- 
2.43.0



From frank at oltmanns.dev  Mon Dec 18 05:35:23 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Mon, 18 Dec 2023 14:35:23 +0100
Subject: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock
 rate
In-Reply-To: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
Message-ID: <20231218-pinephone-pll-fixes-v1-5-e238b6ed6dc1@oltmanns.dev>

This panel is used in the pinephone that runs on a Allwinner A64 SOC.
Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
than 500 MHz.

Therefore, change [hv]sync_(start|end) so that we reach a clock rate
that is high enough to drive PLL-MIPI within its limits.

Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
---
 drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index b55bafd1a8be..6886fd7f765e 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
 
 static const struct drm_display_mode xbd599_mode = {
 	.hdisplay    = 720,
-	.hsync_start = 720 + 40,
-	.hsync_end   = 720 + 40 + 40,
-	.htotal	     = 720 + 40 + 40 + 40,
+	.hsync_start = 720 + 65,
+	.hsync_end   = 720 + 65 + 65,
+	.htotal      = 720 + 65 + 65 + 65,
 	.vdisplay    = 1440,
-	.vsync_start = 1440 + 18,
-	.vsync_end   = 1440 + 18 + 10,
-	.vtotal	     = 1440 + 18 + 10 + 17,
-	.clock	     = 69000,
+	.vsync_start = 1440 + 30,
+	.vsync_end   = 1440 + 30 + 22,
+	.vtotal	     = 1440 + 30 + 22 + 29,
+	.clock	     = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
 	.flags	     = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
 	.width_mm    = 68,
 	.height_mm   = 136,

-- 
2.43.0



From zajec5 at gmail.com  Mon Dec 18 05:37:20 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon, 18 Dec 2023 14:37:20 +0100
Subject: [PATCH 2/4] nvmem: core: add nvmem_dev_size() helper
In-Reply-To: <20231218133722.16150-1-zajec5@gmail.com>
References: <20231218133722.16150-1-zajec5@gmail.com>
Message-ID: <20231218133722.16150-2-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This is required by layouts that need to read whole NVMEM content. It's
especially useful for NVMEM devices without hardcoded layout (like
U-Boot environment data block).

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 drivers/nvmem/core.c           | 13 +++++++++++++
 include/linux/nvmem-consumer.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index ba559e81f77f..1b08bb072f86 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -2176,6 +2176,19 @@ const char *nvmem_dev_name(struct nvmem_device *nvmem)
 }
 EXPORT_SYMBOL_GPL(nvmem_dev_name);
 
+/**
+ * nvmem_dev_size() - Get the size of a given nvmem device.
+ *
+ * @nvmem: nvmem device.
+ *
+ * Return: size of the nvmem device.
+ */
+size_t nvmem_dev_size(struct nvmem_device *nvmem)
+{
+	return nvmem->size;
+}
+EXPORT_SYMBOL_GPL(nvmem_dev_size);
+
 static int __init nvmem_init(void)
 {
 	int ret;
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 2d306fa13b1a..34c0e58dfa26 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -81,6 +81,7 @@ int nvmem_device_cell_write(struct nvmem_device *nvmem,
 			    struct nvmem_cell_info *info, void *buf);
 
 const char *nvmem_dev_name(struct nvmem_device *nvmem);
+size_t nvmem_dev_size(struct nvmem_device *nvmem);
 
 void nvmem_add_cell_lookups(struct nvmem_cell_lookup *entries,
 			    size_t nentries);
-- 
2.35.3



From zajec5 at gmail.com  Mon Dec 18 05:37:22 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon, 18 Dec 2023 14:37:22 +0100
Subject: [PATCH 4/4] nvmem: layouts: add U-Boot env layout
In-Reply-To: <20231218133722.16150-1-zajec5@gmail.com>
References: <20231218133722.16150-1-zajec5@gmail.com>
Message-ID: <20231218133722.16150-4-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This patch moves all generic (NVMEM devices independent) code from NVMEM
device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
code on top of it.

Thanks to proper layout it's possible to support U-Boot env data stored
on any kind of NVMEM device.

For backward compatibility with old DT bindings we need to keep old
NVMEM device driver functional. To avoid code duplication a parsing
function is exported and reused in it.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 MAINTAINERS                        |   1 +
 drivers/nvmem/Kconfig              |   3 +-
 drivers/nvmem/layouts/Kconfig      |  11 ++
 drivers/nvmem/layouts/Makefile     |   1 +
 drivers/nvmem/layouts/u-boot-env.c | 212 +++++++++++++++++++++++++++++
 drivers/nvmem/layouts/u-boot-env.h |  15 ++
 drivers/nvmem/u-boot-env.c         | 155 +--------------------
 7 files changed, 243 insertions(+), 155 deletions(-)
 create mode 100644 drivers/nvmem/layouts/u-boot-env.c
 create mode 100644 drivers/nvmem/layouts/u-boot-env.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b589218605b4..1f7e6d74cd51 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22282,6 +22282,7 @@ U-BOOT ENVIRONMENT VARIABLES
 M:	Rafa? Mi?ecki <rafal at milecki.pl>
 S:	Maintained
 F:	Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+F:	drivers/nvmem/layouts/u-boot-env.c
 F:	drivers/nvmem/u-boot-env.c
 
 UACCE ACCELERATOR FRAMEWORK
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 283134498fbc..d2c384f58028 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -363,8 +363,7 @@ config NVMEM_SUNXI_SID
 config NVMEM_U_BOOT_ENV
 	tristate "U-Boot environment variables support"
 	depends on OF && MTD
-	select CRC32
-	select GENERIC_NET_UTILS
+	select NVMEM_LAYOUT_U_BOOT_ENV
 	help
 	  U-Boot stores its setup as environment variables. This driver adds
 	  support for verifying & exporting such data. It also exposes variables
diff --git a/drivers/nvmem/layouts/Kconfig b/drivers/nvmem/layouts/Kconfig
index 9c6e672fc350..5e586dfebe47 100644
--- a/drivers/nvmem/layouts/Kconfig
+++ b/drivers/nvmem/layouts/Kconfig
@@ -26,6 +26,17 @@ config NVMEM_LAYOUT_ONIE_TLV
 
 	  If unsure, say N.
 
+config NVMEM_LAYOUT_U_BOOT_ENV
+	tristate "U-Boot environment variables layout"
+	select CRC32
+	select GENERIC_NET_UTILS
+	help
+	  U-Boot stores its setup as environment variables. This driver adds
+	  support for verifying & exporting such data. It also exposes variables
+	  as NVMEM cells so they can be referenced by other drivers.
+
+	  If unsure, say N.
+
 endmenu
 
 endif
diff --git a/drivers/nvmem/layouts/Makefile b/drivers/nvmem/layouts/Makefile
index 2974bd7d33ed..4940c9db0665 100644
--- a/drivers/nvmem/layouts/Makefile
+++ b/drivers/nvmem/layouts/Makefile
@@ -5,3 +5,4 @@
 
 obj-$(CONFIG_NVMEM_LAYOUT_SL28_VPD) += sl28vpd.o
 obj-$(CONFIG_NVMEM_LAYOUT_ONIE_TLV) += onie-tlv.o
+obj-$(CONFIG_NVMEM_LAYOUT_U_BOOT_ENV) += u-boot-env.o
diff --git a/drivers/nvmem/layouts/u-boot-env.c b/drivers/nvmem/layouts/u-boot-env.c
new file mode 100644
index 000000000000..1787cfaf45f8
--- /dev/null
+++ b/drivers/nvmem/layouts/u-boot-env.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 - 2023 Rafa? Mi?ecki <rafal at milecki.pl>
+ */
+
+#include <linux/crc32.h>
+#include <linux/etherdevice.h>
+#include <linux/export.h>
+#include <linux/if_ether.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+#include "u-boot-env.h"
+
+struct u_boot_env_image_single {
+	__le32 crc32;
+	uint8_t data[];
+} __packed;
+
+struct u_boot_env_image_redundant {
+	__le32 crc32;
+	u8 mark;
+	uint8_t data[];
+} __packed;
+
+struct u_boot_env_image_broadcom {
+	__le32 magic;
+	__le32 len;
+	__le32 crc32;
+	DECLARE_FLEX_ARRAY(uint8_t, data);
+} __packed;
+
+static const struct of_device_id u_boot_env_of_match_table[] = {
+	{ .compatible = "u-boot,env", .data = (void *)U_BOOT_FORMAT_SINGLE, },
+	{ .compatible = "u-boot,env-redundant-bool", .data = (void *)U_BOOT_FORMAT_REDUNDANT, },
+	{ .compatible = "u-boot,env-redundant-count", .data = (void *)U_BOOT_FORMAT_REDUNDANT, },
+	{ .compatible = "brcm,env", .data = (void *)U_BOOT_FORMAT_BROADCOM, },
+	{},
+};
+
+static int u_boot_env_read_post_process_ethaddr(void *context, const char *id, int index,
+						unsigned int offset, void *buf, size_t bytes)
+{
+	u8 mac[ETH_ALEN];
+
+	if (bytes != 3 * ETH_ALEN - 1)
+		return -EINVAL;
+
+	if (!mac_pton(buf, mac))
+		return -EINVAL;
+
+	if (index)
+		eth_addr_add(mac, index);
+
+	ether_addr_copy(buf, mac);
+
+	return 0;
+}
+
+static int u_boot_env_parse_cells(struct device *dev, struct nvmem_device *nvmem, uint8_t *buf,
+				  size_t data_offset, size_t data_len)
+{
+	char *data = buf + data_offset;
+	char *var, *value, *eq;
+
+	for (var = data;
+	     var < data + data_len && *var;
+	     var = value + strlen(value) + 1) {
+		struct nvmem_cell_info info = {};
+
+		eq = strchr(var, '=');
+		if (!eq)
+			break;
+		*eq = '\0';
+		value = eq + 1;
+
+		info.name = devm_kstrdup(dev, var, GFP_KERNEL);
+		if (!info.name)
+			return -ENOMEM;
+		info.offset = data_offset + value - data;
+		info.bytes = strlen(value);
+		info.np = of_get_child_by_name(dev->of_node, info.name);
+		if (!strcmp(var, "ethaddr")) {
+			info.raw_len = strlen(value);
+			info.bytes = ETH_ALEN;
+			info.read_post_process = u_boot_env_read_post_process_ethaddr;
+		}
+
+		nvmem_add_one_cell(nvmem, &info);
+	}
+
+	return 0;
+}
+
+int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
+		     enum u_boot_env_format format)
+{
+	size_t crc32_data_offset;
+	size_t crc32_data_len;
+	size_t crc32_offset;
+	size_t data_offset;
+	size_t data_len;
+	size_t dev_size;
+	uint32_t crc32;
+	uint32_t calc;
+	uint8_t *buf;
+	int bytes;
+	int err;
+
+	dev_size = nvmem_dev_size(nvmem);
+
+	buf = kcalloc(1, dev_size, GFP_KERNEL);
+	if (!buf) {
+		err = -ENOMEM;
+		goto err_out;
+	}
+
+	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
+	if (bytes < 0)
+		return bytes;
+	else if (bytes != dev_size)
+		return -EIO;
+
+	switch (format) {
+	case U_BOOT_FORMAT_SINGLE:
+		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
+		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
+		data_offset = offsetof(struct u_boot_env_image_single, data);
+		break;
+	case U_BOOT_FORMAT_REDUNDANT:
+		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
+		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
+		data_offset = offsetof(struct u_boot_env_image_redundant, data);
+		break;
+	case U_BOOT_FORMAT_BROADCOM:
+		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
+		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
+		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
+		break;
+	}
+	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
+	crc32_data_len = dev_size - crc32_data_offset;
+	data_len = dev_size - data_offset;
+
+	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
+	if (calc != crc32) {
+		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
+		err = -EINVAL;
+		goto err_kfree;
+	}
+
+	buf[dev_size - 1] = '\0';
+	err = u_boot_env_parse_cells(dev, nvmem, buf, data_offset, data_len);
+	if (err)
+		dev_err(dev, "Failed to add cells: %d\n", err);
+
+err_kfree:
+	kfree(buf);
+err_out:
+	return err;
+}
+EXPORT_SYMBOL_GPL(u_boot_env_parse);
+
+static int u_boot_env_add_cells(struct device *dev, struct nvmem_device *nvmem)
+{
+	const struct of_device_id *match;
+	struct device_node *layout_np;
+	enum u_boot_env_format format;
+
+	layout_np = of_nvmem_layout_get_container(nvmem);
+	if (!layout_np)
+		return -ENOENT;
+
+	match = of_match_node(u_boot_env_of_match_table, layout_np);
+	if (!match)
+		return -ENOENT;
+
+	format = (uintptr_t)match->data;
+
+	of_node_put(layout_np);
+
+	return u_boot_env_parse(dev, nvmem, format);
+}
+
+static int u_boot_env_probe(struct nvmem_layout *layout)
+{
+	layout->add_cells = u_boot_env_add_cells;
+
+	return nvmem_layout_register(layout);
+}
+
+static void u_boot_env_remove(struct nvmem_layout *layout)
+{
+	nvmem_layout_unregister(layout);
+}
+
+static struct nvmem_layout_driver u_boot_env_layout = {
+	.driver = {
+		.owner = THIS_MODULE,
+		.name = "u-boot-env-layout",
+		.of_match_table = u_boot_env_of_match_table,
+	},
+	.probe = u_boot_env_probe,
+	.remove = u_boot_env_remove,
+};
+module_nvmem_layout_driver(u_boot_env_layout);
+
+MODULE_AUTHOR("Rafa? Mi?ecki");
+MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, u_boot_env_of_match_table);
diff --git a/drivers/nvmem/layouts/u-boot-env.h b/drivers/nvmem/layouts/u-boot-env.h
new file mode 100644
index 000000000000..dd5f280ac047
--- /dev/null
+++ b/drivers/nvmem/layouts/u-boot-env.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _LINUX_NVMEM_LAYOUTS_U_BOOT_ENV_H
+#define _LINUX_NVMEM_LAYOUTS_U_BOOT_ENV_H
+
+enum u_boot_env_format {
+	U_BOOT_FORMAT_SINGLE,
+	U_BOOT_FORMAT_REDUNDANT,
+	U_BOOT_FORMAT_BROADCOM,
+};
+
+int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
+		     enum u_boot_env_format format);
+
+#endif  /* ifndef _LINUX_NVMEM_LAYOUTS_U_BOOT_ENV_H */
diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index ab8c9bf63d99..386b2b255c30 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -3,23 +3,15 @@
  * Copyright (C) 2022 Rafa? Mi?ecki <rafal at milecki.pl>
  */
 
-#include <linux/crc32.h>
-#include <linux/etherdevice.h>
-#include <linux/if_ether.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/mtd/mtd.h>
-#include <linux/nvmem-consumer.h>
 #include <linux/nvmem-provider.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
-enum u_boot_env_format {
-	U_BOOT_FORMAT_SINGLE,
-	U_BOOT_FORMAT_REDUNDANT,
-	U_BOOT_FORMAT_BROADCOM,
-};
+#include "layouts/u-boot-env.h"
 
 struct u_boot_env {
 	struct device *dev;
@@ -29,24 +21,6 @@ struct u_boot_env {
 	struct mtd_info *mtd;
 };
 
-struct u_boot_env_image_single {
-	__le32 crc32;
-	uint8_t data[];
-} __packed;
-
-struct u_boot_env_image_redundant {
-	__le32 crc32;
-	u8 mark;
-	uint8_t data[];
-} __packed;
-
-struct u_boot_env_image_broadcom {
-	__le32 magic;
-	__le32 len;
-	__le32 crc32;
-	DECLARE_FLEX_ARRAY(uint8_t, data);
-} __packed;
-
 static int u_boot_env_read(void *context, unsigned int offset, void *val,
 			   size_t bytes)
 {
@@ -69,131 +43,6 @@ static int u_boot_env_read(void *context, unsigned int offset, void *val,
 	return 0;
 }
 
-static int u_boot_env_read_post_process_ethaddr(void *context, const char *id, int index,
-						unsigned int offset, void *buf, size_t bytes)
-{
-	u8 mac[ETH_ALEN];
-
-	if (bytes != 3 * ETH_ALEN - 1)
-		return -EINVAL;
-
-	if (!mac_pton(buf, mac))
-		return -EINVAL;
-
-	if (index)
-		eth_addr_add(mac, index);
-
-	ether_addr_copy(buf, mac);
-
-	return 0;
-}
-
-static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
-				size_t data_offset, size_t data_len)
-{
-	struct nvmem_device *nvmem = priv->nvmem;
-	struct device *dev = priv->dev;
-	char *data = buf + data_offset;
-	char *var, *value, *eq;
-
-	for (var = data;
-	     var < data + data_len && *var;
-	     var = value + strlen(value) + 1) {
-		struct nvmem_cell_info info = {};
-
-		eq = strchr(var, '=');
-		if (!eq)
-			break;
-		*eq = '\0';
-		value = eq + 1;
-
-		info.name = devm_kstrdup(dev, var, GFP_KERNEL);
-		if (!info.name)
-			return -ENOMEM;
-		info.offset = data_offset + value - data;
-		info.bytes = strlen(value);
-		info.np = of_get_child_by_name(dev->of_node, info.name);
-		if (!strcmp(var, "ethaddr")) {
-			info.raw_len = strlen(value);
-			info.bytes = ETH_ALEN;
-			info.read_post_process = u_boot_env_read_post_process_ethaddr;
-		}
-
-		nvmem_add_one_cell(nvmem, &info);
-	}
-
-	return 0;
-}
-
-static int u_boot_env_parse(struct u_boot_env *priv)
-{
-	struct nvmem_device *nvmem = priv->nvmem;
-	struct device *dev = priv->dev;
-	size_t crc32_data_offset;
-	size_t crc32_data_len;
-	size_t crc32_offset;
-	size_t data_offset;
-	size_t data_len;
-	size_t dev_size;
-	uint32_t crc32;
-	uint32_t calc;
-	uint8_t *buf;
-	int bytes;
-	int err;
-
-	dev_size = nvmem_dev_size(nvmem);
-
-	buf = kcalloc(1, dev_size, GFP_KERNEL);
-	if (!buf) {
-		err = -ENOMEM;
-		goto err_out;
-	}
-
-	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
-	if (bytes < 0)
-		return bytes;
-	else if (bytes != dev_size)
-		return -EIO;
-
-	switch (priv->format) {
-	case U_BOOT_FORMAT_SINGLE:
-		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
-		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
-		data_offset = offsetof(struct u_boot_env_image_single, data);
-		break;
-	case U_BOOT_FORMAT_REDUNDANT:
-		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
-		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
-		data_offset = offsetof(struct u_boot_env_image_redundant, data);
-		break;
-	case U_BOOT_FORMAT_BROADCOM:
-		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
-		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
-		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
-		break;
-	}
-	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
-	crc32_data_len = dev_size - crc32_data_offset;
-	data_len = dev_size - data_offset;
-
-	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
-	if (calc != crc32) {
-		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
-		err = -EINVAL;
-		goto err_kfree;
-	}
-
-	buf[dev_size - 1] = '\0';
-	err = u_boot_env_add_cells(priv, buf, data_offset, data_len);
-	if (err)
-		dev_err(dev, "Failed to add cells: %d\n", err);
-
-err_kfree:
-	kfree(buf);
-err_out:
-	return err;
-}
-
 static int u_boot_env_probe(struct platform_device *pdev)
 {
 	struct nvmem_config config = {
@@ -225,7 +74,7 @@ static int u_boot_env_probe(struct platform_device *pdev)
 	if (IS_ERR(priv->nvmem))
 		return PTR_ERR(priv->nvmem);
 
-	return u_boot_env_parse(priv);
+	return u_boot_env_parse(dev, priv->nvmem, priv->format);
 }
 
 static const struct of_device_id u_boot_env_of_match_table[] = {
-- 
2.35.3



From zajec5 at gmail.com  Mon Dec 18 05:37:19 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon, 18 Dec 2023 14:37:19 +0100
Subject: [PATCH 1/4] dt-bindings: nvmem: layouts: add U-Boot environment variables layout
Message-ID: <20231218133722.16150-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various storage devices. Its binding should
be an NVMEM layout instead of a standalone device.

This patch adds layout binding which allows using it on top of MTD NVMEM
device as well as any other. At the same time it deprecates the old
combined binding.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 .../bindings/nvmem/layouts/u-boot,env.yaml    | 55 +++++++++++++++++++
 .../devicetree/bindings/nvmem/u-boot,env.yaml |  6 ++
 2 files changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml

diff --git a/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
new file mode 100644
index 000000000000..3a7ec02b3535
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of U-Boot environment variables
+
+maintainers:
+  - Rafa? Mi?ecki <rafal at milecki.pl>
+
+description:
+  U-Boot uses environment variables to store device parameters and
+  configuration. They may be used for booting process, setup or keeping end user
+  info.
+
+  Data is stored using U-Boot specific formats (variant specific header and NUL
+  separated key-value pairs).
+
+properties:
+  compatible:
+    oneOf:
+      - description: A standalone env data block
+        const: u-boot,env
+      - description: Two redundant blocks with active one flagged
+        const: u-boot,env-redundant-bool
+      - description: Two redundant blocks with active having higher counter
+        const: u-boot,env-redundant-count
+      - description: Broadcom's variant with custom header
+        const: brcm,env
+
+additionalProperties: false
+
+examples:
+  - |
+    partitions {
+        compatible = "fixed-partitions";
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        partition at 0 {
+            reg = <0x0 0x40000>;
+            label = "u-boot";
+            read-only;
+        };
+
+        partition at 40000 {
+            reg = <0x40000 0x10000>;
+            label = "u-boot-env";
+
+            nvmem-layout {
+                compatible = "u-boot,env";
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
index 68214b96f5c9..fd95e611322d 100644
--- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
@@ -26,9 +26,15 @@ description: |
 
   Variables can be defined as NVMEM device subnodes.
 
+  Introduction of NVMEM layouts exposed a limitation of this binding design.
+  Description of NVMEM data content should be separated from NVMEM devices.
+  Since the introduction of U-Boot env data layout this binding is deprecated.
+
 maintainers:
   - Rafa? Mi?ecki <rafal at milecki.pl>
 
+deprecated: true
+
 properties:
   compatible:
     oneOf:
-- 
2.35.3



From krzysztof.kozlowski at linaro.org  Mon Dec 18 05:45:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 14:45:32 +0100
Subject: [PATCH] ARM: MAINTAINERS: drop empty entries for removed boards
Message-ID: <20231218134532.50599-1-krzysztof.kozlowski@linaro.org>

Drop empty and redundant maintainer entries for boards which were
removed to fix `scripts/get_maintainer.pl --self-test=sections` errors
like:

  ./MAINTAINERS:2021: warning: section without file pattern	ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT

Cc: Lennert Buytenhek <kernel at wantstofly.org>
Cc: Steve Sakoman <sakoman at gmail.com>
Cc: Mark F. Brown <mark.brown314 at gmail.com>
Cc: Robert Jarzmik <robert.jarzmik at free.fr>
Cc: Florian Fainelli <florian at openwrt.org>
Cc: Simtec Linux Team <linux at simtec.co.uk>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 MAINTAINERS | 42 ------------------------------------------
 1 file changed, 42 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d26c5311fb1..cdf1575dc851 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2018,11 +2018,6 @@ L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
 S:	Odd Fixes
 N:	clps711x
 
-ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
-M:	Lennert Buytenhek <kernel at wantstofly.org>
-L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-S:	Maintained
-
 ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
 M:	Hartley Sweeten <hsweeten at visionengravers.com>
 M:	Alexander Sverdlin <alexander.sverdlin at gmail.com>
@@ -2171,11 +2166,6 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
 F:	arch/arm/boot/dts/nxp/vf/
 F:	arch/arm/mach-imx/*vf610*
 
-ARM/GUMSTIX MACHINE SUPPORT
-M:	Steve Sakoman <sakoman at gmail.com>
-L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-S:	Maintained
-
 ARM/HISILICON SOC SUPPORT
 M:	Wei Xu <xuwei5 at hisilicon.com>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
@@ -2254,11 +2244,6 @@ F:	Documentation/devicetree/bindings/arm/intel,keembay.yaml
 F:	arch/arm64/boot/dts/intel/keembay-evm.dts
 F:	arch/arm64/boot/dts/intel/keembay-soc.dtsi
 
-ARM/INTEL XSC3 (MANZANO) ARM CORE
-M:	Lennert Buytenhek <kernel at wantstofly.org>
-L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-S:	Maintained
-
 ARM/LG1K ARCHITECTURE
 M:	Chanho Min <chanho.min at lge.com>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
@@ -2840,11 +2825,6 @@ F:	arch/arm/boot/dts/synaptics/
 F:	arch/arm/mach-berlin/
 F:	arch/arm64/boot/dts/synaptics/
 
-ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
-M:	Lennert Buytenhek <kernel at wantstofly.org>
-L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-S:	Maintained
-
 ARM/TEGRA HDMI CEC SUBSYSTEM SUPPORT
 M:	Hans Verkuil <hverkuil-cisco at xs4all.nl>
 L:	linux-tegra at vger.kernel.org
@@ -2861,11 +2841,6 @@ L:	linux-samsung-soc at vger.kernel.org
 S:	Maintained
 F:	arch/arm64/boot/dts/tesla/
 
-ARM/TETON BGA MACHINE SUPPORT
-M:	"Mark F. Brown" <mark.brown314 at gmail.com>
-L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-S:	Maintained
-
 ARM/TEXAS INSTRUMENT AEMIF/EMIF DRIVERS
 M:	Santosh Shilimkar <ssantosh at kernel.org>
 L:	linux-kernel at vger.kernel.org
@@ -17674,14 +17649,6 @@ L:	linux-gpio at vger.kernel.org
 S:	Maintained
 F:	drivers/gpio/gpio-pxa.c
 
-PXA MMCI DRIVER
-S:	Orphan
-
-PXA RTC DRIVER
-M:	Robert Jarzmik <robert.jarzmik at free.fr>
-L:	linux-rtc at vger.kernel.org
-S:	Maintained
-
 PXA2xx/PXA3xx SUPPORT
 M:	Daniel Mack <daniel at zonque.org>
 M:	Haojian Zhuang <haojian.zhuang at gmail.com>
@@ -18320,10 +18287,6 @@ F:	drivers/media/i2c/max9271.c
 F:	drivers/media/i2c/max9271.h
 F:	drivers/media/i2c/rdacm21.c
 
-RDC R-321X SoC
-M:	Florian Fainelli <florian at openwrt.org>
-S:	Maintained
-
 RDC R6040 FAST ETHERNET DRIVER
 M:	Florian Fainelli <f.fainelli at gmail.com>
 L:	netdev at vger.kernel.org
@@ -19930,11 +19893,6 @@ F:	Documentation/devicetree/bindings/display/simple-framebuffer.yaml
 F:	drivers/video/fbdev/simplefb.c
 F:	include/linux/platform_data/simplefb.h
 
-SIMTEC EB110ATX (Chalice CATS)
-M:	Simtec Linux Team <linux at simtec.co.uk>
-S:	Supported
-W:	http://www.simtec.co.uk/products/EB110ATX/
-
 SIOX
 M:	Thorsten Scherer <t.scherer at eckelmann.de>
 M:	Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
-- 
2.34.1



From zajec5 at gmail.com  Mon Dec 18 05:37:21 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon, 18 Dec 2023 14:37:21 +0100
Subject: [PATCH 3/4] nvmem: u-boot-env: use more nvmem subsystem helpers
In-Reply-To: <20231218133722.16150-1-zajec5@gmail.com>
References: <20231218133722.16150-1-zajec5@gmail.com>
Message-ID: <20231218133722.16150-3-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
   mtd dependent
2. Use nvmem_add_one_cell() to simplify adding NVMEM cells

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 drivers/nvmem/u-boot-env.c | 79 +++++++++++++++++---------------------
 1 file changed, 35 insertions(+), 44 deletions(-)

diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index c4ae94af4af7..ab8c9bf63d99 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -23,13 +23,10 @@ enum u_boot_env_format {
 
 struct u_boot_env {
 	struct device *dev;
+	struct nvmem_device *nvmem;
 	enum u_boot_env_format format;
 
 	struct mtd_info *mtd;
-
-	/* Cells */
-	struct nvmem_cell_info *cells;
-	int ncells;
 };
 
 struct u_boot_env_image_single {
@@ -94,72 +91,69 @@ static int u_boot_env_read_post_process_ethaddr(void *context, const char *id, i
 static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
 				size_t data_offset, size_t data_len)
 {
+	struct nvmem_device *nvmem = priv->nvmem;
 	struct device *dev = priv->dev;
 	char *data = buf + data_offset;
 	char *var, *value, *eq;
-	int idx;
-
-	priv->ncells = 0;
-	for (var = data; var < data + data_len && *var; var += strlen(var) + 1)
-		priv->ncells++;
 
-	priv->cells = devm_kcalloc(dev, priv->ncells, sizeof(*priv->cells), GFP_KERNEL);
-	if (!priv->cells)
-		return -ENOMEM;
-
-	for (var = data, idx = 0;
+	for (var = data;
 	     var < data + data_len && *var;
-	     var = value + strlen(value) + 1, idx++) {
+	     var = value + strlen(value) + 1) {
+		struct nvmem_cell_info info = {};
+
 		eq = strchr(var, '=');
 		if (!eq)
 			break;
 		*eq = '\0';
 		value = eq + 1;
 
-		priv->cells[idx].name = devm_kstrdup(dev, var, GFP_KERNEL);
-		if (!priv->cells[idx].name)
+		info.name = devm_kstrdup(dev, var, GFP_KERNEL);
+		if (!info.name)
 			return -ENOMEM;
-		priv->cells[idx].offset = data_offset + value - data;
-		priv->cells[idx].bytes = strlen(value);
-		priv->cells[idx].np = of_get_child_by_name(dev->of_node, priv->cells[idx].name);
+		info.offset = data_offset + value - data;
+		info.bytes = strlen(value);
+		info.np = of_get_child_by_name(dev->of_node, info.name);
 		if (!strcmp(var, "ethaddr")) {
-			priv->cells[idx].raw_len = strlen(value);
-			priv->cells[idx].bytes = ETH_ALEN;
-			priv->cells[idx].read_post_process = u_boot_env_read_post_process_ethaddr;
+			info.raw_len = strlen(value);
+			info.bytes = ETH_ALEN;
+			info.read_post_process = u_boot_env_read_post_process_ethaddr;
 		}
-	}
 
-	if (WARN_ON(idx != priv->ncells))
-		priv->ncells = idx;
+		nvmem_add_one_cell(nvmem, &info);
+	}
 
 	return 0;
 }
 
 static int u_boot_env_parse(struct u_boot_env *priv)
 {
+	struct nvmem_device *nvmem = priv->nvmem;
 	struct device *dev = priv->dev;
 	size_t crc32_data_offset;
 	size_t crc32_data_len;
 	size_t crc32_offset;
 	size_t data_offset;
 	size_t data_len;
+	size_t dev_size;
 	uint32_t crc32;
 	uint32_t calc;
-	size_t bytes;
 	uint8_t *buf;
+	int bytes;
 	int err;
 
-	buf = kcalloc(1, priv->mtd->size, GFP_KERNEL);
+	dev_size = nvmem_dev_size(nvmem);
+
+	buf = kcalloc(1, dev_size, GFP_KERNEL);
 	if (!buf) {
 		err = -ENOMEM;
 		goto err_out;
 	}
 
-	err = mtd_read(priv->mtd, 0, priv->mtd->size, &bytes, buf);
-	if ((err && !mtd_is_bitflip(err)) || bytes != priv->mtd->size) {
-		dev_err(dev, "Failed to read from mtd: %d\n", err);
-		goto err_kfree;
-	}
+	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
+	if (bytes < 0)
+		return bytes;
+	else if (bytes != dev_size)
+		return -EIO;
 
 	switch (priv->format) {
 	case U_BOOT_FORMAT_SINGLE:
@@ -179,8 +173,8 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 		break;
 	}
 	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
-	crc32_data_len = priv->mtd->size - crc32_data_offset;
-	data_len = priv->mtd->size - data_offset;
+	crc32_data_len = dev_size - crc32_data_offset;
+	data_len = dev_size - data_offset;
 
 	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
 	if (calc != crc32) {
@@ -189,7 +183,7 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 		goto err_kfree;
 	}
 
-	buf[priv->mtd->size - 1] = '\0';
+	buf[dev_size - 1] = '\0';
 	err = u_boot_env_add_cells(priv, buf, data_offset, data_len);
 	if (err)
 		dev_err(dev, "Failed to add cells: %d\n", err);
@@ -209,7 +203,6 @@ static int u_boot_env_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
 	struct u_boot_env *priv;
-	int err;
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -224,17 +217,15 @@ static int u_boot_env_probe(struct platform_device *pdev)
 		return PTR_ERR(priv->mtd);
 	}
 
-	err = u_boot_env_parse(priv);
-	if (err)
-		return err;
-
 	config.dev = dev;
-	config.cells = priv->cells;
-	config.ncells = priv->ncells;
 	config.priv = priv;
 	config.size = priv->mtd->size;
 
-	return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &config));
+	priv->nvmem = devm_nvmem_register(dev, &config);
+	if (IS_ERR(priv->nvmem))
+		return PTR_ERR(priv->nvmem);
+
+	return u_boot_env_parse(priv);
 }
 
 static const struct of_device_id u_boot_env_of_match_table[] = {
-- 
2.35.3



From quic_snehshah at quicinc.com  Mon Dec 18 05:50:32 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Mon, 18 Dec 2023 19:20:32 +0530
Subject: [PATCH net-next] net: stmmac: Fix ethool link settings ops for integrated PCS
Message-ID: <20231218135032.27209-1-quic_snehshah@quicinc.com>

Currently get/set_link_ksettings ethtool ops are dependent on PCS.
When PCS is integrated in MAC, it will not have separate link config.
Bypass cofiguring and checking PCS link config for integrated PCS.

Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index f628411ae4ae..e3ba4cd47b8d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -311,8 +311,9 @@ static int stmmac_ethtool_get_link_ksettings(struct net_device *dev,
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 
-	if (priv->hw->pcs & STMMAC_PCS_RGMII ||
-	    priv->hw->pcs & STMMAC_PCS_SGMII) {
+	if (!(priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS) &&
+	    (priv->hw->pcs & STMMAC_PCS_RGMII ||
+	     priv->hw->pcs & STMMAC_PCS_SGMII)) {
 		struct rgmii_adv adv;
 		u32 supported, advertising, lp_advertising;
 
@@ -397,8 +398,9 @@ stmmac_ethtool_set_link_ksettings(struct net_device *dev,
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 
-	if (priv->hw->pcs & STMMAC_PCS_RGMII ||
-	    priv->hw->pcs & STMMAC_PCS_SGMII) {
+	if (!(priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS) &&
+	    (priv->hw->pcs & STMMAC_PCS_RGMII ||
+	     priv->hw->pcs & STMMAC_PCS_SGMII)) {
 		/* Only support ANE */
 		if (cmd->base.autoneg != AUTONEG_ENABLE)
 			return -EINVAL;
-- 
2.17.1



From sebastianene at google.com  Mon Dec 18 05:58:50 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:50 +0000
Subject: [PATCH v4 00/10] arm64: ptdump: View the second stage page-tables
Message-ID: <20231218135859.2513568-2-sebastianene@google.com>

Hi,

This can be used as a debugging tool for dumping the second stage
page-tables.

When CONFIG_PTDUMP_STAGE2_DEBUGFS is enabled, ptdump registers 
'/sys/debug/kvm/<guest_id>/stage2_page_tables' entry with debugfs
upon guest creation. This allows userspace tools (eg. cat) to dump the
stage-2 pagetables by reading the registered file.

Reading the debugfs file shows stage-2 memory ranges in following format:
<IPA range> <size> <descriptor type> <access permissions> <mem_attributes>

Under pKVM configuration(kvm-arm.mode=protected) ptdump registers an entry
for the host stage-2 pagetables in the following path:
/sys/debug/kvm/host_stage2_page_tables/

The tool interprets the pKVM ownership annotation stored in the invalid
entries and dumps to the console the ownership information. To be able
to access the host stage-2 page-tables from the kernel, a new hypervisor
call was introduced which allows us to snapshot the page-tables in a host
provided buffer. The hypervisor call is hidden behind CONFIG_NVHE_EL2_DEBUG
as this should be used under debugging environment.

Link to the third version:
https://lore.kernel.org/all/20231115171639.2852644-2-sebastianene at google.com/

Link to the second version:
https://lore.kernel.org/all/20231019144032.2943044-1-sebastianene at google.com/#r

Link to the first version:
https://lore.kernel.org/all/20230927112517.2631674-1-sebastianene at google.com/

Changelog:
  v3 -> current_version:
  * refactorization: moved all the **KVM** specific components under
    kvm/ as suggested by Oliver. Introduced a new file
    arm64/kvm/ptdump.c which handled the second stage translation.
    re-used only the display portion from mm/ptdump.c

  * pagetable snapshot creation now uses memory donated from the host.
    The memory is no longer shared with the host as this can pose a security
    risk if the host has access to manipulate the pagetable copy while
    the hypervisor iterates it.

  * fixed a memory leak: while memory was used from the memcache for
    building the snapshot pagetable, it was no longer giving back the
    pages to the host for freeing. A separate array was introduced to
    keep track of the pages allocated from the memcache.

  v2 -> v3:
  * register the stage-2 debugfs entry for the host under
    /sys/debug/kvm/host_stage2_page_tables and in
    /sys/debug/kvm/<guest_id>/stage2_page_tables for guests.

  * don't use a static array for parsing the attributes description,
    generate it dynamically based on the number of pagetable levels

  * remove the lock that was guarding the seq_file private inode data,
    and keep the data private to the open file session.

  * minor fixes & renaming of CONFIG_NVHE_EL2_PTDUMP_DEBUGFS to
    CONFIG_PTDUMP_STAGE2_DEBUGFS

  v1 -> v2:
  * use the stage-2 pagetable walker for dumping descriptors instead of
    the one provided by ptdump.

  * support for guests pagetables dumping under VHE/nVHE non-protected

Thanks,

Sebastian Ene (10):
  KVM: arm64: Add snapshot interface for the host stage-2 pagetable
  KVM: arm64: Add ptdump registration with debugfs for the stage-2
    pagetables
  KVM: arm64: Invoke the snapshot interface for the host stage-2
    pagetable
  arm64: ptdump: Expose the attribute parsing functionality
  arm64: ptdump: Use the mask from the state structure
  KVM: arm64: Move pagetable definitions to common header
  KVM: arm64: Walk the pagetable snapshot and parse the ptdump
    descriptors
  arm64: ptdump: Interpret memory attributes based on the runtime config
  arm64: ptdump: Interpret pKVM ownership annotations
  arm64: ptdump: Add guest stage-2 pagetables dumping

 arch/arm64/include/asm/kvm_asm.h              |   1 +
 arch/arm64/include/asm/kvm_pgtable.h          | 111 +++++
 arch/arm64/include/asm/ptdump.h               |  49 +-
 arch/arm64/kvm/Kconfig                        |  13 +
 arch/arm64/kvm/Makefile                       |   1 +
 arch/arm64/kvm/arm.c                          |   2 +
 arch/arm64/kvm/debug.c                        |   6 +
 arch/arm64/kvm/hyp/include/nvhe/mem_protect.h |  27 +-
 arch/arm64/kvm/hyp/nvhe/hyp-main.c            |  12 +
 arch/arm64/kvm/hyp/nvhe/mem_protect.c         | 186 ++++++++
 arch/arm64/kvm/hyp/pgtable.c                  |  85 ++--
 arch/arm64/kvm/kvm_ptdump.h                   |  21 +
 arch/arm64/kvm/ptdump.c                       | 436 ++++++++++++++++++
 arch/arm64/mm/ptdump.c                        |  55 +--
 14 files changed, 897 insertions(+), 108 deletions(-)
 create mode 100644 arch/arm64/kvm/kvm_ptdump.h
 create mode 100644 arch/arm64/kvm/ptdump.c

-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:58:51 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:51 +0000
Subject: [PATCH v4 01/10] KVM: arm64: Add snapshot interface for the host
 stage-2 pagetable
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-3-sebastianene@google.com>

Introduce a new hvc that allows the pKVM hypervisor to snapshot the host
stage-2 pagetables. The caller is expected to allocate & free the memory
for the pagetable snapshot. The below diagram shows the sequence of
events.

[--- HOST ---]
(1) allocate memory for the snapshot
(2) invoke the __pkvm_copy_host_stage2(snapshot) interface
|____
	[--- HYP ---]
	(3) donate the snapshot from HOST -> HYP
	(4) save the host stage-2 pagetables in the snapshot
	(5) donate the snapshot from HYP -> HOST
	[--- return from HYP ---]
[--- HOST ---]
(6) free the memory for the snapshot

When the host kernel invokes this interface, the memory is donated from
the host to the hypervisor. By doing this the memory is unmapped from the
host's translation regime to prevent the host from modifying the buffer
while the hypervisor uses it. The hypervisor walks the host stage-2
pagetable copy while re-creating the original mappings. When the copying
is done, the memory is donated from the hypervisor back to the host.
The pages that have been used from the memcache are donated back to the
host from a temporary array. The hvc is executing synchronously and the
preemption is disabled for the current CPU while running inside the
hypervisor so calling this interface blocks the current CPU until the
snapshoting is done.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/include/asm/kvm_asm.h              |   1 +
 arch/arm64/include/asm/kvm_pgtable.h          |  43 ++++
 arch/arm64/kvm/hyp/include/nvhe/mem_protect.h |   1 +
 arch/arm64/kvm/hyp/nvhe/hyp-main.c            |  12 ++
 arch/arm64/kvm/hyp/nvhe/mem_protect.c         | 186 ++++++++++++++++++
 arch/arm64/kvm/hyp/pgtable.c                  |  43 ++++
 6 files changed, 286 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 24b5e6b23..9df3367d8 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -81,6 +81,7 @@ enum __kvm_host_smccc_func {
 	__KVM_HOST_SMCCC_FUNC___pkvm_init_vm,
 	__KVM_HOST_SMCCC_FUNC___pkvm_init_vcpu,
 	__KVM_HOST_SMCCC_FUNC___pkvm_teardown_vm,
+	__KVM_HOST_SMCCC_FUNC___pkvm_host_stage2_snapshot,
 };
 
 #define DECLARE_KVM_VHE_SYM(sym)	extern char sym[]
diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index d3e354bb8..f73efd8a8 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -10,6 +10,7 @@
 #include <linux/bits.h>
 #include <linux/kvm_host.h>
 #include <linux/types.h>
+#include <asm/kvm_host.h>
 
 #define KVM_PGTABLE_MAX_LEVELS		4U
 
@@ -351,6 +352,28 @@ struct kvm_pgtable {
 	kvm_pgtable_force_pte_cb_t		force_pte_cb;
 };
 
+/**
+ * struct kvm_pgtable_snapshot - Snapshot page-table wrapper.
+ * @pgtable:		The page-table configuration.
+ * @mc:			Memcache used for pagetable pages allocation.
+ * @pgd_hva:		Host virtual address of a physically contiguous buffer
+ *			used for storing the PGD.
+ * @pgd_pages:		The size of the phyisically contiguous buffer in pages.
+ * @used_pages_hva:	Host virtual address of a physically contiguous buffer
+ *			used for storing the consumed pages from the memcache.
+ * @num_used_pages		The size of the used buffer in pages.
+ * @used_pages_indx		The current index of the used pages array.
+ */
+struct kvm_pgtable_snapshot {
+	struct kvm_pgtable			pgtable;
+	struct kvm_hyp_memcache			mc;
+	void					*pgd_hva;
+	size_t					pgd_pages;
+	phys_addr_t				*used_pages_hva;
+	size_t					num_used_pages;
+	size_t					used_pages_indx;
+};
+
 /**
  * kvm_pgtable_hyp_init() - Initialise a hypervisor stage-1 page-table.
  * @pgt:	Uninitialised page-table structure to initialise.
@@ -756,4 +779,24 @@ enum kvm_pgtable_prot kvm_pgtable_hyp_pte_prot(kvm_pte_t pte);
  */
 void kvm_tlb_flush_vmid_range(struct kvm_s2_mmu *mmu,
 				phys_addr_t addr, size_t size);
+
+#ifdef CONFIG_NVHE_EL2_DEBUG
+/**
+ * kvm_pgtable_stage2_snapshot() - Given a memcache and a destination
+ *				pagetable where we have the original PGD
+ *				copied, build a snapshot table with page table
+ *				pages from the given memcache.
+ *
+ * @to_pgt:	Destination pagetable
+ * @mc:		The memcache where we allocate the destination pagetables from
+ */
+int kvm_pgtable_stage2_snapshot(struct kvm_pgtable *to_pgt,
+				void *mc);
+#else
+static inline int kvm_pgtable_stage2_snapshot(struct kvm_pgtable *to_pgt,
+					      void *mc)
+{
+	return -EPERM;
+}
+#endif	/* CONFIG_NVHE_EL2_DEBUG */
 #endif	/* __ARM64_KVM_PGTABLE_H__ */
diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
index 0972faccc..ca8f76915 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
@@ -69,6 +69,7 @@ int __pkvm_host_donate_hyp(u64 pfn, u64 nr_pages);
 int __pkvm_hyp_donate_host(u64 pfn, u64 nr_pages);
 int __pkvm_host_share_ffa(u64 pfn, u64 nr_pages);
 int __pkvm_host_unshare_ffa(u64 pfn, u64 nr_pages);
+int __pkvm_host_stage2_snapshot(struct kvm_pgtable_snapshot *snapshot);
 
 bool addr_is_memory(phys_addr_t phys);
 int host_stage2_idmap_locked(phys_addr_t addr, u64 size, enum kvm_pgtable_prot prot);
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 2385fd03e..7b215245f 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -314,6 +314,17 @@ static void handle___pkvm_teardown_vm(struct kvm_cpu_context *host_ctxt)
 	cpu_reg(host_ctxt, 1) = __pkvm_teardown_vm(handle);
 }
 
+static void handle___pkvm_host_stage2_snapshot(struct kvm_cpu_context *host_ctxt)
+{
+#ifdef CONFIG_NVHE_EL2_DEBUG
+	DECLARE_REG(struct kvm_pgtable_snapshot *, snapshot_hva, host_ctxt, 1);
+
+	cpu_reg(host_ctxt, 1) = __pkvm_host_stage2_snapshot(snapshot_hva);
+#else
+	cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
+#endif
+}
+
 typedef void (*hcall_t)(struct kvm_cpu_context *);
 
 #define HANDLE_FUNC(x)	[__KVM_HOST_SMCCC_FUNC_##x] = (hcall_t)handle_##x
@@ -348,6 +359,7 @@ static const hcall_t host_hcall[] = {
 	HANDLE_FUNC(__pkvm_init_vm),
 	HANDLE_FUNC(__pkvm_init_vcpu),
 	HANDLE_FUNC(__pkvm_teardown_vm),
+	HANDLE_FUNC(__pkvm_host_stage2_snapshot),
 };
 
 static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 8d0a5834e..aaf07f9e1 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -266,6 +266,192 @@ int kvm_guest_prepare_stage2(struct pkvm_hyp_vm *vm, void *pgd)
 	return 0;
 }
 
+#ifdef CONFIG_NVHE_EL2_DEBUG
+static void *snap_zalloc_page(void *mc)
+{
+	struct hyp_page *p;
+	void *addr;
+	struct kvm_pgtable_snapshot *snap;
+	phys_addr_t *used_pg;
+
+	snap = container_of(mc, struct kvm_pgtable_snapshot, mc);
+	used_pg = kern_hyp_va(snap->used_pages_hva);
+
+	/* Check if we have space to track the used page */
+	if (snap->used_pages_indx * sizeof(phys_addr_t) > snap->num_used_pages * PAGE_SIZE)
+		return NULL;
+
+	addr = pop_hyp_memcache(mc, hyp_phys_to_virt);
+	if (!addr)
+		return addr;
+	used_pg[snap->used_pages_indx++] = hyp_virt_to_phys(addr);
+
+	memset(addr, 0, PAGE_SIZE);
+	p = hyp_virt_to_page(addr);
+	memset(p, 0, sizeof(*p));
+
+	return addr;
+}
+
+static void snap_free_pages_exact(void *addr, unsigned long size)
+{
+	u8 order = get_order(size);
+	unsigned int i;
+	struct hyp_page *p;
+
+	for (i = 0; i < (1 << order); i++) {
+		p = hyp_virt_to_page(addr + (i * PAGE_SIZE));
+		hyp_page_ref_dec(p);
+	}
+}
+
+static void *pkvm_setup_snapshot(struct kvm_pgtable_snapshot *snap_hva)
+{
+	unsigned long i;
+	void *pgd, *used_pg;
+	phys_addr_t mc_page, next_mc_page;
+	struct kvm_pgtable_snapshot *snap;
+
+	snap = (void *)kern_hyp_va(snap_hva);
+	if (!PAGE_ALIGNED(snap))
+		return NULL;
+
+	if (__pkvm_host_donate_hyp(hyp_virt_to_pfn(snap), 1))
+		return NULL;
+
+	pgd = kern_hyp_va(snap->pgd_hva);
+	if (!PAGE_ALIGNED(pgd))
+		goto error_with_snapshot;
+
+	if (__pkvm_host_donate_hyp(hyp_virt_to_pfn(pgd), snap->pgd_pages))
+		goto error_with_snapshot;
+
+	mc_page = snap->mc.head;
+	for (i = 0; i < snap->mc.nr_pages; i++) {
+		if (!PAGE_ALIGNED(mc_page))
+			goto error_with_memcache;
+
+		if (__pkvm_host_donate_hyp(hyp_phys_to_pfn(mc_page), 1))
+			goto error_with_memcache;
+
+		mc_page = *((phys_addr_t *)hyp_phys_to_virt(mc_page));
+	}
+
+	used_pg = kern_hyp_va(snap->used_pages_hva);
+	if (!PAGE_ALIGNED(used_pg))
+		goto error_with_memcache;
+
+	if (__pkvm_host_donate_hyp(hyp_virt_to_pfn(used_pg), snap->num_used_pages))
+		goto error_with_memcache;
+
+	return snap;
+error_with_memcache:
+	mc_page = snap->mc.head;
+	for (; i >= 0; i--) {
+		next_mc_page = *((phys_addr_t *)hyp_phys_to_virt(mc_page));
+		WARN_ON(__pkvm_hyp_donate_host(hyp_phys_to_pfn(mc_page), 1));
+		mc_page = next_mc_page;
+	}
+
+	WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(pgd), snap->pgd_pages));
+error_with_snapshot:
+	WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(snap), 1));
+	return NULL;
+}
+
+static void pkvm_teardown_snapshot(struct kvm_pgtable_snapshot *snap)
+{
+	size_t i;
+	phys_addr_t mc_page, next_mc_page;
+	u64 *used_pg = kern_hyp_va(snap->used_pages_hva);
+	void *pgd = kern_hyp_va(snap->pgd_hva);
+
+	for (i = 0; i < snap->used_pages_indx; i++) {
+		mc_page = used_pg[i];
+		WARN_ON(__pkvm_hyp_donate_host(hyp_phys_to_pfn(mc_page), 1));
+	}
+
+	WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(used_pg),
+				       snap->num_used_pages));
+
+	mc_page = snap->mc.head;
+	for (i = 0; i < snap->mc.nr_pages; i++) {
+		next_mc_page = *((phys_addr_t *)hyp_phys_to_virt(mc_page));
+		WARN_ON(__pkvm_hyp_donate_host(hyp_phys_to_pfn(mc_page), 1));
+		mc_page = next_mc_page;
+	}
+
+	snap->pgtable.mm_ops = NULL;
+	WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(pgd), snap->pgd_pages));
+	WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(snap), 1));
+}
+
+static int pkvm_host_stage2_snapshot(struct kvm_pgtable_snapshot *snap)
+{
+	int ret;
+	void *pgd;
+	size_t required_pgd_len;
+	struct kvm_pgtable_mm_ops mm_ops = {0};
+	struct kvm_s2_mmu *mmu;
+	struct kvm_pgtable *to_pgt, *from_pgt;
+
+	if (snap->used_pages_indx != 0)
+		return -EINVAL;
+
+	from_pgt = &host_mmu.pgt;
+	mmu = &host_mmu.arch.mmu;
+	required_pgd_len = kvm_pgtable_stage2_pgd_size(mmu->vtcr);
+	if (snap->pgd_pages < (required_pgd_len >> PAGE_SHIFT))
+		return -ENOMEM;
+
+	if (snap->mc.nr_pages < host_s2_pgtable_pages())
+		return -ENOMEM;
+
+	to_pgt = &snap->pgtable;
+	pgd = kern_hyp_va(snap->pgd_hva);
+
+	mm_ops.zalloc_page		= snap_zalloc_page;
+	mm_ops.free_pages_exact		= snap_free_pages_exact;
+	mm_ops.phys_to_virt		= hyp_phys_to_virt;
+	mm_ops.virt_to_phys		= hyp_virt_to_phys;
+	mm_ops.page_count		= hyp_page_count;
+
+	to_pgt->ia_bits		= from_pgt->ia_bits;
+	to_pgt->start_level	= from_pgt->start_level;
+	to_pgt->flags		= from_pgt->flags;
+	to_pgt->mm_ops		= &mm_ops;
+
+	host_lock_component();
+
+	to_pgt->pgd = pgd;
+	memcpy(to_pgt->pgd, from_pgt->pgd, required_pgd_len);
+	ret = kvm_pgtable_stage2_snapshot(to_pgt, &snap->mc);
+
+	host_unlock_component();
+
+	return ret;
+}
+
+int __pkvm_host_stage2_snapshot(struct kvm_pgtable_snapshot *snap_hva)
+{
+	int ret;
+	struct kvm_pgtable_snapshot *snap;
+	kvm_pteref_t pgd;
+
+	snap = pkvm_setup_snapshot(snap_hva);
+	if (!snap)
+		return -EPERM;
+
+	ret = pkvm_host_stage2_snapshot(snap);
+	if (!ret) {
+		pgd = snap->pgtable.pgd;
+		snap->pgtable.pgd = (kvm_pteref_t)__hyp_pa(pgd);
+	}
+	pkvm_teardown_snapshot(snap);
+	return ret;
+}
+#endif /* CONFIG_NVHE_EL2_DEBUG */
+
 void reclaim_guest_pages(struct pkvm_hyp_vm *vm, struct kvm_hyp_memcache *mc)
 {
 	void *addr;
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 1966fdee7..82fef9620 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -1598,3 +1598,46 @@ void kvm_pgtable_stage2_free_unlinked(struct kvm_pgtable_mm_ops *mm_ops, void *p
 	WARN_ON(mm_ops->page_count(pgtable) != 1);
 	mm_ops->put_page(pgtable);
 }
+
+#ifdef CONFIG_NVHE_EL2_DEBUG
+static int snapshot_walker(const struct kvm_pgtable_visit_ctx *ctx,
+			   enum kvm_pgtable_walk_flags visit)
+{
+	struct kvm_pgtable_mm_ops *mm_ops = ctx->mm_ops;
+	void *copy_table, *original_addr;
+	kvm_pte_t new = ctx->old;
+
+	if (!stage2_pte_is_counted(ctx->old))
+		return 0;
+
+	if (kvm_pte_table(ctx->old, ctx->level)) {
+		copy_table = mm_ops->zalloc_page(ctx->arg);
+		if (!copy_table)
+			return -ENOMEM;
+
+		original_addr = kvm_pte_follow(ctx->old, mm_ops);
+
+		memcpy(copy_table, original_addr, PAGE_SIZE);
+		new = kvm_init_table_pte(copy_table, mm_ops);
+	}
+
+	*ctx->ptep = new;
+
+	return 0;
+}
+
+int kvm_pgtable_stage2_snapshot(struct kvm_pgtable *to_pgt, void *mc)
+{
+	struct kvm_pgtable_walker walker = {
+		.cb	= snapshot_walker,
+		.flags	= KVM_PGTABLE_WALK_LEAF |
+			  KVM_PGTABLE_WALK_TABLE_PRE,
+		.arg = mc
+	};
+
+	if (!to_pgt->pgd)
+		return -ENOMEM;
+
+	return kvm_pgtable_walk(to_pgt, 0, BIT(to_pgt->ia_bits), &walker);
+}
+#endif /* CONFIG_NVHE_EL2_DEBUG */
-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:58:52 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:52 +0000
Subject: [PATCH v4 02/10] KVM: arm64: Add ptdump registration with debugfs for
 the stage-2 pagetables
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-4-sebastianene@google.com>

While arch/*/mem/ptdump handles the kernel pagetable dumping code,
introduce KVM/ptdump which deals with the stage-2 pagetables. The
separation is necessary because most of the definitions from the
stage-2 pagetable reside in the KVM path and we will be invoking
functionality **specific** to KVM.

This registers a wrapper on top of debugfs_create_file which allows us
to hook callbacks on the debugfs open/show/close. The callbacks are used
to prepare the display portion of the pagetable dumping code.
Guard this functionality under the newly introduced PTDUMP_STAGE2_DEBUGFS.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/kvm/Kconfig      | 13 +++++
 arch/arm64/kvm/Makefile     |  1 +
 arch/arm64/kvm/arm.c        |  2 +
 arch/arm64/kvm/kvm_ptdump.h | 18 +++++++
 arch/arm64/kvm/ptdump.c     | 96 +++++++++++++++++++++++++++++++++++++
 5 files changed, 130 insertions(+)
 create mode 100644 arch/arm64/kvm/kvm_ptdump.h
 create mode 100644 arch/arm64/kvm/ptdump.c

diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 83c1e09be..0014e55e2 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -71,4 +71,17 @@ config PROTECTED_NVHE_STACKTRACE
 
 	  If unsure, or not using protected nVHE (pKVM), say N.
 
+config PTDUMP_STAGE2_DEBUGFS
+       bool "Present the stage-2 pagetables to debugfs"
+       depends on PTDUMP_DEBUGFS && KVM
+       default n
+       help
+         Say Y here if you want to show the stage-2 kernel pagetables
+         layout in a debugfs file. This information is only useful for kernel developers
+         who are working in architecture specific areas of the kernel.
+         It is probably not a good idea to enable this feature in a production
+         kernel.
+
+         If in doubt, say N.
+
 endif # VIRTUALIZATION
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index c0c050e53..190eac175 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -23,6 +23,7 @@ kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
 	 vgic/vgic-its.o vgic/vgic-debug.o
 
 kvm-$(CONFIG_HW_PERF_EVENTS)  += pmu-emul.o pmu.o
+kvm-$(CONFIG_PTDUMP_STAGE2_DEBUGFS) += ptdump.o
 
 always-y := hyp_constants.h hyp-constants.s
 
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index e5f75f1f1..ee8d7cb67 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -40,6 +40,7 @@
 #include <asm/kvm_pkvm.h>
 #include <asm/kvm_emulate.h>
 #include <asm/sections.h>
+#include <kvm_ptdump.h>
 
 #include <kvm/arm_hypercalls.h>
 #include <kvm/arm_pmu.h>
@@ -2592,6 +2593,7 @@ static __init int kvm_arm_init(void)
 	if (err)
 		goto out_subs;
 
+	kvm_ptdump_register_host();
 	kvm_arm_initialised = true;
 
 	return 0;
diff --git a/arch/arm64/kvm/kvm_ptdump.h b/arch/arm64/kvm/kvm_ptdump.h
new file mode 100644
index 000000000..98b595ce8
--- /dev/null
+++ b/arch/arm64/kvm/kvm_ptdump.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+//
+// Copyright (C) Google, 2023
+// Author: Sebastian Ene <sebastianene at google.com>
+
+#ifndef __KVM_PTDUMP_H
+#define __KVM_PTDUMP_H
+
+#include <asm/ptdump.h>
+
+
+#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
+void kvm_ptdump_register_host(void);
+#else
+static inline void kvm_ptdump_register_host(void) { }
+#endif /* CONFIG_PTDUMP_STAGE2_DEBUGFS */
+
+#endif /* __KVM_PTDUMP_H */
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
new file mode 100644
index 000000000..5816fc632
--- /dev/null
+++ b/arch/arm64/kvm/ptdump.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Debug helper used to dump the stage-2 pagetables of the system and their
+// associated permissions.
+//
+// Copyright (C) Google, 2023
+// Author: Sebastian Ene <sebastianene at google.com>
+
+#include <linux/debugfs.h>
+#include <linux/kvm_host.h>
+#include <linux/seq_file.h>
+
+#include <asm/kvm_pkvm.h>
+#include <kvm_ptdump.h>
+
+
+struct kvm_ptdump_register {
+	void *(*get_ptdump_info)(struct kvm_ptdump_register *reg);
+	void (*put_ptdump_info)(void *priv);
+	int (*show_ptdump_info)(struct seq_file *m, void *v);
+	void *priv;
+};
+
+static int kvm_ptdump_open(struct inode *inode, struct file *file);
+static int kvm_ptdump_release(struct inode *inode, struct file *file);
+static int kvm_ptdump_show(struct seq_file *m, void *);
+
+static const struct file_operations kvm_ptdump_fops = {
+	.open		= kvm_ptdump_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= kvm_ptdump_release,
+};
+
+static int kvm_ptdump_open(struct inode *inode, struct file *file)
+{
+	struct kvm_ptdump_register *reg = inode->i_private;
+	void *info = NULL;
+	int ret;
+
+	if (reg->get_ptdump_info) {
+		info = reg->get_ptdump_info(reg);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	if (!reg->show_ptdump_info)
+		reg->show_ptdump_info = kvm_ptdump_show;
+
+	ret = single_open(file, reg->show_ptdump_info, info);
+	if (ret && reg->put_ptdump_info)
+		reg->put_ptdump_info(info);
+
+	return ret;
+}
+
+static int kvm_ptdump_release(struct inode *inode, struct file *file)
+{
+	struct kvm_ptdump_register *reg = inode->i_private;
+	struct seq_file *seq_file = file->private_data;
+
+	if (reg->put_ptdump_info)
+		reg->put_ptdump_info(seq_file->private);
+
+	return 0;
+}
+
+static int kvm_ptdump_show(struct seq_file *m, void *)
+{
+	return -EINVAL;
+}
+
+static void kvm_ptdump_debugfs_register(struct kvm_ptdump_register *reg,
+					const char *name, struct dentry *parent)
+{
+	debugfs_create_file(name, 0400, parent, reg, &kvm_ptdump_fops);
+}
+
+static struct kvm_ptdump_register host_reg;
+
+void kvm_ptdump_register_host(void)
+{
+	if (!is_protected_kvm_enabled())
+		return;
+
+	kvm_ptdump_debugfs_register(&host_reg, "host_page_tables",
+				    kvm_debugfs_dir);
+}
+
+static int __init kvm_host_ptdump_init(void)
+{
+	host_reg.priv = (void *)host_s2_pgtable_pages();
+	return 0;
+}
+
+device_initcall(kvm_host_ptdump_init);
-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:58:53 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:53 +0000
Subject: [PATCH v4 03/10] KVM: arm64: Invoke the snapshot interface for the
 host stage-2 pagetable
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-5-sebastianene@google.com>

Allocate memory for the snapshot by creating a memory cache with empty
pages that will be used by the hypervisor during the page table copy.
Get the required size of the PGD and allocate physically contiguous
memory for it. Allocate contiguous memory for an array that is used to
keep track of the pages used from the memcache. Call the snapshot
interface and release the memory for the snapshot.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/kvm/ptdump.c | 107 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)

diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index 5816fc632..e99bab427 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -25,6 +25,9 @@ static int kvm_ptdump_open(struct inode *inode, struct file *file);
 static int kvm_ptdump_release(struct inode *inode, struct file *file);
 static int kvm_ptdump_show(struct seq_file *m, void *);
 
+static phys_addr_t get_host_pa(void *addr);
+static void *get_host_va(phys_addr_t pa);
+
 static const struct file_operations kvm_ptdump_fops = {
 	.open		= kvm_ptdump_open,
 	.read		= seq_read,
@@ -32,6 +35,11 @@ static const struct file_operations kvm_ptdump_fops = {
 	.release	= kvm_ptdump_release,
 };
 
+static struct kvm_pgtable_mm_ops ptdump_host_mmops = {
+	.phys_to_virt	= get_host_va,
+	.virt_to_phys	= get_host_pa,
+};
+
 static int kvm_ptdump_open(struct inode *inode, struct file *file)
 {
 	struct kvm_ptdump_register *reg = inode->i_private;
@@ -78,11 +86,110 @@ static void kvm_ptdump_debugfs_register(struct kvm_ptdump_register *reg,
 
 static struct kvm_ptdump_register host_reg;
 
+static size_t host_stage2_get_pgd_len(void)
+{
+	u32 phys_shift = get_kvm_ipa_limit();
+	u64 vtcr = kvm_get_vtcr(read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1),
+				read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1),
+				phys_shift);
+	return (kvm_pgtable_stage2_pgd_size(vtcr) >> PAGE_SHIFT);
+}
+
+static phys_addr_t get_host_pa(void *addr)
+{
+	return __pa(addr);
+}
+
+static void *get_host_va(phys_addr_t pa)
+{
+	return __va(pa);
+}
+
+static void kvm_host_put_ptdump_info(void *snap)
+{
+	void *mc_page;
+	size_t i;
+	struct kvm_pgtable_snapshot *snapshot;
+
+	if (!snap)
+		return;
+
+	snapshot = snap;
+	while ((mc_page = pop_hyp_memcache(&snapshot->mc, get_host_va)) != NULL)
+		free_page((unsigned long)mc_page);
+
+	if (snapshot->pgd_hva)
+		free_pages_exact(snapshot->pgd_hva, snapshot->pgd_pages);
+
+	if (snapshot->used_pages_hva) {
+		for (i = 0; i < snapshot->used_pages_indx; i++) {
+			mc_page = get_host_va(snapshot->used_pages_hva[i]);
+			free_page((unsigned long)mc_page);
+		}
+
+		free_pages_exact(snapshot->used_pages_hva, snapshot->num_used_pages);
+	}
+
+	free_page((unsigned long)snapshot);
+}
+
+static void *kvm_host_get_ptdump_info(struct kvm_ptdump_register *reg)
+{
+	int i, ret;
+	void *mc_page;
+	struct kvm_pgtable_snapshot *snapshot;
+	size_t memcache_len;
+
+	snapshot = (void *)__get_free_page(GFP_KERNEL_ACCOUNT);
+	if (!snapshot)
+		return NULL;
+
+	memset(snapshot, 0, sizeof(struct kvm_pgtable_snapshot));
+
+	snapshot->pgd_pages = host_stage2_get_pgd_len();
+	snapshot->pgd_hva = alloc_pages_exact(snapshot->pgd_pages, GFP_KERNEL_ACCOUNT);
+	if (!snapshot->pgd_hva)
+		goto err;
+
+	memcache_len = (size_t)reg->priv;
+	for (i = 0; i < memcache_len; i++) {
+		mc_page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT);
+		if (!mc_page)
+			goto err;
+
+		push_hyp_memcache(&snapshot->mc, mc_page, get_host_pa);
+	}
+
+	snapshot->num_used_pages = DIV_ROUND_UP(sizeof(phys_addr_t) * memcache_len,
+					     PAGE_SIZE);
+	snapshot->used_pages_hva = alloc_pages_exact(snapshot->num_used_pages,
+						  GFP_KERNEL_ACCOUNT);
+	if (!snapshot->used_pages_hva)
+		goto err;
+
+	ret = kvm_call_hyp_nvhe(__pkvm_host_stage2_snapshot, snapshot);
+	if (ret) {
+		pr_err("ERROR %d snapshot host pagetables\n", ret);
+		goto err;
+	}
+
+	snapshot->pgtable.pgd = get_host_va((phys_addr_t)snapshot->pgtable.pgd);
+	snapshot->pgtable.mm_ops = &ptdump_host_mmops;
+
+	return snapshot;
+err:
+	kvm_host_put_ptdump_info(snapshot);
+	return NULL;
+}
+
 void kvm_ptdump_register_host(void)
 {
 	if (!is_protected_kvm_enabled())
 		return;
 
+	host_reg.get_ptdump_info = kvm_host_get_ptdump_info;
+	host_reg.put_ptdump_info = kvm_host_put_ptdump_info;
+
 	kvm_ptdump_debugfs_register(&host_reg, "host_page_tables",
 				    kvm_debugfs_dir);
 }
-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:58:54 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:54 +0000
Subject: [PATCH v4 04/10] arm64: ptdump: Expose the attribute parsing functionality
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-6-sebastianene@google.com>

To keep the same output format as the arch specific ptdump and for the
sake of reusability, move the parser's state tracking code out
of the arch specific.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/include/asm/ptdump.h | 41 ++++++++++++++++++++++++++++++++-
 arch/arm64/mm/ptdump.c          | 36 ++---------------------------
 2 files changed, 42 insertions(+), 35 deletions(-)

diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
index 581caac52..23510be35 100644
--- a/arch/arm64/include/asm/ptdump.h
+++ b/arch/arm64/include/asm/ptdump.h
@@ -9,6 +9,8 @@
 
 #include <linux/mm_types.h>
 #include <linux/seq_file.h>
+#include <linux/ptdump.h>
+
 
 struct addr_marker {
 	unsigned long start_address;
@@ -21,15 +23,52 @@ struct ptdump_info {
 	unsigned long			base_addr;
 };
 
+struct prot_bits {
+	u64		mask;
+	u64		val;
+	const char	*set;
+	const char	*clear;
+};
+
+struct pg_level {
+	const struct prot_bits	*bits;
+	const char		*name;
+	size_t			num;
+	u64			mask;
+};
+
+/*
+ * The page dumper groups page table entries of the same type into a single
+ * description. It uses pg_state to track the range information while
+ * iterating over the pte entries. When the continuity is broken it then
+ * dumps out a description of the range.
+ */
+struct pg_state {
+	struct ptdump_state		ptdump;
+	struct seq_file			*seq;
+	const struct addr_marker	*marker;
+	unsigned long			start_address;
+	int				level;
+	u64				current_prot;
+	bool				check_wx;
+	unsigned long			wx_pages;
+	unsigned long			uxn_pages;
+};
+
 void ptdump_walk(struct seq_file *s, struct ptdump_info *info);
+void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
+	       u64 val);
 #ifdef CONFIG_PTDUMP_DEBUGFS
 #define EFI_RUNTIME_MAP_END	DEFAULT_MAP_WINDOW_64
 void __init ptdump_debugfs_register(struct ptdump_info *info, const char *name);
 #else
 static inline void ptdump_debugfs_register(struct ptdump_info *info,
 					   const char *name) { }
-#endif
+#endif /* CONFIG_PTDUMP_DEBUGFS */
 void ptdump_check_wx(void);
+#else
+static inline void note_page(void *pt_st, unsigned long addr,
+			     int level, u64 val) { }
 #endif /* CONFIG_PTDUMP_CORE */
 
 #ifdef CONFIG_DEBUG_WX
diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index e305b6593..64127c70b 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -66,31 +66,6 @@ static struct addr_marker address_markers[] = {
 		seq_printf(m, fmt);	\
 })
 
-/*
- * The page dumper groups page table entries of the same type into a single
- * description. It uses pg_state to track the range information while
- * iterating over the pte entries. When the continuity is broken it then
- * dumps out a description of the range.
- */
-struct pg_state {
-	struct ptdump_state ptdump;
-	struct seq_file *seq;
-	const struct addr_marker *marker;
-	unsigned long start_address;
-	int level;
-	u64 current_prot;
-	bool check_wx;
-	unsigned long wx_pages;
-	unsigned long uxn_pages;
-};
-
-struct prot_bits {
-	u64		mask;
-	u64		val;
-	const char	*set;
-	const char	*clear;
-};
-
 static const struct prot_bits pte_bits[] = {
 	{
 		.mask	= PTE_VALID,
@@ -170,13 +145,6 @@ static const struct prot_bits pte_bits[] = {
 	}
 };
 
-struct pg_level {
-	const struct prot_bits *bits;
-	const char *name;
-	size_t num;
-	u64 mask;
-};
-
 static struct pg_level pg_level[] = {
 	{ /* pgd */
 		.name	= "PGD",
@@ -248,8 +216,8 @@ static void note_prot_wx(struct pg_state *st, unsigned long addr)
 	st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
 }
 
-static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
-		      u64 val)
+void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
+	       u64 val)
 {
 	struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
 	static const char units[] = "KMGTPE";
-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:58:55 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:55 +0000
Subject: [PATCH v4 05/10] arm64: ptdump: Use the mask from the state structure
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-7-sebastianene@google.com>

Printing the descriptor attributes requires accessing a mask which has a
different set of attributes for stage-2. In preparation for adding support
for the stage-2 pagetables dumping, use the mask from the local context
and not from the globally defined pg_level array. Store a pointer to
the pg_level array in the ptdump state structure. This will allow us to
extract the mask which is wrapped in the pg_level array and use it for
descriptor parsing in the note_page.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/include/asm/ptdump.h |  1 +
 arch/arm64/mm/ptdump.c          | 13 ++++++++-----
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
index 23510be35..4e728d2a1 100644
--- a/arch/arm64/include/asm/ptdump.h
+++ b/arch/arm64/include/asm/ptdump.h
@@ -45,6 +45,7 @@ struct pg_level {
  */
 struct pg_state {
 	struct ptdump_state		ptdump;
+	struct pg_level			*pg_level;
 	struct seq_file			*seq;
 	const struct addr_marker	*marker;
 	unsigned long			start_address;
diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index 64127c70b..015ed65d3 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -220,11 +220,12 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
 	       u64 val)
 {
 	struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
+	struct pg_level *pg_info = st->pg_level;
 	static const char units[] = "KMGTPE";
 	u64 prot = 0;
 
 	if (level >= 0)
-		prot = val & pg_level[level].mask;
+		prot = val & pg_info[level].mask;
 
 	if (st->level == -1) {
 		st->level = level;
@@ -250,10 +251,10 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
 			unit++;
 		}
 		pt_dump_seq_printf(st->seq, "%9lu%c %s", delta, *unit,
-				   pg_level[st->level].name);
-		if (st->current_prot && pg_level[st->level].bits)
-			dump_prot(st, pg_level[st->level].bits,
-				  pg_level[st->level].num);
+				   pg_info[st->level].name);
+		if (st->current_prot && pg_info[st->level].bits)
+			dump_prot(st, pg_info[st->level].bits,
+				  pg_info[st->level].num);
 		pt_dump_seq_puts(st->seq, "\n");
 
 		if (addr >= st->marker[1].start_address) {
@@ -284,6 +285,7 @@ void ptdump_walk(struct seq_file *s, struct ptdump_info *info)
 	st = (struct pg_state){
 		.seq = s,
 		.marker = info->markers,
+		.pg_level = &pg_level[0],
 		.level = -1,
 		.ptdump = {
 			.note_page = note_page,
@@ -321,6 +323,7 @@ void ptdump_check_wx(void)
 			{ 0, NULL},
 			{ -1, NULL},
 		},
+		.pg_level = &pg_level[0],
 		.level = -1,
 		.check_wx = true,
 		.ptdump = {
-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:58:56 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:56 +0000
Subject: [PATCH v4 06/10] KVM: arm64: Move pagetable definitions to common header
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-8-sebastianene@google.com>

In preparation for using the stage-2 definitions in ptdump, move some of
these macros in the common header.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/include/asm/kvm_pgtable.h | 42 ++++++++++++++++++++++++++++
 arch/arm64/kvm/hyp/pgtable.c         | 42 ----------------------------
 2 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index f73efd8a8..37f2a8532 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -45,6 +45,48 @@ typedef u64 kvm_pte_t;
 
 #define KVM_PHYS_INVALID		(-1ULL)
 
+#define KVM_PTE_LEAF_ATTR_LO		GENMASK(11, 2)
+
+#define KVM_PTE_LEAF_ATTR_LO_S1_ATTRIDX	GENMASK(4, 2)
+#define KVM_PTE_LEAF_ATTR_LO_S1_AP	GENMASK(7, 6)
+#define KVM_PTE_LEAF_ATTR_LO_S1_AP_RO		\
+	({ cpus_have_final_cap(ARM64_KVM_HVHE) ? 2 : 3; })
+#define KVM_PTE_LEAF_ATTR_LO_S1_AP_RW		\
+	({ cpus_have_final_cap(ARM64_KVM_HVHE) ? 0 : 1; })
+#define KVM_PTE_LEAF_ATTR_LO_S1_SH	GENMASK(9, 8)
+#define KVM_PTE_LEAF_ATTR_LO_S1_SH_IS	3
+#define KVM_PTE_LEAF_ATTR_LO_S1_AF	BIT(10)
+
+#define KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR	GENMASK(5, 2)
+#define KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R	BIT(6)
+#define KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W	BIT(7)
+#define KVM_PTE_LEAF_ATTR_LO_S2_SH	GENMASK(9, 8)
+#define KVM_PTE_LEAF_ATTR_LO_S2_SH_IS	3
+#define KVM_PTE_LEAF_ATTR_LO_S2_AF	BIT(10)
+
+#define KVM_PTE_LEAF_ATTR_HI		GENMASK(63, 50)
+
+#define KVM_PTE_LEAF_ATTR_HI_SW		GENMASK(58, 55)
+
+#define KVM_PTE_LEAF_ATTR_HI_S1_XN	BIT(54)
+
+#define KVM_PTE_LEAF_ATTR_HI_S2_XN	BIT(54)
+
+#define KVM_PTE_LEAF_ATTR_HI_S1_GP	BIT(50)
+
+#define KVM_PTE_LEAF_ATTR_S2_PERMS	(KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R | \
+					 KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | \
+					 KVM_PTE_LEAF_ATTR_HI_S2_XN)
+
+#define KVM_INVALID_PTE_OWNER_MASK	GENMASK(9, 2)
+#define KVM_MAX_OWNER_ID		1
+
+/*
+ * Used to indicate a pte for which a 'break-before-make' sequence is in
+ * progress.
+ */
+#define KVM_INVALID_PTE_LOCKED		BIT(10)
+
 static inline bool kvm_pte_valid(kvm_pte_t pte)
 {
 	return pte & KVM_PTE_VALID;
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 82fef9620..ccd46bf56 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -17,48 +17,6 @@
 #define KVM_PTE_TYPE_PAGE		1
 #define KVM_PTE_TYPE_TABLE		1
 
-#define KVM_PTE_LEAF_ATTR_LO		GENMASK(11, 2)
-
-#define KVM_PTE_LEAF_ATTR_LO_S1_ATTRIDX	GENMASK(4, 2)
-#define KVM_PTE_LEAF_ATTR_LO_S1_AP	GENMASK(7, 6)
-#define KVM_PTE_LEAF_ATTR_LO_S1_AP_RO		\
-	({ cpus_have_final_cap(ARM64_KVM_HVHE) ? 2 : 3; })
-#define KVM_PTE_LEAF_ATTR_LO_S1_AP_RW		\
-	({ cpus_have_final_cap(ARM64_KVM_HVHE) ? 0 : 1; })
-#define KVM_PTE_LEAF_ATTR_LO_S1_SH	GENMASK(9, 8)
-#define KVM_PTE_LEAF_ATTR_LO_S1_SH_IS	3
-#define KVM_PTE_LEAF_ATTR_LO_S1_AF	BIT(10)
-
-#define KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR	GENMASK(5, 2)
-#define KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R	BIT(6)
-#define KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W	BIT(7)
-#define KVM_PTE_LEAF_ATTR_LO_S2_SH	GENMASK(9, 8)
-#define KVM_PTE_LEAF_ATTR_LO_S2_SH_IS	3
-#define KVM_PTE_LEAF_ATTR_LO_S2_AF	BIT(10)
-
-#define KVM_PTE_LEAF_ATTR_HI		GENMASK(63, 50)
-
-#define KVM_PTE_LEAF_ATTR_HI_SW		GENMASK(58, 55)
-
-#define KVM_PTE_LEAF_ATTR_HI_S1_XN	BIT(54)
-
-#define KVM_PTE_LEAF_ATTR_HI_S2_XN	BIT(54)
-
-#define KVM_PTE_LEAF_ATTR_HI_S1_GP	BIT(50)
-
-#define KVM_PTE_LEAF_ATTR_S2_PERMS	(KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R | \
-					 KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | \
-					 KVM_PTE_LEAF_ATTR_HI_S2_XN)
-
-#define KVM_INVALID_PTE_OWNER_MASK	GENMASK(9, 2)
-#define KVM_MAX_OWNER_ID		1
-
-/*
- * Used to indicate a pte for which a 'break-before-make' sequence is in
- * progress.
- */
-#define KVM_INVALID_PTE_LOCKED		BIT(10)
-
 struct kvm_pgtable_walk_data {
 	struct kvm_pgtable_walker	*walker;
 
-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:58:57 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:57 +0000
Subject: [PATCH v4 07/10] KVM: arm64: Walk the pagetable snapshot and parse
 the ptdump descriptors
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-9-sebastianene@google.com>

Define the attributes for the stage-2 pagetables that will be used by
the ptdump parser code to interepret and show the descriptors. Build the
pagetable level description dynamically and use the KVM pagetable walker
to visit the PTEs. Display the number of the bits used by the IPA
address space and the start level.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/kvm/ptdump.c | 135 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 134 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index e99bab427..80c338e03 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -40,6 +40,66 @@ static struct kvm_pgtable_mm_ops ptdump_host_mmops = {
 	.virt_to_phys	= get_host_pa,
 };
 
+static const struct prot_bits stage2_pte_bits[] = {
+	{
+		.mask	= PTE_VALID,
+		.val	= PTE_VALID,
+		.set	= " ",
+		.clear	= "F",
+	}, {
+		.mask	= KVM_PTE_LEAF_ATTR_HI_S2_XN,
+		.val	= KVM_PTE_LEAF_ATTR_HI_S2_XN,
+		.set	= "XN",
+		.clear	= "  ",
+	}, {
+		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R,
+		.val	= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R,
+		.set	= "R",
+		.clear	= " ",
+	}, {
+		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W,
+		.val	= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W,
+		.set	= "W",
+		.clear	= " ",
+	}, {
+		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_AF,
+		.val	= KVM_PTE_LEAF_ATTR_LO_S2_AF,
+		.set	= "AF",
+		.clear	= "  ",
+	}, {
+		.mask	= PTE_NG,
+		.val	= PTE_NG,
+		.set	= "FnXS",
+		.clear	= "  ",
+	}, {
+		.mask	= PTE_CONT,
+		.val	= PTE_CONT,
+		.set	= "CON",
+		.clear	= "   ",
+	}, {
+		.mask	= PTE_TABLE_BIT,
+		.val	= PTE_TABLE_BIT,
+		.set	= "   ",
+		.clear	= "BLK",
+	}, {
+		.mask	= KVM_PGTABLE_PROT_SW0,
+		.val	= KVM_PGTABLE_PROT_SW0,
+		.set	= "SW0", /* PKVM_PAGE_SHARED_OWNED */
+	}, {
+		.mask   = KVM_PGTABLE_PROT_SW1,
+		.val	= KVM_PGTABLE_PROT_SW1,
+		.set	= "SW1", /* PKVM_PAGE_SHARED_BORROWED */
+	}, {
+		.mask	= KVM_PGTABLE_PROT_SW2,
+		.val	= KVM_PGTABLE_PROT_SW2,
+		.set	= "SW2",
+	}, {
+		.mask   = KVM_PGTABLE_PROT_SW3,
+		.val	= KVM_PGTABLE_PROT_SW3,
+		.set	= "SW3",
+	},
+};
+
 static int kvm_ptdump_open(struct inode *inode, struct file *file)
 {
 	struct kvm_ptdump_register *reg = inode->i_private;
@@ -73,9 +133,82 @@ static int kvm_ptdump_release(struct inode *inode, struct file *file)
 	return 0;
 }
 
+static int kvm_ptdump_build_levels(struct pg_level *level, unsigned int start_level)
+{
+	static const char * const level_names[] = {"PGD", "PUD", "PMD", "PTE"};
+	int i, j, name_index;
+
+	if (start_level > 2) {
+		pr_err("invalid start_level %u\n", start_level);
+		return -EINVAL;
+	}
+
+	for (i = start_level; i < KVM_PGTABLE_MAX_LEVELS; i++) {
+		name_index = i - start_level;
+		name_index += name_index * start_level;
+
+		level[i].name	= level_names[name_index];
+		level[i].num	= ARRAY_SIZE(stage2_pte_bits);
+		level[i].bits	= stage2_pte_bits;
+
+		for (j = 0; j < level[i].num; j++)
+			level[i].mask |= level[i].bits[j].mask;
+	}
+
+	return 0;
+}
+
+static int kvm_ptdump_visitor(const struct kvm_pgtable_visit_ctx *ctx,
+			      enum kvm_pgtable_walk_flags visit)
+{
+	struct pg_state *st = ctx->arg;
+	struct ptdump_state *pt_st = &st->ptdump;
+
+	note_page(pt_st, ctx->addr, ctx->level, ctx->old);
+	return 0;
+}
+
 static int kvm_ptdump_show(struct seq_file *m, void *)
 {
-	return -EINVAL;
+	u64 ipa_size;
+	char ipa_description[32];
+	struct pg_state st;
+	struct addr_marker ipa_addr_markers[3] = {0};
+	struct pg_level pg_level_descr[KVM_PGTABLE_MAX_LEVELS] = {0};
+	struct kvm_pgtable_snapshot *snapshot = m->private;
+	struct kvm_pgtable *pgtable = &snapshot->pgtable;
+	struct kvm_pgtable_walker walker = (struct kvm_pgtable_walker) {
+		.cb	= kvm_ptdump_visitor,
+		.arg	= &st,
+		.flags	= KVM_PGTABLE_WALK_LEAF,
+	};
+
+	if (kvm_ptdump_build_levels(pg_level_descr, pgtable->start_level) < 0)
+		return -EINVAL;
+
+	snprintf(ipa_description, sizeof(ipa_description),
+		 "IPA bits %2u start lvl %1u", pgtable->ia_bits,
+		 pgtable->start_level);
+
+	ipa_size = BIT(pgtable->ia_bits);
+	ipa_addr_markers[0].name = ipa_description;
+	ipa_addr_markers[1].start_address = ipa_size;
+
+	st = (struct pg_state) {
+		.seq		= m,
+		.marker		= &ipa_addr_markers[0],
+		.level		= -1,
+		.pg_level	= &pg_level_descr[0],
+		.ptdump	= {
+			.note_page	= note_page,
+			.range		= (struct ptdump_range[]) {
+				{0, ipa_size},
+				{0, 0},
+			},
+		},
+	};
+
+	return kvm_pgtable_walk(pgtable, 0, ipa_size, &walker);
 }
 
 static void kvm_ptdump_debugfs_register(struct kvm_ptdump_register *reg,
-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:58:58 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:58 +0000
Subject: [PATCH v4 08/10] arm64: ptdump: Interpret memory attributes based on
 the runtime config
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-10-sebastianene@google.com>

Introduce two callbacks that verify the current runtime configuration
before parsing the attribute fields. This is used to check when FWB is
enabled which changes the interpretation of the descriptor bits.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/include/asm/ptdump.h |  7 +++++++
 arch/arm64/kvm/ptdump.c         | 32 ++++++++++++++++++++++++++++++++
 arch/arm64/mm/ptdump.c          |  6 ++++++
 3 files changed, 45 insertions(+)

diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
index 4e728d2a1..e150fc21f 100644
--- a/arch/arm64/include/asm/ptdump.h
+++ b/arch/arm64/include/asm/ptdump.h
@@ -23,11 +23,18 @@ struct ptdump_info {
 	unsigned long			base_addr;
 };
 
+/* Forward declaration */
+struct pg_state;
+
 struct prot_bits {
 	u64		mask;
 	u64		val;
 	const char	*set;
 	const char	*clear;
+	/* bit ignored if the callback returns false */
+	bool		(*feature_on)(const struct pg_state *ctxt);
+	/* bit ignored if the callback returns true */
+	bool		(*feature_off)(const struct pg_state *ctxt);
 };
 
 struct pg_level {
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index 80c338e03..0ad7944e5 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -40,6 +40,18 @@ static struct kvm_pgtable_mm_ops ptdump_host_mmops = {
 	.virt_to_phys	= get_host_pa,
 };
 
+static bool is_fwb_enabled(const struct pg_state *m)
+{
+	struct kvm_pgtable_snapshot *snapshot = m->seq->private;
+	struct kvm_pgtable *pgtable = &snapshot->pgtable;
+	bool fwb_enabled = false;
+
+	if (cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
+		fwb_enabled = !(pgtable->flags & KVM_PGTABLE_S2_NOFWB);
+
+	return fwb_enabled;
+}
+
 static const struct prot_bits stage2_pte_bits[] = {
 	{
 		.mask	= PTE_VALID,
@@ -81,6 +93,26 @@ static const struct prot_bits stage2_pte_bits[] = {
 		.val	= PTE_TABLE_BIT,
 		.set	= "   ",
 		.clear	= "BLK",
+	}, {
+		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR | PTE_VALID,
+		.val	= PTE_S2_MEMATTR(MT_S2_DEVICE_nGnRE) | PTE_VALID,
+		.set	= "DEVICE/nGnRE",
+		.feature_off	= is_fwb_enabled,
+	}, {
+		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR | PTE_VALID,
+		.val	= PTE_S2_MEMATTR(MT_S2_FWB_DEVICE_nGnRE) | PTE_VALID,
+		.set	= "DEVICE/nGnRE FWB",
+		.feature_on	= is_fwb_enabled,
+	}, {
+		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR | PTE_VALID,
+		.val	= PTE_S2_MEMATTR(MT_S2_NORMAL) | PTE_VALID,
+		.set	= "MEM/NORMAL",
+		.feature_off	= is_fwb_enabled,
+	}, {
+		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR | PTE_VALID,
+		.val	= PTE_S2_MEMATTR(MT_S2_FWB_NORMAL) | PTE_VALID,
+		.set	= "MEM/NORMAL FWB",
+		.feature_on	= is_fwb_enabled,
 	}, {
 		.mask	= KVM_PGTABLE_PROT_SW0,
 		.val	= KVM_PGTABLE_PROT_SW0,
diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index 015ed65d3..6c7208f66 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -177,6 +177,12 @@ static void dump_prot(struct pg_state *st, const struct prot_bits *bits,
 	for (i = 0; i < num; i++, bits++) {
 		const char *s;
 
+		if (bits->feature_on && !bits->feature_on(st))
+			continue;
+
+		if (bits->feature_off && bits->feature_off(st))
+			continue;
+
 		if ((st->current_prot & bits->mask) == bits->val)
 			s = bits->set;
 		else
-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:58:59 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:58:59 +0000
Subject: [PATCH v4 09/10] arm64: ptdump: Interpret pKVM ownership annotations
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-11-sebastianene@google.com>

When pKVM is enabled the software bits are used to keep track of the
page sharing state. Interepret these fields when pKVM is enabled and
print the sharing state. Move the definitions to common pagetable
header.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/include/asm/kvm_pgtable.h          | 26 ++++++++++
 arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 26 ----------
 arch/arm64/kvm/ptdump.c                       | 47 +++++++++++++++++--
 3 files changed, 69 insertions(+), 30 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index 37f2a8532..7f654d4aa 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -87,6 +87,13 @@ typedef u64 kvm_pte_t;
  */
 #define KVM_INVALID_PTE_LOCKED		BIT(10)
 
+/* This corresponds to page-table locking order */
+enum pkvm_component_id {
+	PKVM_ID_HOST,
+	PKVM_ID_HYP,
+	PKVM_ID_FFA,
+};
+
 static inline bool kvm_pte_valid(kvm_pte_t pte)
 {
 	return pte & KVM_PTE_VALID;
@@ -230,6 +237,25 @@ enum kvm_pgtable_prot {
 	KVM_PGTABLE_PROT_SW3			= BIT(58),
 };
 
+/*
+ * SW bits 0-1 are reserved to track the memory ownership state of each page:
+ *   00: The page is owned exclusively by the page-table owner.
+ *   01: The page is owned by the page-table owner, but is shared
+ *       with another entity.
+ *   10: The page is shared with, but not owned by the page-table owner.
+ *   11: Reserved for future use (lending).
+ */
+enum pkvm_page_state {
+	PKVM_PAGE_OWNED			= 0ULL,
+	PKVM_PAGE_SHARED_OWNED		= KVM_PGTABLE_PROT_SW0,
+	PKVM_PAGE_SHARED_BORROWED	= KVM_PGTABLE_PROT_SW1,
+	__PKVM_PAGE_RESERVED		= KVM_PGTABLE_PROT_SW0 |
+					  KVM_PGTABLE_PROT_SW1,
+
+	/* Meta-states which aren't encoded directly in the PTE's SW bits */
+	PKVM_NOPAGE,
+};
+
 #define KVM_PGTABLE_PROT_RW	(KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W)
 #define KVM_PGTABLE_PROT_RWX	(KVM_PGTABLE_PROT_RW | KVM_PGTABLE_PROT_X)
 
diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
index ca8f76915..677686b86 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
@@ -14,25 +14,6 @@
 #include <nvhe/pkvm.h>
 #include <nvhe/spinlock.h>
 
-/*
- * SW bits 0-1 are reserved to track the memory ownership state of each page:
- *   00: The page is owned exclusively by the page-table owner.
- *   01: The page is owned by the page-table owner, but is shared
- *       with another entity.
- *   10: The page is shared with, but not owned by the page-table owner.
- *   11: Reserved for future use (lending).
- */
-enum pkvm_page_state {
-	PKVM_PAGE_OWNED			= 0ULL,
-	PKVM_PAGE_SHARED_OWNED		= KVM_PGTABLE_PROT_SW0,
-	PKVM_PAGE_SHARED_BORROWED	= KVM_PGTABLE_PROT_SW1,
-	__PKVM_PAGE_RESERVED		= KVM_PGTABLE_PROT_SW0 |
-					  KVM_PGTABLE_PROT_SW1,
-
-	/* Meta-states which aren't encoded directly in the PTE's SW bits */
-	PKVM_NOPAGE,
-};
-
 #define PKVM_PAGE_STATE_PROT_MASK	(KVM_PGTABLE_PROT_SW0 | KVM_PGTABLE_PROT_SW1)
 static inline enum kvm_pgtable_prot pkvm_mkstate(enum kvm_pgtable_prot prot,
 						 enum pkvm_page_state state)
@@ -53,13 +34,6 @@ struct host_mmu {
 };
 extern struct host_mmu host_mmu;
 
-/* This corresponds to page-table locking order */
-enum pkvm_component_id {
-	PKVM_ID_HOST,
-	PKVM_ID_HYP,
-	PKVM_ID_FFA,
-};
-
 extern unsigned long hyp_nr_cpus;
 
 int __pkvm_prot_finalize(void);
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index 0ad7944e5..4296e739f 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -52,6 +52,11 @@ static bool is_fwb_enabled(const struct pg_state *m)
 	return fwb_enabled;
 }
 
+static bool is_pkvm_enabled(const struct pg_state *m)
+{
+	return is_protected_kvm_enabled();
+}
+
 static const struct prot_bits stage2_pte_bits[] = {
 	{
 		.mask	= PTE_VALID,
@@ -113,22 +118,56 @@ static const struct prot_bits stage2_pte_bits[] = {
 		.val	= PTE_S2_MEMATTR(MT_S2_FWB_NORMAL) | PTE_VALID,
 		.set	= "MEM/NORMAL FWB",
 		.feature_on	= is_fwb_enabled,
+	}, {
+		.mask	= KVM_INVALID_PTE_OWNER_MASK | PTE_VALID,
+		.val	= FIELD_PREP_CONST(KVM_INVALID_PTE_OWNER_MASK,
+					   PKVM_ID_HYP),
+		.set	= "HYP",
+	}, {
+		.mask	= KVM_INVALID_PTE_OWNER_MASK | PTE_VALID,
+		.val	= FIELD_PREP_CONST(KVM_INVALID_PTE_OWNER_MASK,
+					   PKVM_ID_FFA),
+		.set	= "FF-A",
+	}, {
+		.mask	= __PKVM_PAGE_RESERVED | PTE_VALID,
+		.val	= PKVM_PAGE_OWNED | PTE_VALID,
+		.set	= "PKVM_PAGE_OWNED",
+		.feature_on	= is_pkvm_enabled,
+	}, {
+		.mask   = __PKVM_PAGE_RESERVED | PTE_VALID,
+		.val	= PKVM_PAGE_SHARED_OWNED | PTE_VALID,
+		.set	= "PKVM_PAGE_SHARED_OWNED",
+		.feature_on     = is_pkvm_enabled,
+	}, {
+		.mask	= __PKVM_PAGE_RESERVED | PTE_VALID,
+		.val	= PKVM_PAGE_SHARED_BORROWED | PTE_VALID,
+		.set	= "PKVM_PAGE_SHARED_BORROWED",
+		.feature_on     = is_pkvm_enabled,
+	}, {
+		.mask	= PKVM_NOPAGE | PTE_VALID,
+		.val	= PKVM_NOPAGE,
+		.set	= "PKVM_NOPAGE",
+		.feature_on     = is_pkvm_enabled,
 	}, {
 		.mask	= KVM_PGTABLE_PROT_SW0,
 		.val	= KVM_PGTABLE_PROT_SW0,
-		.set	= "SW0", /* PKVM_PAGE_SHARED_OWNED */
+		.set    = "SW0",
+		.feature_off	= is_pkvm_enabled,
 	}, {
-		.mask   = KVM_PGTABLE_PROT_SW1,
+		.mask	= KVM_PGTABLE_PROT_SW1,
 		.val	= KVM_PGTABLE_PROT_SW1,
-		.set	= "SW1", /* PKVM_PAGE_SHARED_BORROWED */
+		.set	= "SW1",
+		.feature_off	= is_pkvm_enabled,
 	}, {
-		.mask	= KVM_PGTABLE_PROT_SW2,
+		.mask   = KVM_PGTABLE_PROT_SW2,
 		.val	= KVM_PGTABLE_PROT_SW2,
 		.set	= "SW2",
+		.feature_off	= is_pkvm_enabled,
 	}, {
 		.mask   = KVM_PGTABLE_PROT_SW3,
 		.val	= KVM_PGTABLE_PROT_SW3,
 		.set	= "SW3",
+		.feature_off	= is_pkvm_enabled,
 	},
 };
 
-- 
2.43.0.472.g3155946c3a-goog



From sebastianene at google.com  Mon Dec 18 05:59:00 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Mon, 18 Dec 2023 13:59:00 +0000
Subject: [PATCH v4 10/10] arm64: ptdump: Add guest stage-2 pagetables dumping
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <20231218135859.2513568-12-sebastianene@google.com>

Register a debugfs file on guest creation to be able to view their
second translation tables with ptdump. This assumes that the host is in
control of the guest stage-2 and has direct access to the pagetables.

Signed-off-by: Sebastian Ene <sebastianene at google.com>
---
 arch/arm64/kvm/debug.c      |  6 ++++++
 arch/arm64/kvm/kvm_ptdump.h |  3 +++
 arch/arm64/kvm/ptdump.c     | 35 ++++++++++++++++++++++++++++++++---
 3 files changed, 41 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 8725291cb..7c4c2902d 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -13,6 +13,7 @@
 #include <asm/kvm_asm.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_emulate.h>
+#include <kvm_ptdump.h>
 
 #include "trace.h"
 
@@ -342,3 +343,8 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
 	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_SPE);
 	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
 }
+
+int kvm_arch_create_vm_debugfs(struct kvm *kvm)
+{
+	return kvm_ptdump_register_guest(kvm);
+}
diff --git a/arch/arm64/kvm/kvm_ptdump.h b/arch/arm64/kvm/kvm_ptdump.h
index 98b595ce8..5f5a455d0 100644
--- a/arch/arm64/kvm/kvm_ptdump.h
+++ b/arch/arm64/kvm/kvm_ptdump.h
@@ -6,13 +6,16 @@
 #ifndef __KVM_PTDUMP_H
 #define __KVM_PTDUMP_H
 
+#include <linux/kvm_host.h>
 #include <asm/ptdump.h>
 
 
 #ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
 void kvm_ptdump_register_host(void);
+int kvm_ptdump_register_guest(struct kvm *kvm);
 #else
 static inline void kvm_ptdump_register_host(void) { }
+static inline int kvm_ptdump_register_guest(struct kvm *kvm) { return -1; }
 #endif /* CONFIG_PTDUMP_STAGE2_DEBUGFS */
 
 #endif /* __KVM_PTDUMP_H */
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index 4296e739f..62a753d6b 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -181,6 +181,8 @@ static int kvm_ptdump_open(struct inode *inode, struct file *file)
 		info = reg->get_ptdump_info(reg);
 		if (!info)
 			return -ENOMEM;
+	} else {
+		info = inode->i_private;
 	}
 
 	if (!reg->show_ptdump_info)
@@ -239,15 +241,14 @@ static int kvm_ptdump_visitor(const struct kvm_pgtable_visit_ctx *ctx,
 	return 0;
 }
 
-static int kvm_ptdump_show(struct seq_file *m, void *)
+static int kvm_ptdump_show_common(struct seq_file *m,
+				  struct kvm_pgtable *pgtable)
 {
 	u64 ipa_size;
 	char ipa_description[32];
 	struct pg_state st;
 	struct addr_marker ipa_addr_markers[3] = {0};
 	struct pg_level pg_level_descr[KVM_PGTABLE_MAX_LEVELS] = {0};
-	struct kvm_pgtable_snapshot *snapshot = m->private;
-	struct kvm_pgtable *pgtable = &snapshot->pgtable;
 	struct kvm_pgtable_walker walker = (struct kvm_pgtable_walker) {
 		.cb	= kvm_ptdump_visitor,
 		.arg	= &st,
@@ -282,6 +283,26 @@ static int kvm_ptdump_show(struct seq_file *m, void *)
 	return kvm_pgtable_walk(pgtable, 0, ipa_size, &walker);
 }
 
+static int kvm_host_ptdump_show(struct seq_file *m, void *)
+{
+	struct kvm_pgtable_snapshot *snapshot = m->private;
+
+	return kvm_ptdump_show_common(m, &snapshot->pgtable);
+}
+
+static int kvm_ptdump_show(struct seq_file *m, void *)
+{
+	struct kvm *guest_kvm = m->private;
+	struct kvm_s2_mmu *mmu = &guest_kvm->arch.mmu;
+	int ret;
+
+	write_lock(&guest_kvm->mmu_lock);
+	ret = kvm_ptdump_show_common(m, mmu->pgt);
+	write_unlock(&guest_kvm->mmu_lock);
+
+	return ret;
+}
+
 static void kvm_ptdump_debugfs_register(struct kvm_ptdump_register *reg,
 					const char *name, struct dentry *parent)
 {
@@ -393,11 +414,19 @@ void kvm_ptdump_register_host(void)
 
 	host_reg.get_ptdump_info = kvm_host_get_ptdump_info;
 	host_reg.put_ptdump_info = kvm_host_put_ptdump_info;
+	host_reg.show_ptdump_info = kvm_host_ptdump_show;
 
 	kvm_ptdump_debugfs_register(&host_reg, "host_page_tables",
 				    kvm_debugfs_dir);
 }
 
+int kvm_ptdump_register_guest(struct kvm *kvm)
+{
+	debugfs_create_file("stage2_page_tables", 0400, kvm->debugfs_dentry,
+			    kvm, &kvm_ptdump_fops);
+	return 0;
+}
+
 static int __init kvm_host_ptdump_init(void)
 {
 	host_reg.priv = (void *)host_s2_pgtable_pages();
-- 
2.43.0.472.g3155946c3a-goog



From miquel.raynal at bootlin.com  Mon Dec 18 06:02:23 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Mon, 18 Dec 2023 15:02:23 +0100
Subject: [PATCH 3/4] nvmem: u-boot-env: use more nvmem subsystem helpers
In-Reply-To: <20231218133722.16150-3-zajec5@gmail.com>
References: <20231218133722.16150-1-zajec5@gmail.com>
	<20231218133722.16150-3-zajec5@gmail.com>
Message-ID: <20231218150223.000aacf0@xps-13>

Hi Rafa?,

zajec5 at gmail.com wrote on Mon, 18 Dec 2023 14:37:21 +0100:

> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> 1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
>    mtd dependent
> 2. Use nvmem_add_one_cell() to simplify adding NVMEM cells
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>

Thanks,
Miqu?l


From miquel.raynal at bootlin.com  Mon Dec 18 06:03:12 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Mon, 18 Dec 2023 15:03:12 +0100
Subject: [PATCH 2/4] nvmem: core: add nvmem_dev_size() helper
In-Reply-To: <20231218133722.16150-2-zajec5@gmail.com>
References: <20231218133722.16150-1-zajec5@gmail.com>
	<20231218133722.16150-2-zajec5@gmail.com>
Message-ID: <20231218150312.01bc1472@xps-13>

Hi Rafa?,

zajec5 at gmail.com wrote on Mon, 18 Dec 2023 14:37:20 +0100:

> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> This is required by layouts that need to read whole NVMEM content. It's
> especially useful for NVMEM devices without hardcoded layout (like
> U-Boot environment data block).

Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>

> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

Thanks,
Miqu?l


From linus.walleij at linaro.org  Mon Dec 18 06:09:25 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 18 Dec 2023 15:09:25 +0100
Subject: [GIT PULL] pinctrl: samsung: drivers for v6.8
In-Reply-To: <20231218094548.37105-1-krzysztof.kozlowski@linaro.org>
References: <20231218094548.37105-1-krzysztof.kozlowski@linaro.org>
Message-ID: <CACRpkdZwRJ1U8n=HP8TzqNVK4J5RqhiJYBdH0COexMH7TyDknw@mail.gmail.com>

On Mon, Dec 18, 2023 at 10:45?AM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:

> Google and Samsung SoC pinctrl changes for v6.8.

Pulled in to my "devel" branch for V6.8!

Excellent work as always, thanks for keeping the Samsung Exynos in order,
there are so many users of this SoC now that without your coordination
it would be complete chaos.

Yours,
Linus Walleij


From dmitry.baryshkov at linaro.org  Mon Dec 18 06:21:00 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Mon, 18 Dec 2023 16:21:00 +0200
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <aa8b2ccd-33da-404b-9a93-3d88cf63ec77@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
 <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
 <aa8b2ccd-33da-404b-9a93-3d88cf63ec77@quicinc.com>
Message-ID: <8338db1e-0216-4fc5-b6ab-ddf43adf3648@linaro.org>

On 18/12/2023 13:23, Bibek Kumar Patro wrote:
> 
> 
> On 12/16/2023 9:45 PM, Dmitry Baryshkov wrote:
>> On 16/12/2023 02:03, Konrad Dybcio wrote:
>>> On 15.12.2023 13:54, Robin Murphy wrote:
>>>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>>>>
>>>>>
>>>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>>>>> <quic_bibekkum at quicinc.com> wrote:
>>>>>>>
>>>>>>> Add ACTLR data table for SM8550 along with support for
>>>>>>> same including SM8550 specific implementation operations.
>>>>>>>
>>>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>>>>> ---
>>>>>>> ?? drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 
>>>>>>> ++++++++++++++++++++++
>>>>>>> ?? 1 file changed, 89 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
>>>>>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>> index cb49291f5233..d2006f610243 100644
>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>>>>> ????????? u32 actlr;
>>>>>>> ?? };
>>>>>>>
>>>>>>> +/*
>>>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching 
>>>>>>> in the
>>>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the 
>>>>>>> prefetch
>>>>>>> + * buffer). The remaining bits are implementation defined and 
>>>>>>> vary across
>>>>>>> + * SoCs.
>>>>>>> + */
>>>>>>> +
>>>>>>> +#define PREFETCH_DEFAULT?????? 0
>>>>>>> +#define PREFETCH_SHALLOW?????? BIT(8)
>>>>>>> +#define PREFETCH_MODERATE????? BIT(9)
>>>>>>> +#define PREFETCH_DEEP????????? (BIT(9) | BIT(8))
>>>>>>
>>>>>> I thin the following might be more correct:
>>>>>>
>>>>>> #include <linux/bitfield.h>
>>>>>>
>>>>>> #define PREFETCH_MASK GENMASK(9, 8)
>>>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>>>>
>>>>>
>>>>> Ack, thanks for this suggestion. Let me try this out using
>>>>> GENMASK. Once tested, will take care of this in next version.
>>>>
>>>> FWIW the more typical usage would be to just define the named macros 
>>>> for the raw field values, then put the FIELD_PREP() at the point of 
>>>> use. However in this case that's liable to get pretty verbose, so 
>>>> although I'm usually a fan of bitfield.h, the most readable option 
>>>> here might actually be to stick with simpler definitions of "(0 << 
>>>> 8)", "(1 << 8)", etc. However it's not really a big deal either way, 
>>>> and I defer to whatever Dmitry and Konrad prefer, since they're the 
>>>> ones looking after arm-smmu-qcom the most :)
>>> My 5 cents would be to just use the "common" style of doing this, so:
>>>
>>> #define ACTRL_PREFETCH??? GENMASK(9, 8)
>>> ? #define PREFETCH_DEFAULT 0
>>> ? #define PREFETCH_SHALLOW 1
>>> ? #define PREFETCH_MODERATE 2
>>> ? #define PREFETCH_DEEP 3
>>>
>>> and then use
>>>
>>> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
>>>
>>> it can get verbose, but.. arguably that's good, since you really want
>>> to make sure the right bits are set here
>>
>> Sounds good to me.
>>
> 
> Konrad, Dimitry, just checked FIELD_PREP() implementation
> 
> #define FIELD_FIT(_mask, _val)
> ({????????????????????????????????????????????????????????????? \
>  ???????????????? __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");? \
>  ???????????????? ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
> })
> 
> since it is defined as a block, it won't be possible to use FIELD_PREP
> in macro or as a structure value, and can only be used inside a 
> block/function. Orelse would show compilation errors as following
> 
> kernel/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c:94:20: note: in 
> expansion of macro 'PREFETCH_SHALLOW'
>  ? { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>  ??????????????????? ^
> kernel/include/linux/bitfield.h:113:2: error: braced-group within 
> expression allowed only inside a function
>  ? ({??????? \
>  ? ^
> 
> So as per my understanding I think, we might need to go ahead with the
> generic implementation only. Let me know if I missed something.

Then anyway (foo << bar) is better compared to BIT(n) | BIT(m).

-- 
With best wishes
Dmitry



From miquel.raynal at bootlin.com  Mon Dec 18 06:21:16 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Mon, 18 Dec 2023 15:21:16 +0100
Subject: [PATCH 4/4] nvmem: layouts: add U-Boot env layout
In-Reply-To: <20231218133722.16150-4-zajec5@gmail.com>
References: <20231218133722.16150-1-zajec5@gmail.com>
	<20231218133722.16150-4-zajec5@gmail.com>
Message-ID: <20231218152116.59d59bad@xps-13>

Hi Rafa?,

zajec5 at gmail.com wrote on Mon, 18 Dec 2023 14:37:22 +0100:

> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> This patch moves all generic (NVMEM devices independent) code from NVMEM
> device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
> code on top of it.
> 
> Thanks to proper layout it's possible to support U-Boot env data stored
> on any kind of NVMEM device.
> 
> For backward compatibility with old DT bindings we need to keep old
> NVMEM device driver functional. To avoid code duplication a parsing
> function is exported and reused in it.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> ---

I have a couple of comments about the original driver which gets
copy-pasted in the new layout driver, maybe you could clean these
(the memory leak should be fixed before the migration so it can be
backported easily, the others are just style so it can be done after, I
don't mind).

...

> +int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
> +		     enum u_boot_env_format format)
> +{
> +	size_t crc32_data_offset;
> +	size_t crc32_data_len;
> +	size_t crc32_offset;
> +	size_t data_offset;
> +	size_t data_len;
> +	size_t dev_size;
> +	uint32_t crc32;
> +	uint32_t calc;
> +	uint8_t *buf;
> +	int bytes;
> +	int err;
> +
> +	dev_size = nvmem_dev_size(nvmem);
> +
> +	buf = kcalloc(1, dev_size, GFP_KERNEL);

Out of curiosity, why kcalloc(1,...) rather than kzalloc() ?

> +	if (!buf) {
> +		err = -ENOMEM;
> +		goto err_out;

We could directly return ENOMEM here I guess.

> +	}
> +
> +	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
> +	if (bytes < 0)
> +		return bytes;
> +	else if (bytes != dev_size)
> +		return -EIO;

Don't we need to free buf in the above cases?

> +	switch (format) {
> +	case U_BOOT_FORMAT_SINGLE:
> +		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
> +		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
> +		data_offset = offsetof(struct u_boot_env_image_single, data);
> +		break;
> +	case U_BOOT_FORMAT_REDUNDANT:
> +		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
> +		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
> +		data_offset = offsetof(struct u_boot_env_image_redundant, data);
> +		break;
> +	case U_BOOT_FORMAT_BROADCOM:
> +		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
> +		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
> +		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
> +		break;
> +	}
> +	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));

Looks a bit convoluted, any chances we can use intermediate variables
to help decipher this?

> +	crc32_data_len = dev_size - crc32_data_offset;
> +	data_len = dev_size - data_offset;
> +
> +	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
> +	if (calc != crc32) {
> +		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
> +		err = -EINVAL;
> +		goto err_kfree;
> +	}
> +
> +	buf[dev_size - 1] = '\0';
> +	err = u_boot_env_parse_cells(dev, nvmem, buf, data_offset, data_len);
> +	if (err)
> +		dev_err(dev, "Failed to add cells: %d\n", err);

Please drop this error message, the only reason for which the function
call would fail is apparently an ENOMEM case.

> +
> +err_kfree:
> +	kfree(buf);
> +err_out:
> +	return err;
> +}
> +EXPORT_SYMBOL_GPL(u_boot_env_parse);
> +
> +static int u_boot_env_add_cells(struct device *dev, struct nvmem_device *nvmem)
> +{
> +	const struct of_device_id *match;
> +	struct device_node *layout_np;
> +	enum u_boot_env_format format;
> +
> +	layout_np = of_nvmem_layout_get_container(nvmem);
> +	if (!layout_np)
> +		return -ENOENT;
> +
> +	match = of_match_node(u_boot_env_of_match_table, layout_np);
> +	if (!match)
> +		return -ENOENT;
> +
> +	format = (uintptr_t)match->data;

In the core there is currently an unused helper called
nvmem_layout_get_match_data() which does that. I think the original
intent of this function was to be used in this driver, so depending on
your preference, can you please either use it or remove it?

> +
> +	of_node_put(layout_np);
> +
> +	return u_boot_env_parse(dev, nvmem, format);
> +}

Thanks,
Miqu?l


From maxime.chevallier at bootlin.com  Mon Dec 18 06:21:12 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Mon, 18 Dec 2023 15:21:12 +0100
Subject: [PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support
 for 2.5G SGMII
In-Reply-To: <20231218071118.21879-1-quic_snehshah@quicinc.com>
References: <20231218071118.21879-1-quic_snehshah@quicinc.com>
Message-ID: <20231218152112.4adc5961@device-28.home>

Hi,

On Mon, 18 Dec 2023 12:41:18 +0530
Sneh Shah <quic_snehshah at quicinc.com> wrote:

> Serdes phy needs to operate at 2500 mode for 2.5G speed and 1000
> mode for 1G/100M/10M speed.
> Added changes to configure serdes phy and mac based on link speed.
> 
> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> ---
>  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 31 +++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index d3bf42d0fceb..b3a28dc19161 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -21,6 +21,7 @@
>  #define RGMII_IO_MACRO_CONFIG2		0x1C
>  #define RGMII_IO_MACRO_DEBUG1		0x20
>  #define EMAC_SYSTEM_LOW_POWER_DEBUG	0x28
> +#define ETHQOS_MAC_AN_CTRL		0xE0
>  
>  /* RGMII_IO_MACRO_CONFIG fields */
>  #define RGMII_CONFIG_FUNC_CLK_EN		BIT(30)
> @@ -78,6 +79,10 @@
>  #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
>  #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
>  
> +/*ETHQOS_MAC_AN_CTRL bits */
> +#define ETHQOS_MAC_AN_CTRL_RAN			BIT(9)
> +#define ETHQOS_MAC_AN_CTRL_ANE			BIT(12)
> +
>  struct ethqos_emac_por {
>  	unsigned int offset;
>  	unsigned int value;
> @@ -109,6 +114,7 @@ struct qcom_ethqos {
>  	unsigned int num_por;
>  	bool rgmii_config_loopback_en;
>  	bool has_emac_ge_3;
> +	unsigned int serdes_speed;

Looks like you are storing SPEED_XXX definitions here, which can be
negative in case of SPEED_UNKNOWN, so this should be an int.

>  };
>  
>  static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
> @@ -600,27 +606,47 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>  
>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  {
> -	int val;
> -
> +	int val, mac_an_value;
>  	val = readl(ethqos->mac_base + MAC_CTRL_REG);
> +	mac_an_value = readl(ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
>  
>  	switch (ethqos->speed) {
> +	case SPEED_2500:
> +		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
> +		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> +			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> +			      RGMII_IO_MACRO_CONFIG2);
> +		if (ethqos->serdes_speed != SPEED_2500)
> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> +		mac_an_value &= ~ETHQOS_MAC_AN_CTRL_ANE;
> +		break;
>  	case SPEED_1000:
>  		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
>  		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>  			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>  			      RGMII_IO_MACRO_CONFIG2);
> +		if (ethqos->serdes_speed != SPEED_1000)
> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>  		break;
>  	case SPEED_100:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL | ETHQOS_MAC_CTRL_SPEED_MODE;
> +		if (ethqos->serdes_speed != SPEED_1000)
> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);

I understand that SGMII's serdes always runs at 1000 / 2500, but this
check doesn't make much sense then, if the speed isn't 1000, then you
set the serdes PHY's speed to 100, and the assignment that comes after
that switch-case will also set the serdes speed to 100.

Also, if the serdes PHY really needs to be configured differently for
10/100/1000, then switching from speed 1000 to speed 100 for example
won't trigger a serdes PHY reconfiguration here.

My guess is that you want something like :

	phy_set_speed(ethqos->serdes_phy, SPEED_1000)

and the assignment at the end of the switch-case should be
SPEED_1000/SPEED_2500 only (see the comment bellow).

> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>  		break;
>  	case SPEED_10:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> +		if (ethqos->serdes_speed != SPEED_1000)
> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);

Same remark here

> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>  		break;
>  	}
>  
>  	writel(val, ethqos->mac_base + MAC_CTRL_REG);
> +	writel(mac_an_value, ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
> +	ethqos->serdes_speed = ethqos->speed;

Although the code will behave the same, as you are storing the true
serdes speed here, shouldn't it be either SPEED_1000 or SPEED_2500 ?

You'll end-up storing SPEED_10 / SPEED_100 should the link use these
speeds, which doesn't represent the true serdes speed.

This would spare serdes reconfigurations when alternating between
10/100/1000M speeds.

>  	return val;
>  }
> @@ -789,6 +815,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
>  				     "Failed to get serdes phy\n");
>  
>  	ethqos->speed = SPEED_1000;
> +	ethqos->serdes_speed = SPEED_1000;
>  	ethqos_update_link_clk(ethqos, SPEED_1000);
>  	ethqos_set_func_clk_en(ethqos);
>  

Thanks,

Maxime


From arnd at arndb.de  Mon Dec 18 06:21:41 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 18 Dec 2023 14:21:41 +0000
Subject: [PATCH] ARM: MAINTAINERS: drop empty entries for removed boards
In-Reply-To: <20231218134532.50599-1-krzysztof.kozlowski@linaro.org>
References: <20231218134532.50599-1-krzysztof.kozlowski@linaro.org>
Message-ID: <24e92cfc-8dc8-47b8-b379-ed8b1b776fba@app.fastmail.com>

On Mon, Dec 18, 2023, at 13:45, Krzysztof Kozlowski wrote:
> Drop empty and redundant maintainer entries for boards which were
> removed to fix `scripts/get_maintainer.pl --self-test=sections` errors
> like:
>
>   ./MAINTAINERS:2021: warning: section without file pattern	ARM/CIRRUS 
> LOGIC EDB9315A MACHINE SUPPORT

Good catch, I wonder if I missed these in last year's board removal
or if they were already broken back then. Some of these 

> @@ -2171,11 +2166,6 @@ T:	git 
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
>  F:	arch/arm/boot/dts/nxp/vf/
>  F:	arch/arm/mach-imx/*vf610*
> 
> -ARM/GUMSTIX MACHINE SUPPORT
> -M:	Steve Sakoman <sakoman at gmail.com>
> -L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> -S:	Maintained

I don't know if Steve still cares, but the board is still there
in arch/arm/mach-pxa/{gumstix,am200epd.c,am300epd.c}
 
> -ARM/INTEL XSC3 (MANZANO) ARM CORE
> -M:	Lennert Buytenhek <kernel at wantstofly.org>
> -L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> -S:	Maintained

Same here, the code is still there and used by pxa3xx:

arch/arm/mm/*xsc3l2*

>  ARM/LG1K ARCHITECTURE
>  M:	Chanho Min <chanho.min at lge.com>
>  L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> @@ -2840,11 +2825,6 @@ F:	arch/arm/boot/dts/synaptics/
>  F:	arch/arm/mach-berlin/
>  F:	arch/arm64/boot/dts/synaptics/
> 
> -ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
> -M:	Lennert Buytenhek <kernel at wantstofly.org>
> -L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> -S:	Maintained

arch/arm/mach-ep93xx/ts72xx.c is about to be obsoleted by the ongoing
DT conversion.


> @@ -17674,14 +17649,6 @@ L:	linux-gpio at vger.kernel.org
>  S:	Maintained
>  F:	drivers/gpio/gpio-pxa.c
> 
> -PXA MMCI DRIVER
> -S:	Orphan
> -
> -PXA RTC DRIVER
> -M:	Robert Jarzmik <robert.jarzmik at free.fr>
> -L:	linux-rtc at vger.kernel.org
> -S:	Maintained
> -

drivers/mmc/host/pxamci.c and drivers/rtc/rtc-pxa.c
are still in use.

> 
> -RDC R-321X SoC
> -M:	Florian Fainelli <florian at openwrt.org>
> -S:	Maintained
> -

This is still supported and it's x86 rather than arm.

There is a good chance that we /should/ remove it for being obsolete,
but that has to be a separate series and remove the drivers and
architecture support if we decide to go that way.

I'm fairly sure this platform was originally added for use with
OpenWRT but not everything was merged and OpenWRT stopped
carrying the required patches in 2016:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=fed29fa36bf9ff387ff6e96522b1b5423fed3581

Some of the drivers might still be in use on the related
vortex86 cores, so maybe we keep the support and add

N:     rdc321x

      Arnd


From alexander.stein at ew.tq-group.com  Mon Dec 18 06:23:12 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Mon, 18 Dec 2023 15:23:12 +0100
Subject: [PATCH 1/1] arm64: dts: imx8qxp: add GPU nodes
Message-ID: <20231218142312.3175828-1-alexander.stein@ew.tq-group.com>

Add the DT node for the GPU core found on the i.MX8QXP.

etnaviv-gpu 53100000.gpu: model: GC7000, revision: 6214
[drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
Based on downstream commit [1]. I am not aware if additional
modifications are necessary in etnaviv driver though. The revision
number is slightly different to the one from imx8mp:
etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6204

[1] https://github.com/Freescale/linux-fslc/commit/d0964b3f9afd8a75aca73921fdb0c128cc46c4fe

 .../boot/dts/freescale/imx8-ss-gpu0.dtsi      | 27 +++++++++++++++++++
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi    |  1 +
 2 files changed, 28 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-gpu0.dtsi

diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-gpu0.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-gpu0.dtsi
new file mode 100644
index 000000000000..9b8a44aa63d6
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-gpu0.dtsi
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ *	Dong Aisheng <aisheng.dong at nxp.com>
+ */
+
+#include <dt-bindings/firmware/imx/rsrc.h>
+
+gpu0_subsys: bus at 53000000 {
+	compatible = "simple-bus";
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges = <0x53000000 0x0 0x53000000 0x1000000>;
+
+	gpu_3d0: gpu at 53100000 {
+		compatible = "vivante,gc";
+		reg = <0x53100000 0x40000>;
+		interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&clk IMX_SC_R_GPU_0_PID0 IMX_SC_PM_CLK_PER>,
+			 <&clk IMX_SC_R_GPU_0_PID0 IMX_SC_PM_CLK_MISC>;
+		clock-names = "core", "shader";
+		assigned-clocks = <&clk IMX_SC_R_GPU_0_PID0 IMX_SC_PM_CLK_PER>,
+				  <&clk IMX_SC_R_GPU_0_PID0 IMX_SC_PM_CLK_MISC>;
+		assigned-clock-rates = <700000000>, <850000000>;
+		power-domains = <&pd IMX_SC_R_GPU_0_PID0>;
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index fdbb4242b157..10e16d84c0c3 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -317,6 +317,7 @@ map0 {
 	/* sorted in register address */
 	#include "imx8-ss-img.dtsi"
 	#include "imx8-ss-vpu.dtsi"
+	#include "imx8-ss-gpu0.dtsi"
 	#include "imx8-ss-adma.dtsi"
 	#include "imx8-ss-conn.dtsi"
 	#include "imx8-ss-ddr.dtsi"
-- 
2.34.1



From Frank.li at nxp.com  Mon Dec 18 06:28:33 2023
From: Frank.li at nxp.com (Frank Li)
Date: Mon, 18 Dec 2023 09:28:33 -0500
Subject: [PATCH v4 01/15] PCI: imx6: Simplify clock handling by using
 bulk_clk_*() function
In-Reply-To: <20231217170655.GC6748@thinkpad>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
 <20231217051210.754832-2-Frank.Li@nxp.com>
 <20231217170655.GC6748@thinkpad>
Message-ID: <ZYBXEaUcNuKDswux@lizhi-Precision-Tower-5810>

On Sun, Dec 17, 2023 at 10:36:55PM +0530, Manivannan Sadhasivam wrote:
> On Sun, Dec 17, 2023 at 12:11:56AM -0500, Frank Li wrote:
> > Refactors the clock handling logic in the imx6 PCI driver by adding
> > clk_names[] define in drvdata . Simplifies the code and makes it more
> > maintainable, as future additions of SOC support will only require
> > straightforward changes.
> > 
> 
> Commit description should be in imperative mood as per
> Documentation/process/submitting-patches.rst:
> 
> "Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
> instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
> to do frotz", as if you are giving orders to the codebase to change
> its behaviour."

How about: 

Refactors the clock handling logic. Adds clk_names[] define in drvdata.
Using clk_bulk*() api simplifies the code.

> 
> > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > ---
> > 
> > Notes:
> >     Change from v3 to v4
> >     - using clk_bulk_*() API
> >     Change from v1 to v3
> >     - none
> > 
> >  drivers/pci/controller/dwc/pci-imx6.c | 128 ++++++++------------------
> >  1 file changed, 38 insertions(+), 90 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> > index 74703362aeec7..2086214345e9a 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> 
> [...]
> 
> >  static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
> > @@ -1305,32 +1265,19 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> >  		return imx6_pcie->reset_gpio;
> >  	}
> >  
> > -	/* Fetch clocks */
> > -	imx6_pcie->pcie_bus = devm_clk_get(dev, "pcie_bus");
> > -	if (IS_ERR(imx6_pcie->pcie_bus))
> > -		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_bus),
> > -				     "pcie_bus clock source missing or invalid\n");
> > +	while (imx6_pcie->drvdata->clk_names[imx6_pcie->clks_cnt]) {
> > +		int i = imx6_pcie->clks_cnt;
> >  
> > -	imx6_pcie->pcie = devm_clk_get(dev, "pcie");
> > -	if (IS_ERR(imx6_pcie->pcie))
> > -		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
> > -				     "pcie clock source missing or invalid\n");
> > +		imx6_pcie->clks[i].id = imx6_pcie->drvdata->clk_names[i];
> > +		imx6_pcie->clks_cnt++;
> 
> You can just initialize clks_cnt in drv_data with sizeof() of clk_names.

sizeof will return pre allocated clk_names size, for here, it should be 6.
Not initilized string cnt.

or you have to duplicate two line 
	clk_names = {"clk1", "clk2", ...},
	clks_cnt = ARRAY_SIZE({"clk1", "clk2", ...},


Anyway, it need copy to clks[i].id, count here is simple.

Frank


> 
> > +	}
> > +
> > +	/* Fetch clocks */
> > +	ret = devm_clk_bulk_get(dev, imx6_pcie->clks_cnt, imx6_pcie->clks);
> > +	if (ret)
> > +		return ret;
> >  
> >  	switch (imx6_pcie->drvdata->variant) {
> > -	case IMX6SX:
> > -		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
> > -							   "pcie_inbound_axi");
> > -		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
> > -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
> > -					     "pcie_inbound_axi clock missing or invalid\n");
> > -		break;
> > -	case IMX8MQ:
> > -	case IMX8MQ_EP:
> > -		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> > -		if (IS_ERR(imx6_pcie->pcie_aux))
> > -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> > -					     "pcie_aux clock source missing or invalid\n");
> > -		fallthrough;
> >  	case IMX7D:
> >  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> >  			imx6_pcie->controller_id = 1;
> > @@ -1353,10 +1300,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> >  	case IMX8MM_EP:
> >  	case IMX8MP:
> >  	case IMX8MP_EP:
> > -		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
> > -		if (IS_ERR(imx6_pcie->pcie_aux))
> > -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
> > -					     "pcie_aux clock source missing or invalid\n");
> >  		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
> >  									 "apps");
> >  		if (IS_ERR(imx6_pcie->apps_reset))
> > @@ -1372,14 +1315,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> >  	default:
> >  		break;
> >  	}
> > -	/* Don't fetch the pcie_phy clock, if it has abstract PHY driver */
> > -	if (imx6_pcie->phy == NULL) {
> > -		imx6_pcie->pcie_phy = devm_clk_get(dev, "pcie_phy");
> > -		if (IS_ERR(imx6_pcie->pcie_phy))
> > -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_phy),
> > -					     "pcie_phy clock source missing or invalid\n");
> > -	}
> > -
> >  
> >  	/* Grab turnoff reset */
> >  	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
> > @@ -1470,6 +1405,9 @@ static void imx6_pcie_shutdown(struct platform_device *pdev)
> >  	imx6_pcie_assert_core_reset(imx6_pcie);
> >  }
> >  
> > +#define IMX6_CLKS_COMMON "pcie_bus", "pcie"
> > +#define IMX6_CLKS_NO_PHYDRV IMX6_CLKS_COMMON, "pcie_phy"
> > +
> 
> Just use the clock names directly instead of definitions. It makes the code more
> readable.
> 
> Rest LGTM!
> 
> - Mani
> 
> -- 
> ????????? ????????


From quic_snehshah at quicinc.com  Mon Dec 18 06:32:58 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Mon, 18 Dec 2023 20:02:58 +0530
Subject: [PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support for
 2.5G SGMII
In-Reply-To: <20231218152112.4adc5961@device-28.home>
References: <20231218071118.21879-1-quic_snehshah@quicinc.com>
 <20231218152112.4adc5961@device-28.home>
Message-ID: <edfb87b5-504e-467d-9119-66b59727cc21@quicinc.com>

Hi,

On 12/18/2023 7:51 PM, Maxime Chevallier wrote:
> Hi,
> 
> On Mon, 18 Dec 2023 12:41:18 +0530
> Sneh Shah <quic_snehshah at quicinc.com> wrote:
> 
>> Serdes phy needs to operate at 2500 mode for 2.5G speed and 1000
>> mode for 1G/100M/10M speed.
>> Added changes to configure serdes phy and mac based on link speed.
>>
>> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
>> ---
>>  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 31 +++++++++++++++++--
>>  1 file changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>> index d3bf42d0fceb..b3a28dc19161 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>> @@ -21,6 +21,7 @@
>>  #define RGMII_IO_MACRO_CONFIG2		0x1C
>>  #define RGMII_IO_MACRO_DEBUG1		0x20
>>  #define EMAC_SYSTEM_LOW_POWER_DEBUG	0x28
>> +#define ETHQOS_MAC_AN_CTRL		0xE0
>>  
>>  /* RGMII_IO_MACRO_CONFIG fields */
>>  #define RGMII_CONFIG_FUNC_CLK_EN		BIT(30)
>> @@ -78,6 +79,10 @@
>>  #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
>>  #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
>>  
>> +/*ETHQOS_MAC_AN_CTRL bits */
>> +#define ETHQOS_MAC_AN_CTRL_RAN			BIT(9)
>> +#define ETHQOS_MAC_AN_CTRL_ANE			BIT(12)
>> +
>>  struct ethqos_emac_por {
>>  	unsigned int offset;
>>  	unsigned int value;
>> @@ -109,6 +114,7 @@ struct qcom_ethqos {
>>  	unsigned int num_por;
>>  	bool rgmii_config_loopback_en;
>>  	bool has_emac_ge_3;
>> +	unsigned int serdes_speed;
> 
> Looks like you are storing SPEED_XXX definitions here, which can be
> negative in case of SPEED_UNKNOWN, so this should be an int.
Agree, will update this in next patch.
> 
>>  };
>>  
>>  static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
>> @@ -600,27 +606,47 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>>  
>>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>>  {
>> -	int val;
>> -
>> +	int val, mac_an_value;
>>  	val = readl(ethqos->mac_base + MAC_CTRL_REG);
>> +	mac_an_value = readl(ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
>>  
>>  	switch (ethqos->speed) {
>> +	case SPEED_2500:
>> +		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
>> +		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>> +			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>> +			      RGMII_IO_MACRO_CONFIG2);
>> +		if (ethqos->serdes_speed != SPEED_2500)
>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>> +		mac_an_value &= ~ETHQOS_MAC_AN_CTRL_ANE;
>> +		break;
>>  	case SPEED_1000:
>>  		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
>>  		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>>  			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>>  			      RGMII_IO_MACRO_CONFIG2);
>> +		if (ethqos->serdes_speed != SPEED_1000)
>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>>  		break;
>>  	case SPEED_100:
>>  		val |= ETHQOS_MAC_CTRL_PORT_SEL | ETHQOS_MAC_CTRL_SPEED_MODE;
>> +		if (ethqos->serdes_speed != SPEED_1000)
>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> 
> I understand that SGMII's serdes always runs at 1000 / 2500, but this
> check doesn't make much sense then, if the speed isn't 1000, then you
> set the serdes PHY's speed to 100, and the assignment that comes after
> that switch-case will also set the serdes speed to 100.
> 
> Also, if the serdes PHY really needs to be configured differently for
> 10/100/1000, then switching from speed 1000 to speed 100 for example
> won't trigger a serdes PHY reconfiguration here.
> 
> My guess is that you want something like :
> 
> 	phy_set_speed(ethqos->serdes_phy, SPEED_1000)
> 
> and the assignment at the end of the switch-case should be
> SPEED_1000/SPEED_2500 only (see the comment bellow).

Good point, we have only serdes speed of 1000 and 2500. So for 1000/100/10 we should set ethqos_serdes to speed_1000 and pass speed_1000 to phy_set_speed in case of 1000/100/10. Will update this in next patch.
> 
>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>>  		break;
>>  	case SPEED_10:
>>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
>> +		if (ethqos->serdes_speed != SPEED_1000)
>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> 
> Same remark here
> 
>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>>  		break;
>>  	}
>>  
>>  	writel(val, ethqos->mac_base + MAC_CTRL_REG);
>> +	writel(mac_an_value, ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
>> +	ethqos->serdes_speed = ethqos->speed;
> 
> Although the code will behave the same, as you are storing the true
> serdes speed here, shouldn't it be either SPEED_1000 or SPEED_2500 ?
> 
> You'll end-up storing SPEED_10 / SPEED_100 should the link use these
> speeds, which doesn't represent the true serdes speed.
> 
> This would spare serdes reconfigurations when alternating between
> 10/100/1000M speeds.
> 
>>  	return val;
>>  }
>> @@ -789,6 +815,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
>>  				     "Failed to get serdes phy\n");
>>  
>>  	ethqos->speed = SPEED_1000;
>> +	ethqos->serdes_speed = SPEED_1000;
>>  	ethqos_update_link_clk(ethqos, SPEED_1000);
>>  	ethqos_set_func_clk_en(ethqos);
>>  
> 
> Thanks,
> 
> Maxime


From Frank.li at nxp.com  Mon Dec 18 06:35:34 2023
From: Frank.li at nxp.com (Frank Li)
Date: Mon, 18 Dec 2023 09:35:34 -0500
Subject: [PATCH v4 02/15] PCI: imx6: Simplify phy handling by using by
 using IMX6_PCIE_FLAG_HAS_PHY
In-Reply-To: <20231217171811.GD6748@thinkpad>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
 <20231217051210.754832-3-Frank.Li@nxp.com>
 <20231217171811.GD6748@thinkpad>
Message-ID: <ZYBYti+6So+tXhp9@lizhi-Precision-Tower-5810>

On Sun, Dec 17, 2023 at 10:48:11PM +0530, Manivannan Sadhasivam wrote:
> On Sun, Dec 17, 2023 at 12:11:57AM -0500, Frank Li wrote:
> > Refactors the phy handling logic in the imx6 PCI driver by adding
> > IMX6_PCIE_FLAG_HAS_PHY bitmask define for drvdata::flags.
> > 
> > The drvdata::flags and a bitmask ensures a cleaner and more scalable
> > switch-case structure for handling phy.
> > 
> > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > ---
> > 
> > Notes:
> >     Change from v1 to v3:
> >     - none
> > 
> >  drivers/pci/controller/dwc/pci-imx6.c | 23 ++++++++++++++++-------
> >  1 file changed, 16 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> > index 2086214345e9a..91ba26a4b4c3d 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -60,6 +60,9 @@ enum imx6_pcie_variants {
> >  #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
> >  #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
> >  #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
> > +#define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
> > +
> > +#define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
> >  
> >  #define IMX6_PCIE_MAX_CLKS       6
> >  
> > @@ -1277,6 +1280,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> >  	if (ret)
> >  		return ret;
> >  
> > +	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY)) {
> > +		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
> 
> Can't you use devm_phy_optional_get()? This will return NULL if the PHY is not
> defined in DT. So you can use IS_ERR() to catch error if there are issues in
> acquiring PHY if defined and NULL can be safely passed to other PHY APIs like
> phy_init() as well.
> 
> With this, you won't need a flag in drv_data and can also get rid of the
> condition around PHY APIs.

The key is the driver need know which platform "pcie-phy" is manditary. 
devm_phy_optional_get() can work if dts is correct. use HAS_PHY flags just
double check if dts correct add "pcie-phy" at dts.

This is just one place to check. and Help debug dtb miss match issues.

Frank

> 
> - Mani
> 
> > +		if (IS_ERR(imx6_pcie->phy))
> > +			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
> > +					     "failed to get pcie phy\n");
> > +	}
> > +
> >  	switch (imx6_pcie->drvdata->variant) {
> >  	case IMX7D:
> >  		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> > @@ -1306,11 +1316,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> >  			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
> >  					     "failed to get pcie apps reset control\n");
> >  
> > -		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
> > -		if (IS_ERR(imx6_pcie->phy))
> > -			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
> > -					     "failed to get pcie phy\n");
> > -
> >  		break;
> >  	default:
> >  		break;
> > @@ -1447,13 +1452,15 @@ static const struct imx6_pcie_drvdata drvdata[] = {
> >  	},
> >  	[IMX8MM] = {
> >  		.variant = IMX8MM,
> > -		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> > +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> > +			 IMX6_PCIE_FLAG_HAS_PHY,
> >  		.gpr = "fsl,imx8mm-iomuxc-gpr",
> >  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
> >  	},
> >  	[IMX8MP] = {
> >  		.variant = IMX8MP,
> > -		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
> > +		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
> > +			 IMX6_PCIE_FLAG_HAS_PHY,
> >  		.gpr = "fsl,imx8mp-iomuxc-gpr",
> >  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
> >  	},
> > @@ -1465,12 +1472,14 @@ static const struct imx6_pcie_drvdata drvdata[] = {
> >  	},
> >  	[IMX8MM_EP] = {
> >  		.variant = IMX8MM_EP,
> > +		.flags = IMX6_PCIE_FLAG_HAS_PHY,
> >  		.mode = DW_PCIE_EP_TYPE,
> >  		.gpr = "fsl,imx8mm-iomuxc-gpr",
> >  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
> >  	},
> >  	[IMX8MP_EP] = {
> >  		.variant = IMX8MP_EP,
> > +		.flags = IMX6_PCIE_FLAG_HAS_PHY,
> >  		.mode = DW_PCIE_EP_TYPE,
> >  		.gpr = "fsl,imx8mp-iomuxc-gpr",
> >  		.clk_names = {IMX6_CLKS_COMMON, "pcie_aux"},
> > -- 
> > 2.34.1
> > 
> 
> -- 
> ????????? ????????


From chunkuang.hu at kernel.org  Mon Dec 18 06:38:29 2023
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Mon, 18 Dec 2023 22:38:29 +0800
Subject: [PATCH v2] drm/mediatek: dp: Add phy_mtk_dp module as pre-dependency
In-Reply-To: <20231121142938.460846-1-nfraprado@collabora.com>
References: <20231121142938.460846-1-nfraprado@collabora.com>
Message-ID: <CAAOTY_9g-9qTaja6dV5uD4Gbjw3fusRVnmucUeKUYtMpreVORg@mail.gmail.com>

Hi, Nicolas:

N?colas F. R. A. Prado <nfraprado at collabora.com> ? 2023?11?21? ?? ??10:29???
>
> The mtk_dp driver registers a phy device which is handled by the
> phy_mtk_dp driver and assumes that the phy probe will complete
> synchronously, proceeding to make use of functionality exposed by that
> driver right away. This assumption however is false when the phy driver
> is built as a module, causing the mtk_dp driver to fail probe in this
> case.
>
> Add the phy_mtk_dp module as a pre-dependency to the mtk_dp module to
> ensure the phy module has been loaded before the dp, so that the phy
> probe happens synchrounously and the mtk_dp driver can probe
> successfully even with the phy driver built as a module.

Applied to mediatek-drm-next [1], thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
> Signed-off-by: N?colas F. R. A. Prado <nfraprado at collabora.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
>
> ---
>
> Changes in v2:
> - Added missing Suggested-by tag
>
>  drivers/gpu/drm/mediatek/mtk_dp.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> index e4c16ba9902d..2136a596efa1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -2818,3 +2818,4 @@ MODULE_AUTHOR("Markus Schneider-Pargmann <msp at baylibre.com>");
>  MODULE_AUTHOR("Bo-Chen Chen <rex-bc.chen at mediatek.com>");
>  MODULE_DESCRIPTION("MediaTek DisplayPort Driver");
>  MODULE_LICENSE("GPL");
> +MODULE_SOFTDEP("pre: phy_mtk_dp");
> --
> 2.42.1
>


From krzysztof.kozlowski at linaro.org  Mon Dec 18 06:39:05 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 18 Dec 2023 15:39:05 +0100
Subject: [PATCH] ARM: MAINTAINERS: drop empty entries for removed boards
In-Reply-To: <24e92cfc-8dc8-47b8-b379-ed8b1b776fba@app.fastmail.com>
References: <20231218134532.50599-1-krzysztof.kozlowski@linaro.org>
 <24e92cfc-8dc8-47b8-b379-ed8b1b776fba@app.fastmail.com>
Message-ID: <aaeb97f1-075e-44b9-874d-f66763ef8866@linaro.org>

On 18/12/2023 15:21, Arnd Bergmann wrote:
> On Mon, Dec 18, 2023, at 13:45, Krzysztof Kozlowski wrote:
>> Drop empty and redundant maintainer entries for boards which were
>> removed to fix `scripts/get_maintainer.pl --self-test=sections` errors
>> like:
>>
>>   ./MAINTAINERS:2021: warning: section without file pattern	ARM/CIRRUS 
>> LOGIC EDB9315A MACHINE SUPPORT
> 
> Good catch, I wonder if I missed these in last year's board removal
> or if they were already broken back then. Some of these 
> 
>> @@ -2171,11 +2166,6 @@ T:	git 
>> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
>>  F:	arch/arm/boot/dts/nxp/vf/
>>  F:	arch/arm/mach-imx/*vf610*
>>
>> -ARM/GUMSTIX MACHINE SUPPORT
>> -M:	Steve Sakoman <sakoman at gmail.com>
>> -L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> -S:	Maintained
> 
> I don't know if Steve still cares, but the board is still there
> in arch/arm/mach-pxa/{gumstix,am200epd.c,am300epd.c}

I did not dig that deep before, but since you insist let's take a look:

Entry was introduced in 90b8fc34968d ("[ARM] 4867/1: Adds flash, udc,
mci support for gumstix F boards") and it did not cover board files.

>  
>> -ARM/INTEL XSC3 (MANZANO) ARM CORE
>> -M:	Lennert Buytenhek <kernel at wantstofly.org>
>> -L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> -S:	Maintained
> 
> Same here, the code is still there and used by pxa3xx:
> 
> arch/arm/mm/*xsc3l2*

Similar see: 2b7a52a459cb ("[PATCH] Update CREDITS and MAINTAINERS
entries for Lennert Buytenhek")

Adding the files to these entries would be actually changing status quo.


> 
>>  ARM/LG1K ARCHITECTURE
>>  M:	Chanho Min <chanho.min at lge.com>
>>  L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> @@ -2840,11 +2825,6 @@ F:	arch/arm/boot/dts/synaptics/
>>  F:	arch/arm/mach-berlin/
>>  F:	arch/arm64/boot/dts/synaptics/
>>
>> -ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
>> -M:	Lennert Buytenhek <kernel at wantstofly.org>
>> -L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> -S:	Maintained
> 
> arch/arm/mach-ep93xx/ts72xx.c is about to be obsoleted by the ongoing
> DT conversion.
> 
> 
>> @@ -17674,14 +17649,6 @@ L:	linux-gpio at vger.kernel.org
>>  S:	Maintained
>>  F:	drivers/gpio/gpio-pxa.c
>>
>> -PXA MMCI DRIVER
>> -S:	Orphan
>> -
>> -PXA RTC DRIVER
>> -M:	Robert Jarzmik <robert.jarzmik at free.fr>
>> -L:	linux-rtc at vger.kernel.org
>> -S:	Maintained
>> -
> 
> drivers/mmc/host/pxamci.c and drivers/rtc/rtc-pxa.c
> are still in use.

MMCI does not have maintainer.

For the RTC, I guess the intention of 57f63bc8fe79 ("rtc: update
maintainership of pxa rtc driver") was to maintain the driver.

The actual problem is that all of these entries (and R-321X below) come
from the times people were not putting any file paths to MAINTAINERS.
They stayed like this for 15-17 years, thus being effectively noop.

Let's maybe wait till any of Cc-ed people respond and confirm they want
to grow the maintainer entry to cover the files? If they don't come, I
propose to remove them.

> 
>>
>> -RDC R-321X SoC
>> -M:	Florian Fainelli <florian at openwrt.org>
>> -S:	Maintained
>> -
> 
> This is still supported and it's x86 rather than arm.
> 
> There is a good chance that we /should/ remove it for being obsolete,
> but that has to be a separate series and remove the drivers and
> architecture support if we decide to go that way.

Sure.

> 
> I'm fairly sure this platform was originally added for use with
> OpenWRT but not everything was merged and OpenWRT stopped
> carrying the required patches in 2016:
> 
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=fed29fa36bf9ff387ff6e96522b1b5423fed3581
> 

Best regards,
Krzysztof



From robh at kernel.org  Mon Dec 18 06:48:32 2023
From: robh at kernel.org (Rob Herring)
Date: Mon, 18 Dec 2023 08:48:32 -0600
Subject: [PATCH 1/4] dt-bindings: nvmem: layouts: add U-Boot
 environment variables layout
In-Reply-To: <20231218133722.16150-1-zajec5@gmail.com>
References: <20231218133722.16150-1-zajec5@gmail.com>
Message-ID: <170291091219.3792434.8389294947030479112.robh@kernel.org>


On Mon, 18 Dec 2023 14:37:19 +0100, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> U-Boot env data is a way of storing firmware variables. It's a format
> that can be used of top of various storage devices. Its binding should
> be an NVMEM layout instead of a standalone device.
> 
> This patch adds layout binding which allows using it on top of MTD NVMEM
> device as well as any other. At the same time it deprecates the old
> combined binding.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> ---
>  .../bindings/nvmem/layouts/u-boot,env.yaml    | 55 +++++++++++++++++++
>  .../devicetree/bindings/nvmem/u-boot,env.yaml |  6 ++
>  2 files changed, 61 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/nvmem/u-boot,env.example.dtb: partition at 40000: 'ethaddr', 'reg' do not match any of the regexes: 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/nvmem/u-boot,env.example.dtb: partition-u-boot-env: 'ethaddr' does not match any of the regexes: 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231218133722.16150-1-zajec5 at gmail.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From conor at kernel.org  Mon Dec 18 06:54:35 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 18 Dec 2023 14:54:35 +0000
Subject: [PATCH v2 2/5] dt-bindings: opp: sun50i: Add binding for D1 CPUs
In-Reply-To: <20231218110543.64044-3-fusibrandon13@gmail.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
 <20231218110543.64044-3-fusibrandon13@gmail.com>
Message-ID: <20231218-disprove-judgingly-ee54d39474a7@spud>

On Mon, Dec 18, 2023 at 12:05:40PM +0100, Brandon Cheo Fusi wrote:
> Add binding for D1 CPU OPPs.
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  .../bindings/opp/allwinner,sun50i-h6-operating-points.yaml    | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> index 51f62c3ae..fddaa3216 100644
> --- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> +++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> @@ -23,7 +23,9 @@ allOf:
>  
>  properties:
>    compatible:
> -    const: allwinner,sun50i-h6-operating-points
> +    enum:
> +      - allwinner,sun50i-h6-operating-points
> +      - allwinner,sun20i-d1-operating-points

This doesn't match what you have in your devicetree.

>  
>    nvmem-cells:
>      description: |
> -- 
> 2.30.2
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/d18c4c62/attachment.sig>

From conor at kernel.org  Mon Dec 18 06:55:30 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 18 Dec 2023 14:55:30 +0000
Subject: [PATCH v2 3/5] cpufreq: sun50i: Add D1 support
In-Reply-To: <20231218110543.64044-4-fusibrandon13@gmail.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
 <20231218110543.64044-4-fusibrandon13@gmail.com>
Message-ID: <20231218-blabber-slapstick-ab7ae45af019@spud>

On Mon, Dec 18, 2023 at 12:05:41PM +0100, Brandon Cheo Fusi wrote:
> Add support for D1 based devices to the Allwinner H6 cpufreq
> driver
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> index 32a9c88f8..ccf83780f 100644
> --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> @@ -160,6 +160,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
>  
>  static const struct of_device_id sun50i_cpufreq_match_list[] = {
>  	{ .compatible = "allwinner,sun50i-h6" },
> +	{ .compatible = "allwinner,sun20i-d1" },

I thought the feedback in v2 was to drop this change, since the
devicetree has the sun50i-h6 as a fallback compatible?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/0a5757d0/attachment-0001.sig>

From conor at kernel.org  Mon Dec 18 06:59:20 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 18 Dec 2023 14:59:20 +0000
Subject: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <fa4b9c1d-6033-4b35-b03c-e03419edb5dc@collabora.com>
References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com>
 <20231215204050.2296404-3-cristian.ciocaltea@collabora.com>
 <A7C96942-07CB-40FD-AAAA-4A8947DEE7CA@jrtc27.com>
 <65fd52f1-6861-42b0-9148-266766d054b1@sifive.com>
 <6c62e3b2-acde-4580-9b67-56683289e45e@collabora.com>
 <20231217-spray-livestock-a59d630b751e@spud>
 <fa4b9c1d-6033-4b35-b03c-e03419edb5dc@collabora.com>
Message-ID: <20231218-snowcap-charter-f8c75312eaa9@spud>


> > Won't this also relax the naming for all devices that allow a single
> > reset, but expect the stmmaceth one? I'm not sure that that actually
> > matters, I think the consumer bindings have constraints themselves.
> 
> Before commit 843f603762a5 ("dt-bindings: net: snps,dwmac: Add 'ahb'
> reset/reset-name"), the 'stmmaceth' was the only possible option, hence
> there was no need for any constraints on the consumer bindings.  But
> afterwards it was allowed to use both resets, hence I think the bindings
> should have been updated at that time by adding 'maxItems: 1' to prevent
> using the 2nd reset.
> 
> I could fix this in a separate series, if it's not something mandatory
> to be handled here.

If it is not introduced by this series, I don't see why it could not be
handled separately if needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/51b14f43/attachment.sig>

From linux at armlinux.org.uk  Mon Dec 18 07:27:18 2023
From: linux at armlinux.org.uk (Russell King (Oracle))
Date: Mon, 18 Dec 2023 15:27:18 +0000
Subject: rmk offline until after Christmas
Message-ID: <ZYBk1u0TmX3GCieY@shell.armlinux.org.uk>

All,

To make it more plainly obvious to everyone, I will be offline from when
I send this email until the new year. This means I will not be reviewing
any patches or otherwise responding on the mailing lists.

This has happened earlier than anticipated as I have contracted Covid
last week and tested positive last night. Unfortunately, it does not
appear to be a mild case.

Sorry.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!


From nm at ti.com  Mon Dec 18 07:30:43 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 18 Dec 2023 09:30:43 -0600
Subject: [GIT PULL 1/3] drivers/firmware updates for v6.8 for TI K3 platforms
Message-ID: <20231218153043.r5psxbjjpccusjg4@september>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-driver-soc-for-v6.8

for you to fetch changes up to 2c2235292b33d788a1436f1d2a6108184a657f51:

  soc: ti: k3-socinfo: Add JTAG ID for J722S (2023-12-13 07:52:32 -0600)

----------------------------------------------------------------
TI SoC driver updates for v6.8

- ti_sci: Minor fixup for off by one error in debugfs_create
- k3-socinfo: Refactoring and add j721e detection, j722s

----------------------------------------------------------------
Christophe JAILLET (1):
      firmware: ti_sci: Fix an off-by-one in ti_sci_debugfs_create()

Neha Malcom Francis (1):
      soc: ti: k3-socinfo: Revamp driver to accommodate different rev structs

Vaishnav Achath (1):
      soc: ti: k3-socinfo: Add JTAG ID for J722S

 drivers/firmware/ti_sci.c   | 10 +++----
 drivers/soc/ti/k3-socinfo.c | 73 +++++++++++++++++++++++++++++++++++----------
 2 files changed, 62 insertions(+), 21 deletions(-)

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From nm at ti.com  Mon Dec 18 07:30:39 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 18 Dec 2023 09:30:39 -0600
Subject: [GIT PULL] ARM: dts: ti: keystone: Updates for v6.8
Message-ID: <20231218153039.dok52xazqshbr6ie@playroom>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-keystone-dt-for-v6.8

for you to fetch changes up to c1170c1d04d5bfbd9b38cb968d45b77e6bda2098:

  ARM: dts: ti: keystone: minor whitespace cleanup around '=' (2023-11-24 12:53:00 -0600)

----------------------------------------------------------------
Keystone2 device tree updates for v6.8

Cosmetic cleanups:
* white space cleanup around '='

----------------------------------------------------------------
Krzysztof Kozlowski (1):
      ARM: dts: ti: keystone: minor whitespace cleanup around '='

 arch/arm/boot/dts/ti/keystone/keystone-k2e-netcp.dtsi  | 6 +++---
 arch/arm/boot/dts/ti/keystone/keystone-k2g-evm.dts     | 2 +-
 arch/arm/boot/dts/ti/keystone/keystone-k2g-netcp.dtsi  | 6 +++---
 arch/arm/boot/dts/ti/keystone/keystone-k2hk-evm.dts    | 2 +-
 arch/arm/boot/dts/ti/keystone/keystone-k2hk-netcp.dtsi | 6 +++---
 arch/arm/boot/dts/ti/keystone/keystone-k2l-netcp.dtsi  | 6 +++---
 6 files changed, 14 insertions(+), 14 deletions(-)

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/3971acde/attachment.sig>

From nm at ti.com  Mon Dec 18 07:31:02 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 18 Dec 2023 09:31:02 -0600
Subject: [GIT PULL 2/3] arm64: defconfig: Updates for v6.8 for TI K3 platforms
Message-ID: <20231218153102.ptduqsvtsq7sxs5n@tinsel>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v6.8

for you to fetch changes up to e8779517788fa0f3d04840cb7d4121d3df8dfd54:

  arm64: defconfig: Enable DRM_POWERVR (2023-12-13 08:45:05 -0600)

----------------------------------------------------------------
TI K3 defconfig updates for v6.8

- Enable TI K3 SoC components PRUSS, CSI2RX, POWERVR for various boards.
- Enable TC358767 for Iot2050 board
- Increase 8250_NR_UARTS from 4 to 8 to support AM62x verdin boards (minor increase in kernel image)

----------------------------------------------------------------
Aradhya Bhatia (1):
      arm64: defconfig: Enable Toshiba TC358767 bridge

Donald Robson (1):
      arm64: defconfig: Enable DRM_POWERVR

Francesco Dolcini (1):
      arm64: defconfig: Increase SERIAL_8250_NR_UARTS

Jai Luthra (1):
      arm64: defconfig: Enable J721E CSI2RX

MD Danish Anwar (1):
      arm64: defconfig: Enable TI_ICSSG_PRUETH

 arch/arm64/configs/defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/b9a27cc7/attachment-0001.sig>

From tomi.valkeinen at ideasonboard.com  Mon Dec 18 07:31:18 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Mon, 18 Dec 2023 17:31:18 +0200
Subject: [PATCH v4 05/11] media: rkisp1: Fix RSZ_CTRL bits for i.MX8MP
In-Reply-To: <20231129092759.242641-6-paul.elder@ideasonboard.com>
References: <20231129092759.242641-1-paul.elder@ideasonboard.com>
 <20231129092759.242641-6-paul.elder@ideasonboard.com>
Message-ID: <03b98b67-e88c-4bb0-a01d-5a90f78e04a3@ideasonboard.com>

Hi Paul,

On 29/11/2023 11:27, Paul Elder wrote:
> The ISP8000Nano, found in the i.MX8MP, has a different architecture to
> crop at the resizer input. Instead of the "dual crop" block between the
> ISP and the resizers found in the RK3399, cropping has been moved to the
> input of the resizer blocks. As a result, the resizer CFG_UPD and
> CFG_UPD_AUTO bits have been moved to make space for a new CROP_ENABLE
> bit.
> 
> Fix the resizer shadow update accordingly, using the DUAL_CROP feature
> to infer whether or not the resizer implements cropping. Support for
> resizer cropping itself will be added in a subsequent commit.
> 
> Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
> Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

I don't think this one is correct.

The above is perhaps true for ISP8000, but ISP8000Nano does not have 
CROP_ENABLE bit, and the CFG_UPD and CFG_UPD_AUTO are at the same 
locations as on RK3399.

I don't have documentation to prove this, but experimentation shows that 
this is the case.

  Tomi

> ---
> Changes since v3:
> 
> - Condition on RKISP1_FEATURE_DUAL_CROP feature
> - Update commit message
> 
> Changes since v2:
> 
> - Condition on RKISP1_FEATURE_RSZ_CROP feature
> - Rename bits
> - Use the rkisp1_has_feature() macro
> 
>   .../media/platform/rockchip/rkisp1/rkisp1-regs.h  |  5 +++++
>   .../platform/rockchip/rkisp1/rkisp1-resizer.c     | 15 +++++++++++----
>   2 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> index 3b19c8411360..95646b45f28b 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> @@ -168,6 +168,11 @@
>   #define RKISP1_CIF_RSZ_CTRL_CFG_UPD_AUTO		BIT(9)
>   #define RKISP1_CIF_RSZ_SCALER_FACTOR			BIT(16)
>   
> +/* For resizer instances that support cropping */
> +#define RKISP1_CIF_RSZ_CTRL_CROP_ENABLE			BIT(8)
> +#define RKISP1_CIF_RSZ_CTRL_CROP_CFG_UPD		BIT(9)
> +#define RKISP1_CIF_RSZ_CTRL_CROP_CFG_UPD_AUTO		BIT(10)
> +
>   /* MI_IMSC - MI_MIS - MI_RIS - MI_ICR - MI_ISR */
>   #define RKISP1_CIF_MI_FRAME(stream)			BIT((stream)->id)
>   #define RKISP1_CIF_MI_MBLK_LINE				BIT(2)
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c
> index c1aaeed58acc..6d6ebc53c6e5 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c
> @@ -178,10 +178,17 @@ static void rkisp1_rsz_update_shadow(struct rkisp1_resizer *rsz,
>   {
>   	u32 ctrl_cfg = rkisp1_rsz_read(rsz, RKISP1_CIF_RSZ_CTRL);
>   
> -	if (when == RKISP1_SHADOW_REGS_ASYNC)
> -		ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CFG_UPD_AUTO;
> -	else
> -		ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CFG_UPD;
> +	if (when == RKISP1_SHADOW_REGS_ASYNC) {
> +		if (rkisp1_has_feature(rsz->rkisp1, DUAL_CROP))
> +			ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CFG_UPD_AUTO;
> +		else
> +			ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CROP_CFG_UPD_AUTO;
> +	} else {
> +		if (rkisp1_has_feature(rsz->rkisp1, DUAL_CROP))
> +			ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CFG_UPD;
> +		else
> +			ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CROP_CFG_UPD;
> +	}
>   
>   	rkisp1_rsz_write(rsz, RKISP1_CIF_RSZ_CTRL, ctrl_cfg);
>   }



From nm at ti.com  Mon Dec 18 07:31:15 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 18 Dec 2023 09:31:15 -0600
Subject: [GIT PULL 3/3] arm64: dts: ti: Updates for v6.8 for TI K3 platforms
Message-ID: <20231218153115.szyd22tmoumqkn6g@occupier>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-dt-for-v6.8

for you to fetch changes up to 8bbe8a7dbaabb84d93321f116966af73ba6a7233:

  arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed mode (2023-12-15 10:05:58 -0600)

----------------------------------------------------------------
TI K3 device tree updates for v6.8

New features across K3 SoCs:
- ov5640 and imx219 sensor overlays added to various am62x/am62a boards.
- TP6594 and family support for J7200, j721s2,j721e, am69/j784s4 boards

Generic Fixes:
- minor white space cleanups
- Addition of optional regs for more complete DMA description across all K3
  SoCs.

Misc:
- chip_id node moves under wkup_conf bus.
- COMPILE_TEST+OF_ALL_DTBS is now standard usage for testing overlays.

SoC specific Fixes/Features:
AM62A
 - gpio pin count fixups.
AM625
 - Adds verdin am62x-mallow board
 - Adds IMG's AXE-RGX GPU support
 - Adds gpio-ranges support for main domain GPIOs.
 - SK now defaults to mcu gpio marked as reserved to cater to MCU use cases
AM64
 - EVM/SK now defaults to mcu gpio marked as reserved to cater to MCU use cases
AM65
 - Fix for DSS Irq trigger type, proper fixup for dss-oldi-io-ctrl node
 - misc splitup to make AM652 device variant reusable
J7200
 - mmc: itap delay fixups for DDR52
J721S2/AM68
 - mmc: itap delay fixups for DDR50
J784S4/AM69
 - mmc: itap delay fixups for DDR50

Board specific fixes/Features:
- iot2050 cleanups for enabling icssg-prueth nodes, runtime pinmuxing,
  dropping ecap0pwm nodes, misc cleanups.
- am62x-verdin adds uart2, minor fixups for spi1 chip-select pinctrl
- am62-phycore adds hdmi support
- am64-phycore adds R5F support.
- am62x-beagleplay renames console uart pinmuxes.

----------------------------------------------------------------
Andrew Davis (11):
      arm64: dts: ti: k3-am64-main: Fix typo in epwm_tbclk node name
      arm64: dts: ti: k3-am65: Add chipid node to wkup_conf bus
      arm64: dts: ti: k3-j7200: Add chipid node to wkup_conf bus
      arm64: dts: ti: k3-j721e: Add chipid node to wkup_conf bus
      arm64: dts: ti: k3-j721s2: Add chipid node to wkup_conf bus
      arm64: dts: ti: k3-j784s4: Add chipid node to wkup_conf bus
      arm64: dts: ti: k3-am65: Add full compatible to dss-oldi-io-ctrl node
      arm64: dts: ti: k3-am65: Enable SDHCI nodes at the board level
      arm64: dts: ti: k3-am64: Enable SDHCI nodes at the board level
      arm64: dts: ti: k3-am625-beagleplay: Use UART name in pinmux name
      arm64: dts: ti: k3-am65: Add AM652 dtsi file

Aradhya Bhatia (1):
      arm64: dts: ti: k3-am62a7-sk: Add interrupt support for IO Expander

Benedikt Niedermayr (1):
      arm64: dts: ti: iot2050: Definitions for runtime pinmuxing

Bhavya Kapoor (3):
      arm64: dts: ti: k3-j7200-main: Add Itap Delay Value For DDR52 speed mode
      arm64: dts: ti: k3-j721s2-main: Add Itap Delay Value For DDR50 speed mode
      arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed mode

Esteban Blanc (2):
      arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
      arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs

Garrett Giordano (4):
      arm64: dts: ti: phycore-am64: Add R5F DMA Region and Mailboxes
      arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Lower I2C1 frequency
      arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Add HDMI support
      arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Remove HDMI Reset Line Name

Jai Luthra (8):
      arm64: dts: ti: k3-am62-main: Enable CSI2-RX
      arm64: dts: ti: k3-am62a-main: Enable CSI2-RX
      arm64: dts: ti: k3-am625-beagleplay: Add overlays for OV5640
      arm64: dts: ti: k3-am62x-sk: Enable camera peripherals
      arm64: dts: ti: k3-am62x: Add overlays for OV5640
      arm64: dts: ti: k3-am62a7-sk: Enable camera peripherals
      arm64: dts: ti: k3-am62x: Add overlay for IMX219
      arm64: dts: ti: Use OF_ALL_DTBS for combined blobs

Jan Kiszka (3):
      arm64: dts: ti: iot2050: Re-add aliases
      arm64: dts: ti: iot2050: Drop unused ecap0 PWM
      arm64: dts: ti: iot2050: Add icssg-prueth nodes for PG2 devices

Jerome Neanne (2):
      arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
      arm64: dts: ti: k3-j784s4-evm: Add support for TPS6594 PMIC

Joao Paulo Goncalves (3):
      arm64: dts: ti: verdin-am62: Improve spi1 chip-select pinctrl
      dt-bindings: arm: ti: Add verdin am62 mallow board
      arm64: dts: ti: Add verdin am62 mallow board

Krzysztof Kozlowski (1):
      arm64: dts: ti: minor whitespace cleanup around '='

Manorit Chawdhry (2):
      arm64: dts: ti: k3-am65: Add additional regs for DMA components
      arm64: dts: ti: k3-j7*: Add additional regs for DMA components

Neha Malcom Francis (2):
      arm64: dts: ti: k3-am69-sk: Add support for TPS6594 PMIC
      arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs

Nitin Yadav (1):
      arm64: dts: ti: k3-am62a-main: Fix GPIO pin count in DT nodes

Parth Pancholi (1):
      arm64: dts: ti: k3-am625-verdin: Enable Verdin UART2

Ronald Wahl (1):
      arm64: dts: ti: k3-am62-main: Add gpio-ranges properties

Sarah Walker (1):
      arm64: dts: ti: k3-am62-main: Add GPU device node

Siddharth Vadapalli (3):
      arm64: dts: ti: k3-am68-sk-base-board: Add alias for MCU CPSW2G
      arm64: dts: ti: k3-j721e-evm: Add overlay for PCIE0 Endpoint Mode
      arm64: dts: ti: k3-j721s2-evm: Add overlay for PCIE1 Endpoint Mode

Su Bao Cheng (1):
      arm64: dts: ti: iot2050: Refactor the m.2 and minipcie power pin

Tomi Valkeinen (1):
      arm64: dts: ti: k3-am65-main: Fix DSS irq trigger type

Vignesh Raghavendra (4):
      arm64: dts: ti: k3-am642-evm/sk: Mark mcu_gpio_intr as reserved
      arm64: dts: ti: k3-am62p5-sk: Mark mcu gpio and mcu_gpio_intr as reserved
      arm64: dts: ti: k3-am62x-sk-common: Mark mcu gpio and mcu_gpio_intr as reserved
      arm64: dts: ti: k3-am6*: Add additional regs for DMA components

 Documentation/devicetree/bindings/arm/ti/k3.yaml   |   2 +
 arch/arm64/boot/dts/ti/Makefile                    |  70 +-
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi           |  96 ++-
 arch/arm64/boot/dts/ti/k3-am62-verdin-dahlia.dtsi  |   3 +-
 arch/arm64/boot/dts/ti/k3-am62-verdin-dev.dtsi     |   3 +-
 arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi  | 188 +++++
 arch/arm64/boot/dts/ti/k3-am62-verdin-yavia.dtsi   |   3 +-
 arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi         |  17 +-
 .../dts/ti/k3-am625-beagleplay-csi2-ov5640.dtso    |  77 ++
 .../ti/k3-am625-beagleplay-csi2-tevi-ov5640.dtso   |  77 ++
 arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts     |   4 +-
 .../boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts     |  98 ++-
 .../boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts |  22 +
 .../boot/dts/ti/k3-am625-verdin-wifi-mallow.dts    |  22 +
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi          | 121 ++-
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts            |  39 +
 arch/arm64/boot/dts/ti/k3-am62p-main.dtsi          |  18 +-
 arch/arm64/boot/dts/ti/k3-am62p5-sk.dts            |   9 +
 arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi     |  16 +
 .../arm64/boot/dts/ti/k3-am62x-sk-csi2-imx219.dtso |  84 +++
 .../arm64/boot/dts/ti/k3-am62x-sk-csi2-ov5640.dtso |  82 ++
 .../boot/dts/ti/k3-am62x-sk-csi2-tevi-ov5640.dtso  |  82 ++
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi           |  22 +-
 arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi    | 103 ++-
 arch/arm64/boot/dts/ti/k3-am642-evm.dts            |  12 +-
 .../boot/dts/ti/k3-am642-phyboard-electra-rdk.dts  |   1 +
 arch/arm64/boot/dts/ti/k3-am642-sk.dts             |  10 +-
 .../boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl.dts    |   1 -
 arch/arm64/boot/dts/ti/k3-am642-tqma64xxl.dtsi     |   1 +
 .../boot/dts/ti/k3-am65-iot2050-common-pg1.dtsi    |  10 +-
 .../boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi    |   4 +-
 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi | 826 +++++++++++++++++++--
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi           |  16 +-
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi            |   8 +-
 arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi         |  13 +-
 arch/arm64/boot/dts/ti/k3-am652.dtsi               |  74 ++
 .../dts/ti/k3-am6528-iot2050-basic-common.dtsi     |  16 +-
 arch/arm64/boot/dts/ti/k3-am654-base-board.dts     |   2 +
 .../dts/ti/k3-am6548-iot2050-advanced-common.dtsi  |   2 +
 .../boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts  |  12 +-
 arch/arm64/boot/dts/ti/k3-am68-sk-base-board.dts   |   1 +
 arch/arm64/boot/dts/ti/k3-am69-sk.dts              |  96 ++-
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi          |   9 +-
 arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi    |  21 +-
 arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi        | 153 ++++
 arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso  |  53 ++
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi          |   8 +-
 arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi    |  21 +-
 arch/arm64/boot/dts/ti/k3-j721e-sk.dts             | 151 ++++
 arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi        | 160 ++++
 arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso |  53 ++
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi         |   9 +-
 arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi   |  21 +-
 arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi       | 193 +++++
 arch/arm64/boot/dts/ti/k3-j784s4-evm.dts           | 102 +++
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi         |   9 +-
 arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi   |  22 +-
 57 files changed, 3183 insertions(+), 165 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-beagleplay-csi2-ov5640.dtso
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-beagleplay-csi2-tevi-ov5640.dtso
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am62x-sk-csi2-imx219.dtso
 create mode 100644 arch/arm64/boot/dts/ti/k3-am62x-sk-csi2-ov5640.dtso
 create mode 100644 arch/arm64/boot/dts/ti/k3-am62x-sk-csi2-tevi-ov5640.dtso
 create mode 100644 arch/arm64/boot/dts/ti/k3-am652.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-pcie0-ep.dtso
 create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-pcie1-ep.dtso

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/6f58adab/attachment.sig>

From jbx6244 at gmail.com  Mon Dec 18 07:47:30 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 18 Dec 2023 16:47:30 +0100
Subject: [PATCH v2 0/2] Rockchip rk3066_hdmi update
Message-ID: <f86ec29f-194a-800d-0aaf-9e16e551b37d@gmail.com>

Update the Rockchip rk3066_hdmi driver in a somewhat similar way
to what is proposed for the inno_hdmi driver.

Changed V2:
  Drop already applied patches
  Remove "Remove useless output format" patch for now
  Add fill_modes hook removal patch

Johan Jonker (2):
  drm/rockchip: rk3066_hdmi: remove unused drm device pointer
  drm/rockchip: rk3066_hdmi: drop custom fill_modes hook

 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 16 +---------------
 1 file changed, 1 insertion(+), 15 deletions(-)

--
2.39.2



From laurent.pinchart at ideasonboard.com  Mon Dec 18 07:48:38 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 18 Dec 2023 17:48:38 +0200
Subject: [PATCH v4 05/11] media: rkisp1: Fix RSZ_CTRL bits for i.MX8MP
In-Reply-To: <03b98b67-e88c-4bb0-a01d-5a90f78e04a3@ideasonboard.com>
References: <20231129092759.242641-1-paul.elder@ideasonboard.com>
 <20231129092759.242641-6-paul.elder@ideasonboard.com>
 <03b98b67-e88c-4bb0-a01d-5a90f78e04a3@ideasonboard.com>
Message-ID: <20231218154838.GR5290@pendragon.ideasonboard.com>

On Mon, Dec 18, 2023 at 05:31:18PM +0200, Tomi Valkeinen wrote:
> Hi Paul,
> 
> On 29/11/2023 11:27, Paul Elder wrote:
> > The ISP8000Nano, found in the i.MX8MP, has a different architecture to
> > crop at the resizer input. Instead of the "dual crop" block between the
> > ISP and the resizers found in the RK3399, cropping has been moved to the
> > input of the resizer blocks. As a result, the resizer CFG_UPD and
> > CFG_UPD_AUTO bits have been moved to make space for a new CROP_ENABLE
> > bit.
> > 
> > Fix the resizer shadow update accordingly, using the DUAL_CROP feature
> > to infer whether or not the resizer implements cropping. Support for
> > resizer cropping itself will be added in a subsequent commit.
> > 
> > Signed-off-by: Paul Elder <paul.elder at ideasonboard.com>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> 
> I don't think this one is correct.
> 
> The above is perhaps true for ISP8000, but ISP8000Nano does not have 
> CROP_ENABLE bit, and the CFG_UPD and CFG_UPD_AUTO are at the same 
> locations as on RK3399.
> 
> I don't have documentation to prove this, but experimentation shows that 
> this is the case.

I agree with you. The missing CROP_ENABLE bit matches the missing
resizer input crop capability in the i.MX8MP. I don't know if that's
specific to the i.MX8MP, specific to the ISP8000Nano, or common to all
ISP8000 versions when the instance is synthesized with a single path
(which may be what ISP8000Nano is).

> > ---
> > Changes since v3:
> > 
> > - Condition on RKISP1_FEATURE_DUAL_CROP feature
> > - Update commit message
> > 
> > Changes since v2:
> > 
> > - Condition on RKISP1_FEATURE_RSZ_CROP feature
> > - Rename bits
> > - Use the rkisp1_has_feature() macro
> > 
> >   .../media/platform/rockchip/rkisp1/rkisp1-regs.h  |  5 +++++
> >   .../platform/rockchip/rkisp1/rkisp1-resizer.c     | 15 +++++++++++----
> >   2 files changed, 16 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> > index 3b19c8411360..95646b45f28b 100644
> > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> > @@ -168,6 +168,11 @@
> >   #define RKISP1_CIF_RSZ_CTRL_CFG_UPD_AUTO		BIT(9)
> >   #define RKISP1_CIF_RSZ_SCALER_FACTOR			BIT(16)
> >   
> > +/* For resizer instances that support cropping */
> > +#define RKISP1_CIF_RSZ_CTRL_CROP_ENABLE			BIT(8)
> > +#define RKISP1_CIF_RSZ_CTRL_CROP_CFG_UPD		BIT(9)
> > +#define RKISP1_CIF_RSZ_CTRL_CROP_CFG_UPD_AUTO		BIT(10)
> > +
> >   /* MI_IMSC - MI_MIS - MI_RIS - MI_ICR - MI_ISR */
> >   #define RKISP1_CIF_MI_FRAME(stream)			BIT((stream)->id)
> >   #define RKISP1_CIF_MI_MBLK_LINE				BIT(2)
> > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c
> > index c1aaeed58acc..6d6ebc53c6e5 100644
> > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c
> > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c
> > @@ -178,10 +178,17 @@ static void rkisp1_rsz_update_shadow(struct rkisp1_resizer *rsz,
> >   {
> >   	u32 ctrl_cfg = rkisp1_rsz_read(rsz, RKISP1_CIF_RSZ_CTRL);
> >   
> > -	if (when == RKISP1_SHADOW_REGS_ASYNC)
> > -		ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CFG_UPD_AUTO;
> > -	else
> > -		ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CFG_UPD;
> > +	if (when == RKISP1_SHADOW_REGS_ASYNC) {
> > +		if (rkisp1_has_feature(rsz->rkisp1, DUAL_CROP))
> > +			ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CFG_UPD_AUTO;
> > +		else
> > +			ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CROP_CFG_UPD_AUTO;
> > +	} else {
> > +		if (rkisp1_has_feature(rsz->rkisp1, DUAL_CROP))
> > +			ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CFG_UPD;
> > +		else
> > +			ctrl_cfg |= RKISP1_CIF_RSZ_CTRL_CROP_CFG_UPD;
> > +	}
> >   
> >   	rkisp1_rsz_write(rsz, RKISP1_CIF_RSZ_CTRL, ctrl_cfg);
> >   }

-- 
Regards,

Laurent Pinchart


From jbx6244 at gmail.com  Mon Dec 18 07:48:40 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 18 Dec 2023 16:48:40 +0100
Subject: [PATCH v2 1/2] drm/rockchip: rk3066_hdmi: remove unused drm device
 pointer
In-Reply-To: <f86ec29f-194a-800d-0aaf-9e16e551b37d@gmail.com>
References: <f86ec29f-194a-800d-0aaf-9e16e551b37d@gmail.com>
Message-ID: <745f84db-dc9b-81b2-6171-4d8d86a96966@gmail.com>

The drm_dev field in the rk3066_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 62e6d8187de7..0dac6d133767 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -40,7 +40,6 @@ struct rk3066_hdmi_i2c {

 struct rk3066_hdmi {
 	struct device *dev;
-	struct drm_device *drm_dev;
 	struct regmap *grf_regmap;
 	int irq;
 	struct clk *hclk;
@@ -752,7 +751,6 @@ static int rk3066_hdmi_bind(struct device *dev, struct device *master,
 		return -ENOMEM;

 	hdmi->dev = dev;
-	hdmi->drm_dev = drm;
 	hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hdmi->regs))
 		return PTR_ERR(hdmi->regs);
--
2.39.2



From jbx6244 at gmail.com  Mon Dec 18 07:49:06 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 18 Dec 2023 16:49:06 +0100
Subject: [PATCH v2 2/2] drm/rockchip: rk3066_hdmi: drop custom fill_modes hook
In-Reply-To: <f86ec29f-194a-800d-0aaf-9e16e551b37d@gmail.com>
References: <f86ec29f-194a-800d-0aaf-9e16e551b37d@gmail.com>
Message-ID: <410b116b-cb63-7ba7-3689-4f0832ab5796@gmail.com>

CRTC size validation for the display controller has been added with
Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
hardware capabilities"), so we can drop the custom fill_modes hook.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 0dac6d133767..6dadd753985c 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -501,18 +501,6 @@ rk3066_hdmi_connector_best_encoder(struct drm_connector *connector)
 	return &hdmi->encoder.encoder;
 }

-static int
-rk3066_hdmi_probe_single_connector_modes(struct drm_connector *connector,
-					 uint32_t maxX, uint32_t maxY)
-{
-	if (maxX > 1920)
-		maxX = 1920;
-	if (maxY > 1080)
-		maxY = 1080;
-
-	return drm_helper_probe_single_connector_modes(connector, maxX, maxY);
-}
-
 static void rk3066_hdmi_connector_destroy(struct drm_connector *connector)
 {
 	drm_connector_unregister(connector);
@@ -520,7 +508,7 @@ static void rk3066_hdmi_connector_destroy(struct drm_connector *connector)
 }

 static const struct drm_connector_funcs rk3066_hdmi_connector_funcs = {
-	.fill_modes = rk3066_hdmi_probe_single_connector_modes,
+	.fill_modes = drm_helper_probe_single_connector_modes,
 	.detect = rk3066_hdmi_connector_detect,
 	.destroy = rk3066_hdmi_connector_destroy,
 	.reset = drm_atomic_helper_connector_reset,
--
2.39.2



From andre.przywara at arm.com  Mon Dec 18 07:53:45 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 18 Dec 2023 15:53:45 +0000
Subject: [PATCH v2 3/5] cpufreq: sun50i: Add D1 support
In-Reply-To: <20231218-blabber-slapstick-ab7ae45af019@spud>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
	<20231218110543.64044-4-fusibrandon13@gmail.com>
	<20231218-blabber-slapstick-ab7ae45af019@spud>
Message-ID: <20231218155345.476e71ea@donnerap.manchester.arm.com>

On Mon, 18 Dec 2023 14:55:30 +0000
Conor Dooley <conor at kernel.org> wrote:

Hi,

> On Mon, Dec 18, 2023 at 12:05:41PM +0100, Brandon Cheo Fusi wrote:
> > Add support for D1 based devices to the Allwinner H6 cpufreq
> > driver
> > 
> > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > ---
> >  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > index 32a9c88f8..ccf83780f 100644
> > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > @@ -160,6 +160,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
> >  
> >  static const struct of_device_id sun50i_cpufreq_match_list[] = {
> >  	{ .compatible = "allwinner,sun50i-h6" },
> > +	{ .compatible = "allwinner,sun20i-d1" },  
> 
> I thought the feedback in v2 was to drop this change, since the
> devicetree has the sun50i-h6 as a fallback compatible?

Well, this is the *board* (fallback) compatible string, so we cannot assign
it as we like. The whole (existing) scheme is admittedly somewhat weird,
because we not only match on a particular device compatible
(like allwinner,sun20i-d1-operating-points), but also need to blocklist and
re-match some parts against the *board compatible*, owing to the
cpufreq-dt driver. The board name is basically used as a placeholder to
find out the SoC, because there is (or was?) no other good way - the
CPU DT nodes don't work for this. Back when this was introduced, this was
the "least worst" solution.

I don't remember all the details, and didn't find time yet to look into
this in more detail, but fixing this is non-trivial. If this isn't 6.8
material, I might have a look at this later this week/month.

Cheers,
Andre


From alain.volmat at foss.st.com  Mon Dec 18 07:57:12 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Mon, 18 Dec 2023 16:57:12 +0100
Subject: [PATCH 0/6] spi: stm32: add support for stm32mp25
Message-ID: <20231218155721.359198-1-alain.volmat@foss.st.com>

This series adds support for spi bus found on the stm32mp25 and add
all instances within device-trees.

Alain Volmat (4):
  spi: stm32: use dma_get_slave_caps prior to configuring dma channel
  arm64: dts: st: add all 8 spi nodes on stm32mp251
  arm64: dts: st: add spi3/spi8 pins for stm32mp25
  arm64: dts: st: add spi3 / spi8 properties on stm32mp257f-ev1

Valentin Caron (2):
  dt-bindings: spi: stm32: add st,stm32mp25-spi compatible
  spi: stm32: add st,stm32mp25-spi compatible supporting STM32MP25 soc

 .../devicetree/bindings/spi/st,stm32-spi.yaml |   1 +
 arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi |  46 ++++++
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  88 +++++++++++
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |  14 ++
 drivers/spi/spi-stm32.c                       | 145 ++++++++++++++++--
 5 files changed, 280 insertions(+), 14 deletions(-)

-- 
2.25.1



From alain.volmat at foss.st.com  Mon Dec 18 07:57:14 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Mon, 18 Dec 2023 16:57:14 +0100
Subject: [PATCH 2/6] dt-bindings: spi: stm32: add st,stm32mp25-spi compatible
In-Reply-To: <20231218155721.359198-1-alain.volmat@foss.st.com>
References: <20231218155721.359198-1-alain.volmat@foss.st.com>
Message-ID: <20231218155721.359198-3-alain.volmat@foss.st.com>

From: Valentin Caron <valentin.caron at foss.st.com>

Add st,stm32mp25-spi compatible in dt-bindings.  STM32MP25 spi is similar
to the STM32H7 except for the following two points:
  - Burst should not be enabled with the new DMA used on STM32MP25.
  - STM32MP25 SPI8 has a limited feature set, it can only send words of
    8 or 16 bits and with a maximum words number of 1024.

Signed-off-by: Valentin Caron <valentin.caron at foss.st.com>
Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 Documentation/devicetree/bindings/spi/st,stm32-spi.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
index 5754d603f34f..4bd9aeb81208 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
@@ -25,6 +25,7 @@ properties:
       - st,stm32f4-spi
       - st,stm32f7-spi
       - st,stm32h7-spi
+      - st,stm32mp25-spi
 
   reg:
     maxItems: 1
-- 
2.25.1



From alain.volmat at foss.st.com  Mon Dec 18 07:57:13 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Mon, 18 Dec 2023 16:57:13 +0100
Subject: [PATCH 1/6] spi: stm32: use dma_get_slave_caps prior to configuring dma channel
In-Reply-To: <20231218155721.359198-1-alain.volmat@foss.st.com>
References: <20231218155721.359198-1-alain.volmat@foss.st.com>
Message-ID: <20231218155721.359198-2-alain.volmat@foss.st.com>

First check the dma channel capabilities (max burst) before
configuring the dma channel.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 drivers/spi/spi-stm32.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index f48e4dcc29fc..af0c27d8d704 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -1157,15 +1157,19 @@ static void stm32_spi_dma_rx_cb(void *data)
  * stm32_spi_dma_config - configure dma slave channel depending on current
  *			  transfer bits_per_word.
  * @spi: pointer to the spi controller data structure
+ * @dma_chan: pointer to the DMA channel
  * @dma_conf: pointer to the dma_slave_config structure
  * @dir: direction of the dma transfer
  */
 static void stm32_spi_dma_config(struct stm32_spi *spi,
+				 struct dma_chan *dma_chan,
 				 struct dma_slave_config *dma_conf,
 				 enum dma_transfer_direction dir)
 {
 	enum dma_slave_buswidth buswidth;
+	struct dma_slave_caps caps;
 	u32 maxburst;
+	int ret;
 
 	if (spi->cur_bpw <= 8)
 		buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
@@ -1184,6 +1188,11 @@ static void stm32_spi_dma_config(struct stm32_spi *spi,
 		maxburst = 1;
 	}
 
+	/* Get the DMA channel caps, and adjust maxburst if possible */
+	ret = dma_get_slave_caps(dma_chan, &caps);
+	if (!ret)
+		maxburst = min(maxburst, caps.max_burst);
+
 	memset(dma_conf, 0, sizeof(struct dma_slave_config));
 	dma_conf->direction = dir;
 	if (dma_conf->direction == DMA_DEV_TO_MEM) { /* RX */
@@ -1366,7 +1375,7 @@ static int stm32_spi_transfer_one_dma(struct stm32_spi *spi,
 
 	rx_dma_desc = NULL;
 	if (spi->rx_buf && spi->dma_rx) {
-		stm32_spi_dma_config(spi, &rx_dma_conf, DMA_DEV_TO_MEM);
+		stm32_spi_dma_config(spi, spi->dma_rx, &rx_dma_conf, DMA_DEV_TO_MEM);
 		dmaengine_slave_config(spi->dma_rx, &rx_dma_conf);
 
 		/* Enable Rx DMA request */
@@ -1382,7 +1391,7 @@ static int stm32_spi_transfer_one_dma(struct stm32_spi *spi,
 
 	tx_dma_desc = NULL;
 	if (spi->tx_buf && spi->dma_tx) {
-		stm32_spi_dma_config(spi, &tx_dma_conf, DMA_MEM_TO_DEV);
+		stm32_spi_dma_config(spi, spi->dma_tx, &tx_dma_conf, DMA_MEM_TO_DEV);
 		dmaengine_slave_config(spi->dma_tx, &tx_dma_conf);
 
 		tx_dma_desc = dmaengine_prep_slave_sg(
-- 
2.25.1



From alain.volmat at foss.st.com  Mon Dec 18 07:57:15 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Mon, 18 Dec 2023 16:57:15 +0100
Subject: [PATCH 3/6] spi: stm32: add st,stm32mp25-spi compatible supporting STM32MP25 soc
In-Reply-To: <20231218155721.359198-1-alain.volmat@foss.st.com>
References: <20231218155721.359198-1-alain.volmat@foss.st.com>
Message-ID: <20231218155721.359198-4-alain.volmat@foss.st.com>

From: Valentin Caron <valentin.caron at foss.st.com>

Add support for the STM32MP25:
- Burst should not be enabled with the new DMA used on STM32MP25.
- STM32MP25 SPI8 has a limited feature set, it can only send words of
  8 or 16 bits and with a maximum words number of 1024.

Signed-off-by: Valentin Caron <valentin.caron at foss.st.com>
Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 drivers/spi/spi-stm32.c | 132 ++++++++++++++++++++++++++++++++++++----
 1 file changed, 120 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c
index af0c27d8d704..e61302ef3c21 100644
--- a/drivers/spi/spi-stm32.c
+++ b/drivers/spi/spi-stm32.c
@@ -154,6 +154,20 @@
 /* STM32H7_SPI_I2SCFGR bit fields */
 #define STM32H7_SPI_I2SCFGR_I2SMOD	BIT(0)
 
+/* STM32MP25 SPI registers bit fields */
+#define STM32MP25_SPI_HWCFGR1			0x3F0
+
+/* STM32MP25_SPI_CR2 bit fields */
+#define STM32MP25_SPI_TSIZE_MAX_LIMITED		GENMASK(9, 0)
+
+/* STM32MP25_SPI_HWCFGR1 */
+#define STM32MP25_SPI_HWCFGR1_FULLCFG		GENMASK(27, 24)
+#define STM32MP25_SPI_HWCFGR1_FULLCFG_LIMITED	0x0
+#define STM32MP25_SPI_HWCFGR1_FULLCFG_FULL	0x1
+#define STM32MP25_SPI_HWCFGR1_DSCFG		GENMASK(19, 16)
+#define STM32MP25_SPI_HWCFGR1_DSCFG_16_B	0x0
+#define STM32MP25_SPI_HWCFGR1_DSCFG_32_B	0x1
+
 /* STM32H7 SPI Master Baud Rate min/max divisor */
 #define STM32H7_SPI_MBR_DIV_MIN		(2 << STM32H7_SPI_CFG1_MBR_MIN)
 #define STM32H7_SPI_MBR_DIV_MAX		(2 << STM32H7_SPI_CFG1_MBR_MAX)
@@ -207,6 +221,7 @@ struct stm32_spi_reg {
  * @br: baud rate register and bitfields
  * @rx: SPI RX data register
  * @tx: SPI TX data register
+ * @fullcfg: SPI full or limited feature set register
  */
 struct stm32_spi_regspec {
 	const struct stm32_spi_reg en;
@@ -219,6 +234,7 @@ struct stm32_spi_regspec {
 	const struct stm32_spi_reg br;
 	const struct stm32_spi_reg rx;
 	const struct stm32_spi_reg tx;
+	const struct stm32_spi_reg fullcfg;
 };
 
 struct stm32_spi;
@@ -250,6 +266,7 @@ struct stm32_spi;
  * @has_fifo: boolean to know if fifo is used for driver
  * @has_device_mode: is this compatible capable to switch on device mode
  * @flags: compatible specific SPI controller flags used at registration time
+ * @prevent_dma_burst: boolean to indicate to prevent DMA burst
  */
 struct stm32_spi_cfg {
 	const struct stm32_spi_regspec *regs;
@@ -274,6 +291,7 @@ struct stm32_spi_cfg {
 	bool has_fifo;
 	bool has_device_mode;
 	u16 flags;
+	bool prevent_dma_burst;
 };
 
 /**
@@ -287,6 +305,8 @@ struct stm32_spi_cfg {
  * @lock: prevent I/O concurrent access
  * @irq: SPI controller interrupt line
  * @fifo_size: size of the embedded fifo in bytes
+ * @t_size_max: maximum number of data of one transfer
+ * @feature_set: SPI full or limited feature set
  * @cur_midi: host inter-data idleness in ns
  * @cur_speed: speed configured in Hz
  * @cur_half_period: time of a half bit in us
@@ -314,6 +334,10 @@ struct stm32_spi {
 	spinlock_t lock; /* prevent I/O concurrent access */
 	int irq;
 	unsigned int fifo_size;
+	unsigned int t_size_max;
+	unsigned int feature_set;
+#define STM32_SPI_FEATURE_LIMITED	STM32MP25_SPI_HWCFGR1_FULLCFG_LIMITED	/* 0x0 */
+#define STM32_SPI_FEATURE_FULL		STM32MP25_SPI_HWCFGR1_FULLCFG_FULL	/* 0x1 */
 
 	unsigned int cur_midi;
 	unsigned int cur_speed;
@@ -371,6 +395,28 @@ static const struct stm32_spi_regspec stm32h7_spi_regspec = {
 	.tx = { STM32H7_SPI_TXDR },
 };
 
+static const struct stm32_spi_regspec stm32mp25_spi_regspec = {
+	/* SPI data transfer is enabled but spi_ker_ck is idle.
+	 * CFG1 and CFG2 registers are write protected when SPE is enabled.
+	 */
+	.en = { STM32H7_SPI_CR1, STM32H7_SPI_CR1_SPE },
+
+	.dma_rx_en = { STM32H7_SPI_CFG1, STM32H7_SPI_CFG1_RXDMAEN },
+	.dma_tx_en = { STM32H7_SPI_CFG1, STM32H7_SPI_CFG1_TXDMAEN },
+
+	.cpol = { STM32H7_SPI_CFG2, STM32H7_SPI_CFG2_CPOL },
+	.cpha = { STM32H7_SPI_CFG2, STM32H7_SPI_CFG2_CPHA },
+	.lsb_first = { STM32H7_SPI_CFG2, STM32H7_SPI_CFG2_LSBFRST },
+	.cs_high = { STM32H7_SPI_CFG2, STM32H7_SPI_CFG2_SSIOP },
+	.br = { STM32H7_SPI_CFG1, STM32H7_SPI_CFG1_MBR,
+		STM32H7_SPI_CFG1_MBR_SHIFT },
+
+	.rx = { STM32H7_SPI_RXDR },
+	.tx = { STM32H7_SPI_TXDR },
+
+	.fullcfg = { STM32MP25_SPI_HWCFGR1, STM32MP25_SPI_HWCFGR1_FULLCFG },
+};
+
 static inline void stm32_spi_set_bits(struct stm32_spi *spi,
 				      u32 offset, u32 bits)
 {
@@ -457,6 +503,28 @@ static int stm32h7_spi_get_bpw_mask(struct stm32_spi *spi)
 	return SPI_BPW_RANGE_MASK(4, max_bpw);
 }
 
+/**
+ * stm32mp25_spi_get_bpw_mask - Return bits per word mask
+ * @spi: pointer to the spi controller data structure
+ */
+static int stm32mp25_spi_get_bpw_mask(struct stm32_spi *spi)
+{
+	u32 dscfg, max_bpw;
+
+	if (spi->feature_set == STM32_SPI_FEATURE_LIMITED) {
+		dev_dbg(spi->dev, "8-bit or 16-bit data frame supported\n");
+		return SPI_BPW_MASK(8) | SPI_BPW_MASK(16);
+	}
+
+	dscfg = FIELD_GET(STM32MP25_SPI_HWCFGR1_DSCFG,
+			  readl_relaxed(spi->base + STM32MP25_SPI_HWCFGR1));
+	max_bpw = 16;
+	if (dscfg == STM32MP25_SPI_HWCFGR1_DSCFG_32_B)
+		max_bpw = 32;
+	dev_dbg(spi->dev, "%d-bit maximum data frame\n", max_bpw);
+	return SPI_BPW_RANGE_MASK(4, max_bpw);
+}
+
 /**
  * stm32_spi_prepare_mbr - Determine baud rate divisor value
  * @spi: pointer to the spi controller data structure
@@ -1103,7 +1171,7 @@ static int stm32_spi_prepare_msg(struct spi_controller *ctrl,
 		int ret;
 
 		ret = spi_split_transfers_maxwords(ctrl, msg,
-						   STM32H7_SPI_TSIZE_MAX,
+						   spi->t_size_max,
 						   GFP_KERNEL | GFP_DMA);
 		if (ret)
 			return ret;
@@ -1168,7 +1236,7 @@ static void stm32_spi_dma_config(struct stm32_spi *spi,
 {
 	enum dma_slave_buswidth buswidth;
 	struct dma_slave_caps caps;
-	u32 maxburst;
+	u32 maxburst = 1;
 	int ret;
 
 	if (spi->cur_bpw <= 8)
@@ -1178,15 +1246,9 @@ static void stm32_spi_dma_config(struct stm32_spi *spi,
 	else
 		buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
 
-	if (spi->cfg->has_fifo) {
-		/* Valid for DMA Half or Full Fifo threshold */
-		if (spi->cur_fthlv == 2)
-			maxburst = 1;
-		else
-			maxburst = spi->cur_fthlv;
-	} else {
-		maxburst = 1;
-	}
+	/* Valid for DMA Half or Full Fifo threshold */
+	if (!spi->cfg->prevent_dma_burst && spi->cfg->has_fifo && spi->cur_fthlv != 2)
+		maxburst = spi->cur_fthlv;
 
 	/* Get the DMA channel caps, and adjust maxburst if possible */
 	ret = dma_get_slave_caps(dma_chan, &caps);
@@ -1671,7 +1733,7 @@ static void stm32h7_spi_data_idleness(struct stm32_spi *spi, u32 len)
  */
 static int stm32h7_spi_number_of_data(struct stm32_spi *spi, u32 nb_words)
 {
-	if (nb_words <= STM32H7_SPI_TSIZE_MAX) {
+	if (nb_words <= spi->t_size_max) {
 		writel_relaxed(FIELD_PREP(STM32H7_SPI_CR2_TSIZE, nb_words),
 			       spi->base + STM32H7_SPI_CR2);
 	} else {
@@ -1954,7 +2016,37 @@ static const struct stm32_spi_cfg stm32h7_spi_cfg = {
 	.has_device_mode = true,
 };
 
+/*
+ * STM32MP2 is compatible with the STM32H7 except:
+ * - enforce the DMA maxburst value to 1
+ * - spi8 have limited feature set (TSIZE_MAX = 1024, BPW of 8 OR 16)
+ */
+static const struct stm32_spi_cfg stm32mp25_spi_cfg = {
+	.regs = &stm32mp25_spi_regspec,
+	.get_fifo_size = stm32h7_spi_get_fifo_size,
+	.get_bpw_mask = stm32mp25_spi_get_bpw_mask,
+	.disable = stm32h7_spi_disable,
+	.config = stm32h7_spi_config,
+	.set_bpw = stm32h7_spi_set_bpw,
+	.set_mode = stm32h7_spi_set_mode,
+	.set_data_idleness = stm32h7_spi_data_idleness,
+	.set_number_of_data = stm32h7_spi_number_of_data,
+	.transfer_one_dma_start = stm32h7_spi_transfer_one_dma_start,
+	.dma_rx_cb = stm32_spi_dma_rx_cb,
+	/*
+	 * dma_tx_cb is not necessary since in case of TX, dma is followed by
+	 * SPI access hence handling is performed within the SPI interrupt
+	 */
+	.transfer_one_irq = stm32h7_spi_transfer_one_irq,
+	.irq_handler_thread = stm32h7_spi_irq_thread,
+	.baud_rate_div_min = STM32H7_SPI_MBR_DIV_MIN,
+	.baud_rate_div_max = STM32H7_SPI_MBR_DIV_MAX,
+	.has_fifo = true,
+	.prevent_dma_burst = true,
+};
+
 static const struct of_device_id stm32_spi_of_match[] = {
+	{ .compatible = "st,stm32mp25-spi", .data = (void *)&stm32mp25_spi_cfg },
 	{ .compatible = "st,stm32h7-spi", .data = (void *)&stm32h7_spi_cfg },
 	{ .compatible = "st,stm32f4-spi", .data = (void *)&stm32f4_spi_cfg },
 	{ .compatible = "st,stm32f7-spi", .data = (void *)&stm32f7_spi_cfg },
@@ -2058,6 +2150,22 @@ static int stm32_spi_probe(struct platform_device *pdev)
 	if (spi->cfg->has_fifo)
 		spi->fifo_size = spi->cfg->get_fifo_size(spi);
 
+	spi->feature_set = STM32_SPI_FEATURE_FULL;
+	if (spi->cfg->regs->fullcfg.reg) {
+		spi->feature_set =
+			FIELD_GET(STM32MP25_SPI_HWCFGR1_FULLCFG,
+				  readl_relaxed(spi->base + spi->cfg->regs->fullcfg.reg));
+
+		dev_dbg(spi->dev, "%s feature set\n",
+			spi->feature_set == STM32_SPI_FEATURE_FULL ? "full" : "limited");
+	}
+
+	/* Only for STM32H7 and after */
+	spi->t_size_max = spi->feature_set == STM32_SPI_FEATURE_FULL ?
+				STM32H7_SPI_TSIZE_MAX :
+				STM32MP25_SPI_TSIZE_MAX_LIMITED;
+	dev_dbg(spi->dev, "one message max size %d\n", spi->t_size_max);
+
 	ret = spi->cfg->config(spi);
 	if (ret) {
 		dev_err(&pdev->dev, "controller configuration failed: %d\n",
-- 
2.25.1



From alain.volmat at foss.st.com  Mon Dec 18 07:57:16 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Mon, 18 Dec 2023 16:57:16 +0100
Subject: [PATCH 4/6] arm64: dts: st: add all 8 spi nodes on stm32mp251
In-Reply-To: <20231218155721.359198-1-alain.volmat@foss.st.com>
References: <20231218155721.359198-1-alain.volmat@foss.st.com>
Message-ID: <20231218155721.359198-5-alain.volmat@foss.st.com>

Add the 8 nodes for all spi instances available on the stm32mp251.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 88 ++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index dfbdb3a773e4..feb30c6fb183 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -108,6 +108,28 @@ rifsc: rifsc-bus at 42080000 {
 			#size-cells = <1>;
 			ranges;
 
+			spi2: spi at 400b0000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32mp25-spi";
+				reg = <0x400b0000 0x400>;
+				interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_SPI2>;
+				resets = <&rcc SPI2_R>;
+				status = "disabled";
+			};
+
+			spi3: spi at 400c0000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32mp25-spi";
+				reg = <0x400c0000 0x400>;
+				interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_SPI3>;
+				resets = <&rcc SPI3_R>;
+				status = "disabled";
+			};
+
 			usart2: serial at 400e0000 {
 				compatible = "st,stm32h7-uart";
 				reg = <0x400e0000 0x400>;
@@ -116,6 +138,72 @@ usart2: serial at 400e0000 {
 				status = "disabled";
 			};
 
+			spi1: spi at 40230000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32mp25-spi";
+				reg = <0x40230000 0x400>;
+				interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_SPI1>;
+				resets = <&rcc SPI1_R>;
+				status = "disabled";
+			};
+
+			spi4: spi at 40240000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32mp25-spi";
+				reg = <0x40240000 0x400>;
+				interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_SPI4>;
+				resets = <&rcc SPI4_R>;
+				status = "disabled";
+			};
+
+			spi5: spi at 40280000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32mp25-spi";
+				reg = <0x40280000 0x400>;
+				interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_SPI5>;
+				resets = <&rcc SPI5_R>;
+				status = "disabled";
+			};
+
+			spi6: spi at 40350000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32mp25-spi";
+				reg = <0x40350000 0x400>;
+				interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_SPI6>;
+				resets = <&rcc SPI6_R>;
+				status = "disabled";
+			};
+
+			spi7: spi at 40360000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32mp25-spi";
+				reg = <0x40360000 0x400>;
+				interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_SPI7>;
+				resets = <&rcc SPI7_R>;
+				status = "disabled";
+			};
+
+			spi8: spi at 46020000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "st,stm32mp25-spi";
+				reg = <0x46020000 0x400>;
+				interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_KER_SPI8>;
+				resets = <&rcc SPI8_R>;
+				status = "disabled";
+			};
+
 			sdmmc1: mmc at 48220000 {
 				compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
 				arm,primecell-periphid = <0x00353180>;
-- 
2.25.1



From alain.volmat at foss.st.com  Mon Dec 18 07:57:17 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Mon, 18 Dec 2023 16:57:17 +0100
Subject: [PATCH 5/6] arm64: dts: st: add spi3/spi8 pins for stm32mp25
In-Reply-To: <20231218155721.359198-1-alain.volmat@foss.st.com>
References: <20231218155721.359198-1-alain.volmat@foss.st.com>
Message-ID: <20231218155721.359198-6-alain.volmat@foss.st.com>

Add the spi3 and spi8 pins used on STM32MP257F-EV1 board.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
index 66791a974f8f..e669bfc8c3f1 100644
--- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
@@ -60,6 +60,28 @@ pins {
 		};
 	};
 
+	spi3_pins_a: spi3-0 {
+		pins1 {
+			pinmux = <STM32_PINMUX('B', 7, AF1)>, /* SPI3_SCK */
+				 <STM32_PINMUX('B', 8, AF1)>; /* SPI3_MOSI */
+			drive-push-pull;
+			bias-disable;
+			slew-rate = <1>;
+		};
+		pins2 {
+			pinmux = <STM32_PINMUX('B', 10, AF1)>; /* SPI3_MISO */
+			bias-disable;
+		};
+	};
+
+	spi3_sleep_pins_a: spi3-sleep-0 {
+		pins1 {
+			pinmux = <STM32_PINMUX('B', 7, ANALOG)>, /* SPI3_SCK */
+				 <STM32_PINMUX('B', 8, ANALOG)>, /* SPI3_MOSI */
+				 <STM32_PINMUX('B', 10, ANALOG)>; /* SPI3_MISO */
+		};
+	};
+
 	usart2_pins_a: usart2-0 {
 		pins1 {
 			pinmux = <STM32_PINMUX('A', 4, AF6)>; /* USART2_TX */
@@ -90,3 +112,27 @@ pins {
 		};
 	};
 };
+
+&pinctrl_z {
+	spi8_pins_a: spi8-0 {
+		pins1 {
+			pinmux = <STM32_PINMUX('Z', 2, AF3)>, /* SPI8_SCK */
+				 <STM32_PINMUX('Z', 0, AF3)>; /* SPI8_MOSI */
+			drive-push-pull;
+			bias-disable;
+			slew-rate = <1>;
+		};
+		pins2 {
+			pinmux = <STM32_PINMUX('Z', 1, AF3)>; /* SPI8_MISO */
+			bias-disable;
+		};
+	};
+
+	spi8_sleep_pins_a: spi8-sleep-0 {
+		pins1 {
+			pinmux = <STM32_PINMUX('Z', 2, ANALOG)>, /* SPI8_SCK */
+				 <STM32_PINMUX('Z', 0, ANALOG)>, /* SPI8_MOSI */
+				 <STM32_PINMUX('Z', 1, ANALOG)>; /* SPI8_MISO */
+		};
+	};
+};
-- 
2.25.1



From alain.volmat at foss.st.com  Mon Dec 18 07:57:18 2023
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Mon, 18 Dec 2023 16:57:18 +0100
Subject: [PATCH 6/6] arm64: dts: st: add spi3 / spi8 properties on stm32mp257f-ev1
In-Reply-To: <20231218155721.359198-1-alain.volmat@foss.st.com>
References: <20231218155721.359198-1-alain.volmat@foss.st.com>
Message-ID: <20231218155721.359198-7-alain.volmat@foss.st.com>

Add properties for spi3 and spi8 available on the stm32mp257f-ev1.
Both are kept disabled since only used via the gpio expansion connector.

Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index b2d3afb15758..1ea3c82ca477 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -68,6 +68,20 @@ &sdmmc1 {
 	status = "okay";
 };
 
+&spi3 {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&spi3_pins_a>;
+	pinctrl-1 = <&spi3_sleep_pins_a>;
+	status = "disabled";
+};
+
+&spi8 {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&spi8_pins_a>;
+	pinctrl-1 = <&spi8_sleep_pins_a>;
+	status = "disabled";
+};
+
 &usart2 {
 	pinctrl-names = "default", "idle", "sleep";
 	pinctrl-0 = <&usart2_pins_a>;
-- 
2.25.1



From samuel at sholland.org  Mon Dec 18 08:14:42 2023
From: samuel at sholland.org (Samuel Holland)
Date: Mon, 18 Dec 2023 10:14:42 -0600
Subject: [PATCH v2 1/5] riscv: dts: allwinner: Update opp table to allow
 CPU frequency scaling
In-Reply-To: <20231218110543.64044-2-fusibrandon13@gmail.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
 <20231218110543.64044-2-fusibrandon13@gmail.com>
Message-ID: <aad8302d-a015-44ee-ad11-1a4c6e00074c@sholland.org>

On 12/18/23 05:05, Brandon Cheo Fusi wrote:
> Two OPPs are currently defined for the D1/D1s; one at 408MHz and
> another at 1.08GHz. Switching between these can be done with the
> "sun50i-cpufreq-nvmem" driver. This patch populates the opp table
> appropriately, inspired by
> https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi
> 
> The supply voltages are PWM-controlled, but support for that IP
> is still in the works. So stick to a target vdd-cpu supply of 0.9V,
> which seems to be the default on most D1 boards.
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> index 64c3c2e6c..2f1771c19 100644
> --- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> @@ -39,16 +39,22 @@ cpu0_intc: interrupt-controller {
>  	};
>  
>  	opp_table_cpu: opp-table-cpu {
> -		compatible = "operating-points-v2";
> +		compatible = "allwinner,sun20i-d1-operating-points",
> +				 "allwinner,sun50i-h6-operating-points";

This is not correct. The compatible string specifies the algorithm for
looking up the speed grade from the NVMEM cell, and D1 uses a totally
different algorithm compared to H6:

https://github.com/Tina-Linux/linux-5.4/blob/master/drivers/cpufreq/sun50i-cpufreq-nvmem.c#L293-L338

So you cannot use a fallback compatible string here, and you need to add
driver support for the D1's speed bin encoding.

Regards,
Samuel

> +		nvmem-cells = <&cpu_speed_grade>;
> +		nvmem-cell-names = "speed";
> +		opp-shared;
>  
>  		opp-408000000 {
> +			clock-latency-ns = <244144>; /* 8 32k periods */
>  			opp-hz = /bits/ 64 <408000000>;
> -			opp-microvolt = <900000 900000 1100000>;
> +			opp-microvolt-speed0 = <900000 900000 1100000>;
>  		};
>  
>  		opp-1080000000 {
> +			clock-latency-ns = <244144>; /* 8 32k periods */
>  			opp-hz = /bits/ 64 <1008000000>;
> -			opp-microvolt = <900000 900000 1100000>;
> +			opp-microvolt-speed0 = <900000 900000 1100000>;
>  		};
>  	};
>  
> @@ -115,3 +121,9 @@ pmu {
>  			<0x00000000 0x0000000f 0xffffffff 0xffffffff 0x00020000>;
>  	};
>  };
> +
> +&sid {
> +	cpu_speed_grade: cpu-speed-grade at 0 {
> +		reg = <0x00 0x2>;
> +	};
> +};



From jernej.skrabec at gmail.com  Mon Dec 18 08:15:12 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Mon, 18 Dec 2023 17:15:12 +0100
Subject: [PATCH v2 3/5] cpufreq: sun50i: Add D1 support
In-Reply-To: <20231218155345.476e71ea@donnerap.manchester.arm.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
 <20231218-blabber-slapstick-ab7ae45af019@spud>
 <20231218155345.476e71ea@donnerap.manchester.arm.com>
Message-ID: <2710663.mvXUDI8C0e@jernej-laptop>

Dne ponedeljek, 18. december 2023 ob 16:53:45 CET je Andre Przywara napisal(a):
> On Mon, 18 Dec 2023 14:55:30 +0000
> Conor Dooley <conor at kernel.org> wrote:
> 
> Hi,
> 
> > On Mon, Dec 18, 2023 at 12:05:41PM +0100, Brandon Cheo Fusi wrote:
> > > Add support for D1 based devices to the Allwinner H6 cpufreq
> > > driver
> > > 
> > > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > > ---
> > >  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > index 32a9c88f8..ccf83780f 100644
> > > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > @@ -160,6 +160,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
> > >  
> > >  static const struct of_device_id sun50i_cpufreq_match_list[] = {
> > >  	{ .compatible = "allwinner,sun50i-h6" },
> > > +	{ .compatible = "allwinner,sun20i-d1" },  
> > 
> > I thought the feedback in v2 was to drop this change, since the
> > devicetree has the sun50i-h6 as a fallback compatible?
> 
> Well, this is the *board* (fallback) compatible string, so we cannot assign
> it as we like. The whole (existing) scheme is admittedly somewhat weird,
> because we not only match on a particular device compatible
> (like allwinner,sun20i-d1-operating-points), but also need to blocklist and
> re-match some parts against the *board compatible*, owing to the
> cpufreq-dt driver. The board name is basically used as a placeholder to
> find out the SoC, because there is (or was?) no other good way - the
> CPU DT nodes don't work for this. Back when this was introduced, this was
> the "least worst" solution.
> 
> I don't remember all the details, and didn't find time yet to look into
> this in more detail, but fixing this is non-trivial. If this isn't 6.8
> material, I might have a look at this later this week/month.

I would say it's 6.9 material. -rc6 already passed and it's not yet aligned
with all maintainers.

Best regards,
Jernej




From jernej.skrabec at gmail.com  Mon Dec 18 08:16:52 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Mon, 18 Dec 2023 17:16:52 +0100
Subject: [PATCH v2 5/5] cpufreq: Make sun50i h6 cpufreq Kconfig option arch
 generic
In-Reply-To: <20231218110543.64044-6-fusibrandon13@gmail.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
 <20231218110543.64044-6-fusibrandon13@gmail.com>
Message-ID: <5737049.DvuYhMxLoT@jernej-laptop>

Dne ponedeljek, 18. december 2023 ob 12:05:43 CET je Brandon Cheo Fusi napisal(a):
> Move the Allwinner SUN50I cpufreq driver from Kconfig.arm to the
> main Kconfig file so it supports other architectures, like RISC-V
> in our case, and drop the 'ARM_' prefix.
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  drivers/cpufreq/Kconfig     | 12 ++++++++++++
>  drivers/cpufreq/Kconfig.arm | 12 ------------
>  drivers/cpufreq/Makefile    |  2 +-
>  3 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index 35efb53d5..50aa66cfc 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -301,5 +301,17 @@ config QORIQ_CPUFREQ
>  	  This adds the CPUFreq driver support for Freescale QorIQ SoCs
>  	  which are capable of changing the CPU's frequency dynamically.
>  
> +config ALLWINNER_SUN50I_CPUFREQ_NVMEM
> +	tristate "Allwinner nvmem based SUN50I CPUFreq driver"
> +	depends on ARCH_SUNXI
> +	depends on NVMEM_SUNXI_SID
> +	select PM_OPP
> +	help
> +	  This adds the nvmem based CPUFreq driver for Allwinner
> +	  h6/D1 SoCs.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called sun50i-cpufreq-nvmem.
> +
>  endif
>  endmenu
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index f91160689..98b8e6eef 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -29,18 +29,6 @@ config ACPI_CPPC_CPUFREQ_FIE
>  
>  	  If in doubt, say N.
>  
> -config ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM
> -	tristate "Allwinner nvmem based SUN50I CPUFreq driver"
> -	depends on ARCH_SUNXI
> -	depends on NVMEM_SUNXI_SID
> -	select PM_OPP
> -	help
> -	  This adds the nvmem based CPUFreq driver for Allwinner
> -	  h6 SoC.
> -
> -	  To compile this driver as a module, choose M here: the
> -	  module will be called sun50i-cpufreq-nvmem.
> -
>  config ARM_APPLE_SOC_CPUFREQ
>  	tristate "Apple Silicon SoC CPUFreq support"
>  	depends on ARCH_APPLE || (COMPILE_TEST && 64BIT)
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 8d141c71b..110b676d2 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -78,7 +78,7 @@ obj-$(CONFIG_ARM_SCMI_CPUFREQ)		+= scmi-cpufreq.o
>  obj-$(CONFIG_ARM_SCPI_CPUFREQ)		+= scpi-cpufreq.o
>  obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
>  obj-$(CONFIG_ARM_STI_CPUFREQ)		+= sti-cpufreq.o
> -obj-$(CONFIG_ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM) += sun50i-cpufreq-nvmem.o
> +obj-$(CONFIG_ALLWINNER_SUN50I_CPUFREQ_NVMEM) += sun50i-cpufreq-nvmem.o

This should be moved, so it's sorted alphabetically.

Best regards,
Jernej

>  obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)	+= tegra20-cpufreq.o
>  obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)	+= tegra124-cpufreq.o
>  obj-$(CONFIG_ARM_TEGRA186_CPUFREQ)	+= tegra186-cpufreq.o
> 






From nm at ti.com  Mon Dec 18 08:19:02 2023
From: nm at ti.com (Nishanth Menon)
Date: Mon, 18 Dec 2023 10:19:02 -0600
Subject: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc
 for wkup_uart0
In-Reply-To: <20231218072831.GX5169@atomide.com>
References: <20231114073209.40756-1-tony@atomide.com>
 <20231215160047.uiitnlgmirbudmj5@scored>
 <20231218072831.GX5169@atomide.com>
Message-ID: <20231218161902.nfdht2hk5rctzxuu@grievance>

On 09:28-20231218, Tony Lindgren wrote:
> * Nishanth Menon <nm at ti.com> [231215 16:00]:
> > On 09:32-20231114, Tony Lindgren wrote:
> > > -	wkup_uart0: serial at 2b300000 {
> > > -		compatible = "ti,am64-uart", "ti,am654-uart";
> > > -		reg = <0x00 0x2b300000 0x00 0x100>;
> > > -		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> > > +	target-module at 2b300000 {
> > 
> > should be  target-module at 2b300050 to match up with reg?
> 
> It's best to use the target-module IO range here, not the first reg.
> The first reg may be tossed anywhere in the target module address
> space depending on the device.
> 
> Ideally of course there would be just a standardized range of target
> module related registers at the end of the IO space..

Sorry Tony, but the node address must matchup with the reg description
for the node. I'd rather not sit and argue about this with automated
tools and deal with trivial patches - so either tools like dtc need to
ignore this or lets just fix the node address.
 
> > > +		wkup_uart0: serial at 2b300000 {
> > 
> > serial at 0  to match up with reg?
> 
> Yes thanks for catching this. The 8250 IP is at the beginning of the
> target module IO space. Will post an updated patch.
> 
> Regards,
> 
> Tony

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From conor at kernel.org  Mon Dec 18 08:19:13 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 18 Dec 2023 16:19:13 +0000
Subject: [PATCH v2 3/5] cpufreq: sun50i: Add D1 support
In-Reply-To: <20231218155345.476e71ea@donnerap.manchester.arm.com>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
 <20231218110543.64044-4-fusibrandon13@gmail.com>
 <20231218-blabber-slapstick-ab7ae45af019@spud>
 <20231218155345.476e71ea@donnerap.manchester.arm.com>
Message-ID: <20231218-qualified-mahogany-05e1d6630152@spud>

On Mon, Dec 18, 2023 at 03:53:45PM +0000, Andre Przywara wrote:
> On Mon, 18 Dec 2023 14:55:30 +0000
> Conor Dooley <conor at kernel.org> wrote:
> 
> Hi,
> 
> > On Mon, Dec 18, 2023 at 12:05:41PM +0100, Brandon Cheo Fusi wrote:
> > > Add support for D1 based devices to the Allwinner H6 cpufreq
> > > driver
> > > 
> > > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > > ---
> > >  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > index 32a9c88f8..ccf83780f 100644
> > > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > @@ -160,6 +160,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
> > >  
> > >  static const struct of_device_id sun50i_cpufreq_match_list[] = {
> > >  	{ .compatible = "allwinner,sun50i-h6" },
> > > +	{ .compatible = "allwinner,sun20i-d1" },  
> > 
> > I thought the feedback in v2 was to drop this change, since the
> > devicetree has the sun50i-h6 as a fallback compatible?
> 
> Well, this is the *board* (fallback) compatible string, so we cannot assign

Oh of course... That's both me and Jernej that tripped up on this.
Brandon, please ignore the comment from me on this patch.

Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/99e9a56d/attachment.sig>

From conor at kernel.org  Mon Dec 18 08:20:16 2023
From: conor at kernel.org (Conor Dooley)
Date: Mon, 18 Dec 2023 16:20:16 +0000
Subject: [PATCH v2 2/5] dt-bindings: opp: sun50i: Add binding for D1 CPUs
In-Reply-To: <20231218-disprove-judgingly-ee54d39474a7@spud>
References: <20231218110543.64044-1-fusibrandon13@gmail.com>
 <20231218110543.64044-3-fusibrandon13@gmail.com>
 <20231218-disprove-judgingly-ee54d39474a7@spud>
Message-ID: <20231218-unsavory-private-50e5b52c632f@spud>

On Mon, Dec 18, 2023 at 02:54:35PM +0000, Conor Dooley wrote:
> On Mon, Dec 18, 2023 at 12:05:40PM +0100, Brandon Cheo Fusi wrote:
> > Add binding for D1 CPU OPPs.
> > 
> > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > ---
> >  .../bindings/opp/allwinner,sun50i-h6-operating-points.yaml    | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> > index 51f62c3ae..fddaa3216 100644
> > --- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> > +++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> > @@ -23,7 +23,9 @@ allOf:
> >  
> >  properties:
> >    compatible:
> > -    const: allwinner,sun50i-h6-operating-points
> > +    enum:
> > +      - allwinner,sun50i-h6-operating-points
> > +      - allwinner,sun20i-d1-operating-points
> 
> This doesn't match what you have in your devicetree.

Per Samuel's comments in
<aad8302d-a015-44ee-ad11-1a4c6e00074c at sholland.org>
it looks like this binding is correct but the devicetree is wrong.

Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/beaa7cc0/attachment.sig>

From ahalaney at redhat.com  Mon Dec 18 08:14:25 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Mon, 18 Dec 2023 10:14:25 -0600
Subject: [PATCH net-next] net: stmmac: Fix ethool link settings ops for
 integrated PCS
In-Reply-To: <20231218135032.27209-1-quic_snehshah@quicinc.com>
References: <20231218135032.27209-1-quic_snehshah@quicinc.com>
Message-ID: <lcfvxawesjc3r2n66zjd2qu5gan7gvvpefgjqjzqwcxosh3n4l@kcggappvytkm>

Hi,

I think the subject should be [PATCH net] since this is a fix.

On Mon, Dec 18, 2023 at 07:20:32PM +0530, Sneh Shah wrote:
> Currently get/set_link_ksettings ethtool ops are dependent on PCS.
> When PCS is integrated in MAC, it will not have separate link config.
> Bypass cofiguring and checking PCS link config for integrated PCS.

s/cofiguring/configuring/

Please add:

    Fixes: ("aa571b6275fb net: stmmac: add new switch to struct plat_stmmacenet_data")

This fixes using the ethtool ops for me so also please feel free to add:

    Tested-by: Andrew Halaney <ahalaney at redhat.com> # sa8775p-ride

Thanks for the patch!

> 
> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> index f628411ae4ae..e3ba4cd47b8d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> @@ -311,8 +311,9 @@ static int stmmac_ethtool_get_link_ksettings(struct net_device *dev,
>  {
>  	struct stmmac_priv *priv = netdev_priv(dev);
>  
> -	if (priv->hw->pcs & STMMAC_PCS_RGMII ||
> -	    priv->hw->pcs & STMMAC_PCS_SGMII) {
> +	if (!(priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS) &&
> +	    (priv->hw->pcs & STMMAC_PCS_RGMII ||
> +	     priv->hw->pcs & STMMAC_PCS_SGMII)) {
>  		struct rgmii_adv adv;
>  		u32 supported, advertising, lp_advertising;
>  
> @@ -397,8 +398,9 @@ stmmac_ethtool_set_link_ksettings(struct net_device *dev,
>  {
>  	struct stmmac_priv *priv = netdev_priv(dev);
>  
> -	if (priv->hw->pcs & STMMAC_PCS_RGMII ||
> -	    priv->hw->pcs & STMMAC_PCS_SGMII) {
> +	if (!(priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS) &&
> +	    (priv->hw->pcs & STMMAC_PCS_RGMII ||
> +	     priv->hw->pcs & STMMAC_PCS_SGMII)) {
>  		/* Only support ANE */
>  		if (cmd->base.autoneg != AUTONEG_ENABLE)
>  			return -EINVAL;
> -- 
> 2.17.1
> 



From romain.gantois at bootlin.com  Mon Dec 18 08:23:22 2023
From: romain.gantois at bootlin.com (Romain Gantois)
Date: Mon, 18 Dec 2023 17:23:22 +0100
Subject: [PATCH net 0/1] Prevent DSA tags from breaking COE
Message-ID: <20231218162326.173127-1-romain.gantois@bootlin.com>

Hello everyone,

This is a bugfix for an issue that was recently brought up in two
reports:

https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495 at bootlin.com/
https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2 at electromag.com.au/

The Checksum Offloading Engine of some stmmac cores (e.g. DWMAC1000)
computes an incorrect checksum when presented with DSA-tagged packets. This
causes all TCP/UDP transfers to break when the stmmac device is connected
to the CPU port of a DSA switch.

The main change introduced by this series is a new stmmac dma feature that
stmmac_mac_link_up() can check to detect cores that have DSA-incompatible
COEs. If the flag is set and the netdevice uses DSA, stmmac_xmit() will
complete checksumming in software instead of offloading it.

I've run some iperf3 tests and the TX hotpath performance doesn't seem
to be degraded by the field added to dma_features.

Best Regards,

Romain

Romain Gantois (1):
  net: stmmac: Prevent DSA tags from breaking COE

 drivers/net/ethernet/stmicro/stmmac/common.h     |  1 +
 .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c  |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c    | 16 +++++++++++++++-
 3 files changed, 17 insertions(+), 1 deletion(-)

-- 
2.43.0



From romain.gantois at bootlin.com  Mon Dec 18 08:23:23 2023
From: romain.gantois at bootlin.com (Romain Gantois)
Date: Mon, 18 Dec 2023 17:23:23 +0100
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
In-Reply-To: <20231218162326.173127-1-romain.gantois@bootlin.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
Message-ID: <20231218162326.173127-2-romain.gantois@bootlin.com>

Some stmmac cores have Checksum Offload Engines that cannot handle DSA tags
properly. These cores find the IP/TCP headers on their own and end up
computing an incorrect checksum when a DSA tag is inserted between the MAC
header and IP header.

Add an additional check on stmmac link up so that COE is deactivated
when the stmmac device is used as a DSA conduit.

Add a new dma_feature flag to allow cores to signal that their COEs can't
handle DSA tags on TX.

Fixes: 6b2c6e4a938f ("net: stmmac: propagate feature flags to vlan")
Cc: stable at vger.kernel.org
Reported-by: Richard Tresidder <rtresidd at electromag.com.au>
Closes: https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2 at electromag.com.au/
Reported-by: Romain Gantois <romain.gantois at bootlin.com>
Closes: https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495 at bootlin.com/
Signed-off-by: Romain Gantois <romain.gantois at bootlin.com>
---
 drivers/net/ethernet/stmicro/stmmac/common.h     |  1 +
 .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c  |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c    | 16 +++++++++++++++-
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index a381dee8b52d..1469d95e77a0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -406,6 +406,7 @@ struct dma_features {
 	unsigned int rx_coe_type1;
 	unsigned int rx_coe_type2;
 	unsigned int rxfifo_over_2048;
+	unsigned int dsa_breaks_tx_coe;
 	/* TX and RX number of channels */
 	unsigned int number_rx_channel;
 	unsigned int number_tx_channel;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index daf79cdbd3ec..50686cdc3320 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -264,6 +264,7 @@ static int dwmac1000_get_hw_feature(void __iomem *ioaddr,
 	dma_cap->number_tx_channel = (hw_cap & DMA_HW_FEAT_TXCHCNT) >> 22;
 	/* Alternate (enhanced) DESC mode */
 	dma_cap->enh_desc = (hw_cap & DMA_HW_FEAT_ENHDESSEL) >> 24;
+	dma_cap->dsa_breaks_tx_coe = 1;
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a9b6b383e863..733348c65e04 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -42,6 +42,7 @@
 #include <net/page_pool/helpers.h>
 #include <net/pkt_cls.h>
 #include <net/xdp_sock_drv.h>
+#include <net/dsa.h>
 #include "stmmac_ptp.h"
 #include "stmmac.h"
 #include "stmmac_xdp.h"
@@ -993,8 +994,11 @@ static void stmmac_mac_link_up(struct phylink_config *config,
 			       int speed, int duplex,
 			       bool tx_pause, bool rx_pause)
 {
-	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
+	struct net_device *ndev = to_net_dev(config->dev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	unsigned int tx_queue_cnt;
 	u32 old_ctrl, ctrl;
+	int queue;
 
 	if ((priv->plat->flags & STMMAC_FLAG_SERDES_UP_AFTER_PHY_LINKUP) &&
 	    priv->plat->serdes_powerup)
@@ -1102,6 +1106,16 @@ static void stmmac_mac_link_up(struct phylink_config *config,
 
 	if (priv->plat->flags & STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY)
 		stmmac_hwtstamp_correct_latency(priv, priv);
+
+	/* DSA tags break COEs on some cores. Disable TX checksum
+	 * offloading on those cores if the netdevice is a DSA conduit.
+	 */
+	if (priv->dma_cap.dsa_breaks_tx_coe && netdev_uses_dsa(ndev)) {
+		tx_queue_cnt = priv->plat->tx_queues_to_use;
+		for (queue = 0; queue < tx_queue_cnt; queue++)
+			priv->plat->tx_queues_cfg[queue].coe_unsupported = true;
+	}
+
 }
 
 static const struct phylink_mac_ops stmmac_phylink_mac_ops = {
-- 
2.43.0



From ahalaney at redhat.com  Mon Dec 18 08:20:03 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Mon, 18 Dec 2023 10:20:03 -0600
Subject: [PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support for
 2.5G SGMII
In-Reply-To: <20231218071118.21879-1-quic_snehshah@quicinc.com>
References: <20231218071118.21879-1-quic_snehshah@quicinc.com>
Message-ID: <4zbf5fmijxnajk7kygcjrcusf6tdnuzsqqboh23nr6f3rb3c4g@qkfofhq7jmv6>

On Mon, Dec 18, 2023 at 12:41:18PM +0530, Sneh Shah wrote:
> Serdes phy needs to operate at 2500 mode for 2.5G speed and 1000
> mode for 1G/100M/10M speed.
> Added changes to configure serdes phy and mac based on link speed.
> 
> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> ---
>  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 31 +++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index d3bf42d0fceb..b3a28dc19161 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -21,6 +21,7 @@
>  #define RGMII_IO_MACRO_CONFIG2		0x1C
>  #define RGMII_IO_MACRO_DEBUG1		0x20
>  #define EMAC_SYSTEM_LOW_POWER_DEBUG	0x28
> +#define ETHQOS_MAC_AN_CTRL		0xE0
>  
>  /* RGMII_IO_MACRO_CONFIG fields */
>  #define RGMII_CONFIG_FUNC_CLK_EN		BIT(30)
> @@ -78,6 +79,10 @@
>  #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
>  #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
>  
> +/*ETHQOS_MAC_AN_CTRL bits */
> +#define ETHQOS_MAC_AN_CTRL_RAN			BIT(9)
> +#define ETHQOS_MAC_AN_CTRL_ANE			BIT(12)
> +

nit: space please add a space before ETHQOS_MAC_AN_CTRL

>  struct ethqos_emac_por {
>  	unsigned int offset;
>  	unsigned int value;
> @@ -109,6 +114,7 @@ struct qcom_ethqos {
>  	unsigned int num_por;
>  	bool rgmii_config_loopback_en;
>  	bool has_emac_ge_3;
> +	unsigned int serdes_speed;
>  };
>  
>  static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
> @@ -600,27 +606,47 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>  
>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>  {
> -	int val;
> -
> +	int val, mac_an_value;
>  	val = readl(ethqos->mac_base + MAC_CTRL_REG);
> +	mac_an_value = readl(ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
>  
>  	switch (ethqos->speed) {
> +	case SPEED_2500:
> +		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
> +		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> +			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> +			      RGMII_IO_MACRO_CONFIG2);
> +		if (ethqos->serdes_speed != SPEED_2500)
> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> +		mac_an_value &= ~ETHQOS_MAC_AN_CTRL_ANE;
> +		break;
>  	case SPEED_1000:
>  		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
>  		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>  			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>  			      RGMII_IO_MACRO_CONFIG2);
> +		if (ethqos->serdes_speed != SPEED_1000)
> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>  		break;
>  	case SPEED_100:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL | ETHQOS_MAC_CTRL_SPEED_MODE;
> +		if (ethqos->serdes_speed != SPEED_1000)
> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>  		break;
>  	case SPEED_10:
>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> +		if (ethqos->serdes_speed != SPEED_1000)
> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>  		break;
>  	}
>  
>  	writel(val, ethqos->mac_base + MAC_CTRL_REG);
> +	writel(mac_an_value, ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
> +	ethqos->serdes_speed = ethqos->speed;

I see these bits are generic and there's some functions in stmmac_pcs.h
that muck with these...

Could you help me understand if this really should be Qualcomm specific,
or if this is something that should be considered for the more core bits
of the driver? I feel in either case we should take advantage of the
common definitions in that file if possible.

>  
>  	return val;
>  }
> @@ -789,6 +815,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
>  				     "Failed to get serdes phy\n");
>  
>  	ethqos->speed = SPEED_1000;
> +	ethqos->serdes_speed = SPEED_1000;
>  	ethqos_update_link_clk(ethqos, SPEED_1000);
>  	ethqos_set_func_clk_en(ethqos);
>  
> -- 
> 2.17.1
> 



From Bo.Ye at mediatek.com  Mon Dec 18 08:27:22 2023
From: Bo.Ye at mediatek.com (=?utf-8?B?Qm8gWWUgKOWPtuazoik=?=)
Date: Mon, 18 Dec 2023 16:27:22 +0000
Subject: [PATCH v4] thermal: fix race condition in suspend/resume
In-Reply-To: <20231218162348.69101-1-bo.ye@mediatek.com>
References: <20231218162348.69101-1-bo.ye@mediatek.com>
Message-ID: <TYZPR03MB5199B14364633FD7A09A13719490A@TYZPR03MB5199.apcprd03.prod.outlook.com>

From: "yugang.wang" <yugang.wang at mediatek.com>

  Firstly, it needs to be clarified that this issue occurs in a real- world environment. By analyzing the logs, we inferred that the issue occurred just as the system was entering suspend mode, and the user was switching the thermal policy (this action causes all thermal zones to unregister/register). In addition, we conducted degradation tests and also reproduced this issue. The specific method is to first switch the thermal policy through a command, and then immediately put the system into suspend state through another command. This method can also reproduce the issue.

Body:
  This patch fixes a race condition during system resume. It occurs
  if the system is exiting a suspend state and a user is trying to
  register/unregister a thermal zone concurrently. The root cause is
  that both actions access the `thermal_tz_list`.

In detail:

  1. At PM_POST_SUSPEND during the resume, the system reads all
  thermal
     zones in `thermal_tz_list`, then resets and updates their
     temperatures.
  2. When registering/unregistering a thermal zone, the
     `thermal_tz_list` gets manipulated.

  These two actions might occur concurrently, causing a race condition.
  To solve this issue, we introduce a mutex lock to protect
  `thermal_tz_list` from being modified while it's being read and
  updated during the resume from suspend.

  Kernel oops excerpt related to this fix:

  [ 5201.869845] [T316822] pc: [0xffffffeb7d4876f0]
  mutex_lock+0x34/0x170
  [ 5201.869856] [T316822] lr: [0xffffffeb7ca98a84]
  thermal_pm_notify+0xd4/0x26c
  [... cut for brevity ...]
  [ 5201.871061] [T316822]  suspend_prepare+0x150/0x470
  [ 5201.871067] [T316822]  enter_state+0x84/0x6f4
  [ 5201.871076] [T316822]  state_store+0x15c/0x1e8

  3.Enable thermal policy operation will unregister/register all thermal zones
     10-21 06:13:59.280   854   922 I libMtcLoader: enable thermal policy thermal_policy_09.

  4.System suspend entry time is 2023-10-20 22:13:59.242
     [ 4106.364175][T609387] binder:534_2: [name:spm&][SPM] PM: suspend entry 2023-10-20 22:13:59.242898243 UTC
     [ 4106.366185][T609387] binder:534_2: PM: [name:wakeup&]PM: Pending Wakeup Sources: NETLINK

  5. It can be proven that the absence of a switch strategy will perform
     unregister/register operations on thermal zones (android time is 2023-10-20 22:13:59.282)?
     Because the logs for other thermal zones switching are not enabled by
     default, we cannot see the logs related to other thermal zones.
     [ 4106.404167][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
     [ 4106.404215][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
     [ 4106.404225][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
     [ 4106.404504][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 0
     [ 4106.404545][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 2
     [ 4106.404566][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 1

  6. thermal_pm_notify trigger KE(android time:  2023-10-20 22:13:59.315894)
     [ 4106.437171][T209387] binder:534_2: [name:mrdump&]Kernel Offset:0x289cc80000 from 0xffffffc008000000
     [ 4106.437182][T209387] binder:534_2: [name:mrdump&]PHYS_OFFSET:0x40000000
     [ 4106.437191][T209387] binder:534_2: [name:mrdump&]pstate: 80400005(Nzcv daif +PAN -UAO)
     [ 4106.437204][T209387] binder:534_2: [name:mrdump&]pc :[0xffffffe8a6688200] mutex_lock+0x34/0x184
     [ 4106.437214][T209387] binder:534_2: [name:mrdump&]lr :[0xffffffe8a5ce66bc] thermal_pm_notify+0xd4/0x26c
     [ 4106.437220][T209387] binder:534_2: [name:mrdump&]sp :ffffffc01bab3ae0
     [ 4106.437226][T209387] binder:534_2: [name:mrdump&]x29:ffffffc01bab3af0 x28: 0000000000000001

Signed-off-by: Yugang Wang <yugang.wang at mediatek.com>
Signed-off-by: Bo Ye <bo.ye at mediatek.com>
---
Change in v2:
-remove Subject from title
-add message for reviewers' comment

Change in v3:
-remove "potential" word from title
-add more detail on issue

Change in v4:
-remove Change-Id
---
 drivers/thermal/thermal_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index 9c17d35ccbbd..73d6b820c8b5 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1520,12 +1520,14 @@ static int thermal_pm_notify(struct notifier_block *nb,
 	case PM_POST_HIBERNATION:
 	case PM_POST_RESTORE:
 	case PM_POST_SUSPEND:
+		mutex_lock(&thermal_list_lock);
 		atomic_set(&in_suspend, 0);
 		list_for_each_entry(tz, &thermal_tz_list, node) {
 			thermal_zone_device_init(tz);
 			thermal_zone_device_update(tz,
 						   THERMAL_EVENT_UNSPECIFIED);
 		}
+		mutex_unlock(&thermal_list_lock);
 		break;
 	default:
 		break;
--
2.17.0


From lpieralisi at kernel.org  Mon Dec 18 08:28:53 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Mon, 18 Dec 2023 17:28:53 +0100
Subject: [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields
In-Reply-To: <CAJZ5v0hyUqJspPbGTgTMSVHVBe=wHR6swPx-O3UcsH5dXDFpTA@mail.gmail.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOgs-00Dvko-6t@rmk-PC.armlinux.org.uk>
 <20231215162322.00007391@Huawei.com>
 <ZXyEiHLFBsoUkfNI@shell.armlinux.org.uk>
 <ZYAPhlwPUT/7dN4n@lpieralisi>
 <CAJZ5v0hyUqJspPbGTgTMSVHVBe=wHR6swPx-O3UcsH5dXDFpTA@mail.gmail.com>
Message-ID: <ZYBzRWs7v1PsF6qV@lpieralisi>

On Mon, Dec 18, 2023 at 02:14:30PM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 18, 2023 at 10:23?AM Lorenzo Pieralisi
> <lpieralisi at kernel.org> wrote:
> >
> > On Fri, Dec 15, 2023 at 04:53:28PM +0000, Russell King (Oracle) wrote:
> > > On Fri, Dec 15, 2023 at 04:23:22PM +0000, Jonathan Cameron wrote:
> > > > On Wed, 13 Dec 2023 12:50:18 +0000
> > > > Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> > > >
> > > > > From: James Morse <james.morse at arm.com>
> > > > >
> > > > > Add the new flag field to the MADT's GICC structure.
> > > > >
> > > > > 'Online Capable' indicates a disabled CPU can be enabled later. See
> > > > > ACPI specification 6.5 Tabel 5.37: GICC CPU Interface Flags.
> > > > >
> > > > > Signed-off-by: James Morse <james.morse at arm.com>
> > > > > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > > > > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > > > > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > > >
> > > > I see there is an acpica pull request including this bit but with a different name
> > > > For reference.
> > > > https://github.com/acpica/acpica/pull/914/commits/453a5f67567786522021d5f6913f561f8b3cabf6
> > > >
> > > > +CC Lorenzo who submitted that.
> > >
> > > > > +#define ACPI_MADT_GICC_CPU_CAPABLE      (1<<3)   /* 03: CPU is online capable */
> > > >
> > > > ACPI_MADT_GICC_ONLINE_CAPABLE
> > >
> > > It's somewhat disappointing, but no big deal. It's easy enough to change
> > > "irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs"
> > > to use Lorenzo's name when that patch hits - and it becomes one less
> > > patch in this patch set when Lorenzo's change eventually hits mainline.
> > >
> > > Does anyone know how long it may take for Lorenzo's change to get into
> > > mainline? Would it be by the 6.8 merge window or the following one?
> >
> > I wish I knew. I submitted ACPICA changes for the online capable bit
> > since I had to add additional flags on top (ie DMA coherent) and it
> > would not make sense to submit the latter without the former.
> >
> > I'd be great if the ACPICA headers can make it into Linux for the upcoming
> > merge window, not sure what I can do to fasttrack the process though
> > (I shall ping the maintainers).
> 
> If your upstream pull request has been merged, I can pick up Linux
> patches carrying Link: tags pointing to the upstream ACPICA commits in
> that pull request.

Thank you, I don't think it has been merged yet (and it requires
review because I am not that familiar with the ACPICA code base).

Hopefully it should be an extended kernel cycle so it might be
possible to get these headers in v6.8, if you deem that reasonable
of course once the PR is merged.

Thanks,
Lorenzo


From rafael at kernel.org  Mon Dec 18 08:30:54 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 18 Dec 2023 17:30:54 +0100
Subject: [PATCH] thermal: fix race condition in suspend/resume
In-Reply-To: <20231218162348.69101-1-bo.ye@mediatek.com>
References: <20231218162348.69101-1-bo.ye@mediatek.com>
Message-ID: <CAJZ5v0gguUpHj59AUfjo20thpZkzUUQxiQXtcqStx2ASLixNBg@mail.gmail.com>

On Mon, Dec 18, 2023 at 5:24?PM Bo Ye <bo.ye at mediatek.com> wrote:
>
> From: "yugang.wang" <yugang.wang at mediatek.com>
>
>   Firstly, it needs to be clarified that this issue occurs in a real-
> world environment. By analyzing the logs, we inferred that the
> issue occurred just as the system was entering suspend mode, and the user
> was switching the thermal policy (this action causes all thermal zones
> to unregister/register). In addition, we conducted degradation tests
> and also reproduced this issue. The specific method is to first switch
> the thermal policy through a command, and then immediately put the
> system into suspend state through another command. This method can also
> reproduce the issue.
>
> Body:
>   This patch fixes a race condition during system resume. It occurs
>   if the system is exiting a suspend state and a user is trying to
>   register/unregister a thermal zone concurrently. The root cause is
>   that both actions access the `thermal_tz_list`.
>
> In detail:
>
>   1. At PM_POST_SUSPEND during the resume, the system reads all
>   thermal
>      zones in `thermal_tz_list`, then resets and updates their
>      temperatures.
>   2. When registering/unregistering a thermal zone, the
>      `thermal_tz_list` gets manipulated.
>
>   These two actions might occur concurrently, causing a race condition.
>   To solve this issue, we introduce a mutex lock to protect
>   `thermal_tz_list` from being modified while it's being read and
>   updated during the resume from suspend.
>
>   Kernel oops excerpt related to this fix:
>
>   [ 5201.869845] [T316822] pc: [0xffffffeb7d4876f0]
>   mutex_lock+0x34/0x170
>   [ 5201.869856] [T316822] lr: [0xffffffeb7ca98a84]
>   thermal_pm_notify+0xd4/0x26c
>   [... cut for brevity ...]
>   [ 5201.871061] [T316822]  suspend_prepare+0x150/0x470
>   [ 5201.871067] [T316822]  enter_state+0x84/0x6f4
>   [ 5201.871076] [T316822]  state_store+0x15c/0x1e8
>
>   3.Enable thermal policy operation will unregister/register all thermal zones
>      10-21 06:13:59.280   854   922 I libMtcLoader: enable thermal policy thermal_policy_09.
>
>   4.System suspend entry time is 2023-10-20 22:13:59.242
>      [ 4106.364175][T609387] binder:534_2: [name:spm&][SPM] PM: suspend entry 2023-10-20 22:13:59.242898243 UTC
>      [ 4106.366185][T609387] binder:534_2: PM: [name:wakeup&]PM: Pending Wakeup Sources: NETLINK
>
>   5. It can be proven that the absence of a switch strategy will perform
>      unregister/register operations on thermal zones (android time is 2023-10-20 22:13:59.282)?
>      Because the logs for other thermal zones switching are not enabled by
>      default, we cannot see the logs related to other thermal zones.
>      [ 4106.404167][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
>      [ 4106.404215][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
>      [ 4106.404225][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
>      [ 4106.404504][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 0
>      [ 4106.404545][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 2
>      [ 4106.404566][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 1
>
>   6. thermal_pm_notify trigger KE(android time:  2023-10-20 22:13:59.315894)
>      [ 4106.437171][T209387] binder:534_2: [name:mrdump&]Kernel Offset:0x289cc80000 from 0xffffffc008000000
>      [ 4106.437182][T209387] binder:534_2: [name:mrdump&]PHYS_OFFSET:0x40000000
>      [ 4106.437191][T209387] binder:534_2: [name:mrdump&]pstate: 80400005(Nzcv daif +PAN -UAO)
>      [ 4106.437204][T209387] binder:534_2: [name:mrdump&]pc :[0xffffffe8a6688200] mutex_lock+0x34/0x184
>      [ 4106.437214][T209387] binder:534_2: [name:mrdump&]lr :[0xffffffe8a5ce66bc] thermal_pm_notify+0xd4/0x26c
>      [ 4106.437220][T209387] binder:534_2: [name:mrdump&]sp :ffffffc01bab3ae0
>      [ 4106.437226][T209387] binder:534_2: [name:mrdump&]x29:ffffffc01bab3af0 x28: 0000000000000001
>
> Signed-off-by: Yugang Wang <yugang.wang at mediatek.com>
> Signed-off-by: Bo Ye <bo.ye at mediatek.com>
> ---
>  drivers/thermal/thermal_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 9c17d35ccbbd..73d6b820c8b5 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1520,12 +1520,14 @@ static int thermal_pm_notify(struct notifier_block *nb,
>         case PM_POST_HIBERNATION:
>         case PM_POST_RESTORE:
>         case PM_POST_SUSPEND:
> +               mutex_lock(&thermal_list_lock);
>                 atomic_set(&in_suspend, 0);
>                 list_for_each_entry(tz, &thermal_tz_list, node) {
>                         thermal_zone_device_init(tz);
>                         thermal_zone_device_update(tz,
>                                                    THERMAL_EVENT_UNSPECIFIED);
>                 }
> +               mutex_unlock(&thermal_list_lock);

This isn't sufficient.

I have a patch fixing this more completely, will post it later today
if time permits.

>                 break;
>         default:
>                 break;
> --

Thanks!


From ahalaney at redhat.com  Mon Dec 18 08:31:04 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Mon, 18 Dec 2023 10:31:04 -0600
Subject: [PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support for
 2.5G SGMII
In-Reply-To: <4zbf5fmijxnajk7kygcjrcusf6tdnuzsqqboh23nr6f3rb3c4g@qkfofhq7jmv6>
References: <20231218071118.21879-1-quic_snehshah@quicinc.com>
 <4zbf5fmijxnajk7kygcjrcusf6tdnuzsqqboh23nr6f3rb3c4g@qkfofhq7jmv6>
Message-ID: <pdoedu3n7rdl6ifrfyugoa7pbjougqj4cg6mxyerhu5udf4e2h@unjqgqjt7odi>

On Mon, Dec 18, 2023 at 10:20:03AM -0600, Andrew Halaney wrote:
> On Mon, Dec 18, 2023 at 12:41:18PM +0530, Sneh Shah wrote:
> > Serdes phy needs to operate at 2500 mode for 2.5G speed and 1000
> > mode for 1G/100M/10M speed.
> > Added changes to configure serdes phy and mac based on link speed.
> > 
> > Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> > ---
> >  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 31 +++++++++++++++++--
> >  1 file changed, 29 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> > index d3bf42d0fceb..b3a28dc19161 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> > @@ -21,6 +21,7 @@
> >  #define RGMII_IO_MACRO_CONFIG2		0x1C
> >  #define RGMII_IO_MACRO_DEBUG1		0x20
> >  #define EMAC_SYSTEM_LOW_POWER_DEBUG	0x28
> > +#define ETHQOS_MAC_AN_CTRL		0xE0
> >  
> >  /* RGMII_IO_MACRO_CONFIG fields */
> >  #define RGMII_CONFIG_FUNC_CLK_EN		BIT(30)
> > @@ -78,6 +79,10 @@
> >  #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
> >  #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
> >  
> > +/*ETHQOS_MAC_AN_CTRL bits */
> > +#define ETHQOS_MAC_AN_CTRL_RAN			BIT(9)
> > +#define ETHQOS_MAC_AN_CTRL_ANE			BIT(12)
> > +
> 
> nit: space please add a space before ETHQOS_MAC_AN_CTRL
> 
> >  struct ethqos_emac_por {
> >  	unsigned int offset;
> >  	unsigned int value;
> > @@ -109,6 +114,7 @@ struct qcom_ethqos {
> >  	unsigned int num_por;
> >  	bool rgmii_config_loopback_en;
> >  	bool has_emac_ge_3;
> > +	unsigned int serdes_speed;
> >  };
> >  
> >  static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
> > @@ -600,27 +606,47 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
> >  
> >  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
> >  {
> > -	int val;
> > -
> > +	int val, mac_an_value;
> >  	val = readl(ethqos->mac_base + MAC_CTRL_REG);
> > +	mac_an_value = readl(ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
> >  
> >  	switch (ethqos->speed) {
> > +	case SPEED_2500:
> > +		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
> > +		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> > +			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> > +			      RGMII_IO_MACRO_CONFIG2);
> > +		if (ethqos->serdes_speed != SPEED_2500)
> > +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);

Also, please capture the return value here and propagate the error as
appropriate.

> > +		mac_an_value &= ~ETHQOS_MAC_AN_CTRL_ANE;
> > +		break;
> >  	case SPEED_1000:
> >  		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
> >  		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >  			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >  			      RGMII_IO_MACRO_CONFIG2);
> > +		if (ethqos->serdes_speed != SPEED_1000)
> > +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> > +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
> >  		break;
> >  	case SPEED_100:
> >  		val |= ETHQOS_MAC_CTRL_PORT_SEL | ETHQOS_MAC_CTRL_SPEED_MODE;
> > +		if (ethqos->serdes_speed != SPEED_1000)
> > +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> > +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
> >  		break;
> >  	case SPEED_10:
> >  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
> >  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> > +		if (ethqos->serdes_speed != SPEED_1000)
> > +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> > +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
> >  		break;
> >  	}
> >  
> >  	writel(val, ethqos->mac_base + MAC_CTRL_REG);
> > +	writel(mac_an_value, ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
> > +	ethqos->serdes_speed = ethqos->speed;
> 
> I see these bits are generic and there's some functions in stmmac_pcs.h
> that muck with these...
> 
> Could you help me understand if this really should be Qualcomm specific,
> or if this is something that should be considered for the more core bits
> of the driver? I feel in either case we should take advantage of the
> common definitions in that file if possible.
> 
> >  
> >  	return val;
> >  }
> > @@ -789,6 +815,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> >  				     "Failed to get serdes phy\n");
> >  
> >  	ethqos->speed = SPEED_1000;
> > +	ethqos->serdes_speed = SPEED_1000;
> >  	ethqos_update_link_clk(ethqos, SPEED_1000);
> >  	ethqos_set_func_clk_en(ethqos);
> >  
> > -- 
> > 2.17.1
> > 



From bo.ye at mediatek.com  Mon Dec 18 08:23:46 2023
From: bo.ye at mediatek.com (Bo Ye)
Date: Tue, 19 Dec 2023 00:23:46 +0800
Subject: [PATCH] thermal: fix race condition in suspend/resume
Message-ID: <20231218162348.69101-1-bo.ye@mediatek.com>

From: "yugang.wang" <yugang.wang at mediatek.com>

  Firstly, it needs to be clarified that this issue occurs in a real-
world environment. By analyzing the logs, we inferred that the
issue occurred just as the system was entering suspend mode, and the user
was switching the thermal policy (this action causes all thermal zones
to unregister/register). In addition, we conducted degradation tests
and also reproduced this issue. The specific method is to first switch
the thermal policy through a command, and then immediately put the
system into suspend state through another command. This method can also
reproduce the issue.

Body:
  This patch fixes a race condition during system resume. It occurs
  if the system is exiting a suspend state and a user is trying to
  register/unregister a thermal zone concurrently. The root cause is
  that both actions access the `thermal_tz_list`.

In detail:

  1. At PM_POST_SUSPEND during the resume, the system reads all
  thermal
     zones in `thermal_tz_list`, then resets and updates their
     temperatures.
  2. When registering/unregistering a thermal zone, the
     `thermal_tz_list` gets manipulated.

  These two actions might occur concurrently, causing a race condition.
  To solve this issue, we introduce a mutex lock to protect
  `thermal_tz_list` from being modified while it's being read and
  updated during the resume from suspend.

  Kernel oops excerpt related to this fix:

  [ 5201.869845] [T316822] pc: [0xffffffeb7d4876f0]
  mutex_lock+0x34/0x170
  [ 5201.869856] [T316822] lr: [0xffffffeb7ca98a84]
  thermal_pm_notify+0xd4/0x26c
  [... cut for brevity ...]
  [ 5201.871061] [T316822]  suspend_prepare+0x150/0x470
  [ 5201.871067] [T316822]  enter_state+0x84/0x6f4
  [ 5201.871076] [T316822]  state_store+0x15c/0x1e8

  3.Enable thermal policy operation will unregister/register all thermal zones
     10-21 06:13:59.280   854   922 I libMtcLoader: enable thermal policy thermal_policy_09.

  4.System suspend entry time is 2023-10-20 22:13:59.242
     [ 4106.364175][T609387] binder:534_2: [name:spm&][SPM] PM: suspend entry 2023-10-20 22:13:59.242898243 UTC
     [ 4106.366185][T609387] binder:534_2: PM: [name:wakeup&]PM: Pending Wakeup Sources: NETLINK

  5. It can be proven that the absence of a switch strategy will perform
     unregister/register operations on thermal zones (android time is 2023-10-20 22:13:59.282)?
     Because the logs for other thermal zones switching are not enabled by
     default, we cannot see the logs related to other thermal zones.
     [ 4106.404167][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
     [ 4106.404215][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
     [ 4106.404225][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_unbind unbinding OK
     [ 4106.404504][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 0
     [ 4106.404545][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 2
     [ 4106.404566][T600922] mtkPowerMsgHdl:[name:thermal_monitor&][Thermal/TZ/CPU]tscpu_bind binding OK, 1

  6. thermal_pm_notify trigger KE(android time:  2023-10-20 22:13:59.315894)
     [ 4106.437171][T209387] binder:534_2: [name:mrdump&]Kernel Offset:0x289cc80000 from 0xffffffc008000000
     [ 4106.437182][T209387] binder:534_2: [name:mrdump&]PHYS_OFFSET:0x40000000
     [ 4106.437191][T209387] binder:534_2: [name:mrdump&]pstate: 80400005(Nzcv daif +PAN -UAO)
     [ 4106.437204][T209387] binder:534_2: [name:mrdump&]pc :[0xffffffe8a6688200] mutex_lock+0x34/0x184
     [ 4106.437214][T209387] binder:534_2: [name:mrdump&]lr :[0xffffffe8a5ce66bc] thermal_pm_notify+0xd4/0x26c
     [ 4106.437220][T209387] binder:534_2: [name:mrdump&]sp :ffffffc01bab3ae0
     [ 4106.437226][T209387] binder:534_2: [name:mrdump&]x29:ffffffc01bab3af0 x28: 0000000000000001

Signed-off-by: Yugang Wang <yugang.wang at mediatek.com>
Signed-off-by: Bo Ye <bo.ye at mediatek.com>
---
 drivers/thermal/thermal_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 9c17d35ccbbd..73d6b820c8b5 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1520,12 +1520,14 @@ static int thermal_pm_notify(struct notifier_block *nb,
 	case PM_POST_HIBERNATION:
 	case PM_POST_RESTORE:
 	case PM_POST_SUSPEND:
+		mutex_lock(&thermal_list_lock);
 		atomic_set(&in_suspend, 0);
 		list_for_each_entry(tz, &thermal_tz_list, node) {
 			thermal_zone_device_init(tz);
 			thermal_zone_device_update(tz,
 						   THERMAL_EVENT_UNSPECIFIED);
 		}
+		mutex_unlock(&thermal_list_lock);
 		break;
 	default:
 		break;
-- 
2.17.0



From jan.kiszka at siemens.com  Mon Dec 18 08:35:56 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Mon, 18 Dec 2023 17:35:56 +0100
Subject: [PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant
Message-ID: <cover.1702917360.git.jan.kiszka@siemens.com>

This bring support for yet another IOT2050 device variant, see last
patch for details. The rest is binding and refactoring to make that
happen.

Jan

Baocheng Su (2):
  arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards
  dts: iot2050: Support IOT2050-SM variant

Jan Kiszka (1):
  arm64: dts: ti: iot2050: Factor out arduino connector bits

Su Bao Cheng (1):
  dt-bindings: arm: ti: Add binding for Siemens IOT2050 SM variant

 .../devicetree/bindings/arm/ti/k3.yaml        |   1 +
 arch/arm64/boot/dts/ti/Makefile               |   1 +
 .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
 .../dts/ti/k3-am65-iot2050-common-pg2.dtsi    |   7 +-
 .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
 .../ti/k3-am6528-iot2050-basic-common.dtsi    |   6 +-
 .../boot/dts/ti/k3-am6528-iot2050-basic.dts   |   5 +
 .../dts/ti/k3-am6548-iot2050-advanced-m2.dts  |   6 +-
 .../dts/ti/k3-am6548-iot2050-advanced-pg2.dts |   8 +-
 .../dts/ti/k3-am6548-iot2050-advanced-sm.dts  | 210 +++++
 .../dts/ti/k3-am6548-iot2050-advanced.dts     |   1 +
 11 files changed, 996 insertions(+), 770 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts

-- 
2.35.3



From jan.kiszka at siemens.com  Mon Dec 18 08:35:57 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Mon, 18 Dec 2023 17:35:57 +0100
Subject: [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 SM variant
In-Reply-To: <cover.1702917360.git.jan.kiszka@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
Message-ID: <32e9364eb0f95e94f3966a8988c37cdebfb8803f.1702917360.git.jan.kiszka@siemens.com>

From: Su Bao Cheng <baocheng.su at siemens.com>

This new variant is derived from the Advanced PG2 board, removing the
Arduino interface, and adding a new ASIC for communicating with the
PLC 1200 signal modules.

Signed-off-by: Su Bao Cheng <baocheng.su at siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
---
 Documentation/devicetree/bindings/arm/ti/k3.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 03d2a0d79fb0..2cb3f6eb8a43 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -91,6 +91,7 @@ properties:
               - siemens,iot2050-advanced
               - siemens,iot2050-advanced-m2
               - siemens,iot2050-advanced-pg2
+              - siemens,iot2050-advanced-sm
               - siemens,iot2050-basic
               - siemens,iot2050-basic-pg2
               - ti,am654-evm
-- 
2.35.3



From jan.kiszka at siemens.com  Mon Dec 18 08:35:58 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Mon, 18 Dec 2023 17:35:58 +0100
Subject: [PATCH 2/4] arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards
In-Reply-To: <cover.1702917360.git.jan.kiszka@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
Message-ID: <ebfb1c761624a6998c22808020f1462a9a20065f.1702917360.git.jan.kiszka@siemens.com>

From: Baocheng Su <baocheng.su at siemens.com>

The R5 lockstep disabling should be common for all PG2 boards, move it
from variants dts to common-pg2.dtsi.

As now the Basic PG2 consumes this twice, move Basic disabling to the
PG1 variant.

Signed-off-by: Baocheng Su <baocheng.su at siemens.com>
[Jan: avoid duplication of disabling for Basic PG2]
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
---
 arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi     | 7 ++++++-
 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi | 5 -----
 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts         | 5 +++++
 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts   | 5 -----
 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts  | 7 +------
 5 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi
index e9b57b87e42e..42adb8815f38 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) Siemens AG, 2021
+ * Copyright (c) Siemens AG, 2021-2023
  *
  * Authors:
  *   Chao Zeng <chao.zeng at siemens.com>
@@ -9,6 +9,11 @@
  * Common bits of the IOT2050 Basic and Advanced variants, PG2
  */
 
+&mcu_r5fss0 {
+	/* lock-step mode not supported on PG2 boards */
+	ti,cluster-mode = <0>;
+};
+
 &main_pmx0 {
 	cp2102n_reset_pin_default: cp2102n-reset-default-pins {
 		pinctrl-single,pins = <
diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
index 5ab434c02ab6..2300abe69e94 100644
--- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
@@ -54,8 +54,3 @@ &main_uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_uart0_pins_default>;
 };
-
-&mcu_r5fss0 {
-	/* lock-step mode not supported on Basic boards */
-	ti,cluster-mode = <0>;
-};
diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
index 87928ff28214..be9c8db4c43a 100644
--- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
@@ -22,3 +22,8 @@ / {
 	compatible = "siemens,iot2050-basic", "ti,am654";
 	model = "SIMATIC IOT2050 Basic";
 };
+
+&mcu_r5fss0 {
+	/* lock-step mode not supported on this board */
+	ti,cluster-mode = <0>;
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
index bd6f2e696e94..1e5d4d98b69b 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
@@ -21,11 +21,6 @@ / {
 	model = "SIMATIC IOT2050 Advanced M2";
 };
 
-&mcu_r5fss0 {
-	/* lock-step mode not supported on this board */
-	ti,cluster-mode = <0>;
-};
-
 &main_pmx0 {
 	main_bkey_pcie_reset: main-bkey-pcie-reset-default-pins {
 		pinctrl-single,pins = <
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
index f00dc86d01b9..a8ce8c891894 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) Siemens AG, 2018-2021
+ * Copyright (c) Siemens AG, 2018-2023
  *
  * Authors:
  *   Le Jin <le.jin at siemens.com>
@@ -22,8 +22,3 @@ / {
 	compatible = "siemens,iot2050-advanced-pg2", "ti,am654";
 	model = "SIMATIC IOT2050 Advanced PG2";
 };
-
-&mcu_r5fss0 {
-	/* lock-step mode not supported on this board */
-	ti,cluster-mode = <0>;
-};
-- 
2.35.3



From jan.kiszka at siemens.com  Mon Dec 18 08:36:00 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Mon, 18 Dec 2023 17:36:00 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <cover.1702917360.git.jan.kiszka@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
Message-ID: <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>

From: Baocheng Su <baocheng.su at siemens.com>

Main differences between the new variant and Advanced PG2:

1. Arduino interface is removed. Instead, an new ASIC is added for
   communicating with PLC 1200 signal modules.
2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
   avaiable.
3. DP interface is tailored down. Instead, to communicate with the
   PLC 1200 signal modules, a USB 3.0 type B connector is added but the
   signal is not USB.
4. DDR size is increased to 4 GB.
5. Two sensors are added, one tilt sensor and one light sensor.

The light sensor it not yet added to the DT at this stage as it depends
on to-be-added bindings.

Co-developed-by: Chao Zeng <chao.zeng at siemens.com>
Signed-off-by: Chao Zeng <chao.zeng at siemens.com>
Co-developed-by: Li Hua Qian <huaqian.li at siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li at siemens.com>
Signed-off-by: Baocheng Su <baocheng.su at siemens.com>
[Jan: rebase over arduino refactoring, split-out light sensor]
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
---
 arch/arm64/boot/dts/ti/Makefile               |   1 +
 .../dts/ti/k3-am6548-iot2050-advanced-sm.dts  | 210 ++++++++++++++++++
 2 files changed, 211 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 77a347f9f47d..9b15eaad284c 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-m2.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-pg2.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-sm.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am654-gp-evm.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am654-evm.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
new file mode 100644
index 000000000000..ab3eef683890
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2023
+ *
+ * Authors:
+ *   Baocheng Su <baocheng.su at siemens.com>
+ *   Chao Zeng <chao.zeng at siemens.com>
+ *   Huaqian Li <huaqian.li at siemens.com>
+ *
+ * AM6548-based (quad-core) IOT2050 SM variant, Product Generation 2
+ * 4 GB RAM, 16 GB eMMC, USB-serial converter on connector X30
+ *
+ * Product homepage:
+ * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
+ */
+
+/dts-v1/;
+
+#include "k3-am6548-iot2050-advanced-common.dtsi"
+#include "k3-am65-iot2050-common-pg2.dtsi"
+
+/ {
+	compatible = "siemens,iot2050-advanced-sm", "ti,am654";
+	model = "SIMATIC IOT2050 Advanced SM";
+
+	memory at 80000000 {
+		device_type = "memory";
+		/* 4G RAM */
+		reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+		      <0x00000008 0x80000000 0x00000000 0x80000000>;
+	};
+
+	aliases {
+		spi1 = &main_spi0;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&leds_pins_default>, <&user1_led_pins>;
+
+		user-led1-red {
+			gpios = <&wkup_gpio0 52 GPIO_ACTIVE_HIGH>;
+		};
+
+		user-led1-green {
+			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+&main_pmx0 {
+	main_pcie_enable_pins_default: main-pcie-enable-default-pins {
+		pinctrl-single,pins = <
+			AM65X_IOPAD(0x01d8, PIN_OUTPUT, 7)  /* (AH12) GPIO1_22 */
+		>;
+	};
+
+	main_spi0_pins: main-spi0-default-pins  {
+		pinctrl-single,pins = <
+			AM65X_IOPAD(0x01c4, PIN_INPUT, 0) /* (AH13) SPI0_CLK */
+			AM65X_IOPAD(0x01c8, PIN_INPUT, 0) /* (AE13) SPI0_D0 */
+			AM65X_IOPAD(0x01cc, PIN_INPUT, 0) /* (AD13) SPI0_D1 */
+			AM65X_IOPAD(0x01bc, PIN_OUTPUT, 0) /* (AG13) SPI0_CS0 */
+		>;
+	};
+};
+
+&main_pmx1 {
+	asic_spi_mux_ctrl_pin: asic-spi-mux-ctrl-default-pins {
+		pinctrl-single,pins = <
+			AM65X_IOPAD(0x0010, PIN_OUTPUT, 7)  /* (D21) GPIO1_86 */
+		>;
+	};
+};
+
+&wkup_pmx0 {
+	user1_led_pins: user1-led-default-pins {
+		pinctrl-single,pins = <
+			/* (AB1) WKUP_UART0_RXD:WKUP_GPIO0_52, as USER 1 led red */
+			AM65X_WKUP_IOPAD(0x00a0, PIN_OUTPUT, 7)
+			/* (AB5) WKUP_UART0_TXD:WKUP_GPIO0_53, as USER 1 led green */
+			AM65X_WKUP_IOPAD(0x00a4, PIN_OUTPUT, 7)
+		>;
+	};
+
+	soc_asic_pins: soc-asic-default-pins {
+		pinctrl-single,pins = <
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 7)  /* (P4) WKUP_GPIO0_29 */
+			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)  /* (P5) WKUP_GPIO0_30 */
+			AM65X_WKUP_IOPAD(0x004c, PIN_INPUT, 7)  /* (P1) WKUP_GPIO0_31 */
+		>;
+	};
+};
+
+&main_gpio0 {
+	gpio-line-names = "main_gpio0-base";
+};
+
+&main_gpio1 {
+	pinctrl-names = "default";
+	pinctrl-0 =
+		<&cp2102n_reset_pin_default>,
+		<&main_pcie_enable_pins_default>,
+		<&asic_spi_mux_ctrl_pin>;
+	gpio-line-names =
+		/* 0..9 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 10..19 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 20..29 */
+		"", "", "", "", "CP2102N-RESET", "", "", "", "", "",
+		/* 30..39 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 40..49 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 50..59 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 60..69 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 70..79 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 80..86 */
+		"", "", "", "", "", "", "ASIC-spi-mux-ctrl";
+};
+
+&wkup_gpio0 {
+	pinctrl-names = "default";
+	pinctrl-0 =
+		<&push_button_pins_default>,
+		<&db9_com_mode_pins_default>,
+		<&soc_asic_pins>;
+	gpio-line-names =
+		/* 0..9 */
+		"wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0",
+		"UART0-enable", "UART0-terminate", "", "WIFI-disable",
+		/* 10..19 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 20..29 */
+		"", "", "", "", "", "USER-button", "", "", "","ASIC-gpio-0",
+		/* 30..31 */
+		"ASIC-gpio-1", "ASIC-gpio-2";
+};
+
+&main_spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&main_spi0_pins>;
+
+	#address-cells = <1>;
+	#size-cells= <0>;
+};
+
+&mcu_spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcu_spi0_pins_default>;
+};
+
+&main_i2c3 {
+	accelerometer: lsm6dso at 6a {
+		compatible = "st,lsm6dso";
+		reg = <0x6a>;
+	};
+
+	/delete-node/ edp-bridge at f;
+};
+
+&dss {
+	status = "disabled";
+};
+
+&dss_ports {
+	/delete-node/ port at 1;
+};
+
+&serdes0 {
+	assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>;
+	assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>;
+};
+
+&serdes1 {
+	status = "disabled";
+};
+
+&pcie0_rc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&minipcie_pins_default>;
+
+	num-lanes = <1>;
+	phys = <&serdes0 PHY_TYPE_PCIE 1>;
+	phy-names = "pcie-phy0";
+	reset-gpios = <&wkup_gpio0 27 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+};
+
+&pcie1_rc {
+	status = "disabled";
+};
+
+&dwc3_0 {
+	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
+				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
+	/delete-property/ phys;
+	/delete-property/ phy-names;
+};
+
+&usb0 {
+	maximum-speed = "high-speed";
+	/delete-property/ snps,dis-u1-entry-quirk;
+	/delete-property/ snps,dis-u2-entry-quirk;
+};
-- 
2.35.3



From jan.kiszka at siemens.com  Mon Dec 18 08:35:59 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Mon, 18 Dec 2023 17:35:59 +0100
Subject: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits
In-Reply-To: <cover.1702917360.git.jan.kiszka@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
Message-ID: <202d324ab0aa3728c8f846d31bedcbaba14aebdd.1702917360.git.jan.kiszka@siemens.com>

From: Jan Kiszka <jan.kiszka at siemens.com>

A new variant is to be added which will not have a arduino connector
like the existing ones. Factor out all bits that are specific to this
connector.

The split is not perfect because wkup_gpio0 is defined based on what is
common to all variants having the connector, thus containing also
connector-unrelated information. But this is still cleaner than
replicating this node into all 4 variants.

Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
---
 .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
 .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
 .../ti/k3-am6528-iot2050-basic-common.dtsi    |   1 +
 .../dts/ti/k3-am6548-iot2050-advanced-m2.dts  |   1 +
 .../dts/ti/k3-am6548-iot2050-advanced-pg2.dts |   1 +
 .../dts/ti/k3-am6548-iot2050-advanced.dts     |   1 +
 6 files changed, 772 insertions(+), 753 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi

diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi
new file mode 100644
index 000000000000..cd86f412b837
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi
@@ -0,0 +1,768 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2023
+ *
+ * Authors:
+ *   Le Jin <le.jin at siemens.com>
+ *   Jan Kiszka <jan.kiszka at siemens.com>
+ *
+ * Common bits for IOT2050 variants with Arduino connector
+ */
+
+&wkup_pmx0 {
+	pinctrl-names =
+		"default",
+		"d0-uart0-rxd",  "d0-gpio",  "d0-gpio-pullup",  "d0-gpio-pulldown",
+		"d1-uart0-txd",  "d1-gpio",  "d1-gpio-pullup",  "d1-gpio-pulldown",
+		"d2-uart0-ctsn", "d2-gpio",  "d2-gpio-pullup",  "d2-gpio-pulldown",
+		"d3-uart0-rtsn", "d3-gpio",  "d3-gpio-pullup",  "d3-gpio-pulldown",
+		"d10-spi0-cs0",  "d10-gpio", "d10-gpio-pullup", "d10-gpio-pulldown",
+		"d11-spi0-d0",   "d11-gpio", "d11-gpio-pullup", "d11-gpio-pulldown",
+		"d12-spi0-d1",   "d12-gpio", "d12-gpio-pullup", "d12-gpio-pulldown",
+		"d13-spi0-clk",  "d13-gpio", "d13-gpio-pullup", "d13-gpio-pulldown",
+		"a0-gpio", "a0-gpio-pullup", "a0-gpio-pulldown",
+		"a1-gpio", "a1-gpio-pullup", "a1-gpio-pulldown",
+		"a2-gpio", "a2-gpio-pullup", "a2-gpio-pulldown",
+		"a3-gpio", "a3-gpio-pullup", "a3-gpio-pulldown",
+		"a4-gpio", "a4-gpio-pullup", "a4-gpio-pulldown",
+		"a5-gpio", "a5-gpio-pullup", "a5-gpio-pulldown";
+
+	pinctrl-0 = <&d0_uart0_rxd>;
+	pinctrl-1 = <&d0_uart0_rxd>;
+	pinctrl-2 = <&d0_gpio>;
+	pinctrl-3 = <&d0_gpio_pullup>;
+	pinctrl-4 = <&d0_gpio_pulldown>;
+	pinctrl-5 = <&d1_uart0_txd>;
+	pinctrl-6 = <&d1_gpio>;
+	pinctrl-7 = <&d1_gpio_pullup>;
+	pinctrl-8 = <&d1_gpio_pulldown>;
+	pinctrl-9 = <&d2_uart0_ctsn>;
+	pinctrl-10 = <&d2_gpio>;
+	pinctrl-11 = <&d2_gpio_pullup>;
+	pinctrl-12 = <&d2_gpio_pulldown>;
+	pinctrl-13 = <&d3_uart0_rtsn>;
+	pinctrl-14 = <&d3_gpio>;
+	pinctrl-15 = <&d3_gpio_pullup>;
+	pinctrl-16 = <&d3_gpio_pulldown>;
+	pinctrl-17 = <&d10_spi0_cs0>;
+	pinctrl-18 = <&d10_gpio>;
+	pinctrl-19 = <&d10_gpio_pullup>;
+	pinctrl-20 = <&d10_gpio_pulldown>;
+	pinctrl-21 = <&d11_spi0_d0>;
+	pinctrl-22 = <&d11_gpio>;
+	pinctrl-23 = <&d11_gpio_pullup>;
+	pinctrl-24 = <&d11_gpio_pulldown>;
+	pinctrl-25 = <&d12_spi0_d1>;
+	pinctrl-26 = <&d12_gpio>;
+	pinctrl-27 = <&d12_gpio_pullup>;
+	pinctrl-28 = <&d12_gpio_pulldown>;
+	pinctrl-29 = <&d13_spi0_clk>;
+	pinctrl-30 = <&d13_gpio>;
+	pinctrl-31 = <&d13_gpio_pullup>;
+	pinctrl-32 = <&d13_gpio_pulldown>;
+	pinctrl-33 = <&a0_gpio>;
+	pinctrl-34 = <&a0_gpio_pullup>;
+	pinctrl-35 = <&a0_gpio_pulldown>;
+	pinctrl-36 = <&a1_gpio>;
+	pinctrl-37 = <&a1_gpio_pullup>;
+	pinctrl-38 = <&a1_gpio_pulldown>;
+	pinctrl-39 = <&a2_gpio>;
+	pinctrl-40 = <&a2_gpio_pullup>;
+	pinctrl-41 = <&a2_gpio_pulldown>;
+	pinctrl-42 = <&a3_gpio>;
+	pinctrl-43 = <&a3_gpio_pullup>;
+	pinctrl-44 = <&a3_gpio_pulldown>;
+	pinctrl-45 = <&a4_gpio>;
+	pinctrl-46 = <&a4_gpio_pullup>;
+	pinctrl-47 = <&a4_gpio_pulldown>;
+	pinctrl-48 = <&a5_gpio>;
+	pinctrl-49 = <&a5_gpio_pullup>;
+	pinctrl-50 = <&a5_gpio_pulldown>;
+
+	d0_uart0_rxd: d0-uart0-rxd-pins {
+		pinctrl-single,pins = <
+			/* (P4) MCU_UART0_RXD */
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4)
+		>;
+	};
+
+	d0_gpio: d0-gpio-pins {
+		pinctrl-single,pins = <
+			/* (P4) WKUP_GPIO0_29 */
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 7)
+		>;
+	};
+
+	d0_gpio_pullup: d0-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (P4) WKUP_GPIO0_29 */
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d0_gpio_pulldown: d0-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (P4) WKUP_GPIO0_29 */
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d1_uart0_txd: d1-uart0-txd-pins {
+		pinctrl-single,pins = <
+			/* (P5) MCU_UART0_TXD */
+			AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4)
+		>;
+	};
+
+	d1_gpio: d1-gpio-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_30 */
+			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)
+		>;
+	};
+
+	d1_gpio_pullup: d1-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_30 */
+			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)
+		>;
+	};
+
+	d1_gpio_pulldown: d1-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_30 */
+			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d2_uart0_ctsn: d2-uart0-ctsn-pins {
+		pinctrl-single,pins = <
+			/* (P1) MCU_UART0_CTSn */
+			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 4)
+		>;
+	};
+
+	d2_gpio: d2-gpio-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_31 */
+			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7)
+		>;
+	};
+
+	d2_gpio_pullup: d2-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_31 */
+			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7)
+		>;
+	};
+
+	d2_gpio_pulldown: d2-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_31 */
+			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d3_uart0_rtsn: d3-uart0-rtsn-pins {
+		pinctrl-single,pins = <
+			/* (N3) MCU_UART0_RTSn */
+			AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 4)
+		>;
+	};
+
+	d3_gpio: d3-gpio-pins {
+		pinctrl-single,pins = <
+			/* (N3) WKUP_GPIO0_33 */
+			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7)
+		>;
+	};
+
+	d3_gpio_pullup: d3-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (N3) WKUP_GPIO0_33 */
+			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7)
+		>;
+	};
+
+	d3_gpio_pulldown: d3-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (N3) WKUP_GPIO0_33 */
+			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d10_spi0_cs0: d10-spi0-cs0-pins {
+		pinctrl-single,pins = <
+			/* (Y4) MCU_SPI0_CS0 */
+			AM65X_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0)
+		>;
+	};
+
+	d10_gpio: d10-gpio-pins {
+		pinctrl-single,pins = <
+			/* (Y4) WKUP_GPIO0_51 */
+			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7)
+		>;
+	};
+
+	d10_gpio_pullup: d10-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (Y4) WKUP_GPIO0_51 */
+			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7)
+		>;
+	};
+
+	d10_gpio_pulldown: d10-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (Y4) WKUP_GPIO0_51 */
+			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d11_spi0_d0: d11-spi0-d0-pins {
+		pinctrl-single,pins = <
+			/* (Y3) MCU_SPI0_D0 */
+			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 0)
+		>;
+	};
+
+	d11_gpio: d11-gpio-pins {
+		pinctrl-single,pins = <
+			/* (Y3) WKUP_GPIO0_49 */
+			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7)
+		>;
+	};
+
+	d11_gpio_pullup: d11-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (Y3) WKUP_GPIO0_49 */
+			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7)
+		>;
+	};
+
+	d11_gpio_pulldown: d11-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (Y3) WKUP_GPIO0_49 */
+			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d12_spi0_d1: d12-spi0-d1-pins {
+		pinctrl-single,pins = <
+			/* (Y2) MCU_SPI0_D1 */
+			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 0)
+		>;
+	};
+
+	d12_gpio: d12-gpio-pins {
+		pinctrl-single,pins = <
+			/* (Y2) WKUP_GPIO0_50 */
+			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7)
+		>;
+	};
+
+	d12_gpio_pullup: d12-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (Y2) WKUP_GPIO0_50 */
+			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7)
+		>;
+	};
+
+	d12_gpio_pulldown: d12-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (Y2) WKUP_GPIO0_50 */
+			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d13_spi0_clk: d13-spi0-clk-pins {
+		pinctrl-single,pins = <
+			/* (Y1) MCU_SPI0_CLK */
+			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 0)
+		>;
+	};
+
+	d13_gpio: d13-gpio-pins {
+		pinctrl-single,pins = <
+			/* (Y1) WKUP_GPIO0_48 */
+			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7)
+		>;
+	};
+
+	d13_gpio_pullup: d13-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (Y1) WKUP_GPIO0_48 */
+			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7)
+		>;
+	};
+
+	d13_gpio_pulldown: d13-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (Y1) WKUP_GPIO0_48 */
+			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a0_gpio: a0-gpio-pins {
+		pinctrl-single,pins = <
+			/* (L6) WKUP_GPIO0_45 */
+			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7)
+		>;
+	};
+
+	a0_gpio_pullup: a0-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (L6) WKUP_GPIO0_45 */
+			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7)
+		>;
+	};
+
+	a0_gpio_pulldown: a0-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (L6) WKUP_GPIO0_45 */
+			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a1_gpio: a1-gpio-pins {
+		pinctrl-single,pins = <
+			/* (M6) WKUP_GPIO0_44 */
+			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7)
+		>;
+	};
+
+	a1_gpio_pullup: a1-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (M6) WKUP_GPIO0_44 */
+			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7)
+		>;
+	};
+
+	a1_gpio_pulldown: a1-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (M6) WKUP_GPIO0_44 */
+			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a2_gpio: a2-gpio-pins {
+		pinctrl-single,pins = <
+			/* (L5) WKUP_GPIO0_43 */
+			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7)
+		>;
+	};
+
+	a2_gpio_pullup: a2-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (L5) WKUP_GPIO0_43 */
+			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7)
+		>;
+	};
+
+	a2_gpio_pulldown: a2-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (L5) WKUP_GPIO0_43 */
+			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a3_gpio: a3-gpio-pins {
+		pinctrl-single,pins = <
+			/* (M5) WKUP_GPIO0_39 */
+			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7)
+		>;
+	};
+
+	a3_gpio_pullup: a3-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (M5) WKUP_GPIO0_39 */
+			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7)
+		>;
+	};
+
+	a3_gpio_pulldown: a3-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (M5) WKUP_GPIO0_39 */
+			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a4_gpio: a4-gpio-pins {
+		pinctrl-single,pins = <
+			/* (L2) WKUP_GPIO0_42 */
+			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7)
+		>;
+	};
+
+	a4_gpio_pullup: a4-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (L2) WKUP_GPIO0_42 */
+			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7)
+		>;
+	};
+
+	a4_gpio_pulldown: a4-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (L2) WKUP_GPIO0_42 */
+			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a5_gpio: a5-gpio-pins {
+		pinctrl-single,pins = <
+			/* (N5) WKUP_GPIO0_35 */
+			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT, 7)
+		>;
+	};
+
+	a5_gpio_pullup: a5-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (N5) WKUP_GPIO0_35 */
+			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	a5_gpio_pulldown: a5-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (N5) WKUP_GPIO0_35 */
+			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+		pinctrl-single,pins = <
+			/* (AC7) WKUP_I2C0_SCL */
+			AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT,  0)
+			/* (AD6) WKUP_I2C0_SDA */
+			AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT,  0)
+		>;
+	};
+
+	arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-default-pins {
+		pinctrl-single,pins = <
+			/* (R2) WKUP_GPIO0_21 */
+			AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7)
+		>;
+	};
+
+	arduino_io_oe_pins_default: arduino-io-oe-default-pins {
+		pinctrl-single,pins = <
+			/* (N4) WKUP_GPIO0_34 */
+			AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 7)
+			/* (M2) WKUP_GPIO0_36 */
+			AM65X_WKUP_IOPAD(0x0060, PIN_OUTPUT, 7)
+			/* (M3) WKUP_GPIO0_37 */
+			AM65X_WKUP_IOPAD(0x0064, PIN_OUTPUT, 7)
+			/* (M4) WKUP_GPIO0_38 */
+			AM65X_WKUP_IOPAD(0x0068, PIN_OUTPUT, 7)
+			/* (M1) WKUP_GPIO0_41 */
+			AM65X_WKUP_IOPAD(0x0074, PIN_OUTPUT, 7)
+		>;
+	};
+};
+
+&main_pmx0 {
+	pinctrl-names =
+		"default",
+		"d4-ehrpwm0-a", "d4-gpio", "d4-gpio-pullup", "d4-gpio-pulldown",
+		"d5-ehrpwm1-a", "d5-gpio", "d5-gpio-pullup", "d5-gpio-pulldown",
+		"d6-ehrpwm2-a", "d6-gpio", "d6-gpio-pullup", "d6-gpio-pulldown",
+		"d7-ehrpwm3-a", "d7-gpio", "d7-gpio-pullup", "d7-gpio-pulldown",
+		"d8-ehrpwm4-a", "d8-gpio", "d8-gpio-pullup", "d8-gpio-pulldown",
+		"d9-ehrpwm5-a", "d9-gpio", "d9-gpio-pullup", "d9-gpio-pulldown";
+
+	pinctrl-0 = <&d4_ehrpwm0_a>;
+	pinctrl-1 = <&d4_ehrpwm0_a>;
+	pinctrl-2 = <&d4_gpio>;
+	pinctrl-3 = <&d4_gpio_pullup>;
+	pinctrl-4 = <&d4_gpio_pulldown>;
+
+	pinctrl-5 = <&d5_ehrpwm1_a>;
+	pinctrl-6 = <&d5_gpio>;
+	pinctrl-7 = <&d5_gpio_pullup>;
+	pinctrl-8 = <&d5_gpio_pulldown>;
+
+	pinctrl-9 = <&d6_ehrpwm2_a>;
+	pinctrl-10 = <&d6_gpio>;
+	pinctrl-11 = <&d6_gpio_pullup>;
+	pinctrl-12 = <&d6_gpio_pulldown>;
+
+	pinctrl-13 = <&d7_ehrpwm3_a>;
+	pinctrl-14 = <&d7_gpio>;
+	pinctrl-15 = <&d7_gpio_pullup>;
+	pinctrl-16 = <&d7_gpio_pulldown>;
+
+	pinctrl-17 = <&d8_ehrpwm4_a>;
+	pinctrl-18 = <&d8_gpio>;
+	pinctrl-19 = <&d8_gpio_pullup>;
+	pinctrl-20 = <&d8_gpio_pulldown>;
+
+	pinctrl-21 = <&d9_ehrpwm5_a>;
+	pinctrl-22 = <&d9_gpio>;
+	pinctrl-23 = <&d9_gpio_pullup>;
+	pinctrl-24 = <&d9_gpio_pulldown>;
+
+	d4_ehrpwm0_a: d4-ehrpwm0-a-pins {
+		pinctrl-single,pins = <
+			/* (AG18) EHRPWM0_A */
+			AM65X_IOPAD(0x0084, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d4_gpio: d4-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AG18) GPIO0_33 */
+			AM65X_IOPAD(0x0084, PIN_INPUT, 7)
+		>;
+	};
+
+	d4_gpio_pullup: d4-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AG18) GPIO0_33 */
+			AM65X_IOPAD(0x0084, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d4_gpio_pulldown: d4-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AG18) GPIO0_33 */
+			AM65X_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d5_ehrpwm1_a: d5-ehrpwm1-a-pins {
+		pinctrl-single,pins = <
+			/* (AF17) EHRPWM1_A */
+			AM65X_IOPAD(0x008C, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d5_gpio: d5-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AF17) GPIO0_35 */
+			AM65X_IOPAD(0x008C, PIN_INPUT, 7)
+		>;
+	};
+
+	d5_gpio_pullup: d5-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AF17) GPIO0_35 */
+			AM65X_IOPAD(0x008C, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d5_gpio_pulldown: d5-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AF17) GPIO0_35 */
+			AM65X_IOPAD(0x008C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d6_ehrpwm2_a: d6-ehrpwm2-a-pins {
+		pinctrl-single,pins = <
+			/* (AH16) EHRPWM2_A */
+			AM65X_IOPAD(0x0098, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d6_gpio: d6-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AH16) GPIO0_38 */
+			AM65X_IOPAD(0x0098, PIN_INPUT, 7)
+		>;
+	};
+
+	d6_gpio_pullup: d6-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AH16) GPIO0_38 */
+			AM65X_IOPAD(0x0098, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d6_gpio_pulldown: d6-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AH16) GPIO0_38 */
+			AM65X_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d7_ehrpwm3_a: d7-ehrpwm3-a-pins {
+		pinctrl-single,pins = <
+			/* (AH15) EHRPWM3_A */
+			AM65X_IOPAD(0x00AC, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d7_gpio: d7-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AH15) GPIO0_43 */
+			AM65X_IOPAD(0x00AC, PIN_INPUT, 7)
+		>;
+	};
+
+	d7_gpio_pullup: d7-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AH15) GPIO0_43 */
+			AM65X_IOPAD(0x00AC, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d7_gpio_pulldown: d7-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AH15) GPIO0_43 */
+			AM65X_IOPAD(0x00AC, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d8_ehrpwm4_a: d8-ehrpwm4-a-pins {
+		pinctrl-single,pins = <
+			/* (AG15) EHRPWM4_A */
+			AM65X_IOPAD(0x00C0, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d8_gpio: d8-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AG15) GPIO0_48 */
+			AM65X_IOPAD(0x00C0, PIN_INPUT, 7)
+		>;
+	};
+
+	d8_gpio_pullup: d8-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AG15) GPIO0_48 */
+			AM65X_IOPAD(0x00C0, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d8_gpio_pulldown: d8-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AG15) GPIO0_48 */
+			AM65X_IOPAD(0x00C0, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d9_ehrpwm5_a: d9-ehrpwm5-a-pins {
+		pinctrl-single,pins = <
+			/* (AD15) EHRPWM5_A */
+			AM65X_IOPAD(0x00CC, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d9_gpio: d9-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AD15) GPIO0_51 */
+			AM65X_IOPAD(0x00CC, PIN_INPUT, 7)
+		>;
+	};
+
+	d9_gpio_pullup: d9-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AD15) GPIO0_51 */
+			AM65X_IOPAD(0x00CC, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d9_gpio_pulldown: d9-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AD15) GPIO0_51 */
+			AM65X_IOPAD(0x00CC, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+};
+
+&main_gpio0 {
+	gpio-line-names =
+		"main_gpio0-base", "", "", "", "", "", "", "", "", "",
+		"", "", "", "", "", "", "", "", "", "",
+		"", "", "", "", "", "", "", "", "", "",
+		"", "", "", "IO4", "", "IO5", "", "", "IO6", "",
+		"", "", "", "IO7", "", "", "", "", "IO8", "",
+		"", "IO9";
+};
+
+&wkup_gpio0 {
+	pinctrl-names = "default";
+	pinctrl-0 =
+		<&arduino_i2c_aio_switch_pins_default>,
+		<&arduino_io_oe_pins_default>,
+		<&push_button_pins_default>,
+		<&db9_com_mode_pins_default>;
+	gpio-line-names =
+		/* 0..9 */
+		"wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0",
+		"UART0-enable", "UART0-terminate", "", "WIFI-disable",
+		/* 10..19 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 20..29 */
+		"", "A4A5-I2C-mux", "", "", "", "USER-button", "", "", "","IO0",
+		/* 30..39 */
+		"IO1", "IO2", "", "IO3", "IO17-direction", "A5",
+		"IO16-direction", "IO15-direction", "IO14-direction", "A3",
+		/* 40..49 */
+		"", "IO18-direction", "A4", "A2", "A1", "A0", "", "", "IO13",
+		"IO11",
+		/* 50..51 */
+		"IO12", "IO10";
+};
+
+&wkup_i2c0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&wkup_i2c0_pins_default>;
+	clock-frequency = <400000>;
+};
+
+&mcu_i2c0 {
+	/* D4200 */
+	pcal9535_1: gpio at 20 {
+		compatible = "nxp,pcal9535";
+		reg = <0x20>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-line-names =
+			"A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull",
+			"A5-pull", "", "",
+			"IO14-enable", "IO15-enable", "IO16-enable",
+			"IO17-enable", "IO18-enable", "IO19-enable";
+	};
+
+	/* D4201 */
+	pcal9535_2: gpio at 21 {
+		compatible = "nxp,pcal9535";
+		reg = <0x21>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-line-names =
+			"IO0-direction", "IO1-direction", "IO2-direction",
+			"IO3-direction", "IO4-direction", "IO5-direction",
+			"IO6-direction", "IO7-direction",
+			"IO8-direction", "IO9-direction", "IO10-direction",
+			"IO11-direction", "IO12-direction", "IO13-direction",
+			"IO19-direction";
+	};
+
+	/* D4202 */
+	pcal9535_3: gpio at 25 {
+		compatible = "nxp,pcal9535";
+		reg = <0x25>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-line-names =
+			"IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull",
+			"IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull",
+			"IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull",
+			"IO12-pull", "IO13-pull";
+	};
+};
+
+&mcu_uart0 {
+	status = "okay";
+};
+
+&tscadc1 {
+	status = "okay";
+	adc {
+		ti,adc-channels = <0 1 2 3 4 5>;
+	};
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
index ab1dffa5c1c6..402afa4bc1b6 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -187,434 +187,6 @@ icssg0_emac1: port at 1 {
 };
 
 &wkup_pmx0 {
-	pinctrl-names =
-		"default",
-		"d0-uart0-rxd",  "d0-gpio",  "d0-gpio-pullup",  "d0-gpio-pulldown",
-		"d1-uart0-txd",  "d1-gpio",  "d1-gpio-pullup",  "d1-gpio-pulldown",
-		"d2-uart0-ctsn", "d2-gpio",  "d2-gpio-pullup",  "d2-gpio-pulldown",
-		"d3-uart0-rtsn", "d3-gpio",  "d3-gpio-pullup",  "d3-gpio-pulldown",
-		"d10-spi0-cs0",  "d10-gpio", "d10-gpio-pullup", "d10-gpio-pulldown",
-		"d11-spi0-d0",   "d11-gpio", "d11-gpio-pullup", "d11-gpio-pulldown",
-		"d12-spi0-d1",   "d12-gpio", "d12-gpio-pullup", "d12-gpio-pulldown",
-		"d13-spi0-clk",  "d13-gpio", "d13-gpio-pullup", "d13-gpio-pulldown",
-		"a0-gpio", "a0-gpio-pullup", "a0-gpio-pulldown",
-		"a1-gpio", "a1-gpio-pullup", "a1-gpio-pulldown",
-		"a2-gpio", "a2-gpio-pullup", "a2-gpio-pulldown",
-		"a3-gpio", "a3-gpio-pullup", "a3-gpio-pulldown",
-		"a4-gpio", "a4-gpio-pullup", "a4-gpio-pulldown",
-		"a5-gpio", "a5-gpio-pullup", "a5-gpio-pulldown";
-
-	pinctrl-0 = <&d0_uart0_rxd>;
-	pinctrl-1 = <&d0_uart0_rxd>;
-	pinctrl-2 = <&d0_gpio>;
-	pinctrl-3 = <&d0_gpio_pullup>;
-	pinctrl-4 = <&d0_gpio_pulldown>;
-	pinctrl-5 = <&d1_uart0_txd>;
-	pinctrl-6 = <&d1_gpio>;
-	pinctrl-7 = <&d1_gpio_pullup>;
-	pinctrl-8 = <&d1_gpio_pulldown>;
-	pinctrl-9 = <&d2_uart0_ctsn>;
-	pinctrl-10 = <&d2_gpio>;
-	pinctrl-11 = <&d2_gpio_pullup>;
-	pinctrl-12 = <&d2_gpio_pulldown>;
-	pinctrl-13 = <&d3_uart0_rtsn>;
-	pinctrl-14 = <&d3_gpio>;
-	pinctrl-15 = <&d3_gpio_pullup>;
-	pinctrl-16 = <&d3_gpio_pulldown>;
-	pinctrl-17 = <&d10_spi0_cs0>;
-	pinctrl-18 = <&d10_gpio>;
-	pinctrl-19 = <&d10_gpio_pullup>;
-	pinctrl-20 = <&d10_gpio_pulldown>;
-	pinctrl-21 = <&d11_spi0_d0>;
-	pinctrl-22 = <&d11_gpio>;
-	pinctrl-23 = <&d11_gpio_pullup>;
-	pinctrl-24 = <&d11_gpio_pulldown>;
-	pinctrl-25 = <&d12_spi0_d1>;
-	pinctrl-26 = <&d12_gpio>;
-	pinctrl-27 = <&d12_gpio_pullup>;
-	pinctrl-28 = <&d12_gpio_pulldown>;
-	pinctrl-29 = <&d13_spi0_clk>;
-	pinctrl-30 = <&d13_gpio>;
-	pinctrl-31 = <&d13_gpio_pullup>;
-	pinctrl-32 = <&d13_gpio_pulldown>;
-	pinctrl-33 = <&a0_gpio>;
-	pinctrl-34 = <&a0_gpio_pullup>;
-	pinctrl-35 = <&a0_gpio_pulldown>;
-	pinctrl-36 = <&a1_gpio>;
-	pinctrl-37 = <&a1_gpio_pullup>;
-	pinctrl-38 = <&a1_gpio_pulldown>;
-	pinctrl-39 = <&a2_gpio>;
-	pinctrl-40 = <&a2_gpio_pullup>;
-	pinctrl-41 = <&a2_gpio_pulldown>;
-	pinctrl-42 = <&a3_gpio>;
-	pinctrl-43 = <&a3_gpio_pullup>;
-	pinctrl-44 = <&a3_gpio_pulldown>;
-	pinctrl-45 = <&a4_gpio>;
-	pinctrl-46 = <&a4_gpio_pullup>;
-	pinctrl-47 = <&a4_gpio_pulldown>;
-	pinctrl-48 = <&a5_gpio>;
-	pinctrl-49 = <&a5_gpio_pullup>;
-	pinctrl-50 = <&a5_gpio_pulldown>;
-
-	d0_uart0_rxd: d0-uart0-rxd-pins {
-		pinctrl-single,pins = <
-			/* (P4) MCU_UART0_RXD */
-			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4)
-		>;
-	};
-
-	d0_gpio: d0-gpio-pins {
-		pinctrl-single,pins = <
-			/* (P4) WKUP_GPIO0_29 */
-			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 7)
-		>;
-	};
-
-	d0_gpio_pullup: d0-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (P4) WKUP_GPIO0_29 */
-			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d0_gpio_pulldown: d0-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (P4) WKUP_GPIO0_29 */
-			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d1_uart0_txd: d1-uart0-txd-pins {
-		pinctrl-single,pins = <
-			/* (P5) MCU_UART0_TXD */
-			AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4)
-		>;
-	};
-
-	d1_gpio: d1-gpio-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_30 */
-			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)
-		>;
-	};
-
-	d1_gpio_pullup: d1-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_30 */
-			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)
-		>;
-	};
-
-	d1_gpio_pulldown: d1-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_30 */
-			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d2_uart0_ctsn: d2-uart0-ctsn-pins {
-		pinctrl-single,pins = <
-			/* (P1) MCU_UART0_CTSn */
-			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 4)
-		>;
-	};
-
-	d2_gpio: d2-gpio-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_31 */
-			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7)
-		>;
-	};
-
-	d2_gpio_pullup: d2-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_31 */
-			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7)
-		>;
-	};
-
-	d2_gpio_pulldown: d2-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_31 */
-			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d3_uart0_rtsn: d3-uart0-rtsn-pins {
-		pinctrl-single,pins = <
-			/* (N3) MCU_UART0_RTSn */
-			AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 4)
-		>;
-	};
-
-	d3_gpio: d3-gpio-pins {
-		pinctrl-single,pins = <
-			/* (N3) WKUP_GPIO0_33 */
-			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7)
-		>;
-	};
-
-	d3_gpio_pullup: d3-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (N3) WKUP_GPIO0_33 */
-			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7)
-		>;
-	};
-
-	d3_gpio_pulldown: d3-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (N3) WKUP_GPIO0_33 */
-			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d10_spi0_cs0: d10-spi0-cs0-pins {
-		pinctrl-single,pins = <
-			/* (Y4) MCU_SPI0_CS0 */
-			AM65X_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0)
-		>;
-	};
-
-	d10_gpio: d10-gpio-pins {
-		pinctrl-single,pins = <
-			/* (Y4) WKUP_GPIO0_51 */
-			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7)
-		>;
-	};
-
-	d10_gpio_pullup: d10-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (Y4) WKUP_GPIO0_51 */
-			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7)
-		>;
-	};
-
-	d10_gpio_pulldown: d10-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (Y4) WKUP_GPIO0_51 */
-			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d11_spi0_d0: d11-spi0-d0-pins {
-		pinctrl-single,pins = <
-			/* (Y3) MCU_SPI0_D0 */
-			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 0)
-		>;
-	};
-
-	d11_gpio: d11-gpio-pins {
-		pinctrl-single,pins = <
-			/* (Y3) WKUP_GPIO0_49 */
-			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7)
-		>;
-	};
-
-	d11_gpio_pullup: d11-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (Y3) WKUP_GPIO0_49 */
-			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7)
-		>;
-	};
-
-	d11_gpio_pulldown: d11-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (Y3) WKUP_GPIO0_49 */
-			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d12_spi0_d1: d12-spi0-d1-pins {
-		pinctrl-single,pins = <
-			/* (Y2) MCU_SPI0_D1 */
-			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 0)
-		>;
-	};
-
-	d12_gpio: d12-gpio-pins {
-		pinctrl-single,pins = <
-			/* (Y2) WKUP_GPIO0_50 */
-			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7)
-		>;
-	};
-
-	d12_gpio_pullup: d12-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (Y2) WKUP_GPIO0_50 */
-			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7)
-		>;
-	};
-
-	d12_gpio_pulldown: d12-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (Y2) WKUP_GPIO0_50 */
-			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d13_spi0_clk: d13-spi0-clk-pins {
-		pinctrl-single,pins = <
-			/* (Y1) MCU_SPI0_CLK */
-			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 0)
-		>;
-	};
-
-	d13_gpio: d13-gpio-pins {
-		pinctrl-single,pins = <
-			/* (Y1) WKUP_GPIO0_48 */
-			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7)
-		>;
-	};
-
-	d13_gpio_pullup: d13-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (Y1) WKUP_GPIO0_48 */
-			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7)
-		>;
-	};
-
-	d13_gpio_pulldown: d13-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (Y1) WKUP_GPIO0_48 */
-			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a0_gpio: a0-gpio-pins {
-		pinctrl-single,pins = <
-			/* (L6) WKUP_GPIO0_45 */
-			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7)
-		>;
-	};
-
-	a0_gpio_pullup: a0-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (L6) WKUP_GPIO0_45 */
-			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7)
-		>;
-	};
-
-	a0_gpio_pulldown: a0-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (L6) WKUP_GPIO0_45 */
-			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a1_gpio: a1-gpio-pins {
-		pinctrl-single,pins = <
-			/* (M6) WKUP_GPIO0_44 */
-			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7)
-		>;
-	};
-
-	a1_gpio_pullup: a1-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (M6) WKUP_GPIO0_44 */
-			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7)
-		>;
-	};
-
-	a1_gpio_pulldown: a1-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (M6) WKUP_GPIO0_44 */
-			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a2_gpio: a2-gpio-pins {
-		pinctrl-single,pins = <
-			/* (L5) WKUP_GPIO0_43 */
-			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7)
-		>;
-	};
-
-	a2_gpio_pullup: a2-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (L5) WKUP_GPIO0_43 */
-			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7)
-		>;
-	};
-
-	a2_gpio_pulldown: a2-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (L5) WKUP_GPIO0_43 */
-			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a3_gpio: a3-gpio-pins {
-		pinctrl-single,pins = <
-			/* (M5) WKUP_GPIO0_39 */
-			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7)
-		>;
-	};
-
-	a3_gpio_pullup: a3-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (M5) WKUP_GPIO0_39 */
-			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7)
-		>;
-	};
-
-	a3_gpio_pulldown: a3-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (M5) WKUP_GPIO0_39 */
-			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a4_gpio: a4-gpio-pins {
-		pinctrl-single,pins = <
-			/* (L2) WKUP_GPIO0_42 */
-			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7)
-		>;
-	};
-
-	a4_gpio_pullup: a4-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (L2) WKUP_GPIO0_42 */
-			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7)
-		>;
-	};
-
-	a4_gpio_pulldown: a4-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (L2) WKUP_GPIO0_42 */
-			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a5_gpio: a5-gpio-pins {
-		pinctrl-single,pins = <
-			/* (N5) WKUP_GPIO0_35 */
-			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT, 7)
-		>;
-	};
-
-	a5_gpio_pullup: a5-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (N5) WKUP_GPIO0_35 */
-			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	a5_gpio_pulldown: a5-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (N5) WKUP_GPIO0_35 */
-			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	wkup_i2c0_pins_default: wkup-i2c0-default-pins {
-		pinctrl-single,pins = <
-			/* (AC7) WKUP_I2C0_SCL */
-			AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT,  0)
-			/* (AD6) WKUP_I2C0_SDA */
-			AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT,  0)
-		>;
-	};
-
 	mcu_i2c0_pins_default: mcu-i2c0-default-pins {
 		pinctrl-single,pins = <
 			/* (AD8) MCU_I2C0_SCL */
@@ -624,13 +196,6 @@ AM65X_WKUP_IOPAD(0x00ec, PIN_INPUT,  0)
 		>;
 	};
 
-	arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-default-pins {
-		pinctrl-single,pins = <
-			/* (R2) WKUP_GPIO0_21 */
-			AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7)
-		>;
-	};
-
 	push_button_pins_default: push-button-default-pins {
 		pinctrl-single,pins = <
 			/* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */
@@ -638,22 +203,6 @@ AM65X_WKUP_IOPAD(0x0034, PIN_INPUT,  7)
 		>;
 	};
 
-
-	arduino_io_oe_pins_default: arduino-io-oe-default-pins {
-		pinctrl-single,pins = <
-			/* (N4) WKUP_GPIO0_34 */
-			AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 7)
-			/* (M2) WKUP_GPIO0_36 */
-			AM65X_WKUP_IOPAD(0x0060, PIN_OUTPUT, 7)
-			/* (M3) WKUP_GPIO0_37 */
-			AM65X_WKUP_IOPAD(0x0064, PIN_OUTPUT, 7)
-			/* (M4) WKUP_GPIO0_38 */
-			AM65X_WKUP_IOPAD(0x0068, PIN_OUTPUT, 7)
-			/* (M1) WKUP_GPIO0_41 */
-			AM65X_WKUP_IOPAD(0x0074, PIN_OUTPUT, 7)
-		>;
-	};
-
 	mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-default-pins {
 		pinctrl-single,pins = <
 			/* (V1) MCU_OSPI0_CLK */
@@ -717,214 +266,6 @@ AM65X_WKUP_IOPAD(0x003C, PIN_OUTPUT, 7)
 };
 
 &main_pmx0 {
-	pinctrl-names =
-		"default",
-		"d4-ehrpwm0-a", "d4-gpio", "d4-gpio-pullup", "d4-gpio-pulldown",
-		"d5-ehrpwm1-a", "d5-gpio", "d5-gpio-pullup", "d5-gpio-pulldown",
-		"d6-ehrpwm2-a", "d6-gpio", "d6-gpio-pullup", "d6-gpio-pulldown",
-		"d7-ehrpwm3-a", "d7-gpio", "d7-gpio-pullup", "d7-gpio-pulldown",
-		"d8-ehrpwm4-a", "d8-gpio", "d8-gpio-pullup", "d8-gpio-pulldown",
-		"d9-ehrpwm5-a", "d9-gpio", "d9-gpio-pullup", "d9-gpio-pulldown";
-
-	pinctrl-0 = <&d4_ehrpwm0_a>;
-	pinctrl-1 = <&d4_ehrpwm0_a>;
-	pinctrl-2 = <&d4_gpio>;
-	pinctrl-3 = <&d4_gpio_pullup>;
-	pinctrl-4 = <&d4_gpio_pulldown>;
-
-	pinctrl-5 = <&d5_ehrpwm1_a>;
-	pinctrl-6 = <&d5_gpio>;
-	pinctrl-7 = <&d5_gpio_pullup>;
-	pinctrl-8 = <&d5_gpio_pulldown>;
-
-	pinctrl-9 = <&d6_ehrpwm2_a>;
-	pinctrl-10 = <&d6_gpio>;
-	pinctrl-11 = <&d6_gpio_pullup>;
-	pinctrl-12 = <&d6_gpio_pulldown>;
-
-	pinctrl-13 = <&d7_ehrpwm3_a>;
-	pinctrl-14 = <&d7_gpio>;
-	pinctrl-15 = <&d7_gpio_pullup>;
-	pinctrl-16 = <&d7_gpio_pulldown>;
-
-	pinctrl-17 = <&d8_ehrpwm4_a>;
-	pinctrl-18 = <&d8_gpio>;
-	pinctrl-19 = <&d8_gpio_pullup>;
-	pinctrl-20 = <&d8_gpio_pulldown>;
-
-	pinctrl-21 = <&d9_ehrpwm5_a>;
-	pinctrl-22 = <&d9_gpio>;
-	pinctrl-23 = <&d9_gpio_pullup>;
-	pinctrl-24 = <&d9_gpio_pulldown>;
-
-	d4_ehrpwm0_a: d4-ehrpwm0-a-pins {
-		pinctrl-single,pins = <
-			/* (AG18) EHRPWM0_A */
-			AM65X_IOPAD(0x0084, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d4_gpio: d4-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AG18) GPIO0_33 */
-			AM65X_IOPAD(0x0084, PIN_INPUT, 7)
-		>;
-	};
-
-	d4_gpio_pullup: d4-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AG18) GPIO0_33 */
-			AM65X_IOPAD(0x0084, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d4_gpio_pulldown: d4-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AG18) GPIO0_33 */
-			AM65X_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d5_ehrpwm1_a: d5-ehrpwm1-a-pins {
-		pinctrl-single,pins = <
-			/* (AF17) EHRPWM1_A */
-			AM65X_IOPAD(0x008C, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d5_gpio: d5-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AF17) GPIO0_35 */
-			AM65X_IOPAD(0x008C, PIN_INPUT, 7)
-		>;
-	};
-
-	d5_gpio_pullup: d5-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AF17) GPIO0_35 */
-			AM65X_IOPAD(0x008C, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d5_gpio_pulldown: d5-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AF17) GPIO0_35 */
-			AM65X_IOPAD(0x008C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d6_ehrpwm2_a: d6-ehrpwm2-a-pins {
-		pinctrl-single,pins = <
-			/* (AH16) EHRPWM2_A */
-			AM65X_IOPAD(0x0098, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d6_gpio: d6-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AH16) GPIO0_38 */
-			AM65X_IOPAD(0x0098, PIN_INPUT, 7)
-		>;
-	};
-
-	d6_gpio_pullup: d6-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AH16) GPIO0_38 */
-			AM65X_IOPAD(0x0098, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d6_gpio_pulldown: d6-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AH16) GPIO0_38 */
-			AM65X_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d7_ehrpwm3_a: d7-ehrpwm3-a-pins {
-		pinctrl-single,pins = <
-			/* (AH15) EHRPWM3_A */
-			AM65X_IOPAD(0x00AC, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d7_gpio: d7-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AH15) GPIO0_43 */
-			AM65X_IOPAD(0x00AC, PIN_INPUT, 7)
-		>;
-	};
-
-	d7_gpio_pullup: d7-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AH15) GPIO0_43 */
-			AM65X_IOPAD(0x00AC, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d7_gpio_pulldown: d7-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AH15) GPIO0_43 */
-			AM65X_IOPAD(0x00AC, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d8_ehrpwm4_a: d8-ehrpwm4-a-pins {
-		pinctrl-single,pins = <
-			/* (AG15) EHRPWM4_A */
-			AM65X_IOPAD(0x00C0, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d8_gpio: d8-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AG15) GPIO0_48 */
-			AM65X_IOPAD(0x00C0, PIN_INPUT, 7)
-		>;
-	};
-
-	d8_gpio_pullup: d8-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AG15) GPIO0_48 */
-			AM65X_IOPAD(0x00C0, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d8_gpio_pulldown: d8-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AG15) GPIO0_48 */
-			AM65X_IOPAD(0x00C0, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d9_ehrpwm5_a: d9-ehrpwm5-a-pins {
-		pinctrl-single,pins = <
-			/* (AD15) EHRPWM5_A */
-			AM65X_IOPAD(0x00CC, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d9_gpio: d9-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AD15) GPIO0_51 */
-			AM65X_IOPAD(0x00CC, PIN_INPUT, 7)
-		>;
-	};
-
-	d9_gpio_pullup: d9-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AD15) GPIO0_51 */
-			AM65X_IOPAD(0x00CC, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d9_gpio_pulldown: d9-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AD15) GPIO0_51 */
-			AM65X_IOPAD(0x00CC, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
 	main_pcie_enable_pins_default: main-pcie-enable-default-pins {
 		pinctrl-single,pins = <
 			AM65X_IOPAD(0x01c4, PIN_INPUT_PULLUP, 7)  /* (AH13) GPIO1_17 */
@@ -1083,57 +424,11 @@ &main_uart1 {
 	pinctrl-0 = <&main_uart1_pins_default>;
 };
 
-&mcu_uart0 {
-	status = "okay";
-};
-
-&main_gpio0 {
-	gpio-line-names =
-		"main_gpio0-base", "", "", "", "", "", "", "", "", "",
-		"", "", "", "", "", "", "", "", "", "",
-		"", "", "", "", "", "", "", "", "", "",
-		"", "", "", "IO4", "", "IO5", "", "", "IO6", "",
-		"", "", "", "IO7", "", "", "", "", "IO8", "",
-		"", "IO9";
-};
-
 &main_gpio1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_pcie_enable_pins_default>;
 };
 
-&wkup_gpio0 {
-	pinctrl-names = "default";
-	pinctrl-0 =
-		<&arduino_i2c_aio_switch_pins_default>,
-		<&arduino_io_oe_pins_default>,
-		<&push_button_pins_default>,
-		<&db9_com_mode_pins_default>;
-	gpio-line-names =
-		/* 0..9 */
-		"wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0",
-		"UART0-enable", "UART0-terminate", "", "WIFI-disable",
-		/* 10..19 */
-		"", "", "", "", "", "", "", "", "", "",
-		/* 20..29 */
-		"", "A4A5-I2C-mux", "", "", "", "USER-button", "", "", "","IO0",
-		/* 30..39 */
-		"IO1", "IO2", "", "IO3", "IO17-direction", "A5",
-		"IO16-direction", "IO15-direction", "IO14-direction", "A3",
-		/* 40..49 */
-		"", "IO18-direction", "A4", "A2", "A1", "A0", "", "", "IO13",
-		"IO11",
-		/* 50..51 */
-		"IO12", "IO10";
-};
-
-&wkup_i2c0 {
-	status = "okay";
-	pinctrl-names = "default";
-	pinctrl-0 = <&wkup_i2c0_pins_default>;
-	clock-frequency = <400000>;
-};
-
 &mcu_i2c0 {
 	status = "okay";
 	pinctrl-names = "default";
@@ -1151,47 +446,6 @@ psu: regulator at 60 {
 		ti,vsel1-state-high;
 		ti,enable-vout-discharge;
 	};
-
-	/* D4200 */
-	pcal9535_1: gpio at 20 {
-		compatible = "nxp,pcal9535";
-		reg = <0x20>;
-		#gpio-cells = <2>;
-		gpio-controller;
-		gpio-line-names =
-			"A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull",
-			"A5-pull", "", "",
-			"IO14-enable", "IO15-enable", "IO16-enable",
-			"IO17-enable", "IO18-enable", "IO19-enable";
-	};
-
-	/* D4201 */
-	pcal9535_2: gpio at 21 {
-		compatible = "nxp,pcal9535";
-		reg = <0x21>;
-		#gpio-cells = <2>;
-		gpio-controller;
-		gpio-line-names =
-			"IO0-direction", "IO1-direction", "IO2-direction",
-			"IO3-direction", "IO4-direction", "IO5-direction",
-			"IO6-direction", "IO7-direction",
-			"IO8-direction", "IO9-direction", "IO10-direction",
-			"IO11-direction", "IO12-direction", "IO13-direction",
-			"IO19-direction";
-	};
-
-	/* D4202 */
-	pcal9535_3: gpio at 25 {
-		compatible = "nxp,pcal9535";
-		reg = <0x25>;
-		#gpio-cells = <2>;
-		gpio-controller;
-		gpio-line-names =
-			"IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull",
-			"IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull",
-			"IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull",
-			"IO12-pull", "IO13-pull";
-	};
 };
 
 &main_i2c0 {
@@ -1292,13 +546,6 @@ &mcu_spi0 {
 	ti,pindir-d0-out-d1-in;
 };
 
-&tscadc1 {
-	status = "okay";
-	adc {
-		ti,adc-channels = <0 1 2 3 4 5>;
-	};
-};
-
 &ospi0 {
 	status = "okay";
 	pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
index 2300abe69e94..8c438f101c99 100644
--- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
@@ -10,6 +10,7 @@
  */
 
 #include "k3-am65-iot2050-common.dtsi"
+#include "k3-am65-iot2050-arduino-connector.dtsi"
 
 / {
 	memory at 80000000 {
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
index 1e5d4d98b69b..2401cbe2b66c 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
@@ -15,6 +15,7 @@
 
 #include "k3-am6548-iot2050-advanced-common.dtsi"
 #include "k3-am65-iot2050-common-pg2.dtsi"
+#include "k3-am65-iot2050-arduino-connector.dtsi"
 
 / {
 	compatible = "siemens,iot2050-advanced-m2", "ti,am654";
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
index a8ce8c891894..c1205feef54e 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
@@ -17,6 +17,7 @@
 
 #include "k3-am6548-iot2050-advanced-common.dtsi"
 #include "k3-am65-iot2050-common-pg2.dtsi"
+#include "k3-am65-iot2050-arduino-connector.dtsi"
 
 / {
 	compatible = "siemens,iot2050-advanced-pg2", "ti,am654";
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
index 077f165bdc68..b66965f992b9 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
@@ -17,6 +17,7 @@
 
 #include "k3-am6548-iot2050-advanced-common.dtsi"
 #include "k3-am65-iot2050-common-pg1.dtsi"
+#include "k3-am65-iot2050-arduino-connector.dtsi"
 
 / {
 	compatible = "siemens,iot2050-advanced", "ti,am654";
-- 
2.35.3



From andrew at lunn.ch  Mon Dec 18 08:41:36 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 18 Dec 2023 17:41:36 +0100
Subject: [PATCH net 0/1] Prevent DSA tags from breaking COE
In-Reply-To: <20231218162326.173127-1-romain.gantois@bootlin.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
Message-ID: <f4166144-4874-4b10-96f8-fc3e03f94904@lunn.ch>

On Mon, Dec 18, 2023 at 05:23:22PM +0100, Romain Gantois wrote:
> Hello everyone,
> 
> This is a bugfix for an issue that was recently brought up in two
> reports:
> 
> https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495 at bootlin.com/
> https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2 at electromag.com.au/
> 
> The Checksum Offloading Engine of some stmmac cores (e.g. DWMAC1000)
> computes an incorrect checksum when presented with DSA-tagged packets. This
> causes all TCP/UDP transfers to break when the stmmac device is connected
> to the CPU port of a DSA switch.

Probably a dumb question.... Does this COE also perform checksum
validation on receive? Is it also getting confused by the DSA header?

You must of tested receive, so it works somehow, but i just wounder if
something needs to be done to be on the safe side?

	  Andrew


From ovidiu.panait at windriver.com  Mon Dec 18 08:46:43 2023
From: ovidiu.panait at windriver.com (ovidiu.panait at windriver.com)
Date: Mon, 18 Dec 2023 18:46:43 +0200
Subject: [PATCH 1/7] crypto: rk3288 - Use helper to set reqsize
Message-ID: <20231218164649.2492465-1-ovidiu.panait@windriver.com>

From: Ovidiu Panait <ovidiu.panait at windriver.com>

The value of reqsize must only be changed through the helper.

Signed-off-by: Ovidiu Panait <ovidiu.panait at windriver.com>
---
Cc: Heiko Stuebner <heiko at sntech.de>
Cc: Corentin Labbe <clabbe at baylibre.com>
Cc: linux-rockchip at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org

 drivers/crypto/rockchip/rk3288_crypto_skcipher.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/rockchip/rk3288_crypto_skcipher.c b/drivers/crypto/rockchip/rk3288_crypto_skcipher.c
index da95747d973f..9393e10671c2 100644
--- a/drivers/crypto/rockchip/rk3288_crypto_skcipher.c
+++ b/drivers/crypto/rockchip/rk3288_crypto_skcipher.c
@@ -445,8 +445,8 @@ static int rk_cipher_tfm_init(struct crypto_skcipher *tfm)
 		return PTR_ERR(ctx->fallback_tfm);
 	}
 
-	tfm->reqsize = sizeof(struct rk_cipher_rctx) +
-		crypto_skcipher_reqsize(ctx->fallback_tfm);
+	crypto_skcipher_set_reqsize(tfm, sizeof(struct rk_cipher_rctx) +
+				    crypto_skcipher_reqsize(ctx->fallback_tfm));
 
 	return 0;
 }
-- 
2.34.1



From ovidiu.panait at windriver.com  Mon Dec 18 08:46:47 2023
From: ovidiu.panait at windriver.com (ovidiu.panait at windriver.com)
Date: Mon, 18 Dec 2023 18:46:47 +0200
Subject: [PATCH 5/7] crypto: sl3516 - Use helper to set reqsize
In-Reply-To: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
References: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
Message-ID: <20231218164649.2492465-5-ovidiu.panait@windriver.com>

From: Ovidiu Panait <ovidiu.panait at windriver.com>

The value of reqsize must only be changed through the helper.

Signed-off-by: Ovidiu Panait <ovidiu.panait at windriver.com>
---
Cc: Hans Ulli Kroll <ulli.kroll at googlemail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Corentin Labbe <clabbe at baylibre.com>
Cc: linux-arm-kernel at lists.infradead.org

 drivers/crypto/gemini/sl3516-ce-cipher.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/gemini/sl3516-ce-cipher.c b/drivers/crypto/gemini/sl3516-ce-cipher.c
index 49dce9e0a834..583010b2d007 100644
--- a/drivers/crypto/gemini/sl3516-ce-cipher.c
+++ b/drivers/crypto/gemini/sl3516-ce-cipher.c
@@ -332,8 +332,8 @@ int sl3516_ce_cipher_init(struct crypto_tfm *tfm)
 		return PTR_ERR(op->fallback_tfm);
 	}
 
-	sktfm->reqsize = sizeof(struct sl3516_ce_cipher_req_ctx) +
-			 crypto_skcipher_reqsize(op->fallback_tfm);
+	crypto_skcipher_set_reqsize(sktfm, sizeof(struct sl3516_ce_cipher_req_ctx) +
+				    crypto_skcipher_reqsize(op->fallback_tfm));
 
 	dev_info(op->ce->dev, "Fallback for %s is %s\n",
 		 crypto_tfm_alg_driver_name(&sktfm->base),
-- 
2.34.1



From ovidiu.panait at windriver.com  Mon Dec 18 08:46:46 2023
From: ovidiu.panait at windriver.com (ovidiu.panait at windriver.com)
Date: Mon, 18 Dec 2023 18:46:46 +0200
Subject: [PATCH 4/7] crypto: stm32/cryp - Use helper to set reqsize
In-Reply-To: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
References: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
Message-ID: <20231218164649.2492465-4-ovidiu.panait@windriver.com>

From: Ovidiu Panait <ovidiu.panait at windriver.com>

The value of reqsize must only be changed through the helper.

Signed-off-by: Ovidiu Panait <ovidiu.panait at windriver.com>
---
Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: linux-stm32 at st-md-mailman.stormreply.com
Cc: linux-arm-kernel at lists.infradead.org

 drivers/crypto/stm32/stm32-cryp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/stm32/stm32-cryp.c b/drivers/crypto/stm32/stm32-cryp.c
index c3cbc2673338..11ad4ffdce0d 100644
--- a/drivers/crypto/stm32/stm32-cryp.c
+++ b/drivers/crypto/stm32/stm32-cryp.c
@@ -838,7 +838,7 @@ static int stm32_cryp_aead_one_req(struct crypto_engine *engine, void *areq);
 
 static int stm32_cryp_aes_aead_init(struct crypto_aead *tfm)
 {
-	tfm->reqsize = sizeof(struct stm32_cryp_reqctx);
+	crypto_aead_set_reqsize(tfm, sizeof(struct stm32_cryp_reqctx));
 
 	return 0;
 }
-- 
2.34.1



From ovidiu.panait at windriver.com  Mon Dec 18 08:46:48 2023
From: ovidiu.panait at windriver.com (ovidiu.panait at windriver.com)
Date: Mon, 18 Dec 2023 18:46:48 +0200
Subject: [PATCH 6/7] crypto: sun8i-ce - Use helper to set reqsize
In-Reply-To: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
References: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
Message-ID: <20231218164649.2492465-6-ovidiu.panait@windriver.com>

From: Ovidiu Panait <ovidiu.panait at windriver.com>

The value of reqsize must only be changed through the helper.

Signed-off-by: Ovidiu Panait <ovidiu.panait at windriver.com>
---
Cc: Corentin Labbe <clabbe.montjoie at gmail.com>
Cc: Chen-Yu Tsai <wens at csie.org>
Cc: Jernej Skrabec <jernej.skrabec at gmail.com>
Cc: Samuel Holland <samuel at sholland.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-sunxi at lists.linux.dev

 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index 8d4c42863a62..1262a7773ef3 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -431,8 +431,8 @@ int sun8i_ce_cipher_init(struct crypto_tfm *tfm)
 		return PTR_ERR(op->fallback_tfm);
 	}
 
-	sktfm->reqsize = sizeof(struct sun8i_cipher_req_ctx) +
-			 crypto_skcipher_reqsize(op->fallback_tfm);
+	crypto_skcipher_set_reqsize(sktfm, sizeof(struct sun8i_cipher_req_ctx) +
+				    crypto_skcipher_reqsize(op->fallback_tfm));
 
 	memcpy(algt->fbname,
 	       crypto_tfm_alg_driver_name(crypto_skcipher_tfm(op->fallback_tfm)),
-- 
2.34.1



From ovidiu.panait at windriver.com  Mon Dec 18 08:46:49 2023
From: ovidiu.panait at windriver.com (ovidiu.panait at windriver.com)
Date: Mon, 18 Dec 2023 18:46:49 +0200
Subject: [PATCH 7/7] crypto: sun8i-ss - Use helper to set reqsize
In-Reply-To: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
References: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
Message-ID: <20231218164649.2492465-7-ovidiu.panait@windriver.com>

From: Ovidiu Panait <ovidiu.panait at windriver.com>

The value of reqsize must only be changed through the helper.

Signed-off-by: Ovidiu Panait <ovidiu.panait at windriver.com>
---
Cc: Corentin Labbe <clabbe.montjoie at gmail.com>
Cc: Chen-Yu Tsai <wens at csie.org>
Cc: Jernej Skrabec <jernej.skrabec at gmail.com>
Cc: Samuel Holland <samuel at sholland.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-sunxi at lists.linux.dev

 drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
index 7fa359725ec7..9b9605ce8ee6 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
@@ -405,9 +405,8 @@ int sun8i_ss_cipher_init(struct crypto_tfm *tfm)
 		return PTR_ERR(op->fallback_tfm);
 	}
 
-	sktfm->reqsize = sizeof(struct sun8i_cipher_req_ctx) +
-			 crypto_skcipher_reqsize(op->fallback_tfm);
-
+	crypto_skcipher_set_reqsize(sktfm, sizeof(struct sun8i_cipher_req_ctx) +
+				    crypto_skcipher_reqsize(op->fallback_tfm));
 
 	memcpy(algt->fbname,
 	       crypto_tfm_alg_driver_name(crypto_skcipher_tfm(op->fallback_tfm)),
-- 
2.34.1



From fabrice.gasnier at foss.st.com  Mon Dec 18 08:58:32 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Mon, 18 Dec 2023 17:58:32 +0100
Subject: [PATCH 2/6] dt-bindings: spi: stm32: add st,stm32mp25-spi
 compatible
In-Reply-To: <20231218155721.359198-3-alain.volmat@foss.st.com>
References: <20231218155721.359198-1-alain.volmat@foss.st.com>
 <20231218155721.359198-3-alain.volmat@foss.st.com>
Message-ID: <abf4725b-8569-47f8-a06d-c06285595625@foss.st.com>

On 12/18/23 16:57, Alain Volmat wrote:
> From: Valentin Caron <valentin.caron at foss.st.com>
> 
> Add st,stm32mp25-spi compatible in dt-bindings.  STM32MP25 spi is similar

Hi Alain,
In case you re-submit,
Nitpicking, extra space here could be removed    ^
Capital letters for SPI could also be used here             ^

Appart from that, you can add my:
Reviewed-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>

Best Regards,
Fabrice

> to the STM32H7 except for the following two points:
>   - Burst should not be enabled with the new DMA used on STM32MP25.
>   - STM32MP25 SPI8 has a limited feature set, it can only send words of
>     8 or 16 bits and with a maximum words number of 1024.
> 
> Signed-off-by: Valentin Caron <valentin.caron at foss.st.com>
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
> ---
>  Documentation/devicetree/bindings/spi/st,stm32-spi.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
> index 5754d603f34f..4bd9aeb81208 100644
> --- a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
> +++ b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
> @@ -25,6 +25,7 @@ properties:
>        - st,stm32f4-spi
>        - st,stm32f7-spi
>        - st,stm32h7-spi
> +      - st,stm32mp25-spi
>  
>    reg:
>      maxItems: 1


From gregor.herburger at ew.tq-group.com  Mon Dec 18 09:06:12 2023
From: gregor.herburger at ew.tq-group.com (Gregor Herburger)
Date: Mon, 18 Dec 2023 18:06:12 +0100
Subject: [PATCH] i2c: i2c-imx: allow bus recovery on non-muxable pads
Message-ID: <20231218-i2c-imx-recovery-v1-1-f69fa85b228c@ew.tq-group.com>

Currently the i2c-imx driver assumes that for bus recovery the i2c pins
can be reconfigured as gpio via pinctrl.

But bus recovery can also be done with a gpio electrically connected to
i2c scl.

Modify i2c_imx_init_recovery_info to allow bus recovery on platforms
without pinctrl. In this case only use scl-gpio and
i2c_generic_scl_recovery.

Signed-off-by: Gregor Herburger <gregor.herburger at ew.tq-group.com>
---
 drivers/i2c/busses/i2c-imx.c | 35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 1775a79aeba2..7d71accb031b 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1388,20 +1388,23 @@ static int i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
 	struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
 
 	i2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
-	if (!i2c_imx->pinctrl) {
-		dev_info(&pdev->dev, "pinctrl unavailable, bus recovery not supported\n");
-		return 0;
-	}
+
+	if (PTR_ERR(i2c_imx->pinctrl) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
 	if (IS_ERR(i2c_imx->pinctrl)) {
-		dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
-		return PTR_ERR(i2c_imx->pinctrl);
+		i2c_imx->pinctrl = NULL;
+		dev_info(&pdev->dev, "can't get pinctrl, trying non-pinctrl gpio recovery.\n");
 	}
 
-	i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
-			PINCTRL_STATE_DEFAULT);
-	i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
-			"gpio");
-	rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
+	if (i2c_imx->pinctrl) {
+		i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
+				PINCTRL_STATE_DEFAULT);
+		i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
+				"gpio");
+	}
+
+	rinfo->sda_gpiod = devm_gpiod_get_optional(&pdev->dev, "sda", GPIOD_IN);
 	rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
 
 	if (PTR_ERR(rinfo->sda_gpiod) == -EPROBE_DEFER ||
@@ -1415,11 +1418,15 @@ static int i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
 		return 0;
 	}
 
-	dev_dbg(&pdev->dev, "using scl%s for recovery\n",
+	if (i2c_imx->pinctrl_pins_default && i2c_imx->pinctrl_pins_gpio) {
+		rinfo->prepare_recovery = i2c_imx_prepare_recovery;
+		rinfo->unprepare_recovery = i2c_imx_unprepare_recovery;
+	}
+
+	dev_dbg(&pdev->dev, "using %sscl%s for recovery\n",
+		i2c_imx->pinctrl ? "pinctrl " : "",
 		rinfo->sda_gpiod ? ",sda" : "");
 
-	rinfo->prepare_recovery = i2c_imx_prepare_recovery;
-	rinfo->unprepare_recovery = i2c_imx_unprepare_recovery;
 	rinfo->recover_bus = i2c_generic_scl_recovery;
 	i2c_imx->adapter.bus_recovery_info = rinfo;
 

---
base-commit: ceb2fe0d438644e1de06b9a6468a1fb8e2199c70
change-id: 20231218-i2c-imx-recovery-6da66f0381df

Best regards,
-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
https://www.tq-group.com/



From michal.simek at amd.com  Mon Dec 18 09:10:50 2023
From: michal.simek at amd.com (Michal Simek)
Date: Mon, 18 Dec 2023 18:10:50 +0100
Subject: [PATCH] soc: xilinx: update maintainer of event manager driver
Message-ID: <0171170571802fe96b49cefbca9c87f3c1c9eee6.1702919377.git.michal.simek@amd.com>

From: Jay Buddhabhatti <jay.buddhabhatti at amd.com>

Added Michal as a maintainer of event manager driver as Abhyuday is no
longer active.

Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti at amd.com>
Signed-off-by: Michal Simek <michal.simek at amd.com>
---

 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 97f51d5ec1cf..39ad51aeeff0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23900,7 +23900,7 @@ F:	Documentation/devicetree/bindings/net/can/xilinx,can.yaml
 F:	drivers/net/can/xilinx_can.c
 
 XILINX EVENT MANAGEMENT DRIVER
-M:	Abhyuday Godhasara <abhyuday.godhasara at xilinx.com>
+M:	Michal Simek <michal.simek at amd.com>
 S:	Maintained
 F:	drivers/soc/xilinx/xlnx_event_manager.c
 F:	include/linux/firmware/xlnx-event-manager.h
-- 
2.36.1



From maz at kernel.org  Mon Dec 18 09:11:19 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 18 Dec 2023 17:11:19 +0000
Subject: (subset) [PATCH v3 00/17] KVM: arm64: Fixes to fine grain traps and pKVM traps
In-Reply-To: <20231214100158.2305400-1-tabba@google.com>
References: <20231214100158.2305400-1-tabba@google.com>
Message-ID: <170291942595.3349022.748097050325200963.b4-ty@kernel.org>

On Thu, 14 Dec 2023 10:01:40 +0000, Fuad Tabba wrote:
> Changes from v2:
> - Rebased on arm64/for-next/sysregs, which includes new system
>   register definitions (Mark, Joey)
> - Explicitly trap unsupported HFGxTR_EL2 features rather than
>   relying on its nMASK (Joey)
> - Add new system registers to the auto-generated sysreg rather
>   than hardcoding them (Mark)
> - Drop patch that was meant as RFC
> - Added missing system registers, fields, and  system
>   instructions
> - Split patches that make system register changes
> - Fixes to patches defining allowed features for protected VMs
> - Other minor fixes and tidying up
> 
> [...]

Applied to next with the changes agreed on the list.

[05/17] KVM: arm64: Explicitly trap unsupported HFGxTR_EL2 features
        commit: 1565c881c3df053447309ff69ec7fd5dee2085e4
[06/17] KVM: arm64: Add missing HFGxTR_EL2 FGT entries to nested virt
        commit: 9d400eb722bd1be712b007149ff1d8fb2d6470db
[07/17] KVM: arm64: Add missing HFGITR_EL2 FGT entries to nested virt
        commit: 863ac38984a822ff9f4337d70853d771dcf7aae5
[08/17] KVM: arm64: Add bit masks for HAFGRTR_EL2
        commit: f9d6ed0213021ea00af30efbfa33e9a06c0610f2
[09/17] KVM: arm64: Handle HAFGRTR_EL2 trapping in nested virt
        commit: 676f482354886caa9b0cfa9236f5d20ac78f8c6a
[10/17] KVM: arm64: Update and fix FGT register masks
        commit: fc04838f9c00fcbc90a8926bbd46928d6fb36477
[11/17] KVM: arm64: Add build validation for FGT trap mask values
        commit: 6c4abbea6d9c09df448b43624074a208c38e68e0
[12/17] KVM: arm64: Use generated FGT RES0 bits instead of specifying them
        commit: 9ff67dd26a9eed9d73dc23aa63e87b16b3382184
[13/17] KVM: arm64: Define FGT nMASK bits relative to other fields
        commit: 5f6bd3f3daaaab8559ad7d2266ba38345231b7ae
[14/17] KVM: arm64: Macros for setting/clearing FGT bits
        commit: 0ccd901da1886cf9dc53ab36ad8f1160b65e41f1
[15/17] KVM: arm64: Fix which features are marked as allowed for protected VMs
        commit: 73e3ce3f4a0e561e24ca71b20de00f03b427981e
[16/17] KVM: arm64: Mark PAuth as a restricted feature for protected VMs
        commit: 21de26dbc5170dde8e4dfbfa1ecb77804ed6a377
[17/17] KVM: arm64: Trap external trace for protected VMs
        commit: 9d52612690985fc0ee1ae1fbad61530a4f6bbb53

Cheers,

	M.
-- 
Without deviation from the norm, progress is not possible.




From tabba at google.com  Mon Dec 18 09:15:35 2023
From: tabba at google.com (Fuad Tabba)
Date: Mon, 18 Dec 2023 17:15:35 +0000
Subject: (subset) [PATCH v3 00/17] KVM: arm64: Fixes to fine grain traps
 and pKVM traps
In-Reply-To: <170291942595.3349022.748097050325200963.b4-ty@kernel.org>
References: <20231214100158.2305400-1-tabba@google.com> <170291942595.3349022.748097050325200963.b4-ty@kernel.org>
Message-ID: <CA+EHjTyd_GM0VSSW+3v8jNpC+w1pwhX0PHwKNtdcDFyJGTzAOw@mail.gmail.com>

On Mon, Dec 18, 2023 at 5:11?PM Marc Zyngier <maz at kernel.org> wrote:
>
> On Thu, 14 Dec 2023 10:01:40 +0000, Fuad Tabba wrote:
> > Changes from v2:
> > - Rebased on arm64/for-next/sysregs, which includes new system
> >   register definitions (Mark, Joey)
> > - Explicitly trap unsupported HFGxTR_EL2 features rather than
> >   relying on its nMASK (Joey)
> > - Add new system registers to the auto-generated sysreg rather
> >   than hardcoding them (Mark)
> > - Drop patch that was meant as RFC
> > - Added missing system registers, fields, and  system
> >   instructions
> > - Split patches that make system register changes
> > - Fixes to patches defining allowed features for protected VMs
> > - Other minor fixes and tidying up
> >
> > [...]
>
> Applied to next with the changes agreed on the list.

Thank you!
/fuad

>
> [05/17] KVM: arm64: Explicitly trap unsupported HFGxTR_EL2 features
>         commit: 1565c881c3df053447309ff69ec7fd5dee2085e4
> [06/17] KVM: arm64: Add missing HFGxTR_EL2 FGT entries to nested virt
>         commit: 9d400eb722bd1be712b007149ff1d8fb2d6470db
> [07/17] KVM: arm64: Add missing HFGITR_EL2 FGT entries to nested virt
>         commit: 863ac38984a822ff9f4337d70853d771dcf7aae5
> [08/17] KVM: arm64: Add bit masks for HAFGRTR_EL2
>         commit: f9d6ed0213021ea00af30efbfa33e9a06c0610f2
> [09/17] KVM: arm64: Handle HAFGRTR_EL2 trapping in nested virt
>         commit: 676f482354886caa9b0cfa9236f5d20ac78f8c6a
> [10/17] KVM: arm64: Update and fix FGT register masks
>         commit: fc04838f9c00fcbc90a8926bbd46928d6fb36477
> [11/17] KVM: arm64: Add build validation for FGT trap mask values
>         commit: 6c4abbea6d9c09df448b43624074a208c38e68e0
> [12/17] KVM: arm64: Use generated FGT RES0 bits instead of specifying them
>         commit: 9ff67dd26a9eed9d73dc23aa63e87b16b3382184
> [13/17] KVM: arm64: Define FGT nMASK bits relative to other fields
>         commit: 5f6bd3f3daaaab8559ad7d2266ba38345231b7ae
> [14/17] KVM: arm64: Macros for setting/clearing FGT bits
>         commit: 0ccd901da1886cf9dc53ab36ad8f1160b65e41f1
> [15/17] KVM: arm64: Fix which features are marked as allowed for protected VMs
>         commit: 73e3ce3f4a0e561e24ca71b20de00f03b427981e
> [16/17] KVM: arm64: Mark PAuth as a restricted feature for protected VMs
>         commit: 21de26dbc5170dde8e4dfbfa1ecb77804ed6a377
> [17/17] KVM: arm64: Trap external trace for protected VMs
>         commit: 9d52612690985fc0ee1ae1fbad61530a4f6bbb53
>
> Cheers,
>
>         M.
> --
> Without deviation from the norm, progress is not possible.
>
>


From oliver.upton at linux.dev  Mon Dec 18 09:20:04 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Mon, 18 Dec 2023 17:20:04 +0000
Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset
In-Reply-To: <878r5s8xvc.wl-maz@kernel.org>
References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
 <87a5q983zc.wl-maz@kernel.org>
 <ZX8w1vfQzeXP5klL@linux.dev>
 <ZX8xLhFFqTXRFQtd@linux.dev>
 <878r5s8xvc.wl-maz@kernel.org>
Message-ID: <ZYB_RKR5CqlVS-lV@linux.dev>

On Sun, Dec 17, 2023 at 06:52:55PM +0000, Marc Zyngier wrote:
> On Sun, 17 Dec 2023 17:34:38 +0000,
> Oliver Upton <oliver.upton at linux.dev> wrote:
> > 
> > On Sun, Dec 17, 2023 at 05:33:16PM +0000, Oliver Upton wrote:
> > > On Sun, Dec 17, 2023 at 11:26:15AM +0000, Marc Zyngier wrote:
> > > 
> > > [...]
> > > 
> > > > But this has *nothing* to do with the guest. This is the *host*
> > > > userspace performing a write to the redistributor view, which has
> > > > different semantics. Which is why your earlier description made no
> > > > sense to me.
> > > > 
> > > > I think the problem is slightly larger than what you describe. A write
> > > > to ISPENDR0 should be propagated to the ITS for any values of the
> > > > latch, just like this happens on enabling HW-backed SGIs.
> > > > 
> > > > Can you please give this a go?
> > > 
> > > What do you think about using this as an opportunity for a bit of
> > > cleanup? It'd be nice unify the various MMIO and uaccess handlers for
> > > SPENDING + CPENDING while being careful about the arch_timer interrupt.
> 
> What is special about the timer interrupt?

Isn't that the case where we have a physical IRQ mapped and wind up
forwarding state to the physical GIC?

> Could be. But I'd rather have separate fixes from more invasive
> reworks.  Specially given that we have had multiple ugly bugs around
> this code in the past, which is why we ended up splitting userspace
> from guest accessors.

Fine by me. I had felt like a common helper w/ the user v. guest
exclusions is a bit easier to understand than diffing two very similar
functions, but it isn't a big deal.

Anyway, I'm happy with your fix. I'd like Kunkun to give it a go but
either way I can pick it up for 6.7.

-- 
Thanks,
Oliver


From maz at kernel.org  Mon Dec 18 09:29:48 2023
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 18 Dec 2023 17:29:48 +0000
Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset
In-Reply-To: <ZYB_RKR5CqlVS-lV@linux.dev>
References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
	<87a5q983zc.wl-maz@kernel.org>
	<ZX8w1vfQzeXP5klL@linux.dev>
	<ZX8xLhFFqTXRFQtd@linux.dev>
	<878r5s8xvc.wl-maz@kernel.org>
	<ZYB_RKR5CqlVS-lV@linux.dev>
Message-ID: <86r0jja06r.wl-maz@kernel.org>

On Mon, 18 Dec 2023 17:20:04 +0000,
Oliver Upton <oliver.upton at linux.dev> wrote:
> 
> On Sun, Dec 17, 2023 at 06:52:55PM +0000, Marc Zyngier wrote:
> > On Sun, 17 Dec 2023 17:34:38 +0000,
> > Oliver Upton <oliver.upton at linux.dev> wrote:
> > > 
> > > On Sun, Dec 17, 2023 at 05:33:16PM +0000, Oliver Upton wrote:
> > > > On Sun, Dec 17, 2023 at 11:26:15AM +0000, Marc Zyngier wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > But this has *nothing* to do with the guest. This is the *host*
> > > > > userspace performing a write to the redistributor view, which has
> > > > > different semantics. Which is why your earlier description made no
> > > > > sense to me.
> > > > > 
> > > > > I think the problem is slightly larger than what you describe. A write
> > > > > to ISPENDR0 should be propagated to the ITS for any values of the
> > > > > latch, just like this happens on enabling HW-backed SGIs.
> > > > > 
> > > > > Can you please give this a go?
> > > > 
> > > > What do you think about using this as an opportunity for a bit of
> > > > cleanup? It'd be nice unify the various MMIO and uaccess handlers for
> > > > SPENDING + CPENDING while being careful about the arch_timer interrupt.
> > 
> > What is special about the timer interrupt?
> 
> Isn't that the case where we have a physical IRQ mapped and wind up
> forwarding state to the physical GIC?

Indeed. But that's not specific to the timer. That's a general
infrastructure that NV also uses it for the GIC maintenance interrupt.

> 
> > Could be. But I'd rather have separate fixes from more invasive
> > reworks.  Specially given that we have had multiple ugly bugs around
> > this code in the past, which is why we ended up splitting userspace
> > from guest accessors.
> 
> Fine by me. I had felt like a common helper w/ the user v. guest
> exclusions is a bit easier to understand than diffing two very similar
> functions, but it isn't a big deal.

To be clear, I'm not objecting to that rework. It's just that we
should carefully review these patches on the list, as they would have
a wider ranging impact than a pure GICv4.1 change.

> Anyway, I'm happy with your fix. I'd like Kunkun to give it a go but
> either way I can pick it up for 6.7.

Yup, same here. But we also shouldn't hold the 6.7 fixes for too long.
If we don't get feedback from Kunkun shortly, I'd suggest to move this
patch to 6.8, and at this point your approach makes complete sense.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


From frank at oltmanns.dev  Mon Dec 18 09:26:51 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Mon, 18 Dec 2023 18:26:51 +0100
Subject: [PATCH 1/5] clk: sunxi-ng: nkm: Support constraints on m/n
 ratio and parent rate
In-Reply-To: <20231218-pinephone-pll-fixes-v1-1-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-1-e238b6ed6dc1@oltmanns.dev>
Message-ID: <8734vz1kok.fsf@oltmanns.dev>


On 2023-12-18 at 14:35:19 +0100, Frank Oltmanns <frank at oltmanns.dev> wrote:
> The Allwinner A64 manual lists the following constraints for the
> PLL-MIPI clock:
>  - M/N >= 3
>  - (PLL_VIDEO0)/M >= 24MHz
>
> The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
> these constraints.
>
> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> ---
>  drivers/clk/sunxi-ng/ccu_nkm.c | 23 +++++++++++++++++++++++
>  drivers/clk/sunxi-ng/ccu_nkm.h |  8 ++++++++
>  2 files changed, 31 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> index eed64547ad42..2af5c1ebd527 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> @@ -16,6 +16,20 @@ struct _ccu_nkm {
>  	unsigned long	m, min_m, max_m;
>  };
>
> +static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long parent,
> +				  unsigned long n, unsigned long m)
> +{
> +	struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
> +
> +	if (nkm->max_mn_ratio && (m > nkm->max_mn_ratio * n))
> +		return false;
> +
> +	if (nkm->parent_wo_nk && (parent < nkm->parent_wo_nk * m))
> +		return false;
> +
> +	return true;
> +}
> +
>  static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common,
>  						       struct clk_hw *parent_hw,
>  						       unsigned long *parent, unsigned long rate,
> @@ -32,6 +46,9 @@ static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
>
>  				tmp_parent = clk_hw_round_rate(parent_hw, rate * _m / (_n * _k));
>
> +				if (!ccu_nkm_is_valid_rate(common, tmp_parent, _n, _m))
> +					continue;
> +
>  				tmp_rate = tmp_parent * _n * _k / _m;
>
>  				if (ccu_is_better_rate(common, rate, tmp_rate, best_rate) ||
> @@ -65,6 +82,12 @@ static unsigned long ccu_nkm_find_best(unsigned long parent, unsigned long rate,
>  	for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
>  		for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
>  			for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
> +				if ((common->reg == 0x040) && (_m > 3 * _n))
> +					break;
> +
> +				if ((common->reg == 0x040) && (parent < 24000000 * _m))
> +					continue;
> +

This, of course, is rubbish and should be this instead:
+				if (!ccu_nkm_is_valid_rate(common, parent, _n, _m))
+					continue;
+

I'll submit a V2 after receiving some feedback.

>  				unsigned long tmp_rate;
>
>  				tmp_rate = parent * _n * _k / _m;
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
> index 6601defb3f38..d3d3eaf55faf 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.h
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.h
> @@ -16,6 +16,12 @@
>   * struct ccu_nkm - Definition of an N-K-M clock
>   *
>   * Clocks based on the formula parent * N * K / M
> + *
> + * @max_mn_ratio:	Maximum value for M / N.
> + * @parent_wo_nk:	The minimum rate the parent must provide after applying the divisor,
> + *			but without applying the multipliers, i.e. the contstraint
> + *			   (parent rate)/M >= parent_wo_nk
> + *			must be fulfilled.
>   */
>  struct ccu_nkm {
>  	u32			enable;
> @@ -27,6 +33,8 @@ struct ccu_nkm {
>  	struct ccu_mux_internal	mux;
>
>  	unsigned int		fixed_post_div;
> +	unsigned long		max_mn_ratio;
> +	unsigned long           parent_wo_nk;
>
>  	struct ccu_common	common;
>  };


From david at redhat.com  Mon Dec 18 09:40:49 2023
From: david at redhat.com (David Hildenbrand)
Date: Mon, 18 Dec 2023 18:40:49 +0100
Subject: [PATCH v4 01/16] mm: thp: Batch-collapse PMD with set_ptes()
In-Reply-To: <20231218105100.172635-2-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-2-ryan.roberts@arm.com>
Message-ID: <8ce9f79c-be2f-4fa2-b356-39436a1d108a@redhat.com>

On 18.12.23 11:50, Ryan Roberts wrote:
> Refactor __split_huge_pmd_locked() so that a present PMD can be
> collapsed to PTEs in a single batch using set_ptes(). It also provides a
> future opportunity to batch-add the folio to the rmap using David's new
> batched rmap APIs.

I'd drop that sentence and rather just say "In the future, we might get 
rid of the remaining manual loop by using rmap batching.".

> 
> This should improve performance a little bit, but the real motivation is
> to remove the need for the arm64 backend to have to fold the contpte
> entries. Instead, since the ptes are set as a batch, the contpte blocks
> can be initially set up pre-folded (once the arm64 contpte support is
> added in the next few patches). This leads to noticeable performance
> improvement during split.
> 
Acked-by: David Hildenbrand <david at redhat.com>

-- 
Cheers,

David / dhildenb



From david at redhat.com  Mon Dec 18 09:47:17 2023
From: david at redhat.com (David Hildenbrand)
Date: Mon, 18 Dec 2023 18:47:17 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <20231218105100.172635-3-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
Message-ID: <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>

On 18.12.23 11:50, Ryan Roberts wrote:
> Convert copy_pte_range() to copy a batch of ptes in one go. A given
> batch is determined by the architecture with the new helper,
> pte_batch_remaining(), and maps a physically contiguous block of memory,
> all belonging to the same folio. A pte batch is then write-protected in
> one go in the parent using the new helper, ptep_set_wrprotects() and is
> set in one go in the child using the new helper, set_ptes_full().
> 
> The primary motivation for this change is to reduce the number of tlb
> maintenance operations that the arm64 backend has to perform during
> fork, as it is about to add transparent support for the "contiguous bit"
> in its ptes. By write-protecting the parent using the new
> ptep_set_wrprotects() (note the 's' at the end) function, the backend
> can avoid having to unfold contig ranges of PTEs, which is expensive,
> when all ptes in the range are being write-protected. Similarly, by
> using set_ptes_full() rather than set_pte_at() to set up ptes in the
> child, the backend does not need to fold a contiguous range once they
> are all populated - they can be initially populated as a contiguous
> range in the first place.
> 
> This code is very performance sensitive, and a significant amount of
> effort has been put into not regressing performance for the order-0
> folio case. By default, pte_batch_remaining() is compile constant 1,
> which enables the compiler to simplify the extra loops that are added
> for batching and produce code that is equivalent (and equally
> performant) as the previous implementation.
> 
> This change addresses the core-mm refactoring only and a separate change
> will implement pte_batch_remaining(), ptep_set_wrprotects() and
> set_ptes_full() in the arm64 backend to realize the performance
> improvement as part of the work to enable contpte mappings.
> 
> To ensure the arm64 is performant once implemented, this change is very
> careful to only call ptep_get() once per pte batch.
> 
> The following microbenchmark results demonstate that there is no
> significant performance change after this patch. Fork is called in a
> tight loop in a process with 1G of populated memory and the time for the
> function to execute is measured. 100 iterations per run, 8 runs
> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
> performed for case where 1G memory is comprised of order-0 folios and
> case where comprised of pte-mapped order-9 folios. Negative is faster,
> positive is slower, compared to baseline upon which the series is based:
> 
> | Apple M2 VM   | order-0 (pte-map) | order-9 (pte-map) |
> | fork          |-------------------|-------------------|
> | microbench    |    mean |   stdev |    mean |   stdev |
> |---------------|---------|---------|---------|---------|
> | baseline      |    0.0% |    1.1% |    0.0% |    1.2% |
> | after-change  |   -1.0% |    2.0% |   -0.1% |    1.1% |
> 
> | Ampere Altra  | order-0 (pte-map) | order-9 (pte-map) |
> | fork          |-------------------|-------------------|
> | microbench    |    mean |   stdev |    mean |   stdev |
> |---------------|---------|---------|---------|---------|
> | baseline      |    0.0% |    1.0% |    0.0% |    0.1% |
> | after-change  |   -0.1% |    1.2% |   -0.1% |    0.1% |
> 
> Tested-by: John Hubbard <jhubbard at nvidia.com>
> Reviewed-by: Alistair Popple <apopple at nvidia.com>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>   include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>   mm/memory.c             | 92 ++++++++++++++++++++++++++---------------
>   2 files changed, 139 insertions(+), 33 deletions(-)
> 
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index af7639c3b0a3..db93fb81465a 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>   #define arch_flush_lazy_mmu_mode()	do {} while (0)
>   #endif
>   
> +#ifndef pte_batch_remaining
> +/**
> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
> + * @pte: Page table entry for the first page.
> + * @addr: Address of the first page.
> + * @end: Batch ceiling (e.g. end of vma).
> + *
> + * Some architectures (arm64) can efficiently modify a contiguous batch of ptes.
> + * In such cases, this function returns the remaining number of pages to the end
> + * of the current batch, as defined by addr. This can be useful when iterating
> + * over ptes.
> + *
> + * May be overridden by the architecture, else batch size is always 1.
> + */
> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long addr,
> +						unsigned long end)
> +{
> +	return 1;
> +}
> +#endif

It's a shame we now lose the optimization for all other archtiectures.

Was there no way to have some basic batching mechanism that doesn't 
require arch specifics?

I'd have thought that something very basic would have worked like:

* Check if PTE is the same when setting the PFN to 0.
* Check that PFN is consecutive
* Check that all PFNs belong to the same folio

-- 
Cheers,

David / dhildenb



From cl at linux.com  Mon Dec 18 09:49:57 2023
From: cl at linux.com (Christoph Lameter (Ampere))
Date: Mon, 18 Dec 2023 09:49:57 -0800 (PST)
Subject: [PATCH] ARM64: Implement arch_report_meminfo()
In-Reply-To: <1a8ef5e3-e478-492f-8f4d-05cc16945593@arm.com>
References: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org> <b0d7b928-ecc5-4203-8269-423dee08b1ff@arm.com> <bc9c1287-6b20-8463-50c1-678b7634cca6@linux.com> <1a8ef5e3-e478-492f-8f4d-05cc16945593@arm.com>
Message-ID: <e7244bc8-7bf7-de2c-83ab-7b4e8f2ea87a@linux.com>

On Fri, 15 Dec 2023, Robin Murphy wrote:

> On 14/12/2023 9:35 pm, Christoph Lameter (Ampere) wrote:
>> On Thu, 14 Dec 2023, Robin Murphy wrote:
>> 
>>> It seems somewhat suspect that these counts only ever increase. It's not 
>>> often that we change or remove parts of the linear map, but it certainly 
>>> can happen.
>> 
>> Well yes in the case of hotplug I guess ... Ok here is V2
>
> There are also paths where we remove and reinstate parts of the linear map 
> via set_memory_valid(), set_direct_map_*(), and possibly others. If we're 
> exposing a user ABI that claims to be accounting kernel VA mappings, then I 
> think users are within their rights to expect it to actually account kernel 
> VA mappings, not just expose numbers whose only guaranteed significance is 
> whether they are zero or nonzero.

set_memory_valid() changes mappings via __change_memory_common()
and apply_to_page_range(). It seems that apply_to_page range() creates
PTEs as needed etc.

However, I do not see any accounting for direct map modification 
accounting on x86 either. Since this was satifactory for x86 I dont 
believe that more is needed. Introducing atomics in potentially 
performance sensitive functions run when the kernel is up is not that 
advisable and doing so would require core kernel changes going beyond the 
enablement of arch_report_meminfo() on ARM64.

> Looking again, am I also right in thinking that what I assumed were the 
> non-contiguous counts here are actually total counts of *either* type of 
> mapping at that level, and inclusive of the contiguous counts? If so, that 
> seems a bit non-obvious - my intuitive expectation would be for the sum of 
> all these numbers to represent the total amount of direct-mapped RAM, where 
> either we're intersted in each distinct type of mapping and accounting them 
> all separately, or we're simply interested in the general shape of the 
> pagetables, and thus would account per-level and ignore the contiguous bit 
> since we don't know whether it's actually doing anything useful anyweay

Yes, the CONT PTEs are a subset of the other counts since they are only a 
special case of the PTE type. They are important for performance on ARM64 
in particular with the anticipated use of them for the various sizes of 
pages supported in the kernel with the introduction of folios for the page 
cache.

The problem with CONT_PTE is that it is not clear whether the architecture 
supports it or now. The amount of CONT_PTE can influence the TLB coverage 
possible in kernel space.

We are generally interested in the shape of the page tables. If the user 
later uses processes that require a degradation through smaller mappings 
then that is load dependent.



From william.gray at linaro.org  Mon Dec 18 09:58:28 2023
From: william.gray at linaro.org (William Breathitt Gray)
Date: Mon, 18 Dec 2023 12:58:28 -0500
Subject: [PATCH v2 5/6] counter: stm32-timer-cnt: populate capture
 channels and check encoder
In-Reply-To: <997c056e-c4e1-4bd8-9fcd-9f1b4bd45929@foss.st.com>
References: <20230922143920.3144249-1-fabrice.gasnier@foss.st.com>
 <20230922143920.3144249-6-fabrice.gasnier@foss.st.com>
 <ZSnJR2yfYsBNHu/4@fedora>
 <997c056e-c4e1-4bd8-9fcd-9f1b4bd45929@foss.st.com>
Message-ID: <ZYCIRHVVTDD_k0Wk@ishi>

On Fri, Dec 15, 2023 at 06:13:51PM +0100, Fabrice Gasnier wrote:
> >> +	/*
> >> +	 * Handle diversity for stm32 timers features. For now encoder is found with
> >> +	 * advanced timers or gp timers with 4 channels. Timers with less channels
> >> +	 * doesn't support encoder.
> >> +	 */
> >> +	switch (priv->nchannels) {
> >> +	case 4:
> >> +		if (priv->has_encoder)
> >> +			counter->counts = &stm32_counts_enc_4ch;
> >> +		else
> >> +			counter->counts = &stm32_counts_4ch;
> >> +		counter->signals = stm32_signals;
> >> +		counter->num_signals = ARRAY_SIZE(stm32_signals);
> >> +		break;
> >> +	case 2:
> >> +		counter->counts = &stm32_counts_2ch;
> >> +		counter->signals = stm32_signals;
> >> +		counter->num_signals = 3; /* clock, ch1 and ch2 */
> >> +		break;
> >> +	case 1:
> >> +		counter->counts = &stm32_counts_1ch;
> >> +		counter->signals = stm32_signals;
> >> +		counter->num_signals = 2; /* clock, ch1 */
> >> +		break;
> >> +	default:
> >> +		counter->counts = &stm32_counts;
> >> +		counter->signals = stm32_signals;
> >> +		counter->num_signals = 1; /* clock */
> >> +		break;
> >> +	}
> > 
> > Rather than adjusting the number of counts and signals, keep the
> > configuration static and use a single stm32_counts array. The reason is
> > that in the Counter subsystem paradigm Signals do not necessary
> > correlate to specific hardware signals but are rather an abstract
> > representation of the device behavior at a high level. In other words, a
> > Synapse with an action mode set to COUNTER_SYNAPSE_ACTION_NONE can be
> > viewed as representing a Signal that does not affect the Count (i.e. in
> > this case equivalent to an unconnected line).
> > 
> > What you'll need to do instead is check priv->nchannels during
> > stm32_action_read and stm32_count_function_read calls in order to return
> > the correct synapse action and count function for the particular
> > channels configuration you have. In stm32_count_function_write you would
> > return an -EINVAL (maybe -EOPNOTSUPP would be better?) when the channels
> > configuration does not support a particular count function.
> 
> Hi William,
> 
> Sorry for the long delay to address your comments here. Many thanks for
> these guidelines.
> 
> I'm preparing a v3, to address these. I'll probably send it soon, so we
> can start to review also the capture part of it. Still there are few
> things here I'm wondering about (as an anticipation task).
> 
> Basically, removing all the diversity here means the most featured timer
> model will be represented here (with all possible signals).
> When I wrote the various configuration arrays, I'd have been tempted to
> allocate them dynamically upon probing to avoid having all these
> variants described as const arrays. This may have eased other signals
> additions later. But that's not the direction. So, this simplifies the
> description here, clearly, to describe the full-featured timer/counter,
> and handle the ("unconnected") variants by returning errors.
> 
> I still have in mind the replacement of the last IIO_COUNT device [1]
> (not addressed in this series), e.g. in
> drivers/iio/trigger/stm32-timer-trigger.c. Here, there are
> "valids_table" that are used to cascade two timers (one timer output
> being the input to another timer). With this table currently, an IIO
> user knows the name of the signal it selects (then the driver looks up
> the 'valids' table to set SMCR / TS bits, e.g. trigger select). Each
> individual timer has a different input mapping, so called peripheral
> interconnect in STM32.
> What bothers me here is: with an abstracted full-featured timer, without
> any diversity on the signal names, I fear the userland has no clue on
> which signal would be used. Abstracting the timer this way would mean
> the user only knows it selects "Internal Trigger 0" for example, without
> knowing which internal signal in the SoC it has selected.
> 
> Even if this is out of scope for this series, would you have some clue
> so I can anticipate it ? Or if we stick with abstract names? In which
> case the userland may need to be aware of the signals mapping (where
> currently in IIO_COUNT driver, the signal names are privided). I'd be
> glad to get some direction here.
> 
> Please advise,
> Best Regards,
> Fabrice
> 
> [1] https://lore.kernel.org/linux-arm-kernel/Y0vzlOmFrVCQVXMq at fedora/

Hi Fabrice,

I took a look the stm32-timer-trigger.c file, but I'm having trouble
understanding it well (probably the cascading is confusing me). If I
understand the logic correctly, the user selects the trigger they want
by the attribute's name which is compared via strncmp() against the
'valids' table. It's possible we could dynamically configure the signal
names, but keep the signal id static so the driver code won't need some
many variations; alternatively, we could introduce a new signal
extension attribute that could display the trigger name.

Would you walk me through an example of using the stm32-timer-trigger
IIO sysfs interface? I think that would help me understand how users
currently interact with the triggers for that driver, and then maybe I
can figure out an appropriate equivalent in the Counter paradigm for
the migration. Right now, the timer cascade is confusing me so if I can
grok it well, the right solution for this may come to me more easily.

Thanks,

William Breathitt Gray
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/7b0eb0da/attachment-0001.sig>

From nmorrisson at phytec.com  Mon Dec 18 10:47:38 2023
From: nmorrisson at phytec.com (Nathan Morrisson)
Date: Mon, 18 Dec 2023 10:47:38 -0800
Subject: [PATCH 0/2] *** Add fixed-paritions to phyCORE-AM62x and
 phyCORE-AM64x ***
In-Reply-To: <9f86870c-88cc-43ea-800c-3a05482953aa@ti.com>
References: <20231215191838.1925082-1-nmorrisson@phytec.com>
 <9f86870c-88cc-43ea-800c-3a05482953aa@ti.com>
Message-ID: <d03e3dfc-ba3c-4474-8094-94c5557021f2@phytec.com>

Hi Andrew,

We are adding the nodes directly to the device tree to match what is 
done in other device trees, for example: k3-am642-tqma64xxl.dtsi. You 
are correct that this could be done by the bootloader instead though. 
Why do you prefer having the bootloader add the nodes?

Regards,

Nathan

On 12/15/23 11:20 AM, Andrew Davis wrote:
> On 12/15/23 1:18 PM, Nathan Morrisson wrote:
>> Add a fixed-partitions node to the NOR flash of the phyCORE-AM62x
>> and phyCORE-AM64x to enable the bootloader to fixup the partitions
>> during boot.
>>
>
> Why can't your bootloader add these nodes?
>
> Andrew
>
>> Nathan Morrisson (2):
>> ?? arm64: dts: ti: k3-am62-phycore-som: Add fixed-partitions to NOR 
>> Flash
>> ?? arm64: dts: ti: k3-am64-phycore-som: Add fixed-partitions to NOR 
>> Flash
>>
>> ? arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi | 6 ++++++
>> ? arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi | 6 ++++++
>> ? 2 files changed, 12 insertions(+)
>>


From afd at ti.com  Mon Dec 18 11:41:31 2023
From: afd at ti.com (Andrew Davis)
Date: Mon, 18 Dec 2023 13:41:31 -0600
Subject: [PATCH 0/2] *** Add fixed-paritions to phyCORE-AM62x and
 phyCORE-AM64x ***
In-Reply-To: <d03e3dfc-ba3c-4474-8094-94c5557021f2@phytec.com>
References: <20231215191838.1925082-1-nmorrisson@phytec.com>
 <9f86870c-88cc-43ea-800c-3a05482953aa@ti.com>
 <d03e3dfc-ba3c-4474-8094-94c5557021f2@phytec.com>
Message-ID: <849f7785-547c-4add-8bfd-c04608b3fbab@ti.com>

On 12/18/23 12:47 PM, Nathan Morrisson wrote:
> Hi Andrew,
> 
> We are adding the nodes directly to the device tree to match what is done in other device trees, for example: k3-am642-tqma64xxl.dtsi. You are correct that this could be done by the bootloader instead though. Why do you prefer having the bootloader add the nodes?
> 

k3-am642-tqma64xxl.dtsi should be fixed, it slipped past me and
shouldn't be used as a reference.

The bootloader might not fill it out at all, what if we start
using the new MTD GPT partitions? Then the new bootloaders
will have to start *removing* these stale half-nodes.

If the bootloader is going to add fixed partitions it should do
the whole job. There is no good reason to have a half complete
nodes here.

Andrew

> Regards,
> 
> Nathan
> 
> On 12/15/23 11:20 AM, Andrew Davis wrote:
>> On 12/15/23 1:18 PM, Nathan Morrisson wrote:
>>> Add a fixed-partitions node to the NOR flash of the phyCORE-AM62x
>>> and phyCORE-AM64x to enable the bootloader to fixup the partitions
>>> during boot.
>>>
>>
>> Why can't your bootloader add these nodes?
>>
>> Andrew
>>
>>> Nathan Morrisson (2):
>>> ?? arm64: dts: ti: k3-am62-phycore-som: Add fixed-partitions to NOR Flash
>>> ?? arm64: dts: ti: k3-am64-phycore-som: Add fixed-partitions to NOR Flash
>>>
>>> ? arch/arm64/boot/dts/ti/k3-am62-phycore-som.dtsi | 6 ++++++
>>> ? arch/arm64/boot/dts/ti/k3-am64-phycore-som.dtsi | 6 ++++++
>>> ? 2 files changed, 12 insertions(+)
>>>


From oliver.upton at linux.dev  Mon Dec 18 11:51:15 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Mon, 18 Dec 2023 19:51:15 +0000
Subject: [PATCH v11 00/43] KVM: arm64: Nested Virtualization support
 (FEAT_NV2 only)
In-Reply-To: <86sf3zadmp.wl-maz@kernel.org>
References: <20231120131027.854038-1-maz@kernel.org>
 <86sf3zadmp.wl-maz@kernel.org>
Message-ID: <ZYCis7lNTYouBQnU@linux.dev>

On Mon, Dec 18, 2023 at 12:39:26PM +0000, Marc Zyngier wrote:
> On Mon, 20 Nov 2023 13:09:44 +0000,
> Marc Zyngier <maz at kernel.org> wrote:
> > 
> > This is the 5th drop of NV support on arm64 for this year, and most
> > probably the last one for this side of Christmas.
> 
> Unless someone objects, I'm planning to take the first 10 patches of
> this series into 6.8 (with the dependency on ID_AA64MMFR4_EL1.NV_frac
> in patch #1 removed).

For the first 10 patches:

Reviewed-by: Oliver Upton <oliver.upton at linux.dev>

-- 
Thanks,
Oliver


From jernej.skrabec at gmail.com  Mon Dec 18 11:56:08 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Mon, 18 Dec 2023 20:56:08 +0100
Subject: [PATCH 6/7] crypto: sun8i-ce - Use helper to set reqsize
In-Reply-To: <20231218164649.2492465-6-ovidiu.panait@windriver.com>
References: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
 <20231218164649.2492465-6-ovidiu.panait@windriver.com>
Message-ID: <4532392.LvFx2qVVIh@jernej-laptop>

Dne ponedeljek, 18. december 2023 ob 17:46:48 CET je ovidiu.panait at windriver.com napisal(a):
> From: Ovidiu Panait <ovidiu.panait at windriver.com>
> 
> The value of reqsize must only be changed through the helper.
> 
> Signed-off-by: Ovidiu Panait <ovidiu.panait at windriver.com>

Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>

Best regards,
Jernej




From jernej.skrabec at gmail.com  Mon Dec 18 11:56:29 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Mon, 18 Dec 2023 20:56:29 +0100
Subject: [PATCH 7/7] crypto: sun8i-ss - Use helper to set reqsize
In-Reply-To: <20231218164649.2492465-7-ovidiu.panait@windriver.com>
References: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
 <20231218164649.2492465-7-ovidiu.panait@windriver.com>
Message-ID: <4854975.GXAFRqVoOG@jernej-laptop>

Dne ponedeljek, 18. december 2023 ob 17:46:49 CET je ovidiu.panait at windriver.com napisal(a):
> From: Ovidiu Panait <ovidiu.panait at windriver.com>
> 
> The value of reqsize must only be changed through the helper.
> 
> Signed-off-by: Ovidiu Panait <ovidiu.panait at windriver.com>

Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>

Best regards,
Jernej




From rafael at kernel.org  Mon Dec 18 12:17:34 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 18 Dec 2023 21:17:34 +0100
Subject: [PATCH RFC v3 02/21] ACPI: processor: Add support for processors
 described as container packages
In-Reply-To: <E1rDOfx-00Dvje-MS@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk> <E1rDOfx-00Dvje-MS@rmk-PC.armlinux.org.uk>
Message-ID: <CAJZ5v0iB0bS6nmjQ++pV1zp5YSGuigbffK5VD3wsX+8bY9MA5w@mail.gmail.com>

On Wed, Dec 13, 2023 at 1:49?PM Russell King <rmk+kernel at armlinux.org.uk> wrote:
>
> From: James Morse <james.morse at arm.com>
>
> ACPI has two ways of describing processors in the DSDT. From ACPI v6.5,
> 5.2.12:
>
> "Starting with ACPI Specification 6.3, the use of the Processor() object
> was deprecated. Only legacy systems should continue with this usage. On
> the Itanium architecture only, a _UID is provided for the Processor()
> that is a string object. This usage of _UID is also deprecated since it
> can preclude an OSPM from being able to match a processor to a
> non-enumerable device, such as those defined in the MADT. From ACPI
> Specification 6.3 onward, all processor objects for all architectures
> except Itanium must now use Device() objects with an _HID of ACPI0007,
> and use only integer _UID values."
>
> Also see https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html#declaring-processors
>
> Duplicate descriptions are not allowed, the ACPI processor driver already
> parses the UID from both devices and containers. acpi_processor_get_info()
> returns an error if the UID exists twice in the DSDT.

I'm not really sure how the above is related to the actual patch.

> The missing probe for CPUs described as packages

It is unclear what exactly is meant by "CPUs described as packages".

>From the patch, it looks like those would be Processor() objects
defined under a processor container device.

> creates a problem for
> moving the cpu_register() calls into the acpi_processor driver, as CPUs
> described like this don't get registered, leading to errors from other
> subsystems when they try to add new sysfs entries to the CPU node.
> (e.g. topology_sysfs_init()'s use of topology_add_dev() via cpuhp)
>
> To fix this, parse the processor container and call acpi_processor_add()
> for each processor that is discovered like this.

Discovered like what?

> The processor container
> handler is added with acpi_scan_add_handler(), so no detach call will
> arrive.

The above requires clarification too.

> Qemu TCG describes CPUs using processor devices in a processor container.
> For more information, see build_cpus_aml() in Qemu hw/acpi/cpu.c and
> https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html#processor-container-device
>
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> ---
> Outstanding comments:
>  https://lore.kernel.org/r/20230914145353.000072e2 at Huawei.com
>  https://lore.kernel.org/r/50571c2f-aa3c-baeb-3add-cd59e0eddc02 at redhat.com
> ---
>  drivers/acpi/acpi_processor.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index 4fe2ef54088c..6a542e0ce396 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -626,9 +626,31 @@ static struct acpi_scan_handler processor_handler = {
>         },
>  };
>
> +static acpi_status acpi_processor_container_walk(acpi_handle handle,
> +                                                u32 lvl,
> +                                                void *context,
> +                                                void **rv)
> +{
> +       struct acpi_device *adev;
> +       acpi_status status;
> +
> +       adev = acpi_get_acpi_dev(handle);
> +       if (!adev)
> +               return AE_ERROR;

Why is the reference counting needed here?

Wouldn't acpi_fetch_acpi_dev() suffice?

Also, should the walk really be terminated on the first error?

> +
> +       status = acpi_processor_add(adev, &processor_device_ids[0]);
> +       acpi_put_acpi_dev(adev);
> +
> +       return status;
> +}
> +
>  static int acpi_processor_container_attach(struct acpi_device *dev,
>                                            const struct acpi_device_id *id)
>  {
> +       acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle,
> +                           ACPI_UINT32_MAX, acpi_processor_container_walk,
> +                           NULL, NULL, NULL);

This covers processor objects only, so why is this not needed for
processor devices defined under a processor container object?

It is not obvious, so it would be nice to add a comment explaining the
difference.

> +
>         return 1;
>  }
>
> --


From rafael at kernel.org  Mon Dec 18 12:22:03 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 18 Dec 2023 21:22:03 +0100
Subject: [PATCH RFC v3 03/21] ACPI: processor: Register CPUs that are
 online, but not described in the DSDT
In-Reply-To: <E1rDOg2-00Dvjk-RI@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk> <E1rDOg2-00Dvjk-RI@rmk-PC.armlinux.org.uk>
Message-ID: <CAJZ5v0ju1JHgpjuFLHZVs4NZiARG6iBZN_wza6c2e0kDhZjK0w@mail.gmail.com>

On Wed, Dec 13, 2023 at 1:49?PM Russell King <rmk+kernel at armlinux.org.uk> wrote:
>
> From: James Morse <james.morse at arm.com>
>
> ACPI has two descriptions of CPUs, one in the MADT/APIC table, the other
> in the DSDT. Both are required. (ACPI 6.5's 8.4 "Declaring Processors"
> says "Each processor in the system must be declared in the ACPI
> namespace"). Having two descriptions allows firmware authors to get
> this wrong.
>
> If CPUs are described in the MADT/APIC, they will be brought online
> early during boot. Once the register_cpu() calls are moved to ACPI,
> they will be based on the DSDT description of the CPUs. When CPUs are
> missing from the DSDT description, they will end up online, but not
> registered.
>
> Add a helper that runs after acpi_init() has completed to register
> CPUs that are online, but weren't found in the DSDT. Any CPU that
> is registered by this code triggers a firmware-bug warning and kernel
> taint.
>
> Qemu TCG only describes the first CPU in the DSDT, unless cpu-hotplug
> is configured.

So why is this a kernel problem?

> Signed-off-by: James Morse <james.morse at arm.com>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> Reviewed-by: Gavin Shan <gshan at redhat.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> ---
>  drivers/acpi/acpi_processor.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index 6a542e0ce396..0511f2bc10bc 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -791,6 +791,25 @@ void __init acpi_processor_init(void)
>         acpi_pcc_cpufreq_init();
>  }
>
> +static int __init acpi_processor_register_missing_cpus(void)
> +{
> +       int cpu;
> +
> +       if (acpi_disabled)
> +               return 0;
> +
> +       for_each_online_cpu(cpu) {
> +               if (!get_cpu_device(cpu)) {
> +                       pr_err_once(FW_BUG "CPU %u has no ACPI namespace description!\n", cpu);
> +                       add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
> +                       arch_register_cpu(cpu);

Which part of this code is related to ACPI?

> +               }
> +       }
> +
> +       return 0;
> +}
> +subsys_initcall_sync(acpi_processor_register_missing_cpus);
> +
>  #ifdef CONFIG_ACPI_PROCESSOR_CSTATE
>  /**
>   * acpi_processor_claim_cst_control - Request _CST control from the platform.
> --


From acme at kernel.org  Mon Dec 18 12:28:26 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Mon, 18 Dec 2023 17:28:26 -0300
Subject: [PATCH 3/3] perf scripts python: arm-cs-trace-disasm.py: do not
 ignore disam first sample
In-Reply-To: <20231214123304.34087-4-tianruidong@linux.alibaba.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
 <20231214123304.34087-4-tianruidong@linux.alibaba.com>
Message-ID: <ZYCraiG_hpwBg9CH@kernel.org>

Em Thu, Dec 14, 2023 at 08:33:04PM +0800, Ruidong Tian escreveu:
> arm-cs-trace-disasm ignore disam the first branch sample, For example as
> follow, the instructions beteween 0x0000ffffae878750 and
> 0x0000ffffae878754 is lose:

Leo, Mathieu, Tor, Al, can you guys take a look and provide an Acked or
Reviewed-by tag?

Thanks,

- Arnaldo
 
>   ARM CoreSight Trace Data Assembler Dump
>   Event type: branches:uH
>   Sample = { cpu: 0000 addr: 0x0000ffffae878750 phys_addr: 0x0000000000000000 ip: 0x0000000000000000 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
>   Event type: branches:uH
>   Sample = { cpu: 0000 addr: 0x0000000000000000 phys_addr: 0x0000000000000000 ip: 0x0000ffffae878754 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
> 
> Initialize cpu_data earlier to fix it:
> 
>   ARM CoreSight Trace Data Assembler Dump
>   Event type: branches:uH
>   Sample = { cpu: 0000 addr: 0x0000000000000000 phys_addr: 0x0000000000000000 ip: 0x0000ffffae878754 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
>         0000000000028740 <ioctl>: (base address is 0x0000ffffae850000)
>            28750: b13ffc1f      cmn     x0, #4095
>            28754: 54000042      b.hs    0x2875c <ioctl+0x1c>
>             test 4003489/4003489 [0000]     26765.151766034  __GI___ioctl+0x14                        /usr/lib64/libc-2.32.so
>   Event type: branches:uH
>   Sample = { cpu: 0000 addr: 0x0000ffffa67535ac phys_addr: 0x0000000000000000 ip: 0x0000000000000000 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
> 
> Signed-off-by: Ruidong Tian <tianruidong at linux.alibaba.com>
> ---
>  .../scripts/python/arm-cs-trace-disasm.py     | 21 ++++++++++---------
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> index c9e14af5b58c..b1eb4293cbef 100755
> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> @@ -190,6 +190,17 @@ def process_event(param_dict):
>  	dso_end = get_optional(param_dict, "dso_map_end")
>  	symbol = get_optional(param_dict, "symbol")
>  
> +	cpu = sample["cpu"]
> +	ip = sample["ip"]
> +	addr = sample["addr"]
> +
> +	# Initialize CPU data if it's empty, and directly return back
> +	# if this is the first tracing event for this CPU.
> +	if (cpu_data.get(str(cpu) + 'addr') == None):
> +		cpu_data[str(cpu) + 'addr'] = addr
> +		return
> +
> +
>  	if (options.verbose == True):
>  		print("Event type: %s" % name)
>  		print_sample(sample)
> @@ -211,16 +222,6 @@ def process_event(param_dict):
>  	if (name[0:8] != "branches"):
>  		return
>  
> -	cpu = sample["cpu"]
> -	ip = sample["ip"]
> -	addr = sample["addr"]
> -
> -	# Initialize CPU data if it's empty, and directly return back
> -	# if this is the first tracing event for this CPU.
> -	if (cpu_data.get(str(cpu) + 'addr') == None):
> -		cpu_data[str(cpu) + 'addr'] = addr
> -		return
> -
>  	# The format for packet is:
>  	#
>  	#		  +------------+------------+------------+
> -- 
> 2.33.1
> 
> 

-- 

- Arnaldo


From rafael at kernel.org  Mon Dec 18 12:30:50 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 18 Dec 2023 21:30:50 +0100
Subject: [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from acpi_processor_get_info()
In-Reply-To: <E1rDOg7-00Dvjq-VZ@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk> <E1rDOg7-00Dvjq-VZ@rmk-PC.armlinux.org.uk>
Message-ID: <CAJZ5v0je=-oVnSumZs=dzcyVuVUeVeTgO7yOnjGg1igyrS7EHQ@mail.gmail.com>

On Wed, Dec 13, 2023 at 1:49?PM Russell King <rmk+kernel at armlinux.org.uk> wrote:
>
> From: James Morse <james.morse at arm.com>
>
> To allow ACPI to skip the call to arch_register_cpu() when the _STA
> value indicates the CPU can't be brought online right now, move the
> arch_register_cpu() call into acpi_processor_get_info().

This kind of looks backwards to me and has a potential to become
super-confusing.

I would instead add a way for the generic code to ask the platform
firmware whether or not the given CPU is enabled and so it can be
registered.

> Systems can still be booted with 'acpi=off', or not include an
> ACPI description at all. For these, the CPUs continue to be
> registered by cpu_dev_register_generic().
>
> This moves the CPU register logic back to a subsys_initcall(),
> while the memory nodes will have been registered earlier.

Isn't this somewhat risky?

> Signed-off-by: James Morse <james.morse at arm.com>
> Reviewed-by: Gavin Shan <gshan at redhat.com>
> Tested-by: Miguel Luis <miguel.luis at oracle.com>
> Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> ---
> Changes since RFC v2:
>  * Fixup comment in acpi_processor_get_info() (Gavin Shan)
>  * Add comment in cpu_dev_register_generic() (Gavin Shan)
> ---
>  drivers/acpi/acpi_processor.c | 12 ++++++++++++
>  drivers/base/cpu.c            |  6 +++++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index 0511f2bc10bc..e7ed4730cbbe 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -314,6 +314,18 @@ static int acpi_processor_get_info(struct acpi_device *device)
>                         cpufreq_add_device("acpi-cpufreq");
>         }
>
> +       /*
> +        * Register CPUs that are present. get_cpu_device() is used to skip
> +        * duplicate CPU descriptions from firmware.
> +        */
> +       if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id) &&
> +           !get_cpu_device(pr->id)) {
> +               int ret = arch_register_cpu(pr->id);
> +
> +               if (ret)
> +                       return ret;
> +       }
> +
>         /*
>          *  Extra Processor objects may be enumerated on MP systems with
>          *  less than the max # of CPUs. They should be ignored _iff
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index 47de0f140ba6..13d052bf13f4 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -553,7 +553,11 @@ static void __init cpu_dev_register_generic(void)
>  {
>         int i, ret;
>
> -       if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES))
> +       /*
> +        * When ACPI is enabled, CPUs are registered via
> +        * acpi_processor_get_info().
> +        */
> +       if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES) || !acpi_disabled)
>                 return;
>
>         for_each_present_cpu(i) {
> --
> 2.30.2
>
>


From acme at kernel.org  Mon Dec 18 12:34:54 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Mon, 18 Dec 2023 17:34:54 -0300
Subject: [PATCH v1 10/14] perf top: Avoid repeated function calls
In-Reply-To: <e067c360-56ac-1756-3b3b-4bf5f663be87@arm.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-11-irogers@google.com>
 <e067c360-56ac-1756-3b3b-4bf5f663be87@arm.com>
Message-ID: <ZYCs7mh3GgvNz2-A@kernel.org>

Em Tue, Dec 12, 2023 at 03:11:53PM +0000, James Clark escreveu:
> 
> 
> On 29/11/2023 06:02, Ian Rogers wrote:
> > Add a local variable to avoid repeated calls to perf_cpu_map__nr.
> > 
> > Signed-off-by: Ian Rogers <irogers at google.com>
> 
> Reviewed-by: James Clark <james.clark at arm.com>

Thanks, applied to perf-tools-next.

- Arnaldo

 
> > ---
> >  tools/perf/util/top.c | 9 ++++-----
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> > 
> > diff --git a/tools/perf/util/top.c b/tools/perf/util/top.c
> > index be7157de0451..4db3d1bd686c 100644
> > --- a/tools/perf/util/top.c
> > +++ b/tools/perf/util/top.c
> > @@ -28,6 +28,7 @@ size_t perf_top__header_snprintf(struct perf_top *top, char *bf, size_t size)
> >  	struct record_opts *opts = &top->record_opts;
> >  	struct target *target = &opts->target;
> >  	size_t ret = 0;
> > +	int nr_cpus;
> >  
> >  	if (top->samples) {
> >  		samples_per_sec = top->samples / top->delay_secs;
> > @@ -93,19 +94,17 @@ size_t perf_top__header_snprintf(struct perf_top *top, char *bf, size_t size)
> >  	else
> >  		ret += SNPRINTF(bf + ret, size - ret, " (all");
> >  
> > +	nr_cpus = perf_cpu_map__nr(top->evlist->core.user_requested_cpus);
> >  	if (target->cpu_list)
> >  		ret += SNPRINTF(bf + ret, size - ret, ", CPU%s: %s)",
> > -				perf_cpu_map__nr(top->evlist->core.user_requested_cpus) > 1
> > -				? "s" : "",
> > +				nr_cpus > 1 ? "s" : "",
> >  				target->cpu_list);
> >  	else {
> >  		if (target->tid)
> >  			ret += SNPRINTF(bf + ret, size - ret, ")");
> >  		else
> >  			ret += SNPRINTF(bf + ret, size - ret, ", %d CPU%s)",
> > -					perf_cpu_map__nr(top->evlist->core.user_requested_cpus),
> > -					perf_cpu_map__nr(top->evlist->core.user_requested_cpus) > 1
> > -					? "s" : "");
> > +					nr_cpus, nr_cpus > 1 ? "s" : "");
> >  	}
> >  
> >  	perf_top__reset_sample_counters(top);
> 

-- 

- Arnaldo


From rafael at kernel.org  Mon Dec 18 12:35:16 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 18 Dec 2023 21:35:16 +0100
Subject: [PATCH RFC v3 05/21] ACPI: Rename ACPI_HOTPLUG_CPU to include 'present'
In-Reply-To: <E1rDOgD-00Dvk2-3h@rmk-PC.armlinux.org.uk>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk> <E1rDOgD-00Dvk2-3h@rmk-PC.armlinux.org.uk>
Message-ID: <CAJZ5v0g9nfLrEf9u4Ksw6BOWJQ9iv8Z-O8RsLU6jR5zk0ahxRw@mail.gmail.com>

On Wed, Dec 13, 2023 at 1:49?PM Russell King <rmk+kernel at armlinux.org.uk> wrote:
>
> From: James Morse <james.morse at arm.com>
>
> The code behind ACPI_HOTPLUG_CPU allows a not-present CPU to become
> present.

Right.

> This isn't the only use of HOTPLUG_CPU. On arm64 and riscv
> CPUs can be taken offline as a power saving measure.

But still there is the case in which a non-present CPU can become
present, isn't it there?

> On arm64 an offline CPU may be disabled by firmware, preventing it from
> being brought back online, but it remains present throughout.
>
> Adding code to prevent user-space trying to online these disabled CPUs
> needs some additional terminology.
>
> Rename the Kconfig symbol CONFIG_ACPI_HOTPLUG_PRESENT_CPU to reflect
> that it makes possible CPUs present.

Honestly, I don't think that this change is necessary or even useful.


From acme at kernel.org  Mon Dec 18 12:36:39 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Mon, 18 Dec 2023 17:36:39 -0300
Subject: [PATCH v1 14/14] libperf cpumap: Document perf_cpu_map__nr's
 behavior
In-Reply-To: <0e1ca950-b5a4-1e08-8696-4e3e12e21b19@arm.com>
References: <20231129060211.1890454-1-irogers@google.com>
 <20231129060211.1890454-15-irogers@google.com>
 <0e1ca950-b5a4-1e08-8696-4e3e12e21b19@arm.com>
Message-ID: <ZYCtV6YcDLpgau75@kernel.org>

Em Tue, Dec 12, 2023 at 03:20:47PM +0000, James Clark escreveu:
> On 29/11/2023 06:02, Ian Rogers wrote:
> >  LIBPERF_API void perf_cpu_map__put(struct perf_cpu_map *map);
> > +/**
> > + * perf_cpu_map__cpu - get the CPU value at the given index. Returns -1 if index
> > + *                     is invalid.
> > + */
> >  LIBPERF_API struct perf_cpu perf_cpu_map__cpu(const struct perf_cpu_map *cpus, int idx);
> > +/**
> > + * perf_cpu_map__nr - for an empty map returns 1, as perf_cpu_map__cpu returns a
> > + *                    cpu of -1 for an invalid index, this makes an empty map
> > + *                    look like it contains the "any CPU"/dummy value. Otherwise
> > + *                    the result is the number CPUs in the map plus one if the
> > + *                    "any CPU"/dummy value is present.
> 
> Hmmm... I'm not sure whether to laugh or cry at that API.
> 
> Reviewed-by: James Clark <james.clark at arm.com>



Thanks, applied to perf-tools-next.

- Arnaldo



From u.kleine-koenig at pengutronix.de  Mon Dec 18 12:47:10 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 18 Dec 2023 21:47:10 +0100
Subject: [PATCH] ACPI: APEI: GHES: Convert to platform remove callback
 returning void
In-Reply-To: <20231122174913.GFZV4/GUKci24sp1oj@fat_crate.local>
References: <20231120173053.49597-1-u.kleine-koenig@pengutronix.de>
 <CAJZ5v0iW_B72o8EMbZaH_x2SOHOvqnieP8EsK2A6d93GRDYtBA@mail.gmail.com>
 <20231122174913.GFZV4/GUKci24sp1oj@fat_crate.local>
Message-ID: <ix7bttqx32bv4hajg7szijtosi5vn43nxduun3fwevccjqrjhh@qrbjvcsuddoi>

Hello James,

On Wed, Nov 22, 2023 at 06:49:13PM +0100, Borislav Petkov wrote:
> On Wed, Nov 22, 2023 at 04:25:30PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Nov 20, 2023 at 6:31?PM Uwe Kleine-K?nig
> > <u.kleine-koenig at pengutronix.de> wrote:
> > >
> > > The .remove() callback for a platform driver returns an int which makes
> > > many driver authors wrongly assume it's possible to do error handling by
> > > returning an error code. However the value returned is ignored (apart
> > > from emitting a warning) and this typically results in resource leaks.
> > >
> > > To improve here there is a quest to make the remove callback return
> > > void. In the first step of this quest all drivers are converted to
> > > .remove_new(), which already returns void. Eventually after all drivers
> > > are converted, .remove_new() will be renamed to .remove().
> > >
> > > Instead of returning an error code, emit a better error message than the
> > > core. Apart from the improved error message this patch has no effects
> > > for the driver.
> > >
> > > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> > > ---
> > > Hello,
> > >
> > > I tried to improve this driver before, see
> > >
> > >         https://lore.kernel.org/linux-acpi/CAJZ5v0ifb-wvyp0JRq_4c1L6vTi_qEeXJ6P=Pmmq_56xRL74_A at mail.gmail.com
> > >         https://lore.kernel.org/linux-arm-kernel/20221219221439.1681770-1-u.kleine-koenig at pengutronix.de
> > >         https://lore.kernel.org/linux-arm-kernel/20221220154447.12341-1-u.kleine-koenig at pengutronix.de
> > >
> > > but this didn't result in any patch being applied.
> > >
> > > I think it's inarguable that there is a problem that wants to be fixed.
> > > My tries to fix this problem fixxled out, so here comes a minimal change
> > > that just points out the problem and otherwise makes ghes_remove()
> > > return void without further side effects to allow me to continue my
> > > quest to make platform_driver remove callbacks return no error.
> > 
> > Tony, Boris, any objections against this patch?
> 
> SDEI is James. Moving him to To:

I wonder if you had a chance to look at this patch.

It doesn't change anything for the SDEI driver, the only effect is to
have one driver less using platform_driver's remove function.

Would be great if that patch made it in.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/79814ac8/attachment.sig>

From jacob.e.keller at intel.com  Mon Dec 18 12:48:20 2023
From: jacob.e.keller at intel.com (Jacob Keller)
Date: Mon, 18 Dec 2023 12:48:20 -0800
Subject: [PATCH net v2 1/1] net: stmmac: fix incorrect flag check in
 timestamp interrupt
In-Reply-To: <1702885892-30369-1-git-send-email-jun.ann.lai@intel.com>
References: <1702885892-30369-1-git-send-email-jun.ann.lai@intel.com>
Message-ID: <159702bf-3bc8-482e-b4f5-65799d330d7f@intel.com>



On 12/17/2023 11:51 PM, Lai Peter Jun Ann wrote:
> The driver should continue get the timestamp if STMMAC_FLAG_EXT_SNAPSHOT_EN
> flag is set.
> 

Reviewed-by: Jacob Keller <jacob.e.keller at intel.com>

> Fixes: aa5513f5d95f ("net: stmmac: replace the ext_snapshot_en field with a flag")
> Cc: <stable at vger.kernel.org> # 6.6
> Signed-off-by: Song Yoong Siang <yoong.siang.song at intel.com>
> Signed-off-by: Lai Peter Jun Ann <jun.ann.lai at intel.com>
> ---
> v2 changelog:
>  - Add fix tag and stable at vger.kernel.org in email cc list.
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> index 540f6a4..f05bd75 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> @@ -237,7 +237,7 @@ static void timestamp_interrupt(struct stmmac_priv *priv)
>  	 */
>  	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
>  
> -	if (priv->plat->flags & STMMAC_FLAG_EXT_SNAPSHOT_EN)
> +	if (!(priv->plat->flags & STMMAC_FLAG_EXT_SNAPSHOT_EN))
>  		return;
>  
>  	num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>


From kamal.dasu at broadcom.com  Mon Dec 18 13:07:03 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Mon, 18 Dec 2023 16:07:03 -0500
Subject: [PATCH v4 0/2] mmc: add new sdhci reset sequence for brcm 74165b0
Message-ID: <20231218210705.38201-1-kamal.dasu@broadcom.com>

v4 changes:
 - Fix for v3 changes that introduced dt schema errors
 - Fix for v3 changes that introduced sdhci-brcmstb build warnings 
 - Added proper PATCH format and cleanup commit messages as per
   review comments. Added proper 'Reported-by' and 'Closes' tags
 - Added comments for 32-bit register access as per review comments
 - Replaced wait loop polling with readb_poll_timeout() helper as per
   review comments for the sdhci-brcmstb driver changes
 
v3 changes:
 - Removed extra emun arrayfor possible compatible strings
 - shdci-brcmstb checkpatch warning fixes 

v2 changes:
 - Fixed devicetree bindings for shdci-brcmstb and removed 74165 compatible
   string as per review comments

Kamal Dasu (2):
  dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
  mmc: add new sdhci reset sequence for brcm 74165b0

 .../bindings/mmc/brcm,sdhci-brcmstb.yaml      |  4 +-
 drivers/mmc/host/sdhci-brcmstb.c              | 67 +++++++++++++++++--
 2 files changed, 63 insertions(+), 8 deletions(-)

-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/1b3bd1b0/attachment.p7s>

From kamal.dasu at broadcom.com  Mon Dec 18 13:07:04 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Mon, 18 Dec 2023 16:07:04 -0500
Subject: [PATCH v4 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
In-Reply-To: <20231218210705.38201-1-kamal.dasu@broadcom.com>
References: <20231218210705.38201-1-kamal.dasu@broadcom.com>
Message-ID: <20231218210705.38201-2-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

With newer sdio controller core used for 74165b0 we need to update
the compatibility with "brcm,bcm74165b0-sdhci".

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312101146.IK4Nrw1S-lkp at intel.com/
---
 Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
index c028039bc477..cbd3d6c6c77f 100644
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
+++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
@@ -20,10 +20,8 @@ properties:
           - const: brcm,sdhci-brcmstb
       - items:
           - enum:
+              - brcm,bcm74165b0-sdhci
               - brcm,bcm7445-sdhci
-          - const: brcm,sdhci-brcmstb
-      - items:
-          - enum:
               - brcm,bcm7425-sdhci
           - const: brcm,sdhci-brcmstb
 
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/02be8796/attachment.p7s>

From kamal.dasu at broadcom.com  Mon Dec 18 13:07:05 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Mon, 18 Dec 2023 16:07:05 -0500
Subject: [PATCH v4 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231218210705.38201-1-kamal.dasu@broadcom.com>
References: <20231218210705.38201-1-kamal.dasu@broadcom.com>
Message-ID: <20231218210705.38201-3-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

74165b0 shall use a new sdio controller core version which
requires a different reset sequence. For core reset we use
sdhci_reset. For CMD and/or DATA reset added a new function
to also enable SDHCI clocks SDHCI_CLOCK_CARD_EN
SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
SDHCI_RESET_DATA fields.

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312091608.0VbkRxlh-lkp at intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202312091905.UGzltx8A-lkp at intel.com/
---
 drivers/mmc/host/sdhci-brcmstb.c | 67 +++++++++++++++++++++++++++++---
 1 file changed, 62 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index c23251bb95f3..7c5d04be93b3 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -6,6 +6,7 @@
  */
 
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/mmc/host.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -44,8 +45,13 @@ struct brcmstb_match_priv {
 
 static inline void enable_clock_gating(struct sdhci_host *host)
 {
+	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
 	u32 reg;
 
+	if (!(priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK))
+		return;
+
 	reg = sdhci_readl(host, SDHCI_VENDOR);
 	reg |= SDHCI_VENDOR_GATE_SDCLK_EN;
 	sdhci_writel(host, reg, SDHCI_VENDOR);
@@ -53,14 +59,51 @@ static inline void enable_clock_gating(struct sdhci_host *host)
 
 static void brcmstb_reset(struct sdhci_host *host, u8 mask)
 {
-	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
-
 	sdhci_and_cqhci_reset(host, mask);
 
 	/* Reset will clear this, so re-enable it */
-	if (priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK)
-		enable_clock_gating(host);
+	enable_clock_gating(host);
+}
+
+static void brcmstb_sdhci_reset_cmd_data(struct sdhci_host *host, u8 mask)
+{
+	int ret;
+	u32 reg;
+	u32 new_mask = (mask &  (SDHCI_RESET_CMD | SDHCI_RESET_DATA)) << 24;
+
+	/*
+	 * SDHCI_CLOCK_CONTROL register CARD_EN and CLOCK_INT_EN bits shall
+	 * be set along with SOFTWARE_RESET register RESET_CMD or RESET_DATA
+	 * bits, hence access SDHCI_CLOCK_CONTROL register as 32-bit register
+	 */
+	new_mask |= SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN;
+	reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
+	sdhci_writel(host, reg | new_mask, SDHCI_CLOCK_CONTROL);
+
+	reg = sdhci_readb(host, SDHCI_SOFTWARE_RESET);
+	ret = readb_poll_timeout(host->ioaddr + SDHCI_SOFTWARE_RESET,
+				 reg, reg & mask, 10, 10000);
+
+	if (ret) {
+		pr_err("%s: Reset 0x%x never completed.\n",
+		       mmc_hostname(host->mmc), (int)mask);
+		sdhci_err_stats_inc(host, CTRL_TIMEOUT);
+		sdhci_dumpregs(host);
+	}
+}
+
+static void brcmstb_reset_74165b0(struct sdhci_host *host, u8 mask)
+{
+	/* take care of RESET_ALL as usual */
+	if (mask & SDHCI_RESET_ALL)
+		sdhci_and_cqhci_reset(host, SDHCI_RESET_ALL);
+
+	/* cmd and/or data treated differently on this core */
+	if (mask & (SDHCI_RESET_CMD | SDHCI_RESET_DATA))
+		brcmstb_sdhci_reset_cmd_data(host, mask);
+
+	/* Reset will clear this, so re-enable it */
+	enable_clock_gating(host);
 }
 
 static void sdhci_brcmstb_hs400es(struct mmc_host *mmc, struct mmc_ios *ios)
@@ -162,6 +205,13 @@ static struct sdhci_ops sdhci_brcmstb_ops_7216 = {
 	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
 };
 
+static struct sdhci_ops sdhci_brcmstb_ops_74165b0 = {
+	.set_clock = sdhci_brcmstb_set_clock,
+	.set_bus_width = sdhci_set_bus_width,
+	.reset = brcmstb_reset_74165b0,
+	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
+};
+
 static struct brcmstb_match_priv match_priv_7425 = {
 	.flags = BRCMSTB_MATCH_FLAGS_NO_64BIT |
 	BRCMSTB_MATCH_FLAGS_BROKEN_TIMEOUT,
@@ -179,10 +229,17 @@ static const struct brcmstb_match_priv match_priv_7216 = {
 	.ops = &sdhci_brcmstb_ops_7216,
 };
 
+static struct brcmstb_match_priv match_priv_74165b0 = {
+	.flags = BRCMSTB_MATCH_FLAGS_HAS_CLOCK_GATE,
+	.hs400es = sdhci_brcmstb_hs400es,
+	.ops = &sdhci_brcmstb_ops_74165b0,
+};
+
 static const struct of_device_id __maybe_unused sdhci_brcm_of_match[] = {
 	{ .compatible = "brcm,bcm7425-sdhci", .data = &match_priv_7425 },
 	{ .compatible = "brcm,bcm7445-sdhci", .data = &match_priv_7445 },
 	{ .compatible = "brcm,bcm7216-sdhci", .data = &match_priv_7216 },
+	{ .compatible = "brcm,bcm74165b0-sdhci", .data = &match_priv_74165b0 },
 	{},
 };
 
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231218/c8a33431/attachment-0001.p7s>

From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:41 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:41 +0200
Subject: [PATCH v4 1/9] dt-bindings: net: starfive,jh7110-dwmac: Drop redundant reset description
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231218214451.2345691-2-cristian.ciocaltea@collabora.com>

The reset description items are already provided by the referenced
snps,dwmac.yaml schema, hence replace them with the necessary
{min,max}Items.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../devicetree/bindings/net/starfive,jh7110-dwmac.yaml       | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 5e7cfbbebce6..d90cb82c1424 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -55,9 +55,8 @@ properties:
     maxItems: 3
 
   resets:
-    items:
-      - description: MAC Reset signal.
-      - description: AHB Reset signal.
+    minItems: 2
+    maxItems: 2
 
   reset-names:
     items:
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:43 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:43 +0200
Subject: [PATCH v4 3/9] net: stmmac: dwmac-starfive: Add support for JH7100 SoC
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231218214451.2345691-4-cristian.ciocaltea@collabora.com>

Add a missing quirk to enable support for the StarFive JH7100 SoC.

Additionally, for greater flexibility in operation, allow using the
rgmii-rxid and rgmii-txid phy modes.

Co-developed-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 ++--
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 ++++++++++++++++---
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 85dcda51df05..4ec61f1ee71a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -165,9 +165,9 @@ config DWMAC_STARFIVE
 	help
 	  Support for ethernet controllers on StarFive RISC-V SoCs
 
-	  This selects the StarFive platform specific glue layer support for
-	  the stmmac device driver. This driver is used for StarFive JH7110
-	  ethernet controller.
+	  This selects the StarFive platform specific glue layer support
+	  for the stmmac device driver. This driver is used for the
+	  StarFive JH7100 and JH7110 ethernet controllers.
 
 config DWMAC_STI
 	tristate "STi GMAC support"
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 5d630affb4d1..4e1076faee0c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -15,13 +15,20 @@
 
 #include "stmmac_platform.h"
 
-#define STARFIVE_DWMAC_PHY_INFT_RGMII	0x1
-#define STARFIVE_DWMAC_PHY_INFT_RMII	0x4
-#define STARFIVE_DWMAC_PHY_INFT_FIELD	0x7U
+#define STARFIVE_DWMAC_PHY_INFT_RGMII		0x1
+#define STARFIVE_DWMAC_PHY_INFT_RMII		0x4
+#define STARFIVE_DWMAC_PHY_INFT_FIELD		0x7U
+
+#define JH7100_SYSMAIN_REGISTER49_DLYCHAIN	0xc8
+
+struct starfive_dwmac_data {
+	unsigned int gtxclk_dlychain;
+};
 
 struct starfive_dwmac {
 	struct device *dev;
 	struct clk *clk_tx;
+	const struct starfive_dwmac_data *data;
 };
 
 static void starfive_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode)
@@ -67,6 +74,8 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 
 	case PHY_INTERFACE_MODE_RGMII:
 	case PHY_INTERFACE_MODE_RGMII_ID:
+	case PHY_INTERFACE_MODE_RGMII_RXID:
+	case PHY_INTERFACE_MODE_RGMII_TXID:
 		mode = STARFIVE_DWMAC_PHY_INFT_RGMII;
 		break;
 
@@ -89,6 +98,14 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 	if (err)
 		return dev_err_probe(dwmac->dev, err, "error setting phy mode\n");
 
+	if (dwmac->data) {
+		err = regmap_write(regmap, JH7100_SYSMAIN_REGISTER49_DLYCHAIN,
+				   dwmac->data->gtxclk_dlychain);
+		if (err)
+			return dev_err_probe(dwmac->dev, err,
+					     "error selecting gtxclk delay chain\n");
+	}
+
 	return 0;
 }
 
@@ -114,6 +131,8 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	if (!dwmac)
 		return -ENOMEM;
 
+	dwmac->data = device_get_match_data(&pdev->dev);
+
 	dwmac->clk_tx = devm_clk_get_enabled(&pdev->dev, "tx");
 	if (IS_ERR(dwmac->clk_tx))
 		return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_tx),
@@ -144,8 +163,13 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
 }
 
+static const struct starfive_dwmac_data jh7100_data = {
+	.gtxclk_dlychain = 4,
+};
+
 static const struct of_device_id starfive_dwmac_match[] = {
-	{ .compatible = "starfive,jh7110-dwmac"	},
+	{ .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
+	{ .compatible = "starfive,jh7110-dwmac" },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:40 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:40 +0200
Subject: [PATCH v4 0/9] Enable networking support for StarFive JH7100 SoC
Message-ID: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>

This patch series adds ethernet support for the StarFive JH7100 SoC and makes it
available for the StarFive VisionFive V1 and BeagleV Starlight boards, although
I could only validate on the former SBC.  Thank you Emil and Geert for helping
with tests on BeagleV!

The work is heavily based on the reference implementation [1] and depends on the
SiFive Composable Cache controller and non-coherent DMA support provided by Emil
via [2] and [3].

*Update*: as of next-20231214, all dependencies have been merged.

[1] https://github.com/starfive-tech/linux/commits/visionfive
[2] https://lore.kernel.org/all/CAJM55Z_pdoGxRXbmBgJ5GbVWyeM1N6+LHihbNdT26Oo_qA5VYA at mail.gmail.com/
[3] https://lore.kernel.org/all/20231130151932.729708-1-emil.renner.berthing at canonical.com/

Changes in v4:
 - Restricted double usage of 'ahb' reset name in PATCH 2 (Jessica, Samuel)
 - Moved phy reference from PATCH 5 to both PATCH 6 & 7 where the node is
   actually defined (Emil, Conor)
 - Drop unnecessary gpio include in PATCH 6; also added a DTS comment describing
   the rational behind RX internal delay adjustment (Andrew)
 - v3:
   https://lore.kernel.org/lkml/20231215204050.2296404-1-cristian.ciocaltea at collabora.com/

Changes in v3:
 - Rebased series onto next-20231214 and dropped the ccache & DMA coherency
   related patches (v2 06-08/12) handled by Emil via [3]
 - Squashed PATCH v2 01/12 into PATCH v3 2/9, per Krzysztof's review
 - Dropped incorrect PATCH v2 02/12
 - Incorporated Emil's feedback; also added his Co-developed-by on all dts
   patches
 - Documented the need of adjusting RX internal delay in PATCH v3 8/9, per
   Andrew's request
 - Added clock fixes from Emil (PATCH v3 8-9/9) required to support 10/100Mb
   link speeds
 - v2:
   https://lore.kernel.org/lkml/20231029042712.520010-1-cristian.ciocaltea at collabora.com/

Changes in v2:
 - Dropped ccache PATCH 01-05 reworked by Emil via [2]
 - Dropped already applied PATCH 06/12
 - Added PATCH v2 01 to prepare snps-dwmac binding for JH7100 support
 - Added PATCH v2 02-03 to provide some jh7110-dwmac binding optimizations
 - Handled JH7110 conflicting work in PATCH 07 via PATCH v2 04
 - Reworked PATCH 8 via PATCH v2 05, adding JH7100 quirk and dropped
   starfive,gtxclk-dlychain DT property; also fixed register naming
 - Added PATCH v2 08 providing DMA coherency related DT changes
 - Updated PATCH 9 commit msg:
   s/OF_DMA_DEFAULT_COHERENT/ARCH_DMA_DEFAULT_COHERENT/
 - Replaced 'uncached-offset' property with 'sifive,cache-ops' in PATCH 10/12
   and dropped 'sideband' reg
 - Add new patch providing coherent DMA memory pool (PATCH v2 10)
 - Updated PATCH 11/12 according to the stmmac glue layer changes in upstream
 - Split PATCH 12/12 into PATCH v2 10-12 to handle individual gmac setup of
   VisionFive v1 and BeagleV boards as they use different PHYs; also switched
   phy-mode from "rgmii-tx" to "rgmii-id" (requires a reduction of
   rx-internal-delay-ps by ~50%)
 - Rebased series onto next-20231024
 - v1:
   https://lore.kernel.org/lkml/20230211031821.976408-1-cristian.ciocaltea at collabora.com/

Cristian Ciocaltea (7):
  dt-bindings: net: starfive,jh7110-dwmac: Drop redundant reset
    description
  dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
  net: stmmac: dwmac-starfive: Add support for JH7100 SoC
  riscv: dts: starfive: jh7100: Add sysmain and gmac DT nodes
  riscv: dts: starfive: jh7100-common: Setup pinmux and enable gmac
  riscv: dts: starfive: visionfive-v1: Setup ethernet phy
  riscv: dts: starfive: beaglev-starlight: Setup phy reset gpio

Emil Renner Berthing (2):
  clk: starfive: Add flags argument to JH71X0__MUX macro
  clk: starfive: jh7100: Add CLK_SET_RATE_PARENT to gmac_tx

 .../devicetree/bindings/net/snps,dwmac.yaml   | 11 ++-
 .../bindings/net/starfive,jh7110-dwmac.yaml   | 75 ++++++++++++-----
 .../dts/starfive/jh7100-beaglev-starlight.dts | 11 +++
 .../boot/dts/starfive/jh7100-common.dtsi      | 84 +++++++++++++++++++
 .../jh7100-starfive-visionfive-v1.dts         | 22 ++++-
 arch/riscv/boot/dts/starfive/jh7100.dtsi      | 36 ++++++++
 .../clk/starfive/clk-starfive-jh7100-audio.c  |  2 +-
 drivers/clk/starfive/clk-starfive-jh7100.c    | 32 +++----
 .../clk/starfive/clk-starfive-jh7110-aon.c    |  6 +-
 .../clk/starfive/clk-starfive-jh7110-isp.c    |  2 +-
 .../clk/starfive/clk-starfive-jh7110-sys.c    | 26 +++---
 drivers/clk/starfive/clk-starfive-jh71x0.h    |  4 +-
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 +-
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 ++++++-
 14 files changed, 280 insertions(+), 69 deletions(-)

-- 
2.43.0



From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:42 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:42 +0200
Subject: [PATCH v4 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231218214451.2345691-3-cristian.ciocaltea@collabora.com>

The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
similar to the newer JH7110, but it requires only two interrupts and a
single reset line, which is 'ahb' instead of the commonly used
'stmmaceth'.

Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
conjunction with 'stmmaceth', extend the logic to also permit exclusive
usage of the 'ahb' reset name.  This ensures the following use cases are
supported:

  JH7110: reset-names = "stmmaceth", "ahb";
  JH7100: reset-names = "ahb";
  other:  reset-names = "stmmaceth";

Also note the need to use a different dwmac fallback, as v5.20 applies
to JH7110 only, while JH7100 relies on v3.7x.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 11 ++-
 .../bindings/net/starfive,jh7110-dwmac.yaml   | 74 +++++++++++++------
 2 files changed, 61 insertions(+), 24 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 5c2769dc689a..4052b355ec2c 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -95,6 +95,7 @@ properties:
         - snps,dwmac-5.20
         - snps,dwxgmac
         - snps,dwxgmac-2.10
+        - starfive,jh7100-dwmac
         - starfive,jh7110-dwmac
 
   reg:
@@ -145,9 +146,13 @@ properties:
 
   reset-names:
     minItems: 1
-    items:
-      - const: stmmaceth
-      - const: ahb
+    maxItems: 2
+    oneOf:
+      - items:
+          - enum: [stmmaceth, ahb]
+      - items:
+          - const: stmmaceth
+          - const: ahb
 
   power-domains:
     maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index d90cb82c1424..f5f0bff5be0f 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -16,16 +16,20 @@ select:
     compatible:
       contains:
         enum:
+          - starfive,jh7100-dwmac
           - starfive,jh7110-dwmac
   required:
     - compatible
 
 properties:
   compatible:
-    items:
-      - enum:
-          - starfive,jh7110-dwmac
-      - const: snps,dwmac-5.20
+    oneOf:
+      - items:
+          - const: starfive,jh7100-dwmac
+          - const: snps,dwmac
+      - items:
+          - const: starfive,jh7110-dwmac
+          - const: snps,dwmac-5.20
 
   reg:
     maxItems: 1
@@ -46,23 +50,6 @@ properties:
       - const: tx
       - const: gtx
 
-  interrupts:
-    minItems: 3
-    maxItems: 3
-
-  interrupt-names:
-    minItems: 3
-    maxItems: 3
-
-  resets:
-    minItems: 2
-    maxItems: 2
-
-  reset-names:
-    items:
-      - const: stmmaceth
-      - const: ahb
-
   starfive,tx-use-rgmii-clk:
     description:
       Tx clock is provided by external rgmii clock.
@@ -93,6 +80,51 @@ required:
 allOf:
   - $ref: snps,dwmac.yaml#
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: starfive,jh7100-dwmac
+    then:
+      properties:
+        interrupts:
+          minItems: 2
+          maxItems: 2
+
+        interrupt-names:
+          minItems: 2
+          maxItems: 2
+
+        resets:
+          maxItems: 1
+
+        reset-names:
+          const: ahb
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: starfive,jh7110-dwmac
+    then:
+      properties:
+        interrupts:
+          minItems: 3
+          maxItems: 3
+
+        interrupt-names:
+          minItems: 3
+          maxItems: 3
+
+        resets:
+          minItems: 2
+          maxItems: 2
+
+        reset-names:
+          items:
+            - const: stmmaceth
+            - const: ahb
+
 unevaluatedProperties: false
 
 examples:
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:44 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:44 +0200
Subject: [PATCH v4 4/9] riscv: dts: starfive: jh7100: Add sysmain and gmac DT nodes
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231218214451.2345691-5-cristian.ciocaltea@collabora.com>

Provide the sysmain and gmac DT nodes supporting the DWMAC found on the
StarFive JH7100 SoC.

Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 arch/riscv/boot/dts/starfive/jh7100.dtsi | 36 ++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/riscv/boot/dts/starfive/jh7100.dtsi b/arch/riscv/boot/dts/starfive/jh7100.dtsi
index c216aaecac53..2ebdebe6a81c 100644
--- a/arch/riscv/boot/dts/starfive/jh7100.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7100.dtsi
@@ -204,6 +204,37 @@ sdio1: mmc at 10010000 {
 			status = "disabled";
 		};
 
+		gmac: ethernet at 10020000 {
+			compatible = "starfive,jh7100-dwmac", "snps,dwmac";
+			reg = <0x0 0x10020000 0x0 0x10000>;
+			clocks = <&clkgen JH7100_CLK_GMAC_ROOT_DIV>,
+				 <&clkgen JH7100_CLK_GMAC_AHB>,
+				 <&clkgen JH7100_CLK_GMAC_PTP_REF>,
+				 <&clkgen JH7100_CLK_GMAC_TX_INV>,
+				 <&clkgen JH7100_CLK_GMAC_GTX>;
+			clock-names = "stmmaceth", "pclk", "ptp_ref", "tx", "gtx";
+			resets = <&rstgen JH7100_RSTN_GMAC_AHB>;
+			reset-names = "ahb";
+			interrupts = <6>, <7>;
+			interrupt-names = "macirq", "eth_wake_irq";
+			max-frame-size = <9000>;
+			snps,multicast-filter-bins = <32>;
+			snps,perfect-filter-entries = <128>;
+			starfive,syscon = <&sysmain 0x70 0>;
+			rx-fifo-depth = <32768>;
+			tx-fifo-depth = <16384>;
+			snps,axi-config = <&stmmac_axi_setup>;
+			snps,fixed-burst;
+			snps,force_thresh_dma_mode;
+			status = "disabled";
+
+			stmmac_axi_setup: stmmac-axi-config {
+				snps,wr_osr_lmt = <16>;
+				snps,rd_osr_lmt = <16>;
+				snps,blen = <256 128 64 32 0 0 0>;
+			};
+		};
+
 		clkgen: clock-controller at 11800000 {
 			compatible = "starfive,jh7100-clkgen";
 			reg = <0x0 0x11800000 0x0 0x10000>;
@@ -218,6 +249,11 @@ rstgen: reset-controller at 11840000 {
 			#reset-cells = <1>;
 		};
 
+		sysmain: syscon at 11850000 {
+			compatible = "starfive,jh7100-sysmain", "syscon";
+			reg = <0x0 0x11850000 0x0 0x10000>;
+		};
+
 		i2c0: i2c at 118b0000 {
 			compatible = "snps,designware-i2c";
 			reg = <0x0 0x118b0000 0x0 0x10000>;
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:45 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:45 +0200
Subject: [PATCH v4 5/9] riscv: dts: starfive: jh7100-common: Setup pinmux and enable gmac
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231218214451.2345691-6-cristian.ciocaltea@collabora.com>

Add pinmux configuration for DWMAC found on the JH7100 based boards and
enable the related DT node, providing a basic PHY configuration.

Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../boot/dts/starfive/jh7100-common.dtsi      | 84 +++++++++++++++++++
 1 file changed, 84 insertions(+)

diff --git a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
index 42fb61c36068..bcba08e5bdf2 100644
--- a/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7100-common.dtsi
@@ -72,7 +72,91 @@ wifi_pwrseq: wifi-pwrseq {
 	};
 };
 
+&gmac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac_pins>;
+	phy-mode = "rgmii-id";
+	status = "okay";
+
+	mdio: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+	};
+};
+
 &gpio {
+	gmac_pins: gmac-0 {
+		gtxclk-pins {
+			pins = <PAD_FUNC_SHARE(115)>;
+			bias-pull-up;
+			drive-strength = <35>;
+			input-enable;
+			input-schmitt-enable;
+			slew-rate = <0>;
+		};
+		miitxclk-pins {
+			pins = <PAD_FUNC_SHARE(116)>;
+			bias-pull-up;
+			drive-strength = <14>;
+			input-enable;
+			input-schmitt-disable;
+			slew-rate = <0>;
+		};
+		tx-pins {
+			pins = <PAD_FUNC_SHARE(117)>,
+			       <PAD_FUNC_SHARE(119)>,
+			       <PAD_FUNC_SHARE(120)>,
+			       <PAD_FUNC_SHARE(121)>,
+			       <PAD_FUNC_SHARE(122)>,
+			       <PAD_FUNC_SHARE(123)>,
+			       <PAD_FUNC_SHARE(124)>,
+			       <PAD_FUNC_SHARE(125)>,
+			       <PAD_FUNC_SHARE(126)>;
+			bias-pull-up;
+			drive-strength = <35>;
+			input-disable;
+			input-schmitt-disable;
+			slew-rate = <0>;
+		};
+		rxclk-pins {
+			pins = <PAD_FUNC_SHARE(127)>;
+			bias-pull-up;
+			drive-strength = <14>;
+			input-enable;
+			input-schmitt-disable;
+			slew-rate = <6>;
+		};
+		rxer-pins {
+			pins = <PAD_FUNC_SHARE(129)>;
+			bias-pull-up;
+			drive-strength = <14>;
+			input-enable;
+			input-schmitt-disable;
+			slew-rate = <0>;
+		};
+		rx-pins {
+			pins = <PAD_FUNC_SHARE(128)>,
+			       <PAD_FUNC_SHARE(130)>,
+			       <PAD_FUNC_SHARE(131)>,
+			       <PAD_FUNC_SHARE(132)>,
+			       <PAD_FUNC_SHARE(133)>,
+			       <PAD_FUNC_SHARE(134)>,
+			       <PAD_FUNC_SHARE(135)>,
+			       <PAD_FUNC_SHARE(136)>,
+			       <PAD_FUNC_SHARE(137)>,
+			       <PAD_FUNC_SHARE(138)>,
+			       <PAD_FUNC_SHARE(139)>,
+			       <PAD_FUNC_SHARE(140)>,
+			       <PAD_FUNC_SHARE(141)>;
+			bias-pull-up;
+			drive-strength = <14>;
+			input-enable;
+			input-schmitt-enable;
+			slew-rate = <0>;
+		};
+	};
+
 	i2c0_pins: i2c0-0 {
 		i2c-pins {
 			pinmux = <GPIOMUX(62, GPO_LOW,
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:46 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:46 +0200
Subject: [PATCH v4 6/9] riscv: dts: starfive: visionfive-v1: Setup ethernet phy
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231218214451.2345691-7-cristian.ciocaltea@collabora.com>

The StarFive VisionFive V1 SBC uses a Motorcomm YT8521 PHY supporting
RGMII-ID, but requires manual adjustment of the RX internal delay to
work properly.

The default RX delay provided by the driver is 1.95 ns, which proves to
be too high. Applying a 50% reduction seems to mitigate the issue.

Also note this adjustment is not necessary on BeagleV Starlight SBC,
which uses a Microchip PHY.  Hence, there is no indication of a
misbehaviour on the GMAC side, but most likely the issue stems from
the Motorcomm PHY.

While at it, drop the redundant gpio include, which is already provided
by jh7100-common.dtsi.

Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../jh7100-starfive-visionfive-v1.dts         | 22 ++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts b/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts
index e82af72f1aaf..4e396f820660 100644
--- a/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts
+++ b/arch/riscv/boot/dts/starfive/jh7100-starfive-visionfive-v1.dts
@@ -6,7 +6,6 @@
 
 /dts-v1/;
 #include "jh7100-common.dtsi"
-#include <dt-bindings/gpio/gpio.h>
 
 / {
 	model = "StarFive VisionFive V1";
@@ -18,3 +17,24 @@ gpio-restart {
 		priority = <224>;
 	};
 };
+
+/*
+ * The board uses a Motorcomm YT8521 PHY supporting RGMII-ID, but requires
+ * manual adjustment of the RX internal delay to work properly.  The default
+ * RX delay provided by the driver (1.95ns) is too high, but applying a 50%
+ * reduction seems to mitigate the issue.
+ *
+ * It is worth noting the adjustment is not necessary on BeagleV Starlight SBC,
+ * which uses a Microchip PHY.  Hence, most likely the Motorcomm PHY is the one
+ * responsible for the misbehaviour, not the GMAC.
+ */
+&mdio {
+	phy: ethernet-phy at 0 {
+		reg = <0>;
+		rx-internal-delay-ps = <900>;
+	};
+};
+
+&gmac {
+	phy-handle = <&phy>;
+};
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:47 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:47 +0200
Subject: [PATCH v4 7/9] riscv: dts: starfive: beaglev-starlight: Setup phy reset gpio
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231218214451.2345691-8-cristian.ciocaltea@collabora.com>

The BeagleV Starlight SBC uses a Microchip KSZ9031RNXCA PHY supporting
RGMII-ID which doesn't require any particular setup, other than defining
a reset gpio, as opposed to VisionFive V1 for which the RX internal
delay had to be adjusted.

Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../boot/dts/starfive/jh7100-beaglev-starlight.dts    | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts b/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
index 7cda3a89020a..b79426935bfd 100644
--- a/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
+++ b/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
@@ -11,3 +11,14 @@ / {
 	model = "BeagleV Starlight Beta";
 	compatible = "beagle,beaglev-starlight-jh7100-r0", "starfive,jh7100";
 };
+
+&mdio {
+	phy: ethernet-phy at 7 {
+		reg = <7>;
+		reset-gpios = <&gpio 63 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&gmac {
+	phy-handle = <&phy>;
+};
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:49 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:49 +0200
Subject: [PATCH v4 9/9] clk: starfive: jh7100: Add CLK_SET_RATE_PARENT to gmac_tx
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231218214451.2345691-10-cristian.ciocaltea@collabora.com>

From: Emil Renner Berthing <emil.renner.berthing at canonical.com>

This is needed by the dwmac-starfive ethernet driver to set the clock
for 1000, 100 and 10 Mbps links properly.

Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 drivers/clk/starfive/clk-starfive-jh7100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/starfive/clk-starfive-jh7100.c b/drivers/clk/starfive/clk-starfive-jh7100.c
index d3b260c01d5c..03f6f26a15d8 100644
--- a/drivers/clk/starfive/clk-starfive-jh7100.c
+++ b/drivers/clk/starfive/clk-starfive-jh7100.c
@@ -200,7 +200,7 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0_GDIV(JH7100_CLK_GMAC_GTX, "gmac_gtxclk", 0, 255, JH7100_CLK_GMAC_ROOT_DIV),
 	JH71X0_GDIV(JH7100_CLK_GMAC_RMII_TX, "gmac_rmii_txclk", 0, 8, JH7100_CLK_GMAC_RMII_REF),
 	JH71X0_GDIV(JH7100_CLK_GMAC_RMII_RX, "gmac_rmii_rxclk", 0, 8, JH7100_CLK_GMAC_RMII_REF),
-	JH71X0__MUX(JH7100_CLK_GMAC_TX, "gmac_tx", 0, 3,
+	JH71X0__MUX(JH7100_CLK_GMAC_TX, "gmac_tx", CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT, 3,
 		    JH7100_CLK_GMAC_GTX,
 		    JH7100_CLK_GMAC_TX_INV,
 		    JH7100_CLK_GMAC_RMII_TX),
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Mon Dec 18 13:44:48 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Mon, 18 Dec 2023 23:44:48 +0200
Subject: [PATCH v4 8/9] clk: starfive: Add flags argument to JH71X0__MUX macro
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231218214451.2345691-9-cristian.ciocaltea@collabora.com>

From: Emil Renner Berthing <emil.renner.berthing at canonical.com>

This flag is needed to add the CLK_SET_RATE_PARENT flag on the gmac_tx
clock on the JH7100, which in turn is needed by the dwmac-starfive
driver to set the clock properly for 1000, 100 and 10 Mbps links.

This change was mostly made using coccinelle:

@ match @
expression idx, name, nparents;
@@
 JH71X0__MUX(
-idx, name, nparents,
+idx, name, 0, nparents,
 ...)

Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../clk/starfive/clk-starfive-jh7100-audio.c  |  2 +-
 drivers/clk/starfive/clk-starfive-jh7100.c    | 32 +++++++++----------
 .../clk/starfive/clk-starfive-jh7110-aon.c    |  6 ++--
 .../clk/starfive/clk-starfive-jh7110-isp.c    |  2 +-
 .../clk/starfive/clk-starfive-jh7110-sys.c    | 26 +++++++--------
 drivers/clk/starfive/clk-starfive-jh71x0.h    |  4 +--
 6 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/clk/starfive/clk-starfive-jh7100-audio.c b/drivers/clk/starfive/clk-starfive-jh7100-audio.c
index ee4bda14a40e..1fcf4e62f347 100644
--- a/drivers/clk/starfive/clk-starfive-jh7100-audio.c
+++ b/drivers/clk/starfive/clk-starfive-jh7100-audio.c
@@ -79,7 +79,7 @@ static const struct jh71x0_clk_data jh7100_audclk_data[] = {
 	JH71X0_GDIV(JH7100_AUDCLK_USB_LPM, "usb_lpm", CLK_IGNORE_UNUSED, 4, JH7100_AUDCLK_USB_APB),
 	JH71X0_GDIV(JH7100_AUDCLK_USB_STB, "usb_stb", CLK_IGNORE_UNUSED, 3, JH7100_AUDCLK_USB_APB),
 	JH71X0__DIV(JH7100_AUDCLK_APB_EN, "apb_en", 8, JH7100_AUDCLK_DOM7AHB_BUS),
-	JH71X0__MUX(JH7100_AUDCLK_VAD_MEM, "vad_mem", 2,
+	JH71X0__MUX(JH7100_AUDCLK_VAD_MEM, "vad_mem", 0, 2,
 		    JH7100_AUDCLK_VAD_INTMEM,
 		    JH7100_AUDCLK_AUDIO_12288),
 };
diff --git a/drivers/clk/starfive/clk-starfive-jh7100.c b/drivers/clk/starfive/clk-starfive-jh7100.c
index 69cc11ea7e33..d3b260c01d5c 100644
--- a/drivers/clk/starfive/clk-starfive-jh7100.c
+++ b/drivers/clk/starfive/clk-starfive-jh7100.c
@@ -24,48 +24,48 @@
 #define JH7100_CLK_GMAC_GR_MII_RX	(JH7100_CLK_END + 3)
 
 static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
-	JH71X0__MUX(JH7100_CLK_CPUNDBUS_ROOT, "cpundbus_root", 4,
+	JH71X0__MUX(JH7100_CLK_CPUNDBUS_ROOT, "cpundbus_root", 0, 4,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_DLA_ROOT, "dla_root", 3,
+	JH71X0__MUX(JH7100_CLK_DLA_ROOT, "dla_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_DSP_ROOT, "dsp_root", 4,
+	JH71X0__MUX(JH7100_CLK_DSP_ROOT, "dsp_root", 0, 4,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_GMACUSB_ROOT, "gmacusb_root", 3,
+	JH71X0__MUX(JH7100_CLK_GMACUSB_ROOT, "gmacusb_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_PERH0_ROOT, "perh0_root", 2,
+	JH71X0__MUX(JH7100_CLK_PERH0_ROOT, "perh0_root", 0, 2,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT),
-	JH71X0__MUX(JH7100_CLK_PERH1_ROOT, "perh1_root", 2,
+	JH71X0__MUX(JH7100_CLK_PERH1_ROOT, "perh1_root", 0, 2,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_VIN_ROOT, "vin_root", 3,
+	JH71X0__MUX(JH7100_CLK_VIN_ROOT, "vin_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_VOUT_ROOT, "vout_root", 3,
+	JH71X0__MUX(JH7100_CLK_VOUT_ROOT, "vout_root", 0, 3,
 		    JH7100_CLK_OSC_AUD,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL2_OUT),
 	JH71X0_GDIV(JH7100_CLK_AUDIO_ROOT, "audio_root", 0, 8, JH7100_CLK_PLL0_OUT),
-	JH71X0__MUX(JH7100_CLK_CDECHIFI4_ROOT, "cdechifi4_root", 3,
+	JH71X0__MUX(JH7100_CLK_CDECHIFI4_ROOT, "cdechifi4_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL1_OUT,
 		    JH7100_CLK_PLL2_OUT),
-	JH71X0__MUX(JH7100_CLK_CDEC_ROOT, "cdec_root", 3,
+	JH71X0__MUX(JH7100_CLK_CDEC_ROOT, "cdec_root", 0, 3,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL1_OUT),
-	JH71X0__MUX(JH7100_CLK_VOUTBUS_ROOT, "voutbus_root", 3,
+	JH71X0__MUX(JH7100_CLK_VOUTBUS_ROOT, "voutbus_root", 0, 3,
 		    JH7100_CLK_OSC_AUD,
 		    JH7100_CLK_PLL0_OUT,
 		    JH7100_CLK_PLL2_OUT),
@@ -76,7 +76,7 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0_GDIV(JH7100_CLK_PLL0_TESTOUT, "pll0_testout", 0, 31, JH7100_CLK_PERH0_SRC),
 	JH71X0_GDIV(JH7100_CLK_PLL1_TESTOUT, "pll1_testout", 0, 31, JH7100_CLK_DLA_ROOT),
 	JH71X0_GDIV(JH7100_CLK_PLL2_TESTOUT, "pll2_testout", 0, 31, JH7100_CLK_PERH1_SRC),
-	JH71X0__MUX(JH7100_CLK_PLL2_REF, "pll2_refclk", 2,
+	JH71X0__MUX(JH7100_CLK_PLL2_REF, "pll2_refclk", 0, 2,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_OSC_AUD),
 	JH71X0__DIV(JH7100_CLK_CPU_CORE, "cpu_core", 8, JH7100_CLK_CPUNBUS_ROOT_DIV),
@@ -142,7 +142,7 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0__DIV(JH7100_CLK_NOC_COG, "noc_cog", 8, JH7100_CLK_DLA_ROOT),
 	JH71X0_GATE(JH7100_CLK_NNE_AHB, "nne_ahb", 0, JH7100_CLK_AHB_BUS),
 	JH71X0__DIV(JH7100_CLK_NNEBUS_SRC1, "nnebus_src1", 4, JH7100_CLK_DSP_ROOT),
-	JH71X0__MUX(JH7100_CLK_NNE_BUS, "nne_bus", 2,
+	JH71X0__MUX(JH7100_CLK_NNE_BUS, "nne_bus", 0, 2,
 		    JH7100_CLK_CPU_AXI,
 		    JH7100_CLK_NNEBUS_SRC1),
 	JH71X0_GATE(JH7100_CLK_NNE_AXI, "nne_axi", 0, JH7100_CLK_NNE_BUS),
@@ -166,7 +166,7 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0_GDIV(JH7100_CLK_USBPHY_125M, "usbphy_125m", 0, 8, JH7100_CLK_USBPHY_ROOTDIV),
 	JH71X0_GDIV(JH7100_CLK_USBPHY_PLLDIV25M, "usbphy_plldiv25m", 0, 32,
 		    JH7100_CLK_USBPHY_ROOTDIV),
-	JH71X0__MUX(JH7100_CLK_USBPHY_25M, "usbphy_25m", 2,
+	JH71X0__MUX(JH7100_CLK_USBPHY_25M, "usbphy_25m", 0, 2,
 		    JH7100_CLK_OSC_SYS,
 		    JH7100_CLK_USBPHY_PLLDIV25M),
 	JH71X0_FDIV(JH7100_CLK_AUDIO_DIV, "audio_div", JH7100_CLK_AUDIO_ROOT),
@@ -200,12 +200,12 @@ static const struct jh71x0_clk_data jh7100_clk_data[] __initconst = {
 	JH71X0_GDIV(JH7100_CLK_GMAC_GTX, "gmac_gtxclk", 0, 255, JH7100_CLK_GMAC_ROOT_DIV),
 	JH71X0_GDIV(JH7100_CLK_GMAC_RMII_TX, "gmac_rmii_txclk", 0, 8, JH7100_CLK_GMAC_RMII_REF),
 	JH71X0_GDIV(JH7100_CLK_GMAC_RMII_RX, "gmac_rmii_rxclk", 0, 8, JH7100_CLK_GMAC_RMII_REF),
-	JH71X0__MUX(JH7100_CLK_GMAC_TX, "gmac_tx", 3,
+	JH71X0__MUX(JH7100_CLK_GMAC_TX, "gmac_tx", 0, 3,
 		    JH7100_CLK_GMAC_GTX,
 		    JH7100_CLK_GMAC_TX_INV,
 		    JH7100_CLK_GMAC_RMII_TX),
 	JH71X0__INV(JH7100_CLK_GMAC_TX_INV, "gmac_tx_inv", JH7100_CLK_GMAC_TX),
-	JH71X0__MUX(JH7100_CLK_GMAC_RX_PRE, "gmac_rx_pre", 2,
+	JH71X0__MUX(JH7100_CLK_GMAC_RX_PRE, "gmac_rx_pre", 0, 2,
 		    JH7100_CLK_GMAC_GR_MII_RX,
 		    JH7100_CLK_GMAC_RMII_RX),
 	JH71X0__INV(JH7100_CLK_GMAC_RX_INV, "gmac_rx_inv", JH7100_CLK_GMAC_RX_PRE),
diff --git a/drivers/clk/starfive/clk-starfive-jh7110-aon.c b/drivers/clk/starfive/clk-starfive-jh7110-aon.c
index 62954eb7b50a..418efdad719b 100644
--- a/drivers/clk/starfive/clk-starfive-jh7110-aon.c
+++ b/drivers/clk/starfive/clk-starfive-jh7110-aon.c
@@ -26,7 +26,7 @@
 static const struct jh71x0_clk_data jh7110_aonclk_data[] = {
 	/* source */
 	JH71X0__DIV(JH7110_AONCLK_OSC_DIV4, "osc_div4", 4, JH7110_AONCLK_OSC),
-	JH71X0__MUX(JH7110_AONCLK_APB_FUNC, "apb_func", 2,
+	JH71X0__MUX(JH7110_AONCLK_APB_FUNC, "apb_func", 0, 2,
 		    JH7110_AONCLK_OSC_DIV4,
 		    JH7110_AONCLK_OSC),
 	/* gmac0 */
@@ -39,7 +39,7 @@ static const struct jh71x0_clk_data jh7110_aonclk_data[] = {
 		    JH7110_AONCLK_GMAC0_GTXCLK,
 		    JH7110_AONCLK_GMAC0_RMII_RTX),
 	JH71X0__INV(JH7110_AONCLK_GMAC0_TX_INV, "gmac0_tx_inv", JH7110_AONCLK_GMAC0_TX),
-	JH71X0__MUX(JH7110_AONCLK_GMAC0_RX, "gmac0_rx", 2,
+	JH71X0__MUX(JH7110_AONCLK_GMAC0_RX, "gmac0_rx", 0, 2,
 		    JH7110_AONCLK_GMAC0_RGMII_RXIN,
 		    JH7110_AONCLK_GMAC0_RMII_RTX),
 	JH71X0__INV(JH7110_AONCLK_GMAC0_RX_INV, "gmac0_rx_inv", JH7110_AONCLK_GMAC0_RX),
@@ -48,7 +48,7 @@ static const struct jh71x0_clk_data jh7110_aonclk_data[] = {
 	/* rtc */
 	JH71X0_GATE(JH7110_AONCLK_RTC_APB, "rtc_apb", 0, JH7110_AONCLK_APB_BUS),
 	JH71X0__DIV(JH7110_AONCLK_RTC_INTERNAL, "rtc_internal", 1022, JH7110_AONCLK_OSC),
-	JH71X0__MUX(JH7110_AONCLK_RTC_32K, "rtc_32k", 2,
+	JH71X0__MUX(JH7110_AONCLK_RTC_32K, "rtc_32k", 0, 2,
 		    JH7110_AONCLK_RTC_OSC,
 		    JH7110_AONCLK_RTC_INTERNAL),
 	JH71X0_GATE(JH7110_AONCLK_RTC_CAL, "rtc_cal", 0, JH7110_AONCLK_OSC),
diff --git a/drivers/clk/starfive/clk-starfive-jh7110-isp.c b/drivers/clk/starfive/clk-starfive-jh7110-isp.c
index ce034ed28532..929b8788279e 100644
--- a/drivers/clk/starfive/clk-starfive-jh7110-isp.c
+++ b/drivers/clk/starfive/clk-starfive-jh7110-isp.c
@@ -53,7 +53,7 @@ static const struct jh71x0_clk_data jh7110_ispclk_data[] = {
 		    JH7110_ISPCLK_MIPI_RX0_PXL),
 	JH71X0_GATE(JH7110_ISPCLK_VIN_PIXEL_IF3, "vin_pixel_if3", 0,
 		    JH7110_ISPCLK_MIPI_RX0_PXL),
-	JH71X0__MUX(JH7110_ISPCLK_VIN_P_AXI_WR, "vin_p_axi_wr", 2,
+	JH71X0__MUX(JH7110_ISPCLK_VIN_P_AXI_WR, "vin_p_axi_wr", 0, 2,
 		    JH7110_ISPCLK_MIPI_RX0_PXL,
 		    JH7110_ISPCLK_DVP_INV),
 	/* ispv2_top_wrapper */
diff --git a/drivers/clk/starfive/clk-starfive-jh7110-sys.c b/drivers/clk/starfive/clk-starfive-jh7110-sys.c
index 3884eff9fe93..8f5e5abfa178 100644
--- a/drivers/clk/starfive/clk-starfive-jh7110-sys.c
+++ b/drivers/clk/starfive/clk-starfive-jh7110-sys.c
@@ -36,18 +36,18 @@
 
 static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	/* root */
-	JH71X0__MUX(JH7110_SYSCLK_CPU_ROOT, "cpu_root", 2,
+	JH71X0__MUX(JH7110_SYSCLK_CPU_ROOT, "cpu_root", 0, 2,
 		    JH7110_SYSCLK_OSC,
 		    JH7110_SYSCLK_PLL0_OUT),
 	JH71X0__DIV(JH7110_SYSCLK_CPU_CORE, "cpu_core", 7, JH7110_SYSCLK_CPU_ROOT),
 	JH71X0__DIV(JH7110_SYSCLK_CPU_BUS, "cpu_bus", 2, JH7110_SYSCLK_CPU_CORE),
-	JH71X0__MUX(JH7110_SYSCLK_GPU_ROOT, "gpu_root", 2,
+	JH71X0__MUX(JH7110_SYSCLK_GPU_ROOT, "gpu_root", 0, 2,
 		    JH7110_SYSCLK_PLL2_OUT,
 		    JH7110_SYSCLK_PLL1_OUT),
 	JH71X0_MDIV(JH7110_SYSCLK_PERH_ROOT, "perh_root", 2, 2,
 		    JH7110_SYSCLK_PLL0_OUT,
 		    JH7110_SYSCLK_PLL2_OUT),
-	JH71X0__MUX(JH7110_SYSCLK_BUS_ROOT, "bus_root", 2,
+	JH71X0__MUX(JH7110_SYSCLK_BUS_ROOT, "bus_root", 0, 2,
 		    JH7110_SYSCLK_OSC,
 		    JH7110_SYSCLK_PLL2_OUT),
 	JH71X0__DIV(JH7110_SYSCLK_NOCSTG_BUS, "nocstg_bus", 3, JH7110_SYSCLK_BUS_ROOT),
@@ -62,7 +62,7 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0__DIV(JH7110_SYSCLK_PLL2_DIV2, "pll2_div2", 2, JH7110_SYSCLK_PLL2_OUT),
 	JH71X0__DIV(JH7110_SYSCLK_AUDIO_ROOT, "audio_root", 8, JH7110_SYSCLK_PLL2_OUT),
 	JH71X0__DIV(JH7110_SYSCLK_MCLK_INNER, "mclk_inner", 64, JH7110_SYSCLK_AUDIO_ROOT),
-	JH71X0__MUX(JH7110_SYSCLK_MCLK, "mclk", 2,
+	JH71X0__MUX(JH7110_SYSCLK_MCLK, "mclk", 0, 2,
 		    JH7110_SYSCLK_MCLK_INNER,
 		    JH7110_SYSCLK_MCLK_EXT),
 	JH71X0_GATE(JH7110_SYSCLK_MCLK_OUT, "mclk_out", 0, JH7110_SYSCLK_MCLK_INNER),
@@ -96,7 +96,7 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0__DIV(JH7110_SYSCLK_OSC_DIV2, "osc_div2", 2, JH7110_SYSCLK_OSC),
 	JH71X0__DIV(JH7110_SYSCLK_PLL1_DIV4, "pll1_div4", 2, JH7110_SYSCLK_PLL1_DIV2),
 	JH71X0__DIV(JH7110_SYSCLK_PLL1_DIV8, "pll1_div8", 2, JH7110_SYSCLK_PLL1_DIV4),
-	JH71X0__MUX(JH7110_SYSCLK_DDR_BUS, "ddr_bus", 4,
+	JH71X0__MUX(JH7110_SYSCLK_DDR_BUS, "ddr_bus", 0, 4,
 		    JH7110_SYSCLK_OSC_DIV2,
 		    JH7110_SYSCLK_PLL1_DIV2,
 		    JH7110_SYSCLK_PLL1_DIV4,
@@ -186,7 +186,7 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0__DIV(JH7110_SYSCLK_GMAC1_RMII_RTX, "gmac1_rmii_rtx", 30,
 		    JH7110_SYSCLK_GMAC1_RMII_REFIN),
 	JH71X0_GDIV(JH7110_SYSCLK_GMAC1_PTP, "gmac1_ptp", 0, 31, JH7110_SYSCLK_GMAC_SRC),
-	JH71X0__MUX(JH7110_SYSCLK_GMAC1_RX, "gmac1_rx", 2,
+	JH71X0__MUX(JH7110_SYSCLK_GMAC1_RX, "gmac1_rx", 0, 2,
 		    JH7110_SYSCLK_GMAC1_RGMII_RXIN,
 		    JH7110_SYSCLK_GMAC1_RMII_RTX),
 	JH71X0__INV(JH7110_SYSCLK_GMAC1_RX_INV, "gmac1_rx_inv", JH7110_SYSCLK_GMAC1_RX),
@@ -270,11 +270,11 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0_MDIV(JH7110_SYSCLK_I2STX0_LRCK_MST, "i2stx0_lrck_mst", 64, 2,
 		    JH7110_SYSCLK_I2STX0_BCLK_MST_INV,
 		    JH7110_SYSCLK_I2STX0_BCLK_MST),
-	JH71X0__MUX(JH7110_SYSCLK_I2STX0_BCLK, "i2stx0_bclk",	2,
+	JH71X0__MUX(JH7110_SYSCLK_I2STX0_BCLK, "i2stx0_bclk", 0, 2,
 		    JH7110_SYSCLK_I2STX0_BCLK_MST,
 		    JH7110_SYSCLK_I2STX_BCLK_EXT),
 	JH71X0__INV(JH7110_SYSCLK_I2STX0_BCLK_INV, "i2stx0_bclk_inv", JH7110_SYSCLK_I2STX0_BCLK),
-	JH71X0__MUX(JH7110_SYSCLK_I2STX0_LRCK, "i2stx0_lrck", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2STX0_LRCK, "i2stx0_lrck", 0, 2,
 		    JH7110_SYSCLK_I2STX0_LRCK_MST,
 		    JH7110_SYSCLK_I2STX_LRCK_EXT),
 	/* i2stx1 */
@@ -285,11 +285,11 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0_MDIV(JH7110_SYSCLK_I2STX1_LRCK_MST, "i2stx1_lrck_mst", 64, 2,
 		    JH7110_SYSCLK_I2STX1_BCLK_MST_INV,
 		    JH7110_SYSCLK_I2STX1_BCLK_MST),
-	JH71X0__MUX(JH7110_SYSCLK_I2STX1_BCLK, "i2stx1_bclk", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2STX1_BCLK, "i2stx1_bclk", 0, 2,
 		    JH7110_SYSCLK_I2STX1_BCLK_MST,
 		    JH7110_SYSCLK_I2STX_BCLK_EXT),
 	JH71X0__INV(JH7110_SYSCLK_I2STX1_BCLK_INV, "i2stx1_bclk_inv", JH7110_SYSCLK_I2STX1_BCLK),
-	JH71X0__MUX(JH7110_SYSCLK_I2STX1_LRCK, "i2stx1_lrck", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2STX1_LRCK, "i2stx1_lrck", 0, 2,
 		    JH7110_SYSCLK_I2STX1_LRCK_MST,
 		    JH7110_SYSCLK_I2STX_LRCK_EXT),
 	/* i2srx */
@@ -300,11 +300,11 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0_MDIV(JH7110_SYSCLK_I2SRX_LRCK_MST, "i2srx_lrck_mst", 64, 2,
 		    JH7110_SYSCLK_I2SRX_BCLK_MST_INV,
 		    JH7110_SYSCLK_I2SRX_BCLK_MST),
-	JH71X0__MUX(JH7110_SYSCLK_I2SRX_BCLK, "i2srx_bclk", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2SRX_BCLK, "i2srx_bclk", 0, 2,
 		    JH7110_SYSCLK_I2SRX_BCLK_MST,
 		    JH7110_SYSCLK_I2SRX_BCLK_EXT),
 	JH71X0__INV(JH7110_SYSCLK_I2SRX_BCLK_INV, "i2srx_bclk_inv", JH7110_SYSCLK_I2SRX_BCLK),
-	JH71X0__MUX(JH7110_SYSCLK_I2SRX_LRCK, "i2srx_lrck", 2,
+	JH71X0__MUX(JH7110_SYSCLK_I2SRX_LRCK, "i2srx_lrck", 0, 2,
 		    JH7110_SYSCLK_I2SRX_LRCK_MST,
 		    JH7110_SYSCLK_I2SRX_LRCK_EXT),
 	/* pdm */
@@ -314,7 +314,7 @@ static const struct jh71x0_clk_data jh7110_sysclk_data[] __initconst = {
 	JH71X0_GATE(JH7110_SYSCLK_TDM_AHB, "tdm_ahb", 0, JH7110_SYSCLK_AHB0),
 	JH71X0_GATE(JH7110_SYSCLK_TDM_APB, "tdm_apb", 0, JH7110_SYSCLK_APB0),
 	JH71X0_GDIV(JH7110_SYSCLK_TDM_INTERNAL, "tdm_internal", 0, 64, JH7110_SYSCLK_MCLK),
-	JH71X0__MUX(JH7110_SYSCLK_TDM_TDM, "tdm_tdm", 2,
+	JH71X0__MUX(JH7110_SYSCLK_TDM_TDM, "tdm_tdm", 0, 2,
 		    JH7110_SYSCLK_TDM_INTERNAL,
 		    JH7110_SYSCLK_TDM_EXT),
 	JH71X0__INV(JH7110_SYSCLK_TDM_TDM_INV, "tdm_tdm_inv", JH7110_SYSCLK_TDM_TDM),
diff --git a/drivers/clk/starfive/clk-starfive-jh71x0.h b/drivers/clk/starfive/clk-starfive-jh71x0.h
index 34bb11c72eb7..23e052fc1549 100644
--- a/drivers/clk/starfive/clk-starfive-jh71x0.h
+++ b/drivers/clk/starfive/clk-starfive-jh71x0.h
@@ -61,10 +61,10 @@ struct jh71x0_clk_data {
 	.parents = { [0] = _parent },						\
 }
 
-#define JH71X0__MUX(_idx, _name, _nparents, ...)				\
+#define JH71X0__MUX(_idx, _name, _flags, _nparents, ...)			\
 [_idx] = {									\
 	.name = _name,								\
-	.flags = 0,								\
+	.flags = _flags,							\
 	.max = ((_nparents) - 1) << JH71X0_CLK_MUX_SHIFT,			\
 	.parents = { __VA_ARGS__ },						\
 }
-- 
2.43.0



From bvanassche at acm.org  Mon Dec 18 13:55:51 2023
From: bvanassche at acm.org (Bart Van Assche)
Date: Mon, 18 Dec 2023 13:55:51 -0800
Subject: [PATCH V5 1/2] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231213124353.16407-2-quic_mnaresh@quicinc.com>
References: <20231213124353.16407-1-quic_mnaresh@quicinc.com>
 <20231213124353.16407-2-quic_mnaresh@quicinc.com>
Message-ID: <9861ce52-8163-40aa-b156-dd656143a73d@acm.org>

On 12/13/23 04:43, Maramaina Naresh wrote:
> +static ssize_t ufshcd_pm_qos_enable_store(struct device *dev,
> +		struct device_attribute *attr, const char *buf, size_t count)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +	u32 value;
> +
> +	if (kstrtou32(buf, 0, &value))
> +		return -EINVAL;
> +
> +	value = !!value;
> +	if (value)
> +		ufshcd_pm_qos_init(hba);
> +	else
> +		ufshcd_pm_qos_exit(hba);
> +
> +	return count;
> +}

Please use kstrtobool() instead of kstrtou32().

> +static void ufshcd_init_pm_qos_sysfs(struct ufs_hba *hba)
> +{
> +	hba->pm_qos_enable_attr.show = ufshcd_pm_qos_enable_show;
> +	hba->pm_qos_enable_attr.store = ufshcd_pm_qos_enable_store;
> +	sysfs_attr_init(&hba->pm_qos_enable_attr.attr);
> +	hba->pm_qos_enable_attr.attr.name = "pm_qos_enable";
> +	hba->pm_qos_enable_attr.attr.mode = 0644;
> +	if (device_create_file(hba->dev, &hba->pm_qos_enable_attr))
> +		dev_err(hba->dev, "Failed to create sysfs for pm_qos_enable\n");
> +}

Calling device_create_file() and device_remove_file() is not acceptable because of
the race conditions these calls introduce for udev rules. Please add this attribute
into an existing group and update the is_visible callback function of that group.
See also ufs_sysfs_groups[].

Thanks,

Bart.


From zajec5 at gmail.com  Mon Dec 18 14:02:22 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 18 Dec 2023 23:02:22 +0100
Subject: [PATCH RFC] dt-bindings: nvmem: u-boot, env: add any-name MAC
 cells compatible
In-Reply-To: <CAPnjgZ31AAauR876W1RmU4JPzKUD8XAMCZrJDumE+Dr4miqABQ@mail.gmail.com>
References: <20231214153620.23998-1-zajec5@gmail.com>
 <CAPnjgZ31AAauR876W1RmU4JPzKUD8XAMCZrJDumE+Dr4miqABQ@mail.gmail.com>
Message-ID: <1b4feb5d-f03c-44b3-9474-901534db5eb7@gmail.com>

On 14.12.2023 22:27, Simon Glass wrote:
> On Thu, 14 Dec 2023 at 08:36, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
>>
>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>
>> So far we had a property for "ethaddr" NVMEM cell containing base
>> Ethernet MAC address. The problem is vendors often pick non-standard
>> names for storing MAC(s) (other than "ethaddr"). A few names were
>> noticed over years:
>> 1. "wanaddr" (Edimax, ELECOM, EnGenius, I-O DATA, Sitecom)
>> 2. "et1macaddr" (ASUS)
>> 3. "eth1addr" (Buffalo)
>> 4. "athaddr" (EnGenius)
>> 5. "baseMAC" (Netgear)
>> 6. "mac" (Netgear)
>> 7. "mac_addr" (Moxa)
>> and more ("HW_LAN_MAC", "HW_WAN_MAC", "INIC_MAC_ADDR", "LAN_MAC_ADDR",
>> "RADIOADDR0", "RADIOADDR1", "WAN_MAC_ADDR", "lan1_mac_addr", "wanmac",
>> "wmac1", "wmac2").
>>
>> It doesn't make sense to add property for every possible MAC cell name.
>> Instead allow specifying cells with "mac" compatible.
>>
>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
>> ---
>> List of devices and their U-Boot MAC variables:
>> alphanetworks,asl56026) wanmac
>> asus,rt-ac65p) et1macaddr
>> asus,rt-ac85p) et1macaddr
>> belkin,f9k1109v1) HW_WAN_MAC + HW_LAN_MAC
>> buffalo,ls220de) eth1addr
>> buffalo,ls421de) eth1addr
>> checkpoint,l-50) lan1_mac_addr
>> dovado,tiny-ac) INIC_MAC_ADDR
>> dovado,tiny-ac) LAN_MAC_ADDR + WAN_MAC_ADDR
>> edimax,ra21s) wanaddr
>> edimax,rg21s) wanaddr
>> elecom,wrc-2533ghbk-i) wanaddr
>> elecom,wrc-2533ghbk2-t) wanaddr
>> engenius,ecb1200) athaddr
>> engenius,ecb1750) athaddr
>> engenius,epg5000) wanaddr
>> engenius,epg600) wanaddr
>> engenius,esr1200) wanaddr
>> engenius,esr1750) wanaddr
>> engenius,esr600) wanaddr
>> engenius,esr600h) wanaddr
>> engenius,esr900) wanaddr
>> enterasys,ws-ap3705i) RADIOADDR0 + RADIOADDR1
>> iodata,wn-ac1167dgr) wanaddr
>> iodata,wn-ac1167gr) wanaddr
>> iodata,wn-ac1600dgr) wanaddr
>> iodata,wn-ac1600dgr2) wanaddr
>> iodata,wn-ac733gr3) wanaddr
>> iodata,wn-ag300dgr) wanaddr
>> iodata,wnpr2600g) wanaddr
>> moxa,awk-1137c) mac_addr
>> netgear,wax220) mac
>> netgear,wndap620) baseMAC
>> netgear,wndap660) baseMAC
>> ocedo,panda) wmac1 + wmac2
>> sitecom,wlr-7100) wanaddr
>> sitecom,wlr-8100) wanaddr
>>
>>   .../devicetree/bindings/nvmem/u-boot,env.yaml | 33 +++++++++++++++++++
>>   1 file changed, 33 insertions(+)
>>
> 
> Are these upstream U-Boots, or just vendor forks?

I guess most of those devices don't have upstream U-Boot support. Please
note that while upstreaming vendors changes would be great in most cases
it doesn't happen. Most vendors sadly don't care and most end users
don't have enough time for that. In practice we often stick with vendor
provided bootloader to flash and boot self build Linux system (like
OpenWrt).

I'm not sure if/how does it help with this PATCH but please note that
upstream U-Boot code also supports few extra variables.

There is generic eth_env_get_enetaddr_by_index() that supports variables
like "<%s><%d>addr" and "<%s>addr". Right now it's used only for
"eth<%d>addr" and "ethaddr" so that mostly limits us to "ethaddr",
"eth1addr", "eth2addr" and "eth3addr".

 From some rare cases: there are also "usbnet_devaddr" and "wolpassword".

So given that U-Boot oficially supports at least 6 env variables for
MAC and there are many used with custom U-Boots and firmwares this
binding would help a lot.


From zajec5 at gmail.com  Mon Dec 18 14:10:20 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 18 Dec 2023 23:10:20 +0100
Subject: [PATCH 4/4] nvmem: layouts: add U-Boot env layout
In-Reply-To: <20231218152116.59d59bad@xps-13>
References: <20231218133722.16150-1-zajec5@gmail.com>
 <20231218133722.16150-4-zajec5@gmail.com> <20231218152116.59d59bad@xps-13>
Message-ID: <13bc621c-5fcb-4710-912c-06e3e80d7337@gmail.com>

On 18.12.2023 15:21, Miquel Raynal wrote:
> Hi Rafa?,
> 
> zajec5 at gmail.com wrote on Mon, 18 Dec 2023 14:37:22 +0100:
> 
>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>
>> This patch moves all generic (NVMEM devices independent) code from NVMEM
>> device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
>> code on top of it.
>>
>> Thanks to proper layout it's possible to support U-Boot env data stored
>> on any kind of NVMEM device.
>>
>> For backward compatibility with old DT bindings we need to keep old
>> NVMEM device driver functional. To avoid code duplication a parsing
>> function is exported and reused in it.
>>
>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
>> ---
> 
> I have a couple of comments about the original driver which gets
> copy-pasted in the new layout driver, maybe you could clean these
> (the memory leak should be fixed before the migration so it can be
> backported easily, the others are just style so it can be done after, I
> don't mind).
> 
> ...
> 
>> +int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
>> +		     enum u_boot_env_format format)
>> +{
>> +	size_t crc32_data_offset;
>> +	size_t crc32_data_len;
>> +	size_t crc32_offset;
>> +	size_t data_offset;
>> +	size_t data_len;
>> +	size_t dev_size;
>> +	uint32_t crc32;
>> +	uint32_t calc;
>> +	uint8_t *buf;
>> +	int bytes;
>> +	int err;
>> +
>> +	dev_size = nvmem_dev_size(nvmem);
>> +
>> +	buf = kcalloc(1, dev_size, GFP_KERNEL);
> 
> Out of curiosity, why kcalloc(1,...) rather than kzalloc() ?

I used kcalloc() initially as I didn't need buffer to be zeroed.

I see that memory-allocation.rst however says:
 > And, to be on the safe side it's best to use routines that set memory to zero, like kzalloc().

It's probably close to zero cost to zero that buffer so it could be kzalloc().


>> +	if (!buf) {
>> +		err = -ENOMEM;
>> +		goto err_out;
> 
> We could directly return ENOMEM here I guess.
> 
>> +	}
>> +
>> +	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
>> +	if (bytes < 0)
>> +		return bytes;
>> +	else if (bytes != dev_size)
>> +		return -EIO;
> 
> Don't we need to free buf in the above cases?
> 
>> +	switch (format) {
>> +	case U_BOOT_FORMAT_SINGLE:
>> +		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
>> +		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
>> +		data_offset = offsetof(struct u_boot_env_image_single, data);
>> +		break;
>> +	case U_BOOT_FORMAT_REDUNDANT:
>> +		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
>> +		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
>> +		data_offset = offsetof(struct u_boot_env_image_redundant, data);
>> +		break;
>> +	case U_BOOT_FORMAT_BROADCOM:
>> +		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
>> +		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
>> +		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
>> +		break;
>> +	}
>> +	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
> 
> Looks a bit convoluted, any chances we can use intermediate variables
> to help decipher this?
> 
>> +	crc32_data_len = dev_size - crc32_data_offset;
>> +	data_len = dev_size - data_offset;
>> +
>> +	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
>> +	if (calc != crc32) {
>> +		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
>> +		err = -EINVAL;
>> +		goto err_kfree;
>> +	}
>> +
>> +	buf[dev_size - 1] = '\0';
>> +	err = u_boot_env_parse_cells(dev, nvmem, buf, data_offset, data_len);
>> +	if (err)
>> +		dev_err(dev, "Failed to add cells: %d\n", err);
> 
> Please drop this error message, the only reason for which the function
> call would fail is apparently an ENOMEM case.
> 
>> +
>> +err_kfree:
>> +	kfree(buf);
>> +err_out:
>> +	return err;
>> +}
>> +EXPORT_SYMBOL_GPL(u_boot_env_parse);
>> +
>> +static int u_boot_env_add_cells(struct device *dev, struct nvmem_device *nvmem)
>> +{
>> +	const struct of_device_id *match;
>> +	struct device_node *layout_np;
>> +	enum u_boot_env_format format;
>> +
>> +	layout_np = of_nvmem_layout_get_container(nvmem);
>> +	if (!layout_np)
>> +		return -ENOENT;
>> +
>> +	match = of_match_node(u_boot_env_of_match_table, layout_np);
>> +	if (!match)
>> +		return -ENOENT;
>> +
>> +	format = (uintptr_t)match->data;
> 
> In the core there is currently an unused helper called
> nvmem_layout_get_match_data() which does that. I think the original
> intent of this function was to be used in this driver, so depending on
> your preference, can you please either use it or remove it?

The problem is that nvmem_layout_get_match_data() uses:
layout->dev.driver

It doesn't work with layouts driver (since refactoring?) as driver is
NULL. That results in NULL pointer dereference when trying to reach
of_match_table.

That is why I used u_boot_env_of_match_table directly.

If you know how to fix nvmem_layout_get_match_data() that would be
great. Do we need driver_register() somewhere in NVMEM core?


>> +
>> +	of_node_put(layout_np);
>> +
>> +	return u_boot_env_parse(dev, nvmem, format);
>> +}
> 
> Thanks,
> Miqu?l



From richard at nod.at  Mon Dec 18 14:10:20 2023
From: richard at nod.at (Richard Weinberger)
Date: Mon, 18 Dec 2023 23:10:20 +0100 (CET)
Subject: [PATCH v11 00/10] spi: Add support for stacked/parallel
 memories
In-Reply-To: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
Message-ID: <1953466568.133535.1702937420979.JavaMail.zimbra@nod.at>

----- Urspr?ngliche Mail -----
> Von: "Amit Kumar Mahapatra" <amit.kumar-mahapatra at amd.com>

> This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI
> driver to add stacked and parallel memories support.

I wish the series had a real cover letter which explains the big picture
in more detail.

What I didn't really get so far, is it really necessary to support multiple
chip selects within a single mtd?
You changes introduce hard to maintain changes into the spi-nor/mtd core code
which alert me.
Why can't we have one mtd for each cs and, if needed, combine them later?
We have drivers such as mtdconcat for reasons.

Thanks,
//richard


From zajec5 at gmail.com  Mon Dec 18 14:13:52 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 18 Dec 2023 23:13:52 +0100
Subject: [PATCH 1/4] dt-bindings: nvmem: layouts: add U-Boot environment
 variables layout
In-Reply-To: <170291091219.3792434.8389294947030479112.robh@kernel.org>
References: <20231218133722.16150-1-zajec5@gmail.com>
 <170291091219.3792434.8389294947030479112.robh@kernel.org>
Message-ID: <5cc586e2-c510-42c0-a451-73a8a129a30f@gmail.com>

On 18.12.2023 15:48, Rob Herring wrote:
> 
> On Mon, 18 Dec 2023 14:37:19 +0100, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>
>> U-Boot env data is a way of storing firmware variables. It's a format
>> that can be used of top of various storage devices. Its binding should
>> be an NVMEM layout instead of a standalone device.
>>
>> This patch adds layout binding which allows using it on top of MTD NVMEM
>> device as well as any other. At the same time it deprecates the old
>> combined binding.
>>
>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
>> ---
>>   .../bindings/nvmem/layouts/u-boot,env.yaml    | 55 +++++++++++++++++++
>>   .../devicetree/bindings/nvmem/u-boot,env.yaml |  6 ++
>>   2 files changed, 61 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
>>
> 
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/nvmem/u-boot,env.example.dtb: partition at 40000: 'ethaddr', 'reg' do not match any of the regexes: 'pinctrl-[0-9]+'
> 	from schema $id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env.yaml#
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/nvmem/u-boot,env.example.dtb: partition-u-boot-env: 'ethaddr' does not match any of the regexes: 'pinctrl-[0-9]+'
> 	from schema $id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env.yaml#

I checked my binding independently using using dt_binding_check and
missed that. I'm not aware of any way of limiting possibility of
applying binding to specific cases (like "nvmem-layout" node) so I
guess I'll just have to avoid duplicated "u-boot,env" compatible
string.


> doc reference errors (make refcheckdocs):
> 
> See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231218133722.16150-1-zajec5 at gmail.com
> 
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
> 
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
> 



From ardb at kernel.org  Mon Dec 18 14:26:58 2023
From: ardb at kernel.org (Ard Biesheuvel)
Date: Mon, 18 Dec 2023 23:26:58 +0100
Subject: [PATCH] efi/libstub: zboot: do not use $(shell ...) in cmd_copy_and_pad
In-Reply-To: <20231218080127.907460-1-masahiroy@kernel.org>
References: <20231218080127.907460-1-masahiroy@kernel.org>
Message-ID: <CAMj1kXFmoXKLzFQnfTgatSpsQj=6HnExRoYtH_jaYakGZFwrkg@mail.gmail.com>

On Mon, 18 Dec 2023 at 09:01, Masahiro Yamada <masahiroy at kernel.org> wrote:
>
> You do not need to use $(shell ...) in recipe lines, as they are already
> executed in a shell. An alternative solution is $$(...), which is an
> escaped sequence of the shell's command substituion, $(...).
>
> For this case, there is a reason to avoid $(shell ...).
>
> Kbuild detects command changes by using the if_changed macro, which
> compares the previous command recorded in .*.cmd with the current
> command from Makefile. If they differ, Kbuild re-runs the build rule.
>
> To diff the commands, Make must expand $(shell ...) first. It means that
> hexdump is executed every time, even when nothing needs rebuilding. If
> Kbuild determines that vmlinux.bin needs rebuilding, hexdump will be
> executed again to evaluate the 'cmd' macro, one more time to really
> build vmlinux.bin, and finally yet again to record the expanded command
> into .*.cmd.
>
> Replace $(shell ...) with $$(...) to avoid multiple, unnecessay shell
> evaluations. Since Make is agnostic about the shell code, $(...), the
> if_changed macro compares the string "$(hexdump -s16 -n4 ...)" verbatim,
> so hexdump is run only for building vmlinux.bin.
>
> For the same reason, $(shell ...) in EFI_ZBOOT_OBJCOPY_FLAGS should be
> eliminated.
>
> While I was here, I replaced '&&' with ';' because a command for
> if_changed is executed with 'set -e'.
>
> Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>

Reviewed-by: Ard Biesheuvel <ardb at kernel.org>

> ---
>
>  arch/arm64/boot/Makefile                    | 2 +-
>  drivers/firmware/efi/libstub/Makefile.zboot | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
> index 1761f5972443..a5a787371117 100644
> --- a/arch/arm64/boot/Makefile
> +++ b/arch/arm64/boot/Makefile
> @@ -44,7 +44,7 @@ EFI_ZBOOT_BFD_TARGET  := elf64-littleaarch64
>  EFI_ZBOOT_MACH_TYPE    := ARM64
>  EFI_ZBOOT_FORWARD_CFI  := $(CONFIG_ARM64_BTI_KERNEL)
>
> -EFI_ZBOOT_OBJCOPY_FLAGS        = --add-symbol zboot_code_size=0x$(shell \
> +EFI_ZBOOT_OBJCOPY_FLAGS        = --add-symbol zboot_code_size=0x$$( \
>                                 $(NM) vmlinux|grep _kernel_codesize|cut -d' ' -f1)
>
>  include $(srctree)/drivers/firmware/efi/libstub/Makefile.zboot
> diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot
> index 2c489627a807..65ffd0b760b2 100644
> --- a/drivers/firmware/efi/libstub/Makefile.zboot
> +++ b/drivers/firmware/efi/libstub/Makefile.zboot
> @@ -5,8 +5,8 @@
>  # EFI_ZBOOT_FORWARD_CFI
>
>  quiet_cmd_copy_and_pad = PAD     $@
> -      cmd_copy_and_pad = cp $< $@ && \
> -                        truncate -s $(shell hexdump -s16 -n4 -e '"%u"' $<) $@
> +      cmd_copy_and_pad = cp $< $@; \
> +                        truncate -s $$(hexdump -s16 -n4 -e '"%u"' $<) $@
>
>  # Pad the file to the size of the uncompressed image in memory, including BSS
>  $(obj)/vmlinux.bin: $(obj)/$(EFI_ZBOOT_PAYLOAD) FORCE
> --
> 2.40.1
>
>


From bo.ye at mediatek.com  Mon Dec 18 14:48:29 2023
From: bo.ye at mediatek.com (Bo Ye)
Date: Tue, 19 Dec 2023 06:48:29 +0800
Subject: [PATCH v2] mmc: add wp_grp_size node
Message-ID: <20231218224832.81347-1-bo.ye@mediatek.com>

From: "lin.gui" <lin.gui at mediatek.com>

Detail:
Add node "wp_grp_size", corresponding to WP_GRP_SIZE
(write protect group size) of eMMC's CSD register.

Scenario:
The eMMC card can be set into write-protected mode to
prevent data from being accidentally modified or deleted.
Wp_grp_size (Write Protect Group Size) refers to an
attribute of the eMMC card, used to manage write protection,
and is the CSD register  [36:32] of the eMMC device.
Wp_grp_size (Write Protect Group Size) indicates how many
eMMC blocks are contained in each write protection group on the eMMC card.

Final rendered file:
"/sys/class/mmc_host/mmc0/mmc0:0001/wp_grp_size"

Signed-off-by: Lin Gui <lin.gui at mediatek.com>
Signed-off-by: Bo Ye <bo.ye at mediatek.com>
---
Change in v2: 
-remove Change-Id
-replace space with tabulation
---
 drivers/mmc/core/mmc.c   | 16 +++++++++++++++-
 include/linux/mmc/card.h |  2 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 705942edacc6..e0d72378ac77 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -136,6 +136,17 @@ static void mmc_set_erase_size(struct mmc_card *card)
 	mmc_init_erase(card);
 }
 
+
+static void mmc_set_wp_grp_size(struct mmc_card *card)
+{
+	if (card->ext_csd.erase_group_def & 1)
+		card->wp_grp_size = card->ext_csd.hc_erase_size *
+			card->ext_csd.raw_hc_erase_gap_size;
+	else
+		card->wp_grp_size = card->csd.erase_size *
+			(card->csd.wp_grp_size + 1);
+}
+
 /*
  * Given a 128-bit response, decode to our card CSD structure.
  */
@@ -186,6 +197,7 @@ static int mmc_decode_csd(struct mmc_card *card)
 		b = UNSTUFF_BITS(resp, 37, 5);
 		csd->erase_size = (a + 1) * (b + 1);
 		csd->erase_size <<= csd->write_blkbits - 9;
+		csd->wp_grp_size = UNSTUFF_BITS(resp, 32, 5);
 	}
 
 	return 0;
@@ -790,6 +802,7 @@ MMC_DEV_ATTR(csd, "%08x%08x%08x%08x\n", card->raw_csd[0], card->raw_csd[1],
 MMC_DEV_ATTR(date, "%02d/%04d\n", card->cid.month, card->cid.year);
 MMC_DEV_ATTR(erase_size, "%u\n", card->erase_size << 9);
 MMC_DEV_ATTR(preferred_erase_size, "%u\n", card->pref_erase << 9);
+MMC_DEV_ATTR(wp_grp_size, "%u\n", card->wp_grp_size << 9);
 MMC_DEV_ATTR(ffu_capable, "%d\n", card->ext_csd.ffu_capable);
 MMC_DEV_ATTR(hwrev, "0x%x\n", card->cid.hwrev);
 MMC_DEV_ATTR(manfid, "0x%06x\n", card->cid.manfid);
@@ -850,6 +863,7 @@ static struct attribute *mmc_std_attrs[] = {
 	&dev_attr_date.attr,
 	&dev_attr_erase_size.attr,
 	&dev_attr_preferred_erase_size.attr,
+	&dev_attr_wp_grp_size.attr,
 	&dev_attr_fwrev.attr,
 	&dev_attr_ffu_capable.attr,
 	&dev_attr_hwrev.attr,
@@ -1764,7 +1778,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
 			mmc_set_erase_size(card);
 		}
 	}
-
+	mmc_set_wp_grp_size(card);
 	/*
 	 * Ensure eMMC user default partition is enabled
 	 */
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 7b12eebc5586..b9c3c6303a22 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -32,6 +32,7 @@ struct mmc_csd {
 	unsigned int		r2w_factor;
 	unsigned int		max_dtr;
 	unsigned int		erase_size;		/* In sectors */
+	unsigned int		wp_grp_size;
 	unsigned int		read_blkbits;
 	unsigned int		write_blkbits;
 	unsigned int		capacity;
@@ -306,6 +307,7 @@ struct mmc_card {
 	unsigned int		eg_boundary;	/* don't cross erase-group boundaries */
 	unsigned int		erase_arg;	/* erase / trim / discard */
  	u8			erased_byte;	/* value of erased bytes */
+	unsigned int		wp_grp_size;	/* write group size in sectors */
 
 	u32			raw_cid[4];	/* raw card CID */
 	u32			raw_csd[4];	/* raw card CSD */
-- 
2.18.0



From jacob.e.keller at intel.com  Mon Dec 18 14:53:21 2023
From: jacob.e.keller at intel.com (Jacob Keller)
Date: Mon, 18 Dec 2023 14:53:21 -0800
Subject: [PATCH v4 0/9] Enable networking support for StarFive JH7100 SoC
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <453e0abd-30a4-4abd-b5ae-63d9982ec1b8@intel.com>



On 12/18/2023 1:44 PM, Cristian Ciocaltea wrote:
> This patch series adds ethernet support for the StarFive JH7100 SoC and makes it
> available for the StarFive VisionFive V1 and BeagleV Starlight boards, although
> I could only validate on the former SBC.  Thank you Emil and Geert for helping
> with tests on BeagleV!
> 
> The work is heavily based on the reference implementation [1] and depends on the
> SiFive Composable Cache controller and non-coherent DMA support provided by Emil
> via [2] and [3].
> 
> *Update*: as of next-20231214, all dependencies have been merged.
> 
> [1] https://github.com/starfive-tech/linux/commits/visionfive
> [2] https://lore.kernel.org/all/CAJM55Z_pdoGxRXbmBgJ5GbVWyeM1N6+LHihbNdT26Oo_qA5VYA at mail.gmail.com/
> [3] https://lore.kernel.org/all/20231130151932.729708-1-emil.renner.berthing at canonical.com/
> 

I'm not super familiar with how the various pieces fit together, so I'm
not sure how valuable my read through is.. but I didn't see anything
obviously wrong.

For the series:

Reviewed-by: Jacob Keller <jacob.e.keller at intel.com>

> Changes in v4:
>  - Restricted double usage of 'ahb' reset name in PATCH 2 (Jessica, Samuel)
>  - Moved phy reference from PATCH 5 to both PATCH 6 & 7 where the node is
>    actually defined (Emil, Conor)
>  - Drop unnecessary gpio include in PATCH 6; also added a DTS comment describing
>    the rational behind RX internal delay adjustment (Andrew)
>  - v3:
>    https://lore.kernel.org/lkml/20231215204050.2296404-1-cristian.ciocaltea at collabora.com/
> 
> Changes in v3:
>  - Rebased series onto next-20231214 and dropped the ccache & DMA coherency
>    related patches (v2 06-08/12) handled by Emil via [3]
>  - Squashed PATCH v2 01/12 into PATCH v3 2/9, per Krzysztof's review
>  - Dropped incorrect PATCH v2 02/12
>  - Incorporated Emil's feedback; also added his Co-developed-by on all dts
>    patches
>  - Documented the need of adjusting RX internal delay in PATCH v3 8/9, per
>    Andrew's request
>  - Added clock fixes from Emil (PATCH v3 8-9/9) required to support 10/100Mb
>    link speeds
>  - v2:
>    https://lore.kernel.org/lkml/20231029042712.520010-1-cristian.ciocaltea at collabora.com/
> 
> Changes in v2:
>  - Dropped ccache PATCH 01-05 reworked by Emil via [2]
>  - Dropped already applied PATCH 06/12
>  - Added PATCH v2 01 to prepare snps-dwmac binding for JH7100 support
>  - Added PATCH v2 02-03 to provide some jh7110-dwmac binding optimizations
>  - Handled JH7110 conflicting work in PATCH 07 via PATCH v2 04
>  - Reworked PATCH 8 via PATCH v2 05, adding JH7100 quirk and dropped
>    starfive,gtxclk-dlychain DT property; also fixed register naming
>  - Added PATCH v2 08 providing DMA coherency related DT changes
>  - Updated PATCH 9 commit msg:
>    s/OF_DMA_DEFAULT_COHERENT/ARCH_DMA_DEFAULT_COHERENT/
>  - Replaced 'uncached-offset' property with 'sifive,cache-ops' in PATCH 10/12
>    and dropped 'sideband' reg
>  - Add new patch providing coherent DMA memory pool (PATCH v2 10)
>  - Updated PATCH 11/12 according to the stmmac glue layer changes in upstream
>  - Split PATCH 12/12 into PATCH v2 10-12 to handle individual gmac setup of
>    VisionFive v1 and BeagleV boards as they use different PHYs; also switched
>    phy-mode from "rgmii-tx" to "rgmii-id" (requires a reduction of
>    rx-internal-delay-ps by ~50%)
>  - Rebased series onto next-20231024
>  - v1:
>    https://lore.kernel.org/lkml/20230211031821.976408-1-cristian.ciocaltea at collabora.com/
> 
> Cristian Ciocaltea (7):
>   dt-bindings: net: starfive,jh7110-dwmac: Drop redundant reset
>     description
>   dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
>   net: stmmac: dwmac-starfive: Add support for JH7100 SoC
>   riscv: dts: starfive: jh7100: Add sysmain and gmac DT nodes
>   riscv: dts: starfive: jh7100-common: Setup pinmux and enable gmac
>   riscv: dts: starfive: visionfive-v1: Setup ethernet phy
>   riscv: dts: starfive: beaglev-starlight: Setup phy reset gpio
> 
> Emil Renner Berthing (2):
>   clk: starfive: Add flags argument to JH71X0__MUX macro
>   clk: starfive: jh7100: Add CLK_SET_RATE_PARENT to gmac_tx
> 
>  .../devicetree/bindings/net/snps,dwmac.yaml   | 11 ++-
>  .../bindings/net/starfive,jh7110-dwmac.yaml   | 75 ++++++++++++-----
>  .../dts/starfive/jh7100-beaglev-starlight.dts | 11 +++
>  .../boot/dts/starfive/jh7100-common.dtsi      | 84 +++++++++++++++++++
>  .../jh7100-starfive-visionfive-v1.dts         | 22 ++++-
>  arch/riscv/boot/dts/starfive/jh7100.dtsi      | 36 ++++++++
>  .../clk/starfive/clk-starfive-jh7100-audio.c  |  2 +-
>  drivers/clk/starfive/clk-starfive-jh7100.c    | 32 +++----
>  .../clk/starfive/clk-starfive-jh7110-aon.c    |  6 +-
>  .../clk/starfive/clk-starfive-jh7110-isp.c    |  2 +-
>  .../clk/starfive/clk-starfive-jh7110-sys.c    | 26 +++---
>  drivers/clk/starfive/clk-starfive-jh71x0.h    |  4 +-
>  drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 +-
>  .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 ++++++-
>  14 files changed, 280 insertions(+), 69 deletions(-)
> 


From cristian.ciocaltea at collabora.com  Mon Dec 18 14:59:13 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Tue, 19 Dec 2023 00:59:13 +0200
Subject: [PATCH v4 0/9] Enable networking support for StarFive JH7100 SoC
In-Reply-To: <453e0abd-30a4-4abd-b5ae-63d9982ec1b8@intel.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <453e0abd-30a4-4abd-b5ae-63d9982ec1b8@intel.com>
Message-ID: <426f4baf-4aa2-48a5-a4e3-2fa361c0bc4a@collabora.com>

On 12/19/23 00:53, Jacob Keller wrote:
> 
> 
> On 12/18/2023 1:44 PM, Cristian Ciocaltea wrote:
>> This patch series adds ethernet support for the StarFive JH7100 SoC and makes it
>> available for the StarFive VisionFive V1 and BeagleV Starlight boards, although
>> I could only validate on the former SBC.  Thank you Emil and Geert for helping
>> with tests on BeagleV!

[...]

> I'm not super familiar with how the various pieces fit together, so I'm
> not sure how valuable my read through is.. but I didn't see anything
> obviously wrong.
> 
> For the series:
> 
> Reviewed-by: Jacob Keller <jacob.e.keller at intel.com>

Thanks for the review,
Cristian


From graf at amazon.com  Mon Dec 18 15:01:02 2023
From: graf at amazon.com (Alexander Graf)
Date: Tue, 19 Dec 2023 00:01:02 +0100
Subject: [PATCH 06/15] arm64: Add KHO support
In-Reply-To: <20231214223604.GA1045434-robh@kernel.org>
References: <20231213000452.88295-1-graf@amazon.com>
 <20231213000452.88295-7-graf@amazon.com>
 <20231214223604.GA1045434-robh@kernel.org>
Message-ID: <d843596e-0def-439b-966a-a0f10a1b7f6d@amazon.com>

Hey Rob!

On 14.12.23 23:36, Rob Herring wrote:
> On Wed, Dec 13, 2023 at 12:04:43AM +0000, Alexander Graf wrote:
>> We now have all bits in place to support KHO kexecs. This patch adds
>> awareness of KHO in the kexec file as well as boot path for arm64 and
>> adds the respective kconfig option to the architecture so that it can
>> use KHO successfully.
>>
>> Signed-off-by: Alexander Graf <graf at amazon.com>
>> ---
>>   arch/arm64/Kconfig        | 12 ++++++++++++
>>   arch/arm64/kernel/setup.c |  2 ++
>>   arch/arm64/mm/init.c      |  8 ++++++++
>>   drivers/of/fdt.c          | 41 +++++++++++++++++++++++++++++++++++++++
>>   drivers/of/kexec.c        | 36 ++++++++++++++++++++++++++++++++++
>>   5 files changed, 99 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 7b071a00425d..1ba338ce7598 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -1501,6 +1501,18 @@ config ARCH_SUPPORTS_CRASH_DUMP
>>   config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
>>        def_bool CRASH_CORE
>>
>> +config KEXEC_KHO
>> +     bool "kexec handover"
>> +     depends on KEXEC
>> +     select MEMBLOCK_SCRATCH
>> +     select LIBFDT
>> +     select CMA
>> +     help
>> +       Allow kexec to hand over state across kernels by generating and
>> +       passing additional metadata to the target kernel. This is useful
>> +       to keep data or state alive across the kexec. For this to work,
>> +       both source and target kernels need to have this option enabled.
> Why do we have the same kconfig entry twice? Here and x86.


This was how the kexec config options were done when I wrote the patches 
originally. Since then, looks like Eric DeVolder has cleaned up things 
quite nicely. I'll adapt the new way.


>
>> +
>>   config TRANS_TABLE
>>        def_bool y
>>        depends on HIBERNATION || KEXEC_CORE
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index 417a8a86b2db..8035b673d96d 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -346,6 +346,8 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
>>
>>        paging_init();
>>
>> +     kho_reserve_mem();
>> +
>>        acpi_table_upgrade();
>>
>>        /* Parse the ACPI tables for possible boot-time configuration */
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 74c1db8ce271..254d82f3383a 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -358,6 +358,8 @@ void __init bootmem_init(void)
>>         */
>>        arch_reserve_crashkernel();
>>
>> +     kho_reserve();
>> +
> reserve what? It is not obvious what the difference between
> kho_reserve_mem() and kho_reserve() are.


Yeah, I agree. I was struggling to find good names for them. What they 
do is:

kho_reserve() - Reserve CMA memory for later kexec. We use this memory 
region as scratch memory later.
kho_reserve_mem() - Post-KHO. Creates memory reservations inside 
memblocks for pre-KHO handed over memory.

For v2, I'll change them to kho_reserve_scratch() and 
kho_reserve_previous_mem() unless you have better ideas :)


>
>>        memblock_dump_all();
>>   }
>>
>> @@ -386,6 +388,12 @@ void __init mem_init(void)
>>        /* this will put all unused low memory onto the freelists */
>>        memblock_free_all();
>>
>> +     /*
>> +      * Now that all KHO pages are marked as reserved, let's flip them back
>> +      * to normal pages with accurate refcount.
>> +      */
>> +     kho_populate_refcount();
>> +
>>        /*
>>         * Check boundaries twice: Some fundamental inconsistencies can be
>>         * detected at build time already.
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index bf502ba8da95..af95139351ed 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -1006,6 +1006,44 @@ void __init early_init_dt_check_for_usable_mem_range(void)
>>                memblock_add(rgn[i].base, rgn[i].size);
>>   }
>>
>> +/**
>> + * early_init_dt_check_kho - Decode info required for kexec handover from DT
>> + */
>> +void __init early_init_dt_check_kho(void)
>> +{
>> +#ifdef CONFIG_KEXEC_KHO
> if (!IS_ENABLED(CONFIG_KEXEC_KHO))
>    return;
>
> You'll need a kho_populate() stub.


Always happy to remove #ifdefs :)


>
>> +     unsigned long node = chosen_node_offset;
>> +     u64 kho_start, scratch_start, scratch_size, mem_start, mem_size;
>> +     const __be32 *p;
>> +     int l;
>> +
>> +     if ((long)node < 0)
>> +             return;
>> +
>> +     p = of_get_flat_dt_prop(node, "linux,kho-dt", &l);
>> +     if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
>> +             return;
>> +
>> +     kho_start = dt_mem_next_cell(dt_root_addr_cells, &p);
>> +
>> +     p = of_get_flat_dt_prop(node, "linux,kho-scratch", &l);
>> +     if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
>> +             return;
>> +
>> +     scratch_start = dt_mem_next_cell(dt_root_addr_cells, &p);
>> +     scratch_size = dt_mem_next_cell(dt_root_addr_cells, &p);
>> +
>> +     p = of_get_flat_dt_prop(node, "linux,kho-mem", &l);
>> +     if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
>> +             return;
>> +
>> +     mem_start = dt_mem_next_cell(dt_root_addr_cells, &p);
>> +     mem_size = dt_mem_next_cell(dt_root_addr_cells, &p);
>> +
>> +     kho_populate(kho_start, scratch_start, scratch_size, mem_start, mem_size);
>> +#endif
>> +}
>> +
>>   #ifdef CONFIG_SERIAL_EARLYCON
>>
>>   int __init early_init_dt_scan_chosen_stdout(void)
>> @@ -1304,6 +1342,9 @@ void __init early_init_dt_scan_nodes(void)
>>
>>        /* Handle linux,usable-memory-range property */
>>        early_init_dt_check_for_usable_mem_range();
>> +
>> +     /* Handle kexec handover */
>> +     early_init_dt_check_kho();
>>   }
>>
>>   bool __init early_init_dt_scan(void *params)
>> diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
>> index 68278340cecf..a612e6bb8c75 100644
>> --- a/drivers/of/kexec.c
>> +++ b/drivers/of/kexec.c
>> @@ -264,6 +264,37 @@ static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
>>   }
>>   #endif /* CONFIG_IMA_KEXEC */
>>
>> +static int kho_add_chosen(const struct kimage *image, void *fdt, int chosen_node)
>> +{
>> +     int ret = 0;
>> +
>> +#ifdef CONFIG_KEXEC_KHO
> ditto
>
> Though perhaps image->kho is not defined?


Correct, it is not. But I'm happy to have a few local variables that I 
stash the image->kho contents inside an ifdef into so we can at least 
compile check all libfdt invocations.


Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From andrew at codeconstruct.com.au  Mon Dec 18 15:02:45 2023
From: andrew at codeconstruct.com.au (Andrew Jeffery)
Date: Tue, 19 Dec 2023 09:32:45 +1030
Subject: [PATCH v4 2/2] i2c: aspeed: Acknowledge Tx done with and
 without ACK irq late
In-Reply-To: <7dfc99e5-4c76-413b-aabc-81b26e26249e@os.amperecomputing.com>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
	 <20231211102217.2436294-3-quan@os.amperecomputing.com>
	 <2eab42cde34723a195e7a0287db08b25f8388a3b.camel@codeconstruct.com.au>
	 <54cba87a0df233b8762e43b742afe8e44a77a60c.camel@codeconstruct.com.au>
	 <7dfc99e5-4c76-413b-aabc-81b26e26249e@os.amperecomputing.com>
Message-ID: <477f1e8fbed91cc1160086af1f20030e7a6d853b.camel@codeconstruct.com.au>

On Mon, 2023-12-18 at 15:45 +0700, Quan Nguyen wrote:
> 
> On 15/12/2023 05:21, Andrew Jeffery wrote:
> > 
> > ```
> > $ qemu-system-arm \
> > 	-M ast2600-evb \
> > 	-kernel build.aspeed_g5/arch/arm/boot/zImage \
> > 	-dtb build.aspeed_g5/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dtb \
> > 	-initrd ~/src/buildroot.org/buildroot/output/images/rootfs.cpio.xz \
> > 	-nographic 2>&1 \
> > 	| ts -s
> > ...
> > 00:00:03 [    1.089187] Freeing initrd memory: 3308K
> > 00:00:05 smbus: error: Unexpected send start condition in state 1
> > 00:00:05 smbus: error: Unexpected write in state -1
> > 00:00:06 [    3.685731] aspeed-i2c-bus 1e78a400.i2c-bus: i2c bus 7 registered, irq 48
> > 00:00:06 [    3.688918] aspeed-i2c-bus 1e78a480.i2c-bus: i2c bus 8 registered, irq 49
> > 00:00:06 [    3.692326] aspeed-i2c-bus 1e78a500.i2c-bus: i2c bus 9 registered, irq 50
> > 00:00:06 [    3.693757] aspeed-i2c-bus 1e78a680.i2c-bus: i2c bus 12 registered, irq 51
> > 00:00:06 [    3.695070] aspeed-i2c-bus 1e78a700.i2c-bus: i2c bus 13 registered, irq 52
> > 00:00:06 [    3.696184] aspeed-i2c-bus 1e78a780.i2c-bus: i2c bus 14 registered, irq 53
> > 00:00:06 [    3.697144] aspeed-i2c-bus 1e78a800.i2c-bus: i2c bus 15 registered, irq 54
> > 00:00:06 [    3.699061] aspeed-video 1e700000.video: irq 55
> > 00:00:06 [    3.699254] aspeed-video 1e700000.video: assigned reserved memory node video
> > 00:00:06 [    3.702755] aspeed-video 1e700000.video: alloc mem size(24576) at 0xbc000000 for jpeg header
> > 00:00:06 [    3.706139] Driver for 1-wire Dallas network protocol.
> > 00:00:07 smbus: error: Unexpected send start condition in state -1
> > 00:00:07 smbus: error: Unexpected write in state -1
> > 00:00:10 smbus: error: Unexpected send start condition in state -1
> > 00:00:10 smbus: error: Unexpected write in state -1
> > 00:00:12 smbus: error: Unexpected send start condition in state -1
> > 00:00:12 smbus: error: Unexpected write in state -1
> > 00:00:14 smbus: error: Unexpected send start condition in state -1
> > 00:00:14 smbus: error: Unexpected write in state -1
> > 00:00:17 smbus: error: Unexpected send start condition in state -1
> > 00:00:17 smbus: error: Unexpected write in state -1
> > 00:00:18 [   14.080141] adt7475 7-002e: Error configuring attenuator bypass
> > 00:00:19 smbus: error: Unexpected send start condition in state -1
> > 00:00:19 smbus: error: Unexpected write in state -1
> > 00:00:21 smbus: error: Unexpected send start condition in state -1
> > 00:00:21 smbus: error: Unexpected write in state -1
> > 00:00:24 smbus: error: Unexpected send start condition in state -1
> > 00:00:24 smbus: error: Unexpected write in state -1
> > ```
> > 
> > The smbus errors do not occur if I revert this patch.
> > 
> > Can you look into qemu to see if it's a bug in the aspeed i2c
> > controller model's state machine?
> > 
> 
> Thanks, Andrew, for testing these patches on qemu.
> 
> I'll try to look into it to see if anything can be improved, but I have 
> to admit that I'm not so familiar with it. This is my first time trying 
> it on qemu. Just did these tests on real HW with waveform captured 
> sometimes.
> 
> So far I could be able to reproduce the issue and start playing around 
> trying to understand the model.
> 

So `$ git grep -lF 'Unexpected write in state'` leads us to
hw/i2c/smbus_slave.c:193. From the switch statement there and the log
output above dev->mode must be SMBUS_CONFUSED:


https://gitlab.com/qemu-project/qemu/-/blob/039afc5ef7367fbc8fb475580c291c2655e856cb/hw/i2c/smbus_slave.c#L35-L41

The prior log message was:

```
00:00:05 smbus: error: Unexpected send start condition in state 1
```

So we entered SMBUS_CONFUSED from SMBUS_WRITE_DATA. Given the log
output above it suggests the master model is failing to send an
I2C_FINISH prior to I2C_START_SEND, as that log message is emitted from
`dev->mode != SMBUS_IDLE` when the slave sees an `I2C_START_SEND`.

Perhaps the M_STOP_CMD handling needs to go above the M_START_CMD
handling in aspeed_i2c_bus_handle_cmd()?

https://gitlab.com/qemu-project/qemu/-/blob/039afc5ef7367fbc8fb475580c291c2655e856cb/hw/i2c/aspeed_i2c.c#L450

Andrew


From bo.ye at mediatek.com  Mon Dec 18 15:05:32 2023
From: bo.ye at mediatek.com (Bo Ye)
Date: Tue, 19 Dec 2023 07:05:32 +0800
Subject: [PATCH v2] mmc: add wp_grp_size node
In-Reply-To: <20231218224832.81347-1-bo.ye@mediatek.com>
References: <20231218224832.81347-1-bo.ye@mediatek.com>
Message-ID: <20231218230532.82427-1-bo.ye@mediatek.com>

From: "lin.gui" <lin.gui at mediatek.com>

Detail:
Add node "wp_grp_size", corresponding to WP_GRP_SIZE
(write protect group size) of eMMC's CSD register.

Scenario:
The eMMC card can be set into write-protected mode to
prevent data from being accidentally modified or deleted.
Wp_grp_size (Write Protect Group Size) refers to an
attribute of the eMMC card, used to manage write protection,
and is the CSD register  [36:32] of the eMMC device.
Wp_grp_size (Write Protect Group Size) indicates how many
eMMC blocks are contained in each write protection group on the eMMC card.

Final rendered file:
"/sys/class/mmc_host/mmc0/mmc0:0001/wp_grp_size"

Signed-off-by: Lin Gui <lin.gui at mediatek.com>
Signed-off-by: Bo Ye <bo.ye at mediatek.com>
---
Change in v2: 
-remove Change-Id
-replace space with tabulation
---
 drivers/mmc/core/mmc.c   | 16 +++++++++++++++-
 include/linux/mmc/card.h |  2 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 705942edacc6..e0d72378ac77 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -136,6 +136,17 @@ static void mmc_set_erase_size(struct mmc_card *card)
 	mmc_init_erase(card);
 }
 
+
+static void mmc_set_wp_grp_size(struct mmc_card *card)
+{
+	if (card->ext_csd.erase_group_def & 1)
+		card->wp_grp_size = card->ext_csd.hc_erase_size *
+			card->ext_csd.raw_hc_erase_gap_size;
+	else
+		card->wp_grp_size = card->csd.erase_size *
+			(card->csd.wp_grp_size + 1);
+}
+
 /*
  * Given a 128-bit response, decode to our card CSD structure.
  */
@@ -186,6 +197,7 @@ static int mmc_decode_csd(struct mmc_card *card)
 		b = UNSTUFF_BITS(resp, 37, 5);
 		csd->erase_size = (a + 1) * (b + 1);
 		csd->erase_size <<= csd->write_blkbits - 9;
+		csd->wp_grp_size = UNSTUFF_BITS(resp, 32, 5);
 	}
 
 	return 0;
@@ -790,6 +802,7 @@ MMC_DEV_ATTR(csd, "%08x%08x%08x%08x\n", card->raw_csd[0], card->raw_csd[1],
 MMC_DEV_ATTR(date, "%02d/%04d\n", card->cid.month, card->cid.year);
 MMC_DEV_ATTR(erase_size, "%u\n", card->erase_size << 9);
 MMC_DEV_ATTR(preferred_erase_size, "%u\n", card->pref_erase << 9);
+MMC_DEV_ATTR(wp_grp_size, "%u\n", card->wp_grp_size << 9);
 MMC_DEV_ATTR(ffu_capable, "%d\n", card->ext_csd.ffu_capable);
 MMC_DEV_ATTR(hwrev, "0x%x\n", card->cid.hwrev);
 MMC_DEV_ATTR(manfid, "0x%06x\n", card->cid.manfid);
@@ -850,6 +863,7 @@ static struct attribute *mmc_std_attrs[] = {
 	&dev_attr_date.attr,
 	&dev_attr_erase_size.attr,
 	&dev_attr_preferred_erase_size.attr,
+	&dev_attr_wp_grp_size.attr,
 	&dev_attr_fwrev.attr,
 	&dev_attr_ffu_capable.attr,
 	&dev_attr_hwrev.attr,
@@ -1764,7 +1778,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
 			mmc_set_erase_size(card);
 		}
 	}
-
+	mmc_set_wp_grp_size(card);
 	/*
 	 * Ensure eMMC user default partition is enabled
 	 */
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 7b12eebc5586..b9c3c6303a22 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -32,6 +32,7 @@ struct mmc_csd {
 	unsigned int		r2w_factor;
 	unsigned int		max_dtr;
 	unsigned int		erase_size;		/* In sectors */
+	unsigned int		wp_grp_size;
 	unsigned int		read_blkbits;
 	unsigned int		write_blkbits;
 	unsigned int		capacity;
@@ -306,6 +307,7 @@ struct mmc_card {
 	unsigned int		eg_boundary;	/* don't cross erase-group boundaries */
 	unsigned int		erase_arg;	/* erase / trim / discard */
  	u8			erased_byte;	/* value of erased bytes */
+	unsigned int		wp_grp_size;	/* write group size in sectors */
 
 	u32			raw_cid[4];	/* raw card CID */
 	u32			raw_csd[4];	/* raw card CSD */
-- 
2.18.0



From broonie at kernel.org  Mon Dec 18 15:39:32 2023
From: broonie at kernel.org (Mark Brown)
Date: Mon, 18 Dec 2023 23:39:32 +0000
Subject: [PATCH] kselftest/arm64: Don't probe the current VL for
 unsupported vector types
Message-ID: <20231218-kselftest-arm64-vec-syscfg-rdvl-v1-1-0ac22d47e81f@kernel.org>

The vec-syscfg selftest verifies that setting the VL of the currently
tested vector type does not disrupt the VL of the other vector type. To do
this it records the current vector length for each type but neglects to
guard this with a check for that vector type actually being supported. Add
one, using a helper function which we also update all the other instances
of this pattern.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 tools/testing/selftests/arm64/fp/vec-syscfg.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/arm64/fp/vec-syscfg.c b/tools/testing/selftests/arm64/fp/vec-syscfg.c
index 5f648b97a06f..ea9c7d47790f 100644
--- a/tools/testing/selftests/arm64/fp/vec-syscfg.c
+++ b/tools/testing/selftests/arm64/fp/vec-syscfg.c
@@ -66,6 +66,11 @@ static struct vec_data vec_data[] = {
 	},
 };
 
+static bool vec_type_supported(struct vec_data *data)
+{
+	return getauxval(data->hwcap_type) & data->hwcap;
+}
+
 static int stdio_read_integer(FILE *f, const char *what, int *val)
 {
 	int n = 0;
@@ -564,8 +569,11 @@ static void prctl_set_all_vqs(struct vec_data *data)
 		return;
 	}
 
-	for (i = 0; i < ARRAY_SIZE(vec_data); i++)
+	for (i = 0; i < ARRAY_SIZE(vec_data); i++) {
+		if (!vec_type_supported(&vec_data[i]))
+			continue;
 		orig_vls[i] = vec_data[i].rdvl();
+	}
 
 	for (vq = SVE_VQ_MIN; vq <= SVE_VQ_MAX; vq++) {
 		vl = sve_vl_from_vq(vq);
@@ -594,7 +602,7 @@ static void prctl_set_all_vqs(struct vec_data *data)
 			if (&vec_data[i] == data)
 				continue;
 
-			if (!(getauxval(vec_data[i].hwcap_type) & vec_data[i].hwcap))
+			if (!vec_type_supported(&vec_data[i]))
 				continue;
 
 			if (vec_data[i].rdvl() != orig_vls[i]) {
@@ -765,7 +773,7 @@ int main(void)
 		struct vec_data *data = &vec_data[i];
 		unsigned long supported;
 
-		supported = getauxval(data->hwcap_type) & data->hwcap;
+		supported = vec_type_supported(data);
 		if (!supported)
 			all_supported = false;
 

---
base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab
change-id: 20231215-kselftest-arm64-vec-syscfg-rdvl-7944e19ac64f

Best regards,
-- 
Mark Brown <broonie at kernel.org>



From linus.walleij at linaro.org  Mon Dec 18 15:44:06 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 19 Dec 2023 00:44:06 +0100
Subject: [PATCH 5/7] crypto: sl3516 - Use helper to set reqsize
In-Reply-To: <20231218164649.2492465-5-ovidiu.panait@windriver.com>
References: <20231218164649.2492465-1-ovidiu.panait@windriver.com> <20231218164649.2492465-5-ovidiu.panait@windriver.com>
Message-ID: <CACRpkdaNTdKu9QgvDqFH8sAzJRMaDARwXNa+a5ddHotUw3k_3g@mail.gmail.com>

On Mon, Dec 18, 2023 at 5:46?PM <ovidiu.panait at windriver.com> wrote:

> From: Ovidiu Panait <ovidiu.panait at windriver.com>
>
> The value of reqsize must only be changed through the helper.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait at windriver.com>

Looks right to me:
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From quic_taozha at quicinc.com  Mon Dec 18 16:14:39 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Tue, 19 Dec 2023 08:14:39 +0800
Subject: [PATCH v3 1/8] dt-bindings: arm: Add support for CMB element size
In-Reply-To: <270d759f-74b3-42f0-96ec-f97bee7116b8@linaro.org>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-2-git-send-email-quic_taozha@quicinc.com>
 <270d759f-74b3-42f0-96ec-f97bee7116b8@linaro.org>
Message-ID: <cdde7597-2c1c-4570-a604-91b87eef9455@quicinc.com>


On 11/21/2023 3:24 PM, Krzysztof Kozlowski wrote:
> On 21/11/2023 03:24, Tao Zhang wrote:
>> Add property "qcom,cmb-elem-size" to support CMB(Continuous
>> Multi-Bit) element for TPDM. The associated aggregator will read
>> this size before it is enabled. CMB element size currently only
>> supports 32-bit and 64-bit.
>
>>     qcom,dsb-msrs-num:
>>       description:
>>         Specifies the number of DSB(Discrete Single Bit) MSR(mux select register)
>> @@ -110,4 +119,23 @@ examples:
>>         };
>>       };
>>   
>> +    tpdm at 6c29000 {
>> +      compatible = "qcom,coresight-tpdm", "arm,primecell";
>> +      reg = <0x06c29000 0x1000>;
>> +      reg-names = "tpdm-base";
>> +
>> +      qcom,cmb-element-size = /bits/ 8 <64>;
> One new property usually does not justify new example. Why it cannot be
> added to existing example?

Because the existing example tpdm "tpdm at 684c000" which only supports dsb 
sub-unit.? Most

TPDMs only support one type of sub-unit.

>
> Anyway, I prefer not to take any new Qualcomm Coresight bindings or
> Qualcomm SoC DTS nodes with Coresight till we fix all existing warnings.
> I don't know how to fix them, so I need help with them. No such fixing
> happened so far from Qcom, so pushback is my only way to get any attention.
>
> I already commented on this in other email thread.

Jinlong has fixed the warnings from coresight bindings. I will prepare 
my next patch

series soon.


Best,

Tao

>
> Best regards,
> Krzysztof
>


From retpolanne at posteo.net  Mon Dec 18 16:31:05 2023
From: retpolanne at posteo.net (Anne Macedo)
Date: Tue, 19 Dec 2023 00:31:05 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <20231213122523.219cbfc0@donnerap.manchester.arm.com>
References: <20231212122835.10850-2-retpolanne@posteo.net>
 <20231212162200.10b3868b@donnerap.manchester.arm.com>
 <axsvii25yrknfae6gdreti7lcskoscsdbsujwuispiieimsbdy@gwzm4l7mwlew>
 <20231213013544.2fc7e0d1@minigeek.lan>
 <ceuoq3xxgb5kkel7e7wqpslcg7h6dde3wgdqhyo7jgop6owovk@5a76ks5fiun4>
 <20231213122523.219cbfc0@donnerap.manchester.arm.com>
Message-ID: <ljqe2z34upvzaxh744labf6ephmvcj535img2ct4d2vijjmboh@abg7anbngfyv>

On Wed, Dec 13, 2023 at 12:25:23PM +0000, Andre Przywara wrote:
> On Wed, 13 Dec 2023 11:02:39 +0000
> Anne Macedo <retpolanne at posteo.net> wrote:
> 
> Hi Anne,
> 
> > On Wed, Dec 13, 2023 at 01:35:44AM +0000, Andre Przywara wrote:
> > > On Tue, 12 Dec 2023 19:27:14 +0000
> > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > 
> > > Hi Anne,
> > >   
> > > > On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:  
> > > > > On Tue, 12 Dec 2023 12:28:30 +0000
> > > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > > 
> > > > > Hi Anne,
> > > > >     
> > > > > > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > > > > > Realtek 8211 PHY to Orange Pi One Plus.    
> > > > > 
> > > > > So can you state why this would be needed? This is the RTL8211 ID,    
> > > > 
> > > > Apologies, I completely forgot to include some context. 
> > > >   
> > > > > right? Which should be autodetected via MDIO. Looking back in my inbox
> > > > > you proposed this change before, for U-Boot, specifically, but I fail to
> > > > > find a solution or explanation what really happens here. Two Renesas .dts
> > > > > files have the same compatible, and the commit message talks about the
> > > > > reset line there, is this related?
> > > > > 
> > > > > So can you please give some more background and explanation? That would be
> > > > > part of a good commit message anyway ("why", not "what").    
> > > > 
> > > > Should I resend the commit with a more meaningful explanation? The
> > > > context is the following:
> > > > 
> > > > currently, ethernet doesn't seem to work on both u-boot and Linux on the
> > > > Orange Pi One Plus board. 
> > > > 
> > > > On the kernel, this error shows up:
> > > > 
> > > > Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > [    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> > > > 
> > > > After applying this fix, the PHY gets attached: 
> > > > 
> > > > Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > [    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
> > > > 
> > > > The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
> > > > to find a PHY, so this patch includes the correct PHY ID with the
> > > > RTL8211 ID. 
> > > > 
> > > > The behaviour is described on [1].  
> > > 
> > > So this is all an observation, but no real explanation, isn't it?  
> > 
> > I've made some analysis on [3] on this bug, but it was based solely on
> > u-boot. I was having trouble with the regulator and on u-boot nothing
> > would trigger the GPIO PD6 and the vcc-gmac-3v3 regulator, so the NIC
> > was completely dead. Next I did an analysis based on [2] because the
> > u-boot PHY initialization was flaky.
> > 
> > > To cite [1]: "If the PHY reports an incorrect ID (or none at all) ...".
> > > I am pretty sure this is not the case here, instead we are looking at
> > > some missing platform bits, like a missing clock, reset, or most likely
> > > regulator. Or one of the existing resources is wrongly assigned or  
> > 
> > As I mentioned, PHY initialization is flaky on u-boot, so maybe that
> > assumption is correct. 
> > 
> > > configured? If the PHY is not (yet?) powered correctly when the code
> > > does the auto-detection via the MDIO bus, then the initialisation would  
> > 
> > If I recall correctly (I don't know if I kept it in my notes :c), that
> > could be the case. regulator-boot-on makes the NIC work (LEDs blink, at
> > least) but it doesn't get initialized. 
> > 
> > > fail. But since it works when overriding the auto-detection, I feel
> > > like we are papering over something here.
> > > Do you have the schematics for this board? I can only find the one for
> > > the Orange Pi Plus 2E, and I don't know how similar those two are. This
> > > shows *two* regulators, but both are activated by the same GPIO.  
> > 
> > I do. It's available on [4]
> 
> Oh damn it, I got lost in Orange Pi's naming maze again - and was looking
> for the wrong board! So thanks for the link, and this clears things up!
> 
> So yes, the Orange Pi *One* Plus, much like the Orange Pi 3, uses *two*
> regulators for Ethernet: one 3.3V from the PMIC's ALDO2 rail to power the
> PHY, and a discrete 2.5V regulator, enabled by GPIO PD6, for the voltage
> level on the MDIO lines. On top of this there is a reset line for the PHY,
> though this is held up by a pull-up resistor, so it *should* work,
> although we should describe this in the DT.
> 
> So the DT looks wrong then: The reg_gmac_3v3 is actually a 2.5V regulator,
> and phy-supply is aldo2. I think it was done the way it is to somehow make
> it work with the current DT binding and code, which just supports one
> regulator. And aldo2 is referenced as the source of reg_gmac_3v3, which
> smells like another hack to me.
> 
> > > It would also be interesting to see if any of Corentin's work for the
> > > Orange Pi 3 helps here?  
> > 
> > Adding [5] for reference here, thanks! Will check it out. 
> 
> This is an older version, there are actually updates. And he also mentions
> your board as well, so I think it just can sail in the wake of the OPi 3
> Ethernet enablement.
> 
> Can you try if this change, just applied to your .dts instead, works?
> https://github.com/montjoie/linux/commit/cf6e192eca1d59be630e6729d2cef9e897b3da8c

Hello, 

I've tried applying this change but it didn't seem to work :( 

I got these errors:

[    5.117220] dwmac-sun8i 5020000.ethernet: IRQ eth_wake_irq not found
[    5.124366] dwmac-sun8i 5020000.ethernet: IRQ eth_lpi not found
[    5.130645] dwmac-sun8i 5020000.ethernet: No regulator found
[    5.137133] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[    5.143925] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
[    5.157588] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
[    5.164905] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
[    5.172189] dwmac-sun8i 5020000.ethernet: COE Type 2
[    5.177213] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
[    5.184033] dwmac-sun8i 5020000.ethernet: Normal descriptors
[    5.189724] dwmac-sun8i 5020000.ethernet: Chain mode enabled
[    5.381149] dwmac-sun8i 5020000.ethernet: EMAC reset timeout
[    5.386863] dwmac-sun8i 5020000.ethernet eth0: stmmac_dvr_remove: removing driver
[    5.438851] dwmac-sun8i: probe of 5020000.ethernet failed with error -110

I think I understand what is going on in Corentin's patch though. Please
correct me if I'm wrong:

1. Instead of using the gmac-3v3, they use gmac-2v5 enabled by PD6.
2. For "phy-io", the 2v5 regulator is used
3. For "ephy", the 3v3 regulator is used (aldo2 already sends this 3v3
signal)

My changes are here:
https://github.com/retpolanne/linux/commit/45aa2abde2606f9164f9a97d092fab6a36d45165

Maybe I should try to use the existing 3v3 regulator alongside a new 2v5
regulator on the DT. 
> 
> Cheers,
> Andre
> 
> P.S. Is there any chance where I can reply/comment on your blog? It seems
> like I can clear some things up...
> 
> > [3] https://blog.retpolanne.com/hardware/embedded/2023/07/07/embedded-phy.html
> > [4] https://linux-sunxi.org/images/7/7c/OrangePi_OnePlus_Schematics_v2.0.pdf
> > [5] https://lore.kernel.org/netdev/20220509074857.195302-1-clabbe at baylibre.com/
> > 
> > Regards, Anne
> 

Regards, Anne


From paul at paul-moore.com  Mon Dec 18 16:45:34 2023
From: paul at paul-moore.com (Paul Moore)
Date: Mon, 18 Dec 2023 19:45:34 -0500
Subject: [PATCH v5 0/6] DCP as trusted keys backend
In-Reply-To: <20231215110639.45522-1-david@sigma-star.at>
References: <20231215110639.45522-1-david@sigma-star.at>
Message-ID: <CAHC9VhSRjwN=a9=V--m46_xh4fQNwZ9781YBCDpAmAV1mofhQg@mail.gmail.com>

On Fri, Dec 15, 2023 at 6:07?AM David Gstir <david at sigma-star.at> wrote:
>
> This is a revival of the previous patch set submitted by Richard Weinberger:
> https://lore.kernel.org/linux-integrity/20210614201620.30451-1-richard at nod.at/
>
> v4 is here:
> https://lore.kernel.org/keyrings/20231024162024.51260-1-david at sigma-star.at/
>
> v4 -> v5:
> - Make Kconfig for trust source check scalable as suggested by Jarkko Sakkinen
> - Add Acked-By from Herbert Xu to patch #1 - thanks!
> v3 -> v4:
> - Split changes on MAINTAINERS and documentation into dedicated patches
> - Use more concise wording in commit messages as suggested by Jarkko Sakkinen
> v2 -> v3:
> - Addressed review comments from Jarkko Sakkinen
> v1 -> v2:
> - Revive and rebase to latest version
> - Include review comments from Ahmad Fatoum
>
> The Data CoProcessor (DCP) is an IP core built into many NXP SoCs such
> as i.mx6ull.
>
> Similar to the CAAM engine used in more powerful SoCs, DCP can AES-
> encrypt/decrypt user data using a unique, never-disclosed,
> device-specific key. Unlike CAAM though, it cannot directly wrap and
> unwrap blobs in hardware. As DCP offers only the bare minimum feature
> set and a blob mechanism needs aid from software. A blob in this case
> is a piece of sensitive data (e.g. a key) that is encrypted and
> authenticated using the device-specific key so that unwrapping can only
> be done on the hardware where the blob was wrapped.
>
> This patch series adds a DCP based, trusted-key backend and is similar
> in spirit to the one by Ahmad Fatoum [0] that does the same for CAAM.
> It is of interest for similar use cases as the CAAM patch set, but for
> lower end devices, where CAAM is not available.
>
> Because constructing and parsing the blob has to happen in software,
> we needed to decide on a blob format and chose the following:
>
> struct dcp_blob_fmt {
>         __u8 fmt_version;
>         __u8 blob_key[AES_KEYSIZE_128];
>         __u8 nonce[AES_KEYSIZE_128];
>         __le32 payload_len;
>         __u8 payload[];
> } __packed;
>
> The `fmt_version` is currently 1.
>
> The encrypted key is stored in the payload area. It is AES-128-GCM
> encrypted using `blob_key` and `nonce`, GCM auth tag is attached at
> the end of the payload (`payload_len` does not include the size of
> the auth tag).
>
> The `blob_key` itself is encrypted in AES-128-ECB mode by DCP using
> the OTP or UNIQUE device key. A new `blob_key` and `nonce` are generated
> randomly, when sealing/exporting the DCP blob.
>
> This patchset was tested with dm-crypt on an i.MX6ULL board.
>
> [0] https://lore.kernel.org/keyrings/20220513145705.2080323-1-a.fatoum at pengutronix.de/
>
> David Gstir (6):
>   crypto: mxs-dcp: Add support for hardware-bound keys
>   KEYS: trusted: improve scalability of trust source config
>   KEYS: trusted: Introduce NXP DCP-backed trusted keys
>   MAINTAINERS: add entry for DCP-based trusted keys
>   docs: document DCP-backed trusted keys kernel params
>   docs: trusted-encrypted: add DCP as new trust source
>
>  .../admin-guide/kernel-parameters.txt         |  13 +
>  .../security/keys/trusted-encrypted.rst       |  85 +++++
>  MAINTAINERS                                   |   9 +
>  drivers/crypto/mxs-dcp.c                      | 104 +++++-
>  include/keys/trusted_dcp.h                    |  11 +
>  include/soc/fsl/dcp.h                         |  17 +
>  security/keys/trusted-keys/Kconfig            |  18 +-
>  security/keys/trusted-keys/Makefile           |   2 +
>  security/keys/trusted-keys/trusted_core.c     |   6 +-
>  security/keys/trusted-keys/trusted_dcp.c      | 311 ++++++++++++++++++
>  10 files changed, 562 insertions(+), 14 deletions(-)
>  create mode 100644 include/keys/trusted_dcp.h
>  create mode 100644 include/soc/fsl/dcp.h
>  create mode 100644 security/keys/trusted-keys/trusted_dcp.c

Jarkko, Mimi, David - if this patchset isn't already in your review
queue, can you take a look at it from a security/keys perspective?

Thanks.

-- 
paul-moore.com


From ck.hu at mediatek.com  Mon Dec 18 17:59:46 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 19 Dec 2023 01:59:46 +0000
Subject: [PATCH] drm/mediatek/dp: Add the HDCP feature for DisplayPort
In-Reply-To: <20231124085346.26602-1-mac.shen@mediatek.com>
References: <20231124085346.26602-1-mac.shen@mediatek.com>
Message-ID: <73674f38c33051c0dac151e9fe0cdac02198b4bb.camel@mediatek.com>

Hi, Mac:

On Fri, 2023-11-24 at 16:53 +0800, mac.shen wrote:
> Add tee client application, HDCP 1.x and 2.x authentication for
> DisplayPort
> to support the HDCP feature.
> 
> Signed-off-by: mac.shen <mac.shen at mediatek.com>
> 

[snip]

> +
> +static void mhal_dp_tx_hdcp1x_set_repeater(struct mtk_hdcp_info
> *hdcp_info, bool enable)
> +{
> +	if (enable)
> +		mtk_dp_reg_update_bits(hdcp_info->regs,
> MTK_DP_TRANS_P0_34A4, BIT(15), BIT(15));
> +	else
> +		mtk_dp_reg_update_bits(hdcp_info->regs,
> MTK_DP_TRANS_P0_34A4, 0,  BIT(15));
> +
> +#ifdef IF_ZERO
> +	if (hdcp_info->hdcp1x_info.repeater) {
> +		u8 temp;
> +
> +		temp = BIT(0); /* REAUTHENTICATION_ENABLE_IRQ_HPD */
> +		drm_dp_dpcd_write(hdcp_info->aux, DPCD_6803B, &temp,
> 1);
> +	}
> +#endif

IF_ZERO is not defined, so remove these.

Regards,
CK

> +}
> +

From quic_taozha at quicinc.com  Mon Dec 18 18:13:41 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Tue, 19 Dec 2023 10:13:41 +0800
Subject: [PATCH v3 2/8] coresight-tpda: Add support to configure CMB
 element
In-Reply-To: <88e51407-344e-4584-8711-29cc014c782b@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-3-git-send-email-quic_taozha@quicinc.com>
 <88e51407-344e-4584-8711-29cc014c782b@arm.com>
Message-ID: <b5965008-b51d-4bb7-8cf2-d21aa35d2205@quicinc.com>


On 12/18/2023 6:27 PM, Suzuki K Poulose wrote:
> On 21/11/2023 02:24, Tao Zhang wrote:
>> Read the CMB element size from the device tree. Set the register
>> bit that controls the CMB element size of the corresponding port.
>>
>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>> ---
>> ? drivers/hwtracing/coresight/coresight-tpda.c | 117 +++++++++++--------
>> ? drivers/hwtracing/coresight/coresight-tpda.h |?? 6 +
>> ? 2 files changed, 74 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c 
>> b/drivers/hwtracing/coresight/coresight-tpda.c
>> index 5f82737c37bb..e3762f38abb3 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpda.c
>> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
>> @@ -28,24 +28,54 @@ static bool coresight_device_is_tpdm(struct 
>> coresight_device *csdev)
>> ????????????? CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM);
>> ? }
>> ? +static void tpdm_clear_element_size(struct coresight_device *csdev)
>> +{
>> +??? struct tpda_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> +
>> +??? if (drvdata->dsb_esize)
>> +??????? drvdata->dsb_esize = 0;
>> +??? if (drvdata->cmb_esize)
>> +??????? drvdata->cmb_esize = 0;
>
> Why do we need the if (...) check here ?

The element size of all the TPDM sub-unit should be set to 0 here.

I will update this in the next patch series.

>
>> +}
>> +
>> +static void tpda_set_element_size(struct tpda_drvdata *drvdata, u32 
>> *val)
>> +{
>> +
>> +??? if (drvdata->dsb_esize == 64)
>> +??????? *val |= TPDA_Pn_CR_DSBSIZE;
>> +??? else if (drvdata->dsb_esize == 32)
>> +??????? *val &= ~TPDA_Pn_CR_DSBSIZE;
>> +
>> +??? if (drvdata->cmb_esize == 64)
>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x2);
>> +??? else if (drvdata->cmb_esize == 32)
>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x1);
>> +??? else if (drvdata->cmb_esize == 8)
>> +??????? *val &= ~TPDA_Pn_CR_CMBSIZE;
>> +}
>> +
>
>
>> ? /*
>> - * Read the DSB element size from the TPDM device
>> + * Read the element size from the TPDM device
>> ?? * Returns
>> - *??? The dsb element size read from the devicetree if available.
>> + *??? The element size read from the devicetree if available.
>> ?? *??? 0 - Otherwise, with a warning once.
>
> This doesn't match the function ? It return 0 on success and
> error (-EINVAL) on failure ?

0 means the element size property is found from the devicetree.

Otherwise, it will return error(-EINVAL).

I will update this in the next patch series.

>
>> ?? */
>> -static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
>> +static int tpdm_read_element_size(struct tpda_drvdata *drvdata,
>> +????????????????? struct coresight_device *csdev)
>> ? {
>> -??? int rc = 0;
>> -??? u8 size = 0;
>> -
>> -??? rc = fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>> -??????????? "qcom,dsb-element-size", &size);
>> +??? int rc = -EINVAL;
>> +
>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>> +??????????? "qcom,dsb-element-size", &drvdata->dsb_esize))
>> +??????? rc = 0;
>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>> +??????????? "qcom,cmb-element-size", &drvdata->cmb_esize))
>> +??????? rc = 0;
>
> Are we not silently resetting the error if the former failed ?
>
> Could we not :
>
> ????rc |= fwnode_...
>
> ????rc |= fwnode_...
>
> instead ?
>
> Also what is the expectation here ? Are these properties a MUST for
> TPDM ?

The TPDM must have one of the element size property. As long as one

can be found, this TPDM configuration can be considered valid. So this

function will return 0 if one of the element size property is found.


Best,

Tao

>
>> ????? if (rc)
>> ????????? dev_warn_once(&csdev->dev,
>> -??????????? "Failed to read TPDM DSB Element size: %d\n", rc);
>> +??????????? "Failed to read TPDM Element size: %d\n", rc);
>> ? -??? return size;
>> +??? return rc;
>> ? }
>> ? ? /*
>> @@ -56,11 +86,12 @@ static int tpdm_read_dsb_element_size(struct 
>> coresight_device *csdev)
>> ?? * Parameter "inport" is used to pass in the input port number
>> ?? * of TPDA, and it is set to -1 in the recursize call.
>> ?? */
>> -static int tpda_get_element_size(struct coresight_device *csdev,
>> +static int tpda_get_element_size(struct tpda_drvdata *drvdata,
>> +???????????????? struct coresight_device *csdev,
>> ?????????????????? int inport)
>> ? {
>> -??? int dsb_size = -ENOENT;
>> -??? int i, size;
>> +??? int rc = 0;
>> +??? int i;
>> ????? struct coresight_device *in;
>> ? ????? for (i = 0; i < csdev->pdata->nr_inconns; i++) {
>> @@ -74,25 +105,21 @@ static int tpda_get_element_size(struct 
>> coresight_device *csdev,
>> ????????????? continue;
>> ? ????????? if (coresight_device_is_tpdm(in)) {
>> -??????????? size = tpdm_read_dsb_element_size(in);
>> +??????????? if ((drvdata->dsb_esize) || (drvdata->cmb_esize))
>> +??????????????? return -EEXIST;
>> +??????????? rc = tpdm_read_element_size(drvdata, in);
>> +??????????? if (rc)
>> +??????????????? return rc;
>> ????????? } else {
>> ????????????? /* Recurse down the path */
>> -??????????? size = tpda_get_element_size(in, -1);
>> -??????? }
>> -
>> -??????? if (size < 0)
>> -??????????? return size;
>> -
>> -??????? if (dsb_size < 0) {
>> -??????????? /* Found a size, save it. */
>> -??????????? dsb_size = size;
>> -??????? } else {
>> -??????????? /* Found duplicate TPDMs */
>> -??????????? return -EEXIST;
>> +??????????? rc = tpda_get_element_size(drvdata, in, -1);
>> +??????????? if (rc)
>> +??????????????? return rc;
>> ????????? }
>> ????? }
>> ? -??? return dsb_size;
>> +
>> +??? return rc;
>> ? }
>> ? ? /* Settings pre enabling port control register */
>> @@ -109,7 +136,7 @@ static void tpda_enable_pre_port(struct 
>> tpda_drvdata *drvdata)
>> ? static int tpda_enable_port(struct tpda_drvdata *drvdata, int port)
>> ? {
>> ????? u32 val;
>> -??? int size;
>> +??? int rc;
>> ? ????? val = readl_relaxed(drvdata->base + TPDA_Pn_CR(port));
>> ????? /*
>> @@ -117,29 +144,21 @@ static int tpda_enable_port(struct tpda_drvdata 
>> *drvdata, int port)
>> ?????? * Set the bit to 0 if the size is 32
>> ?????? * Set the bit to 1 if the size is 64
>> ?????? */
>> -??? size = tpda_get_element_size(drvdata->csdev, port);
>> -??? switch (size) {
>> -??? case 32:
>> -??????? val &= ~TPDA_Pn_CR_DSBSIZE;
>> -??????? break;
>> -??? case 64:
>> -??????? val |= TPDA_Pn_CR_DSBSIZE;
>> -??????? break;
>> -??? case 0:
>> -??????? return -EEXIST;
>> -??? case -EEXIST:
>> +??? tpdm_clear_element_size(drvdata->csdev);
>> +??? rc = tpda_get_element_size(drvdata, drvdata->csdev, port);
>> +??? if (!rc && ((drvdata->dsb_esize) || (drvdata->cmb_esize))) {
>> +??????? tpda_set_element_size(drvdata, &val);
>> +??????? /* Enable the port */
>> +??????? val |= TPDA_Pn_CR_ENA;
>> +??????? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>> +??? } else if (rc == -EEXIST)
>> ????????? dev_warn_once(&drvdata->csdev->dev,
>> -??????????? "Detected multiple TPDMs on port %d", -EEXIST);
>> -??????? return -EEXIST;
>> -??? default:
>> -??????? return -EINVAL;
>> -??? }
>> -
>> -??? /* Enable the port */
>> -??? val |= TPDA_Pn_CR_ENA;
>> -??? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>> +????????????????? "Detected multiple TPDMs on port %d", -EEXIST);
>> +??? else
>> +??????? dev_warn_once(&drvdata->csdev->dev,
>> +????????????????? "Didn't find TPDM elem size");
>
> "element size"
>
>> ? -??? return 0;
>> +??? return rc;
>> ? }
>> ? ? static int __tpda_enable(struct tpda_drvdata *drvdata, int port)
>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.h 
>> b/drivers/hwtracing/coresight/coresight-tpda.h
>> index b3b38fd41b64..29164fd9711f 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpda.h
>> +++ b/drivers/hwtracing/coresight/coresight-tpda.h
>> @@ -10,6 +10,8 @@
>> ? #define TPDA_Pn_CR(n)??????? (0x004 + (n * 4))
>> ? /* Aggregator port enable bit */
>> ? #define TPDA_Pn_CR_ENA??????? BIT(0)
>> +/* Aggregator port CMB data set element size bit */
>> +#define TPDA_Pn_CR_CMBSIZE??????? GENMASK(7, 6)
>> ? /* Aggregator port DSB data set element size bit */
>> ? #define TPDA_Pn_CR_DSBSIZE??????? BIT(8)
>> ? @@ -25,6 +27,8 @@
>> ?? * @csdev:????? component vitals needed by the framework.
>> ?? * @spinlock:?? lock for the drvdata value.
>> ?? * @enable:???? enable status of the component.
>> + * @dsb_esize?? Record the DSB element size.
>> + * @cmb_esize?? Record the CMB element size.
>> ?? */
>> ? struct tpda_drvdata {
>> ????? void __iomem??????? *base;
>> @@ -32,6 +36,8 @@ struct tpda_drvdata {
>> ????? struct coresight_device??? *csdev;
>> ????? spinlock_t??????? spinlock;
>> ????? u8??????????? atid;
>> +??? u8??????????? dsb_esize;
>> +??? u8??????????? cmb_esize;
>> ? };
>> ? ? #endif? /* _CORESIGHT_CORESIGHT_TPDA_H */
>
> Suzuki
>
>


From martin.petersen at oracle.com  Mon Dec 18 18:18:53 2023
From: martin.petersen at oracle.com (Martin K. Petersen)
Date: Mon, 18 Dec 2023 21:18:53 -0500
Subject: [PATCH v8 00/10] Enable HS-G5 support on SM8550
In-Reply-To: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
References: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
Message-ID: <170294822172.2675590.9852477289938557441.b4-ty@oracle.com>

On Sat, 02 Dec 2023 04:36:06 -0800, Can Guo wrote:

> This series enables HS-G5 support on SM8550.
> 
> This series is rebased on below changes from Mani -
> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-1-manivannan.sadhasivam at linaro.org/
> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-2-manivannan.sadhasivam at linaro.org/
> 
> This series is tested on below HW combinations -
> SM8550 MTP + UFS4.0
> SM8550 QRD + UFS3.1
> SM8450 MTP + UFS3.1 (for regression test)
> SM8350 MTP + UFS3.1 (for regression test)
> 
> [...]

Applied to 6.8/scsi-queue, thanks!

[01/10] scsi: ufs: host: Rename structure ufs_dev_params to ufs_host_params
        https://git.kernel.org/mkp/scsi/c/fa3dca8251c4
[02/10] scsi: ufs: ufs-qcom: No need to set hs_rate after ufshcd_init_host_param()
        https://git.kernel.org/mkp/scsi/c/dc604b4c9d60
[03/10] scsi: ufs: ufs-qcom: Setup host power mode during init
        https://git.kernel.org/mkp/scsi/c/55820a7f2cb9
[04/10] scsi: ufs: ufs-qcom: Allow the first init start with the maximum supported gear
        https://git.kernel.org/mkp/scsi/c/743e1f596ccc
[05/10] scsi: ufs: ufs-qcom: Limit HS-G5 Rate-A to hosts with HW version 5
        https://git.kernel.org/mkp/scsi/c/9d8528a833fc
[06/10] scsi: ufs: ufs-qcom: Set initial PHY gear to max HS gear for HW ver 4 and newer
        https://git.kernel.org/mkp/scsi/c/0bd3cb895d19
[07/10] scsi: ufs: ufs-qcom: Check return value of phy_set_mode_ext()
        https://git.kernel.org/mkp/scsi/c/a68abdadfe13
[08/10] scsi: ufs: ufs-qcom: Add support for UFS device version detection
        https://git.kernel.org/mkp/scsi/c/dc7c948d74e1

-- 
Martin K. Petersen	Oracle Linux Engineering


From qiwuchen55 at gmail.com  Mon Dec 18 18:22:29 2023
From: qiwuchen55 at gmail.com (chenqiwu)
Date: Tue, 19 Dec 2023 10:22:29 +0800
Subject: [RESEND v3] arm64: Add USER_STACKTRACE support
Message-ID: <20231219022229.10230-1-qiwu.chen@transsion.com>

Currently, userstacktrace is unsupported for ftrace and uprobe
tracers on arm64. This patch uses the perf_callchain_user() code
as blueprint to implement the arch_stack_walk_user() which add
userstacktrace support on arm64.
Meanwhile, we can use arch_stack_walk_user() to simplify the
implementation of perf_callchain_user().
This patch is tested pass with ftrace, uprobe and perf tracers
profiling userstacktrace cases.

changes in v3:
  - update perf_callchain_user() to use arch_stack_walk_user()
    and delete the redundant code as Mark's suggestion in v2.
  - update the commit message.

Tested-by: chenqiwu <qiwu.chen at transsion.com>
Signed-off-by: chenqiwu <qiwu.chen at transsion.com>
---
 arch/arm64/Kconfig                 |   1 +
 arch/arm64/kernel/perf_callchain.c | 118 +---------------------------
 arch/arm64/kernel/stacktrace.c     | 120 +++++++++++++++++++++++++++++
 3 files changed, 125 insertions(+), 114 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..4c5066f88dd2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -255,6 +255,7 @@ config ARM64
 	select TRACE_IRQFLAGS_SUPPORT
 	select TRACE_IRQFLAGS_NMI_SUPPORT
 	select HAVE_SOFTIRQ_ON_OWN_STACK
+	select USER_STACKTRACE_SUPPORT
 	help
 	  ARM 64-bit (AArch64) Linux support.
 
diff --git a/arch/arm64/kernel/perf_callchain.c b/arch/arm64/kernel/perf_callchain.c
index 6d157f32187b..e8ed5673f481 100644
--- a/arch/arm64/kernel/perf_callchain.c
+++ b/arch/arm64/kernel/perf_callchain.c
@@ -10,94 +10,12 @@
 
 #include <asm/pointer_auth.h>
 
-struct frame_tail {
-	struct frame_tail	__user *fp;
-	unsigned long		lr;
-} __attribute__((packed));
-
-/*
- * Get the return address for a single stackframe and return a pointer to the
- * next frame tail.
- */
-static struct frame_tail __user *
-user_backtrace(struct frame_tail __user *tail,
-	       struct perf_callchain_entry_ctx *entry)
-{
-	struct frame_tail buftail;
-	unsigned long err;
-	unsigned long lr;
-
-	/* Also check accessibility of one struct frame_tail beyond */
-	if (!access_ok(tail, sizeof(buftail)))
-		return NULL;
-
-	pagefault_disable();
-	err = __copy_from_user_inatomic(&buftail, tail, sizeof(buftail));
-	pagefault_enable();
-
-	if (err)
-		return NULL;
-
-	lr = ptrauth_strip_user_insn_pac(buftail.lr);
-
-	perf_callchain_store(entry, lr);
-
-	/*
-	 * Frame pointers should strictly progress back up the stack
-	 * (towards higher addresses).
-	 */
-	if (tail >= buftail.fp)
-		return NULL;
-
-	return buftail.fp;
-}
-
-#ifdef CONFIG_COMPAT
-/*
- * The registers we're interested in are at the end of the variable
- * length saved register structure. The fp points at the end of this
- * structure so the address of this struct is:
- * (struct compat_frame_tail *)(xxx->fp)-1
- *
- * This code has been adapted from the ARM OProfile support.
- */
-struct compat_frame_tail {
-	compat_uptr_t	fp; /* a (struct compat_frame_tail *) in compat mode */
-	u32		sp;
-	u32		lr;
-} __attribute__((packed));
-
-static struct compat_frame_tail __user *
-compat_user_backtrace(struct compat_frame_tail __user *tail,
-		      struct perf_callchain_entry_ctx *entry)
+static bool callchain_trace(void *data, unsigned long pc)
 {
-	struct compat_frame_tail buftail;
-	unsigned long err;
-
-	/* Also check accessibility of one struct frame_tail beyond */
-	if (!access_ok(tail, sizeof(buftail)))
-		return NULL;
-
-	pagefault_disable();
-	err = __copy_from_user_inatomic(&buftail, tail, sizeof(buftail));
-	pagefault_enable();
-
-	if (err)
-		return NULL;
-
-	perf_callchain_store(entry, buftail.lr);
-
-	/*
-	 * Frame pointers should strictly progress back up the stack
-	 * (towards higher addresses).
-	 */
-	if (tail + 1 >= (struct compat_frame_tail __user *)
-			compat_ptr(buftail.fp))
-		return NULL;
+	struct perf_callchain_entry_ctx *entry = data;
 
-	return (struct compat_frame_tail __user *)compat_ptr(buftail.fp) - 1;
+	return perf_callchain_store(entry, pc) == 0;
 }
-#endif /* CONFIG_COMPAT */
 
 void perf_callchain_user(struct perf_callchain_entry_ctx *entry,
 			 struct pt_regs *regs)
@@ -107,35 +25,7 @@ void perf_callchain_user(struct perf_callchain_entry_ctx *entry,
 		return;
 	}
 
-	perf_callchain_store(entry, regs->pc);
-
-	if (!compat_user_mode(regs)) {
-		/* AARCH64 mode */
-		struct frame_tail __user *tail;
-
-		tail = (struct frame_tail __user *)regs->regs[29];
-
-		while (entry->nr < entry->max_stack &&
-		       tail && !((unsigned long)tail & 0x7))
-			tail = user_backtrace(tail, entry);
-	} else {
-#ifdef CONFIG_COMPAT
-		/* AARCH32 compat mode */
-		struct compat_frame_tail __user *tail;
-
-		tail = (struct compat_frame_tail __user *)regs->compat_fp - 1;
-
-		while ((entry->nr < entry->max_stack) &&
-			tail && !((unsigned long)tail & 0x3))
-			tail = compat_user_backtrace(tail, entry);
-#endif
-	}
-}
-
-static bool callchain_trace(void *data, unsigned long pc)
-{
-	struct perf_callchain_entry_ctx *entry = data;
-	return perf_callchain_store(entry, pc) == 0;
+	arch_stack_walk_user(callchain_trace, entry, regs);
 }
 
 void perf_callchain_kernel(struct perf_callchain_entry_ctx *entry,
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 17f66a74c745..7f9ab5a37096 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -240,3 +240,123 @@ void show_stack(struct task_struct *tsk, unsigned long *sp, const char *loglvl)
 	dump_backtrace(NULL, tsk, loglvl);
 	barrier();
 }
+
+/*
+ * The struct defined for userspace stack frame in AARCH64 mode.
+ */
+struct frame_tail {
+	struct frame_tail	__user *fp;
+	unsigned long		lr;
+} __attribute__((packed));
+
+/*
+ * Get the return address for a single stackframe and return a pointer to the
+ * next frame tail.
+ */
+static struct frame_tail __user *
+unwind_user_frame(struct frame_tail __user *tail, void *cookie,
+	       stack_trace_consume_fn consume_entry)
+{
+	struct frame_tail buftail;
+	unsigned long err;
+	unsigned long lr;
+
+	/* Also check accessibility of one struct frame_tail beyond */
+	if (!access_ok(tail, sizeof(buftail)))
+		return NULL;
+
+	pagefault_disable();
+	err = __copy_from_user_inatomic(&buftail, tail, sizeof(buftail));
+	pagefault_enable();
+
+	if (err)
+		return NULL;
+
+	lr = ptrauth_strip_user_insn_pac(buftail.lr);
+
+	if (!consume_entry(cookie, lr))
+		return NULL;
+
+	/*
+	 * Frame pointers should strictly progress back up the stack
+	 * (towards higher addresses).
+	 */
+	if (tail >= buftail.fp)
+		return NULL;
+
+	return buftail.fp;
+}
+
+#ifdef CONFIG_COMPAT
+/*
+ * The registers we're interested in are at the end of the variable
+ * length saved register structure. The fp points at the end of this
+ * structure so the address of this struct is:
+ * (struct compat_frame_tail *)(xxx->fp)-1
+ *
+ * This code has been adapted from the ARM OProfile support.
+ */
+struct compat_frame_tail {
+	compat_uptr_t	fp; /* a (struct compat_frame_tail *) in compat mode */
+	u32		sp;
+	u32		lr;
+} __attribute__((packed));
+
+static struct compat_frame_tail __user *
+unwind_compat_user_frame(struct compat_frame_tail __user *tail, void *cookie,
+				stack_trace_consume_fn consume_entry)
+{
+	struct compat_frame_tail buftail;
+	unsigned long err;
+
+	/* Also check accessibility of one struct frame_tail beyond */
+	if (!access_ok(tail, sizeof(buftail)))
+		return NULL;
+
+	pagefault_disable();
+	err = __copy_from_user_inatomic(&buftail, tail, sizeof(buftail));
+	pagefault_enable();
+
+	if (err)
+		return NULL;
+
+	if (!consume_entry(cookie, buftail.lr))
+		return NULL;
+
+	/*
+	 * Frame pointers should strictly progress back up the stack
+	 * (towards higher addresses).
+	 */
+	if (tail + 1 >= (struct compat_frame_tail __user *)
+			compat_ptr(buftail.fp))
+		return NULL;
+
+	return (struct compat_frame_tail __user *)compat_ptr(buftail.fp) - 1;
+}
+#endif /* CONFIG_COMPAT */
+
+
+void arch_stack_walk_user(stack_trace_consume_fn consume_entry, void *cookie,
+					const struct pt_regs *regs)
+{
+	if (!consume_entry(cookie, regs->pc))
+		return;
+
+	if (!compat_user_mode(regs)) {
+		/* AARCH64 mode */
+		struct frame_tail __user *tail;
+
+		tail = (struct frame_tail __user *)regs->regs[29];
+		while (tail && !((unsigned long)tail & 0x7))
+			tail = unwind_user_frame(tail, cookie, consume_entry);
+	} else {
+#ifdef CONFIG_COMPAT
+		/* AARCH32 compat mode */
+		struct compat_frame_tail __user *tail;
+
+		tail = (struct compat_frame_tail __user *)regs->compat_fp - 1;
+		while (tail && !((unsigned long)tail & 0x3))
+			tail = unwind_compat_user_frame(tail, cookie, consume_entry);
+#endif
+	}
+}
-- 
2.25.1



From xiaobo55x at gmail.com  Mon Dec 18 18:28:31 2023
From: xiaobo55x at gmail.com (Haibo Xu)
Date: Tue, 19 Dec 2023 10:28:31 +0800
Subject: [PATCH v4 08/11] KVM: riscv: selftests: Add guest helper to get
 vcpu id
In-Reply-To: <20231213-b02db86aaf7957be22b200f1@orel>
References: <cover.1702371136.git.haibo1.xu@intel.com> <02f6c9ccaaeb4ceb67137863e0317f62cef62496.1702371136.git.haibo1.xu@intel.com>
 <20231213-b02db86aaf7957be22b200f1@orel>
Message-ID: <CAJve8okOO=e66Kko3LyDfsD+tRZvDGf_Zgmog-u5TUzk1JZ1RA@mail.gmail.com>

On Wed, Dec 13, 2023 at 10:08?PM Andrew Jones <ajones at ventanamicro.com> wrote:
>
> On Tue, Dec 12, 2023 at 05:31:17PM +0800, Haibo Xu wrote:
> > Add guest_get_vcpuid() helper to simplify accessing to per-cpu
> > private data. The sscratch CSR was used to store the vcpu id.
> >
> > Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
> > Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
> > ---
> >  tools/testing/selftests/kvm/include/aarch64/processor.h | 4 ----
> >  tools/testing/selftests/kvm/include/kvm_util_base.h     | 9 +++++++++
> >  tools/testing/selftests/kvm/lib/riscv/processor.c       | 8 ++++++++
> >  3 files changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/testing/selftests/kvm/include/aarch64/processor.h b/tools/testing/selftests/kvm/include/aarch64/processor.h
> > index c42d683102c7..16ae0ac01879 100644
> > --- a/tools/testing/selftests/kvm/include/aarch64/processor.h
> > +++ b/tools/testing/selftests/kvm/include/aarch64/processor.h
> > @@ -226,8 +226,4 @@ void smccc_smc(uint32_t function_id, uint64_t arg0, uint64_t arg1,
> >              uint64_t arg2, uint64_t arg3, uint64_t arg4, uint64_t arg5,
> >              uint64_t arg6, struct arm_smccc_res *res);
> >
> > -
> > -
> > -uint32_t guest_get_vcpuid(void);
> > -
> >  #endif /* SELFTEST_KVM_PROCESSOR_H */
> > diff --git a/tools/testing/selftests/kvm/include/kvm_util_base.h b/tools/testing/selftests/kvm/include/kvm_util_base.h
> > index a18db6a7b3cf..666438113d22 100644
> > --- a/tools/testing/selftests/kvm/include/kvm_util_base.h
> > +++ b/tools/testing/selftests/kvm/include/kvm_util_base.h
> > @@ -932,4 +932,13 @@ void kvm_selftest_arch_init(void);
> >
> >  void kvm_arch_vm_post_create(struct kvm_vm *vm);
> >
> > +void vm_init_vector_tables(struct kvm_vm *vm);
> > +void vcpu_init_vector_tables(struct kvm_vcpu *vcpu);
> > +
> > +struct ex_regs;
> > +typedef void(*exception_handler_fn)(struct ex_regs *);
> > +void vm_install_exception_handler(struct kvm_vm *vm, int vector, exception_handler_fn handler);
>
> I think something happend on rebase since the above should be in a
> different patch (and were for v3). I suggest checking your previous
> and current version branches with git-range-diff after rebasing in
> order to catch stuff like this.
>
> Thanks,
> drew
>

Thanks for pointing it out. Will fix it in v5.

> > +
> > +uint32_t guest_get_vcpuid(void);
> > +
> >  #endif /* SELFTEST_KVM_UTIL_BASE_H */
> > diff --git a/tools/testing/selftests/kvm/lib/riscv/processor.c b/tools/testing/selftests/kvm/lib/riscv/processor.c
> > index efd9ac4b0198..39a1e9902dec 100644
> > --- a/tools/testing/selftests/kvm/lib/riscv/processor.c
> > +++ b/tools/testing/selftests/kvm/lib/riscv/processor.c
> > @@ -316,6 +316,9 @@ struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, uint32_t vcpu_id,
> >       vcpu_set_reg(vcpu, RISCV_CORE_REG(regs.sp), stack_vaddr + stack_size);
> >       vcpu_set_reg(vcpu, RISCV_CORE_REG(regs.pc), (unsigned long)guest_code);
> >
> > +     /* Setup sscratch for guest_get_vcpuid() */
> > +     vcpu_set_reg(vcpu, RISCV_CSR_REG(sscratch), vcpu_id);
> > +
> >       /* Setup default exception vector of guest */
> >       vcpu_set_reg(vcpu, RISCV_CSR_REG(stvec), (unsigned long)guest_unexp_trap);
> >
> > @@ -436,3 +439,8 @@ void vm_install_interrupt_handler(struct kvm_vm *vm, exception_handler_fn handle
> >
> >       handlers->exception_handlers[1][0] = handler;
> >  }
> > +
> > +uint32_t guest_get_vcpuid(void)
> > +{
> > +     return csr_read(CSR_SSCRATCH);
> > +}
> > --
> > 2.34.1
> >


From ck.hu at mediatek.com  Mon Dec 18 18:35:43 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 19 Dec 2023 02:35:43 +0000
Subject: [PATCH v4 1/1] drm/mediatek: Fix errors when reporting rotation
 capability
In-Reply-To: <20231124100052.18599-2-shawn.sung@mediatek.com>
References: <20231124100052.18599-1-shawn.sung@mediatek.com>
	 <20231124100052.18599-2-shawn.sung@mediatek.com>
Message-ID: <0eb813192c02ac6f8d05fe9f4fc805517f5cb97b.camel@mediatek.com>

Hi, Hsiao-chien:

On Fri, 2023-11-24 at 18:00 +0800, Hsiao Chien Sung wrote:
> Create rotation property according to the hardware capability.
> Since currently OVL of all chips support same rotation,
> no need to define it in the driver data.
> 
> Fixes: 84d805753983 ("drm/mediatek: Support reflect-y plane
> rotation")
> 
> Reviewed-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno at collabora.com>
> Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_drv.h        |  1 +
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c        | 18 ++++++--------
> ----
>  .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c    |  9 +++++++++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c    |  1 +
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c       |  2 +-
>  5 files changed, 18 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 4d6e8b667bc3..c5afeb7c5527 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -127,6 +127,7 @@ void mtk_ovl_adaptor_register_vblank_cb(struct
> device *dev, void (*vblank_cb)(vo
>  void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev);
>  void mtk_ovl_adaptor_enable_vblank(struct device *dev);
>  void mtk_ovl_adaptor_disable_vblank(struct device *dev);
> +unsigned int mtk_ovl_adaptor_supported_rotations(struct device
> *dev);
>  void mtk_ovl_adaptor_start(struct device *dev);
>  void mtk_ovl_adaptor_stop(struct device *dev);
>  unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index ecc38932fd44..319bbfde5cf9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -415,6 +415,10 @@ unsigned int mtk_ovl_layer_nr(struct device
> *dev)
> 
>  unsigned int mtk_ovl_supported_rotations(struct device *dev)
>  {
> +	/*
> +	 * although currently OVL can only do reflection,
> +	 * reflect x + reflect y = rotate 180
> +	 */
>  	return DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180 |
>  	       DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
>  }
> @@ -423,27 +427,17 @@ int mtk_ovl_layer_check(struct device *dev,
> unsigned int idx,
>  			struct mtk_plane_state *mtk_state)
>  {
>  	struct drm_plane_state *state = &mtk_state->base;
> -	unsigned int rotation = 0;
> 
> -	rotation = drm_rotation_simplify(state->rotation,
> -					 DRM_MODE_ROTATE_0 |
> -					 DRM_MODE_REFLECT_X |
> -					 DRM_MODE_REFLECT_Y);
> -	rotation &= ~DRM_MODE_ROTATE_0;
> -
> -	/* We can only do reflection, not rotation */
> -	if ((rotation & DRM_MODE_ROTATE_MASK) != 0)
> +	if (state->rotation & ~mtk_ovl_supported_rotations(dev))
>  		return -EINVAL;

The commit message of this patch is "Create rotation property according
to the hardware capability". I think this modification is not related
to create property, so separate this to another patch.

> 
>  	/*
>  	 * TODO: Rotating/reflecting YUV buffers is not supported at
> this time.
>  	 *	 Only RGB[AX] variants are supported.
>  	 */
> -	if (state->fb->format->is_yuv && rotation != 0)
> +	if (state->fb->format->is_yuv && (state->rotation &
> ~DRM_MODE_ROTATE_0))
>  		return -EINVAL;
> 
> -	state->rotation = rotation;
> -
>  	return 0;
>  }
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> index 4398db9a6276..273c79d37bef 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> @@ -383,6 +383,15 @@ void mtk_ovl_adaptor_register_vblank_cb(struct
> device *dev, void (*vblank_cb)(vo
>  				     vblank_cb, vblank_cb_data);
>  }
> 
> +unsigned int mtk_ovl_adaptor_supported_rotations(struct device *dev)
> +{
> +	/*
> +	 * should still return DRM_MODE_ROTATE_0 if rotation is not
> supported,
> +	 * or IGT will fail.
> +	 */
> +	return DRM_MODE_ROTATE_0;
> +}
> +
>  void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev)
>  {
>  	struct mtk_disp_ovl_adaptor *ovl_adaptor =
> dev_get_drvdata(dev);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index ffa4868b1222..206dd6f6f99e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -422,6 +422,7 @@ static const struct mtk_ddp_comp_funcs
> ddp_ovl_adaptor = {
>  	.remove = mtk_ovl_adaptor_remove_comp,
>  	.get_formats = mtk_ovl_adaptor_get_formats,
>  	.get_num_formats = mtk_ovl_adaptor_get_num_formats,
> +	.supported_rotations = mtk_ovl_adaptor_supported_rotations,
>  };
> 
>  static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] =
> {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index e2ec61b69618..894c39a38a58 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -344,7 +344,7 @@ int mtk_plane_init(struct drm_device *dev, struct
> drm_plane *plane,
>  		return err;
>  	}
> 
> -	if (supported_rotations & ~DRM_MODE_ROTATE_0) {
> +	if (supported_rotations) {

Why need this modification?
Before Sean's patch [1], only support rotate 0 and does not create
property and it works. Why does it must create property for only
support rotate 0?


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek/mtk_drm_plane.c?h=v6.7-rc6&id=ef87d3e2dd251374c5c9fa3b6502aeff8fe29da9

Regards,
CK

>  		err = drm_plane_create_rotation_property(plane,
>  							 DRM_MODE_ROTAT
> E_0,
>  							 supported_rota
> tions);
> --
> 2.39.2
> 

From quic_taozha at quicinc.com  Mon Dec 18 18:43:19 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Tue, 19 Dec 2023 10:43:19 +0800
Subject: [PATCH v3 6/8] coresight-tpdm: Add timestamp control register
 support for the CMB
In-Reply-To: <ebd7e310-d1b4-4b2e-a915-6241e04763d4@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-7-git-send-email-quic_taozha@quicinc.com>
 <ebd7e310-d1b4-4b2e-a915-6241e04763d4@arm.com>
Message-ID: <b61c3d70-7277-4fe7-ab67-8afc1062c737@quicinc.com>


On 12/18/2023 6:46 PM, Suzuki K Poulose wrote:
> On 21/11/2023 02:24, Tao Zhang wrote:
>> CMB_TIER register is CMB subunit timestamp insertion enable register.
>> Bit 0 is PATT_TSENAB bit. Set this bit to 1 to request a timestamp
>> following a CMB interface pattern match. Bit 1 is XTRIG_TSENAB bit.
>> Set this bit to 1 to request a timestamp following a CMB CTI timestamp
>> request. Bit 2 is TS_ALL bit. Set this bit to 1 to request timestamp
>> for all packets.
>>
>> Reviewed-by: James Clark <james.clark at arm.com>
>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
>> ---
>> ? .../testing/sysfs-bus-coresight-devices-tpdm? |? 35 ++++++
>> ? drivers/hwtracing/coresight/coresight-tpdm.c? | 116 +++++++++++++++++-
>> ? drivers/hwtracing/coresight/coresight-tpdm.h? |? 14 +++
>> ? 3 files changed, 162 insertions(+), 3 deletions(-)
>>
>> diff --git 
>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm 
>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>> index 53662ce7c2d0..e0b77107be13 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>> @@ -214,3 +214,38 @@ KernelVersion??? 6.7
>> ? Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>> Zhang (QUIC) <quic_taozha at quicinc.com>
>> ? Description:
>> ????????? (RW) Set/Get the mask of the pattern for the CMB subunit TPDM.
>> +
>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
>> +Date:??????? September 2023
>> +KernelVersion??? 6.7
>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang 
>> (QUIC) <quic_taozha at quicinc.com>
>> +Description:
>> +??????? (Write) Set the pattern timestamp of CMB tpdm. Read
>> +??????? the pattern timestamp of CMB tpdm.
>> +
>> +??????? Accepts only one of the 2 values -? 0 or 1.
>> +??????? 0 : Disable CMB pattern timestamp.
>> +??????? 1 : Enable CMB pattern timestamp.
>> +
>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
>> +Date:??????? September 2023
>> +KernelVersion??? 6.7
>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang 
>> (QUIC) <quic_taozha at quicinc.com>
>> +Description:
>> +??????? (RW) Set/Get the trigger timestamp of the CMB for tpdm.
>> +
>> +??????? Accepts only one of the 2 values -? 0 or 1.
>> +??????? 0 : Set the CMB trigger type to false
>> +??????? 1 : Set the CMB trigger type to true
>> +
>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
>> +Date:??????? September 2023
>> +KernelVersion??? 6.7
>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang 
>> (QUIC) <quic_taozha at quicinc.com>
>> +Description:
>> +??????? (RW) Read or write the status of timestamp upon all interface.
>> +??????? Only value 0 and 1? can be written to this node. Set this 
>> node to 1 to requeset
>> +??????? timestamp to all trace packet.
>> +??????? Accepts only one of the 2 values -? 0 or 1.
>> +??????? 0 : Disable the timestamp of all trace packets.
>> +??????? 1 : Enable the timestamp of all trace packets.
>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>> index 894d4309f1c7..f6cda5616e84 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>> @@ -331,6 +331,36 @@ static void tpdm_enable_dsb(struct tpdm_drvdata 
>> *drvdata)
>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>> ? }
>> ? +static void set_cmb_tier(struct tpdm_drvdata *drvdata)
>> +{
>> +??? u32 val;
>> +
>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_TIER);
>> +
>> +??? /* Clear all relevant fields */
>> +??? val &= ~(TPDM_CMB_TIER_PATT_TSENAB | TPDM_CMB_TIER_TS_ALL |
>> +???????? TPDM_CMB_TIER_XTRIG_TSENAB);
>> +
>> +??? /* Set pattern timestamp type and enablement */
>> +??? if (drvdata->cmb->patt_ts)
>> +??????? val |= TPDM_CMB_TIER_PATT_TSENAB;
>
> ?-- cut --
>> +??? else
>> +??????? val &= ~TPDM_CMB_TIER_PATT_TSENAB;
>
>
> All the else cases in this function are superfluous. Please remove all
> of them.
I will update this in the next patch.
>
>> +
>> +??? /* Set trigger timestamp */
>> +??? if (drvdata->cmb->trig_ts)
>> +??????? val |= TPDM_CMB_TIER_XTRIG_TSENAB;
>> +??? else
>> +??????? val &= ~TPDM_CMB_TIER_XTRIG_TSENAB;
>> +
>> +??? /* Set all timestamp enablement*/
>> +??? if (drvdata->cmb->ts_all)
>> +??????? val |= TPDM_CMB_TIER_TS_ALL;
>> +??? else
>> +??????? val &= ~TPDM_CMB_TIER_TS_ALL;
>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>> +}
>> +
>> ? static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>> ? {
>> ????? u32 val, i;
>> @@ -347,6 +377,8 @@ static void tpdm_enable_cmb(struct tpdm_drvdata 
>> *drvdata)
>> ????????????????? drvdata->base + TPDM_CMB_XPMR(i));
>> ????? }
>> ? +??? set_cmb_tier(drvdata);
>> +
>> ????? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>> ????? /*
>> ?????? * Set to 0 for continuous CMB collection mode,
>> @@ -695,9 +727,17 @@ static ssize_t enable_ts_show(struct device *dev,
>> ??????????????????? char *buf)
>> ? {
>> ????? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +??? ssize_t size = 0;
>> ? -??? return sysfs_emit(buf, "%u\n",
>> -???????????? (unsigned int)drvdata->dsb->patt_ts);
>> +??? if (tpdm_has_dsb_dataset(drvdata))
>> +??????? size = sysfs_emit(buf, "%u\n",
>> +???????????????? (unsigned int)drvdata->dsb->patt_ts);
>> +
>> +??? if (tpdm_has_cmb_dataset(drvdata))
>> +??????? size = sysfs_emit(buf, "%u\n",
>> +???????????????? (unsigned int)drvdata->cmb->patt_ts);
>
> Why does this need to show two values ? This must only show ONE value.
> How you deduce that might be based on the availability of the feature
> set. Or store the TS value in the drvdata and use that instead for
> controlling CMB/DSB.

Since both of CMB/DSB need to have "enable_ts" SysFs file, can I 
separate them

as "enable_dsb_ts" and "enable_cmb_ts"? The path will be like below.

tpdm0/dsb_patt/enable_dsb_ts

tpdm1/cmb_patt/enable_cmb_ts

Is this design appropriate?

>
> Also, the sysfs documentation needs update, if this is going to
> control the CMB.

Sure. I will update the SysFs documentation according to the 
modification in the

next patch series.


Best,

Tao

>
> Suzuki
>
>
>> +
>> +??? return size;
>> ? }
>> ? ? /*
>> @@ -715,8 +755,13 @@ static ssize_t enable_ts_store(struct device *dev,
>> ????????? return -EINVAL;
>> ? ????? spin_lock(&drvdata->spinlock);
>> -??? drvdata->dsb->patt_ts = !!val;
>> +??? if (tpdm_has_dsb_dataset(drvdata))
>> +??????? drvdata->dsb->patt_ts = !!val;
>> +
>> +??? if (tpdm_has_cmb_dataset(drvdata))
>> +??????? drvdata->cmb->patt_ts = !!val;
>> ????? spin_unlock(&drvdata->spinlock);
>> +
>> ????? return size;
>> ? }
>> ? static DEVICE_ATTR_RW(enable_ts);
>> @@ -851,6 +896,68 @@ static ssize_t cmb_mode_store(struct device *dev,
>> ? }
>> ? static DEVICE_ATTR_RW(cmb_mode);
>> ? +static ssize_t cmb_ts_all_show(struct device *dev,
>> +?????????????????? struct device_attribute *attr,
>> +?????????????????? char *buf)
>> +{
>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +
>> +??? return sysfs_emit(buf, "%u\n",
>> +????????????? (unsigned int)drvdata->cmb->ts_all);
>> +}
>> +
>> +static ssize_t cmb_ts_all_store(struct device *dev,
>> +??????????????? struct device_attribute *attr,
>> +??????????????? const char *buf,
>> +??????????????? size_t size)
>> +{
>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +??? unsigned long val;
>> +
>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>> +??????? return -EINVAL;
>> +
>> +??? spin_lock(&drvdata->spinlock);
>> +??? if (val)
>> +??????? drvdata->cmb->ts_all = true;
>> +??? else
>> +??????? drvdata->cmb->ts_all = false;
>> +??? spin_unlock(&drvdata->spinlock);
>> +??? return size;
>> +}
>> +static DEVICE_ATTR_RW(cmb_ts_all);
>> +
>> +static ssize_t cmb_trig_ts_show(struct device *dev,
>> +??????????????? struct device_attribute *attr,
>> +??????????????? char *buf)
>> +{
>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +
>> +??? return sysfs_emit(buf, "%u\n",
>> +????????????? (unsigned int)drvdata->cmb->trig_ts);
>> +}
>> +
>> +static ssize_t cmb_trig_ts_store(struct device *dev,
>> +???????????????? struct device_attribute *attr,
>> +???????????????? const char *buf,
>> +???????????????? size_t size)
>> +{
>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +??? unsigned long val;
>> +
>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>> +??????? return -EINVAL;
>> +
>> +??? spin_lock(&drvdata->spinlock);
>> +??? if (val)
>> +??????? drvdata->cmb->trig_ts = true;
>> +??? else
>> +??????? drvdata->cmb->trig_ts = false;
>> +??? spin_unlock(&drvdata->spinlock);
>> +??? return size;
>> +}
>> +static DEVICE_ATTR_RW(cmb_trig_ts);
>> +
>> ? static struct attribute *tpdm_dsb_edge_attrs[] = {
>> ????? &dev_attr_ctrl_idx.attr,
>> ????? &dev_attr_ctrl_val.attr,
>> @@ -973,6 +1080,7 @@ static struct attribute *tpdm_cmb_patt_attrs[] = {
>> ????? CMB_PATT_ATTR(1),
>> ????? CMB_PATT_MASK_ATTR(0),
>> ????? CMB_PATT_MASK_ATTR(1),
>> +??? &dev_attr_enable_ts.attr,
>> ????? NULL,
>> ? };
>> ? @@ -985,6 +1093,8 @@ static struct attribute *tpdm_dsb_attrs[] = {
>> ? ? static struct attribute *tpdm_cmb_attrs[] = {
>> ????? &dev_attr_cmb_mode.attr,
>> +??? &dev_attr_cmb_ts_all.attr,
>> +??? &dev_attr_cmb_trig_ts.attr,
>> ????? NULL,
>> ? };
>> ? diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>> index e90d008c1cb2..65b7ca6c4077 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>> @@ -11,6 +11,8 @@
>> ? ? /* CMB Subunit Registers */
>> ? #define TPDM_CMB_CR??????? (0xA00)
>> +/*CMB subunit timestamp insertion enable register*/
>> +#define TPDM_CMB_TIER??????? (0xA04)
>> ? /*CMB subunit timestamp pattern registers*/
>> ? #define TPDM_CMB_TPR(n)??????? (0xA08 + (n * 4))
>> ? /*CMB subunit timestamp pattern mask registers*/
>> @@ -24,6 +26,12 @@
>> ? #define TPDM_CMB_CR_ENA??????? BIT(0)
>> ? /* Trace collection mode for CMB subunit */
>> ? #define TPDM_CMB_CR_MODE??? BIT(1)
>> +/* Timestamp control for pattern match */
>> +#define TPDM_CMB_TIER_PATT_TSENAB??? BIT(0)
>> +/* CMB CTI timestamp request */
>> +#define TPDM_CMB_TIER_XTRIG_TSENAB??? BIT(1)
>> +/* For timestamp fo all trace */
>> +#define TPDM_CMB_TIER_TS_ALL??????? BIT(2)
>> ? ? /*Patten register number*/
>> ? #define TPDM_CMB_MAX_PATT??????? 2
>> @@ -217,6 +225,9 @@ struct dsb_dataset {
>> ?? * @patt_mask:??????? Save value for pattern mask
>> ?? * @trig_patt:??????? Save value for trigger pattern
>> ?? * @trig_patt_mask:?? Save value for trigger pattern mask
>> + * @patt_ts:????????? Indicates if pattern match for timestamp is 
>> enabled.
>> + * @trig_ts:????????? Indicates if CTI trigger for timestamp is 
>> enabled.
>> + * @ts_all:?????????? Indicates if timestamp is enabled for all 
>> packets.
>> ?? */
>> ? struct cmb_dataset {
>> ????? u32??????????? trace_mode;
>> @@ -224,6 +235,9 @@ struct cmb_dataset {
>> ????? u32??????????? patt_mask[TPDM_CMB_MAX_PATT];
>> ????? u32??????????? trig_patt[TPDM_CMB_MAX_PATT];
>> ????? u32??????????? trig_patt_mask[TPDM_CMB_MAX_PATT];
>> +??? bool??????????? patt_ts;
>> +??? bool??????????? trig_ts;
>> +??? bool??????????? ts_all;
>> ? };
>> ? ? /**
>


From bo.ye at mediatek.com  Mon Dec 18 19:14:42 2023
From: bo.ye at mediatek.com (Bo Ye)
Date: Tue, 19 Dec 2023 11:14:42 +0800
Subject: [PATCH v2] fix overflow in idle exit_latency
Message-ID: <20231219031444.91752-1-bo.ye@mediatek.com>

From: C Cheng <C.Cheng at mediatek.com>

In detail:

In C language, when you perform a multiplication operation, if
both operands are of int type, the multiplication operation is
performed on the int type, and then the result is converted to
the target type. This means that if the product of int type
multiplication exceeds the range that int type can represent,
 an overflow will occur even if you store the result in a
variable of int64_t type.

For a multiplication of two int values, it is better to use
mul_u32_u32() rather than s->exit_latency_ns = s->exit_latency *
NSEC_PER_USEC to avoid potential overflow happenning.

Signed-off-by: C Cheng <C.Cheng at mediatek.com>
Signed-off-by: Bo Ye <bo.ye at mediatek.com>
---
Change in v2:
-remove Change-ID
-correct patch author name
-replace multiplication of two int values with mul_u32_u32
-refine commit message
---
 drivers/cpuidle/driver.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index d9cda7f6ccb9..cf5873cc45dc 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -16,6 +16,7 @@
 #include <linux/cpumask.h>
 #include <linux/tick.h>
 #include <linux/cpu.h>
+#include <linux/math64.h>
 
 #include "cpuidle.h"
 
@@ -187,7 +188,7 @@ static void __cpuidle_driver_init(struct cpuidle_driver *drv)
 			s->target_residency = div_u64(s->target_residency_ns, NSEC_PER_USEC);
 
 		if (s->exit_latency > 0)
-			s->exit_latency_ns = s->exit_latency * NSEC_PER_USEC;
+			s->exit_latency_ns = mul_u32_u32(s->exit_latency, NSEC_PER_USEC);
 		else if (s->exit_latency_ns < 0)
 			s->exit_latency_ns =  0;
 		else
-- 
2.18.0



From andersson at kernel.org  Mon Dec 18 19:27:52 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Mon, 18 Dec 2023 21:27:52 -0600
Subject: (subset) [PATCH v6 00/13] arm64: qcom: add and enable SHM Bridge support
In-Reply-To: <20231127141600.20929-1-brgl@bgdev.pl>
References: <20231127141600.20929-1-brgl@bgdev.pl>
Message-ID: <170295646310.109617.9399976770089648986.b4-ty@kernel.org>


On Mon, 27 Nov 2023 15:15:47 +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> 
> This is pretty much another full rewrite of the SHM Bridge support
> series. After more on- and off-list discussions I think this time it
> will be close to the final thing though.
> 
> We've established the need for using separate pools for SCM and QSEECOM
> as well as the upcoming scminvoke driver.
> 
> [...]

Applied, thanks!

[01/13] firmware: qcom: qseecom: fix memory leaks in error paths
        commit: 6c57d7b593c4a4e60db65d5ce0fe1d9f79ccbe9b

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From Shawn.Sung at mediatek.com  Mon Dec 18 19:45:43 2023
From: Shawn.Sung at mediatek.com (=?utf-8?B?U2hhd24gU3VuZyAo5a6L5a2d6KyZKQ==?=)
Date: Tue, 19 Dec 2023 03:45:43 +0000
Subject: [PATCH v4 1/1] drm/mediatek: Fix errors when reporting rotation
 capability
In-Reply-To: <0eb813192c02ac6f8d05fe9f4fc805517f5cb97b.camel@mediatek.com>
References: <20231124100052.18599-1-shawn.sung@mediatek.com>
	 <20231124100052.18599-2-shawn.sung@mediatek.com>
	 <0eb813192c02ac6f8d05fe9f4fc805517f5cb97b.camel@mediatek.com>
Message-ID: <23567207c3b28cb3298f85ac9be827e0ba09d278.camel@mediatek.com>

Hi CK,

On Tue, 2023-12-19 at 02:35 +0000, CK Hu (???) wrote:
> Hi, Hsiao-chien:
> 
> On Fri, 2023-11-24 at 18:00 +0800, Hsiao Chien Sung wrote:
> > Create rotation property according to the hardware capability.
> > Since currently OVL of all chips support same rotation,
> > no need to define it in the driver data.
> > 
> > Fixes: 84d805753983 ("drm/mediatek: Support reflect-y plane
> > rotation")
> > 
> > Reviewed-by: AngeloGioacchino Del Regno <
> > angelogioacchino.delregno at collabora.com>
> > Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_disp_drv.h        |  1 +
> >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c        | 18 ++++++--------
> > ----
> >  .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c    |  9 +++++++++
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c    |  1 +
> >  drivers/gpu/drm/mediatek/mtk_drm_plane.c       |  2 +-
> >  5 files changed, 18 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > index 4d6e8b667bc3..c5afeb7c5527 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > @@ -127,6 +127,7 @@ void mtk_ovl_adaptor_register_vblank_cb(struct
> > device *dev, void (*vblank_cb)(vo
> >  void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev);
> >  void mtk_ovl_adaptor_enable_vblank(struct device *dev);
> >  void mtk_ovl_adaptor_disable_vblank(struct device *dev);
> > +unsigned int mtk_ovl_adaptor_supported_rotations(struct device
> > *dev);
> >  void mtk_ovl_adaptor_start(struct device *dev);
> >  void mtk_ovl_adaptor_stop(struct device *dev);
> >  unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index ecc38932fd44..319bbfde5cf9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -415,6 +415,10 @@ unsigned int mtk_ovl_layer_nr(struct device
> > *dev)
> > 
> >  unsigned int mtk_ovl_supported_rotations(struct device *dev)
> >  {
> > +	/*
> > +	 * although currently OVL can only do reflection,
> > +	 * reflect x + reflect y = rotate 180
> > +	 */
> >  	return DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180 |
> >  	       DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
> >  }
> > @@ -423,27 +427,17 @@ int mtk_ovl_layer_check(struct device *dev,
> > unsigned int idx,
> >  			struct mtk_plane_state *mtk_state)
> >  {
> >  	struct drm_plane_state *state = &mtk_state->base;
> > -	unsigned int rotation = 0;
> > 
> > -	rotation = drm_rotation_simplify(state->rotation,
> > -					 DRM_MODE_ROTATE_0 |
> > -					 DRM_MODE_REFLECT_X |
> > -					 DRM_MODE_REFLECT_Y);
> > -	rotation &= ~DRM_MODE_ROTATE_0;
> > -
> > -	/* We can only do reflection, not rotation */
> > -	if ((rotation & DRM_MODE_ROTATE_MASK) != 0)
> > +	if (state->rotation & ~mtk_ovl_supported_rotations(dev))
> >  		return -EINVAL;
> 
> The commit message of this patch is "Create rotation property
> according
> to the hardware capability". I think this modification is not related
> to create property, so separate this to another patch.

Since these modifications are all related to rotation property, or
should I change the title and commit message to "Modify roation
property for passing IGT"?

> 
> > 
> >  	/*
> >  	 * TODO: Rotating/reflecting YUV buffers is not supported at
> > this time.
> >  	 *	 Only RGB[AX] variants are supported.
> >  	 */
> > -	if (state->fb->format->is_yuv && rotation != 0)
> > +	if (state->fb->format->is_yuv && (state->rotation &
> > ~DRM_MODE_ROTATE_0))
> >  		return -EINVAL;
> > 
> > -	state->rotation = rotation;
> > -
> >  	return 0;
> >  }
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > index 4398db9a6276..273c79d37bef 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > @@ -383,6 +383,15 @@ void mtk_ovl_adaptor_register_vblank_cb(struct
> > device *dev, void (*vblank_cb)(vo
> >  				     vblank_cb, vblank_cb_data);
> >  }
> > 
> > +unsigned int mtk_ovl_adaptor_supported_rotations(struct device
> > *dev)
> > +{
> > +	/*
> > +	 * should still return DRM_MODE_ROTATE_0 if rotation is not
> > supported,
> > +	 * or IGT will fail.
> > +	 */
> > +	return DRM_MODE_ROTATE_0;
> > +}
> > +
> >  void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev)
> >  {
> >  	struct mtk_disp_ovl_adaptor *ovl_adaptor =
> > dev_get_drvdata(dev);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index ffa4868b1222..206dd6f6f99e 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -422,6 +422,7 @@ static const struct mtk_ddp_comp_funcs
> > ddp_ovl_adaptor = {
> >  	.remove = mtk_ovl_adaptor_remove_comp,
> >  	.get_formats = mtk_ovl_adaptor_get_formats,
> >  	.get_num_formats = mtk_ovl_adaptor_get_num_formats,
> > +	.supported_rotations = mtk_ovl_adaptor_supported_rotations,
> >  };
> > 
> >  static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX]
> > =
> > {
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > index e2ec61b69618..894c39a38a58 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > @@ -344,7 +344,7 @@ int mtk_plane_init(struct drm_device *dev,
> > struct
> > drm_plane *plane,
> >  		return err;
> >  	}
> > 
> > -	if (supported_rotations & ~DRM_MODE_ROTATE_0) {
> > +	if (supported_rotations) {
> 
> Why need this modification?
> Before Sean's patch [1], only support rotate 0 and does not create
> property and it works. Why does it must create property for only
> support rotate 0?

Yes, as long as the user doesn't check rotation properties before
commiting the pitures, there will be no problem. But IGT somehow
checked this DRM_MODE_ROTATE_0 flag before executing the tests (not all
of them), and leads to failures in these test itmes.

> 
> 
> [1] 
> 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek/mtk_drm_plane.c?h=v6.7-rc6&id=ef87d3e2dd251374c5c9fa3b6502aeff8fe29da9
> 
> Regards,
> CK
> 
> >  		err = drm_plane_create_rotation_property(plane,
> >  							 DRM_MODE_ROTAT
> > E_0,
> >  							 supported_rota
> > tions);
> > --
> > 2.39.2
> > 

Thanks,
Shawn

From andersson at kernel.org  Mon Dec 18 20:18:54 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Mon, 18 Dec 2023 20:18:54 -0800
Subject: [GIT PULL] Qualcomm driver updates for v6.8
Message-ID: <20231219041855.732578-1-andersson@kernel.org>


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-for-6.8

for you to fetch changes up to 110cb8d861cc1a040cdab495b22ac436c49d1454:

  soc: qcom: llcc: Fix LLCC_TRP_ATTR2_CFGn offset (2023-12-18 21:29:23 -0600)

----------------------------------------------------------------
Qualcomm driver updates for v6.8

Support for SM8650 and X1E is added to the LLCC driver, the
LLCC_TRP_ATTR2_CFGn register stride is corrected, and a bug where for
each iteration looping over slices previous settings for dis_cap_alloc
and retain_on_pc are overwritten.

A quirk is introduced in UCSI, for implementations that does not handle
UCSI_GET_PDOS for non-PD partners. With this, USCI support is enabled by
default in pmic_glink. It is later reverted for SC8280XP due reported
errors.

A few memory leaks in error paths of qseecom are taken care of.

A small driver to expose the ADSP PDCharger ULOG debug log is
introduced, to aid debugging issues with pmic_glink.

The identiy of SM8650, PM8937 and a few DSPs are added to the Qualcomm
socinfo driver.

The Qualcomm sleep stats driver is extended to allow getting detailed
statistics about usage of various DDR states. Unfortunately this ABI
does not seem to be stable across platforms, so this addition is dropped
again while the reported problems are investigated further.

Andy is moved from MAINTAINERS to CREDITS. Thank you, Andy.

----------------------------------------------------------------
Abel Vesa (3):
      soc: qcom: llcc: Add missing description for members in slice config
      dt-bindings: soc: qcom,aoss-qmp: document the X1E80100 Always-On Subsystem side channel
      soc: qcom: llcc: Fix LLCC_TRP_ATTR2_CFGn offset

Andrew Halaney (3):
      soc: qcom: pmic_pdcharger_ulog: Search current directory for headers
      soc: qcom: pmic_pdcharger_ulog: Move TRACE_SYSTEM out of #if protection
      soc: qcom: pmic_pdcharger_ulog: Fix hypothetical ulog request message endianess

Arnd Bergmann (1):
      soc: qcom: stats: fix 64-bit division

Atul Dhudase (1):
      soc: qcom: llcc: Fix dis_cap_alloc and retain_on_pc configuration

Bartosz Golaszewski (1):
      firmware: qcom: qseecom: fix memory leaks in error paths

Bjorn Andersson (1):
      soc: qcom: stats: Express AOSS QMP module dependency

Dang Huynh (1):
      soc: qcom: socinfo: Add PM8937 Power IC

Dmitry Baryshkov (2):
      usb: typec: ucsi: fix UCSI on buggy Qualcomm devices
      soc: qcom: pmic_glink: enable UCSI by default

Ghanshyam Agrawal (1):
      soc: qcom: llcc: Fix typo in kernel-doc

Johan Hovold (3):
      soc: qcom: pmic_glink_altmode: fix port sanity check
      soc: qcom: pmic_glink: disable UCSI on sc8280xp
      soc: qcom: pmic_glink: drop stray semicolons

Konrad Dybcio (4):
      dt-bindings: soc: qcom: stats: Add QMP handle
      soc: qcom: stats: Add DDR sleep stats
      dt-bindings: firmware: qcom,scm: Allow interconnect for everyone
      Revert "soc: qcom: stats: Add DDR sleep stats"

Krzysztof Kozlowski (1):
      MAINTAINERS: qcom: move Andy Gross to credits

Naman Jain (1):
      soc: qcom: socinfo: Add few DSPs to get their image details

Neil Armstrong (8):
      soc: qcom: add ADSP PDCharger ULOG driver
      dt-bindings: soc: qcom,aoss-qmp: document the SM8560 Always-On Subsystem side channel
      dt-bindings: soc: qcom: pmic-glink: document SM8650 compatible
      dt-bindings: firmware: qcom,scm: document SM8650 SCM Firmware Interface
      dt-bindings: arm: qcom,ids: Add SoC ID for SM8650
      soc: qcom: socinfo: Add SM8650 SoC ID table entry
      dt-bindings: cache: qcom,llcc: Document the SM8650 Last Level Cache Controller
      soc: qcom: llcc: Add configuration data for SM8650

Rajendra Nayak (2):
      dt-bindings: cache: qcom,llcc: Add X1E80100 compatible
      soc: qcom: llcc: Add configuration data for X1E80100

Sibi Sankar (1):
      dt-bindings: firmware: qcom,scm: document SCM on X1E80100 SoCs

 CREDITS                                            |   4 +
 .../devicetree/bindings/cache/qcom,llcc.yaml       |   3 +
 .../devicetree/bindings/firmware/qcom,scm.yaml     |  18 +--
 .../bindings/soc/qcom/qcom,aoss-qmp.yaml           |   2 +
 .../bindings/soc/qcom/qcom,pmic-glink.yaml         |  22 ++-
 .../devicetree/bindings/soc/qcom/qcom-stats.yaml   |  14 ++
 MAINTAINERS                                        |   1 -
 drivers/firmware/qcom/qcom_qseecom_uefisecapp.c    |  20 ++-
 drivers/soc/qcom/Kconfig                           |  13 ++
 drivers/soc/qcom/Makefile                          |   2 +
 drivers/soc/qcom/llcc-qcom.c                       | 107 ++++++++++++-
 drivers/soc/qcom/pmic_glink.c                      |  24 +--
 drivers/soc/qcom/pmic_glink_altmode.c              |   6 +-
 drivers/soc/qcom/pmic_pdcharger_ulog.c             | 166 +++++++++++++++++++++
 drivers/soc/qcom/pmic_pdcharger_ulog.h             |  36 +++++
 drivers/soc/qcom/socinfo.c                         |  13 +-
 drivers/usb/typec/ucsi/ucsi.c                      |   3 +
 drivers/usb/typec/ucsi/ucsi.h                      |   3 +
 drivers/usb/typec/ucsi/ucsi_glink.c                |  13 ++
 include/dt-bindings/arm/qcom,ids.h                 |   1 +
 20 files changed, 418 insertions(+), 53 deletions(-)
 create mode 100644 drivers/soc/qcom/pmic_pdcharger_ulog.c
 create mode 100644 drivers/soc/qcom/pmic_pdcharger_ulog.h


From andersson at kernel.org  Mon Dec 18 20:29:12 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Mon, 18 Dec 2023 20:29:12 -0800
Subject: [GIT PULL] Qualcomm ARM32 DeviceTree updates for v6.8
Message-ID: <20231219042914.732684-1-andersson@kernel.org>


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm32-for-6.8

for you to fetch changes up to 648002a27c6b3ae293cc415e1fbf20aaa6af8bd3:

  ARM: dts: qcom: msm8974*: Re-enable remoteprocs on various boards (2023-12-17 12:09:42 -0600)

----------------------------------------------------------------
Qualcomm ARM32 DeviceTree updates for v6.8

Support is added for HTC One Mini 2, Nokia Lumia 630, Microsoft Lumia
640, Microsoft Lumia 640 XL, Nokia Lumia 735, Nokia Lumia 830, and
Motorola Moto G 4G, all built on the MSM8226 platform.

The GPU in MSM8226 is described, and MSM8974 gains watchdog support.

The PMICs are transitioned to use interrupts-extended to properly
reference the PMIC interrupt controller, in accordance with the
DeviceTree specification.

In addition to this, a variety of stylistic and DeviceTree validation
issues are corrected.

----------------------------------------------------------------
Alexey Minnekhanov (1):
      ARM: dts: qcom: msm8974-klte: Remove unused property

Andr? Apitzsch (1):
      ARM: dts: qcom: msm8926-motorola-peregrine: Add initial device tree

Bjorn Andersson (1):
      Merge tag 'qcom-dts-for-6.7-2' into arm32-for-6.8

Bryant Mairs (1):
      ARM: dts: qcom: Disable pm8941 & pm8226 smbb charger by default

Dmitry Baryshkov (37):
      ARM: dts: qcom-sdx55: switch USB QMP PHY to new style of bindings
      ARM: dts: qcom-sdx65: switch USB QMP PHY to new style of bindings
      ARM: dts: qcom: apq8064: correct XOADC register address
      ARM: dts: qcom: msm8960: introduce label for PMIC keypad
      ARM: dts: qcom: msm8660-surf: use keypad label directly
      ARM: dts: qcom: apq8064-nexus7: move sdcc1 node to proper place
      ARM: dts: qcom: mdm9615-wp8548-mangoh-green: group include clauses
      ARM: dts: qcom: strip prefix from PMIC files
      ARM: dts: qcom: apq8064: fix PMIC node labels
      ARM: dts: qcom: mdm9615: fix PMIC node labels
      ARM: dts: qcom: msm8660: fix PMIC node labels
      ARM: dts: qcom: msm8960: fix PMIC node labels
      ARM: dts: qcom: apq8064: move PMIC interrupts to the board files
      ARM: dts: qcom: mdm9615: move PMIC interrupts to the board files
      ARM: dts: qcom: msm8660: move PMIC interrupts to the board files
      ARM: dts: qcom: msm8960: move PMIC interrupts to the board files
      ARM: dts: qcom: msm8960: split PMIC to separate dtsi files
      ARM: dts: qcom: apq8064: split PMICs to separate dtsi files
      ARM: dts: qcom: mdm9615: split PMIC to separate dtsi files
      ARM: dts: qcom: msm8660: split PMIC to separate dtsi files
      ARM: dts: qcom: pm8058: reorder nodes
      ARM: dts: qcom: pm8921: reorder nodes
      ARM: dts: qcom: pm8018: move reg property
      ARM: dts: qcom: pm8921: move reg property
      ARM: dts: qcom: pm8058: use defined IRQ flags
      ARM: dts: qcom: pm8921: switch to interrupts-extended
      ARM: dts: qcom: pm8018: switch to interrupts-extended
      ARM: dts: qcom: pm8058: switch to interrupts-extended
      ARM: dts: qcom: apq8064: move RPM regulators to board files
      ARM: dts: qcom: mdm9615: move RPM regulators to board files
      ARM: dts: qcom: msm8660: move RPM regulators to board files
      ARM: dts: qcom: msm8960: drop useless rpm regulators node
      ARM: dts: qcom: msm8974: move regulators to board files
      ARM: dts: qcom: pm8921: Disable keypad by default
      ARM: dts: qcom: apq8060-dragonboard: rename mpp ADC channels to adc-channel
      ARM: dts: qcom: ipq8064: drop qcom, prefix from SSBI node name
      ARM: dts: qcom: mdm9615: drop qcom, prefix from SSBI node name

Johan Hovold (1):
      ARM: dts: qcom: sdx55: fix USB wakeup interrupt types

Krzysztof Kozlowski (5):
      ARM: dts: qcom: sdx65: correct PCIe EP phy-names
      ARM: dts: qcom: sdx65: add missing GCC clocks
      ARM: dts: qcom: sdx65: correct SPMI node name
      ARM: dts: qcom: minor whitespace cleanup around '='
      ARM: dts: qcom: ipq4019: add dedicated SDHCI compatible

Luca Weiss (7):
      ARM: dts: qcom: msm8974: replace incorrect indentation in interconnect
      ARM: dts: qcom: msm8974: sort nodes by reg
      ARM: dts: qcom: msm8226: provide dsi phy clocks to mmcc
      ARM: dts: qcom: Add support for HTC One Mini 2
      ARM: dts: qcom: msm8226: Add GPU
      ARM: dts: qcom: msm8974: Remove bogus cd-gpio pinctrl
      ARM: dts: qcom: msm8974*: Re-enable remoteprocs on various boards

Manivannan Sadhasivam (1):
      ARM: dts: qcom: Use "pcie" as the node name instead of "pci"

Matti Lehtim?ki (1):
      ARM: dts: qcom: msm8974: Add watchdog node

Rayyan Ansari (5):
      ARM: dts: qcom: add common dt for MSM8x26 Lumias along with Nokia Lumia 630
      ARM: dts: qcom: add device tree for Microsoft Lumia 640
      ARM: dts: qcom: add device tree for Microsoft Lumia 640 XL
      ARM: dts: qcom: add device tree for Nokia Lumia 735
      ARM: dts: qcom: add device tree for Nokia Lumia 830

 arch/arm/boot/dts/qcom/Makefile                    |   7 +
 arch/arm/boot/dts/qcom/pm8018.dtsi                 |  55 +++
 arch/arm/boot/dts/qcom/pm8058.dtsi                 | 159 +++++++++
 .../dts/qcom/{qcom-pm8226.dtsi => pm8226.dtsi}     |   2 +
 arch/arm/boot/dts/qcom/pm8821.dtsi                 |  22 ++
 .../dts/qcom/{qcom-pm8841.dtsi => pm8841.dtsi}     |   0
 arch/arm/boot/dts/qcom/pm8921.dtsi                 | 137 ++++++++
 .../dts/qcom/{qcom-pm8941.dtsi => pm8941.dtsi}     |   2 +
 .../dts/qcom/{qcom-pma8084.dtsi => pma8084.dtsi}   |   0
 .../boot/dts/qcom/{qcom-pmx55.dtsi => pmx55.dtsi}  |   0
 .../boot/dts/qcom/{qcom-pmx65.dtsi => pmx65.dtsi}  |   0
 .../boot/dts/qcom/qcom-apq8026-asus-sparrow.dts    |   4 +-
 .../boot/dts/qcom/qcom-apq8026-huawei-sturgeon.dts |   4 +-
 arch/arm/boot/dts/qcom/qcom-apq8026-lg-lenok.dts   |   4 +-
 .../dts/qcom/qcom-apq8026-samsung-matisse-wifi.dts |   2 +-
 .../arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts | 164 +++++----
 .../boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts |  70 ++--
 arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts   |  35 +-
 arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts    |  42 ++-
 .../qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts   | 111 +++---
 arch/arm/boot/dts/qcom/qcom-apq8064.dtsi           | 203 +----------
 .../arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts |  35 +-
 arch/arm/boot/dts/qcom/qcom-apq8084-ifc6540.dts    |   2 +-
 arch/arm/boot/dts/qcom/qcom-apq8084-mtp.dts        |   2 +-
 arch/arm/boot/dts/qcom/qcom-ipq4019-ap.dk04.1.dtsi |   2 +-
 arch/arm/boot/dts/qcom/qcom-ipq4019.dtsi           |   4 +-
 arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi           |   8 +-
 .../dts/qcom/qcom-mdm9615-wp8548-mangoh-green.dts  |   4 +-
 arch/arm/boot/dts/qcom/qcom-mdm9615-wp8548.dtsi    | 143 +++++++-
 arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi           | 183 +---------
 .../dts/qcom/qcom-msm8226-microsoft-common.dtsi    | 327 ++++++++++++++++++
 .../dts/qcom/qcom-msm8226-microsoft-dempsey.dts    |  17 +
 .../dts/qcom/qcom-msm8226-microsoft-makepeace.dts  |  17 +
 .../dts/qcom/qcom-msm8226-microsoft-moneypenny.dts |  23 ++
 arch/arm/boot/dts/qcom/qcom-msm8226.dtsi           |  48 ++-
 arch/arm/boot/dts/qcom/qcom-msm8660-surf.dts       |  61 ++--
 arch/arm/boot/dts/qcom/qcom-msm8660.dtsi           | 217 +-----------
 arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts  | 372 +++++++++++++++++++++
 .../qcom/qcom-msm8926-microsoft-superman-lte.dts   |  53 +++
 .../boot/dts/qcom/qcom-msm8926-microsoft-tesla.dts |  67 ++++
 .../dts/qcom/qcom-msm8926-motorola-peregrine.dts   | 291 ++++++++++++++++
 arch/arm/boot/dts/qcom/qcom-msm8960-cdp.dts        |  27 +-
 .../dts/qcom/qcom-msm8960-samsung-expressatt.dts   |   7 +-
 arch/arm/boot/dts/qcom/qcom-msm8960.dtsi           |  45 +--
 .../qcom/qcom-msm8974-lge-nexus5-hammerhead.dts    |  33 +-
 .../dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi   |  35 +-
 arch/arm/boot/dts/qcom/qcom-msm8974.dtsi           | 122 +++----
 .../dts/qcom/qcom-msm8974pro-fairphone-fp2.dts     |  33 +-
 .../dts/qcom/qcom-msm8974pro-oneplus-bacon.dts     |  35 +-
 .../boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts |  13 +-
 .../qcom-msm8974pro-sony-xperia-shinano-castor.dts |  35 +-
 arch/arm/boot/dts/qcom/qcom-sdx55-mtp.dts          |   2 +-
 arch/arm/boot/dts/qcom/qcom-sdx55-t55.dts          |   2 +-
 .../boot/dts/qcom/qcom-sdx55-telit-fn980-tlb.dts   |   2 +-
 arch/arm/boot/dts/qcom/qcom-sdx55.dtsi             |  45 ++-
 arch/arm/boot/dts/qcom/qcom-sdx65-mtp.dts          |   2 +-
 arch/arm/boot/dts/qcom/qcom-sdx65.dtsi             |  51 +--
 57 files changed, 2398 insertions(+), 990 deletions(-)
 create mode 100644 arch/arm/boot/dts/qcom/pm8018.dtsi
 create mode 100644 arch/arm/boot/dts/qcom/pm8058.dtsi
 rename arch/arm/boot/dts/qcom/{qcom-pm8226.dtsi => pm8226.dtsi} (99%)
 create mode 100644 arch/arm/boot/dts/qcom/pm8821.dtsi
 rename arch/arm/boot/dts/qcom/{qcom-pm8841.dtsi => pm8841.dtsi} (100%)
 create mode 100644 arch/arm/boot/dts/qcom/pm8921.dtsi
 rename arch/arm/boot/dts/qcom/{qcom-pm8941.dtsi => pm8941.dtsi} (99%)
 rename arch/arm/boot/dts/qcom/{qcom-pma8084.dtsi => pma8084.dtsi} (100%)
 rename arch/arm/boot/dts/qcom/{qcom-pmx55.dtsi => pmx55.dtsi} (100%)
 rename arch/arm/boot/dts/qcom/{qcom-pmx65.dtsi => pmx65.dtsi} (100%)
 create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-common.dtsi
 create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-dempsey.dts
 create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-makepeace.dts
 create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8226-microsoft-moneypenny.dts
 create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts
 create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8926-microsoft-superman-lte.dts
 create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8926-microsoft-tesla.dts
 create mode 100644 arch/arm/boot/dts/qcom/qcom-msm8926-motorola-peregrine.dts


From andersson at kernel.org  Mon Dec 18 20:33:06 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Mon, 18 Dec 2023 20:33:06 -0800
Subject: [GIT PULL] Qualcomm ARM64 defconfig updates for v6.8
Message-ID: <20231219043307.732781-1-andersson@kernel.org>


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-defconfig-for-6.8

for you to fetch changes up to 48a9ba5eb4d720c6e21c6e4d2a6fb6e1a97f5f2a:

  arm64: defconfig: enable Qualcomm WSA884x driver (2023-12-17 15:03:06 -0600)

----------------------------------------------------------------
Qualcomm ARM64 defconfig updates for v6.8

Core platform-specific drivers for SM8650, SM4450, and SDX75 are
enabled. The sound drivers for SC8280XP and SM8650 are enabled.
Lastly the UEFI Secure App driver, providing EFI variable access on some
platforms is enabled.

----------------------------------------------------------------
Johan Hovold (2):
      arm64: defconfig: enable Qualcomm sc8280xp sound drivers
      arm64: defconfig: enable Qualcomm UEFI Secure App driver

Krzysztof Kozlowski (1):
      arm64: defconfig: enable Qualcomm WSA884x driver

Neil Armstrong (1):
      arm64: deconfig: enable Qualcomm SM8650 SoC drivers

Rohit Agarwal (1):
      arm64: defconfig: Enable GCC, pinctrl and interconnect for SDX75

Tengfei Fan (1):
      arm64: defconfig: enable clock controller and pinctrl

 arch/arm64/configs/defconfig | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)


From ck.hu at mediatek.com  Mon Dec 18 21:24:17 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 19 Dec 2023 05:24:17 +0000
Subject: [PATCH v4 1/1] drm/mediatek: Fix errors when reporting rotation
 capability
In-Reply-To: <23567207c3b28cb3298f85ac9be827e0ba09d278.camel@mediatek.com>
References: <20231124100052.18599-1-shawn.sung@mediatek.com>
	 <20231124100052.18599-2-shawn.sung@mediatek.com>
	 <0eb813192c02ac6f8d05fe9f4fc805517f5cb97b.camel@mediatek.com>
	 <23567207c3b28cb3298f85ac9be827e0ba09d278.camel@mediatek.com>
Message-ID: <a2c69e8d60dc09662be993983b6ce3d44acdf523.camel@mediatek.com>

Hi, Hsiao-chien:

On Tue, 2023-12-19 at 03:45 +0000, Shawn Sung (???) wrote:
> Hi CK,
> 
> On Tue, 2023-12-19 at 02:35 +0000, CK Hu (???) wrote:
> > Hi, Hsiao-chien:
> > 
> > On Fri, 2023-11-24 at 18:00 +0800, Hsiao Chien Sung wrote:
> > > Create rotation property according to the hardware capability.
> > > Since currently OVL of all chips support same rotation,
> > > no need to define it in the driver data.
> > > 
> > > Fixes: 84d805753983 ("drm/mediatek: Support reflect-y plane
> > > rotation")
> > > 
> > > Reviewed-by: AngeloGioacchino Del Regno <
> > > angelogioacchino.delregno at collabora.com>
> > > Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_disp_drv.h        |  1 +
> > >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c        | 18 ++++++----
> > > ----
> > > ----
> > >  .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c    |  9 +++++++++
> > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c    |  1 +
> > >  drivers/gpu/drm/mediatek/mtk_drm_plane.c       |  2 +-
> > >  5 files changed, 18 insertions(+), 13 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > index 4d6e8b667bc3..c5afeb7c5527 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > @@ -127,6 +127,7 @@ void
> > > mtk_ovl_adaptor_register_vblank_cb(struct
> > > device *dev, void (*vblank_cb)(vo
> > >  void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev);
> > >  void mtk_ovl_adaptor_enable_vblank(struct device *dev);
> > >  void mtk_ovl_adaptor_disable_vblank(struct device *dev);
> > > +unsigned int mtk_ovl_adaptor_supported_rotations(struct device
> > > *dev);
> > >  void mtk_ovl_adaptor_start(struct device *dev);
> > >  void mtk_ovl_adaptor_stop(struct device *dev);
> > >  unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > index ecc38932fd44..319bbfde5cf9 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > @@ -415,6 +415,10 @@ unsigned int mtk_ovl_layer_nr(struct device
> > > *dev)
> > > 
> > >  unsigned int mtk_ovl_supported_rotations(struct device *dev)
> > >  {
> > > +	/*
> > > +	 * although currently OVL can only do reflection,
> > > +	 * reflect x + reflect y = rotate 180
> > > +	 */
> > >  	return DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180 |
> > >  	       DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
> > >  }
> > > @@ -423,27 +427,17 @@ int mtk_ovl_layer_check(struct device *dev,
> > > unsigned int idx,
> > >  			struct mtk_plane_state *mtk_state)
> > >  {
> > >  	struct drm_plane_state *state = &mtk_state->base;
> > > -	unsigned int rotation = 0;
> > > 
> > > -	rotation = drm_rotation_simplify(state->rotation,
> > > -					 DRM_MODE_ROTATE_0 |
> > > -					 DRM_MODE_REFLECT_X |
> > > -					 DRM_MODE_REFLECT_Y);
> > > -	rotation &= ~DRM_MODE_ROTATE_0;
> > > -
> > > -	/* We can only do reflection, not rotation */
> > > -	if ((rotation & DRM_MODE_ROTATE_MASK) != 0)
> > > +	if (state->rotation & ~mtk_ovl_supported_rotations(dev))
> > >  		return -EINVAL;
> > 
> > The commit message of this patch is "Create rotation property
> > according
> > to the hardware capability". I think this modification is not
> > related
> > to create property, so separate this to another patch.
> 
> Since these modifications are all related to rotation property, or
> should I change the title and commit message to "Modify roation
> property for passing IGT"?

OK. But I don't know why do this, so describe more about this.

> 
> > 
> > > 
> > >  	/*
> > >  	 * TODO: Rotating/reflecting YUV buffers is not supported at
> > > this time.
> > >  	 *	 Only RGB[AX] variants are supported.
> > >  	 */
> > > -	if (state->fb->format->is_yuv && rotation != 0)
> > > +	if (state->fb->format->is_yuv && (state->rotation &
> > > ~DRM_MODE_ROTATE_0))
> > >  		return -EINVAL;
> > > 
> > > -	state->rotation = rotation;
> > > -
> > >  	return 0;
> > >  }
> > > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > > b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > > index 4398db9a6276..273c79d37bef 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > > @@ -383,6 +383,15 @@ void
> > > mtk_ovl_adaptor_register_vblank_cb(struct
> > > device *dev, void (*vblank_cb)(vo
> > >  				     vblank_cb, vblank_cb_data);
> > >  }
> > > 
> > > +unsigned int mtk_ovl_adaptor_supported_rotations(struct device
> > > *dev)
> > > +{
> > > +	/*
> > > +	 * should still return DRM_MODE_ROTATE_0 if rotation is not
> > > supported,
> > > +	 * or IGT will fail.
> > > +	 */
> > > +	return DRM_MODE_ROTATE_0;
> > > +}
> > > +
> > >  void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev)
> > >  {
> > >  	struct mtk_disp_ovl_adaptor *ovl_adaptor =
> > > dev_get_drvdata(dev);
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > index ffa4868b1222..206dd6f6f99e 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > @@ -422,6 +422,7 @@ static const struct mtk_ddp_comp_funcs
> > > ddp_ovl_adaptor = {
> > >  	.remove = mtk_ovl_adaptor_remove_comp,
> > >  	.get_formats = mtk_ovl_adaptor_get_formats,
> > >  	.get_num_formats = mtk_ovl_adaptor_get_num_formats,
> > > +	.supported_rotations = mtk_ovl_adaptor_supported_rotations,
> > >  };
> > > 
> > >  static const char * const
> > > mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX]
> > > =
> > > {
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > index e2ec61b69618..894c39a38a58 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > @@ -344,7 +344,7 @@ int mtk_plane_init(struct drm_device *dev,
> > > struct
> > > drm_plane *plane,
> > >  		return err;
> > >  	}
> > > 
> > > -	if (supported_rotations & ~DRM_MODE_ROTATE_0) {
> > > +	if (supported_rotations) {
> > 
> > Why need this modification?
> > Before Sean's patch [1], only support rotate 0 and does not create
> > property and it works. Why does it must create property for only
> > support rotate 0?
> 
> Yes, as long as the user doesn't check rotation properties before
> commiting the pitures, there will be no problem. But IGT somehow
> checked this DRM_MODE_ROTATE_0 flag before executing the tests (not
> all
> of them), and leads to failures in these test itmes.

OK, so, when supported_rotations == NULL (mtk_disp_rdma), it should
also create rotation property. But I'm confused that if IGT assume that
all drm driver should have rotation property, why drm core does not add
this property for all drm driver?

Regards,
CK

> 
> > 
> > 
> > [1] 
> > 
> 
> 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek/mtk_drm_plane.c?h=v6.7-rc6&id=ef87d3e2dd251374c5c9fa3b6502aeff8fe29da9
> > 
> > Regards,
> > CK
> > 
> > >  		err = drm_plane_create_rotation_property(plane,
> > >  							 DRM_MODE_ROTAT
> > > E_0,
> > >  							 supported_rota
> > > tions);
> > > --
> > > 2.39.2
> > > 
> 
> Thanks,
> Shawn

From jay.buddhabhatti at amd.com  Mon Dec 18 21:50:23 2023
From: jay.buddhabhatti at amd.com (Jay Buddhabhatti)
Date: Mon, 18 Dec 2023 21:50:23 -0800
Subject: [PATCH V2 0/2] add platform check in event manager driver
Message-ID: <20231219055025.27570-1-jay.buddhabhatti@amd.com>

Some error event IDs for Versal and Versal NET are different.
Both the platforms should access their respective error event
IDs so use sub_family_code to check for Versal or Versal NET
platform and check error IDs for respective platforms.

V1: https://lore.kernel.org/lkml/20231218094009.13528-1-jay.buddhabhatti at amd.com/
Changes in v2:
 - Fixed compilation error in edac driver

Jay Buddhabhatti (2):
  firmware: xilinx: Export function to use in other module
  drivers: soc: xilinx: add check for platform

 drivers/edac/versal_edac.c              |  4 ++--
 drivers/firmware/xilinx/zynqmp.c        |  3 ++-
 drivers/soc/xilinx/xlnx_event_manager.c | 25 ++++++++++++++++++++-----
 include/linux/firmware/xlnx-zynqmp.h    | 22 ++++++++++++++++++----
 4 files changed, 42 insertions(+), 12 deletions(-)

-- 
2.17.1



From jay.buddhabhatti at amd.com  Mon Dec 18 21:50:25 2023
From: jay.buddhabhatti at amd.com (Jay Buddhabhatti)
Date: Mon, 18 Dec 2023 21:50:25 -0800
Subject: [PATCH V2 2/2] drivers: soc: xilinx: add check for platform
In-Reply-To: <20231219055025.27570-1-jay.buddhabhatti@amd.com>
References: <20231219055025.27570-1-jay.buddhabhatti@amd.com>
Message-ID: <20231219055025.27570-3-jay.buddhabhatti@amd.com>

Some error event IDs for Versal and Versal NET are different.
Both the platforms should access their respective error event
IDs so use sub_family_code to check for platform and check
error IDs for respective platforms. The family code is passed
via platform data to avoid platform detection again.
Platform data is setup when even driver is registered.

Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti at amd.com>
---
 drivers/edac/versal_edac.c              |  4 ++--
 drivers/soc/xilinx/xlnx_event_manager.c | 25 ++++++++++++++++++++-----
 include/linux/firmware/xlnx-zynqmp.h    | 16 ++++++++++++----
 3 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/drivers/edac/versal_edac.c b/drivers/edac/versal_edac.c
index 8625de20fc71..62caf454b567 100644
--- a/drivers/edac/versal_edac.c
+++ b/drivers/edac/versal_edac.c
@@ -1005,7 +1005,7 @@ static int mc_probe(struct platform_device *pdev)
 		goto free_edac_mc;
 	}
 
-	rc = xlnx_register_event(PM_NOTIFY_CB, EVENT_ERROR_PMC_ERR1,
+	rc = xlnx_register_event(PM_NOTIFY_CB, VERSAL_EVENT_ERROR_PMC_ERR1,
 				 XPM_EVENT_ERROR_MASK_DDRMC_CR | XPM_EVENT_ERROR_MASK_DDRMC_NCR |
 				 XPM_EVENT_ERROR_MASK_NOC_CR | XPM_EVENT_ERROR_MASK_NOC_NCR,
 				 false, err_callback, mci);
@@ -1042,7 +1042,7 @@ static int mc_remove(struct platform_device *pdev)
 	debugfs_remove_recursive(priv->debugfs);
 #endif
 
-	xlnx_unregister_event(PM_NOTIFY_CB, EVENT_ERROR_PMC_ERR1,
+	xlnx_unregister_event(PM_NOTIFY_CB, VERSAL_EVENT_ERROR_PMC_ERR1,
 			      XPM_EVENT_ERROR_MASK_DDRMC_CR |
 			      XPM_EVENT_ERROR_MASK_NOC_CR |
 			      XPM_EVENT_ERROR_MASK_NOC_NCR |
diff --git a/drivers/soc/xilinx/xlnx_event_manager.c b/drivers/soc/xilinx/xlnx_event_manager.c
index 86a048a10a13..78f9a3c6ae11 100644
--- a/drivers/soc/xilinx/xlnx_event_manager.c
+++ b/drivers/soc/xilinx/xlnx_event_manager.c
@@ -77,11 +77,26 @@ struct registered_event_data {
 
 static bool xlnx_is_error_event(const u32 node_id)
 {
-	if (node_id == EVENT_ERROR_PMC_ERR1 ||
-	    node_id == EVENT_ERROR_PMC_ERR2 ||
-	    node_id == EVENT_ERROR_PSM_ERR1 ||
-	    node_id == EVENT_ERROR_PSM_ERR2)
-		return true;
+	u32 pm_family_code, pm_sub_family_code;
+
+	zynqmp_pm_get_family_info(&pm_family_code, &pm_sub_family_code);
+
+	if (pm_sub_family_code == VERSAL_SUB_FAMILY_CODE) {
+		if (node_id == VERSAL_EVENT_ERROR_PMC_ERR1 ||
+		    node_id == VERSAL_EVENT_ERROR_PMC_ERR2 ||
+		    node_id == VERSAL_EVENT_ERROR_PSM_ERR1 ||
+		    node_id == VERSAL_EVENT_ERROR_PSM_ERR2)
+			return true;
+	} else {
+		if (node_id == VERSAL_NET_EVENT_ERROR_PMC_ERR1 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PMC_ERR2 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PMC_ERR3 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PSM_ERR1 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PSM_ERR2 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PSM_ERR3 ||
+		    node_id == VERSAL_NET_EVENT_ERROR_PSM_ERR4)
+			return true;
+	}
 
 	return false;
 }
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 2375ce9b38df..2cfd78f232dc 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -91,10 +91,18 @@
 /*
  * Node IDs for the Error Events.
  */
-#define EVENT_ERROR_PMC_ERR1	(0x28100000U)
-#define EVENT_ERROR_PMC_ERR2	(0x28104000U)
-#define EVENT_ERROR_PSM_ERR1	(0x28108000U)
-#define EVENT_ERROR_PSM_ERR2	(0x2810C000U)
+#define VERSAL_EVENT_ERROR_PMC_ERR1	(0x28100000U)
+#define VERSAL_EVENT_ERROR_PMC_ERR2	(0x28104000U)
+#define VERSAL_EVENT_ERROR_PSM_ERR1	(0x28108000U)
+#define VERSAL_EVENT_ERROR_PSM_ERR2	(0x2810C000U)
+
+#define VERSAL_NET_EVENT_ERROR_PMC_ERR1	(0x28100000U)
+#define VERSAL_NET_EVENT_ERROR_PMC_ERR2	(0x28104000U)
+#define VERSAL_NET_EVENT_ERROR_PMC_ERR3	(0x28108000U)
+#define VERSAL_NET_EVENT_ERROR_PSM_ERR1	(0x2810C000U)
+#define VERSAL_NET_EVENT_ERROR_PSM_ERR2	(0x28110000U)
+#define VERSAL_NET_EVENT_ERROR_PSM_ERR3	(0x28114000U)
+#define VERSAL_NET_EVENT_ERROR_PSM_ERR4	(0x28118000U)
 
 /* ZynqMP SD tap delay tuning */
 #define SD_ITAPDLY	0xFF180314
-- 
2.17.1



From jay.buddhabhatti at amd.com  Mon Dec 18 21:50:24 2023
From: jay.buddhabhatti at amd.com (Jay Buddhabhatti)
Date: Mon, 18 Dec 2023 21:50:24 -0800
Subject: [PATCH V2 1/2] firmware: xilinx: Export function to use in other module
In-Reply-To: <20231219055025.27570-1-jay.buddhabhatti@amd.com>
References: <20231219055025.27570-1-jay.buddhabhatti@amd.com>
Message-ID: <20231219055025.27570-2-jay.buddhabhatti@amd.com>

Export zynqmp_pm_get_family_info() to access and find family information
in other module.

Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti at amd.com>
---
 drivers/firmware/xilinx/zynqmp.c     | 3 ++-
 include/linux/firmware/xlnx-zynqmp.h | 6 ++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index b0d22d4455d9..313965f79dd7 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -414,7 +414,7 @@ EXPORT_SYMBOL_GPL(zynqmp_pm_get_chipid);
  *
  * Return: Returns status, either success or error+reason
  */
-static int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily)
+int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily)
 {
 	u32 ret_payload[PAYLOAD_ARG_CNT];
 	u32 idcode;
@@ -439,6 +439,7 @@ static int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_family_info);
 
 /**
  * zynqmp_pm_get_trustzone_version() - Get secure trustzone firmware version
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index d1ea3898564c..2375ce9b38df 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -515,6 +515,7 @@ int zynqmp_pm_invoke_fn(u32 pm_api_id, u32 arg0, u32 arg1,
 #if IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE)
 int zynqmp_pm_get_api_version(u32 *version);
 int zynqmp_pm_get_chipid(u32 *idcode, u32 *version);
+int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily);
 int zynqmp_pm_query_data(struct zynqmp_pm_query_data qdata, u32 *out);
 int zynqmp_pm_clock_enable(u32 clock_id);
 int zynqmp_pm_clock_disable(u32 clock_id);
@@ -596,6 +597,11 @@ static inline int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
 	return -ENODEV;
 }
 
+static inline int zynqmp_pm_get_family_info(u32 *family, u32 *subfamily)
+{
+	return -ENODEV;
+}
+
 static inline int zynqmp_pm_query_data(struct zynqmp_pm_query_data qdata,
 				       u32 *out)
 {
-- 
2.17.1



From Shawn.Sung at mediatek.com  Mon Dec 18 21:59:39 2023
From: Shawn.Sung at mediatek.com (=?utf-8?B?U2hhd24gU3VuZyAo5a6L5a2d6KyZKQ==?=)
Date: Tue, 19 Dec 2023 05:59:39 +0000
Subject: [PATCH v4 1/1] drm/mediatek: Fix errors when reporting rotation
 capability
In-Reply-To: <a2c69e8d60dc09662be993983b6ce3d44acdf523.camel@mediatek.com>
References: <20231124100052.18599-1-shawn.sung@mediatek.com>
	 <20231124100052.18599-2-shawn.sung@mediatek.com>
	 <0eb813192c02ac6f8d05fe9f4fc805517f5cb97b.camel@mediatek.com>
	 <23567207c3b28cb3298f85ac9be827e0ba09d278.camel@mediatek.com>
	 <a2c69e8d60dc09662be993983b6ce3d44acdf523.camel@mediatek.com>
Message-ID: <9890110452673e7ed4122bab7bb26f99df081f7f.camel@mediatek.com>

Hi CK,

On Tue, 2023-12-19 at 05:24 +0000, CK Hu (???) wrote:
> Hi, Hsiao-chien:
> 
> On Tue, 2023-12-19 at 03:45 +0000, Shawn Sung (???) wrote:
> > Hi CK,
> > 
> > On Tue, 2023-12-19 at 02:35 +0000, CK Hu (???) wrote:
> > > Hi, Hsiao-chien:
> > > 
> > > On Fri, 2023-11-24 at 18:00 +0800, Hsiao Chien Sung wrote:
> > > > Create rotation property according to the hardware capability.
> > > > Since currently OVL of all chips support same rotation,
> > > > no need to define it in the driver data.
> > > > 
> > > > Fixes: 84d805753983 ("drm/mediatek: Support reflect-y plane
> > > > rotation")
> > > > 
> > > > Reviewed-by: AngeloGioacchino Del Regno <
> > > > angelogioacchino.delregno at collabora.com>
> > > > Signed-off-by: Hsiao Chien Sung <shawn.sung at mediatek.com>
> > > > ---
> > > >  drivers/gpu/drm/mediatek/mtk_disp_drv.h        |  1 +
> > > >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c        | 18 ++++++----
> > > > ----
> > > > ----
> > > >  .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c    |  9 +++++++++
> > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c    |  1 +
> > > >  drivers/gpu/drm/mediatek/mtk_drm_plane.c       |  2 +-
> > > >  5 files changed, 18 insertions(+), 13 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > > index 4d6e8b667bc3..c5afeb7c5527 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > > @@ -127,6 +127,7 @@ void
> > > > mtk_ovl_adaptor_register_vblank_cb(struct
> > > > device *dev, void (*vblank_cb)(vo
> > > >  void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev);
> > > >  void mtk_ovl_adaptor_enable_vblank(struct device *dev);
> > > >  void mtk_ovl_adaptor_disable_vblank(struct device *dev);
> > > > +unsigned int mtk_ovl_adaptor_supported_rotations(struct device
> > > > *dev);
> > > >  void mtk_ovl_adaptor_start(struct device *dev);
> > > >  void mtk_ovl_adaptor_stop(struct device *dev);
> > > >  unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > > index ecc38932fd44..319bbfde5cf9 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > > @@ -415,6 +415,10 @@ unsigned int mtk_ovl_layer_nr(struct
> > > > device
> > > > *dev)
> > > > 
> > > >  unsigned int mtk_ovl_supported_rotations(struct device *dev)
> > > >  {
> > > > +	/*
> > > > +	 * although currently OVL can only do reflection,
> > > > +	 * reflect x + reflect y = rotate 180
> > > > +	 */
> > > >  	return DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180 |
> > > >  	       DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
> > > >  }
> > > > @@ -423,27 +427,17 @@ int mtk_ovl_layer_check(struct device
> > > > *dev,
> > > > unsigned int idx,
> > > >  			struct mtk_plane_state *mtk_state)
> > > >  {
> > > >  	struct drm_plane_state *state = &mtk_state->base;
> > > > -	unsigned int rotation = 0;
> > > > 
> > > > -	rotation = drm_rotation_simplify(state->rotation,
> > > > -					 DRM_MODE_ROTATE_0 |
> > > > -					 DRM_MODE_REFLECT_X |
> > > > -					 DRM_MODE_REFLECT_Y);
> > > > -	rotation &= ~DRM_MODE_ROTATE_0;
> > > > -
> > > > -	/* We can only do reflection, not rotation */
> > > > -	if ((rotation & DRM_MODE_ROTATE_MASK) != 0)
> > > > +	if (state->rotation &
> > > > ~mtk_ovl_supported_rotations(dev))
> > > >  		return -EINVAL;
> > > 
> > > The commit message of this patch is "Create rotation property
> > > according
> > > to the hardware capability". I think this modification is not
> > > related
> > > to create property, so separate this to another patch.
> > 
> > Since these modifications are all related to rotation property, or
> > should I change the title and commit message to "Modify roation
> > property for passing IGT"?
> 
> OK. But I don't know why do this, so describe more about this.
> 

Got it, thanks. Will add more information to the commit message.

> > 
> > > 
> > > > 
> > > >  	/*
> > > >  	 * TODO: Rotating/reflecting YUV buffers is not
> > > > supported at
> > > > this time.
> > > >  	 *	 Only RGB[AX] variants are supported.
> > > >  	 */
> > > > -	if (state->fb->format->is_yuv && rotation != 0)
> > > > +	if (state->fb->format->is_yuv && (state->rotation &
> > > > ~DRM_MODE_ROTATE_0))
> > > >  		return -EINVAL;
> > > > 
> > > > -	state->rotation = rotation;
> > > > -
> > > >  	return 0;
> > > >  }
> > > > 
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > > > b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > > > index 4398db9a6276..273c79d37bef 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > > > @@ -383,6 +383,15 @@ void
> > > > mtk_ovl_adaptor_register_vblank_cb(struct
> > > > device *dev, void (*vblank_cb)(vo
> > > >  				     vblank_cb,
> > > > vblank_cb_data);
> > > >  }
> > > > 
> > > > +unsigned int mtk_ovl_adaptor_supported_rotations(struct device
> > > > *dev)
> > > > +{
> > > > +	/*
> > > > +	 * should still return DRM_MODE_ROTATE_0 if rotation is
> > > > not
> > > > supported,
> > > > +	 * or IGT will fail.
> > > > +	 */
> > > > +	return DRM_MODE_ROTATE_0;
> > > > +}
> > > > +
> > > >  void mtk_ovl_adaptor_unregister_vblank_cb(struct device *dev)
> > > >  {
> > > >  	struct mtk_disp_ovl_adaptor *ovl_adaptor =
> > > > dev_get_drvdata(dev);
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > index ffa4868b1222..206dd6f6f99e 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > @@ -422,6 +422,7 @@ static const struct mtk_ddp_comp_funcs
> > > > ddp_ovl_adaptor = {
> > > >  	.remove = mtk_ovl_adaptor_remove_comp,
> > > >  	.get_formats = mtk_ovl_adaptor_get_formats,
> > > >  	.get_num_formats = mtk_ovl_adaptor_get_num_formats,
> > > > +	.supported_rotations =
> > > > mtk_ovl_adaptor_supported_rotations,
> > > >  };
> > > > 
> > > >  static const char * const
> > > > mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX]
> > > > =
> > > > {
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > > index e2ec61b69618..894c39a38a58 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > > @@ -344,7 +344,7 @@ int mtk_plane_init(struct drm_device *dev,
> > > > struct
> > > > drm_plane *plane,
> > > >  		return err;
> > > >  	}
> > > > 
> > > > -	if (supported_rotations & ~DRM_MODE_ROTATE_0) {
> > > > +	if (supported_rotations) {
> > > 
> > > Why need this modification?
> > > Before Sean's patch [1], only support rotate 0 and does not
> > > create
> > > property and it works. Why does it must create property for only
> > > support rotate 0?
> > 
> > Yes, as long as the user doesn't check rotation properties before
> > commiting the pitures, there will be no problem. But IGT somehow
> > checked this DRM_MODE_ROTATE_0 flag before executing the tests (not
> > all
> > of them), and leads to failures in these test itmes.
> 
> OK, so, when supported_rotations == NULL (mtk_disp_rdma), it should
> also create rotation property. But I'm confused that if IGT assume
> that
> all drm driver should have rotation property, why drm core does not
> add
> this property for all drm driver?
> 

After checking the report, only "graphics.IgtKms.kms_flip_unstable" has
such a constraint. However, since IGT version is still keep updating,
there are not guarantees about this behavior.

I did search for "DRM_MODE_ROTATE_0" in the kernel to check if there is
any rule or even suggestion about setting this property, but the flag
is rarely even mentioned.

Maybe we could also report this issue to IGT team instead of changing
the behavior of our driver.

> Regards,
> CK
> 
> > 
> > > 
> > > 
> > > [1] 
> > > 
> > 
> > 
> 
> 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek/mtk_drm_plane.c?h=v6.7-rc6&id=ef87d3e2dd251374c5c9fa3b6502aeff8fe29da9
> > > 
> > > Regards,
> > > CK
> > > 
> > > >  		err = drm_plane_create_rotation_property(plane,
> > > >  							 DRM_MO
> > > > DE_ROTAT
> > > > E_0,
> > > >  							 suppor
> > > > ted_rota
> > > > tions);
> > > > --
> > > > 2.39.2
> > > > 
> > 
> > Thanks,
> > Shawn

From adrian.hunter at intel.com  Mon Dec 18 22:05:34 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Tue, 19 Dec 2023 08:05:34 +0200
Subject: [PATCH RFC V2 0/4] perf/core: Add ability for an event to "pause"
 or "resume" AUX area tracing
In-Reply-To: <20231208172449.35444-1-adrian.hunter@intel.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
Message-ID: <ebf302c5-edd8-451d-b9fa-69733b354fab@intel.com>

On 8/12/23 19:24, Adrian Hunter wrote:
> Hi
> 
> Hardware traces, such as instruction traces, can produce a vast amount of
> trace data, so being able to reduce tracing to more specific circumstances
> can be useful.
> 
> The ability to pause or resume tracing when another event happens, can do
> that.
> 
> These patches add such a facilty and show how it would work for Intel
> Processor Trace.
> 
> Maintainers of other AUX area tracing implementations are requested to
> consider if this is something they might employ and then whether or not
> the ABI would work for them.
> 
> Changes to perf tools are not fleshed out yet.
> 
> 
> Changes in RFC V2:
> 
>       Use ->stop() / ->start() instead of ->pause_resume()
>       Move aux_start_paused bit into aux_output_cfg
>       Tighten up when Intel PT pause / resume is allowed
>       Add an example of how it might work for CoreSight

Any comments?

> 
> 
> Adrian Hunter (4):
>       perf/core: Add aux_pause, aux_resume, aux_start_paused
>       perf/x86/intel/pt: Add support for pause / resume
>       perf tools: Add support for AUX area pause / resume
>       coresight: Have a stab at support for pause / resume
> 
>  arch/x86/events/intel/pt.c                       | 63 ++++++++++++++++++++-
>  arch/x86/events/intel/pt.h                       |  4 ++
>  drivers/hwtracing/coresight/coresight-etm-perf.c | 29 ++++++++--
>  include/linux/perf_event.h                       | 15 +++++
>  include/uapi/linux/perf_event.h                  | 11 +++-
>  kernel/events/core.c                             | 72 +++++++++++++++++++++++-
>  kernel/events/internal.h                         |  1 +
>  tools/include/uapi/linux/perf_event.h            | 11 +++-
>  tools/perf/util/auxtrace.c                       |  4 ++
>  tools/perf/util/evsel.c                          |  9 +++
>  tools/perf/util/evsel_config.h                   |  6 ++
>  tools/perf/util/parse-events.c                   | 33 +++++++++++
>  tools/perf/util/parse-events.h                   |  3 +
>  tools/perf/util/parse-events.l                   |  3 +
>  tools/perf/util/perf_event_attr_fprintf.c        |  3 +
>  15 files changed, 255 insertions(+), 12 deletions(-)
> 
> 
> Regards
> Adrian



From jiapeng.chong at linux.alibaba.com  Mon Dec 18 22:26:35 2023
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Tue, 19 Dec 2023 14:26:35 +0800
Subject: [PATCH] drm/rockchip: vop2: clean up some inconsistent indenting
Message-ID: <20231219062635.100718-1-jiapeng.chong@linux.alibaba.com>

No functional modification involved.

drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:1708 rk3588_calc_cru_cfg() warn: inconsistent indenting.

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7778
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 44508c2dd614..d3fad523bd6e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1705,8 +1705,8 @@ static unsigned long rk3588_calc_cru_cfg(struct vop2_video_port *vp, int id,
 		 * *if_pixclk_div = dclk_rate / if_pixclk_rate;
 		 * *if_dclk_div = dclk_rate / if_dclk_rate;
 		 */
-		 *if_pixclk_div = 2;
-		 *if_dclk_div = 4;
+		*if_pixclk_div = 2;
+		*if_dclk_div = 4;
 	} else if (vop2_output_if_is_edp(id)) {
 		/*
 		 * edp_pixclk = edp_dclk > dclk_core
-- 
2.20.1.7.g153144c



From srinivas.goud at amd.com  Mon Dec 18 22:34:11 2023
From: srinivas.goud at amd.com (Goud, Srinivas)
Date: Tue, 19 Dec 2023 06:34:11 +0000
Subject: [PATCH v7 0/3] can: xilinx_can: Add ECC feature support
In-Reply-To: <1701080895-1475-1-git-send-email-srinivas.goud@amd.com>
References: <1701080895-1475-1-git-send-email-srinivas.goud@amd.com>
Message-ID: <PH8PR12MB6675D8145EA3B95315186C72E197A@PH8PR12MB6675.namprd12.prod.outlook.com>

Ping!

>-----Original Message-----
>From: Srinivas Goud <srinivas.goud at amd.com>
>Sent: Monday, November 27, 2023 3:58 PM
>To: wg at grandegger.com; mkl at pengutronix.de; davem at davemloft.net;
>edumazet at google.com; kuba at kernel.org; pabeni at redhat.com;
>robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org; conor+dt at kernel.org;
>p.zabel at pengutronix.de
>Cc: git (AMD-Xilinx) <git at amd.com>; michal.simek at xilinx.com; linux-
>can at vger.kernel.org; netdev at vger.kernel.org; devicetree at vger.kernel.org;
>linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
>appana.durga.rao at xilinx.com; Goud, Srinivas <srinivas.goud at amd.com>
>Subject: [PATCH v7 0/3] can: xilinx_can: Add ECC feature support
>
>Add ECC feature support to Tx and Rx FIFOs for Xilinx CAN Controller.
>ECC is an IP configuration option where counter registers are added in IP for
>1bit/2bit ECC errors count and reset.
>Also driver reports 1bit/2bit ECC errors for FIFOs based on ECC error interrupts.
>
>Add xlnx,has-ecc optional property for Xilinx AXI CAN controller to support ECC
>if the ECC block is enabled in the HW.
>
>Add ethtool stats interface for getting all the ECC errors information.
>
>There is no public documentation for it available.
>
>---
>BRANCH: linux-can-next/master
>
>Changes in v7:
>Update with spinlock only for stats counters
>
>Changes in v6:
>Update commit description
>
>Changes in v5:
>Fix review comments
>Change the sequence of updates the stats Add get_strings and get_sset_count
>stats interface Use u64 stats helper function
>
>Changes in v4:
>Fix DT binding check warning
>Update xlnx,has-ecc property description
>
>Changes in v3:
>Update mailing list
>Update commit description
>
>Changes in v2:
>Address review comments
>Add ethtool stats interface
>Update commit description
>
>
>Srinivas Goud (3):
>  dt-bindings: can: xilinx_can: Add 'xlnx,has-ecc' optional property
>  can: xilinx_can: Add ECC support
>  can: xilinx_can: Add ethtool stats interface for ECC errors
>
> .../devicetree/bindings/net/can/xilinx,can.yaml    |   5 +
> drivers/net/can/xilinx_can.c                       | 159 ++++++++++++++++++++-
> 2 files changed, 160 insertions(+), 4 deletions(-)
>
>--
>2.1.1



From quic_taozha at quicinc.com  Mon Dec 18 22:58:21 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Tue, 19 Dec 2023 14:58:21 +0800
Subject: [PATCH v3 8/8] coresight-tpdm: Add msr register support for CMB
In-Reply-To: <185b23e7-a42f-4a12-85ba-8a093bc5ea58@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-9-git-send-email-quic_taozha@quicinc.com>
 <185b23e7-a42f-4a12-85ba-8a093bc5ea58@arm.com>
Message-ID: <4409f3cf-7ca9-407f-92c0-5aa7ba6f7b61@quicinc.com>


On 12/18/2023 7:02 PM, Suzuki K Poulose wrote:
> On 21/11/2023 02:24, Tao Zhang wrote:
>> Add the nodes for CMB subunit MSR(mux select register) support.
>> CMB MSRs(mux select registers) is to separate mux,arbitration,
>> ,interleaving,data packing control from stream filtering control.
>>
>> Reviewed-by: James Clark <james.clark at arm.com>
>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>> ---
>> ? .../testing/sysfs-bus-coresight-devices-tpdm? |? 8 ++
>> ? drivers/hwtracing/coresight/coresight-tpdm.c? | 86 +++++++++++++++++++
>> ? drivers/hwtracing/coresight/coresight-tpdm.h? | 16 +++-
>> ? 3 files changed, 109 insertions(+), 1 deletion(-)
>>
>> diff --git 
>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm 
>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>> index e0b77107be13..914f3fd81525 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>> @@ -249,3 +249,11 @@ Description:
>> ????????? Accepts only one of the 2 values -? 0 or 1.
>> ????????? 0 : Disable the timestamp of all trace packets.
>> ????????? 1 : Enable the timestamp of all trace packets.
>> +
>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31]
>> +Date:??????? September 2023
>> +KernelVersion??? 6.7
>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang 
>> (QUIC) <quic_taozha at quicinc.com>
>> +Description:
>> +??????? (RW) Set/Get the MSR(mux select register) for the CMB subunit
>> +??????? TPDM.
>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>> index f6cda5616e84..7e331ea436cc 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>> @@ -86,6 +86,11 @@ static ssize_t tpdm_simple_dataset_show(struct 
>> device *dev,
>> ????????????? return -EINVAL;
>> ????????? return sysfs_emit(buf, "0x%x\n",
>> ????????????? drvdata->cmb->patt_mask[tpdm_attr->idx]);
>> +??? case CMB_MSR:
>> +??????? if (tpdm_attr->idx >= drvdata->cmb_msr_num)
>> +??????????? return -EINVAL;
>> +??????? return sysfs_emit(buf, "0x%x\n",
>> +??????????????? drvdata->cmb->msr[tpdm_attr->idx]);
>> ????? }
>> ????? return -EINVAL;
>> ? }
>> @@ -162,6 +167,12 @@ static ssize_t tpdm_simple_dataset_store(struct 
>> device *dev,
>> ????????? else
>> ????????????? ret = -EINVAL;
>> ????????? break;
>> +??? case CMB_MSR:
>> +??????? if (tpdm_attr->idx < drvdata->cmb_msr_num)
>> +??????????? drvdata->cmb->msr[tpdm_attr->idx] = val;
>> +??????? else
>> +??????????? ret = -EINVAL;
>
>
> minor nit: Could we not break from here instead of adding return -EINVAL
> for each case ? (I understand it has been done for the existing cases.
> But I think we should clean up all of that, including the ones you added
> in Patch 5. Similarly for the dataset_show()

Sure, do I also need to change the DSB corresponding code? If so, how about

if I add a new patch to the next patch series to change the previous 
existing cases?


Best,

Tao

>
>
> Suzuki
>
>
>> +??????? break;
>> ????? default:
>> ????????? ret = -EINVAL;
>> ????? }
>> @@ -220,6 +231,23 @@ static umode_t tpdm_dsb_msr_is_visible(struct 
>> kobject *kobj,
>> ????? return 0;
>> ? }
>> ? +static umode_t tpdm_cmb_msr_is_visible(struct kobject *kobj,
>> +?????????????????????? struct attribute *attr, int n)
>> +{
>> +??? struct device *dev = kobj_to_dev(kobj);
>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +
>> +??? struct device_attribute *dev_attr =
>> +??????? container_of(attr, struct device_attribute, attr);
>> +??? struct tpdm_dataset_attribute *tpdm_attr =
>> +??????? container_of(dev_attr, struct tpdm_dataset_attribute, attr);
>> +
>> +??? if (tpdm_attr->idx < drvdata->cmb_msr_num)
>> +??????? return attr->mode;
>> +
>> +??? return 0;
>> +}
>> +
>> ? static void tpdm_reset_datasets(struct tpdm_drvdata *drvdata)
>> ? {
>> ????? if (tpdm_has_dsb_dataset(drvdata)) {
>> @@ -361,6 +389,15 @@ static void set_cmb_tier(struct tpdm_drvdata 
>> *drvdata)
>> ????? writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>> ? }
>> ? +static void set_cmb_msr(struct tpdm_drvdata *drvdata)
>> +{
>> +??? int i;
>> +
>> +??? for (i = 0; i < drvdata->cmb_msr_num; i++)
>> +??????? writel_relaxed(drvdata->cmb->msr[i],
>> +?????????????? drvdata->base + TPDM_CMB_MSR(i));
>> +}
>> +
>> ? static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>> ? {
>> ????? u32 val, i;
>> @@ -379,6 +416,8 @@ static void tpdm_enable_cmb(struct tpdm_drvdata 
>> *drvdata)
>> ? ????? set_cmb_tier(drvdata);
>> ? +??? set_cmb_msr(drvdata);
>> +
>> ????? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>> ????? /*
>> ?????? * Set to 0 for continuous CMB collection mode,
>> @@ -1084,6 +1123,42 @@ static struct attribute *tpdm_cmb_patt_attrs[] 
>> = {
>> ????? NULL,
>> ? };
>> ? +static struct attribute *tpdm_cmb_msr_attrs[] = {
>> +??? CMB_MSR_ATTR(0),
>> +??? CMB_MSR_ATTR(1),
>> +??? CMB_MSR_ATTR(2),
>> +??? CMB_MSR_ATTR(3),
>> +??? CMB_MSR_ATTR(4),
>> +??? CMB_MSR_ATTR(5),
>> +??? CMB_MSR_ATTR(6),
>> +??? CMB_MSR_ATTR(7),
>> +??? CMB_MSR_ATTR(8),
>> +??? CMB_MSR_ATTR(9),
>> +??? CMB_MSR_ATTR(10),
>> +??? CMB_MSR_ATTR(11),
>> +??? CMB_MSR_ATTR(12),
>> +??? CMB_MSR_ATTR(13),
>> +??? CMB_MSR_ATTR(14),
>> +??? CMB_MSR_ATTR(15),
>> +??? CMB_MSR_ATTR(16),
>> +??? CMB_MSR_ATTR(17),
>> +??? CMB_MSR_ATTR(18),
>> +??? CMB_MSR_ATTR(19),
>> +??? CMB_MSR_ATTR(20),
>> +??? CMB_MSR_ATTR(21),
>> +??? CMB_MSR_ATTR(22),
>> +??? CMB_MSR_ATTR(23),
>> +??? CMB_MSR_ATTR(24),
>> +??? CMB_MSR_ATTR(25),
>> +??? CMB_MSR_ATTR(26),
>> +??? CMB_MSR_ATTR(27),
>> +??? CMB_MSR_ATTR(28),
>> +??? CMB_MSR_ATTR(29),
>> +??? CMB_MSR_ATTR(30),
>> +??? CMB_MSR_ATTR(31),
>> +??? NULL,
>> +};
>> +
>> ? static struct attribute *tpdm_dsb_attrs[] = {
>> ????? &dev_attr_dsb_mode.attr,
>> ????? &dev_attr_dsb_trig_ts.attr,
>> @@ -1144,6 +1219,12 @@ static struct attribute_group 
>> tpdm_cmb_patt_grp = {
>> ????? .name = "cmb_patt",
>> ? };
>> ? +static struct attribute_group tpdm_cmb_msr_grp = {
>> +??? .attrs = tpdm_cmb_msr_attrs,
>> +??? .is_visible = tpdm_cmb_msr_is_visible,
>> +??? .name = "cmb_msr",
>> +};
>> +
>> ? static const struct attribute_group *tpdm_attr_grps[] = {
>> ????? &tpdm_attr_grp,
>> ????? &tpdm_dsb_attr_grp,
>> @@ -1154,6 +1235,7 @@ static const struct attribute_group 
>> *tpdm_attr_grps[] = {
>> ????? &tpdm_cmb_attr_grp,
>> ????? &tpdm_cmb_trig_patt_grp,
>> ????? &tpdm_cmb_patt_grp,
>> +??? &tpdm_cmb_msr_grp,
>> ????? NULL,
>> ? };
>> ? @@ -1192,6 +1274,10 @@ static int tpdm_probe(struct amba_device 
>> *adev, const struct amba_id *id)
>> ????????? of_property_read_u32(drvdata->dev->of_node,
>> ???????????????? "qcom,dsb-msrs-num", &drvdata->dsb_msr_num);
>> ? +??? if (drvdata && tpdm_has_cmb_dataset(drvdata))
>> +??????? of_property_read_u32(drvdata->dev->of_node,
>> +?????????????? "qcom,cmb-msrs-num", &drvdata->cmb_msr_num);
>> +
>> ????? /* Set up coresight component description */
>> ????? desc.name = coresight_alloc_device_name(&tpdm_devs, dev);
>> ????? if (!desc.name)
>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>> index 65b7ca6c4077..255104d024ab 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>> @@ -21,6 +21,8 @@
>> ? #define TPDM_CMB_XPR(n)??????? (0xA18 + (n * 4))
>> ? /*CMB subunit trigger pattern mask registers*/
>> ? #define TPDM_CMB_XPMR(n)??? (0xA20 + (n * 4))
>> +/* CMB MSR register */
>> +#define TPDM_CMB_MSR(n)??????? (0xA80 + (n * 4))
>> ? ? /* Enable bit for CMB subunit */
>> ? #define TPDM_CMB_CR_ENA??????? BIT(0)
>> @@ -36,6 +38,9 @@
>> ? /*Patten register number*/
>> ? #define TPDM_CMB_MAX_PATT??????? 2
>> ? +/* MAX number of DSB MSR */
>> +#define TPDM_CMB_MAX_MSR 32
>> +
>> ? /* DSB Subunit Registers */
>> ? #define TPDM_DSB_CR??????? (0x780)
>> ? #define TPDM_DSB_TIER??????? (0x784)
>> @@ -186,6 +191,10 @@
>> ????????? tpdm_simple_dataset_rw(tpmr##nr,??????? \
>> ????????? CMB_PATT_MASK, nr)
>> ? +#define CMB_MSR_ATTR(nr)??????????????????? \
>> +??????? tpdm_simple_dataset_rw(msr##nr,??????????? \
>> +??????? CMB_MSR, nr)
>> +
>> ? /**
>> ?? * struct dsb_dataset - specifics associated to dsb dataset
>> ?? * @mode:???????????? DSB programming mode
>> @@ -225,6 +234,7 @@ struct dsb_dataset {
>> ?? * @patt_mask:??????? Save value for pattern mask
>> ?? * @trig_patt:??????? Save value for trigger pattern
>> ?? * @trig_patt_mask:?? Save value for trigger pattern mask
>> + * @msr?????????????? Save value for MSR
>> ?? * @patt_ts:????????? Indicates if pattern match for timestamp is 
>> enabled.
>> ?? * @trig_ts:????????? Indicates if CTI trigger for timestamp is 
>> enabled.
>> ?? * @ts_all:?????????? Indicates if timestamp is enabled for all 
>> packets.
>> @@ -235,6 +245,7 @@ struct cmb_dataset {
>> ????? u32??????????? patt_mask[TPDM_CMB_MAX_PATT];
>> ????? u32??????????? trig_patt[TPDM_CMB_MAX_PATT];
>> ????? u32??????????? trig_patt_mask[TPDM_CMB_MAX_PATT];
>> +??? u32??????????? msr[TPDM_CMB_MAX_MSR];
>> ????? bool??????????? patt_ts;
>> ????? bool??????????? trig_ts;
>> ????? bool??????????? ts_all;
>> @@ -251,6 +262,7 @@ struct cmb_dataset {
>> ?? * @dsb???????? Specifics associated to TPDM DSB.
>> ?? * @cmb???????? Specifics associated to TPDM CMB.
>> ?? * @dsb_msr_num Number of MSR supported by DSB TPDM
>> + * @cmb_msr_num Number of MSR supported by CMB TPDM
>> ?? */
>> ? ? struct tpdm_drvdata {
>> @@ -263,6 +275,7 @@ struct tpdm_drvdata {
>> ????? struct dsb_dataset??? *dsb;
>> ????? struct cmb_dataset??? *cmb;
>> ????? u32??????????? dsb_msr_num;
>> +??? u32??????????? cmb_msr_num;
>> ? };
>> ? ? /* Enumerate members of various datasets */
>> @@ -277,7 +290,8 @@ enum dataset_mem {
>> ????? CMB_TRIG_PATT,
>> ????? CMB_TRIG_PATT_MASK,
>> ????? CMB_PATT,
>> -??? CMB_PATT_MASK
>> +??? CMB_PATT_MASK,
>> +??? CMB_MSR
>> ? };
>> ? ? /**
>
> _______________________________________________
> CoreSight mailing list -- coresight at lists.linaro.org
> To unsubscribe send an email to coresight-leave at lists.linaro.org


From tony at atomide.com  Mon Dec 18 23:06:25 2023
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 19 Dec 2023 09:06:25 +0200
Subject: [PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc
 for wkup_uart0
In-Reply-To: <20231218161902.nfdht2hk5rctzxuu@grievance>
References: <20231114073209.40756-1-tony@atomide.com>
 <20231215160047.uiitnlgmirbudmj5@scored>
 <20231218072831.GX5169@atomide.com>
 <20231218161902.nfdht2hk5rctzxuu@grievance>
Message-ID: <20231219070625.GZ5169@atomide.com>

* Nishanth Menon <nm at ti.com> [231218 16:19]:
> On 09:28-20231218, Tony Lindgren wrote:
> > * Nishanth Menon <nm at ti.com> [231215 16:00]:
> > > On 09:32-20231114, Tony Lindgren wrote:
> > > > -	wkup_uart0: serial at 2b300000 {
> > > > -		compatible = "ti,am64-uart", "ti,am654-uart";
> > > > -		reg = <0x00 0x2b300000 0x00 0x100>;
> > > > -		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> > > > +	target-module at 2b300000 {
> > > 
> > > should be  target-module at 2b300050 to match up with reg?
> > 
> > It's best to use the target-module IO range here, not the first reg.
> > The first reg may be tossed anywhere in the target module address
> > space depending on the device.
> > 
> > Ideally of course there would be just a standardized range of target
> > module related registers at the end of the IO space..
> 
> Sorry Tony, but the node address must matchup with the reg description
> for the node. I'd rather not sit and argue about this with automated
> tools and deal with trivial patches - so either tools like dtc need to
> ignore this or lets just fix the node address.

Oh sorry I did not mean to add a make W=1 dtbs warning. Yeah let's change
the node name to match the first reg to avoid the warning.

It should be also add some better checks for node names with ranges but
with just a few control registers.

Regards,

Tony


From krzysztof.kozlowski at linaro.org  Mon Dec 18 23:21:17 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 08:21:17 +0100
Subject: [PATCH v4 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support
 for 74165b0
In-Reply-To: <20231218210705.38201-2-kamal.dasu@broadcom.com>
References: <20231218210705.38201-1-kamal.dasu@broadcom.com>
 <20231218210705.38201-2-kamal.dasu@broadcom.com>
Message-ID: <61c15b50-5bb9-4288-a2dd-efc695f4a6f6@linaro.org>

On 18/12/2023 22:07, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> With newer sdio controller core used for 74165b0 we need to update
> the compatibility with "brcm,bcm74165b0-sdhci".
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312101146.IK4Nrw1S-lkp at intel.com/

What was reported by robot? New SoC? You already received such feedback!
This does not make any sense.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 18 23:22:00 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 08:22:00 +0100
Subject: [PATCH v4 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231218210705.38201-3-kamal.dasu@broadcom.com>
References: <20231218210705.38201-1-kamal.dasu@broadcom.com>
 <20231218210705.38201-3-kamal.dasu@broadcom.com>
Message-ID: <a630b011-4ad0-49d1-8076-647bc44f9d08@linaro.org>

On 18/12/2023 22:07, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> 74165b0 shall use a new sdio controller core version which
> requires a different reset sequence. For core reset we use
> sdhci_reset. For CMD and/or DATA reset added a new function
> to also enable SDHCI clocks SDHCI_CLOCK_CARD_EN
> SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
> SDHCI_RESET_DATA fields.
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312091608.0VbkRxlh-lkp at intel.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202312091905.UGzltx8A-lkp at intel.com/

So again: drop the tags. Please reach to your Broadcom folks to get some
basic guidance on submission process.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 18 23:24:51 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 08:24:51 +0100
Subject: [PATCH v4 1/9] dt-bindings: net: starfive,jh7110-dwmac: Drop
 redundant reset description
In-Reply-To: <20231218214451.2345691-2-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <20231218214451.2345691-2-cristian.ciocaltea@collabora.com>
Message-ID: <92eb5f85-1241-429c-aca9-7a6a17f19ae5@linaro.org>

On 18/12/2023 22:44, Cristian Ciocaltea wrote:
> The reset description items are already provided by the referenced
> snps,dwmac.yaml schema, hence replace them with the necessary
> {min,max}Items.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
> ---
>  .../devicetree/bindings/net/starfive,jh7110-dwmac.yaml       | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> index 5e7cfbbebce6..d90cb82c1424 100644
> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> @@ -55,9 +55,8 @@ properties:
>      maxItems: 3
>  
>    resets:
> -    items:
> -      - description: MAC Reset signal.
> -      - description: AHB Reset signal.
> +    minItems: 2
> +    maxItems: 2

Why changing only resets, but not reset-names?

Best regards,
Krzysztof



From jiangkunkun at huawei.com  Mon Dec 18 23:24:55 2023
From: jiangkunkun at huawei.com (Kunkun Jiang)
Date: Tue, 19 Dec 2023 15:24:55 +0800
Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset
In-Reply-To: <87a5q983zc.wl-maz@kernel.org>
References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
 <87a5q983zc.wl-maz@kernel.org>
Message-ID: <bb4984d2-ed80-ba97-0f58-b45db4f0ff32@huawei.com>

Hi Marc and Oliver,

On 2023/12/17 19:26, Marc Zyngier wrote:
> On Thu, 14 Dec 2023 12:13:57 +0000,
> Kunkun Jiang <jiangkunkun at huawei.com> wrote:
>> Hi list,
>>
>> We have observed on GICv4.1 systems that, after a guest reset, the
>> secondary VCPU would receive an IPI_CPU_STOP accidently and failed to
>> come online eventually.
>>
>> | Guest User-space
> Guest userspace????
Sorry. The formatting is a bit messy.
|??????????? Guest?????????????????????????????? User-space
|
|? reset (with a vSGI pending in the
|? hardware) [0]
|
|???????????????????????????????????? disable the distributor (write 0
|???????????????????????????????????? into GICD_CTLR) [1]
|
|???????????????????????????????????? clear pending status (write 0 into
|???????????????????????????????????? GICR_ISPENDR0 for each RD) [2]
|
|? disable the distributor (write 0
|? into GICD_CTLR) [3]
|
|? enable the distributor with ARE,
|? Group1 and nASSGIreq [4]
>> |
>> | reset (with a vSGI pending in the
>> | hardware) [0]
>> |
>> | disable the distributor (write 0
>> | into GICD_CTLR) [1]
>> |
>> | clear pending status (write 0 into
>> | GICR_ISPENDR0 for each RD) [2]
> This cannot clear the pending bits. Writing 0 to any of the
> ISPEND/ICPEND registers is effectively a NOP.
>
> If you want to remove the pending SGIs, you need to write a bunch of
> 1s to ICPENDR0.
>
>> |
>> | disable the distributor (write 0
>> | into GICD_CTLR) [3]
>> |
>> | enable the distributor with ARE,
>> | Group1 and nASSGIreq [4]
>>
>> The problem is that even if user-space tries to disable the distributor
> I don't understand what userspace does here. Why is it significant
> that it is an EL0 access? I don't know of any SW doing that, but even
> if it existed, this should make no difference.
>
>> and clear pending bits for all SGIs, we don't actually propogate it into
>> HW (we only record it via vgic_dist->{enabled, nassgireq} and
>> vgic_irq->pending_latch) and the vSGI remains pending across the guest
>> reset.
>>
>> And when we're at [4], all vSGI's vgic_irq->hw are *true* and
>> vgic_v4_enable_vsgis() becomes a nop.. That's not good.
>>
>> The following solution can solve the problem. Not sure if this is a good
>> solution.Sent out early for suggestions or solutions.
>>
>> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
>> b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
>> index 89117ba2528a..3678ab33f5b9 100644
>> --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
>> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
>> @@ -374,6 +374,10 @@ static int vgic_v3_uaccess_write_pending(struct
>> kvm_vcpu *vcpu,
>>  ???? ??? ??? irq->pending_latch = true;
>>  ???? ??? ??? vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
>>  ???? ??? } else {
>> + ??? ??? ??? if (irq->hw && vgic_irq_is_sgi(irq->intid))
>> + ??? ??? ??? ??? irq_set_irqchip_state(irq->host_irq,
>> + ??? ??? ??? ??? ??? ??? ???? IRQCHIP_STATE_PENDING,
>> + ??? ??? ??? ??? ??? ??? ???? false);
>>  ???? ??? ??? irq->pending_latch = false;
>>  ???? ??? ??? raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
>>  ???? ??? }
>>
> But this has *nothing* to do with the guest. This is the *host*
> userspace performing a write to the redistributor view, which has
> different semantics. Which is why your earlier description made no
> sense to me.
>
> I think the problem is slightly larger than what you describe. A write
> to ISPENDR0 should be propagated to the ITS for any values of the
> latch, just like this happens on enabling HW-backed SGIs.
>
> Can you please give this a go?
I have given it a go. I tested reseting the guest 100 times in succession,
and the problem did not occur again.

Thanks,
Kunkun Jiang
> Thanks,
>
> 	M.
>
> >From 9932d74392d969057e84bc3c18bd15f1769b6211 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <maz at kernel.org>
> Date: Sun, 17 Dec 2023 11:15:09 +0000
> Subject: [PATCH] KVM: arm64: vgic-v4: Restore pending state on host userspace
>   write
>
> When the VMM writes to ISPENDR0 to set the state pending state of
> an SGI, we fail to convey this to the HW if this SGI is already
> backed by a GICv4.1 vSGI.
>
> This is a bit of a corner case, as this would only occur if the
> vgic state is changed on an already running VM, but this can
> apparently happen across a guest reset driven by the VMM.
>
> Fix this by always writing out the pending_latch value to the
> HW, and reseting it to false.
>
> Reported-by: Kunkun Jiang <jiangkunkun at huawei.com>
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> Link: https://lore.kernel.org/r/7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32 at huawei.com
> ---
>   arch/arm64/kvm/vgic/vgic-mmio-v3.c | 27 +++++++++++++++++----------
>   1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> index a764b0ab8bf9..2533f264b954 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> @@ -365,19 +365,26 @@ static int vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
>   		struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
>   
>   		raw_spin_lock_irqsave(&irq->irq_lock, flags);
> -		if (test_bit(i, &val)) {
> -			/*
> -			 * pending_latch is set irrespective of irq type
> -			 * (level or edge) to avoid dependency that VM should
> -			 * restore irq config before pending info.
> -			 */
> -			irq->pending_latch = true;
> -			vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> -		} else {
> +
> +		/*
> +		 * pending_latch is set irrespective of irq type
> +		 * (level or edge) to avoid dependency that VM should
> +		 * restore irq config before pending info.
> +		 */
> +		irq->pending_latch = test_bit(i, &val);
> +
> +		if (irq->hw && vgic_irq_is_sgi(irq->intid)) {
> +			irq_set_irqchip_state(irq->host_irq,
> +					      IRQCHIP_STATE_PENDING,
> +					      irq->pending_latch);
>   			irq->pending_latch = false;
> -			raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
>   		}
>   
> +		if (irq->pending_latch)
> +			vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> +		else
> +			raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
> +
>   		vgic_put_irq(vcpu->kvm, irq);
>   	}
>   


From tony at atomide.com  Mon Dec 18 23:25:01 2023
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 19 Dec 2023 09:25:01 +0200
Subject: [PATCH v4 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0
Message-ID: <20231219072503.12427-1-tony@atomide.com>

The devices in the wkup domain are capable of waking up the system from
suspend. We can configure the wkup domain devices in a generic way using
the ti-sysc interconnect target module driver like we have done with the
earlier TI SoCs.

As ti-sysc manages the SYSCONFIG related registers independent of the
child hardware device, the wake-up configuration is also set even if
wkup_uart0 is reserved by sysfw.

The wkup_uart0 device has interconnect target module register mapping like
dra7 wkup uart. There is a 1 MB interconnect target range with one uart IP
block in the target module. The power domain and clock affects the whole
interconnect target module.

Note we change the functional clock name to follow the ti-sysc binding
and use "fck" instead of "fclk".

Tested-by: Dhruva Gole <d-gole at ti.com>
Reviewed-by: Kevin Hilman <khilman at baylibre.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---

Changes since v3:

- Use the first reg for the target module node name to avoid a
  make W=1 dtbs warning as noted by Nishanth

Changes since v2:

- Fix node name for 8250 IP, it's at offset 0 from the target module

- Added Kevin's Reviewed-by from v2 as the node name change is mostly
  cosmetic

Changes since v1:

- Added Tested-by from Dhruva

---
 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi | 33 ++++++++++++++++++----
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
--- a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
@@ -5,6 +5,8 @@
  * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
  */
 
+#include <dt-bindings/bus/ti-sysc.h>
+
 &cbass_wakeup {
 	wkup_conf: syscon at 43000000 {
 		bootph-all;
@@ -21,14 +23,33 @@ chipid: chipid at 14 {
 		};
 	};
 
-	wkup_uart0: serial at 2b300000 {
-		compatible = "ti,am64-uart", "ti,am654-uart";
-		reg = <0x00 0x2b300000 0x00 0x100>;
-		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+	target-module at 2b300050 {
+		compatible = "ti,sysc-omap2", "ti,sysc";
+		reg = <0 0x2b300050 0 0x4>,
+		      <0 0x2b300054 0 0x4>,
+		      <0 0x2b300058 0 0x4>;
+		reg-names = "rev", "sysc", "syss";
+		ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
+				 SYSC_OMAP2_SOFTRESET |
+				 SYSC_OMAP2_AUTOIDLE)>;
+		ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+				<SYSC_IDLE_NO>,
+				<SYSC_IDLE_SMART>,
+				<SYSC_IDLE_SMART_WKUP>;
+		ti,syss-mask = <1>;
 		power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
 		clocks = <&k3_clks 114 0>;
-		clock-names = "fclk";
-		status = "disabled";
+		clock-names = "fck";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0 0x2b300000 0x100000>;
+
+		wkup_uart0: serial at 0 {
+			compatible = "ti,am64-uart", "ti,am654-uart";
+			reg = <0 0x100>;
+			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
 	};
 
 	wkup_i2c0: i2c at 2b200000 {
-- 
2.43.0


From krzysztof.kozlowski at linaro.org  Mon Dec 18 23:27:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 08:27:53 +0100
Subject: [PATCH v4 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <20231218214451.2345691-3-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <20231218214451.2345691-3-cristian.ciocaltea@collabora.com>
Message-ID: <c9225053-78f8-40b7-9453-dc3dabe44500@linaro.org>

On 18/12/2023 22:44, Cristian Ciocaltea wrote:
> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
> similar to the newer JH7110, but it requires only two interrupts and a
> single reset line, which is 'ahb' instead of the commonly used
> 'stmmaceth'.
> 

>    reg:
> @@ -145,9 +146,13 @@ properties:
>  
>    reset-names:
>      minItems: 1
> -    items:
> -      - const: stmmaceth
> -      - const: ahb
> +    maxItems: 2

min and maxItems should not be needed here.

> +    oneOf:
> +      - items:
> +          - enum: [stmmaceth, ahb]
> +      - items:
> +          - const: stmmaceth
> +          - const: ahb
>  
>    power-domains:
>      maxItems: 1
> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> index d90cb82c1424..f5f0bff5be0f 100644
> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> @@ -16,16 +16,20 @@ select:
>      compatible:
>        contains:
>          enum:
> +          - starfive,jh7100-dwmac
>            - starfive,jh7110-dwmac
>    required:
>      - compatible
>  
>  properties:
>    compatible:
> -    items:
> -      - enum:
> -          - starfive,jh7110-dwmac
> -      - const: snps,dwmac-5.20
> +    oneOf:
> +      - items:
> +          - const: starfive,jh7100-dwmac
> +          - const: snps,dwmac
> +      - items:
> +          - const: starfive,jh7110-dwmac
> +          - const: snps,dwmac-5.20
>  
>    reg:
>      maxItems: 1
> @@ -46,23 +50,6 @@ properties:
>        - const: tx
>        - const: gtx
>  
> -  interrupts:
> -    minItems: 3
> -    maxItems: 3
> -
> -  interrupt-names:
> -    minItems: 3
> -    maxItems: 3
> -
> -  resets:
> -    minItems: 2
> -    maxItems: 2

What is the point of your previous patch if you immediately remove it?
It is a no-op. Just mention in this commit msg, that both resets and
reset-names are coming from snps,dwmac so they can be removed from
top-level entirely.

Best regards,
Krzysztof



From xu.yang_2 at nxp.com  Mon Dec 18 23:35:48 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Tue, 19 Dec 2023 07:35:48 +0000
Subject: [EXT] Re: [PATCH v2 2/5] arm64: dts: imx8ulp-evk: enable usb
 nodes and add ptn5150 nodes
In-Reply-To: <CAOMZO5AZ6oLgeqvwf5_u9YhrFvwgRSiNjGq+wVMjXYsq7t3MxA@mail.gmail.com>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com>
 <20231218085456.3962720-2-xu.yang_2@nxp.com>
 <CAOMZO5AZ6oLgeqvwf5_u9YhrFvwgRSiNjGq+wVMjXYsq7t3MxA@mail.gmail.com>
Message-ID: <DB7PR04MB51469ABA1E7922B839B4F36E8C97A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Fabio,

> 
> On Mon, Dec 18, 2023 at 5:49?AM Xu Yang <xu.yang_2 at nxp.com> wrote:
> 
> > +
> > +       ptn5150_1: typec at 1d {
> > +               compatible = "nxp,ptn5150";
> > +               reg = <0x1d>;
> > +               int-gpios = <&gpiof 3 IRQ_TYPE_EDGE_FALLING>;
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&pinctrl_typec1>;
> > +               status = "disabled";
> 
> Why disabled?

As we talked before,  I just present these nodes here since the
i.MX8ULP board does have these chips. And I think the above 
information is enough to let people know and use it if they
really want. In most of the cases, it's not needed. 

> 
> No connector and no port properties. Please run dt-schema check
> against linux-next.

The ptn5150 driver doesn't have any relation with typec subsystem. As
Jun said, it uses extcon. 

Also I have run dt-schema check, no warnings.

Thanks,
Xu Yang
	
> 
> > +       };
> > +
> > +       ptn5150_2: typec at 3d {
> > +               compatible = "nxp,ptn5150";
> > +               reg = <0x3d>;
> > +               int-gpios = <&gpiof 5 IRQ_TYPE_EDGE_FALLING>;
> > +                       pinctrl-names = "default";
> > +               pinctrl-0 = <&pinctrl_typec2>;
> > +               status = "disabled";
> 
> Same here.

From Randy.Li at synaptics.com  Mon Dec 18 23:47:38 2023
From: Randy.Li at synaptics.com (Hsia-Jun Li)
Date: Tue, 19 Dec 2023 15:47:38 +0800
Subject: Could external jtag debugger trap page fault instead of kernel
 handler?
Message-ID: <b8ccbd62-7a0d-49eb-bc32-c48e59adeae6@synaptics.com>

Hello

I am trying to debug an illegal memory access problem for a kernel 
driver. The JTAG could trap the kernel function likes 
die_kernel_fault(). But it won't provide a context environment in the 
place where this bug happens.

I know such page fault is more like a software interrupter, is there a 
way that I could move my debugging context back?

Here is what I got from gdb connected to openocd.
(gdb) bt 

#0  __do_kernel_fault (addr=16045481047390945544, addr at entry=264, 
esr=2516582468, regs=0xffffff802937b940)
     at 
/Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:372 

#1  0xffffffc00802c174 in do_bad_area (regs=<optimized out>, 
esr=<optimized out>, far=16045481047390945544)
     at 
/Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:485 

#2  do_translation_fault (far=16045481047390945544, esr=<optimized out>, 
regs=<optimized out>)
     at 
/Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:782 

#3  0xffffffc00802c2cc in do_mem_abort (far=16045481047390945544, 
esr=2516582468, regs=0xffffff802937b940)
     at 
/Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:918 

#4  0xffffffc00889738c in skb_dump (level=0xdead000000000108 "", 
skb=0xffffff802937b940, full_pkt=112)
     at 
/Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/core/skbuff.c:834 

#5  0x0000000000000000 in ?? () 

Backtrace stopped: not enough registers or memory available to unwind 
further
(gdb) info threads
   Id   Target Id 
         Frame
   1    Thread 1 "vs640.cpu_a53.0" (Name: vs640.cpu_a53.0, state: 
debug-request) 0xffffffc008898038 in nf_l4proto_log_inv
alid (skb=0xffffffc0086391a0 <psci_enter_idle_state>, state=0xffffffff, 
protonum=0 '\000', fmt=0x258208 "")
     at 
/Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/netfilter/nf_conntrack_proto.c:62
* 2    Thread 2 "vs640.cpu_a53.1" (Name: vs640.cpu_a53.1, state: 
breakpoint)    __do_kernel_fault (
     addr=16045481047390945544, addr at entry=264, esr=2516582468, 
regs=0xffffff802937b940)
     at 
/Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:372
   3    Thread 3 "vs640.cpu_a53.2" (Name: vs640.cpu_a53.2, state: 
debug-request) 0xffffffc008898038 in nf_l4proto_log_inv
alid (skb=0xffffffc0086391a0 <psci_enter_idle_state>, state=0xffffffff, 
protonum=0 '\000', fmt=0x9f2270 "")
     at 
/Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/netfilter/nf_conntrack_proto.c:62
   4    Thread 4 "vs640.cpu_a53.3" (Name: vs640.cpu_a53.3, state: 
debug-request) 0xffffffc008898038 in nf_l4proto_log_inv
alid (skb=0xffffffc0086391a0 <psci_enter_idle_state>, state=0xffffffff, 
protonum=0 '\000', fmt=0x20ded8 "")
     at 
/Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/netfilter/nf_conntrack_proto.c:62

And here is the issue I am trying to debug:
[ 5478.863161] Unable to handle kernel paging request at virtual address 
dead000000000108
[ 5478.871093] Mem abort info:
[ 5478.873886]   ESR = 0x96000044
[ 5478.876938]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 5478.882249]   SET = 0, FnV = 0
[ 5478.885301]   EA = 0, S1PTW = 0
[ 5478.888440]   FSC = 0x04: level 0 translation fault
[ 5478.893318] Data abort info:
[ 5478.896195]   ISV = 0, ISS = 0x00000044
[ 5478.900029]   CM = 0, WnR = 1
[ 5478.902996] [dead000000000108] address between user and kernel 
address ranges
[ 5478.910129] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 5478.915701] Modules linked in: vpu videobuf2_memops v4l2_mem2mem 
videobuf2_v4l2 videobuf2_common videodev mc synap(O)
  pvrsrvkm syna_drm cfg80211 rfkill amp_bm
[ 5478.929897] CPU: 0 PID: 6613 Comm: gst-launch-1.0 Tainted: G        W 
  O      5.15.62 #1
[ 5478.937988] Hardware name: Synaptics VS640 EVK (DT)
[ 5478.942864] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS 
BTYPE=--)
[ 5478.949825] pc : v4l2_m2m_buf_remove+0x50/0x90 [v4l2_mem2mem]
[ 5478.955582] lr : v4l2_m2m_buf_remove+0x20/0x90 [v4l2_mem2mem]
[ 5478.961329] sp : ffffff8026c4fa90
[ 5478.964643] x29: ffffff8026c4fa90 x28: ffffff8026c201b0 x27: 
0000000000000000
[ 5478.971784] x26: 0000000000000000 x25: ffffff8026c4fd28 x24: 
ffffff8009774270
[ 5478.978921] x23: ffffff8025f4c100 x22: 0000000000000001 x21: 
ffffff8025e1f3a0
[ 5478.986059] x20: ffffff8025e6d7b0 x19: ffffff8025e1f028 x18: 
0000000000000000
[ 5478.993197] x17: 0000000000000000 x16: 0000000000000000 x15: 
00000055a1955a10
[ 5479.000335] x14: 0000000000000000 x13: 0000000000000000 x12: 
0000000000000000
[ 5479.007472] x11: 0000000000000000 x10: 0000000000000000 x9 : 
0000000000000000
[ 5479.014609] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 
0000000000000005
[ 5479.021746] x5 : dead000000000100 x4 : dead000000000122 x3 : 
dead000000000100
[ 5479.028884] x2 : dead000000000122 x1 : 0000000000000000 x0 : 
ffffff8025e1f3a0
[ 5479.036021] Call trace:
[ 5479.038467]  v4l2_m2m_buf_remove+0x50/0x90 [v4l2_mem2mem]
[ 5479.043867]  vb2ops_vdec_stop_streaming+0x98/0x160 [vpu]
[ 5479.049184]  __vb2_queue_cancel+0x30/0x210 [videobuf2_common]
[ 5479.054936]  vb2_core_streamoff+0x20/0xb4 [videobuf2_common]
[ 5479.060597]  vb2_streamoff+0x18/0x64 [videobuf2_v4l2]
[ 5479.065654]  v4l2_m2m_streamoff+0x70/0x140 [v4l2_mem2mem]
[ 5479.071055]  v4l2_m2m_ioctl_streamoff+0x14/0x20 [v4l2_mem2mem]
[ 5479.076889]  v4l_streamoff+0x20/0x30 [videodev]
[ 5479.081455]  __video_do_ioctl+0x174/0x3d0 [videodev]

Sincerely
-- 
Hsia-Jun(Randy) Li


From krzysztof.kozlowski at linaro.org  Mon Dec 18 23:47:48 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 08:47:48 +0100
Subject: [PATCH v2 3/5] dt-bindings: usb: ci-hdrc-usb2: add compatible and
 clock-names restriction for imx93
In-Reply-To: <20231218085456.3962720-3-xu.yang_2@nxp.com>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com>
 <20231218085456.3962720-3-xu.yang_2@nxp.com>
Message-ID: <eb93c554-ee35-49a0-adfb-0d3030f9a77b@linaro.org>

On 18/12/2023 09:54, Xu Yang wrote:
> The i.MX93 needs a wakup clock to work properly. This will add compatible
> and restriction for i.MX93 platform.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> ---
> Changes in v2:
>  - no changes

No changes? Where is the v1 in such case?

> ---
>  .../devicetree/bindings/usb/ci-hdrc-usb2.yaml        | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> index b7e664f7395b..4e22b369e43f 100644
> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> @@ -57,6 +57,7 @@ properties:
>            - enum:
>                - fsl,imx8mm-usb
>                - fsl,imx8mn-usb
> +              - fsl,imx93-usb
>            - const: fsl,imx7d-usb
>            - const: fsl,imx27-usb
>        - items:
> @@ -411,6 +412,17 @@ allOf:
>          external-vbus-divider: false
>          samsung,picophy-pre-emp-curr-control: false
>          samsung,picophy-dc-vol-level-adjust: false

Blank line

> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: fsl,imx93-usb
> +    then:
> +      properties:
> +        clock-names:
> +          items:
> +            - const: usb_ctrl_root_clk
> +            - const: usb_wakeup_clk

What about all the reset? reg, interrupts? Maybe it is time to split the
schema into common part and device-specific.



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 18 23:50:52 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 08:50:52 +0100
Subject: [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050
 SM variant
In-Reply-To: <32e9364eb0f95e94f3966a8988c37cdebfb8803f.1702917360.git.jan.kiszka@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <32e9364eb0f95e94f3966a8988c37cdebfb8803f.1702917360.git.jan.kiszka@siemens.com>
Message-ID: <6acdbd95-3921-49a9-9c48-015ede30c271@linaro.org>

On 18/12/2023 17:35, Jan Kiszka wrote:
> From: Su Bao Cheng <baocheng.su at siemens.com>
> 
> This new variant is derived from the Advanced PG2 board, removing the
> Arduino interface, and adding a new ASIC for communicating with the
> PLC 1200 signal modules.
> 

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 18 23:51:38 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 08:51:38 +0100
Subject: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector
 bits
In-Reply-To: <202d324ab0aa3728c8f846d31bedcbaba14aebdd.1702917360.git.jan.kiszka@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <202d324ab0aa3728c8f846d31bedcbaba14aebdd.1702917360.git.jan.kiszka@siemens.com>
Message-ID: <10f300d6-8a1a-4363-a16e-8337da8525d1@linaro.org>

On 18/12/2023 17:35, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka at siemens.com>
> 
> A new variant is to be added which will not have a arduino connector
> like the existing ones. Factor out all bits that are specific to this
> connector.
> 
> The split is not perfect because wkup_gpio0 is defined based on what is
> common to all variants having the connector, thus containing also
> connector-unrelated information. But this is still cleaner than
> replicating this node into all 4 variants.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> ---
>  .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------

Please use proper -B/-M/-C arguments so code movements will be detected.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 18 23:54:27 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 08:54:27 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
Message-ID: <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>

On 18/12/2023 17:36, Jan Kiszka wrote:
> From: Baocheng Su <baocheng.su at siemens.com>
> 
> Main differences between the new variant and Advanced PG2:

Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.

> 
> 1. Arduino interface is removed. Instead, an new ASIC is added for
>    communicating with PLC 1200 signal modules.
> 2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
>    avaiable.
> 3. DP interface is tailored down. Instead, to communicate with the
>    PLC 1200 signal modules, a USB 3.0 type B connector is added but the
>    signal is not USB.
> 4. DDR size is increased to 4 GB.
> 5. Two sensors are added, one tilt sensor and one light sensor.
> 
> The light sensor it not yet added to the DT at this stage as it depends
> on to-be-added bindings.
> 
> Co-developed-by: Chao Zeng <chao.zeng at siemens.com>
> Signed-off-by: Chao Zeng <chao.zeng at siemens.com>
> Co-developed-by: Li Hua Qian <huaqian.li at siemens.com>
> Signed-off-by: Li Hua Qian <huaqian.li at siemens.com>
> Signed-off-by: Baocheng Su <baocheng.su at siemens.com>
> [Jan: rebase over arduino refactoring, split-out light sensor]
> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> ---
>  arch/arm64/boot/dts/ti/Makefile               |   1 +
>  .../dts/ti/k3-am6548-iot2050-advanced-sm.dts  | 210 ++++++++++++++++++
>  2 files changed, 211 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
> 
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 77a347f9f47d..9b15eaad284c 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-m2.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-pg2.dtb
> +dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-sm.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am654-gp-evm.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am654-evm.dtb
> diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
> new file mode 100644
> index 000000000000..ab3eef683890
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
> @@ -0,0 +1,210 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Siemens AG, 2023
> + *
> + * Authors:
> + *   Baocheng Su <baocheng.su at siemens.com>
> + *   Chao Zeng <chao.zeng at siemens.com>
> + *   Huaqian Li <huaqian.li at siemens.com>
> + *
> + * AM6548-based (quad-core) IOT2050 SM variant, Product Generation 2
> + * 4 GB RAM, 16 GB eMMC, USB-serial converter on connector X30
> + *
> + * Product homepage:
> + * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am6548-iot2050-advanced-common.dtsi"
> +#include "k3-am65-iot2050-common-pg2.dtsi"
> +
> +/ {
> +	compatible = "siemens,iot2050-advanced-sm", "ti,am654";
> +	model = "SIMATIC IOT2050 Advanced SM";
> +
> +	memory at 80000000 {
> +		device_type = "memory";
> +		/* 4G RAM */
> +		reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
> +		      <0x00000008 0x80000000 0x00000000 0x80000000>;
> +	};
> +
> +	aliases {
> +		spi1 = &main_spi0;
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&leds_pins_default>, <&user1_led_pins>;
> +
> +		user-led1-red {

led-0

> +			gpios = <&wkup_gpio0 52 GPIO_ACTIVE_HIGH>;

Missing function, missing color. Color goes as property, not as node name.

> +		};
> +
> +		user-led1-green {

led-1

> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;

Ditto


> +
> +&dwc3_0 {
> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
> +	/delete-property/ phys;
> +	/delete-property/ phy-names;

If your board need to remove phys from the SoC node, something is wrong.
Either your board or SoC.

Any removal of properties in DTS is weird and unexpected. It deserves
comments.

> +};
> +
> +&usb0 {
> +	maximum-speed = "high-speed";
> +	/delete-property/ snps,dis-u1-entry-quirk;
> +	/delete-property/ snps,dis-u2-entry-quirk;

Same questions. If SoC has quirks, how can your board be fixed? It's SoC
property... or you are using different SoC.

Best regards,
Krzysztof



From esben at geanix.com  Mon Dec 18 23:43:13 2023
From: esben at geanix.com (esben at geanix.com)
Date: Tue, 19 Dec 2023 08:43:13 +0100
Subject: [PATCH] i2c: i2c-imx: allow bus recovery on non-muxable pads
In-Reply-To: <20231218-i2c-imx-recovery-v1-1-f69fa85b228c@ew.tq-group.com>
	(Gregor Herburger's message of "Mon, 18 Dec 2023 18:06:12 +0100")
References: <20231218-i2c-imx-recovery-v1-1-f69fa85b228c@ew.tq-group.com>
Message-ID: <87frzyprhq.fsf@geanix.com>

Gregor Herburger <gregor.herburger at ew.tq-group.com> writes:

> Currently the i2c-imx driver assumes that for bus recovery the i2c pins
> can be reconfigured as gpio via pinctrl.
>
> But bus recovery can also be done with a gpio electrically connected to
> i2c scl.
>
> Modify i2c_imx_init_recovery_info to allow bus recovery on platforms
> without pinctrl. In this case only use scl-gpio and
> i2c_generic_scl_recovery.

Why not move to use the generic GPIO recovery instead?  Will something
like this be able to cover at least the same scenarios as your change?

>From 7e432496bae8c7ac35c21504bc1cd03f1dfef97f Mon Sep 17 00:00:00 2001
Message-ID: <7e432496bae8c7ac35c21504bc1cd03f1dfef97f.1702971634.git.esben at geanix.com>
From: Esben Haabendal <esben at geanix.com>
Date: Tue, 25 May 2021 11:25:44 +0200
Subject: [PATCH] i2c: imx: move to generic GPIO recovery

Starting with
commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
GPIO bus recovery is supported by the I2C core, so we can remove the
driver implementation and use that one instead.

As a nice side-effect, pinctrl becomes optional, allowing bus recovery on
LS1021A, which does not have such luxury, but can be wired up to use extra
fixed GPIO pins.

Signed-off-by: Esben Haabendal <esben at geanix.com>
---
 drivers/i2c/busses/i2c-imx.c | 62 ++++--------------------------------
 1 file changed, 7 insertions(+), 55 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 1775a79aeba2..824d8bbb9be5 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -212,10 +212,6 @@ struct imx_i2c_struct {
 	const struct imx_i2c_hwdata	*hwdata;
 	struct i2c_bus_recovery_info rinfo;
 
-	struct pinctrl *pinctrl;
-	struct pinctrl_state *pinctrl_pins_default;
-	struct pinctrl_state *pinctrl_pins_gpio;
-
 	struct imx_i2c_dma	*dma;
 	struct i2c_client	*slave;
 	enum i2c_slave_event last_slave_event;
@@ -1357,24 +1353,6 @@ static int i2c_imx_xfer_atomic(struct i2c_adapter *adapter,
 	return result;
 }
 
-static void i2c_imx_prepare_recovery(struct i2c_adapter *adap)
-{
-	struct imx_i2c_struct *i2c_imx;
-
-	i2c_imx = container_of(adap, struct imx_i2c_struct, adapter);
-
-	pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_gpio);
-}
-
-static void i2c_imx_unprepare_recovery(struct i2c_adapter *adap)
-{
-	struct imx_i2c_struct *i2c_imx;
-
-	i2c_imx = container_of(adap, struct imx_i2c_struct, adapter);
-
-	pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_default);
-}
-
 /*
  * We switch SCL and SDA to their GPIO function and do some bitbanging
  * for bus recovery. These alternative pinmux settings can be
@@ -1385,43 +1363,17 @@ static void i2c_imx_unprepare_recovery(struct i2c_adapter *adap)
 static int i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
 		struct platform_device *pdev)
 {
-	struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
+	struct i2c_bus_recovery_info *bri = &i2c_imx->rinfo;
 
-	i2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
-	if (!i2c_imx->pinctrl) {
-		dev_info(&pdev->dev, "pinctrl unavailable, bus recovery not supported\n");
+	bri->pinctrl = devm_pinctrl_get(&pdev->dev);
+	if (PTR_ERR(bri->pinctrl) == -ENODEV) {
+		bri->pinctrl = NULL;
 		return 0;
 	}
-	if (IS_ERR(i2c_imx->pinctrl)) {
-		dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
-		return PTR_ERR(i2c_imx->pinctrl);
-	}
-
-	i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
-			PINCTRL_STATE_DEFAULT);
-	i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
-			"gpio");
-	rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
-	rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
-
-	if (PTR_ERR(rinfo->sda_gpiod) == -EPROBE_DEFER ||
-	    PTR_ERR(rinfo->scl_gpiod) == -EPROBE_DEFER) {
-		return -EPROBE_DEFER;
-	} else if (IS_ERR(rinfo->sda_gpiod) ||
-		   IS_ERR(rinfo->scl_gpiod) ||
-		   IS_ERR(i2c_imx->pinctrl_pins_default) ||
-		   IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
-		dev_dbg(&pdev->dev, "recovery information incomplete\n");
-		return 0;
-	}
-
-	dev_dbg(&pdev->dev, "using scl%s for recovery\n",
-		rinfo->sda_gpiod ? ",sda" : "");
+	if (IS_ERR(bri->pinctrl))
+		return PTR_ERR(bri->pinctrl);
 
-	rinfo->prepare_recovery = i2c_imx_prepare_recovery;
-	rinfo->unprepare_recovery = i2c_imx_unprepare_recovery;
-	rinfo->recover_bus = i2c_generic_scl_recovery;
-	i2c_imx->adapter.bus_recovery_info = rinfo;
+	i2c_imx->adapter.bus_recovery_info = bri;
 
 	return 0;
 }
-- 
2.43.0


/Esben


From miquel.raynal at bootlin.com  Mon Dec 18 23:55:17 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Tue, 19 Dec 2023 08:55:17 +0100
Subject: [PATCH 4/4] nvmem: layouts: add U-Boot env layout
In-Reply-To: <13bc621c-5fcb-4710-912c-06e3e80d7337@gmail.com>
References: <20231218133722.16150-1-zajec5@gmail.com>
	<20231218133722.16150-4-zajec5@gmail.com>
	<20231218152116.59d59bad@xps-13>
	<13bc621c-5fcb-4710-912c-06e3e80d7337@gmail.com>
Message-ID: <20231219085517.4b6ec4fc@xps-13>

Hi Rafa?,

zajec5 at gmail.com wrote on Mon, 18 Dec 2023 23:10:20 +0100:

> On 18.12.2023 15:21, Miquel Raynal wrote:
> > Hi Rafa?,
> > 
> > zajec5 at gmail.com wrote on Mon, 18 Dec 2023 14:37:22 +0100:
> >   
> >> From: Rafa? Mi?ecki <rafal at milecki.pl>
> >>
> >> This patch moves all generic (NVMEM devices independent) code from NVMEM
> >> device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
> >> code on top of it.
> >>
> >> Thanks to proper layout it's possible to support U-Boot env data stored
> >> on any kind of NVMEM device.
> >>
> >> For backward compatibility with old DT bindings we need to keep old
> >> NVMEM device driver functional. To avoid code duplication a parsing
> >> function is exported and reused in it.
> >>
> >> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> >> ---  
> > 
> > I have a couple of comments about the original driver which gets
> > copy-pasted in the new layout driver, maybe you could clean these
> > (the memory leak should be fixed before the migration so it can be
> > backported easily, the others are just style so it can be done after, I
> > don't mind).
> > 
> > ...
> >   
> >> +int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
> >> +		     enum u_boot_env_format format)
> >> +{
> >> +	size_t crc32_data_offset;
> >> +	size_t crc32_data_len;
> >> +	size_t crc32_offset;
> >> +	size_t data_offset;
> >> +	size_t data_len;
> >> +	size_t dev_size;
> >> +	uint32_t crc32;
> >> +	uint32_t calc;
> >> +	uint8_t *buf;
> >> +	int bytes;
> >> +	int err;
> >> +
> >> +	dev_size = nvmem_dev_size(nvmem);
> >> +
> >> +	buf = kcalloc(1, dev_size, GFP_KERNEL);  
> > 
> > Out of curiosity, why kcalloc(1,...) rather than kzalloc() ?  
> 
> I used kcalloc() initially as I didn't need buffer to be zeroed.

I think kcalloc() initializes the memory to zero.
https://elixir.bootlin.com/linux/latest/source/include/linux/slab.h#L659

If you don't need it you can switch to kmalloc() instead, I don't mind,
but kcalloc() is meant to be used with arrays, I don't see the point of
using kcalloc() in this case.

> 
> I see that memory-allocation.rst however says:
>  > And, to be on the safe side it's best to use routines that set memory to zero, like kzalloc().  
> 
> It's probably close to zero cost to zero that buffer so it could be kzalloc().
> 
> 
> >> +	if (!buf) {
> >> +		err = -ENOMEM;
> >> +		goto err_out;  
> > 
> > We could directly return ENOMEM here I guess.
> >   
> >> +	}
> >> +
> >> +	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
> >> +	if (bytes < 0)
> >> +		return bytes;
> >> +	else if (bytes != dev_size)
> >> +		return -EIO;  
> > 
> > Don't we need to free buf in the above cases?
> >   
> >> +	switch (format) {
> >> +	case U_BOOT_FORMAT_SINGLE:
> >> +		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
> >> +		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
> >> +		data_offset = offsetof(struct u_boot_env_image_single, data);
> >> +		break;
> >> +	case U_BOOT_FORMAT_REDUNDANT:
> >> +		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
> >> +		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
> >> +		data_offset = offsetof(struct u_boot_env_image_redundant, data);
> >> +		break;
> >> +	case U_BOOT_FORMAT_BROADCOM:
> >> +		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
> >> +		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
> >> +		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
> >> +		break;
> >> +	}
> >> +	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));  
> > 
> > Looks a bit convoluted, any chances we can use intermediate variables
> > to help decipher this?
> >   
> >> +	crc32_data_len = dev_size - crc32_data_offset;
> >> +	data_len = dev_size - data_offset;
> >> +
> >> +	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
> >> +	if (calc != crc32) {
> >> +		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
> >> +		err = -EINVAL;
> >> +		goto err_kfree;
> >> +	}
> >> +
> >> +	buf[dev_size - 1] = '\0';
> >> +	err = u_boot_env_parse_cells(dev, nvmem, buf, data_offset, data_len);
> >> +	if (err)
> >> +		dev_err(dev, "Failed to add cells: %d\n", err);  
> > 
> > Please drop this error message, the only reason for which the function
> > call would fail is apparently an ENOMEM case.
> >   
> >> +
> >> +err_kfree:
> >> +	kfree(buf);
> >> +err_out:
> >> +	return err;
> >> +}
> >> +EXPORT_SYMBOL_GPL(u_boot_env_parse);
> >> +
> >> +static int u_boot_env_add_cells(struct device *dev, struct nvmem_device *nvmem)
> >> +{
> >> +	const struct of_device_id *match;
> >> +	struct device_node *layout_np;
> >> +	enum u_boot_env_format format;
> >> +
> >> +	layout_np = of_nvmem_layout_get_container(nvmem);
> >> +	if (!layout_np)
> >> +		return -ENOENT;
> >> +
> >> +	match = of_match_node(u_boot_env_of_match_table, layout_np);
> >> +	if (!match)
> >> +		return -ENOENT;
> >> +
> >> +	format = (uintptr_t)match->data;  
> > 
> > In the core there is currently an unused helper called
> > nvmem_layout_get_match_data() which does that. I think the original
> > intent of this function was to be used in this driver, so depending on
> > your preference, can you please either use it or remove it?  
> 
> The problem is that nvmem_layout_get_match_data() uses:
> layout->dev.driver

I'm surprised .driver is unset. Well anyway, please either fix the core
helper and use it or drop the core helper, because we have no user for
it otherwise?

> It doesn't work with layouts driver (since refactoring?) as driver is
> NULL. That results in NULL pointer dereference when trying to reach
> of_match_table.
> 
> That is why I used u_boot_env_of_match_table directly.
> 
> If you know how to fix nvmem_layout_get_match_data() that would be
> great. Do we need driver_register() somewhere in NVMEM core?
> 


Thanks,
Miqu?l


From peterx at redhat.com  Mon Dec 18 23:55:25 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:25 +0800
Subject: [PATCH 00/13] mm/gup: Unify hugetlb, part 2
Message-ID: <20231219075538.414708-1-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

This is v1 of the series.  The series removes the hugetlb slow gup path
after a previous refactor work [1], so that slow gup now uses the exact
same path to handle all kinds of memory including hugetlb.

It's based on latest mm-unstalbe (c13bdc82ada9).

RFC->v1 (use old verion's patch index):
- Fix build for !THP and/or !HUGETLB
- Fix a bug in the hugepd path that can cause a loop
- patch 3:
  - Rename to "Make HPAGE_PXD_* macros visible even if !THP" [Christoph, MikeR]
- patch 5:
  - Posted separately as a devmap bugfix
- patch 6:
  - Add a comment above gup_huge_pd() explaining the file folio writeback
    issue, with references when anyone would extend hugepd to other types
    of file memories [Christoph]
- patch 7:
  - Keep parameter name as "page" in record_subpages(), modify the
    commit message by removing any assumption on head page. [Matthew]
- patch 12:
  - Rename to: "mm/gup: handle hugetlb in the generic follow_page_mask
    code" [Christoph]
- Added patch:
  - "mm/Kconfig: CONFIG_PGTABLE_HAS_HUGE_LEAVES", this helps to fix build
    for !THP and/or !HUGETLB
- Added patch
  - "mm/gup: Cache *pudp in follow_pud_mask()", as suggested by Christoph

For the long term, this is one small step towards merging hugetlb specific
codes into generic mm paths.  From that POV, this series removes one
reference to huge_pte_offset() out of many others.

To make it work, the generic code will need to at least understand hugepd,
which is already done like so in fast-gup.  Fortunately it seems that's the
only major thing I need to teach slow GUP to share the common path for now
besides normal huge PxD entries.  Non-gup can be more challenging, but
that's a question for later.

There's one major difference for slow-gup on cont_pte / cont_pmd handling,
currently supported on three architectures (aarch64, riscv, ppc).  Before
the series, slow gup will be able to recognize cont entries with the help
of huge_pte_offset().  Now it's gone but still working, by looking up
pgtable entries one by one.  It's not ideal, but hopefully this change
should not affect yet on major workloads.  There's some more information in
the commit message of the last patch.  If this would be a concern, we can
consider teaching slow gup to recognize cont pte/pmd entries, and that
should recover the lost performance.  But I doubt its necessity for now, so
I kept it as simple as it can be.

Test Done
=========

This v1 went through the normal GUP smoke tests over different memory
types on archs (using VM instances): x86_64, aarch64, ppc64le.  For
aarch64, tested over 64KB cont_pte huge pages.  For ppc64le, tested over
16MB hugepd entries (Power8 hash MMU on 4K base page size).

Patch layout
=============

Patch 1-7:    Preparation works, or cleanups in relevant code paths
Patch 8-12:   Teach slow gup with all kinds of huge entries (pXd, hugepd)
Patch 13:     Drop hugetlb_follow_page_mask()

More information can be found in the commit messages of each patch.  Any
comment will be welcomed.  Thanks.

[1] https://lore.kernel.org/all/20230628215310.73782-1-peterx at redhat.com

Peter Xu (13):
  mm/Kconfig: CONFIG_PGTABLE_HAS_HUGE_LEAVES
  mm/hugetlb: Declare hugetlbfs_pagecache_present() non-static
  mm: Provide generic pmd_thp_or_huge()
  mm: Make HPAGE_PXD_* macros even if !THP
  mm: Introduce vma_pgtable_walk_{begin|end}()
  mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
  mm/gup: Refactor record_subpages() to find 1st small page
  mm/gup: Handle hugetlb for no_page_table()
  mm/gup: Cache *pudp in follow_pud_mask()
  mm/gup: Handle huge pud for follow_pud_mask()
  mm/gup: Handle huge pmd for follow_pmd_mask()
  mm/gup: Handle hugepd for follow_page()
  mm/gup: Handle hugetlb in the generic follow_page_mask code

 include/linux/huge_mm.h |  25 +--
 include/linux/hugetlb.h |  16 +-
 include/linux/mm.h      |   3 +
 include/linux/pgtable.h |   4 +
 mm/Kconfig              |   3 +
 mm/gup.c                | 362 ++++++++++++++++++++++++++++++++--------
 mm/huge_memory.c        | 133 +--------------
 mm/hugetlb.c            |  75 +--------
 mm/internal.h           |   7 +-
 mm/memory.c             |  12 ++
 10 files changed, 342 insertions(+), 298 deletions(-)

-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:26 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:26 +0800
Subject: [PATCH 01/13] mm/Kconfig: CONFIG_PGTABLE_HAS_HUGE_LEAVES
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-2-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

Introduce a config option that will be selected as long as huge leaves are
involved in pgtable (thp or hugetlbfs).  It would be useful to mark any
code with this new config that can process either hugetlb or thp pages in
any level that is higher than pte level.

Signed-off-by: Peter Xu <peterx at redhat.com>
---
 mm/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 8f8b02e9c136..4ca97d959323 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -904,6 +904,9 @@ config READ_ONLY_THP_FOR_FS
 
 endif # TRANSPARENT_HUGEPAGE
 
+config PGTABLE_HAS_HUGE_LEAVES
+	def_bool TRANSPARENT_HUGEPAGE || HUGETLB_PAGE
+
 #
 # UP and nommu archs use km based percpu allocator
 #
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:27 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:27 +0800
Subject: [PATCH 02/13] mm/hugetlb: Declare hugetlbfs_pagecache_present() non-static
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-3-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

It will be used outside hugetlb.c soon.

Signed-off-by: Peter Xu <peterx at redhat.com>
---
 include/linux/hugetlb.h | 9 +++++++++
 mm/hugetlb.c            | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 236ec7b63c54..f8c5c174c8a6 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -174,6 +174,9 @@ u32 hugetlb_fault_mutex_hash(struct address_space *mapping, pgoff_t idx);
 
 pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma,
 		      unsigned long addr, pud_t *pud);
+bool hugetlbfs_pagecache_present(struct hstate *h,
+				 struct vm_area_struct *vma,
+				 unsigned long address);
 
 struct address_space *hugetlb_page_mapping_lock_write(struct page *hpage);
 
@@ -1221,6 +1224,12 @@ static inline void hugetlb_register_node(struct node *node)
 static inline void hugetlb_unregister_node(struct node *node)
 {
 }
+
+static inline bool hugetlbfs_pagecache_present(
+    struct hstate *h, struct vm_area_struct *vma, unsigned long address)
+{
+	return false;
+}
 #endif	/* CONFIG_HUGETLB_PAGE */
 
 static inline spinlock_t *huge_pte_lock(struct hstate *h,
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6feb3e0630d1..29705e5c6f40 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6018,8 +6018,8 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma,
 /*
  * Return whether there is a pagecache page to back given address within VMA.
  */
-static bool hugetlbfs_pagecache_present(struct hstate *h,
-			struct vm_area_struct *vma, unsigned long address)
+bool hugetlbfs_pagecache_present(struct hstate *h,
+				 struct vm_area_struct *vma, unsigned long address)
 {
 	struct address_space *mapping = vma->vm_file->f_mapping;
 	pgoff_t idx = linear_page_index(vma, address);
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:28 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:28 +0800
Subject: [PATCH 03/13] mm: Provide generic pmd_thp_or_huge()
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-4-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

ARM defines pmd_thp_or_huge(), detecting either a THP or a huge PMD.  It
can be a helpful helper if we want to merge more THP and hugetlb code
paths.  Make it a generic default implementation, only exist when
CONFIG_MMU.  Arch can overwrite it by defining its own version.

For example, ARM's pgtable-2level.h defines it to always return false.

Keep the macro declared with all config, it should be optimized to a false
anyway if !THP && !HUGETLB.

Signed-off-by: Peter Xu <peterx at redhat.com>
---
 include/linux/pgtable.h | 4 ++++
 mm/gup.c                | 3 +--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index af7639c3b0a3..6f2fa1977b8a 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1355,6 +1355,10 @@ static inline int pmd_write(pmd_t pmd)
 #endif /* pmd_write */
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
+#ifndef pmd_thp_or_huge
+#define pmd_thp_or_huge(pmd)	(pmd_huge(pmd) || pmd_trans_huge(pmd))
+#endif
+
 #ifndef pud_write
 static inline int pud_write(pud_t pud)
 {
diff --git a/mm/gup.c b/mm/gup.c
index 0a5f0e91bfec..efc9847e58fb 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -3004,8 +3004,7 @@ static int gup_pmd_range(pud_t *pudp, pud_t pud, unsigned long addr, unsigned lo
 		if (!pmd_present(pmd))
 			return 0;
 
-		if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
-			     pmd_devmap(pmd))) {
+		if (unlikely(pmd_thp_or_huge(pmd) || pmd_devmap(pmd))) {
 			/* See gup_pte_range() */
 			if (pmd_protnone(pmd))
 				return 0;
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:29 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:29 +0800
Subject: [PATCH 04/13] mm: Make HPAGE_PXD_* macros even if !THP
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-5-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

These macros can be helpful when we plan to merge hugetlb code into generic
code.  Move them out and define them even if !THP.

We actually already defined HPAGE_PMD_NR for other reasons even if !THP.
Reorganize these macros.

Reviewed-by: Christoph Hellwig <hch at infradead.org>
Signed-off-by: Peter Xu <peterx at redhat.com>
---
 include/linux/huge_mm.h | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index fa7a38a30fc6..d335130e145f 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -64,9 +64,6 @@ ssize_t single_hugepage_flag_show(struct kobject *kobj,
 				  enum transparent_hugepage_flag flag);
 extern struct kobj_attribute shmem_enabled_attr;
 
-#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
-#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
-
 /*
  * Mask of all large folio orders supported for anonymous THP; all orders up to
  * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
@@ -87,14 +84,19 @@ extern struct kobj_attribute shmem_enabled_attr;
 #define thp_vma_allowable_order(vma, vm_flags, smaps, in_pf, enforce_sysfs, order) \
 	(!!thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf, enforce_sysfs, BIT(order)))
 
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 #define HPAGE_PMD_SHIFT PMD_SHIFT
 #define HPAGE_PMD_SIZE	((1UL) << HPAGE_PMD_SHIFT)
 #define HPAGE_PMD_MASK	(~(HPAGE_PMD_SIZE - 1))
+#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
+#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
 
 #define HPAGE_PUD_SHIFT PUD_SHIFT
 #define HPAGE_PUD_SIZE	((1UL) << HPAGE_PUD_SHIFT)
 #define HPAGE_PUD_MASK	(~(HPAGE_PUD_SIZE - 1))
+#define HPAGE_PUD_ORDER (HPAGE_PUD_SHIFT-PAGE_SHIFT)
+#define HPAGE_PUD_NR (1<<HPAGE_PUD_ORDER)
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 
 extern unsigned long transparent_hugepage_flags;
 extern unsigned long huge_anon_orders_always;
@@ -378,13 +380,6 @@ static inline bool thp_migration_supported(void)
 }
 
 #else /* CONFIG_TRANSPARENT_HUGEPAGE */
-#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
-#define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
-#define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
-
-#define HPAGE_PUD_SHIFT ({ BUILD_BUG(); 0; })
-#define HPAGE_PUD_MASK ({ BUILD_BUG(); 0; })
-#define HPAGE_PUD_SIZE ({ BUILD_BUG(); 0; })
 
 static inline bool folio_test_pmd_mappable(struct folio *folio)
 {
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:30 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:30 +0800
Subject: [PATCH 05/13] mm: Introduce vma_pgtable_walk_{begin|end}()
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-6-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

Introduce per-vma begin()/end() helpers for pgtable walks.  This is a
preparation work to merge hugetlb pgtable walkers with generic mm.

The helpers need to be called before and after a pgtable walk, will start
to be needed if the pgtable walker code supports hugetlb pages.  It's a
hook point for any type of VMA, but for now only hugetlb uses it to
stablize the pgtable pages from getting away (due to possible pmd
unsharing).

Reviewed-by: Christoph Hellwig <hch at infradead.org>
Signed-off-by: Peter Xu <peterx at redhat.com>
---
 include/linux/mm.h |  3 +++
 mm/memory.c        | 12 ++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index b72bf25a45cf..85e43775824b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -4181,4 +4181,7 @@ static inline bool pfn_is_unaccepted_memory(unsigned long pfn)
 	return range_contains_unaccepted_memory(paddr, paddr + PAGE_SIZE);
 }
 
+void vma_pgtable_walk_begin(struct vm_area_struct *vma);
+void vma_pgtable_walk_end(struct vm_area_struct *vma);
+
 #endif /* _LINUX_MM_H */
diff --git a/mm/memory.c b/mm/memory.c
index 1795aba53cf5..9ac6a9db971e 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -6270,3 +6270,15 @@ void ptlock_free(struct ptdesc *ptdesc)
 	kmem_cache_free(page_ptl_cachep, ptdesc->ptl);
 }
 #endif
+
+void vma_pgtable_walk_begin(struct vm_area_struct *vma)
+{
+	if (is_vm_hugetlb_page(vma))
+		hugetlb_vma_lock_read(vma);
+}
+
+void vma_pgtable_walk_end(struct vm_area_struct *vma)
+{
+	if (is_vm_hugetlb_page(vma))
+		hugetlb_vma_unlock_read(vma);
+}
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:31 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:31 +0800
Subject: [PATCH 06/13] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-7-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

Hugepd format for GUP is only used in PowerPC with hugetlbfs.  There are
some kernel usage of hugepd (can refer to hugepd_populate_kernel() for
PPC_8XX), however those pages are not candidates for GUP.

Commit a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to
file-backed mappings") added a check to fail gup-fast if there's potential
risk of violating GUP over writeback file systems.  That should never apply
to hugepd.  Considering that hugepd is an old format (and even
software-only), there's no plan to extend hugepd into other file typed
memories that is prone to the same issue.

Drop that check, not only because it'll never be true for hugepd per any
known plan, but also it paves way for reusing the function outside
fast-gup.

To make sure we'll still remember this issue just in case hugepd will be
extended to support non-hugetlbfs memories, add a rich comment above
gup_huge_pd(), explaining the issue with proper references.

Cc: Christoph Hellwig <hch at infradead.org>
Cc: Lorenzo Stoakes <lstoakes at gmail.com>
Cc: Michael Ellerman <mpe at ellerman.id.au>
Cc: linuxppc-dev at lists.ozlabs.org
Signed-off-by: Peter Xu <peterx at redhat.com>
---
 mm/gup.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index efc9847e58fb..bb5b7134f10b 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2820,11 +2820,6 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr,
 		return 0;
 	}
 
-	if (!folio_fast_pin_allowed(folio, flags)) {
-		gup_put_folio(folio, refs, flags);
-		return 0;
-	}
-
 	if (!pte_write(pte) && gup_must_unshare(NULL, flags, &folio->page)) {
 		gup_put_folio(folio, refs, flags);
 		return 0;
@@ -2835,6 +2830,14 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr,
 	return 1;
 }
 
+/*
+ * NOTE: currently GUP for a hugepd is only possible on hugetlbfs file
+ * systems on Power, which does not have issue with folio writeback against
+ * GUP updates.  When hugepd will be extended to support non-hugetlbfs or
+ * even anonymous memory, we need to do extra check as what we do with most
+ * of the other folios. See writable_file_mapping_allowed() and
+ * folio_fast_pin_allowed() for more information.
+ */
 static int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
 		unsigned int pdshift, unsigned long end, unsigned int flags,
 		struct page **pages, int *nr)
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:32 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:32 +0800
Subject: [PATCH 07/13] mm/gup: Refactor record_subpages() to find 1st small page
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-8-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

All the fast-gup functions take a tail page to operate, always need to do
page mask calculations before feeding that into record_subpages().

Merge that logic into record_subpages(), so that it will do the nth_page()
calculation.

Signed-off-by: Peter Xu <peterx at redhat.com>
---
 mm/gup.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index bb5b7134f10b..82d28d517d0d 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2767,13 +2767,16 @@ static int __gup_device_huge_pud(pud_t pud, pud_t *pudp, unsigned long addr,
 }
 #endif
 
-static int record_subpages(struct page *page, unsigned long addr,
-			   unsigned long end, struct page **pages)
+static int record_subpages(struct page *page, unsigned long sz,
+			   unsigned long addr, unsigned long end,
+			   struct page **pages)
 {
+	struct page *start_page;
 	int nr;
 
+	start_page = nth_page(page, (addr & (sz - 1)) >> PAGE_SHIFT);
 	for (nr = 0; addr != end; nr++, addr += PAGE_SIZE)
-		pages[nr] = nth_page(page, nr);
+		pages[nr] = nth_page(start_page, nr);
 
 	return nr;
 }
@@ -2808,8 +2811,8 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr,
 	/* hugepages are never "special" */
 	VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
 
-	page = nth_page(pte_page(pte), (addr & (sz - 1)) >> PAGE_SHIFT);
-	refs = record_subpages(page, addr, end, pages + *nr);
+	page = pte_page(pte);
+	refs = record_subpages(page, sz, addr, end, pages + *nr);
 
 	folio = try_grab_folio(page, refs, flags);
 	if (!folio)
@@ -2882,8 +2885,8 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
 					     pages, nr);
 	}
 
-	page = nth_page(pmd_page(orig), (addr & ~PMD_MASK) >> PAGE_SHIFT);
-	refs = record_subpages(page, addr, end, pages + *nr);
+	page = pmd_page(orig);
+	refs = record_subpages(page, PMD_SIZE, addr, end, pages + *nr);
 
 	folio = try_grab_folio(page, refs, flags);
 	if (!folio)
@@ -2926,8 +2929,8 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
 					     pages, nr);
 	}
 
-	page = nth_page(pud_page(orig), (addr & ~PUD_MASK) >> PAGE_SHIFT);
-	refs = record_subpages(page, addr, end, pages + *nr);
+	page = pud_page(orig);
+	refs = record_subpages(page, PUD_SIZE, addr, end, pages + *nr);
 
 	folio = try_grab_folio(page, refs, flags);
 	if (!folio)
@@ -2966,8 +2969,8 @@ static int gup_huge_pgd(pgd_t orig, pgd_t *pgdp, unsigned long addr,
 
 	BUILD_BUG_ON(pgd_devmap(orig));
 
-	page = nth_page(pgd_page(orig), (addr & ~PGDIR_MASK) >> PAGE_SHIFT);
-	refs = record_subpages(page, addr, end, pages + *nr);
+	page = pgd_page(orig);
+	refs = record_subpages(page, PGDIR_SIZE, addr, end, pages + *nr);
 
 	folio = try_grab_folio(page, refs, flags);
 	if (!folio)
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:33 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:33 +0800
Subject: [PATCH 08/13] mm/gup: Handle hugetlb for no_page_table()
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-9-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

no_page_table() is not yet used for hugetlb code paths. Make it prepared.

The major difference here is hugetlb will return -EFAULT as long as page
cache does not exist, even if VM_SHARED.  See hugetlb_follow_page_mask().

Pass "address" into no_page_table() too, as hugetlb will need it.

Reviewed-by: Christoph Hellwig <hch at infradead.org>
Signed-off-by: Peter Xu <peterx at redhat.com>
---
 mm/gup.c | 44 ++++++++++++++++++++++++++------------------
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 82d28d517d0d..6c0d82fa8cc7 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -501,19 +501,27 @@ static inline void mm_set_has_pinned_flag(unsigned long *mm_flags)
 
 #ifdef CONFIG_MMU
 static struct page *no_page_table(struct vm_area_struct *vma,
-		unsigned int flags)
+				  unsigned int flags, unsigned long address)
 {
+	if (!(flags & FOLL_DUMP))
+		return NULL;
+
 	/*
-	 * When core dumping an enormous anonymous area that nobody
-	 * has touched so far, we don't want to allocate unnecessary pages or
+	 * When core dumping, we don't want to allocate unnecessary pages or
 	 * page tables.  Return error instead of NULL to skip handle_mm_fault,
 	 * then get_dump_page() will return NULL to leave a hole in the dump.
 	 * But we can only make this optimization where a hole would surely
 	 * be zero-filled if handle_mm_fault() actually did handle it.
 	 */
-	if ((flags & FOLL_DUMP) &&
-			(vma_is_anonymous(vma) || !vma->vm_ops->fault))
+	if (is_vm_hugetlb_page(vma)) {
+		struct hstate *h = hstate_vma(vma);
+
+		if (!hugetlbfs_pagecache_present(h, vma, address))
+			return ERR_PTR(-EFAULT);
+	} else if ((vma_is_anonymous(vma) || !vma->vm_ops->fault)) {
 		return ERR_PTR(-EFAULT);
+	}
+
 	return NULL;
 }
 
@@ -593,7 +601,7 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
 
 	ptep = pte_offset_map_lock(mm, pmd, address, &ptl);
 	if (!ptep)
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 	pte = ptep_get(ptep);
 	if (!pte_present(pte))
 		goto no_page;
@@ -685,7 +693,7 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
 	pte_unmap_unlock(ptep, ptl);
 	if (!pte_none(pte))
 		return NULL;
-	return no_page_table(vma, flags);
+	return no_page_table(vma, flags, address);
 }
 
 static struct page *follow_pmd_mask(struct vm_area_struct *vma,
@@ -701,27 +709,27 @@ static struct page *follow_pmd_mask(struct vm_area_struct *vma,
 	pmd = pmd_offset(pudp, address);
 	pmdval = pmdp_get_lockless(pmd);
 	if (pmd_none(pmdval))
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 	if (!pmd_present(pmdval))
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 	if (pmd_devmap(pmdval)) {
 		ptl = pmd_lock(mm, pmd);
 		page = follow_devmap_pmd(vma, address, pmd, flags, &ctx->pgmap);
 		spin_unlock(ptl);
 		if (page)
 			return page;
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 	}
 	if (likely(!pmd_trans_huge(pmdval)))
 		return follow_page_pte(vma, address, pmd, flags, &ctx->pgmap);
 
 	if (pmd_protnone(pmdval) && !gup_can_follow_protnone(vma, flags))
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 
 	ptl = pmd_lock(mm, pmd);
 	if (unlikely(!pmd_present(*pmd))) {
 		spin_unlock(ptl);
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 	}
 	if (unlikely(!pmd_trans_huge(*pmd))) {
 		spin_unlock(ptl);
@@ -752,17 +760,17 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma,
 
 	pud = pud_offset(p4dp, address);
 	if (pud_none(*pud))
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 	if (pud_devmap(*pud)) {
 		ptl = pud_lock(mm, pud);
 		page = follow_devmap_pud(vma, address, pud, flags, &ctx->pgmap);
 		spin_unlock(ptl);
 		if (page)
 			return page;
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 	}
 	if (unlikely(pud_bad(*pud)))
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 
 	return follow_pmd_mask(vma, address, pud, flags, ctx);
 }
@@ -776,10 +784,10 @@ static struct page *follow_p4d_mask(struct vm_area_struct *vma,
 
 	p4d = p4d_offset(pgdp, address);
 	if (p4d_none(*p4d))
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 	BUILD_BUG_ON(p4d_huge(*p4d));
 	if (unlikely(p4d_bad(*p4d)))
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 
 	return follow_pud_mask(vma, address, p4d, flags, ctx);
 }
@@ -829,7 +837,7 @@ static struct page *follow_page_mask(struct vm_area_struct *vma,
 	pgd = pgd_offset(mm, address);
 
 	if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
-		return no_page_table(vma, flags);
+		return no_page_table(vma, flags, address);
 
 	return follow_p4d_mask(vma, address, pgd, flags, ctx);
 }
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:34 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:34 +0800
Subject: [PATCH 09/13] mm/gup: Cache *pudp in follow_pud_mask()
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-10-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

Introduce "pud_t pud" in the function, so the code won't dereference *pudp
multiple time.  Not only because that looks less straightforward, but also
because if the dereference really happened, it's not clear whether there
can be race to see different *pudp values if it's being modified at the
same time.

Signed-off-by: Peter Xu <peterx at redhat.com>
---
 mm/gup.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 6c0d82fa8cc7..97e87b7a15c3 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -753,26 +753,27 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma,
 				    unsigned int flags,
 				    struct follow_page_context *ctx)
 {
-	pud_t *pud;
+	pud_t *pudp, pud;
 	spinlock_t *ptl;
 	struct page *page;
 	struct mm_struct *mm = vma->vm_mm;
 
-	pud = pud_offset(p4dp, address);
-	if (pud_none(*pud))
+	pudp = pud_offset(p4dp, address);
+	pud = *pudp;
+	if (pud_none(pud))
 		return no_page_table(vma, flags, address);
-	if (pud_devmap(*pud)) {
-		ptl = pud_lock(mm, pud);
-		page = follow_devmap_pud(vma, address, pud, flags, &ctx->pgmap);
+	if (pud_devmap(pud)) {
+		ptl = pud_lock(mm, pudp);
+		page = follow_devmap_pud(vma, address, pudp, flags, &ctx->pgmap);
 		spin_unlock(ptl);
 		if (page)
 			return page;
 		return no_page_table(vma, flags, address);
 	}
-	if (unlikely(pud_bad(*pud)))
+	if (unlikely(pud_bad(pud)))
 		return no_page_table(vma, flags, address);
 
-	return follow_pmd_mask(vma, address, pud, flags, ctx);
+	return follow_pmd_mask(vma, address, pudp, flags, ctx);
 }
 
 static struct page *follow_p4d_mask(struct vm_area_struct *vma,
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:35 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:35 +0800
Subject: [PATCH 10/13] mm/gup: Handle huge pud for follow_pud_mask()
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-11-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

Teach follow_pud_mask() to be able to handle normal PUD pages like hugetlb.

Rename follow_devmap_pud() to follow_huge_pud() so that it can process
either huge devmap or hugetlb. Move it out of TRANSPARENT_HUGEPAGE_PUD and
and huge_memory.c (which relies on CONFIG_THP).

In the new follow_huge_pud(), taking care of possible CoR for hugetlb if
necessary.  touch_pud() needs to be moved out of huge_memory.c to be
accessable from gup.c even if !THP.

Since at it, optimize the non-present check by adding a pud_present() early
check before taking the pgtable lock, failing the follow_page() early if
PUD is not present: that is required by both devmap or hugetlb.  Use
pud_huge() to also cover the pud_devmap() case.

One more trivial thing to mention is, introduce "pud_t pud" in the code
paths along the way, so the code doesn't dereference *pudp multiple time.
Not only because that looks less straightforward, but also because if the
dereference really happened, it's not clear whether there can be race to
see different *pudp values when it's being modified at the same time.

Setting ctx->page_mask properly for a PUD entry.  As a side effect, this
patch should also be able to optimize devmap GUP on PUD to be able to jump
over the whole PUD range, but not yet verified.  Hugetlb already can do so
prior to this patch.

Signed-off-by: Peter Xu <peterx at redhat.com>
---
 include/linux/huge_mm.h |  8 -----
 mm/gup.c                | 70 +++++++++++++++++++++++++++++++++++++++--
 mm/huge_memory.c        | 47 ++-------------------------
 mm/internal.h           |  2 ++
 4 files changed, 71 insertions(+), 56 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index d335130e145f..80f181d76f94 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -346,8 +346,6 @@ static inline bool folio_test_pmd_mappable(struct folio *folio)
 
 struct page *follow_devmap_pmd(struct vm_area_struct *vma, unsigned long addr,
 		pmd_t *pmd, int flags, struct dev_pagemap **pgmap);
-struct page *follow_devmap_pud(struct vm_area_struct *vma, unsigned long addr,
-		pud_t *pud, int flags, struct dev_pagemap **pgmap);
 
 vm_fault_t do_huge_pmd_numa_page(struct vm_fault *vmf);
 
@@ -503,12 +501,6 @@ static inline struct page *follow_devmap_pmd(struct vm_area_struct *vma,
 	return NULL;
 }
 
-static inline struct page *follow_devmap_pud(struct vm_area_struct *vma,
-	unsigned long addr, pud_t *pud, int flags, struct dev_pagemap **pgmap)
-{
-	return NULL;
-}
-
 static inline bool thp_migration_supported(void)
 {
 	return false;
diff --git a/mm/gup.c b/mm/gup.c
index 97e87b7a15c3..5b14f91d2f6b 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -525,6 +525,70 @@ static struct page *no_page_table(struct vm_area_struct *vma,
 	return NULL;
 }
 
+#ifdef CONFIG_PGTABLE_HAS_HUGE_LEAVES
+static struct page *follow_huge_pud(struct vm_area_struct *vma,
+				    unsigned long addr, pud_t *pudp,
+				    int flags, struct follow_page_context *ctx)
+{
+	struct mm_struct *mm = vma->vm_mm;
+	struct page *page;
+	pud_t pud = *pudp;
+	unsigned long pfn = pud_pfn(pud);
+	int ret;
+
+	assert_spin_locked(pud_lockptr(mm, pudp));
+
+	if ((flags & FOLL_WRITE) && !pud_write(pud))
+		return NULL;
+
+	if (!pud_present(pud))
+		return NULL;
+
+	pfn += (addr & ~PUD_MASK) >> PAGE_SHIFT;
+
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+	if (pud_devmap(pud)) {
+		/*
+		 * device mapped pages can only be returned if the caller
+		 * will manage the page reference count.
+		 *
+		 * At least one of FOLL_GET | FOLL_PIN must be set, so
+		 * assert that here:
+		 */
+		if (!(flags & (FOLL_GET | FOLL_PIN)))
+			return ERR_PTR(-EEXIST);
+
+		if (flags & FOLL_TOUCH)
+			touch_pud(vma, addr, pudp, flags & FOLL_WRITE);
+
+		ctx->pgmap = get_dev_pagemap(pfn, ctx->pgmap);
+		if (!ctx->pgmap)
+			return ERR_PTR(-EFAULT);
+	}
+#endif	/* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
+	page = pfn_to_page(pfn);
+
+	if (!pud_devmap(pud) && !pud_write(pud) &&
+	    gup_must_unshare(vma, flags, page))
+		return ERR_PTR(-EMLINK);
+
+	ret = try_grab_page(page, flags);
+	if (ret)
+		page = ERR_PTR(ret);
+	else
+		ctx->page_mask = HPAGE_PUD_NR - 1;
+
+	return page;
+}
+#else  /* CONFIG_PGTABLE_HAS_HUGE_LEAVES */
+static struct page *follow_huge_pud(struct vm_area_struct *vma,
+				    unsigned long addr, pud_t *pudp,
+				    int flags, struct follow_page_context *ctx)
+{
+	return NULL;
+}
+#endif	/* CONFIG_PGTABLE_HAS_HUGE_LEAVES */
+
 static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
 		pte_t *pte, unsigned int flags)
 {
@@ -760,11 +824,11 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma,
 
 	pudp = pud_offset(p4dp, address);
 	pud = *pudp;
-	if (pud_none(pud))
+	if (pud_none(pud) || !pud_present(pud))
 		return no_page_table(vma, flags, address);
-	if (pud_devmap(pud)) {
+	if (pud_huge(pud)) {
 		ptl = pud_lock(mm, pudp);
-		page = follow_devmap_pud(vma, address, pudp, flags, &ctx->pgmap);
+		page = follow_huge_pud(vma, address, pudp, flags, ctx);
 		spin_unlock(ptl);
 		if (page)
 			return page;
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 6be1a380a298..def1dbe0d7e8 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1371,8 +1371,8 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
 }
 
 #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
-static void touch_pud(struct vm_area_struct *vma, unsigned long addr,
-		      pud_t *pud, bool write)
+void touch_pud(struct vm_area_struct *vma, unsigned long addr,
+	       pud_t *pud, bool write)
 {
 	pud_t _pud;
 
@@ -1384,49 +1384,6 @@ static void touch_pud(struct vm_area_struct *vma, unsigned long addr,
 		update_mmu_cache_pud(vma, addr, pud);
 }
 
-struct page *follow_devmap_pud(struct vm_area_struct *vma, unsigned long addr,
-		pud_t *pud, int flags, struct dev_pagemap **pgmap)
-{
-	unsigned long pfn = pud_pfn(*pud);
-	struct mm_struct *mm = vma->vm_mm;
-	struct page *page;
-	int ret;
-
-	assert_spin_locked(pud_lockptr(mm, pud));
-
-	if (flags & FOLL_WRITE && !pud_write(*pud))
-		return NULL;
-
-	if (pud_present(*pud) && pud_devmap(*pud))
-		/* pass */;
-	else
-		return NULL;
-
-	if (flags & FOLL_TOUCH)
-		touch_pud(vma, addr, pud, flags & FOLL_WRITE);
-
-	/*
-	 * device mapped pages can only be returned if the
-	 * caller will manage the page reference count.
-	 *
-	 * At least one of FOLL_GET | FOLL_PIN must be set, so assert that here:
-	 */
-	if (!(flags & (FOLL_GET | FOLL_PIN)))
-		return ERR_PTR(-EEXIST);
-
-	pfn += (addr & ~PUD_MASK) >> PAGE_SHIFT;
-	*pgmap = get_dev_pagemap(pfn, *pgmap);
-	if (!*pgmap)
-		return ERR_PTR(-EFAULT);
-	page = pfn_to_page(pfn);
-
-	ret = try_grab_page(page, flags);
-	if (ret)
-		page = ERR_PTR(ret);
-
-	return page;
-}
-
 int copy_huge_pud(struct mm_struct *dst_mm, struct mm_struct *src_mm,
 		  pud_t *dst_pud, pud_t *src_pud, unsigned long addr,
 		  struct vm_area_struct *vma)
diff --git a/mm/internal.h b/mm/internal.h
index 222e63b2dea4..2fca14553d0f 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -1007,6 +1007,8 @@ int __must_check try_grab_page(struct page *page, unsigned int flags);
 /*
  * mm/huge_memory.c
  */
+void touch_pud(struct vm_area_struct *vma, unsigned long addr,
+	       pud_t *pud, bool write);
 struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
 				   unsigned long addr, pmd_t *pmd,
 				   unsigned int flags);
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:36 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:36 +0800
Subject: [PATCH 11/13] mm/gup: Handle huge pmd for follow_pmd_mask()
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-12-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

Replace pmd_trans_huge() with pmd_thp_or_huge() to also cover pmd_huge() as
long as enabled.

FOLL_TOUCH and FOLL_SPLIT_PMD only apply to THP, not yet huge.

Since now follow_trans_huge_pmd() can process hugetlb pages, renaming it
into follow_huge_pmd() to match what it does.  Move it into gup.c so not
depend on CONFIG_THP.

When at it, move the ctx->page_mask setup into follow_huge_pmd(), only set
it when the page is valid.  It was not a bug to set it before even if GUP
failed (page==NULL), because follow_page_mask() callers always ignores
page_mask if so.  But doing so makes the code cleaner.

Signed-off-by: Peter Xu <peterx at redhat.com>
---
 mm/gup.c         | 107 ++++++++++++++++++++++++++++++++++++++++++++---
 mm/huge_memory.c |  86 +------------------------------------
 mm/internal.h    |   5 +--
 3 files changed, 105 insertions(+), 93 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 5b14f91d2f6b..080dff79b650 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -580,6 +580,93 @@ static struct page *follow_huge_pud(struct vm_area_struct *vma,
 
 	return page;
 }
+
+/* FOLL_FORCE can write to even unwritable PMDs in COW mappings. */
+static inline bool can_follow_write_pmd(pmd_t pmd, struct page *page,
+					struct vm_area_struct *vma,
+					unsigned int flags)
+{
+	/* If the pmd is writable, we can write to the page. */
+	if (pmd_write(pmd))
+		return true;
+
+	/* Maybe FOLL_FORCE is set to override it? */
+	if (!(flags & FOLL_FORCE))
+		return false;
+
+	/* But FOLL_FORCE has no effect on shared mappings */
+	if (vma->vm_flags & (VM_MAYSHARE | VM_SHARED))
+		return false;
+
+	/* ... or read-only private ones */
+	if (!(vma->vm_flags & VM_MAYWRITE))
+		return false;
+
+	/* ... or already writable ones that just need to take a write fault */
+	if (vma->vm_flags & VM_WRITE)
+		return false;
+
+	/*
+	 * See can_change_pte_writable(): we broke COW and could map the page
+	 * writable if we have an exclusive anonymous page ...
+	 */
+	if (!page || !PageAnon(page) || !PageAnonExclusive(page))
+		return false;
+
+	/* ... and a write-fault isn't required for other reasons. */
+	if (vma_soft_dirty_enabled(vma) && !pmd_soft_dirty(pmd))
+		return false;
+	return !userfaultfd_huge_pmd_wp(vma, pmd);
+}
+
+static struct page *follow_huge_pmd(struct vm_area_struct *vma,
+				    unsigned long addr, pmd_t *pmd,
+				    unsigned int flags,
+				    struct follow_page_context *ctx)
+{
+	struct mm_struct *mm = vma->vm_mm;
+	pmd_t pmdval = *pmd;
+	struct page *page;
+	int ret;
+
+	assert_spin_locked(pmd_lockptr(mm, pmd));
+
+	page = pmd_page(pmdval);
+	VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page);
+
+	if ((flags & FOLL_WRITE) &&
+	    !can_follow_write_pmd(pmdval, page, vma, flags))
+		return NULL;
+
+	/* Avoid dumping huge zero page */
+	if ((flags & FOLL_DUMP) && is_huge_zero_pmd(pmdval))
+		return ERR_PTR(-EFAULT);
+
+	if (pmd_protnone(*pmd) && !gup_can_follow_protnone(vma, flags))
+		return NULL;
+
+	if (!pmd_write(pmdval) && gup_must_unshare(vma, flags, page))
+		return ERR_PTR(-EMLINK);
+
+	VM_BUG_ON_PAGE((flags & FOLL_PIN) && PageAnon(page) &&
+			!PageAnonExclusive(page), page);
+
+	ret = try_grab_page(page, flags);
+	if (ret)
+		return ERR_PTR(ret);
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+	if (pmd_trans_huge(pmdval) && (flags & FOLL_TOUCH))
+		touch_pmd(vma, addr, pmd, flags & FOLL_WRITE);
+#endif	/* CONFIG_TRANSPARENT_HUGEPAGE */
+
+	page += (addr & ~HPAGE_PMD_MASK) >> PAGE_SHIFT;
+	ctx->page_mask = HPAGE_PMD_NR - 1;
+	VM_BUG_ON_PAGE(!PageCompound(page) && !is_zone_device_page(page), page);
+
+	return page;
+}
+
 #else  /* CONFIG_PGTABLE_HAS_HUGE_LEAVES */
 static struct page *follow_huge_pud(struct vm_area_struct *vma,
 				    unsigned long addr, pud_t *pudp,
@@ -587,6 +674,14 @@ static struct page *follow_huge_pud(struct vm_area_struct *vma,
 {
 	return NULL;
 }
+
+static struct page *follow_huge_pmd(struct vm_area_struct *vma,
+				    unsigned long addr, pmd_t *pmd,
+				    unsigned int flags,
+				    struct follow_page_context *ctx)
+{
+	return NULL;
+}
 #endif	/* CONFIG_PGTABLE_HAS_HUGE_LEAVES */
 
 static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
@@ -784,31 +879,31 @@ static struct page *follow_pmd_mask(struct vm_area_struct *vma,
 			return page;
 		return no_page_table(vma, flags, address);
 	}
-	if (likely(!pmd_trans_huge(pmdval)))
+	if (likely(!pmd_thp_or_huge(pmdval)))
 		return follow_page_pte(vma, address, pmd, flags, &ctx->pgmap);
 
 	if (pmd_protnone(pmdval) && !gup_can_follow_protnone(vma, flags))
 		return no_page_table(vma, flags, address);
 
 	ptl = pmd_lock(mm, pmd);
-	if (unlikely(!pmd_present(*pmd))) {
+	pmdval = *pmd;
+	if (unlikely(!pmd_present(pmdval))) {
 		spin_unlock(ptl);
 		return no_page_table(vma, flags, address);
 	}
-	if (unlikely(!pmd_trans_huge(*pmd))) {
+	if (unlikely(!pmd_thp_or_huge(pmdval))) {
 		spin_unlock(ptl);
 		return follow_page_pte(vma, address, pmd, flags, &ctx->pgmap);
 	}
-	if (flags & FOLL_SPLIT_PMD) {
+	if (pmd_trans_huge(pmdval) && (flags & FOLL_SPLIT_PMD)) {
 		spin_unlock(ptl);
 		split_huge_pmd(vma, pmd, address);
 		/* If pmd was left empty, stuff a page table in there quickly */
 		return pte_alloc(mm, pmd) ? ERR_PTR(-ENOMEM) :
 			follow_page_pte(vma, address, pmd, flags, &ctx->pgmap);
 	}
-	page = follow_trans_huge_pmd(vma, address, pmd, flags);
+	page = follow_huge_pmd(vma, address, pmd, flags, ctx);
 	spin_unlock(ptl);
-	ctx->page_mask = HPAGE_PMD_NR - 1;
 	return page;
 }
 
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index def1dbe0d7e8..930c59d7ceab 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1216,8 +1216,8 @@ vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write)
 EXPORT_SYMBOL_GPL(vmf_insert_pfn_pud);
 #endif /* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
 
-static void touch_pmd(struct vm_area_struct *vma, unsigned long addr,
-		      pmd_t *pmd, bool write)
+void touch_pmd(struct vm_area_struct *vma, unsigned long addr,
+	       pmd_t *pmd, bool write)
 {
 	pmd_t _pmd;
 
@@ -1570,88 +1570,6 @@ static inline bool can_change_pmd_writable(struct vm_area_struct *vma,
 	return pmd_dirty(pmd);
 }
 
-/* FOLL_FORCE can write to even unwritable PMDs in COW mappings. */
-static inline bool can_follow_write_pmd(pmd_t pmd, struct page *page,
-					struct vm_area_struct *vma,
-					unsigned int flags)
-{
-	/* If the pmd is writable, we can write to the page. */
-	if (pmd_write(pmd))
-		return true;
-
-	/* Maybe FOLL_FORCE is set to override it? */
-	if (!(flags & FOLL_FORCE))
-		return false;
-
-	/* But FOLL_FORCE has no effect on shared mappings */
-	if (vma->vm_flags & (VM_MAYSHARE | VM_SHARED))
-		return false;
-
-	/* ... or read-only private ones */
-	if (!(vma->vm_flags & VM_MAYWRITE))
-		return false;
-
-	/* ... or already writable ones that just need to take a write fault */
-	if (vma->vm_flags & VM_WRITE)
-		return false;
-
-	/*
-	 * See can_change_pte_writable(): we broke COW and could map the page
-	 * writable if we have an exclusive anonymous page ...
-	 */
-	if (!page || !PageAnon(page) || !PageAnonExclusive(page))
-		return false;
-
-	/* ... and a write-fault isn't required for other reasons. */
-	if (vma_soft_dirty_enabled(vma) && !pmd_soft_dirty(pmd))
-		return false;
-	return !userfaultfd_huge_pmd_wp(vma, pmd);
-}
-
-struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
-				   unsigned long addr,
-				   pmd_t *pmd,
-				   unsigned int flags)
-{
-	struct mm_struct *mm = vma->vm_mm;
-	struct page *page;
-	int ret;
-
-	assert_spin_locked(pmd_lockptr(mm, pmd));
-
-	page = pmd_page(*pmd);
-	VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page);
-
-	if ((flags & FOLL_WRITE) &&
-	    !can_follow_write_pmd(*pmd, page, vma, flags))
-		return NULL;
-
-	/* Avoid dumping huge zero page */
-	if ((flags & FOLL_DUMP) && is_huge_zero_pmd(*pmd))
-		return ERR_PTR(-EFAULT);
-
-	if (pmd_protnone(*pmd) && !gup_can_follow_protnone(vma, flags))
-		return NULL;
-
-	if (!pmd_write(*pmd) && gup_must_unshare(vma, flags, page))
-		return ERR_PTR(-EMLINK);
-
-	VM_BUG_ON_PAGE((flags & FOLL_PIN) && PageAnon(page) &&
-			!PageAnonExclusive(page), page);
-
-	ret = try_grab_page(page, flags);
-	if (ret)
-		return ERR_PTR(ret);
-
-	if (flags & FOLL_TOUCH)
-		touch_pmd(vma, addr, pmd, flags & FOLL_WRITE);
-
-	page += (addr & ~HPAGE_PMD_MASK) >> PAGE_SHIFT;
-	VM_BUG_ON_PAGE(!PageCompound(page) && !is_zone_device_page(page), page);
-
-	return page;
-}
-
 /* NUMA hinting page fault entry point for trans huge pmds */
 vm_fault_t do_huge_pmd_numa_page(struct vm_fault *vmf)
 {
diff --git a/mm/internal.h b/mm/internal.h
index 2fca14553d0f..c0e953a1eb62 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -1009,9 +1009,8 @@ int __must_check try_grab_page(struct page *page, unsigned int flags);
  */
 void touch_pud(struct vm_area_struct *vma, unsigned long addr,
 	       pud_t *pud, bool write);
-struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
-				   unsigned long addr, pmd_t *pmd,
-				   unsigned int flags);
+void touch_pmd(struct vm_area_struct *vma, unsigned long addr,
+	       pmd_t *pmd, bool write);
 
 /*
  * mm/mmap.c
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:37 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:37 +0800
Subject: [PATCH 12/13] mm/gup: Handle hugepd for follow_page()
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-13-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

Hugepd is only used in PowerPC so far on 4K page size kernels where hash
mmu is used.  follow_page_mask() used to leverage hugetlb APIs to access
hugepd entries.  Teach follow_page_mask() itself on hugepd.

With previous refactors on fast-gup gup_huge_pd(), most of the code can be
easily leveraged.  There's something not needed for follow page, for
example, gup_hugepte() tries to detect pgtable entry change which will
never happen with slow gup (which has the pgtable lock held), but that's
not a problem to check.

Since follow_page() always only fetch one page, set the end to "address +
PAGE_SIZE" should suffice.  We will still do the pgtable walk once for each
hugetlb page by setting ctx->page_mask properly.

One thing worth mentioning is that some level of pgtable's _bad() helper
will report is_hugepd() entries as TRUE on Power8 hash MMUs.  I think it at
least applies to PUD on Power8 with 4K pgsize.  It means feeding a hugepd
entry to pud_bad() will report a false positive. Let's leave that for now
because it can be arch-specific where I am a bit declined to touch.  In
this patch it's not a problem as long as hugepd is detected before any bad
pgtable entries.

Signed-off-by: Peter Xu <peterx at redhat.com>
---
 mm/gup.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 69 insertions(+), 9 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 080dff79b650..14a7d13e7bd6 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -30,6 +30,11 @@ struct follow_page_context {
 	unsigned int page_mask;
 };
 
+static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
+				  unsigned long addr, unsigned int pdshift,
+				  unsigned int flags,
+				  struct follow_page_context *ctx);
+
 static inline void sanity_check_pinned_pages(struct page **pages,
 					     unsigned long npages)
 {
@@ -871,6 +876,9 @@ static struct page *follow_pmd_mask(struct vm_area_struct *vma,
 		return no_page_table(vma, flags, address);
 	if (!pmd_present(pmdval))
 		return no_page_table(vma, flags, address);
+	if (unlikely(is_hugepd(__hugepd(pmd_val(pmdval)))))
+		return follow_hugepd(vma, __hugepd(pmd_val(pmdval)),
+				     address, PMD_SHIFT, flags, ctx);
 	if (pmd_devmap(pmdval)) {
 		ptl = pmd_lock(mm, pmd);
 		page = follow_devmap_pmd(vma, address, pmd, flags, &ctx->pgmap);
@@ -921,6 +929,9 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma,
 	pud = *pudp;
 	if (pud_none(pud) || !pud_present(pud))
 		return no_page_table(vma, flags, address);
+	if (unlikely(is_hugepd(__hugepd(pud_val(pud)))))
+		return follow_hugepd(vma, __hugepd(pud_val(pud)),
+				     address, PUD_SHIFT, flags, ctx);
 	if (pud_huge(pud)) {
 		ptl = pud_lock(mm, pudp);
 		page = follow_huge_pud(vma, address, pudp, flags, ctx);
@@ -940,13 +951,17 @@ static struct page *follow_p4d_mask(struct vm_area_struct *vma,
 				    unsigned int flags,
 				    struct follow_page_context *ctx)
 {
-	p4d_t *p4d;
+	p4d_t *p4d, p4dval;
 
 	p4d = p4d_offset(pgdp, address);
-	if (p4d_none(*p4d))
-		return no_page_table(vma, flags, address);
-	BUILD_BUG_ON(p4d_huge(*p4d));
-	if (unlikely(p4d_bad(*p4d)))
+	p4dval = *p4d;
+	BUILD_BUG_ON(p4d_huge(p4dval));
+
+	if (unlikely(is_hugepd(__hugepd(p4d_val(p4dval)))))
+		return follow_hugepd(vma, __hugepd(p4d_val(p4dval)),
+				     address, P4D_SHIFT, flags, ctx);
+
+	if (p4d_none(p4dval) || unlikely(p4d_bad(p4dval)))
 		return no_page_table(vma, flags, address);
 
 	return follow_pud_mask(vma, address, p4d, flags, ctx);
@@ -980,7 +995,7 @@ static struct page *follow_page_mask(struct vm_area_struct *vma,
 			      unsigned long address, unsigned int flags,
 			      struct follow_page_context *ctx)
 {
-	pgd_t *pgd;
+	pgd_t *pgd, pgdval;
 	struct mm_struct *mm = vma->vm_mm;
 
 	ctx->page_mask = 0;
@@ -995,11 +1010,17 @@ static struct page *follow_page_mask(struct vm_area_struct *vma,
 						&ctx->page_mask);
 
 	pgd = pgd_offset(mm, address);
+	pgdval = *pgd;
 
-	if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
-		return no_page_table(vma, flags, address);
+	if (unlikely(is_hugepd(__hugepd(pgd_val(pgdval)))))
+		page = follow_hugepd(vma, __hugepd(pgd_val(pgdval)),
+				     address, PGDIR_SHIFT, flags, ctx);
+	else if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
+		page = no_page_table(vma, flags, address);
+	else
+		page = follow_p4d_mask(vma, address, pgd, flags, ctx);
 
-	return follow_p4d_mask(vma, address, pgd, flags, ctx);
+	return page;
 }
 
 struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
@@ -3026,6 +3047,37 @@ static int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
 
 	return 1;
 }
+
+static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
+				  unsigned long addr, unsigned int pdshift,
+				  unsigned int flags,
+				  struct follow_page_context *ctx)
+{
+	struct page *page;
+	struct hstate *h;
+	spinlock_t *ptl;
+	int nr = 0, ret;
+	pte_t *ptep;
+
+	/* Only hugetlb supports hugepd */
+	if (WARN_ON_ONCE(!is_vm_hugetlb_page(vma)))
+		return ERR_PTR(-EFAULT);
+
+	h = hstate_vma(vma);
+	ptep = hugepte_offset(hugepd, addr, pdshift);
+	ptl = huge_pte_lock(h, vma->vm_mm, ptep);
+	ret = gup_huge_pd(hugepd, addr, pdshift, addr + PAGE_SIZE,
+			  flags, &page, &nr);
+	spin_unlock(ptl);
+
+	if (ret) {
+		WARN_ON_ONCE(nr != 1);
+		ctx->page_mask = (1U << huge_page_order(h)) - 1;
+		return page;
+	}
+
+	return NULL;
+}
 #else
 static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
 		unsigned int pdshift, unsigned long end, unsigned int flags,
@@ -3033,6 +3085,14 @@ static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
 {
 	return 0;
 }
+
+static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
+				  unsigned long addr, unsigned int pdshift,
+				  unsigned int flags,
+				  struct follow_page_context *ctx)
+{
+	return NULL;
+}
 #endif /* CONFIG_ARCH_HAS_HUGEPD */
 
 static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
-- 
2.41.0



From peterx at redhat.com  Mon Dec 18 23:55:38 2023
From: peterx at redhat.com (peterx at redhat.com)
Date: Tue, 19 Dec 2023 15:55:38 +0800
Subject: [PATCH 13/13] mm/gup: Handle hugetlb in the generic follow_page_mask code
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <20231219075538.414708-14-peterx@redhat.com>

From: Peter Xu <peterx at redhat.com>

Now follow_page() is ready to handle hugetlb pages in whatever form, and
over all architectures.  Switch to the generic code path.

Time to retire hugetlb_follow_page_mask(), following the previous
retirement of follow_hugetlb_page() in 4849807114b8.

There may be a slight difference of how the loops run when processing slow
GUP over a large hugetlb range on cont_pte/cont_pmd supported archs: each
loop of __get_user_pages() will resolve one pgtable entry with the patch
applied, rather than relying on the size of hugetlb hstate, the latter may
cover multiple entries in one loop.

A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
a tight loop of slow gup after the path switched.  That shouldn't be a
problem because slow-gup should not be a hot path for GUP in general: when
page is commonly present, fast-gup will already succeed, while when the
page is indeed missing and require a follow up page fault, the slow gup
degrade will probably buried in the fault paths anyway.  It also explains
why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
accelerate thp gup even for "pages != NULL"") lands, the latter not part of
a performance analysis but a side benefit.  If the performance will be a
concern, we can consider handle CONT_PTE in follow_page().

Before that is justified to be necessary, keep everything clean and simple.

Signed-off-by: Peter Xu <peterx at redhat.com>
---
 include/linux/hugetlb.h |  7 ----
 mm/gup.c                | 15 +++------
 mm/hugetlb.c            | 71 -----------------------------------------
 3 files changed, 5 insertions(+), 88 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index f8c5c174c8a6..8a352d577ebf 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -332,13 +332,6 @@ static inline void hugetlb_zap_end(
 {
 }
 
-static inline struct page *hugetlb_follow_page_mask(
-    struct vm_area_struct *vma, unsigned long address, unsigned int flags,
-    unsigned int *page_mask)
-{
-	BUILD_BUG(); /* should never be compiled in if !CONFIG_HUGETLB_PAGE*/
-}
-
 static inline int copy_hugetlb_page_range(struct mm_struct *dst,
 					  struct mm_struct *src,
 					  struct vm_area_struct *dst_vma,
diff --git a/mm/gup.c b/mm/gup.c
index 14a7d13e7bd6..f34c0a912311 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -997,18 +997,11 @@ static struct page *follow_page_mask(struct vm_area_struct *vma,
 {
 	pgd_t *pgd, pgdval;
 	struct mm_struct *mm = vma->vm_mm;
+	struct page *page;
 
-	ctx->page_mask = 0;
-
-	/*
-	 * Call hugetlb_follow_page_mask for hugetlb vmas as it will use
-	 * special hugetlb page table walking code.  This eliminates the
-	 * need to check for hugetlb entries in the general walking code.
-	 */
-	if (is_vm_hugetlb_page(vma))
-		return hugetlb_follow_page_mask(vma, address, flags,
-						&ctx->page_mask);
+	vma_pgtable_walk_begin(vma);
 
+	ctx->page_mask = 0;
 	pgd = pgd_offset(mm, address);
 	pgdval = *pgd;
 
@@ -1020,6 +1013,8 @@ static struct page *follow_page_mask(struct vm_area_struct *vma,
 	else
 		page = follow_p4d_mask(vma, address, pgd, flags, ctx);
 
+	vma_pgtable_walk_end(vma);
+
 	return page;
 }
 
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 29705e5c6f40..3013122a739f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6783,77 +6783,6 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte,
 }
 #endif /* CONFIG_USERFAULTFD */
 
-struct page *hugetlb_follow_page_mask(struct vm_area_struct *vma,
-				      unsigned long address, unsigned int flags,
-				      unsigned int *page_mask)
-{
-	struct hstate *h = hstate_vma(vma);
-	struct mm_struct *mm = vma->vm_mm;
-	unsigned long haddr = address & huge_page_mask(h);
-	struct page *page = NULL;
-	spinlock_t *ptl;
-	pte_t *pte, entry;
-	int ret;
-
-	hugetlb_vma_lock_read(vma);
-	pte = hugetlb_walk(vma, haddr, huge_page_size(h));
-	if (!pte)
-		goto out_unlock;
-
-	ptl = huge_pte_lock(h, mm, pte);
-	entry = huge_ptep_get(pte);
-	if (pte_present(entry)) {
-		page = pte_page(entry);
-
-		if (!huge_pte_write(entry)) {
-			if (flags & FOLL_WRITE) {
-				page = NULL;
-				goto out;
-			}
-
-			if (gup_must_unshare(vma, flags, page)) {
-				/* Tell the caller to do unsharing */
-				page = ERR_PTR(-EMLINK);
-				goto out;
-			}
-		}
-
-		page = nth_page(page, ((address & ~huge_page_mask(h)) >> PAGE_SHIFT));
-
-		/*
-		 * Note that page may be a sub-page, and with vmemmap
-		 * optimizations the page struct may be read only.
-		 * try_grab_page() will increase the ref count on the
-		 * head page, so this will be OK.
-		 *
-		 * try_grab_page() should always be able to get the page here,
-		 * because we hold the ptl lock and have verified pte_present().
-		 */
-		ret = try_grab_page(page, flags);
-
-		if (WARN_ON_ONCE(ret)) {
-			page = ERR_PTR(ret);
-			goto out;
-		}
-
-		*page_mask = (1U << huge_page_order(h)) - 1;
-	}
-out:
-	spin_unlock(ptl);
-out_unlock:
-	hugetlb_vma_unlock_read(vma);
-
-	/*
-	 * Fixup retval for dump requests: if pagecache doesn't exist,
-	 * don't try to allocate a new page but just skip it.
-	 */
-	if (!page && (flags & FOLL_DUMP) &&
-	    !hugetlbfs_pagecache_present(h, vma, address))
-		page = ERR_PTR(-EFAULT);
-
-	return page;
-}
-
 long hugetlb_change_protection(struct vm_area_struct *vma,
 		unsigned long address, unsigned long end,
 		pgprot_t newprot, unsigned long cp_flags)
-- 
2.41.0



From krzysztof.kozlowski at linaro.org  Tue Dec 19 00:06:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 09:06:12 +0100
Subject: [PATCH 00/15] memory: Convert to platform remove callback returning void
In-Reply-To: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
Message-ID: <170297316309.10063.8435852209780151651.b4-ty@linaro.org>


On Sun, 17 Dec 2023 15:29:26 +0100, Uwe Kleine-K?nig wrote:
> this series converts the platform drivers below drivers/memory to make
> use of .remove_new. See commit 5c5a7680e67b ("platform: Provide a remove
> callback that returns no value") for an extended explanation and the
> eventual goal. The TL;DR; is to make it harder for driver authors to
> leak resources without noticing.
> 
> This is merge window material. All patches are pairwise independent of
> each other so they can be applied individually. Still it would be great
> to let them go in all together.
> 
> [...]

Applied, thanks!

[01/15] memory: brcmstb_dpfe: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/431187eadbc7b0f2650d4e55111b3fff4720f867
[02/15] memory: brcmstb_memc: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/f7754712ad6094de5be18674777b265ed4db2f45
[03/15] memory: emif: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/c8a53461990cb697ca494d6671fab9e196d20ce4
[04/15] memory: fsl-corenet-cf: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/021d044b0f9c9a09aa2f778e876e467a8810fb4a
[05/15] memory: fsl_ifc: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/f17130855d51f24563a24cd957add769ad59eee9
[06/15] memory: jz4780-nemc: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/9024fbbd77b4d73279bbbe2c748a4e4b414d50cc
[07/15] memory: mtk-smi: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/08c1aeaa45ce0fd18912e92c6705586c8aa5240f
[08/15] memory: omap-gpmc: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/6a4edb1a4f61e28cc127cd06c470ce3599ee0d9c
[09/15] memory: renesas-rpc-if: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/961abc9f7d6771e8f13db1f4d8b0ffff3f0f41a4
[10/15] memory: exynos5422-dmc: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/8013408e4912fb7e469bb8b14fd3a5c956257eec
[11/15] memory: stm32-fmc2-ebi: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/1455b6b0c83132960826d0e527a79a355e096a80
[12/15] memory: tegra186-emc: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/dcefa0368458e9e20642dbd2608adae6b22e6464
[13/15] memory: tegra210-emc: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/622fa819a2f0f3e6d8322a0b6d3177302ae937b6
[14/15] memory: ti-aemif: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/7852eb8c8ac7e0164b43cc5f8d8245cc3a037620
[15/15] memory: ti-emif-pm: Convert to platform remove callback returning void
        https://git.kernel.org/krzk/linux-mem-ctrl/c/365fcc03b6321f36eb7cbda8baa737238c387907

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


From krzysztof.kozlowski at linaro.org  Tue Dec 19 00:06:29 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 09:06:29 +0100
Subject: [PATCH 00/15] memory: Convert to platform remove callback
 returning void
In-Reply-To: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
References: <cover.1702822744.git.u.kleine-koenig@pengutronix.de>
Message-ID: <cb60263e-4ca2-4042-ba2f-8e17fc850639@linaro.org>

On 17/12/2023 15:29, Uwe Kleine-K?nig wrote:
> Hello,
> 
> this series converts the platform drivers below drivers/memory to make
> use of .remove_new. See commit 5c5a7680e67b ("platform: Provide a remove
> callback that returns no value") for an extended explanation and the
> eventual goal. The TL;DR; is to make it harder for driver authors to
> leak resources without noticing.

Thanks, applied.
It is however very late in the cycle, so there is a chance this will
miss the merge window. If this happens, I will keep it for the next
cycle (no need for resending).

Best regards,
Krzysztof



From jan.kiszka at siemens.com  Tue Dec 19 00:06:32 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 19 Dec 2023 09:06:32 +0100
Subject: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector
 bits
In-Reply-To: <10f300d6-8a1a-4363-a16e-8337da8525d1@linaro.org>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <202d324ab0aa3728c8f846d31bedcbaba14aebdd.1702917360.git.jan.kiszka@siemens.com>
 <10f300d6-8a1a-4363-a16e-8337da8525d1@linaro.org>
Message-ID: <f4b16dc6-1063-40d4-b68e-1eef9db32829@siemens.com>

On 19.12.23 08:51, Krzysztof Kozlowski wrote:
> On 18/12/2023 17:35, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka at siemens.com>
>>
>> A new variant is to be added which will not have a arduino connector
>> like the existing ones. Factor out all bits that are specific to this
>> connector.
>>
>> The split is not perfect because wkup_gpio0 is defined based on what is
>> common to all variants having the connector, thus containing also
>> connector-unrelated information. But this is still cleaner than
>> replicating this node into all 4 variants.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
>> ---
>>  .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
>>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
> 
> Please use proper -B/-M/-C arguments so code movements will be detected.
> 

Those are in place but have no impact, likely because the source file is
still ~700 lines after the shuffling.

Jan

-- 
Siemens AG, Technology
Linux Expert Center



From miquel.raynal at bootlin.com  Tue Dec 19 00:12:21 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Tue, 19 Dec 2023 09:12:21 +0100
Subject: [PATCH v11 00/10] spi: Add support for stacked/parallel
 memories
In-Reply-To: <1953466568.133535.1702937420979.JavaMail.zimbra@nod.at>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
	<1953466568.133535.1702937420979.JavaMail.zimbra@nod.at>
Message-ID: <20231219091221.30b1f167@xps-13>

Hi Richard,

richard at nod.at wrote on Mon, 18 Dec 2023 23:10:20 +0100 (CET):

> ----- Urspr?ngliche Mail -----
> > Von: "Amit Kumar Mahapatra" <amit.kumar-mahapatra at amd.com>  
> 
> > This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI
> > driver to add stacked and parallel memories support.  
> 
> I wish the series had a real cover letter which explains the big picture
> in more detail.
> 
> What I didn't really get so far, is it really necessary to support multiple
> chip selects within a single mtd?
> You changes introduce hard to maintain changes into the spi-nor/mtd core code
> which alert me.
> Why can't we have one mtd for each cs and, if needed, combine them later?
> We have drivers such as mtdconcat for reasons.

The Xilinx SPI controller is a bit convoluted, there are two ways to
address the bits in a memory:
* Either your extend the memory range with the second chip "on
  top" of the first (which would typically be a mtd-concat use case)
* Or you use the two chips in parallel and you store the even bits
  in one device (let's say cs0) and the odd bits in the other (cs1).
  Extending mtd-concat for this might be another solution, I don't know
  how feasible it would be.

Maybe these bindings will help understanding the logic:
e2edd1b64f1c ("spi: dt-bindings: Describe stacked/parallel memories modes")
eba5368503b4 ("spi: dt-bindings: Add an example with two stacked flashes")

However I agree the changes will likely be hard to maintain given the
complexity brought with such a different controller.

Thanks,
Miqu?l


From krzysztof.kozlowski at linaro.org  Tue Dec 19 00:12:43 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 09:12:43 +0100
Subject: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector
 bits
In-Reply-To: <f4b16dc6-1063-40d4-b68e-1eef9db32829@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <202d324ab0aa3728c8f846d31bedcbaba14aebdd.1702917360.git.jan.kiszka@siemens.com>
 <10f300d6-8a1a-4363-a16e-8337da8525d1@linaro.org>
 <f4b16dc6-1063-40d4-b68e-1eef9db32829@siemens.com>
Message-ID: <e8cdfbb4-920e-4d3c-94ea-be24a7e21d57@linaro.org>

On 19/12/2023 09:06, Jan Kiszka wrote:
> On 19.12.23 08:51, Krzysztof Kozlowski wrote:
>> On 18/12/2023 17:35, Jan Kiszka wrote:
>>> From: Jan Kiszka <jan.kiszka at siemens.com>
>>>
>>> A new variant is to be added which will not have a arduino connector
>>> like the existing ones. Factor out all bits that are specific to this
>>> connector.
>>>
>>> The split is not perfect because wkup_gpio0 is defined based on what is
>>> common to all variants having the connector, thus containing also
>>> connector-unrelated information. But this is still cleaner than
>>> replicating this node into all 4 variants.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
>>> ---
>>>  .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
>>>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
>>
>> Please use proper -B/-M/-C arguments so code movements will be detected.
>>
> 
> Those are in place but have no impact, likely because the source file is

In place as what?

> still ~700 lines after the shuffling.

The original file has 720 lines, so if you move 750 (!) of them, I can
hardly believe the rename cannot be detected. You are basically moving
90% or 95% of file, so this must be represented with proper diff.

Your patches do not apply on next, neither on master, so it is tricky to
check.

How do you expect us to review it? Compare line by line?

Best regards,
Krzysztof



From ryan.roberts at arm.com  Tue Dec 19 00:18:17 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 19 Dec 2023 08:18:17 +0000
Subject: [PATCH v4 01/16] mm: thp: Batch-collapse PMD with set_ptes()
In-Reply-To: <8ce9f79c-be2f-4fa2-b356-39436a1d108a@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-2-ryan.roberts@arm.com>
 <8ce9f79c-be2f-4fa2-b356-39436a1d108a@redhat.com>
Message-ID: <a59a2314-82f3-4278-a4de-338d725bbd32@arm.com>

On 18/12/2023 17:40, David Hildenbrand wrote:
> On 18.12.23 11:50, Ryan Roberts wrote:
>> Refactor __split_huge_pmd_locked() so that a present PMD can be
>> collapsed to PTEs in a single batch using set_ptes(). It also provides a
>> future opportunity to batch-add the folio to the rmap using David's new
>> batched rmap APIs.
> 
> I'd drop that sentence and rather just say "In the future, we might get rid of
> the remaining manual loop by using rmap batching.".

OK fair enough. Will fix for next version.

> 
>>
>> This should improve performance a little bit, but the real motivation is
>> to remove the need for the arm64 backend to have to fold the contpte
>> entries. Instead, since the ptes are set as a batch, the contpte blocks
>> can be initially set up pre-folded (once the arm64 contpte support is
>> added in the next few patches). This leads to noticeable performance
>> improvement during split.
>>
> Acked-by: David Hildenbrand <david at redhat.com>

Thanks!



From jan.kiszka at siemens.com  Tue Dec 19 00:18:20 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 19 Dec 2023 09:18:20 +0100
Subject: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector
 bits
In-Reply-To: <e8cdfbb4-920e-4d3c-94ea-be24a7e21d57@linaro.org>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <202d324ab0aa3728c8f846d31bedcbaba14aebdd.1702917360.git.jan.kiszka@siemens.com>
 <10f300d6-8a1a-4363-a16e-8337da8525d1@linaro.org>
 <f4b16dc6-1063-40d4-b68e-1eef9db32829@siemens.com>
 <e8cdfbb4-920e-4d3c-94ea-be24a7e21d57@linaro.org>
Message-ID: <6e891e6f-a673-4eba-97ee-736e302094dd@siemens.com>

On 19.12.23 09:12, Krzysztof Kozlowski wrote:
> On 19/12/2023 09:06, Jan Kiszka wrote:
>> On 19.12.23 08:51, Krzysztof Kozlowski wrote:
>>> On 18/12/2023 17:35, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka at siemens.com>
>>>>
>>>> A new variant is to be added which will not have a arduino connector
>>>> like the existing ones. Factor out all bits that are specific to this
>>>> connector.
>>>>
>>>> The split is not perfect because wkup_gpio0 is defined based on what is
>>>> common to all variants having the connector, thus containing also
>>>> connector-unrelated information. But this is still cleaner than
>>>> replicating this node into all 4 variants.
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
>>>> ---
>>>>  .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
>>>>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
>>>
>>> Please use proper -B/-M/-C arguments so code movements will be detected.
>>>
>>
>> Those are in place but have no impact, likely because the source file is
> 
> In place as what?
> 
>> still ~700 lines after the shuffling.
> 
> The original file has 720 lines, so if you move 750 (!) of them, I can

The original file has 1446 lines - I should have noted that this goes on 
top of [1] which is already pending for 6.8 in Nishanth's tree, sorry.

Jan

[1] https://lore.kernel.org/lkml/cover.1699087938.git.jan.kiszka at siemens.com/

> hardly believe the rename cannot be detected. You are basically moving
> 90% or 95% of file, so this must be represented with proper diff.
> 
> Your patches do not apply on next, neither on master, so it is tricky to
> check.
> 
> How do you expect us to review it? Compare line by line?
> 
> Best regards,
> Krzysztof
> 

-- 
Siemens AG, Technology
Linux Expert Center



From jan.kiszka at siemens.com  Tue Dec 19 00:22:21 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 19 Dec 2023 09:22:21 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
Message-ID: <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>

On 19.12.23 08:54, Krzysztof Kozlowski wrote:
> On 18/12/2023 17:36, Jan Kiszka wrote:
>> From: Baocheng Su <baocheng.su at siemens.com>
>>
>> Main differences between the new variant and Advanced PG2:
> 
> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching.
> 
>>
>> 1. Arduino interface is removed. Instead, an new ASIC is added for
>>    communicating with PLC 1200 signal modules.
>> 2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
>>    avaiable.
>> 3. DP interface is tailored down. Instead, to communicate with the
>>    PLC 1200 signal modules, a USB 3.0 type B connector is added but the
>>    signal is not USB.
>> 4. DDR size is increased to 4 GB.
>> 5. Two sensors are added, one tilt sensor and one light sensor.
>>
>> The light sensor it not yet added to the DT at this stage as it depends
>> on to-be-added bindings.
>>
>> Co-developed-by: Chao Zeng <chao.zeng at siemens.com>
>> Signed-off-by: Chao Zeng <chao.zeng at siemens.com>
>> Co-developed-by: Li Hua Qian <huaqian.li at siemens.com>
>> Signed-off-by: Li Hua Qian <huaqian.li at siemens.com>
>> Signed-off-by: Baocheng Su <baocheng.su at siemens.com>
>> [Jan: rebase over arduino refactoring, split-out light sensor]
>> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
>> ---
>>  arch/arm64/boot/dts/ti/Makefile               |   1 +
>>  .../dts/ti/k3-am6548-iot2050-advanced-sm.dts  | 210 ++++++++++++++++++
>>  2 files changed, 211 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
>>
>> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
>> index 77a347f9f47d..9b15eaad284c 100644
>> --- a/arch/arm64/boot/dts/ti/Makefile
>> +++ b/arch/arm64/boot/dts/ti/Makefile
>> @@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-m2.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-pg2.dtb
>> +dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-sm.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am654-gp-evm.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am654-evm.dtb
>> diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
>> new file mode 100644
>> index 000000000000..ab3eef683890
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
>> @@ -0,0 +1,210 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) Siemens AG, 2023
>> + *
>> + * Authors:
>> + *   Baocheng Su <baocheng.su at siemens.com>
>> + *   Chao Zeng <chao.zeng at siemens.com>
>> + *   Huaqian Li <huaqian.li at siemens.com>
>> + *
>> + * AM6548-based (quad-core) IOT2050 SM variant, Product Generation 2
>> + * 4 GB RAM, 16 GB eMMC, USB-serial converter on connector X30
>> + *
>> + * Product homepage:
>> + * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "k3-am6548-iot2050-advanced-common.dtsi"
>> +#include "k3-am65-iot2050-common-pg2.dtsi"
>> +
>> +/ {
>> +	compatible = "siemens,iot2050-advanced-sm", "ti,am654";
>> +	model = "SIMATIC IOT2050 Advanced SM";
>> +
>> +	memory at 80000000 {
>> +		device_type = "memory";
>> +		/* 4G RAM */
>> +		reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
>> +		      <0x00000008 0x80000000 0x00000000 0x80000000>;
>> +	};
>> +
>> +	aliases {
>> +		spi1 = &main_spi0;
>> +	};
>> +
>> +	leds {
>> +		compatible = "gpio-leds";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&leds_pins_default>, <&user1_led_pins>;
>> +
>> +		user-led1-red {
> 
> led-0
> 
>> +			gpios = <&wkup_gpio0 52 GPIO_ACTIVE_HIGH>;
> 
> Missing function, missing color. Color goes as property, not as node name.
> 
>> +		};
>> +
>> +		user-led1-green {
> 
> led-1
> 
>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
> 
> Ditto
> 

This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
not introducing new ones. We can add the color properties in a separate
patch, but the node names are now part of the kernel ABI. Changing them
would break existing userland.

> 
>> +
>> +&dwc3_0 {
>> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
>> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
>> +	/delete-property/ phys;
>> +	/delete-property/ phy-names;
> 
> If your board need to remove phys from the SoC node, something is wrong.
> Either your board or SoC.
> 
> Any removal of properties in DTS is weird and unexpected. It deserves
> comments.

This goes along disabling USB3 which is by default enabled via
k3-am65-iot2050-common-pg2.dtsi

> 
>> +};
>> +
>> +&usb0 {
>> +	maximum-speed = "high-speed";
>> +	/delete-property/ snps,dis-u1-entry-quirk;
>> +	/delete-property/ snps,dis-u2-entry-quirk;
> 
> Same questions. If SoC has quirks, how can your board be fixed? It's SoC
> property... or you are using different SoC.
> 

Same story.

Baocheng, Zeng Chao, correct me if there is more behind that.

Jan

-- 
Siemens AG, Technology
Linux Expert Center



From quic_bibekkum at quicinc.com  Tue Dec 19 00:24:55 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 13:54:55 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <8338db1e-0216-4fc5-b6ab-ddf43adf3648@linaro.org>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
 <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
 <aa8b2ccd-33da-404b-9a93-3d88cf63ec77@quicinc.com>
 <8338db1e-0216-4fc5-b6ab-ddf43adf3648@linaro.org>
Message-ID: <a363c860-62be-43a7-930c-cab8a6f3fa6c@quicinc.com>



On 12/18/2023 7:51 PM, Dmitry Baryshkov wrote:
> On 18/12/2023 13:23, Bibek Kumar Patro wrote:
>>
>>
>> On 12/16/2023 9:45 PM, Dmitry Baryshkov wrote:
>>> On 16/12/2023 02:03, Konrad Dybcio wrote:
>>>> On 15.12.2023 13:54, Robin Murphy wrote:
>>>>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>>>>>
>>>>>>
>>>>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>>>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>>>>>> <quic_bibekkum at quicinc.com> wrote:
>>>>>>>>
>>>>>>>> Add ACTLR data table for SM8550 along with support for
>>>>>>>> same including SM8550 specific implementation operations.
>>>>>>>>
>>>>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>>>>>> ---
>>>>>>>> ?? drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89 
>>>>>>>> ++++++++++++++++++++++
>>>>>>>> ?? 1 file changed, 89 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
>>>>>>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>> index cb49291f5233..d2006f610243 100644
>>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>>>>>> ????????? u32 actlr;
>>>>>>>> ?? };
>>>>>>>>
>>>>>>>> +/*
>>>>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching 
>>>>>>>> in the
>>>>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the 
>>>>>>>> prefetch
>>>>>>>> + * buffer). The remaining bits are implementation defined and 
>>>>>>>> vary across
>>>>>>>> + * SoCs.
>>>>>>>> + */
>>>>>>>> +
>>>>>>>> +#define PREFETCH_DEFAULT?????? 0
>>>>>>>> +#define PREFETCH_SHALLOW?????? BIT(8)
>>>>>>>> +#define PREFETCH_MODERATE????? BIT(9)
>>>>>>>> +#define PREFETCH_DEEP????????? (BIT(9) | BIT(8))
>>>>>>>
>>>>>>> I thin the following might be more correct:
>>>>>>>
>>>>>>> #include <linux/bitfield.h>
>>>>>>>
>>>>>>> #define PREFETCH_MASK GENMASK(9, 8)
>>>>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>>>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>>>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>>>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>>>>>
>>>>>>
>>>>>> Ack, thanks for this suggestion. Let me try this out using
>>>>>> GENMASK. Once tested, will take care of this in next version.
>>>>>
>>>>> FWIW the more typical usage would be to just define the named 
>>>>> macros for the raw field values, then put the FIELD_PREP() at the 
>>>>> point of use. However in this case that's liable to get pretty 
>>>>> verbose, so although I'm usually a fan of bitfield.h, the most 
>>>>> readable option here might actually be to stick with simpler 
>>>>> definitions of "(0 << 8)", "(1 << 8)", etc. However it's not really 
>>>>> a big deal either way, and I defer to whatever Dmitry and Konrad 
>>>>> prefer, since they're the ones looking after arm-smmu-qcom the most :)
>>>> My 5 cents would be to just use the "common" style of doing this, so:
>>>>
>>>> #define ACTRL_PREFETCH??? GENMASK(9, 8)
>>>> ? #define PREFETCH_DEFAULT 0
>>>> ? #define PREFETCH_SHALLOW 1
>>>> ? #define PREFETCH_MODERATE 2
>>>> ? #define PREFETCH_DEEP 3
>>>>
>>>> and then use
>>>>
>>>> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
>>>>
>>>> it can get verbose, but.. arguably that's good, since you really want
>>>> to make sure the right bits are set here
>>>
>>> Sounds good to me.
>>>
>>
>> Konrad, Dimitry, just checked FIELD_PREP() implementation
>>
>> #define FIELD_FIT(_mask, _val)
>> ({????????????????????????????????????????????????????????????? \
>> ????????????????? __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");? \
>> ????????????????? ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
>> })
>>
>> since it is defined as a block, it won't be possible to use FIELD_PREP
>> in macro or as a structure value, and can only be used inside a 
>> block/function. Orelse would show compilation errors as following
>>
>> kernel/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c:94:20: note: in 
>> expansion of macro 'PREFETCH_SHALLOW'
>> ?? { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>> ???????????????????? ^
>> kernel/include/linux/bitfield.h:113:2: error: braced-group within 
>> expression allowed only inside a function
>> ?? ({??????? \
>> ?? ^
>>
>> So as per my understanding I think, we might need to go ahead with the
>> generic implementation only. Let me know if I missed something.
> 
> Then anyway (foo << bar) is better compared to BIT(n) | BIT(m).
> 

Sure Dmitry, (foo << bar) would be simpler as well as Robin mentioned
earlier in his reply.
I can implement the defines as:

#define PREFETCH_DEFAULT       0
#define PREFETCH_SHALLOW       (1 << 8)
#define PREFETCH_MODERATE      (1 << 9)
#define PREFETCH_DEEP          (3 << 8)

This should be okay I think ?

Thanks,
Bibek



From tudor.ambarus at linaro.org  Tue Dec 19 00:26:20 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Tue, 19 Dec 2023 10:26:20 +0200
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <BN7PR12MB280237CDD7BB148479932874DC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
 <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <c3fa1e04-92ed-48ab-a509-98e43abd5cd6@linaro.org>
 <BN7PR12MB2802E87F1A6CD22D904CAEACDC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
 <b3d3c457-a43b-478a-85b3-52558227d139@linaro.org>
 <BN7PR12MB28027E62D66460A374E3CFEADC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
 <e212f9fa-83c5-4b9e-8636-c8c6183096ab@linaro.org>
 <BN7PR12MB280237CDD7BB148479932874DC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
Message-ID: <576d56ed-d24b-40f9-9ae4-a02c50eea2ab@linaro.org>



On 15.12.2023 13:20, Mahapatra, Amit Kumar wrote:
> Hello Tudor,
> 

Hi!

>> -----Original Message-----
>> From: Tudor Ambarus <tudor.ambarus at linaro.org>
>> Sent: Friday, December 15, 2023 4:03 PM
>> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
>> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
>> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
>> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
>> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
>> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org; michael at walle.cc;
>> linux-mtd at lists.infradead.org; nicolas.ferre at microchip.com;
>> alexandre.belloni at bootlin.com; claudiu.beznea at tuxon.dev; Simek, Michal
>> <michal.simek at amd.com>; linux-arm-kernel at lists.infradead.org; alsa-
>> devel at alsa-project.org; patches at opensource.cirrus.com; linux-
>> sound at vger.kernel.org; git (AMD-Xilinx) <git at amd.com>;
>> amitrkcian2002 at gmail.com
>> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
>> in spi-nor
>>
>>
>>
>> On 12/15/23 10:02, Mahapatra, Amit Kumar wrote:
>>> Hello Tudor,
>>
>> Hi,
>>
>>>
>>>> -----Original Message-----
>>>> From: Tudor Ambarus <tudor.ambarus at linaro.org>
>>>> Sent: Friday, December 15, 2023 1:40 PM
>>>> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
>>>> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
>>>> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
>>>> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
>>>> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
>>>> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
>>>> michael at walle.cc; linux-mtd at lists.infradead.org;
>>>> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
>>>> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>;
>>>> linux- arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
>>>> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
>>>> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
>>>> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories
>>>> support in spi-nor
>>>>
>>>>
>>>>
>>>> On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
>>>>>> Thanks! Can you share with us what flashes you used for testing in
>>>>>> the stacked and parallel configurations?
>>>>> I used SPI-NOR QSPI flashes for testing stacked and parallel.
>>>>
>>>> I got that, I wanted the flash name or device ID.
>>>
>>> N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI
>> flashes
>>> on which we tested. Additionally, we conducted tests on over 30
>>> different QSPI flashes from four distinct vendors (Miron, Winbond,
>> Macronix, and ISSI).
>>>
>>
>> Great.
>>
>>>> What I'm interested is if each flash is in its own package. Are they?
>>>
>>> I'm sorry, but I don't quite understand what you mean by "if each
>>> flash in its own package."
>>>
>>
>> There are flashes that are stacked at the physical level. It's a single flash with
>> multiple dies, that are all under a single physical package.
> 
> Got it. The W25H02JV QSPI flash I mentioned earlier is a device with 
> with four dies that are stacked at the physical level.
> 
>>
>> As I understand, your stacked flash model is at logical level. You have
>> 2 flashes each in its own package. 2 different entities. Is my understanding
>> correct?
> 
> Yes, that?s correct.
> 
> I'd like to contribute to your earlier point regarding the placement of 
> the stacked layer. As you correctly highlighted, it should be in the 
> spi-mem generic layer. For instance, when a read/write operation extends 
> across multiple flashes (whether SPI-NOR or SPI-NAND), the stacked layer 
> must handle the flash crossover. This requires setting the appropriate CS 
> index in mem->spi->cs_index_mask to select the correct slave device and 
> updating the data buffer, address & data length in spi_mem_op struct 
> variable. Does this align with your understanding?
> 

This was the initial idea, yes, but we'll have to see how mtd concat
fits in. Maybe the abstraction can be made at the mtd level, which I
suspect mtd concat does. I have to read that driver, never opened it.

Something else to consider: I see that Micron has a twin quad mode:
https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25t/generation-b/mt25t_qljs_l_512_xba_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500

The micron's "Separate Chip-Select and Clock Signals" resembles the
AMD's dual parallel 8-bit.
Micron's "Shared Chip-Select and Clock Signals" differs from the AMD's
stacked mode, as Micron uses DQ[3:0] and DQ[7:4], whereas AMD considers
both as DQ[3:0].

I had a short chat with Michael and he highlighted that instead of the
parallel mode, one would be better of with an octal device. I wonder
whether the quad parallel is worth the effort. I see AMD can select
either quad (single/stacked/parallel) or octal (single/stacked). Is the
parallel mode considered obsolete for new IPs?

Cheers,
ta


From ryan.roberts at arm.com  Tue Dec 19 00:30:11 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 19 Dec 2023 08:30:11 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
Message-ID: <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>

On 18/12/2023 17:47, David Hildenbrand wrote:
> On 18.12.23 11:50, Ryan Roberts wrote:
>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>> batch is determined by the architecture with the new helper,
>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>> all belonging to the same folio. A pte batch is then write-protected in
>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>> set in one go in the child using the new helper, set_ptes_full().
>>
>> The primary motivation for this change is to reduce the number of tlb
>> maintenance operations that the arm64 backend has to perform during
>> fork, as it is about to add transparent support for the "contiguous bit"
>> in its ptes. By write-protecting the parent using the new
>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>> when all ptes in the range are being write-protected. Similarly, by
>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>> child, the backend does not need to fold a contiguous range once they
>> are all populated - they can be initially populated as a contiguous
>> range in the first place.
>>
>> This code is very performance sensitive, and a significant amount of
>> effort has been put into not regressing performance for the order-0
>> folio case. By default, pte_batch_remaining() is compile constant 1,
>> which enables the compiler to simplify the extra loops that are added
>> for batching and produce code that is equivalent (and equally
>> performant) as the previous implementation.
>>
>> This change addresses the core-mm refactoring only and a separate change
>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>> set_ptes_full() in the arm64 backend to realize the performance
>> improvement as part of the work to enable contpte mappings.
>>
>> To ensure the arm64 is performant once implemented, this change is very
>> careful to only call ptep_get() once per pte batch.
>>
>> The following microbenchmark results demonstate that there is no
>> significant performance change after this patch. Fork is called in a
>> tight loop in a process with 1G of populated memory and the time for the
>> function to execute is measured. 100 iterations per run, 8 runs
>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>> performed for case where 1G memory is comprised of order-0 folios and
>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>> positive is slower, compared to baseline upon which the series is based:
>>
>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>> | fork????????? |-------------------|-------------------|
>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>> |---------------|---------|---------|---------|---------|
>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>
>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>> | fork????????? |-------------------|-------------------|
>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>> |---------------|---------|---------|---------|---------|
>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>
>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
>> ? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>> ? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>> ? 2 files changed, 139 insertions(+), 33 deletions(-)
>>
>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>> index af7639c3b0a3..db93fb81465a 100644
>> --- a/include/linux/pgtable.h
>> +++ b/include/linux/pgtable.h
>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>> ? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>> ? #endif
>> ? +#ifndef pte_batch_remaining
>> +/**
>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>> + * @pte: Page table entry for the first page.
>> + * @addr: Address of the first page.
>> + * @end: Batch ceiling (e.g. end of vma).
>> + *
>> + * Some architectures (arm64) can efficiently modify a contiguous batch of ptes.
>> + * In such cases, this function returns the remaining number of pages to the end
>> + * of the current batch, as defined by addr. This can be useful when iterating
>> + * over ptes.
>> + *
>> + * May be overridden by the architecture, else batch size is always 1.
>> + */
>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long addr,
>> +??????????????????????? unsigned long end)
>> +{
>> +??? return 1;
>> +}
>> +#endif
> 
> It's a shame we now lose the optimization for all other archtiectures.
> 
> Was there no way to have some basic batching mechanism that doesn't require arch
> specifics?

I tried a bunch of things but ultimately the way I've done it was the only way
to reduce the order-0 fork regression to 0.

My original v3 posting was costing 5% extra and even my first attempt at an
arch-specific version that didn't resolve to a compile-time constant 1 still
cost an extra 3%.


> 
> I'd have thought that something very basic would have worked like:
> 
> * Check if PTE is the same when setting the PFN to 0.
> * Check that PFN is consecutive
> * Check that all PFNs belong to the same folio

I haven't tried this exact approach, but I'd be surprised if I can get the
regression under 4% with this. Further along the series I spent a lot of time
having to fiddle with the arm64 implementation; every conditional and every
memory read (even when in cache) was a problem. There is just so little in the
inner loop that every instruction matters. (At least on Ampere Altra and Apple M2).

Of course if you're willing to pay that 4-5% for order-0 then the benefit to
order-9 is around 10% in my measurements. Personally though, I'd prefer to play
safe and ensure the common order-0 case doesn't regress, as you previously
suggested.



From norbert.karecki at quirkbyte.pl  Tue Dec 19 00:35:09 2023
From: norbert.karecki at quirkbyte.pl (Norbert Karecki)
Date: Tue, 19 Dec 2023 08:35:09 GMT
Subject: Fotowoltaika - propozycja instalacji
Message-ID: <20231219084500-0.1.9.279e.0.g0cbgli0ap@quirkbyte.pl>

Dzie? dobry,
 
Czy rozwa?ali Pa?stwo monta? systemu fotowoltaicznego?
 
Instalacja fotowoltaiczna jest najlepszym sposobem na obni?enie wysoko?ci rachunk?w za pr?d (pozostaj? tylko op?aty sta?e) i zabezpieczenie si? przed rosn?cymi cenami energii elektrycznej. Jest to w pe?ni odnawialne i bezemisyjne ?r?d?o energii, dzi?ki czemu przyczyniamy si? do ochrony ?rodowiska naturalnego.
 
Dzia?amy od wielu lat na rynku energetycznym. Przygotujemy projekt, wycen? oraz kompleksowo wykonamy i zg?osimy realizacj? do zak?adu energetycznego. 
 
Czy chc? Pa?stwo pozna? nasz? propozycj??  


Pozdrawiam
Norbert Karecki


From krzysztof.kozlowski at linaro.org  Tue Dec 19 00:48:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 09:48:07 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
Message-ID: <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>

On 19/12/2023 09:22, Jan Kiszka wrote:
>>
>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>
>> Ditto
>>
> 
> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
> not introducing new ones. We can add the color properties in a separate


Then why aren't you overriding by phandle/label?

> patch, but the node names are now part of the kernel ABI. Changing them
> would break existing userland.

You mean label. Why node names became the ABI? Which interface exposes them?

> 
>>
>>> +
>>> +&dwc3_0 {
>>> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
>>> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
>>> +	/delete-property/ phys;
>>> +	/delete-property/ phy-names;
>>
>> If your board need to remove phys from the SoC node, something is wrong.
>> Either your board or SoC.
>>
>> Any removal of properties in DTS is weird and unexpected. It deserves
>> comments.
> 
> This goes along disabling USB3 which is by default enabled via
> k3-am65-iot2050-common-pg2.dtsi

Isn't this mistake? Common part enables only these pieces which are
working in common hardware SoM. If your common part of hardware, which
DTSI should represent, has USB3 then why is it being disabled here? If
common hardware design does not have USB3, then why is it being enabled
in DTSI?
> 

Best regards,
Krzysztof



From kjain at linux.ibm.com  Tue Dec 19 00:48:41 2023
From: kjain at linux.ibm.com (kajoljain)
Date: Tue, 19 Dec 2023 14:18:41 +0530
Subject: [PATCH V3 1/7] perf mem: Add mem_events into the supported
 perf_pmu
In-Reply-To: <20231213195154.1085945-2-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
 <20231213195154.1085945-2-kan.liang@linux.intel.com>
Message-ID: <4b465a74-a991-3612-096c-18d430ea2734@linux.ibm.com>

Patch looks fine to me.

Reviewed-by: Kajol Jain<kjain at linux.ibm.com>
Tested-by: Kajol Jain<kjain at linux.ibm.com>

Thanks,
Kajol Jain

On 12/14/23 01:21, kan.liang at linux.intel.com wrote:
> From: Kan Liang <kan.liang at linux.intel.com>
> 
> With the mem_events, perf doesn't need to read sysfs for each PMU to
> find the mem-events-supported PMU. The patch also makes it possible to
> clean up the related __weak functions later.
> 
> The patch is only to add the mem_events into the perf_pmu for all ARCHs.
> It will be used in the later cleanup patches.
> 
> Reviewed-by: Ian Rogers <irogers at google.com>
> Tested-by: Ravi Bangoria <ravi.bangoria at amd.com>
> Suggested-by: Leo Yan <leo.yan at linaro.org>
> Signed-off-by: Kan Liang <kan.liang at linux.intel.com>
> ---
>  tools/perf/arch/arm/util/pmu.c          | 3 +++
>  tools/perf/arch/arm64/util/mem-events.c | 7 ++++---
>  tools/perf/arch/arm64/util/mem-events.h | 7 +++++++
>  tools/perf/arch/s390/util/pmu.c         | 3 +++
>  tools/perf/arch/x86/util/mem-events.c   | 4 ++--
>  tools/perf/arch/x86/util/mem-events.h   | 9 +++++++++
>  tools/perf/arch/x86/util/pmu.c          | 7 +++++++
>  tools/perf/util/mem-events.c            | 2 +-
>  tools/perf/util/mem-events.h            | 1 +
>  tools/perf/util/pmu.c                   | 4 +++-
>  tools/perf/util/pmu.h                   | 7 +++++++
>  11 files changed, 47 insertions(+), 7 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/mem-events.h
>  create mode 100644 tools/perf/arch/x86/util/mem-events.h
> 
> diff --git a/tools/perf/arch/arm/util/pmu.c b/tools/perf/arch/arm/util/pmu.c
> index 7f3af3b97f3b..8b7cb68ba1a8 100644
> --- a/tools/perf/arch/arm/util/pmu.c
> +++ b/tools/perf/arch/arm/util/pmu.c
> @@ -13,6 +13,7 @@
>  #include "hisi-ptt.h"
>  #include "../../../util/pmu.h"
>  #include "../../../util/cs-etm.h"
> +#include "../../arm64/util/mem-events.h"
>  
>  void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
>  {
> @@ -26,6 +27,8 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
>  		pmu->selectable = true;
>  		pmu->is_uncore = false;
>  		pmu->perf_event_attr_init_default = arm_spe_pmu_default_config;
> +		if (!strcmp(pmu->name, "arm_spe_0"))
> +			pmu->mem_events = perf_mem_events_arm;
>  	} else if (strstarts(pmu->name, HISI_PTT_PMU_NAME)) {
>  		pmu->selectable = true;
>  #endif
> diff --git a/tools/perf/arch/arm64/util/mem-events.c b/tools/perf/arch/arm64/util/mem-events.c
> index 3bcc5c7035c2..edf8207f7812 100644
> --- a/tools/perf/arch/arm64/util/mem-events.c
> +++ b/tools/perf/arch/arm64/util/mem-events.c
> @@ -1,10 +1,11 @@
>  // SPDX-License-Identifier: GPL-2.0
> -#include "map_symbol.h"
> +#include "util/map_symbol.h"
> +#include "util/mem-events.h"
>  #include "mem-events.h"
>  
>  #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>  
> -static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
> +struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX] = {
>  	E("spe-load",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=0,min_latency=%u/",	"arm_spe_0"),
>  	E("spe-store",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=0,store_filter=1/",			"arm_spe_0"),
>  	E("spe-ldst",	"arm_spe_0/ts_enable=1,pa_enable=1,load_filter=1,store_filter=1,min_latency=%u/",	"arm_spe_0"),
> @@ -17,7 +18,7 @@ struct perf_mem_event *perf_mem_events__ptr(int i)
>  	if (i >= PERF_MEM_EVENTS__MAX)
>  		return NULL;
>  
> -	return &perf_mem_events[i];
> +	return &perf_mem_events_arm[i];
>  }
>  
>  const char *perf_mem_events__name(int i, const char *pmu_name __maybe_unused)
> diff --git a/tools/perf/arch/arm64/util/mem-events.h b/tools/perf/arch/arm64/util/mem-events.h
> new file mode 100644
> index 000000000000..5fc50be4be38
> --- /dev/null
> +++ b/tools/perf/arch/arm64/util/mem-events.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ARM64_MEM_EVENTS_H
> +#define _ARM64_MEM_EVENTS_H
> +
> +extern struct perf_mem_event perf_mem_events_arm[PERF_MEM_EVENTS__MAX];
> +
> +#endif /* _ARM64_MEM_EVENTS_H */
> diff --git a/tools/perf/arch/s390/util/pmu.c b/tools/perf/arch/s390/util/pmu.c
> index 886c30e001fa..225d7dc2379c 100644
> --- a/tools/perf/arch/s390/util/pmu.c
> +++ b/tools/perf/arch/s390/util/pmu.c
> @@ -19,4 +19,7 @@ void perf_pmu__arch_init(struct perf_pmu *pmu)
>  	    !strcmp(pmu->name, S390_PMUPAI_EXT) ||
>  	    !strcmp(pmu->name, S390_PMUCPUM_CF))
>  		pmu->selectable = true;
> +
> +	if (pmu->is_core)
> +		pmu->mem_events = perf_mem_events;
>  }
> diff --git a/tools/perf/arch/x86/util/mem-events.c b/tools/perf/arch/x86/util/mem-events.c
> index 191b372f9a2d..2b81d229982c 100644
> --- a/tools/perf/arch/x86/util/mem-events.c
> +++ b/tools/perf/arch/x86/util/mem-events.c
> @@ -16,13 +16,13 @@ static char mem_stores_name[100];
>  
>  #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>  
> -static struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
> +struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX] = {
>  	E("ldlat-loads",	"%s/mem-loads,ldlat=%u/P",	"%s/events/mem-loads"),
>  	E("ldlat-stores",	"%s/mem-stores/P",		"%s/events/mem-stores"),
>  	E(NULL,			NULL,				NULL),
>  };
>  
> -static struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
> +struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX] = {
>  	E(NULL,		NULL,		NULL),
>  	E(NULL,		NULL,		NULL),
>  	E("mem-ldst",	"ibs_op//",	"ibs_op"),
> diff --git a/tools/perf/arch/x86/util/mem-events.h b/tools/perf/arch/x86/util/mem-events.h
> new file mode 100644
> index 000000000000..3959e427f482
> --- /dev/null
> +++ b/tools/perf/arch/x86/util/mem-events.h
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _X86_MEM_EVENTS_H
> +#define _X86_MEM_EVENTS_H
> +
> +extern struct perf_mem_event perf_mem_events_intel[PERF_MEM_EVENTS__MAX];
> +
> +extern struct perf_mem_event perf_mem_events_amd[PERF_MEM_EVENTS__MAX];
> +
> +#endif /* _X86_MEM_EVENTS_H */
> diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c
> index 469555ae9b3c..cd22e80e5657 100644
> --- a/tools/perf/arch/x86/util/pmu.c
> +++ b/tools/perf/arch/x86/util/pmu.c
> @@ -15,6 +15,7 @@
>  #include "../../../util/pmu.h"
>  #include "../../../util/fncache.h"
>  #include "../../../util/pmus.h"
> +#include "mem-events.h"
>  #include "env.h"
>  
>  void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
> @@ -30,6 +31,12 @@ void perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
>  		pmu->selectable = true;
>  	}
>  #endif
> +
> +	if (x86__is_amd_cpu()) {
> +		if (!strcmp(pmu->name, "ibs_op"))
> +			pmu->mem_events = perf_mem_events_amd;
> +	} else if (pmu->is_core)
> +		pmu->mem_events = perf_mem_events_intel;
>  }
>  
>  int perf_pmus__num_mem_pmus(void)
> diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
> index 3a2e3687878c..0a8f415f5efe 100644
> --- a/tools/perf/util/mem-events.c
> +++ b/tools/perf/util/mem-events.c
> @@ -19,7 +19,7 @@ unsigned int perf_mem_events__loads_ldlat = 30;
>  
>  #define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
>  
> -static struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
> +struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
>  	E("ldlat-loads",	"cpu/mem-loads,ldlat=%u/P",	"cpu/events/mem-loads"),
>  	E("ldlat-stores",	"cpu/mem-stores/P",		"cpu/events/mem-stores"),
>  	E(NULL,			NULL,				NULL),
> diff --git a/tools/perf/util/mem-events.h b/tools/perf/util/mem-events.h
> index b40ad6ea93fc..8c5694b2d0b0 100644
> --- a/tools/perf/util/mem-events.h
> +++ b/tools/perf/util/mem-events.h
> @@ -34,6 +34,7 @@ enum {
>  };
>  
>  extern unsigned int perf_mem_events__loads_ldlat;
> +extern struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX];
>  
>  int perf_mem_events__parse(const char *str);
>  int perf_mem_events__init(void);
> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index 3c9609944a2f..3d4373b8ab63 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -986,8 +986,10 @@ static int pmu_max_precise(int dirfd, struct perf_pmu *pmu)
>  }
>  
>  void __weak
> -perf_pmu__arch_init(struct perf_pmu *pmu __maybe_unused)
> +perf_pmu__arch_init(struct perf_pmu *pmu)
>  {
> +	if (pmu->is_core)
> +		pmu->mem_events = perf_mem_events;
>  }
>  
>  struct perf_pmu *perf_pmu__lookup(struct list_head *pmus, int dirfd, const char *name)
> diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
> index 424c3fee0949..e35d985206db 100644
> --- a/tools/perf/util/pmu.h
> +++ b/tools/perf/util/pmu.h
> @@ -10,6 +10,8 @@
>  #include <stdio.h>
>  #include "parse-events.h"
>  #include "pmu-events/pmu-events.h"
> +#include "map_symbol.h"
> +#include "mem-events.h"
>  
>  struct evsel_config_term;
>  struct perf_cpu_map;
> @@ -162,6 +164,11 @@ struct perf_pmu {
>  		 */
>  		bool exclude_guest;
>  	} missing_features;
> +
> +	/**
> +	 * @mem_events: List of the supported mem events
> +	 */
> +	struct perf_mem_event *mem_events;
>  };
>  
>  /** @perf_pmu__fake: A special global PMU used for testing. */


From tomi.valkeinen at ideasonboard.com  Tue Dec 19 00:50:05 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 19 Dec 2023 10:50:05 +0200
Subject: [PATCH 2/2] media: rkisp1: Fix IRQ handling due to shared
 interrupts
In-Reply-To: <20231218092240.GB26540@pendragon.ideasonboard.com>
References: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>
 <20231218-rkisp-shirq-fix-v1-2-173007628248@ideasonboard.com>
 <20231218092240.GB26540@pendragon.ideasonboard.com>
Message-ID: <b465355b-65c2-451f-ae2e-63da9d0a6282@ideasonboard.com>

On 18/12/2023 11:22, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Mon, Dec 18, 2023 at 09:54:01AM +0200, Tomi Valkeinen wrote:
>> The driver requests the interrupts as IRQF_SHARED, so the interrupt
>> handlers can be called at any time. If such a call happens while the ISP
>> is powered down, the SoC will hang as the driver tries to access the
>> ISP registers.
>>
>> This can be reproduced even without the platform sharing the IRQ line:
>> Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will
>> hang.
>>
>> Fix this by adding a new field, 'irqs_enabled', which is used to bail
>> out from the interrupt handler when the ISP is not operational.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>> ---
>>   .../platform/rockchip/rkisp1/rkisp1-capture.c      |  3 +++
>>   .../media/platform/rockchip/rkisp1/rkisp1-common.h |  2 ++
>>   .../media/platform/rockchip/rkisp1/rkisp1-csi.c    |  3 +++
>>   .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 22 ++++++++++++++++++++++
>>   .../media/platform/rockchip/rkisp1/rkisp1-isp.c    |  3 +++
>>   5 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
>> index aebd3c12020b..c381c22135a2 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
>> @@ -725,6 +725,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
>>   	unsigned int i;
>>   	u32 status;
>>   
>> +	if (!rkisp1->irqs_enabled)
>> +		return IRQ_NONE;
> 
> Given that this is something all drivers that use shared IRQs have to
> do, would it make sense to use a standard helper here, such as
> pm_runtime_suspended() for instance ? I haven't looked at which one
> would be the most appropriate (if any), there's also
> pm_runtime_active() and pm_runtime_status_suspended(). That would
> simplify this patch.

I did consider that when writing the patch. But I just wasn't very 
comfortable using the runtime PM here, even if it would make sense, as 
I'm just not quite sure how it works.

For example, pm_runtime_suspended() checks if the device is in 
RPM_SUSPENDED state, and the device will be in RPM_SUSPENDED after the 
driver's suspend callback has finished. This makes sense.

However, _while_ suspending (not after we have suspended), we want to 
make sure that 1) no new irq handling will start, 2) we'll wait until 
any currently running irq handler has finished. For 1), we can't use 
pm_runtime_suspended() in the irq handler, as the status is not 
RPM_SUSPENDED. We could probably check for:

spin_lock(&dev->power.lock);
off = dev->power.runtime_status == RPM_SUSPENDED || 
dev->power.runtime_status == RPM_SUSPENDING;
spin_unlock(&dev->power.lock);
if (off)
	return IRQ_NONE;

That would not work if we would depend on the irq handling while in the 
suspend callback (e.g. waiting for an irq which signals that the device 
has finished processing). But we don't do that at the moment, and that 
kind of this probably can usually be done before calling runtime_put().

When we take into account the resume part, I think we could just check 
for RPM_ACTIVE in the irq handler, which would then rule out 
RPM_RESUMING, RPM_SUSPENDED and RPM_SUSPENDING.

But we can't use pm_runtime_active(), as that also checks for 
dev->power.disable_depth. In other words, when we disable the PM for our 
device (e.g. when unloading the driver), the PM framework says our 
device became active.

Soo... I think this should work in the irq handler:

spin_lock(&dev->power.lock);
active = dev->power.runtime_status == RPM_ACTIVE;
spin_unlock(&dev->power.lock);
if (!active)
	return IRQ_NONE;

I think the driver depends on runtime PM, but if no-PM was an option, I 
guess we'd need to ifdef the above away, and trust that the device is 
always powered on.

So, as I said in the beginning, "I just wasn't very comfortable using 
the runtime PM here". And that's still the case =). The runtime PM is 
horribly complex. If you think the above is clearer, and you think it's 
correct, I can make the change.

  Tomi

> 
>> +
>>   	status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
>>   	if (!status)
>>   		return IRQ_NONE;
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
>> index 4b6b28c05b89..b757f75edecf 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
>> @@ -450,6 +450,7 @@ struct rkisp1_debug {
>>    * @debug:	   debug params to be exposed on debugfs
>>    * @info:	   version-specific ISP information
>>    * @irqs:          IRQ line numbers
>> + * @irqs_enabled:  the hardware is enabled and can cause interrupts
>>    */
>>   struct rkisp1_device {
>>   	void __iomem *base_addr;
>> @@ -471,6 +472,7 @@ struct rkisp1_device {
>>   	struct rkisp1_debug debug;
>>   	const struct rkisp1_info *info;
>>   	int irqs[RKISP1_NUM_IRQS];
>> +	bool irqs_enabled;
>>   };
>>   
>>   /*
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>> index b6e47e2f1b94..4202642e0523 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>> @@ -196,6 +196,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
>>   	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>>   	u32 val, status;
>>   
>> +	if (!rkisp1->irqs_enabled)
>> +		return IRQ_NONE;
>> +
>>   	status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
>>   	if (!status)
>>   		return IRQ_NONE;
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>> index acc559652d6e..73cf08a74011 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>> @@ -305,6 +305,24 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
>>   {
>>   	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>>   
>> +	rkisp1->irqs_enabled = false;
>> +	/* Make sure the IRQ handler will see the above */
>> +	mb();
>> +
>> +	/*
>> +	 * Wait until any running IRQ handler has returned. The IRQ handler
>> +	 * may get called even after this (as it's a shared interrupt line)
>> +	 * but the 'irqs_enabled' flag will make the handler return immediately.
>> +	 */
>> +	for (unsigned int il = 0; il < ARRAY_SIZE(rkisp1->irqs); ++il) {
>> +		if (rkisp1->irqs[il] == -1)
>> +			continue;
>> +
>> +		/* Skip if the irq line is the same as previous */
>> +		if (il == 0 || rkisp1->irqs[il - 1] != rkisp1->irqs[il])
>> +			synchronize_irq(rkisp1->irqs[il]);
>> +	}
>> +
>>   	clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
>>   	return pinctrl_pm_select_sleep_state(dev);
>>   }
>> @@ -321,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
>>   	if (ret)
>>   		return ret;
>>   
>> +	rkisp1->irqs_enabled = true;
>> +	/* Make sure the IRQ handler will see the above */
>> +	mb();
>> +
>>   	return 0;
>>   }
>>   
>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>> index f00873d31c42..78a1f7a1499b 100644
>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>> @@ -976,6 +976,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
>>   	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>>   	u32 status, isp_err;
>>   
>> +	if (!rkisp1->irqs_enabled)
>> +		return IRQ_NONE;
>> +
>>   	status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
>>   	if (!status)
>>   		return IRQ_NONE;
> 



From horms at kernel.org  Tue Dec 19 00:55:57 2023
From: horms at kernel.org (Simon Horman)
Date: Tue, 19 Dec 2023 08:55:57 +0000
Subject: [PATCH net-next v4 07/13] net: ethtool: Introduce a command to
 list PHYs on an interface
In-Reply-To: <20231215171237.1152563-8-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-8-maxime.chevallier@bootlin.com>
Message-ID: <20231219085557.GB811967@kernel.org>

On Fri, Dec 15, 2023 at 06:12:29PM +0100, Maxime Chevallier wrote:
> As we have the ability to track the PHYs connected to a net_device
> through the link_topology, we can expose this list to userspace. This
> allows userspace to use these identifiers for phy-specific commands and
> take the decision of which PHY to target by knowing the link topology.
> 
> Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list
> devices on only one interface.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>

Hi Maxime,

some minor feedback from my side.

> +static int ethnl_phy_parse_request(struct ethnl_req_info *req_base,
> +				   struct nlattr **tb)
> +{
> +	struct phy_req_info *req_info = PHY_REQINFO(req_base);
> +	struct phy_link_topology *topo = &req_base->dev->link_topo;
> +	struct phy_device_node *pdn;

nit: Please consider arranging local variables in reverse xmas tree order -
     longest line to shortest.

> +
> +	if (!req_base->phydev)
> +		return 0;
> +
> +	pdn = xa_load(&topo->phys, req_base->phydev->phyindex);
> +	memcpy(&req_info->pdn, pdn, sizeof(*pdn));
> +
> +	return 0;
> +}

...

> +static int ethnl_phy_dump_one_dev(struct sk_buff *skb, struct net_device *dev,
> +				  struct netlink_callback *cb)
> +{
> +	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
> +	struct phy_req_info *pri = ctx->phy_req_info;
> +	struct phy_device_node *pdn;
> +	unsigned long index = 1;
> +	void *ehdr;
> +	int ret;
> +
> +	pri->base.dev = dev;
> +
> +	xa_for_each(&dev->link_topo.phys, index, pdn) {
> +		ehdr = ethnl_dump_put(skb, cb,
> +				      ETHTOOL_MSG_PHY_GET_REPLY);
> +		if (!ehdr) {
> +			ret = -EMSGSIZE;
> +			break;
> +		}
> +
> +		ret = ethnl_fill_reply_header(skb, dev,
> +					      ETHTOOL_A_PHY_HEADER);
> +		if (ret < 0) {
> +			genlmsg_cancel(skb, ehdr);
> +			break;
> +		}
> +
> +		memcpy(&pri->pdn, pdn, sizeof(*pdn));
> +		ret = ethnl_phy_fill_reply(&pri->base, skb);
> +
> +		genlmsg_end(skb, ehdr);
> +	}
> +
> +	return ret;

I'm unsure if it can happen, but if the loop runs zero times then
ret will be used uninitialised here.

Flagged by Smatch.

> +}

...


From andrew at lunn.ch  Tue Dec 19 00:58:15 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 19 Dec 2023 09:58:15 +0100
Subject: [PATCH v4 6/9] riscv: dts: starfive: visionfive-v1: Setup
 ethernet phy
In-Reply-To: <20231218214451.2345691-7-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <20231218214451.2345691-7-cristian.ciocaltea@collabora.com>
Message-ID: <962691a4-993d-44c0-861f-d0fd5bbc2da9@lunn.ch>

On Mon, Dec 18, 2023 at 11:44:46PM +0200, Cristian Ciocaltea wrote:
> The StarFive VisionFive V1 SBC uses a Motorcomm YT8521 PHY supporting
> RGMII-ID, but requires manual adjustment of the RX internal delay to
> work properly.
> 
> The default RX delay provided by the driver is 1.95 ns, which proves to
> be too high. Applying a 50% reduction seems to mitigate the issue.
> 
> Also note this adjustment is not necessary on BeagleV Starlight SBC,
> which uses a Microchip PHY.  Hence, there is no indication of a
> misbehaviour on the GMAC side, but most likely the issue stems from
> the Motorcomm PHY.
> 
> While at it, drop the redundant gpio include, which is already provided
> by jh7100-common.dtsi.
> 
> Co-developed-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
> Signed-off-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From horms at kernel.org  Tue Dec 19 00:58:51 2023
From: horms at kernel.org (Simon Horman)
Date: Tue, 19 Dec 2023 08:58:51 +0000
Subject: [PATCH net-next v4 13/13] Documentation: networking: document
 phy_link_topology
In-Reply-To: <20231215171237.1152563-14-maxime.chevallier@bootlin.com>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
 <20231215171237.1152563-14-maxime.chevallier@bootlin.com>
Message-ID: <20231219085851.GC811967@kernel.org>

On Fri, Dec 15, 2023 at 06:12:35PM +0100, Maxime Chevallier wrote:

...

> +UAPI
> +====
> +
> +There exist a set of netlink commands to query the link topology from userspace,
> +see ``Documentation/networking/ethtool-netlink.rst``.
> +
> +The whole point of having a topology representation is to assign the phyindex
> +field in :c:type:`struct phy_device <phy_device>`. This index is reported to
> +userspace using the ``ETHTOOL_MSG_PHY_GET`` ethtnl command. Performing a DUMP operation
> +will result in all PHYs from all net_device being listed. The DUMP command
> +accepts either a ``ETHTOOL_A_HEADER_DEV_INDEX`` or ``ETHTOOL_A_HEADER_DEV_NAME``
> +to be passed in the request to filter the DUMP to a single net_device.
> +
> +The retrieved index can then be passed as a request parameter using the
> +``ETHTOOL_A_HEADER_PHY_INDEX`` field in the following ethnl commands :
> +
> +* ``ETHTOOL_MSG_STRSET_GET`` to get the stats strig set from a given PHY

string

> +* ``ETHTOOL_MSG_CABLE_TEST_ACT`` and ``ETHTOOL_MSG_CABLE_TEST_ACT``, to perform
> +  cable testing on a given PHY on the link (most likely the outermost PHY)
> +* ``ETHTOOL_MSG_PSE_SET`` and ``ETHTOOL_MSG_PSE_GET`` for PHY-controlled PoE and PSE settings
> +* ``ETHTOOL_MSG_PLCA_GET_CFG``, ``ETHTOOL_MSG_PLCA_SET_CFG`` and ``ETHTOOL_MSG_PLCA_GET_STATUS``
> +  to set the PLCA (Physical Layer Collision Avoidance) parameters
> +
> +Note that the PHY index can be passed to other requests, which will silently
> +ignore it if present and irrelevant.
> -- 
> 2.43.0
> 


From alexander.stein at ew.tq-group.com  Tue Dec 19 01:02:48 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Tue, 19 Dec 2023 10:02:48 +0100
Subject: [PATCH 1/1] phy: freescale: phy-fsl-imx8-mipi-dphy: Fix alias name to use dashes
Message-ID: <20231219090248.3317500-1-alexander.stein@ew.tq-group.com>

Devicetree spec lists only dashes as valid characters for alias names.
Table 3.2: Valid characters for alias names, Devicee Specification,
Release v0.4

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
index e625b32889bf..0928a526e2ab 100644
--- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
+++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
@@ -706,7 +706,7 @@ static int mixel_dphy_probe(struct platform_device *pdev)
 			return ret;
 		}
 
-		priv->id = of_alias_get_id(np, "mipi_dphy");
+		priv->id = of_alias_get_id(np, "mipi-dphy");
 		if (priv->id < 0) {
 			dev_err(dev, "Failed to get phy node alias id: %d\n",
 				priv->id);
-- 
2.34.1



From andrew at lunn.ch  Tue Dec 19 01:03:09 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 19 Dec 2023 10:03:09 +0100
Subject: [PATCH v4 0/9] Enable networking support for StarFive JH7100 SoC
In-Reply-To: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
Message-ID: <a37d2df9-e593-476f-bfef-d9abaf063daa@lunn.ch>

On Mon, Dec 18, 2023 at 11:44:40PM +0200, Cristian Ciocaltea wrote:
> This patch series adds ethernet support for the StarFive JH7100 SoC and makes it
> available for the StarFive VisionFive V1 and BeagleV Starlight boards, although
> I could only validate on the former SBC.  Thank you Emil and Geert for helping
> with tests on BeagleV!

You will need to split this into patch sets per subsystem. The changes
to the stmmac driver can then go via netdev, and the rest via each
subsystem maintainer. It should then all meet in linux-next and work
there.

	Andrew


From jan.kiszka at siemens.com  Tue Dec 19 01:03:59 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 19 Dec 2023 10:03:59 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
Message-ID: <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>

On 19.12.23 09:48, Krzysztof Kozlowski wrote:
> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>
>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>
>>> Ditto
>>>
>>
>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>> not introducing new ones. We can add the color properties in a separate
> 
> 
> Then why aren't you overriding by phandle/label?
> 

We could do that as well if we added labels first (they don't exist so 
far). Not seeing any difference, though.

>> patch, but the node names are now part of the kernel ABI. Changing them
>> would break existing userland.
> 
> You mean label. Why node names became the ABI? Which interface exposes them?

root at iot2050-debian:~# ls -l /sys/class/leds/
total 0
lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus at 100000/4fa0000.mmc/leds/mmc0::
lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus at 100000/4f80000.mmc/leds/mmc1::
lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red

>>>> +
>>>> +&dwc3_0 {
>>>> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
>>>> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
>>>> +	/delete-property/ phys;
>>>> +	/delete-property/ phy-names;
>>>
>>> If your board need to remove phys from the SoC node, something is wrong.
>>> Either your board or SoC.
>>>
>>> Any removal of properties in DTS is weird and unexpected. It deserves
>>> comments.
>>
>> This goes along disabling USB3 which is by default enabled via
>> k3-am65-iot2050-common-pg2.dtsi
> 
> Isn't this mistake? Common part enables only these pieces which are
> working in common hardware SoM. If your common part of hardware, which
> DTSI should represent, has USB3 then why is it being disabled here? If
> common hardware design does not have USB3, then why is it being enabled
> in DTSI?

It's a trade-off between adding yet another dtsi for those widely 
common bits vs. adjusting the differences of only one variant from 
that. We do the same for the Display Port so far.

Jan

-- 
Siemens AG, Technology
Linux Expert Center



From andrew at lunn.ch  Tue Dec 19 01:04:19 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 19 Dec 2023 10:04:19 +0100
Subject: [PATCH v4 3/9] net: stmmac: dwmac-starfive: Add support for
 JH7100 SoC
In-Reply-To: <20231218214451.2345691-4-cristian.ciocaltea@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <20231218214451.2345691-4-cristian.ciocaltea@collabora.com>
Message-ID: <051463f6-3268-415e-bedc-6f35707a97f9@lunn.ch>

On Mon, Dec 18, 2023 at 11:44:43PM +0200, Cristian Ciocaltea wrote:
> Add a missing quirk to enable support for the StarFive JH7100 SoC.
> 
> Additionally, for greater flexibility in operation, allow using the
> rgmii-rxid and rgmii-txid phy modes.
> 
> Co-developed-by: Emil Renner Berthing <kernel at esmil.dk>
> Signed-off-by: Emil Renner Berthing <kernel at esmil.dk>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From andrew at lunn.ch  Tue Dec 19 01:09:24 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 19 Dec 2023 10:09:24 +0100
Subject: [PATCH 1/1] phy: freescale: phy-fsl-imx8-mipi-dphy: Fix alias
 name to use dashes
In-Reply-To: <20231219090248.3317500-1-alexander.stein@ew.tq-group.com>
References: <20231219090248.3317500-1-alexander.stein@ew.tq-group.com>
Message-ID: <b01e05ac-8b28-49ad-8a1e-9cd667e5f1ec@lunn.ch>

On Tue, Dec 19, 2023 at 10:02:48AM +0100, Alexander Stein wrote:
> Devicetree spec lists only dashes as valid characters for alias names.
> Table 3.2: Valid characters for alias names, Devicee Specification,
> Release v0.4
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> ---
>  drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> index e625b32889bf..0928a526e2ab 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> @@ -706,7 +706,7 @@ static int mixel_dphy_probe(struct platform_device *pdev)
>  			return ret;
>  		}
>  
> -		priv->id = of_alias_get_id(np, "mipi_dphy");
> +		priv->id = of_alias_get_id(np, "mipi-dphy");

Are there any in tree DT blobs using mipi_dphy which are going to
break because of this change?

	Andrew


From alexander.stein at ew.tq-group.com  Tue Dec 19 01:13:03 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Tue, 19 Dec 2023 10:13:03 +0100
Subject: [PATCH 1/1] phy: freescale: phy-fsl-imx8-mipi-dphy: Fix alias name to use dashes
In-Reply-To: <b01e05ac-8b28-49ad-8a1e-9cd667e5f1ec@lunn.ch>
References: <20231219090248.3317500-1-alexander.stein@ew.tq-group.com> <b01e05ac-8b28-49ad-8a1e-9cd667e5f1ec@lunn.ch>
Message-ID: <4858990.GXAFRqVoOG@steina-w>

Hi Andrew,

Am Dienstag, 19. Dezember 2023, 10:09:24 CET schrieb Andrew Lunn:
> On Tue, Dec 19, 2023 at 10:02:48AM +0100, Alexander Stein wrote:
> > Devicetree spec lists only dashes as valid characters for alias names.
> > Table 3.2: Valid characters for alias names, Devicee Specification,
> > Release v0.4
> > 
> > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> > ---
> > 
> >  drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c index
> > e625b32889bf..0928a526e2ab 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > @@ -706,7 +706,7 @@ static int mixel_dphy_probe(struct platform_device
> > *pdev)> 
> >  			return ret;
> >  		
> >  		}
> > 
> > -		priv->id = of_alias_get_id(np, "mipi_dphy");
> > +		priv->id = of_alias_get_id(np, "mipi-dphy");
> 
> Are there any in tree DT blobs using mipi_dphy which are going to
> break because of this change?

You are right, I should have mentioned that already.
The alias is only used when used on a combo-PHY, which is only i.MX8QXP. Up 
until now there is no DT node in-kernel which uses the fsl,imx8qxp-mipi-dphy 
compatible. So no there should be no blobs at all using the old alias name.

Best regards,
Alexander
-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
http://www.tq-group.com/




From quic_taozha at quicinc.com  Tue Dec 19 01:22:29 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Tue, 19 Dec 2023 17:22:29 +0800
Subject: [PATCH v3 3/8] coresight-tpdm: Add CMB dataset support
In-Reply-To: <f4ed3577-f78b-4b78-b306-8284ccb96043@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-4-git-send-email-quic_taozha@quicinc.com>
 <f4ed3577-f78b-4b78-b306-8284ccb96043@arm.com>
Message-ID: <8dcafd9a-ff90-439a-9337-fb957d2fcad1@quicinc.com>


On 12/18/2023 6:34 PM, Suzuki K Poulose wrote:
> On 21/11/2023 02:24, Tao Zhang wrote:
>> CMB (continuous multi-bit) is one of TPDM's dataset type. CMB subunit
>> can be enabled for data collection by writing 1 to the first bit of
>> CMB_CR register. This change is to add enable/disable function for
>> CMB dataset by writing CMB_CR register.
>>
>> Reviewed-by: James Clark <james.clark at arm.com>
>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
>> ---
>> ? drivers/hwtracing/coresight/coresight-tpdm.c | 31 ++++++++++++++++++++
>> ? drivers/hwtracing/coresight/coresight-tpdm.h |? 8 +++++
>> ? 2 files changed, 39 insertions(+)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>> index 97654aa4b772..c8bb38822e08 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>> @@ -131,6 +131,11 @@ static bool tpdm_has_dsb_dataset(struct 
>> tpdm_drvdata *drvdata)
>> ????? return (drvdata->datasets & TPDM_PIDR0_DS_DSB);
>> ? }
>> ? +static bool tpdm_has_cmb_dataset(struct tpdm_drvdata *drvdata)
>> +{
>> +??? return (drvdata->datasets & TPDM_PIDR0_DS_CMB);
>> +}
>> +
>> ? static umode_t tpdm_dsb_is_visible(struct kobject *kobj,
>> ???????????????????? struct attribute *attr, int n)
>> ? {
>> @@ -267,6 +272,17 @@ static void tpdm_enable_dsb(struct tpdm_drvdata 
>> *drvdata)
>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>> ? }
>> ? +static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>> +{
>> +??? u32 val;
>> +
>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>> +??? val |= TPDM_CMB_CR_ENA;
>> +
>> +??? /* Set the enable bit of CMB control register to 1 */
>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
>> +}
>> +
>> ? /*
>> ?? * TPDM enable operations
>> ?? * The TPDM or Monitor serves as data collection component for various
>> @@ -281,6 +297,8 @@ static void __tpdm_enable(struct tpdm_drvdata 
>> *drvdata)
>> ? ????? if (tpdm_has_dsb_dataset(drvdata))
>> ????????? tpdm_enable_dsb(drvdata);
>> +??? if (tpdm_has_cmb_dataset(drvdata))
>> +??????? tpdm_enable_cmb(drvdata);
>
> Don't we need to add this check in the "property read" section ?
> Otherwise, we could generate warnings unnecessarily ?
>
> i.e, if (tpdm_has_cmb_..())
> ????? rc |= fwnode_..read_property(cmb-elem-size...)
>
> Similarly for DSB.

TPDM and TPDA are two independent hardware. If you want to modify them 
in this way, the

two independent drivers will be coupled to each other. At the same time, 
this configuration

is manually set in the devicetree by the users, and this check cannot 
avoid manual setting errors.

 ?Even if the configuration is wrong, it will not cause the driver to 
stop working, it will only cause

the data to be lost from the TPDM.

>
>> ????? CS_LOCK(drvdata->base);
>> ? }
>> @@ -314,6 +332,17 @@ static void tpdm_disable_dsb(struct tpdm_drvdata 
>> *drvdata)
>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>> ? }
>> ? +static void tpdm_disable_cmb(struct tpdm_drvdata *drvdata)
>> +{
>> +??? u32 val;
>> +
>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>> +??? val &= ~TPDM_CMB_CR_ENA;
>> +
>> +??? /* Set the enable bit of CMB control register to 0 */
>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
>> +}
>> +
>> ? /* TPDM disable operations */
>> ? static void __tpdm_disable(struct tpdm_drvdata *drvdata)
>> ? {
>> @@ -321,6 +350,8 @@ static void __tpdm_disable(struct tpdm_drvdata 
>> *drvdata)
>> ? ????? if (tpdm_has_dsb_dataset(drvdata))
>> ????????? tpdm_disable_dsb(drvdata);
>> +??? if (tpdm_has_cmb_dataset(drvdata))
>> +??????? tpdm_disable_cmb(drvdata);
>
> minor nit: Instead of having these :
>
> ????if (tpdm_has_XY_()
> ??????? tpdm_{enable/disable}_XY_()
> I prefer :
>
> ????tpdm_{enable/disable}_XY_
>
> and the helper take care of returning early if the feature is
> not present.
Does the following sample modification meet your expectation?
static void tpdm_disable_dsb(struct tpdm_drvdata *drvdata)
{
 ?? ?u32 val;

 ?? ?if (tpdm_has_dsb_dataset(drvdata)) {
 ?? ???? /* Set the enable bit of DSB control register to 0 */
 ?? ???? val = readl_relaxed(drvdata->base + TPDM_DSB_CR);
 ?? ???? val &= ~TPDM_DSB_CR_ENA;
 ?? ???? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
 ?? ?}
}

static void tpdm_disable_cmb(struct tpdm_drvdata *drvdata)
{
 ?? ?u32 val;

 ?? ?if (tpdm_has_cmb_dataset(drvdata)) {
 ?? ???? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
 ?? ???? val &= ~TPDM_CMB_CR_ENA;

 ?? ???? /* Set the enable bit of CMB control register to 0 */
 ?? ???? writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
 ?? ?}
}

/* TPDM disable operations */
static void __tpdm_disable(struct tpdm_drvdata *drvdata)
{
 ?? ?CS_UNLOCK(drvdata->base);

 ?? ?tpdm_disable_dsb(drvdata);
 ?? ?tpdm_disable_cmb(drvdata);

 ?? ?CS_LOCK(drvdata->base);

}


Best,

Tao

>
>
> Suzuki
>
>
>> ? ????? CS_LOCK(drvdata->base);
>> ? }
>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>> index 4115b2a17b8d..0098c58dfdd6 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>> @@ -9,6 +9,12 @@
>> ? /* The max number of the datasets that TPDM supports */
>> ? #define TPDM_DATASETS?????? 7
>> ? +/* CMB Subunit Registers */
>> +#define TPDM_CMB_CR??????? (0xA00)
>> +
>> +/* Enable bit for CMB subunit */
>> +#define TPDM_CMB_CR_ENA??????? BIT(0)
>> +
>> ? /* DSB Subunit Registers */
>> ? #define TPDM_DSB_CR??????? (0x780)
>> ? #define TPDM_DSB_TIER??????? (0x784)
>> @@ -79,10 +85,12 @@
>> ?? *
>> ?? * PERIPHIDR0[0] : Fix to 1 if ImplDef subunit present, else 0
>> ?? * PERIPHIDR0[1] : Fix to 1 if DSB subunit present, else 0
>> + * PERIPHIDR0[2] : Fix to 1 if CMB subunit present, else 0
>> ?? */
>> ? ? #define TPDM_PIDR0_DS_IMPDEF??? BIT(0)
>> ? #define TPDM_PIDR0_DS_DSB??? BIT(1)
>> +#define TPDM_PIDR0_DS_CMB??? BIT(2)
>> ? ? #define TPDM_DSB_MAX_LINES??? 256
>> ? /* MAX number of EDCR registers */
>


From kjain at linux.ibm.com  Tue Dec 19 01:26:27 2023
From: kjain at linux.ibm.com (kajoljain)
Date: Tue, 19 Dec 2023 14:56:27 +0530
Subject: [PATCH V3 0/7] Clean up perf mem
In-Reply-To: <20231213195154.1085945-1-kan.liang@linux.intel.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
Message-ID: <a0abfee5-4dcd-3eb5-82fe-1a0dcdade038@linux.ibm.com>

Hi,
  I was trying to test this patchset on powerpc.

After applying it on top of acme's perf-tools-next branch, I am getting
below error:

  INSTALL libsubcmd_headers
  INSTALL libperf_headers
  INSTALL libsymbol_headers
  INSTALL libapi_headers
  INSTALL libbpf_headers
  CC      arch/powerpc/util/mem-events.o
In file included from arch/powerpc/util/mem-events.c:3:
arch/powerpc/util/mem-events.h:5:52: error: ?PERF_MEM_EVENTS__MAX?
undeclared here (not in a function)
    5 | extern struct perf_mem_event
perf_mem_events_power[PERF_MEM_EVENTS__MAX];
      |
^~~~~~~~~~~~~~~~~~~~
make[6]: *** [/home/kajol/linux/tools/build/Makefile.build:105:
arch/powerpc/util/mem-events.o] Error 1
make[5]: *** [/home/kajol/linux/tools/build/Makefile.build:158: util]
Error 2
make[4]: *** [/home/kajol/linux/tools/build/Makefile.build:158: powerpc]
Error 2
make[3]: *** [/home/kajol/linux/tools/build/Makefile.build:158: arch]
Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile.perf:693: perf-in.o] Error 2
make[1]: *** [Makefile.perf:251: sub-make] Error 2
make: *** [Makefile:70: all] Error 2

It seems some headerfiles are missing from arch/powerpc/util/mem-
events.c

Thanks,
Kajol Jain

On 12/14/23 01:21, kan.liang at linux.intel.com wrote:
> From: Kan Liang <kan.liang at linux.intel.com>
> 
> Changes since V2:
> - Fix the Arm64 building error (Leo)
> - Add two new patches to clean up perf_mem_events__record_args()
>   and perf_pmus__num_mem_pmus() (Leo)
> 
> Changes since V1:
> - Fix strcmp of PMU name checking (Ravi)
> - Fix "/," typo (Ian)
> - Rename several functions with perf_pmu__mem_events prefix. (Ian)
> - Fold the header removal patch into the patch where the cleanups made.
>   (Arnaldo)
> - Add reviewed-by and tested-by from Ian and Ravi
> 
> As discussed in the below thread, the patch set is to clean up perf mem.
> https://lore.kernel.org/lkml/afefab15-cffc-4345-9cf4-c6a4128d4d9c at linux.intel.com/
> 
> Introduce generic functions perf_mem_events__ptr(),
> perf_mem_events__name() ,and is_mem_loads_aux_event() to replace the
> ARCH specific ones.
> Simplify the perf_mem_event__supported().
> 
> Only keeps the ARCH-specific perf_mem_events array in the corresponding
> mem-events.c for each ARCH.
> 
> There is no functional change.
> 
> The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
> etc. But I can only test it on two Intel platforms.
> Please give it try, if you have machines with other ARCHs.
> 
> Here are the test results:
> Intel hybrid machine:
> 
> $perf mem record -e list
> ldlat-loads  : available
> ldlat-stores : available
> 
> $perf mem record -e ldlat-loads -v --ldlat 50
> calling: record -e cpu_atom/mem-loads,ldlat=50/P -e cpu_core/mem-loads,ldlat=50/P
> 
> $perf mem record -v
> calling: record -e cpu_atom/mem-loads,ldlat=30/P -e cpu_atom/mem-stores/P -e cpu_core/mem-loads,ldlat=30/P -e cpu_core/mem-stores/P
> 
> $perf mem record -t store -v
> calling: record -e cpu_atom/mem-stores/P -e cpu_core/mem-stores/P
> 
> 
> Intel SPR:
> $perf mem record -e list
> ldlat-loads  : available
> ldlat-stores : available
> 
> $perf mem record -e ldlat-loads -v --ldlat 50
> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=50/}:P
> 
> $perf mem record -v
> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=30/}:P -e cpu/mem-stores/P
> 
> $perf mem record -t store -v
> calling: record -e cpu/mem-stores/P
> 
> Kan Liang (7):
>   perf mem: Add mem_events into the supported perf_pmu
>   perf mem: Clean up perf_mem_events__ptr()
>   perf mem: Clean up perf_mem_events__name()
>   perf mem: Clean up perf_mem_event__supported()
>   perf mem: Clean up is_mem_loads_aux_event()
>   perf mem: Clean up perf_mem_events__record_args()
>   perf mem: Clean up perf_pmus__num_mem_pmus()
> 
>  tools/perf/arch/arm/util/pmu.c            |   3 +
>  tools/perf/arch/arm64/util/mem-events.c   |  39 +---
>  tools/perf/arch/arm64/util/mem-events.h   |   7 +
>  tools/perf/arch/powerpc/util/mem-events.c |  13 +-
>  tools/perf/arch/powerpc/util/mem-events.h |   7 +
>  tools/perf/arch/powerpc/util/pmu.c        |  11 ++
>  tools/perf/arch/s390/util/pmu.c           |   3 +
>  tools/perf/arch/x86/util/mem-events.c     |  99 ++--------
>  tools/perf/arch/x86/util/mem-events.h     |  10 +
>  tools/perf/arch/x86/util/pmu.c            |  19 +-
>  tools/perf/builtin-c2c.c                  |  45 ++---
>  tools/perf/builtin-mem.c                  |  48 ++---
>  tools/perf/util/mem-events.c              | 217 +++++++++++++---------
>  tools/perf/util/mem-events.h              |  19 +-
>  tools/perf/util/pmu.c                     |   4 +-
>  tools/perf/util/pmu.h                     |   7 +
>  tools/perf/util/pmus.c                    |   6 -
>  tools/perf/util/pmus.h                    |   1 -
>  18 files changed, 278 insertions(+), 280 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/mem-events.h
>  create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
>  create mode 100644 tools/perf/arch/powerpc/util/pmu.c
>  create mode 100644 tools/perf/arch/x86/util/mem-events.h
> 


From neil.armstrong at linaro.org  Tue Dec 19 01:31:58 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Tue, 19 Dec 2023 10:31:58 +0100
Subject: (subset) [PATCH v4 0/3] reset: amlogic-c3: add reset driver
In-Reply-To: <170126076055.2880660.13057388884278592366.b4-ty@linaro.org>
References: <20230914064018.18790-1-zelong.dong@amlogic.com>
 <170126076055.2880660.13057388884278592366.b4-ty@linaro.org>
Message-ID: <e0d29b32-2302-4a2f-ba78-e76dd7b5e570@linaro.org>

Hi,

On 29/11/2023 13:26, Neil Armstrong wrote:
> Hi,
> 
> On Thu, 14 Sep 2023 14:40:15 +0800, zelong dong wrote:
>> From: Zelong Dong <zelong.dong at amlogic.com>
>>
>> This patchset adds Reset controller driver support for Amlogic C3 SoC.
>> The RESET registers count and offset for C3 Soc are same as S4 Soc.
>>
>> Changes since v1:
>> - remove Change-ID
>> - run scripts/checkpatch.pl and fix reported warnings
>> - sort dts node by base reg offset
>>
>> [...]
> 
> Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.8/arm64-dt)
> 
> [3/3] arm64: dts: amlogic: add reset controller for Amlogic C3 SoC
>        https://git.kernel.org/amlogic/c/a5468f5ea9a01acf29d02745abae7b82482989d4

I'll need to drop this patch from v6.8/arm64-dt since the amlogic,c3-reset.h is missing from
my tree, I'll postpone it to v6.9.

Thanks,
Neil

> 
> These changes has been applied on the intermediate git tree [1].
> 
> The v6.8/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
> for inclusion in their intermediate git branches in order to be sent to Linus during
> the next merge window, or sooner if it's a set of fixes.
> 
> In the cases of fixes, those will be merged in the current release candidate
> kernel and as soon they appear on the Linux master branch they will be
> backported to the previous Stable and Long-Stable kernels [2].
> 
> The intermediate git branches are merged daily in the linux-next tree [3],
> people are encouraged testing these pre-release kernels and report issues on the
> relevant mailing-lists.
> 
> If problems are discovered on those changes, please submit a signed-off-by revert
> patch followed by a corrective changeset.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> 



From yuzenghui at huawei.com  Tue Dec 19 01:32:22 2023
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Tue, 19 Dec 2023 17:32:22 +0800
Subject: [bug report] GICv4.1: vSGI remains pending across the guest reset
In-Reply-To: <ZYB_RKR5CqlVS-lV@linux.dev>
References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
 <87a5q983zc.wl-maz@kernel.org> <ZX8w1vfQzeXP5klL@linux.dev>
 <ZX8xLhFFqTXRFQtd@linux.dev> <878r5s8xvc.wl-maz@kernel.org>
 <ZYB_RKR5CqlVS-lV@linux.dev>
Message-ID: <7ed01ec1-76b1-cef9-05b8-2068f67e1c33@huawei.com>

On 2023/12/19 1:20, Oliver Upton wrote:

> Anyway, I'm happy with your fix. I'd like Kunkun to give it a go but
> either way I can pick it up for 6.7.

+1. When applying, feel free to add my

Reviewed-by: Zenghui Yu <yuzenghui at huawei.com>

and perhaps

Cc: stable at vger.kernel.org # 5.10+

Thanks,
Zenghui


From krzysztof.kozlowski at linaro.org  Tue Dec 19 01:45:22 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 10:45:22 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
Message-ID: <4ab88316-6168-4cbf-85eb-abd4945b809a@linaro.org>

On 19/12/2023 10:03, Jan Kiszka wrote:
> On 19.12.23 09:48, Krzysztof Kozlowski wrote:
>> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>>
>>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>>
>>>> Ditto
>>>>
>>>
>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>>> not introducing new ones. We can add the color properties in a separate
>>
>>
>> Then why aren't you overriding by phandle/label?
>>
> 
> We could do that as well if we added labels first (they don't exist so 
> far). Not seeing any difference, though.
> 
>>> patch, but the node names are now part of the kernel ABI. Changing them
>>> would break existing userland.
>>
>> You mean label. Why node names became the ABI? Which interface exposes them?
> 
> root at iot2050-debian:~# ls -l /sys/class/leds/


> total 0
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus at 100000/4fa0000.mmc/leds/mmc0::
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus at 100000/4f80000.mmc/leds/mmc1::
> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
> 
>>>>> +
>>>>> +&dwc3_0 {
>>>>> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
>>>>> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
>>>>> +	/delete-property/ phys;
>>>>> +	/delete-property/ phy-names;
>>>>
>>>> If your board need to remove phys from the SoC node, something is wrong.
>>>> Either your board or SoC.
>>>>
>>>> Any removal of properties in DTS is weird and unexpected. It deserves
>>>> comments.
>>>
>>> This goes along disabling USB3 which is by default enabled via
>>> k3-am65-iot2050-common-pg2.dtsi
>>
>> Isn't this mistake? Common part enables only these pieces which are
>> working in common hardware SoM. If your common part of hardware, which
>> DTSI should represent, has USB3 then why is it being disabled here? If
>> common hardware design does not have USB3, then why is it being enabled
>> in DTSI?
> 
> It's a trade-off between adding yet another dtsi for those widely 
> common bits vs. adjusting the differences of only one variant from 

You don't need to add one more DTSI to achieve proper architecture of
DTS/DTSI split.

> that. We do the same for the Display Port so far.

DTSI represents common piece of hardware, like SoM or re-usable blocks,
not trade-off.

Best regards,
Krzysztof



From romain.gantois at bootlin.com  Tue Dec 19 01:50:15 2023
From: romain.gantois at bootlin.com (Romain Gantois)
Date: Tue, 19 Dec 2023 10:50:15 +0100 (CET)
Subject: [PATCH net 0/1] Prevent DSA tags from breaking COE
In-Reply-To: <f4166144-4874-4b10-96f8-fc3e03f94904@lunn.ch>
References: <20231218162326.173127-1-romain.gantois@bootlin.com> <f4166144-4874-4b10-96f8-fc3e03f94904@lunn.ch>
Message-ID: <cdc38cdf-536c-c23b-46c1-abadf14001a2@bootlin.com>

On Mon, 18 Dec 2023, Andrew Lunn wrote:
...
> Probably a dumb question.... Does this COE also perform checksum
> validation on receive? Is it also getting confused by the DSA header?
> 
> You must of tested receive, so it works somehow, but i just wounder if
> something needs to be done to be on the safe side?

That's a good point, I just investigated the RX path a bit more and the MAC 
indeed has IP/TCP/UDP RX checksum offloading enabled. However, the 
external switch in my setup uses EDSA tags, which displace the "true" ethertype 
field to the end of the DSA header and replaces the "normal" ethertype with 
ETH_P_EDSA (0xdada). So to the MAC controller, the ethernet frame has an unknown 
ethertype, and so it doesn't see it as an IP frame at all. All of the 
ethtool counters related to IP stuff are at 0, which supports this.

This explains why checksum offloading doesn't break the RX path in my case. 
However, other maybe other DSA switches using different frame formats could 
cause different behavior? Considering this, I think it would be safer to change 
the dsa_breaks_tx_coe flag to a general dsa_breaks_coe flag. It makes sense to 
me to assume that if DSA tags break TX COE, then RX COE will also not work.

I'll take this into account when I send a v2.

Best Regards,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From krzysztof.kozlowski at linaro.org  Tue Dec 19 01:50:19 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 10:50:19 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
Message-ID: <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>

On 19/12/2023 10:03, Jan Kiszka wrote:
> On 19.12.23 09:48, Krzysztof Kozlowski wrote:
>> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>>
>>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>>
>>>> Ditto
>>>>
>>>
>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>>> not introducing new ones. We can add the color properties in a separate
>>
>>
>> Then why aren't you overriding by phandle/label?
>>
> 
> We could do that as well if we added labels first (they don't exist so 
> far). Not seeing any difference, though.

Confusion? Your code suggests new node, thus you got review like you got.

> 
>>> patch, but the node names are now part of the kernel ABI. Changing them
>>> would break existing userland.
>>
>> You mean label. Why node names became the ABI? Which interface exposes them?
> 
> root at iot2050-debian:~# ls -l /sys/class/leds/
> total 0
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus at 100000/4fa0000.mmc/leds/mmc0::
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus at 100000/4f80000.mmc/leds/mmc1::
> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red

I replied too fast previous and did not include answer here:

You have label for that... Somehow all these nodes are half-baked,
without all the expected properties and now you call node name as ABI.
The node name is not the ABI.

Best regards,
Krzysztof



From jan.kiszka at siemens.com  Tue Dec 19 01:54:35 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 19 Dec 2023 10:54:35 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
 <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
Message-ID: <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>

On 19.12.23 10:50, Krzysztof Kozlowski wrote:
> On 19/12/2023 10:03, Jan Kiszka wrote:
>> On 19.12.23 09:48, Krzysztof Kozlowski wrote:
>>> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>>>
>>>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>>>
>>>>> Ditto
>>>>>
>>>>
>>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>>>> not introducing new ones. We can add the color properties in a separate
>>>
>>>
>>> Then why aren't you overriding by phandle/label?
>>>
>>
>> We could do that as well if we added labels first (they don't exist so 
>> far). Not seeing any difference, though.
> 
> Confusion? Your code suggests new node, thus you got review like you got.
> 
>>
>>>> patch, but the node names are now part of the kernel ABI. Changing them
>>>> would break existing userland.
>>>
>>> You mean label. Why node names became the ABI? Which interface exposes them?
>>
>> root at iot2050-debian:~# ls -l /sys/class/leds/
>> total 0
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus at 100000/4fa0000.mmc/leds/mmc0::
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus at 100000/4f80000.mmc/leds/mmc1::
>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
> 
> I replied too fast previous and did not include answer here:
> 
> You have label for that... Somehow all these nodes are half-baked,
> without all the expected properties and now you call node name as ABI.
> The node name is not the ABI.

Well, existing userspace uses those names, and adding the properties
would break that interface. Now, does Linux do that?

Jan

-- 
Siemens AG, Technology
Linux Expert Center



From zajec5 at gmail.com  Tue Dec 19 01:55:04 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 19 Dec 2023 10:55:04 +0100
Subject: [PATCH 4/4] nvmem: layouts: add U-Boot env layout
In-Reply-To: <20231219085517.4b6ec4fc@xps-13>
References: <20231218133722.16150-1-zajec5@gmail.com>
 <20231218133722.16150-4-zajec5@gmail.com> <20231218152116.59d59bad@xps-13>
 <13bc621c-5fcb-4710-912c-06e3e80d7337@gmail.com>
 <20231219085517.4b6ec4fc@xps-13>
Message-ID: <ba8abaf6-6f16-4742-a3ea-ad00d4151698@gmail.com>

On 19.12.2023 08:55, Miquel Raynal wrote:
> Hi Rafa?,
> 
> zajec5 at gmail.com wrote on Mon, 18 Dec 2023 23:10:20 +0100:
> 
>> On 18.12.2023 15:21, Miquel Raynal wrote:
>>> Hi Rafa?,
>>>
>>> zajec5 at gmail.com wrote on Mon, 18 Dec 2023 14:37:22 +0100:
>>>    
>>>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>>>
>>>> This patch moves all generic (NVMEM devices independent) code from NVMEM
>>>> device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
>>>> code on top of it.
>>>>
>>>> Thanks to proper layout it's possible to support U-Boot env data stored
>>>> on any kind of NVMEM device.
>>>>
>>>> For backward compatibility with old DT bindings we need to keep old
>>>> NVMEM device driver functional. To avoid code duplication a parsing
>>>> function is exported and reused in it.
>>>>
>>>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
>>>> ---
>>>
>>> I have a couple of comments about the original driver which gets
>>> copy-pasted in the new layout driver, maybe you could clean these
>>> (the memory leak should be fixed before the migration so it can be
>>> backported easily, the others are just style so it can be done after, I
>>> don't mind).
>>>
>>> ...
>>>    
>>>> +int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
>>>> +		     enum u_boot_env_format format)
>>>> +{
>>>> +	size_t crc32_data_offset;
>>>> +	size_t crc32_data_len;
>>>> +	size_t crc32_offset;
>>>> +	size_t data_offset;
>>>> +	size_t data_len;
>>>> +	size_t dev_size;
>>>> +	uint32_t crc32;
>>>> +	uint32_t calc;
>>>> +	uint8_t *buf;
>>>> +	int bytes;
>>>> +	int err;
>>>> +
>>>> +	dev_size = nvmem_dev_size(nvmem);
>>>> +
>>>> +	buf = kcalloc(1, dev_size, GFP_KERNEL);
>>>
>>> Out of curiosity, why kcalloc(1,...) rather than kzalloc() ?
>>
>> I used kcalloc() initially as I didn't need buffer to be zeroed.
> 
> I think kcalloc() initializes the memory to zero.
> https://elixir.bootlin.com/linux/latest/source/include/linux/slab.h#L659
> 
> If you don't need it you can switch to kmalloc() instead, I don't mind,
> but kcalloc() is meant to be used with arrays, I don't see the point of
> using kcalloc() in this case.
> 
>>
>> I see that memory-allocation.rst however says:
>>   > And, to be on the safe side it's best to use routines that set memory to zero, like kzalloc().
>>
>> It's probably close to zero cost to zero that buffer so it could be kzalloc().
>>
>>
>>>> +	if (!buf) {
>>>> +		err = -ENOMEM;
>>>> +		goto err_out;
>>>
>>> We could directly return ENOMEM here I guess.
>>>    
>>>> +	}
>>>> +
>>>> +	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
>>>> +	if (bytes < 0)
>>>> +		return bytes;
>>>> +	else if (bytes != dev_size)
>>>> +		return -EIO;
>>>
>>> Don't we need to free buf in the above cases?
>>>    
>>>> +	switch (format) {
>>>> +	case U_BOOT_FORMAT_SINGLE:
>>>> +		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
>>>> +		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
>>>> +		data_offset = offsetof(struct u_boot_env_image_single, data);
>>>> +		break;
>>>> +	case U_BOOT_FORMAT_REDUNDANT:
>>>> +		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
>>>> +		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
>>>> +		data_offset = offsetof(struct u_boot_env_image_redundant, data);
>>>> +		break;
>>>> +	case U_BOOT_FORMAT_BROADCOM:
>>>> +		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
>>>> +		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
>>>> +		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
>>>> +		break;
>>>> +	}
>>>> +	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
>>>
>>> Looks a bit convoluted, any chances we can use intermediate variables
>>> to help decipher this?
>>>    
>>>> +	crc32_data_len = dev_size - crc32_data_offset;
>>>> +	data_len = dev_size - data_offset;
>>>> +
>>>> +	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
>>>> +	if (calc != crc32) {
>>>> +		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
>>>> +		err = -EINVAL;
>>>> +		goto err_kfree;
>>>> +	}
>>>> +
>>>> +	buf[dev_size - 1] = '\0';
>>>> +	err = u_boot_env_parse_cells(dev, nvmem, buf, data_offset, data_len);
>>>> +	if (err)
>>>> +		dev_err(dev, "Failed to add cells: %d\n", err);
>>>
>>> Please drop this error message, the only reason for which the function
>>> call would fail is apparently an ENOMEM case.
>>>    
>>>> +
>>>> +err_kfree:
>>>> +	kfree(buf);
>>>> +err_out:
>>>> +	return err;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(u_boot_env_parse);
>>>> +
>>>> +static int u_boot_env_add_cells(struct device *dev, struct nvmem_device *nvmem)
>>>> +{
>>>> +	const struct of_device_id *match;
>>>> +	struct device_node *layout_np;
>>>> +	enum u_boot_env_format format;
>>>> +
>>>> +	layout_np = of_nvmem_layout_get_container(nvmem);
>>>> +	if (!layout_np)
>>>> +		return -ENOENT;
>>>> +
>>>> +	match = of_match_node(u_boot_env_of_match_table, layout_np);
>>>> +	if (!match)
>>>> +		return -ENOENT;
>>>> +
>>>> +	format = (uintptr_t)match->data;
>>>
>>> In the core there is currently an unused helper called
>>> nvmem_layout_get_match_data() which does that. I think the original
>>> intent of this function was to be used in this driver, so depending on
>>> your preference, can you please either use it or remove it?
>>
>> The problem is that nvmem_layout_get_match_data() uses:
>> layout->dev.driver
> 
> I'm surprised .driver is unset. Well anyway, please either fix the core
> helper and use it or drop the core helper, because we have no user for
> it otherwise?

I believe it's because of a very minimalistic "nvmem_bus_type" bus
implementation.

 From a quick look it seems that default expected FORWARD-trace is:
driver_register()
bus_add_driver()
driver_attach()
__driver_attach()
driver_probe_device()
__driver_probe_device()
really_probe()

It's really_probe() that seems to set dev->driver pointer.


>> It doesn't work with layouts driver (since refactoring?) as driver is
>> NULL. That results in NULL pointer dereference when trying to reach
>> of_match_table.
>>
>> That is why I used u_boot_env_of_match_table directly.
>>
>> If you know how to fix nvmem_layout_get_match_data() that would be
>> great. Do we need driver_register() somewhere in NVMEM core?



From jan.kiszka at siemens.com  Tue Dec 19 01:56:37 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 19 Dec 2023 10:56:37 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
 <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
 <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
Message-ID: <d25399e3-9054-44a1-9ff9-e27252436222@siemens.com>

On 19.12.23 10:54, Jan Kiszka wrote:
> On 19.12.23 10:50, Krzysztof Kozlowski wrote:
>> On 19/12/2023 10:03, Jan Kiszka wrote:
>>> On 19.12.23 09:48, Krzysztof Kozlowski wrote:
>>>> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>>>>
>>>>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>>>>
>>>>>> Ditto
>>>>>>
>>>>>
>>>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>>>>> not introducing new ones. We can add the color properties in a separate
>>>>
>>>>
>>>> Then why aren't you overriding by phandle/label?
>>>>
>>>
>>> We could do that as well if we added labels first (they don't exist so 
>>> far). Not seeing any difference, though.
>>
>> Confusion? Your code suggests new node, thus you got review like you got.
>>
>>>
>>>>> patch, but the node names are now part of the kernel ABI. Changing them
>>>>> would break existing userland.
>>>>
>>>> You mean label. Why node names became the ABI? Which interface exposes them?
>>>
>>> root at iot2050-debian:~# ls -l /sys/class/leds/
>>> total 0
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus at 100000/4fa0000.mmc/leds/mmc0::
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus at 100000/4f80000.mmc/leds/mmc1::
>>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
>>
>> I replied too fast previous and did not include answer here:
>>
>> You have label for that... Somehow all these nodes are half-baked,
>> without all the expected properties and now you call node name as ABI.
>> The node name is not the ABI.
> 
> Well, existing userspace uses those names, and adding the properties
> would break that interface. Now, does Linux do that?
> 

Obviously, we could deviate from the existing naming scheme only for the
new variant, keeping it for the other 5, but that will be "fun" to maintain.

Jan

-- 
Siemens AG, Technology
Linux Expert Center



From krzysztof.kozlowski at linaro.org  Tue Dec 19 01:58:04 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 10:58:04 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
 <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
 <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
Message-ID: <ce6b002b-f2a6-4056-bf81-53a6c948b946@linaro.org>

On 19/12/2023 10:54, Jan Kiszka wrote:
>>>> You mean label. Why node names became the ABI? Which interface exposes them?
>>>
>>> root at iot2050-debian:~# ls -l /sys/class/leds/
>>> total 0
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus at 100000/4fa0000.mmc/leds/mmc0::
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus at 100000/4f80000.mmc/leds/mmc1::
>>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
>>
>> I replied too fast previous and did not include answer here:
>>
>> You have label for that... Somehow all these nodes are half-baked,
>> without all the expected properties and now you call node name as ABI.
>> The node name is not the ABI.
> 
> Well, existing userspace uses those names, and adding the properties
> would break that interface. Now, does Linux do that?

I don't think you understood the concept. There is no change for
userspace. Same interface, same names. No ABI break.

Anyway, changing them is not part of this patchset since these are not
new nodes.

Best regards,
Krzysztof



From gregor.herburger at ew.tq-group.com  Tue Dec 19 01:58:42 2023
From: gregor.herburger at ew.tq-group.com (Gregor Herburger)
Date: Tue, 19 Dec 2023 10:58:42 +0100
Subject: [PATCH] i2c: i2c-imx: allow bus recovery on non-muxable pads
In-Reply-To: <87frzyprhq.fsf@geanix.com>
References: <20231218-i2c-imx-recovery-v1-1-f69fa85b228c@ew.tq-group.com>
 <87frzyprhq.fsf@geanix.com>
Message-ID: <ZYFpUpP0Ll5c99py@herburgerg-w2>

Hi Esben,

On Tue, Dec 19, 2023 at 07:43:21AM +0000, esben at geanix.com wrote:
> Gregor Herburger <gregor.herburger at ew.tq-group.com> writes:
> 
> > Currently the i2c-imx driver assumes that for bus recovery the i2c pins
> > can be reconfigured as gpio via pinctrl.
> >
> > But bus recovery can also be done with a gpio electrically connected to
> > i2c scl.
> >
> > Modify i2c_imx_init_recovery_info to allow bus recovery on platforms
> > without pinctrl. In this case only use scl-gpio and
> > i2c_generic_scl_recovery.
> 
> Why not move to use the generic GPIO recovery instead?  Will something
> like this be able to cover at least the same scenarios as your change?

I was not aware of the generic GPIO recovery functions. At a first
glance I think your solution should work. I will give it a try and test
it on hardware.

> 
> From 7e432496bae8c7ac35c21504bc1cd03f1dfef97f Mon Sep 17 00:00:00 2001
> Message-ID: <7e432496bae8c7ac35c21504bc1cd03f1dfef97f.1702971634.git.esben at geanix.com>
> From: Esben Haabendal <esben at geanix.com>
> Date: Tue, 25 May 2021 11:25:44 +0200
> Subject: [PATCH] i2c: imx: move to generic GPIO recovery
> 
> Starting with
> commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
> GPIO bus recovery is supported by the I2C core, so we can remove the
> driver implementation and use that one instead.
> 
> As a nice side-effect, pinctrl becomes optional, allowing bus recovery on
> LS1021A, which does not have such luxury, but can be wired up to use extra
> fixed GPIO pins.
> 
> Signed-off-by: Esben Haabendal <esben at geanix.com>
> ---
>  drivers/i2c/busses/i2c-imx.c | 62 ++++--------------------------------
>  1 file changed, 7 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 1775a79aeba2..824d8bbb9be5 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -212,10 +212,6 @@ struct imx_i2c_struct {
>  	const struct imx_i2c_hwdata	*hwdata;
>  	struct i2c_bus_recovery_info rinfo;
>  
> -	struct pinctrl *pinctrl;
> -	struct pinctrl_state *pinctrl_pins_default;
> -	struct pinctrl_state *pinctrl_pins_gpio;
> -
>  	struct imx_i2c_dma	*dma;
>  	struct i2c_client	*slave;
>  	enum i2c_slave_event last_slave_event;
> @@ -1357,24 +1353,6 @@ static int i2c_imx_xfer_atomic(struct i2c_adapter *adapter,
>  	return result;
>  }
>  
> -static void i2c_imx_prepare_recovery(struct i2c_adapter *adap)
> -{
> -	struct imx_i2c_struct *i2c_imx;
> -
> -	i2c_imx = container_of(adap, struct imx_i2c_struct, adapter);
> -
> -	pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_gpio);
> -}
> -
> -static void i2c_imx_unprepare_recovery(struct i2c_adapter *adap)
> -{
> -	struct imx_i2c_struct *i2c_imx;
> -
> -	i2c_imx = container_of(adap, struct imx_i2c_struct, adapter);
> -
> -	pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_default);
> -}
> -
>  /*
>   * We switch SCL and SDA to their GPIO function and do some bitbanging
>   * for bus recovery. These alternative pinmux settings can be
> @@ -1385,43 +1363,17 @@ static void i2c_imx_unprepare_recovery(struct i2c_adapter *adap)
>  static int i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
>  		struct platform_device *pdev)
>  {
> -	struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
> +	struct i2c_bus_recovery_info *bri = &i2c_imx->rinfo;
>  
> -	i2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
> -	if (!i2c_imx->pinctrl) {
> -		dev_info(&pdev->dev, "pinctrl unavailable, bus recovery not supported\n");
> +	bri->pinctrl = devm_pinctrl_get(&pdev->dev);
> +	if (PTR_ERR(bri->pinctrl) == -ENODEV) {
> +		bri->pinctrl = NULL;
>  		return 0;
>  	}
> -	if (IS_ERR(i2c_imx->pinctrl)) {
> -		dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
> -		return PTR_ERR(i2c_imx->pinctrl);
> -	}
> -
> -	i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
> -			PINCTRL_STATE_DEFAULT);
> -	i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
> -			"gpio");
> -	rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
> -	rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
> -
> -	if (PTR_ERR(rinfo->sda_gpiod) == -EPROBE_DEFER ||
> -	    PTR_ERR(rinfo->scl_gpiod) == -EPROBE_DEFER) {
> -		return -EPROBE_DEFER;
> -	} else if (IS_ERR(rinfo->sda_gpiod) ||
> -		   IS_ERR(rinfo->scl_gpiod) ||
> -		   IS_ERR(i2c_imx->pinctrl_pins_default) ||
> -		   IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
> -		dev_dbg(&pdev->dev, "recovery information incomplete\n");
> -		return 0;
> -	}
> -
> -	dev_dbg(&pdev->dev, "using scl%s for recovery\n",
> -		rinfo->sda_gpiod ? ",sda" : "");
> +	if (IS_ERR(bri->pinctrl))
> +		return PTR_ERR(bri->pinctrl);
>  
> -	rinfo->prepare_recovery = i2c_imx_prepare_recovery;
> -	rinfo->unprepare_recovery = i2c_imx_unprepare_recovery;
> -	rinfo->recover_bus = i2c_generic_scl_recovery;
> -	i2c_imx->adapter.bus_recovery_info = rinfo;
> +	i2c_imx->adapter.bus_recovery_info = bri;
>  
>  	return 0;
>  }
> -- 
> 2.43.0
> 
> 
> /Esben
> 


From shawn.lin at rock-chips.com  Tue Dec 19 02:01:24 2023
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Tue, 19 Dec 2023 18:01:24 +0800
Subject: [PATCH v2 3/3] ARM: dts: rockchip: Remove
 rockchip,default-sample-phase from rk3036.dtsi
In-Reply-To: <20231218105523.2478315-4-andyshrk@163.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
 <20231218105523.2478315-4-andyshrk@163.com>
Message-ID: <31198bf2-54c4-4483-ac31-449e5576cff8@rock-chips.com>


On 2023/12/18 18:55, Andy Yan wrote:
> From: Andy Yan <andy.yan at rock-chips.com>
> 
> This should be a per board property, should not be put in
> a soc core dtsi.
> 
> And when this property convert from default-sample-phase
> in linux-5.7 by commit 8a385eb57296 ("ARM: dts: rockchip: fix
> rockchip,default-sample-phase property names"), the emmc
> on rk3036 kylin board get a initialising error:
> 
> [    4.512797] Freeing unused kernel memory: 8192K
> [    4.519500] mmc_host mmc1: Bus speed (slot 0) = 37125000Hz (slot req 37500000Hz, actual 37125000HZ div = 0)
> [    4.530971] mmc1: error -84 whilst initialising MMC card
> [    4.537277] Run /init as init process
> [    4.550932] mmc_host mmc1: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
> [    4.664717] mmc_host mmc1: Bus speed (slot 0) = 37125000Hz (slot req 37500000Hz, actual 37125000HZ div = 0)
> [    4.676156] mmc1: error -84 whilst initialising MMC card
> 
> I think the reason why the emmc on rk3036 kylin board was able
> to work before linux-5.7 was that the illegal property was not
> correctly identified by the rockchip dw_mmc driver.
> 
> Fixes: faea098e1808 ("ARM: dts: rockchip: add core rk3036 dtsi")
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> ---
> 

Reviewed-by: Shawn Lin <shawn.lin at rock-chips.com>

> (no changes since v1)
> 
>   arch/arm/boot/dts/rockchip/rk3036.dtsi | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> index 5344803442a1..466952bf9db4 100644
> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> @@ -287,7 +287,6 @@ emmc: mmc at 1021c000 {
>   		clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
>   			 <&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
>   		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> -		rockchip,default-sample-phase = <158>;
>   		disable-wp;
>   		dmas = <&pdma 12>;
>   		dma-names = "rx-tx";


From zajec5 at gmail.com  Tue Dec 19 02:10:20 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 19 Dec 2023 11:10:20 +0100
Subject: [PATCH 4/4] nvmem: layouts: add U-Boot env layout
In-Reply-To: <ba8abaf6-6f16-4742-a3ea-ad00d4151698@gmail.com>
References: <20231218133722.16150-1-zajec5@gmail.com>
 <20231218133722.16150-4-zajec5@gmail.com> <20231218152116.59d59bad@xps-13>
 <13bc621c-5fcb-4710-912c-06e3e80d7337@gmail.com>
 <20231219085517.4b6ec4fc@xps-13>
 <ba8abaf6-6f16-4742-a3ea-ad00d4151698@gmail.com>
Message-ID: <b56399f5-03fe-4bf1-b9dc-1bd81ef76e12@gmail.com>

On 19.12.2023 10:55, Rafa? Mi?ecki wrote:
> On 19.12.2023 08:55, Miquel Raynal wrote:
>> Hi Rafa?,
>>
>> zajec5 at gmail.com wrote on Mon, 18 Dec 2023 23:10:20 +0100:
>>
>>> On 18.12.2023 15:21, Miquel Raynal wrote:
>>>> Hi Rafa?,
>>>>
>>>> zajec5 at gmail.com wrote on Mon, 18 Dec 2023 14:37:22 +0100:
>>>>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>>>>
>>>>> This patch moves all generic (NVMEM devices independent) code from NVMEM
>>>>> device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
>>>>> code on top of it.
>>>>>
>>>>> Thanks to proper layout it's possible to support U-Boot env data stored
>>>>> on any kind of NVMEM device.
>>>>>
>>>>> For backward compatibility with old DT bindings we need to keep old
>>>>> NVMEM device driver functional. To avoid code duplication a parsing
>>>>> function is exported and reused in it.
>>>>>
>>>>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
>>>>> ---
>>>>
>>>> I have a couple of comments about the original driver which gets
>>>> copy-pasted in the new layout driver, maybe you could clean these
>>>> (the memory leak should be fixed before the migration so it can be
>>>> backported easily, the others are just style so it can be done after, I
>>>> don't mind).
>>>>
>>>> ...
>>>>> +int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
>>>>> +???????????? enum u_boot_env_format format)
>>>>> +{
>>>>> +??? size_t crc32_data_offset;
>>>>> +??? size_t crc32_data_len;
>>>>> +??? size_t crc32_offset;
>>>>> +??? size_t data_offset;
>>>>> +??? size_t data_len;
>>>>> +??? size_t dev_size;
>>>>> +??? uint32_t crc32;
>>>>> +??? uint32_t calc;
>>>>> +??? uint8_t *buf;
>>>>> +??? int bytes;
>>>>> +??? int err;
>>>>> +
>>>>> +??? dev_size = nvmem_dev_size(nvmem);
>>>>> +
>>>>> +??? buf = kcalloc(1, dev_size, GFP_KERNEL);
>>>>
>>>> Out of curiosity, why kcalloc(1,...) rather than kzalloc() ?
>>>
>>> I used kcalloc() initially as I didn't need buffer to be zeroed.
>>
>> I think kcalloc() initializes the memory to zero.
>> https://elixir.bootlin.com/linux/latest/source/include/linux/slab.h#L659
>>
>> If you don't need it you can switch to kmalloc() instead, I don't mind,
>> but kcalloc() is meant to be used with arrays, I don't see the point of
>> using kcalloc() in this case.
>>
>>>
>>> I see that memory-allocation.rst however says:
>>> ? > And, to be on the safe side it's best to use routines that set memory to zero, like kzalloc().
>>>
>>> It's probably close to zero cost to zero that buffer so it could be kzalloc().
>>>
>>>
>>>>> +??? if (!buf) {
>>>>> +??????? err = -ENOMEM;
>>>>> +??????? goto err_out;
>>>>
>>>> We could directly return ENOMEM here I guess.
>>>>> +??? }
>>>>> +
>>>>> +??? bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
>>>>> +??? if (bytes < 0)
>>>>> +??????? return bytes;
>>>>> +??? else if (bytes != dev_size)
>>>>> +??????? return -EIO;
>>>>
>>>> Don't we need to free buf in the above cases?
>>>>> +??? switch (format) {
>>>>> +??? case U_BOOT_FORMAT_SINGLE:
>>>>> +??????? crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
>>>>> +??????? crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
>>>>> +??????? data_offset = offsetof(struct u_boot_env_image_single, data);
>>>>> +??????? break;
>>>>> +??? case U_BOOT_FORMAT_REDUNDANT:
>>>>> +??????? crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
>>>>> +??????? crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
>>>>> +??????? data_offset = offsetof(struct u_boot_env_image_redundant, data);
>>>>> +??????? break;
>>>>> +??? case U_BOOT_FORMAT_BROADCOM:
>>>>> +??????? crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
>>>>> +??????? crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
>>>>> +??????? data_offset = offsetof(struct u_boot_env_image_broadcom, data);
>>>>> +??????? break;
>>>>> +??? }
>>>>> +??? crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
>>>>
>>>> Looks a bit convoluted, any chances we can use intermediate variables
>>>> to help decipher this?
>>>>> +??? crc32_data_len = dev_size - crc32_data_offset;
>>>>> +??? data_len = dev_size - data_offset;
>>>>> +
>>>>> +??? calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
>>>>> +??? if (calc != crc32) {
>>>>> +??????? dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
>>>>> +??????? err = -EINVAL;
>>>>> +??????? goto err_kfree;
>>>>> +??? }
>>>>> +
>>>>> +??? buf[dev_size - 1] = '\0';
>>>>> +??? err = u_boot_env_parse_cells(dev, nvmem, buf, data_offset, data_len);
>>>>> +??? if (err)
>>>>> +??????? dev_err(dev, "Failed to add cells: %d\n", err);
>>>>
>>>> Please drop this error message, the only reason for which the function
>>>> call would fail is apparently an ENOMEM case.
>>>>> +
>>>>> +err_kfree:
>>>>> +??? kfree(buf);
>>>>> +err_out:
>>>>> +??? return err;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(u_boot_env_parse);
>>>>> +
>>>>> +static int u_boot_env_add_cells(struct device *dev, struct nvmem_device *nvmem)
>>>>> +{
>>>>> +??? const struct of_device_id *match;
>>>>> +??? struct device_node *layout_np;
>>>>> +??? enum u_boot_env_format format;
>>>>> +
>>>>> +??? layout_np = of_nvmem_layout_get_container(nvmem);
>>>>> +??? if (!layout_np)
>>>>> +??????? return -ENOENT;
>>>>> +
>>>>> +??? match = of_match_node(u_boot_env_of_match_table, layout_np);
>>>>> +??? if (!match)
>>>>> +??????? return -ENOENT;
>>>>> +
>>>>> +??? format = (uintptr_t)match->data;
>>>>
>>>> In the core there is currently an unused helper called
>>>> nvmem_layout_get_match_data() which does that. I think the original
>>>> intent of this function was to be used in this driver, so depending on
>>>> your preference, can you please either use it or remove it?
>>>
>>> The problem is that nvmem_layout_get_match_data() uses:
>>> layout->dev.driver
>>
>> I'm surprised .driver is unset. Well anyway, please either fix the core
>> helper and use it or drop the core helper, because we have no user for
>> it otherwise?
> 
> I believe it's because of a very minimalistic "nvmem_bus_type" bus
> implementation.

Scratch that, I was looking at "nvmem_bus_type" instead of
"nvmem_layout_bus_type". I'll see if I can debug that.


>  From a quick look it seems that default expected FORWARD-trace is:
> driver_register()
> bus_add_driver()
> driver_attach()
> __driver_attach()
> driver_probe_device()
> __driver_probe_device()
> really_probe()
> 
> It's really_probe() that seems to set dev->driver pointer.
> 
> 
>>> It doesn't work with layouts driver (since refactoring?) as driver is
>>> NULL. That results in NULL pointer dereference when trying to reach
>>> of_match_table.
>>>
>>> That is why I used u_boot_env_of_match_table directly.
>>>
>>> If you know how to fix nvmem_layout_get_match_data() that would be
>>> great. Do we need driver_register() somewhere in NVMEM core?
> 



From nicolas.ferre at microchip.com  Tue Dec 19 02:11:21 2023
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Tue, 19 Dec 2023 11:11:21 +0100
Subject: [PATCH v3 36/50] ARM: at91: add support in SoC driver for new
 sam9x7
In-Reply-To: <20230728102905.267131-1-varshini.rajendran@microchip.com>
References: <20230728102905.267131-1-varshini.rajendran@microchip.com>
Message-ID: <e4481634-d0b4-427d-a9a2-f3fe5643f2e6@microchip.com>

On 28/07/2023 at 12:29, Varshini Rajendran wrote:
> Add support for SAM9X7 SoC in the SoC driver.
> 
> Signed-off-by: Varshini Rajendran <varshini.rajendran at microchip.com>
> Reviewed-by: Claudiu Beznea <claudiu.beznea at microchip.com>
> ---
>   drivers/soc/atmel/soc.c | 23 +++++++++++++++++++++++
>   drivers/soc/atmel/soc.h |  9 +++++++++
>   2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/soc/atmel/soc.c b/drivers/soc/atmel/soc.c
> index cc9a3e107479..cae3452cbc60 100644
> --- a/drivers/soc/atmel/soc.c
> +++ b/drivers/soc/atmel/soc.c
> @@ -101,6 +101,29 @@ static const struct at91_soc socs[] __initconst = {
>   		 AT91_CIDR_VERSION_MASK, SAM9X60_D6K_EXID_MATCH,
>   		 "sam9x60 8MiB SDRAM SiP", "sam9x60"),
>   #endif
> +#ifdef CONFIG_SOC_SAM9X7
> +	AT91_SOC(SAM9X7_CIDR_MATCH, AT91_CIDR_MATCH_MASK,
> +		 AT91_CIDR_VERSION_MASK, SAM9X75_EXID_MATCH,
> +		 "sam9x75", "sam9x7"),
> +	AT91_SOC(SAM9X7_CIDR_MATCH, AT91_CIDR_MATCH_MASK,
> +		 AT91_CIDR_VERSION_MASK, SAM9X72_EXID_MATCH,
> +		 "sam9x72", "sam9x7"),
> +	AT91_SOC(SAM9X7_CIDR_MATCH, AT91_CIDR_MATCH_MASK,
> +		 AT91_CIDR_VERSION_MASK, SAM9X70_EXID_MATCH,
> +		 "sam9x70", "sam9x7"),
> +	AT91_SOC(SAM9X7_CIDR_MATCH, SAM9X75_D1G_EXID_MATCH,
> +		 AT91_CIDR_VERSION_MASK, SAM9X75_EXID_MATCH,
> +		 "sam9x75 1Gb DDR3L SiP ", "sam9x7"),

I don't want that we introduce more sizes in "bits" instead of "bytes" 
in this file.
I know it's what is advertised in datasheets, but we're software people 
who count these sizes in bytes, so let's do the conversion for the users.

BTW: this file will need to be updated with this statement in mind.

Best regards,
   Nicolas

> +	AT91_SOC(SAM9X7_CIDR_MATCH, SAM9X75_D5M_EXID_MATCH,
> +		 AT91_CIDR_VERSION_MASK, SAM9X75_EXID_MATCH,
> +		 "sam9x75 512Mb DDR2 SiP", "sam9x7"),
> +	AT91_SOC(SAM9X7_CIDR_MATCH, SAM9X75_D1M_EXID_MATCH,
> +		 AT91_CIDR_VERSION_MASK, SAM9X75_EXID_MATCH,
> +		 "sam9x75 128Mb DDR2 SiP", "sam9x7"),
> +	AT91_SOC(SAM9X7_CIDR_MATCH, SAM9X75_D2G_EXID_MATCH,
> +		 AT91_CIDR_VERSION_MASK, SAM9X75_EXID_MATCH,
> +		 "sam9x75 2Gb DDR3L SiP", "sam9x7"),
> +#endif
>   #ifdef CONFIG_SOC_SAMA5
>   	AT91_SOC(SAMA5D2_CIDR_MATCH, AT91_CIDR_MATCH_MASK,
>   		 AT91_CIDR_VERSION_MASK, SAMA5D21CU_EXID_MATCH,
> diff --git a/drivers/soc/atmel/soc.h b/drivers/soc/atmel/soc.h
> index 7a9f47ce85fb..26dd26b4f179 100644
> --- a/drivers/soc/atmel/soc.h
> +++ b/drivers/soc/atmel/soc.h
> @@ -45,6 +45,7 @@ at91_soc_init(const struct at91_soc *socs);
>   #define AT91SAM9N12_CIDR_MATCH		0x019a07a0
>   #define SAM9X60_CIDR_MATCH		0x019b35a0
>   #define SAMA7G5_CIDR_MATCH		0x00162100
> +#define SAM9X7_CIDR_MATCH		0x09750020

Apha-numerial order please.

>   
>   #define AT91SAM9M11_EXID_MATCH		0x00000001
>   #define AT91SAM9M10_EXID_MATCH		0x00000002
> @@ -74,6 +75,14 @@ at91_soc_init(const struct at91_soc *socs);
>   #define SAMA7G54_D2G_EXID_MATCH		0x00000020
>   #define SAMA7G54_D4G_EXID_MATCH		0x00000028
>   
> +#define SAM9X75_EXID_MATCH		0x00000000
> +#define SAM9X72_EXID_MATCH		0x00000004
> +#define SAM9X70_EXID_MATCH		0x00000005
> +#define SAM9X75_D1G_EXID_MATCH		0x00000001
> +#define SAM9X75_D5M_EXID_MATCH		0x00000002
> +#define SAM9X75_D1M_EXID_MATCH		0x00000003
> +#define SAM9X75_D2G_EXID_MATCH		0x00000006
> +

Ditto

>   #define AT91SAM9XE128_CIDR_MATCH	0x329973a0
>   #define AT91SAM9XE256_CIDR_MATCH	0x329a93a0
>   #define AT91SAM9XE512_CIDR_MATCH	0x329aa3a0



From wsa at kernel.org  Tue Dec 19 02:21:16 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 19 Dec 2023 11:21:16 +0100
Subject: [PATCH 1/6] dt-bindings: i2c: exynos5: add specific compatible
 for Tesla FSD
In-Reply-To: <20231205092229.19135-2-krzysztof.kozlowski@linaro.org>
References: <20231205092229.19135-1-krzysztof.kozlowski@linaro.org>
 <20231205092229.19135-2-krzysztof.kozlowski@linaro.org>
Message-ID: <ZYFunIR3WTWEQZ27@shikoro>

On Tue, Dec 05, 2023 at 10:22:24AM +0100, Krzysztof Kozlowski wrote:
> Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the
> others it reuses several devices from older designs.  Historically we
> kept the old (block's) compatible only.  This works fine and there is no
> bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add Tesla FSD compatible specific to be used with an existing fallback.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Acked-by: Wolfram Sang <wsa at kernel.org>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/11dc1a3f/attachment-0001.sig>

From dmitry.baryshkov at linaro.org  Tue Dec 19 02:21:58 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Tue, 19 Dec 2023 12:21:58 +0200
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for SM8550
In-Reply-To: <a363c860-62be-43a7-930c-cab8a6f3fa6c@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com> <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com> <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org> <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
 <aa8b2ccd-33da-404b-9a93-3d88cf63ec77@quicinc.com> <8338db1e-0216-4fc5-b6ab-ddf43adf3648@linaro.org>
 <a363c860-62be-43a7-930c-cab8a6f3fa6c@quicinc.com>
Message-ID: <CAA8EJpoMwrwQ9wBZE6AcobLLkCchFtN23SnHhw3enNOfX3CzTQ@mail.gmail.com>

On Tue, 19 Dec 2023 at 10:25, Bibek Kumar Patro
<quic_bibekkum at quicinc.com> wrote:
>
>
>
> On 12/18/2023 7:51 PM, Dmitry Baryshkov wrote:
> > On 18/12/2023 13:23, Bibek Kumar Patro wrote:
> >>
> >>
> >> On 12/16/2023 9:45 PM, Dmitry Baryshkov wrote:
> >>> On 16/12/2023 02:03, Konrad Dybcio wrote:
> >>>> On 15.12.2023 13:54, Robin Murphy wrote:
> >>>>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
> >>>>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
> >>>>>>> <quic_bibekkum at quicinc.com> wrote:
> >>>>>>>>
> >>>>>>>> Add ACTLR data table for SM8550 along with support for
> >>>>>>>> same including SM8550 specific implementation operations.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
> >>>>>>>> ---
> >>>>>>>>    drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89
> >>>>>>>> ++++++++++++++++++++++
> >>>>>>>>    1 file changed, 89 insertions(+)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >>>>>>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >>>>>>>> index cb49291f5233..d2006f610243 100644
> >>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >>>>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
> >>>>>>>>           u32 actlr;
> >>>>>>>>    };
> >>>>>>>>
> >>>>>>>> +/*
> >>>>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching
> >>>>>>>> in the
> >>>>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the
> >>>>>>>> prefetch
> >>>>>>>> + * buffer). The remaining bits are implementation defined and
> >>>>>>>> vary across
> >>>>>>>> + * SoCs.
> >>>>>>>> + */
> >>>>>>>> +
> >>>>>>>> +#define PREFETCH_DEFAULT       0
> >>>>>>>> +#define PREFETCH_SHALLOW       BIT(8)
> >>>>>>>> +#define PREFETCH_MODERATE      BIT(9)
> >>>>>>>> +#define PREFETCH_DEEP          (BIT(9) | BIT(8))
> >>>>>>>
> >>>>>>> I thin the following might be more correct:
> >>>>>>>
> >>>>>>> #include <linux/bitfield.h>
> >>>>>>>
> >>>>>>> #define PREFETCH_MASK GENMASK(9, 8)
> >>>>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
> >>>>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
> >>>>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
> >>>>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
> >>>>>>>
> >>>>>>
> >>>>>> Ack, thanks for this suggestion. Let me try this out using
> >>>>>> GENMASK. Once tested, will take care of this in next version.
> >>>>>
> >>>>> FWIW the more typical usage would be to just define the named
> >>>>> macros for the raw field values, then put the FIELD_PREP() at the
> >>>>> point of use. However in this case that's liable to get pretty
> >>>>> verbose, so although I'm usually a fan of bitfield.h, the most
> >>>>> readable option here might actually be to stick with simpler
> >>>>> definitions of "(0 << 8)", "(1 << 8)", etc. However it's not really
> >>>>> a big deal either way, and I defer to whatever Dmitry and Konrad
> >>>>> prefer, since they're the ones looking after arm-smmu-qcom the most :)
> >>>> My 5 cents would be to just use the "common" style of doing this, so:
> >>>>
> >>>> #define ACTRL_PREFETCH    GENMASK(9, 8)
> >>>>   #define PREFETCH_DEFAULT 0
> >>>>   #define PREFETCH_SHALLOW 1
> >>>>   #define PREFETCH_MODERATE 2
> >>>>   #define PREFETCH_DEEP 3
> >>>>
> >>>> and then use
> >>>>
> >>>> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
> >>>>
> >>>> it can get verbose, but.. arguably that's good, since you really want
> >>>> to make sure the right bits are set here
> >>>
> >>> Sounds good to me.
> >>>
> >>
> >> Konrad, Dimitry, just checked FIELD_PREP() implementation
> >>
> >> #define FIELD_FIT(_mask, _val)
> >> ({                                                              \
> >>                   __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");  \
> >>                   ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
> >> })
> >>
> >> since it is defined as a block, it won't be possible to use FIELD_PREP
> >> in macro or as a structure value, and can only be used inside a
> >> block/function. Orelse would show compilation errors as following
> >>
> >> kernel/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c:94:20: note: in
> >> expansion of macro 'PREFETCH_SHALLOW'
> >>    { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> >>                      ^
> >> kernel/include/linux/bitfield.h:113:2: error: braced-group within
> >> expression allowed only inside a function
> >>    ({        \
> >>    ^
> >>
> >> So as per my understanding I think, we might need to go ahead with the
> >> generic implementation only. Let me know if I missed something.
> >
> > Then anyway (foo << bar) is better compared to BIT(n) | BIT(m).
> >
>
> Sure Dmitry, (foo << bar) would be simpler as well as Robin mentioned
> earlier in his reply.
> I can implement the defines as:
>
> #define PREFETCH_DEFAULT       0
> #define PREFETCH_SHALLOW       (1 << 8)
> #define PREFETCH_MODERATE      (1 << 9)

2 << 8. Isn't that hard.

> #define PREFETCH_DEEP          (3 << 8)
>
> This should be okay I think ?
>
> Thanks,
> Bibek
>


-- 
With best wishes
Dmitry


From quic_jinlmao at quicinc.com  Tue Dec 19 02:27:04 2023
From: quic_jinlmao at quicinc.com (Jinlong Mao)
Date: Tue, 19 Dec 2023 18:27:04 +0800
Subject: [PATCH v3 7/8] dt-bindings: arm: Add support for TPDM CMB MSR
 register
In-Reply-To: <8051b5ab-4f7f-4a8c-9c4f-fe1f46bb1951@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-8-git-send-email-quic_taozha@quicinc.com>
 <e5fbbfab-02bf-4eda-8353-87c54c307af1@linaro.org>
 <1d57590d-2ecf-4bf6-9c8f-2a9d1ba08aaa@arm.com>
 <caa424d3-7af0-43e6-8e13-e87cde0c4f67@quicinc.com>
 <ca624e71-c487-4004-abc4-126442b92f33@arm.com>
 <8051b5ab-4f7f-4a8c-9c4f-fe1f46bb1951@quicinc.com>
Message-ID: <6ea79046-c091-4945-be62-fc1a36c8e50a@quicinc.com>



On 12/18/2023 8:17 PM, Jinlong Mao wrote:
> 
> 
> On 12/18/2023 7:56 PM, Suzuki K Poulose wrote:
>> Hi Tingwei Zhang
>>
>> On 18/12/2023 11:23, Tingwei Zhang wrote:
>>> On 12/18/2023 6:47 PM, Suzuki K Poulose wrote:
>>>> Tao Zhang,
>>>>
>>>> On 21/11/2023 07:24, Krzysztof Kozlowski wrote:
>>>>> On 21/11/2023 03:24, Tao Zhang wrote:
>>>>>> Add property "qcom,cmb_msr_num" to support CMB MSR(mux select 
>>>>>> register)
>>>>>> for TPDM. It specifies the number of CMB MSR registers supported by
>>>>>> the TDPM.
>>>>>>
>>>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>>>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>>>>>> ---
>>>>>
>>>>> I prefer not to take any new Qualcomm Coresight bindings or 
>>>>> Qualcomm SoC
>>>>> DTS nodes with Coresight till we fix all existing warnings. I don't 
>>>>> know
>>>>> how to fix them, so I need help with them. No such fixing happened so
>>>>> far from Qcom, so pushback is my only way to get any attention.
>>>>>
>>>>> I already commented on this in other email thread.
>>>>
>>>> Are you addressing this ?
>>> The DT warning is fixed in 
>>> https://lore.kernel.org/linux-arm-msm/20231210072633.4243-1-quic_jinlmao at quicinc.com/.
>>> It's applied to linux-arm-msm yesterday.
>>
>> How are you supporting remote-etm ? We haven't merged the support for 
>> it in drivers ? We haven't even reviewed the remote-etm support 
>> patches ? Why weren't the coresight maintainers Cc ed on the "new" 
>> binding support ?
>>
>> Suzuki
>>
>>
> Hi Suzuki,
> 
> Sorry for missing coresight maintainers in the remote-etm binding patch.
>  From the comments, we can add binding for the connected hardware first.
> 
> https://lkml.org/lkml/2023/11/30/539
> 
> Thanks
> Jinlong Mao
> 
Hi Suzuki,

The dt-binding patch of remote-etm is not applied. I run dtbs_check 
without dt-binding patch, there is no device tree warning. I will
merge the dt-binding patch of remote-etm to the remote etm patches to
make them review together.

[2/4] arm64: dts: qcom: msm8996: Fix 'in-ports' is a required property
       commit: 9a6fc510a6a3ec150cb7450aec1e5f257e6fc77b
[3/4] arm64: dts: qcom: msm8998: Fix 'out-ports' is a required property
       commit: ae5ee3562a2519214b12228545e88a203dd68bbd
[4/4] arm64: dts: qcom: Fix coresight warnings in in-ports and out-ports
       commit: bdb6339fd46b8702ea7411b0b414587b86a40562

Thanks
Jinlong Mao
>>
>>>>
>>>> Suzuki
>>>>
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>>>
>>>>
>>>
>>


From maz at kernel.org  Tue Dec 19 02:32:02 2023
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 19 Dec 2023 10:32:02 +0000
Subject: (subset) [PATCH v11 00/43] KVM: arm64: Nested Virtualization support (FEAT_NV2 only)
In-Reply-To: <20231120131027.854038-1-maz@kernel.org>
References: <20231120131027.854038-1-maz@kernel.org>
Message-ID: <170298189037.3443606.3400166802031595828.b4-ty@kernel.org>

On Mon, 20 Nov 2023 13:09:44 +0000, Marc Zyngier wrote:
> This is the 5th drop of NV support on arm64 for this year, and most
> probably the last one for this side of Christmas.
> 
> For the previous episodes, see [1].
> 
> What's changed:
> 
> [...]

Applied to next, thanks!

[01/43] arm64: cpufeatures: Restrict NV support to FEAT_NV2
        commit: 2bfc654b89c4dd1c372bb2cbba6b5a0eb578d214
[02/43] KVM: arm64: nv: Hoist vcpu_has_nv() into is_hyp_ctxt()
        commit: 111903d1f5b9334d1100e1c6ee08e740fa374d91
[03/43] KVM: arm64: nv: Compute NV view of idregs as a one-off
        commit: 3ed0b5123cd5a2a4f1fe4e594e7bf319e9eaf1da
[04/43] KVM: arm64: nv: Drop EL12 register traps that are redirected to VNCR
        commit: 4d4f52052ba8357f1591cb9bc3086541070711af
[05/43] KVM: arm64: nv: Add non-VHE-EL2->EL1 translation helpers
        commit: 3606e0b2e462164bced151dbb54ccfe42ac6c35b
[06/43] KVM: arm64: nv: Add include containing the VNCR_EL2 offsets
        commit: 60ce16cc122aad999129d23061fa35f63d5b1e9b
[07/43] KVM: arm64: Introduce a bad_trap() primitive for unexpected trap handling
        commit: 2733dd10701abc6ab23d65a732f58fbeb80bd203
[08/43] KVM: arm64: nv: Add EL2_REG_VNCR()/EL2_REG_REDIR() sysreg helpers
        commit: 9b9cce60be85e6807bdb0eaa2f520e78dbab0659
[09/43] KVM: arm64: nv: Map VNCR-capable registers to a separate page
        commit: d8bd48e3f0ee9e1fdba2a2e453155a5354e48a8d
[10/43] KVM: arm64: nv: Handle virtual EL2 registers in vcpu_read/write_sys_reg()
        commit: fedc612314acfebf506e071bf3a941076aa56d10

Cheers,

	M.
-- 
Without deviation from the norm, progress is not possible.




From quic_bibekkum at quicinc.com  Tue Dec 19 02:36:48 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 16:06:48 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <CAA8EJpoMwrwQ9wBZE6AcobLLkCchFtN23SnHhw3enNOfX3CzTQ@mail.gmail.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
 <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
 <aa8b2ccd-33da-404b-9a93-3d88cf63ec77@quicinc.com>
 <8338db1e-0216-4fc5-b6ab-ddf43adf3648@linaro.org>
 <a363c860-62be-43a7-930c-cab8a6f3fa6c@quicinc.com>
 <CAA8EJpoMwrwQ9wBZE6AcobLLkCchFtN23SnHhw3enNOfX3CzTQ@mail.gmail.com>
Message-ID: <334bc814-07d2-4966-93e3-f2cfbabc15b2@quicinc.com>



On 12/19/2023 3:51 PM, Dmitry Baryshkov wrote:
> On Tue, 19 Dec 2023 at 10:25, Bibek Kumar Patro
> <quic_bibekkum at quicinc.com> wrote:
>>
>>
>>
>> On 12/18/2023 7:51 PM, Dmitry Baryshkov wrote:
>>> On 18/12/2023 13:23, Bibek Kumar Patro wrote:
>>>>
>>>>
>>>> On 12/16/2023 9:45 PM, Dmitry Baryshkov wrote:
>>>>> On 16/12/2023 02:03, Konrad Dybcio wrote:
>>>>>> On 15.12.2023 13:54, Robin Murphy wrote:
>>>>>>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>>>>>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>>>>>>>> <quic_bibekkum at quicinc.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Add ACTLR data table for SM8550 along with support for
>>>>>>>>>> same including SM8550 specific implementation operations.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>>>>>>>> ---
>>>>>>>>>>     drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89
>>>>>>>>>> ++++++++++++++++++++++
>>>>>>>>>>     1 file changed, 89 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>>>> index cb49291f5233..d2006f610243 100644
>>>>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>>>>>>>>            u32 actlr;
>>>>>>>>>>     };
>>>>>>>>>>
>>>>>>>>>> +/*
>>>>>>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching
>>>>>>>>>> in the
>>>>>>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the
>>>>>>>>>> prefetch
>>>>>>>>>> + * buffer). The remaining bits are implementation defined and
>>>>>>>>>> vary across
>>>>>>>>>> + * SoCs.
>>>>>>>>>> + */
>>>>>>>>>> +
>>>>>>>>>> +#define PREFETCH_DEFAULT       0
>>>>>>>>>> +#define PREFETCH_SHALLOW       BIT(8)
>>>>>>>>>> +#define PREFETCH_MODERATE      BIT(9)
>>>>>>>>>> +#define PREFETCH_DEEP          (BIT(9) | BIT(8))
>>>>>>>>>
>>>>>>>>> I thin the following might be more correct:
>>>>>>>>>
>>>>>>>>> #include <linux/bitfield.h>
>>>>>>>>>
>>>>>>>>> #define PREFETCH_MASK GENMASK(9, 8)
>>>>>>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>>>>>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>>>>>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>>>>>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ack, thanks for this suggestion. Let me try this out using
>>>>>>>> GENMASK. Once tested, will take care of this in next version.
>>>>>>>
>>>>>>> FWIW the more typical usage would be to just define the named
>>>>>>> macros for the raw field values, then put the FIELD_PREP() at the
>>>>>>> point of use. However in this case that's liable to get pretty
>>>>>>> verbose, so although I'm usually a fan of bitfield.h, the most
>>>>>>> readable option here might actually be to stick with simpler
>>>>>>> definitions of "(0 << 8)", "(1 << 8)", etc. However it's not really
>>>>>>> a big deal either way, and I defer to whatever Dmitry and Konrad
>>>>>>> prefer, since they're the ones looking after arm-smmu-qcom the most :)
>>>>>> My 5 cents would be to just use the "common" style of doing this, so:
>>>>>>
>>>>>> #define ACTRL_PREFETCH    GENMASK(9, 8)
>>>>>>    #define PREFETCH_DEFAULT 0
>>>>>>    #define PREFETCH_SHALLOW 1
>>>>>>    #define PREFETCH_MODERATE 2
>>>>>>    #define PREFETCH_DEEP 3
>>>>>>
>>>>>> and then use
>>>>>>
>>>>>> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
>>>>>>
>>>>>> it can get verbose, but.. arguably that's good, since you really want
>>>>>> to make sure the right bits are set here
>>>>>
>>>>> Sounds good to me.
>>>>>
>>>>
>>>> Konrad, Dimitry, just checked FIELD_PREP() implementation
>>>>
>>>> #define FIELD_FIT(_mask, _val)
>>>> ({                                                              \
>>>>                    __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");  \
>>>>                    ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
>>>> })
>>>>
>>>> since it is defined as a block, it won't be possible to use FIELD_PREP
>>>> in macro or as a structure value, and can only be used inside a
>>>> block/function. Orelse would show compilation errors as following
>>>>
>>>> kernel/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c:94:20: note: in
>>>> expansion of macro 'PREFETCH_SHALLOW'
>>>>     { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>>                       ^
>>>> kernel/include/linux/bitfield.h:113:2: error: braced-group within
>>>> expression allowed only inside a function
>>>>     ({        \
>>>>     ^
>>>>
>>>> So as per my understanding I think, we might need to go ahead with the
>>>> generic implementation only. Let me know if I missed something.
>>>
>>> Then anyway (foo << bar) is better compared to BIT(n) | BIT(m).
>>>
>>
>> Sure Dmitry, (foo << bar) would be simpler as well as Robin mentioned
>> earlier in his reply.
>> I can implement the defines as:
>>
>> #define PREFETCH_DEFAULT       0
>> #define PREFETCH_SHALLOW       (1 << 8)
>> #define PREFETCH_MODERATE      (1 << 9)
> 
> 2 << 8. Isn't that hard.
> 

Ah, right. This is nice! .
Will use 2 << 8 instead. Thanks for the suggestion.

Thanks,
Bibek

>> #define PREFETCH_DEEP          (3 << 8)
>>
>> This should be okay I think ?
>>
>> Thanks,
>> Bibek
>>
> 
> 


From dmitry.baryshkov at linaro.org  Tue Dec 19 02:44:04 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Tue, 19 Dec 2023 12:44:04 +0200
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for SM8550
In-Reply-To: <334bc814-07d2-4966-93e3-f2cfbabc15b2@quicinc.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com> <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com> <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org> <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
 <aa8b2ccd-33da-404b-9a93-3d88cf63ec77@quicinc.com> <8338db1e-0216-4fc5-b6ab-ddf43adf3648@linaro.org>
 <a363c860-62be-43a7-930c-cab8a6f3fa6c@quicinc.com> <CAA8EJpoMwrwQ9wBZE6AcobLLkCchFtN23SnHhw3enNOfX3CzTQ@mail.gmail.com>
 <334bc814-07d2-4966-93e3-f2cfbabc15b2@quicinc.com>
Message-ID: <CAA8EJprL8pHQyWcdHiS+GReJsTMrddL=SCgkPhePR_7HvsQpsQ@mail.gmail.com>

On Tue, 19 Dec 2023 at 12:37, Bibek Kumar Patro
<quic_bibekkum at quicinc.com> wrote:
>
>
>
> On 12/19/2023 3:51 PM, Dmitry Baryshkov wrote:
> > On Tue, 19 Dec 2023 at 10:25, Bibek Kumar Patro
> > <quic_bibekkum at quicinc.com> wrote:
> >>
> >>
> >>
> >> On 12/18/2023 7:51 PM, Dmitry Baryshkov wrote:
> >>> On 18/12/2023 13:23, Bibek Kumar Patro wrote:
> >>>>
> >>>>
> >>>> On 12/16/2023 9:45 PM, Dmitry Baryshkov wrote:
> >>>>> On 16/12/2023 02:03, Konrad Dybcio wrote:
> >>>>>> On 15.12.2023 13:54, Robin Murphy wrote:
> >>>>>>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
> >>>>>>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
> >>>>>>>>> <quic_bibekkum at quicinc.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Add ACTLR data table for SM8550 along with support for
> >>>>>>>>>> same including SM8550 specific implementation operations.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
> >>>>>>>>>> ---
> >>>>>>>>>>     drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89
> >>>>>>>>>> ++++++++++++++++++++++
> >>>>>>>>>>     1 file changed, 89 insertions(+)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >>>>>>>>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >>>>>>>>>> index cb49291f5233..d2006f610243 100644
> >>>>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >>>>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >>>>>>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
> >>>>>>>>>>            u32 actlr;
> >>>>>>>>>>     };
> >>>>>>>>>>
> >>>>>>>>>> +/*
> >>>>>>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching
> >>>>>>>>>> in the
> >>>>>>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the
> >>>>>>>>>> prefetch
> >>>>>>>>>> + * buffer). The remaining bits are implementation defined and
> >>>>>>>>>> vary across
> >>>>>>>>>> + * SoCs.
> >>>>>>>>>> + */
> >>>>>>>>>> +
> >>>>>>>>>> +#define PREFETCH_DEFAULT       0
> >>>>>>>>>> +#define PREFETCH_SHALLOW       BIT(8)
> >>>>>>>>>> +#define PREFETCH_MODERATE      BIT(9)
> >>>>>>>>>> +#define PREFETCH_DEEP          (BIT(9) | BIT(8))
> >>>>>>>>>
> >>>>>>>>> I thin the following might be more correct:
> >>>>>>>>>
> >>>>>>>>> #include <linux/bitfield.h>
> >>>>>>>>>
> >>>>>>>>> #define PREFETCH_MASK GENMASK(9, 8)
> >>>>>>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
> >>>>>>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
> >>>>>>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
> >>>>>>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Ack, thanks for this suggestion. Let me try this out using
> >>>>>>>> GENMASK. Once tested, will take care of this in next version.
> >>>>>>>
> >>>>>>> FWIW the more typical usage would be to just define the named
> >>>>>>> macros for the raw field values, then put the FIELD_PREP() at the
> >>>>>>> point of use. However in this case that's liable to get pretty
> >>>>>>> verbose, so although I'm usually a fan of bitfield.h, the most
> >>>>>>> readable option here might actually be to stick with simpler
> >>>>>>> definitions of "(0 << 8)", "(1 << 8)", etc. However it's not really
> >>>>>>> a big deal either way, and I defer to whatever Dmitry and Konrad
> >>>>>>> prefer, since they're the ones looking after arm-smmu-qcom the most :)
> >>>>>> My 5 cents would be to just use the "common" style of doing this, so:
> >>>>>>
> >>>>>> #define ACTRL_PREFETCH    GENMASK(9, 8)
> >>>>>>    #define PREFETCH_DEFAULT 0
> >>>>>>    #define PREFETCH_SHALLOW 1
> >>>>>>    #define PREFETCH_MODERATE 2
> >>>>>>    #define PREFETCH_DEEP 3
> >>>>>>
> >>>>>> and then use
> >>>>>>
> >>>>>> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
> >>>>>>
> >>>>>> it can get verbose, but.. arguably that's good, since you really want
> >>>>>> to make sure the right bits are set here
> >>>>>
> >>>>> Sounds good to me.
> >>>>>
> >>>>
> >>>> Konrad, Dimitry, just checked FIELD_PREP() implementation
> >>>>
> >>>> #define FIELD_FIT(_mask, _val)
> >>>> ({                                                              \
> >>>>                    __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");  \
> >>>>                    ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
> >>>> })
> >>>>
> >>>> since it is defined as a block, it won't be possible to use FIELD_PREP
> >>>> in macro or as a structure value, and can only be used inside a
> >>>> block/function. Orelse would show compilation errors as following
> >>>>
> >>>> kernel/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c:94:20: note: in
> >>>> expansion of macro 'PREFETCH_SHALLOW'
> >>>>     { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> >>>>                       ^
> >>>> kernel/include/linux/bitfield.h:113:2: error: braced-group within
> >>>> expression allowed only inside a function
> >>>>     ({        \
> >>>>     ^
> >>>>
> >>>> So as per my understanding I think, we might need to go ahead with the
> >>>> generic implementation only. Let me know if I missed something.
> >>>
> >>> Then anyway (foo << bar) is better compared to BIT(n) | BIT(m).
> >>>
> >>
> >> Sure Dmitry, (foo << bar) would be simpler as well as Robin mentioned
> >> earlier in his reply.
> >> I can implement the defines as:
> >>
> >> #define PREFETCH_DEFAULT       0
> >> #define PREFETCH_SHALLOW       (1 << 8)
> >> #define PREFETCH_MODERATE      (1 << 9)
> >
> > 2 << 8. Isn't that hard.
> >
>
> Ah, right. This is nice! .
> Will use 2 << 8 instead. Thanks for the suggestion.

It might still be useful to define the PREFETCH_SHIFT equal to 8.

>
> Thanks,
> Bibek
>
> >> #define PREFETCH_DEEP          (3 << 8)
> >>
> >> This should be okay I think ?
> >>
> >> Thanks,
> >> Bibek
> >>
> >
> >



-- 
With best wishes
Dmitry


From esben at geanix.com  Tue Dec 19 02:48:17 2023
From: esben at geanix.com (esben at geanix.com)
Date: Tue, 19 Dec 2023 11:48:17 +0100
Subject: [PATCH] i2c: i2c-imx: allow bus recovery on non-muxable pads
In-Reply-To: <ZYFpUpP0Ll5c99py@herburgerg-w2> (Gregor Herburger's message of
	"Tue, 19 Dec 2023 10:58:42 +0100")
References: <20231218-i2c-imx-recovery-v1-1-f69fa85b228c@ew.tq-group.com>
	<87frzyprhq.fsf@geanix.com> <ZYFpUpP0Ll5c99py@herburgerg-w2>
Message-ID: <877clapixa.fsf@geanix.com>

Gregor Herburger <gregor.herburger at ew.tq-group.com> writes:

> Hi Esben,
>
>> Why not move to use the generic GPIO recovery instead?  Will something
>> like this be able to cover at least the same scenarios as your change?
>
> I was not aware of the generic GPIO recovery functions. At a first
> glance I think your solution should work. I will give it a try and test
> it on hardware.

Great. Let me know if it works for me. If it does, I guess I should send
the patch to the list in it's own thread.

/Esben


From angelogioacchino.delregno at collabora.com  Tue Dec 19 02:55:30 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 19 Dec 2023 11:55:30 +0100
Subject: [PATCH v2] mmc: add wp_grp_size node
In-Reply-To: <20231218230532.82427-1-bo.ye@mediatek.com>
References: <20231218224832.81347-1-bo.ye@mediatek.com>
 <20231218230532.82427-1-bo.ye@mediatek.com>
Message-ID: <716db737-940a-4a28-bd54-b1dce76174d2@collabora.com>

Il 19/12/23 00:05, Bo Ye ha scritto:
> From: "lin.gui" <lin.gui at mediatek.com>
> 
> Detail:
> Add node "wp_grp_size", corresponding to WP_GRP_SIZE
> (write protect group size) of eMMC's CSD register.
> 
> Scenario:
> The eMMC card can be set into write-protected mode to
> prevent data from being accidentally modified or deleted.
> Wp_grp_size (Write Protect Group Size) refers to an
> attribute of the eMMC card, used to manage write protection,
> and is the CSD register  [36:32] of the eMMC device.
> Wp_grp_size (Write Protect Group Size) indicates how many
> eMMC blocks are contained in each write protection group on the eMMC card.
> 
> Final rendered file:
> "/sys/class/mmc_host/mmc0/mmc0:0001/wp_grp_size"
> 
> Signed-off-by: Lin Gui <lin.gui at mediatek.com>
> Signed-off-by: Bo Ye <bo.ye at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Tue Dec 19 02:56:37 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Tue, 19 Dec 2023 11:56:37 +0100
Subject: [PATCH v2] fix overflow in idle exit_latency
In-Reply-To: <20231219031444.91752-1-bo.ye@mediatek.com>
References: <20231219031444.91752-1-bo.ye@mediatek.com>
Message-ID: <e23ebdd8-7fbe-435b-a850-0ef18a51b020@collabora.com>

Il 19/12/23 04:14, Bo Ye ha scritto:
> From: C Cheng <C.Cheng at mediatek.com>
> 
> In detail:
> 
> In C language, when you perform a multiplication operation, if
> both operands are of int type, the multiplication operation is
> performed on the int type, and then the result is converted to
> the target type. This means that if the product of int type
> multiplication exceeds the range that int type can represent,
>   an overflow will occur even if you store the result in a
> variable of int64_t type.
> 
> For a multiplication of two int values, it is better to use
> mul_u32_u32() rather than s->exit_latency_ns = s->exit_latency *
> NSEC_PER_USEC to avoid potential overflow happenning.
> 
> Signed-off-by: C Cheng <C.Cheng at mediatek.com>
> Signed-off-by: Bo Ye <bo.ye at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From will at kernel.org  Tue Dec 19 03:18:30 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 19 Dec 2023 11:18:30 +0000
Subject: [PATCH] kselftest/arm64: Don't probe the current VL for unsupported vector types
In-Reply-To: <20231218-kselftest-arm64-vec-syscfg-rdvl-v1-1-0ac22d47e81f@kernel.org>
References: <20231218-kselftest-arm64-vec-syscfg-rdvl-v1-1-0ac22d47e81f@kernel.org>
Message-ID: <170298019769.1509727.6589504598690487361.b4-ty@kernel.org>

On Mon, 18 Dec 2023 23:39:32 +0000, Mark Brown wrote:
> The vec-syscfg selftest verifies that setting the VL of the currently
> tested vector type does not disrupt the VL of the other vector type. To do
> this it records the current vector length for each type but neglects to
> guard this with a check for that vector type actually being supported. Add
> one, using a helper function which we also update all the other instances
> of this pattern.
> 
> [...]

Applied to arm64 (for-next/selftests), thanks!

[1/1] kselftest/arm64: Don't probe the current VL for unsupported vector types
      https://git.kernel.org/arm64/c/9a802ddb2123

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Tue Dec 19 03:18:31 2023
From: will at kernel.org (Will Deacon)
Date: Tue, 19 Dec 2023 11:18:31 +0000
Subject: [PATCH] efi/libstub: zboot: do not use $(shell ...) in cmd_copy_and_pad
In-Reply-To: <20231218080127.907460-1-masahiroy@kernel.org>
References: <20231218080127.907460-1-masahiroy@kernel.org>
Message-ID: <170298016046.1509472.12688198177716250949.b4-ty@kernel.org>

On Mon, 18 Dec 2023 17:01:27 +0900, Masahiro Yamada wrote:
> You do not need to use $(shell ...) in recipe lines, as they are already
> executed in a shell. An alternative solution is $$(...), which is an
> escaped sequence of the shell's command substituion, $(...).
> 
> For this case, there is a reason to avoid $(shell ...).
> 
> Kbuild detects command changes by using the if_changed macro, which
> compares the previous command recorded in .*.cmd with the current
> command from Makefile. If they differ, Kbuild re-runs the build rule.
> 
> [...]

Applied to arm64 (for-next/kbuild), thanks!

[1/1] efi/libstub: zboot: do not use $(shell ...) in cmd_copy_and_pad
      https://git.kernel.org/arm64/c/97ba4416d6dd

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From david at redhat.com  Tue Dec 19 03:29:23 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 19 Dec 2023 12:29:23 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
Message-ID: <9d473ac7-ef52-4fa4-bb54-900176d987c9@redhat.com>

On 19.12.23 09:30, Ryan Roberts wrote:
> On 18/12/2023 17:47, David Hildenbrand wrote:
>> On 18.12.23 11:50, Ryan Roberts wrote:
>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>> batch is determined by the architecture with the new helper,
>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>> all belonging to the same folio. A pte batch is then write-protected in
>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>> set in one go in the child using the new helper, set_ptes_full().
>>>
>>> The primary motivation for this change is to reduce the number of tlb
>>> maintenance operations that the arm64 backend has to perform during
>>> fork, as it is about to add transparent support for the "contiguous bit"
>>> in its ptes. By write-protecting the parent using the new
>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>> when all ptes in the range are being write-protected. Similarly, by
>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>> child, the backend does not need to fold a contiguous range once they
>>> are all populated - they can be initially populated as a contiguous
>>> range in the first place.
>>>
>>> This code is very performance sensitive, and a significant amount of
>>> effort has been put into not regressing performance for the order-0
>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>> which enables the compiler to simplify the extra loops that are added
>>> for batching and produce code that is equivalent (and equally
>>> performant) as the previous implementation.
>>>
>>> This change addresses the core-mm refactoring only and a separate change
>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>> set_ptes_full() in the arm64 backend to realize the performance
>>> improvement as part of the work to enable contpte mappings.
>>>
>>> To ensure the arm64 is performant once implemented, this change is very
>>> careful to only call ptep_get() once per pte batch.
>>>
>>> The following microbenchmark results demonstate that there is no
>>> significant performance change after this patch. Fork is called in a
>>> tight loop in a process with 1G of populated memory and the time for the
>>> function to execute is measured. 100 iterations per run, 8 runs
>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>> performed for case where 1G memory is comprised of order-0 folios and
>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>> positive is slower, compared to baseline upon which the series is based:
>>>
>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>> | fork????????? |-------------------|-------------------|
>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>> |---------------|---------|---------|---------|---------|
>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>
>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>> | fork????????? |-------------------|-------------------|
>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>> |---------------|---------|---------|---------|---------|
>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>
>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>> ---
>>>  ? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>  ? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>  ? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>> index af7639c3b0a3..db93fb81465a 100644
>>> --- a/include/linux/pgtable.h
>>> +++ b/include/linux/pgtable.h
>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>  ? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>  ? #endif
>>>  ? +#ifndef pte_batch_remaining
>>> +/**
>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>> + * @pte: Page table entry for the first page.
>>> + * @addr: Address of the first page.
>>> + * @end: Batch ceiling (e.g. end of vma).
>>> + *
>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of ptes.
>>> + * In such cases, this function returns the remaining number of pages to the end
>>> + * of the current batch, as defined by addr. This can be useful when iterating
>>> + * over ptes.
>>> + *
>>> + * May be overridden by the architecture, else batch size is always 1.
>>> + */
>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long addr,
>>> +??????????????????????? unsigned long end)
>>> +{
>>> +??? return 1;
>>> +}
>>> +#endif
>>
>> It's a shame we now lose the optimization for all other archtiectures.
>>
>> Was there no way to have some basic batching mechanism that doesn't require arch
>> specifics?
> 
> I tried a bunch of things but ultimately the way I've done it was the only way
> to reduce the order-0 fork regression to 0.

Let me give it a churn today. I think we should really focus on having 
only a single folio_test_large() check on the fast path for order-0. And 
not even try doing batching for anything that works on bare PFNs.

Off to prototyping ... :)

-- 
Cheers,

David / dhildenb



From quic_bibekkum at quicinc.com  Tue Dec 19 03:39:13 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 17:09:13 +0530
Subject: [PATCH v4 3/5] iommu/arm-smmu: add ACTLR data and support for
 SM8550
In-Reply-To: <CAA8EJprL8pHQyWcdHiS+GReJsTMrddL=SCgkPhePR_7HvsQpsQ@mail.gmail.com>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-4-quic_bibekkum@quicinc.com>
 <CAA8EJppcsr1sbeD1fK0nZ+rASABNcetBK3yMvaP7OiA4JPwskw@mail.gmail.com>
 <c9493c5f-ccf8-4e21-b00c-5fbc2a5f2edb@quicinc.com>
 <b7f2bbf9-fb5a-430d-aa32-3a220b46c2f0@arm.com>
 <1eee8bae-59f0-4066-9d04-8c3a5f750d3a@linaro.org>
 <42d627af-164b-4b50-973e-fa71d86cb84c@linaro.org>
 <aa8b2ccd-33da-404b-9a93-3d88cf63ec77@quicinc.com>
 <8338db1e-0216-4fc5-b6ab-ddf43adf3648@linaro.org>
 <a363c860-62be-43a7-930c-cab8a6f3fa6c@quicinc.com>
 <CAA8EJpoMwrwQ9wBZE6AcobLLkCchFtN23SnHhw3enNOfX3CzTQ@mail.gmail.com>
 <334bc814-07d2-4966-93e3-f2cfbabc15b2@quicinc.com>
 <CAA8EJprL8pHQyWcdHiS+GReJsTMrddL=SCgkPhePR_7HvsQpsQ@mail.gmail.com>
Message-ID: <fe091dba-142e-403c-b304-b79064718555@quicinc.com>



On 12/19/2023 4:14 PM, Dmitry Baryshkov wrote:
> On Tue, 19 Dec 2023 at 12:37, Bibek Kumar Patro
> <quic_bibekkum at quicinc.com> wrote:
>>
>>
>>
>> On 12/19/2023 3:51 PM, Dmitry Baryshkov wrote:
>>> On Tue, 19 Dec 2023 at 10:25, Bibek Kumar Patro
>>> <quic_bibekkum at quicinc.com> wrote:
>>>>
>>>>
>>>>
>>>> On 12/18/2023 7:51 PM, Dmitry Baryshkov wrote:
>>>>> On 18/12/2023 13:23, Bibek Kumar Patro wrote:
>>>>>>
>>>>>>
>>>>>> On 12/16/2023 9:45 PM, Dmitry Baryshkov wrote:
>>>>>>> On 16/12/2023 02:03, Konrad Dybcio wrote:
>>>>>>>> On 15.12.2023 13:54, Robin Murphy wrote:
>>>>>>>>> On 2023-12-15 12:20 pm, Bibek Kumar Patro wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 12/15/2023 4:14 PM, Dmitry Baryshkov wrote:
>>>>>>>>>>> On Fri, 15 Dec 2023 at 12:19, Bibek Kumar Patro
>>>>>>>>>>> <quic_bibekkum at quicinc.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Add ACTLR data table for SM8550 along with support for
>>>>>>>>>>>> same including SM8550 specific implementation operations.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>      drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 89
>>>>>>>>>>>> ++++++++++++++++++++++
>>>>>>>>>>>>      1 file changed, 89 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>>>>>> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>>>>>> index cb49291f5233..d2006f610243 100644
>>>>>>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>>>>>>>>>>>> @@ -20,6 +20,85 @@ struct actlr_config {
>>>>>>>>>>>>             u32 actlr;
>>>>>>>>>>>>      };
>>>>>>>>>>>>
>>>>>>>>>>>> +/*
>>>>>>>>>>>> + * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching
>>>>>>>>>>>> in the
>>>>>>>>>>>> + * macro TLB) and BIT(1) as CPRE (Enable context caching in the
>>>>>>>>>>>> prefetch
>>>>>>>>>>>> + * buffer). The remaining bits are implementation defined and
>>>>>>>>>>>> vary across
>>>>>>>>>>>> + * SoCs.
>>>>>>>>>>>> + */
>>>>>>>>>>>> +
>>>>>>>>>>>> +#define PREFETCH_DEFAULT       0
>>>>>>>>>>>> +#define PREFETCH_SHALLOW       BIT(8)
>>>>>>>>>>>> +#define PREFETCH_MODERATE      BIT(9)
>>>>>>>>>>>> +#define PREFETCH_DEEP          (BIT(9) | BIT(8))
>>>>>>>>>>>
>>>>>>>>>>> I thin the following might be more correct:
>>>>>>>>>>>
>>>>>>>>>>> #include <linux/bitfield.h>
>>>>>>>>>>>
>>>>>>>>>>> #define PREFETCH_MASK GENMASK(9, 8)
>>>>>>>>>>> #define PREFETCH_DEFAULT FIELD_PREP(PREFETCH_MASK, 0)
>>>>>>>>>>> #define PREFETCH_SHALLOW FIELD_PREP(PREFETCH_MASK, 1)
>>>>>>>>>>> #define PREFETCH_MODERATE FIELD_PREP(PREFETCH_MASK, 2)
>>>>>>>>>>> #define PREFETCH_DEEP FIELD_PREP(PREFETCH_MASK, 3)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ack, thanks for this suggestion. Let me try this out using
>>>>>>>>>> GENMASK. Once tested, will take care of this in next version.
>>>>>>>>>
>>>>>>>>> FWIW the more typical usage would be to just define the named
>>>>>>>>> macros for the raw field values, then put the FIELD_PREP() at the
>>>>>>>>> point of use. However in this case that's liable to get pretty
>>>>>>>>> verbose, so although I'm usually a fan of bitfield.h, the most
>>>>>>>>> readable option here might actually be to stick with simpler
>>>>>>>>> definitions of "(0 << 8)", "(1 << 8)", etc. However it's not really
>>>>>>>>> a big deal either way, and I defer to whatever Dmitry and Konrad
>>>>>>>>> prefer, since they're the ones looking after arm-smmu-qcom the most :)
>>>>>>>> My 5 cents would be to just use the "common" style of doing this, so:
>>>>>>>>
>>>>>>>> #define ACTRL_PREFETCH    GENMASK(9, 8)
>>>>>>>>     #define PREFETCH_DEFAULT 0
>>>>>>>>     #define PREFETCH_SHALLOW 1
>>>>>>>>     #define PREFETCH_MODERATE 2
>>>>>>>>     #define PREFETCH_DEEP 3
>>>>>>>>
>>>>>>>> and then use
>>>>>>>>
>>>>>>>> | FIELD_PREP(ACTRL_PREFETCH, PREFETCH_x)
>>>>>>>>
>>>>>>>> it can get verbose, but.. arguably that's good, since you really want
>>>>>>>> to make sure the right bits are set here
>>>>>>>
>>>>>>> Sounds good to me.
>>>>>>>
>>>>>>
>>>>>> Konrad, Dimitry, just checked FIELD_PREP() implementation
>>>>>>
>>>>>> #define FIELD_FIT(_mask, _val)
>>>>>> ({                                                              \
>>>>>>                     __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");  \
>>>>>>                     ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
>>>>>> })
>>>>>>
>>>>>> since it is defined as a block, it won't be possible to use FIELD_PREP
>>>>>> in macro or as a structure value, and can only be used inside a
>>>>>> block/function. Orelse would show compilation errors as following
>>>>>>
>>>>>> kernel/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c:94:20: note: in
>>>>>> expansion of macro 'PREFETCH_SHALLOW'
>>>>>>      { 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
>>>>>>                        ^
>>>>>> kernel/include/linux/bitfield.h:113:2: error: braced-group within
>>>>>> expression allowed only inside a function
>>>>>>      ({        \
>>>>>>      ^
>>>>>>
>>>>>> So as per my understanding I think, we might need to go ahead with the
>>>>>> generic implementation only. Let me know if I missed something.
>>>>>
>>>>> Then anyway (foo << bar) is better compared to BIT(n) | BIT(m).
>>>>>
>>>>
>>>> Sure Dmitry, (foo << bar) would be simpler as well as Robin mentioned
>>>> earlier in his reply.
>>>> I can implement the defines as:
>>>>
>>>> #define PREFETCH_DEFAULT       0
>>>> #define PREFETCH_SHALLOW       (1 << 8)
>>>> #define PREFETCH_MODERATE      (1 << 9)
>>>
>>> 2 << 8. Isn't that hard.
>>>
>>
>> Ah, right. This is nice! .
>> Will use 2 << 8 instead. Thanks for the suggestion.
> 
> It might still be useful to define the PREFETCH_SHIFT equal to 8.
> 

Sure, looks okay to me as well to define PREFETCH_SHIFT to 8
as it's constant.

Thanks,
Bibek

>>
>> Thanks,
>> Bibek
>>
>>>> #define PREFETCH_DEEP          (3 << 8)
>>>>
>>>> This should be okay I think ?
>>>>
>>>> Thanks,
>>>> Bibek
>>>>
>>>
>>>
> 
> 
> 


From sebastianene at google.com  Tue Dec 19 03:44:10 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Tue, 19 Dec 2023 11:44:10 +0000
Subject: [PATCH v4 01/10] KVM: arm64: Add snapshot interface for the host
 stage-2 pagetable
In-Reply-To: <20231218135859.2513568-3-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com> <20231218135859.2513568-3-sebastianene@google.com>
Message-ID: <CAHLR_paUwXFUGnJSHSkFd0PnSStrNFkOXc1CLzH2g=qFv7SgNg@mail.gmail.com>

On Mon, Dec 18, 2023 at 01:58:51PM +0000, Sebastian Ene wrote:
> Introduce a new hvc that allows the pKVM hypervisor to snapshot the host
> stage-2 pagetables. The caller is expected to allocate & free the memory
> for the pagetable snapshot. The below diagram shows the sequence of
> events.
>
> [--- HOST ---]
> (1) allocate memory for the snapshot
> (2) invoke the __pkvm_copy_host_stage2(snapshot) interface
> |____
>       [--- HYP ---]
>       (3) donate the snapshot from HOST -> HYP
>       (4) save the host stage-2 pagetables in the snapshot
>       (5) donate the snapshot from HYP -> HOST
>       [--- return from HYP ---]
> [--- HOST ---]
> (6) free the memory for the snapshot
>
> When the host kernel invokes this interface, the memory is donated from
> the host to the hypervisor. By doing this the memory is unmapped from the
> host's translation regime to prevent the host from modifying the buffer
> while the hypervisor uses it. The hypervisor walks the host stage-2
> pagetable copy while re-creating the original mappings. When the copying
> is done, the memory is donated from the hypervisor back to the host.
> The pages that have been used from the memcache are donated back to the
> host from a temporary array. The hvc is executing synchronously and the
> preemption is disabled for the current CPU while running inside the
> hypervisor so calling this interface blocks the current CPU until the
> snapshoting is done.
>
> Signed-off-by: Sebastian Ene <sebastianene at google.com>
> ---
>  arch/arm64/include/asm/kvm_asm.h              |   1 +
>  arch/arm64/include/asm/kvm_pgtable.h          |  43 ++++
>  arch/arm64/kvm/hyp/include/nvhe/mem_protect.h |   1 +
>  arch/arm64/kvm/hyp/nvhe/hyp-main.c            |  12 ++
>  arch/arm64/kvm/hyp/nvhe/mem_protect.c         | 186 ++++++++++++++++++
>  arch/arm64/kvm/hyp/pgtable.c                  |  43 ++++
>  6 files changed, 286 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index 24b5e6b23..9df3367d8 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -81,6 +81,7 @@ enum __kvm_host_smccc_func {
>       __KVM_HOST_SMCCC_FUNC___pkvm_init_vm,
>       __KVM_HOST_SMCCC_FUNC___pkvm_init_vcpu,
>       __KVM_HOST_SMCCC_FUNC___pkvm_teardown_vm,
> +     __KVM_HOST_SMCCC_FUNC___pkvm_host_stage2_snapshot,
>  };
>
>  #define DECLARE_KVM_VHE_SYM(sym)     extern char sym[]
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index d3e354bb8..f73efd8a8 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -10,6 +10,7 @@
>  #include <linux/bits.h>
>  #include <linux/kvm_host.h>
>  #include <linux/types.h>
> +#include <asm/kvm_host.h>
>
>  #define KVM_PGTABLE_MAX_LEVELS               4U
>
> @@ -351,6 +352,28 @@ struct kvm_pgtable {
>       kvm_pgtable_force_pte_cb_t              force_pte_cb;
>  };
>
> +/**
> + * struct kvm_pgtable_snapshot - Snapshot page-table wrapper.
> + * @pgtable:         The page-table configuration.
> + * @mc:                      Memcache used for pagetable pages allocation.
> + * @pgd_hva:         Host virtual address of a physically contiguous buffer
> + *                   used for storing the PGD.
> + * @pgd_pages:               The size of the phyisically contiguous buffer in pages.
> + * @used_pages_hva:  Host virtual address of a physically contiguous buffer
> + *                   used for storing the consumed pages from the memcache.
> + * @num_used_pages           The size of the used buffer in pages.
> + * @used_pages_indx          The current index of the used pages array.
> + */
> +struct kvm_pgtable_snapshot {
> +     struct kvm_pgtable                      pgtable;
> +     struct kvm_hyp_memcache                 mc;
> +     void                                    *pgd_hva;
> +     size_t                                  pgd_pages;
> +     phys_addr_t                             *used_pages_hva;
> +     size_t                                  num_used_pages;
> +     size_t                                  used_pages_indx;
> +};
> +
>  /**
>   * kvm_pgtable_hyp_init() - Initialise a hypervisor stage-1 page-table.
>   * @pgt:     Uninitialised page-table structure to initialise.
> @@ -756,4 +779,24 @@ enum kvm_pgtable_prot kvm_pgtable_hyp_pte_prot(kvm_pte_t pte);
>   */
>  void kvm_tlb_flush_vmid_range(struct kvm_s2_mmu *mmu,
>                               phys_addr_t addr, size_t size);
> +
> +#ifdef CONFIG_NVHE_EL2_DEBUG
> +/**
> + * kvm_pgtable_stage2_snapshot() - Given a memcache and a destination
> + *                           pagetable where we have the original PGD
> + *                           copied, build a snapshot table with page table
> + *                           pages from the given memcache.
> + *
> + * @to_pgt:  Destination pagetable
> + * @mc:              The memcache where we allocate the destination pagetables from
> + */
> +int kvm_pgtable_stage2_snapshot(struct kvm_pgtable *to_pgt,
> +                             void *mc);
> +#else
> +static inline int kvm_pgtable_stage2_snapshot(struct kvm_pgtable *to_pgt,
> +                                           void *mc)
> +{
> +     return -EPERM;
> +}
> +#endif       /* CONFIG_NVHE_EL2_DEBUG */
>  #endif       /* __ARM64_KVM_PGTABLE_H__ */
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> index 0972faccc..ca8f76915 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> @@ -69,6 +69,7 @@ int __pkvm_host_donate_hyp(u64 pfn, u64 nr_pages);
>  int __pkvm_hyp_donate_host(u64 pfn, u64 nr_pages);
>  int __pkvm_host_share_ffa(u64 pfn, u64 nr_pages);
>  int __pkvm_host_unshare_ffa(u64 pfn, u64 nr_pages);
> +int __pkvm_host_stage2_snapshot(struct kvm_pgtable_snapshot *snapshot);
>
>  bool addr_is_memory(phys_addr_t phys);
>  int host_stage2_idmap_locked(phys_addr_t addr, u64 size, enum kvm_pgtable_prot prot);
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 2385fd03e..7b215245f 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -314,6 +314,17 @@ static void handle___pkvm_teardown_vm(struct kvm_cpu_context *host_ctxt)
>       cpu_reg(host_ctxt, 1) = __pkvm_teardown_vm(handle);
>  }
>
> +static void handle___pkvm_host_stage2_snapshot(struct kvm_cpu_context *host_ctxt)
> +{
> +#ifdef CONFIG_NVHE_EL2_DEBUG
> +     DECLARE_REG(struct kvm_pgtable_snapshot *, snapshot_hva, host_ctxt, 1);
> +
> +     cpu_reg(host_ctxt, 1) = __pkvm_host_stage2_snapshot(snapshot_hva);
> +#else
> +     cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> +#endif
> +}
> +
>  typedef void (*hcall_t)(struct kvm_cpu_context *);
>
>  #define HANDLE_FUNC(x)       [__KVM_HOST_SMCCC_FUNC_##x] = (hcall_t)handle_##x
> @@ -348,6 +359,7 @@ static const hcall_t host_hcall[] = {
>       HANDLE_FUNC(__pkvm_init_vm),
>       HANDLE_FUNC(__pkvm_init_vcpu),
>       HANDLE_FUNC(__pkvm_teardown_vm),
> +     HANDLE_FUNC(__pkvm_host_stage2_snapshot),
>  };
>
>  static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 8d0a5834e..aaf07f9e1 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -266,6 +266,192 @@ int kvm_guest_prepare_stage2(struct pkvm_hyp_vm *vm, void *pgd)
>       return 0;
>  }
>
> +#ifdef CONFIG_NVHE_EL2_DEBUG
> +static void *snap_zalloc_page(void *mc)
> +{
> +     struct hyp_page *p;
> +     void *addr;
> +     struct kvm_pgtable_snapshot *snap;
> +     phys_addr_t *used_pg;
> +
> +     snap = container_of(mc, struct kvm_pgtable_snapshot, mc);
> +     used_pg = kern_hyp_va(snap->used_pages_hva);
> +
> +     /* Check if we have space to track the used page */
> +     if (snap->used_pages_indx * sizeof(phys_addr_t) > snap->num_used_pages * PAGE_SIZE)

This should be '>=' instead, and I will fix this.


> +             return NULL;
> +
> +     addr = pop_hyp_memcache(mc, hyp_phys_to_virt);
> +     if (!addr)
> +             return addr;
> +     used_pg[snap->used_pages_indx++] = hyp_virt_to_phys(addr);
> +
> +     memset(addr, 0, PAGE_SIZE);
> +     p = hyp_virt_to_page(addr);
> +     memset(p, 0, sizeof(*p));
> +
> +     return addr;
> +}
> +
> +static void snap_free_pages_exact(void *addr, unsigned long size)
> +{
> +     u8 order = get_order(size);
> +     unsigned int i;
> +     struct hyp_page *p;
> +
> +     for (i = 0; i < (1 << order); i++) {
> +             p = hyp_virt_to_page(addr + (i * PAGE_SIZE));
> +             hyp_page_ref_dec(p);
> +     }
> +}
> +
> +static void *pkvm_setup_snapshot(struct kvm_pgtable_snapshot *snap_hva)
> +{
> +     unsigned long i;
> +     void *pgd, *used_pg;
> +     phys_addr_t mc_page, next_mc_page;
> +     struct kvm_pgtable_snapshot *snap;
> +
> +     snap = (void *)kern_hyp_va(snap_hva);
> +     if (!PAGE_ALIGNED(snap))
> +             return NULL;
> +
> +     if (__pkvm_host_donate_hyp(hyp_virt_to_pfn(snap), 1))
> +             return NULL;
> +
> +     pgd = kern_hyp_va(snap->pgd_hva);
> +     if (!PAGE_ALIGNED(pgd))
> +             goto error_with_snapshot;
> +
> +     if (__pkvm_host_donate_hyp(hyp_virt_to_pfn(pgd), snap->pgd_pages))
> +             goto error_with_snapshot;
> +
> +     mc_page = snap->mc.head;
> +     for (i = 0; i < snap->mc.nr_pages; i++) {
> +             if (!PAGE_ALIGNED(mc_page))
> +                     goto error_with_memcache;
> +
> +             if (__pkvm_host_donate_hyp(hyp_phys_to_pfn(mc_page), 1))
> +                     goto error_with_memcache;
> +
> +             mc_page = *((phys_addr_t *)hyp_phys_to_virt(mc_page));
> +     }
> +
> +     used_pg = kern_hyp_va(snap->used_pages_hva);
> +     if (!PAGE_ALIGNED(used_pg))
> +             goto error_with_memcache;
> +
> +     if (__pkvm_host_donate_hyp(hyp_virt_to_pfn(used_pg), snap->num_used_pages))
> +             goto error_with_memcache;
> +
> +     return snap;
> +error_with_memcache:
> +     mc_page = snap->mc.head;
> +     for (; i >= 0; i--) {
> +             next_mc_page = *((phys_addr_t *)hyp_phys_to_virt(mc_page));
> +             WARN_ON(__pkvm_hyp_donate_host(hyp_phys_to_pfn(mc_page), 1));
> +             mc_page = next_mc_page;
> +     }
> +
> +     WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(pgd), snap->pgd_pages));
> +error_with_snapshot:
> +     WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(snap), 1));
> +     return NULL;
> +}
> +
> +static void pkvm_teardown_snapshot(struct kvm_pgtable_snapshot *snap)
> +{
> +     size_t i;
> +     phys_addr_t mc_page, next_mc_page;
> +     u64 *used_pg = kern_hyp_va(snap->used_pages_hva);
> +     void *pgd = kern_hyp_va(snap->pgd_hva);
> +
> +     for (i = 0; i < snap->used_pages_indx; i++) {
> +             mc_page = used_pg[i];
> +             WARN_ON(__pkvm_hyp_donate_host(hyp_phys_to_pfn(mc_page), 1));
> +     }
> +
> +     WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(used_pg),
> +                                    snap->num_used_pages));
> +
> +     mc_page = snap->mc.head;
> +     for (i = 0; i < snap->mc.nr_pages; i++) {
> +             next_mc_page = *((phys_addr_t *)hyp_phys_to_virt(mc_page));
> +             WARN_ON(__pkvm_hyp_donate_host(hyp_phys_to_pfn(mc_page), 1));
> +             mc_page = next_mc_page;
> +     }
> +
> +     snap->pgtable.mm_ops = NULL;
> +     WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(pgd), snap->pgd_pages));
> +     WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(snap), 1));
> +}
> +
> +static int pkvm_host_stage2_snapshot(struct kvm_pgtable_snapshot *snap)
> +{
> +     int ret;
> +     void *pgd;
> +     size_t required_pgd_len;
> +     struct kvm_pgtable_mm_ops mm_ops = {0};
> +     struct kvm_s2_mmu *mmu;
> +     struct kvm_pgtable *to_pgt, *from_pgt;
> +
> +     if (snap->used_pages_indx != 0)
> +             return -EINVAL;
> +
> +     from_pgt = &host_mmu.pgt;
> +     mmu = &host_mmu.arch.mmu;
> +     required_pgd_len = kvm_pgtable_stage2_pgd_size(mmu->vtcr);
> +     if (snap->pgd_pages < (required_pgd_len >> PAGE_SHIFT))
> +             return -ENOMEM;
> +
> +     if (snap->mc.nr_pages < host_s2_pgtable_pages())
> +             return -ENOMEM;
> +
> +     to_pgt = &snap->pgtable;
> +     pgd = kern_hyp_va(snap->pgd_hva);
> +
> +     mm_ops.zalloc_page              = snap_zalloc_page;
> +     mm_ops.free_pages_exact         = snap_free_pages_exact;
> +     mm_ops.phys_to_virt             = hyp_phys_to_virt;
> +     mm_ops.virt_to_phys             = hyp_virt_to_phys;
> +     mm_ops.page_count               = hyp_page_count;
> +
> +     to_pgt->ia_bits         = from_pgt->ia_bits;
> +     to_pgt->start_level     = from_pgt->start_level;
> +     to_pgt->flags           = from_pgt->flags;
> +     to_pgt->mm_ops          = &mm_ops;
> +
> +     host_lock_component();
> +
> +     to_pgt->pgd = pgd;
> +     memcpy(to_pgt->pgd, from_pgt->pgd, required_pgd_len);
> +     ret = kvm_pgtable_stage2_snapshot(to_pgt, &snap->mc);
> +
> +     host_unlock_component();
> +
> +     return ret;
> +}
> +
> +int __pkvm_host_stage2_snapshot(struct kvm_pgtable_snapshot *snap_hva)
> +{
> +     int ret;
> +     struct kvm_pgtable_snapshot *snap;
> +     kvm_pteref_t pgd;
> +
> +     snap = pkvm_setup_snapshot(snap_hva);
> +     if (!snap)
> +             return -EPERM;
> +
> +     ret = pkvm_host_stage2_snapshot(snap);
> +     if (!ret) {
> +             pgd = snap->pgtable.pgd;
> +             snap->pgtable.pgd = (kvm_pteref_t)__hyp_pa(pgd);
> +     }
> +     pkvm_teardown_snapshot(snap);
> +     return ret;
> +}
> +#endif /* CONFIG_NVHE_EL2_DEBUG */
> +
>  void reclaim_guest_pages(struct pkvm_hyp_vm *vm, struct kvm_hyp_memcache *mc)
>  {
>       void *addr;
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 1966fdee7..82fef9620 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -1598,3 +1598,46 @@ void kvm_pgtable_stage2_free_unlinked(struct kvm_pgtable_mm_ops *mm_ops, void *p
>       WARN_ON(mm_ops->page_count(pgtable) != 1);
>       mm_ops->put_page(pgtable);
>  }
> +
> +#ifdef CONFIG_NVHE_EL2_DEBUG
> +static int snapshot_walker(const struct kvm_pgtable_visit_ctx *ctx,
> +                        enum kvm_pgtable_walk_flags visit)
> +{
> +     struct kvm_pgtable_mm_ops *mm_ops = ctx->mm_ops;
> +     void *copy_table, *original_addr;
> +     kvm_pte_t new = ctx->old;
> +
> +     if (!stage2_pte_is_counted(ctx->old))
> +             return 0;
> +
> +     if (kvm_pte_table(ctx->old, ctx->level)) {
> +             copy_table = mm_ops->zalloc_page(ctx->arg);
> +             if (!copy_table)
> +                     return -ENOMEM;
> +
> +             original_addr = kvm_pte_follow(ctx->old, mm_ops);
> +
> +             memcpy(copy_table, original_addr, PAGE_SIZE);
> +             new = kvm_init_table_pte(copy_table, mm_ops);
> +     }
> +
> +     *ctx->ptep = new;
> +
> +     return 0;
> +}
> +
> +int kvm_pgtable_stage2_snapshot(struct kvm_pgtable *to_pgt, void *mc)
> +{
> +     struct kvm_pgtable_walker walker = {
> +             .cb     = snapshot_walker,
> +             .flags  = KVM_PGTABLE_WALK_LEAF |
> +                       KVM_PGTABLE_WALK_TABLE_PRE,
> +             .arg = mc
> +     };
> +
> +     if (!to_pgt->pgd)
> +             return -ENOMEM;
> +
> +     return kvm_pgtable_walk(to_pgt, 0, BIT(to_pgt->ia_bits), &walker);
> +}
> +#endif /* CONFIG_NVHE_EL2_DEBUG */
> --
> 2.43.0.472.g3155946c3a-goog
>


From sebastianene at google.com  Tue Dec 19 03:45:55 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Tue, 19 Dec 2023 11:45:55 +0000
Subject: [PATCH v4 03/10] KVM: arm64: Invoke the snapshot interface for
 the host stage-2 pagetable
In-Reply-To: <20231218135859.2513568-5-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
 <20231218135859.2513568-5-sebastianene@google.com>
Message-ID: <ZYGCcxhGuXlP4mbY@google.com>

On Mon, Dec 18, 2023 at 01:58:53PM +0000, Sebastian Ene wrote:
> Allocate memory for the snapshot by creating a memory cache with empty
> pages that will be used by the hypervisor during the page table copy.
> Get the required size of the PGD and allocate physically contiguous
> memory for it. Allocate contiguous memory for an array that is used to
> keep track of the pages used from the memcache. Call the snapshot
> interface and release the memory for the snapshot.
> 
> Signed-off-by: Sebastian Ene <sebastianene at google.com>
> ---
>  arch/arm64/kvm/ptdump.c | 107 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 107 insertions(+)
> 
> diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> index 5816fc632..e99bab427 100644
> --- a/arch/arm64/kvm/ptdump.c
> +++ b/arch/arm64/kvm/ptdump.c
> @@ -25,6 +25,9 @@ static int kvm_ptdump_open(struct inode *inode, struct file *file);
>  static int kvm_ptdump_release(struct inode *inode, struct file *file);
>  static int kvm_ptdump_show(struct seq_file *m, void *);
>  
> +static phys_addr_t get_host_pa(void *addr);
> +static void *get_host_va(phys_addr_t pa);
> +
>  static const struct file_operations kvm_ptdump_fops = {
>  	.open		= kvm_ptdump_open,
>  	.read		= seq_read,
> @@ -32,6 +35,11 @@ static const struct file_operations kvm_ptdump_fops = {
>  	.release	= kvm_ptdump_release,
>  };
>  
> +static struct kvm_pgtable_mm_ops ptdump_host_mmops = {
> +	.phys_to_virt	= get_host_va,
> +	.virt_to_phys	= get_host_pa,
> +};
> +
>  static int kvm_ptdump_open(struct inode *inode, struct file *file)
>  {
>  	struct kvm_ptdump_register *reg = inode->i_private;
> @@ -78,11 +86,110 @@ static void kvm_ptdump_debugfs_register(struct kvm_ptdump_register *reg,
>  
>  static struct kvm_ptdump_register host_reg;
>  
> +static size_t host_stage2_get_pgd_len(void)
> +{
> +	u32 phys_shift = get_kvm_ipa_limit();
> +	u64 vtcr = kvm_get_vtcr(read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1),
> +				read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1),
> +				phys_shift);
> +	return (kvm_pgtable_stage2_pgd_size(vtcr) >> PAGE_SHIFT);
> +}
> +
> +static phys_addr_t get_host_pa(void *addr)
> +{
> +	return __pa(addr);
> +}
> +
> +static void *get_host_va(phys_addr_t pa)
> +{
> +	return __va(pa);
> +}
> +
> +static void kvm_host_put_ptdump_info(void *snap)
> +{
> +	void *mc_page;
> +	size_t i;
> +	struct kvm_pgtable_snapshot *snapshot;
> +
> +	if (!snap)
> +		return;
> +
> +	snapshot = snap;
> +	while ((mc_page = pop_hyp_memcache(&snapshot->mc, get_host_va)) != NULL)
> +		free_page((unsigned long)mc_page);
> +
> +	if (snapshot->pgd_hva)
> +		free_pages_exact(snapshot->pgd_hva, snapshot->pgd_pages);
> +
> +	if (snapshot->used_pages_hva) {
> +		for (i = 0; i < snapshot->used_pages_indx; i++) {
> +			mc_page = get_host_va(snapshot->used_pages_hva[i]);
> +			free_page((unsigned long)mc_page);
> +		}
> +
> +		free_pages_exact(snapshot->used_pages_hva, snapshot->num_used_pages);
> +	}
> +
> +	free_page((unsigned long)snapshot);
> +}
> +
> +static void *kvm_host_get_ptdump_info(struct kvm_ptdump_register *reg)
> +{
> +	int i, ret;
> +	void *mc_page;
> +	struct kvm_pgtable_snapshot *snapshot;
> +	size_t memcache_len;
> +
> +	snapshot = (void *)__get_free_page(GFP_KERNEL_ACCOUNT);
> +	if (!snapshot)
> +		return NULL;
> +
> +	memset(snapshot, 0, sizeof(struct kvm_pgtable_snapshot));
> +
> +	snapshot->pgd_pages = host_stage2_get_pgd_len();
> +	snapshot->pgd_hva = alloc_pages_exact(snapshot->pgd_pages, GFP_KERNEL_ACCOUNT);

The allocation should be specified in the number of bytes here.

> +	if (!snapshot->pgd_hva)
> +		goto err;
> +
> +	memcache_len = (size_t)reg->priv;
> +	for (i = 0; i < memcache_len; i++) {
> +		mc_page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT);
> +		if (!mc_page)
> +			goto err;
> +
> +		push_hyp_memcache(&snapshot->mc, mc_page, get_host_pa);
> +	}
> +
> +	snapshot->num_used_pages = DIV_ROUND_UP(sizeof(phys_addr_t) * memcache_len,
> +					     PAGE_SIZE);
> +	snapshot->used_pages_hva = alloc_pages_exact(snapshot->num_used_pages,
> +						  GFP_KERNEL_ACCOUNT);

the same as previous comment.

> +	if (!snapshot->used_pages_hva)
> +		goto err;
> +
> +	ret = kvm_call_hyp_nvhe(__pkvm_host_stage2_snapshot, snapshot);
> +	if (ret) {
> +		pr_err("ERROR %d snapshot host pagetables\n", ret);
> +		goto err;
> +	}
> +
> +	snapshot->pgtable.pgd = get_host_va((phys_addr_t)snapshot->pgtable.pgd);
> +	snapshot->pgtable.mm_ops = &ptdump_host_mmops;
> +
> +	return snapshot;
> +err:
> +	kvm_host_put_ptdump_info(snapshot);
> +	return NULL;
> +}
> +
>  void kvm_ptdump_register_host(void)
>  {
>  	if (!is_protected_kvm_enabled())
>  		return;
>  
> +	host_reg.get_ptdump_info = kvm_host_get_ptdump_info;
> +	host_reg.put_ptdump_info = kvm_host_put_ptdump_info;
> +
>  	kvm_ptdump_debugfs_register(&host_reg, "host_page_tables",
>  				    kvm_debugfs_dir);
>  }
> -- 
> 2.43.0.472.g3155946c3a-goog
> 


From sebastianene at google.com  Tue Dec 19 03:47:40 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Tue, 19 Dec 2023 11:47:40 +0000
Subject: [PATCH v4 02/10] KVM: arm64: Add ptdump registration with
 debugfs for the stage-2 pagetables
In-Reply-To: <20231218135859.2513568-4-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
 <20231218135859.2513568-4-sebastianene@google.com>
Message-ID: <ZYGC3F_UJB8U_wuD@google.com>

On Mon, Dec 18, 2023 at 01:58:52PM +0000, Sebastian Ene wrote:
> While arch/*/mem/ptdump handles the kernel pagetable dumping code,
> introduce KVM/ptdump which deals with the stage-2 pagetables. The
> separation is necessary because most of the definitions from the
> stage-2 pagetable reside in the KVM path and we will be invoking
> functionality **specific** to KVM.
> 
> This registers a wrapper on top of debugfs_create_file which allows us
> to hook callbacks on the debugfs open/show/close. The callbacks are used
> to prepare the display portion of the pagetable dumping code.
> Guard this functionality under the newly introduced PTDUMP_STAGE2_DEBUGFS.
> 
> Signed-off-by: Sebastian Ene <sebastianene at google.com>
> ---
>  arch/arm64/kvm/Kconfig      | 13 +++++
>  arch/arm64/kvm/Makefile     |  1 +
>  arch/arm64/kvm/arm.c        |  2 +
>  arch/arm64/kvm/kvm_ptdump.h | 18 +++++++
>  arch/arm64/kvm/ptdump.c     | 96 +++++++++++++++++++++++++++++++++++++
>  5 files changed, 130 insertions(+)
>  create mode 100644 arch/arm64/kvm/kvm_ptdump.h
>  create mode 100644 arch/arm64/kvm/ptdump.c
> 
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index 83c1e09be..0014e55e2 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -71,4 +71,17 @@ config PROTECTED_NVHE_STACKTRACE
>  
>  	  If unsure, or not using protected nVHE (pKVM), say N.
>  
> +config PTDUMP_STAGE2_DEBUGFS
> +       bool "Present the stage-2 pagetables to debugfs"
> +       depends on PTDUMP_DEBUGFS && KVM
> +       default n
> +       help
> +         Say Y here if you want to show the stage-2 kernel pagetables
> +         layout in a debugfs file. This information is only useful for kernel developers
> +         who are working in architecture specific areas of the kernel.
> +         It is probably not a good idea to enable this feature in a production
> +         kernel.
> +
> +         If in doubt, say N.
> +
>  endif # VIRTUALIZATION
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index c0c050e53..190eac175 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -23,6 +23,7 @@ kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
>  	 vgic/vgic-its.o vgic/vgic-debug.o
>  
>  kvm-$(CONFIG_HW_PERF_EVENTS)  += pmu-emul.o pmu.o
> +kvm-$(CONFIG_PTDUMP_STAGE2_DEBUGFS) += ptdump.o
>  
>  always-y := hyp_constants.h hyp-constants.s
>  
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index e5f75f1f1..ee8d7cb67 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -40,6 +40,7 @@
>  #include <asm/kvm_pkvm.h>
>  #include <asm/kvm_emulate.h>
>  #include <asm/sections.h>
> +#include <kvm_ptdump.h>
>  
>  #include <kvm/arm_hypercalls.h>
>  #include <kvm/arm_pmu.h>
> @@ -2592,6 +2593,7 @@ static __init int kvm_arm_init(void)
>  	if (err)
>  		goto out_subs;
>  
> +	kvm_ptdump_register_host();
>  	kvm_arm_initialised = true;
>  
>  	return 0;
> diff --git a/arch/arm64/kvm/kvm_ptdump.h b/arch/arm64/kvm/kvm_ptdump.h
> new file mode 100644
> index 000000000..98b595ce8
> --- /dev/null
> +++ b/arch/arm64/kvm/kvm_ptdump.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +//
> +// Copyright (C) Google, 2023
> +// Author: Sebastian Ene <sebastianene at google.com>
> +
> +#ifndef __KVM_PTDUMP_H
> +#define __KVM_PTDUMP_H
> +
> +#include <asm/ptdump.h>
> +
> +
> +#ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
> +void kvm_ptdump_register_host(void);
> +#else
> +static inline void kvm_ptdump_register_host(void) { }
> +#endif /* CONFIG_PTDUMP_STAGE2_DEBUGFS */
> +
> +#endif /* __KVM_PTDUMP_H */
> diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> new file mode 100644
> index 000000000..5816fc632
> --- /dev/null
> +++ b/arch/arm64/kvm/ptdump.c
> @@ -0,0 +1,96 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// Debug helper used to dump the stage-2 pagetables of the system and their
> +// associated permissions.
> +//
> +// Copyright (C) Google, 2023
> +// Author: Sebastian Ene <sebastianene at google.com>
> +
> +#include <linux/debugfs.h>
> +#include <linux/kvm_host.h>
> +#include <linux/seq_file.h>
> +
> +#include <asm/kvm_pkvm.h>
> +#include <kvm_ptdump.h>
> +
> +
> +struct kvm_ptdump_register {
> +	void *(*get_ptdump_info)(struct kvm_ptdump_register *reg);
> +	void (*put_ptdump_info)(void *priv);
> +	int (*show_ptdump_info)(struct seq_file *m, void *v);
> +	void *priv;
> +};
> +
> +static int kvm_ptdump_open(struct inode *inode, struct file *file);
> +static int kvm_ptdump_release(struct inode *inode, struct file *file);
> +static int kvm_ptdump_show(struct seq_file *m, void *);
> +
> +static const struct file_operations kvm_ptdump_fops = {
> +	.open		= kvm_ptdump_open,
> +	.read		= seq_read,
> +	.llseek		= seq_lseek,
> +	.release	= kvm_ptdump_release,
> +};
> +
> +static int kvm_ptdump_open(struct inode *inode, struct file *file)
> +{
> +	struct kvm_ptdump_register *reg = inode->i_private;
> +	void *info = NULL;
> +	int ret;
> +
> +	if (reg->get_ptdump_info) {
> +		info = reg->get_ptdump_info(reg);
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	if (!reg->show_ptdump_info)
> +		reg->show_ptdump_info = kvm_ptdump_show;
> +
> +	ret = single_open(file, reg->show_ptdump_info, info);
> +	if (ret && reg->put_ptdump_info)
> +		reg->put_ptdump_info(info);
> +
> +	return ret;
> +}
> +
> +static int kvm_ptdump_release(struct inode *inode, struct file *file)
> +{
> +	struct kvm_ptdump_register *reg = inode->i_private;
> +	struct seq_file *seq_file = file->private_data;
> +
> +	if (reg->put_ptdump_info)
> +		reg->put_ptdump_info(seq_file->private);
> +

Call single_release here.

> +	return 0;
> +}
> +
> +static int kvm_ptdump_show(struct seq_file *m, void *)
> +{
> +	return -EINVAL;
> +}
> +
> +static void kvm_ptdump_debugfs_register(struct kvm_ptdump_register *reg,
> +					const char *name, struct dentry *parent)
> +{
> +	debugfs_create_file(name, 0400, parent, reg, &kvm_ptdump_fops);
> +}
> +
> +static struct kvm_ptdump_register host_reg;
> +
> +void kvm_ptdump_register_host(void)
> +{
> +	if (!is_protected_kvm_enabled())
> +		return;
> +
> +	kvm_ptdump_debugfs_register(&host_reg, "host_page_tables",
> +				    kvm_debugfs_dir);
> +}
> +
> +static int __init kvm_host_ptdump_init(void)
> +{
> +	host_reg.priv = (void *)host_s2_pgtable_pages();
> +	return 0;
> +}
> +
> +device_initcall(kvm_host_ptdump_init);
> -- 
> 2.43.0.472.g3155946c3a-goog
> 


From sebastianene at google.com  Tue Dec 19 03:52:22 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Tue, 19 Dec 2023 11:52:22 +0000
Subject: [PATCH v4 10/10] arm64: ptdump: Add guest stage-2 pagetables
 dumping
In-Reply-To: <20231218135859.2513568-12-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
 <20231218135859.2513568-12-sebastianene@google.com>
Message-ID: <ZYGD9qWqHgICBCp8@google.com>

On Mon, Dec 18, 2023 at 01:59:00PM +0000, Sebastian Ene wrote:
> Register a debugfs file on guest creation to be able to view their
> second translation tables with ptdump. This assumes that the host is in
> control of the guest stage-2 and has direct access to the pagetables.
> 
> Signed-off-by: Sebastian Ene <sebastianene at google.com>
> ---
>  arch/arm64/kvm/debug.c      |  6 ++++++
>  arch/arm64/kvm/kvm_ptdump.h |  3 +++
>  arch/arm64/kvm/ptdump.c     | 35 ++++++++++++++++++++++++++++++++---
>  3 files changed, 41 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 8725291cb..7c4c2902d 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -13,6 +13,7 @@
>  #include <asm/kvm_asm.h>
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_emulate.h>
> +#include <kvm_ptdump.h>
>  
>  #include "trace.h"
>  
> @@ -342,3 +343,8 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_SPE);
>  	vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>  }
> +
> +int kvm_arch_create_vm_debugfs(struct kvm *kvm)
> +{
> +	return kvm_ptdump_register_guest(kvm);
> +}
> diff --git a/arch/arm64/kvm/kvm_ptdump.h b/arch/arm64/kvm/kvm_ptdump.h
> index 98b595ce8..5f5a455d0 100644
> --- a/arch/arm64/kvm/kvm_ptdump.h
> +++ b/arch/arm64/kvm/kvm_ptdump.h
> @@ -6,13 +6,16 @@
>  #ifndef __KVM_PTDUMP_H
>  #define __KVM_PTDUMP_H
>  
> +#include <linux/kvm_host.h>
>  #include <asm/ptdump.h>
>  
>  
>  #ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
>  void kvm_ptdump_register_host(void);
> +int kvm_ptdump_register_guest(struct kvm *kvm);
>  #else
>  static inline void kvm_ptdump_register_host(void) { }
> +static inline int kvm_ptdump_register_guest(struct kvm *kvm) { return -1; }
>  #endif /* CONFIG_PTDUMP_STAGE2_DEBUGFS */
>  
>  #endif /* __KVM_PTDUMP_H */
> diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> index 4296e739f..62a753d6b 100644
> --- a/arch/arm64/kvm/ptdump.c
> +++ b/arch/arm64/kvm/ptdump.c
> @@ -181,6 +181,8 @@ static int kvm_ptdump_open(struct inode *inode, struct file *file)
>  		info = reg->get_ptdump_info(reg);
>  		if (!info)
>  			return -ENOMEM;
> +	} else {
> +		info = inode->i_private;

FIXME: Don't call kvm_ptdump_release with this ^ argument.

>  	}
>  
>  	if (!reg->show_ptdump_info)
> @@ -239,15 +241,14 @@ static int kvm_ptdump_visitor(const struct kvm_pgtable_visit_ctx *ctx,
>  	return 0;
>  }
>  
> -static int kvm_ptdump_show(struct seq_file *m, void *)
> +static int kvm_ptdump_show_common(struct seq_file *m,
> +				  struct kvm_pgtable *pgtable)
>  {
>  	u64 ipa_size;
>  	char ipa_description[32];
>  	struct pg_state st;
>  	struct addr_marker ipa_addr_markers[3] = {0};
>  	struct pg_level pg_level_descr[KVM_PGTABLE_MAX_LEVELS] = {0};
> -	struct kvm_pgtable_snapshot *snapshot = m->private;
> -	struct kvm_pgtable *pgtable = &snapshot->pgtable;
>  	struct kvm_pgtable_walker walker = (struct kvm_pgtable_walker) {
>  		.cb	= kvm_ptdump_visitor,
>  		.arg	= &st,
> @@ -282,6 +283,26 @@ static int kvm_ptdump_show(struct seq_file *m, void *)
>  	return kvm_pgtable_walk(pgtable, 0, ipa_size, &walker);
>  }
>  
> +static int kvm_host_ptdump_show(struct seq_file *m, void *)
> +{
> +	struct kvm_pgtable_snapshot *snapshot = m->private;
> +
> +	return kvm_ptdump_show_common(m, &snapshot->pgtable);
> +}
> +
> +static int kvm_ptdump_show(struct seq_file *m, void *)
> +{
> +	struct kvm *guest_kvm = m->private;
> +	struct kvm_s2_mmu *mmu = &guest_kvm->arch.mmu;
> +	int ret;
> +
> +	write_lock(&guest_kvm->mmu_lock);
> +	ret = kvm_ptdump_show_common(m, mmu->pgt);
> +	write_unlock(&guest_kvm->mmu_lock);
> +
> +	return ret;
> +}
> +
>  static void kvm_ptdump_debugfs_register(struct kvm_ptdump_register *reg,
>  					const char *name, struct dentry *parent)
>  {
> @@ -393,11 +414,19 @@ void kvm_ptdump_register_host(void)
>  
>  	host_reg.get_ptdump_info = kvm_host_get_ptdump_info;
>  	host_reg.put_ptdump_info = kvm_host_put_ptdump_info;
> +	host_reg.show_ptdump_info = kvm_host_ptdump_show;
>  
>  	kvm_ptdump_debugfs_register(&host_reg, "host_page_tables",
>  				    kvm_debugfs_dir);
>  }
>  
> +int kvm_ptdump_register_guest(struct kvm *kvm)
> +{
> +	debugfs_create_file("stage2_page_tables", 0400, kvm->debugfs_dentry,
> +			    kvm, &kvm_ptdump_fops);
> +	return 0;
> +}
> +
>  static int __init kvm_host_ptdump_init(void)
>  {
>  	host_reg.priv = (void *)host_s2_pgtable_pages();
> -- 
> 2.43.0.472.g3155946c3a-goog
> 


From olteanv at gmail.com  Tue Dec 19 03:59:17 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Tue, 19 Dec 2023 13:59:17 +0200
Subject: [PATCH 1/1] phy: freescale: phy-fsl-imx8-mipi-dphy: Fix alias
 name to use dashes
In-Reply-To: <4858990.GXAFRqVoOG@steina-w>
References: <20231219090248.3317500-1-alexander.stein@ew.tq-group.com>
 <b01e05ac-8b28-49ad-8a1e-9cd667e5f1ec@lunn.ch>
 <4858990.GXAFRqVoOG@steina-w>
Message-ID: <20231219115917.44egjhs7pypcx7cs@skbuf>

On Tue, Dec 19, 2023 at 10:13:03AM +0100, Alexander Stein wrote:
> Hi Andrew,
> 
> Am Dienstag, 19. Dezember 2023, 10:09:24 CET schrieb Andrew Lunn:
> > On Tue, Dec 19, 2023 at 10:02:48AM +0100, Alexander Stein wrote:
> > > Devicetree spec lists only dashes as valid characters for alias names.
> > > Table 3.2: Valid characters for alias names, Devicee Specification,
> > > Release v0.4
> > > 
> > > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> > > ---
> > > 
> > >  drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c index
> > > e625b32889bf..0928a526e2ab 100644
> > > --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > @@ -706,7 +706,7 @@ static int mixel_dphy_probe(struct platform_device
> > > *pdev)> 
> > >  			return ret;
> > >  		
> > >  		}
> > > 
> > > -		priv->id = of_alias_get_id(np, "mipi_dphy");
> > > +		priv->id = of_alias_get_id(np, "mipi-dphy");
> > 
> > Are there any in tree DT blobs using mipi_dphy which are going to
> > break because of this change?
> 
> You are right, I should have mentioned that already.
> The alias is only used when used on a combo-PHY, which is only i.MX8QXP. Up 
> until now there is no DT node in-kernel which uses the fsl,imx8qxp-mipi-dphy 
> compatible. So no there should be no blobs at all using the old alias name.
> 
> Best regards,
> Alexander

This seems correct. The NXP kernels have this revert commit which
reinforces the fact that this driver does not probe on the
"fsl,imx8qxp-mipi-dphy" compatible string even downstream.
https://github.com/nxp-imx/linux-imx/commit/daf4e70d081a2672ac4a22ff39f6712798a0cc3b
Adding Liu Ying.


From zajec5 at gmail.com  Tue Dec 19 04:01:03 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Tue, 19 Dec 2023 13:01:03 +0100
Subject: [PATCH v6.8 1/2] nvmem: layouts: refactor .add_cells() callback arguments
Message-ID: <20231219120104.3422-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Simply pass whole "struct nvmem_layout" instead of single variables.
There is nothing in "struct nvmem_layout" that we have to hide from
layout drivers. They also access it during .probe() and .remove().

Thanks to this change:

1. API gets more consistent
   All layouts drivers callbacks get the same argument

2. Layouts get correct device
   Before this change NVMEM core code was passing NVMEM device instead
   of layout device. That resulted in:
   * Confusing prints
   * Calling devm_*() helpers on wrong device
   * Helpers like of_device_get_match_data() dereferencing NULLs

3. It gets possible to get match data
   First of all nvmem_layout_get_match_data() requires passing "struct
   nvmem_layout" which .add_cells() callback didn't have before this. It
   doesn't matter much as it's rather useless now anyway (and will be
   dropped).
   What's more important however is that of_device_get_match_data() can
   be used now thanks to owning a proper device pointer.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
Those changes complete layouts refactoring process so I'd very much like
them to go with the rest of refactoring stuff to v6.8.

It's difficult to add Fixes tag due to the nature of refactoring.
Callback .add_cells() existed even before refactoring so I'm not sure
what commit would be fair to blame.

Srini, Greg: could you see if this could still make it into v6.8?

 drivers/nvmem/core.c             | 2 +-
 drivers/nvmem/layouts/onie-tlv.c | 4 +++-
 drivers/nvmem/layouts/sl28vpd.c  | 4 +++-
 include/linux/nvmem-provider.h   | 2 +-
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index ba559e81f77f..441d132ebb61 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -854,7 +854,7 @@ int nvmem_layout_register(struct nvmem_layout *layout)
 		return -EINVAL;
 
 	/* Populate the cells */
-	ret = layout->add_cells(&layout->nvmem->dev, layout->nvmem);
+	ret = layout->add_cells(layout);
 	if (ret)
 		return ret;
 
diff --git a/drivers/nvmem/layouts/onie-tlv.c b/drivers/nvmem/layouts/onie-tlv.c
index b24cc5dcc6ee..9d2ad5f2dc10 100644
--- a/drivers/nvmem/layouts/onie-tlv.c
+++ b/drivers/nvmem/layouts/onie-tlv.c
@@ -182,8 +182,10 @@ static bool onie_tlv_crc_is_valid(struct device *dev, size_t table_len, u8 *tabl
 	return true;
 }
 
-static int onie_tlv_parse_table(struct device *dev, struct nvmem_device *nvmem)
+static int onie_tlv_parse_table(struct nvmem_layout *layout)
 {
+	struct nvmem_device *nvmem = layout->nvmem;
+	struct device *dev = &layout->dev;
 	struct onie_tlv_hdr hdr;
 	size_t table_len, data_len, hdr_len;
 	u8 *table, *data;
diff --git a/drivers/nvmem/layouts/sl28vpd.c b/drivers/nvmem/layouts/sl28vpd.c
index b8ffae646cc2..53fa50f17dca 100644
--- a/drivers/nvmem/layouts/sl28vpd.c
+++ b/drivers/nvmem/layouts/sl28vpd.c
@@ -80,8 +80,10 @@ static int sl28vpd_v1_check_crc(struct device *dev, struct nvmem_device *nvmem)
 	return 0;
 }
 
-static int sl28vpd_add_cells(struct device *dev, struct nvmem_device *nvmem)
+static int sl28vpd_add_cells(struct nvmem_layout *layout)
 {
+	struct nvmem_device *nvmem = layout->nvmem;
+	struct device *dev = &layout->dev;
 	const struct nvmem_cell_info *pinfo;
 	struct nvmem_cell_info info = {0};
 	struct device_node *layout_np;
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index 6fe65b35ea97..81a67642ac55 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -173,7 +173,7 @@ struct nvmem_cell_table {
 struct nvmem_layout {
 	struct device dev;
 	struct nvmem_device *nvmem;
-	int (*add_cells)(struct device *dev, struct nvmem_device *nvmem);
+	int (*add_cells)(struct nvmem_layout *layout);
 };
 
 struct nvmem_layout_driver {
-- 
2.35.3



From zajec5 at gmail.com  Tue Dec 19 04:01:04 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Tue, 19 Dec 2023 13:01:04 +0100
Subject: [PATCH v6.8 2/2] nvmem: drop nvmem_layout_get_match_data()
In-Reply-To: <20231219120104.3422-1-zajec5@gmail.com>
References: <20231219120104.3422-1-zajec5@gmail.com>
Message-ID: <20231219120104.3422-2-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Thanks for layouts refactoring we now have "struct device" associated
with layout. Also its OF pointer points directly to the "nvmem-layout"
DT node.

All it takes to get match data is a generic of_device_get_match_data().

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 drivers/nvmem/core.c           | 13 -------------
 include/linux/nvmem-provider.h | 10 ----------
 2 files changed, 23 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 441d132ebb61..4ed54076346d 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -876,19 +876,6 @@ void nvmem_layout_unregister(struct nvmem_layout *layout)
 }
 EXPORT_SYMBOL_GPL(nvmem_layout_unregister);
 
-const void *nvmem_layout_get_match_data(struct nvmem_device *nvmem,
-					struct nvmem_layout *layout)
-{
-	struct device_node __maybe_unused *layout_np;
-	const struct of_device_id *match;
-
-	layout_np = of_nvmem_layout_get_container(nvmem);
-	match = of_match_node(layout->dev.driver->of_match_table, layout_np);
-
-	return match ? match->data : NULL;
-}
-EXPORT_SYMBOL_GPL(nvmem_layout_get_match_data);
-
 /**
  * nvmem_register() - Register a nvmem device for given nvmem_config.
  * Also creates a binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index 81a67642ac55..f0ba0e03218f 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -205,9 +205,6 @@ void nvmem_layout_driver_unregister(struct nvmem_layout_driver *drv);
 	module_driver(__nvmem_layout_driver, nvmem_layout_driver_register, \
 		      nvmem_layout_driver_unregister)
 
-const void *nvmem_layout_get_match_data(struct nvmem_device *nvmem,
-					struct nvmem_layout *layout);
-
 #else
 
 static inline struct nvmem_device *nvmem_register(const struct nvmem_config *c)
@@ -238,13 +235,6 @@ static inline int nvmem_layout_register(struct nvmem_layout *layout)
 
 static inline void nvmem_layout_unregister(struct nvmem_layout *layout) {}
 
-static inline const void *
-nvmem_layout_get_match_data(struct nvmem_device *nvmem,
-			    struct nvmem_layout *layout)
-{
-	return NULL;
-}
-
 #endif /* CONFIG_NVMEM */
 
 #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
-- 
2.35.3



From konrad.dybcio at linaro.org  Tue Dec 19 04:06:13 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Tue, 19 Dec 2023 13:06:13 +0100
Subject: [PATCH 1/2] arm64: dts: qcom: sm8650-qrd: add USB-C Altmode
 Support
In-Reply-To: <20231218-topic-sm8650-upstream-altmode-v1-1-7900660693cf@linaro.org>
References: <20231218-topic-sm8650-upstream-altmode-v1-0-7900660693cf@linaro.org>
 <20231218-topic-sm8650-upstream-altmode-v1-1-7900660693cf@linaro.org>
Message-ID: <5b453356-f2bd-4703-8761-5311b5964f6c@linaro.org>

On 18.12.2023 11:26, Neil Armstrong wrote:
> Add the necessary nodes to support the USB-C Altmode path by
> adding the following
> - WCD939x USBSS Mux I2C device
> - nb7vpq904m Redriver I2C device
> - Port/Endpoint graph links bettween PMIC-Glink, Mux, Redriver and USB PHY nodes.
> 
> WCD939x USBSS port 2 Path to Codec will be added later when Audio support
> is added.
> 
> Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
> ---
[...]

> +&i2c3 {
> +       status = "ok";
"okay"
[...]

> +&i2c6 {
> +	status = "ok";
"okay"


Konrad


From wsa at kernel.org  Tue Dec 19 04:13:06 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 19 Dec 2023 13:13:06 +0100
Subject: [PATCH v5 00/20] remove I2C_CLASS_DDC support
In-Reply-To: <ZV/FNWfw0jdXSglr@ninjato>
References: <20231123094040.592-1-hkallweit1@gmail.com>
 <ZV/FNWfw0jdXSglr@ninjato>
Message-ID: <ZYGI0j1sQKWHyjgF@shikoro>


> I created an immutable branch for this which the buildbots will
> hopefully check over night. I will reply with comments tomorrow when I
> got the buildbot results.

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/bec045d1/attachment-0001.sig>

From neil.armstrong at linaro.org  Tue Dec 19 04:20:13 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Tue, 19 Dec 2023 13:20:13 +0100
Subject: [PATCH 1/2] arm64: dts: qcom: sm8650-qrd: add USB-C Altmode
 Support
In-Reply-To: <5b453356-f2bd-4703-8761-5311b5964f6c@linaro.org>
References: <20231218-topic-sm8650-upstream-altmode-v1-0-7900660693cf@linaro.org>
 <20231218-topic-sm8650-upstream-altmode-v1-1-7900660693cf@linaro.org>
 <5b453356-f2bd-4703-8761-5311b5964f6c@linaro.org>
Message-ID: <05473bb7-28ec-452e-9fc7-8f244c8b5de3@linaro.org>

On 19/12/2023 13:06, Konrad Dybcio wrote:
> On 18.12.2023 11:26, Neil Armstrong wrote:
>> Add the necessary nodes to support the USB-C Altmode path by
>> adding the following
>> - WCD939x USBSS Mux I2C device
>> - nb7vpq904m Redriver I2C device
>> - Port/Endpoint graph links bettween PMIC-Glink, Mux, Redriver and USB PHY nodes.
>>
>> WCD939x USBSS port 2 Path to Codec will be added later when Audio support
>> is added.
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
>> ---
> [...]
> 
>> +&i2c3 {
>> +       status = "ok";
> "okay"
> [...]
> 
>> +&i2c6 {
>> +	status = "ok";
> "okay"

Thanks, I should have passed DTBS_CHECK first...

> 
> 
> Konrad



From olteanv at gmail.com  Tue Dec 19 04:20:34 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Tue, 19 Dec 2023 14:20:34 +0200
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
In-Reply-To: <20231218162326.173127-2-romain.gantois@bootlin.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <20231218162326.173127-2-romain.gantois@bootlin.com>
Message-ID: <20231219122034.pg2djgrosa4irubh@skbuf>

Hi Romain,

On Mon, Dec 18, 2023 at 05:23:23PM +0100, Romain Gantois wrote:
> Some stmmac cores have Checksum Offload Engines that cannot handle DSA tags
> properly. These cores find the IP/TCP headers on their own and end up
> computing an incorrect checksum when a DSA tag is inserted between the MAC
> header and IP header.
> 
> Add an additional check on stmmac link up so that COE is deactivated
> when the stmmac device is used as a DSA conduit.
> 
> Add a new dma_feature flag to allow cores to signal that their COEs can't
> handle DSA tags on TX.
> 
> Fixes: 6b2c6e4a938f ("net: stmmac: propagate feature flags to vlan")
> Cc: stable at vger.kernel.org
> Reported-by: Richard Tresidder <rtresidd at electromag.com.au>
> Closes: https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2 at electromag.com.au/
> Reported-by: Romain Gantois <romain.gantois at bootlin.com>
> Closes: https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495 at bootlin.com/
> Signed-off-by: Romain Gantois <romain.gantois at bootlin.com>
> ---

DSA_TAG_PROTO_LAN9303, DSA_TAG_PROTO_SJA1105 and DSA_TAG_PROTO_SJA1110
construct tags with ETH_P_8021Q as EtherType. Do you still think it
would be correct to say that all DSA tags break COE on the stmmac, as
this patch assumes?

The NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM convention is not about
statically checking whether the interface using DSA, but about looking
at each packet before deciding whether to use the offload engine or to
call skb_checksum_help().

You can experiment with any tagging protocol on the stmmac driver, and
thus with the controller's response to any kind of traffic, even if the
port is not attached to a hardware switch. You need to enable the
CONFIG_NET_DSA_LOOP option, edit the return value of dsa_loop_get_protocol()
and the "netdev" field of dsa_loop_pdata. The packets need to be
analyzed on the link partner with a packet analysis tool, since there is
no switch to strip the DSA tag.

>  drivers/net/ethernet/stmicro/stmmac/common.h     |  1 +
>  .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c  |  1 +
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c    | 16 +++++++++++++++-
>  3 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> index daf79cdbd3ec..50686cdc3320 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
> @@ -264,6 +264,7 @@ static int dwmac1000_get_hw_feature(void __iomem *ioaddr,
>  	dma_cap->number_tx_channel = (hw_cap & DMA_HW_FEAT_TXCHCNT) >> 22;
>  	/* Alternate (enhanced) DESC mode */
>  	dma_cap->enh_desc = (hw_cap & DMA_HW_FEAT_ENHDESSEL) >> 24;
> +	dma_cap->dsa_breaks_tx_coe = 1;
>  
>  	return 0;
>  }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index a9b6b383e863..733348c65e04 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -42,6 +42,7 @@
>  #include <net/page_pool/helpers.h>
>  #include <net/pkt_cls.h>
>  #include <net/xdp_sock_drv.h>
> +#include <net/dsa.h>
>  #include "stmmac_ptp.h"
>  #include "stmmac.h"
>  #include "stmmac_xdp.h"
> @@ -993,8 +994,11 @@ static void stmmac_mac_link_up(struct phylink_config *config,
>  			       int speed, int duplex,
>  			       bool tx_pause, bool rx_pause)
>  {
> -	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
> +	struct net_device *ndev = to_net_dev(config->dev);
> +	struct stmmac_priv *priv = netdev_priv(ndev);
> +	unsigned int tx_queue_cnt;
>  	u32 old_ctrl, ctrl;
> +	int queue;
>  
>  	if ((priv->plat->flags & STMMAC_FLAG_SERDES_UP_AFTER_PHY_LINKUP) &&
>  	    priv->plat->serdes_powerup)
> @@ -1102,6 +1106,16 @@ static void stmmac_mac_link_up(struct phylink_config *config,
>  
>  	if (priv->plat->flags & STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY)
>  		stmmac_hwtstamp_correct_latency(priv, priv);
> +
> +	/* DSA tags break COEs on some cores. Disable TX checksum
> +	 * offloading on those cores if the netdevice is a DSA conduit.
> +	 */
> +	if (priv->dma_cap.dsa_breaks_tx_coe && netdev_uses_dsa(ndev)) {
> +		tx_queue_cnt = priv->plat->tx_queues_to_use;
> +		for (queue = 0; queue < tx_queue_cnt; queue++)
> +			priv->plat->tx_queues_cfg[queue].coe_unsupported = true;
> +	}
> +

The DSA switch driver can load after stmmac_mac_link_up() runs.
This implementation is racy anyway.

>  }
>  
>  static const struct phylink_mac_ops stmmac_phylink_mac_ops = {
> -- 
> 2.43.0
> 
> 

pw-bot: cr


From michael at walle.cc  Tue Dec 19 04:21:40 2023
From: michael at walle.cc (Michael Walle)
Date: Tue, 19 Dec 2023 13:21:40 +0100
Subject: [PATCH v6.8 2/2] nvmem: drop nvmem_layout_get_match_data()
In-Reply-To: <20231219120104.3422-2-zajec5@gmail.com>
References: <20231219120104.3422-1-zajec5@gmail.com>
 <20231219120104.3422-2-zajec5@gmail.com>
Message-ID: <040fbc414bf7404046b12dfed7a1c647@walle.cc>

> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> Thanks for layouts refactoring we now have "struct device" associated
> with layout. Also its OF pointer points directly to the "nvmem-layout"
> DT node.
> 
> All it takes to get match data is a generic of_device_get_match_data().

Isn't device_get_match_data() preferred?

> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Reviewed-by: Michael Walle <michael at walle.cc>

-michael


From neil.armstrong at linaro.org  Tue Dec 19 04:22:11 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Tue, 19 Dec 2023 13:22:11 +0100
Subject: [PATCH v2 0/2] arm64: qcom: sm8650: add support for USB-C Altmode
Message-ID: <20231219-topic-sm8650-upstream-altmode-v2-0-a608528864a3@linaro.org>

This adds the missing bits to support Display Port external
display over the USB-C Altmode support using the Redriver/Retimer
and WCD939x USBSS Mux/Switch to provide the correct switching.

Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
---
Changes in v2:
- replaced "ok" by "okay"
- Link to v1: https://lore.kernel.org/r/20231218-topic-sm8650-upstream-altmode-v1-0-7900660693cf at linaro.org

---
Neil Armstrong (2):
      arm64: dts: qcom: sm8650-qrd: add USB-C Altmode Support
      arm64: defconfig: enable WCD939x USBSS driver as module

 arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 104 +++++++++++++++++++++++++++++++-
 arch/arm64/configs/defconfig            |   1 +
 2 files changed, 103 insertions(+), 2 deletions(-)
---
base-commit: ceb2fe0d438644e1de06b9a6468a1fb8e2199c70
change-id: 20231218-topic-sm8650-upstream-altmode-3ee141fdccff

Best regards,
-- 
Neil Armstrong <neil.armstrong at linaro.org>



From neil.armstrong at linaro.org  Tue Dec 19 04:22:12 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Tue, 19 Dec 2023 13:22:12 +0100
Subject: [PATCH v2 1/2] arm64: dts: qcom: sm8650-qrd: add USB-C Altmode
 Support
In-Reply-To: <20231219-topic-sm8650-upstream-altmode-v2-0-a608528864a3@linaro.org>
References: <20231219-topic-sm8650-upstream-altmode-v2-0-a608528864a3@linaro.org>
Message-ID: <20231219-topic-sm8650-upstream-altmode-v2-1-a608528864a3@linaro.org>

Add the necessary nodes to support the USB-C Altmode path by
adding the following
- WCD939x USBSS Mux I2C device
- nb7vpq904m Redriver I2C device
- Port/Endpoint graph links bettween PMIC-Glink, Mux, Redriver and USB PHY nodes.

WCD939x USBSS port 2 Path to Codec will be added later when Audio support
is added.

Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 104 +++++++++++++++++++++++++++++++-
 1 file changed, 102 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
index 592a67a47c78..a6f55191e107 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
@@ -77,9 +77,17 @@ port at 1 {
 					reg = <1>;
 
 					pmic_glink_ss_in: endpoint {
-						remote-endpoint = <&usb_1_dwc3_ss>;
+						remote-endpoint = <&redriver_ss_out>;
 					};
 				};
+
+				port at 2 {
+					reg = <2>;
+
+					pmic_glink_sbu: endpoint {
+						remote-endpoint = <&wcd_usbss_sbu_mux>;
+				    };
+				};
 			};
 		};
 	};
@@ -446,6 +454,70 @@ &gpi_dma1 {
 	status = "okay";
 };
 
+&i2c3 {
+       status = "okay";
+
+       wcd_usbss: typec-mux at e {
+		compatible = "qcom,wcd9395-usbss", "qcom,wcd9390-usbss";
+		reg = <0xe>;
+
+		vdd-supply = <&vreg_l15b_1p8>;
+		reset-gpios = <&tlmm 152 GPIO_ACTIVE_HIGH>;
+
+		mode-switch;
+		orientation-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				wcd_usbss_sbu_mux: endpoint {
+					remote-endpoint = <&pmic_glink_sbu>;
+				};
+			};
+		};
+       };
+};
+
+&i2c6 {
+	status = "okay";
+
+	typec-mux at 1c {
+		compatible = "onnn,nb7vpq904m";
+		reg = <0x1c>;
+
+		vcc-supply = <&vreg_l15b_1p8>;
+
+		retimer-switch;
+		orientation-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				redriver_ss_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss_in>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+
+				redriver_ss_in: endpoint {
+					data-lanes = <3 2 1 0>;
+					remote-endpoint = <&usb_dp_qmpphy_out>;
+				};
+			};
+		};
+	};
+};
+
 &ipa {
 	qcom,gsi-loader = "self";
 	memory-region = <&ipa_fw_mem>;
@@ -495,6 +567,15 @@ &mdss_dsi0_phy {
 	status = "okay";
 };
 
+&mdss_dp0 {
+	status = "okay";
+};
+
+&mdss_dp0_out {
+	data-lanes = <0 1>;
+	remote-endpoint = <&usb_dp_qmpphy_dp_in>;
+};
+
 &mdss_mdp {
 	status = "okay";
 };
@@ -600,6 +681,11 @@ &pmk8550_rtc {
 	status = "okay";
 };
 
+&qup_i2c3_data_clk {
+	/* Use internal I2C pull-up */
+	bias-pull-up = <2200>;
+};
+
 &qupv3_id_0 {
 	status = "okay";
 };
@@ -787,7 +873,7 @@ &usb_1_dwc3_hs {
 };
 
 &usb_1_dwc3_ss {
-	remote-endpoint = <&pmic_glink_ss_in>;
+	remote-endpoint = <&usb_dp_qmpphy_usb_ss_in>;
 };
 
 &usb_1_hsphy {
@@ -803,9 +889,23 @@ &usb_dp_qmpphy {
 	vdda-phy-supply = <&vreg_l3i_1p2>;
 	vdda-pll-supply = <&vreg_l3g_0p91>;
 
+	orientation-switch;
+
 	status = "okay";
 };
 
+&usb_dp_qmpphy_dp_in {
+	remote-endpoint = <&mdss_dp0_out>;
+};
+
+&usb_dp_qmpphy_out {
+	remote-endpoint = <&redriver_ss_in>;
+};
+
+&usb_dp_qmpphy_usb_ss_in {
+	remote-endpoint = <&usb_1_dwc3_ss>;
+};
+
 &xo_board {
 	clock-frequency = <76800000>;
 };

-- 
2.34.1



From neil.armstrong at linaro.org  Tue Dec 19 04:22:13 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Tue, 19 Dec 2023 13:22:13 +0100
Subject: [PATCH v2 2/2] arm64: defconfig: enable WCD939x USBSS driver as
 module
In-Reply-To: <20231219-topic-sm8650-upstream-altmode-v2-0-a608528864a3@linaro.org>
References: <20231219-topic-sm8650-upstream-altmode-v2-0-a608528864a3@linaro.org>
Message-ID: <20231219-topic-sm8650-upstream-altmode-v2-2-a608528864a3@linaro.org>

Enable the Qualcomm WCD939x USBSS Type-C mux as module as
is now used on the SM8650 QRD platform.

Signed-off-by: Neil Armstrong <neil.armstrong at linaro.org>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e67a4849b91..c9ba75f1b248 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1067,6 +1067,7 @@ CONFIG_TYPEC_QCOM_PMIC=m
 CONFIG_TYPEC_UCSI=m
 CONFIG_TYPEC_MUX_FSA4480=m
 CONFIG_TYPEC_MUX_NB7VPQ904M=m
+CONFIG_TYPEC_MUX_WCD939X_USBSS=m
 CONFIG_UCSI_CCG=m
 CONFIG_TYPEC_MUX_GPIO_SBU=m
 CONFIG_TYPEC_DP_ALTMODE=m

-- 
2.34.1



From michael at walle.cc  Tue Dec 19 04:24:56 2023
From: michael at walle.cc (Michael Walle)
Date: Tue, 19 Dec 2023 13:24:56 +0100
Subject: [PATCH v6.8 1/2] nvmem: layouts: refactor .add_cells() callback
 arguments
In-Reply-To: <20231219120104.3422-1-zajec5@gmail.com>
References: <20231219120104.3422-1-zajec5@gmail.com>
Message-ID: <dad4bd72d2d133b86385859a6978a72a@walle.cc>

> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> Simply pass whole "struct nvmem_layout" instead of single variables.
> There is nothing in "struct nvmem_layout" that we have to hide from
> layout drivers. They also access it during .probe() and .remove().
> 
> Thanks to this change:
> 
> 1. API gets more consistent
>    All layouts drivers callbacks get the same argument
> 
> 2. Layouts get correct device
>    Before this change NVMEM core code was passing NVMEM device instead
>    of layout device. That resulted in:
>    * Confusing prints
>    * Calling devm_*() helpers on wrong device
>    * Helpers like of_device_get_match_data() dereferencing NULLs
> 
> 3. It gets possible to get match data
>    First of all nvmem_layout_get_match_data() requires passing "struct
>    nvmem_layout" which .add_cells() callback didn't have before this. 
> It
>    doesn't matter much as it's rather useless now anyway (and will be
>    dropped).
>    What's more important however is that of_device_get_match_data() can
>    be used now thanks to owning a proper device pointer.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

LGTM,
Reviewed-by: Michael Walle <michael at walle.cc>


From sunil.vaghela at softnautics.com  Tue Dec 19 04:29:55 2023
From: sunil.vaghela at softnautics.com (Sunil Vaghela)
Date: Tue, 19 Dec 2023 17:59:55 +0530
Subject: [PATCH] ASoC: xilinx: Embed IEC958 sample rate val to channel status register
Message-ID: <20231219122955.104696-1-sunil.vaghela@softnautics.com>

As per IEC 60958 specification, bits 24 to 27 of channel status register
indicates audio sample frequency. If these bits are not set, audio
analyzer always shows 44.1KHz sample rate, irrespective of any sample
rate audio is being played.

This patch fixes the issue by setting IEC958 specified channel status
values for different audio sample rate in [24:27] bits of MM2S Audio
channel status register.

Signed-off-by: Sunil Vaghela <sunil.vaghela at softnautics.com>
---
 sound/soc/xilinx/xlnx_formatter_pcm.c | 74 ++++++++++++++++++++++++++-
 1 file changed, 73 insertions(+), 1 deletion(-)

diff --git a/sound/soc/xilinx/xlnx_formatter_pcm.c b/sound/soc/xilinx/xlnx_formatter_pcm.c
index 299cfb5e2022..041010203ba5 100644
--- a/sound/soc/xilinx/xlnx_formatter_pcm.c
+++ b/sound/soc/xilinx/xlnx_formatter_pcm.c
@@ -451,12 +451,48 @@ xlnx_formatter_pcm_pointer(struct snd_soc_component *component,
 	return bytes_to_frames(runtime, pos);
 }
 
+static u32 xlnx_formatter_get_iec958_ch_status(u32 sample_rate)
+{
+	u32 tmp = 0;
+
+	switch (sample_rate) {
+	case 32000:
+		tmp = IEC958_AES3_CON_FS_32000;
+		break;
+	case 44100:
+		tmp = IEC958_AES3_CON_FS_44100;
+		break;
+	case 48000:
+		tmp = IEC958_AES3_CON_FS_48000;
+		break;
+	case 88200:
+		tmp = IEC958_AES3_CON_FS_88200;
+		break;
+	case 96000:
+		tmp = IEC958_AES3_CON_FS_96000;
+		break;
+	case 176400:
+		tmp = IEC958_AES3_CON_FS_176400;
+		break;
+	case 192000:
+		tmp = IEC958_AES3_CON_FS_192000;
+		break;
+	case 768000:
+		tmp = IEC958_AES3_CON_FS_768000;
+		break;
+	default:
+		tmp = IEC958_AES3_CON_FS_NOTID;
+	}
+		return tmp;
+}
+
 static int xlnx_formatter_pcm_hw_params(struct snd_soc_component *component,
 					struct snd_pcm_substream *substream,
 					struct snd_pcm_hw_params *params)
 {
+	void __iomem *reg;
 	u32 low, high, active_ch, val, bytes_per_ch, bits_per_sample;
-	u32 aes_reg1_val, aes_reg2_val;
+	u32 aes_reg1_val, aes_reg2_val, sample_rate, ch_sts;
 	u64 size;
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct xlnx_pcm_stream_param *stream_data = runtime->private_data;
@@ -533,6 +569,42 @@ static int xlnx_formatter_pcm_hw_params(struct snd_soc_component *component,
 	bytes_per_ch = DIV_ROUND_UP(params_period_bytes(params), active_ch);
 	writel(bytes_per_ch, stream_data->mmio + XLNX_BYTES_PER_CH);
 
+	if ((strstr(adata->nodes[XLNX_PLAYBACK]->name, "hdmi")) ||
+	    (strstr(adata->nodes[XLNX_PLAYBACK]->name, "dp"))) {
+		sample_rate = params_rate(params);
+		dev_info(component->dev, "%s: sample_rate=%d\n", __func__, sample_rate);
+
+		/* As per IEC 60958 standards, whenever transmitting a valid audio
+		 * stream, HDMI/DP Sources shall always include valid and correct
+		 * information in Channel Status bits 24 through 27. For L-PCM audio,
+		 * these bits shall indicate the audio sample frequency. For
+		 * compressed audio formats, these bits shall indicate the IEC 60958
+		 * frame-rate.
+		 *
+		 * Channel Status Bit Number     Sample Frequency or Frame Rate
+		 *   24    25     26    27
+		 *   -----------------------     ------------------------------
+		 *    1     1      0     0                    32 kHz
+		 *    0     0      0     0                    44.1 kHz
+		 *    0     0      0     1                    88.2 kHz
+		 *    0     0      1     1                    176.4 kHz
+		 *    0     1      0     0                    48 kHz
+		 *    0     1      0     1                    96 kHz
+		 *    0     1      1     1                    192 kHz
+		 *    1     0      0     1                    768 kHz
+		 */
+
+		ch_sts = xlnx_formatter_get_iec958_ch_status(sample_rate);
+		dev_info(component->dev, "%s: iec60958 channel status bits 24 to 27 value for sample rate %dHz = 0x%08x\n",
+			 __func__, sample_rate, ch_sts);
+		ch_sts <<= 24;
+		reg = adata->mmio + XLNX_MM2S_OFFSET + XLNX_AUD_CH_STS_START;
+		aes_reg1_val = ioread32(reg);
+		aes_reg1_val |= ch_sts;
+		dev_info(component->dev, "%s: MM2S: AES Encode channel status register value 0x%08x\n",
+			 __func__, aes_reg1_val);
+		iowrite32(aes_reg1_val, reg);
+	}
 	return 0;
 }
 
-- 
2.25.1



From olteanv at gmail.com  Tue Dec 19 04:30:16 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Tue, 19 Dec 2023 14:30:16 +0200
Subject: [PATCH net 0/1] Prevent DSA tags from breaking COE
In-Reply-To: <20231218162326.173127-1-romain.gantois@bootlin.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
Message-ID: <20231219123016.6xy3gamz4lkr5fdz@skbuf>

On Mon, Dec 18, 2023 at 05:23:22PM +0100, Romain Gantois wrote:
> I've run some iperf3 tests and the TX hotpath performance doesn't seem
> to be degraded by the field added to dma_features.

I don't know what CPU cores you are using, but if the iperf3 performance
was line rate at gigabit before and is line rate at gigabit now, you
haven't effectively measured the impact of the change (and "doesn't seem
to be degraded" is a false conclusion). You need something more CPU
intensive to see the difference, like IP forwarding of 64 byte packets.

A very simplistic way to set up IP forwarding between 2 DSA user ports
is to do this on the router board (DUT):

echo 1 > /proc/sys/net/ipv4/ip_forward
ip link set swp0 up && ip addr add 192.168.100.2/24 dev swp0
ip link set swp1 up && ip addr add 192.168.101.2/24 dev swp1

and this on the system with 2 endpoints:

ip netns add ns0
ip link set $ETH1 netns ns0
ip link set $ETH0 up && ip addr add 192.168.100.1/24 dev $ETH0
ip -n ns0 link set $ETH1 up && ip -n ns0 addr add 192.168.101.1/24 dev $ETH1
ip route add 192.168.101.0/24 via 192.168.100.2
ip -n ns0 route add 192.168.100.0/24 via 192.168.101.2
./net-next/samples/pktgen/pktgen_sample03_burst_single_flow.sh -i $ETH0 -s 64 -m 00:04:9f:05:de:0a -d 192.168.101.1 -t 2 -f 13 -c 0 -p 400 -n 0 -b 4

I compiled the commands from some notes I had lying around, I didn't
retest them.


From zajec5 at gmail.com  Tue Dec 19 04:33:41 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 19 Dec 2023 13:33:41 +0100
Subject: [PATCH v6.8 2/2] nvmem: drop nvmem_layout_get_match_data()
In-Reply-To: <040fbc414bf7404046b12dfed7a1c647@walle.cc>
References: <20231219120104.3422-1-zajec5@gmail.com>
 <20231219120104.3422-2-zajec5@gmail.com>
 <040fbc414bf7404046b12dfed7a1c647@walle.cc>
Message-ID: <09f433c0-72cd-4ebe-b405-4c9acc26e8fd@gmail.com>

On 19.12.2023 13:21, Michael Walle wrote:
>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>
>> Thanks for layouts refactoring we now have "struct device" associated
>> with layout. Also its OF pointer points directly to the "nvmem-layout"
>> DT node.
>>
>> All it takes to get match data is a generic of_device_get_match_data().
> 
> Isn't device_get_match_data() preferred?

You're right. I think a big crusade against of_device_get_match_data()
is still ahead of us but I'll make sure to use device_get_match_data()
in U-Boot env layout to shine as an example :)


>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> Reviewed-by: Michael Walle <michael at walle.cc>

Thank you for quick reviews!


From alexander.stein at ew.tq-group.com  Tue Dec 19 04:34:38 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Tue, 19 Dec 2023 13:34:38 +0100
Subject: [PATCH 1/2] arm64: dts: freescale: imx8-ss-dma: Fix edma3's location
Message-ID: <20231219123439.3359318-1-alexander.stein@ew.tq-group.com>

Sort nodes by base address. edma3 comes later in the memory map.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 .../arm64/boot/dts/freescale/imx8-ss-dma.dtsi | 46 +++++++++----------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
index b0bb77150adc..a180893ac81e 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
@@ -192,29 +192,6 @@ edma2: dma-controller at 5a1f0000 {
 				<&pd IMX_SC_R_DMA_2_CH15>;
 	};
 
-	edma3: dma-controller at 5a9f0000 {
-		compatible = "fsl,imx8qm-edma";
-		reg = <0x5a9f0000 0x90000>;
-		#dma-cells = <3>;
-		dma-channels = <8>;
-		interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 427 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>;
-		power-domains = <&pd IMX_SC_R_DMA_3_CH0>,
-				<&pd IMX_SC_R_DMA_3_CH1>,
-				<&pd IMX_SC_R_DMA_3_CH2>,
-				<&pd IMX_SC_R_DMA_3_CH3>,
-				<&pd IMX_SC_R_DMA_3_CH4>,
-				<&pd IMX_SC_R_DMA_3_CH5>,
-				<&pd IMX_SC_R_DMA_3_CH6>,
-				<&pd IMX_SC_R_DMA_3_CH7>;
-	};
-
 	spi0_lpcg: clock-controller at 5a400000 {
 		compatible = "fsl,imx8qxp-lpcg";
 		reg = <0x5a400000 0x10000>;
@@ -460,6 +437,29 @@ flexcan3: can at 5a8f0000 {
 		status = "disabled";
 	};
 
+	edma3: dma-controller at 5a9f0000 {
+		compatible = "fsl,imx8qm-edma";
+		reg = <0x5a9f0000 0x90000>;
+		#dma-cells = <3>;
+		dma-channels = <8>;
+		interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 427 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>;
+		power-domains = <&pd IMX_SC_R_DMA_3_CH0>,
+				<&pd IMX_SC_R_DMA_3_CH1>,
+				<&pd IMX_SC_R_DMA_3_CH2>,
+				<&pd IMX_SC_R_DMA_3_CH3>,
+				<&pd IMX_SC_R_DMA_3_CH4>,
+				<&pd IMX_SC_R_DMA_3_CH5>,
+				<&pd IMX_SC_R_DMA_3_CH6>,
+				<&pd IMX_SC_R_DMA_3_CH7>;
+	};
+
 	i2c0_lpcg: clock-controller at 5ac00000 {
 		compatible = "fsl,imx8qxp-lpcg";
 		reg = <0x5ac00000 0x10000>;
-- 
2.34.1



From alexander.stein at ew.tq-group.com  Tue Dec 19 04:34:39 2023
From: alexander.stein at ew.tq-group.com (Alexander Stein)
Date: Tue, 19 Dec 2023 13:34:39 +0100
Subject: [PATCH 2/2] arm64: dts: imx8: Fix lpuart DMA channel order
In-Reply-To: <20231219123439.3359318-1-alexander.stein@ew.tq-group.com>
References: <20231219123439.3359318-1-alexander.stein@ew.tq-group.com>
Message-ID: <20231219123439.3359318-2-alexander.stein@ew.tq-group.com>

Bindings say DMA channels are in order Rx, Tx. Adjust the DT nodes
accordingly.

Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
---
 arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
index a180893ac81e..0f48796e32b2 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
@@ -93,8 +93,8 @@ lpuart0: serial at 5a060000 {
 		assigned-clocks = <&clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>;
 		assigned-clock-rates = <80000000>;
 		power-domains = <&pd IMX_SC_R_UART_0>;
-		dma-names = "tx","rx";
-		dmas = <&edma2 9 0 0>, <&edma2 8 0 1>;
+		dma-names = "rx", "tx";
+		dmas = <&edma2 8 0 0>, <&edma2 9 0 1>;
 		status = "disabled";
 	};
 
@@ -107,8 +107,8 @@ lpuart1: serial at 5a070000 {
 		assigned-clocks = <&clk IMX_SC_R_UART_1 IMX_SC_PM_CLK_PER>;
 		assigned-clock-rates = <80000000>;
 		power-domains = <&pd IMX_SC_R_UART_1>;
-		dma-names = "tx","rx";
-		dmas = <&edma2 11 0 0>, <&edma2 10 0 1>;
+		dma-names = "rx", "tx";
+		dmas = <&edma2 10 0 0>, <&edma2 11 0 1>;
 		status = "disabled";
 	};
 
@@ -121,8 +121,8 @@ lpuart2: serial at 5a080000 {
 		assigned-clocks = <&clk IMX_SC_R_UART_2 IMX_SC_PM_CLK_PER>;
 		assigned-clock-rates = <80000000>;
 		power-domains = <&pd IMX_SC_R_UART_2>;
-		dma-names = "tx","rx";
-		dmas = <&edma2 13 0 0>, <&edma2 12 0 1>;
+		dma-names = "rx", "tx";
+		dmas = <&edma2 12 0 0>, <&edma2 13 0 1>;
 		status = "disabled";
 	};
 
@@ -135,8 +135,8 @@ lpuart3: serial at 5a090000 {
 		assigned-clocks = <&clk IMX_SC_R_UART_3 IMX_SC_PM_CLK_PER>;
 		assigned-clock-rates = <80000000>;
 		power-domains = <&pd IMX_SC_R_UART_3>;
-		dma-names = "tx","rx";
-		dmas = <&edma2 15 0 0>, <&edma2 14 0 1>;
+		dma-names = "rx", "tx";
+		dmas = <&edma2 14 0 0>, <&edma2 15 0 1>;
 		status = "disabled";
 	};
 
-- 
2.34.1



From quic_mnaresh at quicinc.com  Tue Dec 19 04:37:04 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Tue, 19 Dec 2023 18:07:04 +0530
Subject: [PATCH V6 0/2] Add CPU latency QoS support for ufs driver
Message-ID: <20231219123706.6463-1-quic_mnaresh@quicinc.com>

Add CPU latency QoS support for ufs driver. This improves random io
performance by 15% for ufs.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 37101.3
	Random Write(IPOS) | 41065.13

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Read(IPOS)  | 42943.4
	Random Write(IPOS) | 46784.9
(Improvement with PM QoS = ~15%).

This patch is based on below patch by Stanley Chu [1]. 
Moving the PM QoS code to ufshcd.c and making it generic.

[1] https://lore.kernel.org/r/20220623035052.18802-8-stanley.chu at mediatek.com

Changes from v5:
- Addressed bvanassche comment to use kstrtobool instead kstrtou32
- Addressed bvanassche comment to add sys attribute into an existing group

Changes from v4:
- Addressed angelogioacchino's comment to update commit text
- Addressed angelogioacchino's comment to code alignment

Changes from v3:
- Removed UFSHCD_CAP_PM_QOS capability flag from patch#2

Changes from v2:
- Addressed bvanassche and mani comments
- Provided sysfs interface to enable/disable PM QoS feature

Changes from v1:
- Addressed bvanassche comments to have the code in core ufshcd
- Design is changed from per-device PM QoS to CPU latency QoS based support
- Reverted existing PM QoS feature from MEDIATEK UFS driver
- Added PM QoS capability for both QCOM and MEDIATEK SoCs

Maramaina Naresh (2):
  ufs: core: Add CPU latency QoS support for ufs driver
  ufs: ufs-mediatek: Migrate to UFSHCD generic CPU latency PM QoS
    support

 drivers/ufs/core/ufs-sysfs.c    | 49 ++++++++++++++++++++++++++++++++
 drivers/ufs/core/ufshcd.c       | 50 +++++++++++++++++++++++++++++++++
 drivers/ufs/host/ufs-mediatek.c | 17 -----------
 drivers/ufs/host/ufs-mediatek.h |  3 --
 include/ufs/ufshcd.h            |  6 ++++
 5 files changed, 105 insertions(+), 20 deletions(-)

-- 
2.17.1



From quic_mnaresh at quicinc.com  Tue Dec 19 04:37:05 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Tue, 19 Dec 2023 18:07:05 +0530
Subject: [PATCH V6 1/2] ufs: core: Add CPU latency QoS support for ufs driver
In-Reply-To: <20231219123706.6463-1-quic_mnaresh@quicinc.com>
References: <20231219123706.6463-1-quic_mnaresh@quicinc.com>
Message-ID: <20231219123706.6463-2-quic_mnaresh@quicinc.com>

Register ufs driver to CPU latency PM QoS framework to improve
ufs device random io performance.

PM QoS initialization will insert new QoS request into the CPU
latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
value.

UFS driver will vote for performance mode on scale up and power
save mode for scale down.

If clock scaling feature is not enabled then voting will be based
on clock on or off condition.

Provided sysfs interface to enable/disable PM QoS feature.

tiotest benchmark tool io performance results on sm8550 platform:

1. Without PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 41065.13
	Random Read(IPOS)  | 37101.3

2. With PM QoS support
	Type (Speed in)    | Average of 18 iterations
	Random Write(IPOS) | 46784.9
	Random Read(IPOS)  | 42943.4
(Improvement with PM QoS = ~15%).

Reviewed-by: Peter Wang <peter.wang at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Co-developed-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall at quicinc.com>
Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/core/ufs-sysfs.c | 49 +++++++++++++++++++++++++++++++++++
 drivers/ufs/core/ufshcd.c    | 50 ++++++++++++++++++++++++++++++++++++
 include/ufs/ufshcd.h         |  6 +++++
 3 files changed, 105 insertions(+)

diff --git a/drivers/ufs/core/ufs-sysfs.c b/drivers/ufs/core/ufs-sysfs.c
index e6d12289e017..3d049967f6bc 100644
--- a/drivers/ufs/core/ufs-sysfs.c
+++ b/drivers/ufs/core/ufs-sysfs.c
@@ -405,6 +405,53 @@ static ssize_t wb_flush_threshold_store(struct device *dev,
 	return count;
 }
 
+/**
+ * pm_qos_enable_show - sysfs handler to show pm qos enable value
+ * @dev: device associated with the UFS controller
+ * @attr: sysfs attribute handle
+ * @buf: buffer for sysfs file
+ *
+ * Print 1 if PM QoS feature is enabled, 0 if disabled.
+ *
+ * Returns number of characters written to @buf.
+ */
+static ssize_t pm_qos_enable_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	return sysfs_emit(buf, "%d\n", hba->pm_qos_enabled);
+}
+
+/**
+ * pm_qos_enable_store - sysfs handler to store value
+ * @dev: device associated with the UFS controller
+ * @attr: sysfs attribute handle
+ * @buf: buffer for sysfs file
+ * @count: stores buffer characters count
+ *
+ * Input 0 to disable PM QoS and 1 value to enable.
+ * Default state: 1
+ *
+ * Return: number of characters written to @buf on success, < 0 upon failure.
+ */
+static ssize_t pm_qos_enable_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+	bool value;
+
+	if (kstrtobool(buf, &value))
+		return -EINVAL;
+
+	if (value)
+		ufshcd_pm_qos_init(hba);
+	else
+		ufshcd_pm_qos_exit(hba);
+
+	return count;
+}
+
 static DEVICE_ATTR_RW(rpm_lvl);
 static DEVICE_ATTR_RO(rpm_target_dev_state);
 static DEVICE_ATTR_RO(rpm_target_link_state);
@@ -416,6 +463,7 @@ static DEVICE_ATTR_RW(wb_on);
 static DEVICE_ATTR_RW(enable_wb_buf_flush);
 static DEVICE_ATTR_RW(wb_flush_threshold);
 static DEVICE_ATTR_RW(rtc_update_ms);
+static DEVICE_ATTR_RW(pm_qos_enable);
 
 static struct attribute *ufs_sysfs_ufshcd_attrs[] = {
 	&dev_attr_rpm_lvl.attr,
@@ -429,6 +477,7 @@ static struct attribute *ufs_sysfs_ufshcd_attrs[] = {
 	&dev_attr_enable_wb_buf_flush.attr,
 	&dev_attr_wb_flush_threshold.attr,
 	&dev_attr_rtc_update_ms.attr,
+	&dev_attr_pm_qos_enable.attr,
 	NULL
 };
 
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 7fb1758384e2..188f4324f49c 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1014,6 +1014,48 @@ static bool ufshcd_is_unipro_pa_params_tuning_req(struct ufs_hba *hba)
 	return ufshcd_get_local_unipro_ver(hba) < UFS_UNIPRO_VER_1_6;
 }
 
+/**
+ * ufshcd_pm_qos_init - initialize PM QoS request
+ * @hba: per adapter instance
+ */
+void ufshcd_pm_qos_init(struct ufs_hba *hba)
+{
+
+	if (hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_add_request(&hba->pm_qos_req, PM_QOS_DEFAULT_VALUE);
+
+	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
+		hba->pm_qos_enabled = true;
+}
+
+/**
+ * ufshcd_pm_qos_exit - remove request from PM QoS
+ * @hba: per adapter instance
+ */
+void ufshcd_pm_qos_exit(struct ufs_hba *hba)
+{
+	if (!hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_remove_request(&hba->pm_qos_req);
+	hba->pm_qos_enabled = false;
+}
+
+/**
+ * ufshcd_pm_qos_update - update PM QoS request
+ * @hba: per adapter instance
+ * @on: If True, vote for perf PM QoS mode otherwise power save mode
+ */
+static void ufshcd_pm_qos_update(struct ufs_hba *hba, bool on)
+{
+	if (!hba->pm_qos_enabled)
+		return;
+
+	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? 0 : PM_QOS_DEFAULT_VALUE);
+}
+
 /**
  * ufshcd_set_clk_freq - set UFS controller clock frequencies
  * @hba: per adapter instance
@@ -1160,8 +1202,11 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, unsigned long freq,
 					    hba->devfreq->previous_freq);
 		else
 			ufshcd_set_clk_freq(hba, !scale_up);
+		goto out;
 	}
 
+	ufshcd_pm_qos_update(hba, scale_up);
+
 out:
 	trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
 			(scale_up ? "up" : "down"),
@@ -9291,6 +9336,8 @@ static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
 	if (ret)
 		return ret;
 
+	if (!ufshcd_is_clkscaling_supported(hba))
+		ufshcd_pm_qos_update(hba, on);
 out:
 	if (ret) {
 		list_for_each_entry(clki, head, list) {
@@ -9468,6 +9515,7 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
 static void ufshcd_hba_exit(struct ufs_hba *hba)
 {
 	if (hba->is_powered) {
+		ufshcd_pm_qos_exit(hba);
 		ufshcd_exit_clk_scaling(hba);
 		ufshcd_exit_clk_gating(hba);
 		if (hba->eh_wq)
@@ -10121,6 +10169,7 @@ static int ufshcd_suspend(struct ufs_hba *hba)
 	ufshcd_vreg_set_lpm(hba);
 	/* Put the host controller in low power mode if possible */
 	ufshcd_hba_vreg_set_lpm(hba);
+	ufshcd_pm_qos_update(hba, false);
 	return ret;
 }
 
@@ -10667,6 +10716,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 	ufs_sysfs_add_nodes(hba->dev);
 
 	device_enable_async_suspend(dev);
+	ufshcd_pm_qos_init(hba);
 	return 0;
 
 free_tmf_queue:
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 38637bea9a52..2f5e88b3e643 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -914,6 +914,8 @@ enum ufshcd_mcq_opr {
  * @dev_cmd_queue: Queue for issuing device management commands
  * @mcq_opr: MCQ operation and runtime registers
  * @ufs_rtc_update_work: A work for UFS RTC periodic update
+ * @pm_qos_req: PM QoS request handle
+ * @pm_qos_enabled: flag to check if pm qos is enabled
  */
 struct ufs_hba {
 	void __iomem *mmio_base;
@@ -1080,6 +1082,8 @@ struct ufs_hba {
 	struct ufshcd_mcq_opr_info_t mcq_opr[OPR_MAX];
 
 	struct delayed_work ufs_rtc_update_work;
+	struct pm_qos_request pm_qos_req;
+	bool pm_qos_enabled;
 };
 
 /**
@@ -1401,6 +1405,8 @@ int ufshcd_suspend_prepare(struct device *dev);
 int __ufshcd_suspend_prepare(struct device *dev, bool rpm_ok_for_spm);
 void ufshcd_resume_complete(struct device *dev);
 bool ufshcd_is_hba_active(struct ufs_hba *hba);
+void ufshcd_pm_qos_init(struct ufs_hba *hba);
+void ufshcd_pm_qos_exit(struct ufs_hba *hba);
 
 /* Wrapper functions for safely calling variant operations */
 static inline int ufshcd_vops_init(struct ufs_hba *hba)
-- 
2.17.1



From quic_mnaresh at quicinc.com  Tue Dec 19 04:37:06 2023
From: quic_mnaresh at quicinc.com (Maramaina Naresh)
Date: Tue, 19 Dec 2023 18:07:06 +0530
Subject: [PATCH V6 2/2] ufs: ufs-mediatek: Migrate to UFSHCD generic CPU latency PM QoS support
In-Reply-To: <20231219123706.6463-1-quic_mnaresh@quicinc.com>
References: <20231219123706.6463-1-quic_mnaresh@quicinc.com>
Message-ID: <20231219123706.6463-3-quic_mnaresh@quicinc.com>

The PM QoS feature found in the MediaTek UFS driver was moved to the UFSHCD
core. Hence remove it from MediaTek UFS driver as it is redundant now.

Reviewed-by: Peter Wang <peter.wang at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Maramaina Naresh <quic_mnaresh at quicinc.com>
---
 drivers/ufs/host/ufs-mediatek.c | 17 -----------------
 drivers/ufs/host/ufs-mediatek.h |  3 ---
 2 files changed, 20 deletions(-)

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index 776bca4f70c8..f43eb945e011 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -17,7 +17,6 @@
 #include <linux/of_platform.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
-#include <linux/pm_qos.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
@@ -626,21 +625,9 @@ static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
 	dev_info(hba->dev, "caps: 0x%x", host->caps);
 }
 
-static void ufs_mtk_boost_pm_qos(struct ufs_hba *hba, bool boost)
-{
-	struct ufs_mtk_host *host = ufshcd_get_variant(hba);
-
-	if (!host || !host->pm_qos_init)
-		return;
-
-	cpu_latency_qos_update_request(&host->pm_qos_req,
-				       boost ? 0 : PM_QOS_DEFAULT_VALUE);
-}
-
 static void ufs_mtk_scale_perf(struct ufs_hba *hba, bool scale_up)
 {
 	ufs_mtk_boost_crypt(hba, scale_up);
-	ufs_mtk_boost_pm_qos(hba, scale_up);
 }
 
 static void ufs_mtk_pwr_ctrl(struct ufs_hba *hba, bool on)
@@ -959,10 +946,6 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
 	host->ip_ver = ufshcd_readl(hba, REG_UFS_MTK_IP_VER);
 
-	/* Initialize pm-qos request */
-	cpu_latency_qos_add_request(&host->pm_qos_req, PM_QOS_DEFAULT_VALUE);
-	host->pm_qos_init = true;
-
 	goto out;
 
 out_variant_clear:
diff --git a/drivers/ufs/host/ufs-mediatek.h b/drivers/ufs/host/ufs-mediatek.h
index f76e80d91729..38eab95b0f79 100644
--- a/drivers/ufs/host/ufs-mediatek.h
+++ b/drivers/ufs/host/ufs-mediatek.h
@@ -7,7 +7,6 @@
 #define _UFS_MEDIATEK_H
 
 #include <linux/bitops.h>
-#include <linux/pm_qos.h>
 #include <linux/soc/mediatek/mtk_sip_svc.h>
 
 /*
@@ -167,7 +166,6 @@ struct ufs_mtk_mcq_intr_info {
 
 struct ufs_mtk_host {
 	struct phy *mphy;
-	struct pm_qos_request pm_qos_req;
 	struct regulator *reg_va09;
 	struct reset_control *hci_reset;
 	struct reset_control *unipro_reset;
@@ -178,7 +176,6 @@ struct ufs_mtk_host {
 	struct ufs_mtk_hw_ver hw_ver;
 	enum ufs_mtk_host_caps caps;
 	bool mphy_powered_on;
-	bool pm_qos_init;
 	bool unipro_lpm;
 	bool ref_clk_enabled;
 	u16 ref_clk_ungating_wait_us;
-- 
2.17.1



From cristian.ciocaltea at collabora.com  Tue Dec 19 04:49:08 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Tue, 19 Dec 2023 14:49:08 +0200
Subject: [PATCH v4 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <c9225053-78f8-40b7-9453-dc3dabe44500@linaro.org>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <20231218214451.2345691-3-cristian.ciocaltea@collabora.com>
 <c9225053-78f8-40b7-9453-dc3dabe44500@linaro.org>
Message-ID: <d030f5b7-8d32-4a80-a3c0-98cfa1c0fe4f@collabora.com>

On 12/19/23 09:27, Krzysztof Kozlowski wrote:
> On 18/12/2023 22:44, Cristian Ciocaltea wrote:
>> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
>> similar to the newer JH7110, but it requires only two interrupts and a
>> single reset line, which is 'ahb' instead of the commonly used
>> 'stmmaceth'.
>>
> 
>>    reg:
>> @@ -145,9 +146,13 @@ properties:
>>  
>>    reset-names:
>>      minItems: 1
>> -    items:
>> -      - const: stmmaceth
>> -      - const: ahb
>> +    maxItems: 2
> 
> min and maxItems should not be needed here.

Indeed, I will drop them.

>> +    oneOf:
>> +      - items:
>> +          - enum: [stmmaceth, ahb]
>> +      - items:
>> +          - const: stmmaceth
>> +          - const: ahb
>>  
>>    power-domains:
>>      maxItems: 1
>> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>> index d90cb82c1424..f5f0bff5be0f 100644
>> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>> @@ -16,16 +16,20 @@ select:
>>      compatible:
>>        contains:
>>          enum:
>> +          - starfive,jh7100-dwmac
>>            - starfive,jh7110-dwmac
>>    required:
>>      - compatible
>>  
>>  properties:
>>    compatible:
>> -    items:
>> -      - enum:
>> -          - starfive,jh7110-dwmac
>> -      - const: snps,dwmac-5.20
>> +    oneOf:
>> +      - items:
>> +          - const: starfive,jh7100-dwmac
>> +          - const: snps,dwmac
>> +      - items:
>> +          - const: starfive,jh7110-dwmac
>> +          - const: snps,dwmac-5.20
>>  
>>    reg:
>>      maxItems: 1
>> @@ -46,23 +50,6 @@ properties:
>>        - const: tx
>>        - const: gtx
>>  
>> -  interrupts:
>> -    minItems: 3
>> -    maxItems: 3
>> -
>> -  interrupt-names:
>> -    minItems: 3
>> -    maxItems: 3
>> -
>> -  resets:
>> -    minItems: 2
>> -    maxItems: 2
> 
> What is the point of your previous patch if you immediately remove it?
> It is a no-op. Just mention in this commit msg, that both resets and
> reset-names are coming from snps,dwmac so they can be removed from
> top-level entirely.

This has been discussed during v2 review [1], where I also provided the
rational behind not updating reset-names. So the code was not deleted,
but moved under an if clause.

Thanks for reviewing,
Cristian

[1]: https://lore.kernel.org/lkml/f4d0b216-5bdc-4559-aabb-8af638d33721 at collabora.com/


From mripard at kernel.org  Tue Dec 19 04:53:18 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Tue, 19 Dec 2023 12:53:18 +0000
Subject: [PATCH v2 1/2] drm/rockchip: rk3066_hdmi: remove unused drm
 device pointer
In-Reply-To: <745f84db-dc9b-81b2-6171-4d8d86a96966@gmail.com>
References: <745f84db-dc9b-81b2-6171-4d8d86a96966@gmail.com>
Message-ID: <473e996c20451aa5bb700d30fdf0f16b@kernel.org>

On Mon, 18 Dec 2023 16:48:40 +0100, Johan Jonker wrote:
> The drm_dev field in the rk3066_hdmi struct stores a pointer to the DRM
> device but is never used anywhere in the driver. Let's remove it.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>

Reviewed-by: Maxime Ripard <mripard at kernel.org>

Thanks!
Maxime


From cristian.ciocaltea at collabora.com  Tue Dec 19 04:55:03 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Tue, 19 Dec 2023 14:55:03 +0200
Subject: [PATCH v4 1/9] dt-bindings: net: starfive,jh7110-dwmac: Drop
 redundant reset description
In-Reply-To: <92eb5f85-1241-429c-aca9-7a6a17f19ae5@linaro.org>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <20231218214451.2345691-2-cristian.ciocaltea@collabora.com>
 <92eb5f85-1241-429c-aca9-7a6a17f19ae5@linaro.org>
Message-ID: <5b6d78a6-4515-41c2-b94d-5c7df12dbb2d@collabora.com>

On 12/19/23 09:24, Krzysztof Kozlowski wrote:
> On 18/12/2023 22:44, Cristian Ciocaltea wrote:
>> The reset description items are already provided by the referenced
>> snps,dwmac.yaml schema, hence replace them with the necessary
>> {min,max}Items.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>> ---
>>  .../devicetree/bindings/net/starfive,jh7110-dwmac.yaml       | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>> index 5e7cfbbebce6..d90cb82c1424 100644
>> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>> @@ -55,9 +55,8 @@ properties:
>>      maxItems: 3
>>  
>>    resets:
>> -    items:
>> -      - description: MAC Reset signal.
>> -      - description: AHB Reset signal.
>> +    minItems: 2
>> +    maxItems: 2
> 
> Why changing only resets, but not reset-names?

Already answered in [1], but also discussed in the context of the 
next patch.

Thanks,
Cristian

[1]: https://lore.kernel.org/lkml/0ff7a905-d8f2-401b-a0ff-47947d12ce05 at collabora.com/


From mripard at kernel.org  Tue Dec 19 04:55:14 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Tue, 19 Dec 2023 13:55:14 +0100
Subject: [PATCH v2 2/2] drm/rockchip: rk3066_hdmi: drop custom fill_modes
 hook
In-Reply-To: <410b116b-cb63-7ba7-3689-4f0832ab5796@gmail.com>
References: <f86ec29f-194a-800d-0aaf-9e16e551b37d@gmail.com>
 <410b116b-cb63-7ba7-3689-4f0832ab5796@gmail.com>
Message-ID: <evaq3yfbqf4gchsps2qoojemtii7tmcss24aruiuze5kkzlnhy@mih7rky7viqz>

Hi,

On Mon, Dec 18, 2023 at 04:49:06PM +0100, Johan Jonker wrote:
> CRTC size validation for the display controller has been added with
> Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
> hardware capabilities"), so we can drop the custom fill_modes hook.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>

I'm not sure those two are equivalent. CRTC and connectors usually have
different requirements and capabilities, and thus different,
supplementary, mode_valid/atomic_check implementations.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/74b99a99/attachment.sig>

From miquel.raynal at bootlin.com  Tue Dec 19 04:55:53 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Tue, 19 Dec 2023 13:55:53 +0100
Subject: [PATCH v6.8 1/2] nvmem: layouts: refactor .add_cells() callback
 arguments
In-Reply-To: <20231219120104.3422-1-zajec5@gmail.com>
References: <20231219120104.3422-1-zajec5@gmail.com>
Message-ID: <20231219135553.4e1b74f4@xps-13>

Hi Rafa?,

zajec5 at gmail.com wrote on Tue, 19 Dec 2023 13:01:03 +0100:

> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> Simply pass whole "struct nvmem_layout" instead of single variables.
> There is nothing in "struct nvmem_layout" that we have to hide from
> layout drivers. They also access it during .probe() and .remove().
> 
> Thanks to this change:
> 
> 1. API gets more consistent
>    All layouts drivers callbacks get the same argument
> 
> 2. Layouts get correct device
>    Before this change NVMEM core code was passing NVMEM device instead
>    of layout device. That resulted in:
>    * Confusing prints
>    * Calling devm_*() helpers on wrong device
>    * Helpers like of_device_get_match_data() dereferencing NULLs
> 
> 3. It gets possible to get match data
>    First of all nvmem_layout_get_match_data() requires passing "struct
>    nvmem_layout" which .add_cells() callback didn't have before this. It
>    doesn't matter much as it's rather useless now anyway (and will be
>    dropped).
>    What's more important however is that of_device_get_match_data() can
>    be used now thanks to owning a proper device pointer.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>

Thanks,
Miqu?l


From miquel.raynal at bootlin.com  Tue Dec 19 04:56:14 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Tue, 19 Dec 2023 13:56:14 +0100
Subject: [PATCH v6.8 2/2] nvmem: drop nvmem_layout_get_match_data()
In-Reply-To: <20231219120104.3422-2-zajec5@gmail.com>
References: <20231219120104.3422-1-zajec5@gmail.com>
	<20231219120104.3422-2-zajec5@gmail.com>
Message-ID: <20231219135614.57fd14f3@xps-13>

Hi Rafa?,

zajec5 at gmail.com wrote on Tue, 19 Dec 2023 13:01:04 +0100:

> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> Thanks for layouts refactoring we now have "struct device" associated
> with layout. Also its OF pointer points directly to the "nvmem-layout"
> DT node.
> 
> All it takes to get match data is a generic of_device_get_match_data().
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>

Thanks,
Miqu?l


From quic_bibekkum at quicinc.com  Tue Dec 19 05:06:31 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 18:36:31 +0530
Subject: [PATCH v4 5/5] iommu/arm-smmu: re-enable context caching in smmu
 reset operation
In-Reply-To: <3c7b8c2c-7174-4ced-8954-5a249f792c1e@linaro.org>
References: <20231215101827.30549-1-quic_bibekkum@quicinc.com>
 <20231215101827.30549-6-quic_bibekkum@quicinc.com>
 <3c7b8c2c-7174-4ced-8954-5a249f792c1e@linaro.org>
Message-ID: <d5291beb-7384-4ee9-a7a4-8aad931d7bc8@quicinc.com>



On 12/16/2023 5:24 AM, Konrad Dybcio wrote:
[...]
>> +
>> +	arm_mmu500_reset(smmu);
> We should check the return value here, in case the function is modified
> some day in a way that makes it return something else than 0
> 

Thanks for pointing this actually. I crosschecked on the
arm_mmu500_reset function behavior, looks like there's no return value
other than 0 and so the functionality won't change. I think we can
keep it as it is in this case.

Thanks,
Bibek

> LGTM otherwise!
> 
> Konrad


From maxime.chevallier at bootlin.com  Tue Dec 19 05:07:54 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Tue, 19 Dec 2023 14:07:54 +0100
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
In-Reply-To: <20231219122034.pg2djgrosa4irubh@skbuf>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
	<20231218162326.173127-2-romain.gantois@bootlin.com>
	<20231219122034.pg2djgrosa4irubh@skbuf>
Message-ID: <20231219140754.7a7a8dbd@device-28.home>

Hi Vlad,

+ Linus Walleij

On Tue, 19 Dec 2023 14:20:34 +0200
Vladimir Oltean <olteanv at gmail.com> wrote:

> Hi Romain,
> 
> On Mon, Dec 18, 2023 at 05:23:23PM +0100, Romain Gantois wrote:
> > Some stmmac cores have Checksum Offload Engines that cannot handle DSA tags
> > properly. These cores find the IP/TCP headers on their own and end up
> > computing an incorrect checksum when a DSA tag is inserted between the MAC
> > header and IP header.
> > 
> > Add an additional check on stmmac link up so that COE is deactivated
> > when the stmmac device is used as a DSA conduit.
> > 
> > Add a new dma_feature flag to allow cores to signal that their COEs can't
> > handle DSA tags on TX.
> > 
> > Fixes: 6b2c6e4a938f ("net: stmmac: propagate feature flags to vlan")
> > Cc: stable at vger.kernel.org
> > Reported-by: Richard Tresidder <rtresidd at electromag.com.au>
> > Closes: https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2 at electromag.com.au/
> > Reported-by: Romain Gantois <romain.gantois at bootlin.com>
> > Closes: https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495 at bootlin.com/
> > Signed-off-by: Romain Gantois <romain.gantois at bootlin.com>
> > ---  
> 
> DSA_TAG_PROTO_LAN9303, DSA_TAG_PROTO_SJA1105 and DSA_TAG_PROTO_SJA1110
> construct tags with ETH_P_8021Q as EtherType. Do you still think it
> would be correct to say that all DSA tags break COE on the stmmac, as
> this patch assumes?
> 
> The NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM convention is not about
> statically checking whether the interface using DSA, but about looking
> at each packet before deciding whether to use the offload engine or to
> call skb_checksum_help().

So it looks like an acceptable solution would be something along the
lines of what Linus is suggesting here :

https://lore.kernel.org/netdev/20231216-new-gemini-ethernet-regression-v2-2-64c269413dfa at linaro.org/

If so, maybe it's worth adding a new helper for that check ?

Maxime


From laurent.pinchart at ideasonboard.com  Tue Dec 19 05:08:49 2023
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 19 Dec 2023 15:08:49 +0200
Subject: [PATCH 2/2] media: rkisp1: Fix IRQ handling due to shared
 interrupts
In-Reply-To: <b465355b-65c2-451f-ae2e-63da9d0a6282@ideasonboard.com>
References: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>
 <20231218-rkisp-shirq-fix-v1-2-173007628248@ideasonboard.com>
 <20231218092240.GB26540@pendragon.ideasonboard.com>
 <b465355b-65c2-451f-ae2e-63da9d0a6282@ideasonboard.com>
Message-ID: <20231219130849.GA29638@pendragon.ideasonboard.com>

Hi Tomi,

CC'ing Sakari

On Tue, Dec 19, 2023 at 10:50:05AM +0200, Tomi Valkeinen wrote:
> On 18/12/2023 11:22, Laurent Pinchart wrote:
> > On Mon, Dec 18, 2023 at 09:54:01AM +0200, Tomi Valkeinen wrote:
> >> The driver requests the interrupts as IRQF_SHARED, so the interrupt
> >> handlers can be called at any time. If such a call happens while the ISP
> >> is powered down, the SoC will hang as the driver tries to access the
> >> ISP registers.
> >>
> >> This can be reproduced even without the platform sharing the IRQ line:
> >> Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will
> >> hang.
> >>
> >> Fix this by adding a new field, 'irqs_enabled', which is used to bail
> >> out from the interrupt handler when the ISP is not operational.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> >> ---
> >>   .../platform/rockchip/rkisp1/rkisp1-capture.c      |  3 +++
> >>   .../media/platform/rockchip/rkisp1/rkisp1-common.h |  2 ++
> >>   .../media/platform/rockchip/rkisp1/rkisp1-csi.c    |  3 +++
> >>   .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 22 ++++++++++++++++++++++
> >>   .../media/platform/rockchip/rkisp1/rkisp1-isp.c    |  3 +++
> >>   5 files changed, 33 insertions(+)
> >>
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> >> index aebd3c12020b..c381c22135a2 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> >> @@ -725,6 +725,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
> >>   	unsigned int i;
> >>   	u32 status;
> >>   
> >> +	if (!rkisp1->irqs_enabled)
> >> +		return IRQ_NONE;
> > 
> > Given that this is something all drivers that use shared IRQs have to
> > do, would it make sense to use a standard helper here, such as
> > pm_runtime_suspended() for instance ? I haven't looked at which one
> > would be the most appropriate (if any), there's also
> > pm_runtime_active() and pm_runtime_status_suspended(). That would
> > simplify this patch.
> 
> I did consider that when writing the patch. But I just wasn't very 
> comfortable using the runtime PM here, even if it would make sense, as 
> I'm just not quite sure how it works.
> 
> For example, pm_runtime_suspended() checks if the device is in 
> RPM_SUSPENDED state, and the device will be in RPM_SUSPENDED after the 
> driver's suspend callback has finished. This makes sense.
> 
> However, _while_ suspending (not after we have suspended), we want to 
> make sure that 1) no new irq handling will start, 2) we'll wait until 
> any currently running irq handler has finished. For 1), we can't use 
> pm_runtime_suspended() in the irq handler, as the status is not 
> RPM_SUSPENDED. We could probably check for:
> 
> spin_lock(&dev->power.lock);
> off = dev->power.runtime_status == RPM_SUSPENDED || 
> dev->power.runtime_status == RPM_SUSPENDING;
> spin_unlock(&dev->power.lock);
> if (off)
> 	return IRQ_NONE;
> 
> That would not work if we would depend on the irq handling while in the 
> suspend callback (e.g. waiting for an irq which signals that the device 
> has finished processing). But we don't do that at the moment, and that 
> kind of this probably can usually be done before calling runtime_put().
> 
> When we take into account the resume part, I think we could just check 
> for RPM_ACTIVE in the irq handler, which would then rule out 
> RPM_RESUMING, RPM_SUSPENDED and RPM_SUSPENDING.
> 
> But we can't use pm_runtime_active(), as that also checks for 
> dev->power.disable_depth. In other words, when we disable the PM for our 
> device (e.g. when unloading the driver), the PM framework says our 
> device became active.
> 
> Soo... I think this should work in the irq handler:
> 
> spin_lock(&dev->power.lock);
> active = dev->power.runtime_status == RPM_ACTIVE;

It would be nice to use pm_runtime_active() instead. This would however
require unregistering the IRQ handler before disabling runtime PM in the
remove path. I think that should be done nonetheless though, as relying
on devm to unregister the IRQ handler means it will happen after
.remove() returns, which could cause all sort of issues (I'm thinking
about the calls to dev_get_drvdata() in the IRQ handlers for instance).
What do you think ?

> spin_unlock(&dev->power.lock);
> if (!active)
> 	return IRQ_NONE;
> 
> I think the driver depends on runtime PM, but if no-PM was an option, I 
> guess we'd need to ifdef the above away, and trust that the device is 
> always powered on.
> 
> So, as I said in the beginning, "I just wasn't very comfortable using 
> the runtime PM here". And that's still the case =). The runtime PM is 
> horribly complex. If you think the above is clearer, and you think it's 
> correct, I can make the change.

It sounds it may require some more work, and we should land this fix in
v6.8, with the revert, right ? If so, I'm fine merging this patch, and
moving to runtime PM checks on top if we decide to do so.

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

By the way, I wonder if it would make sense to handle this in the driver
core. The prospect of copying this code in all drivers doesn't make me
happy.

> >> +
> >>   	status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
> >>   	if (!status)
> >>   		return IRQ_NONE;
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> >> index 4b6b28c05b89..b757f75edecf 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
> >> @@ -450,6 +450,7 @@ struct rkisp1_debug {
> >>    * @debug:	   debug params to be exposed on debugfs
> >>    * @info:	   version-specific ISP information
> >>    * @irqs:          IRQ line numbers
> >> + * @irqs_enabled:  the hardware is enabled and can cause interrupts
> >>    */
> >>   struct rkisp1_device {
> >>   	void __iomem *base_addr;
> >> @@ -471,6 +472,7 @@ struct rkisp1_device {
> >>   	struct rkisp1_debug debug;
> >>   	const struct rkisp1_info *info;
> >>   	int irqs[RKISP1_NUM_IRQS];
> >> +	bool irqs_enabled;
> >>   };
> >>   
> >>   /*
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> >> index b6e47e2f1b94..4202642e0523 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
> >> @@ -196,6 +196,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
> >>   	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
> >>   	u32 val, status;
> >>   
> >> +	if (!rkisp1->irqs_enabled)
> >> +		return IRQ_NONE;
> >> +
> >>   	status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
> >>   	if (!status)
> >>   		return IRQ_NONE;
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> index acc559652d6e..73cf08a74011 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> @@ -305,6 +305,24 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
> >>   {
> >>   	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
> >>   
> >> +	rkisp1->irqs_enabled = false;
> >> +	/* Make sure the IRQ handler will see the above */
> >> +	mb();
> >> +
> >> +	/*
> >> +	 * Wait until any running IRQ handler has returned. The IRQ handler
> >> +	 * may get called even after this (as it's a shared interrupt line)
> >> +	 * but the 'irqs_enabled' flag will make the handler return immediately.
> >> +	 */
> >> +	for (unsigned int il = 0; il < ARRAY_SIZE(rkisp1->irqs); ++il) {
> >> +		if (rkisp1->irqs[il] == -1)
> >> +			continue;
> >> +
> >> +		/* Skip if the irq line is the same as previous */
> >> +		if (il == 0 || rkisp1->irqs[il - 1] != rkisp1->irqs[il])
> >> +			synchronize_irq(rkisp1->irqs[il]);
> >> +	}
> >> +
> >>   	clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
> >>   	return pinctrl_pm_select_sleep_state(dev);
> >>   }
> >> @@ -321,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
> >>   	if (ret)
> >>   		return ret;
> >>   
> >> +	rkisp1->irqs_enabled = true;
> >> +	/* Make sure the IRQ handler will see the above */
> >> +	mb();
> >> +
> >>   	return 0;
> >>   }
> >>   
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> >> index f00873d31c42..78a1f7a1499b 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
> >> @@ -976,6 +976,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
> >>   	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
> >>   	u32 status, isp_err;
> >>   
> >> +	if (!rkisp1->irqs_enabled)
> >> +		return IRQ_NONE;
> >> +
> >>   	status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
> >>   	if (!status)
> >>   		return IRQ_NONE;

-- 
Regards,

Laurent Pinchart


From gabriel.fernandez at foss.st.com  Tue Dec 19 05:09:07 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Tue, 19 Dec 2023 14:09:07 +0100
Subject: [PATCH v7 0/2] Introduce STM32MP257 clock driver
Message-ID: <20231219130909.265091-1-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

v7: base on next-20231219
  - These patches below are applied to clk-next:
      clk: stm32mp1: move stm32mp1 clock driver into stm32 directory
      clk: stm32mp1: use stm32mp13 reset driver
      dt-bindings: stm32: add clocks and reset binding for stm32mp25
  - remove unnecessary includes
  - migrate clock parents to struct clk_parent_data and remove
    CLK_STM32_XXX() macros  to have a more readble code
  - use platform device APIs (devm_of_iomap() instead of_iomap())
  - move content of stm32mp25_rcc_init() to stm32mp25_rcc_clocks_probe()
  - simply get_clock_deps()
  - add const to stm32mp25_data struct
  - remove ck_icn_p_serc clock (will be integrate later with security
    management)

v6:
  - remove useless defines in drivers/clk/stm32/stm32mp25_rcc.h

v5:
  - Fix sparse warnings: was not declared. Should it be static?
    drivers/clk/stm32/clk-stm32mp13.c:1516:29: symbol 'stm32mp13_reset_data'
    drivers/clk/stm32/clk-stm32mp1.c:2148:29: symbol 'stm32mp1_reset_data'
    drivers/clk/stm32/clk-stm32mp25.c:1003:5: symbol 'stm32mp25_cpt_gate'
    drivers/clk/stm32/clk-stm32mp25.c:1005:29: symbol 'stm32mp25_clock_data'
    drivers/clk/stm32/clk-stm32mp25.c:1011:29: symbol 'stm32mp25_reset_data'

v4:
  - use GPL-2.0-only OR BSD-2-Clause for clock and reset binding files
  - use quotes ' for #clock-cells and #reset-cells in YAML documentation
  - reset binding start now to 0 instead 1
  - improve management of reset lines that are not managed

v3:
  - from Rob Herring change clock item description in YAML documentation
v2:
  - rework reset binding (use ID witch start from 0)
  - rework reset driver to manage STM32MP13 / STM32MP15 / STM32MP25
  - rework YAML documentation

Gabriel Fernandez (2):
  clk: stm32: introduce clocks for STM32MP257 platform
  arm64: dts: st: add rcc support in stm32mp251

 arch/arm64/boot/dts/st/stm32mp251.dtsi |   59 +-
 drivers/clk/stm32/Kconfig              |    7 +
 drivers/clk/stm32/Makefile             |    1 +
 drivers/clk/stm32/clk-stm32mp25.c      | 1826 ++++++++++++++++++++++++
 drivers/clk/stm32/reset-stm32.c        |   59 +-
 drivers/clk/stm32/reset-stm32.h        |    7 +
 drivers/clk/stm32/stm32mp25_rcc.h      |  712 +++++++++
 7 files changed, 2628 insertions(+), 43 deletions(-)
 create mode 100644 drivers/clk/stm32/clk-stm32mp25.c
 create mode 100644 drivers/clk/stm32/stm32mp25_rcc.h

-- 
2.25.1



From gabriel.fernandez at foss.st.com  Tue Dec 19 05:09:09 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Tue, 19 Dec 2023 14:09:09 +0100
Subject: [PATCH v7 2/2] arm64: dts: st: add rcc support in stm32mp251
In-Reply-To: <20231219130909.265091-1-gabriel.fernandez@foss.st.com>
References: <20231219130909.265091-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231219130909.265091-3-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Add RCC support to manage clocks and resets on the STM32MP251.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 59 ++++++++++++++------------
 1 file changed, 31 insertions(+), 28 deletions(-)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 96859d098ef8..ce51dbcdf0bb 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -3,7 +3,9 @@
  * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
  * Author: Alexandre Torgue <alexandre.torgue at foss.st.com> for STMicroelectronics.
  */
+#include <dt-bindings/clock/st,stm32mp25-rcc.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset/st,stm32mp25-rcc.h>
 
 / {
 	#address-cells = <2>;
@@ -35,22 +37,10 @@ arm_wdt: watchdog {
 	};
 
 	clocks {
-		ck_flexgen_08: ck-flexgen-08 {
+		clk_rcbsec: clk-rcbsec {
 			#clock-cells = <0>;
 			compatible = "fixed-clock";
-			clock-frequency = <100000000>;
-		};
-
-		ck_flexgen_51: ck-flexgen-51 {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <200000000>;
-		};
-
-		ck_icn_ls_mcu: ck-icn-ls-mcu {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <200000000>;
+			clock-frequency = <64000000>;
 		};
 	};
 
@@ -122,7 +112,7 @@ usart2: serial at 400e0000 {
 				compatible = "st,stm32h7-uart";
 				reg = <0x400e0000 0x400>;
 				interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&ck_flexgen_08>;
+				clocks = <&rcc CK_KER_USART2>;
 				status = "disabled";
 			};
 
@@ -131,7 +121,7 @@ sdmmc1: mmc at 48220000 {
 				arm,primecell-periphid = <0x00353180>;
 				reg = <0x48220000 0x400>, <0x44230400 0x8>;
 				interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&ck_flexgen_51>;
+				clocks = <&rcc CK_KER_SDMMC1 >;
 				clock-names = "apb_pclk";
 				cap-sd-highspeed;
 				cap-mmc-highspeed;
@@ -156,6 +146,19 @@ package_otp at 1e8 {
 			};
 		};
 
+		rcc: clock-controller at 44200000 {
+			compatible = "st,stm32mp25-rcc";
+			reg = <0x44200000 0x10000>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+			clock-names = "hse", "hsi", "msi", "lse", "lsi";
+			clocks = <&scmi_clk CK_SCMI_HSE>,
+				<&scmi_clk CK_SCMI_HSI>,
+				<&scmi_clk CK_SCMI_MSI>,
+				<&scmi_clk CK_SCMI_LSE>,
+				<&scmi_clk CK_SCMI_LSI>;
+		};
+
 		syscfg: syscon at 44230000 {
 			compatible = "st,stm32mp25-syscfg", "syscon";
 			reg = <0x44230000 0x10000>;
@@ -174,7 +177,7 @@ gpioa: gpio at 44240000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x0 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOA>;
 				st,bank-name = "GPIOA";
 				status = "disabled";
 			};
@@ -185,7 +188,7 @@ gpiob: gpio at 44250000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x10000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOB>;
 				st,bank-name = "GPIOB";
 				status = "disabled";
 			};
@@ -196,7 +199,7 @@ gpioc: gpio at 44260000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x20000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOC>;
 				st,bank-name = "GPIOC";
 				status = "disabled";
 			};
@@ -207,7 +210,7 @@ gpiod: gpio at 44270000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x30000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOD>;
 				st,bank-name = "GPIOD";
 				status = "disabled";
 			};
@@ -218,7 +221,7 @@ gpioe: gpio at 44280000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x40000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOE>;
 				st,bank-name = "GPIOE";
 				status = "disabled";
 			};
@@ -229,7 +232,7 @@ gpiof: gpio at 44290000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x50000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOF>;
 				st,bank-name = "GPIOF";
 				status = "disabled";
 			};
@@ -240,7 +243,7 @@ gpiog: gpio at 442a0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x60000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOG>;
 				st,bank-name = "GPIOG";
 				status = "disabled";
 			};
@@ -251,7 +254,7 @@ gpioh: gpio at 442b0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x70000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOH>;
 				st,bank-name = "GPIOH";
 				status = "disabled";
 			};
@@ -262,7 +265,7 @@ gpioi: gpio at 442c0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x80000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOI>;
 				st,bank-name = "GPIOI";
 				status = "disabled";
 			};
@@ -273,7 +276,7 @@ gpioj: gpio at 442d0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0x90000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOJ>;
 				st,bank-name = "GPIOJ";
 				status = "disabled";
 			};
@@ -284,7 +287,7 @@ gpiok: gpio at 442e0000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0xa0000 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOK>;
 				st,bank-name = "GPIOK";
 				status = "disabled";
 			};
@@ -303,7 +306,7 @@ gpioz: gpio at 46200000 {
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0 0x400>;
-				clocks = <&ck_icn_ls_mcu>;
+				clocks = <&scmi_clk CK_SCMI_GPIOZ>;
 				st,bank-name = "GPIOZ";
 				st,bank-ioport = <11>;
 				status = "disabled";
-- 
2.25.1



From gabriel.fernandez at foss.st.com  Tue Dec 19 05:09:08 2023
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Tue, 19 Dec 2023 14:09:08 +0100
Subject: [PATCH v7 1/2] clk: stm32: introduce clocks for STM32MP257 platform
In-Reply-To: <20231219130909.265091-1-gabriel.fernandez@foss.st.com>
References: <20231219130909.265091-1-gabriel.fernandez@foss.st.com>
Message-ID: <20231219130909.265091-2-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

This driver is intended for the STM32MP25 clock family and utilizes
the stm32-core API, similar to the stm32mp13 clock driver.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/stm32/Kconfig         |    7 +
 drivers/clk/stm32/Makefile        |    1 +
 drivers/clk/stm32/clk-stm32mp25.c | 1826 +++++++++++++++++++++++++++++
 drivers/clk/stm32/reset-stm32.c   |   59 +-
 drivers/clk/stm32/reset-stm32.h   |    7 +
 drivers/clk/stm32/stm32mp25_rcc.h |  712 +++++++++++
 6 files changed, 2597 insertions(+), 15 deletions(-)
 create mode 100644 drivers/clk/stm32/clk-stm32mp25.c
 create mode 100644 drivers/clk/stm32/stm32mp25_rcc.h

diff --git a/drivers/clk/stm32/Kconfig b/drivers/clk/stm32/Kconfig
index 3c8493a94a11..dca409d52652 100644
--- a/drivers/clk/stm32/Kconfig
+++ b/drivers/clk/stm32/Kconfig
@@ -25,5 +25,12 @@ config COMMON_CLK_STM32MP157
 	help
 	  Support for stm32mp15x SoC family clocks.
 
+config COMMON_CLK_STM32MP257
+	bool "Clock driver for stm32mp25x clocks"
+	depends on ARM64 || COMPILE_TEST
+	default y
+	help
+	  Support for stm32mp25x SoC family clocks.
+
 endif
 
diff --git a/drivers/clk/stm32/Makefile b/drivers/clk/stm32/Makefile
index 5ced7fe3ddec..0a627164fcce 100644
--- a/drivers/clk/stm32/Makefile
+++ b/drivers/clk/stm32/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_COMMON_CLK_STM32MP135)	+= clk-stm32mp13.o clk-stm32-core.o reset-stm32.o
 obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o reset-stm32.o
+obj-$(CONFIG_COMMON_CLK_STM32MP257)	+= clk-stm32mp25.o clk-stm32-core.o reset-stm32.o
diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
new file mode 100644
index 000000000000..313e022c6142
--- /dev/null
+++ b/drivers/clk/stm32/clk-stm32mp25.c
@@ -0,0 +1,1826 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
+ * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
+ */
+
+#include <linux/clk.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+#include "clk-stm32-core.h"
+#include "reset-stm32.h"
+#include "stm32mp25_rcc.h"
+
+#include <dt-bindings/clock/st,stm32mp25-rcc.h>
+#include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+static const struct clk_parent_data adc12_src[] = {
+	{ .name = "ck_flexgen_46" },
+	{ .name = "ck_icn_ls_mcu" },
+};
+
+static const struct clk_parent_data adc3_src[] = {
+	{ .name = "ck_flexgen_47" },
+	{ .name = "ck_icn_ls_mcu" },
+	{ .name = "ck_flexgen_46" },
+};
+
+static const struct clk_parent_data usb2phy1_src[] = {
+	{ .name = "ck_flexgen_57" },
+	{ .name = "hse_div2_ck" },
+};
+
+static const struct clk_parent_data usb2phy2_src[] = {
+	{ .name = "ck_flexgen_58" },
+	{ .name = "hse_div2_ck" },
+};
+
+static const struct clk_parent_data usb3pciphy_src[] = {
+	{ .name = "ck_flexgen_34" },
+	{ .name = "hse_div2_ck" },
+};
+
+static const struct clk_parent_data dsiblane_src[] = {
+	{ .name = "txbyteclk" },
+	{ .name = "ck_ker_ltdc" },
+};
+
+static const struct clk_parent_data dsiphy_src[] = {
+	{ .name = "ck_flexgen_28" },
+	{ .name = "hse_ck" },
+};
+
+static const struct clk_parent_data lvdsphy_src[] = {
+	{ .name = "ck_flexgen_32" },
+	{ .name = "hse_ck" },
+};
+
+static const struct clk_parent_data dts_src[] = {
+	{ .name = "hsi_ck" },
+	{ .name = "hse_ck" },
+	{ .name = "msi_ck" },
+};
+
+static const struct clk_parent_data mco1_src[] = {
+	{ .name = "ck_flexgen_61" },
+	{ .name = "ck_obs0" },
+};
+
+static const struct clk_parent_data mco2_src[] = {
+	{ .name = "ck_flexgen_62" },
+	{ .name = "ck_obs1" },
+};
+
+enum enum_mux_cfg {
+	MUX_ADC12,
+	MUX_ADC3,
+	MUX_DSIBLANE,
+	MUX_DSIPHY,
+	MUX_DTS,
+	MUX_LVDSPHY,
+	MUX_MCO1,
+	MUX_MCO2,
+	MUX_USB2PHY1,
+	MUX_USB2PHY2,
+	MUX_USB3PCIEPHY,
+	MUX_NB
+};
+
+#define MUX_CFG(id, _offset, _shift, _witdh)	\
+	[id] = {				\
+		.offset		= (_offset),	\
+		.shift		= (_shift),	\
+		.width		= (_witdh),	\
+	}
+
+static const struct stm32_mux_cfg stm32mp25_muxes[MUX_NB] = {
+	MUX_CFG(MUX_ADC12,		RCC_ADC12CFGR,		12,	1),
+	MUX_CFG(MUX_ADC3,		RCC_ADC3CFGR,		12,	2),
+	MUX_CFG(MUX_DSIBLANE,		RCC_DSICFGR,		12,	1),
+	MUX_CFG(MUX_DSIPHY,		RCC_DSICFGR,		15,	1),
+	MUX_CFG(MUX_DTS,		RCC_DTSCFGR,		12,	2),
+	MUX_CFG(MUX_LVDSPHY,		RCC_LVDSCFGR,		15,	1),
+	MUX_CFG(MUX_MCO1,		RCC_MCO1CFGR,		0,	1),
+	MUX_CFG(MUX_MCO2,		RCC_MCO2CFGR,		0,	1),
+	MUX_CFG(MUX_USB2PHY1,		RCC_USB2PHY1CFGR,	15,	1),
+	MUX_CFG(MUX_USB2PHY2,		RCC_USB2PHY2CFGR,	15,	1),
+	MUX_CFG(MUX_USB3PCIEPHY,	RCC_USB3PCIEPHYCFGR,	15,	1),
+};
+
+enum enum_gate_cfg {
+	GATE_ADC12,
+	GATE_ADC3,
+	GATE_ADF1,
+	GATE_CCI,
+	GATE_CRC,
+	GATE_CRYP1,
+	GATE_CRYP2,
+	GATE_CSI,
+	GATE_DCMIPP,
+	GATE_DSI,
+	GATE_DTS,
+	GATE_ETH1,
+	GATE_ETH1MAC,
+	GATE_ETH1RX,
+	GATE_ETH1STP,
+	GATE_ETH1TX,
+	GATE_ETH2,
+	GATE_ETH2MAC,
+	GATE_ETH2RX,
+	GATE_ETH2STP,
+	GATE_ETH2TX,
+	GATE_ETHSW,
+	GATE_ETHSWACMCFG,
+	GATE_ETHSWACMMSG,
+	GATE_ETHSWMAC,
+	GATE_ETHSWREF,
+	GATE_FDCAN,
+	GATE_GPU,
+	GATE_HASH,
+	GATE_HDP,
+	GATE_I2C1,
+	GATE_I2C2,
+	GATE_I2C3,
+	GATE_I2C4,
+	GATE_I2C5,
+	GATE_I2C6,
+	GATE_I2C7,
+	GATE_I2C8,
+	GATE_I3C1,
+	GATE_I3C2,
+	GATE_I3C3,
+	GATE_I3C4,
+	GATE_IS2M,
+	GATE_IWDG1,
+	GATE_IWDG2,
+	GATE_IWDG3,
+	GATE_IWDG4,
+	GATE_IWDG5,
+	GATE_LPTIM1,
+	GATE_LPTIM2,
+	GATE_LPTIM3,
+	GATE_LPTIM4,
+	GATE_LPTIM5,
+	GATE_LPUART1,
+	GATE_LTDC,
+	GATE_LVDS,
+	GATE_MCO1,
+	GATE_MCO2,
+	GATE_MDF1,
+	GATE_OSPIIOM,
+	GATE_PCIE,
+	GATE_PKA,
+	GATE_RNG,
+	GATE_SAES,
+	GATE_SAI1,
+	GATE_SAI2,
+	GATE_SAI3,
+	GATE_SAI4,
+	GATE_SDMMC1,
+	GATE_SDMMC2,
+	GATE_SDMMC3,
+	GATE_SERC,
+	GATE_SPDIFRX,
+	GATE_SPI1,
+	GATE_SPI2,
+	GATE_SPI3,
+	GATE_SPI4,
+	GATE_SPI5,
+	GATE_SPI6,
+	GATE_SPI7,
+	GATE_SPI8,
+	GATE_TIM1,
+	GATE_TIM10,
+	GATE_TIM11,
+	GATE_TIM12,
+	GATE_TIM13,
+	GATE_TIM14,
+	GATE_TIM15,
+	GATE_TIM16,
+	GATE_TIM17,
+	GATE_TIM2,
+	GATE_TIM20,
+	GATE_TIM3,
+	GATE_TIM4,
+	GATE_TIM5,
+	GATE_TIM6,
+	GATE_TIM7,
+	GATE_TIM8,
+	GATE_UART4,
+	GATE_UART5,
+	GATE_UART7,
+	GATE_UART8,
+	GATE_UART9,
+	GATE_USART1,
+	GATE_USART2,
+	GATE_USART3,
+	GATE_USART6,
+	GATE_USB2,
+	GATE_USB2PHY1,
+	GATE_USB2PHY2,
+	GATE_USB3DR,
+	GATE_USB3PCIEPHY,
+	GATE_USBTC,
+	GATE_VDEC,
+	GATE_VENC,
+	GATE_VREF,
+	GATE_WWDG1,
+	GATE_WWDG2,
+	GATE_NB
+};
+
+#define GATE_CFG(id, _offset, _bit_idx, _offset_clr)	\
+	[id] = {					\
+		.offset		= (_offset),		\
+		.bit_idx	= (_bit_idx),		\
+		.set_clr	= (_offset_clr),	\
+	}
+
+static const struct stm32_gate_cfg stm32mp25_gates[GATE_NB] = {
+	GATE_CFG(GATE_ADC12,		RCC_ADC12CFGR,		1,	0),
+	GATE_CFG(GATE_ADC3,		RCC_ADC3CFGR,		1,	0),
+	GATE_CFG(GATE_ADF1,		RCC_ADF1CFGR,		1,	0),
+	GATE_CFG(GATE_CCI,		RCC_CCICFGR,		1,	0),
+	GATE_CFG(GATE_CRC,		RCC_CRCCFGR,		1,	0),
+	GATE_CFG(GATE_CRYP1,		RCC_CRYP1CFGR,		1,	0),
+	GATE_CFG(GATE_CRYP2,		RCC_CRYP2CFGR,		1,	0),
+	GATE_CFG(GATE_CSI,		RCC_CSICFGR,		1,	0),
+	GATE_CFG(GATE_DCMIPP,		RCC_DCMIPPCFGR,		1,	0),
+	GATE_CFG(GATE_DSI,		RCC_DSICFGR,		1,	0),
+	GATE_CFG(GATE_DTS,		RCC_DTSCFGR,		1,	0),
+	GATE_CFG(GATE_ETH1,		RCC_ETH1CFGR,		5,	0),
+	GATE_CFG(GATE_ETH1MAC,		RCC_ETH1CFGR,		1,	0),
+	GATE_CFG(GATE_ETH1RX,		RCC_ETH1CFGR,		10,	0),
+	GATE_CFG(GATE_ETH1STP,		RCC_ETH1CFGR,		4,	0),
+	GATE_CFG(GATE_ETH1TX,		RCC_ETH1CFGR,		8,	0),
+	GATE_CFG(GATE_ETH2,		RCC_ETH2CFGR,		5,	0),
+	GATE_CFG(GATE_ETH2MAC,		RCC_ETH2CFGR,		1,	0),
+	GATE_CFG(GATE_ETH2RX,		RCC_ETH2CFGR,		10,	0),
+	GATE_CFG(GATE_ETH2STP,		RCC_ETH2CFGR,		4,	0),
+	GATE_CFG(GATE_ETH2TX,		RCC_ETH2CFGR,		8,	0),
+	GATE_CFG(GATE_ETHSW,		RCC_ETHSWCFGR,		5,	0),
+	GATE_CFG(GATE_ETHSWACMCFG,	RCC_ETHSWACMCFGR,	1,	0),
+	GATE_CFG(GATE_ETHSWACMMSG,	RCC_ETHSWACMMSGCFGR,	1,	0),
+	GATE_CFG(GATE_ETHSWMAC,		RCC_ETHSWCFGR,		1,	0),
+	GATE_CFG(GATE_ETHSWREF,		RCC_ETHSWCFGR,		21,	0),
+	GATE_CFG(GATE_FDCAN,		RCC_FDCANCFGR,		1,	0),
+	GATE_CFG(GATE_GPU,		RCC_GPUCFGR,		1,	0),
+	GATE_CFG(GATE_HASH,		RCC_HASHCFGR,		1,	0),
+	GATE_CFG(GATE_HDP,		RCC_HDPCFGR,		1,	0),
+	GATE_CFG(GATE_I2C1,		RCC_I2C1CFGR,		1,	0),
+	GATE_CFG(GATE_I2C2,		RCC_I2C2CFGR,		1,	0),
+	GATE_CFG(GATE_I2C3,		RCC_I2C3CFGR,		1,	0),
+	GATE_CFG(GATE_I2C4,		RCC_I2C4CFGR,		1,	0),
+	GATE_CFG(GATE_I2C5,		RCC_I2C5CFGR,		1,	0),
+	GATE_CFG(GATE_I2C6,		RCC_I2C6CFGR,		1,	0),
+	GATE_CFG(GATE_I2C7,		RCC_I2C7CFGR,		1,	0),
+	GATE_CFG(GATE_I2C8,		RCC_I2C8CFGR,		1,	0),
+	GATE_CFG(GATE_I3C1,		RCC_I3C1CFGR,		1,	0),
+	GATE_CFG(GATE_I3C2,		RCC_I3C2CFGR,		1,	0),
+	GATE_CFG(GATE_I3C3,		RCC_I3C3CFGR,		1,	0),
+	GATE_CFG(GATE_I3C4,		RCC_I3C4CFGR,		1,	0),
+	GATE_CFG(GATE_IS2M,		RCC_IS2MCFGR,		1,	0),
+	GATE_CFG(GATE_IWDG1,		RCC_IWDG1CFGR,		1,	0),
+	GATE_CFG(GATE_IWDG2,		RCC_IWDG2CFGR,		1,	0),
+	GATE_CFG(GATE_IWDG3,		RCC_IWDG3CFGR,		1,	0),
+	GATE_CFG(GATE_IWDG4,		RCC_IWDG4CFGR,		1,	0),
+	GATE_CFG(GATE_IWDG5,		RCC_IWDG5CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM1,		RCC_LPTIM1CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM2,		RCC_LPTIM2CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM3,		RCC_LPTIM3CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM4,		RCC_LPTIM4CFGR,		1,	0),
+	GATE_CFG(GATE_LPTIM5,		RCC_LPTIM5CFGR,		1,	0),
+	GATE_CFG(GATE_LPUART1,		RCC_LPUART1CFGR,	1,	0),
+	GATE_CFG(GATE_LTDC,		RCC_LTDCCFGR,		1,	0),
+	GATE_CFG(GATE_LVDS,		RCC_LVDSCFGR,		1,	0),
+	GATE_CFG(GATE_MCO1,		RCC_MCO1CFGR,		8,	0),
+	GATE_CFG(GATE_MCO2,		RCC_MCO2CFGR,		8,	0),
+	GATE_CFG(GATE_MDF1,		RCC_MDF1CFGR,		1,	0),
+	GATE_CFG(GATE_OSPIIOM,		RCC_OSPIIOMCFGR,	1,	0),
+	GATE_CFG(GATE_PCIE,		RCC_PCIECFGR,		1,	0),
+	GATE_CFG(GATE_PKA,		RCC_PKACFGR,		1,	0),
+	GATE_CFG(GATE_RNG,		RCC_RNGCFGR,		1,	0),
+	GATE_CFG(GATE_SAES,		RCC_SAESCFGR,		1,	0),
+	GATE_CFG(GATE_SAI1,		RCC_SAI1CFGR,		1,	0),
+	GATE_CFG(GATE_SAI2,		RCC_SAI2CFGR,		1,	0),
+	GATE_CFG(GATE_SAI3,		RCC_SAI3CFGR,		1,	0),
+	GATE_CFG(GATE_SAI4,		RCC_SAI4CFGR,		1,	0),
+	GATE_CFG(GATE_SDMMC1,		RCC_SDMMC1CFGR,		1,	0),
+	GATE_CFG(GATE_SDMMC2,		RCC_SDMMC2CFGR,		1,	0),
+	GATE_CFG(GATE_SDMMC3,		RCC_SDMMC3CFGR,		1,	0),
+	GATE_CFG(GATE_SERC,		RCC_SERCCFGR,		1,	0),
+	GATE_CFG(GATE_SPDIFRX,		RCC_SPDIFRXCFGR,	1,	0),
+	GATE_CFG(GATE_SPI1,		RCC_SPI1CFGR,		1,	0),
+	GATE_CFG(GATE_SPI2,		RCC_SPI2CFGR,		1,	0),
+	GATE_CFG(GATE_SPI3,		RCC_SPI3CFGR,		1,	0),
+	GATE_CFG(GATE_SPI4,		RCC_SPI4CFGR,		1,	0),
+	GATE_CFG(GATE_SPI5,		RCC_SPI5CFGR,		1,	0),
+	GATE_CFG(GATE_SPI6,		RCC_SPI6CFGR,		1,	0),
+	GATE_CFG(GATE_SPI7,		RCC_SPI7CFGR,		1,	0),
+	GATE_CFG(GATE_SPI8,		RCC_SPI8CFGR,		1,	0),
+	GATE_CFG(GATE_TIM1,		RCC_TIM1CFGR,		1,	0),
+	GATE_CFG(GATE_TIM10,		RCC_TIM10CFGR,		1,	0),
+	GATE_CFG(GATE_TIM11,		RCC_TIM11CFGR,		1,	0),
+	GATE_CFG(GATE_TIM12,		RCC_TIM12CFGR,		1,	0),
+	GATE_CFG(GATE_TIM13,		RCC_TIM13CFGR,		1,	0),
+	GATE_CFG(GATE_TIM14,		RCC_TIM14CFGR,		1,	0),
+	GATE_CFG(GATE_TIM15,		RCC_TIM15CFGR,		1,	0),
+	GATE_CFG(GATE_TIM16,		RCC_TIM16CFGR,		1,	0),
+	GATE_CFG(GATE_TIM17,		RCC_TIM17CFGR,		1,	0),
+	GATE_CFG(GATE_TIM2,		RCC_TIM2CFGR,		1,	0),
+	GATE_CFG(GATE_TIM20,		RCC_TIM20CFGR,		1,	0),
+	GATE_CFG(GATE_TIM3,		RCC_TIM3CFGR,		1,	0),
+	GATE_CFG(GATE_TIM4,		RCC_TIM4CFGR,		1,	0),
+	GATE_CFG(GATE_TIM5,		RCC_TIM5CFGR,		1,	0),
+	GATE_CFG(GATE_TIM6,		RCC_TIM6CFGR,		1,	0),
+	GATE_CFG(GATE_TIM7,		RCC_TIM7CFGR,		1,	0),
+	GATE_CFG(GATE_TIM8,		RCC_TIM8CFGR,		1,	0),
+	GATE_CFG(GATE_UART4,		RCC_UART4CFGR,		1,	0),
+	GATE_CFG(GATE_UART5,		RCC_UART5CFGR,		1,	0),
+	GATE_CFG(GATE_UART7,		RCC_UART7CFGR,		1,	0),
+	GATE_CFG(GATE_UART8,		RCC_UART8CFGR,		1,	0),
+	GATE_CFG(GATE_UART9,		RCC_UART9CFGR,		1,	0),
+	GATE_CFG(GATE_USART1,		RCC_USART1CFGR,		1,	0),
+	GATE_CFG(GATE_USART2,		RCC_USART2CFGR,		1,	0),
+	GATE_CFG(GATE_USART3,		RCC_USART3CFGR,		1,	0),
+	GATE_CFG(GATE_USART6,		RCC_USART6CFGR,		1,	0),
+	GATE_CFG(GATE_USB2,		RCC_USB2CFGR,		1,	0),
+	GATE_CFG(GATE_USB2PHY1,		RCC_USB2PHY1CFGR,	1,	0),
+	GATE_CFG(GATE_USB2PHY2,		RCC_USB2PHY2CFGR,	1,	0),
+	GATE_CFG(GATE_USB3DR,		RCC_USB3DRCFGR,		1,	0),
+	GATE_CFG(GATE_USB3PCIEPHY,	RCC_USB3PCIEPHYCFGR,	1,	0),
+	GATE_CFG(GATE_USBTC,		RCC_USBTCCFGR,		1,	0),
+	GATE_CFG(GATE_VDEC,		RCC_VDECCFGR,		1,	0),
+	GATE_CFG(GATE_VENC,		RCC_VENCCFGR,		1,	0),
+	GATE_CFG(GATE_VREF,		RCC_VREFCFGR,		1,	0),
+	GATE_CFG(GATE_WWDG1,		RCC_WWDG1CFGR,		1,	0),
+	GATE_CFG(GATE_WWDG2,		RCC_WWDG2CFGR,		1,	0),
+};
+
+/* ADC */
+static struct clk_stm32_gate ck_icn_p_adc12 = {
+	.gate_id = GATE_ADC12,
+	.hw.init = CLK_HW_INIT("ck_icn_p_adc12", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_composite ck_ker_adc12 = {
+	.gate_id = GATE_ADC12,
+	.mux_id = MUX_ADC12,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_adc12", adc12_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_adc3 = {
+	.gate_id = GATE_ADC3,
+	.hw.init = CLK_HW_INIT("ck_icn_p_adc3", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_composite ck_ker_adc3 = {
+	.gate_id = GATE_ADC3,
+	.mux_id = MUX_ADC3,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_adc3", adc3_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+/* ADF */
+static struct clk_stm32_gate ck_icn_p_adf1 = {
+	.gate_id = GATE_ADF1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_adf1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_adf1 = {
+	.gate_id = GATE_ADF1,
+	.hw.init = CLK_HW_INIT("ck_ker_adf1", "ck_flexgen_42", &clk_stm32_gate_ops, 0),
+};
+
+/* DCMI */
+static struct clk_stm32_gate ck_icn_p_cci = {
+	.gate_id = GATE_CCI,
+	.hw.init = CLK_HW_INIT("ck_icn_p_cci", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+/* CSI-HOST */
+static struct clk_stm32_gate ck_icn_p_csi = {
+	.gate_id = GATE_CSI,
+	.hw.init = CLK_HW_INIT("ck_icn_p_csi", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_csi = {
+	.gate_id = GATE_CSI,
+	.hw.init = CLK_HW_INIT("ck_ker_csi", "ck_flexgen_29", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_csitxesc = {
+	.gate_id = GATE_CSI,
+	.hw.init = CLK_HW_INIT("ck_ker_csitxesc", "ck_flexgen_30", &clk_stm32_gate_ops, 0),
+};
+
+/* CSI-PHY */
+static struct clk_stm32_gate ck_ker_csiphy = {
+	.gate_id = GATE_CSI,
+	.hw.init = CLK_HW_INIT("ck_ker_csiphy", "ck_flexgen_31", &clk_stm32_gate_ops, 0),
+};
+
+/* DCMIPP */
+static struct clk_stm32_gate ck_icn_p_dcmipp = {
+	.gate_id = GATE_DCMIPP,
+	.hw.init = CLK_HW_INIT("ck_icn_p_dcmipp", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
+};
+
+/* CRC */
+static struct clk_stm32_gate ck_icn_p_crc = {
+	.gate_id = GATE_CRC,
+	.hw.init = CLK_HW_INIT("ck_icn_p_crc", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+/* CRYP */
+static struct clk_stm32_gate ck_icn_p_cryp1 = {
+	.gate_id = GATE_CRYP1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_cryp1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_cryp2 = {
+	.gate_id = GATE_CRYP2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_cryp2", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+/* DBG & TRACE*/
+/* Trace and debug clocks are managed by SCMI */
+
+/* LTDC */
+static struct clk_stm32_gate ck_icn_p_ltdc = {
+	.gate_id = GATE_LTDC,
+	.hw.init = CLK_HW_INIT("ck_icn_p_ltdc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_ltdc = {
+	.gate_id = GATE_LTDC,
+	.hw.init = CLK_HW_INIT("ck_ker_ltdc", "ck_flexgen_27", &clk_stm32_gate_ops,
+			       CLK_SET_RATE_PARENT),
+};
+
+/* DSI */
+static struct clk_stm32_gate ck_icn_p_dsi = {
+	.gate_id = GATE_DSI,
+	.hw.init = CLK_HW_INIT("ck_icn_p_dsi", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_composite clk_lanebyte = {
+	.gate_id = GATE_DSI,
+	.mux_id = MUX_DSIBLANE,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("clk_lanebyte", dsiblane_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+/* LVDS */
+static struct clk_stm32_gate ck_icn_p_lvds = {
+	.gate_id = GATE_LVDS,
+	.hw.init = CLK_HW_INIT("ck_icn_p_lvds", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
+};
+
+/* DSI PHY */
+static struct clk_stm32_composite clk_phy_dsi = {
+	.gate_id = GATE_DSI,
+	.mux_id = MUX_DSIPHY,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("clk_phy_dsi", dsiphy_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+/* LVDS PHY */
+static struct clk_stm32_composite ck_ker_lvdsphy = {
+	.gate_id = GATE_LVDS,
+	.mux_id = MUX_LVDSPHY,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_lvdsphy", lvdsphy_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+/* DTS */
+static struct clk_stm32_composite ck_ker_dts = {
+	.gate_id = GATE_DTS,
+	.mux_id = MUX_DTS,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_dts", dts_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+/* ETHERNET */
+static struct clk_stm32_gate ck_icn_p_eth1 = {
+	.gate_id = GATE_ETH1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_eth1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth1stp = {
+	.gate_id = GATE_ETH1STP,
+	.hw.init = CLK_HW_INIT("ck_ker_eth1stp", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth1 = {
+	.gate_id = GATE_ETH1,
+	.hw.init = CLK_HW_INIT("ck_ker_eth1", "ck_flexgen_54", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth1ptp = {
+	.gate_id = GATE_ETH1,
+	.hw.init = CLK_HW_INIT("ck_ker_eth1ptp", "ck_flexgen_56", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth1mac = {
+	.gate_id = GATE_ETH1MAC,
+	.hw.init = CLK_HW_INIT("ck_ker_eth1mac", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth1tx = {
+	.gate_id = GATE_ETH1TX,
+	.hw.init = CLK_HW_INIT("ck_ker_eth1tx", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth1rx = {
+	.gate_id = GATE_ETH1RX,
+	.hw.init = CLK_HW_INIT("ck_ker_eth1rx", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_eth2 = {
+	.gate_id = GATE_ETH2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_eth2", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth2stp = {
+	.gate_id = GATE_ETH2STP,
+	.hw.init = CLK_HW_INIT("ck_ker_eth2stp", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth2 = {
+	.gate_id = GATE_ETH2,
+	.hw.init = CLK_HW_INIT("ck_ker_eth2", "ck_flexgen_55", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth2ptp = {
+	.gate_id = GATE_ETH2,
+	.hw.init = CLK_HW_INIT("ck_ker_eth2ptp", "ck_flexgen_56", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth2mac = {
+	.gate_id = GATE_ETH2MAC,
+	.hw.init = CLK_HW_INIT("ck_ker_eth2mac", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth2tx = {
+	.gate_id = GATE_ETH2TX,
+	.hw.init = CLK_HW_INIT("ck_ker_eth2tx", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_eth2rx = {
+	.gate_id = GATE_ETH2RX,
+	.hw.init = CLK_HW_INIT("ck_ker_eth2rx", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_ethsw = {
+	.gate_id = GATE_ETHSWMAC,
+	.hw.init = CLK_HW_INIT("ck_icn_p_ethsw", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_ethsw = {
+	.gate_id = GATE_ETHSW,
+	.hw.init = CLK_HW_INIT("ck_ker_ethsw", "ck_flexgen_54", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_ethswref = {
+	.gate_id = GATE_ETHSWREF,
+	.hw.init = CLK_HW_INIT("ck_ker_ethswref", "ck_flexgen_60", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_ethsw_acm_cfg = {
+	.gate_id = GATE_ETHSWACMCFG,
+	.hw.init = CLK_HW_INIT("ck_icn_p_ethsw_acm_cfg", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_ethsw_acm_msg = {
+	.gate_id = GATE_ETHSWACMMSG,
+	.hw.init = CLK_HW_INIT("ck_icn_p_ethsw_acm_msg", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+/* FDCAN */
+static struct clk_stm32_gate ck_icn_p_fdcan = {
+	.gate_id = GATE_FDCAN,
+	.hw.init = CLK_HW_INIT("ck_icn_p_fdcan", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_fdcan = {
+	.gate_id = GATE_FDCAN,
+	.hw.init = CLK_HW_INIT("ck_ker_fdcan", "ck_flexgen_26", &clk_stm32_gate_ops, 0),
+};
+
+/* GPU */
+static struct clk_stm32_gate ck_icn_m_gpu = {
+	.gate_id = GATE_GPU,
+	.hw.init = CLK_HW_INIT("ck_icn_m_gpu", "ck_flexgen_59", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_gpu = {
+	.gate_id = GATE_GPU,
+	.hw.init = CLK_HW_INIT("ck_ker_gpu", "ck_pll3", &clk_stm32_gate_ops, 0),
+};
+
+/* HASH */
+static struct clk_stm32_gate ck_icn_p_hash = {
+	.gate_id = GATE_HASH,
+	.hw.init = CLK_HW_INIT("ck_icn_p_hash", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+/* HDP */
+static struct clk_stm32_gate ck_icn_p_hdp = {
+	.gate_id = GATE_HDP,
+	.hw.init = CLK_HW_INIT("ck_icn_p_hdp", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
+};
+
+/* I2C */
+static struct clk_stm32_gate ck_icn_p_i2c8 = {
+	.gate_id = GATE_I2C8,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i2c8", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i2c1 = {
+	.gate_id = GATE_I2C1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i2c1", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i2c2 = {
+	.gate_id = GATE_I2C2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i2c2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i2c3 = {
+	.gate_id = GATE_I2C3,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i2c3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i2c4 = {
+	.gate_id = GATE_I2C4,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i2c4", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i2c5 = {
+	.gate_id = GATE_I2C5,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i2c5", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i2c6 = {
+	.gate_id = GATE_I2C6,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i2c6", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i2c7 = {
+	.gate_id = GATE_I2C7,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i2c7", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i2c1 = {
+	.gate_id = GATE_I2C1,
+	.hw.init = CLK_HW_INIT("ck_ker_i2c1", "ck_flexgen_12", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i2c2 = {
+	.gate_id = GATE_I2C2,
+	.hw.init = CLK_HW_INIT("ck_ker_i2c2", "ck_flexgen_12", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i2c3 = {
+	.gate_id = GATE_I2C3,
+	.hw.init = CLK_HW_INIT("ck_ker_i2c3", "ck_flexgen_13", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i2c5 = {
+	.gate_id = GATE_I2C5,
+	.hw.init = CLK_HW_INIT("ck_ker_i2c5", "ck_flexgen_13", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i2c4 = {
+	.gate_id = GATE_I2C4,
+	.hw.init = CLK_HW_INIT("ck_ker_i2c4", "ck_flexgen_14", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i2c6 = {
+	.gate_id = GATE_I2C6,
+	.hw.init = CLK_HW_INIT("ck_ker_i2c6", "ck_flexgen_14", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i2c7 = {
+	.gate_id = GATE_I2C7,
+	.hw.init = CLK_HW_INIT("ck_ker_i2c7", "ck_flexgen_15", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i2c8 = {
+	.gate_id = GATE_I2C8,
+	.hw.init = CLK_HW_INIT("ck_ker_i2c8", "ck_flexgen_38", &clk_stm32_gate_ops, 0),
+};
+
+/* I3C */
+static struct clk_stm32_gate ck_icn_p_i3c1 = {
+	.gate_id = GATE_I3C1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i3c1", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i3c2 = {
+	.gate_id = GATE_I3C2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i3c2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i3c3 = {
+	.gate_id = GATE_I3C3,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i3c3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_i3c4 = {
+	.gate_id = GATE_I3C4,
+	.hw.init = CLK_HW_INIT("ck_icn_p_i3c4", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i3c1 = {
+	.gate_id = GATE_I3C1,
+	.hw.init = CLK_HW_INIT("ck_ker_i3c1", "ck_flexgen_12", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i3c2 = {
+	.gate_id = GATE_I3C2,
+	.hw.init = CLK_HW_INIT("ck_ker_i3c2", "ck_flexgen_12", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i3c3 = {
+	.gate_id = GATE_I3C3,
+	.hw.init = CLK_HW_INIT("ck_ker_i3c3", "ck_flexgen_13", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_i3c4 = {
+	.gate_id = GATE_I3C4,
+	.hw.init = CLK_HW_INIT("ck_ker_i3c4", "ck_flexgen_36", &clk_stm32_gate_ops, 0),
+};
+
+/* I2S */
+static struct clk_stm32_gate ck_icn_p_is2m = {
+	.gate_id = GATE_IS2M,
+	.hw.init = CLK_HW_INIT("ck_icn_p_is2m", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
+};
+
+/* IWDG */
+static struct clk_stm32_gate ck_icn_p_iwdg2 = {
+	.gate_id = GATE_IWDG2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_iwdg2", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_iwdg3 = {
+	.gate_id = GATE_IWDG3,
+	.hw.init = CLK_HW_INIT("ck_icn_p_iwdg3", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_iwdg4 = {
+	.gate_id = GATE_IWDG4,
+	.hw.init = CLK_HW_INIT("ck_icn_p_iwdg4", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_iwdg5 = {
+	.gate_id = GATE_IWDG5,
+	.hw.init = CLK_HW_INIT("ck_icn_p_iwdg5", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+/* LPTIM */
+static struct clk_stm32_gate ck_icn_p_lptim1 = {
+	.gate_id = GATE_LPTIM1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_lptim1", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_lptim2 = {
+	.gate_id = GATE_LPTIM2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_lptim2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_lptim3 = {
+	.gate_id = GATE_LPTIM3,
+	.hw.init = CLK_HW_INIT("ck_icn_p_lptim3", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_lptim4 = {
+	.gate_id = GATE_LPTIM4,
+	.hw.init = CLK_HW_INIT("ck_icn_p_lptim4", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_lptim5 = {
+	.gate_id = GATE_LPTIM5,
+	.hw.init = CLK_HW_INIT("ck_icn_p_lptim5", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_lptim1 = {
+	.gate_id = GATE_LPTIM1,
+	.hw.init = CLK_HW_INIT("ck_ker_lptim1", "ck_flexgen_07", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_lptim2 = {
+	.gate_id = GATE_LPTIM2,
+	.hw.init = CLK_HW_INIT("ck_ker_lptim2", "ck_flexgen_07", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_lptim3 = {
+	.gate_id = GATE_LPTIM3,
+	.hw.init = CLK_HW_INIT("ck_ker_lptim3", "ck_flexgen_40", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_lptim4 = {
+	.gate_id = GATE_LPTIM4,
+	.hw.init = CLK_HW_INIT("ck_ker_lptim4", "ck_flexgen_41", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_lptim5 = {
+	.gate_id = GATE_LPTIM5,
+	.hw.init = CLK_HW_INIT("ck_ker_lptim5", "ck_flexgen_41", &clk_stm32_gate_ops, 0),
+};
+
+/* LPUART */
+static struct clk_stm32_gate ck_icn_p_lpuart1 = {
+	.gate_id = GATE_LPUART1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_lpuart1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_lpuart1 = {
+	.gate_id = GATE_LPUART1,
+	.hw.init = CLK_HW_INIT("ck_ker_lpuart1", "ck_flexgen_39", &clk_stm32_gate_ops, 0),
+};
+
+/* MCO1 & MCO2 */
+static struct clk_stm32_composite ck_mco1 = {
+	.gate_id = GATE_MCO1,
+	.mux_id = MUX_MCO1,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_mco1", mco1_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+static struct clk_stm32_composite ck_mco2 = {
+	.gate_id = GATE_MCO2,
+	.mux_id = MUX_MCO2,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_mco2", mco2_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+/* MDF */
+static struct clk_stm32_gate ck_icn_p_mdf1 = {
+	.gate_id = GATE_MDF1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_mdf1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_mdf1 = {
+	.gate_id = GATE_MDF1,
+	.hw.init = CLK_HW_INIT("ck_ker_mdf1", "ck_flexgen_23", &clk_stm32_gate_ops, 0),
+};
+
+/* OSPI */
+static struct clk_stm32_gate ck_icn_p_ospiiom = {
+	.gate_id = GATE_OSPIIOM,
+	.hw.init = CLK_HW_INIT("ck_icn_p_ospiiom", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+/* PCIE */
+static struct clk_stm32_gate ck_icn_p_pcie = {
+	.gate_id = GATE_PCIE,
+	.hw.init = CLK_HW_INIT("ck_icn_p_pcie", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+/* SAI */
+static struct clk_stm32_gate ck_icn_p_sai1 = {
+	.gate_id = GATE_SAI1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_sai1", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_sai2 = {
+	.gate_id = GATE_SAI2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_sai2", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_sai3 = {
+	.gate_id = GATE_SAI3,
+	.hw.init = CLK_HW_INIT("ck_icn_p_sai3", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_sai4 = {
+	.gate_id = GATE_SAI4,
+	.hw.init = CLK_HW_INIT("ck_icn_p_sai4", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_sai1 = {
+	.gate_id = GATE_SAI1,
+	.hw.init = CLK_HW_INIT("ck_ker_sai1", "ck_flexgen_23", &clk_stm32_gate_ops,
+			       CLK_SET_RATE_PARENT),
+};
+
+static struct clk_stm32_gate ck_ker_sai2 = {
+	.gate_id = GATE_SAI2,
+	.hw.init = CLK_HW_INIT("ck_ker_sai2", "ck_flexgen_24", &clk_stm32_gate_ops,
+			       CLK_SET_RATE_PARENT),
+};
+
+static struct clk_stm32_gate ck_ker_sai3 = {
+	.gate_id = GATE_SAI3,
+	.hw.init = CLK_HW_INIT("ck_ker_sai3", "ck_flexgen_25", &clk_stm32_gate_ops,
+			       CLK_SET_RATE_PARENT),
+};
+
+static struct clk_stm32_gate ck_ker_sai4 = {
+	.gate_id = GATE_SAI4,
+	.hw.init = CLK_HW_INIT("ck_ker_sai4", "ck_flexgen_25", &clk_stm32_gate_ops,
+			       CLK_SET_RATE_PARENT),
+};
+
+/* SDMMC */
+static struct clk_stm32_gate ck_icn_m_sdmmc1 = {
+	.gate_id = GATE_SDMMC1,
+	.hw.init = CLK_HW_INIT("ck_icn_m_sdmmc1", "ck_icn_sdmmc", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_m_sdmmc2 = {
+	.gate_id = GATE_SDMMC2,
+	.hw.init = CLK_HW_INIT("ck_icn_m_sdmmc2", "ck_icn_sdmmc", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_m_sdmmc3 = {
+	.gate_id = GATE_SDMMC3,
+	.hw.init = CLK_HW_INIT("ck_icn_m_sdmmc3", "ck_icn_sdmmc", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_sdmmc1 = {
+	.gate_id = GATE_SDMMC1,
+	.hw.init = CLK_HW_INIT("ck_ker_sdmmc1", "ck_flexgen_51", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_sdmmc2 = {
+	.gate_id = GATE_SDMMC2,
+	.hw.init = CLK_HW_INIT("ck_ker_sdmmc2", "ck_flexgen_52", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_sdmmc3 = {
+	.gate_id = GATE_SDMMC3,
+	.hw.init = CLK_HW_INIT("ck_ker_sdmmc3", "ck_flexgen_53", &clk_stm32_gate_ops, 0),
+};
+
+/* SPDIF */
+static struct clk_stm32_gate ck_icn_p_spdifrx = {
+	.gate_id = GATE_SPDIFRX,
+	.hw.init = CLK_HW_INIT("ck_icn_p_spdifrx", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_spdifrx = {
+	.gate_id = GATE_SPDIFRX,
+	.hw.init = CLK_HW_INIT("ck_ker_spdifrx", "ck_flexgen_11", &clk_stm32_gate_ops, 0),
+};
+
+/* SPI */
+static struct clk_stm32_gate ck_icn_p_spi1 = {
+	.gate_id = GATE_SPI1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_spi1", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_spi2 = {
+	.gate_id = GATE_SPI2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_spi2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_spi3 = {
+	.gate_id = GATE_SPI3,
+	.hw.init = CLK_HW_INIT("ck_icn_p_spi3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_spi4 = {
+	.gate_id = GATE_SPI4,
+	.hw.init = CLK_HW_INIT("ck_icn_p_spi4", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_spi5 = {
+	.gate_id = GATE_SPI5,
+	.hw.init = CLK_HW_INIT("ck_icn_p_spi5", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_spi6 = {
+	.gate_id = GATE_SPI6,
+	.hw.init = CLK_HW_INIT("ck_icn_p_spi6", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_spi7 = {
+	.gate_id = GATE_SPI7,
+	.hw.init = CLK_HW_INIT("ck_icn_p_spi7", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_spi8 = {
+	.gate_id = GATE_SPI8,
+	.hw.init = CLK_HW_INIT("ck_icn_p_spi8", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_spi1 = {
+	.gate_id = GATE_SPI1,
+	.hw.init = CLK_HW_INIT("ck_ker_spi1", "ck_flexgen_16", &clk_stm32_gate_ops,
+			       CLK_SET_RATE_PARENT),
+};
+
+static struct clk_stm32_gate ck_ker_spi2 = {
+	.gate_id = GATE_SPI2,
+	.hw.init = CLK_HW_INIT("ck_ker_spi2", "ck_flexgen_10", &clk_stm32_gate_ops,
+			       CLK_SET_RATE_PARENT),
+};
+
+static struct clk_stm32_gate ck_ker_spi3 = {
+	.gate_id = GATE_SPI3,
+	.hw.init = CLK_HW_INIT("ck_ker_spi3", "ck_flexgen_10", &clk_stm32_gate_ops,
+			       CLK_SET_RATE_PARENT),
+};
+
+static struct clk_stm32_gate ck_ker_spi4 = {
+	.gate_id = GATE_SPI4,
+	.hw.init = CLK_HW_INIT("ck_ker_spi4", "ck_flexgen_17", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_spi5 = {
+	.gate_id = GATE_SPI5,
+	.hw.init = CLK_HW_INIT("ck_ker_spi5", "ck_flexgen_17", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_spi6 = {
+	.gate_id = GATE_SPI6,
+	.hw.init = CLK_HW_INIT("ck_ker_spi6", "ck_flexgen_18", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_spi7 = {
+	.gate_id = GATE_SPI7,
+	.hw.init = CLK_HW_INIT("ck_ker_spi7", "ck_flexgen_18", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_spi8 = {
+	.gate_id = GATE_SPI8,
+	.hw.init = CLK_HW_INIT("ck_ker_spi8", "ck_flexgen_37", &clk_stm32_gate_ops, 0),
+};
+
+/* Timers */
+static struct clk_stm32_gate ck_icn_p_tim2 = {
+	.gate_id = GATE_TIM2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim3 = {
+	.gate_id = GATE_TIM3,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim4 = {
+	.gate_id = GATE_TIM4,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim4", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim5 = {
+	.gate_id = GATE_TIM5,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim5", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim6 = {
+	.gate_id = GATE_TIM6,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim6", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim7 = {
+	.gate_id = GATE_TIM7,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim7", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim10 = {
+	.gate_id = GATE_TIM10,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim10", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim11 = {
+	.gate_id = GATE_TIM11,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim11", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim12 = {
+	.gate_id = GATE_TIM12,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim12", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim13 = {
+	.gate_id = GATE_TIM13,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim13", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim14 = {
+	.gate_id = GATE_TIM14,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim14", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim1 = {
+	.gate_id = GATE_TIM1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim1", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim8 = {
+	.gate_id = GATE_TIM8,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim8", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim15 = {
+	.gate_id = GATE_TIM15,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim15", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim16 = {
+	.gate_id = GATE_TIM16,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim16", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim17 = {
+	.gate_id = GATE_TIM17,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim17", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_tim20 = {
+	.gate_id = GATE_TIM20,
+	.hw.init = CLK_HW_INIT("ck_icn_p_tim20", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim2 = {
+	.gate_id = GATE_TIM2,
+	.hw.init = CLK_HW_INIT("ck_ker_tim2", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim3 = {
+	.gate_id = GATE_TIM3,
+	.hw.init = CLK_HW_INIT("ck_ker_tim3", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim4 = {
+	.gate_id = GATE_TIM4,
+	.hw.init = CLK_HW_INIT("ck_ker_tim4", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim5 = {
+	.gate_id = GATE_TIM5,
+	.hw.init = CLK_HW_INIT("ck_ker_tim5", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim6 = {
+	.gate_id = GATE_TIM6,
+	.hw.init = CLK_HW_INIT("ck_ker_tim6", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim7 = {
+	.gate_id = GATE_TIM7,
+	.hw.init = CLK_HW_INIT("ck_ker_tim7", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim10 = {
+	.gate_id = GATE_TIM10,
+	.hw.init = CLK_HW_INIT("ck_ker_tim10", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim11 = {
+	.gate_id = GATE_TIM11,
+	.hw.init = CLK_HW_INIT("ck_ker_tim11", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim12 = {
+	.gate_id = GATE_TIM12,
+	.hw.init = CLK_HW_INIT("ck_ker_tim12", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim13 = {
+	.gate_id = GATE_TIM13,
+	.hw.init = CLK_HW_INIT("ck_ker_tim13", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim14 = {
+	.gate_id = GATE_TIM14,
+	.hw.init = CLK_HW_INIT("ck_ker_tim14", "timg1_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim1 = {
+	.gate_id = GATE_TIM1,
+	.hw.init = CLK_HW_INIT("ck_ker_tim1", "timg2_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim8 = {
+	.gate_id = GATE_TIM8,
+	.hw.init = CLK_HW_INIT("ck_ker_tim8", "timg2_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim15 = {
+	.gate_id = GATE_TIM15,
+	.hw.init = CLK_HW_INIT("ck_ker_tim15", "timg2_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim16 = {
+	.gate_id = GATE_TIM16,
+	.hw.init = CLK_HW_INIT("ck_ker_tim16", "timg2_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim17 = {
+	.gate_id = GATE_TIM17,
+	.hw.init = CLK_HW_INIT("ck_ker_tim17", "timg2_ck", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_tim20 = {
+	.gate_id = GATE_TIM20,
+	.hw.init = CLK_HW_INIT("ck_ker_tim20", "timg2_ck", &clk_stm32_gate_ops, 0),
+};
+
+/* UART/USART */
+static struct clk_stm32_gate ck_icn_p_usart2 = {
+	.gate_id = GATE_USART2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_usart2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_usart3 = {
+	.gate_id = GATE_USART3,
+	.hw.init = CLK_HW_INIT("ck_icn_p_usart3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_uart4 = {
+	.gate_id = GATE_UART4,
+	.hw.init = CLK_HW_INIT("ck_icn_p_uart4", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_uart5 = {
+	.gate_id = GATE_UART5,
+	.hw.init = CLK_HW_INIT("ck_icn_p_uart5", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_usart1 = {
+	.gate_id = GATE_USART1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_usart1", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_usart6 = {
+	.gate_id = GATE_USART6,
+	.hw.init = CLK_HW_INIT("ck_icn_p_usart6", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_uart7 = {
+	.gate_id = GATE_UART7,
+	.hw.init = CLK_HW_INIT("ck_icn_p_uart7", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_uart8 = {
+	.gate_id = GATE_UART8,
+	.hw.init = CLK_HW_INIT("ck_icn_p_uart8", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_uart9 = {
+	.gate_id = GATE_UART9,
+	.hw.init = CLK_HW_INIT("ck_icn_p_uart9", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_usart2 = {
+	.gate_id = GATE_USART2,
+	.hw.init = CLK_HW_INIT("ck_ker_usart2", "ck_flexgen_08", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_uart4 = {
+	.gate_id = GATE_UART4,
+	.hw.init = CLK_HW_INIT("ck_ker_uart4", "ck_flexgen_08", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_usart3 = {
+	.gate_id = GATE_USART3,
+	.hw.init = CLK_HW_INIT("ck_ker_usart3", "ck_flexgen_09", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_uart5 = {
+	.gate_id = GATE_UART5,
+	.hw.init = CLK_HW_INIT("ck_ker_uart5", "ck_flexgen_09", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_usart1 = {
+	.gate_id = GATE_USART1,
+	.hw.init = CLK_HW_INIT("ck_ker_usart1", "ck_flexgen_19", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_usart6 = {
+	.gate_id = GATE_USART6,
+	.hw.init = CLK_HW_INIT("ck_ker_usart6", "ck_flexgen_20", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_uart7 = {
+	.gate_id = GATE_UART7,
+	.hw.init = CLK_HW_INIT("ck_ker_uart7", "ck_flexgen_21", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_uart8 = {
+	.gate_id = GATE_UART8,
+	.hw.init = CLK_HW_INIT("ck_ker_uart8", "ck_flexgen_21", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_uart9 = {
+	.gate_id = GATE_UART9,
+	.hw.init = CLK_HW_INIT("ck_ker_uart9", "ck_flexgen_22", &clk_stm32_gate_ops, 0),
+};
+
+/* USB2PHY1 */
+static struct clk_stm32_composite ck_ker_usb2phy1 = {
+	.gate_id = GATE_USB2PHY1,
+	.mux_id = MUX_USB2PHY1,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_usb2phy1", usb2phy1_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+/* USB2H */
+static struct clk_stm32_gate ck_icn_m_usb2ehci = {
+	.gate_id = GATE_USB2,
+	.hw.init = CLK_HW_INIT("ck_icn_m_usb2ehci", "ck_icn_hsl", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_m_usb2ohci = {
+	.gate_id = GATE_USB2,
+	.hw.init = CLK_HW_INIT("ck_icn_m_usb2ohci", "ck_icn_hsl", &clk_stm32_gate_ops, 0),
+};
+
+/* USB2PHY2 */
+static struct clk_stm32_composite ck_ker_usb2phy2_en = {
+	.gate_id = GATE_USB2PHY2,
+	.mux_id = MUX_USB2PHY2,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_usb2phy2_en", usb2phy2_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+/* USB3 PCIe COMBOPHY */
+static struct clk_stm32_gate ck_icn_p_usb3pciephy = {
+	.gate_id = GATE_USB3PCIEPHY,
+	.hw.init = CLK_HW_INIT("ck_icn_p_usb3pciephy", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_composite ck_ker_usb3pciephy = {
+	.gate_id = GATE_USB3PCIEPHY,
+	.mux_id = MUX_USB3PCIEPHY,
+	.div_id = NO_STM32_DIV,
+	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_usb3pciephy", usb3pciphy_src,
+					    &clk_stm32_composite_ops, 0),
+};
+
+/* USB3 DRD */
+static struct clk_stm32_gate ck_icn_m_usb3dr = {
+	.gate_id = GATE_USB3DR,
+	.hw.init = CLK_HW_INIT("ck_icn_m_usb3dr", "ck_icn_hsl", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_usb2phy2 = {
+	.gate_id = GATE_USB3DR,
+	.hw.init = CLK_HW_INIT("ck_ker_usb2phy2", "ck_flexgen_58", &clk_stm32_gate_ops, 0),
+};
+
+/* USBTC */
+static struct clk_stm32_gate ck_icn_p_usbtc = {
+	.gate_id = GATE_USBTC,
+	.hw.init = CLK_HW_INIT("ck_icn_p_usbtc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_ker_usbtc = {
+	.gate_id = GATE_USBTC,
+	.hw.init = CLK_HW_INIT("ck_ker_usbtc", "ck_flexgen_35", &clk_stm32_gate_ops, 0),
+};
+
+/* VDEC / VENC */
+static struct clk_stm32_gate ck_icn_p_vdec = {
+	.gate_id = GATE_VDEC,
+	.hw.init = CLK_HW_INIT("ck_icn_p_vdec", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_venc = {
+	.gate_id = GATE_VENC,
+	.hw.init = CLK_HW_INIT("ck_icn_p_venc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
+};
+
+/* VREF */
+static struct clk_stm32_gate ck_icn_p_vref = {
+	.gate_id = GATE_VREF,
+	.hw.init = CLK_HW_INIT("ck_icn_p_vref", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
+};
+
+/* WWDG */
+static struct clk_stm32_gate ck_icn_p_wwdg1 = {
+	.gate_id = GATE_WWDG1,
+	.hw.init = CLK_HW_INIT("ck_icn_p_wwdg1", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
+};
+
+static struct clk_stm32_gate ck_icn_p_wwdg2 = {
+	.gate_id = GATE_WWDG2,
+	.hw.init = CLK_HW_INIT("ck_icn_p_wwdg2", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
+};
+
+enum security_clk {
+	SECF_NONE,
+};
+
+static const struct clock_config stm32mp25_clock_cfg[] = {
+	STM32_GATE_CFG(CK_BUS_ETH1,		ck_icn_p_eth1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETH2,		ck_icn_p_eth2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_PCIE,		ck_icn_p_pcie,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETHSW,		ck_icn_p_ethsw,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ADC12,		ck_icn_p_adc12,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ADC3,		ck_icn_p_adc3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CCI,		ck_icn_p_cci,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CRC,		ck_icn_p_crc,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_MDF1,		ck_icn_p_mdf1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_OSPIIOM,		ck_icn_p_ospiiom,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_HASH,		ck_icn_p_hash,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CRYP1,		ck_icn_p_cryp1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CRYP2,		ck_icn_p_cryp2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ADF1,		ck_icn_p_adf1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI8,		ck_icn_p_spi8,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPUART1,		ck_icn_p_lpuart1,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C8,		ck_icn_p_i2c8,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM3,		ck_icn_p_lptim3,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM4,		ck_icn_p_lptim4,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM5,		ck_icn_p_lptim5,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IWDG5,		ck_icn_p_iwdg5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_WWDG2,		ck_icn_p_wwdg2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I3C4,		ck_icn_p_i3c4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SDMMC1,		ck_icn_m_sdmmc1,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SDMMC2,		ck_icn_m_sdmmc2,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SDMMC3,		ck_icn_m_sdmmc3,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USB2OHCI,		ck_icn_m_usb2ohci,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USB2EHCI,		ck_icn_m_usb2ehci,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USB3DR,		ck_icn_m_usb3dr,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM2,		ck_icn_p_tim2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM3,		ck_icn_p_tim3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM4,		ck_icn_p_tim4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM5,		ck_icn_p_tim5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM6,		ck_icn_p_tim6,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM7,		ck_icn_p_tim7,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM10,		ck_icn_p_tim10,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM11,		ck_icn_p_tim11,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM12,		ck_icn_p_tim12,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM13,		ck_icn_p_tim13,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM14,		ck_icn_p_tim14,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM1,		ck_icn_p_lptim1,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LPTIM2,		ck_icn_p_lptim2,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI2,		ck_icn_p_spi2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI3,		ck_icn_p_spi3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPDIFRX,		ck_icn_p_spdifrx,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USART2,		ck_icn_p_usart2,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USART3,		ck_icn_p_usart3,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART4,		ck_icn_p_uart4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART5,		ck_icn_p_uart5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C1,		ck_icn_p_i2c1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C2,		ck_icn_p_i2c2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C3,		ck_icn_p_i2c3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C4,		ck_icn_p_i2c4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C5,		ck_icn_p_i2c5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C6,		ck_icn_p_i2c6,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I2C7,		ck_icn_p_i2c7,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I3C1,		ck_icn_p_i3c1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I3C2,		ck_icn_p_i3c2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_I3C3,		ck_icn_p_i3c3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM1,		ck_icn_p_tim1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM8,		ck_icn_p_tim8,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM15,		ck_icn_p_tim15,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM16,		ck_icn_p_tim16,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM17,		ck_icn_p_tim17,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_TIM20,		ck_icn_p_tim20,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SAI1,		ck_icn_p_sai1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SAI2,		ck_icn_p_sai2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SAI3,		ck_icn_p_sai3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SAI4,		ck_icn_p_sai4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USART1,		ck_icn_p_usart1,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USART6,		ck_icn_p_usart6,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART7,		ck_icn_p_uart7,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART8,		ck_icn_p_uart8,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_UART9,		ck_icn_p_uart9,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_FDCAN,		ck_icn_p_fdcan,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI1,		ck_icn_p_spi1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI4,		ck_icn_p_spi4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI5,		ck_icn_p_spi5,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI6,		ck_icn_p_spi6,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_SPI7,		ck_icn_p_spi7,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IWDG2,		ck_icn_p_iwdg2,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IWDG3,		ck_icn_p_iwdg3,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IWDG4,		ck_icn_p_iwdg4,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_WWDG1,		ck_icn_p_wwdg1,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_VREF,		ck_icn_p_vref,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_HDP,		ck_icn_p_hdp,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_IS2M,		ck_icn_p_is2m,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_DSI,		ck_icn_p_dsi,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LTDC,		ck_icn_p_ltdc,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_CSI,		ck_icn_p_csi,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_DCMIPP,		ck_icn_p_dcmipp,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_LVDS,		ck_icn_p_lvds,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USBTC,		ck_icn_p_usbtc,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_USB3PCIEPHY,	ck_icn_p_usb3pciephy,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_VDEC,		ck_icn_p_vdec,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_VENC,		ck_icn_p_venc,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM2,		ck_ker_tim2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM3,		ck_ker_tim3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM4,		ck_ker_tim4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM5,		ck_ker_tim5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM6,		ck_ker_tim6,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM7,		ck_ker_tim7,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM10,		ck_ker_tim10,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM11,		ck_ker_tim11,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM12,		ck_ker_tim12,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM13,		ck_ker_tim13,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM14,		ck_ker_tim14,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM1,		ck_ker_tim1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM8,		ck_ker_tim8,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM15,		ck_ker_tim15,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM16,		ck_ker_tim16,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM17,		ck_ker_tim17,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_TIM20,		ck_ker_tim20,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM1,		ck_ker_lptim1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM2,		ck_ker_lptim2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USART2,		ck_ker_usart2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART4,		ck_ker_uart4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USART3,		ck_ker_usart3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART5,		ck_ker_uart5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI2,		ck_ker_spi2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI3,		ck_ker_spi3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPDIFRX,		ck_ker_spdifrx,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C1,		ck_ker_i2c1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C2,		ck_ker_i2c2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I3C1,		ck_ker_i3c1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I3C2,		ck_ker_i3c2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C3,		ck_ker_i2c3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C5,		ck_ker_i2c5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I3C3,		ck_ker_i3c3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C4,		ck_ker_i2c4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C6,		ck_ker_i2c6,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C7,		ck_ker_i2c7,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI1,		ck_ker_spi1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI4,		ck_ker_spi4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI5,		ck_ker_spi5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI6,		ck_ker_spi6,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI7,		ck_ker_spi7,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USART1,		ck_ker_usart1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USART6,		ck_ker_usart6,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART7,		ck_ker_uart7,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART8,		ck_ker_uart8,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_UART9,		ck_ker_uart9,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_MDF1,		ck_ker_mdf1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SAI1,		ck_ker_sai1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SAI2,		ck_ker_sai2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SAI3,		ck_ker_sai3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SAI4,		ck_ker_sai4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_FDCAN,		ck_ker_fdcan,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_CSI,		ck_ker_csi,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_CSITXESC,		ck_ker_csitxesc,	SECF_NONE),
+	STM32_GATE_CFG(CK_KER_CSIPHY,		ck_ker_csiphy,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USBTC,		ck_ker_usbtc,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I3C4,		ck_ker_i3c4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SPI8,		ck_ker_spi8,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_I2C8,		ck_ker_i2c8,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPUART1,		ck_ker_lpuart1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM3,		ck_ker_lptim3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM4,		ck_ker_lptim4,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LPTIM5,		ck_ker_lptim5,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ADF1,		ck_ker_adf1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SDMMC1,		ck_ker_sdmmc1,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SDMMC2,		ck_ker_sdmmc2,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_SDMMC3,		ck_ker_sdmmc3,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETH1,		ck_ker_eth1,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH1_STP,		ck_ker_eth1stp,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETHSW,		ck_ker_ethsw,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETH2,		ck_ker_eth2,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH2_STP,		ck_ker_eth2stp,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETH1PTP,		ck_ker_eth1ptp,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETH2PTP,		ck_ker_eth2ptp,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_GPU,		ck_icn_m_gpu,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_GPU,		ck_ker_gpu,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_ETHSWREF,		ck_ker_ethswref,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETHSWACMCFG,	ck_icn_p_ethsw_acm_cfg,	SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETHSWACMMSG, ck_icn_p_ethsw_acm_msg,	SECF_NONE),
+	STM32_GATE_CFG(CK_ETH1_MAC,		ck_ker_eth1mac,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH1_TX,		ck_ker_eth1tx,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH1_RX,		ck_ker_eth1rx,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH2_MAC,		ck_ker_eth2mac,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH2_TX,		ck_ker_eth2tx,		SECF_NONE),
+	STM32_GATE_CFG(CK_ETH2_RX,		ck_ker_eth2rx,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_MCO1,		ck_mco1,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_MCO2,		ck_mco2,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_ADC12,	ck_ker_adc12,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_ADC3,	ck_ker_adc3,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_USB2PHY1,	ck_ker_usb2phy1,	SECF_NONE),
+	STM32_GATE_CFG(CK_KER_USB2PHY2,		ck_ker_usb2phy2,	SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_USB2PHY2EN,	ck_ker_usb2phy2_en,	SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_USB3PCIEPHY,	ck_ker_usb3pciephy,	SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_DSIBLANE,	clk_lanebyte,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_DSIPHY,	clk_phy_dsi,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_LVDSPHY,	ck_ker_lvdsphy,		SECF_NONE),
+	STM32_COMPOSITE_CFG(CK_KER_DTS,		ck_ker_dts,		SECF_NONE),
+	STM32_GATE_CFG(CK_KER_LTDC,		ck_ker_ltdc,		SECF_NONE),
+};
+
+#define RESET_MP25(id, _offset, _bit_idx, _set_clr)	\
+	[id] = &(struct stm32_reset_cfg){		\
+		.offset		= (_offset),		\
+		.bit_idx	= (_bit_idx),		\
+		.set_clr	= (_set_clr),		\
+	}
+
+static const struct stm32_reset_cfg *stm32mp25_reset_cfg[STM32MP25_LAST_RESET] = {
+	RESET_MP25(TIM1_R,		RCC_TIM1CFGR,		0,	0),
+	RESET_MP25(TIM2_R,		RCC_TIM2CFGR,		0,	0),
+	RESET_MP25(TIM3_R,		RCC_TIM3CFGR,		0,	0),
+	RESET_MP25(TIM4_R,		RCC_TIM4CFGR,		0,	0),
+	RESET_MP25(TIM5_R,		RCC_TIM5CFGR,		0,	0),
+	RESET_MP25(TIM6_R,		RCC_TIM6CFGR,		0,	0),
+	RESET_MP25(TIM7_R,		RCC_TIM7CFGR,		0,	0),
+	RESET_MP25(TIM8_R,		RCC_TIM8CFGR,		0,	0),
+	RESET_MP25(TIM10_R,		RCC_TIM10CFGR,		0,	0),
+	RESET_MP25(TIM11_R,		RCC_TIM11CFGR,		0,	0),
+	RESET_MP25(TIM12_R,		RCC_TIM12CFGR,		0,	0),
+	RESET_MP25(TIM13_R,		RCC_TIM13CFGR,		0,	0),
+	RESET_MP25(TIM14_R,		RCC_TIM14CFGR,		0,	0),
+	RESET_MP25(TIM15_R,		RCC_TIM15CFGR,		0,	0),
+	RESET_MP25(TIM16_R,		RCC_TIM16CFGR,		0,	0),
+	RESET_MP25(TIM17_R,		RCC_TIM17CFGR,		0,	0),
+	RESET_MP25(TIM20_R,		RCC_TIM20CFGR,		0,	0),
+	RESET_MP25(LPTIM1_R,		RCC_LPTIM1CFGR,		0,	0),
+	RESET_MP25(LPTIM2_R,		RCC_LPTIM2CFGR,		0,	0),
+	RESET_MP25(LPTIM3_R,		RCC_LPTIM3CFGR,		0,	0),
+	RESET_MP25(LPTIM4_R,		RCC_LPTIM4CFGR,		0,	0),
+	RESET_MP25(LPTIM5_R,		RCC_LPTIM5CFGR,		0,	0),
+	RESET_MP25(SPI1_R,		RCC_SPI1CFGR,		0,	0),
+	RESET_MP25(SPI2_R,		RCC_SPI2CFGR,		0,	0),
+	RESET_MP25(SPI3_R,		RCC_SPI3CFGR,		0,	0),
+	RESET_MP25(SPI4_R,		RCC_SPI4CFGR,		0,	0),
+	RESET_MP25(SPI5_R,		RCC_SPI5CFGR,		0,	0),
+	RESET_MP25(SPI6_R,		RCC_SPI6CFGR,		0,	0),
+	RESET_MP25(SPI7_R,		RCC_SPI7CFGR,		0,	0),
+	RESET_MP25(SPI8_R,		RCC_SPI8CFGR,		0,	0),
+	RESET_MP25(SPDIFRX_R,		RCC_SPDIFRXCFGR,	0,	0),
+	RESET_MP25(USART1_R,		RCC_USART1CFGR,		0,	0),
+	RESET_MP25(USART2_R,		RCC_USART2CFGR,		0,	0),
+	RESET_MP25(USART3_R,		RCC_USART3CFGR,		0,	0),
+	RESET_MP25(UART4_R,		RCC_UART4CFGR,		0,	0),
+	RESET_MP25(UART5_R,		RCC_UART5CFGR,		0,	0),
+	RESET_MP25(USART6_R,		RCC_USART6CFGR,		0,	0),
+	RESET_MP25(UART7_R,		RCC_UART7CFGR,		0,	0),
+	RESET_MP25(UART8_R,		RCC_UART8CFGR,		0,	0),
+	RESET_MP25(UART9_R,		RCC_UART9CFGR,		0,	0),
+	RESET_MP25(LPUART1_R,		RCC_LPUART1CFGR,	0,	0),
+	RESET_MP25(IS2M_R,		RCC_IS2MCFGR,		0,	0),
+	RESET_MP25(I2C1_R,		RCC_I2C1CFGR,		0,	0),
+	RESET_MP25(I2C2_R,		RCC_I2C2CFGR,		0,	0),
+	RESET_MP25(I2C3_R,		RCC_I2C3CFGR,		0,	0),
+	RESET_MP25(I2C4_R,		RCC_I2C4CFGR,		0,	0),
+	RESET_MP25(I2C5_R,		RCC_I2C5CFGR,		0,	0),
+	RESET_MP25(I2C6_R,		RCC_I2C6CFGR,		0,	0),
+	RESET_MP25(I2C7_R,		RCC_I2C7CFGR,		0,	0),
+	RESET_MP25(I2C8_R,		RCC_I2C8CFGR,		0,	0),
+	RESET_MP25(SAI1_R,		RCC_SAI1CFGR,		0,	0),
+	RESET_MP25(SAI2_R,		RCC_SAI2CFGR,		0,	0),
+	RESET_MP25(SAI3_R,		RCC_SAI3CFGR,		0,	0),
+	RESET_MP25(SAI4_R,		RCC_SAI4CFGR,		0,	0),
+	RESET_MP25(MDF1_R,		RCC_MDF1CFGR,		0,	0),
+	RESET_MP25(MDF2_R,		RCC_ADF1CFGR,		0,	0),
+	RESET_MP25(FDCAN_R,		RCC_FDCANCFGR,		0,	0),
+	RESET_MP25(HDP_R,		RCC_HDPCFGR,		0,	0),
+	RESET_MP25(ADC12_R,		RCC_ADC12CFGR,		0,	0),
+	RESET_MP25(ADC3_R,		RCC_ADC3CFGR,		0,	0),
+	RESET_MP25(ETH1_R,		RCC_ETH1CFGR,		0,	0),
+	RESET_MP25(ETH2_R,		RCC_ETH2CFGR,		0,	0),
+	RESET_MP25(USB2_R,		RCC_USB2CFGR,		0,	0),
+	RESET_MP25(USB2PHY1_R,		RCC_USB2PHY1CFGR,	0,	0),
+	RESET_MP25(USB2PHY2_R,		RCC_USB2PHY2CFGR,	0,	0),
+	RESET_MP25(USB3DR_R,		RCC_USB3DRCFGR,		0,	0),
+	RESET_MP25(USB3PCIEPHY_R,	RCC_USB3PCIEPHYCFGR,	0,	0),
+	RESET_MP25(USBTC_R,		RCC_USBTCCFGR,		0,	0),
+	RESET_MP25(ETHSW_R,		RCC_ETHSWCFGR,		0,	0),
+	RESET_MP25(SDMMC1_R,		RCC_SDMMC1CFGR,		0,	0),
+	RESET_MP25(SDMMC1DLL_R,		RCC_SDMMC1CFGR,		16,	0),
+	RESET_MP25(SDMMC2_R,		RCC_SDMMC2CFGR,		0,	0),
+	RESET_MP25(SDMMC2DLL_R,		RCC_SDMMC2CFGR,		16,	0),
+	RESET_MP25(SDMMC3_R,		RCC_SDMMC3CFGR,		0,	0),
+	RESET_MP25(SDMMC3DLL_R,		RCC_SDMMC3CFGR,		16,	0),
+	RESET_MP25(GPU_R,		RCC_GPUCFGR,		0,	0),
+	RESET_MP25(LTDC_R,		RCC_LTDCCFGR,		0,	0),
+	RESET_MP25(DSI_R,		RCC_DSICFGR,		0,	0),
+	RESET_MP25(LVDS_R,		RCC_LVDSCFGR,		0,	0),
+	RESET_MP25(CSI_R,		RCC_CSICFGR,		0,	0),
+	RESET_MP25(DCMIPP_R,		RCC_DCMIPPCFGR,		0,	0),
+	RESET_MP25(CCI_R,		RCC_CCICFGR,		0,	0),
+	RESET_MP25(VDEC_R,		RCC_VDECCFGR,		0,	0),
+	RESET_MP25(VENC_R,		RCC_VENCCFGR,		0,	0),
+	RESET_MP25(WWDG1_R,		RCC_WWDG1CFGR,		0,	0),
+	RESET_MP25(WWDG2_R,		RCC_WWDG2CFGR,		0,	0),
+	RESET_MP25(VREF_R,		RCC_VREFCFGR,		0,	0),
+	RESET_MP25(DTS_R,		RCC_DTSCFGR,		0,	0),
+	RESET_MP25(CRC_R,		RCC_CRCCFGR,		0,	0),
+	RESET_MP25(SERC_R,		RCC_SERCCFGR,		0,	0),
+	RESET_MP25(OSPIIOM_R,		RCC_OSPIIOMCFGR,	0,	0),
+	RESET_MP25(I3C1_R,		RCC_I3C1CFGR,		0,	0),
+	RESET_MP25(I3C2_R,		RCC_I3C2CFGR,		0,	0),
+	RESET_MP25(I3C3_R,		RCC_I3C3CFGR,		0,	0),
+	RESET_MP25(I3C4_R,		RCC_I3C4CFGR,		0,	0),
+	RESET_MP25(IWDG2_KER_R,		RCC_IWDGC1CFGSETR,	18,	1),
+	RESET_MP25(IWDG4_KER_R,		RCC_IWDGC2CFGSETR,	18,	1),
+	RESET_MP25(RNG_R,		RCC_RNGCFGR,		0,	0),
+	RESET_MP25(PKA_R,		RCC_PKACFGR,		0,	0),
+	RESET_MP25(SAES_R,		RCC_SAESCFGR,		0,	0),
+	RESET_MP25(HASH_R,		RCC_HASHCFGR,		0,	0),
+	RESET_MP25(CRYP1_R,		RCC_CRYP1CFGR,		0,	0),
+	RESET_MP25(CRYP2_R,		RCC_CRYP2CFGR,		0,	0),
+	RESET_MP25(PCIE_R,		RCC_PCIECFGR,		0,	0),
+};
+
+static u16 stm32mp25_cpt_gate[GATE_NB];
+
+static struct clk_stm32_clock_data stm32mp25_clock_data = {
+	.gate_cpt	= stm32mp25_cpt_gate,
+	.gates		= stm32mp25_gates,
+	.muxes		= stm32mp25_muxes,
+};
+
+static struct clk_stm32_reset_data stm32mp25_reset_data = {
+	.reset_lines	= stm32mp25_reset_cfg,
+	.nr_lines	= ARRAY_SIZE(stm32mp25_reset_cfg),
+};
+
+static const struct stm32_rcc_match_data stm32mp25_data = {
+	.tab_clocks	= stm32mp25_clock_cfg,
+	.num_clocks	= ARRAY_SIZE(stm32mp25_clock_cfg),
+	.maxbinding	= STM32MP25_LAST_CLK,
+	.clock_data	= &stm32mp25_clock_data,
+	.reset_data	= &stm32mp25_reset_data,
+};
+
+static const struct of_device_id stm32mp25_match_data[] = {
+	{
+		.compatible = "st,stm32mp25-rcc",
+		.data = &stm32mp25_data,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, stm32mp25_match_data);
+
+static int get_clock_deps(struct device *dev)
+{
+	static const char * const clock_deps_name[] = {
+		"hsi", "hse", "msi", "lsi", "lse",
+	};
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(clock_deps_name); i++) {
+		struct clk *clk;
+
+		clk = of_clk_get_by_name(dev_of_node(dev), clock_deps_name[i]);
+		if (IS_ERR(clk))
+			return PTR_ERR(clk);
+
+		clk_put(clk);
+	}
+
+	return 0;
+}
+
+static int stm32mp25_rcc_clocks_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	void __iomem *base;
+	int ret;
+
+	ret = get_clock_deps(dev);
+	if (ret)
+		return ret;
+
+	base = devm_of_iomap(dev, dev->of_node, 0, NULL);
+	if (WARN_ON(IS_ERR(base)))
+		return PTR_ERR(base);
+
+	return stm32_rcc_init(dev, stm32mp25_match_data, base);
+}
+
+static int stm32mp25_rcc_clocks_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *child, *np = dev_of_node(dev);
+
+	for_each_available_child_of_node(np, child)
+		of_clk_del_provider(child);
+
+	return 0;
+}
+
+static struct platform_driver stm32mp25_rcc_clocks_driver = {
+	.driver	= {
+		.name = "stm32mp25_rcc",
+		.of_match_table = stm32mp25_match_data,
+	},
+	.probe = stm32mp25_rcc_clocks_probe,
+	.remove = stm32mp25_rcc_clocks_remove,
+};
+
+static int __init stm32mp25_clocks_init(void)
+{
+	return platform_driver_register(&stm32mp25_rcc_clocks_driver);
+}
+
+core_initcall(stm32mp25_clocks_init);
diff --git a/drivers/clk/stm32/reset-stm32.c b/drivers/clk/stm32/reset-stm32.c
index 14c2ee1eebee..5a8f525842ce 100644
--- a/drivers/clk/stm32/reset-stm32.c
+++ b/drivers/clk/stm32/reset-stm32.c
@@ -19,6 +19,7 @@ struct stm32_reset_data {
 	struct reset_controller_dev	rcdev;
 	void __iomem			*membase;
 	u32				clear_offset;
+	const struct stm32_reset_cfg	**reset_lines;
 };
 
 static inline struct stm32_reset_data *
@@ -27,22 +28,46 @@ to_stm32_reset_data(struct reset_controller_dev *rcdev)
 	return container_of(rcdev, struct stm32_reset_data, rcdev);
 }
 
+static const struct stm32_reset_cfg *stm32_get_reset_line(struct reset_controller_dev *rcdev,
+							  unsigned long id,
+							  struct stm32_reset_cfg *line)
+{
+	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
+
+	if (!data->reset_lines) {
+		int reg_width = sizeof(u32);
+		int bank = id / (reg_width * BITS_PER_BYTE);
+		int offset = id % (reg_width * BITS_PER_BYTE);
+
+		line->offset = bank * reg_width;
+		line->bit_idx = offset;
+		line->set_clr = (data->clear_offset ? true : false);
+
+		return line;
+	}
+
+	return data->reset_lines[id];
+}
+
 static int stm32_reset_update(struct reset_controller_dev *rcdev,
 			      unsigned long id, bool assert)
 {
 	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
+	struct stm32_reset_cfg line_reset;
+	const struct stm32_reset_cfg *ptr_line;
 
-	if (data->clear_offset) {
+	ptr_line = stm32_get_reset_line(rcdev, id, &line_reset);
+	if (!ptr_line)
+		return -EPERM;
+
+	if (ptr_line->set_clr) {
 		void __iomem *addr;
 
-		addr = data->membase + (bank * reg_width);
+		addr = data->membase + ptr_line->offset;
 		if (!assert)
 			addr += data->clear_offset;
 
-		writel(BIT(offset), addr);
+		writel(BIT(ptr_line->bit_idx), addr);
 
 	} else {
 		unsigned long flags;
@@ -50,14 +75,14 @@ static int stm32_reset_update(struct reset_controller_dev *rcdev,
 
 		spin_lock_irqsave(&data->lock, flags);
 
-		reg = readl(data->membase + (bank * reg_width));
+		reg = readl(data->membase + ptr_line->offset);
 
 		if (assert)
-			reg |= BIT(offset);
+			reg |= BIT(ptr_line->bit_idx);
 		else
-			reg &= ~BIT(offset);
+			reg &= ~BIT(ptr_line->bit_idx);
 
-		writel(reg, data->membase + (bank * reg_width));
+		writel(reg, data->membase + ptr_line->offset);
 
 		spin_unlock_irqrestore(&data->lock, flags);
 	}
@@ -81,14 +106,17 @@ static int stm32_reset_status(struct reset_controller_dev *rcdev,
 			      unsigned long id)
 {
 	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
+	struct stm32_reset_cfg line_reset;
+	const struct stm32_reset_cfg *ptr_line;
 	u32 reg;
 
-	reg = readl(data->membase + (bank * reg_width));
+	ptr_line = stm32_get_reset_line(rcdev, id, &line_reset);
+	if (!ptr_line)
+		return -EPERM;
+
+	reg = readl(data->membase + ptr_line->offset);
 
-	return !!(reg & BIT(offset));
+	return !!(reg & BIT(ptr_line->bit_idx));
 }
 
 static const struct reset_control_ops stm32_reset_ops = {
@@ -113,6 +141,7 @@ int stm32_rcc_reset_init(struct device *dev, struct clk_stm32_reset_data *data,
 	reset_data->rcdev.ops = &stm32_reset_ops;
 	reset_data->rcdev.of_node = dev_of_node(dev);
 	reset_data->rcdev.nr_resets = data->nr_lines;
+	reset_data->reset_lines = data->reset_lines;
 	reset_data->clear_offset = data->clear_offset;
 
 	return reset_controller_register(&reset_data->rcdev);
diff --git a/drivers/clk/stm32/reset-stm32.h b/drivers/clk/stm32/reset-stm32.h
index 8cf1cc9be480..f79cad21dfd6 100644
--- a/drivers/clk/stm32/reset-stm32.h
+++ b/drivers/clk/stm32/reset-stm32.h
@@ -4,8 +4,15 @@
  * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
  */
 
+struct stm32_reset_cfg {
+	u16 offset;
+	u8 bit_idx;
+	bool set_clr;
+};
+
 struct clk_stm32_reset_data {
 	const struct reset_control_ops *ops;
+	const struct stm32_reset_cfg **reset_lines;
 	unsigned int nr_lines;
 	u32 clear_offset;
 };
diff --git a/drivers/clk/stm32/stm32mp25_rcc.h b/drivers/clk/stm32/stm32mp25_rcc.h
new file mode 100644
index 000000000000..6ba13cc2ae16
--- /dev/null
+++ b/drivers/clk/stm32/stm32mp25_rcc.h
@@ -0,0 +1,712 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
+ * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
+ */
+
+#ifndef STM32MP25_RCC_H
+#define STM32MP25_RCC_H
+
+#define RCC_SECCFGR0				0x0
+#define RCC_SECCFGR1				0x4
+#define RCC_SECCFGR2				0x8
+#define RCC_SECCFGR3				0xC
+#define RCC_PRIVCFGR0				0x10
+#define RCC_PRIVCFGR1				0x14
+#define RCC_PRIVCFGR2				0x18
+#define RCC_PRIVCFGR3				0x1C
+#define RCC_RCFGLOCKR0				0x20
+#define RCC_RCFGLOCKR1				0x24
+#define RCC_RCFGLOCKR2				0x28
+#define RCC_RCFGLOCKR3				0x2C
+#define RCC_R0CIDCFGR				0x30
+#define RCC_R0SEMCR				0x34
+#define RCC_R1CIDCFGR				0x38
+#define RCC_R1SEMCR				0x3C
+#define RCC_R2CIDCFGR				0x40
+#define RCC_R2SEMCR				0x44
+#define RCC_R3CIDCFGR				0x48
+#define RCC_R3SEMCR				0x4C
+#define RCC_R4CIDCFGR				0x50
+#define RCC_R4SEMCR				0x54
+#define RCC_R5CIDCFGR				0x58
+#define RCC_R5SEMCR				0x5C
+#define RCC_R6CIDCFGR				0x60
+#define RCC_R6SEMCR				0x64
+#define RCC_R7CIDCFGR				0x68
+#define RCC_R7SEMCR				0x6C
+#define RCC_R8CIDCFGR				0x70
+#define RCC_R8SEMCR				0x74
+#define RCC_R9CIDCFGR				0x78
+#define RCC_R9SEMCR				0x7C
+#define RCC_R10CIDCFGR				0x80
+#define RCC_R10SEMCR				0x84
+#define RCC_R11CIDCFGR				0x88
+#define RCC_R11SEMCR				0x8C
+#define RCC_R12CIDCFGR				0x90
+#define RCC_R12SEMCR				0x94
+#define RCC_R13CIDCFGR				0x98
+#define RCC_R13SEMCR				0x9C
+#define RCC_R14CIDCFGR				0xA0
+#define RCC_R14SEMCR				0xA4
+#define RCC_R15CIDCFGR				0xA8
+#define RCC_R15SEMCR				0xAC
+#define RCC_R16CIDCFGR				0xB0
+#define RCC_R16SEMCR				0xB4
+#define RCC_R17CIDCFGR				0xB8
+#define RCC_R17SEMCR				0xBC
+#define RCC_R18CIDCFGR				0xC0
+#define RCC_R18SEMCR				0xC4
+#define RCC_R19CIDCFGR				0xC8
+#define RCC_R19SEMCR				0xCC
+#define RCC_R20CIDCFGR				0xD0
+#define RCC_R20SEMCR				0xD4
+#define RCC_R21CIDCFGR				0xD8
+#define RCC_R21SEMCR				0xDC
+#define RCC_R22CIDCFGR				0xE0
+#define RCC_R22SEMCR				0xE4
+#define RCC_R23CIDCFGR				0xE8
+#define RCC_R23SEMCR				0xEC
+#define RCC_R24CIDCFGR				0xF0
+#define RCC_R24SEMCR				0xF4
+#define RCC_R25CIDCFGR				0xF8
+#define RCC_R25SEMCR				0xFC
+#define RCC_R26CIDCFGR				0x100
+#define RCC_R26SEMCR				0x104
+#define RCC_R27CIDCFGR				0x108
+#define RCC_R27SEMCR				0x10C
+#define RCC_R28CIDCFGR				0x110
+#define RCC_R28SEMCR				0x114
+#define RCC_R29CIDCFGR				0x118
+#define RCC_R29SEMCR				0x11C
+#define RCC_R30CIDCFGR				0x120
+#define RCC_R30SEMCR				0x124
+#define RCC_R31CIDCFGR				0x128
+#define RCC_R31SEMCR				0x12C
+#define RCC_R32CIDCFGR				0x130
+#define RCC_R32SEMCR				0x134
+#define RCC_R33CIDCFGR				0x138
+#define RCC_R33SEMCR				0x13C
+#define RCC_R34CIDCFGR				0x140
+#define RCC_R34SEMCR				0x144
+#define RCC_R35CIDCFGR				0x148
+#define RCC_R35SEMCR				0x14C
+#define RCC_R36CIDCFGR				0x150
+#define RCC_R36SEMCR				0x154
+#define RCC_R37CIDCFGR				0x158
+#define RCC_R37SEMCR				0x15C
+#define RCC_R38CIDCFGR				0x160
+#define RCC_R38SEMCR				0x164
+#define RCC_R39CIDCFGR				0x168
+#define RCC_R39SEMCR				0x16C
+#define RCC_R40CIDCFGR				0x170
+#define RCC_R40SEMCR				0x174
+#define RCC_R41CIDCFGR				0x178
+#define RCC_R41SEMCR				0x17C
+#define RCC_R42CIDCFGR				0x180
+#define RCC_R42SEMCR				0x184
+#define RCC_R43CIDCFGR				0x188
+#define RCC_R43SEMCR				0x18C
+#define RCC_R44CIDCFGR				0x190
+#define RCC_R44SEMCR				0x194
+#define RCC_R45CIDCFGR				0x198
+#define RCC_R45SEMCR				0x19C
+#define RCC_R46CIDCFGR				0x1A0
+#define RCC_R46SEMCR				0x1A4
+#define RCC_R47CIDCFGR				0x1A8
+#define RCC_R47SEMCR				0x1AC
+#define RCC_R48CIDCFGR				0x1B0
+#define RCC_R48SEMCR				0x1B4
+#define RCC_R49CIDCFGR				0x1B8
+#define RCC_R49SEMCR				0x1BC
+#define RCC_R50CIDCFGR				0x1C0
+#define RCC_R50SEMCR				0x1C4
+#define RCC_R51CIDCFGR				0x1C8
+#define RCC_R51SEMCR				0x1CC
+#define RCC_R52CIDCFGR				0x1D0
+#define RCC_R52SEMCR				0x1D4
+#define RCC_R53CIDCFGR				0x1D8
+#define RCC_R53SEMCR				0x1DC
+#define RCC_R54CIDCFGR				0x1E0
+#define RCC_R54SEMCR				0x1E4
+#define RCC_R55CIDCFGR				0x1E8
+#define RCC_R55SEMCR				0x1EC
+#define RCC_R56CIDCFGR				0x1F0
+#define RCC_R56SEMCR				0x1F4
+#define RCC_R57CIDCFGR				0x1F8
+#define RCC_R57SEMCR				0x1FC
+#define RCC_R58CIDCFGR				0x200
+#define RCC_R58SEMCR				0x204
+#define RCC_R59CIDCFGR				0x208
+#define RCC_R59SEMCR				0x20C
+#define RCC_R60CIDCFGR				0x210
+#define RCC_R60SEMCR				0x214
+#define RCC_R61CIDCFGR				0x218
+#define RCC_R61SEMCR				0x21C
+#define RCC_R62CIDCFGR				0x220
+#define RCC_R62SEMCR				0x224
+#define RCC_R63CIDCFGR				0x228
+#define RCC_R63SEMCR				0x22C
+#define RCC_R64CIDCFGR				0x230
+#define RCC_R64SEMCR				0x234
+#define RCC_R65CIDCFGR				0x238
+#define RCC_R65SEMCR				0x23C
+#define RCC_R66CIDCFGR				0x240
+#define RCC_R66SEMCR				0x244
+#define RCC_R67CIDCFGR				0x248
+#define RCC_R67SEMCR				0x24C
+#define RCC_R68CIDCFGR				0x250
+#define RCC_R68SEMCR				0x254
+#define RCC_R69CIDCFGR				0x258
+#define RCC_R69SEMCR				0x25C
+#define RCC_R70CIDCFGR				0x260
+#define RCC_R70SEMCR				0x264
+#define RCC_R71CIDCFGR				0x268
+#define RCC_R71SEMCR				0x26C
+#define RCC_R72CIDCFGR				0x270
+#define RCC_R72SEMCR				0x274
+#define RCC_R73CIDCFGR				0x278
+#define RCC_R73SEMCR				0x27C
+#define RCC_R74CIDCFGR				0x280
+#define RCC_R74SEMCR				0x284
+#define RCC_R75CIDCFGR				0x288
+#define RCC_R75SEMCR				0x28C
+#define RCC_R76CIDCFGR				0x290
+#define RCC_R76SEMCR				0x294
+#define RCC_R77CIDCFGR				0x298
+#define RCC_R77SEMCR				0x29C
+#define RCC_R78CIDCFGR				0x2A0
+#define RCC_R78SEMCR				0x2A4
+#define RCC_R79CIDCFGR				0x2A8
+#define RCC_R79SEMCR				0x2AC
+#define RCC_R80CIDCFGR				0x2B0
+#define RCC_R80SEMCR				0x2B4
+#define RCC_R81CIDCFGR				0x2B8
+#define RCC_R81SEMCR				0x2BC
+#define RCC_R82CIDCFGR				0x2C0
+#define RCC_R82SEMCR				0x2C4
+#define RCC_R83CIDCFGR				0x2C8
+#define RCC_R83SEMCR				0x2CC
+#define RCC_R84CIDCFGR				0x2D0
+#define RCC_R84SEMCR				0x2D4
+#define RCC_R85CIDCFGR				0x2D8
+#define RCC_R85SEMCR				0x2DC
+#define RCC_R86CIDCFGR				0x2E0
+#define RCC_R86SEMCR				0x2E4
+#define RCC_R87CIDCFGR				0x2E8
+#define RCC_R87SEMCR				0x2EC
+#define RCC_R88CIDCFGR				0x2F0
+#define RCC_R88SEMCR				0x2F4
+#define RCC_R89CIDCFGR				0x2F8
+#define RCC_R89SEMCR				0x2FC
+#define RCC_R90CIDCFGR				0x300
+#define RCC_R90SEMCR				0x304
+#define RCC_R91CIDCFGR				0x308
+#define RCC_R91SEMCR				0x30C
+#define RCC_R92CIDCFGR				0x310
+#define RCC_R92SEMCR				0x314
+#define RCC_R93CIDCFGR				0x318
+#define RCC_R93SEMCR				0x31C
+#define RCC_R94CIDCFGR				0x320
+#define RCC_R94SEMCR				0x324
+#define RCC_R95CIDCFGR				0x328
+#define RCC_R95SEMCR				0x32C
+#define RCC_R96CIDCFGR				0x330
+#define RCC_R96SEMCR				0x334
+#define RCC_R97CIDCFGR				0x338
+#define RCC_R97SEMCR				0x33C
+#define RCC_R98CIDCFGR				0x340
+#define RCC_R98SEMCR				0x344
+#define RCC_R99CIDCFGR				0x348
+#define RCC_R99SEMCR				0x34C
+#define RCC_R100CIDCFGR				0x350
+#define RCC_R100SEMCR				0x354
+#define RCC_R101CIDCFGR				0x358
+#define RCC_R101SEMCR				0x35C
+#define RCC_R102CIDCFGR				0x360
+#define RCC_R102SEMCR				0x364
+#define RCC_R103CIDCFGR				0x368
+#define RCC_R103SEMCR				0x36C
+#define RCC_R104CIDCFGR				0x370
+#define RCC_R104SEMCR				0x374
+#define RCC_R105CIDCFGR				0x378
+#define RCC_R105SEMCR				0x37C
+#define RCC_R106CIDCFGR				0x380
+#define RCC_R106SEMCR				0x384
+#define RCC_R107CIDCFGR				0x388
+#define RCC_R107SEMCR				0x38C
+#define RCC_R108CIDCFGR				0x390
+#define RCC_R108SEMCR				0x394
+#define RCC_R109CIDCFGR				0x398
+#define RCC_R109SEMCR				0x39C
+#define RCC_R110CIDCFGR				0x3A0
+#define RCC_R110SEMCR				0x3A4
+#define RCC_R111CIDCFGR				0x3A8
+#define RCC_R111SEMCR				0x3AC
+#define RCC_R112CIDCFGR				0x3B0
+#define RCC_R112SEMCR				0x3B4
+#define RCC_R113CIDCFGR				0x3B8
+#define RCC_R113SEMCR				0x3BC
+#define RCC_GRSTCSETR				0x400
+#define RCC_C1RSTCSETR				0x404
+#define RCC_C1P1RSTCSETR			0x408
+#define RCC_C2RSTCSETR				0x40C
+#define RCC_HWRSTSCLRR				0x410
+#define RCC_C1HWRSTSCLRR			0x414
+#define RCC_C2HWRSTSCLRR			0x418
+#define RCC_C1BOOTRSTSSETR			0x41C
+#define RCC_C1BOOTRSTSCLRR			0x420
+#define RCC_C2BOOTRSTSSETR			0x424
+#define RCC_C2BOOTRSTSCLRR			0x428
+#define RCC_C1SREQSETR				0x42C
+#define RCC_C1SREQCLRR				0x430
+#define RCC_CPUBOOTCR				0x434
+#define RCC_STBYBOOTCR				0x438
+#define RCC_LEGBOOTCR				0x43C
+#define RCC_BDCR				0x440
+#define RCC_D3DCR				0x444
+#define RCC_D3DSR				0x448
+#define RCC_RDCR				0x44C
+#define RCC_C1MSRDCR				0x450
+#define RCC_PWRLPDLYCR				0x454
+#define RCC_C1CIESETR				0x458
+#define RCC_C1CIFCLRR				0x45C
+#define RCC_C2CIESETR				0x460
+#define RCC_C2CIFCLRR				0x464
+#define RCC_IWDGC1FZSETR			0x468
+#define RCC_IWDGC1FZCLRR			0x46C
+#define RCC_IWDGC1CFGSETR			0x470
+#define RCC_IWDGC1CFGCLRR			0x474
+#define RCC_IWDGC2FZSETR			0x478
+#define RCC_IWDGC2FZCLRR			0x47C
+#define RCC_IWDGC2CFGSETR			0x480
+#define RCC_IWDGC2CFGCLRR			0x484
+#define RCC_IWDGC3CFGSETR			0x488
+#define RCC_IWDGC3CFGCLRR			0x48C
+#define RCC_C3CFGR				0x490
+#define RCC_MCO1CFGR				0x494
+#define RCC_MCO2CFGR				0x498
+#define RCC_OCENSETR				0x49C
+#define RCC_OCENCLRR				0x4A0
+#define RCC_OCRDYR				0x4A4
+#define RCC_HSICFGR				0x4A8
+#define RCC_MSICFGR				0x4AC
+#define RCC_RTCDIVR				0x4B0
+#define RCC_APB1DIVR				0x4B4
+#define RCC_APB2DIVR				0x4B8
+#define RCC_APB3DIVR				0x4BC
+#define RCC_APB4DIVR				0x4C0
+#define RCC_APBDBGDIVR				0x4C4
+#define RCC_TIMG1PRER				0x4C8
+#define RCC_TIMG2PRER				0x4CC
+#define RCC_LSMCUDIVR				0x4D0
+#define RCC_DDRCPCFGR				0x4D4
+#define RCC_DDRCAPBCFGR				0x4D8
+#define RCC_DDRPHYCAPBCFGR			0x4DC
+#define RCC_DDRPHYCCFGR				0x4E0
+#define RCC_DDRCFGR				0x4E4
+#define RCC_DDRITFCFGR				0x4E8
+#define RCC_SYSRAMCFGR				0x4F0
+#define RCC_VDERAMCFGR				0x4F4
+#define RCC_SRAM1CFGR				0x4F8
+#define RCC_SRAM2CFGR				0x4FC
+#define RCC_RETRAMCFGR				0x500
+#define RCC_BKPSRAMCFGR				0x504
+#define RCC_LPSRAM1CFGR				0x508
+#define RCC_LPSRAM2CFGR				0x50C
+#define RCC_LPSRAM3CFGR				0x510
+#define RCC_OSPI1CFGR				0x514
+#define RCC_OSPI2CFGR				0x518
+#define RCC_FMCCFGR				0x51C
+#define RCC_DBGCFGR				0x520
+#define RCC_STM500CFGR				0x524
+#define RCC_ETRCFGR				0x528
+#define RCC_GPIOACFGR				0x52C
+#define RCC_GPIOBCFGR				0x530
+#define RCC_GPIOCCFGR				0x534
+#define RCC_GPIODCFGR				0x538
+#define RCC_GPIOECFGR				0x53C
+#define RCC_GPIOFCFGR				0x540
+#define RCC_GPIOGCFGR				0x544
+#define RCC_GPIOHCFGR				0x548
+#define RCC_GPIOICFGR				0x54C
+#define RCC_GPIOJCFGR				0x550
+#define RCC_GPIOKCFGR				0x554
+#define RCC_GPIOZCFGR				0x558
+#define RCC_HPDMA1CFGR				0x55C
+#define RCC_HPDMA2CFGR				0x560
+#define RCC_HPDMA3CFGR				0x564
+#define RCC_LPDMACFGR				0x568
+#define RCC_HSEMCFGR				0x56C
+#define RCC_IPCC1CFGR				0x570
+#define RCC_IPCC2CFGR				0x574
+#define RCC_RTCCFGR				0x578
+#define RCC_SYSCPU1CFGR				0x580
+#define RCC_BSECCFGR				0x584
+#define RCC_IS2MCFGR				0x58C
+#define RCC_PLL2CFGR1				0x590
+#define RCC_PLL2CFGR2				0x594
+#define RCC_PLL2CFGR3				0x598
+#define RCC_PLL2CFGR4				0x59C
+#define RCC_PLL2CFGR5				0x5A0
+#define RCC_PLL2CFGR6				0x5A8
+#define RCC_PLL2CFGR7				0x5AC
+#define RCC_PLL3CFGR1				0x5B8
+#define RCC_PLL3CFGR2				0x5BC
+#define RCC_PLL3CFGR3				0x5C0
+#define RCC_PLL3CFGR4				0x5C4
+#define RCC_PLL3CFGR5				0x5C8
+#define RCC_PLL3CFGR6				0x5D0
+#define RCC_PLL3CFGR7				0x5D4
+#define RCC_HSIFMONCR				0x5E0
+#define RCC_HSIFVALR				0x5E4
+#define RCC_TIM1CFGR				0x700
+#define RCC_TIM2CFGR				0x704
+#define RCC_TIM3CFGR				0x708
+#define RCC_TIM4CFGR				0x70C
+#define RCC_TIM5CFGR				0x710
+#define RCC_TIM6CFGR				0x714
+#define RCC_TIM7CFGR				0x718
+#define RCC_TIM8CFGR				0x71C
+#define RCC_TIM10CFGR				0x720
+#define RCC_TIM11CFGR				0x724
+#define RCC_TIM12CFGR				0x728
+#define RCC_TIM13CFGR				0x72C
+#define RCC_TIM14CFGR				0x730
+#define RCC_TIM15CFGR				0x734
+#define RCC_TIM16CFGR				0x738
+#define RCC_TIM17CFGR				0x73C
+#define RCC_TIM20CFGR				0x740
+#define RCC_LPTIM1CFGR				0x744
+#define RCC_LPTIM2CFGR				0x748
+#define RCC_LPTIM3CFGR				0x74C
+#define RCC_LPTIM4CFGR				0x750
+#define RCC_LPTIM5CFGR				0x754
+#define RCC_SPI1CFGR				0x758
+#define RCC_SPI2CFGR				0x75C
+#define RCC_SPI3CFGR				0x760
+#define RCC_SPI4CFGR				0x764
+#define RCC_SPI5CFGR				0x768
+#define RCC_SPI6CFGR				0x76C
+#define RCC_SPI7CFGR				0x770
+#define RCC_SPI8CFGR				0x774
+#define RCC_SPDIFRXCFGR				0x778
+#define RCC_USART1CFGR				0x77C
+#define RCC_USART2CFGR				0x780
+#define RCC_USART3CFGR				0x784
+#define RCC_UART4CFGR				0x788
+#define RCC_UART5CFGR				0x78C
+#define RCC_USART6CFGR				0x790
+#define RCC_UART7CFGR				0x794
+#define RCC_UART8CFGR				0x798
+#define RCC_UART9CFGR				0x79C
+#define RCC_LPUART1CFGR				0x7A0
+#define RCC_I2C1CFGR				0x7A4
+#define RCC_I2C2CFGR				0x7A8
+#define RCC_I2C3CFGR				0x7AC
+#define RCC_I2C4CFGR				0x7B0
+#define RCC_I2C5CFGR				0x7B4
+#define RCC_I2C6CFGR				0x7B8
+#define RCC_I2C7CFGR				0x7BC
+#define RCC_I2C8CFGR				0x7C0
+#define RCC_SAI1CFGR				0x7C4
+#define RCC_SAI2CFGR				0x7C8
+#define RCC_SAI3CFGR				0x7CC
+#define RCC_SAI4CFGR				0x7D0
+#define RCC_MDF1CFGR				0x7D8
+#define RCC_ADF1CFGR				0x7DC
+#define RCC_FDCANCFGR				0x7E0
+#define RCC_HDPCFGR				0x7E4
+#define RCC_ADC12CFGR				0x7E8
+#define RCC_ADC3CFGR				0x7EC
+#define RCC_ETH1CFGR				0x7F0
+#define RCC_ETH2CFGR				0x7F4
+#define RCC_USB2CFGR				0x7FC
+#define RCC_USB2PHY1CFGR			0x800
+#define RCC_USB2PHY2CFGR			0x804
+#define RCC_USB3DRCFGR				0x808
+#define RCC_USB3PCIEPHYCFGR			0x80C
+#define RCC_PCIECFGR				0x810
+#define RCC_USBTCCFGR				0x814
+#define RCC_ETHSWCFGR				0x818
+#define RCC_ETHSWACMCFGR			0x81C
+#define RCC_ETHSWACMMSGCFGR			0x820
+#define RCC_STGENCFGR				0x824
+#define RCC_SDMMC1CFGR				0x830
+#define RCC_SDMMC2CFGR				0x834
+#define RCC_SDMMC3CFGR				0x838
+#define RCC_GPUCFGR				0x83C
+#define RCC_LTDCCFGR				0x840
+#define RCC_DSICFGR				0x844
+#define RCC_LVDSCFGR				0x850
+#define RCC_CSICFGR				0x858
+#define RCC_DCMIPPCFGR				0x85C
+#define RCC_CCICFGR				0x860
+#define RCC_VDECCFGR				0x864
+#define RCC_VENCCFGR				0x868
+#define RCC_RNGCFGR				0x870
+#define RCC_PKACFGR				0x874
+#define RCC_SAESCFGR				0x878
+#define RCC_HASHCFGR				0x87C
+#define RCC_CRYP1CFGR				0x880
+#define RCC_CRYP2CFGR				0x884
+#define RCC_IWDG1CFGR				0x888
+#define RCC_IWDG2CFGR				0x88C
+#define RCC_IWDG3CFGR				0x890
+#define RCC_IWDG4CFGR				0x894
+#define RCC_IWDG5CFGR				0x898
+#define RCC_WWDG1CFGR				0x89C
+#define RCC_WWDG2CFGR				0x8A0
+#define RCC_VREFCFGR				0x8A8
+#define RCC_DTSCFGR				0x8AC
+#define RCC_CRCCFGR				0x8B4
+#define RCC_SERCCFGR				0x8B8
+#define RCC_OSPIIOMCFGR				0x8BC
+#define RCC_GICV2MCFGR				0x8C0
+#define RCC_I3C1CFGR				0x8C8
+#define RCC_I3C2CFGR				0x8CC
+#define RCC_I3C3CFGR				0x8D0
+#define RCC_I3C4CFGR				0x8D4
+#define RCC_MUXSELCFGR				0x1000
+#define RCC_XBAR0CFGR				0x1018
+#define RCC_XBAR1CFGR				0x101C
+#define RCC_XBAR2CFGR				0x1020
+#define RCC_XBAR3CFGR				0x1024
+#define RCC_XBAR4CFGR				0x1028
+#define RCC_XBAR5CFGR				0x102C
+#define RCC_XBAR6CFGR				0x1030
+#define RCC_XBAR7CFGR				0x1034
+#define RCC_XBAR8CFGR				0x1038
+#define RCC_XBAR9CFGR				0x103C
+#define RCC_XBAR10CFGR				0x1040
+#define RCC_XBAR11CFGR				0x1044
+#define RCC_XBAR12CFGR				0x1048
+#define RCC_XBAR13CFGR				0x104C
+#define RCC_XBAR14CFGR				0x1050
+#define RCC_XBAR15CFGR				0x1054
+#define RCC_XBAR16CFGR				0x1058
+#define RCC_XBAR17CFGR				0x105C
+#define RCC_XBAR18CFGR				0x1060
+#define RCC_XBAR19CFGR				0x1064
+#define RCC_XBAR20CFGR				0x1068
+#define RCC_XBAR21CFGR				0x106C
+#define RCC_XBAR22CFGR				0x1070
+#define RCC_XBAR23CFGR				0x1074
+#define RCC_XBAR24CFGR				0x1078
+#define RCC_XBAR25CFGR				0x107C
+#define RCC_XBAR26CFGR				0x1080
+#define RCC_XBAR27CFGR				0x1084
+#define RCC_XBAR28CFGR				0x1088
+#define RCC_XBAR29CFGR				0x108C
+#define RCC_XBAR30CFGR				0x1090
+#define RCC_XBAR31CFGR				0x1094
+#define RCC_XBAR32CFGR				0x1098
+#define RCC_XBAR33CFGR				0x109C
+#define RCC_XBAR34CFGR				0x10A0
+#define RCC_XBAR35CFGR				0x10A4
+#define RCC_XBAR36CFGR				0x10A8
+#define RCC_XBAR37CFGR				0x10AC
+#define RCC_XBAR38CFGR				0x10B0
+#define RCC_XBAR39CFGR				0x10B4
+#define RCC_XBAR40CFGR				0x10B8
+#define RCC_XBAR41CFGR				0x10BC
+#define RCC_XBAR42CFGR				0x10C0
+#define RCC_XBAR43CFGR				0x10C4
+#define RCC_XBAR44CFGR				0x10C8
+#define RCC_XBAR45CFGR				0x10CC
+#define RCC_XBAR46CFGR				0x10D0
+#define RCC_XBAR47CFGR				0x10D4
+#define RCC_XBAR48CFGR				0x10D8
+#define RCC_XBAR49CFGR				0x10DC
+#define RCC_XBAR50CFGR				0x10E0
+#define RCC_XBAR51CFGR				0x10E4
+#define RCC_XBAR52CFGR				0x10E8
+#define RCC_XBAR53CFGR				0x10EC
+#define RCC_XBAR54CFGR				0x10F0
+#define RCC_XBAR55CFGR				0x10F4
+#define RCC_XBAR56CFGR				0x10F8
+#define RCC_XBAR57CFGR				0x10FC
+#define RCC_XBAR58CFGR				0x1100
+#define RCC_XBAR59CFGR				0x1104
+#define RCC_XBAR60CFGR				0x1108
+#define RCC_XBAR61CFGR				0x110C
+#define RCC_XBAR62CFGR				0x1110
+#define RCC_XBAR63CFGR				0x1114
+#define RCC_PREDIV0CFGR				0x1118
+#define RCC_PREDIV1CFGR				0x111C
+#define RCC_PREDIV2CFGR				0x1120
+#define RCC_PREDIV3CFGR				0x1124
+#define RCC_PREDIV4CFGR				0x1128
+#define RCC_PREDIV5CFGR				0x112C
+#define RCC_PREDIV6CFGR				0x1130
+#define RCC_PREDIV7CFGR				0x1134
+#define RCC_PREDIV8CFGR				0x1138
+#define RCC_PREDIV9CFGR				0x113C
+#define RCC_PREDIV10CFGR			0x1140
+#define RCC_PREDIV11CFGR			0x1144
+#define RCC_PREDIV12CFGR			0x1148
+#define RCC_PREDIV13CFGR			0x114C
+#define RCC_PREDIV14CFGR			0x1150
+#define RCC_PREDIV15CFGR			0x1154
+#define RCC_PREDIV16CFGR			0x1158
+#define RCC_PREDIV17CFGR			0x115C
+#define RCC_PREDIV18CFGR			0x1160
+#define RCC_PREDIV19CFGR			0x1164
+#define RCC_PREDIV20CFGR			0x1168
+#define RCC_PREDIV21CFGR			0x116C
+#define RCC_PREDIV22CFGR			0x1170
+#define RCC_PREDIV23CFGR			0x1174
+#define RCC_PREDIV24CFGR			0x1178
+#define RCC_PREDIV25CFGR			0x117C
+#define RCC_PREDIV26CFGR			0x1180
+#define RCC_PREDIV27CFGR			0x1184
+#define RCC_PREDIV28CFGR			0x1188
+#define RCC_PREDIV29CFGR			0x118C
+#define RCC_PREDIV30CFGR			0x1190
+#define RCC_PREDIV31CFGR			0x1194
+#define RCC_PREDIV32CFGR			0x1198
+#define RCC_PREDIV33CFGR			0x119C
+#define RCC_PREDIV34CFGR			0x11A0
+#define RCC_PREDIV35CFGR			0x11A4
+#define RCC_PREDIV36CFGR			0x11A8
+#define RCC_PREDIV37CFGR			0x11AC
+#define RCC_PREDIV38CFGR			0x11B0
+#define RCC_PREDIV39CFGR			0x11B4
+#define RCC_PREDIV40CFGR			0x11B8
+#define RCC_PREDIV41CFGR			0x11BC
+#define RCC_PREDIV42CFGR			0x11C0
+#define RCC_PREDIV43CFGR			0x11C4
+#define RCC_PREDIV44CFGR			0x11C8
+#define RCC_PREDIV45CFGR			0x11CC
+#define RCC_PREDIV46CFGR			0x11D0
+#define RCC_PREDIV47CFGR			0x11D4
+#define RCC_PREDIV48CFGR			0x11D8
+#define RCC_PREDIV49CFGR			0x11DC
+#define RCC_PREDIV50CFGR			0x11E0
+#define RCC_PREDIV51CFGR			0x11E4
+#define RCC_PREDIV52CFGR			0x11E8
+#define RCC_PREDIV53CFGR			0x11EC
+#define RCC_PREDIV54CFGR			0x11F0
+#define RCC_PREDIV55CFGR			0x11F4
+#define RCC_PREDIV56CFGR			0x11F8
+#define RCC_PREDIV57CFGR			0x11FC
+#define RCC_PREDIV58CFGR			0x1200
+#define RCC_PREDIV59CFGR			0x1204
+#define RCC_PREDIV60CFGR			0x1208
+#define RCC_PREDIV61CFGR			0x120C
+#define RCC_PREDIV62CFGR			0x1210
+#define RCC_PREDIV63CFGR			0x1214
+#define RCC_PREDIVSR1				0x1218
+#define RCC_PREDIVSR2				0x121C
+#define RCC_FINDIV0CFGR				0x1224
+#define RCC_FINDIV1CFGR				0x1228
+#define RCC_FINDIV2CFGR				0x122C
+#define RCC_FINDIV3CFGR				0x1230
+#define RCC_FINDIV4CFGR				0x1234
+#define RCC_FINDIV5CFGR				0x1238
+#define RCC_FINDIV6CFGR				0x123C
+#define RCC_FINDIV7CFGR				0x1240
+#define RCC_FINDIV8CFGR				0x1244
+#define RCC_FINDIV9CFGR				0x1248
+#define RCC_FINDIV10CFGR			0x124C
+#define RCC_FINDIV11CFGR			0x1250
+#define RCC_FINDIV12CFGR			0x1254
+#define RCC_FINDIV13CFGR			0x1258
+#define RCC_FINDIV14CFGR			0x125C
+#define RCC_FINDIV15CFGR			0x1260
+#define RCC_FINDIV16CFGR			0x1264
+#define RCC_FINDIV17CFGR			0x1268
+#define RCC_FINDIV18CFGR			0x126C
+#define RCC_FINDIV19CFGR			0x1270
+#define RCC_FINDIV20CFGR			0x1274
+#define RCC_FINDIV21CFGR			0x1278
+#define RCC_FINDIV22CFGR			0x127C
+#define RCC_FINDIV23CFGR			0x1280
+#define RCC_FINDIV24CFGR			0x1284
+#define RCC_FINDIV25CFGR			0x1288
+#define RCC_FINDIV26CFGR			0x128C
+#define RCC_FINDIV27CFGR			0x1290
+#define RCC_FINDIV28CFGR			0x1294
+#define RCC_FINDIV29CFGR			0x1298
+#define RCC_FINDIV30CFGR			0x129C
+#define RCC_FINDIV31CFGR			0x12A0
+#define RCC_FINDIV32CFGR			0x12A4
+#define RCC_FINDIV33CFGR			0x12A8
+#define RCC_FINDIV34CFGR			0x12AC
+#define RCC_FINDIV35CFGR			0x12B0
+#define RCC_FINDIV36CFGR			0x12B4
+#define RCC_FINDIV37CFGR			0x12B8
+#define RCC_FINDIV38CFGR			0x12BC
+#define RCC_FINDIV39CFGR			0x12C0
+#define RCC_FINDIV40CFGR			0x12C4
+#define RCC_FINDIV41CFGR			0x12C8
+#define RCC_FINDIV42CFGR			0x12CC
+#define RCC_FINDIV43CFGR			0x12D0
+#define RCC_FINDIV44CFGR			0x12D4
+#define RCC_FINDIV45CFGR			0x12D8
+#define RCC_FINDIV46CFGR			0x12DC
+#define RCC_FINDIV47CFGR			0x12E0
+#define RCC_FINDIV48CFGR			0x12E4
+#define RCC_FINDIV49CFGR			0x12E8
+#define RCC_FINDIV50CFGR			0x12EC
+#define RCC_FINDIV51CFGR			0x12F0
+#define RCC_FINDIV52CFGR			0x12F4
+#define RCC_FINDIV53CFGR			0x12F8
+#define RCC_FINDIV54CFGR			0x12FC
+#define RCC_FINDIV55CFGR			0x1300
+#define RCC_FINDIV56CFGR			0x1304
+#define RCC_FINDIV57CFGR			0x1308
+#define RCC_FINDIV58CFGR			0x130C
+#define RCC_FINDIV59CFGR			0x1310
+#define RCC_FINDIV60CFGR			0x1314
+#define RCC_FINDIV61CFGR			0x1318
+#define RCC_FINDIV62CFGR			0x131C
+#define RCC_FINDIV63CFGR			0x1320
+#define RCC_FINDIVSR1				0x1324
+#define RCC_FINDIVSR2				0x1328
+#define RCC_FCALCOBS0CFGR			0x1340
+#define RCC_FCALCOBS1CFGR			0x1344
+#define RCC_FCALCREFCFGR			0x1348
+#define RCC_FCALCCR1				0x134C
+#define RCC_FCALCCR2				0x1354
+#define RCC_FCALCSR				0x1358
+#define RCC_PLL4CFGR1				0x1360
+#define RCC_PLL4CFGR2				0x1364
+#define RCC_PLL4CFGR3				0x1368
+#define RCC_PLL4CFGR4				0x136C
+#define RCC_PLL4CFGR5				0x1370
+#define RCC_PLL4CFGR6				0x1378
+#define RCC_PLL4CFGR7				0x137C
+#define RCC_PLL5CFGR1				0x1388
+#define RCC_PLL5CFGR2				0x138C
+#define RCC_PLL5CFGR3				0x1390
+#define RCC_PLL5CFGR4				0x1394
+#define RCC_PLL5CFGR5				0x1398
+#define RCC_PLL5CFGR6				0x13A0
+#define RCC_PLL5CFGR7				0x13A4
+#define RCC_PLL6CFGR1				0x13B0
+#define RCC_PLL6CFGR2				0x13B4
+#define RCC_PLL6CFGR3				0x13B8
+#define RCC_PLL6CFGR4				0x13BC
+#define RCC_PLL6CFGR5				0x13C0
+#define RCC_PLL6CFGR6				0x13C8
+#define RCC_PLL6CFGR7				0x13CC
+#define RCC_PLL7CFGR1				0x13D8
+#define RCC_PLL7CFGR2				0x13DC
+#define RCC_PLL7CFGR3				0x13E0
+#define RCC_PLL7CFGR4				0x13E4
+#define RCC_PLL7CFGR5				0x13E8
+#define RCC_PLL7CFGR6				0x13F0
+#define RCC_PLL7CFGR7				0x13F4
+#define RCC_PLL8CFGR1				0x1400
+#define RCC_PLL8CFGR2				0x1404
+#define RCC_PLL8CFGR3				0x1408
+#define RCC_PLL8CFGR4				0x140C
+#define RCC_PLL8CFGR5				0x1410
+#define RCC_PLL8CFGR6				0x1418
+#define RCC_PLL8CFGR7				0x141C
+#define RCC_VERR				0xFFF4
+#define RCC_IDR					0xFFF8
+#define RCC_SIDR				0xFFFC
+
+#endif /* STM32MP25_RCC_H */
-- 
2.25.1



From krzysztof.kozlowski at linaro.org  Tue Dec 19 05:19:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 14:19:07 +0100
Subject: [PATCH v4 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <d030f5b7-8d32-4a80-a3c0-98cfa1c0fe4f@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <20231218214451.2345691-3-cristian.ciocaltea@collabora.com>
 <c9225053-78f8-40b7-9453-dc3dabe44500@linaro.org>
 <d030f5b7-8d32-4a80-a3c0-98cfa1c0fe4f@collabora.com>
Message-ID: <15077e1f-c13b-4424-9918-df441b56b695@linaro.org>

On 19/12/2023 13:49, Cristian Ciocaltea wrote:
>>>    reg:
>>>      maxItems: 1
>>> @@ -46,23 +50,6 @@ properties:
>>>        - const: tx
>>>        - const: gtx
>>>  
>>> -  interrupts:
>>> -    minItems: 3
>>> -    maxItems: 3
>>> -
>>> -  interrupt-names:
>>> -    minItems: 3
>>> -    maxItems: 3
>>> -
>>> -  resets:
>>> -    minItems: 2
>>> -    maxItems: 2
>>
>> What is the point of your previous patch if you immediately remove it?
>> It is a no-op. Just mention in this commit msg, that both resets and
>> reset-names are coming from snps,dwmac so they can be removed from
>> top-level entirely.
> 
> This has been discussed during v2 review [1], where I also provided the
> rational behind not updating reset-names. So the code was not deleted,
> but moved under an if clause.
> 
> Thanks for reviewing,
> Cristian
> 
> [1]: https://lore.kernel.org/lkml/f4d0b216-5bdc-4559-aabb-8af638d33721 at collabora.com/

I don't see it being addressed:

https://lore.kernel.org/lkml/35556392-3b9a-4997-b482-082dc2f9121f at linaro.org/

Repeating the same and the same :/

Best regards,
Krzysztof



From cristian.ciocaltea at collabora.com  Tue Dec 19 05:20:57 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Tue, 19 Dec 2023 15:20:57 +0200
Subject: [PATCH v4 0/9] Enable networking support for StarFive JH7100 SoC
In-Reply-To: <a37d2df9-e593-476f-bfef-d9abaf063daa@lunn.ch>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <a37d2df9-e593-476f-bfef-d9abaf063daa@lunn.ch>
Message-ID: <0451e5a9-0cfb-42a5-b74b-2012e2c0d326@collabora.com>

On 12/19/23 11:03, Andrew Lunn wrote:
> On Mon, Dec 18, 2023 at 11:44:40PM +0200, Cristian Ciocaltea wrote:
>> This patch series adds ethernet support for the StarFive JH7100 SoC and makes it
>> available for the StarFive VisionFive V1 and BeagleV Starlight boards, although
>> I could only validate on the former SBC.  Thank you Emil and Geert for helping
>> with tests on BeagleV!
> 
> You will need to split this into patch sets per subsystem. The changes
> to the stmmac driver can then go via netdev, and the rest via each
> subsystem maintainer. It should then all meet in linux-next and work
> there.

Thanks for the reviews and your support to get those networking issues
properly handled!

Just to confirm the split will be done correctly, I'm going to keep just
the bindings and dts patches in v5, while the networking driver and
clock related patches will be submitted as part of two additional sets.

Regards,
Cristian


From krzysztof.kozlowski at linaro.org  Tue Dec 19 05:22:05 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 14:22:05 +0100
Subject: [PATCH v4 1/9] dt-bindings: net: starfive,jh7110-dwmac: Drop
 redundant reset description
In-Reply-To: <5b6d78a6-4515-41c2-b94d-5c7df12dbb2d@collabora.com>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <20231218214451.2345691-2-cristian.ciocaltea@collabora.com>
 <92eb5f85-1241-429c-aca9-7a6a17f19ae5@linaro.org>
 <5b6d78a6-4515-41c2-b94d-5c7df12dbb2d@collabora.com>
Message-ID: <b2a94c68-4461-482b-a711-b859a677f8f0@linaro.org>

On 19/12/2023 13:55, Cristian Ciocaltea wrote:
> On 12/19/23 09:24, Krzysztof Kozlowski wrote:
>> On 18/12/2023 22:44, Cristian Ciocaltea wrote:
>>> The reset description items are already provided by the referenced
>>> snps,dwmac.yaml schema, hence replace them with the necessary
>>> {min,max}Items.
>>>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>>> ---
>>>  .../devicetree/bindings/net/starfive,jh7110-dwmac.yaml       | 5 ++---
>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>>> index 5e7cfbbebce6..d90cb82c1424 100644
>>> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>>> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>>> @@ -55,9 +55,8 @@ properties:
>>>      maxItems: 3
>>>  
>>>    resets:
>>> -    items:
>>> -      - description: MAC Reset signal.
>>> -      - description: AHB Reset signal.
>>> +    minItems: 2
>>> +    maxItems: 2
>>
>> Why changing only resets, but not reset-names?
> 
> Already answered in [1], but also discussed in the context of the 
> next patch.
> 
> Thanks,
> Cristian
> 
> [1]: https://lore.kernel.org/lkml/0ff7a905-d8f2-401b-a0ff-47947d12ce05 at collabora.com/

Neither previous answer nor this is correct. snps,dwmac does not allow
ahb entry alone.

NAK

Best regards,
Krzysztof



From cristian.ciocaltea at collabora.com  Tue Dec 19 05:36:58 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Tue, 19 Dec 2023 15:36:58 +0200
Subject: [PATCH v4 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <15077e1f-c13b-4424-9918-df441b56b695@linaro.org>
References: <20231218214451.2345691-1-cristian.ciocaltea@collabora.com>
 <20231218214451.2345691-3-cristian.ciocaltea@collabora.com>
 <c9225053-78f8-40b7-9453-dc3dabe44500@linaro.org>
 <d030f5b7-8d32-4a80-a3c0-98cfa1c0fe4f@collabora.com>
 <15077e1f-c13b-4424-9918-df441b56b695@linaro.org>
Message-ID: <50f0a002-f602-4cdb-ab18-e085adbf09bc@collabora.com>

On 12/19/23 15:19, Krzysztof Kozlowski wrote:
> On 19/12/2023 13:49, Cristian Ciocaltea wrote:
>>>>    reg:
>>>>      maxItems: 1
>>>> @@ -46,23 +50,6 @@ properties:
>>>>        - const: tx
>>>>        - const: gtx
>>>>  
>>>> -  interrupts:
>>>> -    minItems: 3
>>>> -    maxItems: 3
>>>> -
>>>> -  interrupt-names:
>>>> -    minItems: 3
>>>> -    maxItems: 3
>>>> -
>>>> -  resets:
>>>> -    minItems: 2
>>>> -    maxItems: 2
>>>
>>> What is the point of your previous patch if you immediately remove it?
>>> It is a no-op. Just mention in this commit msg, that both resets and
>>> reset-names are coming from snps,dwmac so they can be removed from
>>> top-level entirely.
>>
>> This has been discussed during v2 review [1], where I also provided the
>> rational behind not updating reset-names. So the code was not deleted,
>> but moved under an if clause.
>>
>> Thanks for reviewing,
>> Cristian
>>
>> [1]: https://lore.kernel.org/lkml/f4d0b216-5bdc-4559-aabb-8af638d33721 at collabora.com/
> 
> I don't see it being addressed:
> 
> https://lore.kernel.org/lkml/35556392-3b9a-4997-b482-082dc2f9121f at linaro.org/
> 
> Repeating the same and the same :/

I think this was just a misunderstanding, sorry for the confusion.  I
kept two sets of changes which were not directly related into separate
patches, so I'm going to squash them in v5.

Thanks,
Cristian


From joro at 8bytes.org  Tue Dec 19 05:37:18 2023
From: joro at 8bytes.org (Joerg Roedel)
Date: Tue, 19 Dec 2023 14:37:18 +0100
Subject: [PATCH v4 1/2] iommu: Allow passing custom allocators to pgtable
 drivers
In-Reply-To: <20231215084302.2484163-1-boris.brezillon@collabora.com>
References: <20231215084302.2484163-1-boris.brezillon@collabora.com>
Message-ID: <ZYGcju8vsrf5YywX@8bytes.org>

On Fri, Dec 15, 2023 at 09:43:01AM +0100, Boris Brezillon wrote:
> v4:
> - Add Gaurav's R-b/T-b

Thanks for the re-post, but there is too much on-top (including merge
commits) to replace these.



From acme at kernel.org  Tue Dec 19 05:42:24 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Tue, 19 Dec 2023 10:42:24 -0300
Subject: [PATCH RFC V2 1/4] perf/core: Add aux_pause, aux_resume,
 aux_start_paused
In-Reply-To: <20231208172449.35444-2-adrian.hunter@intel.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
 <20231208172449.35444-2-adrian.hunter@intel.com>
Message-ID: <ZYGdwNHnAOTenZ7c@kernel.org>

Em Fri, Dec 08, 2023 at 07:24:46PM +0200, Adrian Hunter escreveu:
> Hardware traces, such as instruction traces, can produce a vast amount of
> trace data, so being able to reduce tracing to more specific circumstances
> can be useful.

> The ability to pause or resume tracing when another event happens, can do
> that.
 
> Add ability for an event to "pause" or "resume" AUX area tracing.

We need this as well for the usual ring buffer, 'perf report' has:

        --switch-off <event>
                          Stop considering events after the occurrence of this event
        --switch-on <event>
                          Consider events after the occurrence of this event

And 'perf record' has:

       --switch-output-event
           Events that will cause the switch of the perf.data file, auto-selecting --switch-output=signal, the results are similar as internally the side band thread will also send a
           SIGUSR2 to the main one.

But those are all in userspace, what you're doing is in the kernel, and
for the example you used synchronous, i.e. you're only interested in
what happens after you enter the syscall and then stop when the syscall
exits (but here you'll catch more stuff in the AUX trace, i.e. a "race"
from intel_pt inserting events in the AUX trace and then the syscall
exit switching it off).

Also being able to group the { resume, what-to-enable, pause } is
powerful, as we could have multiple such groups to record those
"slices", not just the --switch-off/--switch-on global ones.
 
> Add aux_pause bit to perf_event_attr to indicate that, if the event
> happens, the associated AUX area tracing should be paused. Ditto
> aux_resume. Do not allow aux_pause and aux_resume to be set together.
> 
> Add aux_start_paused bit to perf_event_attr to indicate to an AUX area
> event that it should start in a "paused" state.
> 
> Add aux_paused to struct perf_event for AUX area events to keep track of
> the "paused" state. aux_paused is initialized to aux_start_paused.
> 
> Add PERF_EF_PAUSE and PERF_EF_RESUME modes for ->stop() and ->start()
> callbacks. Call as needed, during __perf_event_output(). Add
> aux_in_pause_resume to struct perf_buffer to prevent races with the NMI
> handler. Pause/resume in NMI context will miss out if it coincides with
> another pause/resume.
> 
> To use aux_pause or aux_resume, an event must be in a group with the AUX
> area event as the group leader.
> 
> Example (requires Intel PT and tools patches also):
> 
>  $ perf record --kcore -e '{intel_pt/aux-start-paused/k,syscalls:sys_enter_newuname/aux-resume/,syscalls:sys_exit_newuname/aux-pause/}' uname

User interface looks nice, asks for intel_pt to be armed but start
paused, collect just inside the kernel, then sets up another event to
enable the collection of whatever is using the aux area, intel_pt in
this case, and then one other event, sys_exit_newuname to pause it
again.

So this implicitely selects the CPU where the aux-resume took place and
in this specific case we ended up being lucky and that process wasn't
migrated to another CPU in the middle of the syscall...

Scratch that, you're not tracing system wide, but just the 'uname'
process being started from perf, perfect.



- Arnaldo

>  Linux
>  [ perf record: Woken up 1 times to write data ]
>  [ perf record: Captured and wrote 0.041 MB perf.data ]
>  $ perf script --call-trace
>  uname    5712 [007]    83.855580930: name: 0x7ffd9dcebec0
>  uname    5712 [007]    83.855582518:  psb offs: 0
>  uname    5712 [007]    83.855582518:  cbr: 42 freq: 4205 MHz (150%)
>  uname    5712 [007]    83.855582723: ([kernel.kallsyms])    debug_smp_processor_id
>  uname    5712 [007]    83.855582723: ([kernel.kallsyms])    __x64_sys_newuname
>  uname    5712 [007]    83.855582723: ([kernel.kallsyms])        down_read
>  uname    5712 [007]    83.855582723: ([kernel.kallsyms])            __cond_resched
>  uname    5712 [007]    83.855582932: ([kernel.kallsyms])            preempt_count_add
>  uname    5712 [007]    83.855582932: ([kernel.kallsyms])                in_lock_functions
>  uname    5712 [007]    83.855582932: ([kernel.kallsyms])            preempt_count_sub
>  uname    5712 [007]    83.855582932: ([kernel.kallsyms])        up_read
>  uname    5712 [007]    83.855582932: ([kernel.kallsyms])            preempt_count_add
>  uname    5712 [007]    83.855583348: ([kernel.kallsyms])                in_lock_functions
>  uname    5712 [007]    83.855583348: ([kernel.kallsyms])            preempt_count_sub
>  uname    5712 [007]    83.855583348: ([kernel.kallsyms])        _copy_to_user
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])    syscall_exit_to_user_mode
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])        syscall_exit_work
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])            perf_syscall_exit
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])                debug_smp_processor_id
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])                perf_trace_buf_alloc
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    perf_swevent_get_recursion_context
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])                        debug_smp_processor_id
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    debug_smp_processor_id
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])                perf_tp_event
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    perf_trace_buf_update
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])                        tracing_gen_ctx_irq_test
>  uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    perf_swevent_event
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                        __perf_event_account_interrupt
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                            __this_cpu_preempt_check
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                        perf_event_output_forward
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                            perf_event_aux_pause
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                ring_buffer_get
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    __rcu_read_lock
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    __rcu_read_unlock
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                pt_event_stop
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    debug_smp_processor_id
>  uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    debug_smp_processor_id
>  uname    5712 [007]    83.855583973: ([kernel.kallsyms])                                    native_write_msr
>  uname    5712 [007]    83.855583973: ([kernel.kallsyms])                                    native_write_msr
>  uname    5712 [007]    83.855584175: 0x0
> 
> Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
> ---
>  include/linux/perf_event.h      | 15 +++++++
>  include/uapi/linux/perf_event.h | 11 ++++-
>  kernel/events/core.c            | 72 +++++++++++++++++++++++++++++++--
>  kernel/events/internal.h        |  1 +
>  4 files changed, 95 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index e85cd1c0eaf3..252c4aac3b79 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -291,6 +291,7 @@ struct perf_event_pmu_context;
>  #define PERF_PMU_CAP_NO_EXCLUDE			0x0040
>  #define PERF_PMU_CAP_AUX_OUTPUT			0x0080
>  #define PERF_PMU_CAP_EXTENDED_HW_TYPE		0x0100
> +#define PERF_PMU_CAP_AUX_PAUSE			0x0200
>  
>  struct perf_output_handle;
>  
> @@ -363,6 +364,8 @@ struct pmu {
>  #define PERF_EF_START	0x01		/* start the counter when adding    */
>  #define PERF_EF_RELOAD	0x02		/* reload the counter when starting */
>  #define PERF_EF_UPDATE	0x04		/* update the counter when stopping */
> +#define PERF_EF_PAUSE	0x08		/* AUX area event, pause tracing */
> +#define PERF_EF_RESUME	0x10		/* AUX area event, resume tracing */
>  
>  	/*
>  	 * Adds/Removes a counter to/from the PMU, can be done inside a
> @@ -402,6 +405,15 @@ struct pmu {
>  	 *
>  	 * ->start() with PERF_EF_RELOAD will reprogram the counter
>  	 *  value, must be preceded by a ->stop() with PERF_EF_UPDATE.
> +	 *
> +	 * ->stop() with PERF_EF_PAUSE will stop as simply as possible. Will not
> +	 * overlap another ->stop() with PERF_EF_PAUSE nor ->start() with
> +	 * PERF_EF_RESUME.
> +	 *
> +	 * ->start() with PERF_EF_RESUME will start as simply as possible but
> +	 * only if the counter is not otherwise stopped. Will not overlap
> +	 * another ->start() with PERF_EF_RESUME nor ->stop() with
> +	 * PERF_EF_PAUSE.
>  	 */
>  	void (*start)			(struct perf_event *event, int flags);
>  	void (*stop)			(struct perf_event *event, int flags);
> @@ -797,6 +809,9 @@ struct perf_event {
>  	/* for aux_output events */
>  	struct perf_event		*aux_event;
>  
> +	/* for AUX area events */
> +	unsigned int			aux_paused;
> +
>  	void (*destroy)(struct perf_event *);
>  	struct rcu_head			rcu_head;
>  
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 39c6a250dd1b..437bc2a8d50c 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -507,7 +507,16 @@ struct perf_event_attr {
>  	__u16	sample_max_stack;
>  	__u16	__reserved_2;
>  	__u32	aux_sample_size;
> -	__u32	__reserved_3;
> +
> +	union {
> +		__u32	aux_output_cfg;
> +		struct {
> +			__u64	aux_pause        :  1, /* on overflow, pause AUX area tracing */
> +				aux_resume       :  1, /* on overflow, resume AUX area tracing */
> +				aux_start_paused :  1, /* start AUX area tracing paused */
> +				__reserved_3     : 29;
> +		};
> +	};
>  
>  	/*
>  	 * User provided data if sigtrap=1, passed back to user via
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 4c72a41f11af..c1e11884d06e 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2060,7 +2060,8 @@ static void perf_put_aux_event(struct perf_event *event)
>  
>  static bool perf_need_aux_event(struct perf_event *event)
>  {
> -	return !!event->attr.aux_output || !!event->attr.aux_sample_size;
> +	return event->attr.aux_output || event->attr.aux_sample_size ||
> +	       event->attr.aux_pause || event->attr.aux_resume;
>  }
>  
>  static int perf_get_aux_event(struct perf_event *event,
> @@ -2085,6 +2086,10 @@ static int perf_get_aux_event(struct perf_event *event,
>  	    !perf_aux_output_match(event, group_leader))
>  		return 0;
>  
> +	if ((event->attr.aux_pause || event->attr.aux_resume) &&
> +	    !(group_leader->pmu->capabilities & PERF_PMU_CAP_AUX_PAUSE))
> +		return 0;
> +
>  	if (event->attr.aux_sample_size && !group_leader->pmu->snapshot_aux)
>  		return 0;
>  
> @@ -7773,6 +7778,47 @@ void perf_prepare_header(struct perf_event_header *header,
>  	WARN_ON_ONCE(header->size & 7);
>  }
>  
> +static void __perf_event_aux_pause(struct perf_event *event, bool pause)
> +{
> +	if (pause) {
> +		if (!READ_ONCE(event->aux_paused)) {
> +			WRITE_ONCE(event->aux_paused, 1);
> +			event->pmu->stop(event, PERF_EF_PAUSE);
> +		}
> +	} else {
> +		if (READ_ONCE(event->aux_paused)) {
> +			WRITE_ONCE(event->aux_paused, 0);
> +			event->pmu->start(event, PERF_EF_RESUME);
> +		}
> +	}
> +}
> +
> +static void perf_event_aux_pause(struct perf_event *event, bool pause)
> +{
> +	struct perf_buffer *rb;
> +	unsigned long flags;
> +
> +	if (WARN_ON_ONCE(!event))
> +		return;
> +
> +	rb = ring_buffer_get(event);
> +	if (!rb)
> +		return;
> +
> +	local_irq_save(flags);
> +	/* Guard against NMI, NMI loses here */
> +	if (READ_ONCE(rb->aux_in_pause_resume))
> +		goto out_restore;
> +	WRITE_ONCE(rb->aux_in_pause_resume, 1);
> +	barrier();
> +	__perf_event_aux_pause(event, pause);
> +	barrier();
> +	WRITE_ONCE(rb->aux_in_pause_resume, 0);
> +out_restore:
> +	local_irq_restore(flags);
> +	ring_buffer_put(rb);
> +}
> +
>  static __always_inline int
>  __perf_event_output(struct perf_event *event,
>  		    struct perf_sample_data *data,
> @@ -7786,6 +7832,9 @@ __perf_event_output(struct perf_event *event,
>  	struct perf_event_header header;
>  	int err;
>  
> +	if (event->attr.aux_pause)
> +		perf_event_aux_pause(event->aux_event, true);
> +
>  	/* protect the callchain buffers */
>  	rcu_read_lock();
>  
> @@ -7802,6 +7851,10 @@ __perf_event_output(struct perf_event *event,
>  
>  exit:
>  	rcu_read_unlock();
> +
> +	if (event->attr.aux_resume)
> +		perf_event_aux_pause(event->aux_event, false);
> +
>  	return err;
>  }
>  
> @@ -11941,10 +11994,23 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
>  	}
>  
>  	if (event->attr.aux_output &&
> -	    !(pmu->capabilities & PERF_PMU_CAP_AUX_OUTPUT)) {
> +	    (!(pmu->capabilities & PERF_PMU_CAP_AUX_OUTPUT) ||
> +	     event->attr.aux_pause || event->attr.aux_resume)) {
> +		err = -EOPNOTSUPP;
> +		goto err_pmu;
> +	}
> +
> +	if (event->attr.aux_pause && event->attr.aux_resume) {
> +		err = -EINVAL;
> +		goto err_pmu;
> +	}
> +
> +	if (event->attr.aux_start_paused &&
> +	    !(pmu->capabilities & PERF_PMU_CAP_AUX_PAUSE)) {
>  		err = -EOPNOTSUPP;
>  		goto err_pmu;
>  	}
> +	event->aux_paused = event->attr.aux_start_paused;
>  
>  	if (cgroup_fd != -1) {
>  		err = perf_cgroup_connect(cgroup_fd, event, attr, group_leader);
> @@ -12741,7 +12807,7 @@ perf_event_create_kernel_counter(struct perf_event_attr *attr, int cpu,
>  	 * Grouping is not supported for kernel events, neither is 'AUX',
>  	 * make sure the caller's intentions are adjusted.
>  	 */
> -	if (attr->aux_output)
> +	if (attr->aux_output || attr->aux_output_cfg)
>  		return ERR_PTR(-EINVAL);
>  
>  	event = perf_event_alloc(attr, cpu, task, NULL, NULL,
> diff --git a/kernel/events/internal.h b/kernel/events/internal.h
> index 5150d5f84c03..3320f78117dc 100644
> --- a/kernel/events/internal.h
> +++ b/kernel/events/internal.h
> @@ -51,6 +51,7 @@ struct perf_buffer {
>  	void				(*free_aux)(void *);
>  	refcount_t			aux_refcount;
>  	int				aux_in_sampling;
> +	int				aux_in_pause_resume;
>  	void				**aux_pages;
>  	void				*aux_priv;
>  
> -- 
> 2.34.1
> 

-- 

- Arnaldo


From mshavit at google.com  Tue Dec 19 05:42:27 2023
From: mshavit at google.com (Michael Shavit)
Date: Tue, 19 Dec 2023 21:42:27 +0800
Subject: [PATCH 04/19] iommu/arm-smmu-v3: Make STE programming independent
 of the callers
In-Reply-To: <CAKHBV26CRC8eWMuOk6EZYMHOZoR2FauP=NBazzOiWCmQYEa1vg@mail.gmail.com>
References: <0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com> <CAKHBV24UGZuG6+J4cybadJCTyf9hN+e_VgAC0NVOPotmEur7SQ@mail.gmail.com>
 <20231012121616.GF3952@nvidia.com> <CAKHBV27G1PLZ5gkYkOOCZdD9waZOZypkWqk4_HSR4XXGFT-+LA@mail.gmail.com>
 <20231018130455.GU3952@nvidia.com> <CAKHBV270uJjdj4zeK-NNt+j3TiqoGDdLUQ5uRrLw9PN0ysCDbw@mail.gmail.com>
 <20231020113918.GD3952@nvidia.com> <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
 <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com>
 <ZX7xu8jN/rBZ4A/d@nvidia.com> <CAKHBV26CRC8eWMuOk6EZYMHOZoR2FauP=NBazzOiWCmQYEa1vg@mail.gmail.com>
Message-ID: <CAKHBV27qsgjgwPfn8OpSq30z1w203NDqBZ0s66bPgjp1XDnLOg@mail.gmail.com>

On Mon, Dec 18, 2023 at 8:35?PM Michael Shavit <mshavit at google.com> wrote:
>
> On Sun, Dec 17, 2023 at 9:03?PM Jason Gunthorpe <jgg at nvidia.com> wrote:
> >
> > On Sat, Dec 16, 2023 at 04:26:48AM +0800, Michael Shavit wrote:
> >
> > > Ok, I took a proper stab at trying to unroll the loop on the github
> > > version of this patch (v3+)
> > > As you suspected, it's not easy to re-use the unrolled version for
> > > both STE and CD writing as we'd have to pass in callbacks for syncing
> > > the STE/CD and recomputing arm_smmu_{get_ste/cd}_used.
> >
> > Yes, that is why I structured it as an iterator
>
> On second thought, perhaps defining a helper class implementing
> entry_sync() and entry_get_used_bits() might not be so bad?
> It's a little bit more verbose, but avoids deduplication of the
> complicated parts.

Gave this a try so that we have something more concrete to compare.
Consider the following two patches as alternatives to this patch and
patch "Make CD programming use arm_smmu_write_entry_step" from the
next part of the patch series.

STE programming patch
---
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index b120d83668...1e17bff37f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -971,6 +971,174 @@
        arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
 }

+struct arm_smmu_entry_writer;
+
+/**
+ * struct arm_smmu_entry_writer_ops - Helper class for writing a CD/STE entry.
+ * @sync_entry: sync entry to the hardware after writing to it.
+ * @set_unused_bits: Make bits of the entry that aren't in use by the hardware
+ *                   equal to the target's bits.
+ * @get_used_qword_diff_indexes: Compute the list of qwords in the entry that
+ *                               are incorrect compared to the target,
+ *                               considering only the used bits in the target.
+ *                               The set bits in the return value
represents the
+ *                               indexes of those qwords.
+ */
+struct arm_smmu_entry_writer_ops {
+       void (*sync_entry)(struct arm_smmu_entry_writer *);
+       void (*set_unused_bits)(__le64 *entry, const __le64 *target);
+       u8 (*get_used_qword_diff_indexes)(__le64 *entry, const __le64 *target);
+};
+
+struct arm_smmu_entry_writer {
+       struct arm_smmu_entry_writer_ops ops;
+       __le64 v_bit;
+       unsigned int entry_length;
+};
+
+static void arm_smmu_entry_set_unused_bits(__le64 *entry, const __le64 *target,
+                                          const __le64 *entry_used,
+                                          unsigned int length)
+{
+       int i = 0;
+
+       for (i = 0; i < length; i++)
+               entry[i] = (entry[i] & entry_used[i]) |
+                          (target[i] & ~entry_used[i]);
+}
+
+static u8 arm_smmu_entry_used_qword_diff_indexes(__le64 *entry,
+                                                const __le64 *target,
+                                                const __le64 *target_used,
+                                                unsigned int length)
+{
+       u8 qword_diff_indexes = 0;
+       int i = 0;
+
+       for (i = 0; i < length; i++) {
+               if ((entry[i] & target_used[i]) != (target[i] & target_used[i]))
+                       qword_diff_indexes |= 1 << i;
+       }
+       return qword_diff_indexes;
+}
+
+/*
+ * Update the STE/CD to the target configuration. The transition from
the current
+ * entry to the target entry takes place over multiple steps that
attempts to make
+ * the transition hitless if possible. This function takes care not to create a
+ * situation where the HW can perceive a corrupted entry. HW is only
required to
+ * have a 64 bit atomicity with stores from the CPU, while entries are many 64
+ * bit values big.
+ *
+ * The algorithm works by evolving the entry toward the target in a series of
+ * steps. Each step synchronizes with the HW so that the HW can not
see an entry
+ * torn across two steps. During each step the HW can observe a torn entry that
+ * has any combination of the step's old/new 64 bit words. The algorithm
+ * objective is for the HW behavior to always be one of current behavior, V=0,
+ * or new behavior.
+ *
+ * In the most general case we can make any update in three steps:
+ *  - Disrupting the entry (V=0)
+ *  - Fill now unused bits, all bits except V
+ *  - Make valid (V=1), single 64 bit store
+ *
+ * However this disrupts the HW while it is happening. There are several
+ * interesting cases where a STE/CD can be updated without disturbing the HW
+ * because only a small number of bits are changing (S1DSS, CONFIG, etc) or
+ * because the used bits don't intersect. We can detect this by calculating how
+ * many 64 bit values need update after adjusting the unused bits and skip the
+ * V=0 process. This relies on the IGNORED behavior described in the
+ * specification
+ */
+static void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer,
+                                __le64 *cur, const __le64 *target,
+                                __le64 *staging_entry)
+{
+       bool cleanup_sync_required = false;
+       u8 entry_qwords_used_diff = 0;
+       int i = 0;
+
+       entry_qwords_used_diff =
+               writer->ops.get_used_qword_diff_indexes(cur, target);
+       if (WARN_ON_ONCE(entry_qwords_used_diff == 0))
+               return;
+
+       if (hweight8(entry_qwords_used_diff) > 1) {
+               /*
+                * If transitioning to the target entry with a single qword
+                * write isn't possible, then we must first transition to an
+                * intermediate entry. The intermediate entry may either be an
+                * entry that melds bits of the target entry into the current
+                * entry without disrupting the hardware, or a breaking entry if
+                * a hitless transition to the target is impossible.
+                */
+
+               /*
+                * Compute a staging entry that has all the bits currently
+                * unused by HW set to their target values, such that comitting
+                * it to the entry table woudn't disrupt the hardware.
+                */
+               memcpy(staging_entry, cur, writer->entry_length);
+               writer->ops.set_unused_bits(staging_entry, target);
+
+               entry_qwords_used_diff =
+                       writer->ops.get_used_qword_diff_indexes(staging_entry,
+                                                               target);
+               if (hweight8(entry_qwords_used_diff) > 1) {
+                       /*
+                        * More than 1 qword is mismatched between the staging
+                        * and target entry. A hitless transition to the target
+                        * entry is not possible. Set the staging entry to be
+                        * equal to the target entry, apart from the V bit's
+                        * qword. As long as the V bit is cleared first then
+                        * writes to the subsequent qwords will not further
+                        * disrupt the hardware.
+                        */
+                       memcpy(staging_entry, target, writer->entry_length);
+                       staging_entry[0] &= ~writer->v_bit;
+                       /*
+                        * After comitting the staging entry, only the 0th qword
+                        * will differ from the target.
+                        */
+                       entry_qwords_used_diff = 1;
+               }
+
+               /*
+                * Commit the staging entry. Note that the iteration order
+                * matters, as we may be comitting a breaking entry in the
+                * non-hitless case. The 0th qword which holds the valid bit
+                * must be written first in that case.
+                */
+               for (i = 0; i != writer->entry_length; i++)
+                       WRITE_ONCE(cur[i], staging_entry[i]);
+               writer->ops.sync_entry(writer);
+       }
+
+       /*
+        * It's now possible to switch to the target configuration with a write
+        * to a single qword. Make that switch now.
+        */
+       i = ffs(entry_qwords_used_diff) - 1;
+       WRITE_ONCE(cur[i], target[i]);
+       writer->ops.sync_entry(writer);
+
+       /*
+        * Some of the bits set under the previous configuration but unused
+        * under the target configuration might still be set. Clear them as
+        * well. Technically this isn't necessary but it brings the entry to
+        * the full target state, so if there are bugs in the mask calculation
+        * this will obscure them.
+        */
+       for (i = 0; i != writer->entry_length; i++) {
+               if (cur[i] != target[i]) {
+                       WRITE_ONCE(cur[i], target[i]);
+                       cleanup_sync_required = true;
+               }
+       }
+       if (cleanup_sync_required)
+               writer->ops.sync_entry(writer);
+}
+
 static void arm_smmu_sync_cd(struct arm_smmu_master *master,
                             int ssid, bool leaf)
 {
@@ -1248,37 +1416,142 @@
        arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
 }

+/*
+ * Based on the value of ent report which bits of the STE the HW will
access. It
+ * would be nice if this was complete according to the spec, but minimally it
+ * has to capture the bits this driver uses.
+ */
+static void arm_smmu_get_ste_used(const __le64 *ent,
+                                 struct arm_smmu_ste *used_bits)
+{
+       memset(used_bits, 0, sizeof(*used_bits));
+
+       used_bits->data[0] = cpu_to_le64(STRTAB_STE_0_V);
+       if (!(ent[0] & cpu_to_le64(STRTAB_STE_0_V)))
+               return;
+
+       /*
+        * If S1 is enabled S1DSS is valid, see 13.5 Summary of
+        * attribute/permission configuration fields for the SHCFG behavior.
+        */
+       if (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(ent[0])) & 1 &&
+           FIELD_GET(STRTAB_STE_1_S1DSS, le64_to_cpu(ent[1])) ==
+                   STRTAB_STE_1_S1DSS_BYPASS)
+               used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_SHCFG);
+
+       used_bits->data[0] |= cpu_to_le64(STRTAB_STE_0_CFG);
+       switch (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(ent[0]))) {
+       case STRTAB_STE_0_CFG_ABORT:
+               break;
+       case STRTAB_STE_0_CFG_BYPASS:
+               used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_SHCFG);
+               break;
+       case STRTAB_STE_0_CFG_S1_TRANS:
+               used_bits->data[0] |= cpu_to_le64(STRTAB_STE_0_S1FMT |
+                                                 STRTAB_STE_0_S1CTXPTR_MASK |
+                                                 STRTAB_STE_0_S1CDMAX);
+               used_bits->data[1] |=
+                       cpu_to_le64(STRTAB_STE_1_S1DSS | STRTAB_STE_1_S1CIR |
+                                   STRTAB_STE_1_S1COR | STRTAB_STE_1_S1CSH |
+                                   STRTAB_STE_1_S1STALLD | STRTAB_STE_1_STRW);
+               used_bits->data[1] |= cpu_to_le64(STRTAB_STE_1_EATS);
+               break;
+       case STRTAB_STE_0_CFG_S2_TRANS:
+               used_bits->data[1] |=
+                       cpu_to_le64(STRTAB_STE_1_EATS | STRTAB_STE_1_SHCFG);
+               used_bits->data[2] |=
+                       cpu_to_le64(STRTAB_STE_2_S2VMID | STRTAB_STE_2_VTCR |
+                                   STRTAB_STE_2_S2AA64 | STRTAB_STE_2_S2ENDI |
+                                   STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2R);
+               used_bits->data[3] |= cpu_to_le64(STRTAB_STE_3_S2TTB_MASK);
+               break;
+
+       default:
+               memset(used_bits, 0xFF, sizeof(*used_bits));
+               WARN_ON(true);
+       }
+}
+
+struct arm_smmu_ste_writer {
+       struct arm_smmu_entry_writer writer;
+       struct arm_smmu_device *smmu;
+       u32 sid;
+};
+
+static void arm_smmu_ste_set_unused_bits(__le64 *entry, const __le64 *target)
+{
+       struct arm_smmu_ste entry_used;
+       arm_smmu_get_ste_used(entry, &entry_used);
+
+       arm_smmu_entry_set_unused_bits(entry, target, entry_used.data,
+                                      ARRAY_SIZE(entry_used.data));
+}
+
+static u8 arm_smmu_ste_used_qword_diff_indexes(__le64 *cur,
+                                              const __le64 *target)
+{
+       struct arm_smmu_ste target_used;
+
+       arm_smmu_get_ste_used(target, &target_used);
+       return arm_smmu_entry_used_qword_diff_indexes(
+               cur, target, target_used.data, ARRAY_SIZE(target_used.data));
+}
+
+static void arm_smmu_ste_writer_sync_entry(struct
arm_smmu_entry_writer *writer)
+{
+       struct arm_smmu_ste_writer *ste_writer =
+               container_of(writer, struct arm_smmu_ste_writer, writer);
+
+       arm_smmu_sync_ste_for_sid(ste_writer->smmu, ste_writer->sid);
+}
+
+static const struct arm_smmu_entry_writer_ops arm_smmu_ste_writer_ops = {
+       .sync_entry = arm_smmu_ste_writer_sync_entry,
+       .set_unused_bits = arm_smmu_ste_set_unused_bits,
+       .get_used_qword_diff_indexes = arm_smmu_ste_used_qword_diff_indexes,
+};
+
+static void arm_smmu_write_ste(struct arm_smmu_device *smmu, u32 sid,
+                              struct arm_smmu_ste *ste,
+                              const struct arm_smmu_ste *target)
+{
+       struct arm_smmu_ste preallocated_staging_ste = {0};
+       struct arm_smmu_ste_writer ste_writer = {
+               .writer = {
+                       .ops = arm_smmu_ste_writer_ops,
+                       .v_bit = cpu_to_le64(STRTAB_STE_0_V),
+                       .entry_length = ARRAY_SIZE(ste->data),
+               },
+               .smmu = smmu,
+               .sid = sid,
+       };
+
+       arm_smmu_write_entry(&ste_writer.writer,
+                              ste->data,
+                              target->data,
+                              preallocated_staging_ste.data);
+
+       /* It's likely that we'll want to use the new STE soon */
+       if (!(smmu->options & ARM_SMMU_OPT_SKIP_PREFETCH)) {
+               struct arm_smmu_cmdq_ent
+                       prefetch_cmd = { .opcode = CMDQ_OP_PREFETCH_CFG,
+                                        .prefetch = {
+                                                .sid = sid,
+                                        } };
+
+               arm_smmu_cmdq_issue_cmd(smmu, &prefetch_cmd);
+       }
+}
+
 static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
                                      struct arm_smmu_ste *dst)
 {
-       /*
-        * This is hideously complicated, but we only really care about
-        * three cases at the moment:
-        *
-        * 1. Invalid (all zero) -> bypass/fault (init)
-        * 2. Bypass/fault -> translation/bypass (attach)
-        * 3. Translation/bypass -> bypass/fault (detach)
-        *
-        * Given that we can't update the STE atomically and the SMMU
-        * doesn't read the thing in a defined order, that leaves us
-        * with the following maintenance requirements:
-        *
-        * 1. Update Config, return (init time STEs aren't live)
-        * 2. Write everything apart from dword 0, sync, write dword 0, sync
-        * 3. Update Config, sync
-        */
-       u64 val = le64_to_cpu(dst->data[0]);
-       bool ste_live = false;
+       u64 val;
        struct arm_smmu_device *smmu = master->smmu;
        struct arm_smmu_ctx_desc_cfg *cd_table = NULL;
        struct arm_smmu_s2_cfg *s2_cfg = NULL;
        struct arm_smmu_domain *smmu_domain = master->domain;
-       struct arm_smmu_cmdq_ent prefetch_cmd = {
-               .opcode         = CMDQ_OP_PREFETCH_CFG,
-               .prefetch       = {
-                       .sid    = sid,
-               },
-       };
+       struct arm_smmu_ste target = {};

        if (smmu_domain) {
                switch (smmu_domain->stage) {
@@ -1293,22 +1566,6 @@
                }
        }

-       if (val & STRTAB_STE_0_V) {
-               switch (FIELD_GET(STRTAB_STE_0_CFG, val)) {
-               case STRTAB_STE_0_CFG_BYPASS:
-                       break;
-               case STRTAB_STE_0_CFG_S1_TRANS:
-               case STRTAB_STE_0_CFG_S2_TRANS:
-                       ste_live = true;
-                       break;
-               case STRTAB_STE_0_CFG_ABORT:
-                       BUG_ON(!disable_bypass);
-                       break;
-               default:
-                       BUG(); /* STE corruption */
-               }
-       }
-
        /* Nuke the existing STE_0 value, as we're going to rewrite it */
        val = STRTAB_STE_0_V;

@@ -1319,16 +1576,11 @@
                else
                        val |= FIELD_PREP(STRTAB_STE_0_CFG,
STRTAB_STE_0_CFG_BYPASS);

-               dst->data[0] = cpu_to_le64(val);
-               dst->data[1] = cpu_to_le64(FIELD_PREP(STRTAB_STE_1_SHCFG,
+               target.data[0] = cpu_to_le64(val);
+               target.data[1] = cpu_to_le64(FIELD_PREP(STRTAB_STE_1_SHCFG,
                                                STRTAB_STE_1_SHCFG_INCOMING));
-               dst->data[2] = 0; /* Nuke the VMID */
-               /*
-                * The SMMU can perform negative caching, so we must sync
-                * the STE regardless of whether the old value was live.
-                */
-               if (smmu)
-                       arm_smmu_sync_ste_for_sid(smmu, sid);
+               target.data[2] = 0; /* Nuke the VMID */
+               arm_smmu_write_ste(smmu, sid, dst, &target);
                return;
        }

@@ -1336,8 +1588,7 @@
                u64 strw = smmu->features & ARM_SMMU_FEAT_E2H ?
                        STRTAB_STE_1_STRW_EL2 : STRTAB_STE_1_STRW_NSEL1;

-               BUG_ON(ste_live);
-               dst->data[1] = cpu_to_le64(
+               target.data[1] = cpu_to_le64(
                         FIELD_PREP(STRTAB_STE_1_S1DSS,
STRTAB_STE_1_S1DSS_SSID0) |
                         FIELD_PREP(STRTAB_STE_1_S1CIR,
STRTAB_STE_1_S1C_CACHE_WBRA) |
                         FIELD_PREP(STRTAB_STE_1_S1COR,
STRTAB_STE_1_S1C_CACHE_WBRA) |
@@ -1346,7 +1597,7 @@

                if (smmu->features & ARM_SMMU_FEAT_STALLS &&
                    !master->stall_enabled)
-                       dst->data[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
+                       target.data[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);

                val |= (cd_table->cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) |
                        FIELD_PREP(STRTAB_STE_0_CFG,
STRTAB_STE_0_CFG_S1_TRANS) |
@@ -1355,8 +1606,7 @@
        }

        if (s2_cfg) {
-               BUG_ON(ste_live);
-               dst->data[2] = cpu_to_le64(
+               target.data[2] = cpu_to_le64(
                         FIELD_PREP(STRTAB_STE_2_S2VMID, s2_cfg->vmid) |
                         FIELD_PREP(STRTAB_STE_2_VTCR, s2_cfg->vtcr) |
 #ifdef __BIG_ENDIAN
@@ -1365,23 +1615,17 @@
                         STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2AA64 |
                         STRTAB_STE_2_S2R);

-               dst->data[3] = cpu_to_le64(s2_cfg->vttbr &
STRTAB_STE_3_S2TTB_MASK);
+               target.data[3] = cpu_to_le64(s2_cfg->vttbr &
STRTAB_STE_3_S2TTB_MASK);

                val |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S2_TRANS);
        }

        if (master->ats_enabled)
-               dst->data[1] |= cpu_to_le64(FIELD_PREP(STRTAB_STE_1_EATS,
+               target.data[1] |= cpu_to_le64(FIELD_PREP(STRTAB_STE_1_EATS,
                                                 STRTAB_STE_1_EATS_TRANS));

-       arm_smmu_sync_ste_for_sid(smmu, sid);
-       /* See comment in arm_smmu_write_ctx_desc() */
-       WRITE_ONCE(dst->data[0], cpu_to_le64(val));
-       arm_smmu_sync_ste_for_sid(smmu, sid);
-
-       /* It's likely that we'll want to use the new STE soon */
-       if (!(smmu->options & ARM_SMMU_OPT_SKIP_PREFETCH))
-               arm_smmu_cmdq_issue_cmd(smmu, &prefetch_cmd);
+       target.data[0] = cpu_to_le64(val);
+       arm_smmu_write_ste(smmu, sid, dst, &target);
 }

 static void arm_smmu_init_bypass_stes(struct arm_smmu_ste *strtab,





---
CD programming
---
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 55703a5d62...c849b26c43 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1219,6 +1219,86 @@
        return &l1_desc->l2ptr[idx];
 }

+static void arm_smmu_get_cd_used(const __le64 *ent,
+                                struct arm_smmu_cd *used_bits)
+{
+       memset(used_bits, 0, sizeof(*used_bits));
+
+       used_bits->data[0] = cpu_to_le64(CTXDESC_CD_0_V);
+       if (!(ent[0] & cpu_to_le64(CTXDESC_CD_0_V)))
+               return;
+       memset(used_bits, 0xFF, sizeof(*used_bits));
+
+       /* EPD0 means T0SZ/TG0/IR0/OR0/SH0/TTB0 are IGNORED */
+       if (ent[0] & cpu_to_le64(CTXDESC_CD_0_TCR_EPD0)) {
+               used_bits->data[0] &= ~cpu_to_le64(
+                       CTXDESC_CD_0_TCR_T0SZ | CTXDESC_CD_0_TCR_TG0 |
+                       CTXDESC_CD_0_TCR_IRGN0 | CTXDESC_CD_0_TCR_ORGN0 |
+                       CTXDESC_CD_0_TCR_SH0);
+               used_bits->data[1] &= ~cpu_to_le64(CTXDESC_CD_1_TTB0_MASK);
+       }
+}
+
+struct arm_smmu_cd_writer {
+       struct arm_smmu_entry_writer writer;
+       struct arm_smmu_master *master;
+       int ssid;
+};
+
+static void arm_smmu_cd_set_unused_bits(__le64 *entry, const __le64 *target)
+{
+       struct arm_smmu_cd entry_used;
+       arm_smmu_get_cd_used(entry, &entry_used);
+
+       arm_smmu_entry_set_unused_bits(entry, target, entry_used.data,
+                                      ARRAY_SIZE(entry_used.data));
+}
+
+static u8 arm_smmu_cd_used_qword_diff_indexes(__le64 *cur,
+                                              const __le64 *target)
+{
+       struct arm_smmu_cd target_used;
+
+       arm_smmu_get_cd_used(target, &target_used);
+       return arm_smmu_entry_used_qword_diff_indexes(
+               cur, target, target_used.data, ARRAY_SIZE(target_used.data));
+}
+
+static void arm_smmu_cd_writer_sync_entry(struct arm_smmu_entry_writer *writer)
+{
+       struct arm_smmu_cd_writer *cd_writer =
+               container_of(writer, struct arm_smmu_cd_writer, writer);
+
+       arm_smmu_sync_cd(cd_writer->master, cd_writer->ssid, true);
+}
+
+static const struct arm_smmu_entry_writer_ops arm_smmu_cd_writer_ops = {
+       .sync_entry = arm_smmu_cd_writer_sync_entry,
+       .set_unused_bits = arm_smmu_cd_set_unused_bits,
+       .get_used_qword_diff_indexes = arm_smmu_cd_used_qword_diff_indexes,
+};
+
+static void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
+                                   struct arm_smmu_cd *cdptr,
+                                   const struct arm_smmu_cd *target)
+{
+       struct arm_smmu_cd preallocated_staging_cd = {0};
+       struct arm_smmu_cd_writer cd_writer = {
+               .writer = {
+                       .ops = arm_smmu_cd_writer_ops,
+                       .v_bit = cpu_to_le64(CTXDESC_CD_0_V),
+                       .entry_length = ARRAY_SIZE(cdptr->data),
+               },
+               .master = master,
+               .ssid = ssid,
+       };
+
+       arm_smmu_write_entry(&cd_writer.writer,
+                              cdptr->data,
+                              target->data,
+                              preallocated_staging_cd.data);
+}
+
 int arm_smmu_write_ctx_desc(struct arm_smmu_master *master, int ssid,
                            struct arm_smmu_ctx_desc *cd)
 {
@@ -1235,16 +1315,19 @@
         */
        u64 val;
        bool cd_live;
-       struct arm_smmu_cd *cdptr;
+       struct arm_smmu_cd target;
+       struct arm_smmu_cd *cdptr = &target;
+       struct arm_smmu_cd *cd_table_entry;
        struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table;

        if (WARN_ON(ssid >= (1 << cd_table->s1cdmax)))
                return -E2BIG;

-       cdptr = arm_smmu_get_cd_ptr(master, ssid);
-       if (!cdptr)
+       cd_table_entry = arm_smmu_get_cd_ptr(master, ssid);
+       if (!cd_table_entry)
                return -ENOMEM;

+       target = *cd_table_entry;
        val = le64_to_cpu(cdptr->data[0]);
        cd_live = !!(val & CTXDESC_CD_0_V);

@@ -1264,13 +1347,6 @@
                cdptr->data[2] = 0;
                cdptr->data[3] = cpu_to_le64(cd->mair);

-               /*
-                * STE may be live, and the SMMU might read dwords of
this CD in any
-                * order. Ensure that it observes valid values before reading
-                * V=1.
-                */
-               arm_smmu_sync_cd(master, ssid, true);
-
                val = cd->tcr |
 #ifdef __BIG_ENDIAN
                        CTXDESC_CD_0_ENDI |
@@ -1284,18 +1360,8 @@
                if (cd_table->stall_enabled)
                        val |= CTXDESC_CD_0_S;
        }
-
-       /*
-        * The SMMU accesses 64-bit values atomically. See IHI0070Ca 3.21.3
-        * "Configuration structures and configuration invalidation completion"
-        *
-        *   The size of single-copy atomic reads made by the SMMU is
-        *   IMPLEMENTATION DEFINED but must be at least 64 bits. Any single
-        *   field within an aligned 64-bit span of a structure can be altered
-        *   without first making the structure invalid.
-        */
-       WRITE_ONCE(cdptr->data[0], cpu_to_le64(val));
-       arm_smmu_sync_cd(master, ssid, true);
+       cdptr->data[0] = cpu_to_le64(val);
+       arm_smmu_write_cd_entry(master, ssid, cd_table_entry, &target);
        return 0;
 }


From tomi.valkeinen at ideasonboard.com  Tue Dec 19 05:51:09 2023
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Tue, 19 Dec 2023 15:51:09 +0200
Subject: [PATCH 2/2] media: rkisp1: Fix IRQ handling due to shared
 interrupts
In-Reply-To: <20231219130849.GA29638@pendragon.ideasonboard.com>
References: <20231218-rkisp-shirq-fix-v1-0-173007628248@ideasonboard.com>
 <20231218-rkisp-shirq-fix-v1-2-173007628248@ideasonboard.com>
 <20231218092240.GB26540@pendragon.ideasonboard.com>
 <b465355b-65c2-451f-ae2e-63da9d0a6282@ideasonboard.com>
 <20231219130849.GA29638@pendragon.ideasonboard.com>
Message-ID: <60b3aec2-294f-4ab0-8a4b-0c32a52c84a0@ideasonboard.com>

On 19/12/2023 15:08, Laurent Pinchart wrote:
> Hi Tomi,
> 
> CC'ing Sakari
> 
> On Tue, Dec 19, 2023 at 10:50:05AM +0200, Tomi Valkeinen wrote:
>> On 18/12/2023 11:22, Laurent Pinchart wrote:
>>> On Mon, Dec 18, 2023 at 09:54:01AM +0200, Tomi Valkeinen wrote:
>>>> The driver requests the interrupts as IRQF_SHARED, so the interrupt
>>>> handlers can be called at any time. If such a call happens while the ISP
>>>> is powered down, the SoC will hang as the driver tries to access the
>>>> ISP registers.
>>>>
>>>> This can be reproduced even without the platform sharing the IRQ line:
>>>> Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will
>>>> hang.
>>>>
>>>> Fix this by adding a new field, 'irqs_enabled', which is used to bail
>>>> out from the interrupt handler when the ISP is not operational.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>>>> ---
>>>>    .../platform/rockchip/rkisp1/rkisp1-capture.c      |  3 +++
>>>>    .../media/platform/rockchip/rkisp1/rkisp1-common.h |  2 ++
>>>>    .../media/platform/rockchip/rkisp1/rkisp1-csi.c    |  3 +++
>>>>    .../media/platform/rockchip/rkisp1/rkisp1-dev.c    | 22 ++++++++++++++++++++++
>>>>    .../media/platform/rockchip/rkisp1/rkisp1-isp.c    |  3 +++
>>>>    5 files changed, 33 insertions(+)
>>>>
>>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
>>>> index aebd3c12020b..c381c22135a2 100644
>>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
>>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
>>>> @@ -725,6 +725,9 @@ irqreturn_t rkisp1_capture_isr(int irq, void *ctx)
>>>>    	unsigned int i;
>>>>    	u32 status;
>>>>    
>>>> +	if (!rkisp1->irqs_enabled)
>>>> +		return IRQ_NONE;
>>>
>>> Given that this is something all drivers that use shared IRQs have to
>>> do, would it make sense to use a standard helper here, such as
>>> pm_runtime_suspended() for instance ? I haven't looked at which one
>>> would be the most appropriate (if any), there's also
>>> pm_runtime_active() and pm_runtime_status_suspended(). That would
>>> simplify this patch.
>>
>> I did consider that when writing the patch. But I just wasn't very
>> comfortable using the runtime PM here, even if it would make sense, as
>> I'm just not quite sure how it works.
>>
>> For example, pm_runtime_suspended() checks if the device is in
>> RPM_SUSPENDED state, and the device will be in RPM_SUSPENDED after the
>> driver's suspend callback has finished. This makes sense.
>>
>> However, _while_ suspending (not after we have suspended), we want to
>> make sure that 1) no new irq handling will start, 2) we'll wait until
>> any currently running irq handler has finished. For 1), we can't use
>> pm_runtime_suspended() in the irq handler, as the status is not
>> RPM_SUSPENDED. We could probably check for:
>>
>> spin_lock(&dev->power.lock);
>> off = dev->power.runtime_status == RPM_SUSPENDED ||
>> dev->power.runtime_status == RPM_SUSPENDING;
>> spin_unlock(&dev->power.lock);
>> if (off)
>> 	return IRQ_NONE;
>>
>> That would not work if we would depend on the irq handling while in the
>> suspend callback (e.g. waiting for an irq which signals that the device
>> has finished processing). But we don't do that at the moment, and that
>> kind of this probably can usually be done before calling runtime_put().
>>
>> When we take into account the resume part, I think we could just check
>> for RPM_ACTIVE in the irq handler, which would then rule out
>> RPM_RESUMING, RPM_SUSPENDED and RPM_SUSPENDING.
>>
>> But we can't use pm_runtime_active(), as that also checks for
>> dev->power.disable_depth. In other words, when we disable the PM for our
>> device (e.g. when unloading the driver), the PM framework says our
>> device became active.
>>
>> Soo... I think this should work in the irq handler:
>>
>> spin_lock(&dev->power.lock);
>> active = dev->power.runtime_status == RPM_ACTIVE;
> 
> It would be nice to use pm_runtime_active() instead. This would however
> require unregistering the IRQ handler before disabling runtime PM in the
> remove path. I think that should be done nonetheless though, as relying
> on devm to unregister the IRQ handler means it will happen after
> .remove() returns, which could cause all sort of issues (I'm thinking
> about the calls to dev_get_drvdata() in the IRQ handlers for instance).
> What do you think ?

I agree, devm with irqs sounds scary.

What I'd like to do is reserve an irq handler without activating it. 
That call could return an error, if, e.g. there's no such irq. Then 
later I would enable it (could be in the resume callback, but as well in 
the start-stream call), which would never return an error.

Having those both combined in a single call is not nice, as we have to 
deal with irq handler calls even when the driver knows it doesn't want them.

>> spin_unlock(&dev->power.lock);
>> if (!active)
>> 	return IRQ_NONE;
>>
>> I think the driver depends on runtime PM, but if no-PM was an option, I
>> guess we'd need to ifdef the above away, and trust that the device is
>> always powered on.
>>
>> So, as I said in the beginning, "I just wasn't very comfortable using
>> the runtime PM here". And that's still the case =). The runtime PM is
>> horribly complex. If you think the above is clearer, and you think it's
>> correct, I can make the change.
> 
> It sounds it may require some more work, and we should land this fix in
> v6.8, with the revert, right ? If so, I'm fine merging this patch, and
> moving to runtime PM checks on top if we decide to do so.

Yes. I think this fix should work as it is now. That said, I haven't 
heard anyone else reporting this issue, so maybe just applying the 
revert (to fix the driver) would be enough. And we could then figure out 
later how exactly to handle the shared interrupts.

> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> 
> By the way, I wonder if it would make sense to handle this in the driver
> core. The prospect of copying this code in all drivers doesn't make me
> happy.

Indeed. But I wonder if it's always like this. E.g. a "wakeup" irq which 
is supposed to happen while the device is off.

  Tomi

>>>> +
>>>>    	status = rkisp1_read(rkisp1, RKISP1_CIF_MI_MIS);
>>>>    	if (!status)
>>>>    		return IRQ_NONE;
>>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
>>>> index 4b6b28c05b89..b757f75edecf 100644
>>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
>>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h
>>>> @@ -450,6 +450,7 @@ struct rkisp1_debug {
>>>>     * @debug:	   debug params to be exposed on debugfs
>>>>     * @info:	   version-specific ISP information
>>>>     * @irqs:          IRQ line numbers
>>>> + * @irqs_enabled:  the hardware is enabled and can cause interrupts
>>>>     */
>>>>    struct rkisp1_device {
>>>>    	void __iomem *base_addr;
>>>> @@ -471,6 +472,7 @@ struct rkisp1_device {
>>>>    	struct rkisp1_debug debug;
>>>>    	const struct rkisp1_info *info;
>>>>    	int irqs[RKISP1_NUM_IRQS];
>>>> +	bool irqs_enabled;
>>>>    };
>>>>    
>>>>    /*
>>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>>>> index b6e47e2f1b94..4202642e0523 100644
>>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
>>>> @@ -196,6 +196,9 @@ irqreturn_t rkisp1_csi_isr(int irq, void *ctx)
>>>>    	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>>>>    	u32 val, status;
>>>>    
>>>> +	if (!rkisp1->irqs_enabled)
>>>> +		return IRQ_NONE;
>>>> +
>>>>    	status = rkisp1_read(rkisp1, RKISP1_CIF_MIPI_MIS);
>>>>    	if (!status)
>>>>    		return IRQ_NONE;
>>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>>>> index acc559652d6e..73cf08a74011 100644
>>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>>>> @@ -305,6 +305,24 @@ static int __maybe_unused rkisp1_runtime_suspend(struct device *dev)
>>>>    {
>>>>    	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>>>>    
>>>> +	rkisp1->irqs_enabled = false;
>>>> +	/* Make sure the IRQ handler will see the above */
>>>> +	mb();
>>>> +
>>>> +	/*
>>>> +	 * Wait until any running IRQ handler has returned. The IRQ handler
>>>> +	 * may get called even after this (as it's a shared interrupt line)
>>>> +	 * but the 'irqs_enabled' flag will make the handler return immediately.
>>>> +	 */
>>>> +	for (unsigned int il = 0; il < ARRAY_SIZE(rkisp1->irqs); ++il) {
>>>> +		if (rkisp1->irqs[il] == -1)
>>>> +			continue;
>>>> +
>>>> +		/* Skip if the irq line is the same as previous */
>>>> +		if (il == 0 || rkisp1->irqs[il - 1] != rkisp1->irqs[il])
>>>> +			synchronize_irq(rkisp1->irqs[il]);
>>>> +	}
>>>> +
>>>>    	clk_bulk_disable_unprepare(rkisp1->clk_size, rkisp1->clks);
>>>>    	return pinctrl_pm_select_sleep_state(dev);
>>>>    }
>>>> @@ -321,6 +339,10 @@ static int __maybe_unused rkisp1_runtime_resume(struct device *dev)
>>>>    	if (ret)
>>>>    		return ret;
>>>>    
>>>> +	rkisp1->irqs_enabled = true;
>>>> +	/* Make sure the IRQ handler will see the above */
>>>> +	mb();
>>>> +
>>>>    	return 0;
>>>>    }
>>>>    
>>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>>>> index f00873d31c42..78a1f7a1499b 100644
>>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c
>>>> @@ -976,6 +976,9 @@ irqreturn_t rkisp1_isp_isr(int irq, void *ctx)
>>>>    	struct rkisp1_device *rkisp1 = dev_get_drvdata(dev);
>>>>    	u32 status, isp_err;
>>>>    
>>>> +	if (!rkisp1->irqs_enabled)
>>>> +		return IRQ_NONE;
>>>> +
>>>>    	status = rkisp1_read(rkisp1, RKISP1_CIF_ISP_MIS);
>>>>    	if (!status)
>>>>    		return IRQ_NONE;
> 



From suzuki.poulose at arm.com  Tue Dec 19 05:51:58 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 19 Dec 2023 13:51:58 +0000
Subject: [PATCH v3 6/8] coresight-tpdm: Add timestamp control register
 support for the CMB
In-Reply-To: <b61c3d70-7277-4fe7-ab67-8afc1062c737@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-7-git-send-email-quic_taozha@quicinc.com>
 <ebd7e310-d1b4-4b2e-a915-6241e04763d4@arm.com>
 <b61c3d70-7277-4fe7-ab67-8afc1062c737@quicinc.com>
Message-ID: <cdad425c-b965-44c7-a612-1c99341e95b9@arm.com>

On 19/12/2023 02:43, Tao Zhang wrote:
> 
> On 12/18/2023 6:46 PM, Suzuki K Poulose wrote:
>> On 21/11/2023 02:24, Tao Zhang wrote:
>>> CMB_TIER register is CMB subunit timestamp insertion enable register.
>>> Bit 0 is PATT_TSENAB bit. Set this bit to 1 to request a timestamp
>>> following a CMB interface pattern match. Bit 1 is XTRIG_TSENAB bit.
>>> Set this bit to 1 to request a timestamp following a CMB CTI timestamp
>>> request. Bit 2 is TS_ALL bit. Set this bit to 1 to request timestamp
>>> for all packets.
>>>
>>> Reviewed-by: James Clark <james.clark at arm.com>
>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
>>> ---
>>> ? .../testing/sysfs-bus-coresight-devices-tpdm? |? 35 ++++++
>>> ? drivers/hwtracing/coresight/coresight-tpdm.c? | 116 +++++++++++++++++-
>>> ? drivers/hwtracing/coresight/coresight-tpdm.h? |? 14 +++
>>> ? 3 files changed, 162 insertions(+), 3 deletions(-)
>>>
>>> diff --git 
>>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm 
>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>> index 53662ce7c2d0..e0b77107be13 100644
>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>> @@ -214,3 +214,38 @@ KernelVersion??? 6.7
>>> ? Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>> ? Description:
>>> ????????? (RW) Set/Get the mask of the pattern for the CMB subunit TPDM.
>>> +
>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
>>> +Date:??????? September 2023
>>> +KernelVersion??? 6.7
>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang 
>>> (QUIC) <quic_taozha at quicinc.com>
>>> +Description:
>>> +??????? (Write) Set the pattern timestamp of CMB tpdm. Read
>>> +??????? the pattern timestamp of CMB tpdm.
>>> +
>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>> +??????? 0 : Disable CMB pattern timestamp.
>>> +??????? 1 : Enable CMB pattern timestamp.
>>> +
>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
>>> +Date:??????? September 2023
>>> +KernelVersion??? 6.7
>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang 
>>> (QUIC) <quic_taozha at quicinc.com>
>>> +Description:
>>> +??????? (RW) Set/Get the trigger timestamp of the CMB for tpdm.
>>> +
>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>> +??????? 0 : Set the CMB trigger type to false
>>> +??????? 1 : Set the CMB trigger type to true
>>> +
>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
>>> +Date:??????? September 2023
>>> +KernelVersion??? 6.7
>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang 
>>> (QUIC) <quic_taozha at quicinc.com>
>>> +Description:
>>> +??????? (RW) Read or write the status of timestamp upon all interface.
>>> +??????? Only value 0 and 1? can be written to this node. Set this 
>>> node to 1 to requeset
>>> +??????? timestamp to all trace packet.
>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>> +??????? 0 : Disable the timestamp of all trace packets.
>>> +??????? 1 : Enable the timestamp of all trace packets.
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>>> index 894d4309f1c7..f6cda5616e84 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>> @@ -331,6 +331,36 @@ static void tpdm_enable_dsb(struct tpdm_drvdata 
>>> *drvdata)
>>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>>> ? }
>>> ? +static void set_cmb_tier(struct tpdm_drvdata *drvdata)
>>> +{
>>> +??? u32 val;
>>> +
>>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_TIER);
>>> +
>>> +??? /* Clear all relevant fields */
>>> +??? val &= ~(TPDM_CMB_TIER_PATT_TSENAB | TPDM_CMB_TIER_TS_ALL |
>>> +???????? TPDM_CMB_TIER_XTRIG_TSENAB);
>>> +
>>> +??? /* Set pattern timestamp type and enablement */
>>> +??? if (drvdata->cmb->patt_ts)
>>> +??????? val |= TPDM_CMB_TIER_PATT_TSENAB;
>>
>> ?-- cut --
>>> +??? else
>>> +??????? val &= ~TPDM_CMB_TIER_PATT_TSENAB;
>>
>>
>> All the else cases in this function are superfluous. Please remove all
>> of them.
> I will update this in the next patch.
>>
>>> +
>>> +??? /* Set trigger timestamp */
>>> +??? if (drvdata->cmb->trig_ts)
>>> +??????? val |= TPDM_CMB_TIER_XTRIG_TSENAB;
>>> +??? else
>>> +??????? val &= ~TPDM_CMB_TIER_XTRIG_TSENAB;
>>> +
>>> +??? /* Set all timestamp enablement*/
>>> +??? if (drvdata->cmb->ts_all)
>>> +??????? val |= TPDM_CMB_TIER_TS_ALL;
>>> +??? else
>>> +??????? val &= ~TPDM_CMB_TIER_TS_ALL;
>>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>>> +}
>>> +
>>> ? static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>>> ? {
>>> ????? u32 val, i;
>>> @@ -347,6 +377,8 @@ static void tpdm_enable_cmb(struct tpdm_drvdata 
>>> *drvdata)
>>> ????????????????? drvdata->base + TPDM_CMB_XPMR(i));
>>> ????? }
>>> ? +??? set_cmb_tier(drvdata);
>>> +
>>> ????? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>> ????? /*
>>> ?????? * Set to 0 for continuous CMB collection mode,
>>> @@ -695,9 +727,17 @@ static ssize_t enable_ts_show(struct device *dev,
>>> ??????????????????? char *buf)
>>> ? {
>>> ????? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +??? ssize_t size = 0;
>>> ? -??? return sysfs_emit(buf, "%u\n",
>>> -???????????? (unsigned int)drvdata->dsb->patt_ts);
>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>> +??????? size = sysfs_emit(buf, "%u\n",
>>> +???????????????? (unsigned int)drvdata->dsb->patt_ts);
>>> +
>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>> +??????? size = sysfs_emit(buf, "%u\n",
>>> +???????????????? (unsigned int)drvdata->cmb->patt_ts);
>>
>> Why does this need to show two values ? This must only show ONE value.
>> How you deduce that might be based on the availability of the feature
>> set. Or store the TS value in the drvdata and use that instead for
>> controlling CMB/DSB.
> 
> Since both of CMB/DSB need to have "enable_ts" SysFs file, can I 
> separate them

The question really is, do we need fine grained control. i.e.,

enable TS for DSB but not for CMB or vice versa.

I am not an expert on the usage scenario of the same. So, if you/Qcomm
thinks the users need separate, fine grained control for timestamp
for the DSB and CMB, then yes, follow your recommendation below.
i.e., tpdm.../dsb_patt/enable_ts

> as "enable_dsb_ts" and "enable_cmb_ts"? The path will be like below.
> 
> tpdm0/dsb_patt/enable_dsb_ts

You don't need enable_dsb_ts. It could be "enable_ts"

> 
> tpdm1/cmb_patt/enable_cmb_ts
> 
> Is this design appropriate?


Otherwise, stick to single enable_ts : which enables the ts for both
CMB/DSB. And it only ever show one value : 0 (TS is disabled for both
CMB/DSB) 1 : TS enabled for both.

Suzuki


>>

>> Also, the sysfs documentation needs update, if this is going to
>> control the CMB.
> 
> Sure. I will update the SysFs documentation according to the 
> modification in the
> 
> next patch series.
> 
> 
> Best,
> 
> Tao
> 
>>
>> Suzuki
>>
>>
>>> +
>>> +??? return size;
>>> ? }
>>> ? ? /*
>>> @@ -715,8 +755,13 @@ static ssize_t enable_ts_store(struct device *dev,
>>> ????????? return -EINVAL;
>>> ? ????? spin_lock(&drvdata->spinlock);
>>> -??? drvdata->dsb->patt_ts = !!val;
>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>> +??????? drvdata->dsb->patt_ts = !!val;
>>> +
>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>> +??????? drvdata->cmb->patt_ts = !!val;
>>> ????? spin_unlock(&drvdata->spinlock);
>>> +
>>> ????? return size;
>>> ? }
>>> ? static DEVICE_ATTR_RW(enable_ts);
>>> @@ -851,6 +896,68 @@ static ssize_t cmb_mode_store(struct device *dev,
>>> ? }
>>> ? static DEVICE_ATTR_RW(cmb_mode);
>>> ? +static ssize_t cmb_ts_all_show(struct device *dev,
>>> +?????????????????? struct device_attribute *attr,
>>> +?????????????????? char *buf)
>>> +{
>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +
>>> +??? return sysfs_emit(buf, "%u\n",
>>> +????????????? (unsigned int)drvdata->cmb->ts_all);
>>> +}
>>> +
>>> +static ssize_t cmb_ts_all_store(struct device *dev,
>>> +??????????????? struct device_attribute *attr,
>>> +??????????????? const char *buf,
>>> +??????????????? size_t size)
>>> +{
>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +??? unsigned long val;
>>> +
>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>> +??????? return -EINVAL;
>>> +
>>> +??? spin_lock(&drvdata->spinlock);
>>> +??? if (val)
>>> +??????? drvdata->cmb->ts_all = true;
>>> +??? else
>>> +??????? drvdata->cmb->ts_all = false;
>>> +??? spin_unlock(&drvdata->spinlock);
>>> +??? return size;
>>> +}
>>> +static DEVICE_ATTR_RW(cmb_ts_all);
>>> +
>>> +static ssize_t cmb_trig_ts_show(struct device *dev,
>>> +??????????????? struct device_attribute *attr,
>>> +??????????????? char *buf)
>>> +{
>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +
>>> +??? return sysfs_emit(buf, "%u\n",
>>> +????????????? (unsigned int)drvdata->cmb->trig_ts);
>>> +}
>>> +
>>> +static ssize_t cmb_trig_ts_store(struct device *dev,
>>> +???????????????? struct device_attribute *attr,
>>> +???????????????? const char *buf,
>>> +???????????????? size_t size)
>>> +{
>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +??? unsigned long val;
>>> +
>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>> +??????? return -EINVAL;
>>> +
>>> +??? spin_lock(&drvdata->spinlock);
>>> +??? if (val)
>>> +??????? drvdata->cmb->trig_ts = true;
>>> +??? else
>>> +??????? drvdata->cmb->trig_ts = false;
>>> +??? spin_unlock(&drvdata->spinlock);
>>> +??? return size;
>>> +}
>>> +static DEVICE_ATTR_RW(cmb_trig_ts);
>>> +
>>> ? static struct attribute *tpdm_dsb_edge_attrs[] = {
>>> ????? &dev_attr_ctrl_idx.attr,
>>> ????? &dev_attr_ctrl_val.attr,
>>> @@ -973,6 +1080,7 @@ static struct attribute *tpdm_cmb_patt_attrs[] = {
>>> ????? CMB_PATT_ATTR(1),
>>> ????? CMB_PATT_MASK_ATTR(0),
>>> ????? CMB_PATT_MASK_ATTR(1),
>>> +??? &dev_attr_enable_ts.attr,
>>> ????? NULL,
>>> ? };
>>> ? @@ -985,6 +1093,8 @@ static struct attribute *tpdm_dsb_attrs[] = {
>>> ? ? static struct attribute *tpdm_cmb_attrs[] = {
>>> ????? &dev_attr_cmb_mode.attr,
>>> +??? &dev_attr_cmb_ts_all.attr,
>>> +??? &dev_attr_cmb_trig_ts.attr,
>>> ????? NULL,
>>> ? };
>>> ? diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>>> index e90d008c1cb2..65b7ca6c4077 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>> @@ -11,6 +11,8 @@
>>> ? ? /* CMB Subunit Registers */
>>> ? #define TPDM_CMB_CR??????? (0xA00)
>>> +/*CMB subunit timestamp insertion enable register*/
>>> +#define TPDM_CMB_TIER??????? (0xA04)
>>> ? /*CMB subunit timestamp pattern registers*/
>>> ? #define TPDM_CMB_TPR(n)??????? (0xA08 + (n * 4))
>>> ? /*CMB subunit timestamp pattern mask registers*/
>>> @@ -24,6 +26,12 @@
>>> ? #define TPDM_CMB_CR_ENA??????? BIT(0)
>>> ? /* Trace collection mode for CMB subunit */
>>> ? #define TPDM_CMB_CR_MODE??? BIT(1)
>>> +/* Timestamp control for pattern match */
>>> +#define TPDM_CMB_TIER_PATT_TSENAB??? BIT(0)
>>> +/* CMB CTI timestamp request */
>>> +#define TPDM_CMB_TIER_XTRIG_TSENAB??? BIT(1)
>>> +/* For timestamp fo all trace */
>>> +#define TPDM_CMB_TIER_TS_ALL??????? BIT(2)
>>> ? ? /*Patten register number*/
>>> ? #define TPDM_CMB_MAX_PATT??????? 2
>>> @@ -217,6 +225,9 @@ struct dsb_dataset {
>>> ?? * @patt_mask:??????? Save value for pattern mask
>>> ?? * @trig_patt:??????? Save value for trigger pattern
>>> ?? * @trig_patt_mask:?? Save value for trigger pattern mask
>>> + * @patt_ts:????????? Indicates if pattern match for timestamp is 
>>> enabled.
>>> + * @trig_ts:????????? Indicates if CTI trigger for timestamp is 
>>> enabled.
>>> + * @ts_all:?????????? Indicates if timestamp is enabled for all 
>>> packets.
>>> ?? */
>>> ? struct cmb_dataset {
>>> ????? u32??????????? trace_mode;
>>> @@ -224,6 +235,9 @@ struct cmb_dataset {
>>> ????? u32??????????? patt_mask[TPDM_CMB_MAX_PATT];
>>> ????? u32??????????? trig_patt[TPDM_CMB_MAX_PATT];
>>> ????? u32??????????? trig_patt_mask[TPDM_CMB_MAX_PATT];
>>> +??? bool??????????? patt_ts;
>>> +??? bool??????????? trig_ts;
>>> +??? bool??????????? ts_all;
>>> ? };
>>> ? ? /**
>>



From suzuki.poulose at arm.com  Tue Dec 19 05:54:00 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 19 Dec 2023 13:54:00 +0000
Subject: [PATCH v3 2/8] coresight-tpda: Add support to configure CMB
 element
In-Reply-To: <b5965008-b51d-4bb7-8cf2-d21aa35d2205@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-3-git-send-email-quic_taozha@quicinc.com>
 <88e51407-344e-4584-8711-29cc014c782b@arm.com>
 <b5965008-b51d-4bb7-8cf2-d21aa35d2205@quicinc.com>
Message-ID: <fa39e477-7faf-46e4-8ae2-9eb2321afc26@arm.com>

On 19/12/2023 02:13, Tao Zhang wrote:
> 
> On 12/18/2023 6:27 PM, Suzuki K Poulose wrote:
>> On 21/11/2023 02:24, Tao Zhang wrote:
>>> Read the CMB element size from the device tree. Set the register
>>> bit that controls the CMB element size of the corresponding port.
>>>
>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>>> ---
>>> ? drivers/hwtracing/coresight/coresight-tpda.c | 117 +++++++++++--------
>>> ? drivers/hwtracing/coresight/coresight-tpda.h |?? 6 +
>>> ? 2 files changed, 74 insertions(+), 49 deletions(-)
>>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c 
>>> b/drivers/hwtracing/coresight/coresight-tpda.c
>>> index 5f82737c37bb..e3762f38abb3 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpda.c
>>> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
>>> @@ -28,24 +28,54 @@ static bool coresight_device_is_tpdm(struct 
>>> coresight_device *csdev)
>>> ????????????? CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM);
>>> ? }
>>> ? +static void tpdm_clear_element_size(struct coresight_device *csdev)
>>> +{
>>> +??? struct tpda_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>>> +
>>> +??? if (drvdata->dsb_esize)
>>> +??????? drvdata->dsb_esize = 0;
>>> +??? if (drvdata->cmb_esize)
>>> +??????? drvdata->cmb_esize = 0;
>>
>> Why do we need the if (...) check here ?
> 
> The element size of all the TPDM sub-unit should be set to 0 here.
> 
> I will update this in the next patch series.
> 
>>
>>> +}
>>> +
>>> +static void tpda_set_element_size(struct tpda_drvdata *drvdata, u32 
>>> *val)
>>> +{
>>> +
>>> +??? if (drvdata->dsb_esize == 64)
>>> +??????? *val |= TPDA_Pn_CR_DSBSIZE;
>>> +??? else if (drvdata->dsb_esize == 32)
>>> +??????? *val &= ~TPDA_Pn_CR_DSBSIZE;
>>> +
>>> +??? if (drvdata->cmb_esize == 64)
>>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x2);
>>> +??? else if (drvdata->cmb_esize == 32)
>>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x1);
>>> +??? else if (drvdata->cmb_esize == 8)
>>> +??????? *val &= ~TPDA_Pn_CR_CMBSIZE;
>>> +}
>>> +
>>
>>
>>> ? /*
>>> - * Read the DSB element size from the TPDM device
>>> + * Read the element size from the TPDM device
>>> ?? * Returns
>>> - *??? The dsb element size read from the devicetree if available.
>>> + *??? The element size read from the devicetree if available.
>>> ?? *??? 0 - Otherwise, with a warning once.
>>
>> This doesn't match the function ? It return 0 on success and
>> error (-EINVAL) on failure ?
> 
> 0 means the element size property is found from the devicetree.
> 
> Otherwise, it will return error(-EINVAL).
> 
> I will update this in the next patch series.
> 
>>
>>> ?? */
>>> -static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
>>> +static int tpdm_read_element_size(struct tpda_drvdata *drvdata,
>>> +????????????????? struct coresight_device *csdev)
>>> ? {
>>> -??? int rc = 0;
>>> -??? u8 size = 0;
>>> -
>>> -??? rc = fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>> -??????????? "qcom,dsb-element-size", &size);
>>> +??? int rc = -EINVAL;
>>> +
>>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>> +??????????? "qcom,dsb-element-size", &drvdata->dsb_esize))
>>> +??????? rc = 0;
>>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>> +??????????? "qcom,cmb-element-size", &drvdata->cmb_esize))
>>> +??????? rc = 0;
>>
>> Are we not silently resetting the error if the former failed ?
>>
>> Could we not :
>>
>> ????rc |= fwnode_...
>>
>> ????rc |= fwnode_...
>>
>> instead ?
>>
>> Also what is the expectation here ? Are these properties a MUST for
>> TPDM ?
> 
> The TPDM must have one of the element size property. As long as one

Please add a comment in the function. Someone else might try to "fix"
it otherwise.

Suzuki
> 
> can be found, this TPDM configuration can be considered valid. So this
> 
> function will return 0 if one of the element size property is found.


> 
> 
> Best,
> 
> Tao
> 
>>
>>> ????? if (rc)
>>> ????????? dev_warn_once(&csdev->dev,
>>> -??????????? "Failed to read TPDM DSB Element size: %d\n", rc);
>>> +??????????? "Failed to read TPDM Element size: %d\n", rc);
>>> ? -??? return size;
>>> +??? return rc;
>>> ? }
>>> ? ? /*
>>> @@ -56,11 +86,12 @@ static int tpdm_read_dsb_element_size(struct 
>>> coresight_device *csdev)
>>> ?? * Parameter "inport" is used to pass in the input port number
>>> ?? * of TPDA, and it is set to -1 in the recursize call.
>>> ?? */
>>> -static int tpda_get_element_size(struct coresight_device *csdev,
>>> +static int tpda_get_element_size(struct tpda_drvdata *drvdata,
>>> +???????????????? struct coresight_device *csdev,
>>> ?????????????????? int inport)
>>> ? {
>>> -??? int dsb_size = -ENOENT;
>>> -??? int i, size;
>>> +??? int rc = 0;
>>> +??? int i;
>>> ????? struct coresight_device *in;
>>> ? ????? for (i = 0; i < csdev->pdata->nr_inconns; i++) {
>>> @@ -74,25 +105,21 @@ static int tpda_get_element_size(struct 
>>> coresight_device *csdev,
>>> ????????????? continue;
>>> ? ????????? if (coresight_device_is_tpdm(in)) {
>>> -??????????? size = tpdm_read_dsb_element_size(in);
>>> +??????????? if ((drvdata->dsb_esize) || (drvdata->cmb_esize))
>>> +??????????????? return -EEXIST;
>>> +??????????? rc = tpdm_read_element_size(drvdata, in);
>>> +??????????? if (rc)
>>> +??????????????? return rc;
>>> ????????? } else {
>>> ????????????? /* Recurse down the path */
>>> -??????????? size = tpda_get_element_size(in, -1);
>>> -??????? }
>>> -
>>> -??????? if (size < 0)
>>> -??????????? return size;
>>> -
>>> -??????? if (dsb_size < 0) {
>>> -??????????? /* Found a size, save it. */
>>> -??????????? dsb_size = size;
>>> -??????? } else {
>>> -??????????? /* Found duplicate TPDMs */
>>> -??????????? return -EEXIST;
>>> +??????????? rc = tpda_get_element_size(drvdata, in, -1);
>>> +??????????? if (rc)
>>> +??????????????? return rc;
>>> ????????? }
>>> ????? }
>>> ? -??? return dsb_size;
>>> +
>>> +??? return rc;
>>> ? }
>>> ? ? /* Settings pre enabling port control register */
>>> @@ -109,7 +136,7 @@ static void tpda_enable_pre_port(struct 
>>> tpda_drvdata *drvdata)
>>> ? static int tpda_enable_port(struct tpda_drvdata *drvdata, int port)
>>> ? {
>>> ????? u32 val;
>>> -??? int size;
>>> +??? int rc;
>>> ? ????? val = readl_relaxed(drvdata->base + TPDA_Pn_CR(port));
>>> ????? /*
>>> @@ -117,29 +144,21 @@ static int tpda_enable_port(struct tpda_drvdata 
>>> *drvdata, int port)
>>> ?????? * Set the bit to 0 if the size is 32
>>> ?????? * Set the bit to 1 if the size is 64
>>> ?????? */
>>> -??? size = tpda_get_element_size(drvdata->csdev, port);
>>> -??? switch (size) {
>>> -??? case 32:
>>> -??????? val &= ~TPDA_Pn_CR_DSBSIZE;
>>> -??????? break;
>>> -??? case 64:
>>> -??????? val |= TPDA_Pn_CR_DSBSIZE;
>>> -??????? break;
>>> -??? case 0:
>>> -??????? return -EEXIST;
>>> -??? case -EEXIST:
>>> +??? tpdm_clear_element_size(drvdata->csdev);
>>> +??? rc = tpda_get_element_size(drvdata, drvdata->csdev, port);
>>> +??? if (!rc && ((drvdata->dsb_esize) || (drvdata->cmb_esize))) {
>>> +??????? tpda_set_element_size(drvdata, &val);
>>> +??????? /* Enable the port */
>>> +??????? val |= TPDA_Pn_CR_ENA;
>>> +??????? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>>> +??? } else if (rc == -EEXIST)
>>> ????????? dev_warn_once(&drvdata->csdev->dev,
>>> -??????????? "Detected multiple TPDMs on port %d", -EEXIST);
>>> -??????? return -EEXIST;
>>> -??? default:
>>> -??????? return -EINVAL;
>>> -??? }
>>> -
>>> -??? /* Enable the port */
>>> -??? val |= TPDA_Pn_CR_ENA;
>>> -??? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>>> +????????????????? "Detected multiple TPDMs on port %d", -EEXIST);
>>> +??? else
>>> +??????? dev_warn_once(&drvdata->csdev->dev,
>>> +????????????????? "Didn't find TPDM elem size");
>>
>> "element size"
>>
>>> ? -??? return 0;
>>> +??? return rc;
>>> ? }
>>> ? ? static int __tpda_enable(struct tpda_drvdata *drvdata, int port)
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.h 
>>> b/drivers/hwtracing/coresight/coresight-tpda.h
>>> index b3b38fd41b64..29164fd9711f 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpda.h
>>> +++ b/drivers/hwtracing/coresight/coresight-tpda.h
>>> @@ -10,6 +10,8 @@
>>> ? #define TPDA_Pn_CR(n)??????? (0x004 + (n * 4))
>>> ? /* Aggregator port enable bit */
>>> ? #define TPDA_Pn_CR_ENA??????? BIT(0)
>>> +/* Aggregator port CMB data set element size bit */
>>> +#define TPDA_Pn_CR_CMBSIZE??????? GENMASK(7, 6)
>>> ? /* Aggregator port DSB data set element size bit */
>>> ? #define TPDA_Pn_CR_DSBSIZE??????? BIT(8)
>>> ? @@ -25,6 +27,8 @@
>>> ?? * @csdev:????? component vitals needed by the framework.
>>> ?? * @spinlock:?? lock for the drvdata value.
>>> ?? * @enable:???? enable status of the component.
>>> + * @dsb_esize?? Record the DSB element size.
>>> + * @cmb_esize?? Record the CMB element size.
>>> ?? */
>>> ? struct tpda_drvdata {
>>> ????? void __iomem??????? *base;
>>> @@ -32,6 +36,8 @@ struct tpda_drvdata {
>>> ????? struct coresight_device??? *csdev;
>>> ????? spinlock_t??????? spinlock;
>>> ????? u8??????????? atid;
>>> +??? u8??????????? dsb_esize;
>>> +??? u8??????????? cmb_esize;
>>> ? };
>>> ? ? #endif? /* _CORESIGHT_CORESIGHT_TPDA_H */
>>
>> Suzuki
>>
>>



From suzuki.poulose at arm.com  Tue Dec 19 05:56:26 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 19 Dec 2023 13:56:26 +0000
Subject: [PATCH v3 3/8] coresight-tpdm: Add CMB dataset support
In-Reply-To: <8dcafd9a-ff90-439a-9337-fb957d2fcad1@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-4-git-send-email-quic_taozha@quicinc.com>
 <f4ed3577-f78b-4b78-b306-8284ccb96043@arm.com>
 <8dcafd9a-ff90-439a-9337-fb957d2fcad1@quicinc.com>
Message-ID: <df433a15-2698-4e1f-9d15-db52befb7541@arm.com>

On 19/12/2023 09:22, Tao Zhang wrote:
> 
> On 12/18/2023 6:34 PM, Suzuki K Poulose wrote:
>> On 21/11/2023 02:24, Tao Zhang wrote:
>>> CMB (continuous multi-bit) is one of TPDM's dataset type. CMB subunit
>>> can be enabled for data collection by writing 1 to the first bit of
>>> CMB_CR register. This change is to add enable/disable function for
>>> CMB dataset by writing CMB_CR register.
>>>
>>> Reviewed-by: James Clark <james.clark at arm.com>
>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
>>> ---
>>> ? drivers/hwtracing/coresight/coresight-tpdm.c | 31 ++++++++++++++++++++
>>> ? drivers/hwtracing/coresight/coresight-tpdm.h |? 8 +++++
>>> ? 2 files changed, 39 insertions(+)
>>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>>> index 97654aa4b772..c8bb38822e08 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>> @@ -131,6 +131,11 @@ static bool tpdm_has_dsb_dataset(struct 
>>> tpdm_drvdata *drvdata)
>>> ????? return (drvdata->datasets & TPDM_PIDR0_DS_DSB);
>>> ? }
>>> ? +static bool tpdm_has_cmb_dataset(struct tpdm_drvdata *drvdata)
>>> +{
>>> +??? return (drvdata->datasets & TPDM_PIDR0_DS_CMB);
>>> +}
>>> +
>>> ? static umode_t tpdm_dsb_is_visible(struct kobject *kobj,
>>> ???????????????????? struct attribute *attr, int n)
>>> ? {
>>> @@ -267,6 +272,17 @@ static void tpdm_enable_dsb(struct tpdm_drvdata 
>>> *drvdata)
>>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>>> ? }
>>> ? +static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>>> +{
>>> +??? u32 val;
>>> +
>>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>> +??? val |= TPDM_CMB_CR_ENA;
>>> +
>>> +??? /* Set the enable bit of CMB control register to 1 */
>>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
>>> +}
>>> +
>>> ? /*
>>> ?? * TPDM enable operations
>>> ?? * The TPDM or Monitor serves as data collection component for various
>>> @@ -281,6 +297,8 @@ static void __tpdm_enable(struct tpdm_drvdata 
>>> *drvdata)
>>> ? ????? if (tpdm_has_dsb_dataset(drvdata))
>>> ????????? tpdm_enable_dsb(drvdata);
>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>> +??????? tpdm_enable_cmb(drvdata);
>>
>> Don't we need to add this check in the "property read" section ?
>> Otherwise, we could generate warnings unnecessarily ?
>>
>> i.e, if (tpdm_has_cmb_..())
>> ????? rc |= fwnode_..read_property(cmb-elem-size...)
>>
>> Similarly for DSB.
> 
> TPDM and TPDA are two independent hardware. If you want to modify them 
> in this way, the
> 

You don't have to, as long as the header files are included ?

Read my response in the other patch, where it applies.

Suzuki

> two independent drivers will be coupled to each other. At the same time, 
> this configuration
> 
> is manually set in the devicetree by the users, and this check cannot 
> avoid manual setting errors.
> 
>  ?Even if the configuration is wrong, it will not cause the driver to 
> stop working, it will only cause
> 
> the data to be lost from the TPDM.
> 
>>
>>> ????? CS_LOCK(drvdata->base);
>>> ? }
>>> @@ -314,6 +332,17 @@ static void tpdm_disable_dsb(struct tpdm_drvdata 
>>> *drvdata)
>>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>>> ? }
>>> ? +static void tpdm_disable_cmb(struct tpdm_drvdata *drvdata)
>>> +{
>>> +??? u32 val;
>>> +
>>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>> +??? val &= ~TPDM_CMB_CR_ENA;
>>> +
>>> +??? /* Set the enable bit of CMB control register to 0 */
>>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
>>> +}
>>> +
>>> ? /* TPDM disable operations */
>>> ? static void __tpdm_disable(struct tpdm_drvdata *drvdata)
>>> ? {
>>> @@ -321,6 +350,8 @@ static void __tpdm_disable(struct tpdm_drvdata 
>>> *drvdata)
>>> ? ????? if (tpdm_has_dsb_dataset(drvdata))
>>> ????????? tpdm_disable_dsb(drvdata);
>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>> +??????? tpdm_disable_cmb(drvdata);
>>
>> minor nit: Instead of having these :
>>
>> ????if (tpdm_has_XY_()
>> ??????? tpdm_{enable/disable}_XY_()
>> I prefer :
>>
>> ????tpdm_{enable/disable}_XY_
>>
>> and the helper take care of returning early if the feature is
>> not present.
> Does the following sample modification meet your expectation?
> static void tpdm_disable_dsb(struct tpdm_drvdata *drvdata)
> {
>  ?? ?u32 val;
> 
>  ?? ?if (tpdm_has_dsb_dataset(drvdata)) {
>  ?? ???? /* Set the enable bit of DSB control register to 0 */
>  ?? ???? val = readl_relaxed(drvdata->base + TPDM_DSB_CR);
>  ?? ???? val &= ~TPDM_DSB_CR_ENA;
>  ?? ???? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>  ?? ?}
> }
> 
> static void tpdm_disable_cmb(struct tpdm_drvdata *drvdata)
> {
>  ?? ?u32 val;
> 
>  ?? ?if (tpdm_has_cmb_dataset(drvdata)) {
>  ?? ???? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>  ?? ???? val &= ~TPDM_CMB_CR_ENA;
> 
>  ?? ???? /* Set the enable bit of CMB control register to 0 */
>  ?? ???? writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
>  ?? ?}
> }
> 
> /* TPDM disable operations */
> static void __tpdm_disable(struct tpdm_drvdata *drvdata)
> {
>  ?? ?CS_UNLOCK(drvdata->base);
> 
>  ?? ?tpdm_disable_dsb(drvdata);
>  ?? ?tpdm_disable_cmb(drvdata);
> 

Yes, thats exactly I was looking for.

>  ?? ?CS_LOCK(drvdata->base);
> 
> }
> 
> 
> Best,
> 
> Tao
> 
>>
>>
>> Suzuki
>>
>>
>>> ? ????? CS_LOCK(drvdata->base);
>>> ? }
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>>> index 4115b2a17b8d..0098c58dfdd6 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>> @@ -9,6 +9,12 @@
>>> ? /* The max number of the datasets that TPDM supports */
>>> ? #define TPDM_DATASETS?????? 7
>>> ? +/* CMB Subunit Registers */
>>> +#define TPDM_CMB_CR??????? (0xA00)
>>> +
>>> +/* Enable bit for CMB subunit */
>>> +#define TPDM_CMB_CR_ENA??????? BIT(0)
>>> +
>>> ? /* DSB Subunit Registers */
>>> ? #define TPDM_DSB_CR??????? (0x780)
>>> ? #define TPDM_DSB_TIER??????? (0x784)
>>> @@ -79,10 +85,12 @@
>>> ?? *
>>> ?? * PERIPHIDR0[0] : Fix to 1 if ImplDef subunit present, else 0
>>> ?? * PERIPHIDR0[1] : Fix to 1 if DSB subunit present, else 0
>>> + * PERIPHIDR0[2] : Fix to 1 if CMB subunit present, else 0
>>> ?? */
>>> ? ? #define TPDM_PIDR0_DS_IMPDEF??? BIT(0)
>>> ? #define TPDM_PIDR0_DS_DSB??? BIT(1)
>>> +#define TPDM_PIDR0_DS_CMB??? BIT(2)
>>> ? ? #define TPDM_DSB_MAX_LINES??? 256
>>> ? /* MAX number of EDCR registers */
>>



From suzuki.poulose at arm.com  Tue Dec 19 05:59:30 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 19 Dec 2023 13:59:30 +0000
Subject: [PATCH v3 2/8] coresight-tpda: Add support to configure CMB
 element
In-Reply-To: <88e51407-344e-4584-8711-29cc014c782b@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-3-git-send-email-quic_taozha@quicinc.com>
 <88e51407-344e-4584-8711-29cc014c782b@arm.com>
Message-ID: <987a101d-043e-4893-89c0-f9fcd46b5aeb@arm.com>

On 18/12/2023 10:27, Suzuki K Poulose wrote:
> On 21/11/2023 02:24, Tao Zhang wrote:
>> Read the CMB element size from the device tree. Set the register
>> bit that controls the CMB element size of the corresponding port.
>>
>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>> ---
>> ? drivers/hwtracing/coresight/coresight-tpda.c | 117 +++++++++++--------
>> ? drivers/hwtracing/coresight/coresight-tpda.h |?? 6 +
>> ? 2 files changed, 74 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c 
>> b/drivers/hwtracing/coresight/coresight-tpda.c
>> index 5f82737c37bb..e3762f38abb3 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpda.c
>> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
>> @@ -28,24 +28,54 @@ static bool coresight_device_is_tpdm(struct 
>> coresight_device *csdev)
>> ????????????? CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM);
>> ? }
>> +static void tpdm_clear_element_size(struct coresight_device *csdev)
>> +{
>> +??? struct tpda_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> +
>> +??? if (drvdata->dsb_esize)
>> +??????? drvdata->dsb_esize = 0;
>> +??? if (drvdata->cmb_esize)
>> +??????? drvdata->cmb_esize = 0;
> 
> Why do we need the if (...) check here ?
> 
>> +}
>> +
>> +static void tpda_set_element_size(struct tpda_drvdata *drvdata, u32 
>> *val)
>> +{
>> +
>> +??? if (drvdata->dsb_esize == 64)
>> +??????? *val |= TPDA_Pn_CR_DSBSIZE;
>> +??? else if (drvdata->dsb_esize == 32)
>> +??????? *val &= ~TPDA_Pn_CR_DSBSIZE;
>> +
>> +??? if (drvdata->cmb_esize == 64)
>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x2);
>> +??? else if (drvdata->cmb_esize == 32)
>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x1);
>> +??? else if (drvdata->cmb_esize == 8)
>> +??????? *val &= ~TPDA_Pn_CR_CMBSIZE;
>> +}
>> +
> 
> 
>> ? /*
>> - * Read the DSB element size from the TPDM device
>> + * Read the element size from the TPDM device
>> ?? * Returns
>> - *??? The dsb element size read from the devicetree if available.
>> + *??? The element size read from the devicetree if available.
>> ?? *??? 0 - Otherwise, with a warning once.
> 
> This doesn't match the function ? It return 0 on success and
> error (-EINVAL) on failure ?
> 
>> ?? */
>> -static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
>> +static int tpdm_read_element_size(struct tpda_drvdata *drvdata,
>> +????????????????? struct coresight_device *csdev)
>> ? {
>> -??? int rc = 0;
>> -??? u8 size = 0;
>> -
>> -??? rc = fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>> -??????????? "qcom,dsb-element-size", &size);
>> +??? int rc = -EINVAL;
>> +
>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>> +??????????? "qcom,dsb-element-size", &drvdata->dsb_esize))
>> +??????? rc = 0;
>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>> +??????????? "qcom,cmb-element-size", &drvdata->cmb_esize))

At this point we have the csdev->dev.parent as the TPDM device and with:

#include <coresight-tpdm.h>

	struct tpdm_drvdata *tpdm_data = get_drvdata(csdev->dev.parent);

	if (tpdm_has_cmb(tpdm_data)) {
		rc = fwnode_...(... "qcom,cmb-element-size"...)
	}

	if (tpdm_has_dsb(tpdm_data)) {
		rc = fwnode_...(..., "qcom,dsb-element-size"..)
	}

Suzuki


>> +??????? rc = 0;
> 
> Are we not silently resetting the error if the former failed ?
> 
> Could we not :
> 
>  ????rc |= fwnode_...
> 
>  ????rc |= fwnode_...
> 
> instead ?
> 
> Also what is the expectation here ? Are these properties a MUST for
> TPDM ?
> 
>> ????? if (rc)
>> ????????? dev_warn_once(&csdev->dev,
>> -??????????? "Failed to read TPDM DSB Element size: %d\n", rc);
>> +??????????? "Failed to read TPDM Element size: %d\n", rc);
>> -??? return size;
>> +??? return rc;
>> ? }
>> ? /*
>> @@ -56,11 +86,12 @@ static int tpdm_read_dsb_element_size(struct 
>> coresight_device *csdev)
>> ?? * Parameter "inport" is used to pass in the input port number
>> ?? * of TPDA, and it is set to -1 in the recursize call.
>> ?? */
>> -static int tpda_get_element_size(struct coresight_device *csdev,
>> +static int tpda_get_element_size(struct tpda_drvdata *drvdata,
>> +???????????????? struct coresight_device *csdev,
>> ?????????????????? int inport)
>> ? {
>> -??? int dsb_size = -ENOENT;
>> -??? int i, size;
>> +??? int rc = 0;
>> +??? int i;
>> ????? struct coresight_device *in;
>> ????? for (i = 0; i < csdev->pdata->nr_inconns; i++) {
>> @@ -74,25 +105,21 @@ static int tpda_get_element_size(struct 
>> coresight_device *csdev,
>> ????????????? continue;
>> ????????? if (coresight_device_is_tpdm(in)) {
>> -??????????? size = tpdm_read_dsb_element_size(in);
>> +??????????? if ((drvdata->dsb_esize) || (drvdata->cmb_esize))
>> +??????????????? return -EEXIST;
>> +??????????? rc = tpdm_read_element_size(drvdata, in);
>> +??????????? if (rc)
>> +??????????????? return rc;
>> ????????? } else {
>> ????????????? /* Recurse down the path */
>> -??????????? size = tpda_get_element_size(in, -1);
>> -??????? }
>> -
>> -??????? if (size < 0)
>> -??????????? return size;
>> -
>> -??????? if (dsb_size < 0) {
>> -??????????? /* Found a size, save it. */
>> -??????????? dsb_size = size;
>> -??????? } else {
>> -??????????? /* Found duplicate TPDMs */
>> -??????????? return -EEXIST;
>> +??????????? rc = tpda_get_element_size(drvdata, in, -1);
>> +??????????? if (rc)
>> +??????????????? return rc;
>> ????????? }
>> ????? }
>> -??? return dsb_size;
>> +
>> +??? return rc;
>> ? }
>> ? /* Settings pre enabling port control register */
>> @@ -109,7 +136,7 @@ static void tpda_enable_pre_port(struct 
>> tpda_drvdata *drvdata)
>> ? static int tpda_enable_port(struct tpda_drvdata *drvdata, int port)
>> ? {
>> ????? u32 val;
>> -??? int size;
>> +??? int rc;
>> ????? val = readl_relaxed(drvdata->base + TPDA_Pn_CR(port));
>> ????? /*
>> @@ -117,29 +144,21 @@ static int tpda_enable_port(struct tpda_drvdata 
>> *drvdata, int port)
>> ?????? * Set the bit to 0 if the size is 32
>> ?????? * Set the bit to 1 if the size is 64
>> ?????? */
>> -??? size = tpda_get_element_size(drvdata->csdev, port);
>> -??? switch (size) {
>> -??? case 32:
>> -??????? val &= ~TPDA_Pn_CR_DSBSIZE;
>> -??????? break;
>> -??? case 64:
>> -??????? val |= TPDA_Pn_CR_DSBSIZE;
>> -??????? break;
>> -??? case 0:
>> -??????? return -EEXIST;
>> -??? case -EEXIST:
>> +??? tpdm_clear_element_size(drvdata->csdev);
>> +??? rc = tpda_get_element_size(drvdata, drvdata->csdev, port);
>> +??? if (!rc && ((drvdata->dsb_esize) || (drvdata->cmb_esize))) {
>> +??????? tpda_set_element_size(drvdata, &val);
>> +??????? /* Enable the port */
>> +??????? val |= TPDA_Pn_CR_ENA;
>> +??????? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>> +??? } else if (rc == -EEXIST)
>> ????????? dev_warn_once(&drvdata->csdev->dev,
>> -??????????? "Detected multiple TPDMs on port %d", -EEXIST);
>> -??????? return -EEXIST;
>> -??? default:
>> -??????? return -EINVAL;
>> -??? }
>> -
>> -??? /* Enable the port */
>> -??? val |= TPDA_Pn_CR_ENA;
>> -??? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>> +????????????????? "Detected multiple TPDMs on port %d", -EEXIST);
>> +??? else
>> +??????? dev_warn_once(&drvdata->csdev->dev,
>> +????????????????? "Didn't find TPDM elem size");
> 
> "element size"
> 
>> -??? return 0;
>> +??? return rc;
>> ? }
>> ? static int __tpda_enable(struct tpda_drvdata *drvdata, int port)
>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.h 
>> b/drivers/hwtracing/coresight/coresight-tpda.h
>> index b3b38fd41b64..29164fd9711f 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpda.h
>> +++ b/drivers/hwtracing/coresight/coresight-tpda.h
>> @@ -10,6 +10,8 @@
>> ? #define TPDA_Pn_CR(n)??????? (0x004 + (n * 4))
>> ? /* Aggregator port enable bit */
>> ? #define TPDA_Pn_CR_ENA??????? BIT(0)
>> +/* Aggregator port CMB data set element size bit */
>> +#define TPDA_Pn_CR_CMBSIZE??????? GENMASK(7, 6)
>> ? /* Aggregator port DSB data set element size bit */
>> ? #define TPDA_Pn_CR_DSBSIZE??????? BIT(8)
>> @@ -25,6 +27,8 @@
>> ?? * @csdev:????? component vitals needed by the framework.
>> ?? * @spinlock:?? lock for the drvdata value.
>> ?? * @enable:???? enable status of the component.
>> + * @dsb_esize?? Record the DSB element size.
>> + * @cmb_esize?? Record the CMB element size.
>> ?? */
>> ? struct tpda_drvdata {
>> ????? void __iomem??????? *base;
>> @@ -32,6 +36,8 @@ struct tpda_drvdata {
>> ????? struct coresight_device??? *csdev;
>> ????? spinlock_t??????? spinlock;
>> ????? u8??????????? atid;
>> +??? u8??????????? dsb_esize;
>> +??? u8??????????? cmb_esize;
>> ? };
>> ? #endif? /* _CORESIGHT_CORESIGHT_TPDA_H */
> 
> Suzuki
> 
> 



From quic_bibekkum at quicinc.com  Tue Dec 19 05:59:42 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 19:29:42 +0530
Subject: [PATCH v5 0/5] iommu/arm-smmu: introduction of ACTLR implementation for Qualcomm SoCs
Message-ID: <20231219135947.1623-1-quic_bibekkum@quicinc.com>

This patch series consist of five parts and covers the following:

1. Re-enable context caching for Qualcomm SoCs to retain prefetcher
   settings during reset and runtime suspend.

2. Remove cfg inside qcom_smmu structure and replace it with single
   pointer to qcom_smmu_match_data avoiding replication of multiple
   members from same.

3. Introduce intital set of driver changes to implement ACTLR register
   for custom prefetcher settings in Qualcomm SoCs.

4. Add ACTLR data and implementation operations for SM8550.

5. Add ACTLR data and implementation operations for SC7280.

Changes in v5 from v4:
 New addition:
 - Modify copyright year in arm-smmu-qcom.h to 2023 from 2022.
 Changes to incorporate suggestions from Dmitry as follows:
 - Modify the defines for prefetch in (foo << bar) format
   as suggested.(FIELD_PREP could not be used in defines
   is not inside any block/function)
 Changes to incorporate suggestions from Konrad as follows:
 - Shift context caching enablement patch as 1/5 instead of 5/5 to
   be picked up as independent patch.
 - Fix the codestyle to orient variables in reverse xmas tree format
   for patch 1/5.
 - Fix variable name in patch 1/5 as suggested.
 - evaluate for return check (Return check is not needed for
   arm_mmu500_reset, 0 being only return val).
 Link to v3:
https://lore.kernel.org/all/20231215101827.30549-1-quic_bibekkum at quicinc.com/

Changes in v4 from v3:
 New addition:
 - Remove actlrcfg_size and use NULL end element instead to traverse
   the actlr table, as this would be a cleaner approach by removing
   redundancy of actlrcfg_size.
 - Renaming of actlr set function to arm_smmu_qcom based proprietary
   convention.
 - break from loop once sid is found and ACTLR value is initialized
   in qcom_smmu_set_actlr.
 - Modify the GFX prefetch value separating into 2 sensible defines.
 - Modify comments for prefetch defines as per SMMU-500 TRM.
 Changes to incorporate suggestions from Konrad as follows:
 - Use Reverse-Christmas-tree sorting wherever applicable.
 - Pass arguments directly to arm_smmu_set_actlr instead of creating
   duplicate variables.
 - Use array indexing instead of direct pointer addressed by new
   addition of eliminating actlrcfg_size.
 - Switch the HEX value's case from upper to lower case in SC7280
   actlrcfg table.
 Changes to incorporate suggestions from Dmitry as follows:
 - Separate changes not related to ACTLR support to different commit
   with patch 5/5.
 - Using pointer to struct for arguments in smr_is_subset().
 Changes to incorporate suggestions from Bjorn as follows:
 - fix the commit message for patch 2/5 to properly document the
   value space to avoid confusion.
 Fixed build issues reported by kernel test robot [1] for
 arm64-allyesconfig [2].
 [1]: https://lore.kernel.org/all/202312011750.Pwca3TWE-lkp at intel.com/
 [2]: https://download.01.org/0day-ci/archive/20231201/202312011750.Pwca3TWE-lkp at intel.com/config
 Link to v3:
https://lore.kernel.org/all/20231127145412.3981-1-quic_bibekkum at quicinc.com/

Changes in v3 from v2:
 New addition:
 - Include patch 3/4 for adding ACTLR support and data for SC7280.
 - Add driver changes for actlr support in gpu smmu.
 - Add target wise actlr data and implementation ops for gpu smmu.
 Changes to incorporate suggestions from Robin as follows:
 - Match the ACTLR values with individual corresponding SID instead
   of assuming that any SMR will be programmed to match a superset of
   the data.
 - Instead of replicating each elements from qcom_smmu_match_data to
   qcom_smmu structre during smmu device creation, replace the
   replicated members with qcom_smmu_match_data structure inside
   qcom_smmu structre and handle the dereference in places that
   requires them.
 Changes to incorporate suggestions from Dmitry and Konrad as follows:
 - Maintain actlr table inside a single structure instead of
   nested structure.
 - Rename prefetch defines to more appropriately describe their behavior.
 - Remove SM8550 specific implementation ops and roll back to default
   qcom_smmu_500_impl implementation ops.
 - Add back the removed comments which are NAK.
 - Fix commit description for patch 4/4.
 Link to v2:
https://lore.kernel.org/all/20231114135654.30475-1-quic_bibekkum at quicinc.com/

Changes in v2 from v1:
 - Incorporated suggestions on v1 from Dmitry,Konrad,Pratyush.
 - Added defines for ACTLR values.
 - Linked sm8550 implementation structure to corresponding
   compatible string.
 - Repackaged actlr value set implementation to separate function.
 - Fixed indentation errors.
 - Link to v1:
https://lore.kernel.org/all/20231103215124.1095-1-quic_bibekkum at quicinc.com/

Changes in v1 from RFC:
 - Incorporated suggestion form Robin on RFC
 - Moved the actlr data table into driver, instead of maintaining
   it inside soc specific DT and piggybacking on exisiting iommus
   property (iommu = <SID, MASK, ACTLR>) to set this value during
   smmu probe.
 - Link to RFC:
https://lore.kernel.org/all/a01e7e60-6ead-4a9e-ba90-22a8a6bbd03f at quicinc.com/

Bibek Kumar Patro (5):
  iommu/arm-smmu: re-enable context caching in smmu reset operation
  iommu/arm-smmu: refactor qcom_smmu structure to include single pointer
  iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings
  iommu/arm-smmu: add ACTLR data and support for SM8550
  iommu/arm-smmu: add ACTLR data and support for SC7280

 .../iommu/arm/arm-smmu/arm-smmu-qcom-debug.c  |   2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c    | 185 +++++++++++++++++-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h    |   8 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.c         |   5 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.h         |   5 +
 5 files changed, 195 insertions(+), 10 deletions(-)

--
2.17.1



From quic_bibekkum at quicinc.com  Tue Dec 19 05:59:43 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 19:29:43 +0530
Subject: [PATCH v5 1/5] iommu/arm-smmu: re-enable context caching in smmu reset operation
In-Reply-To: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
References: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
Message-ID: <20231219135947.1623-2-quic_bibekkum@quicinc.com>

Default MMU-500 reset operation disables context caching in
prefetch buffer. It is however expected for context banks using
the ACTLR register to retain their prefetch value during reset
and runtime suspend.

Replace default MMU-500 reset operation with Qualcomm specific reset
operation which envelope the default reset operation and re-enables
context caching in prefetch buffer for Qualcomm SoCs.

Suggested-by: Konrad Dybcio <konrad.dybcio at linaro.org>
Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 33 ++++++++++++++++++++--
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 549ae4dba3a6..225a53486307 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -14,6 +14,16 @@

 #define QCOM_DUMMY_VAL	-1

+/*
+ * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
+ * macro TLB) and BIT(1) as CPRE (Enable context caching in the prefetch
+ * buffer). The remaining bits are implementation defined and vary across
+ * SoCs.
+ */
+
+#define CPRE			(1 << 1)
+#define CMTLB			(1 << 0)
+
 static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
 {
 	return container_of(smmu, struct qcom_smmu, smmu);
@@ -376,11 +386,28 @@ static int qcom_smmu_def_domain_type(struct device *dev)
 	return match ? IOMMU_DOMAIN_IDENTITY : 0;
 }

+static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
+{
+	u32 val;
+	int i;
+
+	arm_mmu500_reset(smmu);
+
+	/* arm_mmu500_reset() disables CPRE which is re-enabled here */
+	for (i = 0; i < smmu->num_context_banks; ++i) {
+		val = arm_smmu_cb_read(smmu, i, ARM_SMMU_CB_ACTLR);
+		val |= CPRE;
+		arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_ACTLR, val);
+	}
+
+	return 0;
+}
+
 static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
 {
 	int ret;

-	arm_mmu500_reset(smmu);
+	qcom_smmu500_reset(smmu);

 	/*
 	 * To address performance degradation in non-real time clients,
@@ -407,7 +434,7 @@ static const struct arm_smmu_impl qcom_smmu_500_impl = {
 	.init_context = qcom_smmu_init_context,
 	.cfg_probe = qcom_smmu_cfg_probe,
 	.def_domain_type = qcom_smmu_def_domain_type,
-	.reset = arm_mmu500_reset,
+	.reset = qcom_smmu500_reset,
 	.write_s2cr = qcom_smmu_write_s2cr,
 	.tlb_sync = qcom_smmu_tlb_sync,
 };
@@ -432,7 +459,7 @@ static const struct arm_smmu_impl qcom_adreno_smmu_v2_impl = {
 static const struct arm_smmu_impl qcom_adreno_smmu_500_impl = {
 	.init_context = qcom_adreno_smmu_init_context,
 	.def_domain_type = qcom_smmu_def_domain_type,
-	.reset = arm_mmu500_reset,
+	.reset = qcom_smmu500_reset,
 	.alloc_context_bank = qcom_adreno_smmu_alloc_context_bank,
 	.write_sctlr = qcom_adreno_smmu_write_sctlr,
 	.tlb_sync = qcom_smmu_tlb_sync,
--
2.17.1



From quic_bibekkum at quicinc.com  Tue Dec 19 05:59:44 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 19:29:44 +0530
Subject: [PATCH v5 2/5] iommu/arm-smmu: refactor qcom_smmu structure to include single pointer
In-Reply-To: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
References: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
Message-ID: <20231219135947.1623-3-quic_bibekkum@quicinc.com>

qcom_smmu_match_data is static and constant so refactor qcom_smmu
to store single pointer to qcom_smmu_match_data instead of
replicating multiple child members of the same and handle the further
dereferences in the places that want them.

Suggested-by: Robin Murphy <robin.murphy at arm.com>
Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c       | 2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h       | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
index bb89d49adf8d..e9798b133cbb 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
@@ -22,7 +22,7 @@ void qcom_smmu_tlb_sync_debug(struct arm_smmu_device *smmu)
 	if (__ratelimit(&rs)) {
 		dev_err(smmu->dev, "TLB sync timed out -- SMMU may be deadlocked\n");

-		cfg = qsmmu->cfg;
+		cfg = qsmmu->data->cfg;
 		if (!cfg)
 			return;

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 225a53486307..6af2c8b1ed3d 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -492,7 +492,7 @@ static struct arm_smmu_device *qcom_smmu_create(struct arm_smmu_device *smmu,
 		return ERR_PTR(-ENOMEM);

 	qsmmu->smmu.impl = impl;
-	qsmmu->cfg = data->cfg;
+	qsmmu->data = data;

 	return &qsmmu->smmu;
 }
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
index 593910567b88..f3b91963e234 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
@@ -8,7 +8,7 @@

 struct qcom_smmu {
 	struct arm_smmu_device smmu;
-	const struct qcom_smmu_config *cfg;
+	const struct qcom_smmu_match_data *data;
 	bool bypass_quirk;
 	u8 bypass_cbndx;
 	u32 stall_enabled;
--
2.17.1



From quic_bibekkum at quicinc.com  Tue Dec 19 05:59:45 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 19:29:45 +0530
Subject: [PATCH v5 3/5] iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings
In-Reply-To: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
References: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
Message-ID: <20231219135947.1623-4-quic_bibekkum@quicinc.com>

Currently in Qualcomm  SoCs the default prefetch is set to 1 which allows
the TLB to fetch just the next page table. MMU-500 features ACTLR
register which is implementation defined and is used for Qualcomm SoCs
to have a custom prefetch setting enabling TLB to prefetch the next set
of page tables accordingly allowing for faster translations.

ACTLR value is unique for each SMR (Stream matching register) and stored
in a pre-populated table. This value is set to the register during
context bank initialisation.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 45 ++++++++++++++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h |  6 ++-
 drivers/iommu/arm/arm-smmu/arm-smmu.c      |  5 ++-
 drivers/iommu/arm/arm-smmu/arm-smmu.h      |  5 +++
 4 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 6af2c8b1ed3d..b3cd585abf87 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -24,6 +24,12 @@
 #define CPRE			(1 << 1)
 #define CMTLB			(1 << 0)

+struct actlr_config {
+	u16 sid;
+	u16 mask;
+	u32 actlr;
+};
+
 static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
 {
 	return container_of(smmu, struct qcom_smmu, smmu);
@@ -215,9 +221,38 @@ static bool qcom_adreno_can_do_ttbr1(struct arm_smmu_device *smmu)
 	return true;
 }

+static void qcom_smmu_set_actlr(struct device *dev, struct arm_smmu_device *smmu, int cbndx,
+		const struct actlr_config *actlrcfg)
+{
+	struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
+	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+	struct arm_smmu_smr *smr;
+	u16 mask;
+	int idx;
+	u16 id;
+	int i;
+
+	for (; actlrcfg->sid || actlrcfg->mask || actlrcfg->actlr; actlrcfg++) {
+		id = actlrcfg->sid;
+		mask = actlrcfg->mask;
+
+		for_each_cfg_sme(cfg, fwspec, i, idx) {
+			smr = &smmu->smrs[idx];
+			if (smr_is_subset(smr, id, mask)) {
+				arm_smmu_cb_write(smmu, cbndx, ARM_SMMU_CB_ACTLR,
+						actlrcfg->actlr);
+				break;
+			}
+		}
+	}
+}
+
 static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 		struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
 {
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+	int cbndx = smmu_domain->cfg.cbndx;
 	struct adreno_smmu_priv *priv;

 	smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
@@ -248,6 +283,9 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 	priv->set_stall = qcom_adreno_smmu_set_stall;
 	priv->resume_translation = qcom_adreno_smmu_resume_translation;

+	if (qsmmu->data->actlrcfg_gfx)
+		qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg_gfx);
+
 	return 0;
 }

@@ -274,6 +312,13 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
 static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 		struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
 {
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+	int cbndx = smmu_domain->cfg.cbndx;
+
+	if (qsmmu->data->actlrcfg)
+		qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg);
+
 	smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;

 	return 0;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
index f3b91963e234..cb4cb402c202 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
  */

 #ifndef _ARM_SMMU_QCOM_H
@@ -24,7 +24,11 @@ struct qcom_smmu_config {
 	const u32 *reg_offset;
 };

+struct actlr_config;
+
 struct qcom_smmu_match_data {
+	const struct actlr_config *actlrcfg;
+	const struct actlr_config *actlrcfg_gfx;
 	const struct qcom_smmu_config *cfg;
 	const struct arm_smmu_impl *impl;
 	const struct arm_smmu_impl *adreno_impl;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d6d1a2a55cc0..0c7f700b27dd 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -990,9 +990,10 @@ static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
 		 * expect simply identical entries for this case, but there's
 		 * no harm in accommodating the generalisation.
 		 */
-		if ((mask & smrs[i].mask) == mask &&
-		    !((id ^ smrs[i].id) & ~smrs[i].mask))
+
+		if (smr_is_subset(&smrs[i], id, mask))
 			return i;
+
 		/*
 		 * If the new entry has any other overlap with an existing one,
 		 * though, then there always exists at least one stream ID
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 703fd5817ec1..2e4f65412c6b 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -501,6 +501,11 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
 		writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);
 }

+static inline bool smr_is_subset(struct arm_smmu_smr *smrs, u16 id, u16 mask)
+{
+	return (mask & smrs->mask) == mask && !((id ^ smrs->id) & ~smrs->mask);
+}
+
 #define ARM_SMMU_GR0		0
 #define ARM_SMMU_GR1		1
 #define ARM_SMMU_CB(s, n)	((s)->numpage + (n))
--
2.17.1



From quic_bibekkum at quicinc.com  Tue Dec 19 05:59:46 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 19:29:46 +0530
Subject: [PATCH v5 4/5] iommu/arm-smmu: add ACTLR data and support for SM8550
In-Reply-To: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
References: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
Message-ID: <20231219135947.1623-5-quic_bibekkum@quicinc.com>

Add ACTLR data table for SM8550 along with support for
same including SM8550 specific implementation operations.

Suggested-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 80 ++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index b3cd585abf87..e1819dfa1311 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -23,6 +23,12 @@

 #define CPRE			(1 << 1)
 #define CMTLB			(1 << 0)
+#define PREFETCH_SHIFT		8
+#define PREFETCH_DEFAULT	0
+#define PREFETCH_SHALLOW	(1 << PREFETCH_SHIFT)
+#define PREFETCH_MODERATE	(2 << PREFETCH_SHIFT)
+#define PREFETCH_DEEP		(3 << PREFETCH_SHIFT)
+#define PREFETCH_SWITCH_GFX	(5 << 3)

 struct actlr_config {
 	u16 sid;
@@ -30,6 +36,70 @@ struct actlr_config {
 	u32 actlr;
 };

+static const struct actlr_config sm8550_apps_actlr_cfg[] = {
+	{ 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x0800, 0x0020, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1800, 0x00c0, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1820, 0x0000, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1860, 0x0000, PREFETCH_DEFAULT | CMTLB },
+	{ 0x0c01, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c02, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c03, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c04, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c05, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c06, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c07, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c08, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c09, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0c, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0d, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0e, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0f, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1961, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1962, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1963, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1964, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1965, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1966, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1967, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1968, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1969, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196c, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196d, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196e, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196f, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c1, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c2, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c3, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c4, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c5, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c6, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c7, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c8, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c9, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19cc, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19cd, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19ce, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19cf, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1c00, 0x0002, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1c01, 0x0000, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1920, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1923, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1924, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1940, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1941, 0x0004, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1943, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1944, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{},
+};
+
+static const struct actlr_config sm8550_gfx_actlr_cfg[] = {
+	{ 0x0000, 0x03ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE | CMTLB },
+	{},
+};
+
 static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
 {
 	return container_of(smmu, struct qcom_smmu, smmu);
@@ -576,6 +646,15 @@ static const struct qcom_smmu_match_data sdm845_smmu_500_data = {
 	/* Also no debug configuration. */
 };

+
+static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
+	.impl = &qcom_smmu_500_impl,
+	.adreno_impl = &qcom_adreno_smmu_500_impl,
+	.cfg = &qcom_smmu_impl0_cfg,
+	.actlrcfg = sm8550_apps_actlr_cfg,
+	.actlrcfg_gfx = sm8550_gfx_actlr_cfg,
+};
+
 static const struct qcom_smmu_match_data qcom_smmu_500_impl0_data = {
 	.impl = &qcom_smmu_500_impl,
 	.adreno_impl = &qcom_adreno_smmu_500_impl,
@@ -610,6 +689,7 @@ static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
 	{ .compatible = "qcom,sm8250-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sm8350-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sm8450-smmu-500", .data = &qcom_smmu_500_impl0_data },
+	{ .compatible = "qcom,sm8550-smmu-500", .data = &sm8550_smmu_500_impl0_data },
 	{ .compatible = "qcom,smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ }
 };
--
2.17.1



From quic_bibekkum at quicinc.com  Tue Dec 19 05:59:47 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Tue, 19 Dec 2023 19:29:47 +0530
Subject: [PATCH v5 5/5] iommu/arm-smmu: add ACTLR data and support for SC7280
In-Reply-To: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
References: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
Message-ID: <20231219135947.1623-6-quic_bibekkum@quicinc.com>

Add ACTLR data table for SC7280 along with support for
same including SC7280 specific implementation operations.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 25 +++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index e1819dfa1311..fcf8d1abd8d9 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -36,6 +36,22 @@ struct actlr_config {
 	u32 actlr;
 };

+static const struct actlr_config sc7280_apps_actlr_cfg[] = {
+	{ 0x0800, 0x24e1, PREFETCH_DEFAULT | CMTLB },
+	{ 0x2000, 0x0163, PREFETCH_DEFAULT | CMTLB },
+	{ 0x2080, 0x0461, PREFETCH_DEFAULT | CMTLB },
+	{ 0x2100, 0x0161, PREFETCH_DEFAULT | CMTLB },
+	{ 0x0900, 0x0407, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x2180, 0x0027, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1000, 0x07ff, PREFETCH_DEEP | CPRE | CMTLB },
+	{},
+};
+
+static const struct actlr_config sc7280_gfx_actlr_cfg[] = {
+	{ 0x0000, 0x07ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE | CMTLB },
+	{},
+};
+
 static const struct actlr_config sm8550_apps_actlr_cfg[] = {
 	{ 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
 	{ 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
@@ -646,6 +662,13 @@ static const struct qcom_smmu_match_data sdm845_smmu_500_data = {
 	/* Also no debug configuration. */
 };

+static const struct qcom_smmu_match_data sc7280_smmu_500_impl0_data = {
+	.impl = &qcom_smmu_500_impl,
+	.adreno_impl = &qcom_adreno_smmu_500_impl,
+	.cfg = &qcom_smmu_impl0_cfg,
+	.actlrcfg = sc7280_apps_actlr_cfg,
+	.actlrcfg_gfx = sc7280_gfx_actlr_cfg,
+};

 static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
 	.impl = &qcom_smmu_500_impl,
@@ -672,7 +695,7 @@ static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
 	{ .compatible = "qcom,qdu1000-smmu-500", .data = &qcom_smmu_500_impl0_data  },
 	{ .compatible = "qcom,sc7180-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sc7180-smmu-v2", .data = &qcom_smmu_v2_data },
-	{ .compatible = "qcom,sc7280-smmu-500", .data = &qcom_smmu_500_impl0_data },
+	{ .compatible = "qcom,sc7280-smmu-500", .data = &sc7280_smmu_500_impl0_data },
 	{ .compatible = "qcom,sc8180x-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sc8280xp-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sdm630-smmu-v2", .data = &qcom_smmu_v2_data },
--
2.17.1



From broonie at kernel.org  Tue Dec 19 06:01:22 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 19 Dec 2023 14:01:22 +0000
Subject: [PATCH] ASoC: xilinx: Embed IEC958 sample rate val to channel
 status register
In-Reply-To: <20231219122955.104696-1-sunil.vaghela@softnautics.com>
References: <20231219122955.104696-1-sunil.vaghela@softnautics.com>
Message-ID: <1d354ce4-b85c-495a-b54d-48a443736a52@sirena.org.uk>

On Tue, Dec 19, 2023 at 05:59:55PM +0530, Sunil Vaghela wrote:
> As per IEC 60958 specification, bits 24 to 27 of channel status register
> indicates audio sample frequency. If these bits are not set, audio
> analyzer always shows 44.1KHz sample rate, irrespective of any sample
> rate audio is being played.

This breaks an x86 allmodconfig build:

/build/stage/linux/sound/soc/xilinx/xlnx_formatter_pcm.c: In function ?xlnx_form
atter_pcm_hw_params?:
/build/stage/linux/sound/soc/xilinx/xlnx_formatter_pcm.c:572:26: error: ?struct 
xlnx_pcm_drv_data? has no member named ?nodes?
  572 |         if ((strstr(adata->nodes[XLNX_PLAYBACK]->name, "hdmi")) ||
      |                          ^~
/build/stage/linux/sound/soc/xilinx/xlnx_formatter_pcm.c:572:34: error: ?XLNX_PL
AYBACK? undeclared (first use in this function)
  572 |         if ((strstr(adata->nodes[XLNX_PLAYBACK]->name, "hdmi")) ||
      |                                  ^~~~~~~~~~~~~
/build/stage/linux/sound/soc/xilinx/xlnx_formatter_pcm.c:572:34: note: each unde
clared identifier is reported only once for each function it appears in
/build/stage/linux/sound/soc/xilinx/xlnx_formatter_pcm.c:573:26: error: ?struct xlnx_pcm_drv_data? has no member named ?nodes?
  573 |             (strstr(adata->nodes[XLNX_PLAYBACK]->name, "dp"))) {
      |                          ^~

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/0be2bbf0/attachment.sig>

From bot at kernelci.org  Tue Dec 19 06:03:23 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Tue, 19 Dec 2023 06:03:23 -0800 (PST)
Subject: arm64/for-kernelci build: 1 build: 0 failed,
 1 passed (v6.7-rc6-90-gaafe7ad77b91)
Message-ID: <6581a2ab.a70a0220.38b58.f2ea@mx.google.com>

arm64/for-kernelci build: 1 build: 0 failed, 1 passed (v6.7-rc6-90-gaafe7ad77b91)

Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v6.7-rc6-90-gaafe7ad77b91/

Tree: arm64
Branch: for-kernelci
Git Describe: v6.7-rc6-90-gaafe7ad77b91
Git Commit: aafe7ad77b91342049b8f157b978d5d4d5103211
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Built: 1 unique architecture

================================================================================

Detailed per-defconfig build reports:

--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) ? PASS, 0 errors, 0 warnings, 0 section mismatches

---
For more info write to <info at kernelci.org>


From suzuki.poulose at arm.com  Tue Dec 19 06:09:32 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 19 Dec 2023 14:09:32 +0000
Subject: [PATCH v3 8/8] coresight-tpdm: Add msr register support for CMB
In-Reply-To: <4409f3cf-7ca9-407f-92c0-5aa7ba6f7b61@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-9-git-send-email-quic_taozha@quicinc.com>
 <185b23e7-a42f-4a12-85ba-8a093bc5ea58@arm.com>
 <4409f3cf-7ca9-407f-92c0-5aa7ba6f7b61@quicinc.com>
Message-ID: <d8262a32-cc3c-4889-a5f0-a6b128b7e9d6@arm.com>

On 19/12/2023 06:58, Tao Zhang wrote:
> 
> On 12/18/2023 7:02 PM, Suzuki K Poulose wrote:
>> On 21/11/2023 02:24, Tao Zhang wrote:
>>> Add the nodes for CMB subunit MSR(mux select register) support.
>>> CMB MSRs(mux select registers) is to separate mux,arbitration,
>>> ,interleaving,data packing control from stream filtering control.
>>>
>>> Reviewed-by: James Clark <james.clark at arm.com>
>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>>> ---
>>> ? .../testing/sysfs-bus-coresight-devices-tpdm? |? 8 ++
>>> ? drivers/hwtracing/coresight/coresight-tpdm.c? | 86 +++++++++++++++++++
>>> ? drivers/hwtracing/coresight/coresight-tpdm.h? | 16 +++-
>>> ? 3 files changed, 109 insertions(+), 1 deletion(-)
>>>
>>> diff --git 
>>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm 
>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>> index e0b77107be13..914f3fd81525 100644
>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>> @@ -249,3 +249,11 @@ Description:
>>> ????????? Accepts only one of the 2 values -? 0 or 1.
>>> ????????? 0 : Disable the timestamp of all trace packets.
>>> ????????? 1 : Enable the timestamp of all trace packets.
>>> +
>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31]
>>> +Date:??????? September 2023
>>> +KernelVersion??? 6.7
>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao Zhang 
>>> (QUIC) <quic_taozha at quicinc.com>
>>> +Description:
>>> +??????? (RW) Set/Get the MSR(mux select register) for the CMB subunit
>>> +??????? TPDM.
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>>> index f6cda5616e84..7e331ea436cc 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>> @@ -86,6 +86,11 @@ static ssize_t tpdm_simple_dataset_show(struct 
>>> device *dev,
>>> ????????????? return -EINVAL;
>>> ????????? return sysfs_emit(buf, "0x%x\n",
>>> ????????????? drvdata->cmb->patt_mask[tpdm_attr->idx]);
>>> +??? case CMB_MSR:
>>> +??????? if (tpdm_attr->idx >= drvdata->cmb_msr_num)
>>> +??????????? return -EINVAL;
>>> +??????? return sysfs_emit(buf, "0x%x\n",
>>> +??????????????? drvdata->cmb->msr[tpdm_attr->idx]);
>>> ????? }
>>> ????? return -EINVAL;
>>> ? }
>>> @@ -162,6 +167,12 @@ static ssize_t tpdm_simple_dataset_store(struct 
>>> device *dev,
>>> ????????? else
>>> ????????????? ret = -EINVAL;
>>> ????????? break;
>>> +??? case CMB_MSR:
>>> +??????? if (tpdm_attr->idx < drvdata->cmb_msr_num)
>>> +??????????? drvdata->cmb->msr[tpdm_attr->idx] = val;
>>> +??????? else
>>> +??????????? ret = -EINVAL;
>>
>>
>> minor nit: Could we not break from here instead of adding return -EINVAL
>> for each case ? (I understand it has been done for the existing cases.
>> But I think we should clean up all of that, including the ones you added
>> in Patch 5. Similarly for the dataset_show()
> 
> Sure, do I also need to change the DSB corresponding code? If so, how about
> 
> if I add a new patch to the next patch series to change the previous 
> existing cases?

You could fix the existing cases as a preparatory patch of the next 
version of this series. I can pick it up and push it to next as I see fit.

Suzuki


> 
> 
> Best,
> 
> Tao
> 
>>
>>
>> Suzuki
>>
>>
>>> +??????? break;
>>> ????? default:
>>> ????????? ret = -EINVAL;
>>> ????? }
>>> @@ -220,6 +231,23 @@ static umode_t tpdm_dsb_msr_is_visible(struct 
>>> kobject *kobj,
>>> ????? return 0;
>>> ? }
>>> ? +static umode_t tpdm_cmb_msr_is_visible(struct kobject *kobj,
>>> +?????????????????????? struct attribute *attr, int n)
>>> +{
>>> +??? struct device *dev = kobj_to_dev(kobj);
>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +
>>> +??? struct device_attribute *dev_attr =
>>> +??????? container_of(attr, struct device_attribute, attr);
>>> +??? struct tpdm_dataset_attribute *tpdm_attr =
>>> +??????? container_of(dev_attr, struct tpdm_dataset_attribute, attr);
>>> +
>>> +??? if (tpdm_attr->idx < drvdata->cmb_msr_num)
>>> +??????? return attr->mode;
>>> +
>>> +??? return 0;
>>> +}
>>> +
>>> ? static void tpdm_reset_datasets(struct tpdm_drvdata *drvdata)
>>> ? {
>>> ????? if (tpdm_has_dsb_dataset(drvdata)) {
>>> @@ -361,6 +389,15 @@ static void set_cmb_tier(struct tpdm_drvdata 
>>> *drvdata)
>>> ????? writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>>> ? }
>>> ? +static void set_cmb_msr(struct tpdm_drvdata *drvdata)
>>> +{
>>> +??? int i;
>>> +
>>> +??? for (i = 0; i < drvdata->cmb_msr_num; i++)
>>> +??????? writel_relaxed(drvdata->cmb->msr[i],
>>> +?????????????? drvdata->base + TPDM_CMB_MSR(i));
>>> +}
>>> +
>>> ? static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>>> ? {
>>> ????? u32 val, i;
>>> @@ -379,6 +416,8 @@ static void tpdm_enable_cmb(struct tpdm_drvdata 
>>> *drvdata)
>>> ? ????? set_cmb_tier(drvdata);
>>> ? +??? set_cmb_msr(drvdata);
>>> +
>>> ????? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>> ????? /*
>>> ?????? * Set to 0 for continuous CMB collection mode,
>>> @@ -1084,6 +1123,42 @@ static struct attribute *tpdm_cmb_patt_attrs[] 
>>> = {
>>> ????? NULL,
>>> ? };
>>> ? +static struct attribute *tpdm_cmb_msr_attrs[] = {
>>> +??? CMB_MSR_ATTR(0),
>>> +??? CMB_MSR_ATTR(1),
>>> +??? CMB_MSR_ATTR(2),
>>> +??? CMB_MSR_ATTR(3),
>>> +??? CMB_MSR_ATTR(4),
>>> +??? CMB_MSR_ATTR(5),
>>> +??? CMB_MSR_ATTR(6),
>>> +??? CMB_MSR_ATTR(7),
>>> +??? CMB_MSR_ATTR(8),
>>> +??? CMB_MSR_ATTR(9),
>>> +??? CMB_MSR_ATTR(10),
>>> +??? CMB_MSR_ATTR(11),
>>> +??? CMB_MSR_ATTR(12),
>>> +??? CMB_MSR_ATTR(13),
>>> +??? CMB_MSR_ATTR(14),
>>> +??? CMB_MSR_ATTR(15),
>>> +??? CMB_MSR_ATTR(16),
>>> +??? CMB_MSR_ATTR(17),
>>> +??? CMB_MSR_ATTR(18),
>>> +??? CMB_MSR_ATTR(19),
>>> +??? CMB_MSR_ATTR(20),
>>> +??? CMB_MSR_ATTR(21),
>>> +??? CMB_MSR_ATTR(22),
>>> +??? CMB_MSR_ATTR(23),
>>> +??? CMB_MSR_ATTR(24),
>>> +??? CMB_MSR_ATTR(25),
>>> +??? CMB_MSR_ATTR(26),
>>> +??? CMB_MSR_ATTR(27),
>>> +??? CMB_MSR_ATTR(28),
>>> +??? CMB_MSR_ATTR(29),
>>> +??? CMB_MSR_ATTR(30),
>>> +??? CMB_MSR_ATTR(31),
>>> +??? NULL,
>>> +};
>>> +
>>> ? static struct attribute *tpdm_dsb_attrs[] = {
>>> ????? &dev_attr_dsb_mode.attr,
>>> ????? &dev_attr_dsb_trig_ts.attr,
>>> @@ -1144,6 +1219,12 @@ static struct attribute_group 
>>> tpdm_cmb_patt_grp = {
>>> ????? .name = "cmb_patt",
>>> ? };
>>> ? +static struct attribute_group tpdm_cmb_msr_grp = {
>>> +??? .attrs = tpdm_cmb_msr_attrs,
>>> +??? .is_visible = tpdm_cmb_msr_is_visible,
>>> +??? .name = "cmb_msr",
>>> +};
>>> +
>>> ? static const struct attribute_group *tpdm_attr_grps[] = {
>>> ????? &tpdm_attr_grp,
>>> ????? &tpdm_dsb_attr_grp,
>>> @@ -1154,6 +1235,7 @@ static const struct attribute_group 
>>> *tpdm_attr_grps[] = {
>>> ????? &tpdm_cmb_attr_grp,
>>> ????? &tpdm_cmb_trig_patt_grp,
>>> ????? &tpdm_cmb_patt_grp,
>>> +??? &tpdm_cmb_msr_grp,
>>> ????? NULL,
>>> ? };
>>> ? @@ -1192,6 +1274,10 @@ static int tpdm_probe(struct amba_device 
>>> *adev, const struct amba_id *id)
>>> ????????? of_property_read_u32(drvdata->dev->of_node,
>>> ???????????????? "qcom,dsb-msrs-num", &drvdata->dsb_msr_num);
>>> ? +??? if (drvdata && tpdm_has_cmb_dataset(drvdata))
>>> +??????? of_property_read_u32(drvdata->dev->of_node,
>>> +?????????????? "qcom,cmb-msrs-num", &drvdata->cmb_msr_num);
>>> +
>>> ????? /* Set up coresight component description */
>>> ????? desc.name = coresight_alloc_device_name(&tpdm_devs, dev);
>>> ????? if (!desc.name)
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>>> index 65b7ca6c4077..255104d024ab 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>> @@ -21,6 +21,8 @@
>>> ? #define TPDM_CMB_XPR(n)??????? (0xA18 + (n * 4))
>>> ? /*CMB subunit trigger pattern mask registers*/
>>> ? #define TPDM_CMB_XPMR(n)??? (0xA20 + (n * 4))
>>> +/* CMB MSR register */
>>> +#define TPDM_CMB_MSR(n)??????? (0xA80 + (n * 4))
>>> ? ? /* Enable bit for CMB subunit */
>>> ? #define TPDM_CMB_CR_ENA??????? BIT(0)
>>> @@ -36,6 +38,9 @@
>>> ? /*Patten register number*/
>>> ? #define TPDM_CMB_MAX_PATT??????? 2
>>> ? +/* MAX number of DSB MSR */
>>> +#define TPDM_CMB_MAX_MSR 32
>>> +
>>> ? /* DSB Subunit Registers */
>>> ? #define TPDM_DSB_CR??????? (0x780)
>>> ? #define TPDM_DSB_TIER??????? (0x784)
>>> @@ -186,6 +191,10 @@
>>> ????????? tpdm_simple_dataset_rw(tpmr##nr,??????? \
>>> ????????? CMB_PATT_MASK, nr)
>>> ? +#define CMB_MSR_ATTR(nr)??????????????????? \
>>> +??????? tpdm_simple_dataset_rw(msr##nr,??????????? \
>>> +??????? CMB_MSR, nr)
>>> +
>>> ? /**
>>> ?? * struct dsb_dataset - specifics associated to dsb dataset
>>> ?? * @mode:???????????? DSB programming mode
>>> @@ -225,6 +234,7 @@ struct dsb_dataset {
>>> ?? * @patt_mask:??????? Save value for pattern mask
>>> ?? * @trig_patt:??????? Save value for trigger pattern
>>> ?? * @trig_patt_mask:?? Save value for trigger pattern mask
>>> + * @msr?????????????? Save value for MSR
>>> ?? * @patt_ts:????????? Indicates if pattern match for timestamp is 
>>> enabled.
>>> ?? * @trig_ts:????????? Indicates if CTI trigger for timestamp is 
>>> enabled.
>>> ?? * @ts_all:?????????? Indicates if timestamp is enabled for all 
>>> packets.
>>> @@ -235,6 +245,7 @@ struct cmb_dataset {
>>> ????? u32??????????? patt_mask[TPDM_CMB_MAX_PATT];
>>> ????? u32??????????? trig_patt[TPDM_CMB_MAX_PATT];
>>> ????? u32??????????? trig_patt_mask[TPDM_CMB_MAX_PATT];
>>> +??? u32??????????? msr[TPDM_CMB_MAX_MSR];
>>> ????? bool??????????? patt_ts;
>>> ????? bool??????????? trig_ts;
>>> ????? bool??????????? ts_all;
>>> @@ -251,6 +262,7 @@ struct cmb_dataset {
>>> ?? * @dsb???????? Specifics associated to TPDM DSB.
>>> ?? * @cmb???????? Specifics associated to TPDM CMB.
>>> ?? * @dsb_msr_num Number of MSR supported by DSB TPDM
>>> + * @cmb_msr_num Number of MSR supported by CMB TPDM
>>> ?? */
>>> ? ? struct tpdm_drvdata {
>>> @@ -263,6 +275,7 @@ struct tpdm_drvdata {
>>> ????? struct dsb_dataset??? *dsb;
>>> ????? struct cmb_dataset??? *cmb;
>>> ????? u32??????????? dsb_msr_num;
>>> +??? u32??????????? cmb_msr_num;
>>> ? };
>>> ? ? /* Enumerate members of various datasets */
>>> @@ -277,7 +290,8 @@ enum dataset_mem {
>>> ????? CMB_TRIG_PATT,
>>> ????? CMB_TRIG_PATT_MASK,
>>> ????? CMB_PATT,
>>> -??? CMB_PATT_MASK
>>> +??? CMB_PATT_MASK,
>>> +??? CMB_MSR
>>> ? };
>>> ? ? /**
>>
>> _______________________________________________
>> CoreSight mailing list -- coresight at lists.linaro.org
>> To unsubscribe send an email to coresight-leave at lists.linaro.org



From kan.liang at linux.intel.com  Tue Dec 19 06:15:27 2023
From: kan.liang at linux.intel.com (Liang, Kan)
Date: Tue, 19 Dec 2023 09:15:27 -0500
Subject: [PATCH V3 0/7] Clean up perf mem
In-Reply-To: <a0abfee5-4dcd-3eb5-82fe-1a0dcdade038@linux.ibm.com>
References: <20231213195154.1085945-1-kan.liang@linux.intel.com>
 <a0abfee5-4dcd-3eb5-82fe-1a0dcdade038@linux.ibm.com>
Message-ID: <befb6acd-86be-4255-af96-38865affc56c@linux.intel.com>



On 2023-12-19 4:26 a.m., kajoljain wrote:
> Hi,
>   I was trying to test this patchset on powerpc.
> 
> After applying it on top of acme's perf-tools-next branch, I am getting
> below error:
> 
>   INSTALL libsubcmd_headers
>   INSTALL libperf_headers
>   INSTALL libsymbol_headers
>   INSTALL libapi_headers
>   INSTALL libbpf_headers
>   CC      arch/powerpc/util/mem-events.o
> In file included from arch/powerpc/util/mem-events.c:3:
> arch/powerpc/util/mem-events.h:5:52: error: ?PERF_MEM_EVENTS__MAX?
> undeclared here (not in a function)
>     5 | extern struct perf_mem_event
> perf_mem_events_power[PERF_MEM_EVENTS__MAX];
>       |
> ^~~~~~~~~~~~~~~~~~~~
> make[6]: *** [/home/kajol/linux/tools/build/Makefile.build:105:
> arch/powerpc/util/mem-events.o] Error 1
> make[5]: *** [/home/kajol/linux/tools/build/Makefile.build:158: util]
> Error 2
> make[4]: *** [/home/kajol/linux/tools/build/Makefile.build:158: powerpc]
> Error 2
> make[3]: *** [/home/kajol/linux/tools/build/Makefile.build:158: arch]
> Error 2
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [Makefile.perf:693: perf-in.o] Error 2
> make[1]: *** [Makefile.perf:251: sub-make] Error 2
> make: *** [Makefile:70: all] Error 2
> 
> It seems some headerfiles are missing from arch/powerpc/util/mem-
> events.c
> 

Leo updated the headerfiles for ARM. https://termbin.com/0dkn

I guess powerpc has to do the same thing. Could you please try the below
patch?

diff --git a/tools/perf/arch/powerpc/util/mem-events.c
b/tools/perf/arch/powerpc/util/mem-events.c
index 72a6ac2b52f5..765d4a054b0a 100644
--- a/tools/perf/arch/powerpc/util/mem-events.c
+++ b/tools/perf/arch/powerpc/util/mem-events.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
-#include "map_symbol.h"
+#include "util/map_symbol.h"
+#include "util/mem-events.h"
 #include "mem-events.h"

 #define E(t, n, s, l, a) { .tag = t, .name = n, .event_name = s, .ldlat
= l, .aux_event = a }

Thanks,
Kan

> Thanks,
> Kajol Jain
> 
> On 12/14/23 01:21, kan.liang at linux.intel.com wrote:
>> From: Kan Liang <kan.liang at linux.intel.com>
>>
>> Changes since V2:
>> - Fix the Arm64 building error (Leo)
>> - Add two new patches to clean up perf_mem_events__record_args()
>>   and perf_pmus__num_mem_pmus() (Leo)
>>
>> Changes since V1:
>> - Fix strcmp of PMU name checking (Ravi)
>> - Fix "/," typo (Ian)
>> - Rename several functions with perf_pmu__mem_events prefix. (Ian)
>> - Fold the header removal patch into the patch where the cleanups made.
>>   (Arnaldo)
>> - Add reviewed-by and tested-by from Ian and Ravi
>>
>> As discussed in the below thread, the patch set is to clean up perf mem.
>> https://lore.kernel.org/lkml/afefab15-cffc-4345-9cf4-c6a4128d4d9c at linux.intel.com/
>>
>> Introduce generic functions perf_mem_events__ptr(),
>> perf_mem_events__name() ,and is_mem_loads_aux_event() to replace the
>> ARCH specific ones.
>> Simplify the perf_mem_event__supported().
>>
>> Only keeps the ARCH-specific perf_mem_events array in the corresponding
>> mem-events.c for each ARCH.
>>
>> There is no functional change.
>>
>> The patch set touches almost all the ARCHs, Intel, AMD, ARM, Power and
>> etc. But I can only test it on two Intel platforms.
>> Please give it try, if you have machines with other ARCHs.
>>
>> Here are the test results:
>> Intel hybrid machine:
>>
>> $perf mem record -e list
>> ldlat-loads  : available
>> ldlat-stores : available
>>
>> $perf mem record -e ldlat-loads -v --ldlat 50
>> calling: record -e cpu_atom/mem-loads,ldlat=50/P -e cpu_core/mem-loads,ldlat=50/P
>>
>> $perf mem record -v
>> calling: record -e cpu_atom/mem-loads,ldlat=30/P -e cpu_atom/mem-stores/P -e cpu_core/mem-loads,ldlat=30/P -e cpu_core/mem-stores/P
>>
>> $perf mem record -t store -v
>> calling: record -e cpu_atom/mem-stores/P -e cpu_core/mem-stores/P
>>
>>
>> Intel SPR:
>> $perf mem record -e list
>> ldlat-loads  : available
>> ldlat-stores : available
>>
>> $perf mem record -e ldlat-loads -v --ldlat 50
>> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=50/}:P
>>
>> $perf mem record -v
>> calling: record -e {cpu/mem-loads-aux/,cpu/mem-loads,ldlat=30/}:P -e cpu/mem-stores/P
>>
>> $perf mem record -t store -v
>> calling: record -e cpu/mem-stores/P
>>
>> Kan Liang (7):
>>   perf mem: Add mem_events into the supported perf_pmu
>>   perf mem: Clean up perf_mem_events__ptr()
>>   perf mem: Clean up perf_mem_events__name()
>>   perf mem: Clean up perf_mem_event__supported()
>>   perf mem: Clean up is_mem_loads_aux_event()
>>   perf mem: Clean up perf_mem_events__record_args()
>>   perf mem: Clean up perf_pmus__num_mem_pmus()
>>
>>  tools/perf/arch/arm/util/pmu.c            |   3 +
>>  tools/perf/arch/arm64/util/mem-events.c   |  39 +---
>>  tools/perf/arch/arm64/util/mem-events.h   |   7 +
>>  tools/perf/arch/powerpc/util/mem-events.c |  13 +-
>>  tools/perf/arch/powerpc/util/mem-events.h |   7 +
>>  tools/perf/arch/powerpc/util/pmu.c        |  11 ++
>>  tools/perf/arch/s390/util/pmu.c           |   3 +
>>  tools/perf/arch/x86/util/mem-events.c     |  99 ++--------
>>  tools/perf/arch/x86/util/mem-events.h     |  10 +
>>  tools/perf/arch/x86/util/pmu.c            |  19 +-
>>  tools/perf/builtin-c2c.c                  |  45 ++---
>>  tools/perf/builtin-mem.c                  |  48 ++---
>>  tools/perf/util/mem-events.c              | 217 +++++++++++++---------
>>  tools/perf/util/mem-events.h              |  19 +-
>>  tools/perf/util/pmu.c                     |   4 +-
>>  tools/perf/util/pmu.h                     |   7 +
>>  tools/perf/util/pmus.c                    |   6 -
>>  tools/perf/util/pmus.h                    |   1 -
>>  18 files changed, 278 insertions(+), 280 deletions(-)
>>  create mode 100644 tools/perf/arch/arm64/util/mem-events.h
>>  create mode 100644 tools/perf/arch/powerpc/util/mem-events.h
>>  create mode 100644 tools/perf/arch/powerpc/util/pmu.c
>>  create mode 100644 tools/perf/arch/x86/util/mem-events.h
>>
> 


From linus.walleij at linaro.org  Tue Dec 19 06:19:45 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 19 Dec 2023 15:19:45 +0100
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
In-Reply-To: <20231219140754.7a7a8dbd@device-28.home>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <20231218162326.173127-2-romain.gantois@bootlin.com> <20231219122034.pg2djgrosa4irubh@skbuf>
 <20231219140754.7a7a8dbd@device-28.home>
Message-ID: <CACRpkdaxy9u=1-rQ+f+1tb8xyV-GYOuq52xhb4_SRPk9-LpnUA@mail.gmail.com>

On Tue, Dec 19, 2023 at 2:07?PM Maxime Chevallier
<maxime.chevallier at bootlin.com> wrote:

> So it looks like an acceptable solution would be something along the
> lines of what Linus is suggesting here :
>
> https://lore.kernel.org/netdev/20231216-new-gemini-ethernet-regression-v2-2-64c269413dfa at linaro.org/
>
> If so, maybe it's worth adding a new helper for that check ?

Yeah it's a bit annoying when skb->protocol is not == ethertype of buffer.

I can certainly add a helper such as skb_eth_raw_ethertype()
to <linux/if_ether.h> that will inspect the actual ethertype in
skb->data.

It's the most straight-forward approach.

We could also add something like bool custom_ethertype; to
struct sk_buff and set that to true if the tagger adds a custom
ethertype. But I don't know how the network developers feel about
that.

Yours,
Linus Walleij


From robin.murphy at arm.com  Tue Dec 19 06:24:28 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 19 Dec 2023 14:24:28 +0000
Subject: [PATCH v2 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <4c78e6f2-d6fb-4da7-9c54-ca6a686f2b58@linaro.org>
References: <cover.1702571292.git.robin.murphy@arm.com>
 <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
 <8f583a00-8e9c-4875-936c-ed196d1dae56@linaro.org>
 <2b8414e5-61d5-4c3e-9613-6d9487ae84a8@arm.com>
 <4c78e6f2-d6fb-4da7-9c54-ca6a686f2b58@linaro.org>
Message-ID: <59dd1baa-ef5b-415a-a803-a2dbc3d405b2@arm.com>

On 2023-12-18 7:03 am, Krzysztof Kozlowski wrote:
> On 15/12/2023 19:39, Robin Murphy wrote:
>>>> +required:
>>>> +  - compatible
>>>> +  - reg
>>>> +
>>>> +additionalProperties: false
>>>
>>> Why no example to validate the binding?
>>
>> IMO for such a trivial binding built out of common properties, an
>> equally trivial example isn't going to add any value, since it won't do
>> anything more than re-state the individual property definitions above.
>> In bindings where we have conditional relationships between properties,
>> or complex encodings where a practical example can help explain a
>> definition (e.g. a map/mask pair for a set of input values), then
>> absolutely, an example can add something more to help the author and/or
>> users. But otherwise, the thing I've really grown to like about schema
>> is how thoroughly self-describing the definitions themselves can now be.
> 
> The example is used to validate the schema.

Can you clarify what that *means*, though? As far as I can tell from a 
bit of experimentation, "make dt_bindings_check" picks up errors in the 
schema definition itself just the same whether an example is present or 
not. Thus I still fail to understand what else would be validated by me 
writing an example here, other than my personal ability to comprehend my 
own binding.

Yes, I'm well aware that back when we were bootstrapping dtschema it was 
useful to confirm that schemas were written to correctly describe 
*existing* known-good DT fragments. However with new bindings like this 
we've already reached the end goal, where we write an authoritative 
schema first, then the users follow from there. As I alluded to above, 
there are reasons why I would actually prefer *not* to provide a usage 
example here - frankly if a user doesn't understand which parts of the 
architecture their hardware implements, and/or can't figure out how to 
copy a single compatible string and write a standard reg property, I 
would much rather they come to me asking how to write a DT entry, than 
blindly copy-paste a verbatim example into their DTS, then come to me 
reporting a "bug" with the driver crashing or failing to probe. I'd love 
to say I have no experience to base that judgement on, but...

Thanks,
Robin.


From michal.simek at amd.com  Tue Dec 19 06:25:16 2023
From: michal.simek at amd.com (Michal Simek)
Date: Tue, 19 Dec 2023 15:25:16 +0100
Subject: [PATCH] dt-bindings: soc: xilinx: Add support for K26 rev2 SOMs
Message-ID: <6673abb84e542c2841cece9336571f97b19882fe.1702995908.git.michal.simek@amd.com>

Revision 2 is SW compatible with revision 1 but it is necessary to reflect
it in model and compatible properties which are parsed by user space.
Rev 2 has improved a power on boot reset and MIO34 shutdown glich
improvement done via an additional filter in the GreenPak chip.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

 Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
index d4c0fe1fe435..62617e1ea74f 100644
--- a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
+++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
@@ -118,6 +118,7 @@ properties:
 
       - description: Xilinx Kria SOMs
         items:
+          - const: xlnx,zynqmp-sm-k26-rev2
           - const: xlnx,zynqmp-sm-k26-rev1
           - const: xlnx,zynqmp-sm-k26-revB
           - const: xlnx,zynqmp-sm-k26-revA
@@ -126,6 +127,7 @@ properties:
 
       - description: Xilinx Kria SOMs (starter)
         items:
+          - const: xlnx,zynqmp-smk-k26-rev2
           - const: xlnx,zynqmp-smk-k26-rev1
           - const: xlnx,zynqmp-smk-k26-revB
           - const: xlnx,zynqmp-smk-k26-revA
-- 
2.36.1



From michal.simek at amd.com  Tue Dec 19 06:31:25 2023
From: michal.simek at amd.com (Michal Simek)
Date: Tue, 19 Dec 2023 15:31:25 +0100
Subject: [PATCH] dt-bindings: firmware: xilinx: Fix versal-fpga node name
Message-ID: <6779af2f9cc21c912f10cf310388d99b980800b2.1702996281.git.michal.simek@amd.com>

Based on commit 83a368a3fc8a ("docs: dt-bindings: add DTS Coding Style
document") using underscore ('_') in node name is not recommended that's
why switch to dash ('-').

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

 .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml        | 4 ++--
 Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index 8e584857ddd4..3d578f98ae2c 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -41,7 +41,7 @@ properties:
   "#power-domain-cells":
     const: 1
 
-  versal_fpga:
+  versal-fpga:
     $ref: /schemas/fpga/xlnx,versal-fpga.yaml#
     description: Compatible of the FPGA device.
     type: object
@@ -84,7 +84,7 @@ examples:
       compatible = "xlnx,versal-firmware";
       method = "smc";
 
-      versal_fpga: versal_fpga {
+      versal_fpga: versal-fpga {
         compatible = "xlnx,versal-fpga";
       };
 
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
index 26f18834caa3..80833462f620 100644
--- a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
+++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
@@ -26,7 +26,7 @@ additionalProperties: false
 
 examples:
   - |
-    versal_fpga: versal_fpga {
+    versal_fpga: versal-fpga {
          compatible = "xlnx,versal-fpga";
     };
 
-- 
2.36.1



From michal.simek at amd.com  Tue Dec 19 06:41:02 2023
From: michal.simek at amd.com (Michal Simek)
Date: Tue, 19 Dec 2023 15:41:02 +0100
Subject: [PATCH] dt-bindings: pinctrl: xilinx: Rename *gpio to *gpio-grp
Message-ID: <2e3a1f1f57cf929bd05115bc081e6d01d5a53443.1702996859.git.michal.simek@amd.com>

Anything ending with gpio/gpios is taken as gpio phande/description which
is reported as the issue coming from gpio-consumer.yaml schema.
That's why rename the gpio suffix to gpio-grp to avoid name collision.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

 .../devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml          | 2 +-
 .../devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml
index b85f9e36ce4b..d2676f92ef5b 100644
--- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml
@@ -39,7 +39,7 @@ properties:
       phandle to the SLCR.
 
 patternProperties:
-  '^(.*-)?(default|gpio)$':
+  '^(.*-)?(default|gpio-grp)$':
     type: object
     patternProperties:
       '^mux':
diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
index 01b6f2b57843..f13d315b5d5e 100644
--- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -31,7 +31,7 @@ properties:
     const: xlnx,zynqmp-pinctrl
 
 patternProperties:
-  '^(.*-)?(default|gpio)$':
+  '^(.*-)?(default|gpio-grp)$':
     type: object
     patternProperties:
       '^mux':
-- 
2.36.1



From conor at kernel.org  Tue Dec 19 06:44:17 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 19 Dec 2023 14:44:17 +0000
Subject: [PATCH v4 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <20231213055747.61826-6-bhe@redhat.com>
References: <20231213055747.61826-1-bhe@redhat.com>
 <20231213055747.61826-6-bhe@redhat.com>
Message-ID: <20231219-twitch-many-ca8877857182@spud>

On Wed, Dec 13, 2023 at 01:57:45PM +0800, Baoquan He wrote:
> Then when specifying '-d' for kexec_file_load interface, loaded
> locations of kernel/initrd/cmdline etc can be printed out to help debug.
> 
> Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> loading related codes.
> 
> And also replace pr_notice() with kexec_dprintk() in elf_kexec_load()
> because loaded location of purgatory and device tree are only printed
> out for debugging, it doesn't make sense to always print them out.
> 
> And also remove kexec_image_info() because the content has been printed
> out in generic code.
> 
> Signed-off-by: Baoquan He <bhe at redhat.com>

I'm sorry - I meant to look at this several days ago but I forgot.
Apart from the typo that crept back into $subject, this version explains
the rationale behind what you're changing a lot better, thanks.

Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/f01e6d7d/attachment.sig>

From bot at kernelci.org  Tue Dec 19 06:46:41 2023
From: bot at kernelci.org (kernelci.org bot)
Date: Tue, 19 Dec 2023 06:46:41 -0800 (PST)
Subject: arm64/for-kernelci baseline: 40 runs,
 1 regressions (v6.7-rc6-90-gaafe7ad77b91)
Message-ID: <6581acd1.170a0220.839c6.e370@mx.google.com>

arm64/for-kernelci baseline: 40 runs, 1 regressions (v6.7-rc6-90-gaafe7ad77b91)

Regressions Summary
-------------------

platform                 | arch  | lab             | compiler | defconfig | regressions
-------------------------+-------+-----------------+----------+-----------+------------
imx8mm-innocomm-wb15-evk | arm64 | lab-pengutronix | gcc-10   | defconfig | 1          

  Details:  https://kernelci.org/test/job/arm64/branch/for-kernelci/kernel/v6.7-rc6-90-gaafe7ad77b91/plan/baseline/

  Test:     baseline
  Tree:     arm64
  Branch:   for-kernelci
  Describe: v6.7-rc6-90-gaafe7ad77b91
  URL:      https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
  SHA:      aafe7ad77b91342049b8f157b978d5d4d5103211 


Test Regressions
---------------- 


platform                 | arch  | lab             | compiler | defconfig | regressions
-------------------------+-------+-----------------+----------+-----------+------------
imx8mm-innocomm-wb15-evk | arm64 | lab-pengutronix | gcc-10   | defconfig | 1          

  Details:     https://kernelci.org/test/plan/id/6581a2ac7a5dfaa817e13490

  Results:     0 PASS, 1 FAIL, 0 SKIP
  Full config: defconfig
  Compiler:    gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
  Plain log:   https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc6-90-gaafe7ad77b91/arm64/defconfig/gcc-10/lab-pengutronix/baseline-imx8mm-innocomm-wb15-evk.txt
  HTML log:    https://storage.kernelci.org//arm64/for-kernelci/v6.7-rc6-90-gaafe7ad77b91/arm64/defconfig/gcc-10/lab-pengutronix/baseline-imx8mm-innocomm-wb15-evk.html
  Rootfs:      http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230623.0/arm64/rootfs.cpio.gz 


  * baseline.login: https://kernelci.org/test/case/id/6581a2ac7a5dfaa817e13491
        new failure (last pass: v6.7-rc5-90-g0bcda4cd6851f) 
  


From luca.ceresoli at bootlin.com  Tue Dec 19 06:54:15 2023
From: luca.ceresoli at bootlin.com (Luca Ceresoli)
Date: Tue, 19 Dec 2023 15:54:15 +0100
Subject: [PATCH v2 0/6] Add support for the internal RK3308 audio codec
Message-ID: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>

This series of patches adds support to use the internal audio codec of the
Rockchip RK3308 SoC. This codec is internally connected to the I2S
peripherals on the same chip, and it has some peculiarities arising from
that interconnection.

For proper bidirectional operation with the internal codec, the I2S
peripheral needs two clock sources (tx and rx), while connection with an
external codec commonly needs only one. Since v5.16 there is a driver for
the I2S in sound/soc/rockchip/rockchip_i2s_tdm.c, but it does not correctly
handle receiving those two clocks via the .set_sysclk op. Patch 1 fixes
that.

Patches 2-4 adds the codec driver along with the bindings and a new helper
macro.

Patches 5-6 add to the SoC DT file two I2S controllers (those which are
internally connected to the internal codec) and the codec itself.

Luca

Signed-off-by: Luca Ceresoli <luca.ceresoli at bootlin.com>
---

Changed in v2:
 - largely rewrote the codec driver to use DAPM and lots of improvements
   and cleanups   
 - removed the RK3308 audio card and related patches, will be sent later
 - various other changes, listed per-patch

---
Luca Ceresoli (6):
      ASoC: rockchip: i2s-tdm: Fix clk_id usage in .set_sysclk()
      ASoC: dt-bindings: Add Rockchip RK3308 internal audio codec
      ASoC: core: add SOC_DOUBLE_RANGE_TLV() helper macro
      ASoC: codecs: Add RK3308 internal audio codec driver
      arm64: dts: rockchip: add i2s_8ch_2 and i2s_8ch_3
      arm64: dts: rockchip: add the internal audio codec

 .../bindings/sound/rockchip,rk3308-codec.yaml      |   98 ++
 MAINTAINERS                                        |    7 +
 arch/arm64/boot/dts/rockchip/rk3308.dtsi           |   68 ++
 include/sound/soc.h                                |   12 +
 sound/soc/codecs/Kconfig                           |   11 +
 sound/soc/codecs/Makefile                          |    2 +
 sound/soc/codecs/rk3308_codec.c                    | 1012 ++++++++++++++++++++
 sound/soc/codecs/rk3308_codec.h                    |  593 ++++++++++++
 sound/soc/rockchip/rockchip_i2s_tdm.c              |   22 +-
 9 files changed, 1819 insertions(+), 6 deletions(-)
---
base-commit: f89a0253ea1f519e6866689f0e83857ca276a2e9
change-id: 20231219-rk3308-audio-codec-a5558ba8949d

Best regards,
-- 
Luca Ceresoli <luca.ceresoli at bootlin.com>



From luca.ceresoli at bootlin.com  Tue Dec 19 06:54:16 2023
From: luca.ceresoli at bootlin.com (Luca Ceresoli)
Date: Tue, 19 Dec 2023 15:54:16 +0100
Subject: [PATCH v2 1/6] ASoC: rockchip: i2s-tdm: Fix clk_id usage in
 .set_sysclk()
In-Reply-To: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
References: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
Message-ID: <20231219-rk3308-audio-codec-v2-1-c70d06021946@bootlin.com>

There are two problems with the second parameter of
rockchip_i2s_tdm_set_sysclk():

 1. The second argument to a .set_sysclk() op is a clk_id, not a stream
    index, so it is incorrect to compare it with SNDRV_PCM_STREAM_PLAYBACK.

    Technically this code works correctly anyway because
    SNDRV_PCM_STREAM_PLAYBACK is defined as 0, which is also the clk_id for
    the mclk_tx as enforced by the device tree bindings. So this is a
    formal error, not triggering incorrect behaviour.

 2. The else branch will consider any nonzero value as "rx", while only
    value 1 should be allowed for the mclk_rx clock. This does trigger
    incorrect behaviour if passing clk_id not equal to 0 or 1.

Fix problem 1 by adding a new enum for the clock indexes as enforced in
device tree and replace accordingly:

 * stream -> clk_id
 * SNDRV_PCM_STREAM_PLAYBACK -> CLK_MCLK_TX (value 0)

Fix problem 2 by returning error if clk_id is not 0 or 1.

Also simplify and improve dev_dbg() messages.

Fixes: 081068fd6414 ("ASoC: rockchip: add support for i2s-tdm controller")
Signed-off-by: Luca Ceresoli <luca.ceresoli at bootlin.com>

---

Changed in v2:
 - use switch statement instead of if/then/else
---
 sound/soc/rockchip/rockchip_i2s_tdm.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/sound/soc/rockchip/rockchip_i2s_tdm.c b/sound/soc/rockchip/rockchip_i2s_tdm.c
index 860e66ec85e8..35b36aa3b970 100644
--- a/sound/soc/rockchip/rockchip_i2s_tdm.c
+++ b/sound/soc/rockchip/rockchip_i2s_tdm.c
@@ -32,6 +32,9 @@
 #define TRCM_TX 1
 #define TRCM_RX 2
 
+/* Clock indexes as enforced by the DT bindings */
+enum { CLK_IDX_MCLK_TX, CLK_IDX_MCLK_RX };
+
 struct txrx_config {
 	u32 addr;
 	u32 reg;
@@ -973,7 +976,7 @@ static int rockchip_i2s_tdm_trigger(struct snd_pcm_substream *substream,
 	return 0;
 }
 
-static int rockchip_i2s_tdm_set_sysclk(struct snd_soc_dai *cpu_dai, int stream,
+static int rockchip_i2s_tdm_set_sysclk(struct snd_soc_dai *cpu_dai, int clk_id,
 				       unsigned int freq, int dir)
 {
 	struct rk_i2s_tdm_dev *i2s_tdm = to_info(cpu_dai);
@@ -982,15 +985,22 @@ static int rockchip_i2s_tdm_set_sysclk(struct snd_soc_dai *cpu_dai, int stream,
 	if (i2s_tdm->clk_trcm) {
 		i2s_tdm->mclk_tx_freq = freq;
 		i2s_tdm->mclk_rx_freq = freq;
+
+		dev_dbg(i2s_tdm->dev, "mclk freq: %u", freq);
 	} else {
-		if (stream == SNDRV_PCM_STREAM_PLAYBACK)
+		switch (clk_id) {
+		case CLK_IDX_MCLK_TX:
 			i2s_tdm->mclk_tx_freq = freq;
-		else
+			break;
+		case CLK_IDX_MCLK_RX:
 			i2s_tdm->mclk_rx_freq = freq;
-	}
+			break;
+		default:
+			return -ENOTSUPP;
+		}
 
-	dev_dbg(i2s_tdm->dev, "The target mclk_%s freq is: %d\n",
-		stream ? "rx" : "tx", freq);
+		dev_dbg(i2s_tdm->dev, "mclk[%d] freq: %u", clk_id, freq);
+	}
 
 	return 0;
 }

-- 
2.34.1



From luca.ceresoli at bootlin.com  Tue Dec 19 06:54:18 2023
From: luca.ceresoli at bootlin.com (Luca Ceresoli)
Date: Tue, 19 Dec 2023 15:54:18 +0100
Subject: [PATCH v2 3/6] ASoC: core: add SOC_DOUBLE_RANGE_TLV() helper macro
In-Reply-To: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
References: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
Message-ID: <20231219-rk3308-audio-codec-v2-3-c70d06021946@bootlin.com>

No macro currently allows handling a stereo control that has left and right
in the same register and whose minimum register value is not zero. Add one
that does that.

Note that even though the snd_soc_*_volsw_range() look more appropriate
given the _range suffix, they are not suitable because they don't honor the
two shift values. The snd_soc_*_volsw() look more generic and are suitable
for the task.

Signed-off-by: Luca Ceresoli <luca.ceresoli at bootlin.com>

---

This patch is new in v2.
---
 include/sound/soc.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index 7792c393e238..41ba90bdbea9 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -149,6 +149,18 @@
 		{.reg = xreg, .rreg = xreg, \
 		.shift = shift_left, .rshift = shift_right, \
 		.max = xmax, .min = xmin} }
+#define SOC_DOUBLE_RANGE_TLV(xname, xreg, xshift_left, xshift_right, xmin, xmax, \
+			     xinvert, tlv_array) \
+{	.iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = (xname),\
+	.access = SNDRV_CTL_ELEM_ACCESS_TLV_READ |\
+		  SNDRV_CTL_ELEM_ACCESS_READWRITE,\
+	.tlv.p = (tlv_array), \
+	.info = snd_soc_info_volsw, \
+	.get = snd_soc_get_volsw, .put = snd_soc_put_volsw, \
+	.private_value = (unsigned long)&(struct soc_mixer_control) \
+		{.reg = xreg, .rreg = xreg, \
+		 .shift = xshift_left, .rshift = xshift_right, \
+		 .min = xmin, .max = xmax, .invert = xinvert} }
 #define SOC_DOUBLE_R_TLV(xname, reg_left, reg_right, xshift, xmax, xinvert, tlv_array) \
 {	.iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = (xname),\
 	.access = SNDRV_CTL_ELEM_ACCESS_TLV_READ |\

-- 
2.34.1



From luca.ceresoli at bootlin.com  Tue Dec 19 06:54:17 2023
From: luca.ceresoli at bootlin.com (Luca Ceresoli)
Date: Tue, 19 Dec 2023 15:54:17 +0100
Subject: [PATCH v2 2/6] ASoC: dt-bindings: Add Rockchip RK3308 internal
 audio codec
In-Reply-To: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
References: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
Message-ID: <20231219-rk3308-audio-codec-v2-2-c70d06021946@bootlin.com>

Add device tree bindings document for the internal audio codec of the
Rockchip RK3308 SoC.

Signed-off-by: Luca Ceresoli <luca.ceresoli at bootlin.com>

---

Changed in v2:
 - reword commit title
 - add maxItems to resets
 - remove quotes from reset-names
 - use percent values for rockchip,micbias-avdd-multiplier
 - use name compliant to the docs in the example
---
 .../bindings/sound/rockchip,rk3308-codec.yaml      | 98 ++++++++++++++++++++++
 MAINTAINERS                                        |  5 ++
 2 files changed, 103 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml
new file mode 100644
index 000000000000..27a9e5bcfa58
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/rockchip,rk3308-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3308 Internal Codec
+
+description: |
+  This is the audio codec embedded in the Rockchip RK3308
+  SoC. It has 8 24-bit ADCs and 2 24-bit DACs. The maximum supported
+  sampling rate is 192 kHz.
+
+  It is connected internally to one out of a selection of the internal I2S
+  controllers.
+
+  The RK3308 audio codec has 8 independent capture channels, but some
+  features work on stereo pairs called groups:
+    * grp 0 -- MIC1 / MIC2
+    * grp 1 -- MIC3 / MIC4
+    * grp 2 -- MIC5 / MIC6
+    * grp 3 -- MIC7 / MIC8
+
+maintainers:
+  - Luca Ceresoli <luca.ceresoli at bootlin.com>
+
+properties:
+  compatible:
+    const: rockchip,rk3308-codec
+
+  reg:
+    maxItems: 1
+
+  rockchip,grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      Phandle to the General Register Files (GRF)
+
+  clocks:
+    items:
+      - description: clock for TX
+      - description: clock for RX
+      - description: AHB clock driving the interface
+
+  clock-names:
+    items:
+      - const: mclk_tx
+      - const: mclk_rx
+      - const: hclk
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    items:
+      - const: codec
+
+  "#sound-dai-cells":
+    const: 0
+
+  rockchip,micbias-avdd-percent:
+    description: |
+      Voltage setting for the MICBIAS pins expressed as a percentage of
+      AVDD.
+
+      E.g. if rockchip,micbias-avdd-percent = 85 and AVDD = 3v3, then the
+      MIC BIAS voltage will be 3.3 V * 85% = 2.805 V.
+
+    enum: [ 50, 55, 60, 65, 70, 75, 80, 85 ]
+
+required:
+  - compatible
+  - reg
+  - rockchip,grf
+  - clocks
+  - resets
+  - "#sound-dai-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3308-cru.h>
+
+    audio-codec: audio-codec at ff560000 {
+        compatible = "rockchip,rk3308-codec";
+        reg = <0xff560000 0x10000>;
+        rockchip,grf = <&grf>;
+        clock-names = "mclk_tx", "mclk_rx", "hclk";
+        clocks = <&cru SCLK_I2S2_8CH_TX_OUT>,
+                 <&cru SCLK_I2S2_8CH_RX_OUT>,
+                 <&cru PCLK_ACODEC>;
+        reset-names = "codec";
+        resets = <&cru SRST_ACODEC_P>;
+        #sound-dai-cells = <0>;
+    };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 9104430e148e..feddd6610b51 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18669,6 +18669,11 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/media/rockchip-rga.yaml
 F:	drivers/media/platform/rockchip/rga/
 
+ROCKCHIP RK3308 INTERNAL AUDIO CODEC
+M:	Luca Ceresoli <luca.ceresoli at bootlin.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml
+
 ROCKCHIP VIDEO DECODER DRIVER
 M:	Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
 L:	linux-media at vger.kernel.org

-- 
2.34.1



From luca.ceresoli at bootlin.com  Tue Dec 19 06:54:21 2023
From: luca.ceresoli at bootlin.com (Luca Ceresoli)
Date: Tue, 19 Dec 2023 15:54:21 +0100
Subject: [PATCH v2 6/6] arm64: dts: rockchip: add the internal audio codec
In-Reply-To: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
References: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
Message-ID: <20231219-rk3308-audio-codec-v2-6-c70d06021946@bootlin.com>

The RK3308 has a built-in audio codec that connects internally to i2s_8ch_2
or i2s_8ch_3.

Signed-off-by: Luca Ceresoli <luca.ceresoli at bootlin.com>

---

Changed in v2:
 - use generic node name
---
 arch/arm64/boot/dts/rockchip/rk3308.dtsi | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
index fa34cae915a7..965b7d3230c0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
@@ -810,6 +810,20 @@ cru: clock-controller at ff500000 {
 		assigned-clock-rates = <32768>;
 	};
 
+	codec: codec at ff560000 {
+		compatible = "rockchip,rk3308-codec";
+		reg = <0x0 0xff560000 0x0 0x10000>;
+		rockchip,grf = <&grf>;
+		clock-names = "mclk_tx", "mclk_rx", "hclk";
+		clocks = <&cru SCLK_I2S2_8CH_TX_OUT>,
+			 <&cru SCLK_I2S2_8CH_RX_OUT>,
+			 <&cru PCLK_ACODEC>;
+		reset-names = "codec-reset";
+		resets = <&cru SRST_ACODEC_P>;
+		#sound-dai-cells = <0>;
+		status = "disabled";
+	};
+
 	gic: interrupt-controller at ff580000 {
 		compatible = "arm,gic-400";
 		reg = <0x0 0xff581000 0x0 0x1000>,

-- 
2.34.1



From luca.ceresoli at bootlin.com  Tue Dec 19 06:54:19 2023
From: luca.ceresoli at bootlin.com (Luca Ceresoli)
Date: Tue, 19 Dec 2023 15:54:19 +0100
Subject: [PATCH v2 4/6] ASoC: codecs: Add RK3308 internal audio codec
 driver
In-Reply-To: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
References: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
Message-ID: <20231219-rk3308-audio-codec-v2-4-c70d06021946@bootlin.com>

Add driver for the internal audio codec of the Rockchip RK3308 SoC.

Initially based on the vendor kernel driver [0], with lots of cleanups,
fixes, improvements, conversion to DAPM and removal of some features.

[0] https://github.com/rockchip-linux/kernel/blob/develop-4.19/sound/soc/codecs/rk3308_codec.c

Signed-off-by: Luca Ceresoli <luca.ceresoli at bootlin.com>

---

Changed in v2:
 - convert everything to DAPM support
 - move rk3308_codec_power_on/off() code to .set_bias_level
 - move MICBIAS setting from hw_params to probe
 - support silicon version C which differs in some registers
 - removed LINE IN code as LINE IN is not supported by the hardware
 - remove unneeded digital reset in in rk3308_codec_hw_params
 - rewrite on/off controls to be bool switches, not enums
 - fix _put() operations return value (1 if value changed)
 - fix RK3308_ADC_CURRENT_CHARGE_MSK power-down ramp (it was ramping up
   just like the power-up ramp)
 - enable zero-cross detection unconditionally
 - Remove AGC/ALC implementation
 - Add HPF controls (enable and cut-off frequency)
 - model HP output as a stereo control (requires new ASoC helper macro)
 - use ADC_CH*_MIC_MUTE for muting mics, not the BIST bits
 - fix uninitialized variable is_master
 - remove useless wrappers
 - remove .mute_stream callback
 - remove digital fade in/out for HPOUT volume
 - remove many unneeded register initializations to their reset values and
   documented the few places where open-coded initializations to values
   different from the reset value are needed
 - collapse various functions into rk3308_codec_adc_dig_config(), which
   simplified dramatically the hw_params code
 - various coding style and comments improvements, code reorganization
 - add error checking in several places
---
 MAINTAINERS                     |    2 +
 sound/soc/codecs/Kconfig        |   11 +
 sound/soc/codecs/Makefile       |    2 +
 sound/soc/codecs/rk3308_codec.c | 1012 +++++++++++++++++++++++++++++++++++++++
 sound/soc/codecs/rk3308_codec.h |  593 +++++++++++++++++++++++
 5 files changed, 1620 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index feddd6610b51..d250e0e10a24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18673,6 +18673,8 @@ ROCKCHIP RK3308 INTERNAL AUDIO CODEC
 M:	Luca Ceresoli <luca.ceresoli at bootlin.com>
 S:	Maintained
 F:	Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml
+F:	sound/soc/codecs/rk3308_codec.c
+F:	sound/soc/codecs/rk3308_codec.h
 
 ROCKCHIP VIDEO DECODER DRIVER
 M:	Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 3429419ca694..dea9ed9e4dff 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -179,6 +179,7 @@ config SND_SOC_ALL_CODECS
 	imply SND_SOC_PCM512x_I2C
 	imply SND_SOC_PCM512x_SPI
 	imply SND_SOC_PEB2466
+	imply SND_SOC_RK3308
 	imply SND_SOC_RK3328
 	imply SND_SOC_RK817
 	imply SND_SOC_RT274
@@ -1396,6 +1397,16 @@ config SND_SOC_PEB2466
 	  To compile this driver as a module, choose M here: the module
 	  will be called snd-soc-peb2466.
 
+config SND_SOC_RK3308
+	tristate "Rockchip RK3308 audio CODEC"
+	select REGMAP_MMIO
+	help
+	  This is a device driver for the audio codec embedded in the
+	  Rockchip RK3308 SoC.
+
+	  It has 8 24-bit ADCs and 2 24-bit DACs. The maximum supported
+	  sampling rate is 192 kHz.
+
 config SND_SOC_RK3328
 	tristate "Rockchip RK3328 audio CODEC"
 	select REGMAP_MMIO
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 2078bb0d981e..e33042350bfd 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -201,6 +201,7 @@ snd-soc-pcm512x-objs := pcm512x.o
 snd-soc-pcm512x-i2c-objs := pcm512x-i2c.o
 snd-soc-pcm512x-spi-objs := pcm512x-spi.o
 snd-soc-peb2466-objs := peb2466.o
+snd-soc-rk3308-objs := rk3308_codec.o
 snd-soc-rk3328-objs := rk3328_codec.o
 snd-soc-rk817-objs := rk817_codec.o
 snd-soc-rl6231-objs := rl6231.o
@@ -585,6 +586,7 @@ obj-$(CONFIG_SND_SOC_PCM512x)	+= snd-soc-pcm512x.o
 obj-$(CONFIG_SND_SOC_PCM512x_I2C)	+= snd-soc-pcm512x-i2c.o
 obj-$(CONFIG_SND_SOC_PCM512x_SPI)	+= snd-soc-pcm512x-spi.o
 obj-$(CONFIG_SND_SOC_PEB2466)	+= snd-soc-peb2466.o
+obj-$(CONFIG_SND_SOC_RK3308)	+= snd-soc-rk3308.o
 obj-$(CONFIG_SND_SOC_RK3328)	+= snd-soc-rk3328.o
 obj-$(CONFIG_SND_SOC_RK817)	+= snd-soc-rk817.o
 obj-$(CONFIG_SND_SOC_RL6231)	+= snd-soc-rl6231.o
diff --git a/sound/soc/codecs/rk3308_codec.c b/sound/soc/codecs/rk3308_codec.c
new file mode 100644
index 000000000000..cdf1aae665da
--- /dev/null
+++ b/sound/soc/codecs/rk3308_codec.c
@@ -0,0 +1,1012 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Rockchip RK3308 internal audio codec driver
+ *
+ * Copyright (c) 2018, Fuzhou Rockchip Electronics Co., Ltd All rights reserved.
+ * Copyright (c) 2023, Vivax-Metrotech Ltd
+ */
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <linux/util_macros.h>
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+#include <sound/tlv.h>
+
+#include "rk3308_codec.h"
+
+#define ADC_LR_GROUP_MAX		4
+
+#define GRF_CHIP_ID			0x800
+
+enum {
+	ACODEC_VERSION_A = 'A',
+	ACODEC_VERSION_B,
+	ACODEC_VERSION_C,
+};
+
+enum {
+	DAC_LINEOUT = 0,
+	DAC_HPOUT = 1,
+	DAC_LINEOUT_HPOUT = 11,
+};
+
+struct rk3308_codec_priv {
+	const struct device *dev;
+	struct regmap *regmap;
+	struct regmap *grf;
+	struct reset_control *reset;
+	struct clk *hclk;
+	struct clk *mclk_rx;
+	struct clk *mclk_tx;
+	struct snd_soc_component *component;
+	u32 codec_ver;
+};
+
+static const DECLARE_TLV_DB_SCALE(rk3308_codec_adc_alc_gain_tlv,   -1800, 150, 0);
+static const DECLARE_TLV_DB_SCALE(rk3308_codec_dac_hpout_gain_tlv, -3900, 150, 0);
+static const DECLARE_TLV_DB_SCALE(rk3308_codec_dac_hpmix_gain_tlv,  -600, 600, 0);
+
+static const DECLARE_TLV_DB_RANGE(rk3308_codec_dac_lineout_gain_tlv,
+	0, 0, TLV_DB_SCALE_ITEM(-600, 0, 0),
+	1, 1, TLV_DB_SCALE_ITEM(-300, 0, 0),
+	2, 2, TLV_DB_SCALE_ITEM(-150, 0, 0),
+	3, 3, TLV_DB_SCALE_ITEM(0,    0, 0),
+);
+
+static const char * const rk3308_codec_hpf_cutoff_text[] = {
+	"20 Hz", "245 Hz", "612 Hz"
+};
+
+static SOC_ENUM_SINGLE_DECL(rk3308_codec_hpf_cutoff_enum12, RK3308_ADC_DIG_CON04(0), 0,
+			    rk3308_codec_hpf_cutoff_text);
+static SOC_ENUM_SINGLE_DECL(rk3308_codec_hpf_cutoff_enum34, RK3308_ADC_DIG_CON04(1), 0,
+			    rk3308_codec_hpf_cutoff_text);
+static SOC_ENUM_SINGLE_DECL(rk3308_codec_hpf_cutoff_enum56, RK3308_ADC_DIG_CON04(2), 0,
+			    rk3308_codec_hpf_cutoff_text);
+static SOC_ENUM_SINGLE_DECL(rk3308_codec_hpf_cutoff_enum78, RK3308_ADC_DIG_CON04(3), 0,
+			    rk3308_codec_hpf_cutoff_text);
+
+static const struct snd_kcontrol_new rk3308_codec_controls[] = {
+	/* Despite the register names, these set the gain when AGC is OFF */
+	SOC_SINGLE_RANGE_TLV("MIC1 Capture Volume",
+			     RK3308_ADC_ANA_CON03(0),
+			     RK3308_ADC_CH1_ALC_GAIN_SFT,
+			     RK3308_ADC_CH1_ALC_GAIN_MIN,
+			     RK3308_ADC_CH1_ALC_GAIN_MAX,
+			     0, rk3308_codec_adc_alc_gain_tlv),
+	SOC_SINGLE_RANGE_TLV("MIC2 Capture Volume",
+			     RK3308_ADC_ANA_CON04(0),
+			     RK3308_ADC_CH2_ALC_GAIN_SFT,
+			     RK3308_ADC_CH2_ALC_GAIN_MIN,
+			     RK3308_ADC_CH2_ALC_GAIN_MAX,
+			     0, rk3308_codec_adc_alc_gain_tlv),
+	SOC_SINGLE_RANGE_TLV("MIC3 Capture Volume",
+			     RK3308_ADC_ANA_CON03(1),
+			     RK3308_ADC_CH1_ALC_GAIN_SFT,
+			     RK3308_ADC_CH1_ALC_GAIN_MIN,
+			     RK3308_ADC_CH1_ALC_GAIN_MAX,
+			     0, rk3308_codec_adc_alc_gain_tlv),
+	SOC_SINGLE_RANGE_TLV("MIC4 Capture Volume",
+			     RK3308_ADC_ANA_CON04(1),
+			     RK3308_ADC_CH2_ALC_GAIN_SFT,
+			     RK3308_ADC_CH2_ALC_GAIN_MIN,
+			     RK3308_ADC_CH2_ALC_GAIN_MAX,
+			     0, rk3308_codec_adc_alc_gain_tlv),
+	SOC_SINGLE_RANGE_TLV("MIC5 Capture Volume",
+			     RK3308_ADC_ANA_CON03(2),
+			     RK3308_ADC_CH1_ALC_GAIN_SFT,
+			     RK3308_ADC_CH1_ALC_GAIN_MIN,
+			     RK3308_ADC_CH1_ALC_GAIN_MAX,
+			     0, rk3308_codec_adc_alc_gain_tlv),
+	SOC_SINGLE_RANGE_TLV("MIC6 Capture Volume",
+			     RK3308_ADC_ANA_CON04(2),
+			     RK3308_ADC_CH2_ALC_GAIN_SFT,
+			     RK3308_ADC_CH2_ALC_GAIN_MIN,
+			     RK3308_ADC_CH2_ALC_GAIN_MAX,
+			     0, rk3308_codec_adc_alc_gain_tlv),
+	SOC_SINGLE_RANGE_TLV("MIC7 Capture Volume",
+			     RK3308_ADC_ANA_CON03(3),
+			     RK3308_ADC_CH1_ALC_GAIN_SFT,
+			     RK3308_ADC_CH1_ALC_GAIN_MIN,
+			     RK3308_ADC_CH1_ALC_GAIN_MAX,
+			     0, rk3308_codec_adc_alc_gain_tlv),
+	SOC_SINGLE_RANGE_TLV("MIC8 Capture Volume",
+			     RK3308_ADC_ANA_CON04(3),
+			     RK3308_ADC_CH2_ALC_GAIN_SFT,
+			     RK3308_ADC_CH2_ALC_GAIN_MIN,
+			     RK3308_ADC_CH2_ALC_GAIN_MAX,
+			     0, rk3308_codec_adc_alc_gain_tlv),
+
+	SOC_SINGLE("MIC1 Capture Switch", RK3308_ADC_ANA_CON00(0), 3, 1, 0),
+	SOC_SINGLE("MIC2 Capture Switch", RK3308_ADC_ANA_CON00(0), 7, 1, 0),
+	SOC_SINGLE("MIC3 Capture Switch", RK3308_ADC_ANA_CON00(1), 3, 1, 0),
+	SOC_SINGLE("MIC4 Capture Switch", RK3308_ADC_ANA_CON00(1), 7, 1, 0),
+	SOC_SINGLE("MIC5 Capture Switch", RK3308_ADC_ANA_CON00(2), 3, 1, 0),
+	SOC_SINGLE("MIC6 Capture Switch", RK3308_ADC_ANA_CON00(2), 7, 1, 0),
+	SOC_SINGLE("MIC7 Capture Switch", RK3308_ADC_ANA_CON00(3), 3, 1, 0),
+	SOC_SINGLE("MIC8 Capture Switch", RK3308_ADC_ANA_CON00(3), 7, 1, 0),
+
+	SOC_SINGLE("MIC12 HPF Capture Switch", RK3308_ADC_DIG_CON04(0), 2, 1, 1),
+	SOC_SINGLE("MIC34 HPF Capture Switch", RK3308_ADC_DIG_CON04(1), 2, 1, 1),
+	SOC_SINGLE("MIC56 HPF Capture Switch", RK3308_ADC_DIG_CON04(2), 2, 1, 1),
+	SOC_SINGLE("MIC78 HPF Capture Switch", RK3308_ADC_DIG_CON04(3), 2, 1, 1),
+
+	SOC_ENUM("MIC12 HPF Cutoff", rk3308_codec_hpf_cutoff_enum12),
+	SOC_ENUM("MIC34 HPF Cutoff", rk3308_codec_hpf_cutoff_enum34),
+	SOC_ENUM("MIC56 HPF Cutoff", rk3308_codec_hpf_cutoff_enum56),
+	SOC_ENUM("MIC78 HPF Cutoff", rk3308_codec_hpf_cutoff_enum78),
+
+	SOC_DOUBLE_TLV("Line Out Playback Volume",
+		       RK3308_DAC_ANA_CON04,
+		       RK3308_DAC_L_LINEOUT_GAIN_SFT,
+		       RK3308_DAC_R_LINEOUT_GAIN_SFT,
+		       RK3308_DAC_x_LINEOUT_GAIN_MAX,
+		       0, rk3308_codec_dac_lineout_gain_tlv),
+	SOC_DOUBLE("Line Out Playback Switch",
+		   RK3308_DAC_ANA_CON04,
+		   RK3308_DAC_L_LINEOUT_MUTE_SFT,
+		   RK3308_DAC_R_LINEOUT_MUTE_SFT, 1, 0),
+	SOC_DOUBLE_R_TLV("Headphone Playback Volume",
+			 RK3308_DAC_ANA_CON05,
+			 RK3308_DAC_ANA_CON06,
+			 RK3308_DAC_x_HPOUT_GAIN_SFT,
+			 RK3308_DAC_x_HPOUT_GAIN_MAX,
+			 0, rk3308_codec_dac_hpout_gain_tlv),
+	SOC_DOUBLE("Headphone Playback Switch",
+		   RK3308_DAC_ANA_CON03,
+		   RK3308_DAC_L_HPOUT_MUTE_SFT,
+		   RK3308_DAC_R_HPOUT_MUTE_SFT, 1, 0),
+	SOC_DOUBLE_RANGE_TLV("DAC HPMIX Playback Volume",
+			     RK3308_DAC_ANA_CON12,
+			     RK3308_DAC_L_HPMIX_GAIN_SFT,
+			     RK3308_DAC_R_HPMIX_GAIN_SFT,
+			     1, 2, 0, rk3308_codec_dac_hpmix_gain_tlv),
+};
+
+static int rk3308_codec_pop_sound_set(struct snd_soc_dapm_widget *w,
+				      struct snd_kcontrol *kcontrol,
+				      int event)
+{
+	struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm);
+	struct rk3308_codec_priv *rk3308 = snd_soc_component_get_drvdata(component);
+	unsigned int val = (event == SND_SOC_DAPM_POST_PMU) ?
+		RK3308_DAC_HPOUT_POP_SOUND_x_WORK :
+		RK3308_DAC_HPOUT_POP_SOUND_x_INIT;
+	unsigned int mask = RK3308_DAC_HPOUT_POP_SOUND_x_MSK;
+
+	regmap_update_bits(rk3308->regmap, RK3308_DAC_ANA_CON01,
+			   mask << w->shift, val << w->shift);
+
+	return 0;
+}
+
+static const struct snd_soc_dapm_widget rk3308_codec_dapm_widgets[] = {
+	SND_SOC_DAPM_INPUT("MIC1"),
+	SND_SOC_DAPM_INPUT("MIC2"),
+	SND_SOC_DAPM_INPUT("MIC3"),
+	SND_SOC_DAPM_INPUT("MIC4"),
+	SND_SOC_DAPM_INPUT("MIC5"),
+	SND_SOC_DAPM_INPUT("MIC6"),
+	SND_SOC_DAPM_INPUT("MIC7"),
+	SND_SOC_DAPM_INPUT("MIC8"),
+
+	SND_SOC_DAPM_SUPPLY("ADC_CURRENT_EN12", RK3308_ADC_ANA_CON06(0), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC_CURRENT_EN34", RK3308_ADC_ANA_CON06(1), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC_CURRENT_EN56", RK3308_ADC_ANA_CON06(2), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC_CURRENT_EN78", RK3308_ADC_ANA_CON06(3), 0, 0, NULL, 0),
+
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC1_EN", RK3308_ADC_ANA_CON00(0), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC2_EN", RK3308_ADC_ANA_CON00(0), 5, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC3_EN", RK3308_ADC_ANA_CON00(1), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC4_EN", RK3308_ADC_ANA_CON00(1), 5, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC5_EN", RK3308_ADC_ANA_CON00(2), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC6_EN", RK3308_ADC_ANA_CON00(2), 5, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC7_EN", RK3308_ADC_ANA_CON00(3), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC8_EN", RK3308_ADC_ANA_CON00(3), 5, 1, 1, 0),
+
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC1_WORK", RK3308_ADC_ANA_CON00(0), 2, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC2_WORK", RK3308_ADC_ANA_CON00(0), 6, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC3_WORK", RK3308_ADC_ANA_CON00(1), 2, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC4_WORK", RK3308_ADC_ANA_CON00(1), 6, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC5_WORK", RK3308_ADC_ANA_CON00(2), 2, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC6_WORK", RK3308_ADC_ANA_CON00(2), 6, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC7_WORK", RK3308_ADC_ANA_CON00(3), 2, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_mic, "MIC8_WORK", RK3308_ADC_ANA_CON00(3), 6, 1, 1, 0),
+
+	/*
+	 * In theory MIC1 and MIC2 can switch to LINE IN, but this is not
+	 * supported so all we can do is enabling the MIC input.
+	 */
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "CH1_IN_SEL", RK3308_ADC_ANA_CON07(0), 4, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "CH2_IN_SEL", RK3308_ADC_ANA_CON07(0), 6, 1, 1, 0),
+
+	SND_SOC_DAPM_SUPPLY("ADC1_BUF_REF_EN", RK3308_ADC_ANA_CON00(0), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC2_BUF_REF_EN", RK3308_ADC_ANA_CON00(0), 4, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC3_BUF_REF_EN", RK3308_ADC_ANA_CON00(1), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC4_BUF_REF_EN", RK3308_ADC_ANA_CON00(1), 4, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC5_BUF_REF_EN", RK3308_ADC_ANA_CON00(2), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC6_BUF_REF_EN", RK3308_ADC_ANA_CON00(2), 4, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC7_BUF_REF_EN", RK3308_ADC_ANA_CON00(3), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC8_BUF_REF_EN", RK3308_ADC_ANA_CON00(3), 4, 0, NULL, 0),
+
+	SND_SOC_DAPM_SUPPLY("ADC_MCLK_GATE", RK3308_GLB_CON, 5, 1, NULL, 0),
+
+	SND_SOC_DAPM_SUPPLY("ADC1_CLK_EN", RK3308_ADC_ANA_CON05(0), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC2_CLK_EN", RK3308_ADC_ANA_CON05(0), 4, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC3_CLK_EN", RK3308_ADC_ANA_CON05(1), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC4_CLK_EN", RK3308_ADC_ANA_CON05(1), 4, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC5_CLK_EN", RK3308_ADC_ANA_CON05(2), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC6_CLK_EN", RK3308_ADC_ANA_CON05(2), 4, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC7_CLK_EN", RK3308_ADC_ANA_CON05(3), 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("ADC8_CLK_EN", RK3308_ADC_ANA_CON05(3), 4, 0, NULL, 0),
+
+	// The "ALC" name from the TRM is misleading, these are needed even without ALC/AGC
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC1_EN", RK3308_ADC_ANA_CON02(0), 0, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC2_EN", RK3308_ADC_ANA_CON02(0), 4, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC3_EN", RK3308_ADC_ANA_CON02(1), 0, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC4_EN", RK3308_ADC_ANA_CON02(1), 4, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC5_EN", RK3308_ADC_ANA_CON02(2), 0, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC6_EN", RK3308_ADC_ANA_CON02(2), 4, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC7_EN", RK3308_ADC_ANA_CON02(3), 0, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC8_EN", RK3308_ADC_ANA_CON02(3), 4, 1, 1, 0),
+
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ADC1_EN", RK3308_ADC_ANA_CON05(0), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ADC2_EN", RK3308_ADC_ANA_CON05(0), 5, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ADC3_EN", RK3308_ADC_ANA_CON05(1), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ADC4_EN", RK3308_ADC_ANA_CON05(1), 5, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ADC5_EN", RK3308_ADC_ANA_CON05(2), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ADC6_EN", RK3308_ADC_ANA_CON05(2), 5, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ADC7_EN", RK3308_ADC_ANA_CON05(3), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ADC8_EN", RK3308_ADC_ANA_CON05(3), 5, 1, 1, 0),
+
+	SND_SOC_DAPM_ADC("ADC1_WORK", "Capture", RK3308_ADC_ANA_CON05(0), 2, 0),
+	SND_SOC_DAPM_ADC("ADC2_WORK", "Capture", RK3308_ADC_ANA_CON05(0), 6, 0),
+	SND_SOC_DAPM_ADC("ADC3_WORK", "Capture", RK3308_ADC_ANA_CON05(1), 2, 0),
+	SND_SOC_DAPM_ADC("ADC4_WORK", "Capture", RK3308_ADC_ANA_CON05(1), 6, 0),
+	SND_SOC_DAPM_ADC("ADC5_WORK", "Capture", RK3308_ADC_ANA_CON05(2), 2, 0),
+	SND_SOC_DAPM_ADC("ADC6_WORK", "Capture", RK3308_ADC_ANA_CON05(2), 6, 0),
+	SND_SOC_DAPM_ADC("ADC7_WORK", "Capture", RK3308_ADC_ANA_CON05(3), 2, 0),
+	SND_SOC_DAPM_ADC("ADC8_WORK", "Capture", RK3308_ADC_ANA_CON05(3), 6, 0),
+
+	// The "ALC" name from the TRM is misleading, these are needed even without ALC/AGC
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC1_WORK", RK3308_ADC_ANA_CON02(0), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC2_WORK", RK3308_ADC_ANA_CON02(0), 5, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC3_WORK", RK3308_ADC_ANA_CON02(1), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC4_WORK", RK3308_ADC_ANA_CON02(1), 5, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC5_WORK", RK3308_ADC_ANA_CON02(2), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC6_WORK", RK3308_ADC_ANA_CON02(2), 5, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC7_WORK", RK3308_ADC_ANA_CON02(3), 1, 1, 1, 0),
+	SND_SOC_DAPM_REG(snd_soc_dapm_adc, "ALC8_WORK", RK3308_ADC_ANA_CON02(3), 5, 1, 1, 0),
+
+	SND_SOC_DAPM_SUPPLY("MICBIAS Current", RK3308_ADC_ANA_CON08(0), 4, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("MICBIAS1", RK3308_ADC_ANA_CON07(1), 3, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("MICBIAS2", RK3308_ADC_ANA_CON07(2), 3, 0, NULL, 0),
+
+	SND_SOC_DAPM_OUT_DRV("DAC_L_HPMIX_EN",   RK3308_DAC_ANA_CON13, 0, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("DAC_R_HPMIX_EN",   RK3308_DAC_ANA_CON13, 4, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("DAC_L_HPMIX_WORK", RK3308_DAC_ANA_CON13, 1, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("DAC_R_HPMIX_WORK", RK3308_DAC_ANA_CON13, 5, 0, NULL, 0),
+	/* HPMIX is not actually acting as a mixer as the only supported input is I2S */
+	SND_SOC_DAPM_OUT_DRV("DAC_L_HPMIX_SEL",  RK3308_DAC_ANA_CON12, 2, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("DAC_R_HPMIX_SEL",  RK3308_DAC_ANA_CON12, 6, 0, NULL, 0),
+	SND_SOC_DAPM_MIXER("DAC HPMIX Left",     RK3308_DAC_ANA_CON13, 2, 0, NULL, 0),
+	SND_SOC_DAPM_MIXER("DAC HPMIX Right",    RK3308_DAC_ANA_CON13, 6, 0, NULL, 0),
+
+	SND_SOC_DAPM_SUPPLY("DAC_MCLK_GATE", RK3308_GLB_CON, 4, 1, NULL, 0),
+
+	SND_SOC_DAPM_SUPPLY("DAC_CURRENT_EN", RK3308_DAC_ANA_CON00, 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("DAC_L_REF_EN",   RK3308_DAC_ANA_CON02, 0, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("DAC_R_REF_EN",   RK3308_DAC_ANA_CON02, 4, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("DAC_L_CLK_EN",   RK3308_DAC_ANA_CON02, 1, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("DAC_R_CLK_EN",   RK3308_DAC_ANA_CON02, 5, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("DAC_L_DAC_EN",  RK3308_DAC_ANA_CON02, 2, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("DAC_R_DAC_EN",  RK3308_DAC_ANA_CON02, 6, 0, NULL, 0),
+	SND_SOC_DAPM_DAC("DAC_L_DAC_WORK", NULL, RK3308_DAC_ANA_CON02, 3, 0),
+	SND_SOC_DAPM_DAC("DAC_R_DAC_WORK", NULL, RK3308_DAC_ANA_CON02, 7, 0),
+
+	SND_SOC_DAPM_SUPPLY("DAC_BUF_REF_L", RK3308_DAC_ANA_CON01, 2, 0, NULL, 0),
+	SND_SOC_DAPM_SUPPLY("DAC_BUF_REF_R", RK3308_DAC_ANA_CON01, 6, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV_E("HPOUT_POP_SOUND_L", SND_SOC_NOPM, 0, 0, NULL, 0,
+			       rk3308_codec_pop_sound_set,
+			       SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD),
+	SND_SOC_DAPM_OUT_DRV_E("HPOUT_POP_SOUND_R", SND_SOC_NOPM, 4, 0, NULL, 0,
+			       rk3308_codec_pop_sound_set,
+			       SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD),
+	SND_SOC_DAPM_OUT_DRV("L_HPOUT_EN", RK3308_DAC_ANA_CON03, 1, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("R_HPOUT_EN", RK3308_DAC_ANA_CON03, 5, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("L_HPOUT_WORK", RK3308_DAC_ANA_CON03, 2, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("R_HPOUT_WORK", RK3308_DAC_ANA_CON03, 6, 0, NULL, 0),
+	SND_SOC_DAPM_OUTPUT("HPOUT_L"),
+	SND_SOC_DAPM_OUTPUT("HPOUT_R"),
+
+	SND_SOC_DAPM_OUT_DRV("L_LINEOUT_EN", RK3308_DAC_ANA_CON04, 0, 0, NULL, 0),
+	SND_SOC_DAPM_OUT_DRV("R_LINEOUT_EN", RK3308_DAC_ANA_CON04, 4, 0, NULL, 0),
+	SND_SOC_DAPM_OUTPUT("LINEOUT_L"),
+	SND_SOC_DAPM_OUTPUT("LINEOUT_R"),
+};
+
+static const struct snd_soc_dapm_route rk3308_codec_dapm_routes[] = {
+	{ "MICBIAS1", NULL, "MICBIAS Current" },
+	{ "MICBIAS2", NULL, "MICBIAS Current" },
+
+	{ "MIC1_EN", NULL, "MIC1" },
+	{ "MIC2_EN", NULL, "MIC2" },
+	{ "MIC3_EN", NULL, "MIC3" },
+	{ "MIC4_EN", NULL, "MIC4" },
+	{ "MIC5_EN", NULL, "MIC5" },
+	{ "MIC6_EN", NULL, "MIC6" },
+	{ "MIC7_EN", NULL, "MIC7" },
+	{ "MIC8_EN", NULL, "MIC8" },
+
+	{ "MIC1_WORK", NULL, "MIC1_EN" },
+	{ "MIC2_WORK", NULL, "MIC2_EN" },
+	{ "MIC3_WORK", NULL, "MIC3_EN" },
+	{ "MIC4_WORK", NULL, "MIC4_EN" },
+	{ "MIC5_WORK", NULL, "MIC5_EN" },
+	{ "MIC6_WORK", NULL, "MIC6_EN" },
+	{ "MIC7_WORK", NULL, "MIC7_EN" },
+	{ "MIC8_WORK", NULL, "MIC8_EN" },
+
+	{ "CH1_IN_SEL", NULL, "MIC1_WORK" },
+	{ "CH2_IN_SEL", NULL, "MIC2_WORK" },
+
+	{ "ALC1_EN", NULL, "CH1_IN_SEL" },
+	{ "ALC2_EN", NULL, "CH2_IN_SEL" },
+	{ "ALC3_EN", NULL, "MIC3_WORK" },
+	{ "ALC4_EN", NULL, "MIC4_WORK" },
+	{ "ALC5_EN", NULL, "MIC5_WORK" },
+	{ "ALC6_EN", NULL, "MIC6_WORK" },
+	{ "ALC7_EN", NULL, "MIC7_WORK" },
+	{ "ALC8_EN", NULL, "MIC8_WORK" },
+
+	{ "ADC1_EN", NULL, "ALC1_EN" },
+	{ "ADC2_EN", NULL, "ALC2_EN" },
+	{ "ADC3_EN", NULL, "ALC3_EN" },
+	{ "ADC4_EN", NULL, "ALC4_EN" },
+	{ "ADC5_EN", NULL, "ALC5_EN" },
+	{ "ADC6_EN", NULL, "ALC6_EN" },
+	{ "ADC7_EN", NULL, "ALC7_EN" },
+	{ "ADC8_EN", NULL, "ALC8_EN" },
+
+	{ "ADC1_WORK", NULL, "ADC1_EN" },
+	{ "ADC2_WORK", NULL, "ADC2_EN" },
+	{ "ADC3_WORK", NULL, "ADC3_EN" },
+	{ "ADC4_WORK", NULL, "ADC4_EN" },
+	{ "ADC5_WORK", NULL, "ADC5_EN" },
+	{ "ADC6_WORK", NULL, "ADC6_EN" },
+	{ "ADC7_WORK", NULL, "ADC7_EN" },
+	{ "ADC8_WORK", NULL, "ADC8_EN" },
+
+	{ "ADC1_BUF_REF_EN", NULL, "ADC_CURRENT_EN12" },
+	{ "ADC2_BUF_REF_EN", NULL, "ADC_CURRENT_EN12" },
+	{ "ADC3_BUF_REF_EN", NULL, "ADC_CURRENT_EN34" },
+	{ "ADC4_BUF_REF_EN", NULL, "ADC_CURRENT_EN34" },
+	{ "ADC5_BUF_REF_EN", NULL, "ADC_CURRENT_EN56" },
+	{ "ADC6_BUF_REF_EN", NULL, "ADC_CURRENT_EN56" },
+	{ "ADC7_BUF_REF_EN", NULL, "ADC_CURRENT_EN78" },
+	{ "ADC8_BUF_REF_EN", NULL, "ADC_CURRENT_EN78" },
+
+	{ "ADC1_WORK", NULL, "ADC1_BUF_REF_EN" },
+	{ "ADC2_WORK", NULL, "ADC2_BUF_REF_EN" },
+	{ "ADC3_WORK", NULL, "ADC3_BUF_REF_EN" },
+	{ "ADC4_WORK", NULL, "ADC4_BUF_REF_EN" },
+	{ "ADC5_WORK", NULL, "ADC5_BUF_REF_EN" },
+	{ "ADC6_WORK", NULL, "ADC6_BUF_REF_EN" },
+	{ "ADC7_WORK", NULL, "ADC7_BUF_REF_EN" },
+	{ "ADC8_WORK", NULL, "ADC8_BUF_REF_EN" },
+
+	{ "ADC1_CLK_EN", NULL, "ADC_MCLK_GATE" },
+	{ "ADC2_CLK_EN", NULL, "ADC_MCLK_GATE" },
+	{ "ADC3_CLK_EN", NULL, "ADC_MCLK_GATE" },
+	{ "ADC4_CLK_EN", NULL, "ADC_MCLK_GATE" },
+	{ "ADC5_CLK_EN", NULL, "ADC_MCLK_GATE" },
+	{ "ADC6_CLK_EN", NULL, "ADC_MCLK_GATE" },
+	{ "ADC7_CLK_EN", NULL, "ADC_MCLK_GATE" },
+	{ "ADC8_CLK_EN", NULL, "ADC_MCLK_GATE" },
+
+	{ "ADC1_WORK", NULL, "ADC1_CLK_EN" },
+	{ "ADC2_WORK", NULL, "ADC2_CLK_EN" },
+	{ "ADC3_WORK", NULL, "ADC3_CLK_EN" },
+	{ "ADC4_WORK", NULL, "ADC4_CLK_EN" },
+	{ "ADC5_WORK", NULL, "ADC5_CLK_EN" },
+	{ "ADC6_WORK", NULL, "ADC6_CLK_EN" },
+	{ "ADC7_WORK", NULL, "ADC7_CLK_EN" },
+	{ "ADC8_WORK", NULL, "ADC8_CLK_EN" },
+
+	{ "ALC1_WORK", NULL, "ADC1_WORK" },
+	{ "ALC2_WORK", NULL, "ADC2_WORK" },
+	{ "ALC3_WORK", NULL, "ADC3_WORK" },
+	{ "ALC4_WORK", NULL, "ADC4_WORK" },
+	{ "ALC5_WORK", NULL, "ADC5_WORK" },
+	{ "ALC6_WORK", NULL, "ADC6_WORK" },
+	{ "ALC7_WORK", NULL, "ADC7_WORK" },
+	{ "ALC8_WORK", NULL, "ADC8_WORK" },
+
+	{ "HiFi Capture", NULL, "ALC1_WORK" },
+	{ "HiFi Capture", NULL, "ALC2_WORK" },
+	{ "HiFi Capture", NULL, "ALC3_WORK" },
+	{ "HiFi Capture", NULL, "ALC4_WORK" },
+	{ "HiFi Capture", NULL, "ALC5_WORK" },
+	{ "HiFi Capture", NULL, "ALC6_WORK" },
+	{ "HiFi Capture", NULL, "ALC7_WORK" },
+	{ "HiFi Capture", NULL, "ALC8_WORK" },
+
+	{ "DAC_L_HPMIX_EN", NULL, "HiFi Playback" },
+	{ "DAC_R_HPMIX_EN", NULL, "HiFi Playback" },
+	{ "DAC_L_HPMIX_WORK", NULL, "DAC_L_HPMIX_EN" },
+	{ "DAC_R_HPMIX_WORK", NULL, "DAC_R_HPMIX_EN" },
+	{ "DAC HPMIX Left",  NULL, "DAC_L_HPMIX_WORK" },
+	{ "DAC HPMIX Right", NULL, "DAC_R_HPMIX_WORK" },
+
+	{ "DAC_L_DAC_EN", NULL, "DAC HPMIX Left"  },
+	{ "DAC_R_DAC_EN", NULL, "DAC HPMIX Right" },
+
+	{ "DAC_L_REF_EN", NULL, "DAC_CURRENT_EN" },
+	{ "DAC_R_REF_EN", NULL, "DAC_CURRENT_EN" },
+	{ "DAC_L_CLK_EN", NULL, "DAC_L_REF_EN" },
+	{ "DAC_R_CLK_EN", NULL, "DAC_R_REF_EN" },
+	{ "DAC_L_CLK_EN", NULL, "DAC_MCLK_GATE" },
+	{ "DAC_R_CLK_EN", NULL, "DAC_MCLK_GATE" },
+	{ "DAC_L_DAC_EN", NULL, "DAC_L_CLK_EN" },
+	{ "DAC_R_DAC_EN", NULL, "DAC_R_CLK_EN" },
+	{ "DAC_L_DAC_WORK", NULL, "DAC_L_DAC_EN" },
+	{ "DAC_R_DAC_WORK", NULL, "DAC_R_DAC_EN" },
+	{ "DAC_L_HPMIX_SEL", NULL, "DAC_L_DAC_WORK" },
+	{ "DAC_R_HPMIX_SEL", NULL, "DAC_R_DAC_WORK" },
+
+	{ "HPOUT_L", NULL, "DAC_BUF_REF_L" },
+	{ "HPOUT_R", NULL, "DAC_BUF_REF_R" },
+	{ "L_HPOUT_EN", NULL, "DAC_L_HPMIX_SEL" },
+	{ "R_HPOUT_EN", NULL, "DAC_R_HPMIX_SEL" },
+	{ "L_HPOUT_WORK", NULL, "L_HPOUT_EN" },
+	{ "R_HPOUT_WORK", NULL, "R_HPOUT_EN" },
+	{ "HPOUT_POP_SOUND_L", NULL, "L_HPOUT_WORK" },
+	{ "HPOUT_POP_SOUND_R", NULL, "R_HPOUT_WORK" },
+	{ "HPOUT_L", NULL, "HPOUT_POP_SOUND_L" },
+	{ "HPOUT_R", NULL, "HPOUT_POP_SOUND_R" },
+
+	{ "L_LINEOUT_EN", NULL, "DAC_L_HPMIX_SEL" },
+	{ "R_LINEOUT_EN", NULL, "DAC_R_HPMIX_SEL" },
+	{ "LINEOUT_L", NULL, "L_LINEOUT_EN" },
+	{ "LINEOUT_R", NULL, "R_LINEOUT_EN" },
+};
+
+static int rk3308_codec_set_dai_fmt(struct snd_soc_dai *codec_dai,
+				    unsigned int fmt)
+{
+	struct snd_soc_component *component = codec_dai->component;
+	struct rk3308_codec_priv *rk3308 = snd_soc_component_get_drvdata(component);
+	const unsigned int inv_bits = fmt & SND_SOC_DAIFMT_INV_MASK;
+	const bool inv_bitclk =
+		(inv_bits & SND_SOC_DAIFMT_IB_IF) ||
+		(inv_bits & SND_SOC_DAIFMT_IB_NF);
+	const bool inv_frmclk =
+		(inv_bits & SND_SOC_DAIFMT_IB_IF) ||
+		(inv_bits & SND_SOC_DAIFMT_NB_IF);
+	const unsigned int dac_master_bits = rk3308->codec_ver < ACODEC_VERSION_C ?
+		RK3308_DAC_IO_MODE_MASTER   | RK3308_DAC_MODE_MASTER  :
+		RK3308BS_DAC_IO_MODE_MASTER | RK3308BS_DAC_MODE_MASTER;
+	unsigned int adc_aif1 = 0, adc_aif2 = 0, dac_aif1 = 0, dac_aif2 = 0;
+	bool is_master = false;
+	int grp;
+
+	switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+	case SND_SOC_DAIFMT_CBC_CFC:
+		break;
+	case SND_SOC_DAIFMT_CBP_CFP:
+		adc_aif2 |= RK3308_ADC_IO_MODE_MASTER;
+		adc_aif2 |= RK3308_ADC_MODE_MASTER;
+		dac_aif2 |= dac_master_bits;
+		is_master = true;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+	case SND_SOC_DAIFMT_DSP_A:
+		adc_aif1 |= RK3308_ADC_I2S_MODE_PCM;
+		dac_aif1 |= RK3308_DAC_I2S_MODE_PCM;
+		break;
+	case SND_SOC_DAIFMT_I2S:
+		adc_aif1 |= RK3308_ADC_I2S_MODE_I2S;
+		dac_aif1 |= RK3308_DAC_I2S_MODE_I2S;
+		break;
+	case SND_SOC_DAIFMT_RIGHT_J:
+		adc_aif1 |= RK3308_ADC_I2S_MODE_RJ;
+		dac_aif1 |= RK3308_DAC_I2S_MODE_RJ;
+		break;
+	case SND_SOC_DAIFMT_LEFT_J:
+		adc_aif1 |= RK3308_ADC_I2S_MODE_LJ;
+		dac_aif1 |= RK3308_DAC_I2S_MODE_LJ;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	if (inv_bitclk) {
+		adc_aif2 |= RK3308_ADC_I2S_BIT_CLK_POL_REVERSAL;
+		dac_aif2 |= RK3308_DAC_I2S_BIT_CLK_POL_REVERSAL;
+	}
+
+	if (inv_frmclk) {
+		adc_aif1 |= RK3308_ADC_I2S_LRC_POL_REVERSAL;
+		dac_aif1 |= RK3308_DAC_I2S_LRC_POL_REVERSAL;
+	}
+
+	/*
+	 * Hold ADC Digital registers start at master mode
+	 *
+	 * There are 8 ADCs which use the same internal SCLK and LRCK for
+	 * master mode. We need to make sure that they are in effect at the
+	 * same time, otherwise they will cause abnormal clocks.
+	 */
+	if (is_master)
+		regmap_clear_bits(rk3308->regmap, RK3308_GLB_CON, RK3308_ADC_DIG_WORK);
+
+	for (grp = 0; grp < ADC_LR_GROUP_MAX; grp++) {
+		regmap_update_bits(rk3308->regmap, RK3308_ADC_DIG_CON01(grp),
+				   RK3308_ADC_I2S_LRC_POL_REVERSAL |
+				   RK3308_ADC_I2S_MODE_MSK,
+				   adc_aif1);
+		regmap_update_bits(rk3308->regmap, RK3308_ADC_DIG_CON02(grp),
+				   RK3308_ADC_IO_MODE_MASTER |
+				   RK3308_ADC_MODE_MASTER |
+				   RK3308_ADC_I2S_BIT_CLK_POL_REVERSAL,
+				   adc_aif2);
+	}
+
+	/* Hold ADC Digital registers end at master mode */
+	if (is_master)
+		regmap_set_bits(rk3308->regmap, RK3308_GLB_CON, RK3308_ADC_DIG_WORK);
+
+	regmap_update_bits(rk3308->regmap, RK3308_DAC_DIG_CON01,
+			   RK3308_DAC_I2S_LRC_POL_REVERSAL |
+			   RK3308_DAC_I2S_MODE_MSK,
+			   dac_aif1);
+	regmap_update_bits(rk3308->regmap, RK3308_DAC_DIG_CON02,
+			   dac_master_bits | RK3308_DAC_I2S_BIT_CLK_POL_REVERSAL,
+			   dac_aif2);
+
+	return 0;
+}
+
+static int rk3308_codec_dac_dig_config(struct rk3308_codec_priv *rk3308,
+				       struct snd_pcm_hw_params *params)
+{
+	unsigned int dac_aif1 = 0;
+
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S16_LE:
+		dac_aif1 |= RK3308_DAC_I2S_VALID_LEN_16BITS;
+		break;
+	case SNDRV_PCM_FORMAT_S20_3LE:
+		dac_aif1 |= RK3308_DAC_I2S_VALID_LEN_20BITS;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		dac_aif1 |= RK3308_DAC_I2S_VALID_LEN_24BITS;
+		break;
+	case SNDRV_PCM_FORMAT_S32_LE:
+		dac_aif1 |= RK3308_DAC_I2S_VALID_LEN_32BITS;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	regmap_update_bits(rk3308->regmap, RK3308_DAC_DIG_CON01,
+			   RK3308_DAC_I2S_VALID_LEN_MSK, dac_aif1);
+	regmap_set_bits(rk3308->regmap, RK3308_DAC_DIG_CON02, RK3308_DAC_I2S_WORK);
+
+	return 0;
+}
+
+static int rk3308_codec_adc_dig_config(struct rk3308_codec_priv *rk3308,
+				       struct snd_pcm_hw_params *params)
+{
+	unsigned int adc_aif1 = 0;
+	/*
+	 * grp 0 = ADC1 and ADC2
+	 * grp 1 = ADC3 and ADC4
+	 * grp 2 = ADC5 and ADC6
+	 * grp 3 = ADC7 and ADC8
+	 */
+	u32 used_adc_grps;
+	int grp;
+
+	switch (params_channels(params)) {
+	case 1:
+		adc_aif1 |= RK3308_ADC_I2S_MONO;
+		used_adc_grps = 1;
+		break;
+	case 2:
+	case 4:
+	case 6:
+	case 8:
+		used_adc_grps = params_channels(params) / 2;
+		break;
+	default:
+		dev_err(rk3308->dev, "Invalid channel number %d\n", params_channels(params));
+		return -EINVAL;
+	}
+
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S16_LE:
+		adc_aif1 |= RK3308_ADC_I2S_VALID_LEN_16BITS;
+		break;
+	case SNDRV_PCM_FORMAT_S20_3LE:
+		adc_aif1 |= RK3308_ADC_I2S_VALID_LEN_20BITS;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		adc_aif1 |= RK3308_ADC_I2S_VALID_LEN_24BITS;
+		break;
+	case SNDRV_PCM_FORMAT_S32_LE:
+		adc_aif1 |= RK3308_ADC_I2S_VALID_LEN_32BITS;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	for (grp = 0; grp < used_adc_grps; grp++) {
+		regmap_update_bits(rk3308->regmap,
+				   RK3308_ADC_DIG_CON03(grp),
+				   RK3308_ADC_L_CH_BIST_MSK | RK3308_ADC_R_CH_BIST_MSK,
+				   RK3308_ADC_L_CH_NORMAL_LEFT | RK3308_ADC_R_CH_NORMAL_RIGHT);
+		regmap_update_bits(rk3308->regmap, RK3308_ADC_DIG_CON01(grp),
+				   RK3308_ADC_I2S_VALID_LEN_MSK | RK3308_ADC_I2S_MONO, adc_aif1);
+		regmap_set_bits(rk3308->regmap, RK3308_ADC_DIG_CON02(grp), RK3308_ADC_I2S_WORK);
+	}
+
+	return 0;
+}
+
+static int rk3308_codec_hw_params(struct snd_pcm_substream *substream,
+				  struct snd_pcm_hw_params *params,
+				  struct snd_soc_dai *dai)
+{
+	struct snd_soc_component *component = dai->component;
+	struct rk3308_codec_priv *rk3308 = snd_soc_component_get_drvdata(component);
+
+	return (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) ?
+		rk3308_codec_dac_dig_config(rk3308, params) :
+		rk3308_codec_adc_dig_config(rk3308, params);
+}
+
+static const struct snd_soc_dai_ops rk3308_codec_dai_ops = {
+	.hw_params = rk3308_codec_hw_params,
+	.set_fmt = rk3308_codec_set_dai_fmt,
+};
+
+static struct snd_soc_dai_driver rk3308_codec_dai[] = {
+	{
+		.name = "rk3308-hifi",
+		.id = RK3308_HIFI,
+		.playback = {
+			.stream_name = "HiFi Playback",
+			.channels_min = 2,
+			.channels_max = 2,
+			.rates = SNDRV_PCM_RATE_8000_192000,
+			.formats = (SNDRV_PCM_FMTBIT_S16_LE |
+				    SNDRV_PCM_FMTBIT_S20_3LE |
+				    SNDRV_PCM_FMTBIT_S24_LE |
+				    SNDRV_PCM_FMTBIT_S32_LE),
+		},
+		.capture = {
+			.stream_name = "HiFi Capture",
+			.channels_min = 1,
+			.channels_max = 8,
+			.rates = SNDRV_PCM_RATE_8000_192000,
+			.formats = (SNDRV_PCM_FMTBIT_S16_LE |
+				    SNDRV_PCM_FMTBIT_S20_3LE |
+				    SNDRV_PCM_FMTBIT_S24_LE |
+				    SNDRV_PCM_FMTBIT_S32_LE),
+		},
+		.ops = &rk3308_codec_dai_ops,
+	},
+};
+
+static void rk3308_codec_reset(struct snd_soc_component *component)
+{
+	struct rk3308_codec_priv *rk3308 = snd_soc_component_get_drvdata(component);
+
+	reset_control_assert(rk3308->reset);
+	usleep_range(10000, 11000);     /* estimated value */
+	reset_control_deassert(rk3308->reset);
+
+	regmap_write(rk3308->regmap, RK3308_GLB_CON, 0x00);
+	usleep_range(10000, 11000);     /* estimated value */
+	regmap_write(rk3308->regmap, RK3308_GLB_CON,
+		     RK3308_SYS_WORK |
+		     RK3308_DAC_DIG_WORK |
+		     RK3308_ADC_DIG_WORK);
+}
+
+/*
+ * Initialize register whose default after HW reset is problematic or which
+ * are never modified.
+ */
+static int rk3308_codec_initialize(struct rk3308_codec_priv *rk3308)
+{
+	int grp;
+
+	/*
+	 * Init ADC digital vol to 0 dB (reset value is 0xff, undocumented).
+	 * Range: -97dB ~ +32dB.
+	 */
+	if (rk3308->codec_ver == ACODEC_VERSION_C) {
+		for (grp = 0; grp < ADC_LR_GROUP_MAX; grp++) {
+			regmap_write(rk3308->regmap, RK3308_ADC_DIG_CON05(grp),
+					   RK3308_ADC_DIG_VOL_CON_x_0DB);
+			regmap_write(rk3308->regmap, RK3308_ADC_DIG_CON06(grp),
+					   RK3308_ADC_DIG_VOL_CON_x_0DB);
+		}
+	}
+
+	/* set HPMIX default gains (reset value is 0, which is illegal) */
+	regmap_update_bits(rk3308->regmap, RK3308_DAC_ANA_CON12,
+			   RK3308_DAC_L_HPMIX_GAIN_MSK |
+			   RK3308_DAC_R_HPMIX_GAIN_MSK,
+			   RK3308_DAC_L_HPMIX_GAIN_NDB_6 |
+			   RK3308_DAC_R_HPMIX_GAIN_NDB_6);
+
+	/* recover DAC digital gain to 0 dB (reset value is 0xff, undocumented) */
+	if (rk3308->codec_ver == ACODEC_VERSION_C)
+		regmap_write(rk3308->regmap, RK3308_DAC_DIG_CON04,
+			     RK3308BS_DAC_DIG_GAIN_0DB);
+
+	/*
+	 * Unconditionally enable zero-cross detection (needed for AGC,
+	 * harmless without AGC)
+	 */
+	for (grp = 0; grp < ADC_LR_GROUP_MAX; grp++)
+		regmap_set_bits(rk3308->regmap, RK3308_ADC_ANA_CON02(grp),
+				RK3308_ADC_CH1_ZEROCROSS_DET_EN |
+				RK3308_ADC_CH2_ZEROCROSS_DET_EN);
+
+	return 0;
+}
+
+static int rk3308_codec_probe(struct snd_soc_component *component)
+{
+	struct rk3308_codec_priv *rk3308 = snd_soc_component_get_drvdata(component);
+
+	rk3308->component = component;
+
+	rk3308_codec_reset(component);
+	rk3308_codec_initialize(rk3308);
+
+	return 0;
+}
+
+static int rk3308_codec_set_bias_level(struct snd_soc_component *component,
+				       enum snd_soc_bias_level level)
+{
+	struct rk3308_codec_priv *rk3308 = snd_soc_component_get_drvdata(component);
+	unsigned int v;
+
+	switch (level) {
+	case SND_SOC_BIAS_ON:
+		break;
+	case SND_SOC_BIAS_PREPARE:
+		break;
+	case SND_SOC_BIAS_STANDBY:
+		if (snd_soc_component_get_bias_level(component) != SND_SOC_BIAS_OFF)
+			break;
+
+		/* Sequence from TRM Section 8.6.3 "Power Up" */
+		regmap_update_bits(rk3308->regmap, RK3308_ADC_ANA_CON10(0),
+				   RK3308_ADC_CURRENT_CHARGE_MSK,
+				   RK3308_ADC_SEL_I(0x1));
+		regmap_set_bits(rk3308->regmap, RK3308_ADC_ANA_CON10(0),
+				RK3308_ADC_REF_EN);
+		for (v = 0x1; v <= 0x7f; v++) {
+			regmap_update_bits(rk3308->regmap, RK3308_ADC_ANA_CON10(0),
+					   RK3308_ADC_CURRENT_CHARGE_MSK, v);
+			usleep_range(200, 400);
+		}
+		msleep(20);	/* estimated value */
+		break;
+	case SND_SOC_BIAS_OFF:
+		/* Sequence from TRM Section 8.6.4 "Power Down" */
+		regmap_update_bits(rk3308->regmap, RK3308_ADC_ANA_CON10(0),
+				   RK3308_ADC_CURRENT_CHARGE_MSK,
+				   RK3308_ADC_SEL_I(0x1));
+		regmap_clear_bits(rk3308->regmap, RK3308_ADC_ANA_CON10(0),
+				  RK3308_ADC_REF_EN);
+
+		for (v = 0x7f; v >= 0x1; v--) {
+			regmap_update_bits(rk3308->regmap, RK3308_ADC_ANA_CON10(0),
+					   RK3308_ADC_CURRENT_CHARGE_MSK, v);
+			usleep_range(200, 400);
+		}
+		msleep(20);	/* estimated value */
+		break;
+	}
+	return 0;
+}
+
+static const struct snd_soc_component_driver soc_codec_dev_rk3308 = {
+	.probe = rk3308_codec_probe,
+	.set_bias_level = rk3308_codec_set_bias_level,
+	.controls = rk3308_codec_controls,
+	.num_controls = ARRAY_SIZE(rk3308_codec_controls),
+	.dapm_widgets = rk3308_codec_dapm_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(rk3308_codec_dapm_widgets),
+	.dapm_routes = rk3308_codec_dapm_routes,
+	.num_dapm_routes = ARRAY_SIZE(rk3308_codec_dapm_routes),
+};
+
+static const struct regmap_config rk3308_codec_regmap_config = {
+	.reg_bits = 32,
+	.reg_stride = 4,
+	.val_bits = 32,
+	.max_register = RK3308_DAC_ANA_CON15,
+};
+
+static int rk3308_codec_get_version(struct rk3308_codec_priv *rk3308)
+{
+	unsigned int chip_id;
+	int err;
+
+	err = regmap_read(rk3308->grf, GRF_CHIP_ID, &chip_id);
+	if (err)
+		return err;
+
+	switch (chip_id) {
+	case 3306:
+		rk3308->codec_ver = ACODEC_VERSION_A;
+		break;
+	case 0x3308:
+		rk3308->codec_ver = ACODEC_VERSION_B;
+		return dev_err_probe(rk3308->dev, -EINVAL, "Chip version B not supported\n");
+	case 0x3308c:
+		rk3308->codec_ver = ACODEC_VERSION_C;
+		break;
+	default:
+		return dev_err_probe(rk3308->dev, -EINVAL, "Unknown chip_id: 0x%x\n", chip_id);
+	}
+
+	dev_info(rk3308->dev, "Found codec version %c\n", rk3308->codec_ver);
+	return 0;
+}
+
+static int rk3308_codec_set_micbias_level(struct rk3308_codec_priv *rk3308)
+{
+	struct device_node *np = rk3308->dev->of_node;
+	u32 percent;
+	u32 mult;
+	int err;
+
+	err = of_property_read_u32(np, "rockchip,micbias-avdd-percent", &percent);
+	if (err == -EINVAL)
+		return 0;
+	if (err)
+		return dev_err_probe(rk3308->dev, err,
+				     "Error reading 'rockchip,micbias-avdd-percent'\n");
+
+	/* Convert percent to register value, linerarly (50% -> 0, 5% step = +1) */
+	mult = (percent - 50) / 5;
+
+	/* Check range and that the percent was an exact value allowed */
+	if (mult > RK3308_ADC_LEVEL_RANGE_MICBIAS_MAX || mult * 5 + 50 != percent)
+		return dev_err_probe(rk3308->dev, -EINVAL,
+				     "Invalid value %u for 'rockchip,micbias-avdd-percent'\n",
+				     percent);
+
+	regmap_update_bits(rk3308->regmap, RK3308_ADC_ANA_CON07(0),
+			   RK3308_ADC_LEVEL_RANGE_MICBIAS_MSK,
+			   mult << RK3308_ADC_LEVEL_RANGE_MICBIAS_SFT);
+
+	return 0;
+}
+
+static int rk3308_codec_platform_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct rk3308_codec_priv *rk3308;
+	void __iomem *base;
+	int err;
+
+	rk3308 = devm_kzalloc(&pdev->dev, sizeof(*rk3308), GFP_KERNEL);
+	if (!rk3308)
+		return -ENOMEM;
+
+	rk3308->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(rk3308->grf))
+		return dev_err_probe(&pdev->dev, PTR_ERR(rk3308->grf),
+			"Missing 'rockchip,grf' property\n");
+
+	rk3308->dev = &pdev->dev;
+
+	rk3308->reset = devm_reset_control_get(&pdev->dev, "codec");
+	if (IS_ERR(rk3308->reset)) {
+		err = PTR_ERR(rk3308->reset);
+		if (err != -ENOENT)
+			return err;
+
+		dev_dbg(&pdev->dev, "No reset control found\n");
+		rk3308->reset = NULL;
+	}
+
+	rk3308->hclk = devm_clk_get(&pdev->dev, "hclk");
+	if (IS_ERR(rk3308->hclk))
+		return dev_err_probe(&pdev->dev, PTR_ERR(rk3308->hclk), "Can't get hclk\n");
+
+	rk3308->mclk_rx = devm_clk_get(&pdev->dev, "mclk_rx");
+	if (IS_ERR(rk3308->mclk_rx))
+		return dev_err_probe(&pdev->dev, PTR_ERR(rk3308->mclk_rx), "Can't get mclk_rx\n");
+
+	rk3308->mclk_tx = devm_clk_get(&pdev->dev, "mclk_tx");
+	if (IS_ERR(rk3308->mclk_tx))
+		return dev_err_probe(&pdev->dev, PTR_ERR(rk3308->mclk_tx), "Can't get mclk_tx\n");
+
+	err = clk_prepare_enable(rk3308->hclk);
+	if (err)
+		return dev_err_probe(&pdev->dev, err, "Failed to enable hclk\n");
+
+	err = clk_prepare_enable(rk3308->mclk_rx);
+	if (err)
+		return dev_err_probe(&pdev->dev, err, "Failed to enable mclk_rx\n");
+
+	err = clk_prepare_enable(rk3308->mclk_tx);
+	if (err)
+		return dev_err_probe(&pdev->dev, err, "Failed to enable mclk_tx\n");
+
+	err = rk3308_codec_get_version(rk3308);
+	if (err)
+		return err;
+
+	base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	rk3308->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+					       &rk3308_codec_regmap_config);
+	if (IS_ERR(rk3308->regmap))
+		return dev_err_probe(&pdev->dev, PTR_ERR(rk3308->regmap),
+				     "Failed to init regmap\n");
+
+	platform_set_drvdata(pdev, rk3308);
+
+	err = rk3308_codec_set_micbias_level(rk3308);
+	if (err)
+		return err;
+
+	err = devm_snd_soc_register_component(&pdev->dev, &soc_codec_dev_rk3308,
+					      rk3308_codec_dai, ARRAY_SIZE(rk3308_codec_dai));
+	if (err)
+		return dev_err_probe(&pdev->dev, err, "Failed to register codec\n");
+
+	return 0;
+}
+
+static const struct of_device_id rk3308_codec_of_match[] = {
+	{ .compatible = "rockchip,rk3308-codec", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, rk3308_codec_of_match);
+
+static struct platform_driver rk3308_codec_driver = {
+	.driver = {
+		.name = "rk3308-acodec",
+		.of_match_table = of_match_ptr(rk3308_codec_of_match),
+	},
+	.probe = rk3308_codec_platform_probe,
+};
+module_platform_driver(rk3308_codec_driver);
+
+MODULE_AUTHOR("Xing Zheng <zhengxing at rock-chips.com>");
+MODULE_AUTHOR("Luca Ceresoli <luca.ceresoli at bootlin.com>");
+MODULE_DESCRIPTION("ASoC RK3308 Codec Driver");
+MODULE_LICENSE("GPL");
diff --git a/sound/soc/codecs/rk3308_codec.h b/sound/soc/codecs/rk3308_codec.h
new file mode 100644
index 000000000000..50239a6919ab
--- /dev/null
+++ b/sound/soc/codecs/rk3308_codec.h
@@ -0,0 +1,593 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Rockchip RK3308 internal audio codec driver -- register definitions
+ *
+ * Copyright (c) 2018, Fuzhou Rockchip Electronics Co., Ltd All rights reserved.
+ * Copyright (c) 2022, Vivax-Metrotech Ltd
+ */
+
+#ifndef __RK3308_CODEC_H__
+#define __RK3308_CODEC_H__
+
+#define RK3308_GLB_CON				0x00
+
+/* ADC DIGITAL REGISTERS */
+
+/*
+ * The ADC group are 0 ~ 3, that control:
+ *
+ * CH0: left_0(ADC1) and right_0(ADC2)
+ * CH1: left_1(ADC3) and right_1(ADC4)
+ * CH2: left_2(ADC5) and right_2(ADC6)
+ * CH3: left_3(ADC7) and right_3(ADC8)
+ */
+#define RK3308_ADC_DIG_OFFSET(ch)		(((ch) & 0x3) * 0xc0 + 0x0)
+
+#define RK3308_ADC_DIG_CON01(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x04)
+#define RK3308_ADC_DIG_CON02(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x08)
+#define RK3308_ADC_DIG_CON03(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x0c)
+#define RK3308_ADC_DIG_CON04(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x10)
+#define RK3308_ADC_DIG_CON05(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x14) // ver.C only
+#define RK3308_ADC_DIG_CON06(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x18) // ver.C only
+#define RK3308_ADC_DIG_CON07(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x1c)
+
+#define RK3308_ALC_L_DIG_CON00(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x40)
+#define RK3308_ALC_L_DIG_CON01(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x44)
+#define RK3308_ALC_L_DIG_CON02(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x48)
+#define RK3308_ALC_L_DIG_CON03(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x4c)
+#define RK3308_ALC_L_DIG_CON04(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x50)
+#define RK3308_ALC_L_DIG_CON05(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x54)
+#define RK3308_ALC_L_DIG_CON06(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x58)
+#define RK3308_ALC_L_DIG_CON07(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x5c)
+#define RK3308_ALC_L_DIG_CON08(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x60)
+#define RK3308_ALC_L_DIG_CON09(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x64)
+#define RK3308_ALC_L_DIG_CON12(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x70)
+
+#define RK3308_ALC_R_DIG_CON00(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x80)
+#define RK3308_ALC_R_DIG_CON01(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x84)
+#define RK3308_ALC_R_DIG_CON02(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x88)
+#define RK3308_ALC_R_DIG_CON03(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x8c)
+#define RK3308_ALC_R_DIG_CON04(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x90)
+#define RK3308_ALC_R_DIG_CON05(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x94)
+#define RK3308_ALC_R_DIG_CON06(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x98)
+#define RK3308_ALC_R_DIG_CON07(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0x9c)
+#define RK3308_ALC_R_DIG_CON08(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0xa0)
+#define RK3308_ALC_R_DIG_CON09(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0xa4)
+#define RK3308_ALC_R_DIG_CON12(ch)		(RK3308_ADC_DIG_OFFSET((ch)) + 0xb0)
+
+/* DAC DIGITAL REGISTERS */
+#define RK3308_DAC_DIG_OFFSET			0x300
+#define RK3308_DAC_DIG_CON01			(RK3308_DAC_DIG_OFFSET + 0x04)
+#define RK3308_DAC_DIG_CON02			(RK3308_DAC_DIG_OFFSET + 0x08)
+#define RK3308_DAC_DIG_CON03			(RK3308_DAC_DIG_OFFSET + 0x0c)
+#define RK3308_DAC_DIG_CON04			(RK3308_DAC_DIG_OFFSET + 0x10)
+#define RK3308_DAC_DIG_CON05			(RK3308_DAC_DIG_OFFSET + 0x14)
+#define RK3308_DAC_DIG_CON10			(RK3308_DAC_DIG_OFFSET + 0x28)
+#define RK3308_DAC_DIG_CON11			(RK3308_DAC_DIG_OFFSET + 0x2c)
+#define RK3308_DAC_DIG_CON13			(RK3308_DAC_DIG_OFFSET + 0x34)
+#define RK3308_DAC_DIG_CON14			(RK3308_DAC_DIG_OFFSET + 0x38)
+
+/* ADC ANALOG REGISTERS */
+/*
+ * The ADC group are 0 ~ 3, that control:
+ *
+ * CH0: left_0(ADC1) and right_0(ADC2)
+ * CH1: left_1(ADC3) and right_1(ADC4)
+ * CH2: left_2(ADC5) and right_2(ADC6)
+ * CH3: left_3(ADC7) and right_3(ADC8)
+ */
+#define RK3308_ADC_ANA_OFFSET(ch)		(((ch) & 0x3) * 0x40 + 0x340)
+#define RK3308_ADC_ANA_CON00(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x00)
+#define RK3308_ADC_ANA_CON01(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x04)
+#define RK3308_ADC_ANA_CON02(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x08)
+#define RK3308_ADC_ANA_CON03(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x0c)
+#define RK3308_ADC_ANA_CON04(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x10)
+#define RK3308_ADC_ANA_CON05(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x14)
+#define RK3308_ADC_ANA_CON06(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x18)
+#define RK3308_ADC_ANA_CON07(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x1c)
+#define RK3308_ADC_ANA_CON08(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x20)
+#define RK3308_ADC_ANA_CON10(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x28)
+#define RK3308_ADC_ANA_CON11(ch)		(RK3308_ADC_ANA_OFFSET((ch)) + 0x2c)
+
+/* DAC ANALOG REGISTERS */
+#define RK3308_DAC_ANA_OFFSET			0x440
+#define RK3308_DAC_ANA_CON00			(RK3308_DAC_ANA_OFFSET + 0x00)
+#define RK3308_DAC_ANA_CON01			(RK3308_DAC_ANA_OFFSET + 0x04)
+#define RK3308_DAC_ANA_CON02			(RK3308_DAC_ANA_OFFSET + 0x08)
+#define RK3308_DAC_ANA_CON03			(RK3308_DAC_ANA_OFFSET + 0x0c)
+#define RK3308_DAC_ANA_CON04			(RK3308_DAC_ANA_OFFSET + 0x10)
+#define RK3308_DAC_ANA_CON05			(RK3308_DAC_ANA_OFFSET + 0x14)
+#define RK3308_DAC_ANA_CON06			(RK3308_DAC_ANA_OFFSET + 0x18)
+#define RK3308_DAC_ANA_CON07			(RK3308_DAC_ANA_OFFSET + 0x1c)
+#define RK3308_DAC_ANA_CON08			(RK3308_DAC_ANA_OFFSET + 0x20)
+#define RK3308_DAC_ANA_CON12			(RK3308_DAC_ANA_OFFSET + 0x30)
+#define RK3308_DAC_ANA_CON13			(RK3308_DAC_ANA_OFFSET + 0x34)
+#define RK3308_DAC_ANA_CON14			(RK3308_DAC_ANA_OFFSET + 0x38)
+#define RK3308_DAC_ANA_CON15			(RK3308_DAC_ANA_OFFSET + 0x3c)
+
+/*
+ * These are the bits for registers
+ */
+
+/* RK3308_GLB_CON - REG: 0x0000 */
+#define RK3308_ADC_BIST_WORK			BIT(7)
+#define RK3308_DAC_BIST_WORK			BIT(6)
+#define RK3308_ADC_MCLK_GATING_MSK		BIT(5)
+#define RK3308_DAC_MCLK_GATING_MSK		BIT(4)
+#define RK3308_CODEC_RST_MSK			(0x7 << 0)
+#define RK3308_ADC_DIG_WORK			BIT(2)
+#define RK3308_DAC_DIG_WORK			BIT(1)
+#define RK3308_SYS_WORK				BIT(0)
+
+/* RK3308_ADC_DIG_CON01 - REG: 0x0004 */
+#define RK3308_ADC_I2S_LRC_POL_REVERSAL		BIT(7)
+#define RK3308_ADC_I2S_VALID_LEN_SFT		5
+#define RK3308_ADC_I2S_VALID_LEN_MSK		(0x3 << RK3308_ADC_I2S_VALID_LEN_SFT)
+#define RK3308_ADC_I2S_VALID_LEN_32BITS		(0x3 << RK3308_ADC_I2S_VALID_LEN_SFT)
+#define RK3308_ADC_I2S_VALID_LEN_24BITS		(0x2 << RK3308_ADC_I2S_VALID_LEN_SFT)
+#define RK3308_ADC_I2S_VALID_LEN_20BITS		(0x1 << RK3308_ADC_I2S_VALID_LEN_SFT)
+#define RK3308_ADC_I2S_VALID_LEN_16BITS		(0x0 << RK3308_ADC_I2S_VALID_LEN_SFT)
+#define RK3308_ADC_I2S_MODE_SFT			3
+#define RK3308_ADC_I2S_MODE_MSK			(0x3 << RK3308_ADC_I2S_MODE_SFT)
+#define RK3308_ADC_I2S_MODE_PCM			(0x3 << RK3308_ADC_I2S_MODE_SFT)
+#define RK3308_ADC_I2S_MODE_I2S			(0x2 << RK3308_ADC_I2S_MODE_SFT)
+#define RK3308_ADC_I2S_MODE_LJ			(0x1 << RK3308_ADC_I2S_MODE_SFT)
+#define RK3308_ADC_I2S_MODE_RJ			(0x0 << RK3308_ADC_I2S_MODE_SFT)
+#define RK3308_ADC_I2S_LR_SWAP			BIT(1)
+#define RK3308_ADC_I2S_MONO			BIT(0)
+
+/* RK3308_ADC_DIG_CON02 - REG: 0x0008 */
+#define RK3308_ADC_IO_MODE_MASTER		BIT(5)
+#define RK3308_ADC_MODE_MASTER			BIT(4)
+#define RK3308_ADC_I2S_FRAME_LEN_SFT		2
+#define RK3308_ADC_I2S_FRAME_LEN_MSK		(0x3 << RK3308_ADC_I2S_FRAME_LEN_SFT)
+#define RK3308_ADC_I2S_FRAME_32BITS		(0x3 << RK3308_ADC_I2S_FRAME_LEN_SFT)
+#define RK3308_ADC_I2S_FRAME_24BITS		(0x2 << RK3308_ADC_I2S_FRAME_LEN_SFT)
+#define RK3308_ADC_I2S_FRAME_20BITS		(0x1 << RK3308_ADC_I2S_FRAME_LEN_SFT)
+#define RK3308_ADC_I2S_FRAME_16BITS		(0x0 << RK3308_ADC_I2S_FRAME_LEN_SFT)
+#define RK3308_ADC_I2S_WORK			BIT(1)
+#define RK3308_ADC_I2S_BIT_CLK_POL_REVERSAL	BIT(0)
+
+/* RK3308_ADC_DIG_CON03 - REG: 0x000c */
+#define RK3308_ADC_L_CH_BIST_SFT		2
+#define RK3308_ADC_L_CH_BIST_MSK		(0x3 << RK3308_ADC_L_CH_BIST_SFT)
+#define RK3308_ADC_L_CH_NORMAL_RIGHT		(0x3 << RK3308_ADC_L_CH_BIST_SFT) /* normal mode */
+#define RK3308_ADC_L_CH_BIST_CUBE		(0x2 << RK3308_ADC_L_CH_BIST_SFT)
+#define RK3308_ADC_L_CH_BIST_SINE		(0x1 << RK3308_ADC_L_CH_BIST_SFT)
+#define RK3308_ADC_L_CH_NORMAL_LEFT		(0x0 << RK3308_ADC_L_CH_BIST_SFT) /* normal mode */
+#define RK3308_ADC_R_CH_BIST_SFT		0
+#define RK3308_ADC_R_CH_BIST_MSK		(0x3 << RK3308_ADC_R_CH_BIST_SFT)
+#define RK3308_ADC_R_CH_NORMAL_LEFT		(0x3 << RK3308_ADC_R_CH_BIST_SFT) /* normal mode */
+#define RK3308_ADC_R_CH_BIST_CUBE		(0x2 << RK3308_ADC_R_CH_BIST_SFT)
+#define RK3308_ADC_R_CH_BIST_SINE		(0x1 << RK3308_ADC_R_CH_BIST_SFT)
+#define RK3308_ADC_R_CH_NORMAL_RIGHT		(0x0 << RK3308_ADC_R_CH_BIST_SFT) /* normal mode */
+
+/* RK3308_ADC_DIG_CON04 - REG: 0x0010 */
+#define RK3308_ADC_HPF_PATH_DIS			BIT(2)
+#define RK3308_ADC_HPF_CUTOFF_SFT		0
+#define RK3308_ADC_HPF_CUTOFF_MSK		(0x3 << RK3308_ADC_HPF_CUTOFF_SFT)
+#define RK3308_ADC_HPF_CUTOFF_612HZ		(0x2 << RK3308_ADC_HPF_CUTOFF_SFT)
+#define RK3308_ADC_HPF_CUTOFF_245HZ		(0x1 << RK3308_ADC_HPF_CUTOFF_SFT)
+#define RK3308_ADC_HPF_CUTOFF_20HZ		(0x0 << RK3308_ADC_HPF_CUTOFF_SFT)
+
+/* RK3308_ADC_DIG_CON07 - REG: 0x001c */
+#define RK3308_ADCL_DATA_SFT			4
+#define RK3308_ADCR_DATA_SFT			2
+#define RK3308_ADCL_DATA_SEL_ADCL		BIT(1)
+#define RK3308_ADCR_DATA_SEL_ADCR		BIT(0)
+
+/*
+ * RK3308_ALC_L_DIG_CON00 - REG: 0x0040 + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON00 - REG: 0x0080 + ch * 0xc0
+ */
+#define RK3308_GAIN_ATTACK_JACK			BIT(6)
+#define RK3308_CTRL_GEN_SFT			4
+#define RK3308_CTRL_GEN_MSK			(0x3 << RK3308_ALC_CTRL_GEN_SFT)
+#define RK3308_CTRL_GEN_JACK3			(0x3 << RK3308_ALC_CTRL_GEN_SFT)
+#define RK3308_CTRL_GEN_JACK2			(0x2 << RK3308_ALC_CTRL_GEN_SFT)
+#define RK3308_CTRL_GEN_JACK1			(0x1 << RK3308_ALC_CTRL_GEN_SFT)
+#define RK3308_CTRL_GEN_NORMAL			(0x0 << RK3308_ALC_CTRL_GEN_SFT)
+#define RK3308_AGC_HOLD_TIME_SFT		0
+#define RK3308_AGC_HOLD_TIME_MSK		(0xf << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_1S			(0xa << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_512MS		(0x9 << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_256MS		(0x8 << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_128MS		(0x7 << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_64MS		(0x6 << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_32MS		(0x5 << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_16MS		(0x4 << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_8MS		(0x3 << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_4MS		(0x2 << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_2MS		(0x1 << RK3308_AGC_HOLD_TIME_SFT)
+#define RK3308_AGC_HOLD_TIME_0MS		(0x0 << RK3308_AGC_HOLD_TIME_SFT)
+
+/*
+ * RK3308_ALC_L_DIG_CON01 - REG: 0x0044 + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON01 - REG: 0x0084 + ch * 0xc0
+ */
+#define RK3308_AGC_DECAY_TIME_SFT		4
+#define RK3308_AGC_ATTACK_TIME_SFT		0
+
+/*
+ * RK3308_ALC_L_DIG_CON02 - REG: 0x0048 + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON02 - REG: 0x0088 + ch * 0xc0
+ */
+#define RK3308_AGC_MODE_LIMITER			BIT(7)
+#define RK3308_AGC_ZERO_CRO_EN			BIT(6)
+#define RK3308_AGC_AMP_RECOVER_GAIN		BIT(5)
+#define RK3308_AGC_FAST_DEC_EN			BIT(4)
+#define RK3308_AGC_NOISE_GATE_EN		BIT(3)
+#define RK3308_AGC_NOISE_GATE_THRESH_SFT	0
+#define RK3308_AGC_NOISE_GATE_THRESH_MSK	(0x7 << RK3308_AGC_NOISE_GATE_THRESH_SFT)
+
+/*
+ * RK3308_ALC_L_DIG_CON03 - REG: 0x004c + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON03 - REG: 0x008c + ch * 0xc0
+ */
+#define RK3308_AGC_PGA_ZERO_CRO_EN		BIT(5)
+#define RK3308_AGC_PGA_GAIN_MAX			0x1f
+#define RK3308_AGC_PGA_GAIN_MIN			0
+#define RK3308_AGC_PGA_GAIN_SFT			0
+
+/*
+ * RK3308_ALC_L_DIG_CON04 - REG: 0x0050 + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON04 - REG: 0x0090 + ch * 0xc0
+ */
+#define RK3308_AGC_SLOW_CLK_EN			BIT(3)
+#define RK3308_AGC_APPROX_RATE_SFT		0
+#define RK3308_AGC_APPROX_RATE_MSK		(0x7 << RK3308_AGC_APPROX_RATE_SFT)
+
+/*
+ * RK3308_ALC_L_DIG_CON05 - REG: 0x0054 + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON05 - REG: 0x0094 + ch * 0xc0
+ */
+#define RK3308_AGC_LO_8BITS_AGC_MAX_MSK		0xff
+
+/*
+ * RK3308_ALC_L_DIG_CON06 - REG: 0x0058 + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON06 - REG: 0x0098 + ch * 0xc0
+ */
+#define RK3308_AGC_HI_8BITS_AGC_MAX_MSK		0xff
+
+/*
+ * RK3308_ALC_L_DIG_CON07 - REG: 0x005c + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON07 - REG: 0x009c + ch * 0xc0
+ */
+#define RK3308_AGC_LO_8BITS_AGC_MIN_MSK		0xff
+
+/*
+ * RK3308_ALC_L_DIG_CON08 - REG: 0x0060 + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON08 - REG: 0x00a0 + ch * 0xc0
+ */
+#define RK3308_AGC_HI_8BITS_AGC_MIN_MSK		0xff
+
+/*
+ * RK3308_ALC_L_DIG_CON09 - REG: 0x0064 + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON09 - REG: 0x00a4 + ch * 0xc0
+ */
+#define RK3308_AGC_FUNC_SEL_MSK			BIT(6)
+#define RK3308_AGC_MAX_GAIN_PGA_MAX		0x7
+#define RK3308_AGC_MAX_GAIN_PGA_MIN		0
+#define RK3308_AGC_MAX_GAIN_PGA_SFT		3
+#define RK3308_AGC_MAX_GAIN_PGA_MSK		(0x7 << RK3308_AGC_MAX_GAIN_PGA_SFT)
+#define RK3308_AGC_MIN_GAIN_PGA_MAX		0x7
+#define RK3308_AGC_MIN_GAIN_PGA_MIN		0
+#define RK3308_AGC_MIN_GAIN_PGA_SFT		0
+#define RK3308_AGC_MIN_GAIN_PGA_MSK		(0x7 << RK3308_AGC_MIN_GAIN_PGA_SFT)
+
+/*
+ * RK3308_ALC_L_DIG_CON12 - REG: 0x0068 + ch * 0xc0
+ * RK3308_ALC_R_DIG_CON12 - REG: 0x00a8 + ch * 0xc0
+ */
+#define RK3308_AGC_GAIN_MSK			0x1f
+
+/* RK3308_DAC_DIG_CON01 - REG: 0x0304 */
+#define RK3308_DAC_I2S_LRC_POL_REVERSAL		BIT(7)
+#define RK3308_DAC_I2S_VALID_LEN_SFT		5
+#define RK3308_DAC_I2S_VALID_LEN_MSK		(0x3 << RK3308_DAC_I2S_VALID_LEN_SFT)
+#define RK3308_DAC_I2S_VALID_LEN_32BITS		(0x3 << RK3308_DAC_I2S_VALID_LEN_SFT)
+#define RK3308_DAC_I2S_VALID_LEN_24BITS		(0x2 << RK3308_DAC_I2S_VALID_LEN_SFT)
+#define RK3308_DAC_I2S_VALID_LEN_20BITS		(0x1 << RK3308_DAC_I2S_VALID_LEN_SFT)
+#define RK3308_DAC_I2S_VALID_LEN_16BITS		(0x0 << RK3308_DAC_I2S_VALID_LEN_SFT)
+#define RK3308_DAC_I2S_MODE_SFT			3
+#define RK3308_DAC_I2S_MODE_MSK			(0x3 << RK3308_DAC_I2S_MODE_SFT)
+#define RK3308_DAC_I2S_MODE_PCM			(0x3 << RK3308_DAC_I2S_MODE_SFT)
+#define RK3308_DAC_I2S_MODE_I2S			(0x2 << RK3308_DAC_I2S_MODE_SFT)
+#define RK3308_DAC_I2S_MODE_LJ			(0x1 << RK3308_DAC_I2S_MODE_SFT)
+#define RK3308_DAC_I2S_MODE_RJ			(0x0 << RK3308_DAC_I2S_MODE_SFT)
+#define RK3308_DAC_I2S_LR_SWAP			BIT(2)
+
+/* RK3308_DAC_DIG_CON02 - REG: 0x0308 */
+#define RK3308BS_DAC_IO_MODE_MASTER		BIT(7)
+#define RK3308BS_DAC_MODE_MASTER		BIT(6)
+#define RK3308_DAC_IO_MODE_MASTER		BIT(5)
+#define RK3308_DAC_MODE_MASTER			BIT(4)
+#define RK3308_DAC_I2S_FRAME_LEN_SFT		2
+#define RK3308_DAC_I2S_FRAME_LEN_MSK		(0x3 << RK3308_DAC_I2S_FRAME_LEN_SFT)
+#define RK3308_DAC_I2S_FRAME_32BITS		(0x3 << RK3308_DAC_I2S_FRAME_LEN_SFT)
+#define RK3308_DAC_I2S_FRAME_24BITS		(0x2 << RK3308_DAC_I2S_FRAME_LEN_SFT)
+#define RK3308_DAC_I2S_FRAME_20BITS		(0x1 << RK3308_DAC_I2S_FRAME_LEN_SFT)
+#define RK3308_DAC_I2S_FRAME_16BITS		(0x0 << RK3308_DAC_I2S_FRAME_LEN_SFT)
+#define RK3308_DAC_I2S_WORK			BIT(1)
+#define RK3308_DAC_I2S_BIT_CLK_POL_REVERSAL	BIT(0)
+
+/* RK3308_DAC_DIG_CON03 - REG: 0x030C */
+#define RK3308_DAC_L_CH_BIST_SFT		2
+#define RK3308_DAC_L_CH_BIST_MSK		(0x3 << RK3308_DAC_L_CH_BIST_SFT)
+#define RK3308_DAC_L_CH_BIST_LEFT		(0x3 << RK3308_DAC_L_CH_BIST_SFT) /* normal mode */
+#define RK3308_DAC_L_CH_BIST_CUBE		(0x2 << RK3308_DAC_L_CH_BIST_SFT)
+#define RK3308_DAC_L_CH_BIST_SINE		(0x1 << RK3308_DAC_L_CH_BIST_SFT)
+#define RK3308_DAC_L_CH_BIST_RIGHT		(0x0 << RK3308_DAC_L_CH_BIST_SFT) /* normal mode */
+#define RK3308_DAC_R_CH_BIST_SFT		0
+#define RK3308_DAC_R_CH_BIST_MSK		(0x3 << RK3308_DAC_R_CH_BIST_SFT)
+#define RK3308_DAC_R_CH_BIST_LEFT		(0x3 << RK3308_DAC_R_CH_BIST_SFT) /* normal mode */
+#define RK3308_DAC_R_CH_BIST_CUBE		(0x2 << RK3308_DAC_R_CH_BIST_SFT)
+#define RK3308_DAC_R_CH_BIST_SINE		(0x1 << RK3308_DAC_R_CH_BIST_SFT)
+#define RK3308_DAC_R_CH_BIST_RIGHT		(0x0 << RK3308_DAC_R_CH_BIST_SFT) /* normal mode */
+
+/* RK3308_DAC_DIG_CON04 - REG: 0x0310 */
+/* Versions up to B: */
+#define RK3308_DAC_MODULATOR_GAIN_SFT		4
+#define RK3308_DAC_MODULATOR_GAIN_MSK		(0x7 << RK3308_DAC_MODULATOR_GAIN_SFT)
+#define RK3308_DAC_CIC_IF_GAIN_SFT		0
+#define RK3308_DAC_CIC_IF_GAIN_MSK		(0x7 << RK3308_DAC_CIC_IF_GAIN_SFT)
+/* Version C: */
+#define RK3308BS_DAC_DIG_GAIN_SFT		0
+#define RK3308BS_DAC_DIG_GAIN_MSK		(0xff << RK3308BS_DAC_DIG_GAIN_SFT)
+#define RK3308BS_DAC_DIG_GAIN_0DB		(0xed << RK3308BS_DAC_DIG_GAIN_SFT)
+
+/* RK3308BS_ADC_DIG_CON05..06 (Version C only) */
+#define RK3308_ADC_DIG_VOL_CON_x_SFT		0
+#define RK3308_ADC_DIG_VOL_CON_x_MSK		(0xff << RK3308_ADC_DIG_VOL_CON_x_SFT)
+#define RK3308_ADC_DIG_VOL_CON_x_0DB		(0xc2 << RK3308_ADC_DIG_VOL_CON_x_SFT)
+
+/* RK3308_DAC_DIG_CON05 - REG: 0x0314 */
+#define RK3308_DAC_L_REG_CTL_INDATA		BIT(2)
+#define RK3308_DAC_R_REG_CTL_INDATA		BIT(1)
+
+/* RK3308_DAC_DIG_CON10 - REG: 0x0328 */
+#define RK3308_DAC_DATA_HI4(x)			((x) & 0xf)
+
+/* RK3308_DAC_DIG_CON11 - REG: 0x032c */
+#define RK3308_DAC_DATA_LO8(x)			((x) & 0xff)
+
+/* RK3308_ADC_ANA_CON00 - REG: 0x0340 */
+#define RK3308_ADC_CH1_CH2_MIC_ALL_MSK		(0xff << 0)
+#define RK3308_ADC_CH1_CH2_MIC_ALL		0xff
+#define RK3308_ADC_CH2_MIC_UNMUTE		BIT(7)
+#define RK3308_ADC_CH2_MIC_WORK			BIT(6)
+#define RK3308_ADC_CH2_MIC_EN			BIT(5)
+#define RK3308_ADC_CH2_BUF_REF_EN		BIT(4)
+#define RK3308_ADC_CH1_MIC_UNMUTE		BIT(3)
+#define RK3308_ADC_CH1_MIC_WORK			BIT(2)
+#define RK3308_ADC_CH1_MIC_EN			BIT(1)
+#define RK3308_ADC_CH1_BUF_REF_EN		BIT(0)
+
+/* RK3308_ADC_ANA_CON01 - REG: 0x0344
+ *
+ * The PGA of MIC-INs:
+ * - HW version A:
+ *   0x0 - MIC1~MIC8  0 dB (recommended when ADC used as loopback)
+ *   0x3 - MIC1~MIC8 20 dB (recommended when ADC used as MIC input)
+ * - HW version B:
+ *   0x0 - MIC1~MIC8   0 dB
+ *   0x1 - MIC1~MIC8 6.6 dB
+ *   0x2 - MIC1~MIC8  13 dB
+ *   0x3 - MIC1~MIC8  20 dB
+ */
+#define RK3308_ADC_CH2_MIC_GAIN_MAX		0x3
+#define RK3308_ADC_CH2_MIC_GAIN_MIN		0
+#define RK3308_ADC_CH2_MIC_GAIN_SFT		4
+#define RK3308_ADC_CH2_MIC_GAIN_MSK		(0x3 << RK3308_ADC_CH2_MIC_GAIN_SFT)
+#define RK3308_ADC_CH2_MIC_GAIN_20DB		(0x3 << RK3308_ADC_CH2_MIC_GAIN_SFT)
+#define RK3308_ADC_CH2_MIC_GAIN_13DB		(0x2 << RK3308_ADC_CH2_MIC_GAIN_SFT)
+#define RK3308_ADC_CH2_MIC_GAIN_6_6DB		(0x1 << RK3308_ADC_CH2_MIC_GAIN_SFT)
+#define RK3308_ADC_CH2_MIC_GAIN_0DB		(0x0 << RK3308_ADC_CH2_MIC_GAIN_SFT)
+
+#define RK3308_ADC_CH1_MIC_GAIN_MAX		0x3
+#define RK3308_ADC_CH1_MIC_GAIN_MIN		0
+#define RK3308_ADC_CH1_MIC_GAIN_SFT		0
+#define RK3308_ADC_CH1_MIC_GAIN_MSK		(0x3 << RK3308_ADC_CH1_MIC_GAIN_SFT)
+#define RK3308_ADC_CH1_MIC_GAIN_20DB		(0x3 << RK3308_ADC_CH1_MIC_GAIN_SFT)
+#define RK3308_ADC_CH1_MIC_GAIN_13DB		(0x2 << RK3308_ADC_CH1_MIC_GAIN_SFT)
+#define RK3308_ADC_CH1_MIC_GAIN_6_6DB		(0x1 << RK3308_ADC_CH1_MIC_GAIN_SFT)
+#define RK3308_ADC_CH1_MIC_GAIN_0DB		(0x0 << RK3308_ADC_CH1_MIC_GAIN_SFT)
+
+/* RK3308_ADC_ANA_CON02 - REG: 0x0348 */
+#define RK3308_ADC_CH2_ZEROCROSS_DET_EN		BIT(6)
+#define RK3308_ADC_CH2_ALC_WORK			BIT(5)
+#define RK3308_ADC_CH2_ALC_EN			BIT(4)
+#define RK3308_ADC_CH1_ZEROCROSS_DET_EN		BIT(2)
+#define RK3308_ADC_CH1_ALC_WORK			BIT(1)
+#define RK3308_ADC_CH1_ALC_EN			BIT(0)
+
+/* RK3308_ADC_ANA_CON03 - REG: 0x034c */
+#define RK3308_ADC_CH1_ALC_GAIN_MAX		0x1f
+#define RK3308_ADC_CH1_ALC_GAIN_MIN		0
+#define RK3308_ADC_CH1_ALC_GAIN_SFT		0
+#define RK3308_ADC_CH1_ALC_GAIN_MSK		(0x1f << RK3308_ADC_CH1_ALC_GAIN_SFT)
+#define RK3308_ADC_CH1_ALC_GAIN_0DB		(0x0c << RK3308_ADC_CH1_ALC_GAIN_SFT)
+
+/* RK3308_ADC_ANA_CON04 - REG: 0x0350 */
+#define RK3308_ADC_CH2_ALC_GAIN_MAX		0x1f
+#define RK3308_ADC_CH2_ALC_GAIN_MIN		0
+#define RK3308_ADC_CH2_ALC_GAIN_SFT		0
+#define RK3308_ADC_CH2_ALC_GAIN_MSK		(0x1f << RK3308_ADC_CH2_ALC_GAIN_SFT)
+#define RK3308_ADC_CH2_ALC_GAIN_0DB		(0x0c << RK3308_ADC_CH2_ALC_GAIN_SFT)
+
+/* RK3308_ADC_ANA_CON05 - REG: 0x0354 */
+#define RK3308_ADC_CH2_ADC_WORK			BIT(6)
+#define RK3308_ADC_CH2_ADC_EN			BIT(5)
+#define RK3308_ADC_CH2_CLK_EN			BIT(4)
+#define RK3308_ADC_CH1_ADC_WORK			BIT(2)
+#define RK3308_ADC_CH1_ADC_EN			BIT(1)
+#define RK3308_ADC_CH1_CLK_EN			BIT(0)
+
+/* RK3308_ADC_ANA_CON06 - REG: 0x0358 */
+#define RK3308_ADC_CURRENT_EN			BIT(0)
+
+/* RK3308_ADC_ANA_CON07 - REG: 0x035c */
+/* Note: The register configuration is only valid for ADC2 */
+#define RK3308_ADC_CH2_IN_SEL_SFT		6
+#define RK3308_ADC_CH2_IN_SEL_MSK		(0x3 << RK3308_ADC_CH2_IN_SEL_SFT)
+#define RK3308_ADC_CH2_IN_LINEIN_MIC		(0x3 << RK3308_ADC_CH2_IN_SEL_SFT)
+#define RK3308_ADC_CH2_IN_LINEIN		(0x2 << RK3308_ADC_CH2_IN_SEL_SFT)
+#define RK3308_ADC_CH2_IN_MIC			(0x1 << RK3308_ADC_CH2_IN_SEL_SFT)
+#define RK3308_ADC_CH2_IN_NONE			(0x0 << RK3308_ADC_CH2_IN_SEL_SFT)
+/* Note: The register configuration is only valid for ADC1 */
+#define RK3308_ADC_CH1_IN_SEL_SFT		4
+#define RK3308_ADC_CH1_IN_SEL_MSK		(0x3 << RK3308_ADC_CH1_IN_SEL_SFT)
+#define RK3308_ADC_CH1_IN_LINEIN_MIC		(0x3 << RK3308_ADC_CH1_IN_SEL_SFT)
+#define RK3308_ADC_CH1_IN_LINEIN		(0x2 << RK3308_ADC_CH1_IN_SEL_SFT)
+#define RK3308_ADC_CH1_IN_MIC			(0x1 << RK3308_ADC_CH1_IN_SEL_SFT)
+#define RK3308_ADC_CH1_IN_NONE			(0x0 << RK3308_ADC_CH1_IN_SEL_SFT)
+#define RK3308_ADC_MIC_BIAS_BUF_EN		BIT(3)
+#define RK3308_ADC_LEVEL_RANGE_MICBIAS_MAX	7
+#define RK3308_ADC_LEVEL_RANGE_MICBIAS_SFT	0
+#define RK3308_ADC_LEVEL_RANGE_MICBIAS_MSK	(0x7 << RK3308_ADC_LEVEL_RANGE_MICBIAS_SFT)
+
+/* RK3308_ADC_ANA_CON08 - REG: 0x0360 */
+#define RK3308_ADC_MICBIAS_CURRENT_EN		BIT(4)
+
+/* RK3308_ADC_ANA_CON10 - REG: 0x0368 */
+#define RK3308_ADC_REF_EN			BIT(7)
+#define RK3308_ADC_CURRENT_CHARGE_SFT		0
+#define RK3308_ADC_CURRENT_CHARGE_MSK		(0x7f << RK3308_ADC_CURRENT_CHARGE_SFT)
+/*
+ * 1: Choose the current I
+ * 0: Don't choose the current I
+ */
+#define RK3308_ADC_SEL_I(x)			((x) & 0x7f)
+
+/* RK3308_ADC_ANA_CON11 - REG: 0x036c */
+#define RK3308_ADC_ALCR_CON_GAIN_PGAR_EN	BIT(1)
+#define RK3308_ADC_ALCL_CON_GAIN_PGAL_EN	BIT(0)
+
+/* RK3308_DAC_ANA_CON00 - REG: 0x0440 */
+#define RK3308_DAC_HEADPHONE_DET_EN		BIT(1)
+#define RK3308_DAC_CURRENT_EN			BIT(0)
+
+/* RK3308_DAC_ANA_CON01 - REG: 0x0444 */
+#define RK3308_DAC_BUF_REF_R_EN			BIT(6)
+#define RK3308_DAC_BUF_REF_L_EN			BIT(2)
+#define RK3308_DAC_HPOUT_POP_SOUND_R_SFT	4
+#define RK3308_DAC_HPOUT_POP_SOUND_L_SFT	0
+// unshifted values for both L and R:
+#define RK3308_DAC_HPOUT_POP_SOUND_x_MSK	0x3
+#define RK3308_DAC_HPOUT_POP_SOUND_x_WORK	0x2
+#define RK3308_DAC_HPOUT_POP_SOUND_x_INIT	0x1
+
+/* RK3308_DAC_ANA_CON02 - REG: 0x0448 */
+#define RK3308_DAC_R_DAC_WORK			BIT(7)
+#define RK3308_DAC_R_DAC_EN			BIT(6)
+#define RK3308_DAC_R_CLK_EN			BIT(5)
+#define RK3308_DAC_R_REF_EN			BIT(4)
+#define RK3308_DAC_L_DAC_WORK			BIT(3)
+#define RK3308_DAC_L_DAC_EN			BIT(2)
+#define RK3308_DAC_L_CLK_EN			BIT(1)
+#define RK3308_DAC_L_REF_EN			BIT(0)
+
+/* RK3308_DAC_ANA_CON03 - REG: 0x044c */
+#define RK3308_DAC_R_HPOUT_WORK			BIT(6)
+#define RK3308_DAC_R_HPOUT_EN			BIT(5)
+#define RK3308_DAC_R_HPOUT_MUTE_SFT		4
+#define RK3308_DAC_L_HPOUT_WORK			BIT(2)
+#define RK3308_DAC_L_HPOUT_EN			BIT(1)
+#define RK3308_DAC_L_HPOUT_MUTE_SFT		0
+
+/* RK3308_DAC_ANA_CON04 - REG: 0x0450 */
+#define RK3308_DAC_x_LINEOUT_GAIN_MAX		0x3
+#define RK3308_DAC_R_LINEOUT_GAIN_SFT		6
+#define RK3308_DAC_R_LINEOUT_GAIN_MSK		(0x3 << RK3308_DAC_R_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_R_LINEOUT_GAIN_0DB		(0x3 << RK3308_DAC_R_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_R_LINEOUT_GAIN_NDB_1_5	(0x2 << RK3308_DAC_R_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_R_LINEOUT_GAIN_NDB_3		(0x1 << RK3308_DAC_R_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_R_LINEOUT_GAIN_NDB_6		(0x0 << RK3308_DAC_R_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_R_LINEOUT_MUTE_SFT		5
+#define RK3308_DAC_R_LINEOUT_EN			BIT(4)
+#define RK3308_DAC_L_LINEOUT_GAIN_SFT		2
+#define RK3308_DAC_L_LINEOUT_GAIN_MSK		(0x3 << RK3308_DAC_L_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_L_LINEOUT_GAIN_0DB		(0x3 << RK3308_DAC_L_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_L_LINEOUT_GAIN_NDB_1_5	(0x2 << RK3308_DAC_L_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_L_LINEOUT_GAIN_NDB_3		(0x1 << RK3308_DAC_L_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_L_LINEOUT_GAIN_NDB_6		(0x0 << RK3308_DAC_L_LINEOUT_GAIN_SFT)
+#define RK3308_DAC_L_LINEOUT_MUTE_SFT		1
+#define RK3308_DAC_L_LINEOUT_EN			BIT(0)
+
+/* RK3308_DAC_ANA_CON05 - REG: 0x0454, step is 1.5db */
+/* RK3308_DAC_ANA_CON06 - REG: 0x0458, step is 1.5db */
+#define RK3308_DAC_x_HPOUT_GAIN_MAX		0x1e
+#define RK3308_DAC_x_HPOUT_GAIN_SFT		0
+#define RK3308_DAC_x_HPOUT_GAIN_MSK		(0x1f << RK3308_DAC_x_HPOUT_GAIN_SFT)
+#define RK3308_DAC_x_HPOUT_GAIN_MIN		(0x00 << RK3308_DAC_x_HPOUT_GAIN_SFT)
+
+/* RK3308_DAC_ANA_CON07 - REG: 0x045c */
+#define RK3308_DAC_R_HPOUT_DRV_SFT		4
+#define RK3308_DAC_R_HPOUT_DRV_MSK		(0xf << RK3308_DAC_R_HPOUT_DRV_SFT)
+#define RK3308_DAC_L_HPOUT_DRV_SFT		0
+#define RK3308_DAC_L_HPOUT_DRV_MSK		(0xf << RK3308_DAC_L_HPOUT_DRV_SFT)
+
+/* RK3308_DAC_ANA_CON08 - REG: 0x0460 */
+#define RK3308_DAC_R_LINEOUT_DRV_SFT		4
+#define RK3308_DAC_R_LINEOUT_DRV_MSK		(0xf << RK3308_DAC_R_LINEOUT_DRV_SFT)
+#define RK3308_DAC_L_LINEOUT_DRV_SFT		0
+#define RK3308_DAC_L_LINEOUT_DRV_MSK		(0xf << RK3308_DAC_L_LINEOUT_DRV_SFT)
+
+/* RK3308_DAC_ANA_CON12 - REG: 0x0470 */
+#define RK3308_DAC_R_HPMIX_SEL_SFT		6
+#define RK3308_DAC_R_HPMIX_SEL_MSK		(0x3 << RK3308_DAC_R_HPMIX_SEL_SFT)
+#define RK3308_DAC_R_HPMIX_LINEIN_I2S		(0x3 << RK3308_DAC_R_HPMIX_SEL_SFT)
+#define RK3308_DAC_R_HPMIX_LINEIN		(0x2 << RK3308_DAC_R_HPMIX_SEL_SFT)
+#define RK3308_DAC_R_HPMIX_I2S			(0x1 << RK3308_DAC_R_HPMIX_SEL_SFT)
+#define RK3308_DAC_R_HPMIX_NONE			(0x0 << RK3308_DAC_R_HPMIX_SEL_SFT)
+#define RK3308_DAC_L_HPMIX_SEL_SFT		2
+#define RK3308_DAC_L_HPMIX_SEL_MSK		(0x3 << RK3308_DAC_L_HPMIX_SEL_SFT)
+#define RK3308_DAC_L_HPMIX_LINEIN_I2S		(0x3 << RK3308_DAC_L_HPMIX_SEL_SFT)
+#define RK3308_DAC_L_HPMIX_LINEIN		(0x2 << RK3308_DAC_L_HPMIX_SEL_SFT)
+#define RK3308_DAC_L_HPMIX_I2S			(0x1 << RK3308_DAC_L_HPMIX_SEL_SFT)
+#define RK3308_DAC_L_HPMIX_NONE			(0x0 << RK3308_DAC_L_HPMIX_SEL_SFT)
+#define RK3308_DAC_x_HPMIX_GAIN_MIN		0x1 /* 0x0 and 0x3 are reserved */
+#define RK3308_DAC_x_HPMIX_GAIN_MAX		0x2
+#define RK3308_DAC_R_HPMIX_GAIN_SFT		4
+#define RK3308_DAC_R_HPMIX_GAIN_MSK		(0x3 << RK3308_DAC_R_HPMIX_GAIN_SFT)
+#define RK3308_DAC_R_HPMIX_GAIN_0DB		(0x2 << RK3308_DAC_R_HPMIX_GAIN_SFT)
+#define RK3308_DAC_R_HPMIX_GAIN_NDB_6		(0x1 << RK3308_DAC_R_HPMIX_GAIN_SFT)
+#define RK3308_DAC_L_HPMIX_GAIN_SFT		0
+#define RK3308_DAC_L_HPMIX_GAIN_MSK		(0x3 << RK3308_DAC_L_HPMIX_GAIN_SFT)
+#define RK3308_DAC_L_HPMIX_GAIN_0DB		(0x2 << RK3308_DAC_L_HPMIX_GAIN_SFT)
+#define RK3308_DAC_L_HPMIX_GAIN_NDB_6		(0x1 << RK3308_DAC_L_HPMIX_GAIN_SFT)
+
+/* RK3308_DAC_ANA_CON13 - REG: 0x0474 */
+#define RK3308_DAC_R_HPMIX_UNMUTE_SFT		6
+#define RK3308_DAC_R_HPMIX_WORK_SFT		5
+#define RK3308_DAC_R_HPMIX_EN_SFT		4
+#define RK3308_DAC_L_HPMIX_UNMUTE_SFT		2
+#define RK3308_DAC_L_HPMIX_WORK_SFT		1
+#define RK3308_DAC_L_HPMIX_EN_SFT		0
+
+/* RK3308_DAC_ANA_CON14 - REG: 0x0478 */
+#define RK3308_DAC_VCM_LINEOUT_EN		(0x1 << 4)
+#define RK3308_DAC_CURRENT_CHARGE_SFT		0
+#define RK3308_DAC_CURRENT_CHARGE_MSK		(0xf << RK3308_DAC_CURRENT_CHARGE_SFT)
+
+/*
+ * 1: Choose the current I
+ * 0: Don't choose the current I
+ */
+#define RK3308_DAC_SEL_I(x)			((x) & 0xf)
+
+/* RK3308_DAC_ANA_CON15 - REG: 0x047C */
+#define RK3308_DAC_LINEOUT_POP_SOUND_R_SFT	4
+#define RK3308_DAC_LINEOUT_POP_SOUND_R_MSK	(0x3 << RK3308_DAC_LINEOUT_POP_SOUND_R_SFT)
+#define RK3308_DAC_R_SEL_DC_FROM_INTERNAL	(0x2 << RK3308_DAC_LINEOUT_POP_SOUND_R_SFT)
+#define RK3308_DAC_R_SEL_DC_FROM_VCM		(0x1 << RK3308_DAC_LINEOUT_POP_SOUND_R_SFT)
+#define RK3308_DAC_R_SEL_LINEOUT_FROM_INTERNAL	(0x0 << RK3308_DAC_LINEOUT_POP_SOUND_R_SFT)
+#define RK3308_DAC_LINEOUT_POP_SOUND_L_SFT	0
+#define RK3308_DAC_LINEOUT_POP_SOUND_L_MSK	(0x3 << RK3308_DAC_LINEOUT_POP_SOUND_L_SFT)
+#define RK3308_DAC_L_SEL_DC_FROM_INTERNAL	(0x2 << RK3308_DAC_LINEOUT_POP_SOUND_L_SFT)
+#define RK3308_DAC_L_SEL_DC_FROM_VCM		(0x1 << RK3308_DAC_LINEOUT_POP_SOUND_L_SFT)
+#define RK3308_DAC_L_SEL_LINEOUT_FROM_INTERNAL	(0x0 << RK3308_DAC_LINEOUT_POP_SOUND_L_SFT)
+
+#define RK3308_HIFI				0x0
+
+#endif /* __RK3308_CODEC_H__ */

-- 
2.34.1



From luca.ceresoli at bootlin.com  Tue Dec 19 06:54:20 2023
From: luca.ceresoli at bootlin.com (Luca Ceresoli)
Date: Tue, 19 Dec 2023 15:54:20 +0100
Subject: [PATCH v2 5/6] arm64: dts: rockchip: add i2s_8ch_2 and i2s_8ch_3
In-Reply-To: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
References: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
Message-ID: <20231219-rk3308-audio-codec-v2-5-c70d06021946@bootlin.com>

These are I2S engines internally connected to the built-in audio codec.

Signed-off-by: Luca Ceresoli <luca.ceresoli at bootlin.com>

---

Changed in v2:
 nothing
---
 arch/arm64/boot/dts/rockchip/rk3308.dtsi | 54 ++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
index 2ae4bb7d5e62..fa34cae915a7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
@@ -573,6 +573,60 @@ dmac1: dma-controller at ff2d0000 {
 		#dma-cells = <1>;
 	};
 
+	/*
+	 * - can be clock producer or consumer
+	 * - up to 8 capture channels and 2 playback channels
+	 * - connected internally to audio codec
+	 */
+	i2s_8ch_2: i2s at ff320000 {
+		compatible = "rockchip,rk3308-i2s-tdm";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+		clock-names = "mclk_tx", "mclk_rx", "hclk",
+			      "mclk_tx_src", "mclk_rx_src",
+			      "mclk_root0", "mclk_root1";
+		clocks = <&cru SCLK_I2S2_8CH_TX>,
+			 <&cru SCLK_I2S2_8CH_RX>,
+			 <&cru HCLK_I2S2_8CH>,
+			 <&cru SCLK_I2S2_8CH_TX_SRC>,
+			 <&cru SCLK_I2S2_8CH_RX_SRC>,
+			 <&cru PLL_VPLL0>,
+			 <&cru PLL_VPLL1>;
+		dmas = <&dmac1 5>, <&dmac1 4>;
+		dma-names = "rx", "tx";
+		resets = <&cru SRST_I2S2_8CH_TX_M>, <&cru SRST_I2S2_8CH_RX_M>;
+		reset-names = "tx-m", "rx-m";
+		rockchip,grf = <&grf>;
+		status = "disabled";
+	};
+
+	/*
+	 * - can be clock consumer only
+	 * - up to 4 capture channels, no playback
+	 * - connected internally to audio codec
+	 */
+	i2s_8ch_3: i2s at ff330000 {
+		compatible = "rockchip,rk3308-i2s-tdm";
+		reg = <0x0 0xff330000 0x0 0x1000>;
+		interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+		clock-names = "mclk_tx", "mclk_rx", "hclk",
+			      "mclk_tx_src", "mclk_rx_src",
+			      "mclk_root0", "mclk_root1";
+		clocks = <&cru SCLK_I2S3_8CH_TX>,
+			 <&cru SCLK_I2S3_8CH_RX>,
+			 <&cru HCLK_I2S3_8CH>,
+			 <&cru SCLK_I2S3_8CH_TX_SRC>,
+			 <&cru SCLK_I2S3_8CH_RX_SRC>,
+			 <&cru PLL_VPLL0>,
+			 <&cru PLL_VPLL1>;
+		dmas = <&dmac1 7>;
+		dma-names = "rx";
+		resets = <&cru SRST_I2S3_8CH_TX_M>, <&cru SRST_I2S3_8CH_RX_M>;
+		reset-names = "tx-m", "rx-m";
+		rockchip,grf = <&grf>;
+		status = "disabled";
+	};
+
 	i2s_2ch_0: i2s at ff350000 {
 		compatible = "rockchip,rk3308-i2s", "rockchip,rk3066-i2s";
 		reg = <0x0 0xff350000 0x0 0x1000>;

-- 
2.34.1



From michal.simek at amd.com  Tue Dec 19 06:54:43 2023
From: michal.simek at amd.com (Michal Simek)
Date: Tue, 19 Dec 2023 15:54:43 +0100
Subject: [PATCH] dt-bindings: firmware: xilinx: Describe missing child nodes
Message-ID: <5bb16305a05692de29ee2aa2accc793e23b68dec.1702997680.git.michal.simek@amd.com>

Firmware node has more than fpga, aes and clock child nodes but also power,
reset, gpio, pinctrl and pcap which are not described yet.
All of them have binding in separate files but there is missing connection
to firmware node that's why describe it.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

 .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index 3d578f98ae2c..0662544f86f0 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -53,6 +53,37 @@ properties:
       vector.
     type: object
 
+  zynqmp-power:
+    $ref: /schemas/power/reset/xlnx,zynqmp-power.yaml#
+    description: The zynqmp-power node describes the power management
+      configurations. It will control remote suspend/shutdown interfaces.
+    type: object
+
+  reset-controller:
+    $ref: /schemas/reset/xlnx,zynqmp-reset.yaml#
+    description: The reset-controller node describes connection to the reset
+      functionality via firmware interface.
+    type: object
+
+  gpio:
+    $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
+    description: The gpio node describes connect to PS_MODE pins via firmware
+      interface.
+    type: object
+
+  pinctrl:
+    $ref: /schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+    description: The pinctrl node provides access to pinconfig and pincontrol
+      functionality available in firmware.
+    type: object
+
+  pcap:
+    $ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml
+    description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to
+      configure the Programmable Logic (PL). The configuration uses the
+      firmware interface.
+    type: object
+
   clock-controller:
     $ref: /schemas/clock/xlnx,versal-clk.yaml#
     description: The clock controller is a hardware block of Xilinx versal
-- 
2.36.1



From frieder.schrempf at kontron.de  Tue Dec 19 07:14:15 2023
From: frieder.schrempf at kontron.de (Frieder Schrempf)
Date: Tue, 19 Dec 2023 16:14:15 +0100
Subject: [PATCH v3 00/14] arm64: dts: imx8mm-kontron: DT updates
In-Reply-To: <20231213093134.GN270430@dragon>
References: <20231206144201.46911-1-frieder@fris.de>
 <20231213093134.GN270430@dragon>
Message-ID: <5bdfefe3-238a-48d3-b8a4-cee4fb6b0951@kontron.de>

On 13.12.23 10:31, Shawn Guo wrote:
> On Wed, Dec 06, 2023 at 03:41:03PM +0100, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf at kontron.de>
> ...
>>  arch/arm64/boot/dts/freescale/Makefile        |   4 +
>>  .../dts/freescale/imx8mm-kontron-bl-osm-s.dts | 295 +++------
>>  .../boot/dts/freescale/imx8mm-kontron-bl.dts  | 198 +++++-
>>  .../boot/dts/freescale/imx8mm-kontron-dl.dtso | 201 +++++++
>>  .../dts/freescale/imx8mm-kontron-osm-s.dtsi   | 567 +++++++++++++++++-
>>  .../boot/dts/freescale/imx8mm-kontron-sl.dtsi |   4 +-
>>  6 files changed, 1035 insertions(+), 234 deletions(-)
>>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso
> 
> A couple of things:
> 
> - I have to use 'git am -3' apply some of the patches.  Could you rebase
>   the series on imx/dt64 branch?

Ok, sure!

> 
> - There are a few DTC warnings that need to be addressed.
> 
> ../arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts:235.34-238.7: Warning (graph_endpoint): /soc at 0/bus at 30800000/i2c at 30a40000/bridge at 2c/ports/port at 0/endpoint: graph connection to node '/soc at 0/bus at 32c00000/dsi at 32e10000/ports/port at 1/endpoint' is not bidirectional

I'm not aware of a proper solution for this warning. The thing is that
there is a DSI switch on the board that is able to route the DSI output
of the SoC to one of two bridges (HDMI or LVDS).

On the driver side there is no representation of the switch. Therefore
the result is a three-way connection for the graph ports which is
reported by the binding check, but works fine as we only enable one of
the target port nodes at a time and use GPIO hogs to select the switch path.

Rob, Krzystztof: Would it be acceptable to ignore this until there is a
way to represent this in the DT? Are there alternative solutions? Is
there anything to model a graph link switch?

> arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtbo: Warning (graph_port): /fragment at 3: graph port node name should be 'port'
> ../arch/arm64/boot/dts/freescale/imx8mm-kontron-dl.dtso:61.17-63.3: Warning (graph_endpoint): /fragment at 3/__overlay__: graph endpoint node name should be 'endpoint'

For these warnings it seems like I could work around them by creating
two separate port nodes in the board DT and then only enable the proper
one in the overlay.


From gregkh at linuxfoundation.org  Tue Dec 19 07:22:43 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 19 Dec 2023 16:22:43 +0100
Subject: [PATCH] i2c: make i2c_bus_type const
Message-ID: <2023121942-jumble-unethical-3163@gregkh>

Now that the driver core can properly handle constant struct bus_type,
move the i2c_bus_type variable to be a constant structure as well, placing
it into read-only memory which can not be modified at runtime.

Note, the sound/soc/rockchip/rk3399_gru_sound.c also needed tweaking as
it decided to save off a pointer to a bus type for internal stuff, and
it was using the i2c_bus_type as well.

Cc: Wolfram Sang <wsa at kernel.org>
Cc: Liam Girdwood <lgirdwood at gmail.com>
Cc: Mark Brown <broonie at kernel.org>
Cc: Jaroslav Kysela <perex at perex.cz>
Cc: Takashi Iwai <tiwai at suse.com>
Cc: Heiko Stuebner <heiko at sntech.de>
Cc: linux-i2c at vger.kernel.org
Cc: linux-sound at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-rockchip at lists.infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 drivers/i2c/i2c-core-base.c           | 2 +-
 include/linux/i2c.h                   | 2 +-
 sound/soc/rockchip/rk3399_gru_sound.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index eac90a3cf61a..24c6e1b52668 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -689,7 +689,7 @@ static struct attribute *i2c_dev_attrs[] = {
 };
 ATTRIBUTE_GROUPS(i2c_dev);
 
-struct bus_type i2c_bus_type = {
+const struct bus_type i2c_bus_type = {
 	.name		= "i2c",
 	.match		= i2c_device_match,
 	.probe		= i2c_device_probe,
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 0dae9db27538..180462d1a373 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -23,7 +23,7 @@
 #include <linux/swab.h>		/* for swab16 */
 #include <uapi/linux/i2c.h>
 
-extern struct bus_type i2c_bus_type;
+extern const struct bus_type i2c_bus_type;
 extern struct device_type i2c_adapter_type;
 extern struct device_type i2c_client_type;
 
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index 1a504ebd3a0e..6c89c7331229 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -446,7 +446,7 @@ static const struct rockchip_sound_route rockchip_routes[] = {
 
 struct dailink_match_data {
 	const char *compatible;
-	struct bus_type *bus_type;
+	const struct bus_type *bus_type;
 };
 
 static const struct dailink_match_data dailink_match[] = {
-- 
2.43.0



From broonie at kernel.org  Tue Dec 19 07:24:51 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 19 Dec 2023 15:24:51 +0000
Subject: [PATCH] i2c: make i2c_bus_type const
In-Reply-To: <2023121942-jumble-unethical-3163@gregkh>
References: <2023121942-jumble-unethical-3163@gregkh>
Message-ID: <2512ee2f-05ce-4496-9ac3-f3b3a2e4a6b6@sirena.org.uk>

On Tue, Dec 19, 2023 at 04:22:43PM +0100, Greg Kroah-Hartman wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the i2c_bus_type variable to be a constant structure as well, placing
> it into read-only memory which can not be modified at runtime.

Acked-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/29325c60/attachment.sig>

From jan.kiszka at siemens.com  Tue Dec 19 07:37:42 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 19 Dec 2023 16:37:42 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <ce6b002b-f2a6-4056-bf81-53a6c948b946@linaro.org>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
 <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
 <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
 <ce6b002b-f2a6-4056-bf81-53a6c948b946@linaro.org>
Message-ID: <62be89bb-1ae1-4bf6-9f9e-b6eb68e6504d@siemens.com>

On 19.12.23 10:58, Krzysztof Kozlowski wrote:
> On 19/12/2023 10:54, Jan Kiszka wrote:
>>>>> You mean label. Why node names became the ABI? Which interface exposes them?
>>>>
>>>> root at iot2050-debian:~# ls -l /sys/class/leds/
>>>> total 0
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus at 100000/4fa0000.mmc/leds/mmc0::
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus at 100000/4f80000.mmc/leds/mmc1::
>>>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
>>>
>>> I replied too fast previous and did not include answer here:
>>>
>>> You have label for that... Somehow all these nodes are half-baked,
>>> without all the expected properties and now you call node name as ABI.
>>> The node name is not the ABI.
>>
>> Well, existing userspace uses those names, and adding the properties
>> would break that interface. Now, does Linux do that?
> 
> I don't think you understood the concept. There is no change for
> userspace. Same interface, same names. No ABI break.

I do understand the impact very well:
open("/sys/class/leds/user-led1-red") has to work for all the variants,
consistently and backward-compatible for userspace.

> 
> Anyway, changing them is not part of this patchset since these are not
> new nodes.

Fine, then we can leave the LED topic aside for now.

I will look into the other comments.

Jan

-- 
Siemens AG, Technology
Linux Expert Center



From krzysztof.kozlowski at linaro.org  Tue Dec 19 07:39:35 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 16:39:35 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <62be89bb-1ae1-4bf6-9f9e-b6eb68e6504d@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
 <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
 <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
 <ce6b002b-f2a6-4056-bf81-53a6c948b946@linaro.org>
 <62be89bb-1ae1-4bf6-9f9e-b6eb68e6504d@siemens.com>
Message-ID: <f6241b58-202e-4624-ae83-ce52fc286edf@linaro.org>

On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>
>>>> You have label for that... Somehow all these nodes are half-baked,
>>>> without all the expected properties and now you call node name as ABI.
>>>> The node name is not the ABI.
>>>
>>> Well, existing userspace uses those names, and adding the properties
>>> would break that interface. Now, does Linux do that?
>>
>> I don't think you understood the concept. There is no change for
>> userspace. Same interface, same names. No ABI break.
> 
> I do understand the impact very well:
> open("/sys/class/leds/user-led1-red") has to work for all the variants,
> consistently and backward-compatible for userspace.

And it will. The name is the same.

Best regards,
Krzysztof



From jbx6244 at gmail.com  Tue Dec 19 07:40:12 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Tue, 19 Dec 2023 16:40:12 +0100
Subject: [PATCH v2 2/2] drm/rockchip: rk3066_hdmi: drop custom fill_modes
 hook
In-Reply-To: <evaq3yfbqf4gchsps2qoojemtii7tmcss24aruiuze5kkzlnhy@mih7rky7viqz>
References: <f86ec29f-194a-800d-0aaf-9e16e551b37d@gmail.com>
 <410b116b-cb63-7ba7-3689-4f0832ab5796@gmail.com>
 <evaq3yfbqf4gchsps2qoojemtii7tmcss24aruiuze5kkzlnhy@mih7rky7viqz>
Message-ID: <4aeef6df-2616-0741-00a3-6e45ec63f920@gmail.com>



On 12/19/23 13:55, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Dec 18, 2023 at 04:49:06PM +0100, Johan Jonker wrote:
>> CRTC size validation for the display controller has been added with
>> Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
>> hardware capabilities"), so we can drop the custom fill_modes hook.
>>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> 

> I'm not sure those two are equivalent. CRTC and connectors usually have
> different requirements and capabilities, and thus different,
> supplementary, mode_valid/atomic_check implementations.

Rockchip RK3066 CRTC and connector resolution max_output are equivalent.

>From Rockchip PX2 TRM V1.0.pdf page 17:
- Video Encoder
  Maximum frame rate is up to 30fps at 1920x1080

- Display Interface
  Support LCD or TFT interfaces up to 1920x1080

- HDMI TX Interface
   HDMI version 1.4a, HDCP revision 1.4 and DVI version 1.0 compliant transmitter
   Supports DTV from 480i to 1080i/p HD resolution, and PC from VGA to UXGA by LCDC0 or LCDC1 in RK PX2


Compared to the drm_helper_probe_single_connector_modes() this function added an extra max_output

Checked in rockchip_drm_vop.c is:
https://lore.kernel.org/linux-rockchip/20230216102447.582905-2-s.hauer at pengutronix.de/

+	if (vop->data->max_output.width && mode->hdisplay > vop->data->max_output.width)
+		return MODE_BAD_HVALUE;
+
+	if (vop->data->max_output.height && mode->vdisplay > vop->data->max_output.height)
+		return MODE_BAD_VVALUE;

For RK3066 VOP max_output:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/rockchip_vop_reg.c#n506

This patch was made with HDMI in mind.

	.max_output = { 1920, 1080 },

This first part was added by Heiko, but not was not part my patch that I submitted:
-	if (maxX > 1920)
-		maxX = 1920;
-	if (maxY > 1080)
-		maxY = 1080;
-
-	return drm_helper_probe_single_connector_modes(connector, maxX, maxY);
-}

Original patch:
https://patchwork.freedesktop.org/patch/msgid/20190330095639.14626-2-jbx6244 at gmail.com

+static int
+rk3066_hdmi_probe_single_connector_modes(struct drm_connector *connector,
+					 uint32_t maxX, uint32_t maxY)
+{
+	return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+}

Rockchip RK3066 CRTC and connector resolution max_output are equivalent.

Johan

> 
> Maxime


From jan.kiszka at siemens.com  Tue Dec 19 07:40:48 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 19 Dec 2023 16:40:48 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <f6241b58-202e-4624-ae83-ce52fc286edf@linaro.org>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
 <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
 <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
 <ce6b002b-f2a6-4056-bf81-53a6c948b946@linaro.org>
 <62be89bb-1ae1-4bf6-9f9e-b6eb68e6504d@siemens.com>
 <f6241b58-202e-4624-ae83-ce52fc286edf@linaro.org>
Message-ID: <29c030e1-c493-4521-b5e8-db3f484eefb8@siemens.com>

On 19.12.23 16:39, Krzysztof Kozlowski wrote:
> On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>>
>>>>> You have label for that... Somehow all these nodes are half-baked,
>>>>> without all the expected properties and now you call node name as ABI.
>>>>> The node name is not the ABI.
>>>>
>>>> Well, existing userspace uses those names, and adding the properties
>>>> would break that interface. Now, does Linux do that?
>>>
>>> I don't think you understood the concept. There is no change for
>>> userspace. Same interface, same names. No ABI break.
>>
>> I do understand the impact very well:
>> open("/sys/class/leds/user-led1-red") has to work for all the variants,
>> consistently and backward-compatible for userspace.
> 
> And it will. The name is the same.

Nope, it's not - I tried that already :)

root at iot2050-debian:~# ls -l /sys/class/leds/
total 0
lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator
lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:status -> ../../devices/platform/leds/leds/green:status
lrwxrwxrwx 1 root root 0 Dec 19 09:49 mmc0:: -> ../../devices/platform/bus at 100000/4fa0000.mmc/leds/mmc0::
lrwxrwxrwx 1 root root 0 Dec 19 09:49 mmc1:: -> ../../devices/platform/bus at 100000/4f80000.mmc/leds/mmc1::
lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:indicator -> ../../devices/platform/leds/leds/red:indicator
lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:indicator_1 -> ../../devices/platform/leds/leds/red:indicator_1
lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:indicator_2 -> ../../devices/platform/leds/leds/red:indicator_2
lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:status -> ../../devices/platform/leds/leds/red:status

Jan

-- 
Siemens AG, Technology
Linux Expert Center



From krzysztof.kozlowski at linaro.org  Tue Dec 19 07:42:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 16:42:12 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <29c030e1-c493-4521-b5e8-db3f484eefb8@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
 <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
 <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
 <ce6b002b-f2a6-4056-bf81-53a6c948b946@linaro.org>
 <62be89bb-1ae1-4bf6-9f9e-b6eb68e6504d@siemens.com>
 <f6241b58-202e-4624-ae83-ce52fc286edf@linaro.org>
 <29c030e1-c493-4521-b5e8-db3f484eefb8@siemens.com>
Message-ID: <7edab40c-1ac2-4044-9337-9f26e80024a1@linaro.org>

On 19/12/2023 16:40, Jan Kiszka wrote:
> On 19.12.23 16:39, Krzysztof Kozlowski wrote:
>> On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>>>
>>>>>> You have label for that... Somehow all these nodes are half-baked,
>>>>>> without all the expected properties and now you call node name as ABI.
>>>>>> The node name is not the ABI.
>>>>>
>>>>> Well, existing userspace uses those names, and adding the properties
>>>>> would break that interface. Now, does Linux do that?
>>>>
>>>> I don't think you understood the concept. There is no change for
>>>> userspace. Same interface, same names. No ABI break.
>>>
>>> I do understand the impact very well:
>>> open("/sys/class/leds/user-led1-red") has to work for all the variants,
>>> consistently and backward-compatible for userspace.
>>
>> And it will. The name is the same.
> 
> Nope, it's not - I tried that already :)
> 
> root at iot2050-debian:~# ls -l /sys/class/leds/
> total 0
> lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator

And how does your DTS look like?

Because I also tried and it is exactly the same.

Best regards,
Krzysztof



From jan.kiszka at siemens.com  Tue Dec 19 07:48:18 2023
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Tue, 19 Dec 2023 16:48:18 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <7edab40c-1ac2-4044-9337-9f26e80024a1@linaro.org>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
 <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
 <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
 <ce6b002b-f2a6-4056-bf81-53a6c948b946@linaro.org>
 <62be89bb-1ae1-4bf6-9f9e-b6eb68e6504d@siemens.com>
 <f6241b58-202e-4624-ae83-ce52fc286edf@linaro.org>
 <29c030e1-c493-4521-b5e8-db3f484eefb8@siemens.com>
 <7edab40c-1ac2-4044-9337-9f26e80024a1@linaro.org>
Message-ID: <cc6b7f99-3439-45a1-b4b4-0b5796dcbbbf@siemens.com>

On 19.12.23 16:42, Krzysztof Kozlowski wrote:
> On 19/12/2023 16:40, Jan Kiszka wrote:
>> On 19.12.23 16:39, Krzysztof Kozlowski wrote:
>>> On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>>>>
>>>>>>> You have label for that... Somehow all these nodes are half-baked,
>>>>>>> without all the expected properties and now you call node name as ABI.
>>>>>>> The node name is not the ABI.
>>>>>>
>>>>>> Well, existing userspace uses those names, and adding the properties
>>>>>> would break that interface. Now, does Linux do that?
>>>>>
>>>>> I don't think you understood the concept. There is no change for
>>>>> userspace. Same interface, same names. No ABI break.
>>>>
>>>> I do understand the impact very well:
>>>> open("/sys/class/leds/user-led1-red") has to work for all the variants,
>>>> consistently and backward-compatible for userspace.
>>>
>>> And it will. The name is the same.
>>
>> Nope, it's not - I tried that already :)
>>
>> root at iot2050-debian:~# ls -l /sys/class/leds/
>> total 0
>> lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator
> 
> And how does your DTS look like?
> 
> Because I also tried and it is exactly the same.
> 

I played with

diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
index 402afa4bc1b6..a791444eeb93 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -10,6 +10,7 @@
  */
 
 #include "k3-am654.dtsi"
+#include <dt-bindings/leds/common.h>
 #include <dt-bindings/phy/phy.h>
 #include <dt-bindings/net/ti-dp83867.h>
 
@@ -84,27 +85,39 @@ leds {
 		pinctrl-0 = <&leds_pins_default>;
 
 		status-led-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_STATUS;
 			gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>;
 			panic-indicator;
 		};
 
 		status-led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
 			gpios = <&wkup_gpio0 24 GPIO_ACTIVE_HIGH>;
 		};
 
 		user-led1-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_INDICATOR;
 			gpios = <&pcal9535_3 14 GPIO_ACTIVE_HIGH>;
 		};
 
 		user-led1-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_INDICATOR;
 			gpios = <&pcal9535_2 15 GPIO_ACTIVE_HIGH>;
 		};
 
 		user-led2-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_INDICATOR;
 			gpios = <&wkup_gpio0 17 GPIO_ACTIVE_HIGH>;
 		};
 
 		user-led2-green {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_INDICATOR;
 			gpios = <&wkup_gpio0 22 GPIO_ACTIVE_HIGH>;
 		};
 	};

Jan

-- 
Siemens AG, Technology
Linux Expert Center



From fancer.lancer at gmail.com  Tue Dec 19 07:53:58 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue, 19 Dec 2023 18:53:58 +0300
Subject: [PATCH net v2 1/1] net: stmmac: fix incorrect flag check in
 timestamp interrupt
In-Reply-To: <1702885892-30369-1-git-send-email-jun.ann.lai@intel.com>
References: <1702885892-30369-1-git-send-email-jun.ann.lai@intel.com>
Message-ID: <bhw5l75erhcci7z55vrcos43qtyn7txsspv6qtazhlulpbn7km@dp6yg6sf2gwk>

On Mon, Dec 18, 2023 at 03:51:32PM +0800, Lai Peter Jun Ann wrote:
> The driver should continue get the timestamp if STMMAC_FLAG_EXT_SNAPSHOT_EN
> flag is set.
> 
> Fixes: aa5513f5d95f ("net: stmmac: replace the ext_snapshot_en field with a flag")
> Cc: <stable at vger.kernel.org> # 6.6
> Signed-off-by: Song Yoong Siang <yoong.siang.song at intel.com>
> Signed-off-by: Lai Peter Jun Ann <jun.ann.lai at intel.com>

Right. The blamed commit has wrongly converted that conditional
statement.

Reviewed-by: Serge Semin <fancer.lancer at gmail.com>

-Serge(y)

> ---
> v2 changelog:
>  - Add fix tag and stable at vger.kernel.org in email cc list.
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> index 540f6a4..f05bd75 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> @@ -237,7 +237,7 @@ static void timestamp_interrupt(struct stmmac_priv *priv)
>  	 */
>  	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
>  
> -	if (priv->plat->flags & STMMAC_FLAG_EXT_SNAPSHOT_EN)
> +	if (!(priv->plat->flags & STMMAC_FLAG_EXT_SNAPSHOT_EN))
>  		return;
>  
>  	num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
> -- 
> 1.9.1
> 
> 


From krzysztof.kozlowski at linaro.org  Tue Dec 19 07:56:01 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 19 Dec 2023 16:56:01 +0100
Subject: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant
In-Reply-To: <cc6b7f99-3439-45a1-b4b4-0b5796dcbbbf@siemens.com>
References: <cover.1702917360.git.jan.kiszka@siemens.com>
 <11e0b0c8b828254567a8ff89820c067cacad2150.1702917360.git.jan.kiszka@siemens.com>
 <8b3daa3c-dbf8-4286-b04e-011cd9b0efa5@linaro.org>
 <4c31adc5-3fc5-47bc-9766-6d3d1eeddb65@siemens.com>
 <fbb29d81-9ea0-4468-ad47-f6668c2be277@linaro.org>
 <de3f4778-51d6-48ab-9d4d-451f2ba01a3c@siemens.com>
 <3d2662be-3a55-4390-bd2a-cfa5cc53510f@linaro.org>
 <ef5a6cf0-4350-483d-a1e9-ce8b0ef71280@siemens.com>
 <ce6b002b-f2a6-4056-bf81-53a6c948b946@linaro.org>
 <62be89bb-1ae1-4bf6-9f9e-b6eb68e6504d@siemens.com>
 <f6241b58-202e-4624-ae83-ce52fc286edf@linaro.org>
 <29c030e1-c493-4521-b5e8-db3f484eefb8@siemens.com>
 <7edab40c-1ac2-4044-9337-9f26e80024a1@linaro.org>
 <cc6b7f99-3439-45a1-b4b4-0b5796dcbbbf@siemens.com>
Message-ID: <be4011c2-4628-45d7-a2c2-6d936ad2b636@linaro.org>

On 19/12/2023 16:48, Jan Kiszka wrote:
> On 19.12.23 16:42, Krzysztof Kozlowski wrote:
>> On 19/12/2023 16:40, Jan Kiszka wrote:
>>> On 19.12.23 16:39, Krzysztof Kozlowski wrote:
>>>> On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>>>>>
>>>>>>>> You have label for that... Somehow all these nodes are half-baked,
>>>>>>>> without all the expected properties and now you call node name as ABI.
>>>>>>>> The node name is not the ABI.
>>>>>>>
>>>>>>> Well, existing userspace uses those names, and adding the properties
>>>>>>> would break that interface. Now, does Linux do that?
>>>>>>
>>>>>> I don't think you understood the concept. There is no change for
>>>>>> userspace. Same interface, same names. No ABI break.
>>>>>
>>>>> I do understand the impact very well:
>>>>> open("/sys/class/leds/user-led1-red") has to work for all the variants,
>>>>> consistently and backward-compatible for userspace.
>>>>
>>>> And it will. The name is the same.
>>>
>>> Nope, it's not - I tried that already :)
>>>
>>> root at iot2050-debian:~# ls -l /sys/class/leds/
>>> total 0
>>> lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator
>>
>> And how does your DTS look like?
>>
>> Because I also tried and it is exactly the same.
>>
> 
> I played with
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> index 402afa4bc1b6..a791444eeb93 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> @@ -10,6 +10,7 @@
>   */
>  
>  #include "k3-am654.dtsi"
> +#include <dt-bindings/leds/common.h>
>  #include <dt-bindings/phy/phy.h>
>  #include <dt-bindings/net/ti-dp83867.h>
>  
> @@ -84,27 +85,39 @@ leds {
>  		pinctrl-0 = <&leds_pins_default>;
>  
>  		status-led-red {
> +			color = <LED_COLOR_ID_RED>;
> +			function = LED_FUNCTION_STATUS;
>  			gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>;
>  			panic-indicator;

And where is the label property?

Please read my message again:

>> You:
>> patch, but the node names are now part of the kernel ABI. Changing
them would break existing userland.
> Me:
> You mean label. Why node names became the ABI? Which interface exposes
them?


>> You:
>> root at iot2050-debian:~# ls -l /sys/class/leds/
> Me:
> I replied too fast previous and did not include answer here:
> You have label for that...

So again: The stable ABI is fulfilled by using label property. Not the
Devicetree "label" phandle in front of the node, but the dedicated property.

Best regards,
Krzysztof



From fancer.lancer at gmail.com  Tue Dec 19 08:13:55 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Tue, 19 Dec 2023 19:13:55 +0300
Subject: =?utf-8?B?5Zue5aSNOiBbUEFUQ0g=?= =?utf-8?Q?=5D?=
 net:stmmac:stmmac_platform:Add snps,xpcs devicetree parsing
In-Reply-To: <SA0PR12MB4413305305D47CAAAFEAD528D98EA@SA0PR12MB4413.namprd12.prod.outlook.com>
References: <SA0PR12MB44138E48A245378CF54D2F9ED98AA@SA0PR12MB4413.namprd12.prod.outlook.com>
 <20231208091408.071680db@device.home>
 <uzss3af2cklc5bx5apszoegafeaaiv7o7iwgrgrml4grkyev6p@6tme4hdb4mkn>
 <SA0PR12MB4413305305D47CAAAFEAD528D98EA@SA0PR12MB4413.namprd12.prod.outlook.com>
Message-ID: <iot4xazx5w5ckx77emdz2pcqds573wvnnegtw2rznk6ezrix2m@quhutbzqmtav>

On Tue, Dec 12, 2023 at 10:50:53AM +0000, Jiangfeng Ma wrote:
> 
> 
> > -----????-----
> > ???: Serge Semin <fancer.lancer at gmail.com>
> > ????: Friday, December 8, 2023 10:28 PM
> > ???: Maxime Chevallier <maxime.chevallier at bootlin.com>; Jiangfeng Ma <jiama at synopsys.com>
> > ??: Jiangfeng Ma <jiama at synopsys.com>; Alexandre Torgue <alexandre.torgue at foss.st.com>; Jose
> > Abreu <joabreu at synopsys.com>; David S. Miller <davem at davemloft.net>; Eric Dumazet
> > <edumazet at google.com>; Jakub Kicinski <kuba at kernel.org>; Paolo Abeni <pabeni at redhat.com>;
> > Maxime Coquelin <mcoquelin.stm32 at gmail.com>; Simon Horman <horms at kernel.org>; Andrew
> > Halaney <ahalaney at redhat.com>; Bartosz Golaszewski <bartosz.golaszewski at linaro.org>; Shenwei
> > Wang <shenwei.wang at nxp.com>; Johannes Zink <j.zink at pengutronix.de>; Russell King (Oracle
> > <rmk+kernel at armlinux.org.uk>; Jochen Henneberg <jh at henneberg-systemdesign.com>; open
> > list:STMMAC ETHERNET DRIVER <netdev at vger.kernel.org>; moderated list:ARM/STM32
> > ARCHITECTURE <linux-stm32 at st-md-mailman.stormreply.com>; moderated list:ARM/STM32
> > ARCHITECTURE <linux-arm-kernel at lists.infradead.org>; open list <linux-kernel at vger.kernel.org>; James
> > Li <lijames at synopsys.com>; Martin McKenny <mmckenny at synopsys.com>
> > ??: Re: [PATCH] net:stmmac:stmmac_platform:Add snps,xpcs devicetree parsing
> > 
> Hi Maxime, Serge
> Thanks for your review!
> 
> > Hi Maxime, Jiangfeng
> > 
> > On Fri, Dec 08, 2023 at 09:14:08AM +0100, Maxime Chevallier wrote:
> > > Hello,
> > >
> > > On Fri, 8 Dec 2023 07:02:19 +0000
> > > Jiangfeng Ma <Jiangfeng.Ma at synopsys.com> wrote:
> > >
> > > > In order to setup xpcs, has_xpcs must be set to a non-zero value.
> > > > Add new optional devicetree properties representing this.
> > > >
> > > > If has_xpcs is set to true, then xpcs_an_inband should preferably be
> > > > consistent with it, Otherwise, some errors may occur when starting
> > > > the network, For example, the phy interface that xpcs already supports,
> > > > but link up fails.
> > >
> > > Can you elaborate on why you need this, and on which platform
> > > especially ? Usually drivers for the various stmmac variants know if
> > > they have XPCS or not, or can guess it based on some info such as the
> > > configured PHY mode (dwmac-intel).
> 
> There is no specific platform here. I utilize the dwmcac-generic platform,
> and xpcs is utilized as the MDIO device or it can be seen as a C45 PHY.
> While it's sometimes possible to deduce the presence of xpcs based on information
> such as the phy mode (dwmac-intel), this is not always a definitive indicator.
> For instance, the support of SGMII by XPCS doesn't imply
> that all SGMII-supporting PHYs include XPCS. But as Serge mentioned, using pcs-handle,
> or pcs-handle-name might be a more effective approach.
> > >
> > > Besides that, there are a few issues with your submission. If DT is the
> > > way to go (and I don't say it is), you would also need to update the
> > > bindings to document that property.
> > >
> > > > The types of has_xpcs and xpcs_an_inband are unsigned int,
> > > > and generally used as flags. So it may be more reasonable to set them to
> > > > bool type. This can also be confirmed from the type of @ovr_an_inband.
> > >
> > > And this part would go into a separate patch.
> Sorry for this issue, I will create the patch separately later.
> > 
> > In addition to what Maxime already said having DT-bindings adjusted to
> > fit to the pattern implemented in the software part is a wrong way to
> > go. The best choice in this case is to add the DW XPCS DT-node to the
> > DW MAC MDIO/MI bus and then use the "pcs-handle" to inform the MAC
> > (mainly it's driver) of what PCS-device is actually attached to it.
> > The series I submitted on this week is exactly about that:
> > https://urldefense.com/v3/__https://lore.kernel.org/netdev/20231205103559.9605-1-fancer.lancer at g
> > mail.com/__;!!A4F2R9G_pg!Y6R3WZWHeBdrkZklbqrAQARbHnQ-g_Tbb6r5IqcsSHMQ_l4rOzLLgZvLPl6YP
> > BYferbjrbjZA6_XvSSSvkV35eo2jWPz$
> > I guess I'll need about a month or so to settle all the comments, but
> > the solution implemented there will be better than this one really.
> >

> Yes, I agree that binding the xpcs via the "pcs-handle" DT firmware node 
> is a better way. but the current method of binding xpcs through scanning 
> addresses still relies on mdio_bus_data->has_xpcs.

It doesn't matter on what the code relies. What matters is to
correctly describe the hardware. Adding the 'snps,xpcs' property would
just be a workround so to make things working because the driver was
designed that way.

> The 16th patch in your patchset also mentions the difficulty of 
> obtaining has_xpcs. Therefore, can we add parsing of pcs-handle-names 
> in the platform to determine if the xpcs exists, like this:
> 
> if (plat->mdio_bus_data) {
> 	rc = of_property_match_string(np, "pcs-handle-names", "dw-xpcs");
> 	if (rc >= 0) {
> 		plat->mdio_bus_data->has_xpcs = true;
> 		plat->mdio_bus_data->xpcs_an_inband = true;
> 	}
> }

It won't make sense. 'pcs-handle' would already point out to the
MDIO-device. Since it's doubtfully there is DW XGMAC connected to more
than one PCS device, then there is no need in the named handle
property. Moreover your way of bindings violates bindings rule that
the 'pcs-handle-names' array should always be specified together with
the phandles array:
Documentation/devicetree/bindings/net/ethernet-controller.yaml

Please be patient. After my patchset is merged in, the only thing what
you would need is to do something like this:

xgmac: ethernet at 1f054000 {
	compatible = "snps,dwxgmac";
	reg = <0 0x1f054000 0 0x4000>;

	...

	pcs-handle = <&xgmac_pcs>;

	xgmac_mdio: mdio {
		compatible = "snps,dwmac-mdio";
		#address-cells = <1>;
		#size-cells = <0>;

		xgmac_pcs: ethernet-pcs at 0 {
			compatible = "snps,dw-xpcs";
			reg = <0>;
		};
	};
};

If no XPCS available, just omit the 'pcs-handle' property and the
respective MDIO-bus sub-node.

-Serge(y)

> 
> Thanks,
> Jiangfeng
> 
> > -Serge(y)
> > 
> > >
> > > Thanks,
> > >
> > > Maxime
> > >


From kamal.dasu at broadcom.com  Tue Dec 19 08:22:34 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Tue, 19 Dec 2023 11:22:34 -0500
Subject: [PATCH v5 0/2]  mmc: add new sdhci reset sequence for brcm 74165b0
Message-ID: <20231219162236.36609-1-kamal.dasu@broadcom.com>

v5 changes
 - got rid of  'Reported by:' and 'Closes:' tags for all patches
   
v4 changes:
 - Fix for v3 changes that introduced dt schema errors
 - Fix for v3 changes that introduced sdhci-brcmstb build warnings 
 - Added proper PATCH format and cleanup commit messages as per
   review comments. Added proper 'Reported-by' and 'Closes' tags
 - Added comments for 32-bit register access as per review comments
 - Replaced wait loop polling with readb_poll_timeout() helper as per
   review comments for the sdhci-brcmstb driver changes
 
v3 changes:
 - Removed extra emun arrayfor possible compatible strings
 - shdci-brcmstb checkpatch warning fixes 

v2 changes:
 - Fixed devicetree bindings for shdci-brcmstb and removed 74165 compatible
   string as per review comments

Kamal Dasu (2):
  dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
  mmc: add new sdhci reset sequence for brcm 74165b0

 .../bindings/mmc/brcm,sdhci-brcmstb.yaml      |  4 +-
 drivers/mmc/host/sdhci-brcmstb.c              | 67 +++++++++++++++++--
 2 files changed, 63 insertions(+), 8 deletions(-)

-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/76bb0237/attachment.p7s>

From kamal.dasu at broadcom.com  Tue Dec 19 08:22:35 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Tue, 19 Dec 2023 11:22:35 -0500
Subject: [PATCH v5 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
In-Reply-To: <20231219162236.36609-1-kamal.dasu@broadcom.com>
References: <20231219162236.36609-1-kamal.dasu@broadcom.com>
Message-ID: <20231219162236.36609-2-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

With newer sdio controller core used for 74165b0 we need to update
the compatibility with "brcm,bcm74165b0-sdhci".

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
---
 Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
index c028039bc477..cbd3d6c6c77f 100644
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
+++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
@@ -20,10 +20,8 @@ properties:
           - const: brcm,sdhci-brcmstb
       - items:
           - enum:
+              - brcm,bcm74165b0-sdhci
               - brcm,bcm7445-sdhci
-          - const: brcm,sdhci-brcmstb
-      - items:
-          - enum:
               - brcm,bcm7425-sdhci
           - const: brcm,sdhci-brcmstb
 
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/3ae2455d/attachment-0001.p7s>

From kamal.dasu at broadcom.com  Tue Dec 19 08:22:36 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Tue, 19 Dec 2023 11:22:36 -0500
Subject: [PATCH v5 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231219162236.36609-1-kamal.dasu@broadcom.com>
References: <20231219162236.36609-1-kamal.dasu@broadcom.com>
Message-ID: <20231219162236.36609-3-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

74165b0 shall use a new sdio controller core version which
requires a different reset sequence. For core reset we use
sdhci_reset. For CMD and/or DATA reset added a new function
to also enable SDHCI clocks SDHCI_CLOCK_CARD_EN
SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
SDHCI_RESET_DATA fields.

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
---
 drivers/mmc/host/sdhci-brcmstb.c | 67 +++++++++++++++++++++++++++++---
 1 file changed, 62 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index c23251bb95f3..7c5d04be93b3 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -6,6 +6,7 @@
  */
 
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/mmc/host.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -44,8 +45,13 @@ struct brcmstb_match_priv {
 
 static inline void enable_clock_gating(struct sdhci_host *host)
 {
+	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
 	u32 reg;
 
+	if (!(priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK))
+		return;
+
 	reg = sdhci_readl(host, SDHCI_VENDOR);
 	reg |= SDHCI_VENDOR_GATE_SDCLK_EN;
 	sdhci_writel(host, reg, SDHCI_VENDOR);
@@ -53,14 +59,51 @@ static inline void enable_clock_gating(struct sdhci_host *host)
 
 static void brcmstb_reset(struct sdhci_host *host, u8 mask)
 {
-	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
-
 	sdhci_and_cqhci_reset(host, mask);
 
 	/* Reset will clear this, so re-enable it */
-	if (priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK)
-		enable_clock_gating(host);
+	enable_clock_gating(host);
+}
+
+static void brcmstb_sdhci_reset_cmd_data(struct sdhci_host *host, u8 mask)
+{
+	int ret;
+	u32 reg;
+	u32 new_mask = (mask &  (SDHCI_RESET_CMD | SDHCI_RESET_DATA)) << 24;
+
+	/*
+	 * SDHCI_CLOCK_CONTROL register CARD_EN and CLOCK_INT_EN bits shall
+	 * be set along with SOFTWARE_RESET register RESET_CMD or RESET_DATA
+	 * bits, hence access SDHCI_CLOCK_CONTROL register as 32-bit register
+	 */
+	new_mask |= SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN;
+	reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
+	sdhci_writel(host, reg | new_mask, SDHCI_CLOCK_CONTROL);
+
+	reg = sdhci_readb(host, SDHCI_SOFTWARE_RESET);
+	ret = readb_poll_timeout(host->ioaddr + SDHCI_SOFTWARE_RESET,
+				 reg, reg & mask, 10, 10000);
+
+	if (ret) {
+		pr_err("%s: Reset 0x%x never completed.\n",
+		       mmc_hostname(host->mmc), (int)mask);
+		sdhci_err_stats_inc(host, CTRL_TIMEOUT);
+		sdhci_dumpregs(host);
+	}
+}
+
+static void brcmstb_reset_74165b0(struct sdhci_host *host, u8 mask)
+{
+	/* take care of RESET_ALL as usual */
+	if (mask & SDHCI_RESET_ALL)
+		sdhci_and_cqhci_reset(host, SDHCI_RESET_ALL);
+
+	/* cmd and/or data treated differently on this core */
+	if (mask & (SDHCI_RESET_CMD | SDHCI_RESET_DATA))
+		brcmstb_sdhci_reset_cmd_data(host, mask);
+
+	/* Reset will clear this, so re-enable it */
+	enable_clock_gating(host);
 }
 
 static void sdhci_brcmstb_hs400es(struct mmc_host *mmc, struct mmc_ios *ios)
@@ -162,6 +205,13 @@ static struct sdhci_ops sdhci_brcmstb_ops_7216 = {
 	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
 };
 
+static struct sdhci_ops sdhci_brcmstb_ops_74165b0 = {
+	.set_clock = sdhci_brcmstb_set_clock,
+	.set_bus_width = sdhci_set_bus_width,
+	.reset = brcmstb_reset_74165b0,
+	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
+};
+
 static struct brcmstb_match_priv match_priv_7425 = {
 	.flags = BRCMSTB_MATCH_FLAGS_NO_64BIT |
 	BRCMSTB_MATCH_FLAGS_BROKEN_TIMEOUT,
@@ -179,10 +229,17 @@ static const struct brcmstb_match_priv match_priv_7216 = {
 	.ops = &sdhci_brcmstb_ops_7216,
 };
 
+static struct brcmstb_match_priv match_priv_74165b0 = {
+	.flags = BRCMSTB_MATCH_FLAGS_HAS_CLOCK_GATE,
+	.hs400es = sdhci_brcmstb_hs400es,
+	.ops = &sdhci_brcmstb_ops_74165b0,
+};
+
 static const struct of_device_id __maybe_unused sdhci_brcm_of_match[] = {
 	{ .compatible = "brcm,bcm7425-sdhci", .data = &match_priv_7425 },
 	{ .compatible = "brcm,bcm7445-sdhci", .data = &match_priv_7445 },
 	{ .compatible = "brcm,bcm7216-sdhci", .data = &match_priv_7216 },
+	{ .compatible = "brcm,bcm74165b0-sdhci", .data = &match_priv_74165b0 },
 	{},
 };
 
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/b1127296/attachment.p7s>

From David.Laight at ACULAB.COM  Tue Dec 19 08:24:17 2023
From: David.Laight at ACULAB.COM (David Laight)
Date: Tue, 19 Dec 2023 16:24:17 +0000
Subject: [PATCH v2] fix overflow in idle exit_latency
In-Reply-To: <20231219031444.91752-1-bo.ye@mediatek.com>
References: <20231219031444.91752-1-bo.ye@mediatek.com>
Message-ID: <e807b180b074419ba4f1d1ff8a4c1a80@AcuMS.aculab.com>

From: Bo Ye 
> Sent: 19 December 2023 03:15
> 
> From: C Cheng <C.Cheng at mediatek.com>
> 
> In detail:
> 
> In C language, when you perform a multiplication operation, if
> both operands are of int type, the multiplication operation is
> performed on the int type, and then the result is converted to
> the target type. This means that if the product of int type
> multiplication exceeds the range that int type can represent,
>  an overflow will occur even if you store the result in a
> variable of int64_t type.
> 
> For a multiplication of two int values, it is better to use
> mul_u32_u32() rather than s->exit_latency_ns = s->exit_latency *
> NSEC_PER_USEC to avoid potential overflow happenning.
> 
> Signed-off-by: C Cheng <C.Cheng at mediatek.com>
> Signed-off-by: Bo Ye <bo.ye at mediatek.com>
> ---
> Change in v2:
> -remove Change-ID
> -correct patch author name
> -replace multiplication of two int values with mul_u32_u32
> -refine commit message
> ---
>  drivers/cpuidle/driver.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> index d9cda7f6ccb9..cf5873cc45dc 100644
> --- a/drivers/cpuidle/driver.c
> +++ b/drivers/cpuidle/driver.c
> @@ -16,6 +16,7 @@
>  #include <linux/cpumask.h>
>  #include <linux/tick.h>
>  #include <linux/cpu.h>
> +#include <linux/math64.h>
> 
>  #include "cpuidle.h"
> 
> @@ -187,7 +188,7 @@ static void __cpuidle_driver_init(struct cpuidle_driver *drv)
>  			s->target_residency = div_u64(s->target_residency_ns, NSEC_PER_USEC);
> 
>  		if (s->exit_latency > 0)
> -			s->exit_latency_ns = s->exit_latency * NSEC_PER_USEC;
> +			s->exit_latency_ns = mul_u32_u32(s->exit_latency, NSEC_PER_USEC);

Just force either side of the multiply to a 64bit unsigned type.
The compiler will then DTRT which is likely to be better code than
whatever mul_u32_u32() generates.

In any case is the 'exit_latency' ever going to be greater than 4 seconds?
In which case the 32bit multiply will never overflow.

	David

>  		else if (s->exit_latency_ns < 0)
>  			s->exit_latency_ns =  0;
>  		else
> --
> 2.18.0
> 

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From jthoughton at google.com  Tue Dec 19 08:28:54 2023
From: jthoughton at google.com (James Houghton)
Date: Tue, 19 Dec 2023 11:28:54 -0500
Subject: [PATCH 09/13] mm/gup: Cache *pudp in follow_pud_mask()
In-Reply-To: <20231219075538.414708-10-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com> <20231219075538.414708-10-peterx@redhat.com>
Message-ID: <CADrL8HVu8=-DdAwXN_pO91g1A1+F7bKfBRpm6jYfYMk1QZcRFA@mail.gmail.com>

On Tue, Dec 19, 2023 at 2:57?AM <peterx at redhat.com> wrote:
>
> From: Peter Xu <peterx at redhat.com>
>
> Introduce "pud_t pud" in the function, so the code won't dereference *pudp
> multiple time.  Not only because that looks less straightforward, but also
> because if the dereference really happened, it's not clear whether there
> can be race to see different *pudp values if it's being modified at the
> same time.
>
> Signed-off-by: Peter Xu <peterx at redhat.com>
> ---
>  mm/gup.c | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 6c0d82fa8cc7..97e87b7a15c3 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -753,26 +753,27 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma,
>                                     unsigned int flags,
>                                     struct follow_page_context *ctx)
>  {
> -       pud_t *pud;
> +       pud_t *pudp, pud;
>         spinlock_t *ptl;
>         struct page *page;
>         struct mm_struct *mm = vma->vm_mm;
>
> -       pud = pud_offset(p4dp, address);
> -       if (pud_none(*pud))
> +       pudp = pud_offset(p4dp, address);
> +       pud = *pudp;

I think you might want a READ_ONCE() on this so that the compiler
doesn't actually read the pud multiple times.

> +       if (pud_none(pud))
>                 return no_page_table(vma, flags, address);
> -       if (pud_devmap(*pud)) {
> -               ptl = pud_lock(mm, pud);
> -               page = follow_devmap_pud(vma, address, pud, flags, &ctx->pgmap);
> +       if (pud_devmap(pud)) {
> +               ptl = pud_lock(mm, pudp);
> +               page = follow_devmap_pud(vma, address, pudp, flags, &ctx->pgmap);
>                 spin_unlock(ptl);
>                 if (page)
>                         return page;
>                 return no_page_table(vma, flags, address);
>         }
> -       if (unlikely(pud_bad(*pud)))
> +       if (unlikely(pud_bad(pud)))
>                 return no_page_table(vma, flags, address);

Not your change, but reading this, it's not clear to me that
`pud_present(*pudp)` (and non-leaf) would necessarily be true at this
point -- like, I would prefer to see `!pud_present(pud)` instead of
`pud_bad()`. Thank you for adding that in the next patch. :)

Feel free to add:

Acked-by: James Houghton <jthoughton at google.com>


From maxime.chevallier at bootlin.com  Tue Dec 19 08:29:32 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Tue, 19 Dec 2023 17:29:32 +0100
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
In-Reply-To: <CACRpkdaxy9u=1-rQ+f+1tb8xyV-GYOuq52xhb4_SRPk9-LpnUA@mail.gmail.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
	<20231218162326.173127-2-romain.gantois@bootlin.com>
	<20231219122034.pg2djgrosa4irubh@skbuf>
	<20231219140754.7a7a8dbd@device-28.home>
	<CACRpkdaxy9u=1-rQ+f+1tb8xyV-GYOuq52xhb4_SRPk9-LpnUA@mail.gmail.com>
Message-ID: <20231219172932.13f4b0c3@device-28.home>

Hi Linus,

On Tue, 19 Dec 2023 15:19:45 +0100
Linus Walleij <linus.walleij at linaro.org> wrote:

> On Tue, Dec 19, 2023 at 2:07?PM Maxime Chevallier
> <maxime.chevallier at bootlin.com> wrote:
> 
> > So it looks like an acceptable solution would be something along the
> > lines of what Linus is suggesting here :
> >
> > https://lore.kernel.org/netdev/20231216-new-gemini-ethernet-regression-v2-2-64c269413dfa at linaro.org/
> >
> > If so, maybe it's worth adding a new helper for that check ?  
> 
> Yeah it's a bit annoying when skb->protocol is not == ethertype of buffer.
> 
> I can certainly add a helper such as skb_eth_raw_ethertype()
> to <linux/if_ether.h> that will inspect the actual ethertype in
> skb->data.
> 
> It's the most straight-forward approach.

Agreed :)

> We could also add something like bool custom_ethertype; to
> struct sk_buff and set that to true if the tagger adds a custom
> ethertype. But I don't know how the network developers feel about
> that.

I don't think this would be OK, first because sk_buff is pretty
sensitive when it comes to cache alignment, adding things for this kind
of use-cases isn't necessarily a good idea. Moreover, populating this
flag isn't going to be straightforward as well. I guess some ethertype
would be compatible with checksum engines, while other wouldn't, so
probably what 'custom_ethertype' means will depend on the MAC driver.

From my point of view the first approach would indeed be better.

Thanks,

Maxime


From rafael at kernel.org  Tue Dec 19 08:30:00 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Tue, 19 Dec 2023 17:30:00 +0100
Subject: [PATCH v2] fix overflow in idle exit_latency
In-Reply-To: <e807b180b074419ba4f1d1ff8a4c1a80@AcuMS.aculab.com>
References: <20231219031444.91752-1-bo.ye@mediatek.com> <e807b180b074419ba4f1d1ff8a4c1a80@AcuMS.aculab.com>
Message-ID: <CAJZ5v0gLDZtfGhowxSM+nwBCM80y6sDR56fYZrHNGaRFK1oGyw@mail.gmail.com>

On Tue, Dec 19, 2023 at 5:24?PM David Laight <David.Laight at aculab.com> wrote:
>
> From: Bo Ye
> > Sent: 19 December 2023 03:15
> >
> > From: C Cheng <C.Cheng at mediatek.com>
> >
> > In detail:
> >
> > In C language, when you perform a multiplication operation, if
> > both operands are of int type, the multiplication operation is
> > performed on the int type, and then the result is converted to
> > the target type. This means that if the product of int type
> > multiplication exceeds the range that int type can represent,
> >  an overflow will occur even if you store the result in a
> > variable of int64_t type.
> >
> > For a multiplication of two int values, it is better to use
> > mul_u32_u32() rather than s->exit_latency_ns = s->exit_latency *
> > NSEC_PER_USEC to avoid potential overflow happenning.
> >
> > Signed-off-by: C Cheng <C.Cheng at mediatek.com>
> > Signed-off-by: Bo Ye <bo.ye at mediatek.com>
> > ---
> > Change in v2:
> > -remove Change-ID
> > -correct patch author name
> > -replace multiplication of two int values with mul_u32_u32
> > -refine commit message
> > ---
> >  drivers/cpuidle/driver.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> > index d9cda7f6ccb9..cf5873cc45dc 100644
> > --- a/drivers/cpuidle/driver.c
> > +++ b/drivers/cpuidle/driver.c
> > @@ -16,6 +16,7 @@
> >  #include <linux/cpumask.h>
> >  #include <linux/tick.h>
> >  #include <linux/cpu.h>
> > +#include <linux/math64.h>
> >
> >  #include "cpuidle.h"
> >
> > @@ -187,7 +188,7 @@ static void __cpuidle_driver_init(struct cpuidle_driver *drv)
> >                       s->target_residency = div_u64(s->target_residency_ns, NSEC_PER_USEC);
> >
> >               if (s->exit_latency > 0)
> > -                     s->exit_latency_ns = s->exit_latency * NSEC_PER_USEC;
> > +                     s->exit_latency_ns = mul_u32_u32(s->exit_latency, NSEC_PER_USEC);
>
> Just force either side of the multiply to a 64bit unsigned type.
> The compiler will then DTRT which is likely to be better code than
> whatever mul_u32_u32() generates.

So why is it there?

The default implementation of mul_u32_u32() is to cast its first
argument to u64 before the multiplication AFAICS.

> In any case is the 'exit_latency' ever going to be greater than 4 seconds?
> In which case the 32bit multiply will never overflow.

So this is more of a theoretical thing found by some static analysis
tool or similar.

> >               else if (s->exit_latency_ns < 0)
> >                       s->exit_latency_ns =  0;
> >               else
> > --


From sean at mess.org  Tue Dec 19 08:30:24 2023
From: sean at mess.org (Sean Young)
Date: Tue, 19 Dec 2023 16:30:24 +0000
Subject: [PATCH v10 1/6] pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
In-Reply-To: <cover.1703003288.git.sean@mess.org>
References: <cover.1703003288.git.sean@mess.org>
Message-ID: <b1137f99565ff3d8980fda6e2219c8a06c82129b.1703003288.git.sean@mess.org>

In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:

	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
	int pwm_apply_atomic(struct pwm *, struct pwm_state *);

This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.

Acked-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Acked-by: Guenter Roeck <linux at roeck-us.net>
Acked-by: Mark Brown <broonie at kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov at gmail.com> # for input
Acked-by: Hans de Goede <hdegoede at redhat.com>
Acked-by: Jani Nikula <jani.nikula at intel.com>
Acked-by: Lee Jones <lee at kernel.org>
Signed-off-by: Sean Young <sean at mess.org>
---
 Documentation/driver-api/pwm.rst              |  8 +++---
 MAINTAINERS                                   |  2 +-
 .../gpu/drm/i915/display/intel_backlight.c    |  6 ++--
 drivers/gpu/drm/solomon/ssd130x.c             |  2 +-
 drivers/hwmon/pwm-fan.c                       |  8 +++---
 drivers/input/misc/da7280.c                   |  4 +--
 drivers/input/misc/pwm-beeper.c               |  4 +--
 drivers/input/misc/pwm-vibra.c                |  8 +++---
 drivers/leds/leds-pwm.c                       |  2 +-
 drivers/leds/rgb/leds-pwm-multicolor.c        |  4 +--
 drivers/media/rc/pwm-ir-tx.c                  |  4 +--
 drivers/platform/x86/lenovo-yogabook.c        |  2 +-
 drivers/pwm/core.c                            | 18 ++++++------
 drivers/pwm/pwm-twl-led.c                     |  2 +-
 drivers/pwm/pwm-vt8500.c                      |  2 +-
 drivers/pwm/sysfs.c                           | 10 +++----
 drivers/regulator/pwm-regulator.c             |  4 +--
 drivers/video/backlight/lm3630a_bl.c          |  2 +-
 drivers/video/backlight/lp855x_bl.c           |  2 +-
 drivers/video/backlight/pwm_bl.c              | 12 ++++----
 drivers/video/fbdev/ssd1307fb.c               |  2 +-
 include/linux/pwm.h                           | 28 +++++++++----------
 22 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index bb264490a87a..f1d8197c8c43 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -41,7 +41,7 @@ the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also exist.
 
 After being requested, a PWM has to be configured using::
 
-	int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
+	int pwm_apply_might_sleep(struct pwm_device *pwm, struct pwm_state *state);
 
 This API controls both the PWM period/duty_cycle config and the
 enable/disable state.
@@ -57,13 +57,13 @@ If supported by the driver, the signal can be optimized, for example to improve
 EMI by phase shifting the individual channels of a chip.
 
 The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
-around pwm_apply_state() and should not be used if the user wants to change
+around pwm_apply_might_sleep() and should not be used if the user wants to change
 several parameter at once. For example, if you see pwm_config() and
 pwm_{enable,disable}() calls in the same function, this probably means you
-should switch to pwm_apply_state().
+should switch to pwm_apply_might_sleep().
 
 The PWM user API also allows one to query the PWM state that was passed to the
-last invocation of pwm_apply_state() using pwm_get_state(). Note this is
+last invocation of pwm_apply_might_sleep() using pwm_get_state(). Note this is
 different to what the driver has actually implemented if the request cannot be
 satisfied exactly with the hardware in use. There is currently no way for
 consumers to get the actually implemented settings.
diff --git a/MAINTAINERS b/MAINTAINERS
index 97f51d5ec1cf..c58480595220 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17576,7 +17576,7 @@ F:	drivers/video/backlight/pwm_bl.c
 F:	include/dt-bindings/pwm/
 F:	include/linux/pwm.h
 F:	include/linux/pwm_backlight.h
-K:	pwm_(config|apply_state|ops)
+K:	pwm_(config|apply_might_sleep|ops)
 
 PXA GPIO DRIVER
 M:	Robert Jarzmik <robert.jarzmik at free.fr>
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c b/drivers/gpu/drm/i915/display/intel_backlight.c
index 2e8f17c04522..ff9b9918b0a1 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -274,7 +274,7 @@ static void ext_pwm_set_backlight(const struct drm_connector_state *conn_state,
 	struct intel_panel *panel = &to_intel_connector(conn_state->connector)->panel;
 
 	pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 static void
@@ -427,7 +427,7 @@ static void ext_pwm_disable_backlight(const struct drm_connector_state *old_conn
 	intel_backlight_set_pwm_level(old_conn_state, level);
 
 	panel->backlight.pwm_state.enabled = false;
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 void intel_backlight_disable(const struct drm_connector_state *old_conn_state)
@@ -749,7 +749,7 @@ static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
 
 	pwm_set_relative_duty_cycle(&panel->backlight.pwm_state, level, 100);
 	panel->backlight.pwm_state.enabled = true;
-	pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+	pwm_apply_might_sleep(panel->backlight.pwm, &panel->backlight.pwm_state);
 }
 
 static void __intel_backlight_enable(const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c
index e0174f82e353..cce043a4a1dc 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -319,7 +319,7 @@ static int ssd130x_pwm_enable(struct ssd130x_device *ssd130x)
 
 	pwm_init_state(ssd130x->pwm, &pwmstate);
 	pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
-	pwm_apply_state(ssd130x->pwm, &pwmstate);
+	pwm_apply_might_sleep(ssd130x->pwm, &pwmstate);
 
 	/* Enable the PWM */
 	pwm_enable(ssd130x->pwm);
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 6e4516c2ab89..b67bc9e833c0 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -151,7 +151,7 @@ static int pwm_fan_power_on(struct pwm_fan_ctx *ctx)
 	}
 
 	state->enabled = true;
-	ret = pwm_apply_state(ctx->pwm, state);
+	ret = pwm_apply_might_sleep(ctx->pwm, state);
 	if (ret) {
 		dev_err(ctx->dev, "failed to enable PWM\n");
 		goto disable_regulator;
@@ -181,7 +181,7 @@ static int pwm_fan_power_off(struct pwm_fan_ctx *ctx)
 
 	state->enabled = false;
 	state->duty_cycle = 0;
-	ret = pwm_apply_state(ctx->pwm, state);
+	ret = pwm_apply_might_sleep(ctx->pwm, state);
 	if (ret) {
 		dev_err(ctx->dev, "failed to disable PWM\n");
 		return ret;
@@ -207,7 +207,7 @@ static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
 
 		period = state->period;
 		state->duty_cycle = DIV_ROUND_UP(pwm * (period - 1), MAX_PWM);
-		ret = pwm_apply_state(ctx->pwm, state);
+		ret = pwm_apply_might_sleep(ctx->pwm, state);
 		if (ret)
 			return ret;
 		ret = pwm_fan_power_on(ctx);
@@ -278,7 +278,7 @@ static int pwm_fan_update_enable(struct pwm_fan_ctx *ctx, long val)
 						    state,
 						    &enable_regulator);
 
-			pwm_apply_state(ctx->pwm, state);
+			pwm_apply_might_sleep(ctx->pwm, state);
 			pwm_fan_switch_power(ctx, enable_regulator);
 			pwm_fan_update_state(ctx, 0);
 		}
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
index ce82548916bb..c1fa75c0f970 100644
--- a/drivers/input/misc/da7280.c
+++ b/drivers/input/misc/da7280.c
@@ -352,7 +352,7 @@ static int da7280_haptic_set_pwm(struct da7280_haptic *haptics, bool enabled)
 		state.duty_cycle = period_mag_multi;
 	}
 
-	error = pwm_apply_state(haptics->pwm_dev, &state);
+	error = pwm_apply_might_sleep(haptics->pwm_dev, &state);
 	if (error)
 		dev_err(haptics->dev, "Failed to apply pwm state: %d\n", error);
 
@@ -1175,7 +1175,7 @@ static int da7280_probe(struct i2c_client *client)
 		/* Sync up PWM state and ensure it is off. */
 		pwm_init_state(haptics->pwm_dev, &state);
 		state.enabled = false;
-		error = pwm_apply_state(haptics->pwm_dev, &state);
+		error = pwm_apply_might_sleep(haptics->pwm_dev, &state);
 		if (error) {
 			dev_err(dev, "Failed to apply PWM state: %d\n", error);
 			return error;
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 1e731d8397c6..5b9aedf4362f 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -39,7 +39,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
 	state.period = period;
 	pwm_set_relative_duty_cycle(&state, 50, 100);
 
-	error = pwm_apply_state(beeper->pwm, &state);
+	error = pwm_apply_might_sleep(beeper->pwm, &state);
 	if (error)
 		return error;
 
@@ -138,7 +138,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
 	/* Sync up PWM state and ensure it is off. */
 	pwm_init_state(beeper->pwm, &state);
 	state.enabled = false;
-	error = pwm_apply_state(beeper->pwm, &state);
+	error = pwm_apply_might_sleep(beeper->pwm, &state);
 	if (error) {
 		dev_err(dev, "failed to apply initial PWM state: %d\n",
 			error);
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index acac79c488aa..3e5ed685ed8f 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -56,7 +56,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 	pwm_set_relative_duty_cycle(&state, vibrator->level, 0xffff);
 	state.enabled = true;
 
-	err = pwm_apply_state(vibrator->pwm, &state);
+	err = pwm_apply_might_sleep(vibrator->pwm, &state);
 	if (err) {
 		dev_err(pdev, "failed to apply pwm state: %d\n", err);
 		return err;
@@ -67,7 +67,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 		state.duty_cycle = vibrator->direction_duty_cycle;
 		state.enabled = true;
 
-		err = pwm_apply_state(vibrator->pwm_dir, &state);
+		err = pwm_apply_might_sleep(vibrator->pwm_dir, &state);
 		if (err) {
 			dev_err(pdev, "failed to apply dir-pwm state: %d\n", err);
 			pwm_disable(vibrator->pwm);
@@ -160,7 +160,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
 	/* Sync up PWM state and ensure it is off. */
 	pwm_init_state(vibrator->pwm, &state);
 	state.enabled = false;
-	err = pwm_apply_state(vibrator->pwm, &state);
+	err = pwm_apply_might_sleep(vibrator->pwm, &state);
 	if (err) {
 		dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 			err);
@@ -174,7 +174,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
 		/* Sync up PWM state and ensure it is off. */
 		pwm_init_state(vibrator->pwm_dir, &state);
 		state.enabled = false;
-		err = pwm_apply_state(vibrator->pwm_dir, &state);
+		err = pwm_apply_might_sleep(vibrator->pwm_dir, &state);
 		if (err) {
 			dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 				err);
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 2b3bf1353b70..4e3936a39d0e 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -54,7 +54,7 @@ static int led_pwm_set(struct led_classdev *led_cdev,
 
 	led_dat->pwmstate.duty_cycle = duty;
 	led_dat->pwmstate.enabled = true;
-	return pwm_apply_state(led_dat->pwm, &led_dat->pwmstate);
+	return pwm_apply_might_sleep(led_dat->pwm, &led_dat->pwmstate);
 }
 
 __attribute__((nonnull))
diff --git a/drivers/leds/rgb/leds-pwm-multicolor.c b/drivers/leds/rgb/leds-pwm-multicolor.c
index 46cd062b8b24..e1a81e0109e8 100644
--- a/drivers/leds/rgb/leds-pwm-multicolor.c
+++ b/drivers/leds/rgb/leds-pwm-multicolor.c
@@ -51,8 +51,8 @@ static int led_pwm_mc_set(struct led_classdev *cdev,
 
 		priv->leds[i].state.duty_cycle = duty;
 		priv->leds[i].state.enabled = duty > 0;
-		ret = pwm_apply_state(priv->leds[i].pwm,
-				      &priv->leds[i].state);
+		ret = pwm_apply_might_sleep(priv->leds[i].pwm,
+					    &priv->leds[i].state);
 		if (ret)
 			break;
 	}
diff --git a/drivers/media/rc/pwm-ir-tx.c b/drivers/media/rc/pwm-ir-tx.c
index c5f37c03af9c..cf51e2760975 100644
--- a/drivers/media/rc/pwm-ir-tx.c
+++ b/drivers/media/rc/pwm-ir-tx.c
@@ -68,7 +68,7 @@ static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
 
 	for (i = 0; i < count; i++) {
 		state.enabled = !(i % 2);
-		pwm_apply_state(pwm, &state);
+		pwm_apply_might_sleep(pwm, &state);
 
 		edge = ktime_add_us(edge, txbuf[i]);
 		delta = ktime_us_delta(edge, ktime_get());
@@ -77,7 +77,7 @@ static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
 	}
 
 	state.enabled = false;
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 
 	return count;
 }
diff --git a/drivers/platform/x86/lenovo-yogabook.c b/drivers/platform/x86/lenovo-yogabook.c
index b8d0239192cb..fd62bf746ebd 100644
--- a/drivers/platform/x86/lenovo-yogabook.c
+++ b/drivers/platform/x86/lenovo-yogabook.c
@@ -435,7 +435,7 @@ static int yogabook_pdev_set_kbd_backlight(struct yogabook_data *data, u8 level)
 		.enabled = level,
 	};
 
-	pwm_apply_state(data->kbd_bl_pwm, &state);
+	pwm_apply_might_sleep(data->kbd_bl_pwm, &state);
 	gpiod_set_value(data->kbd_bl_led_enable, level ? 1 : 0);
 	return 0;
 }
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f60b715abe62..c2d78136625d 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -326,8 +326,8 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
 }
 EXPORT_SYMBOL_GPL(pwm_request_from_chip);
 
-static void pwm_apply_state_debug(struct pwm_device *pwm,
-				  const struct pwm_state *state)
+static void pwm_apply_debug(struct pwm_device *pwm,
+			    const struct pwm_state *state)
 {
 	struct pwm_state *last = &pwm->last;
 	struct pwm_chip *chip = pwm->chip;
@@ -433,11 +433,11 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
 }
 
 /**
- * pwm_apply_state() - atomically apply a new state to a PWM device
+ * pwm_apply_might_sleep() - atomically apply a new state to a PWM device
  * @pwm: PWM device
  * @state: new state to apply
  */
-int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
+int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state)
 {
 	struct pwm_chip *chip;
 	int err;
@@ -445,7 +445,7 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	/*
 	 * Some lowlevel driver's implementations of .apply() make use of
 	 * mutexes, also with some drivers only returning when the new
-	 * configuration is active calling pwm_apply_state() from atomic context
+	 * configuration is active calling pwm_apply_might_sleep() from atomic context
 	 * is a bad idea. So make it explicit that calling this function might
 	 * sleep.
 	 */
@@ -475,11 +475,11 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
 	 * only do this after pwm->state was applied as some
 	 * implementations of .get_state depend on this
 	 */
-	pwm_apply_state_debug(pwm, state);
+	pwm_apply_debug(pwm, state);
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(pwm_apply_state);
+EXPORT_SYMBOL_GPL(pwm_apply_might_sleep);
 
 /**
  * pwm_capture() - capture and report a PWM signal
@@ -537,7 +537,7 @@ int pwm_adjust_config(struct pwm_device *pwm)
 		state.period = pargs.period;
 		state.polarity = pargs.polarity;
 
-		return pwm_apply_state(pwm, &state);
+		return pwm_apply_might_sleep(pwm, &state);
 	}
 
 	/*
@@ -560,7 +560,7 @@ int pwm_adjust_config(struct pwm_device *pwm)
 		state.duty_cycle = state.period - state.duty_cycle;
 	}
 
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 EXPORT_SYMBOL_GPL(pwm_adjust_config);
 
diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
index 8a870d0db3c6..c670ccb81653 100644
--- a/drivers/pwm/pwm-twl-led.c
+++ b/drivers/pwm/pwm-twl-led.c
@@ -172,7 +172,7 @@ static int twl4030_pwmled_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * We cannot skip calling ->config even if state->period ==
 	 * pwm->state.period && state->duty_cycle == pwm->state.duty_cycle
 	 * because we might have exited early in the last call to
-	 * pwm_apply_state because of !state->enabled and so the two values in
+	 * pwm_apply_might_sleep because of !state->enabled and so the two values in
 	 * pwm->state might not be configured in hardware.
 	 */
 	ret = twl4030_pwmled_config(chip, pwm,
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index bdea60389487..7bfeacee05d0 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -206,7 +206,7 @@ static int vt8500_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * We cannot skip calling ->config even if state->period ==
 	 * pwm->state.period && state->duty_cycle == pwm->state.duty_cycle
 	 * because we might have exited early in the last call to
-	 * pwm_apply_state because of !state->enabled and so the two values in
+	 * pwm_apply_might_sleep because of !state->enabled and so the two values in
 	 * pwm->state might not be configured in hardware.
 	 */
 	err = vt8500_pwm_config(chip, pwm, state->duty_cycle, state->period);
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 4edb994fa2e1..1698609d91c8 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -62,7 +62,7 @@ static ssize_t period_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.period = val;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -97,7 +97,7 @@ static ssize_t duty_cycle_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.duty_cycle = val;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -144,7 +144,7 @@ static ssize_t enable_store(struct device *child,
 		goto unlock;
 	}
 
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 
 unlock:
 	mutex_unlock(&export->lock);
@@ -194,7 +194,7 @@ static ssize_t polarity_store(struct device *child,
 	mutex_lock(&export->lock);
 	pwm_get_state(pwm, &state);
 	state.polarity = polarity;
-	ret = pwm_apply_state(pwm, &state);
+	ret = pwm_apply_might_sleep(pwm, &state);
 	mutex_unlock(&export->lock);
 
 	return ret ? : size;
@@ -401,7 +401,7 @@ static int pwm_class_apply_state(struct pwm_export *export,
 				 struct pwm_device *pwm,
 				 struct pwm_state *state)
 {
-	int ret = pwm_apply_state(pwm, state);
+	int ret = pwm_apply_might_sleep(pwm, state);
 
 	/* release lock taken in pwm_class_get_state */
 	mutex_unlock(&export->lock);
diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
index 2aff6db748e2..698c420e0869 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -90,7 +90,7 @@ static int pwm_regulator_set_voltage_sel(struct regulator_dev *rdev,
 	pwm_set_relative_duty_cycle(&pstate,
 			drvdata->duty_cycle_table[selector].dutycycle, 100);
 
-	ret = pwm_apply_state(drvdata->pwm, &pstate);
+	ret = pwm_apply_might_sleep(drvdata->pwm, &pstate);
 	if (ret) {
 		dev_err(&rdev->dev, "Failed to configure PWM: %d\n", ret);
 		return ret;
@@ -216,7 +216,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
 
 	pwm_set_relative_duty_cycle(&pstate, dutycycle, duty_unit);
 
-	ret = pwm_apply_state(drvdata->pwm, &pstate);
+	ret = pwm_apply_might_sleep(drvdata->pwm, &pstate);
 	if (ret) {
 		dev_err(&rdev->dev, "Failed to configure PWM: %d\n", ret);
 		return ret;
diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
index 8fcb62be597b..a3412c936ca2 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -180,7 +180,7 @@ static int lm3630a_pwm_ctrl(struct lm3630a_chip *pchip, int br, int br_max)
 
 	pchip->pwmd_state.enabled = pchip->pwmd_state.duty_cycle ? true : false;
 
-	return pwm_apply_state(pchip->pwmd, &pchip->pwmd_state);
+	return pwm_apply_might_sleep(pchip->pwmd, &pchip->pwmd_state);
 }
 
 /* update and get brightness */
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
index da1f124db69c..7075bfab59c4 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -234,7 +234,7 @@ static int lp855x_pwm_ctrl(struct lp855x *lp, int br, int max_br)
 	state.duty_cycle = div_u64(br * state.period, max_br);
 	state.enabled = state.duty_cycle;
 
-	return pwm_apply_state(lp->pwm, &state);
+	return pwm_apply_might_sleep(lp->pwm, &state);
 }
 
 static int lp855x_bl_update_status(struct backlight_device *bl)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 289bd9ce4d36..35c716e9043c 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -103,7 +103,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		pwm_get_state(pb->pwm, &state);
 		state.duty_cycle = compute_duty_cycle(pb, brightness, &state);
 		state.enabled = true;
-		pwm_apply_state(pb->pwm, &state);
+		pwm_apply_might_sleep(pb->pwm, &state);
 
 		pwm_backlight_power_on(pb);
 	} else {
@@ -120,7 +120,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		 * inactive output.
 		 */
 		state.enabled = !pb->power_supply && !pb->enable_gpio;
-		pwm_apply_state(pb->pwm, &state);
+		pwm_apply_might_sleep(pb->pwm, &state);
 	}
 
 	if (pb->notify_after)
@@ -528,7 +528,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 	if (!state.period && (data->pwm_period_ns > 0))
 		state.period = data->pwm_period_ns;
 
-	ret = pwm_apply_state(pb->pwm, &state);
+	ret = pwm_apply_might_sleep(pb->pwm, &state);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
 			ret);
@@ -633,7 +633,7 @@ static void pwm_backlight_remove(struct platform_device *pdev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 
 	if (pb->exit)
 		pb->exit(&pdev->dev);
@@ -649,7 +649,7 @@ static void pwm_backlight_shutdown(struct platform_device *pdev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -673,7 +673,7 @@ static int pwm_backlight_suspend(struct device *dev)
 	pwm_get_state(pb->pwm, &state);
 	state.duty_cycle = 0;
 	state.enabled = false;
-	pwm_apply_state(pb->pwm, &state);
+	pwm_apply_might_sleep(pb->pwm, &state);
 
 	if (pb->notify_after)
 		pb->notify_after(pb->dev, 0);
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 5ae48e36fccb..1a4f90ea7d5a 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -347,7 +347,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
 
 		pwm_init_state(par->pwm, &pwmstate);
 		pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
-		pwm_apply_state(par->pwm, &pwmstate);
+		pwm_apply_might_sleep(par->pwm, &pwmstate);
 
 		/* Enable the PWM */
 		pwm_enable(par->pwm);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index f87655c06c82..b64b8a82415c 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -92,8 +92,8 @@ struct pwm_device {
  * @state: state to fill with the current PWM state
  *
  * The returned PWM state represents the state that was applied by a previous call to
- * pwm_apply_state(). Drivers may have to slightly tweak that state before programming it to
- * hardware. If pwm_apply_state() was never called, this returns either the current hardware
+ * pwm_apply_might_sleep(). Drivers may have to slightly tweak that state before programming it to
+ * hardware. If pwm_apply_might_sleep() was never called, this returns either the current hardware
  * state (if supported) or the default settings.
  */
 static inline void pwm_get_state(const struct pwm_device *pwm,
@@ -157,20 +157,20 @@ static inline void pwm_get_args(const struct pwm_device *pwm,
 }
 
 /**
- * pwm_init_state() - prepare a new state to be applied with pwm_apply_state()
+ * pwm_init_state() - prepare a new state to be applied with pwm_apply_might_sleep()
  * @pwm: PWM device
  * @state: state to fill with the prepared PWM state
  *
  * This functions prepares a state that can later be tweaked and applied
- * to the PWM device with pwm_apply_state(). This is a convenient function
+ * to the PWM device with pwm_apply_might_sleep(). This is a convenient function
  * that first retrieves the current PWM state and the replaces the period
  * and polarity fields with the reference values defined in pwm->args.
  * Once the function returns, you can adjust the ->enabled and ->duty_cycle
- * fields according to your needs before calling pwm_apply_state().
+ * fields according to your needs before calling pwm_apply_might_sleep().
  *
  * ->duty_cycle is initially set to zero to avoid cases where the current
  * ->duty_cycle value exceed the pwm_args->period one, which would trigger
- * an error if the user calls pwm_apply_state() without adjusting ->duty_cycle
+ * an error if the user calls pwm_apply_might_sleep() without adjusting ->duty_cycle
  * first.
  */
 static inline void pwm_init_state(const struct pwm_device *pwm,
@@ -226,7 +226,7 @@ pwm_get_relative_duty_cycle(const struct pwm_state *state, unsigned int scale)
  *
  * pwm_init_state(pwm, &state);
  * pwm_set_relative_duty_cycle(&state, 50, 100);
- * pwm_apply_state(pwm, &state);
+ * pwm_apply_might_sleep(pwm, &state);
  *
  * This functions returns -EINVAL if @duty_cycle and/or @scale are
  * inconsistent (@scale == 0 or @duty_cycle > @scale).
@@ -304,7 +304,7 @@ struct pwm_chip {
 
 #if IS_ENABLED(CONFIG_PWM)
 /* PWM user APIs */
-int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state);
+int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state);
 int pwm_adjust_config(struct pwm_device *pwm);
 
 /**
@@ -332,7 +332,7 @@ static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
 
 	state.duty_cycle = duty_ns;
 	state.period = period_ns;
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 
 /**
@@ -353,7 +353,7 @@ static inline int pwm_enable(struct pwm_device *pwm)
 		return 0;
 
 	state.enabled = true;
-	return pwm_apply_state(pwm, &state);
+	return pwm_apply_might_sleep(pwm, &state);
 }
 
 /**
@@ -372,7 +372,7 @@ static inline void pwm_disable(struct pwm_device *pwm)
 		return;
 
 	state.enabled = false;
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 }
 
 /* PWM provider APIs */
@@ -403,8 +403,8 @@ struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
 				       struct fwnode_handle *fwnode,
 				       const char *con_id);
 #else
-static inline int pwm_apply_state(struct pwm_device *pwm,
-				  const struct pwm_state *state)
+static inline int pwm_apply_might_sleep(struct pwm_device *pwm,
+					const struct pwm_state *state)
 {
 	might_sleep();
 	return -ENOTSUPP;
@@ -521,7 +521,7 @@ static inline void pwm_apply_args(struct pwm_device *pwm)
 	state.period = pwm->args.period;
 	state.usage_power = false;
 
-	pwm_apply_state(pwm, &state);
+	pwm_apply_might_sleep(pwm, &state);
 }
 
 struct pwm_lookup {
-- 
2.43.0



From sean at mess.org  Tue Dec 19 08:30:28 2023
From: sean at mess.org (Sean Young)
Date: Tue, 19 Dec 2023 16:30:28 +0000
Subject: [PATCH v10 5/6] pwm: bcm2835: Allow PWM driver to be used in atomic context
In-Reply-To: <cover.1703003288.git.sean@mess.org>
References: <cover.1703003288.git.sean@mess.org>
Message-ID: <6c5852c902e6603571e4fde5955d1aeb537059ba.1703003288.git.sean@mess.org>

clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
rate changes using clk_rate_exclusive_get().

Signed-off-by: Sean Young <sean at mess.org>
Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
---
 drivers/pwm/pwm-bcm2835.c | 34 +++++++++++++++++++++++++---------
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index ab30667f4f95..d9ac50a5b04e 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -28,6 +28,7 @@ struct bcm2835_pwm {
 	struct device *dev;
 	void __iomem *base;
 	struct clk *clk;
+	unsigned long rate;
 };
 
 static inline struct bcm2835_pwm *to_bcm2835_pwm(struct pwm_chip *chip)
@@ -63,17 +64,11 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 {
 
 	struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
-	unsigned long rate = clk_get_rate(pc->clk);
 	unsigned long long period_cycles;
 	u64 max_period;
 
 	u32 val;
 
-	if (!rate) {
-		dev_err(pc->dev, "failed to get clock rate\n");
-		return -EINVAL;
-	}
-
 	/*
 	 * period_cycles must be a 32 bit value, so period * rate / NSEC_PER_SEC
 	 * must be <= U32_MAX. As U32_MAX * NSEC_PER_SEC < U64_MAX the
@@ -88,13 +83,13 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * <=> period < ((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate
 	 * <=> period <= ceil((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate) - 1
 	 */
-	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, rate) - 1;
+	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, pc->rate) - 1;
 
 	if (state->period > max_period)
 		return -EINVAL;
 
 	/* set period */
-	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * rate, NSEC_PER_SEC);
+	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * pc->rate, NSEC_PER_SEC);
 
 	/* don't accept a period that is too small */
 	if (period_cycles < PERIOD_MIN)
@@ -103,7 +98,7 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	writel(period_cycles, pc->base + PERIOD(pwm->hwpwm));
 
 	/* set duty cycle */
-	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * rate, NSEC_PER_SEC);
+	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * pc->rate, NSEC_PER_SEC);
 	writel(val, pc->base + DUTY(pwm->hwpwm));
 
 	/* set polarity */
@@ -131,6 +126,13 @@ static const struct pwm_ops bcm2835_pwm_ops = {
 	.apply = bcm2835_pwm_apply,
 };
 
+static void devm_clk_rate_exclusive_put(void *data)
+{
+	struct clk *clk = data;
+
+	clk_rate_exclusive_put(clk);
+}
+
 static int bcm2835_pwm_probe(struct platform_device *pdev)
 {
 	struct bcm2835_pwm *pc;
@@ -151,8 +153,22 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
 				     "clock not found\n");
 
+	ret = clk_rate_exclusive_get(pc->clk);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret,
+				     "fail to get exclusive rate\n");
+
+	devm_add_action_or_reset(&pdev->dev, devm_clk_rate_exclusive_put,
+				 pc->clk);
+
+	pc->rate = clk_get_rate(pc->clk);
+	if (!pc->rate)
+		return dev_err_probe(&pdev->dev, -EINVAL,
+				     "failed to get clock rate\n");
+
 	pc->chip.dev = &pdev->dev;
 	pc->chip.ops = &bcm2835_pwm_ops;
+	pc->chip.atomic = true;
 	pc->chip.npwm = 2;
 
 	platform_set_drvdata(pdev, pc);
-- 
2.43.0



From conor at kernel.org  Tue Dec 19 08:39:40 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 19 Dec 2023 16:39:40 +0000
Subject: [PATCH 2/6] dt-bindings: spi: stm32: add st,stm32mp25-spi
 compatible
In-Reply-To: <20231218155721.359198-3-alain.volmat@foss.st.com>
References: <20231218155721.359198-1-alain.volmat@foss.st.com>
 <20231218155721.359198-3-alain.volmat@foss.st.com>
Message-ID: <20231219-subwoofer-aversion-385ee53dc6be@spud>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/34f53945/attachment.sig>

From conor at kernel.org  Tue Dec 19 08:40:15 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 19 Dec 2023 16:40:15 +0000
Subject: [PATCH 1/2] dt-bindings: arm64: add Marvell 7k COMe boards
In-Reply-To: <20231218154431.3789032-2-enachman@marvell.com>
References: <20231218154431.3789032-1-enachman@marvell.com>
 <20231218154431.3789032-2-enachman@marvell.com>
Message-ID: <20231219-briskness-proving-374376a874c3@spud>

On Mon, Dec 18, 2023 at 05:44:30PM +0200, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> Add dt bindings for:
> Armada 7020 COM Express CPU module
> Falcon DB-98CX85x0 COM Express type 7 Carrier board
> Falcon DB-98CX85x0 COM Express type 7 Carrier board
> with an Armada 7020 COM Express CPU module
> 
> Signed-off-by: Elad Nachman <enachman at marvell.com>

Acked-by: Conor Dooley <conor.dooley at microchip.com>

Cheers,
Conor.

> ---
>  .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> index 52d78521e412..24d8031a533d 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> @@ -21,6 +21,17 @@ properties:
>            - const: marvell,armada-ap806-dual
>            - const: marvell,armada-ap806
>  
> +      - description:
> +          Falcon (DB-98CX85x0) Development board COM Express Carrier plus
> +          Armada 7020 SoC COM Express CPU module
> +        items:
> +          - const: marvell,armada7020-falcon-carrier
> +          - const: marvell,db-falcon-carrier
> +          - const: marvell,armada7020-cpu-module
> +          - const: marvell,armada7020
> +          - const: marvell,armada-ap806-dual
> +          - const: marvell,armada-ap806
> +
>        - description: Armada 7040 SoC
>          items:
>            - const: marvell,armada7040
> -- 
> 2.25.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/79dd8328/attachment.sig>

From jernej.skrabec at gmail.com  Tue Dec 19 08:46:08 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Tue, 19 Dec 2023 17:46:08 +0100
Subject: [PATCH 1/5] clk: sunxi-ng: nkm: Support constraints on m/n ratio and
 parent rate
In-Reply-To: <20231218-pinephone-pll-fixes-v1-1-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-1-e238b6ed6dc1@oltmanns.dev>
Message-ID: <5736273.DvuYhMxLoT@jernej-laptop>

Hi Frank!

Dne ponedeljek, 18. december 2023 ob 14:35:19 CET je Frank Oltmanns napisal(a):
> The Allwinner A64 manual lists the following constraints for the
> PLL-MIPI clock:
>  - M/N >= 3

This should be "<="

>  - (PLL_VIDEO0)/M >= 24MHz
> 
> The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
> these constraints.
> 
> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> ---
>  drivers/clk/sunxi-ng/ccu_nkm.c | 23 +++++++++++++++++++++++
>  drivers/clk/sunxi-ng/ccu_nkm.h |  8 ++++++++
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> index eed64547ad42..2af5c1ebd527 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> @@ -16,6 +16,20 @@ struct _ccu_nkm {
>  	unsigned long	m, min_m, max_m;
>  };
>  
> +static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long parent,
> +				  unsigned long n, unsigned long m)
> +{
> +	struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
> +
> +	if (nkm->max_mn_ratio && (m > nkm->max_mn_ratio * n))
> +		return false;
> +
> +	if (nkm->parent_wo_nk && (parent < nkm->parent_wo_nk * m))
> +		return false;
> +
> +	return true;
> +}
> +
>  static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common,
>  						       struct clk_hw *parent_hw,
>  						       unsigned long *parent, unsigned long rate,
> @@ -32,6 +46,9 @@ static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
>  
>  				tmp_parent = clk_hw_round_rate(parent_hw, rate * _m / (_n * _k));
>  
> +				if (!ccu_nkm_is_valid_rate(common, tmp_parent, _n, _m))
> +					continue;
> +
>  				tmp_rate = tmp_parent * _n * _k / _m;
>  
>  				if (ccu_is_better_rate(common, rate, tmp_rate, best_rate) ||
> @@ -65,6 +82,12 @@ static unsigned long ccu_nkm_find_best(unsigned long parent, unsigned long rate,
>  	for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
>  		for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
>  			for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
> +				if ((common->reg == 0x040) && (_m > 3 * _n))
> +					break;
> +
> +				if ((common->reg == 0x040) && (parent < 24000000 * _m))
> +					continue;
> +

You already figured this part.

>  				unsigned long tmp_rate;
>  
>  				tmp_rate = parent * _n * _k / _m;
> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
> index 6601defb3f38..d3d3eaf55faf 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkm.h
> +++ b/drivers/clk/sunxi-ng/ccu_nkm.h
> @@ -16,6 +16,12 @@
>   * struct ccu_nkm - Definition of an N-K-M clock
>   *
>   * Clocks based on the formula parent * N * K / M
> + *
> + * @max_mn_ratio:	Maximum value for M / N.
> + * @parent_wo_nk:	The minimum rate the parent must provide after applying the divisor,
> + *			but without applying the multipliers, i.e. the contstraint
> + *			   (parent rate)/M >= parent_wo_nk
> + *			must be fulfilled.
>   */
>  struct ccu_nkm {
>  	u32			enable;
> @@ -27,6 +33,8 @@ struct ccu_nkm {
>  	struct ccu_mux_internal	mux;
>  
>  	unsigned int		fixed_post_div;
> +	unsigned long		max_mn_ratio;
> +	unsigned long           parent_wo_nk;

What about max_m_n_ratio and max_parent_m_ratio, to be consistent? This
should also allow to simplify description.

Best regards,
Jernej

>  
>  	struct ccu_common	common;
>  };
> 
> 






From jernej.skrabec at gmail.com  Tue Dec 19 08:46:59 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Tue, 19 Dec 2023 17:46:59 +0100
Subject: [PATCH 2/5] clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio
 and parent rate
In-Reply-To: <20231218-pinephone-pll-fixes-v1-2-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-2-e238b6ed6dc1@oltmanns.dev>
Message-ID: <4881920.31r3eYUQgx@jernej-laptop>

Dne ponedeljek, 18. december 2023 ob 14:35:20 CET je Frank Oltmanns napisal(a):
> The Allwinner A64 manual lists the following constraints for the
> PLL-MIPI clock:
>  - M/N >= 3

Same as in previous patch, should be "<=".

Best regards,
Jernej

>  - (PLL_VIDEO0)/M >= 24MHz
> 
> Use these constraints.
> 
> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> ---
>  drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> index 8951ffc14ff5..c034ac027d1c 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> @@ -176,6 +176,8 @@ static struct ccu_nkm pll_mipi_clk = {
>  	.n		= _SUNXI_CCU_MULT(8, 4),
>  	.k		= _SUNXI_CCU_MULT_MIN(4, 2, 2),
>  	.m		= _SUNXI_CCU_DIV(0, 4),
> +	.max_mn_ratio	= 3,
> +	.parent_wo_nk	= 24000000,
>  	.common		= {
>  		.reg		= 0x040,
>  		.hw.init	= CLK_HW_INIT("pll-mipi", "pll-video0",
> 
> 






From tudor.ambarus at linaro.org  Tue Dec 19 08:47:47 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Tue, 19 Dec 2023 16:47:47 +0000
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock
 as critical
In-Reply-To: <CAPLW+4n-S2jaVPUwKTFC_iabnDd_qDV=ZubMqhz-X9XiZzzJow@mail.gmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-8-tudor.ambarus@linaro.org>
 <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>
 <f3d61c49-1a46-476c-b7a5-6cc6a06a33ed@linaro.org>
 <CAPLW+4=tyr8Pcoe6Wm0Wtmkk4udDpuAiOKy7+C+Fwa6mvt3VoQ@mail.gmail.com>
 <5de5cddd-2bab-4408-b31f-f48bef98f14c@linaro.org>
 <CAPLW+4n-S2jaVPUwKTFC_iabnDd_qDV=ZubMqhz-X9XiZzzJow@mail.gmail.com>
Message-ID: <4ba80e1e-8fec-4fd2-9140-6da006c9d5f5@linaro.org>

Hi, Sam!

On 12/14/23 16:43, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 10:15?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>
>>
>>
>> On 12/14/23 16:09, Sam Protsenko wrote:
>>> On Thu, Dec 14, 2023 at 10:01?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 12/14/23 15:37, Sam Protsenko wrote:
>>>>> On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>>>>>
>>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>>>>>> which then makes the system hang. To prevent this, mark
>>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>>>>>> accordingly when tested.
>>>>>>
>>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>>>>>> ---
>>>>>>  drivers/clk/samsung/clk-gs101.c | 2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>>>>>> index 3d194520b05e..08d80fca9cd6 100644
>>>>>> --- a/drivers/clk/samsung/clk-gs101.c
>>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
>>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>>>>>              "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>>>>>              21, 0, 0),
>>>>>>         GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>>>>>> -            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>>>>>> +            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>>>>>
>>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
>>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
>>>>> usually should be avoided. Is it possible that the system freezes
>>>>> because some other clock (which depends on peric0_ip) gets disabled as
>>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
>>>>> is not implemented yet in the clock driver? Just looks weird to me
>>>>> that the system hangs because of CMU IP clock disablement. It's
>>>>> usually something much more specific.
>>>>
>>>> The system hang happened when I tested USI8 in I2C configuration with an
>>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
>>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
>>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
>>>> disablement which makes the system hang. Either marking the CMU_TOP gate
>>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
>>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>>>>
>>>
>>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
>>
>> yes.

I checked again all the clocks. I implemented all but one, the one
defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
don't have any reference on how it should be defined so I won't touch it
yet. But I have some good news too, see below.

> 
> Ok. Are there any other CMUs (perhaps not implemented yet) which
> consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
> clocks derived from it? If so, is there a chance some particular leaf
> clock in those CMUs actually renders the system frozen when disabled
> as a consequence of disabling PERIC0_IP, and would explain better why
> the freeze happens?
> 
> For now I think it's ok to have that CLK_IS_CRITICAL flag here,
> because as you said you implemented all clocks in this CMU and neither
> of those looks like a critical one. But I'd advice to add a TODO
> comment saying it's probably a temporary solution before actual leaf
> clock which leads to freeze is identified (which probably resides in
> some other not implemented yet CMU).
> 
>>
>>> is a chance some other leaf clock (which is not implemented yet in
>>> your driver) gets disabled as a result of PERIC0_IP disablement, which
>>> might actually lead to that hang you observe. Usually it's some
>>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
>>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
>>> and the corresponding comments I left there, maybe it'll give you more
>>> particular idea about what to look for. Yes, making the whole CMU
>>> always running without understanding why (i.e. because of which
>>> particular leaf clock) might not be the best way of handling this
>>
>> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
> 
> That's not a root cause here. And I think PERIC0_IP is neither.
> 

you were right!
>>
>>> issue. I might be mistaken, but at least please check if you
>>> implemented all clocks for PERIC0 first and if making some meaningful
>>> leaf clock critical makes more sense.
>>>

I determined which leaf clocks shall be marked as critical. I enabled
the debugfs clock write access. Then I made sure that the parents of the
PERIC0 CMU have at least one user so that they don't get disabled after
an enable-disable sequence on a leaf clock. The I took all the PERIC0
gate clocks and enabled and disabled them one by one. Whichever hang the
system when the clock was disabled was marked as critical. The list of
critical leaf clocks is as following:

"gout_peric0_peric0_cmu_peric0_pclk",
"gout_peric0_lhm_axi_p_peric0_i_clk",
"gout_peric0_peric0_top1_ipclk_0",
"gout_peric0_peric0_top1_pclk_0".

I'll update v2 with this instead. Thanks for the help, Sam!
Cheers,
ta


From abel.vesa at linaro.org  Tue Dec 19 08:52:20 2023
From: abel.vesa at linaro.org (Abel Vesa)
Date: Tue, 19 Dec 2023 18:52:20 +0200
Subject: [PATCH 1/1] clk: imx: clk-imx8qxp: fix LVDS bypass, pixel and
 phy clocks
In-Reply-To: <20231218122407.2757175-1-alexander.stein@ew.tq-group.com>
References: <20231218122407.2757175-1-alexander.stein@ew.tq-group.com>
Message-ID: <ZYHKRISW1TNR3Ifd@linaro.org>

On 23-12-18 13:24:07, Alexander Stein wrote:
> To be compatibel with SCU firmware based on 1.15 a different clock
> routing for LVDS is needed.
> 

compatible

> Signed-off-by: Oliver F. Brown <oliver.brown at oss.nxp.com>
> Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan at nxp.com>
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

With that:

Reviewed-by: Abel Vesa <abel.vesa at linaro.org>

> ---
> This patch originates from the downstream kernel squashing patches [1] and [2]
> as suggested by the commit message.
> I adjusted the commit so that the name stays the same as before.
> 
> I am somewhat unsure about the From: tag, as both commits have different
> authors.
> 
> Best regards,
> Alexander
> 
> [1] https://github.com/Freescale/linux-fslc/commit/05b5fd0eebd0
> [2] https://github.com/Freescale/linux-fslc/commit/0a202c564e5f
>  drivers/clk/imx/clk-imx8qxp.c | 24 ++++++++++++++++++++----
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
> index 41f0a45aa162..7d8883916cac 100644
> --- a/drivers/clk/imx/clk-imx8qxp.c
> +++ b/drivers/clk/imx/clk-imx8qxp.c
> @@ -66,6 +66,22 @@ static const char * const lcd_pxl_sels[] = {
>  	"lcd_pxl_bypass_div_clk",
>  };
>  
> +static const char *const lvds0_sels[] = {
> +	"clk_dummy",
> +	"clk_dummy",
> +	"clk_dummy",
> +	"clk_dummy",
> +	"mipi0_lvds_bypass_clk",
> +};
> +
> +static const char *const lvds1_sels[] = {
> +	"clk_dummy",
> +	"clk_dummy",
> +	"clk_dummy",
> +	"clk_dummy",
> +	"mipi1_lvds_bypass_clk",
> +};
> +
>  static const char * const mipi_sels[] = {
>  	"clk_dummy",
>  	"clk_dummy",
> @@ -207,9 +223,9 @@ static int imx8qxp_clk_probe(struct platform_device *pdev)
>  	/* MIPI-LVDS SS */
>  	imx_clk_scu("mipi0_bypass_clk", IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_BYPASS);
>  	imx_clk_scu("mipi0_pixel_clk", IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_PER);
> -	imx_clk_scu("mipi0_lvds_pixel_clk", IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC2);
>  	imx_clk_scu("mipi0_lvds_bypass_clk", IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_BYPASS);
> -	imx_clk_scu("mipi0_lvds_phy_clk", IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC3);
> +	imx_clk_scu2("mipi0_lvds_pixel_clk", lvds0_sels, ARRAY_SIZE(lvds0_sels), IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC2);
> +	imx_clk_scu2("mipi0_lvds_phy_clk", lvds0_sels, ARRAY_SIZE(lvds0_sels), IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC3);
>  	imx_clk_scu2("mipi0_dsi_tx_esc_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_MST_BUS);
>  	imx_clk_scu2("mipi0_dsi_rx_esc_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_SLV_BUS);
>  	imx_clk_scu2("mipi0_dsi_phy_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_0, IMX_SC_PM_CLK_PHY);
> @@ -219,9 +235,9 @@ static int imx8qxp_clk_probe(struct platform_device *pdev)
>  
>  	imx_clk_scu("mipi1_bypass_clk", IMX_SC_R_MIPI_1, IMX_SC_PM_CLK_BYPASS);
>  	imx_clk_scu("mipi1_pixel_clk", IMX_SC_R_MIPI_1, IMX_SC_PM_CLK_PER);
> -	imx_clk_scu("mipi1_lvds_pixel_clk", IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC2);
>  	imx_clk_scu("mipi1_lvds_bypass_clk", IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_BYPASS);
> -	imx_clk_scu("mipi1_lvds_phy_clk", IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC3);
> +	imx_clk_scu2("mipi1_lvds_pixel_clk", lvds1_sels, ARRAY_SIZE(lvds1_sels), IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC2);
> +	imx_clk_scu2("mipi1_lvds_phy_clk", lvds1_sels, ARRAY_SIZE(lvds1_sels), IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC3);
>  
>  	imx_clk_scu2("mipi1_dsi_tx_esc_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_1, IMX_SC_PM_CLK_MST_BUS);
>  	imx_clk_scu2("mipi1_dsi_rx_esc_clk", mipi_sels, ARRAY_SIZE(mipi_sels), IMX_SC_R_MIPI_1, IMX_SC_PM_CLK_SLV_BUS);
> -- 
> 2.34.1
> 


From jernej.skrabec at gmail.com  Tue Dec 19 08:52:40 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Tue, 19 Dec 2023 17:52:40 +0100
Subject: [PATCH 3/5] clk: sunxi-ng: nm: Support constraints on n/m ratio and
 parent rate
In-Reply-To: <20231218-pinephone-pll-fixes-v1-3-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-3-e238b6ed6dc1@oltmanns.dev>
Message-ID: <1871631.tdWV9SEqCh@jernej-laptop>

Dne ponedeljek, 18. december 2023 ob 14:35:21 CET je Frank Oltmanns napisal(a):
> The Allwinner A64 manual lists the following constraint for the
> PLL-VIDEO0 clock: 8 <= N/M <= 25
> 
> The PLL-MIPI clock is implemented as ccu_nm. Therefore, add support for
> this constraint.
> 
> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> ---
>  drivers/clk/sunxi-ng/ccu_nm.c | 21 +++++++++++++++++++--
>  drivers/clk/sunxi-ng/ccu_nm.h | 34 ++++++++++++++++++++++++++++++++--
>  2 files changed, 51 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
> index ffac3deb89d6..cfc6981e398b 100644
> --- a/drivers/clk/sunxi-ng/ccu_nm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nm.c
> @@ -27,6 +27,19 @@ static unsigned long ccu_nm_calc_rate(unsigned long parent,
>  	return rate;
>  }
>  
> +static bool ccu_nm_is_valid_rate(struct ccu_common *common, unsigned long n, unsigned long m)
> +{
> +	struct ccu_nm *nm = container_of(common, struct ccu_nm, common);
> +
> +	if (nm->max_nm_ratio && (n > nm->max_nm_ratio * m))
> +		return false;
> +
> +	if (nm->min_nm_ratio && (n < nm->min_nm_ratio * m))
> +		return false;
> +
> +	return true;
> +}
> +
>  static unsigned long ccu_nm_find_best(struct ccu_common *common, unsigned long parent,
>  				      unsigned long rate, struct _ccu_nm *nm)
>  {
> @@ -36,8 +49,12 @@ static unsigned long ccu_nm_find_best(struct ccu_common *common, unsigned long p
>  
>  	for (_n = nm->min_n; _n <= nm->max_n; _n++) {
>  		for (_m = nm->min_m; _m <= nm->max_m; _m++) {
> -			unsigned long tmp_rate = ccu_nm_calc_rate(parent,
> -								  _n, _m);
> +			unsigned long tmp_rate;
> +
> +			if (!ccu_nm_is_valid_rate(common, _n, _m))
> +				continue;
> +
> +			tmp_rate = ccu_nm_calc_rate(parent, _n, _m);
>  
>  			if (ccu_is_better_rate(common, rate, tmp_rate, best_rate)) {
>  				best_rate = tmp_rate;
> diff --git a/drivers/clk/sunxi-ng/ccu_nm.h b/drivers/clk/sunxi-ng/ccu_nm.h
> index 93c11693574f..0075df6d9697 100644
> --- a/drivers/clk/sunxi-ng/ccu_nm.h
> +++ b/drivers/clk/sunxi-ng/ccu_nm.h
> @@ -31,6 +31,8 @@ struct ccu_nm {
>  	unsigned int		fixed_post_div;
>  	unsigned int		min_rate;
>  	unsigned int		max_rate;
> +	unsigned long		min_nm_ratio; /* minimum value for m/n */
> +	unsigned long		max_nm_ratio; /* maximum value for m/n */

Comment is wrong, it should be "n/m". For consistency with nkm patch,
min_n_m_ratio and max_n_m_ratio.

Best regards,
Jernej

>  
>  	struct ccu_common	common;
>  };
> @@ -108,7 +110,8 @@ struct ccu_nm {
>  		},							\
>  	}
>  
> -#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT(_struct, _name,	\
> +#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(		\
> +						 _struct, _name,	\
>  						 _parent, _reg,		\
>  						 _min_rate, _max_rate,	\
>  						 _nshift, _nwidth,	\
> @@ -117,7 +120,9 @@ struct ccu_nm {
>  						 _frac_rate_0,		\
>  						 _frac_rate_1,		\
>  						 _gate, _lock, _flags,	\
> -						 _features)		\
> +						 _features,		\
> +						 _min_nm_ratio,		\
> +						 _max_nm_ratio)		\
>  	struct ccu_nm _struct = {					\
>  		.enable		= _gate,				\
>  		.lock		= _lock,				\
> @@ -128,6 +133,8 @@ struct ccu_nm {
>  						  _frac_rate_1),	\
>  		.min_rate	= _min_rate,				\
>  		.max_rate	= _max_rate,				\
> +		.min_nm_ratio	= _min_nm_ratio,			\
> +		.max_nm_ratio	= _max_nm_ratio,			\
>  		.common		= {					\
>  			.reg		= _reg,				\
>  			.features	= _features,			\
> @@ -138,6 +145,29 @@ struct ccu_nm {
>  		},							\
>  	}
>  
> +#define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT(_struct, _name,	\
> +						 _parent, _reg,		\
> +						 _min_rate, _max_rate,	\
> +						 _nshift, _nwidth,	\
> +						 _mshift, _mwidth,	\
> +						 _frac_en, _frac_sel,	\
> +						 _frac_rate_0,		\
> +						 _frac_rate_1,		\
> +						 _gate, _lock, _flags,	\
> +						 _features)		\
> +	SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(		\
> +						_struct, _name,		\
> +						_parent, _reg,		\
> +						_min_rate, _max_rate,	\
> +						_nshift, _nwidth,	\
> +						_mshift, _mwidth,	\
> +						_frac_en, _frac_sel,	\
> +						_frac_rate_0,		\
> +						_frac_rate_1,		\
> +						_gate, _lock, _flags,	\
> +						_features,		\
> +						0, 0)
> +
>  #define SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX(_struct, _name,	\
>  						 _parent, _reg,		\
>  						 _min_rate, _max_rate,	\
> 
> 






From jernej.skrabec at gmail.com  Tue Dec 19 08:54:19 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Tue, 19 Dec 2023 17:54:19 +0100
Subject: [PATCH 4/5] clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's n/m ratio
In-Reply-To: <20231218-pinephone-pll-fixes-v1-4-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-4-e238b6ed6dc1@oltmanns.dev>
Message-ID: <13411739.uLZWGnKmhe@jernej-laptop>

Dne ponedeljek, 18. december 2023 ob 14:35:22 CET je Frank Oltmanns napisal(a):
> The Allwinner A64 manual lists the following constraint for the
> PLL-VIDEO0 clock: 8 <= N/M <= 25
> 
> Use this constraint.
> 
> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> ---
>  drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> index c034ac027d1c..75d839da446c 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> @@ -68,7 +68,8 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
>  				       BIT(28),	/* lock */
>  				       CLK_SET_RATE_UNGATE);
>  
> -static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-video0",
> +static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(pll_video0_clk,
> +						"pll-video0",
>  						"osc24M", 0x010,
>  						192000000,	/* Minimum rate */
>  						1008000000,	/* Maximum rate */
> @@ -80,7 +81,10 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-vid
>  						297000000,	/* frac rate 1 */
>  						BIT(31),	/* gate */
>  						BIT(28),	/* lock */
> -						CLK_SET_RATE_UNGATE);
> +						CLK_SET_RATE_UNGATE,
> +						CCU_FEATURE_FRACTIONAL |
> +						CCU_FEATURE_CLOSEST_RATE,

Above flags are unrelated change, put them in new patch if needed.

Best regards,
Jernej

> +						8, 25);		/* min/max nm ratio */
>  
>  static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
>  					"osc24M", 0x018,
> 
> 






From conor at kernel.org  Tue Dec 19 08:54:29 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 19 Dec 2023 16:54:29 +0000
Subject: [PATCH 0/3] Add mediatek,gce-events definition to
 mediatek,gce-mailbox bindings
In-Reply-To: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
Message-ID: <20231219-joyous-tarmac-aaf601623859@spud>

On Mon, Dec 18, 2023 at 04:36:01PM +0800, Jason-JH.Lin wrote:
> From: Jason-jh Lin <jason-jh.lin at mediatek.corp-partner.google.com>
> 
> Since mediatek,gce-events property is a HW event signal from GCE,
> it should be defined in mediatek,gce-mailbox.yaml.
> 
> Change the description of mediatek,gce-events property existed in
> other bindings to reference mediatek,gce-mailbox.yaml.

I don't understand this series. I would understand it if the property
should be related to the mailbox provider and it is moved there from the
mailbox consumer, but this series does not do that. Instead the series
now documents this property for both consumers and providers.

Secondly it removes the typedef from the consumers, which makes no sense
if this is a valid property there.

Is your intention to document a property that should be common across
all consumers in a single place? If that is your goal, then something
like spi-peripheral-props.yaml is what you need here.

Confused,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/06a34aca/attachment.sig>

From wsa at kernel.org  Tue Dec 19 08:56:15 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 19 Dec 2023 17:56:15 +0100
Subject: [PATCH v7 1/1] i2c: lpi2c: use clk notifier for rate changes
In-Reply-To: <2912069.e9J7NaK4W3@steina-w>
References: <20231107141201.623482-1-alexander.stein@ew.tq-group.com>
 <20231109091046.4hrvxr7g5imfrykq@zenone.zhora.eu>
 <20231110122720.cyxtnpj5k6bip3ok@zenone.zhora.eu>
 <2912069.e9J7NaK4W3@steina-w>
Message-ID: <ZYHLL8fiLKJNEJ+8@shikoro>

Hi,

> > ... improve the commit message, reporting the real deadlock case
> > instead of a lockdep warning and...
> 
> I've improved the commit message about an actual deadlock.

That means a v8 is in your queue?

> > ... find a more appropriate error number, I will ack this patch.
> 
> Thinking about this again, I think EINVAL is an appropriate error code.
> The parent clock frequency is also an input for the i2c transfer. So if, for 
> whatever reason, that clock frequency is 0, it is an invalid value (argument).
> I've checked other drivers what they do if that clock is 0. Unfortunately most 
> don't consider this case at all. But some do, so e.g. i2c_lpc2k_probe() or 
> dc_i2c_init_hw() both return EINVAL if the clk or a calculated divider is 0.

IMHO, the return value doesn't matter that much as we have a descriptive
text accompanying it anyhow.

Happy hacking,

   Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/23fa9ca9/attachment.sig>

From robin.murphy at arm.com  Tue Dec 19 08:57:42 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 19 Dec 2023 16:57:42 +0000
Subject: Could external jtag debugger trap page fault instead of kernel
 handler?
In-Reply-To: <b8ccbd62-7a0d-49eb-bc32-c48e59adeae6@synaptics.com>
References: <b8ccbd62-7a0d-49eb-bc32-c48e59adeae6@synaptics.com>
Message-ID: <daac75e5-bb80-461f-a77b-939a184d3caa@arm.com>

On 2023-12-19 7:47 am, Hsia-Jun Li wrote:
> Hello
> 
> I am trying to debug an illegal memory access problem for a kernel 
> driver. The JTAG could trap the kernel function likes 
> die_kernel_fault(). But it won't provide a context environment in the 
> place where this bug happens.
> 
> I know such page fault is more like a software interrupter, is there a 
> way that I could move my debugging context back?

Right, you don't want to be looking at the current running context of 
the exception handler itself, you want to be looking at the exception 
context that's stored in "regs" at this point. I've never used GDB for 
that, but I'd hope it has some command for inspecting a stack at an 
arbitrary address other than the current SP register.

However, if you haven't already, it looks like enabling 
CONFIG_DEBUG_LIST might help catch this particular issue sooner, as 
you've clearly got some LIST_POISON values there.

Robin.

> Here is what I got from gdb connected to openocd.
> (gdb) bt
> #0? __do_kernel_fault (addr=16045481047390945544, addr at entry=264, 
> esr=2516582468, regs=0xffffff802937b940)
>  ??? at 
> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:372
> #1? 0xffffffc00802c174 in do_bad_area (regs=<optimized out>, 
> esr=<optimized out>, far=16045481047390945544)
>  ??? at 
> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:485
> #2? do_translation_fault (far=16045481047390945544, esr=<optimized out>, 
> regs=<optimized out>)
>  ??? at 
> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:782
> #3? 0xffffffc00802c2cc in do_mem_abort (far=16045481047390945544, 
> esr=2516582468, regs=0xffffff802937b940)
>  ??? at 
> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:918
> #4? 0xffffffc00889738c in skb_dump (level=0xdead000000000108 "", 
> skb=0xffffff802937b940, full_pkt=112)
>  ??? at 
> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/core/skbuff.c:834
> #5? 0x0000000000000000 in ?? ()
> Backtrace stopped: not enough registers or memory available to unwind 
> further
> (gdb) info threads
>  ? Id?? Target Id ??????? Frame
>  ? 1??? Thread 1 "vs640.cpu_a53.0" (Name: vs640.cpu_a53.0, state: 
> debug-request) 0xffffffc008898038 in nf_l4proto_log_inv
> alid (skb=0xffffffc0086391a0 <psci_enter_idle_state>, state=0xffffffff, 
> protonum=0 '\000', fmt=0x258208 "")
>  ??? at 
> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/netfilter/nf_conntrack_proto.c:62
> * 2??? Thread 2 "vs640.cpu_a53.1" (Name: vs640.cpu_a53.1, state: 
> breakpoint)??? __do_kernel_fault (
>  ??? addr=16045481047390945544, addr at entry=264, esr=2516582468, 
> regs=0xffffff802937b940)
>  ??? at 
> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:372
>  ? 3??? Thread 3 "vs640.cpu_a53.2" (Name: vs640.cpu_a53.2, state: 
> debug-request) 0xffffffc008898038 in nf_l4proto_log_inv
> alid (skb=0xffffffc0086391a0 <psci_enter_idle_state>, state=0xffffffff, 
> protonum=0 '\000', fmt=0x9f2270 "")
>  ??? at 
> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/netfilter/nf_conntrack_proto.c:62
>  ? 4??? Thread 4 "vs640.cpu_a53.3" (Name: vs640.cpu_a53.3, state: 
> debug-request) 0xffffffc008898038 in nf_l4proto_log_inv
> alid (skb=0xffffffc0086391a0 <psci_enter_idle_state>, state=0xffffffff, 
> protonum=0 '\000', fmt=0x20ded8 "")
>  ??? at 
> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/netfilter/nf_conntrack_proto.c:62
> 
> And here is the issue I am trying to debug:
> [ 5478.863161] Unable to handle kernel paging request at virtual address 
> dead000000000108
> [ 5478.871093] Mem abort info:
> [ 5478.873886]?? ESR = 0x96000044
> [ 5478.876938]?? EC = 0x25: DABT (current EL), IL = 32 bits
> [ 5478.882249]?? SET = 0, FnV = 0
> [ 5478.885301]?? EA = 0, S1PTW = 0
> [ 5478.888440]?? FSC = 0x04: level 0 translation fault
> [ 5478.893318] Data abort info:
> [ 5478.896195]?? ISV = 0, ISS = 0x00000044
> [ 5478.900029]?? CM = 0, WnR = 1
> [ 5478.902996] [dead000000000108] address between user and kernel 
> address ranges
> [ 5478.910129] Internal error: Oops: 96000044 [#1] PREEMPT SMP
> [ 5478.915701] Modules linked in: vpu videobuf2_memops v4l2_mem2mem 
> videobuf2_v4l2 videobuf2_common videodev mc synap(O)
>  ?pvrsrvkm syna_drm cfg80211 rfkill amp_bm
> [ 5478.929897] CPU: 0 PID: 6613 Comm: gst-launch-1.0 Tainted: G??????? W 
>  ?O????? 5.15.62 #1
> [ 5478.937988] Hardware name: Synaptics VS640 EVK (DT)
> [ 5478.942864] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS 
> BTYPE=--)
> [ 5478.949825] pc : v4l2_m2m_buf_remove+0x50/0x90 [v4l2_mem2mem]
> [ 5478.955582] lr : v4l2_m2m_buf_remove+0x20/0x90 [v4l2_mem2mem]
> [ 5478.961329] sp : ffffff8026c4fa90
> [ 5478.964643] x29: ffffff8026c4fa90 x28: ffffff8026c201b0 x27: 
> 0000000000000000
> [ 5478.971784] x26: 0000000000000000 x25: ffffff8026c4fd28 x24: 
> ffffff8009774270
> [ 5478.978921] x23: ffffff8025f4c100 x22: 0000000000000001 x21: 
> ffffff8025e1f3a0
> [ 5478.986059] x20: ffffff8025e6d7b0 x19: ffffff8025e1f028 x18: 
> 0000000000000000
> [ 5478.993197] x17: 0000000000000000 x16: 0000000000000000 x15: 
> 00000055a1955a10
> [ 5479.000335] x14: 0000000000000000 x13: 0000000000000000 x12: 
> 0000000000000000
> [ 5479.007472] x11: 0000000000000000 x10: 0000000000000000 x9 : 
> 0000000000000000
> [ 5479.014609] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 
> 0000000000000005
> [ 5479.021746] x5 : dead000000000100 x4 : dead000000000122 x3 : 
> dead000000000100
> [ 5479.028884] x2 : dead000000000122 x1 : 0000000000000000 x0 : 
> ffffff8025e1f3a0
> [ 5479.036021] Call trace:
> [ 5479.038467]? v4l2_m2m_buf_remove+0x50/0x90 [v4l2_mem2mem]
> [ 5479.043867]? vb2ops_vdec_stop_streaming+0x98/0x160 [vpu]
> [ 5479.049184]? __vb2_queue_cancel+0x30/0x210 [videobuf2_common]
> [ 5479.054936]? vb2_core_streamoff+0x20/0xb4 [videobuf2_common]
> [ 5479.060597]? vb2_streamoff+0x18/0x64 [videobuf2_v4l2]
> [ 5479.065654]? v4l2_m2m_streamoff+0x70/0x140 [v4l2_mem2mem]
> [ 5479.071055]? v4l2_m2m_ioctl_streamoff+0x14/0x20 [v4l2_mem2mem]
> [ 5479.076889]? v4l_streamoff+0x20/0x30 [videodev]
> [ 5479.081455]? __video_do_ioctl+0x174/0x3d0 [videodev]
> 
> Sincerely


From u.kleine-koenig at pengutronix.de  Tue Dec 19 08:58:05 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 19 Dec 2023 17:58:05 +0100
Subject: [PATCH v10 5/6] pwm: bcm2835: Allow PWM driver to be used in
 atomic context
In-Reply-To: <6c5852c902e6603571e4fde5955d1aeb537059ba.1703003288.git.sean@mess.org>
References: <cover.1703003288.git.sean@mess.org>
 <6c5852c902e6603571e4fde5955d1aeb537059ba.1703003288.git.sean@mess.org>
Message-ID: <3tkfjp64hw42kzj4pex2ql6lyp7r6gm2u42nq6e3av736cinrq@ykylo7d2zs3i>

On Tue, Dec 19, 2023 at 04:30:28PM +0000, Sean Young wrote:
> clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
> rate changes using clk_rate_exclusive_get().
> 
> Signed-off-by: Sean Young <sean at mess.org>
> Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
> ---
>  drivers/pwm/pwm-bcm2835.c | 34 +++++++++++++++++++++++++---------
>  1 file changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
> index ab30667f4f95..d9ac50a5b04e 100644
> --- a/drivers/pwm/pwm-bcm2835.c
> +++ b/drivers/pwm/pwm-bcm2835.c
> @@ -28,6 +28,7 @@ struct bcm2835_pwm {
>  	struct device *dev;
>  	void __iomem *base;
>  	struct clk *clk;
> +	unsigned long rate;
>  };
>  
>  static inline struct bcm2835_pwm *to_bcm2835_pwm(struct pwm_chip *chip)
> @@ -63,17 +64,11 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>  {
>  
>  	struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
> -	unsigned long rate = clk_get_rate(pc->clk);
>  	unsigned long long period_cycles;
>  	u64 max_period;
>  
>  	u32 val;
>  
> -	if (!rate) {
> -		dev_err(pc->dev, "failed to get clock rate\n");
> -		return -EINVAL;
> -	}
> -
>  	/*
>  	 * period_cycles must be a 32 bit value, so period * rate / NSEC_PER_SEC
>  	 * must be <= U32_MAX. As U32_MAX * NSEC_PER_SEC < U64_MAX the
> @@ -88,13 +83,13 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>  	 * <=> period < ((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate
>  	 * <=> period <= ceil((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate) - 1
>  	 */
> -	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, rate) - 1;
> +	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, pc->rate) - 1;
>  
>  	if (state->period > max_period)
>  		return -EINVAL;
>  
>  	/* set period */
> -	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * rate, NSEC_PER_SEC);
> +	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * pc->rate, NSEC_PER_SEC);
>  
>  	/* don't accept a period that is too small */
>  	if (period_cycles < PERIOD_MIN)
> @@ -103,7 +98,7 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>  	writel(period_cycles, pc->base + PERIOD(pwm->hwpwm));
>  
>  	/* set duty cycle */
> -	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * rate, NSEC_PER_SEC);
> +	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * pc->rate, NSEC_PER_SEC);
>  	writel(val, pc->base + DUTY(pwm->hwpwm));
>  
>  	/* set polarity */
> @@ -131,6 +126,13 @@ static const struct pwm_ops bcm2835_pwm_ops = {
>  	.apply = bcm2835_pwm_apply,
>  };
>  
> +static void devm_clk_rate_exclusive_put(void *data)
> +{
> +	struct clk *clk = data;
> +
> +	clk_rate_exclusive_put(clk);
> +}
> +
>  static int bcm2835_pwm_probe(struct platform_device *pdev)
>  {
>  	struct bcm2835_pwm *pc;
> @@ -151,8 +153,22 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
>  		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
>  				     "clock not found\n");
>  
> +	ret = clk_rate_exclusive_get(pc->clk);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "fail to get exclusive rate\n");
> +
> +	devm_add_action_or_reset(&pdev->dev, devm_clk_rate_exclusive_put,
> +				 pc->clk);

Missing error checking.

Otherwise looks good now.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/670bd11d/attachment.sig>

From bvanassche at acm.org  Tue Dec 19 09:00:31 2023
From: bvanassche at acm.org (Bart Van Assche)
Date: Tue, 19 Dec 2023 09:00:31 -0800
Subject: [PATCH V6 1/2] ufs: core: Add CPU latency QoS support for ufs
 driver
In-Reply-To: <20231219123706.6463-2-quic_mnaresh@quicinc.com>
References: <20231219123706.6463-1-quic_mnaresh@quicinc.com>
 <20231219123706.6463-2-quic_mnaresh@quicinc.com>
Message-ID: <90d13f1f-79aa-4067-b949-6f18cb1bb229@acm.org>

On 12/19/23 04:37, Maramaina Naresh wrote:
> Register ufs driver to CPU latency PM QoS framework to improve
> ufs device random io performance.
> 
> PM QoS initialization will insert new QoS request into the CPU
> latency QoS list with the maximum latency PM_QOS_DEFAULT_VALUE
> value.
> 
> UFS driver will vote for performance mode on scale up and power
> save mode for scale down.
> 
> If clock scaling feature is not enabled then voting will be based
> on clock on or off condition.

Reviewed-by: Bart Van Assche <bvanassche at acm.org>


From bvanassche at acm.org  Tue Dec 19 09:00:45 2023
From: bvanassche at acm.org (Bart Van Assche)
Date: Tue, 19 Dec 2023 09:00:45 -0800
Subject: [PATCH V6 2/2] ufs: ufs-mediatek: Migrate to UFSHCD generic CPU
 latency PM QoS support
In-Reply-To: <20231219123706.6463-3-quic_mnaresh@quicinc.com>
References: <20231219123706.6463-1-quic_mnaresh@quicinc.com>
 <20231219123706.6463-3-quic_mnaresh@quicinc.com>
Message-ID: <04a6f477-2666-4873-8612-a4fc643a462f@acm.org>

On 12/19/23 04:37, Maramaina Naresh wrote:
> The PM QoS feature found in the MediaTek UFS driver was moved to the UFSHCD
> core. Hence remove it from MediaTek UFS driver as it is redundant now.

Reviewed-by: Bart Van Assche <bvanassche at acm.org>


From knaerzche at gmail.com  Tue Dec 19 09:00:31 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:31 +0100
Subject: [PATCH v3 01/29] dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-2-knaerzche@gmail.com>

The integration for this SoC is different from the currently existing: It
needs it's PHY's reference clock rate to calculate the DDC bus frequency
correctly. The controller is also part of a powerdomain, so this gets added
as an mandatory property for this variant.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
---
changes in v2:
 - clarify that the controller itself is part of the powerdomain
 - simplify clock-names
 - made power-domains property only allowed (and required) for new variant

changes in v3:
 - collect RB

 .../display/rockchip/rockchip,inno-hdmi.yaml  | 40 ++++++++++++++++++-
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
index 96889c86849a..be78dcfa1c76 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
@@ -14,6 +14,7 @@ properties:
   compatible:
     enum:
       - rockchip,rk3036-inno-hdmi
+      - rockchip,rk3128-inno-hdmi
 
   reg:
     maxItems: 1
@@ -22,10 +23,19 @@ properties:
     maxItems: 1
 
   clocks:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: The HDMI controller main clock
+      - description: The HDMI PHY reference clock
 
   clock-names:
-    const: pclk
+    minItems: 1
+    items:
+      - const: pclk
+      - const: ref
+
+  power-domains:
+    maxItems: 1
 
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
@@ -55,6 +65,32 @@ required:
   - pinctrl-names
   - ports
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: rockchip,rk3036-inno-hdmi
+
+    then:
+      properties:
+        power-domains: false
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: rockchip,rk3128-inno-hdmi
+
+    then:
+      properties:
+        clocks:
+          minItems: 2
+        clock-names:
+          minItems: 2
+      required:
+        - power-domains
+
 additionalProperties: false
 
 examples:
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:30 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:30 +0100
Subject: [PATCH v3 00/29] Add HDMI support for RK3128
Message-ID: <20231219170100.188800-1-knaerzche@gmail.com>

This is version 3 of my series that aims to add support for the display
controller (VOP) and the HDMI controller block of RK3128 (which is very
similar to the one found in RK3036).
The original intention of this series was to add support for this slightly
different integration but is by now, driven by maintainer's feedback,
exploded to be a rework of inno-hdmi driver in large parts.


The VOP part is very simple -  everything we need for HDMI support is
already there. I only needed to split the output selection registers from
RK3036. The VOP has an IOMMU attached, but it has a serious silicon bug:
Registers can only be written, but not be read. As it's not possible to use
it with the IOMMU driver in it's current state I'm not adding it here and
we have to live with CMA for now - which works fine also. I got response
from the vendor, that there is no possibility to read the registers and an
workaround must be implemented in software in order to use it.

The inno-hdmi driver currently gets a lot of attention [0-2] and I'm
hooking in now also. As requested I incorporated some of Maxime's series
[0] (and tested them).
I have intentionally not removed any code dealing with output format
conversion in this series. In contrast to the input format, which is always
RGB on this platform and certainly can be dropped, that can be implemented
later. And secondly I need the conversion for RGB full range to RGB limited
range for this series.

I did also some smaller driver cleanups from my side and implemented a
custom connector state which now holds the data that belongs there and it
is not longer in the device structure and, of course, addressed the
feedback from v1 [3] and v2 [4].
Please see individual patches for changelog.

Note: Patches are based and tested on next-20231213.

[0] https://lore.kernel.org/all/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org
[1] https://lore.kernel.org/all/20231204123315.28456-1-keith.zhao at starfivetech.com
[2] https://lore.kernel.org/all/2601b669-c570-f39d-8cf9-bff56c939912 at gmail.com
[3] https://lore.kernel.org/all/20231213195125.212923-1-knaerzche at gmail.com/
[4] https://lore.kernel.org/all/20231216162639.125215-1-knaerzche at gmail.com/

Alex Bee (17):
  dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible
  drm/rockchip: vop: Add output selection registers for RK312x
  drm/rockchip: inno_hdmi: Fix video timing
  drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents
  drm/rockchip: inno_hdmi: Drop irq struct member
  drm/rockchip: inno_hdmi: Remove useless include
  drm/rockchip: inno_hdmi: Subclass connector state
  drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
  drm/rockchip: inno_hdmi: Don't power up the phy after resetting
  drm/rockchip: inno_hdmi: Split power mode setting
  drm/rockchip: inno_hdmi: Add variant support
  drm/rockchip: inno_hdmi: Add RK3128 support
  drm/rockchip: inno_hdmi: Add basic mode validation
  drm/rockchip: inno_hdmi: Drop custom fill_modes hook
  ARM: dts: rockchip: Add display subsystem for RK3128
  ARM: dts: rockchip: Add HDMI node for RK3128
  ARM: dts: rockchip: Enable HDMI output for XPI-3128

Maxime Ripard (12):
  drm/rockchip: inno_hdmi: Remove useless mode_fixup
  drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
  drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
  drm/rockchip: inno_hdmi: Get rid of mode_set
  drm/rockchip: inno_hdmi: no need to store vic
  drm/rockchip: inno_hdmi: Remove unneeded has audio flag
  drm/rockchip: inno_hdmi: Remove useless input format
  drm/rockchip: inno_hdmi: Remove tmds rate from structure
  drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support
  drm/rockchip: inno_hdmi: Move infoframe disable to separate function
  drm/rockchip: inno_hdmi: Switch to infoframe type
  drm/rockchip: inno_hdmi: Remove unused drm device pointer

 .../display/rockchip/rockchip,inno-hdmi.yaml  |  40 +-
 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts |  29 +
 arch/arm/boot/dts/rockchip/rk3128.dtsi        |  60 ++
 drivers/gpu/drm/rockchip/inno_hdmi.c          | 543 +++++++++++-------
 drivers/gpu/drm/rockchip/inno_hdmi.h          |   5 -
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c   |  13 +-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h   |   3 +
 7 files changed, 478 insertions(+), 215 deletions(-)


base-commit: 48e8992e33abf054bcc0bb2e77b2d43bb899212e
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:33 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:33 +0100
Subject: [PATCH v3 03/29] drm/rockchip: inno_hdmi: Fix video timing
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-4-knaerzche@gmail.com>

The controller wants the difference between *total and *sync_start in the
HDMI_VIDEO_EXT_*DELAY registers. Otherwise the signal is very unstable for
certain non-VIC modes. See downstream commit [0].

[0] https://github.com/rockchip-linux/kernel/commit/8eb559f2502c

Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Co-developed-by: Zheng Yang <zhengyang at rock-chips.com>
Signed-off-by: Zheng Yang <zhengyang at rock-chips.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - none

changes in v3:
 - none
 
 drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 6e5b922a121e..345253e033c5 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -412,7 +412,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_L, value & 0xFF);
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_H, (value >> 8) & 0xFF);
 
-	value = mode->hsync_start - mode->hdisplay;
+	value = mode->htotal - mode->hsync_start;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_L, value & 0xFF);
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_H, (value >> 8) & 0xFF);
 
@@ -427,7 +427,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
 	value = mode->vtotal - mode->vdisplay;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VBLANK, value & 0xFF);
 
-	value = mode->vsync_start - mode->vdisplay;
+	value = mode->vtotal - mode->vsync_start;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VDELAY, value & 0xFF);
 
 	value = mode->vsync_end - mode->vsync_start;
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:34 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:34 +0100
Subject: [PATCH v3 04/29] drm/rockchip: inno_hdmi: Remove useless mode_fixup
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-5-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The mode_fixup implementation doesn't do anything, so we can simply
remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 345253e033c5..0b1740b38c7b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -517,13 +517,6 @@ static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
 	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
 }
 
-static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
-					 const struct drm_display_mode *mode,
-					 struct drm_display_mode *adj_mode)
-{
-	return true;
-}
-
 static int
 inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 			       struct drm_crtc_state *crtc_state,
@@ -540,7 +533,6 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
 	.enable     = inno_hdmi_encoder_enable,
 	.disable    = inno_hdmi_encoder_disable,
-	.mode_fixup = inno_hdmi_encoder_mode_fixup,
 	.mode_set   = inno_hdmi_encoder_mode_set,
 	.atomic_check = inno_hdmi_encoder_atomic_check,
 };
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:37 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:37 +0100
Subject: [PATCH v3 07/29] drm/rockchip: inno_hdmi: Get rid of mode_set
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-8-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 48c4f010b260..299770e481b7 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -490,21 +490,22 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	return 0;
 }
 
-static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-				       struct drm_crtc_state *crtc_state,
-				       struct drm_connector_state *conn_state)
-{
-	struct drm_display_mode *adj_mode = &crtc_state->adjusted_mode;
-	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
-
-	inno_hdmi_setup(hdmi, adj_mode);
-}
-
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 				     struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
+	struct drm_connector_state *conn_state;
+	struct drm_crtc_state *crtc_state;
+
+	conn_state = drm_atomic_get_new_connector_state(state, &hdmi->connector);
+	if (WARN_ON(!conn_state))
+		return;
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+	if (WARN_ON(!crtc_state))
+		return;
 
+	inno_hdmi_setup(hdmi, &crtc_state->adjusted_mode);
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
@@ -533,7 +534,6 @@ static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
 	.atomic_check	= inno_hdmi_encoder_atomic_check,
 	.atomic_enable	= inno_hdmi_encoder_enable,
 	.atomic_disable	= inno_hdmi_encoder_disable,
-	.atomic_mode_set	= inno_hdmi_encoder_mode_set,
 };
 
 static enum drm_connector_status
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:35 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:35 +0100
Subject: [PATCH v3 05/29] drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-6-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The driver maintains a copy of the adjusted mode but doesn't use it
anywhere. Remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 0b1740b38c7b..14d2ba92a606 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -62,7 +62,6 @@ struct inno_hdmi {
 	unsigned int tmds_rate;
 
 	struct hdmi_data_info	hdmi_data;
-	struct drm_display_mode previous_mode;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -498,9 +497,6 @@ static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_setup(hdmi, adj_mode);
-
-	/* Store the display mode for plugin/DPMS poweron events */
-	drm_mode_copy(&hdmi->previous_mode, adj_mode);
 }
 
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:38 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:38 +0100
Subject: [PATCH v3 08/29] drm/rockchip: inno_hdmi: no need to store vic
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-9-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The mode's VIC is only ever used in the inno_hdmi_setup() function so
there's no need to store it in the main structure.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
[made checkpatch happy]
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 299770e481b7..d99896f1a73a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	int vic;
 	bool sink_has_audio;
 	unsigned int enc_in_format;
 	unsigned int enc_out_format;
@@ -443,16 +442,15 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 			   struct drm_display_mode *mode)
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
-
-	hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
+	u8 vic = drm_match_cea_mode(mode);
 
 	hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
 	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
 
-	if ((hdmi->hdmi_data.vic == 6) || (hdmi->hdmi_data.vic == 7) ||
-	    (hdmi->hdmi_data.vic == 21) || (hdmi->hdmi_data.vic == 22) ||
-	    (hdmi->hdmi_data.vic == 2) || (hdmi->hdmi_data.vic == 3) ||
-	    (hdmi->hdmi_data.vic == 17) || (hdmi->hdmi_data.vic == 18))
+	if (vic == 6 || vic == 7 ||
+	    vic == 21 || vic == 22 ||
+	    vic == 2 || vic == 3 ||
+	    vic == 17 || vic == 18)
 		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
 	else
 		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:32 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:32 +0100
Subject: [PATCH v3 02/29] drm/rockchip: vop: Add output selection registers for RK312x
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-3-knaerzche@gmail.com>

In contrast to RK3036, RK312x SoCs have multiple output channels such as
RGB (i.e. LVDS TTL), LVDS, DSI and HDMI.

In order to support that, this splits output from RK3036 and defines an
separate one for RK3126 with the registers required to enable the
appropriate output and setup the correct polarity.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - rephrase commit message

changes in v3:
 - none

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 ++++++++++++-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  3 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index c51ca82320cb..b9ee02061d5b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -227,11 +227,22 @@ static const struct vop_win_data rk3126_vop_win_data[] = {
 	  .type = DRM_PLANE_TYPE_CURSOR },
 };
 
+static const struct vop_output rk3126_output = {
+	.pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+	.hdmi_pin_pol = VOP_REG(RK3126_INT_SCALER, 0x7, 4),
+	.hdmi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 22),
+	.hdmi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 23),
+	.rgb_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 24),
+	.rgb_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 25),
+	.mipi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 28),
+	.mipi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 29),
+};
+
 static const struct vop_data rk3126_vop = {
 	.intr = &rk3036_intr,
 	.common = &rk3036_common,
 	.modeset = &rk3036_modeset,
-	.output = &rk3036_output,
+	.output = &rk3126_output,
 	.win = rk3126_vop_win_data,
 	.win_size = ARRAY_SIZE(rk3126_vop_win_data),
 	.max_output = { 1920, 1080 },
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 406e981c75bd..fbf1bcc68625 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -872,6 +872,9 @@
 /* rk3036 register definition end */
 
 /* rk3126 register definition */
+#define RK3126_INT_SCALER		0x0c
+
+/* win1 register */
 #define RK3126_WIN1_MST			0x4c
 #define RK3126_WIN1_DSP_INFO		0x50
 #define RK3126_WIN1_DSP_ST		0x54
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:36 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:36 +0100
Subject: [PATCH v3 06/29] drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-7-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The inno_hdmi encoder still uses the !atomic variants of enable, disable
and modeset. Convert to their atomic equivalents.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 14d2ba92a606..48c4f010b260 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -491,22 +491,25 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 }
 
 static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-				       struct drm_display_mode *mode,
-				       struct drm_display_mode *adj_mode)
+				       struct drm_crtc_state *crtc_state,
+				       struct drm_connector_state *conn_state)
 {
+	struct drm_display_mode *adj_mode = &crtc_state->adjusted_mode;
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_setup(hdmi, adj_mode);
 }
 
-static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
+				     struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
+				      struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
@@ -527,10 +530,10 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 }
 
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
-	.enable     = inno_hdmi_encoder_enable,
-	.disable    = inno_hdmi_encoder_disable,
-	.mode_set   = inno_hdmi_encoder_mode_set,
-	.atomic_check = inno_hdmi_encoder_atomic_check,
+	.atomic_check	= inno_hdmi_encoder_atomic_check,
+	.atomic_enable	= inno_hdmi_encoder_enable,
+	.atomic_disable	= inno_hdmi_encoder_disable,
+	.atomic_mode_set	= inno_hdmi_encoder_mode_set,
 };
 
 static enum drm_connector_status
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:39 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:39 +0100
Subject: [PATCH v3 09/29] drm/rockchip: inno_hdmi: Remove unneeded has audio flag
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-10-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The sink_has_audio flag is not used anywhere in the driver so let's get
rid of it. It's redundant with drm_display_info.has_audio anyway.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index d99896f1a73a..58aff7a9c09a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	bool sink_has_audio;
 	unsigned int enc_in_format;
 	unsigned int enc_out_format;
 	unsigned int colorimetry;
@@ -554,7 +553,6 @@ static int inno_hdmi_connector_get_modes(struct drm_connector *connector)
 
 	edid = drm_get_edid(connector, hdmi->ddc);
 	if (edid) {
-		hdmi->hdmi_data.sink_has_audio = drm_detect_monitor_audio(edid);
 		drm_connector_update_edid_property(connector, edid);
 		ret = drm_add_edid_modes(connector, edid);
 		kfree(edid);
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:40 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:40 +0100
Subject: [PATCH v3 10/29] drm/rockchip: inno_hdmi: Remove useless input format
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-11-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The driver has a lot of logic to deal with multiple input formats, but
hardcodes it to RGB. This means that most of that code has been dead
code, so let's get rid of it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
[made checkpatch happy]
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 41 ++++++++--------------------
 1 file changed, 11 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 58aff7a9c09a..7c75feedacad 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	unsigned int enc_in_format;
 	unsigned int enc_out_format;
 	unsigned int colorimetry;
 };
@@ -328,47 +327,30 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		v_VIDEO_INPUT_CSP(0);
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
-	if (data->enc_in_format == data->enc_out_format) {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
-		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
-			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
-			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
-			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
-				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
-				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
-				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
-			return 0;
-		}
+	if (data->enc_out_format == HDMI_COLORSPACE_RGB) {
+		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+
+		hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+			  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+			  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+			  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+		return 0;
 	}
 
 	if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
-		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
-		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
-			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
-			csc_mode = CSC_ITU601_16_235_TO_RGB_0_255_8BIT;
-			auto_csc = AUTO_CSC_ENABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_DISABLE;
 		}
 	} else {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
-		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
-		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
-			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
-			csc_mode = CSC_ITU709_16_235_TO_RGB_0_255_8BIT;
-			auto_csc = AUTO_CSC_ENABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_DISABLE;
 		}
 	}
 
@@ -443,7 +425,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	struct drm_display_info *display = &hdmi->connector.display_info;
 	u8 vic = drm_match_cea_mode(mode);
 
-	hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
 	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
 
 	if (vic == 6 || vic == 7 ||
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:41 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:41 +0100
Subject: [PATCH v3 11/29] drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-12-knaerzche@gmail.com>

Now that the unneeded support for YUV based input formats is gone, the csc
coefficients for those formats can be dropped as well.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - new patch

changes in v3:
 - none
	
 drivers/gpu/drm/rockchip/inno_hdmi.c | 37 ----------------------------
 1 file changed, 37 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 7c75feedacad..04344ee1265d 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -74,49 +74,12 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct drm_connector *connector)
 }
 
 enum {
-	CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
-	CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
-	CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
 	CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
 	CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
 	CSC_RGB_0_255_TO_RGB_16_235_8BIT,
 };
 
 static const char coeff_csc[][24] = {
-	/*
-	 * YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
-	 *   R = 1.164*Y + 1.596*V - 204
-	 *   G = 1.164*Y - 0.391*U - 0.813*V + 154
-	 *   B = 1.164*Y + 2.018*U - 258
-	 */
-	{
-		0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
-		0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
-		0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
-	},
-	/*
-	 * YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
-	 *   R = Y + 1.402*V - 248
-	 *   G = Y - 0.344*U - 0.714*V + 135
-	 *   B = Y + 1.772*U - 227
-	 */
-	{
-		0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 0xf8,
-		0x04, 0x00, 0x11, 0x60, 0x12, 0xdb, 0x00, 0x87,
-		0x04, 0x00, 0x07, 0x16, 0x00, 0x00, 0x02, 0xe3
-	},
-	/*
-	 * YUV2RGB:709 HD mode(Y[16:235],UV[16:240],RGB[0:255]):
-	 *   R = 1.164*Y + 1.793*V - 248
-	 *   G = 1.164*Y - 0.213*U - 0.534*V + 77
-	 *   B = 1.164*Y + 2.115*U - 289
-	 */
-	{
-		0x04, 0xa7, 0x00, 0x00, 0x07, 0x2c, 0x02, 0xf8,
-		0x04, 0xa7, 0x10, 0xda, 0x12, 0x22, 0x00, 0x4d,
-		0x04, 0xa7, 0x08, 0x74, 0x00, 0x00, 0x03, 0x21
-	},
-
 	/*
 	 * RGB2YUV:601 SD mode:
 	 *   Cb = -0.291G - 0.148R + 0.439B + 128
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:42 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:42 +0100
Subject: [PATCH v3 12/29] drm/rockchip: inno_hdmi: Remove tmds rate from structure
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-13-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The tmds_rate field in the inno_hdmi structure is used mostly to
configure the internal i2c controller divider through a call to the
inno_hdmi_i2c_init() function.

We can simply make that rate an argument to that function, which also
removes a workaround to initialize the divider at probe time when we
don't have a mode yet.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v3:
 - imported patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 04344ee1265d..102195837206 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -56,8 +56,6 @@ struct inno_hdmi {
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
 
-	unsigned int tmds_rate;
-
 	struct hdmi_data_info	hdmi_data;
 };
 
@@ -134,11 +132,11 @@ static inline void hdmi_modb(struct inno_hdmi *hdmi, u16 offset,
 	hdmi_writeb(hdmi, offset, temp);
 }
 
-static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
+static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi, unsigned long long rate)
 {
-	int ddc_bus_freq;
+	unsigned long long ddc_bus_freq = rate >> 2;
 
-	ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE;
+	do_div(ddc_bus_freq, HDMI_SCL_RATE);
 
 	hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
 	hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
@@ -421,8 +419,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
 	 * clock rate, and reconfigure the DDC clock.
 	 */
-	hdmi->tmds_rate = mode->clock * 1000;
-	inno_hdmi_i2c_init(hdmi);
+	inno_hdmi_i2c_init(hdmi, mode->clock * 1000);
 
 	/* Unmute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -800,8 +797,7 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
 	 * and reconfigure the DDC clock.
 	 */
-	hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
-	inno_hdmi_i2c_init(hdmi);
+	inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
 
 	ret = inno_hdmi_register(drm, hdmi);
 	if (ret)
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:43 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:43 +0100
Subject: [PATCH v3 13/29] drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-14-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The HDMI vendor infoframe is only meant to be sent with 4k60 modes and
higher, but the controller doesn't support them. Let's drop them from
the kernel.

Suggested-by: Johan Jonker <jbx6244 at gmail.com>
Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 35 ++++++++--------------------
 1 file changed, 10 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 102195837206..5c9f1325441f 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -206,11 +206,15 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 }
 
 static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
-				  union hdmi_infoframe *frame, u32 frame_index,
-				  u32 mask, u32 disable, u32 enable)
+				  union hdmi_infoframe *frame, u32 frame_index)
 {
-	if (mask)
-		hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, disable);
+	struct drm_connector *connector = &hdmi->connector;
+
+	if (frame_index != INFOFRAME_AVI) {
+		drm_err(connector->dev,
+			"Unsupported infoframe type: %u\n", frame_index);
+		return 0;
+	}
 
 	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
 
@@ -226,28 +230,11 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
 		for (i = 0; i < rc; i++)
 			hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
 				    packed_frame[i]);
-
-		if (mask)
-			hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, enable);
 	}
 
 	return setup_rc;
 }
 
-static int inno_hdmi_config_video_vsi(struct inno_hdmi *hdmi,
-				      struct drm_display_mode *mode)
-{
-	union hdmi_infoframe frame;
-	int rc;
-
-	rc = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
-							 &hdmi->connector,
-							 mode);
-
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_VSI,
-		m_PACKET_VSI_EN, v_PACKET_VSI_EN(0), v_PACKET_VSI_EN(1));
-}
-
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 				      struct drm_display_mode *mode)
 {
@@ -265,7 +252,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
+	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
@@ -408,10 +395,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 
 	inno_hdmi_config_video_csc(hdmi);
 
-	if (display->is_hdmi) {
+	if (display->is_hdmi)
 		inno_hdmi_config_video_avi(hdmi, mode);
-		inno_hdmi_config_video_vsi(hdmi, mode);
-	}
 
 	/*
 	 * When IP controller have configured to an accurate video
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:44 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:44 +0100
Subject: [PATCH v3 14/29] drm/rockchip: inno_hdmi: Move infoframe disable to separate function
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-15-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The code to upload infoframes to the controller uses a weird construct
which, based on the previous function call return code, will either
disable or enable that infoframe.

In order to get rid of that argument, let's split the function to
disable the infoframe into a separate function and make it obvious what
we are doing in the error path.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 46 ++++++++++++++++++----------
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 5c9f1325441f..10466c2aa520 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -205,34 +205,44 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
-				  union hdmi_infoframe *frame, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
 {
 	struct drm_connector *connector = &hdmi->connector;
 
 	if (frame_index != INFOFRAME_AVI) {
 		drm_err(connector->dev,
 			"Unsupported infoframe type: %u\n", frame_index);
-		return 0;
+		return;
 	}
 
 	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+}
 
-	if (setup_rc >= 0) {
-		u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
-		ssize_t rc, i;
-
-		rc = hdmi_infoframe_pack(frame, packed_frame,
-					 sizeof(packed_frame));
-		if (rc < 0)
-			return rc;
+static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
+				  union hdmi_infoframe *frame, u32 frame_index)
+{
+	struct drm_connector *connector = &hdmi->connector;
+	u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
+	ssize_t rc, i;
 
-		for (i = 0; i < rc; i++)
-			hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
-				    packed_frame[i]);
+	if (frame_index != INFOFRAME_AVI) {
+		drm_err(connector->dev,
+			"Unsupported infoframe type: %u\n", frame_index);
+		return 0;
 	}
 
-	return setup_rc;
+	inno_hdmi_disable_frame(hdmi, frame_index);
+
+	rc = hdmi_infoframe_pack(frame, packed_frame,
+				 sizeof(packed_frame));
+	if (rc < 0)
+		return rc;
+
+	for (i = 0; i < rc; i++)
+		hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
+			    packed_frame[i]);
+
+	return 0;
 }
 
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
@@ -244,6 +254,10 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
 						      &hdmi->connector,
 						      mode);
+	if (rc) {
+		inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+		return rc;
+	}
 
 	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
 		frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
@@ -252,7 +266,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI);
+	return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:45 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:45 +0100
Subject: [PATCH v3 15/29] drm/rockchip: inno_hdmi: Switch to infoframe type
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-16-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The inno_hdmi driver relies on its own internal infoframe type matching
the hardware.

This works fine, but in order to make further reworks easier, let's
switch to the HDMI spec definition of those types.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB
 
 drivers/gpu/drm/rockchip/inno_hdmi.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 10466c2aa520..49367ca24125 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -205,33 +205,34 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
+				    enum hdmi_infoframe_type type)
 {
 	struct drm_connector *connector = &hdmi->connector;
 
-	if (frame_index != INFOFRAME_AVI) {
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
-			"Unsupported infoframe type: %u\n", frame_index);
+			"Unsupported infoframe type: %u\n", type);
 		return;
 	}
 
-	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
-				  union hdmi_infoframe *frame, u32 frame_index)
+				  union hdmi_infoframe *frame, enum hdmi_infoframe_type type)
 {
 	struct drm_connector *connector = &hdmi->connector;
 	u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
 	ssize_t rc, i;
 
-	if (frame_index != INFOFRAME_AVI) {
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
-			"Unsupported infoframe type: %u\n", frame_index);
+			"Unsupported infoframe type: %u\n", type);
 		return 0;
 	}
 
-	inno_hdmi_disable_frame(hdmi, frame_index);
+	inno_hdmi_disable_frame(hdmi, type);
 
 	rc = hdmi_infoframe_pack(frame, packed_frame,
 				 sizeof(packed_frame));
@@ -255,7 +256,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 						      &hdmi->connector,
 						      mode);
 	if (rc) {
-		inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+		inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI);
 		return rc;
 	}
 
@@ -266,7 +267,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI);
+	return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:46 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:46 +0100
Subject: [PATCH v3 16/29] drm/rockchip: inno_hdmi: Remove unused drm device pointer
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-17-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 49367ca24125..51c1a69dfcc0 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -44,7 +44,6 @@ struct inno_hdmi_i2c {
 
 struct inno_hdmi {
 	struct device *dev;
-	struct drm_device *drm_dev;
 
 	int irq;
 	struct clk *pclk;
@@ -757,7 +756,6 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		return -ENOMEM;
 
 	hdmi->dev = dev;
-	hdmi->drm_dev = drm;
 
 	hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hdmi->regs))
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:47 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:47 +0100
Subject: [PATCH v3 17/29] drm/rockchip: inno_hdmi: Drop irq struct member
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-18-knaerzche@gmail.com>

The struct member irq isn't used anywhere. Drop it.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Maxime Ripard <mripard at kernel.org>
---
changes in v2:
 - new patch

changes in v3:
 - collect RB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 51c1a69dfcc0..138cd4287dea 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -45,7 +45,6 @@ struct inno_hdmi_i2c {
 struct inno_hdmi {
 	struct device *dev;
 
-	int irq;
 	struct clk *pclk;
 	void __iomem *regs;
 
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:48 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:48 +0100
Subject: [PATCH v3 18/29] drm/rockchip: inno_hdmi: Remove useless include
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-19-knaerzche@gmail.com>

The inclusion syscon.h isn't used anywhere. Remove it.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Maxime Ripard <mripard at kernel.org>
---
changes in v2:
 - new patch

changes in v3:
 - collect RB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 138cd4287dea..c306db90832a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -10,7 +10,6 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/hdmi.h>
-#include <linux/mfd/syscon.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:49 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:49 +0100
Subject: [PATCH v3 19/29] drm/rockchip: inno_hdmi: Subclass connector state
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-20-knaerzche@gmail.com>

The data which is currently hold in hdmi_data should not be part of device
itself but of the connector state.
Introduce a connector state subclass and move the data from hdmi_data in
there.

Suggested-by: Maxime Ripard <mripard at kernel.org>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - new patch

changes in v3:
 - added missing customizations of reset and atomic_destroy_state connector hooks
 - moved inno_conn_state member assignments to atomic_check

 drivers/gpu/drm/rockchip/inno_hdmi.c | 111 ++++++++++++++++++++-------
 1 file changed, 84 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index c306db90832a..7ce5836fc80d 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,11 +26,6 @@
 
 #include "inno_hdmi.h"
 
-struct hdmi_data_info {
-	unsigned int enc_out_format;
-	unsigned int colorimetry;
-};
-
 struct inno_hdmi_i2c {
 	struct i2c_adapter adap;
 
@@ -52,8 +47,12 @@ struct inno_hdmi {
 
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
+};
 
-	struct hdmi_data_info	hdmi_data;
+struct inno_hdmi_connector_state {
+	struct drm_connector_state	base;
+	unsigned int			enc_out_format;
+	unsigned int			colorimetry;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -68,6 +67,9 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct drm_connector *connector)
 	return container_of(connector, struct inno_hdmi, connector);
 }
 
+#define to_inno_hdmi_conn_state(conn_state) \
+	container_of_const(conn_state, struct inno_hdmi_connector_state, base)
+
 enum {
 	CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
 	CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
@@ -246,6 +248,10 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 				      struct drm_display_mode *mode)
 {
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_connector_state *conn_state = connector->state;
+	struct inno_hdmi_connector_state *inno_conn_state =
+					to_inno_hdmi_conn_state(conn_state);
 	union hdmi_infoframe frame;
 	int rc;
 
@@ -257,9 +263,9 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 		return rc;
 	}
 
-	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
+	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444)
 		frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
-	else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
+	else if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV422)
 		frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
@@ -269,7 +275,10 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 {
-	struct hdmi_data_info *data = &hdmi->hdmi_data;
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_connector_state *conn_state = connector->state;
+	struct inno_hdmi_connector_state *inno_conn_state =
+					to_inno_hdmi_conn_state(conn_state);
 	int c0_c2_change = 0;
 	int csc_enable = 0;
 	int csc_mode = 0;
@@ -287,7 +296,7 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		v_VIDEO_INPUT_CSP(0);
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
-	if (data->enc_out_format == HDMI_COLORSPACE_RGB) {
+	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
 		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
 		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
 
@@ -298,15 +307,15 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		return 0;
 	}
 
-	if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
+	if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
+		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
 		}
 	} else {
-		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
+		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
@@ -383,17 +392,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 			   struct drm_display_mode *mode)
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
-	u8 vic = drm_match_cea_mode(mode);
-
-	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
-
-	if (vic == 6 || vic == 7 ||
-	    vic == 21 || vic == 22 ||
-	    vic == 2 || vic == 3 ||
-	    vic == 17 || vic == 18)
-		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
-	else
-		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
 
 	/* Mute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -458,10 +456,24 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 			       struct drm_connector_state *conn_state)
 {
 	struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+	struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+	u8 vic = drm_match_cea_mode(mode);
+	struct inno_hdmi_connector_state *inno_conn_state =
+					to_inno_hdmi_conn_state(conn_state);
 
 	s->output_mode = ROCKCHIP_OUT_MODE_P888;
 	s->output_type = DRM_MODE_CONNECTOR_HDMIA;
 
+	if (vic == 6 || vic == 7 ||
+	    vic == 21 || vic == 22 ||
+	    vic == 2 || vic == 3 ||
+	    vic == 17 || vic == 18)
+		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_601;
+	else
+		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
+
+	inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB;
+
 	return 0;
 }
 
@@ -519,13 +531,58 @@ static void inno_hdmi_connector_destroy(struct drm_connector *connector)
 	drm_connector_cleanup(connector);
 }
 
+static void inno_hdmi_connector_reset(struct drm_connector *connector)
+{
+	struct inno_hdmi_connector_state *inno_conn_state;
+
+	inno_conn_state = kzalloc(sizeof(*inno_conn_state), GFP_KERNEL);
+	if (!inno_conn_state)
+		return;
+
+	__drm_atomic_helper_connector_reset(connector, &inno_conn_state->base);
+
+	inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
+	inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB;
+}
+
+static struct drm_connector_state *
+inno_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+	struct inno_hdmi_connector_state *inno_conn_state;
+
+	if (WARN_ON(!connector->state))
+		return NULL;
+
+	inno_conn_state = kmemdup(to_inno_hdmi_conn_state(connector->state),
+				  sizeof(*inno_conn_state), GFP_KERNEL);
+
+	if (!inno_conn_state)
+		return NULL;
+
+	__drm_atomic_helper_connector_duplicate_state(connector,
+						      &inno_conn_state->base);
+
+	return &inno_conn_state->base;
+}
+
+static void
+inno_hdmi_connector_destroy_state(struct drm_connector *connector,
+				  struct drm_connector_state *state)
+{
+	struct inno_hdmi_connector_state *inno_conn_state =
+						to_inno_hdmi_conn_state(state);
+
+	__drm_atomic_helper_connector_destroy_state(&inno_conn_state->base);
+	kfree(inno_conn_state);
+}
+
 static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
 	.fill_modes = inno_hdmi_probe_single_connector_modes,
 	.detect = inno_hdmi_connector_detect,
 	.destroy = inno_hdmi_connector_destroy,
-	.reset = drm_atomic_helper_connector_reset,
-	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+	.reset = inno_hdmi_connector_reset,
+	.atomic_duplicate_state = inno_hdmi_connector_duplicate_state,
+	.atomic_destroy_state = inno_hdmi_connector_destroy_state,
 };
 
 static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = {
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:51 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:51 +0100
Subject: [PATCH v3 21/29] drm/rockchip: inno_hdmi: Don't power up the phy after resetting
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-22-knaerzche@gmail.com>

inno_hdmi_reset is only ever called when initializing the controller. At
this point it?s completely uneccessary to power up the PHY, since all
what has to work at this point is the DDC bus. The phy will be powered up
correctly when a mode is set in inno_hdmi_encoder_enable and disabled in
inno_hdmi_encoder_disable.
Set it to LOWER_PWR after resetting the controller.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v3:
 - new patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e6d37772500c..9fea464b6234 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -202,7 +202,7 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	val = v_REG_CLK_INV | v_REG_CLK_SOURCE_SYS | v_PWR_ON | v_INT_POL_HIGH;
 	hdmi_modb(hdmi, HDMI_SYS_CTRL, msk, val);
 
-	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
+	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
 }
 
 static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:50 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:50 +0100
Subject: [PATCH v3 20/29] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-21-knaerzche@gmail.com>

The display controller will always give full range RGB regardless of the
mode set, but HDMI requires certain modes to be transmitted in limited
range RGB. This is especially required for HDMI sinks which do not support
non-standard quantization ranges.

This enables color space conversion for those modes and sets the
quantization range accordingly in the AVI infoframe.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - made rgb_limited_range part of the new custom connector state

changes in v3:
 - moved assignment of rgb_limited_range to atomic check

 drivers/gpu/drm/rockchip/inno_hdmi.c | 60 +++++++++++++++++++---------
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 7ce5836fc80d..e6d37772500c 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -53,6 +53,7 @@ struct inno_hdmi_connector_state {
 	struct drm_connector_state	base;
 	unsigned int			enc_out_format;
 	unsigned int			colorimetry;
+	bool				rgb_limited_range;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -270,6 +271,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
+	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
+		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
+						   connector, mode,
+						   inno_conn_state->rgb_limited_range ?
+						   HDMI_QUANTIZATION_RANGE_LIMITED :
+						   HDMI_QUANTIZATION_RANGE_FULL);
+	} else {
+		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
+		frame.avi.ycc_quantization_range =
+			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
+	}
+
 	return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI);
 }
 
@@ -297,29 +310,37 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
 	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
-		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
-		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
-		hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
-			  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
-			  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
-			  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
-		return 0;
-	}
-
-	if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
-			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
+		if (inno_conn_state->rgb_limited_range) {
+			csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
+
+		} else {
+			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+
+			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+			return 0;
 		}
 	} else {
-		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
-			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
-			auto_csc = AUTO_CSC_DISABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_ENABLE;
+		if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
+			if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
+				csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
+				auto_csc = AUTO_CSC_DISABLE;
+				c0_c2_change = C0_C2_CHANGE_DISABLE;
+				csc_enable = v_CSC_ENABLE;
+			}
+		} else {
+			if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
+				csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
+				auto_csc = AUTO_CSC_DISABLE;
+				c0_c2_change = C0_C2_CHANGE_DISABLE;
+				csc_enable = v_CSC_ENABLE;
+			}
 		}
 	}
 
@@ -473,6 +494,8 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
 
 	inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB;
+	inno_conn_state->rgb_limited_range =
+		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
 
 	return 0;
 }
@@ -543,6 +566,7 @@ static void inno_hdmi_connector_reset(struct drm_connector *connector)
 
 	inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
 	inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB;
+	inno_conn_state->rgb_limited_range = false;
 }
 
 static struct drm_connector_state *
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:52 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:52 +0100
Subject: [PATCH v3 22/29] drm/rockchip: inno_hdmi: Split power mode setting
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-23-knaerzche@gmail.com>

This splits setting the power mode of the controller / phy in two
functions. It's done in preparation of setting up the phy based on the
pixelclock.

No functional changes intended.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v3:
 - new patch

 drivers/gpu/drm/rockchip/inno_hdmi.c | 54 +++++++++++++---------------
 drivers/gpu/drm/rockchip/inno_hdmi.h |  5 ---
 2 files changed, 24 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 9fea464b6234..e21f6d7aeee6 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -154,38 +154,31 @@ static void inno_hdmi_sys_power(struct inno_hdmi *hdmi, bool enable)
 		hdmi_modb(hdmi, HDMI_SYS_CTRL, m_POWER, v_PWR_OFF);
 }
 
-static void inno_hdmi_set_pwr_mode(struct inno_hdmi *hdmi, int mode)
+static void inno_hdmi_standby(struct inno_hdmi *hdmi)
 {
-	switch (mode) {
-	case NORMAL:
-		inno_hdmi_sys_power(hdmi, false);
+	inno_hdmi_sys_power(hdmi, false);
 
-		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
-		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
-
-		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
-		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
-		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
-		hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x0f);
-		hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x00);
-		hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x01);
-
-		inno_hdmi_sys_power(hdmi, true);
-		break;
+	hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0x00);
+	hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x00);
+	hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x00);
+	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+};
 
-	case LOWER_PWR:
-		inno_hdmi_sys_power(hdmi, false);
-		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0x00);
-		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x00);
-		hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x00);
-		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+static void inno_hdmi_power_up(struct inno_hdmi *hdmi)
+{
+	inno_hdmi_sys_power(hdmi, false);
 
-		break;
+	hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
+	hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
+	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
+	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
+	hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x0f);
+	hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x00);
+	hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x01);
 
-	default:
-		DRM_DEV_ERROR(hdmi->dev, "Unknown power mode %d\n", mode);
-	}
-}
+	inno_hdmi_sys_power(hdmi, true);
+};
 
 static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 {
@@ -202,7 +195,7 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	val = v_REG_CLK_INV | v_REG_CLK_SOURCE_SYS | v_PWR_ON | v_INT_POL_HIGH;
 	hdmi_modb(hdmi, HDMI_SYS_CTRL, msk, val);
 
-	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
+	inno_hdmi_standby(hdmi);
 }
 
 static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
@@ -441,6 +434,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
 		  v_AUDIO_MUTE(0) | v_VIDEO_MUTE(0));
 
+	inno_hdmi_power_up(hdmi);
+
 	return 0;
 }
 
@@ -460,7 +455,6 @@ static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 		return;
 
 	inno_hdmi_setup(hdmi, &crtc_state->adjusted_mode);
-	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
 static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
@@ -468,7 +462,7 @@ static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
-	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
+	inno_hdmi_standby(hdmi);
 }
 
 static int
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.h b/drivers/gpu/drm/rockchip/inno_hdmi.h
index 93245b55f967..a7edf3559e60 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.h
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.h
@@ -10,11 +10,6 @@
 
 #define DDC_SEGMENT_ADDR		0x30
 
-enum PWR_MODE {
-	NORMAL,
-	LOWER_PWR,
-};
-
 #define HDMI_SCL_RATE			(100*1000)
 #define DDC_BUS_FREQ_L			0x4b
 #define DDC_BUS_FREQ_H			0x4c
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:53 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:53 +0100
Subject: [PATCH v3 23/29] drm/rockchip: inno_hdmi: Add variant support
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-24-knaerzche@gmail.com>

In preparation to support RK3128's integration of the controller, this
patch adds a simple variant implementation. They mainly differ in the phy
configuration required, so those are part of the match_data. The values
have been taken from downstream. The pixelclocks in there are meant to be
max-inclusive.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - adapt to the newly introduced inno_hdmi_power_up / inno_hdmi_standby functions

 drivers/gpu/drm/rockchip/inno_hdmi.c | 74 ++++++++++++++++++++++++++--
 1 file changed, 69 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e21f6d7aeee6..df979bab9abd 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,6 +26,17 @@
 
 #include "inno_hdmi.h"
 
+struct inno_hdmi_phy_config {
+	unsigned long pixelclock;
+	u8 pre_emphasis;
+	u8 voltage_level_control;
+};
+
+struct inno_hdmi_variant {
+	struct inno_hdmi_phy_config *phy_configs;
+	struct inno_hdmi_phy_config *default_phy_config;
+};
+
 struct inno_hdmi_i2c {
 	struct i2c_adapter adap;
 
@@ -47,6 +58,8 @@ struct inno_hdmi {
 
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
+
+	const struct inno_hdmi_variant *variant;
 };
 
 struct inno_hdmi_connector_state {
@@ -113,6 +126,30 @@ static const char coeff_csc[][24] = {
 	},
 };
 
+static struct inno_hdmi_phy_config rk3036_hdmi_phy_configs[] = {
+	{  74250000, 0x3f, 0xbb },
+	{ 165000000, 0x6f, 0xbb },
+	{      ~0UL, 0x00, 0x00 }
+};
+
+static int inno_hdmi_find_phy_config(struct inno_hdmi *hdmi,
+				     unsigned long pixelclk)
+{
+	const struct inno_hdmi_phy_config *phy_configs =
+						hdmi->variant->phy_configs;
+	int i;
+
+	for (i = 0; phy_configs[i].pixelclock != ~0UL; i++) {
+		if (pixelclk <= phy_configs[i].pixelclock)
+			return i;
+	}
+
+	DRM_DEV_DEBUG(hdmi->dev, "No phy configuration for pixelclock %lu\n",
+		      pixelclk);
+
+	return -EINVAL;
+}
+
 static inline u8 hdmi_readb(struct inno_hdmi *hdmi, u16 offset)
 {
 	return readl_relaxed(hdmi->regs + (offset) * 0x04);
@@ -164,12 +201,25 @@ static void inno_hdmi_standby(struct inno_hdmi *hdmi)
 	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
 };
 
-static void inno_hdmi_power_up(struct inno_hdmi *hdmi)
+static void inno_hdmi_power_up(struct inno_hdmi *hdmi,
+			       unsigned long mpixelclock)
 {
+	struct inno_hdmi_phy_config *phy_config;
+	int ret = inno_hdmi_find_phy_config(hdmi, mpixelclock);
+
+	if (ret < 0) {
+		phy_config = hdmi->variant->default_phy_config;
+		DRM_DEV_ERROR(hdmi->dev,
+			      "Using default phy configuration for TMDS rate %lu",
+			      mpixelclock);
+	} else {
+		phy_config = &hdmi->variant->phy_configs[ret];
+	}
+
 	inno_hdmi_sys_power(hdmi, false);
 
-	hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
-	hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
+	hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, phy_config->pre_emphasis);
+	hdmi_writeb(hdmi, HDMI_PHY_DRIVER, phy_config->voltage_level_control);
 	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
 	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
 	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
@@ -406,6 +456,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 			   struct drm_display_mode *mode)
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
+	unsigned long mpixelclock = mode->clock * 1000;
 
 	/* Mute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -428,13 +479,13 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
 	 * clock rate, and reconfigure the DDC clock.
 	 */
-	inno_hdmi_i2c_init(hdmi, mode->clock * 1000);
+	inno_hdmi_i2c_init(hdmi, mpixelclock);
 
 	/* Unmute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
 		  v_AUDIO_MUTE(0) | v_VIDEO_MUTE(0));
 
-	inno_hdmi_power_up(hdmi);
+	inno_hdmi_power_up(hdmi, mpixelclock);
 
 	return 0;
 }
@@ -821,6 +872,7 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	struct platform_device *pdev = to_platform_device(dev);
 	struct drm_device *drm = data;
 	struct inno_hdmi *hdmi;
+	const struct inno_hdmi_variant *variant;
 	int irq;
 	int ret;
 
@@ -830,6 +882,12 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 
 	hdmi->dev = dev;
 
+	variant = of_device_get_match_data(hdmi->dev);
+	if (!variant)
+		return -EINVAL;
+
+	hdmi->variant = variant;
+
 	hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hdmi->regs))
 		return PTR_ERR(hdmi->regs);
@@ -923,8 +981,14 @@ static void inno_hdmi_remove(struct platform_device *pdev)
 	component_del(&pdev->dev, &inno_hdmi_ops);
 }
 
+static const struct inno_hdmi_variant rk3036_inno_hdmi_variant = {
+	.phy_configs = rk3036_hdmi_phy_configs,
+	.default_phy_config = &rk3036_hdmi_phy_configs[1],
+};
+
 static const struct of_device_id inno_hdmi_dt_ids[] = {
 	{ .compatible = "rockchip,rk3036-inno-hdmi",
+	  .data = &rk3036_inno_hdmi_variant,
 	},
 	{},
 };
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:58 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:58 +0100
Subject: [PATCH v3 28/29] ARM: dts: rockchip: Add HDMI node for RK3128
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-29-knaerzche@gmail.com>

RK3128 has Innosilicon based HDMI TX controller similar to the one found in
RK3036.
Add it and the respective port nodes to the SoC device tree.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - no changes

 arch/arm/boot/dts/rockchip/rk3128.dtsi | 33 ++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 1a3bc8b2bc6e..fb98873fd94e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -270,6 +270,11 @@ vop: vop at 1010e000 {
 		vop_out: port {
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			vop_out_hdmi: endpoint at 0 {
+				reg = <0>;
+				remote-endpoint = <&hdmi_in_vop>;
+			};
 		};
 	};
 
@@ -463,6 +468,34 @@ usb2phy_otg: otg-port {
 		};
 	};
 
+	hdmi: hdmi at 20034000 {
+		compatible = "rockchip,rk3128-inno-hdmi";
+		reg = <0x20034000 0x4000>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru PCLK_HDMI>, <&cru DCLK_VOP>;
+		clock-names = "pclk", "ref";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hdmii2c_xfer &hdmi_hpd &hdmi_cec>;
+		power-domains = <&power RK3128_PD_VIO>;
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			hdmi_in: port at 0 {
+				reg = <0>;
+				hdmi_in_vop: endpoint {
+					remote-endpoint = <&vop_out_hdmi>;
+				};
+			};
+
+			hdmi_out: port at 1 {
+				reg = <1>;
+			};
+		};
+	};
+
 	timer0: timer at 20044000 {
 		compatible = "rockchip,rk3128-timer", "rockchip,rk3288-timer";
 		reg = <0x20044000 0x20>;
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:57 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:57 +0100
Subject: [PATCH v3 27/29] ARM: dts: rockchip: Add display subsystem for RK3128
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-28-knaerzche@gmail.com>

Add vop and display-subsystem nodes to RK3128's device tree.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - no changes

 arch/arm/boot/dts/rockchip/rk3128.dtsi | 27 ++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index e2264c40b924..1a3bc8b2bc6e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -115,6 +115,12 @@ opp-1200000000 {
 		};
 	};
 
+	display_subsystem: display-subsystem {
+		compatible = "rockchip,display-subsystem";
+		ports = <&vop_out>;
+		status = "disabled";
+	};
+
 	gpu_opp_table: opp-table-1 {
 		compatible = "operating-points-v2";
 
@@ -246,6 +252,27 @@ power-domain at RK3128_PD_GPU {
 		};
 	};
 
+	vop: vop at 1010e000 {
+		compatible = "rockchip,rk3126-vop";
+		reg = <0x1010e000 0x300>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru ACLK_LCDC0>, <&cru DCLK_VOP>,
+			 <&cru HCLK_LCDC0>;
+		clock-names = "aclk_vop", "dclk_vop",
+			      "hclk_vop";
+		resets = <&cru SRST_VOP_A>, <&cru SRST_VOP_H>,
+			 <&cru SRST_VOP_D>;
+		reset-names = "axi", "ahb",
+			      "dclk";
+		power-domains = <&power RK3128_PD_VIO>;
+		status = "disabled";
+
+		vop_out: port {
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	qos_gpu: qos at 1012d000 {
 		compatible = "rockchip,rk3128-qos", "syscon";
 		reg = <0x1012d000 0x20>;
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:56 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:56 +0100
Subject: [PATCH v3 26/29] drm/rockchip: inno_hdmi: Drop custom fill_modes hook
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-27-knaerzche@gmail.com>

Now that we have proper pixelclock-based mode validation we can drop the
custom fill_modes hook.
CRTC size validation for the display controller has been added with
Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
hardware capabilities")

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Maxime Ripard <mripard at kernel.org>
---
changes in v2:
 - no changes

changes in v3:
 - collect RB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index a2a9e54b76c0..29a2c1b87294 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -631,13 +631,6 @@ inno_hdmi_connector_mode_valid(struct drm_connector *connector,
 	return  inno_hdmi_display_mode_valid(hdmi, mode);
 }
 
-static int
-inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
-				       uint32_t maxX, uint32_t maxY)
-{
-	return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
-}
-
 static void inno_hdmi_connector_destroy(struct drm_connector *connector)
 {
 	drm_connector_unregister(connector);
@@ -691,7 +684,7 @@ inno_hdmi_atomic_destroy_state(struct drm_connector *connector,
 }
 
 static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
-	.fill_modes = inno_hdmi_probe_single_connector_modes,
+	.fill_modes = drm_helper_probe_single_connector_modes,
 	.detect = inno_hdmi_connector_detect,
 	.destroy = inno_hdmi_connector_destroy,
 	.reset = inno_hdmi_connector_reset,
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:54 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:54 +0100
Subject: [PATCH v3 24/29] drm/rockchip: inno_hdmi: Add RK3128 support
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-25-knaerzche@gmail.com>

This variant requires the phy reference clock to be enabled before the DDC
block can work and the (initial) DDC bus frequency is calculated based on
the rate of this clock. Besides the only difference is phy configuration
required to make the driver working for this variant as well.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - no changes

 drivers/gpu/drm/rockchip/inno_hdmi.c | 46 +++++++++++++++++++++++++---
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index df979bab9abd..8a1a2320749a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -51,6 +51,7 @@ struct inno_hdmi {
 	struct device *dev;
 
 	struct clk *pclk;
+	struct clk *refclk;
 	void __iomem *regs;
 
 	struct drm_connector	connector;
@@ -132,6 +133,12 @@ static struct inno_hdmi_phy_config rk3036_hdmi_phy_configs[] = {
 	{      ~0UL, 0x00, 0x00 }
 };
 
+static struct inno_hdmi_phy_config rk3128_hdmi_phy_configs[] = {
+	{  74250000, 0x3f, 0xaa },
+	{ 165000000, 0x5f, 0xaa },
+	{      ~0UL, 0x00, 0x00 }
+};
+
 static int inno_hdmi_find_phy_config(struct inno_hdmi *hdmi,
 				     unsigned long pixelclk)
 {
@@ -905,6 +912,20 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		return ret;
 	}
 
+	hdmi->refclk = devm_clk_get_optional(hdmi->dev, "ref");
+	if (IS_ERR(hdmi->refclk)) {
+		DRM_DEV_ERROR(hdmi->dev, "Unable to get HDMI reference clock\n");
+		ret = PTR_ERR(hdmi->refclk);
+		goto err_disable_pclk;
+	}
+
+	ret = clk_prepare_enable(hdmi->refclk);
+	if (ret) {
+		DRM_DEV_ERROR(hdmi->dev,
+			      "Cannot enable HDMI reference clock: %d\n", ret);
+		goto err_disable_pclk;
+	}
+
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		ret = irq;
@@ -921,12 +942,16 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	}
 
 	/*
-	 * When IP controller haven't configured to an accurate video
-	 * timing, then the TMDS clock source would be switched to
-	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
-	 * and reconfigure the DDC clock.
+	 * When the controller isn't configured to an accurate
+	 * video timing and there is no reference clock available,
+	 * then the TMDS clock source would be switched to PCLK_HDMI,
+	 * so we need to init the TMDS rate to PCLK rate, and
+	 * reconfigure the DDC clock.
 	 */
-	inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
+	if (hdmi->refclk)
+		inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->refclk));
+	else
+		inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
 
 	ret = inno_hdmi_register(drm, hdmi);
 	if (ret)
@@ -950,6 +975,8 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 err_put_adapter:
 	i2c_put_adapter(hdmi->ddc);
 err_disable_clk:
+	clk_disable_unprepare(hdmi->refclk);
+err_disable_pclk:
 	clk_disable_unprepare(hdmi->pclk);
 	return ret;
 }
@@ -963,6 +990,7 @@ static void inno_hdmi_unbind(struct device *dev, struct device *master,
 	hdmi->encoder.encoder.funcs->destroy(&hdmi->encoder.encoder);
 
 	i2c_put_adapter(hdmi->ddc);
+	clk_disable_unprepare(hdmi->refclk);
 	clk_disable_unprepare(hdmi->pclk);
 }
 
@@ -986,10 +1014,18 @@ static const struct inno_hdmi_variant rk3036_inno_hdmi_variant = {
 	.default_phy_config = &rk3036_hdmi_phy_configs[1],
 };
 
+static const struct inno_hdmi_variant rk3128_inno_hdmi_variant = {
+	.phy_configs = rk3128_hdmi_phy_configs,
+	.default_phy_config = &rk3128_hdmi_phy_configs[1],
+};
+
 static const struct of_device_id inno_hdmi_dt_ids[] = {
 	{ .compatible = "rockchip,rk3036-inno-hdmi",
 	  .data = &rk3036_inno_hdmi_variant,
 	},
+	{ .compatible = "rockchip,rk3128-inno-hdmi",
+	  .data = &rk3128_inno_hdmi_variant,
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, inno_hdmi_dt_ids);
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:59 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:59 +0100
Subject: [PATCH v3 29/29] ARM: dts: rockchip: Enable HDMI output for XPI-3128
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-30-knaerzche@gmail.com>

Add an hdmi-connector node and enable the hdmi, display-subsystem and vop
nodes.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - no changes

 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index 03a97881519a..21c1678f4e91 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -47,6 +47,17 @@ dc_5v: dc-5v-regulator {
 		regulator-boot-on;
 	};
 
+	hdmi-connnector {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_connector_in: endpoint {
+				remote-endpoint = <&hdmi_connector_out>;
+			};
+		};
+	};
+
 	/*
 	 * This is a vbus-supply, which also supplies the GL852G usb hub,
 	 * thus has to be always-on
@@ -239,6 +250,10 @@ &cpu0 {
 	cpu-supply = <&vdd_arm>;
 };
 
+&display_subsystem {
+	status = "okay";
+};
+
 &emmc {
 	bus-width = <8>;
 	vmmc-supply = <&vcc_io>;
@@ -328,6 +343,16 @@ &gpu {
 	status = "okay";
 };
 
+&hdmi {
+	status = "okay";
+};
+
+&hdmi_out {
+	hdmi_connector_out: endpoint {
+		remote-endpoint = <&hdmi_connector_in>;
+	};
+};
+
 &mdio {
 	phy0: ethernet-phy at 1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
@@ -423,3 +448,7 @@ &usb2phy_host {
 &usb2phy_otg {
 	status = "okay";
 };
+
+&vop {
+	status = "okay";
+};
-- 
2.43.0



From knaerzche at gmail.com  Tue Dec 19 09:00:55 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Tue, 19 Dec 2023 18:00:55 +0100
Subject: [PATCH v3 25/29] drm/rockchip: inno_hdmi: Add basic mode validation
In-Reply-To: <20231219170100.188800-1-knaerzche@gmail.com>
References: <20231219170100.188800-1-knaerzche@gmail.com>
Message-ID: <20231219170100.188800-26-knaerzche@gmail.com>

As per TRM this controller supports pixelclocks starting from 25 MHz. The
maximum supported pixelclocks are defined by the phy configurations we
have. Also it can't support modes that require doubled clocks. If the
variant has a phy reference clock we can additionally validate against VESA
DMT'srecommendations.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Maxime Ripard <mripard at kernel.org>
---
changes in v2:
 - rename inno_mode_valid -> inno_hdmi_display_mode_valid
 - fixed max_tolerance calculation
 - use abs_diff() instead of abs()
 - call in inno_hdmi_display_mode_valid in atomic_check

changes in v3:
 - collect RB

 drivers/gpu/drm/rockchip/inno_hdmi.c | 42 ++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 8a1a2320749a..a2a9e54b76c0 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,6 +26,8 @@
 
 #include "inno_hdmi.h"
 
+#define INNO_HDMI_MIN_TMDS_CLOCK  25000000U
+
 struct inno_hdmi_phy_config {
 	unsigned long pixelclock;
 	u8 pre_emphasis;
@@ -497,6 +499,38 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	return 0;
 }
 
+static enum drm_mode_status inno_hdmi_display_mode_valid(struct inno_hdmi *hdmi,
+							 struct drm_display_mode *mode)
+{
+	unsigned long mpixelclk, max_tolerance;
+	long rounded_refclk;
+
+	/* No support for double-clock modes */
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+		return MODE_BAD;
+
+	mpixelclk = mode->clock * 1000;
+
+	if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
+		return MODE_CLOCK_LOW;
+
+	if (inno_hdmi_find_phy_config(hdmi, mpixelclk) < 0)
+		return MODE_CLOCK_HIGH;
+
+	if (hdmi->refclk) {
+		rounded_refclk = clk_round_rate(hdmi->refclk, mpixelclk);
+		if (rounded_refclk < 0)
+			return MODE_BAD;
+
+		/* Vesa DMT standard mentions +/- 0.5% max tolerance */
+		max_tolerance = mpixelclk / 200;
+		if (abs_diff((unsigned long)rounded_refclk, mpixelclk) > max_tolerance)
+			return MODE_NOCLOCK;
+	}
+
+	return MODE_OK;
+}
+
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 				     struct drm_atomic_state *state)
 {
@@ -529,6 +563,7 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 			       struct drm_connector_state *conn_state)
 {
 	struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 	struct drm_display_mode *mode = &crtc_state->adjusted_mode;
 	u8 vic = drm_match_cea_mode(mode);
 	struct inno_hdmi_connector_state *inno_conn_state =
@@ -549,7 +584,8 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 	inno_conn_state->rgb_limited_range =
 		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
 
-	return 0;
+	return  inno_hdmi_display_mode_valid(hdmi,
+				&crtc_state->adjusted_mode) == MODE_OK ? 0 : -EINVAL;
 }
 
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
@@ -590,7 +626,9 @@ static enum drm_mode_status
 inno_hdmi_connector_mode_valid(struct drm_connector *connector,
 			       struct drm_display_mode *mode)
 {
-	return MODE_OK;
+	struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
+
+	return  inno_hdmi_display_mode_valid(hdmi, mode);
 }
 
 static int
-- 
2.43.0



From sean at mess.org  Tue Dec 19 09:04:24 2023
From: sean at mess.org (Sean Young)
Date: Tue, 19 Dec 2023 17:04:24 +0000
Subject: [PATCH v9 5/6] pwm: bcm2835: Allow PWM driver to be used in
 atomic context
In-Reply-To: <eicw7ppqj5dubskhmeh7iwdaoixv27qw2zqaljkddt2rwosogt@6aftnwt6p5ek>
References: <cover.1702890244.git.sean@mess.org>
 <5249bb5d6c067692e4cd09573ced2df58966693b.1702890244.git.sean@mess.org>
 <eicw7ppqj5dubskhmeh7iwdaoixv27qw2zqaljkddt2rwosogt@6aftnwt6p5ek>
Message-ID: <ZYHNGMabe8xBigyN@gofer.mess.org>

Hello Uwe,

On Mon, Dec 18, 2023 at 10:31:36AM +0100, Uwe Kleine-K?nig wrote:
> On Mon, Dec 18, 2023 at 09:06:46AM +0000, Sean Young wrote:
> > +	pc->rate = clk_get_rate(pc->clk);
> > +	if (!pc->rate) {
> > +		clk_rate_exclusive_put(pc->clk);
> > +		return dev_err_probe(&pdev->dev, -EINVAL,
> > +				     "failed to get clock rate\n");
> > +	}
> > +
> >  	pc->chip.dev = &pdev->dev;
> >  	pc->chip.ops = &bcm2835_pwm_ops;
> > +	pc->chip.atomic = true;
> >  	pc->chip.npwm = 2;
> >  
> >  	platform_set_drvdata(pdev, pc);
> >  
> >  	ret = devm_pwmchip_add(&pdev->dev, &pc->chip);
> > -	if (ret < 0)
> > +	if (ret < 0) {
> > +		clk_rate_exclusive_put(pc->clk);
> >  		return dev_err_probe(&pdev->dev, ret,
> >  				     "failed to add pwmchip\n");
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int bcm2835_pwm_remove(struct platform_device *pdev)
> > +{
> > +	struct bcm2835_pwm *pc = platform_get_drvdata(pdev);
> > +
> > +	clk_rate_exclusive_put(pc->clk);
> 
> The ugly thing here is that now clk_rate_exclusive_put() happens before
> pwmchip_remove().

Mixing devm with non-devm does lead to problems like this.

> Maybe register a devm cleanup which also gets rid of
> the two clk_rate_exclusive_put() in probe's error path?

That's good idea, I've done that in v10.

> 
> >  	return 0;
> >  }
> > @@ -197,6 +216,7 @@ static struct platform_driver bcm2835_pwm_driver = {
> >  		.pm = pm_ptr(&bcm2835_pwm_pm_ops),
> >  	},
> >  	.probe = bcm2835_pwm_probe,
> > +	.remove = bcm2835_pwm_remove,
> 
> Please use .remove_new

No longer needed in v10.


Sean


From jernej.skrabec at gmail.com  Tue Dec 19 09:04:29 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Tue, 19 Dec 2023 18:04:29 +0100
Subject: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate
In-Reply-To: <20231218-pinephone-pll-fixes-v1-5-e238b6ed6dc1@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-5-e238b6ed6dc1@oltmanns.dev>
Message-ID: <10386431.nUPlyArG6x@jernej-laptop>

Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns napisal(a):
> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
> than 500 MHz.
> 
> Therefore, change [hv]sync_(start|end) so that we reach a clock rate
> that is high enough to drive PLL-MIPI within its limits.
> 
> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>

I'm not too sure about this patch. I see that PLL_MIPI doesn't have set
minimum frequency limit in clock driver. If you add it, clock framework
should find rate that is high enough and divisible with target rate.

Best regards,
Jernej  

> ---
>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index b55bafd1a8be..6886fd7f765e 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
>  
>  static const struct drm_display_mode xbd599_mode = {
>  	.hdisplay    = 720,
> -	.hsync_start = 720 + 40,
> -	.hsync_end   = 720 + 40 + 40,
> -	.htotal	     = 720 + 40 + 40 + 40,
> +	.hsync_start = 720 + 65,
> +	.hsync_end   = 720 + 65 + 65,
> +	.htotal      = 720 + 65 + 65 + 65,
>  	.vdisplay    = 1440,
> -	.vsync_start = 1440 + 18,
> -	.vsync_end   = 1440 + 18 + 10,
> -	.vtotal	     = 1440 + 18 + 10 + 17,
> -	.clock	     = 69000,
> +	.vsync_start = 1440 + 30,
> +	.vsync_end   = 1440 + 30 + 22,
> +	.vtotal	     = 1440 + 30 + 22 + 29,
> +	.clock	     = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
>  	.flags	     = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
>  	.width_mm    = 68,
>  	.height_mm   = 136,
> 
> 






From wsa at kernel.org  Tue Dec 19 09:06:26 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 19 Dec 2023 18:06:26 +0100
Subject: [PATCH v3 3/8] i2c: rk3x: Adjust mask/value offset for i2c2 on
 rv1126
In-Reply-To: <20231203124004.2676174-4-tim@feathertop.org>
References: <20231203124004.2676174-1-tim@feathertop.org>
 <20231203124004.2676174-4-tim@feathertop.org>
Message-ID: <ZYHNkgxAauYp6ivX@shikoro>

On Sun, Dec 03, 2023 at 11:39:59PM +1100, Tim Lunn wrote:
> Rockchip RV1126 is using old style i2c controller, the i2c2
> bus uses a non-sequential offset in the grf register for the
> mask/value bits for this bus.
> 
> This patch fixes i2c2 bus on rv1126 SoCs.
> 
> Signed-off-by: Tim Lunn <tim at feathertop.org>
> Acked-by: Heiko Stuebner <heiko at sntech.de>
> 

Applied to for-next, thanks!

But, phew, the fact that this driver _needs_ i2c-aliases in DT should be
fixed somewhen. I totally overlooked this so far :/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/2980d16a/attachment.sig>

From jernej.skrabec at gmail.com  Tue Dec 19 09:14:01 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Tue, 19 Dec 2023 18:14:01 +0100
Subject: [PATCH v6 2/3] thermal: sun8i: Add D1/T113s THS controller support
In-Reply-To: <20231217210629.131486-3-bigunclemax@gmail.com>
References: <20231217210629.131486-1-bigunclemax@gmail.com>
 <20231217210629.131486-3-bigunclemax@gmail.com>
Message-ID: <1950771.PYKUYFuaPT@jernej-laptop>

Dne nedelja, 17. december 2023 ob 22:06:23 CET je Maksim Kiselev napisal(a):
> From: Maxim Kiselev <bigunclemax at gmail.com>
> 
> This patch adds a thermal sensor controller support for the D1/T113s,
> which is similar to the one on H6, but with only one sensor and
> different scale and offset values.
> 
> Signed-off-by: Maxim Kiselev <bigunclemax at gmail.com>

Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>

Best regards,
Jernej




From wsa at kernel.org  Tue Dec 19 09:17:47 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 19 Dec 2023 18:17:47 +0100
Subject: [PATCH 1/1] i2c: imx: Make SDA actually optional for bus
 recovering
In-Reply-To: <12335412.O9o76ZdvQC@steina-w>
References: <20231130095751.65773-1-alexander.stein@ew.tq-group.com>
 <20231203220444.thaeuyqyv36hpv2y@zenone.zhora.eu>
 <12335412.O9o76ZdvQC@steina-w>
Message-ID: <ZYHQOxjCTZnARK0e@shikoro>

On Mon, Dec 04, 2023 at 09:35:00AM +0100, Alexander Stein wrote:
> Hi,
> 
> Am Sonntag, 3. Dezember 2023, 23:04:44 CET schrieb Andi Shyti:
> > Hi,
> > 
> > On Thu, Nov 30, 2023 at 10:57:51AM +0100, Alexander Stein wrote:
> > > Both i2c_generic_scl_recovery() and the debug output indicate that SDA is
> > > purely optional for bus recovery. But devm_gpiod_get() never returns NULL
> > > making it mandatory. Fix this my calling devm_gpiod_get_optional instead.
> > 
> >                                ^^^^
> > as Uwe pointed out, /my/by/.
> > 
> > I think Wolfram can fix this before taking it.
> > 
> > > Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>
> > 
> > otherwise:
> > 
> > Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
> 
> Thanks. Let me know if I should send a v2.

I fixed it up and applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/adcd0a5d/attachment-0001.sig>

From afd at ti.com  Tue Dec 19 09:19:49 2023
From: afd at ti.com (Andrew Davis)
Date: Tue, 19 Dec 2023 11:19:49 -0600
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <3E03E913-48E1-49EC-A6C9-EAC1612E65E7@goldelico.com>
References: <20231204182245.33683-1-afd@ti.com>
 <20231204182245.33683-2-afd@ti.com>
 <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
 <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
 <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>
 <oobcl2kfsuph27er7rflfqvt3lu6athufomxv5chf3uctx4emh@x6rzjtlskhbf>
 <F58855EC-D87D-4747-A363-0E7AA5DB1AEC@goldelico.com>
 <22cny5aumc5wafsrjd3j55zcjbjf2viip64kfbjiqis2grtd6t@wg5dxeuzil6l>
 <3E03E913-48E1-49EC-A6C9-EAC1612E65E7@goldelico.com>
Message-ID: <a3feaf42-17fb-46e5-bbb0-3ffc4ad40bfd@ti.com>

On 12/18/23 4:54 AM, H. Nikolaus Schaller wrote:
> 
> 
>> Am 18.12.2023 um 11:14 schrieb Maxime Ripard <mripard at kernel.org>:
>>
>> On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
>>> Hi Maxime,
>>>
>>>> Am 15.12.2023 um 14:33 schrieb Maxime Ripard <mripard at kernel.org>:
>>>>
>>>>>>
>>>>>> It's for a separate architecture, with a separate driver, maintained out
>>>>>> of tree by a separate community, with a separate set of requirements as
>>>>>> evidenced by the other thread. And that's all fine in itself, but
>>>>>> there's very little reason to put these two bindings in the same file.
>>>>>>
>>>>>> We could also turn this around, why is it important that it's in the
>>>>>> same file?
>>>>>
>>>>> Same vendor. And enough similarity in architectures, even a logical sequence
>>>>> of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
>>>>> (SGX and Rogue seem to be just trade names for their architecture development).
>>>>
>>>> Again, none of that matters for *where* the binding is stored.
>>>
>>> So what then speaks against extending the existing bindings file as proposed
>>> here?
>>
>> I mean, apart from everything you quoted, then sure, nothing speaks
>> against it.
>>
>>>>> AFAIK bindings should describe hardware and not communities or drivers
>>>>> or who is currently maintaining it. The latter can change, the first not.
>>>>
>>>> Bindings are supposed to describe hardware indeed. Nothing was ever said
>>>> about where those bindings are supposed to be located.
>>>>
>>>> There's hundreds of other YAML bindings describing devices of the same
>>>> vendors and different devices from the same generation.
>>>
>>> Usually SoC seem to be split over multiple files by subsystem. Not by versions
>>> or generations. If the subsystems are similar enough they share the same bindings
>>> doc instead of having one for each generation duplicating a lot of code.
>>>
>>> Here is a comparable example that combines multiple vendors and generations:
>>>
>>> Documentation/devicetree/bindings/usb/generic-ehci.yaml
>>
>> EHCI is a single interface for USB2.0 controllers. It's a standard API,
>> and is made of a single driver that requires minor modifications to deal
>> with multiple devices.
>>
>> We're very far from the same situation here.
> 
> How far are we really? And, it is the purpose of the driver to handle different cases.
> 
> That there are currently two drivers is just a matter of history and not a necessity.
> 
>>
>>>> If anything it'll make it easier for you. I'm really not sure why it is
>>>> controversial and you're fighting this so hard.
>>>
>>> Well, you made it controversial by proposing to split what IMHO belongs together.
>>
>> No, reviews aren't controversial.
>> The controversy started when you chose
>> to oppose it while you could have just rolled with it.
> 
> Well, you asked
> 
> "I think it would be best to have a separate file for this, img,sgx.yaml
> maybe?"
> 
> and
> 
> "Because it's more convenient?"
> 
> I understood that as an invitation for discussing the pros and cons and working out the
> most convenient solution. And that involves playing the devil's advocate which of course
> is controversial by principle.
> 
> Now, IMHO all the pros and cons are on the table and the question is who makes a decision
> how to go.
> 

As much as I would land on the side of same file for both, the answer to this question
is simple: the maintainer makes the decision :) So I'll respin with separate binding files.

The hidden unaddressed issue here is that by making these bindings separate it implies
they are not on equal footing (i.e. pre-series6 GPUs are not true "powervr" and so do not
belong in img,powervr.yaml). So if no one objects I'd also like to do the rename of that
file as suggested before and have:

img,powervr-sgx.yaml
img,powervr-rogue.yaml

>>
>>> I feel that the original patch is good enough for its purpose and follows
>>> some design pattern that can be deduced from other binding docs.
>>
>> [citation needed]
> 
> Joke: Documentation/devicetree/bindings/* - I am not aware of a formal analysis of course.
> 
> But see my example for ehci. It follows the pattern I mean. If clocks, regs, interrupts,
> resets, and more properties are (almost) the same, then group them and just differentiate
> by different compatible strings. If necessary use some - if: clauses.
> 
> It is the task of drivers to handle the details.
> 
> As my other (maybe more important) comment to this patch did indicate we IMHO can easily
> live with something like
> 
> +      - items:
> +          - enum:
> +              - ti,am62-gpu # IMG AXE GPU model/revision is fully discoverable
> +              - ti,omap3430-gpu # sgx530 Rev 121
> +              - ti,omap3630-gpu # sgx530 Rev 125
> +              - ingenic,jz4780-gpu # sgx540 Rev 130
> +              - ti,omap4430-gpu # sgx540 Rev 120
> +              - allwinner,sun6i-a31-gpu # sgx544 MP2 Rev 115
> +              - ti,omap4470-gpu # sgx544 MP1 Rev 112
> +              - ti,omap5432-gpu # sgx544 MP2 Rev 105
> +              - ti,am5728-gpu # sgx544 MP2 Rev 116
> +              - ti,am6548-gpu # sgx544 MP1 Rev 117
> 

While we could live with this, the "compatible" groupings makes life just a bit
easier. This is true really for any DT compatible string and is not based on
any technical reasoning.

Andrew

> And leave it to drivers using a table to deduce the generation and
> revision or read it out from the chip. And there can even be different
> drivers handling only a subset of the potential compatibles.
> 
> Then the currently-out-of-tree driver for the sgx5 can be reworked in
> less than half an hour without loosing functionality.
> 
> BR,
> Nikolaus
> 


From david at redhat.com  Tue Dec 19 09:22:52 2023
From: david at redhat.com (David Hildenbrand)
Date: Tue, 19 Dec 2023 18:22:52 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
Message-ID: <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>

On 19.12.23 09:30, Ryan Roberts wrote:
> On 18/12/2023 17:47, David Hildenbrand wrote:
>> On 18.12.23 11:50, Ryan Roberts wrote:
>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>> batch is determined by the architecture with the new helper,
>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>> all belonging to the same folio. A pte batch is then write-protected in
>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>> set in one go in the child using the new helper, set_ptes_full().
>>>
>>> The primary motivation for this change is to reduce the number of tlb
>>> maintenance operations that the arm64 backend has to perform during
>>> fork, as it is about to add transparent support for the "contiguous bit"
>>> in its ptes. By write-protecting the parent using the new
>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>> when all ptes in the range are being write-protected. Similarly, by
>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>> child, the backend does not need to fold a contiguous range once they
>>> are all populated - they can be initially populated as a contiguous
>>> range in the first place.
>>>
>>> This code is very performance sensitive, and a significant amount of
>>> effort has been put into not regressing performance for the order-0
>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>> which enables the compiler to simplify the extra loops that are added
>>> for batching and produce code that is equivalent (and equally
>>> performant) as the previous implementation.
>>>
>>> This change addresses the core-mm refactoring only and a separate change
>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>> set_ptes_full() in the arm64 backend to realize the performance
>>> improvement as part of the work to enable contpte mappings.
>>>
>>> To ensure the arm64 is performant once implemented, this change is very
>>> careful to only call ptep_get() once per pte batch.
>>>
>>> The following microbenchmark results demonstate that there is no
>>> significant performance change after this patch. Fork is called in a
>>> tight loop in a process with 1G of populated memory and the time for the
>>> function to execute is measured. 100 iterations per run, 8 runs
>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>> performed for case where 1G memory is comprised of order-0 folios and
>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>> positive is slower, compared to baseline upon which the series is based:
>>>
>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>> | fork????????? |-------------------|-------------------|
>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>> |---------------|---------|---------|---------|---------|
>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>
>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>> | fork????????? |-------------------|-------------------|
>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>> |---------------|---------|---------|---------|---------|
>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>
>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>> ---
>>>  ? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>  ? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>  ? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>> index af7639c3b0a3..db93fb81465a 100644
>>> --- a/include/linux/pgtable.h
>>> +++ b/include/linux/pgtable.h
>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>  ? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>  ? #endif
>>>  ? +#ifndef pte_batch_remaining
>>> +/**
>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>> + * @pte: Page table entry for the first page.
>>> + * @addr: Address of the first page.
>>> + * @end: Batch ceiling (e.g. end of vma).
>>> + *
>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of ptes.
>>> + * In such cases, this function returns the remaining number of pages to the end
>>> + * of the current batch, as defined by addr. This can be useful when iterating
>>> + * over ptes.
>>> + *
>>> + * May be overridden by the architecture, else batch size is always 1.
>>> + */
>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long addr,
>>> +??????????????????????? unsigned long end)
>>> +{
>>> +??? return 1;
>>> +}
>>> +#endif
>>
>> It's a shame we now lose the optimization for all other archtiectures.
>>
>> Was there no way to have some basic batching mechanism that doesn't require arch
>> specifics?
> 
> I tried a bunch of things but ultimately the way I've done it was the only way
> to reduce the order-0 fork regression to 0.
> 
> My original v3 posting was costing 5% extra and even my first attempt at an
> arch-specific version that didn't resolve to a compile-time constant 1 still
> cost an extra 3%.
> 
> 
>>
>> I'd have thought that something very basic would have worked like:
>>
>> * Check if PTE is the same when setting the PFN to 0.
>> * Check that PFN is consecutive
>> * Check that all PFNs belong to the same folio
> 
> I haven't tried this exact approach, but I'd be surprised if I can get the
> regression under 4% with this. Further along the series I spent a lot of time
> having to fiddle with the arm64 implementation; every conditional and every
> memory read (even when in cache) was a problem. There is just so little in the
> inner loop that every instruction matters. (At least on Ampere Altra and Apple M2).
> 
> Of course if you're willing to pay that 4-5% for order-0 then the benefit to
> order-9 is around 10% in my measurements. Personally though, I'd prefer to play
> safe and ensure the common order-0 case doesn't regress, as you previously
> suggested.
> 

I just hacked something up, on top of my beloved rmap cleanup/batching 
series. I implemented very generic and simple batching for large folios 
(all PTE bits except the PFN have to match).

Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R) 
Silver 4210R CPU.

order-0: 0.014210 -> 0.013969

-> Around 1.7 % faster

order-9: 0.014373 -> 0.009149

-> Around 36.3 % faster


But it's likely buggy, so don't trust the numbers just yet. If they 
actually hold up, we should probably do something like that ahead of 
time, before all the arm-specific cont-pte work.

I suspect you can easily extend that by arch hooks where reasonable.

The (3) patches on top of the rmap cleanups can be found at:

	https://github.com/davidhildenbrand/linux/tree/fork-batching

-- 
Cheers,

David / dhildenb



From wsa at kernel.org  Tue Dec 19 09:23:32 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 19 Dec 2023 18:23:32 +0100
Subject: [PATCH v2] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <20231207082200.16388-1-jensenhuang@friendlyarm.com>
References: <20231207082200.16388-1-jensenhuang@friendlyarm.com>
Message-ID: <ZYHRlMukbJUZw7cO@shikoro>

On Thu, Dec 07, 2023 at 04:21:59PM +0800, Jensen Huang wrote:
> Possible deadlock scenario (on reboot):
> rk3x_i2c_xfer_common(polling)
>     -> rk3x_i2c_wait_xfer_poll()
>         -> rk3x_i2c_irq(0, i2c);
>             --> spin_lock(&i2c->lock);
>             ...
>         <rk3x i2c interrupt>
>         -> rk3x_i2c_irq(0, i2c);
>             --> spin_lock(&i2c->lock); (deadlock here)
> 
> Store the IRQ number and disable/enable it around the polling transfer.
> This patch has been tested on NanoPC-T4.
> 
> Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Applied to for-current, thanks!

But I'd like to see the follow-up patches somewhen which have been
discussed in this thread.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/3b69865e/attachment-0001.sig>

From semen.protsenko at linaro.org  Tue Dec 19 09:31:39 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Tue, 19 Dec 2023 11:31:39 -0600
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock
 as critical
In-Reply-To: <4ba80e1e-8fec-4fd2-9140-6da006c9d5f5@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-8-tudor.ambarus@linaro.org> <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>
 <f3d61c49-1a46-476c-b7a5-6cc6a06a33ed@linaro.org> <CAPLW+4=tyr8Pcoe6Wm0Wtmkk4udDpuAiOKy7+C+Fwa6mvt3VoQ@mail.gmail.com>
 <5de5cddd-2bab-4408-b31f-f48bef98f14c@linaro.org> <CAPLW+4n-S2jaVPUwKTFC_iabnDd_qDV=ZubMqhz-X9XiZzzJow@mail.gmail.com>
 <4ba80e1e-8fec-4fd2-9140-6da006c9d5f5@linaro.org>
Message-ID: <CAPLW+4mm8LG=wtJHT5EYhGGiU72qVe70vJv6-JkEGepiXFjcvA@mail.gmail.com>

On Tue, Dec 19, 2023 at 10:47?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> Hi, Sam!
>
> On 12/14/23 16:43, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 10:15?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>
> >>
> >>
> >> On 12/14/23 16:09, Sam Protsenko wrote:
> >>> On Thu, Dec 14, 2023 at 10:01?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 12/14/23 15:37, Sam Protsenko wrote:
> >>>>> On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>>>>>
> >>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >>>>>> which then makes the system hang. To prevent this, mark
> >>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >>>>>> accordingly when tested.
> >>>>>>
> >>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> >>>>>> ---
> >>>>>>  drivers/clk/samsung/clk-gs101.c | 2 +-
> >>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >>>>>> index 3d194520b05e..08d80fca9cd6 100644
> >>>>>> --- a/drivers/clk/samsung/clk-gs101.c
> >>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
> >>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>>>>>              "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>>>>>              21, 0, 0),
> >>>>>>         GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >>>>>> -            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >>>>>> +            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >>>>>
> >>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> >>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
> >>>>> usually should be avoided. Is it possible that the system freezes
> >>>>> because some other clock (which depends on peric0_ip) gets disabled as
> >>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> >>>>> is not implemented yet in the clock driver? Just looks weird to me
> >>>>> that the system hangs because of CMU IP clock disablement. It's
> >>>>> usually something much more specific.
> >>>>
> >>>> The system hang happened when I tested USI8 in I2C configuration with an
> >>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> >>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> >>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> >>>> disablement which makes the system hang. Either marking the CMU_TOP gate
> >>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
> >>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
> >>>>
> >>>
> >>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
> >>
> >> yes.
>
> I checked again all the clocks. I implemented all but one, the one
> defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
> don't have any reference on how it should be defined so I won't touch it
> yet. But I have some good news too, see below.
>
> >
> > Ok. Are there any other CMUs (perhaps not implemented yet) which
> > consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
> > clocks derived from it? If so, is there a chance some particular leaf
> > clock in those CMUs actually renders the system frozen when disabled
> > as a consequence of disabling PERIC0_IP, and would explain better why
> > the freeze happens?
> >
> > For now I think it's ok to have that CLK_IS_CRITICAL flag here,
> > because as you said you implemented all clocks in this CMU and neither
> > of those looks like a critical one. But I'd advice to add a TODO
> > comment saying it's probably a temporary solution before actual leaf
> > clock which leads to freeze is identified (which probably resides in
> > some other not implemented yet CMU).
> >
> >>
> >>> is a chance some other leaf clock (which is not implemented yet in
> >>> your driver) gets disabled as a result of PERIC0_IP disablement, which
> >>> might actually lead to that hang you observe. Usually it's some
> >>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> >>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> >>> and the corresponding comments I left there, maybe it'll give you more
> >>> particular idea about what to look for. Yes, making the whole CMU
> >>> always running without understanding why (i.e. because of which
> >>> particular leaf clock) might not be the best way of handling this
> >>
> >> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
> >
> > That's not a root cause here. And I think PERIC0_IP is neither.
> >
>
> you were right!
> >>
> >>> issue. I might be mistaken, but at least please check if you
> >>> implemented all clocks for PERIC0 first and if making some meaningful
> >>> leaf clock critical makes more sense.
> >>>
>
> I determined which leaf clocks shall be marked as critical. I enabled
> the debugfs clock write access. Then I made sure that the parents of the
> PERIC0 CMU have at least one user so that they don't get disabled after
> an enable-disable sequence on a leaf clock. The I took all the PERIC0
> gate clocks and enabled and disabled them one by one. Whichever hang the
> system when the clock was disabled was marked as critical. The list of
> critical leaf clocks is as following:
>

Nice! I used somehow similar procedure for clk-exynos850, doing
basically the same thing, but in core clock driver code.

> "gout_peric0_peric0_cmu_peric0_pclk",
> "gout_peric0_lhm_axi_p_peric0_i_clk",
> "gout_peric0_peric0_top1_ipclk_0",
> "gout_peric0_peric0_top1_pclk_0".
>
> I'll update v2 with this instead. Thanks for the help, Sam!

Glad you weren't discouraged by my meticulousness :) In clk-exynos850
I usually used CLK_IGNORE_UNUSED for clocks like XXX_CMU_XXX (in your
case it's PERIC0_CMU_PERIC0), with a corresponding comment. Those
clocks usually can be used to disable the bus clock for corresponding
CMU IP-core (in your case CMU_PERIC0), which makes it impossible to
access the registers from that CMU block, as its register interface is
not clocked anymore. Guess I saw something similar in Exynos5433 or
Exynos7 clk drivers, or maybe Sylwester or Krzysztof told me to do so
-- don't really remember. For AXI clock it also seems logical to keep
it running (AXI bus might be used for GIC and memory). But again,
maybe CLK_IGNORE_UNUSED flag would be more appropriate that
CLK_IS_CRITICAL? For the last two clocks -- it's hard to tell what
exactly they do. Is TOP1 some other CMU or block name, and is there
any further users for those clocks?

Anyways, if you are working on v2, please consider doing next two
things while at it:

  1. For each critical clock: add corresponding comment explaining why
it's marked so
  2. Consider using CLK_IGNORE_UNUSED instead of CLK_IS_CRITICAL when
appropriate; both have their use in different cases

Btw, if you check other Exynos clk drivers, there is a lot of examples
for flags like those.

> Cheers,
> ta


From u.kleine-koenig at pengutronix.de  Tue Dec 19 09:32:10 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 19 Dec 2023 18:32:10 +0100
Subject: [PATCH 12/13] fpga: xilinx-pr-decoupler: Convert to platform remove callback returning void
In-Reply-To: <cover.1703006638.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703006638.git.u.kleine-koenig@pengutronix.de>
Message-ID: <3e37e7cf91749fbaba67619f4ffc6a9a7352a671.1703006638.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/fpga/xilinx-pr-decoupler.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/fpga/xilinx-pr-decoupler.c b/drivers/fpga/xilinx-pr-decoupler.c
index 68835896f180..788dd2f63a65 100644
--- a/drivers/fpga/xilinx-pr-decoupler.c
+++ b/drivers/fpga/xilinx-pr-decoupler.c
@@ -150,7 +150,7 @@ static int xlnx_pr_decoupler_probe(struct platform_device *pdev)
 	return err;
 }
 
-static int xlnx_pr_decoupler_remove(struct platform_device *pdev)
+static void xlnx_pr_decoupler_remove(struct platform_device *pdev)
 {
 	struct fpga_bridge *bridge = platform_get_drvdata(pdev);
 	struct xlnx_pr_decoupler_data *p = bridge->priv;
@@ -158,13 +158,11 @@ static int xlnx_pr_decoupler_remove(struct platform_device *pdev)
 	fpga_bridge_unregister(bridge);
 
 	clk_unprepare(p->clk);
-
-	return 0;
 }
 
 static struct platform_driver xlnx_pr_decoupler_driver = {
 	.probe = xlnx_pr_decoupler_probe,
-	.remove = xlnx_pr_decoupler_remove,
+	.remove_new = xlnx_pr_decoupler_remove,
 	.driver = {
 		.name = "xlnx_pr_decoupler",
 		.of_match_table = xlnx_pr_decoupler_of_match,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Tue Dec 19 09:32:11 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 19 Dec 2023 18:32:11 +0100
Subject: [PATCH 13/13] fpga: zynq-fpga: Convert to platform remove callback returning void
In-Reply-To: <cover.1703006638.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703006638.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e63d4155f96f3504f7e3d6a4775c3807c90dd6ce.1703006638.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/fpga/zynq-fpga.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
index 96611d424a10..0ac93183d201 100644
--- a/drivers/fpga/zynq-fpga.c
+++ b/drivers/fpga/zynq-fpga.c
@@ -618,7 +618,7 @@ static int zynq_fpga_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int zynq_fpga_remove(struct platform_device *pdev)
+static void zynq_fpga_remove(struct platform_device *pdev)
 {
 	struct zynq_fpga_priv *priv;
 	struct fpga_manager *mgr;
@@ -629,8 +629,6 @@ static int zynq_fpga_remove(struct platform_device *pdev)
 	fpga_mgr_unregister(mgr);
 
 	clk_unprepare(priv->clk);
-
-	return 0;
 }
 
 #ifdef CONFIG_OF
@@ -644,7 +642,7 @@ MODULE_DEVICE_TABLE(of, zynq_fpga_of_match);
 
 static struct platform_driver zynq_fpga_driver = {
 	.probe = zynq_fpga_probe,
-	.remove = zynq_fpga_remove,
+	.remove_new = zynq_fpga_remove,
 	.driver = {
 		.name = "zynq_fpga_manager",
 		.of_match_table = of_match_ptr(zynq_fpga_of_match),
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Tue Dec 19 09:31:58 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 19 Dec 2023 18:31:58 +0100
Subject: [PATCH 00/13] fpga: Convert to platform remove callback returning void
Message-ID: <cover.1703006638.git.u.kleine-koenig@pengutronix.de>

Hello,

this series converts all drivers below drivers/fpga to use
.remove_new(). See commit 5c5a7680e67b ("platform: Provide a remove
callback that returns no value") for an extended explanation and the
eventual goal. The TL;DR; is to make it harder for driver authors to
leak resources without noticing.

This is merge window material. All patches are pairwise independent of
each other, so they could be applied individually. Getting them all in
together would be nicer though :-)

Best regards
Uwe

Uwe Kleine-K?nig (13):
  fpga: altera-fpga2sdram: Convert to platform remove callback returning void
  fpga: altera-freeze-bridge: Convert to platform remove callback returning void
  fpga: altera-hps2fpga: Convert to platform remove callback returning void
  fpga: dfl-afu-main: Convert to platform remove callback returning void
  fpga: dfl-fme-br: Convert to platform remove callback returning void
  fpga: dfl-fme-main: Convert to platform remove callback returning void
  fpga: dfl-fme-region: Convert to platform remove callback returning void
  fpga: intel-m10-bmc-sec-update: Convert to platform remove callback returning void
  fpga: of-fpga-region: Convert to platform remove callback returning void
  fpga: socfpga-a10: Convert to platform remove callback returning void
  fpga: stratix10-soc: Convert to platform remove callback returning void
  fpga: xilinx-pr-decoupler: Convert to platform remove callback returning void
  fpga: zynq-fpga: Convert to platform remove callback returning void

 drivers/fpga/altera-fpga2sdram.c        | 6 ++----
 drivers/fpga/altera-freeze-bridge.c     | 6 ++----
 drivers/fpga/altera-hps2fpga.c          | 6 ++----
 drivers/fpga/dfl-afu-main.c             | 6 ++----
 drivers/fpga/dfl-fme-br.c               | 6 ++----
 drivers/fpga/dfl-fme-main.c             | 6 ++----
 drivers/fpga/dfl-fme-region.c           | 6 ++----
 drivers/fpga/intel-m10-bmc-sec-update.c | 6 ++----
 drivers/fpga/of-fpga-region.c           | 6 ++----
 drivers/fpga/socfpga-a10.c              | 6 ++----
 drivers/fpga/stratix10-soc.c            | 6 ++----
 drivers/fpga/xilinx-pr-decoupler.c      | 6 ++----
 drivers/fpga/zynq-fpga.c                | 6 ++----
 13 files changed, 26 insertions(+), 52 deletions(-)

base-commit: aa4db8324c4d0e67aa4670356df4e9fae14b4d37
-- 
2.42.0



From jernej.skrabec at gmail.com  Tue Dec 19 09:34:40 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Tue, 19 Dec 2023 18:34:40 +0100
Subject: [PATCH 2/2] arm64: dts: allwinner: h618: add BananaPi M4 Berry board
In-Reply-To: <20231217232405.302-3-andre.przywara@arm.com>
References: <20231217232405.302-1-andre.przywara@arm.com>
 <20231217232405.302-3-andre.przywara@arm.com>
Message-ID: <3197387.5fSG56mABF@jernej-laptop>

Hi Andre!

Dne ponedeljek, 18. december 2023 ob 00:24:05 CET je Andre Przywara napisal(a):
> The BananaPi M4 Berry is a development board using the Allwinner H618
> SoC. It comes with the following specs:
> 	- Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache)
> 	- 2 GiB LPDDR4 DRAM
> 	- 8 GiB eMMC flash
> 	- AXP313a PMIC
> 	- Gigabit Ethernet, using RTL8211 PHY
> 	- RTL8821CU USB WiFi chip
> 	- HDMI port
> 	- 4 * USB 2.0 ports, via an on-board hub chip
> 	- microSD card slot
> 	- 3.5mm A/V port
> 	- power supply and USB-OTG via USB-C connector
> 
> Add a devicetree file describing the components that we already have
> bindings for, that excludes audio and video at the moment.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>  .../sun50i-h618-bananapi-m4-berry.dts         | 229 ++++++++++++++++++
>  2 files changed, 230 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 91d505b385de5..ed016688bb56f 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -42,5 +42,6 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-bananapi-m4-berry.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero3.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-transpeed-8k618-t.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts
> new file mode 100644
> index 0000000000000..11d893a767d4e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts
> @@ -0,0 +1,229 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2023 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> +	model = "BananaPi M4 Berry";
> +	compatible = "sinovoip,bananapi-m4-berry", "allwinner,sun50i-h618";
> +
> +	aliases {
> +		ethernet0 = &emac0;
> +		serial0 = &uart0;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led-0 {
> +			function = LED_FUNCTION_STATUS;
> +			color = <LED_COLOR_ID_GREEN>;
> +			gpios = <&pio 2 12 GPIO_ACTIVE_LOW>; /* PC12 */
> +		};
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		key-sw4 {

"key-sw3"

> +			label = "sw3";
> +			linux,code = <BTN_0>;
> +			gpios = <&pio 2 7 GPIO_ACTIVE_LOW>;	/* PC7 */
> +		};
> +	};
> +
> +	reg_vcc5v: vcc5v {
> +		/* board wide 5V supply directly from the USB-C socket */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-5v";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-always-on;
> +	};
> +
> +	reg_usb_vbus: regulator-usb-vbus {
> +		/* separate discrete regulator for the USB ports */
> +		compatible = "regulator-fixed";
> +		regulator-name = "usb-vbus";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&reg_vcc5v>;
> +	};
> +
> +	reg_3v3: regulator-3v3 {
> +		/* separate discrete regulator for WiFi and Ethernet PHY */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-3v3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&reg_vcc5v>;
> +	};
> +};
> +
> +&cpu0 {
> +	cpu-supply = <&reg_dcdc2>;
> +};
> +
> +/* Connected to an on-board RTL8821CU USB WiFi chip. */
> +&ehci1 {
> +	status = "okay";
> +};
> +
> +/* on unpopulated pins */
> +&ehci2 {
> +	status = "disabled";
> +};

Just drop above node. I get that it's for documenting purposes, but user need
to use DT overlay in any case.

> +
> +/* Connected to an on-board FE1.1s USB hub chip, supplying 4 USB-A ports. */
> +&ehci3 {
> +	status = "okay";
> +};
> +
> +&emac0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ext_rgmii_pins>;
> +	phy-mode = "rgmii";
> +	phy-handle = <&ext_rgmii_phy>;
> +	phy-supply = <&reg_3v3>;
> +	allwinner,rx-delay-ps = <3100>;
> +	allwinner,tx-delay-ps = <700>;
> +	status = "okay";
> +};
> +
> +&ir {
> +	status = "okay";
> +};
> +
> +&mdio0 {
> +	ext_rgmii_phy: ethernet-phy at 1 {
> +		compatible = "ethernet-phy-ieee802.3-c22";
> +		reg = <1>;
> +		reset-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>;	/* PI16 */
> +	};
> +};
> +
> +&mmc0 {
> +	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;	/* PF6 */
> +	vmmc-supply = <&reg_dldo1>;
> +	bus-width = <4>;
> +	status = "okay";
> +};
> +
> +&mmc2 {
> +	vmmc-supply = <&reg_dldo1>;
> +	vqmmc-supply = <&reg_aldo1>;
> +	bus-width = <8>;
> +	non-removable;
> +	cap-mmc-hw-reset;
> +	mmc-ddr-1_8v;
> +	mmc-hs200-1_8v;
> +	status = "okay";
> +};
> +
> +/* USB ports 1 and 3 connect to onboard devices that are high-speed only. */
> +
> +/* on unpopulated pins */
> +&ohci2 {
> +	status = "disabled";
> +};

Ditto.

Best regards,
Jernej

> +
> +&pio {
> +	vcc-pc-supply = <&reg_aldo1>;
> +	vcc-pf-supply = <&reg_dldo1>;
> +	vcc-pg-supply = <&reg_dldo1>;
> +	vcc-ph-supply = <&reg_dldo1>;
> +	vcc-pi-supply = <&reg_dldo1>;
> +};
> +
> +&r_i2c {
> +	status = "okay";
> +
> +	axp313: pmic at 36 {
> +		compatible = "x-powers,axp313a";
> +		reg = <0x36>;
> +		#interrupt-cells = <1>;
> +		interrupt-controller;
> +		interrupt-parent = <&pio>;
> +
> +		vin1-supply = <&reg_vcc5v>;
> +		vin2-supply = <&reg_vcc5v>;
> +		vin3-supply = <&reg_vcc5v>;
> +
> +		regulators {
> +			reg_aldo1: aldo1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc-1v8-pll";
> +			};
> +
> +			reg_dldo1: dldo1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vcc-3v3-io";
> +			};
> +
> +			reg_dcdc1: dcdc1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <810000>;
> +				regulator-max-microvolt = <990000>;
> +				regulator-name = "vdd-gpu-sys";
> +			};
> +
> +			reg_dcdc2: dcdc2 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <810000>;
> +				regulator-max-microvolt = <1100000>;
> +				regulator-name = "vdd-cpu";
> +			};
> +
> +			reg_dcdc3: dcdc3 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <1100000>;
> +				regulator-max-microvolt = <1100000>;
> +				regulator-name = "vdd-dram";
> +			};
> +		};
> +	};
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_ph_pins>;
> +	status = "okay";
> +};
> +
> +&usbotg {
> +	/*
> +	 * PHY0 pins are connected to a USB-C socket, but a role switch is not
> +	 * implemented: both CC pins are pulled to GND via a 5.1K resistor.
> +	 * The VBUS pins power the device, so a fixed peripheral mode
> +	 * is the best choice.
> +	 * The board can be powered via GPIOs, in this case port0 *can*
> +	 * act as a host (with a cable/adapter ignoring CC), as VBUS is
> +	 * then provided by the GPIOs. Any user of this setup would
> +	 * need to adjust the DT accordingly: dr_mode set to "host",
> +	 * enabling OHCI0 and EHCI0.
> +	 */
> +	dr_mode = "peripheral";
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	usb3_vbus-supply = <&reg_usb_vbus>;
> +	status = "okay";
> +};
> 






From twoerner at gmail.com  Tue Dec 19 09:38:13 2023
From: twoerner at gmail.com (Trevor Woerner)
Date: Tue, 19 Dec 2023 12:38:13 -0500
Subject: [PATCH] arm64: dts: rockchip: rk3308-rock-pi-s cleanup
Message-ID: <20231219173814.1569-1-twoerner@gmail.com>

Perform the following cleanups on a previous patch:
- indent lines after "gpio-line-names"
- fix D0-D8 -> D0-D7
- sort phandle references

Fixes: c45de75d7a9a ("arm64: dts: rockchip: add gpio-line-names to rk3308-rock-pi-s")
Signed-off-by: Trevor Woerner <twoerner at gmail.com>
---
 .../boot/dts/rockchip/rk3308-rock-pi-s.dts    | 120 +++++++++---------
 1 file changed, 62 insertions(+), 58 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts b/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts
index f2d7251de298..b47fe02c33fb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3308-rock-pi-s.dts
@@ -143,6 +143,68 @@ &gmac {
 	status = "okay";
 };
 
+&gpio0 {
+	gpio-line-names =
+		/* GPIO0_A0 - A7 */
+		"", "", "", "", "", "", "", "",
+		/* GPIO0_B0 - B7 */
+		"", "", "", "header1-pin3 [GPIO0_B3]",
+		"header1-pin5 [GPIO0_B4]", "", "",
+		"header1-pin11 [GPIO0_B7]",
+		/* GPIO0_C0 - C7 */
+		"header1-pin13 [GPIO0_C0]",
+		"header1-pin15 [GPIO0_C1]", "", "", "",
+		"", "", "",
+		/* GPIO0_D0 - D7 */
+		"", "", "", "", "", "", "", "";
+};
+
+&gpio1 {
+	gpio-line-names =
+		/* GPIO1_A0 - A7 */
+		"", "", "", "", "", "", "", "",
+		/* GPIO1_B0 - B7 */
+		"", "", "", "", "", "", "", "",
+		/* GPIO1_C0 - C7 */
+		"", "", "", "", "", "", "header1-pin21 [GPIO1_C6]",
+		"header1-pin19 [GPIO1_C7]",
+		/* GPIO1_D0 - D7 */
+		"header1-pin23 [GPIO1_D0]", "header1-pin24 [GPIO1_D1]",
+		"", "", "", "", "", "";
+};
+
+&gpio2 {
+	gpio-line-names =
+		/* GPIO2_A0 - A7 */
+		"header1-pin10 [GPIO2_A0]", "header1-pin8 [GPIO2_A1]",
+		"", "",
+		"header1-pin7 [GPIO2_A4]", "header1-pin12 [GPIO2_A5]",
+		"header2-pin46 [GPIO2_A6]", "header1-pin22 [GPIO1_A7]",
+		/* GPIO2_B0 - B7 */
+		"header2-pin45 [GPIO2_B0]", "header1-pin18 [GPIO2_B1]",
+		"header1-pin16 [GPIO2_B2]", "header2-pin44 [GPIO2_B3]",
+		"header2-pin43 [GPIO2_B4]", "header2-pin28 [GPIO2_B5]",
+		"header2-pin30 [GPIO2_B6]", "header2-pin32 [GPIO2_B7]",
+		/* GPIO2_C0 - C7 */
+		"header2-pin34 [GPIO2_C0]", "", "", "", "", "", "", "",
+		/* GPIO2_D0 - D7 */
+		"", "", "", "", "", "", "", "";
+};
+
+&gpio3 {
+	gpio-line-names =
+		/* GPIO3_A0 - A7 */
+		"", "", "", "", "", "", "", "",
+		/* GPIO3_B0 - B7 */
+		"", "", "header2-pin42 [GPIO3_B2]",
+		"header2-pin41 [GPIO3_B3]", "header2-pin40 [GPIO3_B4]",
+		"header2-pin39 [GPIO3_B5]", "", "",
+		/* GPIO3_C0 - C7 */
+		"", "", "", "", "", "", "", "",
+		/* GPIO3_D0 - D7 */
+		"", "", "", "", "", "", "", "";
+};
+
 &i2c1 {
 	status = "okay";
 };
@@ -250,61 +312,3 @@ &usb20_otg {
 &wdt {
 	status = "okay";
 };
-
-&gpio0 {
-	gpio-line-names =
-	/* GPIO0_A0 - A7 */
-	"", "", "", "", "", "", "", "",
-	/* GPIO0_B0 - B7 */
-	"", "", "", "header1-pin3 [GPIO0_B3]", "header1-pin5 [GPIO0_B4]",
-	"", "", "header1-pin11 [GPIO0_B7]",
-	/* GPIO0_C0 - C7 */
-	"header1-pin13 [GPIO0_C0]", "header1-pin15 [GPIO0_C1]", "", "", "",
-	"", "", "",
-	/* GPIO0_D0 - D8 */
-	"", "", "", "", "", "", "", "";
-};
-
-&gpio1 {
-	gpio-line-names =
-	/* GPIO1_A0 - A7 */
-	"", "", "", "", "", "", "", "",
-	/* GPIO1_B0 - B7 */
-	"", "", "", "", "", "", "", "",
-	/* GPIO1_C0 - C7 */
-	"", "", "", "", "", "", "header1-pin21 [GPIO1_C6]",
-	"header1-pin19 [GPIO1_C7]",
-	/* GPIO1_D0 - D8 */
-	"header1-pin23 [GPIO1_D0]", "header1-pin24 [GPIO1_D1]", "", "", "",
-	"", "", "";
-};
-
-&gpio2 {
-	gpio-line-names =
-	/* GPIO2_A0 - A7 */
-	"header1-pin10 [GPIO2_A0]", "header1-pin8 [GPIO2_A1]", "", "",
-	"header1-pin7 [GPIO2_A4]", "header1-pin12 [GPIO2_A5]",
-	"header2-pin46 [GPIO2_A6]", "header1-pin22 [GPIO1_A7]",
-	/* GPIO2_B0 - B7 */
-	"header2-pin45 [GPIO2_B0]", "header1-pin18 [GPIO2_B1]",
-	"header1-pin16 [GPIO2_B2]", "header2-pin44 [GPIO2_B3]",
-	"header2-pin43 [GPIO2_B4]", "header2-pin28 [GPIO2_B5]",
-	"header2-pin30 [GPIO2_B6]", "header2-pin32 [GPIO2_B7]",
-	/* GPIO2_C0 - C7 */
-	"header2-pin34 [GPIO2_C0]", "", "", "", "", "", "", "",
-	/* GPIO2_D0 - D8 */
-	"", "", "", "", "", "", "", "";
-};
-
-&gpio3 {
-	gpio-line-names =
-	/* GPIO3_A0 - A7 */
-	"", "", "", "", "", "", "", "",
-	/* GPIO3_B0 - B7 */
-	"", "", "header2-pin42 [GPIO3_B2]", "header2-pin41 [GPIO3_B3]",
-	"header2-pin40 [GPIO3_B4]", "header2-pin39 [GPIO3_B5]", "", "",
-	/* GPIO3_C0 - C7 */
-	"", "", "", "", "", "", "", "",
-	/* GPIO3_D0 - D8 */
-	"", "", "", "", "", "", "", "";
-};
-- 
2.43.0.76.g1a87c842ece3



From zajec5 at gmail.com  Tue Dec 19 09:40:21 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Tue, 19 Dec 2023 18:40:21 +0100
Subject: [PATCH V2 1/5] dt-bindings: nvmem: layouts: add U-Boot environment variables layout
Message-ID: <20231219174025.15228-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various storage devices. Its binding should
be an NVMEM layout instead of a standalone device.

This patch adds layout binding which allows using it on top of MTD NVMEM
device as well as any other. At the same time it deprecates the old
combined binding.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
V2: Add "-layout" suffix to compatibles to avoid conflict

 .../nvmem/layouts/u-boot,env-layout.yaml      | 55 +++++++++++++++++++
 .../devicetree/bindings/nvmem/u-boot,env.yaml |  6 ++
 2 files changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/u-boot,env-layout.yaml

diff --git a/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env-layout.yaml
new file mode 100644
index 000000000000..3b4d8f2a44e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env-layout.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env-layout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of U-Boot environment variables
+
+maintainers:
+  - Rafa? Mi?ecki <rafal at milecki.pl>
+
+description:
+  U-Boot uses environment variables to store device parameters and
+  configuration. They may be used for booting process, setup or keeping end user
+  info.
+
+  Data is stored using U-Boot specific formats (variant specific header and NUL
+  separated key-value pairs).
+
+properties:
+  compatible:
+    oneOf:
+      - description: A standalone env data block
+        const: u-boot,env-layout
+      - description: Two redundant blocks with active one flagged
+        const: u-boot,env-redundant-bool-layout
+      - description: Two redundant blocks with active having higher counter
+        const: u-boot,env-redundant-count-layout
+      - description: Broadcom's variant with custom header
+        const: brcm,env-layout
+
+additionalProperties: false
+
+examples:
+  - |
+    partitions {
+        compatible = "fixed-partitions";
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        partition at 0 {
+            reg = <0x0 0x40000>;
+            label = "u-boot";
+            read-only;
+        };
+
+        partition at 40000 {
+            reg = <0x40000 0x10000>;
+            label = "u-boot-env";
+
+            nvmem-layout {
+                compatible = "u-boot,env-layout";
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
index 9c36afc7084b..6c2a3ca5f051 100644
--- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
@@ -26,9 +26,15 @@ description: |
 
   Variables can be defined as NVMEM device subnodes.
 
+  Introduction of NVMEM layouts exposed a limitation of this binding design.
+  Description of NVMEM data content should be separated from NVMEM devices.
+  Since the introduction of U-Boot env data layout this binding is deprecated.
+
 maintainers:
   - Rafa? Mi?ecki <rafal at milecki.pl>
 
+deprecated: true
+
 properties:
   compatible:
     oneOf:
-- 
2.35.3



From zajec5 at gmail.com  Tue Dec 19 09:40:22 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Tue, 19 Dec 2023 18:40:22 +0100
Subject: [PATCH V2 2/5] nvmem: core: add nvmem_dev_size() helper
In-Reply-To: <20231219174025.15228-1-zajec5@gmail.com>
References: <20231219174025.15228-1-zajec5@gmail.com>
Message-ID: <20231219174025.15228-2-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This is required by layouts that need to read whole NVMEM content. It's
especially useful for NVMEM devices without hardcoded layout (like
U-Boot environment data block).

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
 drivers/nvmem/core.c           | 13 +++++++++++++
 include/linux/nvmem-consumer.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 4ed54076346d..980123fb4dde 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -2163,6 +2163,19 @@ const char *nvmem_dev_name(struct nvmem_device *nvmem)
 }
 EXPORT_SYMBOL_GPL(nvmem_dev_name);
 
+/**
+ * nvmem_dev_size() - Get the size of a given nvmem device.
+ *
+ * @nvmem: nvmem device.
+ *
+ * Return: size of the nvmem device.
+ */
+size_t nvmem_dev_size(struct nvmem_device *nvmem)
+{
+	return nvmem->size;
+}
+EXPORT_SYMBOL_GPL(nvmem_dev_size);
+
 static int __init nvmem_init(void)
 {
 	int ret;
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 2d306fa13b1a..34c0e58dfa26 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -81,6 +81,7 @@ int nvmem_device_cell_write(struct nvmem_device *nvmem,
 			    struct nvmem_cell_info *info, void *buf);
 
 const char *nvmem_dev_name(struct nvmem_device *nvmem);
+size_t nvmem_dev_size(struct nvmem_device *nvmem);
 
 void nvmem_add_cell_lookups(struct nvmem_cell_lookup *entries,
 			    size_t nentries);
-- 
2.35.3



From zajec5 at gmail.com  Tue Dec 19 09:40:24 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Tue, 19 Dec 2023 18:40:24 +0100
Subject: [PATCH V2 4/5] nvmem: u-boot-env: improve coding style
In-Reply-To: <20231219174025.15228-1-zajec5@gmail.com>
References: <20231219174025.15228-1-zajec5@gmail.com>
Message-ID: <20231219174025.15228-4-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

1. Prefer kzalloc() over kcalloc()
   See memory-allocation.rst which says: "to be on the safe side it's
   best to use routines that set memory to zero, like kzalloc()"
2. Drop dev_err() for u_boot_env_add_cells() fail
   It can fail only on -ENOMEM. We don't want to print error then.
3. Add extra "crc32_addr" variable
   It makes code reading header's crc32 easier to understand / review.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
V2: New patch with suggestions from Miquel

 drivers/nvmem/u-boot-env.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index 111905189341..befbab156cda 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -132,6 +132,7 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 	size_t crc32_data_offset;
 	size_t crc32_data_len;
 	size_t crc32_offset;
+	__le32 *crc32_addr;
 	size_t data_offset;
 	size_t data_len;
 	size_t dev_size;
@@ -143,7 +144,7 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 
 	dev_size = nvmem_dev_size(nvmem);
 
-	buf = kcalloc(1, dev_size, GFP_KERNEL);
+	buf = kzalloc(dev_size, GFP_KERNEL);
 	if (!buf) {
 		err = -ENOMEM;
 		goto err_out;
@@ -175,7 +176,8 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
 		break;
 	}
-	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
+	crc32_addr = (__le32 *)(buf + crc32_offset);
+	crc32 = le32_to_cpu(*crc32_addr);
 	crc32_data_len = dev_size - crc32_data_offset;
 	data_len = dev_size - data_offset;
 
@@ -188,8 +190,6 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 
 	buf[dev_size - 1] = '\0';
 	err = u_boot_env_add_cells(priv, buf, data_offset, data_len);
-	if (err)
-		dev_err(dev, "Failed to add cells: %d\n", err);
 
 err_kfree:
 	kfree(buf);
-- 
2.35.3



From zajec5 at gmail.com  Tue Dec 19 09:40:23 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Tue, 19 Dec 2023 18:40:23 +0100
Subject: [PATCH V2 3/5] nvmem: u-boot-env: use more nvmem subsystem helpers
In-Reply-To: <20231219174025.15228-1-zajec5@gmail.com>
References: <20231219174025.15228-1-zajec5@gmail.com>
Message-ID: <20231219174025.15228-3-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
   mtd dependent
2. Use nvmem_add_one_cell() to simplify adding NVMEM cells

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
V2: Don't introduce memleak when handling nvmem_device_read() failures

 drivers/nvmem/u-boot-env.c | 78 ++++++++++++++++++--------------------
 1 file changed, 36 insertions(+), 42 deletions(-)

diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index c4ae94af4af7..111905189341 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -23,13 +23,10 @@ enum u_boot_env_format {
 
 struct u_boot_env {
 	struct device *dev;
+	struct nvmem_device *nvmem;
 	enum u_boot_env_format format;
 
 	struct mtd_info *mtd;
-
-	/* Cells */
-	struct nvmem_cell_info *cells;
-	int ncells;
 };
 
 struct u_boot_env_image_single {
@@ -94,70 +91,70 @@ static int u_boot_env_read_post_process_ethaddr(void *context, const char *id, i
 static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
 				size_t data_offset, size_t data_len)
 {
+	struct nvmem_device *nvmem = priv->nvmem;
 	struct device *dev = priv->dev;
 	char *data = buf + data_offset;
 	char *var, *value, *eq;
-	int idx;
-
-	priv->ncells = 0;
-	for (var = data; var < data + data_len && *var; var += strlen(var) + 1)
-		priv->ncells++;
-
-	priv->cells = devm_kcalloc(dev, priv->ncells, sizeof(*priv->cells), GFP_KERNEL);
-	if (!priv->cells)
-		return -ENOMEM;
 
-	for (var = data, idx = 0;
+	for (var = data;
 	     var < data + data_len && *var;
-	     var = value + strlen(value) + 1, idx++) {
+	     var = value + strlen(value) + 1) {
+		struct nvmem_cell_info info = {};
+
 		eq = strchr(var, '=');
 		if (!eq)
 			break;
 		*eq = '\0';
 		value = eq + 1;
 
-		priv->cells[idx].name = devm_kstrdup(dev, var, GFP_KERNEL);
-		if (!priv->cells[idx].name)
+		info.name = devm_kstrdup(dev, var, GFP_KERNEL);
+		if (!info.name)
 			return -ENOMEM;
-		priv->cells[idx].offset = data_offset + value - data;
-		priv->cells[idx].bytes = strlen(value);
-		priv->cells[idx].np = of_get_child_by_name(dev->of_node, priv->cells[idx].name);
+		info.offset = data_offset + value - data;
+		info.bytes = strlen(value);
+		info.np = of_get_child_by_name(dev->of_node, info.name);
 		if (!strcmp(var, "ethaddr")) {
-			priv->cells[idx].raw_len = strlen(value);
-			priv->cells[idx].bytes = ETH_ALEN;
-			priv->cells[idx].read_post_process = u_boot_env_read_post_process_ethaddr;
+			info.raw_len = strlen(value);
+			info.bytes = ETH_ALEN;
+			info.read_post_process = u_boot_env_read_post_process_ethaddr;
 		}
-	}
 
-	if (WARN_ON(idx != priv->ncells))
-		priv->ncells = idx;
+		nvmem_add_one_cell(nvmem, &info);
+	}
 
 	return 0;
 }
 
 static int u_boot_env_parse(struct u_boot_env *priv)
 {
+	struct nvmem_device *nvmem = priv->nvmem;
 	struct device *dev = priv->dev;
 	size_t crc32_data_offset;
 	size_t crc32_data_len;
 	size_t crc32_offset;
 	size_t data_offset;
 	size_t data_len;
+	size_t dev_size;
 	uint32_t crc32;
 	uint32_t calc;
-	size_t bytes;
 	uint8_t *buf;
+	int bytes;
 	int err;
 
-	buf = kcalloc(1, priv->mtd->size, GFP_KERNEL);
+	dev_size = nvmem_dev_size(nvmem);
+
+	buf = kcalloc(1, dev_size, GFP_KERNEL);
 	if (!buf) {
 		err = -ENOMEM;
 		goto err_out;
 	}
 
-	err = mtd_read(priv->mtd, 0, priv->mtd->size, &bytes, buf);
-	if ((err && !mtd_is_bitflip(err)) || bytes != priv->mtd->size) {
-		dev_err(dev, "Failed to read from mtd: %d\n", err);
+	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
+	if (bytes < 0) {
+		err = bytes;
+		goto err_kfree;
+	} else if (bytes != dev_size) {
+		err = -EIO;
 		goto err_kfree;
 	}
 
@@ -179,8 +176,8 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 		break;
 	}
 	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
-	crc32_data_len = priv->mtd->size - crc32_data_offset;
-	data_len = priv->mtd->size - data_offset;
+	crc32_data_len = dev_size - crc32_data_offset;
+	data_len = dev_size - data_offset;
 
 	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
 	if (calc != crc32) {
@@ -189,7 +186,7 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 		goto err_kfree;
 	}
 
-	buf[priv->mtd->size - 1] = '\0';
+	buf[dev_size - 1] = '\0';
 	err = u_boot_env_add_cells(priv, buf, data_offset, data_len);
 	if (err)
 		dev_err(dev, "Failed to add cells: %d\n", err);
@@ -209,7 +206,6 @@ static int u_boot_env_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
 	struct u_boot_env *priv;
-	int err;
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -224,17 +220,15 @@ static int u_boot_env_probe(struct platform_device *pdev)
 		return PTR_ERR(priv->mtd);
 	}
 
-	err = u_boot_env_parse(priv);
-	if (err)
-		return err;
-
 	config.dev = dev;
-	config.cells = priv->cells;
-	config.ncells = priv->ncells;
 	config.priv = priv;
 	config.size = priv->mtd->size;
 
-	return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &config));
+	priv->nvmem = devm_nvmem_register(dev, &config);
+	if (IS_ERR(priv->nvmem))
+		return PTR_ERR(priv->nvmem);
+
+	return u_boot_env_parse(priv);
 }
 
 static const struct of_device_id u_boot_env_of_match_table[] = {
-- 
2.35.3



From zajec5 at gmail.com  Tue Dec 19 09:40:25 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Tue, 19 Dec 2023 18:40:25 +0100
Subject: [PATCH V2 5/5] nvmem: layouts: add U-Boot env layout
In-Reply-To: <20231219174025.15228-1-zajec5@gmail.com>
References: <20231219174025.15228-1-zajec5@gmail.com>
Message-ID: <20231219174025.15228-5-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This patch moves all generic (NVMEM devices independent) code from NVMEM
device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
code on top of it.

Thanks to proper layout it's possible to support U-Boot env data stored
on any kind of NVMEM device.

For backward compatibility with old DT bindings we need to keep old
NVMEM device driver functional. To avoid code duplication a parsing
function is exported and reused in it.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
V2: Support new compatibles & use device_get_match_data() helper

IMPORTANT:
This is based on top of the:
[PATCH v6.8 1/2] nvmem: layouts: refactor .add_cells() callback arguments

 MAINTAINERS                        |   1 +
 drivers/nvmem/Kconfig              |   3 +-
 drivers/nvmem/layouts/Kconfig      |  11 ++
 drivers/nvmem/layouts/Makefile     |   1 +
 drivers/nvmem/layouts/u-boot-env.c | 204 +++++++++++++++++++++++++++++
 drivers/nvmem/layouts/u-boot-env.h |  15 +++
 drivers/nvmem/u-boot-env.c         | 158 +---------------------
 7 files changed, 235 insertions(+), 158 deletions(-)
 create mode 100644 drivers/nvmem/layouts/u-boot-env.c
 create mode 100644 drivers/nvmem/layouts/u-boot-env.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b589218605b4..1f7e6d74cd51 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22282,6 +22282,7 @@ U-BOOT ENVIRONMENT VARIABLES
 M:	Rafa? Mi?ecki <rafal at milecki.pl>
 S:	Maintained
 F:	Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+F:	drivers/nvmem/layouts/u-boot-env.c
 F:	drivers/nvmem/u-boot-env.c
 
 UACCE ACCELERATOR FRAMEWORK
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 283134498fbc..d2c384f58028 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -363,8 +363,7 @@ config NVMEM_SUNXI_SID
 config NVMEM_U_BOOT_ENV
 	tristate "U-Boot environment variables support"
 	depends on OF && MTD
-	select CRC32
-	select GENERIC_NET_UTILS
+	select NVMEM_LAYOUT_U_BOOT_ENV
 	help
 	  U-Boot stores its setup as environment variables. This driver adds
 	  support for verifying & exporting such data. It also exposes variables
diff --git a/drivers/nvmem/layouts/Kconfig b/drivers/nvmem/layouts/Kconfig
index 9c6e672fc350..5e586dfebe47 100644
--- a/drivers/nvmem/layouts/Kconfig
+++ b/drivers/nvmem/layouts/Kconfig
@@ -26,6 +26,17 @@ config NVMEM_LAYOUT_ONIE_TLV
 
 	  If unsure, say N.
 
+config NVMEM_LAYOUT_U_BOOT_ENV
+	tristate "U-Boot environment variables layout"
+	select CRC32
+	select GENERIC_NET_UTILS
+	help
+	  U-Boot stores its setup as environment variables. This driver adds
+	  support for verifying & exporting such data. It also exposes variables
+	  as NVMEM cells so they can be referenced by other drivers.
+
+	  If unsure, say N.
+
 endmenu
 
 endif
diff --git a/drivers/nvmem/layouts/Makefile b/drivers/nvmem/layouts/Makefile
index 2974bd7d33ed..4940c9db0665 100644
--- a/drivers/nvmem/layouts/Makefile
+++ b/drivers/nvmem/layouts/Makefile
@@ -5,3 +5,4 @@
 
 obj-$(CONFIG_NVMEM_LAYOUT_SL28_VPD) += sl28vpd.o
 obj-$(CONFIG_NVMEM_LAYOUT_ONIE_TLV) += onie-tlv.o
+obj-$(CONFIG_NVMEM_LAYOUT_U_BOOT_ENV) += u-boot-env.o
diff --git a/drivers/nvmem/layouts/u-boot-env.c b/drivers/nvmem/layouts/u-boot-env.c
new file mode 100644
index 000000000000..dcd2ffed503c
--- /dev/null
+++ b/drivers/nvmem/layouts/u-boot-env.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 - 2023 Rafa? Mi?ecki <rafal at milecki.pl>
+ */
+
+#include <linux/crc32.h>
+#include <linux/etherdevice.h>
+#include <linux/export.h>
+#include <linux/if_ether.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+#include "u-boot-env.h"
+
+struct u_boot_env_image_single {
+	__le32 crc32;
+	uint8_t data[];
+} __packed;
+
+struct u_boot_env_image_redundant {
+	__le32 crc32;
+	u8 mark;
+	uint8_t data[];
+} __packed;
+
+struct u_boot_env_image_broadcom {
+	__le32 magic;
+	__le32 len;
+	__le32 crc32;
+	DECLARE_FLEX_ARRAY(uint8_t, data);
+} __packed;
+
+static int u_boot_env_read_post_process_ethaddr(void *context, const char *id, int index,
+						unsigned int offset, void *buf, size_t bytes)
+{
+	u8 mac[ETH_ALEN];
+
+	if (bytes != 3 * ETH_ALEN - 1)
+		return -EINVAL;
+
+	if (!mac_pton(buf, mac))
+		return -EINVAL;
+
+	if (index)
+		eth_addr_add(mac, index);
+
+	ether_addr_copy(buf, mac);
+
+	return 0;
+}
+
+static int u_boot_env_parse_cells(struct device *dev, struct nvmem_device *nvmem, uint8_t *buf,
+				  size_t data_offset, size_t data_len)
+{
+	char *data = buf + data_offset;
+	char *var, *value, *eq;
+
+	for (var = data;
+	     var < data + data_len && *var;
+	     var = value + strlen(value) + 1) {
+		struct nvmem_cell_info info = {};
+
+		eq = strchr(var, '=');
+		if (!eq)
+			break;
+		*eq = '\0';
+		value = eq + 1;
+
+		info.name = devm_kstrdup(dev, var, GFP_KERNEL);
+		if (!info.name)
+			return -ENOMEM;
+		info.offset = data_offset + value - data;
+		info.bytes = strlen(value);
+		info.np = of_get_child_by_name(dev->of_node, info.name);
+		if (!strcmp(var, "ethaddr")) {
+			info.raw_len = strlen(value);
+			info.bytes = ETH_ALEN;
+			info.read_post_process = u_boot_env_read_post_process_ethaddr;
+		}
+
+		nvmem_add_one_cell(nvmem, &info);
+	}
+
+	return 0;
+}
+
+int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
+		     enum u_boot_env_format format)
+{
+	size_t crc32_data_offset;
+	size_t crc32_data_len;
+	size_t crc32_offset;
+	__le32 *crc32_addr;
+	size_t data_offset;
+	size_t data_len;
+	size_t dev_size;
+	uint32_t crc32;
+	uint32_t calc;
+	uint8_t *buf;
+	int bytes;
+	int err;
+
+	dev_size = nvmem_dev_size(nvmem);
+
+	buf = kzalloc(dev_size, GFP_KERNEL);
+	if (!buf) {
+		err = -ENOMEM;
+		goto err_out;
+	}
+
+	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
+	if (bytes < 0) {
+		err = bytes;
+		goto err_kfree;
+	} else if (bytes != dev_size) {
+		err = -EIO;
+		goto err_kfree;
+	}
+
+	switch (format) {
+	case U_BOOT_FORMAT_SINGLE:
+		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
+		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
+		data_offset = offsetof(struct u_boot_env_image_single, data);
+		break;
+	case U_BOOT_FORMAT_REDUNDANT:
+		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
+		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
+		data_offset = offsetof(struct u_boot_env_image_redundant, data);
+		break;
+	case U_BOOT_FORMAT_BROADCOM:
+		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
+		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
+		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
+		break;
+	}
+	crc32_addr = (__le32 *)(buf + crc32_offset);
+	crc32 = le32_to_cpu(*crc32_addr);
+	crc32_data_len = dev_size - crc32_data_offset;
+	data_len = dev_size - data_offset;
+
+	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
+	if (calc != crc32) {
+		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
+		err = -EINVAL;
+		goto err_kfree;
+	}
+
+	buf[dev_size - 1] = '\0';
+	err = u_boot_env_parse_cells(dev, nvmem, buf, data_offset, data_len);
+
+err_kfree:
+	kfree(buf);
+err_out:
+	return err;
+}
+EXPORT_SYMBOL_GPL(u_boot_env_parse);
+
+static int u_boot_env_add_cells(struct nvmem_layout *layout)
+{
+	struct device *dev = &layout->dev;
+	enum u_boot_env_format format;
+
+	format = (uintptr_t)device_get_match_data(dev);
+
+	return u_boot_env_parse(dev, layout->nvmem, format);
+}
+
+static int u_boot_env_probe(struct nvmem_layout *layout)
+{
+	layout->add_cells = u_boot_env_add_cells;
+
+	return nvmem_layout_register(layout);
+}
+
+static void u_boot_env_remove(struct nvmem_layout *layout)
+{
+	nvmem_layout_unregister(layout);
+}
+
+static const struct of_device_id u_boot_env_of_match_table[] = {
+	{ .compatible = "u-boot,env-layout", .data = (void *)U_BOOT_FORMAT_SINGLE, },
+	{ .compatible = "u-boot,env-redundant-bool-layout", .data = (void *)U_BOOT_FORMAT_REDUNDANT, },
+	{ .compatible = "u-boot,env-redundant-count-layout", .data = (void *)U_BOOT_FORMAT_REDUNDANT, },
+	{ .compatible = "brcm,env-layout", .data = (void *)U_BOOT_FORMAT_BROADCOM, },
+	{},
+};
+
+static struct nvmem_layout_driver u_boot_env_layout = {
+	.driver = {
+		.owner = THIS_MODULE,
+		.name = "u-boot-env-layout",
+		.of_match_table = u_boot_env_of_match_table,
+	},
+	.probe = u_boot_env_probe,
+	.remove = u_boot_env_remove,
+};
+module_nvmem_layout_driver(u_boot_env_layout);
+
+MODULE_AUTHOR("Rafa? Mi?ecki");
+MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, u_boot_env_of_match_table);
diff --git a/drivers/nvmem/layouts/u-boot-env.h b/drivers/nvmem/layouts/u-boot-env.h
new file mode 100644
index 000000000000..dd5f280ac047
--- /dev/null
+++ b/drivers/nvmem/layouts/u-boot-env.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _LINUX_NVMEM_LAYOUTS_U_BOOT_ENV_H
+#define _LINUX_NVMEM_LAYOUTS_U_BOOT_ENV_H
+
+enum u_boot_env_format {
+	U_BOOT_FORMAT_SINGLE,
+	U_BOOT_FORMAT_REDUNDANT,
+	U_BOOT_FORMAT_BROADCOM,
+};
+
+int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
+		     enum u_boot_env_format format);
+
+#endif  /* ifndef _LINUX_NVMEM_LAYOUTS_U_BOOT_ENV_H */
diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index befbab156cda..386b2b255c30 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -3,23 +3,15 @@
  * Copyright (C) 2022 Rafa? Mi?ecki <rafal at milecki.pl>
  */
 
-#include <linux/crc32.h>
-#include <linux/etherdevice.h>
-#include <linux/if_ether.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/mtd/mtd.h>
-#include <linux/nvmem-consumer.h>
 #include <linux/nvmem-provider.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
-enum u_boot_env_format {
-	U_BOOT_FORMAT_SINGLE,
-	U_BOOT_FORMAT_REDUNDANT,
-	U_BOOT_FORMAT_BROADCOM,
-};
+#include "layouts/u-boot-env.h"
 
 struct u_boot_env {
 	struct device *dev;
@@ -29,24 +21,6 @@ struct u_boot_env {
 	struct mtd_info *mtd;
 };
 
-struct u_boot_env_image_single {
-	__le32 crc32;
-	uint8_t data[];
-} __packed;
-
-struct u_boot_env_image_redundant {
-	__le32 crc32;
-	u8 mark;
-	uint8_t data[];
-} __packed;
-
-struct u_boot_env_image_broadcom {
-	__le32 magic;
-	__le32 len;
-	__le32 crc32;
-	DECLARE_FLEX_ARRAY(uint8_t, data);
-} __packed;
-
 static int u_boot_env_read(void *context, unsigned int offset, void *val,
 			   size_t bytes)
 {
@@ -69,134 +43,6 @@ static int u_boot_env_read(void *context, unsigned int offset, void *val,
 	return 0;
 }
 
-static int u_boot_env_read_post_process_ethaddr(void *context, const char *id, int index,
-						unsigned int offset, void *buf, size_t bytes)
-{
-	u8 mac[ETH_ALEN];
-
-	if (bytes != 3 * ETH_ALEN - 1)
-		return -EINVAL;
-
-	if (!mac_pton(buf, mac))
-		return -EINVAL;
-
-	if (index)
-		eth_addr_add(mac, index);
-
-	ether_addr_copy(buf, mac);
-
-	return 0;
-}
-
-static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
-				size_t data_offset, size_t data_len)
-{
-	struct nvmem_device *nvmem = priv->nvmem;
-	struct device *dev = priv->dev;
-	char *data = buf + data_offset;
-	char *var, *value, *eq;
-
-	for (var = data;
-	     var < data + data_len && *var;
-	     var = value + strlen(value) + 1) {
-		struct nvmem_cell_info info = {};
-
-		eq = strchr(var, '=');
-		if (!eq)
-			break;
-		*eq = '\0';
-		value = eq + 1;
-
-		info.name = devm_kstrdup(dev, var, GFP_KERNEL);
-		if (!info.name)
-			return -ENOMEM;
-		info.offset = data_offset + value - data;
-		info.bytes = strlen(value);
-		info.np = of_get_child_by_name(dev->of_node, info.name);
-		if (!strcmp(var, "ethaddr")) {
-			info.raw_len = strlen(value);
-			info.bytes = ETH_ALEN;
-			info.read_post_process = u_boot_env_read_post_process_ethaddr;
-		}
-
-		nvmem_add_one_cell(nvmem, &info);
-	}
-
-	return 0;
-}
-
-static int u_boot_env_parse(struct u_boot_env *priv)
-{
-	struct nvmem_device *nvmem = priv->nvmem;
-	struct device *dev = priv->dev;
-	size_t crc32_data_offset;
-	size_t crc32_data_len;
-	size_t crc32_offset;
-	__le32 *crc32_addr;
-	size_t data_offset;
-	size_t data_len;
-	size_t dev_size;
-	uint32_t crc32;
-	uint32_t calc;
-	uint8_t *buf;
-	int bytes;
-	int err;
-
-	dev_size = nvmem_dev_size(nvmem);
-
-	buf = kzalloc(dev_size, GFP_KERNEL);
-	if (!buf) {
-		err = -ENOMEM;
-		goto err_out;
-	}
-
-	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
-	if (bytes < 0) {
-		err = bytes;
-		goto err_kfree;
-	} else if (bytes != dev_size) {
-		err = -EIO;
-		goto err_kfree;
-	}
-
-	switch (priv->format) {
-	case U_BOOT_FORMAT_SINGLE:
-		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
-		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
-		data_offset = offsetof(struct u_boot_env_image_single, data);
-		break;
-	case U_BOOT_FORMAT_REDUNDANT:
-		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
-		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
-		data_offset = offsetof(struct u_boot_env_image_redundant, data);
-		break;
-	case U_BOOT_FORMAT_BROADCOM:
-		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
-		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
-		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
-		break;
-	}
-	crc32_addr = (__le32 *)(buf + crc32_offset);
-	crc32 = le32_to_cpu(*crc32_addr);
-	crc32_data_len = dev_size - crc32_data_offset;
-	data_len = dev_size - data_offset;
-
-	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
-	if (calc != crc32) {
-		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
-		err = -EINVAL;
-		goto err_kfree;
-	}
-
-	buf[dev_size - 1] = '\0';
-	err = u_boot_env_add_cells(priv, buf, data_offset, data_len);
-
-err_kfree:
-	kfree(buf);
-err_out:
-	return err;
-}
-
 static int u_boot_env_probe(struct platform_device *pdev)
 {
 	struct nvmem_config config = {
@@ -228,7 +74,7 @@ static int u_boot_env_probe(struct platform_device *pdev)
 	if (IS_ERR(priv->nvmem))
 		return PTR_ERR(priv->nvmem);
 
-	return u_boot_env_parse(priv);
+	return u_boot_env_parse(dev, priv->nvmem, priv->format);
 }
 
 static const struct of_device_id u_boot_env_of_match_table[] = {
-- 
2.35.3



From cki-project at redhat.com  Tue Dec 19 09:41:10 2023
From: cki-project at redhat.com (cki-project at redhat.com)
Date: Tue, 19 Dec 2023 17:41:10 -0000
Subject: =?utf-8?b?4pyF?= PASS: Test report for for-kernelci (6.7.0-rc6,
 arm-next, aafe7ad7)
Message-ID: <14135.123121912411100425@us-mta-546.us.mimecast.lan>

Hi, we tested your kernel and here are the results:

    Overall result: PASSED
             Merge: OK
           Compile: OK
              Test: OK

Tested-by: CKI Project <cki-project at redhat.com>

Kernel information:
    Commit message: Merge branch 'for-next/core' into for-kernelci

You can find all the details about the test run at
    https://datawarehouse.cki-project.org/kcidb/checkouts/119737

One or more kernel tests failed:
    We also see the following known issues which are not related to your changes:
        Issue: [upstream] stress-ng: avc denial on secretmemory
            URL: https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issues/1752
            Affected tests:
                 aarch64 - stress: stress-ng - memory
        Issue: stress: stress-ng - memory: (panic) Comm: systemd-oomd Not tainted 6.1.0-rc3
            URL: https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issues/1461
            Affected tests:
                 aarch64 - stress: stress-ng - memory
        Issue: Firmware test suite: mv: cannot stat 'dtcompilerparser.tab.c': No such file or directory
            URL: https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issues/1544
            Affected tests:
                 aarch64 - Hardware - Firmware test suite



If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.

Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.

        ,-.   ,-.
       ( C ) ( K )  Continuous
        `-',-.`-'   Kernel
          ( I )     Integration
           `-'
______________________________________________________________________________



From ryan.roberts at arm.com  Tue Dec 19 09:42:16 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Tue, 19 Dec 2023 17:42:16 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
Message-ID: <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>

On 19/12/2023 17:22, David Hildenbrand wrote:
> On 19.12.23 09:30, Ryan Roberts wrote:
>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>> batch is determined by the architecture with the new helper,
>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>
>>>> The primary motivation for this change is to reduce the number of tlb
>>>> maintenance operations that the arm64 backend has to perform during
>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>> in its ptes. By write-protecting the parent using the new
>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>> when all ptes in the range are being write-protected. Similarly, by
>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>> child, the backend does not need to fold a contiguous range once they
>>>> are all populated - they can be initially populated as a contiguous
>>>> range in the first place.
>>>>
>>>> This code is very performance sensitive, and a significant amount of
>>>> effort has been put into not regressing performance for the order-0
>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>> which enables the compiler to simplify the extra loops that are added
>>>> for batching and produce code that is equivalent (and equally
>>>> performant) as the previous implementation.
>>>>
>>>> This change addresses the core-mm refactoring only and a separate change
>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>> improvement as part of the work to enable contpte mappings.
>>>>
>>>> To ensure the arm64 is performant once implemented, this change is very
>>>> careful to only call ptep_get() once per pte batch.
>>>>
>>>> The following microbenchmark results demonstate that there is no
>>>> significant performance change after this patch. Fork is called in a
>>>> tight loop in a process with 1G of populated memory and the time for the
>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>> positive is slower, compared to baseline upon which the series is based:
>>>>
>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>> | fork????????? |-------------------|-------------------|
>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>> |---------------|---------|---------|---------|---------|
>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>
>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>> | fork????????? |-------------------|-------------------|
>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>> |---------------|---------|---------|---------|---------|
>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>
>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>> ---
>>>> ?? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>> ?? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>> ?? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>
>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>> index af7639c3b0a3..db93fb81465a 100644
>>>> --- a/include/linux/pgtable.h
>>>> +++ b/include/linux/pgtable.h
>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>> ?? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>> ?? #endif
>>>> ?? +#ifndef pte_batch_remaining
>>>> +/**
>>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>>> + * @pte: Page table entry for the first page.
>>>> + * @addr: Address of the first page.
>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>> + *
>>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of
>>>> ptes.
>>>> + * In such cases, this function returns the remaining number of pages to
>>>> the end
>>>> + * of the current batch, as defined by addr. This can be useful when iterating
>>>> + * over ptes.
>>>> + *
>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>> + */
>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long addr,
>>>> +??????????????????????? unsigned long end)
>>>> +{
>>>> +??? return 1;
>>>> +}
>>>> +#endif
>>>
>>> It's a shame we now lose the optimization for all other archtiectures.
>>>
>>> Was there no way to have some basic batching mechanism that doesn't require arch
>>> specifics?
>>
>> I tried a bunch of things but ultimately the way I've done it was the only way
>> to reduce the order-0 fork regression to 0.
>>
>> My original v3 posting was costing 5% extra and even my first attempt at an
>> arch-specific version that didn't resolve to a compile-time constant 1 still
>> cost an extra 3%.
>>
>>
>>>
>>> I'd have thought that something very basic would have worked like:
>>>
>>> * Check if PTE is the same when setting the PFN to 0.
>>> * Check that PFN is consecutive
>>> * Check that all PFNs belong to the same folio
>>
>> I haven't tried this exact approach, but I'd be surprised if I can get the
>> regression under 4% with this. Further along the series I spent a lot of time
>> having to fiddle with the arm64 implementation; every conditional and every
>> memory read (even when in cache) was a problem. There is just so little in the
>> inner loop that every instruction matters. (At least on Ampere Altra and Apple
>> M2).
>>
>> Of course if you're willing to pay that 4-5% for order-0 then the benefit to
>> order-9 is around 10% in my measurements. Personally though, I'd prefer to play
>> safe and ensure the common order-0 case doesn't regress, as you previously
>> suggested.
>>
> 
> I just hacked something up, on top of my beloved rmap cleanup/batching series. I
> implemented very generic and simple batching for large folios (all PTE bits
> except the PFN have to match).
> 
> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R) Silver
> 4210R CPU.
> 
> order-0: 0.014210 -> 0.013969
> 
> -> Around 1.7 % faster
> 
> order-9: 0.014373 -> 0.009149
> 
> -> Around 36.3 % faster

Well I guess that shows me :)

I'll do a review and run the tests on my HW to see if it concurs.

> 
> 
> But it's likely buggy, so don't trust the numbers just yet. If they actually
> hold up, we should probably do something like that ahead of time, before all the
> arm-specific cont-pte work.
> 
> I suspect you can easily extend that by arch hooks where reasonable.
> 
> The (3) patches on top of the rmap cleanups can be found at:
> 
> ????https://github.com/davidhildenbrand/linux/tree/fork-batching
> 



From daniel.lezcano at linaro.org  Tue Dec 19 09:42:57 2023
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 19 Dec 2023 18:42:57 +0100
Subject: [PATCH v6 0/3] Add D1/T113s thermal sensor controller support
In-Reply-To: <20231217210629.131486-1-bigunclemax@gmail.com>
References: <20231217210629.131486-1-bigunclemax@gmail.com>
Message-ID: <4ed663b6-6c1d-43ed-8417-1704b9adfbae@linaro.org>

On 17/12/2023 22:06, Maksim Kiselev wrote:
> This series adds support for Allwinner D1/T113s thermal sensor controller.
> THIS controller is similar to the one on H6, but with only one sensor and
> uses a different scale and offset values.
> 
> v6:
> - Rebased onto 6.7.0-rc5

Applied, patch 1 & 2

Thanks


-- 
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:09 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:09 +0530
Subject: [RFC PATCH v3 00/17] RISC-V: ACPI: Add external interrupt controller support
Message-ID: <20231219174526.2235150-1-sunilvl@ventanamicro.com>

This series adds support for the below ECR approved by ASWG.
1) MADT - https://drive.google.com/file/d/1oMGPyOD58JaPgMl1pKasT-VKsIKia7zR/view?usp=sharing

The series primarily enables irqchip drivers for RISC-V ACPI based
platforms.

The series can be broadly categorized like below. 

1) PCI ACPI related functions are migrated from arm64 to common file so
that we don't need to duplicate them for RISC-V.

2) Introduced support for fw_devlink for ACPI nodes for IRQ dependency.
This helps to support deferred probe of interrupt controller drivers.

3) Modified pnp_irq() to try registering the IRQ  again if it sees it in
disabled state. This solution is similar to how
platform_get_irq_optional() works for regular platform devices.

4) Added support for re-ordering the probe of interrupt controllers when
IRQCHIP_ACPI_DECLARE is used.

5) ACPI support added in RISC-V interrupt controller drivers.

This series is based on Anup's AIA v11 series. Since Anup's AIA v11 is
not merged yet and first time introducing fw_devlink, deferred probe and
reordering support for IRQCHIP probe, this series is still kept as RFC.
Looking forward for the feedback!

Changes since RFC v2:
	1) Introduced fw_devlink for ACPI nodes for IRQ dependency.
	2) Dropped patches in drivers which are not required due to
	   fw_devlink support.
	3) Dropped pci_set_msi() patch and added a patch in
	   pci_create_root_bus().
	4) Updated pnp_irq() patch so that none of the actual PNP
	   drivers need to change.

Changes since RFC v1:
	1) Abandoned swnode approach as per Marc's feedback.
	2) To cope up with AIA series changes which changed irqchip driver
	   probe from core_initcall() to platform_driver, added patches
	   to support deferred probing.
	3) Rebased on top of Anup's AIA v11 and added tags.

To test the series,

1) Qemu should be built using the riscv_acpi_b2_v8 branch at
https://github.com/vlsunil/qemu.git

2) EDK2 should be built using the instructions at:
https://github.com/tianocore/edk2/blob/master/OvmfPkg/RiscVVirt/README.md

3) Build Linux using this series on top of Anup's AIA v11 series.

Run Qemu:
qemu-system-riscv64 \
 -M virt,pflash0=pflash0,pflash1=pflash1,aia=aplic-imsic \
 -m 2G -smp 8 \
 -serial mon:stdio \
 -device virtio-gpu-pci -full-screen \
 -device qemu-xhci \
 -device usb-kbd \
 -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \
 -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \
 -netdev user,id=net0 -device virtio-net-pci,netdev=net0 \
 -kernel arch/riscv/boot/Image \
 -initrd rootfs.cpio \
 -append "root=/dev/ram ro console=ttyS0 rootwait earlycon=uart8250,mmio,0x10000000"

To boot with APLIC only, use aia=aplic.
To boot with PLIC, remove aia= option.

This series is also available in acpi_b2_v3_riscv_aia_v11 branch at
https://github.com/vlsunil/linux.git

Based-on: 20231023172800.315343-1-apatel at ventanamicro.com
(https://lore.kernel.org/lkml/20231023172800.315343-1-apatel at ventanamicro.com/)

Sunil V L (17):
  arm64: PCI: Migrate ACPI related functions to pci-acpi.c
  RISC-V: ACPI: Implement PCI related functionality
  PCI: Make pci_create_root_bus() declare its reliance on MSI domains
  ACPI: Add fw_devlink support for ACPI fwnode for IRQ dependency
  ACPI: irq: Add support for deferred probe in acpi_register_gsi()
  pnp.h: Reconfigure IRQ in pnp_irq() to support deferred probe
  ACPI: scan.c: Add weak arch specific function to reorder the IRQCHIP
    probe
  ACPI: RISC-V: Implement arch function to reorder irqchip probe entries
  irqchip: riscv-intc: Add ACPI support for AIA
  irqchip: riscv-imsic: Add ACPI support
  irqchip: riscv-aplic: Add ACPI support
  irqchip: irq-sifive-plic: Add ACPI support
  ACPI: bus: Add RINTC IRQ model for RISC-V
  ACPI: bus: Add acpi_riscv_init function
  ACPI: RISC-V: Create APLIC platform device
  ACPI: RISC-V: Create PLIC platform device
  irqchip: riscv-intc: Set ACPI irqmodel

 arch/arm64/kernel/pci.c                    | 191 ---------------------
 arch/riscv/Kconfig                         |   2 +
 arch/riscv/include/asm/irq.h               |  46 +++++
 arch/riscv/kernel/acpi.c                   |  31 ++--
 drivers/acpi/bus.c                         |   4 +
 drivers/acpi/irq.c                         |  22 +++
 drivers/acpi/property.c                    |  20 +++
 drivers/acpi/riscv/Makefile                |   2 +-
 drivers/acpi/riscv/init.c                  |  15 ++
 drivers/acpi/riscv/init.h                  |   6 +
 drivers/acpi/riscv/irq.c                   | 169 ++++++++++++++++++
 drivers/acpi/scan.c                        |   3 +
 drivers/irqchip/irq-riscv-aplic-direct.c   |  21 ++-
 drivers/irqchip/irq-riscv-aplic-main.c     |  64 ++++---
 drivers/irqchip/irq-riscv-aplic-main.h     |   1 +
 drivers/irqchip/irq-riscv-aplic-msi.c      |   9 +-
 drivers/irqchip/irq-riscv-imsic-early.c    |  52 +++++-
 drivers/irqchip/irq-riscv-imsic-platform.c |  51 ++++--
 drivers/irqchip/irq-riscv-imsic-state.c    | 128 +++++++-------
 drivers/irqchip/irq-riscv-imsic-state.h    |   2 +-
 drivers/irqchip/irq-riscv-intc.c           |  96 ++++++++++-
 drivers/irqchip/irq-sifive-plic.c          |  76 ++++++--
 drivers/pci/pci-acpi.c                     | 182 ++++++++++++++++++++
 drivers/pci/probe.c                        |   1 +
 drivers/pnp/pnpacpi/core.c                 |   7 +
 include/linux/acpi.h                       |  18 ++
 include/linux/irqchip/riscv-imsic.h        |  10 ++
 include/linux/pnp.h                        |  14 +-
 28 files changed, 895 insertions(+), 348 deletions(-)
 create mode 100644 drivers/acpi/riscv/init.c
 create mode 100644 drivers/acpi/riscv/init.h
 create mode 100644 drivers/acpi/riscv/irq.c

-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:10 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:10 +0530
Subject: [RFC PATCH v3 01/17] arm64: PCI: Migrate ACPI related functions to pci-acpi.c
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-2-sunilvl@ventanamicro.com>

The functions defined in arm64 for ACPI support are required
for RISC-V also. To avoid duplication, move these functions
to common location.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
---
 arch/arm64/kernel/pci.c | 191 ----------------------------------------
 drivers/pci/pci-acpi.c  | 182 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 182 insertions(+), 191 deletions(-)

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index f872c57e9909..fd9a7bed83ce 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -6,28 +6,7 @@
  * Copyright (C) 2014 ARM Ltd.
  */
 
-#include <linux/acpi.h>
-#include <linux/init.h>
-#include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/mm.h>
 #include <linux/pci.h>
-#include <linux/pci-acpi.h>
-#include <linux/pci-ecam.h>
-#include <linux/slab.h>
-
-#ifdef CONFIG_ACPI
-/*
- * Try to assign the IRQ number when probing a new device
- */
-int pcibios_alloc_irq(struct pci_dev *dev)
-{
-	if (!acpi_disabled)
-		acpi_pci_irq_enable(dev);
-
-	return 0;
-}
-#endif
 
 /*
  * raw_pci_read/write - Platform-specific PCI config space access.
@@ -61,173 +40,3 @@ int pcibus_to_node(struct pci_bus *bus)
 EXPORT_SYMBOL(pcibus_to_node);
 
 #endif
-
-#ifdef CONFIG_ACPI
-
-struct acpi_pci_generic_root_info {
-	struct acpi_pci_root_info	common;
-	struct pci_config_window	*cfg;	/* config space mapping */
-};
-
-int acpi_pci_bus_find_domain_nr(struct pci_bus *bus)
-{
-	struct pci_config_window *cfg = bus->sysdata;
-	struct acpi_device *adev = to_acpi_device(cfg->parent);
-	struct acpi_pci_root *root = acpi_driver_data(adev);
-
-	return root->segment;
-}
-
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
-{
-	struct pci_config_window *cfg;
-	struct acpi_device *adev;
-	struct device *bus_dev;
-
-	if (acpi_disabled)
-		return 0;
-
-	cfg = bridge->bus->sysdata;
-
-	/*
-	 * On Hyper-V there is no corresponding ACPI device for a root bridge,
-	 * therefore ->parent is set as NULL by the driver. And set 'adev' as
-	 * NULL in this case because there is no proper ACPI device.
-	 */
-	if (!cfg->parent)
-		adev = NULL;
-	else
-		adev = to_acpi_device(cfg->parent);
-
-	bus_dev = &bridge->bus->dev;
-
-	ACPI_COMPANION_SET(&bridge->dev, adev);
-	set_dev_node(bus_dev, acpi_get_node(acpi_device_handle(adev)));
-
-	return 0;
-}
-
-static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
-{
-	struct resource_entry *entry, *tmp;
-	int status;
-
-	status = acpi_pci_probe_root_resources(ci);
-	resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
-		if (!(entry->res->flags & IORESOURCE_WINDOW))
-			resource_list_destroy_entry(entry);
-	}
-	return status;
-}
-
-/*
- * Lookup the bus range for the domain in MCFG, and set up config space
- * mapping.
- */
-static struct pci_config_window *
-pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
-{
-	struct device *dev = &root->device->dev;
-	struct resource *bus_res = &root->secondary;
-	u16 seg = root->segment;
-	const struct pci_ecam_ops *ecam_ops;
-	struct resource cfgres;
-	struct acpi_device *adev;
-	struct pci_config_window *cfg;
-	int ret;
-
-	ret = pci_mcfg_lookup(root, &cfgres, &ecam_ops);
-	if (ret) {
-		dev_err(dev, "%04x:%pR ECAM region not found\n", seg, bus_res);
-		return NULL;
-	}
-
-	adev = acpi_resource_consumer(&cfgres);
-	if (adev)
-		dev_info(dev, "ECAM area %pR reserved by %s\n", &cfgres,
-			 dev_name(&adev->dev));
-	else
-		dev_warn(dev, FW_BUG "ECAM area %pR not reserved in ACPI namespace\n",
-			 &cfgres);
-
-	cfg = pci_ecam_create(dev, &cfgres, bus_res, ecam_ops);
-	if (IS_ERR(cfg)) {
-		dev_err(dev, "%04x:%pR error %ld mapping ECAM\n", seg, bus_res,
-			PTR_ERR(cfg));
-		return NULL;
-	}
-
-	return cfg;
-}
-
-/* release_info: free resources allocated by init_info */
-static void pci_acpi_generic_release_info(struct acpi_pci_root_info *ci)
-{
-	struct acpi_pci_generic_root_info *ri;
-
-	ri = container_of(ci, struct acpi_pci_generic_root_info, common);
-	pci_ecam_free(ri->cfg);
-	kfree(ci->ops);
-	kfree(ri);
-}
-
-/* Interface called from ACPI code to setup PCI host controller */
-struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
-{
-	struct acpi_pci_generic_root_info *ri;
-	struct pci_bus *bus, *child;
-	struct acpi_pci_root_ops *root_ops;
-	struct pci_host_bridge *host;
-
-	ri = kzalloc(sizeof(*ri), GFP_KERNEL);
-	if (!ri)
-		return NULL;
-
-	root_ops = kzalloc(sizeof(*root_ops), GFP_KERNEL);
-	if (!root_ops) {
-		kfree(ri);
-		return NULL;
-	}
-
-	ri->cfg = pci_acpi_setup_ecam_mapping(root);
-	if (!ri->cfg) {
-		kfree(ri);
-		kfree(root_ops);
-		return NULL;
-	}
-
-	root_ops->release_info = pci_acpi_generic_release_info;
-	root_ops->prepare_resources = pci_acpi_root_prepare_resources;
-	root_ops->pci_ops = (struct pci_ops *)&ri->cfg->ops->pci_ops;
-	bus = acpi_pci_root_create(root, root_ops, &ri->common, ri->cfg);
-	if (!bus)
-		return NULL;
-
-	/* If we must preserve the resource configuration, claim now */
-	host = pci_find_host_bridge(bus);
-	if (host->preserve_config)
-		pci_bus_claim_resources(bus);
-
-	/*
-	 * Assign whatever was left unassigned. If we didn't claim above,
-	 * this will reassign everything.
-	 */
-	pci_assign_unassigned_root_bus_resources(bus);
-
-	list_for_each_entry(child, &bus->children, node)
-		pcie_bus_configure_settings(child);
-
-	return bus;
-}
-
-void pcibios_add_bus(struct pci_bus *bus)
-{
-	acpi_pci_add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
-	acpi_pci_remove_bus(bus);
-}
-
-#endif
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index a05350a4e49c..58497b25d2ab 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -15,6 +15,7 @@
 #include <linux/pci_hotplug.h>
 #include <linux/module.h>
 #include <linux/pci-acpi.h>
+#include <linux/pci-ecam.h>
 #include <linux/pm_runtime.h>
 #include <linux/pm_qos.h>
 #include <linux/rwsem.h>
@@ -1518,3 +1519,184 @@ static int __init acpi_pci_init(void)
 	return 0;
 }
 arch_initcall(acpi_pci_init);
+
+#if defined(CONFIG_ARM64)
+
+/*
+ * Try to assign the IRQ number when probing a new device
+ */
+int pcibios_alloc_irq(struct pci_dev *dev)
+{
+	if (!acpi_disabled)
+		acpi_pci_irq_enable(dev);
+
+	return 0;
+}
+
+struct acpi_pci_generic_root_info {
+	struct acpi_pci_root_info	common;
+	struct pci_config_window	*cfg;	/* config space mapping */
+};
+
+int acpi_pci_bus_find_domain_nr(struct pci_bus *bus)
+{
+	struct pci_config_window *cfg = bus->sysdata;
+	struct acpi_device *adev = to_acpi_device(cfg->parent);
+	struct acpi_pci_root *root = acpi_driver_data(adev);
+
+	return root->segment;
+}
+
+int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+	struct pci_config_window *cfg;
+	struct acpi_device *adev;
+	struct device *bus_dev;
+
+	if (acpi_disabled)
+		return 0;
+
+	cfg = bridge->bus->sysdata;
+
+	/*
+	 * On Hyper-V there is no corresponding ACPI device for a root bridge,
+	 * therefore ->parent is set as NULL by the driver. And set 'adev' as
+	 * NULL in this case because there is no proper ACPI device.
+	 */
+	if (!cfg->parent)
+		adev = NULL;
+	else
+		adev = to_acpi_device(cfg->parent);
+
+	bus_dev = &bridge->bus->dev;
+
+	ACPI_COMPANION_SET(&bridge->dev, adev);
+	set_dev_node(bus_dev, acpi_get_node(acpi_device_handle(adev)));
+
+	return 0;
+}
+
+static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
+{
+	struct resource_entry *entry, *tmp;
+	int status;
+
+	status = acpi_pci_probe_root_resources(ci);
+	resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
+		if (!(entry->res->flags & IORESOURCE_WINDOW))
+			resource_list_destroy_entry(entry);
+	}
+	return status;
+}
+
+/*
+ * Lookup the bus range for the domain in MCFG, and set up config space
+ * mapping.
+ */
+static struct pci_config_window *
+pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
+{
+	struct device *dev = &root->device->dev;
+	struct resource *bus_res = &root->secondary;
+	u16 seg = root->segment;
+	const struct pci_ecam_ops *ecam_ops;
+	struct resource cfgres;
+	struct acpi_device *adev;
+	struct pci_config_window *cfg;
+	int ret;
+
+	ret = pci_mcfg_lookup(root, &cfgres, &ecam_ops);
+	if (ret) {
+		dev_err(dev, "%04x:%pR ECAM region not found\n", seg, bus_res);
+		return NULL;
+	}
+
+	adev = acpi_resource_consumer(&cfgres);
+	if (adev)
+		dev_info(dev, "ECAM area %pR reserved by %s\n", &cfgres,
+			 dev_name(&adev->dev));
+	else
+		dev_warn(dev, FW_BUG "ECAM area %pR not reserved in ACPI namespace\n",
+			 &cfgres);
+
+	cfg = pci_ecam_create(dev, &cfgres, bus_res, ecam_ops);
+	if (IS_ERR(cfg)) {
+		dev_err(dev, "%04x:%pR error %ld mapping ECAM\n", seg, bus_res,
+			PTR_ERR(cfg));
+		return NULL;
+	}
+
+	return cfg;
+}
+
+/* release_info: free resources allocated by init_info */
+static void pci_acpi_generic_release_info(struct acpi_pci_root_info *ci)
+{
+	struct acpi_pci_generic_root_info *ri;
+
+	ri = container_of(ci, struct acpi_pci_generic_root_info, common);
+	pci_ecam_free(ri->cfg);
+	kfree(ci->ops);
+	kfree(ri);
+}
+
+/* Interface called from ACPI code to setup PCI host controller */
+struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
+{
+	struct acpi_pci_generic_root_info *ri;
+	struct pci_bus *bus, *child;
+	struct acpi_pci_root_ops *root_ops;
+	struct pci_host_bridge *host;
+
+	ri = kzalloc(sizeof(*ri), GFP_KERNEL);
+	if (!ri)
+		return NULL;
+
+	root_ops = kzalloc(sizeof(*root_ops), GFP_KERNEL);
+	if (!root_ops) {
+		kfree(ri);
+		return NULL;
+	}
+
+	ri->cfg = pci_acpi_setup_ecam_mapping(root);
+	if (!ri->cfg) {
+		kfree(ri);
+		kfree(root_ops);
+		return NULL;
+	}
+
+	root_ops->release_info = pci_acpi_generic_release_info;
+	root_ops->prepare_resources = pci_acpi_root_prepare_resources;
+	root_ops->pci_ops = (struct pci_ops *)&ri->cfg->ops->pci_ops;
+	bus = acpi_pci_root_create(root, root_ops, &ri->common, ri->cfg);
+	if (!bus)
+		return NULL;
+
+	/* If we must preserve the resource configuration, claim now */
+	host = pci_find_host_bridge(bus);
+	if (host->preserve_config)
+		pci_bus_claim_resources(bus);
+
+	/*
+	 * Assign whatever was left unassigned. If we didn't claim above,
+	 * this will reassign everything.
+	 */
+	pci_assign_unassigned_root_bus_resources(bus);
+
+	list_for_each_entry(child, &bus->children, node)
+		pcie_bus_configure_settings(child);
+
+	return bus;
+}
+
+void pcibios_add_bus(struct pci_bus *bus)
+{
+	acpi_pci_add_bus(bus);
+}
+
+void pcibios_remove_bus(struct pci_bus *bus)
+{
+	acpi_pci_remove_bus(bus);
+}
+
+#endif
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:11 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:11 +0530
Subject: [RFC PATCH v3 02/17] RISC-V: ACPI: Implement PCI related functionality
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-3-sunilvl@ventanamicro.com>

Replace the dummy implementation for PCI related functions with actual
implementation. This needs ECAM and MCFG CONFIG options to be enabled
for RISC-V.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 arch/riscv/Kconfig       |  2 ++
 arch/riscv/kernel/acpi.c | 31 ++++++++++++++-----------------
 drivers/pci/pci-acpi.c   |  2 +-
 3 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 45c660f1219d..d939fff5b5b1 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -13,6 +13,7 @@ config 32BIT
 config RISCV
 	def_bool y
 	select ACPI_GENERIC_GSI if ACPI
+	select ACPI_MCFG if (ACPI && PCI)
 	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
 	select ARCH_DMA_DEFAULT_COHERENT
 	select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
@@ -151,6 +152,7 @@ config RISCV
 	select OF_EARLY_FLATTREE
 	select OF_IRQ
 	select PCI_DOMAINS_GENERIC if PCI
+	select PCI_ECAM if (ACPI && PCI)
 	select PCI_MSI if PCI
 	select RISCV_ALTERNATIVE if !XIP_KERNEL
 	select RISCV_APLIC
diff --git a/arch/riscv/kernel/acpi.c b/arch/riscv/kernel/acpi.c
index 56cb2c986c48..b7bf1678241a 100644
--- a/arch/riscv/kernel/acpi.c
+++ b/arch/riscv/kernel/acpi.c
@@ -223,29 +223,26 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
 #ifdef CONFIG_PCI
 
 /*
- * These interfaces are defined just to enable building ACPI core.
- * TODO: Update it with actual implementation when external interrupt
- * controller support is added in RISC-V ACPI.
+ * raw_pci_read/write - Platform-specific PCI config space access.
  */
-int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
-		 int reg, int len, u32 *val)
+int raw_pci_read(unsigned int domain, unsigned int bus,
+		 unsigned int devfn, int reg, int len, u32 *val)
 {
-	return PCIBIOS_DEVICE_NOT_FOUND;
-}
+	struct pci_bus *b = pci_find_bus(domain, bus);
 
-int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
-		  int reg, int len, u32 val)
-{
-	return PCIBIOS_DEVICE_NOT_FOUND;
+	if (!b)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	return b->ops->read(b, devfn, reg, len, val);
 }
 
-int acpi_pci_bus_find_domain_nr(struct pci_bus *bus)
+int raw_pci_write(unsigned int domain, unsigned int bus,
+		  unsigned int devfn, int reg, int len, u32 val)
 {
-	return -1;
-}
+	struct pci_bus *b = pci_find_bus(domain, bus);
 
-struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
-{
-	return NULL;
+	if (!b)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	return b->ops->write(b, devfn, reg, len, val);
 }
+
 #endif	/* CONFIG_PCI */
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 58497b25d2ab..c8c3369fd69f 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -1520,7 +1520,7 @@ static int __init acpi_pci_init(void)
 }
 arch_initcall(acpi_pci_init);
 
-#if defined(CONFIG_ARM64)
+#if defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
 
 /*
  * Try to assign the IRQ number when probing a new device
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:12 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:12 +0530
Subject: [RFC PATCH v3 03/17] PCI: Make pci_create_root_bus() declare its reliance on MSI domains
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-4-sunilvl@ventanamicro.com>

Similar to [1], declare this dependency for PCI probe in ACPI based
flow.

This is required especially for RISC-V platforms where MSI controller
can be absent.

[1] - https://lore.kernel.org/all/20210330151145.997953-12-maz at kernel.org/

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/pci/probe.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 795534589b98..9e941cf55d87 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -3054,6 +3054,7 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 	bridge->sysdata = sysdata;
 	bridge->busnr = bus;
 	bridge->ops = ops;
+	bridge->msi_domain = true;
 
 	error = pci_register_host_bridge(bridge);
 	if (error < 0)
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:13 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:13 +0530
Subject: [RFC PATCH v3 04/17] ACPI: Add fw_devlink support for ACPI fwnode for IRQ dependency
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-5-sunilvl@ventanamicro.com>

Currently ACPI doesn't support fw_devlink infrastructure which helps in
ordering the driver probe in the order of dependencies. One of the
dependency between devices in ACPI is GSI interrupt source. This
interrupt source can be another device and mentioned as part of
ResourceSource in the ASL. Or it can be indirectly determined by the GSI
mapping. In either way, adding the link for this dependency avoids
modifying all drivers to handle EPROBE_DEFER. So, add this new interface
into ACPI's fwnode handlers.

Currently, this is necessary for RISC-V architecture. So, kept the
interface functional only for RISC-V. But in future other architectures
also can enable this functionality or can be made common.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/acpi/irq.c      | 18 ++++++++++++++++++
 drivers/acpi/property.c | 20 ++++++++++++++++++++
 include/linux/acpi.h    |  9 +++++++++
 3 files changed, 47 insertions(+)

diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
index 1687483ff319..b3409e2e2041 100644
--- a/drivers/acpi/irq.c
+++ b/drivers/acpi/irq.c
@@ -354,3 +354,21 @@ struct irq_domain *acpi_irq_create_hierarchy(unsigned int flags,
 					   host_data);
 }
 EXPORT_SYMBOL_GPL(acpi_irq_create_hierarchy);
+
+int acpi_get_gsi_parent_fwnode(acpi_handle handle,
+			       unsigned int index,
+			       struct fwnode_handle **parent)
+{
+	struct irq_fwspec fwspec;
+	unsigned long flags;
+	int rc;
+
+	fwspec.fwnode = NULL;
+	rc = acpi_irq_parse_one(handle, index, &fwspec, &flags);
+	if (rc || !fwspec.fwnode)
+		return 0;
+
+	*parent = fwspec.fwnode;
+	return 1;
+}
+EXPORT_SYMBOL_GPL(acpi_get_gsi_parent_fwnode);
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 413e4fcadcaf..88769acb13d4 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1572,6 +1572,25 @@ static int acpi_fwnode_irq_get(const struct fwnode_handle *fwnode,
 	return res.start;
 }
 
+static int acpi_fwnode_add_links(struct fwnode_handle *fwnode)
+{
+	struct fwnode_handle *parent_fwnode;
+	unsigned int i;
+
+	/* This is needed primarily for RISC-V. Other architectures can
+	 * be enabled or made this generic if required.
+	 */
+	if (!IS_ENABLED(CONFIG_RISCV))
+		return 0;
+
+	for (i = 0;
+		   acpi_get_gsi_parent_fwnode(ACPI_HANDLE_FWNODE(fwnode), i, &parent_fwnode);
+		   i++)
+		fwnode_link_add(fwnode, parent_fwnode);
+
+	return 0;
+}
+
 #define DECLARE_ACPI_FWNODE_OPS(ops) \
 	const struct fwnode_operations ops = {				\
 		.device_is_available = acpi_fwnode_device_is_available, \
@@ -1597,6 +1616,7 @@ static int acpi_fwnode_irq_get(const struct fwnode_handle *fwnode,
 		.graph_get_port_parent = acpi_fwnode_get_parent,	\
 		.graph_parse_endpoint = acpi_fwnode_graph_parse_endpoint, \
 		.irq_get = acpi_fwnode_irq_get,				\
+		.add_links = acpi_fwnode_add_links,			\
 	};								\
 	EXPORT_SYMBOL_GPL(ops)
 
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index afd94c9b8b8a..e9a9659314f2 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1463,12 +1463,21 @@ static inline int acpi_parse_spcr(bool enable_earlycon, bool enable_console)
 
 #if IS_ENABLED(CONFIG_ACPI_GENERIC_GSI)
 int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res);
+int acpi_get_gsi_parent_fwnode(acpi_handle handle, unsigned int index,
+			       struct fwnode_handle **parent);
 #else
 static inline
 int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
 {
 	return -EINVAL;
 }
+
+static inline
+int acpi_get_gsi_parent_fwnode(acpi_handle handle, unsigned int index,
+			       struct fwnode_handle **parent)
+{
+	return 0;
+}
 #endif
 
 #ifdef CONFIG_ACPI_LPIT
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:14 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:14 +0530
Subject: [RFC PATCH v3 05/17] ACPI: irq: Add support for deferred probe in acpi_register_gsi()
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-6-sunilvl@ventanamicro.com>

The chip which provides the GSI support may not be initialized at the
time of acpi_register_gsi(). Return -EPROBE_DEFER to support deferred
probing similar to acpi_irq_get().

This is required to support ResourceSource as supported by ACPI spec for
Interrupt resource.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/acpi/irq.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
index b3409e2e2041..c4605fdcda77 100644
--- a/drivers/acpi/irq.c
+++ b/drivers/acpi/irq.c
@@ -52,6 +52,7 @@ EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
  *
  * Returns: a valid linux IRQ number on success
  *          -EINVAL on failure
+ *          -EPROBE_DEFER if irqdomain not created yet
  */
 int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
 		      int polarity)
@@ -65,6 +66,9 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
 		return -EINVAL;
 	}
 
+	if (!irq_find_matching_fwnode(fwspec.fwnode, DOMAIN_BUS_ANY))
+		return -EPROBE_DEFER;
+
 	fwspec.param[0] = gsi;
 	fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
 	fwspec.param_count = 2;
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:15 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:15 +0530
Subject: [RFC PATCH v3 06/17] pnp.h: Reconfigure IRQ in pnp_irq() to support deferred probe
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-7-sunilvl@ventanamicro.com>

PNP devices add the IRQ resources to PNP data structure early during
boot from ACPI resource structure. As part of this, the Interrupt
resource (GSI) are registered and appropriate linux IRQ is saved
directly in PNP data structure while creating PNP devices. But at this
time, the interrupt controller for the GSI (either via GSI vector
mapping or via ResourceSource in Interrupt()) may not be probed and
initialized. Hence, the IRQ number in PNP data structure may not be the
linux IRQ number. When the actual driver for the PNP device get probed,
it will get incorrect linux IRQ number.

Fix this issue similar to how platform devices handle this. Basically,
while creating PNP devices, the hwirq number is saved in PNP device and
marked as disabled since acpi_register_gsi() would have failed. When the
actual driver calls pnp_irq(), get the linux IRQ number again if the IRQ
is disabled.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/pnp/pnpacpi/core.c |  7 +++++++
 include/linux/pnp.h        | 14 ++++++++++++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
index 6ab272c84b7b..239355977d4c 100644
--- a/drivers/pnp/pnpacpi/core.c
+++ b/drivers/pnp/pnpacpi/core.c
@@ -326,3 +326,10 @@ static int __init pnpacpi_setup(char *str)
 }
 
 __setup("pnpacpi=", pnpacpi_setup);
+
+void pnpacpi_reconfigure_irq(struct pnp_dev *dev, unsigned int index, struct resource *res)
+{
+	if (has_acpi_companion(&dev->dev))
+		acpi_irq_get(ACPI_HANDLE(&dev->dev), index, res);
+}
+EXPORT_SYMBOL(pnpacpi_reconfigure_irq);
diff --git a/include/linux/pnp.h b/include/linux/pnp.h
index c2a7cfbca713..8753eb4275b0 100644
--- a/include/linux/pnp.h
+++ b/include/linux/pnp.h
@@ -26,6 +26,7 @@ struct pnp_dev;
 #ifdef CONFIG_PNP
 struct resource *pnp_get_resource(struct pnp_dev *dev, unsigned long type,
 				unsigned int num);
+
 #else
 static inline struct resource *pnp_get_resource(struct pnp_dev *dev,
 			unsigned long type, unsigned int num)
@@ -146,13 +147,22 @@ static inline resource_size_t pnp_mem_len(struct pnp_dev *dev,
 	return 0;
 }
 
+#ifdef CONFIG_PNPACPI
+void pnpacpi_reconfigure_irq(struct pnp_dev *dev, unsigned int index, struct resource *res);
+#endif
 
-static inline resource_size_t pnp_irq(struct pnp_dev *dev, unsigned int bar)
+static inline int pnp_irq(struct pnp_dev *dev, unsigned int bar)
 {
 	struct resource *res = pnp_get_resource(dev, IORESOURCE_IRQ, bar);
 
-	if (pnp_resource_valid(res))
+	if (pnp_resource_valid(res)) {
+#ifdef CONFIG_PNPACPI
+		if (!pnp_resource_enabled(res))
+			pnpacpi_reconfigure_irq(dev, bar, res);
+#endif
 		return res->start;
+	}
+
 	return -1;
 }
 
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:16 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:16 +0530
Subject: [RFC PATCH v3 07/17] ACPI: scan.c: Add weak arch specific function to reorder the IRQCHIP probe
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-8-sunilvl@ventanamicro.com>

Unlike OF framework, the irqchip probe using IRQCHIP_ACPI_DECLARE has no
order defined. Depending on the driver Makefile is not a good idea. So,
usually it is worked around by mandating only root interrupt controller
probed using IRQCHIP_ACPI_DECLARE and other interrupt controllers are
probed via cascade mechanism.

However, this is also not a clean solution because if there are multiple
root controllers (ex: RINTC in RISC-V which is per CPU) which need to be
probed first, then the cascade will happen for every root controller.
So, introduce a architecture specific weak function to order the probing
of the interrupt controllers which can be implemented by different
architectures as per their interrupt controller hierarchy.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/acpi/scan.c  | 3 +++
 include/linux/acpi.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 691d4b7686ee..87f4baebd497 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2685,6 +2685,8 @@ static int __init acpi_match_madt(union acpi_subtable_headers *header,
 	return 0;
 }
 
+void __weak arch_sort_irqchip_probe(struct acpi_probe_entry *ap_head, int nr) { }
+
 int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr)
 {
 	int count = 0;
@@ -2693,6 +2695,7 @@ int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr)
 		return 0;
 
 	mutex_lock(&acpi_probe_mutex);
+	arch_sort_irqchip_probe(ap_head, nr);
 	for (ape = ap_head; nr; ape++, nr--) {
 		if (ACPI_COMPARE_NAMESEG(ACPI_SIG_MADT, ape->id)) {
 			acpi_probe_count = 0;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index e9a9659314f2..ae045e14126b 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1338,6 +1338,8 @@ struct acpi_probe_entry {
 	kernel_ulong_t driver_data;
 };
 
+void arch_sort_irqchip_probe(struct acpi_probe_entry *ap_head, int nr);
+
 #define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, subtable,	\
 				 valid, data, fn)			\
 	static const struct acpi_probe_entry __acpi_probe_##name	\
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:17 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:17 +0530
Subject: [RFC PATCH v3 08/17] ACPI: RISC-V: Implement arch function to reorder irqchip probe entries
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-9-sunilvl@ventanamicro.com>

ACPI MADT entries for interrupt controllers don't have a way to describe
the hierarchy. However, the hierarchy is known to the architecture and
on RISC-V platforms, the MADT sub table types are ordered in the
incremental order from the root controller which is RINTC. So, add
architecture function for RISC-V to reorder the interrupt controller
probing as per the hierarchy as below.

RINTC->IMSIC->APLIC->PLIC

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/acpi/riscv/Makefile |  2 +-
 drivers/acpi/riscv/irq.c    | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 drivers/acpi/riscv/irq.c

diff --git a/drivers/acpi/riscv/Makefile b/drivers/acpi/riscv/Makefile
index 8b3b126e0b94..f80b3da230e9 100644
--- a/drivers/acpi/riscv/Makefile
+++ b/drivers/acpi/riscv/Makefile
@@ -1,2 +1,2 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-y 	+= rhct.o
+obj-y 	+= rhct.o irq.o
diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
new file mode 100644
index 000000000000..36e0525b3235
--- /dev/null
+++ b/drivers/acpi/riscv/irq.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, Ventana Micro Systems Inc
+ *	Author: Sunil V L <sunilvl at ventanamicro.com>
+ *
+ */
+
+#include <linux/acpi.h>
+#include <linux/sort.h>
+
+static int irqchip_cmp_func(const void *in0, const void *in1)
+{
+	struct acpi_probe_entry *elem0 = (struct acpi_probe_entry *)in0;
+	struct acpi_probe_entry *elem1 = (struct acpi_probe_entry *)in1;
+
+	return (elem0->type > elem1->type) - (elem0->type < elem1->type);
+}
+
+/*
+ * RISC-V irqchips in MADT of ACPI spec are defined in the same order how
+ * they should be probed. Since IRQCHIP_ACPI_DECLARE doesn't define any
+ * order, this arch function will reorder the probe functions as per the
+ * required order for the architecture.
+ */
+void arch_sort_irqchip_probe(struct acpi_probe_entry *ap_head, int nr)
+{
+	struct acpi_probe_entry *ape = ap_head;
+
+	if (nr == 1 || !ACPI_COMPARE_NAMESEG(ACPI_SIG_MADT, ape->id))
+		return;
+	sort(ape, nr, sizeof(*ape), irqchip_cmp_func, NULL);
+}
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:18 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:18 +0530
Subject: [RFC PATCH v3 09/17] irqchip: riscv-intc: Add ACPI support for AIA
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-10-sunilvl@ventanamicro.com>

The RINTC subtype structure in MADT also has information about other
interrupt controllers. Save this information and provide interfaces to
retrieve them when required by corresponding drivers.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 arch/riscv/include/asm/irq.h     | 45 +++++++++++++++
 drivers/irqchip/irq-riscv-intc.c | 95 +++++++++++++++++++++++++++++++-
 2 files changed, 139 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index 8e10a94430a2..232314e5f007 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -12,8 +12,53 @@
 
 #include <asm-generic/irq.h>
 
+#ifdef CONFIG_ACPI
+
+/*
+ * The ext_intc_id format is as follows:
+ * Bits [31:24] APLIC/PLIC ID
+ * Bits [15:0] APLIC IDC ID / PLIC S-Mode Context ID for this hart
+ */
+#define APLIC_PLIC_ID(x) ((x) >> 24)
+#define IDC_CONTEXT_ID(x) ((x) & 0x0000ffff)
+
+int __init acpi_get_intc_index_hartid(u32 index, unsigned long *hartid);
+int acpi_get_ext_intc_parent_hartid(u8 id, u32 idx, unsigned long *hartid);
+void acpi_get_plic_nr_contexts(u8 id, int *nr_contexts);
+int acpi_get_plic_context(u8 id, u32 idx, int *context_id);
+int __init acpi_get_imsic_mmio_info(u32 index, struct resource *res);
+
+#else
+static inline struct fwnode_handle *ext_entc_get_gsi_domain_id(u32 gsi)
+{
+	return NULL;
+}
+
+static inline int __init acpi_get_intc_index_hartid(u32 index, unsigned long *hartid)
+{
+	return -EINVAL;
+}
+
+static inline int acpi_get_ext_intc_parent_hartid(u8 id, u32 idx, unsigned long *hartid)
+{
+	return -EINVAL;
+}
+
+static inline void acpi_get_plic_nr_contexts(u8 id, int *nr_contexts) { }
+static inline int acpi_get_plic_context(u8 id, u32 idx, int *context_id)
+{
+	return -EINVAL;
+}
+
+static inline int __init acpi_get_imsic_mmio_info(u32 index, struct resource *res)
+{
+	return -EINVAL;
+}
+#endif
+
 void riscv_set_intc_hwnode_fn(struct fwnode_handle *(*fn)(void));
 
 struct fwnode_handle *riscv_get_intc_hwnode(void);
+int acpi_imsic_probe(struct fwnode_handle *parent);
 
 #endif /* _ASM_RISCV_IRQ_H */
diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
index bab536bbaf2c..24bbc5bfc30f 100644
--- a/drivers/irqchip/irq-riscv-intc.c
+++ b/drivers/irqchip/irq-riscv-intc.c
@@ -195,13 +195,100 @@ IRQCHIP_DECLARE(riscv, "riscv,cpu-intc", riscv_intc_init);
 
 #ifdef CONFIG_ACPI
 
+struct rintc_data {
+	u32 ext_intc_id;
+	unsigned long hart_id;
+	u64 imsic_addr;
+	u32 imsic_size;
+};
+
+static u32 nr_rintc;
+static struct rintc_data *rintc_acpi_data[NR_CPUS];
+
+int acpi_get_intc_index_hartid(u32 index, unsigned long *hartid)
+{
+	if (index >= nr_rintc)
+		return -1;
+
+	*hartid = rintc_acpi_data[index]->hart_id;
+	return 0;
+}
+
+int acpi_get_ext_intc_parent_hartid(u8 id, u32 idx, unsigned long *hartid)
+{
+	int i, j = 0;
+
+	for (i = 0; i < nr_rintc; i++) {
+		if (APLIC_PLIC_ID(rintc_acpi_data[i]->ext_intc_id) == id) {
+			if (idx == j) {
+				*hartid = rintc_acpi_data[i]->hart_id;
+				return 0;
+			}
+			j++;
+		}
+	}
+
+	return -1;
+}
+
+void acpi_get_plic_nr_contexts(u8 id, int *nr_contexts)
+{
+	int i, j = 0;
+
+	for (i = 0; i < nr_rintc; i++) {
+		if (APLIC_PLIC_ID(rintc_acpi_data[i]->ext_intc_id) == id)
+			j++;
+	}
+
+	*nr_contexts = j;
+}
+
+int acpi_get_plic_context(u8 id, u32 idx, int *context_id)
+{
+	int i, j = 0;
+
+	for (i = 0; i < nr_rintc; i++) {
+		if (APLIC_PLIC_ID(rintc_acpi_data[i]->ext_intc_id) == id) {
+			if (idx == j) {
+				*context_id = IDC_CONTEXT_ID(rintc_acpi_data[i]->ext_intc_id);
+				return 0;
+			}
+
+			j++;
+		}
+	}
+
+	return -1;
+}
+
+int acpi_get_imsic_mmio_info(u32 index, struct resource *res)
+{
+	if (index >= nr_rintc)
+		return -1;
+
+	res->start = rintc_acpi_data[index]->imsic_addr;
+	res->end = res->start + rintc_acpi_data[index]->imsic_size - 1;
+	res->flags = IORESOURCE_MEM;
+	return 0;
+}
+
 static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header,
 				       const unsigned long end)
 {
 	struct fwnode_handle *fn;
 	struct acpi_madt_rintc *rintc;
+	int rc;
 
 	rintc = (struct acpi_madt_rintc *)header;
+	rintc_acpi_data[nr_rintc] = kzalloc(sizeof(*rintc_acpi_data[0]), GFP_KERNEL);
+	if (!rintc_acpi_data[nr_rintc])
+		return -ENOMEM;
+
+	rintc_acpi_data[nr_rintc]->ext_intc_id = rintc->ext_intc_id;
+	rintc_acpi_data[nr_rintc]->hart_id = rintc->hart_id;
+	rintc_acpi_data[nr_rintc]->imsic_addr = rintc->imsic_addr;
+	rintc_acpi_data[nr_rintc]->imsic_size = rintc->imsic_size;
+	nr_rintc++;
 
 	/*
 	 * The ACPI MADT will have one INTC for each CPU (or HART)
@@ -218,7 +305,13 @@ static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header,
 		return -ENOMEM;
 	}
 
-	return riscv_intc_init_common(fn);
+	rc = riscv_intc_init_common(fn);
+	if (rc) {
+		irq_domain_free_fwnode(fn);
+		return rc;
+	}
+
+	return 0;
 }
 
 IRQCHIP_ACPI_DECLARE(riscv_intc, ACPI_MADT_TYPE_RINTC, NULL,
-- 
2.39.2



From diogo.ivo at siemens.com  Tue Dec 19 09:45:39 2023
From: diogo.ivo at siemens.com (Diogo Ivo)
Date: Tue, 19 Dec 2023 17:45:39 +0000
Subject: [RFC PATCH net-next 1/8] dt-bindings: net: Add support for AM65x SR1.0 in ICSSG
In-Reply-To: <20231219174548.3481-1-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
Message-ID: <20231219174548.3481-2-diogo.ivo@siemens.com>

Silicon Revision 1.0 of the AM65x came with a slightly different ICSSG
support: Only 2 PRUs per slice are available and instead 2 additional
DMA channels are used for management purposes. We have no restrictions
on specified PRUs, but the DMA channels need to be adjusted.

Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
---
 .../bindings/net/ti,icssg-prueth.yaml         | 62 +++++++++++++------
 1 file changed, 44 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
index 229c8f32019f..fbe51731854a 100644
--- a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
+++ b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
@@ -19,30 +19,15 @@ allOf:
 properties:
   compatible:
     enum:
-      - ti,am642-icssg-prueth  # for AM64x SoC family
-      - ti,am654-icssg-prueth  # for AM65x SoC family
+      - ti,am642-icssg-prueth      # for AM64x SoC family
+      - ti,am654-icssg-prueth      # for AM65x SoC family, SR2.x
+      - ti,am654-icssg-prueth-sr1  # for AM65x SoC family, SR1.0
 
   sram:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
       phandle to MSMC SRAM node
 
-  dmas:
-    maxItems: 10
-
-  dma-names:
-    items:
-      - const: tx0-0
-      - const: tx0-1
-      - const: tx0-2
-      - const: tx0-3
-      - const: tx1-0
-      - const: tx1-1
-      - const: tx1-2
-      - const: tx1-3
-      - const: rx0
-      - const: rx1
-
   ti,mii-g-rt:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
@@ -122,6 +107,47 @@ properties:
       - required:
           - port at 1
 
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - ti,am654-icssg-prueth-sr1
+then:
+  properties:
+    dmas:
+      maxItems: 12
+    dma-names:
+      items:
+        - const: tx0-0
+        - const: tx0-1
+        - const: tx0-2
+        - const: tx0-3
+        - const: tx1-0
+        - const: tx1-1
+        - const: tx1-2
+        - const: tx1-3
+        - const: rx0
+        - const: rx1
+        - const: rxmgm0
+        - const: rxmgm1
+else:
+  properties:
+    dmas:
+      maxItems: 10
+    dma-names:
+      items:
+        - const: tx0-0
+        - const: tx0-1
+        - const: tx0-2
+        - const: tx0-3
+        - const: tx1-0
+        - const: tx1-1
+        - const: tx1-2
+        - const: tx1-3
+        - const: rx0
+        - const: rx1
+
 required:
   - compatible
   - sram
-- 
2.43.0



From diogo.ivo at siemens.com  Tue Dec 19 09:45:38 2023
From: diogo.ivo at siemens.com (Diogo Ivo)
Date: Tue, 19 Dec 2023 17:45:38 +0000
Subject: [RFC PATCH net-next 0/8] Add support for ICSSG-based Ethernet on SR1.0 devices
Message-ID: <20231219174548.3481-1-diogo.ivo@siemens.com>

Hello,

This series extends the current ICSSG-based Ethernet driver to support
Silicon Revision 1.0 devices.

Notable differences between the Silicon Revisions are that there is
no TX core in SR1.0 with this being handled by the firmware, requiring
extra DMA channels to communicate commands to the firmware (with the
firmware being different as well) and in the packet classifier.

The motivation behind it is that a significant number of Siemens
devices containing SR1.0 silicon have been deployed in the field
and need to be supported and updated to newer kernel versions
without losing functionality.

This series is based on TI's 5.10 SDK [1].

[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y

Diogo Ivo (7):
  net: ti: icssg-config: add SR1.0-specific configuration bits
  net: ti: icssg-prueth: add SR1.0-specific configuration bits
  net: ti: icssg-classifier: Add support for SR1.0
  net: ti: icssg-config: Add SR1.0 configuration functions
  net: ti: icssg-ethtool: Adjust channel count for SR1.0
  net: ti: iccsg-prueth: Add necessary functions for SR1.0 support
  net: ti: icssg-prueth: Wire up support for SR1.0

Jan Kiszka (1):
  dt-bindings: net: Add support for AM65x SR1.0 in ICSSG

 .../bindings/net/ti,icssg-prueth.yaml         |  62 +-
 .../net/ethernet/ti/icssg/icssg_classifier.c  | 113 +++-
 drivers/net/ethernet/ti/icssg/icssg_config.c  |  90 ++-
 drivers/net/ethernet/ti/icssg/icssg_config.h  |  61 +-
 drivers/net/ethernet/ti/icssg/icssg_ethtool.c |  10 +-
 drivers/net/ethernet/ti/icssg/icssg_prueth.c  | 556 ++++++++++++++++--
 drivers/net/ethernet/ti/icssg/icssg_prueth.h  |  21 +-
 7 files changed, 812 insertions(+), 101 deletions(-)

-- 
2.43.0



From diogo.ivo at siemens.com  Tue Dec 19 09:45:41 2023
From: diogo.ivo at siemens.com (Diogo Ivo)
Date: Tue, 19 Dec 2023 17:45:41 +0000
Subject: [RFC PATCH net-next 3/8] net: ti: icssg-prueth: add SR1.0-specific configuration bits
In-Reply-To: <20231219174548.3481-1-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
Message-ID: <20231219174548.3481-4-diogo.ivo@siemens.com>

Add fields to differentiate between SR1.0 and SR2.0 in the driver
as well as the structures necessary to program SR1.0.

Based on the work of Roger Quadros in TI's 5.10 SDK [1].

[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y

Co-developed-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
---
 drivers/net/ethernet/ti/icssg/icssg_prueth.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.h b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
index 8b6d6b497010..1bdd3d301fde 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
@@ -127,6 +127,7 @@ struct prueth_rx_chn {
 
 /* data for each emac port */
 struct prueth_emac {
+	bool is_sr1;
 	bool fw_running;
 	struct prueth *prueth;
 	struct net_device *ndev;
@@ -155,6 +156,10 @@ struct prueth_emac {
 	int rx_flow_id_base;
 	int tx_ch_num;
 
+	/* SR1.0 Management channel */
+	struct prueth_rx_chn rx_mgm_chn;
+	int rx_mgm_flow_id_base;
+
 	spinlock_t lock;	/* serialize access */
 
 	/* TX HW Timestamping */
@@ -182,10 +187,12 @@ struct prueth_emac {
  * struct prueth_pdata - PRUeth platform data
  * @fdqring_mode: Free desc queue mode
  * @quirk_10m_link_issue: 10M link detect errata
+ * @is_sr1: device is SR1.0
  */
 struct prueth_pdata {
 	enum k3_ring_mode fdqring_mode;
 	u32	quirk_10m_link_issue:1;
+	u32	is_sr1:1;
 };
 
 /**
@@ -224,6 +231,7 @@ struct prueth {
 	struct device_node *eth_node[PRUETH_NUM_MACS];
 	struct prueth_emac *emac[PRUETH_NUM_MACS];
 	struct net_device *registered_netdevs[PRUETH_NUM_MACS];
+	struct icssg_config_sr1 config[PRUSS_NUM_PRUS];
 	struct regmap *miig_rt;
 	struct regmap *mii_rt;
 
@@ -236,6 +244,13 @@ struct prueth {
 	struct icss_iep *iep1;
 };
 
+struct emac_tx_ts_response_sr1 {
+	u32 lo_ts;
+	u32 hi_ts;
+	u32 reserved;
+	u32 cookie;
+};
+
 struct emac_tx_ts_response {
 	u32 reserved[2];
 	u32 cookie;
-- 
2.43.0



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:19 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:19 +0530
Subject: [RFC PATCH v3 10/17] irqchip: riscv-imsic: Add ACPI support
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-11-sunilvl@ventanamicro.com>

RISC-V IMSIC interrupt controller provides IPI and MSI support.
Currently, DT based drivers setup the IPI feature early during boot but
defer setting up the MSI functionality. However, in ACPI systems, PCI
scan happens early during boot and PCI subsystem expects MSI controller
is already setup. Hence, in case of ACPI, both IPI and MSI features
are initialized early itself.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/irqchip/irq-riscv-imsic-early.c    |  52 ++++++++-
 drivers/irqchip/irq-riscv-imsic-platform.c |  51 +++++---
 drivers/irqchip/irq-riscv-imsic-state.c    | 128 ++++++++++-----------
 drivers/irqchip/irq-riscv-imsic-state.h    |   2 +-
 include/linux/irqchip/riscv-imsic.h        |  10 ++
 5 files changed, 160 insertions(+), 83 deletions(-)

diff --git a/drivers/irqchip/irq-riscv-imsic-early.c b/drivers/irqchip/irq-riscv-imsic-early.c
index 23f689ff5807..866e97559e4c 100644
--- a/drivers/irqchip/irq-riscv-imsic-early.c
+++ b/drivers/irqchip/irq-riscv-imsic-early.c
@@ -5,13 +5,16 @@
  */
 
 #define pr_fmt(fmt) "riscv-imsic: " fmt
+#include <linux/acpi.h>
 #include <linux/cpu.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/irqchip.h>
 #include <linux/irqchip/chained_irq.h>
+#include <linux/irqchip/riscv-imsic.h>
 #include <linux/module.h>
+#include <linux/pci.h>
 #include <linux/spinlock.h>
 #include <linux/smp.h>
 
@@ -216,7 +219,7 @@ static int __init imsic_early_dt_init(struct device_node *node,
 	struct fwnode_handle *fwnode = &node->fwnode;
 
 	/* Setup IMSIC state */
-	rc = imsic_setup_state(fwnode);
+	rc = imsic_setup_state(fwnode, NULL);
 	if (rc) {
 		pr_err("%pfwP: failed to setup state (error %d)\n",
 			fwnode, rc);
@@ -233,3 +236,50 @@ static int __init imsic_early_dt_init(struct device_node *node,
 	return 0;
 }
 IRQCHIP_DECLARE(riscv_imsic, "riscv,imsics", imsic_early_dt_init);
+
+#ifdef CONFIG_ACPI
+
+static struct fwnode_handle *imsic_acpi_fwnode;
+
+struct fwnode_handle *imsic_acpi_get_fwnode(struct device *dev)
+{
+	return imsic_acpi_fwnode;
+}
+
+static int __init imsic_early_acpi_init(union acpi_subtable_headers *header,
+					const unsigned long end)
+{
+	struct acpi_madt_imsic *imsic = (struct acpi_madt_imsic *)header;
+	int rc;
+
+	imsic_acpi_fwnode = irq_domain_alloc_named_fwnode("imsic");
+	if (!imsic_acpi_fwnode) {
+		pr_err("unable to allocate IMSIC FW node\n");
+		return -ENOMEM;
+	}
+
+	/* Setup IMSIC state */
+	rc = imsic_setup_state(imsic_acpi_fwnode, (void *)imsic);
+	if (rc) {
+		pr_err("%pfwP: failed to setup state (error %d)\n", imsic_acpi_fwnode, rc);
+		return rc;
+	}
+
+	/* Do early setup of IMSIC state and IPIs */
+	rc = imsic_early_probe(imsic_acpi_fwnode);
+	if (rc)
+		return rc;
+
+	rc = imsic_platform_acpi_probe(imsic_acpi_fwnode);
+
+#ifdef CONFIG_PCI
+	if (!rc)
+		pci_msi_register_fwnode_provider(&imsic_acpi_get_fwnode);
+#endif
+
+	return rc;
+}
+
+IRQCHIP_ACPI_DECLARE(riscv_imsic, ACPI_MADT_TYPE_IMSIC, NULL,
+		     1, imsic_early_acpi_init);
+#endif
diff --git a/drivers/irqchip/irq-riscv-imsic-platform.c b/drivers/irqchip/irq-riscv-imsic-platform.c
index cdb659401199..f905340d24e6 100644
--- a/drivers/irqchip/irq-riscv-imsic-platform.c
+++ b/drivers/irqchip/irq-riscv-imsic-platform.c
@@ -5,6 +5,7 @@
  */
 
 #define pr_fmt(fmt) "riscv-imsic: " fmt
+#include <linux/acpi.h>
 #include <linux/bitmap.h>
 #include <linux/cpu.h>
 #include <linux/interrupt.h>
@@ -308,43 +309,47 @@ static int imsic_irq_domains_init(struct fwnode_handle *fwnode)
 	return 0;
 }
 
-static int imsic_platform_probe(struct platform_device *pdev)
+static int imsic_platform_probe_common(struct fwnode_handle *fwnode)
 {
-	struct device *dev = &pdev->dev;
 	struct imsic_global_config *global;
 	int rc;
 
 	if (!imsic) {
-		dev_err(dev, "early driver not probed\n");
+		pr_err("%pfwP: early driver not probed\n", fwnode);
 		return -ENODEV;
 	}
 
 	if (imsic->base_domain) {
-		dev_err(dev, "irq domain already created\n");
+		pr_err("%pfwP: irq domain already created\n", fwnode);
 		return -ENODEV;
 	}
 
 	global = &imsic->global;
 
 	/* Initialize IRQ and MSI domains */
-	rc = imsic_irq_domains_init(dev->fwnode);
+	rc = imsic_irq_domains_init(fwnode);
 	if (rc) {
-		dev_err(dev, "failed to initialize IRQ and MSI domains\n");
+		pr_err("%pfwP: failed to initialize IRQ and MSI domains\n", fwnode);
 		return rc;
 	}
 
-	dev_info(dev, "  hart-index-bits: %d,  guest-index-bits: %d\n",
-		 global->hart_index_bits, global->guest_index_bits);
-	dev_info(dev, " group-index-bits: %d, group-index-shift: %d\n",
-		 global->group_index_bits, global->group_index_shift);
-	dev_info(dev, " per-CPU IDs %d at base PPN %pa\n",
-		 global->nr_ids, &global->base_addr);
-	dev_info(dev, " total %d interrupts available\n",
-		 imsic->nr_hwirqs);
+	pr_info("%pfwP: hart-index-bits: %d,  guest-index-bits: %d\n", fwnode,
+		global->hart_index_bits, global->guest_index_bits);
+	pr_info("%pfwP: group-index-bits: %d, group-index-shift: %d\n", fwnode,
+		global->group_index_bits, global->group_index_shift);
+	pr_info("%pfwP: per-CPU IDs %d at base PPN %pa\n", fwnode,
+		global->nr_ids, &global->base_addr);
+	pr_info("%pfwP: total %d interrupts available\n", fwnode,
+		imsic->nr_hwirqs);
 
 	return 0;
 }
 
+static int imsic_platform_dt_probe(struct platform_device *pdev)
+{
+	return imsic_platform_probe_common(pdev->dev.fwnode);
+}
+
 static const struct of_device_id imsic_platform_match[] = {
 	{ .compatible = "riscv,imsics" },
 	{}
@@ -355,6 +360,22 @@ static struct platform_driver imsic_platform_driver = {
 		.name		= "riscv-imsic",
 		.of_match_table	= imsic_platform_match,
 	},
-	.probe = imsic_platform_probe,
+	.probe = imsic_platform_dt_probe,
 };
 builtin_platform_driver(imsic_platform_driver);
+
+#ifdef CONFIG_ACPI
+
+/*
+ *  On ACPI based systems, PCI enumeration happens early during boot in
+ *  acpi_scan_init(). PCI enumeration expects MSI domain setup before
+ *  it calls pci_set_msi_domain(). Hence, unlike in DT where
+ *  imsic-platform drive probe happens late during boot, ACPI based
+ *  systems need to setup the MSI domain early.
+ */
+int imsic_platform_acpi_probe(struct fwnode_handle *fwnode)
+{
+	return imsic_platform_probe_common(fwnode);
+}
+
+#endif
diff --git a/drivers/irqchip/irq-riscv-imsic-state.c b/drivers/irqchip/irq-riscv-imsic-state.c
index 54465e47851c..b842c499df0a 100644
--- a/drivers/irqchip/irq-riscv-imsic-state.c
+++ b/drivers/irqchip/irq-riscv-imsic-state.c
@@ -5,6 +5,7 @@
  */
 
 #define pr_fmt(fmt) "riscv-imsic: " fmt
+#include <linux/acpi.h>
 #include <linux/cpu.h>
 #include <linux/bitmap.h>
 #include <linux/interrupt.h>
@@ -593,12 +594,8 @@ static int __init imsic_get_parent_hartid(struct fwnode_handle *fwnode,
 	int rc;
 	struct of_phandle_args parent;
 
-	/*
-	 * Currently, only OF fwnode is supported so extend this
-	 * function for ACPI support.
-	 */
 	if (!is_of_node(fwnode))
-		return -EINVAL;
+		return acpi_get_intc_index_hartid(index, hartid);
 
 	rc = of_irq_parse_one(to_of_node(fwnode), index, &parent);
 	if (rc)
@@ -617,12 +614,8 @@ static int __init imsic_get_parent_hartid(struct fwnode_handle *fwnode,
 static int __init imsic_get_mmio_resource(struct fwnode_handle *fwnode,
 					  u32 index, struct resource *res)
 {
-	/*
-	 * Currently, only OF fwnode is supported so extend this
-	 * function for ACPI support.
-	 */
 	if (!is_of_node(fwnode))
-		return -EINVAL;
+		return acpi_get_imsic_mmio_info(index, res);
 
 	return of_address_to_resource(to_of_node(fwnode), index, res);
 }
@@ -630,20 +623,15 @@ static int __init imsic_get_mmio_resource(struct fwnode_handle *fwnode,
 static int __init imsic_parse_fwnode(struct fwnode_handle *fwnode,
 				     struct imsic_global_config *global,
 				     u32 *nr_parent_irqs,
-				     u32 *nr_mmios)
+				     u32 *nr_mmios,
+				     void *opaque)
 {
+	struct acpi_madt_imsic *imsic = (struct acpi_madt_imsic *)opaque;
 	unsigned long hartid;
 	struct resource res;
 	int rc;
 	u32 i;
 
-	/*
-	 * Currently, only OF fwnode is supported so extend this
-	 * function for ACPI support.
-	 */
-	if (!is_of_node(fwnode))
-		return -EINVAL;
-
 	*nr_parent_irqs = 0;
 	*nr_mmios = 0;
 
@@ -656,58 +644,66 @@ static int __init imsic_parse_fwnode(struct fwnode_handle *fwnode,
 		return -EINVAL;
 	}
 
-	/* Find number of guest index bits in MSI address */
-	rc = of_property_read_u32(to_of_node(fwnode),
-				  "riscv,guest-index-bits",
-				  &global->guest_index_bits);
-	if (rc)
-		global->guest_index_bits = 0;
+	if (is_of_node(fwnode)) {
+		/* Find number of guest index bits in MSI address */
+		rc = of_property_read_u32(to_of_node(fwnode),
+					  "riscv,guest-index-bits",
+					  &global->guest_index_bits);
+		if (rc)
+			global->guest_index_bits = 0;
 
-	/* Find number of HART index bits */
-	rc = of_property_read_u32(to_of_node(fwnode),
-				  "riscv,hart-index-bits",
-				  &global->hart_index_bits);
-	if (rc) {
-		/* Assume default value */
-		global->hart_index_bits = __fls(*nr_parent_irqs);
-		if (BIT(global->hart_index_bits) < *nr_parent_irqs)
-			global->hart_index_bits++;
-	}
+		/* Find number of HART index bits */
+		rc = of_property_read_u32(to_of_node(fwnode),
+					  "riscv,hart-index-bits",
+					  &global->hart_index_bits);
+		if (rc) {
+			/* Assume default value */
+			global->hart_index_bits = __fls(*nr_parent_irqs);
+			if (BIT(global->hart_index_bits) < *nr_parent_irqs)
+				global->hart_index_bits++;
+		}
 
-	/* Find number of group index bits */
-	rc = of_property_read_u32(to_of_node(fwnode),
-				  "riscv,group-index-bits",
-				  &global->group_index_bits);
-	if (rc)
-		global->group_index_bits = 0;
+		/* Find number of group index bits */
+		rc = of_property_read_u32(to_of_node(fwnode),
+					  "riscv,group-index-bits",
+					  &global->group_index_bits);
+		if (rc)
+			global->group_index_bits = 0;
 
-	/*
-	 * Find first bit position of group index.
-	 * If not specified assumed the default APLIC-IMSIC configuration.
-	 */
-	rc = of_property_read_u32(to_of_node(fwnode),
-				  "riscv,group-index-shift",
-				  &global->group_index_shift);
-	if (rc)
-		global->group_index_shift = IMSIC_MMIO_PAGE_SHIFT * 2;
+		/*
+		 * Find first bit position of group index.
+		 * If not specified assumed the default APLIC-IMSIC configuration.
+		 */
+		rc = of_property_read_u32(to_of_node(fwnode),
+					  "riscv,group-index-shift",
+					  &global->group_index_shift);
+		if (rc)
+			global->group_index_shift = IMSIC_MMIO_PAGE_SHIFT * 2;
+
+		/* Find number of interrupt identities */
+		rc = of_property_read_u32(to_of_node(fwnode),
+					  "riscv,num-ids",
+					  &global->nr_ids);
+		if (rc) {
+			pr_err("%pfwP: number of interrupt identities not found\n", fwnode);
+			return rc;
+		}
 
-	/* Find number of interrupt identities */
-	rc = of_property_read_u32(to_of_node(fwnode),
-				  "riscv,num-ids",
-				  &global->nr_ids);
-	if (rc) {
-		pr_err("%pfwP: number of interrupt identities not found\n",
-			fwnode);
-		return rc;
+		/* Find number of guest interrupt identities */
+		rc = of_property_read_u32(to_of_node(fwnode),
+					  "riscv,num-guest-ids",
+					  &global->nr_guest_ids);
+		if (rc)
+			global->nr_guest_ids = global->nr_ids;
+	} else {
+		global->guest_index_bits = imsic->guest_index_bits;
+		global->hart_index_bits = imsic->hart_index_bits;
+		global->group_index_bits = imsic->group_index_bits;
+		global->group_index_shift = imsic->group_index_shift;
+		global->nr_ids = imsic->num_ids;
+		global->nr_guest_ids = imsic->num_guest_ids;
 	}
 
-	/* Find number of guest interrupt identities */
-	rc = of_property_read_u32(to_of_node(fwnode),
-				  "riscv,num-guest-ids",
-				  &global->nr_guest_ids);
-	if (rc)
-		global->nr_guest_ids = global->nr_ids;
-
 	/* Sanity check guest index bits */
 	i = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
 	if (i < global->guest_index_bits) {
@@ -775,7 +771,7 @@ static int __init imsic_parse_fwnode(struct fwnode_handle *fwnode,
 	return 0;
 }
 
-int __init imsic_setup_state(struct fwnode_handle *fwnode)
+int __init imsic_setup_state(struct fwnode_handle *fwnode, void *opaque)
 {
 	int rc, cpu;
 	phys_addr_t base_addr;
@@ -817,7 +813,7 @@ int __init imsic_setup_state(struct fwnode_handle *fwnode)
 	}
 
 	/* Parse IMSIC fwnode */
-	rc = imsic_parse_fwnode(fwnode, global, &nr_parent_irqs, &nr_mmios);
+	rc = imsic_parse_fwnode(fwnode, global, &nr_parent_irqs, &nr_mmios, opaque);
 	if (rc)
 		goto out_free_local;
 
diff --git a/drivers/irqchip/irq-riscv-imsic-state.h b/drivers/irqchip/irq-riscv-imsic-state.h
index 8d209e77432e..ee1f52891e89 100644
--- a/drivers/irqchip/irq-riscv-imsic-state.h
+++ b/drivers/irqchip/irq-riscv-imsic-state.h
@@ -105,6 +105,6 @@ void imsic_vector_debug_show_summary(struct seq_file *m, int ind);
 int imsic_hwirqs_alloc(unsigned int order);
 void imsic_hwirqs_free(unsigned int base_hwirq, unsigned int order);
 
-int imsic_setup_state(struct fwnode_handle *fwnode);
+int imsic_setup_state(struct fwnode_handle *fwnode, void *opaque);
 
 #endif
diff --git a/include/linux/irqchip/riscv-imsic.h b/include/linux/irqchip/riscv-imsic.h
index cbb7bcd0e4dd..c112e5559d88 100644
--- a/include/linux/irqchip/riscv-imsic.h
+++ b/include/linux/irqchip/riscv-imsic.h
@@ -84,4 +84,14 @@ static inline const struct imsic_global_config *imsic_get_global_config(void)
 
 #endif
 
+#ifdef CONFIG_ACPI
+int imsic_platform_acpi_probe(struct fwnode_handle *fwnode);
+struct fwnode_handle *imsic_acpi_get_fwnode(struct device *dev);
+#else
+static inline struct fwnode_handle *imsic_acpi_get_fwnode(struct device *dev)
+{
+	return NULL;
+}
+#endif
+
 #endif
-- 
2.39.2



From diogo.ivo at siemens.com  Tue Dec 19 09:45:40 2023
From: diogo.ivo at siemens.com (Diogo Ivo)
Date: Tue, 19 Dec 2023 17:45:40 +0000
Subject: [RFC PATCH net-next 2/8] net: ti: icssg-config: add SR1.0-specific configuration bits
In-Reply-To: <20231219174548.3481-1-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
Message-ID: <20231219174548.3481-3-diogo.ivo@siemens.com>

Add required definitions and structures to properly describe
SR 1.0 devices where they differ from SR2.0.

Based on the work of Roger Quadros, Murali Karicheri and
Grygorii Strashko in TI's 5.10 SDK [1].

[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y

Co-developed-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
---
 drivers/net/ethernet/ti/icssg/icssg_config.h | 61 +++++++++++++++++++-
 drivers/net/ethernet/ti/icssg/icssg_prueth.c | 16 ++---
 2 files changed, 66 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/ti/icssg/icssg_config.h b/drivers/net/ethernet/ti/icssg/icssg_config.h
index 43eb0922172a..bbc652bda2fd 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_config.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_config.h
@@ -23,15 +23,24 @@ struct icssg_flow_cfg {
 #define PRUETH_NAV_SW_DATA_SIZE	16	/* SW related data size */
 #define PRUETH_MAX_TX_DESC	512
 #define PRUETH_MAX_RX_DESC	512
-#define PRUETH_MAX_RX_FLOWS	1	/* excluding default flow */
-#define PRUETH_RX_FLOW_DATA	0
+#define PRUETH_MAX_RX_FLOWS_SR1	4	/* excluding default flow */
+#define PRUETH_MAX_RX_FLOWS_SR2	1	/* excluding default flow */
+#define PRUETH_RX_FLOW_DATA_SR1	3       /* highest priority flow */
+#define PRUETH_RX_FLOW_DATA_SR2	0
+
+/* SR1.0 only */
+#define PRUETH_MAX_RX_MGM_DESC		8
+#define PRUETH_MAX_RX_MGM_FLOWS		2	/* excluding default flow */
+#define PRUETH_RX_MGM_FLOW_RESPONSE	0
+#define PRUETH_RX_MGM_FLOW_TIMESTAMP	1
 
 #define PRUETH_EMAC_BUF_POOL_SIZE	SZ_8K
 #define PRUETH_EMAC_POOLS_PER_SLICE	24
 #define PRUETH_EMAC_BUF_POOL_START	8
 #define PRUETH_NUM_BUF_POOLS	8
 #define PRUETH_EMAC_RX_CTX_BUF_SIZE	SZ_16K	/* per slice */
-#define MSMC_RAM_SIZE	\
+#define MSMC_RAM_SIZE_SR1	(SZ_64K + SZ_32K + SZ_2K) /* 0x1880 x 8 x 2 */
+#define MSMC_RAM_SIZE_SR2	\
 	(2 * (PRUETH_EMAC_BUF_POOL_SIZE * PRUETH_NUM_BUF_POOLS + \
 	 PRUETH_EMAC_RX_CTX_BUF_SIZE * 2))
 
@@ -94,6 +103,13 @@ enum icssg_port_state_cmd {
 #define EMAC_ACCEPT_TAG     0xfffe0002
 #define EMAC_ACCEPT_PRIOR   0xfffc0000
 
+#define PRUETH_NUM_BUF_POOLS_SR1		16
+#define PRUETH_EMAC_BUF_POOL_START_SR1		8
+#define PRUETH_EMAC_BUF_POOL_MIN_SIZE_SR1	128
+#define PRUETH_EMAC_BUF_SIZE_SR1		1536
+#define PRUETH_EMAC_NUM_BUF_SR1			4
+#define PRUETH_EMAC_BUF_POOL_SIZE_SR1	(PRUETH_EMAC_NUM_BUF_SR1 * \
+					 PRUETH_EMAC_BUF_SIZE_SR1)
 /* Config area lies in DRAM */
 #define ICSSG_CONFIG_OFFSET	0x0
 
@@ -101,6 +117,45 @@ enum icssg_port_state_cmd {
 #define ICSSG_CONFIG_OFFSET_SLICE0   0
 #define ICSSG_CONFIG_OFFSET_SLICE1   0x8000
 
+struct icssg_config_sr1 {
+	__le32 status;		/* Firmware status */
+	__le32 addr_lo;		/* MSMC Buffer pool base address low. */
+	__le32 addr_hi;		/* MSMC Buffer pool base address high. Must be 0 */
+	__le32 tx_buf_sz[16];	/* Array of buffer pool sizes */
+	__le32 num_tx_threads;	/* Number of active egress threads, 1 to 4 */
+	__le32 tx_rate_lim_en;	/* Bitmask: Egress rate limit en per thread */
+	__le32 rx_flow_id;	/* RX flow id for first rx ring */
+	__le32 rx_mgr_flow_id;	/* RX flow id for the first management ring */
+	__le32 flags;		/* TBD */
+	__le32 n_burst;		/* for debug */
+	__le32 rtu_status;	/* RTU status */
+	__le32 info;		/* reserved */
+	__le32 reserve;
+	__le32 rand_seed;	/* Used for the random number generation at fw */
+} __packed;
+
+/* SR1.0 shutdown command to stop processing at firmware.
+ * Command format : 0x8101ss00. ss - sequence number. Currently not used
+ * by driver.
+ */
+#define ICSSG_SHUTDOWN_CMD		0x81010000
+
+/* SR1.0 pstate speed/duplex command to set speed and duplex settings
+ * in firmware.
+ * Command format : 0x8102ssPN. ss - sequence number: currently not
+ * used by driver, P - port number: For switch, N - Speed/Duplex state
+ * - Possible values of N:
+ * 0x0 - 10Mbps/Half duplex ;
+ * 0x8 - 10Mbps/Full duplex ;
+ * 0x2 - 100Mbps/Half duplex;
+ * 0xa - 100Mbps/Full duplex;
+ * 0xc - 1Gbps/Full duplex;
+ * NOTE: The above are same as bits [3..1](slice 0) or bits [8..6](slice 1) of
+ * RGMII CFG register. So suggested to read the register to populate the command
+ * bits.
+ */
+#define ICSSG_PSTATE_SPEED_DUPLEX_CMD	0x81020000
+
 #define ICSSG_NUM_NORMAL_PDS	64
 #define ICSSG_NUM_SPECIAL_PDS	16
 
diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.c b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
index 411898a4f38c..63f9bbea8237 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
@@ -1058,8 +1058,8 @@ static void emac_adjust_link(struct net_device *ndev)
 static int emac_napi_rx_poll(struct napi_struct *napi_rx, int budget)
 {
 	struct prueth_emac *emac = prueth_napi_to_emac(napi_rx);
-	int rx_flow = PRUETH_RX_FLOW_DATA;
-	int flow = PRUETH_MAX_RX_FLOWS;
+	int rx_flow = PRUETH_RX_FLOW_DATA_SR2;
+	int flow = PRUETH_MAX_RX_FLOWS_SR2;
 	int num_rx = 0;
 	int cur_budget;
 	int ret;
@@ -1345,7 +1345,7 @@ static int emac_ndo_open(struct net_device *ndev)
 		return ret;
 	}
 
-	max_rx_flows = PRUETH_MAX_RX_FLOWS;
+	max_rx_flows = PRUETH_MAX_RX_FLOWS_SR2;
 	ret = prueth_init_rx_chns(emac, &emac->rx_chns, "rx",
 				  max_rx_flows, PRUETH_MAX_RX_DESC);
 	if (ret) {
@@ -1358,7 +1358,7 @@ static int emac_ndo_open(struct net_device *ndev)
 		goto cleanup_rx;
 
 	/* we use only the highest priority flow for now i.e. @irq[3] */
-	rx_flow = PRUETH_RX_FLOW_DATA;
+	rx_flow = PRUETH_RX_FLOW_DATA_SR2;
 	ret = request_irq(emac->rx_chns.irq[rx_flow], prueth_rx_irq,
 			  IRQF_TRIGGER_HIGH, dev_name(dev), emac);
 	if (ret) {
@@ -1447,7 +1447,7 @@ static int emac_ndo_stop(struct net_device *ndev)
 {
 	struct prueth_emac *emac = netdev_priv(ndev);
 	struct prueth *prueth = emac->prueth;
-	int rx_flow = PRUETH_RX_FLOW_DATA;
+	int rx_flow = PRUETH_RX_FLOW_DATA_SR2;
 	int max_rx_flows;
 	int ret, i;
 
@@ -1477,7 +1477,7 @@ static int emac_ndo_stop(struct net_device *ndev)
 	for (i = 0; i < emac->tx_ch_num; i++)
 		napi_disable(&emac->tx_chns[i].napi_tx);
 
-	max_rx_flows = PRUETH_MAX_RX_FLOWS;
+	max_rx_flows = PRUETH_MAX_RX_FLOWS_SR2;
 	k3_udma_glue_tdown_rx_chn(emac->rx_chns.rx_chn, true);
 
 	prueth_reset_rx_chan(&emac->rx_chns, max_rx_flows, true);
@@ -2074,7 +2074,7 @@ static int prueth_probe(struct platform_device *pdev)
 		goto put_mem;
 	}
 
-	msmc_ram_size = MSMC_RAM_SIZE;
+	msmc_ram_size = MSMC_RAM_SIZE_SR2;
 
 	/* NOTE: FW bug needs buffer base to be 64KB aligned */
 	prueth->msmcram.va =
@@ -2264,7 +2264,7 @@ static void prueth_remove(struct platform_device *pdev)
 
 	gen_pool_free(prueth->sram_pool,
 		      (unsigned long)prueth->msmcram.va,
-		      MSMC_RAM_SIZE);
+		      MSMC_RAM_SIZE_SR2);
 
 	pruss_release_mem_region(prueth->pruss, &prueth->shram);
 
-- 
2.43.0



From diogo.ivo at siemens.com  Tue Dec 19 09:45:44 2023
From: diogo.ivo at siemens.com (Diogo Ivo)
Date: Tue, 19 Dec 2023 17:45:44 +0000
Subject: [RFC PATCH net-next 6/8] net: ti: icssg-ethtool: Adjust channel count for SR1.0
In-Reply-To: <20231219174548.3481-1-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
Message-ID: <20231219174548.3481-7-diogo.ivo@siemens.com>

SR1.0 uses the highest priority channel to transmit control
messages to the firmware. Take this into account when computing
channels.

Based on the work of Roger Quadros in TI's 5.10 SDK [1].

[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y

Co-developed-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
---
 drivers/net/ethernet/ti/icssg/icssg_ethtool.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/icssg/icssg_ethtool.c b/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
index a27ec1dcc8d5..29e67526fa22 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
@@ -141,6 +141,9 @@ static int emac_set_channels(struct net_device *ndev,
 		return -EBUSY;
 
 	emac->tx_ch_num = ch->tx_count;
+	/* highest channel number for management messaging on SR1 */
+	if (emac->is_sr1)
+		emac->tx_ch_num++;
 
 	return 0;
 }
@@ -151,9 +154,12 @@ static void emac_get_channels(struct net_device *ndev,
 	struct prueth_emac *emac = netdev_priv(ndev);
 
 	ch->max_rx = 1;
-	ch->max_tx = PRUETH_MAX_TX_QUEUES;
+	/* SR1 use high priority channel for management messages */
+	ch->max_tx = emac->is_sr1 ? PRUETH_MAX_TX_QUEUES - 1 :
+				    PRUETH_MAX_TX_QUEUES;
 	ch->rx_count = 1;
-	ch->tx_count = emac->tx_ch_num;
+	ch->tx_count = emac->is_sr1 ? emac->tx_ch_num - 1 :
+				      emac->tx_ch_num;
 }
 
 static const struct ethtool_rmon_hist_range emac_rmon_ranges[] = {
-- 
2.43.0



From diogo.ivo at siemens.com  Tue Dec 19 09:45:43 2023
From: diogo.ivo at siemens.com (Diogo Ivo)
Date: Tue, 19 Dec 2023 17:45:43 +0000
Subject: [RFC PATCH net-next 5/8] net: ti: icssg-config: Add SR1.0 configuration functions
In-Reply-To: <20231219174548.3481-1-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
Message-ID: <20231219174548.3481-6-diogo.ivo@siemens.com>

The SR1.0 firmware needs to configured differently from the
current SR2.0 firmware. Add the necessary functions.

Based on the work of Roger Quadros, Vignesh Raghavendra
and Grygorii Strashko in TI's 5.10 SDK [1].

[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y

Co-developed-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
---
 drivers/net/ethernet/ti/icssg/icssg_config.c | 90 ++++++++++++++++++--
 1 file changed, 83 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/ti/icssg/icssg_config.c b/drivers/net/ethernet/ti/icssg/icssg_config.c
index 99de8a40ed60..9079714b15cf 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_config.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_config.c
@@ -18,8 +18,10 @@
  */
 
 /* IPG is in core_clk cycles */
-#define MII_RT_TX_IPG_100M	0x17
-#define MII_RT_TX_IPG_1G	0xb
+#define MII_RT_TX_IPG_100M_SR1	0x166
+#define MII_RT_TX_IPG_1G_SR1	0x1a
+#define MII_RT_TX_IPG_100M_SR2	0x17
+#define MII_RT_TX_IPG_1G_SR2	0xb
 
 #define	ICSSG_QUEUES_MAX		64
 #define	ICSSG_QUEUE_OFFSET		0xd00
@@ -205,14 +207,20 @@ void icssg_config_ipg(struct prueth_emac *emac)
 
 	switch (emac->speed) {
 	case SPEED_1000:
-		icssg_mii_update_ipg(prueth->mii_rt, slice, MII_RT_TX_IPG_1G);
+		icssg_mii_update_ipg(prueth->mii_rt, slice,
+				     prueth->pdata.is_sr1 ?
+				     MII_RT_TX_IPG_1G_SR1 : MII_RT_TX_IPG_1G_SR2);
 		break;
 	case SPEED_100:
-		icssg_mii_update_ipg(prueth->mii_rt, slice, MII_RT_TX_IPG_100M);
+		icssg_mii_update_ipg(prueth->mii_rt, slice,
+				     prueth->pdata.is_sr1 ?
+				     MII_RT_TX_IPG_100M_SR1 : MII_RT_TX_IPG_100M_SR2);
 		break;
 	case SPEED_10:
-		/* IPG for 10M is same as 100M */
-		icssg_mii_update_ipg(prueth->mii_rt, slice, MII_RT_TX_IPG_100M);
+		/* Firmware hardcodes IPG for SR1. SR2 same as 100M */
+		if (!prueth->pdata.is_sr1)
+			icssg_mii_update_ipg(prueth->mii_rt, slice,
+					     MII_RT_TX_IPG_100M_SR2);
 		break;
 	default:
 		/* Other links speeds not supported */
@@ -221,6 +229,56 @@ void icssg_config_ipg(struct prueth_emac *emac)
 	}
 }
 
+/* SR1: Set buffer sizes for the pools. There are 8 internal queues
+ * implemented in firmware, but only 4 tx channels/threads in the Egress
+ * direction to firmware. Need a high priority queue for management
+ * messages since they shouldn't be blocked even during high traffic
+ * situation. So use Q0-Q2 as data queues and Q3 as management queue
+ * in the max case. However for ease of configuration, use the max
+ * data queue + 1 for management message if we are not using max
+ * case.
+ *
+ * Allocate 4 MTU buffers per data queue.  Firmware requires
+ * pool sizes to be set for internal queues. Set the upper 5 queue
+ * pool size to min size of 128 bytes since there are only 3 tx
+ * data channels and management queue requires only minimum buffer.
+ * i.e lower queues are used by driver and highest priority queue
+ * from that is used for management message.
+ */
+
+static int emac_egress_buf_pool_size[] = {
+	PRUETH_EMAC_BUF_POOL_SIZE_SR1, PRUETH_EMAC_BUF_POOL_SIZE_SR1,
+	PRUETH_EMAC_BUF_POOL_SIZE_SR1, PRUETH_EMAC_BUF_POOL_MIN_SIZE_SR1,
+	PRUETH_EMAC_BUF_POOL_MIN_SIZE_SR1, PRUETH_EMAC_BUF_POOL_MIN_SIZE_SR1,
+	PRUETH_EMAC_BUF_POOL_MIN_SIZE_SR1, PRUETH_EMAC_BUF_POOL_MIN_SIZE_SR1};
+
+void icssg_config_sr1(struct prueth *prueth, struct prueth_emac *emac,
+		      int slice)
+{
+	struct icssg_config_sr1 *config;
+	void __iomem *va;
+	int i, index;
+
+	va = prueth->shram.va + slice * ICSSG_CONFIG_OFFSET_SLICE1;
+	config = &prueth->config[slice];
+	memset(config, 0, sizeof(*config));
+	config->addr_lo = cpu_to_le32(lower_32_bits(prueth->msmcram.pa));
+	config->addr_hi = cpu_to_le32(upper_32_bits(prueth->msmcram.pa));
+	config->num_tx_threads = 0;
+	config->rx_flow_id = emac->rx_flow_id_base; /* flow id for host port */
+	config->rx_mgr_flow_id = emac->rx_mgm_flow_id_base; /* for mgm ch */
+	config->rand_seed = get_random_u32();
+
+	for (i = PRUETH_EMAC_BUF_POOL_START_SR1; i < PRUETH_NUM_BUF_POOLS_SR1; i++) {
+		index =  i - PRUETH_EMAC_BUF_POOL_START_SR1;
+		config->tx_buf_sz[i] = cpu_to_le32(emac_egress_buf_pool_size[index]);
+	}
+
+	memcpy_toio(va, &prueth->config[slice], sizeof(prueth->config[slice]));
+
+	emac->speed = SPEED_1000;
+}
+
 static void emac_r30_cmd_init(struct prueth_emac *emac)
 {
 	struct icssg_r30_cmd __iomem *p;
@@ -331,6 +389,11 @@ int icssg_config(struct prueth *prueth, struct prueth_emac *emac, int slice)
 	struct icssg_flow_cfg __iomem *flow_cfg;
 	int ret;
 
+	if (prueth->pdata.is_sr1) {
+		icssg_config_sr1(prueth, emac, slice);
+		return 0;
+	}
+
 	icssg_init_emac_mode(prueth);
 
 	memset_io(config, 0, TAS_GATE_MASK_LIST0);
@@ -435,19 +498,32 @@ int emac_set_port_state(struct prueth_emac *emac,
 
 void icssg_config_half_duplex(struct prueth_emac *emac)
 {
+	struct icssg_config_sr1 *config;
+	void __iomem *va;
+	int slice;
 	u32 val;
 
 	if (!emac->half_duplex)
 		return;
 
 	val = get_random_u32();
-	writel(val, emac->dram.va + HD_RAND_SEED_OFFSET);
+	if (emac->is_sr1) {
+		slice = prueth_emac_slice(emac);
+		va = emac->prueth->shram.va + slice * ICSSG_CONFIG_OFFSET_SLICE1;
+		config = (struct icssg_config_sr1 *)va;
+		writel(val, &config->rand_seed);
+	} else {
+		writel(val, emac->dram.va + HD_RAND_SEED_OFFSET);
+	}
 }
 
 void icssg_config_set_speed(struct prueth_emac *emac)
 {
 	u8 fw_speed;
 
+	if (emac->is_sr1)
+		return;
+
 	switch (emac->speed) {
 	case SPEED_1000:
 		fw_speed = FW_LINK_SPEED_1G;
-- 
2.43.0



From diogo.ivo at siemens.com  Tue Dec 19 09:45:42 2023
From: diogo.ivo at siemens.com (Diogo Ivo)
Date: Tue, 19 Dec 2023 17:45:42 +0000
Subject: [RFC PATCH net-next 4/8] net: ti: icssg-classifier: Add support for SR1.0
In-Reply-To: <20231219174548.3481-1-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
Message-ID: <20231219174548.3481-5-diogo.ivo@siemens.com>

Add the functions to program the SR1.0 packet classifier.

Based on the work of Roger Quadros in TI's 5.10 SDK [1].

[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y

Co-developed-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
---
 .../net/ethernet/ti/icssg/icssg_classifier.c  | 113 ++++++++++++++++--
 drivers/net/ethernet/ti/icssg/icssg_prueth.c  |   2 +-
 drivers/net/ethernet/ti/icssg/icssg_prueth.h  |   6 +-
 3 files changed, 110 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/ti/icssg/icssg_classifier.c b/drivers/net/ethernet/ti/icssg/icssg_classifier.c
index 6df53ab17fbc..d7288eb6c0fd 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_classifier.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_classifier.c
@@ -274,6 +274,16 @@ static void rx_class_set_or(struct regmap *miig_rt, int slice, int n,
 	regmap_write(miig_rt, offset, data);
 }
 
+static u32 rx_class_get_or(struct regmap *miig_rt, int slice, int n)
+{
+	u32 offset, val;
+
+	offset = RX_CLASS_N_REG(slice, n, RX_CLASS_OR_EN);
+	regmap_read(miig_rt, offset, &val);
+
+	return val;
+}
+
 void icssg_class_set_host_mac_addr(struct regmap *miig_rt, const u8 *mac)
 {
 	regmap_write(miig_rt, MAC_INTERFACE_0, (u32)(mac[0] | mac[1] << 8 |
@@ -288,6 +298,26 @@ void icssg_class_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac)
 	regmap_write(miig_rt, offs[slice].mac1, (u32)(mac[4] | mac[5] << 8));
 }
 
+static void icssg_class_ft1_add_mcast(struct regmap *miig_rt, int slice,
+				      int slot, const u8 *addr, const u8 *mask)
+{
+	int i;
+	u32 val;
+
+	WARN(slot >= FT1_NUM_SLOTS, "invalid slot: %d\n", slot);
+
+	rx_class_ft1_set_da(miig_rt, slice, slot, addr);
+	rx_class_ft1_set_da_mask(miig_rt, slice, slot, mask);
+	rx_class_ft1_cfg_set_type(miig_rt, slice, slot, FT1_CFG_TYPE_EQ);
+
+	/* Enable the FT1 slot in OR enable for all classifiers */
+	for (i = 0; i < ICSSG_NUM_CLASSIFIERS_IN_USE; i++) {
+		val = rx_class_get_or(miig_rt, slice, i);
+		val |= RX_CLASS_FT_FT1_MATCH(slot);
+		rx_class_set_or(miig_rt, slice, i, val);
+	}
+}
+
 /* disable all RX traffic */
 void icssg_class_disable(struct regmap *miig_rt, int slice)
 {
@@ -331,30 +361,95 @@ void icssg_class_disable(struct regmap *miig_rt, int slice)
 	regmap_write(miig_rt, offs[slice].rx_class_cfg2, 0);
 }
 
-void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti)
+void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti,
+			 bool is_sr1)
 {
+	int classifiers_in_use = is_sr1 ? ICSSG_NUM_CLASSIFIERS_IN_USE : 1;
 	u32 data;
+	int n;
 
 	/* defaults */
 	icssg_class_disable(miig_rt, slice);
 
 	/* Setup Classifier */
-	/* match on Broadcast or MAC_PRU address */
-	data = RX_CLASS_FT_BC | RX_CLASS_FT_DA_P;
+	for (n = 0; n < classifiers_in_use; n++) {
+		/* match on Broadcast or MAC_PRU address */
+		data = RX_CLASS_FT_BC | RX_CLASS_FT_DA_P;
 
-	/* multicast */
-	if (allmulti)
-		data |= RX_CLASS_FT_MC;
+		/* multicast */
+		if (allmulti)
+			data |= RX_CLASS_FT_MC;
 
-	rx_class_set_or(miig_rt, slice, 0, data);
+		rx_class_set_or(miig_rt, slice, n, data);
 
-	/* set CFG1 for OR_OR_AND for classifier */
-	rx_class_sel_set_type(miig_rt, slice, 0, RX_CLASS_SEL_TYPE_OR_OR_AND);
+		/* set CFG1 for OR_OR_AND for classifier */
+		rx_class_sel_set_type(miig_rt, slice, n,
+				      RX_CLASS_SEL_TYPE_OR_OR_AND);
+	}
 
 	/* clear CFG2 */
 	regmap_write(miig_rt, offs[slice].rx_class_cfg2, 0);
 }
 
+void icssg_class_promiscuous_sr1(struct regmap *miig_rt, int slice)
+{
+	u32 data, offset;
+	int n;
+
+	/* defaults */
+	icssg_class_disable(miig_rt, slice);
+
+	/* Setup Classifier */
+	for (n = 0; n < ICSSG_NUM_CLASSIFIERS_IN_USE; n++) {
+		/* set RAW_MASK to bypass filters */
+		offset = RX_CLASS_GATES_N_REG(slice, n);
+		regmap_read(miig_rt, offset, &data);
+		data |= RX_CLASS_GATES_RAW_MASK;
+		regmap_write(miig_rt, offset, data);
+	}
+}
+
+void icssg_class_add_mcast_sr1(struct regmap *miig_rt, int slice,
+			       struct net_device *ndev)
+{
+	u8 sr_addr[6] = { 0x01, 0x80, 0xc2, 0, 0, 0 };
+	u8 cb_addr[6] = { 0x01, 0x00, 0x5e, 0, 0, 0 };
+	u8 mask_addr[6] = { 0, 0, 0, 0, 0, 0xff };
+	struct netdev_hw_addr *ha;
+	int slot = 2;
+
+	rx_class_ft1_set_start_len(miig_rt, slice, 0, 6);
+	/* reserve first 2 slots for
+	 *	1) 01-80-C2-00-00-XX Known Service Ethernet Multicast addresses
+	 *	2) 01-00-5e-00-00-XX Local Network Control Block
+	 *			      (224.0.0.0 - 224.0.0.255  (224.0.0/24))
+	 */
+	icssg_class_ft1_add_mcast(miig_rt, slice, 0, sr_addr, mask_addr);
+	icssg_class_ft1_add_mcast(miig_rt, slice, 1, cb_addr, mask_addr);
+	mask_addr[5] = 0;
+	netdev_for_each_mc_addr(ha, ndev) {
+		/* skip addresses matching reserved slots */
+		if (!memcmp(sr_addr, ha->addr, 5) ||
+		    !memcmp(cb_addr, ha->addr, 5)) {
+			netdev_dbg(ndev, "mcast skip %pM\n", ha->addr);
+			continue;
+		}
+
+		if (slot >= FT1_NUM_SLOTS) {
+			netdev_dbg(ndev,
+				   "can't add more than %d MC addresses, enabling allmulti\n",
+				   FT1_NUM_SLOTS);
+			icssg_class_default(miig_rt, slice, 1, true);
+			break;
+		}
+
+		netdev_dbg(ndev, "mcast add %pM\n", ha->addr);
+		icssg_class_ft1_add_mcast(miig_rt, slice, slot,
+					  ha->addr, mask_addr);
+		slot++;
+	}
+}
+
 /* required for SAV check */
 void icssg_ft1_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac_addr)
 {
diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.c b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
index 63f9bbea8237..fae5e5bbb180 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
@@ -1329,7 +1329,7 @@ static int emac_ndo_open(struct net_device *ndev)
 	icssg_class_set_mac_addr(prueth->miig_rt, slice, emac->mac_addr);
 	icssg_ft1_set_mac_addr(prueth->miig_rt, slice, emac->mac_addr);
 
-	icssg_class_default(prueth->miig_rt, slice, 0);
+	icssg_class_default(prueth->miig_rt, slice, 0, emac->is_sr1);
 
 	/* Notify the stack of the actual queue counts. */
 	ret = netif_set_real_num_tx_queues(ndev, num_data_chn);
diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.h b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
index 1bdd3d301fde..c2221db25950 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
@@ -277,7 +277,11 @@ extern const struct ethtool_ops icssg_ethtool_ops;
 void icssg_class_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac);
 void icssg_class_set_host_mac_addr(struct regmap *miig_rt, const u8 *mac);
 void icssg_class_disable(struct regmap *miig_rt, int slice);
-void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti);
+void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti,
+			 bool is_sr1);
+void icssg_class_promiscuous_sr1(struct regmap *miig_rt, int slice);
+void icssg_class_add_mcast_sr1(struct regmap *miig_rt, int slice,
+			       struct net_device *ndev);
 void icssg_ft1_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac_addr);
 
 /* config helpers */
-- 
2.43.0



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:20 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:20 +0530
Subject: [RFC PATCH v3 11/17] irqchip: riscv-aplic: Add ACPI support
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-12-sunilvl@ventanamicro.com>

Add ACPI support in APLIC drivers. In ACPI, IO devices use Global System
Interrupts (GSI) which is a flat space split across multiple APLICs.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 arch/riscv/include/asm/irq.h             |  6 +++
 drivers/irqchip/irq-riscv-aplic-direct.c | 21 +++++---
 drivers/irqchip/irq-riscv-aplic-main.c   | 64 ++++++++++++++----------
 drivers/irqchip/irq-riscv-aplic-main.h   |  1 +
 drivers/irqchip/irq-riscv-aplic-msi.c    |  9 +++-
 5 files changed, 66 insertions(+), 35 deletions(-)

diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index 232314e5f007..df59192a157d 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -22,6 +22,12 @@
 #define APLIC_PLIC_ID(x) ((x) >> 24)
 #define IDC_CONTEXT_ID(x) ((x) & 0x0000ffff)
 
+#ifdef CONFIG_RISCV_APLIC
+struct fwnode_handle *aplic_get_gsi_domain_id(u32 gsi);
+#else
+static inline struct fwnode_handle *aplic_get_gsi_domain_id(u32 gsi) { return NULL; }
+#endif
+
 int __init acpi_get_intc_index_hartid(u32 index, unsigned long *hartid);
 int acpi_get_ext_intc_parent_hartid(u8 id, u32 idx, unsigned long *hartid);
 void acpi_get_plic_nr_contexts(u8 id, int *nr_contexts);
diff --git a/drivers/irqchip/irq-riscv-aplic-direct.c b/drivers/irqchip/irq-riscv-aplic-direct.c
index 9ed2666bfb5e..3e7a7e092120 100644
--- a/drivers/irqchip/irq-riscv-aplic-direct.c
+++ b/drivers/irqchip/irq-riscv-aplic-direct.c
@@ -4,6 +4,7 @@
  * Copyright (C) 2022 Ventana Micro Systems Inc.
  */
 
+#include <linux/acpi.h>
 #include <linux/bitops.h>
 #include <linux/cpu.h>
 #include <linux/interrupt.h>
@@ -14,6 +15,7 @@
 #include <linux/of_address.h>
 #include <linux/printk.h>
 #include <linux/smp.h>
+#include <asm/acpi.h>
 
 #include "irq-riscv-aplic-main.h"
 
@@ -203,17 +205,20 @@ static int aplic_direct_starting_cpu(unsigned int cpu)
 
 static int aplic_direct_parse_parent_hwirq(struct device *dev,
 					   u32 index, u32 *parent_hwirq,
-					   unsigned long *parent_hartid)
+					   unsigned long *parent_hartid,
+					   struct aplic_priv *priv)
 {
 	struct of_phandle_args parent;
 	int rc;
 
-	/*
-	 * Currently, only OF fwnode is supported so extend this
-	 * function for ACPI support.
-	 */
-	if (!is_of_node(dev->fwnode))
-		return -EINVAL;
+	if (!is_of_node(dev->fwnode)) {
+		rc = acpi_get_ext_intc_parent_hartid(priv->id, index, parent_hartid);
+		if (rc)
+			return rc;
+
+		*parent_hwirq = RV_IRQ_EXT;
+		return 0;
+	}
 
 	rc = of_irq_parse_one(to_of_node(dev->fwnode), index, &parent);
 	if (rc)
@@ -251,7 +256,7 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
 
 	/* Setup per-CPU IDC and target CPU mask */
 	for (i = 0; i < priv->nr_idcs; i++) {
-		rc = aplic_direct_parse_parent_hwirq(dev, i, &hwirq, &hartid);
+		rc = aplic_direct_parse_parent_hwirq(dev, i, &hwirq, &hartid, priv);
 		if (rc) {
 			dev_warn(dev, "parent irq for IDC%d not found\n", i);
 			continue;
diff --git a/drivers/irqchip/irq-riscv-aplic-main.c b/drivers/irqchip/irq-riscv-aplic-main.c
index d1b342b66551..31434b3ff690 100644
--- a/drivers/irqchip/irq-riscv-aplic-main.c
+++ b/drivers/irqchip/irq-riscv-aplic-main.c
@@ -4,12 +4,15 @@
  * Copyright (C) 2022 Ventana Micro Systems Inc.
  */
 
+#include <linux/acpi.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/printk.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/irqchip/riscv-aplic.h>
+#include <linux/irqchip/riscv-imsic.h>
+#include <asm/acpi.h>
 
 #include "irq-riscv-aplic-main.h"
 
@@ -137,38 +140,44 @@ int aplic_setup_priv(struct aplic_priv *priv, struct device *dev,
 		     void __iomem *regs)
 {
 	struct of_phandle_args parent;
+	struct acpi_madt_aplic *aplic;
 	int rc;
 
-	/*
-	 * Currently, only OF fwnode is supported so extend this
-	 * function for ACPI support.
-	 */
-	if (!is_of_node(dev->fwnode))
-		return -EINVAL;
-
 	/* Save device pointer and register base */
 	priv->dev = dev;
 	priv->regs = regs;
 
-	/* Find out number of interrupt sources */
-	rc = of_property_read_u32(to_of_node(dev->fwnode),
-					     "riscv,num-sources",
-					     &priv->nr_irqs);
-	if (rc) {
-		dev_err(dev, "failed to get number of interrupt sources\n");
-		return rc;
-	}
-
-	/*
-	 * Find out number of IDCs based on parent interrupts
-	 *
-	 * If "msi-parent" property is present then we ignore the
-	 * APLIC IDCs which forces the APLIC driver to use MSI mode.
-	 */
-	if (!of_property_present(to_of_node(dev->fwnode), "msi-parent")) {
-		while (!of_irq_parse_one(to_of_node(dev->fwnode),
-					 priv->nr_idcs, &parent))
-			priv->nr_idcs++;
+	if (is_of_node(dev->fwnode)) {
+		/* Find out number of interrupt sources */
+		rc = of_property_read_u32(to_of_node(dev->fwnode),
+					  "riscv,num-sources",
+					  &priv->nr_irqs);
+		if (rc) {
+			dev_err(dev, "failed to get number of interrupt sources\n");
+			return rc;
+		}
+
+		/*
+		 * Find out number of IDCs based on parent interrupts
+		 *
+		 * If "msi-parent" property is present then we ignore the
+		 * APLIC IDCs which forces the APLIC driver to use MSI mode.
+		 */
+		if (!of_property_present(to_of_node(dev->fwnode), "msi-parent")) {
+			while (!of_irq_parse_one(to_of_node(dev->fwnode),
+						 priv->nr_idcs, &parent))
+				priv->nr_idcs++;
+		}
+	} else {
+		aplic = *(struct acpi_madt_aplic **)dev_get_platdata(dev);
+		if (!aplic) {
+			dev_err(dev, "APLIC platform data is NULL!\n");
+			return -1;
+		}
+		priv->gsi_base = aplic->gsi_base;
+		priv->nr_irqs = aplic->num_sources;
+		priv->nr_idcs = aplic->num_idcs;
+		priv->id = aplic->id;
 	}
 
 	/* Setup initial state APLIC interrupts */
@@ -204,6 +213,9 @@ static int aplic_probe(struct platform_device *pdev)
 	if (is_of_node(dev->fwnode))
 		msi_mode = of_property_present(to_of_node(dev->fwnode),
 						"msi-parent");
+	else
+		msi_mode = imsic_acpi_get_fwnode(NULL) ? 1 : 0;
+
 	if (msi_mode)
 		rc = aplic_msi_setup(dev, regs);
 	else
diff --git a/drivers/irqchip/irq-riscv-aplic-main.h b/drivers/irqchip/irq-riscv-aplic-main.h
index 78267ec58098..dc022e89bc97 100644
--- a/drivers/irqchip/irq-riscv-aplic-main.h
+++ b/drivers/irqchip/irq-riscv-aplic-main.h
@@ -28,6 +28,7 @@ struct aplic_priv {
 	u32			gsi_base;
 	u32			nr_irqs;
 	u32			nr_idcs;
+	u32			id;
 	void __iomem		*regs;
 	struct aplic_msicfg	msicfg;
 };
diff --git a/drivers/irqchip/irq-riscv-aplic-msi.c b/drivers/irqchip/irq-riscv-aplic-msi.c
index 086d00e0429e..03a8ac6554c4 100644
--- a/drivers/irqchip/irq-riscv-aplic-msi.c
+++ b/drivers/irqchip/irq-riscv-aplic-msi.c
@@ -178,6 +178,7 @@ static void aplic_msi_write_msg(struct msi_desc *desc, struct msi_msg *msg)
 int aplic_msi_setup(struct device *dev, void __iomem *regs)
 {
 	const struct imsic_global_config *imsic_global;
+	struct irq_domain *msi_domain;
 	struct irq_domain *irqdomain;
 	struct aplic_priv *priv;
 	struct aplic_msicfg *mc;
@@ -261,8 +262,14 @@ int aplic_msi_setup(struct device *dev, void __iomem *regs)
 		 * IMSIC and the IMSIC MSI domains are created later through
 		 * the platform driver probing so we set it explicitly here.
 		 */
-		if (is_of_node(dev->fwnode))
+		if (is_of_node(dev->fwnode)) {
 			of_msi_configure(dev, to_of_node(dev->fwnode));
+		} else {
+			msi_domain = irq_find_matching_fwnode(imsic_acpi_get_fwnode(dev),
+							      DOMAIN_BUS_PLATFORM_MSI);
+			if (msi_domain)
+				dev_set_msi_domain(dev, msi_domain);
+		}
 	}
 
 	/* Create irq domain instance for the APLIC MSI-mode */
-- 
2.39.2



From diogo.ivo at siemens.com  Tue Dec 19 09:45:46 2023
From: diogo.ivo at siemens.com (Diogo Ivo)
Date: Tue, 19 Dec 2023 17:45:46 +0000
Subject: [RFC PATCH net-next 8/8] net: ti: icssg-prueth: Wire up support for SR1.0
In-Reply-To: <20231219174548.3481-1-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
Message-ID: <20231219174548.3481-9-diogo.ivo@siemens.com>

Add the function calls to enable operation for SR1.0.

Based on the work of Roger Quadros, Vignesh Raghavendra and
Grygorii Strashko in TI's 5.10 SDK [1].

[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y

Co-developed-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
---
 drivers/net/ethernet/ti/icssg/icssg_prueth.c | 299 +++++++++++++++----
 1 file changed, 239 insertions(+), 60 deletions(-)

diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.c b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
index 75e23a7b3bb4..77a03a9c2843 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
@@ -169,6 +169,13 @@ static int emac_tx_complete_packets(struct prueth_emac *emac, int chn,
 						     desc_dma);
 		swdata = cppi5_hdesc_get_swdata(desc_tx);
 
+		/* was this command's TX complete? */
+		if (emac->is_sr1 && *(swdata) == emac->cmd_data) {
+			prueth_xmit_free(tx_chn, desc_tx);
+			budget++;	/* not a data packet */
+			continue;
+		}
+
 		skb = *(swdata);
 		prueth_xmit_free(tx_chn, desc_tx);
 
@@ -344,6 +351,7 @@ static int prueth_init_rx_chns(struct prueth_emac *emac,
 	struct net_device *ndev = emac->ndev;
 	u32 fdqring_id, hdesc_size;
 	int i, ret = 0, slice;
+	int flow_id_base;
 
 	slice = prueth_emac_slice(emac);
 	if (slice < 0)
@@ -384,8 +392,14 @@ static int prueth_init_rx_chns(struct prueth_emac *emac,
 		goto fail;
 	}
 
-	emac->rx_flow_id_base = k3_udma_glue_rx_get_flow_id_base(rx_chn->rx_chn);
-	netdev_dbg(ndev, "flow id base = %d\n", emac->rx_flow_id_base);
+	flow_id_base = k3_udma_glue_rx_get_flow_id_base(rx_chn->rx_chn);
+	if (!strcmp(name, "rxmgm")) {
+		emac->rx_mgm_flow_id_base = flow_id_base;
+		netdev_dbg(ndev, "mgm flow id base = %d\n", flow_id_base);
+	} else {
+		emac->rx_flow_id_base = flow_id_base;
+		netdev_dbg(ndev, "flow id base = %d\n", flow_id_base);
+	}
 
 	fdqring_id = K3_RINGACC_RING_ID_ANY;
 	for (i = 0; i < rx_cfg.flow_id_num; i++) {
@@ -494,10 +508,14 @@ static void emac_rx_timestamp(struct prueth_emac *emac,
 	struct skb_shared_hwtstamps *ssh;
 	u64 ns;
 
-	u32 hi_sw = readl(emac->prueth->shram.va +
-			  TIMESYNC_FW_WC_COUNT_HI_SW_OFFSET_OFFSET);
-	ns = icssg_ts_to_ns(hi_sw, psdata[1], psdata[0],
-			    IEP_DEFAULT_CYCLE_TIME_NS);
+	if (emac->is_sr1) {
+		ns = (u64)psdata[1] << 32 | psdata[0];
+	} else {
+		u32 hi_sw = readl(emac->prueth->shram.va +
+				  TIMESYNC_FW_WC_COUNT_HI_SW_OFFSET_OFFSET);
+		ns = icssg_ts_to_ns(hi_sw, psdata[1], psdata[0],
+				    IEP_DEFAULT_CYCLE_TIME_NS);
+	}
 
 	ssh = skb_hwtstamps(skb);
 	memset(ssh, 0, sizeof(*ssh));
@@ -1119,6 +1137,17 @@ struct icssg_firmwares {
 	char *txpru;
 };
 
+static struct icssg_firmwares icssg_emac_firmwares_sr1[] = {
+	{
+		.pru = "ti-pruss/am65x-pru0-prueth-fw.elf",
+		.rtu = "ti-pruss/am65x-rtu0-prueth-fw.elf",
+	},
+	{
+		.pru = "ti-pruss/am65x-pru1-prueth-fw.elf",
+		.rtu = "ti-pruss/am65x-rtu1-prueth-fw.elf",
+	}
+};
+
 static struct icssg_firmwares icssg_emac_firmwares[] = {
 	{
 		.pru = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
@@ -1138,7 +1167,8 @@ static int prueth_emac_start(struct prueth *prueth, struct prueth_emac *emac)
 	struct device *dev = prueth->dev;
 	int slice, ret;
 
-	firmwares = icssg_emac_firmwares;
+	firmwares = prueth->pdata.is_sr1 ? icssg_emac_firmwares_sr1
+					 : icssg_emac_firmwares;
 
 	slice = prueth_emac_slice(emac);
 	if (slice < 0) {
@@ -1164,11 +1194,15 @@ static int prueth_emac_start(struct prueth *prueth, struct prueth_emac *emac)
 		goto halt_pru;
 	}
 
-	ret = rproc_set_firmware(prueth->txpru[slice], firmwares[slice].txpru);
-	ret = rproc_boot(prueth->txpru[slice]);
-	if (ret) {
-		dev_err(dev, "failed to boot TX_PRU%d: %d\n", slice, ret);
-		goto halt_rtu;
+	if (!emac->is_sr1) {
+		ret = rproc_set_firmware(prueth->txpru[slice],
+					 firmwares[slice].txpru);
+		ret = rproc_boot(prueth->txpru[slice]);
+		if (ret) {
+			dev_err(dev, "failed to boot TX_PRU%d: %d\n",
+				slice, ret);
+			goto halt_rtu;
+		}
 	}
 
 	emac->fw_running = 1;
@@ -1201,7 +1235,8 @@ static void prueth_emac_stop(struct prueth_emac *emac)
 	}
 
 	emac->fw_running = 0;
-	rproc_shutdown(prueth->txpru[slice]);
+	if (!emac->is_sr1)
+		rproc_shutdown(prueth->txpru[slice]);
 	rproc_shutdown(prueth->rtu[slice]);
 	rproc_shutdown(prueth->pru[slice]);
 }
@@ -1269,11 +1304,15 @@ static void emac_adjust_link(struct net_device *ndev)
 			icssg_config_ipg(emac);
 			spin_unlock_irqrestore(&emac->lock, flags);
 			icssg_config_set_speed(emac);
-			emac_set_port_state(emac, ICSSG_EMAC_PORT_FORWARD);
+			if (!emac->is_sr1)
+				emac_set_port_state(emac, ICSSG_EMAC_PORT_FORWARD);
 
-		} else {
+		} else if (!emac->is_sr1) {
 			emac_set_port_state(emac, ICSSG_EMAC_PORT_DISABLE);
 		}
+
+		if (emac->is_sr1 && emac->link)
+			emac_change_port_speed_duplex_sr1(emac);
 	}
 
 	if (emac->link) {
@@ -1288,8 +1327,10 @@ static void emac_adjust_link(struct net_device *ndev)
 static int emac_napi_rx_poll(struct napi_struct *napi_rx, int budget)
 {
 	struct prueth_emac *emac = prueth_napi_to_emac(napi_rx);
-	int rx_flow = PRUETH_RX_FLOW_DATA_SR2;
-	int flow = PRUETH_MAX_RX_FLOWS_SR2;
+	int rx_flow = emac->is_sr1 ?
+			PRUETH_RX_FLOW_DATA_SR1 : PRUETH_RX_FLOW_DATA_SR2;
+	int flow = emac->is_sr1 ?
+			PRUETH_MAX_RX_FLOWS_SR1 : PRUETH_MAX_RX_FLOWS_SR2;
 	int num_rx = 0;
 	int cur_budget;
 	int ret;
@@ -1553,11 +1594,19 @@ static int emac_ndo_open(struct net_device *ndev)
 		memset_io(prueth->shram.va, 0, ICSSG_CONFIG_OFFSET_SLICE1 * PRUETH_NUM_MACS);
 	}
 
+	if (emac->is_sr1) {
+		/* For SR1, high priority channel is used exclusively for
+		 * management messages. Do reduce number of data channels.
+		 */
+		num_data_chn--;
+	}
+
 	/* set h/w MAC as user might have re-configured */
 	ether_addr_copy(emac->mac_addr, ndev->dev_addr);
 
 	icssg_class_set_mac_addr(prueth->miig_rt, slice, emac->mac_addr);
-	icssg_ft1_set_mac_addr(prueth->miig_rt, slice, emac->mac_addr);
+	if (!emac->is_sr1)
+		icssg_ft1_set_mac_addr(prueth->miig_rt, slice, emac->mac_addr);
 
 	icssg_class_default(prueth->miig_rt, slice, 0, emac->is_sr1);
 
@@ -1575,7 +1624,8 @@ static int emac_ndo_open(struct net_device *ndev)
 		return ret;
 	}
 
-	max_rx_flows = PRUETH_MAX_RX_FLOWS_SR2;
+	max_rx_flows = emac->is_sr1 ?
+			PRUETH_MAX_RX_FLOWS_SR1 : PRUETH_MAX_RX_FLOWS_SR2;
 	ret = prueth_init_rx_chns(emac, &emac->rx_chns, "rx",
 				  max_rx_flows, PRUETH_MAX_RX_DESC);
 	if (ret) {
@@ -1583,12 +1633,24 @@ static int emac_ndo_open(struct net_device *ndev)
 		goto cleanup_tx;
 	}
 
+	if (emac->is_sr1) {
+		ret = prueth_init_rx_chns(emac, &emac->rx_mgm_chn, "rxmgm",
+					  PRUETH_MAX_RX_MGM_FLOWS,
+					  PRUETH_MAX_RX_MGM_DESC);
+		if (ret) {
+			dev_err(dev, "failed to init rx mgmt channel: %d\n",
+				ret);
+			goto cleanup_rx;
+		}
+	}
+
 	ret = prueth_ndev_add_tx_napi(emac);
 	if (ret)
-		goto cleanup_rx;
+		goto cleanup_rx_mgm;
 
 	/* we use only the highest priority flow for now i.e. @irq[3] */
-	rx_flow = PRUETH_RX_FLOW_DATA_SR2;
+	rx_flow = emac->is_sr1 ?
+			PRUETH_RX_FLOW_DATA_SR1 : PRUETH_RX_FLOW_DATA_SR2;
 	ret = request_irq(emac->rx_chns.irq[rx_flow], prueth_rx_irq,
 			  IRQF_TRIGGER_HIGH, dev_name(dev), emac);
 	if (ret) {
@@ -1596,31 +1658,66 @@ static int emac_ndo_open(struct net_device *ndev)
 		goto cleanup_napi;
 	}
 
+	if (!emac->is_sr1)
+		goto skip_mgm_irq;
+
+	ret = request_threaded_irq(emac->rx_mgm_chn.irq[PRUETH_RX_MGM_FLOW_RESPONSE],
+				   NULL, prueth_rx_mgm_rsp_thread,
+				   IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
+				   dev_name(dev), emac);
+	if (ret) {
+		dev_err(dev, "unable to request RX Management RSP IRQ\n");
+		goto free_rx_irq;
+	}
+
+	ret = request_threaded_irq(emac->rx_mgm_chn.irq[PRUETH_RX_MGM_FLOW_TIMESTAMP],
+				   NULL, prueth_rx_mgm_ts_thread_sr1,
+				   IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
+				   dev_name(dev), emac);
+	if (ret) {
+		dev_err(dev, "unable to request RX Management TS IRQ\n");
+		goto free_rx_mgm_rsp_irq;
+	}
+
+skip_mgm_irq:
 	/* reset and start PRU firmware */
 	ret = prueth_emac_start(prueth, emac);
 	if (ret)
-		goto free_rx_irq;
+		goto free_rx_mgmt_ts_irq;
 
 	icssg_mii_update_mtu(prueth->mii_rt, slice, ndev->max_mtu);
 
-	if (!prueth->emacs_initialized) {
+	if (!emac->is_sr1 && !prueth->emacs_initialized) {
 		ret = icss_iep_init(emac->iep, &prueth_iep_clockops,
 				    emac, IEP_DEFAULT_CYCLE_TIME_NS);
 	}
 
-	ret = request_threaded_irq(emac->tx_ts_irq, NULL, prueth_tx_ts_irq,
-				   IRQF_ONESHOT, dev_name(dev), emac);
-	if (ret)
-		goto stop;
+	if (!emac->is_sr1) {
+		ret = request_threaded_irq(emac->tx_ts_irq, NULL,
+					   prueth_tx_ts_irq, IRQF_ONESHOT,
+					   dev_name(dev), emac);
+		if (ret)
+			goto stop;
+	}
 
 	/* Prepare RX */
 	ret = prueth_prepare_rx_chan(emac, &emac->rx_chns, PRUETH_MAX_PKT_SIZE);
 	if (ret)
 		goto free_tx_ts_irq;
 
+	if (emac->is_sr1) {
+		ret = prueth_prepare_rx_chan(emac, &emac->rx_mgm_chn, 64);
+		if (ret)
+			goto reset_rx_chn;
+
+		ret = k3_udma_glue_enable_rx_chn(emac->rx_mgm_chn.rx_chn);
+		if (ret)
+			goto reset_rx_chn;
+	}
+
 	ret = k3_udma_glue_enable_rx_chn(emac->rx_chns.rx_chn);
 	if (ret)
-		goto reset_rx_chn;
+		goto reset_rx_mgm_chn;
 
 	for (i = 0; i < emac->tx_ch_num; i++) {
 		ret = k3_udma_glue_enable_tx_chn(emac->tx_chns[i].tx_chn);
@@ -1647,16 +1744,33 @@ static int emac_ndo_open(struct net_device *ndev)
 	 * any SKB for completion. So set false to free_skb
 	 */
 	prueth_reset_tx_chan(emac, i, false);
+reset_rx_mgm_chn:
+	if (emac->is_sr1)
+		prueth_reset_rx_chan(&emac->rx_mgm_chn,
+				     PRUETH_MAX_RX_MGM_FLOWS, true);
 reset_rx_chn:
 	prueth_reset_rx_chan(&emac->rx_chns, max_rx_flows, false);
 free_tx_ts_irq:
-	free_irq(emac->tx_ts_irq, emac);
+	if (!emac->is_sr1)
+		free_irq(emac->tx_ts_irq, emac);
 stop:
 	prueth_emac_stop(emac);
+free_rx_mgmt_ts_irq:
+	if (emac->is_sr1)
+		free_irq(emac->rx_mgm_chn.irq[PRUETH_RX_MGM_FLOW_TIMESTAMP],
+			 emac);
+free_rx_mgm_rsp_irq:
+	if (emac->is_sr1)
+		free_irq(emac->rx_mgm_chn.irq[PRUETH_RX_MGM_FLOW_RESPONSE],
+			 emac);
 free_rx_irq:
 	free_irq(emac->rx_chns.irq[rx_flow], emac);
 cleanup_napi:
 	prueth_ndev_del_tx_napi(emac, emac->tx_ch_num);
+cleanup_rx_mgm:
+	if (emac->is_sr1)
+		prueth_cleanup_rx_chns(emac, &emac->rx_mgm_chn,
+				       PRUETH_MAX_RX_MGM_FLOWS);
 cleanup_rx:
 	prueth_cleanup_rx_chns(emac, &emac->rx_chns, max_rx_flows);
 cleanup_tx:
@@ -1677,7 +1791,8 @@ static int emac_ndo_stop(struct net_device *ndev)
 {
 	struct prueth_emac *emac = netdev_priv(ndev);
 	struct prueth *prueth = emac->prueth;
-	int rx_flow = PRUETH_RX_FLOW_DATA_SR2;
+	int rx_flow = emac->is_sr1 ? PRUETH_RX_FLOW_DATA_SR1 :
+				     PRUETH_RX_FLOW_DATA_SR2;
 	int max_rx_flows;
 	int ret, i;
 
@@ -1690,6 +1805,9 @@ static int emac_ndo_stop(struct net_device *ndev)
 
 	icssg_class_disable(prueth->miig_rt, prueth_emac_slice(emac));
 
+	if (emac->is_sr1)
+		emac_send_command_sr1(emac, ICSSG_SHUTDOWN_CMD);
+
 	atomic_set(&emac->tdown_cnt, emac->tx_ch_num);
 	/* ensure new tdown_cnt value is visible */
 	smp_mb__after_atomic();
@@ -1707,10 +1825,17 @@ static int emac_ndo_stop(struct net_device *ndev)
 	for (i = 0; i < emac->tx_ch_num; i++)
 		napi_disable(&emac->tx_chns[i].napi_tx);
 
-	max_rx_flows = PRUETH_MAX_RX_FLOWS_SR2;
+	max_rx_flows = emac->is_sr1 ?
+			PRUETH_MAX_RX_FLOWS_SR1 : PRUETH_MAX_RX_FLOWS_SR2;
 	k3_udma_glue_tdown_rx_chn(emac->rx_chns.rx_chn, true);
 
 	prueth_reset_rx_chan(&emac->rx_chns, max_rx_flows, true);
+	if (emac->is_sr1) {
+		/* Teardown RX MGM channel */
+		k3_udma_glue_tdown_rx_chn(emac->rx_mgm_chn.rx_chn, true);
+		prueth_reset_rx_chan(&emac->rx_mgm_chn,
+				     PRUETH_MAX_RX_MGM_FLOWS, true);
+	}
 
 	napi_disable(&emac->napi_rx);
 
@@ -1722,18 +1847,28 @@ static int emac_ndo_stop(struct net_device *ndev)
 	/* stop PRUs */
 	prueth_emac_stop(emac);
 
-	if (prueth->emacs_initialized == 1)
+	if (!emac->is_sr1 && prueth->emacs_initialized == 1)
 		icss_iep_exit(emac->iep);
 
 	/* stop PRUs */
 	prueth_emac_stop(emac);
 
-	free_irq(emac->tx_ts_irq, emac);
+	if (!emac->is_sr1)
+		free_irq(emac->tx_ts_irq, emac);
 
+	if (emac->is_sr1) {
+		free_irq(emac->rx_mgm_chn.irq[PRUETH_RX_MGM_FLOW_TIMESTAMP],
+			 emac);
+		free_irq(emac->rx_mgm_chn.irq[PRUETH_RX_MGM_FLOW_RESPONSE],
+			 emac);
+	}
 	free_irq(emac->rx_chns.irq[rx_flow], emac);
 	prueth_ndev_del_tx_napi(emac, emac->tx_ch_num);
 	prueth_cleanup_tx_chns(emac);
 
+	if (emac->is_sr1)
+		prueth_cleanup_rx_chns(emac, &emac->rx_mgm_chn,
+				       PRUETH_MAX_RX_MGM_FLOWS);
 	prueth_cleanup_rx_chns(emac, &emac->rx_chns, max_rx_flows);
 	prueth_cleanup_tx_chns(emac);
 
@@ -1814,7 +1949,10 @@ static void emac_ndo_set_rx_mode(struct net_device *ndev)
 {
 	struct prueth_emac *emac = netdev_priv(ndev);
 
-	queue_work(emac->cmd_wq, &emac->rx_mode_work);
+	if (emac->is_sr1)
+		emac_ndo_set_rx_mode_sr1(ndev);
+	else
+		queue_work(emac->cmd_wq, &emac->rx_mode_work);
 }
 
 static int emac_set_ts_config(struct net_device *ndev, struct ifreq *ifr)
@@ -1994,6 +2132,10 @@ static int prueth_netdev_init(struct prueth *prueth,
 	if (mac == PRUETH_MAC_INVALID)
 		return -EINVAL;
 
+	/* Use 1 channel for management messages on SR1 */
+	if (prueth->pdata.is_sr1)
+		num_tx_chn--;
+
 	ndev = alloc_etherdev_mq(sizeof(*emac), num_tx_chn);
 	if (!ndev)
 		return -ENOMEM;
@@ -2021,7 +2163,15 @@ static int prueth_netdev_init(struct prueth *prueth,
 		goto free_wq;
 	}
 
+	emac->is_sr1 = prueth->pdata.is_sr1;
 	emac->tx_ch_num = 1;
+	if (emac->is_sr1) {
+		/* use a dedicated high priority channel for management
+		 * messages which is +1 of highest priority data channel.
+		 */
+		emac->tx_ch_num++;
+		goto skip_irq;
+	}
 
 	irq_name = "tx_ts0";
 	if (emac->port_id == PRUETH_PORT_MII1)
@@ -2032,6 +2182,7 @@ static int prueth_netdev_init(struct prueth *prueth,
 		goto free;
 	}
 
+skip_irq:
 	SET_NETDEV_DEV(ndev, prueth->dev);
 	spin_lock_init(&emac->lock);
 	mutex_init(&emac->cmd_lock);
@@ -2158,7 +2309,7 @@ static int prueth_get_cores(struct prueth *prueth, int slice)
 		idx = 0;
 		break;
 	case ICSS_SLICE1:
-		idx = 3;
+		idx = prueth->pdata.is_sr1 ? 2 : 3;
 		break;
 	default:
 		return -EINVAL;
@@ -2180,6 +2331,9 @@ static int prueth_get_cores(struct prueth *prueth, int slice)
 		return dev_err_probe(dev, ret, "unable to get RTU%d\n", slice);
 	}
 
+	if (prueth->pdata.is_sr1)
+		return 0;
+
 	idx++;
 	prueth->txpru[slice] = pru_rproc_get(np, idx, NULL);
 	if (IS_ERR(prueth->txpru[slice])) {
@@ -2329,14 +2483,20 @@ static int prueth_probe(struct platform_device *pdev)
 		goto put_mem;
 	}
 
-	msmc_ram_size = MSMC_RAM_SIZE_SR2;
+	msmc_ram_size = prueth->pdata.is_sr1 ? MSMC_RAM_SIZE_SR1 : MSMC_RAM_SIZE_SR2;
 
-	/* NOTE: FW bug needs buffer base to be 64KB aligned */
-	prueth->msmcram.va =
-		(void __iomem *)gen_pool_alloc_algo(prueth->sram_pool,
-						    msmc_ram_size,
-						    gen_pool_first_fit_align,
-						    &gp_data);
+	if (prueth->pdata.is_sr1) {
+		prueth->msmcram.va =
+			(void __iomem *)gen_pool_alloc(prueth->sram_pool,
+						       msmc_ram_size);
+	} else {
+		/* NOTE: FW bug needs buffer base to be 64KB aligned */
+		prueth->msmcram.va =
+			(void __iomem *)gen_pool_alloc_algo(prueth->sram_pool,
+							    msmc_ram_size,
+							    gen_pool_first_fit_align,
+							    &gp_data);
+	}
 
 	if (!prueth->msmcram.va) {
 		ret = -ENOMEM;
@@ -2350,17 +2510,19 @@ static int prueth_probe(struct platform_device *pdev)
 	dev_dbg(dev, "sram: pa %llx va %p size %zx\n", prueth->msmcram.pa,
 		prueth->msmcram.va, prueth->msmcram.size);
 
-	prueth->iep0 = icss_iep_get_idx(np, 0);
-	if (IS_ERR(prueth->iep0)) {
-		ret = dev_err_probe(dev, PTR_ERR(prueth->iep0), "iep0 get failed\n");
-		prueth->iep0 = NULL;
-		goto free_pool;
-	}
+	if (!prueth->pdata.is_sr1) {
+		prueth->iep0 = icss_iep_get_idx(np, 0);
+		if (IS_ERR(prueth->iep0)) {
+			ret = dev_err_probe(dev, PTR_ERR(prueth->iep0), "iep0 get failed\n");
+			prueth->iep0 = NULL;
+			goto free_pool;
+		}
 
-	prueth->iep1 = icss_iep_get_idx(np, 1);
-	if (IS_ERR(prueth->iep1)) {
-		ret = dev_err_probe(dev, PTR_ERR(prueth->iep1), "iep1 get failed\n");
-		goto put_iep0;
+		prueth->iep1 = icss_iep_get_idx(np, 1);
+		if (IS_ERR(prueth->iep1)) {
+			ret = dev_err_probe(dev, PTR_ERR(prueth->iep1), "iep1 get failed\n");
+			goto put_iep0;
+		}
 	}
 
 	if (prueth->pdata.quirk_10m_link_issue) {
@@ -2382,7 +2544,8 @@ static int prueth_probe(struct platform_device *pdev)
 		if (of_find_property(eth0_node, "ti,half-duplex-capable", NULL))
 			prueth->emac[PRUETH_MAC0]->half_duplex = 1;
 
-		prueth->emac[PRUETH_MAC0]->iep = prueth->iep0;
+		if (!prueth->pdata.is_sr1)
+			prueth->emac[PRUETH_MAC0]->iep = prueth->iep0;
 	}
 
 	if (eth1_node) {
@@ -2396,7 +2559,8 @@ static int prueth_probe(struct platform_device *pdev)
 		if (of_find_property(eth1_node, "ti,half-duplex-capable", NULL))
 			prueth->emac[PRUETH_MAC1]->half_duplex = 1;
 
-		prueth->emac[PRUETH_MAC1]->iep = prueth->iep0;
+		if (!prueth->pdata.is_sr1)
+			prueth->emac[PRUETH_MAC1]->iep = prueth->iep0;
 	}
 
 	/* register the network devices */
@@ -2457,10 +2621,13 @@ static int prueth_probe(struct platform_device *pdev)
 exit_iep:
 	if (prueth->pdata.quirk_10m_link_issue)
 		icss_iep_exit_fw(prueth->iep1);
-	icss_iep_put(prueth->iep1);
+
+	if (!prueth->pdata.is_sr1)
+		icss_iep_put(prueth->iep1);
 
 put_iep0:
-	icss_iep_put(prueth->iep0);
+	if (!prueth->pdata.is_sr1)
+		icss_iep_put(prueth->iep0);
 	prueth->iep0 = NULL;
 	prueth->iep1 = NULL;
 
@@ -2511,15 +2678,21 @@ static void prueth_remove(struct platform_device *pdev)
 		prueth_netdev_exit(prueth, eth_node);
 	}
 
-	if (prueth->pdata.quirk_10m_link_issue)
+	if (prueth->pdata.is_sr1) {
+		icss_iep_exit(prueth->iep1);
+		icss_iep_exit(prueth->iep0);
+	} else if (prueth->pdata.quirk_10m_link_issue) {
 		icss_iep_exit_fw(prueth->iep1);
+	}
 
-	icss_iep_put(prueth->iep1);
-	icss_iep_put(prueth->iep0);
+	if (!prueth->pdata.is_sr1) {
+		icss_iep_put(prueth->iep1);
+		icss_iep_put(prueth->iep0);
+	}
 
 	gen_pool_free(prueth->sram_pool,
 		      (unsigned long)prueth->msmcram.va,
-		      MSMC_RAM_SIZE_SR2);
+		      prueth->pdata.is_sr1 ? MSMC_RAM_SIZE_SR1 : MSMC_RAM_SIZE_SR2);
 
 	pruss_release_mem_region(prueth->pruss, &prueth->shram);
 
@@ -2588,6 +2761,11 @@ static const struct dev_pm_ops prueth_dev_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(prueth_suspend, prueth_resume)
 };
 
+static const struct prueth_pdata am654_icssg_pdata_sr1 = {
+	.fdqring_mode = K3_RINGACC_RING_MODE_MESSAGE,
+	.is_sr1 = 1,
+};
+
 static const struct prueth_pdata am654_icssg_pdata = {
 	.fdqring_mode = K3_RINGACC_RING_MODE_MESSAGE,
 	.quirk_10m_link_issue = 1,
@@ -2598,6 +2776,7 @@ static const struct prueth_pdata am64x_icssg_pdata = {
 };
 
 static const struct of_device_id prueth_dt_match[] = {
+	{ .compatible = "ti,am654-icssg-prueth-sr1", .data = &am654_icssg_pdata_sr1 },
 	{ .compatible = "ti,am654-icssg-prueth", .data = &am654_icssg_pdata },
 	{ .compatible = "ti,am642-icssg-prueth", .data = &am64x_icssg_pdata },
 	{ /* sentinel */ }
-- 
2.43.0



From diogo.ivo at siemens.com  Tue Dec 19 09:45:45 2023
From: diogo.ivo at siemens.com (Diogo Ivo)
Date: Tue, 19 Dec 2023 17:45:45 +0000
Subject: [RFC PATCH net-next 7/8] net: ti: iccsg-prueth: Add necessary functions for SR1.0 support
In-Reply-To: <20231219174548.3481-1-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
Message-ID: <20231219174548.3481-8-diogo.ivo@siemens.com>

Add functions required to correctly program the SR1.0 firmware for
network operation.

Based on the work of Roger Quadros, Vignesh Raghavendra and
Grygorii Strashko in TI's 5.10 SDK [1].

[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y

Co-developed-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
---
 drivers/net/ethernet/ti/icssg/icssg_prueth.c | 255 +++++++++++++++++++
 1 file changed, 255 insertions(+)

diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.c b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
index fae5e5bbb180..75e23a7b3bb4 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
@@ -616,6 +616,101 @@ static int emac_get_tx_ts(struct prueth_emac *emac,
 	return 0;
 }
 
+static int emac_send_command_sr1(struct prueth_emac *emac, u32 cmd)
+{
+	dma_addr_t desc_dma, buf_dma;
+	struct prueth_tx_chn *tx_chn;
+	struct cppi5_host_desc_t *first_desc;
+	u32 *data = emac->cmd_data;
+	u32 pkt_len = sizeof(emac->cmd_data);
+	void **swdata;
+	int ret = 0;
+	u32 *epib;
+
+	netdev_dbg(emac->ndev, "Sending cmd %x\n", cmd);
+
+	/* only one command at a time allowed to firmware */
+	mutex_lock(&emac->cmd_lock);
+	data[0] = cpu_to_le32(cmd);
+
+	/* highest priority channel for management messages */
+	tx_chn = &emac->tx_chns[emac->tx_ch_num - 1];
+
+	/* Map the linear buffer */
+	buf_dma = dma_map_single(tx_chn->dma_dev, data, pkt_len, DMA_TO_DEVICE);
+	if (dma_mapping_error(tx_chn->dma_dev, buf_dma)) {
+		netdev_err(emac->ndev, "cmd %x: failed to map cmd buffer\n", cmd);
+		ret = -EINVAL;
+		goto err_unlock;
+	}
+
+	first_desc = k3_cppi_desc_pool_alloc(tx_chn->desc_pool);
+	if (!first_desc) {
+		netdev_err(emac->ndev, "cmd %x: failed to allocate descriptor\n", cmd);
+		dma_unmap_single(tx_chn->dma_dev, buf_dma, pkt_len, DMA_TO_DEVICE);
+		ret = -ENOMEM;
+		goto err_unlock;
+	}
+
+	cppi5_hdesc_init(first_desc, CPPI5_INFO0_HDESC_EPIB_PRESENT,
+			 PRUETH_NAV_PS_DATA_SIZE);
+	cppi5_hdesc_set_pkttype(first_desc, PRUETH_PKT_TYPE_CMD);
+	epib = first_desc->epib;
+	epib[0] = 0;
+	epib[1] = 0;
+
+	cppi5_hdesc_attach_buf(first_desc, buf_dma, pkt_len, buf_dma, pkt_len);
+	swdata = cppi5_hdesc_get_swdata(first_desc);
+	*swdata = data;
+
+	cppi5_hdesc_set_pktlen(first_desc, pkt_len);
+	desc_dma = k3_cppi_desc_pool_virt2dma(tx_chn->desc_pool, first_desc);
+
+	/* send command */
+	reinit_completion(&emac->cmd_complete);
+	ret = k3_udma_glue_push_tx_chn(tx_chn->tx_chn, first_desc, desc_dma);
+	if (ret) {
+		netdev_err(emac->ndev, "cmd %x: push failed: %d\n", cmd, ret);
+		goto free_desc;
+	}
+	ret = wait_for_completion_timeout(&emac->cmd_complete, msecs_to_jiffies(100));
+	if (!ret)
+		netdev_err(emac->ndev, "cmd %x: completion timeout\n", cmd);
+
+	mutex_unlock(&emac->cmd_lock);
+
+	return ret;
+free_desc:
+	prueth_xmit_free(tx_chn, first_desc);
+err_unlock:
+	mutex_unlock(&emac->cmd_lock);
+
+	return ret;
+}
+
+static void emac_change_port_speed_duplex_sr1(struct prueth_emac *emac)
+{
+	u32 cmd = ICSSG_PSTATE_SPEED_DUPLEX_CMD, val;
+	struct prueth *prueth = emac->prueth;
+	int slice = prueth_emac_slice(emac);
+
+	/* only full duplex supported for now */
+	if (emac->duplex != DUPLEX_FULL)
+		return;
+
+	val = icssg_rgmii_get_speed(prueth->miig_rt, slice);
+	/* firmware expects full duplex settings in bit 2-1 */
+	val <<= 1;
+	cmd |= val;
+
+	val = icssg_rgmii_get_fullduplex(prueth->miig_rt, slice);
+	/* firmware expects full duplex settings in bit 3 */
+	val <<= 3;
+	cmd |= val;
+
+	emac_send_command_sr1(emac, cmd);
+}
+
 static void tx_ts_work(struct prueth_emac *emac)
 {
 	struct skb_shared_hwtstamps ssh;
@@ -873,6 +968,141 @@ static irqreturn_t prueth_tx_ts_irq(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+/* get one packet from requested flow_id
+ *
+ * Returns skb pointer if packet found else NULL
+ * Caller must free the returned skb.
+ */
+static struct sk_buff *prueth_process_rx_mgm(struct prueth_emac *emac,
+					     u32 flow_id)
+{
+	struct prueth_rx_chn *rx_chn = &emac->rx_mgm_chn;
+	struct net_device *ndev = emac->ndev;
+	struct cppi5_host_desc_t *desc_rx;
+	struct sk_buff *skb, *new_skb;
+	dma_addr_t desc_dma, buf_dma;
+	u32 buf_dma_len, pkt_len;
+	void **swdata;
+	int ret;
+
+	ret = k3_udma_glue_pop_rx_chn(rx_chn->rx_chn, flow_id, &desc_dma);
+	if (ret) {
+		if (ret != -ENODATA)
+			netdev_err(ndev, "rx mgm pop: failed: %d\n", ret);
+		return NULL;
+	}
+
+	if (cppi5_desc_is_tdcm(desc_dma)) /* Teardown */
+		return NULL;
+
+	desc_rx = k3_cppi_desc_pool_dma2virt(rx_chn->desc_pool, desc_dma);
+
+	/* Fix FW bug about incorrect PSDATA size */
+	if (cppi5_hdesc_get_psdata_size(desc_rx) != PRUETH_NAV_PS_DATA_SIZE) {
+		cppi5_hdesc_update_psdata_size(desc_rx,
+					       PRUETH_NAV_PS_DATA_SIZE);
+	}
+
+	swdata = cppi5_hdesc_get_swdata(desc_rx);
+	skb = *swdata;
+	cppi5_hdesc_get_obuf(desc_rx, &buf_dma, &buf_dma_len);
+	pkt_len = cppi5_hdesc_get_pktlen(desc_rx);
+
+	dma_unmap_single(rx_chn->dma_dev, buf_dma, buf_dma_len, DMA_FROM_DEVICE);
+	k3_cppi_desc_pool_free(rx_chn->desc_pool, desc_rx);
+
+	new_skb = netdev_alloc_skb_ip_align(ndev, PRUETH_MAX_PKT_SIZE);
+	/* if allocation fails we drop the packet but push the
+	 * descriptor back to the ring with old skb to prevent a stall
+	 */
+	if (!new_skb) {
+		netdev_err(ndev,
+			   "skb alloc failed, dropped mgm pkt from flow %d\n",
+			   flow_id);
+		new_skb = skb;
+		skb = NULL;	/* return NULL */
+	} else {
+		/* return the filled skb */
+		skb_put(skb, pkt_len);
+	}
+
+	/* queue another DMA */
+	ret = prueth_dma_rx_push(emac, new_skb, &emac->rx_mgm_chn);
+	if (WARN_ON(ret < 0))
+		dev_kfree_skb_any(new_skb);
+
+	return skb;
+}
+
+static void prueth_tx_ts_sr1(struct prueth_emac *emac,
+			     struct emac_tx_ts_response_sr1 *tsr)
+{
+	u64 ns;
+	struct skb_shared_hwtstamps ssh;
+	struct sk_buff *skb;
+
+	ns = (u64)tsr->hi_ts << 32 | tsr->lo_ts;
+
+	if (tsr->cookie >= PRUETH_MAX_TX_TS_REQUESTS) {
+		netdev_dbg(emac->ndev, "Invalid TX TS cookie 0x%x\n",
+			   tsr->cookie);
+		return;
+	}
+
+	skb = emac->tx_ts_skb[tsr->cookie];
+	emac->tx_ts_skb[tsr->cookie] = NULL;	/* free slot */
+
+	memset(&ssh, 0, sizeof(ssh));
+	ssh.hwtstamp = ns_to_ktime(ns);
+
+	skb_tstamp_tx(skb, &ssh);
+	dev_consume_skb_any(skb);
+}
+
+static irqreturn_t prueth_rx_mgm_ts_thread_sr1(int irq, void *dev_id)
+{
+	struct prueth_emac *emac = dev_id;
+	struct sk_buff *skb;
+
+	skb = prueth_process_rx_mgm(emac, PRUETH_RX_MGM_FLOW_TIMESTAMP);
+	if (!skb)
+		return IRQ_NONE;
+
+	prueth_tx_ts_sr1(emac, (void *)skb->data);
+	dev_kfree_skb_any(skb);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t prueth_rx_mgm_rsp_thread(int irq, void *dev_id)
+{
+	struct prueth_emac *emac = dev_id;
+	struct sk_buff *skb;
+	u32 rsp;
+
+	skb = prueth_process_rx_mgm(emac, PRUETH_RX_MGM_FLOW_RESPONSE);
+	if (!skb)
+		return IRQ_NONE;
+
+	/* Process command response */
+	rsp = le32_to_cpu(*(u32 *)skb->data);
+	if ((rsp & 0xffff0000) == ICSSG_SHUTDOWN_CMD) {
+		netdev_dbg(emac->ndev,
+			   "f/w Shutdown cmd resp %x\n", rsp);
+		complete(&emac->cmd_complete);
+	} else if ((rsp & 0xffff0000) ==
+		ICSSG_PSTATE_SPEED_DUPLEX_CMD) {
+		netdev_dbg(emac->ndev,
+			   "f/w Speed/Duplex cmd rsp %x\n",
+			    rsp);
+		complete(&emac->cmd_complete);
+	}
+
+	dev_kfree_skb_any(skb);
+
+	return IRQ_HANDLED;
+}
+
 static irqreturn_t prueth_rx_irq(int irq, void *dev_id)
 {
 	struct prueth_emac *emac = dev_id;
@@ -1517,6 +1747,31 @@ static void emac_ndo_tx_timeout(struct net_device *ndev, unsigned int txqueue)
 	ndev->stats.tx_errors++;
 }
 
+static void emac_ndo_set_rx_mode_sr1(struct net_device *ndev)
+{
+	struct prueth_emac *emac = netdev_priv(ndev);
+	struct prueth *prueth = emac->prueth;
+	int slice = prueth_emac_slice(emac);
+	bool promisc = ndev->flags & IFF_PROMISC;
+	bool allmulti = ndev->flags & IFF_ALLMULTI;
+
+	if (promisc) {
+		icssg_class_promiscuous_sr1(prueth->miig_rt, slice);
+		return;
+	}
+
+	if (allmulti) {
+		icssg_class_default(prueth->miig_rt, slice, 1, true);
+		return;
+	}
+
+	icssg_class_default(prueth->miig_rt, slice, 0, true);
+	if (!netdev_mc_empty(ndev)) {
+		/* program multicast address list into Classifier */
+		icssg_class_add_mcast_sr1(prueth->miig_rt, slice, ndev);
+	}
+}
+
 static void emac_ndo_set_rx_mode_work(struct work_struct *work)
 {
 	struct prueth_emac *emac = container_of(work, struct prueth_emac, rx_mode_work);
-- 
2.43.0



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:21 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:21 +0530
Subject: [RFC PATCH v3 12/17] irqchip: irq-sifive-plic: Add ACPI support
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-13-sunilvl@ventanamicro.com>

Add ACPI support in PLIC driver. In ACPI, IO devices use Global System
Interrupts (GSI) which is a flat space split across multiple PLICs.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
Co-developed-by: Haibo Xu <haibo1.xu at intel.com>
Signed-off-by: Haibo Xu <haibo1.xu at intel.com>
---
 arch/riscv/include/asm/irq.h      |  6 +++
 drivers/irqchip/irq-sifive-plic.c | 76 +++++++++++++++++++++++--------
 2 files changed, 64 insertions(+), 18 deletions(-)

diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index df59192a157d..7b14f3ebe242 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -28,6 +28,12 @@ struct fwnode_handle *aplic_get_gsi_domain_id(u32 gsi);
 static inline struct fwnode_handle *aplic_get_gsi_domain_id(u32 gsi) { return NULL; }
 #endif
 
+#ifdef CONFIG_SIFIVE_PLIC
+struct fwnode_handle *plic_get_gsi_domain_id(u32 gsi);
+#else
+static inline struct fwnode_handle *plic_get_gsi_domain_id(u32 gsi) { return NULL; }
+#endif
+
 int __init acpi_get_intc_index_hartid(u32 index, unsigned long *hartid);
 int acpi_get_ext_intc_parent_hartid(u8 id, u32 idx, unsigned long *hartid);
 void acpi_get_plic_nr_contexts(u8 id, int *nr_contexts);
diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
index c8f8a8cdcce1..d4c355ffa628 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -3,6 +3,7 @@
  * Copyright (C) 2017 SiFive
  * Copyright (C) 2018 Christoph Hellwig
  */
+#include <linux/acpi.h>
 #include <linux/cpu.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
@@ -70,6 +71,8 @@ struct plic_priv {
 	unsigned long plic_quirks;
 	unsigned int nr_irqs;
 	unsigned long *prio_save;
+	u32 gsi_base;
+	int id;
 };
 
 struct plic_handler {
@@ -316,6 +319,10 @@ static int plic_irq_domain_translate(struct irq_domain *d,
 {
 	struct plic_priv *priv = d->host_data;
 
+	/* For DT, gsi_base is always zero. */
+	if (fwspec->param[0] >= priv->gsi_base)
+		fwspec->param[0] = fwspec->param[0] - priv->gsi_base;
+
 	if (test_bit(PLIC_QUIRK_EDGE_INTERRUPT, &priv->plic_quirks))
 		return irq_domain_translate_twocell(d, fwspec, hwirq, type);
 
@@ -417,17 +424,31 @@ static const struct of_device_id plic_match[] = {
 };
 
 static int plic_parse_nr_irqs_and_contexts(struct platform_device *pdev,
-					   u32 *nr_irqs, u32 *nr_contexts)
+					   u32 *nr_irqs, u32 *nr_contexts,
+					   u32 *gsi_base, u32 *id)
 {
 	struct device *dev = &pdev->dev;
+	struct acpi_madt_plic *plic;
 	int rc;
 
-	/*
-	 * Currently, only OF fwnode is supported so extend this
-	 * function for ACPI support.
-	 */
-	if (!is_of_node(dev->fwnode))
-		return -EINVAL;
+	if (!is_of_node(dev->fwnode)) {
+		plic = *(struct acpi_madt_plic **)dev_get_platdata(dev);
+		if (!plic) {
+			dev_err(dev, "PLIC platform data is NULL!\n");
+			return -EINVAL;
+		}
+
+		*nr_irqs = plic->num_irqs;
+		acpi_get_plic_nr_contexts(plic->id, nr_contexts);
+		if (WARN_ON(!*nr_contexts)) {
+			dev_err(dev, "no PLIC context available\n");
+			return -EINVAL;
+		}
+
+		*gsi_base = plic->gsi_base;
+		*id = plic->id;
+		return 0;
+	}
 
 	rc = of_property_read_u32(to_of_node(dev->fwnode),
 				  "riscv,ndev", nr_irqs);
@@ -442,23 +463,28 @@ static int plic_parse_nr_irqs_and_contexts(struct platform_device *pdev,
 		return -EINVAL;
 	}
 
+	*gsi_base = 0;
+	*id = 0;
+
 	return 0;
 }
 
 static int plic_parse_context_parent_hwirq(struct platform_device *pdev,
-					   u32 context, u32 *parent_hwirq,
+					   u32 context, u32 id, u32 *parent_hwirq,
 					   unsigned long *parent_hartid)
 {
 	struct device *dev = &pdev->dev;
 	struct of_phandle_args parent;
 	int rc;
 
-	/*
-	 * Currently, only OF fwnode is supported so extend this
-	 * function for ACPI support.
-	 */
-	if (!is_of_node(dev->fwnode))
-		return -EINVAL;
+	if (!is_of_node(dev->fwnode)) {
+		rc = acpi_get_ext_intc_parent_hartid(id, context, parent_hartid);
+		if (rc)
+			return rc;
+
+		*parent_hwirq = RV_IRQ_EXT;
+		return 0;
+	}
 
 	rc = of_irq_parse_one(to_of_node(dev->fwnode), context, &parent);
 	if (rc)
@@ -483,7 +509,9 @@ static int plic_probe(struct platform_device *pdev)
 	struct plic_priv *priv;
 	irq_hw_number_t hwirq;
 	struct resource *res;
+	int id, context_id;
 	bool cpuhp_setup;
+	u32 gsi_base;
 
 	if (is_of_node(dev->fwnode)) {
 		const struct of_device_id *id;
@@ -510,19 +538,21 @@ static int plic_probe(struct platform_device *pdev)
 		return -EIO;
 	}
 
-	rc = plic_parse_nr_irqs_and_contexts(pdev, &nr_irqs, &nr_contexts);
+	rc = plic_parse_nr_irqs_and_contexts(pdev, &nr_irqs, &nr_contexts, &gsi_base, &id);
 	if (rc) {
 		dev_err(dev, "failed to parse irqs and contexts\n");
 		return rc;
 	}
 	priv->nr_irqs = nr_irqs;
+	priv->gsi_base = gsi_base;
+	priv->id = id;
 
 	priv->prio_save = devm_bitmap_zalloc(dev, nr_irqs, GFP_KERNEL);
 	if (!priv->prio_save)
 		return -ENOMEM;
 
 	for (i = 0; i < nr_contexts; i++) {
-		rc = plic_parse_context_parent_hwirq(pdev, i,
+		rc = plic_parse_context_parent_hwirq(pdev, i, priv->id,
 						     &parent_hwirq, &hartid);
 		if (rc) {
 			dev_warn(dev, "hwirq for context%d not found\n", i);
@@ -574,13 +604,23 @@ static int plic_probe(struct platform_device *pdev)
 			goto done;
 		}
 
+		if (is_of_node(dev->fwnode)) {
+			context_id = i;
+		} else {
+			rc = acpi_get_plic_context(priv->id, i, &context_id);
+			if (rc) {
+				dev_warn(dev, "invalid context id for context%d\n", i);
+				continue;
+			}
+		}
+
 		cpumask_set_cpu(cpu, &priv->lmask);
 		handler->present = true;
 		handler->hart_base = priv->regs + CONTEXT_BASE +
-			i * CONTEXT_SIZE;
+			context_id * CONTEXT_SIZE;
 		raw_spin_lock_init(&handler->enable_lock);
 		handler->enable_base = priv->regs + CONTEXT_ENABLE_BASE +
-			i * CONTEXT_ENABLE_SIZE;
+			context_id * CONTEXT_ENABLE_SIZE;
 		handler->priv = priv;
 
 		handler->enable_save =  devm_kcalloc(dev,
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:22 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:22 +0530
Subject: [RFC PATCH v3 13/17] ACPI: bus: Add RINTC IRQ model for RISC-V
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-14-sunilvl@ventanamicro.com>

Add the IRQ model for RISC-V INTC so that acpi_set_irq_model can use this
for RISC-V.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/acpi/bus.c   | 3 +++
 include/linux/acpi.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index a4aa53b7e2bb..9eace6c7042e 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1158,6 +1158,9 @@ static int __init acpi_bus_init_irq(void)
 	case ACPI_IRQ_MODEL_LPIC:
 		message = "LPIC";
 		break;
+	case ACPI_IRQ_MODEL_RINTC:
+		message = "RINTC";
+		break;
 	default:
 		pr_info("Unknown interrupt routing model\n");
 		return -ENODEV;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index ae045e14126b..b6766bded765 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -95,6 +95,7 @@ enum acpi_irq_model_id {
 	ACPI_IRQ_MODEL_PLATFORM,
 	ACPI_IRQ_MODEL_GIC,
 	ACPI_IRQ_MODEL_LPIC,
+	ACPI_IRQ_MODEL_RINTC,
 	ACPI_IRQ_MODEL_COUNT
 };
 
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:23 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:23 +0530
Subject: [RFC PATCH v3 14/17] ACPI: bus: Add acpi_riscv_init function
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-15-sunilvl@ventanamicro.com>

Add a new function for RISC-V to do any architecture specific
initialization. This function will be used to create platform devices
like APLIC, PLIC, RISC-V IOMMU etc. This is similar to acpi_arm_init().

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/acpi/bus.c          |  1 +
 drivers/acpi/riscv/Makefile |  2 +-
 drivers/acpi/riscv/init.c   | 12 ++++++++++++
 include/linux/acpi.h        |  6 ++++++
 4 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 drivers/acpi/riscv/init.c

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 9eace6c7042e..f7ac0caf04cf 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1417,6 +1417,7 @@ static int __init acpi_init(void)
 	acpi_hest_init();
 	acpi_ghes_init();
 	acpi_arm_init();
+	acpi_riscv_init();
 	acpi_scan_init();
 	acpi_ec_init();
 	acpi_debugfs_init();
diff --git a/drivers/acpi/riscv/Makefile b/drivers/acpi/riscv/Makefile
index f80b3da230e9..c4d679b1359e 100644
--- a/drivers/acpi/riscv/Makefile
+++ b/drivers/acpi/riscv/Makefile
@@ -1,2 +1,2 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-y 	+= rhct.o irq.o
+obj-y 	+= rhct.o irq.o init.o
diff --git a/drivers/acpi/riscv/init.c b/drivers/acpi/riscv/init.c
new file mode 100644
index 000000000000..b5807bbdb171
--- /dev/null
+++ b/drivers/acpi/riscv/init.c
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, Ventana Micro Systems Inc
+ *	Author: Sunil V L <sunilvl at ventanamicro.com>
+ *
+ */
+
+#include <linux/acpi.h>
+
+void __init acpi_riscv_init(void)
+{
+}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b6766bded765..60dc1f1e9351 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1536,6 +1536,12 @@ void acpi_arm_init(void);
 static inline void acpi_arm_init(void) { }
 #endif
 
+#ifdef CONFIG_RISCV
+void acpi_riscv_init(void);
+#else
+static inline void acpi_riscv_init(void) { }
+#endif
+
 #ifdef CONFIG_ACPI_PCC
 void acpi_init_pcc(void);
 #else
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:24 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:24 +0530
Subject: [RFC PATCH v3 15/17] ACPI: RISC-V: Create APLIC platform device
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-16-sunilvl@ventanamicro.com>

Since APLIC needs to be a platform device, probe the MADT and create
platform devices for each APLIC in the system.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/acpi/riscv/init.c |   2 +
 drivers/acpi/riscv/init.h |   5 ++
 drivers/acpi/riscv/irq.c  | 118 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 125 insertions(+)
 create mode 100644 drivers/acpi/riscv/init.h

diff --git a/drivers/acpi/riscv/init.c b/drivers/acpi/riscv/init.c
index b5807bbdb171..e7eff7ab1474 100644
--- a/drivers/acpi/riscv/init.c
+++ b/drivers/acpi/riscv/init.c
@@ -6,7 +6,9 @@
  */
 
 #include <linux/acpi.h>
+#include "init.h"
 
 void __init acpi_riscv_init(void)
 {
+	riscv_acpi_aplic_platform_init();
 }
diff --git a/drivers/acpi/riscv/init.h b/drivers/acpi/riscv/init.h
new file mode 100644
index 000000000000..17bcf0baaadb
--- /dev/null
+++ b/drivers/acpi/riscv/init.h
@@ -0,0 +1,5 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#include <linux/init.h>
+
+void __init riscv_acpi_imsic_platform_init(void);
+void __init riscv_acpi_aplic_platform_init(void);
diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
index 36e0525b3235..d08a851ab6dc 100644
--- a/drivers/acpi/riscv/irq.c
+++ b/drivers/acpi/riscv/irq.c
@@ -6,7 +6,36 @@
  */
 
 #include <linux/acpi.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/platform_device.h>
 #include <linux/sort.h>
+#include "init.h"
+
+static LIST_HEAD(ext_intc_list);
+
+struct ext_intc_fwnode_list {
+	struct fwnode_handle *fwnode;
+	u32 gsi_base;
+	u32 nr_irqs;
+	struct list_head list;
+};
+
+struct fwnode_handle *ext_entc_get_gsi_domain_id(u32 gsi)
+{
+	struct ext_intc_fwnode_list *ext_intc_element;
+	struct list_head *i, *tmp;
+
+	/* Find the External Interrupt controller that manages this GSI. */
+	list_for_each_safe(i, tmp, &ext_intc_list) {
+		ext_intc_element = list_entry(i, struct ext_intc_fwnode_list, list);
+		if (gsi >= ext_intc_element->gsi_base &&
+		    gsi < (ext_intc_element->gsi_base + ext_intc_element->nr_irqs))
+			return ext_intc_element->fwnode;
+	}
+
+	return NULL;
+}
 
 static int irqchip_cmp_func(const void *in0, const void *in1)
 {
@@ -30,3 +59,92 @@ void arch_sort_irqchip_probe(struct acpi_probe_entry *ap_head, int nr)
 		return;
 	sort(ape, nr, sizeof(*ape), irqchip_cmp_func, NULL);
 }
+
+static int __init irqchip_add_platform_device(char *irqchip_name, u32 irqchip_id,
+					      resource_size_t iomem_res_start,
+					      resource_size_t iomem_res_size,
+					      u32 gsi_base,
+					      u32 nr_irqs,
+					      union acpi_subtable_headers *header)
+{
+	struct ext_intc_fwnode_list *ext_intc_element;
+	struct platform_device *pdev;
+	struct fwnode_handle *fn;
+	struct resource *res;
+	int ret;
+
+	fn = irq_domain_alloc_named_id_fwnode(irqchip_name, irqchip_id);
+	if (!fn)
+		return -ENOMEM;
+
+	pdev = platform_device_alloc(irqchip_name, irqchip_id);
+	if (!pdev) {
+		irq_domain_free_fwnode(fn);
+		return -ENOMEM;
+	}
+
+	res = kcalloc(1, sizeof(*res), GFP_KERNEL);
+	if (!res) {
+		irq_domain_free_fwnode(fn);
+		platform_device_put(pdev);
+		return -ENOMEM;
+	}
+
+	ext_intc_element = kcalloc(1, sizeof(*ext_intc_element), GFP_KERNEL);
+	if (!ext_intc_element)
+		return -ENOMEM;
+
+	ext_intc_element->fwnode = fn;
+	ext_intc_element->gsi_base = gsi_base;
+	ext_intc_element->nr_irqs = nr_irqs;
+	list_add_tail(&ext_intc_element->list, &ext_intc_list);
+
+	res->start = iomem_res_start;
+	res->end = res->start + iomem_res_size - 1;
+	res->flags = IORESOURCE_MEM;
+	ret = platform_device_add_resources(pdev, res, 1);
+	/*
+	 * Resources are duplicated in platform_device_add_resources,
+	 * free their allocated memory
+	 */
+	kfree(res);
+
+	/*
+	 * Add copy of aplic pointer so that platform driver get aplic details.
+	 */
+	ret = platform_device_add_data(pdev, &header, sizeof(header));
+	if (ret) {
+		irq_domain_free_fwnode(fn);
+		platform_device_put(pdev);
+		return ret;
+	}
+
+	pdev->dev.fwnode = fn;
+	ret = platform_device_add(pdev);
+	if (ret) {
+		irq_domain_free_fwnode(fn);
+		platform_device_put(pdev);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int __init aplic_parse_madt(union acpi_subtable_headers *header,
+				   const unsigned long end)
+{
+	struct acpi_madt_aplic *aplic = (struct acpi_madt_aplic *)header;
+
+	return irqchip_add_platform_device("riscv-aplic",
+					   aplic->id,
+					   aplic->base_addr,
+					   aplic->size,
+					   aplic->gsi_base,
+					   aplic->num_sources,
+					   header);
+}
+
+void __init riscv_acpi_aplic_platform_init(void)
+{
+	acpi_table_parse_madt(ACPI_MADT_TYPE_APLIC, aplic_parse_madt, 0);
+}
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:25 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:25 +0530
Subject: [RFC PATCH v3 16/17] ACPI: RISC-V: Create PLIC platform device
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-17-sunilvl@ventanamicro.com>

Since PLIC needs to be a platform device, probe the MADT and create
platform devices for each PLIC in the system.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 drivers/acpi/riscv/init.c |  1 +
 drivers/acpi/riscv/init.h |  1 +
 drivers/acpi/riscv/irq.c  | 19 +++++++++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/drivers/acpi/riscv/init.c b/drivers/acpi/riscv/init.c
index e7eff7ab1474..c6fd4097e8ae 100644
--- a/drivers/acpi/riscv/init.c
+++ b/drivers/acpi/riscv/init.c
@@ -11,4 +11,5 @@
 void __init acpi_riscv_init(void)
 {
 	riscv_acpi_aplic_platform_init();
+	riscv_acpi_plic_platform_init();
 }
diff --git a/drivers/acpi/riscv/init.h b/drivers/acpi/riscv/init.h
index 17bcf0baaadb..b4b305d83b3a 100644
--- a/drivers/acpi/riscv/init.h
+++ b/drivers/acpi/riscv/init.h
@@ -3,3 +3,4 @@
 
 void __init riscv_acpi_imsic_platform_init(void);
 void __init riscv_acpi_aplic_platform_init(void);
+void __init riscv_acpi_plic_platform_init(void);
diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
index d08a851ab6dc..f14ea43b0178 100644
--- a/drivers/acpi/riscv/irq.c
+++ b/drivers/acpi/riscv/irq.c
@@ -148,3 +148,22 @@ void __init riscv_acpi_aplic_platform_init(void)
 {
 	acpi_table_parse_madt(ACPI_MADT_TYPE_APLIC, aplic_parse_madt, 0);
 }
+
+static int __init plic_parse_madt(union acpi_subtable_headers *header,
+				  const unsigned long end)
+{
+	struct acpi_madt_plic *plic = (struct acpi_madt_plic *)header;
+
+	return irqchip_add_platform_device("riscv-plic",
+					   plic->id,
+					   plic->base_addr,
+					   plic->size,
+					   plic->gsi_base,
+					   plic->num_irqs,
+					   header);
+}
+
+void __init riscv_acpi_plic_platform_init(void)
+{
+	acpi_table_parse_madt(ACPI_MADT_TYPE_PLIC, plic_parse_madt, 0);
+}
-- 
2.39.2



From sunilvl at ventanamicro.com  Tue Dec 19 09:45:26 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Tue, 19 Dec 2023 23:15:26 +0530
Subject: [RFC PATCH v3 17/17] irqchip: riscv-intc: Set ACPI irqmodel
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <20231219174526.2235150-18-sunilvl@ventanamicro.com>

INTC being the root interrupt controller, set the ACPI irqmodel with
callback function to get the GSI domain id.

Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
---
 arch/riscv/include/asm/irq.h     | 13 +------------
 drivers/irqchip/irq-riscv-intc.c |  1 +
 2 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
index 7b14f3ebe242..9c2bdf4bd880 100644
--- a/arch/riscv/include/asm/irq.h
+++ b/arch/riscv/include/asm/irq.h
@@ -22,18 +22,7 @@
 #define APLIC_PLIC_ID(x) ((x) >> 24)
 #define IDC_CONTEXT_ID(x) ((x) & 0x0000ffff)
 
-#ifdef CONFIG_RISCV_APLIC
-struct fwnode_handle *aplic_get_gsi_domain_id(u32 gsi);
-#else
-static inline struct fwnode_handle *aplic_get_gsi_domain_id(u32 gsi) { return NULL; }
-#endif
-
-#ifdef CONFIG_SIFIVE_PLIC
-struct fwnode_handle *plic_get_gsi_domain_id(u32 gsi);
-#else
-static inline struct fwnode_handle *plic_get_gsi_domain_id(u32 gsi) { return NULL; }
-#endif
-
+struct fwnode_handle *ext_entc_get_gsi_domain_id(u32 gsi);
 int __init acpi_get_intc_index_hartid(u32 index, unsigned long *hartid);
 int acpi_get_ext_intc_parent_hartid(u8 id, u32 idx, unsigned long *hartid);
 void acpi_get_plic_nr_contexts(u8 id, int *nr_contexts);
diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
index 24bbc5bfc30f..bddfe47df27b 100644
--- a/drivers/irqchip/irq-riscv-intc.c
+++ b/drivers/irqchip/irq-riscv-intc.c
@@ -311,6 +311,7 @@ static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header,
 		return rc;
 	}
 
+	acpi_set_irq_model(ACPI_IRQ_MODEL_RINTC, ext_entc_get_gsi_domain_id);
 	return 0;
 }
 
-- 
2.39.2



From rafael at kernel.org  Tue Dec 19 09:50:19 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Tue, 19 Dec 2023 18:50:19 +0100
Subject: [RFC PATCH v3 00/17] RISC-V: ACPI: Add external interrupt
 controller support
In-Reply-To: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
Message-ID: <CAJZ5v0j6Veze8xDFKTbVZ5=WAfmLdeJ8NXRnh9kwCZgyaDdgew@mail.gmail.com>

On Tue, Dec 19, 2023 at 6:45?PM Sunil V L <sunilvl at ventanamicro.com> wrote:
>
> This series adds support for the below ECR approved by ASWG.
> 1) MADT - https://drive.google.com/file/d/1oMGPyOD58JaPgMl1pKasT-VKsIKia7zR/view?usp=sharing
>
> The series primarily enables irqchip drivers for RISC-V ACPI based
> platforms.
>
> The series can be broadly categorized like below.
>
> 1) PCI ACPI related functions are migrated from arm64 to common file so
> that we don't need to duplicate them for RISC-V.
>
> 2) Introduced support for fw_devlink for ACPI nodes for IRQ dependency.
> This helps to support deferred probe of interrupt controller drivers.
>
> 3) Modified pnp_irq() to try registering the IRQ  again if it sees it in
> disabled state. This solution is similar to how
> platform_get_irq_optional() works for regular platform devices.
>
> 4) Added support for re-ordering the probe of interrupt controllers when
> IRQCHIP_ACPI_DECLARE is used.
>
> 5) ACPI support added in RISC-V interrupt controller drivers.
>
> This series is based on Anup's AIA v11 series. Since Anup's AIA v11 is
> not merged yet and first time introducing fw_devlink, deferred probe and
> reordering support for IRQCHIP probe, this series is still kept as RFC.
> Looking forward for the feedback!
>
> Changes since RFC v2:
>         1) Introduced fw_devlink for ACPI nodes for IRQ dependency.
>         2) Dropped patches in drivers which are not required due to
>            fw_devlink support.
>         3) Dropped pci_set_msi() patch and added a patch in
>            pci_create_root_bus().
>         4) Updated pnp_irq() patch so that none of the actual PNP
>            drivers need to change.
>
> Changes since RFC v1:
>         1) Abandoned swnode approach as per Marc's feedback.
>         2) To cope up with AIA series changes which changed irqchip driver
>            probe from core_initcall() to platform_driver, added patches
>            to support deferred probing.
>         3) Rebased on top of Anup's AIA v11 and added tags.
>
> To test the series,
>
> 1) Qemu should be built using the riscv_acpi_b2_v8 branch at
> https://github.com/vlsunil/qemu.git
>
> 2) EDK2 should be built using the instructions at:
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/RiscVVirt/README.md
>
> 3) Build Linux using this series on top of Anup's AIA v11 series.
>
> Run Qemu:
> qemu-system-riscv64 \
>  -M virt,pflash0=pflash0,pflash1=pflash1,aia=aplic-imsic \
>  -m 2G -smp 8 \
>  -serial mon:stdio \
>  -device virtio-gpu-pci -full-screen \
>  -device qemu-xhci \
>  -device usb-kbd \
>  -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \
>  -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \
>  -netdev user,id=net0 -device virtio-net-pci,netdev=net0 \
>  -kernel arch/riscv/boot/Image \
>  -initrd rootfs.cpio \
>  -append "root=/dev/ram ro console=ttyS0 rootwait earlycon=uart8250,mmio,0x10000000"
>
> To boot with APLIC only, use aia=aplic.
> To boot with PLIC, remove aia= option.
>
> This series is also available in acpi_b2_v3_riscv_aia_v11 branch at
> https://github.com/vlsunil/linux.git
>
> Based-on: 20231023172800.315343-1-apatel at ventanamicro.com
> (https://lore.kernel.org/lkml/20231023172800.315343-1-apatel at ventanamicro.com/)
>
> Sunil V L (17):
>   arm64: PCI: Migrate ACPI related functions to pci-acpi.c
>   RISC-V: ACPI: Implement PCI related functionality
>   PCI: Make pci_create_root_bus() declare its reliance on MSI domains
>   ACPI: Add fw_devlink support for ACPI fwnode for IRQ dependency
>   ACPI: irq: Add support for deferred probe in acpi_register_gsi()
>   pnp.h: Reconfigure IRQ in pnp_irq() to support deferred probe
>   ACPI: scan.c: Add weak arch specific function to reorder the IRQCHIP
>     probe
>   ACPI: RISC-V: Implement arch function to reorder irqchip probe entries
>   irqchip: riscv-intc: Add ACPI support for AIA
>   irqchip: riscv-imsic: Add ACPI support
>   irqchip: riscv-aplic: Add ACPI support
>   irqchip: irq-sifive-plic: Add ACPI support
>   ACPI: bus: Add RINTC IRQ model for RISC-V
>   ACPI: bus: Add acpi_riscv_init function
>   ACPI: RISC-V: Create APLIC platform device
>   ACPI: RISC-V: Create PLIC platform device
>   irqchip: riscv-intc: Set ACPI irqmodel

JFYI, I have no capacity to provide any feedback on this till 6.8-rc1 is out.

Thanks!


From konrad.dybcio at linaro.org  Tue Dec 19 09:59:14 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Tue, 19 Dec 2023 18:59:14 +0100
Subject: [PATCH v5 1/5] iommu/arm-smmu: re-enable context caching in smmu
 reset operation
In-Reply-To: <20231219135947.1623-2-quic_bibekkum@quicinc.com>
References: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
 <20231219135947.1623-2-quic_bibekkum@quicinc.com>
Message-ID: <810ee42b-49c9-4184-b5aa-a95261faf77a@linaro.org>

On 19.12.2023 14:59, Bibek Kumar Patro wrote:
> Default MMU-500 reset operation disables context caching in
> prefetch buffer. It is however expected for context banks using
> the ACTLR register to retain their prefetch value during reset
> and runtime suspend.
> 
> Replace default MMU-500 reset operation with Qualcomm specific reset
> operation which envelope the default reset operation and re-enables
> context caching in prefetch buffer for Qualcomm SoCs.
> 
> Suggested-by: Konrad Dybcio <konrad.dybcio at linaro.org>
Suggested-by implies I came up with this being a solution to
an issue.. definitely not the case!

Konrad


From broonie at kernel.org  Tue Dec 19 10:06:43 2023
From: broonie at kernel.org (Mark Brown)
Date: Tue, 19 Dec 2023 18:06:43 +0000
Subject: [v9 0/4] add es8326 dt-bindings, commonize headset codec API,
 es8326 support and Enable dual amp for rt5682s
In-Reply-To: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
References: <20231212123050.4080083-1-zhourui@huaqin.corp-partner.google.com>
Message-ID: <170300920399.125466.9978354781339951707.b4-ty@kernel.org>

On Tue, 12 Dec 2023 20:30:46 +0800, Rui Zhou wrote:
> Add dt-bindings for es8326 and codec es8326 support.
> Remove duplicate code, commonize headset codec init/exit API.
> At the same time, Enable dual amp max98390 for rt5682s.
> 
> Changes in v9:
> - PATCH 3/4: Add comment for MAX98390_TWO_AMP.
> - Link to v8: https://lore.kernel.org/all/20231208070933.720324-1-zhourui at huaqin.corp-partner.google.com/
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/4] ASoC: dt-bindings: mt8188-mt6359: add es8326 support
      commit: ea244b35a4da60a92d0e3be528f82ebcbcf10753
[2/4] ASoC: mediatek: mt8188-mt6359: commonize headset codec init/exit api
      commit: 1a268000b03a162bd5feb7fce1c130f1b31602b5
[3/4] ASoC: mediatek: mt8188-mt6359: add es8326 support
      commit: e794a894427b1d64f2ebff24f003c60373d68c2c
[4/4] ASoC: mediatek: mt8188-mt6359: Enable dual amp for mt8188-rt5682s
      commit: 3423c3db22e9213acd279ff3800bb1e91aa2ac89

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From luiz.dentz at gmail.com  Tue Dec 19 10:06:57 2023
From: luiz.dentz at gmail.com (Luiz Augusto von Dentz)
Date: Tue, 19 Dec 2023 13:06:57 -0500
Subject: [kernel PATCH v1] Bluetooth: btmtksdio: clear BTMTKSDIO_BT_WAKE_ENABLED
 after resume
In-Reply-To: <20231208130705.kernel.v1.1.Ic5024b3da99b11e39c247a5b8ba44876c18880a0@changeid>
References: <20231208130705.kernel.v1.1.Ic5024b3da99b11e39c247a5b8ba44876c18880a0@changeid>
Message-ID: <CABBYNZKOKOCzLkggM1PRXuFjsaU9-0=6WmdTxaF-s3v7WSzvhg@mail.gmail.com>

Hi Zhengping,

On Fri, Dec 8, 2023 at 4:07?PM Zhengping Jiang <jiangzp at google.com> wrote:
>
> Always clear BTMTKSDIO_BT_WAKE_ENABLED bit after resume. When Bluetooth
> does not generate interrupts, the bit will not be cleared and causes
> premature wakeup.
>
> Fixes: 4ed924fc122f ("Bluetooth: btmtksdio: enable bluetooth wakeup in system suspend")
> Signed-off-by: Zhengping Jiang <jiangzp at google.com>
> ---
>
> Changes in v1:
> - Clear BTMTKSDIO_BT_WAKE_ENABLED flag on resume
>
>  drivers/bluetooth/btmtksdio.c    | 10 ++++++++++
>  include/net/bluetooth/hci_core.h |  1 +
>  net/bluetooth/hci_sync.c         |  2 ++
>  3 files changed, 13 insertions(+)
>
> diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> index ff4868c83cd8..8f00b71573c8 100644
> --- a/drivers/bluetooth/btmtksdio.c
> +++ b/drivers/bluetooth/btmtksdio.c
> @@ -1296,6 +1296,15 @@ static bool btmtksdio_sdio_inband_wakeup(struct hci_dev *hdev)
>         return device_may_wakeup(bdev->dev);
>  }
>
> +static void btmtksdio_disable_bt_wakeup(struct hci_dev *hdev)
> +{
> +       struct btmtksdio_dev *bdev = hci_get_drvdata(hdev);
> +
> +       if (!bdev)
> +               return;
> +       clear_bit(BTMTKSDIO_BT_WAKE_ENABLED, &bdev->tx_state);
> +}
> +
>  static bool btmtksdio_sdio_wakeup(struct hci_dev *hdev)
>  {
>         struct btmtksdio_dev *bdev = hci_get_drvdata(hdev);
> @@ -1363,6 +1372,7 @@ static int btmtksdio_probe(struct sdio_func *func,
>         hdev->shutdown = btmtksdio_shutdown;
>         hdev->send     = btmtksdio_send_frame;
>         hdev->wakeup   = btmtksdio_sdio_wakeup;
> +       hdev->clear_wakeup = btmtksdio_disable_bt_wakeup;
>         /*
>          * If SDIO controller supports wake on Bluetooth, sending a wakeon
>          * command is not necessary.
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 0c1754f416bd..4bbd55335269 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -672,6 +672,7 @@ struct hci_dev {
>         int (*get_codec_config_data)(struct hci_dev *hdev, __u8 type,
>                                      struct bt_codec *codec, __u8 *vnd_len,
>                                      __u8 **vnd_data);
> +       void (*clear_wakeup)(struct hci_dev *hdev);

I wonder if it wouldn't be a better idea to add something like suspend
and resume callbacks to notify the about these hdev states, that way
we can synchronize the states better and avoid having to clear the
wakeup state when it shouldn't be active to begin with since the hdev
is not suspended.

>  };
>
>  #define HCI_PHY_HANDLE(handle) (handle & 0xff)
> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> index 3563a90ed2ac..6c4d5ce40524 100644
> --- a/net/bluetooth/hci_sync.c
> +++ b/net/bluetooth/hci_sync.c
> @@ -5947,6 +5947,8 @@ int hci_resume_sync(struct hci_dev *hdev)
>                 return 0;
>
>         hdev->suspended = false;
> +       if (hdev->clear_wakeup)
> +               hdev->clear_wakeup(hdev);
>
>         /* Restore event mask */
>         hci_set_event_mask_sync(hdev);
> --
> 2.43.0.472.g3155946c3a-goog
>


-- 
Luiz Augusto von Dentz


From gregkh at linuxfoundation.org  Tue Dec 19 10:13:43 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 19 Dec 2023 19:13:43 +0100
Subject: [PATCH V2 3/5] nvmem: u-boot-env: use more nvmem subsystem
 helpers
In-Reply-To: <20231219174025.15228-3-zajec5@gmail.com>
References: <20231219174025.15228-1-zajec5@gmail.com>
 <20231219174025.15228-3-zajec5@gmail.com>
Message-ID: <2023121929-salami-pessimist-c943@gregkh>

On Tue, Dec 19, 2023 at 06:40:23PM +0100, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> 1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
>    mtd dependent
> 2. Use nvmem_add_one_cell() to simplify adding NVMEM cells

Shouldn't this be 2 different patches?

thanks,

greg k-h


From zajec5 at gmail.com  Tue Dec 19 10:16:37 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 19 Dec 2023 19:16:37 +0100
Subject: [PATCH V2 3/5] nvmem: u-boot-env: use more nvmem subsystem
 helpers
In-Reply-To: <2023121929-salami-pessimist-c943@gregkh>
References: <20231219174025.15228-1-zajec5@gmail.com>
 <20231219174025.15228-3-zajec5@gmail.com>
 <2023121929-salami-pessimist-c943@gregkh>
Message-ID: <1b5d4c36-9963-476c-8edf-e807beceda80@gmail.com>

On 19.12.2023 19:13, Greg Kroah-Hartman wrote:
> On Tue, Dec 19, 2023 at 06:40:23PM +0100, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>
>> 1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
>>     mtd dependent
>> 2. Use nvmem_add_one_cell() to simplify adding NVMEM cells
> 
> Shouldn't this be 2 different patches?

I used to maintainers complaining my patches are too small and not the
other way ;) I think it happened two or three times with mtd subsys.

Sure, I can split it.


From daniel.lezcano at linaro.org  Tue Dec 19 10:17:11 2023
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 19 Dec 2023 19:17:11 +0100
Subject: [PATCH v6 0/9] Improve Exynos thermal driver
In-Reply-To: <20231201095625.301884-1-m.majewski2@samsung.com>
References: <CGME20231201095637eucas1p25e14bd24e05ae61eb12dee18af2a1dc5@eucas1p2.samsung.com>
 <20231201095625.301884-1-m.majewski2@samsung.com>
Message-ID: <dfed0e9b-f84c-4627-9540-a240d3724f21@linaro.org>

On 01/12/2023 10:56, Mateusz Majewski wrote:
> This work improves Exynos thermal driver in various ways. This is
> related to the discussion in
> https://lore.kernel.org/all/97201878-3bb8-eac5-7fac-a690322ac43a at linaro.org/
> 
> The primary issue being fixed is a lockdep warning, which is fixed by
> the thermal: exynos: use set_trips patch. We also simplify the code in
> general.
> 

Applied, thanks

-- 
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From maz at kernel.org  Tue Dec 19 10:22:44 2023
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 19 Dec 2023 18:22:44 +0000
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us in arch timer test
In-Reply-To: <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
	<0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
Message-ID: <8734vy832j.wl-maz@kernel.org>

On Tue, 12 Dec 2023 09:31:20 +0000,
Haibo Xu <haibo1.xu at intel.com> wrote:
> > @@ -216,6 +221,9 @@ static bool parse_args(int argc, char *argv[])
>  		case 'm':
>  			test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
>  			break;
> +		case 'e':
> +			test_args.timer_err_margin_us = atoi_non_negative("Error Margin", optarg);
> +			break;

So your error margin is always unsigned...

>  		case 'o':
>  			test_args.counter_offset = strtol(optarg, NULL, 0);
>  			test_args.reserved = 0;
> diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
> index 968257b893a7..b1d405e7157d 100644
> --- a/tools/testing/selftests/kvm/include/timer_test.h
> +++ b/tools/testing/selftests/kvm/include/timer_test.h
> @@ -22,6 +22,7 @@ struct test_args {
>  	int nr_iter;
>  	int timer_period_ms;
>  	int migration_freq_ms;
> +	int timer_err_margin_us;

... except that you are storing it as a signed value. Some consistency
wouldn't hurt, really, and would avoid issues when passing large
values.

	M.

-- 
Without deviation from the norm, progress is not possible.


From quic_eberman at quicinc.com  Tue Dec 19 10:24:57 2023
From: quic_eberman at quicinc.com (Elliot Berman)
Date: Tue, 19 Dec 2023 10:24:57 -0800
Subject: [PATCH v6 00/13] arm64: qcom: add and enable SHM Bridge support
In-Reply-To: <20231127141600.20929-1-brgl@bgdev.pl>
References: <20231127141600.20929-1-brgl@bgdev.pl>
Message-ID: <35eaac60-5617-4b42-bf1e-55d4f4dbbd2f@quicinc.com>



On 11/27/2023 6:15 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski at linaro.org>
> 
> This is pretty much another full rewrite of the SHM Bridge support
> series. After more on- and off-list discussions I think this time it
> will be close to the final thing though.
> 
> We've established the need for using separate pools for SCM and QSEECOM
> as well as the upcoming scminvoke driver.
> 
> It's also become clear that in order to be future-proof, the new
> allocator must be an abstraction layer of a higher level as the SHM
> Bridge will not be the only memory protection mechanism that we'll see
> upstream. Hence the rename to TrustZone Memory rather than SCM Memory
> allocator.
> 
> Also to that end: the new allocator is its own module now and provides a
> Kconfig choice menu for selecting the mode of operation (currently
> default and SHM Bridge).
> 
> Due to a high divergence from v2, I dropped all tags except for
> patch 1/15 which didn't change.
> 
> Tested on sm8550 and sa8775p with the Inline Crypto Engine and
> remoteproc.
> 
> v5 -> v6:
> Fixed two issues reported by autobuilders:
> - add a fix for memory leaks in the qseecom driver as the first patch for
>   easier backporting to the v6.6.y branch
> - explicitly cast the bus address stored in a variable of type dma_addr_t
>   to phys_addr_t expected by the genpool API
> 
> v4 -> v5:
> - fix the return value from qcom_tzmem_init() if SHM Bridge is not supported
> - remove a comment that's no longer useful
> - collect tags
> 
> v3 -> v4:
> - include linux/sizes.h for SZ_X macros
> - use dedicated RCU APIs to dereference radix tree slots
> - fix kerneldocs
> - fix the comment in patch 14/15: it's the hypervisor, not the TrustZone
>   that creates the SHM bridge
> 
> v2 -> v3:
> - restore pool management and use separate pools for different users
> - don't use the new allocator in qcom_scm_pas_init_image() as the
>   TrustZone will create an SHM bridge for us here
> - rewrite the entire series again for most part
> 
> v1 -> v2:
> - too many changes to list, it's a complete rewrite as explained above
> 
> Bartosz Golaszewski (13):
>   firmware: qcom: qseecom: fix memory leaks in error paths
>   firmware: qcom: add a dedicated TrustZone buffer allocator
>   firmware: qcom: scm: enable the TZ mem allocator
>   firmware: qcom: scm: smc: switch to using the SCM allocator
>   firmware: qcom: scm: make qcom_scm_assign_mem() use the TZ allocator
>   firmware: qcom: scm: make qcom_scm_ice_set_key() use the TZ allocator
>   firmware: qcom: scm: make qcom_scm_lmh_dcvsh() use the TZ allocator
>   firmware: qcom: scm: make qcom_scm_qseecom_app_get_id() use the TZ
>     allocator
>   firmware: qcom: qseecom: convert to using the TZ allocator
>   firmware: qcom: scm: add support for SHM bridge operations
>   firmware: qcom: tzmem: enable SHM Bridge support
>   firmware: qcom: scm: clarify the comment in qcom_scm_pas_init_image()
>   arm64: defconfig: enable SHM Bridge support for the TZ memory
>     allocator
> 
>  arch/arm64/configs/defconfig                  |   1 +
>  drivers/firmware/qcom/Kconfig                 |  30 ++
>  drivers/firmware/qcom/Makefile                |   1 +
>  .../firmware/qcom/qcom_qseecom_uefisecapp.c   | 261 +++++--------
>  drivers/firmware/qcom/qcom_scm-smc.c          |  30 +-
>  drivers/firmware/qcom/qcom_scm.c              | 179 +++++----
>  drivers/firmware/qcom/qcom_scm.h              |   6 +
>  drivers/firmware/qcom/qcom_tzmem.c            | 365 ++++++++++++++++++
>  drivers/firmware/qcom/qcom_tzmem.h            |  13 +
>  include/linux/firmware/qcom/qcom_qseecom.h    |   4 +-
>  include/linux/firmware/qcom/qcom_scm.h        |   6 +
>  include/linux/firmware/qcom/qcom_tzmem.h      |  28 ++
>  12 files changed, 669 insertions(+), 255 deletions(-)
>  create mode 100644 drivers/firmware/qcom/qcom_tzmem.c
>  create mode 100644 drivers/firmware/qcom/qcom_tzmem.h
>  create mode 100644 include/linux/firmware/qcom/qcom_tzmem.h
> 
Reviewed-by: Elliot Berman <quic_eberman at quicinc.com>


From gregkh at linuxfoundation.org  Tue Dec 19 10:33:06 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 19 Dec 2023 19:33:06 +0100
Subject: [PATCH] [ARM] locomo: make locomo_bus_type constant and static
Message-ID: <2023121905-idiom-opossum-1ba3@gregkh>

Now that the driver core can properly handle constant struct bus_type,
move the locomo_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.

It's also never used outside of arch/arm/common/locomo.c so make it
static and don't export it as no one is using it.

Cc: Russell King <linux at armlinux.org.uk>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
Cc: Randy Dunlap <rdunlap at infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/common/locomo.c               | 4 +++-
 arch/arm/include/asm/hardware/locomo.h | 2 --
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index 70480dd9e96d..6d0c9f7268ba 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -68,6 +68,8 @@ struct locomo {
 #endif
 };
 
+static const struct bus_type locomo_bus_type;
+
 struct locomo_dev_info {
 	unsigned long	offset;
 	unsigned long	length;
@@ -842,7 +844,7 @@ static void locomo_bus_remove(struct device *dev)
 		drv->remove(ldev);
 }
 
-struct bus_type locomo_bus_type = {
+static const struct bus_type locomo_bus_type = {
 	.name		= "locomo-bus",
 	.match		= locomo_match,
 	.probe		= locomo_bus_probe,
diff --git a/arch/arm/include/asm/hardware/locomo.h b/arch/arm/include/asm/hardware/locomo.h
index aaaedafef7cc..9fd9ad5d9202 100644
--- a/arch/arm/include/asm/hardware/locomo.h
+++ b/arch/arm/include/asm/hardware/locomo.h
@@ -158,8 +158,6 @@
 #define LOCOMO_LPT_TOH(TOH)	((TOH & 0x7) << 4)
 #define LOCOMO_LPT_TOL(TOL)	((TOL & 0x7))
 
-extern struct bus_type locomo_bus_type;
-
 #define LOCOMO_DEVID_KEYBOARD	0
 #define LOCOMO_DEVID_FRONTLIGHT	1
 #define LOCOMO_DEVID_BACKLIGHT	2
-- 
2.43.0



From jernej.skrabec at gmail.com  Tue Dec 19 10:54:23 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Tue, 19 Dec 2023 19:54:23 +0100
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <ljqe2z34upvzaxh744labf6ephmvcj535img2ct4d2vijjmboh@abg7anbngfyv>
References: <20231212122835.10850-2-retpolanne@posteo.net>
 <20231213122523.219cbfc0@donnerap.manchester.arm.com>
 <ljqe2z34upvzaxh744labf6ephmvcj535img2ct4d2vijjmboh@abg7anbngfyv>
Message-ID: <3456637.QJadu78ljV@jernej-laptop>

Dne torek, 19. december 2023 ob 01:31:05 CET je Anne Macedo napisal(a):
> On Wed, Dec 13, 2023 at 12:25:23PM +0000, Andre Przywara wrote:
> > On Wed, 13 Dec 2023 11:02:39 +0000
> > Anne Macedo <retpolanne at posteo.net> wrote:
> > 
> > Hi Anne,
> > 
> > > On Wed, Dec 13, 2023 at 01:35:44AM +0000, Andre Przywara wrote:
> > > > On Tue, 12 Dec 2023 19:27:14 +0000
> > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > 
> > > > Hi Anne,
> > > >   
> > > > > On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:  
> > > > > > On Tue, 12 Dec 2023 12:28:30 +0000
> > > > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > > > 
> > > > > > Hi Anne,
> > > > > >     
> > > > > > > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > > > > > > Realtek 8211 PHY to Orange Pi One Plus.    
> > > > > > 
> > > > > > So can you state why this would be needed? This is the RTL8211 ID,    
> > > > > 
> > > > > Apologies, I completely forgot to include some context. 
> > > > >   
> > > > > > right? Which should be autodetected via MDIO. Looking back in my inbox
> > > > > > you proposed this change before, for U-Boot, specifically, but I fail to
> > > > > > find a solution or explanation what really happens here. Two Renesas .dts
> > > > > > files have the same compatible, and the commit message talks about the
> > > > > > reset line there, is this related?
> > > > > > 
> > > > > > So can you please give some more background and explanation? That would be
> > > > > > part of a good commit message anyway ("why", not "what").    
> > > > > 
> > > > > Should I resend the commit with a more meaningful explanation? The
> > > > > context is the following:
> > > > > 
> > > > > currently, ethernet doesn't seem to work on both u-boot and Linux on the
> > > > > Orange Pi One Plus board. 
> > > > > 
> > > > > On the kernel, this error shows up:
> > > > > 
> > > > > Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > [    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> > > > > 
> > > > > After applying this fix, the PHY gets attached: 
> > > > > 
> > > > > Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > [    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
> > > > > 
> > > > > The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
> > > > > to find a PHY, so this patch includes the correct PHY ID with the
> > > > > RTL8211 ID. 
> > > > > 
> > > > > The behaviour is described on [1].  
> > > > 
> > > > So this is all an observation, but no real explanation, isn't it?  
> > > 
> > > I've made some analysis on [3] on this bug, but it was based solely on
> > > u-boot. I was having trouble with the regulator and on u-boot nothing
> > > would trigger the GPIO PD6 and the vcc-gmac-3v3 regulator, so the NIC
> > > was completely dead. Next I did an analysis based on [2] because the
> > > u-boot PHY initialization was flaky.
> > > 
> > > > To cite [1]: "If the PHY reports an incorrect ID (or none at all) ...".
> > > > I am pretty sure this is not the case here, instead we are looking at
> > > > some missing platform bits, like a missing clock, reset, or most likely
> > > > regulator. Or one of the existing resources is wrongly assigned or  
> > > 
> > > As I mentioned, PHY initialization is flaky on u-boot, so maybe that
> > > assumption is correct. 
> > > 
> > > > configured? If the PHY is not (yet?) powered correctly when the code
> > > > does the auto-detection via the MDIO bus, then the initialisation would  
> > > 
> > > If I recall correctly (I don't know if I kept it in my notes :c), that
> > > could be the case. regulator-boot-on makes the NIC work (LEDs blink, at
> > > least) but it doesn't get initialized. 
> > > 
> > > > fail. But since it works when overriding the auto-detection, I feel
> > > > like we are papering over something here.
> > > > Do you have the schematics for this board? I can only find the one for
> > > > the Orange Pi Plus 2E, and I don't know how similar those two are. This
> > > > shows *two* regulators, but both are activated by the same GPIO.  
> > > 
> > > I do. It's available on [4]
> > 
> > Oh damn it, I got lost in Orange Pi's naming maze again - and was looking
> > for the wrong board! So thanks for the link, and this clears things up!
> > 
> > So yes, the Orange Pi *One* Plus, much like the Orange Pi 3, uses *two*
> > regulators for Ethernet: one 3.3V from the PMIC's ALDO2 rail to power the
> > PHY, and a discrete 2.5V regulator, enabled by GPIO PD6, for the voltage
> > level on the MDIO lines. On top of this there is a reset line for the PHY,
> > though this is held up by a pull-up resistor, so it *should* work,
> > although we should describe this in the DT.
> > 
> > So the DT looks wrong then: The reg_gmac_3v3 is actually a 2.5V regulator,
> > and phy-supply is aldo2. I think it was done the way it is to somehow make
> > it work with the current DT binding and code, which just supports one
> > regulator. And aldo2 is referenced as the source of reg_gmac_3v3, which
> > smells like another hack to me.
> > 
> > > > It would also be interesting to see if any of Corentin's work for the
> > > > Orange Pi 3 helps here?  
> > > 
> > > Adding [5] for reference here, thanks! Will check it out. 
> > 
> > This is an older version, there are actually updates. And he also mentions
> > your board as well, so I think it just can sail in the wake of the OPi 3
> > Ethernet enablement.
> > 
> > Can you try if this change, just applied to your .dts instead, works?
> > https://github.com/montjoie/linux/commit/cf6e192eca1d59be630e6729d2cef9e897b3da8c
> 
> Hello, 
> 
> I've tried applying this change but it didn't seem to work :( 

Those patches are obsolete, I took over the work and latest patches are here:
https://github.com/jernejsk/linux-1/commits/opi3-net/ (last 3)

While I have OrangePi 3 and I have tested patches on it, I don't have Orange
Pi One Plus.

> 
> I got these errors:
> 
> [    5.117220] dwmac-sun8i 5020000.ethernet: IRQ eth_wake_irq not found
> [    5.124366] dwmac-sun8i 5020000.ethernet: IRQ eth_lpi not found
> [    5.130645] dwmac-sun8i 5020000.ethernet: No regulator found
> [    5.137133] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> [    5.143925] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
> [    5.157588] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
> [    5.164905] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
> [    5.172189] dwmac-sun8i 5020000.ethernet: COE Type 2
> [    5.177213] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
> [    5.184033] dwmac-sun8i 5020000.ethernet: Normal descriptors
> [    5.189724] dwmac-sun8i 5020000.ethernet: Chain mode enabled
> [    5.381149] dwmac-sun8i 5020000.ethernet: EMAC reset timeout
> [    5.386863] dwmac-sun8i 5020000.ethernet eth0: stmmac_dvr_remove: removing driver
> [    5.438851] dwmac-sun8i: probe of 5020000.ethernet failed with error -110
> 
> I think I understand what is going on in Corentin's patch though. Please
> correct me if I'm wrong:
> 
> 1. Instead of using the gmac-3v3, they use gmac-2v5 enabled by PD6.

Yes, 3v3 is completely wrong. Schematic only shows 2v5 regulator controlled
with PD6.

> 2. For "phy-io", the 2v5 regulator is used
> 3. For "ephy", the 3v3 regulator is used (aldo2 already sends this 3v3
> signal)

Correct.

> 
> My changes are here:
> https://github.com/retpolanne/linux/commit/45aa2abde2606f9164f9a97d092fab6a36d45165
> 
> Maybe I should try to use the existing 3v3 regulator alongside a new 2v5
> regulator on the DT. 

No.

Please make sure that you have
https://github.com/jernejsk/linux-1/commit/25b44143ea8162209beb02759ca3ea3bd3be7a74

Without it, ethernet PHY won't be powered on and you will get errors in dmesg.

Best regards,
Jernej

> > 
> > Cheers,
> > Andre
> > 
> > P.S. Is there any chance where I can reply/comment on your blog? It seems
> > like I can clear some things up...
> > 
> > > [3] https://blog.retpolanne.com/hardware/embedded/2023/07/07/embedded-phy.html
> > > [4] https://linux-sunxi.org/images/7/7c/OrangePi_OnePlus_Schematics_v2.0.pdf
> > > [5] https://lore.kernel.org/netdev/20220509074857.195302-1-clabbe at baylibre.com/
> > > 
> > > Regards, Anne
> > 
> 
> Regards, Anne
> 






From arnd at arndb.de  Tue Dec 19 11:27:19 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 19 Dec 2023 19:27:19 +0000
Subject: [PATCH] [ARM] locomo: make locomo_bus_type constant and static
In-Reply-To: <2023121905-idiom-opossum-1ba3@gregkh>
References: <2023121905-idiom-opossum-1ba3@gregkh>
Message-ID: <e5926d65-5fc9-4ab6-8b04-fdb6ba618a51@app.fastmail.com>

On Tue, Dec 19, 2023, at 18:33, Greg Kroah-Hartman wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the locomo_bus_type variable to be a constant structure as well,
> placing it into read-only memory which can not be modified at runtime.
>
> It's also never used outside of arch/arm/common/locomo.c so make it
> static and don't export it as no one is using it.

Reviewed-by: Arnd Bergmann <arnd at arndb.de>


From m.felsch at pengutronix.de  Tue Dec 19 11:29:12 2023
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Tue, 19 Dec 2023 20:29:12 +0100
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
Message-ID: <20231219192912.yulmczvqbuh4jizg@pengutronix.de>

Hi Peng,

On 23-12-15, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Add SCMI v3.2 pinctrl protocol bindings and example.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  .../devicetree/bindings/firmware/arm,scmi.yaml     | 99 ++++++++++++++++++++++
>  1 file changed, 99 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index 4591523b51a0..bfd2b6a89979 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -247,6 +247,85 @@ properties:
>        reg:
>          const: 0x18
>  
> +  protocol at 19:

...

> @@ -401,6 +480,26 @@ examples:
>              scmi_powercap: protocol at 18 {
>                  reg = <0x18>;
>              };
> +
> +            scmi_pinctrl: protocol at 19 {
> +                reg = <0x19>;
> +                #pinctrl-cells = <0>;
> +
> +                i2c2-pins {
> +                    groups = "i2c2_a", "i2c2_b";
> +                    function = "i2c2";
> +                };
> +
> +                mdio-pins {
> +                    groups = "avb_mdio";
> +                    drive-strength = <24>;
> +                };
> +
> +                keys_pins: keys-pins {
> +                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> +                    bias-pull-up;
> +                };
> +            };

This example is different to the one you mentioned within the
cover-letter. I didn't checked all patches just want to ask which API
will be implemented by this patchset?

Regards,
  Marco

>          };
>      };
>  
> 
> -- 
> 2.37.1
> 
> 
> 


From andersson at kernel.org  Tue Dec 19 11:33:36 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Tue, 19 Dec 2023 13:33:36 -0600
Subject: (subset) [PATCH V5 0/5] dts: qcom: Introduce X1E80100 platforms device tree
In-Reply-To: <20231205062403.14848-1-quic_sibis@quicinc.com>
References: <20231205062403.14848-1-quic_sibis@quicinc.com>
Message-ID: <170301441253.365364.18205363221847147285.b4-ty@kernel.org>


On Tue, 05 Dec 2023 11:53:58 +0530, Sibi Sankar wrote:
> This series adds the initial (clocks, pinctrl, rpmhpd, regulator, interconnect,
> CPU, SoC and board compatibles) device tree support to boot to shell on the
> Qualcomm X1E80100 platform, aka Snapdragon X Elite.
> 
> Our v1 post of the patchsets adding support for Snapdragon X Elite SoC had
> the part number sc8380xp which is now updated to the new part number x1e80100
> based on the new branding scheme and refers to the exact same SoC.
> 
> [...]

Applied, thanks!

[5/5] arm64: defconfig: Enable X1E80100 SoC base configs
      commit: 2e86e6300c4a98b1d0c93e03c491b0fd5d552eb5

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From andersson at kernel.org  Tue Dec 19 11:33:35 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Tue, 19 Dec 2023 13:33:35 -0600
Subject: [PATCH v2] arm64: defconfig: enable GPU clock controller for SM8[45]50
In-Reply-To: <20231218-topic-sm8x50-upstream-gpucc-defconfig-v2-1-e5892470a10b@linaro.org>
References: <20231218-topic-sm8x50-upstream-gpucc-defconfig-v2-1-e5892470a10b@linaro.org>
Message-ID: <170301441255.365364.1342268714697258363.b4-ty@kernel.org>


On Mon, 18 Dec 2023 11:30:23 +0100, Neil Armstrong wrote:
> Enable GPU Clock Controller for SM8450 and SM8550 to allow using
> Adreno GPU on these SoCs.
> 
> 

Applied, thanks!

[1/1] arm64: defconfig: enable GPU clock controller for SM8[45]50
      commit: e45167b2d3fd98b6553c30360f9d9bcbd737ce6c

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From wsa at kernel.org  Tue Dec 19 12:55:58 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 19 Dec 2023 21:55:58 +0100
Subject: [PATCH v4 1/2] i2c: aspeed: Handle the coalesced stop conditions
 with the start conditions.
In-Reply-To: <20231211102217.2436294-2-quan@os.amperecomputing.com>
References: <20231211102217.2436294-1-quan@os.amperecomputing.com>
 <20231211102217.2436294-2-quan@os.amperecomputing.com>
Message-ID: <ZYIDXru48jqk6MH0@shikoro>

On Mon, Dec 11, 2023 at 05:22:16PM +0700, Quan Nguyen wrote:
> Some masters may drive the transfers with low enough latency between
> the nak/stop phase of the current command and the start/address phase
> of the following command that the interrupts are coalesced by the
> time we process them.
> Handle the stop conditions before processing SLAVE_MATCH to fix the
> complaints that sometimes occur below.
> 
> "aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
> 0x00000086, but was 0x00000084"
> 
> Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> Reviewed-by: Andrew Jeffery <andrew at codeconstruct.com.au>
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Applied to for-current, thanks!

I'll wait with patch 2. It seems there are issues to be solved before.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/acfacb3b/attachment.sig>

From wsa at kernel.org  Tue Dec 19 13:01:23 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 19 Dec 2023 22:01:23 +0100
Subject: [PATCH] i2c: make i2c_bus_type const
In-Reply-To: <2023121942-jumble-unethical-3163@gregkh>
References: <2023121942-jumble-unethical-3163@gregkh>
Message-ID: <ZYIEo8H6Vz0psGOB@shikoro>

On Tue, Dec 19, 2023 at 04:22:43PM +0100, Greg Kroah-Hartman wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the i2c_bus_type variable to be a constant structure as well, placing
> it into read-only memory which can not be modified at runtime.
> 
> Note, the sound/soc/rockchip/rk3399_gru_sound.c also needed tweaking as
> it decided to save off a pointer to a bus type for internal stuff, and
> it was using the i2c_bus_type as well.
> 
> Cc: Wolfram Sang <wsa at kernel.org>
> Cc: Liam Girdwood <lgirdwood at gmail.com>
> Cc: Mark Brown <broonie at kernel.org>
> Cc: Jaroslav Kysela <perex at perex.cz>
> Cc: Takashi Iwai <tiwai at suse.com>
> Cc: Heiko Stuebner <heiko at sntech.de>
> Cc: linux-i2c at vger.kernel.org
> Cc: linux-sound at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-rockchip at lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/cf7e9574/attachment.sig>

From u.kleine-koenig at pengutronix.de  Tue Dec 19 13:21:20 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 19 Dec 2023 22:21:20 +0100
Subject: [PATCH] [ARM] locomo: make locomo_bus_type constant and static
In-Reply-To: <2023121905-idiom-opossum-1ba3@gregkh>
References: <2023121905-idiom-opossum-1ba3@gregkh>
Message-ID: <amnspbf2euablvmtl2bpng423cnkbjkvtsf7dhqmoyrzbgtpwb@3rgazgmuqjcx>

On Tue, Dec 19, 2023 at 07:33:06PM +0100, Greg Kroah-Hartman wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the locomo_bus_type variable to be a constant structure as well,
> placing it into read-only memory which can not be modified at runtime.
> 
> It's also never used outside of arch/arm/common/locomo.c so make it
> static and don't export it as no one is using it.
> 
> Cc: Russell King <linux at armlinux.org.uk>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
> Cc: Randy Dunlap <rdunlap at infradead.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> ---
>  arch/arm/common/locomo.c               | 4 +++-
>  arch/arm/include/asm/hardware/locomo.h | 2 --
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
> index 70480dd9e96d..6d0c9f7268ba 100644
> --- a/arch/arm/common/locomo.c
> +++ b/arch/arm/common/locomo.c
> @@ -68,6 +68,8 @@ struct locomo {
>  #endif
>  };
>  
> +static const struct bus_type locomo_bus_type;
> +

If you move up locomo_bus_type together with its three callbacks before
locomo_init_one_child, you don't need the extra declaration here.

That would be:

diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index 6d0c9f7268ba..676e98802561 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -68,8 +68,6 @@ struct locomo {
 #endif
 };
 
-static const struct bus_type locomo_bus_type;
-
 struct locomo_dev_info {
 	unsigned long	offset;
 	unsigned long	length;
@@ -216,6 +214,47 @@ static void locomo_dev_release(struct device *_dev)
 	kfree(dev);
 }
 
+/*
+ *	LoCoMo "Register Access Bus."
+ *
+ *	We model this as a regular bus type, and hang devices directly
+ *	off this.
+ */
+static int locomo_match(struct device *_dev, struct device_driver *_drv)
+{
+	struct locomo_dev *dev = LOCOMO_DEV(_dev);
+	struct locomo_driver *drv = LOCOMO_DRV(_drv);
+
+	return dev->devid == drv->devid;
+}
+
+static int locomo_bus_probe(struct device *dev)
+{
+	struct locomo_dev *ldev = LOCOMO_DEV(dev);
+	struct locomo_driver *drv = LOCOMO_DRV(dev->driver);
+	int ret = -ENODEV;
+
+	if (drv->probe)
+		ret = drv->probe(ldev);
+	return ret;
+}
+
+static void locomo_bus_remove(struct device *dev)
+{
+	struct locomo_dev *ldev = LOCOMO_DEV(dev);
+	struct locomo_driver *drv = LOCOMO_DRV(dev->driver);
+
+	if (drv->remove)
+		drv->remove(ldev);
+}
+
+static const struct bus_type locomo_bus_type = {
+	.name		= "locomo-bus",
+	.match		= locomo_match,
+	.probe		= locomo_bus_probe,
+	.remove		= locomo_bus_remove,
+};
+
 static int
 locomo_init_one_child(struct locomo *lchip, struct locomo_dev_info *info)
 {
@@ -810,47 +849,6 @@ void locomo_frontlight_set(struct locomo_dev *dev, int duty, int vr, int bpwf)
 }
 EXPORT_SYMBOL(locomo_frontlight_set);
 
-/*
- *	LoCoMo "Register Access Bus."
- *
- *	We model this as a regular bus type, and hang devices directly
- *	off this.
- */
-static int locomo_match(struct device *_dev, struct device_driver *_drv)
-{
-	struct locomo_dev *dev = LOCOMO_DEV(_dev);
-	struct locomo_driver *drv = LOCOMO_DRV(_drv);
-
-	return dev->devid == drv->devid;
-}
-
-static int locomo_bus_probe(struct device *dev)
-{
-	struct locomo_dev *ldev = LOCOMO_DEV(dev);
-	struct locomo_driver *drv = LOCOMO_DRV(dev->driver);
-	int ret = -ENODEV;
-
-	if (drv->probe)
-		ret = drv->probe(ldev);
-	return ret;
-}
-
-static void locomo_bus_remove(struct device *dev)
-{
-	struct locomo_dev *ldev = LOCOMO_DEV(dev);
-	struct locomo_driver *drv = LOCOMO_DRV(dev->driver);
-
-	if (drv->remove)
-		drv->remove(ldev);
-}
-
-static const struct bus_type locomo_bus_type = {
-	.name		= "locomo-bus",
-	.match		= locomo_match,
-	.probe		= locomo_bus_probe,
-	.remove		= locomo_bus_remove,
-};
-
 int locomo_driver_register(struct locomo_driver *driver)
 {
 	driver->drv.bus = &locomo_bus_type;

Feel free to squash this into your patch for a v2 if you like it.

Or is that better done as a separate change on top of yours?

Otherwise looks fine to me.

Acked-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/2206f7b1/attachment.sig>

From florian.fainelli at broadcom.com  Tue Dec 19 13:55:38 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Tue, 19 Dec 2023 22:55:38 +0100
Subject: [PATCH v5 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231219162236.36609-3-kamal.dasu@broadcom.com>
References: <20231219162236.36609-1-kamal.dasu@broadcom.com>
 <20231219162236.36609-3-kamal.dasu@broadcom.com>
Message-ID: <45b785bd-9b60-4ab7-80f9-b179d932d04d@broadcom.com>

Hi Kamal,

On 12/19/2023 5:22 PM, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> 74165b0 shall use a new sdio controller core version which
> requires a different reset sequence. For core reset we use
> sdhci_reset. For CMD and/or DATA reset added a new function
> to also enable SDHCI clocks SDHCI_CLOCK_CARD_EN
> SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
> SDHCI_RESET_DATA fields.
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> ---

[snip]

> +static void brcmstb_sdhci_reset_cmd_data(struct sdhci_host *host, u8 mask)
> +{
> +	int ret;
> +	u32 reg;
> +	u32 new_mask = (mask &  (SDHCI_RESET_CMD | SDHCI_RESET_DATA)) << 24;
> +
> +	/*
> +	 * SDHCI_CLOCK_CONTROL register CARD_EN and CLOCK_INT_EN bits shall
> +	 * be set along with SOFTWARE_RESET register RESET_CMD or RESET_DATA
> +	 * bits, hence access SDHCI_CLOCK_CONTROL register as 32-bit register
> +	 */
> +	new_mask |= SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN;
> +	reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
> +	sdhci_writel(host, reg | new_mask, SDHCI_CLOCK_CONTROL);
> +
> +	reg = sdhci_readb(host, SDHCI_SOFTWARE_RESET);
> +	ret = readb_poll_timeout(host->ioaddr + SDHCI_SOFTWARE_RESET,
> +				 reg, reg & mask, 10, 10000);

Does this need to be readb_poll_timeout_atomic() since this function can 
be used in both atomic and non-atomic context AFAIR?
-- 
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/5a5fde22/attachment-0001.p7s>

From tim at feathertop.org  Tue Dec 19 14:40:12 2023
From: tim at feathertop.org (Tim Lunn)
Date: Wed, 20 Dec 2023 09:40:12 +1100
Subject: [PATCH v3 3/8] i2c: rk3x: Adjust mask/value offset for i2c2 on
 rv1126
In-Reply-To: <ZYHNkgxAauYp6ivX@shikoro>
References: <20231203124004.2676174-1-tim@feathertop.org>
 <20231203124004.2676174-4-tim@feathertop.org> <ZYHNkgxAauYp6ivX@shikoro>
Message-ID: <14d972ed-87b3-4bad-a2f9-717f3d19d4a9@feathertop.org>

Hi Wolfram,

On 12/20/23 04:06, Wolfram Sang wrote:
> On Sun, Dec 03, 2023 at 11:39:59PM +1100, Tim Lunn wrote:
>> Rockchip RV1126 is using old style i2c controller, the i2c2
>> bus uses a non-sequential offset in the grf register for the
>> mask/value bits for this bus.
>>
>> This patch fixes i2c2 bus on rv1126 SoCs.
>>
>> Signed-off-by: Tim Lunn <tim at feathertop.org>
>> Acked-by: Heiko Stuebner <heiko at sntech.de>
>>
> Applied to for-next, thanks!
Thanks.
> But, phew, the fact that this driver _needs_ i2c-aliases in DT should be
> fixed somewhen. I totally overlooked this so far :/
>
Not sure what you mean here? I did add an alias for i2c2 in the DT in 
another patch.

Regards
 ?? Tim

>


From olteanv at gmail.com  Tue Dec 19 14:46:16 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Wed, 20 Dec 2023 00:46:16 +0200
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
In-Reply-To: <20231219172932.13f4b0c3@device-28.home>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <20231218162326.173127-2-romain.gantois@bootlin.com>
 <20231219122034.pg2djgrosa4irubh@skbuf>
 <20231219140754.7a7a8dbd@device-28.home>
 <CACRpkdaxy9u=1-rQ+f+1tb8xyV-GYOuq52xhb4_SRPk9-LpnUA@mail.gmail.com>
 <20231219172932.13f4b0c3@device-28.home>
Message-ID: <20231219224616.pw32w5eq2dbuja5i@skbuf>

On Tue, Dec 19, 2023 at 05:29:32PM +0100, Maxime Chevallier wrote:
> Hi Linus,
> 
> On Tue, 19 Dec 2023 15:19:45 +0100
> Linus Walleij <linus.walleij at linaro.org> wrote:
> 
> > On Tue, Dec 19, 2023 at 2:07?PM Maxime Chevallier
> > <maxime.chevallier at bootlin.com> wrote:
> > 
> > > So it looks like an acceptable solution would be something along the
> > > lines of what Linus is suggesting here :
> > >
> > > https://lore.kernel.org/netdev/20231216-new-gemini-ethernet-regression-v2-2-64c269413dfa at linaro.org/
> > >
> > > If so, maybe it's worth adding a new helper for that check ?  
> > 
> > Yeah it's a bit annoying when skb->protocol is not == ethertype of buffer.
> > 
> > I can certainly add a helper such as skb_eth_raw_ethertype()
> > to <linux/if_ether.h> that will inspect the actual ethertype in
> > skb->data.
> > 
> > It's the most straight-forward approach.
> 
> Agreed :)

If you rewrite that patch to use skb_vlan_eth_hdr() to get a struct
vlan_ethhdr pointer through which h_vlan_proto and h_vlan_encapsulated_proto
are accessible, I don't see much value in writing that helper. It is
going to beg the question how generic should it be - should it also
treat ETH_P_8021AD, should it treat nested VLANs?

At the end of the day, you are trying to cover in software the cases for
which the hardware engine can perform TX checksum offloading. That is
going to be hardware specific.

> > We could also add something like bool custom_ethertype; to
> > struct sk_buff and set that to true if the tagger adds a custom
> > ethertype. But I don't know how the network developers feel about
> > that.
> 
> I don't think this would be OK, first because sk_buff is pretty
> sensitive when it comes to cache alignment, adding things for this kind
> of use-cases isn't necessarily a good idea. Moreover, populating this
> flag isn't going to be straightforward as well. I guess some ethertype
> would be compatible with checksum engines, while other wouldn't, so
> probably what 'custom_ethertype' means will depend on the MAC driver.
> 
> From my point of view the first approach would indeed be better.

I guess we should first try to answer the questions "what does
skb->protocol represent?" and "does DSA use it correctly?" before
even thinking about adding yet another fuzzy layer on top it.


From heiko at sntech.de  Tue Dec 19 14:53:18 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 19 Dec 2023 23:53:18 +0100
Subject: [PATCH v3 3/8] i2c: rk3x: Adjust mask/value offset for i2c2 on rv1126
In-Reply-To: <ZYHNkgxAauYp6ivX@shikoro>
References: <20231203124004.2676174-1-tim@feathertop.org>
 <20231203124004.2676174-4-tim@feathertop.org> <ZYHNkgxAauYp6ivX@shikoro>
Message-ID: <3368267.VdNmn5OnKV@diego>

Hi Wolfram,

Am Dienstag, 19. Dezember 2023, 18:06:26 CET schrieb Wolfram Sang:
> On Sun, Dec 03, 2023 at 11:39:59PM +1100, Tim Lunn wrote:
> > Rockchip RV1126 is using old style i2c controller, the i2c2
> > bus uses a non-sequential offset in the grf register for the
> > mask/value bits for this bus.
> > 
> > This patch fixes i2c2 bus on rv1126 SoCs.
> > 
> > Signed-off-by: Tim Lunn <tim at feathertop.org>
> > Acked-by: Heiko Stuebner <heiko at sntech.de>
> > 
> 
> Applied to for-next, thanks!
> 
> But, phew, the fact that this driver _needs_ i2c-aliases in DT should be
> fixed somewhen. I totally overlooked this so far :/

Yeah, relying on aliases for this is probably not the most elegant thing
to do ;-)

Though right now I don't see the perfect way to change that.
Options I can think of, could be:

(1) As this really is "just" a thing for older socs that offer both a very
legacy i2c and the more modern one we use, I guess one possibility
would be to move this completely out of the i2c driver and into the
"grf-cleanup" driver [0].

We never actually implemented the "old"-style i2c driver for rk29xx
and earlier - and that thing is more than 10 years old now, so noone ever
will. So we always want to switch to the new one anyway in the kernel.


(2) The other option would be to try to identify the busses by their
address. We do this in some places, like the dsi driver [1]
with the entry matched against the reg property.


I guess from a "being done with it" perspective, the first option
would be nicer ;-) .

Thoughts?
Heiko


[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/rockchip/grf.c
That code does a number of settings the in the "General Register Files"
that we simply expect, so also doing the i2c controller switch there
for all i2c busses in one go would make sense.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c#n1586




From cristian.ciocaltea at collabora.com  Tue Dec 19 15:10:38 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Wed, 20 Dec 2023 01:10:38 +0200
Subject: [PATCH 0/1] StarFive DWMAC support for JH7100
Message-ID: <20231219231040.2459358-1-cristian.ciocaltea@collabora.com>

This is just a subset of the initial patch series [1] adding networking
support for StarFive JH7100 SoC.

[1]: https://lore.kernel.org/lkml/20231218214451.2345691-1-cristian.ciocaltea at collabora.com/

Cristian Ciocaltea (1):
  net: stmmac: dwmac-starfive: Add support for JH7100 SoC

 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 ++--
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 ++++++++++++++++---
 2 files changed, 31 insertions(+), 7 deletions(-)

-- 
2.43.0



From cristian.ciocaltea at collabora.com  Tue Dec 19 15:10:39 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Wed, 20 Dec 2023 01:10:39 +0200
Subject: [PATCH 1/1] net: stmmac: dwmac-starfive: Add support for JH7100 SoC
In-Reply-To: <20231219231040.2459358-1-cristian.ciocaltea@collabora.com>
References: <20231219231040.2459358-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231219231040.2459358-2-cristian.ciocaltea@collabora.com>

Add a missing quirk to enable support for the StarFive JH7100 SoC.

Additionally, for greater flexibility in operation, allow using the
rgmii-rxid and rgmii-txid phy modes.

Co-developed-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
Reviewed-by: Jacob Keller <jacob.e.keller at intel.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 ++--
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 ++++++++++++++++---
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 85dcda51df05..4ec61f1ee71a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -165,9 +165,9 @@ config DWMAC_STARFIVE
 	help
 	  Support for ethernet controllers on StarFive RISC-V SoCs
 
-	  This selects the StarFive platform specific glue layer support for
-	  the stmmac device driver. This driver is used for StarFive JH7110
-	  ethernet controller.
+	  This selects the StarFive platform specific glue layer support
+	  for the stmmac device driver. This driver is used for the
+	  StarFive JH7100 and JH7110 ethernet controllers.
 
 config DWMAC_STI
 	tristate "STi GMAC support"
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 5d630affb4d1..4e1076faee0c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -15,13 +15,20 @@
 
 #include "stmmac_platform.h"
 
-#define STARFIVE_DWMAC_PHY_INFT_RGMII	0x1
-#define STARFIVE_DWMAC_PHY_INFT_RMII	0x4
-#define STARFIVE_DWMAC_PHY_INFT_FIELD	0x7U
+#define STARFIVE_DWMAC_PHY_INFT_RGMII		0x1
+#define STARFIVE_DWMAC_PHY_INFT_RMII		0x4
+#define STARFIVE_DWMAC_PHY_INFT_FIELD		0x7U
+
+#define JH7100_SYSMAIN_REGISTER49_DLYCHAIN	0xc8
+
+struct starfive_dwmac_data {
+	unsigned int gtxclk_dlychain;
+};
 
 struct starfive_dwmac {
 	struct device *dev;
 	struct clk *clk_tx;
+	const struct starfive_dwmac_data *data;
 };
 
 static void starfive_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode)
@@ -67,6 +74,8 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 
 	case PHY_INTERFACE_MODE_RGMII:
 	case PHY_INTERFACE_MODE_RGMII_ID:
+	case PHY_INTERFACE_MODE_RGMII_RXID:
+	case PHY_INTERFACE_MODE_RGMII_TXID:
 		mode = STARFIVE_DWMAC_PHY_INFT_RGMII;
 		break;
 
@@ -89,6 +98,14 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 	if (err)
 		return dev_err_probe(dwmac->dev, err, "error setting phy mode\n");
 
+	if (dwmac->data) {
+		err = regmap_write(regmap, JH7100_SYSMAIN_REGISTER49_DLYCHAIN,
+				   dwmac->data->gtxclk_dlychain);
+		if (err)
+			return dev_err_probe(dwmac->dev, err,
+					     "error selecting gtxclk delay chain\n");
+	}
+
 	return 0;
 }
 
@@ -114,6 +131,8 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	if (!dwmac)
 		return -ENOMEM;
 
+	dwmac->data = device_get_match_data(&pdev->dev);
+
 	dwmac->clk_tx = devm_clk_get_enabled(&pdev->dev, "tx");
 	if (IS_ERR(dwmac->clk_tx))
 		return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_tx),
@@ -144,8 +163,13 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
 }
 
+static const struct starfive_dwmac_data jh7100_data = {
+	.gtxclk_dlychain = 4,
+};
+
 static const struct of_device_id starfive_dwmac_match[] = {
-	{ .compatible = "starfive,jh7110-dwmac"	},
+	{ .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
+	{ .compatible = "starfive,jh7110-dwmac" },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
-- 
2.43.0



From robh at kernel.org  Tue Dec 19 15:13:26 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 19 Dec 2023 17:13:26 -0600
Subject: [PATCH v2 2/6] ASoC: dt-bindings: Add Rockchip RK3308 internal
 audio codec
In-Reply-To: <20231219-rk3308-audio-codec-v2-2-c70d06021946@bootlin.com>
References: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
 <20231219-rk3308-audio-codec-v2-2-c70d06021946@bootlin.com>
Message-ID: <170302760623.2025074.2958729782154314139.robh@kernel.org>


On Tue, 19 Dec 2023 15:54:17 +0100, Luca Ceresoli wrote:
> Add device tree bindings document for the internal audio codec of the
> Rockchip RK3308 SoC.
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli at bootlin.com>
> 
> ---
> 
> Changed in v2:
>  - reword commit title
>  - add maxItems to resets
>  - remove quotes from reset-names
>  - use percent values for rockchip,micbias-avdd-multiplier
>  - use name compliant to the docs in the example
> ---
>  .../bindings/sound/rockchip,rk3308-codec.yaml      | 98 ++++++++++++++++++++++
>  MAINTAINERS                                        |  5 ++
>  2 files changed, 103 insertions(+)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Error: Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.example.dts:20.20-21 syntax error
FATAL ERROR: Unable to parse input tree
make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: dt_binding_check] Error 2
make: *** [Makefile:234: __sub-make] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231219-rk3308-audio-codec-v2-2-c70d06021946 at bootlin.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From conor at kernel.org  Tue Dec 19 15:48:49 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 19 Dec 2023 23:48:49 +0000
Subject: [PATCH 0/1] StarFive DWMAC support for JH7100
In-Reply-To: <20231219231040.2459358-1-cristian.ciocaltea@collabora.com>
References: <20231219231040.2459358-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231219-green-footwear-e81d37f9c63c@spud>

On Wed, Dec 20, 2023 at 01:10:38AM +0200, Cristian Ciocaltea wrote:
> This is just a subset of the initial patch series [1] adding networking
> support for StarFive JH7100 SoC.
> 
> [1]: https://lore.kernel.org/lkml/20231218214451.2345691-1-cristian.ciocaltea at collabora.com/

You need to send the binding patch alongside the driver, unless that has
been applied already.

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/300de4cb/attachment.sig>

From syzbot+95ffb6a83b20ea7f4f55 at syzkaller.appspotmail.com  Tue Dec 19 15:58:24 2023
From: syzbot+95ffb6a83b20ea7f4f55 at syzkaller.appspotmail.com (syzbot)
Date: Tue, 19 Dec 2023 15:58:24 -0800
Subject: [syzbot] [arm?] WARNING in do_sve_acc
Message-ID: <000000000000511e9a060ce5a45c@google.com>

Hello,

syzbot found the following issue on:

HEAD commit:    3f7168591ebf Merge tag '6.7-rc5-smb3-client-fixes' of git:..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=108baf71e80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8cf3c4f966189832
dashboard link: https://syzkaller.appspot.com/bug?extid=95ffb6a83b20ea7f4f55
compiler:       aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
userspace arch: arm64

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/384ffdcca292/non_bootable_disk-3f716859.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/fc2a62c05f31/vmlinux-3f716859.xz
kernel image: https://storage.googleapis.com/syzbot-assets/4dac83fca8af/Image-3f716859.gz.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+95ffb6a83b20ea7f4f55 at syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: CPU: 0 PID: 16446 at arch/arm64/kernel/fpsimd.c:1394 do_sve_acc+0x6c/0x10c arch/arm64/kernel/fpsimd.c:1393
Modules linked in:
CPU: 0 PID: 16446 Comm: syz-executor.0 Not tainted 6.7.0-rc5-syzkaller-00134-g3f7168591ebf #0
Hardware name: linux,dummy-virt (DT)
pstate: 01400009 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : do_sve_acc+0x6c/0x10c arch/arm64/kernel/fpsimd.c:1394
lr : do_sve_acc+0x5c/0x10c arch/arm64/kernel/fpsimd.c:1391
sp : ffff800082d1be60
x29: ffff800082d1be60 x28: fbff00000648af40 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
x23: 0000000080001000 x22: 0000ffffa04568d4 x21: 00000000ffffffff
x20: fbff00000648bec8 x19: fbff00000648af40 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : faff000029208888 x7 : 0000000000000000 x6 : 000000000000003f
x5 : 0000000000000040 x4 : 0000000000000000 x3 : 0000000000000001
x2 : 0000000000000000 x1 : ffff7ffffd52e000 x0 : 0000000000800000
Call trace:
 do_sve_acc+0x6c/0x10c arch/arm64/kernel/fpsimd.c:1393
 el0_sve_acc+0x2c/0x98 arch/arm64/kernel/entry-common.c:580
 el0t_64_sync_handler+0xf4/0x12c arch/arm64/kernel/entry-common.c:708
 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:595
---[ end trace 0000000000000000 ]---


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller at googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup


From cristian.ciocaltea at collabora.com  Tue Dec 19 15:58:28 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Wed, 20 Dec 2023 01:58:28 +0200
Subject: [PATCH 0/1] StarFive DWMAC support for JH7100
In-Reply-To: <20231219-green-footwear-e81d37f9c63c@spud>
References: <20231219231040.2459358-1-cristian.ciocaltea@collabora.com>
 <20231219-green-footwear-e81d37f9c63c@spud>
Message-ID: <25f36378-a998-4a48-b348-1ab1df6c803e@collabora.com>

On 12/20/23 01:48, Conor Dooley wrote:
> On Wed, Dec 20, 2023 at 01:10:38AM +0200, Cristian Ciocaltea wrote:
>> This is just a subset of the initial patch series [1] adding networking
>> support for StarFive JH7100 SoC.
>>
>> [1]: https://lore.kernel.org/lkml/20231218214451.2345691-1-cristian.ciocaltea at collabora.com/
> 
> You need to send the binding patch alongside the driver, unless that has
> been applied already.

Yeah, I wasn't sure about that, that's why I initially asked in [1] for
a confirmation regarding the split.  I chose to keep the binding in the
same set with the dts patches because the driver is just a glue layer
and doesn't really depend on bindings changes.

Should I still provide it here?  I was about to submit the remaining
patch set, so it would be great if we could clarify this beforehand.

Thanks for noticing the potential issue,
Cristian

[1]:
https://lore.kernel.org/lkml/0451e5a9-0cfb-42a5-b74b-2012e2c0d326 at collabora.com/




From marex at denx.de  Tue Dec 19 16:02:42 2023
From: marex at denx.de (Marek Vasut)
Date: Wed, 20 Dec 2023 01:02:42 +0100
Subject: [PATCH] arm64: dts: imx8mp: Disable UART4 by default on Data Modul i.MX8M Plus eDM SBC
Message-ID: <20231220000345.42593-1-marex@denx.de>

UART4 is used as CM7 coprocessor debug UART and may not be accessible from
Linux in case it is protected by RDC. The RDC protection is set up by the
platform firmware. UART4 is not used on this platform by Linux. Disable
UART4 by default to prevent boot hangs, which occur when the RDC protection
is in place.

Fixes: 562d222f23f0 ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC")
Signed-off-by: Marek Vasut <marex at denx.de>
---
Cc: Conor Dooley <conor+dt at kernel.org>
Cc: Fabio Estevam <festevam at gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
Cc: Rob Herring <robh+dt at kernel.org>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts b/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts
index 34e9aecc403bd..88e1b76d7d75f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts
@@ -491,7 +491,7 @@ &uart3 {	/* A53 Debug */
 &uart4 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart4>;
-	status = "okay";
+	status = "disabled";
 };
 
 &usb3_phy0 {
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Tue Dec 19 16:11:42 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Wed, 20 Dec 2023 02:11:42 +0200
Subject: [PATCH 0/1] StarFive DWMAC support for JH7100
In-Reply-To: <25f36378-a998-4a48-b348-1ab1df6c803e@collabora.com>
References: <20231219231040.2459358-1-cristian.ciocaltea@collabora.com>
 <20231219-green-footwear-e81d37f9c63c@spud>
 <25f36378-a998-4a48-b348-1ab1df6c803e@collabora.com>
Message-ID: <4992a407-c59f-4d1c-a058-9a6679606103@collabora.com>

On 12/20/23 01:58, Cristian Ciocaltea wrote:
> On 12/20/23 01:48, Conor Dooley wrote:
>> On Wed, Dec 20, 2023 at 01:10:38AM +0200, Cristian Ciocaltea wrote:
>>> This is just a subset of the initial patch series [1] adding networking
>>> support for StarFive JH7100 SoC.
>>>
>>> [1]: https://lore.kernel.org/lkml/20231218214451.2345691-1-cristian.ciocaltea at collabora.com/
>>
>> You need to send the binding patch alongside the driver, unless that has
>> been applied already.

You are right, the binding should stay with the driver as it provides
the top-level compatibles.  I was wrongly thinking on the base
snps,dwmac only.

> Yeah, I wasn't sure about that, that's why I initially asked in [1] for
> a confirmation regarding the split.  I chose to keep the binding in the
> same set with the dts patches because the driver is just a glue layer
> and doesn't really depend on bindings changes.
> 
> Should I still provide it here?  I was about to submit the remaining
> patch set, so it would be great if we could clarify this beforehand.
> 
> Thanks for noticing the potential issue,
> Cristian
> 
> [1]:
> https://lore.kernel.org/lkml/0451e5a9-0cfb-42a5-b74b-2012e2c0d326 at collabora.com/
> 
> 


From quic_taozha at quicinc.com  Tue Dec 19 16:27:39 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Wed, 20 Dec 2023 08:27:39 +0800
Subject: [PATCH v3 2/8] coresight-tpda: Add support to configure CMB
 element
In-Reply-To: <fa39e477-7faf-46e4-8ae2-9eb2321afc26@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-3-git-send-email-quic_taozha@quicinc.com>
 <88e51407-344e-4584-8711-29cc014c782b@arm.com>
 <b5965008-b51d-4bb7-8cf2-d21aa35d2205@quicinc.com>
 <fa39e477-7faf-46e4-8ae2-9eb2321afc26@arm.com>
Message-ID: <56f477d9-0b7b-4671-a09c-cc3fc24a8492@quicinc.com>


On 12/19/2023 9:54 PM, Suzuki K Poulose wrote:
> On 19/12/2023 02:13, Tao Zhang wrote:
>>
>> On 12/18/2023 6:27 PM, Suzuki K Poulose wrote:
>>> On 21/11/2023 02:24, Tao Zhang wrote:
>>>> Read the CMB element size from the device tree. Set the register
>>>> bit that controls the CMB element size of the corresponding port.
>>>>
>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>>>> ---
>>>> ? drivers/hwtracing/coresight/coresight-tpda.c | 117 
>>>> +++++++++++--------
>>>> ? drivers/hwtracing/coresight/coresight-tpda.h |?? 6 +
>>>> ? 2 files changed, 74 insertions(+), 49 deletions(-)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c 
>>>> b/drivers/hwtracing/coresight/coresight-tpda.c
>>>> index 5f82737c37bb..e3762f38abb3 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpda.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
>>>> @@ -28,24 +28,54 @@ static bool coresight_device_is_tpdm(struct 
>>>> coresight_device *csdev)
>>>> ????????????? CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM);
>>>> ? }
>>>> ? +static void tpdm_clear_element_size(struct coresight_device *csdev)
>>>> +{
>>>> +??? struct tpda_drvdata *drvdata = 
>>>> dev_get_drvdata(csdev->dev.parent);
>>>> +
>>>> +??? if (drvdata->dsb_esize)
>>>> +??????? drvdata->dsb_esize = 0;
>>>> +??? if (drvdata->cmb_esize)
>>>> +??????? drvdata->cmb_esize = 0;
>>>
>>> Why do we need the if (...) check here ?
>>
>> The element size of all the TPDM sub-unit should be set to 0 here.
>>
>> I will update this in the next patch series.
>>
>>>
>>>> +}
>>>> +
>>>> +static void tpda_set_element_size(struct tpda_drvdata *drvdata, 
>>>> u32 *val)
>>>> +{
>>>> +
>>>> +??? if (drvdata->dsb_esize == 64)
>>>> +??????? *val |= TPDA_Pn_CR_DSBSIZE;
>>>> +??? else if (drvdata->dsb_esize == 32)
>>>> +??????? *val &= ~TPDA_Pn_CR_DSBSIZE;
>>>> +
>>>> +??? if (drvdata->cmb_esize == 64)
>>>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x2);
>>>> +??? else if (drvdata->cmb_esize == 32)
>>>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x1);
>>>> +??? else if (drvdata->cmb_esize == 8)
>>>> +??????? *val &= ~TPDA_Pn_CR_CMBSIZE;
>>>> +}
>>>> +
>>>
>>>
>>>> ? /*
>>>> - * Read the DSB element size from the TPDM device
>>>> + * Read the element size from the TPDM device
>>>> ?? * Returns
>>>> - *??? The dsb element size read from the devicetree if available.
>>>> + *??? The element size read from the devicetree if available.
>>>> ?? *??? 0 - Otherwise, with a warning once.
>>>
>>> This doesn't match the function ? It return 0 on success and
>>> error (-EINVAL) on failure ?
>>
>> 0 means the element size property is found from the devicetree.
>>
>> Otherwise, it will return error(-EINVAL).
>>
>> I will update this in the next patch series.
>>
>>>
>>>> ?? */
>>>> -static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
>>>> +static int tpdm_read_element_size(struct tpda_drvdata *drvdata,
>>>> +????????????????? struct coresight_device *csdev)
>>>> ? {
>>>> -??? int rc = 0;
>>>> -??? u8 size = 0;
>>>> -
>>>> -??? rc = fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>>> -??????????? "qcom,dsb-element-size", &size);
>>>> +??? int rc = -EINVAL;
>>>> +
>>>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>>> +??????????? "qcom,dsb-element-size", &drvdata->dsb_esize))
>>>> +??????? rc = 0;
>>>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>>> +??????????? "qcom,cmb-element-size", &drvdata->cmb_esize))
>>>> +??????? rc = 0;
>>>
>>> Are we not silently resetting the error if the former failed ?
>>>
>>> Could we not :
>>>
>>> ????rc |= fwnode_...
>>>
>>> ????rc |= fwnode_...
>>>
>>> instead ?
>>>
>>> Also what is the expectation here ? Are these properties a MUST for
>>> TPDM ?
>>
>> The TPDM must have one of the element size property. As long as one
>
> Please add a comment in the function. Someone else might try to "fix"
> it otherwise.

Sure, I will update this in the next patch series.


Best,

Tao

>
> Suzuki
>>
>> can be found, this TPDM configuration can be considered valid. So this
>>
>> function will return 0 if one of the element size property is found.
>
>
>>
>>
>> Best,
>>
>> Tao
>>
>>>
>>>> ????? if (rc)
>>>> ????????? dev_warn_once(&csdev->dev,
>>>> -??????????? "Failed to read TPDM DSB Element size: %d\n", rc);
>>>> +??????????? "Failed to read TPDM Element size: %d\n", rc);
>>>> ? -??? return size;
>>>> +??? return rc;
>>>> ? }
>>>> ? ? /*
>>>> @@ -56,11 +86,12 @@ static int tpdm_read_dsb_element_size(struct 
>>>> coresight_device *csdev)
>>>> ?? * Parameter "inport" is used to pass in the input port number
>>>> ?? * of TPDA, and it is set to -1 in the recursize call.
>>>> ?? */
>>>> -static int tpda_get_element_size(struct coresight_device *csdev,
>>>> +static int tpda_get_element_size(struct tpda_drvdata *drvdata,
>>>> +???????????????? struct coresight_device *csdev,
>>>> ?????????????????? int inport)
>>>> ? {
>>>> -??? int dsb_size = -ENOENT;
>>>> -??? int i, size;
>>>> +??? int rc = 0;
>>>> +??? int i;
>>>> ????? struct coresight_device *in;
>>>> ? ????? for (i = 0; i < csdev->pdata->nr_inconns; i++) {
>>>> @@ -74,25 +105,21 @@ static int tpda_get_element_size(struct 
>>>> coresight_device *csdev,
>>>> ????????????? continue;
>>>> ? ????????? if (coresight_device_is_tpdm(in)) {
>>>> -??????????? size = tpdm_read_dsb_element_size(in);
>>>> +??????????? if ((drvdata->dsb_esize) || (drvdata->cmb_esize))
>>>> +??????????????? return -EEXIST;
>>>> +??????????? rc = tpdm_read_element_size(drvdata, in);
>>>> +??????????? if (rc)
>>>> +??????????????? return rc;
>>>> ????????? } else {
>>>> ????????????? /* Recurse down the path */
>>>> -??????????? size = tpda_get_element_size(in, -1);
>>>> -??????? }
>>>> -
>>>> -??????? if (size < 0)
>>>> -??????????? return size;
>>>> -
>>>> -??????? if (dsb_size < 0) {
>>>> -??????????? /* Found a size, save it. */
>>>> -??????????? dsb_size = size;
>>>> -??????? } else {
>>>> -??????????? /* Found duplicate TPDMs */
>>>> -??????????? return -EEXIST;
>>>> +??????????? rc = tpda_get_element_size(drvdata, in, -1);
>>>> +??????????? if (rc)
>>>> +??????????????? return rc;
>>>> ????????? }
>>>> ????? }
>>>> ? -??? return dsb_size;
>>>> +
>>>> +??? return rc;
>>>> ? }
>>>> ? ? /* Settings pre enabling port control register */
>>>> @@ -109,7 +136,7 @@ static void tpda_enable_pre_port(struct 
>>>> tpda_drvdata *drvdata)
>>>> ? static int tpda_enable_port(struct tpda_drvdata *drvdata, int port)
>>>> ? {
>>>> ????? u32 val;
>>>> -??? int size;
>>>> +??? int rc;
>>>> ? ????? val = readl_relaxed(drvdata->base + TPDA_Pn_CR(port));
>>>> ????? /*
>>>> @@ -117,29 +144,21 @@ static int tpda_enable_port(struct 
>>>> tpda_drvdata *drvdata, int port)
>>>> ?????? * Set the bit to 0 if the size is 32
>>>> ?????? * Set the bit to 1 if the size is 64
>>>> ?????? */
>>>> -??? size = tpda_get_element_size(drvdata->csdev, port);
>>>> -??? switch (size) {
>>>> -??? case 32:
>>>> -??????? val &= ~TPDA_Pn_CR_DSBSIZE;
>>>> -??????? break;
>>>> -??? case 64:
>>>> -??????? val |= TPDA_Pn_CR_DSBSIZE;
>>>> -??????? break;
>>>> -??? case 0:
>>>> -??????? return -EEXIST;
>>>> -??? case -EEXIST:
>>>> +??? tpdm_clear_element_size(drvdata->csdev);
>>>> +??? rc = tpda_get_element_size(drvdata, drvdata->csdev, port);
>>>> +??? if (!rc && ((drvdata->dsb_esize) || (drvdata->cmb_esize))) {
>>>> +??????? tpda_set_element_size(drvdata, &val);
>>>> +??????? /* Enable the port */
>>>> +??????? val |= TPDA_Pn_CR_ENA;
>>>> +??????? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>>>> +??? } else if (rc == -EEXIST)
>>>> ????????? dev_warn_once(&drvdata->csdev->dev,
>>>> -??????????? "Detected multiple TPDMs on port %d", -EEXIST);
>>>> -??????? return -EEXIST;
>>>> -??? default:
>>>> -??????? return -EINVAL;
>>>> -??? }
>>>> -
>>>> -??? /* Enable the port */
>>>> -??? val |= TPDA_Pn_CR_ENA;
>>>> -??? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>>>> +????????????????? "Detected multiple TPDMs on port %d", -EEXIST);
>>>> +??? else
>>>> +??????? dev_warn_once(&drvdata->csdev->dev,
>>>> +????????????????? "Didn't find TPDM elem size");
>>>
>>> "element size"
>>>
>>>> ? -??? return 0;
>>>> +??? return rc;
>>>> ? }
>>>> ? ? static int __tpda_enable(struct tpda_drvdata *drvdata, int port)
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.h 
>>>> b/drivers/hwtracing/coresight/coresight-tpda.h
>>>> index b3b38fd41b64..29164fd9711f 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpda.h
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpda.h
>>>> @@ -10,6 +10,8 @@
>>>> ? #define TPDA_Pn_CR(n)??????? (0x004 + (n * 4))
>>>> ? /* Aggregator port enable bit */
>>>> ? #define TPDA_Pn_CR_ENA??????? BIT(0)
>>>> +/* Aggregator port CMB data set element size bit */
>>>> +#define TPDA_Pn_CR_CMBSIZE??????? GENMASK(7, 6)
>>>> ? /* Aggregator port DSB data set element size bit */
>>>> ? #define TPDA_Pn_CR_DSBSIZE??????? BIT(8)
>>>> ? @@ -25,6 +27,8 @@
>>>> ?? * @csdev:????? component vitals needed by the framework.
>>>> ?? * @spinlock:?? lock for the drvdata value.
>>>> ?? * @enable:???? enable status of the component.
>>>> + * @dsb_esize?? Record the DSB element size.
>>>> + * @cmb_esize?? Record the CMB element size.
>>>> ?? */
>>>> ? struct tpda_drvdata {
>>>> ????? void __iomem??????? *base;
>>>> @@ -32,6 +36,8 @@ struct tpda_drvdata {
>>>> ????? struct coresight_device??? *csdev;
>>>> ????? spinlock_t??????? spinlock;
>>>> ????? u8??????????? atid;
>>>> +??? u8??????????? dsb_esize;
>>>> +??? u8??????????? cmb_esize;
>>>> ? };
>>>> ? ? #endif? /* _CORESIGHT_CORESIGHT_TPDA_H */
>>>
>>> Suzuki
>>>
>>>
>


From cristian.ciocaltea at collabora.com  Tue Dec 19 16:28:21 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Wed, 20 Dec 2023 02:28:21 +0200
Subject: [PATCH v2 0/2] StarFive DWMAC support for JH7100
Message-ID: <20231220002824.2462655-1-cristian.ciocaltea@collabora.com>

This is just a subset of the initial patch series [1] adding networking
support for StarFive JH7100 SoC.

[1]: https://lore.kernel.org/lkml/20231218214451.2345691-1-cristian.ciocaltea at collabora.com/

Changes in v2:
 - Add the missing binding patch

Cristian Ciocaltea (2):
  dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
  net: stmmac: dwmac-starfive: Add support for JH7100 SoC

 .../devicetree/bindings/net/snps,dwmac.yaml   | 11 ++-
 .../bindings/net/starfive,jh7110-dwmac.yaml   | 75 +++++++++++++------
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 +-
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 +++++++-
 4 files changed, 91 insertions(+), 33 deletions(-)

-- 
2.43.0



From cristian.ciocaltea at collabora.com  Tue Dec 19 16:28:23 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Wed, 20 Dec 2023 02:28:23 +0200
Subject: [PATCH v2 2/2] net: stmmac: dwmac-starfive: Add support for JH7100 SoC
In-Reply-To: <20231220002824.2462655-1-cristian.ciocaltea@collabora.com>
References: <20231220002824.2462655-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231220002824.2462655-3-cristian.ciocaltea@collabora.com>

Add a missing quirk to enable support for the StarFive JH7100 SoC.

Additionally, for greater flexibility in operation, allow using the
rgmii-rxid and rgmii-txid phy modes.

Co-developed-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
Reviewed-by: Jacob Keller <jacob.e.keller at intel.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 ++--
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 ++++++++++++++++---
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 85dcda51df05..4ec61f1ee71a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -165,9 +165,9 @@ config DWMAC_STARFIVE
 	help
 	  Support for ethernet controllers on StarFive RISC-V SoCs
 
-	  This selects the StarFive platform specific glue layer support for
-	  the stmmac device driver. This driver is used for StarFive JH7110
-	  ethernet controller.
+	  This selects the StarFive platform specific glue layer support
+	  for the stmmac device driver. This driver is used for the
+	  StarFive JH7100 and JH7110 ethernet controllers.
 
 config DWMAC_STI
 	tristate "STi GMAC support"
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 5d630affb4d1..4e1076faee0c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -15,13 +15,20 @@
 
 #include "stmmac_platform.h"
 
-#define STARFIVE_DWMAC_PHY_INFT_RGMII	0x1
-#define STARFIVE_DWMAC_PHY_INFT_RMII	0x4
-#define STARFIVE_DWMAC_PHY_INFT_FIELD	0x7U
+#define STARFIVE_DWMAC_PHY_INFT_RGMII		0x1
+#define STARFIVE_DWMAC_PHY_INFT_RMII		0x4
+#define STARFIVE_DWMAC_PHY_INFT_FIELD		0x7U
+
+#define JH7100_SYSMAIN_REGISTER49_DLYCHAIN	0xc8
+
+struct starfive_dwmac_data {
+	unsigned int gtxclk_dlychain;
+};
 
 struct starfive_dwmac {
 	struct device *dev;
 	struct clk *clk_tx;
+	const struct starfive_dwmac_data *data;
 };
 
 static void starfive_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode)
@@ -67,6 +74,8 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 
 	case PHY_INTERFACE_MODE_RGMII:
 	case PHY_INTERFACE_MODE_RGMII_ID:
+	case PHY_INTERFACE_MODE_RGMII_RXID:
+	case PHY_INTERFACE_MODE_RGMII_TXID:
 		mode = STARFIVE_DWMAC_PHY_INFT_RGMII;
 		break;
 
@@ -89,6 +98,14 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 	if (err)
 		return dev_err_probe(dwmac->dev, err, "error setting phy mode\n");
 
+	if (dwmac->data) {
+		err = regmap_write(regmap, JH7100_SYSMAIN_REGISTER49_DLYCHAIN,
+				   dwmac->data->gtxclk_dlychain);
+		if (err)
+			return dev_err_probe(dwmac->dev, err,
+					     "error selecting gtxclk delay chain\n");
+	}
+
 	return 0;
 }
 
@@ -114,6 +131,8 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	if (!dwmac)
 		return -ENOMEM;
 
+	dwmac->data = device_get_match_data(&pdev->dev);
+
 	dwmac->clk_tx = devm_clk_get_enabled(&pdev->dev, "tx");
 	if (IS_ERR(dwmac->clk_tx))
 		return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_tx),
@@ -144,8 +163,13 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
 }
 
+static const struct starfive_dwmac_data jh7100_data = {
+	.gtxclk_dlychain = 4,
+};
+
 static const struct of_device_id starfive_dwmac_match[] = {
-	{ .compatible = "starfive,jh7110-dwmac"	},
+	{ .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
+	{ .compatible = "starfive,jh7110-dwmac" },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Tue Dec 19 16:28:22 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Wed, 20 Dec 2023 02:28:22 +0200
Subject: [PATCH v2 1/2] dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
In-Reply-To: <20231220002824.2462655-1-cristian.ciocaltea@collabora.com>
References: <20231220002824.2462655-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231220002824.2462655-2-cristian.ciocaltea@collabora.com>

The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
similar to the newer JH7110, but it requires only two interrupts and a
single reset line, which is 'ahb' instead of the commonly used
'stmmaceth'.

Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
conjunction with 'stmmaceth', extend the logic to also permit exclusive
usage of the 'ahb' reset name.  This ensures the following use cases are
supported:

  JH7110: reset-names = "stmmaceth", "ahb";
  JH7100: reset-names = "ahb";
  other:  reset-names = "stmmaceth";

Also note the need to use a different dwmac fallback, as v5.20 applies
to JH7110 only, while JH7100 relies on v3.7x.

Additionally, drop the reset description items from top-level binding as
they are already provided by the included snps,dwmac schema.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 11 ++-
 .../bindings/net/starfive,jh7110-dwmac.yaml   | 75 +++++++++++++------
 2 files changed, 60 insertions(+), 26 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 5c2769dc689a..90c4db178c67 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -95,6 +95,7 @@ properties:
         - snps,dwmac-5.20
         - snps,dwxgmac
         - snps,dwxgmac-2.10
+        - starfive,jh7100-dwmac
         - starfive,jh7110-dwmac
 
   reg:
@@ -144,10 +145,12 @@ properties:
       - description: AHB reset
 
   reset-names:
-    minItems: 1
-    items:
-      - const: stmmaceth
-      - const: ahb
+    oneOf:
+      - items:
+          - enum: [stmmaceth, ahb]
+      - items:
+          - const: stmmaceth
+          - const: ahb
 
   power-domains:
     maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 5e7cfbbebce6..f5f0bff5be0f 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -16,16 +16,20 @@ select:
     compatible:
       contains:
         enum:
+          - starfive,jh7100-dwmac
           - starfive,jh7110-dwmac
   required:
     - compatible
 
 properties:
   compatible:
-    items:
-      - enum:
-          - starfive,jh7110-dwmac
-      - const: snps,dwmac-5.20
+    oneOf:
+      - items:
+          - const: starfive,jh7100-dwmac
+          - const: snps,dwmac
+      - items:
+          - const: starfive,jh7110-dwmac
+          - const: snps,dwmac-5.20
 
   reg:
     maxItems: 1
@@ -46,24 +50,6 @@ properties:
       - const: tx
       - const: gtx
 
-  interrupts:
-    minItems: 3
-    maxItems: 3
-
-  interrupt-names:
-    minItems: 3
-    maxItems: 3
-
-  resets:
-    items:
-      - description: MAC Reset signal.
-      - description: AHB Reset signal.
-
-  reset-names:
-    items:
-      - const: stmmaceth
-      - const: ahb
-
   starfive,tx-use-rgmii-clk:
     description:
       Tx clock is provided by external rgmii clock.
@@ -94,6 +80,51 @@ required:
 allOf:
   - $ref: snps,dwmac.yaml#
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: starfive,jh7100-dwmac
+    then:
+      properties:
+        interrupts:
+          minItems: 2
+          maxItems: 2
+
+        interrupt-names:
+          minItems: 2
+          maxItems: 2
+
+        resets:
+          maxItems: 1
+
+        reset-names:
+          const: ahb
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: starfive,jh7110-dwmac
+    then:
+      properties:
+        interrupts:
+          minItems: 3
+          maxItems: 3
+
+        interrupt-names:
+          minItems: 3
+          maxItems: 3
+
+        resets:
+          minItems: 2
+          maxItems: 2
+
+        reset-names:
+          items:
+            - const: stmmaceth
+            - const: ahb
+
 unevaluatedProperties: false
 
 examples:
-- 
2.43.0



From konrad.dybcio at linaro.org  Tue Dec 19 16:40:17 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 20 Dec 2023 01:40:17 +0100
Subject: [PATCH v2 2/3] ARM: qcom: drop most of 32-bit ARCH_QCOM subtypes
In-Reply-To: <20231216162700.863456-3-dmitry.baryshkov@linaro.org>
References: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>
 <20231216162700.863456-3-dmitry.baryshkov@linaro.org>
Message-ID: <45d3bac6-3110-4d91-91ad-409feab9e5ba@linaro.org>

On 16.12.2023 17:26, Dmitry Baryshkov wrote:
> Historically we had several subtypes of 32-bit Qualcomm platforms.
> Nowadays they became just useless symbols in Kconfig. Drop them and pull
> corresponding clocksource entries towards top-level ARCH_QCOM entry.
> 
> Note, I've left ARCH_IPQ40XX, ARCH_MSM8x60 and ARCH_MSM8960 in place,
> since they have special TEXT_OFFSET handling, which can be sorted out
> separately.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio at linaro.org>

Konrad


From linus.walleij at linaro.org  Tue Dec 19 16:43:55 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 20 Dec 2023 01:43:55 +0100
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
In-Reply-To: <20231219224616.pw32w5eq2dbuja5i@skbuf>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <20231218162326.173127-2-romain.gantois@bootlin.com> <20231219122034.pg2djgrosa4irubh@skbuf>
 <20231219140754.7a7a8dbd@device-28.home> <CACRpkdaxy9u=1-rQ+f+1tb8xyV-GYOuq52xhb4_SRPk9-LpnUA@mail.gmail.com>
 <20231219172932.13f4b0c3@device-28.home> <20231219224616.pw32w5eq2dbuja5i@skbuf>
Message-ID: <CACRpkdbo=Oem4PCOtSV6iWJoojRetTgZhx7J91uecTa-DQA8iQ@mail.gmail.com>

On Tue, Dec 19, 2023 at 11:46?PM Vladimir Oltean <olteanv at gmail.com> wrote:
> On Tue, Dec 19, 2023 at 05:29:32PM +0100, Maxime Chevallier wrote:

> > > I can certainly add a helper such as skb_eth_raw_ethertype()
> > > to <linux/if_ether.h> that will inspect the actual ethertype in
> > > skb->data.
> > >
> > > It's the most straight-forward approach.
> >
> > Agreed :)
>
> If you rewrite that patch to use skb_vlan_eth_hdr() to get a struct
> vlan_ethhdr pointer through which h_vlan_proto and h_vlan_encapsulated_proto
> are accessible, I don't see much value in writing that helper. It is
> going to beg the question how generic should it be - should it also
> treat ETH_P_8021AD, should it treat nested VLANs?

I guess I should just post the patches inline. (It came from both
Erics and Maximes suggestion really.)

Actually I wrote two helpers, one to get the ethertype from the
ethernet frame which is pretty straight-forward.

include/linux/if_ether.h

+/* This determines the ethertype incoded into the skb data without
+ * relying on skb->protocol which is not always identical.
+ */
+static inline u16 skb_eth_raw_ethertype(const struct sk_buff *skb)
+{
+       struct ethhdr *hdr;
+
+       /* If we can't extract a header, return invalid type */
+       if (!skb_pointer_if_linear(skb, 0, ETH_HLEN))
+               return 0x0000U;
+
+       hdr = skb_eth_hdr(skb);
+
+       return ntohs(hdr->h_proto);
+}

Then for *this* driver I need to check for the ethertype
ETH_P_8021Q what is inside it, one level down, and that is a
separate helper. And I named it skb_vlan_raw_inner_ethertype()
It will retrieve the inner type no matter

include/linux/if_vlan.h

+/* This determines the inner ethertype incoded into the skb data without
+ * relying on skb->protocol which is not always identical.
+ */
+static inline u16 skb_vlan_raw_inner_ethertype(const struct sk_buff *skb)
+{
+       struct vlan_ethhdr *vhdr;
+
+       if (!skb_pointer_if_linear(skb, 0, VLAN_ETH_HLEN))
+               return 0x0000U;
+
+       vhdr = vlan_eth_hdr(skb);
+       return ntohs(vhdr->h_vlan_encapsulated_proto);
+}

(We can bikeshed the name of the function. *_inner_protocol maybe.)

It does not handle nested VLANs and I don't see why it should since
the immediate siblings in if_vlan.h does not, i.e.
vlan_eth_hdr(), skb_vlan_eth_hdr(). It's pretty clear these helpers
all go just one level down. (We can add a *_descend_*()
helper the day someone needs that.)

> At the end of the day, you are trying to cover in software the cases for
> which the hardware engine can perform TX checksum offloading. That is
> going to be hardware specific.

Yeps and I am happy to fold these helpers inside of my driver if
they are not helpful to anyone else, or if that is the best idea for something
intended for a fix, i.e. an -rc kernel.

> I guess we should first try to answer the questions "what does
> skb->protocol represent?" and "does DSA use it correctly?" before
> even thinking about adding yet another fuzzy layer on top it.

Fair point! Let's take a step back. The kerneldoc says:

 *      @protocol: Packet protocol from driver

That's a bit vague and it was in the first commit in git history :/

But Eric probably knows the right way to use protocol.

But we know for sure that VLAN uses this for the outermost protocol
ETH_P_8021Q (etc).

I wonder how the network stack reacts if we set the skb->protocol
to whatever DSA taggers put at the position of the ethertype.

For RTL taggers probably this works because they use an elaborate
custom ethertype, but e.g. net/dsa/tag_mtk.c will just put in
"ethertype" 0x0000, 0x0001 or 0x0002, the two latter which are
formally ETH_P_802_3 and ETH_P_AX25 which I think is maybe
not so good to put into skb->protocol.

Another option is to set it to the ETH_P_DSA ethertype, currently
unused in the kernel.

Now this kind of thinking makes me insecure because:
git grep '\->protocol' net/

There is just sooooo much code inspecting ->protocol in the generic
network stack that this seems like inviting disaster.

Yours,
Linus Walleij


From peterx at redhat.com  Tue Dec 19 17:43:13 2023
From: peterx at redhat.com (Peter Xu)
Date: Wed, 20 Dec 2023 09:43:13 +0800
Subject: [PATCH 09/13] mm/gup: Cache *pudp in follow_pud_mask()
In-Reply-To: <CADrL8HVu8=-DdAwXN_pO91g1A1+F7bKfBRpm6jYfYMk1QZcRFA@mail.gmail.com>
References: <20231219075538.414708-1-peterx@redhat.com>
 <20231219075538.414708-10-peterx@redhat.com>
 <CADrL8HVu8=-DdAwXN_pO91g1A1+F7bKfBRpm6jYfYMk1QZcRFA@mail.gmail.com>
Message-ID: <ZYJGsUWpmF1P1Nd0@x1n>

On Tue, Dec 19, 2023 at 11:28:54AM -0500, James Houghton wrote:
> On Tue, Dec 19, 2023 at 2:57?AM <peterx at redhat.com> wrote:
> >
> > From: Peter Xu <peterx at redhat.com>
> >
> > Introduce "pud_t pud" in the function, so the code won't dereference *pudp
> > multiple time.  Not only because that looks less straightforward, but also
> > because if the dereference really happened, it's not clear whether there
> > can be race to see different *pudp values if it's being modified at the
> > same time.
> >
> > Signed-off-by: Peter Xu <peterx at redhat.com>
> > ---
> >  mm/gup.c | 17 +++++++++--------
> >  1 file changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/mm/gup.c b/mm/gup.c
> > index 6c0d82fa8cc7..97e87b7a15c3 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -753,26 +753,27 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma,
> >                                     unsigned int flags,
> >                                     struct follow_page_context *ctx)
> >  {
> > -       pud_t *pud;
> > +       pud_t *pudp, pud;
> >         spinlock_t *ptl;
> >         struct page *page;
> >         struct mm_struct *mm = vma->vm_mm;
> >
> > -       pud = pud_offset(p4dp, address);
> > -       if (pud_none(*pud))
> > +       pudp = pud_offset(p4dp, address);
> > +       pud = *pudp;
> 
> I think you might want a READ_ONCE() on this so that the compiler
> doesn't actually read the pud multiple times.

Makes sense.  I probably only did the "split" part which Christoph
requested, without thinking futher than that. :)

> 
> > +       if (pud_none(pud))
> >                 return no_page_table(vma, flags, address);
> > -       if (pud_devmap(*pud)) {
> > -               ptl = pud_lock(mm, pud);
> > -               page = follow_devmap_pud(vma, address, pud, flags, &ctx->pgmap);
> > +       if (pud_devmap(pud)) {
> > +               ptl = pud_lock(mm, pudp);
> > +               page = follow_devmap_pud(vma, address, pudp, flags, &ctx->pgmap);
> >                 spin_unlock(ptl);
> >                 if (page)
> >                         return page;
> >                 return no_page_table(vma, flags, address);
> >         }
> > -       if (unlikely(pud_bad(*pud)))
> > +       if (unlikely(pud_bad(pud)))
> >                 return no_page_table(vma, flags, address);
> 
> Not your change, but reading this, it's not clear to me that
> `pud_present(*pudp)` (and non-leaf) would necessarily be true at this
> point -- like, I would prefer to see `!pud_present(pud)` instead of
> `pud_bad()`. Thank you for adding that in the next patch. :)

I think the assumption here is it is expected to be a directory entry when
reaching here, and for a valid directory entry pud_present() should always
return true (a side note: pud_present() may not mean "PRESENT bit set", see
m68k's implementation for example).

Yeah I added that in the next patch, my intention was to check
!pud_present() for all cases without the need to take pgtable lock, though.

> 
> Feel free to add:
> 
> Acked-by: James Houghton <jthoughton at google.com>

Thanks,

-- 
Peter Xu



From peng.fan at nxp.com  Tue Dec 19 17:58:09 2023
From: peng.fan at nxp.com (Peng Fan)
Date: Wed, 20 Dec 2023 01:58:09 +0000
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <20231219192912.yulmczvqbuh4jizg@pengutronix.de>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
 <20231219192912.yulmczvqbuh4jizg@pengutronix.de>
Message-ID: <DU0PR04MB94170BCA413C2FD48A397B538896A@DU0PR04MB9417.eurprd04.prod.outlook.com>

> Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
> protocol
> 
> Hi Peng,
> 
> On 23-12-15, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan at nxp.com>
> >
> > Add SCMI v3.2 pinctrl protocol bindings and example.
> >
> > Signed-off-by: Peng Fan <peng.fan at nxp.com>
> > ---
> >  .../devicetree/bindings/firmware/arm,scmi.yaml     | 99
> ++++++++++++++++++++++
> >  1 file changed, 99 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > index 4591523b51a0..bfd2b6a89979 100644
> > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > @@ -247,6 +247,85 @@ properties:
> >        reg:
> >          const: 0x18
> >
> > +  protocol at 19:
> 
> ...
> 
> > @@ -401,6 +480,26 @@ examples:
> >              scmi_powercap: protocol at 18 {
> >                  reg = <0x18>;
> >              };
> > +
> > +            scmi_pinctrl: protocol at 19 {
> > +                reg = <0x19>;
> > +                #pinctrl-cells = <0>;
> > +
> > +                i2c2-pins {
> > +                    groups = "i2c2_a", "i2c2_b";
> > +                    function = "i2c2";
> > +                };
> > +
> > +                mdio-pins {
> > +                    groups = "avb_mdio";
> > +                    drive-strength = <24>;
> > +                };
> > +
> > +                keys_pins: keys-pins {
> > +                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> > +                    bias-pull-up;
> > +                };
> > +            };
> 
> This example is different to the one you mentioned within the cover-letter. I
> didn't checked all patches just want to ask which API will be implemented by
> this patchset?

I kept this change since it was tested by Oleksii, but anyway i.MX not use these.

The API, I suppose you are asking about this?
static const struct pinctrl_ops pinctrl_scmi_pinctrl_ops = {                                        
        .get_groups_count = pinctrl_scmi_get_groups_count,                                          
        .get_group_name = pinctrl_scmi_get_group_name,                                              
        .get_group_pins = pinctrl_scmi_get_group_pins,                                              
#ifdef CONFIG_OF                                                                                    
        .dt_node_to_map = pinconf_generic_dt_node_to_map_all,                                       
        .dt_free_map = pinconf_generic_dt_free_map,                                                 
#endif                                                                                              
};

static const struct pinctrl_ops pinctrl_scmi_imx_pinctrl_ops = {                                    
        .get_groups_count = pinctrl_scmi_get_groups_count,                                          
        .get_group_name = pinctrl_scmi_get_group_name,                                              
        .get_group_pins = pinctrl_scmi_get_group_pins,                                              
#ifdef CONFIG_OF                                                                                    
        .dt_node_to_map = pinctrl_scmi_imx_dt_node_to_map,                                          
        .dt_free_map = pinconf_generic_dt_free_map,                                                 
#endif                                                                                              
};

Thanks,
Peng.

> 
> Regards,
>   Marco
> 
> >          };
> >      };
> >
> >
> > --
> > 2.37.1
> >
> >
> >


From Chunfeng.Yun at mediatek.com  Tue Dec 19 18:05:25 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Wed, 20 Dec 2023 02:05:25 +0000
Subject: [PATCH v2 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <d50abf1a-1ee7-4f84-9f53-69dfe9aad103@linaro.org>
References: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
	 <d50abf1a-1ee7-4f84-9f53-69dfe9aad103@linaro.org>
Message-ID: <2f38caeb95fe9b2d01f158fd91ed0cedafa5d2fa.camel@mediatek.com>

On Fri, 2023-12-15 at 08:36 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 15/12/2023 08:34, Chunfeng Yun wrote:
> > For Gen1 isoc-in endpoint on controller before about SSUSB IPM
> v1.6.0, it
> > still send out unexpected ACK after receiving a short packet in
> burst
> > transfer, this will cause an exception on connected device,
> specially for
> > a 4k camera.
> > Add a quirk property "rx-fifo-depth" to work around this hardware
> issue,
> > prefer to use 2;
> > The side-effect is that may cause performance drop about 10%,
> including
> > bulk transfer.
> > 
> > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > ---
> > v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
> > ---
> >  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12
> ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> xhci.yaml
> > index e9644e333d78..e44a71acb5c0 100644
> > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> > @@ -124,6 +124,18 @@ properties:
> >        defined in the xHCI spec on MTK's controller.
> >      default: 5000
> >  
> > +  rx-fifo-depth:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    description:
> > +      It is a quirk used to work around Gen1 isoc-in endpoint
> transfer issue
> > +      that still send out unexpected ACK after device finish the
> burst transfer
> > +      with a short packet and cause an exception, specially on a
> 4K camera
> > +      device, it happens on controller before about IPM v1.6.0;
> the side-effect
> > +      is that may cause performance drop about 10%, include bulk
> transfer,
> > +      prefer to use 2 here.
> 
> What is the meaning of 0-3? bytes? words?
0 - 1K bytes;
3 - 4K bytes;
I will add this in description

> 
> > +    minimum: 0
> > +    maximum: 3
> 
> 
> Best regards,
> Krzysztof
> 
> 

From kamal.dasu at broadcom.com  Tue Dec 19 18:07:14 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Tue, 19 Dec 2023 21:07:14 -0500
Subject: [PATCH v5 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <45b785bd-9b60-4ab7-80f9-b179d932d04d@broadcom.com>
References: <45b785bd-9b60-4ab7-80f9-b179d932d04d@broadcom.com>
Message-ID: <B98B7C63-E1C0-4E52-B6FE-8FB8258A1F6E@broadcom.com>







> On Dec 19, 2023, at 4:55?PM, Florian Fainelli <florian.fainelli at broadcom.com> wrote:
> 
> ?Hi Kamal,
> 
>> On 12/19/2023 5:22 PM, Kamal Dasu wrote:
>> From: Kamal Dasu <kdasu at broadcom.com>
>> 74165b0 shall use a new sdio controller core version which
>> requires a different reset sequence. For core reset we use
>> sdhci_reset. For CMD and/or DATA reset added a new function
>> to also enable SDHCI clocks SDHCI_CLOCK_CARD_EN
>> SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
>> SDHCI_RESET_DATA fields.
>> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
>> ---
> 
> [snip]
> 
>> +static void brcmstb_sdhci_reset_cmd_data(struct sdhci_host *host, u8 mask)
>> +{
>> +    int ret;
>> +    u32 reg;
>> +    u32 new_mask = (mask &  (SDHCI_RESET_CMD | SDHCI_RESET_DATA)) << 24;
>> +
>> +    /*
>> +     * SDHCI_CLOCK_CONTROL register CARD_EN and CLOCK_INT_EN bits shall
>> +     * be set along with SOFTWARE_RESET register RESET_CMD or RESET_DATA
>> +     * bits, hence access SDHCI_CLOCK_CONTROL register as 32-bit register
>> +     */
>> +    new_mask |= SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN;
>> +    reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
>> +    sdhci_writel(host, reg | new_mask, SDHCI_CLOCK_CONTROL);
>> +
>> +    reg = sdhci_readb(host, SDHCI_SOFTWARE_RESET);
>> +    ret = readb_poll_timeout(host->ioaddr + SDHCI_SOFTWARE_RESET,
>> +                 reg, reg & mask, 10, 10000);
> 
> Does this need to be readb_poll_timeout_atomic() since this function can be used in both atomic and non-atomic context AFAIR?

Yes it does. Will send a v6
> --
> Florian

Kamal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231219/c1fe651b/attachment.p7s>

From victor.liu at nxp.com  Tue Dec 19 18:27:13 2023
From: victor.liu at nxp.com (Ying Liu)
Date: Wed, 20 Dec 2023 02:27:13 +0000
Subject: [PATCH 1/1] phy: freescale: phy-fsl-imx8-mipi-dphy: Fix alias
 name to use dashes
In-Reply-To: <20231219090248.3317500-1-alexander.stein@ew.tq-group.com>
References: <20231219090248.3317500-1-alexander.stein@ew.tq-group.com>
Message-ID: <AM7PR04MB70468E3BDB14C528F8F3654C9896A@AM7PR04MB7046.eurprd04.prod.outlook.com>

On Tuesday, December 19, 2023 5:03 PM, Alexander Stein <alexander.stein at ew.tq-group.com> wrote: 
> Devicetree spec lists only dashes as valid characters for alias names.

This saying is not accurate because it lists digit, lowercase letter and
dash characters.

> Table 3.2: Valid characters for alias names, Devicee Specification,
> Release v0.4
> 
> Signed-off-by: Alexander Stein <alexander.stein at ew.tq-group.com>

It makes sense to add a Fixes tag:
Fixes: 3fbae284887d ("phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support")

Regards,
Liu Ying


From xu.yang_2 at nxp.com  Tue Dec 19 18:23:18 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Wed, 20 Dec 2023 02:23:18 +0000
Subject: [EXT] Re: [PATCH v2 3/5] dt-bindings: usb: ci-hdrc-usb2: add
 compatible and clock-names restriction for imx93
In-Reply-To: <eb93c554-ee35-49a0-adfb-0d3030f9a77b@linaro.org>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com>
 <20231218085456.3962720-3-xu.yang_2@nxp.com>
 <eb93c554-ee35-49a0-adfb-0d3030f9a77b@linaro.org>
Message-ID: <DB7PR04MB5146154E6C62BCFCDA7879F38C96A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Krzysztof,

> 
> On 18/12/2023 09:54, Xu Yang wrote:
> > The i.MX93 needs a wakup clock to work properly. This will add compatible
> > and restriction for i.MX93 platform.
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> >
> > ---
> > Changes in v2:
> >  - no changes
> 
> No changes? Where is the v1 in such case?

Sorry, the changes should be new patch here.

> 
> > ---
> >  .../devicetree/bindings/usb/ci-hdrc-usb2.yaml        | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-
> hdrc-usb2.yaml
> > index b7e664f7395b..4e22b369e43f 100644
> > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> > @@ -57,6 +57,7 @@ properties:
> >            - enum:
> >                - fsl,imx8mm-usb
> >                - fsl,imx8mn-usb
> > +              - fsl,imx93-usb
> >            - const: fsl,imx7d-usb
> >            - const: fsl,imx27-usb
> >        - items:
> > @@ -411,6 +412,17 @@ allOf:
> >          external-vbus-divider: false
> >          samsung,picophy-pre-emp-curr-control: false
> >          samsung,picophy-dc-vol-level-adjust: false
> 
> Blank line

Okay.

> 
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: fsl,imx93-usb
> > +    then:
> > +      properties:
> > +        clock-names:
> > +          items:
> > +            - const: usb_ctrl_root_clk
> > +            - const: usb_wakeup_clk
> 
> What about all the reset? reg, interrupts? Maybe it is time to split the
> schema into common part and device-specific.

Why I need to consider reset, reg and interrupts? Should I add restrictions on
these too? I may not really understand your meaning.

Thanks,
Xu Yang

> 
> 
> 
> Best regards,
> Krzysztof


From Jason-JH.Lin at mediatek.com  Tue Dec 19 18:46:03 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 20 Dec 2023 02:46:03 +0000
Subject: [PATCH 0/3] Add mediatek,gce-events definition to
 mediatek,gce-mailbox bindings
In-Reply-To: <20231219-joyous-tarmac-aaf601623859@spud>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
	 <20231219-joyous-tarmac-aaf601623859@spud>
Message-ID: <6bb9deec93ec4d9b3dc7a8b587903565964eb0a4.camel@mediatek.com>

Hi Conor,

Thanks for the reviews.

On Tue, 2023-12-19 at 16:54 +0000, Conor Dooley wrote:
> On Mon, Dec 18, 2023 at 04:36:01PM +0800, Jason-JH.Lin wrote:
> > From: Jason-jh Lin <jason-jh.lin at mediatek.corp-partner.google.com>
> > 
> > Since mediatek,gce-events property is a HW event signal from GCE,
> > it should be defined in mediatek,gce-mailbox.yaml.
> > 
> > Change the description of mediatek,gce-events property existed in
> > other bindings to reference mediatek,gce-mailbox.yaml.
> 
> I don't understand this series. I would understand it if the property
> should be related to the mailbox provider and it is moved there from
> the
> mailbox consumer, but this series does not do that. Instead the
> series
> now documents this property for both consumers and providers.
I want to move properties related to MediaTek's proprietary GCE HW to a
common place and let it referenced by mailbox providers and consumers.

And I also want to add this property into a mailbox provider, but maybe
not in this series. I'll move this modification into another series.

> 
> Secondly it removes the typedef from the consumers, which makes no
> sense
> if this is a valid property there.
> 
OK, I will keep the $ref for the consumers.

> Is your intention to document a property that should be common across
> all consumers in a single place? If that is your goal, then something
> like spi-peripheral-props.yaml is what you need here.
> 
Thanks for your example.

Since these properties for the GCE HW are MediaTek specific, I will try
to send a series to create a mediatek,gce-props.yaml to list all these
properties. And modify all these properties in mailbox consumers.

Regards,
Jason-JH.Lin

> Confused,
> Conor.

From chunfeng.yun at mediatek.com  Tue Dec 19 18:58:40 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Wed, 20 Dec 2023 10:58:40 +0800
Subject: [PATCH v3 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1 isoc-in transfer issue
Message-ID: <20231220025842.7082-1-chunfeng.yun@mediatek.com>

For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
still send out unexpected ACK after receiving a short packet in burst
transfer, this will cause an exception on connected device, specially for
a 4k camera.
Add a quirk property "rx-fifo-depth" to work around this hardware issue,
prefer to use 3k bytes;
The side-effect is that may cause performance drop about 10%, including
bulk transfer.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v3: add fifo depth unit, change the value range from 0-3 to 1-4
v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
---
 .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index e9644e333d78..9478b7031796 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -124,6 +124,18 @@ properties:
       defined in the xHCI spec on MTK's controller.
     default: 5000
 
+  rx-fifo-depth:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      It is a quirk used to work around Gen1 isoc-in endpoint transfer issue
+      that still send out unexpected ACK after device finish the burst transfer
+      with a short packet and cause an exception, specially on a 4K camera
+      device, it happens on controller before about IPM v1.6.0; the side-effect
+      is that may cause performance drop about 10%, include bulk transfer,
+      prefer to use 3 here. The unit is 1K bytes.
+    minimum: 1
+    maximum: 4
+
   # the following properties are only used for case 1
   wakeup-source:
     description: enable USB remote wakeup, see power/wakeup-source.txt
-- 
2.18.0



From chunfeng.yun at mediatek.com  Tue Dec 19 18:58:42 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Wed, 20 Dec 2023 10:58:42 +0800
Subject: [PATCH v3 3/3] arm64: dts: mediatek: mt8195: Add 'rx-fifo-depth' for cherry
In-Reply-To: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
Message-ID: <20231220025842.7082-3-chunfeng.yun@mediatek.com>

Add the quirk property "rx-fifo-depth" to work around Gen1 isoc-in
transfer issue which send out unexpected ACK even after device
already finished the burst transfer with a short patcket, specially
for a 4K camera device.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v3: change value according to binding
v2: use 'rx-fifo-depth' property
---
 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index dd5b89b73190..58593348b810 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -1185,6 +1185,7 @@
 
 	vusb33-supply = <&mt6359_vusb_ldo_reg>;
 	vbus-supply = <&usb_vbus>;
+	rx-fifo-depth = <3>;
 };
 
 &xhci1 {
@@ -1192,6 +1193,7 @@
 
 	vusb33-supply = <&mt6359_vusb_ldo_reg>;
 	vbus-supply = <&usb_vbus>;
+	rx-fifo-depth = <3>;
 };
 
 &xhci2 {
-- 
2.18.0



From chunfeng.yun at mediatek.com  Tue Dec 19 18:58:41 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Wed, 20 Dec 2023 10:58:41 +0800
Subject: [PATCH v3 2/3] usb: xhci-mtk: fix a short packet issue of gen1 isoc-in transfer
In-Reply-To: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
Message-ID: <20231220025842.7082-2-chunfeng.yun@mediatek.com>

For Gen1 isoc-in transfer, host still send out unexpected ACK after device
finish the burst with a short packet, this will cause an exception on the
connected device, such as, a usb 4k camera.
It can be fixed by setting rxfifo depth less than 4k bytes, prefer to use
3k here, the side-effect is that may cause performance drop about 10%,
including bulk transfer.

Fixes: 926d60ae64a6 ("usb: xhci-mtk: modify the SOF/ITP interval for mt8195")
Cc: stable at vger.kernel.org
Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v3:
add Cc stable
change @rxfifo_depth from int to u32, due to property's value range is changed
v2:
use 'rx-fifo-depth' property;
add header file 'linux/bitfield.h' to avoid building error on some ARCH;
---
 drivers/usb/host/xhci-mtk.c | 37 +++++++++++++++++++++++++++++++++++--
 drivers/usb/host/xhci-mtk.h |  2 ++
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bbdf1b0b7be1..868793b82348 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -7,6 +7,7 @@
  *  Chunfeng Yun <chunfeng.yun at mediatek.com>
  */
 
+#include <linux/bitfield.h>
 #include <linux/dma-mapping.h>
 #include <linux/iopoll.h>
 #include <linux/kernel.h>
@@ -73,6 +74,9 @@
 #define FRMCNT_LEV1_RANG	(0x12b << 8)
 #define FRMCNT_LEV1_RANG_MASK	GENMASK(19, 8)
 
+#define HSCH_CFG1		0x960
+#define SCH3_RXFIFO_DEPTH_MASK	GENMASK(21, 20)
+
 #define SS_GEN2_EOF_CFG		0x990
 #define SSG2EOF_OFFSET		0x3c
 
@@ -165,6 +169,34 @@ static void xhci_mtk_set_frame_interval(struct xhci_hcd_mtk *mtk)
 	writel(value, hcd->regs + SS_GEN2_EOF_CFG);
 }
 
+/*
+ * workaround: usb3.2 gen1 isoc rx hw issue
+ * host send out unexpected ACK afer device fininsh a burst transfer with
+ * a short packet.
+ */
+static void xhci_mtk_rxfifo_depth_set(struct xhci_hcd_mtk *mtk)
+{
+	struct usb_hcd *hcd = mtk->hcd;
+	u32 value;
+
+	if (!mtk->rxfifo_depth)
+		return;
+
+	value = readl(hcd->regs + HSCH_CFG1);
+	value &= ~SCH3_RXFIFO_DEPTH_MASK;
+	value |= FIELD_PREP(SCH3_RXFIFO_DEPTH_MASK, mtk->rxfifo_depth - 1);
+	writel(value, hcd->regs + HSCH_CFG1);
+}
+
+static void xhci_mtk_init_quirk(struct xhci_hcd_mtk *mtk)
+{
+	/* workaround only for mt8195 */
+	xhci_mtk_set_frame_interval(mtk);
+
+	/* workaround for SoCs using SSUSB about before IPM v1.6.0 */
+	xhci_mtk_rxfifo_depth_set(mtk);
+}
+
 static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
 {
 	struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
@@ -448,8 +480,7 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
 		if (ret)
 			return ret;
 
-		/* workaround only for mt8195 */
-		xhci_mtk_set_frame_interval(mtk);
+		xhci_mtk_init_quirk(mtk);
 	}
 
 	ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
@@ -527,6 +558,8 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	of_property_read_u32(node, "mediatek,u2p-dis-msk",
 			     &mtk->u2p_dis_msk);
 
+	of_property_read_u32(node, "rx-fifo-depth", &mtk->rxfifo_depth);
+
 	ret = usb_wakeup_of_property_parse(mtk, node);
 	if (ret) {
 		dev_err(dev, "failed to parse uwk property\n");
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 39f7ae7d3087..f5e2bd66bb1b 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -171,6 +171,8 @@ struct xhci_hcd_mtk {
 	struct regmap *uwk;
 	u32 uwk_reg_base;
 	u32 uwk_vers;
+	/* quirk */
+	u32 rxfifo_depth;
 };
 
 static inline struct xhci_hcd_mtk *hcd_to_mtk(struct usb_hcd *hcd)
-- 
2.18.0



From Randy.Li at synaptics.com  Tue Dec 19 19:12:15 2023
From: Randy.Li at synaptics.com (Hsia-Jun Li)
Date: Wed, 20 Dec 2023 11:12:15 +0800
Subject: Could external jtag debugger trap page fault instead of kernel
 handler?
In-Reply-To: <daac75e5-bb80-461f-a77b-939a184d3caa@arm.com>
References: <b8ccbd62-7a0d-49eb-bc32-c48e59adeae6@synaptics.com>
 <daac75e5-bb80-461f-a77b-939a184d3caa@arm.com>
Message-ID: <aed87c60-d802-45d0-a430-52fb9e7bedad@synaptics.com>



On 12/20/23 00:57, Robin Murphy wrote:
> CAUTION: Email originated externally, do not click links or open 
> attachments unless you recognize the sender and know the content is safe.
> 
> 
> On 2023-12-19 7:47 am, Hsia-Jun Li wrote:
>> Hello
>>
>> I am trying to debug an illegal memory access problem for a kernel
>> driver. The JTAG could trap the kernel function likes
>> die_kernel_fault(). But it won't provide a context environment in the
>> place where this bug happens.
>>
>> I know such page fault is more like a software interrupter, is there a
>> way that I could move my debugging context back?
> 
> Right, you don't want to be looking at the current running context of
> the exception handler itself, you want to be looking at the exception
> context that's stored in "regs" at this point. I've never used GDB for
> that, but I'd hope it has some command for inspecting a stack at an
I think we could make that python script for gdb kernel do that.
> arbitrary address other than the current SP register.

While I think we do need to do something to the kernel. I have not read 
the full document of the coresight. Would the coresight known an 
external debugger is connected to one of its cores?

Or we could have a variable flag here to control the branch. I know the 
kernel could trigger the coresight, instead of software interrupter 
handler from kernel, the external debugger would know what happened with 
help of the python script.

Besides, we need to disable some timer handler in this case, likes arm 
psci timer.
> 
> However, if you haven't already, it looks like enabling
Thank you. I have solved what cause my original bug.
> CONFIG_DEBUG_LIST might help catch this particular issue sooner, as
> you've clearly got some LIST_POISON values there.
> 
> Robin.
> 
>> Here is what I got from gdb connected to openocd.
>> (gdb) bt
>> #0? __do_kernel_fault (addr=16045481047390945544, addr at entry=264,
>> esr=2516582468, regs=0xffffff802937b940)
>> ???? at
>> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:372
>> #1? 0xffffffc00802c174 in do_bad_area (regs=<optimized out>,
>> esr=<optimized out>, far=16045481047390945544)
>> ???? at
>> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:485
>> #2? do_translation_fault (far=16045481047390945544, esr=<optimized out>,
>> regs=<optimized out>)
>> ???? at
>> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:782
>> #3? 0xffffffc00802c2cc in do_mem_abort (far=16045481047390945544,
>> esr=2516582468, regs=0xffffff802937b940)
>> ???? at
>> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:918
>> #4? 0xffffffc00889738c in skb_dump (level=0xdead000000000108 "",
>> skb=0xffffff802937b940, full_pkt=112)
>> ???? at
>> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/core/skbuff.c:834
>> #5? 0x0000000000000000 in ?? ()
>> Backtrace stopped: not enough registers or memory available to unwind
>> further
>> (gdb) info threads
>> ?? Id?? Target Id???????? Frame
>> ?? 1??? Thread 1 "vs640.cpu_a53.0" (Name: vs640.cpu_a53.0, state:
>> debug-request) 0xffffffc008898038 in nf_l4proto_log_inv
>> alid (skb=0xffffffc0086391a0 <psci_enter_idle_state>, state=0xffffffff,
>> protonum=0 '\000', fmt=0x258208 "")
>> ???? at
>> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/netfilter/nf_conntrack_proto.c:62
>> * 2??? Thread 2 "vs640.cpu_a53.1" (Name: vs640.cpu_a53.1, state:
>> breakpoint)??? __do_kernel_fault (
>> ???? addr=16045481047390945544, addr at entry=264, esr=2516582468,
>> regs=0xffffff802937b940)
>> ???? at
>> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/arch/arm64/mm/fault.c:372
>> ?? 3??? Thread 3 "vs640.cpu_a53.2" (Name: vs640.cpu_a53.2, state:
>> debug-request) 0xffffffc008898038 in nf_l4proto_log_inv
>> alid (skb=0xffffffc0086391a0 <psci_enter_idle_state>, state=0xffffffff,
>> protonum=0 '\000', fmt=0x9f2270 "")
>> ???? at
>> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/netfilter/nf_conntrack_proto.c:62
>> ?? 4??? Thread 4 "vs640.cpu_a53.3" (Name: vs640.cpu_a53.3, state:
>> debug-request) 0xffffffc008898038 in nf_l4proto_log_inv
>> alid (skb=0xffffffc0086391a0 <psci_enter_idle_state>, state=0xffffffff,
>> protonum=0 '\000', fmt=0x20ded8 "")
>> ???? at
>> /Codebase_s/ranl/workspace/vs680/kernel/linux-syna/net/netfilter/nf_conntrack_proto.c:62
>>
>> And here is the issue I am trying to debug:
>> [ 5478.863161] Unable to handle kernel paging request at virtual address
>> dead000000000108
>> [ 5478.871093] Mem abort info:
>> [ 5478.873886]?? ESR = 0x96000044
>> [ 5478.876938]?? EC = 0x25: DABT (current EL), IL = 32 bits
>> [ 5478.882249]?? SET = 0, FnV = 0
>> [ 5478.885301]?? EA = 0, S1PTW = 0
>> [ 5478.888440]?? FSC = 0x04: level 0 translation fault
>> [ 5478.893318] Data abort info:
>> [ 5478.896195]?? ISV = 0, ISS = 0x00000044
>> [ 5478.900029]?? CM = 0, WnR = 1
>> [ 5478.902996] [dead000000000108] address between user and kernel
>> address ranges
>> [ 5478.910129] Internal error: Oops: 96000044 [#1] PREEMPT SMP
>> [ 5478.915701] Modules linked in: vpu videobuf2_memops v4l2_mem2mem
>> videobuf2_v4l2 videobuf2_common videodev mc synap(O)
>> ? pvrsrvkm syna_drm cfg80211 rfkill amp_bm
>> [ 5478.929897] CPU: 0 PID: 6613 Comm: gst-launch-1.0 Tainted: G??????? W
>> ? O????? 5.15.62 #1
>> [ 5478.937988] Hardware name: Synaptics VS640 EVK (DT)
>> [ 5478.942864] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS
>> BTYPE=--)
>> [ 5478.949825] pc : v4l2_m2m_buf_remove+0x50/0x90 [v4l2_mem2mem]
>> [ 5478.955582] lr : v4l2_m2m_buf_remove+0x20/0x90 [v4l2_mem2mem]
>> [ 5478.961329] sp : ffffff8026c4fa90
>> [ 5478.964643] x29: ffffff8026c4fa90 x28: ffffff8026c201b0 x27:
>> 0000000000000000
>> [ 5478.971784] x26: 0000000000000000 x25: ffffff8026c4fd28 x24:
>> ffffff8009774270
>> [ 5478.978921] x23: ffffff8025f4c100 x22: 0000000000000001 x21:
>> ffffff8025e1f3a0
>> [ 5478.986059] x20: ffffff8025e6d7b0 x19: ffffff8025e1f028 x18:
>> 0000000000000000
>> [ 5478.993197] x17: 0000000000000000 x16: 0000000000000000 x15:
>> 00000055a1955a10
>> [ 5479.000335] x14: 0000000000000000 x13: 0000000000000000 x12:
>> 0000000000000000
>> [ 5479.007472] x11: 0000000000000000 x10: 0000000000000000 x9 :
>> 0000000000000000
>> [ 5479.014609] x8 : 0000000000000000 x7 : 0000000000000000 x6 :
>> 0000000000000005
>> [ 5479.021746] x5 : dead000000000100 x4 : dead000000000122 x3 :
>> dead000000000100
>> [ 5479.028884] x2 : dead000000000122 x1 : 0000000000000000 x0 :
>> ffffff8025e1f3a0
>> [ 5479.036021] Call trace:
>> [ 5479.038467]? v4l2_m2m_buf_remove+0x50/0x90 [v4l2_mem2mem]
>> [ 5479.043867]? vb2ops_vdec_stop_streaming+0x98/0x160 [vpu]
>> [ 5479.049184]? __vb2_queue_cancel+0x30/0x210 [videobuf2_common]
>> [ 5479.054936]? vb2_core_streamoff+0x20/0xb4 [videobuf2_common]
>> [ 5479.060597]? vb2_streamoff+0x18/0x64 [videobuf2_v4l2]
>> [ 5479.065654]? v4l2_m2m_streamoff+0x70/0x140 [v4l2_mem2mem]
>> [ 5479.071055]? v4l2_m2m_ioctl_streamoff+0x14/0x20 [v4l2_mem2mem]
>> [ 5479.076889]? v4l_streamoff+0x20/0x30 [videodev]
>> [ 5479.081455]? __video_do_ioctl+0x174/0x3d0 [videodev]
>>
>> Sincerely

-- 
Hsia-Jun(Randy) Li


From sunilvl at ventanamicro.com  Tue Dec 19 19:49:32 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Wed, 20 Dec 2023 09:19:32 +0530
Subject: [RFC PATCH v3 00/17] RISC-V: ACPI: Add external interrupt
 controller support
In-Reply-To: <CAJZ5v0j6Veze8xDFKTbVZ5=WAfmLdeJ8NXRnh9kwCZgyaDdgew@mail.gmail.com>
References: <20231219174526.2235150-1-sunilvl@ventanamicro.com>
 <CAJZ5v0j6Veze8xDFKTbVZ5=WAfmLdeJ8NXRnh9kwCZgyaDdgew@mail.gmail.com>
Message-ID: <ZYJkTN+GNi1nMkJd@sunil-laptop>

On Tue, Dec 19, 2023 at 06:50:19PM +0100, Rafael J. Wysocki wrote:
> On Tue, Dec 19, 2023 at 6:45?PM Sunil V L <sunilvl at ventanamicro.com> wrote:
> >
> > This series adds support for the below ECR approved by ASWG.
> > 1) MADT - https://drive.google.com/file/d/1oMGPyOD58JaPgMl1pKasT-VKsIKia7zR/view?usp=sharing
> >
> > The series primarily enables irqchip drivers for RISC-V ACPI based
> > platforms.
> >
> > The series can be broadly categorized like below.
> >
> > 1) PCI ACPI related functions are migrated from arm64 to common file so
> > that we don't need to duplicate them for RISC-V.
> >
> > 2) Introduced support for fw_devlink for ACPI nodes for IRQ dependency.
> > This helps to support deferred probe of interrupt controller drivers.
> >
> > 3) Modified pnp_irq() to try registering the IRQ  again if it sees it in
> > disabled state. This solution is similar to how
> > platform_get_irq_optional() works for regular platform devices.
> >
> > 4) Added support for re-ordering the probe of interrupt controllers when
> > IRQCHIP_ACPI_DECLARE is used.
> >
> > 5) ACPI support added in RISC-V interrupt controller drivers.
> >
> > This series is based on Anup's AIA v11 series. Since Anup's AIA v11 is
> > not merged yet and first time introducing fw_devlink, deferred probe and
> > reordering support for IRQCHIP probe, this series is still kept as RFC.
> > Looking forward for the feedback!
> >
> > Changes since RFC v2:
> >         1) Introduced fw_devlink for ACPI nodes for IRQ dependency.
> >         2) Dropped patches in drivers which are not required due to
> >            fw_devlink support.
> >         3) Dropped pci_set_msi() patch and added a patch in
> >            pci_create_root_bus().
> >         4) Updated pnp_irq() patch so that none of the actual PNP
> >            drivers need to change.
> >
> > Changes since RFC v1:
> >         1) Abandoned swnode approach as per Marc's feedback.
> >         2) To cope up with AIA series changes which changed irqchip driver
> >            probe from core_initcall() to platform_driver, added patches
> >            to support deferred probing.
> >         3) Rebased on top of Anup's AIA v11 and added tags.
> >
> > To test the series,
> >
> > 1) Qemu should be built using the riscv_acpi_b2_v8 branch at
> > https://github.com/vlsunil/qemu.git
> >
> > 2) EDK2 should be built using the instructions at:
> > https://github.com/tianocore/edk2/blob/master/OvmfPkg/RiscVVirt/README.md
> >
> > 3) Build Linux using this series on top of Anup's AIA v11 series.
> >
> > Run Qemu:
> > qemu-system-riscv64 \
> >  -M virt,pflash0=pflash0,pflash1=pflash1,aia=aplic-imsic \
> >  -m 2G -smp 8 \
> >  -serial mon:stdio \
> >  -device virtio-gpu-pci -full-screen \
> >  -device qemu-xhci \
> >  -device usb-kbd \
> >  -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \
> >  -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \
> >  -netdev user,id=net0 -device virtio-net-pci,netdev=net0 \
> >  -kernel arch/riscv/boot/Image \
> >  -initrd rootfs.cpio \
> >  -append "root=/dev/ram ro console=ttyS0 rootwait earlycon=uart8250,mmio,0x10000000"
> >
> > To boot with APLIC only, use aia=aplic.
> > To boot with PLIC, remove aia= option.
> >
> > This series is also available in acpi_b2_v3_riscv_aia_v11 branch at
> > https://github.com/vlsunil/linux.git
> >
> > Based-on: 20231023172800.315343-1-apatel at ventanamicro.com
> > (https://lore.kernel.org/lkml/20231023172800.315343-1-apatel at ventanamicro.com/)
> >
> > Sunil V L (17):
> >   arm64: PCI: Migrate ACPI related functions to pci-acpi.c
> >   RISC-V: ACPI: Implement PCI related functionality
> >   PCI: Make pci_create_root_bus() declare its reliance on MSI domains
> >   ACPI: Add fw_devlink support for ACPI fwnode for IRQ dependency
> >   ACPI: irq: Add support for deferred probe in acpi_register_gsi()
> >   pnp.h: Reconfigure IRQ in pnp_irq() to support deferred probe
> >   ACPI: scan.c: Add weak arch specific function to reorder the IRQCHIP
> >     probe
> >   ACPI: RISC-V: Implement arch function to reorder irqchip probe entries
> >   irqchip: riscv-intc: Add ACPI support for AIA
> >   irqchip: riscv-imsic: Add ACPI support
> >   irqchip: riscv-aplic: Add ACPI support
> >   irqchip: irq-sifive-plic: Add ACPI support
> >   ACPI: bus: Add RINTC IRQ model for RISC-V
> >   ACPI: bus: Add acpi_riscv_init function
> >   ACPI: RISC-V: Create APLIC platform device
> >   ACPI: RISC-V: Create PLIC platform device
> >   irqchip: riscv-intc: Set ACPI irqmodel
> 
> JFYI, I have no capacity to provide any feedback on this till 6.8-rc1 is out.
> 
No worries!. I will wait for your feedback.

Thanks!
Sunil


From thiago.bauermann at linaro.org  Tue Dec 19 20:13:41 2023
From: thiago.bauermann at linaro.org (Thiago Jung Bauermann)
Date: Wed, 20 Dec 2023 01:13:41 -0300
Subject: [PATCH v7 00/39] arm64/gcs: Provide support for GCS in userspace
In-Reply-To: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org>
Message-ID: <874jgdh5oq.fsf@linaro.org>


Mark Brown <broonie at kernel.org> writes:

>       arm64/mm: Restructure arch_validate_flags() for extensibility
>       prctl: arch-agnostic prctl for shadow stack
>       mman: Add map_shadow_stack() flags
>       arm64: Document boot requirements for Guarded Control Stacks
>       arm64/gcs: Document the ABI for Guarded Control Stacks
>       arm64/sysreg: Add new system registers for GCS
>       arm64/sysreg: Add definitions for architected GCS caps
>       arm64/gcs: Add manual encodings of GCS instructions
>       arm64/gcs: Provide put_user_gcs()
>       arm64/cpufeature: Runtime detection of Guarded Control Stack (GCS)
>       arm64/mm: Allocate PIE slots for EL0 guarded control stack
>       mm: Define VM_SHADOW_STACK for arm64 when we support GCS
>       arm64/mm: Map pages for guarded control stack
>       KVM: arm64: Manage GCS registers for guests
>       arm64/gcs: Allow GCS usage at EL0 and EL1
>       arm64/idreg: Add overrride for GCS
>       arm64/hwcap: Add hwcap for GCS
>       arm64/traps: Handle GCS exceptions
>       arm64/mm: Handle GCS data aborts
>       arm64/gcs: Context switch GCS state for EL0
>       arm64/gcs: Allocate a new GCS for threads with GCS enabled
>       arm64/gcs: Implement shadow stack prctl() interface
>       arm64/mm: Implement map_shadow_stack()
>       arm64/signal: Set up and restore the GCS context for signal handlers
>       arm64/signal: Expose GCS state in signal frames
>       arm64/ptrace: Expose GCS via ptrace and core files
>       arm64: Add Kconfig for Guarded Control Stack (GCS)
>       kselftest/arm64: Verify the GCS hwcap
>       kselftest/arm64: Add GCS as a detected feature in the signal tests
>       kselftest/arm64: Add framework support for GCS to signal handling tests
>       kselftest/arm64: Allow signals tests to specify an expected si_code
>       kselftest/arm64: Always run signals tests with GCS enabled
>       kselftest/arm64: Add very basic GCS test program
>       kselftest/arm64: Add a GCS test program built with the system libc
>       kselftest/arm64: Add test coverage for GCS mode locking
>       selftests/arm64: Add GCS signal tests
>       kselftest/arm64: Add a GCS stress test
>       kselftest/arm64: Enable GCS for the FP stress tests
>       kselftest/clone3: Enable GCS in the clone3 selftests

Not sure if this is warranted, so sorry for the potential spam:

I don't have any comments on the patches I haven't replied to.

-- 
Thiago


From sunnanyong at huawei.com  Tue Dec 19 21:18:55 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Wed, 20 Dec 2023 13:18:55 +0800
Subject: [PATCH v2 3/3] arm64: mm: Re-enable OPTIMIZE_HUGETLB_VMEMMAP
In-Reply-To: <20231220051855.47547-1-sunnanyong@huawei.com>
References: <20231220051855.47547-1-sunnanyong@huawei.com>
Message-ID: <20231220051855.47547-4-sunnanyong@huawei.com>

Now update of vmemmap page table can follow the rule of
break-before-make safely for arm64 architecture, re-enable
HVO on arm64.

Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
Reviewed-by: Muchun Song <songmuchun at bytedance.com>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..43e3d5576fb2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -103,6 +103,7 @@ config ARM64
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
 	select ARCH_WANT_FRAME_POINTERS
 	select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
+	select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
 	select ARCH_WANT_LD_ORPHAN_WARN
 	select ARCH_WANTS_NO_INSTR
 	select ARCH_WANTS_THP_SWAP if ARM64_4K_PAGES
-- 
2.25.1



From sunnanyong at huawei.com  Tue Dec 19 21:18:52 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Wed, 20 Dec 2023 13:18:52 +0800
Subject: [PATCH v2 0/3] A Solution to Re-enable hugetlb vmemmap optimize
Message-ID: <20231220051855.47547-1-sunnanyong@huawei.com>

HVO was previously disabled on arm64 [1] due to the lack of necessary
BBM(break-before-make) logic when changing page tables.
This set of patches fix this by adding necessary BBM sequence when
changing page table, and supporting vmemmap page fault handling to
fixup kernel address fault if vmemmap is concurrently accessed.

I have tested this patch set with concurrently accessing the vmemmap
address when do BBM and can recover by vmemmap fault handler. Also
tested under the config of 2/3/4 pgtable levels with 4K/64K page size
and all works well.

V2:
This version mainly changes some naming, and uses more appropriate helper
functions to make the code more clean, according to review comments from
Muchun Song and Kefeng Wang.

[1] commit 060a2c92d1b6 ("arm64: mm: hugetlb: Disable HUGETLB_PAGE_OPTIMIZE_VMEMMAP")

Nanyong Sun (3):
  mm: HVO: introduce helper function to update and flush pgtable
  arm64: mm: HVO: support BBM of vmemmap pgtable safely
  arm64: mm: Re-enable OPTIMIZE_HUGETLB_VMEMMAP

 arch/arm64/Kconfig           |  1 +
 arch/arm64/include/asm/esr.h |  4 ++
 arch/arm64/include/asm/mmu.h | 20 +++++++++
 arch/arm64/mm/fault.c        | 78 ++++++++++++++++++++++++++++++++++--
 arch/arm64/mm/mmu.c          | 28 +++++++++++++
 mm/hugetlb_vmemmap.c         | 55 +++++++++++++++++++------
 6 files changed, 171 insertions(+), 15 deletions(-)

-- 
2.25.1



From sunnanyong at huawei.com  Tue Dec 19 21:18:54 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Wed, 20 Dec 2023 13:18:54 +0800
Subject: [PATCH v2 2/3] arm64: mm: HVO: support BBM of vmemmap pgtable safely
In-Reply-To: <20231220051855.47547-1-sunnanyong@huawei.com>
References: <20231220051855.47547-1-sunnanyong@huawei.com>
Message-ID: <20231220051855.47547-3-sunnanyong@huawei.com>

Implement vmemmap_update_pmd and vmemmap_update_pte on arm64 to do
BBM(break-before-make) logic when change the page table of vmemmap
address, they will under the init_mm.page_table_lock.
If a translation fault of vmemmap address concurrently happened after
pte/pmd cleared, vmemmap page fault handler will acquire the
init_mm.page_table_lock to wait for vmemmap update to complete,
by then the virtual address is valid again, so PF can return and
access can continue.
In other case, do the traditional kernel fault.

Implement vmemmap_flush_tlb_all/range on arm64 with nothing
to do because tlb already flushed in every single BBM.

Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
---
 arch/arm64/include/asm/esr.h |  4 ++
 arch/arm64/include/asm/mmu.h | 20 +++++++++
 arch/arm64/mm/fault.c        | 78 ++++++++++++++++++++++++++++++++++--
 arch/arm64/mm/mmu.c          | 28 +++++++++++++
 4 files changed, 127 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index ae35939f395b..1c63256efd25 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -116,6 +116,10 @@
 #define ESR_ELx_FSC_SERROR	(0x11)
 #define ESR_ELx_FSC_ACCESS	(0x08)
 #define ESR_ELx_FSC_FAULT	(0x04)
+#define ESR_ELx_FSC_FAULT_L0    (0x04)
+#define ESR_ELx_FSC_FAULT_L1    (0x05)
+#define ESR_ELx_FSC_FAULT_L2    (0x06)
+#define ESR_ELx_FSC_FAULT_L3    (0x07)
 #define ESR_ELx_FSC_PERM	(0x0C)
 #define ESR_ELx_FSC_SEA_TTW0	(0x14)
 #define ESR_ELx_FSC_SEA_TTW1	(0x15)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 2fcf51231d6e..b553bc37c925 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -76,5 +76,25 @@ extern bool kaslr_requires_kpti(void);
 #define INIT_MM_CONTEXT(name)	\
 	.pgd = init_pg_dir,
 
+#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
+void vmemmap_update_pmd(unsigned long addr, pmd_t *pmdp, pte_t *ptep);
+#define vmemmap_update_pmd vmemmap_update_pmd
+void vmemmap_update_pte(unsigned long addr, pte_t *ptep, pte_t pte);
+#define vmemmap_update_pte vmemmap_update_pte
+
+static inline void vmemmap_flush_tlb_all(void)
+{
+	/* do nothing, already flushed tlb in every single BBM */
+}
+#define vmemmap_flush_tlb_all vmemmap_flush_tlb_all
+
+static inline void vmemmap_flush_tlb_range(unsigned long start,
+					   unsigned long end)
+{
+	/* do nothing, already flushed tlb in every single BBM */
+}
+#define vmemmap_flush_tlb_range vmemmap_flush_tlb_range
+#endif
+
 #endif	/* !__ASSEMBLY__ */
 #endif
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 460d799e1296..21ac2cba66a3 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -368,6 +368,75 @@ static bool is_el1_mte_sync_tag_check_fault(unsigned long esr)
 	return false;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
+static inline bool vmemmap_fault_may_fixup(unsigned long addr,
+					   unsigned long esr)
+{
+	if (addr < VMEMMAP_START || addr >= VMEMMAP_END)
+		return false;
+
+	/*
+	 * Only try to handle translation fault level 2 or level 3,
+	 * because hugetlb vmemmap optimize only clear pmd or pte.
+	 */
+	switch (esr & ESR_ELx_FSC) {
+	case ESR_ELx_FSC_FAULT_L2:
+	case ESR_ELx_FSC_FAULT_L3:
+		return true;
+	default:
+		return false;
+	}
+}
+
+/*
+ * PMD mapped vmemmap should has been split as PTE mapped
+ * by HVO now, here we only check this case, other cases
+ * should fail.
+ * Also should check the addr is healthy enough that will not cause
+ * a level2 or level3 translation fault again after page fault
+ * handled with success, so we need check both bits[1:0] of PMD and
+ * PTE as ARM Spec mentioned below:
+ * A Translation fault is generated if bits[1:0] of a translation
+ * table descriptor identify the descriptor as either a Fault
+ * encoding or a reserved encoding.
+ */
+static inline bool vmemmap_addr_healthy(unsigned long addr)
+{
+	pmd_t *pmdp, pmd;
+	pte_t *ptep, pte;
+
+	pmdp = pmd_off_k(addr);
+	pmd = pmdp_get(pmdp);
+	if (!pmd_table(pmd))
+		return false;
+
+	ptep = pte_offset_kernel(pmdp, addr);
+	pte = ptep_get(ptep);
+	return (pte_val(pte) & PTE_TYPE_MASK) == PTE_TYPE_PAGE;
+}
+
+static bool vmemmap_handle_page_fault(unsigned long addr,
+				      unsigned long esr)
+{
+	bool ret;
+
+	if (likely(!vmemmap_fault_may_fixup(addr, esr)))
+		return false;
+
+	spin_lock(&init_mm.page_table_lock);
+	ret = vmemmap_addr_healthy(addr);
+	spin_unlock(&init_mm.page_table_lock);
+
+	return ret;
+}
+#else
+static inline bool vmemmap_handle_page_fault(unsigned long addr,
+					     unsigned long esr)
+{
+	return false;
+}
+#endif /* CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP */
+
 static bool is_translation_fault(unsigned long esr)
 {
 	return (esr & ESR_ELx_FSC_TYPE) == ESR_ELx_FSC_FAULT;
@@ -405,9 +474,12 @@ static void __do_kernel_fault(unsigned long addr, unsigned long esr,
 	} else if (addr < PAGE_SIZE) {
 		msg = "NULL pointer dereference";
 	} else {
-		if (is_translation_fault(esr) &&
-		    kfence_handle_page_fault(addr, esr & ESR_ELx_WNR, regs))
-			return;
+		if (is_translation_fault(esr)) {
+			if (kfence_handle_page_fault(addr, esr & ESR_ELx_WNR, regs))
+				return;
+			if (vmemmap_handle_page_fault(addr, esr))
+				return;
+		}
 
 		msg = "paging request";
 	}
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 15f6347d23b6..e475495b6851 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1146,6 +1146,34 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node,
 	return 1;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
+/*
+ * In the window between the page table entry is cleared and filled
+ * with a new value, other threads have the opportunity to concurrently
+ * access the vmemmap area then page translation fault occur.
+ * Therefore, we need to ensure that the init_mm.page_table_lock is held
+ * to synchronize the vmemmap page fault handling which will wait for
+ * this lock to be released to ensure that the page table entry has been
+ * refreshed with a new valid value.
+ */
+void vmemmap_update_pmd(unsigned long addr, pmd_t *pmdp, pte_t *ptep)
+{
+	lockdep_assert_held(&init_mm.page_table_lock);
+	pmd_clear(pmdp);
+	flush_tlb_kernel_range(addr, addr + PMD_SIZE);
+	pmd_populate_kernel(&init_mm, pmdp, ptep);
+}
+
+void vmemmap_update_pte(unsigned long addr, pte_t *ptep, pte_t pte)
+{
+	spin_lock(&init_mm.page_table_lock);
+	pte_clear(&init_mm, addr, ptep);
+	flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+	set_pte_at(&init_mm, addr, ptep, pte);
+	spin_unlock(&init_mm.page_table_lock);
+}
+#endif
+
 int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
 		struct vmem_altmap *altmap)
 {
-- 
2.25.1



From sunnanyong at huawei.com  Tue Dec 19 21:18:53 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Wed, 20 Dec 2023 13:18:53 +0800
Subject: [PATCH v2 1/3] mm: HVO: introduce helper function to update and flush pgtable
In-Reply-To: <20231220051855.47547-1-sunnanyong@huawei.com>
References: <20231220051855.47547-1-sunnanyong@huawei.com>
Message-ID: <20231220051855.47547-2-sunnanyong@huawei.com>

Add pmd/pte update and tlb flush helper function to update page
table. This refactoring patch is designed to facilitate each
architecture to implement its own special logic in preparation
for the arm64 architecture to follow the necessary break-before-make
sequence when updating page tables.

Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
Reviewed-by: Muchun Song <songmuchun at bytedance.com>
---
 mm/hugetlb_vmemmap.c | 55 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 43 insertions(+), 12 deletions(-)

diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
index 87818ee7f01d..2187e5410a94 100644
--- a/mm/hugetlb_vmemmap.c
+++ b/mm/hugetlb_vmemmap.c
@@ -45,6 +45,37 @@ struct vmemmap_remap_walk {
 	unsigned long		flags;
 };
 
+#ifndef vmemmap_update_pmd
+static inline void vmemmap_update_pmd(unsigned long addr,
+				      pmd_t *pmdp, pte_t *ptep)
+{
+	pmd_populate_kernel(&init_mm, pmdp, ptep);
+}
+#endif
+
+#ifndef vmemmap_update_pte
+static inline void vmemmap_update_pte(unsigned long addr,
+				      pte_t *ptep, pte_t pte)
+{
+	set_pte_at(&init_mm, addr, ptep, pte);
+}
+#endif
+
+#ifndef vmemmap_flush_tlb_all
+static inline void vmemmap_flush_tlb_all(void)
+{
+	flush_tlb_all();
+}
+#endif
+
+#ifndef vmemmap_flush_tlb_range
+static inline void vmemmap_flush_tlb_range(unsigned long start,
+					   unsigned long end)
+{
+	flush_tlb_kernel_range(start, end);
+}
+#endif
+
 static int split_vmemmap_huge_pmd(pmd_t *pmd, unsigned long start, bool flush)
 {
 	pmd_t __pmd;
@@ -87,9 +118,9 @@ static int split_vmemmap_huge_pmd(pmd_t *pmd, unsigned long start, bool flush)
 
 		/* Make pte visible before pmd. See comment in pmd_install(). */
 		smp_wmb();
-		pmd_populate_kernel(&init_mm, pmd, pgtable);
+		vmemmap_update_pmd(start, pmd, pgtable);
 		if (flush)
-			flush_tlb_kernel_range(start, start + PMD_SIZE);
+			vmemmap_flush_tlb_range(start, start + PMD_SIZE);
 	} else {
 		pte_free_kernel(&init_mm, pgtable);
 	}
@@ -217,7 +248,7 @@ static int vmemmap_remap_range(unsigned long start, unsigned long end,
 	} while (pgd++, addr = next, addr != end);
 
 	if (walk->remap_pte && !(walk->flags & VMEMMAP_REMAP_NO_TLB_FLUSH))
-		flush_tlb_kernel_range(start, end);
+		vmemmap_flush_tlb_range(start, end);
 
 	return 0;
 }
@@ -263,15 +294,15 @@ static void vmemmap_remap_pte(pte_t *pte, unsigned long addr,
 
 		/*
 		 * Makes sure that preceding stores to the page contents from
-		 * vmemmap_remap_free() become visible before the set_pte_at()
-		 * write.
+		 * vmemmap_remap_free() become visible before the
+		 * vmemmap_update_pte() write.
 		 */
 		smp_wmb();
 	}
 
 	entry = mk_pte(walk->reuse_page, pgprot);
 	list_add(&page->lru, walk->vmemmap_pages);
-	set_pte_at(&init_mm, addr, pte, entry);
+	vmemmap_update_pte(addr, pte, entry);
 }
 
 /*
@@ -310,10 +341,10 @@ static void vmemmap_restore_pte(pte_t *pte, unsigned long addr,
 
 	/*
 	 * Makes sure that preceding stores to the page contents become visible
-	 * before the set_pte_at() write.
+	 * before the vmemmap_update_pte() write.
 	 */
 	smp_wmb();
-	set_pte_at(&init_mm, addr, pte, mk_pte(page, pgprot));
+	vmemmap_update_pte(addr, pte, mk_pte(page, pgprot));
 }
 
 /**
@@ -576,7 +607,7 @@ long hugetlb_vmemmap_restore_folios(const struct hstate *h,
 	}
 
 	if (restored)
-		flush_tlb_all();
+		vmemmap_flush_tlb_all();
 	if (!ret)
 		ret = restored;
 	return ret;
@@ -744,7 +775,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
 			break;
 	}
 
-	flush_tlb_all();
+	vmemmap_flush_tlb_all();
 
 	list_for_each_entry(folio, folio_list, lru) {
 		int ret = __hugetlb_vmemmap_optimize_folio(h, folio,
@@ -760,7 +791,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
 		 * allowing more vmemmap remaps to occur.
 		 */
 		if (ret == -ENOMEM && !list_empty(&vmemmap_pages)) {
-			flush_tlb_all();
+			vmemmap_flush_tlb_all();
 			free_vmemmap_page_list(&vmemmap_pages);
 			INIT_LIST_HEAD(&vmemmap_pages);
 			__hugetlb_vmemmap_optimize_folio(h, folio,
@@ -769,7 +800,7 @@ void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_l
 		}
 	}
 
-	flush_tlb_all();
+	vmemmap_flush_tlb_all();
 	free_vmemmap_page_list(&vmemmap_pages);
 }
 
-- 
2.25.1



From bhe at redhat.com  Tue Dec 19 20:22:29 2023
From: bhe at redhat.com (Baoquan He)
Date: Wed, 20 Dec 2023 12:22:29 +0800
Subject: [PATCH v4 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <20231219-twitch-many-ca8877857182@spud>
References: <20231213055747.61826-1-bhe@redhat.com>
 <20231213055747.61826-6-bhe@redhat.com>
 <20231219-twitch-many-ca8877857182@spud>
Message-ID: <ZYJsBW0Y7Y+XhSgf@MiWiFi-R3L-srv>

On 12/19/23 at 02:44pm, Conor Dooley wrote:
> On Wed, Dec 13, 2023 at 01:57:45PM +0800, Baoquan He wrote:
> > Then when specifying '-d' for kexec_file_load interface, loaded
> > locations of kernel/initrd/cmdline etc can be printed out to help debug.
> > 
> > Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > loading related codes.
> > 
> > And also replace pr_notice() with kexec_dprintk() in elf_kexec_load()
> > because loaded location of purgatory and device tree are only printed
> > out for debugging, it doesn't make sense to always print them out.
> > 
> > And also remove kexec_image_info() because the content has been printed
> > out in generic code.
> > 
> > Signed-off-by: Baoquan He <bhe at redhat.com>
> 
> I'm sorry - I meant to look at this several days ago but I forgot.
> Apart from the typo that crept back into $subject, this version explains
> the rationale behind what you're changing a lot better, thanks.

Thanks for careful checking. I forgot the typo fixing you have pointed
out in v3 reviewing.

Hi Andrew,

Could you help fix the typo in subject?

[PATCH v4 5/7] kexec_file, ricv: print out debugging message if required
                           ~~~ s/ricv/riscv/



From cw9316.lee at samsung.com  Tue Dec 19 21:27:37 2023
From: cw9316.lee at samsung.com (Chanwoo Lee)
Date: Wed, 20 Dec 2023 14:27:37 +0900
Subject: [PATCH] ufs: mcq: Adding a function for MCQ enable
References: <CGME20231220052749epcas1p3b90f6c03110ff5f63ffc547ef0f35907@epcas1p3.samsung.com>
Message-ID: <20231220052737.19857-1-cw9316.lee@samsung.com>

From: ChanWoo Lee <cw9316.lee at samsung.com>

The REG_UFS_MEM_CFG register is too general(broad)
and it is difficult to know the meaning of only values of 0x1 and 0x2.
So far, comments were required.

Therefore, I have added new functions and defines
to improve code readability/reusability.

Signed-off-by: ChanWoo Lee <cw9316.lee at samsung.com>
---
 drivers/ufs/core/ufs-mcq.c      | 10 +++++++++-
 drivers/ufs/core/ufshcd.c       |  5 +----
 drivers/ufs/host/ufs-mediatek.c |  4 +---
 include/ufs/ufshcd.h            |  1 +
 include/ufs/ufshci.h            |  4 ++++
 5 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-mcq.c
index 0787456c2b89..a34ef3aac540 100644
--- a/drivers/ufs/core/ufs-mcq.c
+++ b/drivers/ufs/core/ufs-mcq.c
@@ -394,11 +394,19 @@ EXPORT_SYMBOL_GPL(ufshcd_mcq_make_queues_operational);
 
 void ufshcd_mcq_enable_esi(struct ufs_hba *hba)
 {
-	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x2,
+	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | ESI_ENABLE,
 		      REG_UFS_MEM_CFG);
 }
 EXPORT_SYMBOL_GPL(ufshcd_mcq_enable_esi);
 
+void ufshcd_mcq_enable(struct ufs_hba *hba)
+{
+	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | MCQ_MODE_SELECT,
+		      REG_UFS_MEM_CFG);
+	hba->mcq_enabled = true;
+}
+EXPORT_SYMBOL_GPL(ufshcd_mcq_enable);
+
 void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg *msg)
 {
 	ufshcd_writel(hba, msg->address_lo, REG_UFS_ESILBA);
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index ae9936fc6ffb..8195e01e7a3f 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -8723,10 +8723,7 @@ static void ufshcd_config_mcq(struct ufs_hba *hba)
 	hba->host->can_queue = hba->nutrs - UFSHCD_NUM_RESERVED;
 	hba->reserved_slot = hba->nutrs - UFSHCD_NUM_RESERVED;
 
-	/* Select MCQ mode */
-	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
-		      REG_UFS_MEM_CFG);
-	hba->mcq_enabled = true;
+	ufshcd_mcq_enable(hba);
 
 	dev_info(hba->dev, "MCQ configured, nr_queues=%d, io_queues=%d, read_queue=%d, poll_queues=%d, queue_depth=%d\n",
 		 hba->nr_hw_queues, hba->nr_queues[HCTX_TYPE_DEFAULT],
diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index fc61790d289b..1048add66419 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -1219,9 +1219,7 @@ static int ufs_mtk_link_set_hpm(struct ufs_hba *hba)
 		ufs_mtk_config_mcq(hba, false);
 		ufshcd_mcq_make_queues_operational(hba);
 		ufshcd_mcq_config_mac(hba, hba->nutrs);
-		/* Enable MCQ mode */
-		ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
-			      REG_UFS_MEM_CFG);
+		ufshcd_mcq_enable(hba);
 	}
 
 	if (err)
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index d862c8ddce03..a96c45fa4b4b 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -1257,6 +1257,7 @@ unsigned long ufshcd_mcq_poll_cqe_lock(struct ufs_hba *hba,
 					 struct ufs_hw_queue *hwq);
 void ufshcd_mcq_make_queues_operational(struct ufs_hba *hba);
 void ufshcd_mcq_enable_esi(struct ufs_hba *hba);
+void ufshcd_mcq_enable(struct ufs_hba *hba);
 void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg *msg);
 
 int ufshcd_opp_config_clks(struct device *dev, struct opp_table *opp_table,
diff --git a/include/ufs/ufshci.h b/include/ufs/ufshci.h
index d5accacae6bc..e669fad11fd4 100644
--- a/include/ufs/ufshci.h
+++ b/include/ufs/ufshci.h
@@ -282,6 +282,10 @@ enum {
 /* UTMRLRSR - UTP Task Management Request Run-Stop Register 80h */
 #define UTP_TASK_REQ_LIST_RUN_STOP_BIT		0x1
 
+/* REG_UFS_MEM_CFG - Global Config Registers 300h */
+#define MCQ_MODE_SELECT 	0x1
+#define ESI_ENABLE		0x2
+
 /* CQISy - CQ y Interrupt Status Register  */
 #define UFSHCD_MCQ_CQIS_TAIL_ENT_PUSH_STS	0x1
 
-- 
2.29.0



From apopple at nvidia.com  Tue Dec 19 21:25:07 2023
From: apopple at nvidia.com (Alistair Popple)
Date: Wed, 20 Dec 2023 16:25:07 +1100
Subject: [PATCH v4 03/16] mm: Batch-clear PTE ranges during zap_pte_range()
In-Reply-To: <20231218105100.172635-4-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-4-ryan.roberts@arm.com>
Message-ID: <87zfy5zbmu.fsf@nvdebian.thelocal>


Ryan Roberts <ryan.roberts at arm.com> writes:

[...]

> diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
> index 4f559f4ddd21..39725756e6bf 100644
> --- a/mm/mmu_gather.c
> +++ b/mm/mmu_gather.c
> @@ -47,6 +47,21 @@ static bool tlb_next_batch(struct mmu_gather *tlb)
>  	return true;
>  }
>  
> +unsigned int tlb_reserve_space(struct mmu_gather *tlb, unsigned int nr)
> +{
> +	struct mmu_gather_batch *batch = tlb->active;
> +	unsigned int nr_alloc = batch->max - batch->nr;
> +
> +	while (nr_alloc < nr) {
> +		if (!tlb_next_batch(tlb))
> +			break;
> +		nr_alloc += tlb->active->max;
> +	}
> +
> +	tlb->active = batch;
> +	return nr_alloc;
> +}

Agree this addresses my previous comment nicely, so you can add:

Reviewed-by: Alistair Popple <apopple at nvidia.com>

> +
>  #ifdef CONFIG_SMP
>  static void tlb_flush_rmap_batch(struct mmu_gather_batch *batch, struct vm_area_struct *vma)
>  {



From apopple at nvidia.com  Tue Dec 19 21:28:25 2023
From: apopple at nvidia.com (Alistair Popple)
Date: Wed, 20 Dec 2023 16:28:25 +1100
Subject: [PATCH v4 16/16] arm64/mm: Implement clear_ptes() to optimize
 exit, munmap, dontneed
In-Reply-To: <20231218105100.172635-17-ryan.roberts@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-17-ryan.roberts@arm.com>
Message-ID: <87v88tzbfe.fsf@nvdebian.thelocal>


Ryan Roberts <ryan.roberts at arm.com> writes:

> With the core-mm changes in place to batch-clear ptes during
> zap_pte_range(), we can take advantage of this in arm64 to greatly
> reduce the number of tlbis we have to issue, and recover the lost
> performance in exit, munmap and madvise(DONTNEED) incured when adding
> support for transparent contiguous ptes.
>
> If we are clearing a whole contpte range, we can elide first unfolding
> that range and save the tlbis. We just clear the whole range.
>
> The following microbenchmark results demonstate the effect of this
> change on madvise(DONTNEED) performance for large pte-mapped folios.
> madvise(dontneed) is called for each page of a 1G populated mapping and
> the total time is measured. 100 iterations per run, 8 runs performed on
> both Apple M2 (VM) and Ampere Altra (bare metal). Tests performed for
> case where 1G memory is comprised of pte-mapped order-9 folios. Negative
> is faster, positive is slower, compared to baseline upon which the
> series is based:
>
> | dontneed      |    Apple M2 VM    |    Ampere Altra   |
> | order-9       |-------------------|-------------------|
> | (pte-map)     |    mean |   stdev |    mean |   stdev |
> |---------------|---------|---------|---------|---------|
> | baseline      |    0.0% |    7.9% |    0.0% |    0.0% |
> | before-change |   -1.3% |    7.0% |   13.0% |    0.0% |
> | after-change  |   -9.9% |    0.9% |   14.1% |    0.0% |
>
> The memory is initially all contpte-mapped and has to be unfolded (which
> requires tlbi for the whole block) when the first page is touched (since
> the test is madvise-ing 1 page at a time). Ampere Altra has high cost
> for tlbi; this is why cost increases there.
>
> The following microbenchmark results demonstate the recovery (and
> overall improvement) of munmap performance for large pte-mapped folios.
> munmap is called for a 1G populated mapping and the function runtime is
> measured. 100 iterations per run, 8 runs performed on both Apple M2 (VM)
> and Ampere Altra (bare metal). Tests performed for case where 1G memory
> is comprised of pte-mapped order-9 folios. Negative is faster, positive
> is slower, compared to baseline upon which the series is based:
>
> | munmap        |    Apple M2 VM    |    Ampere Altra   |
> | order-9       |-------------------|-------------------|
> | (pte-map)     |    mean |   stdev |    mean |   stdev |
> |---------------|---------|---------|---------|---------|
> | baseline      |    0.0% |    6.4% |    0.0% |    0.1% |
> | before-change |   43.3% |    1.9% |  375.2% |    0.0% |
> | after-change  |   -6.0% |    1.4% |   -0.6% |    0.2% |
>
> Tested-by: John Hubbard <jhubbard at nvidia.com>
> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
> ---
>  arch/arm64/include/asm/pgtable.h | 42 +++++++++++++++++++++++++++++
>  arch/arm64/mm/contpte.c          | 45 ++++++++++++++++++++++++++++++++
>  2 files changed, 87 insertions(+)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index d4805f73b9db..f5bf059291c3 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -953,6 +953,29 @@ static inline pte_t __ptep_get_and_clear(struct mm_struct *mm,
>  	return pte;
>  }
>  
> +static inline pte_t __clear_ptes(struct mm_struct *mm,
> +				 unsigned long address, pte_t *ptep,
> +				 unsigned int nr, int full)

Ping on my previous comment - why not just use the generic version
defined in patch 3 which is basically identical to this?

> +{
> +	pte_t orig_pte = __ptep_get_and_clear(mm, address, ptep);
> +	unsigned int i;
> +	pte_t pte;
> +
> +	for (i = 1; i < nr; i++) {
> +		address += PAGE_SIZE;
> +		ptep++;
> +		pte = __ptep_get_and_clear(mm, address, ptep);
> +
> +		if (pte_dirty(pte))
> +			orig_pte = pte_mkdirty(orig_pte);
> +
> +		if (pte_young(pte))
> +			orig_pte = pte_mkyoung(orig_pte);
> +	}
> +
> +	return orig_pte;
> +}
> +
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  #define __HAVE_ARCH_PMDP_HUGE_GET_AND_CLEAR
>  static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
> @@ -1151,6 +1174,8 @@ extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
>  extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
>  extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>  				pte_t *ptep, pte_t pte, unsigned int nr);
> +extern pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr,
> +				pte_t *ptep, unsigned int nr, int full);
>  extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>  				unsigned long addr, pte_t *ptep);
>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
> @@ -1279,6 +1304,22 @@ static inline void pte_clear(struct mm_struct *mm,
>  	__pte_clear(mm, addr, ptep);
>  }
>  
> +#define clear_ptes clear_ptes
> +static inline pte_t clear_ptes(struct mm_struct *mm,
> +				unsigned long addr, pte_t *ptep,
> +				unsigned int nr, int full)
> +{
> +	pte_t pte;
> +
> +	if (nr == 1) {
> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
> +		pte = __ptep_get_and_clear(mm, addr, ptep);
> +	} else
> +		pte = contpte_clear_ptes(mm, addr, ptep, nr, full);
> +
> +	return pte;
> +}
> +
>  #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
>  static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
>  				unsigned long addr, pte_t *ptep)
> @@ -1366,6 +1407,7 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma,
>  #define set_pte					__set_pte
>  #define set_ptes				__set_ptes
>  #define pte_clear				__pte_clear
> +#define clear_ptes				__clear_ptes
>  #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
>  #define ptep_get_and_clear			__ptep_get_and_clear
>  #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
> index 72e672024785..6f2a15ac5163 100644
> --- a/arch/arm64/mm/contpte.c
> +++ b/arch/arm64/mm/contpte.c
> @@ -293,6 +293,51 @@ void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>  }
>  EXPORT_SYMBOL(contpte_set_ptes);
>  
> +pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
> +					unsigned int nr, int full)
> +{
> +	/*
> +	 * If we cover a partial contpte block at the beginning or end of the
> +	 * batch, unfold if currently folded. This makes it safe to clear some
> +	 * of the entries while keeping others. contpte blocks in the middle of
> +	 * the range, which are fully covered don't need to be unfolded because
> +	 * we will clear the full block.
> +	 */
> +
> +	unsigned int i;
> +	pte_t pte;
> +	pte_t tail;
> +
> +	if (!mm_is_user(mm))
> +		return __clear_ptes(mm, addr, ptep, nr, full);
> +
> +	if (ptep != contpte_align_down(ptep) || nr < CONT_PTES)
> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
> +
> +	if (ptep + nr != contpte_align_down(ptep + nr))
> +		contpte_try_unfold(mm, addr + PAGE_SIZE * (nr - 1),
> +				   ptep + nr - 1,
> +				   __ptep_get(ptep + nr - 1));
> +
> +	pte = __ptep_get_and_clear(mm, addr, ptep);
> +
> +	for (i = 1; i < nr; i++) {
> +		addr += PAGE_SIZE;
> +		ptep++;
> +
> +		tail = __ptep_get_and_clear(mm, addr, ptep);
> +
> +		if (pte_dirty(tail))
> +			pte = pte_mkdirty(pte);
> +
> +		if (pte_young(tail))
> +			pte = pte_mkyoung(pte);
> +	}
> +
> +	return pte;
> +}
> +EXPORT_SYMBOL(contpte_clear_ptes);
> +
>  int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>  					unsigned long addr, pte_t *ptep)
>  {



From gregkh at linuxfoundation.org  Tue Dec 19 21:57:54 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 20 Dec 2023 06:57:54 +0100
Subject: [PATCH v3 2/3] usb: xhci-mtk: fix a short packet issue of gen1
 isoc-in transfer
In-Reply-To: <20231220025842.7082-2-chunfeng.yun@mediatek.com>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
 <20231220025842.7082-2-chunfeng.yun@mediatek.com>
Message-ID: <2023122033-footprint-impose-9989@gregkh>

On Wed, Dec 20, 2023 at 10:58:41AM +0800, Chunfeng Yun wrote:
> For Gen1 isoc-in transfer, host still send out unexpected ACK after device
> finish the burst with a short packet, this will cause an exception on the
> connected device, such as, a usb 4k camera.
> It can be fixed by setting rxfifo depth less than 4k bytes, prefer to use
> 3k here, the side-effect is that may cause performance drop about 10%,
> including bulk transfer.
> 
> Fixes: 926d60ae64a6 ("usb: xhci-mtk: modify the SOF/ITP interval for mt8195")
> Cc: stable at vger.kernel.org
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
> v3:
> add Cc stable

Why is a patch that you are marking for stable inclusion (and I am
guessing inclusion in 6.7-final) in the middle of other patches that are
not marked as such?

Always split out bugfixes from other things so that they can go through
the two different branches, one for this current release, and one for
the next one.

Otherwise you will have to wait until 6.8-rc1 for this bugfix to land,
which I doubt you intend to have happen.

Please fix up and resend 2 different patch series.

thanks,

greg k-h


From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:31 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:31 -0800
Subject: [PATCH v3 4/9] iommu/arm-smmu: Allow using a threaded handler for context interrupts
In-Reply-To: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
Message-ID: <20231220060236.18600-5-quic_c_gdjako@quicinc.com>

Threaded IRQ handlers run in a less critical context compared to normal
IRQs, so they can perform more complex and time-consuming operations
without causing significant delays in other parts of the kernel.
During a context fault, it might be needed to do more processing and
gather debug information from TBUs in the handler. These operations may
sleep, so add an option to use a threaded IRQ handler in these cases.

Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 12 ++++++++++--
 drivers/iommu/arm/arm-smmu/arm-smmu.h |  1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 68b6bc5e7c71..82436a454c5e 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -806,8 +806,16 @@ static int arm_smmu_init_domain_context(struct arm_smmu_domain *smmu_domain,
 	else
 		context_fault = arm_smmu_context_fault;
 
-	ret = devm_request_irq(smmu->dev, irq, context_fault, IRQF_SHARED,
-			       "arm-smmu-context-fault", smmu_domain);
+	if (smmu->impl && smmu->impl->context_fault_needs_threaded_irq)
+		ret = devm_request_threaded_irq(smmu->dev, irq, NULL,
+						context_fault,
+						IRQF_ONESHOT | IRQF_SHARED,
+						"arm-smmu-context-fault",
+						smmu_domain);
+	else
+		ret = devm_request_irq(smmu->dev, irq, context_fault, IRQF_SHARED,
+				       "arm-smmu-context-fault", smmu_domain);
+
 	if (ret < 0) {
 		dev_err(smmu->dev, "failed to request context IRQ %d (%u)\n",
 			cfg->irptndx, irq);
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 17f704920190..54cb9dfcec76 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -438,6 +438,7 @@ struct arm_smmu_impl {
 	int (*def_domain_type)(struct device *dev);
 	irqreturn_t (*global_fault)(int irq, void *dev);
 	irqreturn_t (*context_fault)(int irq, void *dev);
+	bool context_fault_needs_threaded_irq;
 	int (*alloc_context_bank)(struct arm_smmu_domain *smmu_domain,
 				  struct arm_smmu_device *smmu,
 				  struct device *dev, int start);


From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:30 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:30 -0800
Subject: [PATCH v3 3/9] iommu/arm-smmu-qcom-tbu: Add Qualcomm TBU driver
In-Reply-To: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
Message-ID: <20231220060236.18600-4-quic_c_gdjako@quicinc.com>

Add a driver for the Qualcomm implementation of the MMU-500 TBU.

Operating the TBUs (Translation Buffer Units) from Linux can help
with debugging context faults. The TBUs can provide debug features
such as running ATOS (Address Translation Operations) to manually
trigger address translation of IOVA to physical address in hardware.

The driver will control the resources needed by the TBU to allow
running ATOS on the TBUs or check for outstanding transactions.

Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
---
 drivers/iommu/Kconfig                         |   8 +
 drivers/iommu/arm/arm-smmu/Makefile           |   1 +
 .../iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c    | 366 ++++++++++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h    |   2 +
 drivers/iommu/arm/arm-smmu/arm-smmu.h         |   2 +
 5 files changed, 379 insertions(+)
 create mode 100644 drivers/iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 9a29d742617e..314dc5dbe7ea 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -371,6 +371,14 @@ config ARM_SMMU_QCOM
 	  When running on a Qualcomm platform that has the custom variant
 	  of the ARM SMMU, this needs to be built into the SMMU driver.
 
+config ARM_SMMU_QCOM_TBU
+	bool "Qualcomm TBU driver"
+	depends on ARM_SMMU_QCOM
+	help
+	  The SMMU on Qualcomm platform may include a Translation Buffer
+	  Units (TBUs) for each master. Enabling support for these will
+	  allow operating the TBUs to help debugging context faults.
+
 config ARM_SMMU_QCOM_DEBUG
 	bool "ARM SMMU QCOM implementation defined debug support"
 	depends on ARM_SMMU_QCOM
diff --git a/drivers/iommu/arm/arm-smmu/Makefile b/drivers/iommu/arm/arm-smmu/Makefile
index 2a5a95e8e3f9..c35ff78fcfd5 100644
--- a/drivers/iommu/arm/arm-smmu/Makefile
+++ b/drivers/iommu/arm/arm-smmu/Makefile
@@ -3,4 +3,5 @@ obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
 obj-$(CONFIG_ARM_SMMU) += arm_smmu.o
 arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-nvidia.o
 arm_smmu-$(CONFIG_ARM_SMMU_QCOM) += arm-smmu-qcom.o
+arm_smmu-$(CONFIG_ARM_SMMU_QCOM_TBU) += arm-smmu-qcom-tbu.o
 arm_smmu-$(CONFIG_ARM_SMMU_QCOM_DEBUG) += arm-smmu-qcom-debug.o
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c
new file mode 100644
index 000000000000..2ff00e06d3bf
--- /dev/null
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#include <linux/interconnect.h>
+#include <linux/iopoll.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+#include "arm-smmu.h"
+#include "arm-smmu-qcom.h"
+
+#define TBU_DBG_TIMEOUT_US		100
+#define DEBUG_AXUSER_REG		0x30
+#define DEBUG_AXUSER_CDMID		GENMASK_ULL(43, 36)
+#define DEBUG_AXUSER_CDMID_VAL		0xff
+#define DEBUG_PAR_REG			0x28
+#define DEBUG_PAR_FAULT_VAL		BIT(0)
+#define DEBUG_PAR_PA			GENMASK_ULL(47, 12)
+#define DEBUG_SID_HALT_REG		0x0
+#define DEBUG_SID_HALT_VAL		BIT(16)
+#define DEBUG_SID_HALT_SID		GENMASK(9, 0)
+#define DEBUG_SR_HALT_ACK_REG		0x20
+#define DEBUG_SR_HALT_ACK_VAL		BIT(1)
+#define DEBUG_SR_ECATS_RUNNING_VAL	BIT(0)
+#define DEBUG_TXN_AXCACHE		GENMASK(5, 2)
+#define DEBUG_TXN_AXPROT		GENMASK(8, 6)
+#define DEBUG_TXN_AXPROT_PRIV		0x1
+#define DEBUG_TXN_AXPROT_NSEC		0x2
+#define DEBUG_TXN_TRIGG_REG		0x18
+#define DEBUG_TXN_TRIGGER		BIT(0)
+#define DEBUG_VA_ADDR_REG		0x8
+
+struct qsmmuv500_tbu {
+	struct device *dev;
+	struct arm_smmu_device *smmu;
+	u32 sid_range[2];
+	struct list_head list;
+	struct clk *clk;
+	struct icc_path	*path;
+	void __iomem *base;
+	spinlock_t halt_lock; /* multiple halt or resume can't execute concurrently */
+	int halt_count;
+};
+
+static DEFINE_SPINLOCK(atos_lock);
+
+static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
+{
+	return container_of(smmu, struct qcom_smmu, smmu);
+}
+
+static struct qsmmuv500_tbu *qsmmuv500_find_tbu(struct qcom_smmu *qsmmu, u32 sid)
+{
+	struct qsmmuv500_tbu *tbu = NULL;
+	u32 start, end;
+
+	mutex_lock(&qsmmu->tbu_list_lock);
+
+	list_for_each_entry(tbu, &qsmmu->tbu_list, list) {
+		start = tbu->sid_range[0];
+		end = start + tbu->sid_range[1];
+
+		if (start <= sid && sid < end)
+			break;
+	}
+
+	mutex_unlock(&qsmmu->tbu_list_lock);
+
+	return tbu;
+}
+
+static int qsmmuv500_tbu_halt(struct qsmmuv500_tbu *tbu, struct arm_smmu_domain *smmu_domain)
+{
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	int ret = 0, idx = smmu_domain->cfg.cbndx;
+	unsigned long flags;
+	u32 val, fsr, status;
+
+	spin_lock_irqsave(&tbu->halt_lock, flags);
+	if (tbu->halt_count) {
+		tbu->halt_count++;
+		goto out;
+	}
+
+	val = readl_relaxed(tbu->base + DEBUG_SID_HALT_REG);
+	val |= DEBUG_SID_HALT_VAL;
+	writel_relaxed(val, tbu->base + DEBUG_SID_HALT_REG);
+
+	fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
+	if ((fsr & ARM_SMMU_FSR_FAULT) && (fsr & ARM_SMMU_FSR_SS)) {
+		u32 sctlr_orig, sctlr;
+
+		/*
+		 * We are in a fault. Our request to halt the bus will not
+		 * complete until transactions in front of us (such as the fault
+		 * itself) have completed. Disable iommu faults and terminate
+		 * any existing transactions.
+		 */
+		sctlr_orig = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_SCTLR);
+		sctlr = sctlr_orig & ~(ARM_SMMU_SCTLR_CFCFG | ARM_SMMU_SCTLR_CFIE);
+		arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, sctlr);
+		arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_FSR, fsr);
+		arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_RESUME, ARM_SMMU_RESUME_TERMINATE);
+		arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, sctlr_orig);
+	}
+
+	if (readl_poll_timeout_atomic(tbu->base + DEBUG_SR_HALT_ACK_REG, status,
+				      (status & DEBUG_SR_HALT_ACK_VAL),
+				      0, TBU_DBG_TIMEOUT_US)) {
+		dev_err(tbu->dev, "Timeout while trying to halt TBU!\n");
+		ret = -ETIMEDOUT;
+
+		val = readl_relaxed(tbu->base + DEBUG_SID_HALT_REG);
+		val &= ~DEBUG_SID_HALT_VAL;
+		writel_relaxed(val, tbu->base + DEBUG_SID_HALT_REG);
+
+		goto out;
+	}
+
+	tbu->halt_count = 1;
+
+out:
+	spin_unlock_irqrestore(&tbu->halt_lock, flags);
+	return ret;
+}
+
+static void qsmmuv500_tbu_resume(struct qsmmuv500_tbu *tbu)
+{
+	unsigned long flags;
+	u32 val;
+
+	spin_lock_irqsave(&tbu->halt_lock, flags);
+	if (!tbu->halt_count) {
+		WARN(1, "%s: halt_count is 0", dev_name(tbu->dev));
+		goto out;
+	}
+
+	if (tbu->halt_count > 1) {
+		tbu->halt_count--;
+		goto out;
+	}
+
+	val = readl_relaxed(tbu->base + DEBUG_SID_HALT_REG);
+	val &= ~DEBUG_SID_HALT_VAL;
+	writel_relaxed(val, tbu->base + DEBUG_SID_HALT_REG);
+
+	tbu->halt_count = 0;
+out:
+	spin_unlock_irqrestore(&tbu->halt_lock, flags);
+}
+
+static phys_addr_t qsmmuv500_tbu_trigger_atos(struct arm_smmu_domain *smmu_domain,
+					      struct qsmmuv500_tbu *tbu, dma_addr_t iova, u32 sid)
+{
+	bool atos_timedout = false;
+	phys_addr_t phys = 0;
+	ktime_t timeout;
+	u64 val;
+
+	/* Set address and stream-id */
+	val = readq_relaxed(tbu->base + DEBUG_SID_HALT_REG);
+	val &= ~DEBUG_SID_HALT_SID;
+	val |= FIELD_PREP(DEBUG_SID_HALT_SID, sid);
+	writeq_relaxed(val, tbu->base + DEBUG_SID_HALT_REG);
+	writeq_relaxed(iova, tbu->base + DEBUG_VA_ADDR_REG);
+	val = FIELD_PREP(DEBUG_AXUSER_CDMID, DEBUG_AXUSER_CDMID_VAL);
+	writeq_relaxed(val, tbu->base + DEBUG_AXUSER_REG);
+
+	/* Write-back read and write-allocate */
+	val = FIELD_PREP(DEBUG_TXN_AXCACHE, 0xf);
+
+	/* Non-secure access */
+	val |= FIELD_PREP(DEBUG_TXN_AXPROT, DEBUG_TXN_AXPROT_NSEC);
+
+	/* Priviledged access */
+	val |= FIELD_PREP(DEBUG_TXN_AXPROT, DEBUG_TXN_AXPROT_PRIV);
+
+	val |= DEBUG_TXN_TRIGGER;
+	writeq_relaxed(val, tbu->base + DEBUG_TXN_TRIGG_REG);
+
+	timeout = ktime_add_us(ktime_get(), TBU_DBG_TIMEOUT_US);
+	for (;;) {
+		val = readl_relaxed(tbu->base + DEBUG_SR_HALT_ACK_REG);
+		if (!(val & DEBUG_SR_ECATS_RUNNING_VAL))
+			break;
+		val = readl_relaxed(tbu->base + DEBUG_PAR_REG);
+		if (val & DEBUG_PAR_FAULT_VAL)
+			break;
+		if (ktime_compare(ktime_get(), timeout) > 0) {
+			atos_timedout = true;
+			break;
+		}
+	}
+
+	val = readq_relaxed(tbu->base + DEBUG_PAR_REG);
+	if (val & DEBUG_PAR_FAULT_VAL)
+		dev_err(tbu->dev, "ATOS generated a fault interrupt! PAR = %llx, SID=0x%x\n",
+			val, sid);
+	else if (atos_timedout)
+		dev_err_ratelimited(tbu->dev, "ATOS translation timed out!\n");
+	else
+		phys = FIELD_GET(DEBUG_PAR_PA, val);
+
+	/* Reset hardware */
+	writeq_relaxed(0, tbu->base + DEBUG_TXN_TRIGG_REG);
+	writeq_relaxed(0, tbu->base + DEBUG_VA_ADDR_REG);
+	val = readl_relaxed(tbu->base + DEBUG_SID_HALT_REG);
+	val &= ~DEBUG_SID_HALT_SID;
+	writel_relaxed(val, tbu->base + DEBUG_SID_HALT_REG);
+
+	return phys;
+}
+
+static phys_addr_t qsmmuv500_iova_to_phys(struct arm_smmu_domain *smmu_domain,
+					  dma_addr_t iova, u32 sid)
+{
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+	int idx = smmu_domain->cfg.cbndx;
+	struct qsmmuv500_tbu *tbu;
+	u32 sctlr_orig, sctlr;
+	phys_addr_t phys = 0;
+	unsigned long flags;
+	int attempt = 0;
+	int ret;
+	u64 fsr;
+
+	tbu = qsmmuv500_find_tbu(qsmmu, sid);
+	if (!tbu)
+		return 0;
+
+	ret = icc_set_bw(tbu->path, 0, UINT_MAX);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(tbu->clk);
+	if (ret)
+		goto disable_icc;
+
+	ret = qsmmuv500_tbu_halt(tbu, smmu_domain);
+	if (ret)
+		goto disable_clk;
+
+	/*
+	 * ATOS/ECATS can trigger the fault interrupt, so disable it temporarily
+	 * and check for an interrupt manually.
+	 */
+	sctlr_orig = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_SCTLR);
+	sctlr = sctlr_orig & ~(ARM_SMMU_SCTLR_CFCFG | ARM_SMMU_SCTLR_CFIE);
+	arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, sctlr);
+
+	fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
+	if (fsr & ARM_SMMU_FSR_FAULT) {
+		/* Clear pending interrupts */
+		arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_FSR, fsr);
+
+		/*
+		 * TBU halt takes care of resuming any stalled transcation.
+		 * Kept it here for completeness sake.
+		 */
+		if (fsr & ARM_SMMU_FSR_SS)
+			arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_RESUME,
+					  ARM_SMMU_RESUME_TERMINATE);
+	}
+
+	/* Only one concurrent atos operation */
+	spin_lock_irqsave(&atos_lock, flags);
+
+	/*
+	 * If the translation fails, attempt the lookup more time."
+	 */
+	do {
+		phys = qsmmuv500_tbu_trigger_atos(smmu_domain, tbu, iova, sid);
+
+		fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
+		if (fsr & ARM_SMMU_FSR_FAULT) {
+			/* Clear pending interrupts */
+			arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_FSR, fsr);
+
+			if (fsr & ARM_SMMU_FSR_SS)
+				arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_RESUME,
+						  ARM_SMMU_RESUME_TERMINATE);
+		}
+	} while (!phys && attempt++ < 2);
+
+	arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, sctlr_orig);
+	spin_unlock_irqrestore(&atos_lock, flags);
+	qsmmuv500_tbu_resume(tbu);
+
+	/* Read to complete prior write transcations */
+	readl_relaxed(tbu->base + DEBUG_SR_HALT_ACK_REG);
+
+disable_clk:
+	clk_disable_unprepare(tbu->clk);
+disable_icc:
+	icc_set_bw(tbu->path, 0, 0);
+
+	return phys;
+}
+
+static int qsmmuv500_tbu_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device *dev = &pdev->dev;
+	struct arm_smmu_device *smmu;
+	struct qsmmuv500_tbu *tbu;
+	struct qcom_smmu *qsmmu;
+	int ret;
+
+	smmu = dev_get_drvdata(dev->parent);
+	if (!smmu)
+		return -EPROBE_DEFER;
+
+	qsmmu = to_qcom_smmu(smmu);
+
+	tbu = devm_kzalloc(dev, sizeof(*tbu), GFP_KERNEL);
+	if (!tbu)
+		return -ENOMEM;
+
+	tbu->dev = dev;
+	INIT_LIST_HEAD(&tbu->list);
+	spin_lock_init(&tbu->halt_lock);
+
+	tbu->base = devm_of_iomap(dev, np, 0, NULL);
+	if (IS_ERR(tbu->base))
+		return PTR_ERR(tbu->base);
+
+	ret = of_property_read_u32_array(np, "stream-id-range", tbu->sid_range, 2);
+	if (ret) {
+		dev_err(dev, "The DT property 'stream-id-range' is mandatory\n");
+		return ret;
+	}
+
+	tbu->clk = devm_clk_get_optional(dev, NULL);
+	if (IS_ERR(tbu->clk))
+		return PTR_ERR(tbu->clk);
+
+	tbu->path = devm_of_icc_get(dev, NULL);
+	if (IS_ERR(tbu->path))
+		return PTR_ERR(tbu->path);
+
+	mutex_lock(&qsmmu->tbu_list_lock);
+	list_add_tail(&tbu->list, &qsmmu->tbu_list);
+	mutex_unlock(&qsmmu->tbu_list_lock);
+
+	dev_set_drvdata(dev, tbu);
+
+	return 0;
+}
+
+static const struct of_device_id qsmmuv500_tbu_of_match[] = {
+	{ .compatible = "qcom,qsmmuv500-tbu" },
+	{ }
+};
+
+static struct platform_driver qsmmuv500_tbu_driver = {
+	.driver = {
+		.name           = "qsmmuv500-tbu",
+		.of_match_table = qsmmuv500_tbu_of_match,
+	},
+	.probe = qsmmuv500_tbu_probe,
+};
+builtin_platform_driver(qsmmuv500_tbu_driver);
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
index 2164a9cf3dde..1c0cf393d04e 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
@@ -32,6 +32,8 @@ struct qcom_smmu_match_data {
 	const struct arm_smmu_impl *adreno_impl;
 };
 
+irqreturn_t qcom_smmu_context_fault(int irq, void *dev);
+
 #ifdef CONFIG_ARM_SMMU_QCOM_DEBUG
 void qcom_smmu_tlb_sync_debug(struct arm_smmu_device *smmu);
 #else
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index d375e910b52c..17f704920190 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -136,6 +136,7 @@ enum arm_smmu_cbar_type {
 #define ARM_SMMU_CBAR_VMID		GENMASK(7, 0)
 
 #define ARM_SMMU_GR1_CBFRSYNRA(n)	(0x400 + ((n) << 2))
+#define ARM_SMMU_CBFRSYNRA_SID		GENMASK(15, 0)
 
 #define ARM_SMMU_GR1_CBA2R(n)		(0x800 + ((n) << 2))
 #define ARM_SMMU_CBA2R_VMID16		GENMASK(31, 16)
@@ -238,6 +239,7 @@ enum arm_smmu_cbar_type {
 #define ARM_SMMU_CB_ATSR		0x8f0
 #define ARM_SMMU_ATSR_ACTIVE		BIT(0)
 
+#define ARM_SMMU_RESUME_TERMINATE	BIT(0)
 
 /* Maximum number of context banks per SMMU */
 #define ARM_SMMU_MAX_CBS		128


From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:29 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:29 -0800
Subject: [PATCH v3 2/9] iommu/arm-smmu-qcom: Add support for TBUs
In-Reply-To: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
Message-ID: <20231220060236.18600-3-quic_c_gdjako@quicinc.com>

The ARM MMU-500 implements a Translation Buffer Unit (TBU) for each
connected master besides a single TCU which controls and manages the
address translations.

Allow the Qualcomm SMMU driver to probe for any TBU devices that can
provide additional debug features like triggering transactions, logging
outstanding transactions, snapshot capture etc. The primary use-case
would be to get information from a TBU and print it during a context
fault.

Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 9 +++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h | 4 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 8b04ece00420..581401d6c18a 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -1,12 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
  * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
  */
 
 #include <linux/acpi.h>
 #include <linux/adreno-smmu-priv.h>
 #include <linux/delay.h>
 #include <linux/of_device.h>
+#include <linux/of_platform.h>
 #include <linux/firmware/qcom/qcom_scm.h>
 
 #include "arm-smmu.h"
@@ -446,6 +448,7 @@ static struct arm_smmu_device *qcom_smmu_create(struct arm_smmu_device *smmu,
 	const struct device_node *np = smmu->dev->of_node;
 	const struct arm_smmu_impl *impl;
 	struct qcom_smmu *qsmmu;
+	int ret;
 
 	if (!data)
 		return ERR_PTR(-EINVAL);
@@ -469,6 +472,12 @@ static struct arm_smmu_device *qcom_smmu_create(struct arm_smmu_device *smmu,
 	qsmmu->smmu.impl = impl;
 	qsmmu->cfg = data->cfg;
 
+	INIT_LIST_HEAD(&qsmmu->tbu_list);
+	mutex_init(&qsmmu->tbu_list_lock);
+	ret = devm_of_platform_populate(smmu->dev);
+	if (ret)
+		return ERR_PTR(ret);
+
 	return &qsmmu->smmu;
 }
 
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
index 593910567b88..2164a9cf3dde 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2022-2023, Qualcomm Innovation Center, Inc. All rights reserved.
  */
 
 #ifndef _ARM_SMMU_QCOM_H
@@ -12,6 +12,8 @@ struct qcom_smmu {
 	bool bypass_quirk;
 	u8 bypass_cbndx;
 	u32 stall_enabled;
+	struct mutex tbu_list_lock;  /* protects tbu_list */
+	struct list_head tbu_list;
 };
 
 enum qcom_smmu_impl_reg_offset {


From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:33 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:33 -0800
Subject: [PATCH v3 6/9] arm64: dts: qcom: sdm845: Add DT nodes for the TBUs
In-Reply-To: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
Message-ID: <20231220060236.18600-7-quic_c_gdjako@quicinc.com>

Add the device-tree nodes for the TBUs (translation buffer units) that
are present on the sdm845 platforms. The TBUs can be used debug the
kernel and provide additional information when a context faults occur.

Describe the all registers, clocks, interconnects and power-domain
resources that are needed for each of the TBUs.

Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 74 ++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c2244824355a..c3dfa74d9403 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -15,6 +15,7 @@
 #include <dt-bindings/dma/qcom-gpi.h>
 #include <dt-bindings/firmware/qcom,scm.h>
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interconnect/qcom,icc.h>
 #include <dt-bindings/interconnect/qcom,osm-l3.h>
 #include <dt-bindings/interconnect/qcom,sdm845.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -5005,6 +5006,7 @@
 		apps_smmu: iommu at 15000000 {
 			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
 			reg = <0 0x15000000 0 0x80000>;
+			ranges;
 			#iommu-cells = <2>;
 			#global-interrupts = <1>;
 			interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
@@ -5072,6 +5074,78 @@
 				     <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>;
+
+			#address-cells = <2>;
+			#size-cells = <2>;
+
+			anoc_1_tbu: tbu at 150c5000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x150c5000 0x0 0x1000>;
+				interconnects = <&system_noc MASTER_GNOC_SNOC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &config_noc SLAVE_IMEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+				power-domains = <&gcc HLOS1_VOTE_AGGRE_NOC_MMU_TBU1_GDSC>;
+				stream-id-range = <0x0 0x400>;
+			};
+
+			anoc_2_tbu: tbu at 150c9000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x150c9000 0x0 0x1000>;
+				interconnects = <&system_noc MASTER_GNOC_SNOC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &config_noc SLAVE_IMEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+				power-domains = <&gcc HLOS1_VOTE_AGGRE_NOC_MMU_TBU2_GDSC>;
+				stream-id-range = <0x400 0x400>;
+			};
+
+			mnoc_hf_0_tbu: tbu at 150cd000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x150cd000 0x0 0x1000>;
+				interconnects = <&mmss_noc MASTER_MDP0 QCOM_ICC_TAG_ACTIVE_ONLY
+						 &mmss_noc SLAVE_MNOC_HF_MEM_NOC QCOM_ICC_TAG_ACTIVE_ONLY>;
+				stream-id-range = <0x800 0x400>;
+			};
+
+			mnoc_hf_1_tbu: tbu at 150d1000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x150d1000 0x0 0x1000>;
+				interconnects = <&mmss_noc MASTER_MDP0 QCOM_ICC_TAG_ACTIVE_ONLY
+						 &mmss_noc SLAVE_MNOC_HF_MEM_NOC QCOM_ICC_TAG_ACTIVE_ONLY>;
+				stream-id-range = <0xc00 0x400>;
+			};
+
+			mnoc_sf_0_tbu: tbu at 150d5000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x150d5000 0x0 0x1000>;
+				interconnects = <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ACTIVE_ONLY
+						 &mmss_noc SLAVE_MNOC_SF_MEM_NOC QCOM_ICC_TAG_ACTIVE_ONLY>;
+				stream-id-range = <0x1000 0x400>;
+			};
+
+			compute_dsp_tbu: tbu at 150d9000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x150d9000 0x0 0x1000>;
+				interconnects = <&system_noc MASTER_GNOC_SNOC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &config_noc SLAVE_IMEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+				stream-id-range = <0x1400 0x400>;
+			};
+
+			adsp_tbu: tbu at 150dd000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x150dd000 0x0 0x1000>;
+				interconnects = <&system_noc MASTER_GNOC_SNOC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &config_noc SLAVE_IMEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+				power-domains = <&gcc HLOS1_VOTE_AGGRE_NOC_MMU_AUDIO_TBU_GDSC>;
+				stream-id-range = <0x1800 0x400>;
+			};
+
+			anoc_1_pcie_tbu: tbu at 150e1000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x150e1000 0x0 0x1000>;
+				clocks = <&gcc GCC_AGGRE_NOC_PCIE_TBU_CLK>;
+				interconnects = <&system_noc MASTER_GNOC_SNOC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &config_noc SLAVE_IMEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+				power-domains = <&gcc HLOS1_VOTE_AGGRE_NOC_MMU_PCIE_TBU_GDSC>;
+				stream-id-range = <0x1c00 0x400>;
+			};
 		};
 
 		lpasscc: clock-controller at 17014000 {


From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:27 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:27 -0800
Subject: [PATCH v3 0/9] Add support for Translation Buffer Units
Message-ID: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>

The TCUs (Translation Control Units) and TBUs (Translation Buffer
Units) are key components of the MMU-500. Multiple TBUs are connected
to a single TCU over an interconnect. Each TBU contains a TLB that
caches page tables. The MMU-500 implements a TBU for each connected
master, and the TBU is designed, so that it is local to the master.

The Qualcomm SDM845 and SC7280 platforms have an implementation of the
SMMU-500, that has multiple TBUs. A DT schema is added to describe the
resources for each TBU (register space, power-domains, interconnects
and clocks).

The TBU driver will manage the resources and allow the system to
operate the TBUs during a context fault to obtain details by doing
s1 inv, software + hardware page table walks etc. This is implemented
with ATOS/eCATs as the ATS feature is not supported. Being able to
query the TBUs is useful for debugging various hardware/software
issues on these platforms.

v3:
- Having a TBU is not Qualcomm specific, so allow having TBU child
  nodes with no specific constraints on properties. For some of the
  vendor compatibles however, add a schema to describe specific
  properties and allow validation. (Rob)
- Drop the useless reg-names DT property on TBUs. (Rob)
- Make the stream-id-range DT property a common one. (Rob)
- Fix the DT example. (Rob)
- Minor fixes on the TBU driver.
- Add support for SC7280 platforms.

v2: https://lore.kernel.org/r/20231118042730.2799-1-quic_c_gdjako at quicinc.com
- Improve DT binding description, add full example. (Konrad)
- Drop Qcom specific stuff from the generic binding. (Rob)
- Unconditionally try to populate subnodes. (Konrad)
- Improve TBU driver commit text, remove memory barriers. (Bjorn)
- Move TBU stuff into separate file. Make the driver builtin.
- TODO: Evaluate whether to keep TBU support as a separate driver
  or just instantiate things from qcom_smmu_impl_init()

v1: https://lore.kernel.org/r/20231019021923.13939-1-quic_c_gdjako at quicinc.com

Georgi Djakov (9):
  dt-bindings: iommu: Add Translation Buffer Unit bindings
  iommu/arm-smmu-qcom: Add support for TBUs
  iommu/arm-smmu-qcom-tbu: Add Qualcomm TBU driver
  iommu/arm-smmu: Allow using a threaded handler for context interrupts
  iommu/arm-smmu-qcom: Use a custom context fault handler for sdm845
  arm64: dts: qcom: sdm845: Add DT nodes for the TBUs
  dt-bindings: arm-smmu: Add TBU support for sc7280
  iommu/arm-smmu-qcom: Use the custom fault handler on more platforms
  arm64: dts: qcom: sc7280: Add DT nodes for the TBUs

 .../devicetree/bindings/iommu/arm,smmu.yaml   |  33 ++
 .../bindings/iommu/qcom,qsmmuv500-tbu.yaml    |  77 +++
 arch/arm64/boot/dts/qcom/sc7280.dtsi          |  97 ++++
 arch/arm64/boot/dts/qcom/sdm845.dtsi          |  74 +++
 drivers/iommu/Kconfig                         |   8 +
 drivers/iommu/arm/arm-smmu/Makefile           |   1 +
 .../iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c    | 504 ++++++++++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c    |  17 +
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h    |   6 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.c         |  12 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.h         |   3 +
 11 files changed, 829 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iommu/qcom,qsmmuv500-tbu.yaml
 create mode 100644 drivers/iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c



From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:28 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:28 -0800
Subject: [PATCH v3 1/9] dt-bindings: iommu: Add Translation Buffer Unit bindings
In-Reply-To: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
Message-ID: <20231220060236.18600-2-quic_c_gdjako@quicinc.com>

The "apps_smmu" on the Qualcomm sdm845 platform is an implementation
of the SMMU-500, that consists of a single TCU (Translation Control
Unit) and multiple TBUs (Translation Buffer Units). The TCU is already
being described in the generic SMMU DT schema. Add bindings for the
TBUs to describe their properties and resources that needs to be
managed in order to operate them.

In this DT schema, the TBUs are modelled as child devices of the TCU
and each of them is described with it's register space, clocks, power
domains, interconnects etc.

Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
---
 .../devicetree/bindings/iommu/arm,smmu.yaml   | 31 ++++++++
 .../bindings/iommu/qcom,qsmmuv500-tbu.yaml    | 77 +++++++++++++++++++
 2 files changed, 108 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/qcom,qsmmuv500-tbu.yaml

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index a4042ae24770..a610af2c7e5e 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -235,6 +235,27 @@ properties:
       enabled for any given device.
     $ref: /schemas/types.yaml#/definitions/phandle
 
+  '#address-cells':
+    enum: [ 1, 2 ]
+
+  '#size-cells':
+    enum: [ 1, 2 ]
+
+  ranges: true
+
+patternProperties:
+  "^tbu@[0-9a-f]+":
+    description: The TBU child node(s)
+    type: object
+
+    properties:
+      stream-id-range:
+        $ref: /schemas/types.yaml#/definitions/uint32-array
+        description: Stream ID range (address and size) that is assigned by the TBU
+        items:
+          minItems: 2
+          maxItems: 2
+
 required:
   - compatible
   - reg
@@ -312,6 +333,16 @@ allOf:
                     through the TCU's programming interface.
                 - description: bus clock required for the smmu ptw
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: qcom,sdm845-smmu-500
+    then:
+      patternProperties:
+        "^tbu@[0-9a-f]+":
+          $ref: qcom,qsmmuv500-tbu.yaml
+
   - if:
       properties:
         compatible:
diff --git a/Documentation/devicetree/bindings/iommu/qcom,qsmmuv500-tbu.yaml b/Documentation/devicetree/bindings/iommu/qcom,qsmmuv500-tbu.yaml
new file mode 100644
index 000000000000..c4f148ae5f38
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/qcom,qsmmuv500-tbu.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/qcom,qsmmuv500-tbu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm TBU (Translation Buffer Unit)
+
+maintainers:
+  - Georgi Djakov <quic_c_gdjako at quicinc.com>
+
+description:
+  The Qualcomm SMMU500 implementation consists of TCU and TBU. The TBU contains
+  a Translation Lookaside Buffer (TLB) that caches page tables. TBUs provides
+  debug features to trace and trigger debug transactions. There are multiple TBU
+  instances distributes with each client core.
+
+properties:
+
+  compatible:
+    const: qcom,qsmmuv500-tbu
+
+  reg:
+    items:
+      - description: Address and size of the TBU's register space.
+
+  clocks:
+    maxItems: 1
+
+  interconnects:
+    maxItems: 1
+
+  power-domains:
+    maxItems: 1
+
+  stream-id-range:
+    $ref: "arm,smmu.yaml#/patternProperties/^tbu@[0-9a-f]+/properties/stream-id-range"
+
+required:
+  - compatible
+  - reg
+  - stream-id-range
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+    #include <dt-bindings/interconnect/qcom,icc.h>
+    #include <dt-bindings/interconnect/qcom,sdm845.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/power/qcom-rpmpd.h>
+
+    apps_smmu: iommu at 15000000 {
+        compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
+        reg = <0x15000000 0x80000>;
+        ranges = <0 0 0 0 0xffffffff>;
+        #iommu-cells = <2>;
+        #global-interrupts = <1>;
+        interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>;
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        anoc_1_pcie_tbu: tbu at 150e1000 {
+            compatible = "qcom,qsmmuv500-tbu";
+            reg = <0x0 0x150e1000 0x0 0x1000>;
+            clocks = <&gcc GCC_AGGRE_NOC_PCIE_TBU_CLK>;
+            interconnects = <&system_noc MASTER_GNOC_SNOC QCOM_ICC_TAG_ACTIVE_ONLY
+                             &config_noc SLAVE_IMEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+            power-domains = <&gcc HLOS1_VOTE_AGGRE_NOC_MMU_PCIE_TBU_GDSC>;
+            stream-id-range = <0x1c00 0x400>;
+        };
+    };
+
+...


From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:32 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:32 -0800
Subject: [PATCH v3 5/9] iommu/arm-smmu-qcom: Use a custom context fault handler for sdm845
In-Reply-To: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
Message-ID: <20231220060236.18600-6-quic_c_gdjako@quicinc.com>

The sdm845 platform now supports TBUs, so let's get additional debug
info from the TBUs when a context fault occurs. Implement a custom
context fault handler that does both software + hardware page table
walks and TLB Invalidate All.

Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
---
 .../iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c    | 138 ++++++++++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c    |   4 +
 2 files changed, 142 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c
index 2ff00e06d3bf..cd70bb67a79a 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-tbu.c
@@ -52,6 +52,11 @@ static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
 	return container_of(smmu, struct qcom_smmu, smmu);
 }
 
+static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
+{
+	return container_of(dom, struct arm_smmu_domain, domain);
+}
+
 static struct qsmmuv500_tbu *qsmmuv500_find_tbu(struct qcom_smmu *qsmmu, u32 sid)
 {
 	struct qsmmuv500_tbu *tbu = NULL;
@@ -301,6 +306,139 @@ static phys_addr_t qsmmuv500_iova_to_phys(struct arm_smmu_domain *smmu_domain,
 	return phys;
 }
 
+static phys_addr_t qcom_smmu_iova_to_phys_hard(struct iommu_domain *domain, dma_addr_t iova)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	int idx = smmu_domain->cfg.cbndx;
+	u32 frsynra;
+	u16 sid;
+
+	frsynra = arm_smmu_gr1_read(smmu, ARM_SMMU_GR1_CBFRSYNRA(idx));
+	sid = FIELD_GET(ARM_SMMU_CBFRSYNRA_SID, frsynra);
+
+	return qsmmuv500_iova_to_phys(smmu_domain, iova, sid);
+}
+
+static phys_addr_t qcom_smmu_verify_fault(struct iommu_domain *domain, dma_addr_t iova, u32 fsr)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct io_pgtable *iop = io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	phys_addr_t phys_post_tlbiall;
+	phys_addr_t phys;
+
+	phys = qcom_smmu_iova_to_phys_hard(domain, iova);
+	io_pgtable_tlb_flush_all(iop);
+	phys_post_tlbiall = qcom_smmu_iova_to_phys_hard(domain, iova);
+
+	if (phys != phys_post_tlbiall) {
+		dev_err(smmu->dev,
+			"ATOS results differed across TLBIALL... (before: %pa after: %pa)\n",
+			&phys, &phys_post_tlbiall);
+	}
+
+	return (phys == 0 ? phys_post_tlbiall : phys);
+}
+
+irqreturn_t qcom_smmu_context_fault(int irq, void *dev)
+{
+	struct iommu_domain *domain = dev;
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	u32 fsr, fsynr, cbfrsynra, resume = 0;
+	int idx = smmu_domain->cfg.cbndx;
+	phys_addr_t phys_soft;
+	unsigned long iova;
+	int ret, tmp;
+
+	static DEFINE_RATELIMIT_STATE(_rs,
+				      DEFAULT_RATELIMIT_INTERVAL,
+				      DEFAULT_RATELIMIT_BURST);
+
+	fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
+	if (!(fsr & ARM_SMMU_FSR_FAULT))
+		return IRQ_NONE;
+
+	fsynr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSYNR0);
+	iova = arm_smmu_cb_readq(smmu, idx, ARM_SMMU_CB_FAR);
+	cbfrsynra = arm_smmu_gr1_read(smmu, ARM_SMMU_GR1_CBFRSYNRA(idx));
+
+	phys_soft = ops->iova_to_phys(ops, iova);
+
+	tmp = report_iommu_fault(domain, NULL, iova,
+				 fsynr & ARM_SMMU_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
+	if (!tmp || tmp == -EBUSY) {
+		dev_dbg(smmu->dev,
+			"Context fault handled by client: iova=0x%08lx, fsr=0x%x, fsynr=0x%x, cb=%d\n",
+			iova, fsr, fsynr, idx);
+		dev_dbg(smmu->dev, "soft iova-to-phys=%pa\n", &phys_soft);
+		ret = IRQ_HANDLED;
+		resume = ARM_SMMU_RESUME_TERMINATE;
+	} else {
+		phys_addr_t phys_atos = qcom_smmu_verify_fault(domain, iova, fsr);
+
+		if (__ratelimit(&_rs)) {
+			dev_err(smmu->dev,
+				"Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, cbfrsynra=0x%x, cb=%d\n",
+				fsr, iova, fsynr, cbfrsynra, idx);
+			dev_err(smmu->dev,
+				"FSR    = %08x [%s%s%s%s%s%s%s%s%s], SID=0x%x\n",
+				fsr,
+				(fsr & 0x02) ? "TF " : "",
+				(fsr & 0x04) ? "AFF " : "",
+				(fsr & 0x08) ? "PF " : "",
+				(fsr & 0x10) ? "EF " : "",
+				(fsr & 0x20) ? "TLBMCF " : "",
+				(fsr & 0x40) ? "TLBLKF " : "",
+				(fsr & 0x80) ? "MHF " : "",
+				(fsr & 0x40000000) ? "SS " : "",
+				(fsr & 0x80000000) ? "MULTI " : "",
+				cbfrsynra);
+
+			dev_err(smmu->dev,
+				"soft iova-to-phys=%pa\n", &phys_soft);
+			if (!phys_soft)
+				dev_err(smmu->dev,
+					"SOFTWARE TABLE WALK FAILED! Looks like %s accessed an unmapped address!\n",
+					dev_name(smmu->dev));
+			if (phys_atos)
+				dev_err(smmu->dev, "hard iova-to-phys (ATOS)=%pa\n",
+					&phys_atos);
+			else
+				dev_err(smmu->dev, "hard iova-to-phys (ATOS) failed\n");
+		}
+		ret = IRQ_NONE;
+		resume = ARM_SMMU_RESUME_TERMINATE;
+	}
+
+	/*
+	 * If the client returns -EBUSY, do not clear FSR and do not RESUME
+	 * if stalled. This is required to keep the IOMMU client stalled on
+	 * the outstanding fault. This gives the client a chance to take any
+	 * debug action and then terminate the stalled transaction.
+	 * So, the sequence in case of stall on fault should be:
+	 * 1) Do not clear FSR or write to RESUME here
+	 * 2) Client takes any debug action
+	 * 3) Client terminates the stalled transaction and resumes the IOMMU
+	 * 4) Client clears FSR. The FSR should only be cleared after 3) and
+	 *    not before so that the fault remains outstanding. This ensures
+	 *    SCTLR.HUPCF has the desired effect if subsequent transactions also
+	 *    need to be terminated.
+	 */
+	if (tmp != -EBUSY) {
+		/* Clear the faulting FSR */
+		arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_FSR, fsr);
+
+		/* Retry or terminate any stalled transactions */
+		if (fsr & ARM_SMMU_FSR_SS)
+			arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_RESUME, resume);
+	}
+
+	return ret;
+}
+
 static int qsmmuv500_tbu_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 581401d6c18a..6b41a0214db1 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -423,6 +423,10 @@ static const struct arm_smmu_impl sdm845_smmu_500_impl = {
 	.reset = qcom_sdm845_smmu500_reset,
 	.write_s2cr = qcom_smmu_write_s2cr,
 	.tlb_sync = qcom_smmu_tlb_sync,
+#ifdef CONFIG_ARM_SMMU_QCOM_TBU
+	.context_fault = qcom_smmu_context_fault,
+	.context_fault_needs_threaded_irq = true,
+#endif
 };
 
 static const struct arm_smmu_impl qcom_adreno_smmu_v2_impl = {


From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:35 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:35 -0800
Subject: [PATCH v3 8/9] iommu/arm-smmu-qcom: Use the custom fault handler on more platforms
In-Reply-To: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
Message-ID: <20231220060236.18600-9-quic_c_gdjako@quicinc.com>

The TBU support is now available, so let's allow it to be used on other
platforms that have the Qualcomm SMMU-500 implementation with TBUs. This
will allow the context fault handler to query the TBUs when a context
fault occurs.

Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 6b41a0214db1..fd72b69675a7 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -414,6 +414,10 @@ static const struct arm_smmu_impl qcom_smmu_500_impl = {
 	.reset = arm_mmu500_reset,
 	.write_s2cr = qcom_smmu_write_s2cr,
 	.tlb_sync = qcom_smmu_tlb_sync,
+#ifdef CONFIG_ARM_SMMU_QCOM_TBU
+	.context_fault = qcom_smmu_context_fault,
+	.context_fault_needs_threaded_irq = true,
+#endif
 };
 
 static const struct arm_smmu_impl sdm845_smmu_500_impl = {


From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:36 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:36 -0800
Subject: [PATCH v3 9/9] arm64: dts: qcom: sc7280: Add DT nodes for the TBUs
In-Reply-To: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
Message-ID: <20231220060236.18600-10-quic_c_gdjako@quicinc.com>

Add the device-tree nodes for the TBUs (translation buffer units) that
are present on the sc7280 platforms. The TBUs can be used debug the
kernel and provide additional information when a context faults occur.

Describe the all registers, clocks, interconnects and power-domain
resources that are needed for each of the TBUs.

Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
---
 arch/arm64/boot/dts/qcom/sc7280.dtsi | 97 ++++++++++++++++++++++++++++
 1 file changed, 97 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index ff1e07171dc4..d2cf171aa0e0 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2870,6 +2870,7 @@
 			compatible = "qcom,sc7280-smmu-500", "qcom,adreno-smmu",
 				     "qcom,smmu-500", "arm,mmu-500";
 			reg = <0 0x03da0000 0 0x20000>;
+			ranges;
 			#iommu-cells = <2>;
 			#global-interrupts = <2>;
 			interrupts = <GIC_SPI 673 IRQ_TYPE_LEVEL_HIGH>,
@@ -2902,6 +2903,21 @@
 
 			power-domains = <&gpucc GPU_CC_CX_GDSC>;
 			dma-coherent;
+
+			#address-cells = <2>;
+			#size-cells = <2>;
+
+			gfx_0_tbu: tbu at 3dd9000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x3dd9000 0x0 0x1000>;
+				stream-id-range = <0x0 0x400>;
+			};
+
+			gfx_1_tbu: tbu at 3ddd000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x3ddd000 0x0 0x1000>;
+				stream-id-range = <0x400 0x400>;
+			};
 		};
 
 		remoteproc_mpss: remoteproc at 4080000 {
@@ -5605,6 +5621,7 @@
 		apps_smmu: iommu at 15000000 {
 			compatible = "qcom,sc7280-smmu-500", "arm,mmu-500";
 			reg = <0 0x15000000 0 0x100000>;
+			ranges;
 			#iommu-cells = <2>;
 			#global-interrupts = <1>;
 			dma-coherent;
@@ -5689,6 +5706,86 @@
 				     <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>;
+
+			#address-cells = <2>;
+			#size-cells = <2>;
+
+			anoc_1_tbu: tbu at 151dd000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x151dd000 0x0 0x1000>;
+				interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &cnoc3 SLAVE_TCU QCOM_ICC_TAG_ACTIVE_ONLY>;
+				stream-id-range = <0x0 0x400>;
+			};
+
+			anoc_2_tbu: tbu at 151e1000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x151e1000 0x0 0x1000>;
+				interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &cnoc3 SLAVE_TCU QCOM_ICC_TAG_ACTIVE_ONLY>;
+				stream-id-range = <0x400 0x400>;
+			};
+
+			mnoc_hf_0_tbu: tbu at 151e5000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x151e5000 0x0 0x1000>;
+				interconnects = <&mmss_noc MASTER_MDP0 QCOM_ICC_TAG_ACTIVE_ONLY
+						 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
+				power-domains = <&gcc HLOS1_VOTE_MMNOC_MMU_TBU_HF0_GDSC>;
+				stream-id-range = <0x800 0x400>;
+			};
+
+			mnoc_hf_1_tbu: tbu at 151e9000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x151e9000 0x0 0x1000>;
+				interconnects = <&mmss_noc MASTER_MDP0 QCOM_ICC_TAG_ACTIVE_ONLY
+						 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
+				power-domains = <&gcc HLOS1_VOTE_MMNOC_MMU_TBU_HF1_GDSC>;
+				stream-id-range = <0xc00 0x400>;
+			};
+
+			compute_dsp_0_tbu: tbu at 151ed000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x151ed000 0x0 0x1000>;
+				interconnects = <&nsp_noc MASTER_CDSP_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
+				power-domains = <&gcc HLOS1_VOTE_TURING_MMU_TBU1_GDSC>;
+				stream-id-range = <0x1000 0x400>;
+			};
+
+			compute_dsp_1_tbu: tbu at 151f1000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x151f1000 0x0 0x1000>;
+				interconnects = <&nsp_noc MASTER_CDSP_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
+				power-domains = <&gcc HLOS1_VOTE_TURING_MMU_TBU0_GDSC>;
+				stream-id-range = <0x1400 0x400>;
+			};
+
+			adsp_tbu: tbu at 151f5000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x151f5000 0x0 0x1000>;
+				interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &lpass_ag_noc SLAVE_LPASS_CORE_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+				stream-id-range = <0x1800 0x400>;
+			};
+
+			anoc_1_pcie_tbu: tbu at 151f9000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x151f9000 0x0 0x1000>;
+				interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+						 &cnoc3 SLAVE_TCU QCOM_ICC_TAG_ACTIVE_ONLY>;
+				stream-id-range = <0x1c00 0x400>;
+			};
+
+			mnoc_sf_0_tbu: tbu at 151fd000 {
+				compatible = "qcom,qsmmuv500-tbu";
+				reg = <0x0 0x151fd000 0x0 0x1000>;
+				interconnects = <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ACTIVE_ONLY
+						 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
+				power-domains = <&gcc HLOS1_VOTE_MMNOC_MMU_TBU_SF0_GDSC>;
+				stream-id-range = <0x2000 0x400>;
+			};
 		};
 
 		intc: interrupt-controller at 17a00000 {


From quic_c_gdjako at quicinc.com  Tue Dec 19 22:02:34 2023
From: quic_c_gdjako at quicinc.com (Georgi Djakov)
Date: Tue, 19 Dec 2023 22:02:34 -0800
Subject: [PATCH v3 7/9] dt-bindings: arm-smmu: Add TBU support for sc7280
In-Reply-To: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
Message-ID: <20231220060236.18600-8-quic_c_gdjako@quicinc.com>

Add the sc7280 SMMU to the platforms that have TBUs. This will allow
to validate the DT files against the json schema.

Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
---
 Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index a610af2c7e5e..e983660a8f31 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -337,7 +337,9 @@ allOf:
       properties:
         compatible:
           contains:
-            const: qcom,sdm845-smmu-500
+            enum:
+              - qcom,sc7280-smmu-500
+              - qcom,sdm845-smmu-500
     then:
       patternProperties:
         "^tbu@[0-9a-f]+":


From muchun.song at linux.dev  Tue Dec 19 22:32:33 2023
From: muchun.song at linux.dev (Muchun Song)
Date: Wed, 20 Dec 2023 14:32:33 +0800
Subject: [PATCH v2 2/3] arm64: mm: HVO: support BBM of vmemmap pgtable
 safely
In-Reply-To: <20231220051855.47547-3-sunnanyong@huawei.com>
References: <20231220051855.47547-1-sunnanyong@huawei.com>
 <20231220051855.47547-3-sunnanyong@huawei.com>
Message-ID: <08DCC8BB-631C-4F7A-BB0A-494AD2AD3465@linux.dev>



> On Dec 20, 2023, at 13:18, Nanyong Sun <sunnanyong at huawei.com> wrote:
> 
> Implement vmemmap_update_pmd and vmemmap_update_pte on arm64 to do
> BBM(break-before-make) logic when change the page table of vmemmap
> address, they will under the init_mm.page_table_lock.
> If a translation fault of vmemmap address concurrently happened after
> pte/pmd cleared, vmemmap page fault handler will acquire the
> init_mm.page_table_lock to wait for vmemmap update to complete,
> by then the virtual address is valid again, so PF can return and
> access can continue.
> In other case, do the traditional kernel fault.
> 
> Implement vmemmap_flush_tlb_all/range on arm64 with nothing
> to do because tlb already flushed in every single BBM.
> 
> Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
> ---
> arch/arm64/include/asm/esr.h |  4 ++
> arch/arm64/include/asm/mmu.h | 20 +++++++++
> arch/arm64/mm/fault.c        | 78 ++++++++++++++++++++++++++++++++++--
> arch/arm64/mm/mmu.c          | 28 +++++++++++++
> 4 files changed, 127 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index ae35939f395b..1c63256efd25 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -116,6 +116,10 @@
> #define ESR_ELx_FSC_SERROR (0x11)
> #define ESR_ELx_FSC_ACCESS (0x08)
> #define ESR_ELx_FSC_FAULT (0x04)
> +#define ESR_ELx_FSC_FAULT_L0    (0x04)
> +#define ESR_ELx_FSC_FAULT_L1    (0x05)
> +#define ESR_ELx_FSC_FAULT_L2    (0x06)
> +#define ESR_ELx_FSC_FAULT_L3    (0x07)
> #define ESR_ELx_FSC_PERM (0x0C)
> #define ESR_ELx_FSC_SEA_TTW0 (0x14)
> #define ESR_ELx_FSC_SEA_TTW1 (0x15)
> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
> index 2fcf51231d6e..b553bc37c925 100644
> --- a/arch/arm64/include/asm/mmu.h
> +++ b/arch/arm64/include/asm/mmu.h
> @@ -76,5 +76,25 @@ extern bool kaslr_requires_kpti(void);
> #define INIT_MM_CONTEXT(name) \
> .pgd = init_pg_dir,
> 
> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
> +void vmemmap_update_pmd(unsigned long addr, pmd_t *pmdp, pte_t *ptep);
> +#define vmemmap_update_pmd vmemmap_update_pmd
> +void vmemmap_update_pte(unsigned long addr, pte_t *ptep, pte_t pte);
> +#define vmemmap_update_pte vmemmap_update_pte
> +
> +static inline void vmemmap_flush_tlb_all(void)
> +{
> + 	/* do nothing, already flushed tlb in every single BBM */
> +}
> +#define vmemmap_flush_tlb_all vmemmap_flush_tlb_all
> +
> +static inline void vmemmap_flush_tlb_range(unsigned long start,
> +   unsigned long end)
> +{
> + 	/* do nothing, already flushed tlb in every single BBM */
> +}
> +#define vmemmap_flush_tlb_range vmemmap_flush_tlb_range
> +#endif

I think those declaration related to TLB flushing should be moved
to arch/arm64/include/asm/tlbflush.h since we do not include
<asm/mmu.h> explicitly in hugetlb_vmemmap.c and its functionality
is to flush TLB. Luckily, <asm/tlbflush.h> is included by hugetlb_vmemmap.c.

Additionally, vmemmap_update_pmd/pte helpers should be moved to
arch/arm64/include/asm/pgtable.h since it is really pgtable related
operations.

Thanks.






From xiaobo55x at gmail.com  Tue Dec 19 22:50:03 2023
From: xiaobo55x at gmail.com (Haibo Xu)
Date: Wed, 20 Dec 2023 14:50:03 +0800
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us
 in arch timer test
In-Reply-To: <8734vy832j.wl-maz@kernel.org>
References: <cover.1702371136.git.haibo1.xu@intel.com> <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
 <8734vy832j.wl-maz@kernel.org>
Message-ID: <CAJve8onc0WN5g98aOVBmJx15wFBAqfBKJ+ufoLY+oqYyVL+=3A@mail.gmail.com>

On Wed, Dec 20, 2023 at 2:22?AM Marc Zyngier <maz at kernel.org> wrote:
>
> On Tue, 12 Dec 2023 09:31:20 +0000,
> Haibo Xu <haibo1.xu at intel.com> wrote:
> > > @@ -216,6 +221,9 @@ static bool parse_args(int argc, char *argv[])
> >               case 'm':
> >                       test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
> >                       break;
> > +             case 'e':
> > +                     test_args.timer_err_margin_us = atoi_non_negative("Error Margin", optarg);
> > +                     break;
>
> So your error margin is always unsigned...
>

The error margin was supposed to be a non-negative [0, INT_MAX].
(May be need to define a Max for the input, instead of INT_MAX)

> >               case 'o':
> >                       test_args.counter_offset = strtol(optarg, NULL, 0);
> >                       test_args.reserved = 0;
> > diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
> > index 968257b893a7..b1d405e7157d 100644
> > --- a/tools/testing/selftests/kvm/include/timer_test.h
> > +++ b/tools/testing/selftests/kvm/include/timer_test.h
> > @@ -22,6 +22,7 @@ struct test_args {
> >       int nr_iter;
> >       int timer_period_ms;
> >       int migration_freq_ms;
> > +     int timer_err_margin_us;
>
> ... except that you are storing it as a signed value. Some consistency
> wouldn't hurt, really, and would avoid issues when passing large
> values.
>

Yes, it's more proper to use an unsigned int for the non-negative error margin.
Storing as signed here is just to keep the type consistent with that
of timer_period_ms
since there will be '+' operation in other places.

        tools/testing/selftests/kvm/aarch64/arch_timer.c
        /* Setup a timeout for the interrupt to arrive */
         udelay(msecs_to_usecs(test_args.timer_period_ms) +
             test_args.timer_err_margin_us);

Thanks,
Haibo

>         M.
>
> --
> Without deviation from the norm, progress is not possible.


From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:06:27 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:06:27 +0100
Subject: [PATCH 2/3] dt-bindings: media: mediatek-mdp: Change the
 description of gce-events
In-Reply-To: <20231218083604.7327-3-jason-jh.lin@mediatek.com>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
 <20231218083604.7327-3-jason-jh.lin@mediatek.com>
Message-ID: <e645a032-67d7-4669-9487-585635a1702e@linaro.org>

On 18/12/2023 09:36, Jason-JH.Lin wrote:
> Change the description of mediatek,gce-events property to reference
> mediatek,gce-mailbox.yaml.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  .../devicetree/bindings/media/mediatek,mdp3-rdma.yaml        | 5 +----
>  .../devicetree/bindings/media/mediatek,mdp3-rsz.yaml         | 5 +----
>  .../devicetree/bindings/media/mediatek,mdp3-wrot.yaml        | 5 +----
>  3 files changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> index 7032c7e15039..adb3df4731f6 100644
> --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> @@ -40,10 +40,7 @@ properties:
>  
>    mediatek,gce-events:
>      description:
> -      The event id which is mapping to the specific hardware event signal
> -      to gce. The event id is defined in the gce header
> -      include/dt-bindings/gce/<chip>-gce.h of each chips.
> -    $ref: /schemas/types.yaml#/definitions/uint32-array
> +      Reference to Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml.

There is no reference here. You allow now any type. This does not make
any sense.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:07:33 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:07:33 +0100
Subject: [PATCH 1/3] dt-bindings: mailbox: mediatek,gce-mailbox: Add
 mediatek,gce-events definition
In-Reply-To: <20231218083604.7327-2-jason-jh.lin@mediatek.com>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
 <20231218083604.7327-2-jason-jh.lin@mediatek.com>
Message-ID: <cafae4ec-337a-4134-8545-d86c4c61c858@linaro.org>

On 18/12/2023 09:36, Jason-JH.Lin wrote:
> Since mediatek,gce-events property is a HW event signal from GCE,
> it should be defined in mediatek,gce-mailbox.yaml and change the

Why? None of the bindings reference it. Did you just move property from
one device to completely different one?

> description of mediatek,gce-events property in other bindings to
> reference mediatek,gce-mailbox.yaml.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  .../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml  | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
> index cef9d7601398..e4da0a58c943 100644
> --- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
> @@ -49,6 +49,13 @@ properties:
>      items:
>        - const: gce
>  
> +  mediatek,gce-events:
> +    description:
> +      The event id which is mapping to the specific hardware event signal
> +      to gce. The event id is defined in the gce header
> +      include/dt-bindings/gce/<chip>-gce.h of each chips.
> +    $ref: /schemas/types.yaml#/definitions/uint32-array

Where are the constraints?

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:08:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:08:07 +0100
Subject: [PATCH 3/3] dt-bindings: soc: mediatek: Change the description of
 gce-events
In-Reply-To: <20231218083604.7327-4-jason-jh.lin@mediatek.com>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
 <20231218083604.7327-4-jason-jh.lin@mediatek.com>
Message-ID: <d18350c3-5730-45df-aa5f-3aae7f8f7e10@linaro.org>

On 18/12/2023 09:36, Jason-JH.Lin wrote:
> Change the description of mediatek,gce-events property to reference
> mediatek,gce-mailbox yaml.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  .../devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml     | 5 +----
>  .../devicetree/bindings/soc/mediatek/mediatek,mutex.yaml     | 5 +----
>  .../devicetree/bindings/soc/mediatek/mediatek,wdma.yaml      | 5 +----
>  3 files changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
> index 4380b98b0dfe..64c0f99fcbce 100644
> --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
> @@ -36,10 +36,7 @@ properties:
>  
>    mediatek,gce-events:
>      description:
> -      The event id which is mapping to the specific hardware event signal
> -      to gce. The event id is defined in the gce header
> -      include/dt-bindings/gce/<chip>-gce.h of each chips.
> -    $ref: /schemas/types.yaml#/definitions/uint32-array
> +      Reference to Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml.

NAK, test your bindings. You allow now any type.


Best regards,
Krzysztof



From frank at oltmanns.dev  Tue Dec 19 22:58:07 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Wed, 20 Dec 2023 07:58:07 +0100
Subject: [PATCH 1/5] clk: sunxi-ng: nkm: Support constraints on m/n
 ratio and parent rate
In-Reply-To: <5736273.DvuYhMxLoT@jernej-laptop>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-1-e238b6ed6dc1@oltmanns.dev>
 <5736273.DvuYhMxLoT@jernej-laptop>
Message-ID: <87msu59wrc.fsf@oltmanns.dev>

Hi Jernej!

On 2023-12-19 at 17:46:08 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> Hi Frank!
>
> Dne ponedeljek, 18. december 2023 ob 14:35:19 CET je Frank Oltmanns napisal(a):
>> The Allwinner A64 manual lists the following constraints for the
>> PLL-MIPI clock:
>>  - M/N >= 3
>
> This should be "<="

Yes, good catch! I will fix it in V2.

>
>>  - (PLL_VIDEO0)/M >= 24MHz
>>
>> The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
>> these constraints.
>>
>> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
>> ---
>>  drivers/clk/sunxi-ng/ccu_nkm.c | 23 +++++++++++++++++++++++
>>  drivers/clk/sunxi-ng/ccu_nkm.h |  8 ++++++++
>>  2 files changed, 31 insertions(+)
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
>> index eed64547ad42..2af5c1ebd527 100644
>> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
>> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
>> @@ -16,6 +16,20 @@ struct _ccu_nkm {
>>  	unsigned long	m, min_m, max_m;
>>  };
>>
>> +static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long parent,
>> +				  unsigned long n, unsigned long m)
>> +{
>> +	struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
>> +
>> +	if (nkm->max_mn_ratio && (m > nkm->max_mn_ratio * n))
>> +		return false;
>> +
>> +	if (nkm->parent_wo_nk && (parent < nkm->parent_wo_nk * m))
>> +		return false;
>> +
>> +	return true;
>> +}
>> +
>>  static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common,
>>  						       struct clk_hw *parent_hw,
>>  						       unsigned long *parent, unsigned long rate,
>> @@ -32,6 +46,9 @@ static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
>>
>>  				tmp_parent = clk_hw_round_rate(parent_hw, rate * _m / (_n * _k));
>>
>> +				if (!ccu_nkm_is_valid_rate(common, tmp_parent, _n, _m))
>> +					continue;
>> +
>>  				tmp_rate = tmp_parent * _n * _k / _m;
>>
>>  				if (ccu_is_better_rate(common, rate, tmp_rate, best_rate) ||
>> @@ -65,6 +82,12 @@ static unsigned long ccu_nkm_find_best(unsigned long parent, unsigned long rate,
>>  	for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
>>  		for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
>>  			for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
>> +				if ((common->reg == 0x040) && (_m > 3 * _n))
>> +					break;
>> +
>> +				if ((common->reg == 0x040) && (parent < 24000000 * _m))
>> +					continue;
>> +
>
> You already figured this part.
>
>>  				unsigned long tmp_rate;
>>
>>  				tmp_rate = parent * _n * _k / _m;
>> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
>> index 6601defb3f38..d3d3eaf55faf 100644
>> --- a/drivers/clk/sunxi-ng/ccu_nkm.h
>> +++ b/drivers/clk/sunxi-ng/ccu_nkm.h
>> @@ -16,6 +16,12 @@
>>   * struct ccu_nkm - Definition of an N-K-M clock
>>   *
>>   * Clocks based on the formula parent * N * K / M
>> + *
>> + * @max_mn_ratio:	Maximum value for M / N.
>> + * @parent_wo_nk:	The minimum rate the parent must provide after applying the divisor,
>> + *			but without applying the multipliers, i.e. the contstraint
>> + *			   (parent rate)/M >= parent_wo_nk
>> + *			must be fulfilled.
>>   */
>>  struct ccu_nkm {
>>  	u32			enable;
>> @@ -27,6 +33,8 @@ struct ccu_nkm {
>>  	struct ccu_mux_internal	mux;
>>
>>  	unsigned int		fixed_post_div;
>> +	unsigned long		max_mn_ratio;
>> +	unsigned long           parent_wo_nk;
>
> What about max_m_n_ratio and max_parent_m_ratio, to be consistent? This
> should also allow to simplify description.

Jernej, thank you so much! This is brilliant! I was racking my brain for
a good name but failed. Now, that I see your proposal, I don't know why
I hadn't come up with it. It's the obvious choice.

I'd say with the new names we should be able to get rid of the comments
describing the new struct members (also in ccu_nm.h). What are your
thoughts on that?

Best regards,
  Frank

>
> Best regards,
> Jernej
>
>>
>>  	struct ccu_common	common;
>>  };
>>
>>


From fuyao1697 at cyg.com  Tue Dec 19 23:08:40 2023
From: fuyao1697 at cyg.com (fuyao)
Date: Wed, 20 Dec 2023 15:08:40 +0800
Subject: [PATCH RESEND] iio: adc: sun4i-gpadc-iio: adaptation interrupt number
In-Reply-To: <YxmR5SPPY18O7LaG@google.com>
Message-ID: <YwdhTlk+7h+FMrwm@scg>

__platform_get_irq_byname determinies whether the interrupt
number is 0 and returns EINVAL.

Signed-off-by: fuyao <fuyao1697 at cyg.com>
Acked-by:  Jernej Skrabec <jernej.skrabec at gmail.com>
---
 include/linux/mfd/sun4i-gpadc.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
index ea0ccf33a459..021f820f9d52 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h
@@ -81,8 +81,8 @@
 #define SUN4I_GPADC_TEMP_DATA				0x20
 #define SUN4I_GPADC_DATA				0x24
 
-#define SUN4I_GPADC_IRQ_FIFO_DATA			0
-#define SUN4I_GPADC_IRQ_TEMP_DATA			1
+#define SUN4I_GPADC_IRQ_FIFO_DATA			1
+#define SUN4I_GPADC_IRQ_TEMP_DATA			2
 
 /* 10s delay before suspending the IP */
 #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
-- 
2.32.0


-- 
Technology is exciting

>From mboxrd at z Thu Jan  1 00:00:00 1970
Return-Path: <linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org at lists.infradead.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id D7BEFC04AA5
	for <linux-arm-kernel at archiver.kernel.org>; Thu, 25 Aug 2022 11:54:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=lists.infradead.org; s=bombadil.20210309; h=Sender:
	Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:
	List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Subject:Cc:To:
	From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:
	Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:
	List-Owner; bh=43HWo/ZUnCasly+ZDH2iZ6YziJoEl7DGgRHVq1AWHGA=; b=N4HqsZY4E2SL6r
	coTCsOX2hRzQ7B0a1T00J2VkAPl7AipXosk76WMzyfIWnLKRkW8uqqBXKpQ2sHn25CKHP+ZW5UpiD
	6l25/vh+YIPuTKjxd22dXb3QWpmIObDbHRRIOZSAWMBva+k42rsgsfgRyYKOI/+fBRoqDqFZHrjV1
	LbiROW7b0SqMq6vAWAjGQvRON+qQDsqqpadEY+j508ViyVZdDIB2TY1zdy6uTAc4QqMRmzUH2NP7W
	eSzjr4Kd1dtJMmykNtjjlIm/7IPwpXbHb72IdX1lzo27891mjNCP6V6fToGXw+s5RFS1qHaRuZ+XB
	8g9p7pCDPqH/9eUb74/g==;
Received: from localhost ([::1] helo=bombadil.infradead.org)
	by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux))
	id 1oRBPm-00D1Ka-Ur; Thu, 25 Aug 2022 11:52:51 +0000
Received: from out20-123.mail.aliyun.com ([115.124.20.123])
	by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux))
	id 1oRBPk-00D1FB-2p
	for linux-arm-kernel at lists.infradead.org; Thu, 25 Aug 2022 11:52:49 +0000
X-Alimail-AntiSpam: AC=CONTINUE;BC=0.3045855|-1;BR=01201311R131S89rulernew998_84748_2000303;CH=blue;DM=|CONTINUE|false|;DS=CONTINUE|ham_system_inform|0.025949-0.00105542-0.972996;FP=0|0|0|0|0|-1|-1|-1;HT=ay29a033018047190;MF=fuyao at sjterm.com;NM=1;PH=DS;RN=9;RT=9;SR=0;TI=SMTPD_---.P.m81RD_1661428046;
Received: from localhost(mailfrom:fuyao at sjterm.com fp:SMTPD_---.P.m81RD_1661428046)
          by smtp.aliyun-inc.com;
          Thu, 25 Aug 2022 19:47:26 +0800
Date: Thu, 25 Aug 2022 19:47:26 +0800
From: fuyao <fuyao1697 at cyg.com>
To: Lee Jones <lee at kernel.org>, Chen-Yu Tsai <wens at csie.org>,
	Jernej Skrabec <jernej.skrabec at gmail.com>,
	Samuel Holland <samuel at sholland.org>,
	linux-arm-kernel at lists.infradead.org, linux-sunxi at lists.linux.dev,
	linux-kernel at vger.kernel.org
Cc: Maxime Ripard <mripard at kernel.org>,
	maijianzhang <maijianzhang at allwinnertech.com>
Subject: [PATCH] iio: adc: sun4i-gpadc-iio: adaptation interrupt number
Message-ID: <YwdhTlk+7h+FMrwm at scg>
Mail-Followup-To: Lee Jones <lee at kernel.org>, Chen-Yu Tsai <wens at csie.org>,
	Jernej Skrabec <jernej.skrabec at gmail.com>,
	Samuel Holland <samuel at sholland.org>,
	linux-arm-kernel at lists.infradead.org, linux-sunxi at lists.linux.dev,
	linux-kernel at vger.kernel.org, Maxime Ripard <mripard at kernel.org>,
	maijianzhang <maijianzhang at allwinnertech.com>
MIME-Version: 1.0
Content-Disposition: inline
Organization: work_work_work
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
X-CRM114-CacheID: sfid-20220825_045248_320501_10DAB7D1 
X-CRM114-Status: UNSURE (   9.15  )
X-CRM114-Notice: Please train this message.
X-BeenThere: linux-arm-kernel at lists.infradead.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: <linux-arm-kernel.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-arm-kernel>,
 <mailto:linux-arm-kernel-request at lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/>
List-Post: <mailto:linux-arm-kernel at lists.infradead.org>
List-Help: <mailto:linux-arm-kernel-request at lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>,
 <mailto:linux-arm-kernel-request at lists.infradead.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-arm-kernel" <linux-arm-kernel-bounces at lists.infradead.org>
Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org at lists.infradead.org

__platform_get_irq_byname determinies whether the interrupt
number is 0 and returns EINVAL.

Signed-off-by: fuyao <fuyao1697 at cyg.com>
---
 include/linux/mfd/sun4i-gpadc.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
index ea0ccf33a459..021f820f9d52 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h
@@ -81,8 +81,8 @@
 #define SUN4I_GPADC_TEMP_DATA				0x20
 #define SUN4I_GPADC_DATA				0x24
 
-#define SUN4I_GPADC_IRQ_FIFO_DATA			0
-#define SUN4I_GPADC_IRQ_TEMP_DATA			1
+#define SUN4I_GPADC_IRQ_FIFO_DATA			1
+#define SUN4I_GPADC_IRQ_TEMP_DATA			2
 
 /* 10s delay before suspending the IP */
 #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
-- 
2.32.0


-- 
Technology is exciting

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
CYG Technology.


From peter.wang at mediatek.com  Tue Dec 19 23:03:10 2023
From: peter.wang at mediatek.com (=?utf-8?B?UGV0ZXIgV2FuZyAo546L5L+h5Y+LKQ==?=)
Date: Wed, 20 Dec 2023 07:03:10 +0000
Subject: [PATCH] ufs: mcq: Adding a function for MCQ enable
In-Reply-To: <20231220052737.19857-1-cw9316.lee@samsung.com>
References: <CGME20231220052749epcas1p3b90f6c03110ff5f63ffc547ef0f35907@epcas1p3.samsung.com>
	 <20231220052737.19857-1-cw9316.lee@samsung.com>
Message-ID: <dad07aaadcb7f6f7597ba171c35598008e69b58c.camel@mediatek.com>

On Wed, 2023-12-20 at 14:27 +0900, Chanwoo Lee wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  From: ChanWoo Lee <cw9316.lee at samsung.com>
> 
> The REG_UFS_MEM_CFG register is too general(broad)
> and it is difficult to know the meaning of only values of 0x1 and
> 0x2.
> So far, comments were required.
> 
> Therefore, I have added new functions and defines
> to improve code readability/reusability.
> 
> Signed-off-by: ChanWoo Lee <cw9316.lee at samsung.com>
> ---
>  drivers/ufs/core/ufs-mcq.c      | 10 +++++++++-
>  drivers/ufs/core/ufshcd.c       |  5 +----
>  drivers/ufs/host/ufs-mediatek.c |  4 +---
>  include/ufs/ufshcd.h            |  1 +
>  include/ufs/ufshci.h            |  4 ++++
>  5 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-mcq.c
> index 0787456c2b89..a34ef3aac540 100644
> --- a/drivers/ufs/core/ufs-mcq.c
> +++ b/drivers/ufs/core/ufs-mcq.c
> @@ -394,11 +394,19 @@
> EXPORT_SYMBOL_GPL(ufshcd_mcq_make_queues_operational);
>  
>  void ufshcd_mcq_enable_esi(struct ufs_hba *hba)
>  {
> -ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x2,
> +ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | ESI_ENABLE,
>        REG_UFS_MEM_CFG);
>  }
>  EXPORT_SYMBOL_GPL(ufshcd_mcq_enable_esi);
>  
> +void ufshcd_mcq_enable(struct ufs_hba *hba)
> +{
> +ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) |
> MCQ_MODE_SELECT,
> +      REG_UFS_MEM_CFG);
> +hba->mcq_enabled = true;
> +}
> +EXPORT_SYMBOL_GPL(ufshcd_mcq_enable);
> +
>  void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg *msg)
>  {
>  ufshcd_writel(hba, msg->address_lo, REG_UFS_ESILBA);
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index ae9936fc6ffb..8195e01e7a3f 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -8723,10 +8723,7 @@ static void ufshcd_config_mcq(struct ufs_hba
> *hba)
>  hba->host->can_queue = hba->nutrs - UFSHCD_NUM_RESERVED;
>  hba->reserved_slot = hba->nutrs - UFSHCD_NUM_RESERVED;
>  
> -/* Select MCQ mode */
> -ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
> -      REG_UFS_MEM_CFG);
> -hba->mcq_enabled = true;
> +ufshcd_mcq_enable(hba);
>  
>  dev_info(hba->dev, "MCQ configured, nr_queues=%d, io_queues=%d,
> read_queue=%d, poll_queues=%d, queue_depth=%d\n",
>   hba->nr_hw_queues, hba->nr_queues[HCTX_TYPE_DEFAULT],
> diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-
> mediatek.c
> index fc61790d289b..1048add66419 100644
> --- a/drivers/ufs/host/ufs-mediatek.c
> +++ b/drivers/ufs/host/ufs-mediatek.c
> @@ -1219,9 +1219,7 @@ static int ufs_mtk_link_set_hpm(struct ufs_hba
> *hba)
>  ufs_mtk_config_mcq(hba, false);
>  ufshcd_mcq_make_queues_operational(hba);
>  ufshcd_mcq_config_mac(hba, hba->nutrs);
> -/* Enable MCQ mode */
> -ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
> -      REG_UFS_MEM_CFG);
> +ufshcd_mcq_enable(hba);

Hi Chanwoo,

It is better change 0x1 to MCQ_MODE_SELECT only.
And do not change hba->mcq_enabled value because we enable mcq 
by check hba->mcq_enabled is true.

Thanks.
Peter



>  }
>  
>  if (err)
> diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
> index d862c8ddce03..a96c45fa4b4b 100644
> --- a/include/ufs/ufshcd.h
> +++ b/include/ufs/ufshcd.h
> @@ -1257,6 +1257,7 @@ unsigned long ufshcd_mcq_poll_cqe_lock(struct
> ufs_hba *hba,
>   struct ufs_hw_queue *hwq);
>  void ufshcd_mcq_make_queues_operational(struct ufs_hba *hba);
>  void ufshcd_mcq_enable_esi(struct ufs_hba *hba);
> +void ufshcd_mcq_enable(struct ufs_hba *hba);
>  void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg
> *msg);
>  
>  int ufshcd_opp_config_clks(struct device *dev, struct opp_table
> *opp_table,
> diff --git a/include/ufs/ufshci.h b/include/ufs/ufshci.h
> index d5accacae6bc..e669fad11fd4 100644
> --- a/include/ufs/ufshci.h
> +++ b/include/ufs/ufshci.h
> @@ -282,6 +282,10 @@ enum {
>  /* UTMRLRSR - UTP Task Management Request Run-Stop Register 80h */
>  #define UTP_TASK_REQ_LIST_RUN_STOP_BIT0x1
>  
> +/* REG_UFS_MEM_CFG - Global Config Registers 300h */
> +#define MCQ_MODE_SELECT 0x1
> +#define ESI_ENABLE0x2
> +
>  /* CQISy - CQ y Interrupt Status Register  */
>  #define UFSHCD_MCQ_CQIS_TAIL_ENT_PUSH_STS0x1
>  
> -- 
> 2.29.0
> 

From frank at oltmanns.dev  Tue Dec 19 23:09:28 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Wed, 20 Dec 2023 08:09:28 +0100
Subject: [PATCH 4/5] clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's
 n/m ratio
In-Reply-To: <13411739.uLZWGnKmhe@jernej-laptop>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-4-e238b6ed6dc1@oltmanns.dev>
 <13411739.uLZWGnKmhe@jernej-laptop>
Message-ID: <87il4t9wi1.fsf@oltmanns.dev>


On 2023-12-19 at 17:54:19 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> Dne ponedeljek, 18. december 2023 ob 14:35:22 CET je Frank Oltmanns napisal(a):
>> The Allwinner A64 manual lists the following constraint for the
>> PLL-VIDEO0 clock: 8 <= N/M <= 25
>>
>> Use this constraint.
>>
>> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
>> ---
>>  drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> index c034ac027d1c..75d839da446c 100644
>> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> @@ -68,7 +68,8 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
>>  				       BIT(28),	/* lock */
>>  				       CLK_SET_RATE_UNGATE);
>>
>> -static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-video0",
>> +static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(pll_video0_clk,
>> +						"pll-video0",
>>  						"osc24M", 0x010,
>>  						192000000,	/* Minimum rate */
>>  						1008000000,	/* Maximum rate */
>> @@ -80,7 +81,10 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-vid
>>  						297000000,	/* frac rate 1 */
>>  						BIT(31),	/* gate */
>>  						BIT(28),	/* lock */
>> -						CLK_SET_RATE_UNGATE);
>> +						CLK_SET_RATE_UNGATE,
>> +						CCU_FEATURE_FRACTIONAL |
>> +						CCU_FEATURE_CLOSEST_RATE,
>
> Above flags are unrelated change, put them in new patch if needed.

You might notice that I am using a new macro for initializing the
pll_video0_clk struct:
New: SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO
Old: SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST

Setting the two CCU_FEATURE flags is part of the old initialization
macro.

I'll add SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_NM_RATIO_CLOSEST which
hopefully resolves the confusion.

Thanks,
  Frank

>
> Best regards,
> Jernej
>
>> +						8, 25);		/* min/max nm ratio */
>>
>>  static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
>>  					"osc24M", 0x018,
>>
>>


From tj at kernel.org  Tue Dec 19 23:14:59 2023
From: tj at kernel.org (Tejun Heo)
Date: Tue, 19 Dec 2023 21:14:59 -1000
Subject: Performance drop due to alloc_workqueue() misuse and recent
 change
In-Reply-To: <dbu6wiwu3sdhmhikb2w6lns7b27gbobfavhjj57kwi2quafgwl@htjcc5oikcr3>
References: <dbu6wiwu3sdhmhikb2w6lns7b27gbobfavhjj57kwi2quafgwl@htjcc5oikcr3>
Message-ID: <ZYKUc7MUGvre2lGQ@slm.duckdns.org>

Hello, again.

On Mon, Dec 04, 2023 at 04:03:47PM +0000, Naohiro Aota wrote:
...
> In summary, we misuse max_active, considering it is a global limit. And,
> the recent commit introduced a huge performance drop in some cases.  We
> need to review alloc_workqueue() usage to check if its max_active setting
> is proper or not.

Can you please test the following branch?

 https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git unbound-system-wide-max_active

Thanks.

-- 
tejun


From fuyao1697 at cyg.com  Tue Dec 19 23:15:52 2023
From: fuyao1697 at cyg.com (fuyao)
Date: Wed, 20 Dec 2023 15:15:52 +0800
Subject: [PATCH RESEND] iio: adc: sun4i-gpadc-iio: adaptation interrupt number
In-Reply-To: <YxmR5SPPY18O7LaG@google.com>
Message-ID: <YwdhTlk+8h+FMrwm@scg>

__platform_get_irq_byname determinies whether the interrupt
number is 0 and returns EINVAL.

Signed-off-by: fuyao <fuyao1697 at cyg.com>
Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
---
 include/linux/mfd/sun4i-gpadc.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
index ea0ccf33a459..021f820f9d52 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h
@@ -81,8 +81,8 @@
 #define SUN4I_GPADC_TEMP_DATA				0x20
 #define SUN4I_GPADC_DATA				0x24
 
-#define SUN4I_GPADC_IRQ_FIFO_DATA			0
-#define SUN4I_GPADC_IRQ_TEMP_DATA			1
+#define SUN4I_GPADC_IRQ_FIFO_DATA			1
+#define SUN4I_GPADC_IRQ_TEMP_DATA			2
 
 /* 10s delay before suspending the IP */
 #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
-- 
2.32.0


-- 
CYG Technology

>From mboxrd at z Thu Jan  1 00:00:00 1970
Return-Path: <linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org at lists.infradead.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.lore.kernel.org (Postfix) with ESMTPS id D7BEFC04AA5
	for <linux-arm-kernel at archiver.kernel.org>; Thu, 25 Aug 2022 11:54:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=lists.infradead.org; s=bombadil.20210309; h=Sender:
	Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:
	List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Subject:Cc:To:
	From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:
	Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:
	List-Owner; bh=43HWo/ZUnCasly+ZDH2iZ6YziJoEl7DGgRHVq1AWHGA=; b=N4HqsZY4E2SL6r
	coTCsOX2hRzQ7B0a1T00J2VkAPl7AipXosk76WMzyfIWnLKRkW8uqqBXKpQ2sHn25CKHP+ZW5UpiD
	6l25/vh+YIPuTKjxd22dXb3QWpmIObDbHRRIOZSAWMBva+k42rsgsfgRyYKOI/+fBRoqDqFZHrjV1
	LbiROW7b0SqMq6vAWAjGQvRON+qQDsqqpadEY+j508ViyVZdDIB2TY1zdy6uTAc4QqMRmzUH2NP7W
	eSzjr4Kd1dtJMmykNtjjlIm/7IPwpXbHb72IdX1lzo27891mjNCP6V6fToGXw+s5RFS1qHaRuZ+XB
	8g9p7pCDPqH/9eUb74/g==;
Received: from localhost ([::1] helo=bombadil.infradead.org)
	by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux))
	id 1oRBPm-00D1Ka-Ur; Thu, 25 Aug 2022 11:52:51 +0000
Received: from out20-123.mail.aliyun.com ([115.124.20.123])
	by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux))
	id 1oRBPk-00D1FB-2p
	for linux-arm-kernel at lists.infradead.org; Thu, 25 Aug 2022 11:52:49 +0000
X-Alimail-AntiSpam: AC=CONTINUE;BC=0.3045855|-1;BR=01201311R131S89rulernew998_84748_2000303;CH=blue;DM=|CONTINUE|false|;DS=CONTINUE|ham_system_inform|0.025949-0.00105542-0.972996;FP=0|0|0|0|0|-1|-1|-1;HT=ay29a033018047190;MF=fuyao at sjterm.com;NM=1;PH=DS;RN=9;RT=9;SR=0;TI=SMTPD_---.P.m81RD_1661428046;
Received: from localhost(mailfrom:fuyao at sjterm.com fp:SMTPD_---.P.m81RD_1661428046)
          by smtp.aliyun-inc.com;
          Thu, 25 Aug 2022 19:47:26 +0800
Date: Thu, 25 Aug 2022 19:47:26 +0800
From: fuyao <fuyao1697 at cyg.com>
To: Lee Jones <lee at kernel.org>, Chen-Yu Tsai <wens at csie.org>,
	Jernej Skrabec <jernej.skrabec at gmail.com>,
	Samuel Holland <samuel at sholland.org>,
	linux-arm-kernel at lists.infradead.org, linux-sunxi at lists.linux.dev,
	linux-kernel at vger.kernel.org
Cc: Maxime Ripard <mripard at kernel.org>,
	maijianzhang <maijianzhang at allwinnertech.com>
Subject: [PATCH] iio: adc: sun4i-gpadc-iio: adaptation interrupt number
Message-ID: <YwdhTlk+7h+FMrwm at scg>
Mail-Followup-To: Lee Jones <lee at kernel.org>, Chen-Yu Tsai <wens at csie.org>,
	Jernej Skrabec <jernej.skrabec at gmail.com>,
	Samuel Holland <samuel at sholland.org>,
	linux-arm-kernel at lists.infradead.org, linux-sunxi at lists.linux.dev,
	linux-kernel at vger.kernel.org, Maxime Ripard <mripard at kernel.org>,
	maijianzhang <maijianzhang at allwinnertech.com>
MIME-Version: 1.0
Content-Disposition: inline
Organization: work_work_work
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
X-CRM114-CacheID: sfid-20220825_045248_320501_10DAB7D1 
X-CRM114-Status: UNSURE (   9.15  )
X-CRM114-Notice: Please train this message.
X-BeenThere: linux-arm-kernel at lists.infradead.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: <linux-arm-kernel.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-arm-kernel>,
 <mailto:linux-arm-kernel-request at lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/>
List-Post: <mailto:linux-arm-kernel at lists.infradead.org>
List-Help: <mailto:linux-arm-kernel-request at lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>,
 <mailto:linux-arm-kernel-request at lists.infradead.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-arm-kernel" <linux-arm-kernel-bounces at lists.infradead.org>
Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org at lists.infradead.org

__platform_get_irq_byname determinies whether the interrupt
number is 0 and returns EINVAL.

Signed-off-by: fuyao <fuyao1697 at cyg.com>
---
 include/linux/mfd/sun4i-gpadc.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
index ea0ccf33a459..021f820f9d52 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h
@@ -81,8 +81,8 @@
 #define SUN4I_GPADC_TEMP_DATA				0x20
 #define SUN4I_GPADC_DATA				0x24
 
-#define SUN4I_GPADC_IRQ_FIFO_DATA			0
-#define SUN4I_GPADC_IRQ_TEMP_DATA			1
+#define SUN4I_GPADC_IRQ_FIFO_DATA			1
+#define SUN4I_GPADC_IRQ_TEMP_DATA			2
 
 /* 10s delay before suspending the IP */
 #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
-- 
2.32.0


-- 
Technology is exciting

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
CYG Technology.


From miquel.raynal at bootlin.com  Tue Dec 19 23:17:17 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Wed, 20 Dec 2023 08:17:17 +0100
Subject: [PATCH V2 3/5] nvmem: u-boot-env: use more nvmem subsystem
 helpers
In-Reply-To: <1b5d4c36-9963-476c-8edf-e807beceda80@gmail.com>
References: <20231219174025.15228-1-zajec5@gmail.com>
	<20231219174025.15228-3-zajec5@gmail.com>
	<2023121929-salami-pessimist-c943@gregkh>
	<1b5d4c36-9963-476c-8edf-e807beceda80@gmail.com>
Message-ID: <20231220081717.0afc17f3@xps-13>

Hi Rafa?,

zajec5 at gmail.com wrote on Tue, 19 Dec 2023 19:16:37 +0100:

> On 19.12.2023 19:13, Greg Kroah-Hartman wrote:
> > On Tue, Dec 19, 2023 at 06:40:23PM +0100, Rafa? Mi?ecki wrote:  
> >> From: Rafa? Mi?ecki <rafal at milecki.pl>
> >>
> >> 1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
> >>     mtd dependent
> >> 2. Use nvmem_add_one_cell() to simplify adding NVMEM cells  
> > 
> > Shouldn't this be 2 different patches?  
> 
> I used to maintainers complaining my patches are too small and not the
> other way ;) I think it happened two or three times with mtd subsys.

A single patch may be too small if it's alone and we don't see the big
picture, otherwise I have no issue with small patches, do I? Anyway, in
this case I don't mind the patch being split or kept like this, just
keep my R-by applied to both if you do indeed split.

Thanks,
Miqu?l


From miquel.raynal at bootlin.com  Tue Dec 19 23:19:24 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Wed, 20 Dec 2023 08:19:24 +0100
Subject: [PATCH V2 4/5] nvmem: u-boot-env: improve coding style
In-Reply-To: <20231219174025.15228-4-zajec5@gmail.com>
References: <20231219174025.15228-1-zajec5@gmail.com>
	<20231219174025.15228-4-zajec5@gmail.com>
Message-ID: <20231220081924.39b96ec4@xps-13>

Hi Rafa?,

zajec5 at gmail.com wrote on Tue, 19 Dec 2023 18:40:24 +0100:

> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> 1. Prefer kzalloc() over kcalloc()
>    See memory-allocation.rst which says: "to be on the safe side it's
>    best to use routines that set memory to zero, like kzalloc()"
> 2. Drop dev_err() for u_boot_env_add_cells() fail
>    It can fail only on -ENOMEM. We don't want to print error then.
> 3. Add extra "crc32_addr" variable
>    It makes code reading header's crc32 easier to understand / review.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

Looks much nicer :)

Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>

Thanks,
Miqu?l


From jagan at amarulasolutions.com  Tue Dec 19 23:19:30 2023
From: jagan at amarulasolutions.com (Jagan Teki)
Date: Wed, 20 Dec 2023 12:49:30 +0530
Subject: PHY issue with SJA1105Q/DP84849I Design
Message-ID: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>

Hi,

We have encountered the PHY issue on 6.1 LTS with SJA1105Q Switch
connected to DP84849I PHY. DP84849I PHY supports dual ethernet ports
so we configure the DT to connect two ports from the switch to PHY and
one port to CPU (FEC in i.MX6DL).

&ecspi2 {
       cs-gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
       pinctrl-names = "default";
       pinctrl-0 = <&pinctrl_ecspi2>;
       status = "okay";

      switch at 0 {
          compatible = "nxp,sja1105q";
          reg = <0>;
          spi-max-frequency = <4000000>;
          spi-rx-delay-us = <1>;
          spi-tx-delay-us = <1>;
          spi-cpha;

          clocks = <&clk25m>;

          pinctrl-0 = <&pinctrl_sja1105_rst>;
          pinctrl-names = "default";
          reset-gpios = <&gpio6 5 GPIO_ACTIVE_LOW>;

          ports {
                #address-cells = <1>;
                #size-cells = <0>;

                port at 0 {
                        reg = <0>;
                        label = "ethphy0";
                        phy-handle = <&ethphy0>;
                        phy-mode = "mii";
                };

                port at 1 {
                       reg = <1>;
                       label = "ethphy1";
                       phy-handle = <&ethphy1>;
                       phy-mode = "mii";
                };

                port at 2 {
                      reg = <2>;
                      status = "disabled";
                };

                port at 3 {
                      reg = <3>;
                      status = "disabled";
               };

               port at 4 {
                      reg = <4>;
                      label = "cpu";
                      ethernet = <&fec>;
                      phy-mode = "mii";
                      rx-internal-delay-ps = <2000>;
                      tx-internal-delay-ps = <2000>;

                      fixed-link {
                          speed = <100>;
                          full-duplex;
                     };
              };
        };
     };
};

&fec {
          pinctrl-names = "default";
          pinctrl-0 = <&pinctrl_enet>;
          phy-mode = "mii";
          status = "okay";

          mdio {
             #address-cells = <1>;
             #size-cells = <0>;

            ethphy0: ethernet-phy at 0 {
                      compatible = "ethernet-phy-ieee802.3-c22";
                      reg = <0>;
            };

            ethphy1: ethernet-phy at 1 {
                    compatible = "ethernet-phy-ieee802.3-c22";
                    reg = <1>;
           };
        };
};

Since DP84849I shares the same register spec as DP83848, I have used
the DP83848 driver with the below PHY_ID change

diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c
index c38d33fd3706..c2c82ce5bb41 100644
--- a/drivers/net/phy/dp83848.c
+++ b/drivers/net/phy/dp83848.c
@@ -8,6 +8,7 @@
 #include <linux/module.h>
 #include <linux/phy.h>

+#define TI_DP83849I_PHY_ID             0x20005ca2
 #define TI_DP83848C_PHY_ID             0x20005ca0
 #define TI_DP83620_PHY_ID              0x20005ce0
 #define NS_DP83848C_PHY_ID             0x20005c90
@@ -173,6 +174,8 @@ MODULE_DEVICE_TABLE(mdio, dp83848_tbl);
        }

 static struct phy_driver dp83848_driver[] = {
+       DP83848_PHY_DRIVER(TI_DP83849I_PHY_ID, "TI DP83849I 10/100 Mbps PHY",
+                          NULL),
        DP83848_PHY_DRIVER(TI_DP83848C_PHY_ID, "TI DP83848C 10/100 Mbps PHY",
                           NULL),
        DP83848_PHY_DRIVER(NS_DP83848C_PHY_ID, "NS DP83848C 10/100 Mbps PHY",

The Switch and dual-phy seem detecting as expected but when we try to
bring up the link the PHY0 says NOLINK as mentioned, below.

root at limx6solo:~# dmesg | grep sja
[   23.765086] sja1105 spi1.0: spi_imx_setup: mode 1, 8 bpw, 4000000 hz
[   23.765164] sja1105 spi1.0: setup mode 1, 8 bits/w, 4000000 Hz max --> 0
[   23.766160] sja1105 spi1.0: Probed switch chip: SJA1105Q
[   24.037103] sja1105 spi1.0: configuring for fixed/mii link mode
[   24.119891] sja1105 spi1.0 ethphy0 (uninitialized): PHY
[2188000.ethernet-1:00] driver [TI DP83849I 10/100 Mbps PHY]
(irq=POLL)
[   24.279129] sja1105 spi1.0 ethphy1 (uninitialized): PHY
[2188000.ethernet-1:01] driver [TI DP83849I 10/100 Mbps PHY]
(irq=POLL)
[   26.406998] sja1105 spi1.0: Link is Up - 100Mbps/Full - flow control off

root at imx6solo:~# cat /usr/phy.sh
#!/bin/sh

echo ======= MDIO: PHY0 ========
mdio 2188000.ethernet-1 phy 0 raw 0x0
mdio 2188000.ethernet-1 phy 0 raw 0x1
mdio 2188000.ethernet-1 phy 0 raw 0x2
mdio 2188000.ethernet-1 phy 0 raw 0x3
mdio 2188000.ethernet-1 phy 0 raw 0x4
mdio 2188000.ethernet-1 phy 0 raw 0x5
mdio 2188000.ethernet-1 phy 0 raw 0x6
mdio 2188000.ethernet-1 phy 0 raw 0x7
mdio 2188000.ethernet-1 phy 0 raw 0x10
mdio 2188000.ethernet-1 phy 0 raw 0x19

echo ======= MDIO: PHY1 ========
mdio 2188000.ethernet-1 phy 1 raw 0x0
mdio 2188000.ethernet-1 phy 1 raw 0x1
mdio 2188000.ethernet-1 phy 1 raw 0x2
mdio 2188000.ethernet-1 phy 1 raw 0x3
mdio 2188000.ethernet-1 phy 1 raw 0x4
mdio 2188000.ethernet-1 phy 1 raw 0x5
mdio 2188000.ethernet-1 phy 1 raw 0x6
mdio 2188000.ethernet-1 phy 1 raw 0x7
mdio 2188000.ethernet-1 phy 1 raw 0x10
mdio 2188000.ethernet-1 phy 1 raw 0x19

ip link set dev eth0 down
ip link set dev ethphy0 down
ip link set dev ethphy1 down

ip link set dev ethphy0 address 00:11:22:33:44:55
ip link set dev ethphy1 address 00:11:22:33:44:66

ip addr add dev ethphy0 169.254.178.1/16
ip addr add dev ethphy1 169.253.178.2/16

ip link set dev eth0 up
ip link set dev ethphy0 up
ip link set dev ethphy1 up

echo ########## MDIO: PHY0 ###########
mdio 2188000.ethernet-1 phy 0 raw 0x0
mdio 2188000.ethernet-1 phy 0 raw 0x1
mdio 2188000.ethernet-1 phy 0 raw 0x2
mdio 2188000.ethernet-1 phy 0 raw 0x3
mdio 2188000.ethernet-1 phy 0 raw 0x4
mdio 2188000.ethernet-1 phy 0 raw 0x5
mdio 2188000.ethernet-1 phy 0 raw 0x6
mdio 2188000.ethernet-1 phy 0 raw 0x7
mdio 2188000.ethernet-1 phy 0 raw 0x10
mdio 2188000.ethernet-1 phy 0 raw 0x19

echo ########## MDIO: PHY1 ###########
mdio 2188000.ethernet-1 phy 1 raw 0x0
mdio 2188000.ethernet-1 phy 1 raw 0x1
mdio 2188000.ethernet-1 phy 1 raw 0x2
mdio 2188000.ethernet-1 phy 1 raw 0x3
mdio 2188000.ethernet-1 phy 1 raw 0x4
mdio 2188000.ethernet-1 phy 1 raw 0x5
mdio 2188000.ethernet-1 phy 1 raw 0x6
mdio 2188000.ethernet-1 phy 1 raw 0x7
mdio 2188000.ethernet-1 phy 1 raw 0x10
mdio 2188000.ethernet-1 phy 1 raw 0x19


root at ltts-imx6solo:~# bash /usr/phy.sh
======= MDIO: PHY0 ========
0x0: 0x3900
0x1: 0x7849
0x2: 0x2000
0x3: 0x5ca2
0x4: 0x01e1
0x5: 0x45e1
0x6: 0x0006
0x7: 0x2001
0x10: 0x0000
0x19: 0x8020
======= MDIO: PHY1 ========
0x0: 0x3100
0x1: 0x786d
0x2: 0x2000
0x3: 0x5ca2
0x4: 0x01e1
0x5: 0x45e1
0x6: 0x0007
0x7: 0x2801
0x10: 0x0015
0x19: 0x8021

ip link set dev eth0 down
ip link set dev ethphy0 down
ip link set dev ethphy1 down

ip link set dev ethphy0 address 00:11:22:33:44:55
ip link set dev ethphy1 address 00:11:22:33:44:66
ip link set dev eth0 up
ip link set dev ethphy0 up
ip link set dev ethphy1 up
[ 1254.929229] TI DP83849I 10/100 Mbps PHY 2188000.ethernet-1:00:
attached PHY driver (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
[ 1254.993819] sja1105 spi1.0 ethphy0: configuring for phy/mii link mode
[ 1255.005027] ------------[ cut here ]------------
[ 1255.009962] WARNING: CPU: 0 PID: 374 at drivers/net/phy/phy.c:1157
phy_start+0x58/0xb4
[ 1255.018062] called from state NOLINK
[ 1255.021656] Modules linked in: mdio_netlink(O) bnep tag_sja1105
sja1105 pcs_xpcs brcmfmac brcmutil imx_sdma coda_vpu v4l2_jpeg
imx_vdoa evbug
[ 1255.034578] CPU: 0 PID: 374 Comm: ip Tainted: G           O       6.1.58 #1
[ 1255.041560] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 1255.048103]  unwind_backtrace from show_stack+0x10/0x14
[ 1255.053361]  show_stack from dump_stack_lvl+0x58/0x70
[ 1255.058441]  dump_stack_lvl from __warn+0x70/0x1a4
[ 1255.063258]  __warn from warn_slowpath_fmt+0x1bc/0x270
[ 1255.068416]  warn_slowpath_fmt from phy_start+0x58/0xb4
[ 1255.073662]  phy_start from dsa_port_enable_rt+0x54/0x9c
[ 1255.079000]  dsa_port_enable_rt from dsa_slave_open+0xb8/0x17c
[ 1255.084860]  dsa_slave_open from __dev_open+0xec/0x1ac
[ 1255.090024]  __dev_open from __dev_change_flags+0x18c/0x224
[ 1255.095613]  __dev_change_flags from dev_change_flags+0x14/0x44
[ 1255.101549]  dev_change_flags from do_setlink+0x254/0xe4c
[ 1255.106974]  do_setlink from rtnl_newlink+0x598/0x80c
[ 1255.112048]  rtnl_newlink from rtnetlink_rcv_msg+0x168/0x574
[ 1255.117722]  rtnetlink_rcv_msg from netlink_rcv_skb+0xb8/0x11c
[ 1255.123572]  netlink_rcv_skb from netlink_unicast+0x1a8/0x2dc
[ 1255.129343]  netlink_unicast from netlink_sendmsg+0x1d8/0x450
[ 1255.135117]  netlink_sendmsg from ____sys_sendmsg+0x188/0x258
[ 1255.140891]  ____sys_sendmsg from ___sys_sendmsg+0x6c/0xa4
[ 1255.146397]  ___sys_sendmsg from sys_sendmsg+0x50/0x98
[ 1255.151556]  sys_sendmsg from ret_fast_syscall+0x0/0x1c
[ 1255.156801] Exception stack(0xf10c9fa8 to 0xf10c9ff0)
[ 1255.161867] 9fa0:                   00000000 00000001 00000003
beef2730 00000000 00000000
[ 1255.170057] 9fc0: 00000000 00000001 b6f9e5a0 00000128 626adc51
00000000 004d1cc0 004d1cc0
[ 1255.178244] 9fe0: 00000128 beef26d0 b6e9f6d3 b6e11ae6
[ 1255.183469] irq event stamp: 3345
[ 1255.186852] hardirqs last  enabled at (3355): [<c0195dbc>]
__up_console_sem+0x50/0x60
[ 1255.194715] hardirqs last disabled at (3362): [<c0195da8>]
__up_console_sem+0x3c/0x60
[ 1255.202628] softirqs last  enabled at (3344): [<c01017d0>]
__do_softirq+0x2c0/0x57c
[ 1255.210365] softirqs last disabled at (3325): [<c012f204>]
__irq_exit_rcu+0x138/0x17c
[ 1255.218281] ---[ end trace 0000000000000000 ]---
[ 1255.293759] sja1105 spi1.0 ethphy1: configuring for phy/mii link mode

0x3100
0x7849
0x2000
0x5ca2
0x05e1
0x0000
0x0004
0x2001
0x0000
0x8020

0x3100
0x7849
0x2000
0x5ca2
0x0141
0x0000
0x0005
0x2801
0x0000
0x8021
root at ltts-imx6solo:~# [ 1257.045875] fec 2188000.ethernet eth0: Link
is Up - 100Mbps/Full - flow control rx/tx
[ 1257.054008] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1257.365971] sja1105 spi1.0 ethphy1: Link is Up - 100Mbps/Full -
flow control off
[ 1257.373455] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy1: link becomes ready

root at ltts-imx6solo:~# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1504
        inet6 fe80::7c4c:1aff:fe5e:cbf0  prefixlen 64  scopeid 0x20<link>
        ether 7e:4c:1a:5e:cb:f0  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethphy0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 169.254.178.1  netmask 255.255.0.0  broadcast 0.0.0.0
        ether 00:11:22:33:44:55  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethphy1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.253.178.2  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 fe80::211:22ff:fe33:4466  prefixlen 64  scopeid 0x20<link>
        ether 00:11:22:33:44:66  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 32  bytes 4211 (4.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 91  bytes 7801 (7.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 91  bytes 7801 (7.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

sit0: flags=128<NOARP>  mtu 1480
        unspec 00-00-00-00-31-00-00-4A-00-00-00-00-00-00-00-00
txqueuelen 1000  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether c0:ee:40:82:2f:fc  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root at ltts-imx6solo:~# mdio 2188000.ethernet-1
 DEV      PHY-ID  LINK
0x00  0x20005ca2  up
0x01  0x20005ca2  up

--
Jagan Teki,
Amarula Solutions India Pvt. Ltd.
Co-Founder & Embedded Linux Architect
405/E-Block, Sri Lakshmi Shubham Arcade, Chandanagar, Hyderabad - 500050, India
M. (+91) 910 009 0959
[`as] http://www.amarulasolutions.com


From fuyao1697 at cyg.com  Tue Dec 19 23:23:17 2023
From: fuyao1697 at cyg.com (fuyao)
Date: Wed, 20 Dec 2023 15:23:17 +0800
Subject: [PATCH RESEND] iio: adc: sun4i-gpadc-iio: adaptation interrupt number
In-Reply-To: <YxmR5SPPY18O7LaG@google.com>
Message-ID: <YwdhTlk+9h+9Mrwm@scg>

__platform_get_irq_byname determinies whether the interrupt
number is 0 and returns EINVAL.

Signed-off-by: fuyao <fuyao1697 at cyg.com>
Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
---
 include/linux/mfd/sun4i-gpadc.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
index ea0ccf33a459..021f820f9d52 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h
@@ -81,8 +81,8 @@
 #define SUN4I_GPADC_TEMP_DATA				0x20
 #define SUN4I_GPADC_DATA				0x24
 
-#define SUN4I_GPADC_IRQ_FIFO_DATA			0
-#define SUN4I_GPADC_IRQ_TEMP_DATA			1
+#define SUN4I_GPADC_IRQ_FIFO_DATA			1
+#define SUN4I_GPADC_IRQ_TEMP_DATA			2
 
 /* 10s delay before suspending the IP */
 #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
-- 
2.32.0



From gregkh at linuxfoundation.org  Tue Dec 19 23:24:17 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 20 Dec 2023 08:24:17 +0100
Subject: [PATCH] [ARM] locomo: make locomo_bus_type constant and static
In-Reply-To: <amnspbf2euablvmtl2bpng423cnkbjkvtsf7dhqmoyrzbgtpwb@3rgazgmuqjcx>
References: <2023121905-idiom-opossum-1ba3@gregkh>
 <amnspbf2euablvmtl2bpng423cnkbjkvtsf7dhqmoyrzbgtpwb@3rgazgmuqjcx>
Message-ID: <2023122020-tastiness-counting-788f@gregkh>

On Tue, Dec 19, 2023 at 10:21:20PM +0100, Uwe Kleine-K?nig wrote:
> On Tue, Dec 19, 2023 at 07:33:06PM +0100, Greg Kroah-Hartman wrote:
> > Now that the driver core can properly handle constant struct bus_type,
> > move the locomo_bus_type variable to be a constant structure as well,
> > placing it into read-only memory which can not be modified at runtime.
> > 
> > It's also never used outside of arch/arm/common/locomo.c so make it
> > static and don't export it as no one is using it.
> > 
> > Cc: Russell King <linux at armlinux.org.uk>
> > Cc: Arnd Bergmann <arnd at arndb.de>
> > Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
> > Cc: Randy Dunlap <rdunlap at infradead.org>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> > ---
> >  arch/arm/common/locomo.c               | 4 +++-
> >  arch/arm/include/asm/hardware/locomo.h | 2 --
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
> > index 70480dd9e96d..6d0c9f7268ba 100644
> > --- a/arch/arm/common/locomo.c
> > +++ b/arch/arm/common/locomo.c
> > @@ -68,6 +68,8 @@ struct locomo {
> >  #endif
> >  };
> >  
> > +static const struct bus_type locomo_bus_type;
> > +
> 
> If you move up locomo_bus_type together with its three callbacks before
> locomo_init_one_child, you don't need the extra declaration here.

I was trying to go for "least intrusive and most obvious change
possible" here, given that this file hasn't been touched in over a
decade by anyone else for anything other than api changes.  And even
then, it was just a tiny fix, this is a very old driver, what's the odds
that it's even used anymore?

thanks,

greg k-h


From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:24:33 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:24:33 +0100
Subject: [EXT] Re: [PATCH v2 3/5] dt-bindings: usb: ci-hdrc-usb2: add
 compatible and clock-names restriction for imx93
In-Reply-To: <DB7PR04MB5146154E6C62BCFCDA7879F38C96A@DB7PR04MB5146.eurprd04.prod.outlook.com>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com>
 <20231218085456.3962720-3-xu.yang_2@nxp.com>
 <eb93c554-ee35-49a0-adfb-0d3030f9a77b@linaro.org>
 <DB7PR04MB5146154E6C62BCFCDA7879F38C96A@DB7PR04MB5146.eurprd04.prod.outlook.com>
Message-ID: <e3ca4b8e-7e5b-4e0d-963d-e020729cab6c@linaro.org>

On 20/12/2023 03:23, Xu Yang wrote:
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            const: fsl,imx93-usb
>>> +    then:
>>> +      properties:
>>> +        clock-names:
>>> +          items:
>>> +            - const: usb_ctrl_root_clk
>>> +            - const: usb_wakeup_clk
>>
>> What about all the reset? reg, interrupts? Maybe it is time to split the
>> schema into common part and device-specific.
> 
> Why I need to consider reset, reg and interrupts? Should I add restrictions on
> these too? I may not really understand your meaning.

I looked at the binding and it seems that you allow different number of
items for them. Why aren't these constrained for your device?

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:25:16 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:25:16 +0100
Subject: [PATCH v2 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <2f38caeb95fe9b2d01f158fd91ed0cedafa5d2fa.camel@mediatek.com>
References: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
 <d50abf1a-1ee7-4f84-9f53-69dfe9aad103@linaro.org>
 <2f38caeb95fe9b2d01f158fd91ed0cedafa5d2fa.camel@mediatek.com>
Message-ID: <1050b195-9ac2-4c63-88b0-d8ba3299d334@linaro.org>

On 20/12/2023 03:05, Chunfeng Yun (???) wrote:
> On Fri, 2023-12-15 at 08:36 +0100, Krzysztof Kozlowski wrote:
>>  	 
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>>  On 15/12/2023 08:34, Chunfeng Yun wrote:
>>> For Gen1 isoc-in endpoint on controller before about SSUSB IPM
>> v1.6.0, it
>>> still send out unexpected ACK after receiving a short packet in
>> burst
>>> transfer, this will cause an exception on connected device,
>> specially for
>>> a 4k camera.
>>> Add a quirk property "rx-fifo-depth" to work around this hardware
>> issue,
>>> prefer to use 2;
>>> The side-effect is that may cause performance drop about 10%,
>> including
>>> bulk transfer.
>>>
>>> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
>>> ---
>>> v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
>>> ---
>>>  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12
>> ++++++++++++
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-
>> xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-
>> xhci.yaml
>>> index e9644e333d78..e44a71acb5c0 100644
>>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>>> @@ -124,6 +124,18 @@ properties:
>>>        defined in the xHCI spec on MTK's controller.
>>>      default: 5000
>>>  
>>> +  rx-fifo-depth:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description:
>>> +      It is a quirk used to work around Gen1 isoc-in endpoint
>> transfer issue
>>> +      that still send out unexpected ACK after device finish the
>> burst transfer
>>> +      with a short packet and cause an exception, specially on a
>> 4K camera
>>> +      device, it happens on controller before about IPM v1.6.0;
>> the side-effect
>>> +      is that may cause performance drop about 10%, include bulk
>> transfer,
>>> +      prefer to use 2 here.
>>
>> What is the meaning of 0-3? bytes? words?
> 0 - 1K bytes;
> 3 - 4K bytes;
> I will add this in description

No, don't add. Just use correct values. 0 means 0 words or bytes. Not
1000 bytes.

Best regards,
Krzysztof



From miquel.raynal at bootlin.com  Tue Dec 19 23:27:36 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Wed, 20 Dec 2023 08:27:36 +0100
Subject: [PATCH V2 5/5] nvmem: layouts: add U-Boot env layout
In-Reply-To: <20231219174025.15228-5-zajec5@gmail.com>
References: <20231219174025.15228-1-zajec5@gmail.com>
	<20231219174025.15228-5-zajec5@gmail.com>
Message-ID: <20231220082736.246e947c@xps-13>

Hi Rafa?,

zajec5 at gmail.com wrote on Tue, 19 Dec 2023 18:40:25 +0100:

> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> This patch moves all generic (NVMEM devices independent) code from NVMEM

Nit: In general we avoid starting with "This patch does..." and instead
use the imperative form, like: "Move all generic code..."

> device driver to NVMEM layout driver. Then it adds a simple NVMEM layout

					Then add...

> code on top of it.
> 
> Thanks to proper layout it's possible to support U-Boot env data stored
> on any kind of NVMEM device.
> 
> For backward compatibility with old DT bindings we need to keep old
> NVMEM device driver functional. To avoid code duplication a parsing
> function is exported and reused in it.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> ---
> V2: Support new compatibles & use device_get_match_data() helper
> 
> IMPORTANT:
> This is based on top of the:
> [PATCH v6.8 1/2] nvmem: layouts: refactor .add_cells() callback arguments

Thanks for the move. Looks good to me:

Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>

Thanks,
Miqu?l


From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:30:30 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:30:30 +0100
Subject: [PATCH v2 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <59dd1baa-ef5b-415a-a803-a2dbc3d405b2@arm.com>
References: <cover.1702571292.git.robin.murphy@arm.com>
 <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
 <8f583a00-8e9c-4875-936c-ed196d1dae56@linaro.org>
 <2b8414e5-61d5-4c3e-9613-6d9487ae84a8@arm.com>
 <4c78e6f2-d6fb-4da7-9c54-ca6a686f2b58@linaro.org>
 <59dd1baa-ef5b-415a-a803-a2dbc3d405b2@arm.com>
Message-ID: <13753b13-9bb0-469b-8fff-38f42ce50d82@linaro.org>

On 19/12/2023 15:24, Robin Murphy wrote:
> On 2023-12-18 7:03 am, Krzysztof Kozlowski wrote:
>> On 15/12/2023 19:39, Robin Murphy wrote:
>>>>> +required:
>>>>> +  - compatible
>>>>> +  - reg
>>>>> +
>>>>> +additionalProperties: false
>>>>
>>>> Why no example to validate the binding?
>>>
>>> IMO for such a trivial binding built out of common properties, an
>>> equally trivial example isn't going to add any value, since it won't do
>>> anything more than re-state the individual property definitions above.
>>> In bindings where we have conditional relationships between properties,
>>> or complex encodings where a practical example can help explain a
>>> definition (e.g. a map/mask pair for a set of input values), then
>>> absolutely, an example can add something more to help the author and/or
>>> users. But otherwise, the thing I've really grown to like about schema
>>> is how thoroughly self-describing the definitions themselves can now be.
>>
>> The example is used to validate the schema.
> 
> Can you clarify what that *means*, though? As far as I can tell from a 
> bit of experimentation, "make dt_bindings_check" picks up errors in the 
> schema definition itself just the same whether an example is present or 
> not. Thus I still fail to understand what else would be validated by me 
> writing an example here, other than my personal ability to comprehend my 
> own binding.

You miss here the part that the actual binding is used to verify the
example used. This is something entirely different than validating
schema against meta-schema.

> 
> Yes, I'm well aware that back when we were bootstrapping dtschema it was 
> useful to confirm that schemas were written to correctly describe 
> *existing* known-good DT fragments. However with new bindings like this 
> we've already reached the end goal, where we write an authoritative 
> schema first, then the users follow from there. As I alluded to above, 
> there are reasons why I would actually prefer *not* to provide a usage 
> example here - frankly if a user doesn't understand which parts of the 
> architecture their hardware implements, and/or can't figure out how to 
> copy a single compatible string and write a standard reg property, I 
> would much rather they come to me asking how to write a DT entry, than 
> blindly copy-paste a verbatim example into their DTS, then come to me 
> reporting a "bug" with the driver crashing or failing to probe. I'd love 
> to say I have no experience to base that judgement on, but...

Sure, considering the size of the binding the benefits of the example
here are rather low.

Best regards,
Krzysztof



From quic_snehshah at quicinc.com  Tue Dec 19 23:32:45 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Wed, 20 Dec 2023 13:02:45 +0530
Subject: [PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support for
 2.5G SGMII
In-Reply-To: <4zbf5fmijxnajk7kygcjrcusf6tdnuzsqqboh23nr6f3rb3c4g@qkfofhq7jmv6>
References: <20231218071118.21879-1-quic_snehshah@quicinc.com>
 <4zbf5fmijxnajk7kygcjrcusf6tdnuzsqqboh23nr6f3rb3c4g@qkfofhq7jmv6>
Message-ID: <8b80ab09-8444-4c3d-83b0-c7dbf5e58658@quicinc.com>



On 12/18/2023 9:50 PM, Andrew Halaney wrote:
> On Mon, Dec 18, 2023 at 12:41:18PM +0530, Sneh Shah wrote:
>> Serdes phy needs to operate at 2500 mode for 2.5G speed and 1000
>> mode for 1G/100M/10M speed.
>> Added changes to configure serdes phy and mac based on link speed.
>>
>> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
>> ---
>>  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 31 +++++++++++++++++--
>>  1 file changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>> index d3bf42d0fceb..b3a28dc19161 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>> @@ -21,6 +21,7 @@
>>  #define RGMII_IO_MACRO_CONFIG2		0x1C
>>  #define RGMII_IO_MACRO_DEBUG1		0x20
>>  #define EMAC_SYSTEM_LOW_POWER_DEBUG	0x28
>> +#define ETHQOS_MAC_AN_CTRL		0xE0
>>  
>>  /* RGMII_IO_MACRO_CONFIG fields */
>>  #define RGMII_CONFIG_FUNC_CLK_EN		BIT(30)
>> @@ -78,6 +79,10 @@
>>  #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
>>  #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
>>  
>> +/*ETHQOS_MAC_AN_CTRL bits */
>> +#define ETHQOS_MAC_AN_CTRL_RAN			BIT(9)
>> +#define ETHQOS_MAC_AN_CTRL_ANE			BIT(12)
>> +
> 
> nit: space please add a space before ETHQOS_MAC_AN_CTRL
> 
will take care of this in next patch

>>  struct ethqos_emac_por {
>>  	unsigned int offset;
>>  	unsigned int value;
>> @@ -109,6 +114,7 @@ struct qcom_ethqos {
>>  	unsigned int num_por;
>>  	bool rgmii_config_loopback_en;
>>  	bool has_emac_ge_3;
>> +	unsigned int serdes_speed;
>>  };
>>  
>>  static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
>> @@ -600,27 +606,47 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>>  
>>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>>  {
>> -	int val;
>> -
>> +	int val, mac_an_value;
>>  	val = readl(ethqos->mac_base + MAC_CTRL_REG);
>> +	mac_an_value = readl(ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
>>  
>>  	switch (ethqos->speed) {
>> +	case SPEED_2500:
>> +		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
>> +		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>> +			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>> +			      RGMII_IO_MACRO_CONFIG2);
>> +		if (ethqos->serdes_speed != SPEED_2500)
>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>> +		mac_an_value &= ~ETHQOS_MAC_AN_CTRL_ANE;
>> +		break;
>>  	case SPEED_1000:
>>  		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
>>  		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>>  			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>>  			      RGMII_IO_MACRO_CONFIG2);
>> +		if (ethqos->serdes_speed != SPEED_1000)
>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>>  		break;
>>  	case SPEED_100:
>>  		val |= ETHQOS_MAC_CTRL_PORT_SEL | ETHQOS_MAC_CTRL_SPEED_MODE;
>> +		if (ethqos->serdes_speed != SPEED_1000)
>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>>  		break;
>>  	case SPEED_10:
>>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
>> +		if (ethqos->serdes_speed != SPEED_1000)
>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>>  		break;
>>  	}
>>  
>>  	writel(val, ethqos->mac_base + MAC_CTRL_REG);
>> +	writel(mac_an_value, ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
>> +	ethqos->serdes_speed = ethqos->speed;
> 
> I see these bits are generic and there's some functions in stmmac_pcs.h
> that muck with these...
> 
> Could you help me understand if this really should be Qualcomm specific,
> or if this is something that should be considered for the more core bits
> of the driver? I feel in either case we should take advantage of the
> common definitions in that file if possible.
> 
we do have function dwmac_ctrl_ane in core driver which updates same registers. However, it does not have the option to reset ANE bit, it can only set bits. For SPEED_2500 we need to reset ANE bit. Hence I am adding it here. Not sure if we can extend dwmac_ctrl_ane function to reset bits as well.
>>  
>>  	return val;
>>  }
>> @@ -789,6 +815,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
>>  				     "Failed to get serdes phy\n");
>>  
>>  	ethqos->speed = SPEED_1000;
>> +	ethqos->serdes_speed = SPEED_1000;
>>  	ethqos_update_link_clk(ethqos, SPEED_1000);
>>  	ethqos_set_func_clk_en(ethqos);
>>  
>> -- 
>> 2.17.1
>>
> 


From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:36:30 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:36:30 +0100
Subject: [PATCH v5 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support
 for 74165b0
In-Reply-To: <20231219162236.36609-2-kamal.dasu@broadcom.com>
References: <20231219162236.36609-1-kamal.dasu@broadcom.com>
 <20231219162236.36609-2-kamal.dasu@broadcom.com>
Message-ID: <d6dc32d3-3200-4a2b-8347-c374b17a9e89@linaro.org>

On 19/12/2023 17:22, Kamal Dasu wrote:
> From: Kamal Dasu <kdasu at broadcom.com>
> 
> With newer sdio controller core used for 74165b0 we need to update
> the compatibility with "brcm,bcm74165b0-sdhci".
> 
> Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
> ---


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


---

This is an automated instruction, just in case, because many review tags
are being ignored. If you know the process, you can skip it (please do
not feel offended by me posting it here - no bad intentions intended).
If you do not know the process, here is a short explanation:

Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.

https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577

Best regards,
Krzysztof



From Jason-JH.Lin at mediatek.com  Tue Dec 19 23:33:31 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 20 Dec 2023 07:33:31 +0000
Subject: [PATCH 1/3] dt-bindings: mailbox: mediatek,gce-mailbox: Add
 mediatek,gce-events definition
In-Reply-To: <cafae4ec-337a-4134-8545-d86c4c61c858@linaro.org>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
	 <20231218083604.7327-2-jason-jh.lin@mediatek.com>
	 <cafae4ec-337a-4134-8545-d86c4c61c858@linaro.org>
Message-ID: <c74f9c3418fa89eec6e5925573e3f846163c346f.camel@mediatek.com>

Hi Krzysztof,

Thanks for the reviews.

On Wed, 2023-12-20 at 08:07 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 18/12/2023 09:36, Jason-JH.Lin wrote:
> > Since mediatek,gce-events property is a HW event signal from GCE,
> > it should be defined in mediatek,gce-mailbox.yaml and change the
> 
> Why? None of the bindings reference it. Did you just move property
> from
> one device to completely different one?
> 
> > description of mediatek,gce-events property in other bindings to
> > reference mediatek,gce-mailbox.yaml.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> >  .../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml  | 7
> +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git
> a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml 
> b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
> > index cef9d7601398..e4da0a58c943 100644
> > --- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> mailbox.yaml
> > +++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> mailbox.yaml
> > @@ -49,6 +49,13 @@ properties:
> >      items:
> >        - const: gce
> >  
> > +  mediatek,gce-events:
> > +    description:
> > +      The event id which is mapping to the specific hardware event
> signal
> > +      to gce. The event id is defined in the gce header
> > +      include/dt-bindings/gce/<chip>-gce.h of each chips.
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> 
> Where are the constraints?
> 
Since the GCE HW event id rage is 0~1023,
I would add minItems: 1 and maxItems: 1024 here.

Regards
Jason-JH.Lin

> Best regards,
> Krzysztof
> 

From Kuan-Ying.Lee at mediatek.com  Tue Dec 19 23:36:28 2023
From: Kuan-Ying.Lee at mediatek.com (Kuan-Ying Lee)
Date: Wed, 20 Dec 2023 15:36:28 +0800
Subject: [PATCH] scripts: Fix no space expression between sp and offset
Message-ID: <20231220073629.2658-1-Kuan-Ying.Lee@mediatek.com>

When I use older version aarch64 objdump (2.24) to disassemble
aarch64 vmlinux, I get the result like below.
There is no space between sp and offset.

ffff800008010000 <dw_apb_ictl_handle_irq>:
ffff800008010000:       d503233f        hint    #0x19
ffff800008010004:       a9bc7bfd        stp     x29, x30, [sp,#-64]!
ffff800008010008:       90011e60        adrp    x0, ffff80000a3dc000 <num_ictlrs>
ffff80000801000c:       910003fd        mov     x29, sp
ffff800008010010:       a9025bf5        stp     x21, x22, [sp,#32]

When I use newer version aarch64 objdump (2.35), I get
the result like below.
There is a space between sp and offset.

ffff800008010000 <dw_apb_ictl_handle_irq>:
ffff800008010000:       d503233f        paciasp
ffff800008010004:       a9bc7bfd        stp     x29, x30, [sp, #-64]!
ffff800008010008:       90011e60        adrp    x0, ffff80000a3dc000 <num_ictlrs>
ffff80000801000c:       910003fd        mov     x29, sp
ffff800008010010:       a9025bf5        stp     x21, x22, [sp, #32]

Add no space support of regular expression for old version objdump.

Cc: Casper Li <casper.li at mediatek.com>
Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee at mediatek.com>
---
 scripts/checkstack.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl
index b70482a95088..a0e25a8830b4 100755
--- a/scripts/checkstack.pl
+++ b/scripts/checkstack.pl
@@ -56,7 +56,7 @@ my (@stack, $re, $dre, $sub, $x, $xs, $funcre, $min_stack);
 	if ($arch =~ '^(aarch|arm)64$') {
 		#ffffffc0006325cc:       a9bb7bfd        stp     x29, x30, [sp, #-80]!
 		#a110:       d11643ff        sub     sp, sp, #0x590
-		$re = qr/^.*stp.*sp, \#-([0-9]{1,8})\]\!/o;
+		$re = qr/^.*stp.*sp, ?\#-([0-9]{1,8})\]\!/o;
 		$dre = qr/^.*sub.*sp, sp, #(0x$x{1,8})/o;
 	} elsif ($arch eq 'arm') {
 		#c0008ffc:	e24dd064	sub	sp, sp, #100	; 0x64
-- 
2.18.0



From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:38:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:38:07 +0100
Subject: [PATCH v3 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
Message-ID: <c3d372f0-3d21-4500-96cd-9c88aaf5ce89@linaro.org>

On 20/12/2023 03:58, Chunfeng Yun wrote:
> For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
> still send out unexpected ACK after receiving a short packet in burst
> transfer, this will cause an exception on connected device, specially for
> a 4k camera.
> Add a quirk property "rx-fifo-depth" to work around this hardware issue,
> prefer to use 3k bytes;
> The side-effect is that may cause performance drop about 10%, including
> bulk transfer.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
> v3: add fifo depth unit, change the value range from 0-3 to 1-4
> v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
> ---
>  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> index e9644e333d78..9478b7031796 100644
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> @@ -124,6 +124,18 @@ properties:
>        defined in the xHCI spec on MTK's controller.
>      default: 5000
>  
> +  rx-fifo-depth:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      It is a quirk used to work around Gen1 isoc-in endpoint transfer issue
> +      that still send out unexpected ACK after device finish the burst transfer
> +      with a short packet and cause an exception, specially on a 4K camera
> +      device, it happens on controller before about IPM v1.6.0; the side-effect
> +      is that may cause performance drop about 10%, include bulk transfer,
> +      prefer to use 3 here. The unit is 1K bytes.

NAK. Read comments on previous submission.

Best regards,
Krzysztof



From Kuan-Ying.Lee at mediatek.com  Tue Dec 19 23:47:56 2023
From: Kuan-Ying.Lee at mediatek.com (Kuan-Ying Lee)
Date: Wed, 20 Dec 2023 15:47:56 +0800
Subject: [PATCH] mm: page_alloc: remove duplication of free_one_page()
Message-ID: <20231220074757.3656-1-Kuan-Ying.Lee@mediatek.com>

Remove duplication of free_one_page().

Cc: Casper Li <casper.li at mediatek.com>
Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee at mediatek.com>
---
 mm/page_alloc.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2f646773a934..f46af8616cac 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1262,7 +1262,6 @@ static void free_one_page(struct zone *zone,
 static void __free_pages_ok(struct page *page, unsigned int order,
 			    fpi_t fpi_flags)
 {
-	unsigned long flags;
 	int migratetype;
 	unsigned long pfn = page_to_pfn(page);
 	struct zone *zone = page_zone(page);
@@ -1277,13 +1276,7 @@ static void __free_pages_ok(struct page *page, unsigned int order,
 	 */
 	migratetype = get_pfnblock_migratetype(page, pfn);
 
-	spin_lock_irqsave(&zone->lock, flags);
-	if (unlikely(has_isolate_pageblock(zone) ||
-		is_migrate_isolate(migratetype))) {
-		migratetype = get_pfnblock_migratetype(page, pfn);
-	}
-	__free_one_page(page, pfn, zone, order, migratetype, fpi_flags);
-	spin_unlock_irqrestore(&zone->lock, flags);
+	free_one_page(zone, page, pfn, order, migratetype, fpi_flags);
 
 	__count_vm_events(PGFREE, 1 << order);
 }
-- 
2.18.0



From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:53:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:53:53 +0100
Subject: [PATCH] dt-bindings: firmware: xilinx: Describe missing child
 nodes
In-Reply-To: <5bb16305a05692de29ee2aa2accc793e23b68dec.1702997680.git.michal.simek@amd.com>
References: <5bb16305a05692de29ee2aa2accc793e23b68dec.1702997680.git.michal.simek@amd.com>
Message-ID: <fc7863a2-d3c5-47c8-9484-ef9cd6d7dd5d@linaro.org>

On 19/12/2023 15:54, Michal Simek wrote:
> Firmware node has more than fpga, aes and clock child nodes but also power,
> reset, gpio, pinctrl and pcap which are not described yet.
> All of them have binding in separate files but there is missing connection
> to firmware node that's why describe it.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---
> 
>  .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> index 3d578f98ae2c..0662544f86f0 100644
> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> @@ -53,6 +53,37 @@ properties:
>        vector.
>      type: object
>  
> +  zynqmp-power:

Can we rename it to "power-management" or if it is a power-domain
provider to "power-controller"? Assuming nothing requires the old name?

Also, all these nodes/properties look like not ordered by name, so maybe
it is possible to add new nodes in some order?

> +    $ref: /schemas/power/reset/xlnx,zynqmp-power.yaml#
> +    description: The zynqmp-power node describes the power management
> +      configurations. It will control remote suspend/shutdown interfaces.
> +    type: object
> +


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:54:18 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:54:18 +0100
Subject: [PATCH] dt-bindings: pinctrl: xilinx: Rename *gpio to *gpio-grp
In-Reply-To: <2e3a1f1f57cf929bd05115bc081e6d01d5a53443.1702996859.git.michal.simek@amd.com>
References: <2e3a1f1f57cf929bd05115bc081e6d01d5a53443.1702996859.git.michal.simek@amd.com>
Message-ID: <8d69d05e-f4cc-4c31-8c3e-4a155b469cdb@linaro.org>

On 19/12/2023 15:41, Michal Simek wrote:
> Anything ending with gpio/gpios is taken as gpio phande/description which
> is reported as the issue coming from gpio-consumer.yaml schema.
> That's why rename the gpio suffix to gpio-grp to avoid name collision.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:54:33 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:54:33 +0100
Subject: [PATCH] dt-bindings: firmware: xilinx: Fix versal-fpga node name
In-Reply-To: <6779af2f9cc21c912f10cf310388d99b980800b2.1702996281.git.michal.simek@amd.com>
References: <6779af2f9cc21c912f10cf310388d99b980800b2.1702996281.git.michal.simek@amd.com>
Message-ID: <7ac7db8e-f9b5-4394-af71-1a2b2548c485@linaro.org>

On 19/12/2023 15:31, Michal Simek wrote:
> Based on commit 83a368a3fc8a ("docs: dt-bindings: add DTS Coding Style
> document") using underscore ('_') in node name is not recommended that's
> why switch to dash ('-').
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---
> 
>  .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml        | 4 ++--
>  Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml  | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> index 8e584857ddd4..3d578f98ae2c 100644
> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> @@ -41,7 +41,7 @@ properties:
>    "#power-domain-cells":
>      const: 1
>  

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Tue Dec 19 23:55:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 08:55:32 +0100
Subject: [PATCH] dt-bindings: soc: xilinx: Add support for K26 rev2 SOMs
In-Reply-To: <6673abb84e542c2841cece9336571f97b19882fe.1702995908.git.michal.simek@amd.com>
References: <6673abb84e542c2841cece9336571f97b19882fe.1702995908.git.michal.simek@amd.com>
Message-ID: <1afdcd25-d001-4523-be0d-2bf2c9e1d7a6@linaro.org>

On 19/12/2023 15:25, Michal Simek wrote:
> Revision 2 is SW compatible with revision 1 but it is necessary to reflect
> it in model and compatible properties which are parsed by user space.
> Rev 2 has improved a power on boot reset and MIO34 shutdown glich
> improvement done via an additional filter in the GreenPak chip.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---
> 
>  Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> index d4c0fe1fe435..62617e1ea74f 100644
> --- a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> +++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
> @@ -118,6 +118,7 @@ properties:
>  
>        - description: Xilinx Kria SOMs
>          items:
> +          - const: xlnx,zynqmp-sm-k26-rev2
>            - const: xlnx,zynqmp-sm-k26-rev1
>            - const: xlnx,zynqmp-sm-k26-revB
>            - const: xlnx,zynqmp-sm-k26-revA

You are changing existing list of compatibles, so all devices with
"rev1" will fail the checks. Is it expected?

Best regards,
Krzysztof



From Y.Moog at phytec.de  Tue Dec 19 23:56:11 2023
From: Y.Moog at phytec.de (Yannic Moog)
Date: Wed, 20 Dec 2023 07:56:11 +0000
Subject: [PATCH v2 2/2] arm64: dts: freescale: add phyGATE-Tauri i.MX 8M
 Mini Support
In-Reply-To: <20231220074931.GA13382@wunner.de>
References: <20230925-tauri_upstream_support-v2-0-62a6dfc48e31@phytec.de>
	 <20230925-tauri_upstream_support-v2-2-62a6dfc48e31@phytec.de>
	 <20231220074931.GA13382@wunner.de>
Message-ID: <ab45c82485fa272f74adf560cbb58ee60cc42689.camel@phytec.de>

Hello Lukas,

On Wed, 2023-12-20 at 08:49 +0100, Lukas Wunner wrote:
> On Mon, Sep 25, 2023 at 09:25:19AM +0200, Yannic Moog wrote:
> > phyGATE-Tauri uses a phyCORE-i.MX8MM SoM. Add device tree for the board.
> [...]
> > +	tpm: tpm at 1 {
> > +		compatible = "tcg,tpm_tis-spi";
> 
> What's the chip used on this board?? Going forward, the DT schema for TPMs
> requires the exact chip name in addition to the generic "tcg,tpm_tis-spi".

TPM SLB 9670 is used on the board. Thank you for highlighting this.

Yannic

> 
> 
> > +		interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> > +		interrupt-parent = <&gpio2>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_tpm>;
> > +		reg = <1>;
> > +		spi-max-frequency = <38000000>;
> > +	};
> > +};


From michal.simek at amd.com  Tue Dec 19 23:57:25 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 08:57:25 +0100
Subject: [PATCH] dt-bindings: firmware: xilinx: Describe missing child
 nodes
In-Reply-To: <fc7863a2-d3c5-47c8-9484-ef9cd6d7dd5d@linaro.org>
References: <5bb16305a05692de29ee2aa2accc793e23b68dec.1702997680.git.michal.simek@amd.com>
 <fc7863a2-d3c5-47c8-9484-ef9cd6d7dd5d@linaro.org>
Message-ID: <bcc3a802-70cd-425e-bb33-3ced81c038fd@amd.com>



On 12/20/23 08:53, Krzysztof Kozlowski wrote:
> On 19/12/2023 15:54, Michal Simek wrote:
>> Firmware node has more than fpga, aes and clock child nodes but also power,
>> reset, gpio, pinctrl and pcap which are not described yet.
>> All of them have binding in separate files but there is missing connection
>> to firmware node that's why describe it.
>>
>> Signed-off-by: Michal Simek <michal.simek at amd.com>
>> ---
>>
>>   .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
>>   1 file changed, 31 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>> index 3d578f98ae2c..0662544f86f0 100644
>> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>> @@ -53,6 +53,37 @@ properties:
>>         vector.
>>       type: object
>>   
>> +  zynqmp-power:
> 
> Can we rename it to "power-management" or if it is a power-domain
> provider to "power-controller"? Assuming nothing requires the old name?

I don't think there is any name dependency and node name can be renamed.

> 
> Also, all these nodes/properties look like not ordered by name, so maybe
> it is possible to add new nodes in some order?

I am fine with it. Do you want to sort it before adding new one or add new one 
and sort of all them?

Thanks,
Michal


From frank at oltmanns.dev  Tue Dec 19 23:14:27 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Wed, 20 Dec 2023 08:14:27 +0100
Subject: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher
 clock rate
In-Reply-To: <10386431.nUPlyArG6x@jernej-laptop>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-5-e238b6ed6dc1@oltmanns.dev>
 <10386431.nUPlyArG6x@jernej-laptop>
Message-ID: <87edfh9ud8.fsf@oltmanns.dev>


On 2023-12-19 at 18:04:29 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns napisal(a):
>> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
>> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
>> than 500 MHz.
>>
>> Therefore, change [hv]sync_(start|end) so that we reach a clock rate
>> that is high enough to drive PLL-MIPI within its limits.
>>
>> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
>
> I'm not too sure about this patch. I see that PLL_MIPI doesn't have set
> minimum frequency limit in clock driver. If you add it, clock framework
> should find rate that is high enough and divisible with target rate.

This one is really a tough nut. Unfortunately, the PLL_MIPI clock for
this panel has to run exactly at 6 * panel clock. Let me start by
showing the relevant part of the clock tree (this is on the pinephone
after applying the patches):
    pll-video0                 393600000
       pll-mipi                500945454
          tcon0                500945454
             tcon-data-clock   125236363

To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit
rate [1]. It's a fixed divisor

The panel I'm proposing to change is defined as this:

    static const struct st7703_panel_desc xbd599_desc = {
    	.mode = &xbd599_mode,
    	.lanes = 4,
    	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
    	.format = MIPI_DSI_FMT_RGB888,
    	.init_sequence = xbd599_init_sequence,
    };

So, we have 24 bpp and 4 lanes. Therefore, the resulting requested
tcon-data-clock rate is
    crtc_clock * 1000 * (24 / 4) / 4

tcon-data-clock therefore requests a parent rate of
    4 * (crtc_clock * 1000 * (24 / 4) / 4)

The initial 4 is the fixed divisor between tcon0 and tcon-data-clock.
Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi.

Since PLL-MIPI has to run at at least at 500MHz this forces us to have a
crtc_clock >= 83.333 MHz. The mode I'm prorposing results in a rate of
83.502 MHz.

If we only changed the constraints on the PLL_MIPI without changing the
panel mode, we end up with a mismatch. This, in turn, would result in
dropped frames, right?

Best regards,
  Frank

[1] Source:
https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/sun4i_tcon.c#L346

>
> Best regards,
> Jernej
>
>> ---
>>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++-------
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>> index b55bafd1a8be..6886fd7f765e 100644
>> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
>>
>>  static const struct drm_display_mode xbd599_mode = {
>>  	.hdisplay    = 720,
>> -	.hsync_start = 720 + 40,
>> -	.hsync_end   = 720 + 40 + 40,
>> -	.htotal	     = 720 + 40 + 40 + 40,
>> +	.hsync_start = 720 + 65,
>> +	.hsync_end   = 720 + 65 + 65,
>> +	.htotal      = 720 + 65 + 65 + 65,
>>  	.vdisplay    = 1440,
>> -	.vsync_start = 1440 + 18,
>> -	.vsync_end   = 1440 + 18 + 10,
>> -	.vtotal	     = 1440 + 18 + 10 + 17,
>> -	.clock	     = 69000,
>> +	.vsync_start = 1440 + 30,
>> +	.vsync_end   = 1440 + 30 + 22,
>> +	.vtotal	     = 1440 + 30 + 22 + 29,
>> +	.clock	     = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
>>  	.flags	     = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
>>  	.width_mm    = 68,
>>  	.height_mm   = 136,
>>
>>


From michal.simek at amd.com  Wed Dec 20 00:01:28 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 09:01:28 +0100
Subject: [PATCH] dt-bindings: soc: xilinx: Add support for K26 rev2 SOMs
In-Reply-To: <1afdcd25-d001-4523-be0d-2bf2c9e1d7a6@linaro.org>
References: <6673abb84e542c2841cece9336571f97b19882fe.1702995908.git.michal.simek@amd.com>
 <1afdcd25-d001-4523-be0d-2bf2c9e1d7a6@linaro.org>
Message-ID: <1feb69af-06e4-4cfe-a4ea-8dc583742f6e@amd.com>



On 12/20/23 08:55, Krzysztof Kozlowski wrote:
> On 19/12/2023 15:25, Michal Simek wrote:
>> Revision 2 is SW compatible with revision 1 but it is necessary to reflect
>> it in model and compatible properties which are parsed by user space.
>> Rev 2 has improved a power on boot reset and MIO34 shutdown glich
>> improvement done via an additional filter in the GreenPak chip.
>>
>> Signed-off-by: Michal Simek <michal.simek at amd.com>
>> ---
>>
>>   Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
>> index d4c0fe1fe435..62617e1ea74f 100644
>> --- a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
>> +++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
>> @@ -118,6 +118,7 @@ properties:
>>   
>>         - description: Xilinx Kria SOMs
>>           items:
>> +          - const: xlnx,zynqmp-sm-k26-rev2
>>             - const: xlnx,zynqmp-sm-k26-rev1
>>             - const: xlnx,zynqmp-sm-k26-revB
>>             - const: xlnx,zynqmp-sm-k26-revA
> 
> You are changing existing list of compatibles, so all devices with
> "rev1" will fail the checks. Is it expected?

That's a good point. I have actually never have a need to support older 
combination from validation perspective.
Let me play with it and see how it will look like to support all older 
combinations.
That would very much apply to almost all other records in this file.

Thanks,
Michal




From Jason-JH.Lin at mediatek.com  Tue Dec 19 23:59:58 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 20 Dec 2023 07:59:58 +0000
Subject: [PATCH 2/3] dt-bindings: media: mediatek-mdp: Change the
 description of gce-events
In-Reply-To: <e645a032-67d7-4669-9487-585635a1702e@linaro.org>
References: <20231218083604.7327-1-jason-jh.lin@mediatek.com>
	 <20231218083604.7327-3-jason-jh.lin@mediatek.com>
	 <e645a032-67d7-4669-9487-585635a1702e@linaro.org>
Message-ID: <5d92db1abf4cc52e8520caad5776b7f0719fc9a6.camel@mediatek.com>

Hi 

Thanks for the reviews.

On Wed, 2023-12-20 at 08:06 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 18/12/2023 09:36, Jason-JH.Lin wrote:
> > Change the description of mediatek,gce-events property to reference
> > mediatek,gce-mailbox.yaml.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> >  .../devicetree/bindings/media/mediatek,mdp3-rdma.yaml        | 5
> +----
> >  .../devicetree/bindings/media/mediatek,mdp3-rsz.yaml         | 5
> +----
> >  .../devicetree/bindings/media/mediatek,mdp3-wrot.yaml        | 5
> +----
> >  3 files changed, 3 insertions(+), 12 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-
> rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> rdma.yaml
> > index 7032c7e15039..adb3df4731f6 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-
> rdma.yaml
> > +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> rdma.yaml
> > @@ -40,10 +40,7 @@ properties:
> >  
> >    mediatek,gce-events:
> >      description:
> > -      The event id which is mapping to the specific hardware event
> signal
> > -      to gce. The event id is defined in the gce header
> > -      include/dt-bindings/gce/<chip>-gce.h of each chips.
> > -    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +      Reference to
> Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml.
> 
> There is no reference here. You allow now any type. This does not
> make
> any sense.

Since this property for the GCE HW are MediaTek specific, I will try
to refer to nvidia,tegra210-quad-peripheral-props.yaml and send a
series for creating a mediatek,gce-props.yaml to list all these
properties related to GCE. And change all these properties in mailbox
consumers to reference mediatek,gce-props.yaml.

allOf:
  - $ref: mediatek,gce-props.yaml


Regards,
Jason-JH.Lin

> 
> Best regards,
> Krzysztof
> 

From quic_bibekkum at quicinc.com  Wed Dec 20 00:08:23 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Wed, 20 Dec 2023 13:38:23 +0530
Subject: [PATCH v5 1/5] iommu/arm-smmu: re-enable context caching in smmu
 reset operation
In-Reply-To: <810ee42b-49c9-4184-b5aa-a95261faf77a@linaro.org>
References: <20231219135947.1623-1-quic_bibekkum@quicinc.com>
 <20231219135947.1623-2-quic_bibekkum@quicinc.com>
 <810ee42b-49c9-4184-b5aa-a95261faf77a@linaro.org>
Message-ID: <ccd67437-39cb-4fea-98aa-4dfae5f4c1d0@quicinc.com>



On 12/19/2023 11:29 PM, Konrad Dybcio wrote:
> On 19.12.2023 14:59, Bibek Kumar Patro wrote:
>> Default MMU-500 reset operation disables context caching in
>> prefetch buffer. It is however expected for context banks using
>> the ACTLR register to retain their prefetch value during reset
>> and runtime suspend.
>>
>> Replace default MMU-500 reset operation with Qualcomm specific reset
>> operation which envelope the default reset operation and re-enables
>> context caching in prefetch buffer for Qualcomm SoCs.
>>
>> Suggested-by: Konrad Dybcio <konrad.dybcio at linaro.org>
> Suggested-by implies I came up with this being a solution to
> an issue.. definitely not the case!
> 

Noted, will send v6 by removing the Suggested by tag
and will address the return check as well.

Thanks,
Bibek

> Konrad


From fuyao1697 at cyg.com  Wed Dec 20 00:08:56 2023
From: fuyao1697 at cyg.com (fuyao)
Date: Wed, 20 Dec 2023 16:08:56 +0800
Subject: [PATCH] ARM: dts: sun8i: r40: open the regulator aldo1
Message-ID: <ZYKhGL0gH6MvUK_H@debian.cyg>

the aldo1 is connect regulator pin which power the TV.
The USB core use TV ref as reference Voltage.

Signed-off-by: fuyao <fuyao1697 at cyg.com>
---
 arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
index 9f39b5a2bb35..8906170461df 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
@@ -42,6 +42,13 @@ &pio {
 	vcc-pg-supply = <&reg_dldo1>;
 };
 
+&reg_aldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-aldo1";
+};
+
 &reg_aldo2 {
 	regulator-always-on;
 	regulator-min-microvolt = <1800000>;
-- 
2.39.2


-- 
CYG Technology.


From luca.ceresoli at bootlin.com  Wed Dec 20 00:10:07 2023
From: luca.ceresoli at bootlin.com (Luca Ceresoli)
Date: Wed, 20 Dec 2023 09:10:07 +0100
Subject: [PATCH v2 2/6] ASoC: dt-bindings: Add Rockchip RK3308 internal
 audio codec
In-Reply-To: <170302760623.2025074.2958729782154314139.robh@kernel.org>
References: <20231219-rk3308-audio-codec-v2-0-c70d06021946@bootlin.com>
	<20231219-rk3308-audio-codec-v2-2-c70d06021946@bootlin.com>
	<170302760623.2025074.2958729782154314139.robh@kernel.org>
Message-ID: <20231220091007.35e62af9@booty>

Hello,

On Tue, 19 Dec 2023 17:13:26 -0600
Rob Herring <robh at kernel.org> wrote:

> On Tue, 19 Dec 2023 15:54:17 +0100, Luca Ceresoli wrote:
> > Add device tree bindings document for the internal audio codec of the
> > Rockchip RK3308 SoC.

...

> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Error: Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.example.dts:20.20-21 syntax error

Indeed:

-    audio-codec: audio-codec at ff560000 {
+    audio_codec: audio-codec at ff560000 {

Fixed locally, queued for v3.

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From krzysztof.kozlowski at linaro.org  Wed Dec 20 00:18:28 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 09:18:28 +0100
Subject: [PATCH] dt-bindings: firmware: xilinx: Describe missing child
 nodes
In-Reply-To: <bcc3a802-70cd-425e-bb33-3ced81c038fd@amd.com>
References: <5bb16305a05692de29ee2aa2accc793e23b68dec.1702997680.git.michal.simek@amd.com>
 <fc7863a2-d3c5-47c8-9484-ef9cd6d7dd5d@linaro.org>
 <bcc3a802-70cd-425e-bb33-3ced81c038fd@amd.com>
Message-ID: <5be15b6f-ac6e-4cab-bd83-ef3fa50e1886@linaro.org>

On 20/12/2023 08:57, Michal Simek wrote:
> 
> 
> On 12/20/23 08:53, Krzysztof Kozlowski wrote:
>> On 19/12/2023 15:54, Michal Simek wrote:
>>> Firmware node has more than fpga, aes and clock child nodes but also power,
>>> reset, gpio, pinctrl and pcap which are not described yet.
>>> All of them have binding in separate files but there is missing connection
>>> to firmware node that's why describe it.
>>>
>>> Signed-off-by: Michal Simek <michal.simek at amd.com>
>>> ---
>>>
>>>   .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
>>>   1 file changed, 31 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>> index 3d578f98ae2c..0662544f86f0 100644
>>> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>> @@ -53,6 +53,37 @@ properties:
>>>         vector.
>>>       type: object
>>>   
>>> +  zynqmp-power:
>>
>> Can we rename it to "power-management" or if it is a power-domain
>> provider to "power-controller"? Assuming nothing requires the old name?
> 
> I don't think there is any name dependency and node name can be renamed.
> 
>>
>> Also, all these nodes/properties look like not ordered by name, so maybe
>> it is possible to add new nodes in some order?
> 
> I am fine with it. Do you want to sort it before adding new one or add new one 
> and sort of all them?

Maybe the new properties can be added not in one chunk but
as-ordered-as-possible?

Best regards,
Krzysztof



From fuyao1697 at cyg.com  Wed Dec 20 00:18:43 2023
From: fuyao1697 at cyg.com (fuyao)
Date: Wed, 20 Dec 2023 16:18:43 +0800
Subject: [PATCH RESEND] ARM: dts: sun8i: r40: open the regulator aldo1
Message-ID: <ZYKjYypuAx7gNuam@debian.cyg>

the aldo1 is connect regulator pin which power the TV.
The USB core use TV ref as reference Voltage.

Signed-off-by: fuyao <fuyao1697 at cyg.com>
---
 arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
index 9f39b5a2bb35..8906170461df 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
@@ -42,6 +42,13 @@ &pio {
 	vcc-pg-supply = <&reg_dldo1>;
 };
 
+&reg_aldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-aldo1";
+};
+
 &reg_aldo2 {
 	regulator-always-on;
 	regulator-min-microvolt = <1800000>;
-- 
2.39.2


-- 
CYG Technology.


From michal.simek at amd.com  Wed Dec 20 00:20:20 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 09:20:20 +0100
Subject: [PATCH] dt-bindings: firmware: xilinx: Describe missing child
 nodes
In-Reply-To: <5be15b6f-ac6e-4cab-bd83-ef3fa50e1886@linaro.org>
References: <5bb16305a05692de29ee2aa2accc793e23b68dec.1702997680.git.michal.simek@amd.com>
 <fc7863a2-d3c5-47c8-9484-ef9cd6d7dd5d@linaro.org>
 <bcc3a802-70cd-425e-bb33-3ced81c038fd@amd.com>
 <5be15b6f-ac6e-4cab-bd83-ef3fa50e1886@linaro.org>
Message-ID: <70774949-7309-4a84-a224-13cceccbb3f3@amd.com>



On 12/20/23 09:18, Krzysztof Kozlowski wrote:
> On 20/12/2023 08:57, Michal Simek wrote:
>>
>>
>> On 12/20/23 08:53, Krzysztof Kozlowski wrote:
>>> On 19/12/2023 15:54, Michal Simek wrote:
>>>> Firmware node has more than fpga, aes and clock child nodes but also power,
>>>> reset, gpio, pinctrl and pcap which are not described yet.
>>>> All of them have binding in separate files but there is missing connection
>>>> to firmware node that's why describe it.
>>>>
>>>> Signed-off-by: Michal Simek <michal.simek at amd.com>
>>>> ---
>>>>
>>>>    .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
>>>>    1 file changed, 31 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>>> index 3d578f98ae2c..0662544f86f0 100644
>>>> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>>> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>>> @@ -53,6 +53,37 @@ properties:
>>>>          vector.
>>>>        type: object
>>>>    
>>>> +  zynqmp-power:
>>>
>>> Can we rename it to "power-management" or if it is a power-domain
>>> provider to "power-controller"? Assuming nothing requires the old name?
>>
>> I don't think there is any name dependency and node name can be renamed.
>>
>>>
>>> Also, all these nodes/properties look like not ordered by name, so maybe
>>> it is possible to add new nodes in some order?
>>
>> I am fine with it. Do you want to sort it before adding new one or add new one
>> and sort of all them?
> 
> Maybe the new properties can be added not in one chunk but
> as-ordered-as-possible?

It is more about that current nodes are not sorted that's why they should be sorted.

Thanks,
Michal


From adrian.mackiewicz at bizloop.pl  Wed Dec 20 00:31:11 2023
From: adrian.mackiewicz at bizloop.pl (Adrian Mackiewicz)
Date: Wed, 20 Dec 2023 08:31:11 GMT
Subject: Nowe informacje na stronie www
Message-ID: <20231220084500-0.1.1a.3h90.0.rampm58io2@bizloop.pl>

Szanowni Pa?stwo,

zastanawiali si? Pa?stwo nad now? stron? internetow? dla swojej firmy?

Technologia i trendy w projektowaniu stron stale si? zmieniaj?. Aktualizacja witryny pozwoli Wam utrzyma? krok z najnowszymi rozwi?zaniami, co z pewno?ci? przyci?gnie uwag? klient?w i wyr??ni Was w?r?d konkurencji.

Dzi?ki nowym technologiom oferujemy lepsze do?wiadczenie u?ytkownika, co przek?ada si? na zwi?kszon? satysfakcj? klient?w i wi?ksz? sk?onno?? do interakcji z Wasz? mark?.

Warto rozwa?y?, jak nowoczesne podej?cie mo?e podnie?? Pa?stwa obecno?? online na wy?szy poziom. Mo?emy porozmawia? w tej sprawie?


Pozdrawiam
Adrian Mackiewicz


From krzysztof.kozlowski at linaro.org  Wed Dec 20 00:40:43 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 09:40:43 +0100
Subject: [GIT PULL] clk: samsung: drivers for v6.8
Message-ID: <20231220084043.21549-1-krzysztof.kozlowski@linaro.org>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-clk-6.8

for you to fetch changes up to 5583e92be5c45448e6ea461e1780d46c17d14963:

  clk: samsung: Improve kernel-doc comments (2023-11-16 20:46:03 +0100)

----------------------------------------------------------------
Samsung SoC clock drivers changes for 6.8

Few kernel-doc fixes for Samsung SoC clock controllers.

----------------------------------------------------------------
Sam Protsenko (2):
      clk: samsung: Fix kernel-doc comments
      clk: samsung: Improve kernel-doc comments

 drivers/clk/samsung/clk-cpu.h |  30 ++++----
 drivers/clk/samsung/clk.h     | 157 +++++++++++++++++++++++-------------------
 2 files changed, 101 insertions(+), 86 deletions(-)


From ryan.roberts at arm.com  Wed Dec 20 00:42:49 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 08:42:49 +0000
Subject: [PATCH v4 16/16] arm64/mm: Implement clear_ptes() to optimize
 exit, munmap, dontneed
In-Reply-To: <87v88tzbfe.fsf@nvdebian.thelocal>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-17-ryan.roberts@arm.com>
 <87v88tzbfe.fsf@nvdebian.thelocal>
Message-ID: <44ca1e89-c0f3-4916-9bd7-99a3fc626073@arm.com>

On 20/12/2023 05:28, Alistair Popple wrote:
> 
> Ryan Roberts <ryan.roberts at arm.com> writes:
> 
>> With the core-mm changes in place to batch-clear ptes during
>> zap_pte_range(), we can take advantage of this in arm64 to greatly
>> reduce the number of tlbis we have to issue, and recover the lost
>> performance in exit, munmap and madvise(DONTNEED) incured when adding
>> support for transparent contiguous ptes.
>>
>> If we are clearing a whole contpte range, we can elide first unfolding
>> that range and save the tlbis. We just clear the whole range.
>>
>> The following microbenchmark results demonstate the effect of this
>> change on madvise(DONTNEED) performance for large pte-mapped folios.
>> madvise(dontneed) is called for each page of a 1G populated mapping and
>> the total time is measured. 100 iterations per run, 8 runs performed on
>> both Apple M2 (VM) and Ampere Altra (bare metal). Tests performed for
>> case where 1G memory is comprised of pte-mapped order-9 folios. Negative
>> is faster, positive is slower, compared to baseline upon which the
>> series is based:
>>
>> | dontneed      |    Apple M2 VM    |    Ampere Altra   |
>> | order-9       |-------------------|-------------------|
>> | (pte-map)     |    mean |   stdev |    mean |   stdev |
>> |---------------|---------|---------|---------|---------|
>> | baseline      |    0.0% |    7.9% |    0.0% |    0.0% |
>> | before-change |   -1.3% |    7.0% |   13.0% |    0.0% |
>> | after-change  |   -9.9% |    0.9% |   14.1% |    0.0% |
>>
>> The memory is initially all contpte-mapped and has to be unfolded (which
>> requires tlbi for the whole block) when the first page is touched (since
>> the test is madvise-ing 1 page at a time). Ampere Altra has high cost
>> for tlbi; this is why cost increases there.
>>
>> The following microbenchmark results demonstate the recovery (and
>> overall improvement) of munmap performance for large pte-mapped folios.
>> munmap is called for a 1G populated mapping and the function runtime is
>> measured. 100 iterations per run, 8 runs performed on both Apple M2 (VM)
>> and Ampere Altra (bare metal). Tests performed for case where 1G memory
>> is comprised of pte-mapped order-9 folios. Negative is faster, positive
>> is slower, compared to baseline upon which the series is based:
>>
>> | munmap        |    Apple M2 VM    |    Ampere Altra   |
>> | order-9       |-------------------|-------------------|
>> | (pte-map)     |    mean |   stdev |    mean |   stdev |
>> |---------------|---------|---------|---------|---------|
>> | baseline      |    0.0% |    6.4% |    0.0% |    0.1% |
>> | before-change |   43.3% |    1.9% |  375.2% |    0.0% |
>> | after-change  |   -6.0% |    1.4% |   -0.6% |    0.2% |
>>
>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>> ---
>>  arch/arm64/include/asm/pgtable.h | 42 +++++++++++++++++++++++++++++
>>  arch/arm64/mm/contpte.c          | 45 ++++++++++++++++++++++++++++++++
>>  2 files changed, 87 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index d4805f73b9db..f5bf059291c3 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -953,6 +953,29 @@ static inline pte_t __ptep_get_and_clear(struct mm_struct *mm,
>>  	return pte;
>>  }
>>  
>> +static inline pte_t __clear_ptes(struct mm_struct *mm,
>> +				 unsigned long address, pte_t *ptep,
>> +				 unsigned int nr, int full)
> 
> Ping on my previous comment - why not just use the generic version
> defined in patch 3 which is basically identical to this?

Perhaps I misunderstood your original comment - I thought this was what you were
suggesting - i.e. move this code out of the arm64 clear_ptes() impl into its own
__clear_ptes() helper, and always define an arm64 clear_ptes(), even when
ARM64_CONTPTE is not enabled.

I can use (and was in v3) the generic version when ARM64_CONTPTE is disabled.
But I can't use it when its enabled, because then arm64 needs its own
implementation to manage the contpte bit. And once it defines it's own version,
by defining the macro clear_ptes(), then the generic version is no longer
defined so I can't call it as part of this implementation. Even if I could, that
would be recursive.

Or perhaps I'm still not understanding your suggestion?

> 
>> +{
>> +	pte_t orig_pte = __ptep_get_and_clear(mm, address, ptep);
>> +	unsigned int i;
>> +	pte_t pte;
>> +
>> +	for (i = 1; i < nr; i++) {
>> +		address += PAGE_SIZE;
>> +		ptep++;
>> +		pte = __ptep_get_and_clear(mm, address, ptep);
>> +
>> +		if (pte_dirty(pte))
>> +			orig_pte = pte_mkdirty(orig_pte);
>> +
>> +		if (pte_young(pte))
>> +			orig_pte = pte_mkyoung(orig_pte);
>> +	}
>> +
>> +	return orig_pte;
>> +}
>> +
>>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>  #define __HAVE_ARCH_PMDP_HUGE_GET_AND_CLEAR
>>  static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
>> @@ -1151,6 +1174,8 @@ extern pte_t contpte_ptep_get(pte_t *ptep, pte_t orig_pte);
>>  extern pte_t contpte_ptep_get_lockless(pte_t *orig_ptep);
>>  extern void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>>  				pte_t *ptep, pte_t pte, unsigned int nr);
>> +extern pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr,
>> +				pte_t *ptep, unsigned int nr, int full);
>>  extern int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>  				unsigned long addr, pte_t *ptep);
>>  extern int contpte_ptep_clear_flush_young(struct vm_area_struct *vma,
>> @@ -1279,6 +1304,22 @@ static inline void pte_clear(struct mm_struct *mm,
>>  	__pte_clear(mm, addr, ptep);
>>  }
>>  
>> +#define clear_ptes clear_ptes
>> +static inline pte_t clear_ptes(struct mm_struct *mm,
>> +				unsigned long addr, pte_t *ptep,
>> +				unsigned int nr, int full)
>> +{
>> +	pte_t pte;
>> +
>> +	if (nr == 1) {
>> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>> +		pte = __ptep_get_and_clear(mm, addr, ptep);
>> +	} else
>> +		pte = contpte_clear_ptes(mm, addr, ptep, nr, full);
>> +
>> +	return pte;
>> +}
>> +
>>  #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
>>  static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
>>  				unsigned long addr, pte_t *ptep)
>> @@ -1366,6 +1407,7 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma,
>>  #define set_pte					__set_pte
>>  #define set_ptes				__set_ptes
>>  #define pte_clear				__pte_clear
>> +#define clear_ptes				__clear_ptes
>>  #define __HAVE_ARCH_PTEP_GET_AND_CLEAR
>>  #define ptep_get_and_clear			__ptep_get_and_clear
>>  #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
>> diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
>> index 72e672024785..6f2a15ac5163 100644
>> --- a/arch/arm64/mm/contpte.c
>> +++ b/arch/arm64/mm/contpte.c
>> @@ -293,6 +293,51 @@ void contpte_set_ptes(struct mm_struct *mm, unsigned long addr,
>>  }
>>  EXPORT_SYMBOL(contpte_set_ptes);
>>  
>> +pte_t contpte_clear_ptes(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
>> +					unsigned int nr, int full)
>> +{
>> +	/*
>> +	 * If we cover a partial contpte block at the beginning or end of the
>> +	 * batch, unfold if currently folded. This makes it safe to clear some
>> +	 * of the entries while keeping others. contpte blocks in the middle of
>> +	 * the range, which are fully covered don't need to be unfolded because
>> +	 * we will clear the full block.
>> +	 */
>> +
>> +	unsigned int i;
>> +	pte_t pte;
>> +	pte_t tail;
>> +
>> +	if (!mm_is_user(mm))
>> +		return __clear_ptes(mm, addr, ptep, nr, full);
>> +
>> +	if (ptep != contpte_align_down(ptep) || nr < CONT_PTES)
>> +		contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
>> +
>> +	if (ptep + nr != contpte_align_down(ptep + nr))
>> +		contpte_try_unfold(mm, addr + PAGE_SIZE * (nr - 1),
>> +				   ptep + nr - 1,
>> +				   __ptep_get(ptep + nr - 1));
>> +
>> +	pte = __ptep_get_and_clear(mm, addr, ptep);
>> +
>> +	for (i = 1; i < nr; i++) {
>> +		addr += PAGE_SIZE;
>> +		ptep++;
>> +
>> +		tail = __ptep_get_and_clear(mm, addr, ptep);
>> +
>> +		if (pte_dirty(tail))
>> +			pte = pte_mkdirty(pte);
>> +
>> +		if (pte_young(tail))
>> +			pte = pte_mkyoung(pte);
>> +	}
>> +
>> +	return pte;
>> +}
>> +EXPORT_SYMBOL(contpte_clear_ptes);
>> +
>>  int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma,
>>  					unsigned long addr, pte_t *ptep)
>>  {
> 



From hugues.fruchet at foss.st.com  Wed Dec 20 00:46:40 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 09:46:40 +0100
Subject: [PATCH v3 4/5] arm64: dts: st: add video decoder support to stm32mp255
In-Reply-To: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
References: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220084641.2076428-5-hugues.fruchet@foss.st.com>

Add VDEC hardware video decoder support to STM32MP255.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi |  6 ++++++
 arch/arm64/boot/dts/st/stm32mp255.dtsi | 10 ++++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 96859d098ef8..8fc7e9199499 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -52,6 +52,12 @@ ck_icn_ls_mcu: ck-icn-ls-mcu {
 			compatible = "fixed-clock";
 			clock-frequency = <200000000>;
 		};
+
+		ck_icn_p_vdec: ck-icn-p-vdec {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <200000000>;
+		};
 	};
 
 	firmware {
diff --git a/arch/arm64/boot/dts/st/stm32mp255.dtsi b/arch/arm64/boot/dts/st/stm32mp255.dtsi
index e6fa596211f5..aea5096dac3c 100644
--- a/arch/arm64/boot/dts/st/stm32mp255.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp255.dtsi
@@ -6,4 +6,14 @@
 #include "stm32mp253.dtsi"
 
 / {
+	soc at 0 {
+		rifsc: rifsc-bus at 42080000 {
+			vdec: vdec at 480d0000 {
+				compatible = "st,stm32mp25-vdec";
+				reg = <0x480d0000 0x3c8>;
+				interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ck_icn_p_vdec>;
+			};
+		};
+	};
 };
-- 
2.25.1



From hugues.fruchet at foss.st.com  Wed Dec 20 00:46:38 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 09:46:38 +0100
Subject: [PATCH v3 2/5] media: hantro: add support for STM32MP25 VDEC
In-Reply-To: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
References: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220084641.2076428-3-hugues.fruchet@foss.st.com>

Add support for STM32MP25 VDEC video hardware decoder.
H264/VP8 decoding up to 4080x4080.
No post-processor support.
VDEC has its own reset/clock/irq.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 drivers/media/platform/verisilicon/Kconfig    | 14 ++-
 drivers/media/platform/verisilicon/Makefile   |  3 +
 .../media/platform/verisilicon/hantro_drv.c   |  3 +
 .../media/platform/verisilicon/hantro_hw.h    |  1 +
 .../platform/verisilicon/stm32mp25_vdec_hw.c  | 92 +++++++++++++++++++
 5 files changed, 110 insertions(+), 3 deletions(-)
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c

diff --git a/drivers/media/platform/verisilicon/Kconfig b/drivers/media/platform/verisilicon/Kconfig
index e65b836b9d78..7642ff9cf96c 100644
--- a/drivers/media/platform/verisilicon/Kconfig
+++ b/drivers/media/platform/verisilicon/Kconfig
@@ -4,7 +4,7 @@ comment "Verisilicon media platform drivers"
 
 config VIDEO_HANTRO
 	tristate "Hantro VPU driver"
-	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || COMPILE_TEST
+	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || ARCH_STM32 || COMPILE_TEST
 	depends on V4L_MEM2MEM_DRIVERS
 	depends on VIDEO_DEV
 	select MEDIA_CONTROLLER
@@ -16,8 +16,8 @@ config VIDEO_HANTRO
 	select V4L2_VP9
 	help
 	  Support for the Hantro IP based Video Processing Units present on
-	  Rockchip and NXP i.MX8M SoCs, which accelerate video and image
-	  encoding and decoding.
+	  Rockchip, NXP i.MX8M and STM32MP25 SoCs, which accelerate video
+	  and image encoding and decoding.
 	  To compile this driver as a module, choose M here: the module
 	  will be called hantro-vpu.
 
@@ -52,3 +52,11 @@ config VIDEO_HANTRO_SUNXI
 	default y
 	help
 	  Enable support for H6 SoC.
+
+config VIDEO_HANTRO_STM32MP25
+	bool "Hantro STM32MP25 support"
+	depends on VIDEO_HANTRO
+	depends on ARCH_STM32 || COMPILE_TEST
+	default y
+	help
+	  Enable support for STM32MP25 SoCs.
diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
index 6ad2ef885920..5854e0f0dd32 100644
--- a/drivers/media/platform/verisilicon/Makefile
+++ b/drivers/media/platform/verisilicon/Makefile
@@ -39,3 +39,6 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_ROCKCHIP) += \
 
 hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
 		sunxi_vpu_hw.o
+
+hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
+		stm32mp25_vdec_hw.o
diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
index a9fa05ac56a9..2db27c333924 100644
--- a/drivers/media/platform/verisilicon/hantro_drv.c
+++ b/drivers/media/platform/verisilicon/hantro_drv.c
@@ -733,6 +733,9 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_SUNXI
 	{ .compatible = "allwinner,sun50i-h6-vpu-g2", .data = &sunxi_vpu_variant, },
+#endif
+#ifdef CONFIG_VIDEO_HANTRO_STM32MP25
+	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
 #endif
 	{ /* sentinel */ }
 };
diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
index 7f33f7b07ce4..b7eccc1a96fc 100644
--- a/drivers/media/platform/verisilicon/hantro_hw.h
+++ b/drivers/media/platform/verisilicon/hantro_hw.h
@@ -406,6 +406,7 @@ extern const struct hantro_variant rk3568_vpu_variant;
 extern const struct hantro_variant rk3588_vpu981_variant;
 extern const struct hantro_variant sama5d4_vdec_variant;
 extern const struct hantro_variant sunxi_vpu_variant;
+extern const struct hantro_variant stm32mp25_vdec_variant;
 
 extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
 extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
diff --git a/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
new file mode 100644
index 000000000000..aa8b0f751390
--- /dev/null
+++ b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * STM32MP25 VDEC video decoder driver
+ *
+ * Copyright (C) STMicroelectronics SA 2022
+ * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
+ *          for STMicroelectronics.
+ *
+ */
+
+#include "hantro.h"
+
+/*
+ * Supported formats.
+ */
+
+static const struct hantro_fmt stm32mp25_vdec_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_NV12,
+		.codec_mode = HANTRO_MODE_NONE,
+		.frmsize = {
+			.min_width = FMT_MIN_WIDTH,
+			.max_width = FMT_FHD_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = FMT_MIN_HEIGHT,
+			.max_height = FMT_FHD_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_VP8_FRAME,
+		.codec_mode = HANTRO_MODE_VP8_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = FMT_MIN_WIDTH,
+			.max_width = FMT_FHD_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = FMT_MIN_HEIGHT,
+			.max_height = FMT_FHD_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_H264_SLICE,
+		.codec_mode = HANTRO_MODE_H264_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = FMT_MIN_WIDTH,
+			.max_width = FMT_FHD_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = FMT_MIN_HEIGHT,
+			.max_height = FMT_FHD_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+};
+
+/*
+ * Supported codec ops.
+ */
+
+static const struct hantro_codec_ops stm32mp25_vdec_codec_ops[] = {
+	[HANTRO_MODE_VP8_DEC] = {
+		.run = hantro_g1_vp8_dec_run,
+		.reset = hantro_g1_reset,
+		.init = hantro_vp8_dec_init,
+		.exit = hantro_vp8_dec_exit,
+	},
+	[HANTRO_MODE_H264_DEC] = {
+		.run = hantro_g1_h264_dec_run,
+		.reset = hantro_g1_reset,
+		.init = hantro_h264_dec_init,
+		.exit = hantro_h264_dec_exit,
+	},
+};
+
+static const struct hantro_irq stm32mp25_irqs[] = {
+	{ "vdec", hantro_g1_irq },
+};
+
+static const char * const stm32mp25_clk_names[] = { "vdec-clk" };
+
+const struct hantro_variant stm32mp25_vdec_variant = {
+	.dec_fmts = stm32mp25_vdec_fmts,
+	.num_dec_fmts = ARRAY_SIZE(stm32mp25_vdec_fmts),
+	.codec = HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
+	.codec_ops = stm32mp25_vdec_codec_ops,
+	.irqs = stm32mp25_irqs,
+	.num_irqs = ARRAY_SIZE(stm32mp25_irqs),
+	.clk_names = stm32mp25_clk_names,
+	.num_clocks = ARRAY_SIZE(stm32mp25_clk_names),
+};
-- 
2.25.1



From hugues.fruchet at foss.st.com  Wed Dec 20 00:46:36 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 09:46:36 +0100
Subject: [PATCH v3 0/4] Add support for video hardware codec of STMicroelectronics STM32 SoC series
Message-ID: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>

This patchset introduces support for VDEC video hardware decoder
and VENC video hardware encoder of STMicroelectronics STM32MP25
SoC series.

This initial support implements H264 decoding, VP8 decoding and
JPEG encoding.

This has been tested on STM32MP257F-EV1 evaluation board.

===========
= history =
===========
version 3:
   - Fix remarks from Krzysztof Kozlowski:
    - drop "items", we keep simple enum in such case
    - drop second example - it is the same as the first
   - Drop unused node labels as suggested by Conor Dooley
   - Revisit min/max resolutions as suggested by Nicolas Dufresne

version 2:
   - Fix remarks from Krzysztof Kozlowski on v1:
    - single video-codec binding for both VDEC/VENC
    - get rid of "-names"
    - use of generic node name "video-codec"

version 1:
  - Initial submission

Hugues Fruchet (5):
  dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
  media: hantro: add support for STM32MP25 VDEC
  media: hantro: add support for STM32MP25 VENC
  arm64: dts: st: add video decoder support to stm32mp255
  arm64: dts: st: add video encoder support to stm32mp255

 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  12 ++
 arch/arm64/boot/dts/st/stm32mp255.dtsi        |  17 ++
 drivers/media/platform/verisilicon/Kconfig    |  14 +-
 drivers/media/platform/verisilicon/Makefile   |   4 +
 .../media/platform/verisilicon/hantro_drv.c   |   4 +
 .../media/platform/verisilicon/hantro_hw.h    |   2 +
 .../platform/verisilicon/stm32mp25_vdec_hw.c  |  92 +++++++++++
 .../platform/verisilicon/stm32mp25_venc_hw.c  | 147 ++++++++++++++++++
 8 files changed, 289 insertions(+), 3 deletions(-)
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c

-- 
2.25.1



From hugues.fruchet at foss.st.com  Wed Dec 20 00:46:37 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 09:46:37 +0100
Subject: [PATCH v3 1/5] dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
In-Reply-To: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
References: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220084641.2076428-2-hugues.fruchet@foss.st.com>

Add STM32MP25 VDEC video decoder & VENC video encoder bindings.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 .../media/st,stm32mp25-video-codec.yaml       | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml

diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
new file mode 100644
index 000000000000..e167e3b1bec3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/st,stm32mp25-video-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 VDEC video decoder & VENC video encoder
+
+maintainers:
+  - Hugues Fruchet <hugues.fruchet at foss.st.com>
+
+description:
+  The STMicroelectronics STM32MP25 SOCs embeds a VDEC video hardware
+  decoder peripheral based on Verisilicon VC8000NanoD IP (former Hantro G1)
+  and a VENC video hardware encoder peripheral based on Verisilicon
+  VC8000NanoE IP (former Hantro H1).
+
+properties:
+  compatible:
+    enum:
+      - st,stm32mp25-vdec
+      - st,stm32mp25-venc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    video-codec at 580d0000 {
+        compatible = "st,stm32mp25-vdec";
+        reg = <0x580d0000 0x3c8>;
+        interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&ck_icn_p_vdec>;
+    };
-- 
2.25.1



From hugues.fruchet at foss.st.com  Wed Dec 20 00:46:39 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 09:46:39 +0100
Subject: [PATCH v3 3/5] media: hantro: add support for STM32MP25 VENC
In-Reply-To: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
References: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220084641.2076428-4-hugues.fruchet@foss.st.com>

Add support for STM32MP25 VENC video hardware encoder.
JPEG encoding up to 8176x8176.
VENC has its own reset/clock/irq.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 drivers/media/platform/verisilicon/Makefile   |   3 +-
 .../media/platform/verisilicon/hantro_drv.c   |   1 +
 .../media/platform/verisilicon/hantro_hw.h    |   1 +
 .../platform/verisilicon/stm32mp25_venc_hw.c  | 147 ++++++++++++++++++
 4 files changed, 151 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c

diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
index 5854e0f0dd32..3bf43fdbedc1 100644
--- a/drivers/media/platform/verisilicon/Makefile
+++ b/drivers/media/platform/verisilicon/Makefile
@@ -41,4 +41,5 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
 		sunxi_vpu_hw.o
 
 hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
-		stm32mp25_vdec_hw.o
+		stm32mp25_vdec_hw.o \
+		stm32mp25_venc_hw.o
diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
index 2db27c333924..4d97a8ac03de 100644
--- a/drivers/media/platform/verisilicon/hantro_drv.c
+++ b/drivers/media/platform/verisilicon/hantro_drv.c
@@ -736,6 +736,7 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_STM32MP25
 	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
+	{ .compatible = "st,stm32mp25-venc", .data = &stm32mp25_venc_variant, },
 #endif
 	{ /* sentinel */ }
 };
diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
index b7eccc1a96fc..70c72e9d11d5 100644
--- a/drivers/media/platform/verisilicon/hantro_hw.h
+++ b/drivers/media/platform/verisilicon/hantro_hw.h
@@ -407,6 +407,7 @@ extern const struct hantro_variant rk3588_vpu981_variant;
 extern const struct hantro_variant sama5d4_vdec_variant;
 extern const struct hantro_variant sunxi_vpu_variant;
 extern const struct hantro_variant stm32mp25_vdec_variant;
+extern const struct hantro_variant stm32mp25_venc_variant;
 
 extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
 extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
diff --git a/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
new file mode 100644
index 000000000000..9d220ff5f1a9
--- /dev/null
+++ b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * STM32MP25 VENC video encoder driver
+ *
+ * Copyright (C) STMicroelectronics SA 2022
+ * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
+ *          for STMicroelectronics.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/reset.h>
+
+#include "hantro.h"
+#include "hantro_jpeg.h"
+#include "hantro_h1_regs.h"
+
+/*
+ * Supported formats.
+ */
+
+static const struct hantro_fmt stm32mp25_venc_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_YUV420M,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420P,
+		.frmsize = {
+			.min_width = 96,
+			.max_width = FMT_4K_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = 96,
+			.max_height = FMT_4K_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_NV12M,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420SP,
+		.frmsize = {
+			.min_width = 96,
+			.max_width = FMT_4K_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = 96,
+			.max_height = FMT_4K_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_YUYV,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUYV422,
+		.frmsize = {
+			.min_width = 96,
+			.max_width = FMT_4K_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = 96,
+			.max_height = FMT_4K_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_UYVY,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_UYVY422,
+		.frmsize = {
+			.min_width = 96,
+			.max_width = FMT_4K_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = 96,
+			.max_height = FMT_4K_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_JPEG,
+		.codec_mode = HANTRO_MODE_JPEG_ENC,
+		.max_depth = 2,
+		.header_size = JPEG_HEADER_SIZE,
+		.frmsize = {
+			.min_width = 96,
+			.max_width = FMT_4K_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = 96,
+			.max_height = FMT_4K_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+};
+
+static irqreturn_t stm32mp25_venc_irq(int irq, void *dev_id)
+{
+	struct hantro_dev *vpu = dev_id;
+	enum vb2_buffer_state state;
+	u32 status;
+
+	status = vepu_read(vpu, H1_REG_INTERRUPT);
+	state = (status & H1_REG_INTERRUPT_FRAME_RDY) ?
+		VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
+
+	vepu_write(vpu, H1_REG_INTERRUPT_BIT, H1_REG_INTERRUPT);
+
+	hantro_irq_done(vpu, state);
+
+	return IRQ_HANDLED;
+}
+
+static void stm32mp25_venc_reset(struct hantro_ctx *ctx)
+{
+}
+
+/*
+ * Supported codec ops.
+ */
+
+static const struct hantro_codec_ops stm32mp25_venc_codec_ops[] = {
+	[HANTRO_MODE_JPEG_ENC] = {
+		.run = hantro_h1_jpeg_enc_run,
+		.reset = stm32mp25_venc_reset,
+		.done = hantro_h1_jpeg_enc_done,
+	},
+};
+
+/*
+ * Variants.
+ */
+
+static const struct hantro_irq stm32mp25_venc_irqs[] = {
+	{ "venc", stm32mp25_venc_irq },
+};
+
+static const char * const stm32mp25_venc_clk_names[] = {
+	"venc-clk"
+};
+
+const struct hantro_variant stm32mp25_venc_variant = {
+	.enc_fmts = stm32mp25_venc_fmts,
+	.num_enc_fmts = ARRAY_SIZE(stm32mp25_venc_fmts),
+	.codec = HANTRO_JPEG_ENCODER,
+	.codec_ops = stm32mp25_venc_codec_ops,
+	.irqs = stm32mp25_venc_irqs,
+	.num_irqs = ARRAY_SIZE(stm32mp25_venc_irqs),
+	.clk_names = stm32mp25_venc_clk_names,
+	.num_clocks = ARRAY_SIZE(stm32mp25_venc_clk_names)
+};
+
-- 
2.25.1



From krzysztof.kozlowski at linaro.org  Wed Dec 20 00:47:21 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 09:47:21 +0100
Subject: [GIT PULL 1/2] samsung: drivers for v6.8
Message-ID: <20231220084722.22149-1-krzysztof.kozlowski@linaro.org>

Hi,

Driver changes needed for Google GS101 SoC, plus usual Samsung SoC driver
updates.

This includes topic branch, see explanation in pull-request/tag.

Best regards,
Krzysztof


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-6.8

for you to fetch changes up to 35f32e39b4d9b436354c2a37623c393a2ac7cf87:

  dt-bindings: clock: google,gs101: rename CMU_TOP gate defines (2023-12-18 09:59:20 +0100)

----------------------------------------------------------------
Samsung SoC driver changes for v6.8

1. Add support for Google GS101 SoC to different drivers: clock
   controller, serial and watchdog.

   The clock driver changes depend on few bindings headers, which I put
   in a topic branch with the bindings refactoring and GS101 support,
   therefore this this pull request includes that bindings topic branch.

   The rest of the bindings topic branch is not necessary here, however
   keeping everything together makes it easier to share between
   branches.  The bindings topic branch is mostly refactoring all the
   compatibles to add SoC-specific compatible followed by fallback.

2. Exynos ChipID: recognize ExynosAutov920.

----------------------------------------------------------------
Jaewon Kim (8):
      soc: samsung: exynos-chipid: add exynosautov920 SoC support
      dt-bindings: samsung: exynos-sysreg: add exynosautov920 sysreg
      dt-bindings: samsung: exynos-pmu: add exynosautov920 compatible
      dt-bindings: samsung: usi: add exynosautov920-usi compatible
      dt-bindings: serial: samsung: add exynosautov920-uart compatible
      dt-bindings: pwm: samsung: add exynosautov920 compatible
      dt-bindings: arm: samsung: Document exynosautov920 SADK board binding
      dt-bindings: hwinfo: samsung,exynos-chipid: add exynosautov920 compatible

Krzysztof Kozlowski (18):
      dt-bindings: hwinfo: samsung,exynos-chipid: add specific compatibles for existing SoC
      dt-bindings: i2c: exynos5: add specific compatibles for existing SoC
      dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for existing SoC
      dt-bindings: mmc: samsung,exynos-dw-mshc: add specific compatibles for existing SoC
      dt-bindings: rtc: s3c-rtc: add specific compatibles for existing SoC
      dt-bindings: serial: samsung: add specific compatibles for existing SoC
      dt-bindings: samsung: exynos-pmu: add specific compatibles for existing SoC
      dt-bindings: gpu: arm,mali-midgard: add specific compatibles for existing Exynos SoC
      dt-bindings: iio: samsung,exynos-adc: add specific compatibles for existing SoC
      ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing SoC
      dt-bindings: pwm: samsung: add specific compatibles for existing SoC
      dt-bindings: i2c: exynos5: add specific compatible for Tesla FSD
      dt-bindings: pwm: samsung: add specific compatible for Tesla FSD
      dt-bindings: serial: samsung: add specific compatible for Tesla FSD
      dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla FSD
      dt-bindings: watchdog: samsung: add specific compatible for Tesla FSD
      dt-bindings: samsung: exynos-sysreg: combine exynosautov920 with other enum
      Merge tag 'samsung-dt-bindings-refactoring-and-google-gs101-6.8' into next/drivers

Peter Griffin (13):
      dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
      dt-bindings: clock: Add Google gs101 clock management unit bindings
      dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101
      dt-bindings: watchdog: Document Google gs101 watchdog bindings
      dt-bindings: serial: samsung: Add google-gs101-uart compatible
      dt-bindings: serial: samsung: Make samsung,uart-fifosize a required property
      dt-bindings: clock: google,gs101: fix incorrect numbering and DGB suffix
      clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
      clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm support
      tty: serial: samsung: Add gs101 compatible and common fifoszdt_serial_drv_data
      watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bit
      watchdog: s3c2410_wdt: Update QUIRK macros to use BIT macro
      watchdog: s3c2410_wdt: Add support for Google gs101 SoC

Tudor Ambarus (2):
      dt-bindings: soc: samsung: usi: add google,gs101-usi compatible
      dt-bindings: clock: google,gs101: rename CMU_TOP gate defines

 .../bindings/arm/samsung/samsung-boards.yaml       |    6 +
 .../bindings/clock/google,gs101-clock.yaml         |  106 +
 .../devicetree/bindings/gpu/arm,mali-midgard.yaml  |    5 +
 .../bindings/hwinfo/samsung,exynos-chipid.yaml     |   18 +-
 .../devicetree/bindings/i2c/i2c-exynos5.yaml       |   11 +-
 .../bindings/i2c/samsung,s3c2410-i2c.yaml          |   22 +-
 .../bindings/iio/adc/samsung,exynos-adc.yaml       |   29 +-
 .../bindings/mfd/samsung,exynos5433-lpass.yaml     |    2 +-
 .../bindings/mmc/samsung,exynos-dw-mshc.yaml       |   25 +-
 .../devicetree/bindings/pwm/pwm-samsung.yaml       |    4 +
 Documentation/devicetree/bindings/rtc/s3c-rtc.yaml |    5 +
 .../devicetree/bindings/serial/samsung_uart.yaml   |   28 +-
 .../bindings/soc/samsung/exynos-pmu.yaml           |   10 +
 .../bindings/soc/samsung/exynos-usi.yaml           |    7 +-
 .../soc/samsung/samsung,exynos-sysreg.yaml         |    5 +
 .../devicetree/bindings/sound/samsung-i2s.yaml     |   19 +-
 .../devicetree/bindings/watchdog/samsung-wdt.yaml  |   29 +-
 drivers/clk/samsung/Makefile                       |    1 +
 drivers/clk/samsung/clk-gs101.c                    | 2518 ++++++++++++++++++++
 drivers/clk/samsung/clk-pll.c                      |    6 +
 drivers/clk/samsung/clk-pll.h                      |    3 +
 drivers/soc/samsung/exynos-chipid.c                |    1 +
 drivers/tty/serial/samsung_tty.c                   |   16 +
 drivers/watchdog/s3c2410_wdt.c                     |   85 +-
 include/dt-bindings/clock/google,gs101.h           |  392 +++
 25 files changed, 3285 insertions(+), 68 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 drivers/clk/samsung/clk-gs101.c
 create mode 100644 include/dt-bindings/clock/google,gs101.h


From krzysztof.kozlowski at linaro.org  Wed Dec 20 00:47:22 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 09:47:22 +0100
Subject: [GIT PULL 2/2] arm64: dts: samsung: DTS for v6.8, part two
In-Reply-To: <20231220084722.22149-1-krzysztof.kozlowski@linaro.org>
References: <20231220084722.22149-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231220084722.22149-2-krzysztof.kozlowski@linaro.org>

Hi,

This is second pull request for arm64 Samsung DTS. Previous (part one):
https://lore.kernel.org/all/20231212093105.13938-1-krzysztof.kozlowski at linaro.org/

I did not receive any notification that you pulled in previous (part one) pull,
thus I attach below two diffs:
A. Against previous pull, tags/samsung-dt64-6.8
B. Against master, v6.7-rc1

This includes topic branch, see explanation in pull-request/tag. Most of the
bindings patches affect DTS, because they include compatible-refactoring.  This
refactoring affects new device support - ExynosAutov920 and Google GS101 -
thus everything comes together.

Best regards,
Krzysztof


The following changes since commit 40af852a7ca59d23ab4afd02af2623121da2f116:

  Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64 (2023-12-11 08:41:24 +0100)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-6.8-2

for you to fetch changes up to d0da0de31e1d50ff905eb8f095628eea666f8c67:

  MAINTAINERS: adjust file entry in GOOGLE TENSOR SoC SUPPORT (2023-12-18 11:15:51 +0100)

----------------------------------------------------------------
Samsung DTS ARM64 changes for v6.8, part two

1. Tesla FSD: Add Multi Format Codec (MFC) device nodes, for accelerated
   video de/encoding.

2. Add initial Google Tensor GS101 SoC support. The GS101 SoC can be
   found on Google Pixel 6 phones.  Currently the DTS brings only basic
   support: core clock controllers, pin controllers, serial, watchdog
   and ARM core blocks.

----------------------------------------------------------------
Aakarsh Jain (1):
      arm64: dts: fsd: Add MFC related DT enteries

Lukas Bulwahn (1):
      MAINTAINERS: adjust file entry in GOOGLE TENSOR SoC SUPPORT

Peter Griffin (4):
      dt-bindings: arm: google: Add bindings for Google ARM platforms
      arm64: dts: exynos: google: Add initial Google gs101 SoC support
      arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
      MAINTAINERS: add entry for Google Tensor SoC

 Documentation/devicetree/bindings/arm/google.yaml  |   53 +
 MAINTAINERS                                        |   10 +
 arch/arm64/boot/dts/exynos/Makefile                |    2 +
 arch/arm64/boot/dts/exynos/google/Makefile         |    4 +
 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts |  105 ++
 .../boot/dts/exynos/google/gs101-pinctrl.dtsi      | 1249 ++++++++++++++++++++
 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h  |   33 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi       |  473 ++++++++
 arch/arm64/boot/dts/tesla/fsd.dtsi                 |   21 +
 9 files changed, 1950 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
 create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi



----------------------------------------------------------------
----------------------------------------------------------------

DIFF against master/v6.7-rc1
----------------------------------------------------------------
The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-6.8-2

for you to fetch changes up to d0da0de31e1d50ff905eb8f095628eea666f8c67:

  MAINTAINERS: adjust file entry in GOOGLE TENSOR SoC SUPPORT (2023-12-18 11:15:51 +0100)

----------------------------------------------------------------
Samsung DTS ARM64 changes for v6.8, part two

1. Tesla FSD: Add Multi Format Codec (MFC) device nodes, for accelerated
   video de/encoding.

2. Add initial Google Tensor GS101 SoC support. The GS101 SoC can be
   found on Google Pixel 6 phones.  Currently the DTS brings only basic
   support: core clock controllers, pin controllers, serial, watchdog
   and ARM core blocks.

----------------------------------------------------------------
Aakarsh Jain (1):
      arm64: dts: fsd: Add MFC related DT enteries

Jaewon Kim (10):
      arm64: dts: exynos: add gpio-key node for exynosautov9-sadk
      dt-bindings: samsung: exynos-sysreg: add exynosautov920 sysreg
      dt-bindings: samsung: exynos-pmu: add exynosautov920 compatible
      dt-bindings: samsung: usi: add exynosautov920-usi compatible
      dt-bindings: serial: samsung: add exynosautov920-uart compatible
      dt-bindings: pwm: samsung: add exynosautov920 compatible
      dt-bindings: arm: samsung: Document exynosautov920 SADK board binding
      dt-bindings: hwinfo: samsung,exynos-chipid: add exynosautov920 compatible
      arm64: dts: exynos: add initial support for exynosautov920 SoC
      arm64: dts: exynos: add minimal support for exynosautov920 sadk board

Krzysztof Kozlowski (28):
      dt-bindings: hwinfo: samsung,exynos-chipid: add specific compatibles for existing SoC
      dt-bindings: i2c: exynos5: add specific compatibles for existing SoC
      dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for existing SoC
      dt-bindings: mmc: samsung,exynos-dw-mshc: add specific compatibles for existing SoC
      dt-bindings: rtc: s3c-rtc: add specific compatibles for existing SoC
      dt-bindings: serial: samsung: add specific compatibles for existing SoC
      dt-bindings: samsung: exynos-pmu: add specific compatibles for existing SoC
      dt-bindings: gpu: arm,mali-midgard: add specific compatibles for existing Exynos SoC
      dt-bindings: iio: samsung,exynos-adc: add specific compatibles for existing SoC
      ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing SoC
      dt-bindings: pwm: samsung: add specific compatibles for existing SoC
      arm64: dts: exynos5433: add specific compatibles to several blocks
      arm64: dts: exynos7: add specific compatibles to several blocks
      arm64: dts: exynos7885: add specific compatibles to several blocks
      arm64: dts: exynos850: add specific compatibles to several blocks
      arm64: dts: exynosautov9: add specific compatibles to several blocks
      Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64
      arm64: dts: exynos850: use Exynos7 fallbacks for pin wake-up controllers
      arm64: dts: exynosautov9: use Exynos7 fallbacks for pin wake-up controller
      dt-bindings: i2c: exynos5: add specific compatible for Tesla FSD
      dt-bindings: pwm: samsung: add specific compatible for Tesla FSD
      dt-bindings: serial: samsung: add specific compatible for Tesla FSD
      dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla FSD
      dt-bindings: watchdog: samsung: add specific compatible for Tesla FSD
      Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64
      arm64: dts: fsd: add specific compatibles for Tesla FSD
      dt-bindings: samsung: exynos-sysreg: combine exynosautov920 with other enum
      Merge branch 'for-v6.8/samsung-bindings-compatibles' into next/dt64

Lukas Bulwahn (1):
      MAINTAINERS: adjust file entry in GOOGLE TENSOR SoC SUPPORT

Peter Griffin (7):
      dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
      dt-bindings: clock: Add Google gs101 clock management unit bindings
      dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101
      dt-bindings: arm: google: Add bindings for Google ARM platforms
      arm64: dts: exynos: google: Add initial Google gs101 SoC support
      arm64: dts: exynos: google: Add initial Oriole/pixel 6 board support
      MAINTAINERS: add entry for Google Tensor SoC

 Documentation/devicetree/bindings/arm/google.yaml  |   53 +
 .../bindings/arm/samsung/samsung-boards.yaml       |    6 +
 .../bindings/clock/google,gs101-clock.yaml         |  106 ++
 .../devicetree/bindings/gpu/arm,mali-midgard.yaml  |    5 +
 .../bindings/hwinfo/samsung,exynos-chipid.yaml     |   18 +-
 .../devicetree/bindings/i2c/i2c-exynos5.yaml       |   11 +-
 .../bindings/i2c/samsung,s3c2410-i2c.yaml          |   22 +-
 .../bindings/iio/adc/samsung,exynos-adc.yaml       |   29 +-
 .../bindings/mfd/samsung,exynos5433-lpass.yaml     |    2 +-
 .../bindings/mmc/samsung,exynos-dw-mshc.yaml       |   25 +-
 .../devicetree/bindings/pwm/pwm-samsung.yaml       |    4 +
 Documentation/devicetree/bindings/rtc/s3c-rtc.yaml |    5 +
 .../devicetree/bindings/serial/samsung_uart.yaml   |   17 +-
 .../bindings/soc/samsung/exynos-pmu.yaml           |   10 +
 .../bindings/soc/samsung/exynos-usi.yaml           |    6 +-
 .../soc/samsung/samsung,exynos-sysreg.yaml         |    5 +
 .../devicetree/bindings/sound/samsung-i2s.yaml     |   19 +-
 .../devicetree/bindings/watchdog/samsung-wdt.yaml  |   21 +-
 MAINTAINERS                                        |   10 +
 arch/arm64/boot/dts/exynos/Makefile                |    5 +-
 arch/arm64/boot/dts/exynos/exynos5433.dtsi         |   60 +-
 arch/arm64/boot/dts/exynos/exynos7.dtsi            |   18 +-
 arch/arm64/boot/dts/exynos/exynos7885.dtsi         |   45 +-
 arch/arm64/boot/dts/exynos/exynos850.dtsi          |   40 +-
 arch/arm64/boot/dts/exynos/exynosautov9-sadk.dts   |   51 +
 arch/arm64/boot/dts/exynos/exynosautov9.dtsi       |   10 +-
 .../boot/dts/exynos/exynosautov920-pinctrl.dtsi    | 1266 ++++++++++++++++++++
 arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts |   88 ++
 arch/arm64/boot/dts/exynos/exynosautov920.dtsi     |  312 +++++
 arch/arm64/boot/dts/exynos/google/Makefile         |    4 +
 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts |  105 ++
 .../boot/dts/exynos/google/gs101-pinctrl.dtsi      | 1249 +++++++++++++++++++
 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h  |   33 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi       |  473 ++++++++
 arch/arm64/boot/dts/tesla/fsd.dtsi                 |   53 +-
 include/dt-bindings/clock/google,gs101.h           |  392 ++++++
 36 files changed, 4444 insertions(+), 134 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
 create mode 100644 arch/arm64/boot/dts/exynos/exynosautov920.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/google/Makefile
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/exynos/google/gs101.dtsi
 create mode 100644 include/dt-bindings/clock/google,gs101.h


From hugues.fruchet at foss.st.com  Wed Dec 20 00:46:41 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 09:46:41 +0100
Subject: [PATCH v3 5/5] arm64: dts: st: add video encoder support to stm32mp255
In-Reply-To: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
References: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220084641.2076428-6-hugues.fruchet@foss.st.com>

Add VENC hardware video encoder support to STM32MP255.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 6 ++++++
 arch/arm64/boot/dts/st/stm32mp255.dtsi | 7 +++++++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 8fc7e9199499..5dd4f3580a60 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -58,6 +58,12 @@ ck_icn_p_vdec: ck-icn-p-vdec {
 			compatible = "fixed-clock";
 			clock-frequency = <200000000>;
 		};
+
+		ck_icn_p_venc: ck-icn-p-venc {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <200000000>;
+		};
 	};
 
 	firmware {
diff --git a/arch/arm64/boot/dts/st/stm32mp255.dtsi b/arch/arm64/boot/dts/st/stm32mp255.dtsi
index aea5096dac3c..17f197c5b22b 100644
--- a/arch/arm64/boot/dts/st/stm32mp255.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp255.dtsi
@@ -14,6 +14,13 @@ vdec: vdec at 480d0000 {
 				interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&ck_icn_p_vdec>;
 			};
+
+			venc: venc at 480e0000 {
+				compatible = "st,stm32mp25-venc";
+				reg = <0x480e0000 0x800>;
+				interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ck_icn_ls_mcu>;
+			};
 		};
 	};
 };
-- 
2.25.1



From quic_taozha at quicinc.com  Wed Dec 20 00:55:10 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Wed, 20 Dec 2023 16:55:10 +0800
Subject: [PATCH v3 2/8] coresight-tpda: Add support to configure CMB
 element
In-Reply-To: <987a101d-043e-4893-89c0-f9fcd46b5aeb@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-3-git-send-email-quic_taozha@quicinc.com>
 <88e51407-344e-4584-8711-29cc014c782b@arm.com>
 <987a101d-043e-4893-89c0-f9fcd46b5aeb@arm.com>
Message-ID: <25fdf817-6993-484a-981b-3974ee400722@quicinc.com>


On 12/19/2023 9:59 PM, Suzuki K Poulose wrote:
> On 18/12/2023 10:27, Suzuki K Poulose wrote:
>> On 21/11/2023 02:24, Tao Zhang wrote:
>>> Read the CMB element size from the device tree. Set the register
>>> bit that controls the CMB element size of the corresponding port.
>>>
>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>>> ---
>>> ? drivers/hwtracing/coresight/coresight-tpda.c | 117 
>>> +++++++++++--------
>>> ? drivers/hwtracing/coresight/coresight-tpda.h |?? 6 +
>>> ? 2 files changed, 74 insertions(+), 49 deletions(-)
>>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c 
>>> b/drivers/hwtracing/coresight/coresight-tpda.c
>>> index 5f82737c37bb..e3762f38abb3 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpda.c
>>> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
>>> @@ -28,24 +28,54 @@ static bool coresight_device_is_tpdm(struct 
>>> coresight_device *csdev)
>>> ????????????? CORESIGHT_DEV_SUBTYPE_SOURCE_TPDM);
>>> ? }
>>> +static void tpdm_clear_element_size(struct coresight_device *csdev)
>>> +{
>>> +??? struct tpda_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>>> +
>>> +??? if (drvdata->dsb_esize)
>>> +??????? drvdata->dsb_esize = 0;
>>> +??? if (drvdata->cmb_esize)
>>> +??????? drvdata->cmb_esize = 0;
>>
>> Why do we need the if (...) check here ?
>>
>>> +}
>>> +
>>> +static void tpda_set_element_size(struct tpda_drvdata *drvdata, u32 
>>> *val)
>>> +{
>>> +
>>> +??? if (drvdata->dsb_esize == 64)
>>> +??????? *val |= TPDA_Pn_CR_DSBSIZE;
>>> +??? else if (drvdata->dsb_esize == 32)
>>> +??????? *val &= ~TPDA_Pn_CR_DSBSIZE;
>>> +
>>> +??? if (drvdata->cmb_esize == 64)
>>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x2);
>>> +??? else if (drvdata->cmb_esize == 32)
>>> +??????? *val |= FIELD_PREP(TPDA_Pn_CR_CMBSIZE, 0x1);
>>> +??? else if (drvdata->cmb_esize == 8)
>>> +??????? *val &= ~TPDA_Pn_CR_CMBSIZE;
>>> +}
>>> +
>>
>>
>>> ? /*
>>> - * Read the DSB element size from the TPDM device
>>> + * Read the element size from the TPDM device
>>> ?? * Returns
>>> - *??? The dsb element size read from the devicetree if available.
>>> + *??? The element size read from the devicetree if available.
>>> ?? *??? 0 - Otherwise, with a warning once.
>>
>> This doesn't match the function ? It return 0 on success and
>> error (-EINVAL) on failure ?
>>
>>> ?? */
>>> -static int tpdm_read_dsb_element_size(struct coresight_device *csdev)
>>> +static int tpdm_read_element_size(struct tpda_drvdata *drvdata,
>>> +????????????????? struct coresight_device *csdev)
>>> ? {
>>> -??? int rc = 0;
>>> -??? u8 size = 0;
>>> -
>>> -??? rc = fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>> -??????????? "qcom,dsb-element-size", &size);
>>> +??? int rc = -EINVAL;
>>> +
>>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>> +??????????? "qcom,dsb-element-size", &drvdata->dsb_esize))
>>> +??????? rc = 0;
>>> +??? if (!fwnode_property_read_u8(dev_fwnode(csdev->dev.parent),
>>> +??????????? "qcom,cmb-element-size", &drvdata->cmb_esize))
>
> At this point we have the csdev->dev.parent as the TPDM device and with:
>
> #include <coresight-tpdm.h>
>
> ????struct tpdm_drvdata *tpdm_data = get_drvdata(csdev->dev.parent);
>
> ????if (tpdm_has_cmb(tpdm_data)) {
> ??????? rc = fwnode_...(... "qcom,cmb-element-size"...)
> ????}
>
> ????if (tpdm_has_dsb(tpdm_data)) {
> ??????? rc = fwnode_...(..., "qcom,dsb-element-size"..)
> ????}

I will update according to your approach in the next patch series.


Best,

Tao

>
> Suzuki
>
>
>>> +??????? rc = 0;
>>
>> Are we not silently resetting the error if the former failed ?
>>
>> Could we not :
>>
>> ?????rc |= fwnode_...
>>
>> ?????rc |= fwnode_...
>>
>> instead ?
>>
>> Also what is the expectation here ? Are these properties a MUST for
>> TPDM ?
>>
>>> ????? if (rc)
>>> ????????? dev_warn_once(&csdev->dev,
>>> -??????????? "Failed to read TPDM DSB Element size: %d\n", rc);
>>> +??????????? "Failed to read TPDM Element size: %d\n", rc);
>>> -??? return size;
>>> +??? return rc;
>>> ? }
>>> ? /*
>>> @@ -56,11 +86,12 @@ static int tpdm_read_dsb_element_size(struct 
>>> coresight_device *csdev)
>>> ?? * Parameter "inport" is used to pass in the input port number
>>> ?? * of TPDA, and it is set to -1 in the recursize call.
>>> ?? */
>>> -static int tpda_get_element_size(struct coresight_device *csdev,
>>> +static int tpda_get_element_size(struct tpda_drvdata *drvdata,
>>> +???????????????? struct coresight_device *csdev,
>>> ?????????????????? int inport)
>>> ? {
>>> -??? int dsb_size = -ENOENT;
>>> -??? int i, size;
>>> +??? int rc = 0;
>>> +??? int i;
>>> ????? struct coresight_device *in;
>>> ????? for (i = 0; i < csdev->pdata->nr_inconns; i++) {
>>> @@ -74,25 +105,21 @@ static int tpda_get_element_size(struct 
>>> coresight_device *csdev,
>>> ????????????? continue;
>>> ????????? if (coresight_device_is_tpdm(in)) {
>>> -??????????? size = tpdm_read_dsb_element_size(in);
>>> +??????????? if ((drvdata->dsb_esize) || (drvdata->cmb_esize))
>>> +??????????????? return -EEXIST;
>>> +??????????? rc = tpdm_read_element_size(drvdata, in);
>>> +??????????? if (rc)
>>> +??????????????? return rc;
>>> ????????? } else {
>>> ????????????? /* Recurse down the path */
>>> -??????????? size = tpda_get_element_size(in, -1);
>>> -??????? }
>>> -
>>> -??????? if (size < 0)
>>> -??????????? return size;
>>> -
>>> -??????? if (dsb_size < 0) {
>>> -??????????? /* Found a size, save it. */
>>> -??????????? dsb_size = size;
>>> -??????? } else {
>>> -??????????? /* Found duplicate TPDMs */
>>> -??????????? return -EEXIST;
>>> +??????????? rc = tpda_get_element_size(drvdata, in, -1);
>>> +??????????? if (rc)
>>> +??????????????? return rc;
>>> ????????? }
>>> ????? }
>>> -??? return dsb_size;
>>> +
>>> +??? return rc;
>>> ? }
>>> ? /* Settings pre enabling port control register */
>>> @@ -109,7 +136,7 @@ static void tpda_enable_pre_port(struct 
>>> tpda_drvdata *drvdata)
>>> ? static int tpda_enable_port(struct tpda_drvdata *drvdata, int port)
>>> ? {
>>> ????? u32 val;
>>> -??? int size;
>>> +??? int rc;
>>> ????? val = readl_relaxed(drvdata->base + TPDA_Pn_CR(port));
>>> ????? /*
>>> @@ -117,29 +144,21 @@ static int tpda_enable_port(struct 
>>> tpda_drvdata *drvdata, int port)
>>> ?????? * Set the bit to 0 if the size is 32
>>> ?????? * Set the bit to 1 if the size is 64
>>> ?????? */
>>> -??? size = tpda_get_element_size(drvdata->csdev, port);
>>> -??? switch (size) {
>>> -??? case 32:
>>> -??????? val &= ~TPDA_Pn_CR_DSBSIZE;
>>> -??????? break;
>>> -??? case 64:
>>> -??????? val |= TPDA_Pn_CR_DSBSIZE;
>>> -??????? break;
>>> -??? case 0:
>>> -??????? return -EEXIST;
>>> -??? case -EEXIST:
>>> +??? tpdm_clear_element_size(drvdata->csdev);
>>> +??? rc = tpda_get_element_size(drvdata, drvdata->csdev, port);
>>> +??? if (!rc && ((drvdata->dsb_esize) || (drvdata->cmb_esize))) {
>>> +??????? tpda_set_element_size(drvdata, &val);
>>> +??????? /* Enable the port */
>>> +??????? val |= TPDA_Pn_CR_ENA;
>>> +??????? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>>> +??? } else if (rc == -EEXIST)
>>> ????????? dev_warn_once(&drvdata->csdev->dev,
>>> -??????????? "Detected multiple TPDMs on port %d", -EEXIST);
>>> -??????? return -EEXIST;
>>> -??? default:
>>> -??????? return -EINVAL;
>>> -??? }
>>> -
>>> -??? /* Enable the port */
>>> -??? val |= TPDA_Pn_CR_ENA;
>>> -??? writel_relaxed(val, drvdata->base + TPDA_Pn_CR(port));
>>> +????????????????? "Detected multiple TPDMs on port %d", -EEXIST);
>>> +??? else
>>> +??????? dev_warn_once(&drvdata->csdev->dev,
>>> +????????????????? "Didn't find TPDM elem size");
>>
>> "element size"
>>
>>> -??? return 0;
>>> +??? return rc;
>>> ? }
>>> ? static int __tpda_enable(struct tpda_drvdata *drvdata, int port)
>>> diff --git a/drivers/hwtracing/coresight/coresight-tpda.h 
>>> b/drivers/hwtracing/coresight/coresight-tpda.h
>>> index b3b38fd41b64..29164fd9711f 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tpda.h
>>> +++ b/drivers/hwtracing/coresight/coresight-tpda.h
>>> @@ -10,6 +10,8 @@
>>> ? #define TPDA_Pn_CR(n)??????? (0x004 + (n * 4))
>>> ? /* Aggregator port enable bit */
>>> ? #define TPDA_Pn_CR_ENA??????? BIT(0)
>>> +/* Aggregator port CMB data set element size bit */
>>> +#define TPDA_Pn_CR_CMBSIZE??????? GENMASK(7, 6)
>>> ? /* Aggregator port DSB data set element size bit */
>>> ? #define TPDA_Pn_CR_DSBSIZE??????? BIT(8)
>>> @@ -25,6 +27,8 @@
>>> ?? * @csdev:????? component vitals needed by the framework.
>>> ?? * @spinlock:?? lock for the drvdata value.
>>> ?? * @enable:???? enable status of the component.
>>> + * @dsb_esize?? Record the DSB element size.
>>> + * @cmb_esize?? Record the CMB element size.
>>> ?? */
>>> ? struct tpda_drvdata {
>>> ????? void __iomem??????? *base;
>>> @@ -32,6 +36,8 @@ struct tpda_drvdata {
>>> ????? struct coresight_device??? *csdev;
>>> ????? spinlock_t??????? spinlock;
>>> ????? u8??????????? atid;
>>> +??? u8??????????? dsb_esize;
>>> +??? u8??????????? cmb_esize;
>>> ? };
>>> ? #endif? /* _CORESIGHT_CORESIGHT_TPDA_H */
>>
>> Suzuki
>>
>>
>


From quic_taozha at quicinc.com  Wed Dec 20 00:56:42 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Wed, 20 Dec 2023 16:56:42 +0800
Subject: [PATCH v3 3/8] coresight-tpdm: Add CMB dataset support
In-Reply-To: <df433a15-2698-4e1f-9d15-db52befb7541@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-4-git-send-email-quic_taozha@quicinc.com>
 <f4ed3577-f78b-4b78-b306-8284ccb96043@arm.com>
 <8dcafd9a-ff90-439a-9337-fb957d2fcad1@quicinc.com>
 <df433a15-2698-4e1f-9d15-db52befb7541@arm.com>
Message-ID: <0d4e2aa7-23e3-4851-bc43-80e7737f3a1a@quicinc.com>


On 12/19/2023 9:56 PM, Suzuki K Poulose wrote:
> On 19/12/2023 09:22, Tao Zhang wrote:
>>
>> On 12/18/2023 6:34 PM, Suzuki K Poulose wrote:
>>> On 21/11/2023 02:24, Tao Zhang wrote:
>>>> CMB (continuous multi-bit) is one of TPDM's dataset type. CMB subunit
>>>> can be enabled for data collection by writing 1 to the first bit of
>>>> CMB_CR register. This change is to add enable/disable function for
>>>> CMB dataset by writing CMB_CR register.
>>>>
>>>> Reviewed-by: James Clark <james.clark at arm.com>
>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
>>>> ---
>>>> ? drivers/hwtracing/coresight/coresight-tpdm.c | 31 
>>>> ++++++++++++++++++++
>>>> ? drivers/hwtracing/coresight/coresight-tpdm.h |? 8 +++++
>>>> ? 2 files changed, 39 insertions(+)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>>>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> index 97654aa4b772..c8bb38822e08 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> @@ -131,6 +131,11 @@ static bool tpdm_has_dsb_dataset(struct 
>>>> tpdm_drvdata *drvdata)
>>>> ????? return (drvdata->datasets & TPDM_PIDR0_DS_DSB);
>>>> ? }
>>>> ? +static bool tpdm_has_cmb_dataset(struct tpdm_drvdata *drvdata)
>>>> +{
>>>> +??? return (drvdata->datasets & TPDM_PIDR0_DS_CMB);
>>>> +}
>>>> +
>>>> ? static umode_t tpdm_dsb_is_visible(struct kobject *kobj,
>>>> ???????????????????? struct attribute *attr, int n)
>>>> ? {
>>>> @@ -267,6 +272,17 @@ static void tpdm_enable_dsb(struct 
>>>> tpdm_drvdata *drvdata)
>>>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>>>> ? }
>>>> ? +static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>>>> +{
>>>> +??? u32 val;
>>>> +
>>>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>>> +??? val |= TPDM_CMB_CR_ENA;
>>>> +
>>>> +??? /* Set the enable bit of CMB control register to 1 */
>>>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
>>>> +}
>>>> +
>>>> ? /*
>>>> ?? * TPDM enable operations
>>>> ?? * The TPDM or Monitor serves as data collection component for 
>>>> various
>>>> @@ -281,6 +297,8 @@ static void __tpdm_enable(struct tpdm_drvdata 
>>>> *drvdata)
>>>> ? ????? if (tpdm_has_dsb_dataset(drvdata))
>>>> ????????? tpdm_enable_dsb(drvdata);
>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>> +??????? tpdm_enable_cmb(drvdata);
>>>
>>> Don't we need to add this check in the "property read" section ?
>>> Otherwise, we could generate warnings unnecessarily ?
>>>
>>> i.e, if (tpdm_has_cmb_..())
>>> ????? rc |= fwnode_..read_property(cmb-elem-size...)
>>>
>>> Similarly for DSB.
>>
>> TPDM and TPDA are two independent hardware. If you want to modify 
>> them in this way, the
>>
>
> You don't have to, as long as the header files are included ?
>
> Read my response in the other patch, where it applies.

Got it. I will update in the next patch series.


Best,

Tao

>
> Suzuki
>
>> two independent drivers will be coupled to each other. At the same 
>> time, this configuration
>>
>> is manually set in the devicetree by the users, and this check cannot 
>> avoid manual setting errors.
>>
>> ??Even if the configuration is wrong, it will not cause the driver to 
>> stop working, it will only cause
>>
>> the data to be lost from the TPDM.
>>
>>>
>>>> ????? CS_LOCK(drvdata->base);
>>>> ? }
>>>> @@ -314,6 +332,17 @@ static void tpdm_disable_dsb(struct 
>>>> tpdm_drvdata *drvdata)
>>>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>>>> ? }
>>>> ? +static void tpdm_disable_cmb(struct tpdm_drvdata *drvdata)
>>>> +{
>>>> +??? u32 val;
>>>> +
>>>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>>> +??? val &= ~TPDM_CMB_CR_ENA;
>>>> +
>>>> +??? /* Set the enable bit of CMB control register to 0 */
>>>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
>>>> +}
>>>> +
>>>> ? /* TPDM disable operations */
>>>> ? static void __tpdm_disable(struct tpdm_drvdata *drvdata)
>>>> ? {
>>>> @@ -321,6 +350,8 @@ static void __tpdm_disable(struct tpdm_drvdata 
>>>> *drvdata)
>>>> ? ????? if (tpdm_has_dsb_dataset(drvdata))
>>>> ????????? tpdm_disable_dsb(drvdata);
>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>> +??????? tpdm_disable_cmb(drvdata);
>>>
>>> minor nit: Instead of having these :
>>>
>>> ????if (tpdm_has_XY_()
>>> ??????? tpdm_{enable/disable}_XY_()
>>> I prefer :
>>>
>>> ????tpdm_{enable/disable}_XY_
>>>
>>> and the helper take care of returning early if the feature is
>>> not present.
>> Does the following sample modification meet your expectation?
>> static void tpdm_disable_dsb(struct tpdm_drvdata *drvdata)
>> {
>> ??? ?u32 val;
>>
>> ??? ?if (tpdm_has_dsb_dataset(drvdata)) {
>> ??? ???? /* Set the enable bit of DSB control register to 0 */
>> ??? ???? val = readl_relaxed(drvdata->base + TPDM_DSB_CR);
>> ??? ???? val &= ~TPDM_DSB_CR_ENA;
>> ??? ???? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>> ??? ?}
>> }
>>
>> static void tpdm_disable_cmb(struct tpdm_drvdata *drvdata)
>> {
>> ??? ?u32 val;
>>
>> ??? ?if (tpdm_has_cmb_dataset(drvdata)) {
>> ??? ???? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>> ??? ???? val &= ~TPDM_CMB_CR_ENA;
>>
>> ??? ???? /* Set the enable bit of CMB control register to 0 */
>> ??? ???? writel_relaxed(val, drvdata->base + TPDM_CMB_CR);
>> ??? ?}
>> }
>>
>> /* TPDM disable operations */
>> static void __tpdm_disable(struct tpdm_drvdata *drvdata)
>> {
>> ??? ?CS_UNLOCK(drvdata->base);
>>
>> ??? ?tpdm_disable_dsb(drvdata);
>> ??? ?tpdm_disable_cmb(drvdata);
>>
>
> Yes, thats exactly I was looking for.

Got it. I will update in the next patch series.


Best,

Tao

>
>> ??? ?CS_LOCK(drvdata->base);
>>
>> }
>>
>>
>> Best,
>>
>> Tao
>>
>>>
>>>
>>> Suzuki
>>>
>>>
>>>> ? ????? CS_LOCK(drvdata->base);
>>>> ? }
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>>>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> index 4115b2a17b8d..0098c58dfdd6 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> @@ -9,6 +9,12 @@
>>>> ? /* The max number of the datasets that TPDM supports */
>>>> ? #define TPDM_DATASETS?????? 7
>>>> ? +/* CMB Subunit Registers */
>>>> +#define TPDM_CMB_CR??????? (0xA00)
>>>> +
>>>> +/* Enable bit for CMB subunit */
>>>> +#define TPDM_CMB_CR_ENA??????? BIT(0)
>>>> +
>>>> ? /* DSB Subunit Registers */
>>>> ? #define TPDM_DSB_CR??????? (0x780)
>>>> ? #define TPDM_DSB_TIER??????? (0x784)
>>>> @@ -79,10 +85,12 @@
>>>> ?? *
>>>> ?? * PERIPHIDR0[0] : Fix to 1 if ImplDef subunit present, else 0
>>>> ?? * PERIPHIDR0[1] : Fix to 1 if DSB subunit present, else 0
>>>> + * PERIPHIDR0[2] : Fix to 1 if CMB subunit present, else 0
>>>> ?? */
>>>> ? ? #define TPDM_PIDR0_DS_IMPDEF??? BIT(0)
>>>> ? #define TPDM_PIDR0_DS_DSB??? BIT(1)
>>>> +#define TPDM_PIDR0_DS_CMB??? BIT(2)
>>>> ? ? #define TPDM_DSB_MAX_LINES??? 256
>>>> ? /* MAX number of EDCR registers */
>>>
>


From maz at kernel.org  Wed Dec 20 01:00:48 2023
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 20 Dec 2023 09:00:48 +0000
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us
 in arch timer test
In-Reply-To: <CAJve8onc0WN5g98aOVBmJx15wFBAqfBKJ+ufoLY+oqYyVL+=3A@mail.gmail.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
 <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
 <8734vy832j.wl-maz@kernel.org>
 <CAJve8onc0WN5g98aOVBmJx15wFBAqfBKJ+ufoLY+oqYyVL+=3A@mail.gmail.com>
Message-ID: <f98879dc24f948f7a8a7b5374a32bc04@kernel.org>

On 2023-12-20 06:50, Haibo Xu wrote:
> On Wed, Dec 20, 2023 at 2:22?AM Marc Zyngier <maz at kernel.org> wrote:
>> 
>> On Tue, 12 Dec 2023 09:31:20 +0000,
>> Haibo Xu <haibo1.xu at intel.com> wrote:
>> > > @@ -216,6 +221,9 @@ static bool parse_args(int argc, char *argv[])
>> >               case 'm':
>> >                       test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
>> >                       break;
>> > +             case 'e':
>> > +                     test_args.timer_err_margin_us = atoi_non_negative("Error Margin", optarg);
>> > +                     break;
>> 
>> So your error margin is always unsigned...
>> 
> 
> The error margin was supposed to be a non-negative [0, INT_MAX].
> (May be need to define a Max for the input, instead of INT_MAX)
> 
>> >               case 'o':
>> >                       test_args.counter_offset = strtol(optarg, NULL, 0);
>> >                       test_args.reserved = 0;
>> > diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
>> > index 968257b893a7..b1d405e7157d 100644
>> > --- a/tools/testing/selftests/kvm/include/timer_test.h
>> > +++ b/tools/testing/selftests/kvm/include/timer_test.h
>> > @@ -22,6 +22,7 @@ struct test_args {
>> >       int nr_iter;
>> >       int timer_period_ms;
>> >       int migration_freq_ms;
>> > +     int timer_err_margin_us;
>> 
>> ... except that you are storing it as a signed value. Some consistency
>> wouldn't hurt, really, and would avoid issues when passing large
>> values.
>> 
> 
> Yes, it's more proper to use an unsigned int for the non-negative error 
> margin.
> Storing as signed here is just to keep the type consistent with that
> of timer_period_ms
> since there will be '+' operation in other places.
> 
>         tools/testing/selftests/kvm/aarch64/arch_timer.c
>         /* Setup a timeout for the interrupt to arrive */
>          udelay(msecs_to_usecs(test_args.timer_period_ms) +
>              test_args.timer_err_margin_us);

But that's exactly why using a signed quantity is wrong.
What does it mean to have a huge *negative* margin?

I don't see how you can justify this.

         M.
-- 
Jazz is not dead. It just smells funny...


From quic_taozha at quicinc.com  Wed Dec 20 01:06:54 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Wed, 20 Dec 2023 17:06:54 +0800
Subject: [PATCH v3 8/8] coresight-tpdm: Add msr register support for CMB
In-Reply-To: <d8262a32-cc3c-4889-a5f0-a6b128b7e9d6@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-9-git-send-email-quic_taozha@quicinc.com>
 <185b23e7-a42f-4a12-85ba-8a093bc5ea58@arm.com>
 <4409f3cf-7ca9-407f-92c0-5aa7ba6f7b61@quicinc.com>
 <d8262a32-cc3c-4889-a5f0-a6b128b7e9d6@arm.com>
Message-ID: <3e27b0e2-afb2-4706-9996-f567e33e35ba@quicinc.com>


On 12/19/2023 10:09 PM, Suzuki K Poulose wrote:
> On 19/12/2023 06:58, Tao Zhang wrote:
>>
>> On 12/18/2023 7:02 PM, Suzuki K Poulose wrote:
>>> On 21/11/2023 02:24, Tao Zhang wrote:
>>>> Add the nodes for CMB subunit MSR(mux select register) support.
>>>> CMB MSRs(mux select registers) is to separate mux,arbitration,
>>>> ,interleaving,data packing control from stream filtering control.
>>>>
>>>> Reviewed-by: James Clark <james.clark at arm.com>
>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
>>>> ---
>>>> ? .../testing/sysfs-bus-coresight-devices-tpdm? |? 8 ++
>>>> ? drivers/hwtracing/coresight/coresight-tpdm.c? | 86 
>>>> +++++++++++++++++++
>>>> ? drivers/hwtracing/coresight/coresight-tpdm.h? | 16 +++-
>>>> ? 3 files changed, 109 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git 
>>>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm 
>>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>> index e0b77107be13..914f3fd81525 100644
>>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>> @@ -249,3 +249,11 @@ Description:
>>>> ????????? Accepts only one of the 2 values -? 0 or 1.
>>>> ????????? 0 : Disable the timestamp of all trace packets.
>>>> ????????? 1 : Enable the timestamp of all trace packets.
>>>> +
>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31]
>>>> +Date:??????? September 2023
>>>> +KernelVersion??? 6.7
>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>> +Description:
>>>> +??????? (RW) Set/Get the MSR(mux select register) for the CMB subunit
>>>> +??????? TPDM.
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>>>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> index f6cda5616e84..7e331ea436cc 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> @@ -86,6 +86,11 @@ static ssize_t tpdm_simple_dataset_show(struct 
>>>> device *dev,
>>>> ????????????? return -EINVAL;
>>>> ????????? return sysfs_emit(buf, "0x%x\n",
>>>> drvdata->cmb->patt_mask[tpdm_attr->idx]);
>>>> +??? case CMB_MSR:
>>>> +??????? if (tpdm_attr->idx >= drvdata->cmb_msr_num)
>>>> +??????????? return -EINVAL;
>>>> +??????? return sysfs_emit(buf, "0x%x\n",
>>>> + drvdata->cmb->msr[tpdm_attr->idx]);
>>>> ????? }
>>>> ????? return -EINVAL;
>>>> ? }
>>>> @@ -162,6 +167,12 @@ static ssize_t 
>>>> tpdm_simple_dataset_store(struct device *dev,
>>>> ????????? else
>>>> ????????????? ret = -EINVAL;
>>>> ????????? break;
>>>> +??? case CMB_MSR:
>>>> +??????? if (tpdm_attr->idx < drvdata->cmb_msr_num)
>>>> +??????????? drvdata->cmb->msr[tpdm_attr->idx] = val;
>>>> +??????? else
>>>> +??????????? ret = -EINVAL;
>>>
>>>
>>> minor nit: Could we not break from here instead of adding return 
>>> -EINVAL
>>> for each case ? (I understand it has been done for the existing cases.
>>> But I think we should clean up all of that, including the ones you 
>>> added
>>> in Patch 5. Similarly for the dataset_show()
>>
>> Sure, do I also need to change the DSB corresponding code? If so, how 
>> about
>>
>> if I add a new patch to the next patch series to change the previous 
>> existing cases?
>
> You could fix the existing cases as a preparatory patch of the next 
> version of this series. I can pick it up and push it to next as I see 
> fit.

Got it. I will update this to the next patch series.


Best,

Tao

>
> Suzuki
>
>
>>
>>
>> Best,
>>
>> Tao
>>
>>>
>>>
>>> Suzuki
>>>
>>>
>>>> +??????? break;
>>>> ????? default:
>>>> ????????? ret = -EINVAL;
>>>> ????? }
>>>> @@ -220,6 +231,23 @@ static umode_t tpdm_dsb_msr_is_visible(struct 
>>>> kobject *kobj,
>>>> ????? return 0;
>>>> ? }
>>>> ? +static umode_t tpdm_cmb_msr_is_visible(struct kobject *kobj,
>>>> +?????????????????????? struct attribute *attr, int n)
>>>> +{
>>>> +??? struct device *dev = kobj_to_dev(kobj);
>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>> +
>>>> +??? struct device_attribute *dev_attr =
>>>> +??????? container_of(attr, struct device_attribute, attr);
>>>> +??? struct tpdm_dataset_attribute *tpdm_attr =
>>>> +??????? container_of(dev_attr, struct tpdm_dataset_attribute, attr);
>>>> +
>>>> +??? if (tpdm_attr->idx < drvdata->cmb_msr_num)
>>>> +??????? return attr->mode;
>>>> +
>>>> +??? return 0;
>>>> +}
>>>> +
>>>> ? static void tpdm_reset_datasets(struct tpdm_drvdata *drvdata)
>>>> ? {
>>>> ????? if (tpdm_has_dsb_dataset(drvdata)) {
>>>> @@ -361,6 +389,15 @@ static void set_cmb_tier(struct tpdm_drvdata 
>>>> *drvdata)
>>>> ????? writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>>>> ? }
>>>> ? +static void set_cmb_msr(struct tpdm_drvdata *drvdata)
>>>> +{
>>>> +??? int i;
>>>> +
>>>> +??? for (i = 0; i < drvdata->cmb_msr_num; i++)
>>>> +??????? writel_relaxed(drvdata->cmb->msr[i],
>>>> +?????????????? drvdata->base + TPDM_CMB_MSR(i));
>>>> +}
>>>> +
>>>> ? static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>>>> ? {
>>>> ????? u32 val, i;
>>>> @@ -379,6 +416,8 @@ static void tpdm_enable_cmb(struct tpdm_drvdata 
>>>> *drvdata)
>>>> ? ????? set_cmb_tier(drvdata);
>>>> ? +??? set_cmb_msr(drvdata);
>>>> +
>>>> ????? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>>> ????? /*
>>>> ?????? * Set to 0 for continuous CMB collection mode,
>>>> @@ -1084,6 +1123,42 @@ static struct attribute 
>>>> *tpdm_cmb_patt_attrs[] = {
>>>> ????? NULL,
>>>> ? };
>>>> ? +static struct attribute *tpdm_cmb_msr_attrs[] = {
>>>> +??? CMB_MSR_ATTR(0),
>>>> +??? CMB_MSR_ATTR(1),
>>>> +??? CMB_MSR_ATTR(2),
>>>> +??? CMB_MSR_ATTR(3),
>>>> +??? CMB_MSR_ATTR(4),
>>>> +??? CMB_MSR_ATTR(5),
>>>> +??? CMB_MSR_ATTR(6),
>>>> +??? CMB_MSR_ATTR(7),
>>>> +??? CMB_MSR_ATTR(8),
>>>> +??? CMB_MSR_ATTR(9),
>>>> +??? CMB_MSR_ATTR(10),
>>>> +??? CMB_MSR_ATTR(11),
>>>> +??? CMB_MSR_ATTR(12),
>>>> +??? CMB_MSR_ATTR(13),
>>>> +??? CMB_MSR_ATTR(14),
>>>> +??? CMB_MSR_ATTR(15),
>>>> +??? CMB_MSR_ATTR(16),
>>>> +??? CMB_MSR_ATTR(17),
>>>> +??? CMB_MSR_ATTR(18),
>>>> +??? CMB_MSR_ATTR(19),
>>>> +??? CMB_MSR_ATTR(20),
>>>> +??? CMB_MSR_ATTR(21),
>>>> +??? CMB_MSR_ATTR(22),
>>>> +??? CMB_MSR_ATTR(23),
>>>> +??? CMB_MSR_ATTR(24),
>>>> +??? CMB_MSR_ATTR(25),
>>>> +??? CMB_MSR_ATTR(26),
>>>> +??? CMB_MSR_ATTR(27),
>>>> +??? CMB_MSR_ATTR(28),
>>>> +??? CMB_MSR_ATTR(29),
>>>> +??? CMB_MSR_ATTR(30),
>>>> +??? CMB_MSR_ATTR(31),
>>>> +??? NULL,
>>>> +};
>>>> +
>>>> ? static struct attribute *tpdm_dsb_attrs[] = {
>>>> ????? &dev_attr_dsb_mode.attr,
>>>> ????? &dev_attr_dsb_trig_ts.attr,
>>>> @@ -1144,6 +1219,12 @@ static struct attribute_group 
>>>> tpdm_cmb_patt_grp = {
>>>> ????? .name = "cmb_patt",
>>>> ? };
>>>> ? +static struct attribute_group tpdm_cmb_msr_grp = {
>>>> +??? .attrs = tpdm_cmb_msr_attrs,
>>>> +??? .is_visible = tpdm_cmb_msr_is_visible,
>>>> +??? .name = "cmb_msr",
>>>> +};
>>>> +
>>>> ? static const struct attribute_group *tpdm_attr_grps[] = {
>>>> ????? &tpdm_attr_grp,
>>>> ????? &tpdm_dsb_attr_grp,
>>>> @@ -1154,6 +1235,7 @@ static const struct attribute_group 
>>>> *tpdm_attr_grps[] = {
>>>> ????? &tpdm_cmb_attr_grp,
>>>> ????? &tpdm_cmb_trig_patt_grp,
>>>> ????? &tpdm_cmb_patt_grp,
>>>> +??? &tpdm_cmb_msr_grp,
>>>> ????? NULL,
>>>> ? };
>>>> ? @@ -1192,6 +1274,10 @@ static int tpdm_probe(struct amba_device 
>>>> *adev, const struct amba_id *id)
>>>> ????????? of_property_read_u32(drvdata->dev->of_node,
>>>> ???????????????? "qcom,dsb-msrs-num", &drvdata->dsb_msr_num);
>>>> ? +??? if (drvdata && tpdm_has_cmb_dataset(drvdata))
>>>> +??????? of_property_read_u32(drvdata->dev->of_node,
>>>> +?????????????? "qcom,cmb-msrs-num", &drvdata->cmb_msr_num);
>>>> +
>>>> ????? /* Set up coresight component description */
>>>> ????? desc.name = coresight_alloc_device_name(&tpdm_devs, dev);
>>>> ????? if (!desc.name)
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>>>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> index 65b7ca6c4077..255104d024ab 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> @@ -21,6 +21,8 @@
>>>> ? #define TPDM_CMB_XPR(n)??????? (0xA18 + (n * 4))
>>>> ? /*CMB subunit trigger pattern mask registers*/
>>>> ? #define TPDM_CMB_XPMR(n)??? (0xA20 + (n * 4))
>>>> +/* CMB MSR register */
>>>> +#define TPDM_CMB_MSR(n)??????? (0xA80 + (n * 4))
>>>> ? ? /* Enable bit for CMB subunit */
>>>> ? #define TPDM_CMB_CR_ENA??????? BIT(0)
>>>> @@ -36,6 +38,9 @@
>>>> ? /*Patten register number*/
>>>> ? #define TPDM_CMB_MAX_PATT??????? 2
>>>> ? +/* MAX number of DSB MSR */
>>>> +#define TPDM_CMB_MAX_MSR 32
>>>> +
>>>> ? /* DSB Subunit Registers */
>>>> ? #define TPDM_DSB_CR??????? (0x780)
>>>> ? #define TPDM_DSB_TIER??????? (0x784)
>>>> @@ -186,6 +191,10 @@
>>>> ????????? tpdm_simple_dataset_rw(tpmr##nr,??????? \
>>>> ????????? CMB_PATT_MASK, nr)
>>>> ? +#define CMB_MSR_ATTR(nr)??????????????????? \
>>>> +??????? tpdm_simple_dataset_rw(msr##nr,??????????? \
>>>> +??????? CMB_MSR, nr)
>>>> +
>>>> ? /**
>>>> ?? * struct dsb_dataset - specifics associated to dsb dataset
>>>> ?? * @mode:???????????? DSB programming mode
>>>> @@ -225,6 +234,7 @@ struct dsb_dataset {
>>>> ?? * @patt_mask:??????? Save value for pattern mask
>>>> ?? * @trig_patt:??????? Save value for trigger pattern
>>>> ?? * @trig_patt_mask:?? Save value for trigger pattern mask
>>>> + * @msr?????????????? Save value for MSR
>>>> ?? * @patt_ts:????????? Indicates if pattern match for timestamp is 
>>>> enabled.
>>>> ?? * @trig_ts:????????? Indicates if CTI trigger for timestamp is 
>>>> enabled.
>>>> ?? * @ts_all:?????????? Indicates if timestamp is enabled for all 
>>>> packets.
>>>> @@ -235,6 +245,7 @@ struct cmb_dataset {
>>>> ????? u32??????????? patt_mask[TPDM_CMB_MAX_PATT];
>>>> ????? u32??????????? trig_patt[TPDM_CMB_MAX_PATT];
>>>> ????? u32??????????? trig_patt_mask[TPDM_CMB_MAX_PATT];
>>>> +??? u32??????????? msr[TPDM_CMB_MAX_MSR];
>>>> ????? bool??????????? patt_ts;
>>>> ????? bool??????????? trig_ts;
>>>> ????? bool??????????? ts_all;
>>>> @@ -251,6 +262,7 @@ struct cmb_dataset {
>>>> ?? * @dsb???????? Specifics associated to TPDM DSB.
>>>> ?? * @cmb???????? Specifics associated to TPDM CMB.
>>>> ?? * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>> + * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>> ?? */
>>>> ? ? struct tpdm_drvdata {
>>>> @@ -263,6 +275,7 @@ struct tpdm_drvdata {
>>>> ????? struct dsb_dataset??? *dsb;
>>>> ????? struct cmb_dataset??? *cmb;
>>>> ????? u32??????????? dsb_msr_num;
>>>> +??? u32??????????? cmb_msr_num;
>>>> ? };
>>>> ? ? /* Enumerate members of various datasets */
>>>> @@ -277,7 +290,8 @@ enum dataset_mem {
>>>> ????? CMB_TRIG_PATT,
>>>> ????? CMB_TRIG_PATT_MASK,
>>>> ????? CMB_PATT,
>>>> -??? CMB_PATT_MASK
>>>> +??? CMB_PATT_MASK,
>>>> +??? CMB_MSR
>>>> ? };
>>>> ? ? /**
>>>
>>> _______________________________________________
>>> CoreSight mailing list -- coresight at lists.linaro.org
>>> To unsubscribe send an email to coresight-leave at lists.linaro.org
>


From fuyao1697 at cyg.com  Wed Dec 20 01:08:25 2023
From: fuyao1697 at cyg.com (fuyao)
Date: Wed, 20 Dec 2023 17:08:25 +0800
Subject: [PATCH] gmac: sun8i: r40: add gmac tx_delay support
Message-ID: <ZYKvCQBD-SY9uVLF@debian.cyg>

r40 can support tx_delay, so we add it.

Signed-off-by: fuyao <fuyao1697 at cyg.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 137741b94122..fd07573afc9b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -127,6 +127,7 @@ static const struct emac_variant emac_variant_r40 = {
 	.support_mii = true,
 	.support_rgmii = true,
 	.rx_delay_max = 7,
+	.tx_delay_max = 7,
 };
 
 static const struct emac_variant emac_variant_a64 = {
-- 
2.39.2


-- 
CYG Technology.


From miquel.raynal at bootlin.com  Wed Dec 20 01:12:44 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Wed, 20 Dec 2023 10:12:44 +0100
Subject: [PATCH 1/2] dt-bindings: mtd: partitions: u-boot: Fix typo
In-Reply-To: <20231218130656.9020-1-wahrenst@gmx.net>
Message-ID: <20231220091244.655381-1-miquel.raynal@bootlin.com>

On Mon, 2023-12-18 at 13:06:55 UTC, Stefan Wahren wrote:
> The initial description contained a typo.
> 
> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.

Miquel


From miquel.raynal at bootlin.com  Wed Dec 20 01:12:47 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Wed, 20 Dec 2023 10:12:47 +0100
Subject: [PATCH] mtd: rawnand: fix Excess struct member description kernel-doc warnings
In-Reply-To: <20231216044146.18645-1-rdunlap@infradead.org>
Message-ID: <20231220091247.655421-1-miquel.raynal@bootlin.com>

On Sat, 2023-12-16 at 04:41:46 UTC, Randy Dunlap wrote:
> Delete 2 lines to prevent warnings from scripts/kernel-doc:
> 
> s3c2410.c:117: warning: Excess struct member 'mtd' description in 's3c2410_nand_mtd'
> s3c2410.c:168: warning: Excess struct member 'freq_transition' description in 's3c2410_nand_info'
> 
> 
> Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312150611.EZBAQYqf-lkp at intel.com/
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Miquel Raynal <miquel.raynal at bootlin.com>
> Cc: Richard Weinberger <richard at nod.at>
> Cc: Vignesh Raghavendra <vigneshr at ti.com>
> Cc: linux-mtd at lists.infradead.org
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Cc: Alim Akhtar <alim.akhtar at samsung.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks.

Miquel


From david at redhat.com  Wed Dec 20 01:17:45 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 10:17:45 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
Message-ID: <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>

On 19.12.23 18:42, Ryan Roberts wrote:
> On 19/12/2023 17:22, David Hildenbrand wrote:
>> On 19.12.23 09:30, Ryan Roberts wrote:
>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>> batch is determined by the architecture with the new helper,
>>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>
>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>> maintenance operations that the arm64 backend has to perform during
>>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>>> in its ptes. By write-protecting the parent using the new
>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>> child, the backend does not need to fold a contiguous range once they
>>>>> are all populated - they can be initially populated as a contiguous
>>>>> range in the first place.
>>>>>
>>>>> This code is very performance sensitive, and a significant amount of
>>>>> effort has been put into not regressing performance for the order-0
>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>> which enables the compiler to simplify the extra loops that are added
>>>>> for batching and produce code that is equivalent (and equally
>>>>> performant) as the previous implementation.
>>>>>
>>>>> This change addresses the core-mm refactoring only and a separate change
>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>> improvement as part of the work to enable contpte mappings.
>>>>>
>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>> careful to only call ptep_get() once per pte batch.
>>>>>
>>>>> The following microbenchmark results demonstate that there is no
>>>>> significant performance change after this patch. Fork is called in a
>>>>> tight loop in a process with 1G of populated memory and the time for the
>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>> positive is slower, compared to baseline upon which the series is based:
>>>>>
>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>> | fork????????? |-------------------|-------------------|
>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>> |---------------|---------|---------|---------|---------|
>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>
>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>> | fork????????? |-------------------|-------------------|
>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>> |---------------|---------|---------|---------|---------|
>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>
>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>> ---
>>>>>  ?? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>  ?? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>>>  ?? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>
>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>> --- a/include/linux/pgtable.h
>>>>> +++ b/include/linux/pgtable.h
>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>  ?? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>  ?? #endif
>>>>>  ?? +#ifndef pte_batch_remaining
>>>>> +/**
>>>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>>>> + * @pte: Page table entry for the first page.
>>>>> + * @addr: Address of the first page.
>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>> + *
>>>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of
>>>>> ptes.
>>>>> + * In such cases, this function returns the remaining number of pages to
>>>>> the end
>>>>> + * of the current batch, as defined by addr. This can be useful when iterating
>>>>> + * over ptes.
>>>>> + *
>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>> + */
>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long addr,
>>>>> +??????????????????????? unsigned long end)
>>>>> +{
>>>>> +??? return 1;
>>>>> +}
>>>>> +#endif
>>>>
>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>
>>>> Was there no way to have some basic batching mechanism that doesn't require arch
>>>> specifics?
>>>
>>> I tried a bunch of things but ultimately the way I've done it was the only way
>>> to reduce the order-0 fork regression to 0.
>>>
>>> My original v3 posting was costing 5% extra and even my first attempt at an
>>> arch-specific version that didn't resolve to a compile-time constant 1 still
>>> cost an extra 3%.
>>>
>>>
>>>>
>>>> I'd have thought that something very basic would have worked like:
>>>>
>>>> * Check if PTE is the same when setting the PFN to 0.
>>>> * Check that PFN is consecutive
>>>> * Check that all PFNs belong to the same folio
>>>
>>> I haven't tried this exact approach, but I'd be surprised if I can get the
>>> regression under 4% with this. Further along the series I spent a lot of time
>>> having to fiddle with the arm64 implementation; every conditional and every
>>> memory read (even when in cache) was a problem. There is just so little in the
>>> inner loop that every instruction matters. (At least on Ampere Altra and Apple
>>> M2).
>>>
>>> Of course if you're willing to pay that 4-5% for order-0 then the benefit to
>>> order-9 is around 10% in my measurements. Personally though, I'd prefer to play
>>> safe and ensure the common order-0 case doesn't regress, as you previously
>>> suggested.
>>>
>>
>> I just hacked something up, on top of my beloved rmap cleanup/batching series. I
>> implemented very generic and simple batching for large folios (all PTE bits
>> except the PFN have to match).
>>
>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R) Silver
>> 4210R CPU.
>>
>> order-0: 0.014210 -> 0.013969
>>
>> -> Around 1.7 % faster
>>
>> order-9: 0.014373 -> 0.009149
>>
>> -> Around 36.3 % faster
> 
> Well I guess that shows me :)
> 
> I'll do a review and run the tests on my HW to see if it concurs.


I pushed a simple compile fixup (we need pte_next_pfn()).

Note that we should probably handle "ptep_set_wrprotects" rather like set_ptes:

#ifndef wrprotect_ptes
static inline void wrprotect_ptes(struct mm_struct *mm, unsigned long addr,
                pte_t *ptep, unsigned int nr)
{
        for (;;) {
                ptep_set_wrprotect(mm, addr, ptep);
                if (--nr == 0)
                        break;
                ptep++;
                addr += PAGE_SIZE;
        }
}
#endif


-- 
Cheers,

David / dhildenb



From Moudy.Ho at mediatek.com  Wed Dec 20 01:20:33 2023
From: Moudy.Ho at mediatek.com (=?utf-8?B?TW91ZHkgSG8gKOS9leWul+WOnyk=?=)
Date: Wed, 20 Dec 2023 09:20:33 +0000
Subject: [PATCH v9 00/16] introduce more MDP3 components in MT8195
In-Reply-To: <20231031083357.13775-1-moudy.ho@mediatek.com>
References: <20231031083357.13775-1-moudy.ho@mediatek.com>
Message-ID: <80feea63d4da5f9e942ecd8b4902a6f552394c0f.camel@mediatek.com>

Hi,

This series should depend on another series as follows:
Message ID = 20231214055847.4936-1-shawn.sung at mediatek.com


To include the missing compatible name 'mediatek,mt8188-vdo1-rdma' from
patch [1/12] in the mentioned series in next version.
The original tags will be removed (patch [2/16]), and kindly ask
everyone to review it again.

Sincerely,
Moudy

On Tue, 2023-10-31 at 16:33 +0800, Moudy Ho wrote:
> Changes since v8:
> - Rebase on linux-next.
> - Dependent dtsi files:
>   
> https://patchwork.kernel.org/project/linux-mediatek/list/?series=797543
> - Depends on:
>   Message ID = 20231024130048.14749-9-shawn.sung at mediatek.com
> - Following Rob's suggestion, the number of 'clocks' and 'mboxes'
> items are
>   restricted using the 'minItems' in [2/16] and [3/16].
> - Revise the dependent mt8188 disp padding compatible name in
> [16/16].
> 
> Changes since v7:
> - Rebase on linux-next.
> - Dependent dtsi files:
>   
> https://patchwork.kernel.org/project/linux-mediatek/list/?series=797543
> - Depends on:
>   Message ID = 20231024130048.14749-9-shawn.sung at mediatek.com
> - Correct the bindings of the four components: FG, TCC, TDSHP and
> HDR.
>   The names of the first three are expanded in the title, and
>   the descriptions of all four have been enhanced.
> 
> Changes since v6:
> - Rebase on v6.6-rc5.
> - Dependent dtsi files:
>   
> https://patchwork.kernel.org/project/linux-mediatek/list/?series=792079
> - Depends on:
>   Message ID = 20231006073831.10402-5-shawn.sung at mediatek.com
> - Discard splitting RDMA's common properties and instead use 'allOf'
> to
>   isolate different platform features.
> - Revise the incorrect properties in FG, HDR, STITCH, TCC and TDAP
> bindings.
> - Adding SoC-specific compatible string to components, like WROT and
> RSZ,
>   that are inherited from MT8183.
> - Fixed typos in TCC patch and enhancing its hardware description.
> 
> Changes since v5:
> - Rebase on v6.6-rc2.
> - Dependent dtsi files:
>   
> https://patchwork.kernel.org/project/linux-mediatek/list/?series=786511
> - Depends on:
>   Message ID = 20230911074233.31556-5-shawn.sung at mediatek.com
> - Split out common propertis for RDMA.
> - Split each component into independent patches.
> 
> Changes since v4:
> - Rebase on v6.6-rc1
> - Organize identical hardware components into their respective files.
> 
> Hi,
> 
> The purpose of this patch is to separate the MDP3-related bindings
> from
> the original mailing list mentioned below:
> 
https://lore.kernel.org/all/20230208092209.19472-1-moudy.ho at mediatek.com/
> Those binding files describe additional components that
> are present in the mt8195.
> 
> Moudy Ho (16):
>   dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with
>     generic names
>   dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under
>     display
>   dt-bindings: media: mediatek: mdp3: add config for MT8195 RDMA
>   dt-bindings: media: mediatek: mdp3: add compatible for MT8195 RSZ
>   dt-bindings: media: mediatek: mdp3: add compatible for MT8195 WROT
>   dt-bindings: media: mediatek: mdp3: add component FG for MT8195
>   dt-bindings: media: mediatek: mdp3: add component HDR for MT8195
>   dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
>   dt-bindings: media: mediatek: mdp3: add component TCC for MT8195
>   dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195
>   dt-bindings: display: mediatek: aal: add compatible for MT8195
>   dt-bindings: display: mediatek: color: add compatible for MT8195
>   dt-bindings: display: mediatek: merge: add compatible for MT8195
>   dt-bindings: display: mediatek: ovl: add compatible for MT8195
>   dt-bindings: display: mediatek: split: add compatible for MT8195
>   dt-bindings: display: mediatek: padding: add compatible for MT8195
> 
>  .../display/mediatek/mediatek,aal.yaml        |  1 +
>  .../display/mediatek/mediatek,color.yaml      |  1 +
>  .../display/mediatek/mediatek,mdp-rdma.yaml   | 88 ---------------
> ---
>  .../display/mediatek/mediatek,merge.yaml      |  1 +
>  .../display/mediatek/mediatek,ovl.yaml        |  1 +
>  .../display/mediatek/mediatek,padding.yaml    |  4 +-
>  .../display/mediatek/mediatek,split.yaml      | 27 ++++++
>  .../bindings/media/mediatek,mdp3-fg.yaml      | 61 ++++++++++++
>  .../bindings/media/mediatek,mdp3-hdr.yaml     | 61 ++++++++++++
>  .../bindings/media/mediatek,mdp3-rdma.yaml    | 92 +++++++++++++++
> ----
>  .../bindings/media/mediatek,mdp3-rsz.yaml     |  6 +-
>  .../bindings/media/mediatek,mdp3-stitch.yaml  | 61 ++++++++++++
>  .../bindings/media/mediatek,mdp3-tcc.yaml     | 62 +++++++++++++
>  .../bindings/media/mediatek,mdp3-tdshp.yaml   | 61 ++++++++++++
>  .../bindings/media/mediatek,mdp3-wrot.yaml    | 29 ++++--
>  15 files changed, 440 insertions(+), 116 deletions(-)
>  delete mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-
> rdma.yaml
>  create mode 100644
> Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
>  create mode 100644
> Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
>  create mode 100644
> Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
>  create mode 100644
> Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
>  create mode 100644
> Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
> 

From abel.vesa at linaro.org  Wed Dec 20 01:25:12 2023
From: abel.vesa at linaro.org (Abel Vesa)
Date: Wed, 20 Dec 2023 11:25:12 +0200
Subject: [PATCH] clk: imx: scu: Fix memory leak in __imx_clk_gpr_scu()
In-Reply-To: <20231210171907.3410922-1-visitorckw@gmail.com>
References: <20231210171907.3410922-1-visitorckw@gmail.com>
Message-ID: <170306426324.94631.3566102445536817606.b4-ty@linaro.org>


On Mon, 11 Dec 2023 01:19:07 +0800, Kuan-Wei Chiu wrote:
> In cases where imx_clk_is_resource_owned() returns false, the code path
> does not handle the failure gracefully, potentially leading to a memory
> leak. This fix ensures proper cleanup by freeing the allocated memory
> for 'clk_node' before returning.
> 
> 

Applied, thanks!

[1/1] clk: imx: scu: Fix memory leak in __imx_clk_gpr_scu()
      commit: 986439a9b3a32a6ac20042ec17acd443f1e7e86a

Best regards,
-- 
Abel Vesa <abel.vesa at linaro.org>


From abel.vesa at linaro.org  Wed Dec 20 01:26:11 2023
From: abel.vesa at linaro.org (Abel Vesa)
Date: Wed, 20 Dec 2023 11:26:11 +0200
Subject: [PATCH 1/1] clk: imx: clk-imx8qxp: fix LVDS bypass, pixel and phy clocks
In-Reply-To: <20231218122407.2757175-1-alexander.stein@ew.tq-group.com>
References: <20231218122407.2757175-1-alexander.stein@ew.tq-group.com>
Message-ID: <170306434511.107637.11193901614064155915.b4-ty@linaro.org>


On Mon, 18 Dec 2023 13:24:07 +0100, Alexander Stein wrote:
> To be compatibel with SCU firmware based on 1.15 a different clock
> routing for LVDS is needed.
> 
> 

Applied, thanks!

[1/1] clk: imx: clk-imx8qxp: fix LVDS bypass, pixel and phy clocks
      commit: 18e17b2a160382475a7e3211ce0acfb0dfbee633

Best regards,
-- 
Abel Vesa <abel.vesa at linaro.org>


From gabriel.fernandez at foss.st.com  Wed Dec 20 01:40:59 2023
From: gabriel.fernandez at foss.st.com (Gabriel FERNANDEZ)
Date: Wed, 20 Dec 2023 10:40:59 +0100
Subject: [PATCH v7 1/2] clk: stm32: introduce clocks for STM32MP257
 platform
In-Reply-To: <20231219130909.265091-2-gabriel.fernandez@foss.st.com>
References: <20231219130909.265091-1-gabriel.fernandez@foss.st.com>
 <20231219130909.265091-2-gabriel.fernandez@foss.st.com>
Message-ID: <e87f183a-d3d0-4111-8e22-4d31d1442406@foss.st.com>

Hi Stephen


On 12/19/23 14:09, gabriel.fernandez at foss.st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
>
> This driver is intended for the STM32MP25 clock family and utilizes
> the stm32-core API, similar to the stm32mp13 clock driver.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> ---
>   drivers/clk/stm32/Kconfig         |    7 +
>   drivers/clk/stm32/Makefile        |    1 +
>   drivers/clk/stm32/clk-stm32mp25.c | 1826 +++++++++++++++++++++++++++++
>   drivers/clk/stm32/reset-stm32.c   |   59 +-
>   drivers/clk/stm32/reset-stm32.h   |    7 +
>   drivers/clk/stm32/stm32mp25_rcc.h |  712 +++++++++++
>   6 files changed, 2597 insertions(+), 15 deletions(-)
>   create mode 100644 drivers/clk/stm32/clk-stm32mp25.c
>   create mode 100644 drivers/clk/stm32/stm32mp25_rcc.h
>
> diff --git a/drivers/clk/stm32/Kconfig b/drivers/clk/stm32/Kconfig
> index 3c8493a94a11..dca409d52652 100644
> --- a/drivers/clk/stm32/Kconfig
> +++ b/drivers/clk/stm32/Kconfig
> @@ -25,5 +25,12 @@ config COMMON_CLK_STM32MP157
>   	help
>   	  Support for stm32mp15x SoC family clocks.
>   
> +config COMMON_CLK_STM32MP257
> +	bool "Clock driver for stm32mp25x clocks"
> +	depends on ARM64 || COMPILE_TEST
> +	default y
> +	help
> +	  Support for stm32mp25x SoC family clocks.
> +
>   endif
>   
> diff --git a/drivers/clk/stm32/Makefile b/drivers/clk/stm32/Makefile
> index 5ced7fe3ddec..0a627164fcce 100644
> --- a/drivers/clk/stm32/Makefile
> +++ b/drivers/clk/stm32/Makefile
> @@ -1,2 +1,3 @@
>   obj-$(CONFIG_COMMON_CLK_STM32MP135)	+= clk-stm32mp13.o clk-stm32-core.o reset-stm32.o
>   obj-$(CONFIG_COMMON_CLK_STM32MP157)	+= clk-stm32mp1.o reset-stm32.o
> +obj-$(CONFIG_COMMON_CLK_STM32MP257)	+= clk-stm32mp25.o clk-stm32-core.o reset-stm32.o
> diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
> new file mode 100644
> index 000000000000..313e022c6142
> --- /dev/null
> +++ b/drivers/clk/stm32/clk-stm32mp25.c
> @@ -0,0 +1,1826 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
> + * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +
> +#include "clk-stm32-core.h"
> +#include "reset-stm32.h"
> +#include "stm32mp25_rcc.h"
> +
> +#include <dt-bindings/clock/st,stm32mp25-rcc.h>
> +#include <dt-bindings/reset/st,stm32mp25-rcc.h>
> +
> +static const struct clk_parent_data adc12_src[] = {
> +	{ .name = "ck_flexgen_46" },
> +	{ .name = "ck_icn_ls_mcu" },
> +};

Sorry, I missed adding .index = -1 to ensure that .name is used as a 
fallback.

 ??? { .name = "ck_flexgen_46", .index = -1 },
 ??? { .name = "ck_icn_ls_mcu", .index = -1 },

I will send a V8 for that.

Thank's

Gabriel


> +
> +static const struct clk_parent_data adc3_src[] = {
> +	{ .name = "ck_flexgen_47" },
> +	{ .name = "ck_icn_ls_mcu" },
> +	{ .name = "ck_flexgen_46" },
> +};
> +
> +static const struct clk_parent_data usb2phy1_src[] = {
> +	{ .name = "ck_flexgen_57" },
> +	{ .name = "hse_div2_ck" },
> +};
> +
> +static const struct clk_parent_data usb2phy2_src[] = {
> +	{ .name = "ck_flexgen_58" },
> +	{ .name = "hse_div2_ck" },
> +};
> +
> +static const struct clk_parent_data usb3pciphy_src[] = {
> +	{ .name = "ck_flexgen_34" },
> +	{ .name = "hse_div2_ck" },
> +};
> +
> +static const struct clk_parent_data dsiblane_src[] = {
> +	{ .name = "txbyteclk" },
> +	{ .name = "ck_ker_ltdc" },
> +};
> +
> +static const struct clk_parent_data dsiphy_src[] = {
> +	{ .name = "ck_flexgen_28" },
> +	{ .name = "hse_ck" },
> +};
> +
> +static const struct clk_parent_data lvdsphy_src[] = {
> +	{ .name = "ck_flexgen_32" },
> +	{ .name = "hse_ck" },
> +};
> +
> +static const struct clk_parent_data dts_src[] = {
> +	{ .name = "hsi_ck" },
> +	{ .name = "hse_ck" },
> +	{ .name = "msi_ck" },
> +};
> +
> +static const struct clk_parent_data mco1_src[] = {
> +	{ .name = "ck_flexgen_61" },
> +	{ .name = "ck_obs0" },
> +};
> +
> +static const struct clk_parent_data mco2_src[] = {
> +	{ .name = "ck_flexgen_62" },
> +	{ .name = "ck_obs1" },
> +};
> +
> +enum enum_mux_cfg {
> +	MUX_ADC12,
> +	MUX_ADC3,
> +	MUX_DSIBLANE,
> +	MUX_DSIPHY,
> +	MUX_DTS,
> +	MUX_LVDSPHY,
> +	MUX_MCO1,
> +	MUX_MCO2,
> +	MUX_USB2PHY1,
> +	MUX_USB2PHY2,
> +	MUX_USB3PCIEPHY,
> +	MUX_NB
> +};
> +
> +#define MUX_CFG(id, _offset, _shift, _witdh)	\
> +	[id] = {				\
> +		.offset		= (_offset),	\
> +		.shift		= (_shift),	\
> +		.width		= (_witdh),	\
> +	}
> +
> +static const struct stm32_mux_cfg stm32mp25_muxes[MUX_NB] = {
> +	MUX_CFG(MUX_ADC12,		RCC_ADC12CFGR,		12,	1),
> +	MUX_CFG(MUX_ADC3,		RCC_ADC3CFGR,		12,	2),
> +	MUX_CFG(MUX_DSIBLANE,		RCC_DSICFGR,		12,	1),
> +	MUX_CFG(MUX_DSIPHY,		RCC_DSICFGR,		15,	1),
> +	MUX_CFG(MUX_DTS,		RCC_DTSCFGR,		12,	2),
> +	MUX_CFG(MUX_LVDSPHY,		RCC_LVDSCFGR,		15,	1),
> +	MUX_CFG(MUX_MCO1,		RCC_MCO1CFGR,		0,	1),
> +	MUX_CFG(MUX_MCO2,		RCC_MCO2CFGR,		0,	1),
> +	MUX_CFG(MUX_USB2PHY1,		RCC_USB2PHY1CFGR,	15,	1),
> +	MUX_CFG(MUX_USB2PHY2,		RCC_USB2PHY2CFGR,	15,	1),
> +	MUX_CFG(MUX_USB3PCIEPHY,	RCC_USB3PCIEPHYCFGR,	15,	1),
> +};
> +
> +enum enum_gate_cfg {
> +	GATE_ADC12,
> +	GATE_ADC3,
> +	GATE_ADF1,
> +	GATE_CCI,
> +	GATE_CRC,
> +	GATE_CRYP1,
> +	GATE_CRYP2,
> +	GATE_CSI,
> +	GATE_DCMIPP,
> +	GATE_DSI,
> +	GATE_DTS,
> +	GATE_ETH1,
> +	GATE_ETH1MAC,
> +	GATE_ETH1RX,
> +	GATE_ETH1STP,
> +	GATE_ETH1TX,
> +	GATE_ETH2,
> +	GATE_ETH2MAC,
> +	GATE_ETH2RX,
> +	GATE_ETH2STP,
> +	GATE_ETH2TX,
> +	GATE_ETHSW,
> +	GATE_ETHSWACMCFG,
> +	GATE_ETHSWACMMSG,
> +	GATE_ETHSWMAC,
> +	GATE_ETHSWREF,
> +	GATE_FDCAN,
> +	GATE_GPU,
> +	GATE_HASH,
> +	GATE_HDP,
> +	GATE_I2C1,
> +	GATE_I2C2,
> +	GATE_I2C3,
> +	GATE_I2C4,
> +	GATE_I2C5,
> +	GATE_I2C6,
> +	GATE_I2C7,
> +	GATE_I2C8,
> +	GATE_I3C1,
> +	GATE_I3C2,
> +	GATE_I3C3,
> +	GATE_I3C4,
> +	GATE_IS2M,
> +	GATE_IWDG1,
> +	GATE_IWDG2,
> +	GATE_IWDG3,
> +	GATE_IWDG4,
> +	GATE_IWDG5,
> +	GATE_LPTIM1,
> +	GATE_LPTIM2,
> +	GATE_LPTIM3,
> +	GATE_LPTIM4,
> +	GATE_LPTIM5,
> +	GATE_LPUART1,
> +	GATE_LTDC,
> +	GATE_LVDS,
> +	GATE_MCO1,
> +	GATE_MCO2,
> +	GATE_MDF1,
> +	GATE_OSPIIOM,
> +	GATE_PCIE,
> +	GATE_PKA,
> +	GATE_RNG,
> +	GATE_SAES,
> +	GATE_SAI1,
> +	GATE_SAI2,
> +	GATE_SAI3,
> +	GATE_SAI4,
> +	GATE_SDMMC1,
> +	GATE_SDMMC2,
> +	GATE_SDMMC3,
> +	GATE_SERC,
> +	GATE_SPDIFRX,
> +	GATE_SPI1,
> +	GATE_SPI2,
> +	GATE_SPI3,
> +	GATE_SPI4,
> +	GATE_SPI5,
> +	GATE_SPI6,
> +	GATE_SPI7,
> +	GATE_SPI8,
> +	GATE_TIM1,
> +	GATE_TIM10,
> +	GATE_TIM11,
> +	GATE_TIM12,
> +	GATE_TIM13,
> +	GATE_TIM14,
> +	GATE_TIM15,
> +	GATE_TIM16,
> +	GATE_TIM17,
> +	GATE_TIM2,
> +	GATE_TIM20,
> +	GATE_TIM3,
> +	GATE_TIM4,
> +	GATE_TIM5,
> +	GATE_TIM6,
> +	GATE_TIM7,
> +	GATE_TIM8,
> +	GATE_UART4,
> +	GATE_UART5,
> +	GATE_UART7,
> +	GATE_UART8,
> +	GATE_UART9,
> +	GATE_USART1,
> +	GATE_USART2,
> +	GATE_USART3,
> +	GATE_USART6,
> +	GATE_USB2,
> +	GATE_USB2PHY1,
> +	GATE_USB2PHY2,
> +	GATE_USB3DR,
> +	GATE_USB3PCIEPHY,
> +	GATE_USBTC,
> +	GATE_VDEC,
> +	GATE_VENC,
> +	GATE_VREF,
> +	GATE_WWDG1,
> +	GATE_WWDG2,
> +	GATE_NB
> +};
> +
> +#define GATE_CFG(id, _offset, _bit_idx, _offset_clr)	\
> +	[id] = {					\
> +		.offset		= (_offset),		\
> +		.bit_idx	= (_bit_idx),		\
> +		.set_clr	= (_offset_clr),	\
> +	}
> +
> +static const struct stm32_gate_cfg stm32mp25_gates[GATE_NB] = {
> +	GATE_CFG(GATE_ADC12,		RCC_ADC12CFGR,		1,	0),
> +	GATE_CFG(GATE_ADC3,		RCC_ADC3CFGR,		1,	0),
> +	GATE_CFG(GATE_ADF1,		RCC_ADF1CFGR,		1,	0),
> +	GATE_CFG(GATE_CCI,		RCC_CCICFGR,		1,	0),
> +	GATE_CFG(GATE_CRC,		RCC_CRCCFGR,		1,	0),
> +	GATE_CFG(GATE_CRYP1,		RCC_CRYP1CFGR,		1,	0),
> +	GATE_CFG(GATE_CRYP2,		RCC_CRYP2CFGR,		1,	0),
> +	GATE_CFG(GATE_CSI,		RCC_CSICFGR,		1,	0),
> +	GATE_CFG(GATE_DCMIPP,		RCC_DCMIPPCFGR,		1,	0),
> +	GATE_CFG(GATE_DSI,		RCC_DSICFGR,		1,	0),
> +	GATE_CFG(GATE_DTS,		RCC_DTSCFGR,		1,	0),
> +	GATE_CFG(GATE_ETH1,		RCC_ETH1CFGR,		5,	0),
> +	GATE_CFG(GATE_ETH1MAC,		RCC_ETH1CFGR,		1,	0),
> +	GATE_CFG(GATE_ETH1RX,		RCC_ETH1CFGR,		10,	0),
> +	GATE_CFG(GATE_ETH1STP,		RCC_ETH1CFGR,		4,	0),
> +	GATE_CFG(GATE_ETH1TX,		RCC_ETH1CFGR,		8,	0),
> +	GATE_CFG(GATE_ETH2,		RCC_ETH2CFGR,		5,	0),
> +	GATE_CFG(GATE_ETH2MAC,		RCC_ETH2CFGR,		1,	0),
> +	GATE_CFG(GATE_ETH2RX,		RCC_ETH2CFGR,		10,	0),
> +	GATE_CFG(GATE_ETH2STP,		RCC_ETH2CFGR,		4,	0),
> +	GATE_CFG(GATE_ETH2TX,		RCC_ETH2CFGR,		8,	0),
> +	GATE_CFG(GATE_ETHSW,		RCC_ETHSWCFGR,		5,	0),
> +	GATE_CFG(GATE_ETHSWACMCFG,	RCC_ETHSWACMCFGR,	1,	0),
> +	GATE_CFG(GATE_ETHSWACMMSG,	RCC_ETHSWACMMSGCFGR,	1,	0),
> +	GATE_CFG(GATE_ETHSWMAC,		RCC_ETHSWCFGR,		1,	0),
> +	GATE_CFG(GATE_ETHSWREF,		RCC_ETHSWCFGR,		21,	0),
> +	GATE_CFG(GATE_FDCAN,		RCC_FDCANCFGR,		1,	0),
> +	GATE_CFG(GATE_GPU,		RCC_GPUCFGR,		1,	0),
> +	GATE_CFG(GATE_HASH,		RCC_HASHCFGR,		1,	0),
> +	GATE_CFG(GATE_HDP,		RCC_HDPCFGR,		1,	0),
> +	GATE_CFG(GATE_I2C1,		RCC_I2C1CFGR,		1,	0),
> +	GATE_CFG(GATE_I2C2,		RCC_I2C2CFGR,		1,	0),
> +	GATE_CFG(GATE_I2C3,		RCC_I2C3CFGR,		1,	0),
> +	GATE_CFG(GATE_I2C4,		RCC_I2C4CFGR,		1,	0),
> +	GATE_CFG(GATE_I2C5,		RCC_I2C5CFGR,		1,	0),
> +	GATE_CFG(GATE_I2C6,		RCC_I2C6CFGR,		1,	0),
> +	GATE_CFG(GATE_I2C7,		RCC_I2C7CFGR,		1,	0),
> +	GATE_CFG(GATE_I2C8,		RCC_I2C8CFGR,		1,	0),
> +	GATE_CFG(GATE_I3C1,		RCC_I3C1CFGR,		1,	0),
> +	GATE_CFG(GATE_I3C2,		RCC_I3C2CFGR,		1,	0),
> +	GATE_CFG(GATE_I3C3,		RCC_I3C3CFGR,		1,	0),
> +	GATE_CFG(GATE_I3C4,		RCC_I3C4CFGR,		1,	0),
> +	GATE_CFG(GATE_IS2M,		RCC_IS2MCFGR,		1,	0),
> +	GATE_CFG(GATE_IWDG1,		RCC_IWDG1CFGR,		1,	0),
> +	GATE_CFG(GATE_IWDG2,		RCC_IWDG2CFGR,		1,	0),
> +	GATE_CFG(GATE_IWDG3,		RCC_IWDG3CFGR,		1,	0),
> +	GATE_CFG(GATE_IWDG4,		RCC_IWDG4CFGR,		1,	0),
> +	GATE_CFG(GATE_IWDG5,		RCC_IWDG5CFGR,		1,	0),
> +	GATE_CFG(GATE_LPTIM1,		RCC_LPTIM1CFGR,		1,	0),
> +	GATE_CFG(GATE_LPTIM2,		RCC_LPTIM2CFGR,		1,	0),
> +	GATE_CFG(GATE_LPTIM3,		RCC_LPTIM3CFGR,		1,	0),
> +	GATE_CFG(GATE_LPTIM4,		RCC_LPTIM4CFGR,		1,	0),
> +	GATE_CFG(GATE_LPTIM5,		RCC_LPTIM5CFGR,		1,	0),
> +	GATE_CFG(GATE_LPUART1,		RCC_LPUART1CFGR,	1,	0),
> +	GATE_CFG(GATE_LTDC,		RCC_LTDCCFGR,		1,	0),
> +	GATE_CFG(GATE_LVDS,		RCC_LVDSCFGR,		1,	0),
> +	GATE_CFG(GATE_MCO1,		RCC_MCO1CFGR,		8,	0),
> +	GATE_CFG(GATE_MCO2,		RCC_MCO2CFGR,		8,	0),
> +	GATE_CFG(GATE_MDF1,		RCC_MDF1CFGR,		1,	0),
> +	GATE_CFG(GATE_OSPIIOM,		RCC_OSPIIOMCFGR,	1,	0),
> +	GATE_CFG(GATE_PCIE,		RCC_PCIECFGR,		1,	0),
> +	GATE_CFG(GATE_PKA,		RCC_PKACFGR,		1,	0),
> +	GATE_CFG(GATE_RNG,		RCC_RNGCFGR,		1,	0),
> +	GATE_CFG(GATE_SAES,		RCC_SAESCFGR,		1,	0),
> +	GATE_CFG(GATE_SAI1,		RCC_SAI1CFGR,		1,	0),
> +	GATE_CFG(GATE_SAI2,		RCC_SAI2CFGR,		1,	0),
> +	GATE_CFG(GATE_SAI3,		RCC_SAI3CFGR,		1,	0),
> +	GATE_CFG(GATE_SAI4,		RCC_SAI4CFGR,		1,	0),
> +	GATE_CFG(GATE_SDMMC1,		RCC_SDMMC1CFGR,		1,	0),
> +	GATE_CFG(GATE_SDMMC2,		RCC_SDMMC2CFGR,		1,	0),
> +	GATE_CFG(GATE_SDMMC3,		RCC_SDMMC3CFGR,		1,	0),
> +	GATE_CFG(GATE_SERC,		RCC_SERCCFGR,		1,	0),
> +	GATE_CFG(GATE_SPDIFRX,		RCC_SPDIFRXCFGR,	1,	0),
> +	GATE_CFG(GATE_SPI1,		RCC_SPI1CFGR,		1,	0),
> +	GATE_CFG(GATE_SPI2,		RCC_SPI2CFGR,		1,	0),
> +	GATE_CFG(GATE_SPI3,		RCC_SPI3CFGR,		1,	0),
> +	GATE_CFG(GATE_SPI4,		RCC_SPI4CFGR,		1,	0),
> +	GATE_CFG(GATE_SPI5,		RCC_SPI5CFGR,		1,	0),
> +	GATE_CFG(GATE_SPI6,		RCC_SPI6CFGR,		1,	0),
> +	GATE_CFG(GATE_SPI7,		RCC_SPI7CFGR,		1,	0),
> +	GATE_CFG(GATE_SPI8,		RCC_SPI8CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM1,		RCC_TIM1CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM10,		RCC_TIM10CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM11,		RCC_TIM11CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM12,		RCC_TIM12CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM13,		RCC_TIM13CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM14,		RCC_TIM14CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM15,		RCC_TIM15CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM16,		RCC_TIM16CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM17,		RCC_TIM17CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM2,		RCC_TIM2CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM20,		RCC_TIM20CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM3,		RCC_TIM3CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM4,		RCC_TIM4CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM5,		RCC_TIM5CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM6,		RCC_TIM6CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM7,		RCC_TIM7CFGR,		1,	0),
> +	GATE_CFG(GATE_TIM8,		RCC_TIM8CFGR,		1,	0),
> +	GATE_CFG(GATE_UART4,		RCC_UART4CFGR,		1,	0),
> +	GATE_CFG(GATE_UART5,		RCC_UART5CFGR,		1,	0),
> +	GATE_CFG(GATE_UART7,		RCC_UART7CFGR,		1,	0),
> +	GATE_CFG(GATE_UART8,		RCC_UART8CFGR,		1,	0),
> +	GATE_CFG(GATE_UART9,		RCC_UART9CFGR,		1,	0),
> +	GATE_CFG(GATE_USART1,		RCC_USART1CFGR,		1,	0),
> +	GATE_CFG(GATE_USART2,		RCC_USART2CFGR,		1,	0),
> +	GATE_CFG(GATE_USART3,		RCC_USART3CFGR,		1,	0),
> +	GATE_CFG(GATE_USART6,		RCC_USART6CFGR,		1,	0),
> +	GATE_CFG(GATE_USB2,		RCC_USB2CFGR,		1,	0),
> +	GATE_CFG(GATE_USB2PHY1,		RCC_USB2PHY1CFGR,	1,	0),
> +	GATE_CFG(GATE_USB2PHY2,		RCC_USB2PHY2CFGR,	1,	0),
> +	GATE_CFG(GATE_USB3DR,		RCC_USB3DRCFGR,		1,	0),
> +	GATE_CFG(GATE_USB3PCIEPHY,	RCC_USB3PCIEPHYCFGR,	1,	0),
> +	GATE_CFG(GATE_USBTC,		RCC_USBTCCFGR,		1,	0),
> +	GATE_CFG(GATE_VDEC,		RCC_VDECCFGR,		1,	0),
> +	GATE_CFG(GATE_VENC,		RCC_VENCCFGR,		1,	0),
> +	GATE_CFG(GATE_VREF,		RCC_VREFCFGR,		1,	0),
> +	GATE_CFG(GATE_WWDG1,		RCC_WWDG1CFGR,		1,	0),
> +	GATE_CFG(GATE_WWDG2,		RCC_WWDG2CFGR,		1,	0),
> +};
> +
> +/* ADC */
> +static struct clk_stm32_gate ck_icn_p_adc12 = {
> +	.gate_id = GATE_ADC12,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_adc12", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_composite ck_ker_adc12 = {
> +	.gate_id = GATE_ADC12,
> +	.mux_id = MUX_ADC12,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_adc12", adc12_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_adc3 = {
> +	.gate_id = GATE_ADC3,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_adc3", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_composite ck_ker_adc3 = {
> +	.gate_id = GATE_ADC3,
> +	.mux_id = MUX_ADC3,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_adc3", adc3_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +/* ADF */
> +static struct clk_stm32_gate ck_icn_p_adf1 = {
> +	.gate_id = GATE_ADF1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_adf1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_adf1 = {
> +	.gate_id = GATE_ADF1,
> +	.hw.init = CLK_HW_INIT("ck_ker_adf1", "ck_flexgen_42", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* DCMI */
> +static struct clk_stm32_gate ck_icn_p_cci = {
> +	.gate_id = GATE_CCI,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_cci", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* CSI-HOST */
> +static struct clk_stm32_gate ck_icn_p_csi = {
> +	.gate_id = GATE_CSI,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_csi", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_csi = {
> +	.gate_id = GATE_CSI,
> +	.hw.init = CLK_HW_INIT("ck_ker_csi", "ck_flexgen_29", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_csitxesc = {
> +	.gate_id = GATE_CSI,
> +	.hw.init = CLK_HW_INIT("ck_ker_csitxesc", "ck_flexgen_30", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* CSI-PHY */
> +static struct clk_stm32_gate ck_ker_csiphy = {
> +	.gate_id = GATE_CSI,
> +	.hw.init = CLK_HW_INIT("ck_ker_csiphy", "ck_flexgen_31", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* DCMIPP */
> +static struct clk_stm32_gate ck_icn_p_dcmipp = {
> +	.gate_id = GATE_DCMIPP,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_dcmipp", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* CRC */
> +static struct clk_stm32_gate ck_icn_p_crc = {
> +	.gate_id = GATE_CRC,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_crc", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* CRYP */
> +static struct clk_stm32_gate ck_icn_p_cryp1 = {
> +	.gate_id = GATE_CRYP1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_cryp1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_cryp2 = {
> +	.gate_id = GATE_CRYP2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_cryp2", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* DBG & TRACE*/
> +/* Trace and debug clocks are managed by SCMI */
> +
> +/* LTDC */
> +static struct clk_stm32_gate ck_icn_p_ltdc = {
> +	.gate_id = GATE_LTDC,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_ltdc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_ltdc = {
> +	.gate_id = GATE_LTDC,
> +	.hw.init = CLK_HW_INIT("ck_ker_ltdc", "ck_flexgen_27", &clk_stm32_gate_ops,
> +			       CLK_SET_RATE_PARENT),
> +};
> +
> +/* DSI */
> +static struct clk_stm32_gate ck_icn_p_dsi = {
> +	.gate_id = GATE_DSI,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_dsi", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_composite clk_lanebyte = {
> +	.gate_id = GATE_DSI,
> +	.mux_id = MUX_DSIBLANE,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("clk_lanebyte", dsiblane_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +/* LVDS */
> +static struct clk_stm32_gate ck_icn_p_lvds = {
> +	.gate_id = GATE_LVDS,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_lvds", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* DSI PHY */
> +static struct clk_stm32_composite clk_phy_dsi = {
> +	.gate_id = GATE_DSI,
> +	.mux_id = MUX_DSIPHY,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("clk_phy_dsi", dsiphy_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +/* LVDS PHY */
> +static struct clk_stm32_composite ck_ker_lvdsphy = {
> +	.gate_id = GATE_LVDS,
> +	.mux_id = MUX_LVDSPHY,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_lvdsphy", lvdsphy_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +/* DTS */
> +static struct clk_stm32_composite ck_ker_dts = {
> +	.gate_id = GATE_DTS,
> +	.mux_id = MUX_DTS,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_dts", dts_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +/* ETHERNET */
> +static struct clk_stm32_gate ck_icn_p_eth1 = {
> +	.gate_id = GATE_ETH1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_eth1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth1stp = {
> +	.gate_id = GATE_ETH1STP,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth1stp", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth1 = {
> +	.gate_id = GATE_ETH1,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth1", "ck_flexgen_54", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth1ptp = {
> +	.gate_id = GATE_ETH1,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth1ptp", "ck_flexgen_56", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth1mac = {
> +	.gate_id = GATE_ETH1MAC,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth1mac", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth1tx = {
> +	.gate_id = GATE_ETH1TX,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth1tx", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth1rx = {
> +	.gate_id = GATE_ETH1RX,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth1rx", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_eth2 = {
> +	.gate_id = GATE_ETH2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_eth2", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth2stp = {
> +	.gate_id = GATE_ETH2STP,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth2stp", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth2 = {
> +	.gate_id = GATE_ETH2,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth2", "ck_flexgen_55", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth2ptp = {
> +	.gate_id = GATE_ETH2,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth2ptp", "ck_flexgen_56", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth2mac = {
> +	.gate_id = GATE_ETH2MAC,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth2mac", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth2tx = {
> +	.gate_id = GATE_ETH2TX,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth2tx", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_eth2rx = {
> +	.gate_id = GATE_ETH2RX,
> +	.hw.init = CLK_HW_INIT("ck_ker_eth2rx", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_ethsw = {
> +	.gate_id = GATE_ETHSWMAC,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_ethsw", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_ethsw = {
> +	.gate_id = GATE_ETHSW,
> +	.hw.init = CLK_HW_INIT("ck_ker_ethsw", "ck_flexgen_54", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_ethswref = {
> +	.gate_id = GATE_ETHSWREF,
> +	.hw.init = CLK_HW_INIT("ck_ker_ethswref", "ck_flexgen_60", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_ethsw_acm_cfg = {
> +	.gate_id = GATE_ETHSWACMCFG,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_ethsw_acm_cfg", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_ethsw_acm_msg = {
> +	.gate_id = GATE_ETHSWACMMSG,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_ethsw_acm_msg", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* FDCAN */
> +static struct clk_stm32_gate ck_icn_p_fdcan = {
> +	.gate_id = GATE_FDCAN,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_fdcan", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_fdcan = {
> +	.gate_id = GATE_FDCAN,
> +	.hw.init = CLK_HW_INIT("ck_ker_fdcan", "ck_flexgen_26", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* GPU */
> +static struct clk_stm32_gate ck_icn_m_gpu = {
> +	.gate_id = GATE_GPU,
> +	.hw.init = CLK_HW_INIT("ck_icn_m_gpu", "ck_flexgen_59", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_gpu = {
> +	.gate_id = GATE_GPU,
> +	.hw.init = CLK_HW_INIT("ck_ker_gpu", "ck_pll3", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* HASH */
> +static struct clk_stm32_gate ck_icn_p_hash = {
> +	.gate_id = GATE_HASH,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_hash", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* HDP */
> +static struct clk_stm32_gate ck_icn_p_hdp = {
> +	.gate_id = GATE_HDP,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_hdp", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* I2C */
> +static struct clk_stm32_gate ck_icn_p_i2c8 = {
> +	.gate_id = GATE_I2C8,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i2c8", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i2c1 = {
> +	.gate_id = GATE_I2C1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i2c1", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i2c2 = {
> +	.gate_id = GATE_I2C2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i2c2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i2c3 = {
> +	.gate_id = GATE_I2C3,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i2c3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i2c4 = {
> +	.gate_id = GATE_I2C4,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i2c4", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i2c5 = {
> +	.gate_id = GATE_I2C5,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i2c5", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i2c6 = {
> +	.gate_id = GATE_I2C6,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i2c6", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i2c7 = {
> +	.gate_id = GATE_I2C7,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i2c7", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i2c1 = {
> +	.gate_id = GATE_I2C1,
> +	.hw.init = CLK_HW_INIT("ck_ker_i2c1", "ck_flexgen_12", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i2c2 = {
> +	.gate_id = GATE_I2C2,
> +	.hw.init = CLK_HW_INIT("ck_ker_i2c2", "ck_flexgen_12", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i2c3 = {
> +	.gate_id = GATE_I2C3,
> +	.hw.init = CLK_HW_INIT("ck_ker_i2c3", "ck_flexgen_13", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i2c5 = {
> +	.gate_id = GATE_I2C5,
> +	.hw.init = CLK_HW_INIT("ck_ker_i2c5", "ck_flexgen_13", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i2c4 = {
> +	.gate_id = GATE_I2C4,
> +	.hw.init = CLK_HW_INIT("ck_ker_i2c4", "ck_flexgen_14", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i2c6 = {
> +	.gate_id = GATE_I2C6,
> +	.hw.init = CLK_HW_INIT("ck_ker_i2c6", "ck_flexgen_14", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i2c7 = {
> +	.gate_id = GATE_I2C7,
> +	.hw.init = CLK_HW_INIT("ck_ker_i2c7", "ck_flexgen_15", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i2c8 = {
> +	.gate_id = GATE_I2C8,
> +	.hw.init = CLK_HW_INIT("ck_ker_i2c8", "ck_flexgen_38", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* I3C */
> +static struct clk_stm32_gate ck_icn_p_i3c1 = {
> +	.gate_id = GATE_I3C1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i3c1", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i3c2 = {
> +	.gate_id = GATE_I3C2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i3c2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i3c3 = {
> +	.gate_id = GATE_I3C3,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i3c3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_i3c4 = {
> +	.gate_id = GATE_I3C4,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_i3c4", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i3c1 = {
> +	.gate_id = GATE_I3C1,
> +	.hw.init = CLK_HW_INIT("ck_ker_i3c1", "ck_flexgen_12", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i3c2 = {
> +	.gate_id = GATE_I3C2,
> +	.hw.init = CLK_HW_INIT("ck_ker_i3c2", "ck_flexgen_12", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i3c3 = {
> +	.gate_id = GATE_I3C3,
> +	.hw.init = CLK_HW_INIT("ck_ker_i3c3", "ck_flexgen_13", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_i3c4 = {
> +	.gate_id = GATE_I3C4,
> +	.hw.init = CLK_HW_INIT("ck_ker_i3c4", "ck_flexgen_36", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* I2S */
> +static struct clk_stm32_gate ck_icn_p_is2m = {
> +	.gate_id = GATE_IS2M,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_is2m", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* IWDG */
> +static struct clk_stm32_gate ck_icn_p_iwdg2 = {
> +	.gate_id = GATE_IWDG2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_iwdg2", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_iwdg3 = {
> +	.gate_id = GATE_IWDG3,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_iwdg3", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_iwdg4 = {
> +	.gate_id = GATE_IWDG4,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_iwdg4", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_iwdg5 = {
> +	.gate_id = GATE_IWDG5,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_iwdg5", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* LPTIM */
> +static struct clk_stm32_gate ck_icn_p_lptim1 = {
> +	.gate_id = GATE_LPTIM1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_lptim1", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_lptim2 = {
> +	.gate_id = GATE_LPTIM2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_lptim2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_lptim3 = {
> +	.gate_id = GATE_LPTIM3,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_lptim3", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_lptim4 = {
> +	.gate_id = GATE_LPTIM4,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_lptim4", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_lptim5 = {
> +	.gate_id = GATE_LPTIM5,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_lptim5", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_lptim1 = {
> +	.gate_id = GATE_LPTIM1,
> +	.hw.init = CLK_HW_INIT("ck_ker_lptim1", "ck_flexgen_07", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_lptim2 = {
> +	.gate_id = GATE_LPTIM2,
> +	.hw.init = CLK_HW_INIT("ck_ker_lptim2", "ck_flexgen_07", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_lptim3 = {
> +	.gate_id = GATE_LPTIM3,
> +	.hw.init = CLK_HW_INIT("ck_ker_lptim3", "ck_flexgen_40", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_lptim4 = {
> +	.gate_id = GATE_LPTIM4,
> +	.hw.init = CLK_HW_INIT("ck_ker_lptim4", "ck_flexgen_41", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_lptim5 = {
> +	.gate_id = GATE_LPTIM5,
> +	.hw.init = CLK_HW_INIT("ck_ker_lptim5", "ck_flexgen_41", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* LPUART */
> +static struct clk_stm32_gate ck_icn_p_lpuart1 = {
> +	.gate_id = GATE_LPUART1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_lpuart1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_lpuart1 = {
> +	.gate_id = GATE_LPUART1,
> +	.hw.init = CLK_HW_INIT("ck_ker_lpuart1", "ck_flexgen_39", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* MCO1 & MCO2 */
> +static struct clk_stm32_composite ck_mco1 = {
> +	.gate_id = GATE_MCO1,
> +	.mux_id = MUX_MCO1,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_mco1", mco1_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +static struct clk_stm32_composite ck_mco2 = {
> +	.gate_id = GATE_MCO2,
> +	.mux_id = MUX_MCO2,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_mco2", mco2_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +/* MDF */
> +static struct clk_stm32_gate ck_icn_p_mdf1 = {
> +	.gate_id = GATE_MDF1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_mdf1", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_mdf1 = {
> +	.gate_id = GATE_MDF1,
> +	.hw.init = CLK_HW_INIT("ck_ker_mdf1", "ck_flexgen_23", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* OSPI */
> +static struct clk_stm32_gate ck_icn_p_ospiiom = {
> +	.gate_id = GATE_OSPIIOM,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_ospiiom", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* PCIE */
> +static struct clk_stm32_gate ck_icn_p_pcie = {
> +	.gate_id = GATE_PCIE,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_pcie", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* SAI */
> +static struct clk_stm32_gate ck_icn_p_sai1 = {
> +	.gate_id = GATE_SAI1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_sai1", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_sai2 = {
> +	.gate_id = GATE_SAI2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_sai2", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_sai3 = {
> +	.gate_id = GATE_SAI3,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_sai3", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_sai4 = {
> +	.gate_id = GATE_SAI4,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_sai4", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_sai1 = {
> +	.gate_id = GATE_SAI1,
> +	.hw.init = CLK_HW_INIT("ck_ker_sai1", "ck_flexgen_23", &clk_stm32_gate_ops,
> +			       CLK_SET_RATE_PARENT),
> +};
> +
> +static struct clk_stm32_gate ck_ker_sai2 = {
> +	.gate_id = GATE_SAI2,
> +	.hw.init = CLK_HW_INIT("ck_ker_sai2", "ck_flexgen_24", &clk_stm32_gate_ops,
> +			       CLK_SET_RATE_PARENT),
> +};
> +
> +static struct clk_stm32_gate ck_ker_sai3 = {
> +	.gate_id = GATE_SAI3,
> +	.hw.init = CLK_HW_INIT("ck_ker_sai3", "ck_flexgen_25", &clk_stm32_gate_ops,
> +			       CLK_SET_RATE_PARENT),
> +};
> +
> +static struct clk_stm32_gate ck_ker_sai4 = {
> +	.gate_id = GATE_SAI4,
> +	.hw.init = CLK_HW_INIT("ck_ker_sai4", "ck_flexgen_25", &clk_stm32_gate_ops,
> +			       CLK_SET_RATE_PARENT),
> +};
> +
> +/* SDMMC */
> +static struct clk_stm32_gate ck_icn_m_sdmmc1 = {
> +	.gate_id = GATE_SDMMC1,
> +	.hw.init = CLK_HW_INIT("ck_icn_m_sdmmc1", "ck_icn_sdmmc", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_m_sdmmc2 = {
> +	.gate_id = GATE_SDMMC2,
> +	.hw.init = CLK_HW_INIT("ck_icn_m_sdmmc2", "ck_icn_sdmmc", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_m_sdmmc3 = {
> +	.gate_id = GATE_SDMMC3,
> +	.hw.init = CLK_HW_INIT("ck_icn_m_sdmmc3", "ck_icn_sdmmc", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_sdmmc1 = {
> +	.gate_id = GATE_SDMMC1,
> +	.hw.init = CLK_HW_INIT("ck_ker_sdmmc1", "ck_flexgen_51", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_sdmmc2 = {
> +	.gate_id = GATE_SDMMC2,
> +	.hw.init = CLK_HW_INIT("ck_ker_sdmmc2", "ck_flexgen_52", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_sdmmc3 = {
> +	.gate_id = GATE_SDMMC3,
> +	.hw.init = CLK_HW_INIT("ck_ker_sdmmc3", "ck_flexgen_53", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* SPDIF */
> +static struct clk_stm32_gate ck_icn_p_spdifrx = {
> +	.gate_id = GATE_SPDIFRX,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_spdifrx", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_spdifrx = {
> +	.gate_id = GATE_SPDIFRX,
> +	.hw.init = CLK_HW_INIT("ck_ker_spdifrx", "ck_flexgen_11", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* SPI */
> +static struct clk_stm32_gate ck_icn_p_spi1 = {
> +	.gate_id = GATE_SPI1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_spi1", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_spi2 = {
> +	.gate_id = GATE_SPI2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_spi2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_spi3 = {
> +	.gate_id = GATE_SPI3,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_spi3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_spi4 = {
> +	.gate_id = GATE_SPI4,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_spi4", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_spi5 = {
> +	.gate_id = GATE_SPI5,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_spi5", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_spi6 = {
> +	.gate_id = GATE_SPI6,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_spi6", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_spi7 = {
> +	.gate_id = GATE_SPI7,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_spi7", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_spi8 = {
> +	.gate_id = GATE_SPI8,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_spi8", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_spi1 = {
> +	.gate_id = GATE_SPI1,
> +	.hw.init = CLK_HW_INIT("ck_ker_spi1", "ck_flexgen_16", &clk_stm32_gate_ops,
> +			       CLK_SET_RATE_PARENT),
> +};
> +
> +static struct clk_stm32_gate ck_ker_spi2 = {
> +	.gate_id = GATE_SPI2,
> +	.hw.init = CLK_HW_INIT("ck_ker_spi2", "ck_flexgen_10", &clk_stm32_gate_ops,
> +			       CLK_SET_RATE_PARENT),
> +};
> +
> +static struct clk_stm32_gate ck_ker_spi3 = {
> +	.gate_id = GATE_SPI3,
> +	.hw.init = CLK_HW_INIT("ck_ker_spi3", "ck_flexgen_10", &clk_stm32_gate_ops,
> +			       CLK_SET_RATE_PARENT),
> +};
> +
> +static struct clk_stm32_gate ck_ker_spi4 = {
> +	.gate_id = GATE_SPI4,
> +	.hw.init = CLK_HW_INIT("ck_ker_spi4", "ck_flexgen_17", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_spi5 = {
> +	.gate_id = GATE_SPI5,
> +	.hw.init = CLK_HW_INIT("ck_ker_spi5", "ck_flexgen_17", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_spi6 = {
> +	.gate_id = GATE_SPI6,
> +	.hw.init = CLK_HW_INIT("ck_ker_spi6", "ck_flexgen_18", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_spi7 = {
> +	.gate_id = GATE_SPI7,
> +	.hw.init = CLK_HW_INIT("ck_ker_spi7", "ck_flexgen_18", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_spi8 = {
> +	.gate_id = GATE_SPI8,
> +	.hw.init = CLK_HW_INIT("ck_ker_spi8", "ck_flexgen_37", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* Timers */
> +static struct clk_stm32_gate ck_icn_p_tim2 = {
> +	.gate_id = GATE_TIM2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim3 = {
> +	.gate_id = GATE_TIM3,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim4 = {
> +	.gate_id = GATE_TIM4,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim4", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim5 = {
> +	.gate_id = GATE_TIM5,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim5", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim6 = {
> +	.gate_id = GATE_TIM6,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim6", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim7 = {
> +	.gate_id = GATE_TIM7,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim7", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim10 = {
> +	.gate_id = GATE_TIM10,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim10", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim11 = {
> +	.gate_id = GATE_TIM11,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim11", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim12 = {
> +	.gate_id = GATE_TIM12,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim12", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim13 = {
> +	.gate_id = GATE_TIM13,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim13", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim14 = {
> +	.gate_id = GATE_TIM14,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim14", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim1 = {
> +	.gate_id = GATE_TIM1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim1", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim8 = {
> +	.gate_id = GATE_TIM8,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim8", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim15 = {
> +	.gate_id = GATE_TIM15,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim15", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim16 = {
> +	.gate_id = GATE_TIM16,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim16", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim17 = {
> +	.gate_id = GATE_TIM17,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim17", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_tim20 = {
> +	.gate_id = GATE_TIM20,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_tim20", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim2 = {
> +	.gate_id = GATE_TIM2,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim2", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim3 = {
> +	.gate_id = GATE_TIM3,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim3", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim4 = {
> +	.gate_id = GATE_TIM4,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim4", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim5 = {
> +	.gate_id = GATE_TIM5,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim5", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim6 = {
> +	.gate_id = GATE_TIM6,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim6", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim7 = {
> +	.gate_id = GATE_TIM7,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim7", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim10 = {
> +	.gate_id = GATE_TIM10,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim10", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim11 = {
> +	.gate_id = GATE_TIM11,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim11", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim12 = {
> +	.gate_id = GATE_TIM12,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim12", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim13 = {
> +	.gate_id = GATE_TIM13,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim13", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim14 = {
> +	.gate_id = GATE_TIM14,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim14", "timg1_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim1 = {
> +	.gate_id = GATE_TIM1,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim1", "timg2_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim8 = {
> +	.gate_id = GATE_TIM8,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim8", "timg2_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim15 = {
> +	.gate_id = GATE_TIM15,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim15", "timg2_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim16 = {
> +	.gate_id = GATE_TIM16,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim16", "timg2_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim17 = {
> +	.gate_id = GATE_TIM17,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim17", "timg2_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_tim20 = {
> +	.gate_id = GATE_TIM20,
> +	.hw.init = CLK_HW_INIT("ck_ker_tim20", "timg2_ck", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* UART/USART */
> +static struct clk_stm32_gate ck_icn_p_usart2 = {
> +	.gate_id = GATE_USART2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_usart2", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_usart3 = {
> +	.gate_id = GATE_USART3,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_usart3", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_uart4 = {
> +	.gate_id = GATE_UART4,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_uart4", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_uart5 = {
> +	.gate_id = GATE_UART5,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_uart5", "ck_icn_apb1", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_usart1 = {
> +	.gate_id = GATE_USART1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_usart1", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_usart6 = {
> +	.gate_id = GATE_USART6,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_usart6", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_uart7 = {
> +	.gate_id = GATE_UART7,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_uart7", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_uart8 = {
> +	.gate_id = GATE_UART8,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_uart8", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_uart9 = {
> +	.gate_id = GATE_UART9,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_uart9", "ck_icn_apb2", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_usart2 = {
> +	.gate_id = GATE_USART2,
> +	.hw.init = CLK_HW_INIT("ck_ker_usart2", "ck_flexgen_08", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_uart4 = {
> +	.gate_id = GATE_UART4,
> +	.hw.init = CLK_HW_INIT("ck_ker_uart4", "ck_flexgen_08", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_usart3 = {
> +	.gate_id = GATE_USART3,
> +	.hw.init = CLK_HW_INIT("ck_ker_usart3", "ck_flexgen_09", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_uart5 = {
> +	.gate_id = GATE_UART5,
> +	.hw.init = CLK_HW_INIT("ck_ker_uart5", "ck_flexgen_09", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_usart1 = {
> +	.gate_id = GATE_USART1,
> +	.hw.init = CLK_HW_INIT("ck_ker_usart1", "ck_flexgen_19", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_usart6 = {
> +	.gate_id = GATE_USART6,
> +	.hw.init = CLK_HW_INIT("ck_ker_usart6", "ck_flexgen_20", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_uart7 = {
> +	.gate_id = GATE_UART7,
> +	.hw.init = CLK_HW_INIT("ck_ker_uart7", "ck_flexgen_21", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_uart8 = {
> +	.gate_id = GATE_UART8,
> +	.hw.init = CLK_HW_INIT("ck_ker_uart8", "ck_flexgen_21", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_uart9 = {
> +	.gate_id = GATE_UART9,
> +	.hw.init = CLK_HW_INIT("ck_ker_uart9", "ck_flexgen_22", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* USB2PHY1 */
> +static struct clk_stm32_composite ck_ker_usb2phy1 = {
> +	.gate_id = GATE_USB2PHY1,
> +	.mux_id = MUX_USB2PHY1,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_usb2phy1", usb2phy1_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +/* USB2H */
> +static struct clk_stm32_gate ck_icn_m_usb2ehci = {
> +	.gate_id = GATE_USB2,
> +	.hw.init = CLK_HW_INIT("ck_icn_m_usb2ehci", "ck_icn_hsl", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_m_usb2ohci = {
> +	.gate_id = GATE_USB2,
> +	.hw.init = CLK_HW_INIT("ck_icn_m_usb2ohci", "ck_icn_hsl", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* USB2PHY2 */
> +static struct clk_stm32_composite ck_ker_usb2phy2_en = {
> +	.gate_id = GATE_USB2PHY2,
> +	.mux_id = MUX_USB2PHY2,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_usb2phy2_en", usb2phy2_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +/* USB3 PCIe COMBOPHY */
> +static struct clk_stm32_gate ck_icn_p_usb3pciephy = {
> +	.gate_id = GATE_USB3PCIEPHY,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_usb3pciephy", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_composite ck_ker_usb3pciephy = {
> +	.gate_id = GATE_USB3PCIEPHY,
> +	.mux_id = MUX_USB3PCIEPHY,
> +	.div_id = NO_STM32_DIV,
> +	.hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_usb3pciephy", usb3pciphy_src,
> +					    &clk_stm32_composite_ops, 0),
> +};
> +
> +/* USB3 DRD */
> +static struct clk_stm32_gate ck_icn_m_usb3dr = {
> +	.gate_id = GATE_USB3DR,
> +	.hw.init = CLK_HW_INIT("ck_icn_m_usb3dr", "ck_icn_hsl", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_usb2phy2 = {
> +	.gate_id = GATE_USB3DR,
> +	.hw.init = CLK_HW_INIT("ck_ker_usb2phy2", "ck_flexgen_58", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* USBTC */
> +static struct clk_stm32_gate ck_icn_p_usbtc = {
> +	.gate_id = GATE_USBTC,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_usbtc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_usbtc = {
> +	.gate_id = GATE_USBTC,
> +	.hw.init = CLK_HW_INIT("ck_ker_usbtc", "ck_flexgen_35", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* VDEC / VENC */
> +static struct clk_stm32_gate ck_icn_p_vdec = {
> +	.gate_id = GATE_VDEC,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_vdec", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_venc = {
> +	.gate_id = GATE_VENC,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_venc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* VREF */
> +static struct clk_stm32_gate ck_icn_p_vref = {
> +	.gate_id = GATE_VREF,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_vref", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* WWDG */
> +static struct clk_stm32_gate ck_icn_p_wwdg1 = {
> +	.gate_id = GATE_WWDG1,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_wwdg1", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_wwdg2 = {
> +	.gate_id = GATE_WWDG2,
> +	.hw.init = CLK_HW_INIT("ck_icn_p_wwdg2", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +enum security_clk {
> +	SECF_NONE,
> +};
> +
> +static const struct clock_config stm32mp25_clock_cfg[] = {
> +	STM32_GATE_CFG(CK_BUS_ETH1,		ck_icn_p_eth1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_ETH2,		ck_icn_p_eth2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_PCIE,		ck_icn_p_pcie,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_ETHSW,		ck_icn_p_ethsw,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_ADC12,		ck_icn_p_adc12,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_ADC3,		ck_icn_p_adc3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_CCI,		ck_icn_p_cci,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_CRC,		ck_icn_p_crc,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_MDF1,		ck_icn_p_mdf1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_OSPIIOM,		ck_icn_p_ospiiom,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_HASH,		ck_icn_p_hash,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_CRYP1,		ck_icn_p_cryp1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_CRYP2,		ck_icn_p_cryp2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_ADF1,		ck_icn_p_adf1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SPI8,		ck_icn_p_spi8,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_LPUART1,		ck_icn_p_lpuart1,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I2C8,		ck_icn_p_i2c8,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_LPTIM3,		ck_icn_p_lptim3,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_LPTIM4,		ck_icn_p_lptim4,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_LPTIM5,		ck_icn_p_lptim5,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_IWDG5,		ck_icn_p_iwdg5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_WWDG2,		ck_icn_p_wwdg2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I3C4,		ck_icn_p_i3c4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SDMMC1,		ck_icn_m_sdmmc1,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SDMMC2,		ck_icn_m_sdmmc2,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SDMMC3,		ck_icn_m_sdmmc3,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_USB2OHCI,		ck_icn_m_usb2ohci,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_USB2EHCI,		ck_icn_m_usb2ehci,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_USB3DR,		ck_icn_m_usb3dr,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM2,		ck_icn_p_tim2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM3,		ck_icn_p_tim3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM4,		ck_icn_p_tim4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM5,		ck_icn_p_tim5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM6,		ck_icn_p_tim6,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM7,		ck_icn_p_tim7,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM10,		ck_icn_p_tim10,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM11,		ck_icn_p_tim11,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM12,		ck_icn_p_tim12,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM13,		ck_icn_p_tim13,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM14,		ck_icn_p_tim14,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_LPTIM1,		ck_icn_p_lptim1,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_LPTIM2,		ck_icn_p_lptim2,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SPI2,		ck_icn_p_spi2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SPI3,		ck_icn_p_spi3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SPDIFRX,		ck_icn_p_spdifrx,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_USART2,		ck_icn_p_usart2,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_USART3,		ck_icn_p_usart3,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_UART4,		ck_icn_p_uart4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_UART5,		ck_icn_p_uart5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I2C1,		ck_icn_p_i2c1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I2C2,		ck_icn_p_i2c2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I2C3,		ck_icn_p_i2c3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I2C4,		ck_icn_p_i2c4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I2C5,		ck_icn_p_i2c5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I2C6,		ck_icn_p_i2c6,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I2C7,		ck_icn_p_i2c7,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I3C1,		ck_icn_p_i3c1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I3C2,		ck_icn_p_i3c2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_I3C3,		ck_icn_p_i3c3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM1,		ck_icn_p_tim1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM8,		ck_icn_p_tim8,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM15,		ck_icn_p_tim15,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM16,		ck_icn_p_tim16,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM17,		ck_icn_p_tim17,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_TIM20,		ck_icn_p_tim20,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SAI1,		ck_icn_p_sai1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SAI2,		ck_icn_p_sai2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SAI3,		ck_icn_p_sai3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SAI4,		ck_icn_p_sai4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_USART1,		ck_icn_p_usart1,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_USART6,		ck_icn_p_usart6,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_UART7,		ck_icn_p_uart7,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_UART8,		ck_icn_p_uart8,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_UART9,		ck_icn_p_uart9,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_FDCAN,		ck_icn_p_fdcan,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SPI1,		ck_icn_p_spi1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SPI4,		ck_icn_p_spi4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SPI5,		ck_icn_p_spi5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SPI6,		ck_icn_p_spi6,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_SPI7,		ck_icn_p_spi7,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_IWDG2,		ck_icn_p_iwdg2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_IWDG3,		ck_icn_p_iwdg3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_IWDG4,		ck_icn_p_iwdg4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_WWDG1,		ck_icn_p_wwdg1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_VREF,		ck_icn_p_vref,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_HDP,		ck_icn_p_hdp,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_IS2M,		ck_icn_p_is2m,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_DSI,		ck_icn_p_dsi,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_LTDC,		ck_icn_p_ltdc,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_CSI,		ck_icn_p_csi,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_DCMIPP,		ck_icn_p_dcmipp,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_LVDS,		ck_icn_p_lvds,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_USBTC,		ck_icn_p_usbtc,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_USB3PCIEPHY,	ck_icn_p_usb3pciephy,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_VDEC,		ck_icn_p_vdec,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_VENC,		ck_icn_p_venc,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM2,		ck_ker_tim2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM3,		ck_ker_tim3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM4,		ck_ker_tim4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM5,		ck_ker_tim5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM6,		ck_ker_tim6,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM7,		ck_ker_tim7,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM10,		ck_ker_tim10,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM11,		ck_ker_tim11,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM12,		ck_ker_tim12,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM13,		ck_ker_tim13,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM14,		ck_ker_tim14,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM1,		ck_ker_tim1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM8,		ck_ker_tim8,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM15,		ck_ker_tim15,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM16,		ck_ker_tim16,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM17,		ck_ker_tim17,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_TIM20,		ck_ker_tim20,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_LPTIM1,		ck_ker_lptim1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_LPTIM2,		ck_ker_lptim2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_USART2,		ck_ker_usart2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_UART4,		ck_ker_uart4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_USART3,		ck_ker_usart3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_UART5,		ck_ker_uart5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SPI2,		ck_ker_spi2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SPI3,		ck_ker_spi3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SPDIFRX,		ck_ker_spdifrx,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I2C1,		ck_ker_i2c1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I2C2,		ck_ker_i2c2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I3C1,		ck_ker_i3c1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I3C2,		ck_ker_i3c2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I2C3,		ck_ker_i2c3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I2C5,		ck_ker_i2c5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I3C3,		ck_ker_i3c3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I2C4,		ck_ker_i2c4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I2C6,		ck_ker_i2c6,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I2C7,		ck_ker_i2c7,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SPI1,		ck_ker_spi1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SPI4,		ck_ker_spi4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SPI5,		ck_ker_spi5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SPI6,		ck_ker_spi6,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SPI7,		ck_ker_spi7,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_USART1,		ck_ker_usart1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_USART6,		ck_ker_usart6,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_UART7,		ck_ker_uart7,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_UART8,		ck_ker_uart8,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_UART9,		ck_ker_uart9,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_MDF1,		ck_ker_mdf1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SAI1,		ck_ker_sai1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SAI2,		ck_ker_sai2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SAI3,		ck_ker_sai3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SAI4,		ck_ker_sai4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_FDCAN,		ck_ker_fdcan,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_CSI,		ck_ker_csi,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_CSITXESC,		ck_ker_csitxesc,	SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_CSIPHY,		ck_ker_csiphy,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_USBTC,		ck_ker_usbtc,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I3C4,		ck_ker_i3c4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SPI8,		ck_ker_spi8,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_I2C8,		ck_ker_i2c8,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_LPUART1,		ck_ker_lpuart1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_LPTIM3,		ck_ker_lptim3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_LPTIM4,		ck_ker_lptim4,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_LPTIM5,		ck_ker_lptim5,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_ADF1,		ck_ker_adf1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SDMMC1,		ck_ker_sdmmc1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SDMMC2,		ck_ker_sdmmc2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_SDMMC3,		ck_ker_sdmmc3,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_ETH1,		ck_ker_eth1,		SECF_NONE),
> +	STM32_GATE_CFG(CK_ETH1_STP,		ck_ker_eth1stp,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_ETHSW,		ck_ker_ethsw,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_ETH2,		ck_ker_eth2,		SECF_NONE),
> +	STM32_GATE_CFG(CK_ETH2_STP,		ck_ker_eth2stp,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_ETH1PTP,		ck_ker_eth1ptp,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_ETH2PTP,		ck_ker_eth2ptp,		SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_GPU,		ck_icn_m_gpu,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_GPU,		ck_ker_gpu,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_ETHSWREF,		ck_ker_ethswref,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_ETHSWACMCFG,	ck_icn_p_ethsw_acm_cfg,	SECF_NONE),
> +	STM32_GATE_CFG(CK_BUS_ETHSWACMMSG, ck_icn_p_ethsw_acm_msg,	SECF_NONE),
> +	STM32_GATE_CFG(CK_ETH1_MAC,		ck_ker_eth1mac,		SECF_NONE),
> +	STM32_GATE_CFG(CK_ETH1_TX,		ck_ker_eth1tx,		SECF_NONE),
> +	STM32_GATE_CFG(CK_ETH1_RX,		ck_ker_eth1rx,		SECF_NONE),
> +	STM32_GATE_CFG(CK_ETH2_MAC,		ck_ker_eth2mac,		SECF_NONE),
> +	STM32_GATE_CFG(CK_ETH2_TX,		ck_ker_eth2tx,		SECF_NONE),
> +	STM32_GATE_CFG(CK_ETH2_RX,		ck_ker_eth2rx,		SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_MCO1,		ck_mco1,		SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_MCO2,		ck_mco2,		SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_KER_ADC12,	ck_ker_adc12,		SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_KER_ADC3,	ck_ker_adc3,		SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_KER_USB2PHY1,	ck_ker_usb2phy1,	SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_USB2PHY2,		ck_ker_usb2phy2,	SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_KER_USB2PHY2EN,	ck_ker_usb2phy2_en,	SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_KER_USB3PCIEPHY,	ck_ker_usb3pciephy,	SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_KER_DSIBLANE,	clk_lanebyte,		SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_KER_DSIPHY,	clk_phy_dsi,		SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_KER_LVDSPHY,	ck_ker_lvdsphy,		SECF_NONE),
> +	STM32_COMPOSITE_CFG(CK_KER_DTS,		ck_ker_dts,		SECF_NONE),
> +	STM32_GATE_CFG(CK_KER_LTDC,		ck_ker_ltdc,		SECF_NONE),
> +};
> +
> +#define RESET_MP25(id, _offset, _bit_idx, _set_clr)	\
> +	[id] = &(struct stm32_reset_cfg){		\
> +		.offset		= (_offset),		\
> +		.bit_idx	= (_bit_idx),		\
> +		.set_clr	= (_set_clr),		\
> +	}
> +
> +static const struct stm32_reset_cfg *stm32mp25_reset_cfg[STM32MP25_LAST_RESET] = {
> +	RESET_MP25(TIM1_R,		RCC_TIM1CFGR,		0,	0),
> +	RESET_MP25(TIM2_R,		RCC_TIM2CFGR,		0,	0),
> +	RESET_MP25(TIM3_R,		RCC_TIM3CFGR,		0,	0),
> +	RESET_MP25(TIM4_R,		RCC_TIM4CFGR,		0,	0),
> +	RESET_MP25(TIM5_R,		RCC_TIM5CFGR,		0,	0),
> +	RESET_MP25(TIM6_R,		RCC_TIM6CFGR,		0,	0),
> +	RESET_MP25(TIM7_R,		RCC_TIM7CFGR,		0,	0),
> +	RESET_MP25(TIM8_R,		RCC_TIM8CFGR,		0,	0),
> +	RESET_MP25(TIM10_R,		RCC_TIM10CFGR,		0,	0),
> +	RESET_MP25(TIM11_R,		RCC_TIM11CFGR,		0,	0),
> +	RESET_MP25(TIM12_R,		RCC_TIM12CFGR,		0,	0),
> +	RESET_MP25(TIM13_R,		RCC_TIM13CFGR,		0,	0),
> +	RESET_MP25(TIM14_R,		RCC_TIM14CFGR,		0,	0),
> +	RESET_MP25(TIM15_R,		RCC_TIM15CFGR,		0,	0),
> +	RESET_MP25(TIM16_R,		RCC_TIM16CFGR,		0,	0),
> +	RESET_MP25(TIM17_R,		RCC_TIM17CFGR,		0,	0),
> +	RESET_MP25(TIM20_R,		RCC_TIM20CFGR,		0,	0),
> +	RESET_MP25(LPTIM1_R,		RCC_LPTIM1CFGR,		0,	0),
> +	RESET_MP25(LPTIM2_R,		RCC_LPTIM2CFGR,		0,	0),
> +	RESET_MP25(LPTIM3_R,		RCC_LPTIM3CFGR,		0,	0),
> +	RESET_MP25(LPTIM4_R,		RCC_LPTIM4CFGR,		0,	0),
> +	RESET_MP25(LPTIM5_R,		RCC_LPTIM5CFGR,		0,	0),
> +	RESET_MP25(SPI1_R,		RCC_SPI1CFGR,		0,	0),
> +	RESET_MP25(SPI2_R,		RCC_SPI2CFGR,		0,	0),
> +	RESET_MP25(SPI3_R,		RCC_SPI3CFGR,		0,	0),
> +	RESET_MP25(SPI4_R,		RCC_SPI4CFGR,		0,	0),
> +	RESET_MP25(SPI5_R,		RCC_SPI5CFGR,		0,	0),
> +	RESET_MP25(SPI6_R,		RCC_SPI6CFGR,		0,	0),
> +	RESET_MP25(SPI7_R,		RCC_SPI7CFGR,		0,	0),
> +	RESET_MP25(SPI8_R,		RCC_SPI8CFGR,		0,	0),
> +	RESET_MP25(SPDIFRX_R,		RCC_SPDIFRXCFGR,	0,	0),
> +	RESET_MP25(USART1_R,		RCC_USART1CFGR,		0,	0),
> +	RESET_MP25(USART2_R,		RCC_USART2CFGR,		0,	0),
> +	RESET_MP25(USART3_R,		RCC_USART3CFGR,		0,	0),
> +	RESET_MP25(UART4_R,		RCC_UART4CFGR,		0,	0),
> +	RESET_MP25(UART5_R,		RCC_UART5CFGR,		0,	0),
> +	RESET_MP25(USART6_R,		RCC_USART6CFGR,		0,	0),
> +	RESET_MP25(UART7_R,		RCC_UART7CFGR,		0,	0),
> +	RESET_MP25(UART8_R,		RCC_UART8CFGR,		0,	0),
> +	RESET_MP25(UART9_R,		RCC_UART9CFGR,		0,	0),
> +	RESET_MP25(LPUART1_R,		RCC_LPUART1CFGR,	0,	0),
> +	RESET_MP25(IS2M_R,		RCC_IS2MCFGR,		0,	0),
> +	RESET_MP25(I2C1_R,		RCC_I2C1CFGR,		0,	0),
> +	RESET_MP25(I2C2_R,		RCC_I2C2CFGR,		0,	0),
> +	RESET_MP25(I2C3_R,		RCC_I2C3CFGR,		0,	0),
> +	RESET_MP25(I2C4_R,		RCC_I2C4CFGR,		0,	0),
> +	RESET_MP25(I2C5_R,		RCC_I2C5CFGR,		0,	0),
> +	RESET_MP25(I2C6_R,		RCC_I2C6CFGR,		0,	0),
> +	RESET_MP25(I2C7_R,		RCC_I2C7CFGR,		0,	0),
> +	RESET_MP25(I2C8_R,		RCC_I2C8CFGR,		0,	0),
> +	RESET_MP25(SAI1_R,		RCC_SAI1CFGR,		0,	0),
> +	RESET_MP25(SAI2_R,		RCC_SAI2CFGR,		0,	0),
> +	RESET_MP25(SAI3_R,		RCC_SAI3CFGR,		0,	0),
> +	RESET_MP25(SAI4_R,		RCC_SAI4CFGR,		0,	0),
> +	RESET_MP25(MDF1_R,		RCC_MDF1CFGR,		0,	0),
> +	RESET_MP25(MDF2_R,		RCC_ADF1CFGR,		0,	0),
> +	RESET_MP25(FDCAN_R,		RCC_FDCANCFGR,		0,	0),
> +	RESET_MP25(HDP_R,		RCC_HDPCFGR,		0,	0),
> +	RESET_MP25(ADC12_R,		RCC_ADC12CFGR,		0,	0),
> +	RESET_MP25(ADC3_R,		RCC_ADC3CFGR,		0,	0),
> +	RESET_MP25(ETH1_R,		RCC_ETH1CFGR,		0,	0),
> +	RESET_MP25(ETH2_R,		RCC_ETH2CFGR,		0,	0),
> +	RESET_MP25(USB2_R,		RCC_USB2CFGR,		0,	0),
> +	RESET_MP25(USB2PHY1_R,		RCC_USB2PHY1CFGR,	0,	0),
> +	RESET_MP25(USB2PHY2_R,		RCC_USB2PHY2CFGR,	0,	0),
> +	RESET_MP25(USB3DR_R,		RCC_USB3DRCFGR,		0,	0),
> +	RESET_MP25(USB3PCIEPHY_R,	RCC_USB3PCIEPHYCFGR,	0,	0),
> +	RESET_MP25(USBTC_R,		RCC_USBTCCFGR,		0,	0),
> +	RESET_MP25(ETHSW_R,		RCC_ETHSWCFGR,		0,	0),
> +	RESET_MP25(SDMMC1_R,		RCC_SDMMC1CFGR,		0,	0),
> +	RESET_MP25(SDMMC1DLL_R,		RCC_SDMMC1CFGR,		16,	0),
> +	RESET_MP25(SDMMC2_R,		RCC_SDMMC2CFGR,		0,	0),
> +	RESET_MP25(SDMMC2DLL_R,		RCC_SDMMC2CFGR,		16,	0),
> +	RESET_MP25(SDMMC3_R,		RCC_SDMMC3CFGR,		0,	0),
> +	RESET_MP25(SDMMC3DLL_R,		RCC_SDMMC3CFGR,		16,	0),
> +	RESET_MP25(GPU_R,		RCC_GPUCFGR,		0,	0),
> +	RESET_MP25(LTDC_R,		RCC_LTDCCFGR,		0,	0),
> +	RESET_MP25(DSI_R,		RCC_DSICFGR,		0,	0),
> +	RESET_MP25(LVDS_R,		RCC_LVDSCFGR,		0,	0),
> +	RESET_MP25(CSI_R,		RCC_CSICFGR,		0,	0),
> +	RESET_MP25(DCMIPP_R,		RCC_DCMIPPCFGR,		0,	0),
> +	RESET_MP25(CCI_R,		RCC_CCICFGR,		0,	0),
> +	RESET_MP25(VDEC_R,		RCC_VDECCFGR,		0,	0),
> +	RESET_MP25(VENC_R,		RCC_VENCCFGR,		0,	0),
> +	RESET_MP25(WWDG1_R,		RCC_WWDG1CFGR,		0,	0),
> +	RESET_MP25(WWDG2_R,		RCC_WWDG2CFGR,		0,	0),
> +	RESET_MP25(VREF_R,		RCC_VREFCFGR,		0,	0),
> +	RESET_MP25(DTS_R,		RCC_DTSCFGR,		0,	0),
> +	RESET_MP25(CRC_R,		RCC_CRCCFGR,		0,	0),
> +	RESET_MP25(SERC_R,		RCC_SERCCFGR,		0,	0),
> +	RESET_MP25(OSPIIOM_R,		RCC_OSPIIOMCFGR,	0,	0),
> +	RESET_MP25(I3C1_R,		RCC_I3C1CFGR,		0,	0),
> +	RESET_MP25(I3C2_R,		RCC_I3C2CFGR,		0,	0),
> +	RESET_MP25(I3C3_R,		RCC_I3C3CFGR,		0,	0),
> +	RESET_MP25(I3C4_R,		RCC_I3C4CFGR,		0,	0),
> +	RESET_MP25(IWDG2_KER_R,		RCC_IWDGC1CFGSETR,	18,	1),
> +	RESET_MP25(IWDG4_KER_R,		RCC_IWDGC2CFGSETR,	18,	1),
> +	RESET_MP25(RNG_R,		RCC_RNGCFGR,		0,	0),
> +	RESET_MP25(PKA_R,		RCC_PKACFGR,		0,	0),
> +	RESET_MP25(SAES_R,		RCC_SAESCFGR,		0,	0),
> +	RESET_MP25(HASH_R,		RCC_HASHCFGR,		0,	0),
> +	RESET_MP25(CRYP1_R,		RCC_CRYP1CFGR,		0,	0),
> +	RESET_MP25(CRYP2_R,		RCC_CRYP2CFGR,		0,	0),
> +	RESET_MP25(PCIE_R,		RCC_PCIECFGR,		0,	0),
> +};
> +
> +static u16 stm32mp25_cpt_gate[GATE_NB];
> +
> +static struct clk_stm32_clock_data stm32mp25_clock_data = {
> +	.gate_cpt	= stm32mp25_cpt_gate,
> +	.gates		= stm32mp25_gates,
> +	.muxes		= stm32mp25_muxes,
> +};
> +
> +static struct clk_stm32_reset_data stm32mp25_reset_data = {
> +	.reset_lines	= stm32mp25_reset_cfg,
> +	.nr_lines	= ARRAY_SIZE(stm32mp25_reset_cfg),
> +};
> +
> +static const struct stm32_rcc_match_data stm32mp25_data = {
> +	.tab_clocks	= stm32mp25_clock_cfg,
> +	.num_clocks	= ARRAY_SIZE(stm32mp25_clock_cfg),
> +	.maxbinding	= STM32MP25_LAST_CLK,
> +	.clock_data	= &stm32mp25_clock_data,
> +	.reset_data	= &stm32mp25_reset_data,
> +};
> +
> +static const struct of_device_id stm32mp25_match_data[] = {
> +	{
> +		.compatible = "st,stm32mp25-rcc",
> +		.data = &stm32mp25_data,
> +	},
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, stm32mp25_match_data);
> +
> +static int get_clock_deps(struct device *dev)
> +{
> +	static const char * const clock_deps_name[] = {
> +		"hsi", "hse", "msi", "lsi", "lse",
> +	};
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(clock_deps_name); i++) {
> +		struct clk *clk;
> +
> +		clk = of_clk_get_by_name(dev_of_node(dev), clock_deps_name[i]);
> +		if (IS_ERR(clk))
> +			return PTR_ERR(clk);
> +
> +		clk_put(clk);
> +	}
> +
> +	return 0;
> +}
> +
> +static int stm32mp25_rcc_clocks_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	void __iomem *base;
> +	int ret;
> +
> +	ret = get_clock_deps(dev);
> +	if (ret)
> +		return ret;
> +
> +	base = devm_of_iomap(dev, dev->of_node, 0, NULL);
> +	if (WARN_ON(IS_ERR(base)))
> +		return PTR_ERR(base);
> +
> +	return stm32_rcc_init(dev, stm32mp25_match_data, base);
> +}
> +
> +static int stm32mp25_rcc_clocks_remove(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *child, *np = dev_of_node(dev);
> +
> +	for_each_available_child_of_node(np, child)
> +		of_clk_del_provider(child);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver stm32mp25_rcc_clocks_driver = {
> +	.driver	= {
> +		.name = "stm32mp25_rcc",
> +		.of_match_table = stm32mp25_match_data,
> +	},
> +	.probe = stm32mp25_rcc_clocks_probe,
> +	.remove = stm32mp25_rcc_clocks_remove,
> +};
> +
> +static int __init stm32mp25_clocks_init(void)
> +{
> +	return platform_driver_register(&stm32mp25_rcc_clocks_driver);
> +}
> +
> +core_initcall(stm32mp25_clocks_init);
> diff --git a/drivers/clk/stm32/reset-stm32.c b/drivers/clk/stm32/reset-stm32.c
> index 14c2ee1eebee..5a8f525842ce 100644
> --- a/drivers/clk/stm32/reset-stm32.c
> +++ b/drivers/clk/stm32/reset-stm32.c
> @@ -19,6 +19,7 @@ struct stm32_reset_data {
>   	struct reset_controller_dev	rcdev;
>   	void __iomem			*membase;
>   	u32				clear_offset;
> +	const struct stm32_reset_cfg	**reset_lines;
>   };
>   
>   static inline struct stm32_reset_data *
> @@ -27,22 +28,46 @@ to_stm32_reset_data(struct reset_controller_dev *rcdev)
>   	return container_of(rcdev, struct stm32_reset_data, rcdev);
>   }
>   
> +static const struct stm32_reset_cfg *stm32_get_reset_line(struct reset_controller_dev *rcdev,
> +							  unsigned long id,
> +							  struct stm32_reset_cfg *line)
> +{
> +	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
> +
> +	if (!data->reset_lines) {
> +		int reg_width = sizeof(u32);
> +		int bank = id / (reg_width * BITS_PER_BYTE);
> +		int offset = id % (reg_width * BITS_PER_BYTE);
> +
> +		line->offset = bank * reg_width;
> +		line->bit_idx = offset;
> +		line->set_clr = (data->clear_offset ? true : false);
> +
> +		return line;
> +	}
> +
> +	return data->reset_lines[id];
> +}
> +
>   static int stm32_reset_update(struct reset_controller_dev *rcdev,
>   			      unsigned long id, bool assert)
>   {
>   	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
> -	int reg_width = sizeof(u32);
> -	int bank = id / (reg_width * BITS_PER_BYTE);
> -	int offset = id % (reg_width * BITS_PER_BYTE);
> +	struct stm32_reset_cfg line_reset;
> +	const struct stm32_reset_cfg *ptr_line;
>   
> -	if (data->clear_offset) {
> +	ptr_line = stm32_get_reset_line(rcdev, id, &line_reset);
> +	if (!ptr_line)
> +		return -EPERM;
> +
> +	if (ptr_line->set_clr) {
>   		void __iomem *addr;
>   
> -		addr = data->membase + (bank * reg_width);
> +		addr = data->membase + ptr_line->offset;
>   		if (!assert)
>   			addr += data->clear_offset;
>   
> -		writel(BIT(offset), addr);
> +		writel(BIT(ptr_line->bit_idx), addr);
>   
>   	} else {
>   		unsigned long flags;
> @@ -50,14 +75,14 @@ static int stm32_reset_update(struct reset_controller_dev *rcdev,
>   
>   		spin_lock_irqsave(&data->lock, flags);
>   
> -		reg = readl(data->membase + (bank * reg_width));
> +		reg = readl(data->membase + ptr_line->offset);
>   
>   		if (assert)
> -			reg |= BIT(offset);
> +			reg |= BIT(ptr_line->bit_idx);
>   		else
> -			reg &= ~BIT(offset);
> +			reg &= ~BIT(ptr_line->bit_idx);
>   
> -		writel(reg, data->membase + (bank * reg_width));
> +		writel(reg, data->membase + ptr_line->offset);
>   
>   		spin_unlock_irqrestore(&data->lock, flags);
>   	}
> @@ -81,14 +106,17 @@ static int stm32_reset_status(struct reset_controller_dev *rcdev,
>   			      unsigned long id)
>   {
>   	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
> -	int reg_width = sizeof(u32);
> -	int bank = id / (reg_width * BITS_PER_BYTE);
> -	int offset = id % (reg_width * BITS_PER_BYTE);
> +	struct stm32_reset_cfg line_reset;
> +	const struct stm32_reset_cfg *ptr_line;
>   	u32 reg;
>   
> -	reg = readl(data->membase + (bank * reg_width));
> +	ptr_line = stm32_get_reset_line(rcdev, id, &line_reset);
> +	if (!ptr_line)
> +		return -EPERM;
> +
> +	reg = readl(data->membase + ptr_line->offset);
>   
> -	return !!(reg & BIT(offset));
> +	return !!(reg & BIT(ptr_line->bit_idx));
>   }
>   
>   static const struct reset_control_ops stm32_reset_ops = {
> @@ -113,6 +141,7 @@ int stm32_rcc_reset_init(struct device *dev, struct clk_stm32_reset_data *data,
>   	reset_data->rcdev.ops = &stm32_reset_ops;
>   	reset_data->rcdev.of_node = dev_of_node(dev);
>   	reset_data->rcdev.nr_resets = data->nr_lines;
> +	reset_data->reset_lines = data->reset_lines;
>   	reset_data->clear_offset = data->clear_offset;
>   
>   	return reset_controller_register(&reset_data->rcdev);
> diff --git a/drivers/clk/stm32/reset-stm32.h b/drivers/clk/stm32/reset-stm32.h
> index 8cf1cc9be480..f79cad21dfd6 100644
> --- a/drivers/clk/stm32/reset-stm32.h
> +++ b/drivers/clk/stm32/reset-stm32.h
> @@ -4,8 +4,15 @@
>    * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
>    */
>   
> +struct stm32_reset_cfg {
> +	u16 offset;
> +	u8 bit_idx;
> +	bool set_clr;
> +};
> +
>   struct clk_stm32_reset_data {
>   	const struct reset_control_ops *ops;
> +	const struct stm32_reset_cfg **reset_lines;
>   	unsigned int nr_lines;
>   	u32 clear_offset;
>   };
> diff --git a/drivers/clk/stm32/stm32mp25_rcc.h b/drivers/clk/stm32/stm32mp25_rcc.h
> new file mode 100644
> index 000000000000..6ba13cc2ae16
> --- /dev/null
> +++ b/drivers/clk/stm32/stm32mp25_rcc.h
> @@ -0,0 +1,712 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
> + * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
> + */
> +
> +#ifndef STM32MP25_RCC_H
> +#define STM32MP25_RCC_H
> +
> +#define RCC_SECCFGR0				0x0
> +#define RCC_SECCFGR1				0x4
> +#define RCC_SECCFGR2				0x8
> +#define RCC_SECCFGR3				0xC
> +#define RCC_PRIVCFGR0				0x10
> +#define RCC_PRIVCFGR1				0x14
> +#define RCC_PRIVCFGR2				0x18
> +#define RCC_PRIVCFGR3				0x1C
> +#define RCC_RCFGLOCKR0				0x20
> +#define RCC_RCFGLOCKR1				0x24
> +#define RCC_RCFGLOCKR2				0x28
> +#define RCC_RCFGLOCKR3				0x2C
> +#define RCC_R0CIDCFGR				0x30
> +#define RCC_R0SEMCR				0x34
> +#define RCC_R1CIDCFGR				0x38
> +#define RCC_R1SEMCR				0x3C
> +#define RCC_R2CIDCFGR				0x40
> +#define RCC_R2SEMCR				0x44
> +#define RCC_R3CIDCFGR				0x48
> +#define RCC_R3SEMCR				0x4C
> +#define RCC_R4CIDCFGR				0x50
> +#define RCC_R4SEMCR				0x54
> +#define RCC_R5CIDCFGR				0x58
> +#define RCC_R5SEMCR				0x5C
> +#define RCC_R6CIDCFGR				0x60
> +#define RCC_R6SEMCR				0x64
> +#define RCC_R7CIDCFGR				0x68
> +#define RCC_R7SEMCR				0x6C
> +#define RCC_R8CIDCFGR				0x70
> +#define RCC_R8SEMCR				0x74
> +#define RCC_R9CIDCFGR				0x78
> +#define RCC_R9SEMCR				0x7C
> +#define RCC_R10CIDCFGR				0x80
> +#define RCC_R10SEMCR				0x84
> +#define RCC_R11CIDCFGR				0x88
> +#define RCC_R11SEMCR				0x8C
> +#define RCC_R12CIDCFGR				0x90
> +#define RCC_R12SEMCR				0x94
> +#define RCC_R13CIDCFGR				0x98
> +#define RCC_R13SEMCR				0x9C
> +#define RCC_R14CIDCFGR				0xA0
> +#define RCC_R14SEMCR				0xA4
> +#define RCC_R15CIDCFGR				0xA8
> +#define RCC_R15SEMCR				0xAC
> +#define RCC_R16CIDCFGR				0xB0
> +#define RCC_R16SEMCR				0xB4
> +#define RCC_R17CIDCFGR				0xB8
> +#define RCC_R17SEMCR				0xBC
> +#define RCC_R18CIDCFGR				0xC0
> +#define RCC_R18SEMCR				0xC4
> +#define RCC_R19CIDCFGR				0xC8
> +#define RCC_R19SEMCR				0xCC
> +#define RCC_R20CIDCFGR				0xD0
> +#define RCC_R20SEMCR				0xD4
> +#define RCC_R21CIDCFGR				0xD8
> +#define RCC_R21SEMCR				0xDC
> +#define RCC_R22CIDCFGR				0xE0
> +#define RCC_R22SEMCR				0xE4
> +#define RCC_R23CIDCFGR				0xE8
> +#define RCC_R23SEMCR				0xEC
> +#define RCC_R24CIDCFGR				0xF0
> +#define RCC_R24SEMCR				0xF4
> +#define RCC_R25CIDCFGR				0xF8
> +#define RCC_R25SEMCR				0xFC
> +#define RCC_R26CIDCFGR				0x100
> +#define RCC_R26SEMCR				0x104
> +#define RCC_R27CIDCFGR				0x108
> +#define RCC_R27SEMCR				0x10C
> +#define RCC_R28CIDCFGR				0x110
> +#define RCC_R28SEMCR				0x114
> +#define RCC_R29CIDCFGR				0x118
> +#define RCC_R29SEMCR				0x11C
> +#define RCC_R30CIDCFGR				0x120
> +#define RCC_R30SEMCR				0x124
> +#define RCC_R31CIDCFGR				0x128
> +#define RCC_R31SEMCR				0x12C
> +#define RCC_R32CIDCFGR				0x130
> +#define RCC_R32SEMCR				0x134
> +#define RCC_R33CIDCFGR				0x138
> +#define RCC_R33SEMCR				0x13C
> +#define RCC_R34CIDCFGR				0x140
> +#define RCC_R34SEMCR				0x144
> +#define RCC_R35CIDCFGR				0x148
> +#define RCC_R35SEMCR				0x14C
> +#define RCC_R36CIDCFGR				0x150
> +#define RCC_R36SEMCR				0x154
> +#define RCC_R37CIDCFGR				0x158
> +#define RCC_R37SEMCR				0x15C
> +#define RCC_R38CIDCFGR				0x160
> +#define RCC_R38SEMCR				0x164
> +#define RCC_R39CIDCFGR				0x168
> +#define RCC_R39SEMCR				0x16C
> +#define RCC_R40CIDCFGR				0x170
> +#define RCC_R40SEMCR				0x174
> +#define RCC_R41CIDCFGR				0x178
> +#define RCC_R41SEMCR				0x17C
> +#define RCC_R42CIDCFGR				0x180
> +#define RCC_R42SEMCR				0x184
> +#define RCC_R43CIDCFGR				0x188
> +#define RCC_R43SEMCR				0x18C
> +#define RCC_R44CIDCFGR				0x190
> +#define RCC_R44SEMCR				0x194
> +#define RCC_R45CIDCFGR				0x198
> +#define RCC_R45SEMCR				0x19C
> +#define RCC_R46CIDCFGR				0x1A0
> +#define RCC_R46SEMCR				0x1A4
> +#define RCC_R47CIDCFGR				0x1A8
> +#define RCC_R47SEMCR				0x1AC
> +#define RCC_R48CIDCFGR				0x1B0
> +#define RCC_R48SEMCR				0x1B4
> +#define RCC_R49CIDCFGR				0x1B8
> +#define RCC_R49SEMCR				0x1BC
> +#define RCC_R50CIDCFGR				0x1C0
> +#define RCC_R50SEMCR				0x1C4
> +#define RCC_R51CIDCFGR				0x1C8
> +#define RCC_R51SEMCR				0x1CC
> +#define RCC_R52CIDCFGR				0x1D0
> +#define RCC_R52SEMCR				0x1D4
> +#define RCC_R53CIDCFGR				0x1D8
> +#define RCC_R53SEMCR				0x1DC
> +#define RCC_R54CIDCFGR				0x1E0
> +#define RCC_R54SEMCR				0x1E4
> +#define RCC_R55CIDCFGR				0x1E8
> +#define RCC_R55SEMCR				0x1EC
> +#define RCC_R56CIDCFGR				0x1F0
> +#define RCC_R56SEMCR				0x1F4
> +#define RCC_R57CIDCFGR				0x1F8
> +#define RCC_R57SEMCR				0x1FC
> +#define RCC_R58CIDCFGR				0x200
> +#define RCC_R58SEMCR				0x204
> +#define RCC_R59CIDCFGR				0x208
> +#define RCC_R59SEMCR				0x20C
> +#define RCC_R60CIDCFGR				0x210
> +#define RCC_R60SEMCR				0x214
> +#define RCC_R61CIDCFGR				0x218
> +#define RCC_R61SEMCR				0x21C
> +#define RCC_R62CIDCFGR				0x220
> +#define RCC_R62SEMCR				0x224
> +#define RCC_R63CIDCFGR				0x228
> +#define RCC_R63SEMCR				0x22C
> +#define RCC_R64CIDCFGR				0x230
> +#define RCC_R64SEMCR				0x234
> +#define RCC_R65CIDCFGR				0x238
> +#define RCC_R65SEMCR				0x23C
> +#define RCC_R66CIDCFGR				0x240
> +#define RCC_R66SEMCR				0x244
> +#define RCC_R67CIDCFGR				0x248
> +#define RCC_R67SEMCR				0x24C
> +#define RCC_R68CIDCFGR				0x250
> +#define RCC_R68SEMCR				0x254
> +#define RCC_R69CIDCFGR				0x258
> +#define RCC_R69SEMCR				0x25C
> +#define RCC_R70CIDCFGR				0x260
> +#define RCC_R70SEMCR				0x264
> +#define RCC_R71CIDCFGR				0x268
> +#define RCC_R71SEMCR				0x26C
> +#define RCC_R72CIDCFGR				0x270
> +#define RCC_R72SEMCR				0x274
> +#define RCC_R73CIDCFGR				0x278
> +#define RCC_R73SEMCR				0x27C
> +#define RCC_R74CIDCFGR				0x280
> +#define RCC_R74SEMCR				0x284
> +#define RCC_R75CIDCFGR				0x288
> +#define RCC_R75SEMCR				0x28C
> +#define RCC_R76CIDCFGR				0x290
> +#define RCC_R76SEMCR				0x294
> +#define RCC_R77CIDCFGR				0x298
> +#define RCC_R77SEMCR				0x29C
> +#define RCC_R78CIDCFGR				0x2A0
> +#define RCC_R78SEMCR				0x2A4
> +#define RCC_R79CIDCFGR				0x2A8
> +#define RCC_R79SEMCR				0x2AC
> +#define RCC_R80CIDCFGR				0x2B0
> +#define RCC_R80SEMCR				0x2B4
> +#define RCC_R81CIDCFGR				0x2B8
> +#define RCC_R81SEMCR				0x2BC
> +#define RCC_R82CIDCFGR				0x2C0
> +#define RCC_R82SEMCR				0x2C4
> +#define RCC_R83CIDCFGR				0x2C8
> +#define RCC_R83SEMCR				0x2CC
> +#define RCC_R84CIDCFGR				0x2D0
> +#define RCC_R84SEMCR				0x2D4
> +#define RCC_R85CIDCFGR				0x2D8
> +#define RCC_R85SEMCR				0x2DC
> +#define RCC_R86CIDCFGR				0x2E0
> +#define RCC_R86SEMCR				0x2E4
> +#define RCC_R87CIDCFGR				0x2E8
> +#define RCC_R87SEMCR				0x2EC
> +#define RCC_R88CIDCFGR				0x2F0
> +#define RCC_R88SEMCR				0x2F4
> +#define RCC_R89CIDCFGR				0x2F8
> +#define RCC_R89SEMCR				0x2FC
> +#define RCC_R90CIDCFGR				0x300
> +#define RCC_R90SEMCR				0x304
> +#define RCC_R91CIDCFGR				0x308
> +#define RCC_R91SEMCR				0x30C
> +#define RCC_R92CIDCFGR				0x310
> +#define RCC_R92SEMCR				0x314
> +#define RCC_R93CIDCFGR				0x318
> +#define RCC_R93SEMCR				0x31C
> +#define RCC_R94CIDCFGR				0x320
> +#define RCC_R94SEMCR				0x324
> +#define RCC_R95CIDCFGR				0x328
> +#define RCC_R95SEMCR				0x32C
> +#define RCC_R96CIDCFGR				0x330
> +#define RCC_R96SEMCR				0x334
> +#define RCC_R97CIDCFGR				0x338
> +#define RCC_R97SEMCR				0x33C
> +#define RCC_R98CIDCFGR				0x340
> +#define RCC_R98SEMCR				0x344
> +#define RCC_R99CIDCFGR				0x348
> +#define RCC_R99SEMCR				0x34C
> +#define RCC_R100CIDCFGR				0x350
> +#define RCC_R100SEMCR				0x354
> +#define RCC_R101CIDCFGR				0x358
> +#define RCC_R101SEMCR				0x35C
> +#define RCC_R102CIDCFGR				0x360
> +#define RCC_R102SEMCR				0x364
> +#define RCC_R103CIDCFGR				0x368
> +#define RCC_R103SEMCR				0x36C
> +#define RCC_R104CIDCFGR				0x370
> +#define RCC_R104SEMCR				0x374
> +#define RCC_R105CIDCFGR				0x378
> +#define RCC_R105SEMCR				0x37C
> +#define RCC_R106CIDCFGR				0x380
> +#define RCC_R106SEMCR				0x384
> +#define RCC_R107CIDCFGR				0x388
> +#define RCC_R107SEMCR				0x38C
> +#define RCC_R108CIDCFGR				0x390
> +#define RCC_R108SEMCR				0x394
> +#define RCC_R109CIDCFGR				0x398
> +#define RCC_R109SEMCR				0x39C
> +#define RCC_R110CIDCFGR				0x3A0
> +#define RCC_R110SEMCR				0x3A4
> +#define RCC_R111CIDCFGR				0x3A8
> +#define RCC_R111SEMCR				0x3AC
> +#define RCC_R112CIDCFGR				0x3B0
> +#define RCC_R112SEMCR				0x3B4
> +#define RCC_R113CIDCFGR				0x3B8
> +#define RCC_R113SEMCR				0x3BC
> +#define RCC_GRSTCSETR				0x400
> +#define RCC_C1RSTCSETR				0x404
> +#define RCC_C1P1RSTCSETR			0x408
> +#define RCC_C2RSTCSETR				0x40C
> +#define RCC_HWRSTSCLRR				0x410
> +#define RCC_C1HWRSTSCLRR			0x414
> +#define RCC_C2HWRSTSCLRR			0x418
> +#define RCC_C1BOOTRSTSSETR			0x41C
> +#define RCC_C1BOOTRSTSCLRR			0x420
> +#define RCC_C2BOOTRSTSSETR			0x424
> +#define RCC_C2BOOTRSTSCLRR			0x428
> +#define RCC_C1SREQSETR				0x42C
> +#define RCC_C1SREQCLRR				0x430
> +#define RCC_CPUBOOTCR				0x434
> +#define RCC_STBYBOOTCR				0x438
> +#define RCC_LEGBOOTCR				0x43C
> +#define RCC_BDCR				0x440
> +#define RCC_D3DCR				0x444
> +#define RCC_D3DSR				0x448
> +#define RCC_RDCR				0x44C
> +#define RCC_C1MSRDCR				0x450
> +#define RCC_PWRLPDLYCR				0x454
> +#define RCC_C1CIESETR				0x458
> +#define RCC_C1CIFCLRR				0x45C
> +#define RCC_C2CIESETR				0x460
> +#define RCC_C2CIFCLRR				0x464
> +#define RCC_IWDGC1FZSETR			0x468
> +#define RCC_IWDGC1FZCLRR			0x46C
> +#define RCC_IWDGC1CFGSETR			0x470
> +#define RCC_IWDGC1CFGCLRR			0x474
> +#define RCC_IWDGC2FZSETR			0x478
> +#define RCC_IWDGC2FZCLRR			0x47C
> +#define RCC_IWDGC2CFGSETR			0x480
> +#define RCC_IWDGC2CFGCLRR			0x484
> +#define RCC_IWDGC3CFGSETR			0x488
> +#define RCC_IWDGC3CFGCLRR			0x48C
> +#define RCC_C3CFGR				0x490
> +#define RCC_MCO1CFGR				0x494
> +#define RCC_MCO2CFGR				0x498
> +#define RCC_OCENSETR				0x49C
> +#define RCC_OCENCLRR				0x4A0
> +#define RCC_OCRDYR				0x4A4
> +#define RCC_HSICFGR				0x4A8
> +#define RCC_MSICFGR				0x4AC
> +#define RCC_RTCDIVR				0x4B0
> +#define RCC_APB1DIVR				0x4B4
> +#define RCC_APB2DIVR				0x4B8
> +#define RCC_APB3DIVR				0x4BC
> +#define RCC_APB4DIVR				0x4C0
> +#define RCC_APBDBGDIVR				0x4C4
> +#define RCC_TIMG1PRER				0x4C8
> +#define RCC_TIMG2PRER				0x4CC
> +#define RCC_LSMCUDIVR				0x4D0
> +#define RCC_DDRCPCFGR				0x4D4
> +#define RCC_DDRCAPBCFGR				0x4D8
> +#define RCC_DDRPHYCAPBCFGR			0x4DC
> +#define RCC_DDRPHYCCFGR				0x4E0
> +#define RCC_DDRCFGR				0x4E4
> +#define RCC_DDRITFCFGR				0x4E8
> +#define RCC_SYSRAMCFGR				0x4F0
> +#define RCC_VDERAMCFGR				0x4F4
> +#define RCC_SRAM1CFGR				0x4F8
> +#define RCC_SRAM2CFGR				0x4FC
> +#define RCC_RETRAMCFGR				0x500
> +#define RCC_BKPSRAMCFGR				0x504
> +#define RCC_LPSRAM1CFGR				0x508
> +#define RCC_LPSRAM2CFGR				0x50C
> +#define RCC_LPSRAM3CFGR				0x510
> +#define RCC_OSPI1CFGR				0x514
> +#define RCC_OSPI2CFGR				0x518
> +#define RCC_FMCCFGR				0x51C
> +#define RCC_DBGCFGR				0x520
> +#define RCC_STM500CFGR				0x524
> +#define RCC_ETRCFGR				0x528
> +#define RCC_GPIOACFGR				0x52C
> +#define RCC_GPIOBCFGR				0x530
> +#define RCC_GPIOCCFGR				0x534
> +#define RCC_GPIODCFGR				0x538
> +#define RCC_GPIOECFGR				0x53C
> +#define RCC_GPIOFCFGR				0x540
> +#define RCC_GPIOGCFGR				0x544
> +#define RCC_GPIOHCFGR				0x548
> +#define RCC_GPIOICFGR				0x54C
> +#define RCC_GPIOJCFGR				0x550
> +#define RCC_GPIOKCFGR				0x554
> +#define RCC_GPIOZCFGR				0x558
> +#define RCC_HPDMA1CFGR				0x55C
> +#define RCC_HPDMA2CFGR				0x560
> +#define RCC_HPDMA3CFGR				0x564
> +#define RCC_LPDMACFGR				0x568
> +#define RCC_HSEMCFGR				0x56C
> +#define RCC_IPCC1CFGR				0x570
> +#define RCC_IPCC2CFGR				0x574
> +#define RCC_RTCCFGR				0x578
> +#define RCC_SYSCPU1CFGR				0x580
> +#define RCC_BSECCFGR				0x584
> +#define RCC_IS2MCFGR				0x58C
> +#define RCC_PLL2CFGR1				0x590
> +#define RCC_PLL2CFGR2				0x594
> +#define RCC_PLL2CFGR3				0x598
> +#define RCC_PLL2CFGR4				0x59C
> +#define RCC_PLL2CFGR5				0x5A0
> +#define RCC_PLL2CFGR6				0x5A8
> +#define RCC_PLL2CFGR7				0x5AC
> +#define RCC_PLL3CFGR1				0x5B8
> +#define RCC_PLL3CFGR2				0x5BC
> +#define RCC_PLL3CFGR3				0x5C0
> +#define RCC_PLL3CFGR4				0x5C4
> +#define RCC_PLL3CFGR5				0x5C8
> +#define RCC_PLL3CFGR6				0x5D0
> +#define RCC_PLL3CFGR7				0x5D4
> +#define RCC_HSIFMONCR				0x5E0
> +#define RCC_HSIFVALR				0x5E4
> +#define RCC_TIM1CFGR				0x700
> +#define RCC_TIM2CFGR				0x704
> +#define RCC_TIM3CFGR				0x708
> +#define RCC_TIM4CFGR				0x70C
> +#define RCC_TIM5CFGR				0x710
> +#define RCC_TIM6CFGR				0x714
> +#define RCC_TIM7CFGR				0x718
> +#define RCC_TIM8CFGR				0x71C
> +#define RCC_TIM10CFGR				0x720
> +#define RCC_TIM11CFGR				0x724
> +#define RCC_TIM12CFGR				0x728
> +#define RCC_TIM13CFGR				0x72C
> +#define RCC_TIM14CFGR				0x730
> +#define RCC_TIM15CFGR				0x734
> +#define RCC_TIM16CFGR				0x738
> +#define RCC_TIM17CFGR				0x73C
> +#define RCC_TIM20CFGR				0x740
> +#define RCC_LPTIM1CFGR				0x744
> +#define RCC_LPTIM2CFGR				0x748
> +#define RCC_LPTIM3CFGR				0x74C
> +#define RCC_LPTIM4CFGR				0x750
> +#define RCC_LPTIM5CFGR				0x754
> +#define RCC_SPI1CFGR				0x758
> +#define RCC_SPI2CFGR				0x75C
> +#define RCC_SPI3CFGR				0x760
> +#define RCC_SPI4CFGR				0x764
> +#define RCC_SPI5CFGR				0x768
> +#define RCC_SPI6CFGR				0x76C
> +#define RCC_SPI7CFGR				0x770
> +#define RCC_SPI8CFGR				0x774
> +#define RCC_SPDIFRXCFGR				0x778
> +#define RCC_USART1CFGR				0x77C
> +#define RCC_USART2CFGR				0x780
> +#define RCC_USART3CFGR				0x784
> +#define RCC_UART4CFGR				0x788
> +#define RCC_UART5CFGR				0x78C
> +#define RCC_USART6CFGR				0x790
> +#define RCC_UART7CFGR				0x794
> +#define RCC_UART8CFGR				0x798
> +#define RCC_UART9CFGR				0x79C
> +#define RCC_LPUART1CFGR				0x7A0
> +#define RCC_I2C1CFGR				0x7A4
> +#define RCC_I2C2CFGR				0x7A8
> +#define RCC_I2C3CFGR				0x7AC
> +#define RCC_I2C4CFGR				0x7B0
> +#define RCC_I2C5CFGR				0x7B4
> +#define RCC_I2C6CFGR				0x7B8
> +#define RCC_I2C7CFGR				0x7BC
> +#define RCC_I2C8CFGR				0x7C0
> +#define RCC_SAI1CFGR				0x7C4
> +#define RCC_SAI2CFGR				0x7C8
> +#define RCC_SAI3CFGR				0x7CC
> +#define RCC_SAI4CFGR				0x7D0
> +#define RCC_MDF1CFGR				0x7D8
> +#define RCC_ADF1CFGR				0x7DC
> +#define RCC_FDCANCFGR				0x7E0
> +#define RCC_HDPCFGR				0x7E4
> +#define RCC_ADC12CFGR				0x7E8
> +#define RCC_ADC3CFGR				0x7EC
> +#define RCC_ETH1CFGR				0x7F0
> +#define RCC_ETH2CFGR				0x7F4
> +#define RCC_USB2CFGR				0x7FC
> +#define RCC_USB2PHY1CFGR			0x800
> +#define RCC_USB2PHY2CFGR			0x804
> +#define RCC_USB3DRCFGR				0x808
> +#define RCC_USB3PCIEPHYCFGR			0x80C
> +#define RCC_PCIECFGR				0x810
> +#define RCC_USBTCCFGR				0x814
> +#define RCC_ETHSWCFGR				0x818
> +#define RCC_ETHSWACMCFGR			0x81C
> +#define RCC_ETHSWACMMSGCFGR			0x820
> +#define RCC_STGENCFGR				0x824
> +#define RCC_SDMMC1CFGR				0x830
> +#define RCC_SDMMC2CFGR				0x834
> +#define RCC_SDMMC3CFGR				0x838
> +#define RCC_GPUCFGR				0x83C
> +#define RCC_LTDCCFGR				0x840
> +#define RCC_DSICFGR				0x844
> +#define RCC_LVDSCFGR				0x850
> +#define RCC_CSICFGR				0x858
> +#define RCC_DCMIPPCFGR				0x85C
> +#define RCC_CCICFGR				0x860
> +#define RCC_VDECCFGR				0x864
> +#define RCC_VENCCFGR				0x868
> +#define RCC_RNGCFGR				0x870
> +#define RCC_PKACFGR				0x874
> +#define RCC_SAESCFGR				0x878
> +#define RCC_HASHCFGR				0x87C
> +#define RCC_CRYP1CFGR				0x880
> +#define RCC_CRYP2CFGR				0x884
> +#define RCC_IWDG1CFGR				0x888
> +#define RCC_IWDG2CFGR				0x88C
> +#define RCC_IWDG3CFGR				0x890
> +#define RCC_IWDG4CFGR				0x894
> +#define RCC_IWDG5CFGR				0x898
> +#define RCC_WWDG1CFGR				0x89C
> +#define RCC_WWDG2CFGR				0x8A0
> +#define RCC_VREFCFGR				0x8A8
> +#define RCC_DTSCFGR				0x8AC
> +#define RCC_CRCCFGR				0x8B4
> +#define RCC_SERCCFGR				0x8B8
> +#define RCC_OSPIIOMCFGR				0x8BC
> +#define RCC_GICV2MCFGR				0x8C0
> +#define RCC_I3C1CFGR				0x8C8
> +#define RCC_I3C2CFGR				0x8CC
> +#define RCC_I3C3CFGR				0x8D0
> +#define RCC_I3C4CFGR				0x8D4
> +#define RCC_MUXSELCFGR				0x1000
> +#define RCC_XBAR0CFGR				0x1018
> +#define RCC_XBAR1CFGR				0x101C
> +#define RCC_XBAR2CFGR				0x1020
> +#define RCC_XBAR3CFGR				0x1024
> +#define RCC_XBAR4CFGR				0x1028
> +#define RCC_XBAR5CFGR				0x102C
> +#define RCC_XBAR6CFGR				0x1030
> +#define RCC_XBAR7CFGR				0x1034
> +#define RCC_XBAR8CFGR				0x1038
> +#define RCC_XBAR9CFGR				0x103C
> +#define RCC_XBAR10CFGR				0x1040
> +#define RCC_XBAR11CFGR				0x1044
> +#define RCC_XBAR12CFGR				0x1048
> +#define RCC_XBAR13CFGR				0x104C
> +#define RCC_XBAR14CFGR				0x1050
> +#define RCC_XBAR15CFGR				0x1054
> +#define RCC_XBAR16CFGR				0x1058
> +#define RCC_XBAR17CFGR				0x105C
> +#define RCC_XBAR18CFGR				0x1060
> +#define RCC_XBAR19CFGR				0x1064
> +#define RCC_XBAR20CFGR				0x1068
> +#define RCC_XBAR21CFGR				0x106C
> +#define RCC_XBAR22CFGR				0x1070
> +#define RCC_XBAR23CFGR				0x1074
> +#define RCC_XBAR24CFGR				0x1078
> +#define RCC_XBAR25CFGR				0x107C
> +#define RCC_XBAR26CFGR				0x1080
> +#define RCC_XBAR27CFGR				0x1084
> +#define RCC_XBAR28CFGR				0x1088
> +#define RCC_XBAR29CFGR				0x108C
> +#define RCC_XBAR30CFGR				0x1090
> +#define RCC_XBAR31CFGR				0x1094
> +#define RCC_XBAR32CFGR				0x1098
> +#define RCC_XBAR33CFGR				0x109C
> +#define RCC_XBAR34CFGR				0x10A0
> +#define RCC_XBAR35CFGR				0x10A4
> +#define RCC_XBAR36CFGR				0x10A8
> +#define RCC_XBAR37CFGR				0x10AC
> +#define RCC_XBAR38CFGR				0x10B0
> +#define RCC_XBAR39CFGR				0x10B4
> +#define RCC_XBAR40CFGR				0x10B8
> +#define RCC_XBAR41CFGR				0x10BC
> +#define RCC_XBAR42CFGR				0x10C0
> +#define RCC_XBAR43CFGR				0x10C4
> +#define RCC_XBAR44CFGR				0x10C8
> +#define RCC_XBAR45CFGR				0x10CC
> +#define RCC_XBAR46CFGR				0x10D0
> +#define RCC_XBAR47CFGR				0x10D4
> +#define RCC_XBAR48CFGR				0x10D8
> +#define RCC_XBAR49CFGR				0x10DC
> +#define RCC_XBAR50CFGR				0x10E0
> +#define RCC_XBAR51CFGR				0x10E4
> +#define RCC_XBAR52CFGR				0x10E8
> +#define RCC_XBAR53CFGR				0x10EC
> +#define RCC_XBAR54CFGR				0x10F0
> +#define RCC_XBAR55CFGR				0x10F4
> +#define RCC_XBAR56CFGR				0x10F8
> +#define RCC_XBAR57CFGR				0x10FC
> +#define RCC_XBAR58CFGR				0x1100
> +#define RCC_XBAR59CFGR				0x1104
> +#define RCC_XBAR60CFGR				0x1108
> +#define RCC_XBAR61CFGR				0x110C
> +#define RCC_XBAR62CFGR				0x1110
> +#define RCC_XBAR63CFGR				0x1114
> +#define RCC_PREDIV0CFGR				0x1118
> +#define RCC_PREDIV1CFGR				0x111C
> +#define RCC_PREDIV2CFGR				0x1120
> +#define RCC_PREDIV3CFGR				0x1124
> +#define RCC_PREDIV4CFGR				0x1128
> +#define RCC_PREDIV5CFGR				0x112C
> +#define RCC_PREDIV6CFGR				0x1130
> +#define RCC_PREDIV7CFGR				0x1134
> +#define RCC_PREDIV8CFGR				0x1138
> +#define RCC_PREDIV9CFGR				0x113C
> +#define RCC_PREDIV10CFGR			0x1140
> +#define RCC_PREDIV11CFGR			0x1144
> +#define RCC_PREDIV12CFGR			0x1148
> +#define RCC_PREDIV13CFGR			0x114C
> +#define RCC_PREDIV14CFGR			0x1150
> +#define RCC_PREDIV15CFGR			0x1154
> +#define RCC_PREDIV16CFGR			0x1158
> +#define RCC_PREDIV17CFGR			0x115C
> +#define RCC_PREDIV18CFGR			0x1160
> +#define RCC_PREDIV19CFGR			0x1164
> +#define RCC_PREDIV20CFGR			0x1168
> +#define RCC_PREDIV21CFGR			0x116C
> +#define RCC_PREDIV22CFGR			0x1170
> +#define RCC_PREDIV23CFGR			0x1174
> +#define RCC_PREDIV24CFGR			0x1178
> +#define RCC_PREDIV25CFGR			0x117C
> +#define RCC_PREDIV26CFGR			0x1180
> +#define RCC_PREDIV27CFGR			0x1184
> +#define RCC_PREDIV28CFGR			0x1188
> +#define RCC_PREDIV29CFGR			0x118C
> +#define RCC_PREDIV30CFGR			0x1190
> +#define RCC_PREDIV31CFGR			0x1194
> +#define RCC_PREDIV32CFGR			0x1198
> +#define RCC_PREDIV33CFGR			0x119C
> +#define RCC_PREDIV34CFGR			0x11A0
> +#define RCC_PREDIV35CFGR			0x11A4
> +#define RCC_PREDIV36CFGR			0x11A8
> +#define RCC_PREDIV37CFGR			0x11AC
> +#define RCC_PREDIV38CFGR			0x11B0
> +#define RCC_PREDIV39CFGR			0x11B4
> +#define RCC_PREDIV40CFGR			0x11B8
> +#define RCC_PREDIV41CFGR			0x11BC
> +#define RCC_PREDIV42CFGR			0x11C0
> +#define RCC_PREDIV43CFGR			0x11C4
> +#define RCC_PREDIV44CFGR			0x11C8
> +#define RCC_PREDIV45CFGR			0x11CC
> +#define RCC_PREDIV46CFGR			0x11D0
> +#define RCC_PREDIV47CFGR			0x11D4
> +#define RCC_PREDIV48CFGR			0x11D8
> +#define RCC_PREDIV49CFGR			0x11DC
> +#define RCC_PREDIV50CFGR			0x11E0
> +#define RCC_PREDIV51CFGR			0x11E4
> +#define RCC_PREDIV52CFGR			0x11E8
> +#define RCC_PREDIV53CFGR			0x11EC
> +#define RCC_PREDIV54CFGR			0x11F0
> +#define RCC_PREDIV55CFGR			0x11F4
> +#define RCC_PREDIV56CFGR			0x11F8
> +#define RCC_PREDIV57CFGR			0x11FC
> +#define RCC_PREDIV58CFGR			0x1200
> +#define RCC_PREDIV59CFGR			0x1204
> +#define RCC_PREDIV60CFGR			0x1208
> +#define RCC_PREDIV61CFGR			0x120C
> +#define RCC_PREDIV62CFGR			0x1210
> +#define RCC_PREDIV63CFGR			0x1214
> +#define RCC_PREDIVSR1				0x1218
> +#define RCC_PREDIVSR2				0x121C
> +#define RCC_FINDIV0CFGR				0x1224
> +#define RCC_FINDIV1CFGR				0x1228
> +#define RCC_FINDIV2CFGR				0x122C
> +#define RCC_FINDIV3CFGR				0x1230
> +#define RCC_FINDIV4CFGR				0x1234
> +#define RCC_FINDIV5CFGR				0x1238
> +#define RCC_FINDIV6CFGR				0x123C
> +#define RCC_FINDIV7CFGR				0x1240
> +#define RCC_FINDIV8CFGR				0x1244
> +#define RCC_FINDIV9CFGR				0x1248
> +#define RCC_FINDIV10CFGR			0x124C
> +#define RCC_FINDIV11CFGR			0x1250
> +#define RCC_FINDIV12CFGR			0x1254
> +#define RCC_FINDIV13CFGR			0x1258
> +#define RCC_FINDIV14CFGR			0x125C
> +#define RCC_FINDIV15CFGR			0x1260
> +#define RCC_FINDIV16CFGR			0x1264
> +#define RCC_FINDIV17CFGR			0x1268
> +#define RCC_FINDIV18CFGR			0x126C
> +#define RCC_FINDIV19CFGR			0x1270
> +#define RCC_FINDIV20CFGR			0x1274
> +#define RCC_FINDIV21CFGR			0x1278
> +#define RCC_FINDIV22CFGR			0x127C
> +#define RCC_FINDIV23CFGR			0x1280
> +#define RCC_FINDIV24CFGR			0x1284
> +#define RCC_FINDIV25CFGR			0x1288
> +#define RCC_FINDIV26CFGR			0x128C
> +#define RCC_FINDIV27CFGR			0x1290
> +#define RCC_FINDIV28CFGR			0x1294
> +#define RCC_FINDIV29CFGR			0x1298
> +#define RCC_FINDIV30CFGR			0x129C
> +#define RCC_FINDIV31CFGR			0x12A0
> +#define RCC_FINDIV32CFGR			0x12A4
> +#define RCC_FINDIV33CFGR			0x12A8
> +#define RCC_FINDIV34CFGR			0x12AC
> +#define RCC_FINDIV35CFGR			0x12B0
> +#define RCC_FINDIV36CFGR			0x12B4
> +#define RCC_FINDIV37CFGR			0x12B8
> +#define RCC_FINDIV38CFGR			0x12BC
> +#define RCC_FINDIV39CFGR			0x12C0
> +#define RCC_FINDIV40CFGR			0x12C4
> +#define RCC_FINDIV41CFGR			0x12C8
> +#define RCC_FINDIV42CFGR			0x12CC
> +#define RCC_FINDIV43CFGR			0x12D0
> +#define RCC_FINDIV44CFGR			0x12D4
> +#define RCC_FINDIV45CFGR			0x12D8
> +#define RCC_FINDIV46CFGR			0x12DC
> +#define RCC_FINDIV47CFGR			0x12E0
> +#define RCC_FINDIV48CFGR			0x12E4
> +#define RCC_FINDIV49CFGR			0x12E8
> +#define RCC_FINDIV50CFGR			0x12EC
> +#define RCC_FINDIV51CFGR			0x12F0
> +#define RCC_FINDIV52CFGR			0x12F4
> +#define RCC_FINDIV53CFGR			0x12F8
> +#define RCC_FINDIV54CFGR			0x12FC
> +#define RCC_FINDIV55CFGR			0x1300
> +#define RCC_FINDIV56CFGR			0x1304
> +#define RCC_FINDIV57CFGR			0x1308
> +#define RCC_FINDIV58CFGR			0x130C
> +#define RCC_FINDIV59CFGR			0x1310
> +#define RCC_FINDIV60CFGR			0x1314
> +#define RCC_FINDIV61CFGR			0x1318
> +#define RCC_FINDIV62CFGR			0x131C
> +#define RCC_FINDIV63CFGR			0x1320
> +#define RCC_FINDIVSR1				0x1324
> +#define RCC_FINDIVSR2				0x1328
> +#define RCC_FCALCOBS0CFGR			0x1340
> +#define RCC_FCALCOBS1CFGR			0x1344
> +#define RCC_FCALCREFCFGR			0x1348
> +#define RCC_FCALCCR1				0x134C
> +#define RCC_FCALCCR2				0x1354
> +#define RCC_FCALCSR				0x1358
> +#define RCC_PLL4CFGR1				0x1360
> +#define RCC_PLL4CFGR2				0x1364
> +#define RCC_PLL4CFGR3				0x1368
> +#define RCC_PLL4CFGR4				0x136C
> +#define RCC_PLL4CFGR5				0x1370
> +#define RCC_PLL4CFGR6				0x1378
> +#define RCC_PLL4CFGR7				0x137C
> +#define RCC_PLL5CFGR1				0x1388
> +#define RCC_PLL5CFGR2				0x138C
> +#define RCC_PLL5CFGR3				0x1390
> +#define RCC_PLL5CFGR4				0x1394
> +#define RCC_PLL5CFGR5				0x1398
> +#define RCC_PLL5CFGR6				0x13A0
> +#define RCC_PLL5CFGR7				0x13A4
> +#define RCC_PLL6CFGR1				0x13B0
> +#define RCC_PLL6CFGR2				0x13B4
> +#define RCC_PLL6CFGR3				0x13B8
> +#define RCC_PLL6CFGR4				0x13BC
> +#define RCC_PLL6CFGR5				0x13C0
> +#define RCC_PLL6CFGR6				0x13C8
> +#define RCC_PLL6CFGR7				0x13CC
> +#define RCC_PLL7CFGR1				0x13D8
> +#define RCC_PLL7CFGR2				0x13DC
> +#define RCC_PLL7CFGR3				0x13E0
> +#define RCC_PLL7CFGR4				0x13E4
> +#define RCC_PLL7CFGR5				0x13E8
> +#define RCC_PLL7CFGR6				0x13F0
> +#define RCC_PLL7CFGR7				0x13F4
> +#define RCC_PLL8CFGR1				0x1400
> +#define RCC_PLL8CFGR2				0x1404
> +#define RCC_PLL8CFGR3				0x1408
> +#define RCC_PLL8CFGR4				0x140C
> +#define RCC_PLL8CFGR5				0x1410
> +#define RCC_PLL8CFGR6				0x1418
> +#define RCC_PLL8CFGR7				0x141C
> +#define RCC_VERR				0xFFF4
> +#define RCC_IDR					0xFFF8
> +#define RCC_SIDR				0xFFFC
> +
> +#endif /* STM32MP25_RCC_H */


From baolin.wang at linux.alibaba.com  Wed Dec 20 01:43:18 2023
From: baolin.wang at linux.alibaba.com (Baolin Wang)
Date: Wed, 20 Dec 2023 17:43:18 +0800
Subject: [PATCH] mm: page_alloc: remove duplication of free_one_page()
In-Reply-To: <20231220074757.3656-1-Kuan-Ying.Lee@mediatek.com>
References: <20231220074757.3656-1-Kuan-Ying.Lee@mediatek.com>
Message-ID: <7ec7bbfd-41db-4a62-b58a-315ad244c0aa@linux.alibaba.com>

Hi,

On 12/20/2023 3:47 PM, Kuan-Ying Lee wrote:
> Remove duplication of free_one_page().
> 
> Cc: Casper Li <casper.li at mediatek.com>
> Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee at mediatek.com>

Just FYI:
There is already a same patch submitted, see: 
https://lore.kernel.org/all/20231216030503.2126130-1-yajun.deng at linux.dev/T/#u

> ---
>   mm/page_alloc.c | 9 +--------
>   1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 2f646773a934..f46af8616cac 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1262,7 +1262,6 @@ static void free_one_page(struct zone *zone,
>   static void __free_pages_ok(struct page *page, unsigned int order,
>   			    fpi_t fpi_flags)
>   {
> -	unsigned long flags;
>   	int migratetype;
>   	unsigned long pfn = page_to_pfn(page);
>   	struct zone *zone = page_zone(page);
> @@ -1277,13 +1276,7 @@ static void __free_pages_ok(struct page *page, unsigned int order,
>   	 */
>   	migratetype = get_pfnblock_migratetype(page, pfn);
>   
> -	spin_lock_irqsave(&zone->lock, flags);
> -	if (unlikely(has_isolate_pageblock(zone) ||
> -		is_migrate_isolate(migratetype))) {
> -		migratetype = get_pfnblock_migratetype(page, pfn);
> -	}
> -	__free_one_page(page, pfn, zone, order, migratetype, fpi_flags);
> -	spin_unlock_irqrestore(&zone->lock, flags);
> +	free_one_page(zone, page, pfn, order, migratetype, fpi_flags);
>   
>   	__count_vm_events(PGFREE, 1 << order);
>   }


From ryan.roberts at arm.com  Wed Dec 20 01:51:01 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 09:51:01 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
Message-ID: <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>

On 20/12/2023 09:17, David Hildenbrand wrote:
> On 19.12.23 18:42, Ryan Roberts wrote:
>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>> batch is determined by the architecture with the new helper,
>>>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>
>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>> range in the first place.
>>>>>>
>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>> effort has been put into not regressing performance for the order-0
>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>> for batching and produce code that is equivalent (and equally
>>>>>> performant) as the previous implementation.
>>>>>>
>>>>>> This change addresses the core-mm refactoring only and a separate change
>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>
>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>
>>>>>> The following microbenchmark results demonstate that there is no
>>>>>> significant performance change after this patch. Fork is called in a
>>>>>> tight loop in a process with 1G of populated memory and the time for the
>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>> positive is slower, compared to baseline upon which the series is based:
>>>>>>
>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>> | fork????????? |-------------------|-------------------|
>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>> |---------------|---------|---------|---------|---------|
>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>
>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>> | fork????????? |-------------------|-------------------|
>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>> |---------------|---------|---------|---------|---------|
>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>
>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>> ---
>>>>>> ??? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>> ??? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>>>> ??? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>
>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>> --- a/include/linux/pgtable.h
>>>>>> +++ b/include/linux/pgtable.h
>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>> ??? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>> ??? #endif
>>>>>> ??? +#ifndef pte_batch_remaining
>>>>>> +/**
>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>>>>> + * @pte: Page table entry for the first page.
>>>>>> + * @addr: Address of the first page.
>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>> + *
>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of
>>>>>> ptes.
>>>>>> + * In such cases, this function returns the remaining number of pages to
>>>>>> the end
>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>> iterating
>>>>>> + * over ptes.
>>>>>> + *
>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>> + */
>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long
>>>>>> addr,
>>>>>> +??????????????????????? unsigned long end)
>>>>>> +{
>>>>>> +??? return 1;
>>>>>> +}
>>>>>> +#endif
>>>>>
>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>
>>>>> Was there no way to have some basic batching mechanism that doesn't require
>>>>> arch
>>>>> specifics?
>>>>
>>>> I tried a bunch of things but ultimately the way I've done it was the only way
>>>> to reduce the order-0 fork regression to 0.
>>>>
>>>> My original v3 posting was costing 5% extra and even my first attempt at an
>>>> arch-specific version that didn't resolve to a compile-time constant 1 still
>>>> cost an extra 3%.
>>>>
>>>>
>>>>>
>>>>> I'd have thought that something very basic would have worked like:
>>>>>
>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>> * Check that PFN is consecutive
>>>>> * Check that all PFNs belong to the same folio
>>>>
>>>> I haven't tried this exact approach, but I'd be surprised if I can get the
>>>> regression under 4% with this. Further along the series I spent a lot of time
>>>> having to fiddle with the arm64 implementation; every conditional and every
>>>> memory read (even when in cache) was a problem. There is just so little in the
>>>> inner loop that every instruction matters. (At least on Ampere Altra and Apple
>>>> M2).
>>>>
>>>> Of course if you're willing to pay that 4-5% for order-0 then the benefit to
>>>> order-9 is around 10% in my measurements. Personally though, I'd prefer to play
>>>> safe and ensure the common order-0 case doesn't regress, as you previously
>>>> suggested.
>>>>
>>>
>>> I just hacked something up, on top of my beloved rmap cleanup/batching series. I
>>> implemented very generic and simple batching for large folios (all PTE bits
>>> except the PFN have to match).
>>>
>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R) Silver
>>> 4210R CPU.
>>>
>>> order-0: 0.014210 -> 0.013969
>>>
>>> -> Around 1.7 % faster
>>>
>>> order-9: 0.014373 -> 0.009149
>>>
>>> -> Around 36.3 % faster
>>
>> Well I guess that shows me :)
>>
>> I'll do a review and run the tests on my HW to see if it concurs.
> 
> 
> I pushed a simple compile fixup (we need pte_next_pfn()).

I've just been trying to compile and noticed this. Will take a look at your update.

But upon review, I've noticed the part that I think makes this difficult for
arm64 with the contpte optimization; You are calling ptep_get() for every pte in
the batch. While this is functionally correct, once arm64 has the contpte
changes, its ptep_get() has to read every pte in the contpte block in order to
gather the access and dirty bits. So if your batching function ends up wealking
a 16 entry contpte block, that will cause 16 x 16 reads, which kills
performance. That's why I added the arch-specific pte_batch_remaining()
function; this allows the core-mm to skip to the end of the contpte block and
avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s instead
of 256.

I considered making a ptep_get_noyoungdirty() variant, which would avoid the bit
gathering. But we have a similar problem in zap_pte_range() and that function
needs the dirty bit to update the folio. So it doesn't work there. (see patch 3
in my series).

I guess you are going to say that we should combine both approaches, so that
your batching loop can skip forward an arch-provided number of ptes? That would
certainly work, but feels like an orthogonal change to what I'm trying to
achieve :). Anyway, I'll spend some time playing with it today.


> 
> Note that we should probably handle "ptep_set_wrprotects" rather like set_ptes:
> 
> #ifndef wrprotect_ptes
> static inline void wrprotect_ptes(struct mm_struct *mm, unsigned long addr,
> ?????????????? pte_t *ptep, unsigned int nr)
> {
> ?????? for (;;) {
> ?????????????? ptep_set_wrprotect(mm, addr, ptep);
> ?????????????? if (--nr == 0)
> ?????????????????????? break;
> ?????????????? ptep++;
> ?????????????? addr += PAGE_SIZE;
> ?????? }
> }
> #endif
> 
> 



From quic_taozha at quicinc.com  Wed Dec 20 01:51:03 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Wed, 20 Dec 2023 17:51:03 +0800
Subject: [PATCH v3 6/8] coresight-tpdm: Add timestamp control register
 support for the CMB
In-Reply-To: <cdad425c-b965-44c7-a612-1c99341e95b9@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-7-git-send-email-quic_taozha@quicinc.com>
 <ebd7e310-d1b4-4b2e-a915-6241e04763d4@arm.com>
 <b61c3d70-7277-4fe7-ab67-8afc1062c737@quicinc.com>
 <cdad425c-b965-44c7-a612-1c99341e95b9@arm.com>
Message-ID: <b7ef4e75-69c6-4251-8f9c-58682699e3f6@quicinc.com>


On 12/19/2023 9:51 PM, Suzuki K Poulose wrote:
> On 19/12/2023 02:43, Tao Zhang wrote:
>>
>> On 12/18/2023 6:46 PM, Suzuki K Poulose wrote:
>>> On 21/11/2023 02:24, Tao Zhang wrote:
>>>> CMB_TIER register is CMB subunit timestamp insertion enable register.
>>>> Bit 0 is PATT_TSENAB bit. Set this bit to 1 to request a timestamp
>>>> following a CMB interface pattern match. Bit 1 is XTRIG_TSENAB bit.
>>>> Set this bit to 1 to request a timestamp following a CMB CTI timestamp
>>>> request. Bit 2 is TS_ALL bit. Set this bit to 1 to request timestamp
>>>> for all packets.
>>>>
>>>> Reviewed-by: James Clark <james.clark at arm.com>
>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
>>>> ---
>>>> ? .../testing/sysfs-bus-coresight-devices-tpdm? |? 35 ++++++
>>>> ? drivers/hwtracing/coresight/coresight-tpdm.c? | 116 
>>>> +++++++++++++++++-
>>>> ? drivers/hwtracing/coresight/coresight-tpdm.h? |? 14 +++
>>>> ? 3 files changed, 162 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git 
>>>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm 
>>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>> index 53662ce7c2d0..e0b77107be13 100644
>>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>> @@ -214,3 +214,38 @@ KernelVersion??? 6.7
>>>> ? Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>> ? Description:
>>>> ????????? (RW) Set/Get the mask of the pattern for the CMB subunit 
>>>> TPDM.
>>>> +
>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
>>>> +Date:??????? September 2023
>>>> +KernelVersion??? 6.7
>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>> +Description:
>>>> +??????? (Write) Set the pattern timestamp of CMB tpdm. Read
>>>> +??????? the pattern timestamp of CMB tpdm.
>>>> +
>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>> +??????? 0 : Disable CMB pattern timestamp.
>>>> +??????? 1 : Enable CMB pattern timestamp.
>>>> +
>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
>>>> +Date:??????? September 2023
>>>> +KernelVersion??? 6.7
>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>> +Description:
>>>> +??????? (RW) Set/Get the trigger timestamp of the CMB for tpdm.
>>>> +
>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>> +??????? 0 : Set the CMB trigger type to false
>>>> +??????? 1 : Set the CMB trigger type to true
>>>> +
>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
>>>> +Date:??????? September 2023
>>>> +KernelVersion??? 6.7
>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>> +Description:
>>>> +??????? (RW) Read or write the status of timestamp upon all 
>>>> interface.
>>>> +??????? Only value 0 and 1? can be written to this node. Set this 
>>>> node to 1 to requeset
>>>> +??????? timestamp to all trace packet.
>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>> +??????? 0 : Disable the timestamp of all trace packets.
>>>> +??????? 1 : Enable the timestamp of all trace packets.
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>>>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> index 894d4309f1c7..f6cda5616e84 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> @@ -331,6 +331,36 @@ static void tpdm_enable_dsb(struct 
>>>> tpdm_drvdata *drvdata)
>>>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>>>> ? }
>>>> ? +static void set_cmb_tier(struct tpdm_drvdata *drvdata)
>>>> +{
>>>> +??? u32 val;
>>>> +
>>>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_TIER);
>>>> +
>>>> +??? /* Clear all relevant fields */
>>>> +??? val &= ~(TPDM_CMB_TIER_PATT_TSENAB | TPDM_CMB_TIER_TS_ALL |
>>>> +???????? TPDM_CMB_TIER_XTRIG_TSENAB);
>>>> +
>>>> +??? /* Set pattern timestamp type and enablement */
>>>> +??? if (drvdata->cmb->patt_ts)
>>>> +??????? val |= TPDM_CMB_TIER_PATT_TSENAB;
>>>
>>> ?-- cut --
>>>> +??? else
>>>> +??????? val &= ~TPDM_CMB_TIER_PATT_TSENAB;
>>>
>>>
>>> All the else cases in this function are superfluous. Please remove all
>>> of them.
>> I will update this in the next patch.
>>>
>>>> +
>>>> +??? /* Set trigger timestamp */
>>>> +??? if (drvdata->cmb->trig_ts)
>>>> +??????? val |= TPDM_CMB_TIER_XTRIG_TSENAB;
>>>> +??? else
>>>> +??????? val &= ~TPDM_CMB_TIER_XTRIG_TSENAB;
>>>> +
>>>> +??? /* Set all timestamp enablement*/
>>>> +??? if (drvdata->cmb->ts_all)
>>>> +??????? val |= TPDM_CMB_TIER_TS_ALL;
>>>> +??? else
>>>> +??????? val &= ~TPDM_CMB_TIER_TS_ALL;
>>>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>>>> +}
>>>> +
>>>> ? static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>>>> ? {
>>>> ????? u32 val, i;
>>>> @@ -347,6 +377,8 @@ static void tpdm_enable_cmb(struct tpdm_drvdata 
>>>> *drvdata)
>>>> ????????????????? drvdata->base + TPDM_CMB_XPMR(i));
>>>> ????? }
>>>> ? +??? set_cmb_tier(drvdata);
>>>> +
>>>> ????? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>>> ????? /*
>>>> ?????? * Set to 0 for continuous CMB collection mode,
>>>> @@ -695,9 +727,17 @@ static ssize_t enable_ts_show(struct device *dev,
>>>> ??????????????????? char *buf)
>>>> ? {
>>>> ????? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>> +??? ssize_t size = 0;
>>>> ? -??? return sysfs_emit(buf, "%u\n",
>>>> -???????????? (unsigned int)drvdata->dsb->patt_ts);
>>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>>> +??????? size = sysfs_emit(buf, "%u\n",
>>>> +???????????????? (unsigned int)drvdata->dsb->patt_ts);
>>>> +
>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>> +??????? size = sysfs_emit(buf, "%u\n",
>>>> +???????????????? (unsigned int)drvdata->cmb->patt_ts);
>>>
>>> Why does this need to show two values ? This must only show ONE value.
>>> How you deduce that might be based on the availability of the feature
>>> set. Or store the TS value in the drvdata and use that instead for
>>> controlling CMB/DSB.
>>
>> Since both of CMB/DSB need to have "enable_ts" SysFs file, can I 
>> separate them
>
> The question really is, do we need fine grained control. i.e.,
>
> enable TS for DSB but not for CMB or vice versa.
>
> I am not an expert on the usage scenario of the same. So, if you/Qcomm
> thinks the users need separate, fine grained control for timestamp
> for the DSB and CMB, then yes, follow your recommendation below.
> i.e., tpdm.../dsb_patt/enable_ts
>
>> as "enable_dsb_ts" and "enable_cmb_ts"? The path will be like below.
>>
>> tpdm0/dsb_patt/enable_dsb_ts
>
> You don't need enable_dsb_ts. It could be "enable_ts"
>
>>
>> tpdm1/cmb_patt/enable_cmb_ts
>>
>> Is this design appropriate?
>
>
> Otherwise, stick to single enable_ts : which enables the ts for both
> CMB/DSB. And it only ever show one value : 0 (TS is disabled for both
> CMB/DSB) 1 : TS enabled for both.

We have a very special case, such as the TPDM supporting both CMB and

DSB datasets. Although this case is very rare, it still exists.

Can I use the data bit to instruct whether timestamp is enabled for 
CMB/DSB or not? For example,

size = sysfs_emit(buf, "%u\n",
 ??? ??? ??? ??? (unsigned int)(drvdata->dsb->patt_ts << 1 | 
drvdata->cmb->patt_ts));

Thus, this value can instruct the following situations.

0 - TS is disabled for both CMB/DSB

1 - TS is enabled for CMB

2 - TS is enabled for DSB

3 - TS is enabled for both

Is this approach acceptable?


Best,

Tao

>
> Suzuki
>
>
>>>
>
>>> Also, the sysfs documentation needs update, if this is going to
>>> control the CMB.
>>
>> Sure. I will update the SysFs documentation according to the 
>> modification in the
>>
>> next patch series.
>>
>>
>> Best,
>>
>> Tao
>>
>>>
>>> Suzuki
>>>
>>>
>>>> +
>>>> +??? return size;
>>>> ? }
>>>> ? ? /*
>>>> @@ -715,8 +755,13 @@ static ssize_t enable_ts_store(struct device 
>>>> *dev,
>>>> ????????? return -EINVAL;
>>>> ? ????? spin_lock(&drvdata->spinlock);
>>>> -??? drvdata->dsb->patt_ts = !!val;
>>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>>> +??????? drvdata->dsb->patt_ts = !!val;
>>>> +
>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>> +??????? drvdata->cmb->patt_ts = !!val;
>>>> ????? spin_unlock(&drvdata->spinlock);
>>>> +
>>>> ????? return size;
>>>> ? }
>>>> ? static DEVICE_ATTR_RW(enable_ts);
>>>> @@ -851,6 +896,68 @@ static ssize_t cmb_mode_store(struct device *dev,
>>>> ? }
>>>> ? static DEVICE_ATTR_RW(cmb_mode);
>>>> ? +static ssize_t cmb_ts_all_show(struct device *dev,
>>>> +?????????????????? struct device_attribute *attr,
>>>> +?????????????????? char *buf)
>>>> +{
>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>> +
>>>> +??? return sysfs_emit(buf, "%u\n",
>>>> +????????????? (unsigned int)drvdata->cmb->ts_all);
>>>> +}
>>>> +
>>>> +static ssize_t cmb_ts_all_store(struct device *dev,
>>>> +??????????????? struct device_attribute *attr,
>>>> +??????????????? const char *buf,
>>>> +??????????????? size_t size)
>>>> +{
>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>> +??? unsigned long val;
>>>> +
>>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>>> +??????? return -EINVAL;
>>>> +
>>>> +??? spin_lock(&drvdata->spinlock);
>>>> +??? if (val)
>>>> +??????? drvdata->cmb->ts_all = true;
>>>> +??? else
>>>> +??????? drvdata->cmb->ts_all = false;
>>>> +??? spin_unlock(&drvdata->spinlock);
>>>> +??? return size;
>>>> +}
>>>> +static DEVICE_ATTR_RW(cmb_ts_all);
>>>> +
>>>> +static ssize_t cmb_trig_ts_show(struct device *dev,
>>>> +??????????????? struct device_attribute *attr,
>>>> +??????????????? char *buf)
>>>> +{
>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>> +
>>>> +??? return sysfs_emit(buf, "%u\n",
>>>> +????????????? (unsigned int)drvdata->cmb->trig_ts);
>>>> +}
>>>> +
>>>> +static ssize_t cmb_trig_ts_store(struct device *dev,
>>>> +???????????????? struct device_attribute *attr,
>>>> +???????????????? const char *buf,
>>>> +???????????????? size_t size)
>>>> +{
>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>> +??? unsigned long val;
>>>> +
>>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>>> +??????? return -EINVAL;
>>>> +
>>>> +??? spin_lock(&drvdata->spinlock);
>>>> +??? if (val)
>>>> +??????? drvdata->cmb->trig_ts = true;
>>>> +??? else
>>>> +??????? drvdata->cmb->trig_ts = false;
>>>> +??? spin_unlock(&drvdata->spinlock);
>>>> +??? return size;
>>>> +}
>>>> +static DEVICE_ATTR_RW(cmb_trig_ts);
>>>> +
>>>> ? static struct attribute *tpdm_dsb_edge_attrs[] = {
>>>> ????? &dev_attr_ctrl_idx.attr,
>>>> ????? &dev_attr_ctrl_val.attr,
>>>> @@ -973,6 +1080,7 @@ static struct attribute *tpdm_cmb_patt_attrs[] 
>>>> = {
>>>> ????? CMB_PATT_ATTR(1),
>>>> ????? CMB_PATT_MASK_ATTR(0),
>>>> ????? CMB_PATT_MASK_ATTR(1),
>>>> +??? &dev_attr_enable_ts.attr,
>>>> ????? NULL,
>>>> ? };
>>>> ? @@ -985,6 +1093,8 @@ static struct attribute *tpdm_dsb_attrs[] = {
>>>> ? ? static struct attribute *tpdm_cmb_attrs[] = {
>>>> ????? &dev_attr_cmb_mode.attr,
>>>> +??? &dev_attr_cmb_ts_all.attr,
>>>> +??? &dev_attr_cmb_trig_ts.attr,
>>>> ????? NULL,
>>>> ? };
>>>> ? diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>>>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> index e90d008c1cb2..65b7ca6c4077 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> @@ -11,6 +11,8 @@
>>>> ? ? /* CMB Subunit Registers */
>>>> ? #define TPDM_CMB_CR??????? (0xA00)
>>>> +/*CMB subunit timestamp insertion enable register*/
>>>> +#define TPDM_CMB_TIER??????? (0xA04)
>>>> ? /*CMB subunit timestamp pattern registers*/
>>>> ? #define TPDM_CMB_TPR(n)??????? (0xA08 + (n * 4))
>>>> ? /*CMB subunit timestamp pattern mask registers*/
>>>> @@ -24,6 +26,12 @@
>>>> ? #define TPDM_CMB_CR_ENA??????? BIT(0)
>>>> ? /* Trace collection mode for CMB subunit */
>>>> ? #define TPDM_CMB_CR_MODE??? BIT(1)
>>>> +/* Timestamp control for pattern match */
>>>> +#define TPDM_CMB_TIER_PATT_TSENAB??? BIT(0)
>>>> +/* CMB CTI timestamp request */
>>>> +#define TPDM_CMB_TIER_XTRIG_TSENAB??? BIT(1)
>>>> +/* For timestamp fo all trace */
>>>> +#define TPDM_CMB_TIER_TS_ALL??????? BIT(2)
>>>> ? ? /*Patten register number*/
>>>> ? #define TPDM_CMB_MAX_PATT??????? 2
>>>> @@ -217,6 +225,9 @@ struct dsb_dataset {
>>>> ?? * @patt_mask:??????? Save value for pattern mask
>>>> ?? * @trig_patt:??????? Save value for trigger pattern
>>>> ?? * @trig_patt_mask:?? Save value for trigger pattern mask
>>>> + * @patt_ts:????????? Indicates if pattern match for timestamp is 
>>>> enabled.
>>>> + * @trig_ts:????????? Indicates if CTI trigger for timestamp is 
>>>> enabled.
>>>> + * @ts_all:?????????? Indicates if timestamp is enabled for all 
>>>> packets.
>>>> ?? */
>>>> ? struct cmb_dataset {
>>>> ????? u32??????????? trace_mode;
>>>> @@ -224,6 +235,9 @@ struct cmb_dataset {
>>>> ????? u32??????????? patt_mask[TPDM_CMB_MAX_PATT];
>>>> ????? u32??????????? trig_patt[TPDM_CMB_MAX_PATT];
>>>> ????? u32??????????? trig_patt_mask[TPDM_CMB_MAX_PATT];
>>>> +??? bool??????????? patt_ts;
>>>> +??? bool??????????? trig_ts;
>>>> +??? bool??????????? ts_all;
>>>> ? };
>>>> ? ? /**
>>>
>
> _______________________________________________
> CoreSight mailing list -- coresight at lists.linaro.org
> To unsubscribe send an email to coresight-leave at lists.linaro.org


From fusibrandon13 at gmail.com  Wed Dec 20 01:51:39 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Wed, 20 Dec 2023 10:51:39 +0100
Subject: [RFC PATCH 0/2] Add support for reading D1 efuse speed bin
Message-ID: <20231220095141.27883-1-fusibrandon13@gmail.com>

Hi everyone,

This series is an attempt to get feedback on decoding D1 efuse speed bins
in the Sun50i H6 cpufreq driver, and turning the result into a meaningful
value that selects voltage ranges in an OPP table.

I want to make sure I get this right before sending in a v3 of the D1
cpufreq support series at

https://lore.kernel.org/linux-sunxi/20231218110543.64044-1-fusibrandon13 at gmail.com/T/#t

which is currently stuck at

https://lore.kernel.org/linux-sunxi/aad8302d-a015-44ee-ad11-1a4c6e00074c at sholland.org/

Brandon Cheo Fusi (2):
  cpufreq: sun50i: Add support for D1's speed bin decoding
  riscv: dts: allwinner: Fill in OPPs

 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi |  8 +-
 drivers/cpufreq/sun50i-cpufreq-nvmem.c        | 85 +++++++++++++++----
 2 files changed, 76 insertions(+), 17 deletions(-)

-- 
2.30.2



From fusibrandon13 at gmail.com  Wed Dec 20 01:51:40 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Wed, 20 Dec 2023 10:51:40 +0100
Subject: [RFC PATCH 1/2] cpufreq: sun50i: Add support for D1's speed bin decoding
In-Reply-To: <20231220095141.27883-1-fusibrandon13@gmail.com>
References: <20231220095141.27883-1-fusibrandon13@gmail.com>
Message-ID: <20231220095141.27883-2-fusibrandon13@gmail.com>

Adds support for decoding the efuse value read from D1 efuse speed
bins, and factors out equivalent code for sun50i.

The algorithm is gotten from

https://github.com/Tina-Linux/linux-5.4/blob/master/drivers/cpufreq/sun50i-cpufreq-nvmem.c#L293-L338

and maps an efuse value to either 0 or 1, with 1 meaning stable at
a lower supply voltage for the same clock frequency.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/sun50i-cpufreq-nvmem.c | 85 +++++++++++++++++++++-----
 1 file changed, 70 insertions(+), 15 deletions(-)

diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index ccf83780f..28afbe558 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -25,6 +25,66 @@
 
 static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
 
+struct sunxi_cpufreq_data {
+	u32 (*efuse_xlate)(u32 efuse_value);
+};
+
+static u32 sun20i_efuse_xlate(u32 efuse_value)
+{
+	u32 ret;
+
+	switch (efuse_value) {
+	case 0x5e00:
+		/* QFN package */
+		ret = 0;
+		break;
+	case 0x5c00:
+	case 0x7400:
+		/* QFN package */
+		ret = 1;
+		break;
+	case 0x5000:
+	default:
+		/* BGA package */
+		ret = 0;
+	}
+
+	return ret;
+}
+
+static u32 sun50i_efuse_xlate(u32 efuse_value)
+{
+	efuse_value = (efuse_value >> NVMEM_SHIFT) & NVMEM_MASK;
+
+	/*
+	* We treat unexpected efuse values as if the SoC was from
+	* the slowest bin. Expected efuse values are 1-3, slowest
+	* to fastest.
+	*/
+	if (efuse_value >= 1 && efuse_value <= 3)
+		return efuse_value - 1;
+	else
+		return 0;
+}
+
+struct sunxi_cpufreq_data sun20i_cpufreq_data = {
+	.efuse_xlate = sun20i_efuse_xlate,
+};
+
+struct sunxi_cpufreq_data sun50i_cpufreq_data = {
+	.efuse_xlate = sun50i_efuse_xlate,
+};
+
+static const struct of_device_id cpu_opp_match_list[] = {
+	{ .compatible = "allwinner,sun50i-h6-operating-points",
+	  .data = &sun50i_cpufreq_data,
+	},
+	{ .compatible = "allwinner,sun20i-d1-operating-points",
+	  .data = &sun20i_cpufreq_data,
+	},
+	{}
+};
+
 /**
  * sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
  * @versions: Set to the value parsed from efuse
@@ -36,9 +96,11 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	struct nvmem_cell *speedbin_nvmem;
 	struct device_node *np;
 	struct device *cpu_dev;
-	u32 *speedbin, efuse_value;
+	const struct of_device_id *opp_match;
+	const struct sunxi_cpufreq_data *opp_data;
+	u32 *speedbin, efuse_value = 0;
 	size_t len;
-	int ret;
+	int i;
 
 	cpu_dev = get_cpu_device(0);
 	if (!cpu_dev)
@@ -48,9 +110,8 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	if (!np)
 		return -ENOENT;
 
-	ret = of_device_is_compatible(np,
-				      "allwinner,sun50i-h6-operating-points");
-	if (!ret) {
+	opp_match = of_match_node(cpu_opp_match_list, np);
+	if (!opp_match) {
 		of_node_put(np);
 		return -ENOENT;
 	}
@@ -66,17 +127,11 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	if (IS_ERR(speedbin))
 		return PTR_ERR(speedbin);
 
-	efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
+	for (i = 0; i < len; i++)
+		efuse_value |= ((u32)speedbin[i] << (i * 8));
 
-	/*
-	 * We treat unexpected efuse values as if the SoC was from
-	 * the slowest bin. Expected efuse values are 1-3, slowest
-	 * to fastest.
-	 */
-	if (efuse_value >= 1 && efuse_value <= 3)
-		*versions = efuse_value - 1;
-	else
-		*versions = 0;
+	opp_data = opp_match->data;
+	*versions = opp_data->efuse_xlate(efuse_value);
 
 	kfree(speedbin);
 	return 0;
-- 
2.30.2



From fusibrandon13 at gmail.com  Wed Dec 20 01:51:41 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Wed, 20 Dec 2023 10:51:41 +0100
Subject: [RFC PATCH 2/2] riscv: dts: allwinner: Fill in OPPs
In-Reply-To: <20231220095141.27883-1-fusibrandon13@gmail.com>
References: <20231220095141.27883-1-fusibrandon13@gmail.com>
Message-ID: <20231220095141.27883-3-fusibrandon13@gmail.com>

Specifies two voltage ranges, in order of increasing stability,
for each OPP. This is heavily inspired by

https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L133

and

https://github.com/mangopi-sbc/tina-linux-5.4/blob/0d4903ebd9d2194ad914686d5b0fc1ddacf11a9d/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L182

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
index 2f1771c19..8e7bc8bd0 100644
--- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
+++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
@@ -48,13 +48,17 @@ opp_table_cpu: opp-table-cpu {
 		opp-408000000 {
 			clock-latency-ns = <244144>; /* 8 32k periods */
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt-speed0 = <900000 900000 1100000>;
+
+			opp-microvolt-speed0 = <950000 900000 1100000>;
+			opp-microvolt-speed1 = <900000 900000 1100000>;
 		};
 
 		opp-1080000000 {
 			clock-latency-ns = <244144>; /* 8 32k periods */
 			opp-hz = /bits/ 64 <1008000000>;
-			opp-microvolt-speed0 = <900000 900000 1100000>;
+
+			opp-microvolt-speed0 = <1100000 900000 1100000>;
+			opp-microvolt-speed1 = <950000 900000 1100000>;
 		};
 	};
 
-- 
2.30.2



From pchelkin at ispras.ru  Wed Dec 20 01:53:15 2023
From: pchelkin at ispras.ru (Fedor Pchelkin)
Date: Wed, 20 Dec 2023 12:53:15 +0300
Subject: [PATCH] drm/exynos: gsc: minor fix for loop iteration in gsc_runtime_resume
Message-ID: <20231220095316.23098-1-pchelkin@ispras.ru>

Do not forget to call clk_disable_unprepare() on the first element of
ctx->clocks array.

Found by Linux Verification Center (linuxtesting.org).

Fixes: 8b7d3ec83aba ("drm/exynos: gsc: Convert driver to IPP v2 core API")
Signed-off-by: Fedor Pchelkin <pchelkin at ispras.ru>
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 34cdabc30b4f..5302bebbe38c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1342,7 +1342,7 @@ static int __maybe_unused gsc_runtime_resume(struct device *dev)
 	for (i = 0; i < ctx->num_clocks; i++) {
 		ret = clk_prepare_enable(ctx->clocks[i]);
 		if (ret) {
-			while (--i > 0)
+			while (--i >= 0)
 				clk_disable_unprepare(ctx->clocks[i]);
 			return ret;
 		}
-- 
2.43.0



From david at redhat.com  Wed Dec 20 01:54:56 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 10:54:56 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
Message-ID: <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>

On 20.12.23 10:51, Ryan Roberts wrote:
> On 20/12/2023 09:17, David Hildenbrand wrote:
>> On 19.12.23 18:42, Ryan Roberts wrote:
>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>
>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>> range in the first place.
>>>>>>>
>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>> performant) as the previous implementation.
>>>>>>>
>>>>>>> This change addresses the core-mm refactoring only and a separate change
>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>
>>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>
>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>> tight loop in a process with 1G of populated memory and the time for the
>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>>> positive is slower, compared to baseline upon which the series is based:
>>>>>>>
>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>
>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>
>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>> ---
>>>>>>>  ??? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>>>  ??? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>>>>>  ??? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>
>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>> --- a/include/linux/pgtable.h
>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>  ??? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>  ??? #endif
>>>>>>>  ??? +#ifndef pte_batch_remaining
>>>>>>> +/**
>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>> + * @addr: Address of the first page.
>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>> + *
>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of
>>>>>>> ptes.
>>>>>>> + * In such cases, this function returns the remaining number of pages to
>>>>>>> the end
>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>> iterating
>>>>>>> + * over ptes.
>>>>>>> + *
>>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>>> + */
>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long
>>>>>>> addr,
>>>>>>> +??????????????????????? unsigned long end)
>>>>>>> +{
>>>>>>> +??? return 1;
>>>>>>> +}
>>>>>>> +#endif
>>>>>>
>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>
>>>>>> Was there no way to have some basic batching mechanism that doesn't require
>>>>>> arch
>>>>>> specifics?
>>>>>
>>>>> I tried a bunch of things but ultimately the way I've done it was the only way
>>>>> to reduce the order-0 fork regression to 0.
>>>>>
>>>>> My original v3 posting was costing 5% extra and even my first attempt at an
>>>>> arch-specific version that didn't resolve to a compile-time constant 1 still
>>>>> cost an extra 3%.
>>>>>
>>>>>
>>>>>>
>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>
>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>> * Check that PFN is consecutive
>>>>>> * Check that all PFNs belong to the same folio
>>>>>
>>>>> I haven't tried this exact approach, but I'd be surprised if I can get the
>>>>> regression under 4% with this. Further along the series I spent a lot of time
>>>>> having to fiddle with the arm64 implementation; every conditional and every
>>>>> memory read (even when in cache) was a problem. There is just so little in the
>>>>> inner loop that every instruction matters. (At least on Ampere Altra and Apple
>>>>> M2).
>>>>>
>>>>> Of course if you're willing to pay that 4-5% for order-0 then the benefit to
>>>>> order-9 is around 10% in my measurements. Personally though, I'd prefer to play
>>>>> safe and ensure the common order-0 case doesn't regress, as you previously
>>>>> suggested.
>>>>>
>>>>
>>>> I just hacked something up, on top of my beloved rmap cleanup/batching series. I
>>>> implemented very generic and simple batching for large folios (all PTE bits
>>>> except the PFN have to match).
>>>>
>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R) Silver
>>>> 4210R CPU.
>>>>
>>>> order-0: 0.014210 -> 0.013969
>>>>
>>>> -> Around 1.7 % faster
>>>>
>>>> order-9: 0.014373 -> 0.009149
>>>>
>>>> -> Around 36.3 % faster
>>>
>>> Well I guess that shows me :)
>>>
>>> I'll do a review and run the tests on my HW to see if it concurs.
>>
>>
>> I pushed a simple compile fixup (we need pte_next_pfn()).
> 
> I've just been trying to compile and noticed this. Will take a look at your update.
> 
> But upon review, I've noticed the part that I think makes this difficult for
> arm64 with the contpte optimization; You are calling ptep_get() for every pte in
> the batch. While this is functionally correct, once arm64 has the contpte
> changes, its ptep_get() has to read every pte in the contpte block in order to
> gather the access and dirty bits. So if your batching function ends up wealking
> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
> performance. That's why I added the arch-specific pte_batch_remaining()
> function; this allows the core-mm to skip to the end of the contpte block and
> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s instead
> of 256.
> 
> I considered making a ptep_get_noyoungdirty() variant, which would avoid the bit
> gathering. But we have a similar problem in zap_pte_range() and that function
> needs the dirty bit to update the folio. So it doesn't work there. (see patch 3
> in my series).
> 
> I guess you are going to say that we should combine both approaches, so that
> your batching loop can skip forward an arch-provided number of ptes? That would
> certainly work, but feels like an orthogonal change to what I'm trying to
> achieve :). Anyway, I'll spend some time playing with it today.

You can overwrite the function or add special-casing internally, yes.

Right now, your patch is called "mm: Batch-copy PTE ranges during 
fork()" and it doesn't do any of that besides preparing for some arm64 work.

-- 
Cheers,

David / dhildenb



From ryan.roberts at arm.com  Wed Dec 20 01:57:32 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 09:57:32 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
Message-ID: <15177acd-8d75-46a8-9460-98ea313a7b2b@arm.com>

On 20/12/2023 09:51, Ryan Roberts wrote:
> On 20/12/2023 09:17, David Hildenbrand wrote:
>> On 19.12.23 18:42, Ryan Roberts wrote:
>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>
>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>> range in the first place.
>>>>>>>
>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>> performant) as the previous implementation.
>>>>>>>
>>>>>>> This change addresses the core-mm refactoring only and a separate change
>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>
>>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>
>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>> tight loop in a process with 1G of populated memory and the time for the
>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>>> positive is slower, compared to baseline upon which the series is based:
>>>>>>>
>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>
>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>
>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>> ---
>>>>>>> ??? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>>> ??? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>>>>> ??? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>
>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>> --- a/include/linux/pgtable.h
>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>> ??? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>> ??? #endif
>>>>>>> ??? +#ifndef pte_batch_remaining
>>>>>>> +/**
>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>> + * @addr: Address of the first page.
>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>> + *
>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of
>>>>>>> ptes.
>>>>>>> + * In such cases, this function returns the remaining number of pages to
>>>>>>> the end
>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>> iterating
>>>>>>> + * over ptes.
>>>>>>> + *
>>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>>> + */
>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long
>>>>>>> addr,
>>>>>>> +??????????????????????? unsigned long end)
>>>>>>> +{
>>>>>>> +??? return 1;
>>>>>>> +}
>>>>>>> +#endif
>>>>>>
>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>
>>>>>> Was there no way to have some basic batching mechanism that doesn't require
>>>>>> arch
>>>>>> specifics?
>>>>>
>>>>> I tried a bunch of things but ultimately the way I've done it was the only way
>>>>> to reduce the order-0 fork regression to 0.
>>>>>
>>>>> My original v3 posting was costing 5% extra and even my first attempt at an
>>>>> arch-specific version that didn't resolve to a compile-time constant 1 still
>>>>> cost an extra 3%.
>>>>>
>>>>>
>>>>>>
>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>
>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>> * Check that PFN is consecutive
>>>>>> * Check that all PFNs belong to the same folio
>>>>>
>>>>> I haven't tried this exact approach, but I'd be surprised if I can get the
>>>>> regression under 4% with this. Further along the series I spent a lot of time
>>>>> having to fiddle with the arm64 implementation; every conditional and every
>>>>> memory read (even when in cache) was a problem. There is just so little in the
>>>>> inner loop that every instruction matters. (At least on Ampere Altra and Apple
>>>>> M2).
>>>>>
>>>>> Of course if you're willing to pay that 4-5% for order-0 then the benefit to
>>>>> order-9 is around 10% in my measurements. Personally though, I'd prefer to play
>>>>> safe and ensure the common order-0 case doesn't regress, as you previously
>>>>> suggested.
>>>>>
>>>>
>>>> I just hacked something up, on top of my beloved rmap cleanup/batching series. I
>>>> implemented very generic and simple batching for large folios (all PTE bits
>>>> except the PFN have to match).
>>>>
>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R) Silver
>>>> 4210R CPU.
>>>>
>>>> order-0: 0.014210 -> 0.013969
>>>>
>>>> -> Around 1.7 % faster
>>>>
>>>> order-9: 0.014373 -> 0.009149
>>>>
>>>> -> Around 36.3 % faster
>>>
>>> Well I guess that shows me :)
>>>
>>> I'll do a review and run the tests on my HW to see if it concurs.
>>
>>
>> I pushed a simple compile fixup (we need pte_next_pfn()).
> 
> I've just been trying to compile and noticed this. Will take a look at your update.

Took a look; there will still be arch work needed; arm64 doesn't define
PFN_PTE_SHIFT because it defines set_ptes(). I'm not sure if there are other
arches that also don't define PFN_PTE_SHIFT (or pte_next_pfn()) if the math is
more complex) - it will need an audit.

> 
> But upon review, I've noticed the part that I think makes this difficult for
> arm64 with the contpte optimization; You are calling ptep_get() for every pte in
> the batch. While this is functionally correct, once arm64 has the contpte
> changes, its ptep_get() has to read every pte in the contpte block in order to
> gather the access and dirty bits. So if your batching function ends up wealking
> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
> performance. That's why I added the arch-specific pte_batch_remaining()
> function; this allows the core-mm to skip to the end of the contpte block and
> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s instead
> of 256.
> 
> I considered making a ptep_get_noyoungdirty() variant, which would avoid the bit
> gathering. But we have a similar problem in zap_pte_range() and that function
> needs the dirty bit to update the folio. So it doesn't work there. (see patch 3
> in my series).
> 
> I guess you are going to say that we should combine both approaches, so that
> your batching loop can skip forward an arch-provided number of ptes? That would
> certainly work, but feels like an orthogonal change to what I'm trying to
> achieve :). Anyway, I'll spend some time playing with it today.
> 
> 
>>
>> Note that we should probably handle "ptep_set_wrprotects" rather like set_ptes:
>>
>> #ifndef wrprotect_ptes
>> static inline void wrprotect_ptes(struct mm_struct *mm, unsigned long addr,
>> ?????????????? pte_t *ptep, unsigned int nr)
>> {
>> ?????? for (;;) {
>> ?????????????? ptep_set_wrprotect(mm, addr, ptep);
>> ?????????????? if (--nr == 0)
>> ?????????????????????? break;
>> ?????????????? ptep++;
>> ?????????????? addr += PAGE_SIZE;
>> ?????? }
>> }
>> #endif

Yes that's a much better name; I've also introduced clear_ptes() (in patch 3)
and set_ptes_full(), which takes a flag that allows arm64 to avoid trying to
fold a contpte block; needed to avoid regressing fork once the contpte changes
are present.

>>
>>
> 



From david at redhat.com  Wed Dec 20 02:00:06 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 11:00:06 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <15177acd-8d75-46a8-9460-98ea313a7b2b@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <15177acd-8d75-46a8-9460-98ea313a7b2b@arm.com>
Message-ID: <23638533-048f-4110-971f-bb359b39b60b@redhat.com>

On 20.12.23 10:57, Ryan Roberts wrote:
> On 20/12/2023 09:51, Ryan Roberts wrote:
>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>
>>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>> range in the first place.
>>>>>>>>
>>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>> performant) as the previous implementation.
>>>>>>>>
>>>>>>>> This change addresses the core-mm refactoring only and a separate change
>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>
>>>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>
>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>>> tight loop in a process with 1G of populated memory and the time for the
>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>>>> positive is slower, compared to baseline upon which the series is based:
>>>>>>>>
>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>
>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>
>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>> ---
>>>>>>>>  ??? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>>>>  ??? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>>>>>>  ??? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>  ??? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>  ??? #endif
>>>>>>>>  ??? +#ifndef pte_batch_remaining
>>>>>>>> +/**
>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>> + * @addr: Address of the first page.
>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>> + *
>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of
>>>>>>>> ptes.
>>>>>>>> + * In such cases, this function returns the remaining number of pages to
>>>>>>>> the end
>>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>>> iterating
>>>>>>>> + * over ptes.
>>>>>>>> + *
>>>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>>>> + */
>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long
>>>>>>>> addr,
>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>> +{
>>>>>>>> +??? return 1;
>>>>>>>> +}
>>>>>>>> +#endif
>>>>>>>
>>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>>
>>>>>>> Was there no way to have some basic batching mechanism that doesn't require
>>>>>>> arch
>>>>>>> specifics?
>>>>>>
>>>>>> I tried a bunch of things but ultimately the way I've done it was the only way
>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>
>>>>>> My original v3 posting was costing 5% extra and even my first attempt at an
>>>>>> arch-specific version that didn't resolve to a compile-time constant 1 still
>>>>>> cost an extra 3%.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>
>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>> * Check that PFN is consecutive
>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>
>>>>>> I haven't tried this exact approach, but I'd be surprised if I can get the
>>>>>> regression under 4% with this. Further along the series I spent a lot of time
>>>>>> having to fiddle with the arm64 implementation; every conditional and every
>>>>>> memory read (even when in cache) was a problem. There is just so little in the
>>>>>> inner loop that every instruction matters. (At least on Ampere Altra and Apple
>>>>>> M2).
>>>>>>
>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the benefit to
>>>>>> order-9 is around 10% in my measurements. Personally though, I'd prefer to play
>>>>>> safe and ensure the common order-0 case doesn't regress, as you previously
>>>>>> suggested.
>>>>>>
>>>>>
>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching series. I
>>>>> implemented very generic and simple batching for large folios (all PTE bits
>>>>> except the PFN have to match).
>>>>>
>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R) Silver
>>>>> 4210R CPU.
>>>>>
>>>>> order-0: 0.014210 -> 0.013969
>>>>>
>>>>> -> Around 1.7 % faster
>>>>>
>>>>> order-9: 0.014373 -> 0.009149
>>>>>
>>>>> -> Around 36.3 % faster
>>>>
>>>> Well I guess that shows me :)
>>>>
>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>
>>>
>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>
>> I've just been trying to compile and noticed this. Will take a look at your update.
> 
> Took a look; there will still be arch work needed; arm64 doesn't define
> PFN_PTE_SHIFT because it defines set_ptes(). I'm not sure if there are other
> arches that also don't define PFN_PTE_SHIFT (or pte_next_pfn()) if the math is
> more complex) - it will need an audit.
> 

Right, likely many that have their own set_ptes() implementation right now.

-- 
Cheers,

David / dhildenb



From michal.simek at amd.com  Wed Dec 20 02:00:26 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 11:00:26 +0100
Subject: [PATCH v2 0/4] dt-bindings: xilinx: Add missing firmware child nodes
Message-ID: <cover.1703066422.git.michal.simek@amd.com>

Hi,

series is converting missing descriptions for child nodes and also
synchronizing name for power-controller discussed with Krzysztof in v1
version available here.
https://lore.kernel.org/r/fc7863a2-d3c5-47c8-9484-ef9cd6d7dd5d at linaro.org

Thanks,
Michal

Changes in v2:
- Sort nodes by name
- Rename zynqmp-power to power-controller
- Keep only single patch for easier handling as done in v1
- New patch in series
- New patch is series
- New patch is series

Michal Simek (4):
  dt-bindings: firmware: xilinx: Describe missing child nodes
  dt-bindings: firmware: xilinx: Sort node names (clock-controller)
  dt-bindings: power: reset: xilinx: Rename node names in examples
  arm64: zynqmp: Rename zynqmp-power node to power-controller

 .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 49 +++++++++++++++----
 .../power/reset/xlnx,zynqmp-power.yaml        |  4 +-
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi        |  2 +-
 3 files changed, 43 insertions(+), 12 deletions(-)

-- 
2.36.1



From michal.simek at amd.com  Wed Dec 20 02:00:27 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 11:00:27 +0100
Subject: [PATCH v2 1/4] dt-bindings: firmware: xilinx: Describe missing child nodes
In-Reply-To: <cover.1703066422.git.michal.simek@amd.com>
References: <cover.1703066422.git.michal.simek@amd.com>
Message-ID: <12d012d7ee372e43142bc4a56b0bbf3cb9c51c34.1703066422.git.michal.simek@amd.com>

Firmware node has more than fpga, aes and clock child nodes but also power,
reset, gpio, pinctrl and pcap which are not described yet.
All of them have binding in separate files but there is missing connection
to firmware node that's why describe it.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

Changes in v2:
- Sort nodes by name
- Rename zynqmp-power to power-controller
- Keep only single patch for easier handling as done in v1

 .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index 98945220c33c..310c334e88a2 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -41,6 +41,37 @@ properties:
   "#power-domain-cells":
     const: 1
 
+  gpio:
+    $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
+    description: The gpio node describes connect to PS_MODE pins via firmware
+      interface.
+    type: object
+
+  pcap:
+    $ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml
+    description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to
+      configure the Programmable Logic (PL). The configuration uses the
+      firmware interface.
+    type: object
+
+  pinctrl:
+    $ref: /schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+    description: The pinctrl node provides access to pinconfig and pincontrol
+      functionality available in firmware.
+    type: object
+
+  power-controller:
+    $ref: /schemas/power/reset/xlnx,zynqmp-power.yaml#
+    description: The zynqmp-power node describes the power management
+      configurations. It will control remote suspend/shutdown interfaces.
+    type: object
+
+  reset-controller:
+    $ref: /schemas/reset/xlnx,zynqmp-reset.yaml#
+    description: The reset-controller node describes connection to the reset
+      functionality via firmware interface.
+    type: object
+
   versal-fpga:
     $ref: /schemas/fpga/xlnx,versal-fpga.yaml#
     description: Compatible of the FPGA device.
-- 
2.36.1



From michal.simek at amd.com  Wed Dec 20 02:00:28 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 11:00:28 +0100
Subject: [PATCH v2 2/4] dt-bindings: firmware: xilinx: Sort node names (clock-controller)
In-Reply-To: <cover.1703066422.git.michal.simek@amd.com>
References: <cover.1703066422.git.michal.simek@amd.com>
Message-ID: <9f21ffd8018637c879bc4417e5f1de773412218d.1703066422.git.michal.simek@amd.com>

Nodes should be sorted that's why move clock-controller to the top of list.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

Changes in v2:
- New patch in series

 .../firmware/xilinx/xlnx,zynqmp-firmware.yaml  | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index 310c334e88a2..d64033140c53 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -41,6 +41,15 @@ properties:
   "#power-domain-cells":
     const: 1
 
+  clock-controller:
+    $ref: /schemas/clock/xlnx,versal-clk.yaml#
+    description: The clock controller is a hardware block of Xilinx versal
+      clock tree. It reads required input clock frequencies from the devicetree
+      and acts as clock provider for all clock consumers of PS clocks.list of
+      clock specifiers which are external input clocks to the given clock
+      controller.
+    type: object
+
   gpio:
     $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
     description: The gpio node describes connect to PS_MODE pins via firmware
@@ -84,15 +93,6 @@ properties:
       vector.
     type: object
 
-  clock-controller:
-    $ref: /schemas/clock/xlnx,versal-clk.yaml#
-    description: The clock controller is a hardware block of Xilinx versal
-      clock tree. It reads required input clock frequencies from the devicetree
-      and acts as clock provider for all clock consumers of PS clocks.list of
-      clock specifiers which are external input clocks to the given clock
-      controller.
-    type: object
-
 required:
   - compatible
 
-- 
2.36.1



From michal.simek at amd.com  Wed Dec 20 02:00:29 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 11:00:29 +0100
Subject: [PATCH v2 3/4] dt-bindings: power: reset: xilinx: Rename node names in examples
In-Reply-To: <cover.1703066422.git.michal.simek@amd.com>
References: <cover.1703066422.git.michal.simek@amd.com>
Message-ID: <26aa3459310ba4624ccb5865ca32017357591e4d.1703066422.git.michal.simek@amd.com>

Rename zynqmp-power node name to power-controller which is more aligned
with generic node name recommendation.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

Changes in v2:
- New patch is series

 .../devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml    | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
index 45792e216981..3484be1c89d3 100644
--- a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
@@ -57,7 +57,7 @@ examples:
 
     firmware {
       zynqmp-firmware {
-        zynqmp-power {
+        power-controller {
           compatible = "xlnx,zynqmp-power";
           interrupts = <0 35 4>;
         };
@@ -70,7 +70,7 @@ examples:
 
     firmware {
       zynqmp-firmware {
-        zynqmp-power {
+        power-controller {
           compatible = "xlnx,zynqmp-power";
           interrupt-parent = <&gic>;
           interrupts = <0 35 4>;
-- 
2.36.1



From michal.simek at amd.com  Wed Dec 20 02:00:30 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 11:00:30 +0100
Subject: [PATCH v2 4/4] arm64: zynqmp: Rename zynqmp-power node to power-controller
In-Reply-To: <cover.1703066422.git.michal.simek@amd.com>
References: <cover.1703066422.git.michal.simek@amd.com>
Message-ID: <48590ed3fe1b834cdab111b023b6ce3777a5f96d.1703066422.git.michal.simek@amd.com>

Rename zynqmp-power node name to power-controller which is more aligned
with generic node name recommendation.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

Changes in v2:
- New patch is series

 arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index eaba466804bc..b1bac486c3f7 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -186,7 +186,7 @@ zynqmp_firmware: zynqmp-firmware {
 			method = "smc";
 			bootph-all;
 
-			zynqmp_power: zynqmp-power {
+			zynqmp_power: power-controller {
 				bootph-all;
 				compatible = "xlnx,zynqmp-power";
 				interrupt-parent = <&gic>;
-- 
2.36.1



From moudy.ho at mediatek.com  Wed Dec 20 02:08:37 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:37 +0800
Subject: [PATCH v10 00/16] introduce more MDP3 components in MT8195
Message-ID: <20231220100853.20616-1-moudy.ho@mediatek.com>

From: Moudy Ho <moudy.ho at mediatek.corp-partner.google.com>

Changes since v9:
- Rebase on linux-next.
- Dependent dtsi files:
  Message ID = 20231030094840.2479-1-moudy.ho at mediatek.com
- Depends on:
  Message ID = 20231214055847.4936-1-shawn.sung at mediatek.com
- Include the missing compatible name 'mediatek,mt8188-vdo1-rdma' in
  patch [2/16].

Changes since v8:
- Rebase on linux-next.
- Dependent dtsi files:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=797543
- Depends on:
  Message ID = 20231024130048.14749-9-shawn.sung at mediatek.com
- Following Rob's suggestion, the number of 'clocks' and 'mboxes' items are
  restricted using the 'minItems' in [2/16] and [3/16].
- Revise the dependent mt8188 disp padding compatible name in [16/16].

Changes since v7:
- Rebase on linux-next.
- Dependent dtsi files:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=797543
- Depends on:
  Message ID = 20231024130048.14749-9-shawn.sung at mediatek.com
- Correct the bindings of the four components: FG, TCC, TDSHP and HDR.
  The names of the first three are expanded in the title, and
  the descriptions of all four have been enhanced.

Changes since v6:
- Rebase on v6.6-rc5.
- Dependent dtsi files:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=792079
- Depends on:
  Message ID = 20231006073831.10402-5-shawn.sung at mediatek.com
- Discard splitting RDMA's common properties and instead use 'allOf' to
  isolate different platform features.
- Revise the incorrect properties in FG, HDR, STITCH, TCC and TDAP bindings.
- Adding SoC-specific compatible string to components, like WROT and RSZ,
  that are inherited from MT8183.
- Fixed typos in TCC patch and enhancing its hardware description.

Changes since v5:
- Rebase on v6.6-rc2.
- Dependent dtsi files:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=786511
- Depends on:
  Message ID = 20230911074233.31556-5-shawn.sung at mediatek.com
- Split out common propertis for RDMA.
- Split each component into independent patches.

Changes since v4:
- Rebase on v6.6-rc1
- Organize identical hardware components into their respective files.

Hi,

The purpose of this patch is to separate the MDP3-related bindings from
the original mailing list mentioned below:
https://lore.kernel.org/all/20230208092209.19472-1-moudy.ho at mediatek.com/
Those binding files describe additional components that
are present in the mt8195.

Moudy Ho (16):
  dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with
    generic names
  dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under
    display
  dt-bindings: media: mediatek: mdp3: add config for MT8195 RDMA
  dt-bindings: media: mediatek: mdp3: add compatible for MT8195 RSZ
  dt-bindings: media: mediatek: mdp3: add compatible for MT8195 WROT
  dt-bindings: media: mediatek: mdp3: add component FG for MT8195
  dt-bindings: media: mediatek: mdp3: add component HDR for MT8195
  dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
  dt-bindings: media: mediatek: mdp3: add component TCC for MT8195
  dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195
  dt-bindings: display: mediatek: aal: add compatible for MT8195
  dt-bindings: display: mediatek: color: add compatible for MT8195
  dt-bindings: display: mediatek: merge: add compatible for MT8195
  dt-bindings: display: mediatek: ovl: add compatible for MT8195
  dt-bindings: display: mediatek: split: add compatible for MT8195
  dt-bindings: display: mediatek: padding: add compatible for MT8195

 .../display/mediatek/mediatek,aal.yaml        |  1 +
 .../display/mediatek/mediatek,color.yaml      |  1 +
 .../display/mediatek/mediatek,mdp-rdma.yaml   | 92 ------------------
 .../display/mediatek/mediatek,merge.yaml      |  1 +
 .../display/mediatek/mediatek,ovl.yaml        |  1 +
 .../display/mediatek/mediatek,padding.yaml    |  4 +-
 .../display/mediatek/mediatek,split.yaml      | 27 ++++++
 .../bindings/media/mediatek,mdp3-fg.yaml      | 61 ++++++++++++
 .../bindings/media/mediatek,mdp3-hdr.yaml     | 61 ++++++++++++
 .../bindings/media/mediatek,mdp3-rdma.yaml    | 93 ++++++++++++++++---
 .../bindings/media/mediatek,mdp3-rsz.yaml     |  6 +-
 .../bindings/media/mediatek,mdp3-stitch.yaml  | 61 ++++++++++++
 .../bindings/media/mediatek,mdp3-tcc.yaml     | 62 +++++++++++++
 .../bindings/media/mediatek,mdp3-tdshp.yaml   | 61 ++++++++++++
 .../bindings/media/mediatek,mdp3-wrot.yaml    | 29 ++++--
 15 files changed, 442 insertions(+), 119 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml

-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:40 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:40 +0800
Subject: [PATCH v10 03/16] dt-bindings: media: mediatek: mdp3: add config for MT8195 RDMA
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-4-moudy.ho@mediatek.com>

Added the configuration for MT8195 RDMA. In comparison to MT8183, it
no longer shares SRAM with RSZ, and there are now preconfigured 5 mbox.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/media/mediatek,mdp3-rdma.yaml    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index e9955639ce19..f9ca66413d51 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -22,6 +22,7 @@ properties:
   compatible:
     oneOf:
       - const: mediatek,mt8183-mdp3-rdma
+      - const: mediatek,mt8195-mdp3-rdma
       - const: mediatek,mt8195-vdo1-rdma
       - items:
           - const: mediatek,mt8188-vdo1-rdma
@@ -73,6 +74,9 @@ properties:
     items:
       - description: used for 1st data pipe from RDMA
       - description: used for 2nd data pipe from RDMA
+      - description: used for 3rd data pipe from RDMA
+      - description: used for 4th data pipe from RDMA
+      - description: used for the data pipe from SPLIT
     minItems: 1
 
   interrupts:
@@ -109,6 +113,23 @@ allOf:
         - mboxes
         - mediatek,gce-events
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: mediatek,mt8195-mdp3-rdma
+
+    then:
+      properties:
+        clocks:
+          maxItems: 1
+
+        mboxes:
+          minItems: 5
+
+      required:
+        - mediatek,gce-events
+
   - if:
       properties:
         compatible:
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:43 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:43 +0800
Subject: [PATCH v10 06/16] dt-bindings: media: mediatek: mdp3: add component FG for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-7-moudy.ho@mediatek.com>

Add the fundamental hardware configuration of component FG,
which is controlled by MDP3 on MT8195.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <zangelogioacchino.delregno at collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/media/mediatek,mdp3-fg.yaml      | 61 +++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
new file mode 100644
index 000000000000..03f31b009085
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-fg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 Film Grain
+
+maintainers:
+  - Matthias Brugger <matthias.bgg at gmail.com>
+  - Moudy Ho <moudy.ho at mediatek.com>
+
+description:
+  Film Grain (FG) is a Media Data Path 3 (MDP3) component used to add
+  the film grain according to the AOMedia Video 1 (AV1) standard.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt8195-mdp3-fg
+
+  reg:
+    maxItems: 1
+
+  mediatek,gce-client-reg:
+    description:
+      The register of display function block to be set by gce. There are 4 arguments,
+      such as gce node, subsys id, offset and register size. The subsys id that is
+      mapping to the register of display function blocks is defined in the gce header
+      include/dt-bindings/gce/<chip>-gce.h of each chips.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      items:
+        - description: phandle of GCE
+        - description: GCE subsys id
+        - description: register offset
+        - description: register size
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - mediatek,gce-client-reg
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8195-clk.h>
+    #include <dt-bindings/gce/mt8195-gce.h>
+
+    display at 14002000 {
+        compatible = "mediatek,mt8195-mdp3-fg";
+        reg = <0x14002000 0x1000>;
+        mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x2000 0x1000>;
+        clocks = <&vppsys0 CLK_VPP0_MDP_FG>;
+    };
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:42 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:42 +0800
Subject: [PATCH v10 05/16] dt-bindings: media: mediatek: mdp3: add compatible for MT8195 WROT
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-6-moudy.ho@mediatek.com>

MT8195 WROT inherited from MT8183, add the corresponding
compatible name to it.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../devicetree/bindings/media/mediatek,mdp3-wrot.yaml       | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
index 64ea98aa0592..53a679338402 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
@@ -15,9 +15,13 @@ description: |
 
 properties:
   compatible:
-    items:
+    oneOf:
       - enum:
           - mediatek,mt8183-mdp3-wrot
+      - items:
+          - enum:
+              - mediatek,mt8195-mdp3-wrot
+          - const: mediatek,mt8183-mdp3-wrot
 
   reg:
     maxItems: 1
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:49 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:49 +0800
Subject: [PATCH v10 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-13-moudy.ho@mediatek.com>

Add a compatible string for the COLOR block in MediaTek MT8195 that
is controlled by MDP3.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../devicetree/bindings/display/mediatek/mediatek,color.yaml     | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index f21e44092043..b886ca0d89ea 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -26,6 +26,7 @@ properties:
           - mediatek,mt2701-disp-color
           - mediatek,mt8167-disp-color
           - mediatek,mt8173-disp-color
+          - mediatek,mt8195-mdp3-color
       - items:
           - enum:
               - mediatek,mt7623-disp-color
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:41 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:41 +0800
Subject: [PATCH v10 04/16] dt-bindings: media: mediatek: mdp3: add compatible for MT8195 RSZ
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-5-moudy.ho@mediatek.com>

MT8195 RSZ inherited from MT8183, add the corresponding
compatible name to it.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../devicetree/bindings/media/mediatek,mdp3-rsz.yaml        | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
index 78f9de6192ef..f5676bec4326 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
@@ -15,9 +15,13 @@ description: |
 
 properties:
   compatible:
-    items:
+    oneOf:
       - enum:
           - mediatek,mt8183-mdp3-rsz
+      - items:
+          - enum:
+              - mediatek,mt8195-mdp3-rsz
+          - const: mediatek,mt8183-mdp3-rsz
 
   reg:
     maxItems: 1
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:53 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:53 +0800
Subject: [PATCH v10 16/16] dt-bindings: display: mediatek: padding: add compatible for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-17-moudy.ho@mediatek.com>

Add a compatible string for the PADDING block in MediaTek MT8195 that
is controlled by MDP3.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../bindings/display/mediatek/mediatek,padding.yaml           | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
index 6bad7dc2d69f..be07bbdc54e3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
@@ -20,7 +20,9 @@ description:
 
 properties:
   compatible:
-    const: mediatek,mt8188-disp-padding
+    enum:
+      - mediatek,mt8188-disp-padding
+      - mediatek,mt8195-mdp3-padding
 
   reg:
     maxItems: 1
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:51 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:51 +0800
Subject: [PATCH v10 14/16] dt-bindings: display: mediatek: ovl: add compatible for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-15-moudy.ho@mediatek.com>

Add a compatible string for the OVL block in MediaTek MT8195 that
is controlled by MDP3.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../devicetree/bindings/display/mediatek/mediatek,ovl.yaml       | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index 3e1069b00b56..c471a181d125 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -26,6 +26,7 @@ properties:
           - mediatek,mt8173-disp-ovl
           - mediatek,mt8183-disp-ovl
           - mediatek,mt8192-disp-ovl
+          - mediatek,mt8195-mdp3-ovl
       - items:
           - enum:
               - mediatek,mt7623-disp-ovl
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:45 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:45 +0800
Subject: [PATCH v10 08/16] dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-9-moudy.ho@mediatek.com>

Add the fundamental hardware configuration of component STITCH,
which is controlled by MDP3 on MT8195.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../bindings/media/mediatek,mdp3-stitch.yaml  | 61 +++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
new file mode 100644
index 000000000000..d815bea29154
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-stitch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 STITCH
+
+maintainers:
+  - Matthias Brugger <matthias.bgg at gmail.com>
+  - Moudy Ho <moudy.ho at mediatek.com>
+
+description:
+  One of Media Data Path 3 (MDP3) components used to combine multiple video frame
+  with overlapping fields of view to produce a segmented panorame.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt8195-mdp3-stitch
+
+  reg:
+    maxItems: 1
+
+  mediatek,gce-client-reg:
+    description:
+      The register of display function block to be set by gce. There are 4 arguments,
+      such as gce node, subsys id, offset and register size. The subsys id that is
+      mapping to the register of display function blocks is defined in the gce header
+      include/dt-bindings/gce/<chip>-gce.h of each chips.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      items:
+        - description: phandle of GCE
+        - description: GCE subsys id
+        - description: register offset
+        - description: register size
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - mediatek,gce-client-reg
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8195-clk.h>
+    #include <dt-bindings/gce/mt8195-gce.h>
+
+    display at 14003000 {
+        compatible = "mediatek,mt8195-mdp3-stitch";
+        reg = <0x14003000 0x1000>;
+        mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x3000 0x1000>;
+        clocks = <&vppsys0 CLK_VPP0_STITCH>;
+    };
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:44 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:44 +0800
Subject: [PATCH v10 07/16] dt-bindings: media: mediatek: mdp3: add component HDR for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-8-moudy.ho@mediatek.com>

Add the fundamental hardware configuration of component HDR,
which is controlled by MDP3 on MT8195.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/media/mediatek,mdp3-hdr.yaml     | 61 +++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
new file mode 100644
index 000000000000..d4609bba6578
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-hdr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 HDR
+
+maintainers:
+  - Matthias Brugger <matthias.bgg at gmail.com>
+  - Moudy Ho <moudy.ho at mediatek.com>
+
+description:
+  A Media Data Path 3 (MDP3) component used to perform conversion from
+  High Dynamic Range (HDR) to Standard Dynamic Range (SDR).
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt8195-mdp3-hdr
+
+  reg:
+    maxItems: 1
+
+  mediatek,gce-client-reg:
+    description:
+      The register of display function block to be set by gce. There are 4 arguments,
+      such as gce node, subsys id, offset and register size. The subsys id that is
+      mapping to the register of display function blocks is defined in the gce header
+      include/dt-bindings/gce/<chip>-gce.h of each chips.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      items:
+        - description: phandle of GCE
+        - description: GCE subsys id
+        - description: register offset
+        - description: register size
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - mediatek,gce-client-reg
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8195-clk.h>
+    #include <dt-bindings/gce/mt8195-gce.h>
+
+    display at 14004000 {
+        compatible = "mediatek,mt8195-mdp3-hdr";
+        reg = <0x14004000 0x1000>;
+        mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x4000 0x1000>;
+        clocks = <&vppsys0 CLK_VPP0_MDP_HDR>;
+    };
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:48 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:48 +0800
Subject: [PATCH v10 11/16] dt-bindings: display: mediatek: aal: add compatible for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-12-moudy.ho@mediatek.com>

Add a compatible string for the AAL block in MediaTek MT8195 that
is controlled by MDP3.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Acked-by: Conor Dooley <conor.dooley at microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../devicetree/bindings/display/mediatek/mediatek,aal.yaml       | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index 7fd42c8fdc32..b4c28e96dd55 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -24,6 +24,7 @@ properties:
       - enum:
           - mediatek,mt8173-disp-aal
           - mediatek,mt8183-disp-aal
+          - mediatek,mt8195-mdp3-aal
       - items:
           - enum:
               - mediatek,mt2712-disp-aal
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:39 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:39 +0800
Subject: [PATCH v10 02/16] dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under display
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-3-moudy.ho@mediatek.com>

To simplify maintenance and avoid branches, the identical component
should be merged and placed in the path belonging to the MDP
(from display/* to media/*).

In addition, currently only MDP utilizes RDMA through CMDQ, and the
necessary properties for "mediatek,gce-events", and "mboxes" have been
set up for this purpose.
Within DISP, it directly receives component interrupt signals.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
---
 .../display/mediatek/mediatek,mdp-rdma.yaml   | 92 -------------------
 .../bindings/media/mediatek,mdp3-rdma.yaml    | 43 ++++++++-
 2 files changed, 40 insertions(+), 95 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
deleted file mode 100644
index 7570a0684967..000000000000
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
+++ /dev/null
@@ -1,92 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: MediaTek MDP RDMA
-
-maintainers:
-  - Chun-Kuang Hu <chunkuang.hu at kernel.org>
-  - Philipp Zabel <p.zabel at pengutronix.de>
-
-description:
-  The MediaTek MDP RDMA stands for Read Direct Memory Access.
-  It provides real time data to the back-end panel driver, such as DSI,
-  DPI and DP_INTF.
-  It contains one line buffer to store the sufficient pixel data.
-  RDMA device node must be siblings to the central MMSYS_CONFIG node.
-  For a description of the MMSYS_CONFIG binding, see
-  Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for details.
-
-properties:
-  compatible:
-    oneOf:
-      - const: mediatek,mt8195-vdo1-rdma
-      - items:
-          - const: mediatek,mt8188-vdo1-rdma
-          - const: mediatek,mt8195-vdo1-rdma
-
-  reg:
-    maxItems: 1
-
-  interrupts:
-    maxItems: 1
-
-  power-domains:
-    maxItems: 1
-
-  clocks:
-    items:
-      - description: RDMA Clock
-
-  iommus:
-    maxItems: 1
-
-  mediatek,gce-client-reg:
-    description:
-      The register of display function block to be set by gce. There are 4 arguments,
-      such as gce node, subsys id, offset and register size. The subsys id that is
-      mapping to the register of display function blocks is defined in the gce header
-      include/dt-bindings/gce/<chip>-gce.h of each chips.
-    $ref: /schemas/types.yaml#/definitions/phandle-array
-    items:
-      items:
-        - description: phandle of GCE
-        - description: GCE subsys id
-        - description: register offset
-        - description: register size
-    maxItems: 1
-
-required:
-  - compatible
-  - reg
-  - power-domains
-  - clocks
-  - iommus
-  - mediatek,gce-client-reg
-
-additionalProperties: false
-
-examples:
-  - |
-    #include <dt-bindings/interrupt-controller/arm-gic.h>
-    #include <dt-bindings/clock/mt8195-clk.h>
-    #include <dt-bindings/power/mt8195-power.h>
-    #include <dt-bindings/gce/mt8195-gce.h>
-    #include <dt-bindings/memory/mt8195-memory-port.h>
-
-    soc {
-        #address-cells = <2>;
-        #size-cells = <2>;
-
-        rdma at 1c104000 {
-            compatible = "mediatek,mt8195-vdo1-rdma";
-            reg = <0 0x1c104000 0 0x1000>;
-            interrupts = <GIC_SPI 495 IRQ_TYPE_LEVEL_HIGH 0>;
-            clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
-            power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>;
-            iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>;
-            mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX 0x4000 0x1000>;
-        };
-    };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index e1ffe7eb2cdf..e9955639ce19 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -20,8 +20,12 @@ description: |
 
 properties:
   compatible:
-    items:
+    oneOf:
       - const: mediatek,mt8183-mdp3-rdma
+      - const: mediatek,mt8195-vdo1-rdma
+      - items:
+          - const: mediatek,mt8188-vdo1-rdma
+          - const: mediatek,mt8195-vdo1-rdma
 
   reg:
     maxItems: 1
@@ -60,6 +64,7 @@ properties:
     items:
       - description: RDMA clock
       - description: RSZ clock
+    minItems: 1
 
   iommus:
     maxItems: 1
@@ -68,6 +73,10 @@ properties:
     items:
       - description: used for 1st data pipe from RDMA
       - description: used for 2nd data pipe from RDMA
+    minItems: 1
+
+  interrupts:
+    maxItems: 1
 
   '#dma-cells':
     const: 1
@@ -76,13 +85,41 @@ required:
   - compatible
   - reg
   - mediatek,gce-client-reg
-  - mediatek,gce-events
   - power-domains
   - clocks
   - iommus
-  - mboxes
   - '#dma-cells'
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: mediatek,mt8183-mdp3-rdma
+
+    then:
+      properties:
+        clocks:
+          minItems: 2
+
+        mboxes:
+          minItems: 2
+
+      required:
+        - mboxes
+        - mediatek,gce-events
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: mediatek,mt8195-vdo1-rdma
+
+    then:
+      properties:
+        clocks:
+          maxItems: 1
+
 additionalProperties: false
 
 examples:
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:50 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:50 +0800
Subject: [PATCH v10 13/16] dt-bindings: display: mediatek: merge: add compatible for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-14-moudy.ho@mediatek.com>

Add a compatible string for the MERGE block in MediaTek MT8195 that
is controlled by MDP3.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../devicetree/bindings/display/mediatek/mediatek,merge.yaml     | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
index 5c678695162e..dae839279950 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
@@ -24,6 +24,7 @@ properties:
       - enum:
           - mediatek,mt8173-disp-merge
           - mediatek,mt8195-disp-merge
+          - mediatek,mt8195-mdp3-merge
       - items:
           - const: mediatek,mt6795-disp-merge
           - const: mediatek,mt8173-disp-merge
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:46 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:46 +0800
Subject: [PATCH v10 09/16] dt-bindings: media: mediatek: mdp3: add component TCC for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-10-moudy.ho@mediatek.com>

Add the fundamental hardware configuration of component TCC,
which is controlled by MDP3 on MT8195.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../bindings/media/mediatek,mdp3-tcc.yaml     | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
new file mode 100644
index 000000000000..14ea556d4f82
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-tcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 Tone Curve Conversion
+
+maintainers:
+  - Matthias Brugger <matthias.bgg at gmail.com>
+
+description:
+  Tone Curve Conversion (TCC) is one of Media Profile Path 3 (MDP3) components.
+  It is used to handle the tone mapping of various gamma curves in order to
+  achieve HDR10 effects. This helps adapt the content to the color and
+  brightness range that standard display devices typically support.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt8195-mdp3-tcc
+
+  reg:
+    maxItems: 1
+
+  mediatek,gce-client-reg:
+    description:
+      The register of display function block to be set by gce. There are 4 arguments,
+      such as gce node, subsys id, offset and register size. The subsys id that is
+      mapping to the register of display function blocks is defined in the gce header
+      include/dt-bindings/gce/<chip>-gce.h of each chips.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      items:
+        - description: phandle of GCE
+        - description: GCE subsys id
+        - description: register offset
+        - description: register size
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - mediatek,gce-client-reg
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8195-clk.h>
+    #include <dt-bindings/gce/mt8195-gce.h>
+
+    display at 1400b000 {
+        compatible = "mediatek,mt8195-mdp3-tcc";
+        reg = <0x1400b000 0x1000>;
+        mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0xb000 0x1000>;
+        clocks = <&vppsys0 CLK_VPP0_MDP_TCC>;
+    };
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:47 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:47 +0800
Subject: [PATCH v10 10/16] dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-11-moudy.ho@mediatek.com>

Add the fundamental hardware configuration of component TDSHP,
which is controlled by MDP3 on MT8195.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../bindings/media/mediatek,mdp3-tdshp.yaml   | 61 +++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
new file mode 100644
index 000000000000..8ab7f2d8e148
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-tdshp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 Two-Dimensional Sharpness
+
+maintainers:
+  - Matthias Brugger <matthias.bgg at gmail.com>
+  - Moudy Ho <moudy.ho at mediatek.com>
+
+description:
+  Two-Dimensional Sharpness (TDSHP) is a Media Profile Path 3 (MDP3) component
+  used to perform image edge sharpening and enhance vividness and contrast.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt8195-mdp3-tdshp
+
+  reg:
+    maxItems: 1
+
+  mediatek,gce-client-reg:
+    description:
+      The register of display function block to be set by gce. There are 4 arguments,
+      such as gce node, subsys id, offset and register size. The subsys id that is
+      mapping to the register of display function blocks is defined in the gce header
+      include/dt-bindings/gce/<chip>-gce.h of each chips.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      items:
+        - description: phandle of GCE
+        - description: GCE subsys id
+        - description: register offset
+        - description: register size
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - mediatek,gce-client-reg
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8195-clk.h>
+    #include <dt-bindings/gce/mt8195-gce.h>
+
+    display at 14007000 {
+        compatible = "mediatek,mt8195-mdp3-tdshp";
+        reg = <0x14007000 0x1000>;
+        mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x7000 0x1000>;
+        clocks = <&vppsys0 CLK_VPP0_MDP_TDSHP>;
+    };
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:52 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:52 +0800
Subject: [PATCH v10 15/16] dt-bindings: display: mediatek: split: add compatible for MT8195
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-16-moudy.ho@mediatek.com>

Add compatible string and GCE property for MT8195 SPLIT, of
which is operated by MDP3.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../display/mediatek/mediatek,split.yaml      | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
index a8a5c9608598..e4affc854f3d 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
@@ -23,6 +23,7 @@ properties:
     oneOf:
       - enum:
           - mediatek,mt8173-disp-split
+          - mediatek,mt8195-mdp3-split
       - items:
           - const: mediatek,mt6795-disp-split
           - const: mediatek,mt8173-disp-split
@@ -38,6 +39,21 @@ properties:
       the power controller specified by phandle. See
       Documentation/devicetree/bindings/power/power-domain.yaml for details.
 
+  mediatek,gce-client-reg:
+    description:
+      The register of display function block to be set by gce. There are 4 arguments,
+      such as gce node, subsys id, offset and register size. The subsys id that is
+      mapping to the register of display function blocks is defined in the gce header
+      include/dt-bindings/gce/<chip>-gce.h of each chips.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      items:
+        - description: phandle of GCE
+        - description: GCE subsys id
+        - description: register offset
+        - description: register size
+    maxItems: 1
+
   clocks:
     items:
       - description: SPLIT Clock
@@ -48,6 +64,17 @@ required:
   - power-domains
   - clocks
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: mediatek,mt8195-mdp3-split
+
+    then:
+      required:
+        - mediatek,gce-client-reg
+
 additionalProperties: false
 
 examples:
-- 
2.18.0



From ryan.roberts at arm.com  Wed Dec 20 02:11:16 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 10:11:16 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
Message-ID: <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>

On 20/12/2023 09:54, David Hildenbrand wrote:
> On 20.12.23 10:51, Ryan Roberts wrote:
>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>
>>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>> range in the first place.
>>>>>>>>
>>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>> performant) as the previous implementation.
>>>>>>>>
>>>>>>>> This change addresses the core-mm refactoring only and a separate change
>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>
>>>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>
>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>>> tight loop in a process with 1G of populated memory and the time for the
>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>>>> positive is slower, compared to baseline upon which the series is based:
>>>>>>>>
>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>
>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>
>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>> ---
>>>>>>>> ???? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>>>> ???? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>>>>>> ???? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>> ???? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>> ???? #endif
>>>>>>>> ???? +#ifndef pte_batch_remaining
>>>>>>>> +/**
>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>> + * @addr: Address of the first page.
>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>> + *
>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of
>>>>>>>> ptes.
>>>>>>>> + * In such cases, this function returns the remaining number of pages to
>>>>>>>> the end
>>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>>> iterating
>>>>>>>> + * over ptes.
>>>>>>>> + *
>>>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>>>> + */
>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long
>>>>>>>> addr,
>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>> +{
>>>>>>>> +??? return 1;
>>>>>>>> +}
>>>>>>>> +#endif
>>>>>>>
>>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>>
>>>>>>> Was there no way to have some basic batching mechanism that doesn't require
>>>>>>> arch
>>>>>>> specifics?
>>>>>>
>>>>>> I tried a bunch of things but ultimately the way I've done it was the only
>>>>>> way
>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>
>>>>>> My original v3 posting was costing 5% extra and even my first attempt at an
>>>>>> arch-specific version that didn't resolve to a compile-time constant 1 still
>>>>>> cost an extra 3%.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>
>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>> * Check that PFN is consecutive
>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>
>>>>>> I haven't tried this exact approach, but I'd be surprised if I can get the
>>>>>> regression under 4% with this. Further along the series I spent a lot of time
>>>>>> having to fiddle with the arm64 implementation; every conditional and every
>>>>>> memory read (even when in cache) was a problem. There is just so little in
>>>>>> the
>>>>>> inner loop that every instruction matters. (At least on Ampere Altra and
>>>>>> Apple
>>>>>> M2).
>>>>>>
>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the benefit to
>>>>>> order-9 is around 10% in my measurements. Personally though, I'd prefer to
>>>>>> play
>>>>>> safe and ensure the common order-0 case doesn't regress, as you previously
>>>>>> suggested.
>>>>>>
>>>>>
>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>> series. I
>>>>> implemented very generic and simple batching for large folios (all PTE bits
>>>>> except the PFN have to match).
>>>>>
>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R) Silver
>>>>> 4210R CPU.
>>>>>
>>>>> order-0: 0.014210 -> 0.013969
>>>>>
>>>>> -> Around 1.7 % faster
>>>>>
>>>>> order-9: 0.014373 -> 0.009149
>>>>>
>>>>> -> Around 36.3 % faster
>>>>
>>>> Well I guess that shows me :)
>>>>
>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>
>>>
>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>
>> I've just been trying to compile and noticed this. Will take a look at your
>> update.
>>
>> But upon review, I've noticed the part that I think makes this difficult for
>> arm64 with the contpte optimization; You are calling ptep_get() for every pte in
>> the batch. While this is functionally correct, once arm64 has the contpte
>> changes, its ptep_get() has to read every pte in the contpte block in order to
>> gather the access and dirty bits. So if your batching function ends up wealking
>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>> performance. That's why I added the arch-specific pte_batch_remaining()
>> function; this allows the core-mm to skip to the end of the contpte block and
>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s instead
>> of 256.
>>
>> I considered making a ptep_get_noyoungdirty() variant, which would avoid the bit
>> gathering. But we have a similar problem in zap_pte_range() and that function
>> needs the dirty bit to update the folio. So it doesn't work there. (see patch 3
>> in my series).
>>
>> I guess you are going to say that we should combine both approaches, so that
>> your batching loop can skip forward an arch-provided number of ptes? That would
>> certainly work, but feels like an orthogonal change to what I'm trying to
>> achieve :). Anyway, I'll spend some time playing with it today.
> 
> You can overwrite the function or add special-casing internally, yes.
> 
> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()" and it
> doesn't do any of that besides preparing for some arm64 work.
> 

Well it allows an arch to opt-in to batching. But I see your point.

How do you want to handle your patches? Do you want to clean them up and I'll
base my stuff on top? Or do you want me to take them and sort it all out?

As I see it at the moment, I would keep your folio_pte_batch() always core, but
in subsequent patch, have it use pte_batch_remaining() (the arch function I have
in my series, which defaults to one). Then do a similar thing to what you have
done for fork in zap_pte_range() - also using folio_pte_batch(). Then lay my
series on top.



From david at redhat.com  Wed Dec 20 02:16:46 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 11:16:46 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
Message-ID: <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>

On 20.12.23 11:11, Ryan Roberts wrote:
> On 20/12/2023 09:54, David Hildenbrand wrote:
>> On 20.12.23 10:51, Ryan Roberts wrote:
>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>
>>>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>> range in the first place.
>>>>>>>>>
>>>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>
>>>>>>>>> This change addresses the core-mm refactoring only and a separate change
>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>
>>>>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>
>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>>>> tight loop in a process with 1G of populated memory and the time for the
>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>>>>> positive is slower, compared to baseline upon which the series is based:
>>>>>>>>>
>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>
>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>
>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>> ---
>>>>>>>>>  ???? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>>>>>  ???? mm/memory.c???????????? | 92 ++++++++++++++++++++++++++---------------
>>>>>>>>>  ???? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>  ???? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>  ???? #endif
>>>>>>>>>  ???? +#ifndef pte_batch_remaining
>>>>>>>>> +/**
>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch boundary.
>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>> + *
>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous batch of
>>>>>>>>> ptes.
>>>>>>>>> + * In such cases, this function returns the remaining number of pages to
>>>>>>>>> the end
>>>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>>>> iterating
>>>>>>>>> + * over ptes.
>>>>>>>>> + *
>>>>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>>>>> + */
>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long
>>>>>>>>> addr,
>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>> +{
>>>>>>>>> +??? return 1;
>>>>>>>>> +}
>>>>>>>>> +#endif
>>>>>>>>
>>>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>>>
>>>>>>>> Was there no way to have some basic batching mechanism that doesn't require
>>>>>>>> arch
>>>>>>>> specifics?
>>>>>>>
>>>>>>> I tried a bunch of things but ultimately the way I've done it was the only
>>>>>>> way
>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>
>>>>>>> My original v3 posting was costing 5% extra and even my first attempt at an
>>>>>>> arch-specific version that didn't resolve to a compile-time constant 1 still
>>>>>>> cost an extra 3%.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>
>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>> * Check that PFN is consecutive
>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>
>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can get the
>>>>>>> regression under 4% with this. Further along the series I spent a lot of time
>>>>>>> having to fiddle with the arm64 implementation; every conditional and every
>>>>>>> memory read (even when in cache) was a problem. There is just so little in
>>>>>>> the
>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra and
>>>>>>> Apple
>>>>>>> M2).
>>>>>>>
>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the benefit to
>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd prefer to
>>>>>>> play
>>>>>>> safe and ensure the common order-0 case doesn't regress, as you previously
>>>>>>> suggested.
>>>>>>>
>>>>>>
>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>> series. I
>>>>>> implemented very generic and simple batching for large folios (all PTE bits
>>>>>> except the PFN have to match).
>>>>>>
>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R) Silver
>>>>>> 4210R CPU.
>>>>>>
>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>
>>>>>> -> Around 1.7 % faster
>>>>>>
>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>
>>>>>> -> Around 36.3 % faster
>>>>>
>>>>> Well I guess that shows me :)
>>>>>
>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>
>>>>
>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>
>>> I've just been trying to compile and noticed this. Will take a look at your
>>> update.
>>>
>>> But upon review, I've noticed the part that I think makes this difficult for
>>> arm64 with the contpte optimization; You are calling ptep_get() for every pte in
>>> the batch. While this is functionally correct, once arm64 has the contpte
>>> changes, its ptep_get() has to read every pte in the contpte block in order to
>>> gather the access and dirty bits. So if your batching function ends up wealking
>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>> function; this allows the core-mm to skip to the end of the contpte block and
>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s instead
>>> of 256.
>>>
>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid the bit
>>> gathering. But we have a similar problem in zap_pte_range() and that function
>>> needs the dirty bit to update the folio. So it doesn't work there. (see patch 3
>>> in my series).
>>>
>>> I guess you are going to say that we should combine both approaches, so that
>>> your batching loop can skip forward an arch-provided number of ptes? That would
>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>> achieve :). Anyway, I'll spend some time playing with it today.
>>
>> You can overwrite the function or add special-casing internally, yes.
>>
>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()" and it
>> doesn't do any of that besides preparing for some arm64 work.
>>
> 
> Well it allows an arch to opt-in to batching. But I see your point.
> 
> How do you want to handle your patches? Do you want to clean them up and I'll
> base my stuff on top? Or do you want me to take them and sort it all out?

Whatever you prefer, it was mostly a quick prototype to see if we can 
achieve decent performance.

I can fixup the arch thingies (most should be easy, some might require a 
custom pte_next_pfn()) and you can focus on getting cont-pte sorted out 
on top [I assume that's what you want to work on :) ].

> 
> As I see it at the moment, I would keep your folio_pte_batch() always core, but
> in subsequent patch, have it use pte_batch_remaining() (the arch function I have
> in my series, which defaults to one). 

Just double-checking, how would it use pte_batch_remaining() ?

> Then do a similar thing to what you have
> done for fork in zap_pte_range() - also using folio_pte_batch(). Then lay my
> series on top.

Yes, we should probably try to handle the zapping part similarly: make 
it benefit all archs first, then special-case on cont-pte. I can help 
there as well.

-- 
Cheers,

David / dhildenb



From moudy.ho at mediatek.com  Wed Dec 20 02:18:37 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:37 +0800
Subject: [PATCH v9 11/12] media: platform: mtk-mdp3: add mt8195 MDP3 component settings
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-12-moudy.ho@mediatek.com>

Extend the component settings used in MT8195 MDP3.
Additionally, it is crucial to read all component settings in
a specific manner to ensure that shared memory data structure lengths
are aligned across different platforms.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mtk-mdp3-cmdq.c    |  57 ++
 .../platform/mediatek/mdp3/mtk-mdp3-comp.c    | 798 +++++++++++++++++-
 2 files changed, 851 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index f0c5f5abeb23..8114c288da9c 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -40,6 +40,10 @@ static bool is_output_disabled(int p_id, const struct img_compparam *param, u32
 		num = CFG_COMP(MT8183, param, num_subfrms);
 		dis_output = CFG_COMP(MT8183, param, frame.output_disable);
 		dis_tile = CFG_COMP(MT8183, param, frame.output_disable);
+	} else if (CFG_CHECK(MT8195, p_id)) {
+		num = CFG_COMP(MT8195, param, num_subfrms);
+		dis_output = CFG_COMP(MT8195, param, frame.output_disable);
+		dis_tile = CFG_COMP(MT8195, param, frame.output_disable);
 	}
 
 	return (count < num) ? (dis_output || dis_tile) : true;
@@ -101,6 +105,8 @@ static int mdp_path_subfrm_require(const struct mdp_path *path,
 
 	if (CFG_CHECK(MT8183, p_id))
 		num_comp = CFG_GET(MT8183, path->config, num_components);
+	else if (CFG_CHECK(MT8195, p_id))
+		num_comp = CFG_GET(MT8195, path->config, num_components);
 
 	/* Decide which mutex to use based on the current pipeline */
 	index = __get_pipe(path->mdp_dev, path->comps[0].comp->public_id);
@@ -115,6 +121,9 @@ static int mdp_path_subfrm_require(const struct mdp_path *path,
 
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 
@@ -156,12 +165,17 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
 
 	if (CFG_CHECK(MT8183, p_id))
 		num_comp = CFG_GET(MT8183, path->config, num_components);
+	else if (CFG_CHECK(MT8195, p_id))
+		num_comp = CFG_GET(MT8195, path->config, num_components);
 
 	/* Wait WROT SRAM shared to DISP RDMA */
 	/* Clear SOF event for each engine */
 	for (index = 0; index < num_comp; index++) {
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 		ctx = &path->comps[index];
@@ -180,6 +194,9 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
 	for (index = 0; index < num_comp; index++) {
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 		ctx = &path->comps[index];
@@ -202,6 +219,8 @@ static int mdp_path_ctx_init(struct mdp_dev *mdp, struct mdp_path *path)
 
 	if (CFG_CHECK(MT8183, p_id))
 		num_comp = CFG_GET(MT8183, path->config, num_components);
+	else if (CFG_CHECK(MT8195, p_id))
+		num_comp = CFG_GET(MT8195, path->config, num_components);
 
 	if (num_comp < 1)
 		return -EINVAL;
@@ -211,10 +230,15 @@ static int mdp_path_ctx_init(struct mdp_dev *mdp, struct mdp_path *path)
 
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 		if (CFG_CHECK(MT8183, p_id))
 			param = (void *)CFG_ADDR(MT8183, path->config, components[index]);
+		else if (CFG_CHECK(MT8195, p_id))
+			param = (void *)CFG_ADDR(MT8195, path->config, components[index]);
 		ret = mdp_comp_ctx_config(mdp, &path->comps[index],
 					  param, path->param);
 		if (ret)
@@ -238,9 +262,13 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 
 	if (CFG_CHECK(MT8183, p_id))
 		num_comp = CFG_GET(MT8183, path->config, num_components);
+	else if (CFG_CHECK(MT8195, p_id))
+		num_comp = CFG_GET(MT8195, path->config, num_components);
 
 	if (CFG_CHECK(MT8183, p_id))
 		ctrl = CFG_ADDR(MT8183, path->config, ctrls[count]);
+	else if (CFG_CHECK(MT8195, p_id))
+		ctrl = CFG_ADDR(MT8195, path->config, ctrls[count]);
 
 	/* Acquire components */
 	ret = mdp_path_subfrm_require(path, cmd, &pipe, count);
@@ -256,6 +284,9 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 	for (index = (num_comp - 1); index >= 0; index--) {
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 		ctx = &path->comps[index];
@@ -273,6 +304,9 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 	for (index = 0; index < num_comp; index++) {
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 		ctx = &path->comps[index];
@@ -286,6 +320,9 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 	for (index = 0; index < num_comp; index++) {
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 		ctx = &path->comps[index];
@@ -315,15 +352,22 @@ static int mdp_path_config(struct mdp_dev *mdp, struct mdp_cmdq_cmd *cmd,
 
 	if (CFG_CHECK(MT8183, p_id))
 		num_comp = CFG_GET(MT8183, path->config, num_components);
+	else if (CFG_CHECK(MT8195, p_id))
+		num_comp = CFG_GET(MT8195, path->config, num_components);
 
 	if (CFG_CHECK(MT8183, p_id))
 		num_sub = CFG_GET(MT8183, path->config, num_subfrms);
+	else if (CFG_CHECK(MT8195, p_id))
+		num_sub = CFG_GET(MT8195, path->config, num_subfrms);
 
 	/* Config path frame */
 	/* Reset components */
 	for (index = 0; index < num_comp; index++) {
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 		ctx = &path->comps[index];
@@ -339,11 +383,16 @@ static int mdp_path_config(struct mdp_dev *mdp, struct mdp_cmdq_cmd *cmd,
 		ctx = &path->comps[index];
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 
 		if (CFG_CHECK(MT8183, p_id))
 			out = CFG_COMP(MT8183, ctx->param, outputs[0]);
+		else if (CFG_CHECK(MT8195, p_id))
+			out = CFG_COMP(MT8195, ctx->param, outputs[0]);
 
 		compose = path->composes[out];
 		ret = call_op(ctx, config_frame, cmd, compose);
@@ -361,6 +410,9 @@ static int mdp_path_config(struct mdp_dev *mdp, struct mdp_cmdq_cmd *cmd,
 	for (index = 0; index < num_comp; index++) {
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[index].type);
+
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
 		ctx = &path->comps[index];
@@ -515,6 +567,8 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 
 	if (CFG_CHECK(MT8183, p_id)) {
 		num_comp = CFG_GET(MT8183, param->config, num_components);
+	} else if (CFG_CHECK(MT8195, p_id)) {
+		num_comp = CFG_GET(MT8195, param->config, num_components);
 	} else {
 		ret = -EINVAL;
 		goto err_destroy_pkt;
@@ -570,6 +624,9 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[i].type);
+		else if (CFG_CHECK(MT8195, p_id))
+			inner_id = CFG_GET(MT8195, path->config, components[i].type);
+
 		if (mdp_cfg_comp_is_dummy(mdp, inner_id))
 			continue;
 		memcpy(&comps[i], path->comps[i].comp,
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
index 600fec7d2f7f..8f62fb167156 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
@@ -13,11 +13,19 @@
 #include "mtk-mdp3-core.h"
 #include "mtk-mdp3-regs.h"
 
-#include "mdp_reg_rdma.h"
+#include "mdp_reg_aal.h"
 #include "mdp_reg_ccorr.h"
+#include "mdp_reg_color.h"
+#include "mdp_reg_fg.h"
+#include "mdp_reg_hdr.h"
+#include "mdp_reg_merge.h"
+#include "mdp_reg_ovl.h"
+#include "mdp_reg_pad.h"
+#include "mdp_reg_rdma.h"
 #include "mdp_reg_rsz.h"
-#include "mdp_reg_wrot.h"
+#include "mdp_reg_tdshp.h"
 #include "mdp_reg_wdma.h"
+#include "mdp_reg_wrot.h"
 
 static u32 mdp_comp_alias_id[MDP_COMP_TYPE_COUNT];
 static int p_id;
@@ -85,6 +93,7 @@ static int config_rdma_frame(struct mdp_comp_ctx *ctx,
 	bool en_ufo = MDP_COLOR_IS_UFP(colorformat);
 	phys_addr_t base = ctx->comp->reg_base;
 	u8 subsys_id = ctx->comp->subsys_id;
+	u32 rdma_con_mask = 0;
 	u32 reg = 0;
 
 	if (mdp_cfg && mdp_cfg->rdma_support_10bit) {
@@ -105,6 +114,8 @@ static int config_rdma_frame(struct mdp_comp_ctx *ctx,
 	/* Setup source frame info */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.src_ctrl);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.src_ctrl);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_CON, reg,
 		     0x03C8FE0F);
 
@@ -113,69 +124,163 @@ static int config_rdma_frame(struct mdp_comp_ctx *ctx,
 			/* Setup source buffer base */
 			if (CFG_CHECK(MT8183, p_id))
 				reg = CFG_COMP(MT8183, ctx->param, rdma.ufo_dec_y);
+			else if (CFG_CHECK(MT8195, p_id))
+				reg = CFG_COMP(MT8195, ctx->param, rdma.ufo_dec_y);
 			MM_REG_WRITE(cmd, subsys_id,
 				     base, MDP_RDMA_UFO_DEC_LENGTH_BASE_Y,
 				     reg, 0xFFFFFFFF);
+
 			if (CFG_CHECK(MT8183, p_id))
 				reg = CFG_COMP(MT8183, ctx->param, rdma.ufo_dec_c);
+			else if (CFG_CHECK(MT8195, p_id))
+				reg = CFG_COMP(MT8195, ctx->param, rdma.ufo_dec_c);
 			MM_REG_WRITE(cmd, subsys_id,
 				     base, MDP_RDMA_UFO_DEC_LENGTH_BASE_C,
 				     reg, 0xFFFFFFFF);
+
 			/* Set 10bit source frame pitch */
 			if (block10bit) {
 				if (CFG_CHECK(MT8183, p_id))
 					reg = CFG_COMP(MT8183, ctx->param, rdma.mf_bkgd_in_pxl);
+				else if (CFG_CHECK(MT8195, p_id))
+					reg = CFG_COMP(MT8195, ctx->param, rdma.mf_bkgd_in_pxl);
 				MM_REG_WRITE(cmd, subsys_id,
 					     base, MDP_RDMA_MF_BKGD_SIZE_IN_PXL,
 					     reg, 0x001FFFFF);
 			}
 		}
 
-	if (CFG_CHECK(MT8183, p_id))
+	if (CFG_CHECK(MT8183, p_id)) {
 		reg = CFG_COMP(MT8183, ctx->param, rdma.control);
+		rdma_con_mask = 0x1110;
+	} else if (CFG_CHECK(MT8195, p_id)) {
+		reg = CFG_COMP(MT8195, ctx->param, rdma.control);
+		rdma_con_mask = 0x1130;
+	}
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_CON, reg,
-		     0x1110);
+		     rdma_con_mask);
+
 	/* Setup source buffer base */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.iova[0]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.iova[0]);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_BASE_0, reg,
 		     0xFFFFFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.iova[1]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.iova[1]);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_BASE_1, reg,
 		     0xFFFFFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.iova[2]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.iova[2]);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_BASE_2, reg,
 		     0xFFFFFFFF);
+
 	/* Setup source buffer end */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.iova_end[0]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.iova_end[0]);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_END_0,
 		     reg, 0xFFFFFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.iova_end[1]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.iova_end[1]);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_END_1,
 		     reg, 0xFFFFFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.iova_end[2]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.iova_end[2]);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_END_2,
 		     reg, 0xFFFFFFFF);
+
 	/* Setup source frame pitch */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.mf_bkgd);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.mf_bkgd);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_MF_BKGD_SIZE_IN_BYTE,
 		     reg, 0x001FFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.sf_bkgd);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.sf_bkgd);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SF_BKGD_SIZE_IN_BYTE,
 		     reg, 0x001FFFFF);
+
 	/* Setup color transform */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.transform);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.transform);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_TRANSFORM_0,
 		     reg, 0x0F110000);
 
+	if (!mdp_cfg || !mdp_cfg->rdma_esl_setting)
+		goto rdma_config_done;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.dmabuf_con0);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_DMABUF_CON_0,
+		     reg, 0x0FFF00FF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.ultra_th_high_con0);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_ULTRA_TH_HIGH_CON_0,
+		     reg, 0x3FFFFFFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.ultra_th_low_con0);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_ULTRA_TH_LOW_CON_0,
+		     reg, 0x3FFFFFFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.dmabuf_con1);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_DMABUF_CON_1,
+		     reg, 0x0F7F007F);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.ultra_th_high_con1);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_ULTRA_TH_HIGH_CON_1,
+		     reg, 0x3FFFFFFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.ultra_th_low_con1);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_ULTRA_TH_LOW_CON_1,
+		     reg, 0x3FFFFFFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.dmabuf_con2);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_DMABUF_CON_2,
+		     reg, 0x0F3F003F);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.ultra_th_high_con2);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_ULTRA_TH_HIGH_CON_2,
+		     reg, 0x3FFFFFFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.ultra_th_low_con2);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_ULTRA_TH_LOW_CON_2,
+		     reg, 0x3FFFFFFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.dmabuf_con3);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_DMABUF_CON_3,
+		     reg, 0x0F3F003F);
+
+rdma_config_done:
 	return 0;
 }
 
@@ -197,6 +302,8 @@ static int config_rdma_subfrm(struct mdp_comp_ctx *ctx,
 	/* Set Y pixel offset */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.subfrms[index].offset[0]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.subfrms[index].offset[0]);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_OFFSET_0,
 		     reg, 0xFFFFFFFF);
 
@@ -205,6 +312,8 @@ static int config_rdma_subfrm(struct mdp_comp_ctx *ctx,
 		if (mdp_cfg->rdma_support_10bit && block10bit && en_ufo) {
 			if (CFG_CHECK(MT8183, p_id))
 				reg = CFG_COMP(MT8183, ctx->param, rdma.subfrms[index].offset_0_p);
+			else if (CFG_CHECK(MT8195, p_id))
+				reg = CFG_COMP(MT8195, ctx->param, rdma.subfrms[index].offset_0_p);
 			MM_REG_WRITE(cmd, subsys_id, base,
 				     MDP_RDMA_SRC_OFFSET_0_P,
 				     reg, 0xFFFFFFFF);
@@ -214,32 +323,49 @@ static int config_rdma_subfrm(struct mdp_comp_ctx *ctx,
 	/* Set U pixel offset */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.subfrms[index].offset[1]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.subfrms[index].offset[1]);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_OFFSET_1,
 		     reg, 0xFFFFFFFF);
+
 	/* Set V pixel offset */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.subfrms[index].offset[2]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.subfrms[index].offset[2]);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_SRC_OFFSET_2,
 		     reg, 0xFFFFFFFF);
+
 	/* Set source size */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.subfrms[index].src);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.subfrms[index].src);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_MF_SRC_SIZE, reg,
 		     0x1FFF1FFF);
+
 	/* Set target size */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.subfrms[index].clip);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.subfrms[index].clip);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_MF_CLIP_SIZE,
 		     reg, 0x1FFF1FFF);
+
 	/* Set crop offset */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rdma.subfrms[index].clip_ofst);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rdma.subfrms[index].clip_ofst);
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_MF_OFFSET_1,
 		     reg, 0x003F001F);
 
 	if (CFG_CHECK(MT8183, p_id)) {
 		csf_l = CFG_COMP(MT8183, ctx->param, subfrms[index].in.left);
 		csf_r = CFG_COMP(MT8183, ctx->param, subfrms[index].in.right);
+	} else if (CFG_CHECK(MT8195, p_id)) {
+		csf_l = CFG_COMP(MT8195, ctx->param, subfrms[index].in.left);
+		csf_r = CFG_COMP(MT8195, ctx->param, subfrms[index].in.right);
 	}
 	if (mdp_cfg && mdp_cfg->rdma_upsample_repeat_only)
 		if ((csf_r - csf_l + 1) > 320)
@@ -289,6 +415,14 @@ static int init_rsz(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_ENABLE, 0x0, BIT(16));
 	/* Enable RSZ */
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_ENABLE, BIT(0), BIT(0));
+
+	if (CFG_CHECK(MT8195, p_id)) {
+		struct device *dev;
+
+		dev = ctx->comp->mdp_dev->mm_subsys[MDP_MM_SUBSYS_1].mmsys;
+		mtk_mmsys_vpp_rsz_dcm_config(dev, true, NULL);
+	}
+
 	return 0;
 }
 
@@ -296,13 +430,19 @@ static int config_rsz_frame(struct mdp_comp_ctx *ctx,
 			    struct mdp_cmdq_cmd *cmd,
 			    const struct v4l2_rect *compose)
 {
+	const struct mdp_platform_config *mdp_cfg = __get_plat_cfg(ctx);
 	phys_addr_t base = ctx->comp->reg_base;
 	u8 subsys_id = ctx->comp->subsys_id;
 	bool bypass = FALSE;
 	u32 reg = 0;
 
+	if (mdp_cfg && mdp_cfg->rsz_etc_control)
+		MM_REG_WRITE(cmd, subsys_id, base, RSZ_ETC_CONTROL, 0x0, 0xFFFFFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		bypass = CFG_COMP(MT8183, ctx->param, frame.bypass);
+	else if (CFG_CHECK(MT8195, p_id))
+		bypass = CFG_COMP(MT8195, ctx->param, frame.bypass);
 
 	if (bypass) {
 		/* Disable RSZ */
@@ -312,20 +452,32 @@ static int config_rsz_frame(struct mdp_comp_ctx *ctx,
 
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rsz.control1);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rsz.control1);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_CONTROL_1, reg,
 		     0x03FFFDF3);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rsz.control2);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rsz.control2);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_CONTROL_2, reg,
 		     0x0FFFC290);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rsz.coeff_step_x);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rsz.coeff_step_x);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_HORIZONTAL_COEFF_STEP,
 		     reg, 0x007FFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rsz.coeff_step_y);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rsz.coeff_step_y);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_VERTICAL_COEFF_STEP,
 		     reg, 0x007FFFFF);
+
 	return 0;
 }
 
@@ -337,19 +489,28 @@ static int config_rsz_subfrm(struct mdp_comp_ctx *ctx,
 	u8 subsys_id = ctx->comp->subsys_id;
 	u32 csf_l = 0, csf_r = 0;
 	u32 reg = 0;
+	u32 id;
 
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rsz.subfrms[index].control2);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rsz.subfrms[index].control2);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_CONTROL_2, reg,
 		     0x00003800);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rsz.subfrms[index].src);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rsz.subfrms[index].src);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_INPUT_IMAGE, reg,
 		     0xFFFFFFFF);
 
 	if (CFG_CHECK(MT8183, p_id)) {
 		csf_l = CFG_COMP(MT8183, ctx->param, subfrms[index].in.left);
 		csf_r = CFG_COMP(MT8183, ctx->param, subfrms[index].in.right);
+	} else if (CFG_CHECK(MT8195, p_id)) {
+		csf_l = CFG_COMP(MT8195, ctx->param, subfrms[index].in.left);
+		csf_r = CFG_COMP(MT8195, ctx->param, subfrms[index].in.right);
 	}
 	if (mdp_cfg && mdp_cfg->rsz_disable_dcm_small_sample)
 		if ((csf_r - csf_l + 1) <= 16)
@@ -358,37 +519,99 @@ static int config_rsz_subfrm(struct mdp_comp_ctx *ctx,
 
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, subfrms[index].luma.left);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, subfrms[index].luma.left);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_LUMA_HORIZONTAL_INTEGER_OFFSET,
 		     reg, 0xFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, subfrms[index].luma.left_subpix);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, subfrms[index].luma.left_subpix);
 	MM_REG_WRITE(cmd, subsys_id,
 		     base, PRZ_LUMA_HORIZONTAL_SUBPIXEL_OFFSET,
 		     reg, 0x1FFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, subfrms[index].luma.top);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, subfrms[index].luma.top);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_LUMA_VERTICAL_INTEGER_OFFSET,
 		     reg, 0xFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, subfrms[index].luma.top_subpix);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, subfrms[index].luma.top_subpix);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_LUMA_VERTICAL_SUBPIXEL_OFFSET,
 		     reg, 0x1FFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, subfrms[index].chroma.left);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, subfrms[index].chroma.left);
 	MM_REG_WRITE(cmd, subsys_id,
 		     base, PRZ_CHROMA_HORIZONTAL_INTEGER_OFFSET,
 		     reg, 0xFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, subfrms[index].chroma.left_subpix);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, subfrms[index].chroma.left_subpix);
 	MM_REG_WRITE(cmd, subsys_id,
 		     base, PRZ_CHROMA_HORIZONTAL_SUBPIXEL_OFFSET,
 		     reg, 0x1FFFFF);
 
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, rsz.subfrms[index].clip);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, rsz.subfrms[index].clip);
 	MM_REG_WRITE(cmd, subsys_id, base, PRZ_OUTPUT_IMAGE, reg,
 		     0xFFFFFFFF);
 
+	if (CFG_CHECK(MT8195, p_id)) {
+		struct device *dev;
+		struct mdp_comp *merge;
+		const struct mtk_mdp_driver_data *data = ctx->comp->mdp_dev->mdp_data;
+		enum mtk_mdp_comp_id public_id = ctx->comp->public_id;
+
+		switch (public_id) {
+		case MDP_COMP_RSZ2:
+			merge = ctx->comp->mdp_dev->comp[MDP_COMP_MERGE2];
+			break;
+		case MDP_COMP_RSZ3:
+			merge = ctx->comp->mdp_dev->comp[MDP_COMP_MERGE3];
+			break;
+		default:
+			goto rsz_subfrm_done;
+		}
+
+		if (CFG_CHECK(MT8195, p_id))
+			reg = CFG_COMP(MT8195, ctx->param, rsz.subfrms[index].rsz_switch);
+
+		id = data->comp_data[public_id].match.alias_id;
+		dev = ctx->comp->mdp_dev->mm_subsys[MDP_MM_SUBSYS_1].mmsys;
+		mtk_mmsys_vpp_rsz_merge_config(dev, id, reg, NULL);
+
+		if (CFG_CHECK(MT8195, p_id))
+			reg = CFG_COMP(MT8195, ctx->param, rsz.subfrms[index].merge_cfg);
+		MM_REG_WRITE(cmd, merge->subsys_id, merge->reg_base,
+			     MDP_MERGE_CFG_0, reg, 0xFFFFFFFF);
+		MM_REG_WRITE(cmd, merge->subsys_id, merge->reg_base,
+			     MDP_MERGE_CFG_4, reg, 0xFFFFFFFF);
+		MM_REG_WRITE(cmd, merge->subsys_id, merge->reg_base,
+			     MDP_MERGE_CFG_24, reg, 0xFFFFFFFF);
+		MM_REG_WRITE(cmd, merge->subsys_id, merge->reg_base,
+			     MDP_MERGE_CFG_25, reg, 0xFFFFFFFF);
+
+		/* Bypass mode */
+		MM_REG_WRITE(cmd, merge->subsys_id, merge->reg_base,
+			     MDP_MERGE_CFG_12, BIT(0), 0xFFFFFFFF);
+		MM_REG_WRITE(cmd, merge->subsys_id, merge->reg_base,
+			     MDP_MERGE_ENABLE, BIT(0), 0xFFFFFFFF);
+	}
+
+rsz_subfrm_done:
 	return 0;
 }
 
@@ -405,6 +628,9 @@ static int advance_rsz_subfrm(struct mdp_comp_ctx *ctx,
 		if (CFG_CHECK(MT8183, p_id)) {
 			csf_l = CFG_COMP(MT8183, ctx->param, subfrms[index].in.left);
 			csf_r = CFG_COMP(MT8183, ctx->param, subfrms[index].in.right);
+		} else if (CFG_CHECK(MT8195, p_id)) {
+			csf_l = CFG_COMP(MT8195, ctx->param, subfrms[index].in.left);
+			csf_r = CFG_COMP(MT8195, ctx->param, subfrms[index].in.right);
 		}
 
 		if ((csf_r - csf_l + 1) <= 16)
@@ -431,6 +657,11 @@ static int init_wrot(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
 	/* Reset WROT */
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_SOFT_RST, BIT(0), BIT(0));
 	MM_REG_POLL(cmd, subsys_id, base, VIDO_SOFT_RST_STAT, BIT(0), BIT(0));
+
+	/* Reset setting */
+	if (CFG_CHECK(MT8195, p_id))
+		MM_REG_WRITE(cmd, subsys_id, base, VIDO_CTRL, 0x0, 0xFFFFFFFF);
+
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_SOFT_RST, 0x0, BIT(0));
 	MM_REG_POLL(cmd, subsys_id, base, VIDO_SOFT_RST_STAT, 0x0, BIT(0));
 	return 0;
@@ -448,57 +679,118 @@ static int config_wrot_frame(struct mdp_comp_ctx *ctx,
 	/* Write frame base address */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.iova[0]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.iova[0]);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_BASE_ADDR, reg,
 		     0xFFFFFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.iova[1]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.iova[1]);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_BASE_ADDR_C, reg,
 		     0xFFFFFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.iova[2]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.iova[2]);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_BASE_ADDR_V, reg,
 		     0xFFFFFFFF);
+
+	if (mdp_cfg && mdp_cfg->wrot_support_10bit) {
+		if (CFG_CHECK(MT8195, p_id))
+			reg = CFG_COMP(MT8195, ctx->param, wrot.scan_10bit);
+		MM_REG_WRITE(cmd, subsys_id, base, VIDO_SCAN_10BIT,
+			     reg, 0x0000000F);
+
+		if (CFG_CHECK(MT8195, p_id))
+			reg = CFG_COMP(MT8195, ctx->param, wrot.pending_zero);
+		MM_REG_WRITE(cmd, subsys_id, base, VIDO_PENDING_ZERO,
+			     reg, 0x04000000);
+	}
+
+	if (CFG_CHECK(MT8195, p_id)) {
+		reg = CFG_COMP(MT8195, ctx->param, wrot.bit_number);
+		MM_REG_WRITE(cmd, subsys_id, base, VIDO_CTRL_2,
+			     reg, 0x00000007);
+	}
+
 	/* Write frame related registers */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.control);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.control);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_CTRL, reg,
 		     0xF131510F);
+
+	/* Write pre-ultra threshold */
+	if (CFG_CHECK(MT8195, p_id)) {
+		reg = CFG_COMP(MT8195, ctx->param, wrot.pre_ultra);
+		MM_REG_WRITE(cmd, subsys_id, base, VIDO_DMA_PREULTRA, reg,
+			     0x00FFFFFF);
+	}
+
 	/* Write frame Y pitch */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.stride[0]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.stride[0]);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_STRIDE, reg,
 		     0x0000FFFF);
+
 	/* Write frame UV pitch */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.stride[1]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.stride[1]);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_STRIDE_C, reg,
 		     0xFFFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.stride[2]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.stride[2]);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_STRIDE_V, reg,
 		     0xFFFF);
+
 	/* Write matrix control */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.mat_ctrl);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.mat_ctrl);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_MAT_CTRL, reg, 0xF3);
 
 	/* Set the fixed ALPHA as 0xFF */
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_DITHER, 0xFF000000,
 		     0xFF000000);
+
 	/* Set VIDO_EOL_SEL */
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_RSV_1, BIT(31), BIT(31));
+
 	/* Set VIDO_FIFO_TEST */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.fifo_test);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.fifo_test);
+
 	if (reg != 0)
 		MM_REG_WRITE(cmd, subsys_id, base, VIDO_FIFO_TEST,
 			     reg, 0xFFF);
+
 	/* Filter enable */
 	if (mdp_cfg && mdp_cfg->wrot_filter_constraint) {
 		if (CFG_CHECK(MT8183, p_id))
 			reg = CFG_COMP(MT8183, ctx->param, wrot.filter);
+		else if (CFG_CHECK(MT8195, p_id))
+			reg = CFG_COMP(MT8195, ctx->param, wrot.filter);
 		MM_REG_WRITE(cmd, subsys_id, base, VIDO_MAIN_BUF_SIZE,
 			     reg, 0x77);
+
+		/* Turn off WROT DMA DCM */
+		if (CFG_CHECK(MT8195, p_id))
+			MM_REG_WRITE(cmd, subsys_id, base, VIDO_ROT_EN,
+				     (0x1 << 23) + (0x1 << 20), 0x900000);
 	}
 
 	return 0;
@@ -514,35 +806,54 @@ static int config_wrot_subfrm(struct mdp_comp_ctx *ctx,
 	/* Write Y pixel offset */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.subfrms[index].offset[0]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.subfrms[index].offset[0]);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_OFST_ADDR,
 		     reg, 0x0FFFFFFF);
+
 	/* Write U pixel offset */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.subfrms[index].offset[1]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.subfrms[index].offset[1]);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_OFST_ADDR_C,
 		     reg, 0x0FFFFFFF);
+
 	/* Write V pixel offset */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.subfrms[index].offset[2]);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.subfrms[index].offset[2]);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_OFST_ADDR_V,
 		     reg, 0x0FFFFFFF);
+
 	/* Write source size */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.subfrms[index].src);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.subfrms[index].src);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_IN_SIZE, reg,
 		     0x1FFF1FFF);
+
 	/* Write target size */
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.subfrms[index].clip);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.subfrms[index].clip);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_TAR_SIZE, reg,
 		     0x1FFF1FFF);
+
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.subfrms[index].clip_ofst);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.subfrms[index].clip_ofst);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_CROP_OFST, reg,
 		     0x1FFF1FFF);
 
 	if (CFG_CHECK(MT8183, p_id))
 		reg = CFG_COMP(MT8183, ctx->param, wrot.subfrms[index].main_buf);
+	else if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, wrot.subfrms[index].main_buf);
 	MM_REG_WRITE(cmd, subsys_id, base, VIDO_MAIN_BUF_SIZE,
 		     reg, 0x1FFF7F00);
 
@@ -708,6 +1019,171 @@ static const struct mdp_comp_ops wdma_ops = {
 	.wait_comp_event = wait_wdma_event,
 };
 
+static int reset_luma_hist(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
+{
+	const struct mdp_platform_config *mdp_cfg = __get_plat_cfg(ctx);
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 hist_num, i;
+
+	if (!mdp_cfg)
+		return -EINVAL;
+
+	hist_num = mdp_cfg->tdshp_hist_num;
+
+	/* Reset histogram */
+	for (i = 0; i <= hist_num; i++)
+		MM_REG_WRITE_MASK(cmd, subsys_id, base,
+				  (MDP_LUMA_HIST_INIT + (i << 2)),
+				  0, 0xFFFFFFFF);
+
+	if (mdp_cfg->tdshp_constrain)
+		MM_REG_WRITE(cmd, subsys_id, base,
+			     MDP_DC_TWO_D_W1_RESULT_INIT, 0, 0xFFFFFFFF);
+
+	if (mdp_cfg->tdshp_contour)
+		for (i = 0; i < hist_num; i++)
+			MM_REG_WRITE_MASK(cmd, subsys_id, base,
+					  (MDP_CONTOUR_HIST_INIT + (i << 2)),
+					  0, 0xFFFFFFFF);
+
+	return 0;
+}
+
+static int init_tdshp(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_TDSHP_CTRL, BIT(0), BIT(0));
+	/* Enable FIFO */
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_TDSHP_CFG, BIT(1), BIT(1));
+
+	return reset_luma_hist(ctx, cmd);
+}
+
+static int config_tdshp_frame(struct mdp_comp_ctx *ctx,
+			      struct mdp_cmdq_cmd *cmd,
+			      const struct v4l2_rect *compose)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, tdshp.cfg);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_TDSHP_CFG, reg, BIT(0));
+
+	return 0;
+}
+
+static int config_tdshp_subfrm(struct mdp_comp_ctx *ctx,
+			       struct mdp_cmdq_cmd *cmd, u32 index)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, tdshp.subfrms[index].src);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_TDSHP_INPUT_SIZE,
+		     reg, MDP_TDSHP_INPUT_SIZE_MASK);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, tdshp.subfrms[index].clip_ofst);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_TDSHP_OUTPUT_OFFSET,
+		     reg, 0x00FF00FF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, tdshp.subfrms[index].clip);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_TDSHP_OUTPUT_SIZE,
+		     reg, MDP_TDSHP_OUTPUT_SIZE_MASK);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, tdshp.subfrms[index].hist_cfg_0);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HIST_CFG_00, reg, 0xFFFFFFFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, tdshp.subfrms[index].hist_cfg_1);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HIST_CFG_01, reg, 0xFFFFFFFF);
+
+	return 0;
+}
+
+static const struct mdp_comp_ops tdshp_ops = {
+	.get_comp_flag = get_comp_flag,
+	.init_comp = init_tdshp,
+	.config_frame = config_tdshp_frame,
+	.config_subfrm = config_tdshp_subfrm,
+};
+
+static int init_color(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+
+	MM_REG_WRITE(cmd, subsys_id, base,
+		     MDP_COLOR_START, 0x1, BIT(1) | BIT(0));
+	MM_REG_WRITE(cmd, subsys_id, base,
+		     MDP_COLOR_WIN_X_MAIN, 0xFFFF0000, 0xFFFFFFFF);
+	MM_REG_WRITE(cmd, subsys_id, base,
+		     MDP_COLOR_WIN_Y_MAIN, 0xFFFF0000, 0xFFFFFFFF);
+
+	/* Reset color matrix */
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_COLOR_CM1_EN, 0x0, BIT(0));
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_COLOR_CM2_EN, 0x0, BIT(0));
+
+	/* Enable interrupt */
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_COLOR_INTEN, 0x7, 0x7);
+
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_COLOR_OUT_SEL, 0x333, 0x333);
+
+	return 0;
+}
+
+static int config_color_frame(struct mdp_comp_ctx *ctx,
+			      struct mdp_cmdq_cmd *cmd,
+			      const struct v4l2_rect *compose)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, color.start);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_COLOR_START,
+		     reg, MDP_COLOR_START_MASK);
+
+	return 0;
+}
+
+static int config_color_subfrm(struct mdp_comp_ctx *ctx,
+			       struct mdp_cmdq_cmd *cmd, u32 index)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, color.subfrms[index].in_hsize);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_COLOR_INTERNAL_IP_WIDTH,
+		     reg, 0x00003FFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, color.subfrms[index].in_vsize);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_COLOR_INTERNAL_IP_HEIGHT,
+		     reg, 0x00003FFF);
+
+	return 0;
+}
+
+static const struct mdp_comp_ops color_ops = {
+	.get_comp_flag = get_comp_flag,
+	.init_comp = init_color,
+	.config_frame = config_color_frame,
+	.config_subfrm = config_color_subfrm,
+};
+
 static int init_ccorr(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
 {
 	phys_addr_t base = ctx->comp->reg_base;
@@ -749,12 +1225,318 @@ static const struct mdp_comp_ops ccorr_ops = {
 	.config_subfrm = config_ccorr_subfrm,
 };
 
+static int init_aal(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+
+	/* Always set MDP_AAL enable to 1 */
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_AAL_EN, BIT(0), BIT(0));
+
+	return 0;
+}
+
+static int config_aal_frame(struct mdp_comp_ctx *ctx,
+			    struct mdp_cmdq_cmd *cmd,
+			    const struct v4l2_rect *compose)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, aal.cfg_main);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_AAL_CFG_MAIN, reg, BIT(7));
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, aal.cfg);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_AAL_CFG, reg, BIT(0));
+
+	return 0;
+}
+
+static int config_aal_subfrm(struct mdp_comp_ctx *ctx,
+			     struct mdp_cmdq_cmd *cmd, u32 index)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, aal.subfrms[index].src);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_AAL_SIZE,
+		     reg, MDP_AAL_SIZE_MASK);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, aal.subfrms[index].clip_ofst);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_AAL_OUTPUT_OFFSET,
+		     reg, 0x00FF00FF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, aal.subfrms[index].clip);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_AAL_OUTPUT_SIZE,
+		     reg, MDP_AAL_OUTPUT_SIZE_MASK);
+
+	return 0;
+}
+
+static const struct mdp_comp_ops aal_ops = {
+	.get_comp_flag = get_comp_flag,
+	.init_comp = init_aal,
+	.config_frame = config_aal_frame,
+	.config_subfrm = config_aal_subfrm,
+};
+
+static int init_hdr(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+
+	/* Always set MDP_HDR enable to 1 */
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_TOP, BIT(0), BIT(0));
+
+	return 0;
+}
+
+static int config_hdr_frame(struct mdp_comp_ctx *ctx,
+			    struct mdp_cmdq_cmd *cmd,
+			    const struct v4l2_rect *compose)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.top);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_TOP, reg, BIT(29) | BIT(28));
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.relay);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_RELAY, reg, BIT(0));
+
+	return 0;
+}
+
+static int config_hdr_subfrm(struct mdp_comp_ctx *ctx,
+			     struct mdp_cmdq_cmd *cmd, u32 index)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.subfrms[index].win_size);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_TILE_POS,
+		     reg, MDP_HDR_TILE_POS_MASK);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.subfrms[index].src);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_SIZE_0, reg, 0x1FFF1FFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.subfrms[index].clip_ofst0);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_SIZE_1, reg, 0x1FFF1FFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.subfrms[index].clip_ofst1);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_SIZE_2, reg, 0x1FFF1FFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.subfrms[index].hist_ctrl_0);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_HIST_CTRL_0, reg, 0x00003FFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.subfrms[index].hist_ctrl_1);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_HIST_CTRL_1, reg, 0x00003FFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.subfrms[index].hdr_top);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_TOP, reg, BIT(6) | BIT(5));
+
+	/* Enable histogram */
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, hdr.subfrms[index].hist_addr);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_HDR_HIST_ADDR, reg, BIT(9));
+
+	return 0;
+}
+
+static const struct mdp_comp_ops hdr_ops = {
+	.get_comp_flag = get_comp_flag,
+	.init_comp = init_hdr,
+	.config_frame = config_hdr_frame,
+	.config_subfrm = config_hdr_subfrm,
+};
+
+static int init_fg(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_FG_TRIGGER, BIT(2), BIT(2));
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_FG_TRIGGER, 0x0, BIT(2));
+
+	return 0;
+}
+
+static int config_fg_frame(struct mdp_comp_ctx *ctx,
+			   struct mdp_cmdq_cmd *cmd,
+			   const struct v4l2_rect *compose)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, fg.ctrl_0);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_FG_FG_CTRL_0, reg, BIT(0));
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, fg.ck_en);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_FG_FG_CK_EN, reg, 0x7);
+
+	return 0;
+}
+
+static int config_fg_subfrm(struct mdp_comp_ctx *ctx,
+			    struct mdp_cmdq_cmd *cmd, u32 index)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, fg.subfrms[index].info_0);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_FG_TILE_INFO_0, reg, 0xFFFFFFFF);
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, fg.subfrms[index].info_1);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_FG_TILE_INFO_1, reg, 0xFFFFFFFF);
+
+	return 0;
+}
+
+static const struct mdp_comp_ops fg_ops = {
+	.get_comp_flag = get_comp_flag,
+	.init_comp = init_fg,
+	.config_frame = config_fg_frame,
+	.config_subfrm = config_fg_subfrm,
+};
+
+static int init_ovl(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_OVL_EN,
+		     BIT(0), MDP_OVL_EN_MASK);
+
+	/* Set to relay mode */
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_OVL_SRC_CON,
+		     BIT(9), MDP_OVL_SRC_CON_MASK);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_OVL_DP_CON,
+		     BIT(0), MDP_OVL_DP_CON_MASK);
+
+	return 0;
+}
+
+static int config_ovl_frame(struct mdp_comp_ctx *ctx,
+			    struct mdp_cmdq_cmd *cmd,
+			    const struct v4l2_rect *compose)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, ovl.L0_con);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_OVL_L0_CON, reg, BIT(29) | BIT(28));
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, ovl.src_con);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_OVL_SRC_CON, reg, BIT(0));
+
+	return 0;
+}
+
+static int config_ovl_subfrm(struct mdp_comp_ctx *ctx,
+			     struct mdp_cmdq_cmd *cmd, u32 index)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, ovl.subfrms[index].L0_src_size);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_OVL_L0_SRC_SIZE,
+		     reg, MDP_OVL_L0_SRC_SIZE_MASK);
+
+	/* Setup output size */
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, ovl.subfrms[index].roi_size);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_OVL_ROI_SIZE,
+		     reg, MDP_OVL_ROI_SIZE_MASK);
+
+	return 0;
+}
+
+static const struct mdp_comp_ops ovl_ops = {
+	.get_comp_flag = get_comp_flag,
+	.init_comp = init_ovl,
+	.config_frame = config_ovl_frame,
+	.config_subfrm = config_ovl_subfrm,
+};
+
+static int init_pad(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_PAD_CON,
+		     BIT(1), MDP_PAD_CON_MASK);
+	/* Reset */
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_PAD_W_SIZE,
+		     0, MDP_PAD_W_SIZE_MASK);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_PAD_H_SIZE,
+		     0, MDP_PAD_H_SIZE_MASK);
+
+	return 0;
+}
+
+static int config_pad_subfrm(struct mdp_comp_ctx *ctx,
+			     struct mdp_cmdq_cmd *cmd, u32 index)
+{
+	phys_addr_t base = ctx->comp->reg_base;
+	u16 subsys_id = ctx->comp->subsys_id;
+	u32 reg = 0;
+
+	if (CFG_CHECK(MT8195, p_id))
+		reg = CFG_COMP(MT8195, ctx->param, pad.subfrms[index].pic_size);
+	MM_REG_WRITE(cmd, subsys_id, base, MDP_PAD_PIC_SIZE,
+		     reg, MDP_PAD_PIC_SIZE_MASK);
+
+	return 0;
+}
+
+static const struct mdp_comp_ops pad_ops = {
+	.get_comp_flag = get_comp_flag,
+	.init_comp = init_pad,
+	.config_subfrm = config_pad_subfrm,
+};
+
 static const struct mdp_comp_ops *mdp_comp_ops[MDP_COMP_TYPE_COUNT] = {
 	[MDP_COMP_TYPE_RDMA] =		&rdma_ops,
 	[MDP_COMP_TYPE_RSZ] =		&rsz_ops,
 	[MDP_COMP_TYPE_WROT] =		&wrot_ops,
 	[MDP_COMP_TYPE_WDMA] =		&wdma_ops,
+	[MDP_COMP_TYPE_TDSHP] =		&tdshp_ops,
+	[MDP_COMP_TYPE_COLOR] =		&color_ops,
 	[MDP_COMP_TYPE_CCORR] =		&ccorr_ops,
+	[MDP_COMP_TYPE_AAL] =		&aal_ops,
+	[MDP_COMP_TYPE_HDR] =		&hdr_ops,
+	[MDP_COMP_TYPE_FG] =		&fg_ops,
+	[MDP_COMP_TYPE_OVL] =		&ovl_ops,
+	[MDP_COMP_TYPE_PAD] =		&pad_ops,
 };
 
 static const struct of_device_id mdp_comp_dt_ids[] __maybe_unused = {
@@ -1253,6 +2035,8 @@ int mdp_comp_ctx_config(struct mdp_dev *mdp, struct mdp_comp_ctx *ctx,
 
 	if (CFG_CHECK(MT8183, p_id))
 		arg = CFG_COMP(MT8183, param, type);
+	else if (CFG_CHECK(MT8195, p_id))
+		arg = CFG_COMP(MT8195, param, type);
 	else
 		return -EINVAL;
 	public_id = mdp_cfg_get_id_public(mdp, arg);
@@ -1270,16 +2054,22 @@ int mdp_comp_ctx_config(struct mdp_dev *mdp, struct mdp_comp_ctx *ctx,
 	ctx->param = param;
 	if (CFG_CHECK(MT8183, p_id))
 		arg = CFG_COMP(MT8183, param, input);
+	else if (CFG_CHECK(MT8195, p_id))
+		arg = CFG_COMP(MT8195, param, input);
 	else
 		return -EINVAL;
 	ctx->input = &frame->inputs[arg];
 	if (CFG_CHECK(MT8183, p_id))
 		idx = CFG_COMP(MT8183, param, num_outputs);
+	else if (CFG_CHECK(MT8195, p_id))
+		idx = CFG_COMP(MT8195, param, num_outputs);
 	else
 		return -EINVAL;
 	for (i = 0; i < idx; i++) {
 		if (CFG_CHECK(MT8183, p_id))
 			arg = CFG_COMP(MT8183, param, outputs[i]);
+		else if (CFG_CHECK(MT8195, p_id))
+			arg = CFG_COMP(MT8195, param, outputs[i]);
 		else
 			return -EINVAL;
 		ctx->outputs[i] = &frame->outputs[arg];
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:33 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:33 +0800
Subject: [PATCH v9 07/12] media: platform: mtk-mdp3: extend GCE event waiting in RDMA and WROT
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-8-moudy.ho@mediatek.com>

Support for multiple RDMA/WROT waits for GCE events.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mdp_cfg_data.c     |  2 ++
 .../platform/mediatek/mdp3/mtk-mdp3-comp.c    | 27 +++++++++++++------
 .../platform/mediatek/mdp3/mtk-mdp3-core.h    |  2 ++
 3 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index 6f77c33074ec..3834efe54e17 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -56,8 +56,10 @@ static const struct mdp_platform_config mt8183_plat_cfg = {
 	.rdma_support_10bit		= true,
 	.rdma_rsz1_sram_sharing		= true,
 	.rdma_upsample_repeat_only	= true,
+	.rdma_event_num			= 1,
 	.rsz_disable_dcm_small_sample	= false,
 	.wrot_filter_constraint		= false,
+	.wrot_event_num			= 1,
 };
 
 static const u32 mt8183_mutex_idx[MDP_MAX_COMP_COUNT] = {
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
index 93df2e013438..ed6092e1666f 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
@@ -251,14 +251,20 @@ static int config_rdma_subfrm(struct mdp_comp_ctx *ctx,
 
 static int wait_rdma_event(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
 {
+	const struct mdp_platform_config *mdp_cfg = __get_plat_cfg(ctx);
 	struct device *dev = &ctx->comp->mdp_dev->pdev->dev;
 	phys_addr_t base = ctx->comp->reg_base;
 	u8 subsys_id = ctx->comp->subsys_id;
 
-	if (ctx->comp->alias_id == 0)
-		MM_REG_WAIT(cmd, ctx->comp->gce_event[MDP_GCE_EVENT_EOF]);
-	else
-		dev_err(dev, "Do not support RDMA1_DONE event\n");
+	if (!mdp_cfg)
+		return -EINVAL;
+
+	if (ctx->comp->alias_id >= mdp_cfg->rdma_event_num) {
+		dev_err(dev, "Invalid RDMA event %d\n", ctx->comp->alias_id);
+		return -EINVAL;
+	}
+
+	MM_REG_WAIT(cmd, ctx->comp->gce_event[MDP_GCE_EVENT_EOF]);
 
 	/* Disable RDMA */
 	MM_REG_WRITE(cmd, subsys_id, base, MDP_RDMA_EN, 0x0, BIT(0));
@@ -553,10 +559,15 @@ static int wait_wrot_event(struct mdp_comp_ctx *ctx, struct mdp_cmdq_cmd *cmd)
 	phys_addr_t base = ctx->comp->reg_base;
 	u8 subsys_id = ctx->comp->subsys_id;
 
-	if (ctx->comp->alias_id == 0)
-		MM_REG_WAIT(cmd, ctx->comp->gce_event[MDP_GCE_EVENT_EOF]);
-	else
-		dev_err(dev, "Do not support WROT1_DONE event\n");
+	if (!mdp_cfg)
+		return -EINVAL;
+
+	if (ctx->comp->alias_id >= mdp_cfg->wrot_event_num) {
+		dev_err(dev, "Invalid WROT event %d!\n", ctx->comp->alias_id);
+		return -EINVAL;
+	}
+
+	MM_REG_WAIT(cmd, ctx->comp->gce_event[MDP_GCE_EVENT_EOF]);
 
 	if (mdp_cfg && mdp_cfg->wrot_filter_constraint)
 		MM_REG_WRITE(cmd, subsys_id, base, VIDO_MAIN_BUF_SIZE, 0x0,
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
index 22d1b17ef2fc..e57c415a1c78 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
@@ -49,8 +49,10 @@ struct mdp_platform_config {
 	bool	rdma_support_10bit;
 	bool	rdma_rsz1_sram_sharing;
 	bool	rdma_upsample_repeat_only;
+	u32	rdma_event_num;
 	bool	rsz_disable_dcm_small_sample;
 	bool	wrot_filter_constraint;
+	u32	wrot_event_num;
 };
 
 /* indicate which mutex is used by each pipepline */
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:31 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:31 +0800
Subject: [PATCH v9 05/12] media: platform: mtk-mdp3: add checks for dummy components
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-6-moudy.ho@mediatek.com>

Some components act as bridges only and do not require full configuration.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mdp_cfg_data.c     |  8 +++
 .../platform/mediatek/mdp3/mtk-mdp3-cfg.h     |  1 +
 .../platform/mediatek/mdp3/mtk-mdp3-cmdq.c    | 58 ++++++++++++++++++-
 .../platform/mediatek/mdp3/mtk-mdp3-comp.c    |  9 ++-
 4 files changed, 74 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index fcc582292b77..fe92c0474bfa 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -451,3 +451,11 @@ enum mtk_mdp_comp_id mdp_cfg_get_id_public(struct mdp_dev *mdp_dev, s32 inner_id
 err_public_id:
 	return public_id;
 }
+
+bool mdp_cfg_comp_is_dummy(struct mdp_dev *mdp_dev, s32 inner_id)
+{
+	enum mtk_mdp_comp_id id = mdp_cfg_get_id_public(mdp_dev, inner_id);
+	enum mdp_comp_type type = mdp_dev->mdp_data->comp_data[id].match.type;
+
+	return (type == MDP_COMP_TYPE_DUMMY);
+}
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
index dee57cc4a954..dfffc72868e4 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
@@ -16,5 +16,6 @@ enum mtk_mdp_comp_id;
 
 s32 mdp_cfg_get_id_inner(struct mdp_dev *mdp_dev, enum mtk_mdp_comp_id id);
 enum mtk_mdp_comp_id mdp_cfg_get_id_public(struct mdp_dev *mdp_dev, s32 id);
+bool mdp_cfg_comp_is_dummy(struct mdp_dev *mdp_dev, s32 inner_id);
 
 #endif  /* __MTK_MDP3_CFG_H__ */
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 31930ddbc828..a81caf5f472c 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -6,6 +6,7 @@
 
 #include <linux/mailbox_controller.h>
 #include <linux/platform_device.h>
+#include "mtk-mdp3-cfg.h"
 #include "mtk-mdp3-cmdq.h"
 #include "mtk-mdp3-comp.h"
 #include "mtk-mdp3-core.h"
@@ -108,6 +109,12 @@ static int mdp_path_subfrm_require(const struct mdp_path *path,
 
 	/* Set mutex mod */
 	for (index = 0; index < num_comp; index++) {
+		s32 inner_id = MDP_COMP_NONE;
+
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
 		ctx = &path->comps[index];
 		if (is_output_disabled(p_id, ctx->param, count))
 			continue;
@@ -132,6 +139,7 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
 	int index;
 	u32 num_comp = 0;
 	s32 event;
+	s32 inner_id = MDP_COMP_NONE;
 
 	if (-1 == p->mutex_id) {
 		dev_err(dev, "Incorrect mutex id");
@@ -144,6 +152,10 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
 	/* Wait WROT SRAM shared to DISP RDMA */
 	/* Clear SOF event for each engine */
 	for (index = 0; index < num_comp; index++) {
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
 		ctx = &path->comps[index];
 		if (is_output_disabled(p_id, ctx->param, count))
 			continue;
@@ -158,6 +170,10 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
 
 	/* Wait SOF events and clear mutex modules (optional) */
 	for (index = 0; index < num_comp; index++) {
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
 		ctx = &path->comps[index];
 		if (is_output_disabled(p_id, ctx->param, count))
 			continue;
@@ -183,6 +199,12 @@ static int mdp_path_ctx_init(struct mdp_dev *mdp, struct mdp_path *path)
 		return -EINVAL;
 
 	for (index = 0; index < num_comp; index++) {
+		s32 inner_id = MDP_COMP_NONE;
+
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
 		if (CFG_CHECK(MT8183, p_id))
 			param = (void *)CFG_ADDR(MT8183, path->config, components[index]);
 		ret = mdp_comp_ctx_config(mdp, &path->comps[index],
@@ -204,6 +226,7 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 	struct mdp_pipe_info pipe;
 	int index, ret;
 	u32 num_comp = 0;
+	s32 inner_id = MDP_COMP_NONE;
 
 	if (CFG_CHECK(MT8183, p_id))
 		num_comp = CFG_GET(MT8183, path->config, num_components);
@@ -223,6 +246,10 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 	}
 	/* Config sub-frame information */
 	for (index = (num_comp - 1); index >= 0; index--) {
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
 		ctx = &path->comps[index];
 		if (is_output_disabled(p_id, ctx->param, count))
 			continue;
@@ -236,6 +263,10 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 		return ret;
 	/* Wait components done */
 	for (index = 0; index < num_comp; index++) {
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
 		ctx = &path->comps[index];
 		if (is_output_disabled(p_id, ctx->param, count))
 			continue;
@@ -245,6 +276,10 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 	}
 	/* Advance to the next sub-frame */
 	for (index = 0; index < num_comp; index++) {
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
 		ctx = &path->comps[index];
 		ret = call_op(ctx, advance_subfrm, cmd, count);
 		if (ret)
@@ -268,6 +303,7 @@ static int mdp_path_config(struct mdp_dev *mdp, struct mdp_cmdq_cmd *cmd,
 	int index, count, ret;
 	u32 num_comp = 0;
 	u32 num_sub = 0;
+	s32 inner_id = MDP_COMP_NONE;
 
 	if (CFG_CHECK(MT8183, p_id))
 		num_comp = CFG_GET(MT8183, path->config, num_components);
@@ -278,6 +314,10 @@ static int mdp_path_config(struct mdp_dev *mdp, struct mdp_cmdq_cmd *cmd,
 	/* Config path frame */
 	/* Reset components */
 	for (index = 0; index < num_comp; index++) {
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
 		ctx = &path->comps[index];
 		ret = call_op(ctx, init_comp, cmd);
 		if (ret)
@@ -289,6 +329,11 @@ static int mdp_path_config(struct mdp_dev *mdp, struct mdp_cmdq_cmd *cmd,
 		u32 out = 0;
 
 		ctx = &path->comps[index];
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
+
 		if (CFG_CHECK(MT8183, p_id))
 			out = CFG_COMP(MT8183, ctx->param, outputs[0]);
 
@@ -306,6 +351,10 @@ static int mdp_path_config(struct mdp_dev *mdp, struct mdp_cmdq_cmd *cmd,
 	}
 	/* Post processing information */
 	for (index = 0; index < num_comp; index++) {
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[index].type);
+		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
+			continue;
 		ctx = &path->comps[index];
 		ret = call_op(ctx, post_process, cmd);
 		if (ret)
@@ -508,9 +557,16 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 	}
 	cmdq_pkt_finalize(&cmd->pkt);
 
-	for (i = 0; i < num_comp; i++)
+	for (i = 0; i < num_comp; i++) {
+		s32 inner_id = MDP_COMP_NONE;
+
+		if (CFG_CHECK(MT8183, p_id))
+			inner_id = CFG_GET(MT8183, path->config, components[i].type);
+		if (mdp_cfg_comp_is_dummy(mdp, inner_id))
+			continue;
 		memcpy(&comps[i], path->comps[i].comp,
 		       sizeof(struct mdp_comp));
+	}
 
 	mdp->cmdq_clt->client.rx_callback = mdp_handle_cmdq_callback;
 	cmd->mdp = mdp;
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
index 575c8d52acd1..93df2e013438 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
@@ -853,6 +853,9 @@ int mdp_comp_clocks_on(struct device *dev, struct mdp_comp *comps, int num)
 	int i, ret;
 
 	for (i = 0; i < num; i++) {
+		/* Bypass the dummy component*/
+		if (!comps[i].mdp_dev)
+			continue;
 		ret = mdp_comp_clock_on(dev, &comps[i]);
 		if (ret)
 			return ret;
@@ -865,8 +868,12 @@ void mdp_comp_clocks_off(struct device *dev, struct mdp_comp *comps, int num)
 {
 	int i;
 
-	for (i = 0; i < num; i++)
+	for (i = 0; i < num; i++) {
+		/* Bypass the dummy component*/
+		if (!comps[i].mdp_dev)
+			continue;
 		mdp_comp_clock_off(dev, &comps[i]);
+	}
 }
 
 static int mdp_get_subsys_id(struct mdp_dev *mdp, struct device *dev,
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:26 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:26 +0800
Subject: [PATCH v9 00/12] add support MDP3 on MT8195 platform
Message-ID: <20231220101838.21510-1-moudy.ho@mediatek.com>

From: Moudy Ho <moudy.ho at mediatek.corp-partner.google.com>

Changes since v8:
- Rebase on linux-next.
- Dependent dtsi files:
  Message ID = 20231030094840.2479-1-moudy.ho at mediatek.com
- Dependent bindings:
  Message ID = 20231220100853.20616-1-moudy.ho at mediatek.com

Changes since v7:
- Rebase on linux-next.
- Dependent dtsi files:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=797543
- Dependent bindings:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=797555
- Patch [9/12] has made corresponding adjustments in response to the changes in
  the compatible name of the PAD component in DTSI and binding.
- Adding WROT compatible name in the MDP driver's of_match_table in [9/12] to
  avoid deactivating 'pm_runtime_*' functions.

Changes since v6:
- Rebase on v6.6-rc5.
- Dependent dtsi files:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=792079
- Dependent bindings:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=792477
- Move the patch that fixes compile warnings from this series and
  create a separate standalone patch.

Changes since v5:
- Rebase on v6.6-rc2.
- Dependent dtsi files:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=786511
- Dependent bindings:
  https://patchwork.kernel.org/project/linux-mediatek/list/?series=786520
- Integrate MMSY/MUTEX structure in "mdp_probe".
- Fix the build warnings that were detected by the linux-media
  build scripts tool.

Changes since v4:
- Rebase on v6.6-rc1
- Remove any unnecessary DTS settings.
- Adjust the usage of MOD and clock in blending components.

Changes since v3:
- Depend on :
  [1] https://patchwork.kernel.org/project/linux-media/list/?series=719841
- Suggested by Krzysztof, integrating all newly added bindings for
  the mt8195 MDP3 into the file "mediatek,mt8195-mdp3.yaml".
- Revise MDP3 nodes with generic names.

Changes since v2:
- Depend on :
  [1] MMSYS/MUTEX: https://patchwork.kernel.org/project/linux-mediatek/list/?series=711592
  [2] MDP3: https://patchwork.kernel.org/project/linux-mediatek/list/?series=711618
- Suggested by Rob to revise MDP3 bindings to pass dtbs check
- Add parallel paths feature.
- Add blended components settings.

Changes since v1:
- Depend on :
  [1] MDP3 : https://patchwork.kernel.org/project/linux-mediatek/list/?series=698872
  [2] MMSYS/MUTEX: https://patchwork.kernel.org/project/linux-mediatek/list/?series=684959
- Fix compilation failure due to use of undeclared identifier in file "mtk-mdp3-cmdq.c"

Hello,

This patch is used to add support for MDP3 on the MT8195 platform that
contains more picture quality components, and can arrange more pipelines
through two sets of MMSYS and MUTEX respectively.

Moudy Ho (12):
  media: platform: mtk-mdp3: add support second sets of MMSYS
  media: platform: mtk-mdp3: add support second sets of MUTEX
  media: platform: mtk-mdp3: introduce more pipelines from MT8195
  media: platform: mtk-mdp3: introduce more MDP3 components
  media: platform: mtk-mdp3: add checks for dummy components
  media: platform: mtk-mdp3: avoid multiple driver registrations
  media: platform: mtk-mdp3: extend GCE event waiting in RDMA and WROT
  media: platform: mtk-mdp3: add support for blending multiple
    components
  media: platform: mtk-mdp3: add mt8195 platform configuration
  media: platform: mtk-mdp3: add mt8195 shared memory configurations
  media: platform: mtk-mdp3: add mt8195 MDP3 component settings
  media: platform: mtk-mdp3: add support for parallel pipe to improve
    FPS

 .../platform/mediatek/mdp3/mdp_cfg_data.c     | 729 +++++++++++++-
 .../platform/mediatek/mdp3/mdp_reg_aal.h      |  25 +
 .../platform/mediatek/mdp3/mdp_reg_color.h    |  31 +
 .../media/platform/mediatek/mdp3/mdp_reg_fg.h |  23 +
 .../platform/mediatek/mdp3/mdp_reg_hdr.h      |  31 +
 .../platform/mediatek/mdp3/mdp_reg_merge.h    |  25 +
 .../platform/mediatek/mdp3/mdp_reg_ovl.h      |  25 +
 .../platform/mediatek/mdp3/mdp_reg_pad.h      |  21 +
 .../platform/mediatek/mdp3/mdp_reg_rdma.h     |  24 +
 .../platform/mediatek/mdp3/mdp_reg_rsz.h      |   2 +
 .../platform/mediatek/mdp3/mdp_reg_tdshp.h    |  34 +
 .../platform/mediatek/mdp3/mdp_reg_wrot.h     |   8 +
 .../platform/mediatek/mdp3/mdp_sm_mt8195.h    | 283 ++++++
 .../platform/mediatek/mdp3/mtk-img-ipi.h      |   4 +
 .../platform/mediatek/mdp3/mtk-mdp3-cfg.h     |   2 +
 .../platform/mediatek/mdp3/mtk-mdp3-cmdq.c    | 440 +++++++--
 .../platform/mediatek/mdp3/mtk-mdp3-cmdq.h    |   1 +
 .../platform/mediatek/mdp3/mtk-mdp3-comp.c    | 895 +++++++++++++++++-
 .../platform/mediatek/mdp3/mtk-mdp3-comp.h    |  93 +-
 .../platform/mediatek/mdp3/mtk-mdp3-core.c    | 142 ++-
 .../platform/mediatek/mdp3/mtk-mdp3-core.h    |  50 +-
 .../platform/mediatek/mdp3/mtk-mdp3-m2m.c     |  15 +
 .../platform/mediatek/mdp3/mtk-mdp3-regs.c    |  18 +
 .../platform/mediatek/mdp3/mtk-mdp3-regs.h    |   1 +
 .../platform/mediatek/mdp3/mtk-mdp3-vpu.c     |   3 +-
 25 files changed, 2747 insertions(+), 178 deletions(-)
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_color.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_hdr.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_merge.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_ovl.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_pad.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_tdshp.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h

-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:30 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:30 +0800
Subject: [PATCH v9 04/12] media: platform: mtk-mdp3: introduce more MDP3 components
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-5-moudy.ho@mediatek.com>

Add configuration of more components in MT8195 MDP3.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mdp_reg_aal.h      | 25 ++++++
 .../platform/mediatek/mdp3/mdp_reg_color.h    | 31 +++++++
 .../media/platform/mediatek/mdp3/mdp_reg_fg.h | 23 +++++
 .../platform/mediatek/mdp3/mdp_reg_hdr.h      | 31 +++++++
 .../platform/mediatek/mdp3/mdp_reg_merge.h    | 25 ++++++
 .../platform/mediatek/mdp3/mdp_reg_ovl.h      | 25 ++++++
 .../platform/mediatek/mdp3/mdp_reg_pad.h      | 21 +++++
 .../platform/mediatek/mdp3/mdp_reg_rdma.h     | 24 ++++++
 .../platform/mediatek/mdp3/mdp_reg_rsz.h      |  2 +
 .../platform/mediatek/mdp3/mdp_reg_tdshp.h    | 34 ++++++++
 .../platform/mediatek/mdp3/mdp_reg_wrot.h     |  8 ++
 .../platform/mediatek/mdp3/mtk-mdp3-comp.h    | 85 +++++++++++++++----
 12 files changed, 318 insertions(+), 16 deletions(-)
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_color.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_hdr.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_merge.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_ovl.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_pad.h
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_reg_tdshp.h

diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h
new file mode 100644
index 000000000000..4b9513e54543
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_aal.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Ping-Hsun Wu <ping-hsun.wu at mediatek.com>
+ */
+
+#ifndef __MDP_REG_AAL_H__
+#define __MDP_REG_AAL_H__
+
+#define MDP_AAL_EN			(0x000)
+#define MDP_AAL_CFG			(0x020)
+#define MDP_AAL_SIZE			(0x030)
+#define MDP_AAL_OUTPUT_SIZE		(0x034)
+#define MDP_AAL_OUTPUT_OFFSET		(0x038)
+#define MDP_AAL_CFG_MAIN		(0x200)
+
+/* MASK */
+#define MDP_AAL_EN_MASK			(0x01)
+#define MDP_AAL_CFG_MASK		(0x70FF00B3)
+#define MDP_AAL_SIZE_MASK		(0x1FFF1FFF)
+#define MDP_AAL_OUTPUT_SIZE_MASK	(0x1FFF1FFF)
+#define MDP_AAL_OUTPUT_OFFSET_MASK	(0x0FF00FF)
+#define MDP_AAL_CFG_MAIN_MASK		(0x0FE)
+
+#endif  // __MDP_REG_AAL_H__
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_color.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_color.h
new file mode 100644
index 000000000000..f72503975b24
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_color.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Ping-Hsun Wu <ping-hsun.wu at mediatek.com>
+ */
+
+#ifndef __MDP_REG_COLOR_H__
+#define __MDP_REG_COLOR_H__
+
+#define MDP_COLOR_WIN_X_MAIN			(0x40C)
+#define MDP_COLOR_WIN_Y_MAIN			(0x410)
+#define MDP_COLOR_START				(0xC00)
+#define MDP_COLOR_INTEN				(0xC04)
+#define MDP_COLOR_OUT_SEL			(0xC0C)
+#define MDP_COLOR_INTERNAL_IP_WIDTH		(0xC50)
+#define MDP_COLOR_INTERNAL_IP_HEIGHT		(0xC54)
+#define MDP_COLOR_CM1_EN			(0xC60)
+#define MDP_COLOR_CM2_EN			(0xCA0)
+
+/* MASK */
+#define MDP_COLOR_WIN_X_MAIN_MASK		(0xFFFFFFFF)
+#define MDP_COLOR_WIN_Y_MAIN_MASK		(0xFFFFFFFF)
+#define MDP_COLOR_START_MASK			(0x0FF013F)
+#define MDP_COLOR_INTEN_MASK			(0x07)
+#define MDP_COLOR_OUT_SEL_MASK			(0x0777)
+#define MDP_COLOR_INTERNAL_IP_WIDTH_MASK	(0x03FFF)
+#define MDP_COLOR_INTERNAL_IP_HEIGHT_MASK	(0x03FFF)
+#define MDP_COLOR_CM1_EN_MASK			(0x03)
+#define MDP_COLOR_CM2_EN_MASK			(0x017)
+
+#endif  // __MDP_REG_COLOR_H__
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h
new file mode 100644
index 000000000000..d90bcad33a59
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_fg.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Ping-Hsun Wu <ping-hsun.wu at mediatek.com>
+ */
+
+#ifndef __MDP_REG_FG_H__
+#define __MDP_REG_FG_H__
+
+#define MDP_FG_TRIGGER			(0x0)
+#define MDP_FG_FG_CTRL_0		(0x20)
+#define MDP_FG_FG_CK_EN			(0x24)
+#define MDP_FG_TILE_INFO_0		(0x418)
+#define MDP_FG_TILE_INFO_1		(0x41c)
+
+/* MASK */
+#define MDP_FG_TRIGGER_MASK		(0x00000007)
+#define MDP_FG_FG_CTRL_0_MASK		(0x00000033)
+#define MDP_FG_FG_CK_EN_MASK		(0x0000000F)
+#define MDP_FG_TILE_INFO_0_MASK		(0xFFFFFFFF)
+#define MDP_FG_TILE_INFO_1_MASK		(0xFFFFFFFF)
+
+#endif  //__MDP_REG_FG_H__
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_hdr.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_hdr.h
new file mode 100644
index 000000000000..c19fbba39fc0
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_hdr.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Ping-Hsun Wu <ping-hsun.wu at mediatek.com>
+ */
+
+#ifndef __MDP_REG_HDR_H__
+#define __MDP_REG_HDR_H__
+
+#define MDP_HDR_TOP			(0x000)
+#define MDP_HDR_RELAY			(0x004)
+#define MDP_HDR_SIZE_0			(0x014)
+#define MDP_HDR_SIZE_1			(0x018)
+#define MDP_HDR_SIZE_2			(0x01C)
+#define MDP_HDR_HIST_CTRL_0		(0x020)
+#define MDP_HDR_HIST_CTRL_1		(0x024)
+#define MDP_HDR_HIST_ADDR		(0x0DC)
+#define MDP_HDR_TILE_POS		(0x118)
+
+/* MASK */
+#define MDP_HDR_RELAY_MASK		(0x01)
+#define MDP_HDR_TOP_MASK		(0xFF0FEB6D)
+#define MDP_HDR_SIZE_0_MASK		(0x1FFF1FFF)
+#define MDP_HDR_SIZE_1_MASK		(0x1FFF1FFF)
+#define MDP_HDR_SIZE_2_MASK		(0x1FFF1FFF)
+#define MDP_HDR_HIST_CTRL_0_MASK	(0x1FFF1FFF)
+#define MDP_HDR_HIST_CTRL_1_MASK	(0x1FFF1FFF)
+#define MDP_HDR_HIST_ADDR_MASK		(0xBF3F2F3F)
+#define MDP_HDR_TILE_POS_MASK		(0x1FFF1FFF)
+
+#endif // __MDP_REG_HDR_H__
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_merge.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_merge.h
new file mode 100644
index 000000000000..46be27e2a656
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_merge.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Ping-Hsun Wu <ping-hsun.wu at mediatek.com>
+ */
+
+#ifndef __MDP_REG_MERGE_H__
+#define __MDP_REG_MERGE_H__
+
+#define MDP_MERGE_ENABLE	(0x000)
+#define MDP_MERGE_CFG_0		(0x010)
+#define MDP_MERGE_CFG_4		(0x020)
+#define MDP_MERGE_CFG_12	(0x040)
+#define MDP_MERGE_CFG_24	(0x070)
+#define MDP_MERGE_CFG_25	(0x074)
+
+/* MASK */
+#define MDP_MERGE_ENABLE_MASK	(0xFFFFFFFF)
+#define MDP_MERGE_CFG_0_MASK	(0xFFFFFFFF)
+#define MDP_MERGE_CFG_4_MASK	(0xFFFFFFFF)
+#define MDP_MERGE_CFG_12_MASK	(0xFFFFFFFF)
+#define MDP_MERGE_CFG_24_MASK	(0xFFFFFFFF)
+#define MDP_MERGE_CFG_25_MASK	(0xFFFFFFFF)
+
+#endif //__MDP_REG_MERGE_H__
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_ovl.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_ovl.h
new file mode 100644
index 000000000000..21d2d0323293
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_ovl.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Ping-Hsun Wu <ping-hsun.wu at mediatek.com>
+ */
+
+#ifndef __MDP_REG_OVL_H__
+#define __MDP_REG_OVL_H__
+
+#define MDP_OVL_EN			(0x00c)
+#define MDP_OVL_ROI_SIZE		(0x020)
+#define MDP_OVL_DP_CON			(0x024)
+#define MDP_OVL_SRC_CON			(0x02c)
+#define MDP_OVL_L0_CON			(0x030)
+#define MDP_OVL_L0_SRC_SIZE		(0x038)
+
+/* MASK */
+#define MDP_OVL_DP_CON_MASK		(0x0FFFFFFF)
+#define MDP_OVL_EN_MASK			(0xB07D07B1)
+#define MDP_OVL_L0_CON_MASK		(0xFFFFFFFF)
+#define MDP_OVL_L0_SRC_SIZE_MASK	(0x1FFF1FFF)
+#define MDP_OVL_ROI_SIZE_MASK		(0x1FFF1FFF)
+#define MDP_OVL_SRC_CON_MASK		(0x0000031F)
+
+#endif  //__MDP_REG_OVL_H__
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_pad.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_pad.h
new file mode 100644
index 000000000000..0e89f1db19ed
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_pad.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Ping-Hsun Wu <ping-hsun.wu at mediatek.com>
+ */
+
+#ifndef __MDP_REG_PAD_H__
+#define __MDP_REG_PAD_H__
+
+#define MDP_PAD_CON			(0x000)
+#define MDP_PAD_PIC_SIZE		(0x004)
+#define MDP_PAD_W_SIZE			(0x008)
+#define MDP_PAD_H_SIZE			(0x00c)
+
+/* MASK */
+#define MDP_PAD_CON_MASK		(0x00000007)
+#define MDP_PAD_PIC_SIZE_MASK		(0xFFFFFFFF)
+#define MDP_PAD_W_SIZE_MASK		(0x1FFF1FFF)
+#define MDP_PAD_H_SIZE_MASK		(0x1FFF1FFF)
+
+#endif  // __MDP_REG_PAD_H__
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_rdma.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_rdma.h
index be4065e252d3..0affb2a3b958 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_reg_rdma.h
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_rdma.h
@@ -26,6 +26,18 @@
 #define MDP_RDMA_SRC_OFFSET_2           0x128
 #define MDP_RDMA_SRC_OFFSET_0_P         0x148
 #define MDP_RDMA_TRANSFORM_0            0x200
+#define MDP_RDMA_DMABUF_CON_0           0x240
+#define MDP_RDMA_ULTRA_TH_HIGH_CON_0    0x248
+#define MDP_RDMA_ULTRA_TH_LOW_CON_0     0x250
+#define MDP_RDMA_DMABUF_CON_1           0x258
+#define MDP_RDMA_ULTRA_TH_HIGH_CON_1    0x260
+#define MDP_RDMA_ULTRA_TH_LOW_CON_1     0x268
+#define MDP_RDMA_DMABUF_CON_2           0x270
+#define MDP_RDMA_ULTRA_TH_HIGH_CON_2    0x278
+#define MDP_RDMA_ULTRA_TH_LOW_CON_2     0x280
+#define MDP_RDMA_DMABUF_CON_3           0x288
+#define MDP_RDMA_ULTRA_TH_HIGH_CON_3    0x290
+#define MDP_RDMA_ULTRA_TH_LOW_CON_3     0x298
 #define MDP_RDMA_RESV_DUMMY_0           0x2a0
 #define MDP_RDMA_MON_STA_1              0x408
 #define MDP_RDMA_SRC_BASE_0             0xf00
@@ -54,6 +66,18 @@
 #define MDP_RDMA_SRC_OFFSET_2_MASK          0xffffffff
 #define MDP_RDMA_SRC_OFFSET_0_P_MASK        0xffffffff
 #define MDP_RDMA_TRANSFORM_0_MASK           0xff110777
+#define MDP_RDMA_DMABUF_CON_0_MASK          0x0fff00ff
+#define MDP_RDMA_ULTRA_TH_HIGH_CON_0_MASK   0x3fffffff
+#define MDP_RDMA_ULTRA_TH_LOW_CON_0_MASK    0x3fffffff
+#define MDP_RDMA_DMABUF_CON_1_MASK          0x0f7f007f
+#define MDP_RDMA_ULTRA_TH_HIGH_CON_1_MASK   0x3fffffff
+#define MDP_RDMA_ULTRA_TH_LOW_CON_1_MASK    0x3fffffff
+#define MDP_RDMA_DMABUF_CON_2_MASK          0x0f3f003f
+#define MDP_RDMA_ULTRA_TH_HIGH_CON_2_MASK   0x3fffffff
+#define MDP_RDMA_ULTRA_TH_LOW_CON_2_MASK    0x3fffffff
+#define MDP_RDMA_DMABUF_CON_3_MASK          0x0f3f003f
+#define MDP_RDMA_ULTRA_TH_HIGH_CON_3_MASK   0x3fffffff
+#define MDP_RDMA_ULTRA_TH_LOW_CON_3_MASK    0x3fffffff
 #define MDP_RDMA_RESV_DUMMY_0_MASK          0xffffffff
 #define MDP_RDMA_MON_STA_1_MASK             0xffffffff
 #define MDP_RDMA_SRC_BASE_0_MASK            0xffffffff
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_rsz.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_rsz.h
index 484f6d60641f..187531db8e3b 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_reg_rsz.h
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_rsz.h
@@ -20,6 +20,7 @@
 #define PRZ_LUMA_VERTICAL_SUBPIXEL_OFFSET                 0x02c
 #define PRZ_CHROMA_HORIZONTAL_INTEGER_OFFSET              0x030
 #define PRZ_CHROMA_HORIZONTAL_SUBPIXEL_OFFSET             0x034
+#define RSZ_ETC_CONTROL                                   0x22c
 
 /* MASK */
 #define PRZ_ENABLE_MASK                                   0x00010001
@@ -35,5 +36,6 @@
 #define PRZ_LUMA_VERTICAL_SUBPIXEL_OFFSET_MASK            0x001fffff
 #define PRZ_CHROMA_HORIZONTAL_INTEGER_OFFSET_MASK         0x0000ffff
 #define PRZ_CHROMA_HORIZONTAL_SUBPIXEL_OFFSET_MASK        0x001fffff
+#define RSZ_ETC_CONTROL_MASK                              0xff770000
 
 #endif // __MDP_REG_RSZ_H__
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_tdshp.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_tdshp.h
new file mode 100644
index 000000000000..83b5f9b432d8
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_tdshp.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Ping-Hsun Wu <ping-hsun.wu at mediatek.com>
+ */
+
+#ifndef __MDP_REG_TDSHP_H__
+#define __MDP_REG_TDSHP_H__
+
+#define MDP_HIST_CFG_00				(0x064)
+#define MDP_HIST_CFG_01				(0x068)
+#define MDP_TDSHP_CTRL				(0x100)
+#define MDP_TDSHP_CFG				(0x110)
+#define MDP_TDSHP_INPUT_SIZE			(0x120)
+#define MDP_TDSHP_OUTPUT_OFFSET			(0x124)
+#define MDP_TDSHP_OUTPUT_SIZE			(0x128)
+#define MDP_LUMA_HIST_INIT			(0x200)
+#define MDP_DC_TWO_D_W1_RESULT_INIT		(0x260)
+#define MDP_CONTOUR_HIST_INIT			(0x398)
+
+/* MASK */
+#define MDP_HIST_CFG_00_MASK			(0xFFFFFFFF)
+#define MDP_HIST_CFG_01_MASK			(0xFFFFFFFF)
+#define MDP_LUMA_HIST_MASK			(0xFFFFFFFF)
+#define MDP_TDSHP_CTRL_MASK			(0x07)
+#define MDP_TDSHP_CFG_MASK			(0x03F7)
+#define MDP_TDSHP_INPUT_SIZE_MASK		(0x1FFF1FFF)
+#define MDP_TDSHP_OUTPUT_OFFSET_MASK		(0x0FF00FF)
+#define MDP_TDSHP_OUTPUT_SIZE_MASK		(0x1FFF1FFF)
+#define MDP_LUMA_HIST_INIT_MASK			(0xFFFFFFFF)
+#define MDP_DC_TWO_D_W1_RESULT_INIT_MASK	(0x007FFFFF)
+#define MDP_CONTOUR_HIST_INIT_MASK		(0xFFFFFFFF)
+
+#endif  // __MDP_REG_TDSHP_H__
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_reg_wrot.h b/drivers/media/platform/mediatek/mdp3/mdp_reg_wrot.h
index 6d3ff0e2b672..b6f016d2c29d 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_reg_wrot.h
+++ b/drivers/media/platform/mediatek/mdp3/mdp_reg_wrot.h
@@ -17,14 +17,18 @@
 #define VIDO_STRIDE                 0x030
 #define VIDO_OFST_ADDR_C            0x038
 #define VIDO_STRIDE_C               0x03c
+#define VIDO_CTRL_2                 0x048
 #define VIDO_DITHER                 0x054
 #define VIDO_STRIDE_V               0x06c
 #define VIDO_OFST_ADDR_V            0x068
 #define VIDO_RSV_1                  0x070
+#define VIDO_DMA_PREULTRA           0x074
 #define VIDO_IN_SIZE                0x078
 #define VIDO_ROT_EN                 0x07c
 #define VIDO_FIFO_TEST              0x080
 #define VIDO_MAT_CTRL               0x084
+#define VIDO_SCAN_10BIT             0x0dc
+#define VIDO_PENDING_ZERO           0x0e0
 #define VIDO_BASE_ADDR              0xf00
 #define VIDO_BASE_ADDR_C            0xf04
 #define VIDO_BASE_ADDR_V            0xf08
@@ -40,14 +44,18 @@
 #define VIDO_STRIDE_MASK                0x0000ffff
 #define VIDO_OFST_ADDR_C_MASK           0x0fffffff
 #define VIDO_STRIDE_C_MASK              0x0000ffff
+#define VIDO_CTRL_2_MASK                0x0000000f
 #define VIDO_DITHER_MASK                0xff000001
 #define VIDO_STRIDE_V_MASK              0x0000ffff
 #define VIDO_OFST_ADDR_V_MASK           0x0fffffff
 #define VIDO_RSV_1_MASK                 0xffffffff
+#define VIDO_DMA_PREULTRA_MASK		0x00ffffff
 #define VIDO_IN_SIZE_MASK               0x1fff1fff
 #define VIDO_ROT_EN_MASK                0x00000001
 #define VIDO_FIFO_TEST_MASK             0x00000fff
 #define VIDO_MAT_CTRL_MASK              0x000000f3
+#define VIDO_SCAN_10BIT_MASK            0x0000000f
+#define VIDO_PENDING_ZERO_MASK          0x07ffffff
 #define VIDO_BASE_ADDR_MASK             0xffffffff
 #define VIDO_BASE_ADDR_C_MASK           0xffffffff
 #define VIDO_BASE_ADDR_V_MASK           0xffffffff
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h
index e89c51e1edb7..e6cbc6ab6bae 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h
@@ -84,22 +84,66 @@ enum mtk_mdp_comp_id {
 	MDP_COMP_CAMIN,		/* 9 */
 	MDP_COMP_CAMIN2,	/* 10 */
 	MDP_COMP_RDMA0,		/* 11 */
-	MDP_COMP_AAL0,		/* 12 */
-	MDP_COMP_CCORR0,	/* 13 */
-	MDP_COMP_RSZ0,		/* 14 */
-	MDP_COMP_RSZ1,		/* 15 */
-	MDP_COMP_TDSHP0,	/* 16 */
-	MDP_COMP_COLOR0,	/* 17 */
-	MDP_COMP_PATH0_SOUT,	/* 18 */
-	MDP_COMP_PATH1_SOUT,	/* 19 */
-	MDP_COMP_WROT0,		/* 20 */
-	MDP_COMP_WDMA,		/* 21 */
-
-	/* Dummy Engine */
-	MDP_COMP_RDMA1,		/* 22 */
-	MDP_COMP_RSZ2,		/* 23 */
-	MDP_COMP_TDSHP1,	/* 24 */
-	MDP_COMP_WROT1,		/* 25 */
+	MDP_COMP_RDMA1,		/* 12 */
+	MDP_COMP_RDMA2,		/* 13 */
+	MDP_COMP_RDMA3,		/* 14 */
+	MDP_COMP_AAL0,		/* 15 */
+	MDP_COMP_AAL1,		/* 16 */
+	MDP_COMP_AAL2,		/* 17 */
+	MDP_COMP_AAL3,		/* 18 */
+	MDP_COMP_CCORR0,	/* 19 */
+	MDP_COMP_RSZ0,		/* 20 */
+	MDP_COMP_RSZ1,		/* 21 */
+	MDP_COMP_RSZ2,		/* 22 */
+	MDP_COMP_RSZ3,		/* 23 */
+	MDP_COMP_TDSHP0,	/* 24 */
+	MDP_COMP_TDSHP1,	/* 25 */
+	MDP_COMP_TDSHP2,	/* 26 */
+	MDP_COMP_TDSHP3,	/* 27 */
+	MDP_COMP_COLOR0,	/* 28 */
+	MDP_COMP_COLOR1,	/* 29 */
+	MDP_COMP_COLOR2,	/* 30 */
+	MDP_COMP_COLOR3,	/* 31 */
+	MDP_COMP_PATH0_SOUT,	/* 32 */
+	MDP_COMP_PATH1_SOUT,	/* 33 */
+	MDP_COMP_WROT0,		/* 34 */
+	MDP_COMP_WROT1,		/* 35 */
+	MDP_COMP_WROT2,		/* 36 */
+	MDP_COMP_WROT3,		/* 37 */
+	MDP_COMP_WDMA,		/* 38 */
+	MDP_COMP_SPLIT,		/* 39 */
+	MDP_COMP_SPLIT2,	/* 40 */
+	MDP_COMP_STITCH,	/* 41 */
+	MDP_COMP_FG0,		/* 42 */
+	MDP_COMP_FG1,		/* 43 */
+	MDP_COMP_FG2,		/* 44 */
+	MDP_COMP_FG3,		/* 45 */
+	MDP_COMP_TO_SVPP2MOUT,	/* 46 */
+	MDP_COMP_TO_SVPP3MOUT,	/* 47 */
+	MDP_COMP_TO_WARP0MOUT,	/* 48 */
+	MDP_COMP_TO_WARP1MOUT,	/* 49 */
+	MDP_COMP_VPP0_SOUT,	/* 50 */
+	MDP_COMP_VPP1_SOUT,	/* 51 */
+	MDP_COMP_PQ0_SOUT,	/* 52 */
+	MDP_COMP_PQ1_SOUT,	/* 53 */
+	MDP_COMP_HDR0,		/* 54 */
+	MDP_COMP_HDR1,		/* 55 */
+	MDP_COMP_HDR2,		/* 56 */
+	MDP_COMP_HDR3,		/* 57 */
+	MDP_COMP_OVL0,		/* 58 */
+	MDP_COMP_OVL1,		/* 59 */
+	MDP_COMP_PAD0,		/* 60 */
+	MDP_COMP_PAD1,		/* 61 */
+	MDP_COMP_PAD2,		/* 62 */
+	MDP_COMP_PAD3,		/* 63 */
+	MDP_COMP_TCC0,		/* 64 */
+	MDP_COMP_TCC1,		/* 65 */
+	MDP_COMP_MERGE2,	/* 66 */
+	MDP_COMP_MERGE3,	/* 67 */
+	MDP_COMP_VDO0DL0,	/* 68 */
+	MDP_COMP_VDO1DL0,	/* 69 */
+	MDP_COMP_VDO0DL1,	/* 70 */
+	MDP_COMP_VDO1DL1,	/* 71 */
 
 	MDP_MAX_COMP_COUNT	/* ALWAYS keep at the end */
 };
@@ -117,12 +161,21 @@ enum mdp_comp_type {
 	MDP_COMP_TYPE_COLOR,
 	MDP_COMP_TYPE_DRE,
 	MDP_COMP_TYPE_CCORR,
+	MDP_COMP_TYPE_AAL,
+	MDP_COMP_TYPE_TCC,
 	MDP_COMP_TYPE_HDR,
+	MDP_COMP_TYPE_SPLIT,
+	MDP_COMP_TYPE_STITCH,
+	MDP_COMP_TYPE_FG,
+	MDP_COMP_TYPE_OVL,
+	MDP_COMP_TYPE_PAD,
+	MDP_COMP_TYPE_MERGE,
 
 	MDP_COMP_TYPE_IMGI,
 	MDP_COMP_TYPE_WPEI,
 	MDP_COMP_TYPE_EXTO,	/* External path */
 	MDP_COMP_TYPE_DL_PATH,	/* Direct-link path */
+	MDP_COMP_TYPE_DUMMY,
 
 	MDP_COMP_TYPE_COUNT	/* ALWAYS keep at the end */
 };
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:32 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:32 +0800
Subject: [PATCH v9 06/12] media: platform: mtk-mdp3: avoid multiple driver registrations
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-7-moudy.ho@mediatek.com>

The amount of MDP3 driver probes is determined by the registered
clocks of MMSYS.
Since MT8195 MDP3 utilizes VPPSYS0 and VPPSYS1, it's necessary to
prevent multiple driver registrations.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c  | 1 +
 drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c | 8 ++++++++
 drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h | 1 +
 3 files changed, 10 insertions(+)

diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index fe92c0474bfa..6f77c33074ec 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -410,6 +410,7 @@ static const struct mdp_pipe_info mt8183_pipe_info[] = {
 
 const struct mtk_mdp_driver_data mt8183_mdp_driver_data = {
 	.mdp_plat_id = MT8183,
+	.mdp_con_res = 0x14001000,
 	.mdp_probe_infra = mt8183_mdp_probe_infra,
 	.mdp_cfg = &mt8183_plat_cfg,
 	.mdp_mutex_table_idx = mt8183_mutex_idx,
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
index 4802b20d7f20..6ddb5e075f5d 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
@@ -211,6 +211,7 @@ static int mdp_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mdp_dev *mdp;
 	struct platform_device *mm_pdev;
+	struct resource *res;
 	int ret, i, mutex_id;
 
 	mdp = kzalloc(sizeof(*mdp), GFP_KERNEL);
@@ -222,6 +223,12 @@ static int mdp_probe(struct platform_device *pdev)
 	mdp->pdev = pdev;
 	mdp->mdp_data = of_device_get_match_data(&pdev->dev);
 
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (res->start != mdp->mdp_data->mdp_con_res) {
+		platform_set_drvdata(pdev, mdp);
+		goto success_return;
+	}
+
 	ret = mdp_mm_subsys_deploy(mdp, MDP_INFRA_MMSYS);
 	if (ret)
 		goto err_destroy_device;
@@ -311,6 +318,7 @@ static int mdp_probe(struct platform_device *pdev)
 		goto err_unregister_device;
 	}
 
+success_return:
 	dev_dbg(dev, "mdp-%d registered successfully\n", pdev->id);
 	return 0;
 
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
index ece6509666fd..22d1b17ef2fc 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
@@ -71,6 +71,7 @@ enum mdp_pipe_id {
 
 struct mtk_mdp_driver_data {
 	const int mdp_plat_id;
+	const resource_size_t mdp_con_res;
 	const struct of_device_id *mdp_probe_infra;
 	const struct mdp_platform_config *mdp_cfg;
 	const u32 *mdp_mutex_table_idx;
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:35 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:35 +0800
Subject: [PATCH v9 09/12] media: platform: mtk-mdp3: add mt8195 platform configuration
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-10-moudy.ho@mediatek.com>

Add MT8195 MDP3 basic configuration in file "mdp_cfg_data.c"
and corresponding driver data.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mdp_cfg_data.c     | 666 ++++++++++++++++++
 .../platform/mediatek/mdp3/mtk-img-ipi.h      |   1 +
 .../platform/mediatek/mdp3/mtk-mdp3-cfg.h     |   1 +
 .../platform/mediatek/mdp3/mtk-mdp3-comp.c    |  36 +
 .../platform/mediatek/mdp3/mtk-mdp3-core.c    |   6 +
 .../platform/mediatek/mdp3/mtk-mdp3-core.h    |   6 +
 6 files changed, 716 insertions(+)

diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index 3834efe54e17..9ee3931d31e3 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -46,12 +46,91 @@ enum mt8183_mdp_comp_id {
 	MT8183_MDP_COMP_WROT1,          /* 25 */
 };
 
+enum mt8195_mdp_comp_id {
+	/* MT8195 Comp id */
+	/* ISP */
+	MT8195_MDP_COMP_WPEI = 0,
+	MT8195_MDP_COMP_WPEO,           /* 1 */
+	MT8195_MDP_COMP_WPEI2,          /* 2 */
+	MT8195_MDP_COMP_WPEO2,          /* 3 */
+
+	/* MDP */
+	MT8195_MDP_COMP_CAMIN,          /* 4 */
+	MT8195_MDP_COMP_CAMIN2,         /* 5 */
+	MT8195_MDP_COMP_SPLIT,          /* 6 */
+	MT8195_MDP_COMP_SPLIT2,         /* 7 */
+	MT8195_MDP_COMP_RDMA0,          /* 8 */
+	MT8195_MDP_COMP_RDMA1,          /* 9 */
+	MT8195_MDP_COMP_RDMA2,          /* 10 */
+	MT8195_MDP_COMP_RDMA3,          /* 11 */
+	MT8195_MDP_COMP_STITCH,         /* 12 */
+	MT8195_MDP_COMP_FG0,            /* 13 */
+	MT8195_MDP_COMP_FG1,            /* 14 */
+	MT8195_MDP_COMP_FG2,            /* 15 */
+	MT8195_MDP_COMP_FG3,            /* 16 */
+	MT8195_MDP_COMP_TO_SVPP2MOUT,   /* 17 */
+	MT8195_MDP_COMP_TO_SVPP3MOUT,   /* 18 */
+	MT8195_MDP_COMP_TO_WARP0MOUT,   /* 19 */
+	MT8195_MDP_COMP_TO_WARP1MOUT,   /* 20 */
+	MT8195_MDP_COMP_VPP0_SOUT,      /* 21 */
+	MT8195_MDP_COMP_VPP1_SOUT,      /* 22 */
+	MT8195_MDP_COMP_PQ0_SOUT,       /* 23 */
+	MT8195_MDP_COMP_PQ1_SOUT,       /* 24 */
+	MT8195_MDP_COMP_HDR0,           /* 25 */
+	MT8195_MDP_COMP_HDR1,           /* 26 */
+	MT8195_MDP_COMP_HDR2,           /* 27 */
+	MT8195_MDP_COMP_HDR3,           /* 28 */
+	MT8195_MDP_COMP_AAL0,           /* 29 */
+	MT8195_MDP_COMP_AAL1,           /* 30 */
+	MT8195_MDP_COMP_AAL2,           /* 31 */
+	MT8195_MDP_COMP_AAL3,           /* 32 */
+	MT8195_MDP_COMP_RSZ0,           /* 33 */
+	MT8195_MDP_COMP_RSZ1,           /* 34 */
+	MT8195_MDP_COMP_RSZ2,           /* 35 */
+	MT8195_MDP_COMP_RSZ3,           /* 36 */
+	MT8195_MDP_COMP_TDSHP0,         /* 37 */
+	MT8195_MDP_COMP_TDSHP1,         /* 38 */
+	MT8195_MDP_COMP_TDSHP2,         /* 39 */
+	MT8195_MDP_COMP_TDSHP3,         /* 40 */
+	MT8195_MDP_COMP_COLOR0,         /* 41 */
+	MT8195_MDP_COMP_COLOR1,         /* 42 */
+	MT8195_MDP_COMP_COLOR2,         /* 43 */
+	MT8195_MDP_COMP_COLOR3,         /* 44 */
+	MT8195_MDP_COMP_OVL0,           /* 45 */
+	MT8195_MDP_COMP_OVL1,           /* 46 */
+	MT8195_MDP_COMP_PAD0,           /* 47 */
+	MT8195_MDP_COMP_PAD1,           /* 48 */
+	MT8195_MDP_COMP_PAD2,           /* 49 */
+	MT8195_MDP_COMP_PAD3,           /* 50 */
+	MT8195_MDP_COMP_TCC0,           /* 51 */
+	MT8195_MDP_COMP_TCC1,           /* 52 */
+	MT8195_MDP_COMP_WROT0,          /* 53 */
+	MT8195_MDP_COMP_WROT1,          /* 54 */
+	MT8195_MDP_COMP_WROT2,          /* 55 */
+	MT8195_MDP_COMP_WROT3,          /* 56 */
+	MT8195_MDP_COMP_MERGE2,         /* 57 */
+	MT8195_MDP_COMP_MERGE3,         /* 58 */
+
+	MT8195_MDP_COMP_VDO0DL0,        /* 59 */
+	MT8195_MDP_COMP_VDO1DL0,        /* 60 */
+	MT8195_MDP_COMP_VDO0DL1,        /* 61 */
+	MT8195_MDP_COMP_VDO1DL1,        /* 62 */
+};
+
 static const struct of_device_id mt8183_mdp_probe_infra[MDP_INFRA_MAX] = {
 	[MDP_INFRA_MMSYS] = { .compatible = "mediatek,mt8183-mmsys" },
 	[MDP_INFRA_MUTEX] = { .compatible = "mediatek,mt8183-disp-mutex" },
 	[MDP_INFRA_SCP] = { .compatible = "mediatek,mt8183-scp" }
 };
 
+static const struct of_device_id mt8195_mdp_probe_infra[MDP_INFRA_MAX] = {
+	[MDP_INFRA_MMSYS] = { .compatible = "mediatek,mt8195-vppsys0" },
+	[MDP_INFRA_MMSYS2] = { .compatible = "mediatek,mt8195-vppsys1" },
+	[MDP_INFRA_MUTEX] = { .compatible = "mediatek,mt8195-vpp-mutex" },
+	[MDP_INFRA_MUTEX2] = { .compatible = "mediatek,mt8195-vpp-mutex" },
+	[MDP_INFRA_SCP] = { .compatible = "mediatek,mt8195-scp" }
+};
+
 static const struct mdp_platform_config mt8183_plat_cfg = {
 	.rdma_support_10bit		= true,
 	.rdma_rsz1_sram_sharing		= true,
@@ -62,6 +141,21 @@ static const struct mdp_platform_config mt8183_plat_cfg = {
 	.wrot_event_num			= 1,
 };
 
+static const struct mdp_platform_config mt8195_plat_cfg = {
+	.rdma_support_10bit             = true,
+	.rdma_rsz1_sram_sharing         = false,
+	.rdma_upsample_repeat_only      = false,
+	.rdma_esl_setting		= true,
+	.rdma_event_num			= 4,
+	.rsz_disable_dcm_small_sample   = false,
+	.rsz_etc_control		= true,
+	.wrot_filter_constraint		= false,
+	.wrot_event_num			= 4,
+	.tdshp_hist_num			= 17,
+	.tdshp_constrain		= true,
+	.tdshp_contour			= true,
+};
+
 static const u32 mt8183_mutex_idx[MDP_MAX_COMP_COUNT] = {
 	[MDP_COMP_RDMA0] = MUTEX_MOD_IDX_MDP_RDMA0,
 	[MDP_COMP_RSZ0] = MUTEX_MOD_IDX_MDP_RSZ0,
@@ -73,6 +167,52 @@ static const u32 mt8183_mutex_idx[MDP_MAX_COMP_COUNT] = {
 	[MDP_COMP_CCORR0] = MUTEX_MOD_IDX_MDP_CCORR0,
 };
 
+static const u32 mt8195_mutex_idx[MDP_MAX_COMP_COUNT] = {
+	[MDP_COMP_RDMA0] = MUTEX_MOD_IDX_MDP_RDMA0,
+	[MDP_COMP_RDMA1] = MUTEX_MOD_IDX_MDP_RDMA1,
+	[MDP_COMP_RDMA2] = MUTEX_MOD_IDX_MDP_RDMA2,
+	[MDP_COMP_RDMA3] = MUTEX_MOD_IDX_MDP_RDMA3,
+	[MDP_COMP_STITCH] = MUTEX_MOD_IDX_MDP_STITCH0,
+	[MDP_COMP_FG0] = MUTEX_MOD_IDX_MDP_FG0,
+	[MDP_COMP_FG1] = MUTEX_MOD_IDX_MDP_FG1,
+	[MDP_COMP_FG2] = MUTEX_MOD_IDX_MDP_FG2,
+	[MDP_COMP_FG3] = MUTEX_MOD_IDX_MDP_FG3,
+	[MDP_COMP_HDR0] = MUTEX_MOD_IDX_MDP_HDR0,
+	[MDP_COMP_HDR1] = MUTEX_MOD_IDX_MDP_HDR1,
+	[MDP_COMP_HDR2] = MUTEX_MOD_IDX_MDP_HDR2,
+	[MDP_COMP_HDR3] = MUTEX_MOD_IDX_MDP_HDR3,
+	[MDP_COMP_AAL0] = MUTEX_MOD_IDX_MDP_AAL0,
+	[MDP_COMP_AAL1] = MUTEX_MOD_IDX_MDP_AAL1,
+	[MDP_COMP_AAL2] = MUTEX_MOD_IDX_MDP_AAL2,
+	[MDP_COMP_AAL3] = MUTEX_MOD_IDX_MDP_AAL3,
+	[MDP_COMP_RSZ0] = MUTEX_MOD_IDX_MDP_RSZ0,
+	[MDP_COMP_RSZ1] = MUTEX_MOD_IDX_MDP_RSZ1,
+	[MDP_COMP_RSZ2] = MUTEX_MOD_IDX_MDP_RSZ2,
+	[MDP_COMP_RSZ3] = MUTEX_MOD_IDX_MDP_RSZ3,
+	[MDP_COMP_MERGE2] = MUTEX_MOD_IDX_MDP_MERGE2,
+	[MDP_COMP_MERGE3] = MUTEX_MOD_IDX_MDP_MERGE3,
+	[MDP_COMP_TDSHP0] = MUTEX_MOD_IDX_MDP_TDSHP0,
+	[MDP_COMP_TDSHP1] = MUTEX_MOD_IDX_MDP_TDSHP1,
+	[MDP_COMP_TDSHP2] = MUTEX_MOD_IDX_MDP_TDSHP2,
+	[MDP_COMP_TDSHP3] = MUTEX_MOD_IDX_MDP_TDSHP3,
+	[MDP_COMP_COLOR0] = MUTEX_MOD_IDX_MDP_COLOR0,
+	[MDP_COMP_COLOR1] = MUTEX_MOD_IDX_MDP_COLOR1,
+	[MDP_COMP_COLOR2] = MUTEX_MOD_IDX_MDP_COLOR2,
+	[MDP_COMP_COLOR3] = MUTEX_MOD_IDX_MDP_COLOR3,
+	[MDP_COMP_OVL0] = MUTEX_MOD_IDX_MDP_OVL0,
+	[MDP_COMP_OVL1] = MUTEX_MOD_IDX_MDP_OVL1,
+	[MDP_COMP_PAD0] = MUTEX_MOD_IDX_MDP_PAD0,
+	[MDP_COMP_PAD1] = MUTEX_MOD_IDX_MDP_PAD1,
+	[MDP_COMP_PAD2] = MUTEX_MOD_IDX_MDP_PAD2,
+	[MDP_COMP_PAD3] = MUTEX_MOD_IDX_MDP_PAD3,
+	[MDP_COMP_TCC0] = MUTEX_MOD_IDX_MDP_TCC0,
+	[MDP_COMP_TCC1] = MUTEX_MOD_IDX_MDP_TCC1,
+	[MDP_COMP_WROT0] = MUTEX_MOD_IDX_MDP_WROT0,
+	[MDP_COMP_WROT1] = MUTEX_MOD_IDX_MDP_WROT1,
+	[MDP_COMP_WROT2] = MUTEX_MOD_IDX_MDP_WROT2,
+	[MDP_COMP_WROT3] = MUTEX_MOD_IDX_MDP_WROT3,
+};
+
 static const struct mdp_comp_data mt8183_mdp_comp_data[MDP_MAX_COMP_COUNT] = {
 	[MDP_COMP_WPEI] = {
 		{MDP_COMP_TYPE_WPEI, 0, MT8183_MDP_COMP_WPEI, MDP_MM_SUBSYS_0},
@@ -148,6 +288,263 @@ static const struct mdp_comp_data mt8183_mdp_comp_data[MDP_MAX_COMP_COUNT] = {
 	},
 };
 
+static const struct mdp_comp_data mt8195_mdp_comp_data[MDP_MAX_COMP_COUNT] = {
+	[MDP_COMP_WPEI] = {
+		{MDP_COMP_TYPE_WPEI, 0, MT8195_MDP_COMP_WPEI, MDP_MM_SUBSYS_0},
+		{0, 0, 0}
+	},
+	[MDP_COMP_WPEO] = {
+		{MDP_COMP_TYPE_EXTO, 2, MT8195_MDP_COMP_WPEO, MDP_MM_SUBSYS_0},
+		{0, 0, 0}
+	},
+	[MDP_COMP_WPEI2] = {
+		{MDP_COMP_TYPE_WPEI, 1, MT8195_MDP_COMP_WPEI2, MDP_MM_SUBSYS_0},
+		{0, 0, 0}
+	},
+	[MDP_COMP_WPEO2] = {
+		{MDP_COMP_TYPE_EXTO, 3, MT8195_MDP_COMP_WPEO2, MDP_MM_SUBSYS_0},
+		{0, 0, 0}
+	},
+	[MDP_COMP_CAMIN] = {
+		{MDP_COMP_TYPE_DL_PATH, 0, MT8195_MDP_COMP_CAMIN, MDP_MM_SUBSYS_0},
+		{3, 3, 0}
+	},
+	[MDP_COMP_CAMIN2] = {
+		{MDP_COMP_TYPE_DL_PATH, 1, MT8195_MDP_COMP_CAMIN2, MDP_MM_SUBSYS_0},
+		{3, 6, 0}
+	},
+	[MDP_COMP_SPLIT] = {
+		{MDP_COMP_TYPE_SPLIT, 0, MT8195_MDP_COMP_SPLIT, MDP_MM_SUBSYS_1},
+		{7, 0, 0}
+	},
+	[MDP_COMP_SPLIT2] = {
+		{MDP_COMP_TYPE_SPLIT, 1, MT8195_MDP_COMP_SPLIT2, MDP_MM_SUBSYS_1},
+		{7, 0, 0}
+	},
+	[MDP_COMP_RDMA0] = {
+		{MDP_COMP_TYPE_RDMA, 0, MT8195_MDP_COMP_RDMA0, MDP_MM_SUBSYS_0},
+		{3, 0, 0}
+	},
+	[MDP_COMP_RDMA1] = {
+		{MDP_COMP_TYPE_RDMA, 1, MT8195_MDP_COMP_RDMA1, MDP_MM_SUBSYS_1},
+		{3, 0, 0}
+	},
+	[MDP_COMP_RDMA2] = {
+		{MDP_COMP_TYPE_RDMA, 2, MT8195_MDP_COMP_RDMA2, MDP_MM_SUBSYS_1},
+		{3, 0, 0}
+	},
+	[MDP_COMP_RDMA3] = {
+		{MDP_COMP_TYPE_RDMA, 3, MT8195_MDP_COMP_RDMA3, MDP_MM_SUBSYS_1},
+		{3, 0, 0}
+	},
+	[MDP_COMP_STITCH] = {
+		{MDP_COMP_TYPE_STITCH, 0, MT8195_MDP_COMP_STITCH, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_FG0] = {
+		{MDP_COMP_TYPE_FG, 0, MT8195_MDP_COMP_FG0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_FG1] = {
+		{MDP_COMP_TYPE_FG, 1, MT8195_MDP_COMP_FG1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_FG2] = {
+		{MDP_COMP_TYPE_FG, 2, MT8195_MDP_COMP_FG2, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_FG3] = {
+		{MDP_COMP_TYPE_FG, 3, MT8195_MDP_COMP_FG3, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_HDR0] = {
+		{MDP_COMP_TYPE_HDR, 0, MT8195_MDP_COMP_HDR0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_HDR1] = {
+		{MDP_COMP_TYPE_HDR, 1, MT8195_MDP_COMP_HDR1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_HDR2] = {
+		{MDP_COMP_TYPE_HDR, 2, MT8195_MDP_COMP_HDR2, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_HDR3] = {
+		{MDP_COMP_TYPE_HDR, 3, MT8195_MDP_COMP_HDR3, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_AAL0] = {
+		{MDP_COMP_TYPE_AAL, 0, MT8195_MDP_COMP_AAL0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_AAL1] = {
+		{MDP_COMP_TYPE_AAL, 1, MT8195_MDP_COMP_AAL1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_AAL2] = {
+		{MDP_COMP_TYPE_AAL, 2, MT8195_MDP_COMP_AAL2, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_AAL3] = {
+		{MDP_COMP_TYPE_AAL, 3, MT8195_MDP_COMP_AAL3, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_RSZ0] = {
+		{MDP_COMP_TYPE_RSZ, 0, MT8195_MDP_COMP_RSZ0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_RSZ1] = {
+		{MDP_COMP_TYPE_RSZ, 1, MT8195_MDP_COMP_RSZ1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_RSZ2] = {
+		{MDP_COMP_TYPE_RSZ, 2, MT8195_MDP_COMP_RSZ2, MDP_MM_SUBSYS_1},
+		{2, 0, 0},
+		{MDP_COMP_MERGE2, true, true}
+	},
+	[MDP_COMP_RSZ3] = {
+		{MDP_COMP_TYPE_RSZ, 3, MT8195_MDP_COMP_RSZ3, MDP_MM_SUBSYS_1},
+		{2, 0, 0},
+		{MDP_COMP_MERGE3, true, true}
+	},
+	[MDP_COMP_TDSHP0] = {
+		{MDP_COMP_TYPE_TDSHP, 0, MT8195_MDP_COMP_TDSHP0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_TDSHP1] = {
+		{MDP_COMP_TYPE_TDSHP, 1, MT8195_MDP_COMP_TDSHP1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_TDSHP2] = {
+		{MDP_COMP_TYPE_TDSHP, 2, MT8195_MDP_COMP_TDSHP2, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_TDSHP3] = {
+		{MDP_COMP_TYPE_TDSHP, 3, MT8195_MDP_COMP_TDSHP3, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_COLOR0] = {
+		{MDP_COMP_TYPE_COLOR, 0, MT8195_MDP_COMP_COLOR0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_COLOR1] = {
+		{MDP_COMP_TYPE_COLOR, 1, MT8195_MDP_COMP_COLOR1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_COLOR2] = {
+		{MDP_COMP_TYPE_COLOR, 2, MT8195_MDP_COMP_COLOR2, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_COLOR3] = {
+		{MDP_COMP_TYPE_COLOR, 3, MT8195_MDP_COMP_COLOR3, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_OVL0] = {
+		{MDP_COMP_TYPE_OVL, 0, MT8195_MDP_COMP_OVL0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_OVL1] = {
+		{MDP_COMP_TYPE_OVL, 1, MT8195_MDP_COMP_OVL1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_PAD0] = {
+		{MDP_COMP_TYPE_PAD, 0, MT8195_MDP_COMP_PAD0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_PAD1] = {
+		{MDP_COMP_TYPE_PAD, 1, MT8195_MDP_COMP_PAD1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_PAD2] = {
+		{MDP_COMP_TYPE_PAD, 2, MT8195_MDP_COMP_PAD2, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_PAD3] = {
+		{MDP_COMP_TYPE_PAD, 3, MT8195_MDP_COMP_PAD3, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_TCC0] = {
+		{MDP_COMP_TYPE_TCC, 0, MT8195_MDP_COMP_TCC0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_TCC1] = {
+		{MDP_COMP_TYPE_TCC, 1, MT8195_MDP_COMP_TCC1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_WROT0] = {
+		{MDP_COMP_TYPE_WROT, 0, MT8195_MDP_COMP_WROT0, MDP_MM_SUBSYS_0},
+		{1, 0, 0}
+	},
+	[MDP_COMP_WROT1] = {
+		{MDP_COMP_TYPE_WROT, 1, MT8195_MDP_COMP_WROT1, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_WROT2] = {
+		{MDP_COMP_TYPE_WROT, 2, MT8195_MDP_COMP_WROT2, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_WROT3] = {
+		{MDP_COMP_TYPE_WROT, 3, MT8195_MDP_COMP_WROT3, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_MERGE2] = {
+		{MDP_COMP_TYPE_MERGE, 0, MT8195_MDP_COMP_MERGE2, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_MERGE3] = {
+		{MDP_COMP_TYPE_MERGE, 1, MT8195_MDP_COMP_MERGE3, MDP_MM_SUBSYS_1},
+		{1, 0, 0}
+	},
+	[MDP_COMP_PQ0_SOUT] = {
+		{MDP_COMP_TYPE_DUMMY, 0, MT8195_MDP_COMP_PQ0_SOUT, MDP_MM_SUBSYS_0},
+		{0, 0, 0}
+	},
+	[MDP_COMP_PQ1_SOUT] = {
+		{MDP_COMP_TYPE_DUMMY, 1, MT8195_MDP_COMP_PQ1_SOUT, MDP_MM_SUBSYS_1},
+		{0, 0, 0}
+	},
+	[MDP_COMP_TO_WARP0MOUT] = {
+		{MDP_COMP_TYPE_DUMMY, 2, MT8195_MDP_COMP_TO_WARP0MOUT, MDP_MM_SUBSYS_0},
+		{0, 0, 0}
+	},
+	[MDP_COMP_TO_WARP1MOUT] = {
+		{MDP_COMP_TYPE_DUMMY, 3, MT8195_MDP_COMP_TO_WARP1MOUT, MDP_MM_SUBSYS_0},
+		{0, 0, 0}
+	},
+	[MDP_COMP_TO_SVPP2MOUT] = {
+		{MDP_COMP_TYPE_DUMMY, 4, MT8195_MDP_COMP_TO_SVPP2MOUT, MDP_MM_SUBSYS_1},
+		{0, 0, 0}
+	},
+	[MDP_COMP_TO_SVPP3MOUT] = {
+		{MDP_COMP_TYPE_DUMMY, 5, MT8195_MDP_COMP_TO_SVPP3MOUT, MDP_MM_SUBSYS_1},
+		{0, 0, 0}
+	},
+	[MDP_COMP_VPP0_SOUT] = {
+		{MDP_COMP_TYPE_PATH, 0, MT8195_MDP_COMP_VPP0_SOUT, MDP_MM_SUBSYS_1},
+		{4, 9, 0}
+	},
+	[MDP_COMP_VPP1_SOUT] = {
+		{MDP_COMP_TYPE_PATH, 1, MT8195_MDP_COMP_VPP1_SOUT, MDP_MM_SUBSYS_0},
+		{2, 13, 0}
+	},
+	[MDP_COMP_VDO0DL0] = {
+		{MDP_COMP_TYPE_DL_PATH, 0, MT8195_MDP_COMP_VDO0DL0, MDP_MM_SUBSYS_1},
+		{1, 15, 0}
+	},
+	[MDP_COMP_VDO1DL0] = {
+		{MDP_COMP_TYPE_DL_PATH, 0, MT8195_MDP_COMP_VDO1DL0, MDP_MM_SUBSYS_1},
+		{1, 17, 0}
+	},
+	[MDP_COMP_VDO0DL1] = {
+		{MDP_COMP_TYPE_DL_PATH, 0, MT8195_MDP_COMP_VDO0DL1, MDP_MM_SUBSYS_1},
+		{1, 18, 0}
+	},
+	[MDP_COMP_VDO1DL1] = {
+		{MDP_COMP_TYPE_DL_PATH, 0, MT8195_MDP_COMP_VDO1DL1, MDP_MM_SUBSYS_1},
+		{1, 16, 0}
+	},
+};
+
 static const struct of_device_id mt8183_sub_comp_dt_ids[] = {
 	{
 		.compatible = "mediatek,mt8183-mdp3-wdma",
@@ -159,6 +556,10 @@ static const struct of_device_id mt8183_sub_comp_dt_ids[] = {
 	{}
 };
 
+static const struct of_device_id mt8195_sub_comp_dt_ids[] = {
+	{}
+};
+
 /*
  * All 10-bit related formats are not added in the basic format list,
  * please add the corresponding format settings before use.
@@ -384,6 +785,222 @@ static const struct mdp_format mt8183_formats[] = {
 	}
 };
 
+static const struct mdp_format mt8195_formats[] = {
+	{
+		.pixelformat	= V4L2_PIX_FMT_GREY,
+		.mdp_color	= MDP_COLOR_GREY,
+		.depth		= { 8 },
+		.row_depth	= { 8 },
+		.num_planes	= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_RGB565X,
+		.mdp_color	= MDP_COLOR_BGR565,
+		.depth		= { 16 },
+		.row_depth	= { 16 },
+		.num_planes	= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_RGB565,
+		.mdp_color	= MDP_COLOR_RGB565,
+		.depth		= { 16 },
+		.row_depth	= { 16 },
+		.num_planes	= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_RGB24,
+		.mdp_color	= MDP_COLOR_RGB888,
+		.depth		= { 24 },
+		.row_depth	= { 24 },
+		.num_planes	= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_BGR24,
+		.mdp_color	= MDP_COLOR_BGR888,
+		.depth		= { 24 },
+		.row_depth	= { 24 },
+		.num_planes	= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_ABGR32,
+		.mdp_color	= MDP_COLOR_BGRA8888,
+		.depth		= { 32 },
+		.row_depth	= { 32 },
+		.num_planes	= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_ARGB32,
+		.mdp_color	= MDP_COLOR_ARGB8888,
+		.depth		= { 32 },
+		.row_depth	= { 32 },
+		.num_planes	= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_UYVY,
+		.mdp_color	= MDP_COLOR_UYVY,
+		.depth		= { 16 },
+		.row_depth	= { 16 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_VYUY,
+		.mdp_color	= MDP_COLOR_VYUY,
+		.depth		= { 16 },
+		.row_depth	= { 16 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_YUYV,
+		.mdp_color	= MDP_COLOR_YUYV,
+		.depth		= { 16 },
+		.row_depth	= { 16 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_YVYU,
+		.mdp_color	= MDP_COLOR_YVYU,
+		.depth		= { 16 },
+		.row_depth	= { 16 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_YUV420,
+		.mdp_color	= MDP_COLOR_I420,
+		.depth		= { 12 },
+		.row_depth	= { 8 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_YVU420,
+		.mdp_color	= MDP_COLOR_YV12,
+		.depth		= { 12 },
+		.row_depth	= { 8 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_NV12,
+		.mdp_color	= MDP_COLOR_NV12,
+		.depth		= { 12 },
+		.row_depth	= { 8 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_NV21,
+		.mdp_color	= MDP_COLOR_NV21,
+		.depth		= { 12 },
+		.row_depth	= { 8 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_NV16,
+		.mdp_color	= MDP_COLOR_NV16,
+		.depth		= { 16 },
+		.row_depth	= { 8 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_NV61,
+		.mdp_color	= MDP_COLOR_NV61,
+		.depth		= { 16 },
+		.row_depth	= { 8 },
+		.num_planes	= 1,
+		.walign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_NV12M,
+		.mdp_color	= MDP_COLOR_NV12,
+		.depth		= { 8, 4 },
+		.row_depth	= { 8, 8 },
+		.num_planes	= 2,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_MM21,
+		.mdp_color	= MDP_COLOR_420_BLK,
+		.depth		= { 8, 4 },
+		.row_depth	= { 8, 8 },
+		.num_planes	= 2,
+		.walign		= 6,
+		.halign		= 6,
+		.flags		= MDP_FMT_FLAG_OUTPUT,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_NV21M,
+		.mdp_color	= MDP_COLOR_NV21,
+		.depth		= { 8, 4 },
+		.row_depth	= { 8, 8 },
+		.num_planes	= 2,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_NV16M,
+		.mdp_color	= MDP_COLOR_NV16,
+		.depth		= { 8, 8 },
+		.row_depth	= { 8, 8 },
+		.num_planes	= 2,
+		.walign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_NV61M,
+		.mdp_color	= MDP_COLOR_NV61,
+		.depth		= { 8, 8 },
+		.row_depth	= { 8, 8 },
+		.num_planes	= 2,
+		.walign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_YUV420M,
+		.mdp_color	= MDP_COLOR_I420,
+		.depth		= { 8, 2, 2 },
+		.row_depth	= { 8, 4, 4 },
+		.num_planes	= 3,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_YVU420M,
+		.mdp_color	= MDP_COLOR_YV12,
+		.depth		= { 8, 2, 2 },
+		.row_depth	= { 8, 4, 4 },
+		.num_planes	= 3,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_YUV422M,
+		.mdp_color	= MDP_COLOR_I422,
+		.depth		= { 8, 4, 4 },
+		.row_depth	= { 8, 4, 4 },
+		.num_planes	= 3,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}, {
+		.pixelformat	= V4L2_PIX_FMT_YVU422M,
+		.mdp_color	= MDP_COLOR_YV16,
+		.depth		= { 8, 4, 4 },
+		.row_depth	= { 8, 4, 4 },
+		.num_planes	= 3,
+		.walign		= 1,
+		.halign		= 1,
+		.flags		= MDP_FMT_FLAG_OUTPUT | MDP_FMT_FLAG_CAPTURE,
+	}
+};
+
 static const struct mdp_limit mt8183_mdp_def_limit = {
 	.out_limit = {
 		.wmin	= 16,
@@ -403,6 +1020,25 @@ static const struct mdp_limit mt8183_mdp_def_limit = {
 	.v_scale_down_max = 128,
 };
 
+static const struct mdp_limit mt8195_mdp_def_limit = {
+	.out_limit = {
+		.wmin	= 64,
+		.hmin	= 64,
+		.wmax	= 8192,
+		.hmax	= 8192,
+	},
+	.cap_limit = {
+		.wmin	= 64,
+		.hmin	= 64,
+		.wmax	= 8192,
+		.hmax	= 8192,
+	},
+	.h_scale_up_max = 64,
+	.v_scale_up_max = 64,
+	.h_scale_down_max = 128,
+	.v_scale_down_max = 128,
+};
+
 static const struct mdp_pipe_info mt8183_pipe_info[] = {
 	[MDP_PIPE_WPEI] = {MDP_PIPE_WPEI, MDP_MM_SUBSYS_0, 0},
 	[MDP_PIPE_WPEI2] = {MDP_PIPE_WPEI2, MDP_MM_SUBSYS_0, 1},
@@ -410,6 +1046,20 @@ static const struct mdp_pipe_info mt8183_pipe_info[] = {
 	[MDP_PIPE_RDMA0] = {MDP_PIPE_RDMA0, MDP_MM_SUBSYS_0, 3}
 };
 
+static const struct mdp_pipe_info mt8195_pipe_info[] = {
+	[MDP_PIPE_WPEI] = {MDP_PIPE_WPEI, MDP_MM_SUBSYS_0, 0},
+	[MDP_PIPE_WPEI2] = {MDP_PIPE_WPEI2, MDP_MM_SUBSYS_0, 1},
+	[MDP_PIPE_IMGI] = {MDP_PIPE_IMGI, MDP_MM_SUBSYS_0, 2},
+	[MDP_PIPE_RDMA0] = {MDP_PIPE_RDMA0, MDP_MM_SUBSYS_0, 3},
+	[MDP_PIPE_RDMA1] = {MDP_PIPE_RDMA1, MDP_MM_SUBSYS_1, 0},
+	[MDP_PIPE_RDMA2] = {MDP_PIPE_RDMA2, MDP_MM_SUBSYS_1, 1},
+	[MDP_PIPE_RDMA3] = {MDP_PIPE_RDMA3, MDP_MM_SUBSYS_1, 2},
+	[MDP_PIPE_SPLIT] = {MDP_PIPE_SPLIT, MDP_MM_SUBSYS_1, 3},
+	[MDP_PIPE_SPLIT2] = {MDP_PIPE_SPLIT2, MDP_MM_SUBSYS_1, 4},
+	[MDP_PIPE_VPP1_SOUT] = {MDP_PIPE_VPP1_SOUT, MDP_MM_SUBSYS_0, 4},
+	[MDP_PIPE_VPP0_SOUT] = {MDP_PIPE_VPP0_SOUT, MDP_MM_SUBSYS_1, 5},
+};
+
 const struct mtk_mdp_driver_data mt8183_mdp_driver_data = {
 	.mdp_plat_id = MT8183,
 	.mdp_con_res = 0x14001000,
@@ -426,6 +1076,22 @@ const struct mtk_mdp_driver_data mt8183_mdp_driver_data = {
 	.pipe_info_len = ARRAY_SIZE(mt8183_pipe_info),
 };
 
+const struct mtk_mdp_driver_data mt8195_mdp_driver_data = {
+	.mdp_plat_id = MT8195,
+	.mdp_con_res = 0x14001000,
+	.mdp_probe_infra = mt8195_mdp_probe_infra,
+	.mdp_sub_comp_dt_ids = mt8195_sub_comp_dt_ids,
+	.mdp_cfg = &mt8195_plat_cfg,
+	.mdp_mutex_table_idx = mt8195_mutex_idx,
+	.comp_data = mt8195_mdp_comp_data,
+	.comp_data_len = ARRAY_SIZE(mt8195_mdp_comp_data),
+	.format = mt8195_formats,
+	.format_len = ARRAY_SIZE(mt8195_formats),
+	.def_limit = &mt8195_mdp_def_limit,
+	.pipe_info = mt8195_pipe_info,
+	.pipe_info_len = ARRAY_SIZE(mt8195_pipe_info),
+};
+
 s32 mdp_cfg_get_id_inner(struct mdp_dev *mdp_dev, enum mtk_mdp_comp_id id)
 {
 	if (!mdp_dev)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h b/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h
index 22b8b9a10ef7..08fb0853bcd5 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h
@@ -115,6 +115,7 @@ struct img_frameparam {
 
 /* Platform config indicator */
 #define MT8183 8183
+#define MT8195 8195
 
 #define CFG_CHECK(plat, p_id) ((plat) == (p_id))
 
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
index dfffc72868e4..49cdf45f6e59 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
@@ -10,6 +10,7 @@
 #include <linux/types.h>
 
 extern const struct mtk_mdp_driver_data mt8183_mdp_driver_data;
+extern const struct mtk_mdp_driver_data mt8195_mdp_driver_data;
 
 struct mdp_dev;
 enum mtk_mdp_comp_id;
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
index e97630b7867c..600fec7d2f7f 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
@@ -773,6 +773,42 @@ static const struct of_device_id mdp_comp_dt_ids[] __maybe_unused = {
 	}, {
 		.compatible = "mediatek,mt8183-mdp3-wdma",
 		.data = (void *)MDP_COMP_TYPE_WDMA,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-rdma",
+		.data = (void *)MDP_COMP_TYPE_RDMA,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-split",
+		.data = (void *)MDP_COMP_TYPE_SPLIT,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-stitch",
+		.data = (void *)MDP_COMP_TYPE_STITCH,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-fg",
+		.data = (void *)MDP_COMP_TYPE_FG,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-hdr",
+		.data = (void *)MDP_COMP_TYPE_HDR,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-aal",
+		.data = (void *)MDP_COMP_TYPE_AAL,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-merge",
+		.data = (void *)MDP_COMP_TYPE_MERGE,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-tdshp",
+		.data = (void *)MDP_COMP_TYPE_TDSHP,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-color",
+		.data = (void *)MDP_COMP_TYPE_COLOR,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-ovl",
+		.data = (void *)MDP_COMP_TYPE_OVL,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-padding",
+		.data = (void *)MDP_COMP_TYPE_PAD,
+	}, {
+		.compatible = "mediatek,mt8195-mdp3-tcc",
+		.data = (void *)MDP_COMP_TYPE_TCC,
 	},
 	{}
 };
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
index 6ddb5e075f5d..a6c71fd9e5bf 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
@@ -21,6 +21,12 @@ static const struct of_device_id mdp_of_ids[] = {
 	{ .compatible = "mediatek,mt8183-mdp3-rdma",
 	  .data = &mt8183_mdp_driver_data,
 	},
+	{ .compatible = "mediatek,mt8195-mdp3-rdma",
+	  .data = &mt8195_mdp_driver_data,
+	},
+	{ .compatible = "mediatek,mt8195-mdp3-wrot",
+	  .data = &mt8195_mdp_driver_data,
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, mdp_of_ids);
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
index e57c415a1c78..d6484d17b09f 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
@@ -49,10 +49,16 @@ struct mdp_platform_config {
 	bool	rdma_support_10bit;
 	bool	rdma_rsz1_sram_sharing;
 	bool	rdma_upsample_repeat_only;
+	bool	rdma_esl_setting;
 	u32	rdma_event_num;
 	bool	rsz_disable_dcm_small_sample;
+	bool	rsz_etc_control;
 	bool	wrot_filter_constraint;
+	bool	wrot_support_10bit;
 	u32	wrot_event_num;
+	u32	tdshp_hist_num;
+	bool	tdshp_constrain;
+	bool	tdshp_contour;
 };
 
 /* indicate which mutex is used by each pipepline */
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:38 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:38 +0800
Subject: [PATCH v9 12/12] media: platform: mtk-mdp3: add support for parallel pipe to improve FPS
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-13-moudy.ho@mediatek.com>

In some chips, MDP3 has the ability to utilize two pipelines to
parallelly process a single frame.
To enable this feature, multiple CMDQ clients and packets need to
be configured at the same time.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mdp_cfg_data.c     |   8 +
 .../platform/mediatek/mdp3/mtk-mdp3-cmdq.c    | 188 +++++++++++++-----
 .../platform/mediatek/mdp3/mtk-mdp3-cmdq.h    |   1 +
 .../platform/mediatek/mdp3/mtk-mdp3-core.c    |  18 +-
 .../platform/mediatek/mdp3/mtk-mdp3-core.h    |  12 +-
 .../platform/mediatek/mdp3/mtk-mdp3-m2m.c     |  15 ++
 .../platform/mediatek/mdp3/mtk-mdp3-regs.c    |  18 ++
 .../platform/mediatek/mdp3/mtk-mdp3-regs.h    |   1 +
 .../platform/mediatek/mdp3/mtk-mdp3-vpu.c     |   3 +-
 9 files changed, 208 insertions(+), 56 deletions(-)

diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index 9ee3931d31e3..ecca52b45307 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -1060,6 +1060,11 @@ static const struct mdp_pipe_info mt8195_pipe_info[] = {
 	[MDP_PIPE_VPP0_SOUT] = {MDP_PIPE_VPP0_SOUT, MDP_MM_SUBSYS_1, 5},
 };
 
+static const struct v4l2_rect mt8195_mdp_pp_criteria = {
+	.width = 1920,
+	.height = 1080,
+};
+
 const struct mtk_mdp_driver_data mt8183_mdp_driver_data = {
 	.mdp_plat_id = MT8183,
 	.mdp_con_res = 0x14001000,
@@ -1074,6 +1079,7 @@ const struct mtk_mdp_driver_data mt8183_mdp_driver_data = {
 	.def_limit = &mt8183_mdp_def_limit,
 	.pipe_info = mt8183_pipe_info,
 	.pipe_info_len = ARRAY_SIZE(mt8183_pipe_info),
+	.pp_used = MDP_PP_USED_1,
 };
 
 const struct mtk_mdp_driver_data mt8195_mdp_driver_data = {
@@ -1090,6 +1096,8 @@ const struct mtk_mdp_driver_data mt8195_mdp_driver_data = {
 	.def_limit = &mt8195_mdp_def_limit,
 	.pipe_info = mt8195_pipe_info,
 	.pipe_info_len = ARRAY_SIZE(mt8195_pipe_info),
+	.pp_criteria = &mt8195_mdp_pp_criteria,
+	.pp_used = MDP_PP_USED_2,
 };
 
 s32 mdp_cfg_get_id_inner(struct mdp_dev *mdp_dev, enum mtk_mdp_comp_id id)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 8114c288da9c..1d64bac34b90 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -55,6 +55,16 @@ static struct mtk_mutex *__get_mutex(const struct mdp_dev *mdp_dev,
 	return mdp_dev->mm_subsys[p->sub_id].mdp_mutex[p->mutex_id];
 }
 
+static u8 __get_pp_num(enum mdp_stream_type type)
+{
+	switch (type) {
+	case MDP_STREAM_TYPE_DUAL_BITBLT:
+		return MDP_PP_USED_2;
+	default:
+		return MDP_PP_USED_1;
+	}
+}
+
 static enum mdp_pipe_id __get_pipe(const struct mdp_dev *mdp_dev,
 				   enum mtk_mdp_comp_id id)
 {
@@ -92,6 +102,44 @@ static enum mdp_pipe_id __get_pipe(const struct mdp_dev *mdp_dev,
 	return pipe_id;
 }
 
+static struct img_config *__get_config_offset(struct mdp_dev *mdp,
+					      struct mdp_cmdq_param *param,
+					      u8 pp_idx)
+{
+	const int p_id = mdp->mdp_data->mdp_plat_id;
+	struct device *dev = &mdp->pdev->dev;
+	void *cfg_c, *cfg_n;
+	long bound = mdp->vpu.config_size;
+
+	if (pp_idx >= mdp->mdp_data->pp_used)
+		goto err_param;
+
+	if (CFG_CHECK(MT8183, p_id))
+		cfg_c = CFG_OFST(MT8183, param->config, pp_idx);
+	else if (CFG_CHECK(MT8195, p_id))
+		cfg_c = CFG_OFST(MT8195, param->config, pp_idx);
+	else
+		goto err_param;
+
+	if (CFG_CHECK(MT8183, p_id))
+		cfg_n = CFG_OFST(MT8183, param->config, pp_idx + 1);
+	else if (CFG_CHECK(MT8195, p_id))
+		cfg_n = CFG_OFST(MT8195, param->config, pp_idx + 1);
+	else
+		goto err_param;
+
+	if ((long)cfg_n - (long)mdp->vpu.config > bound) {
+		dev_err(dev, "config offset %ld OOB %ld\n", (long)cfg_n, bound);
+		cfg_c = ERR_PTR(-EFAULT);
+	}
+
+	return (struct img_config *)cfg_c;
+
+err_param:
+	cfg_c = ERR_PTR(-EINVAL);
+	return (struct img_config *)cfg_c;
+}
+
 static int mdp_path_subfrm_require(const struct mdp_path *path,
 				   struct mdp_cmdq_cmd *cmd,
 				   struct mdp_pipe_info *p, u32 count)
@@ -476,8 +524,19 @@ static void mdp_auto_release_work(struct work_struct *work)
 	mdp_comp_clocks_off(&mdp->pdev->dev, cmd->comps,
 			    cmd->num_comps);
 
-	atomic_dec(&mdp->job_count);
-	wake_up(&mdp->callback_wq);
+	if (atomic_dec_and_test(&mdp->job_count)) {
+		if (cmd->mdp_ctx)
+			mdp_m2m_job_finish(cmd->mdp_ctx);
+
+		if (cmd->user_cmdq_cb) {
+			struct cmdq_cb_data user_cb_data;
+
+			user_cb_data.sta = cmd->data->sta;
+			user_cb_data.pkt = cmd->data->pkt;
+			cmd->user_cmdq_cb(user_cb_data);
+		}
+		wake_up(&mdp->callback_wq);
+	}
 
 	mdp_cmdq_pkt_destroy(&cmd->pkt);
 	kfree(cmd->comps);
@@ -501,20 +560,10 @@ static void mdp_handle_cmdq_callback(struct mbox_client *cl, void *mssg)
 
 	data = (struct cmdq_cb_data *)mssg;
 	cmd = container_of(data->pkt, struct mdp_cmdq_cmd, pkt);
+	cmd->data = data;
 	mdp = cmd->mdp;
 	dev = &mdp->pdev->dev;
 
-	if (cmd->mdp_ctx)
-		mdp_m2m_job_finish(cmd->mdp_ctx);
-
-	if (cmd->user_cmdq_cb) {
-		struct cmdq_cb_data user_cb_data;
-
-		user_cb_data.sta = data->sta;
-		user_cb_data.pkt = data->pkt;
-		cmd->user_cmdq_cb(user_cb_data);
-	}
-
 	INIT_WORK(&cmd->auto_release_work, mdp_auto_release_work);
 	if (!queue_work(mdp->clock_wq, &cmd->auto_release_work)) {
 		struct mtk_mutex *mutex;
@@ -526,8 +575,8 @@ static void mdp_handle_cmdq_callback(struct mbox_client *cl, void *mssg)
 		mdp_comp_clocks_off(&mdp->pdev->dev, cmd->comps,
 				    cmd->num_comps);
 
-		atomic_dec(&mdp->job_count);
-		wake_up(&mdp->callback_wq);
+		if (atomic_dec_and_test(&mdp->job_count))
+			wake_up(&mdp->callback_wq);
 
 		mdp_cmdq_pkt_destroy(&cmd->pkt);
 		kfree(cmd->comps);
@@ -537,31 +586,41 @@ static void mdp_handle_cmdq_callback(struct mbox_client *cl, void *mssg)
 	}
 }
 
-int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
+static struct mdp_cmdq_cmd *mdp_cmdq_prepare(struct mdp_dev *mdp,
+					     struct mdp_cmdq_param *param,
+					     u8 pp_idx)
 {
 	struct mdp_path *path = NULL;
 	struct mdp_cmdq_cmd *cmd = NULL;
 	struct mdp_comp *comps = NULL;
 	struct device *dev = &mdp->pdev->dev;
 	const int p_id = mdp->mdp_data->mdp_plat_id;
+	struct img_config *config;
 	struct mtk_mutex *mutex = NULL;
 	enum mdp_pipe_id pipe_id;
-	int i, ret;
-	u32 num_comp = 0;
+	int i, ret = -ECANCELED;
+	u32 num_comp;
 
-	atomic_inc(&mdp->job_count);
-	if (atomic_read(&mdp->suspended)) {
-		atomic_dec(&mdp->job_count);
-		return -ECANCELED;
+	config = __get_config_offset(mdp, param, pp_idx);
+	if (IS_ERR(config)) {
+		ret = PTR_ERR(config);
+		goto err_uninit;
 	}
 
+	if (CFG_CHECK(MT8183, p_id))
+		num_comp = CFG_GET(MT8183, config, num_components);
+	else if (CFG_CHECK(MT8195, p_id))
+		num_comp = CFG_GET(MT8195, config, num_components);
+	else
+		goto err_uninit;
+
 	cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
 	if (!cmd) {
 		ret = -ENOMEM;
-		goto err_cancel_job;
+		goto err_uninit;
 	}
 
-	ret = mdp_cmdq_pkt_create(mdp->cmdq_clt, &cmd->pkt, SZ_16K);
+	ret = mdp_cmdq_pkt_create(mdp->cmdq_clt[pp_idx], &cmd->pkt, SZ_16K);
 	if (ret)
 		goto err_free_cmd;
 
@@ -586,7 +645,7 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 	}
 
 	path->mdp_dev = mdp;
-	path->config = param->config;
+	path->config = config;
 	path->param = param->param;
 	for (i = 0; i < param->param->num_outputs; i++) {
 		path->bounds[i].left = 0;
@@ -600,7 +659,7 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 	}
 	ret = mdp_path_ctx_init(mdp, path);
 	if (ret) {
-		dev_err(dev, "mdp_path_ctx_init error\n");
+		dev_err(dev, "mdp_path_ctx_init error %d\n", pp_idx);
 		goto err_free_path;
 	}
 
@@ -608,13 +667,13 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 	mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[pipe_id]);
 	ret = mtk_mutex_prepare(mutex);
 	if (ret) {
-		dev_err(dev, "Fail to enable mutex clk\n");
+		dev_err(dev, "Fail to enable mutex %d clk\n", pp_idx);
 		goto err_free_path;
 	}
 
 	ret = mdp_path_config(mdp, cmd, path);
 	if (ret) {
-		dev_err(dev, "mdp_path_config error\n");
+		dev_err(dev, "mdp_path_config error %d\n", pp_idx);
 		goto err_free_path;
 	}
 	cmdq_pkt_finalize(&cmd->pkt);
@@ -633,7 +692,7 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 		       sizeof(struct mdp_comp));
 	}
 
-	mdp->cmdq_clt->client.rx_callback = mdp_handle_cmdq_callback;
+	mdp->cmdq_clt[pp_idx]->client.rx_callback = mdp_handle_cmdq_callback;
 	cmd->mdp = mdp;
 	cmd->user_cmdq_cb = param->cmdq_cb;
 	cmd->user_cb_data = param->cb_data;
@@ -641,26 +700,9 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 	cmd->num_comps = num_comp;
 	cmd->mdp_ctx = param->mdp_ctx;
 
-	ret = mdp_comp_clocks_on(&mdp->pdev->dev, cmd->comps, cmd->num_comps);
-	if (ret)
-		goto err_free_path;
-
-	dma_sync_single_for_device(mdp->cmdq_clt->chan->mbox->dev,
-				   cmd->pkt.pa_base, cmd->pkt.cmd_buf_size,
-				   DMA_TO_DEVICE);
-	ret = mbox_send_message(mdp->cmdq_clt->chan, &cmd->pkt);
-	if (ret < 0) {
-		dev_err(dev, "mbox send message fail %d!\n", ret);
-		goto err_clock_off;
-	}
-	mbox_client_txdone(mdp->cmdq_clt->chan, 0);
-
 	kfree(path);
-	return 0;
+	return cmd;
 
-err_clock_off:
-	mdp_comp_clocks_off(&mdp->pdev->dev, cmd->comps,
-			    cmd->num_comps);
 err_free_path:
 	if (mutex)
 		mtk_mutex_unprepare(mutex);
@@ -671,8 +713,58 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 	mdp_cmdq_pkt_destroy(&cmd->pkt);
 err_free_cmd:
 	kfree(cmd);
+err_uninit:
+	return ERR_PTR(ret);
+}
+
+int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
+{
+	struct mdp_cmdq_cmd *cmd[MDP_PP_MAX] = {NULL};
+	struct device *dev = &mdp->pdev->dev;
+	int i, ret;
+	u8 pp_used = __get_pp_num(param->param->type);
+
+	atomic_set(&mdp->job_count, pp_used);
+	if (atomic_read(&mdp->suspended)) {
+		atomic_set(&mdp->job_count, 0);
+		return -ECANCELED;
+	}
+
+	for (i = 0; i < pp_used; i++) {
+		cmd[i] = mdp_cmdq_prepare(mdp, param, i);
+		if (IS_ERR_OR_NULL(cmd[i])) {
+			ret = PTR_ERR(cmd[i]);
+			goto err_cancel_job;
+		}
+	}
+
+	for (i = 0; i < pp_used; i++) {
+		ret = mdp_comp_clocks_on(&mdp->pdev->dev, cmd[i]->comps, cmd[i]->num_comps);
+		if (ret)
+			goto err_clock_off;
+	}
+
+	for (i = 0; i < pp_used; i++) {
+		dma_sync_single_for_device(mdp->cmdq_clt[i]->chan->mbox->dev,
+					   cmd[i]->pkt.pa_base, cmd[i]->pkt.cmd_buf_size,
+					   DMA_TO_DEVICE);
+
+		ret = mbox_send_message(mdp->cmdq_clt[i]->chan, &cmd[i]->pkt);
+		if (ret < 0) {
+			dev_err(dev, "mbox send message fail %d!\n", ret);
+			i = pp_used;
+			goto err_clock_off;
+		}
+		mbox_client_txdone(mdp->cmdq_clt[i]->chan, 0);
+	}
+	return 0;
+
+err_clock_off:
+	while (--i >= 0)
+		mdp_comp_clocks_off(&mdp->pdev->dev, cmd[i]->comps,
+				    cmd[i]->num_comps);
 err_cancel_job:
-	atomic_dec(&mdp->job_count);
+	atomic_set(&mdp->job_count, 0);
 
 	return ret;
 }
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.h
index 43475b862ddb..53a30ad7e0b0 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.h
@@ -29,6 +29,7 @@ struct mdp_cmdq_cmd {
 	struct cmdq_pkt pkt;
 	s32 *event;
 	struct mdp_dev *mdp;
+	struct cmdq_cb_data *data;
 	void (*user_cmdq_cb)(struct cmdq_cb_data data);
 	void *user_cb_data;
 	struct mdp_comp *comps;
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
index a6c71fd9e5bf..5209f531ef8d 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
@@ -142,6 +142,10 @@ void mdp_video_device_release(struct video_device *vdev)
 	struct mdp_dev *mdp = (struct mdp_dev *)video_get_drvdata(vdev);
 	int i;
 
+	for (i = 0; i < mdp->mdp_data->pp_used; i++)
+		if (mdp->cmdq_clt[i])
+			cmdq_mbox_destroy(mdp->cmdq_clt[i]);
+
 	scp_put(mdp->scp);
 
 	destroy_workqueue(mdp->job_wq);
@@ -299,10 +303,12 @@ static int mdp_probe(struct platform_device *pdev)
 	mutex_init(&mdp->vpu_lock);
 	mutex_init(&mdp->m2m_lock);
 
-	mdp->cmdq_clt = cmdq_mbox_create(dev, 0);
-	if (IS_ERR(mdp->cmdq_clt)) {
-		ret = PTR_ERR(mdp->cmdq_clt);
-		goto err_put_scp;
+	for (i = 0; i < mdp->mdp_data->pp_used; i++) {
+		mdp->cmdq_clt[i] = cmdq_mbox_create(dev, i);
+		if (IS_ERR(mdp->cmdq_clt[i])) {
+			ret = PTR_ERR(mdp->cmdq_clt[i]);
+			goto err_mbox_destroy;
+		}
 	}
 
 	init_waitqueue_head(&mdp->callback_wq);
@@ -331,8 +337,8 @@ static int mdp_probe(struct platform_device *pdev)
 err_unregister_device:
 	v4l2_device_unregister(&mdp->v4l2_dev);
 err_mbox_destroy:
-	cmdq_mbox_destroy(mdp->cmdq_clt);
-err_put_scp:
+	while (--i >= 0)
+		cmdq_mbox_destroy(mdp->cmdq_clt[i]);
 	scp_put(mdp->scp);
 err_destroy_clock_wq:
 	destroy_workqueue(mdp->clock_wq);
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
index d6484d17b09f..8c09e984fd01 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
@@ -77,6 +77,14 @@ enum mdp_pipe_id {
 	MDP_PIPE_MAX
 };
 
+/* MDP parallel pipe control */
+enum {
+	MDP_PP_USED_1 = 1,
+	MDP_PP_USED_2 = 2,
+};
+
+#define MDP_PP_MAX MDP_PP_USED_2
+
 struct mtk_mdp_driver_data {
 	const int mdp_plat_id;
 	const resource_size_t mdp_con_res;
@@ -91,6 +99,8 @@ struct mtk_mdp_driver_data {
 	const struct mdp_limit *def_limit;
 	const struct mdp_pipe_info *pipe_info;
 	unsigned int pipe_info_len;
+	const struct v4l2_rect *pp_criteria;
+	const u8 pp_used;
 };
 
 struct mdp_mm_subsys {
@@ -115,7 +125,7 @@ struct mdp_dev {
 	s32					vpu_count;
 	u32					id_count;
 	struct ida				mdp_ida;
-	struct cmdq_client			*cmdq_clt;
+	struct cmdq_client			*cmdq_clt[MDP_PP_MAX];
 	wait_queue_head_t			callback_wq;
 
 	struct v4l2_device			v4l2_dev;
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-m2m.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-m2m.c
index a298c1b15b9e..35a8b059bde5 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-m2m.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-m2m.c
@@ -87,6 +87,9 @@ static void mdp_m2m_device_run(void *priv)
 	dst_vb = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
 	mdp_set_dst_config(&param.outputs[0], frame, &dst_vb->vb2_buf);
 
+	if (mdp_check_pp_enable(ctx->mdp_dev, frame))
+		param.type = MDP_STREAM_TYPE_DUAL_BITBLT;
+
 	ret = mdp_vpu_process(&ctx->mdp_dev->vpu, &param);
 	if (ret) {
 		dev_err(&ctx->mdp_dev->pdev->dev,
@@ -101,6 +104,18 @@ static void mdp_m2m_device_run(void *priv)
 	task.cb_data = NULL;
 	task.mdp_ctx = ctx;
 
+	if (atomic_read(&ctx->mdp_dev->job_count)) {
+		ret = wait_event_timeout(ctx->mdp_dev->callback_wq,
+					 !atomic_read(&ctx->mdp_dev->job_count),
+					 2 * HZ);
+		if (ret == 0) {
+			dev_err(&ctx->mdp_dev->pdev->dev,
+				"%d jobs not yet done\n",
+				atomic_read(&ctx->mdp_dev->job_count));
+			goto worker_end;
+		}
+	}
+
 	ret = mdp_cmdq_send(ctx->mdp_dev, &task);
 	if (ret) {
 		dev_err(&ctx->mdp_dev->pdev->dev,
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-regs.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-regs.c
index 9b436b911d92..657356f87743 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-regs.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-regs.c
@@ -304,6 +304,24 @@ int mdp_check_scaling_ratio(const struct v4l2_rect *crop,
 	return 0;
 }
 
+bool mdp_check_pp_enable(struct mdp_dev *mdp, struct mdp_frame *frame)
+{
+	u32 s, r1, r2;
+
+	if (!mdp || !frame)
+		return false;
+
+	if (!mdp->mdp_data->pp_criteria)
+		return false;
+
+	s = mdp->mdp_data->pp_criteria->width *
+		mdp->mdp_data->pp_criteria->height;
+	r1 = frame->crop.c.width * frame->crop.c.height;
+	r2 = frame->compose.width * frame->compose.height;
+
+	return (r1 >= s || r2 >= s);
+}
+
 /* Stride that is accepted by MDP HW */
 static u32 mdp_fmt_get_stride(const struct mdp_format *fmt,
 			      u32 bytesperline, unsigned int plane)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-regs.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-regs.h
index e9ab8ac2c0e8..b0c8f9f00820 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-regs.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-regs.h
@@ -368,6 +368,7 @@ int mdp_try_crop(struct mdp_m2m_ctx *ctx, struct v4l2_rect *r,
 int mdp_check_scaling_ratio(const struct v4l2_rect *crop,
 			    const struct v4l2_rect *compose, s32 rotation,
 	const struct mdp_limit *limit);
+bool mdp_check_pp_enable(struct mdp_dev *mdp, struct mdp_frame *frame);
 void mdp_set_src_config(struct img_input *in,
 			struct mdp_frame *frame, struct vb2_buffer *vb);
 void mdp_set_dst_config(struct img_output *out,
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-vpu.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-vpu.c
index 49fc2e9d45dd..da3a892ad867 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-vpu.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-vpu.c
@@ -198,6 +198,7 @@ int mdp_vpu_dev_init(struct mdp_vpu_dev *vpu, struct mtk_scp *scp,
 	};
 	struct mdp_dev *mdp = vpu_to_mdp(vpu);
 	int err;
+	u8 pp_num = mdp->mdp_data->pp_used;
 
 	init_completion(&vpu->ipi_acked);
 	vpu->scp = scp;
@@ -211,7 +212,7 @@ int mdp_vpu_dev_init(struct mdp_vpu_dev *vpu, struct mtk_scp *scp,
 	mutex_lock(vpu->lock);
 	vpu->work_size = ALIGN(vpu->work_size, 64);
 	vpu->param_size = ALIGN(sizeof(struct img_ipi_frameparam), 64);
-	vpu->config_size = ALIGN(sizeof(struct img_config), 64);
+	vpu->config_size = ALIGN(sizeof(struct img_config) * pp_num, 64);
 	err = mdp_vpu_shared_mem_alloc(vpu);
 	mutex_unlock(vpu->lock);
 	if (err) {
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:36 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:36 +0800
Subject: [PATCH v9 10/12] media: platform: mtk-mdp3: add mt8195 shared memory configurations
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-11-moudy.ho@mediatek.com>

The configuration of the MT8195 components in the shared memory
is defined in the header file "mdp_sm_mt8195.h".

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mdp_sm_mt8195.h    | 283 ++++++++++++++++++
 .../platform/mediatek/mdp3/mtk-img-ipi.h      |   3 +
 2 files changed, 286 insertions(+)
 create mode 100644 drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h

diff --git a/drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h b/drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h
new file mode 100644
index 000000000000..b09f48222d24
--- /dev/null
+++ b/drivers/media/platform/mediatek/mdp3/mdp_sm_mt8195.h
@@ -0,0 +1,283 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ * Author: Ping-Hsun Wu <ping-hsun.wu at mediatek.com>
+ */
+
+#ifndef __MDP_SM_MT8195_H__
+#define __MDP_SM_MT8195_H__
+
+#include "mtk-mdp3-type.h"
+
+/*
+ * ISP-MDP generic output information
+ * MD5 of the target SCP prebuild:
+ *     a49ec487e458b5971880f1b63dc2a9d5
+ */
+
+#define IMG_MAX_SUBFRAMES_8195	20
+
+struct img_comp_frame_8195 {
+	u32 output_disable;
+	u32 bypass;
+	u32 in_width;
+	u32 in_height;
+	u32 out_width;
+	u32 out_height;
+	struct img_crop crop;
+	u32 in_total_width;
+	u32 out_total_width;
+} __packed;
+
+struct img_comp_subfrm_8195 {
+	u32 tile_disable;
+	struct img_region in;
+	struct img_region out;
+	struct img_offset luma;
+	struct img_offset chroma;
+	s32 out_vertical; /* Output vertical index */
+	s32 out_horizontal; /* Output horizontal index */
+} __packed;
+
+struct mdp_rdma_subfrm_8195 {
+	u32 offset[IMG_MAX_PLANES];
+	u32 offset_0_p;
+	u32 src;
+	u32 clip;
+	u32 clip_ofst;
+	u32 in_tile_xleft;
+	u32 in_tile_ytop;
+} __packed;
+
+struct mdp_rdma_data_8195 {
+	u32 src_ctrl;
+	u32 comp_ctrl;
+	u32 control;
+	u32 iova[IMG_MAX_PLANES];
+	u32 iova_end[IMG_MAX_PLANES];
+	u32 mf_bkgd;
+	u32 mf_bkgd_in_pxl;
+	u32 sf_bkgd;
+	u32 ufo_dec_y;
+	u32 ufo_dec_c;
+	u32 transform;
+	u32 dmabuf_con0;
+	u32 ultra_th_high_con0;
+	u32 ultra_th_low_con0;
+	u32 dmabuf_con1;
+	u32 ultra_th_high_con1;
+	u32 ultra_th_low_con1;
+	u32 dmabuf_con2;
+	u32 ultra_th_high_con2;
+	u32 ultra_th_low_con2;
+	u32 dmabuf_con3;
+	struct mdp_rdma_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_fg_subfrm_8195 {
+	u32 info_0;
+	u32 info_1;
+} __packed;
+
+struct mdp_fg_data_8195 {
+	u32 ctrl_0;
+	u32 ck_en;
+	struct mdp_fg_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_hdr_subfrm_8195 {
+	u32 win_size;
+	u32 src;
+	u32 clip_ofst0;
+	u32 clip_ofst1;
+	u32 hist_ctrl_0;
+	u32 hist_ctrl_1;
+	u32 hdr_top;
+	u32 hist_addr;
+} __packed;
+
+struct mdp_hdr_data_8195 {
+	u32 top;
+	u32 relay;
+	struct mdp_hdr_subfrm_8195   subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_aal_subfrm_8195 {
+	u32 src;
+	u32 clip;
+	u32 clip_ofst;
+} __packed;
+
+struct mdp_aal_data_8195 {
+	u32 cfg_main;
+	u32 cfg;
+	struct mdp_aal_subfrm_8195   subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_rsz_subfrm_8195 {
+	u32 control2;
+	u32 src;
+	u32 clip;
+	u32 hdmirx_en;
+	u32 luma_h_int_ofst;
+	u32 luma_h_sub_ofst;
+	u32 luma_v_int_ofst;
+	u32 luma_v_sub_ofst;
+	u32 chroma_h_int_ofst;
+	u32 chroma_h_sub_ofst;
+	u32 rsz_switch;
+	u32 merge_cfg;
+} __packed;
+
+struct mdp_rsz_data_8195 {
+	u32 coeff_step_x;
+	u32 coeff_step_y;
+	u32 control1;
+	u32 control2;
+	u32 etc_control;
+	u32 prz_enable;
+	u32 ibse_softclip;
+	u32 tap_adapt;
+	u32 ibse_gaincontrol1;
+	u32 ibse_gaincontrol2;
+	u32 ibse_ylevel_1;
+	u32 ibse_ylevel_2;
+	u32 ibse_ylevel_3;
+	u32 ibse_ylevel_4;
+	u32 ibse_ylevel_5;
+	struct mdp_rsz_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_tdshp_subfrm_8195 {
+	u32 src;
+	u32 clip;
+	u32 clip_ofst;
+	u32 hist_cfg_0;
+	u32 hist_cfg_1;
+} __packed;
+
+struct mdp_tdshp_data_8195 {
+	u32 cfg;
+	struct mdp_tdshp_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_color_subfrm_8195 {
+	u32 in_hsize;
+	u32 in_vsize;
+} __packed;
+
+struct mdp_color_data_8195 {
+	u32 start;
+	struct mdp_color_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_ovl_subfrm_8195 {
+	u32 L0_src_size;
+	u32 roi_size;
+} __packed;
+
+struct mdp_ovl_data_8195 {
+	u32 L0_con;
+	u32 src_con;
+	struct mdp_ovl_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_pad_subfrm_8195 {
+	u32 pic_size;
+} __packed;
+
+struct mdp_pad_data_8195 {
+	struct mdp_pad_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_tcc_subfrm_8195 {
+	u32 pic_size;
+} __packed;
+
+struct mdp_tcc_data_8195 {
+	struct mdp_tcc_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_wrot_subfrm_8195 {
+	u32 offset[IMG_MAX_PLANES];
+	u32 src;
+	u32 clip;
+	u32 clip_ofst;
+	u32 main_buf;
+} __packed;
+
+struct mdp_wrot_data_8195 {
+	u32 iova[IMG_MAX_PLANES];
+	u32 control;
+	u32 stride[IMG_MAX_PLANES];
+	u32 mat_ctrl;
+	u32 fifo_test;
+	u32 filter;
+	u32 pre_ultra;
+	u32 framesize;
+	u32 afbc_yuvtrans;
+	u32 scan_10bit;
+	u32 pending_zero;
+	u32 bit_number;
+	u32 pvric;
+	u32 vpp02vpp1;
+	struct mdp_wrot_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct mdp_wdma_subfrm_8195 {
+	u32 offset[IMG_MAX_PLANES];
+	u32 src;
+	u32 clip;
+	u32 clip_ofst;
+} __packed;
+
+struct mdp_wdma_data_8195 {
+	u32 wdma_cfg;
+	u32 iova[IMG_MAX_PLANES];
+	u32 w_in_byte;
+	u32 uv_stride;
+	struct mdp_wdma_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct isp_data_8195 {
+	u64 dl_flags; /* 1 << (enum mdp_comp_type) */
+	u32 smxi_iova[4];
+	u32 cq_idx;
+	u32 cq_iova;
+	u32 tpipe_iova[IMG_MAX_SUBFRAMES_8195];
+} __packed;
+
+struct img_compparam_8195 {
+	u32 type; /* enum mdp_comp_id */
+	u32 id; /* engine alias_id */
+	u32 input;
+	u32 outputs[IMG_MAX_HW_OUTPUTS];
+	u32 num_outputs;
+	struct img_comp_frame_8195 frame;
+	struct img_comp_subfrm_8195 subfrms[IMG_MAX_SUBFRAMES_8195];
+	u32 num_subfrms;
+	union {
+		struct mdp_rdma_data_8195 rdma;
+		struct mdp_fg_data_8195 fg;
+		struct mdp_hdr_data_8195 hdr;
+		struct mdp_aal_data_8195 aal;
+		struct mdp_rsz_data_8195 rsz;
+		struct mdp_tdshp_data_8195 tdshp;
+		struct mdp_color_data_8195 color;
+		struct mdp_ovl_data_8195 ovl;
+		struct mdp_pad_data_8195 pad;
+		struct mdp_tcc_data_8195 tcc;
+		struct mdp_wrot_data_8195 wrot;
+		struct mdp_wdma_data_8195 wdma;
+		struct isp_data_8195 isp;
+	};
+} __packed;
+
+struct img_config_8195 {
+	struct img_compparam_8195 components[IMG_MAX_COMPONENTS];
+	u32 num_components;
+	struct img_mmsys_ctrl ctrls[IMG_MAX_SUBFRAMES_8195];
+	u32 num_subfrms;
+} __packed;
+
+#endif  /* __MDP_SM_MT8195_H__ */
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h b/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h
index 08fb0853bcd5..f83ac408306e 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h
@@ -10,6 +10,7 @@
 
 #include <linux/err.h>
 #include "mdp_sm_mt8183.h"
+#include "mdp_sm_mt8195.h"
 #include "mtk-mdp3-type.h"
 
 /* ISP-MDP generic input information */
@@ -138,12 +139,14 @@ struct img_frameparam {
 struct img_config {
 	union {
 		struct img_config_8183 config_8183;
+		struct img_config_8195 config_8195;
 	};
 } __packed;
 
 struct img_compparam {
 	union {
 		struct img_compparam_8183 comp_8183;
+		struct img_compparam_8195 comp_8195;
 	};
 } __packed;
 
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:34 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:34 +0800
Subject: [PATCH v9 08/12] media: platform: mtk-mdp3: add support for blending multiple components
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-9-moudy.ho@mediatek.com>

Certain chips can combine several components to form complex virtual
units with advanced functions.
These components require simultaneous configuration of their MODs and
clocks.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mtk-mdp3-cmdq.c    | 10 ++++++-
 .../platform/mediatek/mdp3/mtk-mdp3-comp.c    | 29 +++++++++++++++++--
 .../platform/mediatek/mdp3/mtk-mdp3-comp.h    |  7 +++++
 3 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index a81caf5f472c..f0c5f5abeb23 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -110,17 +110,25 @@ static int mdp_path_subfrm_require(const struct mdp_path *path,
 	/* Set mutex mod */
 	for (index = 0; index < num_comp; index++) {
 		s32 inner_id = MDP_COMP_NONE;
+		const u32 *mutex_idx;
+		const struct mdp_comp_blend *b;
 
 		if (CFG_CHECK(MT8183, p_id))
 			inner_id = CFG_GET(MT8183, path->config, components[index].type);
 		if (mdp_cfg_comp_is_dummy(path->mdp_dev, inner_id))
 			continue;
+
 		ctx = &path->comps[index];
 		if (is_output_disabled(p_id, ctx->param, count))
 			continue;
+
+		mutex_idx = data->mdp_mutex_table_idx;
 		id = ctx->comp->public_id;
-		mtk_mutex_write_mod(mutex, data->mdp_mutex_table_idx[id], false);
+		mtk_mutex_write_mod(mutex, mutex_idx[id], false);
 
+		b = &data->comp_data[id].blend;
+		if (b && b->aid_mod)
+			mtk_mutex_write_mod(mutex, mutex_idx[b->b_id], false);
 	}
 
 	mtk_mutex_write_sof(mutex, MUTEX_SOF_IDX_SINGLE_MODE);
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
index ed6092e1666f..e97630b7867c 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c
@@ -864,12 +864,26 @@ int mdp_comp_clocks_on(struct device *dev, struct mdp_comp *comps, int num)
 	int i, ret;
 
 	for (i = 0; i < num; i++) {
+		struct mdp_dev *m = comps[i].mdp_dev;
+		enum mtk_mdp_comp_id id;
+		const struct mdp_comp_blend *b;
+
 		/* Bypass the dummy component*/
-		if (!comps[i].mdp_dev)
+		if (!m)
 			continue;
+
 		ret = mdp_comp_clock_on(dev, &comps[i]);
 		if (ret)
 			return ret;
+
+		id = comps[i].public_id;
+		b = &m->mdp_data->comp_data[id].blend;
+
+		if (b && b->aid_clk) {
+			ret = mdp_comp_clock_on(dev, m->comp[b->b_id]);
+			if (ret)
+				return ret;
+		}
 	}
 
 	return 0;
@@ -880,10 +894,21 @@ void mdp_comp_clocks_off(struct device *dev, struct mdp_comp *comps, int num)
 	int i;
 
 	for (i = 0; i < num; i++) {
+		struct mdp_dev *m = comps[i].mdp_dev;
+		enum mtk_mdp_comp_id id;
+		const struct mdp_comp_blend *b;
+
 		/* Bypass the dummy component*/
-		if (!comps[i].mdp_dev)
+		if (!m)
 			continue;
+
 		mdp_comp_clock_off(dev, &comps[i]);
+
+		id = comps[i].public_id;
+		b = &m->mdp_data->comp_data[id].blend;
+
+		if (b && b->aid_clk)
+			mdp_comp_clock_off(dev, m->comp[b->b_id]);
 	}
 }
 
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h
index e6cbc6ab6bae..3e5d2da1c807 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h
@@ -201,9 +201,16 @@ struct mdp_comp_info {
 	u32 dts_reg_ofst;
 };
 
+struct mdp_comp_blend {
+	enum mtk_mdp_comp_id b_id;
+	bool aid_mod;
+	bool aid_clk;
+};
+
 struct mdp_comp_data {
 	struct mdp_comp_match match;
 	struct mdp_comp_info info;
+	struct mdp_comp_blend blend;
 };
 
 struct mdp_comp_ops;
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:29 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:29 +0800
Subject: [PATCH v9 03/12] media: platform: mtk-mdp3: introduce more pipelines from MT8195
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-4-moudy.ho@mediatek.com>

Increasing the number of sets built by MMSYS and MUTEX in MT8195
will enable the creation of more pipelines in MDP3.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mtk-mdp3-cmdq.c    | 80 ++++++++++++-------
 .../platform/mediatek/mdp3/mtk-mdp3-core.h    |  7 ++
 2 files changed, 60 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 67c8fcc3eda9..31930ddbc828 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -50,6 +50,43 @@ static struct mtk_mutex *__get_mutex(const struct mdp_dev *mdp_dev,
 	return mdp_dev->mm_subsys[p->sub_id].mdp_mutex[p->mutex_id];
 }
 
+static enum mdp_pipe_id __get_pipe(const struct mdp_dev *mdp_dev,
+				   enum mtk_mdp_comp_id id)
+{
+	enum mdp_pipe_id pipe_id;
+
+	switch (id) {
+	case MDP_COMP_RDMA0:
+		pipe_id = MDP_PIPE_RDMA0;
+		break;
+	case MDP_COMP_ISP_IMGI:
+		pipe_id = MDP_PIPE_IMGI;
+		break;
+	case MDP_COMP_WPEI:
+		pipe_id = MDP_PIPE_WPEI;
+		break;
+	case MDP_COMP_WPEI2:
+		pipe_id = MDP_PIPE_WPEI2;
+		break;
+	case MDP_COMP_RDMA1:
+		pipe_id = MDP_PIPE_RDMA1;
+		break;
+	case MDP_COMP_RDMA2:
+		pipe_id = MDP_PIPE_RDMA2;
+		break;
+	case MDP_COMP_RDMA3:
+		pipe_id = MDP_PIPE_RDMA3;
+		break;
+	default:
+		/* Avoid exceptions when operating MUTEX */
+		pipe_id = MDP_PIPE_RDMA0;
+		dev_err(&mdp_dev->pdev->dev, "Unknown pipeline id %d", id);
+		break;
+	}
+
+	return pipe_id;
+}
+
 static int mdp_path_subfrm_require(const struct mdp_path *path,
 				   struct mdp_cmdq_cmd *cmd,
 				   struct mdp_pipe_info *p, u32 count)
@@ -57,7 +94,6 @@ static int mdp_path_subfrm_require(const struct mdp_path *path,
 	const int p_id = path->mdp_dev->mdp_data->mdp_plat_id;
 	const struct mdp_comp_ctx *ctx;
 	const struct mtk_mdp_driver_data *data = path->mdp_dev->mdp_data;
-	struct device *dev = &path->mdp_dev->pdev->dev;
 	struct mtk_mutex *mutex;
 	int id, index;
 	u32 num_comp = 0;
@@ -66,23 +102,7 @@ static int mdp_path_subfrm_require(const struct mdp_path *path,
 		num_comp = CFG_GET(MT8183, path->config, num_components);
 
 	/* Decide which mutex to use based on the current pipeline */
-	switch (path->comps[0].comp->public_id) {
-	case MDP_COMP_RDMA0:
-		index = MDP_PIPE_RDMA0;
-		break;
-	case MDP_COMP_ISP_IMGI:
-		index = MDP_PIPE_IMGI;
-		break;
-	case MDP_COMP_WPEI:
-		index = MDP_PIPE_WPEI;
-		break;
-	case MDP_COMP_WPEI2:
-		index = MDP_PIPE_WPEI2;
-		break;
-	default:
-		dev_err(dev, "Unknown pipeline and no mutex is assigned");
-		return -EINVAL;
-	}
+	index = __get_pipe(path->mdp_dev, path->comps[0].comp->public_id);
 	memcpy(p, &data->pipe_info[index], sizeof(struct mdp_pipe_info));
 	mutex = __get_mutex(path->mdp_dev, p);
 
@@ -336,11 +356,13 @@ static void mdp_auto_release_work(struct work_struct *work)
 	struct mdp_cmdq_cmd *cmd;
 	struct mdp_dev *mdp;
 	struct mtk_mutex *mutex;
+	enum mdp_pipe_id pipe_id;
 
 	cmd = container_of(work, struct mdp_cmdq_cmd, auto_release_work);
 	mdp = cmd->mdp;
 
-	mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0]);
+	pipe_id = __get_pipe(mdp, cmd->comps[0].public_id);
+	mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[pipe_id]);
 	mtk_mutex_unprepare(mutex);
 	mdp_comp_clocks_off(&mdp->pdev->dev, cmd->comps,
 			    cmd->num_comps);
@@ -361,6 +383,7 @@ static void mdp_handle_cmdq_callback(struct mbox_client *cl, void *mssg)
 	struct cmdq_cb_data *data;
 	struct mdp_dev *mdp;
 	struct device *dev;
+	enum mdp_pipe_id pipe_id;
 
 	if (!mssg) {
 		pr_info("%s:no callback data\n", __func__);
@@ -388,7 +411,8 @@ static void mdp_handle_cmdq_callback(struct mbox_client *cl, void *mssg)
 		struct mtk_mutex *mutex;
 
 		dev_err(dev, "%s:queue_work fail!\n", __func__);
-		mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0]);
+		pipe_id = __get_pipe(mdp, cmd->comps[0].public_id);
+		mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[pipe_id]);
 		mtk_mutex_unprepare(mutex);
 		mdp_comp_clocks_off(&mdp->pdev->dev, cmd->comps,
 				    cmd->num_comps);
@@ -412,6 +436,7 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 	struct device *dev = &mdp->pdev->dev;
 	const int p_id = mdp->mdp_data->mdp_plat_id;
 	struct mtk_mutex *mutex = NULL;
+	enum mdp_pipe_id pipe_id;
 	int i, ret;
 	u32 num_comp = 0;
 
@@ -449,13 +474,6 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 		goto err_free_comps;
 	}
 
-	mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0]);
-	ret = mtk_mutex_prepare(mutex);
-	if (ret) {
-		dev_err(dev, "Fail to enable mutex clk\n");
-		goto err_free_path;
-	}
-
 	path->mdp_dev = mdp;
 	path->config = param->config;
 	path->param = param->param;
@@ -475,6 +493,14 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 		goto err_free_path;
 	}
 
+	pipe_id = __get_pipe(mdp, path->comps[0].comp->public_id);
+	mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[pipe_id]);
+	ret = mtk_mutex_prepare(mutex);
+	if (ret) {
+		dev_err(dev, "Fail to enable mutex clk\n");
+		goto err_free_path;
+	}
+
 	ret = mdp_path_config(mdp, cmd, path);
 	if (ret) {
 		dev_err(dev, "mdp_path_config error\n");
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
index fde2c0b95def..ece6509666fd 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
@@ -59,6 +59,13 @@ enum mdp_pipe_id {
 	MDP_PIPE_WPEI2,
 	MDP_PIPE_IMGI,
 	MDP_PIPE_RDMA0,
+	MDP_PIPE_RDMA1,
+	MDP_PIPE_RDMA2,
+	MDP_PIPE_RDMA3,
+	MDP_PIPE_SPLIT,
+	MDP_PIPE_SPLIT2,
+	MDP_PIPE_VPP0_SOUT,
+	MDP_PIPE_VPP1_SOUT,
 	MDP_PIPE_MAX
 };
 
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:18:27 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:27 +0800
Subject: [PATCH v9 01/12] media: platform: mtk-mdp3: add support second sets of MMSYS
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-2-moudy.ho@mediatek.com>

The MT8195 chipset features two MMSYS subsets: VPPSYS0 and VPPSYS1.
These subsets coordinate and control the clock, power, and
register settings required for the components of MDP3.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mdp_cfg_data.c     | 44 ++++++-------
 .../platform/mediatek/mdp3/mtk-mdp3-comp.h    |  1 +
 .../platform/mediatek/mdp3/mtk-mdp3-core.c    | 61 ++++++++++++++++---
 .../platform/mediatek/mdp3/mtk-mdp3-core.h    | 18 +++++-
 4 files changed, 92 insertions(+), 32 deletions(-)

diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index 502eeae0bfdc..fcc582292b77 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -73,75 +73,75 @@ static const u32 mt8183_mutex_idx[MDP_MAX_COMP_COUNT] = {
 
 static const struct mdp_comp_data mt8183_mdp_comp_data[MDP_MAX_COMP_COUNT] = {
 	[MDP_COMP_WPEI] = {
-		{MDP_COMP_TYPE_WPEI, 0, MT8183_MDP_COMP_WPEI},
+		{MDP_COMP_TYPE_WPEI, 0, MT8183_MDP_COMP_WPEI, MDP_MM_SUBSYS_0},
 		{0, 0, 0}
 	},
 	[MDP_COMP_WPEO] = {
-		{MDP_COMP_TYPE_EXTO, 2, MT8183_MDP_COMP_WPEO},
+		{MDP_COMP_TYPE_EXTO, 2, MT8183_MDP_COMP_WPEO, MDP_MM_SUBSYS_0},
 		{0, 0, 0}
 	},
 	[MDP_COMP_WPEI2] = {
-		{MDP_COMP_TYPE_WPEI, 1, MT8183_MDP_COMP_WPEI2},
+		{MDP_COMP_TYPE_WPEI, 1, MT8183_MDP_COMP_WPEI2, MDP_MM_SUBSYS_0},
 		{0, 0, 0}
 	},
 	[MDP_COMP_WPEO2] = {
-		{MDP_COMP_TYPE_EXTO, 3, MT8183_MDP_COMP_WPEO2},
+		{MDP_COMP_TYPE_EXTO, 3, MT8183_MDP_COMP_WPEO2, MDP_MM_SUBSYS_0},
 		{0, 0, 0}
 	},
 	[MDP_COMP_ISP_IMGI] = {
-		{MDP_COMP_TYPE_IMGI, 0, MT8183_MDP_COMP_ISP_IMGI},
+		{MDP_COMP_TYPE_IMGI, 0, MT8183_MDP_COMP_ISP_IMGI, MDP_MM_SUBSYS_0},
 		{0, 0, 4}
 	},
 	[MDP_COMP_ISP_IMGO] = {
-		{MDP_COMP_TYPE_EXTO, 0, MT8183_MDP_COMP_ISP_IMGO},
+		{MDP_COMP_TYPE_EXTO, 0, MT8183_MDP_COMP_ISP_IMGO, MDP_MM_SUBSYS_0},
 		{0, 0, 4}
 	},
 	[MDP_COMP_ISP_IMG2O] = {
-		{MDP_COMP_TYPE_EXTO, 1, MT8183_MDP_COMP_ISP_IMG2O},
+		{MDP_COMP_TYPE_EXTO, 1, MT8183_MDP_COMP_ISP_IMG2O, MDP_MM_SUBSYS_0},
 		{0, 0, 0}
 	},
 	[MDP_COMP_CAMIN] = {
-		{MDP_COMP_TYPE_DL_PATH, 0, MT8183_MDP_COMP_CAMIN},
+		{MDP_COMP_TYPE_DL_PATH, 0, MT8183_MDP_COMP_CAMIN, MDP_MM_SUBSYS_0},
 		{2, 2, 1}
 	},
 	[MDP_COMP_CAMIN2] = {
-		{MDP_COMP_TYPE_DL_PATH, 1, MT8183_MDP_COMP_CAMIN2},
+		{MDP_COMP_TYPE_DL_PATH, 1, MT8183_MDP_COMP_CAMIN2, MDP_MM_SUBSYS_0},
 		{2, 4, 1}
 	},
 	[MDP_COMP_RDMA0] = {
-		{MDP_COMP_TYPE_RDMA, 0, MT8183_MDP_COMP_RDMA0},
+		{MDP_COMP_TYPE_RDMA, 0, MT8183_MDP_COMP_RDMA0, MDP_MM_SUBSYS_0},
 		{2, 0, 0}
 	},
 	[MDP_COMP_CCORR0] = {
-		{MDP_COMP_TYPE_CCORR, 0, MT8183_MDP_COMP_CCORR0},
+		{MDP_COMP_TYPE_CCORR, 0, MT8183_MDP_COMP_CCORR0, MDP_MM_SUBSYS_0},
 		{1, 0, 0}
 	},
 	[MDP_COMP_RSZ0] = {
-		{MDP_COMP_TYPE_RSZ, 0, MT8183_MDP_COMP_RSZ0},
+		{MDP_COMP_TYPE_RSZ, 0, MT8183_MDP_COMP_RSZ0, MDP_MM_SUBSYS_0},
 		{1, 0, 0}
 	},
 	[MDP_COMP_RSZ1] = {
-		{MDP_COMP_TYPE_RSZ, 1, MT8183_MDP_COMP_RSZ1},
+		{MDP_COMP_TYPE_RSZ, 1, MT8183_MDP_COMP_RSZ1, MDP_MM_SUBSYS_0},
 		{1, 0, 0}
 	},
 	[MDP_COMP_TDSHP0] = {
-		{MDP_COMP_TYPE_TDSHP, 0, MT8183_MDP_COMP_TDSHP0},
+		{MDP_COMP_TYPE_TDSHP, 0, MT8183_MDP_COMP_TDSHP0, MDP_MM_SUBSYS_0},
 		{0, 0, 0}
 	},
 	[MDP_COMP_PATH0_SOUT] = {
-		{MDP_COMP_TYPE_PATH, 0, MT8183_MDP_COMP_PATH0_SOUT},
+		{MDP_COMP_TYPE_PATH, 0, MT8183_MDP_COMP_PATH0_SOUT, MDP_MM_SUBSYS_0},
 		{0, 0, 0}
 	},
 	[MDP_COMP_PATH1_SOUT] = {
-		{MDP_COMP_TYPE_PATH, 1, MT8183_MDP_COMP_PATH1_SOUT},
+		{MDP_COMP_TYPE_PATH, 1, MT8183_MDP_COMP_PATH1_SOUT, MDP_MM_SUBSYS_0},
 		{0, 0, 0}
 	},
 	[MDP_COMP_WROT0] = {
-		{MDP_COMP_TYPE_WROT, 0, MT8183_MDP_COMP_WROT0},
+		{MDP_COMP_TYPE_WROT, 0, MT8183_MDP_COMP_WROT0, MDP_MM_SUBSYS_0},
 		{1, 0, 0}
 	},
 	[MDP_COMP_WDMA] = {
-		{MDP_COMP_TYPE_WDMA, 0, MT8183_MDP_COMP_WDMA},
+		{MDP_COMP_TYPE_WDMA, 0, MT8183_MDP_COMP_WDMA, MDP_MM_SUBSYS_0},
 		{1, 0, 0}
 	},
 };
@@ -402,10 +402,10 @@ static const struct mdp_limit mt8183_mdp_def_limit = {
 };
 
 static const struct mdp_pipe_info mt8183_pipe_info[] = {
-	[MDP_PIPE_WPEI] = {MDP_PIPE_WPEI, 0},
-	[MDP_PIPE_WPEI2] = {MDP_PIPE_WPEI2, 1},
-	[MDP_PIPE_IMGI] = {MDP_PIPE_IMGI, 2},
-	[MDP_PIPE_RDMA0] = {MDP_PIPE_RDMA0, 3}
+	[MDP_PIPE_WPEI] = {MDP_PIPE_WPEI, MDP_MM_SUBSYS_0, 0},
+	[MDP_PIPE_WPEI2] = {MDP_PIPE_WPEI2, MDP_MM_SUBSYS_0, 1},
+	[MDP_PIPE_IMGI] = {MDP_PIPE_IMGI, MDP_MM_SUBSYS_0, 2},
+	[MDP_PIPE_RDMA0] = {MDP_PIPE_RDMA0, MDP_MM_SUBSYS_0, 3}
 };
 
 const struct mtk_mdp_driver_data mt8183_mdp_driver_data = {
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h
index 20d2bcb77ef9..e89c51e1edb7 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.h
@@ -138,6 +138,7 @@ struct mdp_comp_match {
 	enum mdp_comp_type type;
 	u32 alias_id;
 	s32 inner_id;
+	s32 subsys_id;
 };
 
 /* Used to describe the item order in MDP property */
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
index 94f4ed78523b..8cd0f11fc290 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
@@ -26,9 +26,10 @@ static const struct of_device_id mdp_of_ids[] = {
 MODULE_DEVICE_TABLE(of, mdp_of_ids);
 
 static struct platform_device *__get_pdev_by_id(struct platform_device *pdev,
+						struct platform_device *from,
 						enum mdp_infra_id id)
 {
-	struct device_node *node;
+	struct device_node *node, *f = NULL;
 	struct platform_device *mdp_pdev = NULL;
 	const struct mtk_mdp_driver_data *mdp_data;
 	const char *compat;
@@ -46,9 +47,14 @@ static struct platform_device *__get_pdev_by_id(struct platform_device *pdev,
 		dev_err(&pdev->dev, "have no driver data to find node\n");
 		return NULL;
 	}
+
 	compat = mdp_data->mdp_probe_infra[id].compatible;
+	if (strlen(compat) == 0)
+		return NULL;
 
-	node = of_find_compatible_node(NULL, NULL, compat);
+	if (from)
+		f = from->dev.of_node;
+	node = of_find_compatible_node(f, NULL, compat);
 	if (WARN_ON(!node)) {
 		dev_err(&pdev->dev, "find node from id %d failed\n", id);
 		return NULL;
@@ -148,6 +154,46 @@ void mdp_video_device_release(struct video_device *vdev)
 	kfree(mdp);
 }
 
+static int mdp_mm_subsys_deploy(struct mdp_dev *mdp, enum mdp_infra_id id)
+{
+	struct platform_device *mm_pdev = NULL;
+	struct device **dev;
+	int i;
+
+	if (!mdp)
+		return -EINVAL;
+
+	for (i = 0; i < MDP_MM_SUBSYS_MAX; i++) {
+		const char *compat;
+		enum mdp_infra_id sub_id = id + i;
+
+		switch (id) {
+		case MDP_INFRA_MMSYS:
+			dev = &mdp->mm_subsys[i].mmsys;
+			break;
+		default:
+			dev_err(&mdp->pdev->dev, "Unknown infra id %d", id);
+			return -EINVAL;
+		}
+
+		/*
+		 * Not every chip has multiple multimedia subsystems, so
+		 * the config may be null.
+		 */
+		compat = mdp->mdp_data->mdp_probe_infra[sub_id].compatible;
+		if (strlen(compat) == 0)
+			continue;
+
+		mm_pdev = __get_pdev_by_id(mdp->pdev, mm_pdev, sub_id);
+		if (WARN_ON(!mm_pdev))
+			return -ENODEV;
+
+		*dev = &mm_pdev->dev;
+	}
+
+	return 0;
+}
+
 static int mdp_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -164,14 +210,11 @@ static int mdp_probe(struct platform_device *pdev)
 	mdp->pdev = pdev;
 	mdp->mdp_data = of_device_get_match_data(&pdev->dev);
 
-	mm_pdev = __get_pdev_by_id(pdev, MDP_INFRA_MMSYS);
-	if (!mm_pdev) {
-		ret = -ENODEV;
+	ret = mdp_mm_subsys_deploy(mdp, MDP_INFRA_MMSYS);
+	if (ret)
 		goto err_destroy_device;
-	}
-	mdp->mdp_mmsys = &mm_pdev->dev;
 
-	mm_pdev = __get_pdev_by_id(pdev, MDP_INFRA_MUTEX);
+	mm_pdev = __get_pdev_by_id(pdev, NULL, MDP_INFRA_MUTEX);
 	if (WARN_ON(!mm_pdev)) {
 		ret = -ENODEV;
 		goto err_destroy_device;
@@ -210,7 +253,7 @@ static int mdp_probe(struct platform_device *pdev)
 
 	mdp->scp = scp_get(pdev);
 	if (!mdp->scp) {
-		mm_pdev = __get_pdev_by_id(pdev, MDP_INFRA_SCP);
+		mm_pdev = __get_pdev_by_id(pdev, NULL, MDP_INFRA_SCP);
 		if (WARN_ON(!mm_pdev)) {
 			dev_err(&pdev->dev, "Could not get scp device\n");
 			ret = -ENODEV;
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
index 7e21d226ceb8..7a7cdd0ce968 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
@@ -19,12 +19,23 @@
 #define MDP_PHANDLE_NAME	"mediatek,mdp3"
 
 enum mdp_infra_id {
+	/*
+	 * Due to the sequential nature of function "mdp_mm_subsys_deploy",
+	 * adding new enum. necessitates careful consideration.
+	 */
 	MDP_INFRA_MMSYS,
+	MDP_INFRA_MMSYS2,
 	MDP_INFRA_MUTEX,
 	MDP_INFRA_SCP,
 	MDP_INFRA_MAX
 };
 
+enum mdp_mm_subsys_id {
+	MDP_MM_SUBSYS_0,
+	MDP_MM_SUBSYS_1,
+	MDP_MM_SUBSYS_MAX,
+};
+
 enum mdp_buffer_usage {
 	MDP_BUFFER_USAGE_HW_READ,
 	MDP_BUFFER_USAGE_MDP,
@@ -65,9 +76,13 @@ struct mtk_mdp_driver_data {
 	unsigned int pipe_info_len;
 };
 
+struct mdp_mm_subsys {
+	struct device *mmsys;
+};
+
 struct mdp_dev {
 	struct platform_device			*pdev;
-	struct device				*mdp_mmsys;
+	struct mdp_mm_subsys			mm_subsys[MDP_MM_SUBSYS_MAX];
 	struct mtk_mutex			*mdp_mutex[MDP_PIPE_MAX];
 	struct mdp_comp				*comp[MDP_MAX_COMP_COUNT];
 	const struct mtk_mdp_driver_data	*mdp_data;
@@ -96,6 +111,7 @@ struct mdp_dev {
 
 struct mdp_pipe_info {
 	enum mdp_pipe_id pipe_id;
+	enum mdp_mm_subsys_id sub_id;
 	u32 mutex_id;
 };
 
-- 
2.18.0



From moudy.ho at mediatek.com  Wed Dec 20 02:08:38 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:08:38 +0800
Subject: [PATCH v10 01/16] dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with generic names
In-Reply-To: <20231220100853.20616-1-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
Message-ID: <20231220100853.20616-2-moudy.ho@mediatek.com>

The DMA-related nodes RDMA/WROT in MDP3 should be changed to generic names.
In addition, fix improper space indent in example.

Fixes: 4ad7b39623ab ("media: dt-binding: mediatek: add bindings for MediaTek MDP3 components")
Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../bindings/media/mediatek,mdp3-rdma.yaml    | 29 +++++++++++--------
 .../bindings/media/mediatek,mdp3-wrot.yaml    | 23 +++++++++------
 2 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index 59dcea797b71..e1ffe7eb2cdf 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -69,6 +69,9 @@ properties:
       - description: used for 1st data pipe from RDMA
       - description: used for 2nd data pipe from RDMA
 
+  '#dma-cells':
+    const: 1
+
 required:
   - compatible
   - reg
@@ -78,6 +81,7 @@ required:
   - clocks
   - iommus
   - mboxes
+  - '#dma-cells'
 
 additionalProperties: false
 
@@ -88,16 +92,17 @@ examples:
     #include <dt-bindings/power/mt8183-power.h>
     #include <dt-bindings/memory/mt8183-larb-port.h>
 
-    mdp3_rdma0: mdp3-rdma0 at 14001000 {
-      compatible = "mediatek,mt8183-mdp3-rdma";
-      reg = <0x14001000 0x1000>;
-      mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>;
-      mediatek,gce-events = <CMDQ_EVENT_MDP_RDMA0_SOF>,
-                            <CMDQ_EVENT_MDP_RDMA0_EOF>;
-      power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
-      clocks = <&mmsys CLK_MM_MDP_RDMA0>,
-               <&mmsys CLK_MM_MDP_RSZ1>;
-      iommus = <&iommu>;
-      mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
-               <&gce 21 CMDQ_THR_PRIO_LOWEST>;
+    dma-controller at 14001000 {
+        compatible = "mediatek,mt8183-mdp3-rdma";
+        reg = <0x14001000 0x1000>;
+        mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>;
+        mediatek,gce-events = <CMDQ_EVENT_MDP_RDMA0_SOF>,
+                              <CMDQ_EVENT_MDP_RDMA0_EOF>;
+        power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+        clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+                 <&mmsys CLK_MM_MDP_RSZ1>;
+        iommus = <&iommu>;
+        mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
+                 <&gce 21 CMDQ_THR_PRIO_LOWEST>;
+        #dma-cells = <1>;
     };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
index 0baa77198fa2..64ea98aa0592 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
@@ -50,6 +50,9 @@ properties:
   iommus:
     maxItems: 1
 
+  '#dma-cells':
+    const: 1
+
 required:
   - compatible
   - reg
@@ -58,6 +61,7 @@ required:
   - power-domains
   - clocks
   - iommus
+  - '#dma-cells'
 
 additionalProperties: false
 
@@ -68,13 +72,14 @@ examples:
     #include <dt-bindings/power/mt8183-power.h>
     #include <dt-bindings/memory/mt8183-larb-port.h>
 
-    mdp3_wrot0: mdp3-wrot0 at 14005000 {
-      compatible = "mediatek,mt8183-mdp3-wrot";
-      reg = <0x14005000 0x1000>;
-      mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x5000 0x1000>;
-      mediatek,gce-events = <CMDQ_EVENT_MDP_WROT0_SOF>,
-                            <CMDQ_EVENT_MDP_WROT0_EOF>;
-      power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
-      clocks = <&mmsys CLK_MM_MDP_WROT0>;
-      iommus = <&iommu>;
+    dma-controller at 14005000 {
+        compatible = "mediatek,mt8183-mdp3-wrot";
+        reg = <0x14005000 0x1000>;
+        mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x5000 0x1000>;
+        mediatek,gce-events = <CMDQ_EVENT_MDP_WROT0_SOF>,
+                              <CMDQ_EVENT_MDP_WROT0_EOF>;
+        power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+        clocks = <&mmsys CLK_MM_MDP_WROT0>;
+        iommus = <&iommu>;
+        #dma-cells = <1>;
     };
-- 
2.18.0



From angelogioacchino.delregno at collabora.com  Wed Dec 20 02:30:38 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 11:30:38 +0100
Subject: [PATCH v3 3/3] arm64: dts: mediatek: mt8195: Add 'rx-fifo-depth'
 for cherry
In-Reply-To: <20231220025842.7082-3-chunfeng.yun@mediatek.com>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
 <20231220025842.7082-3-chunfeng.yun@mediatek.com>
Message-ID: <d1767b1d-0b80-4ece-8a35-18eed52a3f6e@collabora.com>

Il 20/12/23 03:58, Chunfeng Yun ha scritto:
> Add the quirk property "rx-fifo-depth" to work around Gen1 isoc-in
> transfer issue which send out unexpected ACK even after device
> already finished the burst transfer with a short patcket, specially
> for a 4K camera device.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
> v3: change value according to binding
> v2: use 'rx-fifo-depth' property
> ---
>   arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> index dd5b89b73190..58593348b810 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> @@ -1185,6 +1185,7 @@
>   

Can you please place rx-fifo-depth before power supplies?

after which,

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>

Thanks,
Angelo

>   	vusb33-supply = <&mt6359_vusb_ldo_reg>;
>   	vbus-supply = <&usb_vbus>;
> +	rx-fifo-depth = <3>;
>   };
>   
>   &xhci1 {
> @@ -1192,6 +1193,7 @@
>   
>   	vusb33-supply = <&mt6359_vusb_ldo_reg>;
>   	vbus-supply = <&usb_vbus>;
> +	rx-fifo-depth = <3>;
>   };
>   
>   &xhci2 {




From angelogioacchino.delregno at collabora.com  Wed Dec 20 02:30:40 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 11:30:40 +0100
Subject: [PATCH v3 2/3] usb: xhci-mtk: fix a short packet issue of gen1
 isoc-in transfer
In-Reply-To: <20231220025842.7082-2-chunfeng.yun@mediatek.com>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
 <20231220025842.7082-2-chunfeng.yun@mediatek.com>
Message-ID: <9ebfe163-c86a-4aca-8f60-179a218821b4@collabora.com>

Il 20/12/23 03:58, Chunfeng Yun ha scritto:
> For Gen1 isoc-in transfer, host still send out unexpected ACK after device
> finish the burst with a short packet, this will cause an exception on the
> connected device, such as, a usb 4k camera.
> It can be fixed by setting rxfifo depth less than 4k bytes, prefer to use
> 3k here, the side-effect is that may cause performance drop about 10%,
> including bulk transfer.
> 
> Fixes: 926d60ae64a6 ("usb: xhci-mtk: modify the SOF/ITP interval for mt8195")
> Cc: stable at vger.kernel.org
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From andyshrk at 163.com  Wed Dec 20 02:33:34 2023
From: andyshrk at 163.com (Andy Yan)
Date: Wed, 20 Dec 2023 18:33:34 +0800
Subject: [PATCH] Revert "ARM: dts: rockchip: restyle emac nodes"
Message-ID: <20231220103334.2665543-1-andyshrk@163.com>

From: Andy Yan <andy.yan at rock-chips.com>

When try to run rk3036 kylin board with mainline,
I found the emac ethernet probe failed:

[    2.324583] loop: module loaded
[    2.328435] SPI driver spidev has no spi_device_id for rockchip,spidev
[    2.338688] tun: Universal TUN/TAP device driver, 1.6
[    2.345397] rockchip_emac 10200000.ethernet: no regulator found
[    2.351892] rockchip_emac 10200000.ethernet: ARC EMAC detected with id: 0x7fd02
[    2.359331] rockchip_emac 10200000.ethernet: IRQ is 43
[    2.364719] rockchip_emac 10200000.ethernet: MAC address is now e6:58:d6:ec:d9:7c
[    2.396993] mdio_bus Synopsys MII Bus: mdio has invalid PHY address
[    2.403306] mdio_bus Synopsys MII Bus: scan phy mdio at address 0
[    2.508656] rockchip_emac 10200000.ethernet: of_phy_connect() failed
[    2.516334] rockchip_emac 10200000.ethernet: failed to probe arc emac (-19)

This reverts commit 1dabb74971b3 ("ARM: dts: rockchip: restyle emac nodes")
make emac on rk3036 kylin board probe right again:
[    1.920385] CAN device driver interface
[    1.925499] rockchip_emac 10200000.ethernet: no regulator found
[    1.932535] rockchip_emac 10200000.ethernet: ARC EMAC detected with id: 0x7fd02
[    1.940735] rockchip_emac 10200000.ethernet: IRQ is 42
[    1.946743] rockchip_emac 10200000.ethernet: MAC address is now 96:7d:4f:0a:69:b3
[    2.581340] rockchip_emac 10200000.ethernet: connected to Generic PHY phy with id 0xffffc816
[    2.592560] e1000e: Intel(R) PRO/1000 Network Driver
[    2.598136] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.

Fixes: 1dabb74971b3 ("ARM: dts: rockchip: restyle emac nodes")
Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
---

 arch/arm/boot/dts/rockchip/rk3036-evb.dts     | 16 ++++++----------
 arch/arm/boot/dts/rockchip/rk3036-kylin.dts   | 16 ++++++----------
 arch/arm/boot/dts/rockchip/rk3036.dtsi        |  2 ++
 .../boot/dts/rockchip/rk3066a-marsboard.dts   | 17 +++++++----------
 .../boot/dts/rockchip/rk3066a-rayeager.dts    | 15 +++++----------
 .../boot/dts/rockchip/rk3188-radxarock.dts    | 19 ++++++++-----------
 arch/arm/boot/dts/rockchip/rk3xxx.dtsi        |  2 ++
 7 files changed, 36 insertions(+), 51 deletions(-)

diff --git a/arch/arm/boot/dts/rockchip/rk3036-evb.dts b/arch/arm/boot/dts/rockchip/rk3036-evb.dts
index becdc0b664bf..94216f870b57 100644
--- a/arch/arm/boot/dts/rockchip/rk3036-evb.dts
+++ b/arch/arm/boot/dts/rockchip/rk3036-evb.dts
@@ -15,20 +15,16 @@ memory at 60000000 {
 };
 
 &emac {
-	phy = <&phy0>;
-	phy-reset-duration = <10>; /* millisecond */
-	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
 	pinctrl-names = "default";
 	pinctrl-0 = <&emac_xfer>, <&emac_mdio>;
-	status = "okay";
+	phy = <&phy0>;
+	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
+	phy-reset-duration = <10>; /* millisecond */
 
-	mdio {
-		#address-cells = <1>;
-		#size-cells = <0>;
+	status = "okay";
 
-		phy0: ethernet-phy at 0 {
-			reg = <0>;
-		};
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
index 67e1e04139e7..e817eba8c622 100644
--- a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
@@ -80,20 +80,16 @@ &acodec {
 };
 
 &emac {
-	phy = <&phy0>;
-	phy-reset-duration = <10>; /* millisecond */
-	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
 	pinctrl-names = "default";
 	pinctrl-0 = <&emac_xfer>, <&emac_mdio>;
-	status = "okay";
+	phy = <&phy0>;
+	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
+	phy-reset-duration = <10>; /* millisecond */
 
-	mdio {
-		#address-cells = <1>;
-		#size-cells = <0>;
+	status = "okay";
 
-		phy0: ethernet-phy at 0 {
-			reg = <0>;
-		};
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
index 78686fc72ce6..e240b89b0b35 100644
--- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
@@ -228,6 +228,8 @@ emac: ethernet at 10200000 {
 		compatible = "rockchip,rk3036-emac";
 		reg = <0x10200000 0x4000>;
 		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 		rockchip,grf = <&grf>;
 		clocks = <&cru HCLK_MAC>, <&cru SCLK_MACREF>, <&cru SCLK_MAC>;
 		clock-names = "hclk", "macref", "macclk";
diff --git a/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts b/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts
index f6e8d49a02ef..e3d6f0e81330 100644
--- a/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts
+++ b/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts
@@ -150,21 +150,18 @@ vcc28_cif: regulator at 12 {
 #include "../tps65910.dtsi"
 
 &emac {
+	status = "okay";
+
 	phy = <&phy0>;
 	phy-supply = <&vcc_rmii>;
+
 	pinctrl-names = "default";
 	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>;
-	status = "okay";
-
-	mdio {
-		#address-cells = <1>;
-		#size-cells = <0>;
 
-		phy0: ethernet-phy at 0 {
-			reg = <0>;
-			interrupt-parent = <&gpio1>;
-			interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
-		};
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts b/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts
index 29d8e5bf88f5..096616324c2d 100644
--- a/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts
+++ b/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts
@@ -142,20 +142,15 @@ &cpu1 {
 };
 
 &emac {
-	phy = <&phy0>;
-	phy-supply = <&vcc_rmii>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&rmii_rst>;
+	phy = <&phy0>;
+	phy-supply = <&vcc_rmii>;
 	status = "okay";
 
-	mdio {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		phy0: ethernet-phy at 0 {
-			reg = <0>;
-			reset-gpios = <&gpio1 RK_PD6 GPIO_ACTIVE_LOW>;
-		};
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+		reset-gpios = <&gpio1 RK_PD6 GPIO_ACTIVE_LOW>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts b/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts
index 118deacd38c4..239d2ec37fdc 100644
--- a/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts
@@ -126,21 +126,18 @@ vsys: vsys-regulator {
 };
 
 &emac {
-	phy = <&phy0>;
-	phy-supply = <&vcc_rmii>;
+	status = "okay";
+
 	pinctrl-names = "default";
 	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>;
-	status = "okay";
 
-	mdio {
-		#address-cells = <1>;
-		#size-cells = <0>;
+	phy = <&phy0>;
+	phy-supply = <&vcc_rmii>;
 
-		phy0: ethernet-phy at 0 {
-			reg = <0>;
-			interrupt-parent = <&gpio3>;
-			interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
-		};
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
index cb4e42ede56a..17e89d30de78 100644
--- a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
@@ -193,6 +193,8 @@ emac: ethernet at 10204000 {
 		compatible = "snps,arc-emac";
 		reg = <0x10204000 0x3c>;
 		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
 		rockchip,grf = <&grf>;
 
-- 
2.34.1



From gregor.herburger at ew.tq-group.com  Wed Dec 20 02:37:21 2023
From: gregor.herburger at ew.tq-group.com (Gregor Herburger)
Date: Wed, 20 Dec 2023 11:37:21 +0100
Subject: [PATCH] i2c: i2c-imx: allow bus recovery on non-muxable pads
In-Reply-To: <87frzyprhq.fsf@geanix.com>
References: <20231218-i2c-imx-recovery-v1-1-f69fa85b228c@ew.tq-group.com>
 <87frzyprhq.fsf@geanix.com>
Message-ID: <ZYLD4WgOPFB9ccym@herburgerg-w2>

Hi Esben,

I had another look at your patch and tested it on a LX2160a SoC without
pinctrl. I agree that using the generic GPIO recovery you suggested is
the better solution.

To make your solution work I had to make a small change (see below).

On Tue, Dec 19, 2023 at 07:43:21AM +0000, esben at geanix.com wrote:
> Why not move to use the generic GPIO recovery instead?  Will something
> like this be able to cover at least the same scenarios as your change?
> 
> From 7e432496bae8c7ac35c21504bc1cd03f1dfef97f Mon Sep 17 00:00:00 2001
> Message-ID: <7e432496bae8c7ac35c21504bc1cd03f1dfef97f.1702971634.git.esben at geanix.com>
> From: Esben Haabendal <esben at geanix.com>
> Date: Tue, 25 May 2021 11:25:44 +0200
> Subject: [PATCH] i2c: imx: move to generic GPIO recovery
> 
> Starting with
> commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
> GPIO bus recovery is supported by the I2C core, so we can remove the
> driver implementation and use that one instead.
> 
> As a nice side-effect, pinctrl becomes optional, allowing bus recovery on
> LS1021A, which does not have such luxury, but can be wired up to use extra
> fixed GPIO pins.
> 
> Signed-off-by: Esben Haabendal <esben at geanix.com>
> ---
>  drivers/i2c/busses/i2c-imx.c | 62 ++++--------------------------------
>  1 file changed, 7 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 1775a79aeba2..824d8bbb9be5 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -212,10 +212,6 @@ struct imx_i2c_struct {
>  	const struct imx_i2c_hwdata	*hwdata;
>  	struct i2c_bus_recovery_info rinfo;
>  
> -	struct pinctrl *pinctrl;
> -	struct pinctrl_state *pinctrl_pins_default;
> -	struct pinctrl_state *pinctrl_pins_gpio;
> -
>  	struct imx_i2c_dma	*dma;
>  	struct i2c_client	*slave;
>  	enum i2c_slave_event last_slave_event;
> @@ -1357,24 +1353,6 @@ static int i2c_imx_xfer_atomic(struct i2c_adapter *adapter,
>  	return result;
>  }
>  
> -static void i2c_imx_prepare_recovery(struct i2c_adapter *adap)
> -{
> -	struct imx_i2c_struct *i2c_imx;
> -
> -	i2c_imx = container_of(adap, struct imx_i2c_struct, adapter);
> -
> -	pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_gpio);
> -}
> -
> -static void i2c_imx_unprepare_recovery(struct i2c_adapter *adap)
> -{
> -	struct imx_i2c_struct *i2c_imx;
> -
> -	i2c_imx = container_of(adap, struct imx_i2c_struct, adapter);
> -
> -	pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_default);
> -}
> -
>  /*
>   * We switch SCL and SDA to their GPIO function and do some bitbanging
>   * for bus recovery. These alternative pinmux settings can be
> @@ -1385,43 +1363,17 @@ static void i2c_imx_unprepare_recovery(struct i2c_adapter *adap)
>  static int i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
>  		struct platform_device *pdev)
>  {
> -	struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
> +	struct i2c_bus_recovery_info *bri = &i2c_imx->rinfo;
>  
> -	i2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
> -	if (!i2c_imx->pinctrl) {
> -		dev_info(&pdev->dev, "pinctrl unavailable, bus recovery not supported\n");
> +	bri->pinctrl = devm_pinctrl_get(&pdev->dev);
> +	if (PTR_ERR(bri->pinctrl) == -ENODEV) {
> +		bri->pinctrl = NULL;
>  		return 0;
Should not return here to allow setting of adapter.bus_recovery_info
later.

>  	}
> -	if (IS_ERR(i2c_imx->pinctrl)) {
> -		dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
> -		return PTR_ERR(i2c_imx->pinctrl);
> -	}
> -
> -	i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
> -			PINCTRL_STATE_DEFAULT);
> -	i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
> -			"gpio");
> -	rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
> -	rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
> -
> -	if (PTR_ERR(rinfo->sda_gpiod) == -EPROBE_DEFER ||
> -	    PTR_ERR(rinfo->scl_gpiod) == -EPROBE_DEFER) {
> -		return -EPROBE_DEFER;
> -	} else if (IS_ERR(rinfo->sda_gpiod) ||
> -		   IS_ERR(rinfo->scl_gpiod) ||
> -		   IS_ERR(i2c_imx->pinctrl_pins_default) ||
> -		   IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
> -		dev_dbg(&pdev->dev, "recovery information incomplete\n");
> -		return 0;
> -	}
> -
> -	dev_dbg(&pdev->dev, "using scl%s for recovery\n",
> -		rinfo->sda_gpiod ? ",sda" : "");
> +	if (IS_ERR(bri->pinctrl))
> +		return PTR_ERR(bri->pinctrl);
>  
> -	rinfo->prepare_recovery = i2c_imx_prepare_recovery;
> -	rinfo->unprepare_recovery = i2c_imx_unprepare_recovery;
> -	rinfo->recover_bus = i2c_generic_scl_recovery;
> -	i2c_imx->adapter.bus_recovery_info = rinfo;
> +	i2c_imx->adapter.bus_recovery_info = bri;
>  
>  	return 0;
>  }

Best regards,
Gregor

-- 
TQ-Systems GmbH | M?hlstra?e 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M?nchen, HRB 105018
Gesch?ftsf?hrer: Detlef Schneider, R?diger Stahl, Stefan Schneider
https://www.tq-group.com/


From moudy.ho at mediatek.com  Wed Dec 20 02:18:28 2023
From: moudy.ho at mediatek.com (Moudy Ho)
Date: Wed, 20 Dec 2023 18:18:28 +0800
Subject: [PATCH v9 02/12] media: platform: mtk-mdp3: add support second sets of MUTEX
In-Reply-To: <20231220101838.21510-1-moudy.ho@mediatek.com>
References: <20231220101838.21510-1-moudy.ho@mediatek.com>
Message-ID: <20231220101838.21510-3-moudy.ho@mediatek.com>

After setting up the second set of MMSYS (VPPSYS1), it is necessary
to have a corresponding second set of MUTEX (MUTEX2) to assist in
handling SOF/EOF.

Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 .../platform/mediatek/mdp3/mtk-mdp3-cmdq.c    | 57 +++++++++++--------
 .../platform/mediatek/mdp3/mtk-mdp3-core.c    | 51 ++++++++++++-----
 .../platform/mediatek/mdp3/mtk-mdp3-core.h    |  4 +-
 3 files changed, 74 insertions(+), 38 deletions(-)

diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 6adac857a477..67c8fcc3eda9 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -44,15 +44,21 @@ static bool is_output_disabled(int p_id, const struct img_compparam *param, u32
 	return (count < num) ? (dis_output || dis_tile) : true;
 }
 
+static struct mtk_mutex *__get_mutex(const struct mdp_dev *mdp_dev,
+				     const struct mdp_pipe_info *p)
+{
+	return mdp_dev->mm_subsys[p->sub_id].mdp_mutex[p->mutex_id];
+}
+
 static int mdp_path_subfrm_require(const struct mdp_path *path,
 				   struct mdp_cmdq_cmd *cmd,
-				   s32 *mutex_id, u32 count)
+				   struct mdp_pipe_info *p, u32 count)
 {
 	const int p_id = path->mdp_dev->mdp_data->mdp_plat_id;
 	const struct mdp_comp_ctx *ctx;
 	const struct mtk_mdp_driver_data *data = path->mdp_dev->mdp_data;
 	struct device *dev = &path->mdp_dev->pdev->dev;
-	struct mtk_mutex **mutex = path->mdp_dev->mdp_mutex;
+	struct mtk_mutex *mutex;
 	int id, index;
 	u32 num_comp = 0;
 
@@ -77,7 +83,8 @@ static int mdp_path_subfrm_require(const struct mdp_path *path,
 		dev_err(dev, "Unknown pipeline and no mutex is assigned");
 		return -EINVAL;
 	}
-	*mutex_id = data->pipe_info[index].mutex_id;
+	memcpy(p, &data->pipe_info[index], sizeof(struct mdp_pipe_info));
+	mutex = __get_mutex(path->mdp_dev, p);
 
 	/* Set mutex mod */
 	for (index = 0; index < num_comp; index++) {
@@ -85,29 +92,28 @@ static int mdp_path_subfrm_require(const struct mdp_path *path,
 		if (is_output_disabled(p_id, ctx->param, count))
 			continue;
 		id = ctx->comp->public_id;
-		mtk_mutex_write_mod(mutex[*mutex_id],
-				    data->mdp_mutex_table_idx[id], false);
+		mtk_mutex_write_mod(mutex, data->mdp_mutex_table_idx[id], false);
+
 	}
 
-	mtk_mutex_write_sof(mutex[*mutex_id],
-			    MUTEX_SOF_IDX_SINGLE_MODE);
+	mtk_mutex_write_sof(mutex, MUTEX_SOF_IDX_SINGLE_MODE);
 
 	return 0;
 }
 
 static int mdp_path_subfrm_run(const struct mdp_path *path,
 			       struct mdp_cmdq_cmd *cmd,
-			       s32 *mutex_id, u32 count)
+			       struct mdp_pipe_info *p, u32 count)
 {
 	const int p_id = path->mdp_dev->mdp_data->mdp_plat_id;
 	const struct mdp_comp_ctx *ctx;
 	struct device *dev = &path->mdp_dev->pdev->dev;
-	struct mtk_mutex **mutex = path->mdp_dev->mdp_mutex;
+	struct mtk_mutex *mutex;
 	int index;
 	u32 num_comp = 0;
 	s32 event;
 
-	if (-1 == *mutex_id) {
+	if (-1 == p->mutex_id) {
 		dev_err(dev, "Incorrect mutex id");
 		return -EINVAL;
 	}
@@ -127,7 +133,8 @@ static int mdp_path_subfrm_run(const struct mdp_path *path,
 	}
 
 	/* Enable the mutex */
-	mtk_mutex_enable_by_cmdq(mutex[*mutex_id], (void *)&cmd->pkt);
+	mutex = __get_mutex(path->mdp_dev, p);
+	mtk_mutex_enable_by_cmdq(mutex, (void *)&cmd->pkt);
 
 	/* Wait SOF events and clear mutex modules (optional) */
 	for (index = 0; index < num_comp; index++) {
@@ -174,7 +181,7 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 	const struct img_mmsys_ctrl *ctrl = NULL;
 	const struct img_mux *set;
 	struct mdp_comp_ctx *ctx;
-	s32 mutex_id;
+	struct mdp_pipe_info pipe;
 	int index, ret;
 	u32 num_comp = 0;
 
@@ -185,7 +192,7 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 		ctrl = CFG_ADDR(MT8183, path->config, ctrls[count]);
 
 	/* Acquire components */
-	ret = mdp_path_subfrm_require(path, cmd, &mutex_id, count);
+	ret = mdp_path_subfrm_require(path, cmd, &pipe, count);
 	if (ret)
 		return ret;
 	/* Enable mux settings */
@@ -204,7 +211,7 @@ static int mdp_path_config_subfrm(struct mdp_cmdq_cmd *cmd,
 			return ret;
 	}
 	/* Run components */
-	ret = mdp_path_subfrm_run(path, cmd, &mutex_id, count);
+	ret = mdp_path_subfrm_run(path, cmd, &pipe, count);
 	if (ret)
 		return ret;
 	/* Wait components done */
@@ -328,13 +335,13 @@ static void mdp_auto_release_work(struct work_struct *work)
 {
 	struct mdp_cmdq_cmd *cmd;
 	struct mdp_dev *mdp;
-	int id;
+	struct mtk_mutex *mutex;
 
 	cmd = container_of(work, struct mdp_cmdq_cmd, auto_release_work);
 	mdp = cmd->mdp;
 
-	id = mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0].mutex_id;
-	mtk_mutex_unprepare(mdp->mdp_mutex[id]);
+	mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0]);
+	mtk_mutex_unprepare(mutex);
 	mdp_comp_clocks_off(&mdp->pdev->dev, cmd->comps,
 			    cmd->num_comps);
 
@@ -354,7 +361,6 @@ static void mdp_handle_cmdq_callback(struct mbox_client *cl, void *mssg)
 	struct cmdq_cb_data *data;
 	struct mdp_dev *mdp;
 	struct device *dev;
-	int id;
 
 	if (!mssg) {
 		pr_info("%s:no callback data\n", __func__);
@@ -379,9 +385,11 @@ static void mdp_handle_cmdq_callback(struct mbox_client *cl, void *mssg)
 
 	INIT_WORK(&cmd->auto_release_work, mdp_auto_release_work);
 	if (!queue_work(mdp->clock_wq, &cmd->auto_release_work)) {
+		struct mtk_mutex *mutex;
+
 		dev_err(dev, "%s:queue_work fail!\n", __func__);
-		id = mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0].mutex_id;
-		mtk_mutex_unprepare(mdp->mdp_mutex[id]);
+		mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0]);
+		mtk_mutex_unprepare(mutex);
 		mdp_comp_clocks_off(&mdp->pdev->dev, cmd->comps,
 				    cmd->num_comps);
 
@@ -403,6 +411,7 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 	struct mdp_comp *comps = NULL;
 	struct device *dev = &mdp->pdev->dev;
 	const int p_id = mdp->mdp_data->mdp_plat_id;
+	struct mtk_mutex *mutex = NULL;
 	int i, ret;
 	u32 num_comp = 0;
 
@@ -440,8 +449,8 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 		goto err_free_comps;
 	}
 
-	i = mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0].mutex_id;
-	ret = mtk_mutex_prepare(mdp->mdp_mutex[i]);
+	mutex = __get_mutex(mdp, &mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0]);
+	ret = mtk_mutex_prepare(mutex);
 	if (ret) {
 		dev_err(dev, "Fail to enable mutex clk\n");
 		goto err_free_path;
@@ -506,8 +515,8 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct mdp_cmdq_param *param)
 	mdp_comp_clocks_off(&mdp->pdev->dev, cmd->comps,
 			    cmd->num_comps);
 err_free_path:
-	i = mdp->mdp_data->pipe_info[MDP_PIPE_RDMA0].mutex_id;
-	mtk_mutex_unprepare(mdp->mdp_mutex[i]);
+	if (mutex)
+		mtk_mutex_unprepare(mutex);
 	kfree(path);
 err_free_comps:
 	kfree(comps);
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
index 8cd0f11fc290..4802b20d7f20 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
@@ -146,8 +146,17 @@ void mdp_video_device_release(struct video_device *vdev)
 	vb2_dma_contig_clear_max_seg_size(&mdp->pdev->dev);
 
 	mdp_comp_destroy(mdp);
-	for (i = 0; i < MDP_PIPE_MAX; i++)
-		mtk_mutex_put(mdp->mdp_mutex[i]);
+	for (i = 0; i < mdp->mdp_data->pipe_info_len; i++) {
+		enum mdp_mm_subsys_id idx;
+		struct mtk_mutex *m;
+		u32 m_id;
+
+		idx = mdp->mdp_data->pipe_info[i].sub_id;
+		m_id = mdp->mdp_data->pipe_info[i].mutex_id;
+		m = mdp->mm_subsys[idx].mdp_mutex[m_id];
+		if (!IS_ERR_OR_NULL(m))
+			mtk_mutex_put(m);
+	}
 
 	mdp_vpu_shared_mem_free(&mdp->vpu);
 	v4l2_m2m_release(mdp->m2m_dev);
@@ -171,6 +180,9 @@ static int mdp_mm_subsys_deploy(struct mdp_dev *mdp, enum mdp_infra_id id)
 		case MDP_INFRA_MMSYS:
 			dev = &mdp->mm_subsys[i].mmsys;
 			break;
+		case MDP_INFRA_MUTEX:
+			dev = &mdp->mm_subsys[i].mutex;
+			break;
 		default:
 			dev_err(&mdp->pdev->dev, "Unknown infra id %d", id);
 			return -EINVAL;
@@ -214,18 +226,24 @@ static int mdp_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_destroy_device;
 
-	mm_pdev = __get_pdev_by_id(pdev, NULL, MDP_INFRA_MUTEX);
-	if (WARN_ON(!mm_pdev)) {
-		ret = -ENODEV;
+	ret = mdp_mm_subsys_deploy(mdp, MDP_INFRA_MUTEX);
+	if (ret)
 		goto err_destroy_device;
-	}
+
 	for (i = 0; i < mdp->mdp_data->pipe_info_len; i++) {
+		enum mdp_mm_subsys_id idx;
+		struct mtk_mutex **m;
+
+		idx = mdp->mdp_data->pipe_info[i].sub_id;
 		mutex_id = mdp->mdp_data->pipe_info[i].mutex_id;
-		if (!IS_ERR_OR_NULL(mdp->mdp_mutex[mutex_id]))
+		m = &mdp->mm_subsys[idx].mdp_mutex[mutex_id];
+
+		if (!IS_ERR_OR_NULL(*m))
 			continue;
-		mdp->mdp_mutex[mutex_id] = mtk_mutex_get(&mm_pdev->dev);
-		if (IS_ERR(mdp->mdp_mutex[mutex_id])) {
-			ret = PTR_ERR(mdp->mdp_mutex[mutex_id]);
+
+		*m = mtk_mutex_get(mdp->mm_subsys[idx].mutex);
+		if (IS_ERR(*m)) {
+			ret = PTR_ERR(*m);
 			goto err_free_mutex;
 		}
 	}
@@ -309,9 +327,16 @@ static int mdp_probe(struct platform_device *pdev)
 err_deinit_comp:
 	mdp_comp_destroy(mdp);
 err_free_mutex:
-	for (i = 0; i < mdp->mdp_data->pipe_info_len; i++)
-		if (!IS_ERR_OR_NULL(mdp->mdp_mutex[i]))
-			mtk_mutex_put(mdp->mdp_mutex[i]);
+	for (i = 0; i < mdp->mdp_data->pipe_info_len; i++) {
+		enum mdp_mm_subsys_id idx;
+		struct mtk_mutex *m;
+
+		idx = mdp->mdp_data->pipe_info[i].sub_id;
+		mutex_id = mdp->mdp_data->pipe_info[i].mutex_id;
+		m = mdp->mm_subsys[idx].mdp_mutex[mutex_id];
+		if (!IS_ERR_OR_NULL(m))
+			mtk_mutex_put(m);
+	}
 err_destroy_device:
 	kfree(mdp);
 err_return:
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
index 7a7cdd0ce968..fde2c0b95def 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
@@ -26,6 +26,7 @@ enum mdp_infra_id {
 	MDP_INFRA_MMSYS,
 	MDP_INFRA_MMSYS2,
 	MDP_INFRA_MUTEX,
+	MDP_INFRA_MUTEX2,
 	MDP_INFRA_SCP,
 	MDP_INFRA_MAX
 };
@@ -78,12 +79,13 @@ struct mtk_mdp_driver_data {
 
 struct mdp_mm_subsys {
 	struct device *mmsys;
+	struct device *mutex;
+	struct mtk_mutex *mdp_mutex[MDP_PIPE_MAX];
 };
 
 struct mdp_dev {
 	struct platform_device			*pdev;
 	struct mdp_mm_subsys			mm_subsys[MDP_MM_SUBSYS_MAX];
-	struct mtk_mutex			*mdp_mutex[MDP_PIPE_MAX];
 	struct mdp_comp				*comp[MDP_MAX_COMP_COUNT];
 	const struct mtk_mdp_driver_data	*mdp_data;
 
-- 
2.18.0



From william-tw.lin at mediatek.com  Wed Dec 20 02:39:00 2023
From: william-tw.lin at mediatek.com (William-tw Lin)
Date: Wed, 20 Dec 2023 18:39:00 +0800
Subject: [PATCH v3 2/3] soc: mediatek: mtk-socinfo: Add driver for getting chip information
In-Reply-To: <20231220103901.22180-1-william-tw.lin@mediatek.com>
References: <20231220103901.22180-1-william-tw.lin@mediatek.com>
Message-ID: <20231220103901.22180-3-william-tw.lin@mediatek.com>

Add driver for socinfo retrieval. This patch includes the following:
1. mtk-socinfo driver for chip info retrieval
2. Related changes to Makefile and Kconfig

Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
---
 drivers/soc/mediatek/Kconfig       |   8 ++
 drivers/soc/mediatek/Makefile      |   1 +
 drivers/soc/mediatek/mtk-socinfo.c | 186 +++++++++++++++++++++++++++++
 3 files changed, 195 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-socinfo.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 0810b5b0c688..f34d93977ba6 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -68,4 +68,12 @@ config MTK_SVS
 	  chip process corner, temperatures and other factors. Then DVFS
 	  driver could apply SVS bank voltage to PMIC/Buck.
 
+config MTK_SOCINFO
+	tristate "MediaTek SoC Information"
+	default y
+	help
+	  The MediaTek SoC Information (mtk-socinfo) driver provides
+	  information about the SoC to the userspace including the
+	  manufacturer name, marketing name and soc name.
+
 endmenu
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 9d3ce7878c5c..6830512848fd 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_MTK_REGULATOR_COUPLER) += mtk-regulator-coupler.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
 obj-$(CONFIG_MTK_SVS) += mtk-svs.o
+obj-$(CONFIG_MTK_SOCINFO) += mtk-socinfo.o
diff --git a/drivers/soc/mediatek/mtk-socinfo.c b/drivers/soc/mediatek/mtk-socinfo.c
new file mode 100644
index 000000000000..4a257b5c8eda
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-socinfo.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pm_runtime.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/device.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+#include <linux/string.h>
+#include <linux/sys_soc.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+
+#define MTK_SOCINFO_ENTRY(_soc_name, _segment_name, _marketing_name, _cell_data1, _cell_data2) {\
+	.soc_name = _soc_name,									\
+	.segment_name = _segment_name,								\
+	.marketing_name = _marketing_name,							\
+	.cell_data = {_cell_data1, _cell_data2}							\
+}
+#define CELL_NOT_USED (0xFFFFFFFF)
+#define MAX_CELLS (2)
+
+struct mtk_socinfo {
+	struct device *dev;
+	struct name_data *name_data;
+	struct socinfo_data *socinfo_data;
+	struct soc_device *soc_dev;
+};
+
+struct socinfo_data {
+	char *soc_name;
+	char *segment_name;
+	char *marketing_name;
+	u32 cell_data[MAX_CELLS];
+};
+
+static const char *cell_names[MAX_CELLS] = {"socinfo-data1", "socinfo-data2"};
+
+static struct socinfo_data socinfo_data_table[] = {
+	MTK_SOCINFO_ENTRY("MT8173", "MT8173V/AC", "MT8173", 0x6CA20004, 0x10000000),
+	MTK_SOCINFO_ENTRY("MT8183", "MT8183V/AZA", "Kompanio 500", 0x00010043, 0x00000840),
+	MTK_SOCINFO_ENTRY("MT8186", "MT8186GV/AZA", "Kompanio 520", 0x81861001, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8186T", "MT8186TV/AZA", "Kompanio 528", 0x81862001, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8188", "MT8188GV/AZA", "Kompanio 830", 0x81880000, 0x00000010),
+	MTK_SOCINFO_ENTRY("MT8188", "MT8188GV/HZA", "Kompanio 830", 0x81880000, 0x00000011),
+	MTK_SOCINFO_ENTRY("MT8192", "MT8192V/AZA", "Kompanio 820", 0x00001100, 0x00040080),
+	MTK_SOCINFO_ENTRY("MT8192T", "MT8192V/ATZA", "Kompanio 828", 0x00000100, 0x000400C0),
+	MTK_SOCINFO_ENTRY("MT8195", "MT8195GV/EZA", "Kompanio 1200", 0x81950300, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8195", "MT8195GV/EHZA", "Kompanio 1200", 0x81950304, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8195", "MT8195TV/EZA", "Kompanio 1380", 0x81950400, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8195", "MT8195TV/EHZA", "Kompanio 1380", 0x81950404, CELL_NOT_USED),
+};
+
+static int mtk_socinfo_create_socinfo_node(struct mtk_socinfo *mtk_socinfop)
+{
+	struct soc_device_attribute *attrs;
+	static char machine[30] = {0};
+	static const char *soc_manufacturer = "MediaTek";
+
+	attrs = devm_kzalloc(mtk_socinfop->dev, sizeof(*attrs), GFP_KERNEL);
+	if (!attrs)
+		return -ENOMEM;
+
+	snprintf(machine, sizeof(machine), "%s (%s)", mtk_socinfop->socinfo_data->marketing_name,
+		mtk_socinfop->socinfo_data->soc_name);
+	attrs->family = soc_manufacturer;
+	attrs->machine = machine;
+
+	mtk_socinfop->soc_dev = soc_device_register(attrs);
+	if (IS_ERR(mtk_socinfop->soc_dev))
+		return PTR_ERR(mtk_socinfop->soc_dev);
+
+	dev_info(mtk_socinfop->dev, "%s %s SoC detected.\n", soc_manufacturer, attrs->machine);
+	return 0;
+}
+
+static u32 mtk_socinfo_read_cell(struct device *dev, const char *name)
+{
+	struct nvmem_device *nvmemp;
+	struct device_node *np = dev->of_node;
+	u32 offset;
+	u32 cell_val = CELL_NOT_USED;
+
+	nvmemp = devm_nvmem_device_get(dev, "mtk-efuse0");
+	if (IS_ERR(nvmemp))
+		goto out;
+
+	np = of_find_node_by_name(NULL, name);
+	if (!np)
+		goto out;
+
+	if (of_property_read_u32_index(np, "reg", 0, &offset))
+		goto out;
+
+	nvmem_device_read(nvmemp, offset, sizeof(cell_val), &cell_val);
+
+	nvmem_device_put(nvmemp);
+
+out:
+	return cell_val;
+}
+
+static int mtk_socinfo_get_socinfo_data(struct mtk_socinfo *mtk_socinfop)
+{
+	unsigned int i, j;
+	unsigned int num_cell_data = 0;
+	u32 cell_data[MAX_CELLS] = {0};
+	bool match_socinfo;
+	int match_socinfo_index = -1;
+
+	for (i = 0; i < MAX_CELLS; i++) {
+		cell_data[i] = mtk_socinfo_read_cell(mtk_socinfop->dev, cell_names[i]);
+		if (cell_data[i] != CELL_NOT_USED)
+			num_cell_data++;
+		else
+			break;
+	}
+
+	if (!num_cell_data)
+		return -ENOENT;
+
+	for (i = 0; i < ARRAY_SIZE(socinfo_data_table); i++) {
+		match_socinfo = true;
+		for (j = 0; j < num_cell_data; j++) {
+			if (cell_data[j] != socinfo_data_table[i].cell_data[j]) {
+				match_socinfo = false;
+				break;
+			}
+		}
+		if (match_socinfo) {
+			mtk_socinfop->socinfo_data = &(socinfo_data_table[i]);
+			match_socinfo_index = i;
+			break;
+		}
+	}
+
+	return match_socinfo_index >= 0 ? match_socinfo_index : -ENOENT;
+}
+
+static int mtk_socinfo_probe(struct platform_device *pdev)
+{
+	struct mtk_socinfo *mtk_socinfop;
+	int ret;
+
+	mtk_socinfop = devm_kzalloc(&pdev->dev, sizeof(*mtk_socinfop), GFP_KERNEL);
+	if (!mtk_socinfop)
+		return -ENOMEM;
+
+	mtk_socinfop->dev = &pdev->dev;
+
+	ret = mtk_socinfo_get_socinfo_data(mtk_socinfop);
+	if (ret < 0)
+		return dev_err_probe(mtk_socinfop->dev, ret, "Failed to get socinfo data\n");
+
+	ret = mtk_socinfo_create_socinfo_node(mtk_socinfop);
+	if (ret)
+		return dev_err_probe(mtk_socinfop->dev, ret, "Cannot create node\n");
+
+	platform_set_drvdata(pdev, mtk_socinfop);
+	return 0;
+}
+
+static void mtk_socinfo_remove(struct platform_device *pdev)
+{
+	struct mtk_socinfo *mtk_socinfop = platform_get_drvdata(pdev);
+
+	soc_device_unregister(mtk_socinfop->soc_dev);
+}
+
+static struct platform_driver mtk_socinfo = {
+	.probe = mtk_socinfo_probe,
+	.remove_new = mtk_socinfo_remove,
+	.driver = {
+		.name = "mtk-socinfo",
+	},
+};
+builtin_platform_driver(mtk_socinfo);
+
+MODULE_AUTHOR("William-TW LIN <william-tw.lin at mediatek.com>");
+MODULE_DESCRIPTION("MediaTek socinfo driver");
+MODULE_LICENSE("GPL");
-- 
2.18.0



From william-tw.lin at mediatek.com  Wed Dec 20 02:39:01 2023
From: william-tw.lin at mediatek.com (William-tw Lin)
Date: Wed, 20 Dec 2023 18:39:01 +0800
Subject: [PATCH v3 3/3] nvmem: mtk-efuse: Modify driver for getting chip information
In-Reply-To: <20231220103901.22180-1-william-tw.lin@mediatek.com>
References: <20231220103901.22180-1-william-tw.lin@mediatek.com>
Message-ID: <20231220103901.22180-4-william-tw.lin@mediatek.com>

Retrieval of soc info is needed. This patch includes the following:
1. Register socinfo device in mtk-efuse.c

Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
---
 drivers/nvmem/mtk-efuse.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
index 84f05b40a411..3914e039e288 100644
--- a/drivers/nvmem/mtk-efuse.c
+++ b/drivers/nvmem/mtk-efuse.c
@@ -68,6 +68,7 @@ static int mtk_efuse_probe(struct platform_device *pdev)
 	struct nvmem_config econfig = {};
 	struct mtk_efuse_priv *priv;
 	const struct mtk_efuse_pdata *pdata;
+	struct platform_device *socinfo;
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -85,11 +86,19 @@ static int mtk_efuse_probe(struct platform_device *pdev)
 	econfig.size = resource_size(res);
 	econfig.priv = priv;
 	econfig.dev = dev;
+	econfig.name = "mtk-efuse";
 	if (pdata->uses_post_processing)
 		econfig.fixup_dt_cell_info = &mtk_efuse_fixup_dt_cell_info;
 	nvmem = devm_nvmem_register(dev, &econfig);
+	if (IS_ERR(nvmem))
+		return PTR_ERR(nvmem);
 
-	return PTR_ERR_OR_ZERO(nvmem);
+	socinfo = platform_device_register_data(&pdev->dev, "mtk-socinfo",
+						PLATFORM_DEVID_AUTO, NULL, 0);
+	if (IS_ERR(socinfo))
+		dev_info(dev, "MediaTek SoC Information will be unavailable\n");
+
+	return 0;
 }
 
 static const struct mtk_efuse_pdata mtk_mt8186_efuse_pdata = {
-- 
2.18.0



From andre.przywara at arm.com  Wed Dec 20 02:39:32 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 20 Dec 2023 10:39:32 +0000
Subject: [RFC PATCH 1/2] cpufreq: sun50i: Add support for D1's speed bin
 decoding
In-Reply-To: <20231220095141.27883-2-fusibrandon13@gmail.com>
References: <20231220095141.27883-1-fusibrandon13@gmail.com>
	<20231220095141.27883-2-fusibrandon13@gmail.com>
Message-ID: <20231220103932.1b186610@donnerap.manchester.arm.com>

On Wed, 20 Dec 2023 10:51:40 +0100
Brandon Cheo Fusi <fusibrandon13 at gmail.com> wrote:

Hi Brandon,

> Adds support for decoding the efuse value read from D1 efuse speed
> bins, and factors out equivalent code for sun50i.

Thanks for taking care and sharing this approach!

So this seems to be trying to achieve the same goal as this patch:
https://lore.kernel.org/linux-sunxi/20230904-cpufreq-h616-v1-4-b8842e525c43 at somainline.org/
That covers the H616, and would at least clash heavily. The H616 series is
stuck on of some stupid bit in the temperature sensor driver, so I
guess the D1 (being easier) would overtake it.

Can you please split your patch below up, to first refactor the existing
code, with just the H6 support in, then in a second patch add the D1
specific parts? Bonus points for looking at the H616 patch and checking
if there are extra requirements over the D1, which should be already
considered in this refactoring patch.

Many thanks,
Andre


> The algorithm is gotten from
> 
> https://github.com/Tina-Linux/linux-5.4/blob/master/drivers/cpufreq/sun50i-cpufreq-nvmem.c#L293-L338
> 
> and maps an efuse value to either 0 or 1, with 1 meaning stable at
> a lower supply voltage for the same clock frequency.
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 85 +++++++++++++++++++++-----
>  1 file changed, 70 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> index ccf83780f..28afbe558 100644
> --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> @@ -25,6 +25,66 @@
>  
>  static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
>  
> +struct sunxi_cpufreq_data {
> +	u32 (*efuse_xlate)(u32 efuse_value);
> +};
> +
> +static u32 sun20i_efuse_xlate(u32 efuse_value)
> +{
> +	u32 ret;
> +
> +	switch (efuse_value) {
> +	case 0x5e00:
> +		/* QFN package */
> +		ret = 0;
> +		break;
> +	case 0x5c00:
> +	case 0x7400:
> +		/* QFN package */
> +		ret = 1;
> +		break;
> +	case 0x5000:
> +	default:
> +		/* BGA package */
> +		ret = 0;
> +	}
> +
> +	return ret;
> +}
> +
> +static u32 sun50i_efuse_xlate(u32 efuse_value)
> +{
> +	efuse_value = (efuse_value >> NVMEM_SHIFT) & NVMEM_MASK;
> +
> +	/*
> +	* We treat unexpected efuse values as if the SoC was from
> +	* the slowest bin. Expected efuse values are 1-3, slowest
> +	* to fastest.
> +	*/
> +	if (efuse_value >= 1 && efuse_value <= 3)
> +		return efuse_value - 1;
> +	else
> +		return 0;
> +}
> +
> +struct sunxi_cpufreq_data sun20i_cpufreq_data = {
> +	.efuse_xlate = sun20i_efuse_xlate,
> +};
> +
> +struct sunxi_cpufreq_data sun50i_cpufreq_data = {
> +	.efuse_xlate = sun50i_efuse_xlate,
> +};
> +
> +static const struct of_device_id cpu_opp_match_list[] = {
> +	{ .compatible = "allwinner,sun50i-h6-operating-points",
> +	  .data = &sun50i_cpufreq_data,
> +	},
> +	{ .compatible = "allwinner,sun20i-d1-operating-points",
> +	  .data = &sun20i_cpufreq_data,
> +	},
> +	{}
> +};
> +
>  /**
>   * sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
>   * @versions: Set to the value parsed from efuse
> @@ -36,9 +96,11 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
>  	struct nvmem_cell *speedbin_nvmem;
>  	struct device_node *np;
>  	struct device *cpu_dev;
> -	u32 *speedbin, efuse_value;
> +	const struct of_device_id *opp_match;
> +	const struct sunxi_cpufreq_data *opp_data;
> +	u32 *speedbin, efuse_value = 0;
>  	size_t len;
> -	int ret;
> +	int i;
>  
>  	cpu_dev = get_cpu_device(0);
>  	if (!cpu_dev)
> @@ -48,9 +110,8 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
>  	if (!np)
>  		return -ENOENT;
>  
> -	ret = of_device_is_compatible(np,
> -				      "allwinner,sun50i-h6-operating-points");
> -	if (!ret) {
> +	opp_match = of_match_node(cpu_opp_match_list, np);
> +	if (!opp_match) {
>  		of_node_put(np);
>  		return -ENOENT;
>  	}
> @@ -66,17 +127,11 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
>  	if (IS_ERR(speedbin))
>  		return PTR_ERR(speedbin);
>  
> -	efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
> +	for (i = 0; i < len; i++)
> +		efuse_value |= ((u32)speedbin[i] << (i * 8));
>  
> -	/*
> -	 * We treat unexpected efuse values as if the SoC was from
> -	 * the slowest bin. Expected efuse values are 1-3, slowest
> -	 * to fastest.
> -	 */
> -	if (efuse_value >= 1 && efuse_value <= 3)
> -		*versions = efuse_value - 1;
> -	else
> -		*versions = 0;
> +	opp_data = opp_match->data;
> +	*versions = opp_data->efuse_xlate(efuse_value);
>  
>  	kfree(speedbin);
>  	return 0;



From m.szyprowski at samsung.com  Wed Dec 20 02:39:32 2023
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 20 Dec 2023 11:39:32 +0100
Subject: [PATCH] drm/exynos: gsc: minor fix for loop iteration in
 gsc_runtime_resume
In-Reply-To: <20231220095316.23098-1-pchelkin@ispras.ru>
References: <CGME20231220095336eucas1p1f6cec297f84463fbf50a875cc0fb64f6@eucas1p1.samsung.com>
	<20231220095316.23098-1-pchelkin@ispras.ru>
Message-ID: <111adf74-5239-420a-880c-be92a2f663fd@samsung.com>

On 20.12.2023 10:53, Fedor Pchelkin wrote:
> Do not forget to call clk_disable_unprepare() on the first element of
> ctx->clocks array.
>
> Found by Linux Verification Center (linuxtesting.org).
>
> Fixes: 8b7d3ec83aba ("drm/exynos: gsc: Convert driver to IPP v2 core API")
> Signed-off-by: Fedor Pchelkin <pchelkin at ispras.ru>
Reviewed-by: Marek Szyprowski <m.szyprowski at samsung.com>
> ---
>   drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 34cdabc30b4f..5302bebbe38c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1342,7 +1342,7 @@ static int __maybe_unused gsc_runtime_resume(struct device *dev)
>   	for (i = 0; i < ctx->num_clocks; i++) {
>   		ret = clk_prepare_enable(ctx->clocks[i]);
>   		if (ret) {
> -			while (--i > 0)
> +			while (--i >= 0)
>   				clk_disable_unprepare(ctx->clocks[i]);
>   			return ret;
>   		}

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From william-tw.lin at mediatek.com  Wed Dec 20 02:38:59 2023
From: william-tw.lin at mediatek.com (William-tw Lin)
Date: Wed, 20 Dec 2023 18:38:59 +0800
Subject: [PATCH v3 1/3] arm64: dts: Add node for chip info driver
In-Reply-To: <20231220103901.22180-1-william-tw.lin@mediatek.com>
References: <20231220103901.22180-1-william-tw.lin@mediatek.com>
Message-ID: <20231220103901.22180-2-william-tw.lin@mediatek.com>

Add dts node for socinfo retrieval for the following projects:
MT8173, MT8183, MT8186, MT8192, MT8195

Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +++++++++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 9 +++++++++
 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 8 ++++++++
 arch/arm64/boot/dts/mediatek/mt8195.dtsi | 3 +++
 5 files changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index c47d7d900f28..06916e60679a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -590,6 +590,15 @@
 			reg = <0 0x10206000 0 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+
+			socinfo_data1: socinfo-data1 at 40 {
+				reg = <0x040 0x4>;
+			};
+
+			socinfo_data2: socinfo-data2 at 44 {
+				reg = <0x044 0x4>;
+			};
+
 			thermal_calibration: calib at 528 {
 				reg = <0x528 0xc>;
 			};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 976dc968b3ca..d39c25db042e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1585,6 +1585,15 @@
 			reg = <0 0x11f10000 0 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+
+			socinfo_data1: socinfo-data1 at 4c {
+				reg = <0x04c 0x4>;
+			};
+
+			socinfo_data2: socinfo-data2 at 60 {
+				reg = <0x060 0x4>;
+			};
+
 			thermal_calibration: calib at 180 {
 				reg = <0x180 0xc>;
 			};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index df0c04f2ba1d..0e2f6fe14081 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1672,6 +1672,10 @@
 				reg = <0x59c 0x4>;
 				bits = <0 3>;
 			};
+
+			socinfo_data1: socinfo-data1 at 7a0 {
+				reg = <0x7a0 0x4>;
+			};
 		};
 
 		mipi_tx0: dsi-phy at 11cc0000 {
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 69f4cded5dbb..a329b430429f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -1120,6 +1120,14 @@
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			socinfo_data1: socinfo-data1 at 44 {
+				reg = <0x044 0x4>;
+			};
+
+			socinfo_data2: socinfo-data2 at 50 {
+				reg = <0x050 0x4>;
+			};
+
 			lvts_e_data1: data1 at 1c0 {
 				reg = <0x1c0 0x58>;
 			};
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index e0ac2e9f5b72..f1926a6afa8f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -1686,6 +1686,9 @@
 			lvts_efuse_data2: lvts2-calib at 1d0 {
 				reg = <0x1d0 0x38>;
 			};
+			socinfo_data1: socinfo-data1 at 7a0 {
+				reg = <0x7a0 0x4>;
+			};
 		};
 
 		u3phy2: t-phy at 11c40000 {
-- 
2.18.0



From angelogioacchino.delregno at collabora.com  Wed Dec 20 02:40:54 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 11:40:54 +0100
Subject: [PATCH v3 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <c3d372f0-3d21-4500-96cd-9c88aaf5ce89@linaro.org>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
 <c3d372f0-3d21-4500-96cd-9c88aaf5ce89@linaro.org>
Message-ID: <4117de24-75fd-4355-9ffb-7d1bc0167295@collabora.com>

Il 20/12/23 08:38, Krzysztof Kozlowski ha scritto:
> On 20/12/2023 03:58, Chunfeng Yun wrote:
>> For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
>> still send out unexpected ACK after receiving a short packet in burst
>> transfer, this will cause an exception on connected device, specially for
>> a 4k camera.
>> Add a quirk property "rx-fifo-depth" to work around this hardware issue,
>> prefer to use 3k bytes;
>> The side-effect is that may cause performance drop about 10%, including
>> bulk transfer.
>>
>> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
>> ---
>> v3: add fifo depth unit, change the value range from 0-3 to 1-4
>> v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
>> ---
>>   .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12 ++++++++++++
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>> index e9644e333d78..9478b7031796 100644
>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>> @@ -124,6 +124,18 @@ properties:
>>         defined in the xHCI spec on MTK's controller.
>>       default: 5000
>>   
>> +  rx-fifo-depth:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      It is a quirk used to work around Gen1 isoc-in endpoint transfer issue
>> +      that still send out unexpected ACK after device finish the burst transfer
>> +      with a short packet and cause an exception, specially on a 4K camera
>> +      device, it happens on controller before about IPM v1.6.0; the side-effect
>> +      is that may cause performance drop about 10%, include bulk transfer,
>> +      prefer to use 3 here. The unit is 1K bytes.
> 
> NAK. Read comments on previous submission.
> 
> Best regards,
> Krzysztof
> 

Chunfeng, I think the discussion was not clear for you, so I will try to give
you a different explanation: this should be expressed in bytes, so 1000, or 1024,
2048, 4096, etc, and not 1/2/3/4/5/n.

The driver shall then validate and map your bytes number to hardware register
value and subsequently write to the registers.

Cheers,
Angleo


From ryan.roberts at arm.com  Wed Dec 20 02:41:46 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 10:41:46 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
Message-ID: <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>

On 20/12/2023 10:16, David Hildenbrand wrote:
> On 20.12.23 11:11, Ryan Roberts wrote:
>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>>>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>
>>>>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>> range in the first place.
>>>>>>>>>>
>>>>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>
>>>>>>>>>> This change addresses the core-mm refactoring only and a separate change
>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>
>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>
>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>>>>> tight loop in a process with 1G of populated memory and the time for the
>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>>>>>> positive is slower, compared to baseline upon which the series is based:
>>>>>>>>>>
>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>
>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>
>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>> ---
>>>>>>>>>> ????? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>>>>>> ????? mm/memory.c???????????? | 92
>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>> ????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>> ????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>> ????? #endif
>>>>>>>>>> ????? +#ifndef pte_batch_remaining
>>>>>>>>>> +/**
>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>> boundary.
>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>> + *
>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>> batch of
>>>>>>>>>> ptes.
>>>>>>>>>> + * In such cases, this function returns the remaining number of pages to
>>>>>>>>>> the end
>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>>>>> iterating
>>>>>>>>>> + * over ptes.
>>>>>>>>>> + *
>>>>>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>>>>>> + */
>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long
>>>>>>>>>> addr,
>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>> +{
>>>>>>>>>> +??? return 1;
>>>>>>>>>> +}
>>>>>>>>>> +#endif
>>>>>>>>>
>>>>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>>>>
>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>> require
>>>>>>>>> arch
>>>>>>>>> specifics?
>>>>>>>>
>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the only
>>>>>>>> way
>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>
>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt at an
>>>>>>>> arch-specific version that didn't resolve to a compile-time constant 1
>>>>>>>> still
>>>>>>>> cost an extra 3%.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>
>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>
>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can get the
>>>>>>>> regression under 4% with this. Further along the series I spent a lot of
>>>>>>>> time
>>>>>>>> having to fiddle with the arm64 implementation; every conditional and every
>>>>>>>> memory read (even when in cache) was a problem. There is just so little in
>>>>>>>> the
>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra and
>>>>>>>> Apple
>>>>>>>> M2).
>>>>>>>>
>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>> benefit to
>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd prefer to
>>>>>>>> play
>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you previously
>>>>>>>> suggested.
>>>>>>>>
>>>>>>>
>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>> series. I
>>>>>>> implemented very generic and simple batching for large folios (all PTE bits
>>>>>>> except the PFN have to match).
>>>>>>>
>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>> Silver
>>>>>>> 4210R CPU.
>>>>>>>
>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>
>>>>>>> -> Around 1.7 % faster
>>>>>>>
>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>
>>>>>>> -> Around 36.3 % faster
>>>>>>
>>>>>> Well I guess that shows me :)
>>>>>>
>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>
>>>>>
>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>
>>>> I've just been trying to compile and noticed this. Will take a look at your
>>>> update.
>>>>
>>>> But upon review, I've noticed the part that I think makes this difficult for
>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>> pte in
>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>> changes, its ptep_get() has to read every pte in the contpte block in order to
>>>> gather the access and dirty bits. So if your batching function ends up wealking
>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>> function; this allows the core-mm to skip to the end of the contpte block and
>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>> instead
>>>> of 256.
>>>>
>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid the
>>>> bit
>>>> gathering. But we have a similar problem in zap_pte_range() and that function
>>>> needs the dirty bit to update the folio. So it doesn't work there. (see patch 3
>>>> in my series).
>>>>
>>>> I guess you are going to say that we should combine both approaches, so that
>>>> your batching loop can skip forward an arch-provided number of ptes? That would
>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>
>>> You can overwrite the function or add special-casing internally, yes.
>>>
>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()" and it
>>> doesn't do any of that besides preparing for some arm64 work.
>>>
>>
>> Well it allows an arch to opt-in to batching. But I see your point.
>>
>> How do you want to handle your patches? Do you want to clean them up and I'll
>> base my stuff on top? Or do you want me to take them and sort it all out?
> 
> Whatever you prefer, it was mostly a quick prototype to see if we can achieve
> decent performance.

I'm about to run it on Altra and M2. But I assume it will show similar results.

> 
> I can fixup the arch thingies (most should be easy, some might require a custom
> pte_next_pfn()) 

Well if you're happy to do that, great! I'm keen to get the contpte stuff into
v6.9 if at all possible, and I'm concious that I'm introducing more dependencies
on you. And its about to be holiday season...

> and you can focus on getting cont-pte sorted out on top [I
> assume that's what you want to work on :) ].

That's certainly what I'm focussed on. But I'm happy to do whatever is required
to get it over the line. I guess I'll start by finishing my review of your v1
rmap stuff.

> 
>>
>> As I see it at the moment, I would keep your folio_pte_batch() always core, but
>> in subsequent patch, have it use pte_batch_remaining() (the arch function I have
>> in my series, which defaults to one). 
> 
> Just double-checking, how would it use pte_batch_remaining() ?

I think something like this would do it (untested):

static inline int folio_pte_batch(struct folio *folio, unsigned long addr,
		pte_t *start_ptep, pte_t pte, int max_nr)
{
	unsigned long folio_end_pfn = folio_pfn(folio) + folio_nr_pages(folio);
	pte_t expected_pte = pte_next_pfn(pte);
	pte_t *ptep = start_ptep;
	int nr;

	for (;;) {
		nr = min(max_nr, pte_batch_remaining());
		ptep += nr;
		max_nr -= nr;

		if (max_nr == 0)
			break;

		pte = ptep_get(ptep);

		/* Do all PTE bits match, and the PFN is consecutive? */
		if (!pte_same(pte, expected_pte))
			break;

		/*
		 * Stop immediately once we reached the end of the folio. In
		 * corner cases the next PFN might fall into a different
		 * folio.
		 */
		if (pte_pfn(pte) == folio_end_pfn - 1)
			break;

		expected_pte = pte_next_pfn(expected_pte);
	}

	return ptep - start_ptep;
}

Of course, if we have the concept of a "pte batch" in the core-mm, then we might
want to call the arch's thing something different; pte span? pte cont? pte cont
batch? ...


> 
>> Then do a similar thing to what you have
>> done for fork in zap_pte_range() - also using folio_pte_batch(). Then lay my
>> series on top.
> 
> Yes, we should probably try to handle the zapping part similarly: make it
> benefit all archs first, then special-case on cont-pte. I can help there as well.

OK great.



From james.clark at arm.com  Wed Dec 20 02:44:49 2023
From: james.clark at arm.com (James Clark)
Date: Wed, 20 Dec 2023 10:44:49 +0000
Subject: [PATCH 1/3] perf scripts python: arm-cs-trace-disasm.py: print
 dso base address
In-Reply-To: <20231214123304.34087-2-tianruidong@linux.alibaba.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
 <20231214123304.34087-2-tianruidong@linux.alibaba.com>
Message-ID: <912a39f4-025e-26a1-7786-091fa211f293@arm.com>



On 14/12/2023 12:33, Ruidong Tian wrote:
> arm-cs-trace-disasm just print offset for library dso:
> 
> 	0000000000002200 <memcpy>:
>             2200: d503201f      nop
>             2204: 8b020024      add     x4, x1, x2
>             2208: 8b020005      add     x5, x0, x2
> 
> This print DSO base address to get complete virtual address for
> userspace application:
> 
> 	0000000000002200 <memcpy>: (base address is 0x0000ffffb4c21000)
>             2200: d503201f      nop
>             2204: 8b020024      add     x4, x1, x2
>             2208: 8b020005      add     x5, x0, x2
> 

I believe the output format without the base address is consistent with
objdump. For compatibility I would say that it's better to keep it that way.

We could add this as an option, but have it disabled by default. I
suppose it depends how likely that someone is using this output in a
tool and processing it further whether an option is needed or not.

Although it's also not that clear what this is useful for, given that
all the other output is relative too? Maybe you could add an example to
the commit message, even if it's just for debugging. Would an option
that turned _all_ the output into virtual addresses not be more useful?

Thanks
James

> Signed-off-by: Ruidong Tian <tianruidong at linux.alibaba.com>
> ---
>  tools/perf/scripts/python/arm-cs-trace-disasm.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> index d59ff53f1d94..46bf6b02eea1 100755
> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> @@ -108,6 +108,8 @@ def print_disam(dso_fname, dso_start, start_addr, stop_addr):
>  			m = disasm_re.search(line)
>  			if m is None:
>  				continue
> +		else:
> +			line += " (base address is 0x%016x)" % dso_start
>  		print("\t" + line)
>  
>  def print_sample(sample):


From angelogioacchino.delregno at collabora.com  Wed Dec 20 02:53:21 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 11:53:21 +0100
Subject: [PATCH v3 2/3] soc: mediatek: mtk-socinfo: Add driver for getting
 chip information
In-Reply-To: <20231220103901.22180-3-william-tw.lin@mediatek.com>
References: <20231220103901.22180-1-william-tw.lin@mediatek.com>
 <20231220103901.22180-3-william-tw.lin@mediatek.com>
Message-ID: <508c9b5a-61d9-4e42-8faa-c6f48f453235@collabora.com>

Il 20/12/23 11:39, William-tw Lin ha scritto:
> Add driver for socinfo retrieval. This patch includes the following:
> 1. mtk-socinfo driver for chip info retrieval
> 2. Related changes to Makefile and Kconfig
> 
> Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
> ---
>   drivers/soc/mediatek/Kconfig       |   8 ++
>   drivers/soc/mediatek/Makefile      |   1 +
>   drivers/soc/mediatek/mtk-socinfo.c | 186 +++++++++++++++++++++++++++++
>   3 files changed, 195 insertions(+)
>   create mode 100644 drivers/soc/mediatek/mtk-socinfo.c
> 
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index 0810b5b0c688..f34d93977ba6 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -68,4 +68,12 @@ config MTK_SVS
>   	  chip process corner, temperatures and other factors. Then DVFS
>   	  driver could apply SVS bank voltage to PMIC/Buck.
>   
> +config MTK_SOCINFO
> +	tristate "MediaTek SoC Information"
> +	default y

Add the dependency please.

	depends on NVMEM_MTK_EFUSE

> +	help
> +	  The MediaTek SoC Information (mtk-socinfo) driver provides
> +	  information about the SoC to the userspace including the
> +	  manufacturer name, marketing name and soc name.
> +
>   endmenu
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 9d3ce7878c5c..6830512848fd 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_MTK_REGULATOR_COUPLER) += mtk-regulator-coupler.o
>   obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
>   obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
>   obj-$(CONFIG_MTK_SVS) += mtk-svs.o
> +obj-$(CONFIG_MTK_SOCINFO) += mtk-socinfo.o
> diff --git a/drivers/soc/mediatek/mtk-socinfo.c b/drivers/soc/mediatek/mtk-socinfo.c
> new file mode 100644
> index 000000000000..4a257b5c8eda
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-socinfo.c
> @@ -0,0 +1,186 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2023 MediaTek Inc.
> + */
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/device.h>
> +#include <linux/debugfs.h>
> +#include <linux/seq_file.h>
> +#include <linux/string.h>
> +#include <linux/sys_soc.h>
> +#include <linux/slab.h>
> +#include <linux/platform_device.h>
> +
> +#define MTK_SOCINFO_ENTRY(_soc_name, _segment_name, _marketing_name, _cell_data1, _cell_data2) {\
> +	.soc_name = _soc_name,									\
> +	.segment_name = _segment_name,								\
> +	.marketing_name = _marketing_name,							\
> +	.cell_data = {_cell_data1, _cell_data2}							\
> +}
> +#define CELL_NOT_USED (0xFFFFFFFF)
> +#define MAX_CELLS (2)
> +
> +struct mtk_socinfo {
> +	struct device *dev;
> +	struct name_data *name_data;
> +	struct socinfo_data *socinfo_data;
> +	struct soc_device *soc_dev;
> +};
> +
> +struct socinfo_data {
> +	char *soc_name;
> +	char *segment_name;
> +	char *marketing_name;
> +	u32 cell_data[MAX_CELLS];
> +};
> +
> +static const char *cell_names[MAX_CELLS] = {"socinfo-data1", "socinfo-data2"};
> +
> +static struct socinfo_data socinfo_data_table[] = {
> +	MTK_SOCINFO_ENTRY("MT8173", "MT8173V/AC", "MT8173", 0x6CA20004, 0x10000000),
> +	MTK_SOCINFO_ENTRY("MT8183", "MT8183V/AZA", "Kompanio 500", 0x00010043, 0x00000840),
> +	MTK_SOCINFO_ENTRY("MT8186", "MT8186GV/AZA", "Kompanio 520", 0x81861001, CELL_NOT_USED),
> +	MTK_SOCINFO_ENTRY("MT8186T", "MT8186TV/AZA", "Kompanio 528", 0x81862001, CELL_NOT_USED),
> +	MTK_SOCINFO_ENTRY("MT8188", "MT8188GV/AZA", "Kompanio 830", 0x81880000, 0x00000010),
> +	MTK_SOCINFO_ENTRY("MT8188", "MT8188GV/HZA", "Kompanio 830", 0x81880000, 0x00000011),
> +	MTK_SOCINFO_ENTRY("MT8192", "MT8192V/AZA", "Kompanio 820", 0x00001100, 0x00040080),
> +	MTK_SOCINFO_ENTRY("MT8192T", "MT8192V/ATZA", "Kompanio 828", 0x00000100, 0x000400C0),
> +	MTK_SOCINFO_ENTRY("MT8195", "MT8195GV/EZA", "Kompanio 1200", 0x81950300, CELL_NOT_USED),
> +	MTK_SOCINFO_ENTRY("MT8195", "MT8195GV/EHZA", "Kompanio 1200", 0x81950304, CELL_NOT_USED),
> +	MTK_SOCINFO_ENTRY("MT8195", "MT8195TV/EZA", "Kompanio 1380", 0x81950400, CELL_NOT_USED),
> +	MTK_SOCINFO_ENTRY("MT8195", "MT8195TV/EHZA", "Kompanio 1380", 0x81950404, CELL_NOT_USED),
> +};
> +
> +static int mtk_socinfo_create_socinfo_node(struct mtk_socinfo *mtk_socinfop)
> +{
> +	struct soc_device_attribute *attrs;
> +	static char machine[30] = {0};
> +	static const char *soc_manufacturer = "MediaTek";
> +
> +	attrs = devm_kzalloc(mtk_socinfop->dev, sizeof(*attrs), GFP_KERNEL);
> +	if (!attrs)
> +		return -ENOMEM;
> +
> +	snprintf(machine, sizeof(machine), "%s (%s)", mtk_socinfop->socinfo_data->marketing_name,
> +		mtk_socinfop->socinfo_data->soc_name);
> +	attrs->family = soc_manufacturer;
> +	attrs->machine = machine;
> +
> +	mtk_socinfop->soc_dev = soc_device_register(attrs);
> +	if (IS_ERR(mtk_socinfop->soc_dev))
> +		return PTR_ERR(mtk_socinfop->soc_dev);
> +
> +	dev_info(mtk_socinfop->dev, "%s %s SoC detected.\n", soc_manufacturer, attrs->machine);
> +	return 0;
> +}
> +
> +static u32 mtk_socinfo_read_cell(struct device *dev, const char *name)
> +{
> +	struct nvmem_device *nvmemp;
> +	struct device_node *np = dev->of_node;
> +	u32 offset;
> +	u32 cell_val = CELL_NOT_USED;
> +
> +	nvmemp = devm_nvmem_device_get(dev, "mtk-efuse0");

Are you sure that this is supposed to be "mtk-efuse0" and not "mtk-efuse"?
Looks strange.

Everything else looks ok.

Cheers,
Angelo




From david at redhat.com  Wed Dec 20 02:56:26 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 11:56:26 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
Message-ID: <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>

On 20.12.23 11:41, Ryan Roberts wrote:
> On 20/12/2023 10:16, David Hildenbrand wrote:
>> On 20.12.23 11:11, Ryan Roberts wrote:
>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of memory,
>>>>>>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>
>>>>>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous bit"
>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>>> range in the first place.
>>>>>>>>>>>
>>>>>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>
>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate change
>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>
>>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>
>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time for the
>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>>>>>>> positive is slower, compared to baseline upon which the series is based:
>>>>>>>>>>>
>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>
>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>
>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>> ---
>>>>>>>>>>>  ????? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>  ????? mm/memory.c???????????? | 92
>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>  ????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>  ????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>  ????? #endif
>>>>>>>>>>>  ????? +#ifndef pte_batch_remaining
>>>>>>>>>>> +/**
>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>> boundary.
>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>> + *
>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>>> batch of
>>>>>>>>>>> ptes.
>>>>>>>>>>> + * In such cases, this function returns the remaining number of pages to
>>>>>>>>>>> the end
>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>>>>>> iterating
>>>>>>>>>>> + * over ptes.
>>>>>>>>>>> + *
>>>>>>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>>>>>>> + */
>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long
>>>>>>>>>>> addr,
>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>> +{
>>>>>>>>>>> +??? return 1;
>>>>>>>>>>> +}
>>>>>>>>>>> +#endif
>>>>>>>>>>
>>>>>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>>>>>
>>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>>> require
>>>>>>>>>> arch
>>>>>>>>>> specifics?
>>>>>>>>>
>>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the only
>>>>>>>>> way
>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>
>>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt at an
>>>>>>>>> arch-specific version that didn't resolve to a compile-time constant 1
>>>>>>>>> still
>>>>>>>>> cost an extra 3%.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>
>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>
>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can get the
>>>>>>>>> regression under 4% with this. Further along the series I spent a lot of
>>>>>>>>> time
>>>>>>>>> having to fiddle with the arm64 implementation; every conditional and every
>>>>>>>>> memory read (even when in cache) was a problem. There is just so little in
>>>>>>>>> the
>>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra and
>>>>>>>>> Apple
>>>>>>>>> M2).
>>>>>>>>>
>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>> benefit to
>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd prefer to
>>>>>>>>> play
>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you previously
>>>>>>>>> suggested.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>>> series. I
>>>>>>>> implemented very generic and simple batching for large folios (all PTE bits
>>>>>>>> except the PFN have to match).
>>>>>>>>
>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>>> Silver
>>>>>>>> 4210R CPU.
>>>>>>>>
>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>
>>>>>>>> -> Around 1.7 % faster
>>>>>>>>
>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>
>>>>>>>> -> Around 36.3 % faster
>>>>>>>
>>>>>>> Well I guess that shows me :)
>>>>>>>
>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>
>>>>>>
>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>
>>>>> I've just been trying to compile and noticed this. Will take a look at your
>>>>> update.
>>>>>
>>>>> But upon review, I've noticed the part that I think makes this difficult for
>>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>>> pte in
>>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>>> changes, its ptep_get() has to read every pte in the contpte block in order to
>>>>> gather the access and dirty bits. So if your batching function ends up wealking
>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>> function; this allows the core-mm to skip to the end of the contpte block and
>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>>> instead
>>>>> of 256.
>>>>>
>>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid the
>>>>> bit
>>>>> gathering. But we have a similar problem in zap_pte_range() and that function
>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see patch 3
>>>>> in my series).
>>>>>
>>>>> I guess you are going to say that we should combine both approaches, so that
>>>>> your batching loop can skip forward an arch-provided number of ptes? That would
>>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>
>>>> You can overwrite the function or add special-casing internally, yes.
>>>>
>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()" and it
>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>
>>>
>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>
>>> How do you want to handle your patches? Do you want to clean them up and I'll
>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>
>> Whatever you prefer, it was mostly a quick prototype to see if we can achieve
>> decent performance.
> 
> I'm about to run it on Altra and M2. But I assume it will show similar results.
> 
>>
>> I can fixup the arch thingies (most should be easy, some might require a custom
>> pte_next_pfn())
> 
> Well if you're happy to do that, great! I'm keen to get the contpte stuff into
> v6.9 if at all possible, and I'm concious that I'm introducing more dependencies
> on you. And its about to be holiday season...

There is still plenty of time for 6.9. I'll try to get the rmap cleanup 
finished asap.

> 
>> and you can focus on getting cont-pte sorted out on top [I
>> assume that's what you want to work on :) ].
> 
> That's certainly what I'm focussed on. But I'm happy to do whatever is required
> to get it over the line. I guess I'll start by finishing my review of your v1
> rmap stuff.

I'm planning on sending out a new version today.

> 
>>
>>>
>>> As I see it at the moment, I would keep your folio_pte_batch() always core, but
>>> in subsequent patch, have it use pte_batch_remaining() (the arch function I have
>>> in my series, which defaults to one).
>>
>> Just double-checking, how would it use pte_batch_remaining() ?
> 
> I think something like this would do it (untested):
> 
> static inline int folio_pte_batch(struct folio *folio, unsigned long addr,
> 		pte_t *start_ptep, pte_t pte, int max_nr)
> {
> 	unsigned long folio_end_pfn = folio_pfn(folio) + folio_nr_pages(folio);
> 	pte_t expected_pte = pte_next_pfn(pte);
> 	pte_t *ptep = start_ptep;
> 	int nr;
> 
> 	for (;;) {
> 		nr = min(max_nr, pte_batch_remaining());
> 		ptep += nr;
> 		max_nr -= nr;
> 
> 		if (max_nr == 0)
> 			break;
> 

expected_pte would be messed up. We'd have to increment it a couple of 
times to make it match the nr of pages we're skipping.

> 		pte = ptep_get(ptep);
> 
> 		/* Do all PTE bits match, and the PFN is consecutive? */
> 		if (!pte_same(pte, expected_pte))
> 			break;
> 
> 		/*
> 		 * Stop immediately once we reached the end of the folio. In
> 		 * corner cases the next PFN might fall into a different
> 		 * folio.
> 		 */
> 		if (pte_pfn(pte) == folio_end_pfn - 1)
> 			break;
> 
> 		expected_pte = pte_next_pfn(expected_pte);
> 	}
> 
> 	return ptep - start_ptep;
> }
> 
> Of course, if we have the concept of a "pte batch" in the core-mm, then we might
> want to call the arch's thing something different; pte span? pte cont? pte cont
> batch? ...

So, you mean something like

/*
  * The architecture might be able to tell us efficiently using cont-pte
  * bits how many next PTEs are certainly compatible. So in that case,
  * simply skip forward.
  */
nr = min(max_nr, nr_cont_ptes(ptep));
...

I wonder if something simple at the start of the function might be good 
enough for arm with cont-pte as a first step:

nr = nr_cont_ptes(start_ptep)
if (nr != 1) {
	return min(max_nr, nr);
}

Which would get optimized out on other architectures.


-- 
Cheers,

David / dhildenb



From william-tw.lin at mediatek.com  Wed Dec 20 02:38:58 2023
From: william-tw.lin at mediatek.com (William-tw Lin)
Date: Wed, 20 Dec 2023 18:38:58 +0800
Subject: [PATCH v3 0/3] mtk-socinfo driver implementation
Message-ID: <20231220103901.22180-1-william-tw.lin@mediatek.com>

v3 changes:
changes dts:
1. remove socinfo node so mtk-socinfo can be registered from mtk-efuse
2. add unit address to mtk-socinfo nodes

mtk-socinfo.c:
1. add static to previously global variables
2. remove the check on soc_dev in mtk_socinfo_remove
3. Drop .owner from platform_driver mtk_socinfo
4. Instead of probing from devicetree, socinfo is registered from
mtk-efuse

mtk-efuse.c:
1. Add mtk-efuse name to nvmem_config to avoid confusion with future
nvmem nodes
2. register mtk-socinfo from mtk-efuse

William-tw Lin (3):
  arm64: dts: Add node for chip info driver
  soc: mediatek: mtk-socinfo: Add driver for getting chip information
  nvmem: mtk-efuse: Modify driver for getting chip information

 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   9 ++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi |   9 ++
 arch/arm64/boot/dts/mediatek/mt8186.dtsi |   4 +
 arch/arm64/boot/dts/mediatek/mt8192.dtsi |   8 +
 arch/arm64/boot/dts/mediatek/mt8195.dtsi |   3 +
 drivers/nvmem/mtk-efuse.c                |  11 +-
 drivers/soc/mediatek/Kconfig             |   8 +
 drivers/soc/mediatek/Makefile            |   1 +
 drivers/soc/mediatek/mtk-socinfo.c       | 186 +++++++++++++++++++++++
 9 files changed, 238 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soc/mediatek/mtk-socinfo.c

-- 
2.18.0



From angelogioacchino.delregno at collabora.com  Wed Dec 20 03:02:22 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 12:02:22 +0100
Subject: [PATCH v3 3/3] nvmem: mtk-efuse: Modify driver for getting chip
 information
In-Reply-To: <20231220103901.22180-4-william-tw.lin@mediatek.com>
References: <20231220103901.22180-1-william-tw.lin@mediatek.com>
 <20231220103901.22180-4-william-tw.lin@mediatek.com>
Message-ID: <80b61d00-ac87-4880-a535-0a5fdd3bed83@collabora.com>

Il 20/12/23 11:39, William-tw Lin ha scritto:
> Retrieval of soc info is needed. This patch includes the following:
> 1. Register socinfo device in mtk-efuse.c
> 

nvmem: mtk-efuse: Register MediaTek socinfo driver from efuse

The socinfo driver reads chip information from eFuses and does not need
any devicetree node. Register it from mtk-efuse.

While at it, also add the name for this driver's nvmem_config.


^^^ that's a proper commit title and description :-)

> Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
> ---
>   drivers/nvmem/mtk-efuse.c | 11 ++++++++++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 84f05b40a411..3914e039e288 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -68,6 +68,7 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>   	struct nvmem_config econfig = {};
>   	struct mtk_efuse_priv *priv;
>   	const struct mtk_efuse_pdata *pdata;
> +	struct platform_device *socinfo;
>   
>   	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>   	if (!priv)
> @@ -85,11 +86,19 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>   	econfig.size = resource_size(res);
>   	econfig.priv = priv;
>   	econfig.dev = dev;
> +	econfig.name = "mtk-efuse";
>   	if (pdata->uses_post_processing)
>   		econfig.fixup_dt_cell_info = &mtk_efuse_fixup_dt_cell_info;
>   	nvmem = devm_nvmem_register(dev, &econfig);
> +	if (IS_ERR(nvmem))
> +		return PTR_ERR(nvmem);
>   
> -	return PTR_ERR_OR_ZERO(nvmem);
> +	socinfo = platform_device_register_data(&pdev->dev, "mtk-socinfo",
> +						PLATFORM_DEVID_AUTO, NULL, 0);
> +	if (IS_ERR(socinfo))
> +		dev_info(dev, "MediaTek SoC Information will be unavailable\n");
> +

	if (IS_ERR(socinfo))
		dev_info(dev, "MediaTek SoC Information will be unavailable\n");

	platform_set_drvdata(pdev, socinfo);
	return 0;

> +	return 0;
>   }
>   
>   static const struct mtk_efuse_pdata mtk_mt8186_efuse_pdata = {


static void mtk_efuse_remove(struct platform_device *pdev)
{
	struct platform_device *socinfo = platform_get_drvdata(pdev);

	if (!IS_ERR_OR_NULL(socinfo))
		platform_device_unregister(socinfo);
}

static struct platform_driver mtk_efuse_driver = {
	.probe = mtk_efuse_probe,
	.remove_new = mtk_efuse_remove, <---- add this
	.driver = {
		.name = "mediatek,efuse",
		.of_match_table = mtk_efuse_of_match,
	}
};

After those additions, it's good for me.

Thanks,
Angelo


From angelogioacchino.delregno at collabora.com  Wed Dec 20 03:02:34 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 12:02:34 +0100
Subject: [PATCH v3 1/3] arm64: dts: Add node for chip info driver
In-Reply-To: <20231220103901.22180-2-william-tw.lin@mediatek.com>
References: <20231220103901.22180-1-william-tw.lin@mediatek.com>
 <20231220103901.22180-2-william-tw.lin@mediatek.com>
Message-ID: <81c4789d-e7b3-46c4-876c-954e8db9a7e2@collabora.com>

Il 20/12/23 11:38, William-tw Lin ha scritto:
> Add dts node for socinfo retrieval for the following projects:
> MT8173, MT8183, MT8186, MT8192, MT8195
> 

arm64: dts: mediatek: Add socinfo efuses to MT8173/83/96/92/95 SoCs

Add efuse nodes for socinfo retrieval for MT8173, MT8183, MT8186,
MT8192 and MT8195.



...because you're not adding a chipinfo node, but efuse nodes :-)


> Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
> ---
>   arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +++++++++
>   arch/arm64/boot/dts/mediatek/mt8183.dtsi | 9 +++++++++
>   arch/arm64/boot/dts/mediatek/mt8186.dtsi | 4 ++++
>   arch/arm64/boot/dts/mediatek/mt8192.dtsi | 8 ++++++++
>   arch/arm64/boot/dts/mediatek/mt8195.dtsi | 3 +++
>   5 files changed, 33 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index c47d7d900f28..06916e60679a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -590,6 +590,15 @@
>   			reg = <0 0x10206000 0 0x1000>;
>   			#address-cells = <1>;
>   			#size-cells = <1>;
> +
> +			socinfo_data1: socinfo-data1 at 40 {

Also, you don't need the phandles as those nodes will never be modified from
board specific devicetree, nor assigned to any devicetree node.

This means that you can go with just

			socinfo-data1 at 40 {
				reg ...
			}

same for data2 and for all SoCs.

Apart from that, looks good to me.

Cheers,
Angelo


From lukasz.luba at arm.com  Wed Dec 20 03:03:37 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Wed, 20 Dec 2023 11:03:37 +0000
Subject: [RFC PATCH 0/2] Introduce runtime modifiable Energy Model
Message-ID: <20231220110339.1065505-1-lukasz.luba@arm.com>

Hi all,

This is a follow-up patch aiming to show the users of the proposed
runtime modifiable Energy Model framework. The patches and discussion is
available here [1]. I didn't wanted to add more complexity in that
already big EM patch set and planned to add more users later.
This patch set is one of the first user. I have talked about the chip
binning in a few conferences and the need to update the EM after boot.
This Exynos is one of the platforms which adjust voltage after the EM
is registered. This is perfectly fine and alloed in the kernel, even
from a module so very late. The EM framework should just allow to
modify the power values after that.

This patch set will have to wait for merging of the dependet main EM
change. 

Regards,
Lukasz Luba

[1] https://lore.kernel.org/lkml/20231129110853.94344-1-lukasz.luba at arm.com/

Lukasz Luba (2):
  OPP: Add API to update EM after adjustment of voltage for OPPs
  soc: samsung: exynos-asv: Update Energy Model after adjusting voltage

 drivers/opp/of.c                 | 69 ++++++++++++++++++++++++++++++++
 drivers/soc/samsung/exynos-asv.c | 10 ++++-
 include/linux/pm_opp.h           |  6 +++
 3 files changed, 84 insertions(+), 1 deletion(-)

-- 
2.25.1



From lukasz.luba at arm.com  Wed Dec 20 03:03:38 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Wed, 20 Dec 2023 11:03:38 +0000
Subject: [PATCH 1/2] OPP: Add API to update EM after adjustment of voltage for OPPs
In-Reply-To: <20231220110339.1065505-1-lukasz.luba@arm.com>
References: <20231220110339.1065505-1-lukasz.luba@arm.com>
Message-ID: <20231220110339.1065505-2-lukasz.luba@arm.com>

There are device drivers which can modify voltage values for OPPs. It
could be due to the chip binning and those drivers have specific chip
knowledge about this. This adjustment can happen after Energy Model is
registered, thus EM can have stale data about power.

Introduce new API function which can be used by device driver which
adjusted the voltage for OPPs. The implementation takes care about
calculating needed internal details in the new EM table ('cost' field).
It plugs in the new EM table to the framework so other subsystems would
use the correct data.

Signed-off-by: Lukasz Luba <lukasz.luba at arm.com>
---
 drivers/opp/of.c       | 69 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm_opp.h |  6 ++++
 2 files changed, 75 insertions(+)

diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 81fa27599d58..992434c0b711 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -1596,3 +1596,72 @@ int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus)
 	return ret;
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_of_register_em);
+
+/**
+ * dev_pm_opp_of_update_em() - Update Energy Model with new power values
+ * @dev		: Device for which an Energy Model has to be registered
+ *
+ * This uses the "dynamic-power-coefficient" devicetree property to calculate
+ * power values for EM. It uses the new adjusted voltage values known for OPPs
+ * which have changed after boot.
+ */
+int dev_pm_opp_of_update_em(struct device *dev)
+{
+	struct em_perf_table __rcu *runtime_table;
+	struct em_perf_state *table, *new_table;
+	struct em_perf_domain *pd;
+	int ret, table_size, i;
+
+	if (IS_ERR_OR_NULL(dev))
+		return -EINVAL;
+
+	pd = em_pd_get(dev);
+	if (!pd) {
+		dev_warn(dev, "Couldn't find Energy Model %d\n", ret);
+		return -EINVAL;
+	}
+
+	runtime_table = em_allocate_table(pd);
+	if (!runtime_table) {
+		dev_warn(dev, "new EM allocation failed\n");
+		return -ENOMEM;
+	}
+
+	new_table = runtime_table->state;
+
+	table = em_get_table(pd);
+	/* Initialize data based on older EM table */
+	table_size = sizeof(struct em_perf_state) * pd->nr_perf_states;
+	memcpy(new_table, table, table_size);
+
+	em_put_table();
+
+	/* Update power values which might change due to new voltage in OPPs */
+	for (i = 0; i < pd->nr_perf_states; i++) {
+		unsigned long freq = new_table[i].frequency;
+		unsigned long power;
+
+		ret = _get_power(dev, &power, &freq);
+		if (ret)
+			goto failed;
+
+		new_table[i].power = power;
+	}
+
+	ret = em_dev_compute_costs(dev, new_table, pd->nr_perf_states);
+	if (ret)
+		goto failed;
+
+	ret = em_dev_update_perf_domain(dev, runtime_table);
+	if (ret)
+		goto failed;
+
+	return 0;
+
+failed:
+	dev_warn(dev, "EM update failed %d\n", ret);
+	em_free_table(runtime_table);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_update_em);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index ccd97bcef269..b3ab117890fc 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -464,6 +464,7 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
 int of_get_required_opp_performance_state(struct device_node *np, int index);
 int dev_pm_opp_of_find_icc_paths(struct device *dev, struct opp_table *opp_table);
 int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus);
+int dev_pm_opp_of_update_em(struct device *dev);
 static inline void dev_pm_opp_of_unregister_em(struct device *dev)
 {
 	em_dev_unregister_perf_domain(dev);
@@ -527,6 +528,11 @@ static inline void dev_pm_opp_of_unregister_em(struct device *dev)
 {
 }
 
+static inline int dev_pm_opp_of_update_em(struct device *dev)
+{
+	return -EOPNOTSUPP;
+}
+
 static inline int of_get_required_opp_performance_state(struct device_node *np, int index)
 {
 	return -EOPNOTSUPP;
-- 
2.25.1



From lukasz.luba at arm.com  Wed Dec 20 03:03:39 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Wed, 20 Dec 2023 11:03:39 +0000
Subject: [PATCH 2/2] soc: samsung: exynos-asv: Update Energy Model after adjusting voltage
In-Reply-To: <20231220110339.1065505-1-lukasz.luba@arm.com>
References: <20231220110339.1065505-1-lukasz.luba@arm.com>
Message-ID: <20231220110339.1065505-3-lukasz.luba@arm.com>

When the voltage for OPPs is adjusted there is a need to also update
Energy Model framework. The EM data contains power values which depend
on voltage values. The EM structure is used for thermal (IPA governor)
and in scheduler task placement (EAS) so it should reflect the real HW
model as best as possible to operate properly.

Based on data on Exynos5422 ASV tables the maximum power difference might
be ~29%. An Odroid-XU4 (with a random sample SoC in this chip lottery)
showed power difference for some OPPs ~20%. Therefore, it's worth to
update the EM.

Signed-off-by: Lukasz Luba <lukasz.luba at arm.com>
---
 drivers/soc/samsung/exynos-asv.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/samsung/exynos-asv.c b/drivers/soc/samsung/exynos-asv.c
index d60af8acc391..328f079423d6 100644
--- a/drivers/soc/samsung/exynos-asv.c
+++ b/drivers/soc/samsung/exynos-asv.c
@@ -97,9 +97,17 @@ static int exynos_asv_update_opps(struct exynos_asv *asv)
 			last_opp_table = opp_table;
 
 			ret = exynos_asv_update_cpu_opps(asv, cpu);
-			if (ret < 0)
+			if (!ret) {
+				/*
+				 * When the voltage for OPPs successfully
+				 * changed, update the EM power values to
+				 * reflect the reality and not use stale data
+				 */
+				dev_pm_opp_of_update_em(cpu);
+			} else {
 				dev_err(asv->dev, "Couldn't udate OPPs for cpu%d\n",
 					cpuid);
+			}
 		}
 
 		dev_pm_opp_put_opp_table(opp_table);
-- 
2.25.1



From suzuki.poulose at arm.com  Wed Dec 20 03:07:04 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Wed, 20 Dec 2023 11:07:04 +0000
Subject: [PATCH v3 6/8] coresight-tpdm: Add timestamp control register
 support for the CMB
In-Reply-To: <b7ef4e75-69c6-4251-8f9c-58682699e3f6@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-7-git-send-email-quic_taozha@quicinc.com>
 <ebd7e310-d1b4-4b2e-a915-6241e04763d4@arm.com>
 <b61c3d70-7277-4fe7-ab67-8afc1062c737@quicinc.com>
 <cdad425c-b965-44c7-a612-1c99341e95b9@arm.com>
 <b7ef4e75-69c6-4251-8f9c-58682699e3f6@quicinc.com>
Message-ID: <cc7b83ec-2c97-4a5d-87a9-36f1e13d8fc4@arm.com>

On 20/12/2023 09:51, Tao Zhang wrote:
> 
> On 12/19/2023 9:51 PM, Suzuki K Poulose wrote:
>> On 19/12/2023 02:43, Tao Zhang wrote:
>>>
>>> On 12/18/2023 6:46 PM, Suzuki K Poulose wrote:
>>>> On 21/11/2023 02:24, Tao Zhang wrote:
>>>>> CMB_TIER register is CMB subunit timestamp insertion enable register.
>>>>> Bit 0 is PATT_TSENAB bit. Set this bit to 1 to request a timestamp
>>>>> following a CMB interface pattern match. Bit 1 is XTRIG_TSENAB bit.
>>>>> Set this bit to 1 to request a timestamp following a CMB CTI timestamp
>>>>> request. Bit 2 is TS_ALL bit. Set this bit to 1 to request timestamp
>>>>> for all packets.
>>>>>
>>>>> Reviewed-by: James Clark <james.clark at arm.com>
>>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>>> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
>>>>> ---
>>>>> ? .../testing/sysfs-bus-coresight-devices-tpdm? |? 35 ++++++
>>>>> ? drivers/hwtracing/coresight/coresight-tpdm.c? | 116 
>>>>> +++++++++++++++++-
>>>>> ? drivers/hwtracing/coresight/coresight-tpdm.h? |? 14 +++
>>>>> ? 3 files changed, 162 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git 
>>>>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm 
>>>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>>> index 53662ce7c2d0..e0b77107be13 100644
>>>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>>> @@ -214,3 +214,38 @@ KernelVersion??? 6.7
>>>>> ? Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>> ? Description:
>>>>> ????????? (RW) Set/Get the mask of the pattern for the CMB subunit 
>>>>> TPDM.
>>>>> +
>>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
>>>>> +Date:??????? September 2023
>>>>> +KernelVersion??? 6.7
>>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>> +Description:
>>>>> +??????? (Write) Set the pattern timestamp of CMB tpdm. Read
>>>>> +??????? the pattern timestamp of CMB tpdm.
>>>>> +
>>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>>> +??????? 0 : Disable CMB pattern timestamp.
>>>>> +??????? 1 : Enable CMB pattern timestamp.
>>>>> +
>>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
>>>>> +Date:??????? September 2023
>>>>> +KernelVersion??? 6.7
>>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>> +Description:
>>>>> +??????? (RW) Set/Get the trigger timestamp of the CMB for tpdm.
>>>>> +
>>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>>> +??????? 0 : Set the CMB trigger type to false
>>>>> +??????? 1 : Set the CMB trigger type to true
>>>>> +
>>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
>>>>> +Date:??????? September 2023
>>>>> +KernelVersion??? 6.7
>>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>> +Description:
>>>>> +??????? (RW) Read or write the status of timestamp upon all 
>>>>> interface.
>>>>> +??????? Only value 0 and 1? can be written to this node. Set this 
>>>>> node to 1 to requeset
>>>>> +??????? timestamp to all trace packet.
>>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>>> +??????? 0 : Disable the timestamp of all trace packets.
>>>>> +??????? 1 : Enable the timestamp of all trace packets.
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>>>>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> index 894d4309f1c7..f6cda5616e84 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> @@ -331,6 +331,36 @@ static void tpdm_enable_dsb(struct 
>>>>> tpdm_drvdata *drvdata)
>>>>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>>>>> ? }
>>>>> ? +static void set_cmb_tier(struct tpdm_drvdata *drvdata)
>>>>> +{
>>>>> +??? u32 val;
>>>>> +
>>>>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_TIER);
>>>>> +
>>>>> +??? /* Clear all relevant fields */
>>>>> +??? val &= ~(TPDM_CMB_TIER_PATT_TSENAB | TPDM_CMB_TIER_TS_ALL |
>>>>> +???????? TPDM_CMB_TIER_XTRIG_TSENAB);
>>>>> +
>>>>> +??? /* Set pattern timestamp type and enablement */
>>>>> +??? if (drvdata->cmb->patt_ts)
>>>>> +??????? val |= TPDM_CMB_TIER_PATT_TSENAB;
>>>>
>>>> ?-- cut --
>>>>> +??? else
>>>>> +??????? val &= ~TPDM_CMB_TIER_PATT_TSENAB;
>>>>
>>>>
>>>> All the else cases in this function are superfluous. Please remove all
>>>> of them.
>>> I will update this in the next patch.
>>>>
>>>>> +
>>>>> +??? /* Set trigger timestamp */
>>>>> +??? if (drvdata->cmb->trig_ts)
>>>>> +??????? val |= TPDM_CMB_TIER_XTRIG_TSENAB;
>>>>> +??? else
>>>>> +??????? val &= ~TPDM_CMB_TIER_XTRIG_TSENAB;
>>>>> +
>>>>> +??? /* Set all timestamp enablement*/
>>>>> +??? if (drvdata->cmb->ts_all)
>>>>> +??????? val |= TPDM_CMB_TIER_TS_ALL;
>>>>> +??? else
>>>>> +??????? val &= ~TPDM_CMB_TIER_TS_ALL;
>>>>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>>>>> +}
>>>>> +
>>>>> ? static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>>>>> ? {
>>>>> ????? u32 val, i;
>>>>> @@ -347,6 +377,8 @@ static void tpdm_enable_cmb(struct tpdm_drvdata 
>>>>> *drvdata)
>>>>> ????????????????? drvdata->base + TPDM_CMB_XPMR(i));
>>>>> ????? }
>>>>> ? +??? set_cmb_tier(drvdata);
>>>>> +
>>>>> ????? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>>>> ????? /*
>>>>> ?????? * Set to 0 for continuous CMB collection mode,
>>>>> @@ -695,9 +727,17 @@ static ssize_t enable_ts_show(struct device *dev,
>>>>> ??????????????????? char *buf)
>>>>> ? {
>>>>> ????? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>> +??? ssize_t size = 0;
>>>>> ? -??? return sysfs_emit(buf, "%u\n",
>>>>> -???????????? (unsigned int)drvdata->dsb->patt_ts);
>>>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>>>> +??????? size = sysfs_emit(buf, "%u\n",
>>>>> +???????????????? (unsigned int)drvdata->dsb->patt_ts);
>>>>> +
>>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>>> +??????? size = sysfs_emit(buf, "%u\n",
>>>>> +???????????????? (unsigned int)drvdata->cmb->patt_ts);
>>>>
>>>> Why does this need to show two values ? This must only show ONE value.
>>>> How you deduce that might be based on the availability of the feature
>>>> set. Or store the TS value in the drvdata and use that instead for
>>>> controlling CMB/DSB.
>>>
>>> Since both of CMB/DSB need to have "enable_ts" SysFs file, can I 
>>> separate them
>>
>> The question really is, do we need fine grained control. i.e.,
>>
>> enable TS for DSB but not for CMB or vice versa.
>>
>> I am not an expert on the usage scenario of the same. So, if you/Qcomm
>> thinks the users need separate, fine grained control for timestamp
>> for the DSB and CMB, then yes, follow your recommendation below.
>> i.e., tpdm.../dsb_patt/enable_ts
>>
>>> as "enable_dsb_ts" and "enable_cmb_ts"? The path will be like below.
>>>
>>> tpdm0/dsb_patt/enable_dsb_ts
>>
>> You don't need enable_dsb_ts. It could be "enable_ts"
>>
>>>
>>> tpdm1/cmb_patt/enable_cmb_ts
>>>
>>> Is this design appropriate?
>>
>>
>> Otherwise, stick to single enable_ts : which enables the ts for both
>> CMB/DSB. And it only ever show one value : 0 (TS is disabled for both
>> CMB/DSB) 1 : TS enabled for both.
> 
> We have a very special case, such as the TPDM supporting both CMB and
> 
> DSB datasets. Although this case is very rare, it still exists.
> 
> Can I use the data bit to instruct whether timestamp is enabled for 
> CMB/DSB or not? For example,
> 
> size = sysfs_emit(buf, "%u\n",
>  ??? ??? ??? ??? (unsigned int)(drvdata->dsb->patt_ts << 1 | 
> drvdata->cmb->patt_ts));
> 
> Thus, this value can instruct the following situations.
> 
> 0 - TS is disabled for both CMB/DSB
> 
> 1 - TS is enabled for CMB
> 
> 2 - TS is enabled for DSB
> 
> 3 - TS is enabled for both
> 
> Is this approach acceptable?
> 

No, please stick to separate controls for TS. Do not complicate
the user interface.

i.e.,
tpdm0/dsb_patt/enable_ts
tpdm0/cmb_patt/enable_ts

Suzuki


> 
> Best,
> 
> Tao
> 
>>
>> Suzuki
>>
>>
>>>>
>>
>>>> Also, the sysfs documentation needs update, if this is going to
>>>> control the CMB.
>>>
>>> Sure. I will update the SysFs documentation according to the 
>>> modification in the
>>>
>>> next patch series.
>>>
>>>
>>> Best,
>>>
>>> Tao
>>>
>>>>
>>>> Suzuki
>>>>
>>>>
>>>>> +
>>>>> +??? return size;
>>>>> ? }
>>>>> ? ? /*
>>>>> @@ -715,8 +755,13 @@ static ssize_t enable_ts_store(struct device 
>>>>> *dev,
>>>>> ????????? return -EINVAL;
>>>>> ? ????? spin_lock(&drvdata->spinlock);
>>>>> -??? drvdata->dsb->patt_ts = !!val;
>>>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>>>> +??????? drvdata->dsb->patt_ts = !!val;
>>>>> +
>>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>>> +??????? drvdata->cmb->patt_ts = !!val;
>>>>> ????? spin_unlock(&drvdata->spinlock);
>>>>> +
>>>>> ????? return size;
>>>>> ? }
>>>>> ? static DEVICE_ATTR_RW(enable_ts);
>>>>> @@ -851,6 +896,68 @@ static ssize_t cmb_mode_store(struct device *dev,
>>>>> ? }
>>>>> ? static DEVICE_ATTR_RW(cmb_mode);
>>>>> ? +static ssize_t cmb_ts_all_show(struct device *dev,
>>>>> +?????????????????? struct device_attribute *attr,
>>>>> +?????????????????? char *buf)
>>>>> +{
>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>> +
>>>>> +??? return sysfs_emit(buf, "%u\n",
>>>>> +????????????? (unsigned int)drvdata->cmb->ts_all);
>>>>> +}
>>>>> +
>>>>> +static ssize_t cmb_ts_all_store(struct device *dev,
>>>>> +??????????????? struct device_attribute *attr,
>>>>> +??????????????? const char *buf,
>>>>> +??????????????? size_t size)
>>>>> +{
>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>> +??? unsigned long val;
>>>>> +
>>>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>>>> +??????? return -EINVAL;
>>>>> +
>>>>> +??? spin_lock(&drvdata->spinlock);
>>>>> +??? if (val)
>>>>> +??????? drvdata->cmb->ts_all = true;
>>>>> +??? else
>>>>> +??????? drvdata->cmb->ts_all = false;
>>>>> +??? spin_unlock(&drvdata->spinlock);
>>>>> +??? return size;
>>>>> +}
>>>>> +static DEVICE_ATTR_RW(cmb_ts_all);
>>>>> +
>>>>> +static ssize_t cmb_trig_ts_show(struct device *dev,
>>>>> +??????????????? struct device_attribute *attr,
>>>>> +??????????????? char *buf)
>>>>> +{
>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>> +
>>>>> +??? return sysfs_emit(buf, "%u\n",
>>>>> +????????????? (unsigned int)drvdata->cmb->trig_ts);
>>>>> +}
>>>>> +
>>>>> +static ssize_t cmb_trig_ts_store(struct device *dev,
>>>>> +???????????????? struct device_attribute *attr,
>>>>> +???????????????? const char *buf,
>>>>> +???????????????? size_t size)
>>>>> +{
>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>> +??? unsigned long val;
>>>>> +
>>>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>>>> +??????? return -EINVAL;
>>>>> +
>>>>> +??? spin_lock(&drvdata->spinlock);
>>>>> +??? if (val)
>>>>> +??????? drvdata->cmb->trig_ts = true;
>>>>> +??? else
>>>>> +??????? drvdata->cmb->trig_ts = false;
>>>>> +??? spin_unlock(&drvdata->spinlock);
>>>>> +??? return size;
>>>>> +}
>>>>> +static DEVICE_ATTR_RW(cmb_trig_ts);
>>>>> +
>>>>> ? static struct attribute *tpdm_dsb_edge_attrs[] = {
>>>>> ????? &dev_attr_ctrl_idx.attr,
>>>>> ????? &dev_attr_ctrl_val.attr,
>>>>> @@ -973,6 +1080,7 @@ static struct attribute *tpdm_cmb_patt_attrs[] 
>>>>> = {
>>>>> ????? CMB_PATT_ATTR(1),
>>>>> ????? CMB_PATT_MASK_ATTR(0),
>>>>> ????? CMB_PATT_MASK_ATTR(1),
>>>>> +??? &dev_attr_enable_ts.attr,
>>>>> ????? NULL,
>>>>> ? };
>>>>> ? @@ -985,6 +1093,8 @@ static struct attribute *tpdm_dsb_attrs[] = {
>>>>> ? ? static struct attribute *tpdm_cmb_attrs[] = {
>>>>> ????? &dev_attr_cmb_mode.attr,
>>>>> +??? &dev_attr_cmb_ts_all.attr,
>>>>> +??? &dev_attr_cmb_trig_ts.attr,
>>>>> ????? NULL,
>>>>> ? };
>>>>> ? diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>>>>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> index e90d008c1cb2..65b7ca6c4077 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> @@ -11,6 +11,8 @@
>>>>> ? ? /* CMB Subunit Registers */
>>>>> ? #define TPDM_CMB_CR??????? (0xA00)
>>>>> +/*CMB subunit timestamp insertion enable register*/
>>>>> +#define TPDM_CMB_TIER??????? (0xA04)
>>>>> ? /*CMB subunit timestamp pattern registers*/
>>>>> ? #define TPDM_CMB_TPR(n)??????? (0xA08 + (n * 4))
>>>>> ? /*CMB subunit timestamp pattern mask registers*/
>>>>> @@ -24,6 +26,12 @@
>>>>> ? #define TPDM_CMB_CR_ENA??????? BIT(0)
>>>>> ? /* Trace collection mode for CMB subunit */
>>>>> ? #define TPDM_CMB_CR_MODE??? BIT(1)
>>>>> +/* Timestamp control for pattern match */
>>>>> +#define TPDM_CMB_TIER_PATT_TSENAB??? BIT(0)
>>>>> +/* CMB CTI timestamp request */
>>>>> +#define TPDM_CMB_TIER_XTRIG_TSENAB??? BIT(1)
>>>>> +/* For timestamp fo all trace */
>>>>> +#define TPDM_CMB_TIER_TS_ALL??????? BIT(2)
>>>>> ? ? /*Patten register number*/
>>>>> ? #define TPDM_CMB_MAX_PATT??????? 2
>>>>> @@ -217,6 +225,9 @@ struct dsb_dataset {
>>>>> ?? * @patt_mask:??????? Save value for pattern mask
>>>>> ?? * @trig_patt:??????? Save value for trigger pattern
>>>>> ?? * @trig_patt_mask:?? Save value for trigger pattern mask
>>>>> + * @patt_ts:????????? Indicates if pattern match for timestamp is 
>>>>> enabled.
>>>>> + * @trig_ts:????????? Indicates if CTI trigger for timestamp is 
>>>>> enabled.
>>>>> + * @ts_all:?????????? Indicates if timestamp is enabled for all 
>>>>> packets.
>>>>> ?? */
>>>>> ? struct cmb_dataset {
>>>>> ????? u32??????????? trace_mode;
>>>>> @@ -224,6 +235,9 @@ struct cmb_dataset {
>>>>> ????? u32??????????? patt_mask[TPDM_CMB_MAX_PATT];
>>>>> ????? u32??????????? trig_patt[TPDM_CMB_MAX_PATT];
>>>>> ????? u32??????????? trig_patt_mask[TPDM_CMB_MAX_PATT];
>>>>> +??? bool??????????? patt_ts;
>>>>> +??? bool??????????? trig_ts;
>>>>> +??? bool??????????? ts_all;
>>>>> ? };
>>>>> ? ? /**
>>>>
>>
>> _______________________________________________
>> CoreSight mailing list -- coresight at lists.linaro.org
>> To unsubscribe send an email to coresight-leave at lists.linaro.org



From linus.walleij at linaro.org  Wed Dec 20 03:13:54 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 20 Dec 2023 12:13:54 +0100
Subject: [PATCH 2/2] firmware: xilinx: Remove zynqmp_pm_pinctrl_get_function()
In-Reply-To: <e52a415a004e28a43e6d08e9e22d9e8fef3737df.1702565618.git.michal.simek@amd.com>
References: <6ccbffbafd1f0f48f6574d5a3bf2db6a5603fdb0.1702565618.git.michal.simek@amd.com>
 <e52a415a004e28a43e6d08e9e22d9e8fef3737df.1702565618.git.michal.simek@amd.com>
Message-ID: <CACRpkdbso5A0muF6yqVyTquX+uPLTQCUpC0CF8DvR1_-uU0frQ@mail.gmail.com>

On Thu, Dec 14, 2023 at 3:54?PM Michal Simek <michal.simek at amd.com> wrote:

> There is no user for this interface that's why remove it.
>
> Signed-off-by: Michal Simek <michal.simek at amd.com>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

I assume this will be merged in some other git tree, tell me if it
should be merged through the pinctrl tree.

Yours,
Linus Walleij


From shengjiu.wang at nxp.com  Wed Dec 20 02:33:09 2023
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Wed, 20 Dec 2023 18:33:09 +0800
Subject: [PATCH] clk: imx: pll14xx: change naming of fvco to fout
Message-ID: <1703068389-6130-1-git-send-email-shengjiu.wang@nxp.com>

pll14xx_calc_rate() output the fout clock not the fvco clock
The relation of fvco and fout is:
	fout = fvco / (1 << sdiv)

So use correct naming for the clock.

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
---
 drivers/clk/imx/clk-pll14xx.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index 0d58d85c375e..d63564dbb12c 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -104,15 +104,15 @@ static const struct imx_pll14xx_rate_table *imx_get_pll_settings(
 static long pll14xx_calc_rate(struct clk_pll14xx *pll, int mdiv, int pdiv,
 			      int sdiv, int kdiv, unsigned long prate)
 {
-	u64 fvco = prate;
+	u64 fout = prate;
 
-	/* fvco = (m * 65536 + k) * Fin / (p * 65536) */
-	fvco *= (mdiv * 65536 + kdiv);
+	/* fout = (m * 65536 + k) * Fin / (p * 65536) / (1 << sdiv) */
+	fout *= (mdiv * 65536 + kdiv);
 	pdiv *= 65536;
 
-	do_div(fvco, pdiv << sdiv);
+	do_div(fout, pdiv << sdiv);
 
-	return fvco;
+	return fout;
 }
 
 static long pll1443x_calc_kdiv(int mdiv, int pdiv, int sdiv,
@@ -131,7 +131,7 @@ static void imx_pll14xx_calc_settings(struct clk_pll14xx *pll, unsigned long rat
 {
 	u32 pll_div_ctl0, pll_div_ctl1;
 	int mdiv, pdiv, sdiv, kdiv;
-	long fvco, rate_min, rate_max, dist, best = LONG_MAX;
+	long fout, rate_min, rate_max, dist, best = LONG_MAX;
 	const struct imx_pll14xx_rate_table *tt;
 
 	/*
@@ -143,6 +143,7 @@ static void imx_pll14xx_calc_settings(struct clk_pll14xx *pll, unsigned long rat
 	 * d) -32768 <= k <= 32767
 	 *
 	 * fvco = (m * 65536 + k) * prate / (p * 65536)
+	 * fout = (m * 65536 + k) * prate / (p * 65536) / (1 << sdiv)
 	 */
 
 	/* First try if we can get the desired rate from one of the static entries */
@@ -173,8 +174,8 @@ static void imx_pll14xx_calc_settings(struct clk_pll14xx *pll, unsigned long rat
 		pr_debug("%s: in=%ld, want=%ld Only adjust kdiv %ld -> %d\n",
 			 clk_hw_get_name(&pll->hw), prate, rate,
 			 FIELD_GET(KDIV_MASK, pll_div_ctl1), kdiv);
-		fvco = pll14xx_calc_rate(pll, mdiv, pdiv, sdiv, kdiv, prate);
-		t->rate = (unsigned int)fvco;
+		fout = pll14xx_calc_rate(pll, mdiv, pdiv, sdiv, kdiv, prate);
+		t->rate = (unsigned int)fout;
 		t->mdiv = mdiv;
 		t->pdiv = pdiv;
 		t->sdiv = sdiv;
@@ -190,13 +191,13 @@ static void imx_pll14xx_calc_settings(struct clk_pll14xx *pll, unsigned long rat
 			mdiv = clamp(mdiv, 64, 1023);
 
 			kdiv = pll1443x_calc_kdiv(mdiv, pdiv, sdiv, rate, prate);
-			fvco = pll14xx_calc_rate(pll, mdiv, pdiv, sdiv, kdiv, prate);
+			fout = pll14xx_calc_rate(pll, mdiv, pdiv, sdiv, kdiv, prate);
 
 			/* best match */
-			dist = abs((long)rate - (long)fvco);
+			dist = abs((long)rate - (long)fout);
 			if (dist < best) {
 				best = dist;
-				t->rate = (unsigned int)fvco;
+				t->rate = (unsigned int)fout;
 				t->mdiv = mdiv;
 				t->pdiv = pdiv;
 				t->sdiv = sdiv;
-- 
2.34.1



From james.clark at arm.com  Wed Dec 20 03:15:37 2023
From: james.clark at arm.com (James Clark)
Date: Wed, 20 Dec 2023 11:15:37 +0000
Subject: [PATCH 3/3] perf scripts python: arm-cs-trace-disasm.py: do not
 ignore disam first sample
In-Reply-To: <20231214123304.34087-4-tianruidong@linux.alibaba.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
 <20231214123304.34087-4-tianruidong@linux.alibaba.com>
Message-ID: <f9be9348-52e7-7a35-1a4b-f37d4f3cd1ef@arm.com>



On 14/12/2023 12:33, Ruidong Tian wrote:
> arm-cs-trace-disasm ignore disam the first branch sample, For example as
> follow, the instructions beteween 0x0000ffffae878750 and
> 0x0000ffffae878754 is lose:
> 
>   ARM CoreSight Trace Data Assembler Dump
>   Event type: branches:uH
>   Sample = { cpu: 0000 addr: 0x0000ffffae878750 phys_addr: 0x0000000000000000 ip: 0x0000000000000000 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
>   Event type: branches:uH
>   Sample = { cpu: 0000 addr: 0x0000000000000000 phys_addr: 0x0000000000000000 ip: 0x0000ffffae878754 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
> 
> Initialize cpu_data earlier to fix it:
> 
>   ARM CoreSight Trace Data Assembler Dump
>   Event type: branches:uH
>   Sample = { cpu: 0000 addr: 0x0000000000000000 phys_addr: 0x0000000000000000 ip: 0x0000ffffae878754 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
>         0000000000028740 <ioctl>: (base address is 0x0000ffffae850000)
>            28750: b13ffc1f      cmn     x0, #4095
>            28754: 54000042      b.hs    0x2875c <ioctl+0x1c>
>             test 4003489/4003489 [0000]     26765.151766034  __GI___ioctl+0x14                        /usr/lib64/libc-2.32.so
>   Event type: branches:uH
>   Sample = { cpu: 0000 addr: 0x0000ffffa67535ac phys_addr: 0x0000000000000000 ip: 0x0000000000000000 pid: 4003489 tid: 4003489 period: 1 time: 26765151766034 }
> 
> Signed-off-by: Ruidong Tian <tianruidong at linux.alibaba.com>

I noticed that this is for the missing second branch sample. Technically
the first one is also still missing, but it doesn't have the origin set,
only the destination, so I'm not sure if we need to do anything with it,
but the first one always looks like this:

  0 [unknown] ([unknown]) =>     ffff8a3b9100 _start+0x0

Followed by this one which you now generate the disassembly for:

  ffff8a3b9104 _start+0x4 (ld-2.31.so) => ffff8a3b9b80 _dl_start+0x0

Either way:

Reviewed-by: James Clark <james.clark at arm.com>

> ---
>  .../scripts/python/arm-cs-trace-disasm.py     | 21 ++++++++++---------
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> index c9e14af5b58c..b1eb4293cbef 100755
> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> @@ -190,6 +190,17 @@ def process_event(param_dict):
>  	dso_end = get_optional(param_dict, "dso_map_end")
>  	symbol = get_optional(param_dict, "symbol")
>  
> +	cpu = sample["cpu"]
> +	ip = sample["ip"]
> +	addr = sample["addr"]
> +
> +	# Initialize CPU data if it's empty, and directly return back
> +	# if this is the first tracing event for this CPU.
> +	if (cpu_data.get(str(cpu) + 'addr') == None):
> +		cpu_data[str(cpu) + 'addr'] = addr
> +		return
> +
> +
>  	if (options.verbose == True):
>  		print("Event type: %s" % name)
>  		print_sample(sample)
> @@ -211,16 +222,6 @@ def process_event(param_dict):
>  	if (name[0:8] != "branches"):
>  		return
>  
> -	cpu = sample["cpu"]
> -	ip = sample["ip"]
> -	addr = sample["addr"]
> -
> -	# Initialize CPU data if it's empty, and directly return back
> -	# if this is the first tracing event for this CPU.
> -	if (cpu_data.get(str(cpu) + 'addr') == None):
> -		cpu_data[str(cpu) + 'addr'] = addr
> -		return
> -
>  	# The format for packet is:
>  	#
>  	#		  +------------+------------+------------+


From knaerzche at gmail.com  Wed Dec 20 03:16:14 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Wed, 20 Dec 2023 12:16:14 +0100
Subject: [PATCH v2 1/3] ARM: dts: rockchip: Add psci for rk3036
In-Reply-To: <20231218105523.2478315-2-andyshrk@163.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
 <20231218105523.2478315-2-andyshrk@163.com>
Message-ID: <da10e2fc-3179-4bd5-88ed-b4d5f64a7191@gmail.com>

Hi Andy,
Am 18.12.23 um 11:55 schrieb Andy Yan:
> From: Andy Yan <andy.yan at rock-chips.com>
> 
> The system will hang at bringup secondary CPUs
> without psci node.
> 
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> 
> ---
> 
> (no changes since v1)
> 
>   arch/arm/boot/dts/rockchip/rk3036.dtsi | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> index 78686fc72ce6..5344803442a1 100644
> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> @@ -67,6 +67,11 @@ display-subsystem {
>   		ports = <&vop_out>;
>   	};
>   
> +	psci {
> +		compatible = "arm,psci-1.0";
> +		method = "smc";
> +	};
> +
I don't think that's an good idea. You most likely need that because you 
have downstream bootloader installed on this board. PSCI implementation 
takes place in TEE-OS for Rockchips ARM SoCs. There is no support for 
RK3036 in upstream op-tee OS. It's pretty much the same for RK3128 and 
RK3288.
If you use upstream u-boot it should be good as-is.

Alex
>   	timer {
>   		compatible = "arm,armv7-timer";
>   		arm,cpu-registers-not-fw-configured;



From linus.walleij at linaro.org  Wed Dec 20 03:23:30 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 20 Dec 2023 12:23:30 +0100
Subject: [PATCH] pinctrl: at91-pio4: use dedicated lock class for IRQ
In-Reply-To: <20231215-lockdep_warning-v1-1-8137b2510ed5@bootlin.com>
References: <20231215-lockdep_warning-v1-1-8137b2510ed5@bootlin.com>
Message-ID: <CACRpkdYVg47zfPgZFcPyXjTX-p_o-HFALBh1FaDOgmDaomypew@mail.gmail.com>

On Fri, Dec 15, 2023 at 10:35?PM Alexis Lothor?
<alexis.lothore at bootlin.com> wrote:

> Trying to suspend to RAM on SAMA5D27 EVK leads to the following lockdep
> warning:
>
>  ============================================
>  WARNING: possible recursive locking detected
>  6.7.0-rc5-wt+ #532 Not tainted
>  --------------------------------------------
>  sh/92 is trying to acquire lock:
>  c3cf306c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100
>
>  but task is already holding lock:
>  c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100
>
>  other info that might help us debug this:
>   Possible unsafe locking scenario:
>
>         CPU0
>         ----
>    lock(&irq_desc_lock_class);
>    lock(&irq_desc_lock_class);
>
>   *** DEADLOCK ***
>
>   May be due to missing lock nesting notation
>
>  6 locks held by sh/92:
>   #0: c3aa0258 (sb_writers#6){.+.+}-{0:0}, at: ksys_write+0xd8/0x178
>   #1: c4c2df44 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x138/0x284
>   #2: c32684a0 (kn->active){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x148/0x284
>   #3: c232b6d4 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x13c/0x4e8
>   #4: c387b088 (&dev->mutex){....}-{3:3}, at: __device_suspend+0x1e8/0x91c
>   #5: c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100
>
>  stack backtrace:
>  CPU: 0 PID: 92 Comm: sh Not tainted 6.7.0-rc5-wt+ #532
>  Hardware name: Atmel SAMA5
>   unwind_backtrace from show_stack+0x18/0x1c
>   show_stack from dump_stack_lvl+0x34/0x48
>   dump_stack_lvl from __lock_acquire+0x19ec/0x3a0c
>   __lock_acquire from lock_acquire.part.0+0x124/0x2d0
>   lock_acquire.part.0 from _raw_spin_lock_irqsave+0x5c/0x78
>   _raw_spin_lock_irqsave from __irq_get_desc_lock+0xe8/0x100
>   __irq_get_desc_lock from irq_set_irq_wake+0xa8/0x204
>   irq_set_irq_wake from atmel_gpio_irq_set_wake+0x58/0xb4
>   atmel_gpio_irq_set_wake from irq_set_irq_wake+0x100/0x204
>   irq_set_irq_wake from gpio_keys_suspend+0xec/0x2b8
>   gpio_keys_suspend from dpm_run_callback+0xe4/0x248
>   dpm_run_callback from __device_suspend+0x234/0x91c
>   __device_suspend from dpm_suspend+0x224/0x43c
>   dpm_suspend from dpm_suspend_start+0x9c/0xa8
>   dpm_suspend_start from suspend_devices_and_enter+0x1e0/0xa84
>   suspend_devices_and_enter from pm_suspend+0x460/0x4e8
>   pm_suspend from state_store+0x78/0xe4
>   state_store from kernfs_fop_write_iter+0x1a0/0x284
>   kernfs_fop_write_iter from vfs_write+0x38c/0x6f4
>   vfs_write from ksys_write+0xd8/0x178
>   ksys_write from ret_fast_syscall+0x0/0x1c
>  Exception stack(0xc52b3fa8 to 0xc52b3ff0)
>  3fa0:                   00000004 005a0ae8 00000001 005a0ae8 00000004 00000001
>  3fc0: 00000004 005a0ae8 00000001 00000004 00000004 b6c616c0 00000020 0059d190
>  3fe0: 00000004 b6c61678 aec5a041 aebf1a26
>
> This warning is raised because pinctrl-at91-pio4 uses chained IRQ. Whenever
> a wake up source configures an IRQ through irq_set_irq_wake, it will
> lock the corresponding IRQ desc, and then call irq_set_irq_wake on "parent"
> IRQ which will do the same on its own IRQ desc, but since those two locks
> share the same class, lockdep reports this as an issue.
>
> Fix lockdep false positive by setting a different class for parent and
> children IRQ
>
> Fixes: 776180848b57 ("pinctrl: introduce driver for Atmel PIO4 controller")
> Signed-off-by: Alexis Lothor? <alexis.lothore at bootlin.com>

This is a serious bug, what do the PIO4 maintainers say?

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Dec 20 03:24:49 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 20 Dec 2023 12:24:49 +0100
Subject: [PATCH] dmaengine: std_dma40: fix kernel-doc warnings and spelling
In-Reply-To: <20231218060834.19222-1-rdunlap@infradead.org>
References: <20231218060834.19222-1-rdunlap@infradead.org>
Message-ID: <CACRpkdZqf0osxfBT2n-Gri4CiQpFgKUkXOsp3W=UrBGN9vQ=_A@mail.gmail.com>

On Mon, Dec 18, 2023 at 7:08?AM Randy Dunlap <rdunlap at infradead.org> wrote:

> Correct kernel-doc warnings as reported by kernel test robot:
>
> ste_dma40.c:57: warning: Excess struct member 'dev_tx' description in 'stedma40_platform_data'
> ste_dma40.c:57: warning: Excess struct member 'dev_rx' description in 'stedma40_platform_data'
>
> Correct spellos as reported by codespell.
>
> Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312171417.izbQThoU-lkp at intel.com/
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Vinod Koul <vkoul at kernel.org>
> Cc: dmaengine at vger.kernel.org

Thans Randy!
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From ryan.roberts at arm.com  Wed Dec 20 03:28:39 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 11:28:39 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
Message-ID: <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>

On 20/12/2023 10:56, David Hildenbrand wrote:
> On 20.12.23 11:41, Ryan Roberts wrote:
>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>> memory,
>>>>>>>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>
>>>>>>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous
>>>>>>>>>>>> bit"
>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>
>>>>>>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>
>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>> change
>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>
>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>
>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time for
>>>>>>>>>>>> the
>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>> based:
>>>>>>>>>>>>
>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>
>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>
>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> ?????? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>> ?????? mm/memory.c???????????? | 92
>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>> ?????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>> ?????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>> ?????? #endif
>>>>>>>>>>>> ?????? +#ifndef pte_batch_remaining
>>>>>>>>>>>> +/**
>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>> boundary.
>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>> + *
>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>>>> batch of
>>>>>>>>>>>> ptes.
>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>> pages to
>>>>>>>>>>>> the end
>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>>>>>>> iterating
>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>> + *
>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>>>>>>>> + */
>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned
>>>>>>>>>>>> long
>>>>>>>>>>>> addr,
>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>> +{
>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>> +}
>>>>>>>>>>>> +#endif
>>>>>>>>>>>
>>>>>>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>>>>>>
>>>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>>>> require
>>>>>>>>>>> arch
>>>>>>>>>>> specifics?
>>>>>>>>>>
>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the
>>>>>>>>>> only
>>>>>>>>>> way
>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>
>>>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt
>>>>>>>>>> at an
>>>>>>>>>> arch-specific version that didn't resolve to a compile-time constant 1
>>>>>>>>>> still
>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>
>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>
>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can get
>>>>>>>>>> the
>>>>>>>>>> regression under 4% with this. Further along the series I spent a lot of
>>>>>>>>>> time
>>>>>>>>>> having to fiddle with the arm64 implementation; every conditional and
>>>>>>>>>> every
>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>> little in
>>>>>>>>>> the
>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra and
>>>>>>>>>> Apple
>>>>>>>>>> M2).
>>>>>>>>>>
>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>> benefit to
>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>> prefer to
>>>>>>>>>> play
>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>> previously
>>>>>>>>>> suggested.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>>>> series. I
>>>>>>>>> implemented very generic and simple batching for large folios (all PTE
>>>>>>>>> bits
>>>>>>>>> except the PFN have to match).
>>>>>>>>>
>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>>>> Silver
>>>>>>>>> 4210R CPU.
>>>>>>>>>
>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>
>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>
>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>
>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>
>>>>>>>> Well I guess that shows me :)
>>>>>>>>
>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>
>>>>>>>
>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>
>>>>>> I've just been trying to compile and noticed this. Will take a look at your
>>>>>> update.
>>>>>>
>>>>>> But upon review, I've noticed the part that I think makes this difficult for
>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>>>> pte in
>>>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>> order to
>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>> wealking
>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>> function; this allows the core-mm to skip to the end of the contpte block and
>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>>>> instead
>>>>>> of 256.
>>>>>>
>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid the
>>>>>> bit
>>>>>> gathering. But we have a similar problem in zap_pte_range() and that function
>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>> patch 3
>>>>>> in my series).
>>>>>>
>>>>>> I guess you are going to say that we should combine both approaches, so that
>>>>>> your batching loop can skip forward an arch-provided number of ptes? That
>>>>>> would
>>>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>
>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>
>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()"
>>>>> and it
>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>
>>>>
>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>
>>>> How do you want to handle your patches? Do you want to clean them up and I'll
>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>
>>> Whatever you prefer, it was mostly a quick prototype to see if we can achieve
>>> decent performance.
>>
>> I'm about to run it on Altra and M2. But I assume it will show similar results.

OK results in, not looking great, which aligns with my previous experience. That
said, I'm seeing some "BUG: Bad page state in process gmain  pfn:12a094" so
perhaps these results are not valid...

100 iterations per run, 8 runs over 2 reboots. Positive is slower than baseline,
negative is faster:

Fork, order-0, Apple M2 VM:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      0.8% |
| hugetlb-rmap-cleanups |       1.3% |      2.0% |
| fork-batching         |       3.5% |      1.2% |

Fork, order-9, Apple M2 VM:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      0.8% |
| hugetlb-rmap-cleanups |       0.9% |      0.9% |
| fork-batching         |     -35.6% |      2.0% |

Fork, order-0, Ampere Altra:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      0.7% |
| hugetlb-rmap-cleanups |       3.2% |      0.7% |
| fork-batching         |       5.5% |      1.1% |

Fork, order-9, Ampere Altra:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      0.1% |
| hugetlb-rmap-cleanups |       0.5% |      0.1% |
| fork-batching         |     -10.3% |      0.1% |


>>
>>>
>>> I can fixup the arch thingies (most should be easy, some might require a custom
>>> pte_next_pfn())
>>
>> Well if you're happy to do that, great! I'm keen to get the contpte stuff into
>> v6.9 if at all possible, and I'm concious that I'm introducing more dependencies
>> on you. And its about to be holiday season...
> 
> There is still plenty of time for 6.9. I'll try to get the rmap cleanup finished
> asap.
> 
>>
>>> and you can focus on getting cont-pte sorted out on top [I
>>> assume that's what you want to work on :) ].
>>
>> That's certainly what I'm focussed on. But I'm happy to do whatever is required
>> to get it over the line. I guess I'll start by finishing my review of your v1
>> rmap stuff.
> 
> I'm planning on sending out a new version today.
> 
>>
>>>
>>>>
>>>> As I see it at the moment, I would keep your folio_pte_batch() always core, but
>>>> in subsequent patch, have it use pte_batch_remaining() (the arch function I
>>>> have
>>>> in my series, which defaults to one).
>>>
>>> Just double-checking, how would it use pte_batch_remaining() ?
>>
>> I think something like this would do it (untested):
>>
>> static inline int folio_pte_batch(struct folio *folio, unsigned long addr,
>> ??????? pte_t *start_ptep, pte_t pte, int max_nr)
>> {
>> ????unsigned long folio_end_pfn = folio_pfn(folio) + folio_nr_pages(folio);
>> ????pte_t expected_pte = pte_next_pfn(pte);
>> ????pte_t *ptep = start_ptep;
>> ????int nr;
>>
>> ????for (;;) {
>> ??????? nr = min(max_nr, pte_batch_remaining());
>> ??????? ptep += nr;
>> ??????? max_nr -= nr;
>>
>> ??????? if (max_nr == 0)
>> ??????????? break;
>>
> 
> expected_pte would be messed up. We'd have to increment it a couple of times to
> make it match the nr of pages we're skipping.

Ahh, good point.

> 
>> ??????? pte = ptep_get(ptep);
>>
>> ??????? /* Do all PTE bits match, and the PFN is consecutive? */
>> ??????? if (!pte_same(pte, expected_pte))
>> ??????????? break;
>>
>> ??????? /*
>> ???????? * Stop immediately once we reached the end of the folio. In
>> ???????? * corner cases the next PFN might fall into a different
>> ???????? * folio.
>> ???????? */
>> ??????? if (pte_pfn(pte) == folio_end_pfn - 1)
>> ??????????? break;
>>
>> ??????? expected_pte = pte_next_pfn(expected_pte);
>> ????}
>>
>> ????return ptep - start_ptep;
>> }
>>
>> Of course, if we have the concept of a "pte batch" in the core-mm, then we might
>> want to call the arch's thing something different; pte span? pte cont? pte cont
>> batch? ...
> 
> So, you mean something like
> 
> /*
> ?* The architecture might be able to tell us efficiently using cont-pte
> ?* bits how many next PTEs are certainly compatible. So in that case,
> ?* simply skip forward.
> ?*/
> nr = min(max_nr, nr_cont_ptes(ptep));
> ...
> 
> I wonder if something simple at the start of the function might be good enough
> for arm with cont-pte as a first step:
> 
> nr = nr_cont_ptes(start_ptep)
> if (nr != 1) {
> ????return min(max_nr, nr);
> }

Yeah that would probably work. But we need to be careful for the case where
start_ptep is in the middle of a contpte block (which can happen - due to some
vma splitting operations, we can have a contpte block that spans 2 vmas). So
nr_cont_ptes() needs to either be spec'ed to only return the contpte size if
start_ptep is pointing to the front of the block, and all other times, return 1,
or it needs to return the number of ptes remaining to the end of the block (as
it does in my v4).

But I guess we need to get to the bottom of my arm64 perf numbers first... I'll
debug those bugs and rerun.

> 
> Which would get optimized out on other architectures.
> 
> 



From patchwork-bot+netdevbpf at kernel.org  Wed Dec 20 03:30:23 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 20 Dec 2023 11:30:23 +0000
Subject: [PATCH net v2 1/1] net: stmmac: fix incorrect flag check in timestamp
 interrupt
In-Reply-To: <1702885892-30369-1-git-send-email-jun.ann.lai@intel.com>
References: <1702885892-30369-1-git-send-email-jun.ann.lai@intel.com>
Message-ID: <170307182341.15860.4221212163118330561.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net.git (main)
by David S. Miller <davem at davemloft.net>:

On Mon, 18 Dec 2023 15:51:32 +0800 you wrote:
> The driver should continue get the timestamp if STMMAC_FLAG_EXT_SNAPSHOT_EN
> flag is set.
> 
> Fixes: aa5513f5d95f ("net: stmmac: replace the ext_snapshot_en field with a flag")
> Cc: <stable at vger.kernel.org> # 6.6
> Signed-off-by: Song Yoong Siang <yoong.siang.song at intel.com>
> Signed-off-by: Lai Peter Jun Ann <jun.ann.lai at intel.com>
> 
> [...]

Here is the summary with links:
  - [net,v2,1/1] net: stmmac: fix incorrect flag check in timestamp interrupt
    https://git.kernel.org/netdev/net/c/bd7f77dae695

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From tony at atomide.com  Wed Dec 20 03:30:14 2023
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 20 Dec 2023 13:30:14 +0200
Subject: [GIT PULL] Fix for am335x usb boot hang
Message-ID: <pull-1703071616-395333@atomide.com>

From: "Tony Lindgren" <tony at atomide.com>

The following changes since commit c72b9c33ef9695ad7ce7a6eb39a9df8a01b70796:

  ARM: OMAP2+: Fix null pointer dereference and memory leak in omap_soc_device_init (2023-11-30 13:57:00 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/am3-usb-hang-fix-signed

for you to fetch changes up to 9b6a51aab5f5f9f71d2fa16e8b4d530e1643dfcb:

  ARM: dts: Fix occasional boot hang for am3 usb (2023-12-13 08:56:10 +0200)

----------------------------------------------------------------
Fix for occasional boot hang for am335x USB

A fix for occasional boot hang for am335x USB that I've only recently
started noticing.

This can be merged naturally whenever suitable. This issue has been seen
with other similar SoCs earlier and has clearly existed for a long time.

----------------------------------------------------------------
Tony Lindgren (1):
      ARM: dts: Fix occasional boot hang for am3 usb

 arch/arm/boot/dts/ti/omap/am33xx.dtsi | 1 +
 1 file changed, 1 insertion(+)


From pbrobinson at gmail.com  Wed Dec 20 03:32:08 2023
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 20 Dec 2023 11:32:08 +0000
Subject: [PATCH] PCI: cadence: Fix TI J721E PCIe SoC dependencies
Message-ID: <20231220113214.413632-1-pbrobinson@gmail.com>

The J721E PCIe is hardware specific to the TI SoC parts
so add a depenency on that so it's available for those
SoC parts and for compile testing but not necessarily
everyone who enables the Cadence PCIe controller.

Signed-off-by: Peter Robinson <pbrobinson at gmail.com>
---
 drivers/pci/controller/cadence/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/cadence/Kconfig b/drivers/pci/controller/cadence/Kconfig
index 291d12711363..1d5a70c9055e 100644
--- a/drivers/pci/controller/cadence/Kconfig
+++ b/drivers/pci/controller/cadence/Kconfig
@@ -47,6 +47,7 @@ config PCI_J721E
 
 config PCI_J721E_HOST
 	bool "TI J721E PCIe controller (host mode)"
+	depends on ARCH_K3 || COMPILE_TEST
 	depends on OF
 	select PCIE_CADENCE_HOST
 	select PCI_J721E
@@ -57,6 +58,7 @@ config PCI_J721E_HOST
 
 config PCI_J721E_EP
 	bool "TI J721E PCIe controller (endpoint mode)"
+	depends on ARCH_K3 || COMPILE_TEST
 	depends on OF
 	depends on PCI_ENDPOINT
 	select PCIE_CADENCE_EP
-- 
2.43.0



From michal.simek at amd.com  Wed Dec 20 03:32:58 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 12:32:58 +0100
Subject: [PATCH 2/2] firmware: xilinx: Remove
 zynqmp_pm_pinctrl_get_function()
In-Reply-To: <CACRpkdbso5A0muF6yqVyTquX+uPLTQCUpC0CF8DvR1_-uU0frQ@mail.gmail.com>
References: <6ccbffbafd1f0f48f6574d5a3bf2db6a5603fdb0.1702565618.git.michal.simek@amd.com>
 <e52a415a004e28a43e6d08e9e22d9e8fef3737df.1702565618.git.michal.simek@amd.com>
 <CACRpkdbso5A0muF6yqVyTquX+uPLTQCUpC0CF8DvR1_-uU0frQ@mail.gmail.com>
Message-ID: <d3eb97ea-979b-41c3-9f29-95ad4e1220f0@amd.com>



On 12/20/23 12:13, Linus Walleij wrote:
> On Thu, Dec 14, 2023 at 3:54?PM Michal Simek <michal.simek at amd.com> wrote:
> 
>> There is no user for this interface that's why remove it.
>>
>> Signed-off-by: Michal Simek <michal.simek at amd.com>
> 
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> 
> I assume this will be merged in some other git tree, tell me if it
> should be merged through the pinctrl tree.

I expect Greg could take it. If not, I will take it via my soc tree.

Thanks,
Michal


From krzysztof.kozlowski at linaro.org  Wed Dec 20 03:34:00 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 20 Dec 2023 12:34:00 +0100
Subject: [PATCH v3 2/3] soc: mediatek: mtk-socinfo: Add driver for getting
 chip information
In-Reply-To: <20231220103901.22180-3-william-tw.lin@mediatek.com>
References: <20231220103901.22180-1-william-tw.lin@mediatek.com>
 <20231220103901.22180-3-william-tw.lin@mediatek.com>
Message-ID: <97d54894-7c71-49d8-a456-869c398636ec@linaro.org>

On 20/12/2023 11:39, William-tw Lin wrote:
> Add driver for socinfo retrieval. This patch includes the following:
> 1. mtk-socinfo driver for chip info retrieval
> 2. Related changes to Makefile and Kconfig
> 
> Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>

...

> +static struct platform_driver mtk_socinfo = {
> +	.probe = mtk_socinfo_probe,
> +	.remove_new = mtk_socinfo_remove,
> +	.driver = {
> +		.name = "mtk-socinfo",
> +	},
> +};
> +builtin_platform_driver(mtk_socinfo);

module platform driver, because this is tristate and because this should
be a module.

Best regards,
Krzysztof



From robh at kernel.org  Wed Dec 20 03:35:16 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 20 Dec 2023 05:35:16 -0600
Subject: [PATCH v2 3/4] dt-bindings: power: reset: xilinx: Rename node
 names in examples
In-Reply-To: <26aa3459310ba4624ccb5865ca32017357591e4d.1703066422.git.michal.simek@amd.com>
References: <cover.1703066422.git.michal.simek@amd.com>
 <26aa3459310ba4624ccb5865ca32017357591e4d.1703066422.git.michal.simek@amd.com>
Message-ID: <170307211630.3474502.10317980096869391404.robh@kernel.org>


On Wed, 20 Dec 2023 11:00:29 +0100, Michal Simek wrote:
> Rename zynqmp-power node name to power-controller which is more aligned
> with generic node name recommendation.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---
> 
> Changes in v2:
> - New patch is series
> 
>  .../devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml    | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.example.dtb: power-controller: '#power-domain-cells' is a required property
	from schema $id: http://devicetree.org/schemas/power/power-domain.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.example.dtb: power-controller: '#power-domain-cells' is a required property
	from schema $id: http://devicetree.org/schemas/power/power-domain.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/26aa3459310ba4624ccb5865ca32017357591e4d.1703066422.git.michal.simek at amd.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From david at redhat.com  Wed Dec 20 03:36:27 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 12:36:27 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
Message-ID: <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>

On 20.12.23 12:28, Ryan Roberts wrote:
> On 20/12/2023 10:56, David Hildenbrand wrote:
>> On 20.12.23 11:41, Ryan Roberts wrote:
>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>> memory,
>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then write-protected in
>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects() and is
>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>
>>>>>>>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous
>>>>>>>>>>>>> bit"
>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>> change
>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is very
>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time for
>>>>>>>>>>>>> the
>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is faster,
>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>> based:
>>>>>>>>>>>>>
>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>
>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>  ?????? include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>  ?????? mm/memory.c???????????? | 92
>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>  ?????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>  ?????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>  ?????? #endif
>>>>>>>>>>>>>  ?????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>> +/**
>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>>>>> batch of
>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>> pages to
>>>>>>>>>>>>> the end
>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>>>>>>>> iterating
>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is always 1.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned
>>>>>>>>>>>>> long
>>>>>>>>>>>>> addr,
>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>
>>>>>>>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>>>>>>>
>>>>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>>>>> require
>>>>>>>>>>>> arch
>>>>>>>>>>>> specifics?
>>>>>>>>>>>
>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the
>>>>>>>>>>> only
>>>>>>>>>>> way
>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>
>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt
>>>>>>>>>>> at an
>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time constant 1
>>>>>>>>>>> still
>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>
>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>
>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can get
>>>>>>>>>>> the
>>>>>>>>>>> regression under 4% with this. Further along the series I spent a lot of
>>>>>>>>>>> time
>>>>>>>>>>> having to fiddle with the arm64 implementation; every conditional and
>>>>>>>>>>> every
>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>> little in
>>>>>>>>>>> the
>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra and
>>>>>>>>>>> Apple
>>>>>>>>>>> M2).
>>>>>>>>>>>
>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>> benefit to
>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>> prefer to
>>>>>>>>>>> play
>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>> previously
>>>>>>>>>>> suggested.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>>>>> series. I
>>>>>>>>>> implemented very generic and simple batching for large folios (all PTE
>>>>>>>>>> bits
>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>
>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>>>>> Silver
>>>>>>>>>> 4210R CPU.
>>>>>>>>>>
>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>
>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>
>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>
>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>
>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>
>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>
>>>>>>>>
>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>
>>>>>>> I've just been trying to compile and noticed this. Will take a look at your
>>>>>>> update.
>>>>>>>
>>>>>>> But upon review, I've noticed the part that I think makes this difficult for
>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>>>>> pte in
>>>>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>> order to
>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>> wealking
>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>> function; this allows the core-mm to skip to the end of the contpte block and
>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>>>>> instead
>>>>>>> of 256.
>>>>>>>
>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid the
>>>>>>> bit
>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that function
>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>> patch 3
>>>>>>> in my series).
>>>>>>>
>>>>>>> I guess you are going to say that we should combine both approaches, so that
>>>>>>> your batching loop can skip forward an arch-provided number of ptes? That
>>>>>>> would
>>>>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>
>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>
>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()"
>>>>>> and it
>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>
>>>>>
>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>
>>>>> How do you want to handle your patches? Do you want to clean them up and I'll
>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>
>>>> Whatever you prefer, it was mostly a quick prototype to see if we can achieve
>>>> decent performance.
>>>
>>> I'm about to run it on Altra and M2. But I assume it will show similar results.
> 
> OK results in, not looking great, which aligns with my previous experience. That
> said, I'm seeing some "BUG: Bad page state in process gmain  pfn:12a094" so
> perhaps these results are not valid...

I didn't see that so far on x86, maybe related to the PFN fixup?

> 
> 100 iterations per run, 8 runs over 2 reboots. Positive is slower than baseline,
> negative is faster:
> 
> Fork, order-0, Apple M2 VM:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      0.8% |
> | hugetlb-rmap-cleanups |       1.3% |      2.0% |
> | fork-batching         |       3.5% |      1.2% |
> 
> Fork, order-9, Apple M2 VM:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      0.8% |
> | hugetlb-rmap-cleanups |       0.9% |      0.9% |
> | fork-batching         |     -35.6% |      2.0% |
> 
> Fork, order-0, Ampere Altra:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      0.7% |
> | hugetlb-rmap-cleanups |       3.2% |      0.7% |
> | fork-batching         |       5.5% |      1.1% |
> 
> Fork, order-9, Ampere Altra:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      0.1% |
> | hugetlb-rmap-cleanups |       0.5% |      0.1% |
> | fork-batching         |     -10.3% |      0.1% |

It's weird that an effective folio_test_large() should affect 
performance that much. So far I haven't seen that behavior on x86, I 
wodner why arm64 should behave here differently (also for the rmap 
cleanups). Code layout/size?

I'll dig it up again and test on x86 once more.

[...]

> 
> Yeah that would probably work. But we need to be careful for the case where
> start_ptep is in the middle of a contpte block (which can happen - due to some
> vma splitting operations, we can have a contpte block that spans 2 vmas). So
> nr_cont_ptes() needs to either be spec'ed to only return the contpte size if
> start_ptep is pointing to the front of the block, and all other times, return 1,
> or it needs to return the number of ptes remaining to the end of the block (as
> it does in my v4).
> 
> But I guess we need to get to the bottom of my arm64 perf numbers first... I'll
> debug those bugs and rerun.

Yes, I'll dig into it on x86 once more.

-- 
Cheers,

David / dhildenb



From linus.walleij at linaro.org  Wed Dec 20 03:42:27 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 20 Dec 2023 12:42:27 +0100
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl protocol
In-Reply-To: <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com> <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
Message-ID: <CACRpkdbpcwADJnZz1Q0KQ-gJv8FvnvJS=4PpMF+Np4rNCN3x+w@mail.gmail.com>

Hi Peng,

On Fri, Dec 15, 2023 at 12:52?PM Peng Fan (OSS) <peng.fan at oss.nxp.com> wrote:

In this example, as it is not intended to reflect any specific hardware,
use the latest canonical naming:

> +
> +            scmi_pinctrl: protocol at 19 {
> +                reg = <0x19>;
> +                #pinctrl-cells = <0>;
> +
> +                i2c2-pins {
> +                    groups = "i2c2_a", "i2c2_b";

groups = "g_i2c2_a", "g_i2c2_b";

> +                    function = "i2c2";

function = "f_i2c2";

> +                };
> +
> +                mdio-pins {
> +                    groups = "avb_mdio";

groups = "g_avb_mdio";

> +                    drive-strength = <24>;
> +                };
> +
> +                keys_pins: keys-pins {
> +                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";

pins = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1";

These names look odd to me, like these are actually groups
with pins 5..17 etc. Should it be groups = "g_gpio_5_17" etc?

Yours,
Linus Walleij


From wahrenst at gmx.net  Wed Dec 20 03:43:34 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Wed, 20 Dec 2023 12:43:34 +0100
Subject: [PATCH] serial: 8250_bcm2835aux: Restore clock error handling
Message-ID: <20231220114334.4712-1-wahrenst@gmx.net>

The commit fcc446c8aa63 ("serial: 8250_bcm2835aux: Add ACPI support")
dropped the error handling for clock acquiring. But even an optional
clock needs this.

Fixes: fcc446c8aa63 ("serial: 8250_bcm2835aux: Add ACPI support")
Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
 drivers/tty/serial/8250/8250_bcm2835aux.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_bcm2835aux.c b/drivers/tty/serial/8250/8250_bcm2835aux.c
index 15a2387a5b25..4f4502fb5454 100644
--- a/drivers/tty/serial/8250/8250_bcm2835aux.c
+++ b/drivers/tty/serial/8250/8250_bcm2835aux.c
@@ -119,6 +119,8 @@ static int bcm2835aux_serial_probe(struct platform_device *pdev)

 	/* get the clock - this also enables the HW */
 	data->clk = devm_clk_get_optional(&pdev->dev, NULL);
+	if (IS_ERR(data->clk))
+		return dev_err_probe(&pdev->dev, PTR_ERR(data->clk), "could not get clk\n");

 	/* get the interrupt */
 	ret = platform_get_irq(pdev, 0);
--
2.34.1



From linus.walleij at linaro.org  Wed Dec 20 03:50:38 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 20 Dec 2023 12:50:38 +0100
Subject: [PATCH] dt-bindings: pinctrl: xilinx: Rename *gpio to *gpio-grp
In-Reply-To: <2e3a1f1f57cf929bd05115bc081e6d01d5a53443.1702996859.git.michal.simek@amd.com>
References: <2e3a1f1f57cf929bd05115bc081e6d01d5a53443.1702996859.git.michal.simek@amd.com>
Message-ID: <CACRpkda4nqcBpF6Xv2gAS9QzrmWOTeKi52Fe1qW+t7NuM2i_ZA@mail.gmail.com>

On Tue, Dec 19, 2023 at 3:41?PM Michal Simek <michal.simek at amd.com> wrote:

> Anything ending with gpio/gpios is taken as gpio phande/description which
> is reported as the issue coming from gpio-consumer.yaml schema.
> That's why rename the gpio suffix to gpio-grp to avoid name collision.
>
> Signed-off-by: Michal Simek <michal.simek at amd.com>

Patch applied.

Yours,
Linus Walleij


From ryan.roberts at arm.com  Wed Dec 20 03:51:51 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 11:51:51 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
Message-ID: <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>

On 20/12/2023 11:36, David Hildenbrand wrote:
> On 20.12.23 12:28, Ryan Roberts wrote:
>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects()
>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous
>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>>> change
>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is
>>>>>>>>>>>>>> very
>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time for
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> ??????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>> ??????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>> ??????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>> ??????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>> ??????? #endif
>>>>>>>>>>>>>> ??????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned
>>>>>>>>>>>>>> long
>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>>>>>> require
>>>>>>>>>>>>> arch
>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>
>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the
>>>>>>>>>>>> only
>>>>>>>>>>>> way
>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>
>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt
>>>>>>>>>>>> at an
>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time constant 1
>>>>>>>>>>>> still
>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>
>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can get
>>>>>>>>>>>> the
>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>> lot of
>>>>>>>>>>>> time
>>>>>>>>>>>> having to fiddle with the arm64 implementation; every conditional and
>>>>>>>>>>>> every
>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>> little in
>>>>>>>>>>>> the
>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra
>>>>>>>>>>>> and
>>>>>>>>>>>> Apple
>>>>>>>>>>>> M2).
>>>>>>>>>>>>
>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>> benefit to
>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>> prefer to
>>>>>>>>>>>> play
>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>> previously
>>>>>>>>>>>> suggested.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>>>>>> series. I
>>>>>>>>>>> implemented very generic and simple batching for large folios (all PTE
>>>>>>>>>>> bits
>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>
>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>>>>>> Silver
>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>
>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>
>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>
>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>
>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>
>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>
>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>
>>>>>>>> I've just been trying to compile and noticed this. Will take a look at your
>>>>>>>> update.
>>>>>>>>
>>>>>>>> But upon review, I've noticed the part that I think makes this difficult
>>>>>>>> for
>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>>>>>> pte in
>>>>>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>> order to
>>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>>> wealking
>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>> block and
>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>>>>>> instead
>>>>>>>> of 256.
>>>>>>>>
>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid
>>>>>>>> the
>>>>>>>> bit
>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>> function
>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>>> patch 3
>>>>>>>> in my series).
>>>>>>>>
>>>>>>>> I guess you are going to say that we should combine both approaches, so
>>>>>>>> that
>>>>>>>> your batching loop can skip forward an arch-provided number of ptes? That
>>>>>>>> would
>>>>>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>
>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>
>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()"
>>>>>>> and it
>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>
>>>>>>
>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>
>>>>>> How do you want to handle your patches? Do you want to clean them up and I'll
>>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>>
>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can achieve
>>>>> decent performance.
>>>>
>>>> I'm about to run it on Altra and M2. But I assume it will show similar results.
>>
>> OK results in, not looking great, which aligns with my previous experience. That
>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>> perhaps these results are not valid...
> 
> I didn't see that so far on x86, maybe related to the PFN fixup?

All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b19a8aee684c..9eb0fd693df9 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
 }
 #define set_ptes set_ptes
 
+#define PFN_PTE_SHIFT          PAGE_SHIFT
+
 /*
  * Huge pte definitions.
  */


As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit case. But that won't affect this.


With VM_DEBUG on, this is the first warning I see during boot:


[    0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0 mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
[    0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0 nr_pages_mapped:2 pincount:0
[    0.279247] memcg:ffff1a678008a000
[    0.279518] aops:xfs_address_space_operations ino:b0f70c dentry name:"systemd"
[    0.279746] flags: 0xbfffc0000008068(uptodate|lru|private|head|node=0|zone=2|lastcpupid=0xffff)
[    0.280003] page_type: 0xffffffff()
[    0.280110] raw: 0bfffc0000008068 fffffc699effcb08 fffffc699effcd08 ffff1a678980a6b0
[    0.280338] raw: 00000000000001a8 ffff1a678a0f0200 0000000cffffffff ffff1a678008a000
[    0.280564] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1), const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *: (struct folio *)_compound_head(page + nr_pages - 1))) != folio)
[    0.281196] ------------[ cut here ]------------
[    0.281349] WARNING: CPU: 2 PID: 1 at include/linux/rmap.h:208 __folio_rmap_sanity_checks.constprop.0+0x168/0x188
[    0.281650] Modules linked in:
[    0.281752] CPU: 2 PID: 1 Comm: systemd Not tainted 6.7.0-rc4-00345-gdb45492bba9d #7
[    0.281959] Hardware name: linux,dummy-virt (DT)
[    0.282079] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[    0.282260] pc : __folio_rmap_sanity_checks.constprop.0+0x168/0x188
[    0.282421] lr : __folio_rmap_sanity_checks.constprop.0+0x168/0x188
[    0.282583] sp : ffff80008007b9e0
[    0.282670] x29: ffff80008007b9e0 x28: 0000aaaacbecb000 x27: fffffc699effccc0
[    0.282872] x26: 00600001bff33fc3 x25: 0000000000000001 x24: ffff1a678a302228
[    0.283062] x23: ffff1a678a326658 x22: 0000000000000000 x21: 0000000000000004
[    0.283246] x20: fffffc699effccc0 x19: fffffc699effcc00 x18: 0000000000000000
[    0.283435] x17: 3736613166666666 x16: 2066666666666666 x15: 0720072007200720
[    0.283679] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720
[    0.283933] x11: 0720072007200720 x10: ffffa89ecd79ba50 x9 : ffffa89ecab23054
[    0.284214] x8 : ffffa89ecd743a50 x7 : ffffa89ecd79ba50 x6 : 0000000000000000
[    0.284545] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[    0.284875] x2 : 0000000000000000 x1 : ffff1a6781420000 x0 : 00000000000000e5
[    0.285205] Call trace:
[    0.285320]  __folio_rmap_sanity_checks.constprop.0+0x168/0x188
[    0.285594]  copy_page_range+0x1180/0x1328
[    0.285788]  copy_process+0x1b04/0x1db8
[    0.285933]  kernel_clone+0x94/0x3f8
[    0.286078]  __do_sys_clone+0x58/0x88
[    0.286247]  __arm64_sys_clone+0x28/0x40
[    0.286430]  invoke_syscall+0x50/0x128
[    0.286607]  el0_svc_common.constprop.0+0x48/0xf0
[    0.286826]  do_el0_svc+0x24/0x38
[    0.286983]  el0_svc+0x34/0xb8
[    0.287142]  el0t_64_sync_handler+0xc0/0xc8
[    0.287339]  el0t_64_sync+0x190/0x198
[    0.287514] ---[ end trace 0000000000000000 ]---


> 
>>
>> 100 iterations per run, 8 runs over 2 reboots. Positive is slower than baseline,
>> negative is faster:
>>
>> Fork, order-0, Apple M2 VM:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 0.8% |
>> | hugetlb-rmap-cleanups |?????? 1.3% |????? 2.0% |
>> | fork-batching???????? |?????? 3.5% |????? 1.2% |
>>
>> Fork, order-9, Apple M2 VM:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 0.8% |
>> | hugetlb-rmap-cleanups |?????? 0.9% |????? 0.9% |
>> | fork-batching???????? |???? -35.6% |????? 2.0% |
>>
>> Fork, order-0, Ampere Altra:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 0.7% |
>> | hugetlb-rmap-cleanups |?????? 3.2% |????? 0.7% |
>> | fork-batching???????? |?????? 5.5% |????? 1.1% |
>>
>> Fork, order-9, Ampere Altra:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 0.1% |
>> | hugetlb-rmap-cleanups |?????? 0.5% |????? 0.1% |
>> | fork-batching???????? |???? -10.3% |????? 0.1% |
> 
> It's weird that an effective folio_test_large() should affect performance that
> much. So far I haven't seen that behavior on x86, I wodner why arm64 should
> behave here differently (also for the rmap cleanups). Code layout/size?
> 
> I'll dig it up again and test on x86 once more.
> 
> [...]
> 
>>
>> Yeah that would probably work. But we need to be careful for the case where
>> start_ptep is in the middle of a contpte block (which can happen - due to some
>> vma splitting operations, we can have a contpte block that spans 2 vmas). So
>> nr_cont_ptes() needs to either be spec'ed to only return the contpte size if
>> start_ptep is pointing to the front of the block, and all other times, return 1,
>> or it needs to return the number of ptes remaining to the end of the block (as
>> it does in my v4).
>>
>> But I guess we need to get to the bottom of my arm64 perf numbers first... I'll
>> debug those bugs and rerun.
> 
> Yes, I'll dig into it on x86 once more.
> 



From m.felsch at pengutronix.de  Wed Dec 20 03:53:18 2023
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Wed, 20 Dec 2023 12:53:18 +0100
Subject: [PATCH] clk: imx: pll14xx: change naming of fvco to fout
In-Reply-To: <1703068389-6130-1-git-send-email-shengjiu.wang@nxp.com>
References: <1703068389-6130-1-git-send-email-shengjiu.wang@nxp.com>
Message-ID: <20231220115318.o3ql3fjtjktsf73t@pengutronix.de>

Hi,

thanks for the patch.

On 23-12-20, Shengjiu Wang wrote:
> pll14xx_calc_rate() output the fout clock not the fvco clock
> The relation of fvco and fout is:
> 	fout = fvco / (1 << sdiv)
> 
> So use correct naming for the clock.
> 
> Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>

lgtm

Reviewed-by: Marco Felsch <m.felsch at pengutronix.de>

> ---
>  drivers/clk/imx/clk-pll14xx.c | 23 ++++++++++++-----------
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
> index 0d58d85c375e..d63564dbb12c 100644
> --- a/drivers/clk/imx/clk-pll14xx.c
> +++ b/drivers/clk/imx/clk-pll14xx.c
> @@ -104,15 +104,15 @@ static const struct imx_pll14xx_rate_table *imx_get_pll_settings(
>  static long pll14xx_calc_rate(struct clk_pll14xx *pll, int mdiv, int pdiv,
>  			      int sdiv, int kdiv, unsigned long prate)
>  {
> -	u64 fvco = prate;
> +	u64 fout = prate;
>  
> -	/* fvco = (m * 65536 + k) * Fin / (p * 65536) */
> -	fvco *= (mdiv * 65536 + kdiv);
> +	/* fout = (m * 65536 + k) * Fin / (p * 65536) / (1 << sdiv) */
> +	fout *= (mdiv * 65536 + kdiv);
>  	pdiv *= 65536;
>  
> -	do_div(fvco, pdiv << sdiv);
> +	do_div(fout, pdiv << sdiv);
>  
> -	return fvco;
> +	return fout;
>  }
>  
>  static long pll1443x_calc_kdiv(int mdiv, int pdiv, int sdiv,
> @@ -131,7 +131,7 @@ static void imx_pll14xx_calc_settings(struct clk_pll14xx *pll, unsigned long rat
>  {
>  	u32 pll_div_ctl0, pll_div_ctl1;
>  	int mdiv, pdiv, sdiv, kdiv;
> -	long fvco, rate_min, rate_max, dist, best = LONG_MAX;
> +	long fout, rate_min, rate_max, dist, best = LONG_MAX;
>  	const struct imx_pll14xx_rate_table *tt;
>  
>  	/*
> @@ -143,6 +143,7 @@ static void imx_pll14xx_calc_settings(struct clk_pll14xx *pll, unsigned long rat
>  	 * d) -32768 <= k <= 32767
>  	 *
>  	 * fvco = (m * 65536 + k) * prate / (p * 65536)
> +	 * fout = (m * 65536 + k) * prate / (p * 65536) / (1 << sdiv)
>  	 */
>  
>  	/* First try if we can get the desired rate from one of the static entries */
> @@ -173,8 +174,8 @@ static void imx_pll14xx_calc_settings(struct clk_pll14xx *pll, unsigned long rat
>  		pr_debug("%s: in=%ld, want=%ld Only adjust kdiv %ld -> %d\n",
>  			 clk_hw_get_name(&pll->hw), prate, rate,
>  			 FIELD_GET(KDIV_MASK, pll_div_ctl1), kdiv);
> -		fvco = pll14xx_calc_rate(pll, mdiv, pdiv, sdiv, kdiv, prate);
> -		t->rate = (unsigned int)fvco;
> +		fout = pll14xx_calc_rate(pll, mdiv, pdiv, sdiv, kdiv, prate);
> +		t->rate = (unsigned int)fout;
>  		t->mdiv = mdiv;
>  		t->pdiv = pdiv;
>  		t->sdiv = sdiv;
> @@ -190,13 +191,13 @@ static void imx_pll14xx_calc_settings(struct clk_pll14xx *pll, unsigned long rat
>  			mdiv = clamp(mdiv, 64, 1023);
>  
>  			kdiv = pll1443x_calc_kdiv(mdiv, pdiv, sdiv, rate, prate);
> -			fvco = pll14xx_calc_rate(pll, mdiv, pdiv, sdiv, kdiv, prate);
> +			fout = pll14xx_calc_rate(pll, mdiv, pdiv, sdiv, kdiv, prate);
>  
>  			/* best match */
> -			dist = abs((long)rate - (long)fvco);
> +			dist = abs((long)rate - (long)fout);
>  			if (dist < best) {
>  				best = dist;
> -				t->rate = (unsigned int)fvco;
> +				t->rate = (unsigned int)fout;
>  				t->mdiv = mdiv;
>  				t->pdiv = pdiv;
>  				t->sdiv = sdiv;
> -- 
> 2.34.1
> 
> 
> 


From andre.przywara at arm.com  Wed Dec 20 03:54:12 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 20 Dec 2023 11:54:12 +0000
Subject: [PATCH RESEND] iio: adc: sun4i-gpadc-iio: adaptation interrupt
 number
In-Reply-To: <YwdhTlk+9h+9Mrwm@scg>
References: <YxmR5SPPY18O7LaG@google.com>
	<YwdhTlk+9h+9Mrwm@scg>
Message-ID: <20231220115412.65bbc8c7@donnerap.manchester.arm.com>

On Wed, 20 Dec 2023 15:23:17 +0800
fuyao <fuyao1697 at cyg.com> wrote:

Hi,

> __platform_get_irq_byname determinies whether the interrupt
> number is 0 and returns EINVAL.

can you please say what this fixes, exactly? Is something not working at
the moment? Can you please provide parts of the error message?

And maybe expand the explanation a bit more? For instance mention that the
identifiers are used as IRQ resource numbers, where 0 is treated specially.

Cheers,
Andre

> 
> Signed-off-by: fuyao <fuyao1697 at cyg.com>
> Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
> ---
>  include/linux/mfd/sun4i-gpadc.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> index ea0ccf33a459..021f820f9d52 100644
> --- a/include/linux/mfd/sun4i-gpadc.h
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -81,8 +81,8 @@
>  #define SUN4I_GPADC_TEMP_DATA				0x20
>  #define SUN4I_GPADC_DATA				0x24
>  
> -#define SUN4I_GPADC_IRQ_FIFO_DATA			0
> -#define SUN4I_GPADC_IRQ_TEMP_DATA			1
> +#define SUN4I_GPADC_IRQ_FIFO_DATA			1
> +#define SUN4I_GPADC_IRQ_TEMP_DATA			2
>  
>  /* 10s delay before suspending the IP */
>  #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000



From david at redhat.com  Wed Dec 20 03:58:00 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 12:58:00 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
Message-ID: <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>

On 20.12.23 12:51, Ryan Roberts wrote:
> On 20/12/2023 11:36, David Hildenbrand wrote:
>> On 20.12.23 12:28, Ryan Roberts wrote:
>>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects()
>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number of tlb
>>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous
>>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the backend
>>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is expensive,
>>>>>>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in the
>>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once they
>>>>>>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This code is very performance sensitive, and a significant amount of
>>>>>>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile constant 1,
>>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are added
>>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is
>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>>>> significant performance change after this patch. Fork is called in a
>>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time for
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests
>>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0 folios and
>>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>  ??????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>>>  ??????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>>>  ??????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>>>  ??????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>>>  ??????? #endif
>>>>>>>>>>>>>>>  ??????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful when
>>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned
>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's a shame we now lose the optimization for all other archtiectures.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>>>>>>> require
>>>>>>>>>>>>>> arch
>>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the
>>>>>>>>>>>>> only
>>>>>>>>>>>>> way
>>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt
>>>>>>>>>>>>> at an
>>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time constant 1
>>>>>>>>>>>>> still
>>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>>
>>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can get
>>>>>>>>>>>>> the
>>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>>> lot of
>>>>>>>>>>>>> time
>>>>>>>>>>>>> having to fiddle with the arm64 implementation; every conditional and
>>>>>>>>>>>>> every
>>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>>> little in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra
>>>>>>>>>>>>> and
>>>>>>>>>>>>> Apple
>>>>>>>>>>>>> M2).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>>> benefit to
>>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>>> prefer to
>>>>>>>>>>>>> play
>>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>>> previously
>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>>>>>>> series. I
>>>>>>>>>>>> implemented very generic and simple batching for large folios (all PTE
>>>>>>>>>>>> bits
>>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>>
>>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>>>>>>> Silver
>>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>>
>>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>>
>>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>>
>>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>>
>>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>>
>>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>>
>>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>>
>>>>>>>>> I've just been trying to compile and noticed this. Will take a look at your
>>>>>>>>> update.
>>>>>>>>>
>>>>>>>>> But upon review, I've noticed the part that I think makes this difficult
>>>>>>>>> for
>>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>>>>>>> pte in
>>>>>>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>>> order to
>>>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>>>> wealking
>>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>>> block and
>>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>>>>>>> instead
>>>>>>>>> of 256.
>>>>>>>>>
>>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid
>>>>>>>>> the
>>>>>>>>> bit
>>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>>> function
>>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>>>> patch 3
>>>>>>>>> in my series).
>>>>>>>>>
>>>>>>>>> I guess you are going to say that we should combine both approaches, so
>>>>>>>>> that
>>>>>>>>> your batching loop can skip forward an arch-provided number of ptes? That
>>>>>>>>> would
>>>>>>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>>
>>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>>
>>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()"
>>>>>>>> and it
>>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>>
>>>>>>>
>>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>>
>>>>>>> How do you want to handle your patches? Do you want to clean them up and I'll
>>>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>>>
>>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can achieve
>>>>>> decent performance.
>>>>>
>>>>> I'm about to run it on Altra and M2. But I assume it will show similar results.
>>>
>>> OK results in, not looking great, which aligns with my previous experience. That
>>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>>> perhaps these results are not valid...
>>
>> I didn't see that so far on x86, maybe related to the PFN fixup?
> 
> All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index b19a8aee684c..9eb0fd693df9 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
>   }
>   #define set_ptes set_ptes
>   
> +#define PFN_PTE_SHIFT          PAGE_SHIFT
> +
>   /*
>    * Huge pte definitions.
>    */
> 
> 
> As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit case. But that won't affect this.
> 
> 
> With VM_DEBUG on, this is the first warning I see during boot:
> 
> 
> [    0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0 mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
> [    0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0 nr_pages_mapped:2 pincount:0

^ Ah, you are running with mTHP. Let me play with that.

The warning would indicate that nr is too large (or something else is 
messed up).

-- 
Cheers,

David / dhildenb



From jbx6244 at gmail.com  Wed Dec 20 03:58:13 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 20 Dec 2023 12:58:13 +0100
Subject: [PATCH] Revert "ARM: dts: rockchip: restyle emac nodes"
In-Reply-To: <20231220103334.2665543-1-andyshrk@163.com>
References: <20231220103334.2665543-1-andyshrk@163.com>
Message-ID: <406ba492-8f6b-26aa-55cf-2efa8d52ebaf@gmail.com>



On 12/20/23 11:33, Andy Yan wrote:
> From: Andy Yan <andy.yan at rock-chips.com>
> 
> When try to run rk3036 kylin board with mainline,
> I found the emac ethernet probe failed:
> 
> [    2.324583] loop: module loaded
> [    2.328435] SPI driver spidev has no spi_device_id for rockchip,spidev
> [    2.338688] tun: Universal TUN/TAP device driver, 1.6
> [    2.345397] rockchip_emac 10200000.ethernet: no regulator found
> [    2.351892] rockchip_emac 10200000.ethernet: ARC EMAC detected with id: 0x7fd02
> [    2.359331] rockchip_emac 10200000.ethernet: IRQ is 43
> [    2.364719] rockchip_emac 10200000.ethernet: MAC address is now e6:58:d6:ec:d9:7c
> [    2.396993] mdio_bus Synopsys MII Bus: mdio has invalid PHY address
> [    2.403306] mdio_bus Synopsys MII Bus: scan phy mdio at address 0
> [    2.508656] rockchip_emac 10200000.ethernet: of_phy_connect() failed
> [    2.516334] rockchip_emac 10200000.ethernet: failed to probe arc emac (-19)
> 
> This reverts commit 1dabb74971b3 ("ARM: dts: rockchip: restyle emac nodes")
> make emac on rk3036 kylin board probe right again:
> [    1.920385] CAN device driver interface
> [    1.925499] rockchip_emac 10200000.ethernet: no regulator found
> [    1.932535] rockchip_emac 10200000.ethernet: ARC EMAC detected with id: 0x7fd02
> [    1.940735] rockchip_emac 10200000.ethernet: IRQ is 42
> [    1.946743] rockchip_emac 10200000.ethernet: MAC address is now 96:7d:4f:0a:69:b3
> [    2.581340] rockchip_emac 10200000.ethernet: connected to Generic PHY phy with id 0xffffc816
> [    2.592560] e1000e: Intel(R) PRO/1000 Network Driver
> [    2.598136] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
> 
> Fixes: 1dabb74971b3 ("ARM: dts: rockchip: restyle emac nodes")
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> ---
> 
>  arch/arm/boot/dts/rockchip/rk3036-evb.dts     | 16 ++++++----------
>  arch/arm/boot/dts/rockchip/rk3036-kylin.dts   | 16 ++++++----------
>  arch/arm/boot/dts/rockchip/rk3036.dtsi        |  2 ++
>  .../boot/dts/rockchip/rk3066a-marsboard.dts   | 17 +++++++----------
>  .../boot/dts/rockchip/rk3066a-rayeager.dts    | 15 +++++----------
>  .../boot/dts/rockchip/rk3188-radxarock.dts    | 19 ++++++++-----------
>  arch/arm/boot/dts/rockchip/rk3xxx.dtsi        |  2 ++
>  7 files changed, 36 insertions(+), 51 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/rockchip/rk3036-evb.dts b/arch/arm/boot/dts/rockchip/rk3036-evb.dts
> index becdc0b664bf..94216f870b57 100644
> --- a/arch/arm/boot/dts/rockchip/rk3036-evb.dts
> +++ b/arch/arm/boot/dts/rockchip/rk3036-evb.dts
> @@ -15,20 +15,16 @@ memory at 60000000 {
>  };
>  
>  &emac {
> -	phy = <&phy0>;
> -	phy-reset-duration = <10>; /* millisecond */
> -	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&emac_xfer>, <&emac_mdio>;
> -	status = "okay";
> +	phy = <&phy0>;
> +	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
> +	phy-reset-duration = <10>; /* millisecond */


>  
> -	mdio {
> -		#address-cells = <1>;
> -		#size-cells = <0>;
> +	status = "okay";
>  
> -		phy0: ethernet-phy at 0 {
> -			reg = <0>;
> -		};
> +	phy0: ethernet-phy at 0 {
> +		reg = <0>;
>  	};

Sorry, didn't have the hardware when changing that binding.
A little bit background info:

The rk3036 TRM states:
Management Interface (MDIO) state machine for easy real-time communication with the
PHY

A revert of the DT must also match a binding. But...
Bindings must describe the hardware as close as possible.
So when the phy is called over the mdio we must add phy as part of a mdio node.(Is that correct? Ask a expert!)
Somehow the old emac driver doesn't support this sub node setup.
First request would be have a look to make the driver work as it should.

Johan

>  };
>  
> diff --git a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
> index 67e1e04139e7..e817eba8c622 100644
> --- a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
> +++ b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
> @@ -80,20 +80,16 @@ &acodec {
>  };
>  
>  &emac {
> -	phy = <&phy0>;
> -	phy-reset-duration = <10>; /* millisecond */
> -	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&emac_xfer>, <&emac_mdio>;
> -	status = "okay";
> +	phy = <&phy0>;
> +	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
> +	phy-reset-duration = <10>; /* millisecond */
>  
> -	mdio {
> -		#address-cells = <1>;
> -		#size-cells = <0>;
> +	status = "okay";
>  
> -		phy0: ethernet-phy at 0 {
> -			reg = <0>;
> -		};
> +	phy0: ethernet-phy at 0 {
> +		reg = <0>;
>  	};
>  };
>  
> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> index 78686fc72ce6..e240b89b0b35 100644
> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> @@ -228,6 +228,8 @@ emac: ethernet at 10200000 {
>  		compatible = "rockchip,rk3036-emac";
>  		reg = <0x10200000 0x4000>;
>  		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
>  		rockchip,grf = <&grf>;
>  		clocks = <&cru HCLK_MAC>, <&cru SCLK_MACREF>, <&cru SCLK_MAC>;
>  		clock-names = "hclk", "macref", "macclk";
> diff --git a/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts b/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts
> index f6e8d49a02ef..e3d6f0e81330 100644
> --- a/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts
> +++ b/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts
> @@ -150,21 +150,18 @@ vcc28_cif: regulator at 12 {
>  #include "../tps65910.dtsi"
>  
>  &emac {
> +	status = "okay";
> +
>  	phy = <&phy0>;
>  	phy-supply = <&vcc_rmii>;
> +
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>;
> -	status = "okay";
> -
> -	mdio {
> -		#address-cells = <1>;
> -		#size-cells = <0>;
>  
> -		phy0: ethernet-phy at 0 {
> -			reg = <0>;
> -			interrupt-parent = <&gpio1>;
> -			interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
> -		};
> +	phy0: ethernet-phy at 0 {
> +		reg = <0>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
>  	};
>  };
>  
> diff --git a/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts b/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts
> index 29d8e5bf88f5..096616324c2d 100644
> --- a/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts
> +++ b/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts
> @@ -142,20 +142,15 @@ &cpu1 {
>  };
>  
>  &emac {
> -	phy = <&phy0>;
> -	phy-supply = <&vcc_rmii>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&rmii_rst>;
> +	phy = <&phy0>;
> +	phy-supply = <&vcc_rmii>;
>  	status = "okay";
>  
> -	mdio {
> -		#address-cells = <1>;
> -		#size-cells = <0>;
> -
> -		phy0: ethernet-phy at 0 {
> -			reg = <0>;
> -			reset-gpios = <&gpio1 RK_PD6 GPIO_ACTIVE_LOW>;
> -		};
> +	phy0: ethernet-phy at 0 {
> +		reg = <0>;
> +		reset-gpios = <&gpio1 RK_PD6 GPIO_ACTIVE_LOW>;
>  	};
>  };
>  
> diff --git a/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts b/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts
> index 118deacd38c4..239d2ec37fdc 100644
> --- a/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts
> +++ b/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts
> @@ -126,21 +126,18 @@ vsys: vsys-regulator {
>  };
>  
>  &emac {
> -	phy = <&phy0>;
> -	phy-supply = <&vcc_rmii>;
> +	status = "okay";
> +
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>;
> -	status = "okay";
>  
> -	mdio {
> -		#address-cells = <1>;
> -		#size-cells = <0>;
> +	phy = <&phy0>;
> +	phy-supply = <&vcc_rmii>;
>  
> -		phy0: ethernet-phy at 0 {
> -			reg = <0>;
> -			interrupt-parent = <&gpio3>;
> -			interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
> -		};
> +	phy0: ethernet-phy at 0 {
> +		reg = <0>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
>  	};
>  };
>  
> diff --git a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> index cb4e42ede56a..17e89d30de78 100644
> --- a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
> @@ -193,6 +193,8 @@ emac: ethernet at 10204000 {
>  		compatible = "snps,arc-emac";
>  		reg = <0x10204000 0x3c>;
>  		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
>  
>  		rockchip,grf = <&grf>;
>  


From ryan.roberts at arm.com  Wed Dec 20 04:04:28 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 12:04:28 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
Message-ID: <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>

On 20/12/2023 11:58, David Hildenbrand wrote:
> On 20.12.23 12:51, Ryan Roberts wrote:
>> On 20/12/2023 11:36, David Hildenbrand wrote:
>>> On 20.12.23 12:28, Ryan Roberts wrote:
>>>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects()
>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number
>>>>>>>>>>>>>>>> of tlb
>>>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous
>>>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the
>>>>>>>>>>>>>>>> backend
>>>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is
>>>>>>>>>>>>>>>> expensive,
>>>>>>>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once
>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This code is very performance sensitive, and a significant
>>>>>>>>>>>>>>>> amount of
>>>>>>>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile
>>>>>>>>>>>>>>>> constant 1,
>>>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are
>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is
>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>>>>> significant performance change after this patch. Fork is called
>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal).
>>>>>>>>>>>>>>>> Tests
>>>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0
>>>>>>>>>>>>>>>> folios and
>>>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>> ???????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>>>> ???????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>>>> ???????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>>>> ???????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>>>> ???????? #endif
>>>>>>>>>>>>>>>> ???????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful
>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned
>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It's a shame we now lose the optimization for all other
>>>>>>>>>>>>>>> archtiectures.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>> arch
>>>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the
>>>>>>>>>>>>>> only
>>>>>>>>>>>>>> way
>>>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt
>>>>>>>>>>>>>> at an
>>>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time
>>>>>>>>>>>>>> constant 1
>>>>>>>>>>>>>> still
>>>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can
>>>>>>>>>>>>>> get
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>>> time
>>>>>>>>>>>>>> having to fiddle with the arm64 implementation; every conditional and
>>>>>>>>>>>>>> every
>>>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>>>> little in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> Apple
>>>>>>>>>>>>>> M2).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>>>> benefit to
>>>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>>>> prefer to
>>>>>>>>>>>>>> play
>>>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>>>>>>>> series. I
>>>>>>>>>>>>> implemented very generic and simple batching for large folios (all PTE
>>>>>>>>>>>>> bits
>>>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>>>>>>>> Silver
>>>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>>>
>>>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>>>
>>>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>>>
>>>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>>>
>>>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>>>
>>>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>>>
>>>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>>>
>>>>>>>>>> I've just been trying to compile and noticed this. Will take a look at
>>>>>>>>>> your
>>>>>>>>>> update.
>>>>>>>>>>
>>>>>>>>>> But upon review, I've noticed the part that I think makes this difficult
>>>>>>>>>> for
>>>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>>>>>>>> pte in
>>>>>>>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>>>> order to
>>>>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>>>>> wealking
>>>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>>>> block and
>>>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>>>>>>>> instead
>>>>>>>>>> of 256.
>>>>>>>>>>
>>>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid
>>>>>>>>>> the
>>>>>>>>>> bit
>>>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>>>> function
>>>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>>>>> patch 3
>>>>>>>>>> in my series).
>>>>>>>>>>
>>>>>>>>>> I guess you are going to say that we should combine both approaches, so
>>>>>>>>>> that
>>>>>>>>>> your batching loop can skip forward an arch-provided number of ptes? That
>>>>>>>>>> would
>>>>>>>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>>>
>>>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>>>
>>>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()"
>>>>>>>>> and it
>>>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>>>
>>>>>>>> How do you want to handle your patches? Do you want to clean them up and
>>>>>>>> I'll
>>>>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>>>>
>>>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can
>>>>>>> achieve
>>>>>>> decent performance.
>>>>>>
>>>>>> I'm about to run it on Altra and M2. But I assume it will show similar
>>>>>> results.
>>>>
>>>> OK results in, not looking great, which aligns with my previous experience.
>>>> That
>>>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>>>> perhaps these results are not valid...
>>>
>>> I didn't see that so far on x86, maybe related to the PFN fixup?
>>
>> All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index b19a8aee684c..9eb0fd693df9 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
>> ? }
>> ? #define set_ptes set_ptes
>> ? +#define PFN_PTE_SHIFT????????? PAGE_SHIFT
>> +
>> ? /*
>> ?? * Huge pte definitions.
>> ?? */
>>
>>
>> As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit
>> case. But that won't affect this.
>>
>>
>> With VM_DEBUG on, this is the first warning I see during boot:
>>
>>
>> [??? 0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0
>> mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
>> [??? 0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0
>> nr_pages_mapped:2 pincount:0
> 
> ^ Ah, you are running with mTHP. Let me play with that.

Err... Its in mm-unstable, but I'm not enabling any sizes. It should only be set
up for PMD-sized THP.

I am using XFS though, so I imagine its a file folio.

I've rebased your rmap cleanup and fork batching to the version of mm-unstable
that I was doing all my other testing with so I could compare numbers. But its
not very old (perhaps a week). All the patches applied without any conflict.

> 
> The warning would indicate that nr is too large (or something else is messed up).
> 



From james.clark at arm.com  Wed Dec 20 04:06:59 2023
From: james.clark at arm.com (James Clark)
Date: Wed, 20 Dec 2023 12:06:59 +0000
Subject: [PATCH 2/3] perf scripts python: arm-cs-trace-disasm.py: set
 start vm addr of exectable file to 0
In-Reply-To: <20231214123304.34087-3-tianruidong@linux.alibaba.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
 <20231214123304.34087-3-tianruidong@linux.alibaba.com>
Message-ID: <a3ae638f-8efc-70d9-75fd-9473db3de24d@arm.com>



On 14/12/2023 12:33, Ruidong Tian wrote:
> For exectable ELF file, which e_type is ET_EXEC, dso start address is a
> absolute address other than offset. Just set vm_start to zero when dso
> start is 0x400000, which means it is a exectable file.
> 
> Signed-off-by: Ruidong Tian <tianruidong at linux.alibaba.com>
> ---
>  tools/perf/scripts/python/arm-cs-trace-disasm.py | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> index 46bf6b02eea1..c9e14af5b58c 100755
> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
> @@ -260,8 +260,9 @@ def process_event(param_dict):
>  
>  	if (options.objdump_name != None):
>  		# It doesn't need to decrease virtual memory offset for disassembly
> -		# for kernel dso, so in this case we set vm_start to zero.
> -		if (dso == "[kernel.kallsyms]"):
> +		# for kernel dso and executable file dso, so in this case we set
> +		# vm_start to zero.
> +		if (dso == "[kernel.kallsyms]" or dso_start == 0x400000):
>  			dso_vm_start = 0
>  		else:
>  			dso_vm_start = int(dso_start)

I confirmed that this fixes the disassembly for static binaries. It
would have been nice to check the type of the file rather than using a
magic number, but it's not that easy and I don't really see a chance of
the number having a false positive.

I wonder if it's worth putting a fixes tag on this one? For the other
ones I'd say no tag as they have a chance of breaking things.

Reviewed-by: James Clark <james.clark at arm.com>


From david at redhat.com  Wed Dec 20 04:08:29 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 13:08:29 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
Message-ID: <6f414c1d-41f2-41f9-b02f-68b9f4a8cbe2@redhat.com>

On 20.12.23 13:04, Ryan Roberts wrote:
> On 20/12/2023 11:58, David Hildenbrand wrote:
>> On 20.12.23 12:51, Ryan Roberts wrote:
>>> On 20/12/2023 11:36, David Hildenbrand wrote:
>>>> On 20.12.23 12:28, Ryan Roberts wrote:
>>>>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>>>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects()
>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number
>>>>>>>>>>>>>>>>> of tlb
>>>>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous
>>>>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the
>>>>>>>>>>>>>>>>> backend
>>>>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is
>>>>>>>>>>>>>>>>> expensive,
>>>>>>>>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once
>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This code is very performance sensitive, and a significant
>>>>>>>>>>>>>>>>> amount of
>>>>>>>>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile
>>>>>>>>>>>>>>>>> constant 1,
>>>>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are
>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is
>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>>>>>> significant performance change after this patch. Fork is called
>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal).
>>>>>>>>>>>>>>>>> Tests
>>>>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0
>>>>>>>>>>>>>>>>> folios and
>>>>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>  ???????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>>>>>  ???????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>>>>>  ???????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>>>>>  ???????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>>>>>  ???????? #endif
>>>>>>>>>>>>>>>>>  ???????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful
>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned
>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's a shame we now lose the optimization for all other
>>>>>>>>>>>>>>>> archtiectures.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>> arch
>>>>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt
>>>>>>>>>>>>>>> at an
>>>>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time
>>>>>>>>>>>>>>> constant 1
>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can
>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>> having to fiddle with the arm64 implementation; every conditional and
>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>>>>> little in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> Apple
>>>>>>>>>>>>>>> M2).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>>>>> benefit to
>>>>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>>>>> prefer to
>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>>>>>>>>> series. I
>>>>>>>>>>>>>> implemented very generic and simple batching for large folios (all PTE
>>>>>>>>>>>>>> bits
>>>>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>>>>>>>>> Silver
>>>>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>>>>
>>>>>>>>>>> I've just been trying to compile and noticed this. Will take a look at
>>>>>>>>>>> your
>>>>>>>>>>> update.
>>>>>>>>>>>
>>>>>>>>>>> But upon review, I've noticed the part that I think makes this difficult
>>>>>>>>>>> for
>>>>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>>>>>>>>> pte in
>>>>>>>>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>>>>> order to
>>>>>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>>>>>> wealking
>>>>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>>>>> block and
>>>>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>>>>>>>>> instead
>>>>>>>>>>> of 256.
>>>>>>>>>>>
>>>>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid
>>>>>>>>>>> the
>>>>>>>>>>> bit
>>>>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>>>>> function
>>>>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>>>>>> patch 3
>>>>>>>>>>> in my series).
>>>>>>>>>>>
>>>>>>>>>>> I guess you are going to say that we should combine both approaches, so
>>>>>>>>>>> that
>>>>>>>>>>> your batching loop can skip forward an arch-provided number of ptes? That
>>>>>>>>>>> would
>>>>>>>>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>>>>
>>>>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>>>>
>>>>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()"
>>>>>>>>>> and it
>>>>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>>>>
>>>>>>>>> How do you want to handle your patches? Do you want to clean them up and
>>>>>>>>> I'll
>>>>>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>>>>>
>>>>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can
>>>>>>>> achieve
>>>>>>>> decent performance.
>>>>>>>
>>>>>>> I'm about to run it on Altra and M2. But I assume it will show similar
>>>>>>> results.
>>>>>
>>>>> OK results in, not looking great, which aligns with my previous experience.
>>>>> That
>>>>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>>>>> perhaps these results are not valid...
>>>>
>>>> I didn't see that so far on x86, maybe related to the PFN fixup?
>>>
>>> All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:
>>>
>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>> index b19a8aee684c..9eb0fd693df9 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
>>>  ? }
>>>  ? #define set_ptes set_ptes
>>>  ? +#define PFN_PTE_SHIFT????????? PAGE_SHIFT
>>> +
>>>  ? /*
>>>  ?? * Huge pte definitions.
>>>  ?? */
>>>
>>>
>>> As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit
>>> case. But that won't affect this.
>>>
>>>
>>> With VM_DEBUG on, this is the first warning I see during boot:
>>>
>>>
>>> [??? 0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0
>>> mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
>>> [??? 0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0
>>> nr_pages_mapped:2 pincount:0
>>
>> ^ Ah, you are running with mTHP. Let me play with that.
> 
> Err... Its in mm-unstable, but I'm not enabling any sizes. It should only be set
> up for PMD-sized THP.
> 
> I am using XFS though, so I imagine its a file folio.
> 

Right, that's even weirder :)

I should have that in my environment as well. Let me dig.

-- 
Cheers,

David / dhildenb



From retpolanne at posteo.net  Wed Dec 20 04:13:38 2023
From: retpolanne at posteo.net (Anne Macedo)
Date: Wed, 20 Dec 2023 12:13:38 +0000
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <3456637.QJadu78ljV@jernej-laptop>
References: <20231212122835.10850-2-retpolanne@posteo.net>
 <20231213122523.219cbfc0@donnerap.manchester.arm.com>
 <ljqe2z34upvzaxh744labf6ephmvcj535img2ct4d2vijjmboh@abg7anbngfyv>
 <3456637.QJadu78ljV@jernej-laptop>
Message-ID: <6p6d6l7mxof227mmdud2wsbgjr45dlqjxithpfjxnpjut2l23m@xz65d6ckyvi3>

On Tue, Dec 19, 2023 at 07:54:23PM +0100, Jernej Skrabec wrote:
> Dne torek, 19. december 2023 ob 01:31:05 CET je Anne Macedo napisal(a):
> > On Wed, Dec 13, 2023 at 12:25:23PM +0000, Andre Przywara wrote:
> > > On Wed, 13 Dec 2023 11:02:39 +0000
> > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > 
> > > Hi Anne,
> > > 
> > > > On Wed, Dec 13, 2023 at 01:35:44AM +0000, Andre Przywara wrote:
> > > > > On Tue, 12 Dec 2023 19:27:14 +0000
> > > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > > 
> > > > > Hi Anne,
> > > > >   
> > > > > > On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:  
> > > > > > > On Tue, 12 Dec 2023 12:28:30 +0000
> > > > > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > > > > 
> > > > > > > Hi Anne,
> > > > > > >     
> > > > > > > > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > > > > > > > Realtek 8211 PHY to Orange Pi One Plus.    
> > > > > > > 
> > > > > > > So can you state why this would be needed? This is the RTL8211 ID,    
> > > > > > 
> > > > > > Apologies, I completely forgot to include some context. 
> > > > > >   
> > > > > > > right? Which should be autodetected via MDIO. Looking back in my inbox
> > > > > > > you proposed this change before, for U-Boot, specifically, but I fail to
> > > > > > > find a solution or explanation what really happens here. Two Renesas .dts
> > > > > > > files have the same compatible, and the commit message talks about the
> > > > > > > reset line there, is this related?
> > > > > > > 
> > > > > > > So can you please give some more background and explanation? That would be
> > > > > > > part of a good commit message anyway ("why", not "what").    
> > > > > > 
> > > > > > Should I resend the commit with a more meaningful explanation? The
> > > > > > context is the following:
> > > > > > 
> > > > > > currently, ethernet doesn't seem to work on both u-boot and Linux on the
> > > > > > Orange Pi One Plus board. 
> > > > > > 
> > > > > > On the kernel, this error shows up:
> > > > > > 
> > > > > > Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > > [    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> > > > > > 
> > > > > > After applying this fix, the PHY gets attached: 
> > > > > > 
> > > > > > Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > > [    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
> > > > > > 
> > > > > > The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
> > > > > > to find a PHY, so this patch includes the correct PHY ID with the
> > > > > > RTL8211 ID. 
> > > > > > 
> > > > > > The behaviour is described on [1].  
> > > > > 
> > > > > So this is all an observation, but no real explanation, isn't it?  
> > > > 
> > > > I've made some analysis on [3] on this bug, but it was based solely on
> > > > u-boot. I was having trouble with the regulator and on u-boot nothing
> > > > would trigger the GPIO PD6 and the vcc-gmac-3v3 regulator, so the NIC
> > > > was completely dead. Next I did an analysis based on [2] because the
> > > > u-boot PHY initialization was flaky.
> > > > 
> > > > > To cite [1]: "If the PHY reports an incorrect ID (or none at all) ...".
> > > > > I am pretty sure this is not the case here, instead we are looking at
> > > > > some missing platform bits, like a missing clock, reset, or most likely
> > > > > regulator. Or one of the existing resources is wrongly assigned or  
> > > > 
> > > > As I mentioned, PHY initialization is flaky on u-boot, so maybe that
> > > > assumption is correct. 
> > > > 
> > > > > configured? If the PHY is not (yet?) powered correctly when the code
> > > > > does the auto-detection via the MDIO bus, then the initialisation would  
> > > > 
> > > > If I recall correctly (I don't know if I kept it in my notes :c), that
> > > > could be the case. regulator-boot-on makes the NIC work (LEDs blink, at
> > > > least) but it doesn't get initialized. 
> > > > 
> > > > > fail. But since it works when overriding the auto-detection, I feel
> > > > > like we are papering over something here.
> > > > > Do you have the schematics for this board? I can only find the one for
> > > > > the Orange Pi Plus 2E, and I don't know how similar those two are. This
> > > > > shows *two* regulators, but both are activated by the same GPIO.  
> > > > 
> > > > I do. It's available on [4]
> > > 
> > > Oh damn it, I got lost in Orange Pi's naming maze again - and was looking
> > > for the wrong board! So thanks for the link, and this clears things up!
> > > 
> > > So yes, the Orange Pi *One* Plus, much like the Orange Pi 3, uses *two*
> > > regulators for Ethernet: one 3.3V from the PMIC's ALDO2 rail to power the
> > > PHY, and a discrete 2.5V regulator, enabled by GPIO PD6, for the voltage
> > > level on the MDIO lines. On top of this there is a reset line for the PHY,
> > > though this is held up by a pull-up resistor, so it *should* work,
> > > although we should describe this in the DT.
> > > 
> > > So the DT looks wrong then: The reg_gmac_3v3 is actually a 2.5V regulator,
> > > and phy-supply is aldo2. I think it was done the way it is to somehow make
> > > it work with the current DT binding and code, which just supports one
> > > regulator. And aldo2 is referenced as the source of reg_gmac_3v3, which
> > > smells like another hack to me.
> > > 
> > > > > It would also be interesting to see if any of Corentin's work for the
> > > > > Orange Pi 3 helps here?  
> > > > 
> > > > Adding [5] for reference here, thanks! Will check it out. 
> > > 
> > > This is an older version, there are actually updates. And he also mentions
> > > your board as well, so I think it just can sail in the wake of the OPi 3
> > > Ethernet enablement.
> > > 
> > > Can you try if this change, just applied to your .dts instead, works?
> > > https://github.com/montjoie/linux/commit/cf6e192eca1d59be630e6729d2cef9e897b3da8c
> > 
> > Hello, 
> > 
> > I've tried applying this change but it didn't seem to work :( 
> 
> Those patches are obsolete, I took over the work and latest patches are here:
> https://github.com/jernejsk/linux-1/commits/opi3-net/ (last 3)
> 
> While I have OrangePi 3 and I have tested patches on it, I don't have Orange
> Pi One Plus.
> 
> > 
> > I got these errors:
> > 
> > [    5.117220] dwmac-sun8i 5020000.ethernet: IRQ eth_wake_irq not found
> > [    5.124366] dwmac-sun8i 5020000.ethernet: IRQ eth_lpi not found
> > [    5.130645] dwmac-sun8i 5020000.ethernet: No regulator found
> > [    5.137133] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> > [    5.143925] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
> > [    5.157588] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
> > [    5.164905] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
> > [    5.172189] dwmac-sun8i 5020000.ethernet: COE Type 2
> > [    5.177213] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
> > [    5.184033] dwmac-sun8i 5020000.ethernet: Normal descriptors
> > [    5.189724] dwmac-sun8i 5020000.ethernet: Chain mode enabled
> > [    5.381149] dwmac-sun8i 5020000.ethernet: EMAC reset timeout
> > [    5.386863] dwmac-sun8i 5020000.ethernet eth0: stmmac_dvr_remove: removing driver
> > [    5.438851] dwmac-sun8i: probe of 5020000.ethernet failed with error -110
> > 
> > I think I understand what is going on in Corentin's patch though. Please
> > correct me if I'm wrong:
> > 
> > 1. Instead of using the gmac-3v3, they use gmac-2v5 enabled by PD6.
> 
> Yes, 3v3 is completely wrong. Schematic only shows 2v5 regulator controlled
> with PD6.
> 
> > 2. For "phy-io", the 2v5 regulator is used
> > 3. For "ephy", the 3v3 regulator is used (aldo2 already sends this 3v3
> > signal)
> 
> Correct.
> 
> > 
> > My changes are here:
> > https://github.com/retpolanne/linux/commit/45aa2abde2606f9164f9a97d092fab6a36d45165
> > 
> > Maybe I should try to use the existing 3v3 regulator alongside a new 2v5
> > regulator on the DT. 
> 
> No.
> 
> Please make sure that you have
> https://github.com/jernejsk/linux-1/commit/25b44143ea8162209beb02759ca3ea3bd3be7a74

I was able to apply this one
https://github.com/jernejsk/linux-1/commit/18725ec6239ac4eedea4aefbe224594d2735399c

But not this one: 
https://github.com/jernejsk/linux-1/commit/25b44143ea8162209beb02759ca3ea3bd3be7a74

I believe this latter patch is required to make it work. Has it been
sent upstream? 

> 
> Without it, ethernet PHY won't be powered on and you will get errors in dmesg.
> 
> Best regards,
> Jernej
> 
> > > 
> > > Cheers,
> > > Andre
> > > 
> > > P.S. Is there any chance where I can reply/comment on your blog? It seems
> > > like I can clear some things up...
> > > 
> > > > [3] https://blog.retpolanne.com/hardware/embedded/2023/07/07/embedded-phy.html
> > > > [4] https://linux-sunxi.org/images/7/7c/OrangePi_OnePlus_Schematics_v2.0.pdf
> > > > [5] https://lore.kernel.org/netdev/20220509074857.195302-1-clabbe at baylibre.com/
> > > > 
> > > > Regards, Anne
> > > 
> > 
> > Regards, Anne
> > 
> 
> 
> 
> 


From m.felsch at pengutronix.de  Wed Dec 20 04:30:33 2023
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Wed, 20 Dec 2023 13:30:33 +0100
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <DU0PR04MB94170BCA413C2FD48A397B538896A@DU0PR04MB9417.eurprd04.prod.outlook.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
 <20231219192912.yulmczvqbuh4jizg@pengutronix.de>
 <DU0PR04MB94170BCA413C2FD48A397B538896A@DU0PR04MB9417.eurprd04.prod.outlook.com>
Message-ID: <20231220123033.nrbperhbr4jifuvh@pengutronix.de>

On 23-12-20, Peng Fan wrote:
> > Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
> > protocol
> > 
> > Hi Peng,
> > 
> > On 23-12-15, Peng Fan (OSS) wrote:
> > > From: Peng Fan <peng.fan at nxp.com>
> > >
> > > Add SCMI v3.2 pinctrl protocol bindings and example.
> > >
> > > Signed-off-by: Peng Fan <peng.fan at nxp.com>
> > > ---
> > >  .../devicetree/bindings/firmware/arm,scmi.yaml     | 99
> > ++++++++++++++++++++++
> > >  1 file changed, 99 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > index 4591523b51a0..bfd2b6a89979 100644
> > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > @@ -247,6 +247,85 @@ properties:
> > >        reg:
> > >          const: 0x18
> > >
> > > +  protocol at 19:
> > 
> > ...
> > 
> > > @@ -401,6 +480,26 @@ examples:
> > >              scmi_powercap: protocol at 18 {
> > >                  reg = <0x18>;
> > >              };
> > > +
> > > +            scmi_pinctrl: protocol at 19 {
> > > +                reg = <0x19>;
> > > +                #pinctrl-cells = <0>;
> > > +
> > > +                i2c2-pins {
> > > +                    groups = "i2c2_a", "i2c2_b";
> > > +                    function = "i2c2";
> > > +                };
> > > +
> > > +                mdio-pins {
> > > +                    groups = "avb_mdio";
> > > +                    drive-strength = <24>;
> > > +                };
> > > +
> > > +                keys_pins: keys-pins {
> > > +                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> > > +                    bias-pull-up;
> > > +                };
> > > +            };
> > 
> > This example is different to the one you mentioned within the cover-letter. I
> > didn't checked all patches just want to ask which API will be implemented by
> > this patchset?
> 
> I kept this change since it was tested by Oleksii, but anyway i.MX not use these.
> 
> The API, I suppose you are asking about this?
> static const struct pinctrl_ops pinctrl_scmi_pinctrl_ops = {                                        
>         .get_groups_count = pinctrl_scmi_get_groups_count,                                          
>         .get_group_name = pinctrl_scmi_get_group_name,                                              
>         .get_group_pins = pinctrl_scmi_get_group_pins,                                              
> #ifdef CONFIG_OF                                                                                    
>         .dt_node_to_map = pinconf_generic_dt_node_to_map_all,                                       
>         .dt_free_map = pinconf_generic_dt_free_map,                                                 
> #endif                                                                                              
> };
> 
> static const struct pinctrl_ops pinctrl_scmi_imx_pinctrl_ops = {                                    
>         .get_groups_count = pinctrl_scmi_get_groups_count,                                          
>         .get_group_name = pinctrl_scmi_get_group_name,                                              
>         .get_group_pins = pinctrl_scmi_get_group_pins,                                              
> #ifdef CONFIG_OF                                                                                    
>         .dt_node_to_map = pinctrl_scmi_imx_dt_node_to_map,                                          
>         .dt_free_map = pinconf_generic_dt_free_map,                                                 
> #endif                                                                                              
> };

I see, thanks for the clarification. In short: the i.MX SMCI pinctrl
DT-API is the same as the non-SCMI pinctrl API since the dt_node_to_map
will convert it.

Regards,
  Marco


From peng.fan at nxp.com  Wed Dec 20 04:33:57 2023
From: peng.fan at nxp.com (Peng Fan)
Date: Wed, 20 Dec 2023 12:33:57 +0000
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <20231220123033.nrbperhbr4jifuvh@pengutronix.de>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
 <20231219192912.yulmczvqbuh4jizg@pengutronix.de>
 <DU0PR04MB94170BCA413C2FD48A397B538896A@DU0PR04MB9417.eurprd04.prod.outlook.com>
 <20231220123033.nrbperhbr4jifuvh@pengutronix.de>
Message-ID: <DU0PR04MB9417E926CBD95BD7298B64D28896A@DU0PR04MB9417.eurprd04.prod.outlook.com>

> Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
> protocol
> 
> On 23-12-20, Peng Fan wrote:
> > > Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support
> > > pinctrl protocol
> > >
> > > Hi Peng,
> > >
> > > On 23-12-15, Peng Fan (OSS) wrote:
> > > > From: Peng Fan <peng.fan at nxp.com>
> > > >
> > > > Add SCMI v3.2 pinctrl protocol bindings and example.
> > > >
> > > > Signed-off-by: Peng Fan <peng.fan at nxp.com>
> > > > ---
> > > >  .../devicetree/bindings/firmware/arm,scmi.yaml     | 99
> > > ++++++++++++++++++++++
> > > >  1 file changed, 99 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > index 4591523b51a0..bfd2b6a89979 100644
> > > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > @@ -247,6 +247,85 @@ properties:
> > > >        reg:
> > > >          const: 0x18
> > > >
> > > > +  protocol at 19:
> > >
> > > ...
> > >
> > > > @@ -401,6 +480,26 @@ examples:
> > > >              scmi_powercap: protocol at 18 {
> > > >                  reg = <0x18>;
> > > >              };
> > > > +
> > > > +            scmi_pinctrl: protocol at 19 {
> > > > +                reg = <0x19>;
> > > > +                #pinctrl-cells = <0>;
> > > > +
> > > > +                i2c2-pins {
> > > > +                    groups = "i2c2_a", "i2c2_b";
> > > > +                    function = "i2c2";
> > > > +                };
> > > > +
> > > > +                mdio-pins {
> > > > +                    groups = "avb_mdio";
> > > > +                    drive-strength = <24>;
> > > > +                };
> > > > +
> > > > +                keys_pins: keys-pins {
> > > > +                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> > > > +                    bias-pull-up;
> > > > +                };
> > > > +            };
> > >
> > > This example is different to the one you mentioned within the
> > > cover-letter. I didn't checked all patches just want to ask which
> > > API will be implemented by this patchset?
> >
> > I kept this change since it was tested by Oleksii, but anyway i.MX not use
> these.
> >
> > The API, I suppose you are asking about this?
> > static const struct pinctrl_ops pinctrl_scmi_pinctrl_ops = {
> >         .get_groups_count = pinctrl_scmi_get_groups_count,
> >         .get_group_name = pinctrl_scmi_get_group_name,
> >         .get_group_pins = pinctrl_scmi_get_group_pins,
> > #ifdef CONFIG_OF
> >         .dt_node_to_map = pinconf_generic_dt_node_to_map_all,
> >         .dt_free_map = pinconf_generic_dt_free_map,
> > #endif
> > };
> >
> > static const struct pinctrl_ops pinctrl_scmi_imx_pinctrl_ops = {
> >         .get_groups_count = pinctrl_scmi_get_groups_count,
> >         .get_group_name = pinctrl_scmi_get_group_name,
> >         .get_group_pins = pinctrl_scmi_get_group_pins,
> > #ifdef CONFIG_OF
> >         .dt_node_to_map = pinctrl_scmi_imx_dt_node_to_map,
> >         .dt_free_map = pinconf_generic_dt_free_map,
> > #endif
> > };
> 
> I see, thanks for the clarification. In short: the i.MX SMCI pinctrl DT-API is the
> same as the non-SCMI pinctrl API since the dt_node_to_map will convert it.

Yes, the fsl,pins format is same whether SCMI or non-SCMI. But we need
to pack the data to a format that matches the i.MX OEM SCMI PINCTRL
protocol, so we need to dedicated dt_node_to_map here.

Thanks,
Peng.

> 
> Regards,
>   Marco


From m.felsch at pengutronix.de  Wed Dec 20 04:37:45 2023
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Wed, 20 Dec 2023 13:37:45 +0100
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <DU0PR04MB9417E926CBD95BD7298B64D28896A@DU0PR04MB9417.eurprd04.prod.outlook.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
 <20231219192912.yulmczvqbuh4jizg@pengutronix.de>
 <DU0PR04MB94170BCA413C2FD48A397B538896A@DU0PR04MB9417.eurprd04.prod.outlook.com>
 <20231220123033.nrbperhbr4jifuvh@pengutronix.de>
 <DU0PR04MB9417E926CBD95BD7298B64D28896A@DU0PR04MB9417.eurprd04.prod.outlook.com>
Message-ID: <20231220123745.ksdumfymu4xruufa@pengutronix.de>

On 23-12-20, Peng Fan wrote:
> > Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
> > protocol
> > 
> > On 23-12-20, Peng Fan wrote:
> > > > Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support
> > > > pinctrl protocol
> > > >
> > > > Hi Peng,
> > > >
> > > > On 23-12-15, Peng Fan (OSS) wrote:
> > > > > From: Peng Fan <peng.fan at nxp.com>
> > > > >
> > > > > Add SCMI v3.2 pinctrl protocol bindings and example.
> > > > >
> > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com>
> > > > > ---
> > > > >  .../devicetree/bindings/firmware/arm,scmi.yaml     | 99
> > > > ++++++++++++++++++++++
> > > > >  1 file changed, 99 insertions(+)
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > > b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > > index 4591523b51a0..bfd2b6a89979 100644
> > > > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > > @@ -247,6 +247,85 @@ properties:
> > > > >        reg:
> > > > >          const: 0x18
> > > > >
> > > > > +  protocol at 19:
> > > >
> > > > ...
> > > >
> > > > > @@ -401,6 +480,26 @@ examples:
> > > > >              scmi_powercap: protocol at 18 {
> > > > >                  reg = <0x18>;
> > > > >              };
> > > > > +
> > > > > +            scmi_pinctrl: protocol at 19 {
> > > > > +                reg = <0x19>;
> > > > > +                #pinctrl-cells = <0>;
> > > > > +
> > > > > +                i2c2-pins {
> > > > > +                    groups = "i2c2_a", "i2c2_b";
> > > > > +                    function = "i2c2";
> > > > > +                };
> > > > > +
> > > > > +                mdio-pins {
> > > > > +                    groups = "avb_mdio";
> > > > > +                    drive-strength = <24>;
> > > > > +                };
> > > > > +
> > > > > +                keys_pins: keys-pins {
> > > > > +                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> > > > > +                    bias-pull-up;
> > > > > +                };
> > > > > +            };
> > > >
> > > > This example is different to the one you mentioned within the
> > > > cover-letter. I didn't checked all patches just want to ask which
> > > > API will be implemented by this patchset?
> > >
> > > I kept this change since it was tested by Oleksii, but anyway i.MX not use
> > these.
> > >
> > > The API, I suppose you are asking about this?
> > > static const struct pinctrl_ops pinctrl_scmi_pinctrl_ops = {
> > >         .get_groups_count = pinctrl_scmi_get_groups_count,
> > >         .get_group_name = pinctrl_scmi_get_group_name,
> > >         .get_group_pins = pinctrl_scmi_get_group_pins,
> > > #ifdef CONFIG_OF
> > >         .dt_node_to_map = pinconf_generic_dt_node_to_map_all,
> > >         .dt_free_map = pinconf_generic_dt_free_map,
> > > #endif
> > > };
> > >
> > > static const struct pinctrl_ops pinctrl_scmi_imx_pinctrl_ops = {
> > >         .get_groups_count = pinctrl_scmi_get_groups_count,
> > >         .get_group_name = pinctrl_scmi_get_group_name,
> > >         .get_group_pins = pinctrl_scmi_get_group_pins,
> > > #ifdef CONFIG_OF
> > >         .dt_node_to_map = pinctrl_scmi_imx_dt_node_to_map,
> > >         .dt_free_map = pinconf_generic_dt_free_map,
> > > #endif
> > > };
> > 
> > I see, thanks for the clarification. In short: the i.MX SMCI pinctrl DT-API is the
> > same as the non-SCMI pinctrl API since the dt_node_to_map will convert it.
> 
> Yes, the fsl,pins format is same whether SCMI or non-SCMI. But we need
> to pack the data to a format that matches the i.MX OEM SCMI PINCTRL
> protocol, so we need to dedicated dt_node_to_map here.

Yes, I saw that you're using the enum values 192-255 for the OEM
specific part and the packing. Does you have public access to the FW
implementing the SCMI?

Regards,
  Marco

> 
> Thanks,
> Peng.
> 
> > 
> > Regards,
> >   Marco
> 
> 


From patrick at stwcx.xyz  Wed Dec 20 04:38:59 2023
From: patrick at stwcx.xyz (Patrick Williams)
Date: Wed, 20 Dec 2023 06:38:59 -0600
Subject: [PATCH v8] ARM: dts: aspeed: Adding Facebook Bletchley BMC
In-Reply-To: <20231220080733.GA30641@wunner.de>
References: <20231220080733.GA30641@wunner.de>
Message-ID: <F444BFCC-1D44-4AF6-A0E1-B153A217FFE3@stwcx.xyz>


---
Patrick Williams

> On Dec 20, 2023, at 2:07?AM, Lukas Wunner <lukas at wunner.de> wrote:
> 
> ?On Tue, Dec 07, 2021 at 05:49:24PM +0800, Howard Chiu wrote:
>> Initial introduction of Facebook Bletchley equipped with
>> Aspeed 2600 BMC SoC.
> [...]
>> +        tpmdev at 0 {
>> +            compatible = "tcg,tpm_tis-spi";
> 
> What's the chip used on this board?  Going forward, the DT schema for TPMs
> requires the exact chip name in addition to the generic "tcg,tpm_tis-spi".

Why is this a requirement?  This assumes there is exactly one chip. TPMs are often placed on a pluggable module in which multiple vendors could be used. There is no way in the DTS to specify multiple compatible chips. 

>> +            spi-max-frequency = <33000000>;
>> +            reg = <0>;
>> +        };
>> +    };



From david at redhat.com  Wed Dec 20 04:54:59 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 13:54:59 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
Message-ID: <54d645de-d031-4efc-a1ba-042f709cd549@redhat.com>

On 20.12.23 13:04, Ryan Roberts wrote:
> On 20/12/2023 11:58, David Hildenbrand wrote:
>> On 20.12.23 12:51, Ryan Roberts wrote:
>>> On 20/12/2023 11:36, David Hildenbrand wrote:
>>>> On 20.12.23 12:28, Ryan Roberts wrote:
>>>>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>>>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects()
>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number
>>>>>>>>>>>>>>>>> of tlb
>>>>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous
>>>>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the
>>>>>>>>>>>>>>>>> backend
>>>>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is
>>>>>>>>>>>>>>>>> expensive,
>>>>>>>>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once
>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This code is very performance sensitive, and a significant
>>>>>>>>>>>>>>>>> amount of
>>>>>>>>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile
>>>>>>>>>>>>>>>>> constant 1,
>>>>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are
>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is
>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>>>>>> significant performance change after this patch. Fork is called
>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal).
>>>>>>>>>>>>>>>>> Tests
>>>>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0
>>>>>>>>>>>>>>>>> folios and
>>>>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>  ???????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>>>>>  ???????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>>>>>  ???????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>>>>>  ???????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>>>>>  ???????? #endif
>>>>>>>>>>>>>>>>>  ???????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful
>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned
>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's a shame we now lose the optimization for all other
>>>>>>>>>>>>>>>> archtiectures.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>> arch
>>>>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt
>>>>>>>>>>>>>>> at an
>>>>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time
>>>>>>>>>>>>>>> constant 1
>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can
>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>> having to fiddle with the arm64 implementation; every conditional and
>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>>>>> little in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> Apple
>>>>>>>>>>>>>>> M2).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>>>>> benefit to
>>>>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>>>>> prefer to
>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>>>>>>>>> series. I
>>>>>>>>>>>>>> implemented very generic and simple batching for large folios (all PTE
>>>>>>>>>>>>>> bits
>>>>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>>>>>>>>> Silver
>>>>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>>>>
>>>>>>>>>>> I've just been trying to compile and noticed this. Will take a look at
>>>>>>>>>>> your
>>>>>>>>>>> update.
>>>>>>>>>>>
>>>>>>>>>>> But upon review, I've noticed the part that I think makes this difficult
>>>>>>>>>>> for
>>>>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>>>>>>>>> pte in
>>>>>>>>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>>>>> order to
>>>>>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>>>>>> wealking
>>>>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>>>>> block and
>>>>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>>>>>>>>> instead
>>>>>>>>>>> of 256.
>>>>>>>>>>>
>>>>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid
>>>>>>>>>>> the
>>>>>>>>>>> bit
>>>>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>>>>> function
>>>>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>>>>>> patch 3
>>>>>>>>>>> in my series).
>>>>>>>>>>>
>>>>>>>>>>> I guess you are going to say that we should combine both approaches, so
>>>>>>>>>>> that
>>>>>>>>>>> your batching loop can skip forward an arch-provided number of ptes? That
>>>>>>>>>>> would
>>>>>>>>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>>>>
>>>>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>>>>
>>>>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()"
>>>>>>>>>> and it
>>>>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>>>>
>>>>>>>>> How do you want to handle your patches? Do you want to clean them up and
>>>>>>>>> I'll
>>>>>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>>>>>
>>>>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can
>>>>>>>> achieve
>>>>>>>> decent performance.
>>>>>>>
>>>>>>> I'm about to run it on Altra and M2. But I assume it will show similar
>>>>>>> results.
>>>>>
>>>>> OK results in, not looking great, which aligns with my previous experience.
>>>>> That
>>>>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>>>>> perhaps these results are not valid...
>>>>
>>>> I didn't see that so far on x86, maybe related to the PFN fixup?
>>>
>>> All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:
>>>
>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>> index b19a8aee684c..9eb0fd693df9 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
>>>  ? }
>>>  ? #define set_ptes set_ptes
>>>  ? +#define PFN_PTE_SHIFT????????? PAGE_SHIFT
>>> +
>>>  ? /*
>>>  ?? * Huge pte definitions.
>>>  ?? */
>>>
>>>
>>> As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit
>>> case. But that won't affect this.
>>>
>>>
>>> With VM_DEBUG on, this is the first warning I see during boot:
>>>
>>>
>>> [??? 0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0
>>> mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
>>> [??? 0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0
>>> nr_pages_mapped:2 pincount:0
>>
>> ^ Ah, you are running with mTHP. Let me play with that.
> 
> Err... Its in mm-unstable, but I'm not enabling any sizes. It should only be set
> up for PMD-sized THP.
> 
> I am using XFS though, so I imagine its a file folio.
> 
> I've rebased your rmap cleanup and fork batching to the version of mm-unstable
> that I was doing all my other testing with so I could compare numbers. But its
> not very old (perhaps a week). All the patches applied without any conflict.

I think it was something stupid: I would get "17" from folio_pte_batch() 
for an order-4 folio, but only sometimes. The rmap sanity checks were 
definitely worth it :)

I guess we hit the case "next mapped folio is actually the next physical 
folio" and the detection for that was off by one.

diff --git a/mm/memory.c b/mm/memory.c
index 187d1b9b70e2..2af34add7ed7 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -975,7 +975,7 @@ static inline int folio_pte_batch(struct folio 
*folio, unsigned long addr,
                  * corner cases the next PFN might fall into a different
                  * folio.
                  */
-               if (pte_pfn(pte) == folio_end_pfn - 1)
+               if (pte_pfn(pte) == folio_end_pfn)
                         break;

Briefly tested, have to do more testing.

I only tested with order-9, which means max_nr would cap at 512. 
Shouldn't affect the performance measurements, will redo them.

-- 
Cheers,

David / dhildenb



From ryan.roberts at arm.com  Wed Dec 20 05:02:27 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 13:02:27 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <54d645de-d031-4efc-a1ba-042f709cd549@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
 <54d645de-d031-4efc-a1ba-042f709cd549@redhat.com>
Message-ID: <ace9ca55-1515-4ba3-b35e-7acad32e1f1a@arm.com>

On 20/12/2023 12:54, David Hildenbrand wrote:
> On 20.12.23 13:04, Ryan Roberts wrote:
>> On 20/12/2023 11:58, David Hildenbrand wrote:
>>> On 20.12.23 12:51, Ryan Roberts wrote:
>>>> On 20/12/2023 11:36, David Hildenbrand wrote:
>>>>> On 20.12.23 12:28, Ryan Roberts wrote:
>>>>>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>>>>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>>>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A
>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects()
>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number
>>>>>>>>>>>>>>>>>> of tlb
>>>>>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform
>>>>>>>>>>>>>>>>>> during
>>>>>>>>>>>>>>>>>> fork, as it is about to add transparent support for the
>>>>>>>>>>>>>>>>>> "contiguous
>>>>>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the
>>>>>>>>>>>>>>>>>> backend
>>>>>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is
>>>>>>>>>>>>>>>>>> expensive,
>>>>>>>>>>>>>>>>>> when all ptes in the range are being write-protected.
>>>>>>>>>>>>>>>>>> Similarly, by
>>>>>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once
>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>> are all populated - they can be initially populated as a
>>>>>>>>>>>>>>>>>> contiguous
>>>>>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This code is very performance sensitive, and a significant
>>>>>>>>>>>>>>>>>> amount of
>>>>>>>>>>>>>>>>>> effort has been put into not regressing performance for the
>>>>>>>>>>>>>>>>>> order-0
>>>>>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile
>>>>>>>>>>>>>>>>>> constant 1,
>>>>>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are
>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this
>>>>>>>>>>>>>>>>>> change is
>>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>>>>>>> significant performance change after this patch. Fork is called
>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal).
>>>>>>>>>>>>>>>>>> Tests
>>>>>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0
>>>>>>>>>>>>>>>>>> folios and
>>>>>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>> ????????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>>>>>> ????????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>>>>>> ????????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>>>>>> ????????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>>>>>> ????????? #endif
>>>>>>>>>>>>>>>>>> ????????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a
>>>>>>>>>>>>>>>>>> contiguous
>>>>>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful
>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte,
>>>>>>>>>>>>>>>>>> unsigned
>>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It's a shame we now lose the optimization for all other
>>>>>>>>>>>>>>>>> archtiectures.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that
>>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>>> arch
>>>>>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it
>>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first
>>>>>>>>>>>>>>>> attempt
>>>>>>>>>>>>>>>> at an
>>>>>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time
>>>>>>>>>>>>>>>> constant 1
>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can
>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>> having to fiddle with the arm64 implementation; every
>>>>>>>>>>>>>>>> conditional and
>>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>>>>>> little in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere
>>>>>>>>>>>>>>>> Altra
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> Apple
>>>>>>>>>>>>>>>> M2).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>>>>>> benefit to
>>>>>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>>>>>> prefer to
>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I just hacked something up, on top of my beloved rmap
>>>>>>>>>>>>>>> cleanup/batching
>>>>>>>>>>>>>>> series. I
>>>>>>>>>>>>>>> implemented very generic and simple batching for large folios
>>>>>>>>>>>>>>> (all PTE
>>>>>>>>>>>>>>> bits
>>>>>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R)
>>>>>>>>>>>>>>> Xeon(R)
>>>>>>>>>>>>>>> Silver
>>>>>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>>>>>
>>>>>>>>>>>> I've just been trying to compile and noticed this. Will take a look at
>>>>>>>>>>>> your
>>>>>>>>>>>> update.
>>>>>>>>>>>>
>>>>>>>>>>>> But upon review, I've noticed the part that I think makes this
>>>>>>>>>>>> difficult
>>>>>>>>>>>> for
>>>>>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for
>>>>>>>>>>>> every
>>>>>>>>>>>> pte in
>>>>>>>>>>>> the batch. While this is functionally correct, once arm64 has the
>>>>>>>>>>>> contpte
>>>>>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>>>>>> order to
>>>>>>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>>>>>>> wealking
>>>>>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>>>>>> block and
>>>>>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16
>>>>>>>>>>>> READ_ONCE()s
>>>>>>>>>>>> instead
>>>>>>>>>>>> of 256.
>>>>>>>>>>>>
>>>>>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would
>>>>>>>>>>>> avoid
>>>>>>>>>>>> the
>>>>>>>>>>>> bit
>>>>>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>>>>>> function
>>>>>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>>>>>>> patch 3
>>>>>>>>>>>> in my series).
>>>>>>>>>>>>
>>>>>>>>>>>> I guess you are going to say that we should combine both approaches, so
>>>>>>>>>>>> that
>>>>>>>>>>>> your batching loop can skip forward an arch-provided number of ptes?
>>>>>>>>>>>> That
>>>>>>>>>>>> would
>>>>>>>>>>>> certainly work, but feels like an orthogonal change to what I'm
>>>>>>>>>>>> trying to
>>>>>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>>>>>
>>>>>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>>>>>
>>>>>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during
>>>>>>>>>>> fork()"
>>>>>>>>>>> and it
>>>>>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>>>>>
>>>>>>>>>> How do you want to handle your patches? Do you want to clean them up and
>>>>>>>>>> I'll
>>>>>>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>>>>>>
>>>>>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can
>>>>>>>>> achieve
>>>>>>>>> decent performance.
>>>>>>>>
>>>>>>>> I'm about to run it on Altra and M2. But I assume it will show similar
>>>>>>>> results.
>>>>>>
>>>>>> OK results in, not looking great, which aligns with my previous experience.
>>>>>> That
>>>>>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>>>>>> perhaps these results are not valid...
>>>>>
>>>>> I didn't see that so far on x86, maybe related to the PFN fixup?
>>>>
>>>> All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:
>>>>
>>>> diff --git a/arch/arm64/include/asm/pgtable.h
>>>> b/arch/arm64/include/asm/pgtable.h
>>>> index b19a8aee684c..9eb0fd693df9 100644
>>>> --- a/arch/arm64/include/asm/pgtable.h
>>>> +++ b/arch/arm64/include/asm/pgtable.h
>>>> @@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
>>>> ?? }
>>>> ?? #define set_ptes set_ptes
>>>> ?? +#define PFN_PTE_SHIFT????????? PAGE_SHIFT
>>>> +
>>>> ?? /*
>>>> ??? * Huge pte definitions.
>>>> ??? */
>>>>
>>>>
>>>> As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit
>>>> case. But that won't affect this.
>>>>
>>>>
>>>> With VM_DEBUG on, this is the first warning I see during boot:
>>>>
>>>>
>>>> [??? 0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0
>>>> mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
>>>> [??? 0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0
>>>> nr_pages_mapped:2 pincount:0
>>>
>>> ^ Ah, you are running with mTHP. Let me play with that.
>>
>> Err... Its in mm-unstable, but I'm not enabling any sizes. It should only be set
>> up for PMD-sized THP.
>>
>> I am using XFS though, so I imagine its a file folio.
>>
>> I've rebased your rmap cleanup and fork batching to the version of mm-unstable
>> that I was doing all my other testing with so I could compare numbers. But its
>> not very old (perhaps a week). All the patches applied without any conflict.
> 
> I think it was something stupid: I would get "17" from folio_pte_batch() for an
> order-4 folio, but only sometimes. The rmap sanity checks were definitely worth
> it :)
> 
> I guess we hit the case "next mapped folio is actually the next physical folio"
> and the detection for that was off by one.
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index 187d1b9b70e2..2af34add7ed7 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -975,7 +975,7 @@ static inline int folio_pte_batch(struct folio *folio,
> unsigned long addr,
> ???????????????? * corner cases the next PFN might fall into a different
> ???????????????? * folio.
> ???????????????? */
> -?????????????? if (pte_pfn(pte) == folio_end_pfn - 1)
> +?????????????? if (pte_pfn(pte) == folio_end_pfn)
> ??????????????????????? break;
> 

haha, of course! I've been staring at this for an hour and didn't notice.

I no longer see any warnings during boot with debug enabled. Will rerun perf
measurements.


> Briefly tested, have to do more testing.
> 
> I only tested with order-9, which means max_nr would cap at 512. Shouldn't
> affect the performance measurements, will redo them.
> 



From david at redhat.com  Wed Dec 20 05:06:02 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 14:06:02 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
Message-ID: <9f99a3ca-051e-4b1b-81e9-8456d8e422ad@redhat.com>

On 20.12.23 13:04, Ryan Roberts wrote:
> On 20/12/2023 11:58, David Hildenbrand wrote:
>> On 20.12.23 12:51, Ryan Roberts wrote:
>>> On 20/12/2023 11:36, David Hildenbrand wrote:
>>>> On 20.12.23 12:28, Ryan Roberts wrote:
>>>>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>>>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A given
>>>>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects()
>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number
>>>>>>>>>>>>>>>>> of tlb
>>>>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform during
>>>>>>>>>>>>>>>>> fork, as it is about to add transparent support for the "contiguous
>>>>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the
>>>>>>>>>>>>>>>>> backend
>>>>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is
>>>>>>>>>>>>>>>>> expensive,
>>>>>>>>>>>>>>>>> when all ptes in the range are being write-protected. Similarly, by
>>>>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once
>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> are all populated - they can be initially populated as a contiguous
>>>>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This code is very performance sensitive, and a significant
>>>>>>>>>>>>>>>>> amount of
>>>>>>>>>>>>>>>>> effort has been put into not regressing performance for the order-0
>>>>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile
>>>>>>>>>>>>>>>>> constant 1,
>>>>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are
>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this change is
>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>>>>>> significant performance change after this patch. Fork is called
>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal).
>>>>>>>>>>>>>>>>> Tests
>>>>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0
>>>>>>>>>>>>>>>>> folios and
>>>>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>  ???????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>>>>>  ???????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>>>>>  ???????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>>>>>  ???????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>>>>>  ???????? #endif
>>>>>>>>>>>>>>>>>  ???????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a contiguous
>>>>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful
>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned
>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's a shame we now lose the optimization for all other
>>>>>>>>>>>>>>>> archtiectures.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that doesn't
>>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>> arch
>>>>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it was the
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first attempt
>>>>>>>>>>>>>>> at an
>>>>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time
>>>>>>>>>>>>>>> constant 1
>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can
>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>> having to fiddle with the arm64 implementation; every conditional and
>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>>>>> little in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere Altra
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> Apple
>>>>>>>>>>>>>>> M2).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>>>>> benefit to
>>>>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>>>>> prefer to
>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I just hacked something up, on top of my beloved rmap cleanup/batching
>>>>>>>>>>>>>> series. I
>>>>>>>>>>>>>> implemented very generic and simple batching for large folios (all PTE
>>>>>>>>>>>>>> bits
>>>>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R) Xeon(R)
>>>>>>>>>>>>>> Silver
>>>>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>>>>
>>>>>>>>>>> I've just been trying to compile and noticed this. Will take a look at
>>>>>>>>>>> your
>>>>>>>>>>> update.
>>>>>>>>>>>
>>>>>>>>>>> But upon review, I've noticed the part that I think makes this difficult
>>>>>>>>>>> for
>>>>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for every
>>>>>>>>>>> pte in
>>>>>>>>>>> the batch. While this is functionally correct, once arm64 has the contpte
>>>>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>>>>> order to
>>>>>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>>>>>> wealking
>>>>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>>>>> block and
>>>>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16 READ_ONCE()s
>>>>>>>>>>> instead
>>>>>>>>>>> of 256.
>>>>>>>>>>>
>>>>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would avoid
>>>>>>>>>>> the
>>>>>>>>>>> bit
>>>>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>>>>> function
>>>>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>>>>>> patch 3
>>>>>>>>>>> in my series).
>>>>>>>>>>>
>>>>>>>>>>> I guess you are going to say that we should combine both approaches, so
>>>>>>>>>>> that
>>>>>>>>>>> your batching loop can skip forward an arch-provided number of ptes? That
>>>>>>>>>>> would
>>>>>>>>>>> certainly work, but feels like an orthogonal change to what I'm trying to
>>>>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>>>>
>>>>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>>>>
>>>>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during fork()"
>>>>>>>>>> and it
>>>>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>>>>
>>>>>>>>> How do you want to handle your patches? Do you want to clean them up and
>>>>>>>>> I'll
>>>>>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>>>>>
>>>>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can
>>>>>>>> achieve
>>>>>>>> decent performance.
>>>>>>>
>>>>>>> I'm about to run it on Altra and M2. But I assume it will show similar
>>>>>>> results.
>>>>>
>>>>> OK results in, not looking great, which aligns with my previous experience.
>>>>> That
>>>>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>>>>> perhaps these results are not valid...
>>>>
>>>> I didn't see that so far on x86, maybe related to the PFN fixup?
>>>
>>> All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:
>>>
>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>> index b19a8aee684c..9eb0fd693df9 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
>>>  ? }
>>>  ? #define set_ptes set_ptes
>>>  ? +#define PFN_PTE_SHIFT????????? PAGE_SHIFT
>>> +
>>>  ? /*
>>>  ?? * Huge pte definitions.
>>>  ?? */
>>>
>>>
>>> As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit
>>> case. But that won't affect this.
>>>
>>>
>>> With VM_DEBUG on, this is the first warning I see during boot:
>>>
>>>
>>> [??? 0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0
>>> mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
>>> [??? 0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0
>>> nr_pages_mapped:2 pincount:0
>>
>> ^ Ah, you are running with mTHP. Let me play with that.
> 
> Err... Its in mm-unstable, but I'm not enabling any sizes. It should only be set
> up for PMD-sized THP.
> 
> I am using XFS though, so I imagine its a file folio.
> 
> I've rebased your rmap cleanup and fork batching to the version of mm-unstable
> that I was doing all my other testing with so I could compare numbers. But its
> not very old (perhaps a week). All the patches applied without any conflict.


It would also be interesting to know if the compiler on arm64 decides to 
do something stupid: like not inline wrprotect_ptes().

Because with an effective unlikely(folio_test_large(folio)) we shouldn't 
see that much overhead.

-- 
Cheers,

David / dhildenb



From ryan.roberts at arm.com  Wed Dec 20 05:10:36 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 13:10:36 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <9f99a3ca-051e-4b1b-81e9-8456d8e422ad@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
 <9f99a3ca-051e-4b1b-81e9-8456d8e422ad@redhat.com>
Message-ID: <c1913fa2-d313-4f05-a649-da69b6d31d2a@arm.com>

On 20/12/2023 13:06, David Hildenbrand wrote:
> On 20.12.23 13:04, Ryan Roberts wrote:
>> On 20/12/2023 11:58, David Hildenbrand wrote:
>>> On 20.12.23 12:51, Ryan Roberts wrote:
>>>> On 20/12/2023 11:36, David Hildenbrand wrote:
>>>>> On 20.12.23 12:28, Ryan Roberts wrote:
>>>>>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>>>>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>>>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A
>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects()
>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number
>>>>>>>>>>>>>>>>>> of tlb
>>>>>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform
>>>>>>>>>>>>>>>>>> during
>>>>>>>>>>>>>>>>>> fork, as it is about to add transparent support for the
>>>>>>>>>>>>>>>>>> "contiguous
>>>>>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the
>>>>>>>>>>>>>>>>>> backend
>>>>>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is
>>>>>>>>>>>>>>>>>> expensive,
>>>>>>>>>>>>>>>>>> when all ptes in the range are being write-protected.
>>>>>>>>>>>>>>>>>> Similarly, by
>>>>>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once
>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>> are all populated - they can be initially populated as a
>>>>>>>>>>>>>>>>>> contiguous
>>>>>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This code is very performance sensitive, and a significant
>>>>>>>>>>>>>>>>>> amount of
>>>>>>>>>>>>>>>>>> effort has been put into not regressing performance for the
>>>>>>>>>>>>>>>>>> order-0
>>>>>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile
>>>>>>>>>>>>>>>>>> constant 1,
>>>>>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are
>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this
>>>>>>>>>>>>>>>>>> change is
>>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>>>>>>> significant performance change after this patch. Fork is called
>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal).
>>>>>>>>>>>>>>>>>> Tests
>>>>>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0
>>>>>>>>>>>>>>>>>> folios and
>>>>>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>> ????????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>>>>>> ????????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>>>>>> ????????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>>>>>> ????????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>>>>>> ????????? #endif
>>>>>>>>>>>>>>>>>> ????????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a
>>>>>>>>>>>>>>>>>> contiguous
>>>>>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful
>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte,
>>>>>>>>>>>>>>>>>> unsigned
>>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It's a shame we now lose the optimization for all other
>>>>>>>>>>>>>>>>> archtiectures.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that
>>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>>> arch
>>>>>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it
>>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first
>>>>>>>>>>>>>>>> attempt
>>>>>>>>>>>>>>>> at an
>>>>>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time
>>>>>>>>>>>>>>>> constant 1
>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can
>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>> having to fiddle with the arm64 implementation; every
>>>>>>>>>>>>>>>> conditional and
>>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>>>>>> little in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere
>>>>>>>>>>>>>>>> Altra
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> Apple
>>>>>>>>>>>>>>>> M2).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>>>>>> benefit to
>>>>>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>>>>>> prefer to
>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I just hacked something up, on top of my beloved rmap
>>>>>>>>>>>>>>> cleanup/batching
>>>>>>>>>>>>>>> series. I
>>>>>>>>>>>>>>> implemented very generic and simple batching for large folios
>>>>>>>>>>>>>>> (all PTE
>>>>>>>>>>>>>>> bits
>>>>>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R)
>>>>>>>>>>>>>>> Xeon(R)
>>>>>>>>>>>>>>> Silver
>>>>>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>>>>>
>>>>>>>>>>>> I've just been trying to compile and noticed this. Will take a look at
>>>>>>>>>>>> your
>>>>>>>>>>>> update.
>>>>>>>>>>>>
>>>>>>>>>>>> But upon review, I've noticed the part that I think makes this
>>>>>>>>>>>> difficult
>>>>>>>>>>>> for
>>>>>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for
>>>>>>>>>>>> every
>>>>>>>>>>>> pte in
>>>>>>>>>>>> the batch. While this is functionally correct, once arm64 has the
>>>>>>>>>>>> contpte
>>>>>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>>>>>> order to
>>>>>>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>>>>>>> wealking
>>>>>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>>>>>> block and
>>>>>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16
>>>>>>>>>>>> READ_ONCE()s
>>>>>>>>>>>> instead
>>>>>>>>>>>> of 256.
>>>>>>>>>>>>
>>>>>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would
>>>>>>>>>>>> avoid
>>>>>>>>>>>> the
>>>>>>>>>>>> bit
>>>>>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>>>>>> function
>>>>>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>>>>>>> patch 3
>>>>>>>>>>>> in my series).
>>>>>>>>>>>>
>>>>>>>>>>>> I guess you are going to say that we should combine both approaches, so
>>>>>>>>>>>> that
>>>>>>>>>>>> your batching loop can skip forward an arch-provided number of ptes?
>>>>>>>>>>>> That
>>>>>>>>>>>> would
>>>>>>>>>>>> certainly work, but feels like an orthogonal change to what I'm
>>>>>>>>>>>> trying to
>>>>>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>>>>>
>>>>>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>>>>>
>>>>>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during
>>>>>>>>>>> fork()"
>>>>>>>>>>> and it
>>>>>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>>>>>
>>>>>>>>>> How do you want to handle your patches? Do you want to clean them up and
>>>>>>>>>> I'll
>>>>>>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>>>>>>
>>>>>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can
>>>>>>>>> achieve
>>>>>>>>> decent performance.
>>>>>>>>
>>>>>>>> I'm about to run it on Altra and M2. But I assume it will show similar
>>>>>>>> results.
>>>>>>
>>>>>> OK results in, not looking great, which aligns with my previous experience.
>>>>>> That
>>>>>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>>>>>> perhaps these results are not valid...
>>>>>
>>>>> I didn't see that so far on x86, maybe related to the PFN fixup?
>>>>
>>>> All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:
>>>>
>>>> diff --git a/arch/arm64/include/asm/pgtable.h
>>>> b/arch/arm64/include/asm/pgtable.h
>>>> index b19a8aee684c..9eb0fd693df9 100644
>>>> --- a/arch/arm64/include/asm/pgtable.h
>>>> +++ b/arch/arm64/include/asm/pgtable.h
>>>> @@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
>>>> ?? }
>>>> ?? #define set_ptes set_ptes
>>>> ?? +#define PFN_PTE_SHIFT????????? PAGE_SHIFT
>>>> +
>>>> ?? /*
>>>> ??? * Huge pte definitions.
>>>> ??? */
>>>>
>>>>
>>>> As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit
>>>> case. But that won't affect this.
>>>>
>>>>
>>>> With VM_DEBUG on, this is the first warning I see during boot:
>>>>
>>>>
>>>> [??? 0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0
>>>> mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
>>>> [??? 0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0
>>>> nr_pages_mapped:2 pincount:0
>>>
>>> ^ Ah, you are running with mTHP. Let me play with that.
>>
>> Err... Its in mm-unstable, but I'm not enabling any sizes. It should only be set
>> up for PMD-sized THP.
>>
>> I am using XFS though, so I imagine its a file folio.
>>
>> I've rebased your rmap cleanup and fork batching to the version of mm-unstable
>> that I was doing all my other testing with so I could compare numbers. But its
>> not very old (perhaps a week). All the patches applied without any conflict.
> 
> 
> It would also be interesting to know if the compiler on arm64 decides to do
> something stupid: like not inline wrprotect_ptes().
> 
> Because with an effective unlikely(folio_test_large(folio)) we shouldn't see
> that much overhead.
> 

What version of gcc are you using? I must confess I'm using the Ubuntu 20.04
default version:

aarch64-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0

Perhaps I should grab something a bit newer?



From david at redhat.com  Wed Dec 20 05:13:30 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 14:13:30 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <c1913fa2-d313-4f05-a649-da69b6d31d2a@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <20231218105100.172635-3-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
 <9f99a3ca-051e-4b1b-81e9-8456d8e422ad@redhat.com>
 <c1913fa2-d313-4f05-a649-da69b6d31d2a@arm.com>
Message-ID: <c244707c-8c0c-4593-ab45-d8f165dbc5ee@redhat.com>

On 20.12.23 14:10, Ryan Roberts wrote:
> On 20/12/2023 13:06, David Hildenbrand wrote:
>> On 20.12.23 13:04, Ryan Roberts wrote:
>>> On 20/12/2023 11:58, David Hildenbrand wrote:
>>>> On 20.12.23 12:51, Ryan Roberts wrote:
>>>>> On 20/12/2023 11:36, David Hildenbrand wrote:
>>>>>> On 20.12.23 12:28, Ryan Roberts wrote:
>>>>>>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>>>>>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>>>>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>>>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A
>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous block of
>>>>>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>>>>>>> one go in the parent using the new helper, ptep_set_wrprotects()
>>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>>> set in one go in the child using the new helper, set_ptes_full().
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number
>>>>>>>>>>>>>>>>>>> of tlb
>>>>>>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform
>>>>>>>>>>>>>>>>>>> during
>>>>>>>>>>>>>>>>>>> fork, as it is about to add transparent support for the
>>>>>>>>>>>>>>>>>>> "contiguous
>>>>>>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the
>>>>>>>>>>>>>>>>>>> backend
>>>>>>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is
>>>>>>>>>>>>>>>>>>> expensive,
>>>>>>>>>>>>>>>>>>> when all ptes in the range are being write-protected.
>>>>>>>>>>>>>>>>>>> Similarly, by
>>>>>>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up ptes in
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range once
>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>> are all populated - they can be initially populated as a
>>>>>>>>>>>>>>>>>>> contiguous
>>>>>>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This code is very performance sensitive, and a significant
>>>>>>>>>>>>>>>>>>> amount of
>>>>>>>>>>>>>>>>>>> effort has been put into not regressing performance for the
>>>>>>>>>>>>>>>>>>> order-0
>>>>>>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile
>>>>>>>>>>>>>>>>>>> constant 1,
>>>>>>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are
>>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a separate
>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this
>>>>>>>>>>>>>>>>>>> change is
>>>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The following microbenchmark results demonstate that there is no
>>>>>>>>>>>>>>>>>>> significant performance change after this patch. Fork is called
>>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the time
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal).
>>>>>>>>>>>>>>>>>>> Tests
>>>>>>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0
>>>>>>>>>>>>>>>>>>> folios and
>>>>>>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the series is
>>>>>>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>  ????????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>>>>>>>  ????????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>>>>>>>  ????????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>>>>>>>  ????????? #define arch_flush_lazy_mmu_mode()??? do {} while (0)
>>>>>>>>>>>>>>>>>>>  ????????? #endif
>>>>>>>>>>>>>>>>>>>  ????????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next batch
>>>>>>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a
>>>>>>>>>>>>>>>>>>> contiguous
>>>>>>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>>>>>>> + * In such cases, this function returns the remaining number of
>>>>>>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be useful
>>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte,
>>>>>>>>>>>>>>>>>>> unsigned
>>>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It's a shame we now lose the optimization for all other
>>>>>>>>>>>>>>>>>> archtiectures.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that
>>>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>>>> arch
>>>>>>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it
>>>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first
>>>>>>>>>>>>>>>>> attempt
>>>>>>>>>>>>>>>>> at an
>>>>>>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time
>>>>>>>>>>>>>>>>> constant 1
>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'd have thought that something very basic would have worked like:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I can
>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>>> having to fiddle with the arm64 implementation; every
>>>>>>>>>>>>>>>>> conditional and
>>>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>>>>>>> little in
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere
>>>>>>>>>>>>>>>>> Altra
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> Apple
>>>>>>>>>>>>>>>>> M2).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>>>>>>> benefit to
>>>>>>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>>>>>>> prefer to
>>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I just hacked something up, on top of my beloved rmap
>>>>>>>>>>>>>>>> cleanup/batching
>>>>>>>>>>>>>>>> series. I
>>>>>>>>>>>>>>>> implemented very generic and simple batching for large folios
>>>>>>>>>>>>>>>> (all PTE
>>>>>>>>>>>>>>>> bits
>>>>>>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R)
>>>>>>>>>>>>>>>> Xeon(R)
>>>>>>>>>>>>>>>> Silver
>>>>>>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've just been trying to compile and noticed this. Will take a look at
>>>>>>>>>>>>> your
>>>>>>>>>>>>> update.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But upon review, I've noticed the part that I think makes this
>>>>>>>>>>>>> difficult
>>>>>>>>>>>>> for
>>>>>>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for
>>>>>>>>>>>>> every
>>>>>>>>>>>>> pte in
>>>>>>>>>>>>> the batch. While this is functionally correct, once arm64 has the
>>>>>>>>>>>>> contpte
>>>>>>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>>>>>>> order to
>>>>>>>>>>>>> gather the access and dirty bits. So if your batching function ends up
>>>>>>>>>>>>> wealking
>>>>>>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>>>>>>> performance. That's why I added the arch-specific pte_batch_remaining()
>>>>>>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>>>>>>> block and
>>>>>>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16
>>>>>>>>>>>>> READ_ONCE()s
>>>>>>>>>>>>> instead
>>>>>>>>>>>>> of 256.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would
>>>>>>>>>>>>> avoid
>>>>>>>>>>>>> the
>>>>>>>>>>>>> bit
>>>>>>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>>>>>>> function
>>>>>>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there. (see
>>>>>>>>>>>>> patch 3
>>>>>>>>>>>>> in my series).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess you are going to say that we should combine both approaches, so
>>>>>>>>>>>>> that
>>>>>>>>>>>>> your batching loop can skip forward an arch-provided number of ptes?
>>>>>>>>>>>>> That
>>>>>>>>>>>>> would
>>>>>>>>>>>>> certainly work, but feels like an orthogonal change to what I'm
>>>>>>>>>>>>> trying to
>>>>>>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>>>>>>
>>>>>>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>>>>>>
>>>>>>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during
>>>>>>>>>>>> fork()"
>>>>>>>>>>>> and it
>>>>>>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>>>>>>
>>>>>>>>>>> How do you want to handle your patches? Do you want to clean them up and
>>>>>>>>>>> I'll
>>>>>>>>>>> base my stuff on top? Or do you want me to take them and sort it all out?
>>>>>>>>>>
>>>>>>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can
>>>>>>>>>> achieve
>>>>>>>>>> decent performance.
>>>>>>>>>
>>>>>>>>> I'm about to run it on Altra and M2. But I assume it will show similar
>>>>>>>>> results.
>>>>>>>
>>>>>>> OK results in, not looking great, which aligns with my previous experience.
>>>>>>> That
>>>>>>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>>>>>>> perhaps these results are not valid...
>>>>>>
>>>>>> I didn't see that so far on x86, maybe related to the PFN fixup?
>>>>>
>>>>> All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:
>>>>>
>>>>> diff --git a/arch/arm64/include/asm/pgtable.h
>>>>> b/arch/arm64/include/asm/pgtable.h
>>>>> index b19a8aee684c..9eb0fd693df9 100644
>>>>> --- a/arch/arm64/include/asm/pgtable.h
>>>>> +++ b/arch/arm64/include/asm/pgtable.h
>>>>> @@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
>>>>>  ?? }
>>>>>  ?? #define set_ptes set_ptes
>>>>>  ?? +#define PFN_PTE_SHIFT????????? PAGE_SHIFT
>>>>> +
>>>>>  ?? /*
>>>>>  ??? * Huge pte definitions.
>>>>>  ??? */
>>>>>
>>>>>
>>>>> As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit
>>>>> case. But that won't affect this.
>>>>>
>>>>>
>>>>> With VM_DEBUG on, this is the first warning I see during boot:
>>>>>
>>>>>
>>>>> [??? 0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0
>>>>> mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
>>>>> [??? 0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0
>>>>> nr_pages_mapped:2 pincount:0
>>>>
>>>> ^ Ah, you are running with mTHP. Let me play with that.
>>>
>>> Err... Its in mm-unstable, but I'm not enabling any sizes. It should only be set
>>> up for PMD-sized THP.
>>>
>>> I am using XFS though, so I imagine its a file folio.
>>>
>>> I've rebased your rmap cleanup and fork batching to the version of mm-unstable
>>> that I was doing all my other testing with so I could compare numbers. But its
>>> not very old (perhaps a week). All the patches applied without any conflict.
>>
>>
>> It would also be interesting to know if the compiler on arm64 decides to do
>> something stupid: like not inline wrprotect_ptes().
>>
>> Because with an effective unlikely(folio_test_large(folio)) we shouldn't see
>> that much overhead.
>>
> 
> What version of gcc are you using? I must confess I'm using the Ubuntu 20.04
> default version:
> 
> aarch64-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
> 
> Perhaps I should grab something a bit newer?
> 

gcc version 13.2.1 20231011 (Red Hat 13.2.1-4) (GCC)

 From Fedora 38. So "a bit" newer :P

-- 
Cheers,

David / dhildenb



From angelogioacchino.delregno at collabora.com  Wed Dec 20 05:13:51 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 14:13:51 +0100
Subject: [PATCH v3 2/3] soc: mediatek: mtk-socinfo: Add driver for getting
 chip information
In-Reply-To: <97d54894-7c71-49d8-a456-869c398636ec@linaro.org>
References: <20231220103901.22180-1-william-tw.lin@mediatek.com>
 <20231220103901.22180-3-william-tw.lin@mediatek.com>
 <97d54894-7c71-49d8-a456-869c398636ec@linaro.org>
Message-ID: <479fa717-8de7-4f1b-b02c-2cfbd49f71cc@collabora.com>

Il 20/12/23 12:34, Krzysztof Kozlowski ha scritto:
> On 20/12/2023 11:39, William-tw Lin wrote:
>> Add driver for socinfo retrieval. This patch includes the following:
>> 1. mtk-socinfo driver for chip info retrieval
>> 2. Related changes to Makefile and Kconfig
>>
>> Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
> 
> ...
> 
>> +static struct platform_driver mtk_socinfo = {
>> +	.probe = mtk_socinfo_probe,
>> +	.remove_new = mtk_socinfo_remove,
>> +	.driver = {
>> +		.name = "mtk-socinfo",
>> +	},
>> +};
>> +builtin_platform_driver(mtk_socinfo);
> 
> module platform driver, because this is tristate and because this should
> be a module.
> 

Oh! Yes, right! Thanks for catching that, it totally slipped off my brain.

Cheers,
Angelo




From michal.simek at amd.com  Wed Dec 20 05:14:37 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 14:14:37 +0100
Subject: [PATCH v8 2/3] dts: zynqmp: add properties for TCM in remoteproc
In-Reply-To: <20231215235725.1247350-3-tanmay.shah@amd.com>
References: <20231215235725.1247350-1-tanmay.shah@amd.com>
 <20231215235725.1247350-3-tanmay.shah@amd.com>
Message-ID: <6ab19ceb-38ed-4e4c-aabc-a959bc123cf2@amd.com>



On 12/16/23 00:57, Tanmay Shah wrote:
> Add properties as per new bindings in zynqmp remoteproc node
> to represent TCM address and size.
> 
> This patch also adds alternative remoteproc node to represent
> remoteproc cluster in split mode. By default lockstep mode is
> enabled and users should disable it before using split mode
> dts. Both device-tree nodes can't be used simultaneously one
> of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
> remoteproc split mode dts node is enabled and lockstep mode
> dts is disabled.
> 
> Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> ---
>   .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |  8 +++
>   arch/arm64/boot/dts/xilinx/zynqmp.dtsi        | 60 +++++++++++++++++--
>   2 files changed, 63 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
> index c8f71a1aec89..495ca94b45db 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
> @@ -14,6 +14,14 @@ / {
>   	compatible = "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102", "xlnx,zynqmp";
>   };
>   
> +&rproc_split {
> +	status = "okay";
> +};
> +
> +&rproc_lockstep {
> +	status = "disabled";
> +};
> +
>   &eeprom {
>   	#address-cells = <1>;
>   	#size-cells = <1>;
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index b61fc99cd911..602e6aba7ac5 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -247,19 +247,69 @@ fpga_full: fpga-full {
>   		ranges;
>   	};
>   
> -	remoteproc {
> +	rproc_lockstep: remoteproc at ffe00000 {
>   		compatible = "xlnx,zynqmp-r5fss";
>   		xlnx,cluster-mode = <1>;
>   
> -		r5f-0 {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +
> +		ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x20000>,
> +			 <0x0 0x20000 0x0 0xffe20000 0x0 0x20000>,
> +			 <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
> +			 <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
> +
> +		r5f at 0 {
> +			compatible = "xlnx,zynqmp-r5f";
> +			reg = <0x0 0x0 0x0 0x20000>, <0x0 0x20000 0x0 0x20000>;
> +			reg-names = "atcm", "btcm";
> +			power-domains = <&zynqmp_firmware PD_RPU_0>,
> +					<&zynqmp_firmware PD_R5_0_ATCM>,
> +					<&zynqmp_firmware PD_R5_0_BTCM>;
> +			memory-region = <&rproc_0_fw_image>;
> +		};
> +
> +		r5f at 1 {
> +			compatible = "xlnx,zynqmp-r5f";
> +			reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
> +			reg-names = "atcm", "btcm";
> +			power-domains = <&zynqmp_firmware PD_RPU_1>,
> +					<&zynqmp_firmware PD_R5_1_ATCM>,
> +					<&zynqmp_firmware PD_R5_1_BTCM>;
> +			memory-region = <&rproc_1_fw_image>;
> +		};
> +	};
> +
> +	rproc_split: remoteproc-split at ffe00000 {
> +		status = "disabled";
> +		compatible = "xlnx,zynqmp-r5fss";
> +		xlnx,cluster-mode = <0>;
> +
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +
> +		ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
> +			 <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
> +			 <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
> +			 <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
> +
> +		r5f at 0 {
>   			compatible = "xlnx,zynqmp-r5f";
> -			power-domains = <&zynqmp_firmware PD_RPU_0>;
> +			reg = <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0x0 0x10000>;
> +			reg-names = "atcm", "btcm";
> +			power-domains = <&zynqmp_firmware PD_RPU_0>,
> +					<&zynqmp_firmware PD_R5_0_ATCM>,
> +					<&zynqmp_firmware PD_R5_0_BTCM>;
>   			memory-region = <&rproc_0_fw_image>;
>   		};
>   
> -		r5f-1 {
> +		r5f at 1 {
>   			compatible = "xlnx,zynqmp-r5f";
> -			power-domains = <&zynqmp_firmware PD_RPU_1>;
> +			reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
> +			reg-names = "atcm", "btcm";
> +			power-domains = <&zynqmp_firmware PD_RPU_1>,
> +					<&zynqmp_firmware PD_R5_1_ATCM>,
> +					<&zynqmp_firmware PD_R5_1_BTCM>;
>   			memory-region = <&rproc_1_fw_image>;
>   		};
>   	};

Acked-by: Michal Simek <michal.simek at amd.com>

Let me know if you want me to take this via my tree.

Thanks,
Michal


From arnd at arndb.de  Wed Dec 20 05:21:17 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 20 Dec 2023 13:21:17 +0000
Subject: [GIT PULL] ARM: SoC fixes for 6.7, part 2
Message-ID: <10ff8b28-3892-4920-b4a0-4612fe814f6d@app.fastmail.com>

The following changes since commit a39b6ac3781d46ba18193c9dbb2110f31e9bffe9:

  Linux 6.7-rc5 (2023-12-10 14:33:40 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-fixes-6.7-2

for you to fetch changes up to fa3d6c7183106a187a8d399216db3f088a6aab81:

  arm64: dts: mediatek: mt8395-genio-1200-evk: add interrupt-parent for mt6360 (2023-12-20 13:05:43 +0000)

----------------------------------------------------------------
ARM: SoC fixes for 6.7, part 2

There are only a handful of bugfixes this time, which feels almost too
small, so I hope we are not missing something important.

 - One more mediatek dts warning fix after the previous larger set,
   this should finally result in a clean defconfig build.

 - TI OMAP dts fixes for a spurious hang on am335x and invalid data on DTA7

 - One DTS fix for ethernet on Oriange Pi Zero (Allwinner H616)

 - A regression fix for ti-sysc interconnect target module driver to
   not access registers after reset if srst_udelay quirk is needed

 - Reset controller driver fixes for a crash during error handling and
   a build warning

----------------------------------------------------------------
Andrew Davis (1):
      ARM: dts: dra7: Fix DRA7 L3 NoC node register size

Arnd Bergmann (4):
      Merge tag 'sunxi-fixes-for-6.7-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes
      Merge tag 'reset-fixes-for-v6.7' of git://git.pengutronix.de/pza/linux into arm/fixes
      Merge tag 'omap-for-v6.7/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes
      Merge tag 'am3-usb-hang-fix-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes

Chukun Pan (1):
      arm64: dts: allwinner: h616: update emac for Orange Pi Zero 3

Geert Uytterhoeven (1):
      reset: Fix crash when freeing non-existent optional resets

Krzysztof Kozlowski (1):
      reset: hisilicon: hi6220: fix Wvoid-pointer-to-enum-cast warning

Kunwu Chan (1):
      ARM: OMAP2+: Fix null pointer dereference and memory leak in omap_soc_device_init

Macpaul Lin (1):
      arm64: dts: mediatek: mt8395-genio-1200-evk: add interrupt-parent for mt6360

Tony Lindgren (2):
      bus: ti-sysc: Flush posted write only after srst_udelay
      ARM: dts: Fix occasional boot hang for am3 usb

 arch/arm/boot/dts/ti/omap/am33xx.dtsi                  |  1 +
 arch/arm/boot/dts/ti/omap/dra7.dtsi                    |  2 +-
 arch/arm/mach-omap2/id.c                               |  5 +++++
 .../boot/dts/allwinner/sun50i-h616-orangepi-zero.dtsi  |  3 ---
 .../boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts  |  3 +++
 .../boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts  |  2 ++
 arch/arm64/boot/dts/mediatek/mt8395-genio-1200-evk.dts |  1 +
 drivers/bus/ti-sysc.c                                  | 18 ++++++++++++++----
 drivers/reset/core.c                                   |  8 ++++----
 drivers/reset/hisilicon/hi6220_reset.c                 |  2 +-
 10 files changed, 32 insertions(+), 13 deletions(-)


From michal.simek at amd.com  Wed Dec 20 05:23:38 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 14:23:38 +0100
Subject: [PATCH 2/3] mailbox: zynqmp: Move buffered IPI setup to of_match
 selected routine
In-Reply-To: <20231214211354.348294-3-ben.levinsky@amd.com>
References: <20231214211354.348294-1-ben.levinsky@amd.com>
 <20231214211354.348294-3-ben.levinsky@amd.com>
Message-ID: <c7ea6fd6-b4cd-45e5-b1b0-12c8e2aa8696@amd.com>



On 12/14/23 22:13, Ben Levinsky wrote:
> Move routine that initializes the mailboxes for send and receive to
> a function pointer that is set based on compatible string.
> 
> Signed-off-by: Ben Levinsky <ben.levinsky at amd.com>
> ---
>   drivers/mailbox/zynqmp-ipi-mailbox.c | 124 +++++++++++++++++++--------
>   1 file changed, 89 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
> index 2c10aa01b3bb..edefb80a6e47 100644
> --- a/drivers/mailbox/zynqmp-ipi-mailbox.c
> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
> @@ -72,6 +72,10 @@ struct zynqmp_ipi_mchan {
>   	unsigned int chan_type;
>   };
>   
> +struct zynqmp_ipi_mbox;
> +
> +typedef int (*setup_ipi_fn)(struct zynqmp_ipi_mbox *ipi_mbox, struct device_node *node);
> +
>   /**
>    * struct zynqmp_ipi_mbox - Description of a ZynqMP IPI mailbox
>    *                          platform data.
> @@ -82,6 +86,7 @@ struct zynqmp_ipi_mchan {
>    * @mbox:                 mailbox Controller
>    * @mchans:               array for channels, tx channel and rx channel.
>    * @irq:                  IPI agent interrupt ID
> + * setup_ipi_fn:          Function Pointer to set up IPI Channels

Here should be @setup_ipi_fn.

>    */
>   struct zynqmp_ipi_mbox {
>   	struct zynqmp_ipi_pdata *pdata;
> @@ -89,6 +94,7 @@ struct zynqmp_ipi_mbox {
>   	u32 remote_id;
>   	struct mbox_controller mbox;
>   	struct zynqmp_ipi_mchan mchans[2];
> +	setup_ipi_fn setup_ipi_fn;
>   };
>   
>   /**
> @@ -466,12 +472,9 @@ static void zynqmp_ipi_mbox_dev_release(struct device *dev)
>   static int zynqmp_ipi_mbox_probe(struct zynqmp_ipi_mbox *ipi_mbox,
>   				 struct device_node *node)
>   {
> -	struct zynqmp_ipi_mchan *mchan;
>   	struct mbox_chan *chans;
>   	struct mbox_controller *mbox;
> -	struct resource res;
>   	struct device *dev, *mdev;
> -	const char *name;
>   	int ret;
>   
>   	dev = ipi_mbox->pdata->dev;
> @@ -491,6 +494,75 @@ static int zynqmp_ipi_mbox_probe(struct zynqmp_ipi_mbox *ipi_mbox,
>   	}
>   	mdev = &ipi_mbox->dev;
>   
> +	/* Get the IPI remote agent ID */
> +	ret = of_property_read_u32(node, "xlnx,ipi-id", &ipi_mbox->remote_id);
> +	if (ret < 0) {
> +		dev_err(dev, "No IPI remote ID is specified.\n");
> +		return ret;
> +	}
> +
> +	ret = ipi_mbox->setup_ipi_fn(ipi_mbox, node);
> +	if (ret) {
> +		dev_err(dev, "Failed to set up IPI Buffers.\n");
> +		return ret;
> +	}
> +
> +	mbox = &ipi_mbox->mbox;
> +	mbox->dev = mdev;
> +	mbox->ops = &zynqmp_ipi_chan_ops;
> +	mbox->num_chans = 2;
> +	mbox->txdone_irq = false;
> +	mbox->txdone_poll = true;
> +	mbox->txpoll_period = 5;
> +	mbox->of_xlate = zynqmp_ipi_of_xlate;
> +	chans = devm_kzalloc(mdev, 2 * sizeof(*chans), GFP_KERNEL);
> +	if (!chans)
> +		return -ENOMEM;
> +	mbox->chans = chans;
> +	chans[IPI_MB_CHNL_TX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
> +	chans[IPI_MB_CHNL_RX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_RX];
> +	ipi_mbox->mchans[IPI_MB_CHNL_TX].chan_type = IPI_MB_CHNL_TX;
> +	ipi_mbox->mchans[IPI_MB_CHNL_RX].chan_type = IPI_MB_CHNL_RX;
> +	ret = devm_mbox_controller_register(mdev, mbox);
> +	if (ret)
> +		dev_err(mdev,
> +			"Failed to register mbox_controller(%d)\n", ret);
> +	else
> +		dev_info(mdev,
> +			 "Registered ZynqMP IPI mbox with TX/RX channels.\n");
> +	return ret;
> +}
> +
> +/**
> + * zynqmp_ipi_setup - set up IPI Buffers for classic flow
> + *
> + * @ipi_mbox: pointer to IPI mailbox private data structure
> + * @node: IPI mailbox device node
> + *
> + * This will be used to set up IPI Buffers for ZynqMP SOC if user
> + * wishes to use classic driver usage model on new SOC's with only
> + * buffered IPIs.
> + *
> + * Note that bufferless IPIs and mixed usage of buffered and bufferless
> + * IPIs are not supported with this flow.
> + *
> + * This will be invoked with compatible string "xlnx,zynqmp-ipi-mailbox".
> + *
> + * Return: 0 for success, negative value for failure
> + */
> +static int zynqmp_ipi_setup(struct zynqmp_ipi_mbox *ipi_mbox,
> +			    struct device_node *node)
> +{
> +	struct zynqmp_ipi_mchan *mchan;
> +	struct device *mdev;
> +	struct resource res;
> +	struct device *dev;

nit: you can put it to the same line mdev, dev.

> +	const char *name;
> +	int ret;
> +
> +	mdev = &ipi_mbox->dev;
> +	dev = ipi_mbox->pdata->dev;
> +
>   	mchan = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
>   	name = "local_request_region";
>   	ret = zynqmp_ipi_mbox_get_buf_res(node, name, &res);
> @@ -565,37 +637,7 @@ static int zynqmp_ipi_mbox_probe(struct zynqmp_ipi_mbox *ipi_mbox,
>   	if (!mchan->rx_buf)
>   		return -ENOMEM;
>   
> -	/* Get the IPI remote agent ID */
> -	ret = of_property_read_u32(node, "xlnx,ipi-id", &ipi_mbox->remote_id);
> -	if (ret < 0) {
> -		dev_err(dev, "No IPI remote ID is specified.\n");
> -		return ret;
> -	}
> -
> -	mbox = &ipi_mbox->mbox;
> -	mbox->dev = mdev;
> -	mbox->ops = &zynqmp_ipi_chan_ops;
> -	mbox->num_chans = 2;
> -	mbox->txdone_irq = false;
> -	mbox->txdone_poll = true;
> -	mbox->txpoll_period = 5;
> -	mbox->of_xlate = zynqmp_ipi_of_xlate;
> -	chans = devm_kzalloc(mdev, 2 * sizeof(*chans), GFP_KERNEL);
> -	if (!chans)
> -		return -ENOMEM;
> -	mbox->chans = chans;
> -	chans[IPI_MB_CHNL_TX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
> -	chans[IPI_MB_CHNL_RX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_RX];
> -	ipi_mbox->mchans[IPI_MB_CHNL_TX].chan_type = IPI_MB_CHNL_TX;
> -	ipi_mbox->mchans[IPI_MB_CHNL_RX].chan_type = IPI_MB_CHNL_RX;
> -	ret = devm_mbox_controller_register(mdev, mbox);
> -	if (ret)
> -		dev_err(mdev,
> -			"Failed to register mbox_controller(%d)\n", ret);
> -	else
> -		dev_info(mdev,
> -			 "Registered ZynqMP IPI mbox with TX/RX channels.\n");
> -	return ret;
> +	return 0;
>   }
>   
>   /**
> @@ -626,6 +668,7 @@ static int zynqmp_ipi_probe(struct platform_device *pdev)
>   	struct zynqmp_ipi_pdata *pdata;
>   	struct zynqmp_ipi_mbox *mbox;
>   	int num_mboxes, ret = -EINVAL;
> +	setup_ipi_fn ipi_fn;
>   
>   	num_mboxes = of_get_available_child_count(np);
>   	if (num_mboxes == 0) {
> @@ -646,9 +689,18 @@ static int zynqmp_ipi_probe(struct platform_device *pdev)
>   		return ret;
>   	}
>   
> +	ipi_fn = (setup_ipi_fn)device_get_match_data(&pdev->dev);
> +	if (!ipi_fn) {
> +		dev_err(dev,
> +			"Mbox Compatible String is missing IPI Setup fn.\n");
> +		return -ENODEV;
> +	}
> +
>   	pdata->num_mboxes = num_mboxes;
>   
>   	mbox = pdata->ipi_mboxes;
> +	mbox->setup_ipi_fn = ipi_fn;
> +
>   	for_each_available_child_of_node(np, nc) {
>   		mbox->pdata = pdata;
>   		ret = zynqmp_ipi_mbox_probe(mbox, nc);
> @@ -694,7 +746,9 @@ static int zynqmp_ipi_remove(struct platform_device *pdev)
>   }
>   
>   static const struct of_device_id zynqmp_ipi_of_match[] = {
> -	{ .compatible = "xlnx,zynqmp-ipi-mailbox" },
> +	{ .compatible = "xlnx,zynqmp-ipi-mailbox",
> +	  .data = &zynqmp_ipi_setup,
> +	},
>   	{},
>   };
>   MODULE_DEVICE_TABLE(of, zynqmp_ipi_of_match);


M


From michal.simek at amd.com  Wed Dec 20 05:29:25 2023
From: michal.simek at amd.com (Michal Simek)
Date: Wed, 20 Dec 2023 14:29:25 +0100
Subject: [PATCH 3/3] mailbox: zynqmp: Enable Bufferless IPI usage on
 Versal-based SOC's
In-Reply-To: <20231214211354.348294-4-ben.levinsky@amd.com>
References: <20231214211354.348294-1-ben.levinsky@amd.com>
 <20231214211354.348294-4-ben.levinsky@amd.com>
Message-ID: <ea76da63-4758-400f-a5ed-9cb223b65c80@amd.com>



On 12/14/23 22:13, Ben Levinsky wrote:
> On Xilinx-AMD Versal and Versal-NET, there exist both
> inter-processor-interrupts with corresponding message buffers and without
> such buffers.
> 
> Add a routine that, if the corresponding DT compatible
> string "xlnx,versal-ipi-mailbox" is used then a Versal-based SOC
> can use a mailbox Device Tree entry where both host and remote
> can use either of the buffered or bufferless interrupts.
> 
> Signed-off-by: Ben Levinsky <ben.levinsky at amd.com>
> ---
> Note that the linked patch provides corresponding bindings.
> Depends on: https://lore.kernel.org/all/20231214054224.957336-3-tanmay.shah at amd.com/T/
> ---
>   drivers/mailbox/zynqmp-ipi-mailbox.c | 146 +++++++++++++++++++++++++--
>   1 file changed, 139 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
> index edefb80a6e47..316d9406064e 100644
> --- a/drivers/mailbox/zynqmp-ipi-mailbox.c
> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
> @@ -52,6 +52,13 @@
>   #define IPI_MB_CHNL_TX	0 /* IPI mailbox TX channel */
>   #define IPI_MB_CHNL_RX	1 /* IPI mailbox RX channel */
>   
> +/* IPI Message Buffer Information */
> +#define RESP_OFFSET	0x20U
> +#define DEST_OFFSET	0x40U
> +#define IPI_BUF_SIZE	0x20U
> +#define DST_BIT_POS	9U
> +#define SRC_BITMASK	GENMASK(11, 8)
> +
>   /**
>    * struct zynqmp_ipi_mchan - Description of a Xilinx ZynqMP IPI mailbox channel
>    * @is_opened: indicate if the IPI channel is opened
> @@ -170,9 +177,11 @@ static irqreturn_t zynqmp_ipi_interrupt(int irq, void *data)
>   		if (ret > 0 && ret & IPI_MB_STATUS_RECV_PENDING) {
>   			if (mchan->is_opened) {
>   				msg = mchan->rx_buf;
> -				msg->len = mchan->req_buf_size;
> -				memcpy_fromio(msg->data, mchan->req_buf,
> -					      msg->len);
> +				if (msg) {
> +					msg->len = mchan->req_buf_size;
> +					memcpy_fromio(msg->data, mchan->req_buf,
> +						      msg->len);
> +				}
>   				mbox_chan_received_data(chan, (void *)msg);
>   				status = IRQ_HANDLED;
>   			}
> @@ -282,26 +291,26 @@ static int zynqmp_ipi_send_data(struct mbox_chan *chan, void *data)
>   
>   	if (mchan->chan_type == IPI_MB_CHNL_TX) {
>   		/* Send request message */
> -		if (msg && msg->len > mchan->req_buf_size) {
> +		if (msg && msg->len > mchan->req_buf_size && mchan->req_buf) {
>   			dev_err(dev, "channel %d message length %u > max %lu\n",
>   				mchan->chan_type, (unsigned int)msg->len,
>   				mchan->req_buf_size);
>   			return -EINVAL;
>   		}
> -		if (msg && msg->len)
> +		if (msg && msg->len && mchan->req_buf)
>   			memcpy_toio(mchan->req_buf, msg->data, msg->len);
>   		/* Kick IPI mailbox to send message */
>   		arg0 = SMC_IPI_MAILBOX_NOTIFY;
>   		zynqmp_ipi_fw_call(ipi_mbox, arg0, 0, &res);
>   	} else {
>   		/* Send response message */
> -		if (msg && msg->len > mchan->resp_buf_size) {
> +		if (msg && msg->len > mchan->resp_buf_size && mchan->resp_buf) {
>   			dev_err(dev, "channel %d message length %u > max %lu\n",
>   				mchan->chan_type, (unsigned int)msg->len,
>   				mchan->resp_buf_size);
>   			return -EINVAL;
>   		}
> -		if (msg && msg->len)
> +		if (msg && msg->len && mchan->resp_buf)
>   			memcpy_toio(mchan->resp_buf, msg->data, msg->len);
>   		arg0 = SMC_IPI_MAILBOX_ACK;
>   		zynqmp_ipi_fw_call(ipi_mbox, arg0, IPI_SMC_ACK_EIRQ_MASK,
> @@ -640,6 +649,126 @@ static int zynqmp_ipi_setup(struct zynqmp_ipi_mbox *ipi_mbox,
>   	return 0;
>   }
>   
> +/**
> + * versal_ipi_setup - Set up IPIs to support mixed usage of
> + *				 Buffered and Bufferless IPIs.
> + *
> + * @ipi_mbox: pointer to IPI mailbox private data structure
> + * @node: IPI mailbox device node
> + *
> + * Return: 0 for success, negative value for failure
> + */
> +static int versal_ipi_setup(struct zynqmp_ipi_mbox *ipi_mbox,
> +			    struct device_node *node)
> +{
> +	struct zynqmp_ipi_mchan *tx_mchan, *rx_mchan;
> +	struct resource host_res, remote_res;
> +	struct device_node *parent_node;
> +	int host_idx, remote_idx;
> +	struct device *mdev, *dev;
> +
> +	tx_mchan = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
> +	rx_mchan = &ipi_mbox->mchans[IPI_MB_CHNL_RX];
> +	parent_node = of_get_parent(node);
> +	dev = ipi_mbox->pdata->dev;
> +	mdev = &ipi_mbox->dev;
> +
> +	host_idx = zynqmp_ipi_mbox_get_buf_res(parent_node, "msg", &host_res);
> +	remote_idx = zynqmp_ipi_mbox_get_buf_res(node, "msg", &remote_res);
> +
> +	/*
> +	 * Only set up buffers if both sides claim to have msg buffers.
> +	 * This is because each buffered IPI's corresponding msg buffers
> +	 * are reserved for use by other buffered IPI's.
> +	 */
> +	if (!host_idx && !remote_idx) {
> +		u32 host_src, host_dst, remote_src, remote_dst;
> +		u32 buff_sz;
> +
> +		buff_sz = resource_size(&host_res);
> +
> +		host_src = host_res.start & SRC_BITMASK;
> +		remote_src = remote_res.start & SRC_BITMASK;
> +
> +		host_dst = (host_src >> DST_BIT_POS) * DEST_OFFSET;
> +		remote_dst = (remote_src >> DST_BIT_POS) * DEST_OFFSET;
> +
> +		/* Validate that IPI IDs is within IPI Message buffer space. */
> +		if (host_dst >= buff_sz || remote_dst >= buff_sz) {
> +			dev_err(mdev,
> +				"Invalid IPI Message buffer values: %x %x\n",
> +				host_dst, remote_dst);
> +			return -EINVAL;
> +		}
> +
> +		tx_mchan->req_buf = devm_ioremap(mdev,
> +						 host_res.start | remote_dst,
> +						 IPI_BUF_SIZE);
> +		if (!tx_mchan->req_buf) {
> +			dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
> +			return -ENOMEM;
> +		}
> +
> +		tx_mchan->resp_buf = devm_ioremap(mdev,
> +						  (remote_res.start | host_dst) +
> +						  RESP_OFFSET, IPI_BUF_SIZE);
> +		if (!tx_mchan->resp_buf) {
> +			dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
> +			return -ENOMEM;
> +		}
> +
> +		rx_mchan->req_buf = devm_ioremap(mdev,
> +						 remote_res.start | host_dst,
> +						 IPI_BUF_SIZE);
> +		if (!rx_mchan->req_buf) {
> +			dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
> +			return -ENOMEM;
> +		}
> +
> +		rx_mchan->resp_buf = devm_ioremap(mdev,
> +						  (host_res.start | remote_dst) +
> +						  RESP_OFFSET, IPI_BUF_SIZE);
> +		if (!rx_mchan->resp_buf) {
> +			dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
> +			return -ENOMEM;
> +		}
> +
> +		tx_mchan->resp_buf_size = IPI_BUF_SIZE;
> +		tx_mchan->req_buf_size = IPI_BUF_SIZE;
> +		tx_mchan->rx_buf = devm_kzalloc(mdev, IPI_BUF_SIZE +
> +						sizeof(struct zynqmp_ipi_message),
> +						GFP_KERNEL);
> +		if (!tx_mchan->rx_buf)
> +			return -ENOMEM;
> +
> +		rx_mchan->resp_buf_size = IPI_BUF_SIZE;
> +		rx_mchan->req_buf_size = IPI_BUF_SIZE;
> +		rx_mchan->rx_buf = devm_kzalloc(mdev, IPI_BUF_SIZE +
> +						sizeof(struct zynqmp_ipi_message),
> +						GFP_KERNEL);
> +		if (!rx_mchan->rx_buf)
> +			return -ENOMEM;
> +	} else {
> +		/*
> +		 * If here, then set up Bufferless IPI Channel because
> +		 * one or both of the IPI's is bufferless.
> +		 */
> +		tx_mchan->req_buf = NULL;
> +		tx_mchan->resp_buf = NULL;
> +		tx_mchan->rx_buf = NULL;
> +		tx_mchan->resp_buf_size = 0;
> +		tx_mchan->req_buf_size = 0;
> +
> +		rx_mchan->req_buf = NULL;
> +		rx_mchan->resp_buf = NULL;
> +		rx_mchan->rx_buf = NULL;
> +		rx_mchan->resp_buf_size = 0;
> +		rx_mchan->req_buf_size = 0;

Just curious if this is really needed. If none fills that values aren't they 
actually already 0/NULL because that location is cleared by kzalloc.

Thanks,
Michal



From eugen.hristev at collabora.com  Wed Dec 20 05:33:02 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Wed, 20 Dec 2023 15:33:02 +0200
Subject: [PATCH] arm64: dts: mediatek: mt8186: Add video decoder device nodes
Message-ID: <20231220133302.39411-1-eugen.hristev@collabora.com>

From: Yunfei Dong <yunfei.dong at mediatek.com>

Add mt8186 video decoder device nodes.

Signed-off-by: Yunfei Dong <yunfei.dong at mediatek.com>
Signed-off-by: Allen-KH Cheng <allen-kh.cheng at mediatek.com>
Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.org>
[eugen.hristev at collabora.com: minor cleanup]
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---

I based this commit on top of the video encoder patch series.


 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 37 ++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index ebd07bf3d9d2..e451b6c8cd9e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1959,6 +1959,43 @@ larb11: smi at 1582e000 {
 			power-domains = <&spm MT8186_POWER_DOMAIN_IMG2>;
 		};
 
+		video_decoder: video-decoder at 16000000 {
+			compatible = "mediatek,mt8186-vcodec-dec";
+			reg = <0 0x16000000 0 0x1000>;
+			ranges;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>;
+			iommus = <&iommu_mm IOMMU_PORT_L4_HW_VDEC_MC_EXT>;
+			mediatek,scp = <&scp>;
+
+			vcodec_core: video-codec at 16025000 {
+				compatible = "mediatek,mtk-vcodec-core";
+				reg = <0 0x16025000 0 0x1000>;
+				interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH 0>;
+				iommus = <&iommu_mm IOMMU_PORT_L4_HW_VDEC_MC_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_UFO_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_PP_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_PRED_RD_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_PRED_WR_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_PPWRAP_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_TILE_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_VLD_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_VLD2_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_AVC_MV_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_UFO_ENC_EXT>,
+					 <&iommu_mm IOMMU_PORT_L4_HW_VDEC_RG_CTRL_DMA_EXT>;
+				clocks = <&topckgen CLK_TOP_VDEC>,
+					 <&vdecsys CLK_VDEC_CKEN>,
+					 <&vdecsys CLK_VDEC_LARB1_CKEN>,
+					 <&topckgen CLK_TOP_UNIVPLL_D3>;
+				clock-names = "vdec-sel", "vdec-soc-vdec", "vdec", "vdec-top";
+				assigned-clocks = <&topckgen CLK_TOP_VDEC>;
+				assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D3>;
+				power-domains = <&spm MT8186_POWER_DOMAIN_VDEC>;
+			};
+		};
+
 		larb4: smi at 1602e000 {
 			compatible = "mediatek,mt8186-smi-larb";
 			reg = <0 0x1602e000 0 0x1000>;
-- 
2.34.1



From ryan.roberts at arm.com  Wed Dec 20 05:33:01 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 13:33:01 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <c244707c-8c0c-4593-ab45-d8f165dbc5ee@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
 <9f99a3ca-051e-4b1b-81e9-8456d8e422ad@redhat.com>
 <c1913fa2-d313-4f05-a649-da69b6d31d2a@arm.com>
 <c244707c-8c0c-4593-ab45-d8f165dbc5ee@redhat.com>
Message-ID: <ba6a5c11-34fb-40ca-b24a-f51a207464f2@arm.com>

On 20/12/2023 13:13, David Hildenbrand wrote:
> On 20.12.23 14:10, Ryan Roberts wrote:
>> On 20/12/2023 13:06, David Hildenbrand wrote:
>>> On 20.12.23 13:04, Ryan Roberts wrote:
>>>> On 20/12/2023 11:58, David Hildenbrand wrote:
>>>>> On 20.12.23 12:51, Ryan Roberts wrote:
>>>>>> On 20/12/2023 11:36, David Hildenbrand wrote:
>>>>>>> On 20.12.23 12:28, Ryan Roberts wrote:
>>>>>>>> On 20/12/2023 10:56, David Hildenbrand wrote:
>>>>>>>>> On 20.12.23 11:41, Ryan Roberts wrote:
>>>>>>>>>> On 20/12/2023 10:16, David Hildenbrand wrote:
>>>>>>>>>>> On 20.12.23 11:11, Ryan Roberts wrote:
>>>>>>>>>>>> On 20/12/2023 09:54, David Hildenbrand wrote:
>>>>>>>>>>>>> On 20.12.23 10:51, Ryan Roberts wrote:
>>>>>>>>>>>>>> On 20/12/2023 09:17, David Hildenbrand wrote:
>>>>>>>>>>>>>>> On 19.12.23 18:42, Ryan Roberts wrote:
>>>>>>>>>>>>>>>> On 19/12/2023 17:22, David Hildenbrand wrote:
>>>>>>>>>>>>>>>>> On 19.12.23 09:30, Ryan Roberts wrote:
>>>>>>>>>>>>>>>>>> On 18/12/2023 17:47, David Hildenbrand wrote:
>>>>>>>>>>>>>>>>>>> On 18.12.23 11:50, Ryan Roberts wrote:
>>>>>>>>>>>>>>>>>>>> Convert copy_pte_range() to copy a batch of ptes in one go. A
>>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>>> batch is determined by the architecture with the new helper,
>>>>>>>>>>>>>>>>>>>> pte_batch_remaining(), and maps a physically contiguous
>>>>>>>>>>>>>>>>>>>> block of
>>>>>>>>>>>>>>>>>>>> memory,
>>>>>>>>>>>>>>>>>>>> all belonging to the same folio. A pte batch is then
>>>>>>>>>>>>>>>>>>>> write-protected in
>>>>>>>>>>>>>>>>>>>> one go in the parent using the new helper,
>>>>>>>>>>>>>>>>>>>> ptep_set_wrprotects()
>>>>>>>>>>>>>>>>>>>> and is
>>>>>>>>>>>>>>>>>>>> set in one go in the child using the new helper,
>>>>>>>>>>>>>>>>>>>> set_ptes_full().
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The primary motivation for this change is to reduce the number
>>>>>>>>>>>>>>>>>>>> of tlb
>>>>>>>>>>>>>>>>>>>> maintenance operations that the arm64 backend has to perform
>>>>>>>>>>>>>>>>>>>> during
>>>>>>>>>>>>>>>>>>>> fork, as it is about to add transparent support for the
>>>>>>>>>>>>>>>>>>>> "contiguous
>>>>>>>>>>>>>>>>>>>> bit"
>>>>>>>>>>>>>>>>>>>> in its ptes. By write-protecting the parent using the new
>>>>>>>>>>>>>>>>>>>> ptep_set_wrprotects() (note the 's' at the end) function, the
>>>>>>>>>>>>>>>>>>>> backend
>>>>>>>>>>>>>>>>>>>> can avoid having to unfold contig ranges of PTEs, which is
>>>>>>>>>>>>>>>>>>>> expensive,
>>>>>>>>>>>>>>>>>>>> when all ptes in the range are being write-protected.
>>>>>>>>>>>>>>>>>>>> Similarly, by
>>>>>>>>>>>>>>>>>>>> using set_ptes_full() rather than set_pte_at() to set up
>>>>>>>>>>>>>>>>>>>> ptes in
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> child, the backend does not need to fold a contiguous range
>>>>>>>>>>>>>>>>>>>> once
>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>> are all populated - they can be initially populated as a
>>>>>>>>>>>>>>>>>>>> contiguous
>>>>>>>>>>>>>>>>>>>> range in the first place.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This code is very performance sensitive, and a significant
>>>>>>>>>>>>>>>>>>>> amount of
>>>>>>>>>>>>>>>>>>>> effort has been put into not regressing performance for the
>>>>>>>>>>>>>>>>>>>> order-0
>>>>>>>>>>>>>>>>>>>> folio case. By default, pte_batch_remaining() is compile
>>>>>>>>>>>>>>>>>>>> constant 1,
>>>>>>>>>>>>>>>>>>>> which enables the compiler to simplify the extra loops that are
>>>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>>>> for batching and produce code that is equivalent (and equally
>>>>>>>>>>>>>>>>>>>> performant) as the previous implementation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This change addresses the core-mm refactoring only and a
>>>>>>>>>>>>>>>>>>>> separate
>>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>>> will implement pte_batch_remaining(), ptep_set_wrprotects() and
>>>>>>>>>>>>>>>>>>>> set_ptes_full() in the arm64 backend to realize the performance
>>>>>>>>>>>>>>>>>>>> improvement as part of the work to enable contpte mappings.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> To ensure the arm64 is performant once implemented, this
>>>>>>>>>>>>>>>>>>>> change is
>>>>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>>> careful to only call ptep_get() once per pte batch.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The following microbenchmark results demonstate that there
>>>>>>>>>>>>>>>>>>>> is no
>>>>>>>>>>>>>>>>>>>> significant performance change after this patch. Fork is called
>>>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>>>> tight loop in a process with 1G of populated memory and the
>>>>>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> function to execute is measured. 100 iterations per run, 8 runs
>>>>>>>>>>>>>>>>>>>> performed on both Apple M2 (VM) and Ampere Altra (bare metal).
>>>>>>>>>>>>>>>>>>>> Tests
>>>>>>>>>>>>>>>>>>>> performed for case where 1G memory is comprised of order-0
>>>>>>>>>>>>>>>>>>>> folios and
>>>>>>>>>>>>>>>>>>>> case where comprised of pte-mapped order-9 folios. Negative is
>>>>>>>>>>>>>>>>>>>> faster,
>>>>>>>>>>>>>>>>>>>> positive is slower, compared to baseline upon which the
>>>>>>>>>>>>>>>>>>>> series is
>>>>>>>>>>>>>>>>>>>> based:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> | Apple M2 VM?? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.1% |??? 0.0% |??? 1.2% |
>>>>>>>>>>>>>>>>>>>> | after-change? |?? -1.0% |??? 2.0% |?? -0.1% |??? 1.1% |
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> | Ampere Altra? | order-0 (pte-map) | order-9 (pte-map) |
>>>>>>>>>>>>>>>>>>>> | fork????????? |-------------------|-------------------|
>>>>>>>>>>>>>>>>>>>> | microbench??? |??? mean |?? stdev |??? mean |?? stdev |
>>>>>>>>>>>>>>>>>>>> |---------------|---------|---------|---------|---------|
>>>>>>>>>>>>>>>>>>>> | baseline????? |??? 0.0% |??? 1.0% |??? 0.0% |??? 0.1% |
>>>>>>>>>>>>>>>>>>>> | after-change? |?? -0.1% |??? 1.2% |?? -0.1% |??? 0.1% |
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Tested-by: John Hubbard <jhubbard at nvidia.com>
>>>>>>>>>>>>>>>>>>>> Reviewed-by: Alistair Popple <apopple at nvidia.com>
>>>>>>>>>>>>>>>>>>>> Signed-off-by: Ryan Roberts <ryan.roberts at arm.com>
>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>> ?????????? include/linux/pgtable.h | 80
>>>>>>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++
>>>>>>>>>>>>>>>>>>>> ?????????? mm/memory.c???????????? | 92
>>>>>>>>>>>>>>>>>>>> ++++++++++++++++++++++++++---------------
>>>>>>>>>>>>>>>>>>>> ?????????? 2 files changed, 139 insertions(+), 33 deletions(-)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>>>> index af7639c3b0a3..db93fb81465a 100644
>>>>>>>>>>>>>>>>>>>> --- a/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>>>> +++ b/include/linux/pgtable.h
>>>>>>>>>>>>>>>>>>>> @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd)
>>>>>>>>>>>>>>>>>>>> ?????????? #define arch_flush_lazy_mmu_mode()??? do {} while
>>>>>>>>>>>>>>>>>>>> (0)
>>>>>>>>>>>>>>>>>>>> ?????????? #endif
>>>>>>>>>>>>>>>>>>>> ?????????? +#ifndef pte_batch_remaining
>>>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>>>> + * pte_batch_remaining - Number of pages from addr to next
>>>>>>>>>>>>>>>>>>>> batch
>>>>>>>>>>>>>>>>>>>> boundary.
>>>>>>>>>>>>>>>>>>>> + * @pte: Page table entry for the first page.
>>>>>>>>>>>>>>>>>>>> + * @addr: Address of the first page.
>>>>>>>>>>>>>>>>>>>> + * @end: Batch ceiling (e.g. end of vma).
>>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>>> + * Some architectures (arm64) can efficiently modify a
>>>>>>>>>>>>>>>>>>>> contiguous
>>>>>>>>>>>>>>>>>>>> batch of
>>>>>>>>>>>>>>>>>>>> ptes.
>>>>>>>>>>>>>>>>>>>> + * In such cases, this function returns the remaining
>>>>>>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>>>>>>> pages to
>>>>>>>>>>>>>>>>>>>> the end
>>>>>>>>>>>>>>>>>>>> + * of the current batch, as defined by addr. This can be
>>>>>>>>>>>>>>>>>>>> useful
>>>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>>> iterating
>>>>>>>>>>>>>>>>>>>> + * over ptes.
>>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>>> + * May be overridden by the architecture, else batch size is
>>>>>>>>>>>>>>>>>>>> always 1.
>>>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>>>> +static inline unsigned int pte_batch_remaining(pte_t pte,
>>>>>>>>>>>>>>>>>>>> unsigned
>>>>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>>>>> addr,
>>>>>>>>>>>>>>>>>>>> +??????????????????????? unsigned long end)
>>>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>>>> +??? return 1;
>>>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>>>> +#endif
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It's a shame we now lose the optimization for all other
>>>>>>>>>>>>>>>>>>> archtiectures.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Was there no way to have some basic batching mechanism that
>>>>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>>>>> arch
>>>>>>>>>>>>>>>>>>> specifics?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I tried a bunch of things but ultimately the way I've done it
>>>>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>>>> to reduce the order-0 fork regression to 0.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> My original v3 posting was costing 5% extra and even my first
>>>>>>>>>>>>>>>>>> attempt
>>>>>>>>>>>>>>>>>> at an
>>>>>>>>>>>>>>>>>> arch-specific version that didn't resolve to a compile-time
>>>>>>>>>>>>>>>>>> constant 1
>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>> cost an extra 3%.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'd have thought that something very basic would have worked
>>>>>>>>>>>>>>>>>>> like:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> * Check if PTE is the same when setting the PFN to 0.
>>>>>>>>>>>>>>>>>>> * Check that PFN is consecutive
>>>>>>>>>>>>>>>>>>> * Check that all PFNs belong to the same folio
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I haven't tried this exact approach, but I'd be surprised if I
>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> regression under 4% with this. Further along the series I spent a
>>>>>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>>>> having to fiddle with the arm64 implementation; every
>>>>>>>>>>>>>>>>>> conditional and
>>>>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>>>> memory read (even when in cache) was a problem. There is just so
>>>>>>>>>>>>>>>>>> little in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> inner loop that every instruction matters. (At least on Ampere
>>>>>>>>>>>>>>>>>> Altra
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> Apple
>>>>>>>>>>>>>>>>>> M2).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Of course if you're willing to pay that 4-5% for order-0 then the
>>>>>>>>>>>>>>>>>> benefit to
>>>>>>>>>>>>>>>>>> order-9 is around 10% in my measurements. Personally though, I'd
>>>>>>>>>>>>>>>>>> prefer to
>>>>>>>>>>>>>>>>>> play
>>>>>>>>>>>>>>>>>> safe and ensure the common order-0 case doesn't regress, as you
>>>>>>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>>>>> suggested.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I just hacked something up, on top of my beloved rmap
>>>>>>>>>>>>>>>>> cleanup/batching
>>>>>>>>>>>>>>>>> series. I
>>>>>>>>>>>>>>>>> implemented very generic and simple batching for large folios
>>>>>>>>>>>>>>>>> (all PTE
>>>>>>>>>>>>>>>>> bits
>>>>>>>>>>>>>>>>> except the PFN have to match).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Some very quick testing (don't trust each last % ) on Intel(R)
>>>>>>>>>>>>>>>>> Xeon(R)
>>>>>>>>>>>>>>>>> Silver
>>>>>>>>>>>>>>>>> 4210R CPU.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> order-0: 0.014210 -> 0.013969
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -> Around 1.7 % faster
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> order-9: 0.014373 -> 0.009149
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -> Around 36.3 % faster
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Well I guess that shows me :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'll do a review and run the tests on my HW to see if it concurs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I pushed a simple compile fixup (we need pte_next_pfn()).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've just been trying to compile and noticed this. Will take a
>>>>>>>>>>>>>> look at
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>> update.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But upon review, I've noticed the part that I think makes this
>>>>>>>>>>>>>> difficult
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> arm64 with the contpte optimization; You are calling ptep_get() for
>>>>>>>>>>>>>> every
>>>>>>>>>>>>>> pte in
>>>>>>>>>>>>>> the batch. While this is functionally correct, once arm64 has the
>>>>>>>>>>>>>> contpte
>>>>>>>>>>>>>> changes, its ptep_get() has to read every pte in the contpte block in
>>>>>>>>>>>>>> order to
>>>>>>>>>>>>>> gather the access and dirty bits. So if your batching function
>>>>>>>>>>>>>> ends up
>>>>>>>>>>>>>> wealking
>>>>>>>>>>>>>> a 16 entry contpte block, that will cause 16 x 16 reads, which kills
>>>>>>>>>>>>>> performance. That's why I added the arch-specific
>>>>>>>>>>>>>> pte_batch_remaining()
>>>>>>>>>>>>>> function; this allows the core-mm to skip to the end of the contpte
>>>>>>>>>>>>>> block and
>>>>>>>>>>>>>> avoid ptep_get() for the 15 tail ptes. So we end up with 16
>>>>>>>>>>>>>> READ_ONCE()s
>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>> of 256.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I considered making a ptep_get_noyoungdirty() variant, which would
>>>>>>>>>>>>>> avoid
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> bit
>>>>>>>>>>>>>> gathering. But we have a similar problem in zap_pte_range() and that
>>>>>>>>>>>>>> function
>>>>>>>>>>>>>> needs the dirty bit to update the folio. So it doesn't work there.
>>>>>>>>>>>>>> (see
>>>>>>>>>>>>>> patch 3
>>>>>>>>>>>>>> in my series).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I guess you are going to say that we should combine both
>>>>>>>>>>>>>> approaches, so
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> your batching loop can skip forward an arch-provided number of ptes?
>>>>>>>>>>>>>> That
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>> certainly work, but feels like an orthogonal change to what I'm
>>>>>>>>>>>>>> trying to
>>>>>>>>>>>>>> achieve :). Anyway, I'll spend some time playing with it today.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can overwrite the function or add special-casing internally, yes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right now, your patch is called "mm: Batch-copy PTE ranges during
>>>>>>>>>>>>> fork()"
>>>>>>>>>>>>> and it
>>>>>>>>>>>>> doesn't do any of that besides preparing for some arm64 work.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Well it allows an arch to opt-in to batching. But I see your point.
>>>>>>>>>>>>
>>>>>>>>>>>> How do you want to handle your patches? Do you want to clean them up
>>>>>>>>>>>> and
>>>>>>>>>>>> I'll
>>>>>>>>>>>> base my stuff on top? Or do you want me to take them and sort it all
>>>>>>>>>>>> out?
>>>>>>>>>>>
>>>>>>>>>>> Whatever you prefer, it was mostly a quick prototype to see if we can
>>>>>>>>>>> achieve
>>>>>>>>>>> decent performance.
>>>>>>>>>>
>>>>>>>>>> I'm about to run it on Altra and M2. But I assume it will show similar
>>>>>>>>>> results.
>>>>>>>>
>>>>>>>> OK results in, not looking great, which aligns with my previous experience.
>>>>>>>> That
>>>>>>>> said, I'm seeing some "BUG: Bad page state in process gmain? pfn:12a094" so
>>>>>>>> perhaps these results are not valid...
>>>>>>>
>>>>>>> I didn't see that so far on x86, maybe related to the PFN fixup?
>>>>>>
>>>>>> All I've done is define PFN_PTE_SHIFT for arm64 on top of your latest patch:
>>>>>>
>>>>>> diff --git a/arch/arm64/include/asm/pgtable.h
>>>>>> b/arch/arm64/include/asm/pgtable.h
>>>>>> index b19a8aee684c..9eb0fd693df9 100644
>>>>>> --- a/arch/arm64/include/asm/pgtable.h
>>>>>> +++ b/arch/arm64/include/asm/pgtable.h
>>>>>> @@ -359,6 +359,8 @@ static inline void set_ptes(struct mm_struct *mm,
>>>>>> ??? }
>>>>>> ??? #define set_ptes set_ptes
>>>>>> ??? +#define PFN_PTE_SHIFT????????? PAGE_SHIFT
>>>>>> +
>>>>>> ??? /*
>>>>>> ???? * Huge pte definitions.
>>>>>> ???? */
>>>>>>
>>>>>>
>>>>>> As an aside, I think there is a bug in arm64's set_ptes() for PA > 48-bit
>>>>>> case. But that won't affect this.
>>>>>>
>>>>>>
>>>>>> With VM_DEBUG on, this is the first warning I see during boot:
>>>>>>
>>>>>>
>>>>>> [??? 0.278110] page:00000000c7ced4e8 refcount:12 mapcount:0
>>>>>> mapping:00000000b2f9739b index:0x1a8 pfn:0x1bff30
>>>>>> [??? 0.278742] head:00000000c7ced4e8 order:2 entire_mapcount:0
>>>>>> nr_pages_mapped:2 pincount:0
>>>>>
>>>>> ^ Ah, you are running with mTHP. Let me play with that.
>>>>
>>>> Err... Its in mm-unstable, but I'm not enabling any sizes. It should only be
>>>> set
>>>> up for PMD-sized THP.
>>>>
>>>> I am using XFS though, so I imagine its a file folio.
>>>>
>>>> I've rebased your rmap cleanup and fork batching to the version of mm-unstable
>>>> that I was doing all my other testing with so I could compare numbers. But its
>>>> not very old (perhaps a week). All the patches applied without any conflict.
>>>
>>>
>>> It would also be interesting to know if the compiler on arm64 decides to do
>>> something stupid: like not inline wrprotect_ptes().
>>>
>>> Because with an effective unlikely(folio_test_large(folio)) we shouldn't see
>>> that much overhead.
>>>
>>
>> What version of gcc are you using? I must confess I'm using the Ubuntu 20.04
>> default version:
>>
>> aarch64-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
>>
>> Perhaps I should grab something a bit newer?
>>
> 
> gcc version 13.2.1 20231011 (Red Hat 13.2.1-4) (GCC)
> 
> From Fedora 38. So "a bit" newer :P
> 

I'll retry with newer toolchain.

FWIW, with the code fix and the original compiler:

Fork, order-0, Apple M2:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      0.8% |
| hugetlb-rmap-cleanups |       1.3% |      2.0% |
| fork-batching         |       4.3% |      1.0% |

Fork, order-9, Apple M2:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      0.8% |
| hugetlb-rmap-cleanups |       0.9% |      0.9% |
| fork-batching         |     -37.3% |      1.0% |

Fork, order-0, Ampere Altra:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      0.7% |
| hugetlb-rmap-cleanups |       3.2% |      0.7% |
| fork-batching         |       5.5% |      1.1% |

Fork, order-9, Ampere Altra:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      0.1% |
| hugetlb-rmap-cleanups |       0.5% |      0.1% |
| fork-batching         |     -10.4% |      0.1% |



From sunnanyong at huawei.com  Wed Dec 20 05:37:52 2023
From: sunnanyong at huawei.com (Nanyong Sun)
Date: Wed, 20 Dec 2023 21:37:52 +0800
Subject: [PATCH v2 2/3] arm64: mm: HVO: support BBM of vmemmap pgtable
 safely
In-Reply-To: <08DCC8BB-631C-4F7A-BB0A-494AD2AD3465@linux.dev>
References: <20231220051855.47547-1-sunnanyong@huawei.com>
 <20231220051855.47547-3-sunnanyong@huawei.com>
 <08DCC8BB-631C-4F7A-BB0A-494AD2AD3465@linux.dev>
Message-ID: <8e3b03bc-af43-adaf-5980-82548893a7c5@huawei.com>

On 2023/12/20 14:32, Muchun Song wrote:

>
>> On Dec 20, 2023, at 13:18, Nanyong Sun <sunnanyong at huawei.com> wrote:
>>
>> Implement vmemmap_update_pmd and vmemmap_update_pte on arm64 to do
>> BBM(break-before-make) logic when change the page table of vmemmap
>> address, they will under the init_mm.page_table_lock.
>> If a translation fault of vmemmap address concurrently happened after
>> pte/pmd cleared, vmemmap page fault handler will acquire the
>> init_mm.page_table_lock to wait for vmemmap update to complete,
>> by then the virtual address is valid again, so PF can return and
>> access can continue.
>> In other case, do the traditional kernel fault.
>>
>> Implement vmemmap_flush_tlb_all/range on arm64 with nothing
>> to do because tlb already flushed in every single BBM.
>>
>> Signed-off-by: Nanyong Sun <sunnanyong at huawei.com>
>> ---
>> arch/arm64/include/asm/esr.h |  4 ++
>> arch/arm64/include/asm/mmu.h | 20 +++++++++
>> arch/arm64/mm/fault.c        | 78 ++++++++++++++++++++++++++++++++++--
>> arch/arm64/mm/mmu.c          | 28 +++++++++++++
>> 4 files changed, 127 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
>> index ae35939f395b..1c63256efd25 100644
>> --- a/arch/arm64/include/asm/esr.h
>> +++ b/arch/arm64/include/asm/esr.h
>> @@ -116,6 +116,10 @@
>> #define ESR_ELx_FSC_SERROR (0x11)
>> #define ESR_ELx_FSC_ACCESS (0x08)
>> #define ESR_ELx_FSC_FAULT (0x04)
>> +#define ESR_ELx_FSC_FAULT_L0    (0x04)
>> +#define ESR_ELx_FSC_FAULT_L1    (0x05)
>> +#define ESR_ELx_FSC_FAULT_L2    (0x06)
>> +#define ESR_ELx_FSC_FAULT_L3    (0x07)
>> #define ESR_ELx_FSC_PERM (0x0C)
>> #define ESR_ELx_FSC_SEA_TTW0 (0x14)
>> #define ESR_ELx_FSC_SEA_TTW1 (0x15)
>> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
>> index 2fcf51231d6e..b553bc37c925 100644
>> --- a/arch/arm64/include/asm/mmu.h
>> +++ b/arch/arm64/include/asm/mmu.h
>> @@ -76,5 +76,25 @@ extern bool kaslr_requires_kpti(void);
>> #define INIT_MM_CONTEXT(name) \
>> .pgd = init_pg_dir,
>>
>> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
>> +void vmemmap_update_pmd(unsigned long addr, pmd_t *pmdp, pte_t *ptep);
>> +#define vmemmap_update_pmd vmemmap_update_pmd
>> +void vmemmap_update_pte(unsigned long addr, pte_t *ptep, pte_t pte);
>> +#define vmemmap_update_pte vmemmap_update_pte
>> +
>> +static inline void vmemmap_flush_tlb_all(void)
>> +{
>> + 	/* do nothing, already flushed tlb in every single BBM */
>> +}
>> +#define vmemmap_flush_tlb_all vmemmap_flush_tlb_all
>> +
>> +static inline void vmemmap_flush_tlb_range(unsigned long start,
>> +   unsigned long end)
>> +{
>> + 	/* do nothing, already flushed tlb in every single BBM */
>> +}
>> +#define vmemmap_flush_tlb_range vmemmap_flush_tlb_range
>> +#endif
> I think those declaration related to TLB flushing should be moved
> to arch/arm64/include/asm/tlbflush.h since we do not include
> <asm/mmu.h> explicitly in hugetlb_vmemmap.c and its functionality
> is to flush TLB. Luckily, <asm/tlbflush.h> is included by hugetlb_vmemmap.c.
>
> Additionally, vmemmap_update_pmd/pte helpers should be moved to
> arch/arm64/include/asm/pgtable.h since it is really pgtable related
> operations.
>
> Thanks.

Yes?I will move them in next version.

Thanks for your time.

>
>
>
>
> .


From quic_bibekkum at quicinc.com  Wed Dec 20 05:38:03 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Wed, 20 Dec 2023 19:08:03 +0530
Subject: [PATCH v6 0/5] iommu/arm-smmu: introduction of ACTLR implementation for Qualcomm SoCs
Message-ID: <20231220133808.5654-1-quic_bibekkum@quicinc.com>

This patch series consist of five parts and covers the following:

1. Re-enable context caching for Qualcomm SoCs to retain prefetcher
   settings during reset and runtime suspend.

2. Remove cfg inside qcom_smmu structure and replace it with single
   pointer to qcom_smmu_match_data avoiding replication of multiple
   members from same.

3. Introduce intital set of driver changes to implement ACTLR register
   for custom prefetcher settings in Qualcomm SoCs.

4. Add ACTLR data and implementation operations for SM8550.

5. Add ACTLR data and implementation operations for SC7280.

Changes in v6 from v5:
 - Remove extra Suggested-by tags.
 - Add return check for arm_mmu500_reset in 1/5 as discussed.
Link to v5:
https://lore.kernel.org/all/20231219135947.1623-1-quic_bibekkum at quicinc.com/

Changes in v5 from v4:
 New addition:
 - Modify copyright year in arm-smmu-qcom.h to 2023 from 2022.
 Changes to incorporate suggestions from Dmitry as follows:
 - Modify the defines for prefetch in (foo << bar) format
   as suggested.(FIELD_PREP could not be used in defines
   is not inside any block/function)
 Changes to incorporate suggestions from Konrad as follows:
 - Shift context caching enablement patch as 1/5 instead of 5/5 to
   be picked up as independent patch.
 - Fix the codestyle to orient variables in reverse xmas tree format
   for patch 1/5.
 - Fix variable name in patch 1/5 as suggested.
 Link to v3:
https://lore.kernel.org/all/20231215101827.30549-1-quic_bibekkum at quicinc.com/

Changes in v4 from v3:
 New addition:
 - Remove actlrcfg_size and use NULL end element instead to traverse
   the actlr table, as this would be a cleaner approach by removing
   redundancy of actlrcfg_size.
 - Renaming of actlr set function to arm_smmu_qcom based proprietary
   convention.
 - break from loop once sid is found and ACTLR value is initialized
   in qcom_smmu_set_actlr.
 - Modify the GFX prefetch value separating into 2 sensible defines.
 - Modify comments for prefetch defines as per SMMU-500 TRM.
 Changes to incorporate suggestions from Konrad as follows:
 - Use Reverse-Christmas-tree sorting wherever applicable.
 - Pass arguments directly to arm_smmu_set_actlr instead of creating
   duplicate variables.
 - Use array indexing instead of direct pointer addressed by new
   addition of eliminating actlrcfg_size.
 - Switch the HEX value's case from upper to lower case in SC7280
   actlrcfg table.
 Changes to incorporate suggestions from Dmitry as follows:
 - Separate changes not related to ACTLR support to different commit
   with patch 5/5.
 - Using pointer to struct for arguments in smr_is_subset().
 Changes to incorporate suggestions from Bjorn as follows:
 - fix the commit message for patch 2/5 to properly document the
   value space to avoid confusion.
 Fixed build issues reported by kernel test robot [1] for
 arm64-allyesconfig [2].
 [1]: https://lore.kernel.org/all/202312011750.Pwca3TWE-lkp at intel.com/
 [2]:
https://download.01.org/0day-ci/archive/20231201/202312011750.Pwca3TWE-lkp at intel.com/config
 Link to v3:
https://lore.kernel.org/all/20231127145412.3981-1-quic_bibekkum at quicinc.com/

Changes in v3 from v2:
 New addition:
 - Include patch 3/4 for adding ACTLR support and data for SC7280.
 - Add driver changes for actlr support in gpu smmu.
 - Add target wise actlr data and implementation ops for gpu smmu.
 Changes to incorporate suggestions from Robin as follows:
 - Match the ACTLR values with individual corresponding SID instead
   of assuming that any SMR will be programmed to match a superset of
   the data.
 - Instead of replicating each elements from qcom_smmu_match_data to
   qcom_smmu structre during smmu device creation, replace the
   replicated members with qcom_smmu_match_data structure inside
   qcom_smmu structre and handle the dereference in places that
   requires them.
 Changes to incorporate suggestions from Dmitry and Konrad as follows:
 - Maintain actlr table inside a single structure instead of
   nested structure.
 - Rename prefetch defines to more appropriately describe their
   behavior.
 - Remove SM8550 specific implementation ops and roll back to default
   qcom_smmu_500_impl implementation ops.
 - Add back the removed comments which are NAK.
 - Fix commit description for patch 4/4.
 Link to v2:
https://lore.kernel.org/all/20231114135654.30475-1-quic_bibekkum at quicinc.com/

Changes in v2 from v1:
 - Incorporated suggestions on v1 from Dmitry,Konrad,Pratyush.
 - Added defines for ACTLR values.
 - Linked sm8550 implementation structure to corresponding
   compatible string.
 - Repackaged actlr value set implementation to separate function.
 - Fixed indentation errors.
 - Link to v1:
https://lore.kernel.org/all/20231103215124.1095-1-quic_bibekkum at quicinc.com/

Changes in v1 from RFC:
 - Incorporated suggestion form Robin on RFC
 - Moved the actlr data table into driver, instead of maintaining
   it inside soc specific DT and piggybacking on exisiting iommus
   property (iommu = <SID, MASK, ACTLR>) to set this value during
   smmu probe.
 - Link to RFC:
https://lore.kernel.org/all/a01e7e60-6ead-4a9e-ba90-22a8a6bbd03f at quicinc.com/

Bibek Kumar Patro (5):
  iommu/arm-smmu: re-enable context caching in smmu reset operation
  iommu/arm-smmu: refactor qcom_smmu structure to include single pointer
  iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings
  iommu/arm-smmu: add ACTLR data and support for SM8550
  iommu/arm-smmu: add ACTLR data and support for SC7280

 .../iommu/arm/arm-smmu/arm-smmu-qcom-debug.c  |   2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c    | 189 +++++++++++++++++-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h    |   8 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.c         |   5 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.h         |   5 +
 5 files changed, 199 insertions(+), 10 deletions(-)

--
2.17.1



From quic_bibekkum at quicinc.com  Wed Dec 20 05:38:04 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Wed, 20 Dec 2023 19:08:04 +0530
Subject: [PATCH v6 1/5] iommu/arm-smmu: re-enable context caching in smmu reset operation
In-Reply-To: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
Message-ID: <20231220133808.5654-2-quic_bibekkum@quicinc.com>

Default MMU-500 reset operation disables context caching in
prefetch buffer. It is however expected for context banks using
the ACTLR register to retain their prefetch value during reset
and runtime suspend.

Replace default MMU-500 reset operation with Qualcomm specific reset
operation which envelope the default reset operation and re-enables
context caching in prefetch buffer for Qualcomm SoCs.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 37 ++++++++++++++++++++--
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 549ae4dba3a6..000e207346af 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -14,6 +14,16 @@

 #define QCOM_DUMMY_VAL	-1

+/*
+ * SMMU-500 TRM defines BIT(0) as CMTLB (Enable context caching in the
+ * macro TLB) and BIT(1) as CPRE (Enable context caching in the prefetch
+ * buffer). The remaining bits are implementation defined and vary across
+ * SoCs.
+ */
+
+#define CPRE			(1 << 1)
+#define CMTLB			(1 << 0)
+
 static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
 {
 	return container_of(smmu, struct qcom_smmu, smmu);
@@ -376,11 +386,32 @@ static int qcom_smmu_def_domain_type(struct device *dev)
 	return match ? IOMMU_DOMAIN_IDENTITY : 0;
 }

+static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
+{
+	int ret;
+	u32 val;
+	int i;
+
+	ret = arm_mmu500_reset(smmu);
+
+	if (ret)
+		return ret;
+
+	/* arm_mmu500_reset() disables CPRE which is re-enabled here */
+	for (i = 0; i < smmu->num_context_banks; ++i) {
+		val = arm_smmu_cb_read(smmu, i, ARM_SMMU_CB_ACTLR);
+		val |= CPRE;
+		arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_ACTLR, val);
+	}
+
+	return 0;
+}
+
 static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
 {
 	int ret;

-	arm_mmu500_reset(smmu);
+	qcom_smmu500_reset(smmu);

 	/*
 	 * To address performance degradation in non-real time clients,
@@ -407,7 +438,7 @@ static const struct arm_smmu_impl qcom_smmu_500_impl = {
 	.init_context = qcom_smmu_init_context,
 	.cfg_probe = qcom_smmu_cfg_probe,
 	.def_domain_type = qcom_smmu_def_domain_type,
-	.reset = arm_mmu500_reset,
+	.reset = qcom_smmu500_reset,
 	.write_s2cr = qcom_smmu_write_s2cr,
 	.tlb_sync = qcom_smmu_tlb_sync,
 };
@@ -432,7 +463,7 @@ static const struct arm_smmu_impl qcom_adreno_smmu_v2_impl = {
 static const struct arm_smmu_impl qcom_adreno_smmu_500_impl = {
 	.init_context = qcom_adreno_smmu_init_context,
 	.def_domain_type = qcom_smmu_def_domain_type,
-	.reset = arm_mmu500_reset,
+	.reset = qcom_smmu500_reset,
 	.alloc_context_bank = qcom_adreno_smmu_alloc_context_bank,
 	.write_sctlr = qcom_adreno_smmu_write_sctlr,
 	.tlb_sync = qcom_smmu_tlb_sync,
--
2.17.1



From quic_bibekkum at quicinc.com  Wed Dec 20 05:38:05 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Wed, 20 Dec 2023 19:08:05 +0530
Subject: [PATCH v6 2/5] iommu/arm-smmu: refactor qcom_smmu structure to include single pointer
In-Reply-To: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
Message-ID: <20231220133808.5654-3-quic_bibekkum@quicinc.com>

qcom_smmu_match_data is static and constant so refactor qcom_smmu
to store single pointer to qcom_smmu_match_data instead of
replicating multiple child members of the same and handle the further
dereferences in the places that want them.

Suggested-by: Robin Murphy <robin.murphy at arm.com>
Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c       | 2 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h       | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
index bb89d49adf8d..e9798b133cbb 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
@@ -22,7 +22,7 @@ void qcom_smmu_tlb_sync_debug(struct arm_smmu_device *smmu)
 	if (__ratelimit(&rs)) {
 		dev_err(smmu->dev, "TLB sync timed out -- SMMU may be deadlocked\n");

-		cfg = qsmmu->cfg;
+		cfg = qsmmu->data->cfg;
 		if (!cfg)
 			return;

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 000e207346af..20c9836d859b 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -496,7 +496,7 @@ static struct arm_smmu_device *qcom_smmu_create(struct arm_smmu_device *smmu,
 		return ERR_PTR(-ENOMEM);

 	qsmmu->smmu.impl = impl;
-	qsmmu->cfg = data->cfg;
+	qsmmu->data = data;

 	return &qsmmu->smmu;
 }
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
index 593910567b88..f3b91963e234 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
@@ -8,7 +8,7 @@

 struct qcom_smmu {
 	struct arm_smmu_device smmu;
-	const struct qcom_smmu_config *cfg;
+	const struct qcom_smmu_match_data *data;
 	bool bypass_quirk;
 	u8 bypass_cbndx;
 	u32 stall_enabled;
--
2.17.1



From quic_bibekkum at quicinc.com  Wed Dec 20 05:38:06 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Wed, 20 Dec 2023 19:08:06 +0530
Subject: [PATCH v6 3/5] iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings
In-Reply-To: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
Message-ID: <20231220133808.5654-4-quic_bibekkum@quicinc.com>

Currently in Qualcomm  SoCs the default prefetch is set to 1 which allows
the TLB to fetch just the next page table. MMU-500 features ACTLR
register which is implementation defined and is used for Qualcomm SoCs
to have a custom prefetch setting enabling TLB to prefetch the next set
of page tables accordingly allowing for faster translations.

ACTLR value is unique for each SMR (Stream matching register) and stored
in a pre-populated table. This value is set to the register during
context bank initialisation.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 45 ++++++++++++++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h |  6 ++-
 drivers/iommu/arm/arm-smmu/arm-smmu.c      |  5 ++-
 drivers/iommu/arm/arm-smmu/arm-smmu.h      |  5 +++
 4 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 20c9836d859b..1cefdd0ca110 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -24,6 +24,12 @@
 #define CPRE			(1 << 1)
 #define CMTLB			(1 << 0)

+struct actlr_config {
+	u16 sid;
+	u16 mask;
+	u32 actlr;
+};
+
 static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
 {
 	return container_of(smmu, struct qcom_smmu, smmu);
@@ -215,9 +221,38 @@ static bool qcom_adreno_can_do_ttbr1(struct arm_smmu_device *smmu)
 	return true;
 }

+static void qcom_smmu_set_actlr(struct device *dev, struct arm_smmu_device *smmu, int cbndx,
+		const struct actlr_config *actlrcfg)
+{
+	struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
+	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+	struct arm_smmu_smr *smr;
+	u16 mask;
+	int idx;
+	u16 id;
+	int i;
+
+	for (; actlrcfg->sid || actlrcfg->mask || actlrcfg->actlr; actlrcfg++) {
+		id = actlrcfg->sid;
+		mask = actlrcfg->mask;
+
+		for_each_cfg_sme(cfg, fwspec, i, idx) {
+			smr = &smmu->smrs[idx];
+			if (smr_is_subset(smr, id, mask)) {
+				arm_smmu_cb_write(smmu, cbndx, ARM_SMMU_CB_ACTLR,
+						actlrcfg->actlr);
+				break;
+			}
+		}
+	}
+}
+
 static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 		struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
 {
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+	int cbndx = smmu_domain->cfg.cbndx;
 	struct adreno_smmu_priv *priv;

 	smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
@@ -248,6 +283,9 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 	priv->set_stall = qcom_adreno_smmu_set_stall;
 	priv->resume_translation = qcom_adreno_smmu_resume_translation;

+	if (qsmmu->data->actlrcfg_gfx)
+		qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg_gfx);
+
 	return 0;
 }

@@ -274,6 +312,13 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
 static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain,
 		struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
 {
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+	int cbndx = smmu_domain->cfg.cbndx;
+
+	if (qsmmu->data->actlrcfg)
+		qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg);
+
 	smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;

 	return 0;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
index f3b91963e234..cb4cb402c202 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
  */

 #ifndef _ARM_SMMU_QCOM_H
@@ -24,7 +24,11 @@ struct qcom_smmu_config {
 	const u32 *reg_offset;
 };

+struct actlr_config;
+
 struct qcom_smmu_match_data {
+	const struct actlr_config *actlrcfg;
+	const struct actlr_config *actlrcfg_gfx;
 	const struct qcom_smmu_config *cfg;
 	const struct arm_smmu_impl *impl;
 	const struct arm_smmu_impl *adreno_impl;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d6d1a2a55cc0..0c7f700b27dd 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -990,9 +990,10 @@ static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
 		 * expect simply identical entries for this case, but there's
 		 * no harm in accommodating the generalisation.
 		 */
-		if ((mask & smrs[i].mask) == mask &&
-		    !((id ^ smrs[i].id) & ~smrs[i].mask))
+
+		if (smr_is_subset(&smrs[i], id, mask))
 			return i;
+
 		/*
 		 * If the new entry has any other overlap with an existing one,
 		 * though, then there always exists at least one stream ID
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 703fd5817ec1..2e4f65412c6b 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -501,6 +501,11 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
 		writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);
 }

+static inline bool smr_is_subset(struct arm_smmu_smr *smrs, u16 id, u16 mask)
+{
+	return (mask & smrs->mask) == mask && !((id ^ smrs->id) & ~smrs->mask);
+}
+
 #define ARM_SMMU_GR0		0
 #define ARM_SMMU_GR1		1
 #define ARM_SMMU_CB(s, n)	((s)->numpage + (n))
--
2.17.1



From quic_bibekkum at quicinc.com  Wed Dec 20 05:38:07 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Wed, 20 Dec 2023 19:08:07 +0530
Subject: [PATCH v6 4/5] iommu/arm-smmu: add ACTLR data and support for SM8550
In-Reply-To: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
Message-ID: <20231220133808.5654-5-quic_bibekkum@quicinc.com>

Add ACTLR data table for SM8550 along with support for
same including SM8550 specific implementation operations.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 80 ++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 1cefdd0ca110..d6e87d0c8a4f 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -23,6 +23,12 @@

 #define CPRE			(1 << 1)
 #define CMTLB			(1 << 0)
+#define PREFETCH_SHIFT		8
+#define PREFETCH_DEFAULT	0
+#define PREFETCH_SHALLOW	(1 << PREFETCH_SHIFT)
+#define PREFETCH_MODERATE	(2 << PREFETCH_SHIFT)
+#define PREFETCH_DEEP		(3 << PREFETCH_SHIFT)
+#define PREFETCH_SWITCH_GFX	(5 << 3)

 struct actlr_config {
 	u16 sid;
@@ -30,6 +36,70 @@ struct actlr_config {
 	u32 actlr;
 };

+static const struct actlr_config sm8550_apps_actlr_cfg[] = {
+	{ 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x0800, 0x0020, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1800, 0x00c0, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1820, 0x0000, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1860, 0x0000, PREFETCH_DEFAULT | CMTLB },
+	{ 0x0c01, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c02, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c03, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c04, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c05, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c06, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c07, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c08, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c09, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0c, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0d, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0e, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x0c0f, 0x0020, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1961, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1962, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1963, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1964, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1965, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1966, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1967, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1968, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1969, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196c, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196d, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196e, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x196f, 0x0000, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c1, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c2, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c3, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c4, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c5, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c6, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c7, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c8, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19c9, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19cc, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19cd, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19ce, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x19cf, 0x0010, PREFETCH_DEEP | CPRE | CMTLB },
+	{ 0x1c00, 0x0002, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1c01, 0x0000, PREFETCH_DEFAULT | CMTLB },
+	{ 0x1920, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1923, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1924, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1940, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1941, 0x0004, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1943, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1944, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1947, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{},
+};
+
+static const struct actlr_config sm8550_gfx_actlr_cfg[] = {
+	{ 0x0000, 0x03ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE | CMTLB },
+	{},
+};
+
 static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
 {
 	return container_of(smmu, struct qcom_smmu, smmu);
@@ -580,6 +650,15 @@ static const struct qcom_smmu_match_data sdm845_smmu_500_data = {
 	/* Also no debug configuration. */
 };

+
+static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
+	.impl = &qcom_smmu_500_impl,
+	.adreno_impl = &qcom_adreno_smmu_500_impl,
+	.cfg = &qcom_smmu_impl0_cfg,
+	.actlrcfg = sm8550_apps_actlr_cfg,
+	.actlrcfg_gfx = sm8550_gfx_actlr_cfg,
+};
+
 static const struct qcom_smmu_match_data qcom_smmu_500_impl0_data = {
 	.impl = &qcom_smmu_500_impl,
 	.adreno_impl = &qcom_adreno_smmu_500_impl,
@@ -614,6 +693,7 @@ static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
 	{ .compatible = "qcom,sm8250-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sm8350-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sm8450-smmu-500", .data = &qcom_smmu_500_impl0_data },
+	{ .compatible = "qcom,sm8550-smmu-500", .data = &sm8550_smmu_500_impl0_data },
 	{ .compatible = "qcom,smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ }
 };
--
2.17.1



From quic_bibekkum at quicinc.com  Wed Dec 20 05:38:08 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Wed, 20 Dec 2023 19:08:08 +0530
Subject: [PATCH v6 5/5] iommu/arm-smmu: add ACTLR data and support for SC7280
In-Reply-To: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
Message-ID: <20231220133808.5654-6-quic_bibekkum@quicinc.com>

Add ACTLR data table for SC7280 along with support for
same including SC7280 specific implementation operations.

Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 25 +++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d6e87d0c8a4f..0b98e07820e1 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -36,6 +36,22 @@ struct actlr_config {
 	u32 actlr;
 };

+static const struct actlr_config sc7280_apps_actlr_cfg[] = {
+	{ 0x0800, 0x24e1, PREFETCH_DEFAULT | CMTLB },
+	{ 0x2000, 0x0163, PREFETCH_DEFAULT | CMTLB },
+	{ 0x2080, 0x0461, PREFETCH_DEFAULT | CMTLB },
+	{ 0x2100, 0x0161, PREFETCH_DEFAULT | CMTLB },
+	{ 0x0900, 0x0407, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x2180, 0x0027, PREFETCH_SHALLOW | CPRE | CMTLB },
+	{ 0x1000, 0x07ff, PREFETCH_DEEP | CPRE | CMTLB },
+	{},
+};
+
+static const struct actlr_config sc7280_gfx_actlr_cfg[] = {
+	{ 0x0000, 0x07ff, PREFETCH_SWITCH_GFX | PREFETCH_DEEP | CPRE | CMTLB },
+	{},
+};
+
 static const struct actlr_config sm8550_apps_actlr_cfg[] = {
 	{ 0x18a0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
 	{ 0x18e0, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
@@ -650,6 +666,13 @@ static const struct qcom_smmu_match_data sdm845_smmu_500_data = {
 	/* Also no debug configuration. */
 };

+static const struct qcom_smmu_match_data sc7280_smmu_500_impl0_data = {
+	.impl = &qcom_smmu_500_impl,
+	.adreno_impl = &qcom_adreno_smmu_500_impl,
+	.cfg = &qcom_smmu_impl0_cfg,
+	.actlrcfg = sc7280_apps_actlr_cfg,
+	.actlrcfg_gfx = sc7280_gfx_actlr_cfg,
+};

 static const struct qcom_smmu_match_data sm8550_smmu_500_impl0_data = {
 	.impl = &qcom_smmu_500_impl,
@@ -676,7 +699,7 @@ static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
 	{ .compatible = "qcom,qdu1000-smmu-500", .data = &qcom_smmu_500_impl0_data  },
 	{ .compatible = "qcom,sc7180-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sc7180-smmu-v2", .data = &qcom_smmu_v2_data },
-	{ .compatible = "qcom,sc7280-smmu-500", .data = &qcom_smmu_500_impl0_data },
+	{ .compatible = "qcom,sc7280-smmu-500", .data = &sc7280_smmu_500_impl0_data },
 	{ .compatible = "qcom,sc8180x-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sc8280xp-smmu-500", .data = &qcom_smmu_500_impl0_data },
 	{ .compatible = "qcom,sdm630-smmu-v2", .data = &qcom_smmu_v2_data },
--
2.17.1



From nicolas.dufresne at collabora.com  Wed Dec 20 05:47:25 2023
From: nicolas.dufresne at collabora.com (Nicolas Dufresne)
Date: Wed, 20 Dec 2023 08:47:25 -0500
Subject: [PATCH v3 2/5] media: hantro: add support for STM32MP25 VDEC
In-Reply-To: <20231220084641.2076428-3-hugues.fruchet@foss.st.com>
References: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
	 <20231220084641.2076428-3-hugues.fruchet@foss.st.com>
Message-ID: <174478b773ab2f5db8708c29b025332f75b24fe7.camel@collabora.com>

Le mercredi 20 d?cembre 2023 ? 09:46 +0100, Hugues Fruchet a ?crit?:
> Add support for STM32MP25 VDEC video hardware decoder.
> H264/VP8 decoding up to 4080x4080.
> No post-processor support.
> VDEC has its own reset/clock/irq.
> 
> Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>

Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>

> ---
>  drivers/media/platform/verisilicon/Kconfig    | 14 ++-
>  drivers/media/platform/verisilicon/Makefile   |  3 +
>  .../media/platform/verisilicon/hantro_drv.c   |  3 +
>  .../media/platform/verisilicon/hantro_hw.h    |  1 +
>  .../platform/verisilicon/stm32mp25_vdec_hw.c  | 92 +++++++++++++++++++
>  5 files changed, 110 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> 
> diff --git a/drivers/media/platform/verisilicon/Kconfig b/drivers/media/platform/verisilicon/Kconfig
> index e65b836b9d78..7642ff9cf96c 100644
> --- a/drivers/media/platform/verisilicon/Kconfig
> +++ b/drivers/media/platform/verisilicon/Kconfig
> @@ -4,7 +4,7 @@ comment "Verisilicon media platform drivers"
>  
>  config VIDEO_HANTRO
>  	tristate "Hantro VPU driver"
> -	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || COMPILE_TEST
> +	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || ARCH_STM32 || COMPILE_TEST
>  	depends on V4L_MEM2MEM_DRIVERS
>  	depends on VIDEO_DEV
>  	select MEDIA_CONTROLLER
> @@ -16,8 +16,8 @@ config VIDEO_HANTRO
>  	select V4L2_VP9
>  	help
>  	  Support for the Hantro IP based Video Processing Units present on
> -	  Rockchip and NXP i.MX8M SoCs, which accelerate video and image
> -	  encoding and decoding.
> +	  Rockchip, NXP i.MX8M and STM32MP25 SoCs, which accelerate video
> +	  and image encoding and decoding.
>  	  To compile this driver as a module, choose M here: the module
>  	  will be called hantro-vpu.
>  
> @@ -52,3 +52,11 @@ config VIDEO_HANTRO_SUNXI
>  	default y
>  	help
>  	  Enable support for H6 SoC.
> +
> +config VIDEO_HANTRO_STM32MP25
> +	bool "Hantro STM32MP25 support"
> +	depends on VIDEO_HANTRO
> +	depends on ARCH_STM32 || COMPILE_TEST
> +	default y
> +	help
> +	  Enable support for STM32MP25 SoCs.
> diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
> index 6ad2ef885920..5854e0f0dd32 100644
> --- a/drivers/media/platform/verisilicon/Makefile
> +++ b/drivers/media/platform/verisilicon/Makefile
> @@ -39,3 +39,6 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_ROCKCHIP) += \
>  
>  hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
>  		sunxi_vpu_hw.o
> +
> +hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
> +		stm32mp25_vdec_hw.o
> diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
> index a9fa05ac56a9..2db27c333924 100644
> --- a/drivers/media/platform/verisilicon/hantro_drv.c
> +++ b/drivers/media/platform/verisilicon/hantro_drv.c
> @@ -733,6 +733,9 @@ static const struct of_device_id of_hantro_match[] = {
>  #endif
>  #ifdef CONFIG_VIDEO_HANTRO_SUNXI
>  	{ .compatible = "allwinner,sun50i-h6-vpu-g2", .data = &sunxi_vpu_variant, },
> +#endif
> +#ifdef CONFIG_VIDEO_HANTRO_STM32MP25
> +	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
>  #endif
>  	{ /* sentinel */ }
>  };
> diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
> index 7f33f7b07ce4..b7eccc1a96fc 100644
> --- a/drivers/media/platform/verisilicon/hantro_hw.h
> +++ b/drivers/media/platform/verisilicon/hantro_hw.h
> @@ -406,6 +406,7 @@ extern const struct hantro_variant rk3568_vpu_variant;
>  extern const struct hantro_variant rk3588_vpu981_variant;
>  extern const struct hantro_variant sama5d4_vdec_variant;
>  extern const struct hantro_variant sunxi_vpu_variant;
> +extern const struct hantro_variant stm32mp25_vdec_variant;
>  
>  extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
>  extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
> diff --git a/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> new file mode 100644
> index 000000000000..aa8b0f751390
> --- /dev/null
> +++ b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * STM32MP25 VDEC video decoder driver
> + *
> + * Copyright (C) STMicroelectronics SA 2022
> + * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
> + *          for STMicroelectronics.
> + *
> + */
> +
> +#include "hantro.h"
> +
> +/*
> + * Supported formats.
> + */
> +
> +static const struct hantro_fmt stm32mp25_vdec_fmts[] = {
> +	{
> +		.fourcc = V4L2_PIX_FMT_NV12,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.frmsize = {
> +			.min_width = FMT_MIN_WIDTH,
> +			.max_width = FMT_FHD_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = FMT_MIN_HEIGHT,
> +			.max_height = FMT_FHD_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_VP8_FRAME,
> +		.codec_mode = HANTRO_MODE_VP8_DEC,
> +		.max_depth = 2,
> +		.frmsize = {
> +			.min_width = FMT_MIN_WIDTH,
> +			.max_width = FMT_FHD_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = FMT_MIN_HEIGHT,
> +			.max_height = FMT_FHD_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_H264_SLICE,
> +		.codec_mode = HANTRO_MODE_H264_DEC,
> +		.max_depth = 2,
> +		.frmsize = {
> +			.min_width = FMT_MIN_WIDTH,
> +			.max_width = FMT_FHD_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = FMT_MIN_HEIGHT,
> +			.max_height = FMT_FHD_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +};
> +
> +/*
> + * Supported codec ops.
> + */
> +
> +static const struct hantro_codec_ops stm32mp25_vdec_codec_ops[] = {
> +	[HANTRO_MODE_VP8_DEC] = {
> +		.run = hantro_g1_vp8_dec_run,
> +		.reset = hantro_g1_reset,
> +		.init = hantro_vp8_dec_init,
> +		.exit = hantro_vp8_dec_exit,
> +	},
> +	[HANTRO_MODE_H264_DEC] = {
> +		.run = hantro_g1_h264_dec_run,
> +		.reset = hantro_g1_reset,
> +		.init = hantro_h264_dec_init,
> +		.exit = hantro_h264_dec_exit,
> +	},
> +};
> +
> +static const struct hantro_irq stm32mp25_irqs[] = {
> +	{ "vdec", hantro_g1_irq },
> +};
> +
> +static const char * const stm32mp25_clk_names[] = { "vdec-clk" };
> +
> +const struct hantro_variant stm32mp25_vdec_variant = {
> +	.dec_fmts = stm32mp25_vdec_fmts,
> +	.num_dec_fmts = ARRAY_SIZE(stm32mp25_vdec_fmts),
> +	.codec = HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
> +	.codec_ops = stm32mp25_vdec_codec_ops,
> +	.irqs = stm32mp25_irqs,
> +	.num_irqs = ARRAY_SIZE(stm32mp25_irqs),
> +	.clk_names = stm32mp25_clk_names,
> +	.num_clocks = ARRAY_SIZE(stm32mp25_clk_names),
> +};



From xiaobo55x at gmail.com  Wed Dec 20 05:51:24 2023
From: xiaobo55x at gmail.com (Haibo Xu)
Date: Wed, 20 Dec 2023 21:51:24 +0800
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us
 in arch timer test
In-Reply-To: <f98879dc24f948f7a8a7b5374a32bc04@kernel.org>
References: <cover.1702371136.git.haibo1.xu@intel.com> <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
 <8734vy832j.wl-maz@kernel.org> <CAJve8onc0WN5g98aOVBmJx15wFBAqfBKJ+ufoLY+oqYyVL+=3A@mail.gmail.com>
 <f98879dc24f948f7a8a7b5374a32bc04@kernel.org>
Message-ID: <CAJve8ona7g=LxW1YeRB_FqGodF973H=A3b2m8054gmzK=Z7_ww@mail.gmail.com>

On Wed, Dec 20, 2023 at 5:00?PM Marc Zyngier <maz at kernel.org> wrote:
>
> On 2023-12-20 06:50, Haibo Xu wrote:
> > On Wed, Dec 20, 2023 at 2:22?AM Marc Zyngier <maz at kernel.org> wrote:
> >>
> >> On Tue, 12 Dec 2023 09:31:20 +0000,
> >> Haibo Xu <haibo1.xu at intel.com> wrote:
> >> > > @@ -216,6 +221,9 @@ static bool parse_args(int argc, char *argv[])
> >> >               case 'm':
> >> >                       test_args.migration_freq_ms = atoi_non_negative("Frequency", optarg);
> >> >                       break;
> >> > +             case 'e':
> >> > +                     test_args.timer_err_margin_us = atoi_non_negative("Error Margin", optarg);
> >> > +                     break;
> >>
> >> So your error margin is always unsigned...
> >>
> >
> > The error margin was supposed to be a non-negative [0, INT_MAX].
> > (May be need to define a Max for the input, instead of INT_MAX)
> >
> >> >               case 'o':
> >> >                       test_args.counter_offset = strtol(optarg, NULL, 0);
> >> >                       test_args.reserved = 0;
> >> > diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
> >> > index 968257b893a7..b1d405e7157d 100644
> >> > --- a/tools/testing/selftests/kvm/include/timer_test.h
> >> > +++ b/tools/testing/selftests/kvm/include/timer_test.h
> >> > @@ -22,6 +22,7 @@ struct test_args {
> >> >       int nr_iter;
> >> >       int timer_period_ms;
> >> >       int migration_freq_ms;
> >> > +     int timer_err_margin_us;
> >>
> >> ... except that you are storing it as a signed value. Some consistency
> >> wouldn't hurt, really, and would avoid issues when passing large
> >> values.
> >>
> >
> > Yes, it's more proper to use an unsigned int for the non-negative error
> > margin.
> > Storing as signed here is just to keep the type consistent with that
> > of timer_period_ms
> > since there will be '+' operation in other places.
> >
> >         tools/testing/selftests/kvm/aarch64/arch_timer.c
> >         /* Setup a timeout for the interrupt to arrive */
> >          udelay(msecs_to_usecs(test_args.timer_period_ms) +
> >              test_args.timer_err_margin_us);
>
> But that's exactly why using a signed quantity is wrong.
> What does it mean to have a huge *negative* margin?
>

Hi Marc,

I agree that negative values are meaningless for the margin.
If I understand correctly, the negative margin should be filtered by
assertion in atoi_non_negative().

Thanks,
Haibo

> I don't see how you can justify this.
>
>          M.
> --
> Jazz is not dead. It just smells funny...


From nicolas.dufresne at collabora.com  Wed Dec 20 05:53:26 2023
From: nicolas.dufresne at collabora.com (Nicolas Dufresne)
Date: Wed, 20 Dec 2023 08:53:26 -0500
Subject: [PATCH v3 3/5] media: hantro: add support for STM32MP25 VENC
In-Reply-To: <20231220084641.2076428-4-hugues.fruchet@foss.st.com>
References: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
	 <20231220084641.2076428-4-hugues.fruchet@foss.st.com>
Message-ID: <ca865271efc66cf51989d4d7d775ec4c59ce97d3.camel@collabora.com>

Hi,

Le mercredi 20 d?cembre 2023 ? 09:46 +0100, Hugues Fruchet a ?crit?:
> Add support for STM32MP25 VENC video hardware encoder.
> JPEG encoding up to 8176x8176.
> VENC has its own reset/clock/irq.
> 
> Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
> ---
>  drivers/media/platform/verisilicon/Makefile   |   3 +-
>  .../media/platform/verisilicon/hantro_drv.c   |   1 +
>  .../media/platform/verisilicon/hantro_hw.h    |   1 +
>  .../platform/verisilicon/stm32mp25_venc_hw.c  | 147 ++++++++++++++++++
>  4 files changed, 151 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
> 
> diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
> index 5854e0f0dd32..3bf43fdbedc1 100644
> --- a/drivers/media/platform/verisilicon/Makefile
> +++ b/drivers/media/platform/verisilicon/Makefile
> @@ -41,4 +41,5 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
>  		sunxi_vpu_hw.o
>  
>  hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
> -		stm32mp25_vdec_hw.o
> +		stm32mp25_vdec_hw.o \
> +		stm32mp25_venc_hw.o
> diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
> index 2db27c333924..4d97a8ac03de 100644
> --- a/drivers/media/platform/verisilicon/hantro_drv.c
> +++ b/drivers/media/platform/verisilicon/hantro_drv.c
> @@ -736,6 +736,7 @@ static const struct of_device_id of_hantro_match[] = {
>  #endif
>  #ifdef CONFIG_VIDEO_HANTRO_STM32MP25
>  	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
> +	{ .compatible = "st,stm32mp25-venc", .data = &stm32mp25_venc_variant, },
>  #endif
>  	{ /* sentinel */ }
>  };
> diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
> index b7eccc1a96fc..70c72e9d11d5 100644
> --- a/drivers/media/platform/verisilicon/hantro_hw.h
> +++ b/drivers/media/platform/verisilicon/hantro_hw.h
> @@ -407,6 +407,7 @@ extern const struct hantro_variant rk3588_vpu981_variant;
>  extern const struct hantro_variant sama5d4_vdec_variant;
>  extern const struct hantro_variant sunxi_vpu_variant;
>  extern const struct hantro_variant stm32mp25_vdec_variant;
> +extern const struct hantro_variant stm32mp25_venc_variant;
>  
>  extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
>  extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
> diff --git a/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
> new file mode 100644
> index 000000000000..9d220ff5f1a9
> --- /dev/null
> +++ b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * STM32MP25 VENC video encoder driver
> + *
> + * Copyright (C) STMicroelectronics SA 2022
> + * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
> + *          for STMicroelectronics.
> + *
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/reset.h>
> +
> +#include "hantro.h"
> +#include "hantro_jpeg.h"
> +#include "hantro_h1_regs.h"
> +
> +/*
> + * Supported formats.
> + */
> +
> +static const struct hantro_fmt stm32mp25_venc_fmts[] = {
> +	{
> +		.fourcc = V4L2_PIX_FMT_YUV420M,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420P,
> +		.frmsize = {
> +			.min_width = 96,
> +			.max_width = FMT_4K_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = 96,
> +			.max_height = FMT_4K_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_NV12M,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420SP,
> +		.frmsize = {
> +			.min_width = 96,
> +			.max_width = FMT_4K_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = 96,
> +			.max_height = FMT_4K_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_YUYV,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUYV422,
> +		.frmsize = {
> +			.min_width = 96,
> +			.max_width = FMT_4K_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = 96,
> +			.max_height = FMT_4K_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_UYVY,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_UYVY422,
> +		.frmsize = {
> +			.min_width = 96,
> +			.max_width = FMT_4K_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = 96,
> +			.max_height = FMT_4K_HEIGHT,
> +			.step_height = MB_DIM,
> +		},

For all the RAW formats, min/max/step isn't being used at the moment, so best to
drop it.

> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_JPEG,
> +		.codec_mode = HANTRO_MODE_JPEG_ENC,
> +		.max_depth = 2,
> +		.header_size = JPEG_HEADER_SIZE,
> +		.frmsize = {
> +			.min_width = 96,
> +			.max_width = FMT_4K_WIDTH,

This should be 8176 according to your commit message. Though, according to the
Rockchip integration, this is more likely 8192. I'd suggest to add a define and
share it if that is correct.

> +			.step_width = MB_DIM,
> +			.min_height = 96,
> +			.max_height = FMT_4K_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +};
> +
> +static irqreturn_t stm32mp25_venc_irq(int irq, void *dev_id)
> +{
> +	struct hantro_dev *vpu = dev_id;
> +	enum vb2_buffer_state state;
> +	u32 status;
> +
> +	status = vepu_read(vpu, H1_REG_INTERRUPT);
> +	state = (status & H1_REG_INTERRUPT_FRAME_RDY) ?
> +		VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
> +
> +	vepu_write(vpu, H1_REG_INTERRUPT_BIT, H1_REG_INTERRUPT);
> +
> +	hantro_irq_done(vpu, state);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static void stm32mp25_venc_reset(struct hantro_ctx *ctx)
> +{
> +}
> +
> +/*
> + * Supported codec ops.
> + */
> +
> +static const struct hantro_codec_ops stm32mp25_venc_codec_ops[] = {
> +	[HANTRO_MODE_JPEG_ENC] = {
> +		.run = hantro_h1_jpeg_enc_run,
> +		.reset = stm32mp25_venc_reset,
> +		.done = hantro_h1_jpeg_enc_done,
> +	},
> +};
> +
> +/*
> + * Variants.
> + */
> +
> +static const struct hantro_irq stm32mp25_venc_irqs[] = {
> +	{ "venc", stm32mp25_venc_irq },
> +};
> +
> +static const char * const stm32mp25_venc_clk_names[] = {
> +	"venc-clk"
> +};
> +
> +const struct hantro_variant stm32mp25_venc_variant = {
> +	.enc_fmts = stm32mp25_venc_fmts,
> +	.num_enc_fmts = ARRAY_SIZE(stm32mp25_venc_fmts),
> +	.codec = HANTRO_JPEG_ENCODER,
> +	.codec_ops = stm32mp25_venc_codec_ops,
> +	.irqs = stm32mp25_venc_irqs,
> +	.num_irqs = ARRAY_SIZE(stm32mp25_venc_irqs),
> +	.clk_names = stm32mp25_venc_clk_names,
> +	.num_clocks = ARRAY_SIZE(stm32mp25_venc_clk_names)
> +};
> +



From gregory.clement at bootlin.com  Wed Dec 20 05:55:39 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Wed, 20 Dec 2023 14:55:39 +0100
Subject: [PATCH v2 0/3] Moxtet bus fixes
In-Reply-To: <6c93241c35153cfb718db1d81e99e01bfb6dede5.camel@collabora.com>
References: <20231128213536.3764212-1-sjoerd@collabora.com>
 <87fs0ceoif.fsf@BL-laptop> <20231208161724.5f4f626a@dellmb>
 <87fs03cyki.fsf@BL-laptop>
 <6c93241c35153cfb718db1d81e99e01bfb6dede5.camel@collabora.com>
Message-ID: <87o7elash0.fsf@BL-laptop>

Sjoerd Simons <sjoerd at collabora.com> writes:

> On Fri, 2023-12-15 at 15:47 +0100, Gregory CLEMENT wrote:
>> Marek Beh?n <kabel at kernel.org> writes:
>> 
>> > On Fri, 08 Dec 2023 15:51:20 +0100
>> > Gregory CLEMENT <gregory.clement at bootlin.com> wrote:
>> > 
>> > Gregory, as of yet I've never done a pull request. If you are
>> > willing
>> > to take all 3 patches now, please do. In the future I would like to
>> 
>> OK I applied them on mvebu/driver.
>
> Thanks both for moving this patches forward; Gregory looks like you
> only applied two of the three patches (missing the dt patch), are you
> expect that to flow through a different tree or ?

The device tree patch is applied on mvebu/dt64, I've just pushed the
updated branch, but it was already in the for-next branch.

Gregory

>
>
> Regards,
> -- 
> Sjoerd Simons
> Collabora Ltd.

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From nicolas.dufresne at collabora.com  Wed Dec 20 05:56:41 2023
From: nicolas.dufresne at collabora.com (Nicolas Dufresne)
Date: Wed, 20 Dec 2023 08:56:41 -0500
Subject: [PATCH v3 2/5] media: hantro: add support for STM32MP25 VDEC
In-Reply-To: <174478b773ab2f5db8708c29b025332f75b24fe7.camel@collabora.com>
References: <20231220084641.2076428-1-hugues.fruchet@foss.st.com>
	 <20231220084641.2076428-3-hugues.fruchet@foss.st.com>
	 <174478b773ab2f5db8708c29b025332f75b24fe7.camel@collabora.com>
Message-ID: <27ae0842f38b16b53dc167ff5a4bdd7dd8a52ae5.camel@collabora.com>

Le mercredi 20 d?cembre 2023 ? 08:47 -0500, Nicolas Dufresne a ?crit?:
> Le mercredi 20 d?cembre 2023 ? 09:46 +0100, Hugues Fruchet a ?crit?:
> > Add support for STM32MP25 VDEC video hardware decoder.
> > H264/VP8 decoding up to 4080x4080.

Missed that earlier, but the code sets 4096x2304, I believe you forgot to update
the description here. With that minor change, my R-b can stay of course.

> > No post-processor support.
> > VDEC has its own reset/clock/irq.
> > 
> > Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
> 
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>
> 
> > ---
> >  drivers/media/platform/verisilicon/Kconfig    | 14 ++-
> >  drivers/media/platform/verisilicon/Makefile   |  3 +
> >  .../media/platform/verisilicon/hantro_drv.c   |  3 +
> >  .../media/platform/verisilicon/hantro_hw.h    |  1 +
> >  .../platform/verisilicon/stm32mp25_vdec_hw.c  | 92 +++++++++++++++++++
> >  5 files changed, 110 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> > 
> > diff --git a/drivers/media/platform/verisilicon/Kconfig b/drivers/media/platform/verisilicon/Kconfig
> > index e65b836b9d78..7642ff9cf96c 100644
> > --- a/drivers/media/platform/verisilicon/Kconfig
> > +++ b/drivers/media/platform/verisilicon/Kconfig
> > @@ -4,7 +4,7 @@ comment "Verisilicon media platform drivers"
> >  
> >  config VIDEO_HANTRO
> >  	tristate "Hantro VPU driver"
> > -	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || COMPILE_TEST
> > +	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || ARCH_STM32 || COMPILE_TEST
> >  	depends on V4L_MEM2MEM_DRIVERS
> >  	depends on VIDEO_DEV
> >  	select MEDIA_CONTROLLER
> > @@ -16,8 +16,8 @@ config VIDEO_HANTRO
> >  	select V4L2_VP9
> >  	help
> >  	  Support for the Hantro IP based Video Processing Units present on
> > -	  Rockchip and NXP i.MX8M SoCs, which accelerate video and image
> > -	  encoding and decoding.
> > +	  Rockchip, NXP i.MX8M and STM32MP25 SoCs, which accelerate video
> > +	  and image encoding and decoding.
> >  	  To compile this driver as a module, choose M here: the module
> >  	  will be called hantro-vpu.
> >  
> > @@ -52,3 +52,11 @@ config VIDEO_HANTRO_SUNXI
> >  	default y
> >  	help
> >  	  Enable support for H6 SoC.
> > +
> > +config VIDEO_HANTRO_STM32MP25
> > +	bool "Hantro STM32MP25 support"
> > +	depends on VIDEO_HANTRO
> > +	depends on ARCH_STM32 || COMPILE_TEST
> > +	default y
> > +	help
> > +	  Enable support for STM32MP25 SoCs.
> > diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
> > index 6ad2ef885920..5854e0f0dd32 100644
> > --- a/drivers/media/platform/verisilicon/Makefile
> > +++ b/drivers/media/platform/verisilicon/Makefile
> > @@ -39,3 +39,6 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_ROCKCHIP) += \
> >  
> >  hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
> >  		sunxi_vpu_hw.o
> > +
> > +hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
> > +		stm32mp25_vdec_hw.o
> > diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
> > index a9fa05ac56a9..2db27c333924 100644
> > --- a/drivers/media/platform/verisilicon/hantro_drv.c
> > +++ b/drivers/media/platform/verisilicon/hantro_drv.c
> > @@ -733,6 +733,9 @@ static const struct of_device_id of_hantro_match[] = {
> >  #endif
> >  #ifdef CONFIG_VIDEO_HANTRO_SUNXI
> >  	{ .compatible = "allwinner,sun50i-h6-vpu-g2", .data = &sunxi_vpu_variant, },
> > +#endif
> > +#ifdef CONFIG_VIDEO_HANTRO_STM32MP25
> > +	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
> >  #endif
> >  	{ /* sentinel */ }
> >  };
> > diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
> > index 7f33f7b07ce4..b7eccc1a96fc 100644
> > --- a/drivers/media/platform/verisilicon/hantro_hw.h
> > +++ b/drivers/media/platform/verisilicon/hantro_hw.h
> > @@ -406,6 +406,7 @@ extern const struct hantro_variant rk3568_vpu_variant;
> >  extern const struct hantro_variant rk3588_vpu981_variant;
> >  extern const struct hantro_variant sama5d4_vdec_variant;
> >  extern const struct hantro_variant sunxi_vpu_variant;
> > +extern const struct hantro_variant stm32mp25_vdec_variant;
> >  
> >  extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
> >  extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
> > diff --git a/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> > new file mode 100644
> > index 000000000000..aa8b0f751390
> > --- /dev/null
> > +++ b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> > @@ -0,0 +1,92 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * STM32MP25 VDEC video decoder driver
> > + *
> > + * Copyright (C) STMicroelectronics SA 2022
> > + * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
> > + *          for STMicroelectronics.
> > + *
> > + */
> > +
> > +#include "hantro.h"
> > +
> > +/*
> > + * Supported formats.
> > + */
> > +
> > +static const struct hantro_fmt stm32mp25_vdec_fmts[] = {
> > +	{
> > +		.fourcc = V4L2_PIX_FMT_NV12,
> > +		.codec_mode = HANTRO_MODE_NONE,
> > +		.frmsize = {
> > +			.min_width = FMT_MIN_WIDTH,
> > +			.max_width = FMT_FHD_WIDTH,
> > +			.step_width = MB_DIM,
> > +			.min_height = FMT_MIN_HEIGHT,
> > +			.max_height = FMT_FHD_HEIGHT,
> > +			.step_height = MB_DIM,
> > +		},
> > +	},
> > +	{
> > +		.fourcc = V4L2_PIX_FMT_VP8_FRAME,
> > +		.codec_mode = HANTRO_MODE_VP8_DEC,
> > +		.max_depth = 2,
> > +		.frmsize = {
> > +			.min_width = FMT_MIN_WIDTH,
> > +			.max_width = FMT_FHD_WIDTH,
> > +			.step_width = MB_DIM,
> > +			.min_height = FMT_MIN_HEIGHT,
> > +			.max_height = FMT_FHD_HEIGHT,
> > +			.step_height = MB_DIM,
> > +		},
> > +	},
> > +	{
> > +		.fourcc = V4L2_PIX_FMT_H264_SLICE,
> > +		.codec_mode = HANTRO_MODE_H264_DEC,
> > +		.max_depth = 2,
> > +		.frmsize = {
> > +			.min_width = FMT_MIN_WIDTH,
> > +			.max_width = FMT_FHD_WIDTH,
> > +			.step_width = MB_DIM,
> > +			.min_height = FMT_MIN_HEIGHT,
> > +			.max_height = FMT_FHD_HEIGHT,
> > +			.step_height = MB_DIM,
> > +		},
> > +	},
> > +};
> > +
> > +/*
> > + * Supported codec ops.
> > + */
> > +
> > +static const struct hantro_codec_ops stm32mp25_vdec_codec_ops[] = {
> > +	[HANTRO_MODE_VP8_DEC] = {
> > +		.run = hantro_g1_vp8_dec_run,
> > +		.reset = hantro_g1_reset,
> > +		.init = hantro_vp8_dec_init,
> > +		.exit = hantro_vp8_dec_exit,
> > +	},
> > +	[HANTRO_MODE_H264_DEC] = {
> > +		.run = hantro_g1_h264_dec_run,
> > +		.reset = hantro_g1_reset,
> > +		.init = hantro_h264_dec_init,
> > +		.exit = hantro_h264_dec_exit,
> > +	},
> > +};
> > +
> > +static const struct hantro_irq stm32mp25_irqs[] = {
> > +	{ "vdec", hantro_g1_irq },
> > +};
> > +
> > +static const char * const stm32mp25_clk_names[] = { "vdec-clk" };
> > +
> > +const struct hantro_variant stm32mp25_vdec_variant = {
> > +	.dec_fmts = stm32mp25_vdec_fmts,
> > +	.num_dec_fmts = ARRAY_SIZE(stm32mp25_vdec_fmts),
> > +	.codec = HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
> > +	.codec_ops = stm32mp25_vdec_codec_ops,
> > +	.irqs = stm32mp25_irqs,
> > +	.num_irqs = ARRAY_SIZE(stm32mp25_irqs),
> > +	.clk_names = stm32mp25_clk_names,
> > +	.num_clocks = ARRAY_SIZE(stm32mp25_clk_names),
> > +};
> 
> 



From angelogioacchino.delregno at collabora.com  Wed Dec 20 05:57:18 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 14:57:18 +0100
Subject: [PATCH v2 0/4] MediaTek DRM - DSI driver cleanups
Message-ID: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com>

Changes in v2:
 - Rebased over next-20231213

This series performs some cleanups for mtk_dsi, enhancing human
readability, using kernel provided macros where possible and
also reducing code size.

Tested on MT8173 and MT8192 Chromebooks (using a DSI<->DP bridge)
and on MT6795 Sony Xperia M5 (DSI video mode panel).

AngeloGioacchino Del Regno (4):
  drm/mediatek: dsi: Use GENMASK() for register mask definitions
  drm/mediatek: dsi: Cleanup functions mtk_dsi_ps_control{_vact}()
  drm/mediatek: dsi: Use bitfield macros where useful
  drm/mediatek: dsi: Replace open-coded instance of HZ_PER_MHZ

 drivers/gpu/drm/mediatek/mtk_dsi.c | 198 +++++++++++++----------------
 1 file changed, 88 insertions(+), 110 deletions(-)

-- 
2.43.0



From angelogioacchino.delregno at collabora.com  Wed Dec 20 05:57:20 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 14:57:20 +0100
Subject: [PATCH v2 2/4] drm/mediatek: dsi: Cleanup functions mtk_dsi_ps_control{_vact}()
In-Reply-To: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com>
References: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com>
Message-ID: <20231220135722.192080-3-angelogioacchino.delregno@collabora.com>

Function mtk_dsi_ps_control() is a subset of mtk_dsi_ps_control_vact():
merge the two in one mtk_dsi_ps_control() function by adding one
function parameter `config_vact` which, when true, writes the VACT
related registers.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 76 +++++++++---------------------
 1 file changed, 23 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 23d2c5be8dbb..b618e2e31022 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -352,40 +352,6 @@ static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
 	mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
 }
 
-static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
-{
-	struct videomode *vm = &dsi->vm;
-	u32 dsi_buf_bpp, ps_wc;
-	u32 ps_bpp_mode;
-
-	if (dsi->format == MIPI_DSI_FMT_RGB565)
-		dsi_buf_bpp = 2;
-	else
-		dsi_buf_bpp = 3;
-
-	ps_wc = vm->hactive * dsi_buf_bpp;
-	ps_bpp_mode = ps_wc;
-
-	switch (dsi->format) {
-	case MIPI_DSI_FMT_RGB888:
-		ps_bpp_mode |= PACKED_PS_24BIT_RGB888;
-		break;
-	case MIPI_DSI_FMT_RGB666:
-		ps_bpp_mode |= PACKED_PS_18BIT_RGB666;
-		break;
-	case MIPI_DSI_FMT_RGB666_PACKED:
-		ps_bpp_mode |= LOOSELY_PS_18BIT_RGB666;
-		break;
-	case MIPI_DSI_FMT_RGB565:
-		ps_bpp_mode |= PACKED_PS_16BIT_RGB565;
-		break;
-	}
-
-	writel(vm->vactive, dsi->regs + DSI_VACT_NL);
-	writel(ps_bpp_mode, dsi->regs + DSI_PSCTRL);
-	writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
-}
-
 static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
 {
 	u32 tmp_reg;
@@ -417,36 +383,40 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
 	writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
 }
 
-static void mtk_dsi_ps_control(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control(struct mtk_dsi *dsi, bool config_vact)
 {
-	u32 dsi_tmp_buf_bpp;
-	u32 tmp_reg;
+	struct videomode *vm = &dsi->vm;
+	u32 dsi_buf_bpp, ps_wc;
+	u32 ps_bpp_mode;
+
+	if (dsi->format == MIPI_DSI_FMT_RGB565)
+		dsi_buf_bpp = 2;
+	else
+		dsi_buf_bpp = 3;
+
+	ps_wc = vm->hactive * dsi_buf_bpp;
+	ps_bpp_mode = ps_wc;
 
 	switch (dsi->format) {
 	case MIPI_DSI_FMT_RGB888:
-		tmp_reg = PACKED_PS_24BIT_RGB888;
-		dsi_tmp_buf_bpp = 3;
+		ps_bpp_mode |= PACKED_PS_24BIT_RGB888;
 		break;
 	case MIPI_DSI_FMT_RGB666:
-		tmp_reg = LOOSELY_PS_18BIT_RGB666;
-		dsi_tmp_buf_bpp = 3;
+		ps_bpp_mode |= PACKED_PS_18BIT_RGB666;
 		break;
 	case MIPI_DSI_FMT_RGB666_PACKED:
-		tmp_reg = PACKED_PS_18BIT_RGB666;
-		dsi_tmp_buf_bpp = 3;
+		ps_bpp_mode |= LOOSELY_PS_18BIT_RGB666;
 		break;
 	case MIPI_DSI_FMT_RGB565:
-		tmp_reg = PACKED_PS_16BIT_RGB565;
-		dsi_tmp_buf_bpp = 2;
-		break;
-	default:
-		tmp_reg = PACKED_PS_24BIT_RGB888;
-		dsi_tmp_buf_bpp = 3;
+		ps_bpp_mode |= PACKED_PS_16BIT_RGB565;
 		break;
 	}
 
-	tmp_reg += dsi->vm.hactive * dsi_tmp_buf_bpp & DSI_PS_WC;
-	writel(tmp_reg, dsi->regs + DSI_PSCTRL);
+	if (config_vact) {
+		writel(vm->vactive, dsi->regs + DSI_VACT_NL);
+		writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
+	}
+	writel(ps_bpp_mode, dsi->regs + DSI_PSCTRL);
 }
 
 static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
@@ -522,7 +492,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
 	writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
 	writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
 
-	mtk_dsi_ps_control(dsi);
+	mtk_dsi_ps_control(dsi, false);
 }
 
 static void mtk_dsi_start(struct mtk_dsi *dsi)
@@ -667,7 +637,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 	mtk_dsi_reset_engine(dsi);
 	mtk_dsi_phy_timconfig(dsi);
 
-	mtk_dsi_ps_control_vact(dsi);
+	mtk_dsi_ps_control(dsi, true);
 	mtk_dsi_set_vm_cmd(dsi);
 	mtk_dsi_config_vdo_timing(dsi);
 	mtk_dsi_set_interrupt_enable(dsi);
-- 
2.43.0



From angelogioacchino.delregno at collabora.com  Wed Dec 20 05:57:19 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 14:57:19 +0100
Subject: [PATCH v2 1/4] drm/mediatek: dsi: Use GENMASK() for register mask definitions
In-Reply-To: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com>
References: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com>
Message-ID: <20231220135722.192080-2-angelogioacchino.delregno@collabora.com>

Change magic numerical masks with usage of the GENMASK() macro
to improve readability.

This commit brings no functional changes.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 46 ++++++++++++++++--------------
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index a2fdfc8ddb15..23d2c5be8dbb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -58,18 +58,18 @@
 
 #define DSI_TXRX_CTRL		0x18
 #define VC_NUM				BIT(1)
-#define LANE_NUM			(0xf << 2)
+#define LANE_NUM			GENMASK(5, 2)
 #define DIS_EOT				BIT(6)
 #define NULL_EN				BIT(7)
 #define TE_FREERUN			BIT(8)
 #define EXT_TE_EN			BIT(9)
 #define EXT_TE_EDGE			BIT(10)
-#define MAX_RTN_SIZE			(0xf << 12)
+#define MAX_RTN_SIZE			GENMASK(15, 12)
 #define HSTX_CKLP_EN			BIT(16)
 
 #define DSI_PSCTRL		0x1c
-#define DSI_PS_WC			0x3fff
-#define DSI_PS_SEL			(3 << 16)
+#define DSI_PS_WC			GENMASK(14, 0)
+#define DSI_PS_SEL			GENMASK(19, 16)
 #define PACKED_PS_16BIT_RGB565		(0 << 16)
 #define LOOSELY_PS_18BIT_RGB666		(1 << 16)
 #define PACKED_PS_18BIT_RGB666		(2 << 16)
@@ -109,26 +109,27 @@
 #define LD0_WAKEUP_EN			BIT(2)
 
 #define DSI_PHY_TIMECON0	0x110
-#define LPX				(0xff << 0)
-#define HS_PREP				(0xff << 8)
-#define HS_ZERO				(0xff << 16)
-#define HS_TRAIL			(0xff << 24)
+#define LPX				GENMASK(7, 0)
+#define HS_PREP				GENMASK(15, 8)
+#define HS_ZERO				GENMASK(23, 16)
+#define HS_TRAIL			GENMASK(31, 24)
 
 #define DSI_PHY_TIMECON1	0x114
-#define TA_GO				(0xff << 0)
-#define TA_SURE				(0xff << 8)
-#define TA_GET				(0xff << 16)
-#define DA_HS_EXIT			(0xff << 24)
+#define TA_GO				GENMASK(7, 0)
+#define TA_SURE				GENMASK(15, 8)
+#define TA_GET				GENMASK(23, 16)
+#define DA_HS_EXIT			GENMASK(31, 24)
 
 #define DSI_PHY_TIMECON2	0x118
-#define CONT_DET			(0xff << 0)
-#define CLK_ZERO			(0xff << 16)
-#define CLK_TRAIL			(0xff << 24)
+#define CONT_DET			GENMASK(7, 0)
+#define DA_HS_SYNC			GENMASK(15, 8)
+#define CLK_ZERO			GENMASK(23, 16)
+#define CLK_TRAIL			GENMASK(31, 24)
 
 #define DSI_PHY_TIMECON3	0x11c
-#define CLK_HS_PREP			(0xff << 0)
-#define CLK_HS_POST			(0xff << 8)
-#define CLK_HS_EXIT			(0xff << 16)
+#define CLK_HS_PREP			GENMASK(7, 0)
+#define CLK_HS_POST			GENMASK(15, 8)
+#define CLK_HS_EXIT			GENMASK(23, 16)
 
 #define DSI_VM_CMD_CON		0x130
 #define VM_CMD_EN			BIT(0)
@@ -138,13 +139,14 @@
 #define FORCE_COMMIT			BIT(0)
 #define BYPASS_SHADOW			BIT(1)
 
-#define CONFIG				(0xff << 0)
+/* CMDQ related bits */
+#define CONFIG				GENMASK(7, 0)
 #define SHORT_PACKET			0
 #define LONG_PACKET			2
 #define BTA				BIT(2)
-#define DATA_ID				(0xff << 8)
-#define DATA_0				(0xff << 16)
-#define DATA_1				(0xff << 24)
+#define DATA_ID				GENMASK(15, 8)
+#define DATA_0				GENMASK(23, 16)
+#define DATA_1				GENMASK(31, 24)
 
 #define NS_TO_CYCLE(n, c)    ((n) / (c) + (((n) % (c)) ? 1 : 0))
 
-- 
2.43.0



From angelogioacchino.delregno at collabora.com  Wed Dec 20 05:57:21 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 14:57:21 +0100
Subject: [PATCH v2 3/4] drm/mediatek: dsi: Use bitfield macros where useful
In-Reply-To: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com>
References: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com>
Message-ID: <20231220135722.192080-4-angelogioacchino.delregno@collabora.com>

Instead of open coding bitshifting for various register fields,
use the bitfield macro FIELD_PREP(): this allows to enhance the
human readability, decrease likeliness of mistakes (and register
field overflowing) and also to simplify the code.
The latter is especially seen in mtk_dsi_rxtx_control(), where
it was possible to change a switch to a short for loop and to
also remove the need to check for maximum DSI lanes == 4 thanks
to the FIELD_PREP macro masking the value.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 95 ++++++++++++++++--------------
 1 file changed, 50 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b618e2e31022..2ba6cd129150 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -70,16 +70,19 @@
 #define DSI_PSCTRL		0x1c
 #define DSI_PS_WC			GENMASK(14, 0)
 #define DSI_PS_SEL			GENMASK(19, 16)
-#define PACKED_PS_16BIT_RGB565		(0 << 16)
-#define LOOSELY_PS_18BIT_RGB666		(1 << 16)
-#define PACKED_PS_18BIT_RGB666		(2 << 16)
-#define PACKED_PS_24BIT_RGB888		(3 << 16)
+#define PACKED_PS_16BIT_RGB565		0
+#define LOOSELY_PS_18BIT_RGB666		1
+#define PACKED_PS_18BIT_RGB666		2
+#define PACKED_PS_24BIT_RGB888		3
 
 #define DSI_VSA_NL		0x20
 #define DSI_VBP_NL		0x24
 #define DSI_VFP_NL		0x28
 #define DSI_VACT_NL		0x2C
+#define VACT_NL				GENMASK(14, 0)
 #define DSI_SIZE_CON		0x38
+#define DSI_HEIGHT				GENMASK(30, 16)
+#define DSI_WIDTH				GENMASK(14, 0)
 #define DSI_HSA_WC		0x50
 #define DSI_HBP_WC		0x54
 #define DSI_HFP_WC		0x58
@@ -254,14 +257,23 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
 	timing->clk_hs_zero = timing->clk_hs_trail * 4;
 	timing->clk_hs_exit = 2 * timing->clk_hs_trail;
 
-	timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
-		  timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
-	timcon1 = timing->ta_go | timing->ta_sure << 8 |
-		  timing->ta_get << 16 | timing->da_hs_exit << 24;
-	timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
-		  timing->clk_hs_trail << 24;
-	timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
-		  timing->clk_hs_exit << 16;
+	timcon0 = FIELD_PREP(LPX, timing->lpx) |
+		  FIELD_PREP(HS_PREP, timing->da_hs_prepare) |
+		  FIELD_PREP(HS_ZERO, timing->da_hs_zero) |
+		  FIELD_PREP(HS_TRAIL, timing->da_hs_trail);
+
+	timcon1 = FIELD_PREP(TA_GO, timing->ta_go) |
+		  FIELD_PREP(TA_SURE, timing->ta_sure) |
+		  FIELD_PREP(TA_GET, timing->ta_get) |
+		  FIELD_PREP(DA_HS_EXIT, timing->da_hs_exit);
+
+	timcon2 = FIELD_PREP(DA_HS_SYNC, 1) |
+		  FIELD_PREP(CLK_ZERO, timing->clk_hs_zero) |
+		  FIELD_PREP(CLK_TRAIL, timing->clk_hs_trail);
+
+	timcon3 = FIELD_PREP(CLK_HS_PREP, timing->clk_hs_prepare) |
+		  FIELD_PREP(CLK_HS_POST, timing->clk_hs_post) |
+		  FIELD_PREP(CLK_HS_EXIT, timing->clk_hs_exit);
 
 	writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
 	writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -354,69 +366,61 @@ static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
 
 static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
 {
-	u32 tmp_reg;
+	u32 regval, tmp_reg = 0;
+	u8 i;
 
-	switch (dsi->lanes) {
-	case 1:
-		tmp_reg = 1 << 2;
-		break;
-	case 2:
-		tmp_reg = 3 << 2;
-		break;
-	case 3:
-		tmp_reg = 7 << 2;
-		break;
-	case 4:
-		tmp_reg = 0xf << 2;
-		break;
-	default:
-		tmp_reg = 0xf << 2;
-		break;
-	}
+	/* Number of DSI lanes (max 4 lanes), each bit enables one DSI lane. */
+	for (i = 0; i < dsi->lanes; i++)
+		tmp_reg |= BIT(i);
+
+	regval = FIELD_PREP(LANE_NUM, tmp_reg);
 
 	if (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
-		tmp_reg |= HSTX_CKLP_EN;
+		regval |= HSTX_CKLP_EN;
 
 	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
-		tmp_reg |= DIS_EOT;
+		regval |= DIS_EOT;
 
-	writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
+	writel(regval, dsi->regs + DSI_TXRX_CTRL);
 }
 
 static void mtk_dsi_ps_control(struct mtk_dsi *dsi, bool config_vact)
 {
-	struct videomode *vm = &dsi->vm;
-	u32 dsi_buf_bpp, ps_wc;
-	u32 ps_bpp_mode;
+	u32 dsi_buf_bpp, ps_val, ps_wc, vact_nl;
 
 	if (dsi->format == MIPI_DSI_FMT_RGB565)
 		dsi_buf_bpp = 2;
 	else
 		dsi_buf_bpp = 3;
 
-	ps_wc = vm->hactive * dsi_buf_bpp;
-	ps_bpp_mode = ps_wc;
+	/* Word count */
+	ps_wc = FIELD_PREP(DSI_PS_WC, dsi->vm.hactive * dsi_buf_bpp);
+	ps_val = ps_wc;
 
+	/* Pixel Stream type */
 	switch (dsi->format) {
+	default:
+		/* fallthrough */
 	case MIPI_DSI_FMT_RGB888:
-		ps_bpp_mode |= PACKED_PS_24BIT_RGB888;
+		ps_val |= FIELD_PREP(DSI_PS_SEL, PACKED_PS_24BIT_RGB888);
 		break;
 	case MIPI_DSI_FMT_RGB666:
-		ps_bpp_mode |= PACKED_PS_18BIT_RGB666;
+		ps_val |= FIELD_PREP(DSI_PS_SEL, PACKED_PS_18BIT_RGB666);
 		break;
 	case MIPI_DSI_FMT_RGB666_PACKED:
-		ps_bpp_mode |= LOOSELY_PS_18BIT_RGB666;
+		ps_val |= FIELD_PREP(DSI_PS_SEL, LOOSELY_PS_18BIT_RGB666);
 		break;
 	case MIPI_DSI_FMT_RGB565:
-		ps_bpp_mode |= PACKED_PS_16BIT_RGB565;
+		ps_val |= FIELD_PREP(DSI_PS_SEL, PACKED_PS_16BIT_RGB565);
 		break;
 	}
 
 	if (config_vact) {
-		writel(vm->vactive, dsi->regs + DSI_VACT_NL);
+		vact_nl = FIELD_PREP(VACT_NL, dsi->vm.vactive);
+		writel(vact_nl, dsi->regs + DSI_VACT_NL);
 		writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
 	}
-	writel(ps_bpp_mode, dsi->regs + DSI_PSCTRL);
+	writel(ps_val, dsi->regs + DSI_PSCTRL);
 }
 
 static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
@@ -443,7 +447,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
 	writel(vm->vactive, dsi->regs + DSI_VACT_NL);
 
 	if (dsi->driver_data->has_size_ctl)
-		writel(vm->vactive << 16 | vm->hactive,
+		writel(FIELD_PREP(DSI_HEIGHT, vm->vactive) |
+		       FIELD_PREP(DSI_WIDTH, vm->hactive),
 		       dsi->regs + DSI_SIZE_CON);
 
 	horizontal_sync_active_byte = (vm->hsync_len * dsi_tmp_buf_bpp - 10);
-- 
2.43.0



From angelogioacchino.delregno at collabora.com  Wed Dec 20 05:57:22 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 14:57:22 +0100
Subject: [PATCH v2 4/4] drm/mediatek: dsi: Replace open-coded instance of HZ_PER_MHZ
In-Reply-To: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com>
References: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com>
Message-ID: <20231220135722.192080-5-angelogioacchino.delregno@collabora.com>

In mtk_dsi_phy_timconfig(), we're dividing the `data_rate` variable,
expressed in Hz to retrieve a value in MHz: instead of open-coding,
use the HZ_PER_MHZ definition, available in linux/units.h.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 2ba6cd129150..b9a37407f3b4 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -12,6 +12,7 @@
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
 #include <linux/reset.h>
+#include <linux/units.h>
 
 #include <video/mipi_display.h>
 #include <video/videomode.h>
@@ -237,7 +238,7 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
 static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
 {
 	u32 timcon0, timcon1, timcon2, timcon3;
-	u32 data_rate_mhz = DIV_ROUND_UP(dsi->data_rate, 1000000);
+	u32 data_rate_mhz = DIV_ROUND_UP(dsi->data_rate, HZ_PER_MHZ);
 	struct mtk_phy_timing *timing = &dsi->phy_timing;
 
 	timing->lpx = (60 * data_rate_mhz / (8 * 1000)) + 1;
-- 
2.43.0



From maz at kernel.org  Wed Dec 20 05:58:02 2023
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 20 Dec 2023 13:58:02 +0000
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us in arch timer test
In-Reply-To: <CAJve8ona7g=LxW1YeRB_FqGodF973H=A3b2m8054gmzK=Z7_ww@mail.gmail.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
	<0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
	<8734vy832j.wl-maz@kernel.org>
	<CAJve8onc0WN5g98aOVBmJx15wFBAqfBKJ+ufoLY+oqYyVL+=3A@mail.gmail.com>
	<f98879dc24f948f7a8a7b5374a32bc04@kernel.org>
	<CAJve8ona7g=LxW1YeRB_FqGodF973H=A3b2m8054gmzK=Z7_ww@mail.gmail.com>
Message-ID: <87zfy5t1qt.wl-maz@kernel.org>

On Wed, 20 Dec 2023 13:51:24 +0000,
Haibo Xu <xiaobo55x at gmail.com> wrote:
> 
> On Wed, Dec 20, 2023 at 5:00?PM Marc Zyngier <maz at kernel.org> wrote:
> >
> > On 2023-12-20 06:50, Haibo Xu wrote:
> > > On Wed, Dec 20, 2023 at 2:22?AM Marc Zyngier <maz at kernel.org> wrote:
> > >>
> > >> On Tue, 12 Dec 2023 09:31:20 +0000,
> > >> Haibo Xu <haibo1.xu at intel.com> wrote:
> > >> > diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
> > >> > index 968257b893a7..b1d405e7157d 100644
> > >> > --- a/tools/testing/selftests/kvm/include/timer_test.h
> > >> > +++ b/tools/testing/selftests/kvm/include/timer_test.h
> > >> > @@ -22,6 +22,7 @@ struct test_args {
> > >> >       int nr_iter;
> > >> >       int timer_period_ms;
> > >> >       int migration_freq_ms;
> > >> > +     int timer_err_margin_us;
> > >>
> > >> ... except that you are storing it as a signed value. Some consistency
> > >> wouldn't hurt, really, and would avoid issues when passing large
> > >> values.
> > >>
> > >
> > > Yes, it's more proper to use an unsigned int for the non-negative error
> > > margin.
> > > Storing as signed here is just to keep the type consistent with that
> > > of timer_period_ms
> > > since there will be '+' operation in other places.
> > >
> > >         tools/testing/selftests/kvm/aarch64/arch_timer.c
> > >         /* Setup a timeout for the interrupt to arrive */
> > >          udelay(msecs_to_usecs(test_args.timer_period_ms) +
> > >              test_args.timer_err_margin_us);
> >
> > But that's exactly why using a signed quantity is wrong.
> > What does it mean to have a huge *negative* margin?
> >
> 
> Hi Marc,
> 
> I agree that negative values are meaningless for the margin.
> If I understand correctly, the negative margin should be filtered by
> assertion in atoi_non_negative().

No. Please.

atoi_non_negative() returns a uint32_t, which is what it should do.
The bug is squarely in the use of an 'int' to store such value, and it
is the *storage* that turns a positive value into a negative one.

	M.

-- 
Without deviation from the norm, progress is not possible.


From pbrobinson at gmail.com  Wed Dec 20 05:59:47 2023
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 20 Dec 2023 13:59:47 +0000
Subject: [PATCH 2/2] mmc: sdhci_omap: Fix TI SoC dependencies
In-Reply-To: <20231220135950.433588-1-pbrobinson@gmail.com>
References: <20231220135950.433588-1-pbrobinson@gmail.com>
Message-ID: <20231220135950.433588-2-pbrobinson@gmail.com>

The sdhci_omap is specific to  older TI SoCs, update the
dependencies for those SoCs and compile testing. While we're
at it update the text to reflect the wider range of
supported TI SoCS the driver now supports.

Fixes: 7d326930d352 ("mmc: sdhci-omap: Add OMAP SDHCI driver")
Signed-off-by: Peter Robinson <pbrobinson at gmail.com>
---
 drivers/mmc/host/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 24ce5576b61a..81f2c4e05287 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -1026,14 +1026,15 @@ config MMC_SDHCI_XENON
 
 config MMC_SDHCI_OMAP
 	tristate "TI SDHCI Controller Support"
+	depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
 	depends on MMC_SDHCI_PLTFM && OF
 	select THERMAL
 	imply TI_SOC_THERMAL
 	select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
 	help
 	  This selects the Secure Digital Host Controller Interface (SDHCI)
-	  support present in TI's DRA7 SOCs. The controller supports
-	  SD/MMC/SDIO devices.
+	  support present in TI's Keystone/OMAP2+/DRA7 SOCs. The controller
+	  supports SD/MMC/SDIO devices.
 
 	  If you have a controller with this interface, say Y or M here.
 
-- 
2.43.0



From pbrobinson at gmail.com  Wed Dec 20 05:59:46 2023
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 20 Dec 2023 13:59:46 +0000
Subject: [PATCH 1/2] mmc: sdhci_am654: Fix TI SoC dependencies
Message-ID: <20231220135950.433588-1-pbrobinson@gmail.com>

The sdhci_am654 is specific to recent TI SoCs, update the
dependencies for those SoCs and compile testing. While we're
at it update the text to reflect the wider range of
supported TI SoCS the driver now supports.

Fixes: 41fd4caeb00b ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver")
Signed-off-by: Peter Robinson <pbrobinson at gmail.com>
---
 drivers/mmc/host/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 58bd5fe4cd25..24ce5576b61a 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -1041,14 +1041,15 @@ config MMC_SDHCI_OMAP
 
 config MMC_SDHCI_AM654
 	tristate "Support for the SDHCI Controller in TI's AM654 SOCs"
+	depends on ARCH_K3 || COMPILE_TEST
 	depends on MMC_SDHCI_PLTFM && OF
 	select MMC_SDHCI_IO_ACCESSORS
 	select MMC_CQHCI
 	select REGMAP_MMIO
 	help
 	  This selects the Secure Digital Host Controller Interface (SDHCI)
-	  support present in TI's AM654 SOCs. The controller supports
-	  SD/MMC/SDIO devices.
+	  support present in TI's AM65x/AM64x/AM62x/J721E SOCs. The controller
+	  supports SD/MMC/SDIO devices.
 
 	  If you have a controller with this interface, say Y or M here.
 
-- 
2.43.0



From maz at kernel.org  Wed Dec 20 06:00:04 2023
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 20 Dec 2023 14:00:04 +0000
Subject: [PATCH v4 0/3] kvm: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
In-Reply-To: <20231218090719.22250-1-ankita@nvidia.com>
References: <20231218090719.22250-1-ankita@nvidia.com>
Message-ID: <87y1dpt1nf.wl-maz@kernel.org>

On Mon, 18 Dec 2023 09:07:16 +0000,
<ankita at nvidia.com> wrote:
> 
> From: Ankit Agrawal <ankita at nvidia.com>

[...]

> Applied over next-20231211

In the future, please post patches that are generated against a tag
from Linus' tree. The usual wisdom is to use -rc3 as the base.

	M.

-- 
Without deviation from the norm, progress is not possible.


From david at redhat.com  Wed Dec 20 06:00:21 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 15:00:21 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <ba6a5c11-34fb-40ca-b24a-f51a207464f2@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <db1be625-33e4-4d07-8500-3f7d3c8f9937@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
 <9f99a3ca-051e-4b1b-81e9-8456d8e422ad@redhat.com>
 <c1913fa2-d313-4f05-a649-da69b6d31d2a@arm.com>
 <c244707c-8c0c-4593-ab45-d8f165dbc5ee@redhat.com>
 <ba6a5c11-34fb-40ca-b24a-f51a207464f2@arm.com>
Message-ID: <5fcbf405-7e62-4b38-acc4-a9dd8cc91214@redhat.com>

[...]

>>>
>>
>> gcc version 13.2.1 20231011 (Red Hat 13.2.1-4) (GCC)
>>
>>  From Fedora 38. So "a bit" newer :P
>>
> 
> I'll retry with newer toolchain.
> 
> FWIW, with the code fix and the original compiler:
> 
> Fork, order-0, Apple M2:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      0.8% |
> | hugetlb-rmap-cleanups |       1.3% |      2.0% |
> | fork-batching         |       4.3% |      1.0% |
> 
> Fork, order-9, Apple M2:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      0.8% |
> | hugetlb-rmap-cleanups |       0.9% |      0.9% |
> | fork-batching         |     -37.3% |      1.0% |
> 
> Fork, order-0, Ampere Altra:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      0.7% |
> | hugetlb-rmap-cleanups |       3.2% |      0.7% |
> | fork-batching         |       5.5% |      1.1% |
> 
> Fork, order-9, Ampere Altra:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      0.1% |
> | hugetlb-rmap-cleanups |       0.5% |      0.1% |
> | fork-batching         |     -10.4% |      0.1% |
> 

I just gave it another quick benchmark run on that Intel system.

hugetlb-rmap-cleanups -> fork-batching

order-0: 0.014114 -> 0.013848

-1.9%

order-9: 0.014262 -> 0.009410

-34%

Note that I disable SMT and turbo, and pin the test to one CPU, to make 
the results as stable as possible. My kernel config has anything related 
to debugging disabled.

-- 
Cheers,

David / dhildenb



From quic_gkohli at quicinc.com  Wed Dec 20 06:01:42 2023
From: quic_gkohli at quicinc.com (Gaurav Kohli)
Date: Wed, 20 Dec 2023 19:31:42 +0530
Subject: [PATCH v4 1/2] iommu: Allow passing custom allocators to pgtable
 drivers
In-Reply-To: <ZYGcju8vsrf5YywX@8bytes.org>
References: <20231215084302.2484163-1-boris.brezillon@collabora.com>
 <ZYGcju8vsrf5YywX@8bytes.org>
Message-ID: <c2d608a8-6a43-bd30-c22b-0a5dd9eeac81@quicinc.com>

thanks for the reply, please consider these if possible.

On 12/19/2023 7:07 PM, Joerg Roedel wrote:
> On Fri, Dec 15, 2023 at 09:43:01AM +0100, Boris Brezillon wrote:
>> v4:
>> - Add Gaurav's R-b/T-b
> 
> Thanks for the re-post, but there is too much on-top (including merge
> commits) to replace these.
> 


From angelogioacchino.delregno at collabora.com  Wed Dec 20 06:02:33 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Wed, 20 Dec 2023 15:02:33 +0100
Subject: [PATCH v3 0/3] MediaTek clocks: Support mux indices list and 8195
 DP
In-Reply-To: <20231103102533.69280-1-angelogioacchino.delregno@collabora.com>
References: <20231103102533.69280-1-angelogioacchino.delregno@collabora.com>
Message-ID: <cbbcb801-916a-445d-8b36-60d470b61d46@collabora.com>

Il 03/11/23 11:25, AngeloGioacchino Del Regno ha scritto:
> Changes in v3:
>   - Rebased on next-20231025
>   - Added comment in the code explaining why the dp/edp parents lists
>     are split in one PLL per interface
>   - Added a commit performing the same reparenting on MT8188 as well
> 
> Changes in v2:
>   - Rebased on next-20231018
> 

Hello Stephen,

friendly ping for this fully reviewed/tested series :-)

Cheers,
Angelo

> This series adds support to specify custom parent indices for MediaTek
> MUX clocks, necessary to avoid setting the same parent PLL for MT8195's
> top_dp and top_edp clocks, solving DP+eDP concurrent output issues.
> 
> No fixes tags are provided as the clk-mux commit introduces new logic
> and the actual MT8195 fix depends on that.
> 
> This commit was tested on the Acer Tomato Chromebook (MT8195) with
> dual concurrent display outputs (internal eDP panel and TypeC->DP->HDMI
> adapter connected to Samsung UE40JU6400 4k TV); resolution switch on
> DP was also tested; eDP output is not paused and internal display keeps
> working as expected.
> 
> 
> After feedback on v1 of this series (effectively the same as v2, except
> for the rebase), I looked for an alternative solution with using
> clk_set_rate_exclusive() as proposed. Couldn't find any, as that still
> doesn't give any guarantee about selecting the same PLL that the driver
> was manipulating before setting the right divider MUX, hence that still
> wouldn't work correctly.
> 
> For more context, please look at the conversation at [1].
> 
> Cheers!
> 
> [1] https://lore.kernel.org/linux-arm-kernel/20230713072138.84117-1-angelogioacchino.delregno at collabora.com
> 
> AngeloGioacchino Del Regno (3):
>    clk: mediatek: clk-mux: Support custom parent indices for muxes
>    clk: mediatek: mt8195-topckgen: Refactor parents for top_dp/edp muxes
>    clk: mediatek: mt8188-topckgen: Refactor parents for top_dp/edp muxes
> 
>   drivers/clk/mediatek/clk-mt8188-topckgen.c | 27 +++++++-------
>   drivers/clk/mediatek/clk-mt8195-topckgen.c | 27 ++++++++++----
>   drivers/clk/mediatek/clk-mux.c             | 14 +++++++
>   drivers/clk/mediatek/clk-mux.h             | 43 ++++++++++++++++++++--
>   4 files changed, 86 insertions(+), 25 deletions(-)
> 





From maz at kernel.org  Wed Dec 20 06:12:12 2023
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 20 Dec 2023 14:12:12 +0000
Subject: [PATCH v4 1/3] kvm: arm64: introduce new flag for non-cacheable IO memory
In-Reply-To: <20231218090719.22250-2-ankita@nvidia.com>
References: <20231218090719.22250-1-ankita@nvidia.com>
	<20231218090719.22250-2-ankita@nvidia.com>
Message-ID: <87wmt9t137.wl-maz@kernel.org>

On Mon, 18 Dec 2023 09:07:17 +0000,
<ankita at nvidia.com> wrote:
> 
> From: Ankit Agrawal <ankita at nvidia.com>
> 
> For various reasons described in the cover letter, and primarily to

Well, the cover letter does not end-up in the git tree, so you must
put some actual information here.

> allow VM get IO memory with NORMALNC properties, it is desired
> to relax the KVM stage 2 device memory attributes from DEVICE_nGnRE
> to NormalNC. So set S2 PTE for IO memory as NORMAL_NC.
> 
> A Normal-NC flag is not present today. So add a new kvm_pgtable_prot
> (KVM_PGTABLE_PROT_NORMAL_NC) flag for it, along with its
> corresponding PTE value 0x5 (0b101) determined from [1].
> 
> Lastly, adapt the stage2 PTE property setter function
> (stage2_set_prot_attr) to handle the NormalNC attribute.
> 
> [1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf
> 
> Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
> Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> Tested-by: Ankit Agrawal <ankita at nvidia.com>
> ---
>  arch/arm64/include/asm/kvm_pgtable.h |  2 ++
>  arch/arm64/include/asm/memory.h      |  2 ++
>  arch/arm64/kvm/hyp/pgtable.c         | 13 +++++++++++--
>  3 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index cfdf40f734b1..19278dfe7978 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -197,6 +197,7 @@ enum kvm_pgtable_stage2_flags {
>   * @KVM_PGTABLE_PROT_W:		Write permission.
>   * @KVM_PGTABLE_PROT_R:		Read permission.
>   * @KVM_PGTABLE_PROT_DEVICE:	Device attributes.
> + * @KVM_PGTABLE_PROT_NORMAL_NC:	Normal noncacheable attributes.
>   * @KVM_PGTABLE_PROT_SW0:	Software bit 0.
>   * @KVM_PGTABLE_PROT_SW1:	Software bit 1.
>   * @KVM_PGTABLE_PROT_SW2:	Software bit 2.
> @@ -208,6 +209,7 @@ enum kvm_pgtable_prot {
>  	KVM_PGTABLE_PROT_R			= BIT(2),
>  
>  	KVM_PGTABLE_PROT_DEVICE			= BIT(3),
> +	KVM_PGTABLE_PROT_NORMAL_NC		= BIT(4),
>  
>  	KVM_PGTABLE_PROT_SW0			= BIT(55),
>  	KVM_PGTABLE_PROT_SW1			= BIT(56),
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index fde4186cc387..c247e5f29d5a 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -147,6 +147,7 @@
>   * Memory types for Stage-2 translation
>   */
>  #define MT_S2_NORMAL		0xf
> +#define MT_S2_NORMAL_NC		0x5
>  #define MT_S2_DEVICE_nGnRE	0x1
>  
>  /*
> @@ -154,6 +155,7 @@
>   * Stage-2 enforces Normal-WB and Device-nGnRE
>   */
>  #define MT_S2_FWB_NORMAL	6
> +#define MT_S2_FWB_NORMAL_NC	5
>  #define MT_S2_FWB_DEVICE_nGnRE	1
>  
>  #ifdef CONFIG_ARM64_4K_PAGES
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index c651df904fe3..0fff079a0ef3 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -718,10 +718,19 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p
>  				kvm_pte_t *ptep)
>  {
>  	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
> -	kvm_pte_t attr = device ? KVM_S2_MEMATTR(pgt, DEVICE_nGnRE) :
> -			    KVM_S2_MEMATTR(pgt, NORMAL);
> +	bool normal_nc = prot & KVM_PGTABLE_PROT_NORMAL_NC;
> +	kvm_pte_t attr;
>  	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
>  
> +	WARN_ON_ONCE(device && normal_nc);
> +
> +	if (device)
> +		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
> +	else if (normal_nc)
> +		attr = KVM_S2_MEMATTR(pgt, NORMAL_NC);
> +	else
> +		attr = KVM_S2_MEMATTR(pgt, NORMAL);
> +

This whole thing can be written a bit more elegantly:

	switch (prot & (KVM_PGTABLE_PROT_DEVICE |
			KVM_PGTABLE_PROT_NORMAL_NC)) {
	case 0:
		attr = KVM_S2_MEMATTR(pgt, NORMAL);
		break;
	case KVM_PGTABLE_PROT_DEVICE:
		if (prot & KVM_PGTABLE_PROT_X)
			return -EINVAL;
		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
		break;
	case KVM_PGTABLE_PROT_NORMAL_NC:
		attr = KVM_S2_MEMATTR(pgt, NORMAL_NC);
		break;
	default:
		WARN_ON_ONCE(1);
	}

and you can get rid of all of the boolean crud.

	M.

-- 
Without deviation from the norm, progress is not possible.


From maz at kernel.org  Wed Dec 20 06:16:40 2023
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 20 Dec 2023 14:16:40 +0000
Subject: [PATCH v4 2/3] kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices
In-Reply-To: <20231218090719.22250-3-ankita@nvidia.com>
References: <20231218090719.22250-1-ankita@nvidia.com>
	<20231218090719.22250-3-ankita@nvidia.com>
Message-ID: <87v88tt0vr.wl-maz@kernel.org>

On Mon, 18 Dec 2023 09:07:18 +0000,
<ankita at nvidia.com> wrote:
> 
> From: Ankit Agrawal <ankita at nvidia.com>
> 
> To provide VM with the ability to get device IO memory with NormalNC
> property, map device MMIO in KVM for ARM64 at stage2 as NormalNC.
> Having NormalNC S2 default puts guests in control (based on [1],
> "Combining stage 1 and stage 2 memory type attributes") of device
> MMIO regions memory mappings. The rules are summarized below:
> ([(S1) - stage1], [(S2) - stage 2])
> 
> S1           |  S2           | Result
> NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
> NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
> NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
> DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>
> 
> Generalizing this to non PCI devices may be problematic. E.g. GICv2
> vCPU interface, which is effectively a shared peripheral, can allow
> a guest to affect another guest's interrupt distribution. The issue
> may be solved by limiting the relaxation to mappings that have a user
> VMA. Still There is insufficient information and uncertainity in the
> behavior of non PCI driver. Hence caution is maintained and the change
> is restricted to the VFIO-PCI devices. PCIe on the other hand is safe
> because the PCI bridge does not generate errors, and thus do not cause
> uncontained failures.
> 
> A new flag VM_VFIO_ALLOW_WC to indicate KVM that the device is WC capable.
> KVM use this flag to activate the code.
> 
> This could be extended to other devices in the future once that
> is deemed safe.
> 
> [1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf
> 
> Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
> Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
> Acked-by: Jason Gunthorpe <jgg at nvidia.com>
> Tested-by: Ankit Agrawal <ankita at nvidia.com>
> ---
>  arch/arm64/kvm/mmu.c | 18 ++++++++++++++----
>  include/linux/mm.h   | 13 +++++++++++++
>  2 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index d14504821b79..e1e6847a793b 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1381,7 +1381,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	int ret = 0;
>  	bool write_fault, writable, force_pte = false;
>  	bool exec_fault, mte_allowed;
> -	bool device = false;
> +	bool device = false, vfio_allow_wc = false;
>  	unsigned long mmu_seq;
>  	struct kvm *kvm = vcpu->kvm;
>  	struct kvm_mmu_memory_cache *memcache = &vcpu->arch.mmu_page_cache;
> @@ -1472,6 +1472,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	gfn = fault_ipa >> PAGE_SHIFT;
>  	mte_allowed = kvm_vma_mte_allowed(vma);
>  
> +	vfio_allow_wc = (vma->vm_flags & VM_VFIO_ALLOW_WC);
> +
>  	/* Don't use the VMA after the unlock -- it may have vanished */
>  	vma = NULL;
>  
> @@ -1557,10 +1559,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	if (exec_fault)
>  		prot |= KVM_PGTABLE_PROT_X;
>  
> -	if (device)
> -		prot |= KVM_PGTABLE_PROT_DEVICE;
> -	else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
> +	if (device) {
> +		/*
> +		 * To provide VM with the ability to get device IO memory
> +		 * with NormalNC property, map device MMIO as NormalNC in S2.
> +		 */
> +		if (vfio_allow_wc)
> +			prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> +		else
> +			prot |= KVM_PGTABLE_PROT_DEVICE;
> +	} else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
>  		prot |= KVM_PGTABLE_PROT_X;
> +	}
>  
>  	/*
>  	 * Under the premise of getting a FSC_PERM fault, we just need to relax
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 2bea89dc0bdf..d2f0f969875c 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -391,6 +391,19 @@ extern unsigned int kobjsize(const void *objp);
>  # define VM_UFFD_MINOR		VM_NONE
>  #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
>  
> +/* This flag is used to connect VFIO to arch specific KVM code. It
> + * indicates that the memory under this VMA is safe for use with any
> + * non-cachable memory type inside KVM. Some VFIO devices, on some
> + * platforms, are thought to be unsafe and can cause machine crashes if
> + * KVM does not lock down the memory type.
> + */

Comment format.

> +#ifdef CONFIG_64BIT
> +#define VM_VFIO_ALLOW_WC_BIT	39
> +#define VM_VFIO_ALLOW_WC	BIT(VM_VFIO_ALLOW_WC_BIT)
> +#else
> +#define VM_VFIO_ALLOW_WC	VM_NONE
> +#endif
> +
>  /* Bits set in the VMA until the stack is in its final location */
>  #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)

The mm.h change should be standalone, separate from the KVM stuff.

	M.

-- 
Without deviation from the norm, progress is not possible.


From tudor.ambarus at linaro.org  Wed Dec 20 06:22:46 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Wed, 20 Dec 2023 14:22:46 +0000
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock
 as critical
In-Reply-To: <CAPLW+4mm8LG=wtJHT5EYhGGiU72qVe70vJv6-JkEGepiXFjcvA@mail.gmail.com>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-8-tudor.ambarus@linaro.org>
 <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>
 <f3d61c49-1a46-476c-b7a5-6cc6a06a33ed@linaro.org>
 <CAPLW+4=tyr8Pcoe6Wm0Wtmkk4udDpuAiOKy7+C+Fwa6mvt3VoQ@mail.gmail.com>
 <5de5cddd-2bab-4408-b31f-f48bef98f14c@linaro.org>
 <CAPLW+4n-S2jaVPUwKTFC_iabnDd_qDV=ZubMqhz-X9XiZzzJow@mail.gmail.com>
 <4ba80e1e-8fec-4fd2-9140-6da006c9d5f5@linaro.org>
 <CAPLW+4mm8LG=wtJHT5EYhGGiU72qVe70vJv6-JkEGepiXFjcvA@mail.gmail.com>
Message-ID: <c3db7b3e-814c-4afc-b67a-112bce3d38ec@linaro.org>

Hi, Sam!

On 12/19/23 17:31, Sam Protsenko wrote:
> On Tue, Dec 19, 2023 at 10:47?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>
>> Hi, Sam!
>>
>> On 12/14/23 16:43, Sam Protsenko wrote:
>>> On Thu, Dec 14, 2023 at 10:15?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 12/14/23 16:09, Sam Protsenko wrote:
>>>>> On Thu, Dec 14, 2023 at 10:01?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/14/23 15:37, Sam Protsenko wrote:
>>>>>>> On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>>>>>>>>
>>>>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>>>>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>>>>>>>> which then makes the system hang. To prevent this, mark
>>>>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>>>>>>>> accordingly when tested.
>>>>>>>>
>>>>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>>>>>>>> ---
>>>>>>>>  drivers/clk/samsung/clk-gs101.c | 2 +-
>>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>>>>>>>> index 3d194520b05e..08d80fca9cd6 100644
>>>>>>>> --- a/drivers/clk/samsung/clk-gs101.c
>>>>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
>>>>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>>>>>>>              "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>>>>>>>              21, 0, 0),
>>>>>>>>         GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>>>>>>>> -            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>>>>>>>> +            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>>>>>>>
>>>>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
>>>>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
>>>>>>> usually should be avoided. Is it possible that the system freezes
>>>>>>> because some other clock (which depends on peric0_ip) gets disabled as
>>>>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
>>>>>>> is not implemented yet in the clock driver? Just looks weird to me
>>>>>>> that the system hangs because of CMU IP clock disablement. It's
>>>>>>> usually something much more specific.
>>>>>>
>>>>>> The system hang happened when I tested USI8 in I2C configuration with an
>>>>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
>>>>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
>>>>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
>>>>>> disablement which makes the system hang. Either marking the CMU_TOP gate
>>>>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
>>>>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>>>>>>
>>>>>
>>>>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
>>>>
>>>> yes.
>>
>> I checked again all the clocks. I implemented all but one, the one
>> defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
>> don't have any reference on how it should be defined so I won't touch it
>> yet. But I have some good news too, see below.
>>
>>>
>>> Ok. Are there any other CMUs (perhaps not implemented yet) which
>>> consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
>>> clocks derived from it? If so, is there a chance some particular leaf
>>> clock in those CMUs actually renders the system frozen when disabled
>>> as a consequence of disabling PERIC0_IP, and would explain better why
>>> the freeze happens?
>>>
>>> For now I think it's ok to have that CLK_IS_CRITICAL flag here,
>>> because as you said you implemented all clocks in this CMU and neither
>>> of those looks like a critical one. But I'd advice to add a TODO
>>> comment saying it's probably a temporary solution before actual leaf
>>> clock which leads to freeze is identified (which probably resides in
>>> some other not implemented yet CMU).
>>>
>>>>
>>>>> is a chance some other leaf clock (which is not implemented yet in
>>>>> your driver) gets disabled as a result of PERIC0_IP disablement, which
>>>>> might actually lead to that hang you observe. Usually it's some
>>>>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
>>>>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
>>>>> and the corresponding comments I left there, maybe it'll give you more
>>>>> particular idea about what to look for. Yes, making the whole CMU
>>>>> always running without understanding why (i.e. because of which
>>>>> particular leaf clock) might not be the best way of handling this
>>>>
>>>> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
>>>
>>> That's not a root cause here. And I think PERIC0_IP is neither.
>>>
>>
>> you were right!
>>>>
>>>>> issue. I might be mistaken, but at least please check if you
>>>>> implemented all clocks for PERIC0 first and if making some meaningful
>>>>> leaf clock critical makes more sense.
>>>>>
>>
>> I determined which leaf clocks shall be marked as critical. I enabled
>> the debugfs clock write access. Then I made sure that the parents of the
>> PERIC0 CMU have at least one user so that they don't get disabled after
>> an enable-disable sequence on a leaf clock. The I took all the PERIC0
>> gate clocks and enabled and disabled them one by one. Whichever hang the
>> system when the clock was disabled was marked as critical. The list of
>> critical leaf clocks is as following:
>>
> 
> Nice! I used somehow similar procedure for clk-exynos850, doing
> basically the same thing, but in core clock driver code.
> 
>> "gout_peric0_peric0_cmu_peric0_pclk",
>> "gout_peric0_lhm_axi_p_peric0_i_clk",
>> "gout_peric0_peric0_top1_ipclk_0",
>> "gout_peric0_peric0_top1_pclk_0".
>>
>> I'll update v2 with this instead. Thanks for the help, Sam!
> 
> Glad you weren't discouraged by my meticulousness :) In clk-exynos850
> I usually used CLK_IGNORE_UNUSED for clocks like XXX_CMU_XXX (in your
> case it's PERIC0_CMU_PERIC0), with a corresponding comment. Those
> clocks usually can be used to disable the bus clock for corresponding
> CMU IP-core (in your case CMU_PERIC0), which makes it impossible to
> access the registers from that CMU block, as its register interface is
> not clocked anymore. Guess I saw something similar in Exynos5433 or
> Exynos7 clk drivers, or maybe Sylwester or Krzysztof told me to do so
> -- don't really remember. For AXI clock it also seems logical to keep
> it running (AXI bus might be used for GIC and memory). But again,
> maybe CLK_IGNORE_UNUSED flag would be more appropriate that
> CLK_IS_CRITICAL? For the last two clocks -- it's hard to tell what
> exactly they do. Is TOP1 some other CMU or block name, and is there
> any further users for those clocks?
> 
> Anyways, if you are working on v2, please consider doing next two
> things while at it:
> 
>   1. For each critical clock: add corresponding comment explaining why
> it's marked so

Will do.

>   2. Consider using CLK_IGNORE_UNUSED instead of CLK_IS_CRITICAL when
> appropriate; both have their use in different cases
> 
> Btw, if you check other Exynos clk drivers, there is a lot of examples
> for flags like those.
> 
Thanks for the feedback, it's educative.

I played a little with the clk debugfs and I think all should be marked
as critical. What I did was to make sure that their parents are enabled
already and then I enabled and disabled each. Each time I disabled one
of them the system hung. Thus in case they will be used, if one disable
them on an error path, it will hang the system. We can't disable them at
suspend either. Thus I propose to keep them as critical.

Thanks!
ta


From sean at mess.org  Wed Dec 20 06:24:25 2023
From: sean at mess.org (Sean Young)
Date: Wed, 20 Dec 2023 14:24:25 +0000
Subject: [PATCH v11] pwm: bcm2835: Allow PWM driver to be used in atomic context
Message-ID: <20231220142426.1275052-1-sean@mess.org>

clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
rate changes using clk_rate_exclusive_get().

Signed-off-by: Sean Young <sean at mess.org>
Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
---
 drivers/pwm/pwm-bcm2835.c | 38 +++++++++++++++++++++++++++++---------
 1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index ab30667f4f95..307c0bd5f885 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -28,6 +28,7 @@ struct bcm2835_pwm {
 	struct device *dev;
 	void __iomem *base;
 	struct clk *clk;
+	unsigned long rate;
 };
 
 static inline struct bcm2835_pwm *to_bcm2835_pwm(struct pwm_chip *chip)
@@ -63,17 +64,11 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 {
 
 	struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
-	unsigned long rate = clk_get_rate(pc->clk);
 	unsigned long long period_cycles;
 	u64 max_period;
 
 	u32 val;
 
-	if (!rate) {
-		dev_err(pc->dev, "failed to get clock rate\n");
-		return -EINVAL;
-	}
-
 	/*
 	 * period_cycles must be a 32 bit value, so period * rate / NSEC_PER_SEC
 	 * must be <= U32_MAX. As U32_MAX * NSEC_PER_SEC < U64_MAX the
@@ -88,13 +83,13 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * <=> period < ((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate
 	 * <=> period <= ceil((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate) - 1
 	 */
-	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, rate) - 1;
+	max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, pc->rate) - 1;
 
 	if (state->period > max_period)
 		return -EINVAL;
 
 	/* set period */
-	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * rate, NSEC_PER_SEC);
+	period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * pc->rate, NSEC_PER_SEC);
 
 	/* don't accept a period that is too small */
 	if (period_cycles < PERIOD_MIN)
@@ -103,7 +98,7 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	writel(period_cycles, pc->base + PERIOD(pwm->hwpwm));
 
 	/* set duty cycle */
-	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * rate, NSEC_PER_SEC);
+	val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * pc->rate, NSEC_PER_SEC);
 	writel(val, pc->base + DUTY(pwm->hwpwm));
 
 	/* set polarity */
@@ -131,6 +126,13 @@ static const struct pwm_ops bcm2835_pwm_ops = {
 	.apply = bcm2835_pwm_apply,
 };
 
+static void devm_clk_rate_exclusive_put(void *data)
+{
+	struct clk *clk = data;
+
+	clk_rate_exclusive_put(clk);
+}
+
 static int bcm2835_pwm_probe(struct platform_device *pdev)
 {
 	struct bcm2835_pwm *pc;
@@ -151,8 +153,26 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
 				     "clock not found\n");
 
+	ret = clk_rate_exclusive_get(pc->clk);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret,
+				     "fail to get exclusive rate\n");
+
+	ret = devm_add_action_or_reset(&pdev->dev, devm_clk_rate_exclusive_put,
+				       pc->clk);
+	if (ret) {
+		clk_rate_exclusive_put(pc->clk);
+		return ret;
+	}
+
+	pc->rate = clk_get_rate(pc->clk);
+	if (!pc->rate)
+		return dev_err_probe(&pdev->dev, -EINVAL,
+				     "failed to get clock rate\n");
+
 	pc->chip.dev = &pdev->dev;
 	pc->chip.ops = &bcm2835_pwm_ops;
+	pc->chip.atomic = true;
 	pc->chip.npwm = 2;
 
 	platform_set_drvdata(pdev, pc);
-- 
2.43.0



From mani at kernel.org  Wed Dec 20 06:34:22 2023
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Wed, 20 Dec 2023 20:04:22 +0530
Subject: [PATCH] ufs: mcq: Adding a function for MCQ enable
In-Reply-To: <20231220052737.19857-1-cw9316.lee@samsung.com>
References: <CGME20231220052749epcas1p3b90f6c03110ff5f63ffc547ef0f35907@epcas1p3.samsung.com>
 <20231220052737.19857-1-cw9316.lee@samsung.com>
Message-ID: <20231220143422.GF3544@thinkpad>

On Wed, Dec 20, 2023 at 02:27:37PM +0900, Chanwoo Lee wrote:
> From: ChanWoo Lee <cw9316.lee at samsung.com>
> 
> The REG_UFS_MEM_CFG register is too general(broad)
> and it is difficult to know the meaning of only values of 0x1 and 0x2.
> So far, comments were required.
> 
> Therefore, I have added new functions and defines
> to improve code readability/reusability.
> 
> Signed-off-by: ChanWoo Lee <cw9316.lee at samsung.com>
> ---
>  drivers/ufs/core/ufs-mcq.c      | 10 +++++++++-
>  drivers/ufs/core/ufshcd.c       |  5 +----
>  drivers/ufs/host/ufs-mediatek.c |  4 +---
>  include/ufs/ufshcd.h            |  1 +
>  include/ufs/ufshci.h            |  4 ++++
>  5 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-mcq.c
> index 0787456c2b89..a34ef3aac540 100644
> --- a/drivers/ufs/core/ufs-mcq.c
> +++ b/drivers/ufs/core/ufs-mcq.c
> @@ -394,11 +394,19 @@ EXPORT_SYMBOL_GPL(ufshcd_mcq_make_queues_operational);
>  
>  void ufshcd_mcq_enable_esi(struct ufs_hba *hba)
>  {
> -	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x2,
> +	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | ESI_ENABLE,
>  		      REG_UFS_MEM_CFG);

This change should be a separate patch.

>  }
>  EXPORT_SYMBOL_GPL(ufshcd_mcq_enable_esi);
>  
> +void ufshcd_mcq_enable(struct ufs_hba *hba)
> +{
> +	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | MCQ_MODE_SELECT,
> +		      REG_UFS_MEM_CFG);

Use ufshcd_rmwl().

> +	hba->mcq_enabled = true;
> +}
> +EXPORT_SYMBOL_GPL(ufshcd_mcq_enable);
> +
>  void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg *msg)
>  {
>  	ufshcd_writel(hba, msg->address_lo, REG_UFS_ESILBA);
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index ae9936fc6ffb..8195e01e7a3f 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -8723,10 +8723,7 @@ static void ufshcd_config_mcq(struct ufs_hba *hba)
>  	hba->host->can_queue = hba->nutrs - UFSHCD_NUM_RESERVED;
>  	hba->reserved_slot = hba->nutrs - UFSHCD_NUM_RESERVED;
>  
> -	/* Select MCQ mode */
> -	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
> -		      REG_UFS_MEM_CFG);
> -	hba->mcq_enabled = true;
> +	ufshcd_mcq_enable(hba);
>  
>  	dev_info(hba->dev, "MCQ configured, nr_queues=%d, io_queues=%d, read_queue=%d, poll_queues=%d, queue_depth=%d\n",
>  		 hba->nr_hw_queues, hba->nr_queues[HCTX_TYPE_DEFAULT],
> diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
> index fc61790d289b..1048add66419 100644
> --- a/drivers/ufs/host/ufs-mediatek.c
> +++ b/drivers/ufs/host/ufs-mediatek.c
> @@ -1219,9 +1219,7 @@ static int ufs_mtk_link_set_hpm(struct ufs_hba *hba)
>  		ufs_mtk_config_mcq(hba, false);
>  		ufshcd_mcq_make_queues_operational(hba);
>  		ufshcd_mcq_config_mac(hba, hba->nutrs);
> -		/* Enable MCQ mode */
> -		ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
> -			      REG_UFS_MEM_CFG);
> +		ufshcd_mcq_enable(hba);

hba->mcq_enabled flag will be set now which is not done previously.

>  	}
>  
>  	if (err)
> diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
> index d862c8ddce03..a96c45fa4b4b 100644
> --- a/include/ufs/ufshcd.h
> +++ b/include/ufs/ufshcd.h
> @@ -1257,6 +1257,7 @@ unsigned long ufshcd_mcq_poll_cqe_lock(struct ufs_hba *hba,
>  					 struct ufs_hw_queue *hwq);
>  void ufshcd_mcq_make_queues_operational(struct ufs_hba *hba);
>  void ufshcd_mcq_enable_esi(struct ufs_hba *hba);
> +void ufshcd_mcq_enable(struct ufs_hba *hba);
>  void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg *msg);
>  
>  int ufshcd_opp_config_clks(struct device *dev, struct opp_table *opp_table,
> diff --git a/include/ufs/ufshci.h b/include/ufs/ufshci.h
> index d5accacae6bc..e669fad11fd4 100644
> --- a/include/ufs/ufshci.h
> +++ b/include/ufs/ufshci.h
> @@ -282,6 +282,10 @@ enum {
>  /* UTMRLRSR - UTP Task Management Request Run-Stop Register 80h */
>  #define UTP_TASK_REQ_LIST_RUN_STOP_BIT		0x1
>  
> +/* REG_UFS_MEM_CFG - Global Config Registers 300h */
> +#define MCQ_MODE_SELECT 	0x1
> +#define ESI_ENABLE		0x2

Use BIT() macros.

- Mani

> +
>  /* CQISy - CQ y Interrupt Status Register  */
>  #define UFSHCD_MCQ_CQIS_TAIL_ENT_PUSH_STS	0x1
>  
> -- 
> 2.29.0
> 

-- 
????????? ????????


From tanmay.shah at amd.com  Wed Dec 20 06:45:01 2023
From: tanmay.shah at amd.com (Tanmay Shah)
Date: Wed, 20 Dec 2023 08:45:01 -0600
Subject: [PATCH v8 2/3] dts: zynqmp: add properties for TCM in remoteproc
In-Reply-To: <6ab19ceb-38ed-4e4c-aabc-a959bc123cf2@amd.com>
References: <20231215235725.1247350-1-tanmay.shah@amd.com>
 <20231215235725.1247350-3-tanmay.shah@amd.com>
 <6ab19ceb-38ed-4e4c-aabc-a959bc123cf2@amd.com>
Message-ID: <e9e9777d-f8c1-48cd-b433-0292c77f6d57@amd.com>


On 12/20/23 7:14 AM, Michal Simek wrote:
>
> On 12/16/23 00:57, Tanmay Shah wrote:
> > Add properties as per new bindings in zynqmp remoteproc node
> > to represent TCM address and size.
> > 
> > This patch also adds alternative remoteproc node to represent
> > remoteproc cluster in split mode. By default lockstep mode is
> > enabled and users should disable it before using split mode
> > dts. Both device-tree nodes can't be used simultaneously one
> > of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
> > remoteproc split mode dts node is enabled and lockstep mode
> > dts is disabled.
> > 
> > Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> > ---
> >   .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |  8 +++
> >   arch/arm64/boot/dts/xilinx/zynqmp.dtsi        | 60 +++++++++++++++++--
> >   2 files changed, 63 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
> > index c8f71a1aec89..495ca94b45db 100644
> > --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
> > +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
> > @@ -14,6 +14,14 @@ / {
> >   	compatible = "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102", "xlnx,zynqmp";
> >   };
> >   
> > +&rproc_split {
> > +	status = "okay";
> > +};
> > +
> > +&rproc_lockstep {
> > +	status = "disabled";
> > +};
> > +
> >   &eeprom {
> >   	#address-cells = <1>;
> >   	#size-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > index b61fc99cd911..602e6aba7ac5 100644
> > --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > @@ -247,19 +247,69 @@ fpga_full: fpga-full {
> >   		ranges;
> >   	};
> >   
> > -	remoteproc {
> > +	rproc_lockstep: remoteproc at ffe00000 {
> >   		compatible = "xlnx,zynqmp-r5fss";
> >   		xlnx,cluster-mode = <1>;
> >   
> > -		r5f-0 {
> > +		#address-cells = <2>;
> > +		#size-cells = <2>;
> > +
> > +		ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x20000>,
> > +			 <0x0 0x20000 0x0 0xffe20000 0x0 0x20000>,
> > +			 <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
> > +			 <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
> > +
> > +		r5f at 0 {
> > +			compatible = "xlnx,zynqmp-r5f";
> > +			reg = <0x0 0x0 0x0 0x20000>, <0x0 0x20000 0x0 0x20000>;
> > +			reg-names = "atcm", "btcm";
> > +			power-domains = <&zynqmp_firmware PD_RPU_0>,
> > +					<&zynqmp_firmware PD_R5_0_ATCM>,
> > +					<&zynqmp_firmware PD_R5_0_BTCM>;
> > +			memory-region = <&rproc_0_fw_image>;
> > +		};
> > +
> > +		r5f at 1 {
> > +			compatible = "xlnx,zynqmp-r5f";
> > +			reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
> > +			reg-names = "atcm", "btcm";
> > +			power-domains = <&zynqmp_firmware PD_RPU_1>,
> > +					<&zynqmp_firmware PD_R5_1_ATCM>,
> > +					<&zynqmp_firmware PD_R5_1_BTCM>;
> > +			memory-region = <&rproc_1_fw_image>;
> > +		};
> > +	};
> > +
> > +	rproc_split: remoteproc-split at ffe00000 {
> > +		status = "disabled";
> > +		compatible = "xlnx,zynqmp-r5fss";
> > +		xlnx,cluster-mode = <0>;
> > +
> > +		#address-cells = <2>;
> > +		#size-cells = <2>;
> > +
> > +		ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
> > +			 <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
> > +			 <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
> > +			 <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
> > +
> > +		r5f at 0 {
> >   			compatible = "xlnx,zynqmp-r5f";
> > -			power-domains = <&zynqmp_firmware PD_RPU_0>;
> > +			reg = <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0x0 0x10000>;
> > +			reg-names = "atcm", "btcm";
> > +			power-domains = <&zynqmp_firmware PD_RPU_0>,
> > +					<&zynqmp_firmware PD_R5_0_ATCM>,
> > +					<&zynqmp_firmware PD_R5_0_BTCM>;
> >   			memory-region = <&rproc_0_fw_image>;
> >   		};
> >   
> > -		r5f-1 {
> > +		r5f at 1 {
> >   			compatible = "xlnx,zynqmp-r5f";
> > -			power-domains = <&zynqmp_firmware PD_RPU_1>;
> > +			reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
> > +			reg-names = "atcm", "btcm";
> > +			power-domains = <&zynqmp_firmware PD_RPU_1>,
> > +					<&zynqmp_firmware PD_R5_1_ATCM>,
> > +					<&zynqmp_firmware PD_R5_1_BTCM>;
> >   			memory-region = <&rproc_1_fw_image>;
> >   		};
> >   	};
>
> Acked-by: Michal Simek <michal.simek at amd.com>
>
> Let me know if you want me to take this via my tree.

Hi Michal,

Thanks for reviews. I will ping you once driver changes are approved.

Or Mathieu can take this in remoteproc tree, either way is fine.

But I would like to wait till driver changes are approved.

Tanmay

>
> Thanks,
> Michal


From sumang at marvell.com  Wed Dec 20 06:46:09 2023
From: sumang at marvell.com (Suman Ghosh)
Date: Wed, 20 Dec 2023 14:46:09 +0000
Subject: [EXT] [PATCH net-next] net: stmmac: Fix ethool link settings ops
 for integrated PCS
In-Reply-To: <20231218135032.27209-1-quic_snehshah@quicinc.com>
References: <20231218135032.27209-1-quic_snehshah@quicinc.com>
Message-ID: <SJ0PR18MB5216E4E90502F0B37602B06CDB96A@SJ0PR18MB5216.namprd18.prod.outlook.com>

> 	struct stmmac_priv *priv = netdev_priv(dev);
>
>-	if (priv->hw->pcs & STMMAC_PCS_RGMII ||
>-	    priv->hw->pcs & STMMAC_PCS_SGMII) {
>+	if (!(priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS) &&
[Suman] A personal preference here, I think the code will be more readable if we handle the !if condition @ the beginning. Something like,
if (priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS ||
	!(priv->hw->pcs & STMMAC_PCS_RGMII) || !(priv->hw->pcs & STMMAC_PCS_RGMII))
	return phylink_ethtool_ksettings_get(priv->phylink, cmd);

and keep the rest of the code without any check. But it is up-to you.

>+	    (priv->hw->pcs & STMMAC_PCS_RGMII ||
>+	     priv->hw->pcs & STMMAC_PCS_SGMII)) {
> 		struct rgmii_adv adv;
> 		u32 supported, advertising, lp_advertising;
>
>@@ -397,8 +398,9 @@ stmmac_ethtool_set_link_ksettings(struct net_device
>*dev,  {
> 	struct stmmac_priv *priv = netdev_priv(dev);
>
>-	if (priv->hw->pcs & STMMAC_PCS_RGMII ||
>-	    priv->hw->pcs & STMMAC_PCS_SGMII) {
>+	if (!(priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS) &&
>+	    (priv->hw->pcs & STMMAC_PCS_RGMII ||
>+	     priv->hw->pcs & STMMAC_PCS_SGMII)) {
> 		/* Only support ANE */
> 		if (cmd->base.autoneg != AUTONEG_ENABLE)
> 			return -EINVAL;
>--
>2.17.1
>



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:18 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:18 +0100
Subject: [PATCH v3 02/10] counter: stm32-timer-cnt: rename counter
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-3-fabrice.gasnier@foss.st.com>

The STM32 timer may count on various sources or channels. The counter
isn't specifically counting on channe1 1. So rename it to avoid a
confusion.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
 drivers/counter/stm32-timer-cnt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index 36d812ddf162..668e9d1061d3 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -302,7 +302,7 @@ static struct counter_synapse stm32_count_synapses[] = {
 
 static struct counter_count stm32_counts = {
 	.id = 0,
-	.name = "Channel 1 Count",
+	.name = "STM32 Timer Counter",
 	.functions_list = stm32_count_functions,
 	.num_functions = ARRAY_SIZE(stm32_count_functions),
 	.synapses = stm32_count_synapses,
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:17 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:17 +0100
Subject: [PATCH v3 01/10] counter: stm32-timer-cnt: rename quadrature signal
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-2-fabrice.gasnier@foss.st.com>

Drop the Quadrature convention in the signal name. On stm32-timer:
- Quadrature A signal corresponds to timer input ch1, hence "Channel 1"
- Quadrature B signal corresponds to timer input ch2, hence "Channel 2".
So name these signals after their channel. I suspect it referred to the
(unique) quadrature counter support earlier, but the physical input
really is CH1/CH2. This will be easier to support other counter modes.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
Changes in v2:
- Drop the "Quadrature" convention from the signal name, as suggested by
  William
---
 drivers/counter/stm32-timer-cnt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index 6206d2dc3d47..36d812ddf162 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -279,11 +279,11 @@ static const struct counter_ops stm32_timer_cnt_ops = {
 static struct counter_signal stm32_signals[] = {
 	{
 		.id = 0,
-		.name = "Channel 1 Quadrature A"
+		.name = "Channel 1"
 	},
 	{
 		.id = 1,
-		.name = "Channel 1 Quadrature B"
+		.name = "Channel 2"
 	}
 };
 
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:16 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:16 +0100
Subject: [PATCH v3 00/10] counter: Add stm32 timer events support
Message-ID: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>

Improves the stm32 timer counter driver by introducing new signals,
e.g. counting frequency, and missing channels.

It also adds support for interrupt based events using the chrdev interface.
Two event types are added in this series: overflows and capture.

Up to now, stm32 timer counter driver focused mainly on quadrature
encoder feature on channel 1 & 2. It was limited to timers that has
the HW quadrature encoder.

With this series, all timer instances can be enabled for:
- Quadrature encoder on channel 1 and channel 2 (when supported in HW)
- Simple counting on internal clock
- Capture counter value when rising and falling edges are observed at
  channel 1 to channel 4 input (number of channels varies depending on
  the timer instance used)
- Push overflow and/or capture events through the chardev interface

Changes in V3:
- This series has been split [1] and renamed.
[1] https://lore.kernel.org/lkml/20230922143920.3144249-1-fabrice.gasnier at foss.st.com/
- Watch events tool patch applied, hence dropped from this series
- Refactor / split several patches
- Keep original signals order, to avoid breaking existing user space
- Don't adjust number of signals: adopt static configuration. rely on
  error mechanism to manage diversity across STM32 Timers instances.

Changes in v2:
- counter fix and improvement patch applied, hence dropped in v2 series
- mfd patch applied, hence dropped in v2 series
- revisit watch events tool (mainly command line interface)
- add one patch to rename STM32 Timer counter
- various review comments from v1

Fabrice Gasnier (10):
  counter: stm32-timer-cnt: rename quadrature signal
  counter: stm32-timer-cnt: rename counter
  counter: stm32-timer-cnt: adopt signal definitions
  counter: stm32-timer-cnt: introduce clock signal
  counter: stm32-timer-cnt: add counter prescaler extension
  counter: stm32-timer-cnt: add checks on quadrature encoder capability
  counter: stm32-timer-cnt: introduce channels
  counter: stm32-timer-cnt: probe number of channels from registers
  counter: stm32-timer-cnt: add support for overflow events
  counter: stm32-timer-cnt: add support for capture events

 drivers/counter/stm32-timer-cnt.c | 455 +++++++++++++++++++++++++++++-
 include/linux/mfd/stm32-timers.h  |  13 +
 2 files changed, 454 insertions(+), 14 deletions(-)

-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:20 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:20 +0100
Subject: [PATCH v3 04/10] counter: stm32-timer-cnt: introduce clock signal
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-5-fabrice.gasnier@foss.st.com>

Introduce the internal clock signal, used to count when in simple rising
function. Also add the "frequency" extension to the clock signal.

With this patch, signal action reports a consistent state when "increase"
function is used, and the counting frequency:
    $ echo increase > function
    $ grep -H "" signal*_action
    signal0_action:none
    signal1_action:none
    signal2_action:rising edge
    $ echo 1 > enable
    $ cat count
    25425
    $ cat count
    44439
    $ cat ../signal2/frequency
    208877930

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
Changes in v3:
- split the patch in 3 parts: signal definition becomes a pre-cursor patch,
  add the "prescaler" extension in its own patch.
- Move the clock signal at the end of the signals array, so existing
  userspace programs that may rely on signal0 being "Channel 1" for
  example will remain compatible.
---
 drivers/counter/stm32-timer-cnt.c | 53 ++++++++++++++++++++++++++++---
 1 file changed, 49 insertions(+), 4 deletions(-)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index c34747d7857e..21a9c20c4281 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -23,6 +23,7 @@
 
 #define STM32_CH1_SIG		0
 #define STM32_CH2_SIG		1
+#define STM32_CLOCK_SIG		2
 
 struct stm32_timer_regs {
 	u32 cr1;
@@ -226,6 +227,10 @@ static struct counter_comp stm32_count_ext[] = {
 			     stm32_count_ceiling_write),
 };
 
+static const enum counter_synapse_action stm32_clock_synapse_actions[] = {
+	COUNTER_SYNAPSE_ACTION_RISING_EDGE,
+};
+
 static const enum counter_synapse_action stm32_synapse_actions[] = {
 	COUNTER_SYNAPSE_ACTION_NONE,
 	COUNTER_SYNAPSE_ACTION_BOTH_EDGES
@@ -246,7 +251,10 @@ static int stm32_action_read(struct counter_device *counter,
 	switch (function) {
 	case COUNTER_FUNCTION_INCREASE:
 		/* counts on internal clock when CEN=1 */
-		*action = COUNTER_SYNAPSE_ACTION_NONE;
+		if (synapse->signal->id == STM32_CLOCK_SIG)
+			*action = COUNTER_SYNAPSE_ACTION_RISING_EDGE;
+		else
+			*action = COUNTER_SYNAPSE_ACTION_NONE;
 		return 0;
 	case COUNTER_FUNCTION_QUADRATURE_X2_A:
 		/* counts up/down on TI1FP1 edge depending on TI2FP2 level */
@@ -264,7 +272,10 @@ static int stm32_action_read(struct counter_device *counter,
 		return 0;
 	case COUNTER_FUNCTION_QUADRATURE_X4:
 		/* counts up/down on both TI1FP1 and TI2FP2 edges */
-		*action = COUNTER_SYNAPSE_ACTION_BOTH_EDGES;
+		if (synapse->signal->id == STM32_CH1_SIG || synapse->signal->id == STM32_CH2_SIG)
+			*action = COUNTER_SYNAPSE_ACTION_BOTH_EDGES;
+		else
+			*action = COUNTER_SYNAPSE_ACTION_NONE;
 		return 0;
 	default:
 		return -EINVAL;
@@ -279,7 +290,30 @@ static const struct counter_ops stm32_timer_cnt_ops = {
 	.action_read = stm32_action_read,
 };
 
+static int stm32_count_clk_get_freq(struct counter_device *counter,
+				    struct counter_signal *signal, u64 *freq)
+{
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+
+	*freq = clk_get_rate(priv->clk);
+
+	return 0;
+}
+
+static struct counter_comp stm32_count_clock_ext[] = {
+	COUNTER_COMP_SIGNAL_U64("frequency", stm32_count_clk_get_freq, NULL),
+};
+
 static struct counter_signal stm32_signals[] = {
+	/*
+	 * Need to declare all the signals as a static array, and keep the signals order here,
+	 * even if they're unused or unexisting on some timer instances. It's an abstraction,
+	 * e.g. high level view of the counter features.
+	 *
+	 * Userspace programs may rely on signal0 to be "Channel 1", signal1 to be "Channel 2",
+	 * and so on. When a signal is unexisting, the COUNTER_SYNAPSE_ACTION_NONE can be used,
+	 * to indicate that a signal doesn't affect the counter.
+	 */
 	{
 		.id = STM32_CH1_SIG,
 		.name = "Channel 1"
@@ -287,7 +321,13 @@ static struct counter_signal stm32_signals[] = {
 	{
 		.id = STM32_CH2_SIG,
 		.name = "Channel 2"
-	}
+	},
+	{
+		.id = STM32_CLOCK_SIG,
+		.name = "Clock Signal",
+		.ext = stm32_count_clock_ext,
+		.num_ext = ARRAY_SIZE(stm32_count_clock_ext),
+	},
 };
 
 static struct counter_synapse stm32_count_synapses[] = {
@@ -300,7 +340,12 @@ static struct counter_synapse stm32_count_synapses[] = {
 		.actions_list = stm32_synapse_actions,
 		.num_actions = ARRAY_SIZE(stm32_synapse_actions),
 		.signal = &stm32_signals[STM32_CH2_SIG]
-	}
+	},
+	{
+		.actions_list = stm32_clock_synapse_actions,
+		.num_actions = ARRAY_SIZE(stm32_clock_synapse_actions),
+		.signal = &stm32_signals[STM32_CLOCK_SIG]
+	},
 };
 
 static struct counter_count stm32_counts = {
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:19 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:19 +0100
Subject: [PATCH v3 03/10] counter: stm32-timer-cnt: adopt signal definitions
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-4-fabrice.gasnier@foss.st.com>

Adopt signals definitions to ease later signals additions.
There are no intended functional changes here.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
Changes in v3:
 New patch split from "counter: stm32-timer-cnt: introduce clock signal"
---
 drivers/counter/stm32-timer-cnt.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index 668e9d1061d3..c34747d7857e 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -21,6 +21,9 @@
 #define TIM_CCER_MASK	(TIM_CCER_CC1P | TIM_CCER_CC1NP | \
 			 TIM_CCER_CC2P | TIM_CCER_CC2NP)
 
+#define STM32_CH1_SIG		0
+#define STM32_CH2_SIG		1
+
 struct stm32_timer_regs {
 	u32 cr1;
 	u32 cnt;
@@ -247,14 +250,14 @@ static int stm32_action_read(struct counter_device *counter,
 		return 0;
 	case COUNTER_FUNCTION_QUADRATURE_X2_A:
 		/* counts up/down on TI1FP1 edge depending on TI2FP2 level */
-		if (synapse->signal->id == count->synapses[0].signal->id)
+		if (synapse->signal->id == STM32_CH1_SIG)
 			*action = COUNTER_SYNAPSE_ACTION_BOTH_EDGES;
 		else
 			*action = COUNTER_SYNAPSE_ACTION_NONE;
 		return 0;
 	case COUNTER_FUNCTION_QUADRATURE_X2_B:
 		/* counts up/down on TI2FP2 edge depending on TI1FP1 level */
-		if (synapse->signal->id == count->synapses[1].signal->id)
+		if (synapse->signal->id == STM32_CH2_SIG)
 			*action = COUNTER_SYNAPSE_ACTION_BOTH_EDGES;
 		else
 			*action = COUNTER_SYNAPSE_ACTION_NONE;
@@ -278,11 +281,11 @@ static const struct counter_ops stm32_timer_cnt_ops = {
 
 static struct counter_signal stm32_signals[] = {
 	{
-		.id = 0,
+		.id = STM32_CH1_SIG,
 		.name = "Channel 1"
 	},
 	{
-		.id = 1,
+		.id = STM32_CH2_SIG,
 		.name = "Channel 2"
 	}
 };
@@ -291,12 +294,12 @@ static struct counter_synapse stm32_count_synapses[] = {
 	{
 		.actions_list = stm32_synapse_actions,
 		.num_actions = ARRAY_SIZE(stm32_synapse_actions),
-		.signal = &stm32_signals[0]
+		.signal = &stm32_signals[STM32_CH1_SIG]
 	},
 	{
 		.actions_list = stm32_synapse_actions,
 		.num_actions = ARRAY_SIZE(stm32_synapse_actions),
-		.signal = &stm32_signals[1]
+		.signal = &stm32_signals[STM32_CH2_SIG]
 	}
 };
 
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:22 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:22 +0100
Subject: [PATCH v3 06/10] counter: stm32-timer-cnt: add checks on quadrature encoder capability
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-7-fabrice.gasnier@foss.st.com>

This is a precursor patch to support capture channels on all possible
channels and stm32 timer types. Original driver was intended to be used
only as quadrature encoder and simple counter on internal clock.

So, add a check on encoder capability, so the driver may be probed for
timer instances without encoder feature. This way, all timers may be used
as simple counter on internal clock, starting from here.

Encoder capability is retrieved by using the timer index (originally in
stm32-timer-trigger driver and dt-bindings). The need to keep backward
compatibility with existing device tree lead to parse aside trigger node.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
Changes in v3:
- New patch split from:
  "counter: stm32-timer-cnt: populate capture channels and check encoder"
- return -EOPNOTSUPP when encoder function isn't supported by the timer
  instance.
---
 drivers/counter/stm32-timer-cnt.c | 55 +++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index bf2726dd7f12..6933d42b16bf 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -11,6 +11,7 @@
 #include <linux/mfd/stm32-timers.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
+#include <linux/of.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/platform_device.h>
 #include <linux/types.h>
@@ -38,6 +39,8 @@ struct stm32_timer_cnt {
 	u32 max_arr;
 	bool enabled;
 	struct stm32_timer_regs bak;
+	bool has_encoder;
+	u32 idx;
 };
 
 static const enum counter_function stm32_count_functions[] = {
@@ -111,12 +114,18 @@ static int stm32_count_function_write(struct counter_device *counter,
 		sms = TIM_SMCR_SMS_SLAVE_MODE_DISABLED;
 		break;
 	case COUNTER_FUNCTION_QUADRATURE_X2_A:
+		if (!priv->has_encoder)
+			return -EOPNOTSUPP;
 		sms = TIM_SMCR_SMS_ENCODER_MODE_1;
 		break;
 	case COUNTER_FUNCTION_QUADRATURE_X2_B:
+		if (!priv->has_encoder)
+			return -EOPNOTSUPP;
 		sms = TIM_SMCR_SMS_ENCODER_MODE_2;
 		break;
 	case COUNTER_FUNCTION_QUADRATURE_X4:
+		if (!priv->has_encoder)
+			return -EOPNOTSUPP;
 		sms = TIM_SMCR_SMS_ENCODER_MODE_3;
 		break;
 	default:
@@ -388,6 +397,48 @@ static struct counter_count stm32_counts = {
 	.num_ext = ARRAY_SIZE(stm32_count_ext)
 };
 
+/* encoder supported on TIM1 TIM2 TIM3 TIM4 TIM5 TIM8 */
+#define STM32_TIM_ENCODER_SUPPORTED	(BIT(0) | BIT(1) | BIT(2) | BIT(3) | BIT(4) | BIT(7))
+
+static const char * const stm32_timer_trigger_compat[] = {
+	"st,stm32-timer-trigger",
+	"st,stm32h7-timer-trigger",
+};
+
+static int stm32_timer_cnt_probe_encoder(struct platform_device *pdev,
+					 struct stm32_timer_cnt *priv)
+{
+	struct device *parent = pdev->dev.parent;
+	struct device_node *tnode = NULL, *pnode = parent->of_node;
+	int i, ret;
+
+	/*
+	 * Need to retrieve the trigger node index from DT, to be able
+	 * to determine if the counter supports encoder mode. It also
+	 * enforce backward compatibility, and allow to support other
+	 * counter modes in this driver (when the timer doesn't support
+	 * encoder).
+	 */
+	for (i = 0; i < ARRAY_SIZE(stm32_timer_trigger_compat) && !tnode; i++)
+		tnode = of_get_compatible_child(pnode, stm32_timer_trigger_compat[i]);
+	if (!tnode) {
+		dev_err(&pdev->dev, "Can't find trigger node\n");
+		return -ENODATA;
+	}
+
+	ret = of_property_read_u32(tnode, "reg", &priv->idx);
+	if (ret) {
+		dev_err(&pdev->dev, "Can't get index (%d)\n", ret);
+		return ret;
+	}
+
+	priv->has_encoder = !!(STM32_TIM_ENCODER_SUPPORTED & BIT(priv->idx));
+
+	dev_dbg(&pdev->dev, "encoder support: %s\n", priv->has_encoder ? "yes" : "no");
+
+	return 0;
+}
+
 static int stm32_timer_cnt_probe(struct platform_device *pdev)
 {
 	struct stm32_timers *ddata = dev_get_drvdata(pdev->dev.parent);
@@ -409,6 +460,10 @@ static int stm32_timer_cnt_probe(struct platform_device *pdev)
 	priv->clk = ddata->clk;
 	priv->max_arr = ddata->max_arr;
 
+	ret = stm32_timer_cnt_probe_encoder(pdev, priv);
+	if (ret)
+		return ret;
+
 	counter->name = dev_name(dev);
 	counter->parent = dev;
 	counter->ops = &stm32_timer_cnt_ops;
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:24 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:24 +0100
Subject: [PATCH v3 08/10] counter: stm32-timer-cnt: probe number of channels from registers
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-9-fabrice.gasnier@foss.st.com>

Probe the number of capture compare channels, by writing CCER register bits
and read them back. Take care to restore the register original value.

This is a precursor patch to support capture channels.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
Changes in v3:
- New patch split from:
  "counter: stm32-timer-cnt: populate capture channels and check encoder"
---
 drivers/counter/stm32-timer-cnt.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index 55eb6af34750..b5dc4378fecf 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -43,6 +43,7 @@ struct stm32_timer_cnt {
 	struct stm32_timer_regs bak;
 	bool has_encoder;
 	u32 idx;
+	unsigned int nchannels;
 };
 
 static const enum counter_function stm32_count_functions[] = {
@@ -417,6 +418,20 @@ static struct counter_count stm32_counts = {
 	.num_ext = ARRAY_SIZE(stm32_count_ext)
 };
 
+static void stm32_timer_cnt_detect_channels(struct platform_device *pdev,
+					    struct stm32_timer_cnt *priv)
+{
+	u32 ccer, ccer_backup;
+
+	regmap_read(priv->regmap, TIM_CCER, &ccer_backup);
+	regmap_set_bits(priv->regmap, TIM_CCER, TIM_CCER_CCXE);
+	regmap_read(priv->regmap, TIM_CCER, &ccer);
+	regmap_write(priv->regmap, TIM_CCER, ccer_backup);
+	priv->nchannels = hweight32(ccer & TIM_CCER_CCXE);
+
+	dev_dbg(&pdev->dev, "has %d cc channels\n", priv->nchannels);
+}
+
 /* encoder supported on TIM1 TIM2 TIM3 TIM4 TIM5 TIM8 */
 #define STM32_TIM_ENCODER_SUPPORTED	(BIT(0) | BIT(1) | BIT(2) | BIT(3) | BIT(4) | BIT(7))
 
@@ -484,6 +499,8 @@ static int stm32_timer_cnt_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	stm32_timer_cnt_detect_channels(pdev, priv);
+
 	counter->name = dev_name(dev);
 	counter->parent = dev;
 	counter->ops = &stm32_timer_cnt_ops;
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:23 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:23 +0100
Subject: [PATCH v3 07/10] counter: stm32-timer-cnt: introduce channels
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-8-fabrice.gasnier@foss.st.com>

Simply add channels 3 and 4 that can be used for capture. Statically
add them, despite some timers doesn't have them. Rather rely on
stm32_action_read that will report "none" action for these currently.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
Changes in v3:
- New patch split from:
  "counter: stm32-timer-cnt: populate capture channels and check encoder"
---
 drivers/counter/stm32-timer-cnt.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index 6933d42b16bf..55eb6af34750 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -25,6 +25,8 @@
 #define STM32_CH1_SIG		0
 #define STM32_CH2_SIG		1
 #define STM32_CLOCK_SIG		2
+#define STM32_CH3_SIG		3
+#define STM32_CH4_SIG		4
 
 struct stm32_timer_regs {
 	u32 cr1;
@@ -366,6 +368,14 @@ static struct counter_signal stm32_signals[] = {
 		.ext = stm32_count_clock_ext,
 		.num_ext = ARRAY_SIZE(stm32_count_clock_ext),
 	},
+	{
+		.id = STM32_CH3_SIG,
+		.name = "Channel 3"
+	},
+	{
+		.id = STM32_CH4_SIG,
+		.name = "Channel 4"
+	},
 };
 
 static struct counter_synapse stm32_count_synapses[] = {
@@ -384,6 +394,16 @@ static struct counter_synapse stm32_count_synapses[] = {
 		.num_actions = ARRAY_SIZE(stm32_clock_synapse_actions),
 		.signal = &stm32_signals[STM32_CLOCK_SIG]
 	},
+	{
+		.actions_list = stm32_synapse_actions,
+		.num_actions = ARRAY_SIZE(stm32_synapse_actions),
+		.signal = &stm32_signals[STM32_CH3_SIG]
+	},
+	{
+		.actions_list = stm32_synapse_actions,
+		.num_actions = ARRAY_SIZE(stm32_synapse_actions),
+		.signal = &stm32_signals[STM32_CH4_SIG]
+	},
 };
 
 static struct counter_count stm32_counts = {
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:25 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:25 +0100
Subject: [PATCH v3 09/10] counter: stm32-timer-cnt: add support for overflow events
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-10-fabrice.gasnier@foss.st.com>

Add support overflow events. Also add the related validation and
configuration routine. Register and enable interrupts to push events.
STM32 Timers can have either 1 global interrupt, or 4 dedicated interrupt
lines. Request only the necessary interrupt, e.g. either global interrupt
that can report all event types, or update interrupt only for overflow
event.

Acked-by: Lee Jones <lee at kernel.org>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
Changes in v3:
- patch split from: "counter: stm32-timer-cnt: add support for events", to
  focus on the overflow events only here. Move the capture event support
  to a separate patch.
- simplify the patch, by removing diversity introduced by the number of
  possible channels. All channels are now exposed instead.
  Report an error when trying to access a channel that doesn't exist.

Changes in v2:
- fix warnings (kernel test robot)
- fix a typo
- add collected ack from Lee
---
 drivers/counter/stm32-timer-cnt.c | 132 +++++++++++++++++++++++++++++-
 include/linux/mfd/stm32-timers.h  |  13 +++
 2 files changed, 144 insertions(+), 1 deletion(-)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index b5dc4378fecf..d13e4c427965 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -8,6 +8,7 @@
  *
  */
 #include <linux/counter.h>
+#include <linux/interrupt.h>
 #include <linux/mfd/stm32-timers.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
@@ -44,6 +45,9 @@ struct stm32_timer_cnt {
 	bool has_encoder;
 	u32 idx;
 	unsigned int nchannels;
+	unsigned int nr_irqs;
+	u32 *irq;
+	atomic_t nb_ovf;
 };
 
 static const enum counter_function stm32_count_functions[] = {
@@ -259,6 +263,29 @@ static int stm32_count_prescaler_write(struct counter_device *counter,
 	return regmap_write(priv->regmap, TIM_PSC, psc);
 }
 
+static int stm32_count_nb_ovf_read(struct counter_device *counter,
+				   struct counter_count *count, u64 *val)
+{
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+
+	*val = atomic_read(&priv->nb_ovf);
+
+	return 0;
+}
+
+static int stm32_count_nb_ovf_write(struct counter_device *counter,
+				    struct counter_count *count, u64 val)
+{
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+
+	if (val != (typeof(priv->nb_ovf.counter))val)
+		return -ERANGE;
+
+	atomic_set(&priv->nb_ovf, val);
+
+	return 0;
+}
+
 static struct counter_comp stm32_count_ext[] = {
 	COUNTER_COMP_DIRECTION(stm32_count_direction_read),
 	COUNTER_COMP_ENABLE(stm32_count_enable_read, stm32_count_enable_write),
@@ -266,6 +293,7 @@ static struct counter_comp stm32_count_ext[] = {
 			     stm32_count_ceiling_write),
 	COUNTER_COMP_COUNT_U64("prescaler", stm32_count_prescaler_read,
 			       stm32_count_prescaler_write),
+	COUNTER_COMP_COUNT_U64("num_overflows", stm32_count_nb_ovf_read, stm32_count_nb_ovf_write),
 };
 
 static const enum counter_synapse_action stm32_clock_synapse_actions[] = {
@@ -323,12 +351,57 @@ static int stm32_action_read(struct counter_device *counter,
 	}
 }
 
+static int stm32_count_events_configure(struct counter_device *counter)
+{
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+	struct counter_event_node *event_node;
+	u32 val, dier = 0;
+
+	list_for_each_entry(event_node, &counter->events_list, l) {
+		switch (event_node->event) {
+		case COUNTER_EVENT_OVERFLOW_UNDERFLOW:
+			/* first clear possibly latched UIF before enabling */
+			regmap_read(priv->regmap, TIM_DIER, &val);
+			if (!(val & TIM_DIER_UIE))
+				regmap_write(priv->regmap, TIM_SR, (u32)~TIM_SR_UIF);
+			dier |= TIM_DIER_UIE;
+			break;
+		default:
+			/* should never reach this path */
+			return -EINVAL;
+		}
+	}
+
+	regmap_write(priv->regmap, TIM_DIER, dier);
+
+	return 0;
+}
+
+static int stm32_count_watch_validate(struct counter_device *counter,
+				      const struct counter_watch *watch)
+{
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+
+	/* Interrupts are optional */
+	if (!priv->nr_irqs)
+		return -EOPNOTSUPP;
+
+	switch (watch->event) {
+	case COUNTER_EVENT_OVERFLOW_UNDERFLOW:
+		return 0;
+	default:
+		return -EINVAL;
+	}
+}
+
 static const struct counter_ops stm32_timer_cnt_ops = {
 	.count_read = stm32_count_read,
 	.count_write = stm32_count_write,
 	.function_read = stm32_count_function_read,
 	.function_write = stm32_count_function_write,
 	.action_read = stm32_action_read,
+	.events_configure = stm32_count_events_configure,
+	.watch_validate = stm32_count_watch_validate,
 };
 
 static int stm32_count_clk_get_freq(struct counter_device *counter,
@@ -418,6 +491,35 @@ static struct counter_count stm32_counts = {
 	.num_ext = ARRAY_SIZE(stm32_count_ext)
 };
 
+static irqreturn_t stm32_timer_cnt_isr(int irq, void *ptr)
+{
+	struct counter_device *counter = ptr;
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+	u32 clr = GENMASK(31, 0); /* SR flags can be cleared by writing 0 (wr 1 has no effect) */
+	u32 sr, dier;
+
+	regmap_read(priv->regmap, TIM_SR, &sr);
+	regmap_read(priv->regmap, TIM_DIER, &dier);
+	/*
+	 * Some status bits in SR don't match with the enable bits in DIER. Only take care of
+	 * the possibly enabled bits in DIER (that matches in between SR and DIER).
+	 */
+	dier &= TIM_DIER_UIE;
+	sr &= dier;
+
+	if (sr & TIM_SR_UIF) {
+		atomic_inc(&priv->nb_ovf);
+		counter_push_event(counter, COUNTER_EVENT_OVERFLOW_UNDERFLOW, 0);
+		dev_dbg(counter->parent, "COUNTER_EVENT_OVERFLOW_UNDERFLOW\n");
+		/* SR flags can be cleared by writing 0, only clear relevant flag */
+		clr &= ~TIM_SR_UIF;
+	}
+
+	regmap_write(priv->regmap, TIM_SR, clr);
+
+	return IRQ_HANDLED;
+};
+
 static void stm32_timer_cnt_detect_channels(struct platform_device *pdev,
 					    struct stm32_timer_cnt *priv)
 {
@@ -480,7 +582,7 @@ static int stm32_timer_cnt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct stm32_timer_cnt *priv;
 	struct counter_device *counter;
-	int ret;
+	int i, ret;
 
 	if (IS_ERR_OR_NULL(ddata))
 		return -EINVAL;
@@ -494,6 +596,8 @@ static int stm32_timer_cnt_probe(struct platform_device *pdev)
 	priv->regmap = ddata->regmap;
 	priv->clk = ddata->clk;
 	priv->max_arr = ddata->max_arr;
+	priv->nr_irqs = ddata->nr_irqs;
+	priv->irq = ddata->irq;
 
 	ret = stm32_timer_cnt_probe_encoder(pdev, priv);
 	if (ret)
@@ -511,6 +615,32 @@ static int stm32_timer_cnt_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, priv);
 
+	/* STM32 Timers can have either 1 global, or 4 dedicated interrupts (optional) */
+	if (priv->nr_irqs == 1) {
+		/* All events reported through the global interrupt */
+		ret = devm_request_irq(&pdev->dev, priv->irq[0], stm32_timer_cnt_isr,
+				       0, dev_name(dev), counter);
+		if (ret) {
+			dev_err(dev, "Failed to request irq %d (err %d)\n",
+				priv->irq[i], ret);
+			return ret;
+		}
+	} else {
+		for (i = 0; i < priv->nr_irqs; i++) {
+			/* Only take care of update IRQ for overflow events */
+			if (i != STM32_TIMERS_IRQ_UP)
+				continue;
+
+			ret = devm_request_irq(&pdev->dev, priv->irq[i], stm32_timer_cnt_isr,
+					       0, dev_name(dev), counter);
+			if (ret) {
+				dev_err(dev, "Failed to request irq %d (err %d)\n",
+					priv->irq[i], ret);
+				return ret;
+			}
+		}
+	}
+
 	/* Reset input selector to its default input */
 	regmap_write(priv->regmap, TIM_TISEL, 0x0);
 
diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
index ca35af30745f..9eb17481b07f 100644
--- a/include/linux/mfd/stm32-timers.h
+++ b/include/linux/mfd/stm32-timers.h
@@ -41,6 +41,11 @@
 #define TIM_SMCR_SMS	(BIT(0) | BIT(1) | BIT(2)) /* Slave mode selection */
 #define TIM_SMCR_TS	(BIT(4) | BIT(5) | BIT(6)) /* Trigger selection */
 #define TIM_DIER_UIE	BIT(0)	/* Update interrupt	   */
+#define TIM_DIER_CC1IE	BIT(1)  /* CC1 Interrupt Enable    */
+#define TIM_DIER_CC2IE	BIT(2)  /* CC2 Interrupt Enable    */
+#define TIM_DIER_CC3IE	BIT(3)  /* CC3 Interrupt Enable    */
+#define TIM_DIER_CC4IE	BIT(4)  /* CC4 Interrupt Enable    */
+#define TIM_DIER_CC_IE(x)	BIT((x) + 1) /* CC1, CC2, CC3, CC4 interrupt enable */
 #define TIM_DIER_UDE	BIT(8)  /* Update DMA request Enable */
 #define TIM_DIER_CC1DE	BIT(9)  /* CC1 DMA request Enable  */
 #define TIM_DIER_CC2DE	BIT(10) /* CC2 DMA request Enable  */
@@ -49,6 +54,7 @@
 #define TIM_DIER_COMDE	BIT(13) /* COM DMA request Enable  */
 #define TIM_DIER_TDE	BIT(14) /* Trigger DMA request Enable */
 #define TIM_SR_UIF	BIT(0)	/* Update interrupt flag   */
+#define TIM_SR_CC_IF(x)	BIT((x) + 1) /* CC1, CC2, CC3, CC4 interrupt flag */
 #define TIM_EGR_UG	BIT(0)	/* Update Generation       */
 #define TIM_CCMR_PE	BIT(3)	/* Channel Preload Enable  */
 #define TIM_CCMR_M1	(BIT(6) | BIT(5))  /* Channel PWM Mode 1 */
@@ -60,16 +66,23 @@
 #define TIM_CCMR_CC1S_TI2	BIT(1)	/* IC1/IC3 selects TI2/TI4 */
 #define TIM_CCMR_CC2S_TI2	BIT(8)	/* IC2/IC4 selects TI2/TI4 */
 #define TIM_CCMR_CC2S_TI1	BIT(9)	/* IC2/IC4 selects TI1/TI3 */
+#define TIM_CCMR_CC3S		(BIT(0) | BIT(1)) /* Capture/compare 3 sel */
+#define TIM_CCMR_CC4S		(BIT(8) | BIT(9)) /* Capture/compare 4 sel */
+#define TIM_CCMR_CC3S_TI3	BIT(0)	/* IC3 selects TI3 */
+#define TIM_CCMR_CC4S_TI4	BIT(8)	/* IC4 selects TI4 */
 #define TIM_CCER_CC1E	BIT(0)	/* Capt/Comp 1  out Ena    */
 #define TIM_CCER_CC1P	BIT(1)	/* Capt/Comp 1  Polarity   */
 #define TIM_CCER_CC1NE	BIT(2)	/* Capt/Comp 1N out Ena    */
 #define TIM_CCER_CC1NP	BIT(3)	/* Capt/Comp 1N Polarity   */
 #define TIM_CCER_CC2E	BIT(4)	/* Capt/Comp 2  out Ena    */
 #define TIM_CCER_CC2P	BIT(5)	/* Capt/Comp 2  Polarity   */
+#define TIM_CCER_CC2NP	BIT(7)	/* Capt/Comp 2N Polarity   */
 #define TIM_CCER_CC3E	BIT(8)	/* Capt/Comp 3  out Ena    */
 #define TIM_CCER_CC3P	BIT(9)	/* Capt/Comp 3  Polarity   */
+#define TIM_CCER_CC3NP	BIT(11)	/* Capt/Comp 3N Polarity   */
 #define TIM_CCER_CC4E	BIT(12)	/* Capt/Comp 4  out Ena    */
 #define TIM_CCER_CC4P	BIT(13)	/* Capt/Comp 4  Polarity   */
+#define TIM_CCER_CC4NP	BIT(15)	/* Capt/Comp 4N Polarity   */
 #define TIM_CCER_CCXE	(BIT(0) | BIT(4) | BIT(8) | BIT(12))
 #define TIM_BDTR_BKE(x)	BIT(12 + (x) * 12) /* Break input enable */
 #define TIM_BDTR_BKP(x)	BIT(13 + (x) * 12) /* Break input polarity */
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:21 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:21 +0100
Subject: [PATCH v3 05/10] counter: stm32-timer-cnt: add counter prescaler extension
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-6-fabrice.gasnier@foss.st.com>

There's a prescaler in between the selected input signal used for
counting (CK_PSC), and the counter input (CK_CNT).
So add the "prescaler" extension to the counter.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
Changes in v3:
- New patch split from "counter: stm32-timer-cnt: introduce clock signal"
---
 drivers/counter/stm32-timer-cnt.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index 21a9c20c4281..bf2726dd7f12 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -220,11 +220,40 @@ static int stm32_count_enable_write(struct counter_device *counter,
 	return 0;
 }
 
+static int stm32_count_prescaler_read(struct counter_device *counter,
+				      struct counter_count *count, u64 *prescaler)
+{
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+	u32 psc;
+
+	regmap_read(priv->regmap, TIM_PSC, &psc);
+
+	*prescaler = psc + 1;
+
+	return 0;
+}
+
+static int stm32_count_prescaler_write(struct counter_device *counter,
+				       struct counter_count *count, u64 prescaler)
+{
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+	u32 psc;
+
+	if (!prescaler || prescaler > MAX_TIM_PSC + 1)
+		return -ERANGE;
+
+	psc = prescaler - 1;
+
+	return regmap_write(priv->regmap, TIM_PSC, psc);
+}
+
 static struct counter_comp stm32_count_ext[] = {
 	COUNTER_COMP_DIRECTION(stm32_count_direction_read),
 	COUNTER_COMP_ENABLE(stm32_count_enable_read, stm32_count_enable_write),
 	COUNTER_COMP_CEILING(stm32_count_ceiling_read,
 			     stm32_count_ceiling_write),
+	COUNTER_COMP_COUNT_U64("prescaler", stm32_count_prescaler_read,
+			       stm32_count_prescaler_write),
 };
 
 static const enum counter_synapse_action stm32_clock_synapse_actions[] = {
-- 
2.25.1



From fabrice.gasnier at foss.st.com  Wed Dec 20 06:57:26 2023
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Wed, 20 Dec 2023 15:57:26 +0100
Subject: [PATCH v3 10/10] counter: stm32-timer-cnt: add support for capture events
In-Reply-To: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com>
Message-ID: <20231220145726.640627-11-fabrice.gasnier@foss.st.com>

Add support for capture events. Captured counter value for each channel
can be retrieved through CCRx register.
STM32 timers can have up to 4 capture channels (on input channel 1 to
channel 4), hence need to check the number of channels before reading
the capture data.
The capture configuration is hard-coded to capture signals on both edges
(non-inverted). Interrupts are used to report events independently for
each channel.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
---
Changes in v3:
- patch split from: "counter: stm32-timer-cnt: add support for events", to
  focus on the capture events only here.
- only get relevant interrupt line
---
 drivers/counter/stm32-timer-cnt.c | 134 +++++++++++++++++++++++++++++-
 1 file changed, 131 insertions(+), 3 deletions(-)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index d13e4c427965..0b131ca71de6 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -263,6 +263,40 @@ static int stm32_count_prescaler_write(struct counter_device *counter,
 	return regmap_write(priv->regmap, TIM_PSC, psc);
 }
 
+static int stm32_count_cap_read(struct counter_device *counter,
+				struct counter_count *count,
+				size_t ch, u64 *cap)
+{
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+	u32 ccrx;
+
+	if (ch >= priv->nchannels)
+		return -EOPNOTSUPP;
+
+	switch (ch) {
+	case 0:
+		regmap_read(priv->regmap, TIM_CCR1, &ccrx);
+		break;
+	case 1:
+		regmap_read(priv->regmap, TIM_CCR2, &ccrx);
+		break;
+	case 2:
+		regmap_read(priv->regmap, TIM_CCR3, &ccrx);
+		break;
+	case 3:
+		regmap_read(priv->regmap, TIM_CCR4, &ccrx);
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	dev_dbg(counter->parent, "CCR%zu: 0x%08x\n", ch + 1, ccrx);
+
+	*cap = ccrx;
+
+	return 0;
+}
+
 static int stm32_count_nb_ovf_read(struct counter_device *counter,
 				   struct counter_count *count, u64 *val)
 {
@@ -286,6 +320,8 @@ static int stm32_count_nb_ovf_write(struct counter_device *counter,
 	return 0;
 }
 
+static DEFINE_COUNTER_ARRAY_CAPTURE(stm32_count_cap_array, 4);
+
 static struct counter_comp stm32_count_ext[] = {
 	COUNTER_COMP_DIRECTION(stm32_count_direction_read),
 	COUNTER_COMP_ENABLE(stm32_count_enable_read, stm32_count_enable_write),
@@ -293,6 +329,7 @@ static struct counter_comp stm32_count_ext[] = {
 			     stm32_count_ceiling_write),
 	COUNTER_COMP_COUNT_U64("prescaler", stm32_count_prescaler_read,
 			       stm32_count_prescaler_write),
+	COUNTER_COMP_ARRAY_CAPTURE(stm32_count_cap_read, NULL, stm32_count_cap_array),
 	COUNTER_COMP_COUNT_U64("num_overflows", stm32_count_nb_ovf_read, stm32_count_nb_ovf_write),
 };
 
@@ -351,11 +388,68 @@ static int stm32_action_read(struct counter_device *counter,
 	}
 }
 
+struct stm32_count_cc_regs {
+	u32 ccmr_reg;
+	u32 ccmr_mask;
+	u32 ccmr_bits;
+	u32 ccer_bits;
+};
+
+static const struct stm32_count_cc_regs stm32_cc[] = {
+	{ TIM_CCMR1, TIM_CCMR_CC1S, TIM_CCMR_CC1S_TI1,
+		TIM_CCER_CC1E | TIM_CCER_CC1P | TIM_CCER_CC1NP },
+	{ TIM_CCMR1, TIM_CCMR_CC2S, TIM_CCMR_CC2S_TI2,
+		TIM_CCER_CC2E | TIM_CCER_CC2P | TIM_CCER_CC2NP },
+	{ TIM_CCMR2, TIM_CCMR_CC3S, TIM_CCMR_CC3S_TI3,
+		TIM_CCER_CC3E | TIM_CCER_CC3P | TIM_CCER_CC3NP },
+	{ TIM_CCMR2, TIM_CCMR_CC4S, TIM_CCMR_CC4S_TI4,
+		TIM_CCER_CC4E | TIM_CCER_CC4P | TIM_CCER_CC4NP },
+};
+
+static int stm32_count_capture_configure(struct counter_device *counter, unsigned int ch,
+					 bool enable)
+{
+	struct stm32_timer_cnt *const priv = counter_priv(counter);
+	u32 ccmr, ccer, sr;
+
+	if (ch >= ARRAY_SIZE(stm32_cc) || ch >= priv->nchannels) {
+		dev_err(counter->parent, "invalid ch: %d\n", ch);
+		return -EINVAL;
+	}
+
+	/*
+	 * configure channel in input capture mode, map channel 1 on TI1, channel2 on TI2...
+	 * Select both edges / non-inverted to trigger a capture.
+	 */
+	if (enable) {
+		/* first clear possibly latched capture flag upon enabling */
+		regmap_read(priv->regmap, TIM_CCER, &ccer);
+		if (!(ccer & stm32_cc[ch].ccer_bits)) {
+			sr = ~TIM_SR_CC_IF(ch);
+			regmap_write(priv->regmap, TIM_SR, sr);
+		}
+		regmap_update_bits(priv->regmap, stm32_cc[ch].ccmr_reg, stm32_cc[ch].ccmr_mask,
+				   stm32_cc[ch].ccmr_bits);
+		regmap_set_bits(priv->regmap, TIM_CCER, stm32_cc[ch].ccer_bits);
+	} else {
+		regmap_clear_bits(priv->regmap, TIM_CCER, stm32_cc[ch].ccer_bits);
+		regmap_clear_bits(priv->regmap, stm32_cc[ch].ccmr_reg, stm32_cc[ch].ccmr_mask);
+	}
+
+	regmap_read(priv->regmap, stm32_cc[ch].ccmr_reg, &ccmr);
+	regmap_read(priv->regmap, TIM_CCER, &ccer);
+	dev_dbg(counter->parent, "%s(%s) ch%d 0x%08x 0x%08x\n", __func__, enable ? "ena" : "dis",
+		ch, ccmr, ccer);
+
+	return 0;
+}
+
 static int stm32_count_events_configure(struct counter_device *counter)
 {
 	struct stm32_timer_cnt *const priv = counter_priv(counter);
 	struct counter_event_node *event_node;
 	u32 val, dier = 0;
+	int i, ret;
 
 	list_for_each_entry(event_node, &counter->events_list, l) {
 		switch (event_node->event) {
@@ -366,6 +460,12 @@ static int stm32_count_events_configure(struct counter_device *counter)
 				regmap_write(priv->regmap, TIM_SR, (u32)~TIM_SR_UIF);
 			dier |= TIM_DIER_UIE;
 			break;
+		case COUNTER_EVENT_CAPTURE:
+			ret = stm32_count_capture_configure(counter, event_node->channel, true);
+			if (ret)
+				return ret;
+			dier |= TIM_DIER_CC_IE(event_node->channel);
+			break;
 		default:
 			/* should never reach this path */
 			return -EINVAL;
@@ -374,6 +474,15 @@ static int stm32_count_events_configure(struct counter_device *counter)
 
 	regmap_write(priv->regmap, TIM_DIER, dier);
 
+	/* check for disabled capture events */
+	for (i = 0 ; i < priv->nchannels; i++) {
+		if (!(dier & TIM_DIER_CC_IE(i))) {
+			ret = stm32_count_capture_configure(counter, i, false);
+			if (ret)
+				return ret;
+		}
+	}
+
 	return 0;
 }
 
@@ -387,6 +496,12 @@ static int stm32_count_watch_validate(struct counter_device *counter,
 		return -EOPNOTSUPP;
 
 	switch (watch->event) {
+	case COUNTER_EVENT_CAPTURE:
+		if (watch->channel >= priv->nchannels) {
+			dev_err(counter->parent, "Invalid channel %d\n", watch->channel);
+			return -EINVAL;
+		}
+		return 0;
 	case COUNTER_EVENT_OVERFLOW_UNDERFLOW:
 		return 0;
 	default:
@@ -497,6 +612,7 @@ static irqreturn_t stm32_timer_cnt_isr(int irq, void *ptr)
 	struct stm32_timer_cnt *const priv = counter_priv(counter);
 	u32 clr = GENMASK(31, 0); /* SR flags can be cleared by writing 0 (wr 1 has no effect) */
 	u32 sr, dier;
+	int i;
 
 	regmap_read(priv->regmap, TIM_SR, &sr);
 	regmap_read(priv->regmap, TIM_DIER, &dier);
@@ -504,7 +620,7 @@ static irqreturn_t stm32_timer_cnt_isr(int irq, void *ptr)
 	 * Some status bits in SR don't match with the enable bits in DIER. Only take care of
 	 * the possibly enabled bits in DIER (that matches in between SR and DIER).
 	 */
-	dier &= TIM_DIER_UIE;
+	dier &= (TIM_DIER_UIE | TIM_DIER_CC1IE | TIM_DIER_CC2IE | TIM_DIER_CC3IE | TIM_DIER_CC4IE);
 	sr &= dier;
 
 	if (sr & TIM_SR_UIF) {
@@ -515,6 +631,15 @@ static irqreturn_t stm32_timer_cnt_isr(int irq, void *ptr)
 		clr &= ~TIM_SR_UIF;
 	}
 
+	/* Check capture events */
+	for (i = 0 ; i < priv->nchannels; i++) {
+		if (sr & TIM_SR_CC_IF(i)) {
+			counter_push_event(counter, COUNTER_EVENT_CAPTURE, i);
+			clr &= ~TIM_SR_CC_IF(i);
+			dev_dbg(counter->parent, "COUNTER_EVENT_CAPTURE, %d\n", i);
+		}
+	}
+
 	regmap_write(priv->regmap, TIM_SR, clr);
 
 	return IRQ_HANDLED;
@@ -627,8 +752,11 @@ static int stm32_timer_cnt_probe(struct platform_device *pdev)
 		}
 	} else {
 		for (i = 0; i < priv->nr_irqs; i++) {
-			/* Only take care of update IRQ for overflow events */
-			if (i != STM32_TIMERS_IRQ_UP)
+			/*
+			 * Only take care of update IRQ for overflow events, and cc for
+			 * capture events.
+			 */
+			if (i != STM32_TIMERS_IRQ_UP && i != STM32_TIMERS_IRQ_CC)
 				continue;
 
 			ret = devm_request_irq(&pdev->dev, priv->irq[i], stm32_timer_cnt_isr,
-- 
2.25.1



From andre.przywara at arm.com  Wed Dec 20 07:04:00 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 20 Dec 2023 15:04:00 +0000
Subject: [PATCH RESEND] ARM: dts: sun8i: r40: open the regulator aldo1
In-Reply-To: <ZYKjYypuAx7gNuam@debian.cyg>
References: <ZYKjYypuAx7gNuam@debian.cyg>
Message-ID: <20231220150400.0f32e2a5@donnerap.manchester.arm.com>

On Wed, 20 Dec 2023 16:18:43 +0800
fuyao <fuyao1697 at cyg.com> wrote:

Hi,

> the aldo1 is connect regulator pin which power the TV.

What do you mean with that? That ALDO1 is connected to VCC-TVOUT and/or
VCC-TVIN on the R40 SoC?

> The USB core use TV ref as reference Voltage.

The USB core in the SoC? So pin VCC-USB, which requires 3.3V, the same
voltage as the TV pins?
Which means this doesn't really have much to do with TV, it's just that
USB and also "TV" are supplied by ALDO1?

> Signed-off-by: fuyao <fuyao1697 at cyg.com>
> ---
>  arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> index 9f39b5a2bb35..8906170461df 100644
> --- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> +++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> @@ -42,6 +42,13 @@ &pio {
>  	vcc-pg-supply = <&reg_dldo1>;
>  };
>  
> +&reg_aldo1 {
> +	regulator-always-on;

So did USB never work before, with the DT as in mainline?

For always-on regulators it would be good to see some rationale why this
cannot be referenced by its consumer. If it is really supplying the USB
core, that would be a reason, because we don't have a good way of
describing this.

> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-aldo1";

Regulators should be named after their users, so use something like:
	regulator-name = "vcc-3v3-tv-usb";

That then also serves as documentation of why this is always on.

Cheers,
Andre

> +};
> +
>  &reg_aldo2 {
>  	regulator-always-on;
>  	regulator-min-microvolt = <1800000>;



From ryan.roberts at arm.com  Wed Dec 20 07:05:05 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 15:05:05 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <5fcbf405-7e62-4b38-acc4-a9dd8cc91214@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <be8b5181-be2c-4800-ba53-c65a6c3ed803@redhat.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
 <9f99a3ca-051e-4b1b-81e9-8456d8e422ad@redhat.com>
 <c1913fa2-d313-4f05-a649-da69b6d31d2a@arm.com>
 <c244707c-8c0c-4593-ab45-d8f165dbc5ee@redhat.com>
 <ba6a5c11-34fb-40ca-b24a-f51a207464f2@arm.com>
 <5fcbf405-7e62-4b38-acc4-a9dd8cc91214@redhat.com>
Message-ID: <396cae5d-70e4-449f-af6c-2348b720d3a3@arm.com>

On 20/12/2023 14:00, David Hildenbrand wrote:
> [...]
> 
>>>>
>>>
>>> gcc version 13.2.1 20231011 (Red Hat 13.2.1-4) (GCC)
>>>
>>> ?From Fedora 38. So "a bit" newer :P
>>>
>>
>> I'll retry with newer toolchain.
>>
>> FWIW, with the code fix and the original compiler:
>>
>> Fork, order-0, Apple M2:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 0.8% |
>> | hugetlb-rmap-cleanups |?????? 1.3% |????? 2.0% |
>> | fork-batching???????? |?????? 4.3% |????? 1.0% |
>>
>> Fork, order-9, Apple M2:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 0.8% |
>> | hugetlb-rmap-cleanups |?????? 0.9% |????? 0.9% |
>> | fork-batching???????? |???? -37.3% |????? 1.0% |
>>
>> Fork, order-0, Ampere Altra:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 0.7% |
>> | hugetlb-rmap-cleanups |?????? 3.2% |????? 0.7% |
>> | fork-batching???????? |?????? 5.5% |????? 1.1% |
>>
>> Fork, order-9, Ampere Altra:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 0.1% |
>> | hugetlb-rmap-cleanups |?????? 0.5% |????? 0.1% |
>> | fork-batching???????? |???? -10.4% |????? 0.1% |
>>
> 
> I just gave it another quick benchmark run on that Intel system.
> 
> hugetlb-rmap-cleanups -> fork-batching
> 
> order-0: 0.014114 -> 0.013848
> 
> -1.9%
> 
> order-9: 0.014262 -> 0.009410
> 
> -34%
> 
> Note that I disable SMT and turbo, and pin the test to one CPU, to make the
> results as stable as possible. My kernel config has anything related to
> debugging disabled.
> 

And with gcc 13.2 on arm64:

Fork, order-0, Apple M2 VM:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      1.5% |
| hugetlb-rmap-cleanups |      -3.3% |      1.1% |
| fork-batching         |      -3.6% |      1.4% |

Fork, order-9, Apple M2 VM:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      1.8% |
| hugetlb-rmap-cleanups |      -5.8% |      1.3% |
| fork-batching         |     -38.1% |      2.3% |

Fork, order-0, Ampere Altra:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      1.3% |
| hugetlb-rmap-cleanups |      -0.1% |      0.4% |
| fork-batching         |      -0.4% |      0.5% |

Fork, order-9, Ampere Altra:
| kernel                |   mean_rel |   std_rel |
|:----------------------|-----------:|----------:|
| mm-unstable           |       0.0% |      0.1% |
| hugetlb-rmap-cleanups |      -0.1% |      0.1% |
| fork-batching         |     -13.9% |      0.1% |


So all looking good. Compiler was the issue. Sorry for the noise.

So please go ahead with you rmap v2 stuff, and I'll wait for you to post the
fork and zap batching patches properly, then rebase my arm64 contpte stuff on
top and remeasure everything.

Thanks,
Ryan



From robh at kernel.org  Wed Dec 20 07:07:26 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 20 Dec 2023 09:07:26 -0600
Subject: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0
 clock management unit
In-Reply-To: <20231214105243.3707730-3-tudor.ambarus@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-3-tudor.ambarus@linaro.org>
Message-ID: <20231220150726.GA223267-robh@kernel.org>

On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
> clock management unit.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  .../bindings/clock/google,gs101-clock.yaml    | 25 +++++-
>  include/dt-bindings/clock/google,gs101.h      | 86 +++++++++++++++++++
>  2 files changed, 109 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> index 3eebc03a309b..ba54c13c55bc 100644
> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> @@ -30,14 +30,15 @@ properties:
>        - google,gs101-cmu-top
>        - google,gs101-cmu-apm
>        - google,gs101-cmu-misc
> +      - google,gs101-cmu-peric0
>  
>    clocks:
>      minItems: 1
> -    maxItems: 2
> +    maxItems: 3
>  
>    clock-names:
>      minItems: 1
> -    maxItems: 2
> +    maxItems: 3
>  
>    "#clock-cells":
>      const: 1
> @@ -88,6 +89,26 @@ allOf:
>              - const: dout_cmu_misc_bus
>              - const: dout_cmu_misc_sss
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: google,gs101-cmu-peric0
> +
> +    then:
> +      properties:
> +        clocks:
> +          items:
> +            - description: External reference clock (24.576 MHz)
> +            - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
> +            - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
> +
> +        clock-names:
> +          items:
> +            - const: oscclk
> +            - const: dout_cmu_peric0_bus
> +            - const: dout_cmu_peric0_ip

'bus' and 'ip' are sufficient because naming is local to the module. The 
same is true on 'dout_cmu_misc_bus'. As that has not made a release, 
please fix all of them.

Rob


From jernej.skrabec at gmail.com  Wed Dec 20 07:09:55 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 20 Dec 2023 16:09:55 +0100
Subject: [PATCH 1/5] clk: sunxi-ng: nkm: Support constraints on m/n ratio and
 parent rate
In-Reply-To: <87msu59wrc.fsf@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <5736273.DvuYhMxLoT@jernej-laptop> <87msu59wrc.fsf@oltmanns.dev>
Message-ID: <23332183.6Emhk5qWAg@jernej-laptop>

Dne sreda, 20. december 2023 ob 07:58:07 CET je Frank Oltmanns napisal(a):
> Hi Jernej!
> 
> On 2023-12-19 at 17:46:08 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> > Hi Frank!
> >
> > Dne ponedeljek, 18. december 2023 ob 14:35:19 CET je Frank Oltmanns napisal(a):
> >> The Allwinner A64 manual lists the following constraints for the
> >> PLL-MIPI clock:
> >>  - M/N >= 3
> >
> > This should be "<="
> 
> Yes, good catch! I will fix it in V2.
> 
> >
> >>  - (PLL_VIDEO0)/M >= 24MHz
> >>
> >> The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
> >> these constraints.
> >>
> >> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> >> ---
> >>  drivers/clk/sunxi-ng/ccu_nkm.c | 23 +++++++++++++++++++++++
> >>  drivers/clk/sunxi-ng/ccu_nkm.h |  8 ++++++++
> >>  2 files changed, 31 insertions(+)
> >>
> >> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> >> index eed64547ad42..2af5c1ebd527 100644
> >> --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> >> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> >> @@ -16,6 +16,20 @@ struct _ccu_nkm {
> >>  	unsigned long	m, min_m, max_m;
> >>  };
> >>
> >> +static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long parent,
> >> +				  unsigned long n, unsigned long m)
> >> +{
> >> +	struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
> >> +
> >> +	if (nkm->max_mn_ratio && (m > nkm->max_mn_ratio * n))
> >> +		return false;
> >> +
> >> +	if (nkm->parent_wo_nk && (parent < nkm->parent_wo_nk * m))
> >> +		return false;
> >> +
> >> +	return true;
> >> +}
> >> +
> >>  static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common,
> >>  						       struct clk_hw *parent_hw,
> >>  						       unsigned long *parent, unsigned long rate,
> >> @@ -32,6 +46,9 @@ static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
> >>
> >>  				tmp_parent = clk_hw_round_rate(parent_hw, rate * _m / (_n * _k));
> >>
> >> +				if (!ccu_nkm_is_valid_rate(common, tmp_parent, _n, _m))
> >> +					continue;
> >> +
> >>  				tmp_rate = tmp_parent * _n * _k / _m;
> >>
> >>  				if (ccu_is_better_rate(common, rate, tmp_rate, best_rate) ||
> >> @@ -65,6 +82,12 @@ static unsigned long ccu_nkm_find_best(unsigned long parent, unsigned long rate,
> >>  	for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
> >>  		for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
> >>  			for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
> >> +				if ((common->reg == 0x040) && (_m > 3 * _n))
> >> +					break;
> >> +
> >> +				if ((common->reg == 0x040) && (parent < 24000000 * _m))
> >> +					continue;
> >> +
> >
> > You already figured this part.
> >
> >>  				unsigned long tmp_rate;
> >>
> >>  				tmp_rate = parent * _n * _k / _m;
> >> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
> >> index 6601defb3f38..d3d3eaf55faf 100644
> >> --- a/drivers/clk/sunxi-ng/ccu_nkm.h
> >> +++ b/drivers/clk/sunxi-ng/ccu_nkm.h
> >> @@ -16,6 +16,12 @@
> >>   * struct ccu_nkm - Definition of an N-K-M clock
> >>   *
> >>   * Clocks based on the formula parent * N * K / M
> >> + *
> >> + * @max_mn_ratio:	Maximum value for M / N.
> >> + * @parent_wo_nk:	The minimum rate the parent must provide after applying the divisor,
> >> + *			but without applying the multipliers, i.e. the contstraint
> >> + *			   (parent rate)/M >= parent_wo_nk
> >> + *			must be fulfilled.
> >>   */
> >>  struct ccu_nkm {
> >>  	u32			enable;
> >> @@ -27,6 +33,8 @@ struct ccu_nkm {
> >>  	struct ccu_mux_internal	mux;
> >>
> >>  	unsigned int		fixed_post_div;
> >> +	unsigned long		max_mn_ratio;
> >> +	unsigned long           parent_wo_nk;
> >
> > What about max_m_n_ratio and max_parent_m_ratio, to be consistent? This
> > should also allow to simplify description.
> 
> Jernej, thank you so much! This is brilliant! I was racking my brain for
> a good name but failed. Now, that I see your proposal, I don't know why
> I hadn't come up with it. It's the obvious choice.
> 
> I'd say with the new names we should be able to get rid of the comments
> describing the new struct members (also in ccu_nm.h). What are your
> thoughts on that?

Ah, I missed that only new ones are documented. Yeah, you can skip it.

Best regards,
Jernej

> 
> Best regards,
>   Frank
> 
> >
> > Best regards,
> > Jernej
> >
> >>
> >>  	struct ccu_common	common;
> >>  };
> >>
> >>
> 






From semen.protsenko at linaro.org  Wed Dec 20 07:12:14 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Wed, 20 Dec 2023 09:12:14 -0600
Subject: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock
 as critical
In-Reply-To: <c3db7b3e-814c-4afc-b67a-112bce3d38ec@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-8-tudor.ambarus@linaro.org> <CAPLW+4mNjCbJ+VbKR66DFSkiXHyxdjgvwjN7azxjJQ6UxQikEw@mail.gmail.com>
 <f3d61c49-1a46-476c-b7a5-6cc6a06a33ed@linaro.org> <CAPLW+4=tyr8Pcoe6Wm0Wtmkk4udDpuAiOKy7+C+Fwa6mvt3VoQ@mail.gmail.com>
 <5de5cddd-2bab-4408-b31f-f48bef98f14c@linaro.org> <CAPLW+4n-S2jaVPUwKTFC_iabnDd_qDV=ZubMqhz-X9XiZzzJow@mail.gmail.com>
 <4ba80e1e-8fec-4fd2-9140-6da006c9d5f5@linaro.org> <CAPLW+4mm8LG=wtJHT5EYhGGiU72qVe70vJv6-JkEGepiXFjcvA@mail.gmail.com>
 <c3db7b3e-814c-4afc-b67a-112bce3d38ec@linaro.org>
Message-ID: <CAPLW+4=kaSZaMuzAuCRz21qcf2M+1LBrzJULNJaZv6+FQOq4WA@mail.gmail.com>

On Wed, Dec 20, 2023 at 8:22?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
> Hi, Sam!
>
> On 12/19/23 17:31, Sam Protsenko wrote:
> > On Tue, Dec 19, 2023 at 10:47?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>
> >> Hi, Sam!
> >>
> >> On 12/14/23 16:43, Sam Protsenko wrote:
> >>> On Thu, Dec 14, 2023 at 10:15?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 12/14/23 16:09, Sam Protsenko wrote:
> >>>>> On Thu, Dec 14, 2023 at 10:01?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 12/14/23 15:37, Sam Protsenko wrote:
> >>>>>>> On Thu, Dec 14, 2023 at 4:52?AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> >>>>>>>>
> >>>>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >>>>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >>>>>>>> which then makes the system hang. To prevent this, mark
> >>>>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >>>>>>>> accordingly when tested.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> >>>>>>>> ---
> >>>>>>>>  drivers/clk/samsung/clk-gs101.c | 2 +-
> >>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >>>>>>>> index 3d194520b05e..08d80fca9cd6 100644
> >>>>>>>> --- a/drivers/clk/samsung/clk-gs101.c
> >>>>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
> >>>>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>>>>>>>              "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>>>>>>>              21, 0, 0),
> >>>>>>>>         GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >>>>>>>> -            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >>>>>>>> +            CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >>>>>>>
> >>>>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> >>>>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
> >>>>>>> usually should be avoided. Is it possible that the system freezes
> >>>>>>> because some other clock (which depends on peric0_ip) gets disabled as
> >>>>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> >>>>>>> is not implemented yet in the clock driver? Just looks weird to me
> >>>>>>> that the system hangs because of CMU IP clock disablement. It's
> >>>>>>> usually something much more specific.
> >>>>>>
> >>>>>> The system hang happened when I tested USI8 in I2C configuration with an
> >>>>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> >>>>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> >>>>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> >>>>>> disablement which makes the system hang. Either marking the CMU_TOP gate
> >>>>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
> >>>>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
> >>>>>>
> >>>>>
> >>>>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
> >>>>
> >>>> yes.
> >>
> >> I checked again all the clocks. I implemented all but one, the one
> >> defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
> >> don't have any reference on how it should be defined so I won't touch it
> >> yet. But I have some good news too, see below.
> >>
> >>>
> >>> Ok. Are there any other CMUs (perhaps not implemented yet) which
> >>> consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
> >>> clocks derived from it? If so, is there a chance some particular leaf
> >>> clock in those CMUs actually renders the system frozen when disabled
> >>> as a consequence of disabling PERIC0_IP, and would explain better why
> >>> the freeze happens?
> >>>
> >>> For now I think it's ok to have that CLK_IS_CRITICAL flag here,
> >>> because as you said you implemented all clocks in this CMU and neither
> >>> of those looks like a critical one. But I'd advice to add a TODO
> >>> comment saying it's probably a temporary solution before actual leaf
> >>> clock which leads to freeze is identified (which probably resides in
> >>> some other not implemented yet CMU).
> >>>
> >>>>
> >>>>> is a chance some other leaf clock (which is not implemented yet in
> >>>>> your driver) gets disabled as a result of PERIC0_IP disablement, which
> >>>>> might actually lead to that hang you observe. Usually it's some
> >>>>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> >>>>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> >>>>> and the corresponding comments I left there, maybe it'll give you more
> >>>>> particular idea about what to look for. Yes, making the whole CMU
> >>>>> always running without understanding why (i.e. because of which
> >>>>> particular leaf clock) might not be the best way of handling this
> >>>>
> >>>> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
> >>>
> >>> That's not a root cause here. And I think PERIC0_IP is neither.
> >>>
> >>
> >> you were right!
> >>>>
> >>>>> issue. I might be mistaken, but at least please check if you
> >>>>> implemented all clocks for PERIC0 first and if making some meaningful
> >>>>> leaf clock critical makes more sense.
> >>>>>
> >>
> >> I determined which leaf clocks shall be marked as critical. I enabled
> >> the debugfs clock write access. Then I made sure that the parents of the
> >> PERIC0 CMU have at least one user so that they don't get disabled after
> >> an enable-disable sequence on a leaf clock. The I took all the PERIC0
> >> gate clocks and enabled and disabled them one by one. Whichever hang the
> >> system when the clock was disabled was marked as critical. The list of
> >> critical leaf clocks is as following:
> >>
> >
> > Nice! I used somehow similar procedure for clk-exynos850, doing
> > basically the same thing, but in core clock driver code.
> >
> >> "gout_peric0_peric0_cmu_peric0_pclk",
> >> "gout_peric0_lhm_axi_p_peric0_i_clk",
> >> "gout_peric0_peric0_top1_ipclk_0",
> >> "gout_peric0_peric0_top1_pclk_0".
> >>
> >> I'll update v2 with this instead. Thanks for the help, Sam!
> >
> > Glad you weren't discouraged by my meticulousness :) In clk-exynos850
> > I usually used CLK_IGNORE_UNUSED for clocks like XXX_CMU_XXX (in your
> > case it's PERIC0_CMU_PERIC0), with a corresponding comment. Those
> > clocks usually can be used to disable the bus clock for corresponding
> > CMU IP-core (in your case CMU_PERIC0), which makes it impossible to
> > access the registers from that CMU block, as its register interface is
> > not clocked anymore. Guess I saw something similar in Exynos5433 or
> > Exynos7 clk drivers, or maybe Sylwester or Krzysztof told me to do so
> > -- don't really remember. For AXI clock it also seems logical to keep
> > it running (AXI bus might be used for GIC and memory). But again,
> > maybe CLK_IGNORE_UNUSED flag would be more appropriate that
> > CLK_IS_CRITICAL? For the last two clocks -- it's hard to tell what
> > exactly they do. Is TOP1 some other CMU or block name, and is there
> > any further users for those clocks?
> >
> > Anyways, if you are working on v2, please consider doing next two
> > things while at it:
> >
> >   1. For each critical clock: add corresponding comment explaining why
> > it's marked so
>
> Will do.
>
> >   2. Consider using CLK_IGNORE_UNUSED instead of CLK_IS_CRITICAL when
> > appropriate; both have their use in different cases
> >
> > Btw, if you check other Exynos clk drivers, there is a lot of examples
> > for flags like those.
> >
> Thanks for the feedback, it's educative.
>
> I played a little with the clk debugfs and I think all should be marked
> as critical. What I did was to make sure that their parents are enabled
> already and then I enabled and disabled each. Each time I disabled one
> of them the system hung. Thus in case they will be used, if one disable
> them on an error path, it will hang the system. We can't disable them at
> suspend either. Thus I propose to keep them as critical.
>

Do you see those clocks potentially used by some actual consumers in
future? If no, maybe CLK_IGNORE_UNUSED is enough (just to make sure
the core clock framework won't disable those during the clocks
initialization)? Anyway, I don't have any strong preferences in this
case. If you think CLK_IS_CRITICAL is better in this case, I'd say go
for it.

Also, on a bit different note: please make sure there is no
"clk_ignore_unused" param in your kernel cmdline (e.g. passed from the
bootloader via dts). The clock driver should be functional without
that param. Though it might take some additional work.

> Thanks!
> ta


From jernej.skrabec at gmail.com  Wed Dec 20 07:12:42 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 20 Dec 2023 16:12:42 +0100
Subject: [PATCH 4/5] clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's n/m ratio
In-Reply-To: <87il4t9wi1.fsf@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <13411739.uLZWGnKmhe@jernej-laptop> <87il4t9wi1.fsf@oltmanns.dev>
Message-ID: <2174554.Mh6RI2rZIc@jernej-laptop>

Dne sreda, 20. december 2023 ob 08:09:28 CET je Frank Oltmanns napisal(a):
> 
> On 2023-12-19 at 17:54:19 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> > Dne ponedeljek, 18. december 2023 ob 14:35:22 CET je Frank Oltmanns napisal(a):
> >> The Allwinner A64 manual lists the following constraint for the
> >> PLL-VIDEO0 clock: 8 <= N/M <= 25
> >>
> >> Use this constraint.
> >>
> >> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> >> ---
> >>  drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 8 ++++++--
> >>  1 file changed, 6 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> >> index c034ac027d1c..75d839da446c 100644
> >> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> >> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> >> @@ -68,7 +68,8 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
> >>  				       BIT(28),	/* lock */
> >>  				       CLK_SET_RATE_UNGATE);
> >>
> >> -static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-video0",
> >> +static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(pll_video0_clk,
> >> +						"pll-video0",
> >>  						"osc24M", 0x010,
> >>  						192000000,	/* Minimum rate */
> >>  						1008000000,	/* Maximum rate */
> >> @@ -80,7 +81,10 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-vid
> >>  						297000000,	/* frac rate 1 */
> >>  						BIT(31),	/* gate */
> >>  						BIT(28),	/* lock */
> >> -						CLK_SET_RATE_UNGATE);
> >> +						CLK_SET_RATE_UNGATE,
> >> +						CCU_FEATURE_FRACTIONAL |
> >> +						CCU_FEATURE_CLOSEST_RATE,
> >
> > Above flags are unrelated change, put them in new patch if needed.
> 
> You might notice that I am using a new macro for initializing the
> pll_video0_clk struct:
> New: SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO
> Old: SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST
> 
> Setting the two CCU_FEATURE flags is part of the old initialization
> macro.
> 
> I'll add SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_NM_RATIO_CLOSEST which
> hopefully resolves the confusion.

I'm in doubt if we need so many macros. How many users of these macro we'll have?
I see that R40 SoC would also need same ratio limits, but other that that, none?

Best regards,
Jernej

> 
> Thanks,
>   Frank
> 
> >
> > Best regards,
> > Jernej
> >
> >> +						8, 25);		/* min/max nm ratio */
> >>
> >>  static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
> >>  					"osc24M", 0x018,
> >>
> >>
> 






From jernej.skrabec at gmail.com  Wed Dec 20 07:18:49 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 20 Dec 2023 16:18:49 +0100
Subject: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate
In-Reply-To: <87edfh9ud8.fsf@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev>
Message-ID: <1845418.atdPhlSkOF@jernej-laptop>

Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a):
> 
> On 2023-12-19 at 18:04:29 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns napisal(a):
> >> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
> >> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
> >> than 500 MHz.
> >>
> >> Therefore, change [hv]sync_(start|end) so that we reach a clock rate
> >> that is high enough to drive PLL-MIPI within its limits.
> >>
> >> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> >
> > I'm not too sure about this patch. I see that PLL_MIPI doesn't have set
> > minimum frequency limit in clock driver. If you add it, clock framework
> > should find rate that is high enough and divisible with target rate.
> 
> This one is really a tough nut. Unfortunately, the PLL_MIPI clock for
> this panel has to run exactly at 6 * panel clock. Let me start by
> showing the relevant part of the clock tree (this is on the pinephone
> after applying the patches):
>     pll-video0                 393600000
>        pll-mipi                500945454
>           tcon0                500945454
>              tcon-data-clock   125236363
> 
> To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit
> rate [1]. It's a fixed divisor
> 
> The panel I'm proposing to change is defined as this:
> 
>     static const struct st7703_panel_desc xbd599_desc = {
>     	.mode = &xbd599_mode,
>     	.lanes = 4,
>     	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
>     	.format = MIPI_DSI_FMT_RGB888,
>     	.init_sequence = xbd599_init_sequence,
>     };
> 
> So, we have 24 bpp and 4 lanes. Therefore, the resulting requested
> tcon-data-clock rate is
>     crtc_clock * 1000 * (24 / 4) / 4
> 
> tcon-data-clock therefore requests a parent rate of
>     4 * (crtc_clock * 1000 * (24 / 4) / 4)
> 
> The initial 4 is the fixed divisor between tcon0 and tcon-data-clock.
> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi.
> 
> Since PLL-MIPI has to run at at least at 500MHz this forces us to have a
> crtc_clock >= 83.333 MHz. The mode I'm prorposing results in a rate of
> 83.502 MHz.

This is much better explanation why this change is needed. Still, I think
adding min and max rate to PLL_MIPI would make sense, so proper rates
are guaranteed.

Anyway, do you know where are all those old values come from? And how did
you come up with new ones? I guess you can't just simply change timings,
there are probably some HW limitations? Do you know if BSP kernel support
this panel and how this situation is solved there?

> 
> If we only changed the constraints on the PLL_MIPI without changing the
> panel mode, we end up with a mismatch. This, in turn, would result in
> dropped frames, right?

From what I read, I think frame rate would be higher than 60 fps. What
exactly would happen depends on the panel.

Best regards,
Jernej

> 
> Best regards,
>   Frank
> 
> [1] Source:
> https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/sun4i_tcon.c#L346
> 
> >
> > Best regards,
> > Jernej
> >
> >> ---
> >>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++-------
> >>  1 file changed, 7 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> >> index b55bafd1a8be..6886fd7f765e 100644
> >> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> >> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
> >>
> >>  static const struct drm_display_mode xbd599_mode = {
> >>  	.hdisplay    = 720,
> >> -	.hsync_start = 720 + 40,
> >> -	.hsync_end   = 720 + 40 + 40,
> >> -	.htotal	     = 720 + 40 + 40 + 40,
> >> +	.hsync_start = 720 + 65,
> >> +	.hsync_end   = 720 + 65 + 65,
> >> +	.htotal      = 720 + 65 + 65 + 65,
> >>  	.vdisplay    = 1440,
> >> -	.vsync_start = 1440 + 18,
> >> -	.vsync_end   = 1440 + 18 + 10,
> >> -	.vtotal	     = 1440 + 18 + 10 + 17,
> >> -	.clock	     = 69000,
> >> +	.vsync_start = 1440 + 30,
> >> +	.vsync_end   = 1440 + 30 + 22,
> >> +	.vtotal	     = 1440 + 30 + 22 + 29,
> >> +	.clock	     = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
> >>  	.flags	     = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> >>  	.width_mm    = 68,
> >>  	.height_mm   = 136,
> >>
> >>
> 






From jernej.skrabec at gmail.com  Wed Dec 20 07:25:50 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 20 Dec 2023 16:25:50 +0100
Subject: [RFC PATCH 2/2] riscv: dts: allwinner: Fill in OPPs
In-Reply-To: <20231220095141.27883-3-fusibrandon13@gmail.com>
References: <20231220095141.27883-1-fusibrandon13@gmail.com>
 <20231220095141.27883-3-fusibrandon13@gmail.com>
Message-ID: <113541315.nniJfEyVGO@jernej-laptop>

Dne sreda, 20. december 2023 ob 10:51:41 CET je Brandon Cheo Fusi napisal(a):
> Specifies two voltage ranges, in order of increasing stability,
> for each OPP. This is heavily inspired by
> 
> https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L133
> 
> and
> 
> https://github.com/mangopi-sbc/tina-linux-5.4/blob/0d4903ebd9d2194ad914686d5b0fc1ddacf11a9d/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L182

Remove links from message. If you really want them, add Link tag for each.

> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> index 2f1771c19..8e7bc8bd0 100644
> --- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> @@ -48,13 +48,17 @@ opp_table_cpu: opp-table-cpu {
>  		opp-408000000 {
>  			clock-latency-ns = <244144>; /* 8 32k periods */
>  			opp-hz = /bits/ 64 <408000000>;
> -			opp-microvolt-speed0 = <900000 900000 1100000>;
> +
> +			opp-microvolt-speed0 = <950000 900000 1100000>;

Second value should be same as first, otherwise you'll experience stability issue.

> +			opp-microvolt-speed1 = <900000 900000 1100000>;
>  		};
>  
>  		opp-1080000000 {
>  			clock-latency-ns = <244144>; /* 8 32k periods */
>  			opp-hz = /bits/ 64 <1008000000>;
> -			opp-microvolt-speed0 = <900000 900000 1100000>;
> +
> +			opp-microvolt-speed0 = <1100000 900000 1100000>;

Ditto.

Best regards,
Jernej

> +			opp-microvolt-speed1 = <950000 900000 1100000>;
>  		};
>  	};
>  
> 






From hugues.fruchet at foss.st.com  Wed Dec 20 07:27:27 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 16:27:27 +0100
Subject: [PATCH v4 0/5] Add support for video hardware codec of STMicroelectronics STM32 SoC series
Message-ID: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>

This patchset introduces support for VDEC video hardware decoder
and VENC video hardware encoder of STMicroelectronics STM32MP25
SoC series.

This initial support implements H264 decoding, VP8 decoding and
JPEG encoding.

This has been tested on STM32MP257F-EV1 evaluation board.

===========
= history =
===========
version 4:
   - Fix comments from Nicolas about dropping encoder raw steps

version 3:
   - Fix remarks from Krzysztof Kozlowski:
    - drop "items", we keep simple enum in such case
    - drop second example - it is the same as the first
   - Drop unused node labels as suggested by Conor Dooley
   - Revisit min/max resolutions as suggested by Nicolas Dufresne

version 2:
   - Fix remarks from Krzysztof Kozlowski on v1:
    - single video-codec binding for both VDEC/VENC
    - get rid of "-names"
    - use of generic node name "video-codec"

version 1:
  - Initial submission

Hugues Fruchet (5):
  dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
  media: hantro: add support for STM32MP25 VDEC
  media: hantro: add support for STM32MP25 VENC
  arm64: dts: st: add video decoder support to stm32mp255
  arm64: dts: st: add video encoder support to stm32mp255

 .../media/st,stm32mp25-video-codec.yaml       |  50 ++++++++
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  12 ++
 arch/arm64/boot/dts/st/stm32mp255.dtsi        |  17 +++
 drivers/media/platform/verisilicon/Kconfig    |  14 ++-
 drivers/media/platform/verisilicon/Makefile   |   4 +
 .../media/platform/verisilicon/hantro_drv.c   |   4 +
 .../media/platform/verisilicon/hantro_hw.h    |   2 +
 .../platform/verisilicon/stm32mp25_vdec_hw.c  |  92 ++++++++++++++
 .../platform/verisilicon/stm32mp25_venc_hw.c  | 115 ++++++++++++++++++
 9 files changed, 307 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c

-- 
2.25.1



From hugues.fruchet at foss.st.com  Wed Dec 20 07:27:28 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 16:27:28 +0100
Subject: [PATCH v4 1/5] dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
In-Reply-To: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
References: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220152732.2138260-2-hugues.fruchet@foss.st.com>

Add STM32MP25 VDEC video decoder & VENC video encoder bindings.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 .../media/st,stm32mp25-video-codec.yaml       | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml

diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
new file mode 100644
index 000000000000..e167e3b1bec3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/st,stm32mp25-video-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 VDEC video decoder & VENC video encoder
+
+maintainers:
+  - Hugues Fruchet <hugues.fruchet at foss.st.com>
+
+description:
+  The STMicroelectronics STM32MP25 SOCs embeds a VDEC video hardware
+  decoder peripheral based on Verisilicon VC8000NanoD IP (former Hantro G1)
+  and a VENC video hardware encoder peripheral based on Verisilicon
+  VC8000NanoE IP (former Hantro H1).
+
+properties:
+  compatible:
+    enum:
+      - st,stm32mp25-vdec
+      - st,stm32mp25-venc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    video-codec at 580d0000 {
+        compatible = "st,stm32mp25-vdec";
+        reg = <0x580d0000 0x3c8>;
+        interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&ck_icn_p_vdec>;
+    };
-- 
2.25.1



From hugues.fruchet at foss.st.com  Wed Dec 20 07:27:30 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 16:27:30 +0100
Subject: [PATCH v4 3/5] media: hantro: add support for STM32MP25 VENC
In-Reply-To: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
References: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220152732.2138260-4-hugues.fruchet@foss.st.com>

Add support for STM32MP25 VENC video hardware encoder.
Support of JPEG encoding.
VENC has its own reset/clock/irq.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 drivers/media/platform/verisilicon/Makefile   |   3 +-
 .../media/platform/verisilicon/hantro_drv.c   |   1 +
 .../media/platform/verisilicon/hantro_hw.h    |   1 +
 .../platform/verisilicon/stm32mp25_venc_hw.c  | 115 ++++++++++++++++++
 4 files changed, 119 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c

diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
index 5854e0f0dd32..3bf43fdbedc1 100644
--- a/drivers/media/platform/verisilicon/Makefile
+++ b/drivers/media/platform/verisilicon/Makefile
@@ -41,4 +41,5 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
 		sunxi_vpu_hw.o
 
 hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
-		stm32mp25_vdec_hw.o
+		stm32mp25_vdec_hw.o \
+		stm32mp25_venc_hw.o
diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
index 2db27c333924..4d97a8ac03de 100644
--- a/drivers/media/platform/verisilicon/hantro_drv.c
+++ b/drivers/media/platform/verisilicon/hantro_drv.c
@@ -736,6 +736,7 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_STM32MP25
 	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
+	{ .compatible = "st,stm32mp25-venc", .data = &stm32mp25_venc_variant, },
 #endif
 	{ /* sentinel */ }
 };
diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
index b7eccc1a96fc..70c72e9d11d5 100644
--- a/drivers/media/platform/verisilicon/hantro_hw.h
+++ b/drivers/media/platform/verisilicon/hantro_hw.h
@@ -407,6 +407,7 @@ extern const struct hantro_variant rk3588_vpu981_variant;
 extern const struct hantro_variant sama5d4_vdec_variant;
 extern const struct hantro_variant sunxi_vpu_variant;
 extern const struct hantro_variant stm32mp25_vdec_variant;
+extern const struct hantro_variant stm32mp25_venc_variant;
 
 extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
 extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
diff --git a/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
new file mode 100644
index 000000000000..0ff0f073b922
--- /dev/null
+++ b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * STM32MP25 VENC video encoder driver
+ *
+ * Copyright (C) STMicroelectronics SA 2022
+ * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
+ *          for STMicroelectronics.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/reset.h>
+
+#include "hantro.h"
+#include "hantro_jpeg.h"
+#include "hantro_h1_regs.h"
+
+/*
+ * Supported formats.
+ */
+
+static const struct hantro_fmt stm32mp25_venc_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_YUV420M,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420P,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_NV12M,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420SP,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_YUYV,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUYV422,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_UYVY,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_UYVY422,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_JPEG,
+		.codec_mode = HANTRO_MODE_JPEG_ENC,
+		.max_depth = 2,
+		.header_size = JPEG_HEADER_SIZE,
+		.frmsize = {
+			.min_width = 96,
+			.max_width = FMT_4K_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = 96,
+			.max_height = FMT_4K_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+};
+
+static irqreturn_t stm32mp25_venc_irq(int irq, void *dev_id)
+{
+	struct hantro_dev *vpu = dev_id;
+	enum vb2_buffer_state state;
+	u32 status;
+
+	status = vepu_read(vpu, H1_REG_INTERRUPT);
+	state = (status & H1_REG_INTERRUPT_FRAME_RDY) ?
+		VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
+
+	vepu_write(vpu, H1_REG_INTERRUPT_BIT, H1_REG_INTERRUPT);
+
+	hantro_irq_done(vpu, state);
+
+	return IRQ_HANDLED;
+}
+
+static void stm32mp25_venc_reset(struct hantro_ctx *ctx)
+{
+}
+
+/*
+ * Supported codec ops.
+ */
+
+static const struct hantro_codec_ops stm32mp25_venc_codec_ops[] = {
+	[HANTRO_MODE_JPEG_ENC] = {
+		.run = hantro_h1_jpeg_enc_run,
+		.reset = stm32mp25_venc_reset,
+		.done = hantro_h1_jpeg_enc_done,
+	},
+};
+
+/*
+ * Variants.
+ */
+
+static const struct hantro_irq stm32mp25_venc_irqs[] = {
+	{ "venc", stm32mp25_venc_irq },
+};
+
+static const char * const stm32mp25_venc_clk_names[] = {
+	"venc-clk"
+};
+
+const struct hantro_variant stm32mp25_venc_variant = {
+	.enc_fmts = stm32mp25_venc_fmts,
+	.num_enc_fmts = ARRAY_SIZE(stm32mp25_venc_fmts),
+	.codec = HANTRO_JPEG_ENCODER,
+	.codec_ops = stm32mp25_venc_codec_ops,
+	.irqs = stm32mp25_venc_irqs,
+	.num_irqs = ARRAY_SIZE(stm32mp25_venc_irqs),
+	.clk_names = stm32mp25_venc_clk_names,
+	.num_clocks = ARRAY_SIZE(stm32mp25_venc_clk_names)
+};
+
-- 
2.25.1



From hugues.fruchet at foss.st.com  Wed Dec 20 07:27:31 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 16:27:31 +0100
Subject: [PATCH v4 4/5] arm64: dts: st: add video decoder support to stm32mp255
In-Reply-To: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
References: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220152732.2138260-5-hugues.fruchet@foss.st.com>

Add VDEC hardware video decoder support to STM32MP255.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi |  6 ++++++
 arch/arm64/boot/dts/st/stm32mp255.dtsi | 10 ++++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 96859d098ef8..8fc7e9199499 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -52,6 +52,12 @@ ck_icn_ls_mcu: ck-icn-ls-mcu {
 			compatible = "fixed-clock";
 			clock-frequency = <200000000>;
 		};
+
+		ck_icn_p_vdec: ck-icn-p-vdec {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <200000000>;
+		};
 	};
 
 	firmware {
diff --git a/arch/arm64/boot/dts/st/stm32mp255.dtsi b/arch/arm64/boot/dts/st/stm32mp255.dtsi
index e6fa596211f5..aea5096dac3c 100644
--- a/arch/arm64/boot/dts/st/stm32mp255.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp255.dtsi
@@ -6,4 +6,14 @@
 #include "stm32mp253.dtsi"
 
 / {
+	soc at 0 {
+		rifsc: rifsc-bus at 42080000 {
+			vdec: vdec at 480d0000 {
+				compatible = "st,stm32mp25-vdec";
+				reg = <0x480d0000 0x3c8>;
+				interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ck_icn_p_vdec>;
+			};
+		};
+	};
 };
-- 
2.25.1



From hugues.fruchet at foss.st.com  Wed Dec 20 07:27:29 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 16:27:29 +0100
Subject: [PATCH v4 2/5] media: hantro: add support for STM32MP25 VDEC
In-Reply-To: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
References: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220152732.2138260-3-hugues.fruchet@foss.st.com>

Add support for STM32MP25 VDEC video hardware decoder.
Support of H264/VP8 decoding.
No post-processor support.
VDEC has its own reset/clock/irq.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 drivers/media/platform/verisilicon/Kconfig    | 14 ++-
 drivers/media/platform/verisilicon/Makefile   |  3 +
 .../media/platform/verisilicon/hantro_drv.c   |  3 +
 .../media/platform/verisilicon/hantro_hw.h    |  1 +
 .../platform/verisilicon/stm32mp25_vdec_hw.c  | 92 +++++++++++++++++++
 5 files changed, 110 insertions(+), 3 deletions(-)
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c

diff --git a/drivers/media/platform/verisilicon/Kconfig b/drivers/media/platform/verisilicon/Kconfig
index e65b836b9d78..7642ff9cf96c 100644
--- a/drivers/media/platform/verisilicon/Kconfig
+++ b/drivers/media/platform/verisilicon/Kconfig
@@ -4,7 +4,7 @@ comment "Verisilicon media platform drivers"
 
 config VIDEO_HANTRO
 	tristate "Hantro VPU driver"
-	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || COMPILE_TEST
+	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || ARCH_STM32 || COMPILE_TEST
 	depends on V4L_MEM2MEM_DRIVERS
 	depends on VIDEO_DEV
 	select MEDIA_CONTROLLER
@@ -16,8 +16,8 @@ config VIDEO_HANTRO
 	select V4L2_VP9
 	help
 	  Support for the Hantro IP based Video Processing Units present on
-	  Rockchip and NXP i.MX8M SoCs, which accelerate video and image
-	  encoding and decoding.
+	  Rockchip, NXP i.MX8M and STM32MP25 SoCs, which accelerate video
+	  and image encoding and decoding.
 	  To compile this driver as a module, choose M here: the module
 	  will be called hantro-vpu.
 
@@ -52,3 +52,11 @@ config VIDEO_HANTRO_SUNXI
 	default y
 	help
 	  Enable support for H6 SoC.
+
+config VIDEO_HANTRO_STM32MP25
+	bool "Hantro STM32MP25 support"
+	depends on VIDEO_HANTRO
+	depends on ARCH_STM32 || COMPILE_TEST
+	default y
+	help
+	  Enable support for STM32MP25 SoCs.
diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
index 6ad2ef885920..5854e0f0dd32 100644
--- a/drivers/media/platform/verisilicon/Makefile
+++ b/drivers/media/platform/verisilicon/Makefile
@@ -39,3 +39,6 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_ROCKCHIP) += \
 
 hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
 		sunxi_vpu_hw.o
+
+hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
+		stm32mp25_vdec_hw.o
diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
index a9fa05ac56a9..2db27c333924 100644
--- a/drivers/media/platform/verisilicon/hantro_drv.c
+++ b/drivers/media/platform/verisilicon/hantro_drv.c
@@ -733,6 +733,9 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_SUNXI
 	{ .compatible = "allwinner,sun50i-h6-vpu-g2", .data = &sunxi_vpu_variant, },
+#endif
+#ifdef CONFIG_VIDEO_HANTRO_STM32MP25
+	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
 #endif
 	{ /* sentinel */ }
 };
diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
index 7f33f7b07ce4..b7eccc1a96fc 100644
--- a/drivers/media/platform/verisilicon/hantro_hw.h
+++ b/drivers/media/platform/verisilicon/hantro_hw.h
@@ -406,6 +406,7 @@ extern const struct hantro_variant rk3568_vpu_variant;
 extern const struct hantro_variant rk3588_vpu981_variant;
 extern const struct hantro_variant sama5d4_vdec_variant;
 extern const struct hantro_variant sunxi_vpu_variant;
+extern const struct hantro_variant stm32mp25_vdec_variant;
 
 extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
 extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
diff --git a/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
new file mode 100644
index 000000000000..aa8b0f751390
--- /dev/null
+++ b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * STM32MP25 VDEC video decoder driver
+ *
+ * Copyright (C) STMicroelectronics SA 2022
+ * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
+ *          for STMicroelectronics.
+ *
+ */
+
+#include "hantro.h"
+
+/*
+ * Supported formats.
+ */
+
+static const struct hantro_fmt stm32mp25_vdec_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_NV12,
+		.codec_mode = HANTRO_MODE_NONE,
+		.frmsize = {
+			.min_width = FMT_MIN_WIDTH,
+			.max_width = FMT_FHD_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = FMT_MIN_HEIGHT,
+			.max_height = FMT_FHD_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_VP8_FRAME,
+		.codec_mode = HANTRO_MODE_VP8_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = FMT_MIN_WIDTH,
+			.max_width = FMT_FHD_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = FMT_MIN_HEIGHT,
+			.max_height = FMT_FHD_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_H264_SLICE,
+		.codec_mode = HANTRO_MODE_H264_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = FMT_MIN_WIDTH,
+			.max_width = FMT_FHD_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = FMT_MIN_HEIGHT,
+			.max_height = FMT_FHD_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+};
+
+/*
+ * Supported codec ops.
+ */
+
+static const struct hantro_codec_ops stm32mp25_vdec_codec_ops[] = {
+	[HANTRO_MODE_VP8_DEC] = {
+		.run = hantro_g1_vp8_dec_run,
+		.reset = hantro_g1_reset,
+		.init = hantro_vp8_dec_init,
+		.exit = hantro_vp8_dec_exit,
+	},
+	[HANTRO_MODE_H264_DEC] = {
+		.run = hantro_g1_h264_dec_run,
+		.reset = hantro_g1_reset,
+		.init = hantro_h264_dec_init,
+		.exit = hantro_h264_dec_exit,
+	},
+};
+
+static const struct hantro_irq stm32mp25_irqs[] = {
+	{ "vdec", hantro_g1_irq },
+};
+
+static const char * const stm32mp25_clk_names[] = { "vdec-clk" };
+
+const struct hantro_variant stm32mp25_vdec_variant = {
+	.dec_fmts = stm32mp25_vdec_fmts,
+	.num_dec_fmts = ARRAY_SIZE(stm32mp25_vdec_fmts),
+	.codec = HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
+	.codec_ops = stm32mp25_vdec_codec_ops,
+	.irqs = stm32mp25_irqs,
+	.num_irqs = ARRAY_SIZE(stm32mp25_irqs),
+	.clk_names = stm32mp25_clk_names,
+	.num_clocks = ARRAY_SIZE(stm32mp25_clk_names),
+};
-- 
2.25.1



From hugues.fruchet at foss.st.com  Wed Dec 20 07:27:32 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Wed, 20 Dec 2023 16:27:32 +0100
Subject: [PATCH v4 5/5] arm64: dts: st: add video encoder support to stm32mp255
In-Reply-To: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
References: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
Message-ID: <20231220152732.2138260-6-hugues.fruchet@foss.st.com>

Add VENC hardware video encoder support to STM32MP255.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 6 ++++++
 arch/arm64/boot/dts/st/stm32mp255.dtsi | 7 +++++++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 8fc7e9199499..5dd4f3580a60 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -58,6 +58,12 @@ ck_icn_p_vdec: ck-icn-p-vdec {
 			compatible = "fixed-clock";
 			clock-frequency = <200000000>;
 		};
+
+		ck_icn_p_venc: ck-icn-p-venc {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <200000000>;
+		};
 	};
 
 	firmware {
diff --git a/arch/arm64/boot/dts/st/stm32mp255.dtsi b/arch/arm64/boot/dts/st/stm32mp255.dtsi
index aea5096dac3c..17f197c5b22b 100644
--- a/arch/arm64/boot/dts/st/stm32mp255.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp255.dtsi
@@ -14,6 +14,13 @@ vdec: vdec at 480d0000 {
 				interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&ck_icn_p_vdec>;
 			};
+
+			venc: venc at 480e0000 {
+				compatible = "st,stm32mp25-venc";
+				reg = <0x480e0000 0x800>;
+				interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ck_icn_ls_mcu>;
+			};
 		};
 	};
 };
-- 
2.25.1



From kamal.dasu at broadcom.com  Wed Dec 20 07:30:29 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Wed, 20 Dec 2023 10:30:29 -0500
Subject: [PATCH v6 0/2] mmc: add new sdhci reset sequence for brcm 74165b0
Message-ID: <20231220153031.38678-1-kamal.dasu@broadcom.com>

v6 changes:
 - PATCH 1/2 Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
 - PATCH 2/2 replaced readb_poll_timeout() with readb_poll_timeout_atomic()
   based on Review comments

v5 changes:
 - got rid of  'Reported by:' and 'Closes:' tags for all patches
   
v4 changes:
 - Fix for v3 changes that introduced dt schema errors
 - Fix for v3 changes that introduced sdhci-brcmstb build warnings 
 - Added proper PATCH format and cleanup commit messages as per
   review comments. Added proper 'Reported-by' and 'Closes' tags
 - Added comments for 32-bit register access as per review comments
 - Replaced wait loop polling with readb_poll_timeout() helper as per
   review comments for the sdhci-brcmstb driver changes
 
v3 changes:
 - Removed extra emun arrayfor possible compatible strings
 - shdci-brcmstb checkpatch warning fixes 

v2 changes:
 - Fixed devicetree bindings for shdci-brcmstb and removed 74165 compatible
   string as per review comments

Kamal Dasu (2):
  dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
  mmc: add new sdhci reset sequence for brcm 74165b0

 .../bindings/mmc/brcm,sdhci-brcmstb.yaml      |  4 +-
 drivers/mmc/host/sdhci-brcmstb.c              | 67 +++++++++++++++++--
 2 files changed, 63 insertions(+), 8 deletions(-)

-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231220/05043e73/attachment.p7s>

From kamal.dasu at broadcom.com  Wed Dec 20 07:30:30 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Wed, 20 Dec 2023 10:30:30 -0500
Subject: [PATCH v6 1/2] dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 74165b0
In-Reply-To: <20231220153031.38678-1-kamal.dasu@broadcom.com>
References: <20231220153031.38678-1-kamal.dasu@broadcom.com>
Message-ID: <20231220153031.38678-2-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

With newer sdio controller core used for 74165b0 we need to update
the compatibility with "brcm,bcm74165b0-sdhci".

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
index c028039bc477..cbd3d6c6c77f 100644
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
+++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
@@ -20,10 +20,8 @@ properties:
           - const: brcm,sdhci-brcmstb
       - items:
           - enum:
+              - brcm,bcm74165b0-sdhci
               - brcm,bcm7445-sdhci
-          - const: brcm,sdhci-brcmstb
-      - items:
-          - enum:
               - brcm,bcm7425-sdhci
           - const: brcm,sdhci-brcmstb
 
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231220/13e0dccc/attachment-0001.p7s>

From kamal.dasu at broadcom.com  Wed Dec 20 07:30:31 2023
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Wed, 20 Dec 2023 10:30:31 -0500
Subject: [PATCH v6 2/2] mmc: add new sdhci reset sequence for brcm 74165b0
In-Reply-To: <20231220153031.38678-1-kamal.dasu@broadcom.com>
References: <20231220153031.38678-1-kamal.dasu@broadcom.com>
Message-ID: <20231220153031.38678-3-kamal.dasu@broadcom.com>

From: Kamal Dasu <kdasu at broadcom.com>

74165b0 shall use a new sdio controller core version which
requires a different reset sequence. For core reset we use
sdhci_reset. For CMD and/or DATA reset added a new function
to also enable SDHCI clocks SDHCI_CLOCK_CARD_EN
SDHCI_CLOCK_INT_EN along with the SDHCI_RESET_CMD and/or
SDHCI_RESET_DATA fields.

Signed-off-by: Kamal Dasu <kdasu at broadcom.com>
---
 drivers/mmc/host/sdhci-brcmstb.c | 67 +++++++++++++++++++++++++++++---
 1 file changed, 62 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index c23251bb95f3..f171980b014e 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -6,6 +6,7 @@
  */
 
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/mmc/host.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -44,8 +45,13 @@ struct brcmstb_match_priv {
 
 static inline void enable_clock_gating(struct sdhci_host *host)
 {
+	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
 	u32 reg;
 
+	if (!(priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK))
+		return;
+
 	reg = sdhci_readl(host, SDHCI_VENDOR);
 	reg |= SDHCI_VENDOR_GATE_SDCLK_EN;
 	sdhci_writel(host, reg, SDHCI_VENDOR);
@@ -53,14 +59,51 @@ static inline void enable_clock_gating(struct sdhci_host *host)
 
 static void brcmstb_reset(struct sdhci_host *host, u8 mask)
 {
-	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_brcmstb_priv *priv = sdhci_pltfm_priv(pltfm_host);
-
 	sdhci_and_cqhci_reset(host, mask);
 
 	/* Reset will clear this, so re-enable it */
-	if (priv->flags & BRCMSTB_PRIV_FLAGS_GATE_CLOCK)
-		enable_clock_gating(host);
+	enable_clock_gating(host);
+}
+
+static void brcmstb_sdhci_reset_cmd_data(struct sdhci_host *host, u8 mask)
+{
+	int ret;
+	u32 reg;
+	u32 new_mask = (mask &  (SDHCI_RESET_CMD | SDHCI_RESET_DATA)) << 24;
+
+	/*
+	 * SDHCI_CLOCK_CONTROL register CARD_EN and CLOCK_INT_EN bits shall
+	 * be set along with SOFTWARE_RESET register RESET_CMD or RESET_DATA
+	 * bits, hence access SDHCI_CLOCK_CONTROL register as 32-bit register
+	 */
+	new_mask |= SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN;
+	reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
+	sdhci_writel(host, reg | new_mask, SDHCI_CLOCK_CONTROL);
+
+	reg = sdhci_readb(host, SDHCI_SOFTWARE_RESET);
+	ret = readb_poll_timeout_atomic(host->ioaddr + SDHCI_SOFTWARE_RESET,
+					reg, reg & mask, 10, 10000);
+
+	if (ret) {
+		pr_err("%s: Reset 0x%x never completed.\n",
+		       mmc_hostname(host->mmc), (int)mask);
+		sdhci_err_stats_inc(host, CTRL_TIMEOUT);
+		sdhci_dumpregs(host);
+	}
+}
+
+static void brcmstb_reset_74165b0(struct sdhci_host *host, u8 mask)
+{
+	/* take care of RESET_ALL as usual */
+	if (mask & SDHCI_RESET_ALL)
+		sdhci_and_cqhci_reset(host, SDHCI_RESET_ALL);
+
+	/* cmd and/or data treated differently on this core */
+	if (mask & (SDHCI_RESET_CMD | SDHCI_RESET_DATA))
+		brcmstb_sdhci_reset_cmd_data(host, mask);
+
+	/* Reset will clear this, so re-enable it */
+	enable_clock_gating(host);
 }
 
 static void sdhci_brcmstb_hs400es(struct mmc_host *mmc, struct mmc_ios *ios)
@@ -162,6 +205,13 @@ static struct sdhci_ops sdhci_brcmstb_ops_7216 = {
 	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
 };
 
+static struct sdhci_ops sdhci_brcmstb_ops_74165b0 = {
+	.set_clock = sdhci_brcmstb_set_clock,
+	.set_bus_width = sdhci_set_bus_width,
+	.reset = brcmstb_reset_74165b0,
+	.set_uhs_signaling = sdhci_brcmstb_set_uhs_signaling,
+};
+
 static struct brcmstb_match_priv match_priv_7425 = {
 	.flags = BRCMSTB_MATCH_FLAGS_NO_64BIT |
 	BRCMSTB_MATCH_FLAGS_BROKEN_TIMEOUT,
@@ -179,10 +229,17 @@ static const struct brcmstb_match_priv match_priv_7216 = {
 	.ops = &sdhci_brcmstb_ops_7216,
 };
 
+static struct brcmstb_match_priv match_priv_74165b0 = {
+	.flags = BRCMSTB_MATCH_FLAGS_HAS_CLOCK_GATE,
+	.hs400es = sdhci_brcmstb_hs400es,
+	.ops = &sdhci_brcmstb_ops_74165b0,
+};
+
 static const struct of_device_id __maybe_unused sdhci_brcm_of_match[] = {
 	{ .compatible = "brcm,bcm7425-sdhci", .data = &match_priv_7425 },
 	{ .compatible = "brcm,bcm7445-sdhci", .data = &match_priv_7445 },
 	{ .compatible = "brcm,bcm7216-sdhci", .data = &match_priv_7216 },
+	{ .compatible = "brcm,bcm74165b0-sdhci", .data = &match_priv_74165b0 },
 	{},
 };
 
-- 
2.17.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231220/64d2e167/attachment.p7s>

From david at redhat.com  Wed Dec 20 07:35:30 2023
From: david at redhat.com (David Hildenbrand)
Date: Wed, 20 Dec 2023 16:35:30 +0100
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <396cae5d-70e4-449f-af6c-2348b720d3a3@arm.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <dd227e51-c4b2-420b-a92a-65da85ab4018@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
 <9f99a3ca-051e-4b1b-81e9-8456d8e422ad@redhat.com>
 <c1913fa2-d313-4f05-a649-da69b6d31d2a@arm.com>
 <c244707c-8c0c-4593-ab45-d8f165dbc5ee@redhat.com>
 <ba6a5c11-34fb-40ca-b24a-f51a207464f2@arm.com>
 <5fcbf405-7e62-4b38-acc4-a9dd8cc91214@redhat.com>
 <396cae5d-70e4-449f-af6c-2348b720d3a3@arm.com>
Message-ID: <cfd88172-1624-4966-92c6-5197b26a820b@redhat.com>

On 20.12.23 16:05, Ryan Roberts wrote:
> On 20/12/2023 14:00, David Hildenbrand wrote:
>> [...]
>>
>>>>>
>>>>
>>>> gcc version 13.2.1 20231011 (Red Hat 13.2.1-4) (GCC)
>>>>
>>>>  ?From Fedora 38. So "a bit" newer :P
>>>>
>>>
>>> I'll retry with newer toolchain.
>>>
>>> FWIW, with the code fix and the original compiler:
>>>
>>> Fork, order-0, Apple M2:
>>> | kernel??????????????? |?? mean_rel |?? std_rel |
>>> |:----------------------|-----------:|----------:|
>>> | mm-unstable?????????? |?????? 0.0% |????? 0.8% |
>>> | hugetlb-rmap-cleanups |?????? 1.3% |????? 2.0% |
>>> | fork-batching???????? |?????? 4.3% |????? 1.0% |
>>>
>>> Fork, order-9, Apple M2:
>>> | kernel??????????????? |?? mean_rel |?? std_rel |
>>> |:----------------------|-----------:|----------:|
>>> | mm-unstable?????????? |?????? 0.0% |????? 0.8% |
>>> | hugetlb-rmap-cleanups |?????? 0.9% |????? 0.9% |
>>> | fork-batching???????? |???? -37.3% |????? 1.0% |
>>>
>>> Fork, order-0, Ampere Altra:
>>> | kernel??????????????? |?? mean_rel |?? std_rel |
>>> |:----------------------|-----------:|----------:|
>>> | mm-unstable?????????? |?????? 0.0% |????? 0.7% |
>>> | hugetlb-rmap-cleanups |?????? 3.2% |????? 0.7% |
>>> | fork-batching???????? |?????? 5.5% |????? 1.1% |
>>>
>>> Fork, order-9, Ampere Altra:
>>> | kernel??????????????? |?? mean_rel |?? std_rel |
>>> |:----------------------|-----------:|----------:|
>>> | mm-unstable?????????? |?????? 0.0% |????? 0.1% |
>>> | hugetlb-rmap-cleanups |?????? 0.5% |????? 0.1% |
>>> | fork-batching???????? |???? -10.4% |????? 0.1% |
>>>
>>
>> I just gave it another quick benchmark run on that Intel system.
>>
>> hugetlb-rmap-cleanups -> fork-batching
>>
>> order-0: 0.014114 -> 0.013848
>>
>> -1.9%
>>
>> order-9: 0.014262 -> 0.009410
>>
>> -34%
>>
>> Note that I disable SMT and turbo, and pin the test to one CPU, to make the
>> results as stable as possible. My kernel config has anything related to
>> debugging disabled.
>>
> 
> And with gcc 13.2 on arm64:
> 
> Fork, order-0, Apple M2 VM:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      1.5% |
> | hugetlb-rmap-cleanups |      -3.3% |      1.1% |
> | fork-batching         |      -3.6% |      1.4% |
> 
> Fork, order-9, Apple M2 VM:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      1.8% |
> | hugetlb-rmap-cleanups |      -5.8% |      1.3% |
> | fork-batching         |     -38.1% |      2.3% |
> 
> Fork, order-0, Ampere Altra:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      1.3% |
> | hugetlb-rmap-cleanups |      -0.1% |      0.4% |
> | fork-batching         |      -0.4% |      0.5% |
> 
> Fork, order-9, Ampere Altra:
> | kernel                |   mean_rel |   std_rel |
> |:----------------------|-----------:|----------:|
> | mm-unstable           |       0.0% |      0.1% |
> | hugetlb-rmap-cleanups |      -0.1% |      0.1% |
> | fork-batching         |     -13.9% |      0.1% |
> 
> 
> So all looking good. Compiler was the issue. Sorry for the noise.

No need to be sorry, good that we figured out what's going wrong here.

Weird that the compiler makes such a difference here.

> 
> So please go ahead with you rmap v2 stuff, and I'll wait for you to post the
> fork and zap batching patches properly, then rebase my arm64 contpte stuff on
> top and remeasure everything.

Yes, will get rmap v2 out soon, then start working on fork, and then try 
tackling zap. I have some holiday coming up, so it might take some time 
-- but there is plenty of time left.

-- 
Cheers,

David / dhildenb



From akpm at linux-foundation.org  Wed Dec 20 07:46:34 2023
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 20 Dec 2023 07:46:34 -0800
Subject: [PATCH v4 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <ZYJsBW0Y7Y+XhSgf@MiWiFi-R3L-srv>
References: <20231213055747.61826-1-bhe@redhat.com>
	<20231213055747.61826-6-bhe@redhat.com>
	<20231219-twitch-many-ca8877857182@spud>
	<ZYJsBW0Y7Y+XhSgf@MiWiFi-R3L-srv>
Message-ID: <20231220074634.cd736ec567cd7adf1e4c6d7e@linux-foundation.org>

On Wed, 20 Dec 2023 12:22:29 +0800 Baoquan He <bhe at redhat.com> wrote:

> Could you help fix the typo in subject?
> 
> [PATCH v4 5/7] kexec_file, ricv: print out debugging message if required
>                            ~~~ s/ricv/riscv/

I made that change.


From robh at kernel.org  Wed Dec 20 07:46:35 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 20 Dec 2023 09:46:35 -0600
Subject: [PATCH v4 09/15] dt-bindings: imx6q-pcie: remove reg and reg-name
In-Reply-To: <20231217051210.754832-10-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
 <20231217051210.754832-10-Frank.Li@nxp.com>
Message-ID: <20231220154635.GA266754-robh@kernel.org>

On Sun, Dec 17, 2023 at 12:12:04AM -0500, Frank Li wrote:
> snps,dw-pcie.yaml already have reg and reg-name information. Needn't
> duplciate here.

It does, but it doesn't define which of the possible names nor number 
and order of entries. It's primary purpose is to stop people from 
inventing their own names.

Rob


From james.clark at arm.com  Wed Dec 20 07:54:05 2023
From: james.clark at arm.com (James Clark)
Date: Wed, 20 Dec 2023 15:54:05 +0000
Subject: [PATCH RFC V2 1/4] perf/core: Add aux_pause, aux_resume,
 aux_start_paused
In-Reply-To: <20231208172449.35444-2-adrian.hunter@intel.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
 <20231208172449.35444-2-adrian.hunter@intel.com>
Message-ID: <0bbbcdb5-41eb-dd07-660a-2e5e4a0d59f0@arm.com>



On 08/12/2023 17:24, Adrian Hunter wrote:
> Hardware traces, such as instruction traces, can produce a vast amount of
> trace data, so being able to reduce tracing to more specific circumstances
> can be useful.
> 
> The ability to pause or resume tracing when another event happens, can do
> that.
> 
> Add ability for an event to "pause" or "resume" AUX area tracing.
> 
> Add aux_pause bit to perf_event_attr to indicate that, if the event
> happens, the associated AUX area tracing should be paused. Ditto
> aux_resume. Do not allow aux_pause and aux_resume to be set together.
> 
> Add aux_start_paused bit to perf_event_attr to indicate to an AUX area
> event that it should start in a "paused" state.
> 
> Add aux_paused to struct perf_event for AUX area events to keep track of
> the "paused" state. aux_paused is initialized to aux_start_paused.
> 
> Add PERF_EF_PAUSE and PERF_EF_RESUME modes for ->stop() and ->start()
> callbacks. Call as needed, during __perf_event_output(). Add
> aux_in_pause_resume to struct perf_buffer to prevent races with the NMI
> handler. Pause/resume in NMI context will miss out if it coincides with
> another pause/resume.
> 
> To use aux_pause or aux_resume, an event must be in a group with the AUX
> area event as the group leader.
> 
> Example (requires Intel PT and tools patches also):
> 
>  $ perf record --kcore -e '{intel_pt/aux-start-paused/k,syscalls:sys_enter_newuname/aux-resume/,syscalls:sys_exit_newuname/aux-pause/}' uname

I think it might be useful to have an aux-toggle option as well, and
then you could do sampling if you put it on a PMU counter with an
interval. Unless you can make two events for the same counter with
different intervals, and one does resume and the other does pause? I'm
not sure if that would work?

Other than that it looks ok. I got Coresight working with a couple of
changes to what you posted on here, but that can always be done more
thoroughly later if we leave PERF_PMU_CAP_AUX_PAUSE off Coresight for now.

Thanks
James


From robh at kernel.org  Wed Dec 20 07:54:32 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 20 Dec 2023 09:54:32 -0600
Subject: [PATCH v4 09/15] dt-bindings: imx6q-pcie: remove reg and reg-name
In-Reply-To: <20231217051210.754832-10-Frank.Li@nxp.com>
References: <20231217051210.754832-1-Frank.Li@nxp.com>
 <20231217051210.754832-10-Frank.Li@nxp.com>
Message-ID: <170308767228.277985.15603263470608919081.robh@kernel.org>


On Sun, 17 Dec 2023 00:12:04 -0500, Frank Li wrote:
> snps,dw-pcie.yaml already have reg and reg-name information. Needn't
> duplciate here.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> 
> Notes:
>     Change from v1 to v4:
>     - new patch at v4
> 
>  .../devicetree/bindings/pci/fsl,imx6q-pcie.yaml        | 10 ----------
>  1 file changed, 10 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>



From pbrobinson at gmail.com  Wed Dec 20 07:56:39 2023
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 20 Dec 2023 15:56:39 +0000
Subject: [PATCH] mfd: ti_am335x_tscadc: Fix TI SoC dependencies
Message-ID: <20231220155643.445849-1-pbrobinson@gmail.com>

The ti_am335x_tscadc is specific to some TI SoCs, update
the dependencies for those SoCs and compile testing.

Signed-off-by: Peter Robinson <pbrobinson at gmail.com>
---
 drivers/mfd/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 90ce58fd629e..68d71b4b55bd 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1483,6 +1483,7 @@ config MFD_SYSCON
 
 config MFD_TI_AM335X_TSCADC
 	tristate "TI ADC / Touch Screen chip support"
+	depends on ARCH_OMAP2PLUS || ARCH_K3 || COMPILE_TEST
 	select MFD_CORE
 	select REGMAP
 	select REGMAP_MMIO
-- 
2.43.0



From james.clark at arm.com  Wed Dec 20 07:59:01 2023
From: james.clark at arm.com (James Clark)
Date: Wed, 20 Dec 2023 15:59:01 +0000
Subject: [PATCH RFC V3 4/4] coresight: Have a stab at support for pause /
 resume
In-Reply-To: <20231215064242.36251-1-adrian.hunter@intel.com>
References: <20231208172449.35444-5-adrian.hunter@intel.com>
 <20231215064242.36251-1-adrian.hunter@intel.com>
Message-ID: <e80f75ea-99e9-e4d2-6477-443e521ef90a@arm.com>



On 15/12/2023 06:42, Adrian Hunter wrote:
> For discussion only, un-tested...
> 

If anyone wants to test Coresight, the diff below is required to get the
most basic use case working. It also probably needs more thought and
some edge case handling:

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 596c01e37624..bd0767356277 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -556,7 +556,8 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	struct etm_event_data *event_data;
 	struct list_head *path;
 
-	if (mode & PERF_EF_PAUSE && !READ_ONCE(ctxt->pr_allowed))
+	if ((mode & PERF_EF_PAUSE && !READ_ONCE(ctxt->pr_allowed)) ||
+	    event->hw.state == PERF_HES_STOPPED)
 		return;
 
 	WRITE_ONCE(ctxt->pr_allowed, 0);
@@ -573,9 +574,6 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	/* Clear the event_data as this ETM is stopping the trace. */
 	ctxt->event_data = NULL;
 
-	if (event->hw.state == PERF_HES_STOPPED)
-		goto out_pr_allowed;
-
 	/* We must have a valid event_data for a running event */
 	if (WARN_ON(!event_data))
 		return;
@@ -586,7 +584,7 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	 * nothing needs to be torn down other than outputting a
 	 * zero sized record.
 	 */
-	if (handle->event && (mode & PERF_EF_UPDATE) &&
+	if (handle->event && (mode & (PERF_EF_UPDATE | PERF_EF_PAUSE)) &&
 	    !cpumask_test_cpu(cpu, &event_data->mask)) {
 		event->hw.state = PERF_HES_STOPPED;
 		perf_aux_output_end(handle, 0);
@@ -616,7 +614,7 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	 * handle due to lack of buffer space), we don't
 	 * have to do anything here.
 	 */
-	if (handle->event && (mode & PERF_EF_UPDATE)) {
+	if (handle->event && (mode & (PERF_EF_UPDATE | PERF_EF_PAUSE))) {
 		if (WARN_ON_ONCE(handle->event != event))
 			return;
 
@@ -646,7 +644,6 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	/* Disabling the path make its elements available to other sessions */
 	coresight_disable_path(path);
 
-out_pr_allowed:
 	if (mode & PERF_EF_PAUSE)
 		WRITE_ONCE(ctxt->pr_allowed, 1);
 }
@@ -656,7 +653,7 @@ static int etm_event_add(struct perf_event *event, int mode)
 	int ret = 0;
 	struct hw_perf_event *hwc = &event->hw;
 
-	if (mode & PERF_EF_START && !READ_ONCE(event->aux_paused)) {
+	if (mode & PERF_EF_START) {
 		etm_event_start(event, 0);
 		if (hwc->state & PERF_HES_STOPPED)
 			ret = -EINVAL;
-- 
2.34.1



From ahalaney at redhat.com  Wed Dec 20 07:59:20 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Wed, 20 Dec 2023 09:59:20 -0600
Subject: [PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support for
 2.5G SGMII
In-Reply-To: <8b80ab09-8444-4c3d-83b0-c7dbf5e58658@quicinc.com>
References: <20231218071118.21879-1-quic_snehshah@quicinc.com>
 <4zbf5fmijxnajk7kygcjrcusf6tdnuzsqqboh23nr6f3rb3c4g@qkfofhq7jmv6>
 <8b80ab09-8444-4c3d-83b0-c7dbf5e58658@quicinc.com>
Message-ID: <wvzhz4fmtheculsiag4t2pn2kaggyle2mzhvawbs4m5isvqjto@lmaonvq3c3e7>

On Wed, Dec 20, 2023 at 01:02:45PM +0530, Sneh Shah wrote:
> 
> 
> On 12/18/2023 9:50 PM, Andrew Halaney wrote:
> > On Mon, Dec 18, 2023 at 12:41:18PM +0530, Sneh Shah wrote:
> >> Serdes phy needs to operate at 2500 mode for 2.5G speed and 1000
> >> mode for 1G/100M/10M speed.
> >> Added changes to configure serdes phy and mac based on link speed.
> >>
> >> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> >> ---
> >>  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 31 +++++++++++++++++--
> >>  1 file changed, 29 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> >> index d3bf42d0fceb..b3a28dc19161 100644
> >> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> >> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> >> @@ -21,6 +21,7 @@
> >>  #define RGMII_IO_MACRO_CONFIG2		0x1C
> >>  #define RGMII_IO_MACRO_DEBUG1		0x20
> >>  #define EMAC_SYSTEM_LOW_POWER_DEBUG	0x28
> >> +#define ETHQOS_MAC_AN_CTRL		0xE0
> >>  
> >>  /* RGMII_IO_MACRO_CONFIG fields */
> >>  #define RGMII_CONFIG_FUNC_CLK_EN		BIT(30)
> >> @@ -78,6 +79,10 @@
> >>  #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
> >>  #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
> >>  
> >> +/*ETHQOS_MAC_AN_CTRL bits */
> >> +#define ETHQOS_MAC_AN_CTRL_RAN			BIT(9)
> >> +#define ETHQOS_MAC_AN_CTRL_ANE			BIT(12)
> >> +
> > 
> > nit: space please add a space before ETHQOS_MAC_AN_CTRL
> > 
> will take care of this in next patch
> 
> >>  struct ethqos_emac_por {
> >>  	unsigned int offset;
> >>  	unsigned int value;
> >> @@ -109,6 +114,7 @@ struct qcom_ethqos {
> >>  	unsigned int num_por;
> >>  	bool rgmii_config_loopback_en;
> >>  	bool has_emac_ge_3;
> >> +	unsigned int serdes_speed;

Another nit as I look closer: I think this should be grouped by phy_mode
etc just for readability.

> >>  };
> >>  
> >>  static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
> >> @@ -600,27 +606,47 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
> >>  
> >>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
> >>  {
> >> -	int val;
> >> -
> >> +	int val, mac_an_value;
> >>  	val = readl(ethqos->mac_base + MAC_CTRL_REG);
> >> +	mac_an_value = readl(ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
> >>  
> >>  	switch (ethqos->speed) {
> >> +	case SPEED_2500:
> >> +		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
> >> +		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >> +			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >> +			      RGMII_IO_MACRO_CONFIG2);
> >> +		if (ethqos->serdes_speed != SPEED_2500)
> >> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> >> +		mac_an_value &= ~ETHQOS_MAC_AN_CTRL_ANE;
> >> +		break;
> >>  	case SPEED_1000:
> >>  		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
> >>  		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >>  			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >>  			      RGMII_IO_MACRO_CONFIG2);
> >> +		if (ethqos->serdes_speed != SPEED_1000)
> >> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> >> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
> >>  		break;
> >>  	case SPEED_100:
> >>  		val |= ETHQOS_MAC_CTRL_PORT_SEL | ETHQOS_MAC_CTRL_SPEED_MODE;
> >> +		if (ethqos->serdes_speed != SPEED_1000)
> >> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> >> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
> >>  		break;
> >>  	case SPEED_10:
> >>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
> >>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> >> +		if (ethqos->serdes_speed != SPEED_1000)
> >> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> >> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
> >>  		break;
> >>  	}
> >>  
> >>  	writel(val, ethqos->mac_base + MAC_CTRL_REG);
> >> +	writel(mac_an_value, ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
> >> +	ethqos->serdes_speed = ethqos->speed;
> > 
> > I see these bits are generic and there's some functions in stmmac_pcs.h
> > that muck with these...
> > 
> > Could you help me understand if this really should be Qualcomm specific,
> > or if this is something that should be considered for the more core bits
> > of the driver? I feel in either case we should take advantage of the
> > common definitions in that file if possible.
> > 
> we do have function dwmac_ctrl_ane in core driver which updates same registers. However, it does not have the option to reset ANE bit, it can only set bits. For SPEED_2500 we need to reset ANE bit. Hence I am adding it here. Not sure if we can extend dwmac_ctrl_ane function to reset bits as well.

I'd evaluate if you can update that function to clear the ANE bit when
the ane boolean is false. From the usage I see I feel that makes sense,
but correct me if you think I'm wrong.
At the very least let's use the defines from there, and possibly add a
new function if clearing is not acceptable in dwmac_ctrl_ane().

Stepping back, I was asking in general is the need to muck with ANE here
is a Qualcomm specific problem, or is that a generic thing that should be
handled in the core (and the phy_set_speed() bit stay here)? i.e. would
any dwmac5 based IP need to do something like this for SPEED_2500?

> >>  
> >>  	return val;
> >>  }
> >> @@ -789,6 +815,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> >>  				     "Failed to get serdes phy\n");
> >>  
> >>  	ethqos->speed = SPEED_1000;
> >> +	ethqos->serdes_speed = SPEED_1000;
> >>  	ethqos_update_link_clk(ethqos, SPEED_1000);
> >>  	ethqos_set_func_clk_en(ethqos);
> >>  
> >> -- 
> >> 2.17.1
> >>
> > 
> 



From ryan.roberts at arm.com  Wed Dec 20 07:59:26 2023
From: ryan.roberts at arm.com (Ryan Roberts)
Date: Wed, 20 Dec 2023 15:59:26 +0000
Subject: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork()
In-Reply-To: <cfd88172-1624-4966-92c6-5197b26a820b@redhat.com>
References: <20231218105100.172635-1-ryan.roberts@arm.com>
 <7c0236ad-01f3-437f-8b04-125d69e90dc0@redhat.com>
 <9a58b1a2-2c13-4fa0-8ffa-2b3d9655f1b6@arm.com>
 <28968568-f920-47ac-b6fd-87528ffd8f77@redhat.com>
 <10b0b562-c1c0-4a66-9aeb-a6bff5c218f6@arm.com>
 <8f8023cb-3c31-4ead-a9e6-03a10e9490c6@redhat.com>
 <da16a7e5-76dd-4150-9ade-54b0d227a1e1@arm.com>
 <699cb1db-51eb-460e-9ceb-1ce08ca03050@redhat.com>
 <da29a4c6-61f6-4203-9c82-9ce6e1c32552@arm.com>
 <2a8c5b6c-f5ae-43b2-99aa-6d10e79b76e1@redhat.com>
 <ade26f27-03af-4ad7-ad81-38b482f7572c@arm.com>
 <3194b8a5-3f72-4d9e-a267-fbdad32ad864@redhat.com>
 <f2f420cf-678d-466d-ac30-bc8251f16632@arm.com>
 <9f99a3ca-051e-4b1b-81e9-8456d8e422ad@redhat.com>
 <c1913fa2-d313-4f05-a649-da69b6d31d2a@arm.com>
 <c244707c-8c0c-4593-ab45-d8f165dbc5ee@redhat.com>
 <ba6a5c11-34fb-40ca-b24a-f51a207464f2@arm.com>
 <5fcbf405-7e62-4b38-acc4-a9dd8cc91214@redhat.com>
 <396cae5d-70e4-449f-af6c-2348b720d3a3@arm.com>
 <cfd88172-1624-4966-92c6-5197b26a820b@redhat.com>
Message-ID: <65b27029-28be-4744-85c3-6d3aa935aa03@arm.com>

On 20/12/2023 15:35, David Hildenbrand wrote:
> On 20.12.23 16:05, Ryan Roberts wrote:
>> On 20/12/2023 14:00, David Hildenbrand wrote:
>>> [...]
>>>
>>>>>>
>>>>>
>>>>> gcc version 13.2.1 20231011 (Red Hat 13.2.1-4) (GCC)
>>>>>
>>>>> ??From Fedora 38. So "a bit" newer :P
>>>>>
>>>>
>>>> I'll retry with newer toolchain.
>>>>
>>>> FWIW, with the code fix and the original compiler:
>>>>
>>>> Fork, order-0, Apple M2:
>>>> | kernel??????????????? |?? mean_rel |?? std_rel |
>>>> |:----------------------|-----------:|----------:|
>>>> | mm-unstable?????????? |?????? 0.0% |????? 0.8% |
>>>> | hugetlb-rmap-cleanups |?????? 1.3% |????? 2.0% |
>>>> | fork-batching???????? |?????? 4.3% |????? 1.0% |
>>>>
>>>> Fork, order-9, Apple M2:
>>>> | kernel??????????????? |?? mean_rel |?? std_rel |
>>>> |:----------------------|-----------:|----------:|
>>>> | mm-unstable?????????? |?????? 0.0% |????? 0.8% |
>>>> | hugetlb-rmap-cleanups |?????? 0.9% |????? 0.9% |
>>>> | fork-batching???????? |???? -37.3% |????? 1.0% |
>>>>
>>>> Fork, order-0, Ampere Altra:
>>>> | kernel??????????????? |?? mean_rel |?? std_rel |
>>>> |:----------------------|-----------:|----------:|
>>>> | mm-unstable?????????? |?????? 0.0% |????? 0.7% |
>>>> | hugetlb-rmap-cleanups |?????? 3.2% |????? 0.7% |
>>>> | fork-batching???????? |?????? 5.5% |????? 1.1% |
>>>>
>>>> Fork, order-9, Ampere Altra:
>>>> | kernel??????????????? |?? mean_rel |?? std_rel |
>>>> |:----------------------|-----------:|----------:|
>>>> | mm-unstable?????????? |?????? 0.0% |????? 0.1% |
>>>> | hugetlb-rmap-cleanups |?????? 0.5% |????? 0.1% |
>>>> | fork-batching???????? |???? -10.4% |????? 0.1% |
>>>>
>>>
>>> I just gave it another quick benchmark run on that Intel system.
>>>
>>> hugetlb-rmap-cleanups -> fork-batching
>>>
>>> order-0: 0.014114 -> 0.013848
>>>
>>> -1.9%
>>>
>>> order-9: 0.014262 -> 0.009410
>>>
>>> -34%
>>>
>>> Note that I disable SMT and turbo, and pin the test to one CPU, to make the
>>> results as stable as possible. My kernel config has anything related to
>>> debugging disabled.
>>>
>>
>> And with gcc 13.2 on arm64:
>>
>> Fork, order-0, Apple M2 VM:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 1.5% |
>> | hugetlb-rmap-cleanups |????? -3.3% |????? 1.1% |
>> | fork-batching???????? |????? -3.6% |????? 1.4% |
>>
>> Fork, order-9, Apple M2 VM:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 1.8% |
>> | hugetlb-rmap-cleanups |????? -5.8% |????? 1.3% |
>> | fork-batching???????? |???? -38.1% |????? 2.3% |
>>
>> Fork, order-0, Ampere Altra:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 1.3% |
>> | hugetlb-rmap-cleanups |????? -0.1% |????? 0.4% |
>> | fork-batching???????? |????? -0.4% |????? 0.5% |
>>
>> Fork, order-9, Ampere Altra:
>> | kernel??????????????? |?? mean_rel |?? std_rel |
>> |:----------------------|-----------:|----------:|
>> | mm-unstable?????????? |?????? 0.0% |????? 0.1% |
>> | hugetlb-rmap-cleanups |????? -0.1% |????? 0.1% |
>> | fork-batching???????? |???? -13.9% |????? 0.1% |
>>
>>
>> So all looking good. Compiler was the issue. Sorry for the noise.
> 
> No need to be sorry, good that we figured out what's going wrong here.
> 
> Weird that the compiler makes such a difference here.
> 
>>
>> So please go ahead with you rmap v2 stuff, and I'll wait for you to post the
>> fork and zap batching patches properly, then rebase my arm64 contpte stuff on
>> top and remeasure everything.
> 
> Yes, will get rmap v2 out soon, then start working on fork, and then try
> tackling zap. I have some holiday coming up, so it might take some time -- but
> there is plenty of time left.

Me too, I'll be out from end of Friday, returning on 2nd Jan.

Happy Christmas!

> 



From thierry.reding at gmail.com  Wed Dec 20 07:59:47 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Wed, 20 Dec 2023 16:59:47 +0100
Subject: [PATCH] pwm: meson: Simplify using dev_err_probe()
In-Reply-To: <20231212203352.wl3rzob75fct4lov@pengutronix.de>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
 <ZXbsDRslZNKCeJF9@orome.fritz.box>
 <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>
 <ZXcpswXxb1oQldp5@orome.fritz.box>
 <20231212203352.wl3rzob75fct4lov@pengutronix.de>
Message-ID: <ZYMPc50eBi6oBClu@orome.fritz.box>

On Tue, Dec 12, 2023 at 09:33:52PM +0100, Uwe Kleine-K?nig wrote:
> Hello Thierry,
> 
> On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> > It all adds up in the end and keeps me from doing other things.
> 
> If that means you'd be glad to give up the PWM maintainer job, I'd
> happily take over this post.

"Glad" is not the word that I would choose. After all I've looked after
this subsystem for almost 12 years, and letting it go isn't something
that is particularly easy. However, I do realize that my heart isn't in
it anymore and I don't want to be in the way of anyone.

So I'll take you up on that offer. Do you want to send a patch?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231220/a9181b43/attachment.sig>

From thierry.reding at gmail.com  Wed Dec 20 08:06:07 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Wed, 20 Dec 2023 17:06:07 +0100
Subject: [PATCH v11] pwm: bcm2835: Allow PWM driver to be used in atomic context
In-Reply-To: <20231220142426.1275052-1-sean@mess.org>
References: <20231220142426.1275052-1-sean@mess.org>
Message-ID: <170308520275.565566.6645944679194242340.b4-ty@gmail.com>


On Wed, 20 Dec 2023 14:24:25 +0000, Sean Young wrote:
> clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent
> rate changes using clk_rate_exclusive_get().
> 
> 

Applied, thanks!

[1/1] pwm: bcm2835: Allow PWM driver to be used in atomic context
      commit: fcc76072935935082efa127b97c7ddd880d2d793

Best regards,
-- 
Thierry Reding <thierry.reding at gmail.com>


From adrian.hunter at intel.com  Wed Dec 20 08:16:59 2023
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Wed, 20 Dec 2023 18:16:59 +0200
Subject: [PATCH RFC V2 1/4] perf/core: Add aux_pause, aux_resume,
 aux_start_paused
In-Reply-To: <0bbbcdb5-41eb-dd07-660a-2e5e4a0d59f0@arm.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
 <20231208172449.35444-2-adrian.hunter@intel.com>
 <0bbbcdb5-41eb-dd07-660a-2e5e4a0d59f0@arm.com>
Message-ID: <b37d6e3b-d9e2-48aa-b7e8-10a85c3f7aa8@intel.com>

On 20/12/23 17:54, James Clark wrote:
> 
> 
> On 08/12/2023 17:24, Adrian Hunter wrote:
>> Hardware traces, such as instruction traces, can produce a vast amount of
>> trace data, so being able to reduce tracing to more specific circumstances
>> can be useful.
>>
>> The ability to pause or resume tracing when another event happens, can do
>> that.
>>
>> Add ability for an event to "pause" or "resume" AUX area tracing.
>>
>> Add aux_pause bit to perf_event_attr to indicate that, if the event
>> happens, the associated AUX area tracing should be paused. Ditto
>> aux_resume. Do not allow aux_pause and aux_resume to be set together.
>>
>> Add aux_start_paused bit to perf_event_attr to indicate to an AUX area
>> event that it should start in a "paused" state.
>>
>> Add aux_paused to struct perf_event for AUX area events to keep track of
>> the "paused" state. aux_paused is initialized to aux_start_paused.
>>
>> Add PERF_EF_PAUSE and PERF_EF_RESUME modes for ->stop() and ->start()
>> callbacks. Call as needed, during __perf_event_output(). Add
>> aux_in_pause_resume to struct perf_buffer to prevent races with the NMI
>> handler. Pause/resume in NMI context will miss out if it coincides with
>> another pause/resume.
>>
>> To use aux_pause or aux_resume, an event must be in a group with the AUX
>> area event as the group leader.
>>
>> Example (requires Intel PT and tools patches also):
>>
>>  $ perf record --kcore -e '{intel_pt/aux-start-paused/k,syscalls:sys_enter_newuname/aux-resume/,syscalls:sys_exit_newuname/aux-pause/}' uname
> 
> I think it might be useful to have an aux-toggle option as well, and
> then you could do sampling if you put it on a PMU counter with an
> interval. Unless you can make two events for the same counter with
> different intervals, and one does resume and the other does pause? I'm
> not sure if that would work?

There is already ->snapshot_aux() for sampling. Is that what you mean?

> 
> Other than that it looks ok. I got Coresight working with a couple of
> changes to what you posted on here, but that can always be done more
> thoroughly later if we leave PERF_PMU_CAP_AUX_PAUSE off Coresight for now.

Thanks a lot for looking at this!



From nicolas.dufresne at collabora.com  Wed Dec 20 08:37:14 2023
From: nicolas.dufresne at collabora.com (Nicolas Dufresne)
Date: Wed, 20 Dec 2023 11:37:14 -0500
Subject: [PATCH v4 0/5] Add support for video hardware codec of
 STMicroelectronics STM32 SoC series
In-Reply-To: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
References: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
Message-ID: <f8205a1ba599b354032d88dc16b0b6b88f8c2cf8.camel@collabora.com>

Le mercredi 20 d?cembre 2023 ? 16:27 +0100, Hugues Fruchet a ?crit?:
> This patchset introduces support for VDEC video hardware decoder
> and VENC video hardware encoder of STMicroelectronics STM32MP25
> SoC series.
> 
> This initial support implements H264 decoding, VP8 decoding and
> JPEG encoding.
> 
> This has been tested on STM32MP257F-EV1 evaluation board.
> 
> ===========
> = history =
> ===========
> version 4:
>    - Fix comments from Nicolas about dropping encoder raw steps

As discussed in chat, The 4K resolution didn't work correctly, so all the
resolution have been set back to 1080p.

> 
> version 3:
>    - Fix remarks from Krzysztof Kozlowski:
>     - drop "items", we keep simple enum in such case
>     - drop second example - it is the same as the first
>    - Drop unused node labels as suggested by Conor Dooley
>    - Revisit min/max resolutions as suggested by Nicolas Dufresne
> 
> version 2:
>    - Fix remarks from Krzysztof Kozlowski on v1:
>     - single video-codec binding for both VDEC/VENC
>     - get rid of "-names"
>     - use of generic node name "video-codec"
> 
> version 1:
>   - Initial submission
> 
> Hugues Fruchet (5):
>   dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
>   media: hantro: add support for STM32MP25 VDEC
>   media: hantro: add support for STM32MP25 VENC
>   arm64: dts: st: add video decoder support to stm32mp255
>   arm64: dts: st: add video encoder support to stm32mp255
> 
>  .../media/st,stm32mp25-video-codec.yaml       |  50 ++++++++
>  arch/arm64/boot/dts/st/stm32mp251.dtsi        |  12 ++
>  arch/arm64/boot/dts/st/stm32mp255.dtsi        |  17 +++
>  drivers/media/platform/verisilicon/Kconfig    |  14 ++-
>  drivers/media/platform/verisilicon/Makefile   |   4 +
>  .../media/platform/verisilicon/hantro_drv.c   |   4 +
>  .../media/platform/verisilicon/hantro_hw.h    |   2 +
>  .../platform/verisilicon/stm32mp25_vdec_hw.c  |  92 ++++++++++++++
>  .../platform/verisilicon/stm32mp25_venc_hw.c  | 115 ++++++++++++++++++
>  9 files changed, 307 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
>  create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>  create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
> 



From nicolas.dufresne at collabora.com  Wed Dec 20 08:40:53 2023
From: nicolas.dufresne at collabora.com (Nicolas Dufresne)
Date: Wed, 20 Dec 2023 11:40:53 -0500
Subject: [PATCH v4 2/5] media: hantro: add support for STM32MP25 VDEC
In-Reply-To: <20231220152732.2138260-3-hugues.fruchet@foss.st.com>
References: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
	 <20231220152732.2138260-3-hugues.fruchet@foss.st.com>
Message-ID: <8c13951d539ea94f20a96b70ff8287419b597d74.camel@collabora.com>

Le mercredi 20 d?cembre 2023 ? 16:27 +0100, Hugues Fruchet a ?crit?:
> Add support for STM32MP25 VDEC video hardware decoder.
> Support of H264/VP8 decoding.
> No post-processor support.
> VDEC has its own reset/clock/irq.

I'd suggest adding:

  The resolution is currently limited to full HD as per test results.
  Higher resolutions results in visual distortion.

With similar minor addition (please suggest something you are confortable with):

Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>

> 
> Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
> ---
>  drivers/media/platform/verisilicon/Kconfig    | 14 ++-
>  drivers/media/platform/verisilicon/Makefile   |  3 +
>  .../media/platform/verisilicon/hantro_drv.c   |  3 +
>  .../media/platform/verisilicon/hantro_hw.h    |  1 +
>  .../platform/verisilicon/stm32mp25_vdec_hw.c  | 92 +++++++++++++++++++
>  5 files changed, 110 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> 
> diff --git a/drivers/media/platform/verisilicon/Kconfig b/drivers/media/platform/verisilicon/Kconfig
> index e65b836b9d78..7642ff9cf96c 100644
> --- a/drivers/media/platform/verisilicon/Kconfig
> +++ b/drivers/media/platform/verisilicon/Kconfig
> @@ -4,7 +4,7 @@ comment "Verisilicon media platform drivers"
>  
>  config VIDEO_HANTRO
>  	tristate "Hantro VPU driver"
> -	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || COMPILE_TEST
> +	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || ARCH_STM32 || COMPILE_TEST
>  	depends on V4L_MEM2MEM_DRIVERS
>  	depends on VIDEO_DEV
>  	select MEDIA_CONTROLLER
> @@ -16,8 +16,8 @@ config VIDEO_HANTRO
>  	select V4L2_VP9
>  	help
>  	  Support for the Hantro IP based Video Processing Units present on
> -	  Rockchip and NXP i.MX8M SoCs, which accelerate video and image
> -	  encoding and decoding.
> +	  Rockchip, NXP i.MX8M and STM32MP25 SoCs, which accelerate video
> +	  and image encoding and decoding.
>  	  To compile this driver as a module, choose M here: the module
>  	  will be called hantro-vpu.
>  
> @@ -52,3 +52,11 @@ config VIDEO_HANTRO_SUNXI
>  	default y
>  	help
>  	  Enable support for H6 SoC.
> +
> +config VIDEO_HANTRO_STM32MP25
> +	bool "Hantro STM32MP25 support"
> +	depends on VIDEO_HANTRO
> +	depends on ARCH_STM32 || COMPILE_TEST
> +	default y
> +	help
> +	  Enable support for STM32MP25 SoCs.
> diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
> index 6ad2ef885920..5854e0f0dd32 100644
> --- a/drivers/media/platform/verisilicon/Makefile
> +++ b/drivers/media/platform/verisilicon/Makefile
> @@ -39,3 +39,6 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_ROCKCHIP) += \
>  
>  hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
>  		sunxi_vpu_hw.o
> +
> +hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
> +		stm32mp25_vdec_hw.o
> diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
> index a9fa05ac56a9..2db27c333924 100644
> --- a/drivers/media/platform/verisilicon/hantro_drv.c
> +++ b/drivers/media/platform/verisilicon/hantro_drv.c
> @@ -733,6 +733,9 @@ static const struct of_device_id of_hantro_match[] = {
>  #endif
>  #ifdef CONFIG_VIDEO_HANTRO_SUNXI
>  	{ .compatible = "allwinner,sun50i-h6-vpu-g2", .data = &sunxi_vpu_variant, },
> +#endif
> +#ifdef CONFIG_VIDEO_HANTRO_STM32MP25
> +	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
>  #endif
>  	{ /* sentinel */ }
>  };
> diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
> index 7f33f7b07ce4..b7eccc1a96fc 100644
> --- a/drivers/media/platform/verisilicon/hantro_hw.h
> +++ b/drivers/media/platform/verisilicon/hantro_hw.h
> @@ -406,6 +406,7 @@ extern const struct hantro_variant rk3568_vpu_variant;
>  extern const struct hantro_variant rk3588_vpu981_variant;
>  extern const struct hantro_variant sama5d4_vdec_variant;
>  extern const struct hantro_variant sunxi_vpu_variant;
> +extern const struct hantro_variant stm32mp25_vdec_variant;
>  
>  extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
>  extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
> diff --git a/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> new file mode 100644
> index 000000000000..aa8b0f751390
> --- /dev/null
> +++ b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * STM32MP25 VDEC video decoder driver
> + *
> + * Copyright (C) STMicroelectronics SA 2022
> + * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
> + *          for STMicroelectronics.
> + *
> + */
> +
> +#include "hantro.h"
> +
> +/*
> + * Supported formats.
> + */
> +
> +static const struct hantro_fmt stm32mp25_vdec_fmts[] = {
> +	{
> +		.fourcc = V4L2_PIX_FMT_NV12,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.frmsize = {
> +			.min_width = FMT_MIN_WIDTH,
> +			.max_width = FMT_FHD_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = FMT_MIN_HEIGHT,
> +			.max_height = FMT_FHD_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_VP8_FRAME,
> +		.codec_mode = HANTRO_MODE_VP8_DEC,
> +		.max_depth = 2,
> +		.frmsize = {
> +			.min_width = FMT_MIN_WIDTH,
> +			.max_width = FMT_FHD_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = FMT_MIN_HEIGHT,
> +			.max_height = FMT_FHD_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_H264_SLICE,
> +		.codec_mode = HANTRO_MODE_H264_DEC,
> +		.max_depth = 2,
> +		.frmsize = {
> +			.min_width = FMT_MIN_WIDTH,
> +			.max_width = FMT_FHD_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = FMT_MIN_HEIGHT,
> +			.max_height = FMT_FHD_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +};
> +
> +/*
> + * Supported codec ops.
> + */
> +
> +static const struct hantro_codec_ops stm32mp25_vdec_codec_ops[] = {
> +	[HANTRO_MODE_VP8_DEC] = {
> +		.run = hantro_g1_vp8_dec_run,
> +		.reset = hantro_g1_reset,
> +		.init = hantro_vp8_dec_init,
> +		.exit = hantro_vp8_dec_exit,
> +	},
> +	[HANTRO_MODE_H264_DEC] = {
> +		.run = hantro_g1_h264_dec_run,
> +		.reset = hantro_g1_reset,
> +		.init = hantro_h264_dec_init,
> +		.exit = hantro_h264_dec_exit,
> +	},
> +};
> +
> +static const struct hantro_irq stm32mp25_irqs[] = {
> +	{ "vdec", hantro_g1_irq },
> +};
> +
> +static const char * const stm32mp25_clk_names[] = { "vdec-clk" };
> +
> +const struct hantro_variant stm32mp25_vdec_variant = {
> +	.dec_fmts = stm32mp25_vdec_fmts,
> +	.num_dec_fmts = ARRAY_SIZE(stm32mp25_vdec_fmts),
> +	.codec = HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
> +	.codec_ops = stm32mp25_vdec_codec_ops,
> +	.irqs = stm32mp25_irqs,
> +	.num_irqs = ARRAY_SIZE(stm32mp25_irqs),
> +	.clk_names = stm32mp25_clk_names,
> +	.num_clocks = ARRAY_SIZE(stm32mp25_clk_names),
> +};



From nicolas.dufresne at collabora.com  Wed Dec 20 08:41:30 2023
From: nicolas.dufresne at collabora.com (Nicolas Dufresne)
Date: Wed, 20 Dec 2023 11:41:30 -0500
Subject: [PATCH v4 3/5] media: hantro: add support for STM32MP25 VENC
In-Reply-To: <20231220152732.2138260-4-hugues.fruchet@foss.st.com>
References: <20231220152732.2138260-1-hugues.fruchet@foss.st.com>
	 <20231220152732.2138260-4-hugues.fruchet@foss.st.com>
Message-ID: <8661158082baf37cfd6bac7004c695b805233bd5.camel@collabora.com>

Le mercredi 20 d?cembre 2023 ? 16:27 +0100, Hugues Fruchet a ?crit?:
> Add support for STM32MP25 VENC video hardware encoder.
> Support of JPEG encoding.
> VENC has its own reset/clock/irq.
> 
> Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>

Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>

> ---
>  drivers/media/platform/verisilicon/Makefile   |   3 +-
>  .../media/platform/verisilicon/hantro_drv.c   |   1 +
>  .../media/platform/verisilicon/hantro_hw.h    |   1 +
>  .../platform/verisilicon/stm32mp25_venc_hw.c  | 115 ++++++++++++++++++
>  4 files changed, 119 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
> 
> diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
> index 5854e0f0dd32..3bf43fdbedc1 100644
> --- a/drivers/media/platform/verisilicon/Makefile
> +++ b/drivers/media/platform/verisilicon/Makefile
> @@ -41,4 +41,5 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
>  		sunxi_vpu_hw.o
>  
>  hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
> -		stm32mp25_vdec_hw.o
> +		stm32mp25_vdec_hw.o \
> +		stm32mp25_venc_hw.o
> diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
> index 2db27c333924..4d97a8ac03de 100644
> --- a/drivers/media/platform/verisilicon/hantro_drv.c
> +++ b/drivers/media/platform/verisilicon/hantro_drv.c
> @@ -736,6 +736,7 @@ static const struct of_device_id of_hantro_match[] = {
>  #endif
>  #ifdef CONFIG_VIDEO_HANTRO_STM32MP25
>  	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
> +	{ .compatible = "st,stm32mp25-venc", .data = &stm32mp25_venc_variant, },
>  #endif
>  	{ /* sentinel */ }
>  };
> diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
> index b7eccc1a96fc..70c72e9d11d5 100644
> --- a/drivers/media/platform/verisilicon/hantro_hw.h
> +++ b/drivers/media/platform/verisilicon/hantro_hw.h
> @@ -407,6 +407,7 @@ extern const struct hantro_variant rk3588_vpu981_variant;
>  extern const struct hantro_variant sama5d4_vdec_variant;
>  extern const struct hantro_variant sunxi_vpu_variant;
>  extern const struct hantro_variant stm32mp25_vdec_variant;
> +extern const struct hantro_variant stm32mp25_venc_variant;
>  
>  extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
>  extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
> diff --git a/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
> new file mode 100644
> index 000000000000..0ff0f073b922
> --- /dev/null
> +++ b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * STM32MP25 VENC video encoder driver
> + *
> + * Copyright (C) STMicroelectronics SA 2022
> + * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
> + *          for STMicroelectronics.
> + *
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/reset.h>
> +
> +#include "hantro.h"
> +#include "hantro_jpeg.h"
> +#include "hantro_h1_regs.h"
> +
> +/*
> + * Supported formats.
> + */
> +
> +static const struct hantro_fmt stm32mp25_venc_fmts[] = {
> +	{
> +		.fourcc = V4L2_PIX_FMT_YUV420M,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420P,
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_NV12M,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420SP,
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_YUYV,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUYV422,
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_UYVY,
> +		.codec_mode = HANTRO_MODE_NONE,
> +		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_UYVY422,
> +	},
> +	{
> +		.fourcc = V4L2_PIX_FMT_JPEG,
> +		.codec_mode = HANTRO_MODE_JPEG_ENC,
> +		.max_depth = 2,
> +		.header_size = JPEG_HEADER_SIZE,
> +		.frmsize = {
> +			.min_width = 96,
> +			.max_width = FMT_4K_WIDTH,
> +			.step_width = MB_DIM,
> +			.min_height = 96,
> +			.max_height = FMT_4K_HEIGHT,
> +			.step_height = MB_DIM,
> +		},
> +	},
> +};
> +
> +static irqreturn_t stm32mp25_venc_irq(int irq, void *dev_id)
> +{
> +	struct hantro_dev *vpu = dev_id;
> +	enum vb2_buffer_state state;
> +	u32 status;
> +
> +	status = vepu_read(vpu, H1_REG_INTERRUPT);
> +	state = (status & H1_REG_INTERRUPT_FRAME_RDY) ?
> +		VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
> +
> +	vepu_write(vpu, H1_REG_INTERRUPT_BIT, H1_REG_INTERRUPT);
> +
> +	hantro_irq_done(vpu, state);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static void stm32mp25_venc_reset(struct hantro_ctx *ctx)
> +{
> +}
> +
> +/*
> + * Supported codec ops.
> + */
> +
> +static const struct hantro_codec_ops stm32mp25_venc_codec_ops[] = {
> +	[HANTRO_MODE_JPEG_ENC] = {
> +		.run = hantro_h1_jpeg_enc_run,
> +		.reset = stm32mp25_venc_reset,
> +		.done = hantro_h1_jpeg_enc_done,
> +	},
> +};
> +
> +/*
> + * Variants.
> + */
> +
> +static const struct hantro_irq stm32mp25_venc_irqs[] = {
> +	{ "venc", stm32mp25_venc_irq },
> +};
> +
> +static const char * const stm32mp25_venc_clk_names[] = {
> +	"venc-clk"
> +};
> +
> +const struct hantro_variant stm32mp25_venc_variant = {
> +	.enc_fmts = stm32mp25_venc_fmts,
> +	.num_enc_fmts = ARRAY_SIZE(stm32mp25_venc_fmts),
> +	.codec = HANTRO_JPEG_ENCODER,
> +	.codec_ops = stm32mp25_venc_codec_ops,
> +	.irqs = stm32mp25_venc_irqs,
> +	.num_irqs = ARRAY_SIZE(stm32mp25_venc_irqs),
> +	.clk_names = stm32mp25_venc_clk_names,
> +	.num_clocks = ARRAY_SIZE(stm32mp25_venc_clk_names)
> +};
> +



From gregory.clement at bootlin.com  Wed Dec 20 08:49:51 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Wed, 20 Dec 2023 17:49:51 +0100
Subject: [GIT PULL] ARM: mvebu: arm for v6.8 (#1)
Message-ID: <87r0jgbyz4.fsf@BL-laptop>

Hi,

Here is the first pull request for arm for mvebu for v6.8.

Gregory

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-arm-6.8-1

for you to fetch changes up to a2c568ad9936014020e5586a0bdb5f5bf1d94e21:

  MAINTAINERS: add Marvell MBus driver to Marvell EBU SoCs support (2023-12-15 15:25:11 +0100)

----------------------------------------------------------------
mvebu arm for 6.8 (part 1)

Update MAINTAINRES entries for Marvell MBus driver

----------------------------------------------------------------
Lukas Bulwahn (1):
      MAINTAINERS: add Marvell MBus driver to Marvell EBU SoCs support

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Wed Dec 20 08:52:17 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Wed, 20 Dec 2023 17:52:17 +0100
Subject: [GIT PULL] ARM: mvebu: dt for v6.8 (#1)
Message-ID: <87o7ekbyv2.fsf@BL-laptop>

Hi,

Here is the first pull request for dt for mvebu for v6.8.

Gregory

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt-6.8-1

for you to fetch changes up to 62f34e3ec2befcbe5d8a5003f21d53dab80bb03c:

  ARM: dts: marvell: make dts use gpio-fan matrix instead of array (2023-12-15 15:26:41 +0100)

----------------------------------------------------------------
mvebu dt for 6.8 (part 1)

Fix dt for gpio and switch nodes

----------------------------------------------------------------
David Heidelberg (1):
      ARM: dts: marvell: make dts use gpio-fan matrix instead of array

Linus Walleij (1):
      ARM: dts: marvell: Fix some common switch mistakes

 arch/arm/boot/dts/marvell/armada-370-rd.dts        |  26 +++---
 .../dts/marvell/armada-370-seagate-nas-2bay.dts    |   8 +-
 .../dts/marvell/armada-370-seagate-nas-4bay.dts    |   8 +-
 .../dts/marvell/armada-370-synology-ds213j.dts     |  16 ++--
 .../dts/marvell/armada-381-netgear-gs110emx.dts    |  44 +++++----
 .../dts/marvell/armada-385-clearfog-gtr-l8.dts     |  38 ++++----
 .../dts/marvell/armada-385-clearfog-gtr-s4.dts     |  22 ++---
 arch/arm/boot/dts/marvell/armada-385-linksys.dtsi  |  18 ++--
 .../boot/dts/marvell/armada-385-synology-ds116.dts |  16 ++--
 .../boot/dts/marvell/armada-385-turris-omnia.dts   |  20 ++--
 arch/arm/boot/dts/marvell/armada-388-clearfog.dts  |  20 ++--
 arch/arm/boot/dts/marvell/armada-388-gp.dts        |   4 +-
 .../boot/dts/marvell/armada-xp-linksys-mamba.dts   |  18 ++--
 arch/arm/boot/dts/marvell/kirkwood-dnskw.dtsi      |   6 +-
 .../dts/marvell/kirkwood-linkstation-6282.dtsi     |   9 +-
 .../dts/marvell/kirkwood-linkstation-lswxl.dts     |   9 +-
 arch/arm/boot/dts/marvell/kirkwood-lsxl.dtsi       |   9 +-
 arch/arm/boot/dts/marvell/kirkwood-ns2max.dts      |  18 ++--
 arch/arm/boot/dts/marvell/kirkwood-ns2mini.dts     |  18 ++--
 arch/arm/boot/dts/marvell/kirkwood-synology.dtsi   | 102 +++++++++++----------
 .../boot/dts/marvell/mvebu-linkstation-fan.dtsi    |   8 +-
 21 files changed, 217 insertions(+), 220 deletions(-)

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Wed Dec 20 08:55:22 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Wed, 20 Dec 2023 17:55:22 +0100
Subject: [GIT PULL] ARM: mvebu: dt64 for v6.8 (#1)
Message-ID: <87le9obypx.fsf@BL-laptop>

Hi,

Here is the first pull request for dt64 for mvebu for v6.8.

Gregory

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt64-6.8-1

for you to fetch changes up to c11e7732a90c21155de8db40dbba84f043520821:

  arm64: dts: cn913x: add device trees for COM Express boards (2023-12-15 15:51:33 +0100)

----------------------------------------------------------------
mvebu dt64 for 6.8 (part 1)

Add devices tree for CN9130 and CN9131 COM Express Boards
Fix device tree for Turris Mox and for switch nodes

----------------------------------------------------------------
Elad Nachman (3):
      MAINTAINERS: add ac5 to list of maintained Marvell dts files
      dt-bindings: arm64: add Marvell COM Express boards
      arm64: dts: cn913x: add device trees for COM Express boards

Linus Walleij (2):
      ARM64: dts: marvell: Fix some common switch mistakes
      ARM64: dts: Add special compatibles for the Turris Mox

Sjoerd Simons (1):
      arm64: dts: armada-3720-turris-mox: set irq type for RTC

 .../bindings/arm/marvell/armada-7k-8k.yaml         |  22 +++++
 MAINTAINERS                                        |   3 +-
 arch/arm64/boot/dts/marvell/Makefile               |   1 +
 .../boot/dts/marvell/ac5x-rd-carrier-cn9131.dts    |  44 +++++++++
 arch/arm64/boot/dts/marvell/ac5x-rd-carrier.dtsi   |  34 +++++++
 .../dts/marvell/armada-3720-espressobin-ultra.dts  |  14 +--
 .../boot/dts/marvell/armada-3720-espressobin.dtsi  |  20 ++--
 .../boot/dts/marvell/armada-3720-gl-mv1000.dts     |  20 ++--
 .../boot/dts/marvell/armada-3720-turris-mox.dts    |  99 ++++++++++---------
 .../boot/dts/marvell/armada-7040-mochabin.dts      |  24 +++--
 .../dts/marvell/armada-8040-clearfog-gt-8k.dts     |  22 ++---
 arch/arm64/boot/dts/marvell/cn9130-crb.dtsi        |  42 ++++----
 .../boot/dts/marvell/cn9130-db-comexpress.dtsi     |  96 ++++++++++++++++++
 .../boot/dts/marvell/cn9131-db-comexpress.dtsi     | 108 +++++++++++++++++++++
 14 files changed, 428 insertions(+), 121 deletions(-)
 create mode 100644 arch/arm64/boot/dts/marvell/ac5x-rd-carrier-cn9131.dts
 create mode 100644 arch/arm64/boot/dts/marvell/ac5x-rd-carrier.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/cn9130-db-comexpress.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/cn9131-db-comexpress.dtsi

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Wed Dec 20 08:57:43 2023
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Wed, 20 Dec 2023 17:57:43 +0100
Subject: [GIT PULL] ARM: mvebu: drivers for v6.8 (#1)
Message-ID: <87il4sbym0.fsf@BL-laptop>

Hi,

Here is the first pull request for drivers for mvebu for v6.8.

Gregory

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-drivers-6.8-1

for you to fetch changes up to aaafe88d5500ba18b33be72458439367ef878788:

  bus: moxtet: Add spi device table (2023-12-15 15:44:11 +0100)

----------------------------------------------------------------
mvebu drivers for 6.8 (part 1)

moxtet bus fixes

----------------------------------------------------------------
Sjoerd Simons (2):
      bus: moxtet: Mark the irq as shared
      bus: moxtet: Add spi device table

 drivers/bus/moxtet.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From jernej.skrabec at gmail.com  Wed Dec 20 09:04:28 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 20 Dec 2023 18:04:28 +0100
Subject: [PATCH] gmac: sun8i: r40: add gmac tx_delay support
In-Reply-To: <ZYKvCQBD-SY9uVLF@debian.cyg>
References: <ZYKvCQBD-SY9uVLF@debian.cyg>
Message-ID: <2370947.NG923GbCHz@jernej-laptop>

Dne sreda, 20. december 2023 ob 10:08:25 CET je fuyao napisal(a):
> r40 can support tx_delay, so we add it.

I don't see how. User manual, 3.3.4.64. GMAC Clock Register talks only
about RX delay.

Best regards,
Jernej

> 
> Signed-off-by: fuyao <fuyao1697 at cyg.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> index 137741b94122..fd07573afc9b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -127,6 +127,7 @@ static const struct emac_variant emac_variant_r40 = {
>  	.support_mii = true,
>  	.support_rgmii = true,
>  	.rx_delay_max = 7,
> +	.tx_delay_max = 7,
>  };
>  
>  static const struct emac_variant emac_variant_a64 = {
> 






From jernej.skrabec at gmail.com  Wed Dec 20 09:07:08 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Wed, 20 Dec 2023 18:07:08 +0100
Subject: [PATCH] arm64: dts: allwinner: Orange Pi One Plus PHY support
In-Reply-To: <6p6d6l7mxof227mmdud2wsbgjr45dlqjxithpfjxnpjut2l23m@xz65d6ckyvi3>
References: <20231212122835.10850-2-retpolanne@posteo.net>
 <3456637.QJadu78ljV@jernej-laptop>
 <6p6d6l7mxof227mmdud2wsbgjr45dlqjxithpfjxnpjut2l23m@xz65d6ckyvi3>
Message-ID: <1962081.yKVeVyVuyW@jernej-laptop>

Dne sreda, 20. december 2023 ob 13:13:38 CET je Anne Macedo napisal(a):
> On Tue, Dec 19, 2023 at 07:54:23PM +0100, Jernej Skrabec wrote:
> > Dne torek, 19. december 2023 ob 01:31:05 CET je Anne Macedo napisal(a):
> > > On Wed, Dec 13, 2023 at 12:25:23PM +0000, Andre Przywara wrote:
> > > > On Wed, 13 Dec 2023 11:02:39 +0000
> > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > 
> > > > Hi Anne,
> > > > 
> > > > > On Wed, Dec 13, 2023 at 01:35:44AM +0000, Andre Przywara wrote:
> > > > > > On Tue, 12 Dec 2023 19:27:14 +0000
> > > > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > > > 
> > > > > > Hi Anne,
> > > > > >   
> > > > > > > On Tue, Dec 12, 2023 at 04:22:00PM +0000, Andre Przywara wrote:  
> > > > > > > > On Tue, 12 Dec 2023 12:28:30 +0000
> > > > > > > > Anne Macedo <retpolanne at posteo.net> wrote:
> > > > > > > > 
> > > > > > > > Hi Anne,
> > > > > > > >     
> > > > > > > > > Adds compatible values to mdio subnodes for Ethernet PHY representing
> > > > > > > > > Realtek 8211 PHY to Orange Pi One Plus.    
> > > > > > > > 
> > > > > > > > So can you state why this would be needed? This is the RTL8211 ID,    
> > > > > > > 
> > > > > > > Apologies, I completely forgot to include some context. 
> > > > > > >   
> > > > > > > > right? Which should be autodetected via MDIO. Looking back in my inbox
> > > > > > > > you proposed this change before, for U-Boot, specifically, but I fail to
> > > > > > > > find a solution or explanation what really happens here. Two Renesas .dts
> > > > > > > > files have the same compatible, and the commit message talks about the
> > > > > > > > reset line there, is this related?
> > > > > > > > 
> > > > > > > > So can you please give some more background and explanation? That would be
> > > > > > > > part of a good commit message anyway ("why", not "what").    
> > > > > > > 
> > > > > > > Should I resend the commit with a more meaningful explanation? The
> > > > > > > context is the following:
> > > > > > > 
> > > > > > > currently, ethernet doesn't seem to work on both u-boot and Linux on the
> > > > > > > Orange Pi One Plus board. 
> > > > > > > 
> > > > > > > On the kernel, this error shows up:
> > > > > > > 
> > > > > > > Configuring network interfaces... [    5.992589] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > > > [    6.000823] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
> > > > > > > 
> > > > > > > After applying this fix, the PHY gets attached: 
> > > > > > > 
> > > > > > > Configuring network interfaces... [    6.060020] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > > > [    6.069460] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
> > > > > > > 
> > > > > > > The previous compatible list that had ethernet-phy-ieee802.3-c22 fails
> > > > > > > to find a PHY, so this patch includes the correct PHY ID with the
> > > > > > > RTL8211 ID. 
> > > > > > > 
> > > > > > > The behaviour is described on [1].  
> > > > > > 
> > > > > > So this is all an observation, but no real explanation, isn't it?  
> > > > > 
> > > > > I've made some analysis on [3] on this bug, but it was based solely on
> > > > > u-boot. I was having trouble with the regulator and on u-boot nothing
> > > > > would trigger the GPIO PD6 and the vcc-gmac-3v3 regulator, so the NIC
> > > > > was completely dead. Next I did an analysis based on [2] because the
> > > > > u-boot PHY initialization was flaky.
> > > > > 
> > > > > > To cite [1]: "If the PHY reports an incorrect ID (or none at all) ...".
> > > > > > I am pretty sure this is not the case here, instead we are looking at
> > > > > > some missing platform bits, like a missing clock, reset, or most likely
> > > > > > regulator. Or one of the existing resources is wrongly assigned or  
> > > > > 
> > > > > As I mentioned, PHY initialization is flaky on u-boot, so maybe that
> > > > > assumption is correct. 
> > > > > 
> > > > > > configured? If the PHY is not (yet?) powered correctly when the code
> > > > > > does the auto-detection via the MDIO bus, then the initialisation would  
> > > > > 
> > > > > If I recall correctly (I don't know if I kept it in my notes :c), that
> > > > > could be the case. regulator-boot-on makes the NIC work (LEDs blink, at
> > > > > least) but it doesn't get initialized. 
> > > > > 
> > > > > > fail. But since it works when overriding the auto-detection, I feel
> > > > > > like we are papering over something here.
> > > > > > Do you have the schematics for this board? I can only find the one for
> > > > > > the Orange Pi Plus 2E, and I don't know how similar those two are. This
> > > > > > shows *two* regulators, but both are activated by the same GPIO.  
> > > > > 
> > > > > I do. It's available on [4]
> > > > 
> > > > Oh damn it, I got lost in Orange Pi's naming maze again - and was looking
> > > > for the wrong board! So thanks for the link, and this clears things up!
> > > > 
> > > > So yes, the Orange Pi *One* Plus, much like the Orange Pi 3, uses *two*
> > > > regulators for Ethernet: one 3.3V from the PMIC's ALDO2 rail to power the
> > > > PHY, and a discrete 2.5V regulator, enabled by GPIO PD6, for the voltage
> > > > level on the MDIO lines. On top of this there is a reset line for the PHY,
> > > > though this is held up by a pull-up resistor, so it *should* work,
> > > > although we should describe this in the DT.
> > > > 
> > > > So the DT looks wrong then: The reg_gmac_3v3 is actually a 2.5V regulator,
> > > > and phy-supply is aldo2. I think it was done the way it is to somehow make
> > > > it work with the current DT binding and code, which just supports one
> > > > regulator. And aldo2 is referenced as the source of reg_gmac_3v3, which
> > > > smells like another hack to me.
> > > > 
> > > > > > It would also be interesting to see if any of Corentin's work for the
> > > > > > Orange Pi 3 helps here?  
> > > > > 
> > > > > Adding [5] for reference here, thanks! Will check it out. 
> > > > 
> > > > This is an older version, there are actually updates. And he also mentions
> > > > your board as well, so I think it just can sail in the wake of the OPi 3
> > > > Ethernet enablement.
> > > > 
> > > > Can you try if this change, just applied to your .dts instead, works?
> > > > https://github.com/montjoie/linux/commit/cf6e192eca1d59be630e6729d2cef9e897b3da8c
> > > 
> > > Hello, 
> > > 
> > > I've tried applying this change but it didn't seem to work :( 
> > 
> > Those patches are obsolete, I took over the work and latest patches are here:
> > https://github.com/jernejsk/linux-1/commits/opi3-net/ (last 3)
> > 
> > While I have OrangePi 3 and I have tested patches on it, I don't have Orange
> > Pi One Plus.
> > 
> > > 
> > > I got these errors:
> > > 
> > > [    5.117220] dwmac-sun8i 5020000.ethernet: IRQ eth_wake_irq not found
> > > [    5.124366] dwmac-sun8i 5020000.ethernet: IRQ eth_lpi not found
> > > [    5.130645] dwmac-sun8i 5020000.ethernet: No regulator found
> > > [    5.137133] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> > > [    5.143925] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
> > > [    5.157588] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
> > > [    5.164905] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
> > > [    5.172189] dwmac-sun8i 5020000.ethernet: COE Type 2
> > > [    5.177213] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
> > > [    5.184033] dwmac-sun8i 5020000.ethernet: Normal descriptors
> > > [    5.189724] dwmac-sun8i 5020000.ethernet: Chain mode enabled
> > > [    5.381149] dwmac-sun8i 5020000.ethernet: EMAC reset timeout
> > > [    5.386863] dwmac-sun8i 5020000.ethernet eth0: stmmac_dvr_remove: removing driver
> > > [    5.438851] dwmac-sun8i: probe of 5020000.ethernet failed with error -110
> > > 
> > > I think I understand what is going on in Corentin's patch though. Please
> > > correct me if I'm wrong:
> > > 
> > > 1. Instead of using the gmac-3v3, they use gmac-2v5 enabled by PD6.
> > 
> > Yes, 3v3 is completely wrong. Schematic only shows 2v5 regulator controlled
> > with PD6.
> > 
> > > 2. For "phy-io", the 2v5 regulator is used
> > > 3. For "ephy", the 3v3 regulator is used (aldo2 already sends this 3v3
> > > signal)
> > 
> > Correct.
> > 
> > > 
> > > My changes are here:
> > > https://github.com/retpolanne/linux/commit/45aa2abde2606f9164f9a97d092fab6a36d45165
> > > 
> > > Maybe I should try to use the existing 3v3 regulator alongside a new 2v5
> > > regulator on the DT. 
> > 
> > No.
> > 
> > Please make sure that you have
> > https://github.com/jernejsk/linux-1/commit/25b44143ea8162209beb02759ca3ea3bd3be7a74
> 
> I was able to apply this one
> https://github.com/jernejsk/linux-1/commit/18725ec6239ac4eedea4aefbe224594d2735399c
> 
> But not this one: 
> https://github.com/jernejsk/linux-1/commit/25b44143ea8162209beb02759ca3ea3bd3be7a74
> 
> I believe this latter patch is required to make it work. Has it been
> sent upstream? 

No, but I plan to do that soon.

In any case, patches are based on v6.7-rc1, but you should be able to apply
them to v6.6 too. With older kernels there is issue in first chunk (include),
but that is trivial to resolve.

Best regards,
Jernej

> 
> > 
> > Without it, ethernet PHY won't be powered on and you will get errors in dmesg.
> > 
> > Best regards,
> > Jernej
> > 
> > > > 
> > > > Cheers,
> > > > Andre
> > > > 
> > > > P.S. Is there any chance where I can reply/comment on your blog? It seems
> > > > like I can clear some things up...
> > > > 
> > > > > [3] https://blog.retpolanne.com/hardware/embedded/2023/07/07/embedded-phy.html
> > > > > [4] https://linux-sunxi.org/images/7/7c/OrangePi_OnePlus_Schematics_v2.0.pdf
> > > > > [5] https://lore.kernel.org/netdev/20220509074857.195302-1-clabbe at baylibre.com/
> > > > > 
> > > > > Regards, Anne
> > > > 
> > > 
> > > Regards, Anne
> > > 
> > 
> > 
> > 
> > 
> 






From cristian.marussi at arm.com  Wed Dec 20 09:21:12 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Wed, 20 Dec 2023 17:21:12 +0000
Subject: [PATCH] firmware: arm_scmi: Check Mailbox/SMT channel for consistency
Message-ID: <20231220172112.763539-1-cristian.marussi@arm.com>

On reception of a completion interrupt the SMT memory area is accessed to
retrieve the message header at first and then, if the message sequence
number identifies a transaction which is still pending, the related
payload is fetched too.

When an SCMI command times out the channel ownership remains with the
platform until eventually a late reply is received and, as a consequence,
any further transmission attempt remains pending, waiting for the channel
to be relinquished by the platform.

Once that late reply is received the channel ownership is given back
to the agent and any pending request is then allowed to proceed and
overwrite the SMT area of the just delivered late reply; then the wait for
the reply to the new request starts.

It has been observed that the spurious IRQ related to the late reply can
be wrongly associated with the freshly enqueued request: when that happens
the SCMI stack in-flight lookup procedure is fooled by the fact that the
message header now present in the SMT area is related to the new pending
transaction, even though the real reply has still to arrive.

This race-condition on the A2P channel can be detected by looking at the
channel status bits: a genuine reply from the platform will have set the
channel free bit before triggering the completion IRQ.

Add a consistency check to validate such condition in the A2P ISR.

Reported-by: Xinglong Yang <xinglong.yang at cixtech.com>
Closes: https://lore.kernel.org/all/PUZPR06MB54981E6FA00D82BFDBB864FBF08DA at PUZPR06MB5498.apcprd06.prod.outlook.com/
Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type")
CC: stable at vger.kernel.org # 5.15+
Signed-off-by: Cristian Marussi <cristian.marussi at arm.com>
---
 drivers/firmware/arm_scmi/common.h  |  1 +
 drivers/firmware/arm_scmi/mailbox.c | 14 ++++++++++++++
 drivers/firmware/arm_scmi/shmem.c   |  6 ++++++
 3 files changed, 21 insertions(+)

diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 3b7c68a11fd0..0956c2443840 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -329,6 +329,7 @@ void shmem_fetch_notification(struct scmi_shared_mem __iomem *shmem,
 void shmem_clear_channel(struct scmi_shared_mem __iomem *shmem);
 bool shmem_poll_done(struct scmi_shared_mem __iomem *shmem,
 		     struct scmi_xfer *xfer);
+bool shmem_channel_free(struct scmi_shared_mem __iomem *shmem);
 
 /* declarations for message passing transports */
 struct scmi_msg_payld;
diff --git a/drivers/firmware/arm_scmi/mailbox.c b/drivers/firmware/arm_scmi/mailbox.c
index 19246ed1f01f..b8d470417e8f 100644
--- a/drivers/firmware/arm_scmi/mailbox.c
+++ b/drivers/firmware/arm_scmi/mailbox.c
@@ -45,6 +45,20 @@ static void rx_callback(struct mbox_client *cl, void *m)
 {
 	struct scmi_mailbox *smbox = client_to_scmi_mailbox(cl);
 
+	/*
+	 * An A2P IRQ is NOT valid when received while the platform still has
+	 * the ownership of the channel, because the platform at first releases
+	 * the SMT channel and then sends the completion interrupt.
+	 *
+	 * This addresses a possible race condition in which a spurious IRQ from
+	 * a previous timed-out reply which arrived late could be wrongly
+	 * associated with the next pending transaction.
+	 */
+	if (cl->knows_txdone && !shmem_channel_free(smbox->shmem)) {
+		dev_warn(smbox->cinfo->dev, "Ignoring spurious A2P IRQ !\n");
+		return;
+	}
+
 	scmi_rx_callback(smbox->cinfo, shmem_read_header(smbox->shmem), NULL);
 }
 
diff --git a/drivers/firmware/arm_scmi/shmem.c b/drivers/firmware/arm_scmi/shmem.c
index 87b4f4d35f06..517d52fb3bcb 100644
--- a/drivers/firmware/arm_scmi/shmem.c
+++ b/drivers/firmware/arm_scmi/shmem.c
@@ -122,3 +122,9 @@ bool shmem_poll_done(struct scmi_shared_mem __iomem *shmem,
 		(SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR |
 		 SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE);
 }
+
+bool shmem_channel_free(struct scmi_shared_mem __iomem *shmem)
+{
+	return (ioread32(&shmem->channel_status) &
+			SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE);
+}
-- 
2.34.1



From acme at kernel.org  Wed Dec 20 09:31:07 2023
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Wed, 20 Dec 2023 14:31:07 -0300
Subject: [PATCH 0/3] perf scripts python: arm-cs-trace-disasm.py:
In-Reply-To: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
Message-ID: <ZYMk2zh7jTzMiz8K@kernel.org>

Em Thu, Dec 14, 2023 at 08:33:01PM +0800, Ruidong Tian escreveu:
> Now the instruction flow disasmed by arm-cs-trace-disasm.py is
> ambiguous and uncorrect, fix them in one patch set. Please refer to
> each patch for details.
> 
> Ruidong Tian (3):
>   perf scripts python: arm-cs-trace-disasm.py: print dso base address
>   perf scripts python: arm-cs-trace-disasm.py: set start vm addr of
>     exectable file to 0
>   perf scripts python: arm-cs-trace-disasm.py: do not ignore disam first
>     sample

Picked patches 2 and 3, waiting for further discussion about the other
one.

- Arnaldo


From arinc.unal at arinc9.com  Wed Dec 20 09:35:39 2023
From: arinc.unal at arinc9.com (=?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=)
Date: Wed, 20 Dec 2023 19:35:39 +0200
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal MDIO bus
Message-ID: <20231220173539.59071-1-arinc.unal@arinc9.com>

From: David Bauer <mail at david-bauer.net>

The MT753x switches provide a switch-internal MDIO bus for the embedded
PHYs.

Register a OF sub-node on the switch OF-node for this internal MDIO bus.
This allows to configure the embedded PHYs using device-tree.

Signed-off-by: David Bauer <mail at david-bauer.net>
Signed-off-by: Daniel Golle <daniel at makrotopia.org>
Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
---
 drivers/net/dsa/mt7530.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 391c4dbdff42..f8ecc354630b 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2155,10 +2155,13 @@ mt7530_setup_mdio(struct mt7530_priv *priv)
 {
 	struct dsa_switch *ds = priv->ds;
 	struct device *dev = priv->dev;
+	struct device_node *np, *mnp;
 	struct mii_bus *bus;
 	static int idx;
 	int ret;
 
+	np = priv->dev->of_node;
+
 	bus = devm_mdiobus_alloc(dev);
 	if (!bus)
 		return -ENOMEM;
@@ -2177,7 +2180,9 @@ mt7530_setup_mdio(struct mt7530_priv *priv)
 	if (priv->irq)
 		mt7530_setup_mdio_irq(priv);
 
-	ret = devm_mdiobus_register(dev, bus);
+	mnp = of_get_child_by_name(np, "mdio");
+	ret = devm_of_mdiobus_register(dev, bus, mnp);
+	of_node_put(mnp);
 	if (ret) {
 		dev_err(dev, "failed to register MDIO bus: %d\n", ret);
 		if (priv->irq)
-- 
2.40.1



From suzuki.poulose at arm.com  Wed Dec 20 09:41:07 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Wed, 20 Dec 2023 17:41:07 +0000
Subject: [PATCH RFC V2 1/4] perf/core: Add aux_pause, aux_resume,
 aux_start_paused
In-Reply-To: <20231208172449.35444-2-adrian.hunter@intel.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
 <20231208172449.35444-2-adrian.hunter@intel.com>
Message-ID: <7023e9fb-0bde-4a17-aa9e-e29e6b8b4bf1@arm.com>

On 08/12/2023 17:24, Adrian Hunter wrote:
> Hardware traces, such as instruction traces, can produce a vast amount of
> trace data, so being able to reduce tracing to more specific circumstances
> can be useful.
> 
> The ability to pause or resume tracing when another event happens, can do
> that.
> 
> Add ability for an event to "pause" or "resume" AUX area tracing.
> 
> Add aux_pause bit to perf_event_attr to indicate that, if the event
> happens, the associated AUX area tracing should be paused. Ditto
> aux_resume. Do not allow aux_pause and aux_resume to be set together.
> 
> Add aux_start_paused bit to perf_event_attr to indicate to an AUX area
> event that it should start in a "paused" state.
> 
> Add aux_paused to struct perf_event for AUX area events to keep track of
> the "paused" state. aux_paused is initialized to aux_start_paused.
> 
> Add PERF_EF_PAUSE and PERF_EF_RESUME modes for ->stop() and ->start()
> callbacks. Call as needed, during __perf_event_output(). Add
> aux_in_pause_resume to struct perf_buffer to prevent races with the NMI
> handler. Pause/resume in NMI context will miss out if it coincides with
> another pause/resume.
> 
> To use aux_pause or aux_resume, an event must be in a group with the AUX
> area event as the group leader.
> 
> Example (requires Intel PT and tools patches also):
> 
>   $ perf record --kcore -e '{intel_pt/aux-start-paused/k,syscalls:sys_enter_newuname/aux-resume/,syscalls:sys_exit_newuname/aux-pause/}' uname
>   Linux
>   [ perf record: Woken up 1 times to write data ]
>   [ perf record: Captured and wrote 0.041 MB perf.data ]
>   $ perf script --call-trace
>   uname    5712 [007]    83.855580930: name: 0x7ffd9dcebec0
>   uname    5712 [007]    83.855582518:  psb offs: 0
>   uname    5712 [007]    83.855582518:  cbr: 42 freq: 4205 MHz (150%)
>   uname    5712 [007]    83.855582723: ([kernel.kallsyms])    debug_smp_processor_id
>   uname    5712 [007]    83.855582723: ([kernel.kallsyms])    __x64_sys_newuname
>   uname    5712 [007]    83.855582723: ([kernel.kallsyms])        down_read
>   uname    5712 [007]    83.855582723: ([kernel.kallsyms])            __cond_resched
>   uname    5712 [007]    83.855582932: ([kernel.kallsyms])            preempt_count_add
>   uname    5712 [007]    83.855582932: ([kernel.kallsyms])                in_lock_functions
>   uname    5712 [007]    83.855582932: ([kernel.kallsyms])            preempt_count_sub
>   uname    5712 [007]    83.855582932: ([kernel.kallsyms])        up_read
>   uname    5712 [007]    83.855582932: ([kernel.kallsyms])            preempt_count_add
>   uname    5712 [007]    83.855583348: ([kernel.kallsyms])                in_lock_functions
>   uname    5712 [007]    83.855583348: ([kernel.kallsyms])            preempt_count_sub
>   uname    5712 [007]    83.855583348: ([kernel.kallsyms])        _copy_to_user
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])    syscall_exit_to_user_mode
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])        syscall_exit_work
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])            perf_syscall_exit
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])                debug_smp_processor_id
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])                perf_trace_buf_alloc
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    perf_swevent_get_recursion_context
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])                        debug_smp_processor_id
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    debug_smp_processor_id
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])                perf_tp_event
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    perf_trace_buf_update
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])                        tracing_gen_ctx_irq_test
>   uname    5712 [007]    83.855583557: ([kernel.kallsyms])                    perf_swevent_event
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                        __perf_event_account_interrupt
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                            __this_cpu_preempt_check
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                        perf_event_output_forward
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                            perf_event_aux_pause
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                ring_buffer_get
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    __rcu_read_lock
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    __rcu_read_unlock
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                pt_event_stop
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    debug_smp_processor_id
>   uname    5712 [007]    83.855583765: ([kernel.kallsyms])                                    debug_smp_processor_id
>   uname    5712 [007]    83.855583973: ([kernel.kallsyms])                                    native_write_msr
>   uname    5712 [007]    83.855583973: ([kernel.kallsyms])                                    native_write_msr
>   uname    5712 [007]    83.855584175: 0x0
> 
> Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
> ---
>   include/linux/perf_event.h      | 15 +++++++
>   include/uapi/linux/perf_event.h | 11 ++++-
>   kernel/events/core.c            | 72 +++++++++++++++++++++++++++++++--
>   kernel/events/internal.h        |  1 +
>   4 files changed, 95 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index e85cd1c0eaf3..252c4aac3b79 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -291,6 +291,7 @@ struct perf_event_pmu_context;
>   #define PERF_PMU_CAP_NO_EXCLUDE			0x0040
>   #define PERF_PMU_CAP_AUX_OUTPUT			0x0080
>   #define PERF_PMU_CAP_EXTENDED_HW_TYPE		0x0100
> +#define PERF_PMU_CAP_AUX_PAUSE			0x0200
>   
>   struct perf_output_handle;
>   
> @@ -363,6 +364,8 @@ struct pmu {
>   #define PERF_EF_START	0x01		/* start the counter when adding    */
>   #define PERF_EF_RELOAD	0x02		/* reload the counter when starting */
>   #define PERF_EF_UPDATE	0x04		/* update the counter when stopping */
> +#define PERF_EF_PAUSE	0x08		/* AUX area event, pause tracing */
> +#define PERF_EF_RESUME	0x10		/* AUX area event, resume tracing */
>   
>   	/*
>   	 * Adds/Removes a counter to/from the PMU, can be done inside a
> @@ -402,6 +405,15 @@ struct pmu {
>   	 *
>   	 * ->start() with PERF_EF_RELOAD will reprogram the counter
>   	 *  value, must be preceded by a ->stop() with PERF_EF_UPDATE.
> +	 *
> +	 * ->stop() with PERF_EF_PAUSE will stop as simply as possible. Will not
> +	 * overlap another ->stop() with PERF_EF_PAUSE nor ->start() with
> +	 * PERF_EF_RESUME.
> +	 *
> +	 * ->start() with PERF_EF_RESUME will start as simply as possible but
> +	 * only if the counter is not otherwise stopped. Will not overlap
> +	 * another ->start() with PERF_EF_RESUME nor ->stop() with
> +	 * PERF_EF_PAUSE.
>   	 */
>   	void (*start)			(struct perf_event *event, int flags);
>   	void (*stop)			(struct perf_event *event, int flags);
> @@ -797,6 +809,9 @@ struct perf_event {
>   	/* for aux_output events */
>   	struct perf_event		*aux_event;
>   
> +	/* for AUX area events */
> +	unsigned int			aux_paused;
> +
>   	void (*destroy)(struct perf_event *);
>   	struct rcu_head			rcu_head;
>   
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 39c6a250dd1b..437bc2a8d50c 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -507,7 +507,16 @@ struct perf_event_attr {
>   	__u16	sample_max_stack;
>   	__u16	__reserved_2;
>   	__u32	aux_sample_size;
> -	__u32	__reserved_3;
> +
> +	union {
> +		__u32	aux_output_cfg;
> +		struct {
> +			__u64	aux_pause        :  1, /* on overflow, pause AUX area tracing */

Did you mean __u32 ? Otherwise look good to me.

Suzuki

> +				aux_resume       :  1, /* on overflow, resume AUX area tracing */
> +				aux_start_paused :  1, /* start AUX area tracing paused */
> +				__reserved_3     : 29;
> +		};
> +	};
>   
>   	/*
>   	 * User provided data if sigtrap=1, passed back to user via
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 4c72a41f11af..c1e11884d06e 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2060,7 +2060,8 @@ static void perf_put_aux_event(struct perf_event *event)
>   
>   static bool perf_need_aux_event(struct perf_event *event)
>   {
> -	return !!event->attr.aux_output || !!event->attr.aux_sample_size;
> +	return event->attr.aux_output || event->attr.aux_sample_size ||
> +	       event->attr.aux_pause || event->attr.aux_resume;
>   }
>   
>   static int perf_get_aux_event(struct perf_event *event,
> @@ -2085,6 +2086,10 @@ static int perf_get_aux_event(struct perf_event *event,
>   	    !perf_aux_output_match(event, group_leader))
>   		return 0;
>   
> +	if ((event->attr.aux_pause || event->attr.aux_resume) &&
> +	    !(group_leader->pmu->capabilities & PERF_PMU_CAP_AUX_PAUSE))
> +		return 0;
> +
>   	if (event->attr.aux_sample_size && !group_leader->pmu->snapshot_aux)
>   		return 0;
>   
> @@ -7773,6 +7778,47 @@ void perf_prepare_header(struct perf_event_header *header,
>   	WARN_ON_ONCE(header->size & 7);
>   }
>   
> +static void __perf_event_aux_pause(struct perf_event *event, bool pause)
> +{
> +	if (pause) {
> +		if (!READ_ONCE(event->aux_paused)) {
> +			WRITE_ONCE(event->aux_paused, 1);
> +			event->pmu->stop(event, PERF_EF_PAUSE);
> +		}
> +	} else {
> +		if (READ_ONCE(event->aux_paused)) {
> +			WRITE_ONCE(event->aux_paused, 0);
> +			event->pmu->start(event, PERF_EF_RESUME);
> +		}
> +	}
> +}
> +
> +static void perf_event_aux_pause(struct perf_event *event, bool pause)
> +{
> +	struct perf_buffer *rb;
> +	unsigned long flags;
> +
> +	if (WARN_ON_ONCE(!event))
> +		return;
> +
> +	rb = ring_buffer_get(event);
> +	if (!rb)
> +		return;
> +
> +	local_irq_save(flags);
> +	/* Guard against NMI, NMI loses here */
> +	if (READ_ONCE(rb->aux_in_pause_resume))
> +		goto out_restore;
> +	WRITE_ONCE(rb->aux_in_pause_resume, 1);
> +	barrier();
> +	__perf_event_aux_pause(event, pause);
> +	barrier();
> +	WRITE_ONCE(rb->aux_in_pause_resume, 0);
> +out_restore:
> +	local_irq_restore(flags);
> +	ring_buffer_put(rb);
> +}
> +
>   static __always_inline int
>   __perf_event_output(struct perf_event *event,
>   		    struct perf_sample_data *data,
> @@ -7786,6 +7832,9 @@ __perf_event_output(struct perf_event *event,
>   	struct perf_event_header header;
>   	int err;
>   
> +	if (event->attr.aux_pause)
> +		perf_event_aux_pause(event->aux_event, true);
> +
>   	/* protect the callchain buffers */
>   	rcu_read_lock();
>   
> @@ -7802,6 +7851,10 @@ __perf_event_output(struct perf_event *event,
>   
>   exit:
>   	rcu_read_unlock();
> +
> +	if (event->attr.aux_resume)
> +		perf_event_aux_pause(event->aux_event, false);
> +
>   	return err;
>   }
>   
> @@ -11941,10 +11994,23 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
>   	}
>   
>   	if (event->attr.aux_output &&
> -	    !(pmu->capabilities & PERF_PMU_CAP_AUX_OUTPUT)) {
> +	    (!(pmu->capabilities & PERF_PMU_CAP_AUX_OUTPUT) ||
> +	     event->attr.aux_pause || event->attr.aux_resume)) {
> +		err = -EOPNOTSUPP;
> +		goto err_pmu;
> +	}
> +
> +	if (event->attr.aux_pause && event->attr.aux_resume) {
> +		err = -EINVAL;
> +		goto err_pmu;
> +	}
> +
> +	if (event->attr.aux_start_paused &&
> +	    !(pmu->capabilities & PERF_PMU_CAP_AUX_PAUSE)) {
>   		err = -EOPNOTSUPP;
>   		goto err_pmu;
>   	}
> +	event->aux_paused = event->attr.aux_start_paused;
>   
>   	if (cgroup_fd != -1) {
>   		err = perf_cgroup_connect(cgroup_fd, event, attr, group_leader);
> @@ -12741,7 +12807,7 @@ perf_event_create_kernel_counter(struct perf_event_attr *attr, int cpu,
>   	 * Grouping is not supported for kernel events, neither is 'AUX',
>   	 * make sure the caller's intentions are adjusted.
>   	 */
> -	if (attr->aux_output)
> +	if (attr->aux_output || attr->aux_output_cfg)
>   		return ERR_PTR(-EINVAL);
>   
>   	event = perf_event_alloc(attr, cpu, task, NULL, NULL,
> diff --git a/kernel/events/internal.h b/kernel/events/internal.h
> index 5150d5f84c03..3320f78117dc 100644
> --- a/kernel/events/internal.h
> +++ b/kernel/events/internal.h
> @@ -51,6 +51,7 @@ struct perf_buffer {
>   	void				(*free_aux)(void *);
>   	refcount_t			aux_refcount;
>   	int				aux_in_sampling;
> +	int				aux_in_pause_resume;
>   	void				**aux_pages;
>   	void				*aux_priv;
>   



From ben.levinsky at amd.com  Wed Dec 20 09:42:44 2023
From: ben.levinsky at amd.com (Ben Levinsky)
Date: Wed, 20 Dec 2023 09:42:44 -0800
Subject: [PATCH 3/3] mailbox: zynqmp: Enable Bufferless IPI usage on
 Versal-based SOC's
In-Reply-To: <ea76da63-4758-400f-a5ed-9cb223b65c80@amd.com>
References: <20231214211354.348294-1-ben.levinsky@amd.com>
 <20231214211354.348294-4-ben.levinsky@amd.com>
 <ea76da63-4758-400f-a5ed-9cb223b65c80@amd.com>
Message-ID: <038659b4-a148-4663-870e-898f33406a08@amd.com>


On 12/20/23 5:29 AM, Michal Simek wrote:
>
>
> On 12/14/23 22:13, Ben Levinsky wrote:
>> On Xilinx-AMD Versal and Versal-NET, there exist both
>> inter-processor-interrupts with corresponding message buffers and without
>> such buffers.
>>
>> Add a routine that, if the corresponding DT compatible
>> string "xlnx,versal-ipi-mailbox" is used then a Versal-based SOC
>> can use a mailbox Device Tree entry where both host and remote
>> can use either of the buffered or bufferless interrupts.
>>
>> Signed-off-by: Ben Levinsky <ben.levinsky at amd.com>
>> ---
>> Note that the linked patch provides corresponding bindings.
>> Depends on: https://lore.kernel.org/all/20231214054224.957336-3-tanmay.shah at amd.com/T/
>> ---
>> ? drivers/mailbox/zynqmp-ipi-mailbox.c | 146 +++++++++++++++++++++++++--
>> ? 1 file changed, 139 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
>> index edefb80a6e47..316d9406064e 100644
>> --- a/drivers/mailbox/zynqmp-ipi-mailbox.c
>> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
>> @@ -52,6 +52,13 @@
>> ? #define IPI_MB_CHNL_TX??? 0 /* IPI mailbox TX channel */
>> ? #define IPI_MB_CHNL_RX??? 1 /* IPI mailbox RX channel */
>> ? +/* IPI Message Buffer Information */
>> +#define RESP_OFFSET??? 0x20U
>> +#define DEST_OFFSET??? 0x40U
>> +#define IPI_BUF_SIZE??? 0x20U
>> +#define DST_BIT_POS??? 9U
>> +#define SRC_BITMASK??? GENMASK(11, 8)
>> +
>> ? /**
>> ?? * struct zynqmp_ipi_mchan - Description of a Xilinx ZynqMP IPI mailbox channel
>> ?? * @is_opened: indicate if the IPI channel is opened
>> @@ -170,9 +177,11 @@ static irqreturn_t zynqmp_ipi_interrupt(int irq, void *data)
>> ????????? if (ret > 0 && ret & IPI_MB_STATUS_RECV_PENDING) {
>> ????????????? if (mchan->is_opened) {
>> ????????????????? msg = mchan->rx_buf;
>> -??????????????? msg->len = mchan->req_buf_size;
>> -??????????????? memcpy_fromio(msg->data, mchan->req_buf,
>> -????????????????????????? msg->len);
>> +??????????????? if (msg) {
>> +??????????????????? msg->len = mchan->req_buf_size;
>> +??????????????????? memcpy_fromio(msg->data, mchan->req_buf,
>> +????????????????????????????? msg->len);
>> +??????????????? }
>> ????????????????? mbox_chan_received_data(chan, (void *)msg);
>> ????????????????? status = IRQ_HANDLED;
>> ????????????? }
>> @@ -282,26 +291,26 @@ static int zynqmp_ipi_send_data(struct mbox_chan *chan, void *data)
>> ? ????? if (mchan->chan_type == IPI_MB_CHNL_TX) {
>> ????????? /* Send request message */
>> -??????? if (msg && msg->len > mchan->req_buf_size) {
>> +??????? if (msg && msg->len > mchan->req_buf_size && mchan->req_buf) {
>> ????????????? dev_err(dev, "channel %d message length %u > max %lu\n",
>> ????????????????? mchan->chan_type, (unsigned int)msg->len,
>> ????????????????? mchan->req_buf_size);
>> ????????????? return -EINVAL;
>> ????????? }
>> -??????? if (msg && msg->len)
>> +??????? if (msg && msg->len && mchan->req_buf)
>> ????????????? memcpy_toio(mchan->req_buf, msg->data, msg->len);
>> ????????? /* Kick IPI mailbox to send message */
>> ????????? arg0 = SMC_IPI_MAILBOX_NOTIFY;
>> ????????? zynqmp_ipi_fw_call(ipi_mbox, arg0, 0, &res);
>> ????? } else {
>> ????????? /* Send response message */
>> -??????? if (msg && msg->len > mchan->resp_buf_size) {
>> +??????? if (msg && msg->len > mchan->resp_buf_size && mchan->resp_buf) {
>> ????????????? dev_err(dev, "channel %d message length %u > max %lu\n",
>> ????????????????? mchan->chan_type, (unsigned int)msg->len,
>> ????????????????? mchan->resp_buf_size);
>> ????????????? return -EINVAL;
>> ????????? }
>> -??????? if (msg && msg->len)
>> +??????? if (msg && msg->len && mchan->resp_buf)
>> ????????????? memcpy_toio(mchan->resp_buf, msg->data, msg->len);
>> ????????? arg0 = SMC_IPI_MAILBOX_ACK;
>> ????????? zynqmp_ipi_fw_call(ipi_mbox, arg0, IPI_SMC_ACK_EIRQ_MASK,
>> @@ -640,6 +649,126 @@ static int zynqmp_ipi_setup(struct zynqmp_ipi_mbox *ipi_mbox,
>> ????? return 0;
>> ? }
>> ? +/**
>> + * versal_ipi_setup - Set up IPIs to support mixed usage of
>> + *???????????????? Buffered and Bufferless IPIs.
>> + *
>> + * @ipi_mbox: pointer to IPI mailbox private data structure
>> + * @node: IPI mailbox device node
>> + *
>> + * Return: 0 for success, negative value for failure
>> + */
>> +static int versal_ipi_setup(struct zynqmp_ipi_mbox *ipi_mbox,
>> +??????????????? struct device_node *node)
>> +{
>> +??? struct zynqmp_ipi_mchan *tx_mchan, *rx_mchan;
>> +??? struct resource host_res, remote_res;
>> +??? struct device_node *parent_node;
>> +??? int host_idx, remote_idx;
>> +??? struct device *mdev, *dev;
>> +
>> +??? tx_mchan = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
>> +??? rx_mchan = &ipi_mbox->mchans[IPI_MB_CHNL_RX];
>> +??? parent_node = of_get_parent(node);
>> +??? dev = ipi_mbox->pdata->dev;
>> +??? mdev = &ipi_mbox->dev;
>> +
>> +??? host_idx = zynqmp_ipi_mbox_get_buf_res(parent_node, "msg", &host_res);
>> +??? remote_idx = zynqmp_ipi_mbox_get_buf_res(node, "msg", &remote_res);
>> +
>> +??? /*
>> +???? * Only set up buffers if both sides claim to have msg buffers.
>> +???? * This is because each buffered IPI's corresponding msg buffers
>> +???? * are reserved for use by other buffered IPI's.
>> +???? */
>> +??? if (!host_idx && !remote_idx) {
>> +??????? u32 host_src, host_dst, remote_src, remote_dst;
>> +??????? u32 buff_sz;
>> +
>> +??????? buff_sz = resource_size(&host_res);
>> +
>> +??????? host_src = host_res.start & SRC_BITMASK;
>> +??????? remote_src = remote_res.start & SRC_BITMASK;
>> +
>> +??????? host_dst = (host_src >> DST_BIT_POS) * DEST_OFFSET;
>> +??????? remote_dst = (remote_src >> DST_BIT_POS) * DEST_OFFSET;
>> +
>> +??????? /* Validate that IPI IDs is within IPI Message buffer space. */
>> +??????? if (host_dst >= buff_sz || remote_dst >= buff_sz) {
>> +??????????? dev_err(mdev,
>> +??????????????? "Invalid IPI Message buffer values: %x %x\n",
>> +??????????????? host_dst, remote_dst);
>> +??????????? return -EINVAL;
>> +??????? }
>> +
>> +??????? tx_mchan->req_buf = devm_ioremap(mdev,
>> +???????????????????????? host_res.start | remote_dst,
>> +???????????????????????? IPI_BUF_SIZE);
>> +??????? if (!tx_mchan->req_buf) {
>> +??????????? dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
>> +??????????? return -ENOMEM;
>> +??????? }
>> +
>> +??????? tx_mchan->resp_buf = devm_ioremap(mdev,
>> +????????????????????????? (remote_res.start | host_dst) +
>> +????????????????????????? RESP_OFFSET, IPI_BUF_SIZE);
>> +??????? if (!tx_mchan->resp_buf) {
>> +??????????? dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
>> +??????????? return -ENOMEM;
>> +??????? }
>> +
>> +??????? rx_mchan->req_buf = devm_ioremap(mdev,
>> +???????????????????????? remote_res.start | host_dst,
>> +???????????????????????? IPI_BUF_SIZE);
>> +??????? if (!rx_mchan->req_buf) {
>> +??????????? dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
>> +??????????? return -ENOMEM;
>> +??????? }
>> +
>> +??????? rx_mchan->resp_buf = devm_ioremap(mdev,
>> +????????????????????????? (host_res.start | remote_dst) +
>> +????????????????????????? RESP_OFFSET, IPI_BUF_SIZE);
>> +??????? if (!rx_mchan->resp_buf) {
>> +??????????? dev_err(mdev, "Unable to map IPI buffer I/O memory\n");
>> +??????????? return -ENOMEM;
>> +??????? }
>> +
>> +??????? tx_mchan->resp_buf_size = IPI_BUF_SIZE;
>> +??????? tx_mchan->req_buf_size = IPI_BUF_SIZE;
>> +??????? tx_mchan->rx_buf = devm_kzalloc(mdev, IPI_BUF_SIZE +
>> +??????????????????????? sizeof(struct zynqmp_ipi_message),
>> +??????????????????????? GFP_KERNEL);
>> +??????? if (!tx_mchan->rx_buf)
>> +??????????? return -ENOMEM;
>> +
>> +??????? rx_mchan->resp_buf_size = IPI_BUF_SIZE;
>> +??????? rx_mchan->req_buf_size = IPI_BUF_SIZE;
>> +??????? rx_mchan->rx_buf = devm_kzalloc(mdev, IPI_BUF_SIZE +
>> +??????????????????????? sizeof(struct zynqmp_ipi_message),
>> +??????????????????????? GFP_KERNEL);
>> +??????? if (!rx_mchan->rx_buf)
>> +??????????? return -ENOMEM;
>> +??? } else {
>> +??????? /*
>> +???????? * If here, then set up Bufferless IPI Channel because
>> +???????? * one or both of the IPI's is bufferless.
>> +???????? */
>> +??????? tx_mchan->req_buf = NULL;
>> +??????? tx_mchan->resp_buf = NULL;
>> +??????? tx_mchan->rx_buf = NULL;
>> +??????? tx_mchan->resp_buf_size = 0;
>> +??????? tx_mchan->req_buf_size = 0;
>> +
>> +??????? rx_mchan->req_buf = NULL;
>> +??????? rx_mchan->resp_buf = NULL;
>> +??????? rx_mchan->rx_buf = NULL;
>> +??????? rx_mchan->resp_buf_size = 0;
>> +??????? rx_mchan->req_buf_size = 0;
>
> Just curious if this is really needed. If none fills that values aren't they actually already 0/NULL because that location is cleared by kzalloc.
>
> Thanks,
> Michal

Confirmed. I removed the whole else condition and it still worked.

Will update in next rev after I receive any pending feedback from Jassi



From ben.levinsky at amd.com  Wed Dec 20 09:44:36 2023
From: ben.levinsky at amd.com (Ben Levinsky)
Date: Wed, 20 Dec 2023 09:44:36 -0800
Subject: [PATCH 2/3] mailbox: zynqmp: Move buffered IPI setup to of_match
 selected routine
In-Reply-To: <c7ea6fd6-b4cd-45e5-b1b0-12c8e2aa8696@amd.com>
References: <20231214211354.348294-1-ben.levinsky@amd.com>
 <20231214211354.348294-3-ben.levinsky@amd.com>
 <c7ea6fd6-b4cd-45e5-b1b0-12c8e2aa8696@amd.com>
Message-ID: <caab8bb6-7e14-423b-ad97-7d193e6598bc@amd.com>


On 12/20/23 5:23 AM, Michal Simek wrote:
>
>
> On 12/14/23 22:13, Ben Levinsky wrote:
>> Move routine that initializes the mailboxes for send and receive to
>> a function pointer that is set based on compatible string.
>>
>> Signed-off-by: Ben Levinsky <ben.levinsky at amd.com>
>> ---
>> ? drivers/mailbox/zynqmp-ipi-mailbox.c | 124 +++++++++++++++++++--------
>> ? 1 file changed, 89 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
>> index 2c10aa01b3bb..edefb80a6e47 100644
>> --- a/drivers/mailbox/zynqmp-ipi-mailbox.c
>> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
>> @@ -72,6 +72,10 @@ struct zynqmp_ipi_mchan {
>> ????? unsigned int chan_type;
>> ? };
>> ? +struct zynqmp_ipi_mbox;
>> +
>> +typedef int (*setup_ipi_fn)(struct zynqmp_ipi_mbox *ipi_mbox, struct device_node *node);
>> +
>> ? /**
>> ?? * struct zynqmp_ipi_mbox - Description of a ZynqMP IPI mailbox
>> ?? *????????????????????????? platform data.
>> @@ -82,6 +86,7 @@ struct zynqmp_ipi_mchan {
>> ?? * @mbox:???????????????? mailbox Controller
>> ?? * @mchans:?????????????? array for channels, tx channel and rx channel.
>> ?? * @irq:????????????????? IPI agent interrupt ID
>> + * setup_ipi_fn:????????? Function Pointer to set up IPI Channels
>
> Here should be @setup_ipi_fn.
will fix.
>
>> ?? */
>> ? struct zynqmp_ipi_mbox {
>> ????? struct zynqmp_ipi_pdata *pdata;
>> @@ -89,6 +94,7 @@ struct zynqmp_ipi_mbox {
>> ????? u32 remote_id;
>> ????? struct mbox_controller mbox;
>> ????? struct zynqmp_ipi_mchan mchans[2];
>> +??? setup_ipi_fn setup_ipi_fn;
>> ? };
>> ? ? /**
>> @@ -466,12 +472,9 @@ static void zynqmp_ipi_mbox_dev_release(struct device *dev)
>> ? static int zynqmp_ipi_mbox_probe(struct zynqmp_ipi_mbox *ipi_mbox,
>> ?????????????????? struct device_node *node)
>> ? {
>> -??? struct zynqmp_ipi_mchan *mchan;
>> ????? struct mbox_chan *chans;
>> ????? struct mbox_controller *mbox;
>> -??? struct resource res;
>> ????? struct device *dev, *mdev;
>> -??? const char *name;
>> ????? int ret;
>> ? ????? dev = ipi_mbox->pdata->dev;
>> @@ -491,6 +494,75 @@ static int zynqmp_ipi_mbox_probe(struct zynqmp_ipi_mbox *ipi_mbox,
>> ????? }
>> ????? mdev = &ipi_mbox->dev;
>> ? +??? /* Get the IPI remote agent ID */
>> +??? ret = of_property_read_u32(node, "xlnx,ipi-id", &ipi_mbox->remote_id);
>> +??? if (ret < 0) {
>> +??????? dev_err(dev, "No IPI remote ID is specified.\n");
>> +??????? return ret;
>> +??? }
>> +
>> +??? ret = ipi_mbox->setup_ipi_fn(ipi_mbox, node);
>> +??? if (ret) {
>> +??????? dev_err(dev, "Failed to set up IPI Buffers.\n");
>> +??????? return ret;
>> +??? }
>> +
>> +??? mbox = &ipi_mbox->mbox;
>> +??? mbox->dev = mdev;
>> +??? mbox->ops = &zynqmp_ipi_chan_ops;
>> +??? mbox->num_chans = 2;
>> +??? mbox->txdone_irq = false;
>> +??? mbox->txdone_poll = true;
>> +??? mbox->txpoll_period = 5;
>> +??? mbox->of_xlate = zynqmp_ipi_of_xlate;
>> +??? chans = devm_kzalloc(mdev, 2 * sizeof(*chans), GFP_KERNEL);
>> +??? if (!chans)
>> +??????? return -ENOMEM;
>> +??? mbox->chans = chans;
>> +??? chans[IPI_MB_CHNL_TX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
>> +??? chans[IPI_MB_CHNL_RX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_RX];
>> +??? ipi_mbox->mchans[IPI_MB_CHNL_TX].chan_type = IPI_MB_CHNL_TX;
>> +??? ipi_mbox->mchans[IPI_MB_CHNL_RX].chan_type = IPI_MB_CHNL_RX;
>> +??? ret = devm_mbox_controller_register(mdev, mbox);
>> +??? if (ret)
>> +??????? dev_err(mdev,
>> +??????????? "Failed to register mbox_controller(%d)\n", ret);
>> +??? else
>> +??????? dev_info(mdev,
>> +???????????? "Registered ZynqMP IPI mbox with TX/RX channels.\n");
>> +??? return ret;
>> +}
>> +
>> +/**
>> + * zynqmp_ipi_setup - set up IPI Buffers for classic flow
>> + *
>> + * @ipi_mbox: pointer to IPI mailbox private data structure
>> + * @node: IPI mailbox device node
>> + *
>> + * This will be used to set up IPI Buffers for ZynqMP SOC if user
>> + * wishes to use classic driver usage model on new SOC's with only
>> + * buffered IPIs.
>> + *
>> + * Note that bufferless IPIs and mixed usage of buffered and bufferless
>> + * IPIs are not supported with this flow.
>> + *
>> + * This will be invoked with compatible string "xlnx,zynqmp-ipi-mailbox".
>> + *
>> + * Return: 0 for success, negative value for failure
>> + */
>> +static int zynqmp_ipi_setup(struct zynqmp_ipi_mbox *ipi_mbox,
>> +??????????????? struct device_node *node)
>> +{
>> +??? struct zynqmp_ipi_mchan *mchan;
>> +??? struct device *mdev;
>> +??? struct resource res;
>> +??? struct device *dev;
>
> nit: you can put it to the same line mdev, dev.
will fix.
>
>> +??? const char *name;
>> +??? int ret;
>> +
>> +??? mdev = &ipi_mbox->dev;
>> +??? dev = ipi_mbox->pdata->dev;
>> +
>> ????? mchan = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
>> ????? name = "local_request_region";
>> ????? ret = zynqmp_ipi_mbox_get_buf_res(node, name, &res);
>> @@ -565,37 +637,7 @@ static int zynqmp_ipi_mbox_probe(struct zynqmp_ipi_mbox *ipi_mbox,
>> ????? if (!mchan->rx_buf)
>> ????????? return -ENOMEM;
>> ? -??? /* Get the IPI remote agent ID */
>> -??? ret = of_property_read_u32(node, "xlnx,ipi-id", &ipi_mbox->remote_id);
>> -??? if (ret < 0) {
>> -??????? dev_err(dev, "No IPI remote ID is specified.\n");
>> -??????? return ret;
>> -??? }
>> -
>> -??? mbox = &ipi_mbox->mbox;
>> -??? mbox->dev = mdev;
>> -??? mbox->ops = &zynqmp_ipi_chan_ops;
>> -??? mbox->num_chans = 2;
>> -??? mbox->txdone_irq = false;
>> -??? mbox->txdone_poll = true;
>> -??? mbox->txpoll_period = 5;
>> -??? mbox->of_xlate = zynqmp_ipi_of_xlate;
>> -??? chans = devm_kzalloc(mdev, 2 * sizeof(*chans), GFP_KERNEL);
>> -??? if (!chans)
>> -??????? return -ENOMEM;
>> -??? mbox->chans = chans;
>> -??? chans[IPI_MB_CHNL_TX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_TX];
>> -??? chans[IPI_MB_CHNL_RX].con_priv = &ipi_mbox->mchans[IPI_MB_CHNL_RX];
>> -??? ipi_mbox->mchans[IPI_MB_CHNL_TX].chan_type = IPI_MB_CHNL_TX;
>> -??? ipi_mbox->mchans[IPI_MB_CHNL_RX].chan_type = IPI_MB_CHNL_RX;
>> -??? ret = devm_mbox_controller_register(mdev, mbox);
>> -??? if (ret)
>> -??????? dev_err(mdev,
>> -??????????? "Failed to register mbox_controller(%d)\n", ret);
>> -??? else
>> -??????? dev_info(mdev,
>> -???????????? "Registered ZynqMP IPI mbox with TX/RX channels.\n");
>> -??? return ret;
>> +??? return 0;
>> ? }
>> ? ? /**
>> @@ -626,6 +668,7 @@ static int zynqmp_ipi_probe(struct platform_device *pdev)
>> ????? struct zynqmp_ipi_pdata *pdata;
>> ????? struct zynqmp_ipi_mbox *mbox;
>> ????? int num_mboxes, ret = -EINVAL;
>> +??? setup_ipi_fn ipi_fn;
>> ? ????? num_mboxes = of_get_available_child_count(np);
>> ????? if (num_mboxes == 0) {
>> @@ -646,9 +689,18 @@ static int zynqmp_ipi_probe(struct platform_device *pdev)
>> ????????? return ret;
>> ????? }
>> ? +??? ipi_fn = (setup_ipi_fn)device_get_match_data(&pdev->dev);
>> +??? if (!ipi_fn) {
>> +??????? dev_err(dev,
>> +??????????? "Mbox Compatible String is missing IPI Setup fn.\n");
>> +??????? return -ENODEV;
>> +??? }
>> +
>> ????? pdata->num_mboxes = num_mboxes;
>> ? ????? mbox = pdata->ipi_mboxes;
>> +??? mbox->setup_ipi_fn = ipi_fn;
>> +
>> ????? for_each_available_child_of_node(np, nc) {
>> ????????? mbox->pdata = pdata;
>> ????????? ret = zynqmp_ipi_mbox_probe(mbox, nc);
>> @@ -694,7 +746,9 @@ static int zynqmp_ipi_remove(struct platform_device *pdev)
>> ? }
>> ? ? static const struct of_device_id zynqmp_ipi_of_match[] = {
>> -??? { .compatible = "xlnx,zynqmp-ipi-mailbox" },
>> +??? { .compatible = "xlnx,zynqmp-ipi-mailbox",
>> +????? .data = &zynqmp_ipi_setup,
>> +??? },
>> ????? {},
>> ? };
>> ? MODULE_DEVICE_TABLE(of, zynqmp_ipi_of_match);
>
>
> M


From robin.murphy at arm.com  Wed Dec 20 11:23:55 2023
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 20 Dec 2023 19:23:55 +0000
Subject: [PATCH v2 4/5] dt-bindings/perf: Add Arm CoreSight PMU
In-Reply-To: <13753b13-9bb0-469b-8fff-38f42ce50d82@linaro.org>
References: <cover.1702571292.git.robin.murphy@arm.com>
 <3c2dd41b585efe44d361f41fcea0181ff2a9c9c5.1702571292.git.robin.murphy@arm.com>
 <8f583a00-8e9c-4875-936c-ed196d1dae56@linaro.org>
 <2b8414e5-61d5-4c3e-9613-6d9487ae84a8@arm.com>
 <4c78e6f2-d6fb-4da7-9c54-ca6a686f2b58@linaro.org>
 <59dd1baa-ef5b-415a-a803-a2dbc3d405b2@arm.com>
 <13753b13-9bb0-469b-8fff-38f42ce50d82@linaro.org>
Message-ID: <8ad65336-a333-4af9-9464-91291a2e43a4@arm.com>

On 2023-12-20 7:30 am, Krzysztof Kozlowski wrote:
> On 19/12/2023 15:24, Robin Murphy wrote:
>> On 2023-12-18 7:03 am, Krzysztof Kozlowski wrote:
>>> On 15/12/2023 19:39, Robin Murphy wrote:
>>>>>> +required:
>>>>>> +  - compatible
>>>>>> +  - reg
>>>>>> +
>>>>>> +additionalProperties: false
>>>>>
>>>>> Why no example to validate the binding?
>>>>
>>>> IMO for such a trivial binding built out of common properties, an
>>>> equally trivial example isn't going to add any value, since it won't do
>>>> anything more than re-state the individual property definitions above.
>>>> In bindings where we have conditional relationships between properties,
>>>> or complex encodings where a practical example can help explain a
>>>> definition (e.g. a map/mask pair for a set of input values), then
>>>> absolutely, an example can add something more to help the author and/or
>>>> users. But otherwise, the thing I've really grown to like about schema
>>>> is how thoroughly self-describing the definitions themselves can now be.
>>>
>>> The example is used to validate the schema.
>>
>> Can you clarify what that *means*, though? As far as I can tell from a
>> bit of experimentation, "make dt_bindings_check" picks up errors in the
>> schema definition itself just the same whether an example is present or
>> not. Thus I still fail to understand what else would be validated by me
>> writing an example here, other than my personal ability to comprehend my
>> own binding.
> 
> You miss here the part that the actual binding is used to verify the
> example used. This is something entirely different than validating
> schema against meta-schema.

If I say "All cats are orange.", it's certainly meta-valid in terms of 
being a well-constructed English sentence, but is it true? If I then 
show you a picture of Garfield as an example to prove my assertion, does 
that make it any more true?

As long as a definition is self-consistent to begin with, contriving a 
"correct" example *from* it does not and can not prove anything about 
the overall correctness of that definition. However, I guess that the 
subtlety of that initial condition might be where your argument comes 
from - I've been taking it for granted here since I'm sufficiently 
confident that I can write correct schema which means what I intend it 
to mean, but as a reviewer I appreciate that you're not necessarily 
going to make the same assumption, so there's value for you if patches 
include a sanity check to give the bot a chance to weed out stuff that's 
completely broken. I would still hesitate to call that "validation", though.

Thanks,
Robin.

>>
>> Yes, I'm well aware that back when we were bootstrapping dtschema it was
>> useful to confirm that schemas were written to correctly describe
>> *existing* known-good DT fragments. However with new bindings like this
>> we've already reached the end goal, where we write an authoritative
>> schema first, then the users follow from there. As I alluded to above,
>> there are reasons why I would actually prefer *not* to provide a usage
>> example here - frankly if a user doesn't understand which parts of the
>> architecture their hardware implements, and/or can't figure out how to
>> copy a single compatible string and write a standard reg property, I
>> would much rather they come to me asking how to write a DT entry, than
>> blindly copy-paste a verbatim example into their DTS, then come to me
>> reporting a "bug" with the driver crashing or failing to probe. I'd love
>> to say I have no experience to base that judgement on, but...
> 
> Sure, considering the size of the binding the benefits of the example
> here are rather low.
> 
> Best regards,
> Krzysztof
> 


From opendmb at gmail.com  Wed Dec 20 11:32:07 2023
From: opendmb at gmail.com (Doug Berger)
Date: Wed, 20 Dec 2023 11:32:07 -0800
Subject: [PATCH] irqchip/irq-brcmstb-l2: add write memory barrier before exit
Message-ID: <20231220193207.1089469-1-opendmb@gmail.com>

It was observed on Broadcom devices that use GIC v3 architecture
L1 interrupt controllers as the parent of brcmstb-l2 interrupt
controllers that the deactivation of the parent irq could happen
before the brcmstb-l2 deasserted its output. This would lead the
GIC to reactivate the irq only to find that no L2 interrupt was
pending. The result was a spurious interrupt invoking the
handle_bad_irq() with its associated messaging. While this did
not create a functional problem it is a waste of cycles.

The hazard exists because the memory mapped bus writes to the
brcmstb-l2 registers are buffered and the GIC v3 architecture
uses a very efficient system register write to deactivate the
interrupt. This commit adds a write memory barrier prior to
invoking chained_irq_exit() to introduce a dsb(st) on those
systems to ensure the system register write cannot be executed
until the memory mapped writes are visible to the system.

Signed-off-by: Doug Berger <opendmb at gmail.com>
---
 drivers/irqchip/irq-brcmstb-l2.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index 5559c943f03f..63aed60dd3f1 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -2,7 +2,7 @@
 /*
  * Generic Broadcom Set Top Box Level 2 Interrupt controller driver
  *
- * Copyright (C) 2014-2017 Broadcom
+ * Copyright (C) 2014-2023 Broadcom
  */
 
 #define pr_fmt(fmt)	KBUILD_MODNAME	": " fmt
@@ -112,6 +112,9 @@ static void brcmstb_l2_intc_irq_handle(struct irq_desc *desc)
 		generic_handle_domain_irq(b->domain, irq);
 	} while (status);
 out:
+	/* Don't ack parent before all device writes are done */
+	wmb();
+
 	chained_irq_exit(chip, desc);
 }
 
-- 
2.34.1



From frank at oltmanns.dev  Wed Dec 20 10:57:06 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Wed, 20 Dec 2023 19:57:06 +0100
Subject: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher
 clock rate
In-Reply-To: <1845418.atdPhlSkOF@jernej-laptop>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev>
 <1845418.atdPhlSkOF@jernej-laptop>
Message-ID: <875y0sacmz.fsf@oltmanns.dev>


Ok, I've done more detailed testing, and it seems this patch results in
lots of dropped frames. I'm sorry for not being more thorough earlier.
I'll do some more testing without this patch and might have to either
remove it from V2 of this series.

I need to see if the same stability can be achieved when running
PLL-MIPI outside its specied range.

Best regards,
  Frank

On 2023-12-20 at 16:18:49 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a):
>>
>> On 2023-12-19 at 18:04:29 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
>> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns napisal(a):
>> >> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
>> >> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
>> >> than 500 MHz.
>> >>
>> >> Therefore, change [hv]sync_(start|end) so that we reach a clock rate
>> >> that is high enough to drive PLL-MIPI within its limits.
>> >>
>> >> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
>> >
>> > I'm not too sure about this patch. I see that PLL_MIPI doesn't have set
>> > minimum frequency limit in clock driver. If you add it, clock framework
>> > should find rate that is high enough and divisible with target rate.
>>
>> This one is really a tough nut. Unfortunately, the PLL_MIPI clock for
>> this panel has to run exactly at 6 * panel clock. Let me start by
>> showing the relevant part of the clock tree (this is on the pinephone
>> after applying the patches):
>>     pll-video0                 393600000
>>        pll-mipi                500945454
>>           tcon0                500945454
>>              tcon-data-clock   125236363
>>
>> To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit
>> rate [1]. It's a fixed divisor
>>
>> The panel I'm proposing to change is defined as this:
>>
>>     static const struct st7703_panel_desc xbd599_desc = {
>>     	.mode = &xbd599_mode,
>>     	.lanes = 4,
>>     	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
>>     	.format = MIPI_DSI_FMT_RGB888,
>>     	.init_sequence = xbd599_init_sequence,
>>     };
>>
>> So, we have 24 bpp and 4 lanes. Therefore, the resulting requested
>> tcon-data-clock rate is
>>     crtc_clock * 1000 * (24 / 4) / 4
>>
>> tcon-data-clock therefore requests a parent rate of
>>     4 * (crtc_clock * 1000 * (24 / 4) / 4)
>>
>> The initial 4 is the fixed divisor between tcon0 and tcon-data-clock.
>> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi.
>>
>> Since PLL-MIPI has to run at at least at 500MHz this forces us to have a
>> crtc_clock >= 83.333 MHz. The mode I'm prorposing results in a rate of
>> 83.502 MHz.
>
> This is much better explanation why this change is needed. Still, I think
> adding min and max rate to PLL_MIPI would make sense, so proper rates
> are guaranteed.
>
> Anyway, do you know where are all those old values come from? And how did
> you come up with new ones? I guess you can't just simply change timings,
> there are probably some HW limitations? Do you know if BSP kernel support
> this panel and how this situation is solved there?
>
>>
>> If we only changed the constraints on the PLL_MIPI without changing the
>> panel mode, we end up with a mismatch. This, in turn, would result in
>> dropped frames, right?
>
> From what I read, I think frame rate would be higher than 60 fps. What
> exactly would happen depends on the panel.
>
> Best regards,
> Jernej
>
>>
>> Best regards,
>>   Frank
>>
>> [1] Source:
>> https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/sun4i_tcon.c#L346
>>
>> >
>> > Best regards,
>> > Jernej
>> >
>> >> ---
>> >>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++-------
>> >>  1 file changed, 7 insertions(+), 7 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>> >> index b55bafd1a8be..6886fd7f765e 100644
>> >> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>> >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>> >> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
>> >>
>> >>  static const struct drm_display_mode xbd599_mode = {
>> >>  	.hdisplay    = 720,
>> >> -	.hsync_start = 720 + 40,
>> >> -	.hsync_end   = 720 + 40 + 40,
>> >> -	.htotal	     = 720 + 40 + 40 + 40,
>> >> +	.hsync_start = 720 + 65,
>> >> +	.hsync_end   = 720 + 65 + 65,
>> >> +	.htotal      = 720 + 65 + 65 + 65,
>> >>  	.vdisplay    = 1440,
>> >> -	.vsync_start = 1440 + 18,
>> >> -	.vsync_end   = 1440 + 18 + 10,
>> >> -	.vtotal	     = 1440 + 18 + 10 + 17,
>> >> -	.clock	     = 69000,
>> >> +	.vsync_start = 1440 + 30,
>> >> +	.vsync_end   = 1440 + 30 + 22,
>> >> +	.vtotal	     = 1440 + 30 + 22 + 29,
>> >> +	.clock	     = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
>> >>  	.flags	     = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
>> >>  	.width_mm    = 68,
>> >>  	.height_mm   = 136,
>> >>
>> >>
>>


From sboyd at kernel.org  Wed Dec 20 12:15:32 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 20 Dec 2023 12:15:32 -0800
Subject: [GIT PULL] clk: samsung: drivers for v6.8
In-Reply-To: <20231220084043.21549-1-krzysztof.kozlowski@linaro.org>
References: <20231220084043.21549-1-krzysztof.kozlowski@linaro.org>
Message-ID: <00ac7920c506f6a0bb8d11d45c37993c.sboyd@kernel.org>

Quoting Krzysztof Kozlowski (2023-12-20 00:40:43)
> The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
> 
>   Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-clk-6.8
> 
> for you to fetch changes up to 5583e92be5c45448e6ea461e1780d46c17d14963:
> 
>   clk: samsung: Improve kernel-doc comments (2023-11-16 20:46:03 +0100)
> 
> ----------------------------------------------------------------

Thanks. Pulled into clk-next


From gsomlo at gmail.com  Wed Dec 20 12:35:21 2023
From: gsomlo at gmail.com (Gabriel L. Somlo)
Date: Wed, 20 Dec 2023 15:35:21 -0500
Subject: [PATCH RFC 2/5] drivers/soc/litex: Use
 devm_register_restart_handler()
In-Reply-To: <20231117161006.87734-3-afd@ti.com>
References: <20231117161006.87734-1-afd@ti.com>
 <20231117161006.87734-3-afd@ti.com>
Message-ID: <ZYNQCTIRDj1VAwPJ@errol.ini.cmu.edu>

On Fri, Nov 17, 2023 at 10:10:03AM -0600, Andrew Davis wrote:
> Use device life-cycle managed register function to simplify probe error
> path and eliminate need for explicit remove function.
> 
> Signed-off-by: Andrew Davis <afd at ti.com>

Reviewed-by: Gabriel Somlo <gsomlo at gmail.com>

Arnd: the original patch is available here for the purpose of pulling via
the soc tree:
https://lore.kernel.org/lkml/20231117161006.87734-3-afd at ti.com/

Thanks,
--Gabriel

> ---
>  drivers/soc/litex/litex_soc_ctrl.c | 23 +++++------------------
>  1 file changed, 5 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/soc/litex/litex_soc_ctrl.c b/drivers/soc/litex/litex_soc_ctrl.c
> index 10813299aa106..7a0096d93c73d 100644
> --- a/drivers/soc/litex/litex_soc_ctrl.c
> +++ b/drivers/soc/litex/litex_soc_ctrl.c
> @@ -69,14 +69,11 @@ static int litex_check_csr_access(void __iomem *reg_addr)
>  
>  struct litex_soc_ctrl_device {
>  	void __iomem *base;
> -	struct notifier_block reset_nb;
>  };
>  
> -static int litex_reset_handler(struct notifier_block *this, unsigned long mode,
> -			       void *cmd)
> +static int litex_reset_handler(struct sys_off_data *data)
>  {
> -	struct litex_soc_ctrl_device *soc_ctrl_dev =
> -		container_of(this, struct litex_soc_ctrl_device, reset_nb);
> +	struct litex_soc_ctrl_device *soc_ctrl_dev = data->cb_data;
>  
>  	litex_write32(soc_ctrl_dev->base + RESET_REG_OFF, RESET_REG_VALUE);
>  	return NOTIFY_DONE;
> @@ -107,11 +104,9 @@ static int litex_soc_ctrl_probe(struct platform_device *pdev)
>  	if (error)
>  		return error;
>  
> -	platform_set_drvdata(pdev, soc_ctrl_dev);
> -
> -	soc_ctrl_dev->reset_nb.notifier_call = litex_reset_handler;
> -	soc_ctrl_dev->reset_nb.priority = 128;
> -	error = register_restart_handler(&soc_ctrl_dev->reset_nb);
> +	error = devm_register_restart_handler(&pdev->dev,
> +					      litex_reset_handler,
> +					      soc_ctrl_dev);
>  	if (error) {
>  		dev_warn(&pdev->dev, "cannot register restart handler: %d\n",
>  			 error);
> @@ -120,20 +115,12 @@ static int litex_soc_ctrl_probe(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -static void litex_soc_ctrl_remove(struct platform_device *pdev)
> -{
> -	struct litex_soc_ctrl_device *soc_ctrl_dev = platform_get_drvdata(pdev);
> -
> -	unregister_restart_handler(&soc_ctrl_dev->reset_nb);
> -}
> -
>  static struct platform_driver litex_soc_ctrl_driver = {
>  	.driver = {
>  		.name = "litex-soc-controller",
>  		.of_match_table = of_match_ptr(litex_soc_ctrl_of_match)
>  	},
>  	.probe = litex_soc_ctrl_probe,
> -	.remove_new = litex_soc_ctrl_remove,
>  };
>  
>  module_platform_driver(litex_soc_ctrl_driver);
> -- 
> 2.39.2
> 


From jernej.skrabec at gmail.com  Wed Dec 20 12:35:34 2023
From: jernej.skrabec at gmail.com (Jernej Skrabec)
Date: Wed, 20 Dec 2023 21:35:34 +0100
Subject: [PATCH v5 0/3] arm64: add ethernet to orange pi 3 & one plus
Message-ID: <20231220203537.83479-1-jernej.skrabec@gmail.com>

This is continuation of the work done by Corentin:
https://lore.kernel.org/linux-sunxi/20221115073603.3425396-1-clabbe at baylibre.com/

In short, Orange Pi 3 and Orange Pi One Plus boards have ethernet PHYs
which are powered by two voltage regulators. They have to be powered on in
correct order or otherwise they are not functional. Please see link above
for previous discussion on how to achieve that.

Best regards,
Jernej

changes since v1:
- Add regulator_bulk_get_all for ease handling of PHY regulators
- Removed all conversion patches to keep DT compatibility.

Changes since v2:
- removed use of regulator-names and regulators list.

Changes since v3:
- fixes kbuild robot report

Changes since v4:
- dropped merged patches
- reworked PHY powering on/off patch
- added Orange Pi One Plus patch, since it has same issue

Corentin Labbe (1):
  phy: handle optional regulator for PHY

Jernej Skrabec (1):
  arm64: dts: allwinner: orange-pi-one-plus: Fix ethernet

Ondrej Jirman (1):
  arm64: dts: allwinner: orange-pi-3: Enable ethernet

 .../dts/allwinner/sun50i-h6-orangepi-3.dts    | 40 ++++++++++++++
 .../allwinner/sun50i-h6-orangepi-one-plus.dts | 29 +++++++---
 drivers/net/mdio/fwnode_mdio.c                | 53 ++++++++++++++++++-
 drivers/net/phy/phy_device.c                  |  6 +++
 include/linux/phy.h                           |  3 ++
 5 files changed, 122 insertions(+), 9 deletions(-)

-- 
2.43.0



From jernej.skrabec at gmail.com  Wed Dec 20 12:35:35 2023
From: jernej.skrabec at gmail.com (Jernej Skrabec)
Date: Wed, 20 Dec 2023 21:35:35 +0100
Subject: [PATCH v5 1/3] phy: handle optional regulator for PHY
In-Reply-To: <20231220203537.83479-1-jernej.skrabec@gmail.com>
References: <20231220203537.83479-1-jernej.skrabec@gmail.com>
Message-ID: <20231220203537.83479-2-jernej.skrabec@gmail.com>

From: Corentin Labbe <clabbe.montjoie at gmail.com>

Add handling of optional regulators for PHY.

Regulators need to be enabled before PHY scanning, so MDIO bus
initiate this task.

Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec at gmail.com>
---
 drivers/net/mdio/fwnode_mdio.c | 53 ++++++++++++++++++++++++++++++++--
 drivers/net/phy/phy_device.c   |  6 ++++
 include/linux/phy.h            |  3 ++
 3 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index fd02f5cbc853..bd5a27eaf40c 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -11,6 +11,7 @@
 #include <linux/of.h>
 #include <linux/phy.h>
 #include <linux/pse-pd/pse.h>
+#include <linux/regulator/consumer.h>
 
 MODULE_AUTHOR("Calvin Johnson <calvin.johnson at oss.nxp.com>");
 MODULE_LICENSE("GPL");
@@ -58,6 +59,40 @@ fwnode_find_mii_timestamper(struct fwnode_handle *fwnode)
 	return register_mii_timestamper(arg.np, arg.args[0]);
 }
 
+static int
+fwnode_regulator_get_bulk_enabled(struct device *dev,
+				  struct fwnode_handle *fwnode,
+				  struct regulator_bulk_data **consumers)
+{
+	struct device_node *np;
+	int ret, reg_cnt;
+
+	np = to_of_node(fwnode);
+	if (!np)
+		return 0;
+
+	reg_cnt = of_regulator_bulk_get_all(dev, np, consumers);
+	if (reg_cnt < 0) {
+		ret = reg_cnt;
+		goto clean_consumers;
+	}
+
+	if (reg_cnt == 0)
+		return 0;
+
+	ret = regulator_bulk_enable(reg_cnt, *consumers);
+	if (ret)
+		goto clean_consumers;
+
+	return reg_cnt;
+
+clean_consumers:
+	kfree(*consumers);
+	*consumers = NULL;
+
+	return ret;
+}
+
 int fwnode_mdiobus_phy_device_register(struct mii_bus *mdio,
 				       struct phy_device *phy,
 				       struct fwnode_handle *child, u32 addr)
@@ -113,12 +148,13 @@ EXPORT_SYMBOL(fwnode_mdiobus_phy_device_register);
 int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 				struct fwnode_handle *child, u32 addr)
 {
+	struct regulator_bulk_data *consumers = NULL;
 	struct mii_timestamper *mii_ts = NULL;
 	struct pse_control *psec = NULL;
 	struct phy_device *phy;
+	int rc, reg_cnt;
 	bool is_c45;
 	u32 phy_id;
-	int rc;
 
 	psec = fwnode_find_pse_control(child);
 	if (IS_ERR(psec))
@@ -130,6 +166,12 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 		goto clean_pse;
 	}
 
+	reg_cnt = fwnode_regulator_get_bulk_enabled(&bus->dev, child, &consumers);
+	if (reg_cnt < 0) {
+		rc = reg_cnt;
+		goto clean_mii_ts;
+	}
+
 	is_c45 = fwnode_device_is_compatible(child, "ethernet-phy-ieee802.3-c45");
 	if (is_c45 || fwnode_get_phy_id(child, &phy_id))
 		phy = get_phy_device(bus, addr, is_c45);
@@ -137,9 +179,12 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 		phy = phy_device_create(bus, addr, phy_id, 0, NULL);
 	if (IS_ERR(phy)) {
 		rc = PTR_ERR(phy);
-		goto clean_mii_ts;
+		goto clean_regulators;
 	}
 
+	phy->regulator_cnt = reg_cnt;
+	phy->consumers = consumers;
+
 	if (is_acpi_node(child)) {
 		phy->irq = bus->irq[addr];
 
@@ -174,6 +219,10 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 
 clean_phy:
 	phy_device_free(phy);
+clean_regulators:
+	if (reg_cnt > 0)
+		regulator_bulk_disable(reg_cnt, consumers);
+	kfree(consumers);
 clean_mii_ts:
 	unregister_mii_timestamper(mii_ts);
 clean_pse:
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 2ce74593d6e4..31b6913ceed1 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -31,6 +31,7 @@
 #include <linux/phy_led_triggers.h>
 #include <linux/pse-pd/pse.h>
 #include <linux/property.h>
+#include <linux/regulator/consumer.h>
 #include <linux/rtnetlink.h>
 #include <linux/sfp.h>
 #include <linux/skbuff.h>
@@ -3400,6 +3401,11 @@ static int phy_remove(struct device *dev)
 
 	phydev->drv = NULL;
 
+	if (phydev->regulator_cnt > 0)
+		regulator_bulk_disable(phydev->regulator_cnt, phydev->consumers);
+
+	kfree(phydev->consumers);
+
 	return 0;
 }
 
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3cc52826f18e..832cb2d4f76a 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -757,6 +757,9 @@ struct phy_device {
 	void (*phy_link_change)(struct phy_device *phydev, bool up);
 	void (*adjust_link)(struct net_device *dev);
 
+	int regulator_cnt;
+	struct regulator_bulk_data *consumers;
+
 #if IS_ENABLED(CONFIG_MACSEC)
 	/* MACsec management functions */
 	const struct macsec_ops *macsec_ops;
-- 
2.43.0



From jernej.skrabec at gmail.com  Wed Dec 20 12:35:36 2023
From: jernej.skrabec at gmail.com (Jernej Skrabec)
Date: Wed, 20 Dec 2023 21:35:36 +0100
Subject: [PATCH v5 2/3] arm64: dts: allwinner: orange-pi-3: Enable ethernet
In-Reply-To: <20231220203537.83479-1-jernej.skrabec@gmail.com>
References: <20231220203537.83479-1-jernej.skrabec@gmail.com>
Message-ID: <20231220203537.83479-3-jernej.skrabec@gmail.com>

From: Ondrej Jirman <megi at xff.cz>

Orange Pi 3 has two regulators that power the Realtek RTL8211E
PHY. According to the datasheet, both regulators need to be enabled
at the same time, or that "phy-io" should be enabled slightly earlier
than "ephy" regulator.

RTL8211E/RTL8211EG datasheet says:

  Note 4: 2.5V (or 1.8/1.5V) RGMII power should be risen simultaneously
  or slightly earlier than 3.3V power. Rising 2.5V (or 1.8/1.5V) power
  later than 3.3V power may lead to errors.

Signed-off-by: Ondrej Jirman <megi at xff.cz>
Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec at gmail.com>
---
 .../dts/allwinner/sun50i-h6-orangepi-3.dts    | 40 +++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 6fc65e8db220..6ed8613a3169 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -13,6 +13,7 @@ / {
 	compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
 
 	aliases {
+		ethernet0 = &emac;
 		serial0 = &uart0;
 		serial1 = &uart1;
 	};
@@ -55,6 +56,17 @@ led-1 {
 		};
 	};
 
+	reg_gmac_2v5: gmac-2v5 {
+		compatible = "regulator-fixed";
+		regulator-name = "gmac-2v5";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
+		enable-active-high;
+		gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
+		off-on-delay-us = <100000>;
+		vin-supply = <&reg_vcc5v>;
+	};
+
 	reg_vcc5v: vcc5v {
 		/* board wide 5V supply directly from the DC jack */
 		compatible = "regulator-fixed";
@@ -113,6 +125,33 @@ &ehci3 {
 	status = "okay";
 };
 
+&emac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ext_rgmii_pins>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&ext_rgmii_phy>;
+	status = "okay";
+};
+
+&mdio {
+	ext_rgmii_phy: ethernet-phy at 1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+		/*
+		 * The board uses 2.5V RGMII signalling. Power sequence to enable
+		 * the phy is to enable GMAC-2V5 and GMAC-3V (aldo2) power rails
+		 * at the same time and to wait 100ms. The driver enables phy-io
+		 * first. Delay is achieved with enable-ramp-delay on reg_aldo2.
+		 */
+		phy-io-supply = <&reg_gmac_2v5>;
+		ephy-supply = <&reg_aldo2>;
+
+		reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+		reset-assert-us = <15000>;
+		reset-deassert-us = <40000>;
+	};
+};
+
 &gpu {
 	mali-supply = <&reg_dcdcc>;
 	status = "okay";
@@ -211,6 +250,7 @@ reg_aldo2: aldo2 {
 				regulator-min-microvolt = <3300000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-name = "vcc33-audio-tv-ephy-mac";
+				regulator-enable-ramp-delay = <100000>;
 			};
 
 			/* ALDO3 is shorted to CLDO1 */
-- 
2.43.0



From jernej.skrabec at gmail.com  Wed Dec 20 12:35:37 2023
From: jernej.skrabec at gmail.com (Jernej Skrabec)
Date: Wed, 20 Dec 2023 21:35:37 +0100
Subject: [PATCH v5 3/3] arm64: dts: allwinner: orange-pi-one-plus: Fix ethernet
In-Reply-To: <20231220203537.83479-1-jernej.skrabec@gmail.com>
References: <20231220203537.83479-1-jernej.skrabec@gmail.com>
Message-ID: <20231220203537.83479-4-jernej.skrabec@gmail.com>

Orange Pi One Plus has two regulators that power the Realtek RTL8211E
PHY. According to the datasheet, both regulators need to be enabled
at the same time, or that "phy-io" should be enabled slightly earlier
than "ephy" regulator.

RTL8211E/RTL8211EG datasheet says:

  Note 4: 2.5V (or 1.8/1.5V) RGMII power should be risen simultaneously
  or slightly earlier than 3.3V power. Rising 2.5V (or 1.8/1.5V) power
  later than 3.3V power may lead to errors.

Original submission ignored these rules, so it works in some cases but
not all. On top of that, regulator voltages don't reflect actual ones
in hardware. Rework ethernet and PHY nodes to properly reflect HW.

Fixes: 7ee32a17e0d6 ("arm64: dts: allwinner: h6: orangepi-one-plus: Enable ethernet")
Signed-off-by: Jernej Skrabec <jernej.skrabec at gmail.com>
---
 .../allwinner/sun50i-h6-orangepi-one-plus.dts | 29 ++++++++++++++-----
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
index 29a081e72a9b..9c76eecaacce 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dts
@@ -12,15 +12,15 @@ aliases {
 		ethernet0 = &emac;
 	};
 
-	reg_gmac_3v3: gmac-3v3 {
+	reg_gmac_2v5: gmac-2v5 {
 		compatible = "regulator-fixed";
-		regulator-name = "vcc-gmac-3v3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		startup-delay-us = <100000>;
+		regulator-name = "gmac-2v5";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
 		enable-active-high;
 		gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
-		vin-supply = <&reg_aldo2>;
+		off-on-delay-us = <100000>;
+		vin-supply = <&reg_vcc5v>;
 	};
 };
 
@@ -29,7 +29,6 @@ &emac {
 	pinctrl-0 = <&ext_rgmii_pins>;
 	phy-mode = "rgmii-id";
 	phy-handle = <&ext_rgmii_phy>;
-	phy-supply = <&reg_gmac_3v3>;
 	allwinner,rx-delay-ps = <200>;
 	allwinner,tx-delay-ps = <200>;
 	status = "okay";
@@ -39,5 +38,21 @@ &mdio {
 	ext_rgmii_phy: ethernet-phy at 1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		/*
+		 * The board uses 2.5V RGMII signalling. Power sequence to enable
+		 * the phy is to enable GMAC-2V5 and GMAC-3V (aldo2) power rails
+		 * at the same time and to wait 100ms. The driver enables phy-io
+		 * first. Delay is achieved with enable-ramp-delay on reg_aldo2.
+		 */
+		phy-io-supply = <&reg_gmac_2v5>;
+		ephy-supply = <&reg_aldo2>;
+
+		reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+		reset-assert-us = <15000>;
+		reset-deassert-us = <40000>;
 	};
 };
+
+&reg_aldo2 {
+	regulator-enable-ramp-delay = <100000>;
+};
-- 
2.43.0



From Frank.Li at nxp.com  Wed Dec 20 13:35:59 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:35:59 -0500
Subject: [PATCH v5 00/16] PCI: imx6: Clean up and add imx95 pci support
Message-ID: <20231220213615.1561528-1-Frank.Li@nxp.com>

first 6 patches use drvdata: flags to simplify some switch-case code.
Improve maintaince and easy to read code.

Then add imx95 basic pci host function.

follow two patch do endpoint code clean up.
Then add imx95 basic endpont function.

Compared with v2, added EP function support and some fixes,  please change
notes at each patches.

dt-binding pass pcie node:

pcie0: pcie at 4c300000 {
                        compatible = "fsl,imx95-pcie";
                        reg = <0 0x4c300000 0 0x40000>,
                                <0 0x4c360000 0 0x10000>,
                                <0 0x4c340000 0 0x20000>,
                                <0 0x60100000 0 0xfe00000>;
                        reg-names = "dbi", "atu", "app", "config";
                        #address-cells = <3>;
                        #size-cells = <2>;
                        device_type = "pci";
                        linux,pci-domain = <0>;
                        bus-range = <0x00 0xff>;
                        ranges = <0x81000000 0x0 0x00000000 0x0 0x6ff00000 0 0x00100000>,
                                 <0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000>;
                        num-lanes = <1>;
                        num-viewport = <8>;
                        interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
                        interrupt-names = "msi";
                        #interrupt-cells = <1>;
                        interrupt-map-mask = <0 0 0 0x7>;
                        interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 2 &gic 0 0 GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 3 &gic 0 0 GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 4 &gic 0 0 GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
                        fsl,max-link-speed = <3>;
                        clocks = <&scmi_clk IMX95_CLK_HSIO>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                 <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux";
                        assigned-clocks =<&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                         <&scmi_clk IMX95_CLK_HSIOPLL>,
                                         <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        assigned-clock-rates = <3600000000>, <100000000>, <10000000>;
                        assigned-clock-parents = <0>, <0>,
                                                 <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
                        power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
                        /* 0x30~0x37 stream id for pci0 */
                        /*
                         * iommu-map = <0x000 &apps_smmu 0x30 0x1>,
                         * <0x100 &apps_smmu 0x31 0x1>;
                         */
                        status = "disabled";
                };

pcie1: pcie-ep at 4c380000 {
                        compatible = "fsl,imx95-pcie-ep";
                        reg = <0 0x4c380000 0 0x20000>,
                              <0 0x4c3e0000 0 0x1000>,
                              <0 0x4c3a0000 0 0x1000>,
                              <0 0x4c3c0000 0 0x10000>,
                              <0 0x4c3f0000 0 0x10000>,
                              <0xa 0 1 0>;
                        reg-names = "dbi", "atu", "dbi2", "app", "dma", "addr_space";
                        interrupts = <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>;
                        interrupt-names = "dma";
                        fsl,max-link-speed = <3>;
                        clocks = <&scmi_clk IMX95_CLK_HSIO>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                 <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux";
                        assigned-clocks =<&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                         <&scmi_clk IMX95_CLK_HSIOPLL>,
                                         <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        assigned-clock-rates = <3600000000>, <100000000>, <10000000>;
                        assigned-clock-parents = <0>, <0>,
                                                 <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
                        power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
                        status = "disabled";
                };

Frank Li (15):
  PCI: imx6: Simplify clock handling by using bulk_clk_*() function
  PCI: imx6: Simplify phy handling by using by using
    IMX6_PCIE_FLAG_HAS_PHY
  PCI: imx6: Simplify reset handling by using by using
    *_FLAG_HAS_*_RESET
  dt-bindings: imx6q-pcie: Add linux,pci-domain as required for iMX8MQ
  PCI: imx6: Using "linux,pci-domain" as slot ID
  PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
  PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
  PCI: imx6: Simplify switch-case logic by involve init_phy callback
  dt-bindings: imx6q-pcie: Clean up irrationality clocks check
  dt-bindings: imx6q-pcie: remove reg and reg-name
  PCI: imx6: Add iMX95 PCIe support
  PCI: imx6: Clean up get addr_space code
  PCI: imx6: Add epc_features in imx6_pcie_drvdata
  dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
  PCI: imx6: Add iMX95 Endpoint (EP) function support

Richard Zhu (1):
  dt-bindings: imx6q-pcie: Add imx95 pcie compatible string

 .../bindings/pci/fsl,imx6q-pcie-common.yaml   |  28 +-
 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       |  52 +-
 .../bindings/pci/fsl,imx6q-pcie.yaml          |  28 +-
 drivers/pci/controller/dwc/pci-imx6.c         | 628 ++++++++++--------
 4 files changed, 426 insertions(+), 310 deletions(-)

-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:00 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:00 -0500
Subject: [PATCH v5 01/16] PCI: imx6: Simplify clock handling by using bulk_clk_*() function
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-2-Frank.Li@nxp.com>

Refactors the clock handling logic. Adds clk_names[] define in drvdata.
Using clk_bulk*() api simplifies the code.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5
    - update commit message
    - direct using clk name list, instead of macro
    - still keep caculate clk list count because sizeof return pre allocated
    array size.
    
    Change from v3 to v4
    - using clk_bulk_*() API
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 125 ++++++++------------------
 1 file changed, 35 insertions(+), 90 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 74703362aeec7..50d9faaa17f71 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -61,12 +61,15 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 
+#define IMX6_PCIE_MAX_CLKS       6
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
 	u32 flags;
 	int dbi_length;
 	const char *gpr;
+	const char *clk_names[IMX6_PCIE_MAX_CLKS];
 };
 
 struct imx6_pcie {
@@ -74,11 +77,8 @@ struct imx6_pcie {
 	int			reset_gpio;
 	bool			gpio_active_high;
 	bool			link_is_up;
-	struct clk		*pcie_bus;
-	struct clk		*pcie_phy;
-	struct clk		*pcie_inbound_axi;
-	struct clk		*pcie;
-	struct clk		*pcie_aux;
+	struct clk_bulk_data	clks[IMX6_PCIE_MAX_CLKS];
+	u32			clks_cnt;
 	struct regmap		*iomuxc_gpr;
 	u16			msi_ctrl;
 	u32			controller_id;
@@ -407,13 +407,18 @@ static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
 
 static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
 {
-	unsigned long phy_rate = clk_get_rate(imx6_pcie->pcie_phy);
+	unsigned long phy_rate = 0;
 	int mult, div;
 	u16 val;
+	int i;
 
 	if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
 		return 0;
 
+	for (i = 0; i < imx6_pcie->clks_cnt; i++)
+		if (strncmp(imx6_pcie->clks[i].id, "pcie_phy", 8) == 0)
+			phy_rate = clk_get_rate(imx6_pcie->clks[i].clk);
+
 	switch (phy_rate) {
 	case 125000000:
 		/*
@@ -550,19 +555,11 @@ static int imx6_pcie_attach_pd(struct device *dev)
 
 static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	struct dw_pcie *pci = imx6_pcie->pci;
-	struct device *dev = pci->dev;
 	unsigned int offset;
 	int ret = 0;
 
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX6SX:
-		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_axi clock\n");
-			break;
-		}
-
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
 		break;
@@ -589,12 +586,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_aux clock\n");
-			break;
-		}
-
 		offset = imx6_pcie_grp_offset(imx6_pcie);
 		/*
 		 * Set the over ride low and enabled
@@ -615,9 +606,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		clk_disable_unprepare(imx6_pcie->pcie_inbound_axi);
-		break;
 	case IMX6QP:
 	case IMX6Q:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
@@ -631,14 +619,6 @@ static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		clk_disable_unprepare(imx6_pcie->pcie_aux);
-		break;
 	default:
 		break;
 	}
@@ -650,23 +630,9 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 	struct device *dev = pci->dev;
 	int ret;
 
-	ret = clk_prepare_enable(imx6_pcie->pcie_phy);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie_phy clock\n");
+	ret =  clk_bulk_prepare_enable(imx6_pcie->clks_cnt, imx6_pcie->clks);
+	if (ret)
 		return ret;
-	}
-
-	ret = clk_prepare_enable(imx6_pcie->pcie_bus);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie_bus clock\n");
-		goto err_pcie_bus;
-	}
-
-	ret = clk_prepare_enable(imx6_pcie->pcie);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie clock\n");
-		goto err_pcie;
-	}
 
 	ret = imx6_pcie_enable_ref_clk(imx6_pcie);
 	if (ret) {
@@ -679,11 +645,7 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 	return 0;
 
 err_ref_clk:
-	clk_disable_unprepare(imx6_pcie->pcie);
-err_pcie:
-	clk_disable_unprepare(imx6_pcie->pcie_bus);
-err_pcie_bus:
-	clk_disable_unprepare(imx6_pcie->pcie_phy);
+	clk_bulk_disable_unprepare(imx6_pcie->clks_cnt, imx6_pcie->clks);
 
 	return ret;
 }
@@ -691,9 +653,7 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 {
 	imx6_pcie_disable_ref_clk(imx6_pcie);
-	clk_disable_unprepare(imx6_pcie->pcie);
-	clk_disable_unprepare(imx6_pcie->pcie_bus);
-	clk_disable_unprepare(imx6_pcie->pcie_phy);
+	clk_bulk_disable_unprepare(imx6_pcie->clks_cnt, imx6_pcie->clks);
 }
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
@@ -1305,32 +1265,19 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return imx6_pcie->reset_gpio;
 	}
 
-	/* Fetch clocks */
-	imx6_pcie->pcie_bus = devm_clk_get(dev, "pcie_bus");
-	if (IS_ERR(imx6_pcie->pcie_bus))
-		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_bus),
-				     "pcie_bus clock source missing or invalid\n");
+	while (imx6_pcie->drvdata->clk_names[imx6_pcie->clks_cnt]) {
+		int i = imx6_pcie->clks_cnt;
+
+		imx6_pcie->clks[i].id = imx6_pcie->drvdata->clk_names[i];
+		imx6_pcie->clks_cnt++;
+	}
 
-	imx6_pcie->pcie = devm_clk_get(dev, "pcie");
-	if (IS_ERR(imx6_pcie->pcie))
-		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
-				     "pcie clock source missing or invalid\n");
+	/* Fetch clocks */
+	ret = devm_clk_bulk_get(dev, imx6_pcie->clks_cnt, imx6_pcie->clks);
+	if (ret)
+		return ret;
 
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
-							   "pcie_inbound_axi");
-		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
-					     "pcie_inbound_axi clock missing or invalid\n");
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
-		fallthrough;
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
 			imx6_pcie->controller_id = 1;
@@ -1353,10 +1300,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	case IMX8MM_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
 		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
 									 "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
@@ -1372,14 +1315,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	default:
 		break;
 	}
-	/* Don't fetch the pcie_phy clock, if it has abstract PHY driver */
-	if (imx6_pcie->phy == NULL) {
-		imx6_pcie->pcie_phy = devm_clk_get(dev, "pcie_phy");
-		if (IS_ERR(imx6_pcie->pcie_phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_phy),
-					     "pcie_phy clock source missing or invalid\n");
-	}
-
 
 	/* Grab turnoff reset */
 	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
@@ -1477,6 +1412,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1484,6 +1420,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_inbound_axi"},
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1492,40 +1429,48 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:01 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:01 -0500
Subject: [PATCH v5 02/16] PCI: imx6: Simplify phy handling by using by using IMX6_PCIE_FLAG_HAS_PHY
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-3-Frank.Li@nxp.com>

Refactors the phy handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_PHY bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling phy.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5:
    - none, Keep IMX6_PCIE_FLAG_HAS_PHY to indicate dts mismatch when platform
    require phy suppport.
    
    Change from v1 to v3:
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 50d9faaa17f71..4d620249f3d52 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -60,6 +60,9 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
+#define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
+
+#define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
 #define IMX6_PCIE_MAX_CLKS       6
 
@@ -1277,6 +1280,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY)) {
+		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+		if (IS_ERR(imx6_pcie->phy))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
+					     "failed to get pcie phy\n");
+	}
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
@@ -1306,11 +1316,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
 
-		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
-		if (IS_ERR(imx6_pcie->phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
-					     "failed to get pcie phy\n");
-
 		break;
 	default:
 		break;
@@ -1444,13 +1449,15 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
@@ -1462,12 +1469,14 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:02 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:02 -0500
Subject: [PATCH v5 03/16] PCI: imx6: Simplify reset handling by using by using *_FLAG_HAS_*_RESET
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-4-Frank.Li@nxp.com>

Refactors the reset handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling reset.

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5:
    - Add Mani's Reviewed-by tag
    - Fixed MQ_EP's flags
    
    Chagne from v3 to v4:
    - none
    Change from v2 to v3:
    - add Philipp's Reviewed-by tag
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.
    
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.

 drivers/pci/controller/dwc/pci-imx6.c | 108 ++++++++++----------------
 1 file changed, 41 insertions(+), 67 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 4d620249f3d52..294f61a9c6fd9 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -61,6 +61,8 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
+#define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
+#define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -661,18 +663,10 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 {
+	reset_control_assert(imx6_pcie->pciephy_reset);
+	reset_control_assert(imx6_pcie->apps_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_assert(imx6_pcie->pciephy_reset);
-		fallthrough;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
-		break;
 	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
@@ -693,6 +687,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
 		break;
+	default:
+		break;
 	}
 
 	/* Some boards don't have PCIe reset GPIO. */
@@ -706,14 +702,10 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
 
+	reset_control_deassert(imx6_pcie->pciephy_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-		break;
 	case IMX7D:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
 		 * Corrector" and other mysterious undocumented things.
@@ -745,11 +737,7 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 
 		usleep_range(200, 500);
 		break;
-	case IMX6Q:		/* Nothing to do */
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
+	default:
 		break;
 	}
 
@@ -796,16 +784,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2,
 				   IMX6Q_GPR12_PCIE_CTL_2);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_deassert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_deassert(imx6_pcie->apps_reset);
 }
 
 static void imx6_pcie_ltssm_disable(struct device *dev)
@@ -819,16 +802,11 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_assert(imx6_pcie->apps_reset);
 }
 
 static int imx6_pcie_start_link(struct dw_pcie *pci)
@@ -1287,36 +1265,24 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "failed to get pcie phy\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-
-		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
-									    "pciephy");
-		if (IS_ERR(imx6_pcie->pciephy_reset)) {
-			dev_err(dev, "Failed to get PCIEPHY reset control\n");
-			return PTR_ERR(imx6_pcie->pciephy_reset);
-		}
-
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
-		if (IS_ERR(imx6_pcie->apps_reset)) {
-			dev_err(dev, "Failed to get PCIE APPS reset control\n");
-			return PTR_ERR(imx6_pcie->apps_reset);
-		}
-		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET)) {
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev, "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
+	}
 
-		break;
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET)) {
+		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev, "pciephy");
+		if (IS_ERR(imx6_pcie->pciephy_reset))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pciephy_reset),
+					     "Failed to get PCIEPHY reset control\n");
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX7D:
+		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
+			imx6_pcie->controller_id = 1;
 	default:
 		break;
 	}
@@ -1438,31 +1404,39 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
+		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:03 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:03 -0500
Subject: [PATCH v5 04/16] dt-bindings: imx6q-pcie: Add linux,pci-domain as required for iMX8MQ
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-5-Frank.Li@nxp.com>

iMX8MQ have two pci controllers. Adds "linux,pci-domain" as required
proptery for iMX8MQ to indicate pci controller index.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5
    - new patch at v5

 .../bindings/pci/fsl,imx6q-pcie-common.yaml           | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index d91b639ae7ae7..8f39b4e6e8491 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -265,6 +265,17 @@ allOf:
             - const: apps
             - const: turnoff
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fsl,imx8mq-pcie
+              - fsl,imx8mq-pcie-ep
+    then:
+      required:
+        - linux,pci-domain
+
 additionalProperties: true
 
 ...
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:10 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:10 -0500
Subject: [PATCH v5 11/16] dt-bindings: imx6q-pcie: Add imx95 pcie compatible string
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-12-Frank.Li@nxp.com>

From: Richard Zhu <hongxing.zhu at nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
Add "atu" and "app" to reg-names.

Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
---

Notes:
    Change from v2 to v3
    - Remove krzy's ACK tag
    - Add condition check for imx95, which required more reg-names then old
    platform, so need Krzy review again,
    
    Change from v1 to v2
    - add Krzy's ACK tag

 .../bindings/pci/fsl,imx6q-pcie-common.yaml    |  1 +
 .../bindings/pci/fsl,imx6q-pcie.yaml           | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index a284a27c5e873..1b63089ff0aee 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -207,6 +207,7 @@ allOf:
                 - fsl,imx6sx-pcie
                 - fsl,imx6q-pcie
                 - fsl,imx6qp-pcie
+                - fsl,imx95-pcie
                 - fsl,imx6sx-pcie-ep
                 - fsl,imx6q-pcie-ep
                 - fsl,imx6qp-pcie-ep
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index f20d4f0e3cb6c..8633c622bd178 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -29,6 +29,7 @@ properties:
       - fsl,imx8mq-pcie
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
+      - fsl,imx95-pcie
 
   clocks:
     minItems: 3
@@ -80,6 +81,22 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie
+    then:
+      properties:
+        reg:
+          minItems: 4
+        reg-names:
+          items:
+            - const: dbi
+            - const: atu
+            - const: app
+            - const: config
+
   - if:
       properties:
         compatible:
@@ -101,6 +118,7 @@ allOf:
         compatible:
           enum:
             - fsl,imx8mq-pcie
+            - fsl,imx95-pcie
     then:
       properties:
         clocks:
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:11 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:11 -0500
Subject: [PATCH v5 12/16] PCI: imx6: Add iMX95 PCIe support
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-13-Frank.Li@nxp.com>

Add iMX95 PCIe basic root complex function support.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 90 +++++++++++++++++++++++++--
 1 file changed, 85 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index d66a2db53bdb7..9e60ab6f1885a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -42,6 +42,25 @@
 #define IMX8MQ_GPR_PCIE_VREG_BYPASS		BIT(12)
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
 
+#define IMX95_PCIE_PHY_GEN_CTRL			0x0
+#define IMX95_PCIE_REF_USE_PAD			BIT(17)
+
+#define IMX95_PCIE_PHY_MPLLA_CTRL		0x10
+#define IMX95_PCIE_PHY_MPLL_STATE		BIT(30)
+
+#define IMX95_PCIE_SS_RW_REG_0			0xf0
+#define IMX95_PCIE_REF_CLKEN			BIT(23)
+#define IMX95_PCIE_PHY_CR_PARA_SEL		BIT(9)
+
+#define IMX95_PE0_GEN_CTRL_1			0x1050
+#define IMX95_PCIE_DEVICE_TYPE			GENMASK(3, 0)
+
+#define IMX95_PE0_GEN_CTRL_3			0x1058
+#define IMX95_PCIE_LTSSM_EN			BIT(0)
+
+#define IMX95_PE0_PM_STS			0x1064
+#define IMX95_PCIE_PM_LINKST_IN_L2		BIT(14)
+
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -52,6 +71,7 @@ enum imx6_pcie_variants {
 	IMX8MQ,
 	IMX8MM,
 	IMX8MP,
+	IMX95,
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
@@ -63,6 +83,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
+#define IMX6_PCIE_FLAG_HAS_SERDES		BIT(6)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -179,6 +200,24 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
+static int imx95_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			IMX95_PCIE_SS_RW_REG_0,
+			IMX95_PCIE_PHY_CR_PARA_SEL,
+			IMX95_PCIE_PHY_CR_PARA_SEL);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_PHY_GEN_CTRL,
+			   IMX95_PCIE_REF_USE_PAD, 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_SS_RW_REG_0,
+			   IMX95_PCIE_REF_CLKEN,
+			   IMX95_PCIE_REF_CLKEN);
+
+	return 0;
+}
+
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
 	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
@@ -579,6 +618,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
 		break;
 	case IMX7D:
+	case IMX95:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -696,10 +736,19 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 {
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
+	u32 val;
 
 	reset_control_deassert(imx6_pcie->pciephy_reset);
 
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX95:
+		/* Polling the MPLL_STATE */
+		if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+					IMX95_PCIE_PHY_MPLLA_CTRL, val,
+					val & IMX95_PCIE_PHY_MPLL_STATE,
+					10, 10000))
+			dev_err(dev, "PCIe PLL lock timeout\n");
+		break;
 	case IMX7D:
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
@@ -1281,12 +1330,32 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(imx6_pcie->turnoff_reset);
 	}
 
+	if (imx6_pcie->drvdata->gpr) {
 	/* Grab GPR config register range */
-	imx6_pcie->iomuxc_gpr =
-		 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
-	if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
-		dev_err(dev, "unable to find iomuxc registers\n");
-		return PTR_ERR(imx6_pcie->iomuxc_gpr);
+		imx6_pcie->iomuxc_gpr =
+			 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
+	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_SERDES)) {
+		void __iomem *off = devm_platform_ioremap_resource_byname(pdev, "app");
+
+		if (IS_ERR(off))
+			return dev_err_probe(dev, PTR_ERR(off),
+					     "unable to find serdes registers\n");
+
+		static struct regmap_config regmap_config = {
+			.reg_bits = 32,
+			.val_bits = 32,
+			.reg_stride = 4,
+		};
+
+		imx6_pcie->iomuxc_gpr = devm_regmap_init_mmio(dev, off, &regmap_config);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
 	}
 
 	/* Grab PCIe PHY Tx Settings */
@@ -1447,6 +1516,16 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
+	[IMX95] = {
+		.variant = IMX95,
+		.flags = IMX6_PCIE_FLAG_HAS_SERDES,
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
@@ -1488,6 +1567,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
 	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{ .compatible = "fsl,imx8mp-pcie", .data = &drvdata[IMX8MP], },
+	{ .compatible = "fsl,imx95-pcie", .data = &drvdata[IMX95], },
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:12 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:12 -0500
Subject: [PATCH v5 13/16] PCI: imx6: Clean up get addr_space code
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-14-Frank.Li@nxp.com>

The common dw_pcie_ep_init() already do the same thing. Needn't platform
driver do it again.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches

 drivers/pci/controller/dwc/pci-imx6.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 9e60ab6f1885a..4b2b9aafad1b4 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1080,7 +1080,6 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 	int ret;
 	unsigned int pcie_dbi2_offset;
 	struct dw_pcie_ep *ep;
-	struct resource *res;
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct dw_pcie_rp *pp = &pci->pp;
 	struct device *dev = pci->dev;
@@ -1099,14 +1098,8 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 		pcie_dbi2_offset = SZ_4K;
 		break;
 	}
-	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
-	if (!res)
-		return -EINVAL;
 
-	ep->phys_base = res->start;
-	ep->addr_size = resource_size(res);
-	ep->page_size = SZ_64K;
+	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:13 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:13 -0500
Subject: [PATCH v5 14/16] PCI: imx6: Add epc_features in imx6_pcie_drvdata
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-15-Frank.Li@nxp.com>

The i.MX EP exhibits variations in epc_features among different EP
configurations. This introduces the addition of epc_features in
imx6_pcie_drvdata to accommodate these differences. It's important to note
that there are no functional changes in this commit; instead, it lays the
groundwork for supporting i.MX95 EP functions.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patch at v3

 drivers/pci/controller/dwc/pci-imx6.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 4b2b9aafad1b4..6a58fd63a9dd2 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -104,6 +104,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	const struct pci_epc_features *epc_features;
 	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
@@ -1065,7 +1066,10 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
-	return &imx8m_pcie_epc_features;
+	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pci);
+
+	return imx6_pcie->drvdata->epc_features;
 }
 
 static const struct dw_pcie_ep_ops pcie_ep_ops = {
@@ -1530,6 +1534,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
@@ -1540,6 +1545,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
@@ -1549,6 +1555,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:14 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:14 -0500
Subject: [PATCH v5 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-16-Frank.Li@nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
Add reg-name: "atu", "dbi2", "dma" and "serdes".

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches at v3

 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 52 ++++++++++++++++---
 1 file changed, 44 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
index ee155ed5f1811..be9ea77ce8548 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
@@ -22,14 +22,7 @@ properties:
       - fsl,imx8mm-pcie-ep
       - fsl,imx8mq-pcie-ep
       - fsl,imx8mp-pcie-ep
-
-  reg:
-    minItems: 2
-
-  reg-names:
-    items:
-      - const: dbi
-      - const: addr_space
+      - fsl,imx95-pcie-ep
 
   clocks:
     minItems: 3
@@ -62,11 +55,46 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx8mm-pcie-ep
+            - fsl,imx8mq-pcie-ep
+            - fsl,imx8mp-pcie-ep
+    then:
+      properties:
+        reg:
+          minItems: 2
+        reg-names:
+          items:
+            - const: dbi
+            - const: addr_space
+
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie-ep
+    then:
+      properties:
+        reg:
+          minItems: 6
+        reg-names:
+          items:
+            - const: dbi
+            - const: atu
+            - const: dbi2
+            - const: app
+            - const: dma
+            - const: addr_space
+
   - if:
       properties:
         compatible:
           enum:
             - fsl,imx8mq-pcie-ep
+            - fsl,imx95-pcie-ep
     then:
       properties:
         clocks:
@@ -87,6 +115,14 @@ allOf:
             - const: pcie_bus
             - const: pcie_aux
 
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie-ep
+    then:
+      properties:
+        linux,pci-domain: true
 
 unevaluatedProperties: false
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:15 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:15 -0500
Subject: [PATCH v5 16/16] PCI: imx6: Add iMX95 Endpoint (EP) function support
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-17-Frank.Li@nxp.com>

Add iMX95 EP function support and add 64bit address support. Internal bus
bridge for PCI support 64bit dma address in iMX95. So set call
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)).

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v3 to v4
    - change align to 4k for imx95
    Change from v1 to v3
    - new patches at v3

 drivers/pci/controller/dwc/pci-imx6.c | 45 +++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 6a58fd63a9dd2..00ec59867c17b 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,7 @@ enum imx6_pcie_variants {
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
+	IMX95_EP,
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
@@ -84,6 +85,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
 #define IMX6_PCIE_FLAG_HAS_SERDES		BIT(6)
+#define IMX6_PCIE_FLAG_SUPPORT_64BIT		BIT(7)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -620,6 +622,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 		break;
 	case IMX7D:
 	case IMX95:
+	case IMX95_EP:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -1063,6 +1066,23 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 	.align = SZ_64K,
 };
 
+/*
+ * BAR#	| Default BAR enable	| Default BAR Type	| Default BAR Size	| BAR Sizing Scheme
+ * ================================================================================================
+ * BAR0	| Enable		| 64-bit		| 1 MB			| Programmable Size
+ * BAR1	| Disable		| 32-bit		| 64 KB			| Fixed Size
+ *	| (BAR0 is 64-bit)	| if BAR0 is 32-bit	|			| As Bar0 is 64bit
+ * BAR2	| Enable		| 32-bit		| 1 MB			| Programmable Size
+ * BAR3	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ * BAR4	| Enable		| 32-bit		| 1M			| Programmable Size
+ * BAR5	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ */
+static const struct pci_epc_features imx95_pcie_epc_features = {
+	.msi_capable = true,
+	.bar_fixed_size[1] = SZ_64K,
+	.align = SZ_4K,
+};
+
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
@@ -1105,6 +1125,14 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 
 	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
+	/*
+	 * db2 information should fetch from dtb file. dw_pcie_ep_init() can get dbi_base2 from
+	 * "dbi2" if pci->dbi_base2 is NULL. All code related pcie_dbi2_offset should be removed
+	 * after all dts added "dbi2" reg.
+	 */
+	if (imx6_pcie->drvdata->variant == IMX95_EP)
+		pci->dbi_base2 = NULL;
+
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
 		dev_err(dev, "failed to initialize endpoint\n");
@@ -1355,6 +1383,9 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "unable to find iomuxc registers\n");
 	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_SUPPORT_64BIT))
+		dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+
 	/* Grab PCIe PHY Tx Settings */
 	if (of_property_read_u32(node, "fsl,tx-deemph-gen1",
 				 &imx6_pcie->tx_deemph_gen1))
@@ -1557,6 +1588,19 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.epc_features = &imx8m_pcie_epc_features,
 	},
+	[IMX95_EP] = {
+		.variant = IMX95_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_SERDES |
+			 IMX6_PCIE_FLAG_SUPPORT_64BIT,
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+		.epc_features = &imx95_pcie_epc_features,
+		.mode = DW_PCIE_EP_TYPE,
+	},
 };
 
 static const struct of_device_id imx6_pcie_of_match[] = {
@@ -1571,6 +1615,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
+	{ .compatible = "fsl,imx95-pcie-ep", .data = &drvdata[IMX95_EP], },
 	{},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:05 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:05 -0500
Subject: [PATCH v5 06/16] PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-7-Frank.Li@nxp.com>

Add drvdata::ltssm_off and drvdata::ltssm_mask to simple
imx6_pcie_ltssm_enable(disable)() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 37 ++++++++++++---------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 332c392f8e5bc..588bfb616260e 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,8 @@ struct imx6_pcie_drvdata {
 	int dbi_length;
 	const char *gpr;
 	const char *clk_names[IMX6_PCIE_MAX_CLKS];
+	const u32 ltssm_off;
+	const u32 ltssm_mask;
 };
 
 struct imx6_pcie {
@@ -775,18 +777,11 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_ltssm_enable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2,
-				   IMX6Q_GPR12_PCIE_CTL_2);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off, drvdata->ltssm_mask,
+				   drvdata->ltssm_mask);
 
 	reset_control_deassert(imx6_pcie->apps_reset);
 }
@@ -794,17 +789,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 static void imx6_pcie_ltssm_disable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2, 0);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off,
+				   drvdata->ltssm_mask, 0);
 
 	reset_control_assert(imx6_pcie->apps_reset);
 }
@@ -1385,6 +1374,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1393,6 +1384,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_inbound_axi"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1402,6 +1395,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:07 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:07 -0500
Subject: [PATCH v5 08/16] PCI: imx6: Simplify switch-case logic by involve init_phy callback
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-9-Frank.Li@nxp.com>

Add drvdata::init_phy() callback function, so difference SOC choose
difference callback function to simple switch-case logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    change from v1 to v4:
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 135 ++++++++++++++------------
 1 file changed, 71 insertions(+), 64 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 717e8fa030deb..d66a2db53bdb7 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -69,6 +69,9 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_MAX_CLKS       6
 
 #define IMX6_PCIE_MAX_INSTANCES			2
+
+struct imx6_pcie;
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -80,6 +83,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
 struct imx6_pcie {
@@ -323,76 +327,69 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
 	return 0;
 }
 
-static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+static int imx8mq_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		/*
-		 * The PHY initialization had been done in the PHY
-		 * driver, break here directly.
-		 */
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		/*
-		 * TODO: Currently this code assumes external
-		 * oscillator is being used
-		 */
+	/*
+	 * TODO: Currently this code assumes external
+	 * oscillator is being used
+	 */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   imx6_pcie_grp_offset(imx6_pcie),
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD,
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD);
+	/*
+	 * Regarding the datasheet, the PCIE_VPH is suggested
+	 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
+	 * VREG_BYPASS should be cleared to zero.
+	 */
+	if (imx6_pcie->vph && regulator_get_voltage(imx6_pcie->vph) > 3000000)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr,
 				   imx6_pcie_grp_offset(imx6_pcie),
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD,
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD);
-		/*
-		 * Regarding the datasheet, the PCIE_VPH is suggested
-		 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
-		 * VREG_BYPASS should be cleared to zero.
-		 */
-		if (imx6_pcie->vph &&
-		    regulator_get_voltage(imx6_pcie->vph) > 3000000)
-			regmap_update_bits(imx6_pcie->iomuxc_gpr,
-					   imx6_pcie_grp_offset(imx6_pcie),
-					   IMX8MQ_GPR_PCIE_VREG_BYPASS,
-					   0);
-		break;
-	case IMX7D:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX8MQ_GPR_PCIE_VREG_BYPASS,
+				   0);
+
+	return 0;
+}
+
+static int imx7d_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	return	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
-		break;
-	case IMX6SX:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6SX_GPR12_PCIE_RX_EQ_MASK,
-				   IMX6SX_GPR12_PCIE_RX_EQ_2);
-		fallthrough;
-	default:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+}
+
+static int imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 
-		/* configure constant input signal to the pcie ctrl and phy */
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
-
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN1,
-				   imx6_pcie->tx_deemph_gen1 << 0);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
-				   imx6_pcie->tx_deemph_gen2_3p5db << 6);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
-				   imx6_pcie->tx_deemph_gen2_6db << 12);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_FULL,
-				   imx6_pcie->tx_swing_full << 18);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_LOW,
-				   imx6_pcie->tx_swing_low << 25);
-		break;
-	}
+	/* configure constant input signal to the pcie ctrl and phy */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN1,
+			   imx6_pcie->tx_deemph_gen1 << 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
+			   imx6_pcie->tx_deemph_gen2_3p5db << 6);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
+			   imx6_pcie->tx_deemph_gen2_6db << 12);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_FULL,
+			   imx6_pcie->tx_swing_full << 18);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_LOW,
+			   imx6_pcie->tx_swing_low << 25);
+	return 0;
+}
 
-	imx6_pcie_configure_type(imx6_pcie);
+static int imx6sx_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6SX_GPR12_PCIE_RX_EQ_MASK, IMX6SX_GPR12_PCIE_RX_EQ_2);
+
+	return imx6_pcie_init_phy(imx6_pcie);
 }
 
 static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
@@ -903,7 +900,11 @@ static int imx6_pcie_host_init(struct dw_pcie_rp *pp)
 	}
 
 	imx6_pcie_assert_core_reset(imx6_pcie);
-	imx6_pcie_init_phy(imx6_pcie);
+
+	if (imx6_pcie->drvdata->init_phy)
+		imx6_pcie->drvdata->init_phy(imx6_pcie);
+
+	imx6_pcie_configure_type(imx6_pcie);
 
 	ret = imx6_pcie_clk_enable(imx6_pcie);
 	if (ret) {
@@ -1374,6 +1375,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1386,6 +1388,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6sx_pcie_init_phy,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1399,6 +1402,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1409,6 +1413,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx7d_pcie_init_phy,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1420,6 +1425,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1452,6 +1458,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:04 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:04 -0500
Subject: [PATCH v5 05/16] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-6-Frank.Li@nxp.com>

Avoid use get slot id by compared with register physical address. If there
are more than 2 slots, compared logic will become complex.

"linux,pci-domain" already exist at dts since commit:
	commit (c0b70f05c87f3b arm64: dts: imx8mq: use_dt_domains for pci node).

So it is safe to remove compare basic address code:
	...
	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
		imx6_pcie->controller_id = 1;
	...

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v3 to v4
    - remove compare basic address logic
    Change from v2 to v3
    - none
    Change from v1 to v2
    - fix of_get_pci_domain_nr return value check logic

 drivers/pci/controller/dwc/pci-imx6.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 294f61a9c6fd9..332c392f8e5bc 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -33,6 +33,7 @@
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
+#include "../../pci.h"
 #include "pcie-designware.h"
 
 #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
@@ -40,7 +41,6 @@
 #define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE	BIT(11)
 #define IMX8MQ_GPR_PCIE_VREG_BYPASS		BIT(12)
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
-#define IMX8MQ_PCIE2_BASE_ADDR			0x33c00000
 
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
@@ -1279,13 +1279,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "Failed to get PCIEPHY reset control\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-	default:
-		break;
-	}
+	/* Using linux,pci-domain as PCI slot id */
+	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
+	/* If there are not "linux,pci-domain" in dts file, means only 1 controller */
+	if (imx6_pcie->controller_id == -EINVAL)
+		imx6_pcie->controller_id = 0;
+	else if (imx6_pcie->controller_id < 0)
+		return dev_err_probe(dev, imx6_pcie->controller_id,
+				     "linux,pci-domain have wrong value\n");
 
 	/* Grab turnoff reset */
 	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:06 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:06 -0500
Subject: [PATCH v5 07/16] PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-8-Frank.Li@nxp.com>

Add drvdata::mode_off and drvdata::mode_mask to simple
imx6_pcie_configure_type() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v2 to v3
    - none
    Change from v1 to v2
    - use ffs() to fixe build error.

 drivers/pci/controller/dwc/pci-imx6.c | 60 ++++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 588bfb616260e..717e8fa030deb 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -68,6 +68,7 @@ enum imx6_pcie_variants {
 
 #define IMX6_PCIE_MAX_CLKS       6
 
+#define IMX6_PCIE_MAX_INSTANCES			2
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -77,6 +78,8 @@ struct imx6_pcie_drvdata {
 	const char *clk_names[IMX6_PCIE_MAX_CLKS];
 	const u32 ltssm_off;
 	const u32 ltssm_mask;
+	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
+	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
 };
 
 struct imx6_pcie {
@@ -174,32 +177,25 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
-	unsigned int mask, val, mode;
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
+	unsigned int mask, val, mode, id;
 
-	if (imx6_pcie->drvdata->mode == DW_PCIE_EP_TYPE)
+	if (drvdata->mode == DW_PCIE_EP_TYPE)
 		mode = PCI_EXP_TYPE_ENDPOINT;
 	else
 		mode = PCI_EXP_TYPE_ROOT_PORT;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		if (imx6_pcie->controller_id == 1) {
-			mask = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
-					  mode);
-		} else {
-			mask = IMX6Q_GPR12_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		}
-		break;
-	default:
-		mask = IMX6Q_GPR12_DEVICE_TYPE;
-		val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		break;
-	}
+	id = imx6_pcie->controller_id;
+
+	/* If mode_mask[id] is zero, means each controller have its individual gpr */
+	if (!drvdata->mode_mask[id])
+		id = 0;
+
+	mask = drvdata->mode_mask[id];
+	/* FIELD_PREP mask have been constant */
+	val = mode << (ffs(mask) - 1);
 
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, mask, val);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->mode_off[id], mask, val);
 }
 
 static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
@@ -1376,6 +1372,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1386,6 +1384,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_inbound_axi"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1397,6 +1397,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1405,6 +1407,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1412,6 +1416,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1420,6 +1428,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
@@ -1428,6 +1438,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
@@ -1436,6 +1448,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
@@ -1443,6 +1459,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
@@ -1450,6 +1468,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:08 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:08 -0500
Subject: [PATCH v5 09/16] dt-bindings: imx6q-pcie: Clean up irrationality clocks check
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-10-Frank.Li@nxp.com>

There are clocks and clock-names restriction for difference compatible
string. So needn't irrationality check again for clock's miniItems and
maxItems.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v4
    - new patch at v4

 .../bindings/pci/fsl,imx6q-pcie-common.yaml      | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index 8f39b4e6e8491..a284a27c5e873 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -150,22 +150,6 @@ allOf:
             - {}
             - const: pcie_phy
             - const: pcie_aux
-  - if:
-      properties:
-        compatible:
-          not:
-            contains:
-              enum:
-                - fsl,imx6sx-pcie
-                - fsl,imx8mq-pcie
-                - fsl,imx6sx-pcie-ep
-                - fsl,imx8mq-pcie-ep
-    then:
-      properties:
-        clocks:
-          maxItems: 3
-        clock-names:
-          maxItems: 3
 
   - if:
       properties:
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 20 13:36:09 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 20 Dec 2023 16:36:09 -0500
Subject: [PATCH v5 10/16] dt-bindings: imx6q-pcie: remove reg and reg-name
In-Reply-To: <20231220213615.1561528-1-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
Message-ID: <20231220213615.1561528-11-Frank.Li@nxp.com>

snps,dw-pcie.yaml already have reg and reg-name information. Needn't
duplciate here.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5
    - add Rob's Acked
    Change from v1 to v4:
    - new patch at v4

 .../devicetree/bindings/pci/fsl,imx6q-pcie.yaml        | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 81bbb8728f0f9..f20d4f0e3cb6c 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -30,16 +30,6 @@ properties:
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
 
-  reg:
-    items:
-      - description: Data Bus Interface (DBI) registers.
-      - description: PCIe configuration space region.
-
-  reg-names:
-    items:
-      - const: dbi
-      - const: config
-
   clocks:
     minItems: 3
     items:
-- 
2.34.1



From jacob.e.keller at intel.com  Wed Dec 20 14:12:10 2023
From: jacob.e.keller at intel.com (Jacob Keller)
Date: Wed, 20 Dec 2023 14:12:10 -0800
Subject: [PATCH v2 1/2] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <20231220002824.2462655-2-cristian.ciocaltea@collabora.com>
References: <20231220002824.2462655-1-cristian.ciocaltea@collabora.com>
 <20231220002824.2462655-2-cristian.ciocaltea@collabora.com>
Message-ID: <7249a8c0-b97f-4634-a08b-06be503f8c71@intel.com>



On 12/19/2023 4:28 PM, Cristian Ciocaltea wrote:
> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
> similar to the newer JH7110, but it requires only two interrupts and a
> single reset line, which is 'ahb' instead of the commonly used
> 'stmmaceth'.
> 
> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
> conjunction with 'stmmaceth', extend the logic to also permit exclusive
> usage of the 'ahb' reset name.  This ensures the following use cases are
> supported:
> 
>   JH7110: reset-names = "stmmaceth", "ahb";
>   JH7100: reset-names = "ahb";
>   other:  reset-names = "stmmaceth";
> 
> Also note the need to use a different dwmac fallback, as v5.20 applies
> to JH7110 only, while JH7100 relies on v3.7x.
> 
> Additionally, drop the reset description items from top-level binding as
> they are already provided by the included snps,dwmac schema.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
> ---

Reviewed-by: Jacob Keller <jacob.e.keller at intel.com>


From sboyd at kernel.org  Wed Dec 20 14:16:46 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 20 Dec 2023 14:16:46 -0800
Subject: [PATCH v7 1/2] clk: stm32: introduce clocks for STM32MP257 platform
In-Reply-To: <20231219130909.265091-2-gabriel.fernandez@foss.st.com>
References: <20231219130909.265091-1-gabriel.fernandez@foss.st.com> <20231219130909.265091-2-gabriel.fernandez@foss.st.com>
Message-ID: <c98539f99030f174583d7ee36802b4b9.sboyd@kernel.org>

Quoting gabriel.fernandez at foss.st.com (2023-12-19 05:09:08)
> diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
> new file mode 100644
> index 000000000000..313e022c6142
> --- /dev/null
> +++ b/drivers/clk/stm32/clk-stm32mp25.c
> @@ -0,0 +1,1826 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
> + * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +
> +#include "clk-stm32-core.h"
> +#include "reset-stm32.h"
> +#include "stm32mp25_rcc.h"
> +
> +#include <dt-bindings/clock/st,stm32mp25-rcc.h>
> +#include <dt-bindings/reset/st,stm32mp25-rcc.h>
> +
> +static const struct clk_parent_data adc12_src[] = {
> +       { .name = "ck_flexgen_46" },

This is a new driver. Don't use .name here. Instead use .index or .hw
and if that can't work then use .fw_name.

> +       { .name = "ck_icn_ls_mcu" },
> +};
> +
> +static const struct clk_parent_data adc3_src[] = {
> +       { .name = "ck_flexgen_47" },
> +       { .name = "ck_icn_ls_mcu" },
> +       { .name = "ck_flexgen_46" },
> +};
[...]
> +static struct clk_stm32_composite ck_ker_usb3pciephy = {
> +       .gate_id = GATE_USB3PCIEPHY,
> +       .mux_id = MUX_USB3PCIEPHY,
> +       .div_id = NO_STM32_DIV,
> +       .hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_usb3pciephy", usb3pciphy_src,
> +                                           &clk_stm32_composite_ops, 0),
> +};
> +
> +/* USB3 DRD */
> +static struct clk_stm32_gate ck_icn_m_usb3dr = {
> +       .gate_id = GATE_USB3DR,
> +       .hw.init = CLK_HW_INIT("ck_icn_m_usb3dr", "ck_icn_hsl", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_ker_usb2phy2 = {
> +       .gate_id = GATE_USB3DR,
> +       .hw.init = CLK_HW_INIT("ck_ker_usb2phy2", "ck_flexgen_58", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* USBTC */
> +static struct clk_stm32_gate ck_icn_p_usbtc = {
> +       .gate_id = GATE_USBTC,
> +       .hw.init = CLK_HW_INIT("ck_icn_p_usbtc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),

Please stop using strings to match parents, i.e. don't use CLK_HW_INIT.

> +};
> +
> +static struct clk_stm32_gate ck_ker_usbtc = {
> +       .gate_id = GATE_USBTC,
> +       .hw.init = CLK_HW_INIT("ck_ker_usbtc", "ck_flexgen_35", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* VDEC / VENC */
> +static struct clk_stm32_gate ck_icn_p_vdec = {
> +       .gate_id = GATE_VDEC,
> +       .hw.init = CLK_HW_INIT("ck_icn_p_vdec", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_venc = {
> +       .gate_id = GATE_VENC,
> +       .hw.init = CLK_HW_INIT("ck_icn_p_venc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* VREF */
> +static struct clk_stm32_gate ck_icn_p_vref = {
> +       .gate_id = GATE_VREF,
> +       .hw.init = CLK_HW_INIT("ck_icn_p_vref", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
> +};
> +
> +/* WWDG */
> +static struct clk_stm32_gate ck_icn_p_wwdg1 = {
> +       .gate_id = GATE_WWDG1,
> +       .hw.init = CLK_HW_INIT("ck_icn_p_wwdg1", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
> +};
> +
> +static struct clk_stm32_gate ck_icn_p_wwdg2 = {
> +       .gate_id = GATE_WWDG2,
> +       .hw.init = CLK_HW_INIT("ck_icn_p_wwdg2", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
> +};
> +
> +enum security_clk {
> +       SECF_NONE,

What is the use of this single value enum?

> +};
> +
> +static const struct clock_config stm32mp25_clock_cfg[] = {
> +       STM32_GATE_CFG(CK_BUS_ETH1,             ck_icn_p_eth1,          SECF_NONE),
> +       STM32_GATE_CFG(CK_BUS_ETH2,             ck_icn_p_eth2,          SECF_NONE),
[....]
> +
> +static const struct of_device_id stm32mp25_match_data[] = {
> +       {
> +               .compatible = "st,stm32mp25-rcc",
> +               .data = &stm32mp25_data,
> +       },

One line please:

 	{ .compatible = "st,stm32mp25-rcc", .data = &stm32mp25_data, },

> +       { }
> +};
> +MODULE_DEVICE_TABLE(of, stm32mp25_match_data);
> +
> +static int get_clock_deps(struct device *dev)

What is the explanation for this function?

> +{
> +       static const char * const clock_deps_name[] = {
> +               "hsi", "hse", "msi", "lsi", "lse",
> +       };
> +       int i;
> +
> +       for (i = 0; i < ARRAY_SIZE(clock_deps_name); i++) {
> +               struct clk *clk;
> +
> +               clk = of_clk_get_by_name(dev_of_node(dev), clock_deps_name[i]);
> +               if (IS_ERR(clk))
> +                       return PTR_ERR(clk);
> +
> +               clk_put(clk);
> +       }
> +
> +       return 0;
> +}
> +
> +static int stm32mp25_rcc_clocks_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       void __iomem *base;
> +       int ret;
> +
> +       ret = get_clock_deps(dev);
> +       if (ret)
> +               return ret;
> +
> +       base = devm_of_iomap(dev, dev->of_node, 0, NULL);

Use platform device APIs.

> +       if (WARN_ON(IS_ERR(base)))
> +               return PTR_ERR(base);
> +
> +       return stm32_rcc_init(dev, stm32mp25_match_data, base);
> +}
> +
> +static int stm32mp25_rcc_clocks_remove(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct device_node *child, *np = dev_of_node(dev);
> +
> +       for_each_available_child_of_node(np, child)
> +               of_clk_del_provider(child);

Add the providers with devm?

> +
> +       return 0;
> +}
> +
> +static struct platform_driver stm32mp25_rcc_clocks_driver = {
> +       .driver = {
> +               .name = "stm32mp25_rcc",
> +               .of_match_table = stm32mp25_match_data,
> +       },
> +       .probe = stm32mp25_rcc_clocks_probe,
> +       .remove = stm32mp25_rcc_clocks_remove,
> +};
> +
> +static int __init stm32mp25_clocks_init(void)
> +{
> +       return platform_driver_register(&stm32mp25_rcc_clocks_driver);
> +}
> +
> +core_initcall(stm32mp25_clocks_init);


From robh at kernel.org  Wed Dec 20 14:27:30 2023
From: robh at kernel.org (Rob Herring)
Date: Wed, 20 Dec 2023 16:27:30 -0600
Subject: [PATCH 1/2] dt-bindings: mtd: partitions: u-boot: Fix typo
In-Reply-To: <20231218130656.9020-1-wahrenst@gmx.net>
References: <20231218130656.9020-1-wahrenst@gmx.net>
Message-ID: <170311124964.1238110.7971021577049808628.robh@kernel.org>


On Mon, 18 Dec 2023 14:06:55 +0100, Stefan Wahren wrote:
> The initial description contained a typo.
> 
> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
> ---
>  Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh at kernel.org>



From andreyknvl at gmail.com  Wed Dec 20 14:50:37 2023
From: andreyknvl at gmail.com (Andrey Konovalov)
Date: Wed, 20 Dec 2023 23:50:37 +0100
Subject: MTE false-positive with shared userspace/kernel mapping
In-Reply-To: <ZM06vS0JrAVBYv2x@arm.com>
References: <CA+fCnZdeMfx4Y-+tNcnDzNYj6fJ9pFMApLQD93csftCFV7zSow@mail.gmail.com>
 <ZM06vS0JrAVBYv2x@arm.com>
Message-ID: <CA+fCnZcEj8Gm-Q51TXMr84jF5sRUko8mbOYgvz_tERpb4ijTnw@mail.gmail.com>

On Fri, Aug 4, 2023 at 7:52?PM Catalin Marinas <catalin.marinas at arm.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jul 20, 2023 at 08:28:12PM +0200, Andrey Konovalov wrote:
> > Syzbot reported an issue originating from the packet sockets code [1],
> > but it seems to be an MTE false-positive with a shared
> > userspace/kernel mapping.
> >
> > The problem is that mmap_region calls arch_validate_flags to check
> > VM_MTE_ALLOWED only after mapping memory for a non-anonymous mapping
> > via call_mmap().
>
> That was on purpose as we can have some specific mmap implementation
> that can set VM_MTE_ALLOWED. We only do this currently for shmem_mmap().
> But I haven't thought of the vm_insert_page() case.
>
> > What happens in the reproducer [2] is:
> >
> > 1. Userspace creates a packet socket and makes the kernel allocate the
> > backing memory for a shared mapping via alloc_one_pg_vec_page.
> > 2. Userspace calls mmap _with PROT_MTE_ on a packet socket file descriptor.
> > 3. mmap code sets VM_MTE via calc_vm_prot_bits(), as PROT_MTE has been provided.
> > 3. mmap code calls the packet socket mmap handler packet_mmap via
> > call_mmap() (without checking VM_MTE_ALLOWED at this point).
> > 4. Packet socket code uses vm_insert_page to map the memory allocated
> > in step #1 to the userspace area.
> > 5. arm64 code resets memory tags for the backing memory via
> > vm_insert_page->...->__set_pte_at->mte_sync_tags(), as the memory is
> > MT_NORMAL_TAGGED due to VM_MTE.
> > 6. Only now the mmap code checks VM_MTE_ALLOWED via
> > arch_validate_flags() and unmaps the area, but the memory tags have
> > already been reset.
> > 5. The packet socket code accesses the area through its tagged kernel
> > address via __packet_get_status(), which leads to a tag mismatch.
>
> Ah, so we end up rejecting the mmap() eventually but the damage was done
> by clearing the tags on the kernel page via a brief set_pte_at(). I
> assume the problem only triggers with kasan enabled, though even without
> kasan, we shouldn't allow a set_pte_at(PROT_MTE) for a vma that does not
> allow MTE.
>
> > I'm not sure what would be the best fix here. Moving
> > arch_validate_flags() before call_mmap() would be an option, but maybe
> > you have a better suggestion.
>
> This would break the shmem case (though not sure who's using that). Also
> since many drivers do vm_flags_set() (unrelated to MTE), it makes more
> sense for arch_validate_flags() to happen after call_mmap().
>
> Not ideal but an easy fix is calling arch_validate_flags() in those
> specific mmap functions that call vm_insert_page(). They create a
> mapping before the core code had a chance to validate the flags. Unless
> we find a different solution for shmem_mmap() so that we can move the
> arch_validate_flags() earlier.

Just FTR: filed a KASAN bug to not forget about this issue:

https://bugzilla.kernel.org/show_bug.cgi?id=218295


From linus.walleij at linaro.org  Wed Dec 20 15:00:52 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 21 Dec 2023 00:00:52 +0100
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
In-Reply-To: <CACRpkdbo=Oem4PCOtSV6iWJoojRetTgZhx7J91uecTa-DQA8iQ@mail.gmail.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <20231218162326.173127-2-romain.gantois@bootlin.com> <20231219122034.pg2djgrosa4irubh@skbuf>
 <20231219140754.7a7a8dbd@device-28.home> <CACRpkdaxy9u=1-rQ+f+1tb8xyV-GYOuq52xhb4_SRPk9-LpnUA@mail.gmail.com>
 <20231219172932.13f4b0c3@device-28.home> <20231219224616.pw32w5eq2dbuja5i@skbuf>
 <CACRpkdbo=Oem4PCOtSV6iWJoojRetTgZhx7J91uecTa-DQA8iQ@mail.gmail.com>
Message-ID: <CACRpkdY2U-SmNZ=52qTFBcYtqe63MHdBY=FUFitfBfjb3aYeBQ@mail.gmail.com>

On Wed, Dec 20, 2023 at 1:43?AM Linus Walleij <linus.walleij at linaro.org> wrote:

> Then for *this* driver I need to check for the ethertype
> ETH_P_8021Q what is inside it, one level down, and that is a
> separate helper. And I named it skb_vlan_raw_inner_ethertype()
> It will retrieve the inner type no matter
>
> include/linux/if_vlan.h
>
> +/* This determines the inner ethertype incoded into the skb data without
> + * relying on skb->protocol which is not always identical.
> + */
> +static inline u16 skb_vlan_raw_inner_ethertype(const struct sk_buff *skb)
> +{
> +       struct vlan_ethhdr *vhdr;
> +
> +       if (!skb_pointer_if_linear(skb, 0, VLAN_ETH_HLEN))
> +               return 0x0000U;
> +
> +       vhdr = vlan_eth_hdr(skb);
> +       return ntohs(vhdr->h_vlan_encapsulated_proto);
> +}
>
> (We can bikeshed the name of the function. *_inner_protocol maybe.)
>
> It does not handle nested VLANs and I don't see why it should since
> the immediate siblings in if_vlan.h does not, i.e.
> vlan_eth_hdr(), skb_vlan_eth_hdr(). It's pretty clear these helpers
> all go just one level down. (We can add a *_descend_*()
> helper the day someone needs that.)

Forget this whole discussion because in <linux/if_vlan.h>
there is already vlan_get_protocol() and vlan_get_protocol_and_depth()
so this problem is already solved, just better.

Yours,
Linus Walleij


From bhe at redhat.com  Wed Dec 20 15:30:47 2023
From: bhe at redhat.com (Baoquan He)
Date: Thu, 21 Dec 2023 07:30:47 +0800
Subject: [PATCH v4 5/7] kexec_file, ricv: print out debugging message if
 required
In-Reply-To: <20231220074634.cd736ec567cd7adf1e4c6d7e@linux-foundation.org>
References: <20231213055747.61826-1-bhe@redhat.com>
 <20231213055747.61826-6-bhe@redhat.com>
 <20231219-twitch-many-ca8877857182@spud>
 <ZYJsBW0Y7Y+XhSgf@MiWiFi-R3L-srv>
 <20231220074634.cd736ec567cd7adf1e4c6d7e@linux-foundation.org>
Message-ID: <ZYN5Jy4PVh3ghbxN@MiWiFi-R3L-srv>

On 12/20/23 at 07:46am, Andrew Morton wrote:
> On Wed, 20 Dec 2023 12:22:29 +0800 Baoquan He <bhe at redhat.com> wrote:
> 
> > Could you help fix the typo in subject?
> > 
> > [PATCH v4 5/7] kexec_file, ricv: print out debugging message if required
> >                            ~~~ s/ricv/riscv/
> 
> I made that change.

Thanks a lot.



From markhas at chromium.org  Wed Dec 20 15:54:19 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Wed, 20 Dec 2023 16:54:19 -0700
Subject: [PATCH v2 05/22] ARM: dts: rockchip: rk3288: Enable cros-ec-spi as wake source
In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
Message-ID: <20231220165423.v2.5.I8249df4df0b7d12fb68ea1e69f84ca589c574bb1@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to match expected behavior.

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

Changes in v2:
-Split by arch/soc

 arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi
index 092316be67f74..1554fe36e60fe 100644
--- a/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi
@@ -112,6 +112,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_int>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Wed Dec 20 15:54:20 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Wed, 20 Dec 2023 16:54:20 -0700
Subject: [PATCH v2 06/22] ARM: dts: samsung: exynos5420: Enable cros-ec-spi as wake source
In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
Message-ID: <20231220165423.v2.6.I06b059021de1bf6103e60a73211f078f2af75d17@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to match expected behavior.

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

Changes in v2:
-Split by arch/soc

 arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts b/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts
index 4e757b6e28e1c..3759742d38cac 100644
--- a/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts
@@ -967,6 +967,7 @@ cros_ec: cros-ec at 0 {
 		reg = <0>;
 		spi-max-frequency = <3125000>;
 		google,has-vbc-nvram;
+		wakeup-source;
 
 		controller-data {
 			samsung,spi-feedback-delay = <1>;
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Wed Dec 20 15:54:21 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Wed, 20 Dec 2023 16:54:21 -0700
Subject: [PATCH v2 07/22] ARM: dts: samsung: exynos5800: Enable cros-ec-spi as wake source
In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
Message-ID: <20231220165423.v2.7.Idc995ce08a52ba4c5fde0685118ddf2873fc8acd@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to match expected behavior.

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

Changes in v2:
-Split by arch/soc

 arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts b/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts
index f91bc4ae008e4..9bbbdce9103a6 100644
--- a/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts
@@ -949,6 +949,7 @@ cros_ec: cros-ec at 0 {
 		reg = <0>;
 		spi-max-frequency = <3125000>;
 		google,has-vbc-nvram;
+		wakeup-source;
 
 		controller-data {
 			samsung,spi-feedback-delay = <1>;
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Wed Dec 20 15:54:22 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Wed, 20 Dec 2023 16:54:22 -0700
Subject: [PATCH v2 08/22] arm64: dts: mediatek: mt8173: Enable cros-ec-spi as wake source
In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
Message-ID: <20231220165423.v2.8.Ic09ebe116c18e83cc1161f4bb073fea8043f03f3@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to match expected behavior.

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index 111495622cacd..190a3ffd81471 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -1163,6 +1163,7 @@ cros_ec: ec at 0 {
 		interrupt-parent = <&pio>;
 		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
 		google,cros-ec-spi-msg-delay = <500>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel0 {
 			compatible = "google,cros-ec-i2c-tunnel";
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Wed Dec 20 15:54:23 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Wed, 20 Dec 2023 16:54:23 -0700
Subject: [PATCH v2 09/22] arm64: dts: mediatek: mt8183: Enable cros-ec-spi as wake source
In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
Message-ID: <20231220165423.v2.9.Iba4a8b7e908989e57f7838a80013a4062be5e614@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to match expected behavior.

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index 7881a27be0297..06cbf29d16215 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -922,6 +922,7 @@ cros_ec: cros-ec at 0 {
 		interrupts = <151 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_ap_int_odl>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Wed Dec 20 15:54:24 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Wed, 20 Dec 2023 16:54:24 -0700
Subject: [PATCH v2 10/22] arm64: dts: mediatek: mt8192: Enable cros-ec-spi as wake source
In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
Message-ID: <20231220165423.v2.10.Ibd330d26a00f5e219a7e448452769124833a9762@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to match expected behavior.

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
index f2281250ac35d..ab44d382f757e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
@@ -1332,6 +1332,7 @@ cros_ec: ec at 0 {
 		spi-max-frequency = <3000000>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&cros_ec_int>;
+		wakeup-source;
 
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Wed Dec 20 15:54:25 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Wed, 20 Dec 2023 16:54:25 -0700
Subject: [PATCH v2 11/22] arm64: dts: mediatek: mt8195: Enable cros-ec-spi as wake source
In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
Message-ID: <20231220165423.v2.11.Iee33a7f1f991408cef372744199026f936bf54e2@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to match expected behavior.

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index 5a7cab489ff3a..4292b72566bcf 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -1067,6 +1067,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&cros_ec_int>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		keyboard-backlight {
 			compatible = "google,cros-kbd-led-backlight";
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Wed Dec 20 15:54:30 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Wed, 20 Dec 2023 16:54:30 -0700
Subject: [PATCH v2 16/22] arm64: dts: rockchip: rk3399: Enable cros-ec-spi as wake source
In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
Message-ID: <20231220165423.v2.16.Ice617703aded22ad4c806459129e1ae693eb57af@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to match expected behavior.

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 789fd0dcc88ba..b5734e056aef1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -603,6 +603,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_ap_int_l>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
-- 
2.43.0.472.g3155946c3a-goog



From daniel.diaz at linaro.org  Wed Dec 20 16:06:53 2023
From: daniel.diaz at linaro.org (=?UTF-8?B?RGFuaWVsIETDrWF6?=)
Date: Wed, 20 Dec 2023 18:06:53 -0600
Subject: selftests: ftrace: Internal error: Oops: sve_save_state
In-Reply-To: <63e92a6a-9cb7-4272-b524-ccaf997aceb3@sirena.org.uk>
References: <CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com>
 <ad5b7442-385d-41db-9202-a36414460610@sirena.org.uk> <CA+G9fYsbwWpDVR9KJXx8UO5MXsYT81uAJbLLNDnLianr8jmXUA@mail.gmail.com>
 <63e92a6a-9cb7-4272-b524-ccaf997aceb3@sirena.org.uk>
Message-ID: <CAEUSe7_9tE5K7NpsmaG_v_bTJaMGhVVSDRhMn1QYnr2z4vSg8w@mail.gmail.com>

Hello!

On Thu, 19 Oct 2023 at 11:26, Mark Brown <broonie at kernel.org> wrote:
> On Thu, Oct 19, 2023 at 09:07:02PM +0530, Naresh Kamboju wrote:
> > On Tue, 17 Oct 2023 at 17:52, Mark Brown <broonie at kernel.org> wrote:
[...]
> > > To confirm have you seen this on other stables as well or is this only
> > > v6.5?  For how long have you been seeing this?
>
> > This is only seen on 6.5.8-rc2 and seen only once.
> > I have checked on mainline / next and other stable branches and this crash
> > is not seen anywhere else.
>
> > However, I will keep checking them on other branches and next and mainline.
>
> I see.  If the bug has never been reproduced I don't think we can draw
> any conclusion about which branches are affected, I would be a bit
> surprised by something that affects v6.5 only.

We have been seeing this problem in other instances, specifically on
the following kernels:
* 5.15.132, 5.15.134-rc1, 5.15.135, 5.15.136-rc1, 5.15.142, 5.15.145-rc1
* 6.1.42, 6.1.43, 6.1.51-rc1, 6.1.56-rc1, 6.1.59-rc1, 6.1.63
* 6.3.10, 6.3.11
* 6.4.7
* 6.5.2, 6.5.10-rc2

Most recent case is for the current 5.15 RC. Decoded stack trace is here:
-----8<-----
  <4>[   29.297166] ------------[ cut here ]------------
  <4>[ 29.298039] WARNING: CPU: 1 PID: 220 at
arch/arm64/kernel/fpsimd.c:950 do_sve_acc
(/builds/linux/arch/arm64/kernel/fpsimd.c:950 (discriminator 1))
  <4>[   29.300418] Modules linked in: fuse drm dm_mod ip_tables x_tables
  <4>[   29.302720] CPU: 1 PID: 220 Comm: systemd-udevd Not tainted
5.15.145-rc1 #1
  <4>[   29.303601] Hardware name: linux,dummy-virt (DT)
  <4>[   29.304804] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT
-SSBS BTYPE=--)
  <4>[ 29.305615] pc : do_sve_acc
(/builds/linux/arch/arm64/kernel/fpsimd.c:950 (discriminator 1))
  <4>[ 29.306499] lr : do_sve_acc
(/builds/linux/arch/arm64/include/asm/jump_label.h:38
/builds/linux/arch/arm64/include/asm/lse.h:24
/builds/linux/arch/arm64/include/asm/atomic.h:86
/builds/linux/include/linux/atomic/atomic-long.h:335
/builds/linux/include/asm-generic/bitops/atomic.h:42
/builds/linux/include/asm-generic/bitops/instrumented-atomic.h:71
/builds/linux/include/linux/thread_info.h:108
/builds/linux/arch/arm64/kernel/fpsimd.c:949)
  <4>[   29.307466] sp : ffff8000083b3e60
  <4>[   29.308447] x29: ffff8000083b3e60 x28: ffff0000c2f42000 x27:
0000000000000000
  <4>[   29.310500] x26: 0000000000000000 x25: 0000000000000000 x24:
0000000000000000
  <4>[   29.312034] x23: 0000000080001000 x22: 0000ffffb3c8a454 x21:
00000000ffffffff
  <4>[   29.313338] x20: 0000000064000000 x19: ffff0000c2f42000 x18:
0000000000000000
  <4>[   29.314636] x17: 0000000000000000 x16: 0000000000000000 x15:
0000000000000000
  <4>[   29.316090] x14: 0000000000000000 x13: 0000000000000000 x12:
0000000000000000
  <4>[   29.317096] x11: 0000000000000000 x10: 0000000000000000 x9 :
ffffb047a36178f4
  <4>[   29.318131] x8 : ffff0000c2c4d888 x7 : 0000000000000000 x6 :
0000000000000200
  <4>[   29.319171] x5 : ffffb047a5c6f260 x4 : 0000000000000200 x3 :
0000000000000001
  <4>[   29.320180] x2 : 0000000000000000 x1 : ffff4fb95a329000 x0 :
0000000000800800
  <4>[   29.321599] Call trace:
  <4>[ 29.321996] do_sve_acc
(/builds/linux/arch/arm64/kernel/fpsimd.c:950 (discriminator 1))
  <4>[ 29.322674] el0_sve_acc
(/builds/linux/arch/arm64/include/asm/daifflags.h:28
/builds/linux/arch/arm64/kernel/entry-common.c:129
/builds/linux/arch/arm64/kernel/entry-common.c:138
/builds/linux/arch/arm64/kernel/entry-common.c:529)
  <4>[ 29.323273] el0t_64_sync_handler
(/builds/linux/arch/arm64/kernel/entry-common.c:639)
  <4>[ 29.323951] el0t_64_sync (/builds/linux/arch/arm64/kernel/entry.S:584)
  <4>[   29.324598] ---[ end trace b31d3b95f436e1b5 ]---
----->8-----

Complete log (and reproducer) here:
  https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2ZoYpOR79EjlFiAuFHeOWN2rwC3

Artifacts (including vmlinux and System.map) can be found here:
  https://storage.tuxsuite.com/public/linaro/lkft/builds/2ZoYoIewSKk26jISEo4QlNaOvVR/

Greetings!

Daniel D?az
daniel.diaz at linaro.org


From pr-tracker-bot at kernel.org  Wed Dec 20 16:25:17 2023
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Thu, 21 Dec 2023 00:25:17 +0000
Subject: [GIT PULL] ARM: SoC fixes for 6.7, part 2
In-Reply-To: <10ff8b28-3892-4920-b4a0-4612fe814f6d@app.fastmail.com>
References: <10ff8b28-3892-4920-b4a0-4612fe814f6d@app.fastmail.com>
Message-ID: <170311831724.17908.9476961698840609318.pr-tracker-bot@kernel.org>

The pull request you sent on Wed, 20 Dec 2023 13:21:17 +0000:

> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-fixes-6.7-2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/87c71dd604e54b412db09b74cb67ebce09c57cd5

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From dmitry.baryshkov at linaro.org  Wed Dec 20 16:28:08 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 02:28:08 +0200
Subject: [PATCH v6 2/5] iommu/arm-smmu: refactor qcom_smmu structure to
 include single pointer
In-Reply-To: <20231220133808.5654-3-quic_bibekkum@quicinc.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com> <20231220133808.5654-3-quic_bibekkum@quicinc.com>
Message-ID: <CAA8EJpoh_jsA6UrH1aEaJ4cufBTKENvG1zqjciy7WSTEh9nmnQ@mail.gmail.com>

On Wed, 20 Dec 2023 at 15:38, Bibek Kumar Patro
<quic_bibekkum at quicinc.com> wrote:
>
> qcom_smmu_match_data is static and constant so refactor qcom_smmu
> to store single pointer to qcom_smmu_match_data instead of
> replicating multiple child members of the same and handle the further
> dereferences in the places that want them.
>
> Suggested-by: Robin Murphy <robin.murphy at arm.com>
> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 2 +-
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c       | 2 +-
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h       | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>

-- 
With best wishes
Dmitry


From mhiramat at kernel.org  Wed Dec 20 16:34:42 2023
From: mhiramat at kernel.org (Masami Hiramatsu (Google))
Date: Thu, 21 Dec 2023 09:34:42 +0900
Subject: selftests: ftrace: Internal error: Oops: sve_save_state
In-Reply-To: <CAEUSe7_9tE5K7NpsmaG_v_bTJaMGhVVSDRhMn1QYnr2z4vSg8w@mail.gmail.com>
References: <CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com>
	<ad5b7442-385d-41db-9202-a36414460610@sirena.org.uk>
	<CA+G9fYsbwWpDVR9KJXx8UO5MXsYT81uAJbLLNDnLianr8jmXUA@mail.gmail.com>
	<63e92a6a-9cb7-4272-b524-ccaf997aceb3@sirena.org.uk>
	<CAEUSe7_9tE5K7NpsmaG_v_bTJaMGhVVSDRhMn1QYnr2z4vSg8w@mail.gmail.com>
Message-ID: <20231221093442.3c4b84f0d39350f9deb4e51f@kernel.org>

Hi Daniel,

Would you know what ftrace selftest testcase script is running when
this crash happened? I think it depends on the selftest version but
I don't know which one you run.

Thank you,

On Wed, 20 Dec 2023 18:06:53 -0600
Daniel D?az <daniel.diaz at linaro.org> wrote:

> Hello!
> 
> On Thu, 19 Oct 2023 at 11:26, Mark Brown <broonie at kernel.org> wrote:
> > On Thu, Oct 19, 2023 at 09:07:02PM +0530, Naresh Kamboju wrote:
> > > On Tue, 17 Oct 2023 at 17:52, Mark Brown <broonie at kernel.org> wrote:
> [...]
> > > > To confirm have you seen this on other stables as well or is this only
> > > > v6.5?  For how long have you been seeing this?
> >
> > > This is only seen on 6.5.8-rc2 and seen only once.
> > > I have checked on mainline / next and other stable branches and this crash
> > > is not seen anywhere else.
> >
> > > However, I will keep checking them on other branches and next and mainline.
> >
> > I see.  If the bug has never been reproduced I don't think we can draw
> > any conclusion about which branches are affected, I would be a bit
> > surprised by something that affects v6.5 only.
> 
> We have been seeing this problem in other instances, specifically on
> the following kernels:
> * 5.15.132, 5.15.134-rc1, 5.15.135, 5.15.136-rc1, 5.15.142, 5.15.145-rc1
> * 6.1.42, 6.1.43, 6.1.51-rc1, 6.1.56-rc1, 6.1.59-rc1, 6.1.63
> * 6.3.10, 6.3.11
> * 6.4.7
> * 6.5.2, 6.5.10-rc2
> 
> Most recent case is for the current 5.15 RC. Decoded stack trace is here:
> -----8<-----
>   <4>[   29.297166] ------------[ cut here ]------------
>   <4>[ 29.298039] WARNING: CPU: 1 PID: 220 at
> arch/arm64/kernel/fpsimd.c:950 do_sve_acc
> (/builds/linux/arch/arm64/kernel/fpsimd.c:950 (discriminator 1))
>   <4>[   29.300418] Modules linked in: fuse drm dm_mod ip_tables x_tables
>   <4>[   29.302720] CPU: 1 PID: 220 Comm: systemd-udevd Not tainted
> 5.15.145-rc1 #1
>   <4>[   29.303601] Hardware name: linux,dummy-virt (DT)
>   <4>[   29.304804] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT
> -SSBS BTYPE=--)
>   <4>[ 29.305615] pc : do_sve_acc
> (/builds/linux/arch/arm64/kernel/fpsimd.c:950 (discriminator 1))
>   <4>[ 29.306499] lr : do_sve_acc
> (/builds/linux/arch/arm64/include/asm/jump_label.h:38
> /builds/linux/arch/arm64/include/asm/lse.h:24
> /builds/linux/arch/arm64/include/asm/atomic.h:86
> /builds/linux/include/linux/atomic/atomic-long.h:335
> /builds/linux/include/asm-generic/bitops/atomic.h:42
> /builds/linux/include/asm-generic/bitops/instrumented-atomic.h:71
> /builds/linux/include/linux/thread_info.h:108
> /builds/linux/arch/arm64/kernel/fpsimd.c:949)
>   <4>[   29.307466] sp : ffff8000083b3e60
>   <4>[   29.308447] x29: ffff8000083b3e60 x28: ffff0000c2f42000 x27:
> 0000000000000000
>   <4>[   29.310500] x26: 0000000000000000 x25: 0000000000000000 x24:
> 0000000000000000
>   <4>[   29.312034] x23: 0000000080001000 x22: 0000ffffb3c8a454 x21:
> 00000000ffffffff
>   <4>[   29.313338] x20: 0000000064000000 x19: ffff0000c2f42000 x18:
> 0000000000000000
>   <4>[   29.314636] x17: 0000000000000000 x16: 0000000000000000 x15:
> 0000000000000000
>   <4>[   29.316090] x14: 0000000000000000 x13: 0000000000000000 x12:
> 0000000000000000
>   <4>[   29.317096] x11: 0000000000000000 x10: 0000000000000000 x9 :
> ffffb047a36178f4
>   <4>[   29.318131] x8 : ffff0000c2c4d888 x7 : 0000000000000000 x6 :
> 0000000000000200
>   <4>[   29.319171] x5 : ffffb047a5c6f260 x4 : 0000000000000200 x3 :
> 0000000000000001
>   <4>[   29.320180] x2 : 0000000000000000 x1 : ffff4fb95a329000 x0 :
> 0000000000800800
>   <4>[   29.321599] Call trace:
>   <4>[ 29.321996] do_sve_acc
> (/builds/linux/arch/arm64/kernel/fpsimd.c:950 (discriminator 1))
>   <4>[ 29.322674] el0_sve_acc
> (/builds/linux/arch/arm64/include/asm/daifflags.h:28
> /builds/linux/arch/arm64/kernel/entry-common.c:129
> /builds/linux/arch/arm64/kernel/entry-common.c:138
> /builds/linux/arch/arm64/kernel/entry-common.c:529)
>   <4>[ 29.323273] el0t_64_sync_handler
> (/builds/linux/arch/arm64/kernel/entry-common.c:639)
>   <4>[ 29.323951] el0t_64_sync (/builds/linux/arch/arm64/kernel/entry.S:584)
>   <4>[   29.324598] ---[ end trace b31d3b95f436e1b5 ]---
> ----->8-----
> 
> Complete log (and reproducer) here:
>   https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2ZoYpOR79EjlFiAuFHeOWN2rwC3
> 
> Artifacts (including vmlinux and System.map) can be found here:
>   https://storage.tuxsuite.com/public/linaro/lkft/builds/2ZoYoIewSKk26jISEo4QlNaOvVR/
> 
> Greetings!
> 
> Daniel D?az
> daniel.diaz at linaro.org


-- 
Masami Hiramatsu (Google) <mhiramat at kernel.org>


From dmitry.baryshkov at linaro.org  Wed Dec 20 16:36:36 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 02:36:36 +0200
Subject: [PATCH v6 3/5] iommu/arm-smmu: introduction of ACTLR for custom
 prefetcher settings
In-Reply-To: <20231220133808.5654-4-quic_bibekkum@quicinc.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com> <20231220133808.5654-4-quic_bibekkum@quicinc.com>
Message-ID: <CAA8EJpo8X+jfi20N9P7kUshxe6_7pwQe8G0Q02JDuB8ozH7hLA@mail.gmail.com>

On Wed, 20 Dec 2023 at 15:39, Bibek Kumar Patro
<quic_bibekkum at quicinc.com> wrote:
>
> Currently in Qualcomm  SoCs the default prefetch is set to 1 which allows
> the TLB to fetch just the next page table. MMU-500 features ACTLR
> register which is implementation defined and is used for Qualcomm SoCs
> to have a custom prefetch setting enabling TLB to prefetch the next set
> of page tables accordingly allowing for faster translations.
>
> ACTLR value is unique for each SMR (Stream matching register) and stored
> in a pre-populated table. This value is set to the register during
> context bank initialisation.
>
> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 45 ++++++++++++++++++++++
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h |  6 ++-
>  drivers/iommu/arm/arm-smmu/arm-smmu.c      |  5 ++-
>  drivers/iommu/arm/arm-smmu/arm-smmu.h      |  5 +++
>  4 files changed, 58 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index 20c9836d859b..1cefdd0ca110 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -24,6 +24,12 @@
>  #define CPRE                   (1 << 1)
>  #define CMTLB                  (1 << 0)
>
> +struct actlr_config {
> +       u16 sid;
> +       u16 mask;
> +       u32 actlr;
> +};
> +
>  static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
>  {
>         return container_of(smmu, struct qcom_smmu, smmu);
> @@ -215,9 +221,38 @@ static bool qcom_adreno_can_do_ttbr1(struct arm_smmu_device *smmu)
>         return true;
>  }
>
> +static void qcom_smmu_set_actlr(struct device *dev, struct arm_smmu_device *smmu, int cbndx,
> +               const struct actlr_config *actlrcfg)
> +{
> +       struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
> +       struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> +       struct arm_smmu_smr *smr;
> +       u16 mask;
> +       int idx;
> +       u16 id;
> +       int i;
> +
> +       for (; actlrcfg->sid || actlrcfg->mask || actlrcfg->actlr; actlrcfg++) {
> +               id = actlrcfg->sid;
> +               mask = actlrcfg->mask;
> +
> +               for_each_cfg_sme(cfg, fwspec, i, idx) {
> +                       smr = &smmu->smrs[idx];
> +                       if (smr_is_subset(smr, id, mask)) {
> +                               arm_smmu_cb_write(smmu, cbndx, ARM_SMMU_CB_ACTLR,
> +                                               actlrcfg->actlr);
> +                               break;
> +                       }
> +               }
> +       }
> +}
> +
>  static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
>                 struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
>  {
> +       struct arm_smmu_device *smmu = smmu_domain->smmu;
> +       struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
> +       int cbndx = smmu_domain->cfg.cbndx;
>         struct adreno_smmu_priv *priv;
>
>         smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
> @@ -248,6 +283,9 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
>         priv->set_stall = qcom_adreno_smmu_set_stall;
>         priv->resume_translation = qcom_adreno_smmu_resume_translation;
>
> +       if (qsmmu->data->actlrcfg_gfx)
> +               qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg_gfx);

There was a feedback point against v4 that there can be more than two
(apps + gpu) SMMU devices. No, we can not use additional compat
strings, the SMMU units are compatible with each other. Please add
matching between the smmu and particular actlr table using the IO
address of the SMMU block.

> +
>         return 0;
>  }
>
> @@ -274,6 +312,13 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
>  static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain,
>                 struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
>  {
> +       struct arm_smmu_device *smmu = smmu_domain->smmu;
> +       struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
> +       int cbndx = smmu_domain->cfg.cbndx;
> +
> +       if (qsmmu->data->actlrcfg)
> +               qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg);
> +

One issue occured to me, while I was reviewing the patchset. The ACTLR
settings are related to the whole SMMU setup, but we are applying them
each time there is an SMMU context init (in other words, one per each
domain). Is that correct? Or it's just that there is no better place
for initialising the global register set? Would it be better to
reprogram the ACTLR registers which are related just to this
particular domain?

>         smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
>
>         return 0;
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
> index f3b91963e234..cb4cb402c202 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  /*
> - * Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
>   */
>
>  #ifndef _ARM_SMMU_QCOM_H
> @@ -24,7 +24,11 @@ struct qcom_smmu_config {
>         const u32 *reg_offset;
>  };
>
> +struct actlr_config;
> +
>  struct qcom_smmu_match_data {
> +       const struct actlr_config *actlrcfg;
> +       const struct actlr_config *actlrcfg_gfx;
>         const struct qcom_smmu_config *cfg;
>         const struct arm_smmu_impl *impl;
>         const struct arm_smmu_impl *adreno_impl;
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index d6d1a2a55cc0..0c7f700b27dd 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -990,9 +990,10 @@ static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
>                  * expect simply identical entries for this case, but there's
>                  * no harm in accommodating the generalisation.
>                  */
> -               if ((mask & smrs[i].mask) == mask &&
> -                   !((id ^ smrs[i].id) & ~smrs[i].mask))
> +
> +               if (smr_is_subset(&smrs[i], id, mask))
>                         return i;
> +
>                 /*
>                  * If the new entry has any other overlap with an existing one,
>                  * though, then there always exists at least one stream ID
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 703fd5817ec1..2e4f65412c6b 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -501,6 +501,11 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
>                 writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);
>  }
>
> +static inline bool smr_is_subset(struct arm_smmu_smr *smrs, u16 id, u16 mask)
> +{
> +       return (mask & smrs->mask) == mask && !((id ^ smrs->id) & ~smrs->mask);
> +}
> +
>  #define ARM_SMMU_GR0           0
>  #define ARM_SMMU_GR1           1
>  #define ARM_SMMU_CB(s, n)      ((s)->numpage + (n))
> --
> 2.17.1
>


-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Wed Dec 20 16:37:25 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 02:37:25 +0200
Subject: [PATCH v6 3/5] iommu/arm-smmu: introduction of ACTLR for custom
 prefetcher settings
In-Reply-To: <CAA8EJpo8X+jfi20N9P7kUshxe6_7pwQe8G0Q02JDuB8ozH7hLA@mail.gmail.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
 <20231220133808.5654-4-quic_bibekkum@quicinc.com> <CAA8EJpo8X+jfi20N9P7kUshxe6_7pwQe8G0Q02JDuB8ozH7hLA@mail.gmail.com>
Message-ID: <CAA8EJppypaVCBLV1rGPUgbVdtm9Zz9haJiYd=4ar+-bXLPh7DA@mail.gmail.com>

On Thu, 21 Dec 2023 at 02:36, Dmitry Baryshkov
<dmitry.baryshkov at linaro.org> wrote:
>
> On Wed, 20 Dec 2023 at 15:39, Bibek Kumar Patro
> <quic_bibekkum at quicinc.com> wrote:
> >
> > Currently in Qualcomm  SoCs the default prefetch is set to 1 which allows
> > the TLB to fetch just the next page table. MMU-500 features ACTLR
> > register which is implementation defined and is used for Qualcomm SoCs
> > to have a custom prefetch setting enabling TLB to prefetch the next set
> > of page tables accordingly allowing for faster translations.
> >
> > ACTLR value is unique for each SMR (Stream matching register) and stored
> > in a pre-populated table. This value is set to the register during
> > context bank initialisation.
> >
> > Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
> > ---
> >  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 45 ++++++++++++++++++++++
> >  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h |  6 ++-
> >  drivers/iommu/arm/arm-smmu/arm-smmu.c      |  5 ++-
> >  drivers/iommu/arm/arm-smmu/arm-smmu.h      |  5 +++
> >  4 files changed, 58 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > index 20c9836d859b..1cefdd0ca110 100644
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > @@ -24,6 +24,12 @@
> >  #define CPRE                   (1 << 1)
> >  #define CMTLB                  (1 << 0)
> >
> > +struct actlr_config {
> > +       u16 sid;
> > +       u16 mask;
> > +       u32 actlr;
> > +};
> > +
> >  static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
> >  {
> >         return container_of(smmu, struct qcom_smmu, smmu);
> > @@ -215,9 +221,38 @@ static bool qcom_adreno_can_do_ttbr1(struct arm_smmu_device *smmu)
> >         return true;
> >  }
> >
> > +static void qcom_smmu_set_actlr(struct device *dev, struct arm_smmu_device *smmu, int cbndx,
> > +               const struct actlr_config *actlrcfg)
> > +{
> > +       struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
> > +       struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > +       struct arm_smmu_smr *smr;
> > +       u16 mask;
> > +       int idx;
> > +       u16 id;
> > +       int i;
> > +
> > +       for (; actlrcfg->sid || actlrcfg->mask || actlrcfg->actlr; actlrcfg++) {
> > +               id = actlrcfg->sid;
> > +               mask = actlrcfg->mask;
> > +
> > +               for_each_cfg_sme(cfg, fwspec, i, idx) {
> > +                       smr = &smmu->smrs[idx];
> > +                       if (smr_is_subset(smr, id, mask)) {
> > +                               arm_smmu_cb_write(smmu, cbndx, ARM_SMMU_CB_ACTLR,
> > +                                               actlrcfg->actlr);
> > +                               break;
> > +                       }
> > +               }
> > +       }
> > +}
> > +
> >  static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
> >                 struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
> >  {
> > +       struct arm_smmu_device *smmu = smmu_domain->smmu;
> > +       struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
> > +       int cbndx = smmu_domain->cfg.cbndx;
> >         struct adreno_smmu_priv *priv;
> >
> >         smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
> > @@ -248,6 +283,9 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
> >         priv->set_stall = qcom_adreno_smmu_set_stall;
> >         priv->resume_translation = qcom_adreno_smmu_resume_translation;
> >
> > +       if (qsmmu->data->actlrcfg_gfx)
> > +               qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg_gfx);
>
> There was a feedback point against v4 that there can be more than two
> (apps + gpu) SMMU devices. No, we can not use additional compat
> strings, the SMMU units are compatible with each other. Please add
> matching between the smmu and particular actlr table using the IO
> address of the SMMU block.
>
> > +
> >         return 0;
> >  }
> >
> > @@ -274,6 +312,13 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
> >  static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain,
> >                 struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
> >  {
> > +       struct arm_smmu_device *smmu = smmu_domain->smmu;
> > +       struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
> > +       int cbndx = smmu_domain->cfg.cbndx;
> > +
> > +       if (qsmmu->data->actlrcfg)
> > +               qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg);
> > +
>
> One issue occured to me, while I was reviewing the patchset. The ACTLR
> settings are related to the whole SMMU setup, but we are applying them
> each time there is an SMMU context init (in other words, one per each
> domain). Is that correct? Or it's just that there is no better place
> for initialising the global register set? Would it be better to
> reprogram the ACTLR registers which are related just to this
> particular domain?

Ignore this, I went back to qcom_smmu_set_actlr() and understood that
I failed to read it properly.

>
> >         smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
> >
> >         return 0;
> > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
> > index f3b91963e234..cb4cb402c202 100644
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
> > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
> > @@ -1,6 +1,6 @@
> >  /* SPDX-License-Identifier: GPL-2.0-only */
> >  /*
> > - * Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
> > + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
> >   */
> >
> >  #ifndef _ARM_SMMU_QCOM_H
> > @@ -24,7 +24,11 @@ struct qcom_smmu_config {
> >         const u32 *reg_offset;
> >  };
> >
> > +struct actlr_config;
> > +
> >  struct qcom_smmu_match_data {
> > +       const struct actlr_config *actlrcfg;
> > +       const struct actlr_config *actlrcfg_gfx;
> >         const struct qcom_smmu_config *cfg;
> >         const struct arm_smmu_impl *impl;
> >         const struct arm_smmu_impl *adreno_impl;
> > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > index d6d1a2a55cc0..0c7f700b27dd 100644
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > @@ -990,9 +990,10 @@ static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
> >                  * expect simply identical entries for this case, but there's
> >                  * no harm in accommodating the generalisation.
> >                  */
> > -               if ((mask & smrs[i].mask) == mask &&
> > -                   !((id ^ smrs[i].id) & ~smrs[i].mask))
> > +
> > +               if (smr_is_subset(&smrs[i], id, mask))
> >                         return i;
> > +
> >                 /*
> >                  * If the new entry has any other overlap with an existing one,
> >                  * though, then there always exists at least one stream ID
> > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> > index 703fd5817ec1..2e4f65412c6b 100644
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> > @@ -501,6 +501,11 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
> >                 writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);
> >  }
> >
> > +static inline bool smr_is_subset(struct arm_smmu_smr *smrs, u16 id, u16 mask)
> > +{
> > +       return (mask & smrs->mask) == mask && !((id ^ smrs->id) & ~smrs->mask);
> > +}
> > +
> >  #define ARM_SMMU_GR0           0
> >  #define ARM_SMMU_GR1           1
> >  #define ARM_SMMU_CB(s, n)      ((s)->numpage + (n))
> > --
> > 2.17.1
> >
>
>
> --
> With best wishes
> Dmitry



-- 
With best wishes
Dmitry


From broonie at kernel.org  Wed Dec 20 17:06:28 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 21 Dec 2023 01:06:28 +0000
Subject: selftests: ftrace: Internal error: Oops: sve_save_state
In-Reply-To: <CAEUSe7_9tE5K7NpsmaG_v_bTJaMGhVVSDRhMn1QYnr2z4vSg8w@mail.gmail.com>
References: <CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com>
 <ad5b7442-385d-41db-9202-a36414460610@sirena.org.uk>
 <CA+G9fYsbwWpDVR9KJXx8UO5MXsYT81uAJbLLNDnLianr8jmXUA@mail.gmail.com>
 <63e92a6a-9cb7-4272-b524-ccaf997aceb3@sirena.org.uk>
 <CAEUSe7_9tE5K7NpsmaG_v_bTJaMGhVVSDRhMn1QYnr2z4vSg8w@mail.gmail.com>
Message-ID: <b1b8cbdd-6d6c-4656-b17a-4d2dfb555f8a@sirena.org.uk>

On Wed, Dec 20, 2023 at 06:06:53PM -0600, Daniel D?az wrote:

> We have been seeing this problem in other instances, specifically on
> the following kernels:
> * 5.15.132, 5.15.134-rc1, 5.15.135, 5.15.136-rc1, 5.15.142, 5.15.145-rc1
> * 6.1.42, 6.1.43, 6.1.51-rc1, 6.1.56-rc1, 6.1.59-rc1, 6.1.63
> * 6.3.10, 6.3.11
> * 6.4.7
> * 6.5.2, 6.5.10-rc2

This is a huge range of kernels with some substantial reworkings of
the FP code, and I do note that v5.15 appears to have backported only
one change there (an incidental one related to ESR handling).  This
makes me think this is likely to be something that's been sitting there
for a very long time and is unrelated to those versions and any changes
that went into them.  I see you're still testing back to v4.19 which
suggests an issue introduced between v5.10 and v5.15, my change
cccb78ce89c45a4 ("arm64/sve: Rework SVE access trap to convert state in
registers") does jump out there though I don't immediately see what the
issue would be.

Looking at the list of versions you've posted the earliest is from the
very end of June with others in July, was there something that changed
in your test environment in broadly that time?  I see that the 
logs you and Naresh posted are both using a Debian 12/Bookworm based
root filesystem and that was released a couple of weeks before this
started appearing, Bookworm introduced glibc usage of SVE which makes
usage much more common.  Is this perhaps tied to you upgrading your root
filesystems to Bookworm or were you tracking testing before then?

> Most recent case is for the current 5.15 RC. Decoded stack trace is here:
> -----8<-----
>   <4>[   29.297166] ------------[ cut here ]------------
>   <4>[ 29.298039] WARNING: CPU: 1 PID: 220 at
> arch/arm64/kernel/fpsimd.c:950 do_sve_acc
> (/builds/linux/arch/arm64/kernel/fpsimd.c:950 (discriminator 1))

That's an assert that we shouldn't take a SVE trap when SVE is
alreadly enabled for the thread.  The backtrace Naresh originally
supplied was a NULL pointer dereference attempting to save SVE state 
(indicating that we think we're trying to save SVE state but don't have
any storage allocated for it) during thread switch.  It's very plausible
that the two are the same underlying issue but it's also not 100% a
given.  Can you double check exactly how similar the various issues you
are seeing are please?

I have coincidentally been chasing some other stuff in the past week or
two which might potentially be different manifestations of the same
underlying issue with current code, broadly in the area of the register
state and task state getting out of sync.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231221/8d062346/attachment.sig>

From andy.yan at rock-chips.com  Wed Dec 20 17:07:13 2023
From: andy.yan at rock-chips.com (Andy Yan)
Date: Thu, 21 Dec 2023 09:07:13 +0800
Subject: [PATCH v2 1/3] ARM: dts: rockchip: Add psci for rk3036
In-Reply-To: <da10e2fc-3179-4bd5-88ed-b4d5f64a7191@gmail.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
 <20231218105523.2478315-2-andyshrk@163.com>
 <da10e2fc-3179-4bd5-88ed-b4d5f64a7191@gmail.com>
Message-ID: <28216be5-810f-40d6-850b-a0fc590ffa3c@rock-chips.com>

Hi Alex:

On 12/20/23 19:16, Alex Bee wrote:
> Hi Andy,
> Am 18.12.23 um 11:55 schrieb Andy Yan:
>> From: Andy Yan <andy.yan at rock-chips.com>
>>
>> The system will hang at bringup secondary CPUs
>> without psci node.
>>
>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>>
>> ---
>>
>> (no changes since v1)
>>
>> ? arch/arm/boot/dts/rockchip/rk3036.dtsi | 5 +++++
>> ? 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> index 78686fc72ce6..5344803442a1 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> @@ -67,6 +67,11 @@ display-subsystem {
>> ????????? ports = <&vop_out>;
>> ????? };
>> +??? psci {
>> +??????? compatible = "arm,psci-1.0";
>> +??????? method = "smc";
>> +??? };
>> +
> I don't think that's an good idea. 

Why?

>You most likely need that because you have downstream bootloader installed on this board. PSCI implementation takes place in TEE-OS for Rockchips ARM SoCs. There is no support for RK3036 in upstream op-tee OS. It's pretty much the same for RK3128 and RK3288.
> If you use upstream u-boot it should be good as-is.

Unfortunately, upstream u-boot also cannot boot up on this board.
At present, I haven't had time to debug what is going on.

Another reason I want to use downstream u-boot it is: I try run
this board with mainline just because i want to test some community
patches about inno-hdmi driver, as you said "the inno-hdmi driver currently gets a lot of attention"[0]

With a downstream u-boot I can easy switch between upstream kernel and downstream kernel(no need to replace other components)
if I found some function is not work as expected.


[0]https://patchwork.kernel.org/project/linux-rockchip/cover/20231219170100.188800-1-knaerzche at gmail.com/
> 
> Alex
>> ????? timer {
>> ????????? compatible = "arm,armv7-timer";
>> ????????? arm,cpu-registers-not-fw-configured;
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


From peng.fan at nxp.com  Wed Dec 20 17:31:27 2023
From: peng.fan at nxp.com (Peng Fan)
Date: Thu, 21 Dec 2023 01:31:27 +0000
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <20231220123745.ksdumfymu4xruufa@pengutronix.de>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
 <20231219192912.yulmczvqbuh4jizg@pengutronix.de>
 <DU0PR04MB94170BCA413C2FD48A397B538896A@DU0PR04MB9417.eurprd04.prod.outlook.com>
 <20231220123033.nrbperhbr4jifuvh@pengutronix.de>
 <DU0PR04MB9417E926CBD95BD7298B64D28896A@DU0PR04MB9417.eurprd04.prod.outlook.com>
 <20231220123745.ksdumfymu4xruufa@pengutronix.de>
Message-ID: <DU0PR04MB941736A1EEE3A98F188A59488895A@DU0PR04MB9417.eurprd04.prod.outlook.com>

> Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
> protocol
> 
> On 23-12-20, Peng Fan wrote:
> > > Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support
> > > pinctrl protocol
> > >
> > > On 23-12-20, Peng Fan wrote:
> > > > > Subject: Re: [PATCH 4/7] dt-bindings: firmware: arm,scmi:
> > > > > support pinctrl protocol
> > > > >
> > > > > Hi Peng,
> > > > >
> > > > > On 23-12-15, Peng Fan (OSS) wrote:
> > > > > > From: Peng Fan <peng.fan at nxp.com>
> > > > > >
> > > > > > Add SCMI v3.2 pinctrl protocol bindings and example.
> > > > > >
> > > > > > Signed-off-by: Peng Fan <peng.fan at nxp.com>
> > > > > > ---
> > > > > >  .../devicetree/bindings/firmware/arm,scmi.yaml     | 99
> > > > > ++++++++++++++++++++++
> > > > > >  1 file changed, 99 insertions(+)
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > > > b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > > > index 4591523b51a0..bfd2b6a89979 100644
> > > > > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > > > > > @@ -247,6 +247,85 @@ properties:
> > > > > >        reg:
> > > > > >          const: 0x18
> > > > > >
> > > > > > +  protocol at 19:
> > > > >
> > > > > ...
> > > > >
> > > > > > @@ -401,6 +480,26 @@ examples:
> > > > > >              scmi_powercap: protocol at 18 {
> > > > > >                  reg = <0x18>;
> > > > > >              };
> > > > > > +
> > > > > > +            scmi_pinctrl: protocol at 19 {
> > > > > > +                reg = <0x19>;
> > > > > > +                #pinctrl-cells = <0>;
> > > > > > +
> > > > > > +                i2c2-pins {
> > > > > > +                    groups = "i2c2_a", "i2c2_b";
> > > > > > +                    function = "i2c2";
> > > > > > +                };
> > > > > > +
> > > > > > +                mdio-pins {
> > > > > > +                    groups = "avb_mdio";
> > > > > > +                    drive-strength = <24>;
> > > > > > +                };
> > > > > > +
> > > > > > +                keys_pins: keys-pins {
> > > > > > +                    pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
> > > > > > +                    bias-pull-up;
> > > > > > +                };
> > > > > > +            };
> > > > >
> > > > > This example is different to the one you mentioned within the
> > > > > cover-letter. I didn't checked all patches just want to ask
> > > > > which API will be implemented by this patchset?
> > > >
> > > > I kept this change since it was tested by Oleksii, but anyway i.MX
> > > > not use
> > > these.
> > > >
> > > > The API, I suppose you are asking about this?
> > > > static const struct pinctrl_ops pinctrl_scmi_pinctrl_ops = {
> > > >         .get_groups_count = pinctrl_scmi_get_groups_count,
> > > >         .get_group_name = pinctrl_scmi_get_group_name,
> > > >         .get_group_pins = pinctrl_scmi_get_group_pins, #ifdef
> > > > CONFIG_OF
> > > >         .dt_node_to_map = pinconf_generic_dt_node_to_map_all,
> > > >         .dt_free_map = pinconf_generic_dt_free_map, #endif };
> > > >
> > > > static const struct pinctrl_ops pinctrl_scmi_imx_pinctrl_ops = {
> > > >         .get_groups_count = pinctrl_scmi_get_groups_count,
> > > >         .get_group_name = pinctrl_scmi_get_group_name,
> > > >         .get_group_pins = pinctrl_scmi_get_group_pins, #ifdef
> > > > CONFIG_OF
> > > >         .dt_node_to_map = pinctrl_scmi_imx_dt_node_to_map,
> > > >         .dt_free_map = pinconf_generic_dt_free_map, #endif };
> > >
> > > I see, thanks for the clarification. In short: the i.MX SMCI pinctrl
> > > DT-API is the same as the non-SCMI pinctrl API since the dt_node_to_map
> will convert it.
> >
> > Yes, the fsl,pins format is same whether SCMI or non-SCMI. But we need
> > to pack the data to a format that matches the i.MX OEM SCMI PINCTRL
> > protocol, so we need to dedicated dt_node_to_map here.
> 
> Yes, I saw that you're using the enum values 192-255 for the OEM specific
> part and the packing. Does you have public access to the FW implementing
> the SCMI?
> 
The system manager firmware:
https://github.com/nxp-imx/imx-sm

Regards,
Peng.

> Regards,
>   Marco
> 
> >
> > Thanks,
> > Peng.
> >
> > >
> > > Regards,
> > >   Marco
> >
> >


From peng.fan at nxp.com  Wed Dec 20 18:05:08 2023
From: peng.fan at nxp.com (Peng Fan)
Date: Thu, 21 Dec 2023 02:05:08 +0000
Subject: [PATCH] clk: imx: pll14xx: change naming of fvco to fout
In-Reply-To: <1703068389-6130-1-git-send-email-shengjiu.wang@nxp.com>
References: <1703068389-6130-1-git-send-email-shengjiu.wang@nxp.com>
Message-ID: <DU0PR04MB94174727ED9DA25B57FB5EA88895A@DU0PR04MB9417.eurprd04.prod.outlook.com>

> Subject: [PATCH] clk: imx: pll14xx: change naming of fvco to fout
> 
> pll14xx_calc_rate() output the fout clock not the fvco clock The relation of
> fvco and fout is:
> 	fout = fvco / (1 << sdiv)
> 
> So use correct naming for the clock.
> 
> Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>

Reviewed-by: Peng Fan <peng.fan at nxp.com>


From fuyao at sjterm.com  Wed Dec 20 18:20:49 2023
From: fuyao at sjterm.com (fuyao)
Date: Thu, 21 Dec 2023 10:20:49 +0800
Subject: [PATCH RESEND] ARM: dts: sun8i: r40: open the regulator aldo1
In-Reply-To: <20231220150400.0f32e2a5@donnerap.manchester.arm.com>
References: <ZYKjYypuAx7gNuam@debian.cyg>
 <20231220150400.0f32e2a5@donnerap.manchester.arm.com>
Message-ID: <ZYOhAQi7XeLUuAC9@debian.cyg>

On Wed, Dec 20, 2023 at 03:04:00PM +0000, Andre Przywara wrote:
> On Wed, 20 Dec 2023 16:18:43 +0800
> fuyao <fuyao1697 at cyg.com> wrote:
> 
> Hi,
> 
> > the aldo1 is connect regulator pin which power the TV.
> 
> What do you mean with that? That ALDO1 is connected to VCC-TVOUT and/or
> VCC-TVIN on the R40 SoC?

The ALDO1 is connected to VCC-TVOUT on the R40 Soc.

> 
> > The USB core use TV ref as reference Voltage.
> 
> The USB core in the SoC? So pin VCC-USB, which requires 3.3V, the same
> voltage as the TV pins?
> Which means this doesn't really have much to do with TV, it's just that
> USB and also "TV" are supplied by ALDO1?

The internal USB PHY requires a reference voltage. It seems that in
order to save costs, the reference voltage of the TVOUT module is used.

> 
> > Signed-off-by: fuyao <fuyao1697 at cyg.com>
> > ---
> >  arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > index 9f39b5a2bb35..8906170461df 100644
> > --- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > +++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > @@ -42,6 +42,13 @@ &pio {
> >  	vcc-pg-supply = <&reg_dldo1>;
> >  };
> >  
> > +&reg_aldo1 {
> > +	regulator-always-on;
> 
> So did USB never work before, with the DT as in mainline?
> 

The USB can work, but is unstable. Occasionally disconnected because of
the D+/D- electrical characteristics.

> For always-on regulators it would be good to see some rationale why this
> cannot be referenced by its consumer. If it is really supplying the USB
> core, that would be a reason, because we don't have a good way of
> describing this.
> 
> > +	regulator-min-microvolt = <3300000>;
> > +	regulator-max-microvolt = <3300000>;
> > +	regulator-name = "vcc-aldo1";
> 
> Regulators should be named after their users, so use something like:
> 	regulator-name = "vcc-3v3-tv-usb";
> 

thanks.

> That then also serves as documentation of why this is always on.
> 
> Cheers,
> Andre
> 
> > +};
> > +
> >  &reg_aldo2 {
> >  	regulator-always-on;
> >  	regulator-min-microvolt = <1800000>;
> 



From xiaobo55x at gmail.com  Wed Dec 20 18:58:40 2023
From: xiaobo55x at gmail.com (Haibo Xu)
Date: Thu, 21 Dec 2023 10:58:40 +0800
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us
 in arch timer test
In-Reply-To: <87zfy5t1qt.wl-maz@kernel.org>
References: <cover.1702371136.git.haibo1.xu@intel.com> <0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
 <8734vy832j.wl-maz@kernel.org> <CAJve8onc0WN5g98aOVBmJx15wFBAqfBKJ+ufoLY+oqYyVL+=3A@mail.gmail.com>
 <f98879dc24f948f7a8a7b5374a32bc04@kernel.org> <CAJve8ona7g=LxW1YeRB_FqGodF973H=A3b2m8054gmzK=Z7_ww@mail.gmail.com>
 <87zfy5t1qt.wl-maz@kernel.org>
Message-ID: <CAJve8o=nTsAwwgSib4vOLXjOWSMV2+J+BFsUZ57OdAK7eW8q8A@mail.gmail.com>

On Wed, Dec 20, 2023 at 9:58?PM Marc Zyngier <maz at kernel.org> wrote:
>
> On Wed, 20 Dec 2023 13:51:24 +0000,
> Haibo Xu <xiaobo55x at gmail.com> wrote:
> >
> > On Wed, Dec 20, 2023 at 5:00?PM Marc Zyngier <maz at kernel.org> wrote:
> > >
> > > On 2023-12-20 06:50, Haibo Xu wrote:
> > > > On Wed, Dec 20, 2023 at 2:22?AM Marc Zyngier <maz at kernel.org> wrote:
> > > >>
> > > >> On Tue, 12 Dec 2023 09:31:20 +0000,
> > > >> Haibo Xu <haibo1.xu at intel.com> wrote:
> > > >> > diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
> > > >> > index 968257b893a7..b1d405e7157d 100644
> > > >> > --- a/tools/testing/selftests/kvm/include/timer_test.h
> > > >> > +++ b/tools/testing/selftests/kvm/include/timer_test.h
> > > >> > @@ -22,6 +22,7 @@ struct test_args {
> > > >> >       int nr_iter;
> > > >> >       int timer_period_ms;
> > > >> >       int migration_freq_ms;
> > > >> > +     int timer_err_margin_us;
> > > >>
> > > >> ... except that you are storing it as a signed value. Some consistency
> > > >> wouldn't hurt, really, and would avoid issues when passing large
> > > >> values.
> > > >>
> > > >
> > > > Yes, it's more proper to use an unsigned int for the non-negative error
> > > > margin.
> > > > Storing as signed here is just to keep the type consistent with that
> > > > of timer_period_ms
> > > > since there will be '+' operation in other places.
> > > >
> > > >         tools/testing/selftests/kvm/aarch64/arch_timer.c
> > > >         /* Setup a timeout for the interrupt to arrive */
> > > >          udelay(msecs_to_usecs(test_args.timer_period_ms) +
> > > >              test_args.timer_err_margin_us);
> > >
> > > But that's exactly why using a signed quantity is wrong.
> > > What does it mean to have a huge *negative* margin?
> > >
> >
> > Hi Marc,
> >
> > I agree that negative values are meaningless for the margin.
> > If I understand correctly, the negative margin should be filtered by
> > assertion in atoi_non_negative().
>
> No. Please.
>
> atoi_non_negative() returns a uint32_t, which is what it should do.
> The bug is squarely in the use of an 'int' to store such value, and it
> is the *storage* that turns a positive value into a negative one.
>

Thanks for the detailed info!

May I understand that your concern is mainly for a platform with 64bit int type,
which may trigger the positive to negative convert?

If so, I think we may need to do a clean up for the test code since
several other
places have the same issue.

Regards,
Haibo

>         M.
>
> --
> Without deviation from the norm, progress is not possible.


From chui-hao.chiu at mediatek.com  Wed Dec 20 19:26:48 2023
From: chui-hao.chiu at mediatek.com (Peter Chiu)
Date: Thu, 21 Dec 2023 11:26:48 +0800
Subject: [PATCH v4] dt-bindings: net: wireless: mt76: add interrupts description for MT7986
Message-ID: <20231221032648.641-1-chui-hao.chiu@mediatek.com>

The mt7986 can support four interrupts to distribute the interrupts
to different CPUs.

Signed-off-by: Peter Chiu <chui-hao.chiu at mediatek.com>
---
v2: Change to use description instead of using items.
v3: Change to use items and set different minItems for mediatek,mt7986-wmac
v4: Move allOf after required and remove duplicated blank line.
---
 .../bindings/net/wireless/mediatek,mt76.yaml  | 32 ++++++++++++++++---
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
index 252207adbc54..0c6835db397f 100644
--- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
@@ -19,9 +19,6 @@ description: |
   Alternatively, it can specify the wireless part of the MT7628/MT7688
   or MT7622/MT7986 SoC.
 
-allOf:
-  - $ref: ieee80211.yaml#
-
 properties:
   compatible:
     enum:
@@ -38,7 +35,12 @@ properties:
       MT7986 should contain 3 regions consys, dcm, and sku, in this order.
 
   interrupts:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: major interrupt for rings
+      - description: additional interrupt for ring 19
+      - description: additional interrupt for ring 4
+      - description: additional interrupt for ring 5
 
   power-domains:
     maxItems: 1
@@ -217,6 +219,23 @@ required:
   - compatible
   - reg
 
+allOf:
+  - $ref: ieee80211.yaml#
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - mediatek,mt7986-wmac
+    then:
+      properties:
+        interrupts:
+          minItems: 4
+    else:
+      properties:
+        interrupts:
+          maxItems: 1
+
 unevaluatedProperties: false
 
 examples:
@@ -293,7 +312,10 @@ examples:
         reg = <0x18000000 0x1000000>,
               <0x10003000 0x1000>,
               <0x11d10000 0x1000>;
-        interrupts = <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>;
+        interrupts = <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>,
+                     <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>;
         clocks = <&topckgen 50>,
                  <&topckgen 62>;
         clock-names = "mcu", "ap2conn";
-- 
2.18.0



From quic_bjorande at quicinc.com  Wed Dec 20 19:50:37 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 20 Dec 2023 19:50:37 -0800
Subject: [PATCH 3/8] clk: qcom: gpucc-sc8280xp: Add external supply for GX
 gdsc
In-Reply-To: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v1-3-d8cdf2257f97@quicinc.com>

On SA8295P and SA8540P the GFX rail is powered by a dedicated external
regulator, instead of the rpmh-controlled "gfx.lvl".

Define the "vdd-gfx" as the supply regulator for the GDSC, to cause the
gdsc logic to look for, and control, this external power supply.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 drivers/clk/qcom/gpucc-sc8280xp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/gpucc-sc8280xp.c b/drivers/clk/qcom/gpucc-sc8280xp.c
index 8e147ee294ee..e2b3bc000c71 100644
--- a/drivers/clk/qcom/gpucc-sc8280xp.c
+++ b/drivers/clk/qcom/gpucc-sc8280xp.c
@@ -399,6 +399,7 @@ static struct gdsc gx_gdsc = {
 	},
 	.pwrsts = PWRSTS_OFF_ON,
 	.flags = CLAMP_IO | RETAIN_FF_ENABLE,
+	.supply = "vdd-gfx",
 };
 
 static struct gdsc *gpu_cc_sc8280xp_gdscs[] = {

-- 
2.25.1



From quic_bjorande at quicinc.com  Wed Dec 20 19:50:35 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 20 Dec 2023 19:50:35 -0800
Subject: [PATCH 1/8] dt-bindings: clock: qcom: Allow VDD_GFX supply to GX
In-Reply-To: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v1-1-d8cdf2257f97@quicinc.com>

In some designs the SoC's VDD_GFX pads are supplied by an external
regulator, rather than a power-domain. Allow this to be described in the
GPU clock controller binding.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index f369fa34e00c..013ef78d2b31 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -53,6 +53,9 @@ properties:
   power-domains:
     maxItems: 1
 
+  vdd-gfx-supply:
+    description: Regulator supply for the VDD_GFX pads
+
   '#clock-cells':
     const: 1
 

-- 
2.25.1



From quic_bjorande at quicinc.com  Wed Dec 20 19:50:38 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 20 Dec 2023 19:50:38 -0800
Subject: [PATCH 4/8] soc: qcom: rpmhpd: Drop SA8540P gfx.lvl
In-Reply-To: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v1-4-d8cdf2257f97@quicinc.com>

On SA8295P and SA8540P gfx.lvl is not provdied by rpmh, but rather is
handled by an external regulator (max20411). Drop gfx.lvl from the list
of power-domains exposed on this platform.

Fixes: f68f1cb3437d ("soc: qcom: rpmhpd: add sc8280xp & sa8540p rpmh power-domains")
Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 drivers/pmdomain/qcom/rpmhpd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
index 3078896b1300..27a73ff72614 100644
--- a/drivers/pmdomain/qcom/rpmhpd.c
+++ b/drivers/pmdomain/qcom/rpmhpd.c
@@ -217,7 +217,6 @@ static struct rpmhpd *sa8540p_rpmhpds[] = {
 	[SC8280XP_CX] = &cx,
 	[SC8280XP_CX_AO] = &cx_ao,
 	[SC8280XP_EBI] = &ebi,
-	[SC8280XP_GFX] = &gfx,
 	[SC8280XP_LCX] = &lcx,
 	[SC8280XP_LMX] = &lmx,
 	[SC8280XP_MMCX] = &mmcx,

-- 
2.25.1



From quic_bjorande at quicinc.com  Wed Dec 20 19:50:39 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 20 Dec 2023 19:50:39 -0800
Subject: [PATCH 5/8] arm64: dts: qcom: sa8540p: Drop gfx.lvl as
 power-domain for gpucc
In-Reply-To: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v1-5-d8cdf2257f97@quicinc.com>

The SA8295P and SA8540P uses an external regulator (max20411), and
gfx.lvl is not provided by rpmh. Drop the power-domains property of the
gpucc node to reflect this.

Fixes: eec51ab2fd6f ("arm64: dts: qcom: sc8280xp: Add GPU related nodes")
Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 arch/arm64/boot/dts/qcom/sa8540p.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8540p.dtsi b/arch/arm64/boot/dts/qcom/sa8540p.dtsi
index 96b2c59ad02b..b604404ebf64 100644
--- a/arch/arm64/boot/dts/qcom/sa8540p.dtsi
+++ b/arch/arm64/boot/dts/qcom/sa8540p.dtsi
@@ -168,6 +168,8 @@ opp-2592000000 {
 };
 
 &gpucc {
+	/delete-property/ power-domains;
+
 	status = "disabled";
 };
 

-- 
2.25.1



From quic_bjorande at quicinc.com  Wed Dec 20 19:50:41 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 20 Dec 2023 19:50:41 -0800
Subject: [PATCH 7/8] arm64: dts: qcom: sa8295p-adp: Enable GPU
In-Reply-To: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v1-7-d8cdf2257f97@quicinc.com>

With the necessary support in place for supplying VDD_GFX from the
MAX20411 regulator, enable the GPU clock controller, GMU, Adreno SMMU
and the GPU on the SA8295P ADP.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
index e16406c9c19d..7775c5f4d2e8 100644
--- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
@@ -108,6 +108,13 @@ edp3_connector_in: endpoint {
 			};
 		};
 	};
+
+	reserved-memory {
+		gpu_mem: gpu-mem at 8bf00000 {
+			reg = <0 0x8bf00000 0 0x2000>;
+			no-map;
+		};
+	};
 };
 
 &apps_rsc {
@@ -286,6 +293,28 @@ vdd_gfx: regulator at 39 {
 	};
 };
 
+&gpucc {
+	vdd-gfx-supply = <&vdd_gfx>;
+	status = "okay";
+};
+
+&gmu {
+	status = "okay";
+};
+
+&gpu {
+	status = "okay";
+
+	zap-shader {
+		memory-region = <&gpu_mem>;
+		firmware-name = "qcom/sa8295p/a690_zap.mdt";
+	};
+};
+
+&gpu_smmu {
+	status = "okay";
+};
+
 &mdss0 {
 	status = "okay";
 };

-- 
2.25.1



From quic_bjorande at quicinc.com  Wed Dec 20 19:50:34 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 20 Dec 2023 19:50:34 -0800
Subject: [PATCH 0/8] arm64: dts: qcom: sa8295p: Enable GPU
Message-ID: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>

Due to the different PMIC configuration found in the SA8295P platform,
compared to SC8280XP, the VDD_GFX pads are supplied by an dedicated
MAX20411 LDO.

Support for expressing the regulator supply is added to the binding, the
support for enabling the parent supply for GX is added, the missing
gfx.lvl power-domain is dropped, and the DeviceTree is wired up to
enable the GPU in this configuration.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
Bjorn Andersson (8):
      dt-bindings: clock: qcom: Allow VDD_GFX supply to GX
      clk: qcom: gdsc: Enable supply reglator in GPU GX handler
      clk: qcom: gpucc-sc8280xp: Add external supply for GX gdsc
      soc: qcom: rpmhpd: Drop SA8540P gfx.lvl
      arm64: dts: qcom: sa8540p: Drop gfx.lvl as power-domain for gpucc
      arm64: dts: qcom: sa8295p-adp: add max20411
      arm64: dts: qcom: sa8295p-adp: Enable GPU
      arm64: defconfig: Enable MAX20411 regulator driver

 .../devicetree/bindings/clock/qcom,gpucc.yaml      |  3 +
 arch/arm64/boot/dts/qcom/sa8295p-adp.dts           | 69 ++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sa8540p.dtsi              |  2 +
 arch/arm64/configs/defconfig                       |  1 +
 drivers/clk/qcom/gdsc.c                            |  8 ++-
 drivers/clk/qcom/gpucc-sc8280xp.c                  |  1 +
 drivers/pmdomain/qcom/rpmhpd.c                     |  1 -
 7 files changed, 83 insertions(+), 2 deletions(-)
---
base-commit: 20d857259d7d10cd0d5e8b60608455986167cfad
change-id: 20231220-sa8295p-gpu-51c5f343e3ec

Best regards,
-- 
Bjorn Andersson <quic_bjorande at quicinc.com>



From quic_bjorande at quicinc.com  Wed Dec 20 19:50:36 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 20 Dec 2023 19:50:36 -0800
Subject: [PATCH 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX
 handler
In-Reply-To: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v1-2-d8cdf2257f97@quicinc.com>

The GX GDSC is modelled to aid the GMU in powering down the GPU in the
event that the GPU crashes, so that it can be restarted again. But in
the event that the power-domain is supplied through a dedicated
regulator (in contrast to being a subdomin of another power-domain),
something needs to turn that regulator on, both to make sure things are
powered and to match the operation in gdsc_disable().

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 drivers/clk/qcom/gdsc.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index 5358e28122ab..d1139c895503 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -557,7 +557,13 @@ void gdsc_unregister(struct gdsc_desc *desc)
  */
 int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
 {
+	struct gdsc *sc = domain_to_gdsc(domain);
+	int ret = 0;
+
 	/* Do nothing but give genpd the impression that we were successful */
-	return 0;
+	if (sc->rsupply)
+		ret = regulator_enable(sc->rsupply);
+
+	return ret;
 }
 EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);

-- 
2.25.1



From quic_bjorande at quicinc.com  Wed Dec 20 19:50:40 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 20 Dec 2023 19:50:40 -0800
Subject: [PATCH 6/8] arm64: dts: qcom: sa8295p-adp: add max20411
In-Reply-To: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v1-6-d8cdf2257f97@quicinc.com>

From: Bjorn Andersson <andersson at kernel.org>

The SA8295P ADP has a MAX20411 LDO regulator on I2C 12, supplying the
VDD_GFX pads. Enable the bus and add the maxim,max20411 device on the
bus.

Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
---
 arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 40 ++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
index fd253942e5e5..e16406c9c19d 100644
--- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
@@ -266,6 +266,26 @@ &dispcc1 {
 	status = "okay";
 };
 
+&i2c12 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&qup1_i2c4_state>;
+
+	status = "okay";
+
+	vdd_gfx: regulator at 39 {
+		compatible = "maxim,max20411";
+		reg = <0x39>;
+
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <968750>;
+
+		enable-gpios = <&pmm8540a_gpios 2 GPIO_ACTIVE_HIGH>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&max20411_en>;
+	};
+};
+
 &mdss0 {
 	status = "okay";
 };
@@ -476,6 +496,10 @@ &pcie4_phy {
 	status = "okay";
 };
 
+&qup1 {
+	status = "okay";
+};
+
 &qup2 {
 	status = "okay";
 };
@@ -728,4 +752,20 @@ wake-n-pins {
 			bias-pull-up;
 		};
 	};
+
+	qup1_i2c4_state: qup1-i2c4-state {
+		pins = "gpio0", "gpio1";
+		function = "qup12";
+
+		drive-strength = <2>;
+		bias-pull-up;
+	};
+};
+
+&pmm8540a_gpios {
+	max20411_en: max20411-en-state {
+		pins = "gpio2";
+		function = "normal";
+		output-enable;
+	};
 };

-- 
2.25.1



From quic_bjorande at quicinc.com  Wed Dec 20 19:50:42 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 20 Dec 2023 19:50:42 -0800
Subject: [PATCH 8/8] arm64: defconfig: Enable MAX20411 regulator driver
In-Reply-To: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v1-8-d8cdf2257f97@quicinc.com>

The Qualcomm SA8295P ADP board uses a max20411 to power the GPU
subsystem.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ef1061089548..ec94a0c4fd03 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -751,6 +751,7 @@ CONFIG_REGULATOR_HI6421V530=y
 CONFIG_REGULATOR_HI655X=y
 CONFIG_REGULATOR_MAX77620=y
 CONFIG_REGULATOR_MAX8973=y
+CONFIG_REGULATOR_MAX20411=m
 CONFIG_REGULATOR_MP8859=y
 CONFIG_REGULATOR_MT6315=m
 CONFIG_REGULATOR_MT6357=y

-- 
2.25.1



From sboyd at kernel.org  Wed Dec 20 20:36:23 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 20 Dec 2023 20:36:23 -0800
Subject: [PATCH 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX handler
In-Reply-To: <20231220-sa8295p-gpu-v1-2-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com> <20231220-sa8295p-gpu-v1-2-d8cdf2257f97@quicinc.com>
Message-ID: <d0fe9a3302f8c367a26dd5b4b1b29c68.sboyd@kernel.org>

Quoting Bjorn Andersson (2023-12-20 19:50:36)
> The GX GDSC is modelled to aid the GMU in powering down the GPU in the
> event that the GPU crashes, so that it can be restarted again. But in
> the event that the power-domain is supplied through a dedicated
> regulator (in contrast to being a subdomin of another power-domain),
> something needs to turn that regulator on, both to make sure things are
> powered and to match the operation in gdsc_disable().
> 
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>  drivers/clk/qcom/gdsc.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> index 5358e28122ab..d1139c895503 100644
> --- a/drivers/clk/qcom/gdsc.c
> +++ b/drivers/clk/qcom/gdsc.c
> @@ -557,7 +557,13 @@ void gdsc_unregister(struct gdsc_desc *desc)
>   */
>  int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
>  {
> +       struct gdsc *sc = domain_to_gdsc(domain);
> +       int ret = 0;
> +
>         /* Do nothing but give genpd the impression that we were successful */

Update this comment.

> -       return 0;
> +       if (sc->rsupply)
> +               ret = regulator_enable(sc->rsupply);
> +
> +       return ret;
>  }


From shengjiu.wang at nxp.com  Wed Dec 20 21:23:07 2023
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Thu, 21 Dec 2023 13:23:07 +0800
Subject: [PATCH 1/2] arm64: dts: imx8mm-evk: Add PDM micphone sound card support
Message-ID: <1703136188-7222-1-git-send-email-shengjiu.wang@nxp.com>

Add PDM micphone sound card support, configure the pinmux.

This sound card supports recording sound from PDM micphone
and convert the PDM format data to PCM data.

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index b53104ed8919..9679786dac51 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -151,6 +151,18 @@ simple-audio-card,codec {
 			clocks = <&clk IMX8MM_CLK_SAI3_ROOT>;
 		};
 	};
+
+	sound-micfil {
+		compatible = "fsl,imx-audio-card";
+		model = "micfil-audio";
+		pri-dai-link {
+			link-name = "micfil hifi";
+			format = "i2s";
+			cpu {
+				sound-dai = <&micfil>;
+			};
+		};
+	};
 };
 
 &A53_0 {
@@ -434,6 +446,16 @@ &lcdif {
 	status = "okay";
 };
 
+&micfil {
+	#sound-dai-cells = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pdm>;
+	assigned-clocks = <&clk IMX8MM_CLK_PDM>;
+	assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
+	assigned-clock-rates = <196608000>;
+	status = "okay";
+};
+
 &mipi_csi {
 	status = "okay";
 
@@ -636,6 +658,18 @@ MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5       0x41
 		>;
 	};
 
+	pinctrl_pdm: pdmgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_MCLK_SAI5_MCLK        0xd6
+			MX8MM_IOMUXC_SAI5_RXC_PDM_CLK           0xd6
+			MX8MM_IOMUXC_SAI5_RXFS_SAI5_RX_SYNC     0xd6
+			MX8MM_IOMUXC_SAI5_RXD0_PDM_DATA0        0xd6
+			MX8MM_IOMUXC_SAI5_RXD1_PDM_DATA1        0xd6
+			MX8MM_IOMUXC_SAI5_RXD2_PDM_DATA2        0xd6
+			MX8MM_IOMUXC_SAI5_RXD3_PDM_DATA3        0xd6
+		>;
+	};
+
 	pinctrl_pmic: pmicirqgrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x141
-- 
2.34.1



From shengjiu.wang at nxp.com  Wed Dec 20 21:23:08 2023
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Thu, 21 Dec 2023 13:23:08 +0800
Subject: [PATCH 2/2] arm64: dts: imx8mn-evk: Add PDM micphone sound card support
In-Reply-To: <1703136188-7222-1-git-send-email-shengjiu.wang@nxp.com>
References: <1703136188-7222-1-git-send-email-shengjiu.wang@nxp.com>
Message-ID: <1703136188-7222-2-git-send-email-shengjiu.wang@nxp.com>

Add PDM micphone sound card support, configure the pinmux.

This sound card supports recording sound from PDM micphone
and convert the PDM format data to PCM data.

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
index a0e13d3324ed..7d055b63535a 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
@@ -110,6 +110,18 @@ sound-spdif {
 		spdif-out;
 		spdif-in;
 	};
+
+	sound-micfil {
+		compatible = "fsl,imx-audio-card";
+		model = "micfil-audio";
+		pri-dai-link {
+			link-name = "micfil hifi";
+			format = "i2s";
+			cpu {
+				sound-dai = <&micfil>;
+			};
+		};
+	};
 };
 
 &easrc {
@@ -285,6 +297,16 @@ &isi {
 	status = "okay";
 };
 
+&micfil {
+	#sound-dai-cells = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pdm>;
+	assigned-clocks = <&clk IMX8MN_CLK_PDM>;
+	assigned-clock-parents = <&clk IMX8MN_AUDIO_PLL1_OUT>;
+	assigned-clock-rates = <196608000>;
+	status = "okay";
+};
+
 &mipi_csi {
 	status = "okay";
 
@@ -522,6 +544,18 @@ MX8MN_IOMUXC_I2C3_SDA_GPIO5_IO19	0x1c3
 		>;
 	};
 
+	pinctrl_pdm: pdmgrp {
+		fsl,pins = <
+			MX8MN_IOMUXC_SAI5_MCLK_SAI5_MCLK	0xd6
+			MX8MN_IOMUXC_SAI5_RXC_PDM_CLK		0xd6
+			MX8MN_IOMUXC_SAI5_RXFS_SAI5_RX_SYNC	0xd6
+			MX8MN_IOMUXC_SAI5_RXD0_PDM_BIT_STREAM0	0xd6
+			MX8MN_IOMUXC_SAI5_RXD1_PDM_BIT_STREAM1	0xd6
+			MX8MN_IOMUXC_SAI5_RXD2_PDM_BIT_STREAM2	0xd6
+			MX8MN_IOMUXC_SAI5_RXD3_PDM_BIT_STREAM3	0xd6
+		>;
+	};
+
 	pinctrl_pmic: pmicirqgrp {
 		fsl,pins = <
 			MX8MN_IOMUXC_GPIO1_IO03_GPIO1_IO3	0x141
-- 
2.34.1



From twoerner at gmail.com  Wed Dec 20 22:22:43 2023
From: twoerner at gmail.com (Trevor Woerner)
Date: Thu, 21 Dec 2023 01:22:43 -0500
Subject: [PATCH] arm64: rockchip: dts: rk3328-rock-pi-e: enable GbE eth
Message-ID: <20231221062244.11871-1-twoerner@gmail.com>

Adjust the device-tree to get the GbE interface working using a patch found
on the Radxa forum.

Link: https://forum.radxa.com/t/rock-pi-e-board-version-1-21-ethhernet-not-working-in-armbian/15061/3
Signed-off-by: Trevor Woerner <twoerner at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
index 3cda6c627b68..41224a222048 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -148,7 +148,7 @@ &gmac2io {
 	assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
 	assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
 	clock_in_out = "input";
-	phy-handle = <&rtl8211e>;
+	phy-handle = <&rtl8211f>;
 	phy-mode = "rgmii";
 	phy-supply = <&vcc_io>;
 	pinctrl-names = "default";
@@ -156,8 +156,8 @@ &gmac2io {
 	snps,aal;
 	snps,rxpbl = <0x4>;
 	snps,txpbl = <0x4>;
-	tx_delay = <0x26>;
-	rx_delay = <0x11>;
+	tx_delay = <0x1a>;
+	rx_delay = <0x14>;
 	status = "okay";
 
 	mdio {
@@ -165,15 +165,17 @@ mdio {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		rtl8211e: ethernet-phy at 1 {
+		rtl8211f: ethernet-phy at 1 {
+			compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22";
 			reg = <1>;
 			pinctrl-0 = <&eth_phy_int_pin>, <&eth_phy_reset_pin>;
 			pinctrl-names = "default";
 			interrupt-parent = <&gpio1>;
 			interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
-			reset-assert-us = <10000>;
-			reset-deassert-us = <50000>;
+			reset-assert-us = <20000>;
+			reset-deassert-us = <100000>;
 			reset-gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
+			max-speed = <1000>;
 		};
 	};
 };
-- 
2.43.0.76.g1a87c842ece3



From amit.kumar-mahapatra at amd.com  Wed Dec 20 22:54:22 2023
From: amit.kumar-mahapatra at amd.com (Mahapatra, Amit Kumar)
Date: Thu, 21 Dec 2023 06:54:22 +0000
Subject: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor
In-Reply-To: <576d56ed-d24b-40f9-9ae4-a02c50eea2ab@linaro.org>
References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com>
 <20231125092137.2948-8-amit.kumar-mahapatra@amd.com>
 <e2305642-55f1-4893-bea3-b170ac0a5348@linaro.org>
 <BN7PR12MB2802BEDFB821A1748185794CDC8AA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <f5a47024-514a-4846-bc16-08cf0f9af912@linaro.org>
 <BN7PR12MB2802BB3DA682D9C13EF7DE08DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <5a6f6764-6779-42b0-b6c6-3f638b85ef78@linaro.org>
 <BN7PR12MB28029EB1A7D09882878499A2DC8FA@BN7PR12MB2802.namprd12.prod.outlook.com>
 <c3fa1e04-92ed-48ab-a509-98e43abd5cd6@linaro.org>
 <BN7PR12MB2802E87F1A6CD22D904CAEACDC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
 <b3d3c457-a43b-478a-85b3-52558227d139@linaro.org>
 <BN7PR12MB28027E62D66460A374E3CFEADC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
 <e212f9fa-83c5-4b9e-8636-c8c6183096ab@linaro.org>
 <BN7PR12MB280237CDD7BB148479932874DC93A@BN7PR12MB2802.namprd12.prod.outlook.com>
 <576d56ed-d24b-40f9-9ae4-a02c50eea2ab@linaro.org>
Message-ID: <BN7PR12MB2802F288C6A6B1580CF07959DC95A@BN7PR12MB2802.namprd12.prod.outlook.com>

Hello Tudor,

> -----Original Message-----
> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> Sent: Tuesday, December 19, 2023 1:56 PM
> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> michael at walle.cc; linux-mtd at lists.infradead.org;
> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>; linux-
> arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git (AMD-
> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support
> in spi-nor
> 
> 
> 
> On 15.12.2023 13:20, Mahapatra, Amit Kumar wrote:
> > Hello Tudor,
> >
> 
> Hi!
> 
> >> -----Original Message-----
> >> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> >> Sent: Friday, December 15, 2023 4:03 PM
> >> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> >> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> >> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> >> lee at kernel.org; james.schulman at cirrus.com; david.rhodes at cirrus.com;
> >> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> >> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> >> michael at walle.cc; linux-mtd at lists.infradead.org;
> >> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> >> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>;
> >> linux-arm-kernel at lists.infradead.org; alsa- devel at alsa-project.org;
> >> patches at opensource.cirrus.com; linux- sound at vger.kernel.org; git
> >> (AMD-Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> >> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories
> >> support in spi-nor
> >>
> >>
> >>
> >> On 12/15/23 10:02, Mahapatra, Amit Kumar wrote:
> >>> Hello Tudor,
> >>
> >> Hi,
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: Tudor Ambarus <tudor.ambarus at linaro.org>
> >>>> Sent: Friday, December 15, 2023 1:40 PM
> >>>> To: Mahapatra, Amit Kumar <amit.kumar-mahapatra at amd.com>;
> >>>> broonie at kernel.org; pratyush at kernel.org; miquel.raynal at bootlin.com;
> >>>> richard at nod.at; vigneshr at ti.com; sbinding at opensource.cirrus.com;
> >>>> lee at kernel.org; james.schulman at cirrus.com;
> david.rhodes at cirrus.com;
> >>>> rf at opensource.cirrus.com; perex at perex.cz; tiwai at suse.com
> >>>> Cc: linux-spi at vger.kernel.org; linux-kernel at vger.kernel.org;
> >>>> michael at walle.cc; linux-mtd at lists.infradead.org;
> >>>> nicolas.ferre at microchip.com; alexandre.belloni at bootlin.com;
> >>>> claudiu.beznea at tuxon.dev; Simek, Michal <michal.simek at amd.com>;
> >>>> linux- arm-kernel at lists.infradead.org; alsa-devel at alsa-project.org;
> >>>> patches at opensource.cirrus.com; linux-sound at vger.kernel.org; git
> >>>> (AMD-
> >>>> Xilinx) <git at amd.com>; amitrkcian2002 at gmail.com
> >>>> Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories
> >>>> support in spi-nor
> >>>>
> >>>>
> >>>>
> >>>> On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
> >>>>>> Thanks! Can you share with us what flashes you used for testing
> >>>>>> in the stacked and parallel configurations?
> >>>>> I used SPI-NOR QSPI flashes for testing stacked and parallel.
> >>>>
> >>>> I got that, I wanted the flash name or device ID.
> >>>
> >>> N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI
> >> flashes
> >>> on which we tested. Additionally, we conducted tests on over 30
> >>> different QSPI flashes from four distinct vendors (Miron, Winbond,
> >> Macronix, and ISSI).
> >>>
> >>
> >> Great.
> >>
> >>>> What I'm interested is if each flash is in its own package. Are they?
> >>>
> >>> I'm sorry, but I don't quite understand what you mean by "if each
> >>> flash in its own package."
> >>>
> >>
> >> There are flashes that are stacked at the physical level. It's a
> >> single flash with multiple dies, that are all under a single physical package.
> >
> > Got it. The W25H02JV QSPI flash I mentioned earlier is a device with
> > with four dies that are stacked at the physical level.
> >
> >>
> >> As I understand, your stacked flash model is at logical level. You
> >> have
> >> 2 flashes each in its own package. 2 different entities. Is my
> >> understanding correct?
> >
> > Yes, that?s correct.
> >
> > I'd like to contribute to your earlier point regarding the placement
> > of the stacked layer. As you correctly highlighted, it should be in
> > the spi-mem generic layer. For instance, when a read/write operation
> > extends across multiple flashes (whether SPI-NOR or SPI-NAND), the
> > stacked layer must handle the flash crossover. This requires setting
> > the appropriate CS index in mem->spi->cs_index_mask to select the
> > correct slave device and updating the data buffer, address & data
> > length in spi_mem_op struct variable. Does this align with your
> understanding?
> >
> 
> This was the initial idea, yes, but we'll have to see how mtd concat fits in.
> Maybe the abstraction can be made at the mtd level, which I suspect mtd
> concat does. I have to read that driver, never opened it.

I haven't explored the mtd concat driver either.

> 
> Something else to consider: I see that Micron has a twin quad mode:
> https://media-www.micron.com/-
> /media/client/global/documents/products/data-sheet/nor-flash/serial-
> nor/mt25t/generation-
> b/mt25t_qljs_l_512_xba_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500
> 
> The micron's "Separate Chip-Select and Clock Signals" resembles the AMD's
> dual parallel 8-bit.

Yes, I agree.

> Micron's "Shared Chip-Select and Clock Signals" differs from the AMD's
> stacked mode, as Micron uses DQ[3:0] and DQ[7:4], whereas AMD considers
> both as DQ[3:0].

Yes, correct.

> 
> I had a short chat with Michael and he highlighted that instead of the parallel
> mode, one would be better of with an octal device. I wonder whether the
> quad parallel is worth the effort. I see AMD can select either quad
> (single/stacked/parallel) or octal (single/stacked). Is the parallel mode
 
Indeed, customers have the flexibility to choose between quad or octal 
options. However, some opt for a cost-effective strategy by selecting 
only Quad SPI in their chipset and boosting throughput through the 
parallel use of two flashes. To gauge the popularity of this 
configuration, I will consult with our marketing team for further 
insights. Given that parallel is a controller feature, it can be 
integrated into the driver file. At present, we can emphasis on 
implementing support for stacked mode, either through a new interface 
like mtd/spi-nor/stacked.c or by utilizing the mtd concat driver.

> considered obsolete for new IPs?

No, the parallel mode feature is still present in AMD's new IPs.

Regards,
Amit
> 
> Cheers,
> ta

From cw9316.lee at samsung.com  Wed Dec 20 22:56:08 2023
From: cw9316.lee at samsung.com (Chanwoo Lee)
Date: Thu, 21 Dec 2023 15:56:08 +0900
Subject: [PATCH v2] ufs: mcq: Adding a function for MCQ enable
References: <CGME20231221065637epcas1p203dcd5cfb1d4a3964fff9543a041d78d@epcas1p2.samsung.com>
Message-ID: <20231221065608.9899-1-cw9316.lee@samsung.com>

From: ChanWoo Lee <cw9316.lee at samsung.com>

The REG_UFS_MEM_CFG register is too general(broad)
and it is difficult to know the meaning only with a value of 0x1.
So far, comments were required.

Therefore, I have added new functions and defines
to improve code readability/reusability.

Signed-off-by: ChanWoo Lee <cw9316.lee at samsung.com>

* v1->v2:
   1) Excluding ESI_ENABLE
   2) Replace with ufshcd_rmwl, BIT()
   3) Separating hba->mcq_enabled
---
 drivers/ufs/core/ufs-mcq.c      | 6 ++++++
 drivers/ufs/core/ufshcd.c       | 4 +---
 drivers/ufs/host/ufs-mediatek.c | 4 +---
 include/ufs/ufshcd.h            | 1 +
 include/ufs/ufshci.h            | 3 +++
 5 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-mcq.c
index 0787456c2b89..edc752e55878 100644
--- a/drivers/ufs/core/ufs-mcq.c
+++ b/drivers/ufs/core/ufs-mcq.c
@@ -399,6 +399,12 @@ void ufshcd_mcq_enable_esi(struct ufs_hba *hba)
 }
 EXPORT_SYMBOL_GPL(ufshcd_mcq_enable_esi);
 
+void ufshcd_mcq_enable(struct ufs_hba *hba)
+{
+	ufshcd_rmwl(hba, MCQ_MODE_SELECT, MCQ_MODE_SELECT, REG_UFS_MEM_CFG);
+}
+EXPORT_SYMBOL_GPL(ufshcd_mcq_enable);
+
 void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg *msg)
 {
 	ufshcd_writel(hba, msg->address_lo, REG_UFS_ESILBA);
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index ae9936fc6ffb..30df6f6a72c6 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -8723,9 +8723,7 @@ static void ufshcd_config_mcq(struct ufs_hba *hba)
 	hba->host->can_queue = hba->nutrs - UFSHCD_NUM_RESERVED;
 	hba->reserved_slot = hba->nutrs - UFSHCD_NUM_RESERVED;
 
-	/* Select MCQ mode */
-	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
-		      REG_UFS_MEM_CFG);
+	ufshcd_mcq_enable(hba);
 	hba->mcq_enabled = true;
 
 	dev_info(hba->dev, "MCQ configured, nr_queues=%d, io_queues=%d, read_queue=%d, poll_queues=%d, queue_depth=%d\n",
diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index fc61790d289b..1048add66419 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -1219,9 +1219,7 @@ static int ufs_mtk_link_set_hpm(struct ufs_hba *hba)
 		ufs_mtk_config_mcq(hba, false);
 		ufshcd_mcq_make_queues_operational(hba);
 		ufshcd_mcq_config_mac(hba, hba->nutrs);
-		/* Enable MCQ mode */
-		ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
-			      REG_UFS_MEM_CFG);
+		ufshcd_mcq_enable(hba);
 	}
 
 	if (err)
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index d862c8ddce03..a96c45fa4b4b 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -1257,6 +1257,7 @@ unsigned long ufshcd_mcq_poll_cqe_lock(struct ufs_hba *hba,
 					 struct ufs_hw_queue *hwq);
 void ufshcd_mcq_make_queues_operational(struct ufs_hba *hba);
 void ufshcd_mcq_enable_esi(struct ufs_hba *hba);
+void ufshcd_mcq_enable(struct ufs_hba *hba);
 void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg *msg);
 
 int ufshcd_opp_config_clks(struct device *dev, struct opp_table *opp_table,
diff --git a/include/ufs/ufshci.h b/include/ufs/ufshci.h
index d5accacae6bc..2a6989a70671 100644
--- a/include/ufs/ufshci.h
+++ b/include/ufs/ufshci.h
@@ -282,6 +282,9 @@ enum {
 /* UTMRLRSR - UTP Task Management Request Run-Stop Register 80h */
 #define UTP_TASK_REQ_LIST_RUN_STOP_BIT		0x1
 
+/* REG_UFS_MEM_CFG - Global Config Registers 300h */
+#define MCQ_MODE_SELECT 	BIT(0)
+
 /* CQISy - CQ y Interrupt Status Register  */
 #define UFSHCD_MCQ_CQIS_TAIL_ENT_PUSH_STS	0x1
 
-- 
2.29.0



From dmitry.baryshkov at linaro.org  Wed Dec 20 23:03:04 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 09:03:04 +0200
Subject: [PATCH 1/8] dt-bindings: clock: qcom: Allow VDD_GFX supply to GX
In-Reply-To: <20231220-sa8295p-gpu-v1-1-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com> <20231220-sa8295p-gpu-v1-1-d8cdf2257f97@quicinc.com>
Message-ID: <CAA8EJprRjRJsV5hPR6mzjgucKa8UEthJd-y573aYJH0P8QRWqw@mail.gmail.com>

On Thu, 21 Dec 2023 at 05:51, Bjorn Andersson <quic_bjorande at quicinc.com> wrote:
>
> In some designs the SoC's VDD_GFX pads are supplied by an external
> regulator, rather than a power-domain. Allow this to be described in the
> GPU clock controller binding.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>  Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> index f369fa34e00c..013ef78d2b31 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> @@ -53,6 +53,9 @@ properties:
>    power-domains:
>      maxItems: 1
>
> +  vdd-gfx-supply:
> +    description: Regulator supply for the VDD_GFX pads
> +
>    '#clock-cells':
>      const: 1

I think it might be good to restrict this property to a particular
platform (via if:not:properties:compatible:contains
then:properties:vdd-gfx-supply:false).


-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Wed Dec 20 23:04:08 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 09:04:08 +0200
Subject: [PATCH 3/8] clk: qcom: gpucc-sc8280xp: Add external supply for GX gdsc
In-Reply-To: <20231220-sa8295p-gpu-v1-3-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com> <20231220-sa8295p-gpu-v1-3-d8cdf2257f97@quicinc.com>
Message-ID: <CAA8EJpqvo9MMBTT8mMCZRn3+zOmicbe7=sPZLuqU_sAq+Ngd_w@mail.gmail.com>

On Thu, 21 Dec 2023 at 05:51, Bjorn Andersson <quic_bjorande at quicinc.com> wrote:
>
> On SA8295P and SA8540P the GFX rail is powered by a dedicated external
> regulator, instead of the rpmh-controlled "gfx.lvl".
>
> Define the "vdd-gfx" as the supply regulator for the GDSC, to cause the
> gdsc logic to look for, and control, this external power supply.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>  drivers/clk/qcom/gpucc-sc8280xp.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>

-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Wed Dec 20 23:05:23 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 09:05:23 +0200
Subject: [PATCH 4/8] soc: qcom: rpmhpd: Drop SA8540P gfx.lvl
In-Reply-To: <20231220-sa8295p-gpu-v1-4-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com> <20231220-sa8295p-gpu-v1-4-d8cdf2257f97@quicinc.com>
Message-ID: <CAA8EJppbXZQcMw7UGka4YCQDdEJKD0hda=QdsEyNcjYf9U0PNQ@mail.gmail.com>

On Thu, 21 Dec 2023 at 05:51, Bjorn Andersson <quic_bjorande at quicinc.com> wrote:
>
> On SA8295P and SA8540P gfx.lvl is not provdied by rpmh, but rather is
> handled by an external regulator (max20411). Drop gfx.lvl from the list
> of power-domains exposed on this platform.
>
> Fixes: f68f1cb3437d ("soc: qcom: rpmhpd: add sc8280xp & sa8540p rpmh power-domains")
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>  drivers/pmdomain/qcom/rpmhpd.c | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>

-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Wed Dec 20 23:06:42 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 09:06:42 +0200
Subject: [PATCH 5/8] arm64: dts: qcom: sa8540p: Drop gfx.lvl as
 power-domain for gpucc
In-Reply-To: <20231220-sa8295p-gpu-v1-5-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com> <20231220-sa8295p-gpu-v1-5-d8cdf2257f97@quicinc.com>
Message-ID: <CAA8EJpqU4On=jpjk0-KkXMmwVhzLddJchQzy=LmJHnChjNpmSQ@mail.gmail.com>

On Thu, 21 Dec 2023 at 05:51, Bjorn Andersson <quic_bjorande at quicinc.com> wrote:
>
> The SA8295P and SA8540P uses an external regulator (max20411), and
> gfx.lvl is not provided by rpmh. Drop the power-domains property of the
> gpucc node to reflect this.
>
> Fixes: eec51ab2fd6f ("arm64: dts: qcom: sc8280xp: Add GPU related nodes")
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/sa8540p.dtsi | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>

>
> diff --git a/arch/arm64/boot/dts/qcom/sa8540p.dtsi b/arch/arm64/boot/dts/qcom/sa8540p.dtsi
> index 96b2c59ad02b..b604404ebf64 100644
> --- a/arch/arm64/boot/dts/qcom/sa8540p.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sa8540p.dtsi
> @@ -168,6 +168,8 @@ opp-2592000000 {
>  };
>
>  &gpucc {
> +       /delete-property/ power-domains;

Nit: maybe this deserves a comment.

> +
>         status = "disabled";
>  };
>
>
> --
> 2.25.1
>
>


-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Wed Dec 20 23:07:52 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 09:07:52 +0200
Subject: [PATCH 6/8] arm64: dts: qcom: sa8295p-adp: add max20411
In-Reply-To: <20231220-sa8295p-gpu-v1-6-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com> <20231220-sa8295p-gpu-v1-6-d8cdf2257f97@quicinc.com>
Message-ID: <CAA8EJprUobs=EJWTMK5=U-=5rU_L0RWRgjFjBZZX1mQWMiW4_w@mail.gmail.com>

On Thu, 21 Dec 2023 at 05:52, Bjorn Andersson <quic_bjorande at quicinc.com> wrote:
>
> From: Bjorn Andersson <andersson at kernel.org>
>
> The SA8295P ADP has a MAX20411 LDO regulator on I2C 12, supplying the
> VDD_GFX pads. Enable the bus and add the maxim,max20411 device on the
> bus.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 40 ++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> index fd253942e5e5..e16406c9c19d 100644
> --- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> +++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> @@ -266,6 +266,26 @@ &dispcc1 {
>         status = "okay";
>  };
>
> +&i2c12 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&qup1_i2c4_state>;
> +
> +       status = "okay";
> +
> +       vdd_gfx: regulator at 39 {
> +               compatible = "maxim,max20411";
> +               reg = <0x39>;
> +
> +               regulator-min-microvolt = <800000>;
> +               regulator-max-microvolt = <968750>;
> +
> +               enable-gpios = <&pmm8540a_gpios 2 GPIO_ACTIVE_HIGH>;
> +
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&max20411_en>;
> +       };
> +};
> +
>  &mdss0 {
>         status = "okay";
>  };
> @@ -476,6 +496,10 @@ &pcie4_phy {
>         status = "okay";
>  };
>
> +&qup1 {
> +       status = "okay";
> +};
> +
>  &qup2 {
>         status = "okay";
>  };
> @@ -728,4 +752,20 @@ wake-n-pins {
>                         bias-pull-up;
>                 };
>         };
> +
> +       qup1_i2c4_state: qup1-i2c4-state {
> +               pins = "gpio0", "gpio1";
> +               function = "qup12";
> +
> +               drive-strength = <2>;
> +               bias-pull-up;
> +       };
> +};
> +
> +&pmm8540a_gpios {

I think pmm8540a_gpios comes before tlmm in the dictionary order.
Other than that LGTM

> +       max20411_en: max20411-en-state {
> +               pins = "gpio2";
> +               function = "normal";
> +               output-enable;
> +       };
>  };



-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Wed Dec 20 23:09:05 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 09:09:05 +0200
Subject: [PATCH 7/8] arm64: dts: qcom: sa8295p-adp: Enable GPU
In-Reply-To: <20231220-sa8295p-gpu-v1-7-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com> <20231220-sa8295p-gpu-v1-7-d8cdf2257f97@quicinc.com>
Message-ID: <CAA8EJpqiW7Sw-=3FzVjZMh0UcYgXWQCqL5P4Bk0QqrVahJYzQA@mail.gmail.com>

On Thu, 21 Dec 2023 at 05:52, Bjorn Andersson <quic_bjorande at quicinc.com> wrote:
>
> With the necessary support in place for supplying VDD_GFX from the
> MAX20411 regulator, enable the GPU clock controller, GMU, Adreno SMMU
> and the GPU on the SA8295P ADP.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> index e16406c9c19d..7775c5f4d2e8 100644
> --- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> +++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> @@ -108,6 +108,13 @@ edp3_connector_in: endpoint {
>                         };
>                 };
>         };
> +
> +       reserved-memory {
> +               gpu_mem: gpu-mem at 8bf00000 {
> +                       reg = <0 0x8bf00000 0 0x2000>;
> +                       no-map;
> +               };
> +       };
>  };
>
>  &apps_rsc {
> @@ -286,6 +293,28 @@ vdd_gfx: regulator at 39 {
>         };
>  };
>
> +&gpucc {
> +       vdd-gfx-supply = <&vdd_gfx>;
> +       status = "okay";
> +};
> +
> +&gmu {
> +       status = "okay";
> +};
> +
> +&gpu {
> +       status = "okay";
> +
> +       zap-shader {
> +               memory-region = <&gpu_mem>;
> +               firmware-name = "qcom/sa8295p/a690_zap.mdt";

Can we please have .mbn here? Other than that, it looks good to me.

> +       };
> +};
> +
> +&gpu_smmu {
> +       status = "okay";
> +};
> +
>  &mdss0 {
>         status = "okay";
>  };
>
> --
> 2.25.1
>
>


-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Wed Dec 20 23:10:28 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 09:10:28 +0200
Subject: [PATCH 1/8] dt-bindings: clock: qcom: Allow VDD_GFX supply to GX
In-Reply-To: <CAA8EJprRjRJsV5hPR6mzjgucKa8UEthJd-y573aYJH0P8QRWqw@mail.gmail.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
 <20231220-sa8295p-gpu-v1-1-d8cdf2257f97@quicinc.com> <CAA8EJprRjRJsV5hPR6mzjgucKa8UEthJd-y573aYJH0P8QRWqw@mail.gmail.com>
Message-ID: <CAA8EJpqgcOJHUFHtrTEE0T+jtQqdv3RGm-eTuVVa0ama_eFssQ@mail.gmail.com>

On Thu, 21 Dec 2023 at 09:03, Dmitry Baryshkov
<dmitry.baryshkov at linaro.org> wrote:
>
> On Thu, 21 Dec 2023 at 05:51, Bjorn Andersson <quic_bjorande at quicinc.com> wrote:
> >
> > In some designs the SoC's VDD_GFX pads are supplied by an external
> > regulator, rather than a power-domain. Allow this to be described in the
> > GPU clock controller binding.
> >
> > Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> > ---
> >  Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> > index f369fa34e00c..013ef78d2b31 100644
> > --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> > +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> > @@ -53,6 +53,9 @@ properties:
> >    power-domains:
> >      maxItems: 1
> >
> > +  vdd-gfx-supply:
> > +    description: Regulator supply for the VDD_GFX pads
> > +
> >    '#clock-cells':
> >      const: 1
>
> I think it might be good to restrict this property to a particular
> platform (via if:not:properties:compatible:contains
> then:properties:vdd-gfx-supply:false).

After reading the last patches in the series, there is another
suggestion. Maybe we should explicitly say that there should be either
power-domains or vdd-gfx-supply, but not both.


-- 
With best wishes
Dmitry


From herve.codina at bootlin.com  Wed Dec 20 23:15:35 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Thu, 21 Dec 2023 08:15:35 +0100
Subject: [PATCH v2 00/17] Prepare the PowerQUICC QMC and TSA for the
 HDLC QMC driver
In-Reply-To: <20231205152116.122512-1-herve.codina@bootlin.com>
References: <20231205152116.122512-1-herve.codina@bootlin.com>
Message-ID: <20231221081535.22350442@bootlin.com>

Hi Arnd,

As you suggested in the previous iteration [1], I sent a PR related to this
series:
  https://lore.kernel.org/all/20231212105514.273e8ab0 at bootlin.com/

I didn't receive any feedback on this PR and it does not seem to have been
taken into account.
Did I miss something ?

Best regards,
Herv?

[1]  https://lore.kernel.org/all/81e78cb7-ec97-4cec-ac3a-674e296af93b at app.fastmail.com/
  
On Tue,  5 Dec 2023 16:20:57 +0100
Herve Codina <herve.codina at bootlin.com> wrote:

> Hi,
> 
> This series updates PowerQUICC QMC and TSA drivers to prepare the
> support for the QMC HDLC driver.
> 
> Patches were previously sent as part of a full feature series:
> "Add support for QMC HDLC, framer infrastructure and PEF2256 framer" [1]
> 
> The full feature series reached the v9 iteration.
> The v1 was sent the 07/25/2023 followed by the other iterations
> (07/26/2023, 08/09/2023, 08/18/2023, 09/12/2023, 09/22/2023, 09/28/2023,
> 10/11/23, 11/15/2023) and was ready to be merged in its v8.
>   https://lore.kernel.org/linux-kernel/20231025123215.5caca7d4 at kernel.org/
> 
> The lack of feedback from the Freescale SoC and the Quicc Engine
> maintainers (i.e. drivers/soc/fsl/qe/ to which the QMC and TSA drivers
> belong) blocks the entire full feature series.
> These patches are fixes and improvements to TSA and QMC drivers.
> These drivers were previously acked by Li Yang but without any feedback
> from Li Yang nor Qiang Zhao the series cannot move forward.
> 
> In order to ease the review/merge, the full feature series has been
> split and this series contains patches related to the PowerQUICC SoC
> part (QMC and TSA).
>  - Perform some fixes (patches 1 to 5)
>  - Add support for child devices (patch 6)
>  - Add QMC dynamic timeslot support (patches 7 to 17)
> 
> Compare to the previous iteration:
>   https://lore.kernel.org/linux-kernel/20231128140818.261541-1-herve.codina at bootlin.com/
> this v2 series:
> - Removes a forward declaration in the driver.
> - Adds kernel test robot tags as the issue was detected.
> - Adds some missing Cc: stable.
> 
> Best regards,
> Herv?
> 
> [1]: https://lore.kernel.org/linux-kernel/20231115144007.478111-1-herve.codina at bootlin.com/
> 
> Changes v1 -> v2:
>   - Patch 1
>     Add 'Reported-by: kernel test robot <lkp at intel.com>'
>     Add 'Closes: https://lore.kernel.org/oe-kbuild-all/202312051959.9YdRIYbg-lkp at intel.com/'
>     Add 'Cc: stable at vger.kernel.org'
> 
>   - Patch 2, 3
>     Add 'Cc: stable at vger.kernel.org
> 
>   - Patch 15
>     Move qmc_setup_chan_trnsync() to avoid a forward declaration.
> 
> Patches extracted:
>   - Patch 1..6 : full feature series patch 1..6
>   - Patch 7..17 : full feature series patch 9..19
> 
> Herve Codina (17):
>   soc: fsl: cpm1: tsa: Fix __iomem addresses declaration
>   soc: fsl: cpm1: qmc: Fix __iomem addresses declaration
>   soc: fsl: cpm1: qmc: Fix rx channel reset
>   soc: fsl: cpm1: qmc: Extend the API to provide Rx status
>   soc: fsl: cpm1: qmc: Remove inline function specifiers
>   soc: fsl: cpm1: qmc: Add support for child devices
>   soc: fsl: cpm1: qmc: Introduce available timeslots masks
>   soc: fsl: cpm1: qmc: Rename qmc_setup_tsa* to qmc_init_tsa*
>   soc: fsl: cpm1: qmc: Introduce qmc_chan_setup_tsa*
>   soc: fsl: cpm1: qmc: Remove no more needed checks from
>     qmc_check_chans()
>   soc: fsl: cpm1: qmc: Check available timeslots in qmc_check_chans()
>   soc: fsl: cpm1: qmc: Add support for disabling channel TSA entries
>   soc: fsl: cpm1: qmc: Split Tx and Rx TSA entries setup
>   soc: fsl: cpm1: qmc: Introduce is_tsa_64rxtx flag
>   soc: fsl: cpm1: qmc: Handle timeslot entries at channel start() and
>     stop()
>   soc: fsl: cpm1: qmc: Remove timeslots handling from setup_chan()
>   soc: fsl: cpm1: qmc: Introduce functions to change timeslots at
>     runtime
> 
>  drivers/soc/fsl/qe/qmc.c      | 658 ++++++++++++++++++++++++++--------
>  drivers/soc/fsl/qe/tsa.c      |  22 +-
>  include/soc/fsl/qe/qmc.h      |  27 +-
>  sound/soc/fsl/fsl_qmc_audio.c |   2 +-
>  4 files changed, 538 insertions(+), 171 deletions(-)
> 



From fuyao at sjterm.com  Wed Dec 20 23:16:54 2023
From: fuyao at sjterm.com (fuyao)
Date: Thu, 21 Dec 2023 15:16:54 +0800
Subject: [PATCH] gmac: sun8i: r40: add gmac tx_delay support
In-Reply-To: <2370947.NG923GbCHz@jernej-laptop>
References: <ZYKvCQBD-SY9uVLF@debian.cyg>
 <2370947.NG923GbCHz@jernej-laptop>
Message-ID: <ZYPmZj8l01eQsDS5@debian.cyg>

On Wed, Dec 20, 2023 at 06:04:28PM +0100, Jernej ?krabec wrote:
> Dne sreda, 20. december 2023 ob 10:08:25 CET je fuyao napisal(a):
> > r40 can support tx_delay, so we add it.
> 
> I don't see how. User manual, 3.3.4.64. GMAC Clock Register talks only
> about RX delay.
> 

I don't see it in the user manual also.

it works fine in 100M, but it doesn't work good in 1G without tx_delay
in my board.

Read the sdk from allwinner I found in:

https://sourcegraph.com/github.com/tinalinux/linux-3.10/-/blob/arch/arm/boot/dts/sun8iw11p1.dtsi?L1826
https://sourcegraph.com/github.com/tinalinux/linux-3.10 at r40-v1.y/-/blob/drivers/net/ethernet/allwinner/sunxi-gmac.c?L877

And I add it to my board, it works fine.

So, I think it may be exist register but not documented.

Best regards,
fuyao

> Best regards,
> Jernej
> 
> > 
> > Signed-off-by: fuyao <fuyao1697 at cyg.com>
> > ---
> >  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> > index 137741b94122..fd07573afc9b 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> > @@ -127,6 +127,7 @@ static const struct emac_variant emac_variant_r40 = {
> >  	.support_mii = true,
> >  	.support_rgmii = true,
> >  	.rx_delay_max = 7,
> > +	.tx_delay_max = 7,
> >  };
> >  
> >  static const struct emac_variant emac_variant_a64 = {
> > 
> 
> 
> 
> 



From tudor.ambarus at linaro.org  Wed Dec 20 23:20:34 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 21 Dec 2023 07:20:34 +0000
Subject: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0
 clock management unit
In-Reply-To: <20231220150726.GA223267-robh@kernel.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-3-tudor.ambarus@linaro.org>
 <20231220150726.GA223267-robh@kernel.org>
Message-ID: <173b06ab-2518-49ee-a67f-85256bc5b6a7@linaro.org>



On 12/20/23 15:07, Rob Herring wrote:
> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>> clock management unit.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>> ---
>>  .../bindings/clock/google,gs101-clock.yaml    | 25 +++++-
>>  include/dt-bindings/clock/google,gs101.h      | 86 +++++++++++++++++++
>>  2 files changed, 109 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>> index 3eebc03a309b..ba54c13c55bc 100644
>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>> @@ -30,14 +30,15 @@ properties:
>>        - google,gs101-cmu-top
>>        - google,gs101-cmu-apm
>>        - google,gs101-cmu-misc
>> +      - google,gs101-cmu-peric0
>>  
>>    clocks:
>>      minItems: 1
>> -    maxItems: 2
>> +    maxItems: 3
>>  
>>    clock-names:
>>      minItems: 1
>> -    maxItems: 2
>> +    maxItems: 3
>>  
>>    "#clock-cells":
>>      const: 1
>> @@ -88,6 +89,26 @@ allOf:
>>              - const: dout_cmu_misc_bus
>>              - const: dout_cmu_misc_sss
>>  
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: google,gs101-cmu-peric0
>> +
>> +    then:
>> +      properties:
>> +        clocks:
>> +          items:
>> +            - description: External reference clock (24.576 MHz)
>> +            - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>> +            - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>> +
>> +        clock-names:
>> +          items:
>> +            - const: oscclk
>> +            - const: dout_cmu_peric0_bus
>> +            - const: dout_cmu_peric0_ip
> 
> 'bus' and 'ip' are sufficient because naming is local to the module. The 
> same is true on 'dout_cmu_misc_bus'. As that has not made a release, 
> please fix all of them.
>

Ok, will fix them shortly. Thanks, Rob!


From xuewen.yan94 at gmail.com  Wed Dec 20 23:28:12 2023
From: xuewen.yan94 at gmail.com (Xuewen Yan)
Date: Thu, 21 Dec 2023 15:28:12 +0800
Subject: [PATCH 1/2] OPP: Add API to update EM after adjustment of voltage
 for OPPs
In-Reply-To: <20231220110339.1065505-2-lukasz.luba@arm.com>
References: <20231220110339.1065505-1-lukasz.luba@arm.com> <20231220110339.1065505-2-lukasz.luba@arm.com>
Message-ID: <CAB8ipk9PQbS=bjZ8F8brCfdXOgz6HUT0on2K1ZDLAaOhV9OpZw@mail.gmail.com>

On Wed, Dec 20, 2023 at 7:02?PM Lukasz Luba <lukasz.luba at arm.com> wrote:
>
> There are device drivers which can modify voltage values for OPPs. It
> could be due to the chip binning and those drivers have specific chip
> knowledge about this. This adjustment can happen after Energy Model is
> registered, thus EM can have stale data about power.
>
> Introduce new API function which can be used by device driver which
> adjusted the voltage for OPPs. The implementation takes care about
> calculating needed internal details in the new EM table ('cost' field).
> It plugs in the new EM table to the framework so other subsystems would
> use the correct data.
>
> Signed-off-by: Lukasz Luba <lukasz.luba at arm.com>
> ---
>  drivers/opp/of.c       | 69 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/pm_opp.h |  6 ++++
>  2 files changed, 75 insertions(+)
>
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 81fa27599d58..992434c0b711 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -1596,3 +1596,72 @@ int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus)
>         return ret;
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_opp_of_register_em);
> +
> +/**
> + * dev_pm_opp_of_update_em() - Update Energy Model with new power values
> + * @dev                : Device for which an Energy Model has to be registered
> + *
> + * This uses the "dynamic-power-coefficient" devicetree property to calculate
> + * power values for EM. It uses the new adjusted voltage values known for OPPs
> + * which have changed after boot.
> + */
> +int dev_pm_opp_of_update_em(struct device *dev)
> +{
> +       struct em_perf_table __rcu *runtime_table;
> +       struct em_perf_state *table, *new_table;
> +       struct em_perf_domain *pd;
> +       int ret, table_size, i;
> +
> +       if (IS_ERR_OR_NULL(dev))
> +               return -EINVAL;
> +
> +       pd = em_pd_get(dev);
> +       if (!pd) {
> +               dev_warn(dev, "Couldn't find Energy Model %d\n", ret);
> +               return -EINVAL;
> +       }
> +
> +       runtime_table = em_allocate_table(pd);
> +       if (!runtime_table) {
> +               dev_warn(dev, "new EM allocation failed\n");
> +               return -ENOMEM;
> +       }
> +
> +       new_table = runtime_table->state;
> +
> +       table = em_get_table(pd);
> +       /* Initialize data based on older EM table */
> +       table_size = sizeof(struct em_perf_state) * pd->nr_perf_states;
> +       memcpy(new_table, table, table_size);
> +
> +       em_put_table();
> +
> +       /* Update power values which might change due to new voltage in OPPs */
> +       for (i = 0; i < pd->nr_perf_states; i++) {
> +               unsigned long freq = new_table[i].frequency;
> +               unsigned long power;
> +
> +               ret = _get_power(dev, &power, &freq);
> +               if (ret)
> +                       goto failed;

Need we use the EM_SET_ACTIVE_POWER_CB(em_cb, _get_power) and call
em_cb->active_power?

> +
> +               new_table[i].power = power;
> +       }
> +
> +       ret = em_dev_compute_costs(dev, new_table, pd->nr_perf_states);
> +       if (ret)
> +               goto failed;
> +
> +       ret = em_dev_update_perf_domain(dev, runtime_table);
> +       if (ret)
> +               goto failed;
> +
> +       return 0;
> +
> +failed:
> +       dev_warn(dev, "EM update failed %d\n", ret);
> +       em_free_table(runtime_table);
> +
> +       return ret;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_opp_of_update_em);
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index ccd97bcef269..b3ab117890fc 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -464,6 +464,7 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
>  int of_get_required_opp_performance_state(struct device_node *np, int index);
>  int dev_pm_opp_of_find_icc_paths(struct device *dev, struct opp_table *opp_table);
>  int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus);
> +int dev_pm_opp_of_update_em(struct device *dev);
>  static inline void dev_pm_opp_of_unregister_em(struct device *dev)
>  {
>         em_dev_unregister_perf_domain(dev);
> @@ -527,6 +528,11 @@ static inline void dev_pm_opp_of_unregister_em(struct device *dev)
>  {
>  }
>
> +static inline int dev_pm_opp_of_update_em(struct device *dev)
> +{
> +       return -EOPNOTSUPP;
> +}
> +
>  static inline int of_get_required_opp_performance_state(struct device_node *np, int index)
>  {
>         return -EOPNOTSUPP;
> --
> 2.25.1
>


From canghousehold at aol.com  Wed Dec 20 23:40:34 2023
From: canghousehold at aol.com (Household Cang)
Date: Thu, 21 Dec 2023 02:40:34 -0500
Subject: [PATCH net 0/1] Prevent DSA tags from breaking COE
In-Reply-To: <20231218162326.173127-1-romain.gantois@bootlin.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
Message-ID: <0351C5C2-FEE2-4AED-84C8-9DCACCE4ED0A@aol.com>



> On Dec 18, 2023, at 11:23 AM, Romain Gantois <romain.gantois at bootlin.com> wrote:
> 
> This is a bugfix for an issue that was recently brought up in two
> reports:
> 
> https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495 at bootlin.com/
> https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2 at electromag.com.au/
> 
Add me in to be the 3rd report...
RK3568 GMAC0 (eth1) to MT7531BE (CPU port)
Current workaround for me is ethtool -K eth1 rx off tx off

https://lore.kernel.org/netdev/m3clft2k7umjtny546ot3ayebattksibty3yyttpffvdixl65p at 7dpqsr5nisbk/T/#t

Question on the patch to be built: how would I know if my setup could take advantage of the HW checksum offload? RK3658?s eth0 on stmmac is doing fine, and eth0 is not on a DSA switch. Does this mean eth1 should be able to do hw checksum offload once the stmmac driver is fixed?
?Lucas

From tudor.ambarus at linaro.org  Wed Dec 20 23:41:21 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 21 Dec 2023 07:41:21 +0000
Subject: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
In-Reply-To: <914b634d-444c-4eae-bc7e-0f20d0629470@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-6-tudor.ambarus@linaro.org>
 <1938fcf1-eb5d-4723-a6c6-d2fe2c6dd1c0@app.fastmail.com>
 <8808ceeb-35dc-4094-aec4-f43c7acd6174@linaro.org>
 <6962ac73-2f44-4c9e-8731-152087815454@app.fastmail.com>
 <584e036a-2ae7-4b88-a517-8f79c6baed4a@linaro.org>
 <914b634d-444c-4eae-bc7e-0f20d0629470@linaro.org>
Message-ID: <db368449-f446-47e8-81b6-a11c2a872306@linaro.org>



On 12/15/23 08:01, Krzysztof Kozlowski wrote:
> On 14/12/2023 15:31, Tudor Ambarus wrote:
>>
>>
>> On 12/14/23 14:19, Arnd Bergmann wrote:
>>> On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
>>>> On 12/14/23 12:01, Arnd Bergmann wrote:
>>>>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>>>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>>>>
>>>>
>>>> It works if in device tree one specifies the reg-io-width property and
>>>> sets it to 4. If the reg-io-width is not specified, the iotype defaults
>>>> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
>>>> unusable.
>>>
>>> In the case of incorrect DT data like a missing reg-io-width property,
>>> I would expect it to still fail once the regular console or tty takes
>>> over from earlycon.
>>>
>>>> Also, if the earlycon comes specified from the kernel params, the
>>>> of_setup_earlycon() is no longer called and the earlycon will be set
>>>> solely based on the kernel params buffer, thus allowing users to crash
>>>> the kernel on wrong earlycon definitions.
>>>
>>> But that in turn is the same as specifying any other incorrect earlycon.
>>
>> I don't think you can crash the kernel if you use other earlycon as you
>> don't make accesses on the 32bit restricted bus. But I agree that if
>> using the correct earlycon name, and mmio instead mmio32, is equivalent
>> to not specifying reg-io-width in dt.
>>
>>>
>>>> If you think the change is fine, I can amend the commit message with the
>>>> description from above.
>>>
>>> I'm still not convinced we need a special case here when everything else
>>> just requires passing the correct data.
> 
> We shouldn't need any data from DT for this case, because this property
> apparently can be inferred from the compatible. IOW, GS101 SoC requires
> reg-io-width=4, everywhere, for each node, thus there is no need to
> specify this property. It should be deduced from the compatible.
> 

The entire peric0/1 block requires 32 bit data widths indeed. PERIC is
used by the Universal Serial Interface (USI) and I3C. I've checked few
other hardware blocks and all require 32 bit data widths (G3D, TPU, TNR,
PERIC, PDP, MFC, MCSC, IPP, HSI, GSA and I stopped here).

If the reg-io-width shall be inferred from the compatible in the gs101
case, then this patch stands. I'll update the serial driver as well.

Thanks,
ta


From lukasz.luba at arm.com  Thu Dec 21 00:04:16 2023
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Thu, 21 Dec 2023 08:04:16 +0000
Subject: [PATCH 1/2] OPP: Add API to update EM after adjustment of voltage
 for OPPs
In-Reply-To: <CAB8ipk9PQbS=bjZ8F8brCfdXOgz6HUT0on2K1ZDLAaOhV9OpZw@mail.gmail.com>
References: <20231220110339.1065505-1-lukasz.luba@arm.com>
 <20231220110339.1065505-2-lukasz.luba@arm.com>
 <CAB8ipk9PQbS=bjZ8F8brCfdXOgz6HUT0on2K1ZDLAaOhV9OpZw@mail.gmail.com>
Message-ID: <fe2f856b-c9c4-41b9-b569-079657b05b79@arm.com>



On 12/21/23 07:28, Xuewen Yan wrote:
> On Wed, Dec 20, 2023 at 7:02?PM Lukasz Luba <lukasz.luba at arm.com> wrote:
>>
>> There are device drivers which can modify voltage values for OPPs. It
>> could be due to the chip binning and those drivers have specific chip
>> knowledge about this. This adjustment can happen after Energy Model is
>> registered, thus EM can have stale data about power.
>>
>> Introduce new API function which can be used by device driver which
>> adjusted the voltage for OPPs. The implementation takes care about
>> calculating needed internal details in the new EM table ('cost' field).
>> It plugs in the new EM table to the framework so other subsystems would
>> use the correct data.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba at arm.com>
>> ---
>>   drivers/opp/of.c       | 69 ++++++++++++++++++++++++++++++++++++++++++
>>   include/linux/pm_opp.h |  6 ++++
>>   2 files changed, 75 insertions(+)
>>
>> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
>> index 81fa27599d58..992434c0b711 100644
>> --- a/drivers/opp/of.c
>> +++ b/drivers/opp/of.c
>> @@ -1596,3 +1596,72 @@ int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus)
>>          return ret;
>>   }
>>   EXPORT_SYMBOL_GPL(dev_pm_opp_of_register_em);
>> +
>> +/**
>> + * dev_pm_opp_of_update_em() - Update Energy Model with new power values
>> + * @dev                : Device for which an Energy Model has to be registered
>> + *
>> + * This uses the "dynamic-power-coefficient" devicetree property to calculate
>> + * power values for EM. It uses the new adjusted voltage values known for OPPs
>> + * which have changed after boot.
>> + */
>> +int dev_pm_opp_of_update_em(struct device *dev)
>> +{
>> +       struct em_perf_table __rcu *runtime_table;
>> +       struct em_perf_state *table, *new_table;
>> +       struct em_perf_domain *pd;
>> +       int ret, table_size, i;
>> +
>> +       if (IS_ERR_OR_NULL(dev))
>> +               return -EINVAL;
>> +
>> +       pd = em_pd_get(dev);
>> +       if (!pd) {
>> +               dev_warn(dev, "Couldn't find Energy Model %d\n", ret);
>> +               return -EINVAL;
>> +       }
>> +
>> +       runtime_table = em_allocate_table(pd);
>> +       if (!runtime_table) {
>> +               dev_warn(dev, "new EM allocation failed\n");
>> +               return -ENOMEM;
>> +       }
>> +
>> +       new_table = runtime_table->state;
>> +
>> +       table = em_get_table(pd);
>> +       /* Initialize data based on older EM table */
>> +       table_size = sizeof(struct em_perf_state) * pd->nr_perf_states;
>> +       memcpy(new_table, table, table_size);
>> +
>> +       em_put_table();
>> +
>> +       /* Update power values which might change due to new voltage in OPPs */
>> +       for (i = 0; i < pd->nr_perf_states; i++) {
>> +               unsigned long freq = new_table[i].frequency;
>> +               unsigned long power;
>> +
>> +               ret = _get_power(dev, &power, &freq);
>> +               if (ret)
>> +                       goto failed;
> 
> Need we use the EM_SET_ACTIVE_POWER_CB(em_cb, _get_power) and call
> em_cb->active_power?
> 

No, not in this case. It's not like registration of EM, when there
is a need to also pass the callback function. As you can see this code
operates locally and the call _get_power() just simply gets the
power in straight way. Later the whole 'runtime_table' is passed to the
EM framework to 'swap' the pointers under RCU.

Thanks Xuewen for having a look at this!



From linus.walleij at linaro.org  Thu Dec 21 00:06:13 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 21 Dec 2023 09:06:13 +0100
Subject: [PATCH] pinctrl: at91-pio4: use dedicated lock class for IRQ
In-Reply-To: <20231215-lockdep_warning-v1-1-8137b2510ed5@bootlin.com>
References: <20231215-lockdep_warning-v1-1-8137b2510ed5@bootlin.com>
Message-ID: <CACRpkdZnPPHgRf+taFPOM4P0U+4w2LuAUyfgJuRtawVhFQWQkg@mail.gmail.com>

On Fri, Dec 15, 2023 at 10:35?PM Alexis Lothor?
<alexis.lothore at bootlin.com> wrote:

> Trying to suspend to RAM on SAMA5D27 EVK leads to the following lockdep
> warning:
(...)
> Fix lockdep false positive by setting a different class for parent and
> children IRQ
>
> Fixes: 776180848b57 ("pinctrl: introduce driver for Atmel PIO4 controller")
> Signed-off-by: Alexis Lothor? <alexis.lothore at bootlin.com>

Patch applied for fixes.

Yours,
Linus Walleij


From krzysztof.kozlowski at linaro.org  Thu Dec 21 00:14:43 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 09:14:43 +0100
Subject: [PATCH v2 06/22] ARM: dts: samsung: exynos5420: Enable
 cros-ec-spi as wake source
In-Reply-To: <20231220165423.v2.6.I06b059021de1bf6103e60a73211f078f2af75d17@changeid>
References: <20231220235459.2965548-1-markhas@chromium.org>
 <20231220165423.v2.6.I06b059021de1bf6103e60a73211f078f2af75d17@changeid>
Message-ID: <7199b7b7-238e-45de-96f1-0f04d0fa718d@linaro.org>

On 21/12/2023 00:54, Mark Hasemeyer wrote:
> The cros_ec driver currently assumes that cros-ec-spi compatible device
> nodes are a wakeup-source even though the wakeup-source property is not
> defined.
> 
> Add the wakeup-source property to all cros-ec-spi compatible device
> nodes to match expected behavior.
> 

You do not need this property, if driver assumes that. Just enable it
unconditionally. I don't think anything from previous discussion was
resolved.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec 21 00:19:55 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 09:19:55 +0100
Subject: [PATCH v4] dt-bindings: net: wireless: mt76: add interrupts
 description for MT7986
In-Reply-To: <20231221032648.641-1-chui-hao.chiu@mediatek.com>
References: <20231221032648.641-1-chui-hao.chiu@mediatek.com>
Message-ID: <5abb125e-eca8-41d8-813b-7573daaa23a0@linaro.org>

On 21/12/2023 04:26, Peter Chiu wrote:
> The mt7986 can support four interrupts to distribute the interrupts
> to different CPUs.
> 
> Signed-off-by: Peter Chiu <chui-hao.chiu at mediatek.com>
> ---
> v2: Change to use description instead of using items.
> v3: Change to use items and set different minItems for mediatek,mt7986-wmac
> v4: Move allOf after required and remove duplicated blank line.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From andy.yan at rock-chips.com  Thu Dec 21 00:28:29 2023
From: andy.yan at rock-chips.com (Andy Yan)
Date: Thu, 21 Dec 2023 16:28:29 +0800
Subject: [PATCH] Revert "ARM: dts: rockchip: restyle emac nodes"
In-Reply-To: <406ba492-8f6b-26aa-55cf-2efa8d52ebaf@gmail.com>
References: <20231220103334.2665543-1-andyshrk@163.com>
 <406ba492-8f6b-26aa-55cf-2efa8d52ebaf@gmail.com>
Message-ID: <de5080a3-c4a7-492f-92c1-cbcfc80d471d@rock-chips.com>

Hi Johan,

On 12/20/23 19:58, Johan Jonker wrote:
> 
> 
> On 12/20/23 11:33, Andy Yan wrote:
>> From: Andy Yan <andy.yan at rock-chips.com>
>>
>> When try to run rk3036 kylin board with mainline,
>> I found the emac ethernet probe failed:
>>
>> [    2.324583] loop: module loaded
>> [    2.328435] SPI driver spidev has no spi_device_id for rockchip,spidev
>> [    2.338688] tun: Universal TUN/TAP device driver, 1.6
>> [    2.345397] rockchip_emac 10200000.ethernet: no regulator found
>> [    2.351892] rockchip_emac 10200000.ethernet: ARC EMAC detected with id: 0x7fd02
>> [    2.359331] rockchip_emac 10200000.ethernet: IRQ is 43
>> [    2.364719] rockchip_emac 10200000.ethernet: MAC address is now e6:58:d6:ec:d9:7c
>> [    2.396993] mdio_bus Synopsys MII Bus: mdio has invalid PHY address
>> [    2.403306] mdio_bus Synopsys MII Bus: scan phy mdio at address 0
>> [    2.508656] rockchip_emac 10200000.ethernet: of_phy_connect() failed
>> [    2.516334] rockchip_emac 10200000.ethernet: failed to probe arc emac (-19)
>>
>> This reverts commit 1dabb74971b3 ("ARM: dts: rockchip: restyle emac nodes")
>> make emac on rk3036 kylin board probe right again:
>> [    1.920385] CAN device driver interface
>> [    1.925499] rockchip_emac 10200000.ethernet: no regulator found
>> [    1.932535] rockchip_emac 10200000.ethernet: ARC EMAC detected with id: 0x7fd02
>> [    1.940735] rockchip_emac 10200000.ethernet: IRQ is 42
>> [    1.946743] rockchip_emac 10200000.ethernet: MAC address is now 96:7d:4f:0a:69:b3
>> [    2.581340] rockchip_emac 10200000.ethernet: connected to Generic PHY phy with id 0xffffc816
>> [    2.592560] e1000e: Intel(R) PRO/1000 Network Driver
>> [    2.598136] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
>>
>> Fixes: 1dabb74971b3 ("ARM: dts: rockchip: restyle emac nodes")
>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>> ---
>>
>>   arch/arm/boot/dts/rockchip/rk3036-evb.dts     | 16 ++++++----------
>>   arch/arm/boot/dts/rockchip/rk3036-kylin.dts   | 16 ++++++----------
>>   arch/arm/boot/dts/rockchip/rk3036.dtsi        |  2 ++
>>   .../boot/dts/rockchip/rk3066a-marsboard.dts   | 17 +++++++----------
>>   .../boot/dts/rockchip/rk3066a-rayeager.dts    | 15 +++++----------
>>   .../boot/dts/rockchip/rk3188-radxarock.dts    | 19 ++++++++-----------
>>   arch/arm/boot/dts/rockchip/rk3xxx.dtsi        |  2 ++
>>   7 files changed, 36 insertions(+), 51 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/rockchip/rk3036-evb.dts b/arch/arm/boot/dts/rockchip/rk3036-evb.dts
>> index becdc0b664bf..94216f870b57 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3036-evb.dts
>> +++ b/arch/arm/boot/dts/rockchip/rk3036-evb.dts
>> @@ -15,20 +15,16 @@ memory at 60000000 {
>>   };
>>   
>>   &emac {
>> -	phy = <&phy0>;
>> -	phy-reset-duration = <10>; /* millisecond */
>> -	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
>>   	pinctrl-names = "default";
>>   	pinctrl-0 = <&emac_xfer>, <&emac_mdio>;
>> -	status = "okay";
>> +	phy = <&phy0>;
>> +	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
>> +	phy-reset-duration = <10>; /* millisecond */
> 
> 
>>   
>> -	mdio {
>> -		#address-cells = <1>;
>> -		#size-cells = <0>;
>> +	status = "okay";
>>   
>> -		phy0: ethernet-phy at 0 {
>> -			reg = <0>;
>> -		};
>> +	phy0: ethernet-phy at 0 {
>> +		reg = <0>;
>>   	};
> 
> Sorry, didn't have the hardware when changing that binding.
> A little bit background info:
> 
> The rk3036 TRM states:
> Management Interface (MDIO) state machine for easy real-time communication with the
> PHY
> 
> A revert of the DT must also match a binding. But...
> Bindings must describe the hardware as close as possible.
> So when the phy is called over the mdio we must add phy as part of a mdio node.(Is that correct? Ask a expert!)
> Somehow the old emac driver doesn't support this sub node setup.
> First request would be have a look to make the driver work as it should.

Because I lack of knowledge about net driver, I am not sure if the mdio is mandatory.
I post this revert also want to have some suggestion from the net expert.
 From some grep:
emac_rockchip is based on arc-emac, but the example of arc_emac does not have a mdio node[0]
thera are also other platforms use the same way[1]

[0] Documentation/devicetree/bindings/net/arc_emac.txt
[1]arch/arm/boot/dts/hisilicon/hisi-x5hd2-dkb.dts


> 
> Johan
> 
>>   };
>>   
>> diff --git a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
>> index 67e1e04139e7..e817eba8c622 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
>> +++ b/arch/arm/boot/dts/rockchip/rk3036-kylin.dts
>> @@ -80,20 +80,16 @@ &acodec {
>>   };
>>   
>>   &emac {
>> -	phy = <&phy0>;
>> -	phy-reset-duration = <10>; /* millisecond */
>> -	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
>>   	pinctrl-names = "default";
>>   	pinctrl-0 = <&emac_xfer>, <&emac_mdio>;
>> -	status = "okay";
>> +	phy = <&phy0>;
>> +	phy-reset-gpios = <&gpio2 RK_PC6 GPIO_ACTIVE_LOW>; /* PHY_RST */
>> +	phy-reset-duration = <10>; /* millisecond */
>>   
>> -	mdio {
>> -		#address-cells = <1>;
>> -		#size-cells = <0>;
>> +	status = "okay";
>>   
>> -		phy0: ethernet-phy at 0 {
>> -			reg = <0>;
>> -		};
>> +	phy0: ethernet-phy at 0 {
>> +		reg = <0>;
>>   	};
>>   };
>>   
>> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> index 78686fc72ce6..e240b89b0b35 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> @@ -228,6 +228,8 @@ emac: ethernet at 10200000 {
>>   		compatible = "rockchip,rk3036-emac";
>>   		reg = <0x10200000 0x4000>;
>>   		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>>   		rockchip,grf = <&grf>;
>>   		clocks = <&cru HCLK_MAC>, <&cru SCLK_MACREF>, <&cru SCLK_MAC>;
>>   		clock-names = "hclk", "macref", "macclk";
>> diff --git a/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts b/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts
>> index f6e8d49a02ef..e3d6f0e81330 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts
>> +++ b/arch/arm/boot/dts/rockchip/rk3066a-marsboard.dts
>> @@ -150,21 +150,18 @@ vcc28_cif: regulator at 12 {
>>   #include "../tps65910.dtsi"
>>   
>>   &emac {
>> +	status = "okay";
>> +
>>   	phy = <&phy0>;
>>   	phy-supply = <&vcc_rmii>;
>> +
>>   	pinctrl-names = "default";
>>   	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>;
>> -	status = "okay";
>> -
>> -	mdio {
>> -		#address-cells = <1>;
>> -		#size-cells = <0>;
>>   
>> -		phy0: ethernet-phy at 0 {
>> -			reg = <0>;
>> -			interrupt-parent = <&gpio1>;
>> -			interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
>> -		};
>> +	phy0: ethernet-phy at 0 {
>> +		reg = <0>;
>> +		interrupt-parent = <&gpio1>;
>> +		interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
>>   	};
>>   };
>>   
>> diff --git a/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts b/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts
>> index 29d8e5bf88f5..096616324c2d 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts
>> +++ b/arch/arm/boot/dts/rockchip/rk3066a-rayeager.dts
>> @@ -142,20 +142,15 @@ &cpu1 {
>>   };
>>   
>>   &emac {
>> -	phy = <&phy0>;
>> -	phy-supply = <&vcc_rmii>;
>>   	pinctrl-names = "default";
>>   	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&rmii_rst>;
>> +	phy = <&phy0>;
>> +	phy-supply = <&vcc_rmii>;
>>   	status = "okay";
>>   
>> -	mdio {
>> -		#address-cells = <1>;
>> -		#size-cells = <0>;
>> -
>> -		phy0: ethernet-phy at 0 {
>> -			reg = <0>;
>> -			reset-gpios = <&gpio1 RK_PD6 GPIO_ACTIVE_LOW>;
>> -		};
>> +	phy0: ethernet-phy at 0 {
>> +		reg = <0>;
>> +		reset-gpios = <&gpio1 RK_PD6 GPIO_ACTIVE_LOW>;
>>   	};
>>   };
>>   
>> diff --git a/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts b/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts
>> index 118deacd38c4..239d2ec37fdc 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts
>> +++ b/arch/arm/boot/dts/rockchip/rk3188-radxarock.dts
>> @@ -126,21 +126,18 @@ vsys: vsys-regulator {
>>   };
>>   
>>   &emac {
>> -	phy = <&phy0>;
>> -	phy-supply = <&vcc_rmii>;
>> +	status = "okay";
>> +
>>   	pinctrl-names = "default";
>>   	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>;
>> -	status = "okay";
>>   
>> -	mdio {
>> -		#address-cells = <1>;
>> -		#size-cells = <0>;
>> +	phy = <&phy0>;
>> +	phy-supply = <&vcc_rmii>;
>>   
>> -		phy0: ethernet-phy at 0 {
>> -			reg = <0>;
>> -			interrupt-parent = <&gpio3>;
>> -			interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
>> -		};
>> +	phy0: ethernet-phy at 0 {
>> +		reg = <0>;
>> +		interrupt-parent = <&gpio3>;
>> +		interrupts = <RK_PD2 IRQ_TYPE_LEVEL_LOW>;
>>   	};
>>   };
>>   
>> diff --git a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
>> index cb4e42ede56a..17e89d30de78 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3xxx.dtsi
>> @@ -193,6 +193,8 @@ emac: ethernet at 10204000 {
>>   		compatible = "snps,arc-emac";
>>   		reg = <0x10204000 0x3c>;
>>   		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>>   
>>   		rockchip,grf = <&grf>;
>>   


From hugues.fruchet at foss.st.com  Thu Dec 21 00:47:21 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Thu, 21 Dec 2023 09:47:21 +0100
Subject: [PATCH v5 3/5] media: hantro: add support for STM32MP25 VENC
In-Reply-To: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
Message-ID: <20231221084723.2152034-4-hugues.fruchet@foss.st.com>

Add support for STM32MP25 VENC video hardware encoder.
Support of JPEG encoding.
VENC has its own reset/clock/irq.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>
---
 drivers/media/platform/verisilicon/Makefile   |   3 +-
 .../media/platform/verisilicon/hantro_drv.c   |   1 +
 .../media/platform/verisilicon/hantro_hw.h    |   1 +
 .../platform/verisilicon/stm32mp25_venc_hw.c  | 115 ++++++++++++++++++
 4 files changed, 119 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c

diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
index 5854e0f0dd32..3bf43fdbedc1 100644
--- a/drivers/media/platform/verisilicon/Makefile
+++ b/drivers/media/platform/verisilicon/Makefile
@@ -41,4 +41,5 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
 		sunxi_vpu_hw.o
 
 hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
-		stm32mp25_vdec_hw.o
+		stm32mp25_vdec_hw.o \
+		stm32mp25_venc_hw.o
diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
index 2db27c333924..4d97a8ac03de 100644
--- a/drivers/media/platform/verisilicon/hantro_drv.c
+++ b/drivers/media/platform/verisilicon/hantro_drv.c
@@ -736,6 +736,7 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_STM32MP25
 	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
+	{ .compatible = "st,stm32mp25-venc", .data = &stm32mp25_venc_variant, },
 #endif
 	{ /* sentinel */ }
 };
diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
index b7eccc1a96fc..70c72e9d11d5 100644
--- a/drivers/media/platform/verisilicon/hantro_hw.h
+++ b/drivers/media/platform/verisilicon/hantro_hw.h
@@ -407,6 +407,7 @@ extern const struct hantro_variant rk3588_vpu981_variant;
 extern const struct hantro_variant sama5d4_vdec_variant;
 extern const struct hantro_variant sunxi_vpu_variant;
 extern const struct hantro_variant stm32mp25_vdec_variant;
+extern const struct hantro_variant stm32mp25_venc_variant;
 
 extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
 extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
diff --git a/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
new file mode 100644
index 000000000000..0ff0f073b922
--- /dev/null
+++ b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * STM32MP25 VENC video encoder driver
+ *
+ * Copyright (C) STMicroelectronics SA 2022
+ * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
+ *          for STMicroelectronics.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/reset.h>
+
+#include "hantro.h"
+#include "hantro_jpeg.h"
+#include "hantro_h1_regs.h"
+
+/*
+ * Supported formats.
+ */
+
+static const struct hantro_fmt stm32mp25_venc_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_YUV420M,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420P,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_NV12M,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420SP,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_YUYV,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUYV422,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_UYVY,
+		.codec_mode = HANTRO_MODE_NONE,
+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_UYVY422,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_JPEG,
+		.codec_mode = HANTRO_MODE_JPEG_ENC,
+		.max_depth = 2,
+		.header_size = JPEG_HEADER_SIZE,
+		.frmsize = {
+			.min_width = 96,
+			.max_width = FMT_4K_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = 96,
+			.max_height = FMT_4K_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+};
+
+static irqreturn_t stm32mp25_venc_irq(int irq, void *dev_id)
+{
+	struct hantro_dev *vpu = dev_id;
+	enum vb2_buffer_state state;
+	u32 status;
+
+	status = vepu_read(vpu, H1_REG_INTERRUPT);
+	state = (status & H1_REG_INTERRUPT_FRAME_RDY) ?
+		VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
+
+	vepu_write(vpu, H1_REG_INTERRUPT_BIT, H1_REG_INTERRUPT);
+
+	hantro_irq_done(vpu, state);
+
+	return IRQ_HANDLED;
+}
+
+static void stm32mp25_venc_reset(struct hantro_ctx *ctx)
+{
+}
+
+/*
+ * Supported codec ops.
+ */
+
+static const struct hantro_codec_ops stm32mp25_venc_codec_ops[] = {
+	[HANTRO_MODE_JPEG_ENC] = {
+		.run = hantro_h1_jpeg_enc_run,
+		.reset = stm32mp25_venc_reset,
+		.done = hantro_h1_jpeg_enc_done,
+	},
+};
+
+/*
+ * Variants.
+ */
+
+static const struct hantro_irq stm32mp25_venc_irqs[] = {
+	{ "venc", stm32mp25_venc_irq },
+};
+
+static const char * const stm32mp25_venc_clk_names[] = {
+	"venc-clk"
+};
+
+const struct hantro_variant stm32mp25_venc_variant = {
+	.enc_fmts = stm32mp25_venc_fmts,
+	.num_enc_fmts = ARRAY_SIZE(stm32mp25_venc_fmts),
+	.codec = HANTRO_JPEG_ENCODER,
+	.codec_ops = stm32mp25_venc_codec_ops,
+	.irqs = stm32mp25_venc_irqs,
+	.num_irqs = ARRAY_SIZE(stm32mp25_venc_irqs),
+	.clk_names = stm32mp25_venc_clk_names,
+	.num_clocks = ARRAY_SIZE(stm32mp25_venc_clk_names)
+};
+
-- 
2.25.1



From hugues.fruchet at foss.st.com  Thu Dec 21 00:47:20 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Thu, 21 Dec 2023 09:47:20 +0100
Subject: [PATCH v5 2/5] media: hantro: add support for STM32MP25 VDEC
In-Reply-To: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
Message-ID: <20231221084723.2152034-3-hugues.fruchet@foss.st.com>

Add support for STM32MP25 VDEC video hardware decoder.
Support of H264/VP8 decoding.
No post-processor support.
VDEC has its own reset/clock/irq.

Sucessfully tested up to full HD.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>
---
 drivers/media/platform/verisilicon/Kconfig    | 14 ++-
 drivers/media/platform/verisilicon/Makefile   |  3 +
 .../media/platform/verisilicon/hantro_drv.c   |  3 +
 .../media/platform/verisilicon/hantro_hw.h    |  1 +
 .../platform/verisilicon/stm32mp25_vdec_hw.c  | 92 +++++++++++++++++++
 5 files changed, 110 insertions(+), 3 deletions(-)
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c

diff --git a/drivers/media/platform/verisilicon/Kconfig b/drivers/media/platform/verisilicon/Kconfig
index e65b836b9d78..7642ff9cf96c 100644
--- a/drivers/media/platform/verisilicon/Kconfig
+++ b/drivers/media/platform/verisilicon/Kconfig
@@ -4,7 +4,7 @@ comment "Verisilicon media platform drivers"
 
 config VIDEO_HANTRO
 	tristate "Hantro VPU driver"
-	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || COMPILE_TEST
+	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || ARCH_STM32 || COMPILE_TEST
 	depends on V4L_MEM2MEM_DRIVERS
 	depends on VIDEO_DEV
 	select MEDIA_CONTROLLER
@@ -16,8 +16,8 @@ config VIDEO_HANTRO
 	select V4L2_VP9
 	help
 	  Support for the Hantro IP based Video Processing Units present on
-	  Rockchip and NXP i.MX8M SoCs, which accelerate video and image
-	  encoding and decoding.
+	  Rockchip, NXP i.MX8M and STM32MP25 SoCs, which accelerate video
+	  and image encoding and decoding.
 	  To compile this driver as a module, choose M here: the module
 	  will be called hantro-vpu.
 
@@ -52,3 +52,11 @@ config VIDEO_HANTRO_SUNXI
 	default y
 	help
 	  Enable support for H6 SoC.
+
+config VIDEO_HANTRO_STM32MP25
+	bool "Hantro STM32MP25 support"
+	depends on VIDEO_HANTRO
+	depends on ARCH_STM32 || COMPILE_TEST
+	default y
+	help
+	  Enable support for STM32MP25 SoCs.
diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
index 6ad2ef885920..5854e0f0dd32 100644
--- a/drivers/media/platform/verisilicon/Makefile
+++ b/drivers/media/platform/verisilicon/Makefile
@@ -39,3 +39,6 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_ROCKCHIP) += \
 
 hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
 		sunxi_vpu_hw.o
+
+hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
+		stm32mp25_vdec_hw.o
diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
index a9fa05ac56a9..2db27c333924 100644
--- a/drivers/media/platform/verisilicon/hantro_drv.c
+++ b/drivers/media/platform/verisilicon/hantro_drv.c
@@ -733,6 +733,9 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_SUNXI
 	{ .compatible = "allwinner,sun50i-h6-vpu-g2", .data = &sunxi_vpu_variant, },
+#endif
+#ifdef CONFIG_VIDEO_HANTRO_STM32MP25
+	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
 #endif
 	{ /* sentinel */ }
 };
diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
index 7f33f7b07ce4..b7eccc1a96fc 100644
--- a/drivers/media/platform/verisilicon/hantro_hw.h
+++ b/drivers/media/platform/verisilicon/hantro_hw.h
@@ -406,6 +406,7 @@ extern const struct hantro_variant rk3568_vpu_variant;
 extern const struct hantro_variant rk3588_vpu981_variant;
 extern const struct hantro_variant sama5d4_vdec_variant;
 extern const struct hantro_variant sunxi_vpu_variant;
+extern const struct hantro_variant stm32mp25_vdec_variant;
 
 extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
 extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
diff --git a/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
new file mode 100644
index 000000000000..aa8b0f751390
--- /dev/null
+++ b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * STM32MP25 VDEC video decoder driver
+ *
+ * Copyright (C) STMicroelectronics SA 2022
+ * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
+ *          for STMicroelectronics.
+ *
+ */
+
+#include "hantro.h"
+
+/*
+ * Supported formats.
+ */
+
+static const struct hantro_fmt stm32mp25_vdec_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_NV12,
+		.codec_mode = HANTRO_MODE_NONE,
+		.frmsize = {
+			.min_width = FMT_MIN_WIDTH,
+			.max_width = FMT_FHD_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = FMT_MIN_HEIGHT,
+			.max_height = FMT_FHD_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_VP8_FRAME,
+		.codec_mode = HANTRO_MODE_VP8_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = FMT_MIN_WIDTH,
+			.max_width = FMT_FHD_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = FMT_MIN_HEIGHT,
+			.max_height = FMT_FHD_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_H264_SLICE,
+		.codec_mode = HANTRO_MODE_H264_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = FMT_MIN_WIDTH,
+			.max_width = FMT_FHD_WIDTH,
+			.step_width = MB_DIM,
+			.min_height = FMT_MIN_HEIGHT,
+			.max_height = FMT_FHD_HEIGHT,
+			.step_height = MB_DIM,
+		},
+	},
+};
+
+/*
+ * Supported codec ops.
+ */
+
+static const struct hantro_codec_ops stm32mp25_vdec_codec_ops[] = {
+	[HANTRO_MODE_VP8_DEC] = {
+		.run = hantro_g1_vp8_dec_run,
+		.reset = hantro_g1_reset,
+		.init = hantro_vp8_dec_init,
+		.exit = hantro_vp8_dec_exit,
+	},
+	[HANTRO_MODE_H264_DEC] = {
+		.run = hantro_g1_h264_dec_run,
+		.reset = hantro_g1_reset,
+		.init = hantro_h264_dec_init,
+		.exit = hantro_h264_dec_exit,
+	},
+};
+
+static const struct hantro_irq stm32mp25_irqs[] = {
+	{ "vdec", hantro_g1_irq },
+};
+
+static const char * const stm32mp25_clk_names[] = { "vdec-clk" };
+
+const struct hantro_variant stm32mp25_vdec_variant = {
+	.dec_fmts = stm32mp25_vdec_fmts,
+	.num_dec_fmts = ARRAY_SIZE(stm32mp25_vdec_fmts),
+	.codec = HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
+	.codec_ops = stm32mp25_vdec_codec_ops,
+	.irqs = stm32mp25_irqs,
+	.num_irqs = ARRAY_SIZE(stm32mp25_irqs),
+	.clk_names = stm32mp25_clk_names,
+	.num_clocks = ARRAY_SIZE(stm32mp25_clk_names),
+};
-- 
2.25.1



From hugues.fruchet at foss.st.com  Thu Dec 21 00:47:22 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Thu, 21 Dec 2023 09:47:22 +0100
Subject: [PATCH v5 4/5] arm64: dts: st: add video decoder support to stm32mp255
In-Reply-To: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
Message-ID: <20231221084723.2152034-5-hugues.fruchet@foss.st.com>

Add VDEC hardware video decoder support to STM32MP255.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi |  6 ++++++
 arch/arm64/boot/dts/st/stm32mp255.dtsi | 10 ++++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 96859d098ef8..8fc7e9199499 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -52,6 +52,12 @@ ck_icn_ls_mcu: ck-icn-ls-mcu {
 			compatible = "fixed-clock";
 			clock-frequency = <200000000>;
 		};
+
+		ck_icn_p_vdec: ck-icn-p-vdec {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <200000000>;
+		};
 	};
 
 	firmware {
diff --git a/arch/arm64/boot/dts/st/stm32mp255.dtsi b/arch/arm64/boot/dts/st/stm32mp255.dtsi
index e6fa596211f5..aea5096dac3c 100644
--- a/arch/arm64/boot/dts/st/stm32mp255.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp255.dtsi
@@ -6,4 +6,14 @@
 #include "stm32mp253.dtsi"
 
 / {
+	soc at 0 {
+		rifsc: rifsc-bus at 42080000 {
+			vdec: vdec at 480d0000 {
+				compatible = "st,stm32mp25-vdec";
+				reg = <0x480d0000 0x3c8>;
+				interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ck_icn_p_vdec>;
+			};
+		};
+	};
 };
-- 
2.25.1



From hugues.fruchet at foss.st.com  Thu Dec 21 00:47:19 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Thu, 21 Dec 2023 09:47:19 +0100
Subject: [PATCH v5 1/5] dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
In-Reply-To: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
Message-ID: <20231221084723.2152034-2-hugues.fruchet@foss.st.com>

Add STM32MP25 VDEC video decoder & VENC video encoder bindings.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 .../media/st,stm32mp25-video-codec.yaml       | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml

diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
new file mode 100644
index 000000000000..e167e3b1bec3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/st,stm32mp25-video-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 VDEC video decoder & VENC video encoder
+
+maintainers:
+  - Hugues Fruchet <hugues.fruchet at foss.st.com>
+
+description:
+  The STMicroelectronics STM32MP25 SOCs embeds a VDEC video hardware
+  decoder peripheral based on Verisilicon VC8000NanoD IP (former Hantro G1)
+  and a VENC video hardware encoder peripheral based on Verisilicon
+  VC8000NanoE IP (former Hantro H1).
+
+properties:
+  compatible:
+    enum:
+      - st,stm32mp25-vdec
+      - st,stm32mp25-venc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    video-codec at 580d0000 {
+        compatible = "st,stm32mp25-vdec";
+        reg = <0x580d0000 0x3c8>;
+        interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&ck_icn_p_vdec>;
+    };
-- 
2.25.1



From hugues.fruchet at foss.st.com  Thu Dec 21 00:47:18 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Thu, 21 Dec 2023 09:47:18 +0100
Subject: [PATCH v5 0/5] Add support for video hardware codec of STMicroelectronics STM32 SoC series
Message-ID: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>

This patchset introduces support for VDEC video hardware decoder
and VENC video hardware encoder of STMicroelectronics STM32MP25
SoC series.

This initial support implements H264 decoding, VP8 decoding and
JPEG encoding.

This has been tested on STM32MP257F-EV1 evaluation board.

===========
= history =
===========
version 5:
   - Precise that video decoding as been successfully tested up to full HD
   - Add Nicolas Dufresne reviewed-by

version 4:
   - Fix comments from Nicolas about dropping encoder raw steps

version 3:
   - Fix remarks from Krzysztof Kozlowski:
    - drop "items", we keep simple enum in such case
    - drop second example - it is the same as the first
   - Drop unused node labels as suggested by Conor Dooley
   - Revisit min/max resolutions as suggested by Nicolas Dufresne

version 2:
   - Fix remarks from Krzysztof Kozlowski on v1:
    - single video-codec binding for both VDEC/VENC
    - get rid of "-names"
    - use of generic node name "video-codec"

version 1:
  - Initial submission

Hugues Fruchet (5):
  dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
  media: hantro: add support for STM32MP25 VDEC
  media: hantro: add support for STM32MP25 VENC
  arm64: dts: st: add video decoder support to stm32mp255
  arm64: dts: st: add video encoder support to stm32mp255

 .../media/st,stm32mp25-video-codec.yaml       |  50 ++++++++
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  12 ++
 arch/arm64/boot/dts/st/stm32mp255.dtsi        |  17 +++
 drivers/media/platform/verisilicon/Kconfig    |  14 ++-
 drivers/media/platform/verisilicon/Makefile   |   4 +
 .../media/platform/verisilicon/hantro_drv.c   |   4 +
 .../media/platform/verisilicon/hantro_hw.h    |   2 +
 .../platform/verisilicon/stm32mp25_vdec_hw.c  |  92 ++++++++++++++
 .../platform/verisilicon/stm32mp25_venc_hw.c  | 115 ++++++++++++++++++
 9 files changed, 307 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
 create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c

-- 
2.25.1



From hugues.fruchet at foss.st.com  Thu Dec 21 00:47:23 2023
From: hugues.fruchet at foss.st.com (Hugues Fruchet)
Date: Thu, 21 Dec 2023 09:47:23 +0100
Subject: [PATCH v5 5/5] arm64: dts: st: add video encoder support to stm32mp255
In-Reply-To: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
Message-ID: <20231221084723.2152034-6-hugues.fruchet@foss.st.com>

Add VENC hardware video encoder support to STM32MP255.

Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 6 ++++++
 arch/arm64/boot/dts/st/stm32mp255.dtsi | 7 +++++++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 8fc7e9199499..5dd4f3580a60 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -58,6 +58,12 @@ ck_icn_p_vdec: ck-icn-p-vdec {
 			compatible = "fixed-clock";
 			clock-frequency = <200000000>;
 		};
+
+		ck_icn_p_venc: ck-icn-p-venc {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <200000000>;
+		};
 	};
 
 	firmware {
diff --git a/arch/arm64/boot/dts/st/stm32mp255.dtsi b/arch/arm64/boot/dts/st/stm32mp255.dtsi
index aea5096dac3c..17f197c5b22b 100644
--- a/arch/arm64/boot/dts/st/stm32mp255.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp255.dtsi
@@ -14,6 +14,13 @@ vdec: vdec at 480d0000 {
 				interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&ck_icn_p_vdec>;
 			};
+
+			venc: venc at 480e0000 {
+				compatible = "st,stm32mp25-venc";
+				reg = <0x480e0000 0x800>;
+				interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ck_icn_ls_mcu>;
+			};
 		};
 	};
 };
-- 
2.25.1



From Yu-chang.Lee at mediatek.com  Thu Dec 21 00:29:38 2023
From: Yu-chang.Lee at mediatek.com (=?utf-8?B?WXUtY2hhbmcgTGVlICjmnY7nprnnkosp?=)
Date: Thu, 21 Dec 2023 08:29:38 +0000
Subject: Discuss Mediatek Power Domain Driver Support Mulitle Smi Clamp
 Protection
In-Reply-To: <b4fa9b7f-512f-4a34-884a-a99a3b035d34@collabora.com>
References: <a3aaf3180fdb3da117132089bd160ba4d5cebc17.camel@mediatek.com>
	 <b4fa9b7f-512f-4a34-884a-a99a3b035d34@collabora.com>
Message-ID: <f8150ce2859bc8d22d2fa7cbc671bf2d43d4a86d.camel@mediatek.com>

On Wed, 2023-12-20 at 14:11 +0100, AngeloGioacchino Del Regno wrote:
> Il 20/12/23 10:36, Yu-chang Lee (???) ha scritto:
> > Dear Markus, Matthias, Angelo:
> > 
> > I am writing to seek your expertise and advice regarding the
> > revision
> > of the Mediatek power domain driver for the MT8188 platform.
> > Specifically, the display power domain requires multiple SMI clamp
> > protections (refer to [1] in mt8188.dts "MT8188_POWER_DOMAIN_DIP"
> > "mediatek,smi"). However, the current version on the main branch,
> > which
> > has already merged SMI and infra bus protection (mainly [2]),
> > complicates the mapping of individual SMIs to their respective bus
> > protections.
> > 
> > While not a complete solution, I believe the patch in [3] may
> > better
> > illustrate my intentions.
> > 
> > Markus has provided some thoughts and recommendations that I want
> > to
> > bring forward, hoping to gain further direction based on your
> > expertise.
> > 
> > 1.My initial thought is to revert the changes made in [2], which
> > separated the SMI infra bus protection operations. This approach
> > would
> > simplify the mapping of multiple SMIs to bus protections by their
> > order
> > in the DTS. However, reverting to an older version may not be
> > desired.
> > 
> 
> Relying on the order of bus protections in DTS can be flaky and prone
> to generate
> future mistakes; remember that whatever we send upstream is something
> that not
> only has to be working, clean, solid and reliable, but we should also
> take care
> of avoiding future mistakes that could happen when somebody from the
> community, or
> other MediaTek engineers, implement new platforms.

> Reverting commits is not prohibited as long as we're not breaking
> support for any
> platform (so, as long as we're not removing features), but still, I
> don't think
> that this is the best solution, honestly.
> 
> Besides, I don't get why the order of SMI phandles is important, can
> you please
> explain why?

I apologize for the confusion, The bp_cfg order in mt8188-pm-domain.h
is important because the order of bus protection is depned on it.
However smi clamp protection should be done before infra one. So rely
on this is also a little shaky I think. Also it will take some overhead
to loop through bp_cfg, mixed with infra and smi, to find the correct
name smi to do clamp protection.

That why the first approach seems straight forward to me because it
separate smi and infra. And we can do different protection with them.

> 
> > 2.The second approach, suggested by Markus, is to introduce
> > "mediatek,smi-names" and convert "mediatek,smi" to an array of
> > phandles. We could add a new field to the struct
> > scpsys_bus_prot_data,
> > such as const char *smi_name, which could be NULL (for device trees
> > with only a single property). This way, we can use the smi-names to
> > specify the desired SMI. While this method retains the current code
> > structure, the implementation may not be as straightforward.
> > 
> 
> To be completely honest, neither of the two approaches are state of
> the art,
> but the mediatek,smi-names one is better than the first, granted that
> we
> really need to guarantee that the SMIs are ordered.
> 
> But again, my question is: why should those be ordered?
> Can't we clamp IMG1 before clamping IMG0?
> 
We can clamp IMG1 before clamping IMG0, I am more concerned with the
order between infra and smi rather than the order between smi. And I
think current structure mixed smi and infra may also introduce
misunderstanding in the future. Maybe separate the bp_cfg and match the
smi name with smi's bus protection step could be a direction to fix the
problem?

Thanks for your timely feedback!

Best Regards,
yu-chang.lee


> Cheers,
> Angelo
> 
> > Attempting to resolve this issue, I find the first option easier
> > and
> > more direct. However, I would greatly appreciate hearing the
> > thoughts
> > of experts on this matter before proceeding with upstreaming.
> > 
> > I look forward to your valued response.
> > 
> > Cheers!
> > Best Regards,
> > Yu-chang.lee
> > 
> > [1]:
> > 
https://urldefense.com/v3/__https://chromium.googlesource.com/chromiumos/third_party/kernel/*/87222665c8f974e4ff9dca408cedf6b540a9e770__;Kw!!CTRNKA9wMg0ARbw!kDNdDHejJnDRc6HgYp1-LOvU7Ij4m23UJizlQOGgaJET_rH1jNegg7tYmhOf8XkHVZF_dqG94-kHyhzX6nZE_6aGNBv2CSyx6g$
> >  
> > [2]:
> > 
https://lore.kernel.org/all/20230918093751.1188668-6-msp at baylibre.com/
> > [3]:
> > 
https://urldefense.com/v3/__https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/*/5098295__;Kw!!CTRNKA9wMg0ARbw!kDNdDHejJnDRc6HgYp1-LOvU7Ij4m23UJizlQOGgaJET_rH1jNegg7tYmhOf8XkHVZF_dqG94-kHyhzX6nZE_6aGNBvmL2Hiaw$
> >  
> 
> 
> 

From quic_snehshah at quicinc.com  Thu Dec 21 00:53:57 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Thu, 21 Dec 2023 14:23:57 +0530
Subject: [PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support for
 2.5G SGMII
In-Reply-To: <wvzhz4fmtheculsiag4t2pn2kaggyle2mzhvawbs4m5isvqjto@lmaonvq3c3e7>
References: <20231218071118.21879-1-quic_snehshah@quicinc.com>
 <4zbf5fmijxnajk7kygcjrcusf6tdnuzsqqboh23nr6f3rb3c4g@qkfofhq7jmv6>
 <8b80ab09-8444-4c3d-83b0-c7dbf5e58658@quicinc.com>
 <wvzhz4fmtheculsiag4t2pn2kaggyle2mzhvawbs4m5isvqjto@lmaonvq3c3e7>
Message-ID: <8f94489d-5f0e-4166-a14e-4959098a5c80@quicinc.com>



On 12/20/2023 9:29 PM, Andrew Halaney wrote:
> On Wed, Dec 20, 2023 at 01:02:45PM +0530, Sneh Shah wrote:
>>
>>
>> On 12/18/2023 9:50 PM, Andrew Halaney wrote:
>>> On Mon, Dec 18, 2023 at 12:41:18PM +0530, Sneh Shah wrote:
>>>> Serdes phy needs to operate at 2500 mode for 2.5G speed and 1000
>>>> mode for 1G/100M/10M speed.
>>>> Added changes to configure serdes phy and mac based on link speed.
>>>>
>>>> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
>>>> ---
>>>>  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 31 +++++++++++++++++--
>>>>  1 file changed, 29 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>>>> index d3bf42d0fceb..b3a28dc19161 100644
>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
>>>> @@ -21,6 +21,7 @@
>>>>  #define RGMII_IO_MACRO_CONFIG2		0x1C
>>>>  #define RGMII_IO_MACRO_DEBUG1		0x20
>>>>  #define EMAC_SYSTEM_LOW_POWER_DEBUG	0x28
>>>> +#define ETHQOS_MAC_AN_CTRL		0xE0
>>>>  
>>>>  /* RGMII_IO_MACRO_CONFIG fields */
>>>>  #define RGMII_CONFIG_FUNC_CLK_EN		BIT(30)
>>>> @@ -78,6 +79,10 @@
>>>>  #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
>>>>  #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
>>>>  
>>>> +/*ETHQOS_MAC_AN_CTRL bits */
>>>> +#define ETHQOS_MAC_AN_CTRL_RAN			BIT(9)
>>>> +#define ETHQOS_MAC_AN_CTRL_ANE			BIT(12)
>>>> +
>>>
>>> nit: space please add a space before ETHQOS_MAC_AN_CTRL
>>>
>> will take care of this in next patch
>>
>>>>  struct ethqos_emac_por {
>>>>  	unsigned int offset;
>>>>  	unsigned int value;
>>>> @@ -109,6 +114,7 @@ struct qcom_ethqos {
>>>>  	unsigned int num_por;
>>>>  	bool rgmii_config_loopback_en;
>>>>  	bool has_emac_ge_3;
>>>> +	unsigned int serdes_speed;
> 
> Another nit as I look closer: I think this should be grouped by phy_mode
> etc just for readability.
Didn't get this. can you please elaborate more?
> 
>>>>  };
>>>>  
>>>>  static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
>>>> @@ -600,27 +606,47 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
>>>>  
>>>>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
>>>>  {
>>>> -	int val;
>>>> -
>>>> +	int val, mac_an_value;
>>>>  	val = readl(ethqos->mac_base + MAC_CTRL_REG);
>>>> +	mac_an_value = readl(ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
>>>>  
>>>>  	switch (ethqos->speed) {
>>>> +	case SPEED_2500:
>>>> +		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
>>>> +		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>>>> +			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>>>> +			      RGMII_IO_MACRO_CONFIG2);
>>>> +		if (ethqos->serdes_speed != SPEED_2500)
>>>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>>>> +		mac_an_value &= ~ETHQOS_MAC_AN_CTRL_ANE;
>>>> +		break;
>>>>  	case SPEED_1000:
>>>>  		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
>>>>  		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>>>>  			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
>>>>  			      RGMII_IO_MACRO_CONFIG2);
>>>> +		if (ethqos->serdes_speed != SPEED_1000)
>>>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>>>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>>>>  		break;
>>>>  	case SPEED_100:
>>>>  		val |= ETHQOS_MAC_CTRL_PORT_SEL | ETHQOS_MAC_CTRL_SPEED_MODE;
>>>> +		if (ethqos->serdes_speed != SPEED_1000)
>>>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>>>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>>>>  		break;
>>>>  	case SPEED_10:
>>>>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
>>>>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
>>>> +		if (ethqos->serdes_speed != SPEED_1000)
>>>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
>>>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
>>>>  		break;
>>>>  	}
>>>>  
>>>>  	writel(val, ethqos->mac_base + MAC_CTRL_REG);
>>>> +	writel(mac_an_value, ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
>>>> +	ethqos->serdes_speed = ethqos->speed;
>>>
>>> I see these bits are generic and there's some functions in stmmac_pcs.h
>>> that muck with these...
>>>
>>> Could you help me understand if this really should be Qualcomm specific,
>>> or if this is something that should be considered for the more core bits
>>> of the driver? I feel in either case we should take advantage of the
>>> common definitions in that file if possible.
>>>
>> we do have function dwmac_ctrl_ane in core driver which updates same registers. However, it does not have the option to reset ANE bit, it can only set bits. For SPEED_2500 we need to reset ANE bit. Hence I am adding it here. Not sure if we can extend dwmac_ctrl_ane function to reset bits as well.
> 
> I'd evaluate if you can update that function to clear the ANE bit when
> the ane boolean is false. From the usage I see I feel that makes sense,
> but correct me if you think I'm wrong.
> At the very least let's use the defines from there, and possibly add a
> new function if clearing is not acceptable in dwmac_ctrl_ane().
> 
> Stepping back, I was asking in general is the need to muck with ANE here
> is a Qualcomm specific problem, or is that a generic thing that should be
> handled in the core (and the phy_set_speed() bit stay here)? i.e. would
> any dwmac5 based IP need to do something like this for SPEED_2500?
I think disabling ANE for SPEED_2500 is generic not specific to qualcomm. Even in dwxgmac2 versions also we need to disable ANE for SPEED_2500. Autoneg clause 37 stadard doesn't support 2500 speed. So we need to disable autoneg for speed 2500

> 
>>>>  
>>>>  	return val;
>>>>  }
>>>> @@ -789,6 +815,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
>>>>  				     "Failed to get serdes phy\n");
>>>>  
>>>>  	ethqos->speed = SPEED_1000;
>>>> +	ethqos->serdes_speed = SPEED_1000;
>>>>  	ethqos_update_link_clk(ethqos, SPEED_1000);
>>>>  	ethqos_set_func_clk_en(ethqos);
>>>>  
>>>> -- 
>>>> 2.17.1
>>>>
>>>
>>
> 


From andrew at lunn.ch  Thu Dec 21 00:53:56 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 21 Dec 2023 09:53:56 +0100
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal
 MDIO bus
In-Reply-To: <20231220173539.59071-1-arinc.unal@arinc9.com>
References: <20231220173539.59071-1-arinc.unal@arinc9.com>
Message-ID: <34b314a6-1bfd-4133-99bd-d03c95729046@lunn.ch>

On Wed, Dec 20, 2023 at 07:35:39PM +0200, Ar?n? ?NAL wrote:
> From: David Bauer <mail at david-bauer.net>
> 
> The MT753x switches provide a switch-internal MDIO bus for the embedded
> PHYs.
> 
> Register a OF sub-node on the switch OF-node for this internal MDIO bus.
> This allows to configure the embedded PHYs using device-tree.
> 
> Signed-off-by: David Bauer <mail at david-bauer.net>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From yi.fang.gan at intel.com  Thu Dec 21 00:51:07 2023
From: yi.fang.gan at intel.com (Gan, Yi Fang)
Date: Thu, 21 Dec 2023 16:51:07 +0800
Subject: [PATCH net v2 0/2] Fix phylink unloadable issue
Message-ID: <20231221085109.2830794-1-yi.fang.gan@intel.com>

Add module_exit_stub() for phylink module.

Changes since v1:
- Introduce a helper macro for module_exit() boilerplate

This series is the combination of following:
v1 with empty phylink_exit():
https://lore.kernel.org/all/20231127101603.807593-1-yi.fang.gan at intel.com/
v1 of module_exit_stub():
https://lore.kernel.org/all/20231212094352.2263283-1-yi.fang.gan at intel.com/

Gan, Yi Fang (2):
  driver.h: add helper macro for module_exit() boilerplate
  net: phylink: Add module_exit_stub()

 drivers/net/phy/phylink.c     |  1 +
 include/linux/device/driver.h | 14 ++++++++++++++
 2 files changed, 15 insertions(+)

-- 
2.34.1



From yi.fang.gan at intel.com  Thu Dec 21 00:51:08 2023
From: yi.fang.gan at intel.com (Gan, Yi Fang)
Date: Thu, 21 Dec 2023 16:51:08 +0800
Subject: [PATCH net v2 1/2] driver.h: add helper macro for module_exit() boilerplate
In-Reply-To: <20231221085109.2830794-1-yi.fang.gan@intel.com>
References: <20231221085109.2830794-1-yi.fang.gan@intel.com>
Message-ID: <20231221085109.2830794-2-yi.fang.gan@intel.com>

For the modules need a module_init() but don't need to do
anything special in module_exit() might need to have an empty
module_exit(). This patch add a new macro module_exit_stub() to
replace the empty module_exit(). The macro is useful to remove
the module_exit() boilerplate.

Cc: <stable at vger.kernel.org> # 6.1+
Suggested-by: Lobakin, Aleksander <aleksander.lobakin at intel.com>
Signed-off-by: Gan, Yi Fang <yi.fang.gan at intel.com>
---
 include/linux/device/driver.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
index 7738f458995f..7d322eef501e 100644
--- a/include/linux/device/driver.h
+++ b/include/linux/device/driver.h
@@ -288,4 +288,18 @@ static int __init __driver##_init(void) \
 } \
 device_initcall(__driver##_init);
 
+/**
+ * module_exit_stub() - Helper macro for drivers that have init but don't
+ * do anything in exit. This eliminates some boilerplate.
+ * Each module may only use this macro once, and calling it replaces
+ * module_exit().
+ *
+ * @__driver: driver name
+ */
+#define module_exit_stub(__driver) \
+static void __exit __driver##_exit(void) \
+{ \
+} \
+module_exit(__driver##_exit)
+
 #endif	/* _DEVICE_DRIVER_H_ */
-- 
2.34.1



From yi.fang.gan at intel.com  Thu Dec 21 00:51:09 2023
From: yi.fang.gan at intel.com (Gan, Yi Fang)
Date: Thu, 21 Dec 2023 16:51:09 +0800
Subject: [PATCH net v2 2/2] net: phylink: Add module_exit_stub()
In-Reply-To: <20231221085109.2830794-1-yi.fang.gan@intel.com>
References: <20231221085109.2830794-1-yi.fang.gan@intel.com>
Message-ID: <20231221085109.2830794-3-yi.fang.gan@intel.com>

In delete_module(), if mod->init callback is defined but mod->exit
callback is not defined, it will assume the module cannot be removed
and return EBUSY. The module_exit() is missing from current phylink
module drive causing failure while unloading it.
Add module_exit_stub() in phylink for the module to be unloadable.

Fixes: eca68a3c7d05 ("net: phylink: pass supported host PHY interface modes to phylib for SFP's PHYs")
Cc: <stable at vger.kernel.org> # 6.1+
Signed-off-by: Gan, Yi Fang <yi.fang.gan at intel.com>
---
 drivers/net/phy/phylink.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 25c19496a336..823c9b43cd92 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -3725,6 +3725,7 @@ static int __init phylink_init(void)
 }
 
 module_init(phylink_init);
+module_exit_stub(phylink);
 
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("phylink models the MAC to optional PHY connection");
-- 
2.34.1



From r-gunasekaran at ti.com  Thu Dec 21 00:56:24 2023
From: r-gunasekaran at ti.com (Ravi Gunasekaran)
Date: Thu, 21 Dec 2023 14:26:24 +0530
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal
 MDIO bus
In-Reply-To: <20231220173539.59071-1-arinc.unal@arinc9.com>
References: <20231220173539.59071-1-arinc.unal@arinc9.com>
Message-ID: <d78949f0-bb03-82ea-b40f-1bb92b41e200@ti.com>



On 12/20/23 11:05 PM, Ar?n? ?NAL wrote:
> From: David Bauer <mail at david-bauer.net>
> 
> The MT753x switches provide a switch-internal MDIO bus for the embedded
> PHYs.
> 
> Register a OF sub-node on the switch OF-node for this internal MDIO bus.
> This allows to configure the embedded PHYs using device-tree.
> 
> Signed-off-by: David Bauer <mail at david-bauer.net>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
> ---
>  drivers/net/dsa/mt7530.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 391c4dbdff42..f8ecc354630b 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -2155,10 +2155,13 @@ mt7530_setup_mdio(struct mt7530_priv *priv)
>  {
>  	struct dsa_switch *ds = priv->ds;
>  	struct device *dev = priv->dev;
> +	struct device_node *np, *mnp;
>  	struct mii_bus *bus;
>  	static int idx;
>  	int ret;
>  
> +	np = priv->dev->of_node;
> +
>  	bus = devm_mdiobus_alloc(dev);
>  	if (!bus)
>  		return -ENOMEM;
> @@ -2177,7 +2180,9 @@ mt7530_setup_mdio(struct mt7530_priv *priv)
>  	if (priv->irq)
>  		mt7530_setup_mdio_irq(priv);
>  
> -	ret = devm_mdiobus_register(dev, bus);
> +	mnp = of_get_child_by_name(np, "mdio");

If the node is not found, then the return value would be NULL.
Though devm_of_mdiobus_register() and of_node_put() take care of NULL references,
other drivers that use devm_of_mdiobus_register() mostly perform a early exit if the node is NULL.


> +	ret = devm_of_mdiobus_register(dev, bus, mnp);
> +	of_node_put(mnp);
>  	if (ret) {
>  		dev_err(dev, "failed to register MDIO bus: %d\n", ret);
>  		if (priv->irq)

-- 
Regards,
Ravi


From mripard at kernel.org  Thu Dec 21 00:58:53 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 21 Dec 2023 09:58:53 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <3E03E913-48E1-49EC-A6C9-EAC1612E65E7@goldelico.com>
References: <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
 <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
 <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>
 <oobcl2kfsuph27er7rflfqvt3lu6athufomxv5chf3uctx4emh@x6rzjtlskhbf>
 <F58855EC-D87D-4747-A363-0E7AA5DB1AEC@goldelico.com>
 <22cny5aumc5wafsrjd3j55zcjbjf2viip64kfbjiqis2grtd6t@wg5dxeuzil6l>
 <3E03E913-48E1-49EC-A6C9-EAC1612E65E7@goldelico.com>
Message-ID: <nzqeqwof44e3nxjz6lsxmxcfh235unbu343br45esxh6vinskp@xvjydpxhvsuk>

On Mon, Dec 18, 2023 at 11:54:47AM +0100, H. Nikolaus Schaller wrote:
> 
> 
> > Am 18.12.2023 um 11:14 schrieb Maxime Ripard <mripard at kernel.org>:
> > 
> > On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
> >> Hi Maxime,
> >> 
> >>> Am 15.12.2023 um 14:33 schrieb Maxime Ripard <mripard at kernel.org>:
> >>> 
> >>>>> 
> >>>>> It's for a separate architecture, with a separate driver, maintained out
> >>>>> of tree by a separate community, with a separate set of requirements as
> >>>>> evidenced by the other thread. And that's all fine in itself, but
> >>>>> there's very little reason to put these two bindings in the same file.
> >>>>> 
> >>>>> We could also turn this around, why is it important that it's in the
> >>>>> same file?
> >>>> 
> >>>> Same vendor. And enough similarity in architectures, even a logical sequence
> >>>> of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
> >>>> (SGX and Rogue seem to be just trade names for their architecture development).
> >>> 
> >>> Again, none of that matters for *where* the binding is stored.
> >> 
> >> So what then speaks against extending the existing bindings file as proposed
> >> here?
> > 
> > I mean, apart from everything you quoted, then sure, nothing speaks
> > against it.
> > 
> >>>> AFAIK bindings should describe hardware and not communities or drivers
> >>>> or who is currently maintaining it. The latter can change, the first not.
> >>> 
> >>> Bindings are supposed to describe hardware indeed. Nothing was ever said
> >>> about where those bindings are supposed to be located.
> >>> 
> >>> There's hundreds of other YAML bindings describing devices of the same
> >>> vendors and different devices from the same generation.
> >> 
> >> Usually SoC seem to be split over multiple files by subsystem. Not by versions
> >> or generations. If the subsystems are similar enough they share the same bindings
> >> doc instead of having one for each generation duplicating a lot of code.
> >> 
> >> Here is a comparable example that combines multiple vendors and generations:
> >> 
> >> Documentation/devicetree/bindings/usb/generic-ehci.yaml
> > 
> > EHCI is a single interface for USB2.0 controllers. It's a standard API,
> > and is made of a single driver that requires minor modifications to deal
> > with multiple devices.
> > 
> > We're very far from the same situation here.
> 
> How far are we really?

There's one binding for one driver. You suggest one binding for two drivers.

> And, it is the purpose of the driver to handle different cases.
> 
> That there are currently two drivers is just a matter of history and
> not a necessity.

Cool, so what you're saying is that your plan is to support those GPUs
upstream in the imagination driver?

I guess we should delay this patch until we see that series then.

> >>> If anything it'll make it easier for you. I'm really not sure why it is
> >>> controversial and you're fighting this so hard.
> >> 
> >> Well, you made it controversial by proposing to split what IMHO belongs together.
> > 
> > No, reviews aren't controversial.
> > The controversy started when you chose
> > to oppose it while you could have just rolled with it.
> 
> Well, you asked
> 
> "I think it would be best to have a separate file for this, img,sgx.yaml
> maybe?"
> 
> and
> 
> "Because it's more convenient?"
> 
> I understood that as an invitation for discussing the pros and cons
> and working out the most convenient solution. And that involves
> playing the devil's advocate which of course is controversial by
> principle.
> 
> Now, IMHO all the pros and cons are on the table and the question is
> who makes a decision how to go.

You haven't listed any pro so far, you're claiming that the one I raise
are irrelevant.

> >> I feel that the original patch is good enough for its purpose and follows
> >> some design pattern that can be deduced from other binding docs.
> > 
> > [citation needed]
> 
> Joke: Documentation/devicetree/bindings/* - I am not aware of a formal analysis of course.
> 
> But see my example for ehci. It follows the pattern I mean. If clocks, regs, interrupts,
> resets, and more properties are (almost) the same, then group them and just differentiate
> by different compatible strings.

Again, EHCI is not something you can compare to. It's a binding to
support a standard interface. You don't have the same interface and your
driver will need to be different.

And more importantly: bindings are meant to describe the hardware
itself. How it's supported in Linux is irrelevant to the discussion.

So, we could have: 10 drivers for the same binding, or 1 driver for 10
bindings. The two notions are orthogonal.

> If necessary use some - if: clauses.
> 
> It is the task of drivers to handle the details.
>
> As my other (maybe more important) comment to this patch did indicate we IMHO can easily
> live with something like
> 
> +      - items:
> +          - enum:
> +              - ti,am62-gpu # IMG AXE GPU model/revision is fully discoverable
> +              - ti,omap3430-gpu # sgx530 Rev 121
> +              - ti,omap3630-gpu # sgx530 Rev 125
> +              - ingenic,jz4780-gpu # sgx540 Rev 130
> +              - ti,omap4430-gpu # sgx540 Rev 120
> +              - allwinner,sun6i-a31-gpu # sgx544 MP2 Rev 115
> +              - ti,omap4470-gpu # sgx544 MP1 Rev 112
> +              - ti,omap5432-gpu # sgx544 MP2 Rev 105
> +              - ti,am5728-gpu # sgx544 MP2 Rev 116
> +              - ti,am6548-gpu # sgx544 MP1 Rev 117
> 
> And leave it to drivers using a table to deduce the generation and
> revision or read it out from the chip. And there can even be different
> drivers handling only a subset of the potential compatibles.
> 
> Then the currently-out-of-tree driver for the sgx5 can be reworked in
> less than half an hour without loosing functionality.

Again, you're making it harder than it needs to be for no particular
reason other than the potential file name clash that can be addressed.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231221/cc676a4d/attachment.sig>

From tudor.ambarus at linaro.org  Thu Dec 21 01:00:45 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 21 Dec 2023 09:00:45 +0000
Subject: [PATCH 1/2] dt-bindings: clock: gs101: rename cmu_misc clock-names
Message-ID: <20231221090046.1486195-1-tudor.ambarus@linaro.org>

'bus' and 'ip' are sufficient because naming is local to the module.
As the bindings have not made a release yet, rename the cmu_misc
clock-names.

Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
Suggested-by: Rob Herring <robh at kernel.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 .../devicetree/bindings/clock/google,gs101-clock.yaml         | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
index 3eebc03a309b..ca7fdada3ff2 100644
--- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -85,8 +85,8 @@ allOf:
 
         clock-names:
           items:
-            - const: dout_cmu_misc_bus
-            - const: dout_cmu_misc_sss
+            - const: bus
+            - const: sss
 
 additionalProperties: false
 
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 21 01:00:46 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 21 Dec 2023 09:00:46 +0000
Subject: [PATCH 2/2] arm64: dts: exynos: gs101: comply with the new cmu_misc clock names
In-Reply-To: <20231221090046.1486195-1-tudor.ambarus@linaro.org>
References: <20231221090046.1486195-1-tudor.ambarus@linaro.org>
Message-ID: <20231221090046.1486195-2-tudor.ambarus@linaro.org>

The cmu_misc clock-names were renamed to just "bus" and "sss" because
naming is local to the module, so cmu_misc is implied. As the bindings
and the device tree have not made a release yet, comply with the
renamed clocks.

Suggested-by: Rob Herring <robh at kernel.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 9747cb3fa03a..d838e3a7af6e 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -289,7 +289,7 @@ cmu_misc: clock-controller at 10010000 {
 			#clock-cells = <1>;
 			clocks = <&cmu_top CLK_DOUT_CMU_MISC_BUS>,
 				 <&cmu_top CLK_DOUT_CMU_MISC_SSS>;
-			clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
+			clock-names = "bus", "sss";
 		};
 
 		watchdog_cl0: watchdog at 10060000 {
-- 
2.43.0.472.g3155946c3a-goog



From mripard at kernel.org  Thu Dec 21 01:02:54 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 21 Dec 2023 10:02:54 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <a3feaf42-17fb-46e5-bbb0-3ffc4ad40bfd@ti.com>
References: <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
 <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
 <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>
 <oobcl2kfsuph27er7rflfqvt3lu6athufomxv5chf3uctx4emh@x6rzjtlskhbf>
 <F58855EC-D87D-4747-A363-0E7AA5DB1AEC@goldelico.com>
 <22cny5aumc5wafsrjd3j55zcjbjf2viip64kfbjiqis2grtd6t@wg5dxeuzil6l>
 <3E03E913-48E1-49EC-A6C9-EAC1612E65E7@goldelico.com>
 <a3feaf42-17fb-46e5-bbb0-3ffc4ad40bfd@ti.com>
Message-ID: <3dggaesvunebogkqvclz4imruhynrftkhsvmndm75vfccqwpa6@3zp3dgzpzta6>

On Tue, Dec 19, 2023 at 11:19:49AM -0600, Andrew Davis wrote:
> On 12/18/23 4:54 AM, H. Nikolaus Schaller wrote:
> > 
> > 
> > > Am 18.12.2023 um 11:14 schrieb Maxime Ripard <mripard at kernel.org>:
> > > 
> > > On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
> > > > Hi Maxime,
> > > > 
> > > > > Am 15.12.2023 um 14:33 schrieb Maxime Ripard <mripard at kernel.org>:
> > > > > 
> > > > > > > 
> > > > > > > It's for a separate architecture, with a separate driver, maintained out
> > > > > > > of tree by a separate community, with a separate set of requirements as
> > > > > > > evidenced by the other thread. And that's all fine in itself, but
> > > > > > > there's very little reason to put these two bindings in the same file.
> > > > > > > 
> > > > > > > We could also turn this around, why is it important that it's in the
> > > > > > > same file?
> > > > > > 
> > > > > > Same vendor. And enough similarity in architectures, even a logical sequence
> > > > > > of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
> > > > > > (SGX and Rogue seem to be just trade names for their architecture development).
> > > > > 
> > > > > Again, none of that matters for *where* the binding is stored.
> > > > 
> > > > So what then speaks against extending the existing bindings file as proposed
> > > > here?
> > > 
> > > I mean, apart from everything you quoted, then sure, nothing speaks
> > > against it.
> > > 
> > > > > > AFAIK bindings should describe hardware and not communities or drivers
> > > > > > or who is currently maintaining it. The latter can change, the first not.
> > > > > 
> > > > > Bindings are supposed to describe hardware indeed. Nothing was ever said
> > > > > about where those bindings are supposed to be located.
> > > > > 
> > > > > There's hundreds of other YAML bindings describing devices of the same
> > > > > vendors and different devices from the same generation.
> > > > 
> > > > Usually SoC seem to be split over multiple files by subsystem. Not by versions
> > > > or generations. If the subsystems are similar enough they share the same bindings
> > > > doc instead of having one for each generation duplicating a lot of code.
> > > > 
> > > > Here is a comparable example that combines multiple vendors and generations:
> > > > 
> > > > Documentation/devicetree/bindings/usb/generic-ehci.yaml
> > > 
> > > EHCI is a single interface for USB2.0 controllers. It's a standard API,
> > > and is made of a single driver that requires minor modifications to deal
> > > with multiple devices.
> > > 
> > > We're very far from the same situation here.
> > 
> > How far are we really? And, it is the purpose of the driver to handle different cases.
> > 
> > That there are currently two drivers is just a matter of history and not a necessity.
> > 
> > > 
> > > > > If anything it'll make it easier for you. I'm really not sure why it is
> > > > > controversial and you're fighting this so hard.
> > > > 
> > > > Well, you made it controversial by proposing to split what IMHO belongs together.
> > > 
> > > No, reviews aren't controversial.
> > > The controversy started when you chose
> > > to oppose it while you could have just rolled with it.
> > 
> > Well, you asked
> > 
> > "I think it would be best to have a separate file for this, img,sgx.yaml
> > maybe?"
> > 
> > and
> > 
> > "Because it's more convenient?"
> > 
> > I understood that as an invitation for discussing the pros and cons and working out the
> > most convenient solution. And that involves playing the devil's advocate which of course
> > is controversial by principle.
> > 
> > Now, IMHO all the pros and cons are on the table and the question is who makes a decision
> > how to go.
> > 
> 
> As much as I would land on the side of same file for both, the answer to this question
> is simple: the maintainer makes the decision :) So I'll respin with separate binding files.
>
> The hidden unaddressed issue here is that by making these bindings separate it implies
> they are not on equal footing (i.e. pre-series6 GPUs are not true "powervr" and so do not
> belong in img,powervr.yaml).

No, not really. As far as I'm concerned, the only unequal footing here
is that one driver is in-tree and the other isn't, but this situation
was handled nicely for Mali GPUs and lima that used to be in the same
situation for example.

The situation is simple, really: bindings are supposed to be backward
compatible, period. If we ever make a change to that binding that isn't,
you will be well within your right to complain because your driver is
now broken.

> So if no one objects I'd also like to do the rename of that
> file as suggested before and have:
> 
> img,powervr-sgx.yaml
> img,powervr-rogue.yaml

Sounds good to me.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231221/5cdc5e95/attachment-0001.sig>

From andrew at lunn.ch  Thu Dec 21 01:06:50 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 21 Dec 2023 10:06:50 +0100
Subject: [PATCH v5 1/3] phy: handle optional regulator for PHY
In-Reply-To: <20231220203537.83479-2-jernej.skrabec@gmail.com>
References: <20231220203537.83479-1-jernej.skrabec@gmail.com>
 <20231220203537.83479-2-jernej.skrabec@gmail.com>
Message-ID: <f729baa5-7986-4841-8cd6-fc4bdc652f75@lunn.ch>

> +static int
> +fwnode_regulator_get_bulk_enabled(struct device *dev,
> +				  struct fwnode_handle *fwnode,
> +				  struct regulator_bulk_data **consumers)
> +{
> +	struct device_node *np;
> +	int ret, reg_cnt;
> +
> +	np = to_of_node(fwnode);
> +	if (!np)
> +		return 0;
> +
> +	reg_cnt = of_regulator_bulk_get_all(dev, np, consumers);
> +	if (reg_cnt < 0) {
> +		ret = reg_cnt;
> +		goto clean_consumers;
> +	}
> +
> +	if (reg_cnt == 0)
> +		return 0;

I've not used regulators much, but i think you can combine these two
into one. Its guaranteed *consumer is NULL if reg_cnt == 0. And
kfree() is happy with a NULL pointer.

> +
> +	ret = regulator_bulk_enable(reg_cnt, *consumers);
> +	if (ret)
> +		goto clean_consumers;

I would expect this to be part of mdio_device_reset(), same as the
GPIO, and reset controller, but first obviously. And parsing DT should
happen in a similar place to parsing the reset GPIO and reset
controller.

	Andrew


From mripard at kernel.org  Thu Dec 21 01:07:03 2023
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 21 Dec 2023 10:07:03 +0100
Subject: [PATCH v2 2/2] drm/rockchip: rk3066_hdmi: drop custom fill_modes
 hook
In-Reply-To: <4aeef6df-2616-0741-00a3-6e45ec63f920@gmail.com>
References: <f86ec29f-194a-800d-0aaf-9e16e551b37d@gmail.com>
 <410b116b-cb63-7ba7-3689-4f0832ab5796@gmail.com>
 <evaq3yfbqf4gchsps2qoojemtii7tmcss24aruiuze5kkzlnhy@mih7rky7viqz>
 <4aeef6df-2616-0741-00a3-6e45ec63f920@gmail.com>
Message-ID: <j2cpes3kyssj6cw34v5z6clef4buzb2j6srvmrniumbn2kptqx@ovf2yvhxlslr>

On Tue, Dec 19, 2023 at 04:40:12PM +0100, Johan Jonker wrote:
> 
> 
> On 12/19/23 13:55, Maxime Ripard wrote:
> > Hi,
> > 
> > On Mon, Dec 18, 2023 at 04:49:06PM +0100, Johan Jonker wrote:
> >> CRTC size validation for the display controller has been added with
> >> Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
> >> hardware capabilities"), so we can drop the custom fill_modes hook.
> >>
> >> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> > 
> 
> > I'm not sure those two are equivalent. CRTC and connectors usually have
> > different requirements and capabilities, and thus different,
> > supplementary, mode_valid/atomic_check implementations.
> 
> Rockchip RK3066 CRTC and connector resolution max_output are equivalent.
> 
> From Rockchip PX2 TRM V1.0.pdf page 17:
> - Video Encoder
>   Maximum frame rate is up to 30fps at 1920x1080
> 
> - Display Interface
>   Support LCD or TFT interfaces up to 1920x1080
> 
> - HDMI TX Interface
>    HDMI version 1.4a, HDCP revision 1.4 and DVI version 1.0 compliant transmitter
>    Supports DTV from 480i to 1080i/p HD resolution, and PC from VGA to UXGA by LCDC0 or LCDC1 in RK PX2

My point is that there's two limits: the CRTC and HDMI controller ones.
You should put the CRTC ones in the CRTC driver, and the HDMI controller
ones in the HDMI controller driver.

If they are equivalent, great, it's going to filter out the same things, but...

> Compared to the drm_helper_probe_single_connector_modes() this function added an extra max_output
> 
> Checked in rockchip_drm_vop.c is:
> https://lore.kernel.org/linux-rockchip/20230216102447.582905-2-s.hauer at pengutronix.de/
> 
> +	if (vop->data->max_output.width && mode->hdisplay > vop->data->max_output.width)
> +		return MODE_BAD_HVALUE;
> +
> +	if (vop->data->max_output.height && mode->vdisplay > vop->data->max_output.height)
> +		return MODE_BAD_VVALUE;
> 
> For RK3066 VOP max_output:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/rockchip_vop_reg.c#n506
> 
> This patch was made with HDMI in mind.
> 
> 	.max_output = { 1920, 1080 },
> 
> This first part was added by Heiko, but not was not part my patch that I submitted:
> -	if (maxX > 1920)
> -		maxX = 1920;
> -	if (maxY > 1080)
> -		maxY = 1080;
> -
> -	return drm_helper_probe_single_connector_modes(connector, maxX, maxY);
> -}
> 
> Original patch:
> https://patchwork.freedesktop.org/patch/msgid/20190330095639.14626-2-jbx6244 at gmail.com
> 
> +static int
> +rk3066_hdmi_probe_single_connector_modes(struct drm_connector *connector,
> +					 uint32_t maxX, uint32_t maxY)
> +{
> +	return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
> +}
> 
> Rockchip RK3066 CRTC and connector resolution max_output are equivalent.

... a user / dev unfamiliar with the SoC won't have to go through that
to figure out how it's handled, it will be obvious.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231221/2d98cb0d/attachment.sig>

From krzysztof.kozlowski at linaro.org  Thu Dec 21 01:08:48 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 10:08:48 +0100
Subject: [PATCH v5 1/5] dt-bindings: media: Document STM32MP25 VDEC & VENC
 video codecs
In-Reply-To: <20231221084723.2152034-2-hugues.fruchet@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <20231221084723.2152034-2-hugues.fruchet@foss.st.com>
Message-ID: <0af254af-5560-4462-a76a-747f4d7fdbf3@linaro.org>

On 21/12/2023 09:47, Hugues Fruchet wrote:
> Add STM32MP25 VDEC video decoder & VENC video encoder bindings.
> 
> Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From gregkh at linuxfoundation.org  Thu Dec 21 01:11:04 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 21 Dec 2023 10:11:04 +0100
Subject: [PATCH net v2 0/2] Fix phylink unloadable issue
In-Reply-To: <20231221085109.2830794-1-yi.fang.gan@intel.com>
References: <20231221085109.2830794-1-yi.fang.gan@intel.com>
Message-ID: <2023122141-smuggling-confidant-d1d8@gregkh>

On Thu, Dec 21, 2023 at 04:51:07PM +0800, Gan, Yi Fang wrote:
> Add module_exit_stub() for phylink module.
> 
> Changes since v1:
> - Introduce a helper macro for module_exit() boilerplate
> 
> This series is the combination of following:
> v1 with empty phylink_exit():
> https://lore.kernel.org/all/20231127101603.807593-1-yi.fang.gan at intel.com/
> v1 of module_exit_stub():
> https://lore.kernel.org/all/20231212094352.2263283-1-yi.fang.gan at intel.com/

As I said before, no, this isn't ok.  Why just resubmit a patch when
it's already been rejected?

This patch series should NOT be accepted as-is, you know this!

Also, you are not following the documented and REQUIRED rules for Intel
developers to be submitting kernel patches, so on that reason alone
these need to be rejected.

Please work with the Intel internel developers to do this correctly if
you wish to submit this again in the future.

greg k-h


From krzysztof.kozlowski at linaro.org  Thu Dec 21 01:17:24 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 10:17:24 +0100
Subject: [PATCH v2 1/4] dt-bindings: firmware: xilinx: Describe missing
 child nodes
In-Reply-To: <12d012d7ee372e43142bc4a56b0bbf3cb9c51c34.1703066422.git.michal.simek@amd.com>
References: <cover.1703066422.git.michal.simek@amd.com>
 <12d012d7ee372e43142bc4a56b0bbf3cb9c51c34.1703066422.git.michal.simek@amd.com>
Message-ID: <413297a8-5006-4c8c-9a62-5cd31c51125b@linaro.org>

On 20/12/2023 11:00, Michal Simek wrote:
> +  gpio:
> +    $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
> +    description: The gpio node describes connect to PS_MODE pins via firmware
> +      interface.
> +    type: object
> +
> +  pcap:
> +    $ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml
> +    description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to
> +      configure the Programmable Logic (PL). The configuration uses the
> +      firmware interface.
> +    type: object
> +
> +  pinctrl:
> +    $ref: /schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
> +    description: The pinctrl node provides access to pinconfig and pincontrol
> +      functionality available in firmware.
> +    type: object
> +
> +  power-controller:
> +    $ref: /schemas/power/reset/xlnx,zynqmp-power.yaml#

This should be "power-controller" only if it is a power domain provider.
Is it? Bot's report suggest it is not, therefore I suggested
power-management.

Also, please extend the example. The top-level example for complex
devices should be complete. Apologies for not bringing it earlier.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec 21 01:17:38 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 10:17:38 +0100
Subject: [PATCH v2 2/4] dt-bindings: firmware: xilinx: Sort node names
 (clock-controller)
In-Reply-To: <9f21ffd8018637c879bc4417e5f1de773412218d.1703066422.git.michal.simek@amd.com>
References: <cover.1703066422.git.michal.simek@amd.com>
 <9f21ffd8018637c879bc4417e5f1de773412218d.1703066422.git.michal.simek@amd.com>
Message-ID: <4c215b8b-bfbe-4d20-a0ac-e395488385e2@linaro.org>

On 20/12/2023 11:00, Michal Simek wrote:
> Nodes should be sorted that's why move clock-controller to the top of list.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>
> ---
> 
> Changes in v2:

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From u.kleine-koenig at pengutronix.de  Thu Dec 21 01:21:36 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Thu, 21 Dec 2023 10:21:36 +0100
Subject: [PATCH] MAINTAINERS: pwm: Thierry steps down, Uwe takes over
In-Reply-To: <ZYMPc50eBi6oBClu@orome.fritz.box>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
 <ZXbsDRslZNKCeJF9@orome.fritz.box>
 <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>
 <ZXcpswXxb1oQldp5@orome.fritz.box>
 <20231212203352.wl3rzob75fct4lov@pengutronix.de>
 <ZYMPc50eBi6oBClu@orome.fritz.box>
Message-ID: <6nj7rmq36hj5m26b7yhlbmpfps5wuxkx4zwyvttg4cpgocimj7@xtqm4qleo3s6>

It's not easy to let go responsibility for a subsystem that one cared
for for a long time, but Thierry realized that his heart isn't in the
pwm framework any more.

Thierry cared for the pwm subsystem (commit 200efedd8766 ("pwm: Take
over maintainership of the PWM subsystem")) as a maintainer during
nearly 12 years. A big thanks for the time, effort and dedication spend
during that time.

Uwe takes over maintenance.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
Hello Thierry,

On Wed, Dec 20, 2023 at 04:59:47PM +0100, Thierry Reding wrote:
> On Tue, Dec 12, 2023 at 09:33:52PM +0100, Uwe Kleine-K?nig wrote:
> > On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> > > It all adds up in the end and keeps me from doing other things.
> > 
> > If that means you'd be glad to give up the PWM maintainer job, I'd
> > happily take over this post.
> 
> "Glad" is not the word that I would choose. After all I've looked after
> this subsystem for almost 12 years, and letting it go isn't something
> that is particularly easy. However, I do realize that my heart isn't in
> it anymore and I don't want to be in the way of anyone.
> 
> So I'll take you up on that offer. Do you want to send a patch?

Sure, here it comes.

I hesitated to remove you completely, but I guess you intended a clean
cut? Or would you prefer to stay as a reviewer?

Usually I would have added you to CREDITS, but as you will continue to
fill your various other responsibilities (I expect), this felt wrong. 

Best regards
Uwe

 MAINTAINERS | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5342cf32d73f..16c6aa0ad1ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17561,12 +17561,11 @@ F:	Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.yaml
 F:	drivers/media/rc/pwm-ir-tx.c
 
 PWM SUBSYSTEM
-M:	Thierry Reding <thierry.reding at gmail.com>
-R:	Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
+M:	Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
 L:	linux-pwm at vger.kernel.org
 S:	Maintained
 Q:	https://patchwork.ozlabs.org/project/linux-pwm/list/
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
+T:	git https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux-pwm.git
 F:	Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml
 F:	Documentation/devicetree/bindings/pwm/
 F:	Documentation/driver-api/pwm.rst

base-commit: 881791886bfa8e353c3203f95bfbaaeee25d2d50
-- 
2.42.0


-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231221/fef982f2/attachment.sig>

From andrew at lunn.ch  Thu Dec 21 01:22:39 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 21 Dec 2023 10:22:39 +0100
Subject: [PATCH net v2 2/2] net: phylink: Add module_exit_stub()
In-Reply-To: <20231221085109.2830794-3-yi.fang.gan@intel.com>
References: <20231221085109.2830794-1-yi.fang.gan@intel.com>
 <20231221085109.2830794-3-yi.fang.gan@intel.com>
Message-ID: <0f85171e-cb9c-47dd-bb7d-f58537e24a54@lunn.ch>

On Thu, Dec 21, 2023 at 04:51:09PM +0800, Gan, Yi Fang wrote:
> In delete_module(), if mod->init callback is defined but mod->exit
> callback is not defined, it will assume the module cannot be removed
> and return EBUSY. The module_exit() is missing from current phylink
> module drive causing failure while unloading it.

You are missing justification it is actually safe to remove
phylink. Maybe Russell King deliberately did not implement
module_exit() because it can explode in interesting ways if it was?

	Andrew


From fshao at chromium.org  Thu Dec 21 01:17:42 2023
From: fshao at chromium.org (Fei Shao)
Date: Thu, 21 Dec 2023 17:17:42 +0800
Subject: [PATCH v2 0/4] Improvement around mtk_vcodec_mem_free() logging and usage
Message-ID: <20231221092226.1395427-1-fshao@chromium.org>

Hi,

This series includes some improvements around mtk_vcodec_mem_free() in
mtk_vcodec_util.c.

I noticed that mtk_vcodec_mem_free() generates a spurious error if the
target DMA buffer has been freed previously:
  mtk_vcodec_mem_free(),69: [MTK_V4L2][ERROR] 18000000.video-codec
  dma_free size=0 failed!

The warning is harmless, but it brings some confusion to our developers
and testing infra, so I sent this series to fix that with some minor
improvement for the driver alongside.

The first two patches are for aesthetic and style improvements, the
third tries to make the error logs more informative, and the last adds
back the missing checks when calling the free function.

Regards,
Fei

v1: https://lore.kernel.org/all/20231113123049.4117280-1-fshao at chromium.org/

Changes in v2:
- rebased on top of next-20231219
- revise commit message for clearer intention and rationale
- update the error messages based on the suggestion

Fei Shao (4):
  media: mediatek: vcodec: Replace dev_name in error string
  media: mediatek: vcodec: Drop unnecessary variable
  media: mediatek: vcodec: Update mtk_vcodec_mem_free() error messages
  media: mediatek: vcodec: Only free buffer VA that is not NULL

 .../mediatek/vcodec/common/mtk_vcodec_util.c  | 23 +++++++++----------
 .../vcodec/decoder/vdec/vdec_av1_req_lat_if.c | 22 ++++++++++++------
 .../vcodec/encoder/venc/venc_h264_if.c        |  5 ++--
 3 files changed, 29 insertions(+), 21 deletions(-)

-- 
2.43.0.472.g3155946c3a-goog



From fshao at chromium.org  Thu Dec 21 01:17:43 2023
From: fshao at chromium.org (Fei Shao)
Date: Thu, 21 Dec 2023 17:17:43 +0800
Subject: [PATCH v2 1/4] media: mediatek: vcodec: Replace dev_name in error string
In-Reply-To: <20231221092226.1395427-1-fshao@chromium.org>
References: <20231221092226.1395427-1-fshao@chromium.org>
Message-ID: <20231221171727.v2.1.I69223f1e438b93fe02f12ab9ef0a26f8c21f6ae7@changeid>

mtk_v4l2_err() already uses dev_err(), so don't print the device name
again. Print function name instead.

Signed-off-by: Fei Shao <fshao at chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---

Changes in v2:
- rebased on top of next-20231219

 .../media/platform/mediatek/vcodec/common/mtk_vcodec_util.c   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
index 9ce34a3b5ee6..ea8c35c0e667 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
@@ -67,7 +67,7 @@ int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
 	mem->va = dma_alloc_coherent(&plat_dev->dev, size, &mem->dma_addr, GFP_KERNEL);
 	if (!mem->va) {
 		mtk_v4l2_err(plat_dev, "%s dma_alloc size=%ld failed!",
-			     dev_name(&plat_dev->dev), size);
+			     __func__, size);
 		return -ENOMEM;
 	}
 
@@ -99,7 +99,7 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
 
 	if (!mem->va) {
 		mtk_v4l2_err(plat_dev, "%s dma_free size=%ld failed!",
-			     dev_name(&plat_dev->dev), size);
+			     __func__, size);
 		return;
 	}
 
-- 
2.43.0.472.g3155946c3a-goog



From fshao at chromium.org  Thu Dec 21 01:17:44 2023
From: fshao at chromium.org (Fei Shao)
Date: Thu, 21 Dec 2023 17:17:44 +0800
Subject: [PATCH v2 2/4] media: mediatek: vcodec: Drop unnecessary variable
In-Reply-To: <20231221092226.1395427-1-fshao@chromium.org>
References: <20231221092226.1395427-1-fshao@chromium.org>
Message-ID: <20231221092226.1395427-2-fshao@chromium.org>

In mtk_vcodec_mem_alloc() and mtk_vcodec_mem_free(), the value of
mem->size is not expected to change before and when using the DMA APIs
and debug print, so there's no point in keeping local copies of it.

Drop the local variable "size" in the mentioned functions, and update
printk format identifiers accordingly.

This makes the code slightly more visually consistent, and retrieve a
small amount of memory that is used for no real purpose.

Signed-off-by: Fei Shao <fshao at chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---

Changes in v2:
- revise commit message for clearer intention and rationale

 .../mediatek/vcodec/common/mtk_vcodec_util.c  | 22 +++++++++----------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
index ea8c35c0e667..23bea2702c9a 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
@@ -49,7 +49,6 @@ int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
 {
 	enum mtk_instance_type inst_type = *((unsigned int *)priv);
 	struct platform_device *plat_dev;
-	unsigned long size = mem->size;
 	int id;
 
 	if (inst_type == MTK_INST_ENCODER) {
@@ -64,15 +63,15 @@ int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
 		id = dec_ctx->id;
 	}
 
-	mem->va = dma_alloc_coherent(&plat_dev->dev, size, &mem->dma_addr, GFP_KERNEL);
+	mem->va = dma_alloc_coherent(&plat_dev->dev, mem->size, &mem->dma_addr, GFP_KERNEL);
 	if (!mem->va) {
-		mtk_v4l2_err(plat_dev, "%s dma_alloc size=%ld failed!",
-			     __func__, size);
+		mtk_v4l2_err(plat_dev, "%s dma_alloc size=0x%zx failed!",
+			     __func__, mem->size);
 		return -ENOMEM;
 	}
 
-	mtk_v4l2_debug(plat_dev, 3, "[%d] - va = %p dma = 0x%lx size = 0x%lx", id, mem->va,
-		       (unsigned long)mem->dma_addr, size);
+	mtk_v4l2_debug(plat_dev, 3, "[%d] - va = %p dma = 0x%lx size = 0x%zx", id, mem->va,
+		       (unsigned long)mem->dma_addr, mem->size);
 
 	return 0;
 }
@@ -82,7 +81,6 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
 {
 	enum mtk_instance_type inst_type = *((unsigned int *)priv);
 	struct platform_device *plat_dev;
-	unsigned long size = mem->size;
 	int id;
 
 	if (inst_type == MTK_INST_ENCODER) {
@@ -98,15 +96,15 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
 	}
 
 	if (!mem->va) {
-		mtk_v4l2_err(plat_dev, "%s dma_free size=%ld failed!",
-			     __func__, size);
+		mtk_v4l2_err(plat_dev, "%s dma_free size=0x%zx failed!",
+			     __func__, mem->size);
 		return;
 	}
 
-	mtk_v4l2_debug(plat_dev, 3, "[%d] - va = %p dma = 0x%lx size = 0x%lx", id, mem->va,
-		       (unsigned long)mem->dma_addr, size);
+	mtk_v4l2_debug(plat_dev, 3, "[%d] - va = %p dma = 0x%lx size = 0x%zx", id, mem->va,
+		       (unsigned long)mem->dma_addr, mem->size);
 
-	dma_free_coherent(&plat_dev->dev, size, mem->va, mem->dma_addr);
+	dma_free_coherent(&plat_dev->dev, mem->size, mem->va, mem->dma_addr);
 	mem->va = NULL;
 	mem->dma_addr = 0;
 	mem->size = 0;
-- 
2.43.0.472.g3155946c3a-goog



From fshao at chromium.org  Thu Dec 21 01:17:45 2023
From: fshao at chromium.org (Fei Shao)
Date: Thu, 21 Dec 2023 17:17:45 +0800
Subject: [PATCH v2 3/4] media: mediatek: vcodec: Update mtk_vcodec_mem_free() error messages
In-Reply-To: <20231221092226.1395427-1-fshao@chromium.org>
References: <20231221092226.1395427-1-fshao@chromium.org>
Message-ID: <20231221092226.1395427-3-fshao@chromium.org>

In mtk_vcodec_mem_free(), there are two cases where a NULL VA is passed:
- mem->size == 0: we are called to free no memory. This may happen when
  we call mtk_vcodec_mem_free() twice or the memory has never been
  allocated.
- mem->size > 0: we are called to free memory but without VA. This means
  that we failed to free the memory for real.

Both cases are not expected to happen, and we want to have clearer error
messages to describe which one we just encountered.
Update the error messages to include more information for that purpose.

Signed-off-by: Fei Shao <fshao at chromium.org>
---

Changes in v2:
- update the error messages based on the suggestion

 .../media/platform/mediatek/vcodec/common/mtk_vcodec_util.c  | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
index 23bea2702c9a..c60e4c193b25 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
@@ -96,8 +96,9 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
 	}
 
 	if (!mem->va) {
-		mtk_v4l2_err(plat_dev, "%s dma_free size=0x%zx failed!",
-			     __func__, mem->size);
+		mtk_v4l2_err(plat_dev, "%s: Tried to free a NULL VA", __func__);
+		if (mem->size)
+			mtk_v4l2_err(plat_dev, "Failed to free %zu bytes", mem->size);
 		return;
 	}
 
-- 
2.43.0.472.g3155946c3a-goog



From fshao at chromium.org  Thu Dec 21 01:17:46 2023
From: fshao at chromium.org (Fei Shao)
Date: Thu, 21 Dec 2023 17:17:46 +0800
Subject: [PATCH v2 4/4] media: mediatek: vcodec: Only free buffer VA that is not NULL
In-Reply-To: <20231221092226.1395427-1-fshao@chromium.org>
References: <20231221092226.1395427-1-fshao@chromium.org>
Message-ID: <20231221092226.1395427-4-fshao@chromium.org>

In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly
called only when the buffer to free exists, there are some instances
that didn't do the check and triggered warnings in practice.

We believe those checks were forgotten unintentionally. Add the checks
back to fix the warnings.

Signed-off-by: Fei Shao <fshao at chromium.org>
---
I had discussion with Yunfei, and he also thinks that the developers
just forgot to wrap mtk_vcodec_mem_free() with the checks back then.
We believe it's safe to add those checks.


 .../vcodec/decoder/vdec/vdec_av1_req_lat_if.c | 22 +++++++++++++------
 .../vcodec/encoder/venc/venc_h264_if.c        |  5 +++--
 2 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
index 2b6a5adbc419..b0e2e59f61b5 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
@@ -1023,18 +1023,26 @@ static void vdec_av1_slice_free_working_buffer(struct vdec_av1_slice_instance *i
 	int i;
 
 	for (i = 0; i < ARRAY_SIZE(instance->mv); i++)
-		mtk_vcodec_mem_free(ctx, &instance->mv[i]);
+		if (instance->mv[i].va)
+			mtk_vcodec_mem_free(ctx, &instance->mv[i]);
 
 	for (i = 0; i < ARRAY_SIZE(instance->seg); i++)
-		mtk_vcodec_mem_free(ctx, &instance->seg[i]);
+		if (instance->seg[i].va)
+			mtk_vcodec_mem_free(ctx, &instance->seg[i]);
 
 	for (i = 0; i < ARRAY_SIZE(instance->cdf); i++)
-		mtk_vcodec_mem_free(ctx, &instance->cdf[i]);
+		if (instance->cdf[i].va)
+			mtk_vcodec_mem_free(ctx, &instance->cdf[i]);
+
 
-	mtk_vcodec_mem_free(ctx, &instance->tile);
-	mtk_vcodec_mem_free(ctx, &instance->cdf_temp);
-	mtk_vcodec_mem_free(ctx, &instance->cdf_table);
-	mtk_vcodec_mem_free(ctx, &instance->iq_table);
+	if (instance->tile.va)
+		mtk_vcodec_mem_free(ctx, &instance->tile);
+	if (instance->cdf_temp.va)
+		mtk_vcodec_mem_free(ctx, &instance->cdf_temp);
+	if (instance->cdf_table.va)
+		mtk_vcodec_mem_free(ctx, &instance->cdf_table);
+	if (instance->iq_table.va)
+		mtk_vcodec_mem_free(ctx, &instance->iq_table);
 
 	instance->level = AV1_RES_NONE;
 }
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c
index a68dac72c4e4..f8145998fcaf 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c
@@ -301,11 +301,12 @@ static void h264_enc_free_work_buf(struct venc_h264_inst *inst)
 	 * other buffers need to be freed by AP.
 	 */
 	for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
-		if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME)
+		if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME && inst->work_bufs[i].va)
 			mtk_vcodec_mem_free(inst->ctx, &inst->work_bufs[i]);
 	}
 
-	mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
+	if (inst->pps_buf.va)
+		mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
 }
 
 static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst, bool is_34bit)
-- 
2.43.0.472.g3155946c3a-goog



From neil.armstrong at linaro.org  Thu Dec 21 01:23:48 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Thu, 21 Dec 2023 10:23:48 +0100
Subject: [PATCH] MAINTAINERS: pwm: Thierry steps down, Uwe takes over
In-Reply-To: <6nj7rmq36hj5m26b7yhlbmpfps5wuxkx4zwyvttg4cpgocimj7@xtqm4qleo3s6>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
 <ZXbsDRslZNKCeJF9@orome.fritz.box>
 <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>
 <ZXcpswXxb1oQldp5@orome.fritz.box>
 <20231212203352.wl3rzob75fct4lov@pengutronix.de>
 <ZYMPc50eBi6oBClu@orome.fritz.box>
 <6nj7rmq36hj5m26b7yhlbmpfps5wuxkx4zwyvttg4cpgocimj7@xtqm4qleo3s6>
Message-ID: <bdfe5e63-6849-4025-80c1-e8071fce56f1@linaro.org>

On 21/12/2023 10:21, Uwe Kleine-K?nig wrote:
> It's not easy to let go responsibility for a subsystem that one cared
> for for a long time, but Thierry realized that his heart isn't in the
> pwm framework any more.
> 
> Thierry cared for the pwm subsystem (commit 200efedd8766 ("pwm: Take
> over maintainership of the PWM subsystem")) as a maintainer during
> nearly 12 years. A big thanks for the time, effort and dedication spend
> during that time.
> 
> Uwe takes over maintenance.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
> Hello Thierry,
> 
> On Wed, Dec 20, 2023 at 04:59:47PM +0100, Thierry Reding wrote:
>> On Tue, Dec 12, 2023 at 09:33:52PM +0100, Uwe Kleine-K?nig wrote:
>>> On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
>>>> It all adds up in the end and keeps me from doing other things.
>>>
>>> If that means you'd be glad to give up the PWM maintainer job, I'd
>>> happily take over this post.
>>
>> "Glad" is not the word that I would choose. After all I've looked after
>> this subsystem for almost 12 years, and letting it go isn't something
>> that is particularly easy. However, I do realize that my heart isn't in
>> it anymore and I don't want to be in the way of anyone.
>>
>> So I'll take you up on that offer. Do you want to send a patch?
> 
> Sure, here it comes.
> 
> I hesitated to remove you completely, but I guess you intended a clean
> cut? Or would you prefer to stay as a reviewer?
> 
> Usually I would have added you to CREDITS, but as you will continue to
> fill your various other responsibilities (I expect), this felt wrong.
> 
> Best regards
> Uwe
> 
>   MAINTAINERS | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5342cf32d73f..16c6aa0ad1ae 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17561,12 +17561,11 @@ F:	Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.yaml
>   F:	drivers/media/rc/pwm-ir-tx.c
>   
>   PWM SUBSYSTEM
> -M:	Thierry Reding <thierry.reding at gmail.com>
> -R:	Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> +M:	Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
>   L:	linux-pwm at vger.kernel.org
>   S:	Maintained
>   Q:	https://patchwork.ozlabs.org/project/linux-pwm/list/
> -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
> +T:	git https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux-pwm.git
>   F:	Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml
>   F:	Documentation/devicetree/bindings/pwm/
>   F:	Documentation/driver-api/pwm.rst
> 
> base-commit: 881791886bfa8e353c3203f95bfbaaeee25d2d50

Thanks Thierry for all support and work over pwm and your help for pwm-meson!

Reviewed-by: Neil Armstrong <neil.armstrong at linaro.org>


From maz at kernel.org  Thu Dec 21 01:25:02 2023
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 21 Dec 2023 09:25:02 +0000
Subject: [PATCH v4 11/11] KVM: selftests: Enable tunning of err_margin_us in arch timer test
In-Reply-To: <CAJve8o=nTsAwwgSib4vOLXjOWSMV2+J+BFsUZ57OdAK7eW8q8A@mail.gmail.com>
References: <cover.1702371136.git.haibo1.xu@intel.com>
	<0343a9e4bfa8011fbb6bca0286cee7eab1f17d5d.1702371136.git.haibo1.xu@intel.com>
	<8734vy832j.wl-maz@kernel.org>
	<CAJve8onc0WN5g98aOVBmJx15wFBAqfBKJ+ufoLY+oqYyVL+=3A@mail.gmail.com>
	<f98879dc24f948f7a8a7b5374a32bc04@kernel.org>
	<CAJve8ona7g=LxW1YeRB_FqGodF973H=A3b2m8054gmzK=Z7_ww@mail.gmail.com>
	<87zfy5t1qt.wl-maz@kernel.org>
	<CAJve8o=nTsAwwgSib4vOLXjOWSMV2+J+BFsUZ57OdAK7eW8q8A@mail.gmail.com>
Message-ID: <86plyzaowh.wl-maz@kernel.org>

On Thu, 21 Dec 2023 02:58:40 +0000,
Haibo Xu <xiaobo55x at gmail.com> wrote:
> 
> On Wed, Dec 20, 2023 at 9:58?PM Marc Zyngier <maz at kernel.org> wrote:
> >
> > On Wed, 20 Dec 2023 13:51:24 +0000,
> > Haibo Xu <xiaobo55x at gmail.com> wrote:
> > >
> > > On Wed, Dec 20, 2023 at 5:00?PM Marc Zyngier <maz at kernel.org> wrote:
> > > >
> > > > On 2023-12-20 06:50, Haibo Xu wrote:
> > > > > On Wed, Dec 20, 2023 at 2:22?AM Marc Zyngier <maz at kernel.org> wrote:
> > > > >>
> > > > >> On Tue, 12 Dec 2023 09:31:20 +0000,
> > > > >> Haibo Xu <haibo1.xu at intel.com> wrote:
> > > > >> > diff --git a/tools/testing/selftests/kvm/include/timer_test.h b/tools/testing/selftests/kvm/include/timer_test.h
> > > > >> > index 968257b893a7..b1d405e7157d 100644
> > > > >> > --- a/tools/testing/selftests/kvm/include/timer_test.h
> > > > >> > +++ b/tools/testing/selftests/kvm/include/timer_test.h
> > > > >> > @@ -22,6 +22,7 @@ struct test_args {
> > > > >> >       int nr_iter;
> > > > >> >       int timer_period_ms;
> > > > >> >       int migration_freq_ms;
> > > > >> > +     int timer_err_margin_us;
> > > > >>
> > > > >> ... except that you are storing it as a signed value. Some consistency
> > > > >> wouldn't hurt, really, and would avoid issues when passing large
> > > > >> values.
> > > > >>
> > > > >
> > > > > Yes, it's more proper to use an unsigned int for the non-negative error
> > > > > margin.
> > > > > Storing as signed here is just to keep the type consistent with that
> > > > > of timer_period_ms
> > > > > since there will be '+' operation in other places.
> > > > >
> > > > >         tools/testing/selftests/kvm/aarch64/arch_timer.c
> > > > >         /* Setup a timeout for the interrupt to arrive */
> > > > >          udelay(msecs_to_usecs(test_args.timer_period_ms) +
> > > > >              test_args.timer_err_margin_us);
> > > >
> > > > But that's exactly why using a signed quantity is wrong.
> > > > What does it mean to have a huge *negative* margin?
> > > >
> > >
> > > Hi Marc,
> > >
> > > I agree that negative values are meaningless for the margin.
> > > If I understand correctly, the negative margin should be filtered by
> > > assertion in atoi_non_negative().
> >
> > No. Please.
> >
> > atoi_non_negative() returns a uint32_t, which is what it should do.
> > The bug is squarely in the use of an 'int' to store such value, and it
> > is the *storage* that turns a positive value into a negative one.
> >
> 
> Thanks for the detailed info!
> 
> May I understand that your concern is mainly for a platform with
> 64bit int type, which may trigger the positive to negative convert?

No. It specifically applies to architectures with a 32bit int type,
which is... *EVERYTHING*. Here's a basic example:

<quote>
#include <stdio.h>

int main(int argc, char *argv[])
{
	int x = 1U << 31;

	printf("%d (%d)\n", x, sizeof(x));
	return 0;
}
</quote>

which returns "-2147483648 (4)" on any platform.

This really is basic C, and I am very worried that you don't see the
issue. I strongly suggest that you go and read about the C type system
before touching this code.

	M.

-- 
Without deviation from the norm, progress is not possible.


From andrew at lunn.ch  Thu Dec 21 01:27:24 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 21 Dec 2023 10:27:24 +0100
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal
 MDIO bus
In-Reply-To: <d78949f0-bb03-82ea-b40f-1bb92b41e200@ti.com>
References: <20231220173539.59071-1-arinc.unal@arinc9.com>
 <d78949f0-bb03-82ea-b40f-1bb92b41e200@ti.com>
Message-ID: <8e248f59-007a-4c53-877f-6026f4a74d0b@lunn.ch>

> > @@ -2177,7 +2180,9 @@ mt7530_setup_mdio(struct mt7530_priv *priv)
> >  	if (priv->irq)
> >  		mt7530_setup_mdio_irq(priv);
> >  
> > -	ret = devm_mdiobus_register(dev, bus);
> > +	mnp = of_get_child_by_name(np, "mdio");
> 
> If the node is not found, then the return value would be NULL.
> Though devm_of_mdiobus_register() and of_node_put() take care of NULL references,
> other drivers that use devm_of_mdiobus_register() mostly perform a early exit if the node is NULL.

Actually, many don't as well. of_mdiobus_register() falls back to
mdiobus_register() is np==NULL. That causes a scan of the bus to find
all the PHYs and you can then use phy_find_first() to access them.

So this code is O.K.

   Andrew


From krzysztof.kozlowski at linaro.org  Thu Dec 21 01:28:52 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 10:28:52 +0100
Subject: [PATCH v10 02/16] dt-bindings: media: mediatek: mdp3: merge the
 indentical RDMA under display
In-Reply-To: <20231220100853.20616-3-moudy.ho@mediatek.com>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
 <20231220100853.20616-3-moudy.ho@mediatek.com>
Message-ID: <250fead9-868b-4063-a054-4cb966dc4ba3@linaro.org>

On 20/12/2023 11:08, Moudy Ho wrote:
> To simplify maintenance and avoid branches, the identical component
> should be merged and placed in the path belonging to the MDP
> (from display/* to media/*).

Combining bindings into one bigger meta-binding makes it usually more
difficult to maintain and review.

> 
> In addition, currently only MDP utilizes RDMA through CMDQ, and the
> necessary properties for "mediatek,gce-events", and "mboxes" have been
> set up for this purpose.
> Within DISP, it directly receives component interrupt signals.
> 
> Signed-off-by: Moudy Ho <moudy.ho at mediatek.com>
> ---
>  .../display/mediatek/mediatek,mdp-rdma.yaml   | 92 -------------------
>  .../bindings/media/mediatek,mdp3-rdma.yaml    | 43 ++++++++-
>  2 files changed, 40 insertions(+), 95 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
> deleted file mode 100644
> index 7570a0684967..000000000000
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
> +++ /dev/null
> @@ -1,92 +0,0 @@
> -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> -%YAML 1.2
> ----
> -$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml#
> -$schema: http://devicetree.org/meta-schemas/core.yaml#
> -
> -title: MediaTek MDP RDMA
> -
> -maintainers:
> -  - Chun-Kuang Hu <chunkuang.hu at kernel.org>
> -  - Philipp Zabel <p.zabel at pengutronix.de>
> -
> -description:
> -  The MediaTek MDP RDMA stands for Read Direct Memory Access.
> -  It provides real time data to the back-end panel driver, such as DSI,
> -  DPI and DP_INTF.
> -  It contains one line buffer to store the sufficient pixel data.
> -  RDMA device node must be siblings to the central MMSYS_CONFIG node.
> -  For a description of the MMSYS_CONFIG binding, see
> -  Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for details.
> -
> -properties:
> -  compatible:
> -    oneOf:
> -      - const: mediatek,mt8195-vdo1-rdma
> -      - items:
> -          - const: mediatek,mt8188-vdo1-rdma
> -          - const: mediatek,mt8195-vdo1-rdma
> -
> -  reg:
> -    maxItems: 1
> -
> -  interrupts:
> -    maxItems: 1
> -
> -  power-domains:
> -    maxItems: 1
> -
> -  clocks:
> -    items:
> -      - description: RDMA Clock
> -
> -  iommus:
> -    maxItems: 1
> -
> -  mediatek,gce-client-reg:
> -    description:
> -      The register of display function block to be set by gce. There are 4 arguments,
> -      such as gce node, subsys id, offset and register size. The subsys id that is
> -      mapping to the register of display function blocks is defined in the gce header
> -      include/dt-bindings/gce/<chip>-gce.h of each chips.
> -    $ref: /schemas/types.yaml#/definitions/phandle-array
> -    items:
> -      items:
> -        - description: phandle of GCE
> -        - description: GCE subsys id
> -        - description: register offset
> -        - description: register size
> -    maxItems: 1
> -
> -required:
> -  - compatible
> -  - reg
> -  - power-domains
> -  - clocks
> -  - iommus
> -  - mediatek,gce-client-reg
> -
> -additionalProperties: false
> -
> -examples:
> -  - |
> -    #include <dt-bindings/interrupt-controller/arm-gic.h>
> -    #include <dt-bindings/clock/mt8195-clk.h>
> -    #include <dt-bindings/power/mt8195-power.h>
> -    #include <dt-bindings/gce/mt8195-gce.h>
> -    #include <dt-bindings/memory/mt8195-memory-port.h>
> -
> -    soc {
> -        #address-cells = <2>;
> -        #size-cells = <2>;
> -
> -        rdma at 1c104000 {
> -            compatible = "mediatek,mt8195-vdo1-rdma";
> -            reg = <0 0x1c104000 0 0x1000>;
> -            interrupts = <GIC_SPI 495 IRQ_TYPE_LEVEL_HIGH 0>;
> -            clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
> -            power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>;
> -            iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>;
> -            mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX 0x4000 0x1000>;
> -        };
> -    };
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> index e1ffe7eb2cdf..e9955639ce19 100644
> --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> @@ -20,8 +20,12 @@ description: |
>  
>  properties:
>    compatible:
> -    items:
> +    oneOf:
>        - const: mediatek,mt8183-mdp3-rdma
> +      - const: mediatek,mt8195-vdo1-rdma
> +      - items:
> +          - const: mediatek,mt8188-vdo1-rdma
> +          - const: mediatek,mt8195-vdo1-rdma
>  
>    reg:
>      maxItems: 1
> @@ -60,6 +64,7 @@ properties:
>      items:
>        - description: RDMA clock
>        - description: RSZ clock
> +    minItems: 1
>  
>    iommus:
>      maxItems: 1
> @@ -68,6 +73,10 @@ properties:
>      items:
>        - description: used for 1st data pipe from RDMA
>        - description: used for 2nd data pipe from RDMA
> +    minItems: 1
> +
> +  interrupts:
> +    maxItems: 1

Why existing devices now support interrupts?

>  
>    '#dma-cells':
>      const: 1
> @@ -76,13 +85,41 @@ required:
>    - compatible
>    - reg
>    - mediatek,gce-client-reg
> -  - mediatek,gce-events
>    - power-domains
>    - clocks
>    - iommus
> -  - mboxes
>    - '#dma-cells'

I see little value in this commit, considering that next month you will
want to split it because it will grow unmaintainable.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec 21 01:32:37 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 10:32:37 +0100
Subject: [RFC PATCH net-next 1/8] dt-bindings: net: Add support for AM65x
 SR1.0 in ICSSG
In-Reply-To: <20231219174548.3481-2-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
 <20231219174548.3481-2-diogo.ivo@siemens.com>
Message-ID: <5f64cd0d-3a64-41bf-ac12-3a73f7cc2dbf@linaro.org>

On 19/12/2023 18:45, Diogo Ivo wrote:
> Silicon Revision 1.0 of the AM65x came with a slightly different ICSSG
> support: Only 2 PRUs per slice are available and instead 2 additional
> DMA channels are used for management purposes. We have no restrictions
> on specified PRUs, but the DMA channels need to be adjusted.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
> ---
>  .../bindings/net/ti,icssg-prueth.yaml         | 62 +++++++++++++------
>  1 file changed, 44 insertions(+), 18 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
> index 229c8f32019f..fbe51731854a 100644
> --- a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
> +++ b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
> @@ -19,30 +19,15 @@ allOf:
>  properties:
>    compatible:
>      enum:
> -      - ti,am642-icssg-prueth  # for AM64x SoC family
> -      - ti,am654-icssg-prueth  # for AM65x SoC family
> +      - ti,am642-icssg-prueth      # for AM64x SoC family
> +      - ti,am654-icssg-prueth      # for AM65x SoC family, SR2.x
> +      - ti,am654-icssg-prueth-sr1  # for AM65x SoC family, SR1.0

sr1 is revision of am654, so it should be added to SoC name, not at the
end of binding.

>  
>    sram:
>      $ref: /schemas/types.yaml#/definitions/phandle
>      description:
>        phandle to MSMC SRAM node
>  
> -  dmas:
> -    maxItems: 10

Why are you removing top-level properties? They must stay here in widest
constrains.

> -
> -  dma-names:
> -    items:
> -      - const: tx0-0
> -      - const: tx0-1
> -      - const: tx0-2
> -      - const: tx0-3
> -      - const: tx1-0
> -      - const: tx1-1
> -      - const: tx1-2
> -      - const: tx1-3
> -      - const: rx0
> -      - const: rx1

Grow it and use minItems.

> -
>    ti,mii-g-rt:
>      $ref: /schemas/types.yaml#/definitions/phandle
>      description:
> @@ -122,6 +107,47 @@ properties:
>        - required:
>            - port at 1
>  

Missing allOf and then it goes after required block.

> +if:
> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - ti,am654-icssg-prueth-sr1
> +then:
> +  properties:
> +    dmas:

minItems

> +      maxItems: 12
> +    dma-names:
> +      items:

minItems instead

> +        - const: tx0-0
> +        - const: tx0-1
> +        - const: tx0-2
> +        - const: tx0-3
> +        - const: tx1-0
> +        - const: tx1-1
> +        - const: tx1-2
> +        - const: tx1-3
> +        - const: rx0
> +        - const: rx1
> +        - const: rxmgm0
> +        - const: rxmgm1
> +else:
> +  properties:
> +    dmas:
> +      maxItems: 10
> +    dma-names:
> +      items:

maxItems instead



Best regards,
Krzysztof



From jialong.yang at shingroup.cn  Thu Dec 21 01:38:01 2023
From: jialong.yang at shingroup.cn (JiaLong.Yang)
Date: Thu, 21 Dec 2023 17:38:01 +0800
Subject: [PATCH] perf/arm_smmuv3: Omit the two judgements which done in framework
Message-ID: <20231221093802.20612-1-jialong.yang@shingroup.cn>

'event->attr.type != event->pmu->type' has been done in
core.c::perf_init_event() ,core.c::perf_event_modify_attr(), etc.

This PMU is an uncore one. The core framework has disallowed
uncore-task events. So the judgement to event->cpu < 0 is no mean.

The two judgements have been done in kernel/events/core.c

Signed-off-by: JiaLong.Yang <jialong.yang at shingroup.cn>
---
 drivers/perf/arm_smmuv3_pmu.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 6303b82566f9..8ea4a3227165 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -401,19 +401,11 @@ static int smmu_pmu_event_init(struct perf_event *event)
 	int group_num_events = 1;
 	u16 event_id;
 
-	if (event->attr.type != event->pmu->type)
-		return -ENOENT;
-
 	if (hwc->sample_period) {
 		dev_dbg(dev, "Sampling not supported\n");
 		return -EOPNOTSUPP;
 	}
 
-	if (event->cpu < 0) {
-		dev_dbg(dev, "Per-task mode not supported\n");
-		return -EOPNOTSUPP;
-	}
-
 	/* Verify specified event is supported on this PMU */
 	event_id = get_event(event);
 	if (event_id < SMMU_PMCG_ARCH_MAX_EVENTS &&
-- 
2.25.1



From sebastien.szymanski at armadeus.com  Thu Dec 21 01:56:09 2023
From: sebastien.szymanski at armadeus.com (=?UTF-8?Q?S=C3=A9bastien_Szymanski?=)
Date: Thu, 21 Dec 2023 10:56:09 +0100
Subject: [PATCH RFT 2/2] ARM: dts: mxs: imx28: Fix NAND hierarchy
 description
In-Reply-To: <20231218130656.9020-2-wahrenst@gmx.net>
References: <20231218130656.9020-1-wahrenst@gmx.net>
 <20231218130656.9020-2-wahrenst@gmx.net>
Message-ID: <bf76aa11-7005-4bf8-836b-fce616afcdf4@armadeus.com>

Hello Stefan,

On 12/18/23 14:06, Stefan Wahren wrote:
> The size-cells for GPMI are wrong in imx28.dtsi, which causes the
> following warning:
> 
>      nand-controller at 8000c000: #size-cells:0:0: 0 was expected
> 
> The reason for this is the definition of the partitions directly
> below the nand controller node. According to nand-controller.yaml
> the NAND chip must be defined as a child of the controller. Even
> the fixed partitions must be kept in a partitions container.
> 
> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
> ---
> 
> Hi,
> unfortunately i don't have access to MSR M28CU3 or an Armadeus Systems APF28
> so it would be nice if someone can give a try.

I have tried this patch on an APF28. Unfortunately it doesn't work:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 6.7.0-rc6 (sszy at gentoo) 
(arm-buildroot-linux-gnueabi-gcc.br_real (Buildroot 
armadeus-7.0-387-g06d2e893315e-dirty) 12.3.0, GNU ld (GNU Binutils) 
2.40) #1 Thu Dec 21 10:24:41 CET 2023

...

[    4.224482] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[    4.231238] nand: Micron MT29F2G08ABAEAWP
[    4.235399] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, 
OOB size: 64
[    4.245851] Scanning device for bad blocks
[    4.252904] Bad eraseblock 0 at 0x000000000000
[    4.257842] Bad eraseblock 1 at 0x000000020000
[    4.262972] Bad eraseblock 2 at 0x000000040000
[    4.267886] Bad eraseblock 3 at 0x000000060000
[    4.272994] Bad eraseblock 4 at 0x000000080000
[    4.277900] Bad eraseblock 5 at 0x0000000a0000
[    4.283007] Bad eraseblock 6 at 0x0000000c0000
[    4.287916] Bad eraseblock 7 at 0x0000000e0000
[    5.443712] gpmi-nand: ofpart partition 
/apb at 80000000/apbh at 80000000/nand-controller at 8000c000/nand at 0 
(/apb at 80000000/apbh at 80000000/nand-controller at 8000c000) #size-cells is 
wrongly set to <0>, assuming <1> for parsing partitions.
[    5.464436] gpmi-nand: error parsing ofpart partition 
/apb at 80000000/apbh at 80000000/nand-controller at 8000c000/nand at 0 
(/apb at 80000000/apbh at 80000000/nand-controller at 8000c000)
[    5.523845] gpmi-nand 8000c000.nand-controller: driver registered.

Without this patch:

[    5.443988] 7 fixed-partitions partitions found on MTD device gpmi-nand
[    5.450992] Creating 7 MTD partitions on "gpmi-nand":
[    5.456234] 0x000000000000-0x000000300000 : "u-boot"
[    5.506409] 0x000000300000-0x000000380000 : "env"
[    5.537298] 0x000000380000-0x000000400000 : "env2"
[    5.568253] 0x000000400000-0x000000480000 : "dtb"
[    5.598940] 0x000000480000-0x000000500000 : "splash"
[    5.629766] 0x000000500000-0x000000d00000 : "kernel"
[    5.661523] 0x000000d00000-0x000010000000 : "rootfs"
[    5.710012] gpmi-nand 8000c000.nand-controller: driver registered.

Regards,

> 
>   arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts  | 64 +++++++++++++---------
>   arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi   |  2 -
>   arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts | 28 ++++++----
>   arch/arm/boot/dts/nxp/mxs/imx28.dtsi       |  2 +-
>   4 files changed, 56 insertions(+), 40 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts b/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts
> index 98672932e41b..10bfac31f672 100644
> --- a/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts
> +++ b/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts
> @@ -27,39 +27,49 @@ &gpmi {
>   	pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
>   	status = "okay";
> 
> -	partition at 0 {
> -		label = "u-boot";
> -		reg = <0x0 0x300000>;
> -	};
> +	nand at 0 {
> +		reg = <0>;
> 
> -	partition at 300000 {
> -		label = "env";
> -		reg = <0x300000 0x80000>;
> -	};
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> 
> -	partition at 380000 {
> -		label = "env2";
> -		reg = <0x380000 0x80000>;
> -	};
> +			partition at 0 {
> +				label = "u-boot";
> +				reg = <0x0 0x300000>;
> +			};
> 
> -	partition at 400000 {
> -		label = "dtb";
> -		reg = <0x400000 0x80000>;
> -	};
> +			partition at 300000 {
> +				label = "env";
> +				reg = <0x300000 0x80000>;
> +			};
> 
> -	partition at 480000 {
> -		label = "splash";
> -		reg = <0x480000 0x80000>;
> -	};
> +			partition at 380000 {
> +				label = "env2";
> +				reg = <0x380000 0x80000>;
> +			};
> 
> -	partition at 500000 {
> -		label = "kernel";
> -		reg = <0x500000 0x800000>;
> -	};
> +			partition at 400000 {
> +				label = "dtb";
> +				reg = <0x400000 0x80000>;
> +			};
> +
> +			partition at 480000 {
> +				label = "splash";
> +				reg = <0x480000 0x80000>;
> +			};
> +
> +			partition at 500000 {
> +				label = "kernel";
> +				reg = <0x500000 0x800000>;
> +			};
> 
> -	partition at d00000 {
> -		label = "rootfs";
> -		reg = <0xd00000 0xf300000>;
> +			partition at d00000 {
> +				label = "rootfs";
> +				reg = <0xd00000 0xf300000>;
> +			};
> +		};
>   	};
>   };
> 
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi b/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi
> index 66facef10ba9..54b0f715f091 100644
> --- a/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi
> +++ b/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi
> @@ -24,8 +24,6 @@ reg_3p3v: regulator-0 {
>   };
> 
>   &gpmi {
> -	#address-cells = <1>;
> -	#size-cells = <1>;
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
>   	status = "okay";
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts b/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts
> index 34b4d3246db1..d069ac907490 100644
> --- a/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts
> +++ b/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts
> @@ -93,21 +93,29 @@ &duart {
>   };
> 
>   &gpmi {
> -	#address-cells = <1>;
> -	#size-cells = <1>;
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
>   	status = "okay";
> 
> -	partition at 0 {
> -		label = "gpmi-nfc-0-boot";
> -		reg = <0x00000000 0x01400000>;
> -		read-only;
> -	};
> +	nand at 0 {
> +		reg = <0>;
> 
> -	partition at 1 {
> -		label = "gpmi-nfc-general-use";
> -		reg = <0x01400000 0x0ec00000>;
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			partition at 0 {
> +				label = "gpmi-nfc-0-boot";
> +				reg = <0x00000000 0x01400000>;
> +				read-only;
> +			};
> +
> +			partition at 1 {
> +				label = "gpmi-nfc-general-use";
> +				reg = <0x01400000 0x0ec00000>;
> +			};
> +		};
>   	};
>   };
> 
> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
> index 4817fba2d938..9655403b7f90 100644
> --- a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
> +++ b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
> @@ -99,7 +99,7 @@ perfmon: perfmon at 80006000 {
>   			gpmi: nand-controller at 8000c000 {
>   				compatible = "fsl,imx28-gpmi-nand";
>   				#address-cells = <1>;
> -				#size-cells = <1>;
> +				#size-cells = <0>;
>   				reg = <0x8000c000 0x2000>, <0x8000a000 0x2000>;
>   				reg-names = "gpmi-nand", "bch";
>   				interrupts = <41>;
> --
> 2.34.1
> 

-- 
S?bastien Szymanski, Armadeus Systems
Software engineer



From thierry.reding at gmail.com  Thu Dec 21 01:57:23 2023
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 21 Dec 2023 10:57:23 +0100
Subject: [PATCH] MAINTAINERS: pwm: Thierry steps down, Uwe takes over
In-Reply-To: <6nj7rmq36hj5m26b7yhlbmpfps5wuxkx4zwyvttg4cpgocimj7@xtqm4qleo3s6>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
 <ZXbsDRslZNKCeJF9@orome.fritz.box>
 <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>
 <ZXcpswXxb1oQldp5@orome.fritz.box>
 <20231212203352.wl3rzob75fct4lov@pengutronix.de>
 <ZYMPc50eBi6oBClu@orome.fritz.box>
 <6nj7rmq36hj5m26b7yhlbmpfps5wuxkx4zwyvttg4cpgocimj7@xtqm4qleo3s6>
Message-ID: <ZYQMA-tM-zl5IJyC@orome.fritz.box>

On Thu, Dec 21, 2023 at 10:21:36AM +0100, Uwe Kleine-K?nig wrote:
> It's not easy to let go responsibility for a subsystem that one cared
> for for a long time, but Thierry realized that his heart isn't in the
> pwm framework any more.
> 
> Thierry cared for the pwm subsystem (commit 200efedd8766 ("pwm: Take
> over maintainership of the PWM subsystem")) as a maintainer during
> nearly 12 years. A big thanks for the time, effort and dedication spend
> during that time.
> 
> Uwe takes over maintenance.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
> Hello Thierry,
> 
> On Wed, Dec 20, 2023 at 04:59:47PM +0100, Thierry Reding wrote:
> > On Tue, Dec 12, 2023 at 09:33:52PM +0100, Uwe Kleine-K?nig wrote:
> > > On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> > > > It all adds up in the end and keeps me from doing other things.
> > > 
> > > If that means you'd be glad to give up the PWM maintainer job, I'd
> > > happily take over this post.
> > 
> > "Glad" is not the word that I would choose. After all I've looked after
> > this subsystem for almost 12 years, and letting it go isn't something
> > that is particularly easy. However, I do realize that my heart isn't in
> > it anymore and I don't want to be in the way of anyone.
> > 
> > So I'll take you up on that offer. Do you want to send a patch?
> 
> Sure, here it comes.
> 
> I hesitated to remove you completely, but I guess you intended a clean
> cut? Or would you prefer to stay as a reviewer?
> 
> Usually I would have added you to CREDITS, but as you will continue to
> fill your various other responsibilities (I expect), this felt wrong. 

Looks all good to me. I'll keep things going until the next merge window
and will then send out my last PWM pull request and let Linus know to
expect future requests to come from you.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231221/527511ac/attachment.sig>

From quic_bibekkum at quicinc.com  Thu Dec 21 02:02:10 2023
From: quic_bibekkum at quicinc.com (Bibek Kumar Patro)
Date: Thu, 21 Dec 2023 15:32:10 +0530
Subject: [PATCH v6 3/5] iommu/arm-smmu: introduction of ACTLR for custom
 prefetcher settings
In-Reply-To: <CAA8EJpo8X+jfi20N9P7kUshxe6_7pwQe8G0Q02JDuB8ozH7hLA@mail.gmail.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
 <20231220133808.5654-4-quic_bibekkum@quicinc.com>
 <CAA8EJpo8X+jfi20N9P7kUshxe6_7pwQe8G0Q02JDuB8ozH7hLA@mail.gmail.com>
Message-ID: <7b32b7a7-bc64-4102-a6bf-3c3fc8d979ac@quicinc.com>



On 12/21/2023 6:06 AM, Dmitry Baryshkov wrote:
> On Wed, 20 Dec 2023 at 15:39, Bibek Kumar Patro
> <quic_bibekkum at quicinc.com> wrote:
>>
>> Currently in Qualcomm  SoCs the default prefetch is set to 1 which allows
>> the TLB to fetch just the next page table. MMU-500 features ACTLR
>> register which is implementation defined and is used for Qualcomm SoCs
>> to have a custom prefetch setting enabling TLB to prefetch the next set
>> of page tables accordingly allowing for faster translations.
>>
>> ACTLR value is unique for each SMR (Stream matching register) and stored
>> in a pre-populated table. This value is set to the register during
>> context bank initialisation.
>>
>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
>> ---
>>   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 45 ++++++++++++++++++++++
>>   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h |  6 ++-
>>   drivers/iommu/arm/arm-smmu/arm-smmu.c      |  5 ++-
>>   drivers/iommu/arm/arm-smmu/arm-smmu.h      |  5 +++
>>   4 files changed, 58 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> index 20c9836d859b..1cefdd0ca110 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
>> @@ -24,6 +24,12 @@
>>   #define CPRE                   (1 << 1)
>>   #define CMTLB                  (1 << 0)
>>
>> +struct actlr_config {
>> +       u16 sid;
>> +       u16 mask;
>> +       u32 actlr;
>> +};
>> +
>>   static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
>>   {
>>          return container_of(smmu, struct qcom_smmu, smmu);
>> @@ -215,9 +221,38 @@ static bool qcom_adreno_can_do_ttbr1(struct arm_smmu_device *smmu)
>>          return true;
>>   }
>>
>> +static void qcom_smmu_set_actlr(struct device *dev, struct arm_smmu_device *smmu, int cbndx,
>> +               const struct actlr_config *actlrcfg)
>> +{
>> +       struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
>> +       struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>> +       struct arm_smmu_smr *smr;
>> +       u16 mask;
>> +       int idx;
>> +       u16 id;
>> +       int i;
>> +
>> +       for (; actlrcfg->sid || actlrcfg->mask || actlrcfg->actlr; actlrcfg++) {
>> +               id = actlrcfg->sid;
>> +               mask = actlrcfg->mask;
>> +
>> +               for_each_cfg_sme(cfg, fwspec, i, idx) {
>> +                       smr = &smmu->smrs[idx];
>> +                       if (smr_is_subset(smr, id, mask)) {
>> +                               arm_smmu_cb_write(smmu, cbndx, ARM_SMMU_CB_ACTLR,
>> +                                               actlrcfg->actlr);
>> +                               break;
>> +                       }
>> +               }
>> +       }
>> +}
>> +
>>   static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
>>                  struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
>>   {
>> +       struct arm_smmu_device *smmu = smmu_domain->smmu;
>> +       struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
>> +       int cbndx = smmu_domain->cfg.cbndx;
>>          struct adreno_smmu_priv *priv;
>>
>>          smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
>> @@ -248,6 +283,9 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
>>          priv->set_stall = qcom_adreno_smmu_set_stall;
>>          priv->resume_translation = qcom_adreno_smmu_resume_translation;
>>
>> +       if (qsmmu->data->actlrcfg_gfx)
>> +               qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg_gfx);
> 
> There was a feedback point against v4 that there can be more than two
> (apps + gpu) SMMU devices. No, we can not use additional compat
> strings, the SMMU units are compatible with each other.

Just to understand better, did you mean if in the below check
[inside arm-smmu-qcom.c file during qcom_smmu_create()], "else" has two 
things? (Currently adreno_impl for gpu smmu, else for only
apps smmu)

          if (np && of_device_is_compatible(np, "qcom,adreno-smmu"))
                  impl = data->adreno_impl;
          else
                  impl = data->impl;

> Please add
> matching between the smmu and particular actlr table using the IO
> address of the SMMU block.
> 

The ACTLR table for each smmu will have A IO address attached, so based 
on IO address we can apply ACTLR.
Is this your proposal((IMO hardcoding IO in driver won't be viable, 
isn't it?), or in smmu DT we would need to set the IO?


Thanks & regards,
Bibek

>> +
>>          return 0;
>>   }
>>
>> @@ -274,6 +312,13 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
>>   static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain,
>>                  struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
>>   {
>> +       struct arm_smmu_device *smmu = smmu_domain->smmu;
>> +       struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
>> +       int cbndx = smmu_domain->cfg.cbndx;
>> +
>> +       if (qsmmu->data->actlrcfg)
>> +               qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg);
>> +
> 
> One issue occured to me, while I was reviewing the patchset. The ACTLR
> settings are related to the whole SMMU setup, but we are applying them
> each time there is an SMMU context init (in other words, one per each
> domain). Is that correct? Or it's just that there is no better place
> for initialising the global register set? Would it be better to
> reprogram the ACTLR registers which are related just to this
> particular domain?
> 
>>          smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
>>
>>          return 0;
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
>> index f3b91963e234..cb4cb402c202 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
>> @@ -1,6 +1,6 @@
>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>   /*
>> - * Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
>> + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
>>    */
>>
>>   #ifndef _ARM_SMMU_QCOM_H
>> @@ -24,7 +24,11 @@ struct qcom_smmu_config {
>>          const u32 *reg_offset;
>>   };
>>
>> +struct actlr_config;
>> +
>>   struct qcom_smmu_match_data {
>> +       const struct actlr_config *actlrcfg;
>> +       const struct actlr_config *actlrcfg_gfx;
>>          const struct qcom_smmu_config *cfg;
>>          const struct arm_smmu_impl *impl;
>>          const struct arm_smmu_impl *adreno_impl;
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> index d6d1a2a55cc0..0c7f700b27dd 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> @@ -990,9 +990,10 @@ static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
>>                   * expect simply identical entries for this case, but there's
>>                   * no harm in accommodating the generalisation.
>>                   */
>> -               if ((mask & smrs[i].mask) == mask &&
>> -                   !((id ^ smrs[i].id) & ~smrs[i].mask))
>> +
>> +               if (smr_is_subset(&smrs[i], id, mask))
>>                          return i;
>> +
>>                  /*
>>                   * If the new entry has any other overlap with an existing one,
>>                   * though, then there always exists at least one stream ID
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
>> index 703fd5817ec1..2e4f65412c6b 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
>> @@ -501,6 +501,11 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
>>                  writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);
>>   }
>>
>> +static inline bool smr_is_subset(struct arm_smmu_smr *smrs, u16 id, u16 mask)
>> +{
>> +       return (mask & smrs->mask) == mask && !((id ^ smrs->id) & ~smrs->mask);
>> +}
>> +
>>   #define ARM_SMMU_GR0           0
>>   #define ARM_SMMU_GR1           1
>>   #define ARM_SMMU_CB(s, n)      ((s)->numpage + (n))
>> --
>> 2.17.1
>>
> 
> 


From james.clark at arm.com  Thu Dec 21 02:05:33 2023
From: james.clark at arm.com (James Clark)
Date: Thu, 21 Dec 2023 10:05:33 +0000
Subject: [PATCH RFC V2 1/4] perf/core: Add aux_pause, aux_resume,
 aux_start_paused
In-Reply-To: <b37d6e3b-d9e2-48aa-b7e8-10a85c3f7aa8@intel.com>
References: <20231208172449.35444-1-adrian.hunter@intel.com>
 <20231208172449.35444-2-adrian.hunter@intel.com>
 <0bbbcdb5-41eb-dd07-660a-2e5e4a0d59f0@arm.com>
 <b37d6e3b-d9e2-48aa-b7e8-10a85c3f7aa8@intel.com>
Message-ID: <f33f9e4b-8a1c-5409-eb7d-6752471b846b@arm.com>



On 20/12/2023 16:16, Adrian Hunter wrote:
> On 20/12/23 17:54, James Clark wrote:
>>
>>
>> On 08/12/2023 17:24, Adrian Hunter wrote:
>>> Hardware traces, such as instruction traces, can produce a vast amount of
>>> trace data, so being able to reduce tracing to more specific circumstances
>>> can be useful.
>>>
>>> The ability to pause or resume tracing when another event happens, can do
>>> that.
>>>
>>> Add ability for an event to "pause" or "resume" AUX area tracing.
>>>
>>> Add aux_pause bit to perf_event_attr to indicate that, if the event
>>> happens, the associated AUX area tracing should be paused. Ditto
>>> aux_resume. Do not allow aux_pause and aux_resume to be set together.
>>>
>>> Add aux_start_paused bit to perf_event_attr to indicate to an AUX area
>>> event that it should start in a "paused" state.
>>>
>>> Add aux_paused to struct perf_event for AUX area events to keep track of
>>> the "paused" state. aux_paused is initialized to aux_start_paused.
>>>
>>> Add PERF_EF_PAUSE and PERF_EF_RESUME modes for ->stop() and ->start()
>>> callbacks. Call as needed, during __perf_event_output(). Add
>>> aux_in_pause_resume to struct perf_buffer to prevent races with the NMI
>>> handler. Pause/resume in NMI context will miss out if it coincides with
>>> another pause/resume.
>>>
>>> To use aux_pause or aux_resume, an event must be in a group with the AUX
>>> area event as the group leader.
>>>
>>> Example (requires Intel PT and tools patches also):
>>>
>>>  $ perf record --kcore -e '{intel_pt/aux-start-paused/k,syscalls:sys_enter_newuname/aux-resume/,syscalls:sys_exit_newuname/aux-pause/}' uname
>>
>> I think it might be useful to have an aux-toggle option as well, and
>> then you could do sampling if you put it on a PMU counter with an
>> interval. Unless you can make two events for the same counter with
>> different intervals, and one does resume and the other does pause? I'm
>> not sure if that would work?
> 
> There is already ->snapshot_aux() for sampling. Is that what you mean?
> 

I suppose that mostly handles that use case yes. Although there are some
slight differences. It looks like for SAMPLE_AUX, the buffer size for
each sample is fixed and limited to 16 bits in size, whereas between
pause and resume you could potentially have multiple buffers delivered
to userspace of any size.

And it looks like SAMPLE_AUX would leave the trace running even when no
samples were being collected. I suppose you might not want to consume
the memory bandwidth and turn the trace off between samples, which
pause/resume does. Especially if you intend to have long periods between
the samples.

I think if it did turn out to be useful the toggle function can easily
be added later, so I don't intend this comment to be a blocking one.


>>
>> Other than that it looks ok. I got Coresight working with a couple of
>> changes to what you posted on here, but that can always be done more
>> thoroughly later if we leave PERF_PMU_CAP_AUX_PAUSE off Coresight for now.
> 
> Thanks a lot for looking at this!
> 


From fusibrandon13 at gmail.com  Thu Dec 21 02:10:10 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 21 Dec 2023 11:10:10 +0100
Subject: [RFC PATCH v2 0/3] Add support for reading D1 efuse speed bin
Message-ID: <20231221101013.67204-1-fusibrandon13@gmail.com>

Hi everyone,

This series is an attempt to get feedback on decoding D1 efuse speed bins
in the Sun50i H6 cpufreq driver, and turning the result into a meaningful
value that selects voltage ranges in an OPP table.

I want to make sure I get this right before sending in a v3 of the D1
cpufreq support series here

https://lore.kernel.org/linux-sunxi/20231218110543.64044-1-fusibrandon13 at gmail.com/T/#t

which is currently stuck at

https://lore.kernel.org/linux-sunxi/aad8302d-a015-44ee-ad11-1a4c6e00074c at sholland.org/

Changes in v2:
- Make speed bin decoding generic in one patch and add D1 support in a
  separate patch
- Fix OPP voltage ranges to avoid stability issues

Brandon Cheo Fusi (3):
  cpufreq: sun50i: Refactor speed bin decoding
  cpufreq: sun50i: Add support for D1's speed bin decoding
  riscv: dts: allwinner: Fill in OPPs

 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 19 +++-
 drivers/cpufreq/sun50i-cpufreq-nvmem.c        | 89 +++++++++++++++----
 2 files changed, 89 insertions(+), 19 deletions(-)

-- 
2.30.2



From fusibrandon13 at gmail.com  Thu Dec 21 02:10:11 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 21 Dec 2023 11:10:11 +0100
Subject: [RFC PATCH v2 1/3] cpufreq: sun50i: Refactor speed bin decoding
In-Reply-To: <20231221101013.67204-1-fusibrandon13@gmail.com>
References: <20231221101013.67204-1-fusibrandon13@gmail.com>
Message-ID: <20231221101013.67204-2-fusibrandon13@gmail.com>

Make converting the speed bin value into a speed grade generic
and determined by a platform specific callback.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/sun50i-cpufreq-nvmem.c | 55 ++++++++++++++++++--------
 1 file changed, 39 insertions(+), 16 deletions(-)

diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 32a9c88f8..fc509fc49 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -25,6 +25,38 @@
 
 static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
 
+struct sunxi_cpufreq_data {
+	u32 (*efuse_xlate)(u32 *speedbin, size_t len);
+};
+
+static u32 sun50i_efuse_xlate(u32 *speedbin, size_t len)
+{
+	u32 efuse_value = 0;
+
+	efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
+
+	/*
+	* We treat unexpected efuse values as if the SoC was from
+	* the slowest bin. Expected efuse values are 1-3, slowest
+	* to fastest.
+	*/
+	if (efuse_value >= 1 && efuse_value <= 3)
+		return efuse_value - 1;
+	else
+		return 0;
+}
+
+struct sunxi_cpufreq_data sun50i_cpufreq_data = {
+	.efuse_xlate = sun50i_efuse_xlate,
+};
+
+static const struct of_device_id cpu_opp_match_list[] = {
+	{ .compatible = "allwinner,sun50i-h6-operating-points",
+	  .data = &sun50i_cpufreq_data,
+	},
+	{}
+};
+
 /**
  * sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
  * @versions: Set to the value parsed from efuse
@@ -36,9 +68,10 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	struct nvmem_cell *speedbin_nvmem;
 	struct device_node *np;
 	struct device *cpu_dev;
-	u32 *speedbin, efuse_value;
+	const struct of_device_id *match;
+	const struct sunxi_cpufreq_data *opp_data;
+	u32 *speedbin;
 	size_t len;
-	int ret;
 
 	cpu_dev = get_cpu_device(0);
 	if (!cpu_dev)
@@ -48,12 +81,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	if (!np)
 		return -ENOENT;
 
-	ret = of_device_is_compatible(np,
-				      "allwinner,sun50i-h6-operating-points");
-	if (!ret) {
+	match = of_match_node(cpu_opp_match_list, np);
+	if (!match) {
 		of_node_put(np);
 		return -ENOENT;
 	}
+	opp_data = match->data;
 
 	speedbin_nvmem = of_nvmem_cell_get(np, NULL);
 	of_node_put(np);
@@ -66,17 +99,7 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	if (IS_ERR(speedbin))
 		return PTR_ERR(speedbin);
 
-	efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
-
-	/*
-	 * We treat unexpected efuse values as if the SoC was from
-	 * the slowest bin. Expected efuse values are 1-3, slowest
-	 * to fastest.
-	 */
-	if (efuse_value >= 1 && efuse_value <= 3)
-		*versions = efuse_value - 1;
-	else
-		*versions = 0;
+	*versions = opp_data->efuse_xlate(speedbin, len);
 
 	kfree(speedbin);
 	return 0;
-- 
2.30.2



From fusibrandon13 at gmail.com  Thu Dec 21 02:10:12 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 21 Dec 2023 11:10:12 +0100
Subject: [RFC PATCH v2 2/3] cpufreq: sun50i: Add support for D1's speed bin decoding
In-Reply-To: <20231221101013.67204-1-fusibrandon13@gmail.com>
References: <20231221101013.67204-1-fusibrandon13@gmail.com>
Message-ID: <20231221101013.67204-3-fusibrandon13@gmail.com>

Adds support for decoding the efuse value read from D1 efuse speed
bins, and factors out equivalent code for sun50i.

The algorithm is gotten from

https://github.com/Tina-Linux/linux-5.4/blob/master/drivers/cpufreq/sun50i-cpufreq-nvmem.c#L293-L338

and maps an efuse value to either 0 or 1, with 1 meaning stable at
a lower supply voltage for the same clock frequency.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/sun50i-cpufreq-nvmem.c | 34 ++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index fc509fc49..b1cb95308 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -29,6 +29,33 @@ struct sunxi_cpufreq_data {
 	u32 (*efuse_xlate)(u32 *speedbin, size_t len);
 };
 
+static u32 sun20i_efuse_xlate(u32 *speedbin, size_t len)
+{
+	u32 ret, efuse_value = 0;
+	int i;
+
+	for (i = 0; i < len; i++)
+		efuse_value |= ((u32)speedbin[i] << (i * 8));
+
+	switch (efuse_value) {
+	case 0x5e00:
+		/* QFN package */
+		ret = 0;
+		break;
+	case 0x5c00:
+	case 0x7400:
+		/* QFN package */
+		ret = 1;
+		break;
+	case 0x5000:
+	default:
+		/* BGA package */
+		ret = 0;
+	}
+
+	return ret;
+}
+
 static u32 sun50i_efuse_xlate(u32 *speedbin, size_t len)
 {
 	u32 efuse_value = 0;
@@ -46,6 +73,10 @@ static u32 sun50i_efuse_xlate(u32 *speedbin, size_t len)
 		return 0;
 }
 
+struct sunxi_cpufreq_data sun20i_cpufreq_data = {
+	.efuse_xlate = sun20i_efuse_xlate,
+};
+
 struct sunxi_cpufreq_data sun50i_cpufreq_data = {
 	.efuse_xlate = sun50i_efuse_xlate,
 };
@@ -54,6 +85,9 @@ static const struct of_device_id cpu_opp_match_list[] = {
 	{ .compatible = "allwinner,sun50i-h6-operating-points",
 	  .data = &sun50i_cpufreq_data,
 	},
+	{ .compatible = "allwinner,sun20i-d1-operating-points",
+	  .data = &sun20i_cpufreq_data,
+	},
 	{}
 };
 
-- 
2.30.2



From fusibrandon13 at gmail.com  Thu Dec 21 02:10:13 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 21 Dec 2023 11:10:13 +0100
Subject: [RFC PATCH v2 3/3] riscv: dts: allwinner: Fill in OPPs
In-Reply-To: <20231221101013.67204-1-fusibrandon13@gmail.com>
References: <20231221101013.67204-1-fusibrandon13@gmail.com>
Message-ID: <20231221101013.67204-4-fusibrandon13@gmail.com>

Specify two voltage ranges, in order of increasing stability,
for each OPP.

Link: https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L133
Link: https://github.com/mangopi-sbc/tina-linux-5.4/blob/0d4903ebd9d2194ad914686d5b0fc1ddacf11a9d/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L182

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
index 64c3c2e6c..7e2e015e0 100644
--- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
+++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
@@ -39,16 +39,23 @@ cpu0_intc: interrupt-controller {
 	};
 
 	opp_table_cpu: opp-table-cpu {
-		compatible = "operating-points-v2";
+		compatible = "allwinner,sun20i-d1-operating-points";
+		nvmem-cells = <&cpu_speed_grade>;
+		nvmem-cell-names = "speed";
+		opp-shared;
 
 		opp-408000000 {
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <900000 900000 1100000>;
+
+			opp-microvolt-speed0 = <950000 950000 1100000>;
+			opp-microvolt-speed1 = <900000 900000 1100000>;
 		};
 
 		opp-1080000000 {
 			opp-hz = /bits/ 64 <1008000000>;
-			opp-microvolt = <900000 900000 1100000>;
+
+			opp-microvolt-speed0 = <1100000>;
+			opp-microvolt-speed1 = <950000 950000 1100000>;
 		};
 	};
 
@@ -115,3 +122,9 @@ pmu {
 			<0x00000000 0x0000000f 0xffffffff 0xffffffff 0x00020000>;
 	};
 };
+
+&sid {
+	cpu_speed_grade: cpu-speed-grade at 0 {
+		reg = <0x00 0x2>;
+	};
+};
-- 
2.30.2



From neil.armstrong at linaro.org  Thu Dec 21 02:11:07 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Thu, 21 Dec 2023 11:11:07 +0100
Subject: [GIT PULL] amlogic drivers updates for v6.8
Message-ID: <a987f881-1c23-4528-9cb1-e5a875b7e7a8@linaro.org>

Hi,

Here's a couple of non urgent fixes for the meson-sm drivers.

Thanks,
Neil

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

   Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

   https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git tags/amlogic-drivers-for-v6.8

for you to fetch changes up to d8385d7433f9c7d718448465e30d6b8c1207b59f:

   firmware: meson-sm: unmap out_base shmem in error path (2023-11-27 09:17:51 +0100)

----------------------------------------------------------------
Amlogic drivers changes for v6.8:
- meson-sm: unmap out_base shmem in error path
- meson-sm: use dev_groups attrs for sysfs entries

----------------------------------------------------------------
Evgeny Bachinin (2):
       firmware: meson_sm: refactor serial sysfs entry via dev_groups attrs
       firmware: meson-sm: unmap out_base shmem in error path

  drivers/firmware/meson/meson_sm.c | 19 ++++++++-----------
  1 file changed, 8 insertions(+), 11 deletions(-)


From neil.armstrong at linaro.org  Thu Dec 21 02:12:36 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Thu, 21 Dec 2023 11:12:36 +0100
Subject: [GIT PULL] amlogic ARM64 DT updates for v6.8
Message-ID: <e38724be-c9f0-4916-bfd0-d20b316db2da@linaro.org>

Hi,

Here's a set of Amlogic ARM64 DT changes for v6.8, with cleanups
and a set of new HW support for the S4 and C4 Amlogic SoCs.

Neil

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

   Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

   https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git tags/amlogic-arm64-dt-for-v6.8

for you to fetch changes up to eb54ef36282f670c704ed5af8593da62bebba80d:

   arm64: dts: amlogic: fix format for s4 uart node (2023-12-19 10:24:52 +0100)

----------------------------------------------------------------
Amlogic ARM64 DT changes for v6.8:
- DT cleanups
  - s4 uart node
  - drop redundant status=okay
  - minor whitespace cleanup around '='
- Watchdog nodes for S4 & C4 SoCs
- Clock, I2C, SPICC, NAND, Ethernet nodes for S4 And the AQ222 dev board
- Add EEPROM on the jethub-jxx boards
- Update of the amlogic,meson-gx-hhi-sysctrl bindings

----------------------------------------------------------------
Arseniy Krasnov (1):
       arm64: dts: amlogic: meson-axg: pinctrl node for NAND

Huqiang Qin (2):
       arm64: dts: Add watchdog node for Amlogic C3 SoCs
       arm64: dts: Add watchdog node for Amlogic S4 SoCs

Krzysztof Kozlowski (2):
       arm64: dts: amlogic: minor whitespace cleanup around '='
       arm64: dts: amlogic: drop redundant status=okay

Neil Armstrong (1):
       dt-bindings: soc: amlogic,meson-gx-hhi-sysctrl: add example covering meson-axg-hhi-sysctrl

Viacheslav Bocharov (1):
       arm64: dts: meson-axg: jethub-jxx add support for EEPROM

Xianwei Zhao (3):
       arm64: dts: amlogic: add some device nodes for S4
       arm64: dts: amlogic: enable some nodes for board AQ222
       arm64: dts: amlogic: fix format for s4 uart node

  .../soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml  |  33 ++
  arch/arm64/boot/dts/amlogic/amlogic-c3.dtsi        |   6 +
  .../meson-axg-jethome-jethub-j110-rev-2.dts        |  14 +-
  .../meson-axg-jethome-jethub-j110-rev-3.dts        |  12 +
  arch/arm64/boot/dts/amlogic/meson-axg-s400.dts     |   5 -
  arch/arm64/boot/dts/amlogic/meson-axg.dtsi         |  23 ++
  arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts  |   1 -
  arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts |   1 -
  .../boot/dts/amlogic/meson-g12b-bananapi-cm4.dtsi  |   2 +-
  .../boot/dts/amlogic/meson-g12b-bananapi.dtsi      |   2 +-
  arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts  |   1 -
  .../boot/dts/amlogic/meson-g12b-ugoos-am6.dts      |   1 -
  .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |   1 -
  arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts |   1 -
  arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts    |   1 -
  .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi      |   1 -
  .../boot/dts/amlogic/meson-gxbb-wetek-play2.dts    |   1 -
  .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |   1 -
  arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts |   1 -
  .../boot/dts/amlogic/meson-s4-s805x2-aq222.dts     |  60 +++-
  arch/arm64/boot/dts/amlogic/meson-s4.dtsi          | 360 ++++++++++++++++++++-
  arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts   |   1 -
  22 files changed, 504 insertions(+), 25 deletions(-)

-- 
Neil Armstrong <neil.armstrong at linaro.org>
Senior Software Engineer - Linaro Developer Services
https://linaro.org/services


From miquel.raynal at bootlin.com  Thu Dec 21 02:16:03 2023
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Thu, 21 Dec 2023 11:16:03 +0100
Subject: [PATCH RFT 2/2] ARM: dts: mxs: imx28: Fix NAND hierarchy
 description
In-Reply-To: <bf76aa11-7005-4bf8-836b-fce616afcdf4@armadeus.com>
References: <20231218130656.9020-1-wahrenst@gmx.net>
	<20231218130656.9020-2-wahrenst@gmx.net>
	<bf76aa11-7005-4bf8-836b-fce616afcdf4@armadeus.com>
Message-ID: <20231221111603.25c28a05@xps-13>

Hello,

sebastien.szymanski at armadeus.com wrote on Thu, 21 Dec 2023 10:56:09
+0100:

> Hello Stefan,
> 
> On 12/18/23 14:06, Stefan Wahren wrote:
> > The size-cells for GPMI are wrong in imx28.dtsi, which causes the
> > following warning:
> > 
> >      nand-controller at 8000c000: #size-cells:0:0: 0 was expected
> > 
> > The reason for this is the definition of the partitions directly
> > below the nand controller node. According to nand-controller.yaml
> > the NAND chip must be defined as a child of the controller. Even
> > the fixed partitions must be kept in a partitions container.

Bindings evolve over time, we sometimes deprecate them when they are
problematic but:
- the old representations are still accepted (but marked legacy)
- if you want to support the new representation you probably need to
  update the controller driver as well (to support both).

In this case I would expect a deprecation notice rather than a pure
error.

Thanks,
Miqu?l


From xinglong.yang at cixtech.com  Thu Dec 21 02:31:29 2023
From: xinglong.yang at cixtech.com (Xinglong Yang)
Date: Thu, 21 Dec 2023 10:31:29 +0000
Subject: [PATCH] firmware: arm_scmi: Check Mailbox/SMT channel for
 consistency
In-Reply-To: <20231220172112.763539-1-cristian.marussi@arm.com>
References: <20231220172112.763539-1-cristian.marussi@arm.com>
Message-ID: <PUZPR06MB54988A8170D462FC8EE43A05F095A@PUZPR06MB5498.apcprd06.prod.outlook.com>

Hi, Cristian

This patch successfully solves the bug.

From: Cristian Marussi <cristian.marussi at arm.com> Sent: Thursday, December 21, 2023 1:21 AM
> On reception of a completion interrupt the SMT memory area is accessed to
> retrieve the message header at first and then, if the message sequence
> number identifies a transaction which is still pending, the related
> payload is fetched too.
>
> When an SCMI command times out the channel ownership remains with the
> platform until eventually a late reply is received and, as a consequence,
> any further transmission attempt remains pending, waiting for the channel
> to be relinquished by the platform.
>
> Once that late reply is received the channel ownership is given back
> to the agent and any pending request is then allowed to proceed and
> overwrite the SMT area of the just delivered late reply; then the wait for
> the reply to the new request starts.
>
> It has been observed that the spurious IRQ related to the late reply can
> be wrongly associated with the freshly enqueued request: when that
> happens
> the SCMI stack in-flight lookup procedure is fooled by the fact that the
> message header now present in the SMT area is related to the new pending
> transaction, even though the real reply has still to arrive.
>
> This race-condition on the A2P channel can be detected by looking at the
> channel status bits: a genuine reply from the platform will have set the
> channel free bit before triggering the completion IRQ.
>
> Add a consistency check to validate such condition in the A2P ISR.
>
> Reported-by: Xinglong Yang <xinglong.yang at cixtech.com>
> Closes:
> https://lore.k/
> ernel.org%2Fall%2FPUZPR06MB54981E6FA00D82BFDBB864FBF08DA%40PUZP
> R06MB5498.apcprd06.prod.outlook.com%2F&data=05%7C02%7Cxinglong.ya
> ng%40cixtech.com%7C669e9ff5e6764a77791208dc01801b8e%7C0409f77ae53
> d4d23943eccade7cb4811%7C1%7C0%7C638386896955072826%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T1DOD7KfY%2FJNJHacHtX
> d5wcfde%2Fd5UDqGvyW4vuYwYU%3D&reserved=0
> Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of
> the transport type")
> CC: stable at vger.kernel.org # 5.15+
> Signed-off-by: Cristian Marussi <cristian.marussi at arm.com>
> ---
>  drivers/firmware/arm_scmi/common.h  |  1 +
>  drivers/firmware/arm_scmi/mailbox.c | 14 ++++++++++++++
>  drivers/firmware/arm_scmi/shmem.c   |  6 ++++++
>  3 files changed, 21 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/common.h
> b/drivers/firmware/arm_scmi/common.h
> index 3b7c68a11fd0..0956c2443840 100644
> --- a/drivers/firmware/arm_scmi/common.h
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -329,6 +329,7 @@ void shmem_fetch_notification(struct
> scmi_shared_mem __iomem *shmem,
>  void shmem_clear_channel(struct scmi_shared_mem __iomem *shmem);
>  bool shmem_poll_done(struct scmi_shared_mem __iomem *shmem,
>                      struct scmi_xfer *xfer);
> +bool shmem_channel_free(struct scmi_shared_mem __iomem *shmem);
>
>  /* declarations for message passing transports */
>  struct scmi_msg_payld;
> diff --git a/drivers/firmware/arm_scmi/mailbox.c
> b/drivers/firmware/arm_scmi/mailbox.c
> index 19246ed1f01f..b8d470417e8f 100644
> --- a/drivers/firmware/arm_scmi/mailbox.c
> +++ b/drivers/firmware/arm_scmi/mailbox.c
> @@ -45,6 +45,20 @@ static void rx_callback(struct mbox_client *cl, void *m)
>  {
>         struct scmi_mailbox *smbox = client_to_scmi_mailbox(cl);
>
> +       /*
> +        * An A2P IRQ is NOT valid when received while the platform still has
> +        * the ownership of the channel, because the platform at first releases
> +        * the SMT channel and then sends the completion interrupt.
> +        *
> +        * This addresses a possible race condition in which a spurious IRQ from
> +        * a previous timed-out reply which arrived late could be wrongly
> +        * associated with the next pending transaction.
> +        */
> +       if (cl->knows_txdone && !shmem_channel_free(smbox->shmem)) {
> +               dev_warn(smbox->cinfo->dev, "Ignoring spurious A2P IRQ !\n");
> +               return;
> +       }
> +
>         scmi_rx_callback(smbox->cinfo, shmem_read_header(smbox->shmem),
> NULL);
>  }
>
> diff --git a/drivers/firmware/arm_scmi/shmem.c
> b/drivers/firmware/arm_scmi/shmem.c
> index 87b4f4d35f06..517d52fb3bcb 100644
> --- a/drivers/firmware/arm_scmi/shmem.c
> +++ b/drivers/firmware/arm_scmi/shmem.c
> @@ -122,3 +122,9 @@ bool shmem_poll_done(struct scmi_shared_mem
> __iomem *shmem,
>                 (SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR |
>                  SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE);
>  }
> +
> +bool shmem_channel_free(struct scmi_shared_mem __iomem *shmem)
> +{
> +       return (ioread32(&shmem->channel_status) &
> +                       SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE);
> +}
> --
> 2.34.1

Thanks,
Xinglong


From gabriel.fernandez at foss.st.com  Thu Dec 21 02:31:53 2023
From: gabriel.fernandez at foss.st.com (Gabriel FERNANDEZ)
Date: Thu, 21 Dec 2023 11:31:53 +0100
Subject: [PATCH v7 1/2] clk: stm32: introduce clocks for STM32MP257
 platform
In-Reply-To: <c98539f99030f174583d7ee36802b4b9.sboyd@kernel.org>
References: <20231219130909.265091-1-gabriel.fernandez@foss.st.com>
 <20231219130909.265091-2-gabriel.fernandez@foss.st.com>
 <c98539f99030f174583d7ee36802b4b9.sboyd@kernel.org>
Message-ID: <21f758cb-ae25-4d74-905c-0d4820f00070@foss.st.com>


On 12/20/23 23:16, Stephen Boyd wrote:
> Quoting gabriel.fernandez at foss.st.com (2023-12-19 05:09:08)
>> diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
>> new file mode 100644
>> index 000000000000..313e022c6142
>> --- /dev/null
>> +++ b/drivers/clk/stm32/clk-stm32mp25.c
>> @@ -0,0 +1,1826 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
>> + * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/of_address.h>
>> +#include <linux/platform_device.h>
>> +
>> +#include "clk-stm32-core.h"
>> +#include "reset-stm32.h"
>> +#include "stm32mp25_rcc.h"
>> +
>> +#include <dt-bindings/clock/st,stm32mp25-rcc.h>
>> +#include <dt-bindings/reset/st,stm32mp25-rcc.h>
>> +
>> +static const struct clk_parent_data adc12_src[] = {
>> +       { .name = "ck_flexgen_46" },
> This is a new driver. Don't use .name here. Instead use .index or .hw
> and if that can't work then use .fw_name.

These parent clocks are managed by a secure world and exposed through SCMI.

If I use .index or .fw_name, do I have to expose 122 clocks in my DT node ?

This will significantly increase the size of the DT file

 ??? ??? ??? clock-names = "hse", "hsi", ..., "ck_scmi_stm500";
 ?? ???? ??? clocks = <&scmi_clk CK_SCMI_HSE>, <&scmi_clk CK_SCMI_HSI>,? 
... , ? <&scmi_clk CK_SCMI_STM500>;

>
>> +       { .name = "ck_icn_ls_mcu" },
>> +};
>> +
>> +static const struct clk_parent_data adc3_src[] = {
>> +       { .name = "ck_flexgen_47" },
>> +       { .name = "ck_icn_ls_mcu" },
>> +       { .name = "ck_flexgen_46" },
>> +};
> [...]
>> +static struct clk_stm32_composite ck_ker_usb3pciephy = {
>> +       .gate_id = GATE_USB3PCIEPHY,
>> +       .mux_id = MUX_USB3PCIEPHY,
>> +       .div_id = NO_STM32_DIV,
>> +       .hw.init = CLK_HW_INIT_PARENTS_DATA("ck_ker_usb3pciephy", usb3pciphy_src,
>> +                                           &clk_stm32_composite_ops, 0),
>> +};
>> +
>> +/* USB3 DRD */
>> +static struct clk_stm32_gate ck_icn_m_usb3dr = {
>> +       .gate_id = GATE_USB3DR,
>> +       .hw.init = CLK_HW_INIT("ck_icn_m_usb3dr", "ck_icn_hsl", &clk_stm32_gate_ops, 0),
>> +};
>> +
>> +static struct clk_stm32_gate ck_ker_usb2phy2 = {
>> +       .gate_id = GATE_USB3DR,
>> +       .hw.init = CLK_HW_INIT("ck_ker_usb2phy2", "ck_flexgen_58", &clk_stm32_gate_ops, 0),
>> +};
>> +
>> +/* USBTC */
>> +static struct clk_stm32_gate ck_icn_p_usbtc = {
>> +       .gate_id = GATE_USBTC,
>> +       .hw.init = CLK_HW_INIT("ck_icn_p_usbtc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
> Please stop using strings to match parents, i.e. don't use CLK_HW_INIT.
>
>> +};
>> +
>> +static struct clk_stm32_gate ck_ker_usbtc = {
>> +       .gate_id = GATE_USBTC,
>> +       .hw.init = CLK_HW_INIT("ck_ker_usbtc", "ck_flexgen_35", &clk_stm32_gate_ops, 0),
>> +};
>> +
>> +/* VDEC / VENC */
>> +static struct clk_stm32_gate ck_icn_p_vdec = {
>> +       .gate_id = GATE_VDEC,
>> +       .hw.init = CLK_HW_INIT("ck_icn_p_vdec", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
>> +};
>> +
>> +static struct clk_stm32_gate ck_icn_p_venc = {
>> +       .gate_id = GATE_VENC,
>> +       .hw.init = CLK_HW_INIT("ck_icn_p_venc", "ck_icn_apb4", &clk_stm32_gate_ops, 0),
>> +};
>> +
>> +/* VREF */
>> +static struct clk_stm32_gate ck_icn_p_vref = {
>> +       .gate_id = GATE_VREF,
>> +       .hw.init = CLK_HW_INIT("ck_icn_p_vref", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
>> +};
>> +
>> +/* WWDG */
>> +static struct clk_stm32_gate ck_icn_p_wwdg1 = {
>> +       .gate_id = GATE_WWDG1,
>> +       .hw.init = CLK_HW_INIT("ck_icn_p_wwdg1", "ck_icn_apb3", &clk_stm32_gate_ops, 0),
>> +};
>> +
>> +static struct clk_stm32_gate ck_icn_p_wwdg2 = {
>> +       .gate_id = GATE_WWDG2,
>> +       .hw.init = CLK_HW_INIT("ck_icn_p_wwdg2", "ck_icn_ls_mcu", &clk_stm32_gate_ops, 0),
>> +};
>> +
>> +enum security_clk {
>> +       SECF_NONE,
> What is the use of this single value enum?

Yes, just a define is enough for the moment. I will have more 
definitions in my next series to introduce

security (clocks could be managed by a secure world or not).

>> +};
>> +
>> +static const struct clock_config stm32mp25_clock_cfg[] = {
>> +       STM32_GATE_CFG(CK_BUS_ETH1,             ck_icn_p_eth1,          SECF_NONE),
>> +       STM32_GATE_CFG(CK_BUS_ETH2,             ck_icn_p_eth2,          SECF_NONE),
> [....]
>> +
>> +static const struct of_device_id stm32mp25_match_data[] = {
>> +       {
>> +               .compatible = "st,stm32mp25-rcc",
>> +               .data = &stm32mp25_data,
>> +       },
> One line please:
>
>   	{ .compatible = "st,stm32mp25-rcc", .data = &stm32mp25_data, },

ok

>
>> +       { }
>> +};
>> +MODULE_DEVICE_TABLE(of, stm32mp25_match_data);
>> +
>> +static int get_clock_deps(struct device *dev)
> What is the explanation for this function?

It 's to manage the dependency with the SCMI clock driver.


>> +{
>> +       static const char * const clock_deps_name[] = {
>> +               "hsi", "hse", "msi", "lsi", "lse",
>> +       };
>> +       int i;
>> +
>> +       for (i = 0; i < ARRAY_SIZE(clock_deps_name); i++) {
>> +               struct clk *clk;
>> +
>> +               clk = of_clk_get_by_name(dev_of_node(dev), clock_deps_name[i]);
>> +               if (IS_ERR(clk))
>> +                       return PTR_ERR(clk);
>> +
>> +               clk_put(clk);
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int stm32mp25_rcc_clocks_probe(struct platform_device *pdev)
>> +{
>> +       struct device *dev = &pdev->dev;
>> +       void __iomem *base;
>> +       int ret;
>> +
>> +       ret = get_clock_deps(dev);
>> +       if (ret)
>> +               return ret;
>> +
>> +       base = devm_of_iomap(dev, dev->of_node, 0, NULL);
> Use platform device APIs.
>
>> +       if (WARN_ON(IS_ERR(base)))
>> +               return PTR_ERR(base);
>> +
>> +       return stm32_rcc_init(dev, stm32mp25_match_data, base);
>> +}
>> +
>> +static int stm32mp25_rcc_clocks_remove(struct platform_device *pdev)
>> +{
>> +       struct device *dev = &pdev->dev;
>> +       struct device_node *child, *np = dev_of_node(dev);
>> +
>> +       for_each_available_child_of_node(np, child)
>> +               of_clk_del_provider(child);
> Add the providers with devm?

ok


>
>> +
>> +       return 0;
>> +}
>> +
>> +static struct platform_driver stm32mp25_rcc_clocks_driver = {
>> +       .driver = {
>> +               .name = "stm32mp25_rcc",
>> +               .of_match_table = stm32mp25_match_data,
>> +       },
>> +       .probe = stm32mp25_rcc_clocks_probe,
>> +       .remove = stm32mp25_rcc_clocks_remove,
>> +};
>> +
>> +static int __init stm32mp25_clocks_init(void)
>> +{
>> +       return platform_driver_register(&stm32mp25_rcc_clocks_driver);
>> +}
>> +
>> +core_initcall(stm32mp25_clocks_init);


From dmitry.baryshkov at linaro.org  Thu Dec 21 02:32:13 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 12:32:13 +0200
Subject: [PATCH v6 3/5] iommu/arm-smmu: introduction of ACTLR for custom
 prefetcher settings
In-Reply-To: <7b32b7a7-bc64-4102-a6bf-3c3fc8d979ac@quicinc.com>
References: <20231220133808.5654-1-quic_bibekkum@quicinc.com>
 <20231220133808.5654-4-quic_bibekkum@quicinc.com> <CAA8EJpo8X+jfi20N9P7kUshxe6_7pwQe8G0Q02JDuB8ozH7hLA@mail.gmail.com>
 <7b32b7a7-bc64-4102-a6bf-3c3fc8d979ac@quicinc.com>
Message-ID: <CAA8EJpo6LdBQm5q=r2+ETBwhKL3YkUsPDuzA2MGCqb-1R_9b7w@mail.gmail.com>

On Thu, 21 Dec 2023 at 12:02, Bibek Kumar Patro
<quic_bibekkum at quicinc.com> wrote:
>
>
>
> On 12/21/2023 6:06 AM, Dmitry Baryshkov wrote:
> > On Wed, 20 Dec 2023 at 15:39, Bibek Kumar Patro
> > <quic_bibekkum at quicinc.com> wrote:
> >>
> >> Currently in Qualcomm  SoCs the default prefetch is set to 1 which allows
> >> the TLB to fetch just the next page table. MMU-500 features ACTLR
> >> register which is implementation defined and is used for Qualcomm SoCs
> >> to have a custom prefetch setting enabling TLB to prefetch the next set
> >> of page tables accordingly allowing for faster translations.
> >>
> >> ACTLR value is unique for each SMR (Stream matching register) and stored
> >> in a pre-populated table. This value is set to the register during
> >> context bank initialisation.
> >>
> >> Signed-off-by: Bibek Kumar Patro <quic_bibekkum at quicinc.com>
> >> ---
> >>   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 45 ++++++++++++++++++++++
> >>   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h |  6 ++-
> >>   drivers/iommu/arm/arm-smmu/arm-smmu.c      |  5 ++-
> >>   drivers/iommu/arm/arm-smmu/arm-smmu.h      |  5 +++
> >>   4 files changed, 58 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >> index 20c9836d859b..1cefdd0ca110 100644
> >> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> >> @@ -24,6 +24,12 @@
> >>   #define CPRE                   (1 << 1)
> >>   #define CMTLB                  (1 << 0)
> >>
> >> +struct actlr_config {
> >> +       u16 sid;
> >> +       u16 mask;
> >> +       u32 actlr;
> >> +};
> >> +
> >>   static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
> >>   {
> >>          return container_of(smmu, struct qcom_smmu, smmu);
> >> @@ -215,9 +221,38 @@ static bool qcom_adreno_can_do_ttbr1(struct arm_smmu_device *smmu)
> >>          return true;
> >>   }
> >>
> >> +static void qcom_smmu_set_actlr(struct device *dev, struct arm_smmu_device *smmu, int cbndx,
> >> +               const struct actlr_config *actlrcfg)
> >> +{
> >> +       struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
> >> +       struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> >> +       struct arm_smmu_smr *smr;
> >> +       u16 mask;
> >> +       int idx;
> >> +       u16 id;
> >> +       int i;
> >> +
> >> +       for (; actlrcfg->sid || actlrcfg->mask || actlrcfg->actlr; actlrcfg++) {
> >> +               id = actlrcfg->sid;
> >> +               mask = actlrcfg->mask;
> >> +
> >> +               for_each_cfg_sme(cfg, fwspec, i, idx) {
> >> +                       smr = &smmu->smrs[idx];
> >> +                       if (smr_is_subset(smr, id, mask)) {
> >> +                               arm_smmu_cb_write(smmu, cbndx, ARM_SMMU_CB_ACTLR,
> >> +                                               actlrcfg->actlr);
> >> +                               break;
> >> +                       }
> >> +               }
> >> +       }
> >> +}
> >> +
> >>   static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
> >>                  struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
> >>   {
> >> +       struct arm_smmu_device *smmu = smmu_domain->smmu;
> >> +       struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
> >> +       int cbndx = smmu_domain->cfg.cbndx;
> >>          struct adreno_smmu_priv *priv;
> >>
> >>          smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
> >> @@ -248,6 +283,9 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
> >>          priv->set_stall = qcom_adreno_smmu_set_stall;
> >>          priv->resume_translation = qcom_adreno_smmu_resume_translation;
> >>
> >> +       if (qsmmu->data->actlrcfg_gfx)
> >> +               qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg_gfx);
> >
> > There was a feedback point against v4 that there can be more than two
> > (apps + gpu) SMMU devices. No, we can not use additional compat
> > strings, the SMMU units are compatible with each other.
>
> Just to understand better, did you mean if in the below check
> [inside arm-smmu-qcom.c file during qcom_smmu_create()], "else" has two
> things? (Currently adreno_impl for gpu smmu, else for only
> apps smmu)

qcom,adreno-smmu is quite unique here, this is the only distinctive
substring. We do not have such compat strings for any other of SMMU
nodes.

>
>           if (np && of_device_is_compatible(np, "qcom,adreno-smmu"))
>                   impl = data->adreno_impl;
>           else
>                   impl = data->impl;
>
> > Please add
> > matching between the smmu and particular actlr table using the IO
> > address of the SMMU block.
> >
>
> The ACTLR table for each smmu will have A IO address attached, so based
> on IO address we can apply ACTLR.
> Is this your proposal((IMO hardcoding IO in driver won't be viable,
> isn't it?), or in smmu DT we would need to set the IO?

Unfortunately, I meant exactly that: hardcoding addresses of the SMMU
register spaces. see drivers/gpu/drm/msm/dsi_cfg.c
Then during device probe the driver can match the IO address to the
list of the per-platform ACTLR tables and select the correct one.
Then you don't even need a special actlrcfg_gfx. The GFX will fall
into the main schema.

>
>
> Thanks & regards,
> Bibek
>
> >> +
> >>          return 0;
> >>   }
> >>
> >> @@ -274,6 +312,13 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
> >>   static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain,
> >>                  struct io_pgtable_cfg *pgtbl_cfg, struct device *dev)
> >>   {
> >> +       struct arm_smmu_device *smmu = smmu_domain->smmu;
> >> +       struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
> >> +       int cbndx = smmu_domain->cfg.cbndx;
> >> +
> >> +       if (qsmmu->data->actlrcfg)
> >> +               qcom_smmu_set_actlr(dev, smmu, cbndx, qsmmu->data->actlrcfg);
> >> +
> >
> > One issue occured to me, while I was reviewing the patchset. The ACTLR
> > settings are related to the whole SMMU setup, but we are applying them
> > each time there is an SMMU context init (in other words, one per each
> > domain). Is that correct? Or it's just that there is no better place
> > for initialising the global register set? Would it be better to
> > reprogram the ACTLR registers which are related just to this
> > particular domain?
> >
> >>          smmu_domain->cfg.flush_walk_prefer_tlbiasid = true;
> >>
> >>          return 0;
> >> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
> >> index f3b91963e234..cb4cb402c202 100644
> >> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
> >> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h
> >> @@ -1,6 +1,6 @@
> >>   /* SPDX-License-Identifier: GPL-2.0-only */
> >>   /*
> >> - * Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
> >> + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
> >>    */
> >>
> >>   #ifndef _ARM_SMMU_QCOM_H
> >> @@ -24,7 +24,11 @@ struct qcom_smmu_config {
> >>          const u32 *reg_offset;
> >>   };
> >>
> >> +struct actlr_config;
> >> +
> >>   struct qcom_smmu_match_data {
> >> +       const struct actlr_config *actlrcfg;
> >> +       const struct actlr_config *actlrcfg_gfx;
> >>          const struct qcom_smmu_config *cfg;
> >>          const struct arm_smmu_impl *impl;
> >>          const struct arm_smmu_impl *adreno_impl;
> >> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> >> index d6d1a2a55cc0..0c7f700b27dd 100644
> >> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> >> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> >> @@ -990,9 +990,10 @@ static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
> >>                   * expect simply identical entries for this case, but there's
> >>                   * no harm in accommodating the generalisation.
> >>                   */
> >> -               if ((mask & smrs[i].mask) == mask &&
> >> -                   !((id ^ smrs[i].id) & ~smrs[i].mask))
> >> +
> >> +               if (smr_is_subset(&smrs[i], id, mask))
> >>                          return i;
> >> +
> >>                  /*
> >>                   * If the new entry has any other overlap with an existing one,
> >>                   * though, then there always exists at least one stream ID
> >> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> >> index 703fd5817ec1..2e4f65412c6b 100644
> >> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> >> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> >> @@ -501,6 +501,11 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
> >>                  writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);
> >>   }
> >>
> >> +static inline bool smr_is_subset(struct arm_smmu_smr *smrs, u16 id, u16 mask)
> >> +{
> >> +       return (mask & smrs->mask) == mask && !((id ^ smrs->id) & ~smrs->mask);
> >> +}
> >> +
> >>   #define ARM_SMMU_GR0           0
> >>   #define ARM_SMMU_GR1           1
> >>   #define ARM_SMMU_CB(s, n)      ((s)->numpage + (n))
> >> --
> >> 2.17.1
> >>
> >
> >



-- 
With best wishes
Dmitry


From cristian.marussi at arm.com  Thu Dec 21 02:35:30 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Thu, 21 Dec 2023 10:35:30 +0000
Subject: [PATCH] firmware: arm_scmi: Check Mailbox/SMT channel for
 consistency
In-Reply-To: <PUZPR06MB54988A8170D462FC8EE43A05F095A@PUZPR06MB5498.apcprd06.prod.outlook.com>
References: <20231220172112.763539-1-cristian.marussi@arm.com>
 <PUZPR06MB54988A8170D462FC8EE43A05F095A@PUZPR06MB5498.apcprd06.prod.outlook.com>
Message-ID: <ZYQU8n7btB17nvuc@pluto>

On Thu, Dec 21, 2023 at 10:31:29AM +0000, Xinglong Yang wrote:
> Hi, Cristian
> 
> This patch successfully solves the bug.
> 

Hi Xinglong,

thanks for reporting and testing !

Cristian

> From: Cristian Marussi <cristian.marussi at arm.com> Sent: Thursday, December 21, 2023 1:21 AM
> > On reception of a completion interrupt the SMT memory area is accessed to
> > retrieve the message header at first and then, if the message sequence
> > number identifies a transaction which is still pending, the related
> > payload is fetched too.
> >
> > When an SCMI command times out the channel ownership remains with the
> > platform until eventually a late reply is received and, as a consequence,
> > any further transmission attempt remains pending, waiting for the channel
> > to be relinquished by the platform.
> >
> > Once that late reply is received the channel ownership is given back
> > to the agent and any pending request is then allowed to proceed and
> > overwrite the SMT area of the just delivered late reply; then the wait for
> > the reply to the new request starts.
> >
> > It has been observed that the spurious IRQ related to the late reply can
> > be wrongly associated with the freshly enqueued request: when that
> > happens
> > the SCMI stack in-flight lookup procedure is fooled by the fact that the
> > message header now present in the SMT area is related to the new pending
> > transaction, even though the real reply has still to arrive.
> >
> > This race-condition on the A2P channel can be detected by looking at the
> > channel status bits: a genuine reply from the platform will have set the
> > channel free bit before triggering the completion IRQ.
> >
> > Add a consistency check to validate such condition in the A2P ISR.
> >
> > Reported-by: Xinglong Yang <xinglong.yang at cixtech.com>
> > Closes:
> > https://lore.k/
> > ernel.org%2Fall%2FPUZPR06MB54981E6FA00D82BFDBB864FBF08DA%40PUZP
> > R06MB5498.apcprd06.prod.outlook.com%2F&data=05%7C02%7Cxinglong.ya
> > ng%40cixtech.com%7C669e9ff5e6764a77791208dc01801b8e%7C0409f77ae53
> > d4d23943eccade7cb4811%7C1%7C0%7C638386896955072826%7CUnknown%
> > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> > wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T1DOD7KfY%2FJNJHacHtX
> > d5wcfde%2Fd5UDqGvyW4vuYwYU%3D&reserved=0
> > Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of
> > the transport type")
> > CC: stable at vger.kernel.org # 5.15+
> > Signed-off-by: Cristian Marussi <cristian.marussi at arm.com>
> > ---
> >  drivers/firmware/arm_scmi/common.h  |  1 +
> >  drivers/firmware/arm_scmi/mailbox.c | 14 ++++++++++++++
> >  drivers/firmware/arm_scmi/shmem.c   |  6 ++++++
> >  3 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/firmware/arm_scmi/common.h
> > b/drivers/firmware/arm_scmi/common.h
> > index 3b7c68a11fd0..0956c2443840 100644
> > --- a/drivers/firmware/arm_scmi/common.h
> > +++ b/drivers/firmware/arm_scmi/common.h
> > @@ -329,6 +329,7 @@ void shmem_fetch_notification(struct
> > scmi_shared_mem __iomem *shmem,
> >  void shmem_clear_channel(struct scmi_shared_mem __iomem *shmem);
> >  bool shmem_poll_done(struct scmi_shared_mem __iomem *shmem,
> >                      struct scmi_xfer *xfer);
> > +bool shmem_channel_free(struct scmi_shared_mem __iomem *shmem);
> >
> >  /* declarations for message passing transports */
> >  struct scmi_msg_payld;
> > diff --git a/drivers/firmware/arm_scmi/mailbox.c
> > b/drivers/firmware/arm_scmi/mailbox.c
> > index 19246ed1f01f..b8d470417e8f 100644
> > --- a/drivers/firmware/arm_scmi/mailbox.c
> > +++ b/drivers/firmware/arm_scmi/mailbox.c
> > @@ -45,6 +45,20 @@ static void rx_callback(struct mbox_client *cl, void *m)
> >  {
> >         struct scmi_mailbox *smbox = client_to_scmi_mailbox(cl);
> >
> > +       /*
> > +        * An A2P IRQ is NOT valid when received while the platform still has
> > +        * the ownership of the channel, because the platform at first releases
> > +        * the SMT channel and then sends the completion interrupt.
> > +        *
> > +        * This addresses a possible race condition in which a spurious IRQ from
> > +        * a previous timed-out reply which arrived late could be wrongly
> > +        * associated with the next pending transaction.
> > +        */
> > +       if (cl->knows_txdone && !shmem_channel_free(smbox->shmem)) {
> > +               dev_warn(smbox->cinfo->dev, "Ignoring spurious A2P IRQ !\n");
> > +               return;
> > +       }
> > +
> >         scmi_rx_callback(smbox->cinfo, shmem_read_header(smbox->shmem),
> > NULL);
> >  }
> >
> > diff --git a/drivers/firmware/arm_scmi/shmem.c
> > b/drivers/firmware/arm_scmi/shmem.c
> > index 87b4f4d35f06..517d52fb3bcb 100644
> > --- a/drivers/firmware/arm_scmi/shmem.c
> > +++ b/drivers/firmware/arm_scmi/shmem.c
> > @@ -122,3 +122,9 @@ bool shmem_poll_done(struct scmi_shared_mem
> > __iomem *shmem,
> >                 (SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR |
> >                  SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE);
> >  }
> > +
> > +bool shmem_channel_free(struct scmi_shared_mem __iomem *shmem)
> > +{
> > +       return (ioread32(&shmem->channel_status) &
> > +                       SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE);
> > +}
> > --
> > 2.34.1
> 
> Thanks,
> Xinglong
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From andre.przywara at arm.com  Thu Dec 21 02:39:06 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 21 Dec 2023 10:39:06 +0000
Subject: [PATCH RESEND] ARM: dts: sun8i: r40: open the regulator aldo1
In-Reply-To: <ZYOhAQi7XeLUuAC9@debian.cyg>
References: <ZYKjYypuAx7gNuam@debian.cyg>
	<20231220150400.0f32e2a5@donnerap.manchester.arm.com>
	<ZYOhAQi7XeLUuAC9@debian.cyg>
Message-ID: <20231221103906.1830ef94@donnerap.manchester.arm.com>

On Thu, 21 Dec 2023 10:20:49 +0800
fuyao <fuyao at sjterm.com> wrote:

Hi,

thanks for the reply!

> On Wed, Dec 20, 2023 at 03:04:00PM +0000, Andre Przywara wrote:
> > On Wed, 20 Dec 2023 16:18:43 +0800
> > fuyao <fuyao1697 at cyg.com> wrote:
> > 
> > Hi,
> >   
> > > the aldo1 is connect regulator pin which power the TV.  
> > 
> > What do you mean with that? That ALDO1 is connected to VCC-TVOUT and/or
> > VCC-TVIN on the R40 SoC?  
> 
> The ALDO1 is connected to VCC-TVOUT on the R40 Soc.

Ah, thanks for the confirmation.

> > > The USB core use TV ref as reference Voltage.  
> > 
> > The USB core in the SoC? So pin VCC-USB, which requires 3.3V, the same
> > voltage as the TV pins?
> > Which means this doesn't really have much to do with TV, it's just that
> > USB and also "TV" are supplied by ALDO1?  
> 
> The internal USB PHY requires a reference voltage. It seems that in
> order to save costs, the reference voltage of the TVOUT module is used.

Do you mean a USB *reference* voltage that is separate from the USB PHY
power supply voltage, so pin VCC-USB on the SoC? And that it is internally
connected to some TV-OUT related circuits? So that would apply to all
devices using the R40 SoC then?

Or is it simply that the SoC pins VCC-TVOUT and VCC-USB are connected
together, on this SoM?
Do you have access to some schematic? I couldn't find one online easily,
so cannot check this myself.

Thanks,
Andre

> > > Signed-off-by: fuyao <fuyao1697 at cyg.com>
> > > ---
> > >  arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > > index 9f39b5a2bb35..8906170461df 100644
> > > --- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > > +++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > > @@ -42,6 +42,13 @@ &pio {
> > >  	vcc-pg-supply = <&reg_dldo1>;
> > >  };
> > >  
> > > +&reg_aldo1 {
> > > +	regulator-always-on;  
> > 
> > So did USB never work before, with the DT as in mainline?
> >   
> 
> The USB can work, but is unstable. Occasionally disconnected because of
> the D+/D- electrical characteristics.
> 
> > For always-on regulators it would be good to see some rationale why this
> > cannot be referenced by its consumer. If it is really supplying the USB
> > core, that would be a reason, because we don't have a good way of
> > describing this.
> >   
> > > +	regulator-min-microvolt = <3300000>;
> > > +	regulator-max-microvolt = <3300000>;
> > > +	regulator-name = "vcc-aldo1";  
> > 
> > Regulators should be named after their users, so use something like:
> > 	regulator-name = "vcc-3v3-tv-usb";
> >   
> 
> thanks.
> 
> > That then also serves as documentation of why this is always on.
> > 
> > Cheers,
> > Andre
> >   
> > > +};
> > > +
> > >  &reg_aldo2 {
> > >  	regulator-always-on;
> > >  	regulator-min-microvolt = <1800000>;  
> >   
> 



From sudeep.holla at arm.com  Thu Dec 21 02:52:11 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Thu, 21 Dec 2023 10:52:11 +0000
Subject: [PATCH] firmware: arm_scmi: Check Mailbox/SMT channel for
 consistency
In-Reply-To: <PUZPR06MB54988A8170D462FC8EE43A05F095A@PUZPR06MB5498.apcprd06.prod.outlook.com>
References: <20231220172112.763539-1-cristian.marussi@arm.com>
 <PUZPR06MB54988A8170D462FC8EE43A05F095A@PUZPR06MB5498.apcprd06.prod.outlook.com>
Message-ID: <ZYQY20PlVujcKB9H@bogus>

On Thu, Dec 21, 2023 at 10:31:29AM +0000, Xinglong Yang wrote:
> Hi, Cristian
> 
> This patch successfully solves the bug.
>

I take this as:

Tested-by: Xinglong Yang <xinglong.yang at cixtech.com>

Please shout if you don't imply that.

-- 
Regards,
Sudeep


From xinglong.yang at cixtech.com  Thu Dec 21 02:55:03 2023
From: xinglong.yang at cixtech.com (Xinglong Yang)
Date: Thu, 21 Dec 2023 10:55:03 +0000
Subject: [PATCH] firmware: arm_scmi: Check Mailbox/SMT channel for
 consistency
In-Reply-To: <ZYQY20PlVujcKB9H@bogus>
References: <20231220172112.763539-1-cristian.marussi@arm.com>
 <PUZPR06MB54988A8170D462FC8EE43A05F095A@PUZPR06MB5498.apcprd06.prod.outlook.com>
 <ZYQY20PlVujcKB9H@bogus>
Message-ID: <PUZPR06MB5498E03F4E6F59E44295AEB2F095A@PUZPR06MB5498.apcprd06.prod.outlook.com>

It is ok.

From: Sudeep Holla <sudeep.holla at arm.com> Sent: Thursday, December 21, 2023 6:52 PM
> On Thu, Dec 21, 2023 at 10:31:29AM +0000, Xinglong Yang wrote:
> > Hi, Cristian
> >
> > This patch successfully solves the bug.
> >
> 
> I take this as:
> 
> Tested-by: Xinglong Yang <xinglong.yang at cixtech.com>
> 
> Please shout if you don't imply that.
> 
> --
> Regards,
> Sudeep

Thanks,
Xinglong


From florian.fainelli at broadcom.com  Thu Dec 21 03:14:43 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Thu, 21 Dec 2023 12:14:43 +0100
Subject: [PATCH] irqchip/irq-brcmstb-l2: add write memory barrier before
 exit
In-Reply-To: <20231220193207.1089469-1-opendmb@gmail.com>
References: <20231220193207.1089469-1-opendmb@gmail.com>
Message-ID: <b70b649c-906f-41a5-8057-91dcfff346d0@broadcom.com>



On 12/20/2023 8:32 PM, Doug Berger wrote:
> It was observed on Broadcom devices that use GIC v3 architecture
> L1 interrupt controllers as the parent of brcmstb-l2 interrupt
> controllers that the deactivation of the parent irq could happen
> before the brcmstb-l2 deasserted its output. This would lead the
> GIC to reactivate the irq only to find that no L2 interrupt was
> pending. The result was a spurious interrupt invoking the
> handle_bad_irq() with its associated messaging. While this did
> not create a functional problem it is a waste of cycles.
> 
> The hazard exists because the memory mapped bus writes to the
> brcmstb-l2 registers are buffered and the GIC v3 architecture
> uses a very efficient system register write to deactivate the
> interrupt. This commit adds a write memory barrier prior to
> invoking chained_irq_exit() to introduce a dsb(st) on those
> systems to ensure the system register write cannot be executed
> until the memory mapped writes are visible to the system.
> 
> Signed-off-by: Doug Berger <opendmb at gmail.com>

Acked-by: Florian Fainelli <florian.fainelli at broadcom.com>

I would be even keen on slapping a:

Fixes: 7f646e92766e ("irqchip: brcmstb-l2: Add Broadcom Set Top Box 
Level-2 interrupt controller")

Thanks Doug!
-- 
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231221/1482f6f9/attachment-0001.p7s>

From u.kleine-koenig at pengutronix.de  Thu Dec 21 03:17:31 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Thu, 21 Dec 2023 12:17:31 +0100
Subject: [PATCH] MAINTAINERS: pwm: Thierry steps down, Uwe takes over
In-Reply-To: <ZYQMA-tM-zl5IJyC@orome.fritz.box>
References: <20231206214817.1783227-2-u.kleine-koenig@pengutronix.de>
 <ZXM72QYBbb32Q_aL@orome.fritz.box>
 <20231208190620.5qobgtyii2wt7tfa@pengutronix.de>
 <ZXbsDRslZNKCeJF9@orome.fritz.box>
 <20231211141900.x6tpyctch5fv3uqf@pengutronix.de>
 <ZXcpswXxb1oQldp5@orome.fritz.box>
 <20231212203352.wl3rzob75fct4lov@pengutronix.de>
 <ZYMPc50eBi6oBClu@orome.fritz.box>
 <6nj7rmq36hj5m26b7yhlbmpfps5wuxkx4zwyvttg4cpgocimj7@xtqm4qleo3s6>
 <ZYQMA-tM-zl5IJyC@orome.fritz.box>
Message-ID: <bgydjom2y32ahs7y5o5xel67ybpifydmeokc7ew7ocm66gway2@v76vqgxrw3ho>

Hello Thierry,

On Thu, Dec 21, 2023 at 10:57:23AM +0100, Thierry Reding wrote:
> Looks all good to me. I'll keep things going until the next merge window
> and will then send out my last PWM pull request and let Linus know to
> expect future requests to come from you.

Sounds good.

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231221/d3afa743/attachment.sig>

From sebastian.fricke at collabora.com  Thu Dec 21 03:18:30 2023
From: sebastian.fricke at collabora.com (Sebastian Fricke)
Date: Thu, 21 Dec 2023 12:18:30 +0100
Subject: [PATCH v5 2/5] media: hantro: add support for STM32MP25 VDEC
In-Reply-To: <20231221084723.2152034-3-hugues.fruchet@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <20231221084723.2152034-3-hugues.fruchet@foss.st.com>
Message-ID: <20231221111830.gx23e6t354jadujk@basti-XPS-13-9310>

Hey Hugues,

On 21.12.2023 09:47, Hugues Fruchet wrote:
>Add support for STM32MP25 VDEC video hardware decoder.
>Support of H264/VP8 decoding.
>No post-processor support.
>VDEC has its own reset/clock/irq.
>
>Sucessfully tested up to full HD.

s/Sucessfully/Successfully/

if this turns out to be the only problem, then I can fix it up for the
PR.

Greetings,
Sebastian

>
>Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
>Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>
>---
> drivers/media/platform/verisilicon/Kconfig    | 14 ++-
> drivers/media/platform/verisilicon/Makefile   |  3 +
> .../media/platform/verisilicon/hantro_drv.c   |  3 +
> .../media/platform/verisilicon/hantro_hw.h    |  1 +
> .../platform/verisilicon/stm32mp25_vdec_hw.c  | 92 +++++++++++++++++++
> 5 files changed, 110 insertions(+), 3 deletions(-)
> create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>
>diff --git a/drivers/media/platform/verisilicon/Kconfig b/drivers/media/platform/verisilicon/Kconfig
>index e65b836b9d78..7642ff9cf96c 100644
>--- a/drivers/media/platform/verisilicon/Kconfig
>+++ b/drivers/media/platform/verisilicon/Kconfig
>@@ -4,7 +4,7 @@ comment "Verisilicon media platform drivers"
>
> config VIDEO_HANTRO
> 	tristate "Hantro VPU driver"
>-	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || COMPILE_TEST
>+	depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || ARCH_SUNXI || ARCH_STM32 || COMPILE_TEST
> 	depends on V4L_MEM2MEM_DRIVERS
> 	depends on VIDEO_DEV
> 	select MEDIA_CONTROLLER
>@@ -16,8 +16,8 @@ config VIDEO_HANTRO
> 	select V4L2_VP9
> 	help
> 	  Support for the Hantro IP based Video Processing Units present on
>-	  Rockchip and NXP i.MX8M SoCs, which accelerate video and image
>-	  encoding and decoding.
>+	  Rockchip, NXP i.MX8M and STM32MP25 SoCs, which accelerate video
>+	  and image encoding and decoding.
> 	  To compile this driver as a module, choose M here: the module
> 	  will be called hantro-vpu.
>
>@@ -52,3 +52,11 @@ config VIDEO_HANTRO_SUNXI
> 	default y
> 	help
> 	  Enable support for H6 SoC.
>+
>+config VIDEO_HANTRO_STM32MP25
>+	bool "Hantro STM32MP25 support"
>+	depends on VIDEO_HANTRO
>+	depends on ARCH_STM32 || COMPILE_TEST
>+	default y
>+	help
>+	  Enable support for STM32MP25 SoCs.
>diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
>index 6ad2ef885920..5854e0f0dd32 100644
>--- a/drivers/media/platform/verisilicon/Makefile
>+++ b/drivers/media/platform/verisilicon/Makefile
>@@ -39,3 +39,6 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_ROCKCHIP) += \
>
> hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
> 		sunxi_vpu_hw.o
>+
>+hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
>+		stm32mp25_vdec_hw.o
>diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
>index a9fa05ac56a9..2db27c333924 100644
>--- a/drivers/media/platform/verisilicon/hantro_drv.c
>+++ b/drivers/media/platform/verisilicon/hantro_drv.c
>@@ -733,6 +733,9 @@ static const struct of_device_id of_hantro_match[] = {
> #endif
> #ifdef CONFIG_VIDEO_HANTRO_SUNXI
> 	{ .compatible = "allwinner,sun50i-h6-vpu-g2", .data = &sunxi_vpu_variant, },
>+#endif
>+#ifdef CONFIG_VIDEO_HANTRO_STM32MP25
>+	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
> #endif
> 	{ /* sentinel */ }
> };
>diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
>index 7f33f7b07ce4..b7eccc1a96fc 100644
>--- a/drivers/media/platform/verisilicon/hantro_hw.h
>+++ b/drivers/media/platform/verisilicon/hantro_hw.h
>@@ -406,6 +406,7 @@ extern const struct hantro_variant rk3568_vpu_variant;
> extern const struct hantro_variant rk3588_vpu981_variant;
> extern const struct hantro_variant sama5d4_vdec_variant;
> extern const struct hantro_variant sunxi_vpu_variant;
>+extern const struct hantro_variant stm32mp25_vdec_variant;
>
> extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
> extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
>diff --git a/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>new file mode 100644
>index 000000000000..aa8b0f751390
>--- /dev/null
>+++ b/drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>@@ -0,0 +1,92 @@
>+// SPDX-License-Identifier: GPL-2.0
>+/*
>+ * STM32MP25 VDEC video decoder driver
>+ *
>+ * Copyright (C) STMicroelectronics SA 2022
>+ * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
>+ *          for STMicroelectronics.
>+ *
>+ */
>+
>+#include "hantro.h"
>+
>+/*
>+ * Supported formats.
>+ */
>+
>+static const struct hantro_fmt stm32mp25_vdec_fmts[] = {
>+	{
>+		.fourcc = V4L2_PIX_FMT_NV12,
>+		.codec_mode = HANTRO_MODE_NONE,
>+		.frmsize = {
>+			.min_width = FMT_MIN_WIDTH,
>+			.max_width = FMT_FHD_WIDTH,
>+			.step_width = MB_DIM,
>+			.min_height = FMT_MIN_HEIGHT,
>+			.max_height = FMT_FHD_HEIGHT,
>+			.step_height = MB_DIM,
>+		},
>+	},
>+	{
>+		.fourcc = V4L2_PIX_FMT_VP8_FRAME,
>+		.codec_mode = HANTRO_MODE_VP8_DEC,
>+		.max_depth = 2,
>+		.frmsize = {
>+			.min_width = FMT_MIN_WIDTH,
>+			.max_width = FMT_FHD_WIDTH,
>+			.step_width = MB_DIM,
>+			.min_height = FMT_MIN_HEIGHT,
>+			.max_height = FMT_FHD_HEIGHT,
>+			.step_height = MB_DIM,
>+		},
>+	},
>+	{
>+		.fourcc = V4L2_PIX_FMT_H264_SLICE,
>+		.codec_mode = HANTRO_MODE_H264_DEC,
>+		.max_depth = 2,
>+		.frmsize = {
>+			.min_width = FMT_MIN_WIDTH,
>+			.max_width = FMT_FHD_WIDTH,
>+			.step_width = MB_DIM,
>+			.min_height = FMT_MIN_HEIGHT,
>+			.max_height = FMT_FHD_HEIGHT,
>+			.step_height = MB_DIM,
>+		},
>+	},
>+};
>+
>+/*
>+ * Supported codec ops.
>+ */
>+
>+static const struct hantro_codec_ops stm32mp25_vdec_codec_ops[] = {
>+	[HANTRO_MODE_VP8_DEC] = {
>+		.run = hantro_g1_vp8_dec_run,
>+		.reset = hantro_g1_reset,
>+		.init = hantro_vp8_dec_init,
>+		.exit = hantro_vp8_dec_exit,
>+	},
>+	[HANTRO_MODE_H264_DEC] = {
>+		.run = hantro_g1_h264_dec_run,
>+		.reset = hantro_g1_reset,
>+		.init = hantro_h264_dec_init,
>+		.exit = hantro_h264_dec_exit,
>+	},
>+};
>+
>+static const struct hantro_irq stm32mp25_irqs[] = {
>+	{ "vdec", hantro_g1_irq },
>+};
>+
>+static const char * const stm32mp25_clk_names[] = { "vdec-clk" };
>+
>+const struct hantro_variant stm32mp25_vdec_variant = {
>+	.dec_fmts = stm32mp25_vdec_fmts,
>+	.num_dec_fmts = ARRAY_SIZE(stm32mp25_vdec_fmts),
>+	.codec = HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
>+	.codec_ops = stm32mp25_vdec_codec_ops,
>+	.irqs = stm32mp25_irqs,
>+	.num_irqs = ARRAY_SIZE(stm32mp25_irqs),
>+	.clk_names = stm32mp25_clk_names,
>+	.num_clocks = ARRAY_SIZE(stm32mp25_clk_names),
>+};
>-- 
>2.25.1
>
>


From sebastian.fricke at collabora.com  Thu Dec 21 03:18:37 2023
From: sebastian.fricke at collabora.com (Sebastian Fricke)
Date: Thu, 21 Dec 2023 12:18:37 +0100
Subject: [PATCH v5 3/5] media: hantro: add support for STM32MP25 VENC
In-Reply-To: <20231221084723.2152034-4-hugues.fruchet@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <20231221084723.2152034-4-hugues.fruchet@foss.st.com>
Message-ID: <20231221111837.4u22pmba7jd3hinj@basti-XPS-13-9310>

Hey Hugues,

one small comment below, if it should turn out to be the only problem I
can fix it myself for the pull request.

On 21.12.2023 09:47, Hugues Fruchet wrote:
>Add support for STM32MP25 VENC video hardware encoder.
>Support of JPEG encoding.
>VENC has its own reset/clock/irq.
>
>Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
>Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>
>---
> drivers/media/platform/verisilicon/Makefile   |   3 +-
> .../media/platform/verisilicon/hantro_drv.c   |   1 +
> .../media/platform/verisilicon/hantro_hw.h    |   1 +
> .../platform/verisilicon/stm32mp25_venc_hw.c  | 115 ++++++++++++++++++
> 4 files changed, 119 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>
>diff --git a/drivers/media/platform/verisilicon/Makefile b/drivers/media/platform/verisilicon/Makefile
>index 5854e0f0dd32..3bf43fdbedc1 100644
>--- a/drivers/media/platform/verisilicon/Makefile
>+++ b/drivers/media/platform/verisilicon/Makefile
>@@ -41,4 +41,5 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
> 		sunxi_vpu_hw.o
>
> hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
>-		stm32mp25_vdec_hw.o
>+		stm32mp25_vdec_hw.o \
>+		stm32mp25_venc_hw.o
>diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
>index 2db27c333924..4d97a8ac03de 100644
>--- a/drivers/media/platform/verisilicon/hantro_drv.c
>+++ b/drivers/media/platform/verisilicon/hantro_drv.c
>@@ -736,6 +736,7 @@ static const struct of_device_id of_hantro_match[] = {
> #endif
> #ifdef CONFIG_VIDEO_HANTRO_STM32MP25
> 	{ .compatible = "st,stm32mp25-vdec", .data = &stm32mp25_vdec_variant, },
>+	{ .compatible = "st,stm32mp25-venc", .data = &stm32mp25_venc_variant, },
> #endif
> 	{ /* sentinel */ }
> };
>diff --git a/drivers/media/platform/verisilicon/hantro_hw.h b/drivers/media/platform/verisilicon/hantro_hw.h
>index b7eccc1a96fc..70c72e9d11d5 100644
>--- a/drivers/media/platform/verisilicon/hantro_hw.h
>+++ b/drivers/media/platform/verisilicon/hantro_hw.h
>@@ -407,6 +407,7 @@ extern const struct hantro_variant rk3588_vpu981_variant;
> extern const struct hantro_variant sama5d4_vdec_variant;
> extern const struct hantro_variant sunxi_vpu_variant;
> extern const struct hantro_variant stm32mp25_vdec_variant;
>+extern const struct hantro_variant stm32mp25_venc_variant;
>
> extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
> extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
>diff --git a/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>new file mode 100644
>index 000000000000..0ff0f073b922
>--- /dev/null
>+++ b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>@@ -0,0 +1,115 @@
>+// SPDX-License-Identifier: GPL-2.0
>+/*
>+ * STM32MP25 VENC video encoder driver
>+ *
>+ * Copyright (C) STMicroelectronics SA 2022
>+ * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
>+ *          for STMicroelectronics.
>+ *
>+ */
>+
>+#include <linux/clk.h>
>+#include <linux/delay.h>
>+#include <linux/reset.h>
>+
>+#include "hantro.h"
>+#include "hantro_jpeg.h"
>+#include "hantro_h1_regs.h"
>+
>+/*
>+ * Supported formats.
>+ */
>+
>+static const struct hantro_fmt stm32mp25_venc_fmts[] = {
>+	{
>+		.fourcc = V4L2_PIX_FMT_YUV420M,
>+		.codec_mode = HANTRO_MODE_NONE,
>+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420P,
>+	},
>+	{
>+		.fourcc = V4L2_PIX_FMT_NV12M,
>+		.codec_mode = HANTRO_MODE_NONE,
>+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420SP,
>+	},
>+	{
>+		.fourcc = V4L2_PIX_FMT_YUYV,
>+		.codec_mode = HANTRO_MODE_NONE,
>+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUYV422,
>+	},
>+	{
>+		.fourcc = V4L2_PIX_FMT_UYVY,
>+		.codec_mode = HANTRO_MODE_NONE,
>+		.enc_fmt = ROCKCHIP_VPU_ENC_FMT_UYVY422,
>+	},
>+	{
>+		.fourcc = V4L2_PIX_FMT_JPEG,
>+		.codec_mode = HANTRO_MODE_JPEG_ENC,
>+		.max_depth = 2,
>+		.header_size = JPEG_HEADER_SIZE,
>+		.frmsize = {
>+			.min_width = 96,
>+			.max_width = FMT_4K_WIDTH,
>+			.step_width = MB_DIM,
>+			.min_height = 96,
>+			.max_height = FMT_4K_HEIGHT,
>+			.step_height = MB_DIM,
>+		},
>+	},
>+};
>+
>+static irqreturn_t stm32mp25_venc_irq(int irq, void *dev_id)
>+{
>+	struct hantro_dev *vpu = dev_id;
>+	enum vb2_buffer_state state;
>+	u32 status;
>+
>+	status = vepu_read(vpu, H1_REG_INTERRUPT);
>+	state = (status & H1_REG_INTERRUPT_FRAME_RDY) ?
>+		VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
>+
>+	vepu_write(vpu, H1_REG_INTERRUPT_BIT, H1_REG_INTERRUPT);
>+
>+	hantro_irq_done(vpu, state);
>+
>+	return IRQ_HANDLED;
>+}
>+
>+static void stm32mp25_venc_reset(struct hantro_ctx *ctx)
>+{
>+}
>+
>+/*
>+ * Supported codec ops.
>+ */
>+
>+static const struct hantro_codec_ops stm32mp25_venc_codec_ops[] = {
>+	[HANTRO_MODE_JPEG_ENC] = {
>+		.run = hantro_h1_jpeg_enc_run,
>+		.reset = stm32mp25_venc_reset,
>+		.done = hantro_h1_jpeg_enc_done,
>+	},
>+};
>+
>+/*
>+ * Variants.
>+ */
>+
>+static const struct hantro_irq stm32mp25_venc_irqs[] = {
>+	{ "venc", stm32mp25_venc_irq },
>+};
>+
>+static const char * const stm32mp25_venc_clk_names[] = {
>+	"venc-clk"
>+};
>+
>+const struct hantro_variant stm32mp25_venc_variant = {
>+	.enc_fmts = stm32mp25_venc_fmts,
>+	.num_enc_fmts = ARRAY_SIZE(stm32mp25_venc_fmts),
>+	.codec = HANTRO_JPEG_ENCODER,
>+	.codec_ops = stm32mp25_venc_codec_ops,
>+	.irqs = stm32mp25_venc_irqs,
>+	.num_irqs = ARRAY_SIZE(stm32mp25_venc_irqs),
>+	.clk_names = stm32mp25_venc_clk_names,
>+	.num_clocks = ARRAY_SIZE(stm32mp25_venc_clk_names)
>+};
>+

There is an superfluous new line here.

Greetings,
Sebastian

>-- 
>2.25.1
>
>


From j-choudhary at ti.com  Thu Dec 21 03:30:42 2023
From: j-choudhary at ti.com (Jayesh Choudhary)
Date: Thu, 21 Dec 2023 17:00:42 +0530
Subject: [PATCH] arm64: dts: ti: k3-am69-sk: remove assigned-clock-parents for unused VP
Message-ID: <20231221113042.48492-1-j-choudhary@ti.com>

VP2 and VP3 are unused video ports and VP3 share the same parent
clock as VP1 causing issue with pixel clock setting for HDMI (VP1).
So remove the parent clocks for unused VPs.

Fixes: 6f8605fd7d11 ("arm64: dts: ti: k3-am69-sk: Add DP and HDMI support")
Reported-by: Nishanth Menon <nm at ti.com>
Closes: https://storage.kernelci.org/mainline/master/v6.7-rc6/arm64/defconfig/gcc-10/lab-ti/baseline-nfs-am69_sk-fs.txt
Signed-off-by: Jayesh Choudhary <j-choudhary at ti.com>
---

Local testing log for HDMI on AM69-SK:
<https://gist.github.com/Jayesh2000/517395cd85eb28d65b8ee4568cefb809>

 arch/arm64/boot/dts/ti/k3-am69-sk.dts | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
index 8da591579868..370980eb59b0 100644
--- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
@@ -918,13 +918,9 @@ &dss {
 	pinctrl-names = "default";
 	pinctrl-0 = <&dss_vout0_pins_default>;
 	assigned-clocks = <&k3_clks 218 2>,
-			  <&k3_clks 218 5>,
-			  <&k3_clks 218 14>,
-			  <&k3_clks 218 18>;
+			  <&k3_clks 218 5>;
 	assigned-clock-parents = <&k3_clks 218 3>,
-				 <&k3_clks 218 7>,
-				 <&k3_clks 218 16>,
-				 <&k3_clks 218 22>;
+				 <&k3_clks 218 7>;
 };
 
 &serdes_wiz4 {
-- 
2.25.1



From angelogioacchino.delregno at collabora.com  Thu Dec 21 03:43:06 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 21 Dec 2023 12:43:06 +0100
Subject: [PATCH v2 3/4] media: mediatek: vcodec: Update
 mtk_vcodec_mem_free() error messages
In-Reply-To: <20231221092226.1395427-3-fshao@chromium.org>
References: <20231221092226.1395427-1-fshao@chromium.org>
 <20231221092226.1395427-3-fshao@chromium.org>
Message-ID: <e822fa39-ba03-4816-a58e-a8328c39e051@collabora.com>

Il 21/12/23 10:17, Fei Shao ha scritto:
> In mtk_vcodec_mem_free(), there are two cases where a NULL VA is passed:
> - mem->size == 0: we are called to free no memory. This may happen when
>    we call mtk_vcodec_mem_free() twice or the memory has never been
>    allocated.
> - mem->size > 0: we are called to free memory but without VA. This means
>    that we failed to free the memory for real.
> 
> Both cases are not expected to happen, and we want to have clearer error
> messages to describe which one we just encountered.
> Update the error messages to include more information for that purpose.
> 
> Signed-off-by: Fei Shao <fshao at chromium.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From angelogioacchino.delregno at collabora.com  Thu Dec 21 03:43:07 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 21 Dec 2023 12:43:07 +0100
Subject: [PATCH v2 4/4] media: mediatek: vcodec: Only free buffer VA that
 is not NULL
In-Reply-To: <20231221092226.1395427-4-fshao@chromium.org>
References: <20231221092226.1395427-1-fshao@chromium.org>
 <20231221092226.1395427-4-fshao@chromium.org>
Message-ID: <d962815b-087d-4851-b6f0-981531149be9@collabora.com>

Il 21/12/23 10:17, Fei Shao ha scritto:
> In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly
> called only when the buffer to free exists, there are some instances
> that didn't do the check and triggered warnings in practice.
> 
> We believe those checks were forgotten unintentionally. Add the checks
> back to fix the warnings.
> 
> Signed-off-by: Fei Shao <fshao at chromium.org>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>




From rogerq at kernel.org  Thu Dec 21 04:27:58 2023
From: rogerq at kernel.org (Roger Quadros)
Date: Thu, 21 Dec 2023 14:27:58 +0200
Subject: [RFC PATCH net-next 1/8] dt-bindings: net: Add support for AM65x
 SR1.0 in ICSSG
In-Reply-To: <20231219174548.3481-2-diogo.ivo@siemens.com>
References: <20231219174548.3481-1-diogo.ivo@siemens.com>
 <20231219174548.3481-2-diogo.ivo@siemens.com>
Message-ID: <37f1df31-82c7-49ae-8f21-0939b04115e6@kernel.org>

Hi,

On 19/12/2023 19:45, Diogo Ivo wrote:
> Silicon Revision 1.0 of the AM65x came with a slightly different ICSSG
> support: Only 2 PRUs per slice are available and instead 2 additional
> DMA channels are used for management purposes. We have no restrictions
> on specified PRUs, but the DMA channels need to be adjusted.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> Signed-off-by: Diogo Ivo <diogo.ivo at siemens.com>
> ---
>  .../bindings/net/ti,icssg-prueth.yaml         | 62 +++++++++++++------
>  1 file changed, 44 insertions(+), 18 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
> index 229c8f32019f..fbe51731854a 100644
> --- a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
> +++ b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
> @@ -19,30 +19,15 @@ allOf:
>  properties:
>    compatible:
>      enum:
> -      - ti,am642-icssg-prueth  # for AM64x SoC family
> -      - ti,am654-icssg-prueth  # for AM65x SoC family
> +      - ti,am642-icssg-prueth      # for AM64x SoC family
> +      - ti,am654-icssg-prueth      # for AM65x SoC family, SR2.x

You don't need to explicitly mention SR2.x here and in the rest of the patches.
That way there are fewer changes.

> +      - ti,am654-icssg-prueth-sr1  # for AM65x SoC family, SR1.0
>  
>    sram:
>      $ref: /schemas/types.yaml#/definitions/phandle
>      description:
>        phandle to MSMC SRAM node
>  
> -  dmas:
> -    maxItems: 10
> -
> -  dma-names:
> -    items:
> -      - const: tx0-0
> -      - const: tx0-1
> -      - const: tx0-2
> -      - const: tx0-3
> -      - const: tx1-0
> -      - const: tx1-1
> -      - const: tx1-2
> -      - const: tx1-3
> -      - const: rx0
> -      - const: rx1
> -
>    ti,mii-g-rt:
>      $ref: /schemas/types.yaml#/definitions/phandle
>      description:
> @@ -122,6 +107,47 @@ properties:
>        - required:
>            - port at 1
>  
> +if:
> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - ti,am654-icssg-prueth-sr1
> +then:
> +  properties:
> +    dmas:
> +      maxItems: 12
> +    dma-names:
> +      items:
> +        - const: tx0-0
> +        - const: tx0-1
> +        - const: tx0-2
> +        - const: tx0-3
> +        - const: tx1-0
> +        - const: tx1-1
> +        - const: tx1-2
> +        - const: tx1-3
> +        - const: rx0
> +        - const: rx1
> +        - const: rxmgm0
> +        - const: rxmgm1
> +else:
> +  properties:
> +    dmas:
> +      maxItems: 10
> +    dma-names:
> +      items:
> +        - const: tx0-0
> +        - const: tx0-1
> +        - const: tx0-2
> +        - const: tx0-3
> +        - const: tx1-0
> +        - const: tx1-1
> +        - const: tx1-2
> +        - const: tx1-3
> +        - const: rx0
> +        - const: rx1
> +
>  required:
>    - compatible
>    - sram

-- 
cheers,
-roger


From michal.simek at amd.com  Thu Dec 21 04:27:54 2023
From: michal.simek at amd.com (Michal Simek)
Date: Thu, 21 Dec 2023 13:27:54 +0100
Subject: [PATCH v3 1/4] dt-bindings: firmware: xilinx: Describe missing child nodes
In-Reply-To: <cover.1703161663.git.michal.simek@amd.com>
References: <cover.1703161663.git.michal.simek@amd.com>
Message-ID: <1d7988cfadf3554d11f0779f96a670b4fd86ce5a.1703161663.git.michal.simek@amd.com>

Firmware node has more than fpga, aes and clock child nodes but also power,
reset, gpio, pinctrl and pcap which are not described yet.
All of them have binding in separate files but there is missing connection
to firmware node that's why describe it.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

Changes in v3:
- s/power-controller/power-management/g
- extend example

Changes in v2:
- Sort nodes by name
- Rename zynqmp-power to power-controller
- Keep only single patch for easier handling as done in v1

 .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index 98945220c33c..884917edb19d 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -41,6 +41,37 @@ properties:
   "#power-domain-cells":
     const: 1
 
+  gpio:
+    $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
+    description: The gpio node describes connect to PS_MODE pins via firmware
+      interface.
+    type: object
+
+  pcap:
+    $ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml
+    description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to
+      configure the Programmable Logic (PL). The configuration uses the
+      firmware interface.
+    type: object
+
+  pinctrl:
+    $ref: /schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+    description: The pinctrl node provides access to pinconfig and pincontrol
+      functionality available in firmware.
+    type: object
+
+  power-management:
+    $ref: /schemas/power/reset/xlnx,zynqmp-power.yaml#
+    description: The zynqmp-power node describes the power management
+      configurations. It will control remote suspend/shutdown interfaces.
+    type: object
+
+  reset-controller:
+    $ref: /schemas/reset/xlnx,zynqmp-reset.yaml#
+    description: The reset-controller node describes connection to the reset
+      functionality via firmware interface.
+    type: object
+
   versal-fpga:
     $ref: /schemas/fpga/xlnx,versal-fpga.yaml#
     description: Compatible of the FPGA device.
@@ -73,7 +104,26 @@ examples:
     firmware {
       zynqmp_firmware: zynqmp-firmware {
         #power-domain-cells = <1>;
+        gpio {
+          compatible = "xlnx,zynqmp-gpio-modepin";
+          gpio-controller;
+          #gpio-cells = <2>;
+        };
+        pcap {
+          compatible = "xlnx,zynqmp-pcap-fpga";
+        };
+        pinctrl {
+          compatible = "xlnx,zynqmp-pinctrl";
         };
+        power-management {
+          compatible = "xlnx,zynqmp-power";
+          interrupts = <0 35 4>;
+        };
+        reset-controller {
+          compatible = "xlnx,zynqmp-reset";
+          #reset-cells = <1>;
+        };
+      };
     };
 
     sata {
-- 
2.36.1



From michal.simek at amd.com  Thu Dec 21 04:27:53 2023
From: michal.simek at amd.com (Michal Simek)
Date: Thu, 21 Dec 2023 13:27:53 +0100
Subject: [PATCH v3 0/4] dt-bindings: xilinx: Add missing firmware child nodes
Message-ID: <cover.1703161663.git.michal.simek@amd.com>

Hi,

series is converting missing descriptions for child nodes and also
synchronizing name for power-management discussed with Krzysztof in v1
version available here.
https://lore.kernel.org/r/fc7863a2-d3c5-47c8-9484-ef9cd6d7dd5d at linaro.org

Thanks,
Michal

Changes in v3:
- s/power-controller/power-management/g
- extend example
- s/power-controller/power-management/g
- align commit message
- s/power-controller/power-management/g
- update subject and commit message to match sed above

Changes in v2:
- Sort nodes by name
- Rename zynqmp-power to power-controller
- Keep only single patch for easier handling as done in v1
- New patch in series
- New patch is series
- New patch is series

Michal Simek (4):
  dt-bindings: firmware: xilinx: Describe missing child nodes
  dt-bindings: firmware: xilinx: Sort node names (clock-controller)
  dt-bindings: power: reset: xilinx: Rename node names in examples
  arm64: zynqmp: Rename zynqmp-power node to power-management

 .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 68 ++++++++++++++++---
 .../power/reset/xlnx,zynqmp-power.yaml        |  4 +-
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi        |  2 +-
 3 files changed, 62 insertions(+), 12 deletions(-)

-- 
2.36.1



From nm at ti.com  Thu Dec 21 04:28:05 2023
From: nm at ti.com (Nishanth Menon)
Date: Thu, 21 Dec 2023 06:28:05 -0600
Subject: [PATCH] arm64: dts: ti: k3-am69-sk: remove
 assigned-clock-parents for unused VP
In-Reply-To: <20231221113042.48492-1-j-choudhary@ti.com>
References: <20231221113042.48492-1-j-choudhary@ti.com>
Message-ID: <20231221122805.3kl5mujtk2npvrmf@skiing>

On 17:00-20231221, Jayesh Choudhary wrote:
> VP2 and VP3 are unused video ports and VP3 share the same parent
> clock as VP1 causing issue with pixel clock setting for HDMI (VP1).
> So remove the parent clocks for unused VPs.
> 
> Fixes: 6f8605fd7d11 ("arm64: dts: ti: k3-am69-sk: Add DP and HDMI support")
> Reported-by: Nishanth Menon <nm at ti.com>
> Closes: https://storage.kernelci.org/mainline/master/v6.7-rc6/arm64/defconfig/gcc-10/lab-ti/baseline-nfs-am69_sk-fs.txt
> Signed-off-by: Jayesh Choudhary <j-choudhary at ti.com>
> ---
> 
> Local testing log for HDMI on AM69-SK:
> <https://gist.github.com/Jayesh2000/517395cd85eb28d65b8ee4568cefb809>

Has this been always failing or just something introduced in rc6? I know
I noticed this in rc6.. so wondering..

> 
>  arch/arm64/boot/dts/ti/k3-am69-sk.dts | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> index 8da591579868..370980eb59b0 100644
> --- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> @@ -918,13 +918,9 @@ &dss {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&dss_vout0_pins_default>;
>  	assigned-clocks = <&k3_clks 218 2>,
> -			  <&k3_clks 218 5>,
> -			  <&k3_clks 218 14>,
> -			  <&k3_clks 218 18>;
> +			  <&k3_clks 218 5>;
>  	assigned-clock-parents = <&k3_clks 218 3>,
> -				 <&k3_clks 218 7>,
> -				 <&k3_clks 218 16>,
> -				 <&k3_clks 218 22>;
> +				 <&k3_clks 218 7>;
>  };
>  
>  &serdes_wiz4 {
> -- 
> 2.25.1
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From michal.simek at amd.com  Thu Dec 21 04:27:55 2023
From: michal.simek at amd.com (Michal Simek)
Date: Thu, 21 Dec 2023 13:27:55 +0100
Subject: [PATCH v3 2/4] dt-bindings: firmware: xilinx: Sort node names (clock-controller)
In-Reply-To: <cover.1703161663.git.michal.simek@amd.com>
References: <cover.1703161663.git.michal.simek@amd.com>
Message-ID: <ccb6bd5f4d1d28983c73497ada596e893fece499.1703161663.git.michal.simek@amd.com>

Nodes should be sorted that's why move clock-controller to the top of list.

Signed-off-by: Michal Simek <michal.simek at amd.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---

(no changes since v2)

Changes in v2:
- New patch in series

 .../firmware/xilinx/xlnx,zynqmp-firmware.yaml  | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index 884917edb19d..51dc4e3afd25 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -41,6 +41,15 @@ properties:
   "#power-domain-cells":
     const: 1
 
+  clock-controller:
+    $ref: /schemas/clock/xlnx,versal-clk.yaml#
+    description: The clock controller is a hardware block of Xilinx versal
+      clock tree. It reads required input clock frequencies from the devicetree
+      and acts as clock provider for all clock consumers of PS clocks.list of
+      clock specifiers which are external input clocks to the given clock
+      controller.
+    type: object
+
   gpio:
     $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
     description: The gpio node describes connect to PS_MODE pins via firmware
@@ -84,15 +93,6 @@ properties:
       vector.
     type: object
 
-  clock-controller:
-    $ref: /schemas/clock/xlnx,versal-clk.yaml#
-    description: The clock controller is a hardware block of Xilinx versal
-      clock tree. It reads required input clock frequencies from the devicetree
-      and acts as clock provider for all clock consumers of PS clocks.list of
-      clock specifiers which are external input clocks to the given clock
-      controller.
-    type: object
-
 required:
   - compatible
 
-- 
2.36.1



From michal.simek at amd.com  Thu Dec 21 04:27:56 2023
From: michal.simek at amd.com (Michal Simek)
Date: Thu, 21 Dec 2023 13:27:56 +0100
Subject: [PATCH v3 3/4] dt-bindings: power: reset: xilinx: Rename node names in examples
In-Reply-To: <cover.1703161663.git.michal.simek@amd.com>
References: <cover.1703161663.git.michal.simek@amd.com>
Message-ID: <920c839ae2c9c5803c6c08b8705a0d8338bb94bc.1703161663.git.michal.simek@amd.com>

Rename zynqmp-power node name to power-management which is more aligned
with generic node name recommendation.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

Changes in v3:
- s/power-controller/power-management/g
- align commit message

Changes in v2:
- New patch is series

 .../devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml    | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
index 45792e216981..799831636194 100644
--- a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
@@ -57,7 +57,7 @@ examples:
 
     firmware {
       zynqmp-firmware {
-        zynqmp-power {
+        power-management {
           compatible = "xlnx,zynqmp-power";
           interrupts = <0 35 4>;
         };
@@ -70,7 +70,7 @@ examples:
 
     firmware {
       zynqmp-firmware {
-        zynqmp-power {
+        power-management {
           compatible = "xlnx,zynqmp-power";
           interrupt-parent = <&gic>;
           interrupts = <0 35 4>;
-- 
2.36.1



From michal.simek at amd.com  Thu Dec 21 04:27:57 2023
From: michal.simek at amd.com (Michal Simek)
Date: Thu, 21 Dec 2023 13:27:57 +0100
Subject: [PATCH v3 4/4] arm64: zynqmp: Rename zynqmp-power node to power-management
In-Reply-To: <cover.1703161663.git.michal.simek@amd.com>
References: <cover.1703161663.git.michal.simek@amd.com>
Message-ID: <bf24cde92c2b9e2824847687fab69fc25c533d53.1703161663.git.michal.simek@amd.com>

Rename zynqmp-power node name to power-management which is more aligned
with generic node name recommendation.

Signed-off-by: Michal Simek <michal.simek at amd.com>
---

Changes in v3:
- s/power-controller/power-management/g
- update subject and commit message to match sed above

Changes in v2:
- New patch is series

 arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index eaba466804bc..ea1a9ba16246 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -186,7 +186,7 @@ zynqmp_firmware: zynqmp-firmware {
 			method = "smc";
 			bootph-all;
 
-			zynqmp_power: zynqmp-power {
+			zynqmp_power: power-management {
 				bootph-all;
 				compatible = "xlnx,zynqmp-power";
 				interrupt-parent = <&gic>;
-- 
2.36.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:28:36 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:28:36 +0100
Subject: [PATCH v1 1/8] dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds
In-Reply-To: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
References: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221122843.418650-2-raphael.gallais-pou@foss.st.com>

List EDT ETML0700Z9NDHA in the LVDS panel enumeration.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
index 9f1016551e0b..3fb24393529c 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
@@ -42,6 +42,8 @@ properties:
           - auo,b101ew05
           # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel
           - chunghwa,claa070wp03xg
+          # EDT ETML0700Z9NDHA 7.0" WSVGA (1024x600) color TFT LCD LVDS panel
+          - edt,etml0700z9ndha
           # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel
           - hannstar,hsd101pww2
           # Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:28:35 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:28:35 +0100
Subject: [PATCH v1 0/8] Introduce STM32 LVDS driver
Message-ID: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>

This serie introduces a new DRM bridge driver for STM32MP257 platforms
based on Arm Cortex-35. It also adds an instance in the device-tree and
handle the inclusion of the driver within the DRM framework. First patch
adds a new panel compatible in the panel-lvds driver, which is used by
default on the STM32MP257.

Raphael Gallais-Pou (7):
  dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds
  dt-bindings: display: add dt-bindings for STM32 LVDS device
  drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
  drm/stm: ltdc: add lvds pixel clock
  arm64: dts: st: add ltdc support on stm32mp251
  arm64: dts: st: add lvds support on stm32mp253
  arm64: dts: st: add display support on stm32mp257f-ev

Yannick Fertre (1):
  drm/stm: ltdc: implement bus clock

 .../bindings/display/panel/panel-lvds.yaml    |    2 +
 .../bindings/display/st,stm32-lvds.yaml       |  114 ++
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |   12 +
 arch/arm64/boot/dts/st/stm32mp253.dtsi        |   17 +
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |   79 ++
 drivers/gpu/drm/stm/Kconfig                   |   11 +
 drivers/gpu/drm/stm/Makefile                  |    2 +
 drivers/gpu/drm/stm/ltdc.c                    |   26 +
 drivers/gpu/drm/stm/ltdc.h                    |    2 +
 drivers/gpu/drm/stm/lvds.c                    | 1226 +++++++++++++++++
 10 files changed, 1491 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
 create mode 100644 drivers/gpu/drm/stm/lvds.c

-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:28:37 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:28:37 +0100
Subject: [PATCH v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
In-Reply-To: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
References: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221122843.418650-3-raphael.gallais-pou@foss.st.com>

Add dt-binding file for "st,stm32-lvds" compatible.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 .../bindings/display/st,stm32-lvds.yaml       | 114 ++++++++++++++++++
 1 file changed, 114 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml

diff --git a/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
new file mode 100644
index 000000000000..d72c9088133c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/st,stm32-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 LVDS Display Interface Transmitter
+
+maintainers:
+  - Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
+  - Yannick Fertre <yannick.fertre at foss.st.com>
+
+description: |
+  The STMicroelectronics STM32 LVDS Display Interface Transmitter handles the
+  LVDS protocol: it maps the pixels received from the upstream Pixel-DMA (LTDC)
+  onto the LVDS PHY.
+
+  It regroups three sub blocks:
+    - LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input
+      pixels onto the data lanes of the PHY
+    - LVDS PHY: parallelize the data and drives the LVDS data lanes
+    - LVDS wrapper: handles top-level settings
+
+  The LVDS controller driver supports the following high-level features:
+    - FDP-Link-I and OpenLDI (v0.95) protocols
+    - Single-Link or Dual-Link operation
+    - Single-Display or Double-Display (with the same content duplicated on both)
+    - Flexible Bit-Mapping, including JEIDA and VESA
+    - RGB888 or RGB666 output
+    - Synchronous design, with one input pixel per clock cycle
+
+properties:
+  "#clock-cells":
+    const: 0
+
+  compatible:
+    const: st,stm32-lvds
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: APB peripheral clock
+      - description: Reference clock for the internal PLL
+
+  clock-names:
+    items:
+      - const: pclk
+      - const: ref
+
+  resets:
+    maxItems: 1
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port at 0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: |
+          LVDS input port node, connected to the LTDC RGB output port.
+
+      port at 1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: |
+          LVDS output port node, connected to a panel or bridge input port.
+
+required:
+  - "#clock-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+  - ports
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/bus/stm32mp25_sys_bus.h>
+    #include <dt-bindings/clock/stm32mp25-clks.h>
+    #include <dt-bindings/reset/stm32mp25-resets.h>
+
+    lvds: lvds at 48060000 {
+        #clock-cells = <0>;
+        compatible = "st,stm32-lvds";
+        reg = <0x48060000 0x2000>;
+        clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
+        clock-names = "pclk", "ref";
+        resets = <&rcc LVDS_R>;
+
+        ports {
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            port at 0 {
+                reg = <0>;
+                lvds_in: endpoint {
+                   remote-endpoint = <&ltdc_ep1_out>;
+                };
+            };
+
+            port at 1 {
+                reg = <1>;
+                lvds_out0: endpoint {
+                   remote-endpoint = <&lvds_panel_in>;
+                };
+            };
+        };
+    };
+
+...
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:28:39 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:28:39 +0100
Subject: [PATCH v1 4/8] drm/stm: ltdc: implement bus clock
In-Reply-To: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
References: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221122843.418650-5-raphael.gallais-pou@foss.st.com>

From: Yannick Fertre <yannick.fertre at foss.st.com>

The latest hardware version of the LTDC presents the addition of a bus
clock, which contains the global configuration registers and the interrupt
register.

Signed-off-by: Yannick Fertre <yannick.fertre at foss.st.com>
---
 drivers/gpu/drm/stm/ltdc.c | 8 ++++++++
 drivers/gpu/drm/stm/ltdc.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 5576fdae4962..67064f47a4cb 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1896,6 +1896,8 @@ void ltdc_suspend(struct drm_device *ddev)
 
 	DRM_DEBUG_DRIVER("\n");
 	clk_disable_unprepare(ldev->pixel_clk);
+	if (ldev->bus_clk)
+		clk_disable_unprepare(ldev->bus_clk);
 }
 
 int ltdc_resume(struct drm_device *ddev)
@@ -1910,6 +1912,12 @@ int ltdc_resume(struct drm_device *ddev)
 		DRM_ERROR("failed to enable pixel clock (%d)\n", ret);
 		return ret;
 	}
+	if (ldev->bus_clk) {
+		if (clk_prepare_enable(ldev->bus_clk)) {
+			DRM_ERROR("Unable to prepare bus clock\n");
+			return -ENODEV;
+		}
+	}
 
 	return 0;
 }
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 9d488043ffdb..155d8e4a7c6b 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
 	void __iomem *regs;
 	struct regmap *regmap;
 	struct clk *pixel_clk;	/* lcd pixel clock */
+	struct clk *bus_clk;	/* bus clock */
 	struct mutex err_lock;	/* protecting error_status */
 	struct ltdc_caps caps;
 	u32 irq_status;
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:28:38 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:28:38 +0100
Subject: [PATCH v1 3/8] drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
In-Reply-To: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
References: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221122843.418650-4-raphael.gallais-pou@foss.st.com>

The Low-Voltage Differential Signaling (LVDS) Display Interface
Transmitter handles the LVDS protocol: it maps the pixels received from
the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS
PHY.

It regroups three sub blocks:
	* LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps
	  its input pixels onto the data lanes of the PHY
	* LVDS PHY: parallelize the data and drives the LVDS data lanes
	* LVDS wrapper: handles top-level settings

The LVDS controller driver supports the following high-level features:
	* FDP-Link-I and OpenLDI (v0.95) protocols
	* Single-Link or Dual-Link operation
	* Single-Display or Double-Display (with the same content
	  duplicated on both)
	* Flexible Bit-Mapping, including JEIDA and VESA
	* RGB888 or RGB666 output
	* Synchronous design, with one input pixel per clock cycle

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 drivers/gpu/drm/stm/Kconfig  |   11 +
 drivers/gpu/drm/stm/Makefile |    2 +
 drivers/gpu/drm/stm/lvds.c   | 1226 ++++++++++++++++++++++++++++++++++
 3 files changed, 1239 insertions(+)
 create mode 100644 drivers/gpu/drm/stm/lvds.c

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index fa49cde43bb2..9627814d027c 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -20,3 +20,14 @@ config DRM_STM_DSI
 	select DRM_DW_MIPI_DSI
 	help
 	  Choose this option for MIPI DSI support on STMicroelectronics SoC.
+
+config DRM_STM_LVDS
+	tristate "STMicroelectronics LVDS Display Interface Transmitter DRM driver"
+	depends on DRM_STM
+	help
+	  Enable support for LVDS encoders on STMicroelectronics SoC.
+	  The STM LVDS is a bridge which serialize pixel stream onto
+	  a LVDS protocol.
+
+	  To compile this driver as a module, choose M here: the module will be
+	  called lvds.
diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile
index 4df5caf01f35..ad740d6175a6 100644
--- a/drivers/gpu/drm/stm/Makefile
+++ b/drivers/gpu/drm/stm/Makefile
@@ -5,4 +5,6 @@ stm-drm-y := \
 
 obj-$(CONFIG_DRM_STM_DSI) += dw_mipi_dsi-stm.o
 
+obj-$(CONFIG_DRM_STM_LVDS) += lvds.o
+
 obj-$(CONFIG_DRM_STM) += stm-drm.o
diff --git a/drivers/gpu/drm/stm/lvds.c b/drivers/gpu/drm/stm/lvds.c
new file mode 100644
index 000000000000..f01490939ab5
--- /dev/null
+++ b/drivers/gpu/drm/stm/lvds.c
@@ -0,0 +1,1226 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ * Author(s): Rapha??l GALLAIS-POU <raphael.gallais-pou at foss.st.com> for STMicroelectronics.
+ */
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_bridge.h>
+#include <drm/drm_device.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_print.h>
+#include <drm/drm_probe_helper.h>
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/media-bus-format.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/reset.h>
+
+/* LVDS Host registers */
+#define LVDS_CR		0x0000  /* configuration register */
+#define LVDS_DMLCR0	0x0004  /* data mapping lsb configuration register 0 */
+#define LVDS_DMMCR0	0x0008  /* data mapping msb configuration register 0 */
+#define LVDS_DMLCR1	0x000C  /* data mapping lsb configuration register 1 */
+#define LVDS_DMMCR1	0x0010  /* data mapping msb configuration register 1 */
+#define LVDS_DMLCR2	0x0014  /* data mapping lsb configuration register 2 */
+#define LVDS_DMMCR2	0x0018  /* data mapping msb configuration register 2 */
+#define LVDS_DMLCR3	0x001C  /* data mapping lsb configuration register 3 */
+#define LVDS_DMMCR3	0x0020  /* data mapping msb configuration register 3 */
+#define LVDS_DMLCR4	0x0024  /* data mapping lsb configuration register 4 */
+#define LVDS_DMMCR4	0x0028  /* data mapping msb configuration register 4 */
+#define LVDS_CDL1CR	0x002C  /* channel distrib link 1 configuration register */
+#define LVDS_CDL2CR	0x0030  /* channel distrib link 2 configuration register */
+
+#define CDL1CR_DEFAULT	0x04321 /* Default value for CDL1CR */
+#define CDL2CR_DEFAULT	0x59876 /* Default value for CDL2CR */
+
+#define LVDS_DMLCR(bit)	(LVDS_DMLCR0 + 0x8 * (bit))
+#define LVDS_DMMCR(bit)	(LVDS_DMMCR0 + 0x8 * (bit))
+
+/* LVDS Wrapper registers */
+#define LVDS_WCLKCR	0x11B0  /* Wrapper clock control register */
+
+#define LVDS_HWCFGR	0x1FF0  /* HW configuration register	*/
+#define LVDS_VERR	0x1FF4  /* Version register	*/
+#define LVDS_IPIDR	0x1FF8  /* Identification register	*/
+#define LVDS_SIDR	0x1FFC  /* Size Identification register	*/
+
+/* Bitfield description */
+#define CR_LVDSEN	BIT(0)  /* LVDS PHY Enable */
+#define CR_HSPOL	BIT(1)  /* Horizontal Synchronization Polarity */
+#define CR_VSPOL	BIT(2)  /* Vertical Synchronization Polarity */
+#define CR_DEPOL	BIT(3)  /* Data Enable Polarity */
+#define CR_CI		BIT(4)  /* Control Internal (software controlled bit) */
+#define CR_LKMOD	BIT(5)  /* Link Mode, for both Links */
+#define CR_LKPHA	BIT(6)  /* Link Phase, for both Links */
+#define CR_LK1POL	GENMASK(20, 16)  /* Link-1 output Polarity */
+#define CR_LK2POL	GENMASK(25, 21)  /* Link-2 output Polarity */
+
+#define DMMCRx_MAP0	GENMASK(4, 0) /* Mapping for bit 0 of datalane x */
+#define DMMCRx_MAP1	GENMASK(9, 5) /* Mapping for bit 1 of datalane x */
+#define DMMCRx_MAP2	GENMASK(14, 10) /* Mapping for bit 2 of datalane x */
+#define DMMCRx_MAP3	GENMASK(19, 15) /* Mapping for bit 3 of datalane x */
+#define DMLCRx_MAP4	GENMASK(4, 0) /* Mapping for bit 4 of datalane x */
+#define DMLCRx_MAP5	GENMASK(9, 5) /* Mapping for bit 5 of datalane x */
+#define DMLCRx_MAP6	GENMASK(14, 10) /* Mapping for bit 6 of datalane x */
+
+#define CDLCRx_DISTR0	GENMASK(3, 0) /* Channel distribution for lane 0 */
+#define CDLCRx_DISTR1	GENMASK(7, 4) /* Channel distribution for lane 1 */
+#define CDLCRx_DISTR2	GENMASK(11, 8) /* Channel distribution for lane 2 */
+#define CDLCRx_DISTR3	GENMASK(15, 12) /* Channel distribution for lane 3 */
+#define CDLCRx_DISTR4	GENMASK(19, 16) /* Channel distribution for lane 4 */
+
+#define PHY_GCR_BIT_CLK_OUT	BIT(0)  /* BIT clock enable */
+#define PHY_GCR_LS_CLK_OUT	BIT(4)  /* LS clock enable */
+#define PHY_GCR_DP_CLK_OUT	BIT(8)  /* DP clock enable */
+#define PHY_GCR_RSTZ		BIT(24) /* LVDS PHY digital reset */
+#define PHY_GCR_DIV_RSTN	BIT(25) /* Output divider reset */
+#define PHY_SCR_TX_EN		BIT(16) /* Transmission mode enable */
+/* Current mode driver enable */
+#define PHY_CMCR_CM_EN_DL	(BIT(28) | BIT(20) | BIT(12) | BIT(4))
+#define PHY_CMCR_CM_EN_DL4	BIT(4)
+/* Bias enable */
+#define PHY_BCR1_EN_BIAS_DL	(BIT(16) | BIT(12) | BIT(8) | BIT(4) | BIT(0))
+#define PHY_BCR2_BIAS_EN	BIT(28)
+/* Voltage mode driver enable */
+#define PHY_BCR3_VM_EN_DL	(BIT(16) | BIT(12) | BIT(8) | BIT(4) | BIT(0))
+#define PHY_DCR_POWER_OK	BIT(12)
+#define PHY_CFGCR_EN_DIG_DL	GENMASK(4, 0) /* LVDS PHY digital lane enable */
+#define PHY_PLLCR1_PLL_EN	BIT(0) /* LVDS PHY PLL enable */
+#define PHY_PLLCR1_EN_SD	BIT(1) /* LVDS PHY PLL sigma-delta signal enable */
+#define PHY_PLLCR1_EN_TWG	BIT(2) /* LVDS PHY PLL triangular wave generator enable */
+#define PHY_PLLCR1_DIV_EN	BIT(8) /* LVDS PHY PLL dividers enable */
+#define PHY_PLLCR2_NDIV		GENMASK(25, 16) /* NDIV mask value */
+#define PHY_PLLCR2_BDIV		GENMASK(9, 0)   /* BDIV mask value */
+#define PHY_PLLSR_PLL_LOCK	BIT(0) /* LVDS PHY PLL lock status */
+#define PHY_PLLSDCR1_MDIV	GENMASK(9, 0)   /* MDIV mask value */
+#define PHY_PLLTESTCR_TDIV	GENMASK(25, 16) /* TDIV mask value */
+#define PHY_PLLTESTCR_CLK_EN	BIT(0) /* Test clock enable */
+#define PHY_PLLTESTCR_EN	BIT(8) /* Test divider output enable */
+
+#define WCLKCR_SECND_CLKPIX_SEL	BIT(0) /* Pixel clock selection */
+#define WCLKCR_SRCSEL		BIT(8) /* Source selection for the pixel clock */
+
+/* Sleep & timeout for pll lock/unlock */
+#define SLEEP_US	1000
+#define TIMEOUT_US	200000
+
+/*
+ * The link phase defines whether an ODD pixel is carried over together with
+ * the next EVEN pixel or together with the previous EVEN pixel.
+ *
+ * LVDS_DUAL_LINK_EVEN_ODD_PIXELS (LKPHA = 0)
+ *
+ * ,--------.  ,--------.  ,--------.  ,--------.  ,---------.
+ * | ODD  LK \/ PIXEL  3 \/ PIXEL  1 \/ PIXEL' 1 \/ PIXEL' 3 |
+ * | EVEN LK /\ PIXEL  2 /\ PIXEL' 0 /\ PIXEL' 2 /\ PIXEL' 4 |
+ * `--------'  `--------'  `--------'  `--------'  `---------'
+ *
+ * LVDS_DUAL_LINK_ODD_EVEN_PIXELS (LKPHA = 1)
+ *
+ * ,--------.  ,--------.  ,--------.  ,--------.  ,---------.
+ * | ODD  LK \/ PIXEL  3 \/ PIXEL  1 \/ PIXEL' 1 \/ PIXEL' 3 |
+ * | EVEN LK /\ PIXEL  4 /\ PIXEL  2 /\ PIXEL' 0 /\ PIXEL' 2 |
+ * `--------'  `--------'  `--------'  `--------'  `---------'
+ *
+ */
+enum lvds_link_type {
+	LVDS_SINGLE_LINK_PRIMARY = 0,
+	LVDS_SINGLE_LINK_SECONDARY,
+	LVDS_DUAL_LINK_EVEN_ODD_PIXELS,
+	LVDS_DUAL_LINK_ODD_EVEN_PIXELS,
+};
+
+enum lvds_pixel {
+	PIX_R_0 = 0,
+	PIX_R_1,
+	PIX_R_2,
+	PIX_R_3,
+	PIX_R_4,
+	PIX_R_5,
+	PIX_R_6,
+	PIX_R_7,
+	PIX_G_0,
+	PIX_G_1,
+	PIX_G_2,
+	PIX_G_3,
+	PIX_G_4,
+	PIX_G_5,
+	PIX_G_6,
+	PIX_G_7,
+	PIX_B_0,
+	PIX_B_1,
+	PIX_B_2,
+	PIX_B_3,
+	PIX_B_4,
+	PIX_B_5,
+	PIX_B_6,
+	PIX_B_7,
+	PIX_H_S,
+	PIX_V_S,
+	PIX_D_E,
+	PIX_C_E,
+	PIX_C_I,
+	PIX_TOG,
+	PIX_ONE,
+	PIX_ZER,
+};
+
+struct phy_reg_offsets {
+	u32 GCR;	/* Global Control Register	*/
+	u32 CMCR1;    /* Current Mode Control Register 1 */
+	u32 CMCR2;    /* Current Mode Control Register 2 */
+	u32 SCR;      /* Serial Control Register	*/
+	u32 BCR1;     /* Bias Control Register 1	*/
+	u32 BCR2;     /* Bias Control Register 2	*/
+	u32 BCR3;     /* Bias Control Register 3	*/
+	u32 MPLCR;    /* Monitor PLL Lock Control Register */
+	u32 DCR;      /* Debug Control Register	*/
+	u32 SSR1;     /* Spare Status Register 1	*/
+	u32 CFGCR;    /* Configuration Control Register */
+	u32 PLLCR1;   /* PLL_MODE 1 Control Register	*/
+	u32 PLLCR2;   /* PLL_MODE 2 Control Register	*/
+	u32 PLLSR;    /* PLL Status Register	*/
+	u32 PLLSDCR1; /* PLL_SD_1 Control Register	*/
+	u32 PLLSDCR2; /* PLL_SD_2 Control Register	*/
+	u32 PLLTWGCR1;/* PLL_TWG_1 Control Register	*/
+	u32 PLLTWGCR2;/* PLL_TWG_2 Control Register	*/
+	u32 PLLCPCR;  /* PLL_CP Control Register	*/
+	u32 PLLTESTCR;/* PLL_TEST Control Register	*/
+};
+
+struct lvds_phy_info {
+	u32 base;
+	struct phy_reg_offsets ofs;
+};
+
+static struct lvds_phy_info lvds_phy_16ff_primary = {
+	.base = 0x1000,
+	.ofs = {
+		.GCR = 0x0,
+		.CMCR1 = 0xC,
+		.CMCR2 = 0x10,
+		.SCR = 0x20,
+		.BCR1 = 0x2C,
+		.BCR2 = 0x30,
+		.BCR3 = 0x34,
+		.MPLCR = 0x64,
+		.DCR = 0x84,
+		.SSR1 = 0x88,
+		.CFGCR = 0xA0,
+		.PLLCR1 = 0xC0,
+		.PLLCR2 = 0xC4,
+		.PLLSR = 0xC8,
+		.PLLSDCR1 = 0xCC,
+		.PLLSDCR2 = 0xD0,
+		.PLLTWGCR1 = 0xD4,
+		.PLLTWGCR2 = 0xD8,
+		.PLLCPCR = 0xE0,
+		.PLLTESTCR = 0xE8,
+	}
+};
+
+static struct lvds_phy_info lvds_phy_16ff_secondary = {
+	.base = 0x1100,
+	.ofs = {
+		.GCR = 0x0,
+		.CMCR1 = 0xC,
+		.CMCR2 = 0x10,
+		.SCR = 0x20,
+		.BCR1 = 0x2C,
+		.BCR2 = 0x30,
+		.BCR3 = 0x34,
+		.MPLCR = 0x64,
+		.DCR = 0x84,
+		.SSR1 = 0x88,
+		.CFGCR = 0xA0,
+		.PLLCR1 = 0xC0,
+		.PLLCR2 = 0xC4,
+		.PLLSR = 0xC8,
+		.PLLSDCR1 = 0xCC,
+		.PLLSDCR2 = 0xD0,
+		.PLLTWGCR1 = 0xD4,
+		.PLLTWGCR2 = 0xD8,
+		.PLLCPCR = 0xE0,
+		.PLLTESTCR = 0xE8,
+	}
+};
+
+struct stm_lvds {
+	void __iomem *base;
+	struct device *dev;
+	struct clk *pclk;		/* APB peripheral clock */
+	struct clk *pllref_clk;		/* Reference clock for the internal PLL */
+	struct clk_hw lvds_ck_px;	/* Pixel clock */
+	u32 pixel_clock_rate;		/* Pixel clock rate */
+
+	struct lvds_phy_info *primary;
+	struct lvds_phy_info *secondary;
+
+	struct drm_bridge lvds_bridge;
+	struct drm_bridge *next_bridge;
+	struct drm_connector connector;
+	struct drm_encoder *encoder;
+	struct drm_panel *panel;
+
+	u32 hw_version;
+	u32 link_type;
+};
+
+#define bridge_to_stm_lvds(b) \
+	container_of(b, struct stm_lvds, lvds_bridge)
+
+#define connector_to_stm_lvds(c) \
+	container_of(c, struct stm_lvds, connector)
+
+#define lvds_is_dual_link(lvds) \
+	({	\
+	typeof(lvds) __lvds = (lvds);	\
+	__lvds == LVDS_DUAL_LINK_EVEN_ODD_PIXELS ||	\
+	__lvds == LVDS_DUAL_LINK_ODD_EVEN_PIXELS;	\
+	})
+
+static inline void lvds_write(struct stm_lvds *lvds, u32 reg, u32 val)
+{
+	writel(val, lvds->base + reg);
+}
+
+static inline u32 lvds_read(struct stm_lvds *lvds, u32 reg)
+{
+	return readl(lvds->base + reg);
+}
+
+static inline void lvds_set(struct stm_lvds *lvds, u32 reg, u32 mask)
+{
+	lvds_write(lvds, reg, lvds_read(lvds, reg) | mask);
+}
+
+static inline void lvds_clear(struct stm_lvds *lvds, u32 reg, u32 mask)
+{
+	lvds_write(lvds, reg, lvds_read(lvds, reg) & ~mask);
+}
+
+/*
+ * Expected JEIDA-RGB888 data to be sent in LSB format
+ *	    bit6 ............................bit0
+ * CHAN0   {ONE, ONE, ZERO, ZERO, ZERO, ONE, ONE}
+ * CHAN1   {G2,  R7,  R6,   R5,   R4,   R3,  R2}
+ * CHAN2   {B3,  B2,  G7,   G6,   G5,   G4,  G3}
+ * CHAN3   {DE,  VS,  HS,   B7,   B6,   B5,  B4}
+ * CHAN4   {CE,  B1,  B0,   G1,   G0,   R1,  R0}
+ */
+enum lvds_pixel lvds_bitmap_jeida_rgb888[5][7] = {
+	{ PIX_ONE, PIX_ONE, PIX_ZER, PIX_ZER, PIX_ZER, PIX_ONE, PIX_ONE },
+	{ PIX_G_2, PIX_R_7, PIX_R_6, PIX_R_5, PIX_R_4, PIX_R_3, PIX_R_2 },
+	{ PIX_B_3, PIX_B_2, PIX_G_7, PIX_G_6, PIX_G_5, PIX_G_4, PIX_G_3 },
+	{ PIX_D_E, PIX_V_S, PIX_H_S, PIX_B_7, PIX_B_6, PIX_B_5, PIX_B_4 },
+	{ PIX_C_E, PIX_B_1, PIX_B_0, PIX_G_1, PIX_G_0, PIX_R_1, PIX_R_0 }
+};
+
+/*
+ * Expected VESA-RGB888 data to be sent in LSB format
+ *	    bit6 ............................bit0
+ * CHAN0   {ONE, ONE, ZERO, ZERO, ZERO, ONE, ONE}
+ * CHAN1   {G0,  R5,  R4,   R3,   R2,   R1,  R0}
+ * CHAN2   {B1,  B0,  G5,   G4,   G3,   G2,  G1}
+ * CHAN3   {DE,  VS,  HS,   B5,   B4,   B3,  B2}
+ * CHAN4   {CE,  B7,  B6,   G7,   G6,   R7,  R6}
+ */
+enum lvds_pixel lvds_bitmap_vesa_rgb888[5][7] = {
+	{ PIX_ONE, PIX_ONE, PIX_ZER, PIX_ZER, PIX_ZER, PIX_ONE, PIX_ONE },
+	{ PIX_G_0, PIX_R_5, PIX_R_4, PIX_R_3, PIX_R_2, PIX_R_1, PIX_R_0 },
+	{ PIX_B_1, PIX_B_0, PIX_G_5, PIX_G_4, PIX_G_3, PIX_G_2, PIX_G_1 },
+	{ PIX_D_E, PIX_V_S, PIX_H_S, PIX_B_5, PIX_B_4, PIX_B_3, PIX_B_2 },
+	{ PIX_C_E, PIX_B_7, PIX_B_6, PIX_G_7, PIX_G_6, PIX_R_7, PIX_R_6 }
+};
+
+/*
+ * Clocks and PHY related functions
+ */
+static int lvds_pll_enable(struct stm_lvds *lvds, struct lvds_phy_info *phy)
+{
+	struct drm_device *drm = lvds->lvds_bridge.dev;
+	u32 lvds_gcr;
+	int val, ret;
+
+	/*
+	 * PLL lock timing control for the monitor unmask after startup (pll_en)
+	 * Adjusted value so that the masking window is opened at start-up
+	 */
+	lvds_write(lvds, phy->base + phy->ofs.MPLCR, (0x200 - 0x160) << 16);
+
+	/* Enable bias */
+	lvds_write(lvds, phy->base + phy->ofs.BCR2, PHY_BCR2_BIAS_EN);
+
+	/* Enable DP, LS, BIT clock output */
+	lvds_gcr = PHY_GCR_DP_CLK_OUT | PHY_GCR_LS_CLK_OUT | PHY_GCR_BIT_CLK_OUT;
+	lvds_set(lvds, phy->base + phy->ofs.GCR, lvds_gcr);
+
+	/* Power up all output dividers */
+	lvds_set(lvds, phy->base + phy->ofs.PLLTESTCR, PHY_PLLTESTCR_EN);
+	lvds_set(lvds, phy->base + phy->ofs.PLLCR1, PHY_PLLCR1_DIV_EN);
+
+	/* Set PHY in serial transmission mode */
+	lvds_set(lvds, phy->base + phy->ofs.SCR, PHY_SCR_TX_EN);
+
+	/* Enable the LVDS PLL & wait for its lock */
+	lvds_set(lvds, phy->base + phy->ofs.PLLCR1, PHY_PLLCR1_PLL_EN);
+	ret = readl_poll_timeout_atomic(lvds->base + phy->base + phy->ofs.PLLSR,
+					val, val & PHY_PLLSR_PLL_LOCK,
+					SLEEP_US, TIMEOUT_US);
+	if (ret)
+		drm_err(drm, "!TIMEOUT! waiting PLL, let's continue\n");
+
+	/* WCLKCR_SECND_CLKPIX_SEL is for dual link */
+	lvds_write(lvds, LVDS_WCLKCR, WCLKCR_SECND_CLKPIX_SEL);
+
+	lvds_set(lvds, phy->ofs.PLLTESTCR, PHY_PLLTESTCR_CLK_EN);
+
+	return ret;
+}
+
+static int pll_get_clkout_khz(int clkin_khz, int bdiv, int mdiv, int ndiv)
+{
+	int divisor = ndiv * bdiv;
+
+	/* Prevents from division by 0 */
+	if (!divisor)
+		return 0;
+
+	return clkin_khz * mdiv / divisor;
+}
+
+#define TDIV	70
+#define NDIV_MIN	2
+#define NDIV_MAX	6
+#define BDIV_MIN	2
+#define BDIV_MAX	6
+#define MDIV_MIN	1
+#define MDIV_MAX	1023
+
+static int lvds_pll_get_params(struct stm_lvds *lvds,
+			       unsigned int clkin_khz, unsigned int clkout_khz,
+			       unsigned int *bdiv, unsigned int *mdiv, unsigned int *ndiv)
+{
+	int delta, best_delta; /* all in khz */
+	int i, o, n;
+
+	/* Early checks preventing division by 0 & odd results */
+	if (clkin_khz <= 0 || clkout_khz <= 0)
+		return -EINVAL;
+
+	best_delta = 1000000; /* big started value (1000000khz) */
+
+	for (i = NDIV_MIN; i <= NDIV_MAX; i++) {
+		for (o = BDIV_MIN; o <= BDIV_MAX; o++) {
+			n = DIV_ROUND_CLOSEST(i * o * clkout_khz, clkin_khz);
+			/* Check ndiv according to vco range */
+			if (n < MDIV_MIN || n > MDIV_MAX)
+				continue;
+			/* Check if new delta is better & saves parameters */
+			delta = pll_get_clkout_khz(clkin_khz, i, n, o) - clkout_khz;
+			if (delta < 0)
+				delta = -delta;
+			if (delta < best_delta) {
+				*ndiv = i;
+				*mdiv = n;
+				*bdiv = o;
+				best_delta = delta;
+			}
+			/* fast return in case of "perfect result" */
+			if (!delta)
+				return 0;
+		}
+	}
+
+	return 0;
+}
+
+static void lvds_pll_config(struct stm_lvds *lvds, struct lvds_phy_info *phy)
+{
+	unsigned int pll_in_khz, bdiv = 0, mdiv = 0, ndiv = 0;
+	struct clk_hw *hwclk;
+	int multiplier;
+
+	/*
+	 * The LVDS PHY includes a low power low jitter high performance and
+	 * highly configuration Phase Locked Loop supporting integer and
+	 * fractional multiplication ratios and Spread Spectrum Clocking.  In
+	 * integer mode, the only software supported feature for now, the PLL is
+	 * made of a pre-divider NDIV, a feedback multiplier MDIV, followed by
+	 * several post-dividers, each one with a specific application.
+	 *
+	 *          ,------.         ,-----.     ,-----.
+	 * Fref --> | NDIV | -Fpdf-> | PFD | --> | VCO | --------> Fvco
+	 *          `------'     ,-> |     |     `-----'  |
+	 *                       |   `-----'              |
+	 *                       |         ,------.       |
+	 *                       `-------- | MDIV | <-----'
+	 *                                 `------'
+	 *
+	 * From the output of the VCO, the clock can be optionally extracted on
+	 * the RCC clock observer, with a divider TDIV, for testing purpose, or
+	 * is passed through a programmable post-divider BDIV.  Finally, the
+	 * frequency can be divided further with two fixed dividers.
+	 *
+	 *                            ,--------.
+	 *                    ,-----> | DP div | ----------------> Fdp
+	 *          ,------.  |       `--------'
+	 * Fvco --> | BDIV | ------------------------------------> Fbit
+	 *      |   `------'    ,------.   |
+	 *      `-------------> | TDIV | --.---------------------> ClkObs
+	 *                      '------'   |    ,--------.
+	 *                                 `--> | LS div | ------> Fls
+	 *                                      '--------'
+	 *
+	 * The LS and DP clock dividers operate at a fixed ratio of 7 and 3.5
+	 * respectively with regards to fbit. LS divider converts the bit clock
+	 * to a pixel clock per lane per clock sample (Fls).  This is useful
+	 * when used to generate a dot clock for the display unit RGB output,
+	 * and DP divider is.
+	 */
+
+	hwclk = __clk_get_hw(lvds->pllref_clk);
+	if (!hwclk)
+		return;
+
+	pll_in_khz = clk_hw_get_rate(hwclk) / 1000;
+
+	if (lvds_is_dual_link(lvds->link_type))
+		multiplier = 2;
+	else
+		multiplier = 1;
+
+	lvds_pll_get_params(lvds, pll_in_khz,
+			    lvds->pixel_clock_rate * 7 / 1000 / multiplier,
+			    &bdiv, &mdiv, &ndiv);
+
+	/* Set BDIV, MDIV and NDIV */
+	lvds_write(lvds, phy->base + phy->ofs.PLLCR2, ndiv << 16);
+	lvds_set(lvds, phy->base + phy->ofs.PLLCR2, bdiv);
+	lvds_write(lvds, phy->base + phy->ofs.PLLSDCR1, mdiv);
+
+	/* Hardcode TDIV as dynamic values are not yet implemented */
+	lvds_write(lvds, phy->base + phy->ofs.PLLTESTCR, TDIV << 16);
+
+	/*
+	 * For now, PLL just needs to be in integer mode
+	 * Fractional and spread spectrum clocking are not yet implemented
+	 *
+	 * PLL integer mode:
+	 *	- PMRY_PLL_TWG_STEP = PMRY_PLL_SD_INT_RATIO
+	 *	- EN_TWG = 0
+	 *	- EN_SD = 0
+	 *	- DOWN_SPREAD = 0
+	 *
+	 * PLL fractional mode:
+	 *	- EN_TWG = 0
+	 *	- EN_SD = 1
+	 *	- DOWN_SPREAD = 0
+	 *
+	 * Spread Spectrum Clocking
+	 *	- EN_TWG = 1
+	 *	- EN_SD = 1
+	 */
+
+	/* Disable TWG and SD */
+	lvds_clear(lvds, phy->base + phy->ofs.PLLCR1, PHY_PLLCR1_EN_TWG | PHY_PLLCR1_EN_SD);
+
+	/* Power up bias and PLL dividers */
+	lvds_set(lvds, phy->base + phy->ofs.DCR, PHY_DCR_POWER_OK);
+	lvds_set(lvds, phy->base + phy->ofs.CMCR1, PHY_CMCR_CM_EN_DL);
+	lvds_set(lvds, phy->base + phy->ofs.CMCR2, PHY_CMCR_CM_EN_DL4);
+
+	/* Set up voltage mode */
+	lvds_set(lvds, phy->base + phy->ofs.PLLCPCR, 0x1);
+	lvds_set(lvds, phy->base + phy->ofs.BCR3, PHY_BCR3_VM_EN_DL);
+	lvds_set(lvds, phy->base + phy->ofs.BCR1, PHY_BCR1_EN_BIAS_DL);
+	/* Enable digital datalanes */
+	lvds_set(lvds, phy->base + phy->ofs.CFGCR, PHY_CFGCR_EN_DIG_DL);
+}
+
+static int lvds_pixel_clk_enable(struct clk_hw *hw)
+{
+	struct stm_lvds *lvds = container_of(hw, struct stm_lvds, lvds_ck_px);
+	struct drm_device *drm = lvds->lvds_bridge.dev;
+	struct lvds_phy_info *phy;
+	int ret;
+
+	ret = clk_prepare_enable(lvds->pclk);
+	if (ret) {
+		drm_err(drm, "Failed to enable lvds peripheral clk\n");
+		return ret;
+	}
+
+	ret = clk_prepare_enable(lvds->pllref_clk);
+	if (ret) {
+		drm_err(drm, "Failed to enable lvds reference clk\n");
+		clk_disable_unprepare(lvds->pclk);
+		return ret;
+	}
+
+	/* In case we are operating in dual link the second PHY is set before the primary PHY. */
+	if (lvds->secondary) {
+		phy = lvds->secondary;
+
+		/* Release LVDS PHY from reset mode */
+		lvds_set(lvds, phy->base + phy->ofs.GCR, PHY_GCR_DIV_RSTN | PHY_GCR_RSTZ);
+		lvds_pll_config(lvds, phy);
+
+		ret = lvds_pll_enable(lvds, phy);
+		if (ret) {
+			drm_err(drm, "Failed to enable secondary PHY PLL: %d\n", ret);
+			return ret;
+		}
+	}
+
+	if (lvds->primary) {
+		phy = lvds->primary;
+
+		/* Release LVDS PHY from reset mode */
+		lvds_set(lvds, phy->base + phy->ofs.GCR, PHY_GCR_DIV_RSTN | PHY_GCR_RSTZ);
+		lvds_pll_config(lvds, phy);
+
+		ret = lvds_pll_enable(lvds, phy);
+		if (ret) {
+			drm_err(drm, "Failed to enable primary PHY PLL: %d\n", ret);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static void lvds_pixel_clk_disable(struct clk_hw *hw)
+{
+	struct stm_lvds *lvds = container_of(hw, struct stm_lvds, lvds_ck_px);
+
+	/*
+	 * For each PHY:
+	 * Disable DP, LS, BIT clock outputs
+	 * Shutdown the PLL
+	 * Assert LVDS PHY in reset mode
+	 */
+
+	if (lvds->primary) {
+		lvds_clear(lvds, lvds->primary->base + lvds->primary->ofs.GCR,
+			   (PHY_GCR_DP_CLK_OUT | PHY_GCR_LS_CLK_OUT | PHY_GCR_BIT_CLK_OUT));
+		lvds_clear(lvds, lvds->primary->base + lvds->primary->ofs.PLLCR1,
+			   PHY_PLLCR1_PLL_EN);
+		lvds_clear(lvds, lvds->primary->base + lvds->primary->ofs.GCR,
+			   PHY_GCR_DIV_RSTN | PHY_GCR_RSTZ);
+	}
+
+	if (lvds->secondary) {
+		lvds_clear(lvds, lvds->secondary->base + lvds->secondary->ofs.GCR,
+			   (PHY_GCR_DP_CLK_OUT | PHY_GCR_LS_CLK_OUT | PHY_GCR_BIT_CLK_OUT));
+		lvds_clear(lvds, lvds->secondary->base + lvds->secondary->ofs.PLLCR1,
+			   PHY_PLLCR1_PLL_EN);
+		lvds_clear(lvds, lvds->secondary->base + lvds->secondary->ofs.GCR,
+			   PHY_GCR_DIV_RSTN | PHY_GCR_RSTZ);
+	}
+
+	clk_disable_unprepare(lvds->pllref_clk);
+	clk_disable_unprepare(lvds->pclk);
+}
+
+static unsigned long lvds_pixel_clk_recalc_rate(struct clk_hw *hw,
+						unsigned long parent_rate)
+{
+	struct stm_lvds *lvds = container_of(hw, struct stm_lvds, lvds_ck_px);
+	struct drm_device *drm = lvds->lvds_bridge.dev;
+	unsigned int pll_in_khz, bdiv, mdiv, ndiv;
+	int ret, multiplier, pll_out_khz;
+	u32 val;
+
+	ret = clk_prepare_enable(lvds->pclk);
+	if (ret) {
+		drm_err(drm, "Failed to enable lvds peripheral clk\n");
+		return 0;
+	}
+
+	if (lvds_is_dual_link(lvds->link_type))
+		multiplier = 2;
+	else
+		multiplier = 1;
+
+	val = lvds_read(lvds, lvds->primary->base + lvds->primary->ofs.PLLCR2);
+	drm_dbg(drm, "val = %08x\n", val);
+
+	ndiv = (val & PHY_PLLCR2_NDIV) >> 16;
+	bdiv = (val & PHY_PLLCR2_BDIV) >> 0;
+
+	mdiv = (unsigned int)lvds_read(lvds,
+				       lvds->primary->base + lvds->primary->ofs.PLLSDCR1);
+
+	pll_in_khz = (unsigned int)(parent_rate / 1000);
+
+	/* Compute values if not yet accessible */
+	if (val == 0 || mdiv == 0) {
+		lvds_pll_get_params(lvds, pll_in_khz,
+				    lvds->pixel_clock_rate * 7 / 1000 / multiplier,
+				    &bdiv, &mdiv, &ndiv);
+	}
+
+	pll_out_khz = pll_get_clkout_khz(pll_in_khz, bdiv, mdiv, ndiv);
+	drm_dbg(drm, "ndiv %d , bdiv %d, mdiv %d, pll_out_khz %d\n",
+		ndiv, bdiv, mdiv, pll_out_khz);
+
+	/*
+	 * 1/7 because for each pixel in 1 lane there is 7 bits
+	 * We want pixclk, not bitclk
+	 */
+	lvds->pixel_clock_rate = pll_out_khz * 1000 * multiplier / 7;
+
+	clk_disable_unprepare(lvds->pclk);
+
+	return (unsigned long)lvds->pixel_clock_rate;
+}
+
+static long lvds_pixel_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+				      unsigned long *parent_rate)
+{
+	struct stm_lvds *lvds = container_of(hw, struct stm_lvds, lvds_ck_px);
+	unsigned int pll_in_khz, bdiv = 0, mdiv = 0, ndiv = 0;
+	const struct drm_connector *connector;
+	const struct drm_display_mode *mode;
+	int multiplier;
+
+	connector = &lvds->connector;
+	if (!connector)
+		return -EINVAL;
+
+	if (list_empty(&connector->modes)) {
+		drm_dbg(connector->dev, "connector: empty modes list\n");
+		return -EINVAL;
+	}
+
+	mode = list_first_entry(&connector->modes,
+				struct drm_display_mode, head);
+
+	pll_in_khz = (unsigned int)(*parent_rate / 1000);
+
+	if (lvds_is_dual_link(lvds->link_type))
+		multiplier = 2;
+	else
+		multiplier = 1;
+
+	lvds_pll_get_params(lvds, pll_in_khz, mode->clock * 7 / multiplier, &bdiv, &mdiv, &ndiv);
+
+	/*
+	 * 1/7 because for each pixel in 1 lane there is 7 bits
+	 * We want pixclk, not bitclk
+	 */
+	lvds->pixel_clock_rate = (unsigned long)pll_get_clkout_khz(pll_in_khz, bdiv, mdiv, ndiv)
+					 * 1000 * multiplier / 7;
+
+	return lvds->pixel_clock_rate;
+}
+
+static const struct clk_ops lvds_pixel_clk_ops = {
+	.enable = lvds_pixel_clk_enable,
+	.disable = lvds_pixel_clk_disable,
+	.recalc_rate = lvds_pixel_clk_recalc_rate,
+	.round_rate = lvds_pixel_clk_round_rate,
+};
+
+static const struct clk_init_data clk_data = {
+	.name = "clk_pix_lvds",
+	.ops = &lvds_pixel_clk_ops,
+	.parent_names = (const char * []) {"ck_ker_lvdsphy"},
+	.num_parents = 1,
+	.flags = CLK_IGNORE_UNUSED,
+};
+
+static void lvds_pixel_clk_unregister(void *data)
+{
+	struct stm_lvds *lvds = data;
+
+	of_clk_del_provider(lvds->dev->of_node);
+	clk_hw_unregister(&lvds->lvds_ck_px);
+}
+
+static int lvds_pixel_clk_register(struct stm_lvds *lvds)
+{
+	struct device_node *node = lvds->dev->of_node;
+	int ret;
+
+	lvds->lvds_ck_px.init = &clk_data;
+
+	/* set the rate by default at 148500000 */
+	lvds->pixel_clock_rate = 148500000;
+
+	ret = clk_hw_register(lvds->dev, &lvds->lvds_ck_px);
+	if (ret)
+		return ret;
+
+	ret = of_clk_add_hw_provider(node, of_clk_hw_simple_get,
+				     &lvds->lvds_ck_px);
+	if (ret)
+		clk_hw_unregister(&lvds->lvds_ck_px);
+
+	return ret;
+}
+
+/*
+ * Host configuration related
+ */
+static void lvds_config_data_mapping(struct stm_lvds *lvds)
+{
+	struct drm_device *drm = lvds->lvds_bridge.dev;
+	const struct drm_display_info *info;
+	enum lvds_pixel (*bitmap)[7];
+	u32 lvds_dmlcr, lvds_dmmcr;
+	int i;
+
+	info = &(&lvds->connector)->display_info;
+	if (!info->num_bus_formats || !info->bus_formats) {
+		drm_warn(drm, "No LVDS bus format reported\n");
+		return;
+	}
+
+	switch (info->bus_formats[0]) {
+	case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG: /* VESA-RGB666 */
+		drm_warn(drm, "Pixel format with data mapping not yet supported.\n");
+		return;
+	case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG: /* VESA-RGB888 */
+		bitmap = lvds_bitmap_vesa_rgb888;
+		break;
+	case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA: /* JEIDA-RGB888 */
+		bitmap = lvds_bitmap_jeida_rgb888;
+		break;
+	default:
+		drm_warn(drm, "Unsupported LVDS bus format 0x%04x\n", info->bus_formats[0]);
+		return;
+	}
+
+	/* Set bitmap for each lane */
+	for (i = 0; i < 5; i++) {
+		lvds_dmlcr = ((bitmap[i][0])
+			      + (bitmap[i][1] << 5)
+			      + (bitmap[i][2] << 10)
+			      + (bitmap[i][3] << 15));
+		lvds_dmmcr = ((bitmap[i][4])
+			      + (bitmap[i][5] << 5)
+			      + (bitmap[i][6] << 10));
+
+		lvds_write(lvds, LVDS_DMLCR(i), lvds_dmlcr);
+		lvds_write(lvds, LVDS_DMMCR(i), lvds_dmmcr);
+	}
+}
+
+static void lvds_config_mode(struct stm_lvds *lvds)
+{
+	u32 bus_flags, lvds_cr = 0, lvds_cdl1cr = 0, lvds_cdl2cr = 0;
+	const struct drm_display_mode *mode;
+	const struct drm_connector *connector;
+
+	connector = &lvds->connector;
+	if (!connector)
+		return;
+
+	if (list_empty(&connector->modes)) {
+		drm_dbg(connector->dev, "connector: empty modes list\n");
+		return;
+	}
+
+	bus_flags = connector->display_info.bus_flags;
+	mode = list_first_entry(&connector->modes,
+				struct drm_display_mode, head);
+
+	lvds_clear(lvds, LVDS_CR, CR_LKMOD);
+	lvds_clear(lvds, LVDS_CDL1CR, CDLCRx_DISTR0 | CDLCRx_DISTR1 | CDLCRx_DISTR2 |
+				      CDLCRx_DISTR3 | CDLCRx_DISTR4);
+	lvds_clear(lvds, LVDS_CDL2CR, CDLCRx_DISTR0 | CDLCRx_DISTR1 | CDLCRx_DISTR2 |
+				      CDLCRx_DISTR3 | CDLCRx_DISTR4);
+
+	/* Set channel distribution */
+	if (lvds->primary)
+		lvds_cdl1cr = CDL1CR_DEFAULT;
+
+	if (lvds->secondary) {
+		lvds_cr |= CR_LKMOD;
+		lvds_cdl2cr = CDL2CR_DEFAULT;
+	}
+
+	/* Set signal polarity */
+	if (bus_flags & DRM_BUS_FLAG_DE_LOW)
+		lvds_cr |= CR_DEPOL;
+
+	if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+		lvds_cr |= CR_HSPOL;
+
+	if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+		lvds_cr |= CR_VSPOL;
+
+	switch (lvds->link_type) {
+	case LVDS_DUAL_LINK_EVEN_ODD_PIXELS: /* LKPHA = 0 */
+		lvds_cr &= ~CR_LKPHA;
+		break;
+	case LVDS_DUAL_LINK_ODD_EVEN_PIXELS: /* LKPHA = 1 */
+		lvds_cr |= CR_LKPHA;
+		break;
+	default:
+		drm_notice(lvds->lvds_bridge.dev, "No phase precised, setting default\n");
+		lvds_cr &= ~CR_LKPHA;
+		break;
+	}
+
+	/* Write config to registers */
+	lvds_set(lvds, LVDS_CR, lvds_cr);
+	lvds_write(lvds, LVDS_CDL1CR, lvds_cdl1cr);
+	lvds_write(lvds, LVDS_CDL2CR, lvds_cdl2cr);
+}
+
+static int lvds_connector_get_modes(struct drm_connector *connector)
+{
+	struct stm_lvds *lvds = connector_to_stm_lvds(connector);
+
+	return drm_panel_get_modes(lvds->panel, connector);
+}
+
+static int lvds_connector_atomic_check(struct drm_connector *connector,
+				       struct drm_atomic_state *state)
+{
+	const struct drm_display_mode *panel_mode;
+	struct drm_connector_state *conn_state;
+	struct drm_crtc_state *crtc_state;
+
+	conn_state = drm_atomic_get_new_connector_state(state, connector);
+	if (!conn_state)
+		return -EINVAL;
+
+	if (list_empty(&connector->modes)) {
+		drm_dbg(connector->dev, "connector: empty modes list\n");
+		return -EINVAL;
+	}
+
+	if (!conn_state->crtc)
+		return -EINVAL;
+
+	panel_mode = list_first_entry(&connector->modes,
+				      struct drm_display_mode, head);
+
+	/* We're not allowed to modify the resolution. */
+	crtc_state = drm_atomic_get_crtc_state(state, conn_state->crtc);
+	if (IS_ERR(crtc_state))
+		return PTR_ERR(crtc_state);
+
+	if (crtc_state->mode.hdisplay != panel_mode->hdisplay ||
+	    crtc_state->mode.vdisplay != panel_mode->vdisplay)
+		return -EINVAL;
+
+	/* The flat panel mode is fixed, just copy it to the adjusted mode. */
+	drm_mode_copy(&crtc_state->adjusted_mode, panel_mode);
+
+	return 0;
+}
+
+static const struct drm_connector_helper_funcs lvds_conn_helper_funcs = {
+	.get_modes = lvds_connector_get_modes,
+	.atomic_check = lvds_connector_atomic_check,
+};
+
+static const struct drm_connector_funcs lvds_conn_funcs = {
+	.reset = drm_atomic_helper_connector_reset,
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.destroy = drm_connector_cleanup,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int lvds_attach(struct drm_bridge *bridge,
+		       enum drm_bridge_attach_flags flags)
+{
+	struct stm_lvds *lvds = bridge_to_stm_lvds(bridge);
+	struct drm_connector *connector = &lvds->connector;
+	struct drm_encoder *encoder = bridge->encoder;
+	int ret;
+
+	if (!bridge->encoder) {
+		drm_err(bridge->dev, "Parent encoder object not found\n");
+		return -ENODEV;
+	}
+
+	/* Set the encoder type as caller does not know it */
+	bridge->encoder->encoder_type = DRM_MODE_ENCODER_LVDS;
+
+	/* No cloning support */
+	bridge->encoder->possible_clones = 0;
+
+	/* If we have a next bridge just attach it. */
+	if (lvds->next_bridge)
+		return drm_bridge_attach(bridge->encoder, lvds->next_bridge,
+					 bridge, flags);
+
+	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+		drm_err(bridge->dev, "Fix bridge driver to make connector optional!");
+		return -EINVAL;
+	}
+
+	/* Otherwise if we have a panel, create a connector. */
+	if (!lvds->panel)
+		return 0;
+
+	ret = drm_connector_init(bridge->dev, connector,
+				 &lvds_conn_funcs, DRM_MODE_CONNECTOR_LVDS);
+	if (ret < 0)
+		return ret;
+
+	drm_connector_helper_add(connector, &lvds_conn_helper_funcs);
+
+	ret = drm_connector_attach_encoder(connector, encoder);
+
+	return ret;
+}
+
+static void lvds_atomic_enable(struct drm_bridge *bridge,
+			       struct drm_bridge_state *old_bridge_state)
+{
+	struct drm_atomic_state *state = old_bridge_state->base.state;
+	struct stm_lvds *lvds = bridge_to_stm_lvds(bridge);
+	struct drm_connector_state *conn_state;
+	struct drm_connector *connector;
+	int ret;
+
+	ret = clk_prepare_enable(lvds->pclk);
+	if (ret) {
+		drm_err(bridge->dev, "Failed to enable lvds peripheral clk\n");
+		return;
+	}
+
+	connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
+	if (!connector)
+		return;
+
+	conn_state = drm_atomic_get_new_connector_state(state, connector);
+	if (!conn_state)
+		return;
+
+	lvds_config_mode(lvds);
+
+	/* Set Data Mapping */
+	lvds_config_data_mapping(lvds);
+
+	/* Turn the output on. */
+	lvds_set(lvds, LVDS_CR, CR_LVDSEN);
+
+	if (lvds->panel) {
+		drm_panel_prepare(lvds->panel);
+		drm_panel_enable(lvds->panel);
+	}
+}
+
+static void lvds_atomic_disable(struct drm_bridge *bridge,
+				struct drm_bridge_state *old_bridge_state)
+{
+	struct stm_lvds *lvds = bridge_to_stm_lvds(bridge);
+
+	if (lvds->panel) {
+		drm_panel_disable(lvds->panel);
+		drm_panel_unprepare(lvds->panel);
+	}
+
+	/* Disable LVDS module */
+	lvds_clear(lvds, LVDS_CR, CR_LVDSEN);
+
+	clk_disable_unprepare(lvds->pclk);
+}
+
+static const struct drm_bridge_funcs lvds_bridge_funcs = {
+	.attach = lvds_attach,
+	.atomic_enable = lvds_atomic_enable,
+	.atomic_disable = lvds_atomic_disable,
+	.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+	.atomic_reset = drm_atomic_helper_bridge_reset,
+};
+
+static int lvds_probe(struct platform_device *pdev)
+{
+	struct device_node *port1, *port2, *remote;
+	struct device *dev = &pdev->dev;
+	struct reset_control *rstc;
+	struct stm_lvds *lvds;
+	int ret, dual_link;
+
+	dev_dbg(dev, "Probing LVDS driver...\n");
+
+	lvds = devm_kzalloc(dev, sizeof(*lvds), GFP_KERNEL);
+	if (!lvds)
+		return -ENOMEM;
+
+	lvds->dev = dev;
+
+	ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
+					  &lvds->panel, &lvds->next_bridge);
+	if (ret) {
+		dev_err_probe(dev, ret, "Panel not found\n");
+		return ret;
+	}
+
+	lvds->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(lvds->base)) {
+		ret = PTR_ERR(lvds->base);
+		dev_err(dev, "Unable to get regs %d\n", ret);
+		return ret;
+	}
+
+	lvds->pclk = devm_clk_get(dev, "pclk");
+	if (IS_ERR(lvds->pclk)) {
+		ret = PTR_ERR(lvds->pclk);
+		dev_err(dev, "Unable to get peripheral clock: %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(lvds->pclk);
+	if (ret) {
+		dev_err(dev, "%s: Failed to enable peripheral clk\n", __func__);
+		return ret;
+	}
+
+	rstc = devm_reset_control_get_exclusive(dev, NULL);
+
+	if (IS_ERR(rstc)) {
+		ret = PTR_ERR(rstc);
+		goto err_lvds_probe;
+	}
+
+	reset_control_assert(rstc);
+	usleep_range(10, 20);
+	reset_control_deassert(rstc);
+
+	port1 = of_graph_get_port_by_id(dev->of_node, 1);
+	port2 = of_graph_get_port_by_id(dev->of_node, 2);
+	dual_link = drm_of_lvds_get_dual_link_pixel_order(port1, port2);
+
+	switch (dual_link) {
+	case DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS:
+		lvds->link_type = LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+		lvds->primary = &lvds_phy_16ff_primary;
+		lvds->secondary = &lvds_phy_16ff_secondary;
+		break;
+	case DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS:
+		lvds->link_type = LVDS_DUAL_LINK_EVEN_ODD_PIXELS;
+		lvds->primary = &lvds_phy_16ff_primary;
+		lvds->secondary = &lvds_phy_16ff_secondary;
+		break;
+	case -EINVAL:
+		/*
+		 * drm_of_lvds_get_dual_pixel_order returns 4 possible values.
+		 * In the case where the returned value is an error, it can be
+		 * either ENODEV or EINVAL. Seeing the structure of this
+		 * function, EINVAL means that either port1 or port2 is not
+		 * present in the device tree.
+		 * In that case, the lvds panel can be a single link panel, or
+		 * there is a semantical error in the device tree code.
+		 */
+		remote = of_get_next_available_child(port1, NULL);
+		if (remote) {
+			if (of_graph_get_remote_endpoint(remote)) {
+				lvds->link_type = LVDS_SINGLE_LINK_PRIMARY;
+				lvds->primary = &lvds_phy_16ff_primary;
+				lvds->secondary = NULL;
+			} else {
+				ret = -EINVAL;
+			}
+
+			of_node_put(remote);
+		}
+
+		remote = of_get_next_available_child(port2, NULL);
+		if (remote) {
+			if (of_graph_get_remote_endpoint(remote)) {
+				lvds->link_type = LVDS_SINGLE_LINK_SECONDARY;
+				lvds->primary = NULL;
+				lvds->secondary = &lvds_phy_16ff_secondary;
+			} else {
+				ret = (ret == -EINVAL) ? -EINVAL : 0;
+			}
+
+			of_node_put(remote);
+		}
+		break;
+	default:
+		ret = -EINVAL;
+		goto err_lvds_probe;
+	}
+	of_node_put(port1);
+	of_node_put(port2);
+
+	lvds->pllref_clk = devm_clk_get(dev, "ref");
+	if (IS_ERR(lvds->pllref_clk)) {
+		ret = PTR_ERR(lvds->pllref_clk);
+		dev_err(dev, "Unable to get reference clock: %d\n", ret);
+		goto err_lvds_probe;
+	}
+
+	ret = lvds_pixel_clk_register(lvds);
+	if (ret) {
+		dev_err(dev, "Failed to register LVDS pixel clock: %d\n", ret);
+		goto err_lvds_probe;
+	}
+
+	lvds->lvds_bridge.funcs = &lvds_bridge_funcs;
+	lvds->lvds_bridge.of_node = dev->of_node;
+	lvds->hw_version = lvds_read(lvds, LVDS_VERR);
+
+	dev_info(dev, "version 0x%02x initialized\n", lvds->hw_version);
+
+	drm_bridge_add(&lvds->lvds_bridge);
+
+	platform_set_drvdata(pdev, lvds);
+
+	clk_disable_unprepare(lvds->pclk);
+
+	return 0;
+
+err_lvds_probe:
+	clk_disable_unprepare(lvds->pclk);
+
+	return ret;
+}
+
+static int lvds_remove(struct platform_device *pdev)
+{
+	struct stm_lvds *lvds = platform_get_drvdata(pdev);
+
+	lvds_pixel_clk_unregister(lvds);
+
+	drm_bridge_remove(&lvds->lvds_bridge);
+
+	return 0;
+}
+
+static const struct of_device_id lvds_dt_ids[] = {
+	{
+		.compatible = "st,stm32-lvds",
+		.data = NULL
+	},
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, lvds_dt_ids);
+
+static struct platform_driver lvds_platform_driver = {
+	.probe = lvds_probe,
+	.remove = lvds_remove,
+	.driver = {
+		.name = "stm32-display-lvds",
+		.owner = THIS_MODULE,
+		.of_match_table = lvds_dt_ids,
+	},
+};
+
+module_platform_driver(lvds_platform_driver);
+
+MODULE_AUTHOR("Rapha??l Gallais-Pou <raphael.gallais-pou at foss.st.com>");
+MODULE_AUTHOR("Philippe Cornu <philippe.cornu at foss.st.com>");
+MODULE_AUTHOR("Yannick Fertre <yannick.fertre at foss.st.com>");
+MODULE_DESCRIPTION("STMicroelectronics LVDS Display Interface Transmitter DRM driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1



From angelogioacchino.delregno at collabora.com  Thu Dec 21 04:31:31 2023
From: angelogioacchino.delregno at collabora.com (AngeloGioacchino Del Regno)
Date: Thu, 21 Dec 2023 13:31:31 +0100
Subject: Discuss Mediatek Power Domain Driver Support Mulitle Smi Clamp
 Protection
In-Reply-To: <f8150ce2859bc8d22d2fa7cbc671bf2d43d4a86d.camel@mediatek.com>
References: <a3aaf3180fdb3da117132089bd160ba4d5cebc17.camel@mediatek.com>
 <b4fa9b7f-512f-4a34-884a-a99a3b035d34@collabora.com>
 <f8150ce2859bc8d22d2fa7cbc671bf2d43d4a86d.camel@mediatek.com>
Message-ID: <e80dbd42-b9c8-4564-be4e-6ee449d24c70@collabora.com>

Il 21/12/23 09:29, Yu-chang Lee (???) ha scritto:
> On Wed, 2023-12-20 at 14:11 +0100, AngeloGioacchino Del Regno wrote:
>> Il 20/12/23 10:36, Yu-chang Lee (???) ha scritto:
>>> Dear Markus, Matthias, Angelo:
>>>
>>> I am writing to seek your expertise and advice regarding the
>>> revision
>>> of the Mediatek power domain driver for the MT8188 platform.
>>> Specifically, the display power domain requires multiple SMI clamp
>>> protections (refer to [1] in mt8188.dts "MT8188_POWER_DOMAIN_DIP"
>>> "mediatek,smi"). However, the current version on the main branch,
>>> which
>>> has already merged SMI and infra bus protection (mainly [2]),
>>> complicates the mapping of individual SMIs to their respective bus
>>> protections.
>>>
>>> While not a complete solution, I believe the patch in [3] may
>>> better
>>> illustrate my intentions.
>>>
>>> Markus has provided some thoughts and recommendations that I want
>>> to
>>> bring forward, hoping to gain further direction based on your
>>> expertise.
>>>
>>> 1.My initial thought is to revert the changes made in [2], which
>>> separated the SMI infra bus protection operations. This approach
>>> would
>>> simplify the mapping of multiple SMIs to bus protections by their
>>> order
>>> in the DTS. However, reverting to an older version may not be
>>> desired.
>>>
>>
>> Relying on the order of bus protections in DTS can be flaky and prone
>> to generate
>> future mistakes; remember that whatever we send upstream is something
>> that not
>> only has to be working, clean, solid and reliable, but we should also
>> take care
>> of avoiding future mistakes that could happen when somebody from the
>> community, or
>> other MediaTek engineers, implement new platforms.
> 
>> Reverting commits is not prohibited as long as we're not breaking
>> support for any
>> platform (so, as long as we're not removing features), but still, I
>> don't think
>> that this is the best solution, honestly.
>>
>> Besides, I don't get why the order of SMI phandles is important, can
>> you please
>> explain why?
> 
> I apologize for the confusion, The bp_cfg order in mt8188-pm-domain.h
> is important because the order of bus protection is depned on it.
> However smi clamp protection should be done before infra one. So rely
> on this is also a little shaky I think. Also it will take some overhead
> to loop through bp_cfg, mixed with infra and smi, to find the correct
> name smi to do clamp protection.
> 
> That why the first approach seems straight forward to me because it
> separate smi and infra. And we can do different protection with them.
> 
>>
>>> 2.The second approach, suggested by Markus, is to introduce
>>> "mediatek,smi-names" and convert "mediatek,smi" to an array of
>>> phandles. We could add a new field to the struct
>>> scpsys_bus_prot_data,
>>> such as const char *smi_name, which could be NULL (for device trees
>>> with only a single property). This way, we can use the smi-names to
>>> specify the desired SMI. While this method retains the current code
>>> structure, the implementation may not be as straightforward.
>>>
>>
>> To be completely honest, neither of the two approaches are state of
>> the art,
>> but the mediatek,smi-names one is better than the first, granted that
>> we
>> really need to guarantee that the SMIs are ordered.
>>
>> But again, my question is: why should those be ordered?
>> Can't we clamp IMG1 before clamping IMG0?
>>
> We can clamp IMG1 before clamping IMG0, I am more concerned with the
> order between infra and smi rather than the order between smi. And I
> think current structure mixed smi and infra may also introduce
> misunderstanding in the future. Maybe separate the bp_cfg and match the
> smi name with smi's bus protection step could be a direction to fix the
> problem?
> 

That could work, yes. You could alternatively build an array, or a 32 bit value for
which each bit corresponds to the position of a BUS_PROT_WR entry in .bp_cfg, and
then use that to locate SMI vs INFRA bus protection entries.

Taking as an example a "messy" bp_cfg:

.bp_cfg = {
	BUS_PROT_WR(INFRA, other_params),
	BUS_PROT_WR(SMI, other_params),
	BUS_PROT_WR(INFRA, ...),
	BUS_PROT_WR(INFRA, ...),
	BUS_PROT_WR(SMI, ...),
}

probe_function() {
	...

	for (....) {
		if (.bp_cfg[i] == SMI)
			pd->smi_bp_map |= BIT(i);
	}

	....
}

powerup_function() {
	...
	u16 smi_bp_map = pd->smi_bp_map;

	for_each_set_bit(i, &smi_pd_map, 16)
		bus_protect_smi_write(somewhere->bp_cfg[i]);

	...

	bus_protect_infra_write()

	...
}


Or, simply, we can *enforce* ordering in bp_cfg, so that all of the SMI entries
are before INFRA, like:

.bp_cfg = {
	/* Ordering is important here: SMI bus prot always before INFRA */
	BUS_PROT_WR(SMI, other_params),
	BUS_PROT_WR(SMI, ...),
	BUS_PROT_WR(INFRA, other_params),
	BUS_PROT_WR(INFRA, ...),
	BUS_PROT_WR(INFRA, ...),
}

...so that we never build any positional information / bitmaps.

Since the SMI vs INFRA order is really important, we could add a "failsafe" check
in the probe function, like:

probe() {
	bool smi_prot_found;

	for (....) {
		if ((...->bp_cfg[i].flags & BUS_PROT_COMPONENT_INFRA) &&
		    smi_prot_found) {
			dev_err(... , "SMI bus prot cannot be mixed with INFRA");
			return -EINVAL;
		} else if (....->bp_cfg[i] & BUS_PROT_COMPONENT_SMI)
			smi_prot_found = true;
	}
}

Obviously the error message etc should be reworded, all the above is just
examples to solve the issue without having any meaningful overhead in the
performance paths [scpsys_power_on() and scpsys_power_off()].

Does that help you?

Cheers,
Angelo

> Thanks for your timely feedback!
> 
> Best Regards,
> yu-chang.lee
> 
> 
>> Cheers,
>> Angelo
>>
>>> Attempting to resolve this issue, I find the first option easier
>>> and
>>> more direct. However, I would greatly appreciate hearing the
>>> thoughts
>>> of experts on this matter before proceeding with upstreaming.
>>>
>>> I look forward to your valued response.
>>>
>>> Cheers!
>>> Best Regards,
>>> Yu-chang.lee
>>>
>>> [1]:
>>>
> https://urldefense.com/v3/__https://chromium.googlesource.com/chromiumos/third_party/kernel/*/87222665c8f974e4ff9dca408cedf6b540a9e770__;Kw!!CTRNKA9wMg0ARbw!kDNdDHejJnDRc6HgYp1-LOvU7Ij4m23UJizlQOGgaJET_rH1jNegg7tYmhOf8XkHVZF_dqG94-kHyhzX6nZE_6aGNBv2CSyx6g$
>>>   
>>> [2]:
>>>
> https://lore.kernel.org/all/20230918093751.1188668-6-msp at baylibre.com/
>>> [3]:
>>>
> https://urldefense.com/v3/__https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/*/5098295__;Kw!!CTRNKA9wMg0ARbw!kDNdDHejJnDRc6HgYp1-LOvU7Ij4m23UJizlQOGgaJET_rH1jNegg7tYmhOf8XkHVZF_dqG94-kHyhzX6nZE_6aGNBvmL2Hiaw$
>>>   
>>
>>
>>



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:30:34 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:30:34 +0100
Subject: [PATCH v1 5/8] drm/stm: ltdc: add lvds pixel clock
Message-ID: <20231221123037.418851-6-raphael.gallais-pou@foss.st.com>

The STM32MP25x display subsystem presents a mux which feeds the loopback
pixel clock of the current bridge in use into the LTDC. This mux is only
accessible through sysconfig registers which is not yet available in the
STM32MP25x common clock framework.

While waiting for a complete update of the clock framework, this would
allow to use the LVDS.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at st.com>
Signed-off-by: Yannick Fertre <yannick.fertre at foss.st.com>
---
 drivers/gpu/drm/stm/ltdc.c | 18 ++++++++++++++++++
 drivers/gpu/drm/stm/ltdc.h |  1 +
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 67064f47a4cb..1cf9f16e56cc 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -838,6 +838,12 @@ ltdc_crtc_mode_valid(struct drm_crtc *crtc,
 	int target_max = target + CLK_TOLERANCE_HZ;
 	int result;
 
+	if (ldev->lvds_clk) {
+		result = clk_round_rate(ldev->lvds_clk, target);
+		DRM_DEBUG_DRIVER("lvds pixclk rate target %d, available %d\n",
+				 target, result);
+	}
+
 	result = clk_round_rate(ldev->pixel_clk, target);
 
 	DRM_DEBUG_DRIVER("clk rate target %d, available %d\n", target, result);
@@ -1898,6 +1904,8 @@ void ltdc_suspend(struct drm_device *ddev)
 	clk_disable_unprepare(ldev->pixel_clk);
 	if (ldev->bus_clk)
 		clk_disable_unprepare(ldev->bus_clk);
+	if (ldev->lvds_clk)
+		clk_disable_unprepare(ldev->lvds_clk);
 }
 
 int ltdc_resume(struct drm_device *ddev)
@@ -1918,6 +1926,12 @@ int ltdc_resume(struct drm_device *ddev)
 			return -ENODEV;
 		}
 	}
+	if (ldev->lvds_clk) {
+		if (clk_prepare_enable(ldev->lvds_clk)) {
+			DRM_ERROR("Unable to prepare lvds clock\n");
+			return -ENODEV;
+		}
+	}
 
 	return 0;
 }
@@ -1989,6 +2003,10 @@ int ltdc_load(struct drm_device *ddev)
 		}
 	}
 
+	ldev->lvds_clk = devm_clk_get(dev, "lvds");
+	if (IS_ERR(ldev->lvds_clk))
+		ldev->lvds_clk = NULL;
+
 	rstc = devm_reset_control_get_exclusive(dev, NULL);
 
 	mutex_init(&ldev->err_lock);
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 155d8e4a7c6b..662650a0fae2 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
 	void __iomem *regs;
 	struct regmap *regmap;
 	struct clk *pixel_clk;	/* lcd pixel clock */
+	struct clk *lvds_clk;	/* lvds pixel clock */
 	struct clk *bus_clk;	/* bus clock */
 	struct mutex err_lock;	/* protecting error_status */
 	struct ltdc_caps caps;
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:30:35 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:30:35 +0100
Subject: [PATCH v1 6/8] arm64: dts: st: add ltdc support on stm32mp251
In-Reply-To: <20231221123037.418851-6-raphael.gallais-pou@foss.st.com>
References: <20231221123037.418851-6-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221123037.418851-7-raphael.gallais-pou@foss.st.com>

The LCD-TFT Display Controller (LTDC) handles display composition,
scaling and rotation. It provides a parallel digital RGB flow to be used
by display interfaces.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 93bc8a8908ce..064077e98dfd 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -212,6 +212,18 @@ i2c8: i2c at 46040000 {
 				status = "disabled";
 			};
 
+			ltdc: display-controller at 48010000 {
+				compatible = "st,stm32-ltdc";
+				reg = <0x48010000 0x400>;
+				st,syscon = <&syscfg>;
+				interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_BUS_LTDC>, <&rcc CK_KER_LTDC>;
+				clock-names = "bus", "lcd";
+				resets = <&rcc LTDC_R>;
+				status = "disabled";
+			};
+
 			sdmmc1: mmc at 48220000 {
 				compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
 				arm,primecell-periphid = <0x00353180>;
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:30:36 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:30:36 +0100
Subject: [PATCH v1 7/8] arm64: dts: st: add lvds support on stm32mp253
In-Reply-To: <20231221123037.418851-6-raphael.gallais-pou@foss.st.com>
References: <20231221123037.418851-6-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221123037.418851-8-raphael.gallais-pou@foss.st.com>

This patch adds LVDS support on stm32mp253.  The LVDS is used on
STM32MP2 as a display interface.  LVDS PLL clock is binded to the LTDC
input clock.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp253.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp253.dtsi b/arch/arm64/boot/dts/st/stm32mp253.dtsi
index af48e82efe8a..bcc605e502de 100644
--- a/arch/arm64/boot/dts/st/stm32mp253.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp253.dtsi
@@ -21,3 +21,20 @@ arm-pmu {
 		interrupt-affinity = <&cpu0>, <&cpu1>;
 	};
 };
+
+&ltdc {
+	clocks = <&rcc CK_BUS_LTDC>, <&rcc CK_KER_LTDC>, <&lvds 0>;
+	clock-names = "bus", "lcd", "lvds";
+};
+
+&rifsc {
+	lvds: lvds at 48060000 {
+		#clock-cells = <0>;
+		compatible = "st,stm32-lvds";
+		reg = <0x48060000 0x2000>;
+		clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
+		clock-names = "pclk", "ref";
+		resets = <&rcc LVDS_R>;
+		status = "disabled";
+	};
+};
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:30:37 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:30:37 +0100
Subject: [PATCH v1 8/8] arm64: dts: st: add display support on stm32mp257f-ev
In-Reply-To: <20231221123037.418851-6-raphael.gallais-pou@foss.st.com>
References: <20231221123037.418851-6-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221123037.418851-9-raphael.gallais-pou@foss.st.com>

This patch enables the following IPs on stm32mp257f-ev :
  * LTDC
  * LVDS
  * WSVGA LVDS panel (1024x600)
  * Panel backlight
  * Ilitek touchescreen

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 79 ++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 0ea8e69bfb3d..ca2da988d91c 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -29,6 +29,43 @@ memory at 80000000 {
 		reg = <0x0 0x80000000 0x1 0x0>;
 	};
 
+	panel_lvds: panel-lvds {
+		compatible = "edt,etml0700z9ndha", "panel-lvds";
+		enable-gpios = <&gpiog 15 GPIO_ACTIVE_HIGH>;
+		backlight = <&panel_lvds_backlight>;
+		status = "okay";
+
+		width-mm = <156>;
+		height-mm = <92>;
+		data-mapping = "vesa-24";
+
+		panel-timing {
+			clock-frequency = <54000000>;
+			hactive = <1024>;
+			vactive = <600>;
+			hfront-porch = <150>;
+			hback-porch = <150>;
+			hsync-len = <21>;
+			vfront-porch = <24>;
+			vback-porch = <24>;
+			vsync-len = <21>;
+		};
+
+		port {
+			lvds_panel_in: endpoint {
+				remote-endpoint = <&lvds_out0>;
+			};
+		};
+	};
+
+	panel_lvds_backlight: panel-lvds-backlight {
+		compatible = "gpio-backlight";
+		gpios = <&gpioi 5 GPIO_ACTIVE_HIGH>;
+		default-on;
+		default-brightness-level = <0>;
+		status = "okay";
+	};
+
 	reserved-memory {
 		#address-cells = <2>;
 		#size-cells = <2>;
@@ -63,6 +100,15 @@ &i2c2 {
 	i2c-scl-falling-time-ns = <13>;
 	clock-frequency = <400000>;
 	status = "okay";
+
+	ili2511: ili2511 at 41 {
+		compatible = "ilitek,ili251x";
+		reg = <0x41>;
+		interrupt-parent = <&gpioi>;
+		interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&gpiog 14 GPIO_ACTIVE_LOW>;
+		status = "okay";
+	};
 };
 
 &i2c8 {
@@ -75,6 +121,39 @@ &i2c8 {
 	status = "disabled";
 };
 
+&ltdc {
+	status = "okay";
+
+	port {
+		ltdc_ep0_out: endpoint {
+			remote-endpoint = <&lvds_in>;
+		};
+	};
+};
+
+&lvds {
+	status = "okay";
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port at 0 {
+			reg = <0>;
+			lvds_in: endpoint {
+				remote-endpoint = <&ltdc_ep0_out>;
+			};
+		};
+
+		port at 1 {
+			reg = <1>;
+			lvds_out0: endpoint {
+				remote-endpoint = <&lvds_panel_in>;
+			};
+		};
+	};
+};
+
 &sdmmc1 {
 	pinctrl-names = "default", "opendrain", "sleep";
 	pinctrl-0 = <&sdmmc1_b4_pins_a>;
-- 
2.25.1



From knaerzche at gmail.com  Thu Dec 21 04:40:42 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 21 Dec 2023 13:40:42 +0100
Subject: [PATCH v5 0/5] Add support for video hardware codec of
 STMicroelectronics STM32 SoC series
In-Reply-To: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
Message-ID: <769a1510-f8d2-4095-9879-42f413141dee@gmail.com>

Hi Hugues, Hi Nicolas,

is there any specific reason I'm not understanding / seeing why this is 
added in two seperate vdec* / venc* files and not a single vpu* file? Is 
it only for the seperate clocks (-names) / irqs (-names) / callbacks? 
Those are defined per variant and perfectly fit in a single file holding 
one vdec and one venc variant.

Alex

Am 21.12.23 um 09:47 schrieb Hugues Fruchet:
> This patchset introduces support for VDEC video hardware decoder
> and VENC video hardware encoder of STMicroelectronics STM32MP25
> SoC series.
> 
> This initial support implements H264 decoding, VP8 decoding and
> JPEG encoding.
> 
> This has been tested on STM32MP257F-EV1 evaluation board.
> 
> ===========
> = history =
> ===========
> version 5:
>     - Precise that video decoding as been successfully tested up to full HD
>     - Add Nicolas Dufresne reviewed-by
> 
> version 4:
>     - Fix comments from Nicolas about dropping encoder raw steps
> 
> version 3:
>     - Fix remarks from Krzysztof Kozlowski:
>      - drop "items", we keep simple enum in such case
>      - drop second example - it is the same as the first
>     - Drop unused node labels as suggested by Conor Dooley
>     - Revisit min/max resolutions as suggested by Nicolas Dufresne
> 
> version 2:
>     - Fix remarks from Krzysztof Kozlowski on v1:
>      - single video-codec binding for both VDEC/VENC
>      - get rid of "-names"
>      - use of generic node name "video-codec"
> 
> version 1:
>    - Initial submission
> 
> Hugues Fruchet (5):
>    dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
>    media: hantro: add support for STM32MP25 VDEC
>    media: hantro: add support for STM32MP25 VENC
>    arm64: dts: st: add video decoder support to stm32mp255
>    arm64: dts: st: add video encoder support to stm32mp255
> 
>   .../media/st,stm32mp25-video-codec.yaml       |  50 ++++++++
>   arch/arm64/boot/dts/st/stm32mp251.dtsi        |  12 ++
>   arch/arm64/boot/dts/st/stm32mp255.dtsi        |  17 +++
>   drivers/media/platform/verisilicon/Kconfig    |  14 ++-
>   drivers/media/platform/verisilicon/Makefile   |   4 +
>   .../media/platform/verisilicon/hantro_drv.c   |   4 +
>   .../media/platform/verisilicon/hantro_hw.h    |   2 +
>   .../platform/verisilicon/stm32mp25_vdec_hw.c  |  92 ++++++++++++++
>   .../platform/verisilicon/stm32mp25_venc_hw.c  | 115 ++++++++++++++++++
>   9 files changed, 307 insertions(+), 3 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
>   create mode 100644 drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>   create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
> 



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:43:32 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:43:32 +0100
Subject: [PATCH RESEND v1 1/8] dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds
In-Reply-To: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221124339.420119-2-raphael.gallais-pou@foss.st.com>

List EDT ETML0700Z9NDHA in the LVDS panel enumeration.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
index 9f1016551e0b..3fb24393529c 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
@@ -42,6 +42,8 @@ properties:
           - auo,b101ew05
           # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel
           - chunghwa,claa070wp03xg
+          # EDT ETML0700Z9NDHA 7.0" WSVGA (1024x600) color TFT LCD LVDS panel
+          - edt,etml0700z9ndha
           # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel
           - hannstar,hsd101pww2
           # Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:43:33 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:43:33 +0100
Subject: [PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings for STM32 LVDS device
In-Reply-To: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221124339.420119-3-raphael.gallais-pou@foss.st.com>

Add dt-binding file for "st,stm32-lvds" compatible.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 .../bindings/display/st,stm32-lvds.yaml       | 114 ++++++++++++++++++
 1 file changed, 114 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml

diff --git a/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
new file mode 100644
index 000000000000..d72c9088133c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/st,stm32-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 LVDS Display Interface Transmitter
+
+maintainers:
+  - Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
+  - Yannick Fertre <yannick.fertre at foss.st.com>
+
+description: |
+  The STMicroelectronics STM32 LVDS Display Interface Transmitter handles the
+  LVDS protocol: it maps the pixels received from the upstream Pixel-DMA (LTDC)
+  onto the LVDS PHY.
+
+  It regroups three sub blocks:
+    - LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input
+      pixels onto the data lanes of the PHY
+    - LVDS PHY: parallelize the data and drives the LVDS data lanes
+    - LVDS wrapper: handles top-level settings
+
+  The LVDS controller driver supports the following high-level features:
+    - FDP-Link-I and OpenLDI (v0.95) protocols
+    - Single-Link or Dual-Link operation
+    - Single-Display or Double-Display (with the same content duplicated on both)
+    - Flexible Bit-Mapping, including JEIDA and VESA
+    - RGB888 or RGB666 output
+    - Synchronous design, with one input pixel per clock cycle
+
+properties:
+  "#clock-cells":
+    const: 0
+
+  compatible:
+    const: st,stm32-lvds
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: APB peripheral clock
+      - description: Reference clock for the internal PLL
+
+  clock-names:
+    items:
+      - const: pclk
+      - const: ref
+
+  resets:
+    maxItems: 1
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port at 0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: |
+          LVDS input port node, connected to the LTDC RGB output port.
+
+      port at 1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: |
+          LVDS output port node, connected to a panel or bridge input port.
+
+required:
+  - "#clock-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+  - ports
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/bus/stm32mp25_sys_bus.h>
+    #include <dt-bindings/clock/stm32mp25-clks.h>
+    #include <dt-bindings/reset/stm32mp25-resets.h>
+
+    lvds: lvds at 48060000 {
+        #clock-cells = <0>;
+        compatible = "st,stm32-lvds";
+        reg = <0x48060000 0x2000>;
+        clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
+        clock-names = "pclk", "ref";
+        resets = <&rcc LVDS_R>;
+
+        ports {
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            port at 0 {
+                reg = <0>;
+                lvds_in: endpoint {
+                   remote-endpoint = <&ltdc_ep1_out>;
+                };
+            };
+
+            port at 1 {
+                reg = <1>;
+                lvds_out0: endpoint {
+                   remote-endpoint = <&lvds_panel_in>;
+                };
+            };
+        };
+    };
+
+...
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:43:31 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:43:31 +0100
Subject: [PATCH RESEND v1 0/8] Introduce STM32 LVDS driver
Message-ID: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>

This serie introduces a new DRM bridge driver for STM32MP257 platforms
based on Arm Cortex-35. It also adds an instance in the device-tree and
handle the inclusion of the driver within the DRM framework. First patch
adds a new panel compatible in the panel-lvds driver, which is used by
default on the STM32MP257.

Raphael Gallais-Pou (7):
  dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds
  dt-bindings: display: add dt-bindings for STM32 LVDS device
  drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
  drm/stm: ltdc: add lvds pixel clock
  arm64: dts: st: add ltdc support on stm32mp251
  arm64: dts: st: add lvds support on stm32mp253
  arm64: dts: st: add display support on stm32mp257f-ev

Yannick Fertre (1):
  drm/stm: ltdc: implement bus clock

 .../bindings/display/panel/panel-lvds.yaml    |    2 +
 .../bindings/display/st,stm32-lvds.yaml       |  114 ++
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |   12 +
 arch/arm64/boot/dts/st/stm32mp253.dtsi        |   17 +
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts    |   79 ++
 drivers/gpu/drm/stm/Kconfig                   |   11 +
 drivers/gpu/drm/stm/Makefile                  |    2 +
 drivers/gpu/drm/stm/ltdc.c                    |   26 +
 drivers/gpu/drm/stm/ltdc.h                    |    2 +
 drivers/gpu/drm/stm/lvds.c                    | 1226 +++++++++++++++++
 10 files changed, 1491 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
 create mode 100644 drivers/gpu/drm/stm/lvds.c

-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:43:34 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:43:34 +0100
Subject: [PATCH RESEND v1 3/8] drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
In-Reply-To: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221124339.420119-4-raphael.gallais-pou@foss.st.com>

The Low-Voltage Differential Signaling (LVDS) Display Interface
Transmitter handles the LVDS protocol: it maps the pixels received from
the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS
PHY.

It regroups three sub blocks:
	* LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps
	  its input pixels onto the data lanes of the PHY
	* LVDS PHY: parallelize the data and drives the LVDS data lanes
	* LVDS wrapper: handles top-level settings

The LVDS controller driver supports the following high-level features:
	* FDP-Link-I and OpenLDI (v0.95) protocols
	* Single-Link or Dual-Link operation
	* Single-Display or Double-Display (with the same content
	  duplicated on both)
	* Flexible Bit-Mapping, including JEIDA and VESA
	* RGB888 or RGB666 output
	* Synchronous design, with one input pixel per clock cycle

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 drivers/gpu/drm/stm/Kconfig  |   11 +
 drivers/gpu/drm/stm/Makefile |    2 +
 drivers/gpu/drm/stm/lvds.c   | 1226 ++++++++++++++++++++++++++++++++++
 3 files changed, 1239 insertions(+)
 create mode 100644 drivers/gpu/drm/stm/lvds.c

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index fa49cde43bb2..9627814d027c 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -20,3 +20,14 @@ config DRM_STM_DSI
 	select DRM_DW_MIPI_DSI
 	help
 	  Choose this option for MIPI DSI support on STMicroelectronics SoC.
+
+config DRM_STM_LVDS
+	tristate "STMicroelectronics LVDS Display Interface Transmitter DRM driver"
+	depends on DRM_STM
+	help
+	  Enable support for LVDS encoders on STMicroelectronics SoC.
+	  The STM LVDS is a bridge which serialize pixel stream onto
+	  a LVDS protocol.
+
+	  To compile this driver as a module, choose M here: the module will be
+	  called lvds.
diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile
index 4df5caf01f35..ad740d6175a6 100644
--- a/drivers/gpu/drm/stm/Makefile
+++ b/drivers/gpu/drm/stm/Makefile
@@ -5,4 +5,6 @@ stm-drm-y := \
 
 obj-$(CONFIG_DRM_STM_DSI) += dw_mipi_dsi-stm.o
 
+obj-$(CONFIG_DRM_STM_LVDS) += lvds.o
+
 obj-$(CONFIG_DRM_STM) += stm-drm.o
diff --git a/drivers/gpu/drm/stm/lvds.c b/drivers/gpu/drm/stm/lvds.c
new file mode 100644
index 000000000000..f01490939ab5
--- /dev/null
+++ b/drivers/gpu/drm/stm/lvds.c
@@ -0,0 +1,1226 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ * Author(s): Rapha??l GALLAIS-POU <raphael.gallais-pou at foss.st.com> for STMicroelectronics.
+ */
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_bridge.h>
+#include <drm/drm_device.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_print.h>
+#include <drm/drm_probe_helper.h>
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/media-bus-format.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/reset.h>
+
+/* LVDS Host registers */
+#define LVDS_CR		0x0000  /* configuration register */
+#define LVDS_DMLCR0	0x0004  /* data mapping lsb configuration register 0 */
+#define LVDS_DMMCR0	0x0008  /* data mapping msb configuration register 0 */
+#define LVDS_DMLCR1	0x000C  /* data mapping lsb configuration register 1 */
+#define LVDS_DMMCR1	0x0010  /* data mapping msb configuration register 1 */
+#define LVDS_DMLCR2	0x0014  /* data mapping lsb configuration register 2 */
+#define LVDS_DMMCR2	0x0018  /* data mapping msb configuration register 2 */
+#define LVDS_DMLCR3	0x001C  /* data mapping lsb configuration register 3 */
+#define LVDS_DMMCR3	0x0020  /* data mapping msb configuration register 3 */
+#define LVDS_DMLCR4	0x0024  /* data mapping lsb configuration register 4 */
+#define LVDS_DMMCR4	0x0028  /* data mapping msb configuration register 4 */
+#define LVDS_CDL1CR	0x002C  /* channel distrib link 1 configuration register */
+#define LVDS_CDL2CR	0x0030  /* channel distrib link 2 configuration register */
+
+#define CDL1CR_DEFAULT	0x04321 /* Default value for CDL1CR */
+#define CDL2CR_DEFAULT	0x59876 /* Default value for CDL2CR */
+
+#define LVDS_DMLCR(bit)	(LVDS_DMLCR0 + 0x8 * (bit))
+#define LVDS_DMMCR(bit)	(LVDS_DMMCR0 + 0x8 * (bit))
+
+/* LVDS Wrapper registers */
+#define LVDS_WCLKCR	0x11B0  /* Wrapper clock control register */
+
+#define LVDS_HWCFGR	0x1FF0  /* HW configuration register	*/
+#define LVDS_VERR	0x1FF4  /* Version register	*/
+#define LVDS_IPIDR	0x1FF8  /* Identification register	*/
+#define LVDS_SIDR	0x1FFC  /* Size Identification register	*/
+
+/* Bitfield description */
+#define CR_LVDSEN	BIT(0)  /* LVDS PHY Enable */
+#define CR_HSPOL	BIT(1)  /* Horizontal Synchronization Polarity */
+#define CR_VSPOL	BIT(2)  /* Vertical Synchronization Polarity */
+#define CR_DEPOL	BIT(3)  /* Data Enable Polarity */
+#define CR_CI		BIT(4)  /* Control Internal (software controlled bit) */
+#define CR_LKMOD	BIT(5)  /* Link Mode, for both Links */
+#define CR_LKPHA	BIT(6)  /* Link Phase, for both Links */
+#define CR_LK1POL	GENMASK(20, 16)  /* Link-1 output Polarity */
+#define CR_LK2POL	GENMASK(25, 21)  /* Link-2 output Polarity */
+
+#define DMMCRx_MAP0	GENMASK(4, 0) /* Mapping for bit 0 of datalane x */
+#define DMMCRx_MAP1	GENMASK(9, 5) /* Mapping for bit 1 of datalane x */
+#define DMMCRx_MAP2	GENMASK(14, 10) /* Mapping for bit 2 of datalane x */
+#define DMMCRx_MAP3	GENMASK(19, 15) /* Mapping for bit 3 of datalane x */
+#define DMLCRx_MAP4	GENMASK(4, 0) /* Mapping for bit 4 of datalane x */
+#define DMLCRx_MAP5	GENMASK(9, 5) /* Mapping for bit 5 of datalane x */
+#define DMLCRx_MAP6	GENMASK(14, 10) /* Mapping for bit 6 of datalane x */
+
+#define CDLCRx_DISTR0	GENMASK(3, 0) /* Channel distribution for lane 0 */
+#define CDLCRx_DISTR1	GENMASK(7, 4) /* Channel distribution for lane 1 */
+#define CDLCRx_DISTR2	GENMASK(11, 8) /* Channel distribution for lane 2 */
+#define CDLCRx_DISTR3	GENMASK(15, 12) /* Channel distribution for lane 3 */
+#define CDLCRx_DISTR4	GENMASK(19, 16) /* Channel distribution for lane 4 */
+
+#define PHY_GCR_BIT_CLK_OUT	BIT(0)  /* BIT clock enable */
+#define PHY_GCR_LS_CLK_OUT	BIT(4)  /* LS clock enable */
+#define PHY_GCR_DP_CLK_OUT	BIT(8)  /* DP clock enable */
+#define PHY_GCR_RSTZ		BIT(24) /* LVDS PHY digital reset */
+#define PHY_GCR_DIV_RSTN	BIT(25) /* Output divider reset */
+#define PHY_SCR_TX_EN		BIT(16) /* Transmission mode enable */
+/* Current mode driver enable */
+#define PHY_CMCR_CM_EN_DL	(BIT(28) | BIT(20) | BIT(12) | BIT(4))
+#define PHY_CMCR_CM_EN_DL4	BIT(4)
+/* Bias enable */
+#define PHY_BCR1_EN_BIAS_DL	(BIT(16) | BIT(12) | BIT(8) | BIT(4) | BIT(0))
+#define PHY_BCR2_BIAS_EN	BIT(28)
+/* Voltage mode driver enable */
+#define PHY_BCR3_VM_EN_DL	(BIT(16) | BIT(12) | BIT(8) | BIT(4) | BIT(0))
+#define PHY_DCR_POWER_OK	BIT(12)
+#define PHY_CFGCR_EN_DIG_DL	GENMASK(4, 0) /* LVDS PHY digital lane enable */
+#define PHY_PLLCR1_PLL_EN	BIT(0) /* LVDS PHY PLL enable */
+#define PHY_PLLCR1_EN_SD	BIT(1) /* LVDS PHY PLL sigma-delta signal enable */
+#define PHY_PLLCR1_EN_TWG	BIT(2) /* LVDS PHY PLL triangular wave generator enable */
+#define PHY_PLLCR1_DIV_EN	BIT(8) /* LVDS PHY PLL dividers enable */
+#define PHY_PLLCR2_NDIV		GENMASK(25, 16) /* NDIV mask value */
+#define PHY_PLLCR2_BDIV		GENMASK(9, 0)   /* BDIV mask value */
+#define PHY_PLLSR_PLL_LOCK	BIT(0) /* LVDS PHY PLL lock status */
+#define PHY_PLLSDCR1_MDIV	GENMASK(9, 0)   /* MDIV mask value */
+#define PHY_PLLTESTCR_TDIV	GENMASK(25, 16) /* TDIV mask value */
+#define PHY_PLLTESTCR_CLK_EN	BIT(0) /* Test clock enable */
+#define PHY_PLLTESTCR_EN	BIT(8) /* Test divider output enable */
+
+#define WCLKCR_SECND_CLKPIX_SEL	BIT(0) /* Pixel clock selection */
+#define WCLKCR_SRCSEL		BIT(8) /* Source selection for the pixel clock */
+
+/* Sleep & timeout for pll lock/unlock */
+#define SLEEP_US	1000
+#define TIMEOUT_US	200000
+
+/*
+ * The link phase defines whether an ODD pixel is carried over together with
+ * the next EVEN pixel or together with the previous EVEN pixel.
+ *
+ * LVDS_DUAL_LINK_EVEN_ODD_PIXELS (LKPHA = 0)
+ *
+ * ,--------.  ,--------.  ,--------.  ,--------.  ,---------.
+ * | ODD  LK \/ PIXEL  3 \/ PIXEL  1 \/ PIXEL' 1 \/ PIXEL' 3 |
+ * | EVEN LK /\ PIXEL  2 /\ PIXEL' 0 /\ PIXEL' 2 /\ PIXEL' 4 |
+ * `--------'  `--------'  `--------'  `--------'  `---------'
+ *
+ * LVDS_DUAL_LINK_ODD_EVEN_PIXELS (LKPHA = 1)
+ *
+ * ,--------.  ,--------.  ,--------.  ,--------.  ,---------.
+ * | ODD  LK \/ PIXEL  3 \/ PIXEL  1 \/ PIXEL' 1 \/ PIXEL' 3 |
+ * | EVEN LK /\ PIXEL  4 /\ PIXEL  2 /\ PIXEL' 0 /\ PIXEL' 2 |
+ * `--------'  `--------'  `--------'  `--------'  `---------'
+ *
+ */
+enum lvds_link_type {
+	LVDS_SINGLE_LINK_PRIMARY = 0,
+	LVDS_SINGLE_LINK_SECONDARY,
+	LVDS_DUAL_LINK_EVEN_ODD_PIXELS,
+	LVDS_DUAL_LINK_ODD_EVEN_PIXELS,
+};
+
+enum lvds_pixel {
+	PIX_R_0 = 0,
+	PIX_R_1,
+	PIX_R_2,
+	PIX_R_3,
+	PIX_R_4,
+	PIX_R_5,
+	PIX_R_6,
+	PIX_R_7,
+	PIX_G_0,
+	PIX_G_1,
+	PIX_G_2,
+	PIX_G_3,
+	PIX_G_4,
+	PIX_G_5,
+	PIX_G_6,
+	PIX_G_7,
+	PIX_B_0,
+	PIX_B_1,
+	PIX_B_2,
+	PIX_B_3,
+	PIX_B_4,
+	PIX_B_5,
+	PIX_B_6,
+	PIX_B_7,
+	PIX_H_S,
+	PIX_V_S,
+	PIX_D_E,
+	PIX_C_E,
+	PIX_C_I,
+	PIX_TOG,
+	PIX_ONE,
+	PIX_ZER,
+};
+
+struct phy_reg_offsets {
+	u32 GCR;	/* Global Control Register	*/
+	u32 CMCR1;    /* Current Mode Control Register 1 */
+	u32 CMCR2;    /* Current Mode Control Register 2 */
+	u32 SCR;      /* Serial Control Register	*/
+	u32 BCR1;     /* Bias Control Register 1	*/
+	u32 BCR2;     /* Bias Control Register 2	*/
+	u32 BCR3;     /* Bias Control Register 3	*/
+	u32 MPLCR;    /* Monitor PLL Lock Control Register */
+	u32 DCR;      /* Debug Control Register	*/
+	u32 SSR1;     /* Spare Status Register 1	*/
+	u32 CFGCR;    /* Configuration Control Register */
+	u32 PLLCR1;   /* PLL_MODE 1 Control Register	*/
+	u32 PLLCR2;   /* PLL_MODE 2 Control Register	*/
+	u32 PLLSR;    /* PLL Status Register	*/
+	u32 PLLSDCR1; /* PLL_SD_1 Control Register	*/
+	u32 PLLSDCR2; /* PLL_SD_2 Control Register	*/
+	u32 PLLTWGCR1;/* PLL_TWG_1 Control Register	*/
+	u32 PLLTWGCR2;/* PLL_TWG_2 Control Register	*/
+	u32 PLLCPCR;  /* PLL_CP Control Register	*/
+	u32 PLLTESTCR;/* PLL_TEST Control Register	*/
+};
+
+struct lvds_phy_info {
+	u32 base;
+	struct phy_reg_offsets ofs;
+};
+
+static struct lvds_phy_info lvds_phy_16ff_primary = {
+	.base = 0x1000,
+	.ofs = {
+		.GCR = 0x0,
+		.CMCR1 = 0xC,
+		.CMCR2 = 0x10,
+		.SCR = 0x20,
+		.BCR1 = 0x2C,
+		.BCR2 = 0x30,
+		.BCR3 = 0x34,
+		.MPLCR = 0x64,
+		.DCR = 0x84,
+		.SSR1 = 0x88,
+		.CFGCR = 0xA0,
+		.PLLCR1 = 0xC0,
+		.PLLCR2 = 0xC4,
+		.PLLSR = 0xC8,
+		.PLLSDCR1 = 0xCC,
+		.PLLSDCR2 = 0xD0,
+		.PLLTWGCR1 = 0xD4,
+		.PLLTWGCR2 = 0xD8,
+		.PLLCPCR = 0xE0,
+		.PLLTESTCR = 0xE8,
+	}
+};
+
+static struct lvds_phy_info lvds_phy_16ff_secondary = {
+	.base = 0x1100,
+	.ofs = {
+		.GCR = 0x0,
+		.CMCR1 = 0xC,
+		.CMCR2 = 0x10,
+		.SCR = 0x20,
+		.BCR1 = 0x2C,
+		.BCR2 = 0x30,
+		.BCR3 = 0x34,
+		.MPLCR = 0x64,
+		.DCR = 0x84,
+		.SSR1 = 0x88,
+		.CFGCR = 0xA0,
+		.PLLCR1 = 0xC0,
+		.PLLCR2 = 0xC4,
+		.PLLSR = 0xC8,
+		.PLLSDCR1 = 0xCC,
+		.PLLSDCR2 = 0xD0,
+		.PLLTWGCR1 = 0xD4,
+		.PLLTWGCR2 = 0xD8,
+		.PLLCPCR = 0xE0,
+		.PLLTESTCR = 0xE8,
+	}
+};
+
+struct stm_lvds {
+	void __iomem *base;
+	struct device *dev;
+	struct clk *pclk;		/* APB peripheral clock */
+	struct clk *pllref_clk;		/* Reference clock for the internal PLL */
+	struct clk_hw lvds_ck_px;	/* Pixel clock */
+	u32 pixel_clock_rate;		/* Pixel clock rate */
+
+	struct lvds_phy_info *primary;
+	struct lvds_phy_info *secondary;
+
+	struct drm_bridge lvds_bridge;
+	struct drm_bridge *next_bridge;
+	struct drm_connector connector;
+	struct drm_encoder *encoder;
+	struct drm_panel *panel;
+
+	u32 hw_version;
+	u32 link_type;
+};
+
+#define bridge_to_stm_lvds(b) \
+	container_of(b, struct stm_lvds, lvds_bridge)
+
+#define connector_to_stm_lvds(c) \
+	container_of(c, struct stm_lvds, connector)
+
+#define lvds_is_dual_link(lvds) \
+	({	\
+	typeof(lvds) __lvds = (lvds);	\
+	__lvds == LVDS_DUAL_LINK_EVEN_ODD_PIXELS ||	\
+	__lvds == LVDS_DUAL_LINK_ODD_EVEN_PIXELS;	\
+	})
+
+static inline void lvds_write(struct stm_lvds *lvds, u32 reg, u32 val)
+{
+	writel(val, lvds->base + reg);
+}
+
+static inline u32 lvds_read(struct stm_lvds *lvds, u32 reg)
+{
+	return readl(lvds->base + reg);
+}
+
+static inline void lvds_set(struct stm_lvds *lvds, u32 reg, u32 mask)
+{
+	lvds_write(lvds, reg, lvds_read(lvds, reg) | mask);
+}
+
+static inline void lvds_clear(struct stm_lvds *lvds, u32 reg, u32 mask)
+{
+	lvds_write(lvds, reg, lvds_read(lvds, reg) & ~mask);
+}
+
+/*
+ * Expected JEIDA-RGB888 data to be sent in LSB format
+ *	    bit6 ............................bit0
+ * CHAN0   {ONE, ONE, ZERO, ZERO, ZERO, ONE, ONE}
+ * CHAN1   {G2,  R7,  R6,   R5,   R4,   R3,  R2}
+ * CHAN2   {B3,  B2,  G7,   G6,   G5,   G4,  G3}
+ * CHAN3   {DE,  VS,  HS,   B7,   B6,   B5,  B4}
+ * CHAN4   {CE,  B1,  B0,   G1,   G0,   R1,  R0}
+ */
+enum lvds_pixel lvds_bitmap_jeida_rgb888[5][7] = {
+	{ PIX_ONE, PIX_ONE, PIX_ZER, PIX_ZER, PIX_ZER, PIX_ONE, PIX_ONE },
+	{ PIX_G_2, PIX_R_7, PIX_R_6, PIX_R_5, PIX_R_4, PIX_R_3, PIX_R_2 },
+	{ PIX_B_3, PIX_B_2, PIX_G_7, PIX_G_6, PIX_G_5, PIX_G_4, PIX_G_3 },
+	{ PIX_D_E, PIX_V_S, PIX_H_S, PIX_B_7, PIX_B_6, PIX_B_5, PIX_B_4 },
+	{ PIX_C_E, PIX_B_1, PIX_B_0, PIX_G_1, PIX_G_0, PIX_R_1, PIX_R_0 }
+};
+
+/*
+ * Expected VESA-RGB888 data to be sent in LSB format
+ *	    bit6 ............................bit0
+ * CHAN0   {ONE, ONE, ZERO, ZERO, ZERO, ONE, ONE}
+ * CHAN1   {G0,  R5,  R4,   R3,   R2,   R1,  R0}
+ * CHAN2   {B1,  B0,  G5,   G4,   G3,   G2,  G1}
+ * CHAN3   {DE,  VS,  HS,   B5,   B4,   B3,  B2}
+ * CHAN4   {CE,  B7,  B6,   G7,   G6,   R7,  R6}
+ */
+enum lvds_pixel lvds_bitmap_vesa_rgb888[5][7] = {
+	{ PIX_ONE, PIX_ONE, PIX_ZER, PIX_ZER, PIX_ZER, PIX_ONE, PIX_ONE },
+	{ PIX_G_0, PIX_R_5, PIX_R_4, PIX_R_3, PIX_R_2, PIX_R_1, PIX_R_0 },
+	{ PIX_B_1, PIX_B_0, PIX_G_5, PIX_G_4, PIX_G_3, PIX_G_2, PIX_G_1 },
+	{ PIX_D_E, PIX_V_S, PIX_H_S, PIX_B_5, PIX_B_4, PIX_B_3, PIX_B_2 },
+	{ PIX_C_E, PIX_B_7, PIX_B_6, PIX_G_7, PIX_G_6, PIX_R_7, PIX_R_6 }
+};
+
+/*
+ * Clocks and PHY related functions
+ */
+static int lvds_pll_enable(struct stm_lvds *lvds, struct lvds_phy_info *phy)
+{
+	struct drm_device *drm = lvds->lvds_bridge.dev;
+	u32 lvds_gcr;
+	int val, ret;
+
+	/*
+	 * PLL lock timing control for the monitor unmask after startup (pll_en)
+	 * Adjusted value so that the masking window is opened at start-up
+	 */
+	lvds_write(lvds, phy->base + phy->ofs.MPLCR, (0x200 - 0x160) << 16);
+
+	/* Enable bias */
+	lvds_write(lvds, phy->base + phy->ofs.BCR2, PHY_BCR2_BIAS_EN);
+
+	/* Enable DP, LS, BIT clock output */
+	lvds_gcr = PHY_GCR_DP_CLK_OUT | PHY_GCR_LS_CLK_OUT | PHY_GCR_BIT_CLK_OUT;
+	lvds_set(lvds, phy->base + phy->ofs.GCR, lvds_gcr);
+
+	/* Power up all output dividers */
+	lvds_set(lvds, phy->base + phy->ofs.PLLTESTCR, PHY_PLLTESTCR_EN);
+	lvds_set(lvds, phy->base + phy->ofs.PLLCR1, PHY_PLLCR1_DIV_EN);
+
+	/* Set PHY in serial transmission mode */
+	lvds_set(lvds, phy->base + phy->ofs.SCR, PHY_SCR_TX_EN);
+
+	/* Enable the LVDS PLL & wait for its lock */
+	lvds_set(lvds, phy->base + phy->ofs.PLLCR1, PHY_PLLCR1_PLL_EN);
+	ret = readl_poll_timeout_atomic(lvds->base + phy->base + phy->ofs.PLLSR,
+					val, val & PHY_PLLSR_PLL_LOCK,
+					SLEEP_US, TIMEOUT_US);
+	if (ret)
+		drm_err(drm, "!TIMEOUT! waiting PLL, let's continue\n");
+
+	/* WCLKCR_SECND_CLKPIX_SEL is for dual link */
+	lvds_write(lvds, LVDS_WCLKCR, WCLKCR_SECND_CLKPIX_SEL);
+
+	lvds_set(lvds, phy->ofs.PLLTESTCR, PHY_PLLTESTCR_CLK_EN);
+
+	return ret;
+}
+
+static int pll_get_clkout_khz(int clkin_khz, int bdiv, int mdiv, int ndiv)
+{
+	int divisor = ndiv * bdiv;
+
+	/* Prevents from division by 0 */
+	if (!divisor)
+		return 0;
+
+	return clkin_khz * mdiv / divisor;
+}
+
+#define TDIV	70
+#define NDIV_MIN	2
+#define NDIV_MAX	6
+#define BDIV_MIN	2
+#define BDIV_MAX	6
+#define MDIV_MIN	1
+#define MDIV_MAX	1023
+
+static int lvds_pll_get_params(struct stm_lvds *lvds,
+			       unsigned int clkin_khz, unsigned int clkout_khz,
+			       unsigned int *bdiv, unsigned int *mdiv, unsigned int *ndiv)
+{
+	int delta, best_delta; /* all in khz */
+	int i, o, n;
+
+	/* Early checks preventing division by 0 & odd results */
+	if (clkin_khz <= 0 || clkout_khz <= 0)
+		return -EINVAL;
+
+	best_delta = 1000000; /* big started value (1000000khz) */
+
+	for (i = NDIV_MIN; i <= NDIV_MAX; i++) {
+		for (o = BDIV_MIN; o <= BDIV_MAX; o++) {
+			n = DIV_ROUND_CLOSEST(i * o * clkout_khz, clkin_khz);
+			/* Check ndiv according to vco range */
+			if (n < MDIV_MIN || n > MDIV_MAX)
+				continue;
+			/* Check if new delta is better & saves parameters */
+			delta = pll_get_clkout_khz(clkin_khz, i, n, o) - clkout_khz;
+			if (delta < 0)
+				delta = -delta;
+			if (delta < best_delta) {
+				*ndiv = i;
+				*mdiv = n;
+				*bdiv = o;
+				best_delta = delta;
+			}
+			/* fast return in case of "perfect result" */
+			if (!delta)
+				return 0;
+		}
+	}
+
+	return 0;
+}
+
+static void lvds_pll_config(struct stm_lvds *lvds, struct lvds_phy_info *phy)
+{
+	unsigned int pll_in_khz, bdiv = 0, mdiv = 0, ndiv = 0;
+	struct clk_hw *hwclk;
+	int multiplier;
+
+	/*
+	 * The LVDS PHY includes a low power low jitter high performance and
+	 * highly configuration Phase Locked Loop supporting integer and
+	 * fractional multiplication ratios and Spread Spectrum Clocking.  In
+	 * integer mode, the only software supported feature for now, the PLL is
+	 * made of a pre-divider NDIV, a feedback multiplier MDIV, followed by
+	 * several post-dividers, each one with a specific application.
+	 *
+	 *          ,------.         ,-----.     ,-----.
+	 * Fref --> | NDIV | -Fpdf-> | PFD | --> | VCO | --------> Fvco
+	 *          `------'     ,-> |     |     `-----'  |
+	 *                       |   `-----'              |
+	 *                       |         ,------.       |
+	 *                       `-------- | MDIV | <-----'
+	 *                                 `------'
+	 *
+	 * From the output of the VCO, the clock can be optionally extracted on
+	 * the RCC clock observer, with a divider TDIV, for testing purpose, or
+	 * is passed through a programmable post-divider BDIV.  Finally, the
+	 * frequency can be divided further with two fixed dividers.
+	 *
+	 *                            ,--------.
+	 *                    ,-----> | DP div | ----------------> Fdp
+	 *          ,------.  |       `--------'
+	 * Fvco --> | BDIV | ------------------------------------> Fbit
+	 *      |   `------'    ,------.   |
+	 *      `-------------> | TDIV | --.---------------------> ClkObs
+	 *                      '------'   |    ,--------.
+	 *                                 `--> | LS div | ------> Fls
+	 *                                      '--------'
+	 *
+	 * The LS and DP clock dividers operate at a fixed ratio of 7 and 3.5
+	 * respectively with regards to fbit. LS divider converts the bit clock
+	 * to a pixel clock per lane per clock sample (Fls).  This is useful
+	 * when used to generate a dot clock for the display unit RGB output,
+	 * and DP divider is.
+	 */
+
+	hwclk = __clk_get_hw(lvds->pllref_clk);
+	if (!hwclk)
+		return;
+
+	pll_in_khz = clk_hw_get_rate(hwclk) / 1000;
+
+	if (lvds_is_dual_link(lvds->link_type))
+		multiplier = 2;
+	else
+		multiplier = 1;
+
+	lvds_pll_get_params(lvds, pll_in_khz,
+			    lvds->pixel_clock_rate * 7 / 1000 / multiplier,
+			    &bdiv, &mdiv, &ndiv);
+
+	/* Set BDIV, MDIV and NDIV */
+	lvds_write(lvds, phy->base + phy->ofs.PLLCR2, ndiv << 16);
+	lvds_set(lvds, phy->base + phy->ofs.PLLCR2, bdiv);
+	lvds_write(lvds, phy->base + phy->ofs.PLLSDCR1, mdiv);
+
+	/* Hardcode TDIV as dynamic values are not yet implemented */
+	lvds_write(lvds, phy->base + phy->ofs.PLLTESTCR, TDIV << 16);
+
+	/*
+	 * For now, PLL just needs to be in integer mode
+	 * Fractional and spread spectrum clocking are not yet implemented
+	 *
+	 * PLL integer mode:
+	 *	- PMRY_PLL_TWG_STEP = PMRY_PLL_SD_INT_RATIO
+	 *	- EN_TWG = 0
+	 *	- EN_SD = 0
+	 *	- DOWN_SPREAD = 0
+	 *
+	 * PLL fractional mode:
+	 *	- EN_TWG = 0
+	 *	- EN_SD = 1
+	 *	- DOWN_SPREAD = 0
+	 *
+	 * Spread Spectrum Clocking
+	 *	- EN_TWG = 1
+	 *	- EN_SD = 1
+	 */
+
+	/* Disable TWG and SD */
+	lvds_clear(lvds, phy->base + phy->ofs.PLLCR1, PHY_PLLCR1_EN_TWG | PHY_PLLCR1_EN_SD);
+
+	/* Power up bias and PLL dividers */
+	lvds_set(lvds, phy->base + phy->ofs.DCR, PHY_DCR_POWER_OK);
+	lvds_set(lvds, phy->base + phy->ofs.CMCR1, PHY_CMCR_CM_EN_DL);
+	lvds_set(lvds, phy->base + phy->ofs.CMCR2, PHY_CMCR_CM_EN_DL4);
+
+	/* Set up voltage mode */
+	lvds_set(lvds, phy->base + phy->ofs.PLLCPCR, 0x1);
+	lvds_set(lvds, phy->base + phy->ofs.BCR3, PHY_BCR3_VM_EN_DL);
+	lvds_set(lvds, phy->base + phy->ofs.BCR1, PHY_BCR1_EN_BIAS_DL);
+	/* Enable digital datalanes */
+	lvds_set(lvds, phy->base + phy->ofs.CFGCR, PHY_CFGCR_EN_DIG_DL);
+}
+
+static int lvds_pixel_clk_enable(struct clk_hw *hw)
+{
+	struct stm_lvds *lvds = container_of(hw, struct stm_lvds, lvds_ck_px);
+	struct drm_device *drm = lvds->lvds_bridge.dev;
+	struct lvds_phy_info *phy;
+	int ret;
+
+	ret = clk_prepare_enable(lvds->pclk);
+	if (ret) {
+		drm_err(drm, "Failed to enable lvds peripheral clk\n");
+		return ret;
+	}
+
+	ret = clk_prepare_enable(lvds->pllref_clk);
+	if (ret) {
+		drm_err(drm, "Failed to enable lvds reference clk\n");
+		clk_disable_unprepare(lvds->pclk);
+		return ret;
+	}
+
+	/* In case we are operating in dual link the second PHY is set before the primary PHY. */
+	if (lvds->secondary) {
+		phy = lvds->secondary;
+
+		/* Release LVDS PHY from reset mode */
+		lvds_set(lvds, phy->base + phy->ofs.GCR, PHY_GCR_DIV_RSTN | PHY_GCR_RSTZ);
+		lvds_pll_config(lvds, phy);
+
+		ret = lvds_pll_enable(lvds, phy);
+		if (ret) {
+			drm_err(drm, "Failed to enable secondary PHY PLL: %d\n", ret);
+			return ret;
+		}
+	}
+
+	if (lvds->primary) {
+		phy = lvds->primary;
+
+		/* Release LVDS PHY from reset mode */
+		lvds_set(lvds, phy->base + phy->ofs.GCR, PHY_GCR_DIV_RSTN | PHY_GCR_RSTZ);
+		lvds_pll_config(lvds, phy);
+
+		ret = lvds_pll_enable(lvds, phy);
+		if (ret) {
+			drm_err(drm, "Failed to enable primary PHY PLL: %d\n", ret);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static void lvds_pixel_clk_disable(struct clk_hw *hw)
+{
+	struct stm_lvds *lvds = container_of(hw, struct stm_lvds, lvds_ck_px);
+
+	/*
+	 * For each PHY:
+	 * Disable DP, LS, BIT clock outputs
+	 * Shutdown the PLL
+	 * Assert LVDS PHY in reset mode
+	 */
+
+	if (lvds->primary) {
+		lvds_clear(lvds, lvds->primary->base + lvds->primary->ofs.GCR,
+			   (PHY_GCR_DP_CLK_OUT | PHY_GCR_LS_CLK_OUT | PHY_GCR_BIT_CLK_OUT));
+		lvds_clear(lvds, lvds->primary->base + lvds->primary->ofs.PLLCR1,
+			   PHY_PLLCR1_PLL_EN);
+		lvds_clear(lvds, lvds->primary->base + lvds->primary->ofs.GCR,
+			   PHY_GCR_DIV_RSTN | PHY_GCR_RSTZ);
+	}
+
+	if (lvds->secondary) {
+		lvds_clear(lvds, lvds->secondary->base + lvds->secondary->ofs.GCR,
+			   (PHY_GCR_DP_CLK_OUT | PHY_GCR_LS_CLK_OUT | PHY_GCR_BIT_CLK_OUT));
+		lvds_clear(lvds, lvds->secondary->base + lvds->secondary->ofs.PLLCR1,
+			   PHY_PLLCR1_PLL_EN);
+		lvds_clear(lvds, lvds->secondary->base + lvds->secondary->ofs.GCR,
+			   PHY_GCR_DIV_RSTN | PHY_GCR_RSTZ);
+	}
+
+	clk_disable_unprepare(lvds->pllref_clk);
+	clk_disable_unprepare(lvds->pclk);
+}
+
+static unsigned long lvds_pixel_clk_recalc_rate(struct clk_hw *hw,
+						unsigned long parent_rate)
+{
+	struct stm_lvds *lvds = container_of(hw, struct stm_lvds, lvds_ck_px);
+	struct drm_device *drm = lvds->lvds_bridge.dev;
+	unsigned int pll_in_khz, bdiv, mdiv, ndiv;
+	int ret, multiplier, pll_out_khz;
+	u32 val;
+
+	ret = clk_prepare_enable(lvds->pclk);
+	if (ret) {
+		drm_err(drm, "Failed to enable lvds peripheral clk\n");
+		return 0;
+	}
+
+	if (lvds_is_dual_link(lvds->link_type))
+		multiplier = 2;
+	else
+		multiplier = 1;
+
+	val = lvds_read(lvds, lvds->primary->base + lvds->primary->ofs.PLLCR2);
+	drm_dbg(drm, "val = %08x\n", val);
+
+	ndiv = (val & PHY_PLLCR2_NDIV) >> 16;
+	bdiv = (val & PHY_PLLCR2_BDIV) >> 0;
+
+	mdiv = (unsigned int)lvds_read(lvds,
+				       lvds->primary->base + lvds->primary->ofs.PLLSDCR1);
+
+	pll_in_khz = (unsigned int)(parent_rate / 1000);
+
+	/* Compute values if not yet accessible */
+	if (val == 0 || mdiv == 0) {
+		lvds_pll_get_params(lvds, pll_in_khz,
+				    lvds->pixel_clock_rate * 7 / 1000 / multiplier,
+				    &bdiv, &mdiv, &ndiv);
+	}
+
+	pll_out_khz = pll_get_clkout_khz(pll_in_khz, bdiv, mdiv, ndiv);
+	drm_dbg(drm, "ndiv %d , bdiv %d, mdiv %d, pll_out_khz %d\n",
+		ndiv, bdiv, mdiv, pll_out_khz);
+
+	/*
+	 * 1/7 because for each pixel in 1 lane there is 7 bits
+	 * We want pixclk, not bitclk
+	 */
+	lvds->pixel_clock_rate = pll_out_khz * 1000 * multiplier / 7;
+
+	clk_disable_unprepare(lvds->pclk);
+
+	return (unsigned long)lvds->pixel_clock_rate;
+}
+
+static long lvds_pixel_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+				      unsigned long *parent_rate)
+{
+	struct stm_lvds *lvds = container_of(hw, struct stm_lvds, lvds_ck_px);
+	unsigned int pll_in_khz, bdiv = 0, mdiv = 0, ndiv = 0;
+	const struct drm_connector *connector;
+	const struct drm_display_mode *mode;
+	int multiplier;
+
+	connector = &lvds->connector;
+	if (!connector)
+		return -EINVAL;
+
+	if (list_empty(&connector->modes)) {
+		drm_dbg(connector->dev, "connector: empty modes list\n");
+		return -EINVAL;
+	}
+
+	mode = list_first_entry(&connector->modes,
+				struct drm_display_mode, head);
+
+	pll_in_khz = (unsigned int)(*parent_rate / 1000);
+
+	if (lvds_is_dual_link(lvds->link_type))
+		multiplier = 2;
+	else
+		multiplier = 1;
+
+	lvds_pll_get_params(lvds, pll_in_khz, mode->clock * 7 / multiplier, &bdiv, &mdiv, &ndiv);
+
+	/*
+	 * 1/7 because for each pixel in 1 lane there is 7 bits
+	 * We want pixclk, not bitclk
+	 */
+	lvds->pixel_clock_rate = (unsigned long)pll_get_clkout_khz(pll_in_khz, bdiv, mdiv, ndiv)
+					 * 1000 * multiplier / 7;
+
+	return lvds->pixel_clock_rate;
+}
+
+static const struct clk_ops lvds_pixel_clk_ops = {
+	.enable = lvds_pixel_clk_enable,
+	.disable = lvds_pixel_clk_disable,
+	.recalc_rate = lvds_pixel_clk_recalc_rate,
+	.round_rate = lvds_pixel_clk_round_rate,
+};
+
+static const struct clk_init_data clk_data = {
+	.name = "clk_pix_lvds",
+	.ops = &lvds_pixel_clk_ops,
+	.parent_names = (const char * []) {"ck_ker_lvdsphy"},
+	.num_parents = 1,
+	.flags = CLK_IGNORE_UNUSED,
+};
+
+static void lvds_pixel_clk_unregister(void *data)
+{
+	struct stm_lvds *lvds = data;
+
+	of_clk_del_provider(lvds->dev->of_node);
+	clk_hw_unregister(&lvds->lvds_ck_px);
+}
+
+static int lvds_pixel_clk_register(struct stm_lvds *lvds)
+{
+	struct device_node *node = lvds->dev->of_node;
+	int ret;
+
+	lvds->lvds_ck_px.init = &clk_data;
+
+	/* set the rate by default at 148500000 */
+	lvds->pixel_clock_rate = 148500000;
+
+	ret = clk_hw_register(lvds->dev, &lvds->lvds_ck_px);
+	if (ret)
+		return ret;
+
+	ret = of_clk_add_hw_provider(node, of_clk_hw_simple_get,
+				     &lvds->lvds_ck_px);
+	if (ret)
+		clk_hw_unregister(&lvds->lvds_ck_px);
+
+	return ret;
+}
+
+/*
+ * Host configuration related
+ */
+static void lvds_config_data_mapping(struct stm_lvds *lvds)
+{
+	struct drm_device *drm = lvds->lvds_bridge.dev;
+	const struct drm_display_info *info;
+	enum lvds_pixel (*bitmap)[7];
+	u32 lvds_dmlcr, lvds_dmmcr;
+	int i;
+
+	info = &(&lvds->connector)->display_info;
+	if (!info->num_bus_formats || !info->bus_formats) {
+		drm_warn(drm, "No LVDS bus format reported\n");
+		return;
+	}
+
+	switch (info->bus_formats[0]) {
+	case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG: /* VESA-RGB666 */
+		drm_warn(drm, "Pixel format with data mapping not yet supported.\n");
+		return;
+	case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG: /* VESA-RGB888 */
+		bitmap = lvds_bitmap_vesa_rgb888;
+		break;
+	case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA: /* JEIDA-RGB888 */
+		bitmap = lvds_bitmap_jeida_rgb888;
+		break;
+	default:
+		drm_warn(drm, "Unsupported LVDS bus format 0x%04x\n", info->bus_formats[0]);
+		return;
+	}
+
+	/* Set bitmap for each lane */
+	for (i = 0; i < 5; i++) {
+		lvds_dmlcr = ((bitmap[i][0])
+			      + (bitmap[i][1] << 5)
+			      + (bitmap[i][2] << 10)
+			      + (bitmap[i][3] << 15));
+		lvds_dmmcr = ((bitmap[i][4])
+			      + (bitmap[i][5] << 5)
+			      + (bitmap[i][6] << 10));
+
+		lvds_write(lvds, LVDS_DMLCR(i), lvds_dmlcr);
+		lvds_write(lvds, LVDS_DMMCR(i), lvds_dmmcr);
+	}
+}
+
+static void lvds_config_mode(struct stm_lvds *lvds)
+{
+	u32 bus_flags, lvds_cr = 0, lvds_cdl1cr = 0, lvds_cdl2cr = 0;
+	const struct drm_display_mode *mode;
+	const struct drm_connector *connector;
+
+	connector = &lvds->connector;
+	if (!connector)
+		return;
+
+	if (list_empty(&connector->modes)) {
+		drm_dbg(connector->dev, "connector: empty modes list\n");
+		return;
+	}
+
+	bus_flags = connector->display_info.bus_flags;
+	mode = list_first_entry(&connector->modes,
+				struct drm_display_mode, head);
+
+	lvds_clear(lvds, LVDS_CR, CR_LKMOD);
+	lvds_clear(lvds, LVDS_CDL1CR, CDLCRx_DISTR0 | CDLCRx_DISTR1 | CDLCRx_DISTR2 |
+				      CDLCRx_DISTR3 | CDLCRx_DISTR4);
+	lvds_clear(lvds, LVDS_CDL2CR, CDLCRx_DISTR0 | CDLCRx_DISTR1 | CDLCRx_DISTR2 |
+				      CDLCRx_DISTR3 | CDLCRx_DISTR4);
+
+	/* Set channel distribution */
+	if (lvds->primary)
+		lvds_cdl1cr = CDL1CR_DEFAULT;
+
+	if (lvds->secondary) {
+		lvds_cr |= CR_LKMOD;
+		lvds_cdl2cr = CDL2CR_DEFAULT;
+	}
+
+	/* Set signal polarity */
+	if (bus_flags & DRM_BUS_FLAG_DE_LOW)
+		lvds_cr |= CR_DEPOL;
+
+	if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+		lvds_cr |= CR_HSPOL;
+
+	if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+		lvds_cr |= CR_VSPOL;
+
+	switch (lvds->link_type) {
+	case LVDS_DUAL_LINK_EVEN_ODD_PIXELS: /* LKPHA = 0 */
+		lvds_cr &= ~CR_LKPHA;
+		break;
+	case LVDS_DUAL_LINK_ODD_EVEN_PIXELS: /* LKPHA = 1 */
+		lvds_cr |= CR_LKPHA;
+		break;
+	default:
+		drm_notice(lvds->lvds_bridge.dev, "No phase precised, setting default\n");
+		lvds_cr &= ~CR_LKPHA;
+		break;
+	}
+
+	/* Write config to registers */
+	lvds_set(lvds, LVDS_CR, lvds_cr);
+	lvds_write(lvds, LVDS_CDL1CR, lvds_cdl1cr);
+	lvds_write(lvds, LVDS_CDL2CR, lvds_cdl2cr);
+}
+
+static int lvds_connector_get_modes(struct drm_connector *connector)
+{
+	struct stm_lvds *lvds = connector_to_stm_lvds(connector);
+
+	return drm_panel_get_modes(lvds->panel, connector);
+}
+
+static int lvds_connector_atomic_check(struct drm_connector *connector,
+				       struct drm_atomic_state *state)
+{
+	const struct drm_display_mode *panel_mode;
+	struct drm_connector_state *conn_state;
+	struct drm_crtc_state *crtc_state;
+
+	conn_state = drm_atomic_get_new_connector_state(state, connector);
+	if (!conn_state)
+		return -EINVAL;
+
+	if (list_empty(&connector->modes)) {
+		drm_dbg(connector->dev, "connector: empty modes list\n");
+		return -EINVAL;
+	}
+
+	if (!conn_state->crtc)
+		return -EINVAL;
+
+	panel_mode = list_first_entry(&connector->modes,
+				      struct drm_display_mode, head);
+
+	/* We're not allowed to modify the resolution. */
+	crtc_state = drm_atomic_get_crtc_state(state, conn_state->crtc);
+	if (IS_ERR(crtc_state))
+		return PTR_ERR(crtc_state);
+
+	if (crtc_state->mode.hdisplay != panel_mode->hdisplay ||
+	    crtc_state->mode.vdisplay != panel_mode->vdisplay)
+		return -EINVAL;
+
+	/* The flat panel mode is fixed, just copy it to the adjusted mode. */
+	drm_mode_copy(&crtc_state->adjusted_mode, panel_mode);
+
+	return 0;
+}
+
+static const struct drm_connector_helper_funcs lvds_conn_helper_funcs = {
+	.get_modes = lvds_connector_get_modes,
+	.atomic_check = lvds_connector_atomic_check,
+};
+
+static const struct drm_connector_funcs lvds_conn_funcs = {
+	.reset = drm_atomic_helper_connector_reset,
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.destroy = drm_connector_cleanup,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int lvds_attach(struct drm_bridge *bridge,
+		       enum drm_bridge_attach_flags flags)
+{
+	struct stm_lvds *lvds = bridge_to_stm_lvds(bridge);
+	struct drm_connector *connector = &lvds->connector;
+	struct drm_encoder *encoder = bridge->encoder;
+	int ret;
+
+	if (!bridge->encoder) {
+		drm_err(bridge->dev, "Parent encoder object not found\n");
+		return -ENODEV;
+	}
+
+	/* Set the encoder type as caller does not know it */
+	bridge->encoder->encoder_type = DRM_MODE_ENCODER_LVDS;
+
+	/* No cloning support */
+	bridge->encoder->possible_clones = 0;
+
+	/* If we have a next bridge just attach it. */
+	if (lvds->next_bridge)
+		return drm_bridge_attach(bridge->encoder, lvds->next_bridge,
+					 bridge, flags);
+
+	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+		drm_err(bridge->dev, "Fix bridge driver to make connector optional!");
+		return -EINVAL;
+	}
+
+	/* Otherwise if we have a panel, create a connector. */
+	if (!lvds->panel)
+		return 0;
+
+	ret = drm_connector_init(bridge->dev, connector,
+				 &lvds_conn_funcs, DRM_MODE_CONNECTOR_LVDS);
+	if (ret < 0)
+		return ret;
+
+	drm_connector_helper_add(connector, &lvds_conn_helper_funcs);
+
+	ret = drm_connector_attach_encoder(connector, encoder);
+
+	return ret;
+}
+
+static void lvds_atomic_enable(struct drm_bridge *bridge,
+			       struct drm_bridge_state *old_bridge_state)
+{
+	struct drm_atomic_state *state = old_bridge_state->base.state;
+	struct stm_lvds *lvds = bridge_to_stm_lvds(bridge);
+	struct drm_connector_state *conn_state;
+	struct drm_connector *connector;
+	int ret;
+
+	ret = clk_prepare_enable(lvds->pclk);
+	if (ret) {
+		drm_err(bridge->dev, "Failed to enable lvds peripheral clk\n");
+		return;
+	}
+
+	connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
+	if (!connector)
+		return;
+
+	conn_state = drm_atomic_get_new_connector_state(state, connector);
+	if (!conn_state)
+		return;
+
+	lvds_config_mode(lvds);
+
+	/* Set Data Mapping */
+	lvds_config_data_mapping(lvds);
+
+	/* Turn the output on. */
+	lvds_set(lvds, LVDS_CR, CR_LVDSEN);
+
+	if (lvds->panel) {
+		drm_panel_prepare(lvds->panel);
+		drm_panel_enable(lvds->panel);
+	}
+}
+
+static void lvds_atomic_disable(struct drm_bridge *bridge,
+				struct drm_bridge_state *old_bridge_state)
+{
+	struct stm_lvds *lvds = bridge_to_stm_lvds(bridge);
+
+	if (lvds->panel) {
+		drm_panel_disable(lvds->panel);
+		drm_panel_unprepare(lvds->panel);
+	}
+
+	/* Disable LVDS module */
+	lvds_clear(lvds, LVDS_CR, CR_LVDSEN);
+
+	clk_disable_unprepare(lvds->pclk);
+}
+
+static const struct drm_bridge_funcs lvds_bridge_funcs = {
+	.attach = lvds_attach,
+	.atomic_enable = lvds_atomic_enable,
+	.atomic_disable = lvds_atomic_disable,
+	.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+	.atomic_reset = drm_atomic_helper_bridge_reset,
+};
+
+static int lvds_probe(struct platform_device *pdev)
+{
+	struct device_node *port1, *port2, *remote;
+	struct device *dev = &pdev->dev;
+	struct reset_control *rstc;
+	struct stm_lvds *lvds;
+	int ret, dual_link;
+
+	dev_dbg(dev, "Probing LVDS driver...\n");
+
+	lvds = devm_kzalloc(dev, sizeof(*lvds), GFP_KERNEL);
+	if (!lvds)
+		return -ENOMEM;
+
+	lvds->dev = dev;
+
+	ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
+					  &lvds->panel, &lvds->next_bridge);
+	if (ret) {
+		dev_err_probe(dev, ret, "Panel not found\n");
+		return ret;
+	}
+
+	lvds->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(lvds->base)) {
+		ret = PTR_ERR(lvds->base);
+		dev_err(dev, "Unable to get regs %d\n", ret);
+		return ret;
+	}
+
+	lvds->pclk = devm_clk_get(dev, "pclk");
+	if (IS_ERR(lvds->pclk)) {
+		ret = PTR_ERR(lvds->pclk);
+		dev_err(dev, "Unable to get peripheral clock: %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(lvds->pclk);
+	if (ret) {
+		dev_err(dev, "%s: Failed to enable peripheral clk\n", __func__);
+		return ret;
+	}
+
+	rstc = devm_reset_control_get_exclusive(dev, NULL);
+
+	if (IS_ERR(rstc)) {
+		ret = PTR_ERR(rstc);
+		goto err_lvds_probe;
+	}
+
+	reset_control_assert(rstc);
+	usleep_range(10, 20);
+	reset_control_deassert(rstc);
+
+	port1 = of_graph_get_port_by_id(dev->of_node, 1);
+	port2 = of_graph_get_port_by_id(dev->of_node, 2);
+	dual_link = drm_of_lvds_get_dual_link_pixel_order(port1, port2);
+
+	switch (dual_link) {
+	case DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS:
+		lvds->link_type = LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+		lvds->primary = &lvds_phy_16ff_primary;
+		lvds->secondary = &lvds_phy_16ff_secondary;
+		break;
+	case DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS:
+		lvds->link_type = LVDS_DUAL_LINK_EVEN_ODD_PIXELS;
+		lvds->primary = &lvds_phy_16ff_primary;
+		lvds->secondary = &lvds_phy_16ff_secondary;
+		break;
+	case -EINVAL:
+		/*
+		 * drm_of_lvds_get_dual_pixel_order returns 4 possible values.
+		 * In the case where the returned value is an error, it can be
+		 * either ENODEV or EINVAL. Seeing the structure of this
+		 * function, EINVAL means that either port1 or port2 is not
+		 * present in the device tree.
+		 * In that case, the lvds panel can be a single link panel, or
+		 * there is a semantical error in the device tree code.
+		 */
+		remote = of_get_next_available_child(port1, NULL);
+		if (remote) {
+			if (of_graph_get_remote_endpoint(remote)) {
+				lvds->link_type = LVDS_SINGLE_LINK_PRIMARY;
+				lvds->primary = &lvds_phy_16ff_primary;
+				lvds->secondary = NULL;
+			} else {
+				ret = -EINVAL;
+			}
+
+			of_node_put(remote);
+		}
+
+		remote = of_get_next_available_child(port2, NULL);
+		if (remote) {
+			if (of_graph_get_remote_endpoint(remote)) {
+				lvds->link_type = LVDS_SINGLE_LINK_SECONDARY;
+				lvds->primary = NULL;
+				lvds->secondary = &lvds_phy_16ff_secondary;
+			} else {
+				ret = (ret == -EINVAL) ? -EINVAL : 0;
+			}
+
+			of_node_put(remote);
+		}
+		break;
+	default:
+		ret = -EINVAL;
+		goto err_lvds_probe;
+	}
+	of_node_put(port1);
+	of_node_put(port2);
+
+	lvds->pllref_clk = devm_clk_get(dev, "ref");
+	if (IS_ERR(lvds->pllref_clk)) {
+		ret = PTR_ERR(lvds->pllref_clk);
+		dev_err(dev, "Unable to get reference clock: %d\n", ret);
+		goto err_lvds_probe;
+	}
+
+	ret = lvds_pixel_clk_register(lvds);
+	if (ret) {
+		dev_err(dev, "Failed to register LVDS pixel clock: %d\n", ret);
+		goto err_lvds_probe;
+	}
+
+	lvds->lvds_bridge.funcs = &lvds_bridge_funcs;
+	lvds->lvds_bridge.of_node = dev->of_node;
+	lvds->hw_version = lvds_read(lvds, LVDS_VERR);
+
+	dev_info(dev, "version 0x%02x initialized\n", lvds->hw_version);
+
+	drm_bridge_add(&lvds->lvds_bridge);
+
+	platform_set_drvdata(pdev, lvds);
+
+	clk_disable_unprepare(lvds->pclk);
+
+	return 0;
+
+err_lvds_probe:
+	clk_disable_unprepare(lvds->pclk);
+
+	return ret;
+}
+
+static int lvds_remove(struct platform_device *pdev)
+{
+	struct stm_lvds *lvds = platform_get_drvdata(pdev);
+
+	lvds_pixel_clk_unregister(lvds);
+
+	drm_bridge_remove(&lvds->lvds_bridge);
+
+	return 0;
+}
+
+static const struct of_device_id lvds_dt_ids[] = {
+	{
+		.compatible = "st,stm32-lvds",
+		.data = NULL
+	},
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, lvds_dt_ids);
+
+static struct platform_driver lvds_platform_driver = {
+	.probe = lvds_probe,
+	.remove = lvds_remove,
+	.driver = {
+		.name = "stm32-display-lvds",
+		.owner = THIS_MODULE,
+		.of_match_table = lvds_dt_ids,
+	},
+};
+
+module_platform_driver(lvds_platform_driver);
+
+MODULE_AUTHOR("Rapha??l Gallais-Pou <raphael.gallais-pou at foss.st.com>");
+MODULE_AUTHOR("Philippe Cornu <philippe.cornu at foss.st.com>");
+MODULE_AUTHOR("Yannick Fertre <yannick.fertre at foss.st.com>");
+MODULE_DESCRIPTION("STMicroelectronics LVDS Display Interface Transmitter DRM driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:43:35 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:43:35 +0100
Subject: [PATCH RESEND v1 4/8] drm/stm: ltdc: implement bus clock
In-Reply-To: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221124339.420119-5-raphael.gallais-pou@foss.st.com>

From: Yannick Fertre <yannick.fertre at foss.st.com>

The latest hardware version of the LTDC presents the addition of a bus
clock, which contains the global configuration registers and the interrupt
register.

Signed-off-by: Yannick Fertre <yannick.fertre at foss.st.com>
---
 drivers/gpu/drm/stm/ltdc.c | 8 ++++++++
 drivers/gpu/drm/stm/ltdc.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 5576fdae4962..67064f47a4cb 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1896,6 +1896,8 @@ void ltdc_suspend(struct drm_device *ddev)
 
 	DRM_DEBUG_DRIVER("\n");
 	clk_disable_unprepare(ldev->pixel_clk);
+	if (ldev->bus_clk)
+		clk_disable_unprepare(ldev->bus_clk);
 }
 
 int ltdc_resume(struct drm_device *ddev)
@@ -1910,6 +1912,12 @@ int ltdc_resume(struct drm_device *ddev)
 		DRM_ERROR("failed to enable pixel clock (%d)\n", ret);
 		return ret;
 	}
+	if (ldev->bus_clk) {
+		if (clk_prepare_enable(ldev->bus_clk)) {
+			DRM_ERROR("Unable to prepare bus clock\n");
+			return -ENODEV;
+		}
+	}
 
 	return 0;
 }
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 9d488043ffdb..155d8e4a7c6b 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
 	void __iomem *regs;
 	struct regmap *regmap;
 	struct clk *pixel_clk;	/* lcd pixel clock */
+	struct clk *bus_clk;	/* bus clock */
 	struct mutex err_lock;	/* protecting error_status */
 	struct ltdc_caps caps;
 	u32 irq_status;
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:43:38 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:43:38 +0100
Subject: [PATCH RESEND v1 7/8] arm64: dts: st: add lvds support on stm32mp253
In-Reply-To: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221124339.420119-8-raphael.gallais-pou@foss.st.com>

This patch adds LVDS support on stm32mp253.  The LVDS is used on
STM32MP2 as a display interface.  LVDS PLL clock is binded to the LTDC
input clock.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp253.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp253.dtsi b/arch/arm64/boot/dts/st/stm32mp253.dtsi
index af48e82efe8a..bcc605e502de 100644
--- a/arch/arm64/boot/dts/st/stm32mp253.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp253.dtsi
@@ -21,3 +21,20 @@ arm-pmu {
 		interrupt-affinity = <&cpu0>, <&cpu1>;
 	};
 };
+
+&ltdc {
+	clocks = <&rcc CK_BUS_LTDC>, <&rcc CK_KER_LTDC>, <&lvds 0>;
+	clock-names = "bus", "lcd", "lvds";
+};
+
+&rifsc {
+	lvds: lvds at 48060000 {
+		#clock-cells = <0>;
+		compatible = "st,stm32-lvds";
+		reg = <0x48060000 0x2000>;
+		clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
+		clock-names = "pclk", "ref";
+		resets = <&rcc LVDS_R>;
+		status = "disabled";
+	};
+};
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:43:36 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:43:36 +0100
Subject: [PATCH RESEND v1 5/8] drm/stm: ltdc: add lvds pixel clock
In-Reply-To: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221124339.420119-6-raphael.gallais-pou@foss.st.com>

The STM32MP25x display subsystem presents a mux which feeds the loopback
pixel clock of the current bridge in use into the LTDC. This mux is only
accessible through sysconfig registers which is not yet available in the
STM32MP25x common clock framework.

While waiting for a complete update of the clock framework, this would
allow to use the LVDS.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at st.com>
Signed-off-by: Yannick Fertre <yannick.fertre at foss.st.com>
---
 drivers/gpu/drm/stm/ltdc.c | 18 ++++++++++++++++++
 drivers/gpu/drm/stm/ltdc.h |  1 +
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 67064f47a4cb..1cf9f16e56cc 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -838,6 +838,12 @@ ltdc_crtc_mode_valid(struct drm_crtc *crtc,
 	int target_max = target + CLK_TOLERANCE_HZ;
 	int result;
 
+	if (ldev->lvds_clk) {
+		result = clk_round_rate(ldev->lvds_clk, target);
+		DRM_DEBUG_DRIVER("lvds pixclk rate target %d, available %d\n",
+				 target, result);
+	}
+
 	result = clk_round_rate(ldev->pixel_clk, target);
 
 	DRM_DEBUG_DRIVER("clk rate target %d, available %d\n", target, result);
@@ -1898,6 +1904,8 @@ void ltdc_suspend(struct drm_device *ddev)
 	clk_disable_unprepare(ldev->pixel_clk);
 	if (ldev->bus_clk)
 		clk_disable_unprepare(ldev->bus_clk);
+	if (ldev->lvds_clk)
+		clk_disable_unprepare(ldev->lvds_clk);
 }
 
 int ltdc_resume(struct drm_device *ddev)
@@ -1918,6 +1926,12 @@ int ltdc_resume(struct drm_device *ddev)
 			return -ENODEV;
 		}
 	}
+	if (ldev->lvds_clk) {
+		if (clk_prepare_enable(ldev->lvds_clk)) {
+			DRM_ERROR("Unable to prepare lvds clock\n");
+			return -ENODEV;
+		}
+	}
 
 	return 0;
 }
@@ -1989,6 +2003,10 @@ int ltdc_load(struct drm_device *ddev)
 		}
 	}
 
+	ldev->lvds_clk = devm_clk_get(dev, "lvds");
+	if (IS_ERR(ldev->lvds_clk))
+		ldev->lvds_clk = NULL;
+
 	rstc = devm_reset_control_get_exclusive(dev, NULL);
 
 	mutex_init(&ldev->err_lock);
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 155d8e4a7c6b..662650a0fae2 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
 	void __iomem *regs;
 	struct regmap *regmap;
 	struct clk *pixel_clk;	/* lcd pixel clock */
+	struct clk *lvds_clk;	/* lvds pixel clock */
 	struct clk *bus_clk;	/* bus clock */
 	struct mutex err_lock;	/* protecting error_status */
 	struct ltdc_caps caps;
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:43:37 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:43:37 +0100
Subject: [PATCH RESEND v1 6/8] arm64: dts: st: add ltdc support on stm32mp251
In-Reply-To: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221124339.420119-7-raphael.gallais-pou@foss.st.com>

The LCD-TFT Display Controller (LTDC) handles display composition,
scaling and rotation. It provides a parallel digital RGB flow to be used
by display interfaces.

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 93bc8a8908ce..064077e98dfd 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -212,6 +212,18 @@ i2c8: i2c at 46040000 {
 				status = "disabled";
 			};
 
+			ltdc: display-controller at 48010000 {
+				compatible = "st,stm32-ltdc";
+				reg = <0x48010000 0x400>;
+				st,syscon = <&syscfg>;
+				interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&rcc CK_BUS_LTDC>, <&rcc CK_KER_LTDC>;
+				clock-names = "bus", "lcd";
+				resets = <&rcc LTDC_R>;
+				status = "disabled";
+			};
+
 			sdmmc1: mmc at 48220000 {
 				compatible = "st,stm32mp25-sdmmc2", "arm,pl18x", "arm,primecell";
 				arm,primecell-periphid = <0x00353180>;
-- 
2.25.1



From raphael.gallais-pou at foss.st.com  Thu Dec 21 04:43:39 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Thu, 21 Dec 2023 13:43:39 +0100
Subject: [PATCH RESEND v1 8/8] arm64: dts: st: add display support on stm32mp257f-ev
In-Reply-To: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
Message-ID: <20231221124339.420119-9-raphael.gallais-pou@foss.st.com>

This patch enables the following IPs on stm32mp257f-ev :
  * LTDC
  * LVDS
  * WSVGA LVDS panel (1024x600)
  * Panel backlight
  * Ilitek touchescreen

Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 79 ++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 0ea8e69bfb3d..ca2da988d91c 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -29,6 +29,43 @@ memory at 80000000 {
 		reg = <0x0 0x80000000 0x1 0x0>;
 	};
 
+	panel_lvds: panel-lvds {
+		compatible = "edt,etml0700z9ndha", "panel-lvds";
+		enable-gpios = <&gpiog 15 GPIO_ACTIVE_HIGH>;
+		backlight = <&panel_lvds_backlight>;
+		status = "okay";
+
+		width-mm = <156>;
+		height-mm = <92>;
+		data-mapping = "vesa-24";
+
+		panel-timing {
+			clock-frequency = <54000000>;
+			hactive = <1024>;
+			vactive = <600>;
+			hfront-porch = <150>;
+			hback-porch = <150>;
+			hsync-len = <21>;
+			vfront-porch = <24>;
+			vback-porch = <24>;
+			vsync-len = <21>;
+		};
+
+		port {
+			lvds_panel_in: endpoint {
+				remote-endpoint = <&lvds_out0>;
+			};
+		};
+	};
+
+	panel_lvds_backlight: panel-lvds-backlight {
+		compatible = "gpio-backlight";
+		gpios = <&gpioi 5 GPIO_ACTIVE_HIGH>;
+		default-on;
+		default-brightness-level = <0>;
+		status = "okay";
+	};
+
 	reserved-memory {
 		#address-cells = <2>;
 		#size-cells = <2>;
@@ -63,6 +100,15 @@ &i2c2 {
 	i2c-scl-falling-time-ns = <13>;
 	clock-frequency = <400000>;
 	status = "okay";
+
+	ili2511: ili2511 at 41 {
+		compatible = "ilitek,ili251x";
+		reg = <0x41>;
+		interrupt-parent = <&gpioi>;
+		interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&gpiog 14 GPIO_ACTIVE_LOW>;
+		status = "okay";
+	};
 };
 
 &i2c8 {
@@ -75,6 +121,39 @@ &i2c8 {
 	status = "disabled";
 };
 
+&ltdc {
+	status = "okay";
+
+	port {
+		ltdc_ep0_out: endpoint {
+			remote-endpoint = <&lvds_in>;
+		};
+	};
+};
+
+&lvds {
+	status = "okay";
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port at 0 {
+			reg = <0>;
+			lvds_in: endpoint {
+				remote-endpoint = <&ltdc_ep0_out>;
+			};
+		};
+
+		port at 1 {
+			reg = <1>;
+			lvds_out0: endpoint {
+				remote-endpoint = <&lvds_panel_in>;
+			};
+		};
+	};
+};
+
 &sdmmc1 {
 	pinctrl-names = "default", "opendrain", "sleep";
 	pinctrl-0 = <&sdmmc1_b4_pins_a>;
-- 
2.25.1



From andre.przywara at arm.com  Thu Dec 21 04:49:57 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 21 Dec 2023 12:49:57 +0000
Subject: [RFC PATCH v2 2/3] cpufreq: sun50i: Add support for D1's speed
 bin decoding
In-Reply-To: <20231221101013.67204-3-fusibrandon13@gmail.com>
References: <20231221101013.67204-1-fusibrandon13@gmail.com>
	<20231221101013.67204-3-fusibrandon13@gmail.com>
Message-ID: <20231221124957.27fa9922@donnerap.manchester.arm.com>

On Thu, 21 Dec 2023 11:10:12 +0100
Brandon Cheo Fusi <fusibrandon13 at gmail.com> wrote:

Hi Brandon,

thanks for the quick turnaround, and for splitting this code up, that
makes reasoning about this much easier!

> Adds support for decoding the efuse value read from D1 efuse speed
> bins, and factors out equivalent code for sun50i.
> 
> The algorithm is gotten from
> 
> https://github.com/Tina-Linux/linux-5.4/blob/master/drivers/cpufreq/sun50i-cpufreq-nvmem.c#L293-L338
> 
> and maps an efuse value to either 0 or 1, with 1 meaning stable at
> a lower supply voltage for the same clock frequency.
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 34 ++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> index fc509fc49..b1cb95308 100644
> --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> @@ -29,6 +29,33 @@ struct sunxi_cpufreq_data {
>  	u32 (*efuse_xlate)(u32 *speedbin, size_t len);
>  };
>  
> +static u32 sun20i_efuse_xlate(u32 *speedbin, size_t len)

I feel like this prototype can be shortened to:

static u32 sun20i_efuse_xlate(u32 speedbin)

See below.

> +{
> +	u32 ret, efuse_value = 0;
> +	int i;
> +
> +	for (i = 0; i < len; i++)
> +		efuse_value |= ((u32)speedbin[i] << (i * 8));

The cast is not needed. Looking deeper into the original code you linked
to, cell_value[] there is an array of u8, so they assemble a little endian
32-bit integer from *up to* four 8-bit values read from the nvmem.

So I think this code here is wrong, len is the size of the nvmem cells
holding the bin identifier, in *bytes*, so the idea here is to just read
the (lowest) 16 bits (in the D1 case, cf. "reg = <0x00 0x2>;" in the next
patch) from this nvmem cell. Here you are combining two 32-bit words into
efuse_value.

So I think this whole part above is actually not necessary: we are
expecting maximum 32 bits, and nvmem_cell_read() should take care of
masking off unrequested bits, so we get the correct value back already. So
can you try to remove the loop above, and use ...

> +
> +	switch (efuse_value) {

	switch (*speedbin & 0xffff) {

here instead? Or drop the pointer at all, and just use one u32 value, see
the above prototype.

Cheers,
Andre

P.S. This is just a "peephole review" of this patch, I haven't got around
to look at this whole scheme in whole yet, to see if we actually need this
or can simplify this or clean it up.


> +	case 0x5e00:
> +		/* QFN package */
> +		ret = 0;
> +		break;
> +	case 0x5c00:
> +	case 0x7400:
> +		/* QFN package */
> +		ret = 1;
> +		break;
> +	case 0x5000:
> +	default:
> +		/* BGA package */
> +		ret = 0;
> +	}
> +
> +	return ret;
> +}
> +
>  static u32 sun50i_efuse_xlate(u32 *speedbin, size_t len)
>  {
>  	u32 efuse_value = 0;
> @@ -46,6 +73,10 @@ static u32 sun50i_efuse_xlate(u32 *speedbin, size_t len)
>  		return 0;
>  }
>  
> +struct sunxi_cpufreq_data sun20i_cpufreq_data = {
> +	.efuse_xlate = sun20i_efuse_xlate,
> +};
> +
>  struct sunxi_cpufreq_data sun50i_cpufreq_data = {
>  	.efuse_xlate = sun50i_efuse_xlate,
>  };
> @@ -54,6 +85,9 @@ static const struct of_device_id cpu_opp_match_list[] = {
>  	{ .compatible = "allwinner,sun50i-h6-operating-points",
>  	  .data = &sun50i_cpufreq_data,
>  	},
> +	{ .compatible = "allwinner,sun20i-d1-operating-points",
> +	  .data = &sun20i_cpufreq_data,
> +	},
>  	{}
>  };
>  



From konrad.dybcio at linaro.org  Thu Dec 21 04:51:58 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Thu, 21 Dec 2023 13:51:58 +0100
Subject: [PATCH 6/8] arm64: dts: qcom: sa8295p-adp: add max20411
In-Reply-To: <20231220-sa8295p-gpu-v1-6-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
 <20231220-sa8295p-gpu-v1-6-d8cdf2257f97@quicinc.com>
Message-ID: <b6866ee4-31d9-4404-9bd9-92bc4ab59b8c@linaro.org>

On 21.12.2023 04:50, Bjorn Andersson wrote:
> From: Bjorn Andersson <andersson at kernel.org>
> 
> The SA8295P ADP has a MAX20411 LDO regulator on I2C 12, supplying the
> VDD_GFX pads. Enable the bus and add the maxim,max20411 device on the
> bus.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 40 ++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> index fd253942e5e5..e16406c9c19d 100644
> --- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> +++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> @@ -266,6 +266,26 @@ &dispcc1 {
>  	status = "okay";
>  };
>  
> +&i2c12 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&qup1_i2c4_state>;
property-n
property-names

(same below)
> +
> +	status = "okay";
> +
> +	vdd_gfx: regulator at 39 {
> +		compatible = "maxim,max20411";
> +		reg = <0x39>;
> +
> +		regulator-min-microvolt = <800000>;
> +		regulator-max-microvolt = <968750>;
Is this ever going to be scaled? I suppose you could add some OPP code to
drm/msm and use opp-microvolts.. Or lock this down at min=max

Konrad


From konrad.dybcio at linaro.org  Thu Dec 21 04:57:15 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Thu, 21 Dec 2023 13:57:15 +0100
Subject: [PATCH 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX
 handler
In-Reply-To: <20231220-sa8295p-gpu-v1-2-d8cdf2257f97@quicinc.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
 <20231220-sa8295p-gpu-v1-2-d8cdf2257f97@quicinc.com>
Message-ID: <8d206362-7d80-46dc-8474-871fc53abc20@linaro.org>

On 21.12.2023 04:50, Bjorn Andersson wrote:
> The GX GDSC is modelled to aid the GMU in powering down the GPU in the
> event that the GPU crashes, so that it can be restarted again. But in
> the event that the power-domain is supplied through a dedicated
> regulator (in contrast to being a subdomin of another power-domain),
> something needs to turn that regulator on, both to make sure things are
> powered and to match the operation in gdsc_disable().
> 
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>  drivers/clk/qcom/gdsc.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> index 5358e28122ab..d1139c895503 100644
> --- a/drivers/clk/qcom/gdsc.c
> +++ b/drivers/clk/qcom/gdsc.c
> @@ -557,7 +557,13 @@ void gdsc_unregister(struct gdsc_desc *desc)
>   */
>  int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
I suppose the name is confusing now..

But at the same time I can't come up with anything that's less than
like 6 words..

Konrad


From abel.vesa at linaro.org  Thu Dec 21 05:03:07 2023
From: abel.vesa at linaro.org (Abel Vesa)
Date: Thu, 21 Dec 2023 15:03:07 +0200
Subject: [PATCH] clk: imx: pll14xx: change naming of fvco to fout
In-Reply-To: <1703068389-6130-1-git-send-email-shengjiu.wang@nxp.com>
References: <1703068389-6130-1-git-send-email-shengjiu.wang@nxp.com>
Message-ID: <170316377039.2868388.1010743948171671677.b4-ty@linaro.org>


On Wed, 20 Dec 2023 18:33:09 +0800, Shengjiu Wang wrote:
> pll14xx_calc_rate() output the fout clock not the fvco clock
> The relation of fvco and fout is:
> 	fout = fvco / (1 << sdiv)
> 
> So use correct naming for the clock.
> 
> 
> [...]

Applied, thanks!

[1/1] clk: imx: pll14xx: change naming of fvco to fout
      commit: f52f00069888e410cec718792b3e314624f209ea

Best regards,
-- 
Abel Vesa <abel.vesa at linaro.org>


From dmitry.baryshkov at linaro.org  Thu Dec 21 05:04:35 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 15:04:35 +0200
Subject: [PATCH 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX handler
In-Reply-To: <8d206362-7d80-46dc-8474-871fc53abc20@linaro.org>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
 <20231220-sa8295p-gpu-v1-2-d8cdf2257f97@quicinc.com> <8d206362-7d80-46dc-8474-871fc53abc20@linaro.org>
Message-ID: <CAA8EJpoEqKv_rWB8468WJzxqPA5w7u_zmGJJ0oKWAyaB9-f0eQ@mail.gmail.com>

On Thu, 21 Dec 2023 at 15:01, Konrad Dybcio <konrad.dybcio at linaro.org> wrote:
>
> On 21.12.2023 04:50, Bjorn Andersson wrote:
> > The GX GDSC is modelled to aid the GMU in powering down the GPU in the
> > event that the GPU crashes, so that it can be restarted again. But in
> > the event that the power-domain is supplied through a dedicated
> > regulator (in contrast to being a subdomin of another power-domain),
> > something needs to turn that regulator on, both to make sure things are
> > powered and to match the operation in gdsc_disable().
> >
> > Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> > ---
> >  drivers/clk/qcom/gdsc.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> > index 5358e28122ab..d1139c895503 100644
> > --- a/drivers/clk/qcom/gdsc.c
> > +++ b/drivers/clk/qcom/gdsc.c
> > @@ -557,7 +557,13 @@ void gdsc_unregister(struct gdsc_desc *desc)
> >   */
> >  int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
> I suppose the name is confusing now..
>
> But at the same time I can't come up with anything that's less than
> like 6 words..

gdsc_gx_enable() ;-)

-- 
With best wishes
Dmitry


From hugues.fruchet at foss.st.com  Thu Dec 21 05:05:01 2023
From: hugues.fruchet at foss.st.com (Hugues FRUCHET)
Date: Thu, 21 Dec 2023 14:05:01 +0100
Subject: [PATCH v5 3/5] media: hantro: add support for STM32MP25 VENC
In-Reply-To: <20231221111837.4u22pmba7jd3hinj@basti-XPS-13-9310>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <20231221084723.2152034-4-hugues.fruchet@foss.st.com>
 <20231221111837.4u22pmba7jd3hinj@basti-XPS-13-9310>
Message-ID: <70ed583e-af57-43e5-91a4-daa0568e83ab@foss.st.com>

Hi Sebastian,

Yes, feel free to fix the two comments !

BR,
Hugues.

On 12/21/23 12:18, Sebastian Fricke wrote:
> Hey Hugues,
> 
> one small comment below, if it should turn out to be the only problem I
> can fix it myself for the pull request.
> 
> On 21.12.2023 09:47, Hugues Fruchet wrote:
>> Add support for STM32MP25 VENC video hardware encoder.
>> Support of JPEG encoding.
>> VENC has its own reset/clock/irq.
>>
>> Signed-off-by: Hugues Fruchet <hugues.fruchet at foss.st.com>
>> Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>
>> ---
>> drivers/media/platform/verisilicon/Makefile?? |?? 3 +-
>> .../media/platform/verisilicon/hantro_drv.c?? |?? 1 +
>> .../media/platform/verisilicon/hantro_hw.h??? |?? 1 +
>> .../platform/verisilicon/stm32mp25_venc_hw.c? | 115 ++++++++++++++++++
>> 4 files changed, 119 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>>
>> diff --git a/drivers/media/platform/verisilicon/Makefile 
>> b/drivers/media/platform/verisilicon/Makefile
>> index 5854e0f0dd32..3bf43fdbedc1 100644
>> --- a/drivers/media/platform/verisilicon/Makefile
>> +++ b/drivers/media/platform/verisilicon/Makefile
>> @@ -41,4 +41,5 @@ hantro-vpu-$(CONFIG_VIDEO_HANTRO_SUNXI) += \
>> ??????? sunxi_vpu_hw.o
>>
>> hantro-vpu-$(CONFIG_VIDEO_HANTRO_STM32MP25) += \
>> -??????? stm32mp25_vdec_hw.o
>> +??????? stm32mp25_vdec_hw.o \
>> +??????? stm32mp25_venc_hw.o
>> diff --git a/drivers/media/platform/verisilicon/hantro_drv.c 
>> b/drivers/media/platform/verisilicon/hantro_drv.c
>> index 2db27c333924..4d97a8ac03de 100644
>> --- a/drivers/media/platform/verisilicon/hantro_drv.c
>> +++ b/drivers/media/platform/verisilicon/hantro_drv.c
>> @@ -736,6 +736,7 @@ static const struct of_device_id of_hantro_match[] 
>> = {
>> #endif
>> #ifdef CONFIG_VIDEO_HANTRO_STM32MP25
>> ????{ .compatible = "st,stm32mp25-vdec", .data = 
>> &stm32mp25_vdec_variant, },
>> +??? { .compatible = "st,stm32mp25-venc", .data = 
>> &stm32mp25_venc_variant, },
>> #endif
>> ????{ /* sentinel */ }
>> };
>> diff --git a/drivers/media/platform/verisilicon/hantro_hw.h 
>> b/drivers/media/platform/verisilicon/hantro_hw.h
>> index b7eccc1a96fc..70c72e9d11d5 100644
>> --- a/drivers/media/platform/verisilicon/hantro_hw.h
>> +++ b/drivers/media/platform/verisilicon/hantro_hw.h
>> @@ -407,6 +407,7 @@ extern const struct hantro_variant 
>> rk3588_vpu981_variant;
>> extern const struct hantro_variant sama5d4_vdec_variant;
>> extern const struct hantro_variant sunxi_vpu_variant;
>> extern const struct hantro_variant stm32mp25_vdec_variant;
>> +extern const struct hantro_variant stm32mp25_venc_variant;
>>
>> extern const struct hantro_postproc_ops hantro_g1_postproc_ops;
>> extern const struct hantro_postproc_ops hantro_g2_postproc_ops;
>> diff --git a/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c 
>> b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>> new file mode 100644
>> index 000000000000..0ff0f073b922
>> --- /dev/null
>> +++ b/drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>> @@ -0,0 +1,115 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * STM32MP25 VENC video encoder driver
>> + *
>> + * Copyright (C) STMicroelectronics SA 2022
>> + * Authors: Hugues Fruchet <hugues.fruchet at foss.st.com>
>> + *????????? for STMicroelectronics.
>> + *
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/reset.h>
>> +
>> +#include "hantro.h"
>> +#include "hantro_jpeg.h"
>> +#include "hantro_h1_regs.h"
>> +
>> +/*
>> + * Supported formats.
>> + */
>> +
>> +static const struct hantro_fmt stm32mp25_venc_fmts[] = {
>> +??? {
>> +??????? .fourcc = V4L2_PIX_FMT_YUV420M,
>> +??????? .codec_mode = HANTRO_MODE_NONE,
>> +??????? .enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420P,
>> +??? },
>> +??? {
>> +??????? .fourcc = V4L2_PIX_FMT_NV12M,
>> +??????? .codec_mode = HANTRO_MODE_NONE,
>> +??????? .enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUV420SP,
>> +??? },
>> +??? {
>> +??????? .fourcc = V4L2_PIX_FMT_YUYV,
>> +??????? .codec_mode = HANTRO_MODE_NONE,
>> +??????? .enc_fmt = ROCKCHIP_VPU_ENC_FMT_YUYV422,
>> +??? },
>> +??? {
>> +??????? .fourcc = V4L2_PIX_FMT_UYVY,
>> +??????? .codec_mode = HANTRO_MODE_NONE,
>> +??????? .enc_fmt = ROCKCHIP_VPU_ENC_FMT_UYVY422,
>> +??? },
>> +??? {
>> +??????? .fourcc = V4L2_PIX_FMT_JPEG,
>> +??????? .codec_mode = HANTRO_MODE_JPEG_ENC,
>> +??????? .max_depth = 2,
>> +??????? .header_size = JPEG_HEADER_SIZE,
>> +??????? .frmsize = {
>> +??????????? .min_width = 96,
>> +??????????? .max_width = FMT_4K_WIDTH,
>> +??????????? .step_width = MB_DIM,
>> +??????????? .min_height = 96,
>> +??????????? .max_height = FMT_4K_HEIGHT,
>> +??????????? .step_height = MB_DIM,
>> +??????? },
>> +??? },
>> +};
>> +
>> +static irqreturn_t stm32mp25_venc_irq(int irq, void *dev_id)
>> +{
>> +??? struct hantro_dev *vpu = dev_id;
>> +??? enum vb2_buffer_state state;
>> +??? u32 status;
>> +
>> +??? status = vepu_read(vpu, H1_REG_INTERRUPT);
>> +??? state = (status & H1_REG_INTERRUPT_FRAME_RDY) ?
>> +??????? VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
>> +
>> +??? vepu_write(vpu, H1_REG_INTERRUPT_BIT, H1_REG_INTERRUPT);
>> +
>> +??? hantro_irq_done(vpu, state);
>> +
>> +??? return IRQ_HANDLED;
>> +}
>> +
>> +static void stm32mp25_venc_reset(struct hantro_ctx *ctx)
>> +{
>> +}
>> +
>> +/*
>> + * Supported codec ops.
>> + */
>> +
>> +static const struct hantro_codec_ops stm32mp25_venc_codec_ops[] = {
>> +??? [HANTRO_MODE_JPEG_ENC] = {
>> +??????? .run = hantro_h1_jpeg_enc_run,
>> +??????? .reset = stm32mp25_venc_reset,
>> +??????? .done = hantro_h1_jpeg_enc_done,
>> +??? },
>> +};
>> +
>> +/*
>> + * Variants.
>> + */
>> +
>> +static const struct hantro_irq stm32mp25_venc_irqs[] = {
>> +??? { "venc", stm32mp25_venc_irq },
>> +};
>> +
>> +static const char * const stm32mp25_venc_clk_names[] = {
>> +??? "venc-clk"
>> +};
>> +
>> +const struct hantro_variant stm32mp25_venc_variant = {
>> +??? .enc_fmts = stm32mp25_venc_fmts,
>> +??? .num_enc_fmts = ARRAY_SIZE(stm32mp25_venc_fmts),
>> +??? .codec = HANTRO_JPEG_ENCODER,
>> +??? .codec_ops = stm32mp25_venc_codec_ops,
>> +??? .irqs = stm32mp25_venc_irqs,
>> +??? .num_irqs = ARRAY_SIZE(stm32mp25_venc_irqs),
>> +??? .clk_names = stm32mp25_venc_clk_names,
>> +??? .num_clocks = ARRAY_SIZE(stm32mp25_venc_clk_names)
>> +};
>> +
> 
> There is an superfluous new line here.
> 
> Greetings,
> Sebastian
> 
>> -- 
>> 2.25.1
>>
>>


From ruipengqi7 at gmail.com  Thu Dec 21 05:05:55 2023
From: ruipengqi7 at gmail.com (Ruipeng Qi)
Date: Thu, 21 Dec 2023 21:05:55 +0800
Subject: [RFC PATCH 0/7] osdump: Add one new os minidump module
Message-ID: <20231221130555.32551-1-ruipengqi7@gmail.com>

From: qiruipeng <qiruipeng at lixiang.com>

Osdump is a new crash dumping solution aiming at specific embedded
devices within automotive or Industrial.
 - limited memory.
 - reboot as soon as possible when system fault.

In order to reduce dump file size and speed up dump process, it has the
following features:
 - no userspace memory, just designed for solving os issues.
 - no const data, such as text segment
 - dump core os data only.
   - bss, data segments which alloc static.
   - dynamic data
     - slub data for little size data.
     - some large size data.
 - compress dump data to reduce dump file size.

consist of large massive of uncontinuous data,so use binary data format
directly.

reasemble a standard elf format file with dump file and vmlinux, and
then parse it with crash tool.

Signed-off-by: qiruipeng <qiruipeng at lixiang.com>

qiruipeng (7):
  [RFC PATCH 1/7] osdump: Add one new os minidump module
  [RFC PATCH 2/7] osdump: reuse some code from crash_core to get
    vmcoreinfo
  [RFC PATCH 3/7] doc: Add osdump guide
  [RFC PATCH 4/7] dt-bindings: reserved-memory: Support osdump module
  [RFC PATCH 5/7] sched: access to runqueues by function
  [RFC PATCH 6/7] mm/slub: make slab data more observable
  [RFC PATCH 7/7] panic: invoke osdump when panic

 Documentation/admin-guide/index.rst           |   1 +
 Documentation/admin-guide/osdump.rst          |  94 +++
 .../bindings/reserved-memory/osdump.yaml      |  45 ++
 arch/arm64/Kconfig                            | 169 +++++
 arch/arm64/kernel/Makefile                    |   1 +
 drivers/of/platform.c                         |   1 +
 include/linux/buildid.h                       |   3 +-
 include/linux/osdump.h                        |   7 +
 kernel/Makefile                               |   2 +
 kernel/crash_core_mini.c                      | 275 ++++++++
 kernel/osdump/Makefile                        |   1 +
 kernel/osdump/compr.c                         | 252 ++++++++
 kernel/osdump/core.c                          | 608 ++++++++++++++++++
 kernel/osdump/extern.h                        |  13 +
 kernel/osdump/inode.c                         |  77 +++
 kernel/osdump/internal.h                      |  95 +++
 kernel/panic.c                                |   7 +
 kernel/printk/printk.c                        |   2 +-
 kernel/sched/core.c                           |   8 +
 lib/buildid.c                                 |   3 +-
 mm/slab.h                                     |   2 +
 mm/slub.c                                     |  38 +-
 22 files changed, 1700 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/admin-guide/osdump.rst
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/osdump.yaml
 create mode 100644 include/linux/osdump.h
 create mode 100644 kernel/crash_core_mini.c
 create mode 100644 kernel/osdump/Makefile
 create mode 100644 kernel/osdump/compr.c
 create mode 100644 kernel/osdump/core.c
 create mode 100644 kernel/osdump/extern.h
 create mode 100644 kernel/osdump/inode.c
 create mode 100644 kernel/osdump/internal.h

-- 
2.17.1



From hugues.fruchet at foss.st.com  Thu Dec 21 05:08:23 2023
From: hugues.fruchet at foss.st.com (Hugues FRUCHET)
Date: Thu, 21 Dec 2023 14:08:23 +0100
Subject: [PATCH v5 0/5] Add support for video hardware codec of
 STMicroelectronics STM32 SoC series
In-Reply-To: <769a1510-f8d2-4095-9879-42f413141dee@gmail.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <769a1510-f8d2-4095-9879-42f413141dee@gmail.com>
Message-ID: <a240d2ac-db0e-481b-8d13-3ae76cfd2fe7@foss.st.com>

Hi Alex,

This is because VDEC and VENC are two separated IPs with their own 
hardware resources and no links between both.
On future SoCs, VDEC can ship on its own, same for VENC.

Hoping that this clarify.

Best regards,
Hugues.

On 12/21/23 13:40, Alex Bee wrote:
> Hi Hugues, Hi Nicolas,
> 
> is there any specific reason I'm not understanding / seeing why this is 
> added in two seperate vdec* / venc* files and not a single vpu* file? Is 
> it only for the seperate clocks (-names) / irqs (-names) / callbacks? 
> Those are defined per variant and perfectly fit in a single file holding 
> one vdec and one venc variant.
> 
> Alex
> 
> Am 21.12.23 um 09:47 schrieb Hugues Fruchet:
>> This patchset introduces support for VDEC video hardware decoder
>> and VENC video hardware encoder of STMicroelectronics STM32MP25
>> SoC series.
>>
>> This initial support implements H264 decoding, VP8 decoding and
>> JPEG encoding.
>>
>> This has been tested on STM32MP257F-EV1 evaluation board.
>>
>> ===========
>> = history =
>> ===========
>> version 5:
>> ??? - Precise that video decoding as been successfully tested up to 
>> full HD
>> ??? - Add Nicolas Dufresne reviewed-by
>>
>> version 4:
>> ??? - Fix comments from Nicolas about dropping encoder raw steps
>>
>> version 3:
>> ??? - Fix remarks from Krzysztof Kozlowski:
>> ???? - drop "items", we keep simple enum in such case
>> ???? - drop second example - it is the same as the first
>> ??? - Drop unused node labels as suggested by Conor Dooley
>> ??? - Revisit min/max resolutions as suggested by Nicolas Dufresne
>>
>> version 2:
>> ??? - Fix remarks from Krzysztof Kozlowski on v1:
>> ???? - single video-codec binding for both VDEC/VENC
>> ???? - get rid of "-names"
>> ???? - use of generic node name "video-codec"
>>
>> version 1:
>> ?? - Initial submission
>>
>> Hugues Fruchet (5):
>> ?? dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
>> ?? media: hantro: add support for STM32MP25 VDEC
>> ?? media: hantro: add support for STM32MP25 VENC
>> ?? arm64: dts: st: add video decoder support to stm32mp255
>> ?? arm64: dts: st: add video encoder support to stm32mp255
>>
>> ? .../media/st,stm32mp25-video-codec.yaml?????? |? 50 ++++++++
>> ? arch/arm64/boot/dts/st/stm32mp251.dtsi??????? |? 12 ++
>> ? arch/arm64/boot/dts/st/stm32mp255.dtsi??????? |? 17 +++
>> ? drivers/media/platform/verisilicon/Kconfig??? |? 14 ++-
>> ? drivers/media/platform/verisilicon/Makefile?? |?? 4 +
>> ? .../media/platform/verisilicon/hantro_drv.c?? |?? 4 +
>> ? .../media/platform/verisilicon/hantro_hw.h??? |?? 2 +
>> ? .../platform/verisilicon/stm32mp25_vdec_hw.c? |? 92 ++++++++++++++
>> ? .../platform/verisilicon/stm32mp25_venc_hw.c? | 115 ++++++++++++++++++
>> ? 9 files changed, 307 insertions(+), 3 deletions(-)
>> ? create mode 100644 
>> Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
>> ? create mode 100644 
>> drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>> ? create mode 100644 
>> drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>>
> 


From ruipengqi7 at gmail.com  Thu Dec 21 05:09:30 2023
From: ruipengqi7 at gmail.com (Ruipeng Qi)
Date: Thu, 21 Dec 2023 21:09:30 +0800
Subject: [PATCH 1/7] [RFC PATCH 1/7] osdump: Add one new os minidump module
Message-ID: <20231221130930.32634-1-ruipengqi7@gmail.com>

From: qiruipeng <qiruipeng at lixiang.com>

Osdump is a new crash dumping solution aiming at specific embedded
devices within automotive or Industrial.
 - limited memory.
 - reboot as soon as possible when system fault.

In order to reduce dump file size and speed up dump process, it has the
following features:
 - no userspace memory, just designed for solving os issues.
 - no const data, such as text segment
 - dump core os data only.
   - bss, data segments which alloc static.
   - dynamic data
     - slub data for little size data.
     - some large size data.
 - compress dump data to reduce dump file size.

consist of large massive of uncontinuous data,so use binary data format
directly.

reasemble a standard elf format file with dump file and vmlinux, and
then parse it with crash tool.

Signed-off-by: qiruipeng <qiruipeng at lixiang.com>
---
 arch/arm64/Kconfig       | 169 +++++++++++
 drivers/of/platform.c    |   1 +
 include/linux/osdump.h   |   7 +
 kernel/Makefile          |   1 +
 kernel/osdump/Makefile   |   1 +
 kernel/osdump/compr.c    | 252 ++++++++++++++++
 kernel/osdump/core.c     | 608 +++++++++++++++++++++++++++++++++++++++
 kernel/osdump/extern.h   |  13 +
 kernel/osdump/inode.c    |  77 +++++
 kernel/osdump/internal.h |  95 ++++++
 10 files changed, 1224 insertions(+)
 create mode 100644 include/linux/osdump.h
 create mode 100644 kernel/osdump/Makefile
 create mode 100644 kernel/osdump/compr.c
 create mode 100644 kernel/osdump/core.c
 create mode 100644 kernel/osdump/extern.h
 create mode 100644 kernel/osdump/inode.c
 create mode 100644 kernel/osdump/internal.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..6e5e96b5738e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -258,6 +258,175 @@ config ARM64
 	help
 	  ARM 64-bit (AArch64) Linux support.
 
+config OS_MINIDUMP
+	bool "Enable os minidump module"
+	default n
+	depends on !CRASH_CORE && !SLUB_DEBUG && !SLUB_TINY
+	help
+	  Trigger os minidump when panic. It only dump parts of os core
+	  datas/segments in raw binary format to reduce its size and
+	  speed up dump process. Reasemble a standard elf format file
+	  with dump file and vmlinux, and then parse it with crash tool.
+
+	  For more details see Documentation/admin-guide/osdump.rst
+
+	  If unsure, say N.
+
+config OS_MINIDUMP_DEFLATE_COMPRESS
+	tristate "DEFLATE (ZLIB) compression"
+	depends on OS_MINIDUMP
+	select CRYPTO_DEFLATE
+	help
+	  This option enables DEFLATE (also known as ZLIB) compression
+	  algorithm support for os minidump. Enabling this option will allow
+	  mini dumps to be compressed using DEFLATE, which may reduce the size of
+	  the dump files.
+
+	  If unsure, say N.
+
+config OS_MINIDUMP_LZO_COMPRESS
+	tristate "LZO compression"
+	default y
+	depends on OS_MINIDUMP
+	select CRYPTO_LZO
+	help
+	  This option enables LZO compression algorithm support for os minidump.
+	  Enabling this option will allow mini dumps to be compressed using LZO,
+	  which may reduce the size of the dump files.
+
+	  If unsure, say Y.
+
+config OS_MINIDUMP_LZ4_COMPRESS
+	tristate "LZ4 compression"
+	depends on OS_MINIDUMP
+	select CRYPTO_LZ4
+	help
+	  This option enables LZ4 compression algorithm support for os minidump.
+	  Enabling this option will allow mini dumps to be compressed using LZ4,
+	  which may reduce the size of the dump files.
+
+	  If unsure, say N.
+
+config OS_MINIDUMP_LZ4HC_COMPRESS
+	tristate "LZ4HC compression"
+	depends on OS_MINIDUMP
+	select CRYPTO_LZ4HC
+	help
+	  This option enables LZ4HC (high compression) mode algorithm.
+	  Enabling this option will allow mini dumps to be compressed using LZ4HC,
+	  which may reduce the size of the dump files.
+
+	  If unsure, say N.
+
+config OS_MINIDUMP_842_COMPRESS
+	bool "842 compression"
+	depends on OS_MINIDUMP
+	select CRYPTO_842
+	help
+	  This option enables 842 compression algorithm support for os minidump.
+	  Enabling this option will allow mini dumps to be compressed using 842,
+	  which may reduce the size of the dump files.
+
+	  If unsure, say N.
+
+config OS_MINIDUMP_ZSTD_COMPRESS
+	bool "zstd compression"
+	depends on OS_MINIDUMP
+	select CRYPTO_ZSTD
+	help
+	  This option enables zstd compression algorithm support for os minidump.
+	  Enabling this option will allow mini dumps to be compressed using ZSTD,
+	  which may reduce the size of the dump files.
+
+	  If unsure, say N.
+
+config OS_MINIDUMP_COMPRESS
+	def_bool y
+	depends on OS_MINIDUMP
+	depends on OS_MINIDUMP_DEFLATE_COMPRESS || OS_MINIDUMP_LZO_COMPRESS ||    \
+		   OS_MINIDUMP_LZ4_COMPRESS || OS_MINIDUMP_LZ4HC_COMPRESS ||      \
+		   OS_MINIDUMP_842_COMPRESS || OS_MINIDUMP_ZSTD_COMPRESS
+
+choice
+	prompt "Default osdump.compression algorithm"
+	depends on OS_MINIDUMP_COMPRESS
+	help
+	  This option chooses the default active compression algorithm.
+	  This can be changed at boot with "osdump.compress=..." on
+	  the kernel command line.
+
+	  Currently, osdump.has support for 6 compression algorithms:
+	  deflate, lzo, lz4, lz4hc, 842 and zstd.
+
+	  The default compression algorithm is lzo.
+
+	config OS_MINIDUMP_DEFLATE_COMPRESS_DEFAULT
+		bool "deflate" if OS_MINIDUMP_DEFLATE_COMPRESS
+		help
+		  This option chooses deflate as default compression algorithm,
+		  which reduce the size of the dump files greately.
+
+		  This can be changed at boot with "osdump.compress=..." on
+		  the kernel command line.
+
+	config OS_MINIDUMP_LZO_COMPRESS_DEFAULT
+		bool "lzo" if OS_MINIDUMP_LZO_COMPRESS
+		help
+		  This option chooses lzo as default compression algorithm,
+		  which reduce the size of the dump files greately.
+
+		  This can be changed at boot with "osdump.compress=..." on
+		  the kernel command line.
+
+	config OS_MINIDUMP_LZ4_COMPRESS_DEFAULT
+		bool "lz4" if OS_MINIDUMP_LZ4_COMPRESS
+		help
+		  This option chooses lz4 as default compression algorithm,
+		  which reduce the size of the dump files greately.
+
+		  This can be changed at boot with "osdump.compress=..." on
+		  the kernel command line.
+
+	config OS_MINIDUMP_LZ4HC_COMPRESS_DEFAULT
+		bool "lz4hc" if OS_MINIDUMP_LZ4HC_COMPRESS
+		help
+		  This option chooses lz4hc as default compression algorithm,
+		  which reduce the size of the dump files greately.
+
+		  This can be changed at boot with "osdump.compress=..." on
+		  the kernel command line.
+
+	config OS_MINIDUMP_842_COMPRESS_DEFAULT
+		bool "842" if OS_MINIDUMP_842_COMPRESS
+		help
+		  This option chooses 842 as default compression algorithm,
+		  which reduce the size of the dump files greately.
+
+		  This can be changed at boot with "osdump.compress=..." on
+		  the kernel command line.
+
+	config OS_MINIDUMP_ZSTD_COMPRESS_DEFAULT
+		bool "zstd" if OS_MINIDUMP_ZSTD_COMPRESS
+		help
+		  This option chooses zstd as default compression algorithm,
+		  which reduce the size of the dump files greately.
+
+		  This can be changed at boot with "osdump.compress=..." on
+		  the kernel command line.
+
+endchoice
+
+config OS_MINIDUMP_COMPRESS_DEFAULT
+	string
+	depends on OS_MINIDUMP_COMPRESS
+	default "deflate" if OS_MINIDUMP_DEFLATE_COMPRESS_DEFAULT
+	default "lzo" if OS_MINIDUMP_LZO_COMPRESS_DEFAULT
+	default "lz4" if OS_MINIDUMP_LZ4_COMPRESS_DEFAULT
+	default "lz4hc" if OS_MINIDUMP_LZ4HC_COMPRESS_DEFAULT
+	default "842" if OS_MINIDUMP_842_COMPRESS_DEFAULT
+	default "zstd" if OS_MINIDUMP_ZSTD_COMPRESS_DEFAULT
+
+
 config CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS
 	def_bool CC_IS_CLANG
 	# https://github.com/ClangBuiltLinux/linux/issues/1507
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 126d265aa7d8..6622292633f7 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -538,6 +538,7 @@ static const struct of_device_id reserved_mem_matches[] = {
 	{ .compatible = "qcom,cmd-db" },
 	{ .compatible = "qcom,smem" },
 	{ .compatible = "ramoops" },
+	{ .compatible = "osdump" },
 	{ .compatible = "nvmem-rmem" },
 	{ .compatible = "google,open-dice" },
 	{}
diff --git a/include/linux/osdump.h b/include/linux/osdump.h
new file mode 100644
index 000000000000..600d0d4901eb
--- /dev/null
+++ b/include/linux/osdump.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_OS_MINIDUMP_H
+#define _LINUX_OS_MINIDUMP_H
+
+extern int osdump(void);
+
+#endif
diff --git a/kernel/Makefile b/kernel/Makefile
index 3947122d618b..dc2b4ba5c953 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -116,6 +116,7 @@ obj-$(CONFIG_HAVE_STATIC_CALL_INLINE) += static_call_inline.o
 obj-$(CONFIG_CFI_CLANG) += cfi.o
 
 obj-$(CONFIG_PERF_EVENTS) += events/
+obj-$(CONFIG_OS_MINIDUMP) += osdump/
 
 obj-$(CONFIG_USER_RETURN_NOTIFIER) += user-return-notifier.o
 obj-$(CONFIG_PADATA) += padata.o
diff --git a/kernel/osdump/Makefile b/kernel/osdump/Makefile
new file mode 100644
index 000000000000..3f9cd6282653
--- /dev/null
+++ b/kernel/osdump/Makefile
@@ -0,0 +1 @@
+obj-y += core.o inode.o compr.o
diff --git a/kernel/osdump/compr.c b/kernel/osdump/compr.c
new file mode 100644
index 000000000000..08aa6b72177c
--- /dev/null
+++ b/kernel/osdump/compr.c
@@ -0,0 +1,252 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * OS Minidump - compression driver interface parts.
+ *
+ */
+
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_LZO_COMPRESS)
+#include <linux/types.h>
+#include <linux/lzo.h>
+#endif
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_LZ4_COMPRESS) || IS_ENABLED(CONFIG_OS_MINIDUMP_LZ4HC_COMPRESS)
+#include <linux/lz4.h>
+#endif
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_ZSTD_COMPRESS)
+#include <linux/zstd.h>
+#endif
+#include <linux/crypto.h>
+#include <linux/string.h>
+
+#include <linux/module.h>
+#include "internal.h"
+
+static char *compress = CONFIG_OS_MINIDUMP_COMPRESS_DEFAULT;
+
+module_param(compress, charp, 0444);
+MODULE_PARM_DESC(compress, "compression to use");
+
+/* Compression parameters */
+static struct crypto_comp *tfm;
+
+struct osdump_zbackend {
+	int (*zbufsize)(size_t size);
+	const char *name;
+};
+
+static void *big_oops_buf;
+size_t big_oops_buf_sz;
+EXPORT_SYMBOL_GPL(big_oops_buf_sz);
+
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_DEFLATE_COMPRESS)
+static int zbufsize_deflate(size_t size)
+{
+	size_t cmpr;
+
+	switch (size) {
+	/* buffer range for efivars */
+	case 1000 ... 2000:
+		cmpr = 56;
+		break;
+	case 2001 ... 3000:
+		cmpr = 54;
+		break;
+	case 3001 ... 3999:
+		cmpr = 52;
+		break;
+		/* buffer range for nvram, erst */
+	case 4000 ... 10000:
+		cmpr = 45;
+		break;
+	default:
+		cmpr = 60;
+		break;
+	}
+
+	return (size * 100) / cmpr;
+}
+#endif
+
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_LZO_COMPRESS)
+static int zbufsize_lzo(size_t size)
+{
+	return lzo1x_worst_compress(size);
+}
+#endif
+
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_LZ4_COMPRESS) || IS_ENABLED(CONFIG_OS_MINIDUMP_LZ4HC_COMPRESS)
+static int zbufsize_lz4(size_t size)
+{
+	return LZ4_compressBound(size);
+}
+#endif
+
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_842_COMPRESS)
+static int zbufsize_842(size_t size)
+{
+	return size;
+}
+#endif
+
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_ZSTD_COMPRESS)
+static int zbufsize_zstd(size_t size)
+{
+	return ZSTD_compressBound(size);
+}
+#endif
+
+static const struct osdump_zbackend *zbackend __ro_after_init;
+
+static const struct osdump_zbackend zbackends[] = {
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_DEFLATE_COMPRESS)
+	{
+		.zbufsize       = zbufsize_deflate,
+		.name           = "deflate",
+	},
+#endif
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_LZO_COMPRESS)
+	{
+		.zbufsize       = zbufsize_lzo,
+		.name           = "lzo",
+	},
+#endif
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_LZ4_COMPRESS)
+	{
+		.zbufsize       = zbufsize_lz4,
+		.name           = "lz4",
+	},
+#endif
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_LZ4HC_COMPRESS)
+	{
+		.zbufsize       = zbufsize_lz4,
+		.name           = "lz4hc",
+	},
+#endif
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_842_COMPRESS)
+	{
+		.zbufsize       = zbufsize_842,
+		.name           = "842",
+	},
+#endif
+#if IS_ENABLED(CONFIG_OS_MINIDUMP_ZSTD_COMPRESS)
+	{
+		.zbufsize       = zbufsize_zstd,
+		.name           = "zstd",
+	},
+#endif
+	{ }
+};
+
+int osdump_compress(const void *in, void *out, unsigned int size, int *left)
+{
+	int ret;
+	unsigned int outlen = size;
+
+	if (!IS_ENABLED(CONFIG_OS_MINIDUMP_COMPRESS))
+		return -EINVAL;
+
+	ret = crypto_comp_compress(tfm, in, size, big_oops_buf, &outlen);
+	if (ret) {
+		pr_err(DUMP_BANNER "crypto_comp_compress failed, ret = %d!\n", ret);
+		return ret;
+	}
+
+	if (outlen <= *left) {
+		memcpy(out, big_oops_buf, outlen);
+		*left -= outlen;
+	} else
+		*left = 0;
+
+	return outlen;
+}
+
+static void allocate_buf_for_compression(void)
+{
+	struct crypto_comp *ctx;
+	int size;
+	char *buf;
+
+	/* Skip if not built-in or compression backend not selected yet. */
+	if (!IS_ENABLED(CONFIG_OS_MINIDUMP_COMPRESS) || !zbackend)
+		return;
+
+	/* Skip if compression init already done. */
+	if (tfm)
+		return;
+
+	if (!crypto_has_comp(zbackend->name, 0, 0)) {
+		pr_err(DUMP_BANNER "Unknown compression: %s\n", zbackend->name);
+		return;
+	}
+
+	size = zbackend->zbufsize(CRYPTO_SIZE);
+	if (size <= 0) {
+		pr_err(DUMP_BANNER "Invalid compression size for %s: %d\n",
+				zbackend->name, size);
+		return;
+	}
+	size = round_down(size, PAGE_SIZE);
+
+	buf = kmalloc(size, GFP_KERNEL);
+	if (!buf)
+		return;
+
+	ctx = crypto_alloc_comp(zbackend->name, 0, 0);
+	if (IS_ERR_OR_NULL(ctx)) {
+		kfree(buf);
+		pr_err(DUMP_BANNER "crypto_alloc_comp('%s') failed: %ld\n", zbackend->name,
+				PTR_ERR(ctx));
+		return;
+	}
+
+	/* A non-NULL big_oops_buf indicates compression is available. */
+	tfm = ctx;
+	big_oops_buf_sz = size;
+	big_oops_buf = buf;
+
+	pr_info(DUMP_BANNER "Using os minidump compression: %s\n", zbackend->name);
+}
+
+static void free_buf_for_compression(void)
+{
+	if (IS_ENABLED(CONFIG_OS_MINIDUMP_COMPRESS) && tfm) {
+		crypto_free_comp(tfm);
+		tfm = NULL;
+	}
+	kfree(big_oops_buf);
+	big_oops_buf = NULL;
+	big_oops_buf_sz = 0;
+}
+
+static void __init osdump_choose_compression(void)
+{
+	const struct osdump_zbackend *step;
+
+	if (!compress)
+		return;
+
+	for (step = zbackends; step->name; step++) {
+		if (!strcmp(compress, step->name)) {
+			zbackend = step;
+			return;
+		}
+	}
+}
+
+static int __init compr_init(void)
+{
+	osdump_choose_compression();
+
+	allocate_buf_for_compression();
+
+	return 0;
+}
+late_initcall(compr_init);
+
+static void __exit compr_exit(void)
+{
+	free_buf_for_compression();
+}
+module_exit(compr_exit);
+
+MODULE_AUTHOR("qiruipeng");
+MODULE_LICENSE("GPL");
diff --git a/kernel/osdump/core.c b/kernel/osdump/core.c
new file mode 100644
index 000000000000..0da8c2ac3fc7
--- /dev/null
+++ b/kernel/osdump/core.c
@@ -0,0 +1,608 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * OS Minidump - core implement parts.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/seq_file.h>
+#include <linux/proc_fs.h>
+#include <linux/mm.h>
+#include <linux/platform_device.h>
+#include <linux/of_device.h>
+#include <linux/io.h>
+#include <linux/device.h>
+#include "internal.h"
+#include <linux/slab.h>
+#include "../../mm/slab.h"
+#include <linux/nmi.h>
+#include <linux/sched.h>
+#include <linux/byteorder/generic.h>
+#include <asm/kernel-pgtable.h>
+#include <linux/osdump.h>
+#include <linux/cpu.h>
+#include "extern.h"
+
+#define OS_DUMP		"osdump"
+
+struct osdump_variables osdump_var;
+EXPORT_SYMBOL_GPL(osdump_var);
+
+static inline u64 htonll(u64 val)
+{
+	return (((u64) htonl(val)) << 32) + htonl(val >> 32);
+}
+
+static inline u64 ntohll(u64 val)
+{
+	return (((u64) ntohl(val)) << 32) + ntohl(val >> 32);
+}
+
+static int common_store(void *src, phys_addr_t phys_addr, int src_size,
+			struct osdump_variables *osdump_var, int *sum)
+{
+	void *addr = osdump_var->mem_address;
+	int size, tmp, cnt = 0;
+
+	while (src_size > 0) {
+		size  = src_size > big_oops_buf_sz ? big_oops_buf_sz : src_size;
+		tmp = size;
+		size = osdump_compress(src, osdump_var->dst, size, &osdump_var->rem);
+
+		*sum += tmp;
+		(osdump_var->meta)->start = htonl(osdump_var->dst - addr);
+		(osdump_var->meta)->size = htonl(size);
+		(osdump_var->meta)->src = htonll(phys_addr);
+		(osdump_var->dst) += size;
+		(osdump_var->meta)++;
+		cnt++;
+		src += tmp;
+		phys_addr += tmp;
+		src_size -= tmp;
+
+		if (osdump_var->meta > osdump_var->meta_end)
+			osdump_var->rem = 0;
+	}
+
+	return cnt;
+}
+
+static int stack_dump(struct osdump_variables *osdump_var)
+{
+	int cnt = 0;
+	int sum = 0;
+
+	struct task_struct *tsk;
+	struct vm_struct *area;
+	int i;
+
+	tsk = current;
+	area = tsk->stack_vm_area;
+
+	for (i = 0; i < area->nr_pages; i++) {
+		cnt += common_store(area->addr + i * PAGE_SIZE, page_to_phys(area->pages[i]),
+					PAGE_SIZE, osdump_var, &sum);
+		if (osdump_var->rem <= 0)
+			break;
+	}
+
+
+	return cnt;
+}
+
+#if CONFIG_PGTABLE_LEVELS >= 2
+static int process_pmd(pmd_t *pmd, struct osdump_variables *osdump_var, int *sum)
+{
+	int i, cnt = 0;
+	struct page *page;
+
+	for (i = 0; i < PTRS_PER_PMD; i++) {
+
+		if (!pmd_none(*pmd)) {
+			page = pmd_page(*pmd);
+			if ((pmd_val(*pmd) & PMD_ATTRINDX_MASK) >> 2 == MT_NORMAL) {
+				if ((pmd_val(*pmd) & PMD_TYPE_MASK)  == PMD_TYPE_TABLE) {
+					cnt += common_store(page_to_virt(page), page_to_phys(page),
+								PAGE_SIZE, osdump_var, sum);
+
+				// save struct page here
+				} else if ((pmd_val(*pmd) & PMD_TYPE_MASK)  == PMD_TYPE_SECT
+						&& !(pmd_val(*pmd) & (PMD_SECT_RDONLY))) {
+					cnt += common_store(page_to_virt(page), page_to_phys(page),
+								PMD_SIZE, osdump_var, sum);
+
+				}
+				if (osdump_var->rem <= 0)
+					break;
+			}
+		}
+
+		pmd++;
+	}
+	return cnt;
+}
+#endif
+
+#if CONFIG_PGTABLE_LEVELS >= 3
+static int process_pud(pud_t *pud, struct osdump_variables *osdump_var, int *sum)
+{
+	int i, cnt = 0;
+	struct page *page;
+
+	for (i = 0; i < PTRS_PER_PUD; i++) {
+		if ((pud_val(*pud))) {
+			page = pud_page(*pud);
+
+			cnt += common_store(page_to_virt(page), page_to_phys(page),
+						PAGE_SIZE, osdump_var, sum);
+			if (osdump_var->rem <= 0)
+				break;
+
+			cnt += process_pmd(pud_pgtable(*pud), osdump_var, sum);
+			if (osdump_var->rem <= 0)
+				break;
+
+		}
+
+		pud++;
+	}
+
+	return cnt;
+}
+#endif
+
+#if CONFIG_PGTABLE_LEVELS >= 4
+static int process_p4d(p4d_t *p4d, struct osdump_variables *osdump_var, int *sum)
+{
+	int i, cnt = 0;
+	struct page *page;
+
+	for (i = 0; i < PTRS_PER_P4D; i++) {
+		if ((p4d_val(*p4d))) {
+			page = p4d_page(*p4d);
+
+			cnt += common_store(page_to_virt(page), page_to_phys(page),
+						PAGE_SIZE, osdump_var, sum);
+			if (osdump_var->rem <= 0)
+				break;
+
+			cnt += process_pud(p4d_pgtable(*p4d), osdump_var, sum);
+			if (osdump_var->rem <= 0)
+				break;
+
+		}
+
+		p4d++;
+	}
+
+	return cnt;
+}
+#endif
+
+#if CONFIG_PGTABLE_LEVELS == 5
+static int process_pgd(pgd_t *pgd, struct osdump_variables *osdump_var, int *sum)
+{
+	int i, cnt = 0;
+	struct page *page;
+
+	for (i = 0; i < PTRS_PER_PGD; i++) {
+		if ((pgd_val(*pgd))) {
+			page = pgd_page(*pgd);
+
+			cnt += common_store(page_to_virt(page), page_to_phys(page),
+						PAGE_SIZE, osdump_var, sum);
+			if (osdump_var->rem <= 0)
+				break;
+
+			cnt += process_p4d(pgd_pgtable(*pgd), osdump_var, sum);
+			if (osdump_var->rem <= 0)
+				break;
+
+		}
+
+		pgd++;
+	}
+
+	return cnt;
+}
+#endif
+
+static int ptl_dump(struct osdump_variables *osdump_var)
+{
+	int cnt = 0, sum = 0;
+
+	struct mm_struct *mm = &init_mm;
+	pgd_t *pgd = mm->pgd;
+
+	cnt += common_store(pgd, virt_to_phys(pgd), PAGE_SIZE, osdump_var, &sum);
+	if (osdump_var->rem <= 0)
+		return cnt;
+
+#if CONFIG_PGTABLE_LEVELS == 5
+	cnt += process_pgd(pgd, osdump_var, &sum);
+#elif CONFIG_PGTABLE_LEVELS == 4
+	cnt += process_p4d((p4d_t *) pgd, osdump_var, &sum);
+#elif CONFIG_PGTABLE_LEVELS == 3
+	cnt += process_pud((pud_t *) pgd, osdump_var, &sum);
+#elif CONFIG_PGTABLE_LEVELS == 2
+	cnt += process_pmd((pmd_t *) pgd, osdump_var, &sum);
+#endif
+
+	return cnt;
+}
+
+static int other_dump(struct osdump_variables *osdump_var)
+{
+	int cpu, len, sum = 0, cnt = 0;
+	void *rq;
+
+	cnt += common_store(_sdata, virt_to_phys(_sdata), _edata - _sdata, osdump_var, &sum);
+	if (osdump_var->rem <= 0)
+		return cnt;
+
+	cnt += common_store(__bss_start, virt_to_phys(__bss_start),
+				__bss_stop - __bss_start, osdump_var, &sum);
+	if (osdump_var->rem <= 0)
+		return cnt;
+
+	cnt += common_store(mem_section, virt_to_phys(mem_section), PAGE_SIZE<<1, osdump_var, &sum);
+	if (osdump_var->rem <= 0)
+		return cnt;
+
+	for_each_online_cpu(cpu) {
+		len = get_rq(cpu, &rq);
+
+		cnt += common_store(rq, virt_to_phys(rq), len, osdump_var, &sum);
+		if (osdump_var->rem <= 0)
+			return cnt;
+
+	}
+
+	return cnt;
+}
+
+static int note_dump(struct osdump_variables *osdump_var)
+{
+	int cnt = 0;
+	int sum = 0;
+
+	cnt += common_store(vmcoreinfo_note, virt_to_phys(vmcoreinfo_note),
+				get_note_size(), osdump_var, &sum);
+
+	return cnt;
+}
+
+
+struct unrecord_struct {
+	const char *name;
+	struct kmem_cache *s;
+};
+
+/*
+ * In certain scenarios, some slab objects may experience abnormally high growth,
+ * which can lead to an excessive increase in memory dump size. or some objects
+ * are unlikely to cause issues, they can be excluded from memory dumps.
+ * This exclusion helps to reduce the overall size of the dump, making crash
+ * analysis more manageable and efficient.
+ */
+static struct unrecord_struct unrecord_slab[] = {
+	[0] = {
+		.name = "dentry",
+	},
+	[1] = {
+		.name = "inode_cache",
+	},
+	[2] = {
+		.name = "ext4_inode_cache",
+	},
+	[3] = {
+		.name = "proc_inode_cache",
+	},
+	[4] = {
+		.name = "kernfs_node_cache",
+	},
+
+	[5] = {
+		.name = "UDP",
+	},
+	[6] = {
+		.name = "TCP",
+	},
+	[7] = {
+		.name = "fs_cache",
+	},
+};
+
+static int slab_dump(struct osdump_variables *osdump_var)
+{
+	int sum = 0, i;
+
+	unsigned long flags;
+	struct kmem_cache *s;
+	struct page *page;
+	struct kmem_cache_node *node;
+	struct list_head *head;
+	struct kmem_cache_cpu *c;
+	struct slab *slab;
+
+	int cnt = 0, cpu;
+	pg_data_t *pgdat;
+
+	if (!mutex_trylock(&slab_mutex)) {
+		pr_err(DUMP_BANNER "can't acquire slab_mutex, just skip dump slab!\n");
+		return 0;
+	}
+
+	list_for_each_entry(s, &slab_caches, list) {
+		for (i = 0; i < ARRAY_SIZE(unrecord_slab); i++) {
+			if (!strcmp(unrecord_slab[i].name, s->name)) {
+				unrecord_slab[i].s = s;
+				break;
+			}
+		}
+
+		if (i != ARRAY_SIZE(unrecord_slab))
+			continue;
+
+		touch_nmi_watchdog();
+		touch_all_softlockup_watchdogs();
+
+		for_each_possible_cpu(cpu) {
+			local_irq_save(flags);
+			c = per_cpu_ptr(s->cpu_slab, cpu);
+
+			slab = READ_ONCE(c->slab);
+			if (!slab) {
+				local_irq_restore(flags);
+				continue;
+			}
+
+			page = slab_page(slab);
+			cnt += common_store(page_to_virt(page), page_to_phys(page),
+					PAGE_SIZE << compound_order(page), osdump_var, &sum);
+			if (osdump_var->rem <= 0) {
+				local_irq_restore(flags);
+				goto out_ret;
+			}
+
+
+#ifdef CONFIG_SLUB_CPU_PARTIAL
+			slab = slub_percpu_partial_read_once(c);
+			while (slab) {
+				page = slab_page(slab);
+				cnt += common_store(page_to_virt(page), page_to_phys(page),
+					PAGE_SIZE << compound_order(page), osdump_var, &sum);
+				if (osdump_var->rem <= 0) {
+					local_irq_restore(flags);
+					goto out_ret;
+				}
+
+				slab = slab->next;
+			}
+#endif
+			local_irq_restore(flags);
+		}
+
+		for_each_online_pgdat(pgdat) {
+			node = s->node[pgdat->node_id];
+
+#ifdef CONFIG_SLAB
+
+			head = &node->slabs_full;
+			list_for_each_entry(slab, head, slab_list) {
+				page = slab_page(slab);
+				cnt += common_store(page_to_virt(page), page_to_phys(page),
+					PAGE_SIZE << compound_order(page), osdump_var, &sum);
+				if (osdump_var->rem <= 0)
+					goto out_ret;
+
+			}
+
+			head = &node->slabs_partial;
+			list_for_each_entry(slab, head, slab_list) {
+				page = slab_page(slab);
+				cnt += common_store(page_to_virt(page), page_to_phys(page),
+					PAGE_SIZE << compound_order(page), osdump_var, &sum);
+				if (osdump_var->rem <= 0)
+					goto out_ret;
+
+			}
+
+#elif CONFIG_SLUB
+			spin_lock_irqsave(&node->list_lock, flags);
+			head = &node->full;
+
+
+			list_for_each_entry(slab, head, slab_list) {
+				page = slab_page(slab);
+				cnt += common_store(page_to_virt(page), page_to_phys(page),
+					PAGE_SIZE << compound_order(page), osdump_var, &sum);
+				if (osdump_var->rem <= 0) {
+					spin_unlock_irqrestore(&node->list_lock, flags);
+					goto out_ret;
+				}
+			}
+
+			spin_unlock_irqrestore(&node->list_lock, flags);
+
+			spin_lock_irqsave(&node->list_lock, flags);
+			head = &node->partial;
+
+			list_for_each_entry(slab, head, slab_list) {
+				page = slab_page(slab);
+				cnt += common_store(page_to_virt(page), page_to_phys(page),
+					PAGE_SIZE << compound_order(page), osdump_var, &sum);
+				if (osdump_var->rem <= 0) {
+					spin_unlock_irqrestore(&node->list_lock, flags);
+					goto out_ret;
+				}
+			}
+
+
+			spin_unlock_irqrestore(&node->list_lock, flags);
+#endif
+
+		}
+
+	}
+
+out_ret:
+	mutex_unlock(&slab_mutex);
+
+	return cnt;
+}
+
+static int dump_mem(struct osdump_variables *osdump_var)
+{
+	int cnt = 0;
+	struct table_hdr *hdr = (struct table_hdr *)(osdump_var->mem_address);
+
+	memset(hdr, 0, sizeof(struct table_hdr));
+
+	osdump_var->rem = osdump_var->mem_size - MDUMP_HDR_SIZE;
+	osdump_var->dst = (void *)osdump_var->mem_address + MDUMP_HDR_SIZE;
+	osdump_var->meta_end = (void *)osdump_var->mem_address + MDUMP_HDR_SIZE -
+				sizeof(struct table_entry);
+	osdump_var->meta = (void *)osdump_var->mem_address + sizeof(struct table_hdr);
+
+
+	if (osdump_var->rem <= 0)
+		goto out;
+
+	cnt += note_dump(osdump_var);
+	if (osdump_var->rem <= 0)
+		goto out;
+
+	cnt += other_dump(osdump_var);
+	if (osdump_var->rem <= 0)
+		goto out;
+
+	cnt += stack_dump(osdump_var);
+	if (osdump_var->rem <= 0)
+		goto out;
+
+	cnt += slab_dump(osdump_var);
+	if (osdump_var->rem <= 0)
+		goto out;
+
+	cnt += ptl_dump(osdump_var);
+
+out:
+	hdr->count = htonl(cnt);
+	hdr->size = htonl(osdump_var->dst - (void *)osdump_var->mem_address);
+	strscpy(hdr->magic, MDUMP_MAGIC, strlen(MDUMP_MAGIC));
+	hdr->checksum = cal_checksum(hdr);
+
+	return cnt;
+}
+
+int osdump(void)
+{
+	int ret = 0;
+
+	ret = dump_mem(&osdump_var);
+	if (ret < 0) {
+		pr_err(DUMP_BANNER "dump mem failed!\n");
+		return -1;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(osdump);
+
+static void *persistent_ram_vmap(phys_addr_t start, size_t size,
+		unsigned int memtype)
+{
+	struct page **pages;
+	phys_addr_t page_start;
+	unsigned int page_count;
+	pgprot_t prot;
+	unsigned int i;
+	void *vaddr;
+
+	page_start = start - offset_in_page(start);
+	page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
+
+	if (memtype)
+		prot = pgprot_noncached(PAGE_KERNEL);
+	else
+		prot = pgprot_writecombine(PAGE_KERNEL);
+
+	pages = kmalloc_array(page_count, sizeof(struct page *), GFP_KERNEL);
+	if (!pages)
+		return NULL;
+
+	for (i = 0; i < page_count; i++) {
+		phys_addr_t addr = page_start + i * PAGE_SIZE;
+
+		pages[i] = pfn_to_page(addr >> PAGE_SHIFT);
+	}
+	vaddr = vmap(pages, page_count, VM_MAP, prot);
+	kfree(pages);
+
+	/*
+	 * Since vmap() uses page granularity, we must add the offset
+	 * into the page here, to get the byte granularity address
+	 * into the mapping to represent the actual "start" location.
+	 */
+	return vaddr + offset_in_page(start);
+}
+
+static int osdump_parse_dt(struct platform_device *pdev, struct osdump_variables *pdata)
+{
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		pr_err(DUMP_BANNER "failed to locate DT /reserved-memory resource!\n");
+		return -EINVAL;
+	}
+
+	pdata->mem_address = persistent_ram_vmap(res->start, resource_size(res), 0);
+	pdata->mem_size = resource_size(res);
+
+	return 0;
+}
+
+static int osdump_probe(struct platform_device *pdev)
+{
+	struct device *dev;
+
+	dev = &pdev->dev;
+	dev->platform_data = &osdump_var;
+
+	if (dev_of_node(dev))
+		osdump_parse_dt(pdev, &osdump_var);
+
+	return 0;
+}
+
+static int osdump_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+
+static const struct of_device_id osdump_of_match[] = {
+	{ .compatible = "osdump", },
+	{}
+};
+
+static struct platform_driver osdump_driver = {
+	.probe = osdump_probe,
+	.remove = osdump_remove,
+	.driver = {
+		.name = OS_DUMP,
+		.of_match_table = osdump_of_match,
+	},
+};
+
+static int __init osdump_init(void)
+{
+	return platform_driver_register(&osdump_driver);
+}
+postcore_initcall(osdump_init);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("os minidump driver");
+MODULE_AUTHOR("qiruipeng");
diff --git a/kernel/osdump/extern.h b/kernel/osdump/extern.h
new file mode 100644
index 000000000000..da0d25ef4662
--- /dev/null
+++ b/kernel/osdump/extern.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_OS_MINIDUMP_EXTERN_H
+#define _LINUX_OS_MINIDUMP_EXTERN_H
+
+extern struct kmem_cache *task_struct_cachep;
+extern size_t big_oops_buf_sz;
+extern int osdump_compress(const void *in, void *out, int size, int *left);
+extern int get_rq(int cpu, void **rq);
+extern u32 *vmcoreinfo_note;
+extern int get_note_size(void);
+
+#endif
diff --git a/kernel/osdump/inode.c b/kernel/osdump/inode.c
new file mode 100644
index 000000000000..9356c4b8795f
--- /dev/null
+++ b/kernel/osdump/inode.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Interface for accessing the crash dump from the system's previous life.
+ */
+#include <linux/module.h>
+#include <linux/proc_fs.h>
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include "internal.h"
+
+struct inode_priv {
+	void *addr;
+	size_t size;
+	struct proc_dir_entry *proc_osdump;
+};
+static struct inode_priv *inode_priv;
+
+static ssize_t osdump_read(struct file *file, char __user *buf,
+		size_t count, loff_t *ppos)
+{
+	if (!inode_priv)
+		return 0;
+
+	return simple_read_from_buffer(buf, count, ppos, inode_priv->addr, inode_priv->size);
+}
+
+static const struct proc_ops osdump_proc_ops = {
+	.proc_read = osdump_read,
+	.proc_lseek = default_llseek,
+};
+
+static int __init osdump_init_fs(void)
+{
+	int ret = 0;
+	struct table_hdr *hdr;
+
+	inode_priv = kzalloc(sizeof(struct inode_priv), GFP_KERNEL);
+	if (!inode_priv)
+		return -ENOMEM;
+
+	hdr = (struct table_hdr *)osdump_var.mem_address;
+	if (!hdr_valid(hdr))
+		goto err;
+
+	inode_priv->addr = hdr;
+	inode_priv->size = ntohl(hdr->size);
+
+	inode_priv->proc_osdump = proc_create("osdump", 0400, NULL, &osdump_proc_ops);
+	if (!inode_priv->proc_osdump) {
+		ret = -ENOENT;
+		pr_err(DUMP_BANNER "osdump create inode failed!\n");
+		goto err;
+	}
+
+	return 0;
+
+err:
+	kfree(inode_priv);
+	inode_priv = NULL;
+
+	return ret;
+}
+fs_initcall(osdump_init_fs);
+
+void osdump_cleanup_fs(void)
+{
+	if (inode_priv && inode_priv->proc_osdump) {
+		proc_remove(inode_priv->proc_osdump);
+		inode_priv->proc_osdump = NULL;
+	}
+
+	kfree(inode_priv);
+	inode_priv = NULL;
+}
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("qiruipeng");
diff --git a/kernel/osdump/internal.h b/kernel/osdump/internal.h
new file mode 100644
index 000000000000..5dc09fe37295
--- /dev/null
+++ b/kernel/osdump/internal.h
@@ -0,0 +1,95 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef	_LINUX_OS_MINIDUMP_INTERNAL_H
+#define	_LINUX_OS_MINIDUMP_INTERNAL_H
+
+/*
+ * We only dump the data we are interested in, each of which represents
+ * a continuous region - this could be a structure or pages of data. These
+ * data are compressed first and then stored into one or several entries,
+ * each with a maximum size of 32K.
+ *
+ * We use reserved memory to store these dump data, referred to as
+ * 'dump region'. This region consists of two parts: The first part records
+ * the meta info and is thus, known as the 'meta region' and the second part
+ * stores the raw data in sequence and is known as the 'data region'.
+ *
+ * At the beginning of the meta region lies a header that records the total
+ * size and count of entries. Following the header, there's a table which
+ * holds metadata for each entry. This metadata records the physical address
+ * of the dumped data in memory, in addition to the offset and size of the
+ * data stored in the dump region.
+ *
+ * The second part of the dump region stores compressed data for each entry
+ * in an orderly manner.
+ */
+
+// fixed size for meta region.
+#define MDUMP_HDR_SIZE		(192*1024)
+#define MDUMP_MAGIC		"osdump"
+#define DUMP_BANNER		"osdump: "
+
+#define CRYPTO_SIZE		(PAGE_SIZE << 3)
+
+struct table_hdr {
+	/* entries count */
+	unsigned int count;
+	/* total size */
+	unsigned int size;
+	/* for aligned */
+	union {
+		int reserve[2];
+		struct {
+			char magic[7];
+			unsigned char  checksum;
+		};
+	};
+};
+
+struct table_entry {
+	/*  offset in dump region */
+	unsigned int start;
+	unsigned int size;
+	/* physical addr in memory */
+	unsigned long long src;
+};
+
+/*
+ * Runtime information: this struct save the runtime information used for
+ * os minidump.
+ */
+struct osdump_variables {
+	/* virtual addr for dump region */
+	void           *mem_address;
+	/* total size for dump data */
+	unsigned long   mem_size;
+	/* curr entry's metadata */
+	struct table_entry *meta;
+	/* last metadata */
+	struct table_entry *meta_end;
+	/* remain size for dump data */
+	int             rem;
+	/* addr stored  in dump region */
+	void            *dst;
+};
+
+
+extern struct osdump_variables osdump_var;
+
+static inline unsigned char cal_checksum(struct table_hdr *hdr)
+{
+	int i, len = sizeof(struct table_hdr) - 1;
+	unsigned char ch = 0, *ptr = (unsigned char *)hdr;
+
+	for (i = 0; i < len; i++)
+		ch += ptr[i];
+
+	return ch;
+}
+
+static inline bool hdr_valid(struct table_hdr *hdr)
+{
+	return !strncmp(MDUMP_MAGIC, hdr->magic, strlen(MDUMP_MAGIC)) &&
+						hdr->checksum == cal_checksum(hdr);
+}
+#endif
-- 
2.17.1



From xu.yang_2 at nxp.com  Thu Dec 21 05:13:00 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 21 Dec 2023 13:13:00 +0000
Subject: [EXT] Re: [PATCH v2 3/5] dt-bindings: usb: ci-hdrc-usb2: add
 compatible and clock-names restriction for imx93
In-Reply-To: <e3ca4b8e-7e5b-4e0d-963d-e020729cab6c@linaro.org>
References: <20231218085456.3962720-1-xu.yang_2@nxp.com>
 <20231218085456.3962720-3-xu.yang_2@nxp.com>
 <eb93c554-ee35-49a0-adfb-0d3030f9a77b@linaro.org>
 <DB7PR04MB5146154E6C62BCFCDA7879F38C96A@DB7PR04MB5146.eurprd04.prod.outlook.com>
 <e3ca4b8e-7e5b-4e0d-963d-e020729cab6c@linaro.org>
Message-ID: <DB7PR04MB5146920CF37DBF212199C1958C95A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Krzysztof,

> 
> On 20/12/2023 03:23, Xu Yang wrote:
> >>> +  - if:
> >>> +      properties:
> >>> +        compatible:
> >>> +          contains:
> >>> +            const: fsl,imx93-usb
> >>> +    then:
> >>> +      properties:
> >>> +        clock-names:
> >>> +          items:
> >>> +            - const: usb_ctrl_root_clk
> >>> +            - const: usb_wakeup_clk
> >>
> >> What about all the reset? reg, interrupts? Maybe it is time to split the
> >> schema into common part and device-specific.
> >
> > Why I need to consider reset, reg and interrupts? Should I add restrictions on
> > these too? I may not really understand your meaning.
> 
> I looked at the binding and it seems that you allow different number of
> items for them. Why aren't these constrained for your device?

Well, understood now. I should add number of clocks and clock-names
for my case. However, reset, reg and interrupts property is not special
for imx93.

Thanks,
Xu Yang

> 
> Best regards,
> Krzysztof


From konrad.dybcio at linaro.org  Thu Dec 21 05:16:30 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Thu, 21 Dec 2023 14:16:30 +0100
Subject: [PATCH 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX
 handler
In-Reply-To: <CAA8EJpoEqKv_rWB8468WJzxqPA5w7u_zmGJJ0oKWAyaB9-f0eQ@mail.gmail.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
 <20231220-sa8295p-gpu-v1-2-d8cdf2257f97@quicinc.com>
 <8d206362-7d80-46dc-8474-871fc53abc20@linaro.org>
 <CAA8EJpoEqKv_rWB8468WJzxqPA5w7u_zmGJJ0oKWAyaB9-f0eQ@mail.gmail.com>
Message-ID: <35845077-7839-41bf-9eca-82f8b0be29ec@linaro.org>

On 21.12.2023 14:04, Dmitry Baryshkov wrote:
> On Thu, 21 Dec 2023 at 15:01, Konrad Dybcio <konrad.dybcio at linaro.org> wrote:
>>
>> On 21.12.2023 04:50, Bjorn Andersson wrote:
>>> The GX GDSC is modelled to aid the GMU in powering down the GPU in the
>>> event that the GPU crashes, so that it can be restarted again. But in
>>> the event that the power-domain is supplied through a dedicated
>>> regulator (in contrast to being a subdomin of another power-domain),
>>> something needs to turn that regulator on, both to make sure things are
>>> powered and to match the operation in gdsc_disable().
>>>
>>> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
>>> ---
>>>  drivers/clk/qcom/gdsc.c | 8 +++++++-
>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>>> index 5358e28122ab..d1139c895503 100644
>>> --- a/drivers/clk/qcom/gdsc.c
>>> +++ b/drivers/clk/qcom/gdsc.c
>>> @@ -557,7 +557,13 @@ void gdsc_unregister(struct gdsc_desc *desc)
>>>   */
>>>  int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
>> I suppose the name is confusing now..
>>
>> But at the same time I can't come up with anything that's less than
>> like 6 words..
> 
> gdsc_gx_enable() ;-)
except not really only gx and not really enable :(

gdsc_shared_enable would probably be closer to our current
nomenclature..

Konrad


From konrad.dybcio at linaro.org  Thu Dec 21 05:17:04 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Thu, 21 Dec 2023 14:17:04 +0100
Subject: [PATCH 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX
 handler
In-Reply-To: <35845077-7839-41bf-9eca-82f8b0be29ec@linaro.org>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
 <20231220-sa8295p-gpu-v1-2-d8cdf2257f97@quicinc.com>
 <8d206362-7d80-46dc-8474-871fc53abc20@linaro.org>
 <CAA8EJpoEqKv_rWB8468WJzxqPA5w7u_zmGJJ0oKWAyaB9-f0eQ@mail.gmail.com>
 <35845077-7839-41bf-9eca-82f8b0be29ec@linaro.org>
Message-ID: <9f227687-5760-4169-a86d-008f393de949@linaro.org>

On 21.12.2023 14:16, Konrad Dybcio wrote:
> On 21.12.2023 14:04, Dmitry Baryshkov wrote:
>> On Thu, 21 Dec 2023 at 15:01, Konrad Dybcio <konrad.dybcio at linaro.org> wrote:
>>>
>>> On 21.12.2023 04:50, Bjorn Andersson wrote:
>>>> The GX GDSC is modelled to aid the GMU in powering down the GPU in the
>>>> event that the GPU crashes, so that it can be restarted again. But in
>>>> the event that the power-domain is supplied through a dedicated
>>>> regulator (in contrast to being a subdomin of another power-domain),
>>>> something needs to turn that regulator on, both to make sure things are
>>>> powered and to match the operation in gdsc_disable().
>>>>
>>>> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
>>>> ---
>>>>  drivers/clk/qcom/gdsc.c | 8 +++++++-
>>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>>>> index 5358e28122ab..d1139c895503 100644
>>>> --- a/drivers/clk/qcom/gdsc.c
>>>> +++ b/drivers/clk/qcom/gdsc.c
>>>> @@ -557,7 +557,13 @@ void gdsc_unregister(struct gdsc_desc *desc)
>>>>   */
>>>>  int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
>>> I suppose the name is confusing now..
>>>
>>> But at the same time I can't come up with anything that's less than
>>> like 6 words..
>>
>> gdsc_gx_enable() ;-)
> except not really only gx and not really enable :(
> 
> gdsc_shared_enable would probably be closer to our current
> nomenclature..
but then VOTABLE also taps into the concept of "shared" :/

Konrad


From dmitry.baryshkov at linaro.org  Thu Dec 21 05:17:31 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 15:17:31 +0200
Subject: [PATCH RESEND v1 4/8] drm/stm: ltdc: implement bus clock
In-Reply-To: <20231221124339.420119-5-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com> <20231221124339.420119-5-raphael.gallais-pou@foss.st.com>
Message-ID: <CAA8EJpq-NWUEe8QbUwDHu0BBSViWKh92PujD7PA84xgvSUsvhg@mail.gmail.com>

On Thu, 21 Dec 2023 at 14:45, Raphael Gallais-Pou
<raphael.gallais-pou at foss.st.com> wrote:
>
> From: Yannick Fertre <yannick.fertre at foss.st.com>
>
> The latest hardware version of the LTDC presents the addition of a bus
> clock, which contains the global configuration registers and the interrupt
> register.
>
> Signed-off-by: Yannick Fertre <yannick.fertre at foss.st.com>
> ---
>  drivers/gpu/drm/stm/ltdc.c | 8 ++++++++
>  drivers/gpu/drm/stm/ltdc.h | 1 +
>  2 files changed, 9 insertions(+)

I might be missing something, but I don't see this clock being set
(compare this patch to the patch 5/8)

>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 5576fdae4962..67064f47a4cb 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -1896,6 +1896,8 @@ void ltdc_suspend(struct drm_device *ddev)
>
>         DRM_DEBUG_DRIVER("\n");
>         clk_disable_unprepare(ldev->pixel_clk);
> +       if (ldev->bus_clk)
> +               clk_disable_unprepare(ldev->bus_clk);
>  }
>
>  int ltdc_resume(struct drm_device *ddev)
> @@ -1910,6 +1912,12 @@ int ltdc_resume(struct drm_device *ddev)
>                 DRM_ERROR("failed to enable pixel clock (%d)\n", ret);
>                 return ret;
>         }
> +       if (ldev->bus_clk) {
> +               if (clk_prepare_enable(ldev->bus_clk)) {
> +                       DRM_ERROR("Unable to prepare bus clock\n");
> +                       return -ENODEV;
> +               }
> +       }
>
>         return 0;
>  }
> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
> index 9d488043ffdb..155d8e4a7c6b 100644
> --- a/drivers/gpu/drm/stm/ltdc.h
> +++ b/drivers/gpu/drm/stm/ltdc.h
> @@ -44,6 +44,7 @@ struct ltdc_device {
>         void __iomem *regs;
>         struct regmap *regmap;
>         struct clk *pixel_clk;  /* lcd pixel clock */
> +       struct clk *bus_clk;    /* bus clock */
>         struct mutex err_lock;  /* protecting error_status */
>         struct ltdc_caps caps;
>         u32 irq_status;
> --
> 2.25.1
>


-- 
With best wishes
Dmitry


From dmitry.baryshkov at linaro.org  Thu Dec 21 05:18:49 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Thu, 21 Dec 2023 15:18:49 +0200
Subject: [PATCH 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX handler
In-Reply-To: <35845077-7839-41bf-9eca-82f8b0be29ec@linaro.org>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
 <20231220-sa8295p-gpu-v1-2-d8cdf2257f97@quicinc.com> <8d206362-7d80-46dc-8474-871fc53abc20@linaro.org>
 <CAA8EJpoEqKv_rWB8468WJzxqPA5w7u_zmGJJ0oKWAyaB9-f0eQ@mail.gmail.com> <35845077-7839-41bf-9eca-82f8b0be29ec@linaro.org>
Message-ID: <CAA8EJppr0+=JxzXP1e9uP=8mGwCwWyi4wTYkM0ORm1Uf+2FPMA@mail.gmail.com>

On Thu, 21 Dec 2023 at 15:16, Konrad Dybcio <konrad.dybcio at linaro.org> wrote:
>
> On 21.12.2023 14:04, Dmitry Baryshkov wrote:
> > On Thu, 21 Dec 2023 at 15:01, Konrad Dybcio <konrad.dybcio at linaro.org> wrote:
> >>
> >> On 21.12.2023 04:50, Bjorn Andersson wrote:
> >>> The GX GDSC is modelled to aid the GMU in powering down the GPU in the
> >>> event that the GPU crashes, so that it can be restarted again. But in
> >>> the event that the power-domain is supplied through a dedicated
> >>> regulator (in contrast to being a subdomin of another power-domain),
> >>> something needs to turn that regulator on, both to make sure things are
> >>> powered and to match the operation in gdsc_disable().
> >>>
> >>> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> >>> ---
> >>>  drivers/clk/qcom/gdsc.c | 8 +++++++-
> >>>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> >>> index 5358e28122ab..d1139c895503 100644
> >>> --- a/drivers/clk/qcom/gdsc.c
> >>> +++ b/drivers/clk/qcom/gdsc.c
> >>> @@ -557,7 +557,13 @@ void gdsc_unregister(struct gdsc_desc *desc)
> >>>   */
> >>>  int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
> >> I suppose the name is confusing now..
> >>
> >> But at the same time I can't come up with anything that's less than
> >> like 6 words..
> >
> > gdsc_gx_enable() ;-)
> except not really only gx and not really enable :(
>
> gdsc_shared_enable would probably be closer to our current
> nomenclature..

gdsc_dummy_gx_enable*(

Or gdsc_dummy_gmu_gx_enable(). Still less than 6 words. I'm trying my best!


-- 
With best wishes
Dmitry


From catalin.marinas at arm.com  Thu Dec 21 05:19:18 2023
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 21 Dec 2023 13:19:18 +0000
Subject: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for
 vfio pci devices
In-Reply-To: <ZXszoQ48pZ7FnQNV@linux.dev>
References: <20231208164709.23101-1-ankita@nvidia.com>
 <20231208164709.23101-3-ankita@nvidia.com>
 <ZXicemDzXm8NShs1@arm.com>
 <20231212181156.GO3014157@nvidia.com>
 <ZXoOieQN7rBiLL4A@linux.dev>
 <ZXsjv+svp44YjMmh@lpieralisi>
 <ZXszoQ48pZ7FnQNV@linux.dev>
Message-ID: <ZYQ7VjApH1v1QwTW@arm.com>

Catching up on emails before going on holiday (again).

On Thu, Dec 14, 2023 at 04:56:01PM +0000, Oliver Upton wrote:
> On Thu, Dec 14, 2023 at 04:48:15PM +0100, Lorenzo Pieralisi wrote:
> > > AFAICT, the only reason PCI devices can get the blanket treatment of
> > > Normal-NC at stage-2 is because userspace has a Device-* mapping and can't
> > > speculatively load from the alias. This feels a bit hacky, and maybe we
> > > should prioritize an interface for mapping a device into a VM w/o a
> > > valid userspace mapping.
> > 
> > FWIW - I have tried to summarize the reasoning behind PCIe devices
> > Normal-NC default stage-2 safety in a document that I have just realized
> > now it has become this series cover letter, I don't think the PCI blanket
> > treatment is related *only* to the current user space mappings (ie
> > BTW, AFAICS it is also *possible* at present to map a prefetchable BAR through
> > sysfs with Normal-NC memory attributes in the host at the same time a PCI
> > device is passed-through to a guest with VFIO - and therefore we have a
> > dev-nGnRnE stage-1 mapping for it. Don't think anyone does that - what for -
> > but it is possible and KVM would not know about it).
> > 
> > Again, FWIW, we were told (source Arm ARM) mismatched aliases concerning
> > device-XXX vs Normal-NC are not problematic as long as the transactions
> > issued for the related mappings are independent (and none of the
> > mappings is cacheable).
> > 
> > I appreciate this is not enough to give everyone full confidence on
> > this solution robustness - that's why I wrote that up so that we know
> > what we are up against and write KVM interfaces accordingly.
> 
> Apologies, I didn't mean to question what's going on here from the
> hardware POV. My concern was more from the kernel + user interfaces POV,
> this all seems to work (specifically for PCI) by maintaining an
> intentional mismatch between the VFIO stage-1 and KVM stage-2 mappings.

If you stare at it long enough, the mismatch starts to look fine ;).
Even if you have the VFIO stage 1 Normal NC, KVM stage 2 Normal NC, you
can still have the guest setting stage 1 to Device and introduce an
architectural mismatch. These aliases have some bad reputation but the
behaviour is constrained architecturally.

IMHO we should move on from this attribute mismatch since we can't fully
solve it anyway and focus instead on what the device, system can
tolerate, who's responsible for deciding which MMIO ranges can be mapped
as Normal NC. There are a few options here (talking in the PCIe context
but it can be extended to other VFIO mappings):

1. The VMM is responsible for intra-BAR relaxation of the KVM stage 2:
   a) via the stage 1 VFIO mapping attributes - Device or Normal
   b) via other means (e.g. ioctl(<range>)) while the stage 1 VFIO stays
      Device

2. KVM decides the intra-BAR relaxation irrespective of the VFIO stage 1
   attributes (VMM mapping)

3. KVM decides the full-BAR relaxation with the guest responsible for
   the intra-BAR attributes. As with (2), that's irrespective of the
   VFIO stage 1 host mapping

Whichever option we pick, it won't be the host forcing the Normal NC
mapping, that's still a guest decision and the host only allowing it.

(1) needs specific device knowledge in the VMM or a VFIO-specific driver
(or both if the VMM isn't fully trusted to request the right
attributes). (2) moves the device-specific knowledge to KVM or a
combination of KVM and VFIO-specific driver. Things can get a lot worse
if the Device vs Normal ranges within a BAR are configurable and needs
some paravirtualised interface for the guest to agree with the host.

These patches aim for (3) but only if the host VFIO driver deems it safe
(hence PCIe only for now). I find this an acceptable compromise.

If we really want to avoid any aliases (though I think we are spending
too many cycles on something that's not a real issue), the only way is
to have fd-based mappings in KVM so that there's no VMM alias. After
that we need to choose between (2) and (3) since the VMM may no longer
be able to probe the device and figure out which ranges need what
attributes.

> If we add more behind-the-scenes tricks to get other MMIO mappings
> working in the future then this whole interaction will get even
> hairier. At least if we follow the stage-1 attributes (where possible)
> then we can document some sort of expected behavior in KVM. The VMM would
> need know if the device has read side-effects, as the only way to get a
> Normal-NC mapping in the guest would be to have one at stage-1.

I don't think KVM or the VMM should attempt to hand-hold the guest and
ensure that it maps an MMIO with read side-effects appropriately. The
guest driver can do this by itself or get incorrect hw behaviour. Such
hand-holding is only needed if the speculative loads have wider system
implications but we concluded that it's not the case for PCIe. Even with
a Device mapping, the guest can always issue random reads from an
assigned MMIO range and cause side-effects.

> Kinda stinks to make the VMM aware of the device, but IMO it is a
> fundamental limitation of the way we back memslots right now.

As I mentioned above, the limitation may be more complex if the
intra-BAR attributes are not something readily available in the device
documentation. Maybe Jason or Ankit can shed some light here: are those
intra-BAR ranges configurable by the (guest) driver or they are already
pre-configured by firmware and the driver only needs to probe them?

Anyway, about to go on the Christmas break, so most likely I'll follow
up in January. Happy holidays!

-- 
Catalin


From ruipengqi7 at gmail.com  Thu Dec 21 05:25:22 2023
From: ruipengqi7 at gmail.com (Ruipeng Qi)
Date: Thu, 21 Dec 2023 21:25:22 +0800
Subject: [RFC PATCH 2/7] osdump: reuse some code from crash_core to get vmcoreinfo
Message-ID: <20231221132522.547-1-ruipengqi7@gmail.com>

From: qiruipeng <qiruipeng at lixiang.com>

Osdump is a new crash dumping solution like crash. It is interested in
vmcoreinfo,too. Reuse some data and function from crash_core, but not full
of them. So pick some code to get vmcoreinfo as needed.

Signed-off-by: qiruipeng <qiruipeng at lixiang.com>
---
 arch/arm64/kernel/Makefile |   1 +
 include/linux/buildid.h    |   3 +-
 kernel/Makefile            |   1 +
 kernel/crash_core_mini.c   | 275 +++++++++++++++++++++++++++++++++++++
 kernel/printk/printk.c     |   2 +-
 lib/buildid.c              |   3 +-
 6 files changed, 282 insertions(+), 3 deletions(-)
 create mode 100644 kernel/crash_core_mini.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index d95b3d6b471a..fd6d06e44ae2 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_ARM64_RELOC_TEST)		+= arm64-reloc-test.o
 arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
 obj-$(CONFIG_CRASH_DUMP)		+= crash_dump.o
 obj-$(CONFIG_CRASH_CORE)		+= crash_core.o
+obj-$(CONFIG_OS_MINIDUMP)              += crash_core.o
 obj-$(CONFIG_ARM_SDE_INTERFACE)		+= sdei.o
 obj-$(CONFIG_ARM64_PTR_AUTH)		+= pointer_auth.o
 obj-$(CONFIG_ARM64_MTE)			+= mte.o
diff --git a/include/linux/buildid.h b/include/linux/buildid.h
index 8a582d242f06..157edba44068 100644
--- a/include/linux/buildid.h
+++ b/include/linux/buildid.h
@@ -11,7 +11,8 @@ int build_id_parse(struct vm_area_struct *vma, unsigned char *build_id,
 		   __u32 *size);
 int build_id_parse_buf(const void *buf, unsigned char *build_id, u32 buf_size);
 
-#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) || IS_ENABLED(CONFIG_CRASH_CORE)
+#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) || IS_ENABLED(CONFIG_CRASH_CORE) \
+	|| IS_ENABLED(CONFIG_OS_MINIDUMP)
 extern unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX];
 void init_vmlinux_build_id(void);
 #else
diff --git a/kernel/Makefile b/kernel/Makefile
index dc2b4ba5c953..14b7002f3279 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_KALLSYMS) += kallsyms.o
 obj-$(CONFIG_KALLSYMS_SELFTEST) += kallsyms_selftest.o
 obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
 obj-$(CONFIG_CRASH_CORE) += crash_core.o
+obj-$(CONFIG_OS_MINIDUMP) += crash_core_mini.o
 obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC_FILE) += kexec_file.o
diff --git a/kernel/crash_core_mini.c b/kernel/crash_core_mini.c
new file mode 100644
index 000000000000..a0f8d0c79bba
--- /dev/null
+++ b/kernel/crash_core_mini.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * crash.c - kernel crash support code.
+ * Copyright (C) 2002-2004 Eric Biederman  <ebiederm at xmission.com>
+ */
+
+#include <linux/buildid.h>
+#include <linux/init.h>
+#include <linux/utsname.h>
+#include <linux/vmalloc.h>
+#include <linux/sizes.h>
+#include <linux/kexec.h>
+#include <linux/memory.h>
+#include <linux/cpuhotplug.h>
+#include <linux/memblock.h>
+#include <linux/kexec.h>
+#include <linux/kmemleak.h>
+
+#include <asm/page.h>
+#include <asm/sections.h>
+
+#include <crypto/sha1.h>
+
+#include "kallsyms_internal.h"
+#include "kexec_internal.h"
+
+/* Per cpu memory for storing cpu states in case of system crash. */
+note_buf_t __percpu *crash_notes;
+
+/* vmcoreinfo stuff */
+unsigned char *vmcoreinfo_data;
+size_t vmcoreinfo_size;
+u32 *vmcoreinfo_note;
+
+/* trusted vmcoreinfo, e.g. we can make a copy in the crash memory */
+static unsigned char *vmcoreinfo_data_safecopy;
+
+
+Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
+			  void *data, size_t data_len)
+{
+	struct elf_note *note = (struct elf_note *)buf;
+
+	note->n_namesz = strlen(name) + 1;
+	note->n_descsz = data_len;
+	note->n_type   = type;
+	buf += DIV_ROUND_UP(sizeof(*note), sizeof(Elf_Word));
+	memcpy(buf, name, note->n_namesz);
+	buf += DIV_ROUND_UP(note->n_namesz, sizeof(Elf_Word));
+	memcpy(buf, data, data_len);
+	buf += DIV_ROUND_UP(data_len, sizeof(Elf_Word));
+
+	return buf;
+}
+
+void final_note(Elf_Word *buf)
+{
+	memset(buf, 0, sizeof(struct elf_note));
+}
+
+static void update_vmcoreinfo_note(void)
+{
+	u32 *buf = vmcoreinfo_note;
+
+	if (!vmcoreinfo_size)
+		return;
+	buf = append_elf_note(buf, VMCOREINFO_NOTE_NAME, 0, vmcoreinfo_data,
+			      vmcoreinfo_size);
+	final_note(buf);
+}
+
+void crash_update_vmcoreinfo_safecopy(void *ptr)
+{
+	if (ptr)
+		memcpy(ptr, vmcoreinfo_data, vmcoreinfo_size);
+
+	vmcoreinfo_data_safecopy = ptr;
+}
+
+void crash_save_vmcoreinfo(void)
+{
+	if (!vmcoreinfo_note)
+		return;
+
+	/* Use the safe copy to generate vmcoreinfo note if have */
+	if (vmcoreinfo_data_safecopy)
+		vmcoreinfo_data = vmcoreinfo_data_safecopy;
+
+	vmcoreinfo_append_str("CRASHTIME=%lld\n", ktime_get_real_seconds());
+	update_vmcoreinfo_note();
+}
+
+void vmcoreinfo_append_str(const char *fmt, ...)
+{
+	va_list args;
+	char buf[0x50];
+	size_t r;
+
+	va_start(args, fmt);
+	r = vscnprintf(buf, sizeof(buf), fmt, args);
+	va_end(args);
+
+	r = min(r, (size_t)VMCOREINFO_BYTES - vmcoreinfo_size);
+
+	memcpy(&vmcoreinfo_data[vmcoreinfo_size], buf, r);
+
+	vmcoreinfo_size += r;
+
+	WARN_ONCE(vmcoreinfo_size == VMCOREINFO_BYTES,
+		  "vmcoreinfo data exceeds allocated size, truncating");
+}
+
+/*
+ * provide an empty default implementation here -- architecture
+ * code may override this
+ */
+void __weak arch_crash_save_vmcoreinfo(void)
+{}
+
+phys_addr_t __weak paddr_vmcoreinfo_note(void)
+{
+	return __pa(vmcoreinfo_note);
+}
+EXPORT_SYMBOL(paddr_vmcoreinfo_note);
+
+int get_note_size(void)
+{
+	return VMCOREINFO_NOTE_SIZE;
+}
+
+static int __init crash_save_vmcoreinfo_init(void)
+{
+	vmcoreinfo_data = (unsigned char *)get_zeroed_page(GFP_KERNEL);
+	if (!vmcoreinfo_data) {
+		pr_warn("Memory allocation for vmcoreinfo_data failed\n");
+		return -ENOMEM;
+	}
+
+	vmcoreinfo_note = alloc_pages_exact(VMCOREINFO_NOTE_SIZE,
+						GFP_KERNEL | __GFP_ZERO);
+	if (!vmcoreinfo_note) {
+		free_page((unsigned long)vmcoreinfo_data);
+		vmcoreinfo_data = NULL;
+		pr_warn("Memory allocation for vmcoreinfo_note failed\n");
+		return -ENOMEM;
+	}
+
+	VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
+	VMCOREINFO_BUILD_ID();
+	VMCOREINFO_PAGESIZE(PAGE_SIZE);
+
+	VMCOREINFO_SYMBOL(init_uts_ns);
+	VMCOREINFO_OFFSET(uts_namespace, name);
+	VMCOREINFO_SYMBOL(node_online_map);
+#ifdef CONFIG_MMU
+	VMCOREINFO_SYMBOL_ARRAY(swapper_pg_dir);
+#endif
+	VMCOREINFO_SYMBOL(_stext);
+	VMCOREINFO_SYMBOL(vmap_area_list);
+
+#ifndef CONFIG_NUMA
+	VMCOREINFO_SYMBOL(mem_map);
+	VMCOREINFO_SYMBOL(contig_page_data);
+#endif
+#ifdef CONFIG_SPARSEMEM
+	VMCOREINFO_SYMBOL_ARRAY(mem_section);
+	VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
+	VMCOREINFO_STRUCT_SIZE(mem_section);
+	VMCOREINFO_OFFSET(mem_section, section_mem_map);
+	VMCOREINFO_NUMBER(SECTION_SIZE_BITS);
+	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
+#endif
+	VMCOREINFO_STRUCT_SIZE(page);
+	VMCOREINFO_STRUCT_SIZE(pglist_data);
+	VMCOREINFO_STRUCT_SIZE(zone);
+	VMCOREINFO_STRUCT_SIZE(free_area);
+	VMCOREINFO_STRUCT_SIZE(list_head);
+	VMCOREINFO_SIZE(nodemask_t);
+	VMCOREINFO_OFFSET(page, flags);
+	VMCOREINFO_OFFSET(page, _refcount);
+	VMCOREINFO_OFFSET(page, mapping);
+	VMCOREINFO_OFFSET(page, lru);
+	VMCOREINFO_OFFSET(page, _mapcount);
+	VMCOREINFO_OFFSET(page, private);
+	VMCOREINFO_OFFSET(page, compound_head);
+	VMCOREINFO_OFFSET(pglist_data, node_zones);
+	VMCOREINFO_OFFSET(pglist_data, nr_zones);
+#ifdef CONFIG_FLATMEM
+	VMCOREINFO_OFFSET(pglist_data, node_mem_map);
+#endif
+	VMCOREINFO_OFFSET(pglist_data, node_start_pfn);
+	VMCOREINFO_OFFSET(pglist_data, node_spanned_pages);
+	VMCOREINFO_OFFSET(pglist_data, node_id);
+	VMCOREINFO_OFFSET(zone, free_area);
+	VMCOREINFO_OFFSET(zone, vm_stat);
+	VMCOREINFO_OFFSET(zone, spanned_pages);
+	VMCOREINFO_OFFSET(free_area, free_list);
+	VMCOREINFO_OFFSET(list_head, next);
+	VMCOREINFO_OFFSET(list_head, prev);
+	VMCOREINFO_OFFSET(vmap_area, va_start);
+	VMCOREINFO_OFFSET(vmap_area, list);
+	VMCOREINFO_LENGTH(zone.free_area, MAX_ORDER + 1);
+	log_buf_vmcoreinfo_setup();
+	VMCOREINFO_LENGTH(free_area.free_list, MIGRATE_TYPES);
+	VMCOREINFO_NUMBER(NR_FREE_PAGES);
+	VMCOREINFO_NUMBER(PG_lru);
+	VMCOREINFO_NUMBER(PG_private);
+	VMCOREINFO_NUMBER(PG_swapcache);
+	VMCOREINFO_NUMBER(PG_swapbacked);
+	VMCOREINFO_NUMBER(PG_slab);
+#ifdef CONFIG_MEMORY_FAILURE
+	VMCOREINFO_NUMBER(PG_hwpoison);
+#endif
+	VMCOREINFO_NUMBER(PG_head_mask);
+#define PAGE_BUDDY_MAPCOUNT_VALUE	(~PG_buddy)
+	VMCOREINFO_NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE);
+#ifdef CONFIG_HUGETLB_PAGE
+	VMCOREINFO_NUMBER(PG_hugetlb);
+#define PAGE_OFFLINE_MAPCOUNT_VALUE	(~PG_offline)
+	VMCOREINFO_NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE);
+#endif
+
+#ifdef CONFIG_KALLSYMS
+	VMCOREINFO_SYMBOL(kallsyms_names);
+	VMCOREINFO_SYMBOL(kallsyms_num_syms);
+	VMCOREINFO_SYMBOL(kallsyms_token_table);
+	VMCOREINFO_SYMBOL(kallsyms_token_index);
+#ifdef CONFIG_KALLSYMS_BASE_RELATIVE
+	VMCOREINFO_SYMBOL(kallsyms_offsets);
+	VMCOREINFO_SYMBOL(kallsyms_relative_base);
+#else
+	VMCOREINFO_SYMBOL(kallsyms_addresses);
+#endif /* CONFIG_KALLSYMS_BASE_RELATIVE */
+#endif /* CONFIG_KALLSYMS */
+
+	arch_crash_save_vmcoreinfo();
+	update_vmcoreinfo_note();
+
+	return 0;
+}
+
+subsys_initcall(crash_save_vmcoreinfo_init);
+
+static int __init crash_notes_memory_init(void)
+{
+	/* Allocate memory for saving cpu registers. */
+	size_t size, align;
+
+	/*
+	 * crash_notes could be allocated across 2 vmalloc pages when percpu
+	 * is vmalloc based . vmalloc doesn't guarantee 2 continuous vmalloc
+	 * pages are also on 2 continuous physical pages. In this case the
+	 * 2nd part of crash_notes in 2nd page could be lost since only the
+	 * starting address and size of crash_notes are exported through sysfs.
+	 * Here round up the size of crash_notes to the nearest power of two
+	 * and pass it to __alloc_percpu as align value. This can make sure
+	 * crash_notes is allocated inside one physical page.
+	 */
+	size = sizeof(note_buf_t);
+	align = min(roundup_pow_of_two(sizeof(note_buf_t)), PAGE_SIZE);
+
+	/*
+	 * Break compile if size is bigger than PAGE_SIZE since crash_notes
+	 * definitely will be in 2 pages with that.
+	 */
+	BUILD_BUG_ON(size > PAGE_SIZE);
+
+	crash_notes = __alloc_percpu(size, align);
+	if (!crash_notes) {
+		pr_warn("Memory allocation for saving cpu register states failed\n");
+		return -ENOMEM;
+	}
+	return 0;
+}
+subsys_initcall(crash_notes_memory_init);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index f2444b581e16..f4dea403bda7 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -951,7 +951,7 @@ const struct file_operations kmsg_fops = {
 	.release = devkmsg_release,
 };
 
-#ifdef CONFIG_CRASH_CORE
+#if defined(CONFIG_CRASH_CORE) || defined(CONFIG_OS_MINIDUMP)
 /*
  * This appends the listed symbols to /proc/vmcore
  *
diff --git a/lib/buildid.c b/lib/buildid.c
index e3a7acdeef0e..78d7ce03b34e 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -174,7 +174,8 @@ int build_id_parse_buf(const void *buf, unsigned char *build_id, u32 buf_size)
 	return parse_build_id_buf(build_id, NULL, buf, buf_size);
 }
 
-#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) || IS_ENABLED(CONFIG_CRASH_CORE)
+#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID) || IS_ENABLED(CONFIG_CRASH_CORE) \
+		|| (IS_ENABLED(CONFIG_OS_MINIDUMP))
 unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX] __ro_after_init;
 
 /**
-- 
2.17.1



From knaerzche at gmail.com  Thu Dec 21 05:31:44 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 21 Dec 2023 14:31:44 +0100
Subject: [PATCH v5 0/5] Add support for video hardware codec of
 STMicroelectronics STM32 SoC series
In-Reply-To: <a240d2ac-db0e-481b-8d13-3ae76cfd2fe7@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <769a1510-f8d2-4095-9879-42f413141dee@gmail.com>
 <a240d2ac-db0e-481b-8d13-3ae76cfd2fe7@foss.st.com>
Message-ID: <e5ba1e14-4bbf-43e3-933a-fee6d4b90641@gmail.com>

Hi Hugues,

Am 21.12.23 um 14:08 schrieb Hugues FRUCHET:
> Hi Alex,
>
> This is because VDEC and VENC are two separated IPs with their own 
> hardware resources and no links between both.
> On future SoCs, VDEC can ship on its own, same for VENC.
>
I think that's what the driver is/was designed for :)

I don't? think there _has_ to be a link between variants in the same file.
For Rockchip we only had the issue that there _is_ a link (shared
resources) between encoder and decoder and they had (for that reason) to be
defined has a _single_ variant. And there is no reason you can ship decoder
and encoder seperated when you have two variants (with different
compatibles).
For Rockchip and iMX those files are even containing variants for completly
different generations / different SoCs. I had to cleanup this mess for
Rockchip once - and it was no fun :) Anyways: It's up to the maintainers I
guess - I just wanted to ask if I missunderstand something here.

Greetings,

Alex

> Hoping that this clarify.
>
> Best regards,
> Hugues.
>
> On 12/21/23 13:40, Alex Bee wrote:
>> Hi Hugues, Hi Nicolas,
>>
>> is there any specific reason I'm not understanding / seeing why this 
>> is added in two seperate vdec* / venc* files and not a single vpu* 
>> file? Is it only for the seperate clocks (-names) / irqs (-names) / 
>> callbacks? Those are defined per variant and perfectly fit in a 
>> single file holding one vdec and one venc variant.
>>
>> Alex
>>
>> Am 21.12.23 um 09:47 schrieb Hugues Fruchet:
>>> This patchset introduces support for VDEC video hardware decoder
>>> and VENC video hardware encoder of STMicroelectronics STM32MP25
>>> SoC series.
>>>
>>> This initial support implements H264 decoding, VP8 decoding and
>>> JPEG encoding.
>>>
>>> This has been tested on STM32MP257F-EV1 evaluation board.
>>>
>>> ===========
>>> = history =
>>> ===========
>>> version 5:
>>> ??? - Precise that video decoding as been successfully tested up to 
>>> full HD
>>> ??? - Add Nicolas Dufresne reviewed-by
>>>
>>> version 4:
>>> ??? - Fix comments from Nicolas about dropping encoder raw steps
>>>
>>> version 3:
>>> ??? - Fix remarks from Krzysztof Kozlowski:
>>> ???? - drop "items", we keep simple enum in such case
>>> ???? - drop second example - it is the same as the first
>>> ??? - Drop unused node labels as suggested by Conor Dooley
>>> ??? - Revisit min/max resolutions as suggested by Nicolas Dufresne
>>>
>>> version 2:
>>> ??? - Fix remarks from Krzysztof Kozlowski on v1:
>>> ???? - single video-codec binding for both VDEC/VENC
>>> ???? - get rid of "-names"
>>> ???? - use of generic node name "video-codec"
>>>
>>> version 1:
>>> ?? - Initial submission
>>>
>>> Hugues Fruchet (5):
>>> ?? dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
>>> ?? media: hantro: add support for STM32MP25 VDEC
>>> ?? media: hantro: add support for STM32MP25 VENC
>>> ?? arm64: dts: st: add video decoder support to stm32mp255
>>> ?? arm64: dts: st: add video encoder support to stm32mp255
>>>
>>> ? .../media/st,stm32mp25-video-codec.yaml?????? |? 50 ++++++++
>>> ? arch/arm64/boot/dts/st/stm32mp251.dtsi??????? |? 12 ++
>>> ? arch/arm64/boot/dts/st/stm32mp255.dtsi??????? |? 17 +++
>>> ? drivers/media/platform/verisilicon/Kconfig??? |? 14 ++-
>>> ? drivers/media/platform/verisilicon/Makefile?? |?? 4 +
>>> ? .../media/platform/verisilicon/hantro_drv.c?? |?? 4 +
>>> ? .../media/platform/verisilicon/hantro_hw.h??? |?? 2 +
>>> ? .../platform/verisilicon/stm32mp25_vdec_hw.c? |? 92 ++++++++++++++
>>> ? .../platform/verisilicon/stm32mp25_venc_hw.c? | 115 
>>> ++++++++++++++++++
>>> ? 9 files changed, 307 insertions(+), 3 deletions(-)
>>> ? create mode 100644 
>>> Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
>>> ? create mode 100644 
>>> drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>>> ? create mode 100644 
>>> drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>>>
>>


From aford173 at gmail.com  Thu Dec 21 05:38:47 2023
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 21 Dec 2023 07:38:47 -0600
Subject: [PATCH v5 0/5] Add support for video hardware codec of
 STMicroelectronics STM32 SoC series
In-Reply-To: <e5ba1e14-4bbf-43e3-933a-fee6d4b90641@gmail.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <769a1510-f8d2-4095-9879-42f413141dee@gmail.com> <a240d2ac-db0e-481b-8d13-3ae76cfd2fe7@foss.st.com>
 <e5ba1e14-4bbf-43e3-933a-fee6d4b90641@gmail.com>
Message-ID: <CAHCN7xJ3Ktn+TnoOYdnNvKTddGCfLp4OQ+gM0WonWj-aqnsGuA@mail.gmail.com>

On Thu, Dec 21, 2023 at 7:31?AM Alex Bee <knaerzche at gmail.com> wrote:
>
> Hi Hugues,
>
> Am 21.12.23 um 14:08 schrieb Hugues FRUCHET:
> > Hi Alex,
> >
> > This is because VDEC and VENC are two separated IPs with their own
> > hardware resources and no links between both.
> > On future SoCs, VDEC can ship on its own, same for VENC.
> >
> I think that's what the driver is/was designed for :)
>
> I don't  think there _has_ to be a link between variants in the same file.
> For Rockchip we only had the issue that there _is_ a link (shared
> resources) between encoder and decoder and they had (for that reason) to be
> defined has a _single_ variant. And there is no reason you can ship decoder
> and encoder seperated when you have two variants (with different
> compatibles).
> For Rockchip and iMX those files are even containing variants for completly
> different generations / different SoCs. I had to cleanup this mess for

The i.MX8M Mini and Plus have different power domains for encoder and
decoders as well as different clocks.  Keeping them separate would
almost be necessary.

adam

> Rockchip once - and it was no fun :) Anyways: It's up to the maintainers I
> guess - I just wanted to ask if I missunderstand something here.
>
> Greetings,
>
> Alex
>
> > Hoping that this clarify.
> >
> > Best regards,
> > Hugues.
> >
> > On 12/21/23 13:40, Alex Bee wrote:
> >> Hi Hugues, Hi Nicolas,
> >>
> >> is there any specific reason I'm not understanding / seeing why this
> >> is added in two seperate vdec* / venc* files and not a single vpu*
> >> file? Is it only for the seperate clocks (-names) / irqs (-names) /
> >> callbacks? Those are defined per variant and perfectly fit in a
> >> single file holding one vdec and one venc variant.
> >>
> >> Alex
> >>
> >> Am 21.12.23 um 09:47 schrieb Hugues Fruchet:
> >>> This patchset introduces support for VDEC video hardware decoder
> >>> and VENC video hardware encoder of STMicroelectronics STM32MP25
> >>> SoC series.
> >>>
> >>> This initial support implements H264 decoding, VP8 decoding and
> >>> JPEG encoding.
> >>>
> >>> This has been tested on STM32MP257F-EV1 evaluation board.
> >>>
> >>> ===========
> >>> = history =
> >>> ===========
> >>> version 5:
> >>>     - Precise that video decoding as been successfully tested up to
> >>> full HD
> >>>     - Add Nicolas Dufresne reviewed-by
> >>>
> >>> version 4:
> >>>     - Fix comments from Nicolas about dropping encoder raw steps
> >>>
> >>> version 3:
> >>>     - Fix remarks from Krzysztof Kozlowski:
> >>>      - drop "items", we keep simple enum in such case
> >>>      - drop second example - it is the same as the first
> >>>     - Drop unused node labels as suggested by Conor Dooley
> >>>     - Revisit min/max resolutions as suggested by Nicolas Dufresne
> >>>
> >>> version 2:
> >>>     - Fix remarks from Krzysztof Kozlowski on v1:
> >>>      - single video-codec binding for both VDEC/VENC
> >>>      - get rid of "-names"
> >>>      - use of generic node name "video-codec"
> >>>
> >>> version 1:
> >>>    - Initial submission
> >>>
> >>> Hugues Fruchet (5):
> >>>    dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
> >>>    media: hantro: add support for STM32MP25 VDEC
> >>>    media: hantro: add support for STM32MP25 VENC
> >>>    arm64: dts: st: add video decoder support to stm32mp255
> >>>    arm64: dts: st: add video encoder support to stm32mp255
> >>>
> >>>   .../media/st,stm32mp25-video-codec.yaml       |  50 ++++++++
> >>>   arch/arm64/boot/dts/st/stm32mp251.dtsi        |  12 ++
> >>>   arch/arm64/boot/dts/st/stm32mp255.dtsi        |  17 +++
> >>>   drivers/media/platform/verisilicon/Kconfig    |  14 ++-
> >>>   drivers/media/platform/verisilicon/Makefile   |   4 +
> >>>   .../media/platform/verisilicon/hantro_drv.c   |   4 +
> >>>   .../media/platform/verisilicon/hantro_hw.h    |   2 +
> >>>   .../platform/verisilicon/stm32mp25_vdec_hw.c  |  92 ++++++++++++++
> >>>   .../platform/verisilicon/stm32mp25_venc_hw.c  | 115
> >>> ++++++++++++++++++
> >>>   9 files changed, 307 insertions(+), 3 deletions(-)
> >>>   create mode 100644
> >>> Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
> >>>   create mode 100644
> >>> drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
> >>>   create mode 100644
> >>> drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
> >>>
> >>


From andriy.shevchenko at intel.com  Thu Dec 21 05:42:17 2023
From: andriy.shevchenko at intel.com (Andy Shevchenko)
Date: Thu, 21 Dec 2023 15:42:17 +0200
Subject: [PATCH v2 00/22] Improve IRQ wake capability reporting and
 update the cros_ec driver to use it
In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
Message-ID: <ZYRAuY1LGdD8_u5K@smile.fi.intel.com>

On Wed, Dec 20, 2023 at 04:54:14PM -0700, Mark Hasemeyer wrote:
> Currently the cros_ec driver assumes that its associated interrupt is
> wake capable. This is an incorrect assumption as some Chromebooks use a
> separate wake pin, while others overload the interrupt for wake and IO.
> This patch train updates the driver to query the underlying ACPI/DT data
> to determine whether or not the IRQ should be enabled for wake.
> 
> Both the device tree and ACPI systems have methods for reporting IRQ
> wake capability. In device tree based systems, a node can advertise
> itself as a 'wakeup-source'. In ACPI based systems, GpioInt and
> Interrupt resource descriptors can use the 'SharedAndWake' or
> 'ExclusiveAndWake' share types.
> 
> Some logic is added to the platform, ACPI, and DT subsystems to more
> easily pipe wakeirq information up to the driver.

Just wondering if you used --histogram diff algo when preparing patches.


-- 
With Best Regards,
Andy Shevchenko




From knaerzche at gmail.com  Thu Dec 21 05:46:56 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 21 Dec 2023 14:46:56 +0100
Subject: [PATCH v5 0/5] Add support for video hardware codec of
 STMicroelectronics STM32 SoC series
In-Reply-To: <CAHCN7xJ3Ktn+TnoOYdnNvKTddGCfLp4OQ+gM0WonWj-aqnsGuA@mail.gmail.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <769a1510-f8d2-4095-9879-42f413141dee@gmail.com>
 <a240d2ac-db0e-481b-8d13-3ae76cfd2fe7@foss.st.com>
 <e5ba1e14-4bbf-43e3-933a-fee6d4b90641@gmail.com>
 <CAHCN7xJ3Ktn+TnoOYdnNvKTddGCfLp4OQ+gM0WonWj-aqnsGuA@mail.gmail.com>
Message-ID: <b03a7ddc-65c5-44c3-a563-d52ee938148a@gmail.com>


Am 21.12.23 um 14:38 schrieb Adam Ford:
> On Thu, Dec 21, 2023 at 7:31?AM Alex Bee <knaerzche at gmail.com> wrote:
>> Hi Hugues,
>>
>> Am 21.12.23 um 14:08 schrieb Hugues FRUCHET:
>>> Hi Alex,
>>>
>>> This is because VDEC and VENC are two separated IPs with their own
>>> hardware resources and no links between both.
>>> On future SoCs, VDEC can ship on its own, same for VENC.
>>>
>> I think that's what the driver is/was designed for :)
>>
>> I don't  think there _has_ to be a link between variants in the same file.
>> For Rockchip we only had the issue that there _is_ a link (shared
>> resources) between encoder and decoder and they had (for that reason) to be
>> defined has a _single_ variant. And there is no reason you can ship decoder
>> and encoder seperated when you have two variants (with different
>> compatibles).
>> For Rockchip and iMX those files are even containing variants for completly
>> different generations / different SoCs. I had to cleanup this mess for
> The i.MX8M Mini and Plus have different power domains for encoder and
> decoders as well as different clocks.  Keeping them separate would
> almost be necessary.
I guess there is missunderstanding: I didn't say the two STM variants
should be merged in one variant, but the two variants should be within the
same _file_, like the other platforms are doing :)
> adam
>
>> Rockchip once - and it was no fun :) Anyways: It's up to the maintainers I
>> guess - I just wanted to ask if I missunderstand something here.
>>
>> Greetings,
>>
>> Alex
>>
>>> Hoping that this clarify.
>>>
>>> Best regards,
>>> Hugues.
>>>
>>> On 12/21/23 13:40, Alex Bee wrote:
>>>> Hi Hugues, Hi Nicolas,
>>>>
>>>> is there any specific reason I'm not understanding / seeing why this
>>>> is added in two seperate vdec* / venc* files and not a single vpu*
>>>> file? Is it only for the seperate clocks (-names) / irqs (-names) /
>>>> callbacks? Those are defined per variant and perfectly fit in a
>>>> single file holding one vdec and one venc variant.
>>>>
>>>> Alex
>>>>
>>>> Am 21.12.23 um 09:47 schrieb Hugues Fruchet:
>>>>> This patchset introduces support for VDEC video hardware decoder
>>>>> and VENC video hardware encoder of STMicroelectronics STM32MP25
>>>>> SoC series.
>>>>>
>>>>> This initial support implements H264 decoding, VP8 decoding and
>>>>> JPEG encoding.
>>>>>
>>>>> This has been tested on STM32MP257F-EV1 evaluation board.
>>>>>
>>>>> ===========
>>>>> = history =
>>>>> ===========
>>>>> version 5:
>>>>>      - Precise that video decoding as been successfully tested up to
>>>>> full HD
>>>>>      - Add Nicolas Dufresne reviewed-by
>>>>>
>>>>> version 4:
>>>>>      - Fix comments from Nicolas about dropping encoder raw steps
>>>>>
>>>>> version 3:
>>>>>      - Fix remarks from Krzysztof Kozlowski:
>>>>>       - drop "items", we keep simple enum in such case
>>>>>       - drop second example - it is the same as the first
>>>>>      - Drop unused node labels as suggested by Conor Dooley
>>>>>      - Revisit min/max resolutions as suggested by Nicolas Dufresne
>>>>>
>>>>> version 2:
>>>>>      - Fix remarks from Krzysztof Kozlowski on v1:
>>>>>       - single video-codec binding for both VDEC/VENC
>>>>>       - get rid of "-names"
>>>>>       - use of generic node name "video-codec"
>>>>>
>>>>> version 1:
>>>>>     - Initial submission
>>>>>
>>>>> Hugues Fruchet (5):
>>>>>     dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
>>>>>     media: hantro: add support for STM32MP25 VDEC
>>>>>     media: hantro: add support for STM32MP25 VENC
>>>>>     arm64: dts: st: add video decoder support to stm32mp255
>>>>>     arm64: dts: st: add video encoder support to stm32mp255
>>>>>
>>>>>    .../media/st,stm32mp25-video-codec.yaml       |  50 ++++++++
>>>>>    arch/arm64/boot/dts/st/stm32mp251.dtsi        |  12 ++
>>>>>    arch/arm64/boot/dts/st/stm32mp255.dtsi        |  17 +++
>>>>>    drivers/media/platform/verisilicon/Kconfig    |  14 ++-
>>>>>    drivers/media/platform/verisilicon/Makefile   |   4 +
>>>>>    .../media/platform/verisilicon/hantro_drv.c   |   4 +
>>>>>    .../media/platform/verisilicon/hantro_hw.h    |   2 +
>>>>>    .../platform/verisilicon/stm32mp25_vdec_hw.c  |  92 ++++++++++++++
>>>>>    .../platform/verisilicon/stm32mp25_venc_hw.c  | 115
>>>>> ++++++++++++++++++
>>>>>    9 files changed, 307 insertions(+), 3 deletions(-)
>>>>>    create mode 100644
>>>>> Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
>>>>>    create mode 100644
>>>>> drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>>>>>    create mode 100644
>>>>> drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>>>>>


From yilun.xu at linux.intel.com  Thu Dec 21 05:47:36 2023
From: yilun.xu at linux.intel.com (Xu Yilun)
Date: Thu, 21 Dec 2023 21:47:36 +0800
Subject: [PATCH] dt-bindings: firmware: xilinx: Fix versal-fpga node name
In-Reply-To: <7ac7db8e-f9b5-4394-af71-1a2b2548c485@linaro.org>
References: <6779af2f9cc21c912f10cf310388d99b980800b2.1702996281.git.michal.simek@amd.com>
 <7ac7db8e-f9b5-4394-af71-1a2b2548c485@linaro.org>
Message-ID: <ZYRB+Jkj0IMTphDo@yilunxu-OptiPlex-7050>

On Wed, Dec 20, 2023 at 08:54:33AM +0100, Krzysztof Kozlowski wrote:
> On 19/12/2023 15:31, Michal Simek wrote:
> > Based on commit 83a368a3fc8a ("docs: dt-bindings: add DTS Coding Style
> > document") using underscore ('_') in node name is not recommended that's
> > why switch to dash ('-').
> > 
> > Signed-off-by: Michal Simek <michal.simek at amd.com>
> > ---
> > 
> >  .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml        | 4 ++--
> >  Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml  | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> > index 8e584857ddd4..3d578f98ae2c 100644
> > --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> > +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> > @@ -41,7 +41,7 @@ properties:
> >    "#power-domain-cells":
> >      const: 1
> >  
> 
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Acked-by: Xu Yilun <yilun.xu at intel.com>

> 
> Best regards,
> Krzysztof
> 
> 


From hugues.fruchet at foss.st.com  Thu Dec 21 05:55:54 2023
From: hugues.fruchet at foss.st.com (Hugues FRUCHET)
Date: Thu, 21 Dec 2023 14:55:54 +0100
Subject: [PATCH v5 0/5] Add support for video hardware codec of
 STMicroelectronics STM32 SoC series
In-Reply-To: <b03a7ddc-65c5-44c3-a563-d52ee938148a@gmail.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <769a1510-f8d2-4095-9879-42f413141dee@gmail.com>
 <a240d2ac-db0e-481b-8d13-3ae76cfd2fe7@foss.st.com>
 <e5ba1e14-4bbf-43e3-933a-fee6d4b90641@gmail.com>
 <CAHCN7xJ3Ktn+TnoOYdnNvKTddGCfLp4OQ+gM0WonWj-aqnsGuA@mail.gmail.com>
 <b03a7ddc-65c5-44c3-a563-d52ee938148a@gmail.com>
Message-ID: <6d26d307-eb7a-43ad-b4f3-57f8ac7ce8f0@foss.st.com>

Hi Alex,

On 12/21/23 14:46, Alex Bee wrote:
> 
> Am 21.12.23 um 14:38 schrieb Adam Ford:
>> On Thu, Dec 21, 2023 at 7:31?AM Alex Bee <knaerzche at gmail.com> wrote:
>>> Hi Hugues,
>>>
>>> Am 21.12.23 um 14:08 schrieb Hugues FRUCHET:
>>>> Hi Alex,
>>>>
>>>> This is because VDEC and VENC are two separated IPs with their own
>>>> hardware resources and no links between both.
>>>> On future SoCs, VDEC can ship on its own, same for VENC.
>>>>
>>> I think that's what the driver is/was designed for :)
>>>
>>> I don't? think there _has_ to be a link between variants in the same 
>>> file.
>>> For Rockchip we only had the issue that there _is_ a link (shared
>>> resources) between encoder and decoder and they had (for that reason) 
>>> to be
>>> defined has a _single_ variant. And there is no reason you can ship 
>>> decoder
>>> and encoder seperated when you have two variants (with different
>>> compatibles).
>>> For Rockchip and iMX those files are even containing variants for 
>>> completly
>>> different generations / different SoCs. I had to cleanup this mess for
>> The i.MX8M Mini and Plus have different power domains for encoder and
>> decoders as well as different clocks.? Keeping them separate would
>> almost be necessary.
> I guess there is missunderstanding: I didn't say the two STM variants
> should be merged in one variant, but the two variants should be within the
> same _file_, like the other platforms are doing :)

I have two separated hardware: VDEC and VENC, not a single block like 
"VPU" for example. So what name should have this file ?
Other platforms had a common file because there was a common block 
embedding both decoder and encoder, sometimes with links/dependencies 
between both.
SAMA5D4 has only a decoder, only a single file called "_vdec_hw.c"...
so it is quite logical for me to have one file per independent IP.

>> adam
>>
>>> Rockchip once - and it was no fun :) Anyways: It's up to the 
>>> maintainers I
>>> guess - I just wanted to ask if I missunderstand something here.
>>>
>>> Greetings,
>>>
>>> Alex
>>>
>>>> Hoping that this clarify.
>>>>
>>>> Best regards,
>>>> Hugues.
>>>>
>>>> On 12/21/23 13:40, Alex Bee wrote:
>>>>> Hi Hugues, Hi Nicolas,
>>>>>
>>>>> is there any specific reason I'm not understanding / seeing why this
>>>>> is added in two seperate vdec* / venc* files and not a single vpu*
>>>>> file? Is it only for the seperate clocks (-names) / irqs (-names) /
>>>>> callbacks? Those are defined per variant and perfectly fit in a
>>>>> single file holding one vdec and one venc variant.
>>>>>
>>>>> Alex
>>>>>
>>>>> Am 21.12.23 um 09:47 schrieb Hugues Fruchet:
>>>>>> This patchset introduces support for VDEC video hardware decoder
>>>>>> and VENC video hardware encoder of STMicroelectronics STM32MP25
>>>>>> SoC series.
>>>>>>
>>>>>> This initial support implements H264 decoding, VP8 decoding and
>>>>>> JPEG encoding.
>>>>>>
>>>>>> This has been tested on STM32MP257F-EV1 evaluation board.
>>>>>>
>>>>>> ===========
>>>>>> = history =
>>>>>> ===========
>>>>>> version 5:
>>>>>> ???? - Precise that video decoding as been successfully tested up to
>>>>>> full HD
>>>>>> ???? - Add Nicolas Dufresne reviewed-by
>>>>>>
>>>>>> version 4:
>>>>>> ???? - Fix comments from Nicolas about dropping encoder raw steps
>>>>>>
>>>>>> version 3:
>>>>>> ???? - Fix remarks from Krzysztof Kozlowski:
>>>>>> ????? - drop "items", we keep simple enum in such case
>>>>>> ????? - drop second example - it is the same as the first
>>>>>> ???? - Drop unused node labels as suggested by Conor Dooley
>>>>>> ???? - Revisit min/max resolutions as suggested by Nicolas Dufresne
>>>>>>
>>>>>> version 2:
>>>>>> ???? - Fix remarks from Krzysztof Kozlowski on v1:
>>>>>> ????? - single video-codec binding for both VDEC/VENC
>>>>>> ????? - get rid of "-names"
>>>>>> ????? - use of generic node name "video-codec"
>>>>>>
>>>>>> version 1:
>>>>>> ??? - Initial submission
>>>>>>
>>>>>> Hugues Fruchet (5):
>>>>>> ??? dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
>>>>>> ??? media: hantro: add support for STM32MP25 VDEC
>>>>>> ??? media: hantro: add support for STM32MP25 VENC
>>>>>> ??? arm64: dts: st: add video decoder support to stm32mp255
>>>>>> ??? arm64: dts: st: add video encoder support to stm32mp255
>>>>>>
>>>>>> ?? .../media/st,stm32mp25-video-codec.yaml?????? |? 50 ++++++++
>>>>>> ?? arch/arm64/boot/dts/st/stm32mp251.dtsi??????? |? 12 ++
>>>>>> ?? arch/arm64/boot/dts/st/stm32mp255.dtsi??????? |? 17 +++
>>>>>> ?? drivers/media/platform/verisilicon/Kconfig??? |? 14 ++-
>>>>>> ?? drivers/media/platform/verisilicon/Makefile?? |?? 4 +
>>>>>> ?? .../media/platform/verisilicon/hantro_drv.c?? |?? 4 +
>>>>>> ?? .../media/platform/verisilicon/hantro_hw.h??? |?? 2 +
>>>>>> ?? .../platform/verisilicon/stm32mp25_vdec_hw.c? |? 92 ++++++++++++++
>>>>>> ?? .../platform/verisilicon/stm32mp25_venc_hw.c? | 115
>>>>>> ++++++++++++++++++
>>>>>> ?? 9 files changed, 307 insertions(+), 3 deletions(-)
>>>>>> ?? create mode 100644
>>>>>> Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
>>>>>> ?? create mode 100644
>>>>>> drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>>>>>> ?? create mode 100644
>>>>>> drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>>>>>>

Best regards,
Hugues.


From andre.przywara at arm.com  Thu Dec 21 06:06:14 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 21 Dec 2023 14:06:14 +0000
Subject: [PATCH] dt-bindings: arm: sunxi: sort alphabetically
Message-ID: <20231221140614.639697-1-andre.przywara@arm.com>

The sunxi.yaml file, holding all known board compatible names for
devices with Allwinner SoCs, is apparently sorted alphabetically, by the
"description" entry. However there are a few outliers.

Re-order the entries to get a strict alphabetical ordering, so that:
$ grep description: sunxi.yaml | sort -fc
returns empty-handed. There is no change otherwise.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
Based on sunxi/dt-for-6.8

 .../devicetree/bindings/arm/sunxi.yaml        | 172 +++++++++---------
 1 file changed, 86 insertions(+), 86 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index a9d8e85565b89..0bf24f4882240 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -51,16 +51,16 @@ properties:
           - const: allwinner,parrot
           - const: allwinner,sun8i-a33
 
-      - description: Anbernic RG-Nano
-        items:
-          - const: anbernic,rg-nano
-          - const: allwinner,sun8i-v3s
-
       - description: Amarula A64 Relic
         items:
           - const: amarula,a64-relic
           - const: allwinner,sun50i-a64
 
+      - description: Anbernic RG-Nano
+        items:
+          - const: anbernic,rg-nano
+          - const: allwinner,sun8i-v3s
+
       - description: Auxtek T003 A10s HDMI TV Stick
         items:
           - const: allwinner,auxtek-t003
@@ -96,6 +96,11 @@ properties:
           - const: sinovoip,bpi-m2-berry
           - const: allwinner,sun8i-r40
 
+      - description: BananaPi M2 Magic
+        items:
+          - const: sinovoip,bananapi-m2m
+          - const: allwinner,sun8i-a33
+
       - description: BananaPi M2 Plus
         items:
           - const: sinovoip,bpi-m2-plus
@@ -116,11 +121,6 @@ properties:
           - const: bananapi,bpi-m2-plus-v1.2
           - const: allwinner,sun50i-h5
 
-      - description: BananaPi M2 Magic
-        items:
-          - const: sinovoip,bananapi-m2m
-          - const: allwinner,sun8i-a33
-
       - description: BananaPi M2 Ultra
         items:
           - const: sinovoip,bpi-m2-ultra
@@ -230,6 +230,18 @@ properties:
           - const: sochip,s3
           - const: allwinner,sun8i-v3
 
+      - description: Emlid Neutis N5 Developer Board
+        items:
+          - const: emlid,neutis-n5-devboard
+          - const: emlid,neutis-n5
+          - const: allwinner,sun50i-h5
+
+      - description: Emlid Neutis N5H3 Developer Board
+        items:
+          - const: emlid,neutis-n5h3-devboard
+          - const: emlid,neutis-n5h3
+          - const: allwinner,sun8i-h3
+
       - description: Empire Electronix D709 Tablet
         items:
           - const: empire-electronix,d709
@@ -306,16 +318,26 @@ properties:
           - const: gemei,g9
           - const: allwinner,sun4i-a10
 
-      - description: Hyundai A7HD
+      - description: HAOYU Electronics Marsboard A10
         items:
-          - const: hyundai,a7hd
+          - const: haoyu,a10-marsboard
           - const: allwinner,sun4i-a10
 
+      - description: HAOYU Electronics Marsboard A20
+        items:
+          - const: haoyu,a20-marsboard
+          - const: allwinner,sun7i-a20
+
       - description: HSG H702
         items:
           - const: hsg,h702
           - const: allwinner,sun5i-a13
 
+      - description: Hyundai A7HD
+        items:
+          - const: hyundai,a7hd
+          - const: allwinner,sun4i-a10
+
       - description: I12 TV Box
         items:
           - const: allwinner,i12-tvbox
@@ -343,11 +365,6 @@ properties:
           - const: primux,inet86dz
           - const: allwinner,sun8i-a23
 
-      - description: iNet-9F Rev 03
-        items:
-          - const: inet-tek,inet9f-rev03
-          - const: allwinner,sun4i-a10
-
       - description: iNet-97F Rev 02
         items:
           - const: primux,inet97fv2
@@ -358,6 +375,11 @@ properties:
           - const: primux,inet98v-rev2
           - const: allwinner,sun5i-a13
 
+      - description: iNet-9F Rev 03
+        items:
+          - const: inet-tek,inet9f-rev03
+          - const: allwinner,sun4i-a10
+
       - description: iNet D978 Rev 02 Tablet
         items:
           - const: primux,inet-d978-rev2
@@ -472,15 +494,10 @@ properties:
           - const: lamobo,lamobo-r1
           - const: allwinner,sun7i-a20
 
-      - description: HAOYU Electronics Marsboard A10
-        items:
-          - const: haoyu,a10-marsboard
-          - const: allwinner,sun4i-a10
-
-      - description: HAOYU Electronics Marsboard A20
+      - description: MangoPi MQ-R board
         items:
-          - const: haoyu,a20-marsboard
-          - const: allwinner,sun7i-a20
+          - const: widora,mangopi-mq-r-t113
+          - const: allwinner,sun8i-t113s
 
       - description: MapleBoard MP130
         items:
@@ -557,18 +574,6 @@ properties:
           - const: msi,primo81
           - const: allwinner,sun6i-a31s
 
-      - description: Emlid Neutis N5 Developer Board
-        items:
-          - const: emlid,neutis-n5-devboard
-          - const: emlid,neutis-n5
-          - const: allwinner,sun50i-h5
-
-      - description: Emlid Neutis N5H3 Developer Board
-        items:
-          - const: emlid,neutis-n5h3-devboard
-          - const: emlid,neutis-n5h3
-          - const: allwinner,sun8i-h3
-
       - description: NextThing Co. CHIP
         items:
           - const: nextthing,chip
@@ -638,11 +643,6 @@ properties:
           - const: olimex,a20-olinuxino-lime
           - const: allwinner,sun7i-a20
 
-      - description: Olimex A20-OlinuXino LIME (with eMMC)
-        items:
-          - const: olimex,a20-olinuxino-lime-emmc
-          - const: allwinner,sun7i-a20
-
       - description: Olimex A20-OlinuXino LIME2
         items:
           - const: olimex,a20-olinuxino-lime2
@@ -653,6 +653,11 @@ properties:
           - const: olimex,a20-olinuxino-lime2-emmc
           - const: allwinner,sun7i-a20
 
+      - description: Olimex A20-OlinuXino LIME (with eMMC)
+        items:
+          - const: olimex,a20-olinuxino-lime-emmc
+          - const: allwinner,sun7i-a20
+
       - description: Olimex A20-OlinuXino Micro
         items:
           - const: olimex,a20-olinuxino-micro
@@ -703,6 +708,17 @@ properties:
           - const: pine64,pine64-plus
           - const: allwinner,sun50i-a64
 
+      - description: Pine64 LTS
+        items:
+          - const: pine64,pine64-lts
+          - const: allwinner,sun50i-r18
+          - const: allwinner,sun50i-a64
+
+      - description: Pine64 Pinebook
+        items:
+          - const: pine64,pinebook
+          - const: allwinner,sun50i-a64
+
       - description: Pine64 PineCube
         items:
           - const: pine64,pinecube
@@ -719,20 +735,9 @@ properties:
           - const: pine64,pine-h64-model-b
           - const: allwinner,sun50i-h6
 
-      - description: Pine64 LTS
-        items:
-          - const: pine64,pine64-lts
-          - const: allwinner,sun50i-r18
-          - const: allwinner,sun50i-a64
-
-      - description: Pine64 Pinebook
-        items:
-          - const: pine64,pinebook
-          - const: allwinner,sun50i-a64
-
-      - description: Pine64 PinePhone Developer Batch (1.0)
+      - description: Pine64 PinePhone (1.2)
         items:
-          - const: pine64,pinephone-1.0
+          - const: pine64,pinephone-1.2
           - const: pine64,pinephone
           - const: allwinner,sun50i-a64
 
@@ -742,9 +747,9 @@ properties:
           - const: pine64,pinephone
           - const: allwinner,sun50i-a64
 
-      - description: Pine64 PinePhone (1.2)
+      - description: Pine64 PinePhone Developer Batch (1.0)
         items:
-          - const: pine64,pinephone-1.2
+          - const: pine64,pinephone-1.0
           - const: pine64,pinephone
           - const: allwinner,sun50i-a64
 
@@ -835,6 +840,12 @@ properties:
           - const: sinlinx,sina33
           - const: allwinner,sun8i-a33
 
+      - description: SL631 Action Camera with IMX179
+        items:
+          - const: allwinner,sl631-imx179
+          - const: allwinner,sl631
+          - const: allwinner,sun8i-v3
+
       - description: SourceParts PopStick v1.1
         items:
           - const: sourceparts,popstick-v1.1
@@ -842,12 +853,6 @@ properties:
           - const: allwinner,suniv-f1c200s
           - const: allwinner,suniv-f1c100s
 
-      - description: SL631 Action Camera with IMX179
-        items:
-          - const: allwinner,sl631-imx179
-          - const: allwinner,sl631
-          - const: allwinner,sun8i-v3
-
       - description: Tanix TX6
         items:
           - const: oranth,tanix-tx6
@@ -883,11 +888,6 @@ properties:
           - const: wexler,tab7200
           - const: allwinner,sun7i-a20
 
-      - description: MangoPi MQ-R board
-        items:
-          - const: widora,mangopi-mq-r-t113
-          - const: allwinner,sun8i-t113s
-
       - description: WITS A31 Colombus Evaluation Board
         items:
           - const: wits,colombus
@@ -903,11 +903,6 @@ properties:
           - const: wobo,a10s-wobo-i5
           - const: allwinner,sun5i-a10s
 
-      - description: Yones TopTech BS1078 v2 Tablet
-        items:
-          - const: yones-toptech,bs1078-v2
-          - const: allwinner,sun6i-a31s
-
       - description: X96 Mate TV box
         items:
           - const: hechuang,x96-mate
@@ -998,6 +993,21 @@ properties:
           - const: xunlong,orangepi-zero
           - const: allwinner,sun8i-h2-plus
 
+      - description: Xunlong OrangePi Zero 2
+        items:
+          - const: xunlong,orangepi-zero2
+          - const: allwinner,sun50i-h616
+
+      - description: Xunlong OrangePi Zero 2W
+        items:
+          - const: xunlong,orangepi-zero2w
+          - const: allwinner,sun50i-h618
+
+      - description: Xunlong OrangePi Zero 3
+        items:
+          - const: xunlong,orangepi-zero3
+          - const: allwinner,sun50i-h618
+
       - description: Xunlong OrangePi Zero Plus
         items:
           - const: xunlong,orangepi-zero-plus
@@ -1013,19 +1023,9 @@ properties:
           - const: xunlong,orangepi-zero-plus2-h3
           - const: allwinner,sun8i-h3
 
-      - description: Xunlong OrangePi Zero 2
-        items:
-          - const: xunlong,orangepi-zero2
-          - const: allwinner,sun50i-h616
-
-      - description: Xunlong OrangePi Zero 2W
-        items:
-          - const: xunlong,orangepi-zero2w
-          - const: allwinner,sun50i-h618
-
-      - description: Xunlong OrangePi Zero 3
+      - description: Yones TopTech BS1078 v2 Tablet
         items:
-          - const: xunlong,orangepi-zero3
-          - const: allwinner,sun50i-h618
+          - const: yones-toptech,bs1078-v2
+          - const: allwinner,sun6i-a31s
 
 additionalProperties: true

base-commit: a4aebe936554dac6a91e5d091179c934f8325708
prerequisite-patch-id: b72637774a9de3328cc561ae4bb3137bba25fafd
prerequisite-patch-id: 1a3327044ae61af705ffd79028687f3f6629edf4
-- 
2.25.1



From knaerzche at gmail.com  Thu Dec 21 06:18:56 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 21 Dec 2023 15:18:56 +0100
Subject: [PATCH v5 0/5] Add support for video hardware codec of
 STMicroelectronics STM32 SoC series
In-Reply-To: <6d26d307-eb7a-43ad-b4f3-57f8ac7ce8f0@foss.st.com>
References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com>
 <769a1510-f8d2-4095-9879-42f413141dee@gmail.com>
 <a240d2ac-db0e-481b-8d13-3ae76cfd2fe7@foss.st.com>
 <e5ba1e14-4bbf-43e3-933a-fee6d4b90641@gmail.com>
 <CAHCN7xJ3Ktn+TnoOYdnNvKTddGCfLp4OQ+gM0WonWj-aqnsGuA@mail.gmail.com>
 <b03a7ddc-65c5-44c3-a563-d52ee938148a@gmail.com>
 <6d26d307-eb7a-43ad-b4f3-57f8ac7ce8f0@foss.st.com>
Message-ID: <5095f695-6dad-45e2-9cff-1b79003355c9@gmail.com>

Hi Hugues,

Am 21.12.23 um 14:55 schrieb Hugues FRUCHET:
> Hi Alex,
>
> On 12/21/23 14:46, Alex Bee wrote:
>>
>> Am 21.12.23 um 14:38 schrieb Adam Ford:
>>> On Thu, Dec 21, 2023 at 7:31?AM Alex Bee <knaerzche at gmail.com> wrote:
>>>> Hi Hugues,
>>>>
>>>> Am 21.12.23 um 14:08 schrieb Hugues FRUCHET:
>>>>> Hi Alex,
>>>>>
>>>>> This is because VDEC and VENC are two separated IPs with their own
>>>>> hardware resources and no links between both.
>>>>> On future SoCs, VDEC can ship on its own, same for VENC.
>>>>>
>>>> I think that's what the driver is/was designed for :)
>>>>
>>>> I don't? think there _has_ to be a link between variants in the 
>>>> same file.
>>>> For Rockchip we only had the issue that there _is_ a link (shared
>>>> resources) between encoder and decoder and they had (for that 
>>>> reason) to be
>>>> defined has a _single_ variant. And there is no reason you can ship 
>>>> decoder
>>>> and encoder seperated when you have two variants (with different
>>>> compatibles).
>>>> For Rockchip and iMX those files are even containing variants for 
>>>> completly
>>>> different generations / different SoCs. I had to cleanup this mess for
>>> The i.MX8M Mini and Plus have different power domains for encoder and
>>> decoders as well as different clocks.? Keeping them separate would
>>> almost be necessary.
>> I guess there is missunderstanding: I didn't say the two STM variants
>> should be merged in one variant, but the two variants should be 
>> within the
>> same _file_, like the other platforms are doing :)
>
> I have two separated hardware: VDEC and VENC, not a single block like 
> "VPU" for example. So what name should have this file ?
> Other platforms had a common file because there was a common block 
> embedding both decoder and encoder, sometimes with links/dependencies 
> between both.
> SAMA5D4 has only a decoder, only a single file called "_vdec_hw.c"...
> so it is quite logical for me to have one file per independent IP.
>
Maybe - but that's not way the driver is currently organzied.
rockchip_vpu_hw.c also holds variants which have only have a decoder and
also some which only have a encoder. So "vpu" is quite neutral, I guess. It
doesn't say anything if it belongs to encoder or decoder.
When I was adding the RK3066 variant a I was even asked to add a explicit
comment, why this integration can't be splitted in encoder and decoder
variant.

We were having a a lot of these split-ups in the early days of hantro
driver and it was no fun to clean them up.

Alex

>>> adam
>>>
>>>> Rockchip once - and it was no fun :) Anyways: It's up to the 
>>>> maintainers I
>>>> guess - I just wanted to ask if I missunderstand something here.
>>>>
>>>> Greetings,
>>>>
>>>> Alex
>>>>
>>>>> Hoping that this clarify.
>>>>>
>>>>> Best regards,
>>>>> Hugues.
>>>>>
>>>>> On 12/21/23 13:40, Alex Bee wrote:
>>>>>> Hi Hugues, Hi Nicolas,
>>>>>>
>>>>>> is there any specific reason I'm not understanding / seeing why this
>>>>>> is added in two seperate vdec* / venc* files and not a single vpu*
>>>>>> file? Is it only for the seperate clocks (-names) / irqs (-names) /
>>>>>> callbacks? Those are defined per variant and perfectly fit in a
>>>>>> single file holding one vdec and one venc variant.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> Am 21.12.23 um 09:47 schrieb Hugues Fruchet:
>>>>>>> This patchset introduces support for VDEC video hardware decoder
>>>>>>> and VENC video hardware encoder of STMicroelectronics STM32MP25
>>>>>>> SoC series.
>>>>>>>
>>>>>>> This initial support implements H264 decoding, VP8 decoding and
>>>>>>> JPEG encoding.
>>>>>>>
>>>>>>> This has been tested on STM32MP257F-EV1 evaluation board.
>>>>>>>
>>>>>>> ===========
>>>>>>> = history =
>>>>>>> ===========
>>>>>>> version 5:
>>>>>>> ???? - Precise that video decoding as been successfully tested 
>>>>>>> up to
>>>>>>> full HD
>>>>>>> ???? - Add Nicolas Dufresne reviewed-by
>>>>>>>
>>>>>>> version 4:
>>>>>>> ???? - Fix comments from Nicolas about dropping encoder raw steps
>>>>>>>
>>>>>>> version 3:
>>>>>>> ???? - Fix remarks from Krzysztof Kozlowski:
>>>>>>> ????? - drop "items", we keep simple enum in such case
>>>>>>> ????? - drop second example - it is the same as the first
>>>>>>> ???? - Drop unused node labels as suggested by Conor Dooley
>>>>>>> ???? - Revisit min/max resolutions as suggested by Nicolas Dufresne
>>>>>>>
>>>>>>> version 2:
>>>>>>> ???? - Fix remarks from Krzysztof Kozlowski on v1:
>>>>>>> ????? - single video-codec binding for both VDEC/VENC
>>>>>>> ????? - get rid of "-names"
>>>>>>> ????? - use of generic node name "video-codec"
>>>>>>>
>>>>>>> version 1:
>>>>>>> ??? - Initial submission
>>>>>>>
>>>>>>> Hugues Fruchet (5):
>>>>>>> ??? dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs
>>>>>>> ??? media: hantro: add support for STM32MP25 VDEC
>>>>>>> ??? media: hantro: add support for STM32MP25 VENC
>>>>>>> ??? arm64: dts: st: add video decoder support to stm32mp255
>>>>>>> ??? arm64: dts: st: add video encoder support to stm32mp255
>>>>>>>
>>>>>>> ?? .../media/st,stm32mp25-video-codec.yaml?????? |? 50 ++++++++
>>>>>>> ?? arch/arm64/boot/dts/st/stm32mp251.dtsi??????? |? 12 ++
>>>>>>> ?? arch/arm64/boot/dts/st/stm32mp255.dtsi??????? |? 17 +++
>>>>>>> ?? drivers/media/platform/verisilicon/Kconfig??? |? 14 ++-
>>>>>>> ?? drivers/media/platform/verisilicon/Makefile?? |?? 4 +
>>>>>>> ?? .../media/platform/verisilicon/hantro_drv.c?? |?? 4 +
>>>>>>> ?? .../media/platform/verisilicon/hantro_hw.h??? |?? 2 +
>>>>>>> ?? .../platform/verisilicon/stm32mp25_vdec_hw.c? |? 92 
>>>>>>> ++++++++++++++
>>>>>>> ?? .../platform/verisilicon/stm32mp25_venc_hw.c? | 115
>>>>>>> ++++++++++++++++++
>>>>>>> ?? 9 files changed, 307 insertions(+), 3 deletions(-)
>>>>>>> ?? create mode 100644
>>>>>>> Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml 
>>>>>>>
>>>>>>> ?? create mode 100644
>>>>>>> drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c
>>>>>>> ?? create mode 100644
>>>>>>> drivers/media/platform/verisilicon/stm32mp25_venc_hw.c
>>>>>>>
>
> Best regards,
> Hugues.


From robh at kernel.org  Thu Dec 21 06:25:31 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 21 Dec 2023 08:25:31 -0600
Subject: [PATCH v3 1/9] dt-bindings: iommu: Add Translation Buffer Unit
 bindings
In-Reply-To: <20231220060236.18600-2-quic_c_gdjako@quicinc.com>
References: <20231220060236.18600-1-quic_c_gdjako@quicinc.com>
 <20231220060236.18600-2-quic_c_gdjako@quicinc.com>
Message-ID: <20231221142531.GA3730284-robh@kernel.org>

On Tue, Dec 19, 2023 at 10:02:28PM -0800, Georgi Djakov wrote:
> The "apps_smmu" on the Qualcomm sdm845 platform is an implementation
> of the SMMU-500, that consists of a single TCU (Translation Control
> Unit) and multiple TBUs (Translation Buffer Units). The TCU is already
> being described in the generic SMMU DT schema. Add bindings for the
> TBUs to describe their properties and resources that needs to be
> managed in order to operate them.
> 
> In this DT schema, the TBUs are modelled as child devices of the TCU
> and each of them is described with it's register space, clocks, power
> domains, interconnects etc.
> 
> Signed-off-by: Georgi Djakov <quic_c_gdjako at quicinc.com>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.yaml   | 31 ++++++++
>  .../bindings/iommu/qcom,qsmmuv500-tbu.yaml    | 77 +++++++++++++++++++
>  2 files changed, 108 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/qcom,qsmmuv500-tbu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index a4042ae24770..a610af2c7e5e 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -235,6 +235,27 @@ properties:
>        enabled for any given device.
>      $ref: /schemas/types.yaml#/definitions/phandle
>  
> +  '#address-cells':
> +    enum: [ 1, 2 ]
> +
> +  '#size-cells':
> +    enum: [ 1, 2 ]
> +
> +  ranges: true
> +
> +patternProperties:
> +  "^tbu@[0-9a-f]+":

Missing '$' on the end.

> +    description: The TBU child node(s)
> +    type: object
> +
> +    properties:
> +      stream-id-range:
> +        $ref: /schemas/types.yaml#/definitions/uint32-array
> +        description: Stream ID range (address and size) that is assigned by the TBU
> +        items:
> +          minItems: 2
> +          maxItems: 2

This is allowing any property in the TBU nodes. This all needs to move 
to a separate TBU schema.

> +
>  required:
>    - compatible
>    - reg
> @@ -312,6 +333,16 @@ allOf:
>                      through the TCU's programming interface.
>                  - description: bus clock required for the smmu ptw
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: qcom,sdm845-smmu-500
> +    then:
> +      patternProperties:
> +        "^tbu@[0-9a-f]+":
> +          $ref: qcom,qsmmuv500-tbu.yaml

TBU nodes are allowed for all other SMMUs. Is that your intent? If not, 
then the node definition up above should be removed and you would just 
have this if/then schema.

> +
>    - if:
>        properties:
>          compatible:
> diff --git a/Documentation/devicetree/bindings/iommu/qcom,qsmmuv500-tbu.yaml b/Documentation/devicetree/bindings/iommu/qcom,qsmmuv500-tbu.yaml
> new file mode 100644
> index 000000000000..c4f148ae5f38
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/qcom,qsmmuv500-tbu.yaml
> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/qcom,qsmmuv500-tbu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm TBU (Translation Buffer Unit)
> +
> +maintainers:
> +  - Georgi Djakov <quic_c_gdjako at quicinc.com>
> +
> +description:
> +  The Qualcomm SMMU500 implementation consists of TCU and TBU. The TBU contains
> +  a Translation Lookaside Buffer (TLB) that caches page tables. TBUs provides
> +  debug features to trace and trigger debug transactions. There are multiple TBU
> +  instances distributes with each client core.
> +
> +properties:
> +
> +  compatible:
> +    const: qcom,qsmmuv500-tbu
> +
> +  reg:
> +    items:
> +      - description: Address and size of the TBU's register space.
> +
> +  clocks:
> +    maxItems: 1
> +
> +  interconnects:
> +    maxItems: 1
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  stream-id-range:
> +    $ref: "arm,smmu.yaml#/patternProperties/^tbu@[0-9a-f]+/properties/stream-id-range"

No. We generally don't reference properties this way. Partly because not 
all regex's work as a path.

You need a base TBU schema of the common properties that is referenced 
at the top level here. That should also solve the above problem.

> +
> +required:
> +  - compatible
> +  - reg
> +  - stream-id-range
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/qcom,gcc-sdm845.h>
> +    #include <dt-bindings/interconnect/qcom,icc.h>
> +    #include <dt-bindings/interconnect/qcom,sdm845.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/power/qcom-rpmpd.h>
> +
> +    apps_smmu: iommu at 15000000 {

Drop unused labels.

> +        compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
> +        reg = <0x15000000 0x80000>;
> +        ranges = <0 0 0 0 0xffffffff>;
> +        #iommu-cells = <2>;
> +        #global-interrupts = <1>;
> +        interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
> +                     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>;
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        anoc_1_pcie_tbu: tbu at 150e1000 {
> +            compatible = "qcom,qsmmuv500-tbu";
> +            reg = <0x0 0x150e1000 0x0 0x1000>;
> +            clocks = <&gcc GCC_AGGRE_NOC_PCIE_TBU_CLK>;
> +            interconnects = <&system_noc MASTER_GNOC_SNOC QCOM_ICC_TAG_ACTIVE_ONLY
> +                             &config_noc SLAVE_IMEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
> +            power-domains = <&gcc HLOS1_VOTE_AGGRE_NOC_MMU_PCIE_TBU_GDSC>;
> +            stream-id-range = <0x1c00 0x400>;
> +        };
> +    };
> +
> +...


From ahalaney at redhat.com  Thu Dec 21 06:30:49 2023
From: ahalaney at redhat.com (Andrew Halaney)
Date: Thu, 21 Dec 2023 08:30:49 -0600
Subject: [PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support for
 2.5G SGMII
In-Reply-To: <8f94489d-5f0e-4166-a14e-4959098a5c80@quicinc.com>
References: <20231218071118.21879-1-quic_snehshah@quicinc.com>
 <4zbf5fmijxnajk7kygcjrcusf6tdnuzsqqboh23nr6f3rb3c4g@qkfofhq7jmv6>
 <8b80ab09-8444-4c3d-83b0-c7dbf5e58658@quicinc.com>
 <wvzhz4fmtheculsiag4t2pn2kaggyle2mzhvawbs4m5isvqjto@lmaonvq3c3e7>
 <8f94489d-5f0e-4166-a14e-4959098a5c80@quicinc.com>
Message-ID: <vvlnwiobrgcwuam6lkud2np5xqocj6asjf627j3gekkhm4hfp5@vhdd47fyortm>

On Thu, Dec 21, 2023 at 02:23:57PM +0530, Sneh Shah wrote:
> 
> 
> On 12/20/2023 9:29 PM, Andrew Halaney wrote:
> > On Wed, Dec 20, 2023 at 01:02:45PM +0530, Sneh Shah wrote:
> >>
> >>
> >> On 12/18/2023 9:50 PM, Andrew Halaney wrote:
> >>> On Mon, Dec 18, 2023 at 12:41:18PM +0530, Sneh Shah wrote:
> >>>> Serdes phy needs to operate at 2500 mode for 2.5G speed and 1000
> >>>> mode for 1G/100M/10M speed.
> >>>> Added changes to configure serdes phy and mac based on link speed.
> >>>>
> >>>> Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
> >>>> ---
> >>>>  .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 31 +++++++++++++++++--
> >>>>  1 file changed, 29 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> >>>> index d3bf42d0fceb..b3a28dc19161 100644
> >>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> >>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> >>>> @@ -21,6 +21,7 @@
> >>>>  #define RGMII_IO_MACRO_CONFIG2		0x1C
> >>>>  #define RGMII_IO_MACRO_DEBUG1		0x20
> >>>>  #define EMAC_SYSTEM_LOW_POWER_DEBUG	0x28
> >>>> +#define ETHQOS_MAC_AN_CTRL		0xE0
> >>>>  
> >>>>  /* RGMII_IO_MACRO_CONFIG fields */
> >>>>  #define RGMII_CONFIG_FUNC_CLK_EN		BIT(30)
> >>>> @@ -78,6 +79,10 @@
> >>>>  #define ETHQOS_MAC_CTRL_SPEED_MODE		BIT(14)
> >>>>  #define ETHQOS_MAC_CTRL_PORT_SEL		BIT(15)
> >>>>  
> >>>> +/*ETHQOS_MAC_AN_CTRL bits */
> >>>> +#define ETHQOS_MAC_AN_CTRL_RAN			BIT(9)
> >>>> +#define ETHQOS_MAC_AN_CTRL_ANE			BIT(12)
> >>>> +
> >>>
> >>> nit: space please add a space before ETHQOS_MAC_AN_CTRL
> >>>
> >> will take care of this in next patch
> >>
> >>>>  struct ethqos_emac_por {
> >>>>  	unsigned int offset;
> >>>>  	unsigned int value;
> >>>> @@ -109,6 +114,7 @@ struct qcom_ethqos {
> >>>>  	unsigned int num_por;
> >>>>  	bool rgmii_config_loopback_en;
> >>>>  	bool has_emac_ge_3;
> >>>> +	unsigned int serdes_speed;
> > 
> > Another nit as I look closer: I think this should be grouped by phy_mode
> > etc just for readability.
> Didn't get this. can you please elaborate more?

I meant instead of this:

    struct qcom_ethqos {
	    struct platform_device *pdev;
	    void __iomem *rgmii_base;
	    void __iomem *mac_base;
	    int (*configure_func)(struct qcom_ethqos *ethqos);

	    unsigned int link_clk_rate;
	    struct clk *link_clk;
	    struct phy *serdes_phy;
	    unsigned int speed;
	    phy_interface_t phy_mode;

	    const struct ethqos_emac_por *por;
	    unsigned int num_por;
	    bool rgmii_config_loopback_en;
	    bool has_emac_ge_3;
	    unsigned int serdes_speed;
    };

I think this would make more logical sense:

    struct qcom_ethqos {
	    struct platform_device *pdev;
	    void __iomem *rgmii_base;
	    void __iomem *mac_base;
	    int (*configure_func)(struct qcom_ethqos *ethqos);

	    unsigned int link_clk_rate;
	    struct clk *link_clk;
	    struct phy *serdes_phy;
	    unsigned int serdes_speed;
	    unsigned int speed;
	    phy_interface_t phy_mode;

	    const struct ethqos_emac_por *por;
	    unsigned int num_por;
	    bool rgmii_config_loopback_en;
	    bool has_emac_ge_3;
    };

It is definitely nit picking though :)
> > 
> >>>>  };
> >>>>  
> >>>>  static int rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
> >>>> @@ -600,27 +606,47 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos)
> >>>>  
> >>>>  static int ethqos_configure_sgmii(struct qcom_ethqos *ethqos)
> >>>>  {
> >>>> -	int val;
> >>>> -
> >>>> +	int val, mac_an_value;
> >>>>  	val = readl(ethqos->mac_base + MAC_CTRL_REG);
> >>>> +	mac_an_value = readl(ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
> >>>>  
> >>>>  	switch (ethqos->speed) {
> >>>> +	case SPEED_2500:
> >>>> +		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
> >>>> +		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >>>> +			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >>>> +			      RGMII_IO_MACRO_CONFIG2);
> >>>> +		if (ethqos->serdes_speed != SPEED_2500)
> >>>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> >>>> +		mac_an_value &= ~ETHQOS_MAC_AN_CTRL_ANE;
> >>>> +		break;
> >>>>  	case SPEED_1000:
> >>>>  		val &= ~ETHQOS_MAC_CTRL_PORT_SEL;
> >>>>  		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >>>>  			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
> >>>>  			      RGMII_IO_MACRO_CONFIG2);
> >>>> +		if (ethqos->serdes_speed != SPEED_1000)
> >>>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> >>>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
> >>>>  		break;
> >>>>  	case SPEED_100:
> >>>>  		val |= ETHQOS_MAC_CTRL_PORT_SEL | ETHQOS_MAC_CTRL_SPEED_MODE;
> >>>> +		if (ethqos->serdes_speed != SPEED_1000)
> >>>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> >>>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
> >>>>  		break;
> >>>>  	case SPEED_10:
> >>>>  		val |= ETHQOS_MAC_CTRL_PORT_SEL;
> >>>>  		val &= ~ETHQOS_MAC_CTRL_SPEED_MODE;
> >>>> +		if (ethqos->serdes_speed != SPEED_1000)
> >>>> +			phy_set_speed(ethqos->serdes_phy, ethqos->speed);
> >>>> +		mac_an_value |= ETHQOS_MAC_AN_CTRL_RAN | ETHQOS_MAC_AN_CTRL_ANE;
> >>>>  		break;
> >>>>  	}
> >>>>  
> >>>>  	writel(val, ethqos->mac_base + MAC_CTRL_REG);
> >>>> +	writel(mac_an_value, ethqos->mac_base + ETHQOS_MAC_AN_CTRL);
> >>>> +	ethqos->serdes_speed = ethqos->speed;
> >>>
> >>> I see these bits are generic and there's some functions in stmmac_pcs.h
> >>> that muck with these...
> >>>
> >>> Could you help me understand if this really should be Qualcomm specific,
> >>> or if this is something that should be considered for the more core bits
> >>> of the driver? I feel in either case we should take advantage of the
> >>> common definitions in that file if possible.
> >>>
> >> we do have function dwmac_ctrl_ane in core driver which updates same registers. However, it does not have the option to reset ANE bit, it can only set bits. For SPEED_2500 we need to reset ANE bit. Hence I am adding it here. Not sure if we can extend dwmac_ctrl_ane function to reset bits as well.
> > 
> > I'd evaluate if you can update that function to clear the ANE bit when
> > the ane boolean is false. From the usage I see I feel that makes sense,
> > but correct me if you think I'm wrong.
> > At the very least let's use the defines from there, and possibly add a
> > new function if clearing is not acceptable in dwmac_ctrl_ane().
> > 
> > Stepping back, I was asking in general is the need to muck with ANE here
> > is a Qualcomm specific problem, or is that a generic thing that should be
> > handled in the core (and the phy_set_speed() bit stay here)? i.e. would
> > any dwmac5 based IP need to do something like this for SPEED_2500?
> I think disabling ANE for SPEED_2500 is generic not specific to qualcomm. Even in dwxgmac2 versions also we need to disable ANE for SPEED_2500. Autoneg clause 37 stadard doesn't support 2500 speed. So we need to disable autoneg for speed 2500

Another nit, sorry for being so picky. Can you please wrap your emails
to around 80 characters? That's the general etiquette when replying
on-list, makes it easier to read (similar to say a commit message).

Thanks for explaining that. Then in my opinion based on what you've said
I think the disabling of ANE for SPEED_2500 should be done outside of
the Qualcomm platform code.

Note, I'm struggling to keep up with the standards at play here, so if
someone else who's a bit more wise on these topics has an opinion I'd
listen to them. I find myself rewatching this presentation from
Maxime/Antoine as a primer on all of this:

    https://www.youtube.com/watch?v=K962S9gTBVM

If anyone's got any recommended resources for me to read in particular I
am all ears.

I'll be out the next 2-3 weeks, so don't wait for any responses from me
:)

Thanks,
Andrew

> 
> > 
> >>>>  
> >>>>  	return val;
> >>>>  }
> >>>> @@ -789,6 +815,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> >>>>  				     "Failed to get serdes phy\n");
> >>>>  
> >>>>  	ethqos->speed = SPEED_1000;
> >>>> +	ethqos->serdes_speed = SPEED_1000;
> >>>>  	ethqos_update_link_clk(ethqos, SPEED_1000);
> >>>>  	ethqos_set_func_clk_en(ethqos);
> >>>>  
> >>>> -- 
> >>>> 2.17.1
> >>>>
> >>>
> >>
> > 
> 



From sui.jingfeng at linux.dev  Thu Dec 21 06:33:21 2023
From: sui.jingfeng at linux.dev (Sui Jingfeng)
Date: Thu, 21 Dec 2023 22:33:21 +0800
Subject: [v5,40/44] drm/sun4i: hdmi: Convert encoder to atomic
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-40-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-40-6538e19d634d@kernel.org>
Message-ID: <29c8523b-6554-4716-91dd-b4e7c0697b33@linux.dev>

Hi,


LGTM,


On 2023/12/7 23:50, Maxime Ripard wrote:
> The sun4i_hdmi driver still uses the non-atomic variants of the encoder
> hooks, so let's convert to their atomic equivalents.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>

Acked-by: Sui Jingfeng <sui.jingfeng at linux.dev>



From wahrenst at gmx.net  Thu Dec 21 06:40:22 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Thu, 21 Dec 2023 15:40:22 +0100
Subject: [PATCH RFT 2/2] ARM: dts: mxs: imx28: Fix NAND hierarchy
 description
In-Reply-To: <bf76aa11-7005-4bf8-836b-fce616afcdf4@armadeus.com>
References: <20231218130656.9020-1-wahrenst@gmx.net>
 <20231218130656.9020-2-wahrenst@gmx.net>
 <bf76aa11-7005-4bf8-836b-fce616afcdf4@armadeus.com>
Message-ID: <786de238-0ad3-4632-85a5-1b9b5c76fcea@gmx.net>

Hi,

Am 21.12.23 um 10:56 schrieb S?bastien Szymanski:
> Hello Stefan,
>
> On 12/18/23 14:06, Stefan Wahren wrote:
>> The size-cells for GPMI are wrong in imx28.dtsi, which causes the
>> following warning:
>>
>> ???? nand-controller at 8000c000: #size-cells:0:0: 0 was expected
>>
>> The reason for this is the definition of the partitions directly
>> below the nand controller node. According to nand-controller.yaml
>> the NAND chip must be defined as a child of the controller. Even
>> the fixed partitions must be kept in a partitions container.
>>
>> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
>> ---
>>
>> Hi,
>> unfortunately i don't have access to MSR M28CU3 or an Armadeus 
>> Systems APF28
>> so it would be nice if someone can give a try.
>
> I have tried this patch on an APF28. Unfortunately it doesn't work:
>
> [??? 0.000000] Booting Linux on physical CPU 0x0
> [??? 0.000000] Linux version 6.7.0-rc6 (sszy at gentoo) 
> (arm-buildroot-linux-gnueabi-gcc.br_real (Buildroot 
> armadeus-7.0-387-g06d2e893315e-dirty) 12.3.0, GNU ld (GNU Binutils) 
> 2.40) #1 Thu Dec 21 10:24:41 CET 2023
>
> ...
>
> [??? 4.224482] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> [??? 4.231238] nand: Micron MT29F2G08ABAEAWP
> [??? 4.235399] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 
> 2048, OOB size: 64
> [??? 4.245851] Scanning device for bad blocks
> [??? 4.252904] Bad eraseblock 0 at 0x000000000000
> [??? 4.257842] Bad eraseblock 1 at 0x000000020000
> [??? 4.262972] Bad eraseblock 2 at 0x000000040000
> [??? 4.267886] Bad eraseblock 3 at 0x000000060000
> [??? 4.272994] Bad eraseblock 4 at 0x000000080000
> [??? 4.277900] Bad eraseblock 5 at 0x0000000a0000
> [??? 4.283007] Bad eraseblock 6 at 0x0000000c0000
> [??? 4.287916] Bad eraseblock 7 at 0x0000000e0000
> [??? 5.443712] gpmi-nand: ofpart partition 
> /apb at 80000000/apbh at 80000000/nand-controller at 8000c000/nand at 0 
> (/apb at 80000000/apbh at 80000000/nand-controller at 8000c000) #size-cells is 
> wrongly set to <0>, assuming <1> for parsing partitions.

i was too naive by assuming that dt-binding and driver are in sync. I 
looked a little bit at the code and DT parsing is done outside of 
gpmi-nand by parsers/ofpart_core. So at least the right part is 
triggered. Unfortunately the parser seems to look at the wrong node.

Unfortunately i don't have a NAND setup to investigate further. Sorry, i 
thought this was a low hanging fruit :-(

> [ 5.464436] gpmi-nand: error parsing ofpart partition 
> /apb at 80000000/apbh at 80000000/nand-controller at 8000c000/nand at 0 
> (/apb at 80000000/apbh at 80000000/nand-controller at 8000c000)
> [??? 5.523845] gpmi-nand 8000c000.nand-controller: driver registered.
>
> Without this patch:
>
> [??? 5.443988] 7 fixed-partitions partitions found on MTD device 
> gpmi-nand
> [??? 5.450992] Creating 7 MTD partitions on "gpmi-nand":
> [??? 5.456234] 0x000000000000-0x000000300000 : "u-boot"
> [??? 5.506409] 0x000000300000-0x000000380000 : "env"
> [??? 5.537298] 0x000000380000-0x000000400000 : "env2"
> [??? 5.568253] 0x000000400000-0x000000480000 : "dtb"
> [??? 5.598940] 0x000000480000-0x000000500000 : "splash"
> [??? 5.629766] 0x000000500000-0x000000d00000 : "kernel"
> [??? 5.661523] 0x000000d00000-0x000010000000 : "rootfs"
> [??? 5.710012] gpmi-nand 8000c000.nand-controller: driver registered.
>
> Regards,
>
>>
>> ? arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts? | 64 +++++++++++++---------
>> ? arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi?? |? 2 -
>> ? arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts | 28 ++++++----
>> ? arch/arm/boot/dts/nxp/mxs/imx28.dtsi?????? |? 2 +-
>> ? 4 files changed, 56 insertions(+), 40 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts 
>> b/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts
>> index 98672932e41b..10bfac31f672 100644
>> --- a/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts
>> +++ b/arch/arm/boot/dts/nxp/mxs/imx28-apf28.dts
>> @@ -27,39 +27,49 @@ &gpmi {
>> ????? pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
>> ????? status = "okay";
>>
>> -??? partition at 0 {
>> -??????? label = "u-boot";
>> -??????? reg = <0x0 0x300000>;
>> -??? };
>> +??? nand at 0 {
>> +??????? reg = <0>;
>>
>> -??? partition at 300000 {
>> -??????? label = "env";
>> -??????? reg = <0x300000 0x80000>;
>> -??? };
>> +??????? partitions {
>> +??????????? compatible = "fixed-partitions";
>> +??????????? #address-cells = <1>;
>> +??????????? #size-cells = <1>;
>>
>> -??? partition at 380000 {
>> -??????? label = "env2";
>> -??????? reg = <0x380000 0x80000>;
>> -??? };
>> +??????????? partition at 0 {
>> +??????????????? label = "u-boot";
>> +??????????????? reg = <0x0 0x300000>;
>> +??????????? };
>>
>> -??? partition at 400000 {
>> -??????? label = "dtb";
>> -??????? reg = <0x400000 0x80000>;
>> -??? };
>> +??????????? partition at 300000 {
>> +??????????????? label = "env";
>> +??????????????? reg = <0x300000 0x80000>;
>> +??????????? };
>>
>> -??? partition at 480000 {
>> -??????? label = "splash";
>> -??????? reg = <0x480000 0x80000>;
>> -??? };
>> +??????????? partition at 380000 {
>> +??????????????? label = "env2";
>> +??????????????? reg = <0x380000 0x80000>;
>> +??????????? };
>>
>> -??? partition at 500000 {
>> -??????? label = "kernel";
>> -??????? reg = <0x500000 0x800000>;
>> -??? };
>> +??????????? partition at 400000 {
>> +??????????????? label = "dtb";
>> +??????????????? reg = <0x400000 0x80000>;
>> +??????????? };
>> +
>> +??????????? partition at 480000 {
>> +??????????????? label = "splash";
>> +??????????????? reg = <0x480000 0x80000>;
>> +??????????? };
>> +
>> +??????????? partition at 500000 {
>> +??????????????? label = "kernel";
>> +??????????????? reg = <0x500000 0x800000>;
>> +??????????? };
>>
>> -??? partition at d00000 {
>> -??????? label = "rootfs";
>> -??????? reg = <0xd00000 0xf300000>;
>> +??????????? partition at d00000 {
>> +??????????????? label = "rootfs";
>> +??????????????? reg = <0xd00000 0xf300000>;
>> +??????????? };
>> +??????? };
>> ????? };
>> ? };
>>
>> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi 
>> b/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi
>> index 66facef10ba9..54b0f715f091 100644
>> --- a/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi
>> +++ b/arch/arm/boot/dts/nxp/mxs/imx28-m28.dtsi
>> @@ -24,8 +24,6 @@ reg_3p3v: regulator-0 {
>> ? };
>>
>> ? &gpmi {
>> -??? #address-cells = <1>;
>> -??? #size-cells = <1>;
>> ????? pinctrl-names = "default";
>> ????? pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
>> ????? status = "okay";
>> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts 
>> b/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts
>> index 34b4d3246db1..d069ac907490 100644
>> --- a/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts
>> +++ b/arch/arm/boot/dts/nxp/mxs/imx28-m28cu3.dts
>> @@ -93,21 +93,29 @@ &duart {
>> ? };
>>
>> ? &gpmi {
>> -??? #address-cells = <1>;
>> -??? #size-cells = <1>;
>> ????? pinctrl-names = "default";
>> ????? pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
>> ????? status = "okay";
>>
>> -??? partition at 0 {
>> -??????? label = "gpmi-nfc-0-boot";
>> -??????? reg = <0x00000000 0x01400000>;
>> -??????? read-only;
>> -??? };
>> +??? nand at 0 {
>> +??????? reg = <0>;
>>
>> -??? partition at 1 {
>> -??????? label = "gpmi-nfc-general-use";
>> -??????? reg = <0x01400000 0x0ec00000>;
>> +??????? partitions {
>> +??????????? compatible = "fixed-partitions";
>> +??????????? #address-cells = <1>;
>> +??????????? #size-cells = <1>;
>> +
>> +??????????? partition at 0 {
>> +??????????????? label = "gpmi-nfc-0-boot";
>> +??????????????? reg = <0x00000000 0x01400000>;
>> +??????????????? read-only;
>> +??????????? };
>> +
>> +??????????? partition at 1 {
>> +??????????????? label = "gpmi-nfc-general-use";
>> +??????????????? reg = <0x01400000 0x0ec00000>;
>> +??????????? };
>> +??????? };
>> ????? };
>> ? };
>>
>> diff --git a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi 
>> b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
>> index 4817fba2d938..9655403b7f90 100644
>> --- a/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
>> +++ b/arch/arm/boot/dts/nxp/mxs/imx28.dtsi
>> @@ -99,7 +99,7 @@ perfmon: perfmon at 80006000 {
>> ????????????? gpmi: nand-controller at 8000c000 {
>> ????????????????? compatible = "fsl,imx28-gpmi-nand";
>> ????????????????? #address-cells = <1>;
>> -??????????????? #size-cells = <1>;
>> +??????????????? #size-cells = <0>;
>> ????????????????? reg = <0x8000c000 0x2000>, <0x8000a000 0x2000>;
>> ????????????????? reg-names = "gpmi-nand", "bch";
>> ????????????????? interrupts = <41>;
>> -- 
>> 2.34.1
>>
>


From lee at kernel.org  Thu Dec 21 06:40:34 2023
From: lee at kernel.org (Lee Jones)
Date: Thu, 21 Dec 2023 14:40:34 +0000
Subject: (subset) [PATCH] mfd: ab8500-sysctrl: Drop ancient charger
In-Reply-To: <20231214-ab8500-sysctrl-oneliner-v1-1-fd78a15c0b2f@linaro.org>
References: <20231214-ab8500-sysctrl-oneliner-v1-1-fd78a15c0b2f@linaro.org>
Message-ID: <170316963447.599575.18294304575878441440.b4-ty@kernel.org>

On Thu, 14 Dec 2023 19:26:31 +0100, Linus Walleij wrote:
> The sysctrl driver was looking for an instance of the PM2301
> charger but this has been deleted from the kernel and is not
> used with the U8500 systems any more. Drop the string.
> 
> 

Applied, thanks!

[1/1] mfd: ab8500-sysctrl: Drop ancient charger
      commit: 9aab3f5b572eca8f4f2c3ffbbf4aeecf7d5cadb9

--
Lee Jones [???]



From sui.jingfeng at linux.dev  Thu Dec 21 06:43:39 2023
From: sui.jingfeng at linux.dev (Sui Jingfeng)
Date: Thu, 21 Dec 2023 22:43:39 +0800
Subject: [v5,41/44] drm/sun4i: hdmi: Move mode_set into enable
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-41-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-41-6538e19d634d@kernel.org>
Message-ID: <df5406ae-aca4-459f-bf70-4a5efbf3864e@linux.dev>

Hi,


On 2023/12/7 23:50, Maxime Ripard wrote:
> We're not doing anything special in atomic_mode_set so we can simply
> merge it into atomic_enable.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>


Acked-by: Sui Jingfeng <sui.jingfeng at linux.dev>



From krzysztof.kozlowski at linaro.org  Thu Dec 21 06:45:17 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 15:45:17 +0100
Subject: [PATCH] dt-bindings: arm: sunxi: sort alphabetically
In-Reply-To: <20231221140614.639697-1-andre.przywara@arm.com>
References: <20231221140614.639697-1-andre.przywara@arm.com>
Message-ID: <ab8e7d68-c09c-47ff-9f31-08b073387403@linaro.org>

On 21/12/2023 15:06, Andre Przywara wrote:
> The sunxi.yaml file, holding all known board compatible names for
> devices with Allwinner SoCs, is apparently sorted alphabetically, by the
> "description" entry. However there are a few outliers.
> 
> Re-order the entries to get a strict alphabetical ordering, so that:
> $ grep description: sunxi.yaml | sort -fc
> returns empty-handed. There is no change otherwise.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

What was the existing order? Aren't this just shuffling again things?

Best regards,
Krzysztof



From robh at kernel.org  Thu Dec 21 06:45:59 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 21 Dec 2023 08:45:59 -0600
Subject: [PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings
 for STM32 LVDS device
In-Reply-To: <20231221124339.420119-3-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
 <20231221124339.420119-3-raphael.gallais-pou@foss.st.com>
Message-ID: <170316995910.3869238.14321525013510097521.robh@kernel.org>


On Thu, 21 Dec 2023 13:43:33 +0100, Raphael Gallais-Pou wrote:
> Add dt-binding file for "st,stm32-lvds" compatible.
> 
> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
> ---
>  .../bindings/display/st,stm32-lvds.yaml       | 114 ++++++++++++++++++
>  1 file changed, 114 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/display/st,stm32-lvds.example.dts:18:18: fatal error: dt-bindings/bus/stm32mp25_sys_bus.h: No such file or directory
   18 |         #include <dt-bindings/bus/stm32mp25_sys_bus.h>
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/st,stm32-lvds.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: dt_binding_check] Error 2
make: *** [Makefile:234: __sub-make] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231221124339.420119-3-raphael.gallais-pou at foss.st.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From lee at kernel.org  Thu Dec 21 06:49:24 2023
From: lee at kernel.org (Lee Jones)
Date: Thu, 21 Dec 2023 14:49:24 +0000
Subject: (subset) [PATCH v1 1/1] leds: sun50i-a100: Convert to be
 agnostic to property provider
In-Reply-To: <20231214192131.1309912-1-andriy.shevchenko@linux.intel.com>
References: <20231214192131.1309912-1-andriy.shevchenko@linux.intel.com>
Message-ID: <170317016487.605235.6036458810231529969.b4-ty@kernel.org>

On Thu, 14 Dec 2023 21:21:31 +0200, Andy Shevchenko wrote:
> Convert the driver to be agnostic to the property provider.
> LEDS subsytem is not dependent on OF, so no need to make drivers
> be a such.
> 
> 

Applied, thanks!

[1/1] leds: sun50i-a100: Convert to be agnostic to property provider
      commit: 06c5206ccdb459de95bb8d558602d2a722dd4bbc

--
Lee Jones [???]



From sui.jingfeng at linux.dev  Thu Dec 21 06:53:26 2023
From: sui.jingfeng at linux.dev (Sui Jingfeng)
Date: Thu, 21 Dec 2023 22:53:26 +0800
Subject: [v5,43/44] drm/sun4i: hdmi: Consolidate atomic_check and
 mode_valid
In-Reply-To: <20231207-kms-hdmi-connector-state-v5-43-6538e19d634d@kernel.org>
References: <20231207-kms-hdmi-connector-state-v5-43-6538e19d634d@kernel.org>
Message-ID: <bf45f0f7-8772-4f95-94b5-0078ac20b8b7@linux.dev>

Hi,


On 2023/12/7 23:50, Maxime Ripard wrote:
> atomic_check and mode_valid do not check for the same things which can
> lead to surprising result if the userspace commits a mode that didn't go
> through mode_valid. Let's merge the two implementations into a function
> called by both.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>


Acked-by: Sui Jingfeng <sui.jingfeng at linux.dev>



From andre.przywara at arm.com  Thu Dec 21 07:07:14 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 21 Dec 2023 15:07:14 +0000
Subject: [PATCH] dt-bindings: arm: sunxi: sort alphabetically
In-Reply-To: <ab8e7d68-c09c-47ff-9f31-08b073387403@linaro.org>
References: <20231221140614.639697-1-andre.przywara@arm.com>
	<ab8e7d68-c09c-47ff-9f31-08b073387403@linaro.org>
Message-ID: <20231221150714.53d40ea3@donnerap.manchester.arm.com>

On Thu, 21 Dec 2023 15:45:17 +0100
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

Hi,

> On 21/12/2023 15:06, Andre Przywara wrote:
> > The sunxi.yaml file, holding all known board compatible names for
> > devices with Allwinner SoCs, is apparently sorted alphabetically, by the
> > "description" entry. However there are a few outliers.
> > 
> > Re-order the entries to get a strict alphabetical ordering, so that:
> > $ grep description: sunxi.yaml | sort -fc
> > returns empty-handed. There is no change otherwise.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara at arm.com>  
> 
> What was the existing order? Aren't this just shuffling again things?

It assume the intention was to order "alphabetically by description", but
there were some out-of-place entries which apparently slipped through
review.

Shall I add a comment at the top to note the order?

Cheers,
Andre


From cristian.marussi at arm.com  Thu Dec 21 07:11:29 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Thu, 21 Dec 2023 15:11:29 +0000
Subject: [PATCH] firmware: arm_scmi: Add multiple protocols registration support
Message-ID: <20231221151129.325749-1-cristian.marussi@arm.com>

Add the capability for one SCMI driver to register with the core SCMI stack
to use multiple SCMI protocols: in such a case the SCMI driver probe
function will end up being called once for each registered protocol which
have been also found as implemented on the platform.

This is especially useful in testing scenarios.

Signed-off-by: Cristian Marussi <cristian.marussi at arm.com>
---
 drivers/firmware/arm_scmi/bus.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index c15928b8c5cc..1f9735dbebec 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -141,6 +141,17 @@ static int scmi_protocol_device_request(const struct scmi_device_id *id_table)
 	return ret;
 }
 
+static int scmi_protocol_table_register(const struct scmi_device_id *id_table)
+{
+	int ret = 0;
+	const struct scmi_device_id *entry;
+
+	for (entry = id_table; entry->name && ret == 0; entry++)
+		ret = scmi_protocol_device_request(entry);
+
+	return ret;
+}
+
 /**
  * scmi_protocol_device_unrequest  - Helper to unrequest a device
  *
@@ -186,6 +197,15 @@ static void scmi_protocol_device_unrequest(const struct scmi_device_id *id_table
 	mutex_unlock(&scmi_requested_devices_mtx);
 }
 
+static void
+scmi_protocol_table_unregister(const struct scmi_device_id *id_table)
+{
+	const struct scmi_device_id *entry;
+
+	for (entry = id_table; entry->name; entry++)
+		scmi_protocol_device_unrequest(entry);
+}
+
 static const struct scmi_device_id *
 scmi_dev_match_id(struct scmi_device *scmi_dev, struct scmi_driver *scmi_drv)
 {
@@ -279,7 +299,7 @@ int scmi_driver_register(struct scmi_driver *driver, struct module *owner,
 	if (!driver->probe)
 		return -EINVAL;
 
-	retval = scmi_protocol_device_request(driver->id_table);
+	retval = scmi_protocol_table_register(driver->id_table);
 	if (retval)
 		return retval;
 
@@ -299,7 +319,7 @@ EXPORT_SYMBOL_GPL(scmi_driver_register);
 void scmi_driver_unregister(struct scmi_driver *driver)
 {
 	driver_unregister(&driver->driver);
-	scmi_protocol_device_unrequest(driver->id_table);
+	scmi_protocol_table_unregister(driver->id_table);
 }
 EXPORT_SYMBOL_GPL(scmi_driver_unregister);
 
-- 
2.43.0



From olteanv at gmail.com  Thu Dec 21 07:16:07 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Thu, 21 Dec 2023 17:16:07 +0200
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal
 MDIO bus
In-Reply-To: <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231220173539.59071-1-arinc.unal@arinc9.com>
References: <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231220173539.59071-1-arinc.unal@arinc9.com>
Message-ID: <20231221151607.ujobhh4aet4obxdz@skbuf>

On Wed, Dec 20, 2023 at 07:35:39PM +0200, Ar?n? ?NAL wrote:
> From: David Bauer <mail at david-bauer.net>
> 
> The MT753x switches provide a switch-internal MDIO bus for the embedded
> PHYs.
> 
> Register a OF sub-node on the switch OF-node for this internal MDIO bus.
> This allows to configure the embedded PHYs using device-tree.
> 
> Signed-off-by: David Bauer <mail at david-bauer.net>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
> ---

Can you please not assign "bus" to ds->user_mii_bus unless there is no
"mdio" OF node? We don't need ds->user_mii_bus populated when it is
described in device tree.


From vincent.guittot at linaro.org  Thu Dec 21 07:24:02 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 21 Dec 2023 16:24:02 +0100
Subject: [PATCH v2 0/5] Rework system pressure interface to the scheduler
Message-ID: <20231221152407.436177-1-vincent.guittot@linaro.org>

Following the consolidation and cleanup of CPU capacity in [1], this serie
reworks how the scheduler gets the pressures on CPUs. We need to take into
account all pressures applied by cpufreq on the compute capacity of a CPU
for dozens of ms or more and not only cpufreq cooling device or HW
mitigiations. we split the pressure applied on CPU's capacity in 2 parts:
- one from cpufreq and freq_qos
- one from HW high freq mitigiation.

The next step will be to add a dedicated interface for long standing
capping of the CPU capacity (i.e. for seconds or more) like the
scaling_max_freq of cpufreq sysfs. The latter is already taken into
account by this serie but as a temporary pressure which is not always the
best choice when we know that it will happen for seconds or more.

[1] https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot at linaro.org/

Change since v1:
- Use struct cpufreq_policy as parameter of cpufreq_update_pressure()
- Fix typos and comments
- Make sched_thermal_decay_shift boot param as deprecated

Vincent Guittot (5):
  cpufreq: Add a cpufreq pressure feedback for the scheduler
  sched: Take cpufreq feedback into account
  thermal/cpufreq: Remove arch_update_thermal_pressure()
  sched: Rename arch_update_thermal_pressure into
    arch_update_hw_pressure
  sched/pelt: Remove shift of thermal clock

 .../admin-guide/kernel-parameters.txt         |  1 +
 arch/arm/include/asm/topology.h               |  6 +-
 arch/arm64/include/asm/topology.h             |  6 +-
 drivers/base/arch_topology.c                  | 26 ++++----
 drivers/cpufreq/cpufreq.c                     | 34 ++++++++++
 drivers/cpufreq/qcom-cpufreq-hw.c             |  4 +-
 drivers/thermal/cpufreq_cooling.c             |  3 -
 include/linux/arch_topology.h                 |  8 +--
 include/linux/cpufreq.h                       | 10 +++
 include/linux/sched/topology.h                |  8 +--
 .../{thermal_pressure.h => hw_pressure.h}     | 14 ++---
 include/trace/events/sched.h                  |  2 +-
 init/Kconfig                                  | 12 ++--
 kernel/sched/core.c                           |  8 +--
 kernel/sched/fair.c                           | 63 +++++++++----------
 kernel/sched/pelt.c                           | 18 +++---
 kernel/sched/pelt.h                           | 16 ++---
 kernel/sched/sched.h                          | 22 +------
 18 files changed, 142 insertions(+), 119 deletions(-)
 rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)

-- 
2.34.1



From vincent.guittot at linaro.org  Thu Dec 21 07:24:03 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 21 Dec 2023 16:24:03 +0100
Subject: [PATCH v2 1/5] cpufreq: Add a cpufreq pressure feedback for the scheduler
In-Reply-To: <20231221152407.436177-1-vincent.guittot@linaro.org>
References: <20231221152407.436177-1-vincent.guittot@linaro.org>
Message-ID: <20231221152407.436177-2-vincent.guittot@linaro.org>

Provide to the scheduler a feedback about the temporary max available
capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
filtered as the pressure will happen for dozens ms or more.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 drivers/cpufreq/cpufreq.c | 34 ++++++++++++++++++++++++++++++++++
 include/linux/cpufreq.h   | 10 ++++++++++
 2 files changed, 44 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 44db4f59c4cc..15bd41f9bb5e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2563,6 +2563,38 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
 }
 EXPORT_SYMBOL(cpufreq_get_policy);
 
+DEFINE_PER_CPU(unsigned long, cpufreq_pressure);
+
+/**
+ * cpufreq_update_pressure() - Update cpufreq pressure for CPUs
+ * @policy: cpufreq policy of the CPUs.
+ *
+ * Update the value of cpufreq pressure for all @cpus in the policy.
+ */
+static void cpufreq_update_pressure(struct cpufreq_policy *policy)
+{
+	unsigned long max_capacity, capped_freq, pressure;
+	u32 max_freq;
+	int cpu;
+
+	cpu = cpumask_first(policy->related_cpus);
+	pressure = max_capacity = arch_scale_cpu_capacity(cpu);
+	capped_freq = policy->max;
+	max_freq = arch_scale_freq_ref(cpu);
+
+	/*
+	 * Handle properly the boost frequencies, which should simply clean
+	 * the thermal pressure value.
+	 */
+	if (max_freq <= capped_freq)
+		pressure -= max_capacity;
+	else
+		pressure -= mult_frac(max_capacity, capped_freq, max_freq);
+
+	for_each_cpu(cpu, policy->related_cpus)
+		WRITE_ONCE(per_cpu(cpufreq_pressure, cpu), pressure);
+}
+
 /**
  * cpufreq_set_policy - Modify cpufreq policy parameters.
  * @policy: Policy object to modify.
@@ -2618,6 +2650,8 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
 	policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
 	trace_cpu_frequency_limits(policy);
 
+	cpufreq_update_pressure(policy);
+
 	policy->cached_target_freq = UINT_MAX;
 
 	pr_debug("new min and max freqs are %u - %u kHz\n",
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index afda5f24d3dd..b1d97edd3253 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -241,6 +241,12 @@ struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy);
 void cpufreq_enable_fast_switch(struct cpufreq_policy *policy);
 void cpufreq_disable_fast_switch(struct cpufreq_policy *policy);
 bool has_target_index(void);
+
+DECLARE_PER_CPU(unsigned long, cpufreq_pressure);
+static inline unsigned long cpufreq_get_pressure(int cpu)
+{
+	return per_cpu(cpufreq_pressure, cpu);
+}
 #else
 static inline unsigned int cpufreq_get(unsigned int cpu)
 {
@@ -263,6 +269,10 @@ static inline bool cpufreq_supports_freq_invariance(void)
 	return false;
 }
 static inline void disable_cpufreq(void) { }
+static inline unsigned long cpufreq_get_pressure(int cpu)
+{
+	return 0;
+}
 #endif
 
 #ifdef CONFIG_CPU_FREQ_STAT
-- 
2.34.1



From vincent.guittot at linaro.org  Thu Dec 21 07:24:04 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 21 Dec 2023 16:24:04 +0100
Subject: [PATCH v2 2/5] sched: Take cpufreq feedback into account
In-Reply-To: <20231221152407.436177-1-vincent.guittot@linaro.org>
References: <20231221152407.436177-1-vincent.guittot@linaro.org>
Message-ID: <20231221152407.436177-3-vincent.guittot@linaro.org>

Aggregate the different pressures applied on the capacity of CPUs and
create a new function that returns the actual capacity of the CPU:
  get_actual_cpu_capacity()

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>
---
 kernel/sched/fair.c | 45 +++++++++++++++++++++++++--------------------
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bcea3d55d95d..0235081defa5 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4932,13 +4932,22 @@ static inline void util_est_update(struct cfs_rq *cfs_rq,
 	trace_sched_util_est_se_tp(&p->se);
 }
 
+static inline unsigned long get_actual_cpu_capacity(int cpu)
+{
+	unsigned long capacity = arch_scale_cpu_capacity(cpu);
+
+	capacity -= max(thermal_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
+
+	return capacity;
+}
+
 static inline int util_fits_cpu(unsigned long util,
 				unsigned long uclamp_min,
 				unsigned long uclamp_max,
 				int cpu)
 {
-	unsigned long capacity_orig, capacity_orig_thermal;
 	unsigned long capacity = capacity_of(cpu);
+	unsigned long capacity_orig;
 	bool fits, uclamp_max_fits;
 
 	/*
@@ -4970,7 +4979,6 @@ static inline int util_fits_cpu(unsigned long util,
 	 * goal is to cap the task. So it's okay if it's getting less.
 	 */
 	capacity_orig = arch_scale_cpu_capacity(cpu);
-	capacity_orig_thermal = capacity_orig - arch_scale_thermal_pressure(cpu);
 
 	/*
 	 * We want to force a task to fit a cpu as implied by uclamp_max.
@@ -5045,7 +5053,8 @@ static inline int util_fits_cpu(unsigned long util,
 	 * handle the case uclamp_min > uclamp_max.
 	 */
 	uclamp_min = min(uclamp_min, uclamp_max);
-	if (fits && (util < uclamp_min) && (uclamp_min > capacity_orig_thermal))
+	if (fits && (util < uclamp_min) &&
+	    (uclamp_min > get_actual_cpu_capacity(cpu)))
 		return -1;
 
 	return fits;
@@ -7426,7 +7435,7 @@ select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target)
 		 * Look for the CPU with best capacity.
 		 */
 		else if (fits < 0)
-			cpu_cap = arch_scale_cpu_capacity(cpu) - thermal_load_avg(cpu_rq(cpu));
+			cpu_cap = get_actual_cpu_capacity(cpu);
 
 		/*
 		 * First, select CPU which fits better (-1 being better than 0).
@@ -7919,8 +7928,8 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 	struct root_domain *rd = this_rq()->rd;
 	int cpu, best_energy_cpu, target = -1;
 	int prev_fits = -1, best_fits = -1;
-	unsigned long best_thermal_cap = 0;
-	unsigned long prev_thermal_cap = 0;
+	unsigned long best_actual_cap = 0;
+	unsigned long prev_actual_cap = 0;
 	struct sched_domain *sd;
 	struct perf_domain *pd;
 	struct energy_env eenv;
@@ -7950,7 +7959,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 
 	for (; pd; pd = pd->next) {
 		unsigned long util_min = p_util_min, util_max = p_util_max;
-		unsigned long cpu_cap, cpu_thermal_cap, util;
+		unsigned long cpu_cap, cpu_actual_cap, util;
 		long prev_spare_cap = -1, max_spare_cap = -1;
 		unsigned long rq_util_min, rq_util_max;
 		unsigned long cur_delta, base_energy;
@@ -7962,18 +7971,17 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 		if (cpumask_empty(cpus))
 			continue;
 
-		/* Account thermal pressure for the energy estimation */
+		/* Account external pressure for the energy estimation */
 		cpu = cpumask_first(cpus);
-		cpu_thermal_cap = arch_scale_cpu_capacity(cpu);
-		cpu_thermal_cap -= arch_scale_thermal_pressure(cpu);
+		cpu_actual_cap = get_actual_cpu_capacity(cpu);
 
-		eenv.cpu_cap = cpu_thermal_cap;
+		eenv.cpu_cap = cpu_actual_cap;
 		eenv.pd_cap = 0;
 
 		for_each_cpu(cpu, cpus) {
 			struct rq *rq = cpu_rq(cpu);
 
-			eenv.pd_cap += cpu_thermal_cap;
+			eenv.pd_cap += cpu_actual_cap;
 
 			if (!cpumask_test_cpu(cpu, sched_domain_span(sd)))
 				continue;
@@ -8044,7 +8052,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 			if (prev_delta < base_energy)
 				goto unlock;
 			prev_delta -= base_energy;
-			prev_thermal_cap = cpu_thermal_cap;
+			prev_actual_cap = cpu_actual_cap;
 			best_delta = min(best_delta, prev_delta);
 		}
 
@@ -8059,7 +8067,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 			 * but best energy cpu has better capacity.
 			 */
 			if ((max_fits < 0) &&
-			    (cpu_thermal_cap <= best_thermal_cap))
+			    (cpu_actual_cap <= best_actual_cap))
 				continue;
 
 			cur_delta = compute_energy(&eenv, pd, cpus, p,
@@ -8080,14 +8088,14 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 			best_delta = cur_delta;
 			best_energy_cpu = max_spare_cap_cpu;
 			best_fits = max_fits;
-			best_thermal_cap = cpu_thermal_cap;
+			best_actual_cap = cpu_actual_cap;
 		}
 	}
 	rcu_read_unlock();
 
 	if ((best_fits > prev_fits) ||
 	    ((best_fits > 0) && (best_delta < prev_delta)) ||
-	    ((best_fits < 0) && (best_thermal_cap > prev_thermal_cap)))
+	    ((best_fits < 0) && (best_actual_cap > prev_actual_cap)))
 		target = best_energy_cpu;
 
 	return target;
@@ -9465,8 +9473,8 @@ static inline void init_sd_lb_stats(struct sd_lb_stats *sds)
 
 static unsigned long scale_rt_capacity(int cpu)
 {
+	unsigned long max = get_actual_cpu_capacity(cpu);
 	struct rq *rq = cpu_rq(cpu);
-	unsigned long max = arch_scale_cpu_capacity(cpu);
 	unsigned long used, free;
 	unsigned long irq;
 
@@ -9478,12 +9486,9 @@ static unsigned long scale_rt_capacity(int cpu)
 	/*
 	 * avg_rt.util_avg and avg_dl.util_avg track binary signals
 	 * (running and not running) with weights 0 and 1024 respectively.
-	 * avg_thermal.load_avg tracks thermal pressure and the weighted
-	 * average uses the actual delta max capacity(load).
 	 */
 	used = READ_ONCE(rq->avg_rt.util_avg);
 	used += READ_ONCE(rq->avg_dl.util_avg);
-	used += thermal_load_avg(rq);
 
 	if (unlikely(used >= max))
 		return 1;
-- 
2.34.1



From vincent.guittot at linaro.org  Thu Dec 21 07:24:05 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 21 Dec 2023 16:24:05 +0100
Subject: [PATCH v2 3/5] thermal/cpufreq: Remove arch_update_thermal_pressure()
In-Reply-To: <20231221152407.436177-1-vincent.guittot@linaro.org>
References: <20231221152407.436177-1-vincent.guittot@linaro.org>
Message-ID: <20231221152407.436177-4-vincent.guittot@linaro.org>

arch_update_thermal_pressure() aims to update fast changing signal which
should be averaged using PELT filtering before being provided to the
scheduler which can't make smart use of fast changing signal.
cpufreq now provides the maximum freq_qos pressure on the capacity to the
scheduler, which includes cpufreq cooling device. Remove the call to
arch_update_thermal_pressure() in cpufreq cooling device as this is
handled by cpufreq_get_pressure().

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>
---
 drivers/thermal/cpufreq_cooling.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/thermal/cpufreq_cooling.c b/drivers/thermal/cpufreq_cooling.c
index e2cc7bd30862..e77d3b44903e 100644
--- a/drivers/thermal/cpufreq_cooling.c
+++ b/drivers/thermal/cpufreq_cooling.c
@@ -448,7 +448,6 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
 				 unsigned long state)
 {
 	struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
-	struct cpumask *cpus;
 	unsigned int frequency;
 	int ret;
 
@@ -465,8 +464,6 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
 	ret = freq_qos_update_request(&cpufreq_cdev->qos_req, frequency);
 	if (ret >= 0) {
 		cpufreq_cdev->cpufreq_state = state;
-		cpus = cpufreq_cdev->policy->related_cpus;
-		arch_update_thermal_pressure(cpus, frequency);
 		ret = 0;
 	}
 
-- 
2.34.1



From vincent.guittot at linaro.org  Thu Dec 21 07:24:06 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 21 Dec 2023 16:24:06 +0100
Subject: [PATCH v2 4/5] sched: Rename arch_update_thermal_pressure into arch_update_hw_pressure
In-Reply-To: <20231221152407.436177-1-vincent.guittot@linaro.org>
References: <20231221152407.436177-1-vincent.guittot@linaro.org>
Message-ID: <20231221152407.436177-5-vincent.guittot@linaro.org>

Now that cpufreq provides a pressure value to the scheduler, rename
arch_update_thermal_pressure into HW pressure to reflect that it returns
a pressure applied by HW (i.e. with a high frequency change) and not
always related to thermal mitigation but also generated by max current
limitation as an example. Such high frequency signal needs filtering to be
smoothed and provide an value that reflects the average available capacity
into the scheduler time scale.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 arch/arm/include/asm/topology.h               |  6 ++---
 arch/arm64/include/asm/topology.h             |  6 ++---
 drivers/base/arch_topology.c                  | 26 +++++++++----------
 drivers/cpufreq/qcom-cpufreq-hw.c             |  4 +--
 include/linux/arch_topology.h                 |  8 +++---
 include/linux/sched/topology.h                |  8 +++---
 .../{thermal_pressure.h => hw_pressure.h}     | 14 +++++-----
 include/trace/events/sched.h                  |  2 +-
 init/Kconfig                                  | 12 ++++-----
 kernel/sched/core.c                           |  8 +++---
 kernel/sched/fair.c                           | 16 ++++++------
 kernel/sched/pelt.c                           | 18 ++++++-------
 kernel/sched/pelt.h                           | 16 ++++++------
 kernel/sched/sched.h                          | 10 +++----
 14 files changed, 77 insertions(+), 77 deletions(-)
 rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)

diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index 853c4f81ba4a..ad36b6570067 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -22,9 +22,9 @@
 /* Enable topology flag updates */
 #define arch_update_cpu_topology topology_update_cpu_topology
 
-/* Replace task scheduler's default thermal pressure API */
-#define arch_scale_thermal_pressure topology_get_thermal_pressure
-#define arch_update_thermal_pressure	topology_update_thermal_pressure
+/* Replace task scheduler's default HW pressure API */
+#define arch_scale_hw_pressure topology_get_hw_pressure
+#define arch_update_hw_pressure	topology_update_hw_pressure
 
 #else
 
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index a323b109b9c4..0f6ef432fb84 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -35,9 +35,9 @@ void update_freq_counters_refs(void);
 /* Enable topology flag updates */
 #define arch_update_cpu_topology topology_update_cpu_topology
 
-/* Replace task scheduler's default thermal pressure API */
-#define arch_scale_thermal_pressure topology_get_thermal_pressure
-#define arch_update_thermal_pressure	topology_update_thermal_pressure
+/* Replace task scheduler's default HW pressure API */
+#define arch_scale_hw_pressure topology_get_hw_pressure
+#define arch_update_hw_pressure	topology_update_hw_pressure
 
 #include <asm-generic/topology.h>
 
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 0906114963ff..405af7a87008 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -22,7 +22,7 @@
 #include <linux/units.h>
 
 #define CREATE_TRACE_POINTS
-#include <trace/events/thermal_pressure.h>
+#include <trace/events/hw_pressure.h>
 
 static DEFINE_PER_CPU(struct scale_freq_data __rcu *, sft_data);
 static struct cpumask scale_freq_counters_mask;
@@ -160,26 +160,26 @@ void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity)
 	per_cpu(cpu_scale, cpu) = capacity;
 }
 
-DEFINE_PER_CPU(unsigned long, thermal_pressure);
+DEFINE_PER_CPU(unsigned long, hw_pressure);
 
 /**
- * topology_update_thermal_pressure() - Update thermal pressure for CPUs
+ * topology_update_hw_pressure() - Update HW pressure for CPUs
  * @cpus        : The related CPUs for which capacity has been reduced
  * @capped_freq : The maximum allowed frequency that CPUs can run at
  *
- * Update the value of thermal pressure for all @cpus in the mask. The
+ * Update the value of HW pressure for all @cpus in the mask. The
  * cpumask should include all (online+offline) affected CPUs, to avoid
  * operating on stale data when hot-plug is used for some CPUs. The
  * @capped_freq reflects the currently allowed max CPUs frequency due to
- * thermal capping. It might be also a boost frequency value, which is bigger
+ * HW capping. It might be also a boost frequency value, which is bigger
  * than the internal 'capacity_freq_ref' max frequency. In such case the
  * pressure value should simply be removed, since this is an indication that
- * there is no thermal throttling. The @capped_freq must be provided in kHz.
+ * there is no HW throttling. The @capped_freq must be provided in kHz.
  */
-void topology_update_thermal_pressure(const struct cpumask *cpus,
+void topology_update_hw_pressure(const struct cpumask *cpus,
 				      unsigned long capped_freq)
 {
-	unsigned long max_capacity, capacity, th_pressure;
+	unsigned long max_capacity, capacity, hw_pressure;
 	u32 max_freq;
 	int cpu;
 
@@ -189,21 +189,21 @@ void topology_update_thermal_pressure(const struct cpumask *cpus,
 
 	/*
 	 * Handle properly the boost frequencies, which should simply clean
-	 * the thermal pressure value.
+	 * the HW pressure value.
 	 */
 	if (max_freq <= capped_freq)
 		capacity = max_capacity;
 	else
 		capacity = mult_frac(max_capacity, capped_freq, max_freq);
 
-	th_pressure = max_capacity - capacity;
+	hw_pressure = max_capacity - capacity;
 
-	trace_thermal_pressure_update(cpu, th_pressure);
+	trace_hw_pressure_update(cpu, hw_pressure);
 
 	for_each_cpu(cpu, cpus)
-		WRITE_ONCE(per_cpu(thermal_pressure, cpu), th_pressure);
+		WRITE_ONCE(per_cpu(hw_pressure, cpu), hw_pressure);
 }
-EXPORT_SYMBOL_GPL(topology_update_thermal_pressure);
+EXPORT_SYMBOL_GPL(topology_update_hw_pressure);
 
 static ssize_t cpu_capacity_show(struct device *dev,
 				 struct device_attribute *attr,
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index 70b0f21968a0..ec8df5496a0c 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -347,8 +347,8 @@ static void qcom_lmh_dcvs_notify(struct qcom_cpufreq_data *data)
 
 	throttled_freq = freq_hz / HZ_PER_KHZ;
 
-	/* Update thermal pressure (the boost frequencies are accepted) */
-	arch_update_thermal_pressure(policy->related_cpus, throttled_freq);
+	/* Update HW pressure (the boost frequencies are accepted) */
+	arch_update_hw_pressure(policy->related_cpus, throttled_freq);
 
 	/*
 	 * In the unlikely case policy is unregistered do not enable
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index a63d61ca55af..b721f360d759 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -60,14 +60,14 @@ void topology_scale_freq_tick(void);
 void topology_set_scale_freq_source(struct scale_freq_data *data, const struct cpumask *cpus);
 void topology_clear_scale_freq_source(enum scale_freq_source source, const struct cpumask *cpus);
 
-DECLARE_PER_CPU(unsigned long, thermal_pressure);
+DECLARE_PER_CPU(unsigned long, hw_pressure);
 
-static inline unsigned long topology_get_thermal_pressure(int cpu)
+static inline unsigned long topology_get_hw_pressure(int cpu)
 {
-	return per_cpu(thermal_pressure, cpu);
+	return per_cpu(hw_pressure, cpu);
 }
 
-void topology_update_thermal_pressure(const struct cpumask *cpus,
+void topology_update_hw_pressure(const struct cpumask *cpus,
 				      unsigned long capped_freq);
 
 struct cpu_topology {
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index a6e04b4a21d7..e3b2cf7de018 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -264,17 +264,17 @@ unsigned long arch_scale_cpu_capacity(int cpu)
 }
 #endif
 
-#ifndef arch_scale_thermal_pressure
+#ifndef arch_scale_hw_pressure
 static __always_inline
-unsigned long arch_scale_thermal_pressure(int cpu)
+unsigned long arch_scale_hw_pressure(int cpu)
 {
 	return 0;
 }
 #endif
 
-#ifndef arch_update_thermal_pressure
+#ifndef arch_update_hw_pressure
 static __always_inline
-void arch_update_thermal_pressure(const struct cpumask *cpus,
+void arch_update_hw_pressure(const struct cpumask *cpus,
 				  unsigned long capped_frequency)
 { }
 #endif
diff --git a/include/trace/events/thermal_pressure.h b/include/trace/events/hw_pressure.h
similarity index 55%
rename from include/trace/events/thermal_pressure.h
rename to include/trace/events/hw_pressure.h
index b68680201360..b9cd68854128 100644
--- a/include/trace/events/thermal_pressure.h
+++ b/include/trace/events/hw_pressure.h
@@ -1,27 +1,27 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 #undef TRACE_SYSTEM
-#define TRACE_SYSTEM thermal_pressure
+#define TRACE_SYSTEM hw_pressure
 
 #if !defined(_TRACE_THERMAL_PRESSURE_H) || defined(TRACE_HEADER_MULTI_READ)
 #define _TRACE_THERMAL_PRESSURE_H
 
 #include <linux/tracepoint.h>
 
-TRACE_EVENT(thermal_pressure_update,
-	TP_PROTO(int cpu, unsigned long thermal_pressure),
-	TP_ARGS(cpu, thermal_pressure),
+TRACE_EVENT(hw_pressure_update,
+	TP_PROTO(int cpu, unsigned long hw_pressure),
+	TP_ARGS(cpu, hw_pressure),
 
 	TP_STRUCT__entry(
-		__field(unsigned long, thermal_pressure)
+		__field(unsigned long, hw_pressure)
 		__field(int, cpu)
 	),
 
 	TP_fast_assign(
-		__entry->thermal_pressure = thermal_pressure;
+		__entry->hw_pressure = hw_pressure;
 		__entry->cpu = cpu;
 	),
 
-	TP_printk("cpu=%d thermal_pressure=%lu", __entry->cpu, __entry->thermal_pressure)
+	TP_printk("cpu=%d hw_pressure=%lu", __entry->cpu, __entry->hw_pressure)
 );
 #endif /* _TRACE_THERMAL_PRESSURE_H */
 
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index dbb01b4b7451..d115d64c4011 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -752,7 +752,7 @@ DECLARE_TRACE(pelt_dl_tp,
 	TP_PROTO(struct rq *rq),
 	TP_ARGS(rq));
 
-DECLARE_TRACE(pelt_thermal_tp,
+DECLARE_TRACE(pelt_hw_tp,
 	TP_PROTO(struct rq *rq),
 	TP_ARGS(rq));
 
diff --git a/init/Kconfig b/init/Kconfig
index 9ffb103fc927..37ceeb67e01c 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -538,24 +538,24 @@ config HAVE_SCHED_AVG_IRQ
 	depends on IRQ_TIME_ACCOUNTING || PARAVIRT_TIME_ACCOUNTING
 	depends on SMP
 
-config SCHED_THERMAL_PRESSURE
+config SCHED_HW_PRESSURE
 	bool
 	default y if ARM && ARM_CPU_TOPOLOGY
 	default y if ARM64
 	depends on SMP
 	depends on CPU_FREQ_THERMAL
 	help
-	  Select this option to enable thermal pressure accounting in the
-	  scheduler. Thermal pressure is the value conveyed to the scheduler
+	  Select this option to enable HW pressure accounting in the
+	  scheduler. HW pressure is the value conveyed to the scheduler
 	  that reflects the reduction in CPU compute capacity resulted from
-	  thermal throttling. Thermal throttling occurs when the performance of
-	  a CPU is capped due to high operating temperatures.
+	  HW throttling. HW throttling occurs when the performance of
+	  a CPU is capped due to high operating temperatures as an example.
 
 	  If selected, the scheduler will be able to balance tasks accordingly,
 	  i.e. put less load on throttled CPUs than on non/less throttled ones.
 
 	  This requires the architecture to implement
-	  arch_update_thermal_pressure() and arch_scale_thermal_pressure().
+	  arch_update_hw_pressure() and arch_scale_thermal_pressure().
 
 config BSD_PROCESS_ACCT
 	bool "BSD Process Accounting"
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index db4be4921e7f..a6f084bdf1c5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -107,7 +107,7 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_rt_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_dl_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_irq_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_se_tp);
-EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_thermal_tp);
+EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_hw_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(sched_cpu_capacity_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(sched_overutilized_tp);
 EXPORT_TRACEPOINT_SYMBOL_GPL(sched_util_est_cfs_tp);
@@ -5658,7 +5658,7 @@ void scheduler_tick(void)
 	struct rq *rq = cpu_rq(cpu);
 	struct task_struct *curr = rq->curr;
 	struct rq_flags rf;
-	unsigned long thermal_pressure;
+	unsigned long hw_pressure;
 	u64 resched_latency;
 
 	if (housekeeping_cpu(cpu, HK_TYPE_TICK))
@@ -5669,8 +5669,8 @@ void scheduler_tick(void)
 	rq_lock(rq, &rf);
 
 	update_rq_clock(rq);
-	thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
-	update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure);
+	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
+	update_hw_load_avg(rq_clock_hw(rq), rq, hw_pressure);
 	curr->sched_class->task_tick(rq, curr, 0);
 	if (sched_feat(LATENCY_WARN))
 		resched_latency = cpu_resched_latency(rq);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0235081defa5..ce0d32f441a8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -78,7 +78,7 @@ static unsigned int normalized_sysctl_sched_base_slice	= 750000ULL;
 
 const_debug unsigned int sysctl_sched_migration_cost	= 500000UL;
 
-int sched_thermal_decay_shift;
+int sched_hw_decay_shift;
 static int __init setup_sched_thermal_decay_shift(char *str)
 {
 	int _shift = 0;
@@ -86,7 +86,7 @@ static int __init setup_sched_thermal_decay_shift(char *str)
 	if (kstrtoint(str, 0, &_shift))
 		pr_warn("Unable to set scheduler thermal pressure decay shift parameter\n");
 
-	sched_thermal_decay_shift = clamp(_shift, 0, 10);
+	sched_hw_decay_shift = clamp(_shift, 0, 10);
 	return 1;
 }
 __setup("sched_thermal_decay_shift=", setup_sched_thermal_decay_shift);
@@ -4936,7 +4936,7 @@ static inline unsigned long get_actual_cpu_capacity(int cpu)
 {
 	unsigned long capacity = arch_scale_cpu_capacity(cpu);
 
-	capacity -= max(thermal_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
+	capacity -= max(hw_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
 
 	return capacity;
 }
@@ -4969,7 +4969,7 @@ static inline int util_fits_cpu(unsigned long util,
 	 * Similarly if a task is capped to arch_scale_cpu_capacity(little_cpu), it
 	 * should fit a little cpu even if there's some pressure.
 	 *
-	 * Only exception is for thermal pressure since it has a direct impact
+	 * Only exception is for HW or cpufreq pressure since it has a direct impact
 	 * on available OPP of the system.
 	 *
 	 * We honour it for uclamp_min only as a drop in performance level
@@ -9226,7 +9226,7 @@ static inline bool others_have_blocked(struct rq *rq)
 	if (READ_ONCE(rq->avg_dl.util_avg))
 		return true;
 
-	if (thermal_load_avg(rq))
+	if (hw_load_avg(rq))
 		return true;
 
 #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
@@ -9258,7 +9258,7 @@ static bool __update_blocked_others(struct rq *rq, bool *done)
 {
 	const struct sched_class *curr_class;
 	u64 now = rq_clock_pelt(rq);
-	unsigned long thermal_pressure;
+	unsigned long hw_pressure;
 	bool decayed;
 
 	/*
@@ -9267,11 +9267,11 @@ static bool __update_blocked_others(struct rq *rq, bool *done)
 	 */
 	curr_class = rq->curr->sched_class;
 
-	thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
+	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
 
 	decayed = update_rt_rq_load_avg(now, rq, curr_class == &rt_sched_class) |
 		  update_dl_rq_load_avg(now, rq, curr_class == &dl_sched_class) |
-		  update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure) |
+		  update_hw_load_avg(rq_clock_hw(rq), rq, hw_pressure) |
 		  update_irq_load_avg(rq, 0);
 
 	if (others_have_blocked(rq))
diff --git a/kernel/sched/pelt.c b/kernel/sched/pelt.c
index 63b6cf898220..f951c44f1d52 100644
--- a/kernel/sched/pelt.c
+++ b/kernel/sched/pelt.c
@@ -384,30 +384,30 @@ int update_dl_rq_load_avg(u64 now, struct rq *rq, int running)
 	return 0;
 }
 
-#ifdef CONFIG_SCHED_THERMAL_PRESSURE
+#ifdef CONFIG_SCHED_HW_PRESSURE
 /*
- * thermal:
+ * hardware:
  *
  *   load_sum = \Sum se->avg.load_sum but se->avg.load_sum is not tracked
  *
  *   util_avg and runnable_load_avg are not supported and meaningless.
  *
  * Unlike rt/dl utilization tracking that track time spent by a cpu
- * running a rt/dl task through util_avg, the average thermal pressure is
- * tracked through load_avg. This is because thermal pressure signal is
+ * running a rt/dl task through util_avg, the average HW pressure is
+ * tracked through load_avg. This is because HW pressure signal is
  * time weighted "delta" capacity unlike util_avg which is binary.
  * "delta capacity" =  actual capacity  -
- *			capped capacity a cpu due to a thermal event.
+ *			capped capacity a cpu due to a HW event.
  */
 
-int update_thermal_load_avg(u64 now, struct rq *rq, u64 capacity)
+int update_hw_load_avg(u64 now, struct rq *rq, u64 capacity)
 {
-	if (___update_load_sum(now, &rq->avg_thermal,
+	if (___update_load_sum(now, &rq->avg_hw,
 			       capacity,
 			       capacity,
 			       capacity)) {
-		___update_load_avg(&rq->avg_thermal, 1);
-		trace_pelt_thermal_tp(rq);
+		___update_load_avg(&rq->avg_hw, 1);
+		trace_pelt_hw_tp(rq);
 		return 1;
 	}
 
diff --git a/kernel/sched/pelt.h b/kernel/sched/pelt.h
index 3a0e0dc28721..e3ab44c4a2ef 100644
--- a/kernel/sched/pelt.h
+++ b/kernel/sched/pelt.h
@@ -7,21 +7,21 @@ int __update_load_avg_cfs_rq(u64 now, struct cfs_rq *cfs_rq);
 int update_rt_rq_load_avg(u64 now, struct rq *rq, int running);
 int update_dl_rq_load_avg(u64 now, struct rq *rq, int running);
 
-#ifdef CONFIG_SCHED_THERMAL_PRESSURE
-int update_thermal_load_avg(u64 now, struct rq *rq, u64 capacity);
+#ifdef CONFIG_SCHED_HW_PRESSURE
+int update_hw_load_avg(u64 now, struct rq *rq, u64 capacity);
 
-static inline u64 thermal_load_avg(struct rq *rq)
+static inline u64 hw_load_avg(struct rq *rq)
 {
-	return READ_ONCE(rq->avg_thermal.load_avg);
+	return READ_ONCE(rq->avg_hw.load_avg);
 }
 #else
 static inline int
-update_thermal_load_avg(u64 now, struct rq *rq, u64 capacity)
+update_hw_load_avg(u64 now, struct rq *rq, u64 capacity)
 {
 	return 0;
 }
 
-static inline u64 thermal_load_avg(struct rq *rq)
+static inline u64 hw_load_avg(struct rq *rq)
 {
 	return 0;
 }
@@ -202,12 +202,12 @@ update_dl_rq_load_avg(u64 now, struct rq *rq, int running)
 }
 
 static inline int
-update_thermal_load_avg(u64 now, struct rq *rq, u64 capacity)
+update_hw_load_avg(u64 now, struct rq *rq, u64 capacity)
 {
 	return 0;
 }
 
-static inline u64 thermal_load_avg(struct rq *rq)
+static inline u64 hw_load_avg(struct rq *rq)
 {
 	return 0;
 }
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index e58a54bda77d..677d24202eec 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1078,8 +1078,8 @@ struct rq {
 #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
 	struct sched_avg	avg_irq;
 #endif
-#ifdef CONFIG_SCHED_THERMAL_PRESSURE
-	struct sched_avg	avg_thermal;
+#ifdef CONFIG_SCHED_HW_PRESSURE
+	struct sched_avg	avg_hw;
 #endif
 	u64			idle_stamp;
 	u64			avg_idle;
@@ -1531,11 +1531,11 @@ static inline u64 rq_clock_task(struct rq *rq)
  *	3			256
  *	4			512
  */
-extern int sched_thermal_decay_shift;
+extern int sched_hw_decay_shift;
 
-static inline u64 rq_clock_thermal(struct rq *rq)
+static inline u64 rq_clock_hw(struct rq *rq)
 {
-	return rq_clock_task(rq) >> sched_thermal_decay_shift;
+	return rq_clock_task(rq) >> sched_hw_decay_shift;
 }
 
 static inline void rq_clock_skip_update(struct rq *rq)
-- 
2.34.1



From vincent.guittot at linaro.org  Thu Dec 21 07:24:07 2023
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 21 Dec 2023 16:24:07 +0100
Subject: [PATCH v2 5/5] sched/pelt: Remove shift of thermal clock
In-Reply-To: <20231221152407.436177-1-vincent.guittot@linaro.org>
References: <20231221152407.436177-1-vincent.guittot@linaro.org>
Message-ID: <20231221152407.436177-6-vincent.guittot@linaro.org>

The optional shift of the clock used by thermal/hw load avg has been
introduced to handle case where the signal was not always a high frequency
hw signal. Now that cpufreq provides a signal for firmware and
SW pressure, we can remove this exception and always keep this PELT signal
aligned with other signals.
Mark deprecated sched_thermal_decay_shift boot parameter.

Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
---
 .../admin-guide/kernel-parameters.txt          |  1 +
 kernel/sched/core.c                            |  2 +-
 kernel/sched/fair.c                            | 10 ++--------
 kernel/sched/sched.h                           | 18 ------------------
 4 files changed, 4 insertions(+), 27 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 65731b060e3f..2ee15522b15d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5722,6 +5722,7 @@
 			but is useful for debugging and performance tuning.
 
 	sched_thermal_decay_shift=
+			[Deprecated]
 			[KNL, SMP] Set a decay shift for scheduler thermal
 			pressure signal. Thermal pressure signal follows the
 			default decay period of other scheduler pelt
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a6f084bdf1c5..c68e47bfd5ae 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5670,7 +5670,7 @@ void scheduler_tick(void)
 
 	update_rq_clock(rq);
 	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));
-	update_hw_load_avg(rq_clock_hw(rq), rq, hw_pressure);
+	update_hw_load_avg(rq_clock_task(rq), rq, hw_pressure);
 	curr->sched_class->task_tick(rq, curr, 0);
 	if (sched_feat(LATENCY_WARN))
 		resched_latency = cpu_resched_latency(rq);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ce0d32f441a8..16d71e764131 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -78,15 +78,9 @@ static unsigned int normalized_sysctl_sched_base_slice	= 750000ULL;
 
 const_debug unsigned int sysctl_sched_migration_cost	= 500000UL;
 
-int sched_hw_decay_shift;
 static int __init setup_sched_thermal_decay_shift(char *str)
 {
-	int _shift = 0;
-
-	if (kstrtoint(str, 0, &_shift))
-		pr_warn("Unable to set scheduler thermal pressure decay shift parameter\n");
-
-	sched_hw_decay_shift = clamp(_shift, 0, 10);
+	pr_warn("Ignoring the deprecated sched_thermal_decay_shift= option\n");
 	return 1;
 }
 __setup("sched_thermal_decay_shift=", setup_sched_thermal_decay_shift);
@@ -9271,7 +9265,7 @@ static bool __update_blocked_others(struct rq *rq, bool *done)
 
 	decayed = update_rt_rq_load_avg(now, rq, curr_class == &rt_sched_class) |
 		  update_dl_rq_load_avg(now, rq, curr_class == &dl_sched_class) |
-		  update_hw_load_avg(rq_clock_hw(rq), rq, hw_pressure) |
+		  update_hw_load_avg(now, rq, hw_pressure) |
 		  update_irq_load_avg(rq, 0);
 
 	if (others_have_blocked(rq))
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 677d24202eec..6fc6718a1060 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1520,24 +1520,6 @@ static inline u64 rq_clock_task(struct rq *rq)
 	return rq->clock_task;
 }
 
-/**
- * By default the decay is the default pelt decay period.
- * The decay shift can change the decay period in
- * multiples of 32.
- *  Decay shift		Decay period(ms)
- *	0			32
- *	1			64
- *	2			128
- *	3			256
- *	4			512
- */
-extern int sched_hw_decay_shift;
-
-static inline u64 rq_clock_hw(struct rq *rq)
-{
-	return rq_clock_task(rq) >> sched_hw_decay_shift;
-}
-
 static inline void rq_clock_skip_update(struct rq *rq)
 {
 	lockdep_assert_rq_held(rq);
-- 
2.34.1



From hns at goldelico.com  Thu Dec 21 07:23:39 2023
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Thu, 21 Dec 2023 16:23:39 +0100
Subject: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
In-Reply-To: <nzqeqwof44e3nxjz6lsxmxcfh235unbu343br45esxh6vinskp@xvjydpxhvsuk>
References: <23livt5mcc64bb6lkeec2uxp5cyn4wfekwaj6wzrjnrkndvwgj@6tveqglqpr4v>
 <B3A1B8A7-0363-4ECB-AFBF-576FECA569FA@goldelico.com>
 <vawv2mwhonuyvgmp7uox4rfgdcjwg5fa7hmbcfgl3wiase6e4p@tyavpclppfvu>
 <6BC60156-89E2-4734-BD00-B49A9A6C1D7A@goldelico.com>
 <6gpehpoz54f5lxhmvirqbfwmq7dpgiroy27cljpvu66wtn7aqy@lgrh7wysyxnp>
 <D8AB6CC4-DCA5-40DD-A311-94A16FF59254@goldelico.com>
 <oobcl2kfsuph27er7rflfqvt3lu6athufomxv5chf3uctx4emh@x6rzjtlskhbf>
 <F58855EC-D87D-4747-A363-0E7AA5DB1AEC@goldelico.com>
 <22cny5aumc5wafsrjd3j55zcjbjf2viip64kfbjiqis2grtd6t@wg5dxeuzil6l>
 <3E03E913-48E1-49EC-A6C9-EAC1612E65E7@goldelico.com>
 <nzqeqwof44e3nxjz6lsxmxcfh235unbu343br45esxh6vinskp@xvjydpxhvsuk>
Message-ID: <F2D7693E-7769-463A-97A8-BA952EB5320B@goldelico.com>


> Am 21.12.2023 um 09:58 schrieb Maxime Ripard <mripard at kernel.org>:
> 
> Cool, so what you're saying is that your plan is to support those GPUs
> upstream in the imagination driver?

Yes, I would like to see PowerVR Series 5 SGX supported upstream since there
are still so many devices in the wild which could use it. The most advanced
being the Pyra handheld gaming computer but there are omap4 based phones
or other omap3/amm335x based devices.

And the only reason the OpenPVRSGX group was founded (BTW not by me, I am just
maintaining the code and running a mailing list because it was rejected to host
it on vger.kernel.org), was to make that happen.

From the GitHub description:
	This is about shaping existing GPL Linux kernel drivers for the PVR/SGX5
	architecture so that they can become accepted into drivers/staging

But nobody can currently tell if it can be integrated with the recently upstreamed
Rogue driver (I wouldn't call that *the* imagination driver) or if it better stays
a separate driver because the first would need touching closed user-space code
and GPU firmware.

And nobody knows who is capable and willing to work on it. It depends on access to
(confidential) documentation and available time to make such a big task a rewarding
project. And discussions like this one are not at all encouraging to even try.

>> Now, IMHO all the pros and cons are on the table and the question is
>> who makes a decision how to go.
> 
> You haven't listed any pro so far, you're claiming that the one I raise
> are irrelevant.

I have listed some "pros" for "single file" but you apparently don't see
them as such. I can't change that. The main argument is that a single file is
simpler than two files duplicating parts, which are apparently the same
(integration of PVR architectures into SoC doesn't differ very much: shared
register block, DMA memory, clocks, resets etc.).
Yours is that two files duplicating such common things is "more convenient".
I just wonder for whom.

But it seems as if the IMHO second best solution has already been chosen.
So let it be.

>> Then the currently-out-of-tree driver for the sgx5 can be reworked in
>> less than half an hour without loosing functionality.
> 
> Again, you're making it harder than it needs to be for no particular
> reason other than the potential file name clash that can be addressed.

What I want to avoid is a situation that upstream activities do not take the
existing and working out-of-tree SGX driver into account and make porting
(not even speaking of upstreaming) that driver more difficult than necessary
and force device tree files to contain redundant information nobody will need
and use. You can of course ignore experience and suggestions of people
who have worked on an SGX driver for a while. But that is the reason why I
participate in this discussion and raise my voice.

Now, I am looking forward to a v2 of this patch.

BR,
Nikolaus




From lee at kernel.org  Thu Dec 21 07:25:53 2023
From: lee at kernel.org (Lee Jones)
Date: Thu, 21 Dec 2023 15:25:53 +0000
Subject: [PATCH RESEND] iio: adc: sun4i-gpadc-iio: adaptation interrupt
 number
In-Reply-To: <20231220115412.65bbc8c7@donnerap.manchester.arm.com>
References: <YxmR5SPPY18O7LaG@google.com>
 <YwdhTlk+9h+9Mrwm@scg>
 <20231220115412.65bbc8c7@donnerap.manchester.arm.com>
Message-ID: <20231221152553.GM10102@google.com>

On Wed, 20 Dec 2023, Andre Przywara wrote:

> On Wed, 20 Dec 2023 15:23:17 +0800
> fuyao <fuyao1697 at cyg.com> wrote:
> 
> Hi,
> 
> > __platform_get_irq_byname determinies whether the interrupt
> > number is 0 and returns EINVAL.
> 
> can you please say what this fixes, exactly? Is something not working at
> the moment? Can you please provide parts of the error message?
> 
> And maybe expand the explanation a bit more? For instance mention that the
> identifiers are used as IRQ resource numbers, where 0 is treated specially.
> 
> Cheers,
> Andre
> 
> > 
> > Signed-off-by: fuyao <fuyao1697 at cyg.com>

You have to use your full real name as well.

> > Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
> > ---
> >  include/linux/mfd/sun4i-gpadc.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> > index ea0ccf33a459..021f820f9d52 100644
> > --- a/include/linux/mfd/sun4i-gpadc.h
> > +++ b/include/linux/mfd/sun4i-gpadc.h
> > @@ -81,8 +81,8 @@
> >  #define SUN4I_GPADC_TEMP_DATA				0x20
> >  #define SUN4I_GPADC_DATA				0x24
> >  
> > -#define SUN4I_GPADC_IRQ_FIFO_DATA			0
> > -#define SUN4I_GPADC_IRQ_TEMP_DATA			1
> > +#define SUN4I_GPADC_IRQ_FIFO_DATA			1
> > +#define SUN4I_GPADC_IRQ_TEMP_DATA			2
> >  
> >  /* 10s delay before suspending the IP */
> >  #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
> 

-- 
Lee Jones [???]


From lee at kernel.org  Thu Dec 21 07:26:50 2023
From: lee at kernel.org (Lee Jones)
Date: Thu, 21 Dec 2023 15:26:50 +0000
Subject: [PATCH RESEND] iio: adc: sun4i-gpadc-iio: adaptation interrupt
 number
In-Reply-To: <20231221152553.GM10102@google.com>
References: <YxmR5SPPY18O7LaG@google.com>
 <YwdhTlk+9h+9Mrwm@scg>
 <20231220115412.65bbc8c7@donnerap.manchester.arm.com>
 <20231221152553.GM10102@google.com>
Message-ID: <20231221152650.GN10102@google.com>

On Thu, 21 Dec 2023, Lee Jones wrote:

> On Wed, 20 Dec 2023, Andre Przywara wrote:
> 
> > On Wed, 20 Dec 2023 15:23:17 +0800
> > fuyao <fuyao1697 at cyg.com> wrote:
> > 
> > Hi,
> > 
> > > __platform_get_irq_byname determinies whether the interrupt
> > > number is 0 and returns EINVAL.
> > 
> > can you please say what this fixes, exactly? Is something not working at
> > the moment? Can you please provide parts of the error message?
> > 
> > And maybe expand the explanation a bit more? For instance mention that the
> > identifiers are used as IRQ resource numbers, where 0 is treated specially.
> > 
> > Cheers,
> > Andre
> > 
> > > 
> > > Signed-off-by: fuyao <fuyao1697 at cyg.com>
> 
> You have to use your full real name as well.
> 
> > > Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
> > > ---
> > >  include/linux/mfd/sun4i-gpadc.h | 4 ++--

Also the subject line is wrong.

This doesn't have anything to do with IIO.

> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> > > index ea0ccf33a459..021f820f9d52 100644
> > > --- a/include/linux/mfd/sun4i-gpadc.h
> > > +++ b/include/linux/mfd/sun4i-gpadc.h
> > > @@ -81,8 +81,8 @@
> > >  #define SUN4I_GPADC_TEMP_DATA				0x20
> > >  #define SUN4I_GPADC_DATA				0x24
> > >  
> > > -#define SUN4I_GPADC_IRQ_FIFO_DATA			0
> > > -#define SUN4I_GPADC_IRQ_TEMP_DATA			1
> > > +#define SUN4I_GPADC_IRQ_FIFO_DATA			1
> > > +#define SUN4I_GPADC_IRQ_TEMP_DATA			2
> > >  
> > >  /* 10s delay before suspending the IP */
> > >  #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
> > 
> 
> -- 
> Lee Jones [???]

-- 
Lee Jones [???]


From krzysztof.kozlowski at linaro.org  Thu Dec 21 07:38:41 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 16:38:41 +0100
Subject: [PATCH] dt-bindings: arm: sunxi: sort alphabetically
In-Reply-To: <20231221150714.53d40ea3@donnerap.manchester.arm.com>
References: <20231221140614.639697-1-andre.przywara@arm.com>
 <ab8e7d68-c09c-47ff-9f31-08b073387403@linaro.org>
 <20231221150714.53d40ea3@donnerap.manchester.arm.com>
Message-ID: <6721cb2f-4498-4d20-9059-257846005905@linaro.org>

On 21/12/2023 16:07, Andre Przywara wrote:
> On Thu, 21 Dec 2023 15:45:17 +0100
> Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> 
> Hi,
> 
>> On 21/12/2023 15:06, Andre Przywara wrote:
>>> The sunxi.yaml file, holding all known board compatible names for
>>> devices with Allwinner SoCs, is apparently sorted alphabetically, by the
>>> "description" entry. However there are a few outliers.
>>>
>>> Re-order the entries to get a strict alphabetical ordering, so that:
>>> $ grep description: sunxi.yaml | sort -fc
>>> returns empty-handed. There is no change otherwise.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>  
>>
>> What was the existing order? Aren't this just shuffling again things?
> 
> It assume the intention was to order "alphabetically by description", but
> there were some out-of-place entries which apparently slipped through
> review.
> 
> Shall I add a comment at the top to note the order?

Some files like this are ordered by compatible, some by class or family
of devices, so first you need to be sure there is no existing order.

Best regards,
Krzysztof



From ankita at nvidia.com  Thu Dec 21 07:39:58 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Thu, 21 Dec 2023 21:09:58 +0530
Subject: [PATCH v5 0/4] kvm: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
Message-ID: <20231221154002.32622-1-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

Currently, KVM for ARM64 maps at stage 2 memory that is considered device
with DEVICE_nGnRE memory attributes; this setting overrides (per
ARM architecture [1]) any device MMIO mapping present at stage 1,
resulting in a set-up whereby a guest operating system cannot
determine device MMIO mapping memory attributes on its own but
it is always overridden by the KVM stage 2 default.

This set-up does not allow guest operating systems to select device
memory attributes independently from KVM stage-2 mappings
(refer to [1], "Combining stage 1 and stage 2 memory type attributes"),
which turns out to be an issue in that guest operating systems
(e.g. Linux) may request to map devices MMIO regions with memory
attributes that guarantee better performance (e.g. gathering
attribute - that for some devices can generate larger PCIe memory
writes TLPs) and specific operations (e.g. unaligned transactions)
such as the NormalNC memory type.

The default device stage 2 mapping was chosen in KVM for ARM64 since
it was considered safer (i.e. it would not allow guests to trigger
uncontained failures ultimately crashing the machine) but this
turned out to be asynchronous (SError) defeating the purpose.

For these reasons, relax the KVM stage 2 device memory attributes
from DEVICE_nGnRE to Normal-NC.

Generalizing to other devices may be problematic, however. E.g.
GICv2 VCPU interface, which is effectively a shared peripheral, can
allow a guest to affect another guest's interrupt distribution. Hence
limit the change to VFIO PCI as caution. This is achieved by
making the VFIO PCI core module set a flag that is tested by KVM
to activate the code. This could be extended to other devices in
the future once that is deemed safe.

[1] section D8.5 - DDI0487J_a_a-profile_architecture_reference_manual.pdf

Applied over v6.7-rc3.

History
=======
v4 -> v5
- Moved the cover letter description text to patch 1/4.
- Cleaned up stage2_set_prot_attr() based on Marc Zyngier suggestions.
- Moved the mm header file changes to a separate patch.
- Rebased to v6.7-rc3.

v3 -> v4
- Moved the vfio-pci change to use the VM_VFIO_ALLOW_WC into
  separate patch.
- Added check to warn on the case NORMAL_NC and DEVICE are
  set simultaneously.
- Fixed miscellaneous nitpicks suggested in v3.

v2 -> v3
- Added a new patch (and converted to patch series) suggested by
  Catalin Marinas to ensure the code changes are restricted to
  VFIO PCI devices.
- Introduced VM_VFIO_ALLOW_WC flag for VFIO PCI to communicate
  with VMM.
- Reverted GIC mapping to DEVICE.

v1 -> v2
- Updated commit log to the one posted by
  Lorenzo Pieralisi <lpieralisi at kernel.org> (Thanks!)
- Added new flag to represent the NORMAL_NC setting. Updated
  stage2_set_prot_attr() to handle new flag.

v4 Link:
https://lore.kernel.org/all/20231218090719.22250-1-ankita at nvidia.com/

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>

Ankit Agrawal (4):
  kvm: arm64: introduce new flag for non-cacheable IO memory
  mm: introduce new flag to indicate wc safe
  kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices
  vfio: convey kvm that the vfio-pci device is wc safe

 arch/arm64/include/asm/kvm_pgtable.h |  2 ++
 arch/arm64/include/asm/memory.h      |  2 ++
 arch/arm64/kvm/hyp/pgtable.c         | 23 ++++++++++++++++++-----
 arch/arm64/kvm/mmu.c                 | 18 ++++++++++++++----
 drivers/vfio/pci/vfio_pci_core.c     |  3 ++-
 include/linux/mm.h                   | 14 ++++++++++++++
 6 files changed, 52 insertions(+), 10 deletions(-)

-- 
2.17.1



From ankita at nvidia.com  Thu Dec 21 07:40:00 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Thu, 21 Dec 2023 21:10:00 +0530
Subject: [PATCH v5 2/4] mm: introduce new flag to indicate wc safe
In-Reply-To: <20231221154002.32622-1-ankita@nvidia.com>
References: <20231221154002.32622-1-ankita@nvidia.com>
Message-ID: <20231221154002.32622-3-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

Generalizing S2 setting from DEVICE_nGnRE to NormalNc for non PCI
devices may be problematic. E.g. GICv2 vCPU interface, which is
effectively a shared peripheral, can allow a guest to affect another
guest's interrupt distribution. The issue may be solved by limiting
the relaxation to mappings that have a user VMA. Still there is
insufficient information and uncertainity in the behavior of
non PCI drivers.

Add a new flag VM_VFIO_ALLOW_WC to indicate KVM that the device is
WC capable and these S2 changes can be extended to it. KVM can use
this flag to activate the code.

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Jason Gunthorpe <jgg at nvidia.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>
---
 include/linux/mm.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 418d26608ece..49277e845b21 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -391,6 +391,20 @@ extern unsigned int kobjsize(const void *objp);
 # define VM_UFFD_MINOR		VM_NONE
 #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
 
+/*
+ * This flag is used to connect VFIO to arch specific KVM code. It
+ * indicates that the memory under this VMA is safe for use with any
+ * non-cachable memory type inside KVM. Some VFIO devices, on some
+ * platforms, are thought to be unsafe and can cause machine crashes if
+ * KVM does not lock down the memory type.
+ */
+#ifdef CONFIG_64BIT
+#define VM_VFIO_ALLOW_WC_BIT	39
+#define VM_VFIO_ALLOW_WC	BIT(VM_VFIO_ALLOW_WC_BIT)
+#else
+#define VM_VFIO_ALLOW_WC	VM_NONE
+#endif
+
 /* Bits set in the VMA until the stack is in its final location */
 #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
 
-- 
2.17.1



From ankita at nvidia.com  Thu Dec 21 07:39:59 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Thu, 21 Dec 2023 21:09:59 +0530
Subject: [PATCH v5 1/4] kvm: arm64: introduce new flag for non-cacheable IO memory
In-Reply-To: <20231221154002.32622-1-ankita@nvidia.com>
References: <20231221154002.32622-1-ankita@nvidia.com>
Message-ID: <20231221154002.32622-2-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

Currently, KVM for ARM64 maps at stage 2 memory that is considered device
(i.e. it is not RAM) with DEVICE_nGnRE memory attributes; this setting
overrides (as per the ARM architecture [1]) any device MMIO mapping
present at stage 1, resulting in a set-up whereby a guest operating
system cannot determine device MMIO mapping memory attributes on its
own but it is always overridden by the KVM stage 2 default.

This set-up does not allow guest operating systems to select device
memory attributes independently from KVM stage-2 mappings
(refer to [1], "Combining stage 1 and stage 2 memory type attributes"),
which turns out to be an issue in that guest operating systems
(e.g. Linux) may request to map devices MMIO regions with memory
attributes that guarantee better performance (e.g. gathering
attribute - that for some devices can generate larger PCIe memory
writes TLPs) and specific operations (e.g. unaligned transactions)
such as the NormalNC memory type.

The default device stage 2 mapping was chosen in KVM for ARM64 since
it was considered safer (i.e. it would not allow guests to trigger
uncontained failures ultimately crashing the machine) but this
turned out to be asynchronous (SError) defeating the purpose.

Failures containability is a property of the platform and is independent
from the memory type used for MMIO device memory mappings.

Actually, DEVICE_nGnRE memory type is even more problematic than
Normal-NC memory type in terms of faults containability in that e.g.
aborts triggered on DEVICE_nGnRE loads cannot be made, architecturally,
synchronous (i.e. that would imply that the processor should issue at
most 1 load transaction at a time - it cannot pipeline them - otherwise
the synchronous abort semantics would break the no-speculation attribute
attached to DEVICE_XXX memory).

This means that regardless of the combined stage1+stage2 mappings a
platform is safe if and only if device transactions cannot trigger
uncontained failures and that in turn relies on platform capabilities
and the device type being assigned (i.e. PCIe AER/DPC error containment
and RAS architecture[3]); therefore the default KVM device stage 2
memory attributes play no role in making device assignment safer
for a given platform (if the platform design adheres to design
guidelines outlined in [3]) and therefore can be relaxed.

For all these reasons, relax the KVM stage 2 device memory attributes
from DEVICE_nGnRE to Normal-NC.

The NormalNC was chosen over a different Normal memory type default
at stage-2 (e.g. Normal Write-through) to avoid cache allocation/snooping.

Relaxing S2 KVM device MMIO mappings to Normal-NC is not expected to
trigger any issue on guest device reclaim use cases either (i.e. device
MMIO unmap followed by a device reset) at least for PCIe devices, in that
in PCIe a device reset is architected and carried out through PCI config
space transactions that are naturally ordered with respect to MMIO
transactions according to the PCI ordering rules.

Having Normal-NC S2 default puts guests in control (thanks to
stage1+stage2 combined memory attributes rules [1]) of device MMIO
regions memory mappings, according to the rules described in [1]
and summarized here ([(S1) - stage1], [(S2) - stage 2]):

S1           |  S2           | Result
NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>

It is worth noting that currently, to map devices MMIO space to user
space in a device pass-through use case the VFIO framework applies memory
attributes derived from pgprot_noncached() settings applied to VMAs, which
result in device-nGnRnE memory attributes for the stage-1 VMM mappings.

This means that a userspace mapping for device MMIO space carried
out with the current VFIO framework and a guest OS mapping for the same
MMIO space may result in a mismatched alias as described in [2].

Defaulting KVM device stage-2 mappings to Normal-NC attributes does not
change anything in this respect, in that the mismatched aliases would
only affect (refer to [2] for a detailed explanation) ordering between
the userspace and GuestOS mappings resulting stream of transactions
(i.e. it does not cause loss of property for either stream of
transactions on its own), which is harmless given that the userspace
and GuestOS access to the device is carried out through independent
transactions streams.

A Normal-NC flag is not present today. So add a new kvm_pgtable_prot
(KVM_PGTABLE_PROT_NORMAL_NC) flag for it, along with its
corresponding PTE value 0x5 (0b101) determined from [1].

Lastly, adapt the stage2 PTE property setter function
(stage2_set_prot_attr) to handle the NormalNC attribute.

[1] section D8.5.5 - DDI0487J_a_a-profile_architecture_reference_manual.pdf
[2] section B2.8 - DDI0487J_a_a-profile_architecture_reference_manual.pdf
[3] sections 1.7.7.3/1.8.5.2/appendix C - DEN0029H_SBSA_7.1.pdf

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Jason Gunthorpe <jgg at nvidia.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>

---
 arch/arm64/include/asm/kvm_pgtable.h |  2 ++
 arch/arm64/include/asm/memory.h      |  2 ++
 arch/arm64/kvm/hyp/pgtable.c         | 23 ++++++++++++++++++-----
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index d3e354bb8351..de0b8845df7a 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -169,6 +169,7 @@ enum kvm_pgtable_stage2_flags {
  * @KVM_PGTABLE_PROT_W:		Write permission.
  * @KVM_PGTABLE_PROT_R:		Read permission.
  * @KVM_PGTABLE_PROT_DEVICE:	Device attributes.
+ * @KVM_PGTABLE_PROT_NORMAL_NC:	Normal noncacheable attributes.
  * @KVM_PGTABLE_PROT_SW0:	Software bit 0.
  * @KVM_PGTABLE_PROT_SW1:	Software bit 1.
  * @KVM_PGTABLE_PROT_SW2:	Software bit 2.
@@ -180,6 +181,7 @@ enum kvm_pgtable_prot {
 	KVM_PGTABLE_PROT_R			= BIT(2),
 
 	KVM_PGTABLE_PROT_DEVICE			= BIT(3),
+	KVM_PGTABLE_PROT_NORMAL_NC		= BIT(4),
 
 	KVM_PGTABLE_PROT_SW0			= BIT(55),
 	KVM_PGTABLE_PROT_SW1			= BIT(56),
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index fde4186cc387..c247e5f29d5a 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -147,6 +147,7 @@
  * Memory types for Stage-2 translation
  */
 #define MT_S2_NORMAL		0xf
+#define MT_S2_NORMAL_NC		0x5
 #define MT_S2_DEVICE_nGnRE	0x1
 
 /*
@@ -154,6 +155,7 @@
  * Stage-2 enforces Normal-WB and Device-nGnRE
  */
 #define MT_S2_FWB_NORMAL	6
+#define MT_S2_FWB_NORMAL_NC	5
 #define MT_S2_FWB_DEVICE_nGnRE	1
 
 #ifdef CONFIG_ARM64_4K_PAGES
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 1966fdee740e..8ffd31e0b9b5 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -695,15 +695,28 @@ void kvm_tlb_flush_vmid_range(struct kvm_s2_mmu *mmu,
 static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot prot,
 				kvm_pte_t *ptep)
 {
-	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
-	kvm_pte_t attr = device ? KVM_S2_MEMATTR(pgt, DEVICE_nGnRE) :
-			    KVM_S2_MEMATTR(pgt, NORMAL);
+	kvm_pte_t attr;
 	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
 
+	switch (prot & (KVM_PGTABLE_PROT_DEVICE |
+			KVM_PGTABLE_PROT_NORMAL_NC)) {
+	case 0:
+		attr = KVM_S2_MEMATTR(pgt, NORMAL);
+		break;
+	case KVM_PGTABLE_PROT_DEVICE:
+		if (prot & KVM_PGTABLE_PROT_X)
+			return -EINVAL;
+		attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE);
+		break;
+	case KVM_PGTABLE_PROT_NORMAL_NC:
+		attr = KVM_S2_MEMATTR(pgt, NORMAL_NC);
+		break;
+	default:
+		WARN_ON_ONCE(1);
+	}
+
 	if (!(prot & KVM_PGTABLE_PROT_X))
 		attr |= KVM_PTE_LEAF_ATTR_HI_S2_XN;
-	else if (device)
-		return -EINVAL;
 
 	if (prot & KVM_PGTABLE_PROT_R)
 		attr |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R;
-- 
2.17.1



From ankita at nvidia.com  Thu Dec 21 07:40:01 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Thu, 21 Dec 2023 21:10:01 +0530
Subject: [PATCH v5 3/4] kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices
In-Reply-To: <20231221154002.32622-1-ankita@nvidia.com>
References: <20231221154002.32622-1-ankita@nvidia.com>
Message-ID: <20231221154002.32622-4-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

To provide VM with the ability to get device IO memory with NormalNC
property, map device MMIO in KVM for ARM64 at stage2 as NormalNC.
Having NormalNC S2 default puts guests in control (based on [1],
"Combining stage 1 and stage 2 memory type attributes") of device
MMIO regions memory mappings. The rules are summarized below:
([(S1) - stage1], [(S2) - stage 2])

S1           |  S2           | Result
NORMAL-WB    |  NORMAL-NC    | NORMAL-NC
NORMAL-WT    |  NORMAL-NC    | NORMAL-NC
NORMAL-NC    |  NORMAL-NC    | NORMAL-NC
DEVICE<attr> |  NORMAL-NC    | DEVICE<attr>

Still this cannot be generalized to non PCI devices such as GICv2.
There is insufficient information and uncertainity in the behavior
of non PCI driver. A driver must indicate support using the
new flag VM_VFIO_ALLOW_WC.

Adapt KVM to make use of the flag VM_VFIO_ALLOW_WC as indicator to
activate the S2 setting to NormalNc.

[1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Jason Gunthorpe <jgg at nvidia.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>

---
 arch/arm64/kvm/mmu.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index d87c8fcc4c24..7e01fff78e23 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1379,7 +1379,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	int ret = 0;
 	bool write_fault, writable, force_pte = false;
 	bool exec_fault, mte_allowed;
-	bool device = false;
+	bool device = false, vfio_allow_wc = false;
 	unsigned long mmu_seq;
 	struct kvm *kvm = vcpu->kvm;
 	struct kvm_mmu_memory_cache *memcache = &vcpu->arch.mmu_page_cache;
@@ -1471,6 +1471,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	gfn = fault_ipa >> PAGE_SHIFT;
 	mte_allowed = kvm_vma_mte_allowed(vma);
 
+	vfio_allow_wc = (vma->vm_flags & VM_VFIO_ALLOW_WC);
+
 	/* Don't use the VMA after the unlock -- it may have vanished */
 	vma = NULL;
 
@@ -1557,10 +1559,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	if (exec_fault)
 		prot |= KVM_PGTABLE_PROT_X;
 
-	if (device)
-		prot |= KVM_PGTABLE_PROT_DEVICE;
-	else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
+	if (device) {
+		/*
+		 * To provide VM with the ability to get device IO memory
+		 * with NormalNC property, map device MMIO as NormalNC in S2.
+		 */
+		if (vfio_allow_wc)
+			prot |= KVM_PGTABLE_PROT_NORMAL_NC;
+		else
+			prot |= KVM_PGTABLE_PROT_DEVICE;
+	} else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
 		prot |= KVM_PGTABLE_PROT_X;
+	}
 
 	/*
 	 * Under the premise of getting a FSC_PERM fault, we just need to relax
-- 
2.17.1



From ankita at nvidia.com  Thu Dec 21 07:40:02 2023
From: ankita at nvidia.com (ankita at nvidia.com)
Date: Thu, 21 Dec 2023 21:10:02 +0530
Subject: [PATCH v5 4/4] vfio: convey kvm that the vfio-pci device is wc safe
In-Reply-To: <20231221154002.32622-1-ankita@nvidia.com>
References: <20231221154002.32622-1-ankita@nvidia.com>
Message-ID: <20231221154002.32622-5-ankita@nvidia.com>

From: Ankit Agrawal <ankita at nvidia.com>

The code to map the MMIO in S2 as NormalNC is enabled when conveyed
that the device is WC safe using a new flag VM_VFIO_ALLOW_WC.

Make vfio-pci set the VM_VFIO_ALLOW_WC flag.

This could be extended to other devices in the future once that
is deemed safe.

Signed-off-by: Ankit Agrawal <ankita at nvidia.com>
Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Jason Gunthorpe <jgg at nvidia.com>
Tested-by: Ankit Agrawal <ankita at nvidia.com>
---
 drivers/vfio/pci/vfio_pci_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 1929103ee59a..c5ebca74b8a8 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1863,7 +1863,8 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
 	 * See remap_pfn_range(), called from vfio_pci_fault() but we can't
 	 * change vm_flags within the fault handler.  Set them now.
 	 */
-	vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
+	vm_flags_set(vma, VM_VFIO_ALLOW_WC | VM_IO | VM_PFNMAP |
+			VM_DONTEXPAND | VM_DONTDUMP);
 	vma->vm_ops = &vfio_pci_mmap_ops;
 
 	return 0;
-- 
2.17.1



From knaerzche at gmail.com  Thu Dec 21 07:58:13 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Thu, 21 Dec 2023 16:58:13 +0100
Subject: [PATCH v2 1/3] ARM: dts: rockchip: Add psci for rk3036
In-Reply-To: <28216be5-810f-40d6-850b-a0fc590ffa3c@rock-chips.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
 <20231218105523.2478315-2-andyshrk@163.com>
 <da10e2fc-3179-4bd5-88ed-b4d5f64a7191@gmail.com>
 <28216be5-810f-40d6-850b-a0fc590ffa3c@rock-chips.com>
Message-ID: <a82481ca-b578-49a4-b0d0-974b6ee65c98@gmail.com>

Hi Andy,

Am 21.12.23 um 02:07 schrieb Andy Yan:
> Hi Alex:
>
> On 12/20/23 19:16, Alex Bee wrote:
>> Hi Andy,
>> Am 18.12.23 um 11:55 schrieb Andy Yan:
>>> From: Andy Yan <andy.yan at rock-chips.com>
>>>
>>> The system will hang at bringup secondary CPUs
>>> without psci node.
>>>
>>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>>>
>>> ---
>>>
>>> (no changes since v1)
>>>
>>> ? arch/arm/boot/dts/rockchip/rk3036.dtsi | 5 +++++
>>> ? 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi 
>>> b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>> index 78686fc72ce6..5344803442a1 100644
>>> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>> @@ -67,6 +67,11 @@ display-subsystem {
>>> ????????? ports = <&vop_out>;
>>> ????? };
>>> +??? psci {
>>> +??????? compatible = "arm,psci-1.0";
>>> +??????? method = "smc";
>>> +??? };
>>> +
>> I don't think that's an good idea. 
>
> Why?
It's only what I've been told before: We shoudn't add properties which
depend on non-upstream software (if an upstream alternative exists). Also
I'm not sure what happens if somebody doesn't?use downstream bootloader
and PSCI can't be found: Would the board still be able to boot?
>
>> You most likely need that because you have downstream bootloader 
>> installed on this board. PSCI implementation takes place in TEE-OS 
>> for Rockchips ARM SoCs. There is no support for RK3036 in upstream 
>> op-tee OS. It's pretty much the same for RK3128 and RK3288.
>> If you use upstream u-boot it should be good as-is.
>
> Unfortunately, upstream u-boot also cannot boot up on this board.
> At present, I haven't had time to debug what is going on.
>
> Another reason I want to use downstream u-boot it is: I try run
> this board with mainline just because i want to test some community
> patches about inno-hdmi driver, as you said "the inno-hdmi driver 
> currently gets a lot of attention"[0]
>
Thanks for helping testing this.

Alex

> With a downstream u-boot I can easy switch between upstream kernel and 
> downstream kernel(no need to replace other components)
> if I found some function is not work as expected.
>
>
> [0]https://patchwork.kernel.org/project/linux-rockchip/cover/20231219170100.188800-1-knaerzche at gmail.com/ 
>
>>
>> Alex
>>> ????? timer {
>>> ????????? compatible = "arm,armv7-timer";
>>> ????????? arm,cpu-registers-not-fw-configured;
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip


From lee at kernel.org  Thu Dec 21 08:11:52 2023
From: lee at kernel.org (Lee Jones)
Date: Thu, 21 Dec 2023 16:11:52 +0000
Subject: (subset) [PATCH] mfd: ti_am335x_tscadc: Fix TI SoC
 dependencies
In-Reply-To: <20231220155643.445849-1-pbrobinson@gmail.com>
References: <20231220155643.445849-1-pbrobinson@gmail.com>
Message-ID: <170317511203.648767.11706110106024240818.b4-ty@kernel.org>

On Wed, 20 Dec 2023 15:56:39 +0000, Peter Robinson wrote:
> The ti_am335x_tscadc is specific to some TI SoCs, update
> the dependencies for those SoCs and compile testing.
> 
> 

Applied, thanks!

[1/1] mfd: ti_am335x_tscadc: Fix TI SoC dependencies
      commit: 835e69774333833221aa1c3cbc621cec8cbc79fc

--
Lee Jones [???]



From krzysztof.kozlowski at linaro.org  Thu Dec 21 08:25:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 17:25:08 +0100
Subject: [PATCH 1/7] [RFC PATCH 1/7] osdump: Add one new os minidump
 module
In-Reply-To: <20231221130930.32634-1-ruipengqi7@gmail.com>
References: <20231221130930.32634-1-ruipengqi7@gmail.com>
Message-ID: <e9aa311f-6f13-410e-bb35-20320275668c@linaro.org>

On 21/12/2023 14:09, Ruipeng Qi wrote:
> From: qiruipeng <qiruipeng at lixiang.com>
> 
> Osdump is a new crash dumping solution aiming at specific embedded
> devices within automotive or Industrial.
>  - limited memory.
>  - reboot as soon as possible when system fault.

NAK, sorry, work with Qualcomm minidump series to incorporate all your
needs there.

Best regards,
Krzysztof



From andre.przywara at arm.com  Thu Dec 21 08:29:07 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 21 Dec 2023 16:29:07 +0000
Subject: [PATCH] dt-bindings: arm: sunxi: sort alphabetically
In-Reply-To: <6721cb2f-4498-4d20-9059-257846005905@linaro.org>
References: <20231221140614.639697-1-andre.przywara@arm.com>
	<ab8e7d68-c09c-47ff-9f31-08b073387403@linaro.org>
	<20231221150714.53d40ea3@donnerap.manchester.arm.com>
	<6721cb2f-4498-4d20-9059-257846005905@linaro.org>
Message-ID: <20231221162907.1b609235@donnerap.manchester.arm.com>

On Thu, 21 Dec 2023 16:38:41 +0100
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

Hi,

(CC:ing Maxime for potential historic context)

> On 21/12/2023 16:07, Andre Przywara wrote:
> > On Thu, 21 Dec 2023 15:45:17 +0100
> > Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> > 
> > Hi,
> >   
> >> On 21/12/2023 15:06, Andre Przywara wrote:  
> >>> The sunxi.yaml file, holding all known board compatible names for
> >>> devices with Allwinner SoCs, is apparently sorted alphabetically, by the
> >>> "description" entry. However there are a few outliers.
> >>>
> >>> Re-order the entries to get a strict alphabetical ordering, so that:
> >>> $ grep description: sunxi.yaml | sort -fc
> >>> returns empty-handed. There is no change otherwise.
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>    
> >>
> >> What was the existing order? Aren't this just shuffling again things?  
> > 
> > It assume the intention was to order "alphabetically by description", but
> > there were some out-of-place entries which apparently slipped through
> > review.
> > 
> > Shall I add a comment at the top to note the order?  
> 
> Some files like this are ordered by compatible, some by class or family
> of devices, so first you need to be sure there is no existing order.

That's what I did, of course:
- there is no order in the compatible strings, not in the most specific
name, nor in the fallback names
- new boards have always been added somewhere in the middle, never at the
end, so it's not "oldest boards first"
- the SoCs used in the boards are all over the place, so it's not sorted
by SoC
- I see no rhyme or reason in the board types: we have tablets, devboards,
TV boxes all mixed up happily.

But: from the 197 listed boards, a movement of 13 boards, often by just one
position, makes the list ordered by description.

So I assumed this was the intention, and fixed the list accordingly. Happy
to stand corrected if the maintainers have a better idea.

Cheers,
Andre


From vkoul at kernel.org  Thu Dec 21 08:29:58 2023
From: vkoul at kernel.org (Vinod Koul)
Date: Thu, 21 Dec 2023 21:59:58 +0530
Subject: [PATCH] dmaengine: std_dma40: fix kernel-doc warnings and
 spelling
In-Reply-To: <20231218060834.19222-1-rdunlap@infradead.org>
References: <20231218060834.19222-1-rdunlap@infradead.org>
Message-ID: <170317619891.683420.428561244511510954.b4-ty@kernel.org>


On Sun, 17 Dec 2023 22:08:34 -0800, Randy Dunlap wrote:
> Correct kernel-doc warnings as reported by kernel test robot:
> 
> ste_dma40.c:57: warning: Excess struct member 'dev_tx' description in 'stedma40_platform_data'
> ste_dma40.c:57: warning: Excess struct member 'dev_rx' description in 'stedma40_platform_data'
> 
> Correct spellos as reported by codespell.
> 
> [...]

Applied, thanks!

[1/1] dmaengine: std_dma40: fix kernel-doc warnings and spelling
      commit: 71a5197e2b872afeef8ade3099ffc4050466b542

Best regards,
-- 
~Vinod




From cniedermaier at dh-electronics.com  Thu Dec 21 08:46:33 2023
From: cniedermaier at dh-electronics.com (Christoph Niedermaier)
Date: Thu, 21 Dec 2023 17:46:33 +0100
Subject: [PATCH] ARM: dts: imx6ull-dhcor: Remove 900MHz operating point
Message-ID: <20231221164633.2029-1-cniedermaier@dh-electronics.com>

Due to CPU lifetime consideration of the SoC manufacturer [1] and
the preferred area of operation in the industrial related
environment, set the maximum frequency for each DHCOM i.MX6ULL to
792MHz, as with the industrial type. This is done by removing the
operating point at 900MHz and set the clock-frequency to 792000000.

[1] https://www.nxp.com/docs/en/application-note/AN5337.pdf

Signed-off-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>
---
Cc: Rob Herring <robh+dt at kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
Cc: Conor Dooley <conor+dt at kernel.org>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <festevam at denx.de>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: kernel at dh-electronics.com
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/nxp/imx/imx6ull-dhcor-som.dtsi | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx6ull-dhcor-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ull-dhcor-som.dtsi
index 45315adfaa86..75486e1b0c15 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ull-dhcor-som.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ull-dhcor-som.dtsi
@@ -28,10 +28,14 @@
 	/*
 	 * Due to the design as a solderable SOM, there are no capacitors
 	 * below the SoC, therefore higher voltages are required.
+	 * Due to CPU lifetime consideration of the SoC manufacturer and
+	 * the preferred area of operation in the industrial related
+	 * environment, set the maximum frequency for each DHCOM i.MX6ULL
+	 * to 792MHz, as with the industrial type.
 	 */
+	clock-frequency = <792000000>;
 	operating-points = <
 		/* kHz	uV */
-		900000	1275000
 		792000	1250000 /* Voltage increased */
 		528000	1175000
 		396000	1025000
@@ -39,7 +43,6 @@
 	>;
 	fsl,soc-operating-points = <
 		/* KHz	uV */
-		900000	1250000
 		792000	1250000 /* Voltage increased */
 		528000	1175000
 		396000	1175000
-- 
2.11.0



From vkoul at kernel.org  Thu Dec 21 08:48:37 2023
From: vkoul at kernel.org (Vinod Koul)
Date: Thu, 21 Dec 2023 22:18:37 +0530
Subject: [RFC PATCH net-next v3 2/8] phy: add driver for MediaTek pextp
 10GE SerDes PHY
In-Reply-To: <a58dae1cce1b49093b0ae05159c784a9ec02f058.1702352117.git.daniel@makrotopia.org>
References: <cover.1702352117.git.daniel@makrotopia.org>
 <a58dae1cce1b49093b0ae05159c784a9ec02f058.1702352117.git.daniel@makrotopia.org>
Message-ID: <ZYRsZWY0w2_uFOpn@matsya>

On 12-12-23, 03:46, Daniel Golle wrote:
> Add driver for MediaTek's pextp 10 Gigabit/s Ethernet SerDes PHY which
> can be found in the MT7988 SoC.
> 
> The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
> PHY_INTERFACE_MODE_* corresponding to the supported modes:
> 
>  * USXGMII
>  * 10GBase-R
>  * 5GBase-R
>  * 2500Base-X
>  * 1000Base-X
>  * Cisco SGMII (MAC side)
> 
> In order to work-around a performance issue present on the first of
> two PEXTP present in MT7988 special tuning is applied which can be
> selected by adding the mediatek,usxgmii-performance-errata property to
> the device tree node.
> 
> There is no documentation what-so-ever for the pextp registers and
> this driver is based on a GPL licensed implementation found in
> MediaTek's SDK.
> 
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
> ---
>  MAINTAINERS                          |   1 +
>  drivers/phy/mediatek/Kconfig         |  11 +
>  drivers/phy/mediatek/Makefile        |   1 +
>  drivers/phy/mediatek/phy-mtk-pextp.c | 361 +++++++++++++++++++++++++++
>  4 files changed, 374 insertions(+)
>  create mode 100644 drivers/phy/mediatek/phy-mtk-pextp.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 98f7dd0499f17..b2772cfe2a704 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13510,6 +13510,7 @@ L:	netdev at vger.kernel.org
>  S:	Maintained
>  F:	drivers/net/phy/mediatek-ge-soc.c
>  F:	drivers/net/phy/mediatek-ge.c
> +F:	drivers/phy/mediatek/phy-mtk-pextp.c
>  
>  MEDIATEK I2C CONTROLLER DRIVER
>  M:	Qii Wang <qii.wang at mediatek.com>
> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> index 3125ecb5d119f..a7749a6d96541 100644
> --- a/drivers/phy/mediatek/Kconfig
> +++ b/drivers/phy/mediatek/Kconfig
> @@ -13,6 +13,17 @@ config PHY_MTK_PCIE
>  	  callback for PCIe GEN3 port, it supports software efuse
>  	  initialization.
>  
> +config PHY_MTK_PEXTP
> +	tristate "MediaTek PEXTP Driver"
> +	depends on ARCH_MEDIATEK || COMPILE_TEST
> +	depends on OF && OF_ADDRESS
> +	depends on HAS_IOMEM
> +	select GENERIC_PHY
> +	help
> +	  Say 'Y' here to add support for MediaTek pextp PHY driver.
> +	  The driver provides access to the Ethernet SerDes PHY supporting
> +	  various 1GE, 2.5GE, 5GE and 10GE modes.
> +
>  config PHY_MTK_TPHY
>  	tristate "MediaTek T-PHY Driver"
>  	depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index c9a50395533eb..ca60c7b9b02ac 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_PHY_MTK_PCIE)		+= phy-mtk-pcie.o
>  obj-$(CONFIG_PHY_MTK_TPHY)		+= phy-mtk-tphy.o
>  obj-$(CONFIG_PHY_MTK_UFS)		+= phy-mtk-ufs.o
>  obj-$(CONFIG_PHY_MTK_XSPHY)		+= phy-mtk-xsphy.o
> +obj-$(CONFIG_PHY_MTK_PEXTP)		+= phy-mtk-pextp.o

alphabetically sorted please

>  
>  phy-mtk-hdmi-drv-y			:= phy-mtk-hdmi.o
>  phy-mtk-hdmi-drv-y			+= phy-mtk-hdmi-mt2701.o
> diff --git a/drivers/phy/mediatek/phy-mtk-pextp.c b/drivers/phy/mediatek/phy-mtk-pextp.c
> new file mode 100644
> index 0000000000000..3ec48cf129105
> --- /dev/null
> +++ b/drivers/phy/mediatek/phy-mtk-pextp.c
> @@ -0,0 +1,361 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/* MediaTek 10GE SerDes PHY driver
> + *
> + * Copyright (c) 2023 Daniel Golle <daniel at makrotopia.org>
> + * based on mtk_usxgmii.c found in MediaTek's SDK released under GPL-2.0
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Henry Yen <henry.yen at mediatek.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/netdevice.h>

why do you need this header?

> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +#include <linux/phy.h>
> +#include <linux/phy/phy.h>
> +
> +#define MTK_PEXTP_NUM_CLOCKS	2
> +
> +struct mtk_pextp_phy {
> +	void __iomem		*base;
> +	struct device		*dev;
> +	struct reset_control	*reset;
> +	struct clk_bulk_data	clocks[MTK_PEXTP_NUM_CLOCKS];
> +	bool			da_war;
> +};
> +
> +static bool mtk_interface_mode_is_xgmii(phy_interface_t interface)
> +{
> +	switch (interface) {
> +	case PHY_INTERFACE_MODE_INTERNAL:
> +	case PHY_INTERFACE_MODE_USXGMII:
> +	case PHY_INTERFACE_MODE_10GBASER:
> +	case PHY_INTERFACE_MODE_5GBASER:
> +		return true;
> +	default:
> +		return false;
> +	}
> +}
> +
> +static void mtk_pextp_setup(struct mtk_pextp_phy *pextp, phy_interface_t interface)
> +{
> +	bool is_10g = (interface == PHY_INTERFACE_MODE_10GBASER ||
> +		       interface == PHY_INTERFACE_MODE_USXGMII);
> +	bool is_2p5g = (interface == PHY_INTERFACE_MODE_2500BASEX);
> +	bool is_5g = (interface == PHY_INTERFACE_MODE_5GBASER);
> +
> +	dev_dbg(pextp->dev, "setting up for mode %s\n", phy_modes(interface));
> +
> +	/* Setup operation mode */
> +	if (is_10g)
> +		iowrite32(0x00c9071c, pextp->base + 0x9024);
> +	else
> +		iowrite32(0x00d9071c, pextp->base + 0x9024);
> +
> +	if (is_5g)
> +		iowrite32(0xaaa5a5aa, pextp->base + 0x2020);
> +	else
> +		iowrite32(0xaa8585aa, pextp->base + 0x2020);
> +
> +	if (is_2p5g || is_5g || is_10g) {
> +		iowrite32(0x0c020707, pextp->base + 0x2030);
> +		iowrite32(0x0e050f0f, pextp->base + 0x2034);
> +		iowrite32(0x00140032, pextp->base + 0x2040);
> +	} else {
> +		iowrite32(0x0c020207, pextp->base + 0x2030);
> +		iowrite32(0x0e05050f, pextp->base + 0x2034);
> +		iowrite32(0x00200032, pextp->base + 0x2040);
> +	}
> +
> +	if (is_2p5g || is_10g)
> +		iowrite32(0x00c014aa, pextp->base + 0x50f0);
> +	else if (is_5g)
> +		iowrite32(0x00c018aa, pextp->base + 0x50f0);
> +	else
> +		iowrite32(0x00c014ba, pextp->base + 0x50f0);
> +
> +	if (is_5g) {
> +		iowrite32(0x3777812b, pextp->base + 0x50e0);
> +		iowrite32(0x005c9cff, pextp->base + 0x506c);
> +		iowrite32(0x9dfafafa, pextp->base + 0x5070);
> +		iowrite32(0x273f3f3f, pextp->base + 0x5074);
> +		iowrite32(0xa8883868, pextp->base + 0x5078);
> +		iowrite32(0x14661466, pextp->base + 0x507c);
> +	} else {
> +		iowrite32(0x3777c12b, pextp->base + 0x50e0);
> +		iowrite32(0x005f9cff, pextp->base + 0x506c);
> +		iowrite32(0x9d9dfafa, pextp->base + 0x5070);
> +		iowrite32(0x27273f3f, pextp->base + 0x5074);
> +		iowrite32(0xa7883c68, pextp->base + 0x5078);
> +		iowrite32(0x11661166, pextp->base + 0x507c);
> +	}
> +
> +	if (is_2p5g || is_10g) {
> +		iowrite32(0x0e000aaf, pextp->base + 0x5080);
> +		iowrite32(0x08080d0d, pextp->base + 0x5084);
> +		iowrite32(0x02030909, pextp->base + 0x5088);
> +	} else if (is_5g) {
> +		iowrite32(0x0e001abf, pextp->base + 0x5080);
> +		iowrite32(0x080b0d0d, pextp->base + 0x5084);
> +		iowrite32(0x02050909, pextp->base + 0x5088);
> +	} else {
> +		iowrite32(0x0e000eaf, pextp->base + 0x5080);
> +		iowrite32(0x08080e0d, pextp->base + 0x5084);
> +		iowrite32(0x02030b09, pextp->base + 0x5088);
> +	}
> +
> +	if (is_5g) {
> +		iowrite32(0x0c000000, pextp->base + 0x50e4);
> +		iowrite32(0x04000000, pextp->base + 0x50e8);
> +	} else {
> +		iowrite32(0x0c0c0000, pextp->base + 0x50e4);
> +		iowrite32(0x04040000, pextp->base + 0x50e8);
> +	}
> +
> +	if (is_2p5g || mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x0f0f0c06, pextp->base + 0x50eC);

ouch, why mixed case, make it small everwhere please

> +	else
> +		iowrite32(0x0f0f0606, pextp->base + 0x50eC);
> +
> +	if (is_5g) {
> +		iowrite32(0x50808c8c, pextp->base + 0x50a8);
> +		iowrite32(0x18000000, pextp->base + 0x6004);
> +	} else {
> +		iowrite32(0x506e8c8c, pextp->base + 0x50a8);
> +		iowrite32(0x18190000, pextp->base + 0x6004);
> +	}
> +
> +	if (is_10g)
> +		iowrite32(0x01423342, pextp->base + 0x00f8);
> +	else if (is_5g)
> +		iowrite32(0x00a132a1, pextp->base + 0x00f8);
> +	else if (is_2p5g)
> +		iowrite32(0x009c329c, pextp->base + 0x00f8);
> +	else
> +		iowrite32(0x00fa32fa, pextp->base + 0x00f8);
> +
> +	/* Force SGDT_OUT off and select PCS */
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x80201f20, pextp->base + 0x00f4);
> +	else
> +		iowrite32(0x80201f21, pextp->base + 0x00f4);
> +
> +	/* Force GLB_CKDET_OUT */
> +	iowrite32(0x00050c00, pextp->base + 0x0030);
> +
> +	/* Force AEQ on */
> +	iowrite32(0x02002800, pextp->base + 0x0070);
> +	ndelay(1020);
> +
> +	/* Setup DA default value */
> +	iowrite32(0x00000020, pextp->base + 0x30b0);
> +	iowrite32(0x00008a01, pextp->base + 0x3028);
> +	iowrite32(0x0000a884, pextp->base + 0x302c);
> +	iowrite32(0x00083002, pextp->base + 0x3024);
> +	if (mtk_interface_mode_is_xgmii(interface)) {
> +		iowrite32(0x00022220, pextp->base + 0x3010);
> +		iowrite32(0x0f020a01, pextp->base + 0x5064);
> +		iowrite32(0x06100600, pextp->base + 0x50b4);
> +		if (interface == PHY_INTERFACE_MODE_USXGMII)
> +			iowrite32(0x40704000, pextp->base + 0x3048);
> +		else
> +			iowrite32(0x47684100, pextp->base + 0x3048);
> +	} else {
> +		iowrite32(0x00011110, pextp->base + 0x3010);
> +		iowrite32(0x40704000, pextp->base + 0x3048);
> +	}
> +
> +	if (!mtk_interface_mode_is_xgmii(interface) && !is_2p5g)
> +		iowrite32(0x0000c000, pextp->base + 0x3064);
> +
> +	if (interface != PHY_INTERFACE_MODE_10GBASER) {
> +		iowrite32(0xa8000000, pextp->base + 0x3050);
> +		iowrite32(0x000000aa, pextp->base + 0x3054);
> +	} else {
> +		iowrite32(0x00000000, pextp->base + 0x3050);
> +		iowrite32(0x00000000, pextp->base + 0x3054);
> +	}
> +
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x00000f00, pextp->base + 0x306c);
> +	else if (is_2p5g)
> +		iowrite32(0x22000f00, pextp->base + 0x306c);
> +	else
> +		iowrite32(0x20200f00, pextp->base + 0x306c);
> +
> +	if (interface == PHY_INTERFACE_MODE_10GBASER && pextp->da_war)
> +		iowrite32(0x0007b400, pextp->base + 0xa008);
> +
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x00040000, pextp->base + 0xa060);
> +	else
> +		iowrite32(0x00050000, pextp->base + 0xa060);
> +
> +	if (is_10g)
> +		iowrite32(0x00000001, pextp->base + 0x90d0);
> +	else if (is_5g)
> +		iowrite32(0x00000003, pextp->base + 0x90d0);
> +	else if (is_2p5g)
> +		iowrite32(0x00000005, pextp->base + 0x90d0);
> +	else
> +		iowrite32(0x00000007, pextp->base + 0x90d0);
> +
> +	/* Release reset */
> +	iowrite32(0x0200e800, pextp->base + 0x0070);
> +	usleep_range(150, 500);
> +
> +	/* Switch to P0 */
> +	iowrite32(0x0200c111, pextp->base + 0x0070);
> +	ndelay(1020);
> +	iowrite32(0x0200c101, pextp->base + 0x0070);
> +	usleep_range(15, 50);
> +
> +	if (mtk_interface_mode_is_xgmii(interface)) {
> +		/* Switch to Gen3 */
> +		iowrite32(0x0202c111, pextp->base + 0x0070);
> +	} else {
> +		/* Switch to Gen2 */
> +		iowrite32(0x0201c111, pextp->base + 0x0070);
> +	}
> +	ndelay(1020);
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x0202c101, pextp->base + 0x0070);
> +	else
> +		iowrite32(0x0201c101, pextp->base + 0x0070);
> +	usleep_range(100, 500);
> +	iowrite32(0x00000030, pextp->base + 0x30b0);
> +	if (mtk_interface_mode_is_xgmii(interface))
> +		iowrite32(0x80201f00, pextp->base + 0x00f4);
> +	else
> +		iowrite32(0x80201f01, pextp->base + 0x00f4);
> +
> +	iowrite32(0x30000000, pextp->base + 0x3040);
> +	usleep_range(400, 1000);
> +}
> +
> +static int mtk_pextp_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> +	if (mode != PHY_MODE_ETHERNET)
> +		return -EINVAL;
> +
> +	switch (submode) {
> +	case PHY_INTERFACE_MODE_1000BASEX:
> +	case PHY_INTERFACE_MODE_2500BASEX:
> +	case PHY_INTERFACE_MODE_SGMII:
> +	case PHY_INTERFACE_MODE_5GBASER:
> +	case PHY_INTERFACE_MODE_10GBASER:
> +	case PHY_INTERFACE_MODE_USXGMII:
> +		mtk_pextp_setup(pextp, submode);
> +		return 0;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static int mtk_pextp_reset(struct phy *phy)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> +	reset_control_assert(pextp->reset);
> +	usleep_range(100, 500);
> +	reset_control_deassert(pextp->reset);
> +	usleep_range(1, 10);
> +
> +	return 0;
> +}
> +
> +static int mtk_pextp_power_on(struct phy *phy)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> +	return clk_bulk_prepare_enable(MTK_PEXTP_NUM_CLOCKS, pextp->clocks);
> +}
> +
> +static int mtk_pextp_power_off(struct phy *phy)
> +{
> +	struct mtk_pextp_phy *pextp = phy_get_drvdata(phy);
> +
> +	clk_bulk_disable_unprepare(MTK_PEXTP_NUM_CLOCKS, pextp->clocks);
> +
> +	return 0;
> +}
> +
> +static const struct phy_ops mtk_pextp_ops = {
> +	.power_on	= mtk_pextp_power_on,
> +	.power_off	= mtk_pextp_power_off,
> +	.set_mode	= mtk_pextp_set_mode,
> +	.reset		= mtk_pextp_reset,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int mtk_pextp_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct phy_provider *phy_provider;
> +	struct mtk_pextp_phy *pextp;
> +	struct phy *phy;
> +
> +	if (!np)
> +		return -ENODEV;
> +
> +	pextp = devm_kzalloc(&pdev->dev, sizeof(*pextp), GFP_KERNEL);
> +	if (!pextp)
> +		return -ENOMEM;
> +
> +	pextp->base = devm_of_iomap(&pdev->dev, np, 0, NULL);
> +	if (!pextp->base)
> +		return -EIO;
> +
> +	pextp->dev = &pdev->dev;
> +
> +	pextp->clocks[0].id = "topxtal";
> +	pextp->clocks[0].clk = devm_clk_get(&pdev->dev, pextp->clocks[0].id);
> +	if (IS_ERR(pextp->clocks[0].clk))
> +		return PTR_ERR(pextp->clocks[0].clk);
> +
> +	pextp->clocks[1].id = "xfipll";
> +	pextp->clocks[1].clk = devm_clk_get(&pdev->dev, pextp->clocks[1].id);
> +	if (IS_ERR(pextp->clocks[1].clk))
> +		return PTR_ERR(pextp->clocks[1].clk);
> +
> +	pextp->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> +	if (IS_ERR(pextp->reset))
> +		return PTR_ERR(pextp->reset);
> +
> +	pextp->da_war = of_property_read_bool(np, "mediatek,usxgmii-performance-errata");
> +
> +	phy = devm_phy_create(&pdev->dev, NULL, &mtk_pextp_ops);
> +	if (IS_ERR(phy))
> +		return PTR_ERR(phy);
> +
> +	phy_set_drvdata(phy, pextp);
> +
> +	phy_provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
> +
> +	return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct of_device_id mtk_pextp_match[] = {
> +	{ .compatible = "mediatek,mt7988-xfi-pextp", },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, mtk_pextp_match);
> +
> +static struct platform_driver mtk_pextp_driver = {
> +	.probe = mtk_pextp_probe,
> +	.driver = {
> +		.name = "mtk-pextp",
> +		.of_match_table = mtk_pextp_match,
> +	},
> +};
> +module_platform_driver(mtk_pextp_driver);

why is this driver in netdev series, it should not be dependent on rest
and can be send separately to phy ss

> +
> +MODULE_DESCRIPTION("MediaTek pextp SerDes PHY driver");
> +MODULE_AUTHOR("Daniel Golle <daniel at makrotopia.org>");
> +MODULE_LICENSE("GPL");
> -- 
> 2.43.0

-- 
~Vinod


From maxime.chevallier at bootlin.com  Thu Dec 21 08:58:57 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 17:58:57 +0100
Subject: [Linux-stm32] [PATCH net-next] net: stmmac: dwmac-qcom-ethqos:
 Add support for 2.5G SGMII
In-Reply-To: <vvlnwiobrgcwuam6lkud2np5xqocj6asjf627j3gekkhm4hfp5@vhdd47fyortm>
References: <20231218071118.21879-1-quic_snehshah@quicinc.com>
	<4zbf5fmijxnajk7kygcjrcusf6tdnuzsqqboh23nr6f3rb3c4g@qkfofhq7jmv6>
	<8b80ab09-8444-4c3d-83b0-c7dbf5e58658@quicinc.com>
	<wvzhz4fmtheculsiag4t2pn2kaggyle2mzhvawbs4m5isvqjto@lmaonvq3c3e7>
	<8f94489d-5f0e-4166-a14e-4959098a5c80@quicinc.com>
	<vvlnwiobrgcwuam6lkud2np5xqocj6asjf627j3gekkhm4hfp5@vhdd47fyortm>
Message-ID: <20231221175857.6d2874ff@device-28.home>

Hello Andrew,

On Thu, 21 Dec 2023 08:30:49 -0600
Andrew Halaney <ahalaney at redhat.com> wrote:

[...]
> 
> Note, I'm struggling to keep up with the standards at play here, so if
> someone else who's a bit more wise on these topics has an opinion I'd
> listen to them. I find myself rewatching this presentation from
> Maxime/Antoine as a primer on all of this:
> 
>     https://www.youtube.com/watch?v=K962S9gTBVM

:)

> If anyone's got any recommended resources for me to read in particular I
> am all ears.

I think Russell and Andrew did a good job clarifying some quirks with
all these standards :

https://elixir.bootlin.com/linux/latest/source/Documentation/networking/phy.rst#L229

There are some more info in Andrew's LPC talk here :
http://vger.kernel.org/lpc_net2018_talks/phylink-and-sfp-slides.pdf

(more phylink related though)

But I agree that this is hard to fully grasp, there are so many
variants everywhere, some standard, some ad-hoc standards, etc.

Maxime


From fusibrandon13 at gmail.com  Thu Dec 21 09:11:07 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Thu, 21 Dec 2023 18:11:07 +0100
Subject: [RFC PATCH v2 2/3] cpufreq: sun50i: Add support for D1's speed bin decoding
In-Reply-To: <20231221124957.27fa9922@donnerap.manchester.arm.com>
References: <20231221124957.27fa9922@donnerap.manchester.arm.com>
Message-ID: <20231221171107.85991-1-fusibrandon13@gmail.com>

On Thu, Dec 21, 2023 at 1:50?PM Andre Przywara <andre.przywara at arm.com> wrote:
>
> On Thu, 21 Dec 2023 11:10:12 +0100
> Brandon Cheo Fusi <fusibrandon13 at gmail.com> wrote:
>
> Hi Brandon,
>
> thanks for the quick turnaround, and for splitting this code up, that
> makes reasoning about this much easier!
>
> > Adds support for decoding the efuse value read from D1 efuse speed
> > bins, and factors out equivalent code for sun50i.
> >
> > The algorithm is gotten from
> >
> > https://github.com/Tina-Linux/linux-5.4/blob/master/drivers/cpufreq/sun50i-cpufreq-nvmem.c#L293-L338
> >
> > and maps an efuse value to either 0 or 1, with 1 meaning stable at
> > a lower supply voltage for the same clock frequency.
> >
> > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > ---
> >  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 34 ++++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > index fc509fc49..b1cb95308 100644
> > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > @@ -29,6 +29,33 @@ struct sunxi_cpufreq_data {
> >       u32 (*efuse_xlate)(u32 *speedbin, size_t len);
> >  };
> >
> > +static u32 sun20i_efuse_xlate(u32 *speedbin, size_t len)
>
> I feel like this prototype can be shortened to:
>
> static u32 sun20i_efuse_xlate(u32 speedbin)
>
> See below.
>
> > +{
> > +     u32 ret, efuse_value = 0;
> > +     int i;
> > +
> > +     for (i = 0; i < len; i++)
> > +             efuse_value |= ((u32)speedbin[i] << (i * 8));
>
> The cast is not needed. Looking deeper into the original code you linked
> to, cell_value[] there is an array of u8, so they assemble a little endian
> 32-bit integer from *up to* four 8-bit values read from the nvmem.
>
> So I think this code here is wrong, len is the size of the nvmem cells
> holding the bin identifier, in *bytes*, so the idea here is to just read
> the (lowest) 16 bits (in the D1 case, cf. "reg = <0x00 0x2>;" in the next
> patch) from this nvmem cell. Here you are combining two 32-bit words into

This is true. Not sure though what the 'in the D1 case...' bit means.

> efuse_value.
>
> So I think this whole part above is actually not necessary: we are
> expecting maximum 32 bits, and nvmem_cell_read() should take care of
> masking off unrequested bits, so we get the correct value back already. So
> can you try to remove the loop above, and use ...
>
> > +
> > +     switch (efuse_value) {
>
>         switch (*speedbin & 0xffff) {
>

Shouldn't the bytes in *speedbin be reversed? 

> here instead? Or drop the pointer at all, and just use one u32 value, see
> the above prototype.
>

I was uncomfortable dropping the len parameter, because then each
platform's efuse_xlate would ignore the number of valid bytes actually
read.

> Cheers,
> Andre
>
> P.S. This is just a "peephole review" of this patch, I haven't got around
> to look at this whole scheme in whole yet, to see if we actually need this
> or can simplify this or clean it up.
>
>
> > +     case 0x5e00:
> > +             /* QFN package */
> > +             ret = 0;
> > +             break;
> > +     case 0x5c00:
> > +     case 0x7400:
> > +             /* QFN package */
> > +             ret = 1;
> > +             break;
> > +     case 0x5000:
> > +     default:
> > +             /* BGA package */
> > +             ret = 0;
> > +     }
> > +
> > +     return ret;
> > +}
> > +
> >  static u32 sun50i_efuse_xlate(u32 *speedbin, size_t len)
> >  {
> >       u32 efuse_value = 0;
> > @@ -46,6 +73,10 @@ static u32 sun50i_efuse_xlate(u32 *speedbin, size_t len)
> >               return 0;
> >  }
> >
> > +struct sunxi_cpufreq_data sun20i_cpufreq_data = {
> > +     .efuse_xlate = sun20i_efuse_xlate,
> > +};
> > +
> >  struct sunxi_cpufreq_data sun50i_cpufreq_data = {
> >       .efuse_xlate = sun50i_efuse_xlate,
> >  };
> > @@ -54,6 +85,9 @@ static const struct of_device_id cpu_opp_match_list[] = {
> >       { .compatible = "allwinner,sun50i-h6-operating-points",
> >         .data = &sun50i_cpufreq_data,
> >       },
> > +     { .compatible = "allwinner,sun20i-d1-operating-points",
> > +       .data = &sun20i_cpufreq_data,
> > +     },
> >       {}
> >  };
> >
>

Thank you for reviewing.
Brandon.


From vkoul at kernel.org  Thu Dec 21 09:15:50 2023
From: vkoul at kernel.org (Vinod Koul)
Date: Thu, 21 Dec 2023 22:45:50 +0530
Subject: (subset) [PATCH v8 00/10] Enable HS-G5 support on SM8550
In-Reply-To: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
References: <1701520577-31163-1-git-send-email-quic_cang@quicinc.com>
Message-ID: <170317895067.712473.11493486832134923013.b4-ty@kernel.org>


On Sat, 02 Dec 2023 04:36:06 -0800, Can Guo wrote:
> This series enables HS-G5 support on SM8550.
> 
> This series is rebased on below changes from Mani -
> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-1-manivannan.sadhasivam at linaro.org/
> https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-2-manivannan.sadhasivam at linaro.org/
> 
> This series is tested on below HW combinations -
> SM8550 MTP + UFS4.0
> SM8550 QRD + UFS3.1
> SM8450 MTP + UFS3.1 (for regression test)
> SM8350 MTP + UFS3.1 (for regression test)
> 
> [...]

Applied, thanks!

[09/10] phy: qualcomm: phy-qcom-qmp-ufs: Rectify SM8550 UFS HS-G4 PHY Settings
        commit: 5301b7a04040b0a6191856c765146e0a9ab88ebc
[10/10] phy: qualcomm: phy-qcom-qmp-ufs: Add High Speed Gear 5 support for SM8550
        (no commit info)

Best regards,
-- 
~Vinod




From vkoul at kernel.org  Thu Dec 21 09:15:59 2023
From: vkoul at kernel.org (Vinod Koul)
Date: Thu, 21 Dec 2023 22:45:59 +0530
Subject: [PATCH v2 1/2] dt-bindings: phy: mediatek: tphy: add a
 property for force-mode switch
In-Reply-To: <20231211025624.28991-1-chunfeng.yun@mediatek.com>
References: <20231211025624.28991-1-chunfeng.yun@mediatek.com>
Message-ID: <170317895962.712473.102387666807925662.b4-ty@kernel.org>


On Mon, 11 Dec 2023 10:56:23 +0800, Chunfeng Yun wrote:
> Due to some old SoCs with shared t-phy between usb3 and pcie only support
> force-mode switch, and shared and non-shared t-phy may exist at the same
> time on a SoC, can't use compatible to distinguish between shared and
> non-shared t-phy, add a property to supported it.
> Currently, only support switch from default pcie mode to usb3 mode.
> But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.
> 
> [...]

Applied, thanks!

[1/2] dt-bindings: phy: mediatek: tphy: add a property for force-mode switch
      commit: cc230a4cd8e91f64c90b5494dfd76848197418ed
[2/2] phy: mediatek: tphy: add support force phy mode switch
      commit: 9b27303003f5af0d378f29ccccea57c7d65cc642

Best regards,
-- 
~Vinod




From andre.draszik at linaro.org  Thu Dec 21 09:22:15 2023
From: andre.draszik at linaro.org (=?ISO-8859-1?Q?Andr=E9?= Draszik)
Date: Thu, 21 Dec 2023 17:22:15 +0000
Subject: [PATCH 2/2] arm64: dts: exynos: gs101: comply with the new
 cmu_misc clock names
In-Reply-To: <20231221090046.1486195-2-tudor.ambarus@linaro.org>
Message-ID: <aa2991470dfb8fb2e80892d62538d0c75444e6c9.camel@linaro.org>

Hi Tudor,

> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index 9747cb3fa03a..d838e3a7af6e 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -289,7 +289,7 @@ cmu_misc: clock-controller at 10010000 {
>  			#clock-cells = <1>;
>  			clocks = <&cmu_top CLK_DOUT_CMU_MISC_BUS>,
>  				 <&cmu_top CLK_DOUT_CMU_MISC_SSS>;
> -			clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
> +			clock-names = "bus", "sss";
>  		};
> 

With this change, parent clock enablement fails, and we get:
    exynos_arm64_register_cmu: could not enable bus clock dout_cmu_misc_bus; err = -2
during boot.


Cheers,
Andre'




From tudor.ambarus at linaro.org  Thu Dec 21 09:23:06 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 21 Dec 2023 17:23:06 +0000
Subject: [PATCH 2/2] arm64: dts: exynos: gs101: comply with the new
 cmu_misc clock names
In-Reply-To: <20231221090046.1486195-2-tudor.ambarus@linaro.org>
References: <20231221090046.1486195-1-tudor.ambarus@linaro.org>
 <20231221090046.1486195-2-tudor.ambarus@linaro.org>
Message-ID: <c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f@linaro.org>



On 12/21/23 09:00, Tudor Ambarus wrote:
> The cmu_misc clock-names were renamed to just "bus" and "sss" because
> naming is local to the module, so cmu_misc is implied. As the bindings
> and the device tree have not made a release yet, comply with the
> renamed clocks.
> 
> Suggested-by: Rob Herring <robh at kernel.org>
> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> ---
>  arch/arm64/boot/dts/exynos/google/gs101.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index 9747cb3fa03a..d838e3a7af6e 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -289,7 +289,7 @@ cmu_misc: clock-controller at 10010000 {
>  			#clock-cells = <1>;
>  			clocks = <&cmu_top CLK_DOUT_CMU_MISC_BUS>,
>  				 <&cmu_top CLK_DOUT_CMU_MISC_SSS>;
> -			clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
> +			clock-names = "bus", "sss";
>  		};
>  
>  		watchdog_cl0: watchdog at 10060000 {

argh, please ignore the patch set. It seems that the clock driver has to
be updated as well:

[    0.050947] exynos_arm64_register_cmu: could not enable bus clock
dout_cmu_misc_bus; err = -2
[    0.052385] exynos_arm64_register_cmu: could not enable bus clock
dout_cmu_peric0_bus; err = -2


From andre.przywara at arm.com  Thu Dec 21 09:26:44 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 21 Dec 2023 17:26:44 +0000
Subject: [RFC PATCH v2 2/3] cpufreq: sun50i: Add support for D1's speed
 bin decoding
In-Reply-To: <20231221171107.85991-1-fusibrandon13@gmail.com>
References: <20231221124957.27fa9922@donnerap.manchester.arm.com>
	<20231221171107.85991-1-fusibrandon13@gmail.com>
Message-ID: <20231221172644.21cf3817@donnerap.manchester.arm.com>

On Thu, 21 Dec 2023 18:11:07 +0100
Brandon Cheo Fusi <fusibrandon13 at gmail.com> wrote:

Hi Brandon,

> On Thu, Dec 21, 2023 at 1:50?PM Andre Przywara <andre.przywara at arm.com> wrote:
> >
> > On Thu, 21 Dec 2023 11:10:12 +0100
> > Brandon Cheo Fusi <fusibrandon13 at gmail.com> wrote:
> >
> > Hi Brandon,
> >
> > thanks for the quick turnaround, and for splitting this code up, that
> > makes reasoning about this much easier!
> >  
> > > Adds support for decoding the efuse value read from D1 efuse speed
> > > bins, and factors out equivalent code for sun50i.
> > >
> > > The algorithm is gotten from
> > >
> > > https://github.com/Tina-Linux/linux-5.4/blob/master/drivers/cpufreq/sun50i-cpufreq-nvmem.c#L293-L338
> > >
> > > and maps an efuse value to either 0 or 1, with 1 meaning stable at
> > > a lower supply voltage for the same clock frequency.
> > >
> > > Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > > ---
> > >  drivers/cpufreq/sun50i-cpufreq-nvmem.c | 34 ++++++++++++++++++++++++++
> > >  1 file changed, 34 insertions(+)
> > >
> > > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > index fc509fc49..b1cb95308 100644
> > > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > @@ -29,6 +29,33 @@ struct sunxi_cpufreq_data {
> > >       u32 (*efuse_xlate)(u32 *speedbin, size_t len);
> > >  };
> > >
> > > +static u32 sun20i_efuse_xlate(u32 *speedbin, size_t len)  
> >
> > I feel like this prototype can be shortened to:
> >
> > static u32 sun20i_efuse_xlate(u32 speedbin)
> >
> > See below.
> >  
> > > +{
> > > +     u32 ret, efuse_value = 0;
> > > +     int i;
> > > +
> > > +     for (i = 0; i < len; i++)
> > > +             efuse_value |= ((u32)speedbin[i] << (i * 8));  
> >
> > The cast is not needed. Looking deeper into the original code you linked
> > to, cell_value[] there is an array of u8, so they assemble a little endian
> > 32-bit integer from *up to* four 8-bit values read from the nvmem.
> >
> > So I think this code here is wrong, len is the size of the nvmem cells
> > holding the bin identifier, in *bytes*, so the idea here is to just read
> > the (lowest) 16 bits (in the D1 case, cf. "reg = <0x00 0x2>;" in the next
> > patch) from this nvmem cell. Here you are combining two 32-bit words into  
> 
> This is true. Not sure though what the 'in the D1 case...' bit means.

In the next patch you introduce the nvmem DT property, and set the length
part to "0x2". So for the D1 we will always read two bytes.

> > efuse_value.
> >
> > So I think this whole part above is actually not necessary: we are
> > expecting maximum 32 bits, and nvmem_cell_read() should take care of
> > masking off unrequested bits, so we get the correct value back already. So
> > can you try to remove the loop above, and use ...
> >  
> > > +
> > > +     switch (efuse_value) {  
> >
> >         switch (*speedbin & 0xffff) {
> >  
> 
> Shouldn't the bytes in *speedbin be reversed? 

I believe they are stored as a little endian 16-bit integer in the fuses.
I haven't tried a BE kernel, but I think the NVMEM framework takes care of
that.
If you dump the values as returned by nvmem_cell_read(), we would know for
sure.

> > here instead? Or drop the pointer at all, and just use one u32 value, see
> > the above prototype.
> >  
> 
> I was uncomfortable dropping the len parameter, because then each
> platform's efuse_xlate would ignore the number of valid bytes actually
> read.

Well, I am not sure either, but neither the H6, nor the H616 or the D1
apparently really need that: they all use either 4 or 2 bytes to encode
the speed bin. And since the routines are SoC specific anyway, and the
first 32-bit word of the buffer filled by nvmem_cell_read() should always
be valid (and be it 0), I think there is little need to check that.
I ported the H616 code over, and it looks somewhat similar to the D1 (with
different numbers, though): it's (ab)using some die revision code (the
first two bytes in the SID) to derive the speed bin. The H6 had a
dedicated bin fuse.

So iff we are going to see a SoC needing to check the length, we can always
introduce that later: it's just an internal function.
But for now I'd like to keep it simple.

Cheers,
Andre

> 
> > Cheers,
> > Andre
> >
> > P.S. This is just a "peephole review" of this patch, I haven't got around
> > to look at this whole scheme in whole yet, to see if we actually need this
> > or can simplify this or clean it up.
> >
> >  
> > > +     case 0x5e00:
> > > +             /* QFN package */
> > > +             ret = 0;
> > > +             break;
> > > +     case 0x5c00:
> > > +     case 0x7400:
> > > +             /* QFN package */
> > > +             ret = 1;
> > > +             break;
> > > +     case 0x5000:
> > > +     default:
> > > +             /* BGA package */
> > > +             ret = 0;
> > > +     }
> > > +
> > > +     return ret;
> > > +}
> > > +
> > >  static u32 sun50i_efuse_xlate(u32 *speedbin, size_t len)
> > >  {
> > >       u32 efuse_value = 0;
> > > @@ -46,6 +73,10 @@ static u32 sun50i_efuse_xlate(u32 *speedbin, size_t len)
> > >               return 0;
> > >  }
> > >
> > > +struct sunxi_cpufreq_data sun20i_cpufreq_data = {
> > > +     .efuse_xlate = sun20i_efuse_xlate,
> > > +};
> > > +
> > >  struct sunxi_cpufreq_data sun50i_cpufreq_data = {
> > >       .efuse_xlate = sun50i_efuse_xlate,
> > >  };
> > > @@ -54,6 +85,9 @@ static const struct of_device_id cpu_opp_match_list[] = {
> > >       { .compatible = "allwinner,sun50i-h6-operating-points",
> > >         .data = &sun50i_cpufreq_data,
> > >       },
> > > +     { .compatible = "allwinner,sun20i-d1-operating-points",
> > > +       .data = &sun20i_cpufreq_data,
> > > +     },
> > >       {}
> > >  };
> > >  
> >  
> 
> Thank you for reviewing.
> Brandon.
> 



From krzysztof.kozlowski at linaro.org  Thu Dec 21 09:27:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 18:27:12 +0100
Subject: [PATCH v1 2/8] dt-bindings: display: add dt-bindings for STM32
 LVDS device
In-Reply-To: <20231221122843.418650-3-raphael.gallais-pou@foss.st.com>
References: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
 <20231221122843.418650-3-raphael.gallais-pou@foss.st.com>
Message-ID: <fcd68fbe-c543-4b6d-9b7f-bcea09918fb9@linaro.org>

On 21/12/2023 13:28, Raphael Gallais-Pou wrote:
> Add dt-binding file for "st,stm32-lvds" compatible.
> 

A nit, subject: drop second/last, redundant "dt-bindings for". The
"dt-bindings" prefix is already stating that these are bindings.

> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
> ---
>  .../bindings/display/st,stm32-lvds.yaml       | 114 ++++++++++++++++++
>  1 file changed, 114 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
> 

...

> +properties:
> +  "#clock-cells":
> +    const: 0
> +
> +  compatible:
> +    const: st,stm32-lvds

Please put compatible as first.

> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    items:
> +      - description: APB peripheral clock
> +      - description: Reference clock for the internal PLL
> +
> +  clock-names:
> +    items:
> +      - const: pclk
> +      - const: ref
> +
> +  resets:
> +    maxItems: 1
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port at 0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: |
> +          LVDS input port node, connected to the LTDC RGB output port.
> +
> +      port at 1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: |
> +          LVDS output port node, connected to a panel or bridge input port.

Ports are not required? I would assume it won't work without input and
output.

> +
> +required:
> +  - "#clock-cells"
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - resets
> +  - ports
> +
> +unevaluatedProperties: false

additionalProperties instead... or did I miss some $ref anywhere?

> +
> +examples:
> +  - |
> +    #include <dt-bindings/bus/stm32mp25_sys_bus.h>
> +    #include <dt-bindings/clock/stm32mp25-clks.h>
> +    #include <dt-bindings/reset/stm32mp25-resets.h>
> +
> +    lvds: lvds at 48060000 {
> +        #clock-cells = <0>;
> +        compatible = "st,stm32-lvds";

compatible is always the first property.

> +        reg = <0x48060000 0x2000>;

put clock-cells here

> +        clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
> +        clock-names = "pclk", "ref";
> +        resets = <&rcc LVDS_R>;

Best regards,
Krzysztof



From maxime.chevallier at bootlin.com  Thu Dec 21 09:31:45 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 18:31:45 +0100
Subject: [PATCH net-next v4 10/13] net: ethtool: pse-pd: Target the
 command to the requested PHY
In-Reply-To: <5f3a74fe-11e4-4c6e-a77d-f9c4f6fab156@lunn.ch>
References: <20231215171237.1152563-1-maxime.chevallier@bootlin.com>
	<20231215171237.1152563-11-maxime.chevallier@bootlin.com>
	<5f3a74fe-11e4-4c6e-a77d-f9c4f6fab156@lunn.ch>
Message-ID: <20231221183145.31c167c0@device-28.home>

Hi Andrew,

Sorry I forgot to reply to that one...

On Mon, 18 Dec 2023 10:58:30 +0100
Andrew Lunn <andrew at lunn.ch> wrote:

> On Fri, Dec 15, 2023 at 06:12:32PM +0100, Maxime Chevallier wrote:
> > PSE and PD configuration is a PHY-specific command. Instead of targeting
> > the command towards dev->phydev, use the request to pick the targeted
> > PHY device.
> > 
> > Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
> > ---
> > V4: No changes
> > V3: No changes
> > V2: New patch
> > 
> >  net/ethtool/pse-pd.c | 14 +++-----------
> >  1 file changed, 3 insertions(+), 11 deletions(-)
> > 
> > diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
> > index cc478af77111..0d9cd9c87104 100644
> > --- a/net/ethtool/pse-pd.c
> > +++ b/net/ethtool/pse-pd.c
> > @@ -31,17 +31,10 @@ const struct nla_policy ethnl_pse_get_policy[ETHTOOL_A_PSE_HEADER + 1] = {
> >  	[ETHTOOL_A_PSE_HEADER] = NLA_POLICY_NESTED(ethnl_header_policy),
> >  };
> >  
> > -static int pse_get_pse_attributes(struct net_device *dev,
> > +static int pse_get_pse_attributes(struct phy_device *phydev,
> >  				  struct netlink_ext_ack *extack,
> >  				  struct pse_reply_data *data)
> >  {
> > -	struct phy_device *phydev = dev->phydev;
> > -
> > -	if (!phydev) {
> > -		NL_SET_ERR_MSG(extack, "No PHY is attached");
> > -		return -EOPNOTSUPP;
> > -	}
> > -  
> 
> It would be good to say in the commit message why it is safe to remove
> this.

That's a good catch, this removal is wrong and will be put back in the
next iteration.

> > @@ -132,7 +124,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
> >  	/* this values are already validated by the ethnl_pse_set_policy */
> >  	config.admin_cotrol = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);
> >  
> > -	phydev = dev->phydev;
> > +	phydev = req_info->phydev;
> >  	if (!phydev) {
> >  		NL_SET_ERR_MSG(info->extack, "No PHY is attached");
> >  		return -EOPNOTSUPP;  
> 
> So you removed one test, but this one stays?

Thanks for the review,

Maxime



From zajec5 at gmail.com  Thu Dec 21 09:34:16 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 21 Dec 2023 18:34:16 +0100
Subject: [PATCH V3 1/6] dt-bindings: nvmem: layouts: add U-Boot environment variables layout
Message-ID: <20231221173421.13737-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various storage devices. Its binding should
be an NVMEM layout instead of a standalone device.

This patch adds layout binding which allows using it on top of MTD NVMEM
device as well as any other. At the same time it deprecates the old
combined binding.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
V2: Add "-layout" suffix to compatibles to avoid conflict

 .../nvmem/layouts/u-boot,env-layout.yaml      | 55 +++++++++++++++++++
 .../devicetree/bindings/nvmem/u-boot,env.yaml |  6 ++
 2 files changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/u-boot,env-layout.yaml

diff --git a/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env-layout.yaml
new file mode 100644
index 000000000000..3b4d8f2a44e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env-layout.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env-layout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of U-Boot environment variables
+
+maintainers:
+  - Rafa? Mi?ecki <rafal at milecki.pl>
+
+description:
+  U-Boot uses environment variables to store device parameters and
+  configuration. They may be used for booting process, setup or keeping end user
+  info.
+
+  Data is stored using U-Boot specific formats (variant specific header and NUL
+  separated key-value pairs).
+
+properties:
+  compatible:
+    oneOf:
+      - description: A standalone env data block
+        const: u-boot,env-layout
+      - description: Two redundant blocks with active one flagged
+        const: u-boot,env-redundant-bool-layout
+      - description: Two redundant blocks with active having higher counter
+        const: u-boot,env-redundant-count-layout
+      - description: Broadcom's variant with custom header
+        const: brcm,env-layout
+
+additionalProperties: false
+
+examples:
+  - |
+    partitions {
+        compatible = "fixed-partitions";
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        partition at 0 {
+            reg = <0x0 0x40000>;
+            label = "u-boot";
+            read-only;
+        };
+
+        partition at 40000 {
+            reg = <0x40000 0x10000>;
+            label = "u-boot-env";
+
+            nvmem-layout {
+                compatible = "u-boot,env-layout";
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
index 9c36afc7084b..6c2a3ca5f051 100644
--- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
@@ -26,9 +26,15 @@ description: |
 
   Variables can be defined as NVMEM device subnodes.
 
+  Introduction of NVMEM layouts exposed a limitation of this binding design.
+  Description of NVMEM data content should be separated from NVMEM devices.
+  Since the introduction of U-Boot env data layout this binding is deprecated.
+
 maintainers:
   - Rafa? Mi?ecki <rafal at milecki.pl>
 
+deprecated: true
+
 properties:
   compatible:
     oneOf:
-- 
2.35.3



From zajec5 at gmail.com  Thu Dec 21 09:34:17 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 21 Dec 2023 18:34:17 +0100
Subject: [PATCH V3 2/6] nvmem: core: add nvmem_dev_size() helper
In-Reply-To: <20231221173421.13737-1-zajec5@gmail.com>
References: <20231221173421.13737-1-zajec5@gmail.com>
Message-ID: <20231221173421.13737-2-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This is required by layouts that need to read whole NVMEM content. It's
especially useful for NVMEM devices without hardcoded layout (like
U-Boot environment data block).

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
 drivers/nvmem/core.c           | 13 +++++++++++++
 include/linux/nvmem-consumer.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 4ed54076346d..980123fb4dde 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -2163,6 +2163,19 @@ const char *nvmem_dev_name(struct nvmem_device *nvmem)
 }
 EXPORT_SYMBOL_GPL(nvmem_dev_name);
 
+/**
+ * nvmem_dev_size() - Get the size of a given nvmem device.
+ *
+ * @nvmem: nvmem device.
+ *
+ * Return: size of the nvmem device.
+ */
+size_t nvmem_dev_size(struct nvmem_device *nvmem)
+{
+	return nvmem->size;
+}
+EXPORT_SYMBOL_GPL(nvmem_dev_size);
+
 static int __init nvmem_init(void)
 {
 	int ret;
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 2d306fa13b1a..34c0e58dfa26 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -81,6 +81,7 @@ int nvmem_device_cell_write(struct nvmem_device *nvmem,
 			    struct nvmem_cell_info *info, void *buf);
 
 const char *nvmem_dev_name(struct nvmem_device *nvmem);
+size_t nvmem_dev_size(struct nvmem_device *nvmem);
 
 void nvmem_add_cell_lookups(struct nvmem_cell_lookup *entries,
 			    size_t nentries);
-- 
2.35.3



From zajec5 at gmail.com  Thu Dec 21 09:34:18 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 21 Dec 2023 18:34:18 +0100
Subject: [PATCH V3 3/6] nvmem: u-boot-env: use nvmem_add_one_cell() nvmem subsystem helper
In-Reply-To: <20231221173421.13737-1-zajec5@gmail.com>
References: <20231221173421.13737-1-zajec5@gmail.com>
Message-ID: <20231221173421.13737-3-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Simplify adding NVMEM cells.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
V3: Split PATCH 3/3 into two

 drivers/nvmem/u-boot-env.c | 55 +++++++++++++++-----------------------
 1 file changed, 21 insertions(+), 34 deletions(-)

diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index c4ae94af4af7..dd9d0ad22712 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -23,13 +23,10 @@ enum u_boot_env_format {
 
 struct u_boot_env {
 	struct device *dev;
+	struct nvmem_device *nvmem;
 	enum u_boot_env_format format;
 
 	struct mtd_info *mtd;
-
-	/* Cells */
-	struct nvmem_cell_info *cells;
-	int ncells;
 };
 
 struct u_boot_env_image_single {
@@ -94,43 +91,36 @@ static int u_boot_env_read_post_process_ethaddr(void *context, const char *id, i
 static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
 				size_t data_offset, size_t data_len)
 {
+	struct nvmem_device *nvmem = priv->nvmem;
 	struct device *dev = priv->dev;
 	char *data = buf + data_offset;
 	char *var, *value, *eq;
-	int idx;
-
-	priv->ncells = 0;
-	for (var = data; var < data + data_len && *var; var += strlen(var) + 1)
-		priv->ncells++;
-
-	priv->cells = devm_kcalloc(dev, priv->ncells, sizeof(*priv->cells), GFP_KERNEL);
-	if (!priv->cells)
-		return -ENOMEM;
 
-	for (var = data, idx = 0;
+	for (var = data;
 	     var < data + data_len && *var;
-	     var = value + strlen(value) + 1, idx++) {
+	     var = value + strlen(value) + 1) {
+		struct nvmem_cell_info info = {};
+
 		eq = strchr(var, '=');
 		if (!eq)
 			break;
 		*eq = '\0';
 		value = eq + 1;
 
-		priv->cells[idx].name = devm_kstrdup(dev, var, GFP_KERNEL);
-		if (!priv->cells[idx].name)
+		info.name = devm_kstrdup(dev, var, GFP_KERNEL);
+		if (!info.name)
 			return -ENOMEM;
-		priv->cells[idx].offset = data_offset + value - data;
-		priv->cells[idx].bytes = strlen(value);
-		priv->cells[idx].np = of_get_child_by_name(dev->of_node, priv->cells[idx].name);
+		info.offset = data_offset + value - data;
+		info.bytes = strlen(value);
+		info.np = of_get_child_by_name(dev->of_node, info.name);
 		if (!strcmp(var, "ethaddr")) {
-			priv->cells[idx].raw_len = strlen(value);
-			priv->cells[idx].bytes = ETH_ALEN;
-			priv->cells[idx].read_post_process = u_boot_env_read_post_process_ethaddr;
+			info.raw_len = strlen(value);
+			info.bytes = ETH_ALEN;
+			info.read_post_process = u_boot_env_read_post_process_ethaddr;
 		}
-	}
 
-	if (WARN_ON(idx != priv->ncells))
-		priv->ncells = idx;
+		nvmem_add_one_cell(nvmem, &info);
+	}
 
 	return 0;
 }
@@ -209,7 +199,6 @@ static int u_boot_env_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
 	struct u_boot_env *priv;
-	int err;
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -224,17 +213,15 @@ static int u_boot_env_probe(struct platform_device *pdev)
 		return PTR_ERR(priv->mtd);
 	}
 
-	err = u_boot_env_parse(priv);
-	if (err)
-		return err;
-
 	config.dev = dev;
-	config.cells = priv->cells;
-	config.ncells = priv->ncells;
 	config.priv = priv;
 	config.size = priv->mtd->size;
 
-	return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &config));
+	priv->nvmem = devm_nvmem_register(dev, &config);
+	if (IS_ERR(priv->nvmem))
+		return PTR_ERR(priv->nvmem);
+
+	return u_boot_env_parse(priv);
 }
 
 static const struct of_device_id u_boot_env_of_match_table[] = {
-- 
2.35.3



From zajec5 at gmail.com  Thu Dec 21 09:34:19 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 21 Dec 2023 18:34:19 +0100
Subject: [PATCH V3 4/6] nvmem: u-boot-env: use nvmem device helpers
In-Reply-To: <20231221173421.13737-1-zajec5@gmail.com>
References: <20231221173421.13737-1-zajec5@gmail.com>
Message-ID: <20231221173421.13737-4-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Use nvmem_dev_size() and nvmem_device_read() to make this driver less
mtd dependent.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
V2: Don't introduce memleak when handling nvmem_device_read() failures
V3: Split PATCH 3/3 into two

 drivers/nvmem/u-boot-env.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index dd9d0ad22712..111905189341 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -127,27 +127,34 @@ static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
 
 static int u_boot_env_parse(struct u_boot_env *priv)
 {
+	struct nvmem_device *nvmem = priv->nvmem;
 	struct device *dev = priv->dev;
 	size_t crc32_data_offset;
 	size_t crc32_data_len;
 	size_t crc32_offset;
 	size_t data_offset;
 	size_t data_len;
+	size_t dev_size;
 	uint32_t crc32;
 	uint32_t calc;
-	size_t bytes;
 	uint8_t *buf;
+	int bytes;
 	int err;
 
-	buf = kcalloc(1, priv->mtd->size, GFP_KERNEL);
+	dev_size = nvmem_dev_size(nvmem);
+
+	buf = kcalloc(1, dev_size, GFP_KERNEL);
 	if (!buf) {
 		err = -ENOMEM;
 		goto err_out;
 	}
 
-	err = mtd_read(priv->mtd, 0, priv->mtd->size, &bytes, buf);
-	if ((err && !mtd_is_bitflip(err)) || bytes != priv->mtd->size) {
-		dev_err(dev, "Failed to read from mtd: %d\n", err);
+	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
+	if (bytes < 0) {
+		err = bytes;
+		goto err_kfree;
+	} else if (bytes != dev_size) {
+		err = -EIO;
 		goto err_kfree;
 	}
 
@@ -169,8 +176,8 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 		break;
 	}
 	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
-	crc32_data_len = priv->mtd->size - crc32_data_offset;
-	data_len = priv->mtd->size - data_offset;
+	crc32_data_len = dev_size - crc32_data_offset;
+	data_len = dev_size - data_offset;
 
 	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
 	if (calc != crc32) {
@@ -179,7 +186,7 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 		goto err_kfree;
 	}
 
-	buf[priv->mtd->size - 1] = '\0';
+	buf[dev_size - 1] = '\0';
 	err = u_boot_env_add_cells(priv, buf, data_offset, data_len);
 	if (err)
 		dev_err(dev, "Failed to add cells: %d\n", err);
-- 
2.35.3



From zajec5 at gmail.com  Thu Dec 21 09:34:20 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 21 Dec 2023 18:34:20 +0100
Subject: [PATCH V3 5/6] nvmem: u-boot-env: improve coding style
In-Reply-To: <20231221173421.13737-1-zajec5@gmail.com>
References: <20231221173421.13737-1-zajec5@gmail.com>
Message-ID: <20231221173421.13737-5-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

1. Prefer kzalloc() over kcalloc()
   See memory-allocation.rst which says: "to be on the safe side it's
   best to use routines that set memory to zero, like kzalloc()"
2. Drop dev_err() for u_boot_env_add_cells() fail
   It can fail only on -ENOMEM. We don't want to print error then.
3. Add extra "crc32_addr" variable
   It makes code reading header's crc32 easier to understand / review.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
V2: New patch with suggestions from Miquel

 drivers/nvmem/u-boot-env.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index 111905189341..befbab156cda 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -132,6 +132,7 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 	size_t crc32_data_offset;
 	size_t crc32_data_len;
 	size_t crc32_offset;
+	__le32 *crc32_addr;
 	size_t data_offset;
 	size_t data_len;
 	size_t dev_size;
@@ -143,7 +144,7 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 
 	dev_size = nvmem_dev_size(nvmem);
 
-	buf = kcalloc(1, dev_size, GFP_KERNEL);
+	buf = kzalloc(dev_size, GFP_KERNEL);
 	if (!buf) {
 		err = -ENOMEM;
 		goto err_out;
@@ -175,7 +176,8 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
 		break;
 	}
-	crc32 = le32_to_cpu(*(__le32 *)(buf + crc32_offset));
+	crc32_addr = (__le32 *)(buf + crc32_offset);
+	crc32 = le32_to_cpu(*crc32_addr);
 	crc32_data_len = dev_size - crc32_data_offset;
 	data_len = dev_size - data_offset;
 
@@ -188,8 +190,6 @@ static int u_boot_env_parse(struct u_boot_env *priv)
 
 	buf[dev_size - 1] = '\0';
 	err = u_boot_env_add_cells(priv, buf, data_offset, data_len);
-	if (err)
-		dev_err(dev, "Failed to add cells: %d\n", err);
 
 err_kfree:
 	kfree(buf);
-- 
2.35.3



From zajec5 at gmail.com  Thu Dec 21 09:34:21 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 21 Dec 2023 18:34:21 +0100
Subject: [PATCH V3 6/6] nvmem: layouts: add U-Boot env layout
In-Reply-To: <20231221173421.13737-1-zajec5@gmail.com>
References: <20231221173421.13737-1-zajec5@gmail.com>
Message-ID: <20231221173421.13737-6-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Move all generic (NVMEM devices independent) code from NVMEM device
driver to NVMEM layout driver. Then add a simple NVMEM layout code on
top of it.

Thanks to proper layout it's possible to support U-Boot env data stored
on any kind of NVMEM device.

For backward compatibility with old DT bindings we need to keep old
NVMEM device driver functional. To avoid code duplication export and
reuse a parsing function.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>
---
V2: Support new compatibles & use device_get_match_data() helper
V3: Use imperative in commit body

IMPORTANT:
This is based on top of the:
[PATCH v6.8 1/2] nvmem: layouts: refactor .add_cells() callback arguments

 MAINTAINERS                        |   1 +
 drivers/nvmem/Kconfig              |   3 +-
 drivers/nvmem/layouts/Kconfig      |  11 ++
 drivers/nvmem/layouts/Makefile     |   1 +
 drivers/nvmem/layouts/u-boot-env.c | 204 +++++++++++++++++++++++++++++
 drivers/nvmem/layouts/u-boot-env.h |  15 +++
 drivers/nvmem/u-boot-env.c         | 158 +---------------------
 7 files changed, 235 insertions(+), 158 deletions(-)
 create mode 100644 drivers/nvmem/layouts/u-boot-env.c
 create mode 100644 drivers/nvmem/layouts/u-boot-env.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b589218605b4..1f7e6d74cd51 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22282,6 +22282,7 @@ U-BOOT ENVIRONMENT VARIABLES
 M:	Rafa? Mi?ecki <rafal at milecki.pl>
 S:	Maintained
 F:	Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+F:	drivers/nvmem/layouts/u-boot-env.c
 F:	drivers/nvmem/u-boot-env.c
 
 UACCE ACCELERATOR FRAMEWORK
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 283134498fbc..d2c384f58028 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -363,8 +363,7 @@ config NVMEM_SUNXI_SID
 config NVMEM_U_BOOT_ENV
 	tristate "U-Boot environment variables support"
 	depends on OF && MTD
-	select CRC32
-	select GENERIC_NET_UTILS
+	select NVMEM_LAYOUT_U_BOOT_ENV
 	help
 	  U-Boot stores its setup as environment variables. This driver adds
 	  support for verifying & exporting such data. It also exposes variables
diff --git a/drivers/nvmem/layouts/Kconfig b/drivers/nvmem/layouts/Kconfig
index 9c6e672fc350..5e586dfebe47 100644
--- a/drivers/nvmem/layouts/Kconfig
+++ b/drivers/nvmem/layouts/Kconfig
@@ -26,6 +26,17 @@ config NVMEM_LAYOUT_ONIE_TLV
 
 	  If unsure, say N.
 
+config NVMEM_LAYOUT_U_BOOT_ENV
+	tristate "U-Boot environment variables layout"
+	select CRC32
+	select GENERIC_NET_UTILS
+	help
+	  U-Boot stores its setup as environment variables. This driver adds
+	  support for verifying & exporting such data. It also exposes variables
+	  as NVMEM cells so they can be referenced by other drivers.
+
+	  If unsure, say N.
+
 endmenu
 
 endif
diff --git a/drivers/nvmem/layouts/Makefile b/drivers/nvmem/layouts/Makefile
index 2974bd7d33ed..4940c9db0665 100644
--- a/drivers/nvmem/layouts/Makefile
+++ b/drivers/nvmem/layouts/Makefile
@@ -5,3 +5,4 @@
 
 obj-$(CONFIG_NVMEM_LAYOUT_SL28_VPD) += sl28vpd.o
 obj-$(CONFIG_NVMEM_LAYOUT_ONIE_TLV) += onie-tlv.o
+obj-$(CONFIG_NVMEM_LAYOUT_U_BOOT_ENV) += u-boot-env.o
diff --git a/drivers/nvmem/layouts/u-boot-env.c b/drivers/nvmem/layouts/u-boot-env.c
new file mode 100644
index 000000000000..dcd2ffed503c
--- /dev/null
+++ b/drivers/nvmem/layouts/u-boot-env.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 - 2023 Rafa? Mi?ecki <rafal at milecki.pl>
+ */
+
+#include <linux/crc32.h>
+#include <linux/etherdevice.h>
+#include <linux/export.h>
+#include <linux/if_ether.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+#include "u-boot-env.h"
+
+struct u_boot_env_image_single {
+	__le32 crc32;
+	uint8_t data[];
+} __packed;
+
+struct u_boot_env_image_redundant {
+	__le32 crc32;
+	u8 mark;
+	uint8_t data[];
+} __packed;
+
+struct u_boot_env_image_broadcom {
+	__le32 magic;
+	__le32 len;
+	__le32 crc32;
+	DECLARE_FLEX_ARRAY(uint8_t, data);
+} __packed;
+
+static int u_boot_env_read_post_process_ethaddr(void *context, const char *id, int index,
+						unsigned int offset, void *buf, size_t bytes)
+{
+	u8 mac[ETH_ALEN];
+
+	if (bytes != 3 * ETH_ALEN - 1)
+		return -EINVAL;
+
+	if (!mac_pton(buf, mac))
+		return -EINVAL;
+
+	if (index)
+		eth_addr_add(mac, index);
+
+	ether_addr_copy(buf, mac);
+
+	return 0;
+}
+
+static int u_boot_env_parse_cells(struct device *dev, struct nvmem_device *nvmem, uint8_t *buf,
+				  size_t data_offset, size_t data_len)
+{
+	char *data = buf + data_offset;
+	char *var, *value, *eq;
+
+	for (var = data;
+	     var < data + data_len && *var;
+	     var = value + strlen(value) + 1) {
+		struct nvmem_cell_info info = {};
+
+		eq = strchr(var, '=');
+		if (!eq)
+			break;
+		*eq = '\0';
+		value = eq + 1;
+
+		info.name = devm_kstrdup(dev, var, GFP_KERNEL);
+		if (!info.name)
+			return -ENOMEM;
+		info.offset = data_offset + value - data;
+		info.bytes = strlen(value);
+		info.np = of_get_child_by_name(dev->of_node, info.name);
+		if (!strcmp(var, "ethaddr")) {
+			info.raw_len = strlen(value);
+			info.bytes = ETH_ALEN;
+			info.read_post_process = u_boot_env_read_post_process_ethaddr;
+		}
+
+		nvmem_add_one_cell(nvmem, &info);
+	}
+
+	return 0;
+}
+
+int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
+		     enum u_boot_env_format format)
+{
+	size_t crc32_data_offset;
+	size_t crc32_data_len;
+	size_t crc32_offset;
+	__le32 *crc32_addr;
+	size_t data_offset;
+	size_t data_len;
+	size_t dev_size;
+	uint32_t crc32;
+	uint32_t calc;
+	uint8_t *buf;
+	int bytes;
+	int err;
+
+	dev_size = nvmem_dev_size(nvmem);
+
+	buf = kzalloc(dev_size, GFP_KERNEL);
+	if (!buf) {
+		err = -ENOMEM;
+		goto err_out;
+	}
+
+	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
+	if (bytes < 0) {
+		err = bytes;
+		goto err_kfree;
+	} else if (bytes != dev_size) {
+		err = -EIO;
+		goto err_kfree;
+	}
+
+	switch (format) {
+	case U_BOOT_FORMAT_SINGLE:
+		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
+		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
+		data_offset = offsetof(struct u_boot_env_image_single, data);
+		break;
+	case U_BOOT_FORMAT_REDUNDANT:
+		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
+		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
+		data_offset = offsetof(struct u_boot_env_image_redundant, data);
+		break;
+	case U_BOOT_FORMAT_BROADCOM:
+		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
+		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
+		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
+		break;
+	}
+	crc32_addr = (__le32 *)(buf + crc32_offset);
+	crc32 = le32_to_cpu(*crc32_addr);
+	crc32_data_len = dev_size - crc32_data_offset;
+	data_len = dev_size - data_offset;
+
+	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
+	if (calc != crc32) {
+		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
+		err = -EINVAL;
+		goto err_kfree;
+	}
+
+	buf[dev_size - 1] = '\0';
+	err = u_boot_env_parse_cells(dev, nvmem, buf, data_offset, data_len);
+
+err_kfree:
+	kfree(buf);
+err_out:
+	return err;
+}
+EXPORT_SYMBOL_GPL(u_boot_env_parse);
+
+static int u_boot_env_add_cells(struct nvmem_layout *layout)
+{
+	struct device *dev = &layout->dev;
+	enum u_boot_env_format format;
+
+	format = (uintptr_t)device_get_match_data(dev);
+
+	return u_boot_env_parse(dev, layout->nvmem, format);
+}
+
+static int u_boot_env_probe(struct nvmem_layout *layout)
+{
+	layout->add_cells = u_boot_env_add_cells;
+
+	return nvmem_layout_register(layout);
+}
+
+static void u_boot_env_remove(struct nvmem_layout *layout)
+{
+	nvmem_layout_unregister(layout);
+}
+
+static const struct of_device_id u_boot_env_of_match_table[] = {
+	{ .compatible = "u-boot,env-layout", .data = (void *)U_BOOT_FORMAT_SINGLE, },
+	{ .compatible = "u-boot,env-redundant-bool-layout", .data = (void *)U_BOOT_FORMAT_REDUNDANT, },
+	{ .compatible = "u-boot,env-redundant-count-layout", .data = (void *)U_BOOT_FORMAT_REDUNDANT, },
+	{ .compatible = "brcm,env-layout", .data = (void *)U_BOOT_FORMAT_BROADCOM, },
+	{},
+};
+
+static struct nvmem_layout_driver u_boot_env_layout = {
+	.driver = {
+		.owner = THIS_MODULE,
+		.name = "u-boot-env-layout",
+		.of_match_table = u_boot_env_of_match_table,
+	},
+	.probe = u_boot_env_probe,
+	.remove = u_boot_env_remove,
+};
+module_nvmem_layout_driver(u_boot_env_layout);
+
+MODULE_AUTHOR("Rafa? Mi?ecki");
+MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, u_boot_env_of_match_table);
diff --git a/drivers/nvmem/layouts/u-boot-env.h b/drivers/nvmem/layouts/u-boot-env.h
new file mode 100644
index 000000000000..dd5f280ac047
--- /dev/null
+++ b/drivers/nvmem/layouts/u-boot-env.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _LINUX_NVMEM_LAYOUTS_U_BOOT_ENV_H
+#define _LINUX_NVMEM_LAYOUTS_U_BOOT_ENV_H
+
+enum u_boot_env_format {
+	U_BOOT_FORMAT_SINGLE,
+	U_BOOT_FORMAT_REDUNDANT,
+	U_BOOT_FORMAT_BROADCOM,
+};
+
+int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem,
+		     enum u_boot_env_format format);
+
+#endif  /* ifndef _LINUX_NVMEM_LAYOUTS_U_BOOT_ENV_H */
diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
index befbab156cda..386b2b255c30 100644
--- a/drivers/nvmem/u-boot-env.c
+++ b/drivers/nvmem/u-boot-env.c
@@ -3,23 +3,15 @@
  * Copyright (C) 2022 Rafa? Mi?ecki <rafal at milecki.pl>
  */
 
-#include <linux/crc32.h>
-#include <linux/etherdevice.h>
-#include <linux/if_ether.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/mtd/mtd.h>
-#include <linux/nvmem-consumer.h>
 #include <linux/nvmem-provider.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
-enum u_boot_env_format {
-	U_BOOT_FORMAT_SINGLE,
-	U_BOOT_FORMAT_REDUNDANT,
-	U_BOOT_FORMAT_BROADCOM,
-};
+#include "layouts/u-boot-env.h"
 
 struct u_boot_env {
 	struct device *dev;
@@ -29,24 +21,6 @@ struct u_boot_env {
 	struct mtd_info *mtd;
 };
 
-struct u_boot_env_image_single {
-	__le32 crc32;
-	uint8_t data[];
-} __packed;
-
-struct u_boot_env_image_redundant {
-	__le32 crc32;
-	u8 mark;
-	uint8_t data[];
-} __packed;
-
-struct u_boot_env_image_broadcom {
-	__le32 magic;
-	__le32 len;
-	__le32 crc32;
-	DECLARE_FLEX_ARRAY(uint8_t, data);
-} __packed;
-
 static int u_boot_env_read(void *context, unsigned int offset, void *val,
 			   size_t bytes)
 {
@@ -69,134 +43,6 @@ static int u_boot_env_read(void *context, unsigned int offset, void *val,
 	return 0;
 }
 
-static int u_boot_env_read_post_process_ethaddr(void *context, const char *id, int index,
-						unsigned int offset, void *buf, size_t bytes)
-{
-	u8 mac[ETH_ALEN];
-
-	if (bytes != 3 * ETH_ALEN - 1)
-		return -EINVAL;
-
-	if (!mac_pton(buf, mac))
-		return -EINVAL;
-
-	if (index)
-		eth_addr_add(mac, index);
-
-	ether_addr_copy(buf, mac);
-
-	return 0;
-}
-
-static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf,
-				size_t data_offset, size_t data_len)
-{
-	struct nvmem_device *nvmem = priv->nvmem;
-	struct device *dev = priv->dev;
-	char *data = buf + data_offset;
-	char *var, *value, *eq;
-
-	for (var = data;
-	     var < data + data_len && *var;
-	     var = value + strlen(value) + 1) {
-		struct nvmem_cell_info info = {};
-
-		eq = strchr(var, '=');
-		if (!eq)
-			break;
-		*eq = '\0';
-		value = eq + 1;
-
-		info.name = devm_kstrdup(dev, var, GFP_KERNEL);
-		if (!info.name)
-			return -ENOMEM;
-		info.offset = data_offset + value - data;
-		info.bytes = strlen(value);
-		info.np = of_get_child_by_name(dev->of_node, info.name);
-		if (!strcmp(var, "ethaddr")) {
-			info.raw_len = strlen(value);
-			info.bytes = ETH_ALEN;
-			info.read_post_process = u_boot_env_read_post_process_ethaddr;
-		}
-
-		nvmem_add_one_cell(nvmem, &info);
-	}
-
-	return 0;
-}
-
-static int u_boot_env_parse(struct u_boot_env *priv)
-{
-	struct nvmem_device *nvmem = priv->nvmem;
-	struct device *dev = priv->dev;
-	size_t crc32_data_offset;
-	size_t crc32_data_len;
-	size_t crc32_offset;
-	__le32 *crc32_addr;
-	size_t data_offset;
-	size_t data_len;
-	size_t dev_size;
-	uint32_t crc32;
-	uint32_t calc;
-	uint8_t *buf;
-	int bytes;
-	int err;
-
-	dev_size = nvmem_dev_size(nvmem);
-
-	buf = kzalloc(dev_size, GFP_KERNEL);
-	if (!buf) {
-		err = -ENOMEM;
-		goto err_out;
-	}
-
-	bytes = nvmem_device_read(nvmem, 0, dev_size, buf);
-	if (bytes < 0) {
-		err = bytes;
-		goto err_kfree;
-	} else if (bytes != dev_size) {
-		err = -EIO;
-		goto err_kfree;
-	}
-
-	switch (priv->format) {
-	case U_BOOT_FORMAT_SINGLE:
-		crc32_offset = offsetof(struct u_boot_env_image_single, crc32);
-		crc32_data_offset = offsetof(struct u_boot_env_image_single, data);
-		data_offset = offsetof(struct u_boot_env_image_single, data);
-		break;
-	case U_BOOT_FORMAT_REDUNDANT:
-		crc32_offset = offsetof(struct u_boot_env_image_redundant, crc32);
-		crc32_data_offset = offsetof(struct u_boot_env_image_redundant, data);
-		data_offset = offsetof(struct u_boot_env_image_redundant, data);
-		break;
-	case U_BOOT_FORMAT_BROADCOM:
-		crc32_offset = offsetof(struct u_boot_env_image_broadcom, crc32);
-		crc32_data_offset = offsetof(struct u_boot_env_image_broadcom, data);
-		data_offset = offsetof(struct u_boot_env_image_broadcom, data);
-		break;
-	}
-	crc32_addr = (__le32 *)(buf + crc32_offset);
-	crc32 = le32_to_cpu(*crc32_addr);
-	crc32_data_len = dev_size - crc32_data_offset;
-	data_len = dev_size - data_offset;
-
-	calc = crc32(~0, buf + crc32_data_offset, crc32_data_len) ^ ~0L;
-	if (calc != crc32) {
-		dev_err(dev, "Invalid calculated CRC32: 0x%08x (expected: 0x%08x)\n", calc, crc32);
-		err = -EINVAL;
-		goto err_kfree;
-	}
-
-	buf[dev_size - 1] = '\0';
-	err = u_boot_env_add_cells(priv, buf, data_offset, data_len);
-
-err_kfree:
-	kfree(buf);
-err_out:
-	return err;
-}
-
 static int u_boot_env_probe(struct platform_device *pdev)
 {
 	struct nvmem_config config = {
@@ -228,7 +74,7 @@ static int u_boot_env_probe(struct platform_device *pdev)
 	if (IS_ERR(priv->nvmem))
 		return PTR_ERR(priv->nvmem);
 
-	return u_boot_env_parse(priv);
+	return u_boot_env_parse(dev, priv->nvmem, priv->format);
 }
 
 static const struct of_device_id u_boot_env_of_match_table[] = {
-- 
2.35.3



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:37 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:37 +0100
Subject: [PATCH net-next v5 04/13] net: sfp: Add helper to return the SFP bus name
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-5-maxime.chevallier@bootlin.com>

Knowing the bus name is helpful when we want to expose the link topology
to userspace, add a helper to return the SFP bus name.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
V5: - Added Andrew's R-b
V4: - No changes
V3: - Added RTNL assert
    - Made the stub inline
V2: New patch

 drivers/net/phy/sfp-bus.c | 11 +++++++++++
 include/linux/sfp.h       |  6 ++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 3a86c41e1235..fb1c102714b5 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -859,3 +859,14 @@ void sfp_unregister_socket(struct sfp_bus *bus)
 	sfp_bus_put(bus);
 }
 EXPORT_SYMBOL_GPL(sfp_unregister_socket);
+
+const char *sfp_get_name(struct sfp_bus *bus)
+{
+	ASSERT_RTNL();
+
+	if (bus->sfp_dev)
+		return dev_name(bus->sfp_dev);
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(sfp_get_name);
diff --git a/include/linux/sfp.h b/include/linux/sfp.h
index 0573e53b0c11..55c0ab17c9e2 100644
--- a/include/linux/sfp.h
+++ b/include/linux/sfp.h
@@ -570,6 +570,7 @@ struct sfp_bus *sfp_bus_find_fwnode(const struct fwnode_handle *fwnode);
 int sfp_bus_add_upstream(struct sfp_bus *bus, void *upstream,
 			 const struct sfp_upstream_ops *ops);
 void sfp_bus_del_upstream(struct sfp_bus *bus);
+const char *sfp_get_name(struct sfp_bus *bus);
 #else
 static inline int sfp_parse_port(struct sfp_bus *bus,
 				 const struct sfp_eeprom_id *id,
@@ -648,6 +649,11 @@ static inline int sfp_bus_add_upstream(struct sfp_bus *bus, void *upstream,
 static inline void sfp_bus_del_upstream(struct sfp_bus *bus)
 {
 }
+
+static inline const char *sfp_get_name(struct sfp_bus *bus)
+{
+	return NULL;
+}
 #endif
 
 #endif
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:39 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:39 +0100
Subject: [PATCH net-next v5 06/13] netlink: specs: add phy-index as a header parameter
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-7-maxime.chevallier@bootlin.com>

Update the spec to take the newly introduced phy-index as a generic
request parameter.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
V5: Added Andrew's R-b
V4: Ditch the ethtool-user generated code
V3: New patch

 Documentation/netlink/specs/ethtool.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 197208f419dc..bb6e1dc6d1c5 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -30,6 +30,9 @@ attribute-sets:
       -
         name: flags
         type: u32
+      -
+        name: phy-index
+        type: u32
 
   -
     name: bitset-bit
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:33 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:33 +0100
Subject: [PATCH net-next v5 00/13] Introduce PHY listing and link_topology tracking
Message-ID: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>

Hello everyone,

Here's a V5 of the multi-PHY support series.

At a glance, besides some minor fixes and R'd-by from Andrew, one of the
thing this series does is remove the ASSERT_RTNL() from the
topo_add_phy/del_phy operations.

These operations will take a PHY device and put it into the list of
devices associated to a netdevice. The main thing to protect here is the
list itself, but since we use xarrays, my naive understanding of it is
that it contains its own protection scheme. There shouldn't be a need
for more locking, as the insertion/deletion paths are already hooked
into the PHY connection to a netdev, or disconnection from it.

Now for the rest of the cover :

As a remainder, this ongoing work aims ultimately at supporting complex
link topologies that involve multiplexing multiple PHYs/SFPs on a single
netdevice. As a first step, it's required that we are able to enumerate the
PHYs on a given ethernet interface.

By just doing so, we also improve already-existing use-cases, namely the
copper SFP modules support when a media-converter is used (as we have 2
PHYs on the link, but only one is referenced by net_device.phydev, which
is used on a variety of netlink commands).

The series is architectured as follows :

- The first patch adds the notion of phy_link_topology, which tracks
all PHYs attached to a netdevice.

- Patches 2, 3 and 4 adds some plumbing into SFP and phylib to be able
  to connect the dots when building the topology tree, to know which PHY
  is connected to which SFP bus, trying not to be too invasive on phylib.

- Patch 5 allows passing a PHY_INDEX to ethnl commands. I'm uncertain about
  this, as there are at least 4 netlink commands ( 5 with the one introduced
  in patch 7 ) that targets PHYs directly or indirectly, which to me makes
  it worth-it to have a generic way to pass a PHY index to commands, however
  the approach taken may be too generic.

- Patch 6 is the netlink spec update + ethtool-user.c|h autogenerated code
update (the autogenerated code triggers checkpatch warning though)

- Patch 7 introduces a new netlink command set to list PHYs on a netdevice.
It implements a custom DUMP and GET operation to allow filtered dumps,
that lists all PHYs on a given netdevice. I couldn't use most of ethnl's
plumbing though.

- Patch 8 is the netlink spec update + ethtool-user.c|h update for that
new command

- Patch 8,9,10 and 11 updates the PLCA, strset, cable-test and pse netlink
commands to use the user-provided PHY instead of net_device.phydev.

- Finally patch 12 adds some documentation for this whole work.

Examples
========

Here's a short overview of the kind of operations you can have regarding
the PHY topology. These tests were performed on a MacchiatoBin, which
has 3 interfaces :

eth0 and eth1 have the following layout:

MAC - PHY - SFP

eth2 has this more classic topology :

MAC - PHY - RJ45

finally eth3 has the following topology :

MAC - SFP

When performing a dump with all interfaces down, we don't get any
result, as no PHY has been attached to their respective net_device :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get
None

The following output is with eth0, eth2 and eth3 up, but no SFP module
inserted in none of the interfaces :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get
[{'downstream-sfp-name': 'sfp-eth0',
  'drvname': 'mv88x3310',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 0,
  'index': 1,
  'name': 'f212a600.mdio-mii:00',
  'upstream-type': 'mac'},
 {'drvname': 'Marvell 88E1510',
  'header': {'dev-index': 4, 'dev-name': 'eth2'},
  'id': 21040593,
  'index': 1,
  'name': 'f212a200.mdio-mii:00',
  'upstream-type': 'mac'}]


And now is a dump operation with a copper SFP in the eth0 port :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get
[{'downstream-sfp-name': 'sfp-eth0',
  'drvname': 'mv88x3310',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 0,
  'index': 1,
  'name': 'f212a600.mdio-mii:00',
  'upstream-type': 'mac'},
 {'drvname': 'Marvell 88E1111',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 21040322,
  'index': 2,
  'name': 'i2c:sfp-eth0:16',
  'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'},
  'upstream-type': 'phy'},
 {'drvname': 'Marvell 88E1510',
  'header': {'dev-index': 4, 'dev-name': 'eth2'},
  'id': 21040593,
  'index': 1,
  'name': 'f212a200.mdio-mii:00',
  'upstream-type': 'mac'}]

 -- Note that this shouldn't actually work as the 88x3310 PHY doesn't allow
a 1G SFP to be connected to its SFP interface, and I don't have a 10G copper SFP,
so for the sake of the demo I applied the following modification, which
of courses gives a non-functionnal link, but the PHY attach still works,
which is what I want to demonstrate :

@@ -488,7 +488,7 @@ static int mv3310_sfp_insert(void *upstream, const struct sfp_eeprom_id *id)

        if (iface != PHY_INTERFACE_MODE_10GBASER) {
                dev_err(&phydev->mdio.dev, "incompatible SFP module inserted\n");
-               return -EINVAL;
+               //return -EINVAL;
        }
        return 0;
 }

Finally an example of the filtered DUMP operation that Jakub suggested
in V1 :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml \
# --dump phy-get --json '{"header" : {"dev-name" : "eth0"}}'

[{'downstream-sfp-name': 'sfp-eth0',
  'drvname': 'mv88x3310',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 0,
  'index': 1,
  'name': 'f212a600.mdio-mii:00',
  'upstream-type': 'mac'},
 {'drvname': 'Marvell 88E1111',
  'header': {'dev-index': 2, 'dev-name': 'eth0'},
  'id': 21040322,
  'index': 2,
  'name': 'i2c:sfp-eth0:16',
  'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'},
  'upstream-type': 'phy'}]

And a classic GET operation allows querying a single PHY's info :

# ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml \
# --do phy-get --json '{"header" : {"dev-name" : "eth0", "phy-index" : 2}}'

{'drvname': 'Marvell 88E1111',
 'header': {'dev-index': 2, 'dev-name': 'eth0'},
 'id': 21040322,
 'index': 2,
 'name': 'i2c:sfp-eth0:16',
 'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'},
 'upstream-type': 'phy'}

Changed in V5:
- Removed the RTNL assertion in the topology ops
- Made the phy_topo_get_phy inline
- Fixed the PSE-PD multi-PHY support by re-adding a wrongly dropped
  check
- Fixed some typos in the documentation
- Fixed reverse xmas trees

Changes in V4:
- Dropped the RFC flag
- Made the net_device integration independent to having phylib enabled
- Removed the autogenerated ethtool-user code for the YNL specs

Changes in V3:
- Added RTNL assertions where needed
- Fixed issues in the DUMP code for PHY_GET, which crashed when running it
  twice in a row
- Added the documentation, and moved in-source docs around
- renamed link_topology to phy_link_topology

Changes in V2:
- Added the DUMP operation
- Added much more information in the reported data, to be able to reconstruct
  precisely the topology tree
- renamed phy_list to link_topology

Maxime Chevallier (13):
  net: phy: Introduce ethernet link topology representation
  net: sfp: pass the phy_device when disconnecting an sfp module's PHY
  net: phy: add helpers to handle sfp phy connect/disconnect
  net: sfp: Add helper to return the SFP bus name
  net: ethtool: Allow passing a phy index for some commands
  netlink: specs: add phy-index as a header parameter
  net: ethtool: Introduce a command to list PHYs on an interface
  netlink: specs: add ethnl PHY_GET command set
  net: ethtool: plca: Target the command to the requested PHY
  net: ethtool: pse-pd: Target the command to the requested PHY
  net: ethtool: cable-test: Target the command to the requested PHY
  net: ethtool: strset: Allow querying phy stats by index
  Documentation: networking: document phy_link_topology

 Documentation/netlink/specs/ethtool.yaml      |  68 ++++
 Documentation/networking/ethtool-netlink.rst  |  51 +++
 Documentation/networking/index.rst            |   1 +
 .../networking/phy-link-topology.rst          | 121 +++++++
 MAINTAINERS                                   |   2 +
 drivers/net/phy/Makefile                      |   2 +-
 drivers/net/phy/at803x.c                      |   2 +
 drivers/net/phy/marvell-88x2222.c             |   2 +
 drivers/net/phy/marvell.c                     |   2 +
 drivers/net/phy/marvell10g.c                  |   2 +
 drivers/net/phy/phy_device.c                  |  55 ++++
 drivers/net/phy/phy_link_topology.c           |  66 ++++
 drivers/net/phy/phylink.c                     |   3 +-
 drivers/net/phy/sfp-bus.c                     |  15 +-
 include/linux/netdevice.h                     |   4 +-
 include/linux/phy.h                           |   6 +
 include/linux/phy_link_topology.h             |  67 ++++
 include/linux/phy_link_topology_core.h        |  19 ++
 include/linux/sfp.h                           |   8 +-
 include/uapi/linux/ethtool.h                  |  16 +
 include/uapi/linux/ethtool_netlink.h          |  30 ++
 net/core/dev.c                                |   3 +
 net/ethtool/Makefile                          |   2 +-
 net/ethtool/cabletest.c                       |  12 +-
 net/ethtool/netlink.c                         |  33 ++
 net/ethtool/netlink.h                         |  12 +-
 net/ethtool/phy.c                             | 306 ++++++++++++++++++
 net/ethtool/plca.c                            |  13 +-
 net/ethtool/pse-pd.c                          |   9 +-
 net/ethtool/strset.c                          |  15 +-
 30 files changed, 912 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/networking/phy-link-topology.rst
 create mode 100644 drivers/net/phy/phy_link_topology.c
 create mode 100644 include/linux/phy_link_topology.h
 create mode 100644 include/linux/phy_link_topology_core.h
 create mode 100644 net/ethtool/phy.c

-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:42 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:42 +0100
Subject: [PATCH net-next v5 09/13] net: ethtool: plca: Target the command to the requested PHY
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-10-maxime.chevallier@bootlin.com>

PLCA is a PHY-specific command. Instead of targeting the command
towards dev->phydev, use the request to pick the targeted PHY.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
V5: Added Andrew's R-b
V4: No changes
V3: No changes
V2: New patch

 net/ethtool/plca.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/net/ethtool/plca.c b/net/ethtool/plca.c
index b1e2e3b5027f..2b3e419f4dc2 100644
--- a/net/ethtool/plca.c
+++ b/net/ethtool/plca.c
@@ -61,7 +61,7 @@ static int plca_get_cfg_prepare_data(const struct ethnl_req_info *req_base,
 	int ret;
 
 	// check that the PHY device is available and connected
-	if (!dev->phydev) {
+	if (!req_base->phydev) {
 		ret = -EOPNOTSUPP;
 		goto out;
 	}
@@ -80,7 +80,7 @@ static int plca_get_cfg_prepare_data(const struct ethnl_req_info *req_base,
 	memset(&data->plca_cfg, 0xff,
 	       sizeof_field(struct plca_reply_data, plca_cfg));
 
-	ret = ops->get_plca_cfg(dev->phydev, &data->plca_cfg);
+	ret = ops->get_plca_cfg(req_base->phydev, &data->plca_cfg);
 	ethnl_ops_complete(dev);
 
 out:
@@ -141,7 +141,6 @@ const struct nla_policy ethnl_plca_set_cfg_policy[] = {
 static int
 ethnl_set_plca(struct ethnl_req_info *req_info, struct genl_info *info)
 {
-	struct net_device *dev = req_info->dev;
 	const struct ethtool_phy_ops *ops;
 	struct nlattr **tb = info->attrs;
 	struct phy_plca_cfg plca_cfg;
@@ -149,7 +148,7 @@ ethnl_set_plca(struct ethnl_req_info *req_info, struct genl_info *info)
 	int ret;
 
 	// check that the PHY device is available and connected
-	if (!dev->phydev)
+	if (!req_info->phydev)
 		return -EOPNOTSUPP;
 
 	ops = ethtool_phy_ops;
@@ -168,7 +167,7 @@ ethnl_set_plca(struct ethnl_req_info *req_info, struct genl_info *info)
 	if (!mod)
 		return 0;
 
-	ret = ops->set_plca_cfg(dev->phydev, &plca_cfg, info->extack);
+	ret = ops->set_plca_cfg(req_info->phydev, &plca_cfg, info->extack);
 	return ret < 0 ? ret : 1;
 }
 
@@ -204,7 +203,7 @@ static int plca_get_status_prepare_data(const struct ethnl_req_info *req_base,
 	int ret;
 
 	// check that the PHY device is available and connected
-	if (!dev->phydev) {
+	if (!req_base->phydev) {
 		ret = -EOPNOTSUPP;
 		goto out;
 	}
@@ -223,7 +222,7 @@ static int plca_get_status_prepare_data(const struct ethnl_req_info *req_base,
 	memset(&data->plca_st, 0xff,
 	       sizeof_field(struct plca_reply_data, plca_st));
 
-	ret = ops->get_plca_status(dev->phydev, &data->plca_st);
+	ret = ops->get_plca_status(req_base->phydev, &data->plca_st);
 	ethnl_ops_complete(dev);
 out:
 	return ret;
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:34 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:34 +0100
Subject: [PATCH net-next v5 01/13] net: phy: Introduce ethernet link topology representation
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-2-maxime.chevallier@bootlin.com>

Link topologies containing multiple network PHYs attached to the same
net_device can be found when using a PHY as a media converter for use
with an SFP connector, on which an SFP transceiver containing a PHY can
be used.

With the current model, the transceiver's PHY can't be used for
operations such as cable testing, timestamping, macsec offload, etc.

The reason being that most of the logic for these configuration, coming
from either ethtool netlink or ioctls tend to use netdev->phydev, which
in multi-phy systems will reference the PHY closest to the MAC.

Introduce a numbering scheme allowing to enumerate PHY devices that
belong to any netdev, which can in turn allow userspace to take more
precise decisions with regard to each PHY's configuration.

The numbering is maintained per-netdev, in a phy_device_list.
The numbering works similarly to a netdevice's ifindex, with
identifiers that are only recycled once INT_MAX has been reached.

This prevents races that could occur between PHY listing and SFP
transceiver removal/insertion.

The identifiers are assigned at phy_attach time, as the numbering
depends on the netdevice the phy is attached to.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V5: - Dropped the ASSERT_RTNL()
    - Made the phy_link_topo_get_phy inline
V4: - Moved the phy_link_topo_init() code to an inline header function
    - Made the code build without phylib

V3: - Renamed to phy_link_topology
    - Added assertions for RTNL
    - Various cleanups of leftover, unused test code
    - Made the PHY index u32

 MAINTAINERS                            |  2 +
 drivers/net/phy/Makefile               |  2 +-
 drivers/net/phy/phy_device.c           |  7 +++
 drivers/net/phy/phy_link_topology.c    | 66 +++++++++++++++++++++++++
 include/linux/netdevice.h              |  4 +-
 include/linux/phy.h                    |  4 ++
 include/linux/phy_link_topology.h      | 67 ++++++++++++++++++++++++++
 include/linux/phy_link_topology_core.h | 19 ++++++++
 include/uapi/linux/ethtool.h           | 16 ++++++
 net/core/dev.c                         |  3 ++
 10 files changed, 188 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/phy/phy_link_topology.c
 create mode 100644 include/linux/phy_link_topology.h
 create mode 100644 include/linux/phy_link_topology_core.h

diff --git a/MAINTAINERS b/MAINTAINERS
index dda78b4ce707..f09b1d4e5487 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7873,6 +7873,8 @@ F:	include/linux/mii.h
 F:	include/linux/of_net.h
 F:	include/linux/phy.h
 F:	include/linux/phy_fixed.h
+F:	include/linux/phy_link_topology.h
+F:	include/linux/phy_link_topology_core.h
 F:	include/linux/phylib_stubs.h
 F:	include/linux/platform_data/mdio-bcm-unimac.h
 F:	include/linux/platform_data/mdio-gpio.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e35ea69d9cb4..a7a9640bfa3a 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -2,7 +2,7 @@
 # Makefile for Linux PHY drivers
 
 libphy-y			:= phy.o phy-c45.o phy-core.o phy_device.o \
-				   linkmode.o
+				   linkmode.o phy_link_topology.o
 mdio-bus-y			+= mdio_bus.o mdio_device.o
 
 ifdef CONFIG_MDIO_DEVICE
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0c52a9eff188..d7c0812bd107 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -29,6 +29,7 @@
 #include <linux/phy.h>
 #include <linux/phylib_stubs.h>
 #include <linux/phy_led_triggers.h>
+#include <linux/phy_link_topology.h>
 #include <linux/pse-pd/pse.h>
 #include <linux/property.h>
 #include <linux/rtnetlink.h>
@@ -1491,6 +1492,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
 
 		if (phydev->sfp_bus_attached)
 			dev->sfp_bus = phydev->sfp_bus;
+
+		err = phy_link_topo_add_phy(&dev->link_topo, phydev,
+					    PHY_UPSTREAM_MAC, dev);
+		if (err)
+			goto error;
 	}
 
 	/* Some Ethernet drivers try to connect to a PHY device before
@@ -1819,6 +1825,7 @@ void phy_detach(struct phy_device *phydev)
 	if (dev) {
 		phydev->attached_dev->phydev = NULL;
 		phydev->attached_dev = NULL;
+		phy_link_topo_del_phy(&dev->link_topo, phydev);
 	}
 	phydev->phylink = NULL;
 
diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c
new file mode 100644
index 000000000000..34e7e08fbfc3
--- /dev/null
+++ b/drivers/net/phy/phy_link_topology.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Infrastructure to handle all PHY devices connected to a given netdev,
+ * either directly or indirectly attached.
+ *
+ * Copyright (c) 2023 Maxime Chevallier<maxime.chevallier at bootlin.com>
+ */
+
+#include <linux/phy_link_topology.h>
+#include <linux/netdevice.h>
+#include <linux/phy.h>
+#include <linux/rtnetlink.h>
+#include <linux/xarray.h>
+
+int phy_link_topo_add_phy(struct phy_link_topology *topo,
+			  struct phy_device *phy,
+			  enum phy_upstream upt, void *upstream)
+{
+	struct phy_device_node *pdn;
+	int ret;
+
+	pdn = kzalloc(sizeof(*pdn), GFP_KERNEL);
+	if (!pdn)
+		return -ENOMEM;
+
+	pdn->phy = phy;
+	switch (upt) {
+	case PHY_UPSTREAM_MAC:
+		pdn->upstream.netdev = (struct net_device *)upstream;
+		if (phy_on_sfp(phy))
+			pdn->parent_sfp_bus = pdn->upstream.netdev->sfp_bus;
+		break;
+	case PHY_UPSTREAM_PHY:
+		pdn->upstream.phydev = (struct phy_device *)upstream;
+		if (phy_on_sfp(phy))
+			pdn->parent_sfp_bus = pdn->upstream.phydev->sfp_bus;
+		break;
+	default:
+		ret = -EINVAL;
+		goto err;
+	}
+	pdn->upstream_type = upt;
+
+	ret = xa_alloc_cyclic(&topo->phys, &phy->phyindex, pdn, xa_limit_32b,
+			      &topo->next_phy_index, GFP_KERNEL);
+	if (ret)
+		goto err;
+
+	return 0;
+
+err:
+	kfree(pdn);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_add_phy);
+
+void phy_link_topo_del_phy(struct phy_link_topology *topo,
+			   struct phy_device *phy)
+{
+	struct phy_device_node *pdn = xa_erase(&topo->phys, phy->phyindex);
+
+	phy->phyindex = 0;
+
+	kfree(pdn);
+}
+EXPORT_SYMBOL_GPL(phy_link_topo_del_phy);
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 75c7725e5e4f..5baa5517f533 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -40,7 +40,6 @@
 #include <net/dcbnl.h>
 #endif
 #include <net/netprio_cgroup.h>
-
 #include <linux/netdev_features.h>
 #include <linux/neighbour.h>
 #include <uapi/linux/netdevice.h>
@@ -52,6 +51,7 @@
 #include <net/net_trackers.h>
 #include <net/net_debug.h>
 #include <net/dropreason-core.h>
+#include <linux/phy_link_topology_core.h>
 
 struct netpoll_info;
 struct device;
@@ -2047,6 +2047,7 @@ enum netdev_stat_type {
  *	@fcoe_ddp_xid:	Max exchange id for FCoE LRO by ddp
  *
  *	@priomap:	XXX: need comments on this one
+ *	@link_topo:	Physical link topology tracking attached PHYs
  *	@phydev:	Physical device may attach itself
  *			for hardware timestamping
  *	@sfp_bus:	attached &struct sfp_bus structure.
@@ -2441,6 +2442,7 @@ struct net_device {
 #if IS_ENABLED(CONFIG_CGROUP_NET_PRIO)
 	struct netprio_map __rcu *priomap;
 #endif
+	struct phy_link_topology	link_topo;
 	struct phy_device	*phydev;
 	struct sfp_bus		*sfp_bus;
 	struct lock_class_key	*qdisc_tx_busylock;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index e9e85d347587..9f21eb380475 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -544,6 +544,9 @@ struct macsec_ops;
  * @drv: Pointer to the driver for this PHY instance
  * @devlink: Create a link between phy dev and mac dev, if the external phy
  *           used by current mac interface is managed by another mac interface.
+ * @phyindex: Unique id across the phy's parent tree of phys to address the PHY
+ *	      from userspace, similar to ifindex. A zero index means the PHY
+ *	      wasn't assigned an id yet.
  * @phy_id: UID for this device found during discovery
  * @c45_ids: 802.3-c45 Device Identifiers if is_c45.
  * @is_c45:  Set to true if this PHY uses clause 45 addressing.
@@ -643,6 +646,7 @@ struct phy_device {
 
 	struct device_link *devlink;
 
+	u32 phyindex;
 	u32 phy_id;
 
 	struct phy_c45_device_ids c45_ids;
diff --git a/include/linux/phy_link_topology.h b/include/linux/phy_link_topology.h
new file mode 100644
index 000000000000..91902263ec0e
--- /dev/null
+++ b/include/linux/phy_link_topology.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * PHY device list allow maintaining a list of PHY devices that are
+ * part of a netdevice's link topology. PHYs can for example be chained,
+ * as is the case when using a PHY that exposes an SFP module, on which an
+ * SFP transceiver that embeds a PHY is connected.
+ *
+ * This list can then be used by userspace to leverage individual PHY
+ * capabilities.
+ */
+#ifndef __PHY_LINK_TOPOLOGY_H
+#define __PHY_LINK_TOPOLOGY_H
+
+#include <linux/ethtool.h>
+#include <linux/phy_link_topology_core.h>
+
+struct xarray;
+struct phy_device;
+struct net_device;
+struct sfp_bus;
+
+struct phy_device_node {
+	enum phy_upstream upstream_type;
+
+	union {
+		struct net_device	*netdev;
+		struct phy_device	*phydev;
+	} upstream;
+
+	struct sfp_bus *parent_sfp_bus;
+
+	struct phy_device *phy;
+};
+
+static inline struct phy_device *
+phy_link_topo_get_phy(struct phy_link_topology *topo, u32 phyindex)
+{
+	struct phy_device_node *pdn = xa_load(&topo->phys, phyindex);
+
+	if (pdn)
+		return pdn->phy;
+
+	return NULL;
+}
+
+#if IS_ENABLED(CONFIG_PHYLIB)
+int phy_link_topo_add_phy(struct phy_link_topology *topo,
+			  struct phy_device *phy,
+			  enum phy_upstream upt, void *upstream);
+
+void phy_link_topo_del_phy(struct phy_link_topology *lt, struct phy_device *phy);
+
+#else
+static inline int phy_link_topo_add_phy(struct phy_link_topology *topo,
+					struct phy_device *phy,
+					enum phy_upstream upt, void *upstream)
+{
+	return 0;
+}
+
+static inline void phy_link_topo_del_phy(struct phy_link_topology *topo,
+					 struct phy_device *phy)
+{
+}
+#endif
+
+#endif /* __PHY_LINK_TOPOLOGY_H */
diff --git a/include/linux/phy_link_topology_core.h b/include/linux/phy_link_topology_core.h
new file mode 100644
index 000000000000..78c75f909489
--- /dev/null
+++ b/include/linux/phy_link_topology_core.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PHY_LINK_TOPOLOGY_CORE_H
+#define __PHY_LINK_TOPOLOGY_CORE_H
+
+struct xarray;
+
+struct phy_link_topology {
+	struct xarray phys;
+
+	u32 next_phy_index;
+};
+
+static inline void phy_link_topo_init(struct phy_link_topology *topo)
+{
+	xa_init_flags(&topo->phys, XA_FLAGS_ALLOC1);
+	topo->next_phy_index = 1;
+}
+
+#endif /* __PHY_LINK_TOPOLOGY_CORE_H */
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 0787d561ace0..9cff798c6df9 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -2216,4 +2216,20 @@ struct ethtool_link_settings {
 	 * __u32 map_lp_advertising[link_mode_masks_nwords];
 	 */
 };
+
+/**
+ * enum phy_upstream - Represents the upstream component a given PHY device
+ * is connected to, as in what is on the other end of the MII bus. Most PHYs
+ * will be attached to an Ethernet MAC controller, but in some cases, there's
+ * an intermediate PHY used as a media-converter, which will driver another
+ * MII interface as its output.
+ * @PHY_UPSTREAM_MAC: Upstream component is a MAC (a switch port,
+ *		      or ethernet controller)
+ * @PHY_UPSTREAM_PHY: Upstream component is a PHY (likely a media converter)
+ */
+enum phy_upstream {
+	PHY_UPSTREAM_MAC,
+	PHY_UPSTREAM_PHY,
+};
+
 #endif /* _UAPI_LINUX_ETHTOOL_H */
diff --git a/net/core/dev.c b/net/core/dev.c
index b87504078320..476acd22956c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -153,6 +153,7 @@
 #include <linux/prandom.h>
 #include <linux/once_lite.h>
 #include <net/netdev_rx_queue.h>
+#include <linux/phy_link_topology_core.h>
 
 #include "dev.h"
 #include "net-sysfs.h"
@@ -10872,6 +10873,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
 #ifdef CONFIG_NET_SCHED
 	hash_init(dev->qdisc_hash);
 #endif
+	phy_link_topo_init(&dev->link_topo);
+
 	dev->priv_flags = IFF_XMIT_DST_RELEASE | IFF_XMIT_DST_RELEASE_PERM;
 	setup(dev);
 
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:43 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:43 +0100
Subject: [PATCH net-next v5 10/13] net: ethtool: pse-pd: Target the command to the requested PHY
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-11-maxime.chevallier@bootlin.com>

PSE and PD configuration is a PHY-specific command. Instead of targeting
the command towards dev->phydev, use the request to pick the targeted
PHY device.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V5: Added-back an incorrectly removed check
V4: No changes
V3: No changes
V2: New patch

 net/ethtool/pse-pd.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index cc478af77111..4a1c8d37bd3d 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -31,12 +31,10 @@ const struct nla_policy ethnl_pse_get_policy[ETHTOOL_A_PSE_HEADER + 1] = {
 	[ETHTOOL_A_PSE_HEADER] = NLA_POLICY_NESTED(ethnl_header_policy),
 };
 
-static int pse_get_pse_attributes(struct net_device *dev,
+static int pse_get_pse_attributes(struct phy_device *phydev,
 				  struct netlink_ext_ack *extack,
 				  struct pse_reply_data *data)
 {
-	struct phy_device *phydev = dev->phydev;
-
 	if (!phydev) {
 		NL_SET_ERR_MSG(extack, "No PHY is attached");
 		return -EOPNOTSUPP;
@@ -64,7 +62,7 @@ static int pse_prepare_data(const struct ethnl_req_info *req_base,
 	if (ret < 0)
 		return ret;
 
-	ret = pse_get_pse_attributes(dev, info->extack, data);
+	ret = pse_get_pse_attributes(req_base->phydev, info->extack, data);
 
 	ethnl_ops_complete(dev);
 
@@ -124,7 +122,6 @@ ethnl_set_pse_validate(struct ethnl_req_info *req_info, struct genl_info *info)
 static int
 ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 {
-	struct net_device *dev = req_info->dev;
 	struct pse_control_config config = {};
 	struct nlattr **tb = info->attrs;
 	struct phy_device *phydev;
@@ -132,7 +129,7 @@ ethnl_set_pse(struct ethnl_req_info *req_info, struct genl_info *info)
 	/* this values are already validated by the ethnl_pse_set_policy */
 	config.admin_cotrol = nla_get_u32(tb[ETHTOOL_A_PODL_PSE_ADMIN_CONTROL]);
 
-	phydev = dev->phydev;
+	phydev = req_info->phydev;
 	if (!phydev) {
 		NL_SET_ERR_MSG(info->extack, "No PHY is attached");
 		return -EOPNOTSUPP;
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:46 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:46 +0100
Subject: [PATCH net-next v5 13/13] Documentation: networking: document phy_link_topology
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-14-maxime.chevallier@bootlin.com>

The newly introduced phy_link_topology tracks all ethernet PHYs that are
attached to a netdevice. Document the base principle, internal and
external APIs. As the phy_link_topology is expected to be extended, this
documentation will hold any further improvements and additions made
relative to topology handling.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V5: Fixed a lot of typos
V4: No changes
V3: New patch

 Documentation/networking/index.rst            |   1 +
 .../networking/phy-link-topology.rst          | 121 ++++++++++++++++++
 2 files changed, 122 insertions(+)
 create mode 100644 Documentation/networking/phy-link-topology.rst

diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 69f3d6dcd9fd..a2c45a75a4a6 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -88,6 +88,7 @@ Contents:
    operstates
    packet_mmap
    phonet
+   phy-link-topology
    pktgen
    plip
    ppp_generic
diff --git a/Documentation/networking/phy-link-topology.rst b/Documentation/networking/phy-link-topology.rst
new file mode 100644
index 000000000000..1fd8e904ef4b
--- /dev/null
+++ b/Documentation/networking/phy-link-topology.rst
@@ -0,0 +1,121 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+PHY link topology
+=================
+
+Overview
+========
+
+The PHY link topology representation in the networking stack aims at representing
+the hardware layout for any given Ethernet link.
+
+An Ethernet Interface from userspace's point of view is nothing but a
+:c:type:`struct net_device <net_device>`, which exposes configuration options
+through the legacy ioctls and the ethool netlink commands. The base assumption
+when designing these configuration channels were that the link looked
+something like this ::
+
+  +-----------------------+        +----------+      +--------------+
+  | Ethernet Controller / |        | Ethernet |      | Connector /  |
+  |       MAC             | ------ |   PHY    | ---- |    Port      | ---... to LP
+  +-----------------------+        +----------+      +--------------+
+  struct net_device               struct phy_device
+
+Commands that needs to configure the PHY will go through the net_device.phydev
+field to reach the PHY and perform the relevant configuration.
+
+This assumption falls apart in more complex topologies that can arise when,
+for example, using SFP transceivers (although that's not the only specific case).
+
+Here, we have 2 basic scenarios. Either the MAC is able to output a serialized
+interface, that can directly be fed to an SFP cage, such as SGMII, 1000BaseX,
+10GBaseR, etc.
+
+The link topology then looks like this (when an SFP module is inserted) ::
+
+  +-----+  SGMII  +------------+
+  | MAC | ------- | SFP Module |
+  +-----+         +------------+
+
+Knowing that some modules embed a PHY, the actual link is more like ::
+
+  +-----+  SGMII   +--------------+
+  | MAC | -------- | PHY (on SFP) |
+  +-----+          +--------------+
+
+In this case, the SFP PHY is handled by phylib, and registered by phylink through
+its SFP upstream ops.
+
+Now some Ethernet controllers aren't able to output a serialized interface, so
+we can't directly connect them to an SFP cage. However, some PHYs can be used
+as media-converters, to translate the non-serialized MAC MII interface to a
+serialized MII interface fed to the SFP ::
+
+  +-----+  RGMII  +-----------------------+  SGMII  +--------------+
+  | MAC | ------- | PHY (media converter) | ------- | PHY (on SFP) |
+  +-----+         +-----------------------+         +--------------+
+
+This is where the model of having a single net_device.phydev pointer shows its
+limitations, as we now have 2 PHYs on the link.
+
+The phy_link topology framework aims at providing a way to keep track of every
+PHY on the link, for use by both kernel drivers and subsystems, but also to
+report the topology to userspace, allowing to target individual PHYs in configuration
+commands.
+
+API
+===
+
+The :c:type:`struct phy_link_topology <phy_link_topology>` is a per-netdevice
+resource, that gets initialized at netdevice creation. Once it's initialized,
+it is then possible to register PHYs to the topology through :
+
+:c:func:`phy_link_topo_add_phy`
+
+Besides registering the PHY to the topology, this call will also assign a unique
+index to the PHY, which can then be reported to userspace to refer to this PHY
+(akin to the ifindex). This index is a u32, ranging from 1 to U32_MAX. The value
+0 is reserved to indicate the PHY doesn't belong to any topology yet.
+
+The PHY can then be removed from the topology through
+
+:c:func:`phy_link_topo_del_phy`
+
+These function are already hooked into the phylib subsystem, so all PHYs that
+are linked to a net_device through :c:func:`phy_attach_direct` will automatically
+join the netdev's topology.
+
+PHYs that are on a SFP module will also be automatically registered IF the SFP
+upstream is phylink (so, no media-converter).
+
+PHY drivers that can be used as SFP upstream need to call :c:func:`phy_sfp_attach_phy`
+and :c:func:`phy_sfp_detach_phy`, which can be used as a
+.attach_phy / .detach_phy implementation for the
+:c:type:`struct sfp_upstream_ops <sfp_upstream_ops>`.
+
+UAPI
+====
+
+There exist a set of netlink commands to query the link topology from userspace,
+see ``Documentation/networking/ethtool-netlink.rst``.
+
+The whole point of having a topology representation is to assign the phyindex
+field in :c:type:`struct phy_device <phy_device>`. This index is reported to
+userspace using the ``ETHTOOL_MSG_PHY_GET`` ethtnl command. Performing a DUMP operation
+will result in all PHYs from all net_device being listed. The DUMP command
+accepts either a ``ETHTOOL_A_HEADER_DEV_INDEX`` or ``ETHTOOL_A_HEADER_DEV_NAME``
+to be passed in the request to filter the DUMP to a single net_device.
+
+The retrieved index can then be passed as a request parameter using the
+``ETHTOOL_A_HEADER_PHY_INDEX`` field in the following ethnl commands :
+
+* ``ETHTOOL_MSG_STRSET_GET`` to get the stats string set from a given PHY
+* ``ETHTOOL_MSG_CABLE_TEST_ACT`` and ``ETHTOOL_MSG_CABLE_TEST_ACT``, to perform
+  cable testing on a given PHY on the link (most likely the outermost PHY)
+* ``ETHTOOL_MSG_PSE_SET`` and ``ETHTOOL_MSG_PSE_GET`` for PHY-controlled PoE and PSE settings
+* ``ETHTOOL_MSG_PLCA_GET_CFG``, ``ETHTOOL_MSG_PLCA_SET_CFG`` and ``ETHTOOL_MSG_PLCA_GET_STATUS``
+  to set the PLCA (Physical Layer Collision Avoidance) parameters
+
+Note that the PHY index can be passed to other requests, which will silently
+ignore it if present and irrelevant.
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:35 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:35 +0100
Subject: [PATCH net-next v5 02/13] net: sfp: pass the phy_device when disconnecting an sfp module's PHY
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-3-maxime.chevallier@bootlin.com>

Pass the phy_device as a parameter to the sfp upstream .disconnect_phy
operation. This is preparatory work to help track phy devices across
a net_device's link.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V5: No changes
V4: No changes
V3: No changes

 drivers/net/phy/phy_device.c | 8 ++++++++
 drivers/net/phy/phylink.c    | 3 ++-
 drivers/net/phy/sfp-bus.c    | 4 ++--
 include/linux/sfp.h          | 2 +-
 4 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index d7c0812bd107..aad78e3f7894 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -266,6 +266,14 @@ static void phy_mdio_device_remove(struct mdio_device *mdiodev)
 
 static struct phy_driver genphy_driver;
 
+static struct phy_link_topology *phy_get_link_topology(struct phy_device *phydev)
+{
+	if (phydev->attached_dev)
+		return &phydev->attached_dev->link_topo;
+
+	return NULL;
+}
+
 static LIST_HEAD(phy_fixup_list);
 static DEFINE_MUTEX(phy_fixup_lock);
 
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 298dfd6982a5..3d25a4a6212b 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -3319,7 +3319,8 @@ static int phylink_sfp_connect_phy(void *upstream, struct phy_device *phy)
 	return ret;
 }
 
-static void phylink_sfp_disconnect_phy(void *upstream)
+static void phylink_sfp_disconnect_phy(void *upstream,
+				       struct phy_device *phydev)
 {
 	phylink_disconnect_phy(upstream);
 }
diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 6fa679b36290..3a86c41e1235 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -486,7 +486,7 @@ static void sfp_unregister_bus(struct sfp_bus *bus)
 			bus->socket_ops->stop(bus->sfp);
 		bus->socket_ops->detach(bus->sfp);
 		if (bus->phydev && ops && ops->disconnect_phy)
-			ops->disconnect_phy(bus->upstream);
+			ops->disconnect_phy(bus->upstream, bus->phydev);
 	}
 	bus->registered = false;
 }
@@ -742,7 +742,7 @@ void sfp_remove_phy(struct sfp_bus *bus)
 	const struct sfp_upstream_ops *ops = sfp_get_upstream_ops(bus);
 
 	if (ops && ops->disconnect_phy)
-		ops->disconnect_phy(bus->upstream);
+		ops->disconnect_phy(bus->upstream, bus->phydev);
 	bus->phydev = NULL;
 }
 EXPORT_SYMBOL_GPL(sfp_remove_phy);
diff --git a/include/linux/sfp.h b/include/linux/sfp.h
index 9346cd44814d..0573e53b0c11 100644
--- a/include/linux/sfp.h
+++ b/include/linux/sfp.h
@@ -544,7 +544,7 @@ struct sfp_upstream_ops {
 	void (*link_down)(void *priv);
 	void (*link_up)(void *priv);
 	int (*connect_phy)(void *priv, struct phy_device *);
-	void (*disconnect_phy)(void *priv);
+	void (*disconnect_phy)(void *priv, struct phy_device *);
 };
 
 #if IS_ENABLED(CONFIG_SFP)
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:36 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:36 +0100
Subject: [PATCH net-next v5 03/13] net: phy: add helpers to handle sfp phy connect/disconnect
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-4-maxime.chevallier@bootlin.com>

There are a few PHY drivers that can handle SFP modules through their
sfp_upstream_ops. Introduce Phylib helpers to keep track of connected
SFP PHYs in a netdevice's namespace, by adding the SFP PHY to the
upstream PHY's netdev's namespace.

By doing so, these SFP PHYs can be enumerated and exposed to users,
which will be able to use their capabilities.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V5: No Changes
V4: Rebased the at803x part with the newer version on net-next
V3: Renaming
V2: Renaming

 drivers/net/phy/at803x.c          |  2 ++
 drivers/net/phy/marvell-88x2222.c |  2 ++
 drivers/net/phy/marvell.c         |  2 ++
 drivers/net/phy/marvell10g.c      |  2 ++
 drivers/net/phy/phy_device.c      | 40 +++++++++++++++++++++++++++++++
 include/linux/phy.h               |  2 ++
 6 files changed, 50 insertions(+)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index d5dc927618ab..1a62f868ec40 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -1452,6 +1452,8 @@ static const struct sfp_upstream_ops at8031_sfp_ops = {
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
 	.module_insert = at8031_sfp_insert,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 };
 
 static int at8031_parse_dt(struct phy_device *phydev)
diff --git a/drivers/net/phy/marvell-88x2222.c b/drivers/net/phy/marvell-88x2222.c
index e3aa30dad2e6..3f77bbc7e04f 100644
--- a/drivers/net/phy/marvell-88x2222.c
+++ b/drivers/net/phy/marvell-88x2222.c
@@ -555,6 +555,8 @@ static const struct sfp_upstream_ops sfp_phy_ops = {
 	.link_down = mv2222_sfp_link_down,
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 };
 
 static int mv2222_probe(struct phy_device *phydev)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index eba652a4c1d8..674e29bce2cc 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -3254,6 +3254,8 @@ static const struct sfp_upstream_ops m88e1510_sfp_ops = {
 	.module_remove = m88e1510_sfp_remove,
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 };
 
 static int m88e1510_probe(struct phy_device *phydev)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index ad43e280930c..6642eb642d4b 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -503,6 +503,8 @@ static int mv3310_sfp_insert(void *upstream, const struct sfp_eeprom_id *id)
 static const struct sfp_upstream_ops mv3310_sfp_ops = {
 	.attach = phy_sfp_attach,
 	.detach = phy_sfp_detach,
+	.connect_phy = phy_sfp_connect_phy,
+	.disconnect_phy = phy_sfp_disconnect_phy,
 	.module_insert = mv3310_sfp_insert,
 };
 
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index aad78e3f7894..6a7a05802bc6 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1363,6 +1363,46 @@ phy_standalone_show(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RO(phy_standalone);
 
+/**
+ * phy_sfp_connect_phy - Connect the SFP module's PHY to the upstream PHY
+ * @upstream: pointer to the upstream phy device
+ * @phy: pointer to the SFP module's phy device
+ *
+ * This helper allows keeping track of PHY devices on the link. It adds the
+ * SFP module's phy to the phy namespace of the upstream phy
+ */
+int phy_sfp_connect_phy(void *upstream, struct phy_device *phy)
+{
+	struct phy_device *phydev = upstream;
+	struct phy_link_topology *topo = phy_get_link_topology(phydev);
+
+	if (topo)
+		return phy_link_topo_add_phy(topo, phy, PHY_UPSTREAM_PHY, phydev);
+
+	return 0;
+}
+EXPORT_SYMBOL(phy_sfp_connect_phy);
+
+/**
+ * phy_sfp_disconnect_phy - Disconnect the SFP module's PHY from the upstream PHY
+ * @upstream: pointer to the upstream phy device
+ * @phy: pointer to the SFP module's phy device
+ *
+ * This helper allows keeping track of PHY devices on the link. It removes the
+ * SFP module's phy to the phy namespace of the upstream phy. As the module phy
+ * will be destroyed, re-inserting the same module will add a new phy with a
+ * new index.
+ */
+void phy_sfp_disconnect_phy(void *upstream, struct phy_device *phy)
+{
+	struct phy_device *phydev = upstream;
+	struct phy_link_topology *topo = phy_get_link_topology(phydev);
+
+	if (topo)
+		phy_link_topo_del_phy(topo, phy);
+}
+EXPORT_SYMBOL(phy_sfp_disconnect_phy);
+
 /**
  * phy_sfp_attach - attach the SFP bus to the PHY upstream network device
  * @upstream: pointer to the phy device
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 9f21eb380475..6cb9d843aee9 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1726,6 +1726,8 @@ int phy_suspend(struct phy_device *phydev);
 int phy_resume(struct phy_device *phydev);
 int __phy_resume(struct phy_device *phydev);
 int phy_loopback(struct phy_device *phydev, bool enable);
+int phy_sfp_connect_phy(void *upstream, struct phy_device *phy);
+void phy_sfp_disconnect_phy(void *upstream, struct phy_device *phy);
 void phy_sfp_attach(void *upstream, struct sfp_bus *bus);
 void phy_sfp_detach(void *upstream, struct sfp_bus *bus);
 int phy_sfp_probe(struct phy_device *phydev,
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:41 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:41 +0100
Subject: [PATCH net-next v5 08/13] netlink: specs: add ethnl PHY_GET command set
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-9-maxime.chevallier@bootlin.com>

The PHY_GET command, supporting both DUMP and GET operations, is used to
retrieve the list of PHYs connected to a netdevice, and get topology
information to know where exactly it sits on the physical link.

Add the netlink specs corresponding to that command.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V5: No changes
V4: Remove the ethtool-user generated code
V3: New patch

 Documentation/netlink/specs/ethtool.yaml | 65 ++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index bb6e1dc6d1c5..7f6fb1f61dd4 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -16,6 +16,11 @@ definitions:
     name: stringset
     type: enum
     entries: []
+  -
+    name: phy-upstream-type
+    enum-name:
+    type: enum
+    entries: [ mac, phy ]
 
 attribute-sets:
   -
@@ -945,6 +950,45 @@ attribute-sets:
       -
         name: burst-tmr
         type: u32
+  -
+    name: phy-upstream
+    attributes:
+      -
+        name: index
+        type: u32
+      -
+        name: sfp-name
+        type: string
+  -
+    name: phy
+    attributes:
+      -
+        name: header
+        type: nest
+        nested-attributes: header
+      -
+        name: index
+        type: u32
+      -
+        name: drvname
+        type: string
+      -
+        name: name
+        type: string
+      -
+        name: upstream-type
+        type: u8
+        enum: phy-upstream-type
+      -
+        name: upstream
+        type: nest
+        nested-attributes: phy-upstream
+      -
+        name: downstream-sfp-name
+        type: string
+      -
+        name: id
+        type: u32
 
 operations:
   enum-model: directional
@@ -1696,3 +1740,24 @@ operations:
       name: mm-ntf
       doc: Notification for change in MAC Merge configuration.
       notify: mm-get
+    -
+      name: phy-get
+      doc: Get PHY devices attached to an interface
+
+      attribute-set: phy
+
+      do: &phy-get-op
+        request:
+          attributes:
+            - header
+        reply:
+          attributes:
+            - header
+            - index
+            - drvname
+            - name
+            - upstream-type
+            - upstream
+            - downstream-sfp-name
+            - id
+      dump: *phy-get-op
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:38 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:38 +0100
Subject: [PATCH net-next v5 05/13] net: ethtool: Allow passing a phy index for some commands
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-6-maxime.chevallier@bootlin.com>

Some netlink commands are target towards ethernet PHYs, to control some
of their features. As there's several such commands, add the ability to
pass a PHY index in the ethnl request, which will populate the generic
ethnl_req_info with the relevant phydev when the command targets a PHY.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
V5: - Added Andrew's R-b
    - Fix a typo reported by Simon
V4: - No Changes
V3: - Fixed the documentation
V2: - New patch

 Documentation/networking/ethtool-netlink.rst |  7 ++++++
 include/uapi/linux/ethtool_netlink.h         |  1 +
 net/ethtool/netlink.c                        | 24 ++++++++++++++++++++
 net/ethtool/netlink.h                        |  7 ++++--
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index d583d9abf2f8..3ca6c21e74af 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst
@@ -57,6 +57,7 @@ Structure of this header is
   ``ETHTOOL_A_HEADER_DEV_INDEX``  u32     device ifindex
   ``ETHTOOL_A_HEADER_DEV_NAME``   string  device name
   ``ETHTOOL_A_HEADER_FLAGS``      u32     flags common for all requests
+  ``ETHTOOL_A_HEADER_PHY_INDEX``  u32     phy device index
   ==============================  ======  =============================
 
 ``ETHTOOL_A_HEADER_DEV_INDEX`` and ``ETHTOOL_A_HEADER_DEV_NAME`` identify the
@@ -81,6 +82,12 @@ the behaviour is backward compatible, i.e. requests from old clients not aware
 of the flag should be interpreted the way the client expects. A client must
 not set flags it does not understand.
 
+``ETHTOOL_A_HEADER_PHY_INDEX`` identify the ethernet PHY the message relates to.
+As there are numerous commands that are related to PHY configuration, and because
+we can have more than one PHY on the link, the PHY index can be passed in the
+request for the commands that needs it. It is however not mandatory, and if it
+is not passed for commands that target a PHY, the net_device.phydev pointer
+is used, as a fallback that keeps the legacy behaviour.
 
 Bit sets
 ========
diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h
index 3f89074aa06c..422e8cfdd98c 100644
--- a/include/uapi/linux/ethtool_netlink.h
+++ b/include/uapi/linux/ethtool_netlink.h
@@ -133,6 +133,7 @@ enum {
 	ETHTOOL_A_HEADER_DEV_INDEX,		/* u32 */
 	ETHTOOL_A_HEADER_DEV_NAME,		/* string */
 	ETHTOOL_A_HEADER_FLAGS,			/* u32 - ETHTOOL_FLAG_* */
+	ETHTOOL_A_HEADER_PHY_INDEX,		/* u32 */
 
 	/* add new constants above here */
 	__ETHTOOL_A_HEADER_CNT,
diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
index fe3553f60bf3..1c26766ce996 100644
--- a/net/ethtool/netlink.c
+++ b/net/ethtool/netlink.c
@@ -4,6 +4,7 @@
 #include <linux/ethtool_netlink.h>
 #include <linux/pm_runtime.h>
 #include "netlink.h"
+#include <linux/phy_link_topology.h>
 
 static struct genl_family ethtool_genl_family;
 
@@ -20,6 +21,7 @@ const struct nla_policy ethnl_header_policy[] = {
 					    .len = ALTIFNAMSIZ - 1 },
 	[ETHTOOL_A_HEADER_FLAGS]	= NLA_POLICY_MASK(NLA_U32,
 							  ETHTOOL_FLAGS_BASIC),
+	[ETHTOOL_A_HEADER_PHY_INDEX]		= NLA_POLICY_MIN(NLA_U32, 1),
 };
 
 const struct nla_policy ethnl_header_policy_stats[] = {
@@ -28,6 +30,7 @@ const struct nla_policy ethnl_header_policy_stats[] = {
 					    .len = ALTIFNAMSIZ - 1 },
 	[ETHTOOL_A_HEADER_FLAGS]	= NLA_POLICY_MASK(NLA_U32,
 							  ETHTOOL_FLAGS_STATS),
+	[ETHTOOL_A_HEADER_PHY_INDEX]		= NLA_POLICY_MIN(NLA_U32, 1),
 };
 
 int ethnl_ops_begin(struct net_device *dev)
@@ -91,6 +94,7 @@ int ethnl_parse_header_dev_get(struct ethnl_req_info *req_info,
 {
 	struct nlattr *tb[ARRAY_SIZE(ethnl_header_policy)];
 	const struct nlattr *devname_attr;
+	struct phy_device *phydev = NULL;
 	struct net_device *dev = NULL;
 	u32 flags = 0;
 	int ret;
@@ -145,6 +149,26 @@ int ethnl_parse_header_dev_get(struct ethnl_req_info *req_info,
 		return -EINVAL;
 	}
 
+	if (dev) {
+		if (tb[ETHTOOL_A_HEADER_PHY_INDEX]) {
+			u32 phy_index = nla_get_u32(tb[ETHTOOL_A_HEADER_PHY_INDEX]);
+
+			phydev = phy_link_topo_get_phy(&dev->link_topo,
+						       phy_index);
+			if (!phydev) {
+				NL_SET_ERR_MSG_ATTR(extack, header,
+						    "no phy matches phy index");
+				return -EINVAL;
+			}
+		} else {
+			/* If we need a PHY but no phy index is specified, fallback
+			 * to dev->phydev
+			 */
+			phydev = dev->phydev;
+		}
+	}
+
+	req_info->phydev = phydev;
 	req_info->dev = dev;
 	req_info->flags = flags;
 	return 0;
diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h
index 9a333a8d04c1..def84e2def9e 100644
--- a/net/ethtool/netlink.h
+++ b/net/ethtool/netlink.h
@@ -250,6 +250,7 @@ static inline unsigned int ethnl_reply_header_size(void)
  * @dev:   network device the request is for (may be null)
  * @dev_tracker: refcount tracker for @dev reference
  * @flags: request flags common for all request types
+ * @phydev: phy_device connected to @dev this request is for (may be null)
  *
  * This is a common base for request specific structures holding data from
  * parsed userspace request. These always embed struct ethnl_req_info at
@@ -259,6 +260,7 @@ struct ethnl_req_info {
 	struct net_device	*dev;
 	netdevice_tracker	dev_tracker;
 	u32			flags;
+	struct phy_device	*phydev;
 };
 
 static inline void ethnl_parse_header_dev_put(struct ethnl_req_info *req_info)
@@ -395,9 +397,10 @@ extern const struct ethnl_request_ops ethnl_rss_request_ops;
 extern const struct ethnl_request_ops ethnl_plca_cfg_request_ops;
 extern const struct ethnl_request_ops ethnl_plca_status_request_ops;
 extern const struct ethnl_request_ops ethnl_mm_request_ops;
+extern const struct ethnl_request_ops ethnl_phy_request_ops;
 
-extern const struct nla_policy ethnl_header_policy[ETHTOOL_A_HEADER_FLAGS + 1];
-extern const struct nla_policy ethnl_header_policy_stats[ETHTOOL_A_HEADER_FLAGS + 1];
+extern const struct nla_policy ethnl_header_policy[ETHTOOL_A_HEADER_PHY_INDEX + 1];
+extern const struct nla_policy ethnl_header_policy_stats[ETHTOOL_A_HEADER_PHY_INDEX + 1];
 extern const struct nla_policy ethnl_strset_get_policy[ETHTOOL_A_STRSET_COUNTS_ONLY + 1];
 extern const struct nla_policy ethnl_linkinfo_get_policy[ETHTOOL_A_LINKINFO_HEADER + 1];
 extern const struct nla_policy ethnl_linkinfo_set_policy[ETHTOOL_A_LINKINFO_TP_MDIX_CTRL + 1];
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:40 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:40 +0100
Subject: [PATCH net-next v5 07/13] net: ethtool: Introduce a command to list PHYs on an interface
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-8-maxime.chevallier@bootlin.com>

As we have the ability to track the PHYs connected to a net_device
through the link_topology, we can expose this list to userspace. This
allows userspace to use these identifiers for phy-specific commands and
take the decision of which PHY to target by knowing the link topology.

Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list
devices on only one interface.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
---
V5: - Fixed xmas tree
    - Fixed uninitialized return variable (Simon)
V4: - Fixed errors when not having SFP enabled, resulting in null names
      being passed as parameters to strlen.
V3: - Fixed the documentation
    - Fixed the DUMP implementation
V2: New patch

 Documentation/networking/ethtool-netlink.rst |  44 +++
 include/uapi/linux/ethtool_netlink.h         |  29 ++
 net/ethtool/Makefile                         |   2 +-
 net/ethtool/netlink.c                        |   9 +
 net/ethtool/netlink.h                        |   5 +
 net/ethtool/phy.c                            | 306 +++++++++++++++++++
 6 files changed, 394 insertions(+), 1 deletion(-)
 create mode 100644 net/ethtool/phy.c

diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index 3ca6c21e74af..97ff787a7dd8 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst
@@ -2011,6 +2011,49 @@ The attributes are propagated to the driver through the following structure:
 .. kernel-doc:: include/linux/ethtool.h
     :identifiers: ethtool_mm_cfg
 
+PHY_GET
+=======
+
+Retrieve information about a given Ethernet PHY sitting on the link. As there
+can be more than one PHY, the DUMP operation can be used to list the PHYs
+present on a given interface, by passing an interface index or name in
+the dump request
+
+Request contents:
+
+  ====================================  ======  ==========================
+  ``ETHTOOL_A_PHY_HEADER``              nested  request header
+  ====================================  ======  ==========================
+
+Kernel response contents:
+
+  ===================================== ======  ==========================
+  ``ETHTOOL_A_PHY_HEADER``              nested  request header
+  ``ETHTOOL_A_PHY_INDEX``               u32     the phy's unique index, that can
+                                                be used for phy-specific requests
+  ``ETHTOOL_A_PHY_DRVNAME``             string  the phy driver name
+  ``ETHTOOL_A_PHY_NAME``                string  the phy device name
+  ``ETHTOOL_A_PHY_UPSTREAM_TYPE``       u32     the type of device this phy is
+                                                connected to
+  ``ETHTOOL_A_PHY_UPSTREAM_PHY``        nested  if the phy is connected to another
+                                                phy, this nest contains info on
+                                                that connection
+  ``ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME`` string  if the phy controls an sfp bus,
+                                                the name of the sfp bus
+  ``ETHTOOL_A_PHY_ID``                  u32     the phy id if the phy is C22
+  ===================================== ======  ==========================
+
+When ``ETHTOOL_A_PHY_UPSTREAM_TYPE`` is PHY_UPSTREAM_PHY, the PHY's parent is
+another PHY. Information on the parent PHY will be set in the
+``ETHTOOL_A_PHY_UPSTREAM_PHY`` nest, which has the following structure :
+
+  =================================== ======  ==========================
+  ``ETHTOOL_A_PHY_UPSTREAM_INDEX``    u32     the PHY index of the upstream PHY
+  ``ETHTOOL_A_PHY_UPSTREAM_SFP_NAME`` string  if this PHY is connected to it's
+                                                parent PHY through an SFP bus, the
+                                                name of this sfp bus
+  =================================== ======  ==========================
+
 Request translation
 ===================
 
@@ -2117,4 +2160,5 @@ are netlink only.
   n/a                                 ``ETHTOOL_MSG_PLCA_GET_STATUS``
   n/a                                 ``ETHTOOL_MSG_MM_GET``
   n/a                                 ``ETHTOOL_MSG_MM_SET``
+  n/a                                 ``ETHTOOL_MSG_PHY_GET``
   =================================== =====================================
diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h
index 422e8cfdd98c..00cd7ad16709 100644
--- a/include/uapi/linux/ethtool_netlink.h
+++ b/include/uapi/linux/ethtool_netlink.h
@@ -57,6 +57,7 @@ enum {
 	ETHTOOL_MSG_PLCA_GET_STATUS,
 	ETHTOOL_MSG_MM_GET,
 	ETHTOOL_MSG_MM_SET,
+	ETHTOOL_MSG_PHY_GET,
 
 	/* add new constants above here */
 	__ETHTOOL_MSG_USER_CNT,
@@ -109,6 +110,8 @@ enum {
 	ETHTOOL_MSG_PLCA_NTF,
 	ETHTOOL_MSG_MM_GET_REPLY,
 	ETHTOOL_MSG_MM_NTF,
+	ETHTOOL_MSG_PHY_GET_REPLY,
+	ETHTOOL_MSG_PHY_NTF,
 
 	/* add new constants above here */
 	__ETHTOOL_MSG_KERNEL_CNT,
@@ -977,6 +980,32 @@ enum {
 	ETHTOOL_A_MM_MAX = (__ETHTOOL_A_MM_CNT - 1)
 };
 
+enum {
+	ETHTOOL_A_PHY_UPSTREAM_UNSPEC,
+	ETHTOOL_A_PHY_UPSTREAM_INDEX,			/* u32 */
+	ETHTOOL_A_PHY_UPSTREAM_SFP_NAME,		/* string */
+
+	/* add new constants above here */
+	__ETHTOOL_A_PHY_UPSTREAM_CNT,
+	ETHTOOL_A_PHY_UPSTREAM_MAX = (__ETHTOOL_A_PHY_UPSTREAM_CNT - 1)
+};
+
+enum {
+	ETHTOOL_A_PHY_UNSPEC,
+	ETHTOOL_A_PHY_HEADER,			/* nest - _A_HEADER_* */
+	ETHTOOL_A_PHY_INDEX,			/* u32 */
+	ETHTOOL_A_PHY_DRVNAME,			/* string */
+	ETHTOOL_A_PHY_NAME,			/* string */
+	ETHTOOL_A_PHY_UPSTREAM_TYPE,		/* u8 */
+	ETHTOOL_A_PHY_UPSTREAM,			/* nest - _A_PHY_UPSTREAM_* */
+	ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME,	/* string */
+	ETHTOOL_A_PHY_ID,			/* u32 */
+
+	/* add new constants above here */
+	__ETHTOOL_A_PHY_CNT,
+	ETHTOOL_A_PHY_MAX = (__ETHTOOL_A_PHY_CNT - 1)
+};
+
 /* generic netlink info */
 #define ETHTOOL_GENL_NAME "ethtool"
 #define ETHTOOL_GENL_VERSION 1
diff --git a/net/ethtool/Makefile b/net/ethtool/Makefile
index 504f954a1b28..0ccd0e9afd3f 100644
--- a/net/ethtool/Makefile
+++ b/net/ethtool/Makefile
@@ -8,4 +8,4 @@ ethtool_nl-y	:= netlink.o bitset.o strset.o linkinfo.o linkmodes.o rss.o \
 		   linkstate.o debug.o wol.o features.o privflags.o rings.o \
 		   channels.o coalesce.o pause.o eee.o tsinfo.o cabletest.o \
 		   tunnels.o fec.o eeprom.o stats.o phc_vclocks.o mm.o \
-		   module.o pse-pd.o plca.o mm.o
+		   module.o pse-pd.o plca.o mm.o phy.o
diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
index 1c26766ce996..92b0dd8ca046 100644
--- a/net/ethtool/netlink.c
+++ b/net/ethtool/netlink.c
@@ -1153,6 +1153,15 @@ static const struct genl_ops ethtool_genl_ops[] = {
 		.policy = ethnl_mm_set_policy,
 		.maxattr = ARRAY_SIZE(ethnl_mm_set_policy) - 1,
 	},
+	{
+		.cmd	= ETHTOOL_MSG_PHY_GET,
+		.doit	= ethnl_phy_doit,
+		.start	= ethnl_phy_start,
+		.dumpit	= ethnl_phy_dumpit,
+		.done	= ethnl_phy_done,
+		.policy = ethnl_phy_get_policy,
+		.maxattr = ARRAY_SIZE(ethnl_phy_get_policy) - 1,
+	},
 };
 
 static const struct genl_multicast_group ethtool_nl_mcgrps[] = {
diff --git a/net/ethtool/netlink.h b/net/ethtool/netlink.h
index def84e2def9e..5e6a43e35a09 100644
--- a/net/ethtool/netlink.h
+++ b/net/ethtool/netlink.h
@@ -444,6 +444,7 @@ extern const struct nla_policy ethnl_plca_set_cfg_policy[ETHTOOL_A_PLCA_MAX + 1]
 extern const struct nla_policy ethnl_plca_get_status_policy[ETHTOOL_A_PLCA_HEADER + 1];
 extern const struct nla_policy ethnl_mm_get_policy[ETHTOOL_A_MM_HEADER + 1];
 extern const struct nla_policy ethnl_mm_set_policy[ETHTOOL_A_MM_MAX + 1];
+extern const struct nla_policy ethnl_phy_get_policy[ETHTOOL_A_PHY_HEADER + 1];
 
 int ethnl_set_features(struct sk_buff *skb, struct genl_info *info);
 int ethnl_act_cable_test(struct sk_buff *skb, struct genl_info *info);
@@ -451,6 +452,10 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct genl_info *info);
 int ethnl_tunnel_info_doit(struct sk_buff *skb, struct genl_info *info);
 int ethnl_tunnel_info_start(struct netlink_callback *cb);
 int ethnl_tunnel_info_dumpit(struct sk_buff *skb, struct netlink_callback *cb);
+int ethnl_phy_start(struct netlink_callback *cb);
+int ethnl_phy_doit(struct sk_buff *skb, struct genl_info *info);
+int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb);
+int ethnl_phy_done(struct netlink_callback *cb);
 
 extern const char stats_std_names[__ETHTOOL_STATS_CNT][ETH_GSTRING_LEN];
 extern const char stats_eth_phy_names[__ETHTOOL_A_STATS_ETH_PHY_CNT][ETH_GSTRING_LEN];
diff --git a/net/ethtool/phy.c b/net/ethtool/phy.c
new file mode 100644
index 000000000000..5add2840aaeb
--- /dev/null
+++ b/net/ethtool/phy.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2023 Bootlin
+ *
+ */
+#include "common.h"
+#include "netlink.h"
+
+#include <linux/phy.h>
+#include <linux/phy_link_topology.h>
+#include <linux/sfp.h>
+
+struct phy_req_info {
+	struct ethnl_req_info		base;
+	struct phy_device_node		pdn;
+};
+
+#define PHY_REQINFO(__req_base) \
+	container_of(__req_base, struct phy_req_info, base)
+
+const struct nla_policy ethnl_phy_get_policy[ETHTOOL_A_PHY_HEADER + 1] = {
+	[ETHTOOL_A_PHY_HEADER] = NLA_POLICY_NESTED(ethnl_header_policy),
+};
+
+/* Caller holds rtnl */
+static ssize_t
+ethnl_phy_reply_size(const struct ethnl_req_info *req_base,
+		     struct netlink_ext_ack *extack)
+{
+	struct phy_link_topology *topo;
+	struct phy_device_node *pdn;
+	struct phy_device *phydev;
+	unsigned long index;
+	size_t size;
+
+	ASSERT_RTNL();
+
+	topo = &req_base->dev->link_topo;
+
+	size = nla_total_size(0);
+
+	xa_for_each(&topo->phys, index, pdn) {
+		phydev = pdn->phy;
+
+		/* ETHTOOL_A_PHY_INDEX */
+		size += nla_total_size(sizeof(u32));
+
+		/* ETHTOOL_A_DRVNAME */
+		size += nla_total_size(strlen(phydev->drv->name) + 1);
+
+		/* ETHTOOL_A_NAME */
+		size += nla_total_size(strlen(dev_name(&phydev->mdio.dev)) + 1);
+
+		/* ETHTOOL_A_PHY_UPSTREAM_TYPE */
+		size += nla_total_size(sizeof(u8));
+
+		/* ETHTOOL_A_PHY_ID */
+		size += nla_total_size(sizeof(u32));
+
+		if (phy_on_sfp(phydev)) {
+			const char *upstream_sfp_name = sfp_get_name(pdn->parent_sfp_bus);
+
+			/* ETHTOOL_A_PHY_UPSTREAM_SFP_NAME */
+			if (upstream_sfp_name)
+				size += nla_total_size(strlen(upstream_sfp_name) + 1);
+
+			/* ETHTOOL_A_PHY_UPSTREAM_INDEX */
+			size += nla_total_size(sizeof(u32));
+		}
+
+		/* ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME */
+		if (phydev->sfp_bus) {
+			const char *sfp_name = sfp_get_name(phydev->sfp_bus);
+
+			if (sfp_name)
+				size += nla_total_size(strlen(sfp_name) + 1);
+		}
+	}
+
+	return size;
+}
+
+static int
+ethnl_phy_fill_reply(const struct ethnl_req_info *req_base, struct sk_buff *skb)
+{
+	struct phy_req_info *req_info = PHY_REQINFO(req_base);
+	struct phy_device_node *pdn = &req_info->pdn;
+	struct phy_device *phydev = pdn->phy;
+	enum phy_upstream ptype;
+	struct nlattr *nest;
+
+	ptype = pdn->upstream_type;
+
+	if (nla_put_u32(skb, ETHTOOL_A_PHY_INDEX, phydev->phyindex) ||
+	    nla_put_string(skb, ETHTOOL_A_PHY_DRVNAME, phydev->drv->name) ||
+	    nla_put_string(skb, ETHTOOL_A_PHY_NAME, dev_name(&phydev->mdio.dev)) ||
+	    nla_put_u8(skb, ETHTOOL_A_PHY_UPSTREAM_TYPE, ptype) ||
+	    nla_put_u32(skb, ETHTOOL_A_PHY_ID, phydev->phy_id))
+		return -EMSGSIZE;
+
+	if (ptype == PHY_UPSTREAM_PHY) {
+		struct phy_device *upstream = pdn->upstream.phydev;
+		const char *sfp_upstream_name;
+
+		nest = nla_nest_start(skb, ETHTOOL_A_PHY_UPSTREAM);
+		if (!nest)
+			return -EMSGSIZE;
+
+		/* Parent index */
+		if (nla_put_u32(skb, ETHTOOL_A_PHY_UPSTREAM_INDEX, upstream->phyindex))
+			return -EMSGSIZE;
+
+		if (pdn->parent_sfp_bus) {
+			sfp_upstream_name = sfp_get_name(pdn->parent_sfp_bus);
+			if (sfp_upstream_name && nla_put_string(skb,
+								ETHTOOL_A_PHY_UPSTREAM_SFP_NAME,
+								sfp_upstream_name))
+				return -EMSGSIZE;
+		}
+
+		nla_nest_end(skb, nest);
+	}
+
+	if (phydev->sfp_bus) {
+		const char *sfp_name = sfp_get_name(phydev->sfp_bus);
+
+		if (sfp_name &&
+		    nla_put_string(skb, ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME,
+				   sfp_name))
+			return -EMSGSIZE;
+	}
+
+	return 0;
+}
+
+static int ethnl_phy_parse_request(struct ethnl_req_info *req_base,
+				   struct nlattr **tb)
+{
+	struct phy_link_topology *topo = &req_base->dev->link_topo;
+	struct phy_req_info *req_info = PHY_REQINFO(req_base);
+	struct phy_device_node *pdn;
+
+	if (!req_base->phydev)
+		return 0;
+
+	pdn = xa_load(&topo->phys, req_base->phydev->phyindex);
+	memcpy(&req_info->pdn, pdn, sizeof(*pdn));
+
+	return 0;
+}
+
+int ethnl_phy_doit(struct sk_buff *skb, struct genl_info *info)
+{
+	struct phy_req_info req_info = {};
+	struct nlattr **tb = info->attrs;
+	struct sk_buff *rskb;
+	void *reply_payload;
+	int reply_len;
+	int ret;
+
+	ret = ethnl_parse_header_dev_get(&req_info.base,
+					 tb[ETHTOOL_A_PHY_HEADER],
+					 genl_info_net(info), info->extack,
+					 true);
+	if (ret < 0)
+		return ret;
+
+	rtnl_lock();
+
+	ret = ethnl_phy_parse_request(&req_info.base, tb);
+	if (ret < 0)
+		goto err_unlock_rtnl;
+
+	/* No PHY, return early */
+	if (!req_info.pdn.phy)
+		goto err_unlock_rtnl;
+
+	ret = ethnl_phy_reply_size(&req_info.base, info->extack);
+	if (ret < 0)
+		goto err_unlock_rtnl;
+	reply_len = ret + ethnl_reply_header_size();
+
+	rskb = ethnl_reply_init(reply_len, req_info.base.dev,
+				ETHTOOL_MSG_PHY_GET_REPLY,
+				ETHTOOL_A_PHY_HEADER,
+				info, &reply_payload);
+	if (!rskb) {
+		ret = -ENOMEM;
+		goto err_unlock_rtnl;
+	}
+
+	ret = ethnl_phy_fill_reply(&req_info.base, rskb);
+	if (ret)
+		goto err_free_msg;
+
+	rtnl_unlock();
+	ethnl_parse_header_dev_put(&req_info.base);
+	genlmsg_end(rskb, reply_payload);
+
+	return genlmsg_reply(rskb, info);
+
+err_free_msg:
+	nlmsg_free(rskb);
+err_unlock_rtnl:
+	rtnl_unlock();
+	ethnl_parse_header_dev_put(&req_info.base);
+	return ret;
+}
+
+struct ethnl_phy_dump_ctx {
+	struct phy_req_info	*phy_req_info;
+};
+
+int ethnl_phy_start(struct netlink_callback *cb)
+{
+	const struct genl_dumpit_info *info = genl_dumpit_info(cb);
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+	struct nlattr **tb = info->info.attrs;
+	int ret;
+
+	BUILD_BUG_ON(sizeof(*ctx) > sizeof(cb->ctx));
+
+	ctx->phy_req_info = kzalloc(sizeof(*ctx->phy_req_info), GFP_KERNEL);
+	if (!ctx->phy_req_info)
+		return -ENOMEM;
+
+	ret = ethnl_parse_header_dev_get(&ctx->phy_req_info->base,
+					 tb[ETHTOOL_A_PHY_HEADER],
+					 sock_net(cb->skb->sk), cb->extack,
+					 false);
+	return ret;
+}
+
+int ethnl_phy_done(struct netlink_callback *cb)
+{
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+
+	kfree(ctx->phy_req_info);
+
+	return 0;
+}
+
+static int ethnl_phy_dump_one_dev(struct sk_buff *skb, struct net_device *dev,
+				  struct netlink_callback *cb)
+{
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+	struct phy_req_info *pri = ctx->phy_req_info;
+	struct phy_device_node *pdn;
+	unsigned long index = 1;
+	int ret = 0;
+	void *ehdr;
+
+	pri->base.dev = dev;
+
+	xa_for_each(&dev->link_topo.phys, index, pdn) {
+		ehdr = ethnl_dump_put(skb, cb,
+				      ETHTOOL_MSG_PHY_GET_REPLY);
+		if (!ehdr) {
+			ret = -EMSGSIZE;
+			break;
+		}
+
+		ret = ethnl_fill_reply_header(skb, dev,
+					      ETHTOOL_A_PHY_HEADER);
+		if (ret < 0) {
+			genlmsg_cancel(skb, ehdr);
+			break;
+		}
+
+		memcpy(&pri->pdn, pdn, sizeof(*pdn));
+		ret = ethnl_phy_fill_reply(&pri->base, skb);
+
+		genlmsg_end(skb, ehdr);
+	}
+
+	return ret;
+}
+
+int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
+{
+	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
+	struct net *net = sock_net(skb->sk);
+	unsigned long ifindex = 1;
+	struct net_device *dev;
+	int ret = 0;
+
+	rtnl_lock();
+
+	if (ctx->phy_req_info->base.dev) {
+		ret = ethnl_phy_dump_one_dev(skb, ctx->phy_req_info->base.dev, cb);
+		ethnl_parse_header_dev_put(&ctx->phy_req_info->base);
+		ctx->phy_req_info->base.dev = NULL;
+	} else {
+		for_each_netdev_dump(net, dev, ifindex) {
+			ret = ethnl_phy_dump_one_dev(skb, dev, cb);
+			if (ret)
+				break;
+		}
+	}
+	rtnl_unlock();
+
+	if (ret == -EMSGSIZE && skb->len)
+		return skb->len;
+	return ret;
+}
+
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:44 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:44 +0100
Subject: [PATCH net-next v5 11/13] net: ethtool: cable-test: Target the command to the requested PHY
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-12-maxime.chevallier@bootlin.com>

Cable testing is a PHY-specific command. Instead of targeting the command
towards dev->phydev, use the request to pick the targeted PHY.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
V5: Added Andrew's R-b
V4: No changes
V3: No changes
V2: New patch

 net/ethtool/cabletest.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/ethtool/cabletest.c b/net/ethtool/cabletest.c
index 06a151165c31..6b00d0800f23 100644
--- a/net/ethtool/cabletest.c
+++ b/net/ethtool/cabletest.c
@@ -69,7 +69,7 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct genl_info *info)
 		return ret;
 
 	dev = req_info.dev;
-	if (!dev->phydev) {
+	if (!req_info.phydev) {
 		ret = -EOPNOTSUPP;
 		goto out_dev_put;
 	}
@@ -85,12 +85,12 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct genl_info *info)
 	if (ret < 0)
 		goto out_rtnl;
 
-	ret = ops->start_cable_test(dev->phydev, info->extack);
+	ret = ops->start_cable_test(req_info.phydev, info->extack);
 
 	ethnl_ops_complete(dev);
 
 	if (!ret)
-		ethnl_cable_test_started(dev->phydev,
+		ethnl_cable_test_started(req_info.phydev,
 					 ETHTOOL_MSG_CABLE_TEST_NTF);
 
 out_rtnl:
@@ -321,7 +321,7 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct genl_info *info)
 		return ret;
 
 	dev = req_info.dev;
-	if (!dev->phydev) {
+	if (!req_info.phydev) {
 		ret = -EOPNOTSUPP;
 		goto out_dev_put;
 	}
@@ -342,12 +342,12 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct genl_info *info)
 	if (ret < 0)
 		goto out_rtnl;
 
-	ret = ops->start_cable_test_tdr(dev->phydev, info->extack, &cfg);
+	ret = ops->start_cable_test_tdr(req_info.phydev, info->extack, &cfg);
 
 	ethnl_ops_complete(dev);
 
 	if (!ret)
-		ethnl_cable_test_started(dev->phydev,
+		ethnl_cable_test_started(req_info.phydev,
 					 ETHTOOL_MSG_CABLE_TEST_TDR_NTF);
 
 out_rtnl:
-- 
2.43.0



From maxime.chevallier at bootlin.com  Thu Dec 21 10:00:45 2023
From: maxime.chevallier at bootlin.com (Maxime Chevallier)
Date: Thu, 21 Dec 2023 19:00:45 +0100
Subject: [PATCH net-next v5 12/13] net: ethtool: strset: Allow querying phy stats by index
In-Reply-To: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
Message-ID: <20231221180047.1924733-13-maxime.chevallier@bootlin.com>

The ETH_SS_PHY_STATS command gets PHY statistics. Use the phydev pointer
from the ethnl request to allow query phy stats from each PHY on the
link.

Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
V5: Added Andrew's R-b
V4: No changes
V3: No changes
V2: New patch

 net/ethtool/strset.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/net/ethtool/strset.c b/net/ethtool/strset.c
index c678b484a079..70c00631c51f 100644
--- a/net/ethtool/strset.c
+++ b/net/ethtool/strset.c
@@ -233,17 +233,18 @@ static void strset_cleanup_data(struct ethnl_reply_data *reply_base)
 }
 
 static int strset_prepare_set(struct strset_info *info, struct net_device *dev,
-			      unsigned int id, bool counts_only)
+			      struct phy_device *phydev, unsigned int id,
+			      bool counts_only)
 {
 	const struct ethtool_phy_ops *phy_ops = ethtool_phy_ops;
 	const struct ethtool_ops *ops = dev->ethtool_ops;
 	void *strings;
 	int count, ret;
 
-	if (id == ETH_SS_PHY_STATS && dev->phydev &&
+	if (id == ETH_SS_PHY_STATS && phydev &&
 	    !ops->get_ethtool_phy_stats && phy_ops &&
 	    phy_ops->get_sset_count)
-		ret = phy_ops->get_sset_count(dev->phydev);
+		ret = phy_ops->get_sset_count(phydev);
 	else if (ops->get_sset_count && ops->get_strings)
 		ret = ops->get_sset_count(dev, id);
 	else
@@ -258,10 +259,10 @@ static int strset_prepare_set(struct strset_info *info, struct net_device *dev,
 		strings = kcalloc(count, ETH_GSTRING_LEN, GFP_KERNEL);
 		if (!strings)
 			return -ENOMEM;
-		if (id == ETH_SS_PHY_STATS && dev->phydev &&
+		if (id == ETH_SS_PHY_STATS && phydev &&
 		    !ops->get_ethtool_phy_stats && phy_ops &&
 		    phy_ops->get_strings)
-			phy_ops->get_strings(dev->phydev, strings);
+			phy_ops->get_strings(phydev, strings);
 		else
 			ops->get_strings(dev, id, strings);
 		info->strings = strings;
@@ -305,8 +306,8 @@ static int strset_prepare_data(const struct ethnl_req_info *req_base,
 		    !data->sets[i].per_dev)
 			continue;
 
-		ret = strset_prepare_set(&data->sets[i], dev, i,
-					 req_info->counts_only);
+		ret = strset_prepare_set(&data->sets[i], dev, req_base->phydev,
+					 i, req_info->counts_only);
 		if (ret < 0)
 			goto err_ops;
 	}
-- 
2.43.0



From oliver.upton at linux.dev  Thu Dec 21 10:14:20 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Thu, 21 Dec 2023 18:14:20 +0000
Subject: [PATCH v4 02/10] KVM: arm64: Add ptdump registration with
 debugfs for the stage-2 pagetables
In-Reply-To: <20231218135859.2513568-4-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
 <20231218135859.2513568-4-sebastianene@google.com>
Message-ID: <ZYSAfORj2-cXo5t_@linux.dev>

On Mon, Dec 18, 2023 at 01:58:52PM +0000, Sebastian Ene wrote:
> +config PTDUMP_STAGE2_DEBUGFS
> +       bool "Present the stage-2 pagetables to debugfs"
> +       depends on PTDUMP_DEBUGFS && KVM
> +       default n
> +       help
> +         Say Y here if you want to show the stage-2 kernel pagetables
> +         layout in a debugfs file. This information is only useful for kernel developers
> +         who are working in architecture specific areas of the kernel.
> +         It is probably not a good idea to enable this feature in a production
> +         kernel.

It isn't really a good idea to mount debugfs at all in a production
system. There are already plenty worse interfaces lurking in that
filesystem. The pKVM portions already depend on CONFIG_NVHE_EL2_DEBUG,
so I don't see a need for this Kconfig option.

> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index e5f75f1f1..ee8d7cb67 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -40,6 +40,7 @@
>  #include <asm/kvm_pkvm.h>
>  #include <asm/kvm_emulate.h>
>  #include <asm/sections.h>
> +#include <kvm_ptdump.h>
>  
>  #include <kvm/arm_hypercalls.h>
>  #include <kvm/arm_pmu.h>
> @@ -2592,6 +2593,7 @@ static __init int kvm_arm_init(void)
>  	if (err)
>  		goto out_subs;
>  
> +	kvm_ptdump_register_host();
>  	kvm_arm_initialised = true;
>  
>  	return 0;
> diff --git a/arch/arm64/kvm/kvm_ptdump.h b/arch/arm64/kvm/kvm_ptdump.h
> new file mode 100644
> index 000000000..98b595ce8
> --- /dev/null
> +++ b/arch/arm64/kvm/kvm_ptdump.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +//
> +// Copyright (C) Google, 2023
> +// Author: Sebastian Ene <sebastianene at google.com>

You've got the comment styles backwards for these. The SPDX license uses
the 'C++' style comment (//), whereas your multiline comment should always
use a 'C' style comment (/* */).

> +struct kvm_ptdump_register {
> +	void *(*get_ptdump_info)(struct kvm_ptdump_register *reg);
> +	void (*put_ptdump_info)(void *priv);
> +	int (*show_ptdump_info)(struct seq_file *m, void *v);
> +	void *priv;
> +};

Please thoroughly consider the necessity of this. You're wrapping a
callback structure with yet another callback structure. IMO, it would
make a lot more sense to implement the file ops structure for every
walker variant you need and avoid the indirection, it's hard to
understand.

> +void kvm_ptdump_register_host(void)
> +{
> +	if (!is_protected_kvm_enabled())
> +		return;
> +
> +	kvm_ptdump_debugfs_register(&host_reg, "host_page_tables",
> +				    kvm_debugfs_dir);
> +}
> +
> +static int __init kvm_host_ptdump_init(void)
> +{
> +	host_reg.priv = (void *)host_s2_pgtable_pages();
> +	return 0;
> +}
> +
> +device_initcall(kvm_host_ptdump_init);

Why can't all of this be called from finalize_pkvm()?

> -- 
> 2.43.0.472.g3155946c3a-goog
> 

-- 
Thanks,
Oliver


From oliver.upton at linux.dev  Thu Dec 21 10:27:59 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Thu, 21 Dec 2023 18:27:59 +0000
Subject: [PATCH v4 10/10] arm64: ptdump: Add guest stage-2 pagetables
 dumping
In-Reply-To: <20231218135859.2513568-12-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
 <20231218135859.2513568-12-sebastianene@google.com>
Message-ID: <ZYSDr9uYi3cUk_Jt@linux.dev>

On Mon, Dec 18, 2023 at 01:59:00PM +0000, Sebastian Ene wrote:
> Register a debugfs file on guest creation to be able to view their
> second translation tables with ptdump. This assumes that the host is in
> control of the guest stage-2 and has direct access to the pagetables.
> 
> Signed-off-by: Sebastian Ene <sebastianene at google.com>

I couldn't see how this patched worked at all until I went back to patch
1 and found this:

> +static int kvm_ptdump_open(struct inode *inode, struct file *file)
> +{

[...]

> +	if (!reg->show_ptdump_info)
> +		reg->show_ptdump_info = kvm_ptdump_show;

[...]

> +}


> +static int kvm_ptdump_show(struct seq_file *m, void *)
> +{
> +	struct kvm *guest_kvm = m->private;
> +	struct kvm_s2_mmu *mmu = &guest_kvm->arch.mmu;
> +	int ret;
> +
> +	write_lock(&guest_kvm->mmu_lock);
> +	ret = kvm_ptdump_show_common(m, mmu->pgt);
> +	write_unlock(&guest_kvm->mmu_lock);
> +
> +	return ret;
> +}

Where are you getting a reference on the kvm struct? You need to do this
to ensure the VM doesn't get destroyed behind your back.

-- 
Thanks,
Oliver


From markhas at chromium.org  Thu Dec 21 10:29:47 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Thu, 21 Dec 2023 11:29:47 -0700
Subject: [PATCH v2 06/22] ARM: dts: samsung: exynos5420: Enable
 cros-ec-spi as wake source
In-Reply-To: <7199b7b7-238e-45de-96f1-0f04d0fa718d@linaro.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
 <20231220165423.v2.6.I06b059021de1bf6103e60a73211f078f2af75d17@changeid> <7199b7b7-238e-45de-96f1-0f04d0fa718d@linaro.org>
Message-ID: <CANg-bXD+TVHO3o6f66fJXQ7AtXxPY00TQqjvX2vwk9PyTd1ZaA@mail.gmail.com>

> You do not need this property, if driver assumes that. Just enable it
> unconditionally.

The goal of this patch series is to change exactly that: to prevent
the driver from unconditionally enabling the irq for wake.
The driver works across numerous buses (spi, uart, i2c, lpc) and
supports DT and ACPI.
SPI+DT systems all happen to need irq wake enabled.

> I don't think anything from previous discussion was
> resolved.

Which previous discussion do you mean? In v1 it was suggested to split
up the DTS changes by arch/soc and add a cover letter (which I did).
Wrt to the binding discussion, Sudeep said the new documentation
wording looked good to him [1].

[1]: https://lore.kernel.org/all/ZYAjxxHcCOgDVMTQ at bogus/


From oliver.upton at linux.dev  Thu Dec 21 10:36:28 2023
From: oliver.upton at linux.dev (Oliver Upton)
Date: Thu, 21 Dec 2023 18:36:28 +0000
Subject: [PATCH v4 00/10] arm64: ptdump: View the second stage page-tables
In-Reply-To: <20231218135859.2513568-2-sebastianene@google.com>
References: <20231218135859.2513568-2-sebastianene@google.com>
Message-ID: <ZYSFrFDHKo_ZTkxM@linux.dev>

Hi Sebastian,

I'm going to try and review the series a bit more after the holidays,
but in general this is unecessarily complex. Furthermore, building out
the feature for pKVM *first* rather than 'normal' VMs makes it all very
challenging to follow.

I would strongly prefer that this series be split in two, adding support
for 'normal' VMs with a follow-up series for getting the pKVM plumbing
in place for host stage-2.

-- 
Thanks,
Oliver


From krzysztof.kozlowski at linaro.org  Thu Dec 21 10:38:40 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 19:38:40 +0100
Subject: [PATCH v2 06/22] ARM: dts: samsung: exynos5420: Enable
 cros-ec-spi as wake source
In-Reply-To: <CANg-bXD+TVHO3o6f66fJXQ7AtXxPY00TQqjvX2vwk9PyTd1ZaA@mail.gmail.com>
References: <20231220235459.2965548-1-markhas@chromium.org>
 <20231220165423.v2.6.I06b059021de1bf6103e60a73211f078f2af75d17@changeid>
 <7199b7b7-238e-45de-96f1-0f04d0fa718d@linaro.org>
 <CANg-bXD+TVHO3o6f66fJXQ7AtXxPY00TQqjvX2vwk9PyTd1ZaA@mail.gmail.com>
Message-ID: <50dceec0-3a43-4363-8404-d701f726acc0@linaro.org>

On 21/12/2023 19:29, Mark Hasemeyer wrote:
>> You do not need this property, if driver assumes that. Just enable it
>> unconditionally.
> 
> The goal of this patch series is to change exactly that: to prevent
> the driver from unconditionally enabling the irq for wake.

But why? What is the problem being solved? Is unconditional wakeup in
the driver incorrect? If so, mention it shortly in the commit msg, what
is rationale because existing one does not justify this change.

> The driver works across numerous buses (spi, uart, i2c, lpc) and
> supports DT and ACPI.
> SPI+DT systems all happen to need irq wake enabled.
> 
>> I don't think anything from previous discussion was
>> resolved.
> 
> Which previous discussion do you mean? In v1 it was suggested to split

https://lore.kernel.org/all/20231213221124.GB2115075-robh at kernel.org/


Best regards,
Krzysztof



From sebastianene at google.com  Thu Dec 21 10:41:52 2023
From: sebastianene at google.com (Sebastian Ene)
Date: Thu, 21 Dec 2023 18:41:52 +0000
Subject: [PATCH v4 00/10] arm64: ptdump: View the second stage page-tables
In-Reply-To: <ZYSFrFDHKo_ZTkxM@linux.dev>
References: <20231218135859.2513568-2-sebastianene@google.com>
 <ZYSFrFDHKo_ZTkxM@linux.dev>
Message-ID: <ZYSG8JvOGy8Silz1@google.com>

On Thu, Dec 21, 2023 at 06:36:28PM +0000, Oliver Upton wrote:

Hello Oliver,

> Hi Sebastian,
> 
> I'm going to try and review the series a bit more after the holidays,
> but in general this is unecessarily complex. Furthermore, building out
> the feature for pKVM *first* rather than 'normal' VMs makes it all very
> challenging to follow.
> 

Thanks for having a look. This sounds good, I can split the series into
two afer the holidays and push a new version because I am really not
happy with my current state of the patches (especially because I
discovered some issues after I subimtted on the list).


> I would strongly prefer that this series be split in two, adding support
> for 'normal' VMs with a follow-up series for getting the pKVM plumbing
> in place for host stage-2.
> 
> -- 
> Thanks,
> Oliver

Thank you,
Seb


From quic_bjorande at quicinc.com  Thu Dec 21 10:48:11 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 10:48:11 -0800
Subject: [PATCH 6/8] arm64: dts: qcom: sa8295p-adp: add max20411
In-Reply-To: <b6866ee4-31d9-4404-9bd9-92bc4ab59b8c@linaro.org>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
 <20231220-sa8295p-gpu-v1-6-d8cdf2257f97@quicinc.com>
 <b6866ee4-31d9-4404-9bd9-92bc4ab59b8c@linaro.org>
Message-ID: <20231221184811.GR1766637@hu-bjorande-lv.qualcomm.com>

On Thu, Dec 21, 2023 at 01:51:58PM +0100, Konrad Dybcio wrote:
> On 21.12.2023 04:50, Bjorn Andersson wrote:
> > From: Bjorn Andersson <andersson at kernel.org>
> > 
> > The SA8295P ADP has a MAX20411 LDO regulator on I2C 12, supplying the
> > VDD_GFX pads. Enable the bus and add the maxim,max20411 device on the
> > bus.
> > 
> > Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
> > ---
> >  arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 40 ++++++++++++++++++++++++++++++++
> >  1 file changed, 40 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > index fd253942e5e5..e16406c9c19d 100644
> > --- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > +++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > @@ -266,6 +266,26 @@ &dispcc1 {
> >  	status = "okay";
> >  };
> >  
> > +&i2c12 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&qup1_i2c4_state>;
> property-n
> property-names
> 
> (same below)
> > +
> > +	status = "okay";
> > +
> > +	vdd_gfx: regulator at 39 {
> > +		compatible = "maxim,max20411";
> > +		reg = <0x39>;
> > +
> > +		regulator-min-microvolt = <800000>;
> > +		regulator-max-microvolt = <968750>;
> Is this ever going to be scaled? I suppose you could add some OPP code to
> drm/msm and use opp-microvolts.. Or lock this down at min=max
> 

Downstream leave it at 0.8V, so let's lock it down for now.

Regards,
Bjorn

> Konrad


From quic_bjorande at quicinc.com  Thu Dec 21 11:16:34 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 11:16:34 -0800
Subject: [PATCH 1/8] dt-bindings: clock: qcom: Allow VDD_GFX supply to GX
In-Reply-To: <CAA8EJpqgcOJHUFHtrTEE0T+jtQqdv3RGm-eTuVVa0ama_eFssQ@mail.gmail.com>
References: <20231220-sa8295p-gpu-v1-0-d8cdf2257f97@quicinc.com>
 <20231220-sa8295p-gpu-v1-1-d8cdf2257f97@quicinc.com>
 <CAA8EJprRjRJsV5hPR6mzjgucKa8UEthJd-y573aYJH0P8QRWqw@mail.gmail.com>
 <CAA8EJpqgcOJHUFHtrTEE0T+jtQqdv3RGm-eTuVVa0ama_eFssQ@mail.gmail.com>
Message-ID: <20231221191634.GS1766637@hu-bjorande-lv.qualcomm.com>

On Thu, Dec 21, 2023 at 09:10:28AM +0200, Dmitry Baryshkov wrote:
> On Thu, 21 Dec 2023 at 09:03, Dmitry Baryshkov
> <dmitry.baryshkov at linaro.org> wrote:
> >
> > On Thu, 21 Dec 2023 at 05:51, Bjorn Andersson <quic_bjorande at quicinc.com> wrote:
> > >
> > > In some designs the SoC's VDD_GFX pads are supplied by an external
> > > regulator, rather than a power-domain. Allow this to be described in the
> > > GPU clock controller binding.
> > >
> > > Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> > > ---
> > >  Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> > > index f369fa34e00c..013ef78d2b31 100644
> > > --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> > > +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> > > @@ -53,6 +53,9 @@ properties:
> > >    power-domains:
> > >      maxItems: 1
> > >
> > > +  vdd-gfx-supply:
> > > +    description: Regulator supply for the VDD_GFX pads
> > > +
> > >    '#clock-cells':
> > >      const: 1
> >
> > I think it might be good to restrict this property to a particular
> > platform (via if:not:properties:compatible:contains
> > then:properties:vdd-gfx-supply:false).
> 
> After reading the last patches in the series, there is another
> suggestion. Maybe we should explicitly say that there should be either
> power-domains or vdd-gfx-supply, but not both.
> 

Even on this platform it's not a property of the SoC, but surrounding
design. So I like this proposal.

Thanks,
Bjorn


From markhas at chromium.org  Thu Dec 21 11:24:51 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Thu, 21 Dec 2023 12:24:51 -0700
Subject: [PATCH v2 06/22] ARM: dts: samsung: exynos5420: Enable
 cros-ec-spi as wake source
In-Reply-To: <50dceec0-3a43-4363-8404-d701f726acc0@linaro.org>
References: <20231220235459.2965548-1-markhas@chromium.org>
 <20231220165423.v2.6.I06b059021de1bf6103e60a73211f078f2af75d17@changeid>
 <7199b7b7-238e-45de-96f1-0f04d0fa718d@linaro.org> <CANg-bXD+TVHO3o6f66fJXQ7AtXxPY00TQqjvX2vwk9PyTd1ZaA@mail.gmail.com>
 <50dceec0-3a43-4363-8404-d701f726acc0@linaro.org>
Message-ID: <CANg-bXAY5AGTu_jwtO8syCi8XVh5ti1V6ZFMzyCSBjzCUKUn1Q@mail.gmail.com>

> >> You do not need this property, if driver assumes that. Just enable it
> >> unconditionally.
> >
> > The goal of this patch series is to change exactly that: to prevent
> > the driver from unconditionally enabling the irq for wake.
>
> But why? What is the problem being solved? Is unconditional wakeup in
> the driver incorrect? If so, mention it shortly in the commit msg, what
> is rationale because existing one does not justify this change.

The cover letter talks about it:
"Currently the cros_ec driver assumes that its associated interrupt is
wake capable. This is an incorrect assumption as some Chromebooks use
a separate wake pin, while others overload the interrupt for wake and
IO."
With the current assumption, spurious wakes can occur on systems that
use a separate wake pin.
I can add wording to the dts patches to help clarify.

> > The driver works across numerous buses (spi, uart, i2c, lpc) and
> > supports DT and ACPI.
> > SPI+DT systems all happen to need irq wake enabled.
> >
> >> I don't think anything from previous discussion was
> >> resolved.
> >
> > Which previous discussion do you mean? In v1 it was suggested to split
>
> https://lore.kernel.org/all/20231213221124.GB2115075-robh at kernel.org/

Hmm, I thought that was addressed [2]. I was referencing the existing
binding documentation. From there, there was discussion about updating
the docs to clarify what was actually intended (patch 3 in this
series). I also addressed the ABI break concern in the thread and
mentioned it in patch 22.
"For device tree base systems, it is not an issue as the relevant
device tree entries have been updated and DTS is built from source for
each ChromeOS update."

Is there a specific concern you feel is not resolved? Or can I make
something more clear?

[2] https://lore.kernel.org/all/CANg-bXCG61HFW7JFuAd3k+OrCG_F9F3e8brjM-pmBauS53aobQ at mail.gmail.com/


From rafael at kernel.org  Thu Dec 21 11:57:08 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Thu, 21 Dec 2023 20:57:08 +0100
Subject: [PATCH v2 1/5] cpufreq: Add a cpufreq pressure feedback for the scheduler
In-Reply-To: <20231221152407.436177-2-vincent.guittot@linaro.org>
References: <20231221152407.436177-1-vincent.guittot@linaro.org> <20231221152407.436177-2-vincent.guittot@linaro.org>
Message-ID: <CAJZ5v0iU+nx_Tk_K74=dfeOuA7Lyvbq51UW=U1L4mZVEKy-+ZQ@mail.gmail.com>

On Thu, Dec 21, 2023 at 4:24?PM Vincent Guittot
<vincent.guittot at linaro.org> wrote:
>
> Provide to the scheduler a feedback about the temporary max available
> capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
> filtered as the pressure will happen for dozens ms or more.
>
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> ---
>  drivers/cpufreq/cpufreq.c | 34 ++++++++++++++++++++++++++++++++++
>  include/linux/cpufreq.h   | 10 ++++++++++
>  2 files changed, 44 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 44db4f59c4cc..15bd41f9bb5e 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2563,6 +2563,38 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
>  }
>  EXPORT_SYMBOL(cpufreq_get_policy);
>
> +DEFINE_PER_CPU(unsigned long, cpufreq_pressure);
> +
> +/**
> + * cpufreq_update_pressure() - Update cpufreq pressure for CPUs
> + * @policy: cpufreq policy of the CPUs.
> + *
> + * Update the value of cpufreq pressure for all @cpus in the policy.
> + */
> +static void cpufreq_update_pressure(struct cpufreq_policy *policy)
> +{
> +       unsigned long max_capacity, capped_freq, pressure;
> +       u32 max_freq;
> +       int cpu;
> +
> +       cpu = cpumask_first(policy->related_cpus);
> +       pressure = max_capacity = arch_scale_cpu_capacity(cpu);

I would prefer two separate statements instead of the above.

Other than this

Acked-by: Rafael J. Wysocki <rafael at kernel.org>

> +       capped_freq = policy->max;
> +       max_freq = arch_scale_freq_ref(cpu);
> +
> +       /*
> +        * Handle properly the boost frequencies, which should simply clean
> +        * the thermal pressure value.
> +        */
> +       if (max_freq <= capped_freq)
> +               pressure -= max_capacity;
> +       else
> +               pressure -= mult_frac(max_capacity, capped_freq, max_freq);
> +
> +       for_each_cpu(cpu, policy->related_cpus)
> +               WRITE_ONCE(per_cpu(cpufreq_pressure, cpu), pressure);
> +}
> +
>  /**
>   * cpufreq_set_policy - Modify cpufreq policy parameters.
>   * @policy: Policy object to modify.
> @@ -2618,6 +2650,8 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
>         policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
>         trace_cpu_frequency_limits(policy);
>
> +       cpufreq_update_pressure(policy);
> +
>         policy->cached_target_freq = UINT_MAX;
>
>         pr_debug("new min and max freqs are %u - %u kHz\n",
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index afda5f24d3dd..b1d97edd3253 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -241,6 +241,12 @@ struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy);
>  void cpufreq_enable_fast_switch(struct cpufreq_policy *policy);
>  void cpufreq_disable_fast_switch(struct cpufreq_policy *policy);
>  bool has_target_index(void);
> +
> +DECLARE_PER_CPU(unsigned long, cpufreq_pressure);
> +static inline unsigned long cpufreq_get_pressure(int cpu)
> +{
> +       return per_cpu(cpufreq_pressure, cpu);
> +}
>  #else
>  static inline unsigned int cpufreq_get(unsigned int cpu)
>  {
> @@ -263,6 +269,10 @@ static inline bool cpufreq_supports_freq_invariance(void)
>         return false;
>  }
>  static inline void disable_cpufreq(void) { }
> +static inline unsigned long cpufreq_get_pressure(int cpu)
> +{
> +       return 0;
> +}
>  #endif
>
>  #ifdef CONFIG_CPU_FREQ_STAT
> --
> 2.34.1
>


From rafael at kernel.org  Thu Dec 21 12:01:51 2023
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Thu, 21 Dec 2023 21:01:51 +0100
Subject: [PATCH v2 1/5] cpufreq: Add a cpufreq pressure feedback for the scheduler
In-Reply-To: <CAJZ5v0iU+nx_Tk_K74=dfeOuA7Lyvbq51UW=U1L4mZVEKy-+ZQ@mail.gmail.com>
References: <20231221152407.436177-1-vincent.guittot@linaro.org>
 <20231221152407.436177-2-vincent.guittot@linaro.org> <CAJZ5v0iU+nx_Tk_K74=dfeOuA7Lyvbq51UW=U1L4mZVEKy-+ZQ@mail.gmail.com>
Message-ID: <CAJZ5v0iChOQKpHaQy+Q0e9bBDjPsB107qk0FfT1z8_exFXiJdQ@mail.gmail.com>

On Thu, Dec 21, 2023 at 8:57?PM Rafael J. Wysocki <rafael at kernel.org> wrote:
>
> On Thu, Dec 21, 2023 at 4:24?PM Vincent Guittot
> <vincent.guittot at linaro.org> wrote:
> >
> > Provide to the scheduler a feedback about the temporary max available
> > capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
> > filtered as the pressure will happen for dozens ms or more.
> >
> > Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> > ---
> >  drivers/cpufreq/cpufreq.c | 34 ++++++++++++++++++++++++++++++++++
> >  include/linux/cpufreq.h   | 10 ++++++++++
> >  2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 44db4f59c4cc..15bd41f9bb5e 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2563,6 +2563,38 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
> >  }
> >  EXPORT_SYMBOL(cpufreq_get_policy);
> >
> > +DEFINE_PER_CPU(unsigned long, cpufreq_pressure);
> > +
> > +/**
> > + * cpufreq_update_pressure() - Update cpufreq pressure for CPUs
> > + * @policy: cpufreq policy of the CPUs.
> > + *
> > + * Update the value of cpufreq pressure for all @cpus in the policy.
> > + */
> > +static void cpufreq_update_pressure(struct cpufreq_policy *policy)
> > +{
> > +       unsigned long max_capacity, capped_freq, pressure;
> > +       u32 max_freq;
> > +       int cpu;
> > +
> > +       cpu = cpumask_first(policy->related_cpus);
> > +       pressure = max_capacity = arch_scale_cpu_capacity(cpu);
>
> I would prefer two separate statements instead of the above.
>
> Other than this
>
> Acked-by: Rafael J. Wysocki <rafael at kernel.org>
>
> > +       capped_freq = policy->max;
> > +       max_freq = arch_scale_freq_ref(cpu);
> > +
> > +       /*
> > +        * Handle properly the boost frequencies, which should simply clean
> > +        * the thermal pressure value.
> > +        */
> > +       if (max_freq <= capped_freq)
> > +               pressure -= max_capacity;

Actually, it would be somewhat cleaner to do

pressure = 0;

here and

> > +       else
> > +               pressure -= mult_frac(max_capacity, capped_freq, max_freq);

pressure = max_capacity - mult_frac(max_capacity, capped_freq, max_freq);

and it would not be necessary to initialize pressure.

> > +
> > +       for_each_cpu(cpu, policy->related_cpus)
> > +               WRITE_ONCE(per_cpu(cpufreq_pressure, cpu), pressure);
> > +}
> > +
> >  /**
> >   * cpufreq_set_policy - Modify cpufreq policy parameters.
> >   * @policy: Policy object to modify.
> > @@ -2618,6 +2650,8 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
> >         policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
> >         trace_cpu_frequency_limits(policy);
> >
> > +       cpufreq_update_pressure(policy);
> > +
> >         policy->cached_target_freq = UINT_MAX;
> >
> >         pr_debug("new min and max freqs are %u - %u kHz\n",
> > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> > index afda5f24d3dd..b1d97edd3253 100644
> > --- a/include/linux/cpufreq.h
> > +++ b/include/linux/cpufreq.h
> > @@ -241,6 +241,12 @@ struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy);
> >  void cpufreq_enable_fast_switch(struct cpufreq_policy *policy);
> >  void cpufreq_disable_fast_switch(struct cpufreq_policy *policy);
> >  bool has_target_index(void);
> > +
> > +DECLARE_PER_CPU(unsigned long, cpufreq_pressure);
> > +static inline unsigned long cpufreq_get_pressure(int cpu)
> > +{
> > +       return per_cpu(cpufreq_pressure, cpu);
> > +}
> >  #else
> >  static inline unsigned int cpufreq_get(unsigned int cpu)
> >  {
> > @@ -263,6 +269,10 @@ static inline bool cpufreq_supports_freq_invariance(void)
> >         return false;
> >  }
> >  static inline void disable_cpufreq(void) { }
> > +static inline unsigned long cpufreq_get_pressure(int cpu)
> > +{
> > +       return 0;
> > +}
> >  #endif
> >
> >  #ifdef CONFIG_CPU_FREQ_STAT
> > --
> > 2.34.1
> >


From krzysztof.kozlowski at linaro.org  Thu Dec 21 12:34:16 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 21:34:16 +0100
Subject: [PATCH v2 06/22] ARM: dts: samsung: exynos5420: Enable
 cros-ec-spi as wake source
In-Reply-To: <CANg-bXAY5AGTu_jwtO8syCi8XVh5ti1V6ZFMzyCSBjzCUKUn1Q@mail.gmail.com>
References: <20231220235459.2965548-1-markhas@chromium.org>
 <20231220165423.v2.6.I06b059021de1bf6103e60a73211f078f2af75d17@changeid>
 <7199b7b7-238e-45de-96f1-0f04d0fa718d@linaro.org>
 <CANg-bXD+TVHO3o6f66fJXQ7AtXxPY00TQqjvX2vwk9PyTd1ZaA@mail.gmail.com>
 <50dceec0-3a43-4363-8404-d701f726acc0@linaro.org>
 <CANg-bXAY5AGTu_jwtO8syCi8XVh5ti1V6ZFMzyCSBjzCUKUn1Q@mail.gmail.com>
Message-ID: <b9f146ee-ac25-425e-bd56-3339fee53223@linaro.org>

On 21/12/2023 20:24, Mark Hasemeyer wrote:
>>>> You do not need this property, if driver assumes that. Just enable it
>>>> unconditionally.
>>>
>>> The goal of this patch series is to change exactly that: to prevent
>>> the driver from unconditionally enabling the irq for wake.
>>
>> But why? What is the problem being solved? Is unconditional wakeup in
>> the driver incorrect? If so, mention it shortly in the commit msg, what
>> is rationale because existing one does not justify this change.
> 
> The cover letter talks about it:
> "Currently the cros_ec driver assumes that its associated interrupt is
> wake capable. This is an incorrect assumption as some Chromebooks use
> a separate wake pin, while others overload the interrupt for wake and
> IO."
> With the current assumption, spurious wakes can occur on systems that
> use a separate wake pin.

This sentence would be enough.

> I can add wording to the dts patches to help clarify.
> 
>>> The driver works across numerous buses (spi, uart, i2c, lpc) and
>>> supports DT and ACPI.
>>> SPI+DT systems all happen to need irq wake enabled.
>>>
>>>> I don't think anything from previous discussion was
>>>> resolved.
>>>
>>> Which previous discussion do you mean? In v1 it was suggested to split
>>
>> https://lore.kernel.org/all/20231213221124.GB2115075-robh at kernel.org/
> 
> Hmm, I thought that was addressed [2]. I was referencing the existing
> binding documentation. From there, there was discussion about updating
> the docs to clarify what was actually intended (patch 3 in this
> series). I also addressed the ABI break concern in the thread and
> mentioned it in patch 22.
> "For device tree base systems, it is not an issue as the relevant
> device tree entries have been updated and DTS is built from source for
> each ChromeOS update."
> 
> Is there a specific concern you feel is not resolved? Or can I make
> something more clear?
> 
Seems fine, thanks.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec 21 12:36:37 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 21:36:37 +0100
Subject: [PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings for
 STM32 LVDS device
In-Reply-To: <20231221124339.420119-3-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
 <20231221124339.420119-3-raphael.gallais-pou@foss.st.com>
Message-ID: <88834783-5aea-46d2-82cc-dd22cb4473f5@linaro.org>

On 21/12/2023 13:43, Raphael Gallais-Pou wrote:
> Add dt-binding file for "st,stm32-lvds" compatible.
> 
> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
> ---

I don't know why this was resend, nothing explains it, but I already
commented on other version.

Please respond to comments there.

In the future, unless it is obvious resend over 2 weeks, say why you are
doing it and what changed.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec 21 12:38:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 21:38:32 +0100
Subject: [PATCH v3 1/4] dt-bindings: firmware: xilinx: Describe missing
 child nodes
In-Reply-To: <1d7988cfadf3554d11f0779f96a670b4fd86ce5a.1703161663.git.michal.simek@amd.com>
References: <cover.1703161663.git.michal.simek@amd.com>
 <1d7988cfadf3554d11f0779f96a670b4fd86ce5a.1703161663.git.michal.simek@amd.com>
Message-ID: <3bc9f0a4-1336-4398-a654-13bd276df5bf@linaro.org>

On 21/12/2023 13:27, Michal Simek wrote:
> Firmware node has more than fpga, aes and clock child nodes but also power,
> reset, gpio, pinctrl and pcap which are not described yet.
> All of them have binding in separate files but there is missing connection
> to firmware node that's why describe it.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Thu Dec 21 12:39:18 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 21 Dec 2023 21:39:18 +0100
Subject: [PATCH v3 3/4] dt-bindings: power: reset: xilinx: Rename node
 names in examples
In-Reply-To: <920c839ae2c9c5803c6c08b8705a0d8338bb94bc.1703161663.git.michal.simek@amd.com>
References: <cover.1703161663.git.michal.simek@amd.com>
 <920c839ae2c9c5803c6c08b8705a0d8338bb94bc.1703161663.git.michal.simek@amd.com>
Message-ID: <5827119c-5788-4d59-8073-3d7f393aa821@linaro.org>

On 21/12/2023 13:27, Michal Simek wrote:
> Rename zynqmp-power node name to power-management which is more aligned
> with generic node name recommendation.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>


Best regards,
Krzysztof



From robh at kernel.org  Thu Dec 21 13:09:54 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 21 Dec 2023 15:09:54 -0600
Subject: [PATCH RESEND v1 1/8] dt-bindings: panel: lvds: Append
 edt,etml0700z9ndha in panel-lvds
In-Reply-To: <20231221124339.420119-2-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
 <20231221124339.420119-2-raphael.gallais-pou@foss.st.com>
Message-ID: <170319299428.98837.13859133240448825226.robh@kernel.org>


On Thu, 21 Dec 2023 13:43:32 +0100, Raphael Gallais-Pou wrote:
> List EDT ETML0700Z9NDHA in the LVDS panel enumeration.
> 
> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
> ---
>  Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>



From broonie at kernel.org  Thu Dec 21 13:21:09 2023
From: broonie at kernel.org (Mark Brown)
Date: Thu, 21 Dec 2023 21:21:09 +0000
Subject: [PATCH] KVM: arm64: Document why we trap SVE access from the host
 in nVHE
Message-ID: <20231221-kvm-arm64-nvhe-sve-trap-v1-1-332ecc56f694@kernel.org>

When we exit from a SVE guest we leave the SVE configuration in EL2 as it
was for the guest, only switching back to the host configuration on next
use by the host. This is perhaps a little surprising when encountered in
the code by itself, add comments explaining what is going on both in the
trap handler and when we configure the traps.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_emulate.h | 2 ++
 arch/arm64/kvm/hyp/nvhe/hyp-main.c   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 78a550537b67..edd807a77e19 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -590,6 +590,7 @@ static __always_inline u64 kvm_get_reset_cptr_el2(struct kvm_vcpu *vcpu)
 	} else if (has_hvhe()) {
 		val = (CPACR_EL1_FPEN_EL0EN | CPACR_EL1_FPEN_EL1EN);
 
+		/* Leave traps enabled, we will restore EL2 lazily */
 		if (!vcpu_has_sve(vcpu) ||
 		    (vcpu->arch.fp_state != FP_STATE_GUEST_OWNED))
 			val |= CPACR_EL1_ZEN_EL1EN | CPACR_EL1_ZEN_EL0EN;
@@ -598,6 +599,7 @@ static __always_inline u64 kvm_get_reset_cptr_el2(struct kvm_vcpu *vcpu)
 	} else {
 		val = CPTR_NVHE_EL2_RES1;
 
+		/* Leave traps enabled, we will restore EL2 lazily */
 		if (vcpu_has_sve(vcpu) &&
 		    (vcpu->arch.fp_state == FP_STATE_GUEST_OWNED))
 			val |= CPTR_EL2_TZ;
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 2385fd03ed87..84deed83e580 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -420,6 +420,7 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
 		handle_host_smc(host_ctxt);
 		break;
 	case ESR_ELx_EC_SVE:
+		/* Handle lazy restore of the host VL */
 		if (has_hvhe())
 			sysreg_clear_set(cpacr_el1, 0, (CPACR_EL1_ZEN_EL1EN |
 							CPACR_EL1_ZEN_EL0EN));

---
base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab
change-id: 20231218-kvm-arm64-nvhe-sve-trap-f65a3dd46a6a

Best regards,
-- 
Mark Brown <broonie at kernel.org>



From robh at kernel.org  Thu Dec 21 14:01:11 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 21 Dec 2023 16:01:11 -0600
Subject: [PATCH v8 06/13] of: property: fw_devlink: Add support for
 "access-controller"
In-Reply-To: <20231212152356.345703-7-gatien.chevallier@foss.st.com>
References: <20231212152356.345703-1-gatien.chevallier@foss.st.com>
 <20231212152356.345703-7-gatien.chevallier@foss.st.com>
Message-ID: <170319607084.165973.14576693798188042387.robh@kernel.org>


On Tue, 12 Dec 2023 16:23:49 +0100, Gatien Chevallier wrote:
> Allows tracking dependencies between devices and their access
> controller.
> 
> Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
> ---
> 
> Changes in V6:
>     	- Renamed access-controller to access-controllers
> 
> Changes in V5:
> 	- Rename feature-domain* to access-control*
> 
> Patch not present in V1
> 
>  drivers/of/property.c | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Thu Dec 21 14:21:09 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 21 Dec 2023 16:21:09 -0600
Subject: [PATCH v2 1/2] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <20231220002824.2462655-2-cristian.ciocaltea@collabora.com>
References: <20231220002824.2462655-1-cristian.ciocaltea@collabora.com>
 <20231220002824.2462655-2-cristian.ciocaltea@collabora.com>
Message-ID: <20231221222109.GA186673-robh@kernel.org>

On Wed, Dec 20, 2023 at 02:28:22AM +0200, Cristian Ciocaltea wrote:
> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
> similar to the newer JH7110, but it requires only two interrupts and a
> single reset line, which is 'ahb' instead of the commonly used
> 'stmmaceth'.
> 
> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
> conjunction with 'stmmaceth', extend the logic to also permit exclusive
> usage of the 'ahb' reset name.  This ensures the following use cases are
> supported:
> 
>   JH7110: reset-names = "stmmaceth", "ahb";
>   JH7100: reset-names = "ahb";
>   other:  reset-names = "stmmaceth";
> 
> Also note the need to use a different dwmac fallback, as v5.20 applies
> to JH7110 only, while JH7100 relies on v3.7x.
> 
> Additionally, drop the reset description items from top-level binding as
> they are already provided by the included snps,dwmac schema.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
> ---
>  .../devicetree/bindings/net/snps,dwmac.yaml   | 11 ++-
>  .../bindings/net/starfive,jh7110-dwmac.yaml   | 75 +++++++++++++------
>  2 files changed, 60 insertions(+), 26 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 5c2769dc689a..90c4db178c67 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -95,6 +95,7 @@ properties:
>          - snps,dwmac-5.20
>          - snps,dwxgmac
>          - snps,dwxgmac-2.10
> +        - starfive,jh7100-dwmac
>          - starfive,jh7110-dwmac
>  
>    reg:
> @@ -144,10 +145,12 @@ properties:
>        - description: AHB reset
>  
>    reset-names:
> -    minItems: 1
> -    items:
> -      - const: stmmaceth
> -      - const: ahb
> +    oneOf:
> +      - items:
> +          - enum: [stmmaceth, ahb]
> +      - items:
> +          - const: stmmaceth
> +          - const: ahb
>  
>    power-domains:
>      maxItems: 1
> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> index 5e7cfbbebce6..f5f0bff5be0f 100644
> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> @@ -16,16 +16,20 @@ select:
>      compatible:
>        contains:
>          enum:
> +          - starfive,jh7100-dwmac
>            - starfive,jh7110-dwmac
>    required:
>      - compatible
>  
>  properties:
>    compatible:
> -    items:
> -      - enum:
> -          - starfive,jh7110-dwmac
> -      - const: snps,dwmac-5.20
> +    oneOf:
> +      - items:
> +          - const: starfive,jh7100-dwmac
> +          - const: snps,dwmac
> +      - items:
> +          - const: starfive,jh7110-dwmac
> +          - const: snps,dwmac-5.20
>  
>    reg:
>      maxItems: 1
> @@ -46,24 +50,6 @@ properties:
>        - const: tx
>        - const: gtx
>  
> -  interrupts:
> -    minItems: 3
> -    maxItems: 3
> -
> -  interrupt-names:
> -    minItems: 3
> -    maxItems: 3
> -
> -  resets:
> -    items:
> -      - description: MAC Reset signal.
> -      - description: AHB Reset signal.
> -
> -  reset-names:
> -    items:
> -      - const: stmmaceth
> -      - const: ahb
> -
>    starfive,tx-use-rgmii-clk:
>      description:
>        Tx clock is provided by external rgmii clock.
> @@ -94,6 +80,51 @@ required:
>  allOf:
>    - $ref: snps,dwmac.yaml#
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: starfive,jh7100-dwmac
> +    then:
> +      properties:
> +        interrupts:
> +          minItems: 2
> +          maxItems: 2
> +
> +        interrupt-names:
> +          minItems: 2
> +          maxItems: 2
> +
> +        resets:
> +          maxItems: 1
> +
> +        reset-names:
> +          const: ahb

Just 'maxItems: 1'

> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: starfive,jh7110-dwmac
> +    then:
> +      properties:
> +        interrupts:
> +          minItems: 3
> +          maxItems: 3
> +
> +        interrupt-names:
> +          minItems: 3
> +          maxItems: 3
> +
> +        resets:
> +          minItems: 2
> +          maxItems: 2

max is already 2. Drop.

> +
> +        reset-names:
> +          items:
> +            - const: stmmaceth
> +            - const: ahb

Already defined the names. Just 'minItems: 2'.

> +
>  unevaluatedProperties: false
>  
>  examples:
> -- 
> 2.43.0
> 


From robh at kernel.org  Thu Dec 21 14:29:32 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 21 Dec 2023 16:29:32 -0600
Subject: [PATCH v10 02/16] dt-bindings: media: mediatek: mdp3: merge the
 indentical RDMA under display
In-Reply-To: <250fead9-868b-4063-a054-4cb966dc4ba3@linaro.org>
References: <20231220100853.20616-1-moudy.ho@mediatek.com>
 <20231220100853.20616-3-moudy.ho@mediatek.com>
 <250fead9-868b-4063-a054-4cb966dc4ba3@linaro.org>
Message-ID: <20231221222932.GA196757-robh@kernel.org>

On Thu, Dec 21, 2023 at 10:28:52AM +0100, Krzysztof Kozlowski wrote:
> On 20/12/2023 11:08, Moudy Ho wrote:
> > To simplify maintenance and avoid branches, the identical component
> > should be merged and placed in the path belonging to the MDP
> > (from display/* to media/*).
> 
> Combining bindings into one bigger meta-binding makes it usually more
> difficult to maintain and review.

Yeah, but these mediatek blocks appear to be used for both display and 
video codec pipelines. So having different bindings was probably wrong 
to start with.

Rob


From robh at kernel.org  Thu Dec 21 14:50:33 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 21 Dec 2023 16:50:33 -0600
Subject: [PATCH v5 10/16] dt-bindings: imx6q-pcie: remove reg and reg-name
In-Reply-To: <20231220213615.1561528-11-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-11-Frank.Li@nxp.com>
Message-ID: <20231221225033.GA228866-robh@kernel.org>

On Wed, Dec 20, 2023 at 04:36:09PM -0500, Frank Li wrote:
> snps,dw-pcie.yaml already have reg and reg-name information. Needn't
> duplciate here.
> 
> Acked-by: Rob Herring <robh at kernel.org>
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> 
> Notes:
>     Change from v4 to v5
>     - add Rob's Acked

Err, that was intended for patch 9, not this one. This patch should be 
dropped.

>     Change from v1 to v4:
>     - new patch at v4
> 
>  .../devicetree/bindings/pci/fsl,imx6q-pcie.yaml        | 10 ----------
>  1 file changed, 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> index 81bbb8728f0f9..f20d4f0e3cb6c 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> @@ -30,16 +30,6 @@ properties:
>        - fsl,imx8mm-pcie
>        - fsl,imx8mp-pcie
>  
> -  reg:
> -    items:
> -      - description: Data Bus Interface (DBI) registers.
> -      - description: PCIe configuration space region.
> -
> -  reg-names:
> -    items:
> -      - const: dbi
> -      - const: config
> -
>    clocks:
>      minItems: 3
>      items:
> -- 
> 2.34.1
> 


From robh at kernel.org  Thu Dec 21 14:52:18 2023
From: robh at kernel.org (Rob Herring)
Date: Thu, 21 Dec 2023 16:52:18 -0600
Subject: [PATCH v5 11/16] dt-bindings: imx6q-pcie: Add imx95 pcie
 compatible string
In-Reply-To: <20231220213615.1561528-12-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-12-Frank.Li@nxp.com>
Message-ID: <20231221225218.GA232422-robh@kernel.org>

On Wed, Dec 20, 2023 at 04:36:10PM -0500, Frank Li wrote:
> From: Richard Zhu <hongxing.zhu at nxp.com>
> 
> Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
> Add "atu" and "app" to reg-names.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> ---
> 
> Notes:
>     Change from v2 to v3
>     - Remove krzy's ACK tag
>     - Add condition check for imx95, which required more reg-names then old
>     platform, so need Krzy review again,
>     
>     Change from v1 to v2
>     - add Krzy's ACK tag
> 
>  .../bindings/pci/fsl,imx6q-pcie-common.yaml    |  1 +
>  .../bindings/pci/fsl,imx6q-pcie.yaml           | 18 ++++++++++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
> index a284a27c5e873..1b63089ff0aee 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
> @@ -207,6 +207,7 @@ allOf:
>                  - fsl,imx6sx-pcie
>                  - fsl,imx6q-pcie
>                  - fsl,imx6qp-pcie
> +                - fsl,imx95-pcie
>                  - fsl,imx6sx-pcie-ep
>                  - fsl,imx6q-pcie-ep
>                  - fsl,imx6qp-pcie-ep
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> index f20d4f0e3cb6c..8633c622bd178 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> @@ -29,6 +29,7 @@ properties:
>        - fsl,imx8mq-pcie
>        - fsl,imx8mm-pcie
>        - fsl,imx8mp-pcie
> +      - fsl,imx95-pcie
>  
>    clocks:
>      minItems: 3
> @@ -80,6 +81,22 @@ required:
>  allOf:
>    - $ref: /schemas/pci/snps,dw-pcie.yaml#
>    - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          enum:
> +            - fsl,imx95-pcie
> +    then:
> +      properties:
> +        reg:
> +          minItems: 4
> +        reg-names:
> +          items:
> +            - const: dbi
> +            - const: atu
> +            - const: app
> +            - const: config

Add new entries to the end. Originally, you had dbi and config. Add ata 
and app on the end.

> +
>    - if:
>        properties:
>          compatible:
> @@ -101,6 +118,7 @@ allOf:
>          compatible:
>            enum:
>              - fsl,imx8mq-pcie
> +            - fsl,imx95-pcie
>      then:
>        properties:
>          clocks:
> -- 
> 2.34.1
> 


From martin.juecker at gmail.com  Thu Dec 21 15:02:57 2023
From: martin.juecker at gmail.com (=?UTF-8?q?Martin=20J=C3=BCcker?=)
Date: Fri, 22 Dec 2023 00:02:57 +0100
Subject: [PATCH 1/2] ARM: dts: exynos: add accelerometer and gyro to p4note
Message-ID: <20231221230258.56272-1-martin.juecker@gmail.com>

Add entries for LSM330DLC accelerometer and gyro to the p4note.

Signed-off-by: Martin J?cker <martin.juecker at gmail.com>
---
 .../boot/dts/samsung/exynos4412-p4note.dtsi   | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/samsung/exynos4412-p4note.dtsi b/arch/arm/boot/dts/samsung/exynos4412-p4note.dtsi
index 0b89d5682f857..39a3d1cbe4c3b 100644
--- a/arch/arm/boot/dts/samsung/exynos4412-p4note.dtsi
+++ b/arch/arm/boot/dts/samsung/exynos4412-p4note.dtsi
@@ -362,6 +362,39 @@ &hsotg {
 	status = "okay";
 };
 
+&i2c_1 {
+	samsung,i2c-sda-delay = <100>;
+	samsung,i2c-slave-addr = <0x10>;
+	samsung,i2c-max-bus-freq = <400000>;
+	pinctrl-0 = <&i2c1_bus>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	accelerometer at 19 {
+		compatible = "st,lsm330dlc-accel";
+		reg = <0x19>;
+		interrupt-parent = <&gpx0>;
+		interrupts = <0 IRQ_TYPE_EDGE_RISING>;
+		pinctrl-0 = <&accelerometer_irq>;
+		pinctrl-names = "default";
+		mount-matrix =	"1",  "0",  "0",
+				"0", "-1",  "0",
+				"0",  "0", "-1";
+	};
+
+	gyro at 6b {
+		compatible = "st,lsm330dlc-gyro";
+		reg = <0x6b>;
+		interrupt-parent = <&gpx0>;
+		interrupts = <6 IRQ_TYPE_EDGE_RISING>;
+		pinctrl-0 = <&gyro_data_enable &gyro_irq>;
+		pinctrl-names = "default";
+		mount-matrix =	"1",  "0",  "0",
+				"0", "-1",  "0",
+				"0",  "0", "-1";
+	};
+};
+
 &i2c_3 {
 	samsung,i2c-sda-delay = <100>;
 	samsung,i2c-slave-addr = <0x10>;
@@ -844,6 +877,12 @@ bt_shutdown: bt-shutdown-pins {
 		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
 	};
 
+	gyro_data_enable: gyro-data-enable-pins {
+		samsung,pins = "gpl2-0";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+	};
+
 	uart_sel: uart-sel-pins {
 		samsung,pins = "gpl2-7";
 		samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
@@ -894,12 +933,24 @@ ak8975_irq: ak8975-irq-pins {
 		samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
 	};
 
+	accelerometer_irq: accelerometer-irq-pins {
+		samsung,pins = "gpx0-0";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
 	stmpe_adc_irq: stmpe-adc-irq-pins {
 		samsung,pins = "gpx0-1";
 		samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
 		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
 	};
 
+	gyro_irq: gyro-irq-pins {
+		samsung,pins = "gpx0-6";
+		samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+	};
+
 	max77686_irq: max77686-irq-pins {
 		samsung,pins = "gpx0-7";
 		samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
-- 
2.34.1



From martin.juecker at gmail.com  Thu Dec 21 15:02:58 2023
From: martin.juecker at gmail.com (=?UTF-8?q?Martin=20J=C3=BCcker?=)
Date: Fri, 22 Dec 2023 00:02:58 +0100
Subject: [PATCH 2/2] ARM: defconfig: enable STMicroelectronics accelerometer and gyro
In-Reply-To: <20231221230258.56272-1-martin.juecker@gmail.com>
References: <20231221230258.56272-1-martin.juecker@gmail.com>
Message-ID: <20231221230258.56272-2-martin.juecker@gmail.com>

Enable STMicroelectronics accelerometer and gyro drivers for the p4note
device family in exynos and multi_v7 defconfigs.

Signed-off-by: Martin J?cker <martin.juecker at gmail.com>
---
 arch/arm/configs/exynos_defconfig   | 3 +++
 arch/arm/configs/multi_v7_defconfig | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index 7483d7be23a66..0b64ce9be9aca 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -320,8 +320,11 @@ CONFIG_EXTCON_MAX77693=y
 CONFIG_EXTCON_MAX8997=y
 CONFIG_EXYNOS5422_DMC=y
 CONFIG_IIO=y
+CONFIG_IIO_ST_ACCEL_3AXIS=m
+# CONFIG_IIO_ST_ACCEL_SPI_3AXIS is not set
 CONFIG_EXYNOS_ADC=y
 CONFIG_STMPE_ADC=y
+CONFIG_IIO_ST_GYRO_3AXIS=m
 CONFIG_CM36651=y
 CONFIG_AK8975=y
 CONFIG_SENSORS_ISL29018=y
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index a4260c9e600d4..2e4a732420a21 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1146,6 +1146,8 @@ CONFIG_STM32_FMC2_EBI=y
 CONFIG_EXYNOS5422_DMC=m
 CONFIG_IIO=y
 CONFIG_IIO_SW_TRIGGER=y
+CONFIG_IIO_ST_ACCEL_3AXIS=m
+# CONFIG_IIO_ST_ACCEL_SPI_3AXIS is not set
 CONFIG_ASPEED_ADC=m
 CONFIG_AT91_ADC=m
 CONFIG_AT91_SAMA5D2_ADC=m
@@ -1165,6 +1167,7 @@ CONFIG_IIO_CROS_EC_SENSORS_CORE=m
 CONFIG_IIO_CROS_EC_SENSORS=m
 CONFIG_STM32_DAC=m
 CONFIG_MPU3050_I2C=y
+CONFIG_IIO_ST_GYRO_3AXIS=m
 CONFIG_CM36651=m
 CONFIG_IIO_CROS_EC_LIGHT_PROX=m
 CONFIG_SENSORS_ISL29018=y
-- 
2.34.1



From cristian.ciocaltea at collabora.com  Thu Dec 21 16:25:54 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 22 Dec 2023 02:25:54 +0200
Subject: [PATCH v2 1/2] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible
In-Reply-To: <20231221222109.GA186673-robh@kernel.org>
References: <20231220002824.2462655-1-cristian.ciocaltea@collabora.com>
 <20231220002824.2462655-2-cristian.ciocaltea@collabora.com>
 <20231221222109.GA186673-robh@kernel.org>
Message-ID: <459d320f-07bd-45f9-b7c6-1cf7969f0df7@collabora.com>

On 12/22/23 00:21, Rob Herring wrote:
> On Wed, Dec 20, 2023 at 02:28:22AM +0200, Cristian Ciocaltea wrote:
>> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
>> similar to the newer JH7110, but it requires only two interrupts and a
>> single reset line, which is 'ahb' instead of the commonly used
>> 'stmmaceth'.
>>
>> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
>> conjunction with 'stmmaceth', extend the logic to also permit exclusive
>> usage of the 'ahb' reset name.  This ensures the following use cases are
>> supported:
>>
>>   JH7110: reset-names = "stmmaceth", "ahb";
>>   JH7100: reset-names = "ahb";
>>   other:  reset-names = "stmmaceth";
>>
>> Also note the need to use a different dwmac fallback, as v5.20 applies
>> to JH7110 only, while JH7100 relies on v3.7x.
>>
>> Additionally, drop the reset description items from top-level binding as
>> they are already provided by the included snps,dwmac schema.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
>> ---
>>  .../devicetree/bindings/net/snps,dwmac.yaml   | 11 ++-
>>  .../bindings/net/starfive,jh7110-dwmac.yaml   | 75 +++++++++++++------
>>  2 files changed, 60 insertions(+), 26 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> index 5c2769dc689a..90c4db178c67 100644
>> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
>> @@ -95,6 +95,7 @@ properties:
>>          - snps,dwmac-5.20
>>          - snps,dwxgmac
>>          - snps,dwxgmac-2.10
>> +        - starfive,jh7100-dwmac
>>          - starfive,jh7110-dwmac
>>  
>>    reg:
>> @@ -144,10 +145,12 @@ properties:
>>        - description: AHB reset
>>  
>>    reset-names:
>> -    minItems: 1
>> -    items:
>> -      - const: stmmaceth
>> -      - const: ahb
>> +    oneOf:
>> +      - items:
>> +          - enum: [stmmaceth, ahb]
>> +      - items:
>> +          - const: stmmaceth
>> +          - const: ahb
>>  
>>    power-domains:
>>      maxItems: 1
>> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>> index 5e7cfbbebce6..f5f0bff5be0f 100644
>> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
>> @@ -16,16 +16,20 @@ select:
>>      compatible:
>>        contains:
>>          enum:
>> +          - starfive,jh7100-dwmac
>>            - starfive,jh7110-dwmac
>>    required:
>>      - compatible
>>  
>>  properties:
>>    compatible:
>> -    items:
>> -      - enum:
>> -          - starfive,jh7110-dwmac
>> -      - const: snps,dwmac-5.20
>> +    oneOf:
>> +      - items:
>> +          - const: starfive,jh7100-dwmac
>> +          - const: snps,dwmac
>> +      - items:
>> +          - const: starfive,jh7110-dwmac
>> +          - const: snps,dwmac-5.20
>>  
>>    reg:
>>      maxItems: 1
>> @@ -46,24 +50,6 @@ properties:
>>        - const: tx
>>        - const: gtx
>>  
>> -  interrupts:
>> -    minItems: 3
>> -    maxItems: 3
>> -
>> -  interrupt-names:
>> -    minItems: 3
>> -    maxItems: 3
>> -
>> -  resets:
>> -    items:
>> -      - description: MAC Reset signal.
>> -      - description: AHB Reset signal.
>> -
>> -  reset-names:
>> -    items:
>> -      - const: stmmaceth
>> -      - const: ahb
>> -
>>    starfive,tx-use-rgmii-clk:
>>      description:
>>        Tx clock is provided by external rgmii clock.
>> @@ -94,6 +80,51 @@ required:
>>  allOf:
>>    - $ref: snps,dwmac.yaml#
>>  
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: starfive,jh7100-dwmac
>> +    then:
>> +      properties:
>> +        interrupts:
>> +          minItems: 2
>> +          maxItems: 2
>> +
>> +        interrupt-names:
>> +          minItems: 2
>> +          maxItems: 2
>> +
>> +        resets:
>> +          maxItems: 1
>> +
>> +        reset-names:
>> +          const: ahb
> 
> Just 'maxItems: 1'

This would allow using either 'ahb' or 'stmmaceth', while only the
former should be permitted.

No issues with the other two optimizations, will be handled in v3.

Thank you for reviewing,
Cristian

>> +
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: starfive,jh7110-dwmac
>> +    then:
>> +      properties:
>> +        interrupts:
>> +          minItems: 3
>> +          maxItems: 3
>> +
>> +        interrupt-names:
>> +          minItems: 3
>> +          maxItems: 3
>> +
>> +        resets:
>> +          minItems: 2
>> +          maxItems: 2
> 
> max is already 2. Drop.
> 
>> +
>> +        reset-names:
>> +          items:
>> +            - const: stmmaceth
>> +            - const: ahb
> 
> Already defined the names. Just 'minItems: 2'.
> 
>> +
>>  unevaluatedProperties: false
>>  
>>  examples:
>> -- 
>> 2.43.0
>>


From sboyd at kernel.org  Thu Dec 21 16:48:59 2023
From: sboyd at kernel.org (Stephen Boyd)
Date: Thu, 21 Dec 2023 16:48:59 -0800
Subject: [PATCH v7 1/2] clk: stm32: introduce clocks for STM32MP257 platform
In-Reply-To: <21f758cb-ae25-4d74-905c-0d4820f00070@foss.st.com>
References: <20231219130909.265091-1-gabriel.fernandez@foss.st.com> <20231219130909.265091-2-gabriel.fernandez@foss.st.com> <c98539f99030f174583d7ee36802b4b9.sboyd@kernel.org> <21f758cb-ae25-4d74-905c-0d4820f00070@foss.st.com>
Message-ID: <a2d96b8259eed101c649fd71f7c1e453.sboyd@kernel.org>

Quoting Gabriel FERNANDEZ (2023-12-21 02:31:53)
> 
> On 12/20/23 23:16, Stephen Boyd wrote:
> > Quoting gabriel.fernandez at foss.st.com (2023-12-19 05:09:08)
> >> diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
> >> new file mode 100644
> >> index 000000000000..313e022c6142
> >> --- /dev/null
> >> +++ b/drivers/clk/stm32/clk-stm32mp25.c
> >> @@ -0,0 +1,1826 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +/*
> >> + * Copyright (C) STMicroelectronics 2023 - All Rights Reserved
> >> + * Author: Gabriel Fernandez <gabriel.fernandez at foss.st.com> for STMicroelectronics.
> >> + */
> >> +
> >> +#include <linux/clk.h>
> >> +#include <linux/of_address.h>
> >> +#include <linux/platform_device.h>
> >> +
> >> +#include "clk-stm32-core.h"
> >> +#include "reset-stm32.h"
> >> +#include "stm32mp25_rcc.h"
> >> +
> >> +#include <dt-bindings/clock/st,stm32mp25-rcc.h>
> >> +#include <dt-bindings/reset/st,stm32mp25-rcc.h>
> >> +
> >> +static const struct clk_parent_data adc12_src[] = {
> >> +       { .name = "ck_flexgen_46" },
> > This is a new driver. Don't use .name here. Instead use .index or .hw
> > and if that can't work then use .fw_name.
> 
> These parent clocks are managed by a secure world and exposed through SCMI.
> 
> If I use .index or .fw_name, do I have to expose 122 clocks in my DT node ?
> 
> This will significantly increase the size of the DT file
> 
>  ??? ??? ??? clock-names = "hse", "hsi", ..., "ck_scmi_stm500";
>  ?? ???? ??? clocks = <&scmi_clk CK_SCMI_HSE>, <&scmi_clk CK_SCMI_HSI>,? 
> ... , ? <&scmi_clk CK_SCMI_STM500>;
> 

Yes? We want DT to express the connections between device nodes, and if
the clks managed by SCMI are consumed here then they need to be
specified via the clocks property.

> 
> >
> >> +       { }
> >> +};
> >> +MODULE_DEVICE_TABLE(of, stm32mp25_match_data);
> >> +
> >> +static int get_clock_deps(struct device *dev)
> > What is the explanation for this function?
> 
> It 's to manage the dependency with the SCMI clock driver.

Please elaborate. Are you making sure the SCMI clk driver has probed
before this driver? Why? What's wrong with probing this driver first?


From tharvey at gateworks.com  Thu Dec 21 17:12:16 2023
From: tharvey at gateworks.com (Tim Harvey)
Date: Thu, 21 Dec 2023 17:12:16 -0800
Subject: imx7_media_csi probe deferred
Message-ID: <CAJ+vNU2Kj=a-_xDBsNO5zkyP_mgLsVtA2bXqkAkpmCQmVEA_=w@mail.gmail.com>

Greetings,

I'm running into an issue with Linux 6.6 (6.6.8) when compiling with
modules where the imx7_media_csi driver probe is deferred and I'm not
clear how to troubleshoot the cause.

The board is imx8mm-venice-gw73xx-0x [1] with
imx8mm-venice-gw73xx-0x-imx219.dtso [2] and I'm using
arch/arm64/configs/defconfig.

The kernel reports the following:
# dmesg | egrep csi\|mipi\|imx219
[    1.293264] i2c 2-0010: Fixed dependency cycle(s) with
/soc at 0/bus at 32c00000/mipi-csi at 32e30000/ports/port at 0/endpoint
[   12.001419] imx219 2-0010: supply VANA not found, using dummy regulator
[   12.044885] imx219 2-0010: supply VDDL not found, using dummy regulator
[   12.164308] imx7-csi 32e20000.csi: Registered csi capture as /dev/video0
[   12.178460] imx7-csi 32e20000.csi: error -ENOTCONN: Failed to get
remote endpoint
[   12.200047] imx7-csi: probe of 32e20000.csi failed with error -107
# cat /sys/kernel/debug/devices_deferred
cpufreq-dt
32e30000.mipi-csi       platform: wait for supplier
/soc at 0/bus at 32c00000/csi at 32e20000/port/endpoint
# zcat /proc/config.gz | egrep VIDEO_IMX219\|VIDEO_IMX_MIPI\|VIDEO_IMX7
CONFIG_VIDEO_IMX7_CSI=m
CONFIG_VIDEO_IMX_MIPI_CSIS=m
CONFIG_VIDEO_IMX219=m
# lsmod | grep imx
fsl_imx8_ddr_perf      16384  0
imx8m_ddrc             12288  0
imx7_media_csi         28672  0
videobuf2_dma_contig    16384  2 hantro_vpu,imx7_media_csi
videobuf2_v4l2         32768  3 hantro_vpu,imx7_media_csi,v4l2_mem2mem
videobuf2_common       57344  6
videobuf2_dma_contig,videobuf2_v4l2,hantro_vpu,imx7_media_csi,v4l2_mem2mem,videobuf2_memops
imx_mipi_csis          24576  0
imx219                 20480  0
v4l2_cci               12288  1 imx219
v4l2_fwnode            20480  2 imx219,imx_mipi_csis
v4l2_async             20480  4 v4l2_fwnode,imx219,imx_mipi_csis,imx7_media_csi
videodev              258048  8
v4l2_async,v4l2_fwnode,imx219,videobuf2_v4l2,hantro_vpu,imx_mipi_csis,imx7_media_csi,v4l2_mem2mem
mc                     61440  9
v4l2_async,videodev,imx219,videobuf2_v4l2,hantro_vpu,videobuf2_common,imx_mipi_csis,imx7_media_csi,v4l
2_mem2mem
spi_imx                24576  0
imx_pcm_dma            12288  1 snd_soc_fsl_sai
imx8mm_thermal         12288  0
imx_sdma               24576  6
imx_cpufreq_dt         12288  0

The relevant dt looks like this:

csi: csi at 32e20000 {
     compatible = "fsl,imx8mm-csi", "fsl,imx7-csi";
     reg = <0x32e20000 0x1000>;
     interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
     clocks = <&clk IMX8MM_CLK_CSI1_ROOT>;
     clock-names = "mclk";
     power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_CSI_BRIDGE>;
     status = "disabled";

     port {
          csi_in: endpoint {
               remote-endpoint = <&imx8mm_mipi_csi_out>;
          };
     };
};

mipi_csi: mipi-csi at 32e30000 {
     compatible = "fsl,imx8mm-mipi-csi2";
     reg = <0x32e30000 0x1000>;
     interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
     assigned-clocks = <&clk IMX8MM_CLK_CSI1_CORE>;
     assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_1000M>;

     clock-frequency = <333000000>;
     clocks = <&clk IMX8MM_CLK_DISP_APB_ROOT>,
          <&clk IMX8MM_CLK_CSI1_ROOT>,
          <&clk IMX8MM_CLK_CSI1_PHY_REF>,
          <&clk IMX8MM_CLK_DISP_AXI_ROOT>;
     clock-names = "pclk", "wrap", "phy", "axi";
     power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_MIPI_CSI>;
     status = "disabled";

     ports {
          #address-cells = <1>;
          #size-cells = <0>;

          port at 0 {
               reg = <0>;
          };

          port at 1 {
               reg = <1>;

               imx8mm_mipi_csi_out: endpoint {
                    remote-endpoint = <&csi_in>;
               };
          };
};

&csi {
     status = "okay";
};

&i2c3 {
     #address-cells = <1>;
     #size-cells = <0>;

     imx219: sensor at 10 {
          compatible = "sony,imx219";
          reg = <0x10>;
          clocks = <&cam24m>;
          VDIG-supply = <&reg_cam>;

          port {
               /* MIPI CSI-2 bus endpoint */
               imx219_to_mipi_csi2: endpoint {
                    remote-endpoint = <&imx8mm_mipi_csi_in>;
                    clock-lanes = <0>;
                    data-lanes = <1 2>;
                    link-frequencies = /bits/ 64 <456000000>;
               };
          };
     };
};

&mipi_csi {
     status = "okay";

     ports {
          #address-cells = <1>;
          #size-cells = <0>;

          port at 0 {
               reg = <0>;

               imx8mm_mipi_csi_in: endpoint {
                    remote-endpoint = <&imx219_to_mipi_csi2>;
                    data-lanes = <1 2>;
               };
          };

          port at 1 {
               reg = <1>;

               imx8mm_mipi_csi_out: endpoint {
                    remote-endpoint = <&csi_in>;
               };
          };
     };
};

Strangely I have a kernel config without modules where I do not run
into this issue so it has something to do with modules but I haven't
been able to determine which configs make a difference.

Any ideas what is wrong here or tips on troubleshooting the cause for
the probe defer?

Best Regards,

Tim
[1] https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts
[2] https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x-imx219.dtso


From peterx at redhat.com  Thu Dec 21 17:35:43 2023
From: peterx at redhat.com (Peter Xu)
Date: Fri, 22 Dec 2023 09:35:43 +0800
Subject: [PATCH 00/13] mm/gup: Unify hugetlb, part 2
In-Reply-To: <20231219075538.414708-1-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
Message-ID: <ZYTn70CDVeNMed0f@x1n>

Copy Muchun, which I forgot since the start, sorry.

-- 
Peter Xu



From boy.wu at mediatek.com  Thu Dec 21 18:27:41 2023
From: boy.wu at mediatek.com (boy.wu)
Date: Fri, 22 Dec 2023 10:27:41 +0800
Subject: [PATCH] arm: kasan: clear stale stack poison
Message-ID: <20231222022741.8223-1-boy.wu@mediatek.com>

From: Boy Wu <boy.wu at mediatek.com>

We found below OOB crash:

[   33.452494] ==================================================================
[   33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
[   33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0
[   33.455515]
[   33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O       6.1.25-mainline #1
[   33.456880] Hardware name: Generic DT based system
[   33.457555]  unwind_backtrace from show_stack+0x18/0x1c
[   33.458326]  show_stack from dump_stack_lvl+0x40/0x4c
[   33.459072]  dump_stack_lvl from print_report+0x158/0x4a4
[   33.459863]  print_report from kasan_report+0x9c/0x148
[   33.460616]  kasan_report from kasan_check_range+0x94/0x1a0
[   33.461424]  kasan_check_range from memset+0x20/0x3c
[   33.462157]  memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
[   33.463064]  refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c
[   33.464181]  tick_nohz_idle_stop_tick from do_idle+0x264/0x354
[   33.465029]  do_idle from cpu_startup_entry+0x20/0x24
[   33.465769]  cpu_startup_entry from rest_init+0xf0/0xf4
[   33.466528]  rest_init from arch_post_acpi_subsys_init+0x0/0x18
[   33.467397]
[   33.467644] The buggy address belongs to stack of task swapper/0/0
[   33.468493]  and is located at offset 112 in frame:
[   33.469172]  refresh_cpu_vm_stats.constprop.0+0x0/0x2ec
[   33.469917]
[   33.470165] This frame has 2 objects:
[   33.470696]  [32, 76) 'global_zone_diff'
[   33.470729]  [112, 276) 'global_node_diff'
[   33.471294]
[   33.472095] The buggy address belongs to the physical page:
[   33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03
[   33.473944] flags: 0x1000(reserved|zone=0)
[   33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001
[   33.475656] raw: 00000000
[   33.476050] page dumped because: kasan: bad access detected
[   33.476816]
[   33.477061] Memory state around the buggy address:
[   33.477732]  c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   33.478630]  c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
[   33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1
[   33.480415]                                                ^
[   33.481195]  c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3
[   33.482088]  c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
[   33.482978] ==================================================================

We find the root cause of this OOB is that arm does not clear stale stack
poison in the case of cpuidle.

This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.

Signed-off-by: Boy Wu <boy.wu at mediatek.com>
---
 arch/arm/kernel/sleep.S | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index a86a1d4f3461..93afd1005b43 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -127,6 +127,10 @@ cpu_resume_after_mmu:
 	instr_sync
 #endif
 	bl	cpu_init		@ restore the und/abt/irq banked regs
+#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
+	mov	r0, sp
+	bl	kasan_unpoison_task_stack_below
+#endif
 	mov	r0, #0			@ return zero on success
 	ldmfd	sp!, {r4 - r11, pc}
 ENDPROC(cpu_resume_after_mmu)
-- 
2.18.0



From sfr at canb.auug.org.au  Thu Dec 21 18:49:14 2023
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 22 Dec 2023 13:49:14 +1100
Subject: linux-next: duplicate patch in the v4l-dvb tree
Message-ID: <20231222134914.74698b92@canb.auug.org.au>

Hi all,

The following commit is also in the arm-soc tree as a different commit
(but the same patch):

  a60577cef7de ("media: dt-bindings: mediatek: Add phandle to mediatek,scp on MDP3 RDMA")

This is commit

  a17cf4c6de2d ("media: dt-bindings: mediatek: Add phandle to mediatek,scp on MDP3 RDMA")

in the arm-soc tree.

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/5bdd8c91/attachment-0001.sig>

From sfr at canb.auug.org.au  Thu Dec 21 19:16:40 2023
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 22 Dec 2023 14:16:40 +1100
Subject: linux-next: duplicate patch in the thermal tree
Message-ID: <20231222141640.5d21be60@canb.auug.org.au>

Hi all,

The following commit is also in the arm-soc tree as a different commit
(but the same patchs):

  4d8d0704a46e ("dt-bindings: thermal: convert Mediatek Thermal to the json-schema")

This is commit

  10bbf22de75a ("dt-bindings: thermal: convert Mediatek Thermal to the json-schema")

in the arm-soc tree.

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/0452fac5/attachment.sig>

From peter.chen at kernel.org  Thu Dec 21 19:40:26 2023
From: peter.chen at kernel.org (Peter Chen)
Date: Fri, 22 Dec 2023 11:40:26 +0800
Subject: [PATCH v2 1/3] usb: chipidea: ci_hdrc_imx: add wakeup clock and
 keep it always on
In-Reply-To: <20231218061420.3460145-1-xu.yang_2@nxp.com>
References: <20231218061420.3460145-1-xu.yang_2@nxp.com>
Message-ID: <20231222034026.GA1951375@nchen-desktop>

On 23-12-18 14:14:18, Xu Yang wrote:
> Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
> on without usb driver intervention. And some may need driver to handle
> this clock. For now only i.MX93 needs this wakeup clock. This patch will
> get wakeup clock and keep it always on to make controller work properly.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> 
> ---
> Changes in v2:
>  - modify commit msg to make it clear
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> index e28bb2f2612d..4330be8240ff 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -96,6 +96,7 @@ struct ci_hdrc_imx_data {
>  	struct usb_phy *phy;
>  	struct platform_device *ci_pdev;
>  	struct clk *clk;
> +	struct clk *clk_wakeup;
>  	struct imx_usbmisc_data *usbmisc_data;
>  	bool supports_runtime_pm;
>  	bool override_phy_control;
> @@ -199,7 +200,7 @@ static int imx_get_clks(struct device *dev)
>  
>  	data->clk_ipg = devm_clk_get(dev, "ipg");
>  	if (IS_ERR(data->clk_ipg)) {
> -		/* If the platform only needs one clocks */
> +		/* If the platform only needs one primary clock */
>  		data->clk = devm_clk_get(dev, NULL);
>  		if (IS_ERR(data->clk)) {
>  			ret = PTR_ERR(data->clk);
> @@ -208,6 +209,18 @@ static int imx_get_clks(struct device *dev)
>  				PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
>  			return ret;
>  		}
> +		/* Get wakeup clock. Not all of the platforms need to
> +		 * handle this clock. So make it optional.
> +		 */
> +		data->clk_wakeup = devm_clk_get_optional(dev,
> +							 "usb_wakeup_clk");
> +		if (IS_ERR(data->clk_wakeup)) {
> +			ret = PTR_ERR(data->clk_wakeup);
> +			dev_err(dev,
> +				"Failed to get wakeup clk, err=%ld\n",
> +				PTR_ERR(data->clk_wakeup));
> +			return ret;
> +		}
>  		return ret;
>  	}
>  
> @@ -423,6 +436,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto disable_hsic_regulator;
>  
> +	ret = clk_prepare_enable(data->clk_wakeup);
> +	if (ret)
> +		goto err_wakeup_clk;
> +

Better add at function imx_prepare_enable_clks()

>  	data->phy = devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0);
>  	if (IS_ERR(data->phy)) {
>  		ret = PTR_ERR(data->phy);
> @@ -504,6 +521,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  disable_device:
>  	ci_hdrc_remove_device(data->ci_pdev);
>  err_clk:
> +	clk_disable_unprepare(data->clk_wakeup);
> +err_wakeup_clk:


Better add clk_disable_unprepare for wakeup clk at function
imx_disable_unprepare_clks();

Peter

>  	imx_disable_unprepare_clks(dev);
>  disable_hsic_regulator:
>  	if (data->hsic_pad_regulator)
> @@ -530,6 +549,7 @@ static void ci_hdrc_imx_remove(struct platform_device *pdev)
>  		usb_phy_shutdown(data->phy);
>  	if (data->ci_pdev) {
>  		imx_disable_unprepare_clks(&pdev->dev);
> +		clk_disable_unprepare(data->clk_wakeup);
>  		if (data->plat_data->flags & CI_HDRC_PMQOS)
>  			cpu_latency_qos_remove_request(&data->pm_qos_req);
>  		if (data->hsic_pad_regulator)
> -- 
> 2.34.1
> 
> 

-- 

Thanks,
Peter Chen


From peter.chen at kernel.org  Thu Dec 21 19:41:55 2023
From: peter.chen at kernel.org (Peter Chen)
Date: Fri, 22 Dec 2023 11:41:55 +0800
Subject: [PATCH v2 2/3] usb: chipidea: wait controller resume finished
 for wakeup irq
In-Reply-To: <20231218061420.3460145-2-xu.yang_2@nxp.com>
References: <20231218061420.3460145-1-xu.yang_2@nxp.com>
 <20231218061420.3460145-2-xu.yang_2@nxp.com>
Message-ID: <20231222034155.GB1951375@nchen-desktop>

On 23-12-18 14:14:19, Xu Yang wrote:
> After the chipidea driver introduce extcon for id and vbus, it's able
> to wakeup from another irq source, in case the system with extcon ID
> cable, wakeup from usb ID cable and device removal, the usb device
> disconnect irq may come firstly before the extcon notifier while system
> resume, so we will get 2 "wakeup" irq, one for usb device disconnect;
> and one for extcon ID cable change(real wakeup event), current driver
> treat them as 2 successive wakeup irq so can't handle it correctly, then
> finally the usb irq can't be enabled. This patch adds a check to bypass
> further usb events before controller resume finished to fix it.
> 
> Fixes: 1f874edcb731 ("usb: chipidea: add runtime power management support")
> cc: <stable at vger.kernel.org>
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> Signed-off-by: Li Jun <jun.li at nxp.com>

Acked-by: Peter Chen <peter.chen at kernel.org>

> 
> ---
> Changes in v2:
>  - no changes
> ---
>  drivers/usb/chipidea/core.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 7ac39a281b8c..85e9c3ab66e9 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -523,6 +523,13 @@ static irqreturn_t ci_irq_handler(int irq, void *data)
>  	u32 otgsc = 0;
>  
>  	if (ci->in_lpm) {
> +		/*
> +		 * If we already have a wakeup irq pending there,
> +		 * let's just return to wait resume finished firstly.
> +		 */
> +		if (ci->wakeup_int)
> +			return IRQ_HANDLED;
> +
>  		disable_irq_nosync(irq);
>  		ci->wakeup_int = true;
>  		pm_runtime_get(ci->dev);
> -- 
> 2.34.1
> 

-- 

Thanks,
Peter Chen


From quic_bjorande at quicinc.com  Thu Dec 21 20:39:25 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:39:25 -0800
Subject: [PATCH v2 4/8] soc: qcom: rpmhpd: Drop SA8540P gfx.lvl
In-Reply-To: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v2-4-4763246b72c0@quicinc.com>

On SA8295P and SA8540P gfx.lvl is not provdied by rpmh, but rather is
handled by an external regulator (max20411). Drop gfx.lvl from the list
of power-domains exposed on this platform.

Fixes: f68f1cb3437d ("soc: qcom: rpmhpd: add sc8280xp & sa8540p rpmh power-domains")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 drivers/pmdomain/qcom/rpmhpd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
index 3078896b1300..27a73ff72614 100644
--- a/drivers/pmdomain/qcom/rpmhpd.c
+++ b/drivers/pmdomain/qcom/rpmhpd.c
@@ -217,7 +217,6 @@ static struct rpmhpd *sa8540p_rpmhpds[] = {
 	[SC8280XP_CX] = &cx,
 	[SC8280XP_CX_AO] = &cx_ao,
 	[SC8280XP_EBI] = &ebi,
-	[SC8280XP_GFX] = &gfx,
 	[SC8280XP_LCX] = &lcx,
 	[SC8280XP_LMX] = &lmx,
 	[SC8280XP_MMCX] = &mmcx,

-- 
2.25.1



From quic_bjorande at quicinc.com  Thu Dec 21 20:39:21 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:39:21 -0800
Subject: [PATCH v2 0/8] arm64: dts: qcom: sa8295p: Enable GPU
Message-ID: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>

Due to the different PMIC configuration found in the SA8295P platform,
compared to SC8280XP, the VDD_GFX pads are supplied by an dedicated
MAX20411 LDO.

Support for expressing the regulator supply is added to the binding, the
support for enabling the parent supply for GX is added, the missing
gfx.lvl power-domain is dropped, and the DeviceTree is wired up to
enable the GPU in this configuration.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
Changes in v2:
- Made gpucc binding accept either power-domain or vdd-gfx-supply
- Updated comment in gdsc_gx_do_nothing_enable()
- Added a comment for the /delete-property/ power-domains
- Fixed node and property sort order in dts
- Switched zap firmware to use mbn file
- Link to v1: https://lore.kernel.org/r/20231220-sa8295p-gpu-v1-0-d8cdf2257f97 at quicinc.com

---
Bjorn Andersson (8):
      dt-bindings: clock: qcom: Allow VDD_GFX supply to GX
      clk: qcom: gdsc: Enable supply reglator in GPU GX handler
      clk: qcom: gpucc-sc8280xp: Add external supply for GX gdsc
      soc: qcom: rpmhpd: Drop SA8540P gfx.lvl
      arm64: dts: qcom: sa8540p: Drop gfx.lvl as power-domain for gpucc
      arm64: dts: qcom: sa8295p-adp: add max20411
      arm64: dts: qcom: sa8295p-adp: Enable GPU
      arm64: defconfig: Enable MAX20411 regulator driver

 .../devicetree/bindings/clock/qcom,gpucc.yaml      | 16 +++++
 arch/arm64/boot/dts/qcom/sa8295p-adp.dts           | 69 ++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sa8540p.dtsi              |  3 +
 arch/arm64/configs/defconfig                       |  1 +
 drivers/clk/qcom/gdsc.c                            | 12 +++-
 drivers/clk/qcom/gpucc-sc8280xp.c                  |  1 +
 drivers/pmdomain/qcom/rpmhpd.c                     |  1 -
 7 files changed, 100 insertions(+), 3 deletions(-)
---
base-commit: 20d857259d7d10cd0d5e8b60608455986167cfad
change-id: 20231220-sa8295p-gpu-51c5f343e3ec

Best regards,
-- 
Bjorn Andersson <quic_bjorande at quicinc.com>



From quic_bjorande at quicinc.com  Thu Dec 21 20:39:26 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:39:26 -0800
Subject: [PATCH v2 5/8] arm64: dts: qcom: sa8540p: Drop gfx.lvl as
 power-domain for gpucc
In-Reply-To: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v2-5-4763246b72c0@quicinc.com>

The SA8295P and SA8540P uses an external regulator (max20411), and
gfx.lvl is not provided by rpmh. Drop the power-domains property of the
gpucc node to reflect this.

Fixes: eec51ab2fd6f ("arm64: dts: qcom: sc8280xp: Add GPU related nodes")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 arch/arm64/boot/dts/qcom/sa8540p.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8540p.dtsi b/arch/arm64/boot/dts/qcom/sa8540p.dtsi
index 96b2c59ad02b..23888029cc11 100644
--- a/arch/arm64/boot/dts/qcom/sa8540p.dtsi
+++ b/arch/arm64/boot/dts/qcom/sa8540p.dtsi
@@ -168,6 +168,9 @@ opp-2592000000 {
 };
 
 &gpucc {
+	/* SA8295P and SA8540P doesn't provide gfx.lvl */
+	/delete-property/ power-domains;
+
 	status = "disabled";
 };
 

-- 
2.25.1



From quic_bjorande at quicinc.com  Thu Dec 21 20:39:29 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:39:29 -0800
Subject: [PATCH v2 8/8] arm64: defconfig: Enable MAX20411 regulator driver
In-Reply-To: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v2-8-4763246b72c0@quicinc.com>

The Qualcomm SA8295P ADP board uses a max20411 to power the GPU
subsystem.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ef1061089548..ec94a0c4fd03 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -751,6 +751,7 @@ CONFIG_REGULATOR_HI6421V530=y
 CONFIG_REGULATOR_HI655X=y
 CONFIG_REGULATOR_MAX77620=y
 CONFIG_REGULATOR_MAX8973=y
+CONFIG_REGULATOR_MAX20411=m
 CONFIG_REGULATOR_MP8859=y
 CONFIG_REGULATOR_MT6315=m
 CONFIG_REGULATOR_MT6357=y

-- 
2.25.1



From quic_bjorande at quicinc.com  Thu Dec 21 20:39:22 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:39:22 -0800
Subject: [PATCH v2 1/8] dt-bindings: clock: qcom: Allow VDD_GFX supply to
 GX
In-Reply-To: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v2-1-4763246b72c0@quicinc.com>

In some designs the SoC's VDD_GFX pads are supplied by an external
regulator, rather than a power-domain. Allow this to be described in the
GPU clock controller binding.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index f369fa34e00c..c0dd24c9dcb3 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -53,6 +53,9 @@ properties:
   power-domains:
     maxItems: 1
 
+  vdd-gfx-supply:
+    description: Regulator supply for the VDD_GFX pads
+
   '#clock-cells':
     const: 1
 
@@ -74,6 +77,19 @@ required:
   - '#reset-cells'
   - '#power-domain-cells'
 
+# Allow either power-domains or vdd-gfx-supply, not both
+oneOf:
+  - required:
+      - power-domains
+  - required:
+      - vdd-gfx-supply
+  - not:
+      anyOf:
+        - required:
+            - power-domains
+        - required:
+            - vdd-gfx-supply
+
 additionalProperties: false
 
 examples:

-- 
2.25.1



From quic_bjorande at quicinc.com  Thu Dec 21 20:39:23 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:39:23 -0800
Subject: [PATCH v2 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX
 handler
In-Reply-To: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v2-2-4763246b72c0@quicinc.com>

The GX GDSC is modelled to aid the GMU in powering down the GPU in the
event that the GPU crashes, so that it can be restarted again. But in
the event that the power-domain is supplied through a dedicated
regulator (in contrast to being a subdomin of another power-domain),
something needs to turn that regulator on, both to make sure things are
powered and to match the operation in gdsc_disable().

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 drivers/clk/qcom/gdsc.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index 5358e28122ab..e7a4068b9f39 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -557,7 +557,15 @@ void gdsc_unregister(struct gdsc_desc *desc)
  */
 int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain)
 {
-	/* Do nothing but give genpd the impression that we were successful */
-	return 0;
+	struct gdsc *sc = domain_to_gdsc(domain);
+	int ret = 0;
+
+	/* Enable the parent supply, when controlled through the regulator framework. */
+	if (sc->rsupply)
+		ret = regulator_enable(sc->rsupply);
+
+	/* Do nothing with the GDSC itself */
+
+	return ret;
 }
 EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);

-- 
2.25.1



From quic_bjorande at quicinc.com  Thu Dec 21 20:39:28 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:39:28 -0800
Subject: [PATCH v2 7/8] arm64: dts: qcom: sa8295p-adp: Enable GPU
In-Reply-To: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v2-7-4763246b72c0@quicinc.com>

With the necessary support in place for supplying VDD_GFX from the
MAX20411 regulator, enable the GPU clock controller, GMU, Adreno SMMU
and the GPU on the SA8295P ADP.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
index 14327c697116..304c8d79bd31 100644
--- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
@@ -108,6 +108,13 @@ edp3_connector_in: endpoint {
 			};
 		};
 	};
+
+	reserved-memory {
+		gpu_mem: gpu-mem at 8bf00000 {
+			reg = <0 0x8bf00000 0 0x2000>;
+			no-map;
+		};
+	};
 };
 
 &apps_rsc {
@@ -286,6 +293,28 @@ vdd_gfx: regulator at 39 {
 	};
 };
 
+&gpucc {
+	vdd-gfx-supply = <&vdd_gfx>;
+	status = "okay";
+};
+
+&gmu {
+	status = "okay";
+};
+
+&gpu {
+	status = "okay";
+
+	zap-shader {
+		memory-region = <&gpu_mem>;
+		firmware-name = "qcom/sa8295p/a690_zap.mbn";
+	};
+};
+
+&gpu_smmu {
+	status = "okay";
+};
+
 &mdss0 {
 	status = "okay";
 };

-- 
2.25.1



From quic_bjorande at quicinc.com  Thu Dec 21 20:39:24 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:39:24 -0800
Subject: [PATCH v2 3/8] clk: qcom: gpucc-sc8280xp: Add external supply for
 GX gdsc
In-Reply-To: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v2-3-4763246b72c0@quicinc.com>

On SA8295P and SA8540P the GFX rail is powered by a dedicated external
regulator, instead of the rpmh-controlled "gfx.lvl".

Define the "vdd-gfx" as the supply regulator for the GDSC, to cause the
gdsc logic to look for, and control, this external power supply.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 drivers/clk/qcom/gpucc-sc8280xp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/gpucc-sc8280xp.c b/drivers/clk/qcom/gpucc-sc8280xp.c
index 8e147ee294ee..e2b3bc000c71 100644
--- a/drivers/clk/qcom/gpucc-sc8280xp.c
+++ b/drivers/clk/qcom/gpucc-sc8280xp.c
@@ -399,6 +399,7 @@ static struct gdsc gx_gdsc = {
 	},
 	.pwrsts = PWRSTS_OFF_ON,
 	.flags = CLAMP_IO | RETAIN_FF_ENABLE,
+	.supply = "vdd-gfx",
 };
 
 static struct gdsc *gpu_cc_sc8280xp_gdscs[] = {

-- 
2.25.1



From quic_bjorande at quicinc.com  Thu Dec 21 20:39:27 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:39:27 -0800
Subject: [PATCH v2 6/8] arm64: dts: qcom: sa8295p-adp: add max20411
In-Reply-To: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
Message-ID: <20231220-sa8295p-gpu-v2-6-4763246b72c0@quicinc.com>

From: Bjorn Andersson <andersson at kernel.org>

The SA8295P ADP has a MAX20411 LDO regulator on I2C 12, supplying the
VDD_GFX pads. Enable the bus and add the maxim,max20411 device on the
bus.

Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
---
 arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 40 ++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
index fd253942e5e5..14327c697116 100644
--- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
@@ -266,6 +266,26 @@ &dispcc1 {
 	status = "okay";
 };
 
+&i2c12 {
+	pinctrl-0 = <&qup1_i2c4_state>;
+	pinctrl-names = "default";
+
+	status = "okay";
+
+	vdd_gfx: regulator at 39 {
+		compatible = "maxim,max20411";
+		reg = <0x39>;
+
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <800000>;
+
+		enable-gpios = <&pmm8540a_gpios 2 GPIO_ACTIVE_HIGH>;
+
+		pinctrl-0 = <&max20411_en>;
+		pinctrl-names = "default";
+	};
+};
+
 &mdss0 {
 	status = "okay";
 };
@@ -476,6 +496,10 @@ &pcie4_phy {
 	status = "okay";
 };
 
+&qup1 {
+	status = "okay";
+};
+
 &qup2 {
 	status = "okay";
 };
@@ -636,6 +660,14 @@ &xo_board_clk {
 
 /* PINCTRL */
 
+&pmm8540a_gpios {
+	max20411_en: max20411-en-state {
+		pins = "gpio2";
+		function = "normal";
+		output-enable;
+	};
+};
+
 &tlmm {
 	pcie2a_default: pcie2a-default-state {
 		clkreq-n-pins {
@@ -728,4 +760,12 @@ wake-n-pins {
 			bias-pull-up;
 		};
 	};
+
+	qup1_i2c4_state: qup1-i2c4-state {
+		pins = "gpio0", "gpio1";
+		function = "qup12";
+
+		drive-strength = <2>;
+		bias-pull-up;
+	};
 };

-- 
2.25.1



From herbert at gondor.apana.org.au  Thu Dec 21 20:42:06 2023
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 22 Dec 2023 12:42:06 +0800
Subject: [PATCH] crypto: stm32/crc32 - fix parsing list of devices
In-Reply-To: <20231215111724.864051-1-thomas.bourgoin@foss.st.com>
References: <20231215111724.864051-1-thomas.bourgoin@foss.st.com>
Message-ID: <ZYUTnm83NdBC0+Rb@gondor.apana.org.au>

On Fri, Dec 15, 2023 at 12:17:24PM +0100, Thomas Bourgoin wrote:
> smatch warnings:
> drivers/crypto/stm32/stm32-crc32.c:108 stm32_crc_get_next_crc() warn:
> can 'crc' even be NULL?
> 
> Use list_first_entry_or_null instead of list_first_entry to retrieve
> the first device registered.
> The function list_first_entry always return a non NULL pointer even if
> the list is empty. Hence checking if the pointer returned is NULL does
> not tell if the list is empty or not.
> 
> Reported-by: kernel test robot <lkp at intel.com>
> Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp at intel.com/
> Reported-by: Dan Carpenter <error27 at gmail.com>
> Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp at intel.com/
> Signed-off-by: Thomas Bourgoin <thomas.bourgoin at foss.st.com>
> ---
>  drivers/crypto/stm32/stm32-crc32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From quic_bjorande at quicinc.com  Thu Dec 21 20:47:16 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Thu, 21 Dec 2023 20:47:16 -0800
Subject: [PATCH] arm64: defconfig: Enable Qualcomm SC8280XP camera clock
 controller
Message-ID: <20231221-enable-sc8280xp-camcc-v1-1-2249581dd538@quicinc.com>

With the camera clock controller added to the DeviceTree of SC8280XP the
interconnect providers no longer reaches sync_state, resulting in a
noticeable reduction in battery life.

Enable the camera clock controller (as a module) to avoid this, and
hopefully soon provide some level of camera support.

Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ef1061089548..e5ce6d08006e 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1256,6 +1256,7 @@ CONFIG_QCM_GCC_2290=y
 CONFIG_QCM_DISPCC_2290=m
 CONFIG_QCS_GCC_404=y
 CONFIG_SA_GCC_8775P=y
+CONFIG_SC_CAMCC_8280XP=m
 CONFIG_SC_DISPCC_8280XP=m
 CONFIG_SA_GPUCC_8775P=m
 CONFIG_SC_GCC_7180=y

---
base-commit: 20d857259d7d10cd0d5e8b60608455986167cfad
change-id: 20231221-enable-sc8280xp-camcc-969b2cf2e4d7

Best regards,
-- 
Bjorn Andersson <quic_bjorande at quicinc.com>



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:26 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:26 +0800
Subject: [PATCH v3 7/9] mailbox: mediatek: Move reuseable definition to header for secure driver
In-Reply-To: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
Message-ID: <20231222045228.27826-8-jason-jh.lin@mediatek.com>

To support CMDQ secure driver, move some reuseable definition to header.
- define: e.g. CMDQ_GCE_NUM_MAX, CMDQ_THR_BASE, CMDQ_THR_SIZE.
- struct: e.g. cmdq_thread, cmdq, cmdq_task.
- include: e.g. <linux/clk.h>.

Add "#include <linux/mailbox_controller.h>" for the function that takes
"struct mbox_chan * chan" as a parameter. That may occur a build error
if secure driver header includes the mtk-cmdq-mailbox.h.
- function: e.g. cmdq_get_shift_pa(struct mbox_chan *chan).

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/mailbox/mtk-cmdq-mailbox.c       | 30 ---------------------
 include/linux/mailbox/mtk-cmdq-mailbox.h | 33 ++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 30 deletions(-)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 5390b6488ebc..04321f7e10c3 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -3,7 +3,6 @@
 // Copyright (c) 2018 MediaTek Inc.
 
 #include <linux/bitops.h>
-#include <linux/clk.h>
 #include <linux/clk-provider.h>
 #include <linux/dma-mapping.h>
 #include <linux/errno.h>
@@ -22,13 +21,10 @@
 
 #define CMDQ_OP_CODE_MASK		(0xff << CMDQ_OP_CODE_SHIFT)
 #define CMDQ_NUM_CMD(t)			(t->cmd_buf_size / CMDQ_INST_SIZE)
-#define CMDQ_GCE_NUM_MAX		(2)
 
 #define CMDQ_CURR_IRQ_STATUS		0x10
 #define CMDQ_SYNC_TOKEN_UPDATE		0x68
 #define CMDQ_THR_SLOT_CYCLES		0x30
-#define CMDQ_THR_BASE			0x100
-#define CMDQ_THR_SIZE			0x80
 #define CMDQ_THR_WARM_RESET		0x00
 #define CMDQ_THR_ENABLE_TASK		0x04
 #define CMDQ_THR_SUSPEND_TASK		0x08
@@ -59,32 +55,6 @@
 #define CMDQ_JUMP_BY_OFFSET		0x10000000
 #define CMDQ_JUMP_BY_PA			0x10000001
 
-struct cmdq_thread {
-	struct mbox_chan	*chan;
-	void __iomem		*base;
-	struct list_head	task_busy_list;
-	u32			priority;
-};
-
-struct cmdq_task {
-	struct cmdq		*cmdq;
-	struct list_head	list_entry;
-	dma_addr_t		pa_base;
-	struct cmdq_thread	*thread;
-	struct cmdq_pkt		*pkt; /* the packet sent from mailbox client */
-};
-
-struct cmdq {
-	struct mbox_controller	mbox;
-	void __iomem		*base;
-	int			irq;
-	u32			irq_mask;
-	const struct gce_plat	*pdata;
-	struct cmdq_thread	*thread;
-	struct clk_bulk_data	clocks[CMDQ_GCE_NUM_MAX];
-	bool			suspended;
-};
-
 struct gce_plat {
 	u32 thread_nr;
 	u8 shift;
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index f78a08e7c6ed..43eae45a08c9 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -7,10 +7,17 @@
 #ifndef __MTK_CMDQ_MAILBOX_H__
 #define __MTK_CMDQ_MAILBOX_H__
 
+#include <linux/clk.h>
+#include <linux/mailbox_controller.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/types.h>
 
+#define CMDQ_GCE_NUM_MAX		2
+
+#define CMDQ_THR_BASE			0x100
+#define CMDQ_THR_SIZE			0x80
+
 #define CMDQ_INST_SIZE			8 /* instruction is 64-bit */
 #define CMDQ_SUBSYS_SHIFT		16
 #define CMDQ_OP_CODE_SHIFT		24
@@ -79,6 +86,32 @@ struct cmdq_pkt {
 	bool			loop;
 };
 
+struct cmdq_thread {
+	struct mbox_chan	*chan;
+	void __iomem		*base;
+	struct list_head	task_busy_list;
+	u32			priority;
+};
+
+struct cmdq {
+	struct mbox_controller	mbox;
+	void __iomem		*base;
+	int			irq;
+	u32			irq_mask;
+	const struct gce_plat	*pdata;
+	struct cmdq_thread	*thread;
+	struct clk_bulk_data	clocks[CMDQ_GCE_NUM_MAX];
+	bool			suspended;
+};
+
+struct cmdq_task {
+	struct cmdq		*cmdq;
+	struct list_head	list_entry;
+	dma_addr_t		pa_base;
+	struct cmdq_thread	*thread;
+	struct cmdq_pkt		*pkt; /* the packet sent from mailbox client */
+};
+
 u8 cmdq_get_shift_pa(struct mbox_chan *chan);
 
 #endif /* __MTK_CMDQ_MAILBOX_H__ */
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:28 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:28 +0800
Subject: [PATCH v3 9/9] mailbox: mediatek: Add secure CMDQ driver support for CMDQ driver
In-Reply-To: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
Message-ID: <20231222045228.27826-10-jason-jh.lin@mediatek.com>

CMDQ driver will probe a secure CMDQ driver when has_sec flag
in platform data is true and its device node in dts has defined a
event id of CMDQ_SYNC_TOKEN_SEC_EOF.

Secure CMDQ driver support on mt8188 and mt8195 currently.
So add a has_secure flag to their driver data to probe it.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/mailbox/mtk-cmdq-mailbox.c | 38 ++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 04321f7e10c3..79167696c1eb 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -15,6 +15,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/mailbox_controller.h>
 #include <linux/mailbox/mtk-cmdq-mailbox.h>
+#include <linux/mailbox/mtk-cmdq-sec-mailbox.h>
 #include <linux/of.h>
 
 #define CMDQ_MBOX_AUTOSUSPEND_DELAY_MS	100
@@ -60,6 +61,9 @@ struct gce_plat {
 	u8 shift;
 	bool control_by_sw;
 	bool sw_ddr_en;
+	bool has_secure;
+	u32 secure_thread_nr;
+	u32 secure_thread_min;
 	u32 gce_num;
 };
 
@@ -570,6 +574,7 @@ static int cmdq_probe(struct platform_device *pdev)
 	int alias_id = 0;
 	static const char * const clk_name = "gce";
 	static const char * const clk_names[] = { "gce0", "gce1" };
+	u32 hwid = 0;
 
 	cmdq = devm_kzalloc(dev, sizeof(*cmdq), GFP_KERNEL);
 	if (!cmdq)
@@ -595,6 +600,8 @@ static int cmdq_probe(struct platform_device *pdev)
 		dev, cmdq->base, cmdq->irq);
 
 	if (cmdq->pdata->gce_num > 1) {
+		hwid = of_alias_get_id(dev->of_node, clk_name);
+
 		for_each_child_of_node(phandle->parent, node) {
 			alias_id = of_alias_get_id(node, clk_name);
 			if (alias_id >= 0 && alias_id < cmdq->pdata->gce_num) {
@@ -677,6 +684,31 @@ static int cmdq_probe(struct platform_device *pdev)
 	pm_runtime_set_autosuspend_delay(dev, CMDQ_MBOX_AUTOSUSPEND_DELAY_MS);
 	pm_runtime_use_autosuspend(dev);
 
+	if (cmdq->pdata->has_secure) {
+		struct platform_device *mtk_cmdq_sec;
+		static struct gce_sec_plat sec_plat = {0};
+
+		if (of_property_read_u32_index(dev->of_node, "mediatek,gce-events", 0,
+					       &sec_plat.cmdq_event) == 0) {
+			sec_plat.gce_dev = dev;
+			sec_plat.hwid = hwid;
+			sec_plat.gce_num = cmdq->pdata->gce_num;
+			sec_plat.clocks = cmdq->clocks;
+			sec_plat.thread_nr = cmdq->pdata->thread_nr;
+			sec_plat.secure_thread_nr = cmdq->pdata->secure_thread_nr;
+			sec_plat.secure_thread_min = cmdq->pdata->secure_thread_min;
+
+			mtk_cmdq_sec = platform_device_register_data(dev, "mtk-cmdq-sec",
+								     PLATFORM_DEVID_AUTO,
+								     &sec_plat,
+								     sizeof(sec_plat));
+			if (IS_ERR(mtk_cmdq_sec)) {
+				dev_err(dev, "failed to register platform_device mtk-cmdq-sec\n");
+				return PTR_ERR(mtk_cmdq_sec);
+			}
+		}
+	}
+
 	return 0;
 }
 
@@ -720,6 +752,9 @@ static const struct gce_plat gce_plat_mt8188 = {
 	.thread_nr = 32,
 	.shift = 3,
 	.control_by_sw = true,
+	.has_secure = true,
+	.secure_thread_nr = 2,
+	.secure_thread_min = 8,
 	.gce_num = 2
 };
 
@@ -734,6 +769,9 @@ static const struct gce_plat gce_plat_mt8195 = {
 	.thread_nr = 24,
 	.shift = 3,
 	.control_by_sw = true,
+	.has_secure = true,
+	.secure_thread_nr = 2,
+	.secure_thread_min = 8,
 	.gce_num = 2
 };
 
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:22 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:22 +0800
Subject: [PATCH v3 3/9] soc: mediatek: cmdq: Add cmdq_pkt_logic_command to support math operation
In-Reply-To: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
Message-ID: <20231222045228.27826-4-jason-jh.lin@mediatek.com>

Add cmdq_pkt_logic_command to support math operation.

cmdq_pkt_logic_command can append logic command to the CMDQ packet,
ask GCE to execute a arithmetic calculate instruction,
such as add, subtract, multiply, AND, OR and NOT, etc.

Note that all arithmetic instructions are unsigned calculations.
If there are any overflows, GCE will sent the invalid IRQ to notify
CMDQ driver.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/soc/mediatek/mtk-cmdq-helper.c | 36 ++++++++++++++++++++++
 include/linux/soc/mediatek/mtk-cmdq.h  | 42 ++++++++++++++++++++++++++
 2 files changed, 78 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index b0cd071c4719..60f8ecbab5e7 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -13,9 +13,18 @@
 #define CMDQ_WRITE_ENABLE_MASK	BIT(0)
 #define CMDQ_POLL_ENABLE_MASK	BIT(0)
 #define CMDQ_EOC_IRQ_EN		BIT(0)
+#define CMDQ_IMMEDIATE_VALUE	0
 #define CMDQ_REG_TYPE		1
 #define CMDQ_JUMP_RELATIVE	1
 
+#define CMDQ_OPERAND_GET_IDX_VALUE(operand) \
+	({ \
+		struct cmdq_operand *op = operand; \
+		op->reg ? op->idx : op->value; \
+	})
+#define CMDQ_OPERAND_TYPE(operand) \
+	((operand)->reg ? CMDQ_REG_TYPE : CMDQ_IMMEDIATE_VALUE)
+
 struct cmdq_instruction {
 	union {
 		u32 value;
@@ -380,6 +389,33 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
 }
 EXPORT_SYMBOL(cmdq_pkt_poll_mask);
 
+int cmdq_pkt_logic_command(struct cmdq_pkt *pkt, u16 result_reg_idx,
+			   struct cmdq_operand *left_operand,
+			   enum cmdq_logic_op s_op,
+			   struct cmdq_operand *right_operand)
+{
+	struct cmdq_instruction inst = { {0} };
+	u32 left_idx_value;
+	u32 right_idx_value;
+
+	if (!left_operand || !right_operand || s_op >= CMDQ_LOGIC_MAX)
+		return -EINVAL;
+
+	left_idx_value = CMDQ_OPERAND_GET_IDX_VALUE(left_operand);
+	right_idx_value = CMDQ_OPERAND_GET_IDX_VALUE(right_operand);
+	inst.op = CMDQ_CODE_LOGIC;
+	inst.dst_t = CMDQ_REG_TYPE;
+	inst.src_t = CMDQ_OPERAND_TYPE(left_operand);
+	inst.arg_c_t = CMDQ_OPERAND_TYPE(right_operand);
+	inst.sop = s_op;
+	inst.arg_c = right_idx_value;
+	inst.src_reg = left_idx_value;
+	inst.reg_dst = result_reg_idx;
+
+	return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_logic_command);
+
 int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
 {
 	struct cmdq_instruction inst = {};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index a253c001c861..73eadda1dd2d 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -26,6 +26,31 @@
 
 struct cmdq_pkt;
 
+enum cmdq_logic_op {
+	CMDQ_LOGIC_ASSIGN = 0,
+	CMDQ_LOGIC_ADD = 1,
+	CMDQ_LOGIC_SUBTRACT = 2,
+	CMDQ_LOGIC_MULTIPLY = 3,
+	CMDQ_LOGIC_XOR = 8,
+	CMDQ_LOGIC_NOT = 9,
+	CMDQ_LOGIC_OR = 10,
+	CMDQ_LOGIC_AND = 11,
+	CMDQ_LOGIC_LEFT_SHIFT = 12,
+	CMDQ_LOGIC_RIGHT_SHIFT = 13,
+	CMDQ_LOGIC_MAX,
+};
+
+struct cmdq_operand {
+	/* register type */
+	bool reg;
+	union {
+		/* index */
+		u16 idx;
+		/* value */
+		u16 value;
+	};
+};
+
 struct cmdq_client_reg {
 	u8 subsys;
 	u16 offset;
@@ -244,6 +269,23 @@ int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
 int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
 		       u16 offset, u32 value, u32 mask);
 
+/**
+ * cmdq_pkt_logic_command() - Append logic command to the CMDQ packet, ask GCE to
+ *		          execute an instruction that store the result of logic operation
+ *		          with left and right operand into result_reg_idx.
+ * @pkt:		the CMDQ packet
+ * @result_reg_idx:	SPR index that store operation result of left_operand and right_operand
+ * @left_operand:	left operand
+ * @s_op:		the logic operator enum
+ * @right_operand:	right operand
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_logic_command(struct cmdq_pkt *pkt, u16 result_reg_idx,
+			   struct cmdq_operand *left_operand,
+			   enum cmdq_logic_op s_op,
+			   struct cmdq_operand *right_operand);
+
 /**
  * cmdq_pkt_assign() - Append logic assign command to the CMDQ packet, ask GCE
  *		       to execute an instruction that set a constant value into
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:19 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:19 +0800
Subject: [PATCH v3 0/9] Add CMDQ secure driver for SVP
Message-ID: <20231222045228.27826-1-jason-jh.lin@mediatek.com>

From: Jason-jh Lin <jason-jh.lin at mediatek.corp-partner.google.com>

For the Secure Video Path (SVP) feature, inculding the memory stored
secure video content, the registers of display HW pipeline and the
HW configure operations are required to execute in the secure world.

So using a CMDQ secure driver to make all display HW registers
configuration secure DRAM access permision settings execute by GCE
secure thread in the secure world.

We are landing this feature on mt8188 and mt8195 currently.
---
Based on 2 series and 1 patch:
[1] Add CMDQ driver support for mt8188
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=810382
[2] Add mediatek,gce-events definition to mediatek,gce-mailbox bindings
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=810938
[3] soc: mediatek: Add register definitions for GCE
- https://patchwork.kernel.org/project/linux-mediatek/patch/20231017064717.21616-2-shawn.sung at mediatek.com/
---
Change in v3:
1. separate mt8188 driver porting patches to another series
2. separate adding 'mediatek,gce-events' event prop to another series
3. sepatate mailbox helper and controller driver modification to a
   single patch for adding looping thread
4. add kerneldoc for secure mailbox related definition
5. add moving reuseable definition patch before adding secure mailbox
   driver patch
6. adjust redundant logic in mtk-cmdq-sec-mailbox

Change in v2:

1. adjust dt-binding SW event define patch before the dt-binding patch using it
2. adjust dt-binding patch for secure cmdq driver
3. remove the redundant patches or merge the patches of modification for the same API

Jason-JH.Lin (9):
  dt-bindings: gce: mt8195: Add CMDQ_SYNC_TOKEN_SECURE_THR_EOF event id
  dt-bindings: mailbox: Add mboxes property for CMDQ secure driver
  soc: mediatek: cmdq: Add cmdq_pkt_logic_command to support math
    operation
  soc: mediatek: cmdq: Add cmdq_pkt_write_s_reg_value to support write
    value to reg
  mailbox: mtk-cmdq: Support GCE loop packets in interrupt handler
  soc: mediatek: cmdq: Add cmdq_pkt_finalize_loop for looping cmd with
    irq
  mailbox: mediatek: Move reuseable definition to header for secure
    driver
  mailbox: mediatek: Add CMDQ secure mailbox driver
  mailbox: mediatek: Add secure CMDQ driver support for CMDQ driver

 .../mailbox/mediatek,gce-mailbox.yaml         |    3 +
 drivers/mailbox/Makefile                      |    2 +-
 drivers/mailbox/mtk-cmdq-mailbox.c            |   79 +-
 drivers/mailbox/mtk-cmdq-sec-mailbox.c        | 1091 +++++++++++++++++
 drivers/mailbox/mtk-cmdq-sec-tee.c            |  165 +++
 drivers/soc/mediatek/mtk-cmdq-helper.c        |   72 ++
 include/dt-bindings/gce/mt8195-gce.h          |    6 +
 include/linux/mailbox/mtk-cmdq-mailbox.h      |   36 +
 .../linux/mailbox/mtk-cmdq-sec-iwc-common.h   |  385 ++++++
 include/linux/mailbox/mtk-cmdq-sec-mailbox.h  |  158 +++
 include/linux/mailbox/mtk-cmdq-sec-tee.h      |  105 ++
 include/linux/soc/mediatek/mtk-cmdq.h         |   61 +
 12 files changed, 2132 insertions(+), 31 deletions(-)
 create mode 100644 drivers/mailbox/mtk-cmdq-sec-mailbox.c
 create mode 100644 drivers/mailbox/mtk-cmdq-sec-tee.c
 create mode 100644 include/linux/mailbox/mtk-cmdq-sec-iwc-common.h
 create mode 100644 include/linux/mailbox/mtk-cmdq-sec-mailbox.h
 create mode 100644 include/linux/mailbox/mtk-cmdq-sec-tee.h

-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:21 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:21 +0800
Subject: [PATCH v3 2/9] dt-bindings: mailbox: Add mboxes property for CMDQ secure driver
In-Reply-To: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
Message-ID: <20231222045228.27826-3-jason-jh.lin@mediatek.com>

Add mboxes to define a GCE loopping thread as a secure irq handler.
This property is only required if CMDQ secure driver is supported.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 .../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml      | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
index e4da0a58c943..0c17e1be99c2 100644
--- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
@@ -56,6 +56,9 @@ properties:
       include/dt-bindings/gce/<chip>-gce.h of each chips.
     $ref: /schemas/types.yaml#/definitions/uint32-array
 
+  mboxes:
+    maxItems: 1
+
 required:
   - compatible
   - "#mbox-cells"
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:24 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:24 +0800
Subject: [PATCH v3 5/9] mailbox: mtk-cmdq: Support GCE loop packets in interrupt handler
In-Reply-To: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
Message-ID: <20231222045228.27826-6-jason-jh.lin@mediatek.com>

1. Add a loop flag for CMDQ packet struct.
CMDQ helper will use a loop flag to mark CMDQ packet as lopping command
and make current command buffer jumps to the beginning when GCE executes
to the end of command buffer.

2. Add a looping task handle flow in irq handler.
GCE irq occurs when GCE executes to the end of command(EOC) instruction.
If the CMDQ packet is a loopping command, GCE irq handler can not
delete the CMDQ task and disable the GCE thread.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/mailbox/mtk-cmdq-mailbox.c       | 11 +++++++++++
 include/linux/mailbox/mtk-cmdq-mailbox.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 27ff3a3ccf2f..5390b6488ebc 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -267,6 +267,17 @@ static void cmdq_thread_irq_handler(struct cmdq *cmdq,
 
 	curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR) << cmdq->pdata->shift;
 
+	task = list_first_entry_or_null(&thread->task_busy_list,
+					struct cmdq_task, list_entry);
+	if (task && task->pkt->loop) {
+		struct cmdq_cb_data data;
+
+		data.sta = err;
+		data.pkt = task->pkt;
+		mbox_chan_received_data(task->thread->chan, &data);
+		return;
+	}
+
 	list_for_each_entry_safe(task, tmp, &thread->task_busy_list,
 				 list_entry) {
 		task_end_pa = task->pa_base + task->pkt->cmd_buf_size;
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index a8f0070c7aa9..f78a08e7c6ed 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -76,6 +76,7 @@ struct cmdq_pkt {
 	size_t			cmd_buf_size; /* command occupied size */
 	size_t			buf_size; /* real buffer size */
 	void			*cl;
+	bool			loop;
 };
 
 u8 cmdq_get_shift_pa(struct mbox_chan *chan);
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:25 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:25 +0800
Subject: [PATCH v3 6/9] soc: mediatek: cmdq: Add cmdq_pkt_finalize_loop for looping cmd with irq
In-Reply-To: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
Message-ID: <20231222045228.27826-7-jason-jh.lin@mediatek.com>

Add cmdq_pkt_finalize_loop to CMDQ driver.

cmdq_pkt_finalize_loop appends end of command(EOC) instruction and
jump to start of command buffer instruction to make the command
buffer loopable.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/soc/mediatek/mtk-cmdq-helper.c | 23 +++++++++++++++++++++++
 include/linux/soc/mediatek/mtk-cmdq.h  |  8 ++++++++
 2 files changed, 31 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index dfef436d9b8a..b6ba8b5d0db7 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -475,6 +475,29 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
 }
 EXPORT_SYMBOL(cmdq_pkt_finalize);
 
+int cmdq_pkt_finalize_loop(struct cmdq_pkt *pkt)
+{
+	struct cmdq_instruction inst = { {0} };
+	int err;
+
+	/* insert EOC and generate IRQ for each command iteration */
+	inst.op = CMDQ_CODE_EOC;
+	inst.value = CMDQ_EOC_IRQ_EN;
+	err = cmdq_pkt_append_command(pkt, inst);
+	if (err < 0)
+		return err;
+
+	/* JUMP to start of pkt */
+	err = cmdq_pkt_jump(pkt, pkt->pa_base);
+	if (err < 0)
+		return err;
+
+	pkt->loop = true;
+
+	return err;
+}
+EXPORT_SYMBOL(cmdq_pkt_finalize_loop);
+
 int cmdq_pkt_flush_async(struct cmdq_pkt *pkt)
 {
 	int err;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index d1cd8108cad0..39994fc8a4f5 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -329,6 +329,14 @@ int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr);
  */
 int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
 
+/**
+ * cmdq_pkt_finalize_loop() - Append EOC and jump to start command.
+ * @pkt:	the CMDQ packet
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_finalize_loop(struct cmdq_pkt *pkt);
+
 /**
  * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
  *                          packet and call back at the end of done packet
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:23 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:23 +0800
Subject: [PATCH v3 4/9] soc: mediatek: cmdq: Add cmdq_pkt_write_s_reg_value to support write value to reg
In-Reply-To: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
Message-ID: <20231222045228.27826-5-jason-jh.lin@mediatek.com>

Add cmdq_pkt_write_s_reg_value to support write a value to a register.

It appends write_s command to the command buffer in a CMDQ packet,
ask GCE to excute a write instruction to write a value to a register
with low 16 bits physical address offset.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/soc/mediatek/mtk-cmdq-helper.c | 13 +++++++++++++
 include/linux/soc/mediatek/mtk-cmdq.h  | 11 +++++++++++
 2 files changed, 24 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 60f8ecbab5e7..dfef436d9b8a 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -287,6 +287,19 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
 }
 EXPORT_SYMBOL(cmdq_pkt_write_s_value);
 
+int cmdq_pkt_write_s_reg_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx, u32 value)
+{
+	struct cmdq_instruction inst = {};
+
+	inst.op = CMDQ_CODE_WRITE_S;
+	inst.dst_t = CMDQ_REG_TYPE;
+	inst.reg_dst = high_addr_reg_idx;
+	inst.value = value;
+
+	return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_reg_value);
+
 int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
 				u16 addr_low, u32 value, u32 mask)
 {
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 73eadda1dd2d..d1cd8108cad0 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -208,6 +208,17 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
 int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
 				u16 addr_low, u32 value, u32 mask);
 
+/**
+ * cmdq_pkt_write_s_reg_value() - append write_s command to the CMDQ packet which
+ *				  write value to a register with low address pa
+ * @pkt:	the CMDQ packet
+ * @high_addr_reg_idx:	internal register ID which contains high address of pa
+ * @value:	the specified target value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_reg_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx, u32 value);
+
 /**
  * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
  * @pkt:	the CMDQ packet
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:27 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:27 +0800
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
Message-ID: <20231222045228.27826-9-jason-jh.lin@mediatek.com>

To support secure video path feature, GCE have to read/write registgers
in the secure world. GCE will enable the secure access permission to the
HW who wants to access the secure content buffer.

Add CMDQ secure mailbox driver to make CMDQ client user is able to
sending their HW settings to the secure world. So that GCE can execute
all instructions to configure HW in the secure world.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/mailbox/Makefile                      |    2 +-
 drivers/mailbox/mtk-cmdq-sec-mailbox.c        | 1091 +++++++++++++++++
 drivers/mailbox/mtk-cmdq-sec-tee.c            |  165 +++
 include/linux/mailbox/mtk-cmdq-mailbox.h      |    2 +
 .../linux/mailbox/mtk-cmdq-sec-iwc-common.h   |  385 ++++++
 include/linux/mailbox/mtk-cmdq-sec-mailbox.h  |  158 +++
 include/linux/mailbox/mtk-cmdq-sec-tee.h      |  105 ++
 7 files changed, 1907 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mailbox/mtk-cmdq-sec-mailbox.c
 create mode 100644 drivers/mailbox/mtk-cmdq-sec-tee.c
 create mode 100644 include/linux/mailbox/mtk-cmdq-sec-iwc-common.h
 create mode 100644 include/linux/mailbox/mtk-cmdq-sec-mailbox.h
 create mode 100644 include/linux/mailbox/mtk-cmdq-sec-tee.h

diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index fc9376117111..82da2f4ee81a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -51,7 +51,7 @@ obj-$(CONFIG_STM32_IPCC) 	+= stm32-ipcc.o
 
 obj-$(CONFIG_MTK_ADSP_MBOX)	+= mtk-adsp-mailbox.o
 
-obj-$(CONFIG_MTK_CMDQ_MBOX)	+= mtk-cmdq-mailbox.o
+obj-$(CONFIG_MTK_CMDQ_MBOX)	+= mtk-cmdq-mailbox.o mtk-cmdq-sec-mailbox.o mtk-cmdq-sec-tee.o
 
 obj-$(CONFIG_ZYNQMP_IPI_MBOX)	+= zynqmp-ipi-mailbox.o
 
diff --git a/drivers/mailbox/mtk-cmdq-sec-mailbox.c b/drivers/mailbox/mtk-cmdq-sec-mailbox.c
new file mode 100644
index 000000000000..c08d42bcc06f
--- /dev/null
+++ b/drivers/mailbox/mtk-cmdq-sec-mailbox.c
@@ -0,0 +1,1091 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/mailbox_controller.h>
+#include <linux/of_platform.h>
+#include <linux/sched/clock.h>
+#include <linux/timer.h>
+
+#include <linux/mailbox/mtk-cmdq-sec-mailbox.h>
+
+#define CMDQ_THR_EXEC_CNT_PA		(0x28)
+
+#define CMDQ_TIMEOUT_DEFAULT		(1000)
+#define CMDQ_NO_TIMEOUT			(0xffffffff)
+#define ADDR_METADATA_MAX_COUNT_ORIGIN	(8)
+
+struct cmdq_sec_task {
+	struct cmdq_task		task;
+
+	/* secure CMDQ */
+	bool				reset_exec;
+	u32				wait_cookie;
+	u64				engine_flag;
+	s32				scenario;
+	u64				trigger;
+	u64				exec_time;
+	struct work_struct		exec_work;
+};
+
+struct cmdq_sec_thread {
+	struct cmdq_thread		thread;
+
+	/* secure CMDQ */
+	u32				idx;
+	struct timer_list		timeout;
+	u32				timeout_ms;
+	struct work_struct		timeout_work;
+	u32				wait_cookie;
+	u32				next_cookie;
+	u32				task_cnt;
+	struct workqueue_struct		*task_exec_wq;
+};
+
+/**
+ * struct cmdq_sec_context - CMDQ secure context structure.
+ * @tgid: tgid of process context.
+ * @state: state of inter-world communicatiom.
+ * @iwc_msg: buffer for inter-world communicatiom message.
+ * @tee_ctx: context structure for tee vendor.
+ *
+ * Note it is not global data, each process has its own cmdq_sec_context.
+ */
+struct cmdq_sec_context {
+	u32				tgid;
+	enum cmdq_iwc_state_enum	state;
+	void				*iwc_msg;
+	struct cmdq_sec_tee_context	tee_ctx;
+};
+
+/**
+ * struct cmdq_sec_shared_mem - shared memory between normal and secure world
+ * @va: virtual address of share memory.
+ * @pa: physical address of share memory.
+ * @size: size of share memory.
+ *
+ */
+struct cmdq_sec_shared_mem {
+	void				*va;
+	dma_addr_t			pa;
+	u32				size;
+};
+
+struct cmdq_sec {
+	struct mbox_controller		mbox;
+	const struct gce_sec_plat	*pdata;
+	void __iomem			*base;
+	phys_addr_t			base_pa;
+	struct cmdq_sec_thread		*sec_thread;
+	struct cmdq_client		*clt;
+	struct cmdq_pkt			*clt_pkt;
+
+	atomic_t			path_res;
+	struct cmdq_sec_shared_mem	*shared_mem;
+	struct cmdq_sec_context		*context;
+	struct iwc_cmdq_cancel_task_t	cancel;
+
+	struct workqueue_struct		*timeout_wq;
+	u64				sec_invoke;
+	u64				sec_done;
+
+	bool				notify_run;
+	struct work_struct		irq_notify_work;
+	struct workqueue_struct		*notify_wq;
+	/* mutex for cmdq_sec_thread excuting cmdq_sec_task */
+	struct mutex			exec_lock;
+};
+
+static atomic_t cmdq_path_res = ATOMIC_INIT(0);
+
+static int cmdq_sec_task_submit(struct cmdq_sec *cmdq, struct cmdq_sec_task *sec_task,
+				const u32 iwc_cmd, const u32 thrd_idx, void *data);
+
+int cmdq_sec_insert_backup_cookie(struct cmdq_pkt *pkt)
+{
+	struct cmdq_client *cl = (struct cmdq_client *)pkt->cl;
+	struct cmdq_thread *thread = ((struct mbox_chan *)(cl->chan))->con_priv;
+	struct cmdq_sec_thread *sec_thread = container_of(thread, struct cmdq_sec_thread, thread);
+	struct cmdq_sec *cmdq = container_of(thread->chan->mbox, struct cmdq_sec, mbox);
+	struct cmdq_operand left, right;
+	dma_addr_t addr;
+
+	if (!cmdq->shared_mem)
+		return -EFAULT;
+
+	dev_dbg(cmdq->mbox.dev, "%s %d: pkt:%p thread:%u gce:%#lx",
+		__func__, __LINE__, pkt, sec_thread->idx, (unsigned long)cmdq->base_pa);
+
+	addr = (u32)(cmdq->base_pa + CMDQ_THR_BASE +
+		CMDQ_THR_SIZE * sec_thread->idx + CMDQ_THR_EXEC_CNT_PA);
+
+	cmdq_pkt_assign(pkt, CMDQ_THR_SPR_IDX1, CMDQ_ADDR_HIGH(addr));
+	cmdq_pkt_read_s(pkt, CMDQ_THR_SPR_IDX1, CMDQ_ADDR_LOW(addr), CMDQ_THR_SPR_IDX1);
+
+	left.reg = true;
+	left.idx = CMDQ_THR_SPR_IDX1;
+	right.reg = false;
+	right.value = 1;
+	cmdq_pkt_logic_command(pkt, CMDQ_THR_SPR_IDX1, &left, CMDQ_LOGIC_ADD, &right);
+
+	addr = cmdq->shared_mem->pa + CMDQ_SEC_SHARED_THR_CNT_OFFSET +
+		sec_thread->idx * sizeof(u32);
+
+	cmdq_pkt_assign(pkt, CMDQ_THR_SPR_IDX2, CMDQ_ADDR_HIGH(addr));
+	cmdq_pkt_write_s(pkt, CMDQ_THR_SPR_IDX2, CMDQ_ADDR_LOW(addr), CMDQ_THR_SPR_IDX1);
+	cmdq_pkt_set_event(pkt, cmdq->pdata->cmdq_event);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_insert_backup_cookie);
+
+static int cmdq_sec_realloc_addr_list(struct cmdq_pkt *pkt, const u32 count)
+{
+	struct cmdq_sec_data *sec_data = (struct cmdq_sec_data *)pkt->sec_data;
+	void *prev = (void *)(unsigned long)sec_data->addr_metadatas, *curr;
+
+	if (count <= sec_data->addr_metadata_max_cnt)
+		return 0;
+
+	curr = kcalloc(count, sizeof(*sec_data), GFP_KERNEL);
+	if (!curr)
+		return -ENOMEM;
+
+	if (count && sec_data->addr_metadatas)
+		memcpy(curr, prev, sizeof(*sec_data) * sec_data->addr_metadata_max_cnt);
+
+	kfree(prev);
+
+	sec_data->addr_metadatas = (uintptr_t)curr;
+	sec_data->addr_metadata_max_cnt = count;
+	return 0;
+}
+
+void cmdq_sec_pkt_free_sec_data(struct cmdq_pkt *pkt)
+{
+	kfree(pkt->sec_data);
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_pkt_free_sec_data);
+
+int cmdq_sec_pkt_alloc_sec_data(struct cmdq_pkt *pkt)
+{
+	struct cmdq_sec_data *sec_data;
+
+	if (pkt->sec_data)
+		return 0;
+
+	sec_data = kzalloc(sizeof(*sec_data), GFP_KERNEL);
+	if (!sec_data)
+		return -ENOMEM;
+
+	pkt->sec_data = (void *)sec_data;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_pkt_alloc_sec_data);
+
+static int cmdq_sec_append_metadata(struct cmdq_pkt *pkt,
+				    const enum cmdq_iwc_addr_metadata_type type,
+				    const u64 base, const u32 offset, const u32 size,
+				    const u32 port)
+{
+	struct cmdq_sec_data *sec_data;
+	struct iwc_cmdq_addr_metadata_t *meta;
+	int idx, max, ret;
+
+	pr_debug("[%s %d] pkt:%p type:%u base:%#llx offset:%#x size:%#x port:%#x",
+		 __func__, __LINE__, pkt, type, base, offset, size, port);
+
+	ret = cmdq_sec_pkt_alloc_sec_data(pkt);
+	if (ret < 0)
+		return ret;
+
+	sec_data = (struct cmdq_sec_data *)pkt->sec_data;
+	idx = sec_data->addr_metadata_cnt;
+	if (idx >= CMDQ_IWC_MAX_ADDR_LIST_LENGTH) {
+		pr_err("idx:%u reach over:%u", idx, CMDQ_IWC_MAX_ADDR_LIST_LENGTH);
+		return -EFAULT;
+	}
+
+	if (!sec_data->addr_metadata_max_cnt)
+		max = ADDR_METADATA_MAX_COUNT_ORIGIN;
+	else if (idx >= sec_data->addr_metadata_max_cnt)
+		max = sec_data->addr_metadata_max_cnt * 2;
+	else
+		max = sec_data->addr_metadata_max_cnt;
+
+	ret = cmdq_sec_realloc_addr_list(pkt, max);
+	if (ret)
+		return ret;
+
+	if (!sec_data->addr_metadatas) {
+		pr_info("addrMetadatas is missing");
+
+		meta = kzalloc(sizeof(*meta), GFP_KERNEL);
+		if (!meta)
+			return -ENOMEM;
+
+		sec_data->addr_metadatas = (uintptr_t)(void *)meta;
+	}
+	meta = (struct iwc_cmdq_addr_metadata_t *)(uintptr_t)sec_data->addr_metadatas;
+
+	meta[idx].instr_idx = pkt->cmd_buf_size / CMDQ_INST_SIZE - 1;
+	meta[idx].type = type;
+	meta[idx].base_handle = base;
+	meta[idx].offset = offset;
+	meta[idx].size = size;
+	meta[idx].port = port;
+	sec_data->addr_metadata_cnt += 1;
+	return 0;
+}
+
+int cmdq_sec_pkt_set_data(struct cmdq_pkt *pkt, const u64 dapc_engine,
+			  const u64 port_sec_engine, const enum cmdq_sec_scenario scenario)
+{
+	struct cmdq_sec_data *sec_data;
+	int ret;
+
+	if (!pkt) {
+		pr_err("invalid pkt:%p", pkt);
+		return -EINVAL;
+	}
+
+	ret = cmdq_sec_pkt_alloc_sec_data(pkt);
+	if (ret < 0)
+		return ret;
+
+	pr_debug("[%s %d] pkt:%p sec_data:%p dapc:%llu port_sec:%llu scen:%u",
+		 __func__, __LINE__, pkt, pkt->sec_data, dapc_engine, port_sec_engine, scenario);
+
+	sec_data = (struct cmdq_sec_data *)pkt->sec_data;
+	sec_data->engs_need_dapc |= dapc_engine;
+	sec_data->engs_need_sec_port |= port_sec_engine;
+	sec_data->scenario = scenario;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_pkt_set_data);
+
+int cmdq_sec_pkt_write(struct cmdq_pkt *pkt, u32 addr, u64 base,
+		       const enum cmdq_iwc_addr_metadata_type type,
+		       const u32 offset, const u32 size, const u32 port)
+{
+	int ret;
+
+	ret = cmdq_pkt_assign(pkt, CMDQ_THR_SPR_IDX0, addr);
+	if (ret)
+		return ret;
+
+	ret = cmdq_pkt_write_s_reg_value(pkt, CMDQ_THR_SPR_IDX0, (u32)base);
+	if (ret)
+		return ret;
+
+	return cmdq_sec_append_metadata(pkt, type, base, offset, size, port);
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_pkt_write);
+
+static u32 cmdq_sec_get_cookie(struct cmdq_sec *cmdq, u32 idx)
+{
+	return *(u32 *)(cmdq->shared_mem->va +
+		CMDQ_SEC_SHARED_THR_CNT_OFFSET + idx * sizeof(u32));
+}
+
+static void cmdq_sec_task_done(struct cmdq_sec_task *sec_task, int sta)
+{
+	struct cmdq_cb_data data;
+
+	data.sta = sta;
+	data.pkt = sec_task->task.pkt;
+
+	pr_debug("%s sec_task:%p pkt:%p err:%d",
+		 __func__, sec_task, sec_task->task.pkt, sta);
+
+	mbox_chan_received_data(sec_task->task.thread->chan, &data);
+
+	list_del_init(&sec_task->task.list_entry);
+	kfree(sec_task);
+}
+
+static bool cmdq_sec_irq_handler(struct cmdq_sec_thread *sec_thread,
+				 const u32 cookie, const int err)
+{
+	struct cmdq_sec_task *sec_task;
+	struct cmdq_task *task, *temp, *cur_task = NULL;
+	struct cmdq_sec *cmdq = container_of(sec_thread->thread.chan->mbox, struct cmdq_sec, mbox);
+	unsigned long flags;
+	int done;
+
+	spin_lock_irqsave(&sec_thread->thread.chan->lock, flags);
+	if (sec_thread->wait_cookie <= cookie)
+		done = cookie - sec_thread->wait_cookie + 1;
+	else if (sec_thread->wait_cookie == (cookie + 1) % CMDQ_MAX_COOKIE_VALUE)
+		done = 0;
+	else
+		done = CMDQ_MAX_COOKIE_VALUE - sec_thread->wait_cookie + 1 + cookie + 1;
+
+	list_for_each_entry_safe(task, temp, &sec_thread->thread.task_busy_list, list_entry) {
+		if (!done)
+			break;
+
+		sec_task = container_of(task, struct cmdq_sec_task, task);
+		cmdq_sec_task_done(sec_task, err);
+
+		if (sec_thread->task_cnt)
+			sec_thread->task_cnt -= 1;
+
+		done--;
+	}
+
+	cur_task = list_first_entry_or_null(&sec_thread->thread.task_busy_list,
+					    struct cmdq_task, list_entry);
+	if (err && cur_task) {
+		spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
+
+		sec_task = container_of(cur_task, struct cmdq_sec_task, task);
+
+		/* for error task, cancel, callback and done */
+		memset(&cmdq->cancel, 0, sizeof(cmdq->cancel));
+		cmdq_sec_task_submit(cmdq, sec_task, CMD_CMDQ_IWC_CANCEL_TASK,
+				     sec_thread->idx, &cmdq->cancel);
+
+		cmdq_sec_task_done(sec_task, err);
+
+		spin_lock_irqsave(&sec_thread->thread.chan->lock, flags);
+
+		task = list_first_entry_or_null(&sec_thread->thread.task_busy_list,
+						struct cmdq_task, list_entry);
+		if (cur_task == task)
+			cmdq_sec_task_done(sec_task, err);
+		else
+			dev_err(cmdq->mbox.dev, "task list changed");
+
+		/*
+		 * error case stop all task for secure,
+		 * since secure tdrv always remove all when cancel
+		 */
+		while (!list_empty(&sec_thread->thread.task_busy_list)) {
+			cur_task = list_first_entry(&sec_thread->thread.task_busy_list,
+						    struct cmdq_task, list_entry);
+
+			sec_task = container_of(cur_task, struct cmdq_sec_task, task);
+			cmdq_sec_task_done(sec_task, -ECONNABORTED);
+		}
+	} else if (err) {
+		dev_dbg(cmdq->mbox.dev, "error but all task done, check notify callback");
+	}
+
+	if (list_empty(&sec_thread->thread.task_busy_list)) {
+		sec_thread->wait_cookie = 0;
+		sec_thread->next_cookie = 0;
+		sec_thread->task_cnt = 0;
+		__raw_writel(0, (void __iomem *)cmdq->shared_mem->va +
+			     CMDQ_SEC_SHARED_THR_CNT_OFFSET +
+			     sec_thread->idx * sizeof(u32));
+		spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
+		del_timer(&sec_thread->timeout);
+		return true;
+	}
+
+	sec_thread->wait_cookie = cookie % CMDQ_MAX_COOKIE_VALUE + 1;
+
+	mod_timer(&sec_thread->timeout, jiffies + msecs_to_jiffies(sec_thread->timeout_ms));
+	spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
+
+	return false;
+}
+
+static void cmdq_sec_irq_notify_work(struct work_struct *work_item)
+{
+	struct cmdq_sec *cmdq = container_of(work_item, struct cmdq_sec, irq_notify_work);
+	int i;
+	u32 thread_max = cmdq->pdata->secure_thread_min + cmdq->pdata->secure_thread_nr;
+
+	mutex_lock(&cmdq->exec_lock);
+
+	for (i = cmdq->pdata->secure_thread_min; i <= thread_max; i++) {
+		struct cmdq_sec_thread *sec_thread = &cmdq->sec_thread[i];
+		u32 cookie = cmdq_sec_get_cookie(cmdq, sec_thread->idx);
+
+		if (cookie < sec_thread->wait_cookie || !sec_thread->task_cnt)
+			continue;
+
+		cmdq_sec_irq_handler(sec_thread, cookie, 0);
+	}
+
+	mutex_unlock(&cmdq->exec_lock);
+}
+
+static void cmdq_sec_irq_notify_callback(struct mbox_client *cl, void *mssg)
+{
+	struct cmdq_cb_data *data = (struct cmdq_cb_data *)mssg;
+	struct cmdq_sec *cmdq = container_of(((struct cmdq_client *)data->pkt->cl)->chan->mbox,
+					     struct cmdq_sec, mbox);
+
+	if (work_pending(&cmdq->irq_notify_work)) {
+		dev_dbg(cmdq->mbox.dev, "%s last notify callback working", __func__);
+		return;
+	}
+
+	queue_work(cmdq->notify_wq, &cmdq->irq_notify_work);
+}
+
+static int cmdq_sec_irq_notify_start(struct cmdq_sec *cmdq)
+{
+	int err;
+
+	if (cmdq->notify_run)
+		return 0;
+
+	if (!cmdq->clt_pkt) {
+		cmdq->clt = cmdq_mbox_create(cmdq->mbox.dev, 0);
+		if (!cmdq->clt || IS_ERR(cmdq->clt)) {
+			dev_err(cmdq->mbox.dev, "clt mbox_create failed clt:%p index:%d",
+				cmdq->clt, CMDQ_SEC_IRQ_THREAD);
+			return -EINVAL;
+		}
+		cmdq->clt->client.rx_callback = cmdq_sec_irq_notify_callback;
+
+		cmdq->clt_pkt = cmdq_pkt_create(cmdq->clt, PAGE_SIZE);
+		if (!cmdq->clt_pkt || IS_ERR(cmdq->clt_pkt)) {
+			dev_err(cmdq->mbox.dev, "clt_pkt cmdq_pkt_create failed pkt:%p index:%d",
+				cmdq->clt_pkt, CMDQ_SEC_IRQ_THREAD);
+			return -EINVAL;
+		}
+
+		INIT_WORK(&cmdq->irq_notify_work, cmdq_sec_irq_notify_work);
+	}
+
+	cmdq_pkt_wfe(cmdq->clt_pkt, cmdq->pdata->cmdq_event, true);
+	cmdq_pkt_finalize_loop(cmdq->clt_pkt);
+	dma_sync_single_for_device(cmdq->mbox.dev,
+				   cmdq->clt_pkt->pa_base,
+				   cmdq->clt_pkt->cmd_buf_size,
+				   DMA_TO_DEVICE);
+	err = mbox_send_message(cmdq->clt->chan, cmdq->clt_pkt);
+	mbox_client_txdone(cmdq->clt->chan, 0);
+	if (err < 0) {
+		dev_err(cmdq->mbox.dev, "%s failed:%d", __func__, err);
+
+		cmdq_sec_pkt_free_sec_data(cmdq->clt_pkt);
+		cmdq_pkt_destroy(cmdq->clt_pkt);
+		cmdq_mbox_destroy(cmdq->clt);
+
+		return err;
+	}
+
+	cmdq->notify_run = true;
+	dev_dbg(cmdq->mbox.dev, "%s success!", __func__);
+
+	return 0;
+}
+
+static int cmdq_sec_session_init(struct cmdq_sec_context *context)
+{
+	int err = 0;
+
+	if (context->state >= IWC_SES_OPENED) {
+		pr_debug("session opened:%u", context->state);
+		return 0;
+	}
+
+	switch (context->state) {
+	case IWC_INIT:
+		err = cmdq_sec_init_context(&context->tee_ctx);
+		if (err)
+			return err;
+		context->state = IWC_CONTEXT_INITED;
+	fallthrough;
+	case IWC_CONTEXT_INITED:
+		if (context->iwc_msg) {
+			pr_err("iwcMessage not NULL:%p", context->iwc_msg);
+			return -EINVAL;
+		}
+
+		err = cmdq_sec_allocate_wsm(&context->tee_ctx, &context->iwc_msg,
+					    sizeof(struct iwc_cmdq_message_t));
+		if (err)
+			return err;
+
+		context->state = IWC_WSM_ALLOCATED;
+	fallthrough;
+	case IWC_WSM_ALLOCATED:
+		err = cmdq_sec_open_session(&context->tee_ctx, context->iwc_msg);
+		if (err)
+			return err;
+
+		context->state = IWC_SES_OPENED;
+	fallthrough;
+	default:
+		break;
+	}
+
+	return 0;
+}
+
+static int cmdq_sec_fill_iwc_msg(struct cmdq_sec_context *context,
+				 struct cmdq_sec_task *sec_task, u32 thrd_idx)
+{
+	struct iwc_cmdq_message_t *iwc_msg = NULL;
+	struct cmdq_sec_data *data = (struct cmdq_sec_data *)sec_task->task.pkt->sec_data;
+	u32 size = 0, offset = 0, *instr;
+
+	iwc_msg = (struct iwc_cmdq_message_t *)context->iwc_msg;
+
+	if (sec_task->task.pkt->cmd_buf_size + 4 * CMDQ_INST_SIZE > CMDQ_TZ_CMD_BLOCK_SIZE) {
+		pr_err("sec_task:%p size:%zu > %u",
+		       sec_task, sec_task->task.pkt->cmd_buf_size, CMDQ_TZ_CMD_BLOCK_SIZE);
+		return -EFAULT;
+	}
+
+	if (thrd_idx == CMDQ_INVALID_THREAD) {
+		iwc_msg->command.cmd_size = 0;
+		iwc_msg->command.metadata.addr_list_length = 0;
+		return -EINVAL;
+	}
+
+	iwc_msg->command.thread = thrd_idx;
+	iwc_msg->command.scenario = sec_task->scenario;
+	iwc_msg->command.eng_flag = sec_task->engine_flag;
+	size = sec_task->task.pkt->cmd_buf_size;
+	memcpy(iwc_msg->command.va_base + offset, sec_task->task.pkt->va_base, size);
+	iwc_msg->command.cmd_size += size;
+	offset += size / 4;
+
+	instr = &iwc_msg->command.va_base[iwc_msg->command.cmd_size / 4 - 4];
+	if ((u64)*instr == CMDQ_EOC_CMD)
+		instr[0] = 0;
+	else
+		pr_err("%s %d: find EOC failed: %#x %#x",
+		       __func__, __LINE__, instr[1], instr[0]);
+
+	iwc_msg->command.wait_cookie = sec_task->wait_cookie;
+	iwc_msg->command.reset_exec = sec_task->reset_exec;
+
+	if (data->addr_metadata_cnt) {
+		iwc_msg->command.metadata.addr_list_length = data->addr_metadata_cnt;
+		memcpy(iwc_msg->command.metadata.addr_list,
+		       (u32 *)(unsigned long)data->addr_metadatas,
+		       data->addr_metadata_cnt * sizeof(struct iwc_cmdq_addr_metadata_t));
+	}
+
+	iwc_msg->command.metadata.engs_need_dapc = data->engs_need_dapc;
+	iwc_msg->command.metadata.engs_need_sec_port = data->engs_need_sec_port;
+	iwc_msg->command.normal_task_handle = (unsigned long)sec_task->task.pkt;
+
+	return 0;
+}
+
+static int cmdq_sec_session_send(struct cmdq_sec_context *context,
+				 struct cmdq_sec_task *sec_task, const u32 iwc_cmd,
+				 const u32 thrd_idx, struct cmdq_sec *cmdq)
+{
+	int err = 0;
+	u64 cost;
+	struct iwc_cmdq_message_t *iwc_msg = NULL;
+
+	iwc_msg = (struct iwc_cmdq_message_t *)context->iwc_msg;
+
+	memset(iwc_msg, 0, sizeof(*iwc_msg));
+	iwc_msg->cmd = iwc_cmd;
+	iwc_msg->cmdq_id = cmdq->pdata->hwid;
+	iwc_msg->command.thread = thrd_idx;
+
+	switch (iwc_cmd) {
+	case CMD_CMDQ_IWC_SUBMIT_TASK:
+		err = cmdq_sec_fill_iwc_msg(context, sec_task, thrd_idx);
+		if (err)
+			return err;
+		break;
+	case CMD_CMDQ_IWC_CANCEL_TASK:
+		iwc_msg->cancel_task.wait_cookie = sec_task->wait_cookie;
+		iwc_msg->cancel_task.thread = thrd_idx;
+		break;
+	case CMD_CMDQ_IWC_PATH_RES_ALLOCATE:
+		if (!cmdq->shared_mem || !cmdq->shared_mem->va) {
+			dev_err(cmdq->mbox.dev, "%s %d: shared_mem is NULL", __func__, __LINE__);
+			return -EFAULT;
+		}
+		iwc_msg->path_resource.size = cmdq->shared_mem->size;
+		iwc_msg->path_resource.share_memoy_pa = cmdq->shared_mem->pa;
+		iwc_msg->path_resource.use_normal_irq = 1;
+		break;
+	default:
+		break;
+	}
+
+	cmdq->sec_invoke = sched_clock();
+	dev_dbg(cmdq->mbox.dev, "%s execute cmdq:%p sec_task:%p command:%u thread:%u cookie:%d",
+		__func__, cmdq, sec_task, iwc_cmd, thrd_idx,
+		sec_task ? sec_task->wait_cookie : -1);
+
+	/* send message */
+	err = cmdq_sec_execute_session(&context->tee_ctx, iwc_cmd, CMDQ_TIMEOUT_DEFAULT);
+
+	cmdq->sec_done = sched_clock();
+	cost = div_u64(cmdq->sec_done - cmdq->sec_invoke, 1000000);
+	if (cost >= CMDQ_TIMEOUT_DEFAULT)
+		dev_err(cmdq->mbox.dev, "%s execute timeout cmdq:%p sec_task:%p cost:%lluus",
+			__func__, cmdq, sec_task, cost);
+	else
+		dev_dbg(cmdq->mbox.dev, "%s execute done cmdq:%p sec_task:%p cost:%lluus",
+			__func__, cmdq, sec_task, cost);
+
+	if (err)
+		return err;
+
+	context->state = IWC_SES_ON_TRANSACTED;
+	return 0;
+}
+
+static int cmdq_sec_session_reply(const u32 iwc_cmd, struct iwc_cmdq_message_t *iwc_msg,
+				  void *data, struct cmdq_sec_task *sec_task)
+{
+	struct iwc_cmdq_cancel_task_t *cancel = data;
+	struct cmdq_sec_data *sec_data = sec_task->task.pkt->sec_data;
+
+	if (iwc_cmd == CMD_CMDQ_IWC_SUBMIT_TASK && iwc_msg->rsp < 0) {
+		/* submit fail case copy status */
+		memcpy(&sec_data->sec_status, &iwc_msg->sec_status,
+		       sizeof(sec_data->sec_status));
+		sec_data->response = iwc_msg->rsp;
+	} else if (iwc_cmd == CMD_CMDQ_IWC_CANCEL_TASK && cancel) {
+		/* cancel case only copy cancel result */
+		memcpy(cancel, &iwc_msg->cancel_task, sizeof(*cancel));
+	}
+
+	return iwc_msg->rsp;
+}
+
+static int cmdq_sec_task_submit(struct cmdq_sec *cmdq, struct cmdq_sec_task *sec_task,
+				const u32 iwc_cmd, const u32 thrd_idx, void *data)
+{
+	struct cmdq_sec_context *context;
+	int err = 0;
+
+	if (!cmdq->context) {
+		context = kzalloc(sizeof(*cmdq->context), GFP_ATOMIC);
+		if (!context)
+			return -ENOMEM;
+
+		cmdq->context = context;
+		cmdq->context->state = IWC_INIT;
+		cmdq->context->tgid = current->tgid;
+	}
+
+	if (cmdq->context->state == IWC_INIT)
+		cmdq_sec_setup_tee_context(&cmdq->context->tee_ctx);
+
+	err = cmdq_sec_session_init(cmdq->context);
+	if (err) {
+		dev_err(cmdq->mbox.dev, "%s %d: cmdq_sec_session_init fail: %d",
+			__func__, __LINE__, err);
+		return err;
+	}
+
+	err = cmdq_sec_irq_notify_start(cmdq);
+	if (err) {
+		dev_err(cmdq->mbox.dev, "%s %d: cmdq_sec_irq_notify_start fail: %d",
+			__func__, __LINE__, err);
+		return err;
+	}
+
+	err = cmdq_sec_session_send(cmdq->context, sec_task, iwc_cmd, thrd_idx, cmdq);
+	if (err) {
+		dev_err(cmdq->mbox.dev, "%s %d: iwc_cmd:%d err:%d sec_task:%p thread:%u gce:%#lx",
+			__func__, __LINE__, iwc_cmd, err,
+			sec_task, thrd_idx, (unsigned long)cmdq->base_pa);
+		return err;
+	}
+
+	err = cmdq_sec_session_reply(iwc_cmd, cmdq->context->iwc_msg, data, sec_task);
+	if (err) {
+		dev_err(cmdq->mbox.dev, "%s %d: cmdq_sec_session_reply fail: %d",
+			__func__, __LINE__, err);
+		return err;
+	}
+
+	return 0;
+}
+
+static int cmdq_sec_suspend(struct device *dev)
+{
+	struct cmdq_sec *cmdq = dev_get_drvdata(dev);
+
+	clk_bulk_disable_unprepare(cmdq->pdata->gce_num, cmdq->pdata->clocks);
+	return 0;
+}
+
+static int cmdq_sec_resume(struct device *dev)
+{
+	struct cmdq_sec *cmdq = dev_get_drvdata(dev);
+
+	WARN_ON(clk_bulk_prepare_enable(cmdq->pdata->gce_num, cmdq->pdata->clocks));
+	return 0;
+}
+
+static const struct dev_pm_ops cmdq_sec_pm_ops = {
+	.suspend = cmdq_sec_suspend,
+	.resume = cmdq_sec_resume,
+};
+
+static void cmdq_sec_task_exec_work(struct work_struct *work_item)
+{
+	struct cmdq_sec_task *sec_task = container_of(work_item,
+						      struct cmdq_sec_task, exec_work);
+	struct cmdq_sec_thread *sec_thread = container_of(sec_task->task.thread,
+							 struct cmdq_sec_thread, thread);
+	struct cmdq_sec *cmdq = container_of(sec_thread->thread.chan->mbox,
+					     struct cmdq_sec, mbox);
+	struct cmdq_sec_data *data;
+	unsigned long flags;
+	int err;
+
+	dev_dbg(cmdq->mbox.dev, "%s gce:%#lx sec_task:%p pkt:%p thread:%u",
+		__func__, (unsigned long)cmdq->base_pa,
+		sec_task, sec_task->task.pkt, sec_thread->idx);
+
+	if (!sec_task->task.pkt->sec_data) {
+		dev_err(cmdq->mbox.dev, "pkt:%p without sec_data", sec_task->task.pkt);
+		return;
+	}
+	data = (struct cmdq_sec_data *)sec_task->task.pkt->sec_data;
+
+	mutex_lock(&cmdq->exec_lock);
+
+	spin_lock_irqsave(&sec_thread->thread.chan->lock, flags);
+	if (!sec_thread->task_cnt) {
+		mod_timer(&sec_thread->timeout, jiffies +
+			  msecs_to_jiffies(sec_thread->timeout_ms));
+		sec_thread->wait_cookie = 1;
+		sec_thread->next_cookie = 1;
+		sec_thread->task_cnt = 0;
+		__raw_writel(0, (void __iomem *)cmdq->shared_mem->va +
+			     CMDQ_SEC_SHARED_THR_CNT_OFFSET + sec_thread->idx * sizeof(u32));
+	}
+
+	sec_task->reset_exec = sec_thread->task_cnt ? false : true;
+	sec_task->wait_cookie = sec_thread->next_cookie;
+	sec_thread->next_cookie = (sec_thread->next_cookie + 1) % CMDQ_MAX_COOKIE_VALUE;
+	list_add_tail(&sec_task->task.list_entry, &sec_thread->thread.task_busy_list);
+	sec_thread->task_cnt += 1;
+	spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
+	sec_task->trigger = sched_clock();
+
+	if (!atomic_cmpxchg(&cmdq_path_res, 0, 1)) {
+		err = cmdq_sec_task_submit(cmdq, NULL, CMD_CMDQ_IWC_PATH_RES_ALLOCATE,
+					   CMDQ_INVALID_THREAD, NULL);
+		if (err) {
+			atomic_set(&cmdq_path_res, 0);
+			goto task_end;
+		}
+	}
+
+	if (sec_thread->task_cnt > CMDQ_MAX_TASK_IN_SECURE_THREAD) {
+		dev_err(cmdq->mbox.dev, "task_cnt:%u cannot more than %u sec_task:%p thread:%u",
+			sec_thread->task_cnt, CMDQ_MAX_TASK_IN_SECURE_THREAD,
+			sec_task, sec_thread->idx);
+		err = -EMSGSIZE;
+		goto task_end;
+	}
+
+	err = cmdq_sec_task_submit(cmdq, sec_task, CMD_CMDQ_IWC_SUBMIT_TASK,
+				   sec_thread->idx, NULL);
+	if (err)
+		dev_err(cmdq->mbox.dev, "cmdq_sec_task_submit err:%d sec_task:%p thread:%u",
+			err, sec_task, sec_thread->idx);
+
+task_end:
+	if (err) {
+		struct cmdq_cb_data cb_data;
+
+		cb_data.sta = err;
+		cb_data.pkt = sec_task->task.pkt;
+		mbox_chan_received_data(sec_thread->thread.chan, &cb_data);
+
+		spin_lock_irqsave(&sec_thread->thread.chan->lock, flags);
+		if (!sec_thread->task_cnt)
+			dev_err(cmdq->mbox.dev, "thread:%u task_cnt:%u cannot below zero",
+				sec_thread->idx, sec_thread->task_cnt);
+		else
+			sec_thread->task_cnt -= 1;
+
+		sec_thread->next_cookie = (sec_thread->next_cookie - 1 +
+			CMDQ_MAX_COOKIE_VALUE) % CMDQ_MAX_COOKIE_VALUE;
+		list_del(&sec_task->task.list_entry);
+		dev_dbg(cmdq->mbox.dev, "gce:%#lx err:%d sec_task:%p pkt:%p",
+			(unsigned long)cmdq->base_pa, err, sec_task, sec_task->task.pkt);
+		dev_dbg(cmdq->mbox.dev, "thread:%u task_cnt:%u wait_cookie:%u next_cookie:%u",
+			sec_thread->idx, sec_thread->task_cnt,
+			sec_thread->wait_cookie, sec_thread->next_cookie);
+		spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
+
+		kfree(sec_task);
+	}
+
+	mutex_unlock(&cmdq->exec_lock);
+}
+
+static int cmdq_sec_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+	struct cmdq_pkt *pkt = (struct cmdq_pkt *)data;
+	struct cmdq_sec_data *sec_data = (struct cmdq_sec_data *)pkt->sec_data;
+	struct cmdq_thread *thread = (struct cmdq_thread *)chan->con_priv;
+	struct cmdq_sec_thread *sec_thread = container_of(thread, struct cmdq_sec_thread, thread);
+	struct cmdq_sec_task *sec_task;
+
+	if (!sec_data)
+		return -EINVAL;
+
+	sec_task = kzalloc(sizeof(*sec_task), GFP_ATOMIC);
+	if (!sec_task)
+		return -ENOMEM;
+
+	sec_task->task.pkt = pkt;
+	sec_task->task.thread = thread;
+	sec_task->scenario = sec_data->scenario;
+	sec_task->engine_flag = sec_data->engs_need_dapc | sec_data->engs_need_sec_port;
+
+	INIT_WORK(&sec_task->exec_work, cmdq_sec_task_exec_work);
+	queue_work(sec_thread->task_exec_wq, &sec_task->exec_work);
+	return 0;
+}
+
+static void cmdq_sec_thread_timeout(struct timer_list *t)
+{
+	struct cmdq_sec_thread *sec_thread = from_timer(sec_thread, t, timeout);
+	struct cmdq_sec *cmdq = container_of(sec_thread->thread.chan->mbox, struct cmdq_sec, mbox);
+
+	if (!work_pending(&sec_thread->timeout_work))
+		queue_work(cmdq->timeout_wq, &sec_thread->timeout_work);
+}
+
+static void cmdq_sec_task_timeout_work(struct work_struct *work_item)
+{
+	struct cmdq_sec_thread *sec_thread = container_of(work_item,
+							  struct cmdq_sec_thread, timeout_work);
+	struct cmdq_sec *cmdq = container_of(sec_thread->thread.chan->mbox,
+					     struct cmdq_sec, mbox);
+	struct cmdq_task *task;
+	struct cmdq_sec_task *sec_task;
+	unsigned long flags;
+	u64 duration;
+	u32 cookie;
+
+	mutex_lock(&cmdq->exec_lock);
+
+	spin_lock_irqsave(&sec_thread->thread.chan->lock, flags);
+	if (list_empty(&sec_thread->thread.task_busy_list)) {
+		dev_err(cmdq->mbox.dev, "thread:%u task_list is empty", sec_thread->idx);
+		spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
+		goto done;
+	}
+
+	task = list_first_entry(&sec_thread->thread.task_busy_list,
+				struct cmdq_task, list_entry);
+	sec_task = container_of(task, struct cmdq_sec_task, task);
+	duration = div_u64(sched_clock() - sec_task->trigger, 1000000);
+	if (duration < sec_thread->timeout_ms) {
+		mod_timer(&sec_thread->timeout, jiffies +
+			  msecs_to_jiffies(sec_thread->timeout_ms - duration));
+		spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
+		goto done;
+	}
+
+	cookie = cmdq_sec_get_cookie(cmdq, sec_thread->idx);
+	spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
+
+	dev_err(cmdq->mbox.dev, "%s duration:%llu cookie:%u thread:%u",
+		__func__, duration, cookie, sec_thread->idx);
+	cmdq_sec_irq_handler(sec_thread, cookie, -ETIMEDOUT);
+
+done:
+	mutex_unlock(&cmdq->exec_lock);
+}
+
+static int cmdq_sec_mbox_startup(struct mbox_chan *chan)
+{
+	struct cmdq_thread *thread = (struct cmdq_thread *)chan->con_priv;
+	struct cmdq_sec_thread *sec_thread = container_of(thread,
+							  struct cmdq_sec_thread, thread);
+	char name[20];
+
+	timer_setup(&sec_thread->timeout, cmdq_sec_thread_timeout, 0);
+
+	INIT_WORK(&sec_thread->timeout_work, cmdq_sec_task_timeout_work);
+	snprintf(name, sizeof(name), "task_exec_wq_%u", sec_thread->idx);
+	sec_thread->task_exec_wq = create_singlethread_workqueue(name);
+	return 0;
+}
+
+static void cmdq_sec_mbox_shutdown(struct mbox_chan *chan)
+{
+}
+
+static int cmdq_sec_mbox_flush(struct mbox_chan *chan, unsigned long timeout)
+{
+	struct cmdq_thread *thread = (struct cmdq_thread *)chan->con_priv;
+	struct cmdq_sec *cmdq = container_of(thread->chan->mbox, struct cmdq_sec, mbox);
+	int i;
+	u32 thread_max = cmdq->pdata->secure_thread_min + cmdq->pdata->secure_thread_nr;
+
+	mutex_lock(&cmdq->exec_lock);
+
+	if (list_empty(&thread->task_busy_list)) {
+		mutex_unlock(&cmdq->exec_lock);
+		return 0;
+	}
+
+	for (i = cmdq->pdata->secure_thread_min; i < thread_max; i++) {
+		struct cmdq_sec_thread *sec_thread = &cmdq->sec_thread[i];
+		u32 cookie = cmdq_sec_get_cookie(cmdq, sec_thread->idx);
+
+		if (cookie < sec_thread->wait_cookie || !sec_thread->task_cnt)
+			continue;
+
+		cmdq_sec_irq_handler(sec_thread, cookie, -ECONNABORTED);
+	}
+
+	mutex_unlock(&cmdq->exec_lock);
+	return 0;
+}
+
+static const struct mbox_chan_ops cmdq_sec_mbox_chan_ops = {
+	.send_data = cmdq_sec_mbox_send_data,
+	.startup = cmdq_sec_mbox_startup,
+	.shutdown = cmdq_sec_mbox_shutdown,
+	.flush = cmdq_sec_mbox_flush,
+};
+
+static struct mbox_chan *cmdq_sec_mbox_of_xlate(struct mbox_controller *mbox,
+						const struct of_phandle_args *sp)
+{
+	struct cmdq_thread *thread;
+	struct cmdq_sec_thread *sec_thread;
+	int idx = sp->args[0];
+
+	if (mbox->num_chans <= idx) {
+		pr_err("invalid thrd-idx:%u", idx);
+		return ERR_PTR(-EINVAL);
+	}
+
+	thread = (struct cmdq_thread *)mbox->chans[idx].con_priv;
+	thread->chan = &mbox->chans[idx];
+	thread->priority = sp->args[1];
+	sec_thread = container_of(thread, struct cmdq_sec_thread, thread);
+	sec_thread->timeout_ms = CMDQ_NO_TIMEOUT;
+
+	return &mbox->chans[idx];
+}
+
+static int cmdq_sec_probe(struct platform_device *pdev)
+{
+	int i, err;
+	struct cmdq_sec *cmdq;
+	struct device *dev = &pdev->dev;
+	struct device *gce_dev;
+	struct resource *res;
+
+	cmdq = devm_kzalloc(dev, sizeof(*cmdq), GFP_KERNEL);
+	if (!cmdq)
+		return -ENOMEM;
+
+	cmdq->pdata = (struct gce_sec_plat *)pdev->dev.platform_data;
+	if (!cmdq->pdata) {
+		dev_err(dev, "no valid gce platform data!\n");
+		return -EINVAL;
+	}
+
+	gce_dev = cmdq->pdata->gce_dev;
+	cmdq->base = devm_platform_get_and_ioremap_resource(to_platform_device(gce_dev),
+							    0, &res);
+	if (IS_ERR(cmdq->base))
+		return PTR_ERR(cmdq->base);
+
+	cmdq->base_pa = res->start;
+
+	cmdq->mbox.dev = gce_dev;
+	cmdq->mbox.chans = devm_kcalloc(dev, cmdq->pdata->thread_nr,
+					sizeof(*cmdq->mbox.chans), GFP_KERNEL);
+	if (!cmdq->mbox.chans)
+		return -ENOMEM;
+
+	cmdq->mbox.ops = &cmdq_sec_mbox_chan_ops;
+	cmdq->mbox.num_chans = cmdq->pdata->thread_nr;
+	cmdq->mbox.of_xlate = cmdq_sec_mbox_of_xlate;
+
+	/* make use of TXDONE_BY_ACK */
+	cmdq->mbox.txdone_irq = false;
+	cmdq->mbox.txdone_poll = false;
+
+	cmdq->sec_thread = devm_kcalloc(dev, cmdq->pdata->thread_nr,
+					sizeof(*cmdq->sec_thread), GFP_KERNEL);
+	if (!cmdq->sec_thread)
+		return -ENOMEM;
+
+	mutex_init(&cmdq->exec_lock);
+	for (i = 0; i < cmdq->pdata->thread_nr; i++) {
+		cmdq->sec_thread[i].thread.base = cmdq->base + CMDQ_THR_BASE + CMDQ_THR_SIZE * i;
+		INIT_LIST_HEAD(&cmdq->sec_thread[i].thread.task_busy_list);
+		cmdq->sec_thread[i].idx = i;
+		cmdq->mbox.chans[i].con_priv = (void *)&cmdq->sec_thread[i].thread;
+	}
+
+	cmdq->notify_wq = create_singlethread_workqueue("mtk_cmdq_sec_notify_wq");
+	cmdq->timeout_wq = create_singlethread_workqueue("mtk_cmdq_sec_timeout_wq");
+	err = devm_mbox_controller_register(dev, &cmdq->mbox);
+	if (err)
+		return err;
+
+	cmdq->shared_mem = devm_kzalloc(dev, sizeof(*cmdq->shared_mem), GFP_KERNEL);
+	if (!cmdq->shared_mem)
+		return -ENOMEM;
+
+	cmdq->shared_mem->va = dma_alloc_coherent(dev, PAGE_SIZE,
+						  &cmdq->shared_mem->pa, GFP_KERNEL);
+	cmdq->shared_mem->size = PAGE_SIZE;
+
+	platform_set_drvdata(pdev, cmdq);
+	WARN_ON(clk_bulk_prepare_enable(cmdq->pdata->gce_num, cmdq->pdata->clocks));
+
+	return 0;
+}
+
+static int cmdq_sec_remove(struct platform_device *pdev)
+{
+	struct cmdq_sec *cmdq = platform_get_drvdata(pdev);
+
+	if (cmdq->context)
+		cmdq_sec_free_wsm(&cmdq->context->tee_ctx, &cmdq->context->iwc_msg);
+
+	mbox_controller_unregister(&cmdq->mbox);
+
+	clk_bulk_disable_unprepare(cmdq->pdata->gce_num, cmdq->pdata->clocks);
+	return 0;
+}
+
+static struct platform_driver cmdq_sec_drv = {
+	.probe = cmdq_sec_probe,
+	.remove = cmdq_sec_remove,
+	.driver = {
+		.name = "mtk-cmdq-sec",
+		.pm = &cmdq_sec_pm_ops,
+	},
+};
+
+static int __init cmdq_sec_init(void)
+{
+	int err;
+
+	err = platform_driver_register(&cmdq_sec_drv);
+	if (err)
+		pr_err("platform_driver_register failed:%d", err);
+	return err;
+}
+
+rootfs_initcall(cmdq_sec_init);
+
+MODULE_LICENSE("GPL");
diff --git a/drivers/mailbox/mtk-cmdq-sec-tee.c b/drivers/mailbox/mtk-cmdq-sec-tee.c
new file mode 100644
index 000000000000..e3f5ba6aaaaa
--- /dev/null
+++ b/drivers/mailbox/mtk-cmdq-sec-tee.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#include <linux/math64.h>
+#include <linux/sched/clock.h>
+
+#include <linux/mailbox/mtk-cmdq-sec-tee.h>
+#include <linux/soc/mediatek/mtk-cmdq.h>
+
+/* lock to protect atomic secure task execution */
+static DEFINE_MUTEX(cmdq_sec_exec_lock);
+
+void cmdq_sec_setup_tee_context(struct cmdq_sec_tee_context *tee)
+{
+	/* 09010000 0000 0000 0000000000000000 */
+	memset(tee->uuid, 0, sizeof(tee->uuid));
+	tee->uuid[0] = 0x9;
+	tee->uuid[1] = 0x1;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_setup_tee_context);
+
+static int tee_dev_match(struct tee_ioctl_version_data *t, const void *v)
+{
+	if (t->impl_id == TEE_IMPL_ID_OPTEE)
+		return 1;
+
+	return 0;
+}
+
+int cmdq_sec_init_context(struct cmdq_sec_tee_context *tee)
+{
+	tee->tee_context = tee_client_open_context(NULL, tee_dev_match, NULL, NULL);
+	if (!tee->tee_context) {
+		pr_err("[%s][%d] tee_client_open_context failed!", __func__, __LINE__);
+		return -EFAULT;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_init_context);
+
+int cmdq_sec_deinit_context(struct cmdq_sec_tee_context *tee)
+{
+	if (tee && tee->tee_context)
+		tee_client_close_context(tee->tee_context);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_deinit_context);
+
+int cmdq_sec_allocate_wsm(struct cmdq_sec_tee_context *tee, void **wsm_buffer, u32 size)
+{
+	void *buffer;
+
+	if (!wsm_buffer)
+		return -EINVAL;
+
+	if (size == 0)
+		return -EINVAL;
+
+	buffer = kmalloc(size, GFP_KERNEL);
+	if (!buffer)
+		return -ENOMEM;
+
+	tee->shared_mem = tee_shm_register_kernel_buf(tee->tee_context, buffer, size);
+	if (!tee->shared_mem) {
+		kfree(buffer);
+		return -ENOMEM;
+	}
+
+	*wsm_buffer = buffer;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_allocate_wsm);
+
+int cmdq_sec_free_wsm(struct cmdq_sec_tee_context *tee, void **wsm_buffer)
+{
+	if (!wsm_buffer)
+		return -EINVAL;
+
+	tee_shm_put(tee->shared_mem);
+	tee->shared_mem = NULL;
+	kfree(*wsm_buffer);
+	*wsm_buffer = NULL;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_free_wsm);
+
+int cmdq_sec_open_session(struct cmdq_sec_tee_context *tee, void *wsm_buffer)
+{
+	struct tee_ioctl_open_session_arg osarg = {0};
+	struct tee_param params = {0};
+	int ret = 0;
+
+	if (!wsm_buffer)
+		return -EINVAL;
+
+	osarg.num_params = 1;
+	memcpy(osarg.uuid, tee->uuid, sizeof(osarg.uuid));
+	osarg.clnt_login = 0;
+
+	ret = tee_client_open_session(tee->tee_context, &osarg, &params);
+	if (ret)
+		return -EFAULT;
+
+	if (!osarg.ret)
+		tee->session = osarg.session;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_open_session);
+
+int cmdq_sec_close_session(struct cmdq_sec_tee_context *tee)
+{
+	tee_client_close_session(tee->tee_context, tee->session);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_close_session);
+
+int cmdq_sec_execute_session(struct cmdq_sec_tee_context *tee, u32 cmd, s32 timeout_ms)
+{
+	struct tee_ioctl_invoke_arg invoke_arg = {0};
+	struct tee_param params = {0};
+	u64 ts = sched_clock();
+	int ret = 0;
+
+	mutex_lock(&cmdq_sec_exec_lock);
+
+	params.attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT;
+	params.u.memref.shm = tee->shared_mem;
+	params.u.memref.shm_offs = 0;
+	params.u.memref.size = tee->shared_mem->size;
+
+	invoke_arg.num_params = 1;
+	invoke_arg.session = tee->session;
+	invoke_arg.func = cmd;
+
+	ret = tee_client_invoke_func(tee->tee_context, &invoke_arg, &params);
+	if (ret) {
+		pr_err("tee_client_invoke_func failed, ret=%d\n", ret);
+		return -EFAULT;
+	}
+
+	ret = invoke_arg.ret;
+
+	mutex_unlock(&cmdq_sec_exec_lock);
+
+	ts = div_u64(sched_clock() - ts, 1000000);
+
+	if (ret != 0)
+		pr_err("[SEC]execute: TEEC_InvokeCommand:%u ret:%d cost:%lluus", cmd, ret, ts);
+	else if (ts > timeout_ms)
+		pr_err("[SEC]execute: TEEC_InvokeCommand:%u ret:%d cost:%lluus", cmd, ret, ts);
+	else
+		pr_debug("[SEC]execute: TEEC_InvokeCommand:%u ret:%d cost:%lluus", cmd, ret, ts);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cmdq_sec_execute_session);
+
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 43eae45a08c9..d29916d17110 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -22,6 +22,7 @@
 #define CMDQ_SUBSYS_SHIFT		16
 #define CMDQ_OP_CODE_SHIFT		24
 #define CMDQ_JUMP_PASS			CMDQ_INST_SIZE
+#define CMDQ_EOC_CMD			0x4000000000000001ULL
 
 #define CMDQ_WFE_UPDATE			BIT(31)
 #define CMDQ_WFE_UPDATE_VALUE		BIT(16)
@@ -84,6 +85,7 @@ struct cmdq_pkt {
 	size_t			buf_size; /* real buffer size */
 	void			*cl;
 	bool			loop;
+	void			*sec_data;
 };
 
 struct cmdq_thread {
diff --git a/include/linux/mailbox/mtk-cmdq-sec-iwc-common.h b/include/linux/mailbox/mtk-cmdq-sec-iwc-common.h
new file mode 100644
index 000000000000..655185ea8a82
--- /dev/null
+++ b/include/linux/mailbox/mtk-cmdq-sec-iwc-common.h
@@ -0,0 +1,385 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#ifndef __CMDQ_SEC_IWC_COMMON_H__
+#define __CMDQ_SEC_IWC_COMMON_H__
+
+/**
+ * CMDQ_SEC_SHARED_THR_CNT_OFFSET - shared memory offset to store thread count.
+ */
+#define CMDQ_SEC_SHARED_THR_CNT_OFFSET		0x100
+
+/**
+ * CMDQ_TZ_CMD_BLOCK_SIZE - total command buffer size copy from normal world to secure world.
+ * maximum 20 pages may be requested for MDP readback.
+ */
+#define CMDQ_TZ_CMD_BLOCK_SIZE		(20 << 12)
+
+/**
+ * CMDQ_IWC_MAX_CMD_LENGTH - max length of u32 array to store commanad buffer.
+ */
+#define CMDQ_IWC_MAX_CMD_LENGTH		(CMDQ_TZ_CMD_BLOCK_SIZE / sizeof(u32))
+
+/**
+ * CMDQ_IWC_MAX_ADDR_LIST_LENGTH - max length of addr metadata list.
+ */
+#define CMDQ_IWC_MAX_ADDR_LIST_LENGTH	(30)
+
+/**
+ * CMDQ_IWC_CLIENT_NAME - length for caller_name in iwc_cmdq_command_t.
+ */
+#define CMDQ_IWC_CLIENT_NAME		(16)
+
+/**
+ * CMDQ_MAX_READBACK_ENG - length for readback_engs in iwc_cmdq_command_t.
+ */
+#define CMDQ_MAX_READBACK_ENG		(8)
+
+/**
+ * CMDQ_SEC_MESSAGE_INST_LEN - length for sec_inst in iwc_cmdq_sec_status_t.
+ */
+#define CMDQ_SEC_MESSAGE_INST_LEN	(8)
+
+/**
+ * CMDQ_SEC_DISPATCH_LEN - length for dispatch in iwc_cmdq_sec_status_t.
+ */
+#define CMDQ_SEC_DISPATCH_LEN		(8)
+
+/*
+ * IWC Command IDs - ID for normal world(TLC or linux kernel) to secure world.
+ */
+#define CMD_CMDQ_IWC_SUBMIT_TASK	(1) /* submit current task */
+#define CMD_CMDQ_IWC_CANCEL_TASK	(3) /* cancel current task */
+#define CMD_CMDQ_IWC_PATH_RES_ALLOCATE	(4) /* create global resource for secure path */
+
+/**
+ * enum cmdq_iwc_addr_metadata_type - address medadata type to be converted in secure world.
+ * @CMDQ_IWC_H_2_PA: secure handle to sec PA.
+ * @CMDQ_IWC_H_2_MVA: secure handle to sec MVA.
+ * @CMDQ_IWC_NMVA_2_MVA: map normal MVA to secure world.
+ * @CMDQ_IWC_PH_2_MVA: session protected handle to sec MVA.
+ *
+ * To tell secure world waht operation to use for converting address in metadata list.
+ */
+enum cmdq_iwc_addr_metadata_type {
+	CMDQ_IWC_H_2_PA		= 0,
+	CMDQ_IWC_H_2_MVA	= 1,
+	CMDQ_IWC_NMVA_2_MVA	= 2,
+	CMDQ_IWC_PH_2_MVA	= 3,
+};
+
+/*
+ * enum cmdq_sec_engine_enum - the flag for HW engines need to be proteced in secure world.
+ * Each enum is a bit in a u64 engine flag variable.
+ */
+enum cmdq_sec_engine_enum {
+	/* MDP */
+	CMDQ_SEC_MDP_RDMA0		= 0,
+	CMDQ_SEC_MDP_RDMA1		= 1,
+	CMDQ_SEC_MDP_WDMA		= 2,
+	CMDQ_SEC_MDP_RDMA2		= 3,
+	CMDQ_SEC_MDP_RDMA3		= 4,
+	CMDQ_SEC_MDP_WROT0		= 5,
+	CMDQ_SEC_MDP_WROT1		= 6,
+	CMDQ_SEC_MDP_WROT2		= 7,
+	CMDQ_SEC_MDP_WROT3		= 8,
+	CMDQ_SEC_MDP_HDR0		= 9,
+	CMDQ_SEC_MDP_HDR1		= 10,
+	CMDQ_SEC_MDP_HDR2		= 11,
+	CMDQ_SEC_MDP_HDR3		= 12,
+	CMDQ_SEC_MDP_AAL0		= 13,
+	CMDQ_SEC_MDP_AAL1		= 14,
+	CMDQ_SEC_MDP_AAL2		= 15,
+	CMDQ_SEC_MDP_AAL3		= 16,
+
+	/* DISP (VDOSYS0) */
+	CMDQ_SEC_DISP_RDMA0		= 17,
+	CMDQ_SEC_DISP_RDMA1		= 18,
+	CMDQ_SEC_DISP_WDMA0		= 19,
+	CMDQ_SEC_DISP_WDMA1		= 20,
+	CMDQ_SEC_DISP_OVL0		= 21,
+	CMDQ_SEC_DISP_OVL1		= 22,
+	CMDQ_SEC_DISP_OVL2		= 23,
+	CMDQ_SEC_DISP_2L_OVL0		= 24,
+	CMDQ_SEC_DISP_2L_OVL1		= 25,
+	CMDQ_SEC_DISP_2L_OVL2		= 26,
+
+	/* DSIP (VDOSYS1) */
+	CMDQ_SEC_VDO1_DISP_RDMA_L0	= 27,
+	CMDQ_SEC_VDO1_DISP_RDMA_L1	= 28,
+	CMDQ_SEC_VDO1_DISP_RDMA_L2	= 29,
+	CMDQ_SEC_VDO1_DISP_RDMA_L3	= 30,
+
+	/* VENC */
+	CMDQ_SEC_VENC_BSDMA		= 31,
+	CMDQ_SEC_VENC_CUR_LUMA		= 32,
+	CMDQ_SEC_VENC_CUR_CHROMA	= 33,
+	CMDQ_SEC_VENC_REF_LUMA		= 34,
+	CMDQ_SEC_VENC_REF_CHROMA	= 35,
+	CMDQ_SEC_VENC_REC		= 36,
+	CMDQ_SEC_VENC_SUB_R_LUMA	= 37,
+	CMDQ_SEC_VENC_SUB_W_LUMA	= 38,
+	CMDQ_SEC_VENC_SV_COMV		= 39,
+	CMDQ_SEC_VENC_RD_COMV		= 40,
+	CMDQ_SEC_VENC_NBM_RDMA		= 41,
+	CMDQ_SEC_VENC_NBM_WDMA		= 42,
+	CMDQ_SEC_VENC_NBM_RDMA_LITE	= 43,
+	CMDQ_SEC_VENC_NBM_WDMA_LITE	= 44,
+	CMDQ_SEC_VENC_FCS_NBM_RDMA	= 45,
+	CMDQ_SEC_VENC_FCS_NBM_WDMA	= 46,
+
+	CMDQ_SEC_MAX_ENG_COUNT
+};
+
+/**
+ * struct iwc_cmdq_addr_metadata_t - metadata structure for converting address of secure buffer.
+ * @instr_idx: index of instruction.
+ * @type: addr metadata type.
+ * @base_handle: secure address handle.
+ * @block_offset: block offset from handle(PA) to current block(plane).
+ * @offset: buffser offset to secure handle.
+ * @size: buffer size.
+ * @port: HW port id (i.e. M4U port id)
+ */
+struct iwc_cmdq_addr_metadata_t {
+	/**
+	 * @instr_idx: update its arg_b value to real PA/MVA in secure world.
+	 */
+	u32 instr_idx;
+
+	/**
+	 * @type: address medadata type to be converted in secure world.
+	 */
+	u32 type;
+
+	/**
+	 * @base_handle:
+	 * @block_offset:
+	 * @offset:
+	 * @size:
+	 * these members are used to store the buffer and offset relationship.
+	 *
+	 *   -------------
+	 *   |     |     |
+	 *   -------------
+	 *   ^     ^  ^  ^
+	 *   A     B  C  D
+	 *
+	 *  A: base_handle
+	 *  B: base_handle + block_offset
+	 *  C: base_handle + block_offset + offset
+	 *  A~B or B~D: size
+	 */
+	u64 base_handle;
+	u32 block_offset;
+	u32 offset;
+	u32 size;
+
+	/**
+	 * @port: [IN]
+	 *
+	 * used to configure M4U port id.
+	 */
+	u32 port;
+};
+
+/**
+ * struct iwc_cmdq_metadata_t - metadata structure for converting a list of secure buffer address.
+ * @addr_list_length: length of metadata address list.
+ * @addr_list: array of metadata address list.
+ * @engs_need_dapc: HW engines need to be protected by dapc.
+ * @engs_need_sec_port: HW engines need to be protected by secure larb port.
+ */
+struct iwc_cmdq_metadata_t {
+	u32 addr_list_length;
+	struct iwc_cmdq_addr_metadata_t addr_list[CMDQ_IWC_MAX_ADDR_LIST_LENGTH];
+	u64 engs_need_dapc;
+	u64 engs_need_sec_port;
+};
+
+/**
+ * enum sec_extension_iwc - extension HW engine flag to be protcted in secure world.
+ * @IWC_MDP_AAL: for MDP AAL engine.
+ * @IWC_MDP_TDSHP: for MDP TDSHP engine.
+ */
+enum sec_extension_iwc {
+	IWC_MDP_AAL = 0,
+	IWC_MDP_TDSHP,
+};
+
+/**
+ * struct readback_engine - readback engine parameters.
+ * @engine: HW engine flag for readback.
+ * @start: start address pa of readback buffer.
+ * @count: u32 size count of readback buffer.
+ * @param: other parameters need in secure world.
+ */
+struct readback_engine {
+	u32 engine;
+	u32 start;
+	u32 count;
+	u32 param;
+};
+
+/**
+ * struct iwc_cmdq_command_t - structure for excuting cmdq task in secure world.
+ * @thread: GCE secure thread index to execute command.
+ * @scenario: scenario to execute command.
+ * @priority: priority of GCE secure thread.
+ * @cmd_size: command size used in command buffer.
+ * @eng_flag: HW engine flag need to enable protection configuration.
+ * @va_base: command buffer
+ * @wait_cookie: index in thread's task list, it should be (nextCookie - 1).
+ * @reset_exec: reset HW thread.
+ * @caller_pid: pid of client module.
+ * @caller_name: name of client module.
+ * @metadata: metadata structure for converting a list of secure buffer address.
+ * @extension: extension HW engine flag to be protcted in secure world.
+ * @readback_pa: readback buffer pa.
+ * @normal_task_handle: handle to reference task in normal world.
+ * @mdp_extension: extension MDP HW engine flag to be protcted in secure world.
+ * @readback_engs: array of readback engines parameters.
+ * @readback_cnt: count of readback_engs array.
+ */
+struct iwc_cmdq_command_t {
+	/* basic execution data */
+	u32 thread;
+	u32 scenario;
+	u32 priority;
+	u32 cmd_size;
+	u64 eng_flag;
+	u32 va_base[CMDQ_IWC_MAX_CMD_LENGTH];
+
+	/* exec order data */
+	u32 wait_cookie;
+	bool reset_exec;
+
+	/* client info */
+	s32 caller_pid;
+	char caller_name[CMDQ_IWC_CLIENT_NAME];
+
+	/* metadata */
+	struct iwc_cmdq_metadata_t metadata;
+
+	/* client extension bits */
+	u64 extension;
+	u64 readback_pa;
+
+	/* debug */
+	u64 normal_task_handle;
+
+	/* SVP HDR */
+	u32 mdp_extension;
+	struct readback_engine readback_engs[CMDQ_MAX_READBACK_ENG];
+	u32 readback_cnt;
+};
+
+/**
+ * struct iwc_cmdq_cancel_task_t - structure for canceling cmdq task in the secure world.
+ * @thread: [IN] GCE secure thread index.
+ * @wait_cookie: [IN] execute count cookie to wait.
+ * @throw_aee: [OUT] AEE has thrown.
+ * @has_reset: [OUT] current secure thread has been reset
+ * @irq_status: [OUT] global secure IRQ flag.
+ * @irq_flag: [OUT] thread IRQ flag.
+ * @err_instr: [OUT] err_instr[0] = instruction low bits, err_instr[1] = instruction high bits.
+ * @reg_value: [OUT] value of error register.
+ * @pc: [OUT] current pc.
+ *
+ * used to allocate share memory from secure world.
+ */
+struct iwc_cmdq_cancel_task_t {
+	s32 thread;
+	u32 wait_cookie;
+	bool throw_aee;
+	bool has_reset;
+	s32 irq_status;
+	s32 irq_flag;
+	u32 err_instr[2];
+	u32 reg_value;
+	u32 pc;
+};
+
+/**
+ * struct iwc_cmdq_path_resource_t - Inter-World Communication resource allocation structure.
+ * @share_memoy_pa: use long long for 64 bit compatible support.
+ * @size: size of share memory.
+ * @use_normal_irq: use normal IRQ in secure world.
+ *
+ * used to allocate share memory from secure world.
+ */
+struct iwc_cmdq_path_resource_t {
+	long long share_memoy_pa;
+	u32 size;
+	bool use_normal_irq;
+};
+
+/**
+ * struct iwc_cmdq_debug_config_t - debug config structure for secure debug log.
+ *
+ * @log_level: log level in secure world.
+ * @enable_profile: enable profile in secure world.
+ */
+struct iwc_cmdq_debug_config_t {
+	s32 log_level;
+	s32 enable_profile;
+};
+
+/**
+ * struct iwc_cmdq_sec_status_t - secure status from secure world.
+ *
+ * @step: the step in secure cmdq TA.
+ * @status: the status in secure cmdq TA.
+ * @args: the status arguments in secure cmdq TA.
+ * @sec_inst: current instruction in secure cmdq TA.
+ * @inst_index: current instruction index in secure cmdq TA.
+ * @dispatch: current HW engine configuring in secure cmdq TA.
+ */
+struct iwc_cmdq_sec_status_t {
+	u32 step;
+	s32 status;
+	u32 args[4];
+	u32 sec_inst[CMDQ_SEC_MESSAGE_INST_LEN];
+	u32 inst_index;
+	char dispatch[CMDQ_SEC_DISPATCH_LEN];
+};
+
+/**
+ * struct iwc_cmdq_message_t - Inter-World Communication message structure.
+ * @cmd: [IN] iwc command id.
+ * @rsp: [OUT] respond from secureworld, 0 for success, < 0 for error.
+ * @command: [IN] structure for excuting cmdq task in secure world.
+ * @cancel_task: [IN] structure for canceling cmdq task in the secure world.
+ * @path_resource: [IN]
+ * @debug: [IN] debug config structure for secure debug log.
+ * @sec_status: [OUT] secure status from secure world.
+ * @cmdq_id: [IN] GCE core id.
+ *
+ * Both Linex kernel and mobicore have their own MMU tables for mapping
+ * world shared memory and physical addresses, so mobicore does not understand
+ * linux virtual address mapping.
+ * If we want to transact a large buffer in TCI/DCI, there are 2 ways (both require 1 copy):
+ * 1. Ue mc_map to map the normal world buffer to WSM and pass secure_virt_addr in TCI/DCI buffer.
+ *    Note that mc_map implies a memcopy to copy the content from normal world to WSM.
+ * 2. Declare a fixed-length array in TCI/DCI struct and its size must be < 1M.
+ */
+struct iwc_cmdq_message_t {
+	union {
+		u32 cmd;
+		s32 rsp;
+	};
+
+	union {
+		struct iwc_cmdq_command_t command;
+		struct iwc_cmdq_cancel_task_t cancel_task;
+		struct iwc_cmdq_path_resource_t path_resource;
+	};
+
+	struct iwc_cmdq_debug_config_t debug;
+	struct iwc_cmdq_sec_status_t sec_status;
+
+	u8 cmdq_id;
+};
+#endif /* __CMDQ_SEC_IWC_COMMON_H__ */
diff --git a/include/linux/mailbox/mtk-cmdq-sec-mailbox.h b/include/linux/mailbox/mtk-cmdq-sec-mailbox.h
new file mode 100644
index 000000000000..01a842d713e6
--- /dev/null
+++ b/include/linux/mailbox/mtk-cmdq-sec-mailbox.h
@@ -0,0 +1,158 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#ifndef __MTK_CMDQ_SEC_MAILBOX_H__
+#define __MTK_CMDQ_SEC_MAILBOX_H__
+
+#include <linux/kernel.h>
+
+#include <linux/mailbox/mtk-cmdq-mailbox.h>
+#include <linux/mailbox/mtk-cmdq-sec-iwc-common.h>
+#include <linux/mailbox/mtk-cmdq-sec-tee.h>
+#include <linux/soc/mediatek/mtk-cmdq.h>
+
+#define CMDQ_INVALID_THREAD		(-1)
+#define CMDQ_MAX_TASK_IN_SECURE_THREAD	(16)
+#define CMDQ_SEC_IRQ_THREAD		(15)
+
+/**
+ * CMDQ_MAX_COOKIE_VALUE - max value of CMDQ_THR_EXEC_CNT_PA (value starts from 0)
+ */
+#define CMDQ_MAX_COOKIE_VALUE           (0xffff)
+
+/**
+ * enum cmdq_sec_scenario - scenario settings for cmdq TA.
+ * @CMDQ_SEC_SCNR_PRIMARY_DISP: primary display vdo mode enable.
+ * @CMDQ_SEC_SCNR_SUB_DISP: external display vdo mode enable.
+ * @CMDQ_SEC_SCNR_PRIMARY_DISP_DISABLE: primary display vdo mode disable.
+ * @CMDQ_SEC_SCNR_SUB_DISP_DISABLE: external display vdo mode disable.
+ * @CMDQ_SEC_SCNR_MAX: the end of enum.
+ *
+ * These states are used to record the state of IWC message structure.
+ */
+enum cmdq_sec_scenario {
+	CMDQ_SEC_SCNR_PRIMARY_DISP		= 1,
+	CMDQ_SEC_SCNR_SUB_DISP			= 4,
+	CMDQ_SEC_SCNR_PRIMARY_DISP_DISABLE	= 18,
+	CMDQ_SEC_SCNR_SUB_DISP_DISABLE		= 19,
+	CMDQ_SEC_SCNR_MAX,
+};
+
+/**
+ * enum cmdq_iwc_state_enum - state of Inter-world Communication(IWC) message
+ * @IWC_INIT: state of initializing tee context, means tee context has not initialized.
+ * @IWC_CONTEXT_INITED: tee context has initialized.
+ * @IWC_WSM_ALLOCATED: world share memory has allocated.
+ * @IWC_SES_OPENED: session to the tee context has opend.
+ * @IWC_SES_ON_TRANSACTED: session to the tee context has transacted.
+ * @IWC_STATE_MAX: the end of enum.
+ *
+ * These states are used to record the state of IWC message structure.
+ */
+enum cmdq_iwc_state_enum {
+	IWC_INIT,
+	IWC_CONTEXT_INITED,
+	IWC_WSM_ALLOCATED,
+	IWC_SES_OPENED,
+	IWC_SES_ON_TRANSACTED,
+	IWC_STATE_MAX,
+};
+
+/**
+ * struct gce_sec_plat - used to pass platform data from cmdq driver.
+ * @gce_dev: pointer to GCE device.
+ * @hwid: GCE core id.
+ * @gce_num: number of GCE core.
+ * @clocks: GCE clocks.
+ * @thread_nr: number of thread in each GCE core.
+ * @secure_thread_nr: number of secure thread.
+ * @secure_thread_min: min index of secure thread.
+ * @cmdq_event: secure EOF event id.
+ */
+struct gce_sec_plat {
+	struct device *gce_dev;
+	u32 hwid;
+	u32 gce_num;
+	struct clk_bulk_data *clocks;
+	u32 thread_nr;
+	u8 secure_thread_nr;
+	u8 secure_thread_min;
+	u32 cmdq_event;
+};
+
+/**
+ * struct cmdq_sec_data - used to translate secure buffer PA related instruction
+ * @addr_metadata_cnt: count of element in addr_list.
+ * @addr_metadatas: array of iwc_cmdq_addr_metadata_t.
+ * @addr_metadata_max_cnt: Reserved.
+ * @scenario: scenario config for secure world.
+ * @engs_need_dapc: engine falgs that need to config dapc in secure world.
+ * @engs_need_sec_port: engine falgs that need to config secure larb port in secure world.
+ * @response: return value from secure world.
+ * @sec_status: current iwc message status from secure world.
+ *
+ */
+struct cmdq_sec_data {
+	u32 addr_metadata_cnt;
+	u64 addr_metadatas;
+	u32 addr_metadata_max_cnt;
+	enum cmdq_sec_scenario scenario;
+	u64 engs_need_dapc;
+	u64 engs_need_sec_port;
+	s32 response;
+	struct iwc_cmdq_sec_status_t sec_status;
+};
+
+/**
+ * cmdq_sec_pkt_free_sec_data() - free sec_data for CMDQ packet.
+ * @pkt:	the CMDQ packet.
+ */
+void cmdq_sec_pkt_free_sec_data(struct cmdq_pkt *pkt);
+
+/**
+ * cmdq_sec_pkt_alloc_sec_data() - allocate sec_data for CMDQ packet.
+ * @pkt:	the CMDQ packet.
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_sec_pkt_alloc_sec_data(struct cmdq_pkt *pkt);
+
+/**
+ * cmdq_sec_insert_backup_cookie() - append backup cookie related instructions.
+ * @pkt:	the CMDQ packet.
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_sec_insert_backup_cookie(struct cmdq_pkt *pkt);
+
+/**
+ * cmdq_sec_pkt_set_data() - set secure configuration to sec_data in CDMQ packet.
+ * @pkt:	the CMDQ packet.
+ * @dapc_engine:	the engine flag for dapc protection.
+ * @port_sec_engine:	the engine flag for secure larb prot protection.
+ * @scenario:		the scenario to CMDQ TA.
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_sec_pkt_set_data(struct cmdq_pkt *pkt, const u64 dapc_engine,
+			  const u64 port_sec_engine, const enum cmdq_sec_scenario scenario);
+
+/**
+ * cmdq_sec_pkt_write() - append write secure buffer related instructions.
+ * @pkt:	  the CMDQ packet.
+ * @addr:	the register to be configured.
+ * @base:	the secure handle of secure buffer.
+ * @type:	the address metadata conversion type.
+ * @offset:	the address offset of secure buffer.
+ * @size:	the secure buffer size.
+ * @port:	the HW port id to M4U TA.
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_sec_pkt_write(struct cmdq_pkt *pkt, u32 addr, u64 base,
+		       const enum cmdq_iwc_addr_metadata_type type,
+		       const u32 offset, const u32 size, const u32 port);
+
+#endif /* __MTK_CMDQ_SEC_MAILBOX_H__ */
diff --git a/include/linux/mailbox/mtk-cmdq-sec-tee.h b/include/linux/mailbox/mtk-cmdq-sec-tee.h
new file mode 100644
index 000000000000..d2c97a137e01
--- /dev/null
+++ b/include/linux/mailbox/mtk-cmdq-sec-tee.h
@@ -0,0 +1,105 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#ifndef __MTK_CMDQ_SEC_TEE_H__
+#define __MTK_CMDQ_SEC_TEE_H__
+
+#include <linux/types.h>
+#include <linux/delay.h>
+#include <linux/tee_drv.h>
+
+/**
+ * struct cmdq_sec_tee_context - context for tee vendor
+ * @uuid: Universally Unique Identifier of secure world.
+ * @tee_context: basic tee context.
+ * @session: session handle.
+ * @shared_mem: shared memory.
+ */
+struct cmdq_sec_tee_context {
+	u8			uuid[TEE_IOCTL_UUID_LEN];
+	struct tee_context	*tee_context;
+	u32			session;
+	struct tee_shm		*shared_mem;
+};
+
+/**
+ * cmdq_sec_setup_tee_context() - setup the uuid for the tee context to communicate with
+ * @tee:	context for tee vendor
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ */
+void cmdq_sec_setup_tee_context(struct cmdq_sec_tee_context *tee);
+
+/**
+ * cmdq_sec_init_context() - initialize the tee context
+ * @tee:	context for tee vendor
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ */
+int cmdq_sec_init_context(struct cmdq_sec_tee_context *tee);
+
+/**
+ * cmdq_sec_deinit_context() - de-initialize the tee context
+ * @tee:	context for tee vendor
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ */
+int cmdq_sec_deinit_context(struct cmdq_sec_tee_context *tee);
+
+/**
+ * cmdq_sec_allocate_wsm() - allocate the world share memory to pass message to tee
+ * @tee:	context for tee vendor
+ * @wsm_buffer:	world share memory buffer with parameters pass to tee
+ * @size:	size to allocate
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ */
+int cmdq_sec_allocate_wsm(struct cmdq_sec_tee_context *tee, void **wsm_buffer, u32 size);
+
+/**
+ * cmdq_sec_free_wsm() - free the world share memory
+ * @tee:	context for tee vendor
+ * @wsm_buffer:	world share memory buffer with parameters pass to tee
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ */
+int cmdq_sec_free_wsm(struct cmdq_sec_tee_context *tee, void **wsm_buffer);
+
+/**
+ * cmdq_sec_open_session() - open session to the tee context
+ * @tee:	context for tee vendor
+ * @wsm_buffer:	world share memory buffer with parameters pass to tee
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ */
+int cmdq_sec_open_session(struct cmdq_sec_tee_context *tee, void *wsm_buffer);
+
+/**
+ * cmdq_sec_close_session() - close session to the tee context
+ * @tee:	context for tee vendor
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ */
+int cmdq_sec_close_session(struct cmdq_sec_tee_context *tee);
+
+/**
+ * cmdq_sec_execute_session() - execute session to the tee context
+ * @tee:	context for tee vendor
+ * @cmd:	tee invoke cmd id
+ * @timeout_ms:	timeout ms to current tee invoke cmd
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ */
+int cmdq_sec_execute_session(struct cmdq_sec_tee_context *tee, u32 cmd, s32 timeout_ms);
+
+#endif	/* __MTK_CMDQ_SEC_TEE_H__ */
-- 
2.18.0



From jason-jh.lin at mediatek.com  Thu Dec 21 20:52:20 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Fri, 22 Dec 2023 12:52:20 +0800
Subject: [PATCH v3 1/9] dt-bindings: gce: mt8195: Add CMDQ_SYNC_TOKEN_SECURE_THR_EOF event id
In-Reply-To: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
Message-ID: <20231222045228.27826-2-jason-jh.lin@mediatek.com>

There are 2 kind of GCE event signal:
- The SW token means: a GCE event signal triggered by SW drivers.
e.g. SW driver append a GCE command to set a GCE event after a specific
GCE command. Or SW driver use CPU to write a event id to GCE register to
trigger the GCE event corresponding to that event id.

- The HW event means: a GCE event signal triggered by HW engines.
e.g. When HW OVL fetches all the data in frame buffer, HW OVL will send
a frame done irq and also send a frame done GCE event via HW bus directly.

CMDQ_SYNC_TOKEN_SECURE_THR_EOF is a SW token event that is set in the
end of each cmdq secure pkt. It is used as a secure irq to notify
CMDQ driver in the normal world that GCE secure thread has completed
a secure cmd buffer in thee secure world.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 include/dt-bindings/gce/mt8195-gce.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/dt-bindings/gce/mt8195-gce.h b/include/dt-bindings/gce/mt8195-gce.h
index dcfb302b8a5b..b6b3db82c381 100644
--- a/include/dt-bindings/gce/mt8195-gce.h
+++ b/include/dt-bindings/gce/mt8195-gce.h
@@ -800,6 +800,12 @@
 #define CMDQ_EVENT_WPE_VPP1_WPE_GCE_FRAME_DONE	969
 #define CMDQ_EVENT_WPE_VPP1_WPE_DONE_SYNC_OUT	970
 
+/*
+ * Notify normal CMDQ there are some secure task done,
+ * this token sync with secure world.
+ */
+#define CMDQ_SYNC_TOKEN_SECURE_THR_EOF			980
+
 #define CMDQ_EVENT_DP_TX_VBLANK_FALLING	994
 #define CMDQ_EVENT_DP_TX_VSC_FINISH	995
 
-- 
2.18.0



From leong.ching.swee at intel.com  Thu Dec 21 21:44:47 2023
From: leong.ching.swee at intel.com (Leong Ching Swee)
Date: Fri, 22 Dec 2023 13:44:47 +0800
Subject: [PATCH net-next v1 0/4] net: stmmac: Enable Per DMA Channel interrupt
Message-ID: <20231222054451.2683242-1-leong.ching.swee@intel.com>

From: Swee Leong Ching <leong.ching.swee at intel.com>

Hi,
Add Per DMA Channel interrupt feature for DWXGMAC IP.
 
Patchset (link below) contains per DMA channel interrupt, But it was 
achieved.
https://lore.kernel.org/lkml/20230821203328.GA2197059-
robh at kernel.org/t/#m849b529a642e1bff89c05a07efc25d6a94c8bfb4
 
Some of the changes in this patchset are based on reviewer comment on 
patchset mentioned beforehand.

Swee Leong Ching (4):
  dt-bindings: net: snps,dwmac: per channel irq
  net: stmmac: Make MSI interrupt routine generic
  net: stmmac: Add support for TX/RX channel interrupt
  net: stmmac: Use interrupt mode INTM=1 for per channel irq

 .../devicetree/bindings/net/snps,dwmac.yaml   | 24 ++++++++++----
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c |  4 +--
 .../net/ethernet/stmicro/stmmac/dwmac4_dma.c  |  2 +-
 .../net/ethernet/stmicro/stmmac/dwxgmac2.h    |  3 ++
 .../ethernet/stmicro/stmmac/dwxgmac2_dma.c    | 32 +++++++++++--------
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 29 +++++++++--------
 .../ethernet/stmicro/stmmac/stmmac_platform.c | 24 ++++++++++++++
 include/linux/stmmac.h                        |  4 +--
 8 files changed, 84 insertions(+), 38 deletions(-)

-- 
2.34.1



From leong.ching.swee at intel.com  Thu Dec 21 21:44:48 2023
From: leong.ching.swee at intel.com (Leong Ching Swee)
Date: Fri, 22 Dec 2023 13:44:48 +0800
Subject: [PATCH net-next v1 1/4] dt-bindings: net: snps,dwmac: per channel irq
In-Reply-To: <20231222054451.2683242-1-leong.ching.swee@intel.com>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
Message-ID: <20231222054451.2683242-2-leong.ching.swee@intel.com>

From: Swee Leong Ching <leong.ching.swee at intel.com>

Add dt-bindings for per channel irq.

Signed-off-by: Rohan G Thomas <rohan.g.thomas at intel.com>
Signed-off-by: Swee Leong Ching <leong.ching.swee at intel.com>
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 24 +++++++++++++------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 5c2769dc689a..e72dded824f4 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -103,17 +103,27 @@ properties:
 
   interrupts:
     minItems: 1
-    items:
-      - description: Combined signal for various interrupt events
-      - description: The interrupt to manage the remote wake-up packet detection
-      - description: The interrupt that occurs when Rx exits the LPI state
+    maxItems: 19
 
   interrupt-names:
     minItems: 1
+    maxItems: 19
     items:
-      - const: macirq
-      - enum: [eth_wake_irq, eth_lpi]
-      - const: eth_lpi
+      oneOf:
+        - description: Combined signal for various interrupt events
+          const: macirq
+        - description: The interrupt to manage the remote wake-up packet detection
+          const: eth_wake_irq
+        - description: The interrupt that occurs when Rx exits the LPI state
+          const: eth_lpi
+        - description: DMA Tx per-channel interrupt
+          pattern: '^dma_tx[0-7]?$'
+        - description: DMA Rx per-channel interrupt
+          pattern: '^dma_rx[0-7]?$'
+
+    allOf:
+      - contains:
+          const: macirq
 
   clocks:
     minItems: 1
-- 
2.34.1



From leong.ching.swee at intel.com  Thu Dec 21 21:44:49 2023
From: leong.ching.swee at intel.com (Leong Ching Swee)
Date: Fri, 22 Dec 2023 13:44:49 +0800
Subject: [PATCH net-next v1 2/4] net: stmmac: Make MSI interrupt routine generic
In-Reply-To: <20231222054451.2683242-1-leong.ching.swee@intel.com>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
Message-ID: <20231222054451.2683242-3-leong.ching.swee@intel.com>

From: Swee Leong Ching <leong.ching.swee at intel.com>

There is no support for per DMA channel interrupt for non-MSI platform,
where the MAC's per channel interrupt hooks up to interrupt controller(GIC)
through shared peripheral interrupt(SPI) to handle interrupt from TX/RX
transmit channel.

This patch generalize the existing MSI ISR to also support non-MSI
platform.

Signed-off-by: Teoh Ji Sheng <ji.sheng.teoh at intel.com>
Signed-off-by: Swee Leong Ching <leong.ching.swee at intel.com>
---
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c |  4 +--
 .../net/ethernet/stmicro/stmmac/dwmac4_dma.c  |  2 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 29 ++++++++++---------
 include/linux/stmmac.h                        |  4 +--
 4 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 60283543ffc8..f0ec69af96c9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -952,7 +952,7 @@ static int stmmac_config_single_msi(struct pci_dev *pdev,
 
 	res->irq = pci_irq_vector(pdev, 0);
 	res->wol_irq = res->irq;
-	plat->flags &= ~STMMAC_FLAG_MULTI_MSI_EN;
+	plat->flags &= ~STMMAC_FLAG_MULTI_IRQ_EN;
 	dev_info(&pdev->dev, "%s: Single IRQ enablement successful\n",
 		 __func__);
 
@@ -1004,7 +1004,7 @@ static int stmmac_config_multi_msi(struct pci_dev *pdev,
 	if (plat->msi_sfty_ue_vec < STMMAC_MSI_VEC_MAX)
 		res->sfty_ue_irq = pci_irq_vector(pdev, plat->msi_sfty_ue_vec);
 
-	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
+	plat->flags |= STMMAC_FLAG_MULTI_IRQ_EN;
 	dev_info(&pdev->dev, "%s: multi MSI enablement successful\n", __func__);
 
 	return 0;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 84d3a8551b03..5f649106ffcd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -175,7 +175,7 @@ static void dwmac4_dma_init(void __iomem *ioaddr,
 
 	value = readl(ioaddr + DMA_BUS_MODE);
 
-	if (dma_cfg->multi_msi_en) {
+	if (dma_cfg->multi_irq_en) {
 		value &= ~DMA_BUS_MODE_INTM_MASK;
 		value |= (DMA_BUS_MODE_INTM_MODE1 << DMA_BUS_MODE_INTM_SHIFT);
 	}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 47de466e432c..30cc9edb4198 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -129,8 +129,8 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id);
 /* For MSI interrupts handling */
 static irqreturn_t stmmac_mac_interrupt(int irq, void *dev_id);
 static irqreturn_t stmmac_safety_interrupt(int irq, void *dev_id);
-static irqreturn_t stmmac_msi_intr_tx(int irq, void *data);
-static irqreturn_t stmmac_msi_intr_rx(int irq, void *data);
+static irqreturn_t stmmac_tx_queue_interrupt(int irq, void *data);
+static irqreturn_t stmmac_rx_queue_interrupt(int irq, void *data);
 static void stmmac_reset_rx_queue(struct stmmac_priv *priv, u32 queue);
 static void stmmac_reset_tx_queue(struct stmmac_priv *priv, u32 queue);
 static void stmmac_reset_queues_param(struct stmmac_priv *priv);
@@ -3602,7 +3602,7 @@ static void stmmac_free_irq(struct net_device *dev,
 	}
 }
 
-static int stmmac_request_irq_multi_msi(struct net_device *dev)
+static int stmmac_request_irq_multi(struct net_device *dev)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 	enum request_irq_err irq_err;
@@ -3701,13 +3701,13 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
 	for (i = 0; i < priv->plat->rx_queues_to_use; i++) {
 		if (i >= MTL_MAX_RX_QUEUES)
 			break;
-		if (priv->rx_irq[i] == 0)
+		if (priv->rx_irq[i] <= 0)
 			continue;
 
 		int_name = priv->int_name_rx_irq[i];
 		sprintf(int_name, "%s:%s-%d", dev->name, "rx", i);
 		ret = request_irq(priv->rx_irq[i],
-				  stmmac_msi_intr_rx,
+				  stmmac_rx_queue_interrupt,
 				  0, int_name, &priv->dma_conf.rx_queue[i]);
 		if (unlikely(ret < 0)) {
 			netdev_err(priv->dev,
@@ -3726,13 +3726,13 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
 	for (i = 0; i < priv->plat->tx_queues_to_use; i++) {
 		if (i >= MTL_MAX_TX_QUEUES)
 			break;
-		if (priv->tx_irq[i] == 0)
+		if (priv->tx_irq[i] <= 0)
 			continue;
 
 		int_name = priv->int_name_tx_irq[i];
 		sprintf(int_name, "%s:%s-%d", dev->name, "tx", i);
 		ret = request_irq(priv->tx_irq[i],
-				  stmmac_msi_intr_tx,
+				  stmmac_tx_queue_interrupt,
 				  0, int_name, &priv->dma_conf.tx_queue[i]);
 		if (unlikely(ret < 0)) {
 			netdev_err(priv->dev,
@@ -3811,8 +3811,8 @@ static int stmmac_request_irq(struct net_device *dev)
 	int ret;
 
 	/* Request the IRQ lines */
-	if (priv->plat->flags & STMMAC_FLAG_MULTI_MSI_EN)
-		ret = stmmac_request_irq_multi_msi(dev);
+	if (priv->plat->flags & STMMAC_FLAG_MULTI_IRQ_EN)
+		ret = stmmac_request_irq_multi(dev);
 	else
 		ret = stmmac_request_irq_single(dev);
 
@@ -6075,7 +6075,7 @@ static irqreturn_t stmmac_safety_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static irqreturn_t stmmac_msi_intr_tx(int irq, void *data)
+static irqreturn_t stmmac_tx_queue_interrupt(int irq, void *data)
 {
 	struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)data;
 	struct stmmac_dma_conf *dma_conf;
@@ -6107,7 +6107,7 @@ static irqreturn_t stmmac_msi_intr_tx(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
-static irqreturn_t stmmac_msi_intr_rx(int irq, void *data)
+static irqreturn_t stmmac_rx_queue_interrupt(int irq, void *data)
 {
 	struct stmmac_rx_queue *rx_q = (struct stmmac_rx_queue *)data;
 	struct stmmac_dma_conf *dma_conf;
@@ -7456,8 +7456,11 @@ int stmmac_dvr_probe(struct device *device,
 	priv->plat = plat_dat;
 	priv->ioaddr = res->addr;
 	priv->dev->base_addr = (unsigned long)res->addr;
-	priv->plat->dma_cfg->multi_msi_en =
-		(priv->plat->flags & STMMAC_FLAG_MULTI_MSI_EN);
+
+	if (res->rx_irq[0] > 0 && res->tx_irq[0] > 0) {
+		priv->plat->flags |= STMMAC_FLAG_MULTI_IRQ_EN;
+		priv->plat->dma_cfg->multi_irq_en = true;
+	}
 
 	priv->dev->irq = res->irq;
 	priv->wol_irq = res->wol_irq;
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index dee5ad6e48c5..b950e6f9761d 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -98,7 +98,7 @@ struct stmmac_dma_cfg {
 	int mixed_burst;
 	bool aal;
 	bool eame;
-	bool multi_msi_en;
+	bool multi_irq_en;
 	bool dche;
 };
 
@@ -215,7 +215,7 @@ struct dwmac4_addrs {
 #define STMMAC_FLAG_TSO_EN			BIT(4)
 #define STMMAC_FLAG_SERDES_UP_AFTER_PHY_LINKUP	BIT(5)
 #define STMMAC_FLAG_VLAN_FAIL_Q_EN		BIT(6)
-#define STMMAC_FLAG_MULTI_MSI_EN		BIT(7)
+#define STMMAC_FLAG_MULTI_IRQ_EN		BIT(7)
 #define STMMAC_FLAG_EXT_SNAPSHOT_EN		BIT(8)
 #define STMMAC_FLAG_INT_SNAPSHOT_EN		BIT(9)
 #define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI		BIT(10)
-- 
2.34.1



From leong.ching.swee at intel.com  Thu Dec 21 21:44:50 2023
From: leong.ching.swee at intel.com (Leong Ching Swee)
Date: Fri, 22 Dec 2023 13:44:50 +0800
Subject: [PATCH net-next v1 3/4] net: stmmac: Add support for TX/RX channel interrupt
In-Reply-To: <20231222054451.2683242-1-leong.ching.swee@intel.com>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
Message-ID: <20231222054451.2683242-4-leong.ching.swee@intel.com>

From: Swee Leong Ching <leong.ching.swee at intel.com>

Enable TX/RX channel interrupt registration for MAC that interrupts CPU
through shared peripheral interrupt (SPI).

Per channel interrupts and interrupt-names are registered through,
Eg: 4 tx and 4 rx channels:
interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
             <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
             <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
             <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
             <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
             <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
             <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
             <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "dma_tx0",
                  "dma_tx1",
                  "dma_tx2",
                  "dma_tx3",
                  "dma_rx0",
                  "dma_rx1",
                  "dma_rx2",
                  "dma_rx3";

Signed-off-by: Teoh Ji Sheng <ji.sheng.teoh at intel.com>
Signed-off-by: Swee Leong Ching <leong.ching.swee at intel.com>
---
 .../ethernet/stmicro/stmmac/stmmac_platform.c | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 70eadc83ca68..f857907f13a0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -710,6 +710,8 @@ EXPORT_SYMBOL_GPL(devm_stmmac_probe_config_dt);
 int stmmac_get_platform_resources(struct platform_device *pdev,
 				  struct stmmac_resources *stmmac_res)
 {
+	char irq_name[8];
+	int i;
 	memset(stmmac_res, 0, sizeof(*stmmac_res));
 
 	/* Get IRQ information early to have an ability to ask for deferred
@@ -719,6 +721,28 @@ int stmmac_get_platform_resources(struct platform_device *pdev,
 	if (stmmac_res->irq < 0)
 		return stmmac_res->irq;
 
+	/* For RX Channel */
+	for (i = 0; i < MTL_MAX_RX_QUEUES; i++) {
+		snprintf(irq_name, sizeof(irq_name), "dma_rx%i", i);
+		stmmac_res->rx_irq[i] = platform_get_irq_byname_optional(pdev, irq_name);
+		if (stmmac_res->rx_irq[i] < 0) {
+			if (stmmac_res->rx_irq[i] == -EPROBE_DEFER)
+				return -EPROBE_DEFER;
+			break;
+		}
+	}
+
+	/* For TX Channel */
+	for (i = 0; i < MTL_MAX_TX_QUEUES; i++) {
+		snprintf(irq_name, sizeof(irq_name), "dma_tx%i", i);
+		stmmac_res->tx_irq[i] = platform_get_irq_byname_optional(pdev, irq_name);
+		if (stmmac_res->tx_irq[i] < 0) {
+			if (stmmac_res->rx_irq[i] == -EPROBE_DEFER)
+				return -EPROBE_DEFER;
+			break;
+		}
+	}
+
 	/* On some platforms e.g. SPEAr the wake up irq differs from the mac irq
 	 * The external wake up irq can be passed through the platform code
 	 * named as "eth_wake_irq"
-- 
2.34.1



From leong.ching.swee at intel.com  Thu Dec 21 21:44:51 2023
From: leong.ching.swee at intel.com (Leong Ching Swee)
Date: Fri, 22 Dec 2023 13:44:51 +0800
Subject: [PATCH net-next v1 4/4] net: stmmac: Use interrupt mode INTM=1 for per channel irq
In-Reply-To: <20231222054451.2683242-1-leong.ching.swee@intel.com>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
Message-ID: <20231222054451.2683242-5-leong.ching.swee@intel.com>

From: Swee Leong Ching <leong.ching.swee at intel.com>

Enable per DMA channel interrupt that uses shared peripheral
interrupt (SPI), so only per channel TX and RX intr (TI/RI)
are handled by TX/RX ISR without calling common interrupt ISR.

Signed-off-by: Teoh Ji Sheng <ji.sheng.teoh at intel.com>
Signed-off-by: Swee Leong Ching <leong.ching.swee at intel.com>
---
 .../net/ethernet/stmicro/stmmac/dwxgmac2.h    |  3 ++
 .../ethernet/stmicro/stmmac/dwxgmac2_dma.c    | 32 +++++++++++--------
 2 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 207ff1799f2c..04bf731cb7ea 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -346,6 +346,9 @@
 /* DMA Registers */
 #define XGMAC_DMA_MODE			0x00003000
 #define XGMAC_SWR			BIT(0)
+#define XGMAC_DMA_MODE_INTM_MASK	GENMASK(13, 12)
+#define XGMAC_DMA_MODE_INTM_SHIFT	12
+#define XGMAC_DMA_MODE_INTM_MODE1	0x1
 #define XGMAC_DMA_SYSBUS_MODE		0x00003004
 #define XGMAC_WR_OSR_LMT		GENMASK(29, 24)
 #define XGMAC_WR_OSR_LMT_SHIFT		24
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 3cde695fec91..dcb9f094415d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -31,6 +31,13 @@ static void dwxgmac2_dma_init(void __iomem *ioaddr,
 		value |= XGMAC_EAME;
 
 	writel(value, ioaddr + XGMAC_DMA_SYSBUS_MODE);
+
+	if (dma_cfg->multi_irq_en) {
+		value = readl(ioaddr + XGMAC_DMA_MODE);
+		value &= ~XGMAC_DMA_MODE_INTM_MASK;
+		value |= (XGMAC_DMA_MODE_INTM_MODE1 << XGMAC_DMA_MODE_INTM_SHIFT);
+		writel(value, ioaddr + XGMAC_DMA_MODE);
+	}
 }
 
 static void dwxgmac2_dma_init_chan(struct stmmac_priv *priv,
@@ -365,19 +372,18 @@ static int dwxgmac2_dma_interrupt(struct stmmac_priv *priv,
 	}
 
 	/* TX/RX NORMAL interrupts */
-	if (likely(intr_status & XGMAC_NIS)) {
-		if (likely(intr_status & XGMAC_RI)) {
-			u64_stats_update_begin(&rxq_stats->syncp);
-			rxq_stats->rx_normal_irq_n++;
-			u64_stats_update_end(&rxq_stats->syncp);
-			ret |= handle_rx;
-		}
-		if (likely(intr_status & (XGMAC_TI | XGMAC_TBU))) {
-			u64_stats_update_begin(&txq_stats->syncp);
-			txq_stats->tx_normal_irq_n++;
-			u64_stats_update_end(&txq_stats->syncp);
-			ret |= handle_tx;
-		}
+	if (likely(intr_status & XGMAC_RI)) {
+		u64_stats_update_begin(&rxq_stats->syncp);
+		rxq_stats->rx_normal_irq_n++;
+		u64_stats_update_end(&rxq_stats->syncp);
+		ret |= handle_rx;
+	}
+
+	if (likely(intr_status & (XGMAC_TI | XGMAC_TBU))) {
+		u64_stats_update_begin(&txq_stats->syncp);
+		txq_stats->tx_normal_irq_n++;
+		u64_stats_update_end(&txq_stats->syncp);
+		ret |= handle_tx;
 	}
 
 	/* Clear interrupts */
-- 
2.34.1



From mengqi.zhang at mediatek.com  Thu Dec 21 22:12:19 2023
From: mengqi.zhang at mediatek.com (Mengqi Zhang)
Date: Fri, 22 Dec 2023 14:12:19 +0800
Subject: [PATCH v2 0/1] mmc: core: Add HS400 tuning in HS400es initialization
Message-ID: <20231222061220.26270-1-mengqi.zhang@mediatek.com>

change v2
1. remove hs400 tuning from mmc_retune.
2. remove mmc_retune_enable() from hs400es initialization.

Mengqi Zhang (1):
  mmc: core: Add HS400 tuning in HS400es initialization

 drivers/mmc/core/mmc.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

-- 
2.25.1



From mengqi.zhang at mediatek.com  Thu Dec 21 22:22:36 2023
From: mengqi.zhang at mediatek.com (Mengqi Zhang)
Date: Fri, 22 Dec 2023 14:22:36 +0800
Subject: [PATCH v2 1/1] mmc: core: Add HS400 tuning in HS400es initialization
Message-ID: <20231222062236.26370-1-mengqi.zhang@mediatek.com>

During the initialization to HS400es stage, add hs400 tuning flow as an
optional process. For Mediatek IP, HS00es mode requires a specific tuning to
ensure the correct HS400 timing setting.

Signed-off-by: Mengqi Zhang <mengqi.zhang at mediatek.com>
---
the previous patch link:
https://patchwork.kernel.org/project/linux-mediatek/patch/20231201030547.11553-1-mengqi.zhang at mediatek.com/
---
 drivers/mmc/core/mmc.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 705942edacc6..9760eea2c104 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1823,7 +1823,15 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
 		if (err)
 			goto free_card;
 
-	} else if (!mmc_card_hs400es(card)) {
+	} else if (mmc_card_hs400es(card)) {
+		if (host->ops->execute_hs400_tuning) {
+			mmc_retune_disable(host);
+			err = host->ops->execute_hs400_tuning(host, card);
+			mmc_retune_enable(host);
+			if (err)
+				goto free_card;
+		}
+	} else {
 		/* Select the desired bus width optionally */
 		err = mmc_select_bus_width(card);
 		if (err > 0 && mmc_card_hs(card)) {
-- 
2.25.1



From dmitry.baryshkov at linaro.org  Thu Dec 21 22:31:43 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 22 Dec 2023 08:31:43 +0200
Subject: [PATCH v2 7/8] arm64: dts: qcom: sa8295p-adp: Enable GPU
In-Reply-To: <20231220-sa8295p-gpu-v2-7-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com> <20231220-sa8295p-gpu-v2-7-4763246b72c0@quicinc.com>
Message-ID: <CAA8EJpqswNNDUj3tJu6qTYN+g7LoG7L5gMgUQvZfb3cxZRnF+Q@mail.gmail.com>

On Fri, 22 Dec 2023 at 06:40, Bjorn Andersson <quic_bjorande at quicinc.com> wrote:
>
> With the necessary support in place for supplying VDD_GFX from the
> MAX20411 regulator, enable the GPU clock controller, GMU, Adreno SMMU
> and the GPU on the SA8295P ADP.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>


-- 
With best wishes
Dmitry


From peter.wang at mediatek.com  Thu Dec 21 22:31:18 2023
From: peter.wang at mediatek.com (=?utf-8?B?UGV0ZXIgV2FuZyAo546L5L+h5Y+LKQ==?=)
Date: Fri, 22 Dec 2023 06:31:18 +0000
Subject: [PATCH v2] ufs: mcq: Adding a function for MCQ enable
In-Reply-To: <20231221065608.9899-1-cw9316.lee@samsung.com>
References: <CGME20231221065637epcas1p203dcd5cfb1d4a3964fff9543a041d78d@epcas1p2.samsung.com>
	 <20231221065608.9899-1-cw9316.lee@samsung.com>
Message-ID: <534326e6da3b692648eb0be2be6f88e7957d3d89.camel@mediatek.com>

On Thu, 2023-12-21 at 15:56 +0900, Chanwoo Lee wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  From: ChanWoo Lee <cw9316.lee at samsung.com>
> 
> The REG_UFS_MEM_CFG register is too general(broad)
> and it is difficult to know the meaning only with a value of 0x1.
> So far, comments were required.
> 
> Therefore, I have added new functions and defines
> to improve code readability/reusability.
> 
> Signed-off-by: ChanWoo Lee <cw9316.lee at samsung.com>
> 
> * v1->v2:
>    1) Excluding ESI_ENABLE
>    2) Replace with ufshcd_rmwl, BIT()
>    3) Separating hba->mcq_enabled
> ---
> 

Reviewed-by: Peter Wang <peter.wang at mediatek.com>

From tianruidong at linux.alibaba.com  Thu Dec 21 23:29:18 2023
From: tianruidong at linux.alibaba.com (Ruidong Tian)
Date: Fri, 22 Dec 2023 15:29:18 +0800
Subject: [PATCH 1/3] perf scripts python: arm-cs-trace-disasm.py: print
 dso base address
In-Reply-To: <912a39f4-025e-26a1-7786-091fa211f293@arm.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
 <20231214123304.34087-2-tianruidong@linux.alibaba.com>
 <912a39f4-025e-26a1-7786-091fa211f293@arm.com>
Message-ID: <6177beec-f140-44aa-b534-182cd4b0a988@linux.alibaba.com>

Hi James

? 2023/12/20 18:44, James Clark ??:
>
> On 14/12/2023 12:33, Ruidong Tian wrote:
>> arm-cs-trace-disasm just print offset for library dso:
>>
>> 	0000000000002200 <memcpy>:
>>              2200: d503201f      nop
>>              2204: 8b020024      add     x4, x1, x2
>>              2208: 8b020005      add     x5, x0, x2
>>
>> This print DSO base address to get complete virtual address for
>> userspace application:
>>
>> 	0000000000002200 <memcpy>: (base address is 0x0000ffffb4c21000)
>>              2200: d503201f      nop
>>              2204: 8b020024      add     x4, x1, x2
>>              2208: 8b020005      add     x5, x0, x2
>>
> I believe the output format without the base address is consistent with
> objdump. For compatibility I would say that it's better to keep it that way.
Sure, the output is totally corrected, i just print the base address 
rather than modify the output address, i don't think this change is 
incompatible.
>
> We could add this as an option, but have it disabled by default. I
> suppose it depends how likely that someone is using this output in a
> tool and processing it further whether an option is needed or not.
I want to get the runtime trace flow with virtual address, i can get the 
trace information with virtual address in `perf report` and `perf 
script` by default, so i think it is more reasonable to print virtual 
address in arm-cs-trace-disasm script by default.
>
> Although it's also not that clear what this is useful for, given that
> all the other output is relative too? Maybe you could add an example to
> the commit message, even if it's just for debugging. Would an option
> that turned _all_ the output into virtual addresses not be more useful?
I want to use arm-cs-trace-disasm.py output associate with PMU and SPE 
data to explore more CPU performance info, all the PMU/SPE/Coresight 
informations generated by `perf report` and `perf script` include 
virtual address, so i want this script do the same thing.
>
> Thanks
> James
>
>> Signed-off-by: Ruidong Tian <tianruidong at linux.alibaba.com>
>> ---
>>   tools/perf/scripts/python/arm-cs-trace-disasm.py | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
>> index d59ff53f1d94..46bf6b02eea1 100755
>> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
>> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
>> @@ -108,6 +108,8 @@ def print_disam(dso_fname, dso_start, start_addr, stop_addr):
>>   			m = disasm_re.search(line)
>>   			if m is None:
>>   				continue
>> +		else:
>> +			line += " (base address is 0x%016x)" % dso_start
>>   		print("\t" + line)
>>   
>>   def print_sample(sample):


From frank at oltmanns.dev  Thu Dec 21 23:46:01 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Fri, 22 Dec 2023 08:46:01 +0100
Subject: [PATCH 4/5] clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's
 n/m ratio
In-Reply-To: <2174554.Mh6RI2rZIc@jernej-laptop>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <13411739.uLZWGnKmhe@jernej-laptop> <87il4t9wi1.fsf@oltmanns.dev>
 <2174554.Mh6RI2rZIc@jernej-laptop>
Message-ID: <87edfellxi.fsf@oltmanns.dev>


On 2023-12-20 at 16:12:42 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> Dne sreda, 20. december 2023 ob 08:09:28 CET je Frank Oltmanns napisal(a):
>>
>> On 2023-12-19 at 17:54:19 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
>> > Dne ponedeljek, 18. december 2023 ob 14:35:22 CET je Frank Oltmanns napisal(a):
>> >> The Allwinner A64 manual lists the following constraint for the
>> >> PLL-VIDEO0 clock: 8 <= N/M <= 25
>> >>
>> >> Use this constraint.
>> >>
>> >> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
>> >> ---
>> >>  drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 8 ++++++--
>> >>  1 file changed, 6 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> >> index c034ac027d1c..75d839da446c 100644
>> >> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> >> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> >> @@ -68,7 +68,8 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
>> >>  				       BIT(28),	/* lock */
>> >>  				       CLK_SET_RATE_UNGATE);
>> >>
>> >> -static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-video0",
>> >> +static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(pll_video0_clk,
>> >> +						"pll-video0",
>> >>  						"osc24M", 0x010,
>> >>  						192000000,	/* Minimum rate */
>> >>  						1008000000,	/* Maximum rate */
>> >> @@ -80,7 +81,10 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-vid
>> >>  						297000000,	/* frac rate 1 */
>> >>  						BIT(31),	/* gate */
>> >>  						BIT(28),	/* lock */
>> >> -						CLK_SET_RATE_UNGATE);
>> >> +						CLK_SET_RATE_UNGATE,
>> >> +						CCU_FEATURE_FRACTIONAL |
>> >> +						CCU_FEATURE_CLOSEST_RATE,
>> >
>> > Above flags are unrelated change, put them in new patch if needed.
>>
>> You might notice that I am using a new macro for initializing the
>> pll_video0_clk struct:
>> New: SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO
>> Old: SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST
>>
>> Setting the two CCU_FEATURE flags is part of the old initialization
>> macro.
>>
>> I'll add SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_NM_RATIO_CLOSEST which
>> hopefully resolves the confusion.
>
> I'm in doubt if we need so many macros. How many users of these macro we'll have?
> I see that R40 SoC would also need same ratio limits, but other that that, none?

Ok, IIUC no additional macro and we keep this part of the patch as is.

Best regards,
  Frank

>
> Best regards,
> Jernej
>
>>
>> Thanks,
>>   Frank
>>
>> >
>> > Best regards,
>> > Jernej
>> >
>> >> +						8, 25);		/* min/max nm ratio */
>> >>
>> >>  static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
>> >>  					"osc24M", 0x018,
>> >>
>> >>
>>


From william-tw.lin at mediatek.com  Fri Dec 22 00:07:36 2023
From: william-tw.lin at mediatek.com (William-tw Lin)
Date: Fri, 22 Dec 2023 16:07:36 +0800
Subject: [PATCH v4 0/3] mtk-socinfo driver implementation
Message-ID: <20231222080739.21706-1-william-tw.lin@mediatek.com>

v4 changes:
dts:
1. remove phandle from socinfo-data for all platforms

mtk-socinfo.c:
1. use module_platform_driver instead of builtin_platform_driver

drivers/soc/mediatek/Kconfig:
1. add dependency for MTK_SOCINFO

mtk-efuse.c:
1. add remove function

commit message:
1. update commit message by following reviewer's comment

William-tw Lin (3):
  arm64: dts: mediatek: Add socinfo efuses to MT8173/83/96/92/95 SoCs
  soc: mediatek: mtk-socinfo: Add driver for getting chip information
  nvmem: mtk-efuse: Register MediaTek socinfo driver from efuse

 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   9 ++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi |   9 ++
 arch/arm64/boot/dts/mediatek/mt8186.dtsi |   4 +
 arch/arm64/boot/dts/mediatek/mt8192.dtsi |   8 +
 arch/arm64/boot/dts/mediatek/mt8195.dtsi |   3 +
 drivers/nvmem/mtk-efuse.c                |  21 ++-
 drivers/soc/mediatek/Kconfig             |   9 ++
 drivers/soc/mediatek/Makefile            |   1 +
 drivers/soc/mediatek/mtk-socinfo.c       | 186 +++++++++++++++++++++++
 9 files changed, 249 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soc/mediatek/mtk-socinfo.c

-- 
2.18.0



From william-tw.lin at mediatek.com  Fri Dec 22 00:07:39 2023
From: william-tw.lin at mediatek.com (William-tw Lin)
Date: Fri, 22 Dec 2023 16:07:39 +0800
Subject: [PATCH v4 3/3] nvmem: mtk-efuse: Register MediaTek socinfo driver from efuse
In-Reply-To: <20231222080739.21706-1-william-tw.lin@mediatek.com>
References: <20231222080739.21706-1-william-tw.lin@mediatek.com>
Message-ID: <20231222080739.21706-4-william-tw.lin@mediatek.com>

The socinfo driver reads chip information from eFuses and does not need
any devicetree node. Register it from mtk-efuse.

While at it, also add the name for this driver's nvmem_config.

Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
---
 drivers/nvmem/mtk-efuse.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
index 84f05b40a411..f5bebcecf9bd 100644
--- a/drivers/nvmem/mtk-efuse.c
+++ b/drivers/nvmem/mtk-efuse.c
@@ -68,6 +68,7 @@ static int mtk_efuse_probe(struct platform_device *pdev)
 	struct nvmem_config econfig = {};
 	struct mtk_efuse_priv *priv;
 	const struct mtk_efuse_pdata *pdata;
+	struct platform_device *socinfo;
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -85,11 +86,20 @@ static int mtk_efuse_probe(struct platform_device *pdev)
 	econfig.size = resource_size(res);
 	econfig.priv = priv;
 	econfig.dev = dev;
+	econfig.name = "mtk-efuse";
 	if (pdata->uses_post_processing)
 		econfig.fixup_dt_cell_info = &mtk_efuse_fixup_dt_cell_info;
 	nvmem = devm_nvmem_register(dev, &econfig);
+	if (IS_ERR(nvmem))
+		return PTR_ERR(nvmem);
 
-	return PTR_ERR_OR_ZERO(nvmem);
+	socinfo = platform_device_register_data(&pdev->dev, "mtk-socinfo",
+						PLATFORM_DEVID_AUTO, NULL, 0);
+	if (IS_ERR(socinfo))
+		dev_info(dev, "MediaTek SoC Information will be unavailable\n");
+
+	platform_set_drvdata(pdev, socinfo);
+	return 0;
 }
 
 static const struct mtk_efuse_pdata mtk_mt8186_efuse_pdata = {
@@ -108,8 +118,17 @@ static const struct of_device_id mtk_efuse_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, mtk_efuse_of_match);
 
+static void mtk_efuse_remove(struct platform_device *pdev)
+{
+	struct platform_device *socinfo = platform_get_drvdata(pdev);
+
+	if (!IS_ERR_OR_NULL(socinfo))
+		platform_device_unregister(socinfo);
+}
+
 static struct platform_driver mtk_efuse_driver = {
 	.probe = mtk_efuse_probe,
+	.remove_new = mtk_efuse_remove,
 	.driver = {
 		.name = "mediatek,efuse",
 		.of_match_table = mtk_efuse_of_match,
-- 
2.18.0



From krzysztof.kozlowski at linaro.org  Fri Dec 22 00:09:44 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 22 Dec 2023 09:09:44 +0100
Subject: [PATCH] dt-bindings: arm: sunxi: sort alphabetically
In-Reply-To: <20231221162907.1b609235@donnerap.manchester.arm.com>
References: <20231221140614.639697-1-andre.przywara@arm.com>
 <ab8e7d68-c09c-47ff-9f31-08b073387403@linaro.org>
 <20231221150714.53d40ea3@donnerap.manchester.arm.com>
 <6721cb2f-4498-4d20-9059-257846005905@linaro.org>
 <20231221162907.1b609235@donnerap.manchester.arm.com>
Message-ID: <82cae2be-edab-4b2d-8b2d-bd823b58eeb8@linaro.org>

On 21/12/2023 17:29, Andre Przywara wrote:
>>> Shall I add a comment at the top to note the order?  
>>
>> Some files like this are ordered by compatible, some by class or family
>> of devices, so first you need to be sure there is no existing order.
> 
> That's what I did, of course:
> - there is no order in the compatible strings, not in the most specific
> name, nor in the fallback names
> - new boards have always been added somewhere in the middle, never at the
> end, so it's not "oldest boards first"
> - the SoCs used in the boards are all over the place, so it's not sorted
> by SoC
> - I see no rhyme or reason in the board types: we have tablets, devboards,
> TV boxes all mixed up happily.
> 
> But: from the 197 listed boards, a movement of 13 boards, often by just one
> position, makes the list ordered by description.
> 
> So I assumed this was the intention, and fixed the list accordingly. Happy
> to stand corrected if the maintainers have a better idea.

With short comment at the top about sorting:

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From neil.armstrong at linaro.org  Fri Dec 22 00:10:33 2023
From: neil.armstrong at linaro.org (Neil Armstrong)
Date: Fri, 22 Dec 2023 09:10:33 +0100
Subject: (subset) [PATCH RESEND v1 0/8] Introduce STM32 LVDS driver
In-Reply-To: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
Message-ID: <170323263335.3968091.3418124758627043970.b4-ty@linaro.org>

Hi,

On Thu, 21 Dec 2023 13:43:31 +0100, Raphael Gallais-Pou wrote:
> This serie introduces a new DRM bridge driver for STM32MP257 platforms
> based on Arm Cortex-35. It also adds an instance in the device-tree and
> handle the inclusion of the driver within the DRM framework. First patch
> adds a new panel compatible in the panel-lvds driver, which is used by
> default on the STM32MP257.
> 
> Raphael Gallais-Pou (7):
>   dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds
>   dt-bindings: display: add dt-bindings for STM32 LVDS device
>   drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
>   drm/stm: ltdc: add lvds pixel clock
>   arm64: dts: st: add ltdc support on stm32mp251
>   arm64: dts: st: add lvds support on stm32mp253
>   arm64: dts: st: add display support on stm32mp257f-ev
> 
> [...]

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)

[1/8] dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvds
      https://cgit.freedesktop.org/drm/drm-misc/commit/?id=021a81e7ac8f579b049e5bc76efabd9e67bd627c

-- 
Neil



From krzysztof.kozlowski at linaro.org  Fri Dec 22 00:12:04 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 22 Dec 2023 09:12:04 +0100
Subject: [PATCH v2 1/8] dt-bindings: clock: qcom: Allow VDD_GFX supply to
 GX
In-Reply-To: <20231220-sa8295p-gpu-v2-1-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-1-4763246b72c0@quicinc.com>
Message-ID: <26617c83-31b3-4ad9-8a61-0b8271fad41f@linaro.org>

On 22/12/2023 05:39, Bjorn Andersson wrote:
> In some designs the SoC's VDD_GFX pads are supplied by an external
> regulator, rather than a power-domain. Allow this to be described in the
> GPU clock controller binding.
> 
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>  Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> index f369fa34e00c..c0dd24c9dcb3 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> @@ -53,6 +53,9 @@ properties:
>    power-domains:
>      maxItems: 1
>  
> +  vdd-gfx-supply:
> +    description: Regulator supply for the VDD_GFX pads
> +
>    '#clock-cells':
>      const: 1
>  
> @@ -74,6 +77,19 @@ required:
>    - '#reset-cells'
>    - '#power-domain-cells'
>  
> +# Allow either power-domains or vdd-gfx-supply, not both
> +oneOf:
> +  - required:
> +      - power-domains
> +  - required:
> +      - vdd-gfx-supply

This should be enough, assuming one of them is actually required. The
code. See also:
https://elixir.bootlin.com/linux/v5.17-rc2/source/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml#L91

Best regards,
Krzysztof



From jensenhuang at friendlyarm.com  Fri Dec 22 00:22:26 2023
From: jensenhuang at friendlyarm.com (Jensen Huang)
Date: Fri, 22 Dec 2023 16:22:26 +0800
Subject: [PATCH v2] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <94bf6180-8abf-777d-2dce-498efafb57c1@collabora.com>
References: <20231207082200.16388-1-jensenhuang@friendlyarm.com>
 <ebf6cf8ec3b5befd673d295061fa2738@manjaro.org> <CAMpZ1qHUnTDQ78gdrQF9Sx_-XfLM-B+H-0bL1-+twKsno+JOvg@mail.gmail.com>
 <5e11553952c02ad20591992be4284bbd@manjaro.org> <95cc7716-ba01-e239-e7c0-eba0b7da7955@collabora.com>
 <CAMpZ1qENxWsDnvke4jMvK9tYpta3dThHUHxjDWO-u2JV+8dZdQ@mail.gmail.com> <94bf6180-8abf-777d-2dce-498efafb57c1@collabora.com>
Message-ID: <CAMpZ1qH1c1WuBmj6DQZjgxS-WyiWq8cbi499tLwwD5yRDhCnWA@mail.gmail.com>

On Wed, Dec 20, 2023 at 1:23?AM Wolfram Sang <wsa at kernel.org> wrote:
>
> On Thu, Dec 07, 2023 at 04:21:59PM +0800, Jensen Huang wrote:
> > Possible deadlock scenario (on reboot):
> > rk3x_i2c_xfer_common(polling)
> >     -> rk3x_i2c_wait_xfer_poll()
> >         -> rk3x_i2c_irq(0, i2c);
> >             --> spin_lock(&i2c->lock);
> >             ...
> >         <rk3x i2c interrupt>
> >         -> rk3x_i2c_irq(0, i2c);
> >             --> spin_lock(&i2c->lock); (deadlock here)
> >
> > Store the IRQ number and disable/enable it around the polling transfer.
> > This patch has been tested on NanoPC-T4.
> >
> > Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>
> > Reviewed-by: Heiko Stuebner <heiko at sntech.de>
> > Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
>
> Applied to for-current, thanks!
>
> But I'd like to see the follow-up patches somewhen which have been
> discussed in this thread.

I've made some attempts, such as removing irqsave/restore, but it
didn't meet my expectations and
requires further testing. Therefore, I may not be able to submit such
a patch in the short term. However,
if someone else submits a new patch, I'd be happy to test it on rk3328/rk3399.


On Fri, Dec 8, 2023 at 8:17?PM Dmitry Osipenko
<dmitry.osipenko at collabora.com> wrote:
>
> On 12/8/23 11:53, Jensen Huang wrote:
> > On Fri, Dec 8, 2023 at 12:00?AM Dmitry Osipenko
> > <dmitry.osipenko at collabora.com> wrote:
> >>
> >> On 12/7/23 17:10, Dragan Simic wrote:
> >>> On 2023-12-07 10:25, Jensen Huang wrote:
> >>>> On Thu, Dec 7, 2023 at 4:37?PM Dragan Simic <dsimic at manjaro.org> wrote:
> >>>>>
> >>>>> On 2023-12-07 09:21, Jensen Huang wrote:
> >>>>>> Possible deadlock scenario (on reboot):
> >>>>>> rk3x_i2c_xfer_common(polling)
> >>>>>>     -> rk3x_i2c_wait_xfer_poll()
> >>>>>>         -> rk3x_i2c_irq(0, i2c);
> >>>>>>             --> spin_lock(&i2c->lock);
> >>>>>>             ...
> >>>>>>         <rk3x i2c interrupt>
> >>>>>>         -> rk3x_i2c_irq(0, i2c);
> >>>>>>             --> spin_lock(&i2c->lock); (deadlock here)
> >>>>>>
> >>>>>> Store the IRQ number and disable/enable it around the polling
> >>>>> transfer.
> >>>>>> This patch has been tested on NanoPC-T4.
> >>>>>
> >>>>> In case you haven't already seen the related discussion linked below,
> >>>>> please have a look.  I also added more people to the list of recipients,
> >>>>> in an attempt to make everyone aware of the different approaches to
> >>>>> solving this issue.
> >>>>>
> >>>>> https://lore.kernel.org/all/655177f4.050a0220.d85c9.3ba0 at mx.google.com/T/#m6fc9c214452fec6681843e7f455978c35c6f6c8b
> >>>>
> >>>> Thank you for providing the information. I hadn't seen this link before.
> >>>> After carefully looking into the related discussion, it appears that
> >>>> Dmitry Osipenko is already working on a suitable patch. To avoid
> >>>> duplication
> >>>> or conflicts, my patch can be discarded.
> >>>
> >>> Thank you for responding so quickly.  Perhaps it would be best to hear
> >>> from Dmitry as well, before discarding anything.  It's been a while
> >>> since Dmitry wrote about working on the patch, so he might have
> >>> abandoned it.
> >>
> >> This patch is okay. In general, will be better to have IRQ disabled by
> >> default like I did in my variant, it should allow to remove the spinlock
> >> entirely. Of course this also can be done later on in a follow up
> >> patches. Jensen, feel free to use my variant of the patch, add my
> >> s-o-b+co-developed tags to the commit msg if you'll do. Otherwise I'll
> >> be able to send my patch next week.
> >
> > Thank you for the suggestion. I've updated the patch to your variant, and
> > as confirmed by others, reboots are functioning correctly. I measured the
> > overhead of enable_irq/disable_irq() by calculating ktime in the
> > updated version,
> > and on rk3399, the minimum delta I observed was 291/875 ns. This extra
> > cost may impact most interrupt-based transfers. Therefore, I personally lean
> > towards the current v2 patch and handle the spinlock and irqsave/restore in
> > a follow up patch. I'd like to hear everyone's thoughts on this.
>
> Please don't use ktime for perf measurements, ktime itself is a slow API
> and it should be 200us that ktime takes itself. Also, the 0.2us is
> practically nothing, especially compared to I2C transfers measured in ms.
>
> I'm fine with keeping your v2 variant for the bug fix if you prefer
> that. Thanks for addressing the issue :)

Thank you for clarifying the situation with ktime. Honestly, I also
believe that the overhead
of disable_irq/enable_irq should be minimal. Considering that system
frequency adjustments
involve I2C transfers, I conducted this 'somewhat imprecise' measurements.


--
Best regards,
Jensen


From xu.yang_2 at nxp.com  Fri Dec 22 00:24:04 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Fri, 22 Dec 2023 08:24:04 +0000
Subject: [EXT] Re: [PATCH v2 1/3] usb: chipidea: ci_hdrc_imx: add wakeup
 clock and keep it always on
In-Reply-To: <20231222034026.GA1951375@nchen-desktop>
References: <20231218061420.3460145-1-xu.yang_2@nxp.com>
 <20231222034026.GA1951375@nchen-desktop>
Message-ID: <DB7PR04MB5146CBDACACF5D85114A7AB08C94A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Peter,

> 
> On 23-12-18 14:14:18, Xu Yang wrote:
> > Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
> > on without usb driver intervention. And some may need driver to handle
> > this clock. For now only i.MX93 needs this wakeup clock. This patch will
> > get wakeup clock and keep it always on to make controller work properly.
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> >
> > ---
> > Changes in v2:
> >  - modify commit msg to make it clear
> > ---
> >  drivers/usb/chipidea/ci_hdrc_imx.c | 22 +++++++++++++++++++++-
> >  1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> > index e28bb2f2612d..4330be8240ff 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > @@ -96,6 +96,7 @@ struct ci_hdrc_imx_data {
> >       struct usb_phy *phy;
> >       struct platform_device *ci_pdev;
> >       struct clk *clk;
> > +     struct clk *clk_wakeup;
> >       struct imx_usbmisc_data *usbmisc_data;
> >       bool supports_runtime_pm;
> >       bool override_phy_control;
> > @@ -199,7 +200,7 @@ static int imx_get_clks(struct device *dev)
> >
> >       data->clk_ipg = devm_clk_get(dev, "ipg");
> >       if (IS_ERR(data->clk_ipg)) {
> > -             /* If the platform only needs one clocks */
> > +             /* If the platform only needs one primary clock */
> >               data->clk = devm_clk_get(dev, NULL);
> >               if (IS_ERR(data->clk)) {
> >                       ret = PTR_ERR(data->clk);
> > @@ -208,6 +209,18 @@ static int imx_get_clks(struct device *dev)
> >                               PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
> >                       return ret;
> >               }
> > +             /* Get wakeup clock. Not all of the platforms need to
> > +              * handle this clock. So make it optional.
> > +              */
> > +             data->clk_wakeup = devm_clk_get_optional(dev,
> > +                                                      "usb_wakeup_clk");
> > +             if (IS_ERR(data->clk_wakeup)) {
> > +                     ret = PTR_ERR(data->clk_wakeup);
> > +                     dev_err(dev,
> > +                             "Failed to get wakeup clk, err=%ld\n",
> > +                             PTR_ERR(data->clk_wakeup));
> > +                     return ret;
> > +             }
> >               return ret;
> >       }
> >
> > @@ -423,6 +436,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> >       if (ret)
> >               goto disable_hsic_regulator;
> >
> > +     ret = clk_prepare_enable(data->clk_wakeup);
> > +     if (ret)
> > +             goto err_wakeup_clk;
> > +
> 
> Better add at function imx_prepare_enable_clks()
> 
> >       data->phy = devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0);
> >       if (IS_ERR(data->phy)) {
> >               ret = PTR_ERR(data->phy);
> > @@ -504,6 +521,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> >  disable_device:
> >       ci_hdrc_remove_device(data->ci_pdev);
> >  err_clk:
> > +     clk_disable_unprepare(data->clk_wakeup);
> > +err_wakeup_clk:
> 
> 
> Better add clk_disable_unprepare for wakeup clk at function
> imx_disable_unprepare_clks();

According to IC degin's suggestion, 32K clock should be enabled
all the time. Since imx_prepare_enable_clks and imx_disable_unprepare_clks()
will be dynamiclly called in runtime/system PM cases,  I don't want
32K clock go though such path. Therefore, I didn't put clk_prepare_enable/
clk_disable_unprepare() in that functions.

Thanks,
Xu Yang

> 
> Peter
> 
> >       imx_disable_unprepare_clks(dev);
> >  disable_hsic_regulator:
> >       if (data->hsic_pad_regulator)
> > @@ -530,6 +549,7 @@ static void ci_hdrc_imx_remove(struct platform_device *pdev)
> >               usb_phy_shutdown(data->phy);
> >       if (data->ci_pdev) {
> >               imx_disable_unprepare_clks(&pdev->dev);
> > +             clk_disable_unprepare(data->clk_wakeup);
> >               if (data->plat_data->flags & CI_HDRC_PMQOS)
> >                       cpu_latency_qos_remove_request(&data->pm_qos_req);
> >               if (data->hsic_pad_regulator)
> > --
> > 2.34.1
> >
> >
> 
> --
> 
> Thanks,
> Peter Chen


From william-tw.lin at mediatek.com  Fri Dec 22 00:07:38 2023
From: william-tw.lin at mediatek.com (William-tw Lin)
Date: Fri, 22 Dec 2023 16:07:38 +0800
Subject: [PATCH v4 2/3] soc: mediatek: mtk-socinfo: Add driver for getting chip information
In-Reply-To: <20231222080739.21706-1-william-tw.lin@mediatek.com>
References: <20231222080739.21706-1-william-tw.lin@mediatek.com>
Message-ID: <20231222080739.21706-3-william-tw.lin@mediatek.com>

Add driver for socinfo retrieval. This patch includes the following:
1. mtk-socinfo driver for chip info retrieval
2. Related changes to Makefile and Kconfig

Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
---
 drivers/soc/mediatek/Kconfig       |   9 ++
 drivers/soc/mediatek/Makefile      |   1 +
 drivers/soc/mediatek/mtk-socinfo.c | 186 +++++++++++++++++++++++++++++
 3 files changed, 196 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-socinfo.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 0810b5b0c688..50c664b65f4d 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -68,4 +68,13 @@ config MTK_SVS
 	  chip process corner, temperatures and other factors. Then DVFS
 	  driver could apply SVS bank voltage to PMIC/Buck.
 
+config MTK_SOCINFO
+	tristate "MediaTek SoC Information"
+	default y
+	depends on NVMEM_MTK_EFUSE
+	help
+	  The MediaTek SoC Information (mtk-socinfo) driver provides
+	  information about the SoC to the userspace including the
+	  manufacturer name, marketing name and soc name.
+
 endmenu
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 9d3ce7878c5c..6830512848fd 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_MTK_REGULATOR_COUPLER) += mtk-regulator-coupler.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
 obj-$(CONFIG_MTK_SVS) += mtk-svs.o
+obj-$(CONFIG_MTK_SOCINFO) += mtk-socinfo.o
diff --git a/drivers/soc/mediatek/mtk-socinfo.c b/drivers/soc/mediatek/mtk-socinfo.c
new file mode 100644
index 000000000000..0094f43e1e08
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-socinfo.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pm_runtime.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/device.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+#include <linux/string.h>
+#include <linux/sys_soc.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+
+#define MTK_SOCINFO_ENTRY(_soc_name, _segment_name, _marketing_name, _cell_data1, _cell_data2) {\
+	.soc_name = _soc_name,									\
+	.segment_name = _segment_name,								\
+	.marketing_name = _marketing_name,							\
+	.cell_data = {_cell_data1, _cell_data2}							\
+}
+#define CELL_NOT_USED (0xFFFFFFFF)
+#define MAX_CELLS (2)
+
+struct mtk_socinfo {
+	struct device *dev;
+	struct name_data *name_data;
+	struct socinfo_data *socinfo_data;
+	struct soc_device *soc_dev;
+};
+
+struct socinfo_data {
+	char *soc_name;
+	char *segment_name;
+	char *marketing_name;
+	u32 cell_data[MAX_CELLS];
+};
+
+static const char *cell_names[MAX_CELLS] = {"socinfo-data1", "socinfo-data2"};
+
+static struct socinfo_data socinfo_data_table[] = {
+	MTK_SOCINFO_ENTRY("MT8173", "MT8173V/AC", "MT8173", 0x6CA20004, 0x10000000),
+	MTK_SOCINFO_ENTRY("MT8183", "MT8183V/AZA", "Kompanio 500", 0x00010043, 0x00000840),
+	MTK_SOCINFO_ENTRY("MT8186", "MT8186GV/AZA", "Kompanio 520", 0x81861001, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8186T", "MT8186TV/AZA", "Kompanio 528", 0x81862001, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8188", "MT8188GV/AZA", "Kompanio 830", 0x81880000, 0x00000010),
+	MTK_SOCINFO_ENTRY("MT8188", "MT8188GV/HZA", "Kompanio 830", 0x81880000, 0x00000011),
+	MTK_SOCINFO_ENTRY("MT8192", "MT8192V/AZA", "Kompanio 820", 0x00001100, 0x00040080),
+	MTK_SOCINFO_ENTRY("MT8192T", "MT8192V/ATZA", "Kompanio 828", 0x00000100, 0x000400C0),
+	MTK_SOCINFO_ENTRY("MT8195", "MT8195GV/EZA", "Kompanio 1200", 0x81950300, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8195", "MT8195GV/EHZA", "Kompanio 1200", 0x81950304, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8195", "MT8195TV/EZA", "Kompanio 1380", 0x81950400, CELL_NOT_USED),
+	MTK_SOCINFO_ENTRY("MT8195", "MT8195TV/EHZA", "Kompanio 1380", 0x81950404, CELL_NOT_USED),
+};
+
+static int mtk_socinfo_create_socinfo_node(struct mtk_socinfo *mtk_socinfop)
+{
+	struct soc_device_attribute *attrs;
+	static char machine[30] = {0};
+	static const char *soc_manufacturer = "MediaTek";
+
+	attrs = devm_kzalloc(mtk_socinfop->dev, sizeof(*attrs), GFP_KERNEL);
+	if (!attrs)
+		return -ENOMEM;
+
+	snprintf(machine, sizeof(machine), "%s (%s)", mtk_socinfop->socinfo_data->marketing_name,
+		mtk_socinfop->socinfo_data->soc_name);
+	attrs->family = soc_manufacturer;
+	attrs->machine = machine;
+
+	mtk_socinfop->soc_dev = soc_device_register(attrs);
+	if (IS_ERR(mtk_socinfop->soc_dev))
+		return PTR_ERR(mtk_socinfop->soc_dev);
+
+	dev_info(mtk_socinfop->dev, "%s %s SoC detected.\n", soc_manufacturer, attrs->machine);
+	return 0;
+}
+
+static u32 mtk_socinfo_read_cell(struct device *dev, const char *name)
+{
+	struct nvmem_device *nvmemp;
+	struct device_node *np = dev->of_node;
+	u32 offset;
+	u32 cell_val = CELL_NOT_USED;
+
+	nvmemp = devm_nvmem_device_get(dev, "mtk-efuse0");
+	if (IS_ERR(nvmemp))
+		goto out;
+
+	np = of_find_node_by_name(NULL, name);
+	if (!np)
+		goto out;
+
+	if (of_property_read_u32_index(np, "reg", 0, &offset))
+		goto out;
+
+	nvmem_device_read(nvmemp, offset, sizeof(cell_val), &cell_val);
+
+	nvmem_device_put(nvmemp);
+
+out:
+	return cell_val;
+}
+
+static int mtk_socinfo_get_socinfo_data(struct mtk_socinfo *mtk_socinfop)
+{
+	unsigned int i, j;
+	unsigned int num_cell_data = 0;
+	u32 cell_data[MAX_CELLS] = {0};
+	bool match_socinfo;
+	int match_socinfo_index = -1;
+
+	for (i = 0; i < MAX_CELLS; i++) {
+		cell_data[i] = mtk_socinfo_read_cell(mtk_socinfop->dev, cell_names[i]);
+		if (cell_data[i] != CELL_NOT_USED)
+			num_cell_data++;
+		else
+			break;
+	}
+
+	if (!num_cell_data)
+		return -ENOENT;
+
+	for (i = 0; i < ARRAY_SIZE(socinfo_data_table); i++) {
+		match_socinfo = true;
+		for (j = 0; j < num_cell_data; j++) {
+			if (cell_data[j] != socinfo_data_table[i].cell_data[j]) {
+				match_socinfo = false;
+				break;
+			}
+		}
+		if (match_socinfo) {
+			mtk_socinfop->socinfo_data = &(socinfo_data_table[i]);
+			match_socinfo_index = i;
+			break;
+		}
+	}
+
+	return match_socinfo_index >= 0 ? match_socinfo_index : -ENOENT;
+}
+
+static int mtk_socinfo_probe(struct platform_device *pdev)
+{
+	struct mtk_socinfo *mtk_socinfop;
+	int ret;
+
+	mtk_socinfop = devm_kzalloc(&pdev->dev, sizeof(*mtk_socinfop), GFP_KERNEL);
+	if (!mtk_socinfop)
+		return -ENOMEM;
+
+	mtk_socinfop->dev = &pdev->dev;
+
+	ret = mtk_socinfo_get_socinfo_data(mtk_socinfop);
+	if (ret < 0)
+		return dev_err_probe(mtk_socinfop->dev, ret, "Failed to get socinfo data\n");
+
+	ret = mtk_socinfo_create_socinfo_node(mtk_socinfop);
+	if (ret)
+		return dev_err_probe(mtk_socinfop->dev, ret, "Cannot create node\n");
+
+	platform_set_drvdata(pdev, mtk_socinfop);
+	return 0;
+}
+
+static void mtk_socinfo_remove(struct platform_device *pdev)
+{
+	struct mtk_socinfo *mtk_socinfop = platform_get_drvdata(pdev);
+
+	soc_device_unregister(mtk_socinfop->soc_dev);
+}
+
+static struct platform_driver mtk_socinfo = {
+	.probe = mtk_socinfo_probe,
+	.remove_new = mtk_socinfo_remove,
+	.driver = {
+		.name = "mtk-socinfo",
+	},
+};
+module_platform_driver(mtk_socinfo);
+
+MODULE_AUTHOR("William-TW LIN <william-tw.lin at mediatek.com>");
+MODULE_DESCRIPTION("MediaTek socinfo driver");
+MODULE_LICENSE("GPL");
-- 
2.18.0



From william-tw.lin at mediatek.com  Fri Dec 22 00:07:37 2023
From: william-tw.lin at mediatek.com (William-tw Lin)
Date: Fri, 22 Dec 2023 16:07:37 +0800
Subject: [PATCH v4 1/3] arm64: dts: mediatek: Add socinfo efuses to MT8173/83/96/92/95 SoCs
In-Reply-To: <20231222080739.21706-1-william-tw.lin@mediatek.com>
References: <20231222080739.21706-1-william-tw.lin@mediatek.com>
Message-ID: <20231222080739.21706-2-william-tw.lin@mediatek.com>

Add efuse nodes for socinfo retrieval for MT8173, MT8183, MT8186,
MT8192 and MT8195.

Signed-off-by: William-tw Lin <william-tw.lin at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +++++++++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 9 +++++++++
 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 8 ++++++++
 arch/arm64/boot/dts/mediatek/mt8195.dtsi | 3 +++
 5 files changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index c47d7d900f28..0f4aab80d5e4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -590,6 +590,15 @@
 			reg = <0 0x10206000 0 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+
+			socinfo-data1 at 40 {
+				reg = <0x040 0x4>;
+			};
+
+			socinfo-data2 at 44 {
+				reg = <0x044 0x4>;
+			};
+
 			thermal_calibration: calib at 528 {
 				reg = <0x528 0xc>;
 			};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 976dc968b3ca..1fe351b710ed 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1585,6 +1585,15 @@
 			reg = <0 0x11f10000 0 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+
+			socinfo-data1 at 4c {
+				reg = <0x04c 0x4>;
+			};
+
+			socinfo-data2 at 60 {
+				reg = <0x060 0x4>;
+			};
+
 			thermal_calibration: calib at 180 {
 				reg = <0x180 0xc>;
 			};
diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index df0c04f2ba1d..7dd0ae965ee0 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1672,6 +1672,10 @@
 				reg = <0x59c 0x4>;
 				bits = <0 3>;
 			};
+
+			socinfo-data1 at 7a0 {
+				reg = <0x7a0 0x4>;
+			};
 		};
 
 		mipi_tx0: dsi-phy at 11cc0000 {
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 69f4cded5dbb..85f2c49be6fc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -1120,6 +1120,14 @@
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			socinfo-data1 at 44 {
+				reg = <0x044 0x4>;
+			};
+
+			socinfo-data2 at 50 {
+				reg = <0x050 0x4>;
+			};
+
 			lvts_e_data1: data1 at 1c0 {
 				reg = <0x1c0 0x58>;
 			};
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index e0ac2e9f5b72..520f7b649cb2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -1686,6 +1686,9 @@
 			lvts_efuse_data2: lvts2-calib at 1d0 {
 				reg = <0x1d0 0x38>;
 			};
+			socinfo-data1 at 7a0 {
+				reg = <0x7a0 0x4>;
+			};
 		};
 
 		u3phy2: t-phy at 11c40000 {
-- 
2.18.0



From raphael.gallais-pou at foss.st.com  Fri Dec 22 00:45:59 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Fri, 22 Dec 2023 09:45:59 +0100
Subject: [PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings for
 STM32 LVDS device
In-Reply-To: <170316995910.3869238.14321525013510097521.robh@kernel.org>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
 <20231221124339.420119-3-raphael.gallais-pou@foss.st.com>
 <170316995910.3869238.14321525013510097521.robh@kernel.org>
Message-ID: <5c5fde3c-8073-430c-b9e6-b3e6d84eddee@foss.st.com>

Hi Rob

On 12/21/23 15:45, Rob Herring wrote:
> On Thu, 21 Dec 2023 13:43:33 +0100, Raphael Gallais-Pou wrote:
>> Add dt-binding file for "st,stm32-lvds" compatible.
>>
>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
>> ---
>>  .../bindings/display/st,stm32-lvds.yaml       | 114 ++++++++++++++++++
>>  1 file changed, 114 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
>>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/display/st,stm32-lvds.example.dts:18:18: fatal error: dt-bindings/bus/stm32mp25_sys_bus.h: No such file or directory
>    18 |         #include <dt-bindings/bus/stm32mp25_sys_bus.h>
>       |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/st,stm32-lvds.example.dtb] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: dt_binding_check] Error 2
> make: *** [Makefile:234: __sub-make] Error 2

This is because I forgot to remove this line from the example. I'll remove it in V2.


Thanks,

Rapha?l


> doc reference errors (make refcheckdocs):
>
> See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231221124339.420119-3-raphael.gallais-pou at foss.st.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>


From raphael.gallais-pou at foss.st.com  Fri Dec 22 00:48:38 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Fri, 22 Dec 2023 09:48:38 +0100
Subject: [PATCH v1 2/8] dt-bindings: display: add dt-bindings for STM32
 LVDS device
In-Reply-To: <fcd68fbe-c543-4b6d-9b7f-bcea09918fb9@linaro.org>
References: <20231221122843.418650-1-raphael.gallais-pou@foss.st.com>
 <20231221122843.418650-3-raphael.gallais-pou@foss.st.com>
 <fcd68fbe-c543-4b6d-9b7f-bcea09918fb9@linaro.org>
Message-ID: <24110918-5402-4877-a80f-db1228afeaa1@foss.st.com>

Hi Krzysztof,


Thanks for your review. I wall send another serie later with those modifications.


Best regards,

Rapha?l


On 12/21/23 18:27, Krzysztof Kozlowski wrote:
> On 21/12/2023 13:28, Raphael Gallais-Pou wrote:
>> Add dt-binding file for "st,stm32-lvds" compatible.
>>
> A nit, subject: drop second/last, redundant "dt-bindings for". The
> "dt-bindings" prefix is already stating that these are bindings.
>
>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
>> ---
>>  .../bindings/display/st,stm32-lvds.yaml       | 114 ++++++++++++++++++
>>  1 file changed, 114 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
>>
> ...
>
>> +properties:
>> +  "#clock-cells":
>> +    const: 0
>> +
>> +  compatible:
>> +    const: st,stm32-lvds
> Please put compatible as first.
>
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    items:
>> +      - description: APB peripheral clock
>> +      - description: Reference clock for the internal PLL
>> +
>> +  clock-names:
>> +    items:
>> +      - const: pclk
>> +      - const: ref
>> +
>> +  resets:
>> +    maxItems: 1
>> +
>> +  ports:
>> +    $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +    properties:
>> +      port at 0:
>> +        $ref: /schemas/graph.yaml#/properties/port
>> +        description: |
>> +          LVDS input port node, connected to the LTDC RGB output port.
>> +
>> +      port at 1:
>> +        $ref: /schemas/graph.yaml#/properties/port
>> +        description: |
>> +          LVDS output port node, connected to a panel or bridge input port.
> Ports are not required? I would assume it won't work without input and
> output.
>
>> +
>> +required:
>> +  - "#clock-cells"
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - clock-names
>> +  - resets
>> +  - ports
>> +
>> +unevaluatedProperties: false
> additionalProperties instead... or did I miss some $ref anywhere?
>
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/bus/stm32mp25_sys_bus.h>
>> +    #include <dt-bindings/clock/stm32mp25-clks.h>
>> +    #include <dt-bindings/reset/stm32mp25-resets.h>
>> +
>> +    lvds: lvds at 48060000 {
>> +        #clock-cells = <0>;
>> +        compatible = "st,stm32-lvds";
> compatible is always the first property.
>
>> +        reg = <0x48060000 0x2000>;
> put clock-cells here
>
>> +        clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
>> +        clock-names = "pclk", "ref";
>> +        resets = <&rcc LVDS_R>;
> Best regards,
> Krzysztof
>


From piotr.firek at financialflows.pl  Fri Dec 22 00:50:57 2023
From: piotr.firek at financialflows.pl (Piotr Firek)
Date: Fri, 22 Dec 2023 08:50:57 GMT
Subject: =?UTF-8?Q?Prosz=C4=99_o_kontakt?=
Message-ID: <20231222074501-0.1.1q.8i4i.0.faq75v9mc5@financialflows.pl>

Dzie? dobry,

Czy jest mo?liwo?? nawi?zania wsp??pracy z Pa?stwem?

Z ch?ci? porozmawiam z osob? zajmuj?c? si? dzia?aniami zwi?zanymi ze sprzeda??.

Pomagamy skutecznie pozyskiwa? nowych klient?w.

Zapraszam do kontaktu.


Pozdrawiam
Piotr Firek


From raphael.gallais-pou at foss.st.com  Fri Dec 22 00:55:36 2023
From: raphael.gallais-pou at foss.st.com (Raphael Gallais-Pou)
Date: Fri, 22 Dec 2023 09:55:36 +0100
Subject: [PATCH RESEND v1 2/8] dt-bindings: display: add dt-bindings for
 STM32 LVDS device
In-Reply-To: <88834783-5aea-46d2-82cc-dd22cb4473f5@linaro.org>
References: <20231221124339.420119-1-raphael.gallais-pou@foss.st.com>
 <20231221124339.420119-3-raphael.gallais-pou@foss.st.com>
 <88834783-5aea-46d2-82cc-dd22cb4473f5@linaro.org>
Message-ID: <024f56fd-6fe2-4a6f-a5a0-2ef06faa653a@foss.st.com>


On 12/21/23 21:36, Krzysztof Kozlowski wrote:
> On 21/12/2023 13:43, Raphael Gallais-Pou wrote:
>> Add dt-binding file for "st,stm32-lvds" compatible.
>>
>> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou at foss.st.com>
>> ---
> I don't know why this was resend, nothing explains it, but I already
> commented on other version.
>
> Please respond to comments there.
>
> In the future, unless it is obvious resend over 2 weeks, say why you are
> doing it and what changed.

My proxy tends to block every patch after a batch of 4 or 5 patches. Since it
splitted the serie in half I resent it so that the serie could be entirely read
without problems. This explains the resend. I was not sure about putting a short
explanation in the cover letter since it was not related any change in the
serie, but next time I will do so.

Best Regards,

Rapha?l


>
> Best regards,
> Krzysztof
>


From frank at oltmanns.dev  Fri Dec 22 01:10:25 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Fri, 22 Dec 2023 10:10:25 +0100
Subject: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher
 clock rate
In-Reply-To: <875y0sacmz.fsf@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev>
 <1845418.atdPhlSkOF@jernej-laptop> <875y0sacmz.fsf@oltmanns.dev>
Message-ID: <87v88qk3ge.fsf@oltmanns.dev>


On 2023-12-20 at 19:57:06 +0100, Frank Oltmanns <frank at oltmanns.dev> wrote:
> Ok, I've done more detailed testing, and it seems this patch results in
> lots of dropped frames. I'm sorry for not being more thorough earlier.
> I'll do some more testing without this patch and might have to either
> remove it from V2 of this series.
>
> I need to see if the same stability can be achieved when running
> PLL-MIPI outside its specied range.

I've done some more (load) testing and observing the panel for dropped
frames.

The conclusion I draw from those results is that this patch isn't
necessary for the pinephone. It would be enough to use the correct clock
rate based on the existing values [*]:
-	.clock	     = 69000,
+	.clock	     = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000,

I've asked in the postmarketOS community for a bit more testing. They
already have a merge request that contains these changes [2].

This means that we would continue to drive PLL-MIPI outside it's
specified range. I have, so far, not experienced any downside of doing
so. It seems enough to fix the ratios that are part of the first four
patches in this series without introducing a min and max rate.

In conclusion, I'll soon (after some more feedback from the fine folks
at postmarketOS) submit a V2 that addresses the fixes requested in the
first four patches of this series. I'll drop the existing PATCH 5 and
replace it with the one I sent in February [1] instead.

After that, just for fun, I'll probably look into min_rate and max_rate
for nkm clocks and which consequences it has on the pinephone. I might
or might not send a follow up series for that. However, if the pinephone
runs stable without it, it's not a high priority for me.

Best regards,
  Frank

[*] I've already submitted a patch in February '23 [1]. It was of little
    use back then because the A64's PLL-MIPI clock was not able to run
    close to that rate. But since kernel 6.6 PLL-MIPI is able to set
    it's parent rate, so that it can come quite close to the required
    rate:
     + Panel requires 74.844 MHz with the current timings.
     +-> tcon-data-clock rate should be 112.266 MHz (panel*24/4/4).
      +-> PLL-MIPI rate should be 449.064 MHz (TCON0 * 4)

    The 6.6 kernel the following rates are possible:
     + PLL-MIPI: ~448.984615 MHz
     +-> tcon-data-clock: ~112.246153
      +-> panel: ~74.830768 MHz

    Which leaves us with a vertical refresh rate of ~59.989 Hz,
    deviating less then 0.2% from the ideal 60Hz. That's probably closer
    than the accumulated accuracy of all involved components can
    reliably achieve. I'd say, let's leave it at that.

[1]: https://lore.kernel.org/lkml/20230219114553.288057-2-frank at oltmanns.dev/
[2]: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4645
>
> Best regards,
>   Frank
>
> On 2023-12-20 at 16:18:49 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
>> Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a):
>>>
>>> On 2023-12-19 at 18:04:29 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
>>> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns napisal(a):
>>> >> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
>>> >> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
>>> >> than 500 MHz.
>>> >>
>>> >> Therefore, change [hv]sync_(start|end) so that we reach a clock rate
>>> >> that is high enough to drive PLL-MIPI within its limits.
>>> >>
>>> >> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
>>> >
>>> > I'm not too sure about this patch. I see that PLL_MIPI doesn't have set
>>> > minimum frequency limit in clock driver. If you add it, clock framework
>>> > should find rate that is high enough and divisible with target rate.
>>>
>>> This one is really a tough nut. Unfortunately, the PLL_MIPI clock for
>>> this panel has to run exactly at 6 * panel clock. Let me start by
>>> showing the relevant part of the clock tree (this is on the pinephone
>>> after applying the patches):
>>>     pll-video0                 393600000
>>>        pll-mipi                500945454
>>>           tcon0                500945454
>>>              tcon-data-clock   125236363
>>>
>>> To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit
>>> rate [1]. It's a fixed divisor
>>>
>>> The panel I'm proposing to change is defined as this:
>>>
>>>     static const struct st7703_panel_desc xbd599_desc = {
>>>     	.mode = &xbd599_mode,
>>>     	.lanes = 4,
>>>     	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
>>>     	.format = MIPI_DSI_FMT_RGB888,
>>>     	.init_sequence = xbd599_init_sequence,
>>>     };
>>>
>>> So, we have 24 bpp and 4 lanes. Therefore, the resulting requested
>>> tcon-data-clock rate is
>>>     crtc_clock * 1000 * (24 / 4) / 4
>>>
>>> tcon-data-clock therefore requests a parent rate of
>>>     4 * (crtc_clock * 1000 * (24 / 4) / 4)
>>>
>>> The initial 4 is the fixed divisor between tcon0 and tcon-data-clock.
>>> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi.
>>>
>>> Since PLL-MIPI has to run at at least at 500MHz this forces us to have a
>>> crtc_clock >= 83.333 MHz. The mode I'm prorposing results in a rate of
>>> 83.502 MHz.
>>
>> This is much better explanation why this change is needed. Still, I think
>> adding min and max rate to PLL_MIPI would make sense, so proper rates
>> are guaranteed.
>>
>> Anyway, do you know where are all those old values come from? And how did
>> you come up with new ones? I guess you can't just simply change timings,
>> there are probably some HW limitations? Do you know if BSP kernel support
>> this panel and how this situation is solved there?
>>
>>>
>>> If we only changed the constraints on the PLL_MIPI without changing the
>>> panel mode, we end up with a mismatch. This, in turn, would result in
>>> dropped frames, right?
>>
>> From what I read, I think frame rate would be higher than 60 fps. What
>> exactly would happen depends on the panel.
>>
>> Best regards,
>> Jernej
>>
>>>
>>> Best regards,
>>>   Frank
>>>
>>> [1] Source:
>>> https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/sun4i_tcon.c#L346
>>>
>>> >
>>> > Best regards,
>>> > Jernej
>>> >
>>> >> ---
>>> >>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++-------
>>> >>  1 file changed, 7 insertions(+), 7 deletions(-)
>>> >>
>>> >> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>>> >> index b55bafd1a8be..6886fd7f765e 100644
>>> >> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>>> >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>>> >> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
>>> >>
>>> >>  static const struct drm_display_mode xbd599_mode = {
>>> >>  	.hdisplay    = 720,
>>> >> -	.hsync_start = 720 + 40,
>>> >> -	.hsync_end   = 720 + 40 + 40,
>>> >> -	.htotal	     = 720 + 40 + 40 + 40,
>>> >> +	.hsync_start = 720 + 65,
>>> >> +	.hsync_end   = 720 + 65 + 65,
>>> >> +	.htotal      = 720 + 65 + 65 + 65,
>>> >>  	.vdisplay    = 1440,
>>> >> -	.vsync_start = 1440 + 18,
>>> >> -	.vsync_end   = 1440 + 18 + 10,
>>> >> -	.vtotal	     = 1440 + 18 + 10 + 17,
>>> >> -	.clock	     = 69000,
>>> >> +	.vsync_start = 1440 + 30,
>>> >> +	.vsync_end   = 1440 + 30 + 22,
>>> >> +	.vtotal	     = 1440 + 30 + 22 + 29,
>>> >> +	.clock	     = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
>>> >>  	.flags	     = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
>>> >>  	.width_mm    = 68,
>>> >>  	.height_mm   = 136,
>>> >>
>>> >>
>>>


From Markus.Elfring at web.de  Fri Dec 22 01:23:13 2023
From: Markus.Elfring at web.de (Markus Elfring)
Date: Fri, 22 Dec 2023 10:23:13 +0100
Subject: [PATCH] clk: imx: scu: Use common error handling code in
 __imx_clk_gpr_scu()
In-Reply-To: <20231210171907.3410922-1-visitorckw@gmail.com>
References: <20231210171907.3410922-1-visitorckw@gmail.com>
Message-ID: <0e906ec6-fe73-4dbd-b555-a2c03b6e1030@web.de>

From: Markus Elfring <elfring at users.sourceforge.net>
Date: Fri, 22 Dec 2023 10:05:32 +0100

Use another label so that a bit of exception handling can be better reused
at the end of this function.

Signed-off-by: Markus Elfring <elfring at users.sourceforge.net>
---
 drivers/clk/imx/clk-scu.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c
index e48a904c0013..4ca9dccf3d3b 100644
--- a/drivers/clk/imx/clk-scu.c
+++ b/drivers/clk/imx/clk-scu.c
@@ -882,19 +882,19 @@ struct clk_hw *__imx_clk_gpr_scu(const char *name, const char * const *parent_na
 		return ERR_PTR(-ENOMEM);

 	if (!imx_scu_clk_is_valid(rsrc_id)) {
-		kfree(clk_node);
-		return ERR_PTR(-EINVAL);
+		ret = -EINVAL;
+		goto free_clk_node;
 	}

 	if (!imx_clk_is_resource_owned(rsrc_id)) {
-		kfree(clk_node);
-		return NULL;
+		ret = 0;
+		goto free_clk_node;
 	}

 	clk = kzalloc(sizeof(*clk), GFP_KERNEL);
 	if (!clk) {
-		kfree(clk_node);
-		return ERR_PTR(-ENOMEM);
+		ret = -ENOMEM;
+		goto free_clk_node;
 	}

 	clk->rsrc_id = rsrc_id;
@@ -922,6 +922,7 @@ struct clk_hw *__imx_clk_gpr_scu(const char *name, const char * const *parent_na
 	ret = clk_hw_register(NULL, hw);
 	if (ret) {
 		kfree(clk);
+free_clk_node:
 		kfree(clk_node);
 		hw = ERR_PTR(ret);
 	} else {
--
2.43.0



From peter.chen at kernel.org  Fri Dec 22 01:25:42 2023
From: peter.chen at kernel.org (Peter Chen)
Date: Fri, 22 Dec 2023 17:25:42 +0800
Subject: [PATCH v2 1/3] usb: chipidea: ci_hdrc_imx: add wakeup clock and
 keep it always on
In-Reply-To: <20231218061420.3460145-1-xu.yang_2@nxp.com>
References: <20231218061420.3460145-1-xu.yang_2@nxp.com>
Message-ID: <20231222092542.GC1951375@nchen-desktop>

On 23-12-18 14:14:18, Xu Yang wrote:
> Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
> on without usb driver intervention. And some may need driver to handle
> this clock. For now only i.MX93 needs this wakeup clock. This patch will
> get wakeup clock and keep it always on to make controller work properly.
> 
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

Acked-by: Peter Chen <peter.chen at kernel.org>

> 
> ---
> Changes in v2:
>  - modify commit msg to make it clear
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> index e28bb2f2612d..4330be8240ff 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -96,6 +96,7 @@ struct ci_hdrc_imx_data {
>  	struct usb_phy *phy;
>  	struct platform_device *ci_pdev;
>  	struct clk *clk;
> +	struct clk *clk_wakeup;
>  	struct imx_usbmisc_data *usbmisc_data;
>  	bool supports_runtime_pm;
>  	bool override_phy_control;
> @@ -199,7 +200,7 @@ static int imx_get_clks(struct device *dev)
>  
>  	data->clk_ipg = devm_clk_get(dev, "ipg");
>  	if (IS_ERR(data->clk_ipg)) {
> -		/* If the platform only needs one clocks */
> +		/* If the platform only needs one primary clock */
>  		data->clk = devm_clk_get(dev, NULL);
>  		if (IS_ERR(data->clk)) {
>  			ret = PTR_ERR(data->clk);
> @@ -208,6 +209,18 @@ static int imx_get_clks(struct device *dev)
>  				PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
>  			return ret;
>  		}
> +		/* Get wakeup clock. Not all of the platforms need to
> +		 * handle this clock. So make it optional.
> +		 */
> +		data->clk_wakeup = devm_clk_get_optional(dev,
> +							 "usb_wakeup_clk");
> +		if (IS_ERR(data->clk_wakeup)) {
> +			ret = PTR_ERR(data->clk_wakeup);
> +			dev_err(dev,
> +				"Failed to get wakeup clk, err=%ld\n",
> +				PTR_ERR(data->clk_wakeup));
> +			return ret;
> +		}
>  		return ret;
>  	}
>  
> @@ -423,6 +436,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto disable_hsic_regulator;
>  
> +	ret = clk_prepare_enable(data->clk_wakeup);
> +	if (ret)
> +		goto err_wakeup_clk;
> +
>  	data->phy = devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0);
>  	if (IS_ERR(data->phy)) {
>  		ret = PTR_ERR(data->phy);
> @@ -504,6 +521,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  disable_device:
>  	ci_hdrc_remove_device(data->ci_pdev);
>  err_clk:
> +	clk_disable_unprepare(data->clk_wakeup);
> +err_wakeup_clk:
>  	imx_disable_unprepare_clks(dev);
>  disable_hsic_regulator:
>  	if (data->hsic_pad_regulator)
> @@ -530,6 +549,7 @@ static void ci_hdrc_imx_remove(struct platform_device *pdev)
>  		usb_phy_shutdown(data->phy);
>  	if (data->ci_pdev) {
>  		imx_disable_unprepare_clks(&pdev->dev);
> +		clk_disable_unprepare(data->clk_wakeup);
>  		if (data->plat_data->flags & CI_HDRC_PMQOS)
>  			cpu_latency_qos_remove_request(&data->pm_qos_req);
>  		if (data->hsic_pad_regulator)
> -- 
> 2.34.1
> 
> 

-- 

Thanks,
Peter Chen


From peter.chen at kernel.org  Fri Dec 22 01:28:42 2023
From: peter.chen at kernel.org (Peter Chen)
Date: Fri, 22 Dec 2023 17:28:42 +0800
Subject: [PATCH v2 3/3] usb: phy: mxs: remove CONFIG_USB_OTG condition
 for mxs_phy_is_otg_host()
In-Reply-To: <20231218061420.3460145-3-xu.yang_2@nxp.com>
References: <20231218061420.3460145-1-xu.yang_2@nxp.com>
 <20231218061420.3460145-3-xu.yang_2@nxp.com>
Message-ID: <20231222092842.GD1951375@nchen-desktop>

On 23-12-18 14:14:20, Xu Yang wrote:
> When CONFIG_USB_OTG is not set, mxs_phy_is_otg_host() will always return
> false. This behaviour is wrong. Since phy.last_event will always be set
> for either host or device mode. Therefore, CONFIG_USB_OTG condition
> can be removed.
> 
> Fixes: 5eda42aebb76 ("usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host()")
> cc: <stable at vger.kernel.org>
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

Acked-by: Peter Chen <peter.chen at kernel.org>
> 
> ---
> Changes in v2:
>  - add fix tag and stable maillist
> ---
>  drivers/usb/phy/phy-mxs-usb.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index acd46b72899e..920a32cd094d 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -388,8 +388,7 @@ static void __mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool disconnect)
>  
>  static bool mxs_phy_is_otg_host(struct mxs_phy *mxs_phy)
>  {
> -	return IS_ENABLED(CONFIG_USB_OTG) &&
> -		mxs_phy->phy.last_event == USB_EVENT_ID;
> +	return mxs_phy->phy.last_event == USB_EVENT_ID;
>  }
>  
>  static void mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool on)
> -- 
> 2.34.1
> 

-- 

Thanks,
Peter Chen


From contact at emersion.fr  Fri Dec 22 01:40:18 2023
From: contact at emersion.fr (Simon Ser)
Date: Fri, 22 Dec 2023 09:40:18 +0000
Subject: [PATCH v3 0/7] dma-buf: heaps: Add secure heap
In-Reply-To: <20231213161614.43e5bca8@eldfell>
References: <20231212024607.3681-1-yong.wu@mediatek.com> <DPBmATfmfvSP8Cwjz99kj_JvCEiAqRfuMFJZEBF2aIgl8NZqWFR66eyPTX1E8bHyOlimBihEE3E80p9bfOJ-0SNu8pwoIzL9gD2Xae6r97g=@emersion.fr> <20231213110517.6ce36aca@eldfell> <20231213101549.lioqfzjxcvmqxqu3@pop-os.localdomain> <20231213133825.0a329864@eldfell> <20231213132229.q3uxdhtdsxuzw3w6@pop-os.localdomain> <20231213161614.43e5bca8@eldfell>
Message-ID: <9m8eC1j8YSwxu9Mr8vCXyzF0nfyCSHpFbfc__FtUjjKppew65jElBbUqa-nkzFTN-N_ME893w0YQRcb3r3UbIajQUP-Y5LxnHKKFoiBepSI=@emersion.fr>

On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> > > It is protected/shielded/fortified from all the kernel and userspace,
> > > but a more familiar word to describe that is inaccessible.
> > > "Inaccessible buffer" per se OTOH sounds like a useless concept.
> > > 
> > > It is not secure, because it does not involve security in any way. In
> > > fact, given it's so fragile, I'd classify it as mildly opposite of
> > > secure, as e.g. clients of a Wayland compositor can potentially DoS the
> > > compositor with it by simply sending such a dmabuf. Or DoS the whole
> > > system.
> > 
> > I hear what you are saying and DoS is a known problem and attack vector,
> > but regardless, we have use cases where we don't want to expose
> > information in the clear and where we also would like to have some
> > guarantees about correctness. That is where various secure elements and
> > more generally security is needed.
> > 
> > So, it sounds like we have two things here, the first is the naming and
> > the meaning behind it. I'm pretty sure the people following and
> > contributing to this thread can agree on a name that makes sense. Would
> > you personally be OK with "restricted" as the name? It sounds like that.
> 
> I would. I'm also just a by-stander, not a maintainer of kernel
> anything. I have no power to accept nor reject anything here.

I'd also personally be OK with "restricted", I think it's a lot better
than "secure".

In general I agree with everything Pekka said.


From eichest at gmail.com  Fri Dec 22 01:52:56 2023
From: eichest at gmail.com (Stefan Eichenberger)
Date: Fri, 22 Dec 2023 10:52:56 +0100
Subject: [PATCH v2 0/2] Add a property to turn off the max touch controller in suspend mode
Message-ID: <20231222095258.33369-1-eichest@gmail.com>

From: Stefan Eichenberger <stefan.eichenberger at toradex.com>

Our hardware has a shared regulator that powers various peripherals such
as the display, touch, USB hub, etc. Since the Maxtouch controller
doesn't currently allow it to be turned off, this regulator has to stay
on in suspend mode. This increases the overall power consumption. In
order to turn off the controller when the system goes into suspend mode,
this series adds a device tree property to the maxtouch driver that
allows the controller to be turned off completely and ensurs that it can
resume from the power off state.

Changes since v1:
- Rename the property and change the description (Krzysztof, Linus,
  Dmitry, Conor)

Stefan Eichenberger (2):
  dt-bindings: input: atmel,maxtouch: add poweroff-sleep property
  Input: atmel_mxt_ts - support poweroff in suspend

 .../bindings/input/atmel,maxtouch.yaml        |  6 ++
 drivers/input/touchscreen/atmel_mxt_ts.c      | 72 ++++++++++++++-----
 2 files changed, 61 insertions(+), 17 deletions(-)

-- 
2.40.1



From eichest at gmail.com  Fri Dec 22 01:52:57 2023
From: eichest at gmail.com (Stefan Eichenberger)
Date: Fri, 22 Dec 2023 10:52:57 +0100
Subject: [PATCH v2 1/2] dt-bindings: input: atmel,maxtouch: add poweroff-sleep property
In-Reply-To: <20231222095258.33369-1-eichest@gmail.com>
References: <20231222095258.33369-1-eichest@gmail.com>
Message-ID: <20231222095258.33369-2-eichest@gmail.com>

From: Stefan Eichenberger <stefan.eichenberger at toradex.com>

Add a new property to indicate that the device should power off rather
than use deep sleep. Deep sleep is a feature of the controller that
expects the controller to remain powered in suspend. However, if a
display shares its regulator with the touch controller, we may want to
do a power off so that the display and touch controller do not use any
power.

Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>
---
 Documentation/devicetree/bindings/input/atmel,maxtouch.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
index c40799355ed7..8de5f539b30e 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -87,6 +87,12 @@ properties:
       - 2 # ATMEL_MXT_WAKEUP_GPIO
     default: 0
 
+  atmel,poweroff-sleep:
+    description: |
+      Instead of using the deep sleep feature of the maXTouch controller,
+      poweroff the regulators.
+    type: boolean
+
   wakeup-source:
     type: boolean
 
-- 
2.40.1



From eichest at gmail.com  Fri Dec 22 01:52:58 2023
From: eichest at gmail.com (Stefan Eichenberger)
Date: Fri, 22 Dec 2023 10:52:58 +0100
Subject: [PATCH v2 2/2] Input: atmel_mxt_ts - support poweroff in suspend
In-Reply-To: <20231222095258.33369-1-eichest@gmail.com>
References: <20231222095258.33369-1-eichest@gmail.com>
Message-ID: <20231222095258.33369-3-eichest@gmail.com>

From: Stefan Eichenberger <stefan.eichenberger at toradex.com>

Add a new device tree property to indicate that the device should be
powered off in suspend mode. We have a shared regulator that powers the
display, a USB hub and some other peripherals. The maXTouch controller
doesn't normally disable the regulator in suspend mode, so our extra
peripherals stay powered on. This is not desirable as it consumes more
power. With this patch we add the option to disable the regulator in
suspend mode for the maXTouch and accept the longer initialisation time.

Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>
---
 drivers/input/touchscreen/atmel_mxt_ts.c | 72 ++++++++++++++++++------
 1 file changed, 55 insertions(+), 17 deletions(-)

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 20094b9899f0..3f7f58f1c930 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -317,6 +317,7 @@ struct mxt_data {
 	struct gpio_desc *reset_gpio;
 	struct gpio_desc *wake_gpio;
 	bool use_retrigen_workaround;
+	bool poweroff_sleep;
 
 	/* Cached parameters from object table */
 	u16 T5_address;
@@ -2799,15 +2800,18 @@ static int mxt_configure_objects(struct mxt_data *data,
 			dev_warn(dev, "Error %d updating config\n", error);
 	}
 
-	if (data->multitouch) {
-		error = mxt_initialize_input_device(data);
-		if (error)
-			return error;
-	} else {
-		dev_warn(dev, "No touch object detected\n");
-	}
+	/* If input device is not already registered */
+	if (!data->input_dev) {
+		if (data->multitouch) {
+			error = mxt_initialize_input_device(data);
+			if (error)
+				return error;
+		} else {
+			dev_warn(dev, "No touch object detected\n");
+		}
 
-	mxt_debug_init(data);
+		mxt_debug_init(data);
+	}
 
 	return 0;
 }
@@ -3328,6 +3332,8 @@ static int mxt_probe(struct i2c_client *client)
 		msleep(MXT_RESET_INVALID_CHG);
 	}
 
+	data->poweroff_sleep = device_property_read_bool(&client->dev,
+							 "atmel,poweroff-sleep");
 	/*
 	 * Controllers like mXT1386 have a dedicated WAKE line that could be
 	 * connected to a GPIO or to I2C SCL pin, or permanently asserted low.
@@ -3390,12 +3396,21 @@ static int mxt_suspend(struct device *dev)
 	if (!input_dev)
 		return 0;
 
-	mutex_lock(&input_dev->mutex);
+	if (!device_may_wakeup(dev) && data->poweroff_sleep) {
+		if (data->reset_gpio)
+			gpiod_set_value(data->reset_gpio, 1);
 
-	if (input_device_enabled(input_dev))
-		mxt_stop(data);
+		regulator_bulk_disable(ARRAY_SIZE(data->regulators),
+				data->regulators);
+		data->T44_address = 0;
+	} else {
+		mutex_lock(&input_dev->mutex);
+
+		if (input_device_enabled(input_dev))
+			mxt_stop(data);
 
-	mutex_unlock(&input_dev->mutex);
+		mutex_unlock(&input_dev->mutex);
+	}
 
 	disable_irq(data->irq);
 
@@ -3411,14 +3426,37 @@ static int mxt_resume(struct device *dev)
 	if (!input_dev)
 		return 0;
 
-	enable_irq(data->irq);
+	if (!device_may_wakeup(dev) && data->poweroff_sleep) {
+		int ret;
 
-	mutex_lock(&input_dev->mutex);
+		ret = regulator_bulk_enable(ARRAY_SIZE(data->regulators),
+				data->regulators);
+		if (ret) {
+			dev_err(dev, "failed to enable regulators: %d\n",
+					ret);
+			return ret;
+		}
+		msleep(MXT_BACKUP_TIME);
 
-	if (input_device_enabled(input_dev))
-		mxt_start(data);
+		if (data->reset_gpio) {
+			/* Wait a while and then de-assert the RESET GPIO line */
+			msleep(MXT_RESET_GPIO_TIME);
+			gpiod_set_value(data->reset_gpio, 0);
+			msleep(MXT_RESET_INVALID_CHG);
+		}
 
-	mutex_unlock(&input_dev->mutex);
+		/* This also enables the irq again */
+		mxt_initialize(data);
+	} else {
+		enable_irq(data->irq);
+
+		mutex_lock(&input_dev->mutex);
+
+		if (input_device_enabled(input_dev))
+			mxt_start(data);
+
+		mutex_unlock(&input_dev->mutex);
+	}
 
 	return 0;
 }
-- 
2.40.1



From cristian.ciocaltea at collabora.com  Fri Dec 22 02:09:58 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 22 Dec 2023 12:09:58 +0200
Subject: [PATCH v3 0/2] StarFive DWMAC support for JH7100
Message-ID: <20231222101001.2541758-1-cristian.ciocaltea@collabora.com>

This is just a subset of the initial patch series [1] adding networking
support for StarFive JH7100 SoC.

[1]: https://lore.kernel.org/lkml/20231218214451.2345691-1-cristian.ciocaltea at collabora.com/

Changes in v3:
 - Optimized jh7110 resets & reset-names properties (Rob)
 - Added R-b tag from Jacob in PATCH 1
 - v2:
   https://lore.kernel.org/lkml/20231220002824.2462655-1-cristian.ciocaltea at collabora.com/

Changes in v2:
 - Add the missing binding patch (Conor)
 - v1:
   https://lore.kernel.org/lkml/20231219231040.2459358-1-cristian.ciocaltea at collabora.com/

Cristian Ciocaltea (2):
  dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
  net: stmmac: dwmac-starfive: Add support for JH7100 SoC

 .../devicetree/bindings/net/snps,dwmac.yaml   | 11 +--
 .../bindings/net/starfive,jh7110-dwmac.yaml   | 72 +++++++++++++------
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 +-
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 +++++++--
 4 files changed, 88 insertions(+), 33 deletions(-)

-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 22 02:09:59 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 22 Dec 2023 12:09:59 +0200
Subject: [PATCH v3 1/2] dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
In-Reply-To: <20231222101001.2541758-1-cristian.ciocaltea@collabora.com>
References: <20231222101001.2541758-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231222101001.2541758-2-cristian.ciocaltea@collabora.com>

The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
similar to the newer JH7110, but it requires only two interrupts and a
single reset line, which is 'ahb' instead of the commonly used
'stmmaceth'.

Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
conjunction with 'stmmaceth', extend the logic to also permit exclusive
usage of the 'ahb' reset name.  This ensures the following use cases are
supported:

  JH7110: reset-names = "stmmaceth", "ahb";
  JH7100: reset-names = "ahb";
  other:  reset-names = "stmmaceth";

Also note the need to use a different dwmac fallback, as v5.20 applies
to JH7110 only, while JH7100 relies on v3.7x.

Additionally, drop the reset description items from top-level binding as
they are already provided by the included snps,dwmac schema.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
Reviewed-by: Jacob Keller <jacob.e.keller at intel.com>
---
 .../devicetree/bindings/net/snps,dwmac.yaml   | 11 +--
 .../bindings/net/starfive,jh7110-dwmac.yaml   | 72 +++++++++++++------
 2 files changed, 57 insertions(+), 26 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 5c2769dc689a..90c4db178c67 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -95,6 +95,7 @@ properties:
         - snps,dwmac-5.20
         - snps,dwxgmac
         - snps,dwxgmac-2.10
+        - starfive,jh7100-dwmac
         - starfive,jh7110-dwmac
 
   reg:
@@ -144,10 +145,12 @@ properties:
       - description: AHB reset
 
   reset-names:
-    minItems: 1
-    items:
-      - const: stmmaceth
-      - const: ahb
+    oneOf:
+      - items:
+          - enum: [stmmaceth, ahb]
+      - items:
+          - const: stmmaceth
+          - const: ahb
 
   power-domains:
     maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 5e7cfbbebce6..0d1962980f57 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -16,16 +16,20 @@ select:
     compatible:
       contains:
         enum:
+          - starfive,jh7100-dwmac
           - starfive,jh7110-dwmac
   required:
     - compatible
 
 properties:
   compatible:
-    items:
-      - enum:
-          - starfive,jh7110-dwmac
-      - const: snps,dwmac-5.20
+    oneOf:
+      - items:
+          - const: starfive,jh7100-dwmac
+          - const: snps,dwmac
+      - items:
+          - const: starfive,jh7110-dwmac
+          - const: snps,dwmac-5.20
 
   reg:
     maxItems: 1
@@ -46,24 +50,6 @@ properties:
       - const: tx
       - const: gtx
 
-  interrupts:
-    minItems: 3
-    maxItems: 3
-
-  interrupt-names:
-    minItems: 3
-    maxItems: 3
-
-  resets:
-    items:
-      - description: MAC Reset signal.
-      - description: AHB Reset signal.
-
-  reset-names:
-    items:
-      - const: stmmaceth
-      - const: ahb
-
   starfive,tx-use-rgmii-clk:
     description:
       Tx clock is provided by external rgmii clock.
@@ -94,6 +80,48 @@ required:
 allOf:
   - $ref: snps,dwmac.yaml#
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: starfive,jh7100-dwmac
+    then:
+      properties:
+        interrupts:
+          minItems: 2
+          maxItems: 2
+
+        interrupt-names:
+          minItems: 2
+          maxItems: 2
+
+        resets:
+          maxItems: 1
+
+        reset-names:
+          const: ahb
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: starfive,jh7110-dwmac
+    then:
+      properties:
+        interrupts:
+          minItems: 3
+          maxItems: 3
+
+        interrupt-names:
+          minItems: 3
+          maxItems: 3
+
+        resets:
+          minItems: 2
+
+        reset-names:
+          minItems: 2
+
 unevaluatedProperties: false
 
 examples:
-- 
2.43.0



From cristian.ciocaltea at collabora.com  Fri Dec 22 02:10:00 2023
From: cristian.ciocaltea at collabora.com (Cristian Ciocaltea)
Date: Fri, 22 Dec 2023 12:10:00 +0200
Subject: [PATCH v3 2/2] net: stmmac: dwmac-starfive: Add support for JH7100 SoC
In-Reply-To: <20231222101001.2541758-1-cristian.ciocaltea@collabora.com>
References: <20231222101001.2541758-1-cristian.ciocaltea@collabora.com>
Message-ID: <20231222101001.2541758-3-cristian.ciocaltea@collabora.com>

Add a missing quirk to enable support for the StarFive JH7100 SoC.

Additionally, for greater flexibility in operation, allow using the
rgmii-rxid and rgmii-txid phy modes.

Co-developed-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel at esmil.dk>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
Reviewed-by: Jacob Keller <jacob.e.keller at intel.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |  6 ++--
 .../ethernet/stmicro/stmmac/dwmac-starfive.c  | 32 ++++++++++++++++---
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 85dcda51df05..4ec61f1ee71a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -165,9 +165,9 @@ config DWMAC_STARFIVE
 	help
 	  Support for ethernet controllers on StarFive RISC-V SoCs
 
-	  This selects the StarFive platform specific glue layer support for
-	  the stmmac device driver. This driver is used for StarFive JH7110
-	  ethernet controller.
+	  This selects the StarFive platform specific glue layer support
+	  for the stmmac device driver. This driver is used for the
+	  StarFive JH7100 and JH7110 ethernet controllers.
 
 config DWMAC_STI
 	tristate "STi GMAC support"
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 5d630affb4d1..4e1076faee0c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -15,13 +15,20 @@
 
 #include "stmmac_platform.h"
 
-#define STARFIVE_DWMAC_PHY_INFT_RGMII	0x1
-#define STARFIVE_DWMAC_PHY_INFT_RMII	0x4
-#define STARFIVE_DWMAC_PHY_INFT_FIELD	0x7U
+#define STARFIVE_DWMAC_PHY_INFT_RGMII		0x1
+#define STARFIVE_DWMAC_PHY_INFT_RMII		0x4
+#define STARFIVE_DWMAC_PHY_INFT_FIELD		0x7U
+
+#define JH7100_SYSMAIN_REGISTER49_DLYCHAIN	0xc8
+
+struct starfive_dwmac_data {
+	unsigned int gtxclk_dlychain;
+};
 
 struct starfive_dwmac {
 	struct device *dev;
 	struct clk *clk_tx;
+	const struct starfive_dwmac_data *data;
 };
 
 static void starfive_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode)
@@ -67,6 +74,8 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 
 	case PHY_INTERFACE_MODE_RGMII:
 	case PHY_INTERFACE_MODE_RGMII_ID:
+	case PHY_INTERFACE_MODE_RGMII_RXID:
+	case PHY_INTERFACE_MODE_RGMII_TXID:
 		mode = STARFIVE_DWMAC_PHY_INFT_RGMII;
 		break;
 
@@ -89,6 +98,14 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
 	if (err)
 		return dev_err_probe(dwmac->dev, err, "error setting phy mode\n");
 
+	if (dwmac->data) {
+		err = regmap_write(regmap, JH7100_SYSMAIN_REGISTER49_DLYCHAIN,
+				   dwmac->data->gtxclk_dlychain);
+		if (err)
+			return dev_err_probe(dwmac->dev, err,
+					     "error selecting gtxclk delay chain\n");
+	}
+
 	return 0;
 }
 
@@ -114,6 +131,8 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	if (!dwmac)
 		return -ENOMEM;
 
+	dwmac->data = device_get_match_data(&pdev->dev);
+
 	dwmac->clk_tx = devm_clk_get_enabled(&pdev->dev, "tx");
 	if (IS_ERR(dwmac->clk_tx))
 		return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_tx),
@@ -144,8 +163,13 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
 	return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
 }
 
+static const struct starfive_dwmac_data jh7100_data = {
+	.gtxclk_dlychain = 4,
+};
+
 static const struct of_device_id starfive_dwmac_match[] = {
-	{ .compatible = "starfive,jh7110-dwmac"	},
+	{ .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
+	{ .compatible = "starfive,jh7110-dwmac" },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Fri Dec 22 02:30:47 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 22 Dec 2023 11:30:47 +0100
Subject: [PATCH v11] pwm: bcm2835: Allow PWM driver to be used in atomic
 context
In-Reply-To: <20231220142426.1275052-1-sean@mess.org>
References: <20231220142426.1275052-1-sean@mess.org>
Message-ID: <fuku3b5ur6y4k4refd3vmeoenzjo6mwe3b3gtel34rhhhtvnsa@w4uktgbqsc3w>

Hello Sean,

On Wed, Dec 20, 2023 at 02:24:25PM +0000, Sean Young wrote:
> @@ -151,8 +153,26 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
>  		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
>  				     "clock not found\n");
>  
> +	ret = clk_rate_exclusive_get(pc->clk);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "fail to get exclusive rate\n");
> +
> +	ret = devm_add_action_or_reset(&pdev->dev, devm_clk_rate_exclusive_put,
> +				       pc->clk);
> +	if (ret) {
> +		clk_rate_exclusive_put(pc->clk);

That clk_rate_exclusive_put() is wrong. If devm_add_action_or_reset()
fails that is already cared for.

Given that Thierry already applied this patch, getting this fixed in a
timely manner would be good.

> +		return ret;
> +	}
> +
> +	pc->rate = clk_get_rate(pc->clk);
> +	if (!pc->rate)
> +		return dev_err_probe(&pdev->dev, -EINVAL,
> +				     "failed to get clock rate\n");
> +
>  	pc->chip.dev = &pdev->dev;
>  	pc->chip.ops = &bcm2835_pwm_ops;
> +	pc->chip.atomic = true;
>  	pc->chip.npwm = 2;
>  
>  	platform_set_drvdata(pdev, pc);

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/d9478292/attachment.sig>

From sean at mess.org  Fri Dec 22 02:37:02 2023
From: sean at mess.org (Sean Young)
Date: Fri, 22 Dec 2023 10:37:02 +0000
Subject: [PATCH v11] pwm: bcm2835: Allow PWM driver to be used in atomic
 context
In-Reply-To: <fuku3b5ur6y4k4refd3vmeoenzjo6mwe3b3gtel34rhhhtvnsa@w4uktgbqsc3w>
References: <20231220142426.1275052-1-sean@mess.org>
 <fuku3b5ur6y4k4refd3vmeoenzjo6mwe3b3gtel34rhhhtvnsa@w4uktgbqsc3w>
Message-ID: <ZYVmzrRwgVOGinmy@gofer.mess.org>

On Fri, Dec 22, 2023 at 11:30:47AM +0100, Uwe Kleine-K?nig wrote:
> Hello Sean,
> 
> On Wed, Dec 20, 2023 at 02:24:25PM +0000, Sean Young wrote:
> > @@ -151,8 +153,26 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
> >  		return dev_err_probe(&pdev->dev, PTR_ERR(pc->clk),
> >  				     "clock not found\n");
> >  
> > +	ret = clk_rate_exclusive_get(pc->clk);
> > +	if (ret)
> > +		return dev_err_probe(&pdev->dev, ret,
> > +				     "fail to get exclusive rate\n");
> > +
> > +	ret = devm_add_action_or_reset(&pdev->dev, devm_clk_rate_exclusive_put,
> > +				       pc->clk);
> > +	if (ret) {
> > +		clk_rate_exclusive_put(pc->clk);
> 
> That clk_rate_exclusive_put() is wrong. If devm_add_action_or_reset()
> fails that is already cared for.

Yes, you're right. I missed that - should've checked.

> Given that Thierry already applied this patch, getting this fixed in a
> timely manner would be good.

I'll send out a patch shortly, thanks for catching.


Sean


From andy.yan at rock-chips.com  Fri Dec 22 02:37:57 2023
From: andy.yan at rock-chips.com (Andy Yan)
Date: Fri, 22 Dec 2023 18:37:57 +0800
Subject: [PATCH v2 1/3] ARM: dts: rockchip: Add psci for rk3036
In-Reply-To: <a82481ca-b578-49a4-b0d0-974b6ee65c98@gmail.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
 <20231218105523.2478315-2-andyshrk@163.com>
 <da10e2fc-3179-4bd5-88ed-b4d5f64a7191@gmail.com>
 <28216be5-810f-40d6-850b-a0fc590ffa3c@rock-chips.com>
 <a82481ca-b578-49a4-b0d0-974b6ee65c98@gmail.com>
Message-ID: <74e497f5-0361-47f7-a410-4b20d3526d52@rock-chips.com>

Hi Alex,

On 12/21/23 23:58, Alex Bee wrote:
> Hi Andy,
> 
> Am 21.12.23 um 02:07 schrieb Andy Yan:
>> Hi Alex:
>>
>> On 12/20/23 19:16, Alex Bee wrote:
>>> Hi Andy,
>>> Am 18.12.23 um 11:55 schrieb Andy Yan:
>>>> From: Andy Yan <andy.yan at rock-chips.com>
>>>>
>>>> The system will hang at bringup secondary CPUs
>>>> without psci node.
>>>>
>>>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>>>>
>>>> ---
>>>>
>>>> (no changes since v1)
>>>>
>>>> ? arch/arm/boot/dts/rockchip/rk3036.dtsi | 5 +++++
>>>> ? 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>>> index 78686fc72ce6..5344803442a1 100644
>>>> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>>> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>>> @@ -67,6 +67,11 @@ display-subsystem {
>>>> ????????? ports = <&vop_out>;
>>>> ????? };
>>>> +??? psci {
>>>> +??????? compatible = "arm,psci-1.0";
>>>> +??????? method = "smc";
>>>> +??? };
>>>> +
>>> I don't think that's an good idea. 
>>
>> Why?
> It's only what I've been told before: We shoudn't add properties which
> depend on non-upstream software (if an upstream alternative exists). Also

> I'm not sure what happens if somebody doesn't?use downstream bootloader
> and PSCI can't be found: Would the board still be able to boot?

The psci is released herel[0].
And also, there are only two rk3036 based boards in mainline:
rk3036-evb,rk3036-keylin, both of them from rockchip.
And the mainline support of these boards broken from linux 5.7(2020, see PATCH 3),
no one report this broken until I try to run this board now.
So maybe there is no such somebody will run into this situation.


[0]https://github.com/rockchip-linux/rkbin/tree/master/bin/rk30

>>
>>> You most likely need that because you have downstream bootloader installed on this board. PSCI implementation takes place in TEE-OS for Rockchips ARM SoCs. There is no support for RK3036 in upstream op-tee OS. It's pretty much the same for RK3128 and RK3288.
>>> If you use upstream u-boot it should be good as-is.
>>
>> Unfortunately, upstream u-boot also cannot boot up on this board.
>> At present, I haven't had time to debug what is going on.
>>
>> Another reason I want to use downstream u-boot it is: I try run
>> this board with mainline just because i want to test some community
>> patches about inno-hdmi driver, as you said "the inno-hdmi driver currently gets a lot of attention"[0]
>>
> Thanks for helping testing this.
> 
> Alex
> 
>> With a downstream u-boot I can easy switch between upstream kernel and downstream kernel(no need to replace other components)
>> if I found some function is not work as expected.
>>
>>
>> [0]https://patchwork.kernel.org/project/linux-rockchip/cover/20231219170100.188800-1-knaerzche at gmail.com/
>>>
>>> Alex
>>>> ????? timer {
>>>> ????????? compatible = "arm,armv7-timer";
>>>> ????????? arm,cpu-registers-not-fw-configured;
>>>
>>>
>>> _______________________________________________
>>> Linux-rockchip mailing list
>>> Linux-rockchip at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip


From wsa at kernel.org  Fri Dec 22 02:44:50 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Fri, 22 Dec 2023 11:44:50 +0100
Subject: [PATCH v3 1/9] i2c: stm32f7: use dev_err_probe upon calls of
 devm_request_irq
In-Reply-To: <20231215170617.95868-2-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
 <20231215170617.95868-2-alain.volmat@foss.st.com>
Message-ID: <ZYVoolBtWqO7DLIn@shikoro>

On Fri, Dec 15, 2023 at 06:06:05PM +0100, Alain Volmat wrote:
> Convert error handling upon calls of devm_request_irq functions during
> the probe of the driver.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/e7fe74c8/attachment.sig>

From wsa at kernel.org  Fri Dec 22 02:44:58 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Fri, 22 Dec 2023 11:44:58 +0100
Subject: [PATCH v3 2/9] i2c: stm32f7: perform most of irq job in threaded
 handler
In-Reply-To: <20231215170617.95868-3-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
 <20231215170617.95868-3-alain.volmat@foss.st.com>
Message-ID: <ZYVoqkoKh0S6yArc@shikoro>

On Fri, Dec 15, 2023 at 06:06:06PM +0100, Alain Volmat wrote:
> The irq handling is currently split between the irq handler
> and the threaded irq handler.  Some of the handling (such as
> dma related stuffs) done within the irq handler might sleep or
> take some time leading to issues if the kernel is built with
> realtime constraints.  In order to fix that, perform an overall
> rework to perform most of the job within the threaded handler
> and only keep fifo access in the non threaded handler.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/365600cf/attachment.sig>

From wsa at kernel.org  Fri Dec 22 02:45:06 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Fri, 22 Dec 2023 11:45:06 +0100
Subject: [PATCH v3 3/9] i2c: stm32f7: simplify status messages in case of
 errors
In-Reply-To: <20231215170617.95868-4-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
 <20231215170617.95868-4-alain.volmat@foss.st.com>
Message-ID: <ZYVosiRTD2w9sVV+@shikoro>

On Fri, Dec 15, 2023 at 06:06:07PM +0100, Alain Volmat wrote:
> Avoid usage of __func__ when reporting an error message
> since dev_err/dev_dbg are already providing enough details
> to identify the source of the message.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
> Reviewed-by: Andi Shyti <andi.shyti at kernel.org>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/08408fcf/attachment.sig>

From wsa at kernel.org  Fri Dec 22 02:45:18 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Fri, 22 Dec 2023 11:45:18 +0100
Subject: [PATCH v3 4/9] dt-bindings: i2c: document st,stm32mp25-i2c
 compatible
In-Reply-To: <20231215170617.95868-5-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
 <20231215170617.95868-5-alain.volmat@foss.st.com>
Message-ID: <ZYVovt1SmdgS58yH@shikoro>

On Fri, Dec 15, 2023 at 06:06:08PM +0100, Alain Volmat wrote:
> Add a new compatible st,stm32mp25-i2c for the STM32MP25 series which
> has only one interrupt line for both events and errors and differs in
> term of handling of FastModePlus.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>
> Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/85229afc/attachment-0001.sig>

From wsa at kernel.org  Fri Dec 22 02:45:27 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Fri, 22 Dec 2023 11:45:27 +0100
Subject: [PATCH v3 5/9] i2c: stm32f7: perform I2C_ISR read once at
 beginning of event isr
In-Reply-To: <20231215170617.95868-6-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
 <20231215170617.95868-6-alain.volmat@foss.st.com>
Message-ID: <ZYVox185zFjRZUJ4@shikoro>

On Fri, Dec 15, 2023 at 06:06:09PM +0100, Alain Volmat wrote:
> Move readl_relaxed of I2C_ISR register at beginning of event isr
> so that it done once for both master & slave handling.
> 
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/ff22447b/attachment.sig>

From wsa at kernel.org  Fri Dec 22 02:45:37 2023
From: wsa at kernel.org (Wolfram Sang)
Date: Fri, 22 Dec 2023 11:45:37 +0100
Subject: [PATCH v3 6/9] i2c: stm32f7: add support for stm32mp25 soc
In-Reply-To: <20231215170617.95868-7-alain.volmat@foss.st.com>
References: <20231215170617.95868-1-alain.volmat@foss.st.com>
 <20231215170617.95868-7-alain.volmat@foss.st.com>
Message-ID: <ZYVo0X1q9w19qTwg@shikoro>

On Fri, Dec 15, 2023 at 06:06:10PM +0100, Alain Volmat wrote:
> The stm32mp25 has only a single interrupt line used for both
> events and errors. In order to cope with that, reorganise the
> error handling code so that it can be called either from the
> common handler (used in case of SoC having only a single IT line)
> and the error handler for others.
> The CR1 register also embeds a new FMP bit, necessary when running
> at Fast Mode Plus frequency. This bit should be used instead of
> the SYSCFG bit used on other platforms.
> Add a new compatible to distinguish between the SoCs and two
> boolean within the setup structure in order to know if the
> platform has a single/multiple IT lines and if the FMP bit
> within CR1 is available or not.
> 
> Signed-off-by: Valentin Caron <valentin.caron at foss.st.com>
> Signed-off-by: Alain Volmat <alain.volmat at foss.st.com>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/7866c9cb/attachment.sig>

From sean at mess.org  Fri Dec 22 02:46:51 2023
From: sean at mess.org (Sean Young)
Date: Fri, 22 Dec 2023 10:46:51 +0000
Subject: [PATCH] pwm: bcm2835: Duplicate call to clk_rate_exclusive_put in error path
Message-ID: <20231222104651.167821-1-sean@mess.org>

devm_add_action_or_reset() already calls the action in the error case.

Reported-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Closes: https://lore.kernel.org/linux-pwm/fuku3b5ur6y4k4refd3vmeoenzjo6mwe3b3gtel34rhhhtvnsa at w4uktgbqsc3w/
Signed-off-by: Sean Young <sean at mess.org>
---
 drivers/pwm/pwm-bcm2835.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index 307c0bd5f885..283cf27f25ba 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -160,10 +160,8 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
 
 	ret = devm_add_action_or_reset(&pdev->dev, devm_clk_rate_exclusive_put,
 				       pc->clk);
-	if (ret) {
-		clk_rate_exclusive_put(pc->clk);
+	if (ret)
 		return ret;
-	}
 
 	pc->rate = clk_get_rate(pc->clk);
 	if (!pc->rate)
-- 
2.43.0



From arnd at arndb.de  Fri Dec 22 02:55:00 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 22 Dec 2023 10:55:00 +0000
Subject: [GIT PULL] PowerQUICC QMC and TSA drivers updates for v6.8
In-Reply-To: <20231212105514.273e8ab0@bootlin.com>
References: <20231212105514.273e8ab0@bootlin.com>
Message-ID: <a274ba17-6ab7-4169-a10c-22fcc9e74248@app.fastmail.com>

On Tue, Dec 12, 2023, at 09:55, Herve Codina wrote:
> The following changes since commit 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab:
>
>   Linux 6.7-rc3 (2023-11-26 19:59:33 -0800)
>
> are available in the Git repository at:
>
>   git at github.com:hcodina/linux.git tags/fsl_qmc_tsa_v6.8
>
> for you to fetch changes up to 7a2ee1576dcc6bbe017a8283fba237b05b13fd15:
>

This is not a valid git URL I can pull from. I have instead pulled from

  https://github.com/hcodina/linux.git tags/fsl_qmc_tsa_v6.8

which is what I think you meant. 

You should probably edit your .gitconfig file to add a section
like (not sure about the exact syntax, you'll figure it out).

[url "https://github.com"]
    insteadOf = git at github.com


>  drivers/soc/fsl/qe/qmc.c      | 658 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------

This is an overly long line that you probably copied from a large
terminal window. Just for readability, I recommend redirecting the
'git request-pull' output, e.g. into 'xclip' or 'cat', which will
give it the appropriate line length for emails.

      Arnd


From u.kleine-koenig at pengutronix.de  Fri Dec 22 02:56:32 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 22 Dec 2023 11:56:32 +0100
Subject: [PATCH] pwm: bcm2835: Duplicate call to clk_rate_exclusive_put
 in error path
In-Reply-To: <20231222104651.167821-1-sean@mess.org>
References: <20231222104651.167821-1-sean@mess.org>
Message-ID: <jtcp45zfijjc5kfikph4wuhnkqrnm5ncs6hte3romefm33k3q4@7gyzfb42eglg>

Hello Sean,

thanks for the quick fix. I'd do s/Duplicate/Deduplicate/ in the
Subject (+ maybe s/clk_rate_exclusive_put/clk_rate_exclusive_put()/)

Apart from that:

Fixes: fcc760729359 ("pwm: bcm2835: Allow PWM driver to be used in atomic context")
Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/0974c2ff/attachment-0001.sig>

From manut at mecka.net  Fri Dec 22 03:05:41 2023
From: manut at mecka.net (Manuel Traut)
Date: Fri, 22 Dec 2023 12:05:41 +0100
Subject: [PATCH 1/6] dt-bindings: display: panel: Add BOE
 TH101MB31IG002-28A panel
In-Reply-To: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
Message-ID: <20231222-pinetab2-v1-1-e148a7f61bd1@mecka.net>

Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
used e.g. in the Pine64 Pinetab2 and PinetabV.

Signed-off-by: Manuel Traut <manut at mecka.net>
---
 .../display/panel/boe,th101mb31ig002-28a.yaml      | 73 ++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
new file mode 100644
index 000000000000..a8a5e1b4439b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,th101mb31ig002-28a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TH101MB31IG002-28A Pine64 Pinetab2 DSI Display Panel
+
+maintainers:
+  - Manuel Traut <manut at mecka.net>
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+    enum:
+        # BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel
+      - boe,th101mb31ig002-28a
+
+  reg:
+    description: the virtual channel number of a DSI peripheral
+
+  backlight:
+    description: phandle of the backlight device attached to the panel
+
+  enable-gpios:
+    description: a GPIO spec for the enable pin
+
+  power-supply:
+    description: core voltage supply
+
+
+  ports: true
+  rotation: true
+
+required:
+  - compatible
+  - reg
+  - enable-gpios
+  - power-supply
+
+additionalProperties: false
+
+examples:
+  - |
+    dsi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        panel at 0 {
+            compatible = "boe,th101mb31ig002-28a";
+            reg = <0>;
+            backlight = <&backlight_lcd0>;
+            enable-gpios = <&pio 45 0>;
+            rotation = <90>;
+            power-supply = <&vcc_3v3>;
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                port at 0 {
+                    reg = <0>;
+                    #address-cells = <1>;
+                    #size-cells = <0>;
+                    panel_in_dsi: endpoint at 0 {
+                        reg = <0>;
+                        remote-endpoint = <&dsi0_out_con>;
+                    };
+                };
+            };
+        };
+    };
+
+...

-- 
2.43.0



From manut at mecka.net  Fri Dec 22 03:05:42 2023
From: manut at mecka.net (Manuel Traut)
Date: Fri, 22 Dec 2023 12:05:42 +0100
Subject: [PATCH 2/6] drm/panel: Add driver for BOE TH101MB31IG002-28A panel
In-Reply-To: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
Message-ID: <20231222-pinetab2-v1-2-e148a7f61bd1@mecka.net>

From: Segfault <awarnecke002 at hotmail.com>

The BOE TH101MB31IG002-28A panel is a WXGA panel.
It is used in Pine64 Pinetab2 and PinetabV.

Signed-off-by: Segfault <awarnecke002 at hotmail.com>
Signed-off-by: Manuel Traut <manut at mecka.net>
---
 drivers/gpu/drm/panel/Kconfig                      |  11 +
 drivers/gpu/drm/panel/Makefile                     |   1 +
 .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c   | 307 +++++++++++++++++++++
 3 files changed, 319 insertions(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..927ddd10e688 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -67,6 +67,17 @@ config DRM_PANEL_BOE_HIMAX8279D
 	  24 bit RGB per pixel. It provides a MIPI DSI interface to
 	  the host and has a built-in LED backlight.
 
+config DRM_PANEL_BOE_TH101MB31UIG002_28A
+	tristate "Boe TH101MB31UIG002-28A panel"
+	depends on OF
+	depends on DRM_MIPI_DSI
+	depends on BACKLIGHT_CLASS_DEVICE
+	help
+	  Say Y here if you want to enable support for Boe
+	  TH101MB31UIG002-28A TFT-LCD modules. The panel has a 800x1280
+	  resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI
+	  interface to the host and has a built-in LED backlight.
+
 config DRM_PANEL_BOE_TV101WUM_NL6
 	tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
 	depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..dd6e1ac9d0a2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) += panel-asus-z00t-tm5p5-n35596.
 obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
 obj-$(CONFIG_DRM_PANEL_BOE_BF060Y8M_AJ0) += panel-boe-bf060y8m-aj0.o
 obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
+obj-$(CONFIG_DRM_PANEL_BOE_TH101MB31UIG002_28A) += panel-boe-th101mb31ig002-28a.o
 obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
 obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
diff --git a/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
new file mode 100644
index 000000000000..ac1dc99a0300
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Alexander Warnecke <awarnecke002 at hotmail.com>
+ * Copyright (c) 2023 Manuel Traut <manut at mecka.net>
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/drm_connector.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_panel.h>
+
+struct boe_th101mb31ig002 {
+	struct drm_panel panel;
+	bool enabled;
+	bool prepared;
+
+	struct mipi_dsi_device *dsi;
+
+	struct regulator *power;
+	struct gpio_desc *enable;
+	struct gpio_desc *reset;
+
+	enum drm_panel_orientation orientation;
+};
+
+static int boe_th101mb31ig002_disable(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+
+	if (!ctx->enabled)
+		return 0;
+
+	mipi_dsi_dcs_set_display_off(ctx->dsi);
+	msleep(120);
+	ctx->enabled = false;
+
+	return 0;
+}
+
+static int boe_th101mb31ig002_unprepare(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+
+	if (!ctx->prepared)
+		return 0;
+
+	mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
+	msleep(220);
+	gpiod_set_value_cansleep(ctx->reset, 1);
+	gpiod_set_value_cansleep(ctx->enable, 0);
+	regulator_disable(ctx->power);
+	ctx->prepared = false;
+
+	return 0;
+}
+
+static int boe_th101mb31ig002_prepare(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+	struct mipi_dsi_device *dsi = ctx->dsi;
+	int ret;
+
+	if (ctx->prepared)
+		return 0;
+
+	ret = regulator_enable(ctx->power);
+	if (ret) {
+		dev_err(&dsi->dev, "Failed to enable power supply: %d\n", ret);
+		return ret;
+	}
+
+	gpiod_set_value_cansleep(ctx->enable, 1);
+	msleep(120);
+	gpiod_direction_output(ctx->reset, 1);
+	msleep(120);
+	gpiod_direction_output(ctx->reset, 0);
+	msleep(120);
+
+	mipi_dsi_dcs_write_seq(dsi, 0xE0, 0xAB, 0xBA);
+	mipi_dsi_dcs_write_seq(dsi, 0xE1, 0xBA, 0xAB);
+	mipi_dsi_dcs_write_seq(dsi, 0xB1, 0x10, 0x01, 0x47, 0xFF);
+	mipi_dsi_dcs_write_seq(dsi, 0xB2, 0x0C, 0x14, 0x04, 0x50, 0x50, 0x14);
+	mipi_dsi_dcs_write_seq(dsi, 0xB3, 0x56, 0x53, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xB4, 0x33, 0x30, 0x04);
+	mipi_dsi_dcs_write_seq(dsi, 0xB6, 0xB0, 0x00, 0x00, 0x10, 0x00, 0x10,
+			       0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xB8, 0x05, 0x12, 0x29, 0x49, 0x48, 0x00,
+			       0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xB9, 0x7C, 0x65, 0x55, 0x49, 0x46, 0x36,
+			       0x3B, 0x24, 0x3D, 0x3C, 0x3D, 0x5C, 0x4C, 0x55,
+			       0x47, 0x46, 0x39, 0x26, 0x06, 0x7C, 0x65, 0x55,
+			       0x49, 0x46, 0x36, 0x3B, 0x24, 0x3D, 0x3C, 0x3D,
+			       0x5C, 0x4C, 0x55, 0x47, 0x46, 0x39, 0x26, 0x06);
+	mipi_dsi_dcs_write_seq(dsi, 0xC0, 0xFF, 0x87, 0x12, 0x34, 0x44, 0x44,
+			       0x44, 0x44, 0x98, 0x04, 0x98, 0x04, 0x0F, 0x00,
+			       0x00, 0xC1);
+	mipi_dsi_dcs_write_seq(dsi, 0xC1, 0x54, 0x94, 0x02, 0x85, 0x9F, 0x00,
+			       0x7F, 0x00, 0x54, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xC2, 0x17, 0x09, 0x08, 0x89, 0x08, 0x11,
+			       0x22, 0x20, 0x44, 0xFF, 0x18, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xC3, 0x86, 0x46, 0x05, 0x05, 0x1C, 0x1C,
+			       0x1D, 0x1D, 0x02, 0x1F, 0x1F, 0x1E, 0x1E, 0x0F,
+			       0x0F, 0x0D, 0x0D, 0x13, 0x13, 0x11, 0x11, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xC4, 0x07, 0x07, 0x04, 0x04, 0x1C, 0x1C,
+			       0x1D, 0x1D, 0x02, 0x1F, 0x1F, 0x1E, 0x1E, 0x0E,
+			       0x0E, 0x0C, 0x0C, 0x12, 0x12, 0x10, 0x10, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xC6, 0x2A, 0x2A);
+	mipi_dsi_dcs_write_seq(dsi, 0xC8, 0x21, 0x00, 0x31, 0x42, 0x34, 0x16);
+	mipi_dsi_dcs_write_seq(dsi, 0xCA, 0xCB, 0x43);
+	mipi_dsi_dcs_write_seq(dsi, 0xCD, 0x0E, 0x4B, 0x4B, 0x20, 0x19, 0x6B,
+			       0x06, 0xB3);
+	mipi_dsi_dcs_write_seq(dsi, 0xD2, 0xE3, 0x2B, 0x38, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xD4, 0x00, 0x01, 0x00, 0x0E, 0x04, 0x44,
+			       0x08, 0x10, 0x00, 0x00, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xE6, 0x80, 0x01, 0xFF, 0xFF, 0xFF, 0xFF,
+			       0xFF, 0xFF);
+	mipi_dsi_dcs_write_seq(dsi, 0xF0, 0x12, 0x03, 0x20, 0x00, 0xFF);
+	mipi_dsi_dcs_write_seq(dsi, 0xF3, 0x00);
+
+	mipi_dsi_dcs_exit_sleep_mode(dsi);
+	msleep(120);
+	ctx->prepared = true;
+
+	return 0;
+}
+
+static int boe_th101mb31ig002_enable(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+
+	if (ctx->enabled)
+		return 0;
+
+	mipi_dsi_dcs_set_display_on(ctx->dsi);
+	msleep(120);
+	ctx->enabled = true;
+
+	return 0;
+}
+
+static const struct drm_display_mode boe_th101mb31ig002_default_mode = {
+	.clock		= 73500,
+	.hdisplay	= 800,
+	.hsync_start	= 800 + 64,
+	.hsync_end	= 800 + 64 + 16,
+	.htotal		= 800 + 64 + 16 + 64,
+	.vdisplay	= 1280,
+	.vsync_start	= 1280 + 2,
+	.vsync_end	= 1280 + 2 + 4,
+	.vtotal		= 1280 + 2 + 4 + 12,
+	.type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static int boe_th101mb31ig002_get_modes(struct drm_panel *panel,
+					struct drm_connector *connector)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+	struct drm_display_mode *mode;
+
+	mode = drm_mode_duplicate(connector->dev,
+				  &boe_th101mb31ig002_default_mode);
+	if (!mode) {
+		dev_err(panel->dev, "Failed to add mode %ux%u@%u\n",
+			boe_th101mb31ig002_default_mode.hdisplay,
+			boe_th101mb31ig002_default_mode.vdisplay,
+			drm_mode_vrefresh(&boe_th101mb31ig002_default_mode));
+		return -ENOMEM;
+	}
+
+	drm_mode_set_name(mode);
+	drm_mode_probed_add(connector, mode);
+
+	connector->display_info.bpc = 8;
+	connector->display_info.width_mm = 216;
+	connector->display_info.height_mm = 135;
+
+	/*
+	 * TODO: Remove once all drm drivers call
+	 * drm_connector_set_orientation_from_panel()
+	 */
+	drm_connector_set_panel_orientation(connector, ctx->orientation);
+
+	return 1;
+}
+
+static enum drm_panel_orientation boe_th101mb31ig002_get_orientation(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+
+	return ctx->orientation;
+}
+
+static const struct drm_panel_funcs boe_th101mb31ig002_funcs = {
+	.disable = boe_th101mb31ig002_disable,
+	.unprepare = boe_th101mb31ig002_unprepare,
+	.prepare = boe_th101mb31ig002_prepare,
+	.enable = boe_th101mb31ig002_enable,
+	.get_modes = boe_th101mb31ig002_get_modes,
+	.get_orientation = boe_th101mb31ig002_get_orientation,
+};
+
+static int boe_th101mb31ig002_dsi_probe(struct mipi_dsi_device *dsi)
+{
+	struct boe_th101mb31ig002 *ctx;
+	int ret;
+
+	ctx = devm_kzalloc(&dsi->dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ctx->enabled = false;
+	ctx->prepared = false;
+
+	mipi_dsi_set_drvdata(dsi, ctx);
+	ctx->dsi = dsi;
+
+	drm_panel_init(&ctx->panel, &dsi->dev, &boe_th101mb31ig002_funcs,
+		       DRM_MODE_CONNECTOR_DSI);
+
+	ctx->power = devm_regulator_get(&dsi->dev, "power");
+	if (IS_ERR(ctx->power))
+		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->power),
+				     "Failed to get power regulator\n");
+
+	ctx->enable = devm_gpiod_get(&dsi->dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(ctx->enable))
+		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->enable),
+				     "Failed to get enable GPIO\n");
+
+	ctx->reset = devm_gpiod_get(&dsi->dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(ctx->reset))
+		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
+				     "Failed to get reset GPIO\n");
+
+	ret = of_drm_get_panel_orientation(dsi->dev.of_node,
+					   &ctx->orientation);
+	if (ret)
+		return dev_err_probe(&dsi->dev, ret,
+				     "Failed to get orientation\n");
+
+	ret = drm_panel_of_backlight(&ctx->panel);
+	if (ret)
+		return ret;
+
+	drm_panel_add(&ctx->panel);
+
+	dsi->lanes = 4;
+	dsi->format = MIPI_DSI_FMT_RGB888;
+	dsi->mode_flags = MIPI_DSI_MODE_VIDEO_BURST |
+			  MIPI_DSI_MODE_NO_EOT_PACKET |
+			  MIPI_DSI_MODE_LPM;
+
+	ret = mipi_dsi_attach(dsi);
+	if (ret < 0) {
+		drm_panel_remove(&ctx->panel);
+		return ret;
+	}
+
+	return 0;
+}
+
+static void boe_th101mb31ig002_dsi_remove(struct mipi_dsi_device *dsi)
+{
+	struct boe_th101mb31ig002 *ctx = mipi_dsi_get_drvdata(dsi);
+
+	mipi_dsi_detach(dsi);
+	drm_panel_remove(&ctx->panel);
+}
+
+static const struct of_device_id boe_th101mb31ig002_of_match[] = {
+	{ .compatible = "boe,th101mb31ig002-28a", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, boe_th101mb31ig002_of_match);
+
+static struct mipi_dsi_driver boe_th101mb31ig002_driver = {
+	.driver = {
+		.name = "boe-th101mb31ig002-28a",
+		.of_match_table = boe_th101mb31ig002_of_match,
+	},
+	.probe = boe_th101mb31ig002_dsi_probe,
+	.remove = boe_th101mb31ig002_dsi_remove,
+};
+module_mipi_dsi_driver(boe_th101mb31ig002_driver);
+
+MODULE_AUTHOR("Alexander Warnecke <awarnecke002 at hotmail.com>");
+MODULE_DESCRIPTION("BOE TH101MB31IG002-28A MIPI-DSI LCD panel");
+MODULE_LICENSE("GPL");

-- 
2.43.0



From manut at mecka.net  Fri Dec 22 03:05:43 2023
From: manut at mecka.net (Manuel Traut)
Date: Fri, 22 Dec 2023 12:05:43 +0100
Subject: [PATCH 3/6] dt-bindings: arm64: rockchip: Add Pine64 Pinetab2
In-Reply-To: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
Message-ID: <20231222-pinetab2-v1-3-e148a7f61bd1@mecka.net>

Add devicvetree binding documentation for Pine64 Pinetab2
which uses the Rockchip RK3566 SoC.

Signed-off-by: Manuel Traut <manut at mecka.net>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5f7c6c4aad8f..96d54b0587ab 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -635,6 +635,14 @@ properties:
           - const: pine64,pinenote
           - const: rockchip,rk3566
 
+      - description: Pine64 PineTab2
+        items:
+          - enum:
+              - pine64,pinetab2-v0.1
+              - pine64,pinetab2-v2.0
+          - const: pine64,pinetab2
+          - const: rockchip,rk3566
+
       - description: Pine64 PinePhonePro
         items:
           - const: pine64,pinephone-pro

-- 
2.43.0



From manut at mecka.net  Fri Dec 22 03:05:46 2023
From: manut at mecka.net (Manuel Traut)
Date: Fri, 22 Dec 2023 12:05:46 +0100
Subject: [PATCH 6/6] dt-bindings: display: rockchip: dw-hdmi: Add missing
 sound-dai-cells property
In-Reply-To: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
Message-ID: <20231222-pinetab2-v1-6-e148a7f61bd1@mecka.net>

The sound-dai-cells property is used, e.g. in rk356x.dtsi

Signed-off-by: Manuel Traut <manut at mecka.net>
---
 .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml        | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 7e59dee15a5f..43250255fb6f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -94,6 +94,9 @@ properties:
       - const: default
       - const: unwedge
 
+  '#sound-dai-cells':
+    const: 0
+
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
 
@@ -145,6 +148,7 @@ examples:
         interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
         clocks = <&cru  PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
         clock-names = "iahb", "isfr";
+        #sound-dai-cells = <0>;
 
         ports {
             port {

-- 
2.43.0



From manut at mecka.net  Fri Dec 22 03:05:40 2023
From: manut at mecka.net (Manuel Traut)
Date: Fri, 22 Dec 2023 12:05:40 +0100
Subject: [PATCH 0/6] arm64: rockchip: Pine64 pinetab2 support
Message-ID: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>

This adds support for the BOE TH101MB31IG002 LCD Panel used in Pinetab2 [1] and
Pinetab-V [2] as well as the devictrees for the Pinetab2 v0.1 and v2.0.

The BOE LCD Panel patch was retrieved from [3]. The function-name prefix has
been adapted and the LCD init section was simplified.

The Pinetab2 devicetree patch was retrieved from [4]. Some renaming was needed
to pass the dtb-checks, the brightness-levels are specified as range and steps
instead of a list of values.

The last to patches fix some dtb-checker warnings that showed up with the new
device-trees.

[1] https://wiki.pine64.org/wiki/PineTab2
[2] https://wiki.pine64.org/wiki/PineTab-V
[3] https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/display/0018-drm-panel-add-BOE-TH101MB31IG002-28A-driver.patch?ref_type=heads
[4] https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/device-tree/0134-arch-arm64-add-Pine64-PineTab2-device-trees.patch?ref_type=heads

Signed-off-by: Manuel Traut <manut at mecka.net>
---
Manuel Traut (4):
      dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel
      dt-bindings: arm64: rockchip: Add Pine64 Pinetab2
      arm64: dts: rockchip: Fix some dtb-check warnings
      dt-bindings: display: rockchip: dw-hdmi: Add missing sound-dai-cells property

Segfault (2):
      drm/panel: Add driver for BOE TH101MB31IG002-28A panel
      arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2

 .../devicetree/bindings/arm/rockchip.yaml          |    8 +
 .../display/panel/boe,th101mb31ig002-28a.yaml      |   73 ++
 .../display/rockchip/rockchip,dw-hdmi.yaml         |    4 +
 arch/arm64/boot/dts/rockchip/Makefile              |    2 +
 .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts     |   26 +
 .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts     |   46 +
 arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi  | 1032 ++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk356x.dtsi           |    5 +-
 drivers/gpu/drm/panel/Kconfig                      |   11 +
 drivers/gpu/drm/panel/Makefile                     |    1 +
 .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c   |  307 ++++++
 11 files changed, 1513 insertions(+), 2 deletions(-)
---
base-commit: 24e0d2e527a39f64caeb2e6be39ad5396fb2da5e
change-id: 20231222-pinetab2-faa77e01db6f

Best regards,
-- 
Manuel Traut <manut at mecka.net>



From manut at mecka.net  Fri Dec 22 03:05:44 2023
From: manut at mecka.net (Manuel Traut)
Date: Fri, 22 Dec 2023 12:05:44 +0100
Subject: [PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64
 Pinetab2
In-Reply-To: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
Message-ID: <20231222-pinetab2-v1-4-e148a7f61bd1@mecka.net>

From: Segfault <awarnecke002 at hotmail.com>

This includes support for both the v0.1 units that were sent to developers and
the v2.0 units from production.

v1.0 is not included as no units are known to exist.

Working/Tested:
- SDMMC
- UART
- Buttons
- Charging/Battery/PMIC
- Audio
- USB
- Display

WiFi is not added, since the driver is not ready for mainline.

Signed-off-by: Segfault <awarnecke002 at hotmail.com>
Signed-off-by: Manuel Traut <manut at mecka.net>
---
 arch/arm64/boot/dts/rockchip/Makefile              |    2 +
 .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts     |   26 +
 .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts     |   46 +
 arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi  | 1032 ++++++++++++++++++++
 4 files changed, 1106 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index a18f33bf0c0e..ef66c0937a9b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -77,6 +77,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v0.1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v2.0.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
new file mode 100644
index 000000000000..ba244545ba26
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+	model = "Pine64 PineTab2 v0.1";
+	compatible = "pine64,pinetab2-v0.1", "pine64,pinetab2", "rockchip,rk3566";
+};
+
+&lcd {
+	reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+};
+
+&pinctrl {
+	display {
+		lcd0_rst_l: lcd0-rst-l {
+			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&vcc_wl {
+	gpio = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
new file mode 100644
index 000000000000..f401ff802175
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+	model = "Pine64 PineTab2 v2.0";
+	compatible = "pine64,pinetab2-v2.0", "pine64,pinetab2", "rockchip,rk3566";
+};
+
+&gpio_keys {
+	pinctrl-0 = <&kb_id_det>, <&hall_int_l>;
+
+	event-hall-sensor {
+		debounce-interval = <20>;
+		gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+		label = "Hall Sensor";
+		linux,code = <SW_LID>;
+		linux,input-type = <EV_SW>;
+		wakeup-event-action = <EV_ACT_DEASSERTED>;
+		wakeup-source;
+	};
+};
+
+&lcd {
+	reset-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_LOW>;
+};
+
+&pinctrl {
+	display {
+		lcd0_rst_l: lcd0-rst-l {
+			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	hall {
+		hall_int_l: hall-int-l {
+			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&vcc_wl {
+	gpio = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
new file mode 100644
index 000000000000..6d320cfee338
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -0,0 +1,1032 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include <dt-bindings/usb/pd.h>
+#include "rk3566.dtsi"
+
+/ {
+	chassis-type = "tablet";
+
+	aliases {
+		mmc0 = &sdmmc0;
+		mmc1 = &sdhci;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <25>;
+
+		button-vol-up {
+			label = "Volume Up";
+			linux,code = <KEY_VOLUMEUP>;
+			press-threshold-microvolt = <297500>;
+		};
+
+		button-vol-down {
+			label = "Volume Down";
+			linux,code = <KEY_VOLUMEDOWN>;
+			press-threshold-microvolt = <1750>;
+		};
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm4 0 25000 0>;
+		brightness-levels = <20 220>;
+		num-interpolated-steps = <200>;
+		default-brightness-level = <100>;
+		power-supply = <&vcc_sys>;
+	};
+
+	battery: battery {
+		compatible = "simple-battery";
+		charge-full-design-microamp-hours = <6000000>;
+		charge-term-current-microamp = <300000>;
+		constant-charge-current-max-microamp = <2000000>;
+		constant-charge-voltage-max-microvolt = <4300000>;
+		voltage-max-design-microvolt = <4350000>;
+		voltage-min-design-microvolt = <3400000>;
+
+		ocv-capacity-celsius = <20>;
+		ocv-capacity-table-0 = <4322000 100>, <4250000 95>, <4192000 90>, <4136000 85>,
+				       <4080000 80>, <4022000 75>, <3972000 70>, <3928000 65>,
+				       <3885000 60>, <3833000 55>, <3798000 50>, <3780000 45>,
+				       <3776000 40>, <3773000 35>, <3755000 30>, <3706000 25>,
+				       <3640000 20>, <3589000 15>, <3535000 10>, <3492000 5>,
+				       <3400000 0>;
+	};
+
+	gpio_keys: gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&kb_id_det>;
+
+		tablet-mode-switch {
+			debounce-interval = <20>;
+			gpios = <&gpio4 RK_PA4 GPIO_ACTIVE_HIGH>;
+			label = "Tablet Mode";
+			linux,input-type = <EV_SW>;
+			linux,code = <SW_TABLET_MODE>;
+		};
+	};
+
+	hdmi-con {
+		compatible = "hdmi-connector";
+		type = "d";
+
+		port {
+			hdmi_con_in: endpoint {
+				remote-endpoint = <&hdmi_out_con>;
+			};
+		};
+	};
+
+	led-flash {
+		compatible = "regulator-led";
+		vled-supply = <&led_flash_reg>;
+		function = LED_FUNCTION_FLASH;
+		color = <LED_COLOR_ID_WHITE>;
+	};
+
+	led_flash_reg: led-flash-reg {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&flash_led_en_h>;
+		regulator-name = "led_flash_reg";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v_midu>;
+	};
+
+	rk817-sound {
+		compatible = "simple-audio-card";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hp_det_l>;
+		simple-audio-card,format = "i2s";
+		simple-audio-card,name = "PineTab2";
+		simple-audio-card,mclk-fs = <256>;
+
+		simple-audio-card,widgets =
+			"Microphone", "Mic Jack",
+			"Headphone", "Headphones",
+			"Microphone", "Microphone",
+			"Speaker", "Speakers";
+
+		simple-audio-card,routing =
+			"MICL", "Microphone",
+			"MICR", "Mic Jack",
+			"Headphones", "HPOL",
+			"Headphones", "HPOR",
+			"Speaker Amplifier INL", "HPOL",
+			"Speaker Amplifier INR", "HPOR",
+			"Speakers", "Speaker Amplifier OUTL",
+			"Speakers", "Speaker Amplifier OUTR";
+
+		simple-audio-card,hp-det-gpio = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
+		simple-audio-card,aux-devs = <&speaker_amp>;
+		simple-audio-card,pin-switches = "Speakers", "Microphone";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s1_8ch>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&rk817>;
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk817 1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_reset>;
+		reset-gpios = <&gpio3 RK_PD2 GPIO_ACTIVE_LOW>;
+		post-power-on-delay-ms = <200>;
+	};
+
+	speaker_amp: speaker-amplifier {
+		compatible = "simple-audio-amplifier";
+		pinctrl-names = "default";
+		pinctrl-0 = <&spk_ctl>;
+		enable-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_HIGH>;
+		sound-name-prefix = "Speaker Amplifier";
+		VCC-supply = <&vcc_bat>;
+	};
+
+	vcc_3v3: vcc_3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc3v3_minipcie: vcc3v3_minipcie {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PC3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pcie_pwren_h>;
+		regulator-name = "vcc3v3_minipcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc3v3_sd: vcc3v3_sd {
+		compatible = "regulator-fixed";
+		gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc_pwren_l>;
+		regulator-name = "vcc3v3_sd";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc5v0_usb_host0: vcc5v0_usb_host0 {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PC4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren1_h>;
+		regulator-name = "vcc5v0_usb_host0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v_midu>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc5v0_usb_host2: vcc5v0_usb_host2 {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PC5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren2_h>;
+		regulator-name = "vcc5v0_usb_host2";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v_midu>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc_bat: vcc_bat {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_bat";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vcc_sys: vcc_sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc_bat>;
+	};
+
+	vcc_wl: vcc_wl {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_pwren>;
+		regulator-name = "vcc_wl";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd1v2_dvp: vdd1v2_dvp {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd1v2_dvp";
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+		vin-supply = <&vcc_3v3>;
+		/*enable-supply = <&vcc2v8_dvp>;*/
+	};
+};
+
+&combphy1 {
+	status = "okay";
+};
+
+&combphy2 {
+	status = "okay";
+};
+
+&cpu0 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cru {
+	assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>, <&cru PLL_VPLL>;
+	assigned-clock-rates = <1200000000>, <200000000>, <500000000>;
+};
+
+&csi_dphy {
+	status = "okay";
+};
+
+&dsi0 {
+	status = "okay";
+	clock-master;
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	lcd: panel at 0 {
+		compatible = "boe,th101mb31ig002-28a";
+		reg = <0>;
+		backlight = <&backlight>;
+		enable-gpios = <&gpio0 RK_PC7 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&lcd_pwren_h &lcd0_rst_l>;
+		rotation = <90>;
+		power-supply = <&vcc_3v3>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				panel_in_dsi: endpoint at 0 {
+					reg = <0>;
+					remote-endpoint = <&dsi0_out_con>;
+				};
+			};
+		};
+	};
+};
+
+&dsi0_in {
+	dsi0_in_vp1: endpoint {
+		remote-endpoint = <&vp1_out_dsi0>;
+	};
+};
+
+&dsi0_out {
+	dsi0_out_con: endpoint {
+		remote-endpoint = <&panel_in_dsi>;
+	};
+};
+
+&dsi_dphy0 {
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu_npu>;
+	status = "okay";
+};
+
+&hdmi {
+	avdd-0v9-supply = <&vdda_0v9_p>;
+	avdd-1v8-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&hdmi_in {
+	hdmi_in_vp0: endpoint {
+		remote-endpoint = <&vp0_out_hdmi>;
+	};
+};
+
+&hdmi_out {
+	hdmi_out_con: endpoint {
+		remote-endpoint = <&hdmi_con_in>;
+	};
+};
+
+&hdmi_sound {
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	vdd_cpu: regulator at 1c {
+		compatible = "tcs,tcs4525";
+		reg = <0x1c>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu";
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <1150000>;
+		regulator-ramp-delay = <2300>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	rk817: pmic at 20 {
+		compatible = "rockchip,rk817";
+		reg = <0x20>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+		assigned-clocks = <&cru I2S1_MCLKOUT_TX>;
+		assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>;
+		clock-names = "mclk";
+		clocks = <&cru I2S1_MCLKOUT_TX>;
+		clock-output-names = "rk808-clkout1", "rk808-clkout2";
+		#clock-cells = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>, <&i2s1m0_mclk>;
+		rockchip,system-power-controller;
+		#sound-dai-cells = <0>;
+		wakeup-source;
+
+		vcc1-supply = <&vcc_sys>;
+		vcc2-supply = <&vcc_sys>;
+		vcc3-supply = <&vcc_sys>;
+		vcc4-supply = <&vcc_sys>;
+		vcc5-supply = <&vcc_sys>;
+		vcc6-supply = <&vcc_sys>;
+		vcc7-supply = <&vcc_sys>;
+		vcc8-supply = <&vcc_sys>;
+		vcc9-supply = <&vcc5v_midu>;
+
+		regulators {
+			vdd_logic: DCDC_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vdd_logic";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_gpu_npu: DCDC_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vdd_gpu_npu";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vcc_ddr";
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc3v3_sys: DCDC_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vcc3v3_sys";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca1v8_pmu: LDO_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca1v8_pmu";
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vdda_0v9_p: LDO_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-name = "vdda_0v9_p";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda0v9_pmu: LDO_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-name = "vdda0v9_pmu";
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vccio_acodec: LDO_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vccio_acodec";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd: LDO_REG5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vccio_sd";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_pmu: LDO_REG6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc3v3_pmu";
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: LDO_REG7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc1v8_dvp: LDO_REG8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8_dvp";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc2v8_dvp: LDO_REG9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-name = "vcc2v8_dvp";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc5v_midu: BOOST {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5000000>;
+				regulator-name = "boost";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vbus: OTG_SWITCH {
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5000000>;
+				regulator-name = "otg_switch";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+
+		charger {
+			monitored-battery = <&battery>;
+			rockchip,resistor-sense-micro-ohms = <10000>;
+			rockchip,sleep-enter-current-microamp = <300000>;
+			rockchip,sleep-filter-current-microamp = <100000>;
+		};
+	};
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	touchscreen at 5d {
+		compatible = "goodix,gt911";
+		reg = <0x5d>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_EDGE_FALLING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&tp_int_l_pmuio2>, <&tp_rst_l_pmuio2>;
+		AVDD28-supply = <&vcc3v3_pmu>;
+		VDDIO-supply = <&vcca1v8_pmu>;
+		irq-gpios = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+	pinctrl-0 = <&i2c2m1_xfer>;
+	status = "okay";
+
+	vcm at c {
+		compatible = "dongwoon,dw9714";
+		reg = <0x0c>;
+		vcc-supply = <&vcc1v8_dvp>;
+	};
+
+	camera at 36 {
+		compatible = "ovti,ov5648";
+		reg = <0x36>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&camerab_pdn_l &camerab_rst_l>;
+
+		clocks = <&cru CLK_CIF_OUT>;
+		assigned-clocks = <&cru CLK_CIF_OUT>;
+		assigned-clock-rates = <24000000>;
+
+		avdd-supply = <&vcc2v8_dvp>;
+		dvdd-supply = <&vdd1v2_dvp>;
+		dovdd-supply = <&vcc1v8_dvp>;
+		powerdown-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
+
+		port {
+			endpoint {
+				data-lanes = <1 2>;
+				remote-endpoint = <0>;
+				link-frequencies = /bits/ 64 <210000000 168000000>;
+			};
+		};
+	};
+};
+
+&i2c5 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	accelerometer at 18 {
+		compatible = "silan,sc7a20";
+		reg = <0x18>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gsensor_int_l>;
+		st,drdy-int-pin = <1>;
+		vdd-supply = <&vcc_1v8>;
+		vddio-supply = <&vcc_1v8>;
+		mount-matrix = "1", "0", "0",
+			       "0", "0", "1",
+			       "0", "1", "0";
+	};
+};
+
+&i2s0_8ch {
+	status = "okay";
+};
+
+&i2s1_8ch {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s1m0_sclktx
+		     &i2s1m0_lrcktx
+		     &i2s1m0_sdi0
+		     &i2s1m0_sdo0>;
+	rockchip,trcm-sync-tx-only;
+	status = "okay";
+};
+
+&pcie2x1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie_reset_h>;
+	reset-gpios = <&gpio1 RK_PB2 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_minipcie>;
+	status = "okay";
+};
+
+&pinctrl {
+	accelerometer {
+		gsensor_int_l: gsensor-int-l {
+			rockchip,pins = <3 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	bluetooth {
+		bt_wake_host_h: bt-wake-host-h {
+			rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	camerab {
+		camerab_pdn_l: camerab-pdn-l {
+			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		camerab_rst_l: camerab-rst-l {
+			rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	cameraf {
+		cameraf_pdn_l: cameraf-pdn-l {
+			rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		cameraf_rst_l: cameraf-rst-l {
+			rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	display {
+		lcd_pwren_h: lcd-pwren-h {
+			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	flash {
+		flash_led_en_h: flash-led-en-h {
+			rockchip,pins = <4 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	keyboard {
+		kb_id_det: kb-id-det {
+			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pcie {
+		pcie_pwren_h: pcie-pwren-h {
+			rockchip,pins = <4 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		pcie_reset_h: pcie-reset-h {
+			rockchip,pins = <1 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		pmic_int_l: pmic-int-l {
+			rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sd {
+		sdmmc_pwren_l: sdmmc-pwren-l {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	fspi {
+		fspi_dual_io_pins: fspi-dual-io-pins {
+			rockchip,pins =
+				/* fspi_clk */
+				<1 RK_PD0 1 &pcfg_pull_none>,
+				/* fspi_cs0n */
+				<1 RK_PD3 1 &pcfg_pull_none>,
+				/* fspi_d0 */
+				<1 RK_PD1 1 &pcfg_pull_none>,
+				/* fspi_d1 */
+				<1 RK_PD2 1 &pcfg_pull_none>;
+		};
+	};
+
+	sound {
+		hp_det_l: hp-det-l {
+			rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		spk_ctl: spk-ctl {
+			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	touchscreen {
+		tp_int_l_pmuio2: tp-int-l-pmuio2 {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		tp_rst_l_pmuio2: tp-rst-l-pmuio2 {
+			rockchip,pins = <0 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		usbcc_int_l: usbcc-int-l {
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_host_pwren1_h: usb-host-pwren1-h {
+			rockchip,pins = <4 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_host_pwren2_h: usb-host-pwren2-h {
+			rockchip,pins = <4 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wifi {
+		host_wake_wl: host-wake-wl {
+			rockchip,pins = <0 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_pwren: wifi-pwren {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_reg_on_h: wifi-reg-on-h {
+			rockchip,pins = <0 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_reset: wifi-reset {
+			rockchip,pins = <3 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_wake_host_h: wifi-wake-host-h {
+			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+};
+
+&pmu_io_domains {
+	pmuio1-supply = <&vcc3v3_pmu>;
+	pmuio2-supply = <&vcca1v8_pmu>;
+	vccio1-supply = <&vccio_acodec>;
+	vccio2-supply = <&vcc_1v8>;
+	vccio3-supply = <&vccio_sd>;
+	vccio4-supply = <&vcc_1v8>;
+	vccio5-supply = <&vcc_1v8>;
+	vccio6-supply = <&vcc1v8_dvp>;
+	vccio7-supply = <&vcc_3v3>;
+	status = "okay";
+};
+
+&pwm4 {
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs200-1_8v;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_bus8
+		     &emmc_clk
+		     &emmc_cmd
+		     &emmc_datastrobe
+		     &emmc_rstnout>;
+	vmmc-supply = <&vcc_3v3>;
+	vqmmc-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdmmc0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc0_bus4
+		     &sdmmc0_clk
+		     &sdmmc0_cmd
+		     &sdmmc0_det>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc3v3_sd>;
+	vqmmc-supply = <&vccio_sd>;
+	status = "okay";
+};
+
+&sdmmc1 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc1_bus4
+		     &sdmmc1_cmd
+		     &sdmmc1_clk>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_wl>;
+	vqmmc-supply = <&vcca1v8_pmu>;
+	status = "okay";
+};
+
+&sfc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&fspi_dual_io_pins>;
+	status = "okay";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	flash at 0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <24000000>;
+		spi-rx-bus-width = <2>;
+		spi-tx-bus-width = <1>;
+	};
+};
+
+&tsadc {
+	rockchip,hw-tshut-mode = <1>;
+	rockchip,hw-tshut-polarity = <0>;
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1m0_xfer
+		     &uart1m0_ctsn
+		     &uart1m0_rtsn>;
+	status = "okay";
+	uart-has-rtscts;
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host0_xhci {
+	status = "okay";
+};
+
+&usb_host1_xhci {
+	status = "okay";
+};
+
+&usb2phy0 {
+	status = "okay";
+};
+
+&usb2phy0_host {
+	phy-supply = <&vcc5v0_usb_host0>;
+	status = "okay";
+};
+
+&usb2phy0_otg {
+	status = "okay";
+};
+
+&usb2phy1 {
+	status = "okay";
+};
+
+&usb2phy1_otg {
+	phy-supply = <&vcc5v0_usb_host2>;
+	status = "okay";
+};
+
+&vop {
+	assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+	assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+	status = "okay";
+};
+
+&vop_mmu {
+	status = "okay";
+};
+
+&vp0 {
+	vp0_out_hdmi: endpoint at ROCKCHIP_VOP2_EP_HDMI0 {
+		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi_in_vp0>;
+	};
+};
+
+&vp1 {
+	vp1_out_dsi0: endpoint at ROCKCHIP_VOP2_EP_MIPI0 {
+		reg = <ROCKCHIP_VOP2_EP_MIPI0>;
+		remote-endpoint = <&dsi0_in_vp1>;
+	};
+};

-- 
2.43.0



From fusibrandon13 at gmail.com  Fri Dec 22 03:14:04 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Fri, 22 Dec 2023 12:14:04 +0100
Subject: [RFC PATCH v3 0/3] Add support for reading D1 efuse speed bin
Message-ID: <20231222111407.104270-1-fusibrandon13@gmail.com>

Hi everyone,

This series is an attempt to get feedback on decoding D1 efuse speed bins
in the Sun50i H6 cpufreq driver, and turning the result into a meaningful
value that selects voltage ranges in an OPP table.

I want to make sure I get this right before sending in a v3 of the D1
cpufreq support series here

https://lore.kernel.org/linux-sunxi/20231218110543.64044-1-fusibrandon13 at gmail.com/T/#t

which is currently stuck at

https://lore.kernel.org/linux-sunxi/aad8302d-a015-44ee-ad11-1a4c6e00074c at sholland.org/

Changes in v3:
- Drop 'len' parameter and pointer in sunxi_cpufreq_data::efuse_xlate()
  prototype

Changes in v2:
- Make speed bin decoding generic in one patch and add D1 support in a
  separate patch
- Fix OPP voltage ranges to avoid stability issues

Brandon Cheo Fusi (3):
  cpufreq: sun50i: Refactor speed bin decoding
  cpufreq: sun50i: Add support for D1's speed bin decoding
  riscv: dts: allwinner: Fill in OPPs

 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 19 +++-
 drivers/cpufreq/sun50i-cpufreq-nvmem.c        | 89 +++++++++++++++----
 2 files changed, 87 insertions(+), 21 deletions(-)

-- 
2.30.2



From fusibrandon13 at gmail.com  Fri Dec 22 03:14:05 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Fri, 22 Dec 2023 12:14:05 +0100
Subject: [RFC PATCH v3 1/3] cpufreq: sun50i: Refactor speed bin decoding
In-Reply-To: <20231222111407.104270-1-fusibrandon13@gmail.com>
References: <20231222111407.104270-1-fusibrandon13@gmail.com>
Message-ID: <20231222111407.104270-2-fusibrandon13@gmail.com>

Make converting the speed bin value into a speed grade generic
and determined by a platform specific callback.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/sun50i-cpufreq-nvmem.c | 58 ++++++++++++++++++--------
 1 file changed, 40 insertions(+), 18 deletions(-)

diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 32a9c88f8..e8c2a1dc3 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -25,6 +25,38 @@
 
 static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
 
+struct sunxi_cpufreq_data {
+	u32 (*efuse_xlate)(u32 speedbin);
+};
+
+static u32 sun50i_efuse_xlate(u32 speedbin)
+{
+	u32 efuse_value;
+
+	efuse_value = (speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
+
+	/*
+	* We treat unexpected efuse values as if the SoC was from
+	* the slowest bin. Expected efuse values are 1-3, slowest
+	* to fastest.
+	*/
+	if (efuse_value >= 1 && efuse_value <= 3)
+		return efuse_value - 1;
+	else
+		return 0;
+}
+
+static struct sunxi_cpufreq_data sun50i_cpufreq_data = {
+	.efuse_xlate = sun50i_efuse_xlate,
+};
+
+static const struct of_device_id cpu_opp_match_list[] = {
+	{ .compatible = "allwinner,sun50i-h6-operating-points",
+	  .data = &sun50i_cpufreq_data,
+	},
+	{}
+};
+
 /**
  * sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
  * @versions: Set to the value parsed from efuse
@@ -36,9 +68,9 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	struct nvmem_cell *speedbin_nvmem;
 	struct device_node *np;
 	struct device *cpu_dev;
-	u32 *speedbin, efuse_value;
-	size_t len;
-	int ret;
+	const struct of_device_id *match;
+	const struct sunxi_cpufreq_data *opp_data;
+	u32 *speedbin;
 
 	cpu_dev = get_cpu_device(0);
 	if (!cpu_dev)
@@ -48,12 +80,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	if (!np)
 		return -ENOENT;
 
-	ret = of_device_is_compatible(np,
-				      "allwinner,sun50i-h6-operating-points");
-	if (!ret) {
+	match = of_match_node(cpu_opp_match_list, np);
+	if (!match) {
 		of_node_put(np);
 		return -ENOENT;
 	}
+	opp_data = match->data;
 
 	speedbin_nvmem = of_nvmem_cell_get(np, NULL);
 	of_node_put(np);
@@ -61,22 +93,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 		return dev_err_probe(cpu_dev, PTR_ERR(speedbin_nvmem),
 				     "Could not get nvmem cell\n");
 
-	speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+	speedbin = nvmem_cell_read(speedbin_nvmem, NULL);
 	nvmem_cell_put(speedbin_nvmem);
 	if (IS_ERR(speedbin))
 		return PTR_ERR(speedbin);
 
-	efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
-
-	/*
-	 * We treat unexpected efuse values as if the SoC was from
-	 * the slowest bin. Expected efuse values are 1-3, slowest
-	 * to fastest.
-	 */
-	if (efuse_value >= 1 && efuse_value <= 3)
-		*versions = efuse_value - 1;
-	else
-		*versions = 0;
+	*versions = opp_data->efuse_xlate(*speedbin);
 
 	kfree(speedbin);
 	return 0;
-- 
2.30.2



From fusibrandon13 at gmail.com  Fri Dec 22 03:14:06 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Fri, 22 Dec 2023 12:14:06 +0100
Subject: [RFC PATCH v3 2/3] cpufreq: sun50i: Add support for D1's speed bin decoding
In-Reply-To: <20231222111407.104270-1-fusibrandon13@gmail.com>
References: <20231222111407.104270-1-fusibrandon13@gmail.com>
Message-ID: <20231222111407.104270-3-fusibrandon13@gmail.com>

Adds support for decoding the efuse value read from D1 efuse speed
bins, and factors out equivalent code for sun50i.

The algorithm is gotten from

https://github.com/Tina-Linux/linux-5.4/blob/master/drivers/cpufreq/sun50i-cpufreq-nvmem.c#L293-L338

and maps an efuse value to either 0 or 1, with 1 meaning stable at
a lower supply voltage for the same clock frequency.

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 drivers/cpufreq/sun50i-cpufreq-nvmem.c | 31 ++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index e8c2a1dc3..26bb5217b 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -29,6 +29,29 @@ struct sunxi_cpufreq_data {
 	u32 (*efuse_xlate)(u32 speedbin);
 };
 
+static u32 sun20i_efuse_xlate(u32 speedbin)
+{
+	u32 ret;
+
+	switch (speedbin & 0xffff) {
+	case 0x5e00:
+		/* QFN package */
+		ret = 0;
+		break;
+	case 0x5c00:
+	case 0x7400:
+		/* QFN package */
+		ret = 1;
+		break;
+	case 0x5000:
+	default:
+		/* BGA package */
+		ret = 0;
+	}
+
+	return ret;
+}
+
 static u32 sun50i_efuse_xlate(u32 speedbin)
 {
 	u32 efuse_value;
@@ -46,6 +69,10 @@ static u32 sun50i_efuse_xlate(u32 speedbin)
 		return 0;
 }
 
+struct sunxi_cpufreq_data sun20i_cpufreq_data = {
+	.efuse_xlate = sun20i_efuse_xlate,
+};
+
 static struct sunxi_cpufreq_data sun50i_cpufreq_data = {
 	.efuse_xlate = sun50i_efuse_xlate,
 };
@@ -54,6 +81,9 @@ static const struct of_device_id cpu_opp_match_list[] = {
 	{ .compatible = "allwinner,sun50i-h6-operating-points",
 	  .data = &sun50i_cpufreq_data,
 	},
+	{ .compatible = "allwinner,sun20i-d1-operating-points",
+	  .data = &sun20i_cpufreq_data,
+	},
 	{}
 };
 
@@ -182,6 +212,7 @@ static struct platform_driver sun50i_cpufreq_driver = {
 
 static const struct of_device_id sun50i_cpufreq_match_list[] = {
 	{ .compatible = "allwinner,sun50i-h6" },
+	{ .compatible = "allwinner,sun20i-d1" },
 	{}
 };
 MODULE_DEVICE_TABLE(of, sun50i_cpufreq_match_list);
-- 
2.30.2



From fusibrandon13 at gmail.com  Fri Dec 22 03:14:07 2023
From: fusibrandon13 at gmail.com (Brandon Cheo Fusi)
Date: Fri, 22 Dec 2023 12:14:07 +0100
Subject: [RFC PATCH v3 3/3] riscv: dts: allwinner: Fill in OPPs
In-Reply-To: <20231222111407.104270-1-fusibrandon13@gmail.com>
References: <20231222111407.104270-1-fusibrandon13@gmail.com>
Message-ID: <20231222111407.104270-4-fusibrandon13@gmail.com>

Specify two voltage ranges, in order of increasing stability,
for each OPP.

Also define an nvmem cpu speed grade cell of length 2.

Link: https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L133
Link: https://github.com/mangopi-sbc/tina-linux-5.4/blob/0d4903ebd9d2194ad914686d5b0fc1ddacf11a9d/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L182

Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
---
 arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
index 64c3c2e6c..7e2e015e0 100644
--- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
+++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
@@ -39,16 +39,23 @@ cpu0_intc: interrupt-controller {
 	};
 
 	opp_table_cpu: opp-table-cpu {
-		compatible = "operating-points-v2";
+		compatible = "allwinner,sun20i-d1-operating-points";
+		nvmem-cells = <&cpu_speed_grade>;
+		nvmem-cell-names = "speed";
+		opp-shared;
 
 		opp-408000000 {
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <900000 900000 1100000>;
+
+			opp-microvolt-speed0 = <950000 950000 1100000>;
+			opp-microvolt-speed1 = <900000 900000 1100000>;
 		};
 
 		opp-1080000000 {
 			opp-hz = /bits/ 64 <1008000000>;
-			opp-microvolt = <900000 900000 1100000>;
+
+			opp-microvolt-speed0 = <1100000>;
+			opp-microvolt-speed1 = <950000 950000 1100000>;
 		};
 	};
 
@@ -115,3 +122,9 @@ pmu {
 			<0x00000000 0x0000000f 0xffffffff 0xffffffff 0x00020000>;
 	};
 };
+
+&sid {
+	cpu_speed_grade: cpu-speed-grade at 0 {
+		reg = <0x00 0x2>;
+	};
+};
-- 
2.30.2



From manut at mecka.net  Fri Dec 22 03:05:45 2023
From: manut at mecka.net (Manuel Traut)
Date: Fri, 22 Dec 2023 12:05:45 +0100
Subject: [PATCH 5/6] arm64: dts: rockchip: Fix some dtb-check warnings
In-Reply-To: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
Message-ID: <20231222-pinetab2-v1-5-e148a7f61bd1@mecka.net>

devicetree checks show some warnings:

video-codec at fdea0400: 'interrupt-names' is a required property
from schema $id: http://devicetree.org/schemas/media/rockchip-vpu.yaml#

hdmi at fe0a0000: Unevaluated properties are not allowed ('power-domains' were unexpected)
from schema $id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#

i2s at fe420000: reset-names:0: 'm' is not one of ['tx-m', 'rx-m']
from schema $id: http://devicetree.org/schemas/sound/rockchip,i2s-tdm.yaml#

phy at fe870000: 'power-domains' is a required property
from schema $id: http://devicetree.org/schemas/phy/rockchip-inno-csi-dphy.yaml#

Fix them by
  - setting a interrupt-name for the video-codec
  - remove the unevaluated power-domain property from hdmi
  - set reset-names according to the spec for i2s
  - add a power-domain property for the CSI phy

Signed-off-by: Manuel Traut <manut at mecka.net>
---
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index c19c0f1b3778..651156759582 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -597,6 +597,7 @@ vpu: video-codec at fdea0400 {
 		compatible = "rockchip,rk3568-vpu";
 		reg = <0x0 0xfdea0000 0x0 0x800>;
 		interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "vdpu";
 		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
 		clock-names = "aclk", "hclk";
 		iommus = <&vdpu_mmu>;
@@ -819,7 +820,6 @@ hdmi: hdmi at fe0a0000 {
 		clock-names = "iahb", "isfr", "cec", "ref";
 		pinctrl-names = "default";
 		pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
-		power-domains = <&power RK3568_PD_VO>;
 		reg-io-width = <4>;
 		rockchip,grf = <&grf>;
 		#sound-dai-cells = <0>;
@@ -1123,7 +1123,7 @@ i2s2_2ch: i2s at fe420000 {
 		dmas = <&dmac1 4>, <&dmac1 5>;
 		dma-names = "tx", "rx";
 		resets = <&cru SRST_M_I2S2_2CH>;
-		reset-names = "m";
+		reset-names = "tx-m", "rx-m";
 		rockchip,grf = <&grf>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&i2s2m0_sclktx
@@ -1739,6 +1739,7 @@ csi_dphy: phy at fe870000 {
 		clocks = <&cru PCLK_MIPICSIPHY>;
 		clock-names = "pclk";
 		#phy-cells = <0>;
+		power-domains = <&power RK3568_PD_VO>;
 		resets = <&cru SRST_P_MIPICSIPHY>;
 		reset-names = "apb";
 		rockchip,grf = <&grf>;

-- 
2.43.0



From wahrenst at gmx.net  Fri Dec 22 03:26:20 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Fri, 22 Dec 2023 12:26:20 +0100
Subject: imx7_media_csi probe deferred
In-Reply-To: <CAJ+vNU2Kj=a-_xDBsNO5zkyP_mgLsVtA2bXqkAkpmCQmVEA_=w@mail.gmail.com>
References: <CAJ+vNU2Kj=a-_xDBsNO5zkyP_mgLsVtA2bXqkAkpmCQmVEA_=w@mail.gmail.com>
Message-ID: <6cc73cc9-cc57-44ef-baf0-809e634c38c5@gmx.net>

Hi Tim,

Am 22.12.23 um 02:12 schrieb Tim Harvey:
> Greetings,
>
> I'm running into an issue with Linux 6.6 (6.6.8) when compiling with
> modules where the imx7_media_csi driver probe is deferred and I'm not
> clear how to troubleshoot the cause.
one important question would be "did it ever worked before?"
>
> The board is imx8mm-venice-gw73xx-0x [1] with
> imx8mm-venice-gw73xx-0x-imx219.dtso [2] and I'm using
> arch/arm64/configs/defconfig.
>
> The kernel reports the following:
> # dmesg | egrep csi\|mipi\|imx219
> [    1.293264] i2c 2-0010: Fixed dependency cycle(s) with
> /soc at 0/bus at 32c00000/mipi-csi at 32e30000/ports/port at 0/endpoint
> [   12.001419] imx219 2-0010: supply VANA not found, using dummy regulator
> [   12.044885] imx219 2-0010: supply VDDL not found, using dummy regulator
> [   12.164308] imx7-csi 32e20000.csi: Registered csi capture as /dev/video0
> [   12.178460] imx7-csi 32e20000.csi: error -ENOTCONN: Failed to get
> remote endpoint
> [   12.200047] imx7-csi: probe of 32e20000.csi failed with error -107
> # cat /sys/kernel/debug/devices_deferred
> cpufreq-dt
> 32e30000.mipi-csi       platform: wait for supplier
> /soc at 0/bus at 32c00000/csi at 32e20000/port/endpoint
> # zcat /proc/config.gz | egrep VIDEO_IMX219\|VIDEO_IMX_MIPI\|VIDEO_IMX7
> CONFIG_VIDEO_IMX7_CSI=m
> CONFIG_VIDEO_IMX_MIPI_CSIS=m
> CONFIG_VIDEO_IMX219=m
> # lsmod | grep imx
> fsl_imx8_ddr_perf      16384  0
> imx8m_ddrc             12288  0
> imx7_media_csi         28672  0
> videobuf2_dma_contig    16384  2 hantro_vpu,imx7_media_csi
> videobuf2_v4l2         32768  3 hantro_vpu,imx7_media_csi,v4l2_mem2mem
> videobuf2_common       57344  6
> videobuf2_dma_contig,videobuf2_v4l2,hantro_vpu,imx7_media_csi,v4l2_mem2mem,videobuf2_memops
> imx_mipi_csis          24576  0
> imx219                 20480  0
> v4l2_cci               12288  1 imx219
> v4l2_fwnode            20480  2 imx219,imx_mipi_csis
> v4l2_async             20480  4 v4l2_fwnode,imx219,imx_mipi_csis,imx7_media_csi
> videodev              258048  8
> v4l2_async,v4l2_fwnode,imx219,videobuf2_v4l2,hantro_vpu,imx_mipi_csis,imx7_media_csi,v4l2_mem2mem
> mc                     61440  9
> v4l2_async,videodev,imx219,videobuf2_v4l2,hantro_vpu,videobuf2_common,imx_mipi_csis,imx7_media_csi,v4l
> 2_mem2mem
> spi_imx                24576  0
> imx_pcm_dma            12288  1 snd_soc_fsl_sai
> imx8mm_thermal         12288  0
> imx_sdma               24576  6
> imx_cpufreq_dt         12288  0
>
> The relevant dt looks like this:
>
> csi: csi at 32e20000 {
>       compatible = "fsl,imx8mm-csi", "fsl,imx7-csi";
>       reg = <0x32e20000 0x1000>;
>       interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
>       clocks = <&clk IMX8MM_CLK_CSI1_ROOT>;
>       clock-names = "mclk";
>       power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_CSI_BRIDGE>;
Just a wild guess, has the power domains driver probed properly?
> Strangely I have a kernel config without modules where I do not run
> into this issue so it has something to do with modules but I haven't
> been able to determine which configs make a difference.
>
> Any ideas what is wrong here or tips on troubleshooting the cause for
> the probe defer?
In case the complete dmesg doesn't provide further errors, you could try
to add "initcall_debug" to the kernel cmdline.
>
> Best Regards,
>
> Tim
> [1] https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x.dts
> [2] https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x-imx219.dtso
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From Markus.Elfring at web.de  Fri Dec 22 04:03:08 2023
From: Markus.Elfring at web.de (Markus Elfring)
Date: Fri, 22 Dec 2023 13:03:08 +0100
Subject: [PATCH] clk: imx: scu: Use common error handling code in
 imx_clk_scu_alloc_dev()
Message-ID: <01446ce9-c0e8-4467-8b2d-fd736bc5b8e4@web.de>

From: Markus Elfring <elfring at users.sourceforge.net>
Date: Fri, 22 Dec 2023 12:56:48 +0100

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

Signed-off-by: Markus Elfring <elfring at users.sourceforge.net>
---
 drivers/clk/imx/clk-scu.c | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c
index e48a904c0013..b1dd0c08e091 100644
--- a/drivers/clk/imx/clk-scu.c
+++ b/drivers/clk/imx/clk-scu.c
@@ -712,17 +712,13 @@ struct clk_hw *imx_clk_scu_alloc_dev(const char *name,
 	}

 	ret = platform_device_add_data(pdev, &clk, sizeof(clk));
-	if (ret) {
-		platform_device_put(pdev);
-		return ERR_PTR(ret);
-	}
+	if (ret)
+		goto put_device;

 	ret = driver_set_override(&pdev->dev, &pdev->driver_override,
 				  "imx-scu-clk", strlen("imx-scu-clk"));
-	if (ret) {
-		platform_device_put(pdev);
-		return ERR_PTR(ret);
-	}
+	if (ret)
+		goto put_device;

 	ret = imx_clk_scu_attach_pd(&pdev->dev, rsrc_id);
 	if (ret)
@@ -730,13 +726,15 @@ struct clk_hw *imx_clk_scu_alloc_dev(const char *name,
 			name, ret);

 	ret = platform_device_add(pdev);
-	if (ret) {
-		platform_device_put(pdev);
-		return ERR_PTR(ret);
-	}
+	if (ret)
+		goto put_device;

 	/* For API backwards compatiblilty, simply return NULL for success */
 	return NULL;
+
+put_device:
+	platform_device_put(pdev);
+	return ERR_PTR(ret);
 }

 void imx_clk_scu_unregister(void)
--
2.43.0



From konrad.dybcio at linaro.org  Fri Dec 22 04:07:33 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Fri, 22 Dec 2023 13:07:33 +0100
Subject: [PATCH v2 1/8] dt-bindings: clock: qcom: Allow VDD_GFX supply to
 GX
In-Reply-To: <26617c83-31b3-4ad9-8a61-0b8271fad41f@linaro.org>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-1-4763246b72c0@quicinc.com>
 <26617c83-31b3-4ad9-8a61-0b8271fad41f@linaro.org>
Message-ID: <94d2c5e2-d75e-4de6-928a-e278b341a02c@linaro.org>

On 22.12.2023 09:12, Krzysztof Kozlowski wrote:
> On 22/12/2023 05:39, Bjorn Andersson wrote:
>> In some designs the SoC's VDD_GFX pads are supplied by an external
>> regulator, rather than a power-domain. Allow this to be described in the
>> GPU clock controller binding.
>>
>> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
>> ---
>>  Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
>> index f369fa34e00c..c0dd24c9dcb3 100644
>> --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
>> +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
>> @@ -53,6 +53,9 @@ properties:
>>    power-domains:
>>      maxItems: 1
>>  
>> +  vdd-gfx-supply:
>> +    description: Regulator supply for the VDD_GFX pads
>> +
>>    '#clock-cells':
>>      const: 1
>>  
>> @@ -74,6 +77,19 @@ required:
>>    - '#reset-cells'
>>    - '#power-domain-cells'
>>  
>> +# Allow either power-domains or vdd-gfx-supply, not both
>> +oneOf:
>> +  - required:
>> +      - power-domains
>> +  - required:
>> +      - vdd-gfx-supply
> 
> This should be enough, assuming one of them is actually required. The
> code. See also:
> https://elixir.bootlin.com/linux/v5.17-rc2/source/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml#L91
At least one of them indeed is, though this change is being made
implicitly. No clock controller works with no power FWIW

Konrad


From wahrenst at gmx.net  Fri Dec 22 04:26:23 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Fri, 22 Dec 2023 13:26:23 +0100
Subject: [PATCH v2 1/3] usb: chipidea: ci_hdrc_imx: add wakeup clock and
 keep it always on
In-Reply-To: <20231218061420.3460145-1-xu.yang_2@nxp.com>
References: <20231218061420.3460145-1-xu.yang_2@nxp.com>
Message-ID: <568fce67-a9e2-4aa8-a165-f12efcf494b8@gmx.net>

Hi Xu,

Am 18.12.23 um 07:14 schrieb Xu Yang:
> Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
> on without usb driver intervention. And some may need driver to handle
> this clock. For now only i.MX93 needs this wakeup clock. This patch will
> get wakeup clock and keep it always on to make controller work properly.
>
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
>
> ---
> Changes in v2:
>   - modify commit msg to make it clear
> ---
>   drivers/usb/chipidea/ci_hdrc_imx.c | 22 +++++++++++++++++++++-
>   1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> index e28bb2f2612d..4330be8240ff 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -96,6 +96,7 @@ struct ci_hdrc_imx_data {
>   	struct usb_phy *phy;
>   	struct platform_device *ci_pdev;
>   	struct clk *clk;
> +	struct clk *clk_wakeup;
>   	struct imx_usbmisc_data *usbmisc_data;
>   	bool supports_runtime_pm;
>   	bool override_phy_control;
> @@ -199,7 +200,7 @@ static int imx_get_clks(struct device *dev)
>
>   	data->clk_ipg = devm_clk_get(dev, "ipg");
>   	if (IS_ERR(data->clk_ipg)) {
> -		/* If the platform only needs one clocks */
> +		/* If the platform only needs one primary clock */
>   		data->clk = devm_clk_get(dev, NULL);
>   		if (IS_ERR(data->clk)) {
>   			ret = PTR_ERR(data->clk);
> @@ -208,6 +209,18 @@ static int imx_get_clks(struct device *dev)
>   				PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
>   			return ret;
>   		}
> +		/* Get wakeup clock. Not all of the platforms need to
> +		 * handle this clock. So make it optional.
> +		 */
> +		data->clk_wakeup = devm_clk_get_optional(dev,
> +							 "usb_wakeup_clk");
> +		if (IS_ERR(data->clk_wakeup)) {
> +			ret = PTR_ERR(data->clk_wakeup);
> +			dev_err(dev,
> +				"Failed to get wakeup clk, err=%ld\n",
> +				PTR_ERR(data->clk_wakeup));
> +			return ret;
this could be simplified to:

return dev_err_probe(dev, PTR_ERR(data->clk_wakeup), "Failed to get
wakeup clk\n");

AFAIK the error code is also printed out. Another benefit is that this
handles deferred probe of the clock and avoid spamming.
> +		}
>   		return ret;
>   	}
>
> @@ -423,6 +436,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>   	if (ret)
>   		goto disable_hsic_regulator;
>
> +	ret = clk_prepare_enable(data->clk_wakeup);
> +	if (ret)
> +		goto err_wakeup_clk;
> +
>   	data->phy = devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0);
>   	if (IS_ERR(data->phy)) {
>   		ret = PTR_ERR(data->phy);
> @@ -504,6 +521,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>   disable_device:
>   	ci_hdrc_remove_device(data->ci_pdev);
>   err_clk:
> +	clk_disable_unprepare(data->clk_wakeup);
> +err_wakeup_clk:
>   	imx_disable_unprepare_clks(dev);
>   disable_hsic_regulator:
>   	if (data->hsic_pad_regulator)
> @@ -530,6 +549,7 @@ static void ci_hdrc_imx_remove(struct platform_device *pdev)
>   		usb_phy_shutdown(data->phy);
>   	if (data->ci_pdev) {
>   		imx_disable_unprepare_clks(&pdev->dev);
> +		clk_disable_unprepare(data->clk_wakeup);
>   		if (data->plat_data->flags & CI_HDRC_PMQOS)
>   			cpu_latency_qos_remove_request(&data->pm_qos_req);
>   		if (data->hsic_pad_regulator)



From olteanv at gmail.com  Fri Dec 22 04:30:23 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Fri, 22 Dec 2023 14:30:23 +0200
Subject: [PATCH net 0/1] Prevent DSA tags from breaking COE
In-Reply-To: <0351C5C2-FEE2-4AED-84C8-9DCACCE4ED0A@aol.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <0351C5C2-FEE2-4AED-84C8-9DCACCE4ED0A@aol.com>
Message-ID: <20231222123023.voxoxfcckxsz2vce@skbuf>

Hi Lucas,

On Thu, Dec 21, 2023 at 02:40:34AM -0500, Household Cang wrote:
> > On Dec 18, 2023, at 11:23 AM, Romain Gantois <romain.gantois at bootlin.com> wrote:
> > 
> > This is a bugfix for an issue that was recently brought up in two
> > reports:
> > 
> > https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495 at bootlin.com/
> > https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2 at electromag.com.au/
> > 
> Add me in to be the 3rd report...
> RK3568 GMAC0 (eth1) to MT7531BE (CPU port)
> Current workaround for me is ethtool -K eth1 rx off tx off

Is "rx off" actually required, or just "tx off"?

> https://lore.kernel.org/netdev/m3clft2k7umjtny546ot3ayebattksibty3yyttpffvdixl65p at 7dpqsr5nisbk/T/#t
> 
> Question on the patch to be built: how would I know if my setup could
> take advantage of the HW checksum offload? RK3658?s eth0 on stmmac is
> doing fine, and eth0 is not on a DSA switch. Does this mean eth1
> should be able to do hw checksum offload once the stmmac driver is
> fixed?

The MT7531BE switch requires transmitted packets to have an additional
header which indicates what switch port is targeted. So the packet
structure is not the same as what eth0 transmits.

Your GMAC datasheet should explain what packets it is able to offload
L4 checksumming for, quite plainly. Probably MAC + IP + TCP yes, but
MAC + MTK DSA + IP + TCP no.

The bug is that the network stack thinks that the GMAC is able to
offload TX checksums for these MTK DSA tagged packets, so it does not
calculate the checksum in software, leaving the task up to the hardware.
My guess is that the hardware doesn't recognize the packets as something
that is offloadable, so it doesn't calculate the checksum either, and
that's the story of how you end up with packets with bad checksums.

The patch to be built should analyze the packet before passing it to a
hardware offload engine which will do nothing. The driver still declares
the NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM features because it is able to
offload checksumming for _some_ packets, but it falls back to the
software checksum helper for the rest. This includes your MTK DSA tagged
packets. They can be checksummed in software even with the DSA tag added,
because that uses the more generic mechanism with skb->csum_start and
skb->csum_offset, which DSA is compatible with, just fine. The GMAC
driver, most likely because of the lack of hardware support, does not
look at skb->csum_start and skb->csum_offset (aka it does not declare
the NETIF_F_HW_CSUM feature), so it cannot offload checksumming for your
switch traffic unless that was specifically baked into the RTL.

More details in the "Switch tagging protocols" section of
Documentation/networking/dsa/dsa.rst.


From herve.codina at bootlin.com  Fri Dec 22 04:34:48 2023
From: herve.codina at bootlin.com (Herve Codina)
Date: Fri, 22 Dec 2023 13:34:48 +0100
Subject: [GIT PULL] PowerQUICC QMC and TSA drivers updates for v6.8
In-Reply-To: <a274ba17-6ab7-4169-a10c-22fcc9e74248@app.fastmail.com>
References: <20231212105514.273e8ab0@bootlin.com>
	<a274ba17-6ab7-4169-a10c-22fcc9e74248@app.fastmail.com>
Message-ID: <20231222133448.1413d78d@bootlin.com>

Hi Arnd,

On Fri, 22 Dec 2023 10:55:00 +0000
"Arnd Bergmann" <arnd at arndb.de> wrote:

> On Tue, Dec 12, 2023, at 09:55, Herve Codina wrote:
> > The following changes since commit 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab:
> >
> >   Linux 6.7-rc3 (2023-11-26 19:59:33 -0800)
> >
> > are available in the Git repository at:
> >
> >   git at github.com:hcodina/linux.git tags/fsl_qmc_tsa_v6.8
> >
> > for you to fetch changes up to 7a2ee1576dcc6bbe017a8283fba237b05b13fd15:
> >  
> 
> This is not a valid git URL I can pull from. I have instead pulled from
> 
>   https://github.com/hcodina/linux.git tags/fsl_qmc_tsa_v6.8
> 
> which is what I think you meant. 

Yes, exactly.
Thanks a lot for having pulled the https url.

> 
> You should probably edit your .gitconfig file to add a section
> like (not sure about the exact syntax, you'll figure it out).
> 
> [url "https://github.com"]
>     insteadOf = git at github.com
> 
> 
> >  drivers/soc/fsl/qe/qmc.c      | 658 
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------  
> 
> This is an overly long line that you probably copied from a large
> terminal window. Just for readability, I recommend redirecting the
> 'git request-pull' output, e.g. into 'xclip' or 'cat', which will
> give it the appropriate line length for emails.
> 

Thanks you these feedback and tips.
I will be more careful in the future.

Herv?


From horms at kernel.org  Fri Dec 22 04:52:34 2023
From: horms at kernel.org (Simon Horman)
Date: Fri, 22 Dec 2023 13:52:34 +0100
Subject: [PATCH v5 1/3] phy: handle optional regulator for PHY
In-Reply-To: <20231220203537.83479-2-jernej.skrabec@gmail.com>
References: <20231220203537.83479-1-jernej.skrabec@gmail.com>
 <20231220203537.83479-2-jernej.skrabec@gmail.com>
Message-ID: <20231222125234.GF1202958@kernel.org>

On Wed, Dec 20, 2023 at 09:35:35PM +0100, Jernej Skrabec wrote:
> From: Corentin Labbe <clabbe.montjoie at gmail.com>
> 
> Add handling of optional regulators for PHY.
> 
> Regulators need to be enabled before PHY scanning, so MDIO bus
> initiate this task.
> 
> Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com>
> Signed-off-by: Jernej Skrabec <jernej.skrabec at gmail.com>

Hi Jernej,

> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 3cc52826f18e..832cb2d4f76a 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -757,6 +757,9 @@ struct phy_device {
>  	void (*phy_link_change)(struct phy_device *phydev, bool up);
>  	void (*adjust_link)(struct net_device *dev);
>  
> +	int regulator_cnt;
> +	struct regulator_bulk_data *consumers;

Please add these two new fields to the kernel doc
for struct phy_device which appears a above this hunk in phy.h.

> +
>  #if IS_ENABLED(CONFIG_MACSEC)
>  	/* MACsec management functions */
>  	const struct macsec_ops *macsec_ops;

-- 
pw-bot: changes-requested


From bryan.odonoghue at linaro.org  Fri Dec 22 05:08:45 2023
From: bryan.odonoghue at linaro.org (Bryan O'Donoghue)
Date: Fri, 22 Dec 2023 13:08:45 +0000
Subject: [PATCH] arm64: defconfig: Enable Qualcomm SC8280XP camera clock
 controller
In-Reply-To: <20231221-enable-sc8280xp-camcc-v1-1-2249581dd538@quicinc.com>
References: <20231221-enable-sc8280xp-camcc-v1-1-2249581dd538@quicinc.com>
Message-ID: <61998a14-2f9a-4b37-a6d0-77451332ae6f@linaro.org>

On 22/12/2023 04:47, Bjorn Andersson wrote:
> With the camera clock controller added to the DeviceTree of SC8280XP the
> interconnect providers no longer reaches sync_state, resulting in a
> noticeable reduction in battery life.
> 
> Enable the camera clock controller (as a module) to avoid this, and
> hopefully soon provide some level of camera support.
> 
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
>   arch/arm64/configs/defconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index ef1061089548..e5ce6d08006e 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -1256,6 +1256,7 @@ CONFIG_QCM_GCC_2290=y
>   CONFIG_QCM_DISPCC_2290=m
>   CONFIG_QCS_GCC_404=y
>   CONFIG_SA_GCC_8775P=y
> +CONFIG_SC_CAMCC_8280XP=m
>   CONFIG_SC_DISPCC_8280XP=m
>   CONFIG_SA_GPUCC_8775P=m
>   CONFIG_SC_GCC_7180=y
> 
> ---
> base-commit: 20d857259d7d10cd0d5e8b60608455986167cfad
> change-id: 20231221-enable-sc8280xp-camcc-969b2cf2e4d7
> 
> Best regards,

Reviewed-by: Bryan O'Donoghue <bryan.odonoghue at linaro.org>


From sean at mess.org  Fri Dec 22 05:13:11 2023
From: sean at mess.org (Sean Young)
Date: Fri, 22 Dec 2023 13:13:11 +0000
Subject: [PATCH v2] pwm: bcm2835: Remove duplicate call to clk_rate_exclusive_put()
Message-ID: <20231222131312.174491-1-sean@mess.org>

devm_add_action_or_reset() already calls the action in the error case.

Reported-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Closes: https://lore.kernel.org/linux-pwm/fuku3b5ur6y4k4refd3vmeoenzjo6mwe3b3gtel34rhhhtvnsa at w4uktgbqsc3w/
Fixes: fcc760729359 ("pwm: bcm2835: Allow PWM driver to be used in atomic context")
Signed-off-by: Sean Young <sean at mess.org>
Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-bcm2835.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index 307c0bd5f885..283cf27f25ba 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -160,10 +160,8 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
 
 	ret = devm_add_action_or_reset(&pdev->dev, devm_clk_rate_exclusive_put,
 				       pc->clk);
-	if (ret) {
-		clk_rate_exclusive_put(pc->clk);
+	if (ret)
 		return ret;
-	}
 
 	pc->rate = clk_get_rate(pc->clk);
 	if (!pc->rate)
-- 
2.43.0



From lucasvp at gmail.com  Fri Dec 22 05:22:21 2023
From: lucasvp at gmail.com (Lucas Pereira)
Date: Fri, 22 Dec 2023 10:22:21 -0300
Subject: [PATCH net 0/1] Prevent DSA tags from breaking COE
In-Reply-To: <20231222123023.voxoxfcckxsz2vce@skbuf>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <0351C5C2-FEE2-4AED-84C8-9DCACCE4ED0A@aol.com> <20231222123023.voxoxfcckxsz2vce@skbuf>
Message-ID: <CAG7fG-bDdtTxWkv8690+LHE5DVMKUn_+pQGsFVHxjXYPrLnN_w@mail.gmail.com>

Dear community collaborators,

First of all, I would like to thank you for the prompt response and
the suggestions provided.

We conducted the tests as indicated, but unfortunately, the problem
persists. It seems to me that if it were a Checksum-related issue, the
behavior would be different, as the VPN and communication work
normally for several days before failing suddenly.

We have observed that the only effective ways to reestablish
communication, so far, are through a system reboot or by changing the
authentication cipher, such as switching from MD5 to SHA1.
Interestingly, when switching back to the MD5 cipher, the
communication fails to function again.

I am immensely grateful for the help received so far and would greatly
appreciate any further suggestions or recommendations that you might
offer to resolve this challenge.

Sincerely,
Lucas

________________________________
De: Vladimir Oltean <olteanv at gmail.com>
Enviado: sexta-feira, 22 de dezembro de 2023 09:30
Para: Household Cang <canghousehold at aol.com>
Cc: Romain Gantois <romain.gantois at bootlin.com>; Alexandre Torgue
<alexandre.torgue at foss.st.com>; Jose Abreu <joabreu at synopsys.com>;
David S. Miller <davem at davemloft.net>; Eric Dumazet
<edumazet at google.com>; Jakub Kicinski <kuba at kernel.org>; Paolo Abeni
<pabeni at redhat.com>; Maxime Coquelin <mcoquelin.stm32 at gmail.com>;
Miquel Raynal <miquel.raynal at bootlin.com>; Maxime Chevallier
<maxime.chevallier at bootlin.com>; Sylvain Girard
<sylvain.girard at se.com>; Pascal EBERHARD <pascal.eberhard at se.com>;
Richard Tresidder <rtresidd at electromag.com.au>; netdev at vger.kernel.org
<netdev at vger.kernel.org>; linux-stm32 at st-md-mailman.stormreply.com
<linux-stm32 at st-md-mailman.stormreply.com>;
linux-arm-kernel at lists.infradead.org
<linux-arm-kernel at lists.infradead.org>
Assunto: Re: [PATCH net 0/1] Prevent DSA tags from breaking COE

Hi Lucas,

On Thu, Dec 21, 2023 at 02:40:34AM -0500, Household Cang wrote:
> > On Dec 18, 2023, at 11:23 AM, Romain Gantois <romain.gantois at bootlin.com> wrote:
> >
> > This is a bugfix for an issue that was recently brought up in two
> > reports:
> >
> > https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495 at bootlin.com/
> > https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2 at electromag.com.au/
> >
> Add me in to be the 3rd report...
> RK3568 GMAC0 (eth1) to MT7531BE (CPU port)
> Current workaround for me is ethtool -K eth1 rx off tx off

Is "rx off" actually required, or just "tx off"?

> https://lore.kernel.org/netdev/m3clft2k7umjtny546ot3ayebattksibty3yyttpffvdixl65p at 7dpqsr5nisbk/T/#t
>
> Question on the patch to be built: how would I know if my setup could
> take advantage of the HW checksum offload? RK3658?s eth0 on stmmac is
> doing fine, and eth0 is not on a DSA switch. Does this mean eth1
> should be able to do hw checksum offload once the stmmac driver is
> fixed?

The MT7531BE switch requires transmitted packets to have an additional
header which indicates what switch port is targeted. So the packet
structure is not the same as what eth0 transmits.

Your GMAC datasheet should explain what packets it is able to offload
L4 checksumming for, quite plainly. Probably MAC + IP + TCP yes, but
MAC + MTK DSA + IP + TCP no.

The bug is that the network stack thinks that the GMAC is able to
offload TX checksums for these MTK DSA tagged packets, so it does not
calculate the checksum in software, leaving the task up to the hardware.
My guess is that the hardware doesn't recognize the packets as something
that is offloadable, so it doesn't calculate the checksum either, and
that's the story of how you end up with packets with bad checksums.

The patch to be built should analyze the packet before passing it to a
hardware offload engine which will do nothing. The driver still declares
the NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM features because it is able to
offload checksumming for _some_ packets, but it falls back to the
software checksum helper for the rest. This includes your MTK DSA tagged
packets. They can be checksummed in software even with the DSA tag added,
because that uses the more generic mechanism with skb->csum_start and
skb->csum_offset, which DSA is compatible with, just fine. The GMAC
driver, most likely because of the lack of hardware support, does not
look at skb->csum_start and skb->csum_offset (aka it does not declare
the NETIF_F_HW_CSUM feature), so it cannot offload checksumming for your
switch traffic unless that was specifically baked into the RTL.

More details in the "Switch tagging protocols" section of
Documentation/networking/dsa/dsa.rst.


From broonie at kernel.org  Fri Dec 22 05:30:00 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 13:30:00 +0000
Subject: (subset) [PATCH 0/6] spi: stm32: add support for stm32mp25
In-Reply-To: <20231218155721.359198-1-alain.volmat@foss.st.com>
References: <20231218155721.359198-1-alain.volmat@foss.st.com>
Message-ID: <170325180035.61341.901936375661515103.b4-ty@kernel.org>

On Mon, 18 Dec 2023 16:57:12 +0100, Alain Volmat wrote:
> This series adds support for spi bus found on the stm32mp25 and add
> all instances within device-trees.
> 
> Alain Volmat (4):
>   spi: stm32: use dma_get_slave_caps prior to configuring dma channel
>   arm64: dts: st: add all 8 spi nodes on stm32mp251
>   arm64: dts: st: add spi3/spi8 pins for stm32mp25
>   arm64: dts: st: add spi3 / spi8 properties on stm32mp257f-ev1
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/6] spi: stm32: use dma_get_slave_caps prior to configuring dma channel
      commit: 6f98f25247b7ef03fb89030a3af6c0eb08132104
[2/6] dt-bindings: spi: stm32: add st,stm32mp25-spi compatible
      commit: f034a151059a84cecaae68f5a72ee5d815e94625
[3/6] spi: stm32: add st,stm32mp25-spi compatible supporting STM32MP25 soc
      commit: f6cd66231aa58599526584ff4df1bdde8d86eac8

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From olteanv at gmail.com  Fri Dec 22 05:46:43 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Fri, 22 Dec 2023 15:46:43 +0200
Subject: [PATCH net 0/1] Prevent DSA tags from breaking COE
In-Reply-To: <CAG7fG-bDdtTxWkv8690+LHE5DVMKUn_+pQGsFVHxjXYPrLnN_w@mail.gmail.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <0351C5C2-FEE2-4AED-84C8-9DCACCE4ED0A@aol.com>
 <20231222123023.voxoxfcckxsz2vce@skbuf>
 <CAG7fG-bDdtTxWkv8690+LHE5DVMKUn_+pQGsFVHxjXYPrLnN_w@mail.gmail.com>
Message-ID: <20231222134643.undeg7ruu6ptqisq@skbuf>

On Fri, Dec 22, 2023 at 10:22:21AM -0300, Lucas Pereira wrote:
> Dear community collaborators,
> 
> First of all, I would like to thank you for the prompt response and
> the suggestions provided.
> 
> We conducted the tests as indicated, but unfortunately, the problem
> persists. It seems to me that if it were a Checksum-related issue, the
> behavior would be different, as the VPN and communication work
> normally for several days before failing suddenly.
> 
> We have observed that the only effective ways to reestablish
> communication, so far, are through a system reboot or by changing the
> authentication cipher, such as switching from MD5 to SHA1.
> Interestingly, when switching back to the MD5 cipher, the
> communication fails to function again.
> 
> I am immensely grateful for the help received so far and would greatly
> appreciate any further suggestions or recommendations that you might
> offer to resolve this challenge.
> 
> Sincerely,
> Lucas

Are you responding to the right thread? This is about on-board Ethernet
switch chips attached to Synopsys MAC hardware IPs.


From arnd at arndb.de  Fri Dec 22 06:21:49 2023
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 22 Dec 2023 14:21:49 +0000
Subject: [PATCH 08/10] ARM: mach-hpe: Rework support and directory structure
In-Reply-To: <20230515160234.289631-8-afd@ti.com>
References: <20230515160234.289631-1-afd@ti.com>
 <20230515160234.289631-8-afd@ti.com>
Message-ID: <8853b024-4f1f-4acf-ac52-6b20bbd2ba12@app.fastmail.com>

On Mon, May 15, 2023, at 16:02, Andrew Davis wrote:
> Having a platform need a mach-* directory should be seen as a negative,
> it means the platform needs special non-standard handling. ARM64 support
> does not allow mach-* directories at all. While we may not get to that
> given all the non-standard architectures we support, we should still try
> to get as close as we can and reduce the number of mach directories.
>
> The mach-hpe/ directory and files, provides just one "feature":
> having the kernel print the machine name if the DTB does not also contain
> a "model" string (which they always do). To reduce the number of mach-*
> directories let's do without that feature and remove this directory.
>
> Signed-off-by: Andrew Davis <afd at ti.com>
> ---
>  MAINTAINERS                |  1 -
>  arch/arm/Kconfig           |  2 --
>  arch/arm/Kconfig.platforms | 25 +++++++++++++++++++++++++
>  arch/arm/Makefile          |  1 -
>  arch/arm/mach-hpe/Kconfig  | 23 -----------------------
>  arch/arm/mach-hpe/Makefile |  1 -
>  arch/arm/mach-hpe/gxp.c    | 16 ----------------

I'm dropping this patch from the series:

> -/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P. */
> -
> -#include <linux/of_platform.h>
> -#include <asm/mach/arch.h>
> -
> -static const char * const gxp_board_dt_compat[] = {
> -	"hpe,gxp",
> -	NULL,
> -};
> -
> -DT_MACHINE_START(GXP_DT, "HPE GXP")
> -	.dt_compat	= gxp_board_dt_compat,
> -	.l2c_aux_val = 0,
> -	.l2c_aux_mask = ~0,
> -MACHINE_END

As Russell had previously pointed out, removing the l2c settings
from a machine file breaks these machines if there is an actual
l2c node, which for gxp there is, same for most other Cortex-A9
and A5 based platforms.

The Uniphier machine that you also modify here is an exception
because they use a custom L2 cache implementation.

      Arnd


From fancer.lancer at gmail.com  Fri Dec 22 06:44:58 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Fri, 22 Dec 2023 17:44:58 +0300
Subject: [PATCH net-next v1 0/4] net: stmmac: Enable Per DMA Channel
 interrupt
In-Reply-To: <20231222054451.2683242-1-leong.ching.swee@intel.com>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
Message-ID: <kmmjm4sf5geudch54nmehl3ibkpwvlgbhpf7y6quhqy3gnqg32@gcvwlvzec6pn>

Hi Leong

On Fri, Dec 22, 2023 at 01:44:47PM +0800, Leong Ching Swee wrote:
> From: Swee Leong Ching <leong.ching.swee at intel.com>
> 
> Hi,
> Add Per DMA Channel interrupt feature for DWXGMAC IP.
>  
> Patchset (link below) contains per DMA channel interrupt, But it was 
> achieved.
> https://lore.kernel.org/lkml/20230821203328.GA2197059-
> robh at kernel.org/t/#m849b529a642e1bff89c05a07efc25d6a94c8bfb4
>  
> Some of the changes in this patchset are based on reviewer comment on 
> patchset mentioned beforehand.

Thanks for resubmitting the patches. At some point in the past they
saved me some time in fixing the DW XGMAC on my platform.

-Serge(y)

> 
> Swee Leong Ching (4):
>   dt-bindings: net: snps,dwmac: per channel irq
>   net: stmmac: Make MSI interrupt routine generic
>   net: stmmac: Add support for TX/RX channel interrupt
>   net: stmmac: Use interrupt mode INTM=1 for per channel irq
> 
>  .../devicetree/bindings/net/snps,dwmac.yaml   | 24 ++++++++++----
>  .../net/ethernet/stmicro/stmmac/dwmac-intel.c |  4 +--
>  .../net/ethernet/stmicro/stmmac/dwmac4_dma.c  |  2 +-
>  .../net/ethernet/stmicro/stmmac/dwxgmac2.h    |  3 ++
>  .../ethernet/stmicro/stmmac/dwxgmac2_dma.c    | 32 +++++++++++--------
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c | 29 +++++++++--------
>  .../ethernet/stmicro/stmmac/stmmac_platform.c | 24 ++++++++++++++
>  include/linux/stmmac.h                        |  4 +--
>  8 files changed, 84 insertions(+), 38 deletions(-)
> 
> -- 
> 2.34.1
> 
> 


From olteanv at gmail.com  Fri Dec 22 06:51:00 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Fri, 22 Dec 2023 16:51:00 +0200
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
Message-ID: <20231222145100.sfcuux7ayxtxgogo@skbuf>

On Wed, Dec 20, 2023 at 12:49:30PM +0530, Jagan Teki wrote:
> [ 1255.021656] Modules linked in: mdio_netlink(O) bnep tag_sja1105 sja1105 pcs_xpcs brcmfmac brcmutil imx_sdma coda_vpu v4l2_jpeg imx_vdoa evbug
> [ 1255.034578] CPU: 0 PID: 374 Comm: ip Tainted: G           O       6.1.58 #1

Can you please reproduce the issue with no out-of-tree modules used
(here mdio_netlink)?


From fancer.lancer at gmail.com  Fri Dec 22 06:51:04 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Fri, 22 Dec 2023 17:51:04 +0300
Subject: [PATCH net-next v1 1/4] dt-bindings: net: snps,dwmac: per
 channel irq
In-Reply-To: <20231222054451.2683242-2-leong.ching.swee@intel.com>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
 <20231222054451.2683242-2-leong.ching.swee@intel.com>
Message-ID: <tly7rej6uz7r36j3nm2yk6mhrbdxkvwyphj3oosar5xd3ucpey@hv4dro7emw3h>

On Fri, Dec 22, 2023 at 01:44:48PM +0800, Leong Ching Swee wrote:
> From: Swee Leong Ching <leong.ching.swee at intel.com>
> 
> Add dt-bindings for per channel irq.
> 
> Signed-off-by: Rohan G Thomas <rohan.g.thomas at intel.com>
> Signed-off-by: Swee Leong Ching <leong.ching.swee at intel.com>
> ---
>  .../devicetree/bindings/net/snps,dwmac.yaml   | 24 +++++++++++++------
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 5c2769dc689a..e72dded824f4 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -103,17 +103,27 @@ properties:
>  
>    interrupts:
>      minItems: 1
> -    items:
> -      - description: Combined signal for various interrupt events
> -      - description: The interrupt to manage the remote wake-up packet detection
> -      - description: The interrupt that occurs when Rx exits the LPI state
> +    maxItems: 19
>  
>    interrupt-names:
>      minItems: 1
> +    maxItems: 19
>      items:
> -      - const: macirq
> -      - enum: [eth_wake_irq, eth_lpi]
> -      - const: eth_lpi
> +      oneOf:
> +        - description: Combined signal for various interrupt events
> +          const: macirq
> +        - description: The interrupt to manage the remote wake-up packet detection
> +          const: eth_wake_irq
> +        - description: The interrupt that occurs when Rx exits the LPI state
> +          const: eth_lpi
> +        - description: DMA Tx per-channel interrupt
> +          pattern: '^dma_tx[0-7]?$'
> +        - description: DMA Rx per-channel interrupt
> +          pattern: '^dma_rx[0-7]?$'
> +

> +    allOf:
> +      - contains:
> +          const: macirq

As Rob correctly noted it's also better to make sure that 'macirq' is
placed first in the array. So instead of the constraint above I guess
the next one would make sure both the array has 'macirq' name and it's
the first item:

allOf:
  - maxItems: 34
    items:
      - const: macirq

-Serge(y)

>  
>    clocks:
>      minItems: 1
> -- 
> 2.34.1
> 
> 


From conor at kernel.org  Fri Dec 22 07:07:14 2023
From: conor at kernel.org (Conor Dooley)
Date: Fri, 22 Dec 2023 15:07:14 +0000
Subject: [PATCH v3 2/9] dt-bindings: mailbox: Add mboxes property for
 CMDQ secure driver
In-Reply-To: <20231222045228.27826-3-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
 <20231222045228.27826-3-jason-jh.lin@mediatek.com>
Message-ID: <20231222-unpicked-jaundice-837baa3092ed@spud>

On Fri, Dec 22, 2023 at 12:52:21PM +0800, Jason-JH.Lin wrote:
> Add mboxes to define a GCE loopping thread as a secure irq handler.

> This property is only required if CMDQ secure driver is supported.

What do drivers have to do with this? Either the mailbox channel exists
or it does not. That said, I am not sure why this should be in DT in the
first place, can't the driver for the mailbox controller reserve a
channel for its own use?

Thanks,
Conor.

> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  .../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml      | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
> index e4da0a58c943..0c17e1be99c2 100644
> --- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
> @@ -56,6 +56,9 @@ properties:
>        include/dt-bindings/gce/<chip>-gce.h of each chips.
>      $ref: /schemas/types.yaml#/definitions/uint32-array
>  
> +  mboxes:
> +    maxItems: 1
> +
>  required:
>    - compatible
>    - "#mbox-cells"
> -- 
> 2.18.0
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/dcfa7802/attachment.sig>

From cristian.marussi at arm.com  Fri Dec 22 07:30:11 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 22 Dec 2023 15:30:11 +0000
Subject: [PATCH 1/7] firmware: arm_scmi: introduce helper get_max_msg_size
In-Reply-To: <20231215-pinctrl-scmi-v1-1-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-1-0fe35e4611f7@nxp.com>
Message-ID: <ZYWrgzujGh84CT-5@pluto>

On Fri, Dec 15, 2023 at 07:56:29PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> When Agent sending data to SCMI server, the Agent driver could check
> the size to avoid protocol buffer overflow. So introduce the helper
> get_max_msg_size.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/firmware/arm_scmi/driver.c    | 15 +++++++++++++++
>  drivers/firmware/arm_scmi/protocols.h |  1 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index a9f70e6e58ac..b4f8f190351b 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -1481,6 +1481,20 @@ static int scmi_common_extended_name_get(const struct scmi_protocol_handle *ph,
>  	return ret;
>  }
>  
> +/**
> + * scmi_common_get_max_msg_size  - Get maximum message size
> + * @ph: A protocol handle reference.
> + *
> + * Return: Maximum message size for the current protocol.
> + */
> +static int scmi_common_get_max_msg_size(const struct scmi_protocol_handle *ph)
> +{
> +	const struct scmi_protocol_instance *pi = ph_to_pi(ph);
> +	struct scmi_info *info = handle_to_scmi_info(pi->handle);
> +
> +	return info->desc->max_msg_size;
> +}
> +
>  /**
>   * struct scmi_iterator  - Iterator descriptor
>   * @msg: A reference to the message TX buffer; filled by @prepare_message with
> @@ -1756,6 +1770,7 @@ static void scmi_common_fastchannel_db_ring(struct scmi_fc_db_info *db)
>  
>  static const struct scmi_proto_helpers_ops helpers_ops = {
>  	.extended_name_get = scmi_common_extended_name_get,
> +	.get_max_msg_size = scmi_common_get_max_msg_size,
>  	.iter_response_init = scmi_iterator_init,
>  	.iter_response_run = scmi_iterator_run,
>  	.fastchannel_init = scmi_common_fastchannel_init,
> diff --git a/drivers/firmware/arm_scmi/protocols.h b/drivers/firmware/arm_scmi/protocols.h
> index e683c26f24eb..08de8dc064c1 100644
> --- a/drivers/firmware/arm_scmi/protocols.h
> +++ b/drivers/firmware/arm_scmi/protocols.h
> @@ -270,6 +270,7 @@ struct scmi_proto_helpers_ops {
>  				 void __iomem **p_addr,
>  				 struct scmi_fc_db_info **p_db);
>  	void (*fastchannel_db_ring)(struct scmi_fc_db_info *db);
> +	int (*get_max_msg_size)(const struct scmi_protocol_handle *ph);
>  };

This looks good to me, but please add a comment for this new helper in
the comment block above.

Other than that:

Reviewed-by: Cristian Marussi <cristian.marussi at arm.com>

Thanks,
Cristian



From conor at kernel.org  Fri Dec 22 07:30:55 2023
From: conor at kernel.org (Conor Dooley)
Date: Fri, 22 Dec 2023 15:30:55 +0000
Subject: [RFC PATCH 1/3] dt-bindings: fpga: Add support for user-key
 encrypted bitstream loading
In-Reply-To: <a90d980e-71a1-4b90-b1cb-66ac45d79031@linaro.org>
References: <20231122054404.3764288-1-nava.kishore.manne@amd.com>
 <20231122054404.3764288-2-nava.kishore.manne@amd.com>
 <20231122-exert-gleeful-e4476851c489@spud>
 <DM6PR12MB3993F0EC4930E68C54299B36CDB8A@DM6PR12MB3993.namprd12.prod.outlook.com>
 <20231124-tweezers-slug-0349a2188802@spud>
 <a90d980e-71a1-4b90-b1cb-66ac45d79031@linaro.org>
Message-ID: <20231222-unisexual-construct-573e79a488c9@spud>

On Fri, Nov 24, 2023 at 04:46:06PM +0100, Krzysztof Kozlowski wrote:
> On 24/11/2023 13:48, Conor Dooley wrote:
> > On Fri, Nov 24, 2023 at 06:35:19AM +0000, Manne, Nava kishore wrote:
> >> Hi Conor,
> >>
> >> 	Thanks for providing the review comments.
> >> Please find my response inline.
> >>
> >>> -----Original Message-----
> >>> From: Conor Dooley <conor at kernel.org>
> >>> Sent: Wednesday, November 22, 2023 10:21 PM
> >>> To: Manne, Nava kishore <nava.kishore.manne at amd.com>
> >>> Cc: mdf at kernel.org; hao.wu at intel.com; yilun.xu at intel.com;
> >>> trix at redhat.com; robh+dt at kernel.org; krzysztof.kozlowski+dt at linaro.org;
> >>> conor+dt at kernel.org; Simek, Michal <michal.simek at amd.com>;
> >>> mathieu.poirier at linaro.org; Levinsky, Ben <ben.levinsky at amd.com>;
> >>> Potthuri, Sai Krishna <sai.krishna.potthuri at amd.com>; Shah, Tanmay
> >>> <tanmay.shah at amd.com>; dhaval.r.shah at amd.com; arnd at arndb.de;
> >>> Datta, Shubhrajyoti <shubhrajyoti.datta at amd.com>; linux-
> >>> fpga at vger.kernel.org; devicetree at vger.kernel.org; linux-
> >>> kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> >>> Subject: Re: [RFC PATCH 1/3] dt-bindings: fpga: Add support for user-key
> >>> encrypted bitstream loading
> >>>
> >>> On Wed, Nov 22, 2023 at 11:14:02AM +0530, Nava kishore Manne wrote:
> >>>> Adds ?encrypted-key-name? property to support user-key encrypted
> >>>> bitstream loading use case.
> >>>>
> >>>> Signed-off-by: Nava kishore Manne <nava.kishore.manne at amd.com>
> >>>> ---
> >>>>  .../devicetree/bindings/fpga/fpga-region.txt  | 32
> >>>> +++++++++++++++++++
> >>>
> >>> Is there a reason that this has not yet been converted to yaml?
> >>>
> >> I am not sure about the complication involved here why it's not converted to yaml format.
> >> Due to time constraints, I couldn?t spend much time so I have used this existing legacy format
> >> to add my changes.
> >>
> >>>>  1 file changed, 32 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt
> >>>> b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> >>>> index 528df8a0e6d8..309334558b3f 100644
> >>>> --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
> >>>> +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> >>>> @@ -177,6 +177,9 @@ Optional properties:
> >>>>  	it indicates that the FPGA has already been programmed with this
> >>> image.
> >>>>  	If this property is in an overlay targeting an FPGA region, it is a
> >>>>  	request to program the FPGA with that image.
> >>>> +- encrypted-key-name : should contain the name of an encrypted key file
> >>> located
> >>>> +	on the firmware search path. It will be used to decrypt the FPGA
> >>> image
> >>>> +	file with user-key.
> >>>
> >>> I might be misreading things, but your driver code seems to assume that this
> >>> is an aes key. Nothing here seems to document that this is supposed to be a
> >>> key of a particular type.
> >>>
> >>
> >> Yes, these changes are intended to add the support for Aes user-key encrypted bitstream loading use case.
> >> Will fix it in v2, something like below.
> >> aes-key-file-name : Should contain the AES key file name on the firmware search path.
> >> 		      The key file contains the AES key and it will be used to decrypt the FPGA image.
> > 
> > Then when someone comes along looking for a different type of encryption
> > we will end up with national-pride-foo-file-name etc. I think I'd rather
> > have a second property that notes what type of cipher is being used and
> > if that property is not present default to AES.
> 
> I wonder why does it need to be in DT in the first place? Why it cannot
> be appended to the FPGA binary image itself? Which also points to
> dubious security aspect of this approach... Shipping FPGA encrypted
> image with its decryption key sounds like marvelous idea.
> 
> Even if this is suitable, why not using more arguments of firmware-name?
> This would scale even for multiple FPGA firmwares with different keys
> (although such need seems unlikely).

In case it is not clear (given the month's delay here), this question is
for the submitter of the series to answer, not me.

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/4834b805/attachment.sig>

From knaerzche at gmail.com  Fri Dec 22 07:37:37 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 16:37:37 +0100
Subject: [PATCH v2 1/3] ARM: dts: rockchip: Add psci for rk3036
In-Reply-To: <74e497f5-0361-47f7-a410-4b20d3526d52@rock-chips.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
 <20231218105523.2478315-2-andyshrk@163.com>
 <da10e2fc-3179-4bd5-88ed-b4d5f64a7191@gmail.com>
 <28216be5-810f-40d6-850b-a0fc590ffa3c@rock-chips.com>
 <a82481ca-b578-49a4-b0d0-974b6ee65c98@gmail.com>
 <74e497f5-0361-47f7-a410-4b20d3526d52@rock-chips.com>
Message-ID: <18c16355-9140-45be-bd16-96fad8b184a4@gmail.com>

Hi Andy,

Am 22.12.23 um 11:37 schrieb Andy Yan:
> Hi Alex,
>
> On 12/21/23 23:58, Alex Bee wrote:
>> Hi Andy,
>>
>> Am 21.12.23 um 02:07 schrieb Andy Yan:
>>> Hi Alex:
>>>
>>> On 12/20/23 19:16, Alex Bee wrote:
>>>> Hi Andy,
>>>> Am 18.12.23 um 11:55 schrieb Andy Yan:
>>>>> From: Andy Yan <andy.yan at rock-chips.com>
>>>>>
>>>>> The system will hang at bringup secondary CPUs
>>>>> without psci node.
>>>>>
>>>>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>>>>>
>>>>> ---
>>>>>
>>>>> (no changes since v1)
>>>>>
>>>>> ? arch/arm/boot/dts/rockchip/rk3036.dtsi | 5 +++++
>>>>> ? 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi 
>>>>> b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>>>> index 78686fc72ce6..5344803442a1 100644
>>>>> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>>>> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>>>> @@ -67,6 +67,11 @@ display-subsystem {
>>>>> ????????? ports = <&vop_out>;
>>>>> ????? };
>>>>> +??? psci {
>>>>> +??????? compatible = "arm,psci-1.0";
>>>>> +??????? method = "smc";
>>>>> +??? };
>>>>> +
>>>> I don't think that's an good idea. 
>>>
>>> Why?
>> It's only what I've been told before: We shoudn't add properties which
>> depend on non-upstream software (if an upstream alternative exists). 
>> Also
>
>> I'm not sure what happens if somebody doesn't?use downstream bootloader
>> and PSCI can't be found: Would the board still be able to boot?
>
> The psci is released herel[0].
> And also, there are only two rk3036 based boards in mainline:
> rk3036-evb,rk3036-keylin, both of them from rockchip.
> And the mainline support of these boards broken from linux 5.7(2020, 
> see PATCH 3),
> no one report this broken until I try to run this board now.
> So maybe there is no such somebody will run into this situation.
>
>
> [0]https://github.com/rockchip-linux/rkbin/tree/master/bin/rk30
>
Yeah sure, there are binary release for downstream optee implementations,
but the won't work with upstream u-boot, since they are using a calling
convention different from upstream optee os. I tried to add support for
those, but it was rejected [0].

Upstream bootflow doesn't implement/need PSCI as it uses a SMP bringup
method which is done in kernel only (see enable-method in cpu section). I
guess that it doesn't work for you is most likely because the downstream
tee os makes the cpu registers the upstream enable-method uses only
accessible in a higher exception level.

I can undust my RK3036 evb board during christmas holidays and check whats
broken for RK3036 in u-boot. Everything was working fine (including SMP
bringup w/o PSCI and upstream u-boot) when I was adding VPU support in 5.14
[1]. I likely booted from TF-card rather than eMMC.

[0] 
https://patchwork.ozlabs.org/project/uboot/patch/20230718145715.1280201-6-knaerzche at gmail.com/
[1] 
https://patchwork.kernel.org/project/linux-rockchip/patch/20210527154455.358869-11-knaerzche at gmail.com/

Nice holidays!

Alex

>>>
>>>> You most likely need that because you have downstream bootloader 
>>>> installed on this board. PSCI implementation takes place in TEE-OS 
>>>> for Rockchips ARM SoCs. There is no support for RK3036 in upstream 
>>>> op-tee OS. It's pretty much the same for RK3128 and RK3288.
>>>> If you use upstream u-boot it should be good as-is.
>>>
>>> Unfortunately, upstream u-boot also cannot boot up on this board.
>>> At present, I haven't had time to debug what is going on.
>>>
>>> Another reason I want to use downstream u-boot it is: I try run
>>> this board with mainline just because i want to test some community
>>> patches about inno-hdmi driver, as you said "the inno-hdmi driver 
>>> currently gets a lot of attention"[0]
>>>
>> Thanks for helping testing this.
>>
>> Alex
>>
>>> With a downstream u-boot I can easy switch between upstream kernel 
>>> and downstream kernel(no need to replace other components)
>>> if I found some function is not work as expected.
>>>
>>>
>>> [0]https://patchwork.kernel.org/project/linux-rockchip/cover/20231219170100.188800-1-knaerzche at gmail.com/ 
>>>
>>>>
>>>> Alex
>>>>> ????? timer {
>>>>> ????????? compatible = "arm,armv7-timer";
>>>>> ????????? arm,cpu-registers-not-fw-configured;
>>>>
>>>>
>>>> _______________________________________________
>>>> Linux-rockchip mailing list
>>>> Linux-rockchip at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip


From cristian.marussi at arm.com  Fri Dec 22 07:40:32 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 22 Dec 2023 15:40:32 +0000
Subject: [PATCH 3/7] firmware: arm_scmi: bus: iterate the id_table
In-Reply-To: <20231215-pinctrl-scmi-v1-3-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-3-0fe35e4611f7@nxp.com>
Message-ID: <ZYWt8JY1uOrER7MB@pluto>

On Fri, Dec 15, 2023 at 07:56:31PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> There maybe more entries in driver->id_table, just like platform
> driver of_match_table. So iterate the id_table, not only use the 1st
> entry.
> 

I understand the need, but you dont consider the unbind/unload part.

Moreover since I needed a similar mechanism for testing (multiple
protocols in a single driver), I posted yesterday a patch that does this
same thing that since I was using since ages but never posted (and it
takes care of unload/unbind too.).

https://lore.kernel.org/all/20231221151129.325749-1-cristian.marussi at arm.com/

Please drop this patch and use the above (that soon should be in -next)

Thanks,
Cristian


From cristian.marussi at arm.com  Fri Dec 22 07:58:16 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 22 Dec 2023 15:58:16 +0000
Subject: [PATCH 5/7] firmware: arm_scmi: Add SCMI v3.2 pincontrol
 protocol basic support
In-Reply-To: <20231215-pinctrl-scmi-v1-5-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-5-0fe35e4611f7@nxp.com>
Message-ID: <ZYWyGKEZi5YLYeQu@pluto>

On Fri, Dec 15, 2023 at 07:56:33PM +0800, Peng Fan (OSS) wrote:
> From: Oleksii Moisieiev <Oleksii_Moisieiev at epam.com>
> 
> Add basic implementation of the SCMI v3.2 pincontrol protocol.
> 

Hi

> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev at epam.com>
> Co-developed-by: Peng Fan <peng.fan at nxp.com>
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  MAINTAINERS                           |   6 +
>  drivers/firmware/arm_scmi/Makefile    |   1 +
>  drivers/firmware/arm_scmi/driver.c    |   2 +
>  drivers/firmware/arm_scmi/pinctrl.c   | 927 ++++++++++++++++++++++++++++++++++
>  drivers/firmware/arm_scmi/protocols.h |   1 +
>  include/linux/scmi_protocol.h         |  46 ++
>  6 files changed, 983 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b589218605b4..8d971adeee22 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21180,6 +21180,12 @@ F:	include/linux/sc[mp]i_protocol.h
>  F:	include/trace/events/scmi.h
>  F:	include/uapi/linux/virtio_scmi.h
>  
> +SYSTEM CONTROL MANAGEMENT INTERFACE (SCMI) PINCTRL DRIVER
> +M:	Oleksii Moisieiev <oleksii_moisieiev at epam.com>
> +L:	linux-arm-kernel at lists.infradead.org
> +S:	Maintained
> +F:	drivers/firmware/arm_scmi/pinctrl.c
> +
>  SYSTEM RESET/SHUTDOWN DRIVERS
>  M:	Sebastian Reichel <sre at kernel.org>
>  L:	linux-pm at vger.kernel.org
> diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile
> index a7bc4796519c..8e3874ff1544 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -11,6 +11,7 @@ scmi-transport-$(CONFIG_ARM_SCMI_HAVE_MSG) += msg.o
>  scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o
>  scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o
>  scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o system.o voltage.o powercap.o
> +scmi-protocols-y += pinctrl.o
>  scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y)
>  
>  obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 3174da57d832..1cf9f5d4f7bd 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -3057,6 +3057,7 @@ static int __init scmi_driver_init(void)
>  	scmi_voltage_register();
>  	scmi_system_register();
>  	scmi_powercap_register();
> +	scmi_pinctrl_register();
>  
>  	return platform_driver_register(&scmi_driver);
>  }
> @@ -3074,6 +3075,7 @@ static void __exit scmi_driver_exit(void)
>  	scmi_voltage_unregister();
>  	scmi_system_unregister();
>  	scmi_powercap_unregister();
> +	scmi_pinctrl_unregister();
>  
>  	scmi_transports_exit();
>  
> diff --git a/drivers/firmware/arm_scmi/pinctrl.c b/drivers/firmware/arm_scmi/pinctrl.c
> new file mode 100644
> index 000000000000..a25c8edcedd2
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/pinctrl.c
> @@ -0,0 +1,927 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * System Control and Management Interface (SCMI) Pinctrl Protocol
> + *
> + * Copyright (C) 2023 EPAM
> + */
> +
> +#include <linux/module.h>
> +#include <linux/pinctrl/pinconf-generic.h>
> +#include <linux/scmi_protocol.h>
> +#include <linux/slab.h>
> +
> +#include "common.h"
> +#include "protocols.h"
> +
> +/* Updated only after ALL the mandatory features for that version are merged */
> +#define SCMI_PROTOCOL_SUPPORTED_VERSION                0x40000
> +
> +#define REG_TYPE_BITS GENMASK(9, 8)
> +#define REG_CONFIG GENMASK(7, 0)
> +
> +#define GET_GROUPS_NR(x)	le32_get_bits((x), GENMASK(31, 16))
> +#define GET_PINS_NR(x)		le32_get_bits((x), GENMASK(15, 0))
> +#define GET_FUNCTIONS_NR(x)	le32_get_bits((x), GENMASK(15, 0))
> +
> +#define EXT_NAME_FLAG(x)	le32_get_bits((x), BIT(31))
> +#define NUM_ELEMS(x)		le32_get_bits((x), GENMASK(15, 0))
> +
> +#define REMAINING(x)		le32_get_bits((x), GENMASK(31, 16))
> +#define RETURNED(x)		le32_get_bits((x), GENMASK(11, 0))
> +
> +enum scmi_pinctrl_protocol_cmd {
> +	PINCTRL_ATTRIBUTES = 0x3,
> +	PINCTRL_LIST_ASSOCIATIONS = 0x4,
> +	PINCTRL_CONFIG_GET = 0x5,
> +	PINCTRL_CONFIG_SET = 0x6,
> +	PINCTRL_FUNCTION_SELECT = 0x7,
> +	PINCTRL_REQUEST = 0x8,
> +	PINCTRL_RELEASE = 0x9,
> +	PINCTRL_NAME_GET = 0xa,
> +	PINCTRL_SET_PERMISSIONS = 0xb
> +};
> +
> +struct scmi_msg_conf_set {
> +	__le32 identifier;
> +	__le32 attributes;
> +	__le32 configs[];
> +};
> +
> +struct scmi_msg_conf_get {
> +	__le32 identifier;
> +	__le32 attributes;
> +};
> +
> +struct scmi_resp_conf_get {
> +	__le32 num_configs;
> +	__le32 configs[];
> +};
> +
> +struct scmi_msg_pinctrl_protocol_attributes {
> +	__le32 attributes_low;
> +	__le32 attributes_high;
> +};
> +
> +struct scmi_msg_pinctrl_attributes {
> +	__le32 identifier;
> +	__le32 flags;
> +};
> +
> +struct scmi_resp_pinctrl_attributes {
> +	__le32 attributes;
> +	u8 name[SCMI_SHORT_NAME_MAX_SIZE];
> +};
> +
> +struct scmi_msg_pinctrl_list_assoc {
> +	__le32 identifier;
> +	__le32 flags;
> +	__le32 index;
> +};
> +
> +struct scmi_resp_pinctrl_list_assoc {
> +	__le32 flags;
> +	__le16 array[];
> +};
> +
> +struct scmi_msg_func_set {
> +	__le32 identifier;
> +	__le32 function_id;
> +	__le32 flags;
> +};
> +
> +struct scmi_msg_request {
> +	__le32 identifier;
> +	__le32 flags;
> +};
> +
> +struct scmi_group_info {
> +	char name[SCMI_MAX_STR_SIZE];
> +	bool present;
> +	unsigned int *group_pins;
> +	unsigned int nr_pins;
> +};
> +
> +struct scmi_function_info {
> +	char name[SCMI_MAX_STR_SIZE];
> +	bool present;
> +	unsigned int *groups;
> +	unsigned int nr_groups;
> +};
> +
> +struct scmi_pin_info {
> +	char name[SCMI_MAX_STR_SIZE];
> +	bool present;
> +};
> +
> +struct scmi_pinctrl_info {
> +	u32 version;
> +	int nr_groups;
> +	int nr_functions;
> +	int nr_pins;
> +	struct scmi_group_info *groups;
> +	struct scmi_function_info *functions;
> +	struct scmi_pin_info *pins;
> +};
> +
> +static int scmi_pinctrl_attributes_get(const struct scmi_protocol_handle *ph,
> +				       struct scmi_pinctrl_info *pi)
> +{
> +	int ret;
> +	struct scmi_xfer *t;
> +	struct scmi_msg_pinctrl_protocol_attributes *attr;
> +
> +	ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0, sizeof(*attr), &t);
> +	if (ret)
> +		return ret;
> +
> +	attr = t->rx.buf;
> +
> +	ret = ph->xops->do_xfer(ph, t);
> +	if (!ret) {
> +		pi->nr_functions = GET_FUNCTIONS_NR(attr->attributes_high);
> +		pi->nr_groups = GET_GROUPS_NR(attr->attributes_low);
> +		pi->nr_pins = GET_PINS_NR(attr->attributes_low);
> +	}
> +
> +	ph->xops->xfer_put(ph, t);
> +	return ret;
> +}
> +
> +static int scmi_pinctrl_count_get(const struct scmi_protocol_handle *ph,
> +				  enum scmi_pinctrl_selector_type type)
> +{
> +	struct scmi_pinctrl_info *pi = ph->get_priv(ph);
> +
> +	switch (type) {
> +	case PIN_TYPE:
> +		return pi->nr_pins;
> +	case GROUP_TYPE:
> +		return pi->nr_groups;
> +	case FUNCTION_TYPE:
> +		return pi->nr_functions;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static int scmi_pinctrl_validate_id(const struct scmi_protocol_handle *ph,
> +				    u32 identifier,
> +				    enum scmi_pinctrl_selector_type type)
> +{
> +	int value;
> +
> +	value = scmi_pinctrl_count_get(ph, type);
> +	if (value < 0)
> +		return value;
> +
> +	if (identifier >= value)
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +static int scmi_pinctrl_attributes(const struct scmi_protocol_handle *ph,
> +				   enum scmi_pinctrl_selector_type type,
> +				   u32 selector, char *name,
> +				   unsigned int *n_elems)
> +{
> +	int ret;
> +	struct scmi_xfer *t;
> +	struct scmi_msg_pinctrl_attributes *tx;
> +	struct scmi_resp_pinctrl_attributes *rx;
> +
> +	if (!name)
> +		return -EINVAL;
> +
> +	ret = scmi_pinctrl_validate_id(ph, selector, type);
> +	if (ret)
> +		return ret;
> +
> +	ret = ph->xops->xfer_get_init(ph, PINCTRL_ATTRIBUTES, sizeof(*tx), sizeof(*rx), &t);
> +	if (ret)
> +		return ret;
> +
> +	tx = t->tx.buf;
> +	rx = t->rx.buf;
> +	tx->identifier = cpu_to_le32(selector);
> +	tx->flags = cpu_to_le32(type);
> +
> +	ret = ph->xops->do_xfer(ph, t);
> +	if (!ret) {
> +		if (n_elems)
> +			*n_elems = NUM_ELEMS(rx->attributes);
> +
> +		strscpy(name, rx->name, SCMI_SHORT_NAME_MAX_SIZE);
> +	}
> +
> +	ph->xops->xfer_put(ph, t);
> +
> +	/*
> +	 * If supported overwrite short name with the extended one;
> +	 * on error just carry on and use already provided short name.
> +	 */
> +	if (!ret && EXT_NAME_FLAG(rx->attributes))
> +		ph->hops->extended_name_get(ph, PINCTRL_NAME_GET, selector,
> +					    (u32 *)&type, name,
> +					    SCMI_MAX_STR_SIZE);
> +	return ret;
> +}
> +
> +struct scmi_pinctrl_ipriv {
> +	u32 selector;
> +	enum scmi_pinctrl_selector_type type;
> +	unsigned int *array;
> +};
> +
> +static void iter_pinctrl_assoc_prepare_message(void *message,
> +					       unsigned int desc_index,
> +					       const void *priv)
> +{
> +	struct scmi_msg_pinctrl_list_assoc *msg = message;
> +	const struct scmi_pinctrl_ipriv *p = priv;
> +
> +	msg->identifier = cpu_to_le32(p->selector);
> +	msg->flags = cpu_to_le32(p->type);
> +	/* Set the number of OPPs to be skipped/already read */
> +	msg->index = cpu_to_le32(desc_index);
> +}
> +
> +static int iter_pinctrl_assoc_update_state(struct scmi_iterator_state *st,
> +					   const void *response, void *priv)
> +{
> +	const struct scmi_resp_pinctrl_list_assoc *r = response;
> +
> +	st->num_returned = RETURNED(r->flags);
> +	st->num_remaining = REMAINING(r->flags);
> +
> +	return 0;
> +}
> +
> +static int
> +iter_pinctrl_assoc_process_response(const struct scmi_protocol_handle *ph,
> +				    const void *response,
> +				    struct scmi_iterator_state *st, void *priv)
> +{
> +	const struct scmi_resp_pinctrl_list_assoc *r = response;
> +	struct scmi_pinctrl_ipriv *p = priv;
> +
> +	p->array[st->desc_index + st->loop_idx] =
> +		le16_to_cpu(r->array[st->loop_idx]);
> +
> +	return 0;
> +}
> +
> +static int scmi_pinctrl_list_associations(const struct scmi_protocol_handle *ph,
> +					  u32 selector,
> +					  enum scmi_pinctrl_selector_type type,
> +					  u16 size, unsigned int *array)
> +{
> +	int ret;
> +	void *iter;
> +	struct scmi_iterator_ops ops = {
> +		.prepare_message = iter_pinctrl_assoc_prepare_message,
> +		.update_state = iter_pinctrl_assoc_update_state,
> +		.process_response = iter_pinctrl_assoc_process_response,
> +	};
> +	struct scmi_pinctrl_ipriv ipriv = {
> +		.selector = selector,
> +		.type = type,
> +		.array = array,
> +	};
> +
> +	if (!array || !size || type == PIN_TYPE)
> +		return -EINVAL;
> +
> +	ret = scmi_pinctrl_validate_id(ph, selector, type);
> +	if (ret)
> +		return ret;
> +
> +	iter = ph->hops->iter_response_init(ph, &ops, size,
> +					    PINCTRL_LIST_ASSOCIATIONS,
> +					    sizeof(struct scmi_msg_pinctrl_list_assoc),
> +					    &ipriv);
> +
> +	if (IS_ERR(iter))
> +		return PTR_ERR(iter);
> +
> +	return ph->hops->iter_response_run(iter);
> +}
> +
> +struct scmi_conf_get_ipriv {
> +	u32 selector;
> +	enum scmi_pinctrl_selector_type type;
> +	u8 all;
> +	u8 *config_types;
> +	unsigned long *config_values;
> +};
> +
> +static void iter_pinctrl_conf_get_prepare_message(void *message,
> +						  unsigned int desc_index,
> +						  const void *priv)
> +{
> +	struct scmi_msg_conf_get *msg = message;
> +	const struct scmi_conf_get_ipriv *p = priv;
> +	u32 attributes;
> +
> +	msg->identifier = cpu_to_le32(p->selector);
        ^^^^^

> +	attributes = FIELD_PREP(BIT(18), p->all) |
> +		     FIELD_PREP(GENMASK(17, 16), p->type);
> +
> +	if (p->all)
> +		attributes |= FIELD_PREP(GENMASK(15, 8), desc_index);
> +	else
> +		attributes |= FIELD_PREP(GENMASK(7, 0), p->config_types[0]);
> +
> +	msg->attributes = cpu_to_le32(attributes);
> +	msg->identifier = cpu_to_le32(p->selector);
Duplicated .. see above ^^^^

> +}
> +
> +static int iter_pinctrl_conf_get_update_state(struct scmi_iterator_state *st,
> +					      const void *response, void *priv)
> +{
> +	const struct scmi_resp_conf_get *r = response;
> +
> +	st->num_returned = le32_get_bits(r->num_configs, GENMASK(7, 0));
> +	st->num_remaining = le32_get_bits(r->num_configs, GENMASK(31, 24));
> +

You use the same iterators for both config_get and config_get_all() with proper
conditional ifs (and that is fine) BUT also here you should take care of
the case in which !p->all because in such a case the spec says that the
r->num_configs field should be ignored, which means that the platform
could return 0 or garbage, and you should assume insetad that

      if (!p->all) {
      		st->num_returned = 1;
		st->num_remaining = 0;
      }

...if not the iterator could not work.

(I still have to emulate and test this on my setup though...but at first
sight it is out of spec as it is now...)

> +	return 0;
> +}
> +
> +static int iter_pinctrl_conf_get_process_response(const struct scmi_protocol_handle *ph,
> +						  const void *response,
> +						  struct scmi_iterator_state *st, void *priv)
> +{
> +	const struct scmi_resp_conf_get *r = response;
> +	struct scmi_conf_get_ipriv *p = priv;
> +
> +	if (!p->all) {
> +		if (p->config_types[0] !=
> +		    le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0)))
> +			return -EINVAL;
> +	} else {
> +		p->config_types[st->desc_index + st->loop_idx] =
> +			le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0));
> +	}
> +
> +	p->config_values[st->desc_index + st->loop_idx] =
> +		le32_to_cpu(r->configs[st->loop_idx * 2 + 1]);
> +
> +	return 0;
> +}
> +
> +static int scmi_pinctrl_config_get(const struct scmi_protocol_handle *ph,
> +				   u32 selector,
> +				   enum scmi_pinctrl_selector_type type,
> +				   u8 config_type, unsigned long *config_value)
> +{
> +	int ret;
> +	void *iter;
> +	struct scmi_iterator_ops ops = {
> +		.prepare_message = iter_pinctrl_conf_get_prepare_message,
> +		.update_state = iter_pinctrl_conf_get_update_state,
> +		.process_response = iter_pinctrl_conf_get_process_response,
> +	};
> +	struct scmi_conf_get_ipriv ipriv = {
> +		.selector = selector,
> +		.type = type,
> +		.all = 0,
> +		.config_types = &config_type,
> +		.config_values = config_value,
> +	};
> +
> +	if (!config_value || type == FUNCTION_TYPE)
> +		return -EINVAL;
> +
> +	ret = scmi_pinctrl_validate_id(ph, selector, type);
> +	if (ret)
> +		return ret;
> +
> +	iter = ph->hops->iter_response_init(ph, &ops, 1, PINCTRL_CONFIG_GET,
> +					    sizeof(struct scmi_msg_conf_get),
> +					    &ipriv);
> +
> +	if (IS_ERR(iter))
> +		return PTR_ERR(iter);
> +
> +	return ph->hops->iter_response_run(iter);
> +}
> +
> +static int scmi_pinctrl_config_get_all(const struct scmi_protocol_handle *ph,
> +				       u32 selector,
> +				       enum scmi_pinctrl_selector_type type,
> +				       u16 size, u8 *config_types,
> +				       unsigned long *config_values)
> +{
> +	int ret;
> +	void *iter;
> +	struct scmi_iterator_ops ops = {
> +		.prepare_message = iter_pinctrl_conf_get_prepare_message,
> +		.update_state = iter_pinctrl_conf_get_update_state,
> +		.process_response = iter_pinctrl_conf_get_process_response,
> +	};
> +	struct scmi_conf_get_ipriv ipriv = {
> +		.selector = selector,
> +		.type = type,
> +		.all = 1,
> +		.config_types = config_types,
> +		.config_values = config_values,
> +	};
> +
> +	if (!config_values || !config_types || type == FUNCTION_TYPE)
> +		return -EINVAL;
> +
> +	ret = scmi_pinctrl_validate_id(ph, selector, type);
> +	if (ret)
> +		return ret;
> +
> +	iter = ph->hops->iter_response_init(ph, &ops, size, PINCTRL_CONFIG_GET,
> +					    sizeof(struct scmi_msg_conf_get),
> +					    &ipriv);
> +
> +	if (IS_ERR(iter))
> +		return PTR_ERR(iter);
> +
> +	return ph->hops->iter_response_run(iter);
> +}
> +
> +static int scmi_pinctrl_config_set(const struct scmi_protocol_handle *ph,
> +				   u32 selector,
> +				   enum scmi_pinctrl_selector_type type,
> +				   unsigned long *configs, unsigned int nr_configs)
> +{
> +	struct scmi_xfer *t;
> +	struct scmi_msg_conf_set *tx;
> +	u32 attributes;
> +	int ret, i;
> +	unsigned int configs_in_chunk, conf_num = 0;
> +	unsigned int chunk;
> +	int max_msg_size = ph->hops->get_max_msg_size(ph);
> +
> +	if (!configs || type == FUNCTION_TYPE)
> +		return -EINVAL;
> +
> +	ret = scmi_pinctrl_validate_id(ph, selector, type);
> +	if (ret)
> +		return ret;
> +
> +	configs_in_chunk = (max_msg_size - sizeof(*tx)) / (sizeof(unsigned long) * 2);
> +	while (conf_num < nr_configs) {
> +		chunk = (nr_configs - conf_num > configs_in_chunk) ? configs_in_chunk :
> +			nr_configs - conf_num;
> +
> +		ret = ph->xops->xfer_get_init(ph, PINCTRL_CONFIG_SET,
> +					      sizeof(*tx) + chunk * 2 * sizeof(unsigned long),
> +					      0, &t);
> +		if (ret)
> +			return ret;
> +
> +		tx = t->tx.buf;
> +		tx->identifier = cpu_to_le32(selector);
> +		attributes = FIELD_PREP(GENMASK(1, 0), type) |
> +			FIELD_PREP(GENMASK(9, 2), chunk);
> +		tx->attributes = cpu_to_le32(attributes);
> +

The chunking seems good to me till here, BUT these last lines should not be like:

> +		for (i = 0; i < chunk; i++) {
> +			tx->configs[i * 2] = cpu_to_le32(pinconf_to_config_param(configs[i]));

			tx->configs[i * 2] = cpu_to_le32(pinconf_to_config_param(configs[conf_num + i]));

> +			tx->configs[i * 2 + 1] =
> +				cpu_to_le32(pinconf_to_config_argument(configs[i]));

				cpu_to_le32(pinconf_to_config_argument(configs[conf_num + i]));

..sice you are indexing the provided configs inside a chunk loop ?
(still to be properly 'fully' tested too...)

> +		}
> +
> +		ret = ph->xops->do_xfer(ph, t);
> +
> +		ph->xops->xfer_put(ph, t);
> +
> +		if (ret)
> +			break;
> +
> +		conf_num += chunk;
> +	}
> +
> +	return ret;
> +}

As said, I'll plan to exercise a bit more these interfaces directly BUT
as it is now my basic test case using the original generic pinctrl scmi
driver is still working after these latest changes.

Thanks,
Cristian


From krzysztof.kozlowski at linaro.org  Fri Dec 22 08:01:37 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 22 Dec 2023 17:01:37 +0100
Subject: [PATCH 1/6] dt-bindings: display: panel: Add BOE
 TH101MB31IG002-28A panel
In-Reply-To: <20231222-pinetab2-v1-1-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-1-e148a7f61bd1@mecka.net>
Message-ID: <282596bd-3987-4322-b8f1-fabfe2c91628@linaro.org>

On 22/12/2023 12:05, Manuel Traut wrote:
> Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
> used e.g. in the Pine64 Pinetab2 and PinetabV.
> 
> Signed-off-by: Manuel Traut <manut at mecka.net>
> ---

> +
> +maintainers:
> +  - Manuel Traut <manut at mecka.net>
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +    enum:
> +        # BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel
> +      - boe,th101mb31ig002-28a
> +
> +  reg:

reg: true

> +    description: the virtual channel number of a DSI peripheral
> +
> +  backlight:

: true

> +    description: phandle of the backlight device attached to the panel

Because there is really no need to repeat obvious.

> +
> +  enable-gpios:
> +    description: a GPIO spec for the enable pin

Ditto

> +
> +  power-supply:
> +    description: core voltage supply

Ditto

> +
> +

And drop redundant blank lines.

> +  ports: true

Hm, why ports? From where did you copy it?

> +  rotation: true
> +
> +required:
> +  - compatible
> +  - reg
> +  - enable-gpios
> +  - power-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    dsi {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        panel at 0 {
> +            compatible = "boe,th101mb31ig002-28a";
> +            reg = <0>;
> +            backlight = <&backlight_lcd0>;
> +            enable-gpios = <&pio 45 0>;

Use define for GPIO flag.



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec 22 08:02:32 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 22 Dec 2023 17:02:32 +0100
Subject: [PATCH 3/6] dt-bindings: arm64: rockchip: Add Pine64 Pinetab2
In-Reply-To: <20231222-pinetab2-v1-3-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-3-e148a7f61bd1@mecka.net>
Message-ID: <5b4692c8-e9f7-46dc-a060-6b309da97d27@linaro.org>

On 22/12/2023 12:05, Manuel Traut wrote:
> Add devicvetree binding documentation for Pine64 Pinetab2
> which uses the Rockchip RK3566 SoC.
> 
> Signed-off-by: Manuel Traut <manut at mecka.net>
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec 22 08:05:26 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 22 Dec 2023 17:05:26 +0100
Subject: [PATCH 6/6] dt-bindings: display: rockchip: dw-hdmi: Add missing
 sound-dai-cells property
In-Reply-To: <20231222-pinetab2-v1-6-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-6-e148a7f61bd1@mecka.net>
Message-ID: <da0ba7fd-4704-42d5-8d7b-f033cb68d259@linaro.org>

On 22/12/2023 12:05, Manuel Traut wrote:
> The sound-dai-cells property is used, e.g. in rk356x.dtsi

Better to see here rather explanation why dai cells are needed, unless
you aren't sure and just want to fix warning.

> 
> Signed-off-by: Manuel Traut <manut at mecka.net>
> ---
>  .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml        | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> index 7e59dee15a5f..43250255fb6f 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> @@ -94,6 +94,9 @@ properties:
>        - const: default
>        - const: unwedge
>  

Please add $ref to dai-common.yaml in allOf.

	
> +  '#sound-dai-cells':
> +    const: 0
> +

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Fri Dec 22 08:07:31 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Fri, 22 Dec 2023 17:07:31 +0100
Subject: [PATCH 5/6] arm64: dts: rockchip: Fix some dtb-check warnings
In-Reply-To: <20231222-pinetab2-v1-5-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-5-e148a7f61bd1@mecka.net>
Message-ID: <d59a60d9-6bd3-4945-a345-0b01eaf1ead8@linaro.org>

On 22/12/2023 12:05, Manuel Traut wrote:
> devicetree checks show some warnings:
> 
> video-codec at fdea0400: 'interrupt-names' is a required property
> from schema $id: http://devicetree.org/schemas/media/rockchip-vpu.yaml#
> 
> hdmi at fe0a0000: Unevaluated properties are not allowed ('power-domains' were unexpected)
> from schema $id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
> 

...

> @@ -819,7 +820,6 @@ hdmi: hdmi at fe0a0000 {
>  		clock-names = "iahb", "isfr", "cec", "ref";
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
> -		power-domains = <&power RK3568_PD_VO>;
>  		reg-io-width = <4>;
>  		rockchip,grf = <&grf>;
>  		#sound-dai-cells = <0>;
> @@ -1123,7 +1123,7 @@ i2s2_2ch: i2s at fe420000 {
>  		dmas = <&dmac1 4>, <&dmac1 5>;
>  		dma-names = "tx", "rx";
>  		resets = <&cru SRST_M_I2S2_2CH>;
> -		reset-names = "m";
> +		reset-names = "tx-m", "rx-m";

That's not correct. Look at line above. How many entries it has?

Do not fix warnings just to make the warning disappear. Your change here
clearly suggests you did just that.

Best regards,
Krzysztof



From broonie at kernel.org  Fri Dec 22 08:21:08 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:08 +0000
Subject: [PATCH RFC v2 00/22] KVM: arm64: Implement support for SME in
 non-protected guests
Message-ID: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>

This series implements support for SME use in non-protected KVM guests.
Much of this is very similar to SVE, the main additional challenge that
SME presents is that it introduces two new controls which change the
registers seen by guests:

 - PSTATE.ZA enables the ZA matrix register and, if SME2 is supported,
   the ZT0 LUT register.
 - PSTATE.SM enables streaming mode, a new floating point mode which
   uses the SVE register set with a separately configured vector length.
   In streaming mode implementation of the FFR register is optional.

It is also permitted to build systems which support SME without SVE, in
this case when not in streaming mode no SVE registers or instructions
are available.  Further, there is no requirement that there be any
overlap in the set of vector lengths supported by SVE and SME in a
system, this is expected to be a common situation in practical systems.

Since there is a new vector length to configure we introduce a new
feature parallel to the existing SVE one with a new pseudo register for
the streaming mode vector length.  Due to the overlap with SVE caused by
streaming mode rather than finalising SME as a separate feature we use
the existing SVE finalisation to also finalise SME, a new define
KVM_ARM_VCPU_VEC is provided to help make user code clearer.  Finalising
SVE and SME separately would introduce complication with register access
since finalising SVE makes the SVE regsiters writeable by userspace and
doing multiple finalisations results in an error being reported.
Dealing with a state where the SVE registers are writeable due to one of
SVE or SME being finalised but may have their VL changed by the other
being finalised seems like needless complexity with minimal practical
utility, it seems clearer to just express directly that only one
finalisation can be done in the ABI.

We represent the streaming mode registers to userspace by always using
the existing SVE registers to access the floating point state, using the
larger of the SME and (if enabled for the guest) SVE vector lengths.

There are a large number of subfeatures for SME, most of which only
offer additional instructions but some of which (SME2 and FA64) add
architectural state.  The expectation is that these will be configured
via the ID registers but since the mechanism for doing this is still
unclear the current code enables SME2 and FA64 for the guest if the host
supports them regardless of what the ID registers say.

Since we do not yet have support for SVE in protected guests and SME is
very reliant on SVE this series does not implement support for SME in
protected guests.  This will be added separately once SVE support is
merged into mainline (or along with merging that), there is code for
protected guests using SVE in the Android tree.

The new KVM_ARM_VCPU_VEC feature and ZA and ZT0 registers have not been
added to the get-reg-list selftest, the idea of supporting additional
features there without restructuring the program to generate all
possible feature combinations has been rejected.  I will post a separate
series which does that restructuring.

I am seeing some test failures currently which I've not got to the
bottom of, at this point I'm reasonably sure these are preexisting
issues in the kernel which are more apparent in a guest.

To: Marc Zyngier <maz at kernel.org>
To: Oliver Upton <oliver.upton at linux.dev>
To: James Morse <james.morse at arm.com>
To: Suzuki K Poulose <suzuki.poulose at arm.com>
To: Catalin Marinas <catalin.marinas at arm.com>
To: Will Deacon <will at kernel.org>
Cc:  <linux-arm-kernel at lists.infradead.org>
Cc:  <kvmarm at lists.linux.dev>
Cc:  <linux-kernel at vger.kernel.org>
To: Paolo Bonzini <pbonzini at redhat.com>
To: Jonathan Corbet <corbet at lwn.net>
Cc:  <kvm at vger.kernel.org>
Cc:  <linux-doc at vger.kernel.org>
To: Shuah Khan <shuah at kernel.org>
Cc:  <linux-kselftest at vger.kernel.org>
Signed-off-by: Mark Brown <broonie at kernel.org>

Changes in v2:
- Rebase onto v6.7-rc3.
- Configure subfeatures based on host system only.
- Complete nVHE support.
- There was some snafu with sending v1 out, it didn't make it to the
  lists but in case it hit people's inboxes I'm sending as v2.

---
Mark Brown (22):
      KVM: arm64: Document why we trap SVE access from the host
      arm64/fpsimd: Make SVE<->FPSIMD rewriting available to KVM
      KVM: arm64: Move SVE state access macros after feature test macros
      KVM: arm64: Store vector lengths in an array
      KVM: arm64: Document the KVM ABI for SME
      KVM: arm64: Make FFR restore optional in __sve_restore_state()
      KVM: arm64: Define guest flags for SME
      KVM: arm64: Rename SVE finalization constants to be more general
      KVM: arm64: Basic SME system register descriptions
      KVM: arm64: Add support for TPIDR2_EL0
      KVM: arm64: Make SMPRI_EL1 RES0 for SME guests
      KVM: arm64: Make SVCR a normal system register
      KVM: arm64: Context switch SME state for guest
      KVM: arm64: Manage and handle SME traps
      KVM: arm64: Implement SME vector length configuration
      KVM: arm64: Rename sve_state_reg_region
      KVM: arm64: Support userspace access to streaming mode SVE registers
      KVM: arm64: Expose ZA to userspace
      KVM: arm64: Provide userspace access to ZT0
      KVM: arm64: Support SME version configuration via ID registers
      KVM: arm64: Provide userspace ABI for enabling SME
      KVM: arm64: selftests: Add SME system registers to get-reg-list

 Documentation/virt/kvm/api.rst                     | 104 +++++---
 arch/arm64/include/asm/fpsimd.h                    |   5 +
 arch/arm64/include/asm/kvm_emulate.h               |  13 +-
 arch/arm64/include/asm/kvm_host.h                  |  99 +++++---
 arch/arm64/include/asm/kvm_hyp.h                   |   3 +-
 arch/arm64/include/uapi/asm/kvm.h                  |  33 +++
 arch/arm64/kernel/fpsimd.c                         |  51 +++-
 arch/arm64/kvm/arm.c                               |  16 +-
 arch/arm64/kvm/fpsimd.c                            | 266 ++++++++++++++++++---
 arch/arm64/kvm/guest.c                             | 230 +++++++++++++++---
 arch/arm64/kvm/handle_exit.c                       |  11 +
 arch/arm64/kvm/hyp/fpsimd.S                        |  11 +-
 arch/arm64/kvm/hyp/include/hyp/switch.h            |  86 ++++++-
 arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h         |  16 ++
 arch/arm64/kvm/hyp/nvhe/hyp-main.c                 |  60 ++++-
 arch/arm64/kvm/hyp/nvhe/switch.c                   |  13 +-
 arch/arm64/kvm/hyp/vhe/switch.c                    |   3 +
 arch/arm64/kvm/reset.c                             | 150 +++++++++---
 arch/arm64/kvm/sys_regs.c                          |  67 +++++-
 include/uapi/linux/kvm.h                           |   1 +
 tools/testing/selftests/kvm/aarch64/get-reg-list.c |  32 ++-
 21 files changed, 1063 insertions(+), 207 deletions(-)
---
base-commit: 4ae6e89253b387476c2ba0202c3a80f2e1284e91
change-id: 20230301-kvm-arm64-sme-06a1246d3636

Best regards,
-- 
Mark Brown <broonie at kernel.org>



From broonie at kernel.org  Fri Dec 22 08:21:09 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:09 +0000
Subject: [PATCH RFC v2 01/22] KVM: arm64: Document why we trap SVE access
 from the host
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-1-da226cb180bb@kernel.org>

When we exit from a SVE guest we leave the SVE configuration in EL2 as it
was for the guest, only switching back to the host configuration on next
use by the host. This is perhaps a little surprising, add comments
explaining what is going on both in the trap handler and when we configure
the traps.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_emulate.h | 1 +
 arch/arm64/kvm/hyp/nvhe/hyp-main.c   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 78a550537b67..14d6ff2e2a39 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -598,6 +598,7 @@ static __always_inline u64 kvm_get_reset_cptr_el2(struct kvm_vcpu *vcpu)
 	} else {
 		val = CPTR_NVHE_EL2_RES1;
 
+		/* Leave traps enabled, we will restore EL2 lazily */
 		if (vcpu_has_sve(vcpu) &&
 		    (vcpu->arch.fp_state == FP_STATE_GUEST_OWNED))
 			val |= CPTR_EL2_TZ;
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 2385fd03ed87..84deed83e580 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -420,6 +420,7 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
 		handle_host_smc(host_ctxt);
 		break;
 	case ESR_ELx_EC_SVE:
+		/* Handle lazy restore of the host VL */
 		if (has_hvhe())
 			sysreg_clear_set(cpacr_el1, 0, (CPACR_EL1_ZEN_EL1EN |
 							CPACR_EL1_ZEN_EL0EN));

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:10 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:10 +0000
Subject: [PATCH RFC v2 02/22] arm64/fpsimd: Make SVE<->FPSIMD rewriting
 available to KVM
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-2-da226cb180bb@kernel.org>

We have routines to rewrite between FPSIMD and SVE data formats, make these
visible to the KVM host code so that we can use them to present the FP
register state in SVE format for guests which have SME without SVE.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/fpsimd.h |  5 +++++
 arch/arm64/kernel/fpsimd.c      | 23 +++++++++++++++--------
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index 50e5f25d3024..7092e7f944ae 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -157,6 +157,11 @@ extern void cpu_enable_fa64(const struct arm64_cpu_capabilities *__unused);
 
 extern u64 read_smcr_features(void);
 
+void __fpsimd_to_sve(void *sst, struct user_fpsimd_state const *fst,
+		     unsigned int vq);
+void __sve_to_fpsimd(struct user_fpsimd_state *fst, void const *sst,
+		     unsigned int vq);
+
 /*
  * Helpers to translate bit indices in sve_vq_map to VQ values (and
  * vice versa).  This allows find_next_bit() to be used to find the
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 1559c706d32d..e6a4dd68f62a 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -647,8 +647,8 @@ static __uint128_t arm64_cpu_to_le128(__uint128_t x)
 
 #define arm64_le128_to_cpu(x) arm64_cpu_to_le128(x)
 
-static void __fpsimd_to_sve(void *sst, struct user_fpsimd_state const *fst,
-			    unsigned int vq)
+void __fpsimd_to_sve(void *sst, struct user_fpsimd_state const *fst,
+		     unsigned int vq)
 {
 	unsigned int i;
 	__uint128_t *p;
@@ -659,6 +659,18 @@ static void __fpsimd_to_sve(void *sst, struct user_fpsimd_state const *fst,
 	}
 }
 
+void __sve_to_fpsimd(struct user_fpsimd_state *fst, const void *sst,
+		     unsigned int vq)
+{
+	unsigned int i;
+	__uint128_t const *p;
+
+	for (i = 0; i < SVE_NUM_ZREGS; ++i) {
+		p = (__uint128_t const *)ZREG(sst, vq, i);
+		fst->vregs[i] = arm64_le128_to_cpu(*p);
+	}
+}
+
 /*
  * Transfer the FPSIMD state in task->thread.uw.fpsimd_state to
  * task->thread.sve_state.
@@ -700,18 +712,13 @@ static void sve_to_fpsimd(struct task_struct *task)
 	unsigned int vq, vl;
 	void const *sst = task->thread.sve_state;
 	struct user_fpsimd_state *fst = &task->thread.uw.fpsimd_state;
-	unsigned int i;
-	__uint128_t const *p;
 
 	if (!system_supports_sve() && !system_supports_sme())
 		return;
 
 	vl = thread_get_cur_vl(&task->thread);
 	vq = sve_vq_from_vl(vl);
-	for (i = 0; i < SVE_NUM_ZREGS; ++i) {
-		p = (__uint128_t const *)ZREG(sst, vq, i);
-		fst->vregs[i] = arm64_le128_to_cpu(*p);
-	}
+	__sve_to_fpsimd(fst, sst, vq);
 }
 
 #ifdef CONFIG_ARM64_SVE

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:11 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:11 +0000
Subject: [PATCH RFC v2 03/22] KVM: arm64: Move SVE state access macros
 after feature test macros
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-3-da226cb180bb@kernel.org>

In preparation for SME support move the macros used to access SVE state
after the feature test macros, we will need to test for SME subfeatures to
determine the size of the SME state.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h | 40 +++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 824f29f04916..9180713a2f9b 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -772,26 +772,6 @@ struct kvm_vcpu_arch {
 #define IN_WFI			__vcpu_single_flag(sflags, BIT(7))
 
 
-/* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
-#define vcpu_sve_pffr(vcpu) (kern_hyp_va((vcpu)->arch.sve_state) +	\
-			     sve_ffr_offset((vcpu)->arch.sve_max_vl))
-
-#define vcpu_sve_max_vq(vcpu)	sve_vq_from_vl((vcpu)->arch.sve_max_vl)
-
-#define vcpu_sve_state_size(vcpu) ({					\
-	size_t __size_ret;						\
-	unsigned int __vcpu_vq;						\
-									\
-	if (WARN_ON(!sve_vl_valid((vcpu)->arch.sve_max_vl))) {		\
-		__size_ret = 0;						\
-	} else {							\
-		__vcpu_vq = vcpu_sve_max_vq(vcpu);			\
-		__size_ret = SVE_SIG_REGS_SIZE(__vcpu_vq);		\
-	}								\
-									\
-	__size_ret;							\
-})
-
 #define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE | \
 				 KVM_GUESTDBG_USE_SW_BP | \
 				 KVM_GUESTDBG_USE_HW | \
@@ -820,6 +800,26 @@ struct kvm_vcpu_arch {
 
 #define vcpu_gp_regs(v)		(&(v)->arch.ctxt.regs)
 
+/* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
+#define vcpu_sve_pffr(vcpu) (kern_hyp_va((vcpu)->arch.sve_state) +	\
+			     sve_ffr_offset((vcpu)->arch.sve_max_vl))
+
+#define vcpu_sve_max_vq(vcpu)	sve_vq_from_vl((vcpu)->arch.sve_max_vl)
+
+#define vcpu_sve_state_size(vcpu) ({					\
+	size_t __size_ret;						\
+	unsigned int __vcpu_vq;						\
+									\
+	if (WARN_ON(!sve_vl_valid((vcpu)->arch.sve_max_vl))) {		\
+		__size_ret = 0;						\
+	} else {							\
+		__vcpu_vq = vcpu_sve_max_vq(vcpu);			\
+		__size_ret = SVE_SIG_REGS_SIZE(__vcpu_vq);		\
+	}								\
+									\
+	__size_ret;							\
+})
+
 /*
  * Only use __vcpu_sys_reg/ctxt_sys_reg if you know you want the
  * memory backed version of a register, and not the one most recently

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:12 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:12 +0000
Subject: [PATCH RFC v2 04/22] KVM: arm64: Store vector lengths in an array
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-4-da226cb180bb@kernel.org>

SME introduces a second vector length enumerated and configured in the same
manner as for SVE. In a similar manner to the host kernel refactor to store
an array of vector lengths in order to facilitate sharing code between the
two.

We do not fully handle vcpu_sve_pffr() since we have not yet introduced
support for streaming mode, this will be updated as part of implementing
streaming mode.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h  | 12 +++++++-----
 arch/arm64/kvm/fpsimd.c            |  2 +-
 arch/arm64/kvm/guest.c             |  6 +++---
 arch/arm64/kvm/hyp/nvhe/hyp-main.c |  5 ++++-
 arch/arm64/kvm/reset.c             | 16 ++++++++--------
 5 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 9180713a2f9b..3b557ffb8e7b 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -74,7 +74,7 @@ static inline enum kvm_mode kvm_get_mode(void) { return KVM_MODE_NONE; };
 
 DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
 
-extern unsigned int __ro_after_init kvm_sve_max_vl;
+extern unsigned int __ro_after_init kvm_vec_max_vl[ARM64_VEC_MAX];
 int __init kvm_arm_init_sve(void);
 
 u32 __attribute_const__ kvm_target_cpu(void);
@@ -515,7 +515,7 @@ struct kvm_vcpu_arch {
 	 */
 	void *sve_state;
 	enum fp_type fp_type;
-	unsigned int sve_max_vl;
+	unsigned int max_vl[ARM64_VEC_MAX];
 	u64 svcr;
 
 	/* Stage 2 paging state used by the hardware on next switch */
@@ -802,15 +802,17 @@ struct kvm_vcpu_arch {
 
 /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
 #define vcpu_sve_pffr(vcpu) (kern_hyp_va((vcpu)->arch.sve_state) +	\
-			     sve_ffr_offset((vcpu)->arch.sve_max_vl))
+			     sve_ffr_offset((vcpu)->arch.max_vl[ARM64_VEC_SVE]))
 
-#define vcpu_sve_max_vq(vcpu)	sve_vq_from_vl((vcpu)->arch.sve_max_vl)
+#define vcpu_vec_max_vq(type, vcpu) sve_vq_from_vl((vcpu)->arch.max_vl[type])
+
+#define vcpu_sve_max_vq(vcpu)	vcpu_vec_max_vq(ARM64_VEC_SVE, vcpu)
 
 #define vcpu_sve_state_size(vcpu) ({					\
 	size_t __size_ret;						\
 	unsigned int __vcpu_vq;						\
 									\
-	if (WARN_ON(!sve_vl_valid((vcpu)->arch.sve_max_vl))) {		\
+	if (WARN_ON(!sve_vl_valid((vcpu)->arch.max_vl[ARM64_VEC_SVE]))) { \
 		__size_ret = 0;						\
 	} else {							\
 		__vcpu_vq = vcpu_sve_max_vq(vcpu);			\
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 8c1d0d4853df..a402a072786a 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -150,7 +150,7 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
 		 */
 		fp_state.st = &vcpu->arch.ctxt.fp_regs;
 		fp_state.sve_state = vcpu->arch.sve_state;
-		fp_state.sve_vl = vcpu->arch.sve_max_vl;
+		fp_state.sve_vl = vcpu->arch.max_vl[ARM64_VEC_SVE];
 		fp_state.sme_state = NULL;
 		fp_state.svcr = &vcpu->arch.svcr;
 		fp_state.fp_type = &vcpu->arch.fp_type;
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index aaf1d4939739..3ae08f7c0b80 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -317,7 +317,7 @@ static int get_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	if (!vcpu_has_sve(vcpu))
 		return -ENOENT;
 
-	if (WARN_ON(!sve_vl_valid(vcpu->arch.sve_max_vl)))
+	if (WARN_ON(!sve_vl_valid(vcpu->arch.max_vl[ARM64_VEC_SVE])))
 		return -EINVAL;
 
 	memset(vqs, 0, sizeof(vqs));
@@ -355,7 +355,7 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 		if (vq_present(vqs, vq))
 			max_vq = vq;
 
-	if (max_vq > sve_vq_from_vl(kvm_sve_max_vl))
+	if (max_vq > sve_vq_from_vl(kvm_vec_max_vl[ARM64_VEC_SVE]))
 		return -EINVAL;
 
 	/*
@@ -374,7 +374,7 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 		return -EINVAL;
 
 	/* vcpu->arch.sve_state will be alloc'd by kvm_vcpu_finalize_sve() */
-	vcpu->arch.sve_max_vl = sve_vl_from_vq(max_vq);
+	vcpu->arch.max_vl[ARM64_VEC_SVE] = sve_vl_from_vq(max_vq);
 
 	return 0;
 }
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 84deed83e580..56808df6a078 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -26,11 +26,14 @@ void __kvm_hyp_host_forward_smc(struct kvm_cpu_context *host_ctxt);
 static void flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
 {
 	struct kvm_vcpu *host_vcpu = hyp_vcpu->host_vcpu;
+	int i;
 
 	hyp_vcpu->vcpu.arch.ctxt	= host_vcpu->arch.ctxt;
 
+	for (i = 0; i < ARRAY_SIZE(hyp_vcpu->vcpu.arch.max_vl); i++)
+		hyp_vcpu->vcpu.arch.max_vl[i] = host_vcpu->arch.max_vl[i];
+
 	hyp_vcpu->vcpu.arch.sve_state	= kern_hyp_va(host_vcpu->arch.sve_state);
-	hyp_vcpu->vcpu.arch.sve_max_vl	= host_vcpu->arch.sve_max_vl;
 
 	hyp_vcpu->vcpu.arch.hw_mmu	= host_vcpu->arch.hw_mmu;
 
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 5bb4de162cab..81b949dd809d 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -45,12 +45,12 @@ static u32 __ro_after_init kvm_ipa_limit;
 #define VCPU_RESET_PSTATE_SVC	(PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
 				 PSR_AA32_I_BIT | PSR_AA32_F_BIT)
 
-unsigned int __ro_after_init kvm_sve_max_vl;
+unsigned int __ro_after_init kvm_vec_max_vl[ARM64_VEC_MAX];
 
 int __init kvm_arm_init_sve(void)
 {
 	if (system_supports_sve()) {
-		kvm_sve_max_vl = sve_max_virtualisable_vl();
+		kvm_vec_max_vl[ARM64_VEC_SVE] = sve_max_virtualisable_vl();
 
 		/*
 		 * The get_sve_reg()/set_sve_reg() ioctl interface will need
@@ -58,16 +58,16 @@ int __init kvm_arm_init_sve(void)
 		 * order to support vector lengths greater than
 		 * VL_ARCH_MAX:
 		 */
-		if (WARN_ON(kvm_sve_max_vl > VL_ARCH_MAX))
-			kvm_sve_max_vl = VL_ARCH_MAX;
+		if (WARN_ON(kvm_vec_max_vl[ARM64_VEC_SVE] > VL_ARCH_MAX))
+			kvm_vec_max_vl[ARM64_VEC_SVE] = VL_ARCH_MAX;
 
 		/*
 		 * Don't even try to make use of vector lengths that
 		 * aren't available on all CPUs, for now:
 		 */
-		if (kvm_sve_max_vl < sve_max_vl())
+		if (kvm_vec_max_vl[ARM64_VEC_SVE] < sve_max_vl())
 			pr_warn("KVM: SVE vector length for guests limited to %u bytes\n",
-				kvm_sve_max_vl);
+				kvm_vec_max_vl[ARM64_VEC_SVE]);
 	}
 
 	return 0;
@@ -75,7 +75,7 @@ int __init kvm_arm_init_sve(void)
 
 static void kvm_vcpu_enable_sve(struct kvm_vcpu *vcpu)
 {
-	vcpu->arch.sve_max_vl = kvm_sve_max_vl;
+	vcpu->arch.max_vl[ARM64_VEC_SVE] = kvm_vec_max_vl[ARM64_VEC_SVE];
 
 	/*
 	 * Userspace can still customize the vector lengths by writing
@@ -96,7 +96,7 @@ static int kvm_vcpu_finalize_sve(struct kvm_vcpu *vcpu)
 	size_t reg_sz;
 	int ret;
 
-	vl = vcpu->arch.sve_max_vl;
+	vl = vcpu->arch.max_vl[ARM64_VEC_SVE];
 
 	/*
 	 * Responsibility for these properties is shared between

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:13 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:13 +0000
Subject: [PATCH RFC v2 05/22] KVM: arm64: Document the KVM ABI for SME
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-5-da226cb180bb@kernel.org>

SME, the Scalable Matrix Extension, is an arm64 extension which adds support
for matrix operations, with core concepts patterned after SVE.

SVE introduced some complication in the ABI since it adds new vector
floating point registers with runtime configurable size, the size being
controlled by a prameter called the vector length (VL). To provide control
of this to VMMs we offer two phase configuration of SVE, SVE must first be
enabled for the vCPU with KVM_ARM_VCPU_INIT(KVM_ARM_VCPU_SVE), after which
vector length may then be configured but the configurably sized floating
point registers are inaccessible until finalized with a call to
KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE) after which the configurably sized
registers can be accessed.

SME introduces an additional independent configurable vector length which
as well as controlling the size of the new ZA register also provides an
alternative view of the configurably sized SVE registers (known as streaming
mode) with the guest able to switch between the two modes as it pleases.
There is also a fixed sized register ZT0 introduced in SME2. As well as
streaming mode the guest may enable and disable ZA and (where SME2 is
available) ZT0 dynamically independently of streaming mode. These modes are
controlled via the system register SVCR.

We handle the configuration of the vector length for SME in a similar
manner to SVE, requiring initialization and finalization of the feature
with a pseudo register controlling the available SME vector lengths as for
SVE. Further, if the guest has both SVE and SME then finalizing one
prevents further configuration of the vector length for the other.

Where both SVE and SME are configured for the guest we always present the
SVE registers to userspace as having the larger of the configured maximum
SVE and SME vector lengths, discarding extra data at load time and zero
padding on read as required if the active vector length is lower. Note that
this means that enabling or disabling streaming mode while the guest is
stopped will not zero Zn or Pn as it will when the guest is running, but it
does allow SVCR, Zn and Pn to be read and written in any order.

Userspace access to ZA and (if configured) ZT0 is always available, they
will be zeroed when the guest runs if disabled in SVCR and the value read
will be zero if the guest stops with them disabled. This mirrors the
behaviour of the architecture, enabling access causes ZA and ZT0 to be
zeroed, while allowing access to SVCR, ZA and ZT0 to be performed in any
order.

If SME is enabled for a guest without SVE then the FPSIMD Vn registers
must be accessed via the low 128 bits of the SVE Zn registers as is the
case when SVE is enabled. This is not ideal but allows access to SVCR and
the registers in any order without duplication or ambiguity about which
values should take effect. This may be an issue for VMMs that are
unaware of SME on systems that implement it without SVE if they let SME
be enabled, the lack of access to Vn may surprise them, but it seems
like an unusual implementation choice.

For SME unware VMMs on systems with both SVE and SME support the SVE
registers may be larger than expected, this should be less disruptive
than on a system without SVE as they will simply ignore the high bits of
the registers.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 Documentation/virt/kvm/api.rst | 104 +++++++++++++++++++++++++++++------------
 1 file changed, 73 insertions(+), 31 deletions(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 7025b3751027..b64541fa3e2a 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -374,7 +374,7 @@ Errors:
              instructions from device memory (arm64)
   ENOSYS     data abort outside memslots with no syndrome info and
              KVM_CAP_ARM_NISV_TO_USER not enabled (arm64)
-  EPERM      SVE feature set but not finalized (arm64)
+  EPERM      SVE or SME feature set but not finalized (arm64)
   =======    ==============================================================
 
 This ioctl is used to run a guest virtual cpu.  While there are no
@@ -2585,12 +2585,13 @@ Specifically:
   0x6020 0000 0010 00d5 FPCR        32  fp_regs.fpcr
 ======================= ========= ===== =======================================
 
-.. [1] These encodings are not accepted for SVE-enabled vcpus.  See
+.. [1] These encodings are not accepted for SVE or SME enabled vcpus.  See
        KVM_ARM_VCPU_INIT.
 
        The equivalent register content can be accessed via bits [127:0] of
        the corresponding SVE Zn registers instead for vcpus that have SVE
-       enabled (see below).
+       or SME enabled (see below).  Note carefully that this is true even
+       when only SVE is supported.
 
 arm64 CCSIDR registers are demultiplexed by CSSELR value::
 
@@ -2621,24 +2622,31 @@ arm64 SVE registers have the following bit patterns::
   0x6050 0000 0015 060 <slice:5>        FFR bits[256*slice + 255 : 256*slice]
   0x6060 0000 0015 ffff                 KVM_REG_ARM64_SVE_VLS pseudo-register
 
-Access to register IDs where 2048 * slice >= 128 * max_vq will fail with
-ENOENT.  max_vq is the vcpu's maximum supported vector length in 128-bit
-quadwords: see [2]_ below.
+arm64 SME registers have the following bit patterns:
+
+  0x6080 0000 0017 00 <n:5> <slice:5>   ZA.H[n] bits[2048*slice + 2047 : 2048*slice]
+  0x60XX 0000 0017 0100                 ZT0
+  0x6060 0000 0017 fffe                 KVM_REG_ARM64_SME_VLS pseudo-register
+
+Access to Z, P or ZA register IDs where 2048 * slice >= 128 * max_vq
+will fail with ENOENT.  max_vq is the vcpu's maximum supported vector
+length in 128-bit quadwords: see [2]_ below.
 
 These registers are only accessible on vcpus for which SVE is enabled.
 See KVM_ARM_VCPU_INIT for details.
 
-In addition, except for KVM_REG_ARM64_SVE_VLS, these registers are not
-accessible until the vcpu's SVE configuration has been finalized
-using KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE).  See KVM_ARM_VCPU_INIT
-and KVM_ARM_VCPU_FINALIZE for more information about this procedure.
+In addition, except for KVM_REG_ARM64_SVE_VLS and
+KVM_REG_ARM64_SME_VLS, these registers are not accessible until the
+vcpu's SVE configuration has been finalized using
+KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC).  See KVM_ARM_VCPU_INIT and
+KVM_ARM_VCPU_FINALIZE for more information about this procedure.
 
-KVM_REG_ARM64_SVE_VLS is a pseudo-register that allows the set of vector
-lengths supported by the vcpu to be discovered and configured by
-userspace.  When transferred to or from user memory via KVM_GET_ONE_REG
-or KVM_SET_ONE_REG, the value of this register is of type
-__u64[KVM_ARM64_SVE_VLS_WORDS], and encodes the set of vector lengths as
-follows::
+KVM_REG_ARM64_SVE_VLS and KVM_ARM64_VCPU_SME_VLS are pseudo-registers
+that allows the set of vector lengths supported by the vcpu to be
+discovered and configured by userspace.  When transferred to or from
+user memory via KVM_GET_ONE_REG or KVM_SET_ONE_REG, the value of this
+register is of type __u64[KVM_ARM64_SVE_VLS_WORDS], and encodes the
+set of vector lengths as follows::
 
   __u64 vector_lengths[KVM_ARM64_SVE_VLS_WORDS];
 
@@ -2652,17 +2660,20 @@ follows::
 .. [2] The maximum value vq for which the above condition is true is
        max_vq.  This is the maximum vector length available to the guest on
        this vcpu, and determines which register slices are visible through
-       this ioctl interface.
+       this ioctl interface.  If both SVE and SME are supported for the
+       guest this will be the larger of the two vector lengths regardless
+       of streaming mode being active.
 
 (See Documentation/arch/arm64/sve.rst for an explanation of the "vq"
 nomenclature.)
 
-KVM_REG_ARM64_SVE_VLS is only accessible after KVM_ARM_VCPU_INIT.
-KVM_ARM_VCPU_INIT initialises it to the best set of vector lengths that
-the host supports.
+KVM_REG_ARM64_SVE_VLS and KVM_REG_ARM_SME_VLS are only accessible
+after KVM_ARM_VCPU_INIT.  KVM_ARM_VCPU_INIT initialises them to the
+best set of vector lengths that the host supports.
 
-Userspace may subsequently modify it if desired until the vcpu's SVE
-configuration is finalized using KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE).
+Userspace may subsequently modify these registers if desired until the
+vcpu's SVE and SME configuration is finalized using
+KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC).
 
 Apart from simply removing all vector lengths from the host set that
 exceed some value, support for arbitrarily chosen sets of vector lengths
@@ -2670,8 +2681,8 @@ is hardware-dependent and may not be available.  Attempting to configure
 an invalid set of vector lengths via KVM_SET_ONE_REG will fail with
 EINVAL.
 
-After the vcpu's SVE configuration is finalized, further attempts to
-write this register will fail with EPERM.
+After the vcpu's SVE or SME configuration is finalized, further
+attempts to write these registers will fail with EPERM.
 
 arm64 bitmap feature firmware pseudo-registers have the following bit pattern::
 
@@ -3454,6 +3465,7 @@ The initial values are defined as:
 	- General Purpose registers, including PC and SP: set to 0
 	- FPSIMD/NEON registers: set to 0
 	- SVE registers: set to 0
+	- SME registers: set to 0
 	- System registers: Reset to their architecturally defined
 	  values as for a warm reset to EL1 (resp. SVC)
 
@@ -3496,7 +3508,7 @@ Possible features:
 
 	- KVM_ARM_VCPU_SVE: Enables SVE for the CPU (arm64 only).
 	  Depends on KVM_CAP_ARM_SVE.
-	  Requires KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE):
+	  Requires KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC):
 
 	   * After KVM_ARM_VCPU_INIT:
 
@@ -3504,7 +3516,7 @@ Possible features:
 	        initial value of this pseudo-register indicates the best set of
 	        vector lengths possible for a vcpu on this host.
 
-	   * Before KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE):
+	   * Before KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC}):
 
 	      - KVM_RUN and KVM_GET_REG_LIST are not available;
 
@@ -3517,11 +3529,40 @@ Possible features:
 	        KVM_SET_ONE_REG, to modify the set of vector lengths available
 	        for the vcpu.
 
-	   * After KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE):
+	   * After KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC):
 
 	      - the KVM_REG_ARM64_SVE_VLS pseudo-register is immutable, and can
 	        no longer be written using KVM_SET_ONE_REG.
 
+	- KVM_ARM_VCPU_SME: Enables SME for the CPU (arm64 only).
+	  Depends on KVM_CAP_ARM_SME.
+	  Requires KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC):
+
+	   * After KVM_ARM_VCPU_INIT:
+
+	      - KVM_REG_ARM64_SME_VLS may be read using KVM_GET_ONE_REG: the
+	        initial value of this pseudo-register indicates the best set of
+	        vector lengths possible for a vcpu on this host.
+
+	   * Before KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC}):
+
+	      - KVM_RUN and KVM_GET_REG_LIST are not available;
+
+	      - KVM_GET_ONE_REG and KVM_SET_ONE_REG cannot be used to access
+	        the scalable architectural SVE registers
+	        KVM_REG_ARM64_SVE_ZREG(), KVM_REG_ARM64_SVE_PREG() or
+	        KVM_REG_ARM64_SVE_FFR, the matrix register
+		KVM_REG_ARM64_SME_ZA() or the LUT register KVM_REG_ARM64_ZT();
+
+	      - KVM_REG_ARM64_SME_VLS may optionally be written using
+	        KVM_SET_ONE_REG, to modify the set of vector lengths available
+	        for the vcpu.
+
+	   * After KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC):
+
+	      - the KVM_REG_ARM64_SME_VLS pseudo-register is immutable, and can
+	        no longer be written using KVM_SET_ONE_REG.
+
 4.83 KVM_ARM_PREFERRED_TARGET
 -----------------------------
 
@@ -5055,11 +5096,12 @@ Errors:
 
 Recognised values for feature:
 
-  =====      ===========================================
-  arm64      KVM_ARM_VCPU_SVE (requires KVM_CAP_ARM_SVE)
-  =====      ===========================================
+  =====      ==============================================================
+  arm64      KVM_ARM_VCPU_VEC (requires KVM_CAP_ARM_SVE or KVM_CAP_ARM_SME)
+  arm64      KVM_ARM_VCPU_SVE (alias for KVM_ARM_VCPU_VEC)
+  =====      ==============================================================
 
-Finalizes the configuration of the specified vcpu feature.
+Finalizes the configuration of the specified vcpu features.
 
 The vcpu must already have been initialised, enabling the affected feature, by
 means of a successful KVM_ARM_VCPU_INIT call with the appropriate flag set in

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:14 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:14 +0000
Subject: [PATCH RFC v2 06/22] KVM: arm64: Make FFR restore optional in
 __sve_restore_state()
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-6-da226cb180bb@kernel.org>

Since FFR is an optional feature of SME's streaming SVE mode in order to
support load of guest register state when SME is implemented we need to
provide callers of __sve_restore_state() access to the flag that the
sve_load macro has indicating if FFR should be loaded. Do so, simply a
matter of removing the hard coding in the asm.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_hyp.h        | 2 +-
 arch/arm64/kvm/hyp/fpsimd.S             | 1 -
 arch/arm64/kvm/hyp/include/hyp/switch.h | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 145ce73fc16c..7ac38ed90062 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -111,7 +111,7 @@ void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu);
 
 void __fpsimd_save_state(struct user_fpsimd_state *fp_regs);
 void __fpsimd_restore_state(struct user_fpsimd_state *fp_regs);
-void __sve_restore_state(void *sve_pffr, u32 *fpsr);
+void __sve_restore_state(void *sve_pffr, u32 *fpsr, bool restore_ffr);
 
 u64 __guest_enter(struct kvm_vcpu *vcpu);
 
diff --git a/arch/arm64/kvm/hyp/fpsimd.S b/arch/arm64/kvm/hyp/fpsimd.S
index 61e6f3ba7b7d..8940954b5420 100644
--- a/arch/arm64/kvm/hyp/fpsimd.S
+++ b/arch/arm64/kvm/hyp/fpsimd.S
@@ -21,7 +21,6 @@ SYM_FUNC_START(__fpsimd_restore_state)
 SYM_FUNC_END(__fpsimd_restore_state)
 
 SYM_FUNC_START(__sve_restore_state)
-	mov	x2, #1
 	sve_load 0, x1, x2, 3
 	ret
 SYM_FUNC_END(__sve_restore_state)
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index f99d8af0b9af..9601212bd3ce 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -286,7 +286,7 @@ static inline void __hyp_sve_restore_guest(struct kvm_vcpu *vcpu)
 {
 	sve_cond_update_zcr_vq(vcpu_sve_max_vq(vcpu) - 1, SYS_ZCR_EL2);
 	__sve_restore_state(vcpu_sve_pffr(vcpu),
-			    &vcpu->arch.ctxt.fp_regs.fpsr);
+			    &vcpu->arch.ctxt.fp_regs.fpsr, true);
 	write_sysreg_el1(__vcpu_sys_reg(vcpu, ZCR_EL1), SYS_ZCR);
 }
 

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:15 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:15 +0000
Subject: [PATCH RFC v2 07/22] KVM: arm64: Define guest flags for SME
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-7-da226cb180bb@kernel.org>

Introduce flags for the individually selectable features in SME which
add architectural state:

 - Base SME which adds the system registers and ZA matrix.
 - SME 2 which adds ZT0.
 - FA64 which enables access to the full floating point feature set in
   streaming mode, including adding FFR in streaming mode.

along with helper functions for checking them.

These will be used by further patches actually implementing support for
SME in guests.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h          | 13 +++++++++++++
 arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 10 ++++++++++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3b557ffb8e7b..461068c99b61 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -710,6 +710,12 @@ struct kvm_vcpu_arch {
 #define GUEST_HAS_PTRAUTH	__vcpu_single_flag(cflags, BIT(2))
 /* KVM_ARM_VCPU_INIT completed */
 #define VCPU_INITIALIZED	__vcpu_single_flag(cflags, BIT(3))
+/* SME1 exposed to guest */
+#define GUEST_HAS_SME		__vcpu_single_flag(cflags, BIT(4))
+/* SME2 exposed to guest */
+#define GUEST_HAS_SME2		__vcpu_single_flag(cflags, BIT(5))
+/* FA64 exposed to guest */
+#define GUEST_HAS_FA64		__vcpu_single_flag(cflags, BIT(6))
 
 /* Exception pending */
 #define PENDING_EXCEPTION	__vcpu_single_flag(iflags, BIT(0))
@@ -780,6 +786,13 @@ struct kvm_vcpu_arch {
 #define vcpu_has_sve(vcpu) (system_supports_sve() &&			\
 			    vcpu_get_flag(vcpu, GUEST_HAS_SVE))
 
+#define vcpu_has_sme(vcpu) (system_supports_sme() &&			\
+			    vcpu_get_flag(vcpu, GUEST_HAS_SME))
+#define vcpu_has_sme2(vcpu) (system_supports_sme2() &&			\
+			     vcpu_get_flag(vcpu, GUEST_HAS_SME2))
+#define vcpu_has_fa64(vcpu) (system_supports_fa64() &&			\
+			     vcpu_get_flag(vcpu, GUEST_HAS_FA64))
+
 #ifdef CONFIG_ARM64_PTR_AUTH
 #define vcpu_has_ptrauth(vcpu)						\
 	((cpus_have_final_cap(ARM64_HAS_ADDRESS_AUTH) ||		\
diff --git a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
index bb6b571ec627..fb84834cd2a0 100644
--- a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
+++ b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
@@ -21,6 +21,16 @@ static inline void __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
 	ctxt_sys_reg(ctxt, MDSCR_EL1)	= read_sysreg(mdscr_el1);
 }
 
+static inline bool ctxt_has_sme(struct kvm_cpu_context *ctxt)
+{
+	struct kvm_vcpu *vcpu = ctxt->__hyp_running_vcpu;
+
+	if (!vcpu)
+		vcpu = container_of(ctxt, struct kvm_vcpu, arch.ctxt);
+
+	return vcpu_has_sme(vcpu);
+}
+
 static inline void __sysreg_save_user_state(struct kvm_cpu_context *ctxt)
 {
 	ctxt_sys_reg(ctxt, TPIDR_EL0)	= read_sysreg(tpidr_el0);

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:16 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:16 +0000
Subject: [PATCH RFC v2 08/22] KVM: arm64: Rename SVE finalization constants
 to be more general
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-8-da226cb180bb@kernel.org>

Due to the overlap between SVE and SME vector length configuration
created by streaming mode SVE we will finalize both at once.  Rename the
existing finalization to use _VEC (vector) for the naming to avoid
confusion.

Since this includes the userspace API we create an alias
KVM_ARM_VCPU_VEC for the existing KVM_ARM_VCPU_SVE capability, existing
code which does not enable SME will be unaffected and any SME only code
will not need to use SVE constants.

No functional change.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h |  8 +++++---
 arch/arm64/include/uapi/asm/kvm.h |  6 ++++++
 arch/arm64/kvm/guest.c            | 10 +++++-----
 arch/arm64/kvm/reset.c            | 16 ++++++++--------
 4 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 461068c99b61..920f8a1ff901 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -704,8 +704,8 @@ struct kvm_vcpu_arch {
 
 /* SVE exposed to guest */
 #define GUEST_HAS_SVE		__vcpu_single_flag(cflags, BIT(0))
-/* SVE config completed */
-#define VCPU_SVE_FINALIZED	__vcpu_single_flag(cflags, BIT(1))
+/* SVE/SME config completed */
+#define VCPU_VEC_FINALIZED	__vcpu_single_flag(cflags, BIT(1))
 /* PTRAUTH exposed to guest */
 #define GUEST_HAS_PTRAUTH	__vcpu_single_flag(cflags, BIT(2))
 /* KVM_ARM_VCPU_INIT completed */
@@ -793,6 +793,8 @@ struct kvm_vcpu_arch {
 #define vcpu_has_fa64(vcpu) (system_supports_fa64() &&			\
 			     vcpu_get_flag(vcpu, GUEST_HAS_FA64))
 
+#define vcpu_has_vec(vcpu) (vcpu_has_sve(vcpu) || vcpu_has_sme(vcpu))
+
 #ifdef CONFIG_ARM64_PTR_AUTH
 #define vcpu_has_ptrauth(vcpu)						\
 	((cpus_have_final_cap(ARM64_HAS_ADDRESS_AUTH) ||		\
@@ -1179,7 +1181,7 @@ static inline bool kvm_vm_is_protected(struct kvm *kvm)
 int kvm_arm_vcpu_finalize(struct kvm_vcpu *vcpu, int feature);
 bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
 
-#define kvm_arm_vcpu_sve_finalized(vcpu) vcpu_get_flag(vcpu, VCPU_SVE_FINALIZED)
+#define kvm_arm_vcpu_vec_finalized(vcpu) vcpu_get_flag(vcpu, VCPU_VEC_FINALIZED)
 
 #define kvm_has_mte(kvm)					\
 	(system_supports_mte() &&				\
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 89d2fc872d9f..3048890fac68 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -111,6 +111,12 @@ struct kvm_regs {
 #define KVM_ARM_VCPU_PTRAUTH_GENERIC	6 /* VCPU uses generic authentication */
 #define KVM_ARM_VCPU_HAS_EL2		7 /* Support nested virtualization */
 
+/*
+ * An alias for _SVE since we finalize VL configuration for both SVE and SME
+ * simultaneously.
+ */
+#define KVM_ARM_VCPU_VEC       		KVM_ARM_VCPU_SVE
+
 struct kvm_vcpu_init {
 	__u32 target;
 	__u32 features[7];
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 3ae08f7c0b80..6e116fd8a917 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -341,7 +341,7 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	if (!vcpu_has_sve(vcpu))
 		return -ENOENT;
 
-	if (kvm_arm_vcpu_sve_finalized(vcpu))
+	if (kvm_arm_vcpu_vec_finalized(vcpu))
 		return -EPERM; /* too late! */
 
 	if (WARN_ON(vcpu->arch.sve_state))
@@ -496,7 +496,7 @@ static int get_sve_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	if (ret)
 		return ret;
 
-	if (!kvm_arm_vcpu_sve_finalized(vcpu))
+	if (!kvm_arm_vcpu_vec_finalized(vcpu))
 		return -EPERM;
 
 	if (copy_to_user(uptr, vcpu->arch.sve_state + region.koffset,
@@ -522,7 +522,7 @@ static int set_sve_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	if (ret)
 		return ret;
 
-	if (!kvm_arm_vcpu_sve_finalized(vcpu))
+	if (!kvm_arm_vcpu_vec_finalized(vcpu))
 		return -EPERM;
 
 	if (copy_from_user(vcpu->arch.sve_state + region.koffset, uptr,
@@ -656,7 +656,7 @@ static unsigned long num_sve_regs(const struct kvm_vcpu *vcpu)
 		return 0;
 
 	/* Policed by KVM_GET_REG_LIST: */
-	WARN_ON(!kvm_arm_vcpu_sve_finalized(vcpu));
+	WARN_ON(!kvm_arm_vcpu_vec_finalized(vcpu));
 
 	return slices * (SVE_NUM_PREGS + SVE_NUM_ZREGS + 1 /* FFR */)
 		+ 1; /* KVM_REG_ARM64_SVE_VLS */
@@ -674,7 +674,7 @@ static int copy_sve_reg_indices(const struct kvm_vcpu *vcpu,
 		return 0;
 
 	/* Policed by KVM_GET_REG_LIST: */
-	WARN_ON(!kvm_arm_vcpu_sve_finalized(vcpu));
+	WARN_ON(!kvm_arm_vcpu_vec_finalized(vcpu));
 
 	/*
 	 * Enumerate this first, so that userspace can save/restore in
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 81b949dd809d..ab7cd657a73c 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -89,7 +89,7 @@ static void kvm_vcpu_enable_sve(struct kvm_vcpu *vcpu)
  * Finalize vcpu's maximum SVE vector length, allocating
  * vcpu->arch.sve_state as necessary.
  */
-static int kvm_vcpu_finalize_sve(struct kvm_vcpu *vcpu)
+static int kvm_vcpu_finalize_vec(struct kvm_vcpu *vcpu)
 {
 	void *buf;
 	unsigned int vl;
@@ -119,21 +119,21 @@ static int kvm_vcpu_finalize_sve(struct kvm_vcpu *vcpu)
 	}
 	
 	vcpu->arch.sve_state = buf;
-	vcpu_set_flag(vcpu, VCPU_SVE_FINALIZED);
+	vcpu_set_flag(vcpu, VCPU_VEC_FINALIZED);
 	return 0;
 }
 
 int kvm_arm_vcpu_finalize(struct kvm_vcpu *vcpu, int feature)
 {
 	switch (feature) {
-	case KVM_ARM_VCPU_SVE:
-		if (!vcpu_has_sve(vcpu))
+	case KVM_ARM_VCPU_VEC:
+		if (!vcpu_has_vec(vcpu))
 			return -EINVAL;
 
-		if (kvm_arm_vcpu_sve_finalized(vcpu))
+		if (kvm_arm_vcpu_vec_finalized(vcpu))
 			return -EPERM;
 
-		return kvm_vcpu_finalize_sve(vcpu);
+		return kvm_vcpu_finalize_vec(vcpu);
 	}
 
 	return -EINVAL;
@@ -141,7 +141,7 @@ int kvm_arm_vcpu_finalize(struct kvm_vcpu *vcpu, int feature)
 
 bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu)
 {
-	if (vcpu_has_sve(vcpu) && !kvm_arm_vcpu_sve_finalized(vcpu))
+	if (vcpu_has_vec(vcpu) && !kvm_arm_vcpu_vec_finalized(vcpu))
 		return false;
 
 	return true;
@@ -207,7 +207,7 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	if (loaded)
 		kvm_arch_vcpu_put(vcpu);
 
-	if (!kvm_arm_vcpu_sve_finalized(vcpu)) {
+	if (!kvm_arm_vcpu_vec_finalized(vcpu)) {
 		if (vcpu_has_feature(vcpu, KVM_ARM_VCPU_SVE))
 			kvm_vcpu_enable_sve(vcpu);
 	} else {

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:17 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:17 +0000
Subject: [PATCH RFC v2 09/22] KVM: arm64: Basic SME system register
 descriptions
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-9-da226cb180bb@kernel.org>

Set up the basic system register descriptions for the more straightforward
SME registers. All the registers are available from SME 1.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h |  1 +
 arch/arm64/kvm/sys_regs.c         | 23 +++++++++++++++++++----
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 920f8a1ff901..4be5dda9734d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -333,6 +333,7 @@ enum vcpu_sysreg {
 	ACTLR_EL1,	/* Auxiliary Control Register */
 	CPACR_EL1,	/* Coprocessor Access Control */
 	ZCR_EL1,	/* SVE Control */
+	SMCR_EL1,	/* SME Control */
 	TTBR0_EL1,	/* Translation Table Base Register 0 */
 	TTBR1_EL1,	/* Translation Table Base Register 1 */
 	TCR_EL1,	/* Translation Control Register */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4735e1b37fb3..e6339ca1d8dc 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1404,7 +1404,8 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu,
 		if (!kvm_has_mte(vcpu->kvm))
 			val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
 
-		val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_SME);
+		if (!vcpu_has_sme(vcpu))
+			val &= ~ID_AA64PFR1_EL1_SME_MASK;
 		break;
 	case SYS_ID_AA64ISAR1_EL1:
 		if (!vcpu_has_ptrauth(vcpu))
@@ -1470,6 +1471,9 @@ static unsigned int id_visibility(const struct kvm_vcpu *vcpu,
 		if (!vcpu_has_sve(vcpu))
 			return REG_RAZ;
 		break;
+	case SYS_ID_AA64SMFR0_EL1:
+		if (!vcpu_has_sme(vcpu))
+			return REG_RAZ;
 	}
 
 	return 0;
@@ -1521,6 +1525,16 @@ static unsigned int sve_visibility(const struct kvm_vcpu *vcpu,
 	return REG_HIDDEN;
 }
 
+/* Visibility overrides for SME-specific control registers */
+static unsigned int sme_visibility(const struct kvm_vcpu *vcpu,
+				   const struct sys_reg_desc *rd)
+{
+	if (vcpu_has_sme(vcpu))
+		return 0;
+
+	return REG_HIDDEN;
+}
+
 static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
 					  const struct sys_reg_desc *rd)
 {
@@ -2142,7 +2156,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	ID_UNALLOCATED(4,2),
 	ID_UNALLOCATED(4,3),
 	ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0),
-	ID_HIDDEN(ID_AA64SMFR0_EL1),
+	ID_WRITABLE(ID_AA64SMFR0_EL1, ~ID_AA64SMFR0_EL1_RES0),
 	ID_UNALLOCATED(4,6),
 	ID_UNALLOCATED(4,7),
 
@@ -2211,7 +2225,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_ZCR_EL1), NULL, reset_val, ZCR_EL1, 0, .visibility = sve_visibility },
 	{ SYS_DESC(SYS_TRFCR_EL1), undef_access },
 	{ SYS_DESC(SYS_SMPRI_EL1), undef_access },
-	{ SYS_DESC(SYS_SMCR_EL1), undef_access },
+	{ SYS_DESC(SYS_SMCR_EL1), NULL, reset_val, SMCR_EL1, 0, .visibility = sme_visibility },
 	{ SYS_DESC(SYS_TTBR0_EL1), access_vm_reg, reset_unknown, TTBR0_EL1 },
 	{ SYS_DESC(SYS_TTBR1_EL1), access_vm_reg, reset_unknown, TTBR1_EL1 },
 	{ SYS_DESC(SYS_TCR_EL1), access_vm_reg, reset_val, TCR_EL1, 0 },
@@ -2306,7 +2320,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_CLIDR_EL1), access_clidr, reset_clidr, CLIDR_EL1,
 	  .set_user = set_clidr },
 	{ SYS_DESC(SYS_CCSIDR2_EL1), undef_access },
-	{ SYS_DESC(SYS_SMIDR_EL1), undef_access },
+	{ SYS_DESC(SYS_SMIDR_EL1), .access = access_id_reg,
+	  .get_user = get_id_reg, .visibility = sme_visibility },
 	{ SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, CSSELR_EL1 },
 	{ SYS_DESC(SYS_CTR_EL0), access_ctr },
 	{ SYS_DESC(SYS_SVCR), undef_access },

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:18 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:18 +0000
Subject: [PATCH RFC v2 10/22] KVM: arm64: Add support for TPIDR2_EL0
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-10-da226cb180bb@kernel.org>

SME adds a new user register TPIDR2_EL0, implement support for mananging
this for guests. We provide system register access to it, disable traps
and context switch it along with the other TPIDRs for guests with SME.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h          | 3 +++
 arch/arm64/kvm/hyp/include/hyp/switch.h    | 5 ++++-
 arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 6 ++++++
 arch/arm64/kvm/sys_regs.c                  | 2 +-
 4 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 4be5dda9734d..36bf9d7e92e1 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -347,6 +347,7 @@ enum vcpu_sysreg {
 	CONTEXTIDR_EL1,	/* Context ID Register */
 	TPIDR_EL0,	/* Thread ID, User R/W */
 	TPIDRRO_EL0,	/* Thread ID, User R/O */
+	TPIDR2_EL0,	/* Thread ID 2, User R/W */
 	TPIDR_EL1,	/* Thread ID, Privileged */
 	AMAIR_EL1,	/* Aux Memory Attribute Indirection Register */
 	CNTKCTL_EL1,	/* Timer Control Register (EL1) */
@@ -885,6 +886,7 @@ static inline bool __vcpu_read_sys_reg_from_cpu(int reg, u64 *val)
 	case CONTEXTIDR_EL1:	*val = read_sysreg_s(SYS_CONTEXTIDR_EL12);break;
 	case TPIDR_EL0:		*val = read_sysreg_s(SYS_TPIDR_EL0);	break;
 	case TPIDRRO_EL0:	*val = read_sysreg_s(SYS_TPIDRRO_EL0);	break;
+	case TPIDR2_EL0:	*val = read_sysreg_s(SYS_TPIDR2_EL0);	break;
 	case TPIDR_EL1:		*val = read_sysreg_s(SYS_TPIDR_EL1);	break;
 	case AMAIR_EL1:		*val = read_sysreg_s(SYS_AMAIR_EL12);	break;
 	case CNTKCTL_EL1:	*val = read_sysreg_s(SYS_CNTKCTL_EL12);	break;
@@ -928,6 +930,7 @@ static inline bool __vcpu_write_sys_reg_to_cpu(u64 val, int reg)
 	case VBAR_EL1:		write_sysreg_s(val, SYS_VBAR_EL12);	break;
 	case CONTEXTIDR_EL1:	write_sysreg_s(val, SYS_CONTEXTIDR_EL12);break;
 	case TPIDR_EL0:		write_sysreg_s(val, SYS_TPIDR_EL0);	break;
+	case TPIDR2_EL0:	write_sysreg_s(val, SYS_TPIDR2_EL0);	break;
 	case TPIDRRO_EL0:	write_sysreg_s(val, SYS_TPIDRRO_EL0);	break;
 	case TPIDR_EL1:		write_sysreg_s(val, SYS_TPIDR_EL1);	break;
 	case AMAIR_EL1:		write_sysreg_s(val, SYS_AMAIR_EL12);	break;
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 9601212bd3ce..72982e752972 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -93,7 +93,10 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 	ctxt_sys_reg(hctxt, HFGWTR_EL2) = read_sysreg_s(SYS_HFGWTR_EL2);
 
 	if (cpus_have_final_cap(ARM64_SME)) {
-		tmp = HFGxTR_EL2_nSMPRI_EL1_MASK | HFGxTR_EL2_nTPIDR2_EL0_MASK;
+		tmp = HFGxTR_EL2_nSMPRI_EL1_MASK;
+
+		if (!vcpu_has_sme(vcpu))
+			tmp |= HFGxTR_EL2_nTPIDR2_EL0_MASK;
 
 		r_clr |= tmp;
 		w_clr |= tmp;
diff --git a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
index fb84834cd2a0..5436b33d50b7 100644
--- a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
+++ b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
@@ -35,6 +35,9 @@ static inline void __sysreg_save_user_state(struct kvm_cpu_context *ctxt)
 {
 	ctxt_sys_reg(ctxt, TPIDR_EL0)	= read_sysreg(tpidr_el0);
 	ctxt_sys_reg(ctxt, TPIDRRO_EL0)	= read_sysreg(tpidrro_el0);
+
+	if (ctxt_has_sme(ctxt))
+		ctxt_sys_reg(ctxt, TPIDR2_EL0) = read_sysreg_s(SYS_TPIDR2_EL0);
 }
 
 static inline bool ctxt_has_mte(struct kvm_cpu_context *ctxt)
@@ -105,6 +108,9 @@ static inline void __sysreg_restore_user_state(struct kvm_cpu_context *ctxt)
 {
 	write_sysreg(ctxt_sys_reg(ctxt, TPIDR_EL0),	tpidr_el0);
 	write_sysreg(ctxt_sys_reg(ctxt, TPIDRRO_EL0),	tpidrro_el0);
+
+	if (ctxt_has_sme(ctxt))
+		write_sysreg_s(ctxt_sys_reg(ctxt, TPIDR2_EL0), SYS_TPIDR2_EL0);
 }
 
 static inline void __sysreg_restore_el1_state(struct kvm_cpu_context *ctxt)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index e6339ca1d8dc..a33ad12dc3ab 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2369,7 +2369,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 
 	{ SYS_DESC(SYS_TPIDR_EL0), NULL, reset_unknown, TPIDR_EL0 },
 	{ SYS_DESC(SYS_TPIDRRO_EL0), NULL, reset_unknown, TPIDRRO_EL0 },
-	{ SYS_DESC(SYS_TPIDR2_EL0), undef_access },
+	{ SYS_DESC(SYS_TPIDR2_EL0), NULL, reset_unknown, TPIDR2_EL0, 0, .visibility = sme_visibility },
 
 	{ SYS_DESC(SYS_SCXTNUM_EL0), undef_access },
 

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:19 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:19 +0000
Subject: [PATCH RFC v2 11/22] KVM: arm64: Make SMPRI_EL1 RES0 for SME
 guests
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-11-da226cb180bb@kernel.org>

SME priorities are entirely implementation defined and Linux currently has
no support for SME priorities so we do not expose them to SME capable
guests, reporting SMIDR_EL1.SMPS as 0. This means that on a host which
supports SME priorities we need to trap writes to SMPRI_EL1 and make the
whole register RES0. For a guest that does not support SME at all the
register should instead be undefined.

If the host does not support SME priorities we could disable the trap but
since there is no reason to access SMPRI_EL1 on a system that does not
support priorities it seems more trouble than it is worth to detect and
handle this eventuality, especially given the lack of SME priority support
in the host and potential user confusion that may result if we report that
the feature is detected but do not provide any interface for it.

With the current specification and host implementation we could disable
read traps for all guests since we initialise SMPRI_EL1.Priority to 0
but for robustness when we do start implementing host support for
priorities or if more fields are added just leave the traps enabled.

Once we have physical implementations that implement SME priorities and an
understanding of how their use impacts the system we can consider exposing
the feature to guests in some form but this will require substantial study.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/kvm/hyp/include/hyp/switch.h |  5 +++++
 arch/arm64/kvm/sys_regs.c               | 14 +++++++++++++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 72982e752972..0cf4770b9d70 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -93,6 +93,11 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
 	ctxt_sys_reg(hctxt, HFGWTR_EL2) = read_sysreg_s(SYS_HFGWTR_EL2);
 
 	if (cpus_have_final_cap(ARM64_SME)) {
+		/*
+		 * We hide priorities from guests so need to trap
+		 * access to SMPRI_EL1 in order to map it to RES0
+		 * even if the guest has SME.
+		 */
 		tmp = HFGxTR_EL2_nSMPRI_EL1_MASK;
 
 		if (!vcpu_has_sme(vcpu))
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index a33ad12dc3ab..b618bcab526e 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -351,6 +351,18 @@ static bool access_gic_sre(struct kvm_vcpu *vcpu,
 	return true;
 }
 
+static bool access_res0(struct kvm_vcpu *vcpu,
+			struct sys_reg_params *p,
+			const struct sys_reg_desc *r)
+{
+	if (p->is_write)
+		return ignore_write(vcpu, p);
+
+	p->regval = 0;
+
+	return true;
+}
+
 static bool trap_raz_wi(struct kvm_vcpu *vcpu,
 			struct sys_reg_params *p,
 			const struct sys_reg_desc *r)
@@ -2224,7 +2236,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 
 	{ SYS_DESC(SYS_ZCR_EL1), NULL, reset_val, ZCR_EL1, 0, .visibility = sve_visibility },
 	{ SYS_DESC(SYS_TRFCR_EL1), undef_access },
-	{ SYS_DESC(SYS_SMPRI_EL1), undef_access },
+	{ SYS_DESC(SYS_SMPRI_EL1), .access = access_res0, .visibility = sme_visibility },
 	{ SYS_DESC(SYS_SMCR_EL1), NULL, reset_val, SMCR_EL1, 0, .visibility = sme_visibility },
 	{ SYS_DESC(SYS_TTBR0_EL1), access_vm_reg, reset_unknown, TTBR0_EL1 },
 	{ SYS_DESC(SYS_TTBR1_EL1), access_vm_reg, reset_unknown, TTBR1_EL1 },

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:20 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:20 +0000
Subject: [PATCH RFC v2 12/22] KVM: arm64: Make SVCR a normal system
 register
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-12-da226cb180bb@kernel.org>

As a placeholder while SME guests were not supported we provide a u64 in
struct kvm_vcpu_arch for the host kernel's floating point save code to use
when managing KVM guests. In order to support KVM guests we will need to
replace this with a proper KVM system register, do so and update the system
register definition to make it accessible to the guest if it has SME.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h | 2 +-
 arch/arm64/kvm/fpsimd.c           | 8 +++++---
 arch/arm64/kvm/sys_regs.c         | 2 +-
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 36bf9d7e92e1..690c439b5e2a 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -356,6 +356,7 @@ enum vcpu_sysreg {
 	MDCCINT_EL1,	/* Monitor Debug Comms Channel Interrupt Enable Reg */
 	OSLSR_EL1,	/* OS Lock Status Register */
 	DISR_EL1,	/* Deferred Interrupt Status Register */
+	SVCR,		/* Scalable Vector Control Register */
 
 	/* Performance Monitors Registers */
 	PMCR_EL0,	/* Control Register */
@@ -518,7 +519,6 @@ struct kvm_vcpu_arch {
 	void *sve_state;
 	enum fp_type fp_type;
 	unsigned int max_vl[ARM64_VEC_MAX];
-	u64 svcr;
 
 	/* Stage 2 paging state used by the hardware on next switch */
 	struct kvm_s2_mmu *hw_mmu;
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index a402a072786a..1be18d719fce 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -145,14 +145,16 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
 	if (vcpu->arch.fp_state == FP_STATE_GUEST_OWNED) {
 
 		/*
-		 * Currently we do not support SME guests so SVCR is
-		 * always 0 and we just need a variable to point to.
+		 * We peer into the registers since SVCR is saved as
+		 * part of the floating point state, determining which
+		 * registers exist and their size, so is saved by
+		 * fpsimd_save().
 		 */
 		fp_state.st = &vcpu->arch.ctxt.fp_regs;
 		fp_state.sve_state = vcpu->arch.sve_state;
 		fp_state.sve_vl = vcpu->arch.max_vl[ARM64_VEC_SVE];
 		fp_state.sme_state = NULL;
-		fp_state.svcr = &vcpu->arch.svcr;
+		fp_state.svcr = &(vcpu->arch.ctxt.sys_regs[SVCR]);
 		fp_state.fp_type = &vcpu->arch.fp_type;
 
 		if (vcpu_has_sve(vcpu))
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index b618bcab526e..f908aa3fb606 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2336,7 +2336,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  .get_user = get_id_reg, .visibility = sme_visibility },
 	{ SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, CSSELR_EL1 },
 	{ SYS_DESC(SYS_CTR_EL0), access_ctr },
-	{ SYS_DESC(SYS_SVCR), undef_access },
+	{ SYS_DESC(SYS_SVCR), NULL, reset_val, SVCR, 0, .visibility = sme_visibility },
 
 	{ PMU_SYS_REG(PMCR_EL0), .access = access_pmcr, .reset = reset_pmcr,
 	  .reg = PMCR_EL0, .get_user = get_pmcr, .set_user = set_pmcr },

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:21 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:21 +0000
Subject: [PATCH RFC v2 13/22] KVM: arm64: Context switch SME state for
 guest
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-13-da226cb180bb@kernel.org>

If the guest has access to SME then we need to restore state for it and
configure SMCR_EL2 to grant the guest access to the vector lengths that
it has access to, along with FA64 and ZT0 if they were enabled.

SME has three sets of registers, ZA, ZT (only present if SME2 is
supported for the guest) and streaming SVE. ZA and streaming SVE use a
separately configured streaming mode vector length. The first two are
fairly straightforward, they are enabled by PSTATE.ZA which is saved and
restored via SVCR.ZA. We reuse the assembly the host already uses to
load them from a single contiguous buffer. If PSTATE.ZA is not set they
can only be accessed by setting PSTATE.ZA which will initialise them to
all bits 0.

Streaming mode SVE presents some complications, this is a version of
the SVE registers which may optionally omit the FFR register and which
uses the streaming mode vector length. Similarly to ZA and ZT it is
controlled by PSTATE.SM which we save and restore with SVCR.SM. Any
change in the value of PSTATE.SM initialises all bits of the floating
point registers to 0 so we do not need to be concerned about information
leakage due to changes in vector length between streaming and non-streaming
modes.

The overall floating point restore is modified to start by assuming that
we will restore either FPSIMD or full SVE register state depending on if
the guest has access to vanilla SVE. If the guest has SME we then check
the SME configuration we are restoring and override as appropriate.
Since SVE instructions are VL agnostic the hardware will load using the
appropriate vector length without us needing to pass further flags.

We also modify the floating point save to save SMCR and restore the host
configuration in a similar way to ZCR, the code is slightly more complex
since for SME as well as the vector length we also have enables for FA64
and ZT0 in the register.

Since the layout of the SVE register state depends on the vector length
we need to pass the active vector length when getting the pointer to
FFR.

Since for reasons discussed at length in aaa2f14e6f3f ("KVM: arm64:
Clarify host SME state management") we always disable both PSTATE.SM and
PSTATE.ZA prior to running the guest meaning that we do not need to
worry about saving host SME state.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h       |  7 ++-
 arch/arm64/include/asm/kvm_hyp.h        |  1 +
 arch/arm64/kvm/fpsimd.c                 | 83 ++++++++++++++++++++++-----------
 arch/arm64/kvm/hyp/fpsimd.S             | 10 ++++
 arch/arm64/kvm/hyp/include/hyp/switch.h | 76 ++++++++++++++++++++++++++++--
 5 files changed, 143 insertions(+), 34 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 690c439b5e2a..022b9585e6f6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -517,6 +517,7 @@ struct kvm_vcpu_arch {
 	 * records which view it saved in fp_type.
 	 */
 	void *sve_state;
+	void *sme_state;
 	enum fp_type fp_type;
 	unsigned int max_vl[ARM64_VEC_MAX];
 
@@ -818,13 +819,15 @@ struct kvm_vcpu_arch {
 #define vcpu_gp_regs(v)		(&(v)->arch.ctxt.regs)
 
 /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
-#define vcpu_sve_pffr(vcpu) (kern_hyp_va((vcpu)->arch.sve_state) +	\
-			     sve_ffr_offset((vcpu)->arch.max_vl[ARM64_VEC_SVE]))
+#define vcpu_sve_pffr(vcpu, vec) (kern_hyp_va((vcpu)->arch.sve_state) +	\
+			     sve_ffr_offset((vcpu)->arch.max_vl[vec]))
 
 #define vcpu_vec_max_vq(type, vcpu) sve_vq_from_vl((vcpu)->arch.max_vl[type])
 
 #define vcpu_sve_max_vq(vcpu)	vcpu_vec_max_vq(ARM64_VEC_SVE, vcpu)
 
+#define vcpu_sme_max_vq(vcpu)	vcpu_vec_max_vq(ARM64_VEC_SME, vcpu)
+
 #define vcpu_sve_state_size(vcpu) ({					\
 	size_t __size_ret;						\
 	unsigned int __vcpu_vq;						\
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 7ac38ed90062..e555af02ece3 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -112,6 +112,7 @@ void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu);
 void __fpsimd_save_state(struct user_fpsimd_state *fp_regs);
 void __fpsimd_restore_state(struct user_fpsimd_state *fp_regs);
 void __sve_restore_state(void *sve_pffr, u32 *fpsr, bool restore_ffr);
+void __sme_restore_state(void const *state, bool zt);
 
 u64 __guest_enter(struct kvm_vcpu *vcpu);
 
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 1be18d719fce..d9a56a4027a6 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -153,10 +153,15 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
 		fp_state.st = &vcpu->arch.ctxt.fp_regs;
 		fp_state.sve_state = vcpu->arch.sve_state;
 		fp_state.sve_vl = vcpu->arch.max_vl[ARM64_VEC_SVE];
-		fp_state.sme_state = NULL;
+		fp_state.sme_vl = vcpu->arch.max_vl[ARM64_VEC_SME];
+		fp_state.sme_state = vcpu->arch.sme_state;
 		fp_state.svcr = &(vcpu->arch.ctxt.sys_regs[SVCR]);
 		fp_state.fp_type = &vcpu->arch.fp_type;
 
+		/*
+		 * If we are in streaming mode PSTATE.SM will override
+		 * FP_STATE_FPSIMD during save for SME only guests.
+		 */
 		if (vcpu_has_sve(vcpu))
 			fp_state.to_save = FP_STATE_SVE;
 		else
@@ -177,26 +182,11 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
 void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
 {
 	unsigned long flags;
+	u64 cpacr_set, cpacr_clear;
+	u64 smcr_cur, smcr_new;
 
 	local_irq_save(flags);
 
-	/*
-	 * If we have VHE then the Hyp code will reset CPACR_EL1 to
-	 * the default value and we need to reenable SME.
-	 */
-	if (has_vhe() && system_supports_sme()) {
-		/* Also restore EL0 state seen on entry */
-		if (vcpu_get_flag(vcpu, HOST_SME_ENABLED))
-			sysreg_clear_set(CPACR_EL1, 0,
-					 CPACR_EL1_SMEN_EL0EN |
-					 CPACR_EL1_SMEN_EL1EN);
-		else
-			sysreg_clear_set(CPACR_EL1,
-					 CPACR_EL1_SMEN_EL0EN,
-					 CPACR_EL1_SMEN_EL1EN);
-		isb();
-	}
-
 	if (vcpu->arch.fp_state == FP_STATE_GUEST_OWNED) {
 		if (vcpu_has_sve(vcpu)) {
 			__vcpu_sys_reg(vcpu, ZCR_EL1) = read_sysreg_el1(SYS_ZCR);
@@ -207,19 +197,56 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
 						       SYS_ZCR_EL1);
 		}
 
+		if (vcpu_has_sme(vcpu)) {
+			smcr_cur = read_sysreg_el1(SYS_SMCR);
+			__vcpu_sys_reg(vcpu, SMCR_EL1) = smcr_cur;
+
+			/* Restore the full VL and feature set */
+			if (!has_vhe()) {
+				smcr_new = vcpu_sme_max_vq(vcpu) - 1;
+
+				if (system_supports_fa64())
+					smcr_new |= SMCR_ELx_FA64;
+				if (system_supports_sme2())
+					smcr_new |= SMCR_ELx_EZT0_MASK;
+
+				if (smcr_cur != smcr_new)
+					write_sysreg_s(smcr_new, SYS_SMCR_EL1);
+			}
+		}
+
 		fpsimd_save_and_flush_cpu_state();
-	} else if (has_vhe() && system_supports_sve()) {
+	} else if (has_vhe()) {
 		/*
-		 * The FPSIMD/SVE state in the CPU has not been touched, and we
-		 * have SVE (and VHE): CPACR_EL1 (alias CPTR_EL2) has been
-		 * reset by kvm_reset_cptr_el2() in the Hyp code, disabling SVE
-		 * for EL0.  To avoid spurious traps, restore the trap state
-		 * seen by kvm_arch_vcpu_load_fp():
+		 * The FP state in the CPU has not been touched, and
+		 * we have SVE or SME (and VHE): CPACR_EL1 (alias
+		 * CPTR_EL2) has been reset by kvm_reset_cptr_el2() in
+		 * the Hyp code, disabling SVE/SME for EL0.  To avoid
+		 * spurious traps, restore the trap state seen by
+		 * kvm_arch_vcpu_load_fp():
 		 */
-		if (vcpu_get_flag(vcpu, HOST_SVE_ENABLED))
-			sysreg_clear_set(CPACR_EL1, 0, CPACR_EL1_ZEN_EL0EN);
-		else
-			sysreg_clear_set(CPACR_EL1, CPACR_EL1_ZEN_EL0EN, 0);
+
+		cpacr_clear = 0;
+		cpacr_set = 0;
+
+		if (system_supports_sve()) {
+			if (vcpu_get_flag(vcpu, HOST_SVE_ENABLED)) {
+				cpacr_set |= CPACR_EL1_ZEN_EL0EN;
+			} else {
+				cpacr_clear |= CPACR_EL1_ZEN_EL0EN;
+			}
+		}
+
+		if (system_supports_sme()) {
+			if (vcpu_get_flag(vcpu, HOST_SME_ENABLED)) {
+				cpacr_set |= CPACR_EL1_SMEN_EL0EN;
+			} else {
+				cpacr_clear |= CPACR_EL1_SMEN_EL0EN;
+			}
+		}
+
+		if (cpacr_clear || cpacr_set)
+			sysreg_clear_set(CPACR_EL1, cpacr_clear, cpacr_set);
 	}
 
 	local_irq_restore(flags);
diff --git a/arch/arm64/kvm/hyp/fpsimd.S b/arch/arm64/kvm/hyp/fpsimd.S
index 8940954b5420..b266f97b77ae 100644
--- a/arch/arm64/kvm/hyp/fpsimd.S
+++ b/arch/arm64/kvm/hyp/fpsimd.S
@@ -24,3 +24,13 @@ SYM_FUNC_START(__sve_restore_state)
 	sve_load 0, x1, x2, 3
 	ret
 SYM_FUNC_END(__sve_restore_state)
+
+SYM_FUNC_START(__sme_restore_state)
+	_sme_rdsvl	2, 1		// x2 = VL/8
+	sme_load_za 0, x2, 12		// Leaves x0 pointing to the end of ZA
+
+	cbz	x1, 1f
+	_ldr_zt 0
+1:
+	ret
+SYM_FUNC_END(__sme_restore_state)
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 0cf4770b9d70..10a055e8ed73 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -293,11 +293,45 @@ static bool kvm_hyp_handle_mops(struct kvm_vcpu *vcpu, u64 *exit_code)
 static inline void __hyp_sve_restore_guest(struct kvm_vcpu *vcpu)
 {
 	sve_cond_update_zcr_vq(vcpu_sve_max_vq(vcpu) - 1, SYS_ZCR_EL2);
-	__sve_restore_state(vcpu_sve_pffr(vcpu),
-			    &vcpu->arch.ctxt.fp_regs.fpsr, true);
 	write_sysreg_el1(__vcpu_sys_reg(vcpu, ZCR_EL1), SYS_ZCR);
 }
 
+static inline void __hyp_sme_restore_guest(struct kvm_vcpu *vcpu,
+					   bool *restore_sve_regs,
+					   bool *restore_ffr,
+					   enum vec_type *vec_type)
+{
+	u64 svcr, old_smcr, new_smcr;
+
+	/* Configure VL and features for the guest */
+	old_smcr = read_sysreg_s(SYS_SMCR_EL2);
+	new_smcr = old_smcr & ~(SMCR_ELx_LEN_MASK | SMCR_ELx_FA64_MASK |
+				SMCR_ELx_EZT0_MASK);
+	new_smcr |= (vcpu_sme_max_vq(vcpu) - 1) & SMCR_ELx_LEN_MASK;
+	if (vcpu_has_fa64(vcpu))
+		new_smcr |= SMCR_ELx_FA64_MASK;
+	if (vcpu_has_sme2(vcpu))
+		new_smcr |= SMCR_ELx_EZT0_MASK;
+	if (old_smcr != new_smcr)
+		write_sysreg_s(new_smcr, SYS_SMCR_EL2);
+
+	write_sysreg_el1(__vcpu_sys_reg(vcpu, SMCR_EL1), SYS_SMCR);
+
+	/* Restore SVCR before data to ensure PSTATE.{SM,ZA} are configured */
+	svcr = __vcpu_sys_reg(vcpu, SVCR);
+	write_sysreg_s(svcr, SYS_SVCR);
+
+	if (svcr & SVCR_SM_MASK) {
+		*restore_sve_regs = true;
+		*restore_ffr = vcpu_has_fa64(vcpu);
+		*vec_type = ARM64_VEC_SME;
+	}
+
+	if (svcr & SVCR_ZA_MASK)
+		__sme_restore_state(kern_hyp_va((vcpu)->arch.sme_state),
+				    vcpu_has_sme2(vcpu));
+}
+
 /*
  * We trap the first access to the FP/SIMD to save the host context and
  * restore the guest context lazily.
@@ -306,15 +340,20 @@ static inline void __hyp_sve_restore_guest(struct kvm_vcpu *vcpu)
  */
 static bool kvm_hyp_handle_fpsimd(struct kvm_vcpu *vcpu, u64 *exit_code)
 {
-	bool sve_guest;
-	u8 esr_ec;
+	bool sve_guest, sme_guest;
+	u8 esr_ec, esr_iss;
 	u64 reg;
+	bool restore_ffr;
+	bool restore_sve_regs;
+	enum vec_type vec_type = ARM64_VEC_SVE;
 
 	if (!system_supports_fpsimd())
 		return false;
 
 	sve_guest = vcpu_has_sve(vcpu);
+	sme_guest = vcpu_has_sme(vcpu);
 	esr_ec = kvm_vcpu_trap_get_class(vcpu);
+	esr_iss = ESR_ELx_ISS(kvm_vcpu_get_esr(vcpu));
 
 	/* Only handle traps the vCPU can support here: */
 	switch (esr_ec) {
@@ -324,6 +363,14 @@ static bool kvm_hyp_handle_fpsimd(struct kvm_vcpu *vcpu, u64 *exit_code)
 		if (!sve_guest)
 			return false;
 		break;
+	case ESR_ELx_EC_SME:
+		if (!sme_guest)
+			return false;
+
+		if (!vcpu_has_sme2(vcpu) &&
+		    (esr_iss == ESR_ELx_SME_ISS_ZT_DISABLED))
+			return false;
+		break;
 	default:
 		return false;
 	}
@@ -335,12 +382,16 @@ static bool kvm_hyp_handle_fpsimd(struct kvm_vcpu *vcpu, u64 *exit_code)
 		reg = CPACR_EL1_FPEN_EL0EN | CPACR_EL1_FPEN_EL1EN;
 		if (sve_guest)
 			reg |= CPACR_EL1_ZEN_EL0EN | CPACR_EL1_ZEN_EL1EN;
+		if (sme_guest)
+			reg |= CPACR_EL1_SMEN_EL0EN | CPACR_EL1_SMEN_EL1EN;
 
 		sysreg_clear_set(cpacr_el1, 0, reg);
 	} else {
 		reg = CPTR_EL2_TFP;
 		if (sve_guest)
 			reg |= CPTR_EL2_TZ;
+		if (sme_guest)
+			reg |= CPTR_EL2_TSM;
 
 		sysreg_clear_set(cptr_el2, reg, 0);
 	}
@@ -351,8 +402,25 @@ static bool kvm_hyp_handle_fpsimd(struct kvm_vcpu *vcpu, u64 *exit_code)
 		__fpsimd_save_state(vcpu->arch.host_fpsimd_state);
 
 	/* Restore the guest state */
+
+	/*
+	 * These may be overridden if the guest has SME, the host can
+	 * have SME without SVE and in streaming mode SME may lack FFR.
+	 */
+	restore_sve_regs = sve_guest;
+	restore_ffr = sve_guest;
+
 	if (sve_guest)
 		__hyp_sve_restore_guest(vcpu);
+	/* SVCR is cleared by kvm_arch_vcpu_load_fp() for !SME cases */
+	if (sme_guest)
+		__hyp_sme_restore_guest(vcpu, &restore_sve_regs, &restore_ffr,
+					&vec_type);
+
+	if (restore_sve_regs)
+		__sve_restore_state(vcpu_sve_pffr(vcpu, vec_type),
+				    &vcpu->arch.ctxt.fp_regs.fpsr,
+				    restore_ffr);
 	else
 		__fpsimd_restore_state(&vcpu->arch.ctxt.fp_regs);
 

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:22 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:22 +0000
Subject: [PATCH RFC v2 14/22] KVM: arm64: Manage and handle SME traps
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-14-da226cb180bb@kernel.org>

Now that we have support for managing SME state for KVM guests add
handling for SME exceptions generated by guests.  As with SVE these are
routed to the generic floating point exception handlers for both VHE and
nVHE, the floating point state is handled as a uniform block.

Since we do not presently support SME for protected VMs handle
exceptions from protected guests as UNDEF.

For nVHE and hVHE modes we currently do a lazy restore of the host EL2
setup for SVE, do the same for SME. Since it is likely that there will be
common situations where SVE and SME are both used in quick succession by
the host (eg, saving the guest state) restore the configuration for both at
once in order to minimise the number of EL2 entries.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_emulate.h | 12 ++++----
 arch/arm64/kvm/handle_exit.c         | 11 +++++++
 arch/arm64/kvm/hyp/nvhe/hyp-main.c   | 56 ++++++++++++++++++++++++++++++------
 arch/arm64/kvm/hyp/nvhe/switch.c     | 13 ++++-----
 arch/arm64/kvm/hyp/vhe/switch.c      |  3 ++
 5 files changed, 73 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 14d6ff2e2a39..756c2c28c592 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -584,16 +584,15 @@ static __always_inline u64 kvm_get_reset_cptr_el2(struct kvm_vcpu *vcpu)
 
 	if (has_vhe()) {
 		val = (CPACR_EL1_FPEN_EL0EN | CPACR_EL1_FPEN_EL1EN |
-		       CPACR_EL1_ZEN_EL1EN);
-		if (cpus_have_final_cap(ARM64_SME))
-			val |= CPACR_EL1_SMEN_EL1EN;
+		       CPACR_EL1_ZEN_EL1EN | CPACR_EL1_SMEN_EL1EN);
 	} else if (has_hvhe()) {
 		val = (CPACR_EL1_FPEN_EL0EN | CPACR_EL1_FPEN_EL1EN);
 
 		if (!vcpu_has_sve(vcpu) ||
 		    (vcpu->arch.fp_state != FP_STATE_GUEST_OWNED))
 			val |= CPACR_EL1_ZEN_EL1EN | CPACR_EL1_ZEN_EL0EN;
-		if (cpus_have_final_cap(ARM64_SME))
+		if (!vcpu_has_sme(vcpu) ||
+		    (vcpu->arch.fp_state != FP_STATE_GUEST_OWNED))
 			val |= CPACR_EL1_SMEN_EL1EN | CPACR_EL1_SMEN_EL0EN;
 	} else {
 		val = CPTR_NVHE_EL2_RES1;
@@ -602,8 +601,9 @@ static __always_inline u64 kvm_get_reset_cptr_el2(struct kvm_vcpu *vcpu)
 		if (vcpu_has_sve(vcpu) &&
 		    (vcpu->arch.fp_state == FP_STATE_GUEST_OWNED))
 			val |= CPTR_EL2_TZ;
-		if (cpus_have_final_cap(ARM64_SME))
-			val &= ~CPTR_EL2_TSM;
+		if (vcpu_has_sme(vcpu) &&
+		    (vcpu->arch.fp_state == FP_STATE_GUEST_OWNED))
+			val |= CPTR_EL2_TSM;
 	}
 
 	return val;
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 617ae6dea5d5..e5d8d8767872 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -206,6 +206,16 @@ static int handle_sve(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
+/*
+ * Guest access to SME registers should be routed to this handler only
+ * when the system doesn't support SME.
+ */
+static int handle_sme(struct kvm_vcpu *vcpu)
+{
+	kvm_inject_undefined(vcpu);
+	return 1;
+}
+
 /*
  * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into
  * a NOP). If we get here, it is that we didn't fixup ptrauth on exit, and all
@@ -268,6 +278,7 @@ static exit_handle_fn arm_exit_handlers[] = {
 	[ESR_ELx_EC_SVC64]	= handle_svc,
 	[ESR_ELx_EC_SYS64]	= kvm_handle_sys_reg,
 	[ESR_ELx_EC_SVE]	= handle_sve,
+	[ESR_ELx_EC_SME]	= handle_sme,
 	[ESR_ELx_EC_ERET]	= kvm_handle_eret,
 	[ESR_ELx_EC_IABT_LOW]	= kvm_handle_guest_abort,
 	[ESR_ELx_EC_DABT_LOW]	= kvm_handle_guest_abort,
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 56808df6a078..b2da4800b673 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -411,6 +411,52 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
 	kvm_skip_host_instr();
 }
 
+static void handle_host_vec(void)
+{
+	u64 old_smcr, new_smcr;
+	u64 mask = 0;
+
+	/*
+	 * Handle lazy restore of the EL2 configuration for host SVE
+	 * and SME usage.  It is likely that when a host supports both
+	 * SVE and SME it will use both in quick succession (eg,
+	 * saving guest state) so we restore both when either traps.
+	 */
+	if (has_hvhe()) {
+		if (cpus_have_final_cap(ARM64_SVE))
+			mask |= CPACR_EL1_ZEN_EL1EN | CPACR_EL1_ZEN_EL0EN;
+		if (cpus_have_final_cap(ARM64_SME))
+			mask |= CPACR_EL1_SMEN_EL1EN | CPACR_EL1_SMEN_EL0EN;
+
+		sysreg_clear_set(cpacr_el1, 0, mask);
+	} else {
+		if (cpus_have_final_cap(ARM64_SVE))
+			mask |= CPTR_EL2_TZ;
+		if (cpus_have_final_cap(ARM64_SME))
+			mask |= CPTR_EL2_TSM;
+
+		sysreg_clear_set(cptr_el2, mask, 0);
+	}
+
+	isb();
+
+	if (cpus_have_final_cap(ARM64_SVE))
+		sve_cond_update_zcr_vq(ZCR_ELx_LEN_MASK, SYS_ZCR_EL2);
+
+	if (cpus_have_final_cap(ARM64_SME)) {
+		old_smcr = read_sysreg_s(SYS_SMCR_EL2);
+		new_smcr = SMCR_ELx_LEN_MASK;
+
+		if (cpus_have_final_cap(ARM64_SME_FA64))
+			new_smcr |= SMCR_ELx_FA64_MASK;
+		if (cpus_have_final_cap(ARM64_SME2))
+			new_smcr |= SMCR_ELx_EZT0_MASK;
+
+		if (old_smcr != new_smcr)
+			write_sysreg_s(new_smcr, SYS_SMCR_EL2);
+	}
+}
+
 void handle_trap(struct kvm_cpu_context *host_ctxt)
 {
 	u64 esr = read_sysreg_el2(SYS_ESR);
@@ -423,14 +469,8 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
 		handle_host_smc(host_ctxt);
 		break;
 	case ESR_ELx_EC_SVE:
-		/* Handle lazy restore of the host VL */
-		if (has_hvhe())
-			sysreg_clear_set(cpacr_el1, 0, (CPACR_EL1_ZEN_EL1EN |
-							CPACR_EL1_ZEN_EL0EN));
-		else
-			sysreg_clear_set(cptr_el2, CPTR_EL2_TZ, 0);
-		isb();
-		sve_cond_update_zcr_vq(ZCR_ELx_LEN_MASK, SYS_ZCR_EL2);
+	case ESR_ELx_EC_SME:
+		handle_host_vec();
 		break;
 	case ESR_ELx_EC_IABT_LOW:
 	case ESR_ELx_EC_DABT_LOW:
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index c50f8459e4fc..b022728edb2f 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -46,19 +46,14 @@ static void __activate_traps(struct kvm_vcpu *vcpu)
 	val = vcpu->arch.cptr_el2;
 	val |= CPTR_EL2_TAM;	/* Same bit irrespective of E2H */
 	val |= has_hvhe() ? CPACR_EL1_TTA : CPTR_EL2_TTA;
-	if (cpus_have_final_cap(ARM64_SME)) {
-		if (has_hvhe())
-			val &= ~(CPACR_EL1_SMEN_EL1EN | CPACR_EL1_SMEN_EL0EN);
-		else
-			val |= CPTR_EL2_TSM;
-	}
 
 	if (!guest_owns_fp_regs(vcpu)) {
 		if (has_hvhe())
 			val &= ~(CPACR_EL1_FPEN_EL0EN | CPACR_EL1_FPEN_EL1EN |
-				 CPACR_EL1_ZEN_EL0EN | CPACR_EL1_ZEN_EL1EN);
+				 CPACR_EL1_ZEN_EL0EN | CPACR_EL1_ZEN_EL1EN |
+				 CPACR_EL1_SMEN_EL0EN | CPACR_EL1_SMEN_EL1EN);
 		else
-			val |= CPTR_EL2_TFP | CPTR_EL2_TZ;
+			val |= CPTR_EL2_TFP | CPTR_EL2_TZ | CPTR_EL2_TSM;
 
 		__activate_traps_fpsimd32(vcpu);
 	}
@@ -186,6 +181,7 @@ static const exit_handler_fn hyp_exit_handlers[] = {
 	[0 ... ESR_ELx_EC_MAX]		= NULL,
 	[ESR_ELx_EC_CP15_32]		= kvm_hyp_handle_cp15_32,
 	[ESR_ELx_EC_SYS64]		= kvm_hyp_handle_sysreg,
+	[ESR_ELx_EC_SME]		= kvm_hyp_handle_fpsimd,
 	[ESR_ELx_EC_SVE]		= kvm_hyp_handle_fpsimd,
 	[ESR_ELx_EC_FP_ASIMD]		= kvm_hyp_handle_fpsimd,
 	[ESR_ELx_EC_IABT_LOW]		= kvm_hyp_handle_iabt_low,
@@ -198,6 +194,7 @@ static const exit_handler_fn hyp_exit_handlers[] = {
 static const exit_handler_fn pvm_exit_handlers[] = {
 	[0 ... ESR_ELx_EC_MAX]		= NULL,
 	[ESR_ELx_EC_SYS64]		= kvm_handle_pvm_sys64,
+	[ESR_ELx_EC_SME]		= kvm_handle_pvm_restricted,
 	[ESR_ELx_EC_SVE]		= kvm_handle_pvm_restricted,
 	[ESR_ELx_EC_FP_ASIMD]		= kvm_hyp_handle_fpsimd,
 	[ESR_ELx_EC_IABT_LOW]		= kvm_hyp_handle_iabt_low,
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 1581df6aec87..0b1a9733f3e0 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -78,6 +78,8 @@ static void __activate_traps(struct kvm_vcpu *vcpu)
 	if (guest_owns_fp_regs(vcpu)) {
 		if (vcpu_has_sve(vcpu))
 			val |= CPACR_EL1_ZEN_EL0EN | CPACR_EL1_ZEN_EL1EN;
+		if (vcpu_has_sme(vcpu))
+			val |= CPACR_EL1_SMEN_EL0EN | CPACR_EL1_SMEN_EL1EN;
 	} else {
 		val &= ~(CPACR_EL1_FPEN_EL0EN | CPACR_EL1_FPEN_EL1EN);
 		__activate_traps_fpsimd32(vcpu);
@@ -177,6 +179,7 @@ static const exit_handler_fn hyp_exit_handlers[] = {
 	[0 ... ESR_ELx_EC_MAX]		= NULL,
 	[ESR_ELx_EC_CP15_32]		= kvm_hyp_handle_cp15_32,
 	[ESR_ELx_EC_SYS64]		= kvm_hyp_handle_sysreg,
+	[ESR_ELx_EC_SME]		= kvm_hyp_handle_fpsimd,
 	[ESR_ELx_EC_SVE]		= kvm_hyp_handle_fpsimd,
 	[ESR_ELx_EC_FP_ASIMD]		= kvm_hyp_handle_fpsimd,
 	[ESR_ELx_EC_IABT_LOW]		= kvm_hyp_handle_iabt_low,

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:23 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:23 +0000
Subject: [PATCH RFC v2 15/22] KVM: arm64: Implement SME vector length
 configuration
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-15-da226cb180bb@kernel.org>

Configuration for SME vector lengths is done using a virtual register as
for SVE, hook up the implementation for the virtual register.  Since we
do not yet have support for any of the new SME registers stub register
access functions are provided.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/uapi/asm/kvm.h |  9 ++++
 arch/arm64/kvm/guest.c            | 94 +++++++++++++++++++++++++++++++--------
 2 files changed, 84 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 3048890fac68..02642bb96496 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -353,6 +353,15 @@ struct kvm_arm_counter_offset {
 #define KVM_ARM64_SVE_VLS_WORDS	\
 	((KVM_ARM64_SVE_VQ_MAX - KVM_ARM64_SVE_VQ_MIN) / 64 + 1)
 
+/* SME registers */
+#define KVM_REG_ARM64_SME		(0x17 << KVM_REG_ARM_COPROC_SHIFT)
+
+/* Vector lengths pseudo-register: */
+#define KVM_REG_ARM64_SME_VLS		(KVM_REG_ARM64 | KVM_REG_ARM64_SME | \
+					 KVM_REG_SIZE_U512 | 0xffff)
+#define KVM_ARM64_SME_VLS_WORDS	\
+	((KVM_ARM64_SVE_VQ_MAX - KVM_ARM64_SVE_VQ_MIN) / 64 + 1)
+
 /* Bitmap feature firmware registers */
 #define KVM_REG_ARM_FW_FEAT_BMAP		(0x0016 << KVM_REG_ARM_COPROC_SHIFT)
 #define KVM_REG_ARM_FW_FEAT_BMAP_REG(r)		(KVM_REG_ARM64 | KVM_REG_SIZE_U64 | \
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 6e116fd8a917..30446ae357f0 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -309,22 +309,20 @@ static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 #define vq_mask(vq) ((u64)1 << ((vq) - SVE_VQ_MIN) % 64)
 #define vq_present(vqs, vq) (!!((vqs)[vq_word(vq)] & vq_mask(vq)))
 
-static int get_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+static int get_vec_vls(enum vec_type vec_type, struct kvm_vcpu *vcpu,
+		      const struct kvm_one_reg *reg)
 {
 	unsigned int max_vq, vq;
 	u64 vqs[KVM_ARM64_SVE_VLS_WORDS];
 
-	if (!vcpu_has_sve(vcpu))
-		return -ENOENT;
-
-	if (WARN_ON(!sve_vl_valid(vcpu->arch.max_vl[ARM64_VEC_SVE])))
+	if (WARN_ON(!sve_vl_valid(vcpu->arch.max_vl[vec_type])))
 		return -EINVAL;
 
 	memset(vqs, 0, sizeof(vqs));
 
-	max_vq = vcpu_sve_max_vq(vcpu);
+	max_vq = vcpu_vec_max_vq(vec_type, vcpu);
 	for (vq = SVE_VQ_MIN; vq <= max_vq; ++vq)
-		if (sve_vq_available(vq))
+		if (vq_available(vec_type, vq))
 			vqs[vq_word(vq)] |= vq_mask(vq);
 
 	if (copy_to_user((void __user *)reg->addr, vqs, sizeof(vqs)))
@@ -333,18 +331,13 @@ static int get_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	return 0;
 }
 
-static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+static int set_vec_vls(enum vec_type vec_type, struct kvm_vcpu *vcpu,
+		       const struct kvm_one_reg *reg)
 {
 	unsigned int max_vq, vq;
 	u64 vqs[KVM_ARM64_SVE_VLS_WORDS];
 
-	if (!vcpu_has_sve(vcpu))
-		return -ENOENT;
-
-	if (kvm_arm_vcpu_vec_finalized(vcpu))
-		return -EPERM; /* too late! */
-
-	if (WARN_ON(vcpu->arch.sve_state))
+	if (WARN_ON(!sve_vl_valid(vcpu->arch.max_vl[vec_type])))
 		return -EINVAL;
 
 	if (copy_from_user(vqs, (const void __user *)reg->addr, sizeof(vqs)))
@@ -355,18 +348,18 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 		if (vq_present(vqs, vq))
 			max_vq = vq;
 
-	if (max_vq > sve_vq_from_vl(kvm_vec_max_vl[ARM64_VEC_SVE]))
+	if (max_vq > sve_vq_from_vl(kvm_vec_max_vl[vec_type]))
 		return -EINVAL;
 
 	/*
 	 * Vector lengths supported by the host can't currently be
 	 * hidden from the guest individually: instead we can only set a
-	 * maximum via ZCR_EL2.LEN.  So, make sure the available vector
+	 * maximum via xCR_EL2.LEN.  So, make sure the available vector
 	 * lengths match the set requested exactly up to the requested
 	 * maximum:
 	 */
 	for (vq = SVE_VQ_MIN; vq <= max_vq; ++vq)
-		if (vq_present(vqs, vq) != sve_vq_available(vq))
+		if (vq_present(vqs, vq) != vq_available(vec_type, vq))
 			return -EINVAL;
 
 	/* Can't run with no vector lengths at all: */
@@ -374,11 +367,33 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 		return -EINVAL;
 
 	/* vcpu->arch.sve_state will be alloc'd by kvm_vcpu_finalize_sve() */
-	vcpu->arch.max_vl[ARM64_VEC_SVE] = sve_vl_from_vq(max_vq);
+	vcpu->arch.max_vl[vec_type] = sve_vl_from_vq(max_vq);
 
 	return 0;
 }
 
+static int get_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	if (!vcpu_has_sve(vcpu))
+		return -ENOENT;
+
+	return get_vec_vls(ARM64_VEC_SVE, vcpu, reg);
+}
+
+static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	if (!vcpu_has_sve(vcpu))
+		return -ENOENT;
+
+	if (kvm_arm_vcpu_vec_finalized(vcpu))
+		return -EPERM; /* too late! */
+
+	if (WARN_ON(vcpu->arch.sve_state))
+		return -EINVAL;
+
+	return set_vec_vls(ARM64_VEC_SVE, vcpu, reg);
+}
+
 #define SVE_REG_SLICE_SHIFT	0
 #define SVE_REG_SLICE_BITS	5
 #define SVE_REG_ID_SHIFT	(SVE_REG_SLICE_SHIFT + SVE_REG_SLICE_BITS)
@@ -532,6 +547,45 @@ static int set_sve_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	return 0;
 }
 
+static int get_sme_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	if (!vcpu_has_sme(vcpu))
+		return -ENOENT;
+
+	return get_vec_vls(ARM64_VEC_SME, vcpu, reg);
+}
+
+static int set_sme_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	if (!vcpu_has_sme(vcpu))
+		return -ENOENT;
+
+	if (kvm_arm_vcpu_vec_finalized(vcpu))
+		return -EPERM; /* too late! */
+
+	if (WARN_ON(vcpu->arch.sme_state))
+		return -EINVAL;
+
+	return set_vec_vls(ARM64_VEC_SME, vcpu, reg);
+}
+
+static int get_sme_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	/* Handle the KVM_REG_ARM64_SME_VLS pseudo-reg as a special case: */
+	if (reg->id == KVM_REG_ARM64_SME_VLS)
+		return get_sme_vls(vcpu, reg);
+
+	return -EINVAL;
+}
+
+static int set_sme_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
+{
+	/* Handle the KVM_REG_ARM64_SME_VLS pseudo-reg as a special case: */
+	if (reg->id == KVM_REG_ARM64_SME_VLS)
+		return set_sme_vls(vcpu, reg);
+
+	return -EINVAL;
+}
 int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 {
 	return -EINVAL;
@@ -771,6 +825,7 @@ int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	case KVM_REG_ARM_FW_FEAT_BMAP:
 		return kvm_arm_get_fw_reg(vcpu, reg);
 	case KVM_REG_ARM64_SVE:	return get_sve_reg(vcpu, reg);
+	case KVM_REG_ARM64_SME:	return get_sme_reg(vcpu, reg);
 	}
 
 	if (is_timer_reg(reg->id))
@@ -791,6 +846,7 @@ int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	case KVM_REG_ARM_FW_FEAT_BMAP:
 		return kvm_arm_set_fw_reg(vcpu, reg);
 	case KVM_REG_ARM64_SVE:	return set_sve_reg(vcpu, reg);
+	case KVM_REG_ARM64_SME:	return set_sme_reg(vcpu, reg);
 	}
 
 	if (is_timer_reg(reg->id))

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:24 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:24 +0000
Subject: [PATCH RFC v2 16/22] KVM: arm64: Rename sve_state_reg_region
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-16-da226cb180bb@kernel.org>

As for SVE we will need to pull parts of dynamically sized registers out of
a block of memory for SME so we will use a similar code pattern for this.
Rename the current struct sve_state_reg_region in preparation for this.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/kvm/guest.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 30446ae357f0..1d161fa7c2be 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -418,9 +418,9 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
  */
 #define vcpu_sve_slices(vcpu) 1
 
-/* Bounds of a single SVE register slice within vcpu->arch.sve_state */
-struct sve_state_reg_region {
-	unsigned int koffset;	/* offset into sve_state in kernel memory */
+/* Bounds of a single register slice within vcpu->arch.s[mv]e_state */
+struct vec_state_reg_region {
+	unsigned int koffset;	/* offset into s[mv]e_state in kernel memory */
 	unsigned int klen;	/* length in kernel memory */
 	unsigned int upad;	/* extra trailing padding in user memory */
 };
@@ -429,7 +429,7 @@ struct sve_state_reg_region {
  * Validate SVE register ID and get sanitised bounds for user/kernel SVE
  * register copy
  */
-static int sve_reg_to_region(struct sve_state_reg_region *region,
+static int sve_reg_to_region(struct vec_state_reg_region *region,
 			     struct kvm_vcpu *vcpu,
 			     const struct kvm_one_reg *reg)
 {
@@ -499,7 +499,7 @@ static int sve_reg_to_region(struct sve_state_reg_region *region,
 static int get_sve_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 {
 	int ret;
-	struct sve_state_reg_region region;
+	struct vec_state_reg_region region;
 	char __user *uptr = (char __user *)reg->addr;
 
 	/* Handle the KVM_REG_ARM64_SVE_VLS pseudo-reg as a special case: */
@@ -525,7 +525,7 @@ static int get_sve_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 static int set_sve_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 {
 	int ret;
-	struct sve_state_reg_region region;
+	struct vec_state_reg_region region;
 	const char __user *uptr = (const char __user *)reg->addr;
 
 	/* Handle the KVM_REG_ARM64_SVE_VLS pseudo-reg as a special case: */

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:25 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:25 +0000
Subject: [PATCH RFC v2 17/22] KVM: arm64: Support userspace access to
 streaming mode SVE registers
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-17-da226cb180bb@kernel.org>

SME defines a new mode called streaming mode with an associated vector
length which may be configured independently to the standard SVE vector
length. SVE and SME also have no interdependency, it is valid to implement
SME without SVE. When in streaming mode the SVE registers are accessible
with the streaming mode vector length rather than  the usual SVE vector
length. In order to handle this we extend the existing SVE register
interface to expose the vector length dependent registers with the larger
of the SVE or SME vector length and requiring access to the V registers via
the SVE register set if the system supports only SME.

The main complication this creates is that the format that is sensible for
saving and restoring the registers in the hypervisor is no longer the same
as that which is exposed to userspace. This is especially true when the
host does not have SVE, in that case we must use FPSIMD register save and
restore code in non-streaming mode. Handle this by extending our set of
register access owners to include userspace access, converting to the
format used by the hypervisor if needed when preparing to run the guest
and to userspace format when the registers are read. This avoids any
conversions in normal hypervisor scheduling.

The userspace format is the existing SVE format with the largest vector
length used. The hypervisor format varies depending on the current value
of SVCR.SM and if SVE is supported:

 - If SVCR.SM=1 then SVE format with the SME vector length is used.
 - If SVCR.SM=0 and SVE is not supported then the FPSIMD format is used.
 - If SVCR.SM=0 and SVE is supported the SVE format and vector length are
   used.

When converting to a larger vector length we pad the high bits with 0.

Since we already track the owner of the floating point register state
introduce a new state FP_STATE_USER_OWNED in which the state is stored in
the format we present to userspace. The guest starts out in this state.
When we prepare to run the guest we check for this state and
the guest we check for this state and if we are in it we do any rewrites
needed to store in the format the hypervisor expects. In order to minimise
overhead we only convert back to userspace format if userspace accesses the
SVE registers.

For simpliciy we always represent FFR for SVE storage, if the system
lacks both SVE and streaming mode FFR then the value will be visible
but ignored.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h |   6 +-
 arch/arm64/kvm/arm.c              |   9 +-
 arch/arm64/kvm/fpsimd.c           | 173 ++++++++++++++++++++++++++++++++++++++
 arch/arm64/kvm/guest.c            |  16 ++--
 4 files changed, 195 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 022b9585e6f6..a5ed0433edc6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -540,6 +540,7 @@ struct kvm_vcpu_arch {
 		FP_STATE_FREE,
 		FP_STATE_HOST_OWNED,
 		FP_STATE_GUEST_OWNED,
+		FP_STATE_USER_OWNED,
 	} fp_state;
 
 	/* Configuration flags, set once and for all before the vcpu can run */
@@ -828,6 +829,9 @@ struct kvm_vcpu_arch {
 
 #define vcpu_sme_max_vq(vcpu)	vcpu_vec_max_vq(ARM64_VEC_SME, vcpu)
 
+int vcpu_max_vq(struct kvm_vcpu *vcpu);
+void vcpu_fp_guest_to_user(struct kvm_vcpu *vcpu);
+
 #define vcpu_sve_state_size(vcpu) ({					\
 	size_t __size_ret;						\
 	unsigned int __vcpu_vq;						\
@@ -835,7 +839,7 @@ struct kvm_vcpu_arch {
 	if (WARN_ON(!sve_vl_valid((vcpu)->arch.max_vl[ARM64_VEC_SVE]))) { \
 		__size_ret = 0;						\
 	} else {							\
-		__vcpu_vq = vcpu_sve_max_vq(vcpu);			\
+		__vcpu_vq = vcpu_max_vq(vcpu);				\
 		__size_ret = SVE_SIG_REGS_SIZE(__vcpu_vq);		\
 	}								\
 									\
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index e5f75f1f1085..aa7e2031263c 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -376,9 +376,14 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
 
 	/*
 	 * Default value for the FP state, will be overloaded at load
-	 * time if we support FP (pretty likely)
+	 * time if we support FP (pretty likely).  If we support both
+	 * SVE and SME we may have to rewrite between the two VLs,
+	 * default to formatting the registers for userspace access.
 	 */
-	vcpu->arch.fp_state = FP_STATE_FREE;
+	if (system_supports_sve() && system_supports_sme())
+		vcpu->arch.fp_state = FP_STATE_USER_OWNED;
+	else
+		vcpu->arch.fp_state = FP_STATE_FREE;
 
 	/* Set up the timer */
 	kvm_timer_vcpu_init(vcpu);
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index d9a56a4027a6..a40072e149cf 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -14,6 +14,24 @@
 #include <asm/kvm_mmu.h>
 #include <asm/sysreg.h>
 
+/* We present Z and P to userspace with the maximum of the SVE or SME VL */
+int vcpu_max_vq(struct kvm_vcpu *vcpu)
+{
+	int sve, sme;
+
+	if (vcpu_has_sve(vcpu))
+		sve = vcpu_sve_max_vq(vcpu);
+	else
+		sve = 0;
+
+	if (vcpu_has_sme(vcpu))
+		sme = vcpu_sme_max_vq(vcpu);
+	else
+		sme = 0;
+
+	return max(sve, sme);
+}
+
 void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
 {
 	struct task_struct *p = vcpu->arch.parent_task;
@@ -65,6 +83,159 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
 	return 0;
 }
 
+static bool vcpu_fp_user_format_needed(struct kvm_vcpu *vcpu)
+{
+	/* Only systems with SME need rewrites */
+	if (!system_supports_sme())
+		return false;
+
+	/*
+	 * If we have both SVE and SME and the two VLs are the same
+	 * and no rewrite is needed.
+	 */
+	if (vcpu_has_sve(vcpu) &&
+	    (vcpu_sve_max_vq(vcpu) == vcpu_sme_max_vq(vcpu)))
+		return false;
+
+	return true;
+}
+
+static bool vcpu_sm_active(struct kvm_vcpu *vcpu)
+{
+	return __vcpu_sys_reg(vcpu, SVCR) & SVCR_SM;
+}
+
+static int vcpu_active_vq(struct kvm_vcpu *vcpu)
+{
+	if (vcpu_sm_active(vcpu))
+		return vcpu_sme_max_vq(vcpu);
+	else
+		return vcpu_sve_max_vq(vcpu);
+}
+
+static void *buf_zreg(void *buf, int vq, int reg)
+{
+	return buf + __SVE_ZREG_OFFSET(vq, reg) - __SVE_ZREGS_OFFSET;
+}
+
+static void *buf_preg(void *buf, int vq, int reg)
+{
+	return buf + __SVE_PREG_OFFSET(vq, reg) - __SVE_ZREGS_OFFSET;
+}
+
+static void vcpu_rewrite_sve(struct kvm_vcpu *vcpu, int vq_in, int vq_out)
+{
+	void *new_buf;
+	int copy_size, i;
+
+	new_buf = kzalloc(vcpu_sve_state_size(vcpu), GFP_KERNEL);
+	if (!new_buf)
+		return;
+
+	if (WARN_ON_ONCE(vq_in == vq_out))
+		return;
+
+	/* Z registers */
+	if (vq_in < vq_out)
+		copy_size = vq_in * __SVE_VQ_BYTES;
+	else
+		copy_size = vq_out * __SVE_VQ_BYTES;
+
+	for (i = 0; i < SVE_NUM_ZREGS; i++)
+		memcpy(buf_zreg(new_buf, vq_out, i),
+		       buf_zreg(vcpu->arch.sve_state, vq_in, i),
+		       copy_size);
+
+	/* P and FFR, FFR is stored as an additional P */
+	copy_size /= 8;
+	for (i = 0; i <= SVE_NUM_PREGS; i++)
+		memcpy(buf_preg(new_buf, vq_out, i),
+		       buf_preg(vcpu->arch.sve_state, vq_in, i),
+		       copy_size);
+
+	/*
+	 * Ideally we would unmap the existing SVE buffer and remap
+	 * the new one.
+	 */
+	memcpy(vcpu->arch.sve_state, new_buf, vcpu_sve_state_size(vcpu));
+	kfree(new_buf);
+}
+
+/*
+ * If both SVE and SME are supported we present userspace with the SVE
+ * Z, P and FFR registers configured with the larger of the SVE and
+ * SME vector length, and if we have SME then even without SVE we
+ * present the V registers via Z.
+ */
+static void vcpu_fp_user_to_guest(struct kvm_vcpu *vcpu)
+{
+	if (likely(vcpu->arch.fp_state != FP_STATE_USER_OWNED))
+		return;
+
+	if (!vcpu_fp_user_format_needed(vcpu)) {
+		vcpu->arch.fp_state = FP_STATE_FREE;
+		return;
+	}
+
+	if (vcpu_has_sve(vcpu)) {
+		/*
+		 * The register state is stored in SVE format, rewrite
+		 * from the larger VL to the one the guest is
+		 * currently using.
+		 */
+		if (vcpu_active_vq(vcpu) != vcpu_max_vq(vcpu))
+			vcpu_rewrite_sve(vcpu, vcpu_max_vq(vcpu),
+					 vcpu_active_vq(vcpu));
+	} else {
+		/*
+		 * A FPSIMD only system will store non-streaming guest
+		 * state in FPSIMD format when running the guest but
+		 * present to userspace via the SVE regset.
+		 */
+		if (!vcpu_sm_active(vcpu))
+			__sve_to_fpsimd(&vcpu->arch.ctxt.fp_regs,
+					vcpu->arch.sve_state,
+					vcpu_sme_max_vq(vcpu));
+	}
+
+	vcpu->arch.fp_state = FP_STATE_FREE;
+}
+
+void vcpu_fp_guest_to_user(struct kvm_vcpu *vcpu)
+{
+	if (vcpu->arch.fp_state == FP_STATE_USER_OWNED)
+		return;
+
+	if (!vcpu_fp_user_format_needed(vcpu))
+		return;
+
+	if (vcpu_has_sve(vcpu)) {
+		/*
+		 * The register state is stored in SVE format, rewrite
+		 * to the largest VL.
+		 */
+		if (vcpu_active_vq(vcpu) != vcpu_max_vq(vcpu))
+			vcpu_rewrite_sve(vcpu, vcpu_active_vq(vcpu),
+					 vcpu_max_vq(vcpu));
+	} else {
+		/*
+		 * A FPSIMD only system will store non-streaming guest
+		 * state in FPSIMD format when running the guest but
+		 * present to userspace via the SVE regset, rewrite
+		 * with zero padding.
+		 */
+		if (!vcpu_sm_active(vcpu)) {
+			memset(vcpu->arch.sve_state, 0,
+			       vcpu_sve_state_size(vcpu));
+			__fpsimd_to_sve(vcpu->arch.sve_state,
+					&vcpu->arch.ctxt.fp_regs,
+					vcpu_sme_max_vq(vcpu));
+		}
+	}
+
+	vcpu->arch.fp_state = FP_STATE_USER_OWNED;
+}
+
 /*
  * Prepare vcpu for saving the host's FPSIMD state and loading the guest's.
  * The actual loading is done by the FPSIMD access trap taken to hyp.
@@ -81,6 +252,8 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
 
 	fpsimd_kvm_prepare();
 
+	vcpu_fp_user_to_guest(vcpu);
+
 	/*
 	 * We will check TIF_FOREIGN_FPSTATE just before entering the
 	 * guest in kvm_arch_vcpu_ctxflush_fp() and override this to
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 1d161fa7c2be..5f2845625c55 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -110,9 +110,9 @@ static int core_reg_size_from_offset(const struct kvm_vcpu *vcpu, u64 off)
 	/*
 	 * The KVM_REG_ARM64_SVE regs must be used instead of
 	 * KVM_REG_ARM_CORE for accessing the FPSIMD V-registers on
-	 * SVE-enabled vcpus:
+	 * SVE or SME enabled vcpus:
 	 */
-	if (vcpu_has_sve(vcpu) && core_reg_offset_is_vreg(off))
+	if (vcpu_has_vec(vcpu) && core_reg_offset_is_vreg(off))
 		return -EINVAL;
 
 	return size;
@@ -462,20 +462,20 @@ static int sve_reg_to_region(struct vec_state_reg_region *region,
 	reg_num = (reg->id & SVE_REG_ID_MASK) >> SVE_REG_ID_SHIFT;
 
 	if (reg->id >= zreg_id_min && reg->id <= zreg_id_max) {
-		if (!vcpu_has_sve(vcpu) || (reg->id & SVE_REG_SLICE_MASK) > 0)
+		if (!vcpu_has_vec(vcpu) || (reg->id & SVE_REG_SLICE_MASK) > 0)
 			return -ENOENT;
 
-		vq = vcpu_sve_max_vq(vcpu);
+		vq = vcpu_max_vq(vcpu);
 
 		reqoffset = SVE_SIG_ZREG_OFFSET(vq, reg_num) -
 				SVE_SIG_REGS_OFFSET;
 		reqlen = KVM_SVE_ZREG_SIZE;
 		maxlen = SVE_SIG_ZREG_SIZE(vq);
 	} else if (reg->id >= preg_id_min && reg->id <= preg_id_max) {
-		if (!vcpu_has_sve(vcpu) || (reg->id & SVE_REG_SLICE_MASK) > 0)
+		if (!vcpu_has_vec(vcpu) || (reg->id & SVE_REG_SLICE_MASK) > 0)
 			return -ENOENT;
 
-		vq = vcpu_sve_max_vq(vcpu);
+		vq = vcpu_max_vq(vcpu);
 
 		reqoffset = SVE_SIG_PREG_OFFSET(vq, reg_num) -
 				SVE_SIG_REGS_OFFSET;
@@ -514,6 +514,8 @@ static int get_sve_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	if (!kvm_arm_vcpu_vec_finalized(vcpu))
 		return -EPERM;
 
+	vcpu_fp_guest_to_user(vcpu);
+
 	if (copy_to_user(uptr, vcpu->arch.sve_state + region.koffset,
 			 region.klen) ||
 	    clear_user(uptr + region.klen, region.upad))
@@ -540,6 +542,8 @@ static int set_sve_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	if (!kvm_arm_vcpu_vec_finalized(vcpu))
 		return -EPERM;
 
+	vcpu_fp_guest_to_user(vcpu);
+
 	if (copy_from_user(vcpu->arch.sve_state + region.koffset, uptr,
 			   region.klen))
 		return -EFAULT;

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:26 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:26 +0000
Subject: [PATCH RFC v2 18/22] KVM: arm64: Expose ZA to userspace
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-18-da226cb180bb@kernel.org>

The SME ZA matrix is a single SVL*SVL register which is available when
PSTATE.ZA is set. We follow the pattern established by the architecture
itself and expose this to userspace as a series of horizontal SVE vectors
with the streaming mode vector length, using the format already established
for the SVE vectors themselves.

For the purposes of exporting to userspace we ignore the value of
PSTATE.ZA, if PSTATE.ZA is clear when the guest is run then the guest will
need to set it to access ZA which would cause the value to be cleared. If
userspace reads ZA when PSTATE.ZA is clear then it will read whatever stale
data was last saved. This removes ordering requirements from userspace,
minimising the need to special case.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h | 14 ++++++
 arch/arm64/include/uapi/asm/kvm.h | 15 +++++++
 arch/arm64/kvm/guest.c            | 95 ++++++++++++++++++++++++++++++++++++++-
 3 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index a5ed0433edc6..a1aa9471084d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -846,6 +846,20 @@ void vcpu_fp_guest_to_user(struct kvm_vcpu *vcpu);
 	__size_ret;							\
 })
 
+#define vcpu_sme_state_size(vcpu) ({					\
+	size_t __size_ret;						\
+	unsigned int __vcpu_vq;						\
+									\
+	if (WARN_ON(!sve_vl_valid((vcpu)->arch.max_vl[ARM64_VEC_SME]))) { \
+		__size_ret = 0;						\
+	} else {							\
+		__vcpu_vq = vcpu_sme_max_vq(vcpu);			\
+		__size_ret = ZA_SIG_REGS_SIZE(__vcpu_vq);		\
+	}								\
+									\
+	__size_ret;							\
+})
+
 /*
  * Only use __vcpu_sys_reg/ctxt_sys_reg if you know you want the
  * memory backed version of a register, and not the one most recently
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 02642bb96496..00fb2ea4c057 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -356,6 +356,21 @@ struct kvm_arm_counter_offset {
 /* SME registers */
 #define KVM_REG_ARM64_SME		(0x17 << KVM_REG_ARM_COPROC_SHIFT)
 
+#define KVM_ARM64_SME_VQ_MIN __SVE_VQ_MIN
+#define KVM_ARM64_SME_VQ_MAX __SVE_VQ_MAX
+
+/* ZA and ZTn occupy blocks at the following offsets within this range: */
+#define KVM_REG_ARM64_SME_ZA_BASE	0
+#define KVM_REG_ARM64_SME_ZT_BASE	0x600
+
+#define KVM_ARM64_SME_MAX_ZAHREG	(__SVE_VQ_BYTES * KVM_ARM64_SME_VQ_MAX)
+
+#define KVM_REG_ARM64_SME_ZAHREG(n, i)					\
+	(KVM_REG_ARM64 | KVM_REG_ARM64_SME | KVM_REG_ARM64_SME_ZA_BASE | \
+	 KVM_REG_SIZE_U2048 |						\
+	 (((n) & (KVM_ARM64_SME_MAX_ZAHREG - 1)) << 5) |		\
+	 ((i) & (KVM_ARM64_SVE_MAX_SLICES - 1)))
+
 /* Vector lengths pseudo-register: */
 #define KVM_REG_ARM64_SME_VLS		(KVM_REG_ARM64 | KVM_REG_ARM64_SME | \
 					 KVM_REG_SIZE_U512 | 0xffff)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 5f2845625c55..cb38af891387 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -573,22 +573,113 @@ static int set_sme_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	return set_vec_vls(ARM64_VEC_SME, vcpu, reg);
 }
 
+/*
+ * Validate SVE register ID and get sanitised bounds for user/kernel SVE
+ * register copy
+ */
+static int sme_reg_to_region(struct vec_state_reg_region *region,
+			     struct kvm_vcpu *vcpu,
+			     const struct kvm_one_reg *reg)
+{
+	/* reg ID ranges for ZA.H[n] registers */
+	unsigned int vq = vcpu_sme_max_vq(vcpu) - 1;
+	const u64 za_h_max = vq * __SVE_VQ_BYTES;
+	const u64 zah_id_min = KVM_REG_ARM64_SME_ZAHREG(0, 0);
+	const u64 zah_id_max = KVM_REG_ARM64_SME_ZAHREG(za_h_max - 1,
+						       SVE_NUM_SLICES - 1);
+
+	unsigned int reg_num;
+
+	unsigned int reqoffset, reqlen; /* User-requested offset and length */
+	unsigned int maxlen; /* Maximum permitted length */
+
+	size_t sme_state_size;
+
+	reg_num = (reg->id & SVE_REG_ID_MASK) >> SVE_REG_ID_SHIFT;
+
+	if (reg->id >= zah_id_min && reg->id <= zah_id_max) {
+		/* ZA is exposed as SVE vectors ZA.H[n] */
+		if (!vcpu_has_sme(vcpu) || (reg->id & SVE_REG_SLICE_MASK) > 0)
+			return -ENOENT;
+
+		reqoffset = ZA_SIG_ZAV_OFFSET(vq, reg_num) -
+			ZA_SIG_REGS_OFFSET;
+		reqlen = KVM_SVE_ZREG_SIZE;
+		maxlen = SVE_SIG_ZREG_SIZE(vq);
+	} else {
+		return -EINVAL;
+	}
+
+	sme_state_size = vcpu_sme_state_size(vcpu);
+	if (WARN_ON(!sme_state_size))
+		return -EINVAL;
+
+	region->koffset = array_index_nospec(reqoffset, sme_state_size);
+	region->klen = min(maxlen, reqlen);
+	region->upad = reqlen - region->klen;
+
+	return 0;
+}
+
+/*
+ * ZA is exposed as an array of horizontal vectors with the same
+ * format as SVE, mirroring the architecture's LDR ZA[Wv, offs], [Xn]
+ * instruction.
+ */
+
 static int get_sme_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 {
+	int ret;
+	struct vec_state_reg_region region;
+	char __user *uptr = (char __user *)reg->addr;
+
 	/* Handle the KVM_REG_ARM64_SME_VLS pseudo-reg as a special case: */
 	if (reg->id == KVM_REG_ARM64_SME_VLS)
 		return get_sme_vls(vcpu, reg);
 
-	return -EINVAL;
+	/* Try to interpret reg ID as an architectural SVE register... */
+	ret = sme_reg_to_region(&region, vcpu, reg);
+	if (ret)
+		return ret;
+
+	/* Try to interpret reg ID as an architectural SVE register... */
+	ret = sme_reg_to_region(&region, vcpu, reg);
+	if (ret)
+		return ret;
+
+	if (!kvm_arm_vcpu_vec_finalized(vcpu))
+		return -EPERM;
+
+	if (copy_from_user(vcpu->arch.sme_state + region.koffset, uptr,
+			   region.klen))
+		return -EFAULT;
+
+	return 0;
 }
 
 static int set_sme_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 {
+	int ret;
+	struct vec_state_reg_region region;
+	char __user *uptr = (char __user *)reg->addr;
+
 	/* Handle the KVM_REG_ARM64_SME_VLS pseudo-reg as a special case: */
 	if (reg->id == KVM_REG_ARM64_SME_VLS)
 		return set_sme_vls(vcpu, reg);
 
-	return -EINVAL;
+	/* Try to interpret reg ID as an architectural SVE register... */
+	ret = sme_reg_to_region(&region, vcpu, reg);
+	if (ret)
+		return ret;
+
+	if (!kvm_arm_vcpu_vec_finalized(vcpu))
+		return -EPERM;
+
+	if (copy_from_user(vcpu->arch.sme_state + region.koffset, uptr,
+			   region.klen))
+		return -EFAULT;
+
+	return 0;
 }
 int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 {

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:27 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:27 +0000
Subject: [PATCH RFC v2 19/22] KVM: arm64: Provide userspace access to ZT0
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-19-da226cb180bb@kernel.org>

ZT0 is a single register with a refreshingly fixed size 512 bit register
which is like ZA accessible only when PSTATE.ZA is set. Add support for it
to the userspace API, as with ZA we allow the regster to be read or written
regardless of the state of PSTATE.ZA in order to simplify userspace usage.
The value will be reset to 0 whenever PSTATE.ZA changes from 0 to 1,
userspace can read stale values but these are not observable by the guest
without manipulation of PSTATE.ZA by userspace.

While there is currently only one ZT register the naming as ZT0 and the
instruction encoding clearly leave room for future extensions adding more
ZT registers. This encoding can readily support such an extension if one is
introduced.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h |  2 ++
 arch/arm64/include/uapi/asm/kvm.h |  2 ++
 arch/arm64/kvm/guest.c            | 13 +++++++++++--
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index a1aa9471084d..6a5002ab8042 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -855,6 +855,8 @@ void vcpu_fp_guest_to_user(struct kvm_vcpu *vcpu);
 	} else {							\
 		__vcpu_vq = vcpu_sme_max_vq(vcpu);			\
 		__size_ret = ZA_SIG_REGS_SIZE(__vcpu_vq);		\
+		if (system_supports_sme2())				\
+			__size_ret += ZT_SIG_REG_SIZE;			\
 	}								\
 									\
 	__size_ret;							\
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 00fb2ea4c057..58640aeb88e4 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -371,6 +371,8 @@ struct kvm_arm_counter_offset {
 	 (((n) & (KVM_ARM64_SME_MAX_ZAHREG - 1)) << 5) |		\
 	 ((i) & (KVM_ARM64_SVE_MAX_SLICES - 1)))
 
+#define KVM_REG_ARM64_SME_ZTREG_SIZE	(512 / 8)
+
 /* Vector lengths pseudo-register: */
 #define KVM_REG_ARM64_SME_VLS		(KVM_REG_ARM64 | KVM_REG_ARM64_SME | \
 					 KVM_REG_SIZE_U512 | 0xffff)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index cb38af891387..fba5ff377b8b 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -587,7 +587,6 @@ static int sme_reg_to_region(struct vec_state_reg_region *region,
 	const u64 zah_id_min = KVM_REG_ARM64_SME_ZAHREG(0, 0);
 	const u64 zah_id_max = KVM_REG_ARM64_SME_ZAHREG(za_h_max - 1,
 						       SVE_NUM_SLICES - 1);
-
 	unsigned int reg_num;
 
 	unsigned int reqoffset, reqlen; /* User-requested offset and length */
@@ -598,14 +597,24 @@ static int sme_reg_to_region(struct vec_state_reg_region *region,
 	reg_num = (reg->id & SVE_REG_ID_MASK) >> SVE_REG_ID_SHIFT;
 
 	if (reg->id >= zah_id_min && reg->id <= zah_id_max) {
-		/* ZA is exposed as SVE vectors ZA.H[n] */
 		if (!vcpu_has_sme(vcpu) || (reg->id & SVE_REG_SLICE_MASK) > 0)
 			return -ENOENT;
 
+		/* ZA is exposed as SVE vectors ZA.H[n] */
 		reqoffset = ZA_SIG_ZAV_OFFSET(vq, reg_num) -
 			ZA_SIG_REGS_OFFSET;
 		reqlen = KVM_SVE_ZREG_SIZE;
 		maxlen = SVE_SIG_ZREG_SIZE(vq);
+	} if (reg->id == KVM_REG_ARM64_SME_ZT_BASE) {
+		/* ZA is exposed as SVE vectors ZA.H[n] */
+		if (!vcpu_has_sme2(vcpu) ||
+		    (reg->id & SVE_REG_SLICE_MASK) > 0 ||
+		    reg_num > 0)
+			return -ENOENT;
+
+		/* ZT0 is stored after ZA */
+		reqlen = KVM_REG_ARM64_SME_ZTREG_SIZE;
+		maxlen = KVM_REG_ARM64_SME_ZTREG_SIZE;
 	} else {
 		return -EINVAL;
 	}

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:28 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:28 +0000
Subject: [PATCH RFC v2 20/22] KVM: arm64: Support SME version configuration
 via ID registers
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-20-da226cb180bb@kernel.org>

As well as a substantial set of features which provide additional
instructions there are also two current extensions which add new
architectural state, SME2 (which adds ZT) and FA64 (which makes
FFR valid in streaming mode SVE). Allow all of these to be
configured through writes to the ID registers.

At present the guest support for SME2 and FA64 does not use the values
configured here pending clarity on the approach to be taken generally
with regards to parsing supported features from ID registers.

We always allocate state for the new architectural state which might be
enabled if the host supports it, in the case of FFR this simplifies the
already fiddly allocation and is needed when SVE is also supported. In
the case of ZT the register is 64 bytes which is not completely trivial
(though not so much relative to the other SME state) but it is not
expected that there will be many practical users that want SME1 only so
it is expected that guests with SME1 only would not be common enough to
justify the complication of handling this. If this proves to be a
problem we can improve things incrementally.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/kvm/sys_regs.c | 30 ++++++++++++++++++++++--------
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f908aa3fb606..1ea658615467 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1412,13 +1412,6 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu,
 	val = read_sanitised_ftr_reg(id);
 
 	switch (id) {
-	case SYS_ID_AA64PFR1_EL1:
-		if (!kvm_has_mte(vcpu->kvm))
-			val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
-
-		if (!vcpu_has_sme(vcpu))
-			val &= ~ID_AA64PFR1_EL1_SME_MASK;
-		break;
 	case SYS_ID_AA64ISAR1_EL1:
 		if (!vcpu_has_ptrauth(vcpu))
 			val &= ~(ARM64_FEATURE_MASK(ID_AA64ISAR1_EL1_APA) |
@@ -1582,6 +1575,20 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
 	return val;
 }
 
+static u64 read_sanitised_id_aa64pfr1_el1(struct kvm_vcpu *vcpu,
+					  const struct sys_reg_desc *rd)
+{
+	u64 val = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1);
+
+	if (!vcpu_has_sme(vcpu))
+		val &= ~ID_AA64PFR1_EL1_SME_MASK;
+
+	if (!kvm_has_mte(vcpu->kvm))
+		val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
+
+	return val;
+}
+
 #define ID_REG_LIMIT_FIELD_ENUM(val, reg, field, limit)			       \
 ({									       \
 	u64 __f_val = FIELD_GET(reg##_##field##_MASK, val);		       \
@@ -2164,7 +2171,14 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 		   ID_AA64PFR0_EL1_GIC |
 		   ID_AA64PFR0_EL1_AdvSIMD |
 		   ID_AA64PFR0_EL1_FP), },
-	ID_SANITISED(ID_AA64PFR1_EL1),
+	{ SYS_DESC(SYS_ID_AA64PFR1_EL1),
+	  .access = access_id_reg,
+	  .get_user = get_id_reg,
+	  .set_user = set_id_reg,
+	  .reset = read_sanitised_id_aa64pfr1_el1,
+	  .val = ~(ID_AA64PFR1_EL1_MPAM_frac |
+		   ID_AA64PFR1_EL1_RAS_frac |
+		   ID_AA64PFR1_EL1_MTE), },
 	ID_UNALLOCATED(4,2),
 	ID_UNALLOCATED(4,3),
 	ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0),

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:29 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:29 +0000
Subject: [PATCH RFC v2 21/22] KVM: arm64: Provide userspace ABI for
 enabling SME
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-21-da226cb180bb@kernel.org>

Now that everything else is in place allow userspace to enable SME with a
vCPU flag KVM_ARM_VCPU_SME similar to that for SVE, finalized with the
same KVM_ARM_VCPU_VEC/SVE flag used for SVE.

As with SVE when when SME feature is enabled we default the vector
length to the highest vector length that can be exposed to guests
without them being able to observe inconsistencies between the set of
supported vector lengths on processors, discovering this during host SME
enumeration.

When the vectors are finalised we allocate state for both SVE and SME.

Currently SME2 and FA64 are enabled for the guest if supported by the
host, once it is clear how we intend to handle parsing features from ID
registers these features should be handled based on the configured ID
registers.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/kvm_host.h |   3 +-
 arch/arm64/include/uapi/asm/kvm.h |   1 +
 arch/arm64/kernel/fpsimd.c        |  28 +++++++++
 arch/arm64/kvm/arm.c              |   7 +++
 arch/arm64/kvm/reset.c            | 120 +++++++++++++++++++++++++++++++++-----
 include/uapi/linux/kvm.h          |   1 +
 6 files changed, 145 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 6a5002ab8042..c054aee8160a 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -38,7 +38,7 @@
 
 #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
 
-#define KVM_VCPU_MAX_FEATURES 7
+#define KVM_VCPU_MAX_FEATURES 8
 #define KVM_VCPU_VALID_FEATURES	(BIT(KVM_VCPU_MAX_FEATURES) - 1)
 
 #define KVM_REQ_SLEEP \
@@ -76,6 +76,7 @@ DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
 
 extern unsigned int __ro_after_init kvm_vec_max_vl[ARM64_VEC_MAX];
 int __init kvm_arm_init_sve(void);
+int __init kvm_arm_init_sme(void);
 
 u32 __attribute_const__ kvm_target_cpu(void);
 void kvm_reset_vcpu(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 58640aeb88e4..0f5e678c3ef3 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -110,6 +110,7 @@ struct kvm_regs {
 #define KVM_ARM_VCPU_PTRAUTH_ADDRESS	5 /* VCPU uses address authentication */
 #define KVM_ARM_VCPU_PTRAUTH_GENERIC	6 /* VCPU uses generic authentication */
 #define KVM_ARM_VCPU_HAS_EL2		7 /* Support nested virtualization */
+#define KVM_ARM_VCPU_SME		8 /* enable SME for this CPU */
 
 /*
  * An alias for _SVE since we finalize VL configuration for both SVE and SME
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index e6a4dd68f62a..05e806a580f0 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -1307,6 +1307,8 @@ void __init sme_setup(void)
 {
 	struct vl_info *info = &vl_info[ARM64_VEC_SME];
 	int min_bit, max_bit;
+	DECLARE_BITMAP(tmp_map, SVE_VQ_MAX);
+	unsigned long b;
 
 	if (!cpus_have_cap(ARM64_SME))
 		return;
@@ -1342,6 +1344,32 @@ void __init sme_setup(void)
 		info->max_vl);
 	pr_info("SME: default vector length %u bytes per vector\n",
 		get_sme_default_vl());
+
+	/*
+	 * KVM can't cope with any mismatch in supported VLs between
+	 * CPUs, detect any inconsistencies.  Unlike SVE it is
+	 * architecturally possible to end up with no VLs.
+	 */
+	bitmap_andnot(tmp_map, info->vq_partial_map, info->vq_map,
+		      SVE_VQ_MAX);
+
+	b = find_last_bit(tmp_map, SVE_VQ_MAX);
+	if (b >= SVE_VQ_MAX)
+		/* No non-virtualisable VLs found */
+		info->max_virtualisable_vl = SVE_VQ_MAX;
+	else if (WARN_ON(b == SVE_VQ_MAX - 1))
+		/* No virtualisable VLs?  Architecturally possible... */
+		info->max_virtualisable_vl = 0;
+	else /* b + 1 < SVE_VQ_MAX */
+		info->max_virtualisable_vl = sve_vl_from_vq(__bit_to_vq(b + 1));
+
+	if (info->max_virtualisable_vl > info->max_vl)
+		info->max_virtualisable_vl = info->max_vl;
+
+	/* KVM decides whether to support mismatched systems. Just warn here: */
+	if (sve_max_virtualisable_vl() < sve_max_vl())
+		pr_warn("%s: unvirtualisable vector lengths present\n",
+			info->name);
 }
 
 #endif /* CONFIG_ARM64_SME */
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index aa7e2031263c..baa4a8074aaf 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -305,6 +305,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_ARM_SVE:
 		r = system_supports_sve();
 		break;
+	case KVM_CAP_ARM_SME:
+		r = system_supports_sme();
+		break;
 	case KVM_CAP_ARM_PTRAUTH_ADDRESS:
 	case KVM_CAP_ARM_PTRAUTH_GENERIC:
 		r = system_has_full_ptr_auth();
@@ -2559,6 +2562,10 @@ static __init int kvm_arm_init(void)
 	if (err)
 		return err;
 
+	err = kvm_arm_init_sme();
+	if (err)
+		return err;
+
 	err = kvm_arm_vmid_alloc_init();
 	if (err) {
 		kvm_err("Failed to initialize VMID allocator.\n");
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index ab7cd657a73c..56fc91cd8567 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -85,42 +85,125 @@ static void kvm_vcpu_enable_sve(struct kvm_vcpu *vcpu)
 	vcpu_set_flag(vcpu, GUEST_HAS_SVE);
 }
 
+int __init kvm_arm_init_sme(void)
+{
+	if (system_supports_sme()) {
+		kvm_vec_max_vl[ARM64_VEC_SME] = sme_max_virtualisable_vl();
+
+		/*
+		 * The get_sve_reg()/set_sve_reg() ioctl interface will need
+		 * to be extended with multiple register slice support in
+		 * order to support vector lengths greater than
+		 * VL_ARCH_MAX:
+		 */
+		if (WARN_ON(kvm_vec_max_vl[ARM64_VEC_SME] > VL_ARCH_MAX))
+			kvm_vec_max_vl[ARM64_VEC_SME] = VL_ARCH_MAX;
+
+		/*
+		 * Don't even try to make use of vector lengths that
+		 * aren't available on all CPUs, for now:
+		 */
+		if (kvm_vec_max_vl[ARM64_VEC_SME] < sme_max_vl())
+			pr_warn("KVM: SME vector length for guests limited to %u bytes\n",
+				kvm_vec_max_vl[ARM64_VEC_SME]);
+	}
+
+	return 0;
+}
+
+static int kvm_vcpu_enable_sme(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.max_vl[ARM64_VEC_SME] = kvm_vec_max_vl[ARM64_VEC_SME];
+
+	/*
+	 * Userspace can still customize the vector lengths by writing
+	 * KVM_REG_ARM64_SME_VLS.  Allocation is deferred until
+	 * kvm_arm_vcpu_finalize(), which freezes the configuration.
+	 */
+	vcpu_set_flag(vcpu, GUEST_HAS_SME);
+
+	return 0;
+}
+
+
 /*
- * Finalize vcpu's maximum SVE vector length, allocating
- * vcpu->arch.sve_state as necessary.
+ * Finalize vcpu's maximum SVE/SME vector lengths, allocating
+ * vcpu->arch.sve_state and vcpu->arch.sme_state as necessary.
  */
 static int kvm_vcpu_finalize_vec(struct kvm_vcpu *vcpu)
 {
-	void *buf;
 	unsigned int vl;
-	size_t reg_sz;
+	void *sve_buf, *sme_buf;
+	size_t sve_sz, sme_sz;
 	int ret;
 
-	vl = vcpu->arch.max_vl[ARM64_VEC_SVE];
+	/* Both SVE and SME need the SVE state */
 
-	/*
+        /*
 	 * Responsibility for these properties is shared between
 	 * kvm_arm_init_sve(), kvm_vcpu_enable_sve() and
 	 * set_sve_vls().  Double-check here just to be sure:
 	 */
+	vl = vcpu->arch.max_vl[ARM64_VEC_SVE];
 	if (WARN_ON(!sve_vl_valid(vl) || vl > sve_max_virtualisable_vl() ||
 		    vl > VL_ARCH_MAX))
 		return -EIO;
 
-	reg_sz = vcpu_sve_state_size(vcpu);
-	buf = kzalloc(reg_sz, GFP_KERNEL_ACCOUNT);
-	if (!buf)
+	sve_sz = vcpu_sve_state_size(vcpu);
+	sve_buf = kzalloc(sve_sz, GFP_KERNEL_ACCOUNT);
+	if (!sve_buf)
 		return -ENOMEM;
 
-	ret = kvm_share_hyp(buf, buf + reg_sz);
+	ret = kvm_share_hyp(sve_buf, sve_buf + sve_sz);
 	if (ret) {
-		kfree(buf);
+		kfree(sve_buf);
 		return ret;
 	}
+
+	if (vcpu_has_sme(vcpu)) {
+		vl = vcpu->arch.max_vl[ARM64_VEC_SME];
+		if (WARN_ON(!sve_vl_valid(vl) ||
+			    vl > sme_max_virtualisable_vl() ||
+			    vl > VL_ARCH_MAX)) {
+			ret = -EIO;
+			goto free_sve;
+		}
+
+		sme_sz = vcpu_sme_state_size(vcpu);
+		sme_buf = kzalloc(sme_sz, GFP_KERNEL_ACCOUNT);
+		if (!sme_buf) {
+			ret = -ENOMEM;
+			goto free_sve;
+		}
+
+		ret = kvm_share_hyp(sme_buf, sme_buf + sme_sz);
+		if (ret) {
+			kfree(sme_buf);
+			goto free_sve;
+		}
+
+		vcpu->arch.sme_state = sme_buf;
+
+		/*
+		 * These are expected to be parsed from ID registers
+		 * once the general approach to doing that is worked
+		 * out.
+		 */
+		if (system_supports_sme2())
+			vcpu_set_flag(vcpu, GUEST_HAS_SME2);
+		if (system_supports_fa64())
+			vcpu_set_flag(vcpu, GUEST_HAS_FA64);
+	}
 	
-	vcpu->arch.sve_state = buf;
+	vcpu->arch.sve_state = sve_buf;
+
 	vcpu_set_flag(vcpu, VCPU_VEC_FINALIZED);
 	return 0;
+
+free_sve:
+	kvm_unshare_hyp(sve_buf, sve_buf + sve_sz);
+	kfree(sve_buf);
+	return ret;
 }
 
 int kvm_arm_vcpu_finalize(struct kvm_vcpu *vcpu, int feature)
@@ -150,19 +233,25 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu)
 void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu)
 {
 	void *sve_state = vcpu->arch.sve_state;
+	void *sme_state = vcpu->arch.sme_state;
 
 	kvm_vcpu_unshare_task_fp(vcpu);
 	kvm_unshare_hyp(vcpu, vcpu + 1);
 	if (sve_state)
 		kvm_unshare_hyp(sve_state, sve_state + vcpu_sve_state_size(vcpu));
 	kfree(sve_state);
+	if (sme_state)
+		kvm_unshare_hyp(sme_state, sme_state + vcpu_sme_state_size(vcpu));
+	kfree(sme_state);
 	kfree(vcpu->arch.ccsidr);
 }
 
-static void kvm_vcpu_reset_sve(struct kvm_vcpu *vcpu)
+static void kvm_vcpu_reset_vec(struct kvm_vcpu *vcpu)
 {
 	if (vcpu_has_sve(vcpu))
 		memset(vcpu->arch.sve_state, 0, vcpu_sve_state_size(vcpu));
+	if (vcpu_has_sme(vcpu))
+		memset(vcpu->arch.sme_state, 0, vcpu_sme_state_size(vcpu));
 }
 
 static void kvm_vcpu_enable_ptrauth(struct kvm_vcpu *vcpu)
@@ -210,8 +299,11 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	if (!kvm_arm_vcpu_vec_finalized(vcpu)) {
 		if (vcpu_has_feature(vcpu, KVM_ARM_VCPU_SVE))
 			kvm_vcpu_enable_sve(vcpu);
+
+		if (vcpu_has_feature(vcpu, KVM_ARM_VCPU_SME))
+			kvm_vcpu_enable_sme(vcpu);
 	} else {
-		kvm_vcpu_reset_sve(vcpu);
+		kvm_vcpu_reset_vec(vcpu);
 	}
 
 	if (vcpu_has_feature(vcpu, KVM_ARM_VCPU_PTRAUTH_ADDRESS) ||
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 211b86de35ac..42484c0a9051 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1201,6 +1201,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE 228
 #define KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES 229
 #define KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES 230
+#define KVM_CAP_ARM_SME 231
 
 #ifdef KVM_CAP_IRQ_ROUTING
 

-- 
2.30.2



From broonie at kernel.org  Fri Dec 22 08:21:30 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 22 Dec 2023 16:21:30 +0000
Subject: [PATCH RFC v2 22/22] KVM: arm64: selftests: Add SME system
 registers to get-reg-list
In-Reply-To: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
References: <20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.org>
Message-ID: <20231222-kvm-arm64-sme-v2-22-da226cb180bb@kernel.org>

SME adds a number of new system registers, update get-reg-list to check for
them based on the visibility of SME.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 tools/testing/selftests/kvm/aarch64/get-reg-list.c | 32 +++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index 709d7d721760..a1c2853388b6 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -23,6 +23,18 @@ struct feature_id_reg {
 };
 
 static struct feature_id_reg feat_id_regs[] = {
+	{
+		ARM64_SYS_REG(3, 0, 1, 2, 4),	/* SMPRI_EL1 */
+		ARM64_SYS_REG(3, 0, 0, 4, 1),	/* ID_AA64PFR1_EL1 */
+		24,
+		1
+	},
+	{
+		ARM64_SYS_REG(3, 0, 1, 2, 6),	/* SMCR_EL1 */
+		ARM64_SYS_REG(3, 0, 0, 4, 1),	/* ID_AA64PFR1_EL1 */
+		24,
+		1
+	},
 	{
 		ARM64_SYS_REG(3, 0, 2, 0, 3),	/* TCR2_EL1 */
 		ARM64_SYS_REG(3, 0, 0, 7, 3),	/* ID_AA64MMFR3_EL1 */
@@ -40,7 +52,25 @@ static struct feature_id_reg feat_id_regs[] = {
 		ARM64_SYS_REG(3, 0, 0, 7, 3),	/* ID_AA64MMFR3_EL1 */
 		4,
 		1
-	}
+	},
+	{
+		ARM64_SYS_REG(3, 1, 0, 0, 6),	/* SMIDR_EL1 */
+		ARM64_SYS_REG(3, 0, 0, 4, 1),	/* ID_AA64PFR1_EL1 */
+		24,
+		1
+	},
+	{
+		ARM64_SYS_REG(3, 3, 4, 2, 2),	/* SVCR */
+		ARM64_SYS_REG(3, 0, 0, 4, 1),	/* ID_AA64PFR1_EL1 */
+		24,
+		1
+	},
+	{
+		ARM64_SYS_REG(3, 3, 13, 0, 5),	/* TPIDR2_EL0 */
+		ARM64_SYS_REG(3, 0, 0, 4, 1),	/* ID_AA64PFR1_EL1 */
+		24,
+		1
+	},
 };
 
 bool filter_reg(__u64 reg)

-- 
2.30.2



From cristian.marussi at arm.com  Fri Dec 22 08:26:22 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 22 Dec 2023 16:26:22 +0000
Subject: [PATCH 5/7] firmware: arm_scmi: Add SCMI v3.2 pincontrol
 protocol basic support
In-Reply-To: <20231215-pinctrl-scmi-v1-5-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-5-0fe35e4611f7@nxp.com>
Message-ID: <ZYW4rgVoh5uOo6g_@pluto>

On Fri, Dec 15, 2023 at 07:56:33PM +0800, Peng Fan (OSS) wrote:
> From: Oleksii Moisieiev <Oleksii_Moisieiev at epam.com>
> 
> Add basic implementation of the SCMI v3.2 pincontrol protocol.
> 
> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev at epam.com>
> Co-developed-by: Peng Fan <peng.fan at nxp.com>
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  MAINTAINERS                           |   6 +
>  drivers/firmware/arm_scmi/Makefile    |   1 +
>  drivers/firmware/arm_scmi/driver.c    |   2 +
>  drivers/firmware/arm_scmi/pinctrl.c   | 927 ++++++++++++++++++++++++++++++++++
>  drivers/firmware/arm_scmi/protocols.h |   1 +
>  include/linux/scmi_protocol.h         |  46 ++
>  6 files changed, 983 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b589218605b4..8d971adeee22 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21180,6 +21180,12 @@ F:	include/linux/sc[mp]i_protocol.h
>  F:	include/trace/events/scmi.h
>  F:	include/uapi/linux/virtio_scmi.h
>  
> +SYSTEM CONTROL MANAGEMENT INTERFACE (SCMI) PINCTRL DRIVER
> +M:	Oleksii Moisieiev <oleksii_moisieiev at epam.com>
> +L:	linux-arm-kernel at lists.infradead.org
> +S:	Maintained
> +F:	drivers/firmware/arm_scmi/pinctrl.c
> +
>  SYSTEM RESET/SHUTDOWN DRIVERS
>  M:	Sebastian Reichel <sre at kernel.org>
>  L:	linux-pm at vger.kernel.org
> diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile
> index a7bc4796519c..8e3874ff1544 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -11,6 +11,7 @@ scmi-transport-$(CONFIG_ARM_SCMI_HAVE_MSG) += msg.o
>  scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o
>  scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o
>  scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o system.o voltage.o powercap.o
> +scmi-protocols-y += pinctrl.o
>  scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y)
>  
>  obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 3174da57d832..1cf9f5d4f7bd 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -3057,6 +3057,7 @@ static int __init scmi_driver_init(void)
>  	scmi_voltage_register();
>  	scmi_system_register();
>  	scmi_powercap_register();
> +	scmi_pinctrl_register();
>  
>  	return platform_driver_register(&scmi_driver);
>  }
> @@ -3074,6 +3075,7 @@ static void __exit scmi_driver_exit(void)
>  	scmi_voltage_unregister();
>  	scmi_system_unregister();
>  	scmi_powercap_unregister();
> +	scmi_pinctrl_unregister();
>  
>  	scmi_transports_exit();
>  
> diff --git a/drivers/firmware/arm_scmi/pinctrl.c b/drivers/firmware/arm_scmi/pinctrl.c
> new file mode 100644
> index 000000000000..a25c8edcedd2
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/pinctrl.c
> @@ -0,0 +1,927 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * System Control and Management Interface (SCMI) Pinctrl Protocol
> + *
> + * Copyright (C) 2023 EPAM
> + */
> +
> +#include <linux/module.h>
> +#include <linux/pinctrl/pinconf-generic.h>

I spotted this only later while looking at the SCMI Pinctrl driver...

...Get rid of this and please make these conversions in the SCMI pinctrl driver
NOT here in the protocol layer....these ops should receive SCMI valid requests
and should not have any need to invoke some other subsystem helpers to
pack/unpack.

See below..


> +#include <linux/scmi_protocol.h>
> +#include <linux/slab.h>

[snip]

> +
> +static int scmi_pinctrl_config_set(const struct scmi_protocol_handle *ph,
> +				   u32 selector,
> +				   enum scmi_pinctrl_selector_type type,
> +				   unsigned long *configs, unsigned int nr_configs)
> +{
> +	struct scmi_xfer *t;
> +	struct scmi_msg_conf_set *tx;
> +	u32 attributes;
> +	int ret, i;
> +	unsigned int configs_in_chunk, conf_num = 0;
> +	unsigned int chunk;
> +	int max_msg_size = ph->hops->get_max_msg_size(ph);
> +
> +	if (!configs || type == FUNCTION_TYPE)
> +		return -EINVAL;
> +
> +	ret = scmi_pinctrl_validate_id(ph, selector, type);
> +	if (ret)
> +		return ret;
> +
> +	configs_in_chunk = (max_msg_size - sizeof(*tx)) / (sizeof(unsigned long) * 2);
									^^
									sizeof(__le32))
> +	while (conf_num < nr_configs) {
> +		chunk = (nr_configs - conf_num > configs_in_chunk) ? configs_in_chunk :
> +			nr_configs - conf_num;
> +
> +		ret = ph->xops->xfer_get_init(ph, PINCTRL_CONFIG_SET,
> +					      sizeof(*tx) + chunk * 2 * sizeof(unsigned long),

									^^
									sizeof(__le32))
> +					      0, &t);
> +		if (ret)
> +			return ret;
> +
> +		tx = t->tx.buf;
> +		tx->identifier = cpu_to_le32(selector);
> +		attributes = FIELD_PREP(GENMASK(1, 0), type) |
> +			FIELD_PREP(GENMASK(9, 2), chunk);
> +		tx->attributes = cpu_to_le32(attributes);
> +
> +		for (i = 0; i < chunk; i++) {
> +			tx->configs[i * 2] = cpu_to_le32(pinconf_to_config_param(configs[i]));

This should be the bare config_type as received already in SCMI format
as a param.

> +			tx->configs[i * 2 + 1] =
> +				cpu_to_le32(pinconf_to_config_argument(configs[i]));

and here the config_values...this also means you will have to change the
parameters to this function to pass a

	uint8_t *config_types
	uint32_t *config_values
	unsigne int num_configs

or something like that....there is also a subtle need to remap the types
from Pinctrl to SCMI in the pinctrl SCMI driver (I commented this on
that patch)

Thanks,
Cristian


From didi.debian at cknow.org  Fri Dec 22 08:30:45 2023
From: didi.debian at cknow.org (Diederik de Haas)
Date: Fri, 22 Dec 2023 17:30:45 +0100
Subject: [PATCH 1/6] dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel
In-Reply-To: <20231222-pinetab2-v1-1-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-1-e148a7f61bd1@mecka.net>
Message-ID: <2093114.Y6Bb1VsB30@bagend>

On Friday, 22 December 2023 12:05:41 CET Manuel Traut wrote:
> +title: BOE TH101MB31IG002-28A Pine64 Pinetab2 DSI Display Panel

s/Pine64 Pinetab2 // ?

It is used by the PT2 but I assume it's a 'standalone' panel?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/82acdce4/attachment.sig>

From Markus.Elfring at web.de  Fri Dec 22 08:33:19 2023
From: Markus.Elfring at web.de (Markus Elfring)
Date: Fri, 22 Dec 2023 17:33:19 +0100
Subject: [PATCH 0/2] clk: imx: composite-8m: Adjustments for
 __imx8m_clk_hw_composite()
Message-ID: <1d494176-2238-4430-bc26-4e4c78fe4ede@web.de>

From: Markus Elfring <elfring at users.sourceforge.net>
Date: Fri, 22 Dec 2023 17:24:32 +0100

A few update suggestions were taken into account
from source code analysis.

Markus Elfring (2):
  Less function calls after error detection
  Delete two unnecessary initialisations

 drivers/clk/imx/clk-composite-8m.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

--
2.43.0



From cristian.marussi at arm.com  Fri Dec 22 08:35:11 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 22 Dec 2023 16:35:11 +0000
Subject: [PATCH 6/7] pinctrl: Implementation of the generic scmi-pinctrl
 driver
In-Reply-To: <20231215-pinctrl-scmi-v1-6-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-6-0fe35e4611f7@nxp.com>
Message-ID: <ZYW6v724Ags5JtY9@pluto>

On Fri, Dec 15, 2023 at 07:56:34PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> scmi-pinctrl driver implements pinctrl driver interface and using
> SCMI protocol to redirect messages from pinctrl subsystem SDK to
> SCMI platform firmware, which does the changes in HW.
> 

[CC: Akashi which was interested in this series]

This generic driver still works fine for me as of now in my emulated
setup using the generic SCMI bindings as in the initial Oleksii example
and a dummy driver consumer for this pins, BUT there is still an open
issue as reported by Akashi previously ..see below.

> Co-developed-by: Oleksii Moisieiev <oleksii_moisieiev at epam.com>
> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev at epam.com>
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  MAINTAINERS                    |   1 +
>  drivers/pinctrl/Kconfig        |  11 ++
>  drivers/pinctrl/Makefile       |   1 +
>  drivers/pinctrl/pinctrl-scmi.c | 403 +++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 416 insertions(+)
 
 [snip]

> +static const struct pinmux_ops pinctrl_scmi_pinmux_ops = {
> +	.request = pinctrl_scmi_request,
> +	.free = pinctrl_scmi_free,
> +	.get_functions_count = pinctrl_scmi_get_functions_count,
> +	.get_function_name = pinctrl_scmi_get_function_name,
> +	.get_function_groups = pinctrl_scmi_get_function_groups,
> +	.set_mux = pinctrl_scmi_func_set_mux,
> +};
> +
> +static int pinctrl_scmi_pinconf_get(struct pinctrl_dev *pctldev, unsigned int _pin,
> +				    unsigned long *config)
> +{
> +	int ret;
> +	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
> +	enum pin_config_param config_type;
> +	unsigned long config_value;
> +
> +	if (!config)
> +		return -EINVAL;
> +
> +	config_type = pinconf_to_config_param(*config);

This config types that are packed/unpacked from the generic Pinctrl
subsystem have also to be mapped/umapped, here and below, to the SCMI
ones since they are slightly different/.

IOW SCMI V3.2 Table_24 in the spec, which defines Pins Config Types as
understood by an SCMI platform FW is NOT exactly mapping to the enum
pin_config_param used by Pinctrl in its pinconf_to_config so you risk
passing a config_type to the SCMI fw that does NOT mean at all what
intended...if the FW is compliant with SCMI.

> +
> +	ret = pinctrl_ops->config_get(pmx->ph, _pin, PIN_TYPE, config_type, &config_value);
> +	if (ret)
> +		return ret;
> +
> +	*config = pinconf_to_config_packed(config_type, config_value);
> +
> +	return 0;
> +}
> +
> +static int pinctrl_scmi_pinconf_set(struct pinctrl_dev *pctldev,
> +				    unsigned int _pin,
> +				    unsigned long *configs,
> +				    unsigned int num_configs)
> +{
> +	int ret;
> +	struct scmi_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
> +
> +	if (!configs || !num_configs)
> +		return -EINVAL;
> +

Same here, as said in the previous patch about pinctrl protocol, you
should pack/unpack and map/unmap from Pinctrl packed configs and types
to SCMI types and unpacked config/values, to fix the mismatch between
Pinctrl and SCMI types and also to avoid the usage of Pinctrl helpers to
extract the types from the SCMI protocol layer so that we can keep it
agnostic in these regards.

Thanks,
Cristian


From Markus.Elfring at web.de  Fri Dec 22 08:35:53 2023
From: Markus.Elfring at web.de (Markus Elfring)
Date: Fri, 22 Dec 2023 17:35:53 +0100
Subject: [PATCH 1/2] clk: imx: composite-8m: Less function calls in
 __imx8m_clk_hw_composite() after error detection
In-Reply-To: <1d494176-2238-4430-bc26-4e4c78fe4ede@web.de>
References: <1d494176-2238-4430-bc26-4e4c78fe4ede@web.de>
Message-ID: <147ca1e6-69f3-4586-b5b3-b69f9574a862@web.de>

From: Markus Elfring <elfring at users.sourceforge.net>
Date: Fri, 22 Dec 2023 16:48:24 +0100

The function ?kfree? was called in up to three cases
by the function ?__imx8m_clk_hw_composite? during error handling
even if the passed variables contained a null pointer.

Adjust jump targets according to the Linux coding style convention.

Signed-off-by: Markus Elfring <elfring at users.sourceforge.net>
---
 drivers/clk/imx/clk-composite-8m.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/imx/clk-composite-8m.c b/drivers/clk/imx/clk-composite-8m.c
index 27a08c50ac1d..eb5392f7a257 100644
--- a/drivers/clk/imx/clk-composite-8m.c
+++ b/drivers/clk/imx/clk-composite-8m.c
@@ -220,7 +220,7 @@ struct clk_hw *__imx8m_clk_hw_composite(const char *name,

 	mux = kzalloc(sizeof(*mux), GFP_KERNEL);
 	if (!mux)
-		goto fail;
+		return ERR_CAST(hw);

 	mux_hw = &mux->hw;
 	mux->reg = reg;
@@ -230,7 +230,7 @@ struct clk_hw *__imx8m_clk_hw_composite(const char *name,

 	div = kzalloc(sizeof(*div), GFP_KERNEL);
 	if (!div)
-		goto fail;
+		goto free_mux;

 	div_hw = &div->hw;
 	div->reg = reg;
@@ -260,7 +260,7 @@ struct clk_hw *__imx8m_clk_hw_composite(const char *name,
 	if (!mcore_booted) {
 		gate = kzalloc(sizeof(*gate), GFP_KERNEL);
 		if (!gate)
-			goto fail;
+			goto free_div;

 		gate_hw = &gate->hw;
 		gate->reg = reg;
@@ -272,13 +272,15 @@ struct clk_hw *__imx8m_clk_hw_composite(const char *name,
 			mux_hw, mux_ops, div_hw,
 			divider_ops, gate_hw, &clk_gate_ops, flags);
 	if (IS_ERR(hw))
-		goto fail;
+		goto free_gate;

 	return hw;

-fail:
+free_gate:
 	kfree(gate);
+free_div:
 	kfree(div);
+free_mux:
 	kfree(mux);
 	return ERR_CAST(hw);
 }
--
2.43.0



From Markus.Elfring at web.de  Fri Dec 22 08:37:49 2023
From: Markus.Elfring at web.de (Markus Elfring)
Date: Fri, 22 Dec 2023 17:37:49 +0100
Subject: [PATCH 2/2] clk: imx: composite-8m: Delete two unnecessary
 initialisations in __imx8m_clk_hw_composite()
In-Reply-To: <1d494176-2238-4430-bc26-4e4c78fe4ede@web.de>
References: <1d494176-2238-4430-bc26-4e4c78fe4ede@web.de>
Message-ID: <6604590e-d0f7-4798-a1b9-b2f474f3a642@web.de>

From: Markus Elfring <elfring at users.sourceforge.net>
Date: Fri, 22 Dec 2023 17:11:03 +0100

Two local variables will eventually be set to appropriate pointers
a bit later. Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring <elfring at users.sourceforge.net>
---
 drivers/clk/imx/clk-composite-8m.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-composite-8m.c b/drivers/clk/imx/clk-composite-8m.c
index eb5392f7a257..8cc07d056a83 100644
--- a/drivers/clk/imx/clk-composite-8m.c
+++ b/drivers/clk/imx/clk-composite-8m.c
@@ -212,9 +212,9 @@ struct clk_hw *__imx8m_clk_hw_composite(const char *name,
 {
 	struct clk_hw *hw = ERR_PTR(-ENOMEM), *mux_hw;
 	struct clk_hw *div_hw, *gate_hw = NULL;
-	struct clk_divider *div = NULL;
+	struct clk_divider *div;
 	struct clk_gate *gate = NULL;
-	struct clk_mux *mux = NULL;
+	struct clk_mux *mux;
 	const struct clk_ops *divider_ops;
 	const struct clk_ops *mux_ops;

--
2.43.0



From lkp at intel.com  Fri Dec 22 08:46:22 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 00:46:22 +0800
Subject: [soc:rockchip/dt64] BUILD SUCCESS
 8174dff9e583f7791dacf6d8ce034eb18ec2b292
Message-ID: <202312230019.vNwcDy21-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git rockchip/dt64
branch HEAD: 8174dff9e583f7791dacf6d8ce034eb18ec2b292  arm64: dts: rockchip: Add Anbernic RG351V

elapsed time: 14154m

configs tested: 160
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                        nsim_700_defconfig   gcc  
arc                   randconfig-001-20231222   gcc  
arc                   randconfig-002-20231222   gcc  
arc                           tb10x_defconfig   gcc  
arm                               allnoconfig   gcc  
arm                           h3600_defconfig   gcc  
arm                            mps2_defconfig   gcc  
arm                       omap2plus_defconfig   gcc  
arm                         orion5x_defconfig   clang
arm                            qcom_defconfig   gcc  
arm                   randconfig-001-20231222   gcc  
arm                   randconfig-002-20231222   gcc  
arm                   randconfig-003-20231222   gcc  
arm                   randconfig-004-20231222   gcc  
arm                           sama5_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231222   gcc  
arm64                 randconfig-002-20231222   gcc  
arm64                 randconfig-003-20231222   gcc  
arm64                 randconfig-004-20231222   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231222   gcc  
csky                  randconfig-002-20231222   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                                defconfig   gcc  
i386                  randconfig-011-20231222   clang
i386                  randconfig-012-20231222   clang
i386                  randconfig-013-20231222   clang
i386                  randconfig-014-20231222   clang
i386                  randconfig-015-20231222   clang
i386                  randconfig-016-20231222   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231222   gcc  
loongarch             randconfig-002-20231222   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                      maltasmvp_defconfig   gcc  
mips                        maltaup_defconfig   clang
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231222   gcc  
nios2                 randconfig-002-20231222   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231222   gcc  
parisc                randconfig-002-20231222   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                      arches_defconfig   gcc  
powerpc                      bamboo_defconfig   gcc  
powerpc                      makalu_defconfig   gcc  
powerpc                       maple_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                 mpc832x_rdb_defconfig   clang
powerpc               randconfig-001-20231222   gcc  
powerpc               randconfig-002-20231222   gcc  
powerpc               randconfig-003-20231222   gcc  
powerpc                    sam440ep_defconfig   gcc  
powerpc64             randconfig-001-20231222   gcc  
powerpc64             randconfig-002-20231222   gcc  
powerpc64             randconfig-003-20231222   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                    nommu_k210_defconfig   gcc  
riscv                    nommu_virt_defconfig   clang
riscv                 randconfig-001-20231222   gcc  
riscv                 randconfig-002-20231222   gcc  
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                        apsh4ad0a_defconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                             espt_defconfig   gcc  
sh                    randconfig-001-20231222   gcc  
sh                    randconfig-002-20231222   gcc  
sh                           se7619_defconfig   gcc  
sh                     sh7710voipgw_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc                       sparc32_defconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231222   gcc  
sparc64               randconfig-002-20231222   gcc  
um                               alldefconfig   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231222   gcc  
um                    randconfig-002-20231222   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231222   gcc  
x86_64       buildonly-randconfig-002-20231222   gcc  
x86_64       buildonly-randconfig-003-20231222   gcc  
x86_64       buildonly-randconfig-004-20231222   gcc  
x86_64       buildonly-randconfig-005-20231222   gcc  
x86_64       buildonly-randconfig-006-20231222   gcc  
x86_64                              defconfig   gcc  
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231222   gcc  
x86_64                randconfig-012-20231222   gcc  
x86_64                randconfig-013-20231222   gcc  
x86_64                randconfig-014-20231222   gcc  
x86_64                randconfig-015-20231222   gcc  
x86_64                randconfig-016-20231222   gcc  
x86_64                randconfig-071-20231222   gcc  
x86_64                randconfig-072-20231222   gcc  
x86_64                randconfig-073-20231222   gcc  
x86_64                randconfig-074-20231222   gcc  
x86_64                randconfig-075-20231222   gcc  
x86_64                randconfig-076-20231222   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                  cadence_csp_defconfig   gcc  
xtensa                randconfig-001-20231222   gcc  
xtensa                randconfig-002-20231222   gcc  
xtensa                    smp_lx200_defconfig   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From didi.debian at cknow.org  Fri Dec 22 08:49:35 2023
From: didi.debian at cknow.org (Diederik de Haas)
Date: Fri, 22 Dec 2023 17:49:35 +0100
Subject: [PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2
In-Reply-To: <20231222-pinetab2-v1-4-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-4-e148a7f61bd1@mecka.net>
Message-ID: <2250271.fI8GBZLEnK@bagend>

On Friday, 22 December 2023 12:05:44 CET Manuel Traut wrote:
> +       rk817-sound {
> +               compatible = "simple-audio-card";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&hp_det_l>;
> +               simple-audio-card,format = "i2s";
> +               simple-audio-card,name = "PineTab2";
> +               simple-audio-card,mclk-fs = <256>;
> +
> +               simple-audio-card,widgets =
> +                       "Microphone", "Mic Jack",
> +                       "Headphone", "Headphones",
> +                       "Microphone", "Microphone",
> +                       "Speaker", "Speakers";
> +
> +               simple-audio-card,routing =
> +                       "MICL", "Microphone",
> +                       "MICR", "Mic Jack",
> +                       "Headphones", "HPOL",
> +                       "Headphones", "HPOR",
> +                       "Speaker Amplifier INL", "HPOL",
> +                       "Speaker Amplifier INR", "HPOR",
> +                       "Speakers", "Speaker Amplifier OUTL",
> +                       "Speakers", "Speaker Amplifier OUTR";
> +
> +               simple-audio-card,hp-det-gpio = <&gpio4 RK_PC6
> GPIO_ACTIVE_HIGH>; +               simple-audio-card,aux-devs =
> <&speaker_amp>;
> +               simple-audio-card,pin-switches = "Speakers", "Microphone";
> +
> +               simple-audio-card,cpu {
> +                       sound-dai = <&i2s1_8ch>;
> +               };
> +
> +               simple-audio-card,codec {
> +                       sound-dai = <&rk817>;
> +               };
> +       };

Not sure if it's right (or allowed) to post a different patch as attachment, 
but I have been using a different audio configuration (see attachment).
I haven't yet tried if/how it works via HDMI yet, but the speakers and 
headphones work fine.
This patch is based on the following commit:
https://github.com/TuxThePenguin0/linux/commit/
872b829a3511cfa853bd3af3bd4f30be1cb3d1ab

I've added 'Danct12' to the To list as they are the maintainer of the primary 
PT2 image and we worked together to get to this audio config.
I don't if they still use it.
(I've been using my own kernel/image for a while now).

Cheers,
  Diederik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-arm64-dts-rk3566-pinetab2-Fix-audio-configuration.patch
Type: text/x-patch
Size: 2292 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/f86b0dde/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/f86b0dde/attachment-0001.sig>

From didi.debian at cknow.org  Fri Dec 22 08:51:41 2023
From: didi.debian at cknow.org (Diederik de Haas)
Date: Fri, 22 Dec 2023 17:51:41 +0100
Subject: [PATCH 0/6] arm64: rockchip: Pine64 pinetab2 support
In-Reply-To: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
Message-ID: <2631715.l0DajZZ3Y3@bagend>

On Friday, 22 December 2023 12:05:40 CET Manuel Traut wrote:
> [3]
> https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/
> mobian-6.6/debian/patches/display/0018-drm-panel-add-BOE-TH101MB31IG002-28A-
> driver.patch?ref_type=heads 
> [4]
> https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/
> mobian-6.6/debian/patches/device-tree/0134-arch-arm64-add-Pine64-PineTab2-de
> vice-trees.patch?ref_type=heads

FWIW I believe the actual sources are from
https://github.com/TuxThePenguin0/linux/commits/device/pine64-pinetab2_stable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/8465a404/attachment.sig>

From peter.griffin at linaro.org  Fri Dec 22 08:53:52 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 22 Dec 2023 16:53:52 +0000
Subject: [PATCH 0/3]  Enable Multi Core Timer (MCT) for gs101
Message-ID: <20231222165355.1462740-1-peter.griffin@linaro.org>

Hi folks,

This series enables Multi Core Timer (MCT) for gs101. As part of enabling
MCT we also need to register cmu_misc bank of clocks early so exynos_mct can
obtain it's clock.

MCT timer is required longer term as the Arm arch timer can't wake the CPU from
suspend. This series is based off todays linux-next.

Note the dtsi change without the corresponding clock driver changes will result
in a system that doesn't boot. So ideally this would both be merged together
through Krzysztofs Samsung exynos tree. If that is OK with everyone?

regards,

Peter

Peter Griffin (3):
  dt-bindings: timer: exynos4210-mct: Add google,gs101-mct compatible
  clk: samsung: gs101: register cmu_misc clocks early
  arm64: dts: exynos: gs101: define Multi Core Timer (MCT) node

 .../timer/samsung,exynos4210-mct.yaml         |  2 ++
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  | 20 +++++++++++++++++++
 drivers/clk/samsung/clk-gs101.c               | 12 ++++++++---
 3 files changed, 31 insertions(+), 3 deletions(-)

-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Fri Dec 22 08:53:53 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 22 Dec 2023 16:53:53 +0000
Subject: [PATCH 1/3] dt-bindings: timer: exynos4210-mct: Add google,gs101-mct compatible
In-Reply-To: <20231222165355.1462740-1-peter.griffin@linaro.org>
References: <20231222165355.1462740-1-peter.griffin@linaro.org>
Message-ID: <20231222165355.1462740-2-peter.griffin@linaro.org>

Add dedicated google,gs101-mct compatible to the dt-schema for
representing mct timer of the Google Tensor gs101 SoC.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 .../devicetree/bindings/timer/samsung,exynos4210-mct.yaml       | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
index 829bd2227f7c..774b7992a0ca 100644
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
@@ -26,6 +26,7 @@ properties:
       - items:
           - enum:
               - axis,artpec8-mct
+              - google,gs101-mct
               - samsung,exynos3250-mct
               - samsung,exynos5250-mct
               - samsung,exynos5260-mct
@@ -127,6 +128,7 @@ allOf:
           contains:
             enum:
               - axis,artpec8-mct
+              - google,gs101-mct
               - samsung,exynos5260-mct
               - samsung,exynos5420-mct
               - samsung,exynos5433-mct
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Fri Dec 22 08:53:54 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 22 Dec 2023 16:53:54 +0000
Subject: [PATCH 2/3] clk: samsung: gs101: register cmu_misc clocks early
In-Reply-To: <20231222165355.1462740-1-peter.griffin@linaro.org>
References: <20231222165355.1462740-1-peter.griffin@linaro.org>
Message-ID: <20231222165355.1462740-3-peter.griffin@linaro.org>

Update cmu_misc so it is registered early, as it contains
the gate which clocks the Multi Core Timer (MCT). This clock
is required early in boot, otherwise exynos_mct will fail
obtaining the clock.

Note this wasn't previously an issue as exynos_mct wasn't
enabled.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 drivers/clk/samsung/clk-gs101.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 0964bb11657f..590119a25c18 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -2478,6 +2478,15 @@ static const struct samsung_cmu_info misc_cmu_info __initconst = {
 	.clk_name		= "dout_cmu_misc_bus",
 };
 
+static void __init gs101_cmu_misc_init(struct device_node *np)
+{
+	exynos_arm64_register_cmu(NULL, np, &misc_cmu_info);
+}
+
+/* Register CMU_MISC early, as it's needed for MCT timer */
+CLK_OF_DECLARE(gs101_cmu_misc, "google,gs101-cmu-misc",
+	       gs101_cmu_misc_init);
+
 /* ---- platform_driver ----------------------------------------------------- */
 
 static int __init gs101_cmu_probe(struct platform_device *pdev)
@@ -2495,9 +2504,6 @@ static const struct of_device_id gs101_cmu_of_match[] = {
 	{
 		.compatible = "google,gs101-cmu-apm",
 		.data = &apm_cmu_info,
-	}, {
-		.compatible = "google,gs101-cmu-misc",
-		.data = &misc_cmu_info,
 	}, {
 	},
 };
-- 
2.43.0.472.g3155946c3a-goog



From peter.griffin at linaro.org  Fri Dec 22 08:53:55 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 22 Dec 2023 16:53:55 +0000
Subject: [PATCH 3/3] arm64: dts: exynos: gs101: define Multi Core Timer (MCT) node
In-Reply-To: <20231222165355.1462740-1-peter.griffin@linaro.org>
References: <20231222165355.1462740-1-peter.griffin@linaro.org>
Message-ID: <20231222165355.1462740-4-peter.griffin@linaro.org>

MCT has one global timer and 8 CPU local timers. The global timer
can generate 4 interrupts, and each local timer can generate an
interrupt making 12 interrupts in total.

Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
---
 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 9747cb3fa03a..4b09e740b58a 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -292,6 +292,26 @@ cmu_misc: clock-controller at 10010000 {
 			clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
 		};
 
+		timer at 10050000 {
+			compatible = "google,gs101-mct",
+				     "samsung,exynos4210-mct";
+			reg = <0x10050000 0x800>;
+			interrupts = <GIC_SPI 753 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 754 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 755 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 756 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 757 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 758 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 759 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 760 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 761 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 762 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 763 IRQ_TYPE_LEVEL_HIGH 0>,
+				     <GIC_SPI 764 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks = <&ext_24_5m>, <&cmu_misc CLK_GOUT_MISC_MCT_PCLK>;
+			clock-names = "fin_pll", "mct";
+		};
+
 		watchdog_cl0: watchdog at 10060000 {
 			compatible = "google,gs101-wdt";
 			reg = <0x10060000 0x100>;
-- 
2.43.0.472.g3155946c3a-goog



From semen.protsenko at linaro.org  Fri Dec 22 08:58:25 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 22 Dec 2023 10:58:25 -0600
Subject: [PATCH 1/3] dt-bindings: timer: exynos4210-mct: Add
 google,gs101-mct compatible
In-Reply-To: <20231222165355.1462740-2-peter.griffin@linaro.org>
References: <20231222165355.1462740-1-peter.griffin@linaro.org> <20231222165355.1462740-2-peter.griffin@linaro.org>
Message-ID: <CAPLW+4mDnHXjvsqGVB4ORP1e_t5RrOf7mWqNLxJJfBhOaHO0wg@mail.gmail.com>

On Fri, Dec 22, 2023 at 10:54?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Add dedicated google,gs101-mct compatible to the dt-schema for
> representing mct timer of the Google Tensor gs101 SoC.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  .../devicetree/bindings/timer/samsung,exynos4210-mct.yaml       | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> index 829bd2227f7c..774b7992a0ca 100644
> --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> @@ -26,6 +26,7 @@ properties:
>        - items:
>            - enum:
>                - axis,artpec8-mct
> +              - google,gs101-mct
>                - samsung,exynos3250-mct
>                - samsung,exynos5250-mct
>                - samsung,exynos5260-mct
> @@ -127,6 +128,7 @@ allOf:
>            contains:
>              enum:
>                - axis,artpec8-mct
> +              - google,gs101-mct
>                - samsung,exynos5260-mct
>                - samsung,exynos5420-mct
>                - samsung,exynos5433-mct
> --
> 2.43.0.472.g3155946c3a-goog
>


From semen.protsenko at linaro.org  Fri Dec 22 08:59:13 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 22 Dec 2023 10:59:13 -0600
Subject: [PATCH 2/3] clk: samsung: gs101: register cmu_misc clocks early
In-Reply-To: <20231222165355.1462740-3-peter.griffin@linaro.org>
References: <20231222165355.1462740-1-peter.griffin@linaro.org> <20231222165355.1462740-3-peter.griffin@linaro.org>
Message-ID: <CAPLW+4konUmivej17mjxyMJF7kBfQ9qZGMzr=Fq6ROiGtEASzA@mail.gmail.com>

On Fri, Dec 22, 2023 at 10:54?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> Update cmu_misc so it is registered early, as it contains
> the gate which clocks the Multi Core Timer (MCT). This clock
> is required early in boot, otherwise exynos_mct will fail
> obtaining the clock.
>
> Note this wasn't previously an issue as exynos_mct wasn't
> enabled.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  drivers/clk/samsung/clk-gs101.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> index 0964bb11657f..590119a25c18 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -2478,6 +2478,15 @@ static const struct samsung_cmu_info misc_cmu_info __initconst = {
>         .clk_name               = "dout_cmu_misc_bus",
>  };
>
> +static void __init gs101_cmu_misc_init(struct device_node *np)
> +{
> +       exynos_arm64_register_cmu(NULL, np, &misc_cmu_info);
> +}
> +
> +/* Register CMU_MISC early, as it's needed for MCT timer */
> +CLK_OF_DECLARE(gs101_cmu_misc, "google,gs101-cmu-misc",
> +              gs101_cmu_misc_init);
> +
>  /* ---- platform_driver ----------------------------------------------------- */
>
>  static int __init gs101_cmu_probe(struct platform_device *pdev)
> @@ -2495,9 +2504,6 @@ static const struct of_device_id gs101_cmu_of_match[] = {
>         {
>                 .compatible = "google,gs101-cmu-apm",
>                 .data = &apm_cmu_info,
> -       }, {
> -               .compatible = "google,gs101-cmu-misc",
> -               .data = &misc_cmu_info,
>         }, {
>         },
>  };
> --
> 2.43.0.472.g3155946c3a-goog
>


From semen.protsenko at linaro.org  Fri Dec 22 08:59:37 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Fri, 22 Dec 2023 10:59:37 -0600
Subject: [PATCH 3/3] arm64: dts: exynos: gs101: define Multi Core Timer
 (MCT) node
In-Reply-To: <20231222165355.1462740-4-peter.griffin@linaro.org>
References: <20231222165355.1462740-1-peter.griffin@linaro.org> <20231222165355.1462740-4-peter.griffin@linaro.org>
Message-ID: <CAPLW+4khNwA=480_69XU5vPOY=Zw=4ytA4stF7gvRfUDCEGE5Q@mail.gmail.com>

On Fri, Dec 22, 2023 at 10:54?AM Peter Griffin <peter.griffin at linaro.org> wrote:
>
> MCT has one global timer and 8 CPU local timers. The global timer
> can generate 4 interrupts, and each local timer can generate an
> interrupt making 12 interrupts in total.
>
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  arch/arm64/boot/dts/exynos/google/gs101.dtsi | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index 9747cb3fa03a..4b09e740b58a 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -292,6 +292,26 @@ cmu_misc: clock-controller at 10010000 {
>                         clock-names = "dout_cmu_misc_bus", "dout_cmu_misc_sss";
>                 };
>
> +               timer at 10050000 {
> +                       compatible = "google,gs101-mct",
> +                                    "samsung,exynos4210-mct";
> +                       reg = <0x10050000 0x800>;
> +                       interrupts = <GIC_SPI 753 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 754 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 755 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 756 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 757 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 758 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 759 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 760 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 761 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 762 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 763 IRQ_TYPE_LEVEL_HIGH 0>,
> +                                    <GIC_SPI 764 IRQ_TYPE_LEVEL_HIGH 0>;
> +                       clocks = <&ext_24_5m>, <&cmu_misc CLK_GOUT_MISC_MCT_PCLK>;
> +                       clock-names = "fin_pll", "mct";
> +               };
> +
>                 watchdog_cl0: watchdog at 10060000 {
>                         compatible = "google,gs101-wdt";
>                         reg = <0x10060000 0x100>;
> --
> 2.43.0.472.g3155946c3a-goog
>


From didi.debian at cknow.org  Fri Dec 22 09:01:54 2023
From: didi.debian at cknow.org (Diederik de Haas)
Date: Fri, 22 Dec 2023 18:01:54 +0100
Subject: [PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2
In-Reply-To: <20231222-pinetab2-v1-4-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-4-e148a7f61bd1@mecka.net>
Message-ID: <2121710.IWpXjAX0fk@bagend>

On Friday, 22 December 2023 12:05:44 CET Manuel Traut wrote:
> +
> +&cru {
> +       assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>, <&cru
> PLL_VPLL>; +       assigned-clock-rates = <1200000000>, <200000000>,
> <500000000>; +};

Attachment seem to work and for this I also have the attached patch in my 
patch set.
IIRC without it you get an error in dmesg immediately at boot up which is 
visible on the PT2 *if* you have immediate visual output (which is not (yet?) 
the case in my image/kernel).

Cheers,
  Diederik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-arm64-dts-rk3566-pinetab2-Fix-cru-assigned-clocks.patch
Type: text/x-patch
Size: 1418 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/ed096e45/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/ed096e45/attachment-0001.sig>

From jernej.skrabec at gmail.com  Fri Dec 22 09:36:31 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Fri, 22 Dec 2023 18:36:31 +0100
Subject: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate
In-Reply-To: <87v88qk3ge.fsf@oltmanns.dev>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <875y0sacmz.fsf@oltmanns.dev> <87v88qk3ge.fsf@oltmanns.dev>
Message-ID: <4187182.1IzOArtZ34@jernej-laptop>

Dne petek, 22. december 2023 ob 10:10:25 CET je Frank Oltmanns napisal(a):
> 
> On 2023-12-20 at 19:57:06 +0100, Frank Oltmanns <frank at oltmanns.dev> wrote:
> > Ok, I've done more detailed testing, and it seems this patch results in
> > lots of dropped frames. I'm sorry for not being more thorough earlier.
> > I'll do some more testing without this patch and might have to either
> > remove it from V2 of this series.
> >
> > I need to see if the same stability can be achieved when running
> > PLL-MIPI outside its specied range.
> 
> I've done some more (load) testing and observing the panel for dropped
> frames.
> 
> The conclusion I draw from those results is that this patch isn't
> necessary for the pinephone. It would be enough to use the correct clock
> rate based on the existing values [*]:
> -	.clock	     = 69000,
> +	.clock	     = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000,
> 
> I've asked in the postmarketOS community for a bit more testing. They
> already have a merge request that contains these changes [2].

This patch sounds reasonable and IMO should be merged.

Best regards,
Jernej

> 
> This means that we would continue to drive PLL-MIPI outside it's
> specified range. I have, so far, not experienced any downside of doing
> so. It seems enough to fix the ratios that are part of the first four
> patches in this series without introducing a min and max rate.
> 
> In conclusion, I'll soon (after some more feedback from the fine folks
> at postmarketOS) submit a V2 that addresses the fixes requested in the
> first four patches of this series. I'll drop the existing PATCH 5 and
> replace it with the one I sent in February [1] instead.
> 
> After that, just for fun, I'll probably look into min_rate and max_rate
> for nkm clocks and which consequences it has on the pinephone. I might
> or might not send a follow up series for that. However, if the pinephone
> runs stable without it, it's not a high priority for me.
> 
> Best regards,
>   Frank
> 
> [*] I've already submitted a patch in February '23 [1]. It was of little
>     use back then because the A64's PLL-MIPI clock was not able to run
>     close to that rate. But since kernel 6.6 PLL-MIPI is able to set
>     it's parent rate, so that it can come quite close to the required
>     rate:
>      + Panel requires 74.844 MHz with the current timings.
>      +-> tcon-data-clock rate should be 112.266 MHz (panel*24/4/4).
>       +-> PLL-MIPI rate should be 449.064 MHz (TCON0 * 4)
> 
>     The 6.6 kernel the following rates are possible:
>      + PLL-MIPI: ~448.984615 MHz
>      +-> tcon-data-clock: ~112.246153
>       +-> panel: ~74.830768 MHz
> 
>     Which leaves us with a vertical refresh rate of ~59.989 Hz,
>     deviating less then 0.2% from the ideal 60Hz. That's probably closer
>     than the accumulated accuracy of all involved components can
>     reliably achieve. I'd say, let's leave it at that.
> 
> [1]: https://lore.kernel.org/lkml/20230219114553.288057-2-frank at oltmanns.dev/
> [2]: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4645
> >
> > Best regards,
> >   Frank
> >
> > On 2023-12-20 at 16:18:49 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> >> Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a):
> >>>
> >>> On 2023-12-19 at 18:04:29 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> >>> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns napisal(a):
> >>> >> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
> >>> >> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
> >>> >> than 500 MHz.
> >>> >>
> >>> >> Therefore, change [hv]sync_(start|end) so that we reach a clock rate
> >>> >> that is high enough to drive PLL-MIPI within its limits.
> >>> >>
> >>> >> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
> >>> >
> >>> > I'm not too sure about this patch. I see that PLL_MIPI doesn't have set
> >>> > minimum frequency limit in clock driver. If you add it, clock framework
> >>> > should find rate that is high enough and divisible with target rate.
> >>>
> >>> This one is really a tough nut. Unfortunately, the PLL_MIPI clock for
> >>> this panel has to run exactly at 6 * panel clock. Let me start by
> >>> showing the relevant part of the clock tree (this is on the pinephone
> >>> after applying the patches):
> >>>     pll-video0                 393600000
> >>>        pll-mipi                500945454
> >>>           tcon0                500945454
> >>>              tcon-data-clock   125236363
> >>>
> >>> To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit
> >>> rate [1]. It's a fixed divisor
> >>>
> >>> The panel I'm proposing to change is defined as this:
> >>>
> >>>     static const struct st7703_panel_desc xbd599_desc = {
> >>>     	.mode = &xbd599_mode,
> >>>     	.lanes = 4,
> >>>     	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> >>>     	.format = MIPI_DSI_FMT_RGB888,
> >>>     	.init_sequence = xbd599_init_sequence,
> >>>     };
> >>>
> >>> So, we have 24 bpp and 4 lanes. Therefore, the resulting requested
> >>> tcon-data-clock rate is
> >>>     crtc_clock * 1000 * (24 / 4) / 4
> >>>
> >>> tcon-data-clock therefore requests a parent rate of
> >>>     4 * (crtc_clock * 1000 * (24 / 4) / 4)
> >>>
> >>> The initial 4 is the fixed divisor between tcon0 and tcon-data-clock.
> >>> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi.
> >>>
> >>> Since PLL-MIPI has to run at at least at 500MHz this forces us to have a
> >>> crtc_clock >= 83.333 MHz. The mode I'm prorposing results in a rate of
> >>> 83.502 MHz.
> >>
> >> This is much better explanation why this change is needed. Still, I think
> >> adding min and max rate to PLL_MIPI would make sense, so proper rates
> >> are guaranteed.
> >>
> >> Anyway, do you know where are all those old values come from? And how did
> >> you come up with new ones? I guess you can't just simply change timings,
> >> there are probably some HW limitations? Do you know if BSP kernel support
> >> this panel and how this situation is solved there?
> >>
> >>>
> >>> If we only changed the constraints on the PLL_MIPI without changing the
> >>> panel mode, we end up with a mismatch. This, in turn, would result in
> >>> dropped frames, right?
> >>
> >> From what I read, I think frame rate would be higher than 60 fps. What
> >> exactly would happen depends on the panel.
> >>
> >> Best regards,
> >> Jernej
> >>
> >>>
> >>> Best regards,
> >>>   Frank
> >>>
> >>> [1] Source:
> >>> https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/sun4i_tcon.c#L346
> >>>
> >>> >
> >>> > Best regards,
> >>> > Jernej
> >>> >
> >>> >> ---
> >>> >>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++-------
> >>> >>  1 file changed, 7 insertions(+), 7 deletions(-)
> >>> >>
> >>> >> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> >>> >> index b55bafd1a8be..6886fd7f765e 100644
> >>> >> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> >>> >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> >>> >> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
> >>> >>
> >>> >>  static const struct drm_display_mode xbd599_mode = {
> >>> >>  	.hdisplay    = 720,
> >>> >> -	.hsync_start = 720 + 40,
> >>> >> -	.hsync_end   = 720 + 40 + 40,
> >>> >> -	.htotal	     = 720 + 40 + 40 + 40,
> >>> >> +	.hsync_start = 720 + 65,
> >>> >> +	.hsync_end   = 720 + 65 + 65,
> >>> >> +	.htotal      = 720 + 65 + 65 + 65,
> >>> >>  	.vdisplay    = 1440,
> >>> >> -	.vsync_start = 1440 + 18,
> >>> >> -	.vsync_end   = 1440 + 18 + 10,
> >>> >> -	.vtotal	     = 1440 + 18 + 10 + 17,
> >>> >> -	.clock	     = 69000,
> >>> >> +	.vsync_start = 1440 + 30,
> >>> >> +	.vsync_end   = 1440 + 30 + 22,
> >>> >> +	.vtotal	     = 1440 + 30 + 22 + 29,
> >>> >> +	.clock	     = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
> >>> >>  	.flags	     = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> >>> >>  	.width_mm    = 68,
> >>> >>  	.height_mm   = 136,
> >>> >>
> >>> >>
> >>>
> 






From knaerzche at gmail.com  Fri Dec 22 09:41:53 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:41:53 +0100
Subject: [PATCH v4 02/29] drm/rockchip: vop: Add output selection registers for RK312x
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-3-knaerzche@gmail.com>

In contrast to RK3036, RK312x SoCs have multiple output channels such as
RGB (i.e. LVDS TTL), LVDS, DSI and HDMI.

In order to support that, this splits output from RK3036 and defines an
separate one for RK3126 with the registers required to enable the
appropriate output and setup the correct polarity.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - rephrase commit message

changes in v3:
 - none

changes in v4:
 - none

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 ++++++++++++-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  3 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index c51ca82320cb..b9ee02061d5b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -227,11 +227,22 @@ static const struct vop_win_data rk3126_vop_win_data[] = {
 	  .type = DRM_PLANE_TYPE_CURSOR },
 };
 
+static const struct vop_output rk3126_output = {
+	.pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+	.hdmi_pin_pol = VOP_REG(RK3126_INT_SCALER, 0x7, 4),
+	.hdmi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 22),
+	.hdmi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 23),
+	.rgb_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 24),
+	.rgb_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 25),
+	.mipi_en = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 28),
+	.mipi_dclk_pol = VOP_REG(RK3036_AXI_BUS_CTRL, 0x1, 29),
+};
+
 static const struct vop_data rk3126_vop = {
 	.intr = &rk3036_intr,
 	.common = &rk3036_common,
 	.modeset = &rk3036_modeset,
-	.output = &rk3036_output,
+	.output = &rk3126_output,
 	.win = rk3126_vop_win_data,
 	.win_size = ARRAY_SIZE(rk3126_vop_win_data),
 	.max_output = { 1920, 1080 },
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 406e981c75bd..fbf1bcc68625 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -872,6 +872,9 @@
 /* rk3036 register definition end */
 
 /* rk3126 register definition */
+#define RK3126_INT_SCALER		0x0c
+
+/* win1 register */
 #define RK3126_WIN1_MST			0x4c
 #define RK3126_WIN1_DSP_INFO		0x50
 #define RK3126_WIN1_DSP_ST		0x54
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:41:52 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:41:52 +0100
Subject: [PATCH v4 01/29] dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-2-knaerzche@gmail.com>

The integration for this SoC is different from the currently existing: It
needs it's PHY's reference clock rate to calculate the DDC bus frequency
correctly. The controller is also part of a powerdomain, so this gets added
as an mandatory property for this variant.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
---
changes in v2:
 - clarify that the controller itself is part of the powerdomain
 - simplify clock-names
 - made power-domains property only allowed (and required) for new variant

changes in v3:
 - collect RB

changes in v4:
 - none

 .../display/rockchip/rockchip,inno-hdmi.yaml  | 40 ++++++++++++++++++-
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
index 96889c86849a..be78dcfa1c76 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
@@ -14,6 +14,7 @@ properties:
   compatible:
     enum:
       - rockchip,rk3036-inno-hdmi
+      - rockchip,rk3128-inno-hdmi
 
   reg:
     maxItems: 1
@@ -22,10 +23,19 @@ properties:
     maxItems: 1
 
   clocks:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: The HDMI controller main clock
+      - description: The HDMI PHY reference clock
 
   clock-names:
-    const: pclk
+    minItems: 1
+    items:
+      - const: pclk
+      - const: ref
+
+  power-domains:
+    maxItems: 1
 
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
@@ -55,6 +65,32 @@ required:
   - pinctrl-names
   - ports
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: rockchip,rk3036-inno-hdmi
+
+    then:
+      properties:
+        power-domains: false
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: rockchip,rk3128-inno-hdmi
+
+    then:
+      properties:
+        clocks:
+          minItems: 2
+        clock-names:
+          minItems: 2
+      required:
+        - power-domains
+
 additionalProperties: false
 
 examples:
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:41:56 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:41:56 +0100
Subject: [PATCH v4 05/29] drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-6-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The driver maintains a copy of the adjusted mode but doesn't use it
anywhere. Remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 0b1740b38c7b..14d2ba92a606 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -62,7 +62,6 @@ struct inno_hdmi {
 	unsigned int tmds_rate;
 
 	struct hdmi_data_info	hdmi_data;
-	struct drm_display_mode previous_mode;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -498,9 +497,6 @@ static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_setup(hdmi, adj_mode);
-
-	/* Store the display mode for plugin/DPMS poweron events */
-	drm_mode_copy(&hdmi->previous_mode, adj_mode);
 }
 
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:41:51 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:41:51 +0100
Subject: [PATCH v4 00/29]  Add HDMI support for RK3128
Message-ID: <20231222174220.55249-1-knaerzche@gmail.com>

This is version 4 of my series that aims to add support for the display
controller (VOP) and the HDMI controller block of RK3128 (which is very
similar to the one found in RK3036). The original intention of this series
was to add support for this slightly different integration but is by now,
driven by maintainer's feedback, exploded to be a rework of inno-hdmi
driver in large parts. It is, however, a change for the better.

The VOP part is very simple -  everything we need for HDMI support is
already there. I only needed to split the output selection registers from
RK3036. The VOP has an IOMMU attached, but it has a serious silicon bug:
Registers can only be written, but not be read. As it's not possible to use
it with the IOMMU driver in it's current state I'm not adding it here and
we have to live with CMA for now - which works fine also. I got response
from the vendor, that there is no possibility to read the registers and an
workaround must be implemented in software in order to use it.

The inno-hdmi driver currently gets a lot of attention [0-2] and I'm
hooking in now also. As requested I incorporated some of Maxime's series
[0] (and tested them).
I have intentionally not removed any code dealing with output format
conversion in this series. In contrast to the input format, which is always
RGB on this platform and certainly can be dropped, that can be implemented
later. And secondly I need the conversion for RGB full range to RGB limited
range for this series.

I did also some smaller driver cleanups from my side and implemented a
custom connector state which now holds the data that belongs there and it
is not longer in the device structure and, of course, addressed the
feedback from v1 [3] and v2 [4].
There hasn't been any feedback to v3[5] so far, but I fixed an issue with
the new custom connector reset hook: If there is a connector state already
it needs to be destroyed in there as well.

Please see individual patches for detailed changelog.

Note: Patches are based and tested on next-20231213.

[0] https://lore.kernel.org/all/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d at kernel.org
[1] https://lore.kernel.org/all/20231204123315.28456-1-keith.zhao at starfivetech.com
[2] https://lore.kernel.org/all/2601b669-c570-f39d-8cf9-bff56c939912 at gmail.com
[3] https://lore.kernel.org/all/20231213195125.212923-1-knaerzche at gmail.com/
[4] https://lore.kernel.org/all/20231216162639.125215-1-knaerzche at gmail.com/
[5] https://lore.kernel.org/all/20231219170100.188800-1-knaerzche at gmail.com/

Alex Bee (17):
  dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible
  drm/rockchip: vop: Add output selection registers for RK312x
  drm/rockchip: inno_hdmi: Fix video timing
  drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents
  drm/rockchip: inno_hdmi: Drop irq struct member
  drm/rockchip: inno_hdmi: Remove useless include
  drm/rockchip: inno_hdmi: Subclass connector state
  drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
  drm/rockchip: inno_hdmi: Don't power up the phy after resetting
  drm/rockchip: inno_hdmi: Split power mode setting
  drm/rockchip: inno_hdmi: Add variant support
  drm/rockchip: inno_hdmi: Add RK3128 support
  drm/rockchip: inno_hdmi: Add basic mode validation
  drm/rockchip: inno_hdmi: Drop custom fill_modes hook
  ARM: dts: rockchip: Add display subsystem for RK3128
  ARM: dts: rockchip: Add HDMI node for RK3128
  ARM: dts: rockchip: Enable HDMI output for XPI-3128

Maxime Ripard (12):
  drm/rockchip: inno_hdmi: Remove useless mode_fixup
  drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
  drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
  drm/rockchip: inno_hdmi: Get rid of mode_set
  drm/rockchip: inno_hdmi: no need to store vic
  drm/rockchip: inno_hdmi: Remove unneeded has audio flag
  drm/rockchip: inno_hdmi: Remove useless input format
  drm/rockchip: inno_hdmi: Remove tmds rate from structure
  drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support
  drm/rockchip: inno_hdmi: Move infoframe disable to separate function
  drm/rockchip: inno_hdmi: Switch to infoframe type
  drm/rockchip: inno_hdmi: Remove unused drm device pointer

 .../display/rockchip/rockchip,inno-hdmi.yaml  |  40 +-
 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts |  29 +
 arch/arm/boot/dts/rockchip/rk3128.dtsi        |  60 ++
 drivers/gpu/drm/rockchip/inno_hdmi.c          | 549 +++++++++++-------
 drivers/gpu/drm/rockchip/inno_hdmi.h          |   5 -
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c   |  13 +-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h   |   3 +
 7 files changed, 484 insertions(+), 215 deletions(-)


base-commit: 48e8992e33abf054bcc0bb2e77b2d43bb899212e
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:41:58 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:41:58 +0100
Subject: [PATCH v4 07/29] drm/rockchip: inno_hdmi: Get rid of mode_set
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-8-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 48c4f010b260..299770e481b7 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -490,21 +490,22 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	return 0;
 }
 
-static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-				       struct drm_crtc_state *crtc_state,
-				       struct drm_connector_state *conn_state)
-{
-	struct drm_display_mode *adj_mode = &crtc_state->adjusted_mode;
-	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
-
-	inno_hdmi_setup(hdmi, adj_mode);
-}
-
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 				     struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
+	struct drm_connector_state *conn_state;
+	struct drm_crtc_state *crtc_state;
+
+	conn_state = drm_atomic_get_new_connector_state(state, &hdmi->connector);
+	if (WARN_ON(!conn_state))
+		return;
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+	if (WARN_ON(!crtc_state))
+		return;
 
+	inno_hdmi_setup(hdmi, &crtc_state->adjusted_mode);
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
@@ -533,7 +534,6 @@ static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
 	.atomic_check	= inno_hdmi_encoder_atomic_check,
 	.atomic_enable	= inno_hdmi_encoder_enable,
 	.atomic_disable	= inno_hdmi_encoder_disable,
-	.atomic_mode_set	= inno_hdmi_encoder_mode_set,
 };
 
 static enum drm_connector_status
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:41:55 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:41:55 +0100
Subject: [PATCH v4 04/29] drm/rockchip: inno_hdmi: Remove useless mode_fixup
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-5-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The mode_fixup implementation doesn't do anything, so we can simply
remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 345253e033c5..0b1740b38c7b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -517,13 +517,6 @@ static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
 	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
 }
 
-static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
-					 const struct drm_display_mode *mode,
-					 struct drm_display_mode *adj_mode)
-{
-	return true;
-}
-
 static int
 inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 			       struct drm_crtc_state *crtc_state,
@@ -540,7 +533,6 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
 	.enable     = inno_hdmi_encoder_enable,
 	.disable    = inno_hdmi_encoder_disable,
-	.mode_fixup = inno_hdmi_encoder_mode_fixup,
 	.mode_set   = inno_hdmi_encoder_mode_set,
 	.atomic_check = inno_hdmi_encoder_atomic_check,
 };
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:41:57 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:41:57 +0100
Subject: [PATCH v4 06/29] drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-7-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The inno_hdmi encoder still uses the !atomic variants of enable, disable
and modeset. Convert to their atomic equivalents.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 14d2ba92a606..48c4f010b260 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -491,22 +491,25 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 }
 
 static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
-				       struct drm_display_mode *mode,
-				       struct drm_display_mode *adj_mode)
+				       struct drm_crtc_state *crtc_state,
+				       struct drm_connector_state *conn_state)
 {
+	struct drm_display_mode *adj_mode = &crtc_state->adjusted_mode;
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_setup(hdmi, adj_mode);
 }
 
-static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
+				     struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
+				      struct drm_atomic_state *state)
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
@@ -527,10 +530,10 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 }
 
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
-	.enable     = inno_hdmi_encoder_enable,
-	.disable    = inno_hdmi_encoder_disable,
-	.mode_set   = inno_hdmi_encoder_mode_set,
-	.atomic_check = inno_hdmi_encoder_atomic_check,
+	.atomic_check	= inno_hdmi_encoder_atomic_check,
+	.atomic_enable	= inno_hdmi_encoder_enable,
+	.atomic_disable	= inno_hdmi_encoder_disable,
+	.atomic_mode_set	= inno_hdmi_encoder_mode_set,
 };
 
 static enum drm_connector_status
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:00 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:00 +0100
Subject: [PATCH v4 09/29] drm/rockchip: inno_hdmi: Remove unneeded has audio flag
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-10-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The sink_has_audio flag is not used anywhere in the driver so let's get
rid of it. It's redundant with drm_display_info.has_audio anyway.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index d99896f1a73a..58aff7a9c09a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	bool sink_has_audio;
 	unsigned int enc_in_format;
 	unsigned int enc_out_format;
 	unsigned int colorimetry;
@@ -554,7 +553,6 @@ static int inno_hdmi_connector_get_modes(struct drm_connector *connector)
 
 	edid = drm_get_edid(connector, hdmi->ddc);
 	if (edid) {
-		hdmi->hdmi_data.sink_has_audio = drm_detect_monitor_audio(edid);
 		drm_connector_update_edid_property(connector, edid);
 		ret = drm_add_edid_modes(connector, edid);
 		kfree(edid);
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:41:59 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:41:59 +0100
Subject: [PATCH v4 08/29] drm/rockchip: inno_hdmi: no need to store vic
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-9-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The mode's VIC is only ever used in the inno_hdmi_setup() function so
there's no need to store it in the main structure.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
[made checkpatch happy]
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - none

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 299770e481b7..d99896f1a73a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	int vic;
 	bool sink_has_audio;
 	unsigned int enc_in_format;
 	unsigned int enc_out_format;
@@ -443,16 +442,15 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 			   struct drm_display_mode *mode)
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
-
-	hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
+	u8 vic = drm_match_cea_mode(mode);
 
 	hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
 	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
 
-	if ((hdmi->hdmi_data.vic == 6) || (hdmi->hdmi_data.vic == 7) ||
-	    (hdmi->hdmi_data.vic == 21) || (hdmi->hdmi_data.vic == 22) ||
-	    (hdmi->hdmi_data.vic == 2) || (hdmi->hdmi_data.vic == 3) ||
-	    (hdmi->hdmi_data.vic == 17) || (hdmi->hdmi_data.vic == 18))
+	if (vic == 6 || vic == 7 ||
+	    vic == 21 || vic == 22 ||
+	    vic == 2 || vic == 3 ||
+	    vic == 17 || vic == 18)
 		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
 	else
 		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:01 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:01 +0100
Subject: [PATCH v4 10/29] drm/rockchip: inno_hdmi: Remove useless input format
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-11-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The driver has a lot of logic to deal with multiple input formats, but
hardcodes it to RGB. This means that most of that code has been dead
code, so let's get rid of it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
[made checkpatch happy]
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - none

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 41 ++++++++--------------------
 1 file changed, 11 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 58aff7a9c09a..7c75feedacad 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
 #include "inno_hdmi.h"
 
 struct hdmi_data_info {
-	unsigned int enc_in_format;
 	unsigned int enc_out_format;
 	unsigned int colorimetry;
 };
@@ -328,47 +327,30 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		v_VIDEO_INPUT_CSP(0);
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
-	if (data->enc_in_format == data->enc_out_format) {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
-		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
-			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
-			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
-			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
-				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
-				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
-				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
-			return 0;
-		}
+	if (data->enc_out_format == HDMI_COLORSPACE_RGB) {
+		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+
+		hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+			  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+			  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+			  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+		return 0;
 	}
 
 	if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
-		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
-		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
-			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
-			csc_mode = CSC_ITU601_16_235_TO_RGB_0_255_8BIT;
-			auto_csc = AUTO_CSC_ENABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_DISABLE;
 		}
 	} else {
-		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
-		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
-		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
-			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
-			csc_mode = CSC_ITU709_16_235_TO_RGB_0_255_8BIT;
-			auto_csc = AUTO_CSC_ENABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_DISABLE;
 		}
 	}
 
@@ -443,7 +425,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	struct drm_display_info *display = &hdmi->connector.display_info;
 	u8 vic = drm_match_cea_mode(mode);
 
-	hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
 	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
 
 	if (vic == 6 || vic == 7 ||
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:41:54 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:41:54 +0100
Subject: [PATCH v4 03/29] drm/rockchip: inno_hdmi: Fix video timing
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-4-knaerzche@gmail.com>

The controller wants the difference between *total and *sync_start in the
HDMI_VIDEO_EXT_*DELAY registers. Otherwise the signal is very unstable for
certain non-VIC modes. See downstream commit [0].

[0] https://github.com/rockchip-linux/kernel/commit/8eb559f2502c

Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Co-developed-by: Zheng Yang <zhengyang at rock-chips.com>
Signed-off-by: Zheng Yang <zhengyang at rock-chips.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - none

changes in v3:
 - none

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 6e5b922a121e..345253e033c5 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -412,7 +412,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_L, value & 0xFF);
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_H, (value >> 8) & 0xFF);
 
-	value = mode->hsync_start - mode->hdisplay;
+	value = mode->htotal - mode->hsync_start;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_L, value & 0xFF);
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_H, (value >> 8) & 0xFF);
 
@@ -427,7 +427,7 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
 	value = mode->vtotal - mode->vdisplay;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VBLANK, value & 0xFF);
 
-	value = mode->vsync_start - mode->vdisplay;
+	value = mode->vtotal - mode->vsync_start;
 	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VDELAY, value & 0xFF);
 
 	value = mode->vsync_end - mode->vsync_start;
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:04 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:04 +0100
Subject: [PATCH v4 13/29] drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-14-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The HDMI vendor infoframe is only meant to be sent with 4k60 modes and
higher, but the controller doesn't support them. Let's drop them from
the kernel.

Suggested-by: Johan Jonker <jbx6244 at gmail.com>
Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 35 ++++++++--------------------
 1 file changed, 10 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 102195837206..5c9f1325441f 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -206,11 +206,15 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 }
 
 static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
-				  union hdmi_infoframe *frame, u32 frame_index,
-				  u32 mask, u32 disable, u32 enable)
+				  union hdmi_infoframe *frame, u32 frame_index)
 {
-	if (mask)
-		hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, disable);
+	struct drm_connector *connector = &hdmi->connector;
+
+	if (frame_index != INFOFRAME_AVI) {
+		drm_err(connector->dev,
+			"Unsupported infoframe type: %u\n", frame_index);
+		return 0;
+	}
 
 	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
 
@@ -226,28 +230,11 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
 		for (i = 0; i < rc; i++)
 			hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
 				    packed_frame[i]);
-
-		if (mask)
-			hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, enable);
 	}
 
 	return setup_rc;
 }
 
-static int inno_hdmi_config_video_vsi(struct inno_hdmi *hdmi,
-				      struct drm_display_mode *mode)
-{
-	union hdmi_infoframe frame;
-	int rc;
-
-	rc = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
-							 &hdmi->connector,
-							 mode);
-
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_VSI,
-		m_PACKET_VSI_EN, v_PACKET_VSI_EN(0), v_PACKET_VSI_EN(1));
-}
-
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 				      struct drm_display_mode *mode)
 {
@@ -265,7 +252,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
+	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
@@ -408,10 +395,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 
 	inno_hdmi_config_video_csc(hdmi);
 
-	if (display->is_hdmi) {
+	if (display->is_hdmi)
 		inno_hdmi_config_video_avi(hdmi, mode);
-		inno_hdmi_config_video_vsi(hdmi, mode);
-	}
 
 	/*
 	 * When IP controller have configured to an accurate video
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:02 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:02 +0100
Subject: [PATCH v4 11/29] drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-12-knaerzche@gmail.com>

Now that the unneeded support for YUV based input formats is gone, the csc
coefficients for those formats can be dropped as well.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - new patch

changes in v3:
 - none

changes in v4:
 - none
	
 drivers/gpu/drm/rockchip/inno_hdmi.c | 37 ----------------------------
 1 file changed, 37 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 7c75feedacad..04344ee1265d 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -74,49 +74,12 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct drm_connector *connector)
 }
 
 enum {
-	CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
-	CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
-	CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
 	CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
 	CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
 	CSC_RGB_0_255_TO_RGB_16_235_8BIT,
 };
 
 static const char coeff_csc[][24] = {
-	/*
-	 * YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
-	 *   R = 1.164*Y + 1.596*V - 204
-	 *   G = 1.164*Y - 0.391*U - 0.813*V + 154
-	 *   B = 1.164*Y + 2.018*U - 258
-	 */
-	{
-		0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
-		0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
-		0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
-	},
-	/*
-	 * YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
-	 *   R = Y + 1.402*V - 248
-	 *   G = Y - 0.344*U - 0.714*V + 135
-	 *   B = Y + 1.772*U - 227
-	 */
-	{
-		0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 0xf8,
-		0x04, 0x00, 0x11, 0x60, 0x12, 0xdb, 0x00, 0x87,
-		0x04, 0x00, 0x07, 0x16, 0x00, 0x00, 0x02, 0xe3
-	},
-	/*
-	 * YUV2RGB:709 HD mode(Y[16:235],UV[16:240],RGB[0:255]):
-	 *   R = 1.164*Y + 1.793*V - 248
-	 *   G = 1.164*Y - 0.213*U - 0.534*V + 77
-	 *   B = 1.164*Y + 2.115*U - 289
-	 */
-	{
-		0x04, 0xa7, 0x00, 0x00, 0x07, 0x2c, 0x02, 0xf8,
-		0x04, 0xa7, 0x10, 0xda, 0x12, 0x22, 0x00, 0x4d,
-		0x04, 0xa7, 0x08, 0x74, 0x00, 0x00, 0x03, 0x21
-	},
-
 	/*
 	 * RGB2YUV:601 SD mode:
 	 *   Cb = -0.291G - 0.148R + 0.439B + 128
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:03 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:03 +0100
Subject: [PATCH v4 12/29] drm/rockchip: inno_hdmi: Remove tmds rate from structure
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-13-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The tmds_rate field in the inno_hdmi structure is used mostly to
configure the internal i2c controller divider through a call to the
inno_hdmi_i2c_init() function.

We can simply make that rate an argument to that function, which also
removes a workaround to initialize the divider at probe time when we
don't have a mode yet.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v3:
 - imported patch

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 04344ee1265d..102195837206 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -56,8 +56,6 @@ struct inno_hdmi {
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
 
-	unsigned int tmds_rate;
-
 	struct hdmi_data_info	hdmi_data;
 };
 
@@ -134,11 +132,11 @@ static inline void hdmi_modb(struct inno_hdmi *hdmi, u16 offset,
 	hdmi_writeb(hdmi, offset, temp);
 }
 
-static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
+static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi, unsigned long long rate)
 {
-	int ddc_bus_freq;
+	unsigned long long ddc_bus_freq = rate >> 2;
 
-	ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE;
+	do_div(ddc_bus_freq, HDMI_SCL_RATE);
 
 	hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
 	hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
@@ -421,8 +419,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
 	 * clock rate, and reconfigure the DDC clock.
 	 */
-	hdmi->tmds_rate = mode->clock * 1000;
-	inno_hdmi_i2c_init(hdmi);
+	inno_hdmi_i2c_init(hdmi, mode->clock * 1000);
 
 	/* Unmute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -800,8 +797,7 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
 	 * and reconfigure the DDC clock.
 	 */
-	hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
-	inno_hdmi_i2c_init(hdmi);
+	inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
 
 	ret = inno_hdmi_register(drm, hdmi);
 	if (ret)
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:05 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:05 +0100
Subject: [PATCH v4 14/29] drm/rockchip: inno_hdmi: Move infoframe disable to separate function
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-15-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The code to upload infoframes to the controller uses a weird construct
which, based on the previous function call return code, will either
disable or enable that infoframe.

In order to get rid of that argument, let's split the function to
disable the infoframe into a separate function and make it obvious what
we are doing in the error path.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 46 ++++++++++++++++++----------
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 5c9f1325441f..10466c2aa520 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -205,34 +205,44 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
-				  union hdmi_infoframe *frame, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
 {
 	struct drm_connector *connector = &hdmi->connector;
 
 	if (frame_index != INFOFRAME_AVI) {
 		drm_err(connector->dev,
 			"Unsupported infoframe type: %u\n", frame_index);
-		return 0;
+		return;
 	}
 
 	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+}
 
-	if (setup_rc >= 0) {
-		u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
-		ssize_t rc, i;
-
-		rc = hdmi_infoframe_pack(frame, packed_frame,
-					 sizeof(packed_frame));
-		if (rc < 0)
-			return rc;
+static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
+				  union hdmi_infoframe *frame, u32 frame_index)
+{
+	struct drm_connector *connector = &hdmi->connector;
+	u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
+	ssize_t rc, i;
 
-		for (i = 0; i < rc; i++)
-			hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
-				    packed_frame[i]);
+	if (frame_index != INFOFRAME_AVI) {
+		drm_err(connector->dev,
+			"Unsupported infoframe type: %u\n", frame_index);
+		return 0;
 	}
 
-	return setup_rc;
+	inno_hdmi_disable_frame(hdmi, frame_index);
+
+	rc = hdmi_infoframe_pack(frame, packed_frame,
+				 sizeof(packed_frame));
+	if (rc < 0)
+		return rc;
+
+	for (i = 0; i < rc; i++)
+		hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
+			    packed_frame[i]);
+
+	return 0;
 }
 
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
@@ -244,6 +254,10 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
 						      &hdmi->connector,
 						      mode);
+	if (rc) {
+		inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+		return rc;
+	}
 
 	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
 		frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
@@ -252,7 +266,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI);
+	return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:07 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:07 +0100
Subject: [PATCH v4 16/29] drm/rockchip: inno_hdmi: Remove unused drm device pointer
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-17-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 49367ca24125..51c1a69dfcc0 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -44,7 +44,6 @@ struct inno_hdmi_i2c {
 
 struct inno_hdmi {
 	struct device *dev;
-	struct drm_device *drm_dev;
 
 	int irq;
 	struct clk *pclk;
@@ -757,7 +756,6 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		return -ENOMEM;
 
 	hdmi->dev = dev;
-	hdmi->drm_dev = drm;
 
 	hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hdmi->regs))
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:10 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:10 +0100
Subject: [PATCH v4 19/29] drm/rockchip: inno_hdmi: Subclass connector state
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-20-knaerzche@gmail.com>

The data which is currently hold in hdmi_data should not be part of device
itself but of the connector state.
Introduce a connector state subclass and move the data from hdmi_data in
there.

Suggested-by: Maxime Ripard <mripard at kernel.org>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - new patch

changes in v3:
 - added missing customizations of reset and atomic_destroy_state connector hooks
 - moved inno_conn_state member assignments to atomic_check

changes in v4:
 - added missing state destroy in reset hook

 drivers/gpu/drm/rockchip/inno_hdmi.c | 117 ++++++++++++++++++++-------
 1 file changed, 90 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index c306db90832a..e43fce968310 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,11 +26,6 @@
 
 #include "inno_hdmi.h"
 
-struct hdmi_data_info {
-	unsigned int enc_out_format;
-	unsigned int colorimetry;
-};
-
 struct inno_hdmi_i2c {
 	struct i2c_adapter adap;
 
@@ -52,8 +47,12 @@ struct inno_hdmi {
 
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
+};
 
-	struct hdmi_data_info	hdmi_data;
+struct inno_hdmi_connector_state {
+	struct drm_connector_state	base;
+	unsigned int			enc_out_format;
+	unsigned int			colorimetry;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -68,6 +67,9 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct drm_connector *connector)
 	return container_of(connector, struct inno_hdmi, connector);
 }
 
+#define to_inno_hdmi_conn_state(conn_state) \
+	container_of_const(conn_state, struct inno_hdmi_connector_state, base)
+
 enum {
 	CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
 	CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
@@ -246,6 +248,10 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
 static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 				      struct drm_display_mode *mode)
 {
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_connector_state *conn_state = connector->state;
+	struct inno_hdmi_connector_state *inno_conn_state =
+					to_inno_hdmi_conn_state(conn_state);
 	union hdmi_infoframe frame;
 	int rc;
 
@@ -257,9 +263,9 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 		return rc;
 	}
 
-	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
+	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444)
 		frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
-	else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
+	else if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV422)
 		frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
@@ -269,7 +275,10 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 {
-	struct hdmi_data_info *data = &hdmi->hdmi_data;
+	struct drm_connector *connector = &hdmi->connector;
+	struct drm_connector_state *conn_state = connector->state;
+	struct inno_hdmi_connector_state *inno_conn_state =
+					to_inno_hdmi_conn_state(conn_state);
 	int c0_c2_change = 0;
 	int csc_enable = 0;
 	int csc_mode = 0;
@@ -287,7 +296,7 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		v_VIDEO_INPUT_CSP(0);
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
-	if (data->enc_out_format == HDMI_COLORSPACE_RGB) {
+	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
 		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
 		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
 
@@ -298,15 +307,15 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 		return 0;
 	}
 
-	if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
+	if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
+		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
 		}
 	} else {
-		if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
+		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
 			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
@@ -383,17 +392,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 			   struct drm_display_mode *mode)
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
-	u8 vic = drm_match_cea_mode(mode);
-
-	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
-
-	if (vic == 6 || vic == 7 ||
-	    vic == 21 || vic == 22 ||
-	    vic == 2 || vic == 3 ||
-	    vic == 17 || vic == 18)
-		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
-	else
-		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
 
 	/* Mute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -458,10 +456,24 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 			       struct drm_connector_state *conn_state)
 {
 	struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+	struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+	u8 vic = drm_match_cea_mode(mode);
+	struct inno_hdmi_connector_state *inno_conn_state =
+					to_inno_hdmi_conn_state(conn_state);
 
 	s->output_mode = ROCKCHIP_OUT_MODE_P888;
 	s->output_type = DRM_MODE_CONNECTOR_HDMIA;
 
+	if (vic == 6 || vic == 7 ||
+	    vic == 21 || vic == 22 ||
+	    vic == 2 || vic == 3 ||
+	    vic == 17 || vic == 18)
+		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_601;
+	else
+		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
+
+	inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB;
+
 	return 0;
 }
 
@@ -519,13 +531,63 @@ static void inno_hdmi_connector_destroy(struct drm_connector *connector)
 	drm_connector_cleanup(connector);
 }
 
+static void
+inno_hdmi_connector_destroy_state(struct drm_connector *connector,
+				  struct drm_connector_state *state)
+{
+	struct inno_hdmi_connector_state *inno_conn_state =
+						to_inno_hdmi_conn_state(state);
+
+	__drm_atomic_helper_connector_destroy_state(&inno_conn_state->base);
+	kfree(inno_conn_state);
+}
+
+static void inno_hdmi_connector_reset(struct drm_connector *connector)
+{
+	struct inno_hdmi_connector_state *inno_conn_state;
+
+	if (connector->state) {
+		inno_hdmi_connector_destroy_state(connector, connector->state);
+		connector->state = NULL;
+	}
+
+	inno_conn_state = kzalloc(sizeof(*inno_conn_state), GFP_KERNEL);
+	if (!inno_conn_state)
+		return;
+
+	__drm_atomic_helper_connector_reset(connector, &inno_conn_state->base);
+
+	inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
+	inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB;
+}
+
+static struct drm_connector_state *
+inno_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+	struct inno_hdmi_connector_state *inno_conn_state;
+
+	if (WARN_ON(!connector->state))
+		return NULL;
+
+	inno_conn_state = kmemdup(to_inno_hdmi_conn_state(connector->state),
+				  sizeof(*inno_conn_state), GFP_KERNEL);
+
+	if (!inno_conn_state)
+		return NULL;
+
+	__drm_atomic_helper_connector_duplicate_state(connector,
+						      &inno_conn_state->base);
+
+	return &inno_conn_state->base;
+}
+
 static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
 	.fill_modes = inno_hdmi_probe_single_connector_modes,
 	.detect = inno_hdmi_connector_detect,
 	.destroy = inno_hdmi_connector_destroy,
-	.reset = drm_atomic_helper_connector_reset,
-	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+	.reset = inno_hdmi_connector_reset,
+	.atomic_duplicate_state = inno_hdmi_connector_duplicate_state,
+	.atomic_destroy_state = inno_hdmi_connector_destroy_state,
 };
 
 static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = {
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:11 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:11 +0100
Subject: [PATCH v4 20/29] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-21-knaerzche@gmail.com>

The display controller will always give full range RGB regardless of the
mode set, but HDMI requires certain modes to be transmitted in limited
range RGB. This is especially required for HDMI sinks which do not support
non-standard quantization ranges.

This enables color space conversion for those modes and sets the
quantization range accordingly in the AVI infoframe.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - made rgb_limited_range part of the new custom connector state

changes in v3:
 - moved assignment of rgb_limited_range to atomic check

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 60 +++++++++++++++++++---------
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e43fce968310..f3b90b479ab9 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -53,6 +53,7 @@ struct inno_hdmi_connector_state {
 	struct drm_connector_state	base;
 	unsigned int			enc_out_format;
 	unsigned int			colorimetry;
+	bool				rgb_limited_range;
 };
 
 static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -270,6 +271,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
+	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
+		drm_hdmi_avi_infoframe_quant_range(&frame.avi,
+						   connector, mode,
+						   inno_conn_state->rgb_limited_range ?
+						   HDMI_QUANTIZATION_RANGE_LIMITED :
+						   HDMI_QUANTIZATION_RANGE_FULL);
+	} else {
+		frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
+		frame.avi.ycc_quantization_range =
+			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
+	}
+
 	return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI);
 }
 
@@ -297,29 +310,37 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
 	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
 
 	if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_RGB) {
-		value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
-		hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
-		hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
-			  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
-			  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
-			  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
-		return 0;
-	}
-
-	if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
-		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
-			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
+		if (inno_conn_state->rgb_limited_range) {
+			csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
 			auto_csc = AUTO_CSC_DISABLE;
 			c0_c2_change = C0_C2_CHANGE_DISABLE;
 			csc_enable = v_CSC_ENABLE;
+
+		} else {
+			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+
+			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+			return 0;
 		}
 	} else {
-		if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
-			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
-			auto_csc = AUTO_CSC_DISABLE;
-			c0_c2_change = C0_C2_CHANGE_DISABLE;
-			csc_enable = v_CSC_ENABLE;
+		if (inno_conn_state->colorimetry == HDMI_COLORIMETRY_ITU_601) {
+			if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
+				csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
+				auto_csc = AUTO_CSC_DISABLE;
+				c0_c2_change = C0_C2_CHANGE_DISABLE;
+				csc_enable = v_CSC_ENABLE;
+			}
+		} else {
+			if (inno_conn_state->enc_out_format == HDMI_COLORSPACE_YUV444) {
+				csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
+				auto_csc = AUTO_CSC_DISABLE;
+				c0_c2_change = C0_C2_CHANGE_DISABLE;
+				csc_enable = v_CSC_ENABLE;
+			}
 		}
 	}
 
@@ -473,6 +494,8 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 		inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
 
 	inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB;
+	inno_conn_state->rgb_limited_range =
+		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
 
 	return 0;
 }
@@ -559,6 +582,7 @@ static void inno_hdmi_connector_reset(struct drm_connector *connector)
 
 	inno_conn_state->colorimetry = HDMI_COLORIMETRY_ITU_709;
 	inno_conn_state->enc_out_format = HDMI_COLORSPACE_RGB;
+	inno_conn_state->rgb_limited_range = false;
 }
 
 static struct drm_connector_state *
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:13 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:13 +0100
Subject: [PATCH v4 22/29] drm/rockchip: inno_hdmi: Split power mode setting
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-23-knaerzche@gmail.com>

This splits setting the power mode of the controller / phy in two
functions. It's done in preparation of setting up the phy based on the
pixelclock.

No functional changes intended.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v3:
 - new patch

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 54 +++++++++++++---------------
 drivers/gpu/drm/rockchip/inno_hdmi.h |  5 ---
 2 files changed, 24 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 52b49f44a4f4..44c311e7e2d3 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -154,38 +154,31 @@ static void inno_hdmi_sys_power(struct inno_hdmi *hdmi, bool enable)
 		hdmi_modb(hdmi, HDMI_SYS_CTRL, m_POWER, v_PWR_OFF);
 }
 
-static void inno_hdmi_set_pwr_mode(struct inno_hdmi *hdmi, int mode)
+static void inno_hdmi_standby(struct inno_hdmi *hdmi)
 {
-	switch (mode) {
-	case NORMAL:
-		inno_hdmi_sys_power(hdmi, false);
+	inno_hdmi_sys_power(hdmi, false);
 
-		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
-		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
-
-		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
-		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
-		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
-		hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x0f);
-		hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x00);
-		hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x01);
-
-		inno_hdmi_sys_power(hdmi, true);
-		break;
+	hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0x00);
+	hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x00);
+	hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x00);
+	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+};
 
-	case LOWER_PWR:
-		inno_hdmi_sys_power(hdmi, false);
-		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0x00);
-		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x00);
-		hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x00);
-		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+static void inno_hdmi_power_up(struct inno_hdmi *hdmi)
+{
+	inno_hdmi_sys_power(hdmi, false);
 
-		break;
+	hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
+	hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
+	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
+	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
+	hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x0f);
+	hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x00);
+	hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x01);
 
-	default:
-		DRM_DEV_ERROR(hdmi->dev, "Unknown power mode %d\n", mode);
-	}
-}
+	inno_hdmi_sys_power(hdmi, true);
+};
 
 static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 {
@@ -202,7 +195,7 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	val = v_REG_CLK_INV | v_REG_CLK_SOURCE_SYS | v_PWR_ON | v_INT_POL_HIGH;
 	hdmi_modb(hdmi, HDMI_SYS_CTRL, msk, val);
 
-	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
+	inno_hdmi_standby(hdmi);
 }
 
 static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
@@ -441,6 +434,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
 		  v_AUDIO_MUTE(0) | v_VIDEO_MUTE(0));
 
+	inno_hdmi_power_up(hdmi);
+
 	return 0;
 }
 
@@ -460,7 +455,6 @@ static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 		return;
 
 	inno_hdmi_setup(hdmi, &crtc_state->adjusted_mode);
-	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
 static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
@@ -468,7 +462,7 @@ static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
 {
 	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
-	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
+	inno_hdmi_standby(hdmi);
 }
 
 static int
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.h b/drivers/gpu/drm/rockchip/inno_hdmi.h
index 93245b55f967..a7edf3559e60 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.h
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.h
@@ -10,11 +10,6 @@
 
 #define DDC_SEGMENT_ADDR		0x30
 
-enum PWR_MODE {
-	NORMAL,
-	LOWER_PWR,
-};
-
 #define HDMI_SCL_RATE			(100*1000)
 #define DDC_BUS_FREQ_L			0x4b
 #define DDC_BUS_FREQ_H			0x4c
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:12 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:12 +0100
Subject: [PATCH v4 21/29] drm/rockchip: inno_hdmi: Don't power up the phy after resetting
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-22-knaerzche@gmail.com>

inno_hdmi_reset is only ever called when initializing the controller. At
this point it?s completely uneccessary to power up the PHY, since all
what has to work at this point is the DDC bus. The phy will be powered up
correctly when a mode is set in inno_hdmi_encoder_enable and disabled in
inno_hdmi_encoder_disable.
Set it to LOWER_PWR after resetting the controller.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v3:
 - new patch

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f3b90b479ab9..52b49f44a4f4 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -202,7 +202,7 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	val = v_REG_CLK_INV | v_REG_CLK_SOURCE_SYS | v_PWR_ON | v_INT_POL_HIGH;
 	hdmi_modb(hdmi, HDMI_SYS_CTRL, msk, val);
 
-	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
+	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
 }
 
 static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:16 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:16 +0100
Subject: [PATCH v4 25/29] drm/rockchip: inno_hdmi: Add basic mode validation
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-26-knaerzche@gmail.com>

As per TRM this controller supports pixelclocks starting from 25 MHz. The
maximum supported pixelclocks are defined by the phy configurations we
have. Also it can't support modes that require doubled clocks. If the
variant has a phy reference clock we can additionally validate against VESA
DMT'srecommendations.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Maxime Ripard <mripard at kernel.org>
---
changes in v2:
 - rename inno_mode_valid -> inno_hdmi_display_mode_valid
 - fixed max_tolerance calculation
 - use abs_diff() instead of abs()
 - call in inno_hdmi_display_mode_valid in atomic_check

changes in v3:
 - collect RB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 42 ++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 3b76929deefe..a074451a0c49 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,6 +26,8 @@
 
 #include "inno_hdmi.h"
 
+#define INNO_HDMI_MIN_TMDS_CLOCK  25000000U
+
 struct inno_hdmi_phy_config {
 	unsigned long pixelclock;
 	u8 pre_emphasis;
@@ -497,6 +499,38 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	return 0;
 }
 
+static enum drm_mode_status inno_hdmi_display_mode_valid(struct inno_hdmi *hdmi,
+							 struct drm_display_mode *mode)
+{
+	unsigned long mpixelclk, max_tolerance;
+	long rounded_refclk;
+
+	/* No support for double-clock modes */
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+		return MODE_BAD;
+
+	mpixelclk = mode->clock * 1000;
+
+	if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
+		return MODE_CLOCK_LOW;
+
+	if (inno_hdmi_find_phy_config(hdmi, mpixelclk) < 0)
+		return MODE_CLOCK_HIGH;
+
+	if (hdmi->refclk) {
+		rounded_refclk = clk_round_rate(hdmi->refclk, mpixelclk);
+		if (rounded_refclk < 0)
+			return MODE_BAD;
+
+		/* Vesa DMT standard mentions +/- 0.5% max tolerance */
+		max_tolerance = mpixelclk / 200;
+		if (abs_diff((unsigned long)rounded_refclk, mpixelclk) > max_tolerance)
+			return MODE_NOCLOCK;
+	}
+
+	return MODE_OK;
+}
+
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
 				     struct drm_atomic_state *state)
 {
@@ -529,6 +563,7 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 			       struct drm_connector_state *conn_state)
 {
 	struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 	struct drm_display_mode *mode = &crtc_state->adjusted_mode;
 	u8 vic = drm_match_cea_mode(mode);
 	struct inno_hdmi_connector_state *inno_conn_state =
@@ -549,7 +584,8 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
 	inno_conn_state->rgb_limited_range =
 		drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
 
-	return 0;
+	return  inno_hdmi_display_mode_valid(hdmi,
+				&crtc_state->adjusted_mode) == MODE_OK ? 0 : -EINVAL;
 }
 
 static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
@@ -590,7 +626,9 @@ static enum drm_mode_status
 inno_hdmi_connector_mode_valid(struct drm_connector *connector,
 			       struct drm_display_mode *mode)
 {
-	return MODE_OK;
+	struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
+
+	return  inno_hdmi_display_mode_valid(hdmi, mode);
 }
 
 static int
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:17 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:17 +0100
Subject: [PATCH v4 26/29] drm/rockchip: inno_hdmi: Drop custom fill_modes hook
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-27-knaerzche@gmail.com>

Now that we have proper pixelclock-based mode validation we can drop the
custom fill_modes hook.
CRTC size validation for the display controller has been added with
Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
hardware capabilities")

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Maxime Ripard <mripard at kernel.org>
---
changes in v2:
 - no changes

changes in v3:
 - collect RB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index a074451a0c49..d7453c36d37a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -630,13 +630,6 @@ inno_hdmi_connector_mode_valid(struct drm_connector *connector,
 	return  inno_hdmi_display_mode_valid(hdmi, mode);
 }
 
-static int
-inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
-				       uint32_t maxX, uint32_t maxY)
-{
-	return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
-}
-
 static void inno_hdmi_connector_destroy(struct drm_connector *connector)
 {
 	drm_connector_unregister(connector);
@@ -695,7 +688,7 @@ inno_hdmi_connector_duplicate_state(struct drm_connector *connector)
 }
 
 static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
-	.fill_modes = inno_hdmi_probe_single_connector_modes,
+	.fill_modes = drm_helper_probe_single_connector_modes,
 	.detect = inno_hdmi_connector_detect,
 	.destroy = inno_hdmi_connector_destroy,
 	.reset = inno_hdmi_connector_reset,
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:18 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:18 +0100
Subject: [PATCH v4 27/29] ARM: dts: rockchip: Add display subsystem for RK3128
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-28-knaerzche@gmail.com>

Add vop and display-subsystem nodes to RK3128's device tree.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - no changes

changes in v4:
 - none

 arch/arm/boot/dts/rockchip/rk3128.dtsi | 27 ++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index e2264c40b924..1a3bc8b2bc6e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -115,6 +115,12 @@ opp-1200000000 {
 		};
 	};
 
+	display_subsystem: display-subsystem {
+		compatible = "rockchip,display-subsystem";
+		ports = <&vop_out>;
+		status = "disabled";
+	};
+
 	gpu_opp_table: opp-table-1 {
 		compatible = "operating-points-v2";
 
@@ -246,6 +252,27 @@ power-domain at RK3128_PD_GPU {
 		};
 	};
 
+	vop: vop at 1010e000 {
+		compatible = "rockchip,rk3126-vop";
+		reg = <0x1010e000 0x300>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru ACLK_LCDC0>, <&cru DCLK_VOP>,
+			 <&cru HCLK_LCDC0>;
+		clock-names = "aclk_vop", "dclk_vop",
+			      "hclk_vop";
+		resets = <&cru SRST_VOP_A>, <&cru SRST_VOP_H>,
+			 <&cru SRST_VOP_D>;
+		reset-names = "axi", "ahb",
+			      "dclk";
+		power-domains = <&power RK3128_PD_VIO>;
+		status = "disabled";
+
+		vop_out: port {
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	qos_gpu: qos at 1012d000 {
 		compatible = "rockchip,rk3128-qos", "syscon";
 		reg = <0x1012d000 0x20>;
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:14 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:14 +0100
Subject: [PATCH v4 23/29] drm/rockchip: inno_hdmi: Add variant support
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-24-knaerzche@gmail.com>

In preparation to support RK3128's integration of the controller, this
patch adds a simple variant implementation. They mainly differ in the phy
configuration required, so those are part of the match_data. The values
have been taken from downstream. The pixelclocks in there are meant to be
max-inclusive.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - adapt to the newly introduced inno_hdmi_power_up / inno_hdmi_standby functions

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 74 ++++++++++++++++++++++++++--
 1 file changed, 69 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 44c311e7e2d3..34f0358e8d7b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,6 +26,17 @@
 
 #include "inno_hdmi.h"
 
+struct inno_hdmi_phy_config {
+	unsigned long pixelclock;
+	u8 pre_emphasis;
+	u8 voltage_level_control;
+};
+
+struct inno_hdmi_variant {
+	struct inno_hdmi_phy_config *phy_configs;
+	struct inno_hdmi_phy_config *default_phy_config;
+};
+
 struct inno_hdmi_i2c {
 	struct i2c_adapter adap;
 
@@ -47,6 +58,8 @@ struct inno_hdmi {
 
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
+
+	const struct inno_hdmi_variant *variant;
 };
 
 struct inno_hdmi_connector_state {
@@ -113,6 +126,30 @@ static const char coeff_csc[][24] = {
 	},
 };
 
+static struct inno_hdmi_phy_config rk3036_hdmi_phy_configs[] = {
+	{  74250000, 0x3f, 0xbb },
+	{ 165000000, 0x6f, 0xbb },
+	{      ~0UL, 0x00, 0x00 }
+};
+
+static int inno_hdmi_find_phy_config(struct inno_hdmi *hdmi,
+				     unsigned long pixelclk)
+{
+	const struct inno_hdmi_phy_config *phy_configs =
+						hdmi->variant->phy_configs;
+	int i;
+
+	for (i = 0; phy_configs[i].pixelclock != ~0UL; i++) {
+		if (pixelclk <= phy_configs[i].pixelclock)
+			return i;
+	}
+
+	DRM_DEV_DEBUG(hdmi->dev, "No phy configuration for pixelclock %lu\n",
+		      pixelclk);
+
+	return -EINVAL;
+}
+
 static inline u8 hdmi_readb(struct inno_hdmi *hdmi, u16 offset)
 {
 	return readl_relaxed(hdmi->regs + (offset) * 0x04);
@@ -164,12 +201,25 @@ static void inno_hdmi_standby(struct inno_hdmi *hdmi)
 	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
 };
 
-static void inno_hdmi_power_up(struct inno_hdmi *hdmi)
+static void inno_hdmi_power_up(struct inno_hdmi *hdmi,
+			       unsigned long mpixelclock)
 {
+	struct inno_hdmi_phy_config *phy_config;
+	int ret = inno_hdmi_find_phy_config(hdmi, mpixelclock);
+
+	if (ret < 0) {
+		phy_config = hdmi->variant->default_phy_config;
+		DRM_DEV_ERROR(hdmi->dev,
+			      "Using default phy configuration for TMDS rate %lu",
+			      mpixelclock);
+	} else {
+		phy_config = &hdmi->variant->phy_configs[ret];
+	}
+
 	inno_hdmi_sys_power(hdmi, false);
 
-	hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
-	hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
+	hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, phy_config->pre_emphasis);
+	hdmi_writeb(hdmi, HDMI_PHY_DRIVER, phy_config->voltage_level_control);
 	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
 	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
 	hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
@@ -406,6 +456,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 			   struct drm_display_mode *mode)
 {
 	struct drm_display_info *display = &hdmi->connector.display_info;
+	unsigned long mpixelclock = mode->clock * 1000;
 
 	/* Mute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -428,13 +479,13 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
 	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
 	 * clock rate, and reconfigure the DDC clock.
 	 */
-	inno_hdmi_i2c_init(hdmi, mode->clock * 1000);
+	inno_hdmi_i2c_init(hdmi, mpixelclock);
 
 	/* Unmute video and audio output */
 	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
 		  v_AUDIO_MUTE(0) | v_VIDEO_MUTE(0));
 
-	inno_hdmi_power_up(hdmi);
+	inno_hdmi_power_up(hdmi, mpixelclock);
 
 	return 0;
 }
@@ -827,6 +878,7 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	struct platform_device *pdev = to_platform_device(dev);
 	struct drm_device *drm = data;
 	struct inno_hdmi *hdmi;
+	const struct inno_hdmi_variant *variant;
 	int irq;
 	int ret;
 
@@ -836,6 +888,12 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 
 	hdmi->dev = dev;
 
+	variant = of_device_get_match_data(hdmi->dev);
+	if (!variant)
+		return -EINVAL;
+
+	hdmi->variant = variant;
+
 	hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hdmi->regs))
 		return PTR_ERR(hdmi->regs);
@@ -929,8 +987,14 @@ static void inno_hdmi_remove(struct platform_device *pdev)
 	component_del(&pdev->dev, &inno_hdmi_ops);
 }
 
+static const struct inno_hdmi_variant rk3036_inno_hdmi_variant = {
+	.phy_configs = rk3036_hdmi_phy_configs,
+	.default_phy_config = &rk3036_hdmi_phy_configs[1],
+};
+
 static const struct of_device_id inno_hdmi_dt_ids[] = {
 	{ .compatible = "rockchip,rk3036-inno-hdmi",
+	  .data = &rk3036_inno_hdmi_variant,
 	},
 	{},
 };
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:20 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:20 +0100
Subject: [PATCH v4 29/29] ARM: dts: rockchip: Enable HDMI output for XPI-3128
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-30-knaerzche@gmail.com>

Add an hdmi-connector node and enable the hdmi, display-subsystem and vop
nodes.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - no changes

changes in v4:
 - none

 .../arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
index 03a97881519a..21c1678f4e91 100644
--- a/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
+++ b/arch/arm/boot/dts/rockchip/rk3128-xpi-3128.dts
@@ -47,6 +47,17 @@ dc_5v: dc-5v-regulator {
 		regulator-boot-on;
 	};
 
+	hdmi-connnector {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_connector_in: endpoint {
+				remote-endpoint = <&hdmi_connector_out>;
+			};
+		};
+	};
+
 	/*
 	 * This is a vbus-supply, which also supplies the GL852G usb hub,
 	 * thus has to be always-on
@@ -239,6 +250,10 @@ &cpu0 {
 	cpu-supply = <&vdd_arm>;
 };
 
+&display_subsystem {
+	status = "okay";
+};
+
 &emmc {
 	bus-width = <8>;
 	vmmc-supply = <&vcc_io>;
@@ -328,6 +343,16 @@ &gpu {
 	status = "okay";
 };
 
+&hdmi {
+	status = "okay";
+};
+
+&hdmi_out {
+	hdmi_connector_out: endpoint {
+		remote-endpoint = <&hdmi_connector_in>;
+	};
+};
+
 &mdio {
 	phy0: ethernet-phy at 1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
@@ -423,3 +448,7 @@ &usb2phy_host {
 &usb2phy_otg {
 	status = "okay";
 };
+
+&vop {
+	status = "okay";
+};
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:06 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:06 +0100
Subject: [PATCH v4 15/29] drm/rockchip: inno_hdmi: Switch to infoframe type
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-16-knaerzche@gmail.com>

From: Maxime Ripard <mripard at kernel.org>

The inno_hdmi driver relies on its own internal infoframe type matching
the hardware.

This works fine, but in order to make further reworks easier, let's
switch to the HDMI spec definition of those types.

Signed-off-by: Maxime Ripard <mripard at kernel.org>
Tested-by: Alex Bee <knaerzche at gmail.com>
Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - imported patch

changes in v3:
 - added my SoB

changes in v4:
 - none
 
 drivers/gpu/drm/rockchip/inno_hdmi.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 10466c2aa520..49367ca24125 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -205,33 +205,34 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
-static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
+				    enum hdmi_infoframe_type type)
 {
 	struct drm_connector *connector = &hdmi->connector;
 
-	if (frame_index != INFOFRAME_AVI) {
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
-			"Unsupported infoframe type: %u\n", frame_index);
+			"Unsupported infoframe type: %u\n", type);
 		return;
 	}
 
-	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI);
 }
 
 static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
-				  union hdmi_infoframe *frame, u32 frame_index)
+				  union hdmi_infoframe *frame, enum hdmi_infoframe_type type)
 {
 	struct drm_connector *connector = &hdmi->connector;
 	u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
 	ssize_t rc, i;
 
-	if (frame_index != INFOFRAME_AVI) {
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
 		drm_err(connector->dev,
-			"Unsupported infoframe type: %u\n", frame_index);
+			"Unsupported infoframe type: %u\n", type);
 		return 0;
 	}
 
-	inno_hdmi_disable_frame(hdmi, frame_index);
+	inno_hdmi_disable_frame(hdmi, type);
 
 	rc = hdmi_infoframe_pack(frame, packed_frame,
 				 sizeof(packed_frame));
@@ -255,7 +256,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 						      &hdmi->connector,
 						      mode);
 	if (rc) {
-		inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
+		inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI);
 		return rc;
 	}
 
@@ -266,7 +267,7 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
 	else
 		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-	return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI);
+	return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI);
 }
 
 static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:09 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:09 +0100
Subject: [PATCH v4 18/29] drm/rockchip: inno_hdmi: Remove useless include
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-19-knaerzche@gmail.com>

The inclusion syscon.h isn't used anywhere. Remove it.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Maxime Ripard <mripard at kernel.org>
---
changes in v2:
 - new patch

changes in v3:
 - collect RB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 138cd4287dea..c306db90832a 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -10,7 +10,6 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/hdmi.h>
-#include <linux/mfd/syscon.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:08 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:08 +0100
Subject: [PATCH v4 17/29] drm/rockchip: inno_hdmi: Drop irq struct member
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-18-knaerzche@gmail.com>

The struct member irq isn't used anywhere. Drop it.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
Reviewed-by: Maxime Ripard <mripard at kernel.org>
---
changes in v2:
 - new patch

changes in v3:
 - collect RB

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 51c1a69dfcc0..138cd4287dea 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -45,7 +45,6 @@ struct inno_hdmi_i2c {
 struct inno_hdmi {
 	struct device *dev;
 
-	int irq;
 	struct clk *pclk;
 	void __iomem *regs;
 
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:15 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:15 +0100
Subject: [PATCH v4 24/29] drm/rockchip: inno_hdmi: Add RK3128 support
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-25-knaerzche@gmail.com>

This variant requires the phy reference clock to be enabled before the DDC
block can work and the (initial) DDC bus frequency is calculated based on
the rate of this clock. Besides the only difference is phy configuration
required to make the driver working for this variant as well.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - no changes

changes in v4:
 - none

 drivers/gpu/drm/rockchip/inno_hdmi.c | 46 +++++++++++++++++++++++++---
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 34f0358e8d7b..3b76929deefe 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -51,6 +51,7 @@ struct inno_hdmi {
 	struct device *dev;
 
 	struct clk *pclk;
+	struct clk *refclk;
 	void __iomem *regs;
 
 	struct drm_connector	connector;
@@ -132,6 +133,12 @@ static struct inno_hdmi_phy_config rk3036_hdmi_phy_configs[] = {
 	{      ~0UL, 0x00, 0x00 }
 };
 
+static struct inno_hdmi_phy_config rk3128_hdmi_phy_configs[] = {
+	{  74250000, 0x3f, 0xaa },
+	{ 165000000, 0x5f, 0xaa },
+	{      ~0UL, 0x00, 0x00 }
+};
+
 static int inno_hdmi_find_phy_config(struct inno_hdmi *hdmi,
 				     unsigned long pixelclk)
 {
@@ -911,6 +918,20 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 		return ret;
 	}
 
+	hdmi->refclk = devm_clk_get_optional(hdmi->dev, "ref");
+	if (IS_ERR(hdmi->refclk)) {
+		DRM_DEV_ERROR(hdmi->dev, "Unable to get HDMI reference clock\n");
+		ret = PTR_ERR(hdmi->refclk);
+		goto err_disable_pclk;
+	}
+
+	ret = clk_prepare_enable(hdmi->refclk);
+	if (ret) {
+		DRM_DEV_ERROR(hdmi->dev,
+			      "Cannot enable HDMI reference clock: %d\n", ret);
+		goto err_disable_pclk;
+	}
+
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		ret = irq;
@@ -927,12 +948,16 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	}
 
 	/*
-	 * When IP controller haven't configured to an accurate video
-	 * timing, then the TMDS clock source would be switched to
-	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
-	 * and reconfigure the DDC clock.
+	 * When the controller isn't configured to an accurate
+	 * video timing and there is no reference clock available,
+	 * then the TMDS clock source would be switched to PCLK_HDMI,
+	 * so we need to init the TMDS rate to PCLK rate, and
+	 * reconfigure the DDC clock.
 	 */
-	inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
+	if (hdmi->refclk)
+		inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->refclk));
+	else
+		inno_hdmi_i2c_init(hdmi, clk_get_rate(hdmi->pclk));
 
 	ret = inno_hdmi_register(drm, hdmi);
 	if (ret)
@@ -956,6 +981,8 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 err_put_adapter:
 	i2c_put_adapter(hdmi->ddc);
 err_disable_clk:
+	clk_disable_unprepare(hdmi->refclk);
+err_disable_pclk:
 	clk_disable_unprepare(hdmi->pclk);
 	return ret;
 }
@@ -969,6 +996,7 @@ static void inno_hdmi_unbind(struct device *dev, struct device *master,
 	hdmi->encoder.encoder.funcs->destroy(&hdmi->encoder.encoder);
 
 	i2c_put_adapter(hdmi->ddc);
+	clk_disable_unprepare(hdmi->refclk);
 	clk_disable_unprepare(hdmi->pclk);
 }
 
@@ -992,10 +1020,18 @@ static const struct inno_hdmi_variant rk3036_inno_hdmi_variant = {
 	.default_phy_config = &rk3036_hdmi_phy_configs[1],
 };
 
+static const struct inno_hdmi_variant rk3128_inno_hdmi_variant = {
+	.phy_configs = rk3128_hdmi_phy_configs,
+	.default_phy_config = &rk3128_hdmi_phy_configs[1],
+};
+
 static const struct of_device_id inno_hdmi_dt_ids[] = {
 	{ .compatible = "rockchip,rk3036-inno-hdmi",
 	  .data = &rk3036_inno_hdmi_variant,
 	},
+	{ .compatible = "rockchip,rk3128-inno-hdmi",
+	  .data = &rk3128_inno_hdmi_variant,
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, inno_hdmi_dt_ids);
-- 
2.43.0



From knaerzche at gmail.com  Fri Dec 22 09:42:19 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:42:19 +0100
Subject: [PATCH v4 28/29] ARM: dts: rockchip: Add HDMI node for RK3128
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <20231222174220.55249-29-knaerzche@gmail.com>

RK3128 has Innosilicon based HDMI TX controller similar to the one found in
RK3036.
Add it and the respective port nodes to the SoC device tree.

Signed-off-by: Alex Bee <knaerzche at gmail.com>
---
changes in v2:
 - no changes

changes in v3:
 - no changes

changes in v4:
 - none

 arch/arm/boot/dts/rockchip/rk3128.dtsi | 33 ++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index 1a3bc8b2bc6e..fb98873fd94e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -270,6 +270,11 @@ vop: vop at 1010e000 {
 		vop_out: port {
 			#address-cells = <1>;
 			#size-cells = <0>;
+
+			vop_out_hdmi: endpoint at 0 {
+				reg = <0>;
+				remote-endpoint = <&hdmi_in_vop>;
+			};
 		};
 	};
 
@@ -463,6 +468,34 @@ usb2phy_otg: otg-port {
 		};
 	};
 
+	hdmi: hdmi at 20034000 {
+		compatible = "rockchip,rk3128-inno-hdmi";
+		reg = <0x20034000 0x4000>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru PCLK_HDMI>, <&cru DCLK_VOP>;
+		clock-names = "pclk", "ref";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hdmii2c_xfer &hdmi_hpd &hdmi_cec>;
+		power-domains = <&power RK3128_PD_VIO>;
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			hdmi_in: port at 0 {
+				reg = <0>;
+				hdmi_in_vop: endpoint {
+					remote-endpoint = <&vop_out_hdmi>;
+				};
+			};
+
+			hdmi_out: port at 1 {
+				reg = <1>;
+			};
+		};
+	};
+
 	timer0: timer at 20044000 {
 		compatible = "rockchip,rk3128-timer", "rockchip,rk3288-timer";
 		reg = <0x20044000 0x20>;
-- 
2.43.0



From cristian.marussi at arm.com  Fri Dec 22 09:43:53 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 22 Dec 2023 17:43:53 +0000
Subject: [PATCH 7/7] pinctrl: scmi: implement
 pinctrl_scmi_imx_dt_node_to_map
In-Reply-To: <20231215-pinctrl-scmi-v1-7-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-7-0fe35e4611f7@nxp.com>
Message-ID: <ZYXK2YVJ1nnETSuI@pluto>

On Fri, Dec 15, 2023 at 07:56:35PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> i.MX95 System Manager FW supports SCMI PINCTRL protocol, but uses
> OEM Pin Configuration type, so need i.MX specific dt_node_to_map.
> 

This does not even compile for me, as of now, when configuring the Pinctrl
SCMI driver as a module with your IMX custom additions. (I think the
Makefile with the additional pinctrl-imx is wrong in how describes the
objects composing the pinctrl-scmi module with IMX addons...)

ERROR: modpost: "pinctrl_scmi_imx_dt_node_to_map" [drivers/pinctrl/pinctrl-scmi.ko] undefined!              
make[3]: *** [dev/src/linux/scripts/Makefile.modpost:145: Module.symvers] Error 1                                   
make[2]: *** [dev/src/linux/Makefile:1863: modpost] Error 2                                                         
make[1]: *** [dev/src/linux/Makefile:234: __sub-make] Error 2 
make[1]: Leaving directory dev/out_linux       
make: *** [Makefile:234: __sub-make] Error 2                                                  

More in general, I think that this NXP OEM specific additions, which are
in general welcome (and indeed as you know part of the spec was modified
to allow for OEM specific needs), do NOT belong to this generic SCMI
Pinctrl driver, because the driver from Oleksii/EPAM was born as a
generic SCMI driver and it fits perfectly with the Generic Pinctrl
Linux subsystem and related generic bindings parsing: now with this
you are trying to stick a custom OEM slight varied behaviour (and
related binding) on top of a generic thing.

And this choice leads to a number of additional changes in the SCMI core
to support an even more complex handling of SCMI devices, which is
already too complex IMO..

IOW...I dont think that the whole idea of the per-protocol optional
compatible to be able to select slightly different behaviours/parsing
would have a great chance to fly sincerely...

I know there is an issue with having a completely distinct SCMI IMX
pinctrl driver that uses the same protocol node @19 (without the need for
the compatible trick) due to the way in which the Pinctrl subsystem
searches for devices (by of_node)...I'll think about an alternative
way to allow this but I am not sure (as you saw) that would be so easily
doable...

Also, I am wondering if this is really a problem in reality since I would
NOT expect you to load/ship both the OEM/NXP custom specific SCMI pinctrl
driver AND the generic one on the same platform (after having made them
distinct I mean...) am I wrong ?
(so you could even made them exclude each other at compile time...far
from being the best option I agree...)

Thanks,
Cristian


From cristian.marussi at arm.com  Fri Dec 22 09:46:56 2023
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Fri, 22 Dec 2023 17:46:56 +0000
Subject: [PATCH 4/7] dt-bindings: firmware: arm,scmi: support pinctrl
 protocol
In-Reply-To: <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-4-0fe35e4611f7@nxp.com>
Message-ID: <ZYXLkIPG3QFY89RY@pluto>

On Fri, Dec 15, 2023 at 07:56:32PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Add SCMI v3.2 pinctrl protocol bindings and example.
> 

Hi

as I mentioned on the last patch review, I dont see adding all this
vendor specific stuff in the ARM SCMI Pinctrl generic binding as a
viable option, nor the per-protocol compatible to select slightly
different behaviours.

Thanks,
Cristian


From masahiroy at kernel.org  Fri Dec 22 09:50:55 2023
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Sat, 23 Dec 2023 02:50:55 +0900
Subject: [PATCH v7 1/3] check-uapi: Introduce check-uapi.sh
In-Reply-To: <20231212020259.2451253-2-quic_johmoo@quicinc.com>
References: <20231212020259.2451253-1-quic_johmoo@quicinc.com> <20231212020259.2451253-2-quic_johmoo@quicinc.com>
Message-ID: <CAK7LNASZzeJzZV0hiMrcKd6FUtQXqfuvUqux8Bf+WvBmjCwNCA@mail.gmail.com>

On Tue, Dec 12, 2023 at 11:04?AM John Moon <quic_johmoo at quicinc.com> wrote:
>
> While the kernel community has been good at maintaining backwards
> compatibility with kernel UAPIs, it would be helpful to have a tool
> to check if a commit introduces changes that break backwards
> compatibility.
>
> To that end, introduce check-uapi.sh: a simple shell script that
> checks for changes to UAPI headers using libabigail.
>
> libabigail is "a framework which aims at helping developers and
> software distributors to spot some ABI-related issues like interface
> incompatibility in ELF shared libraries by performing a static
> analysis of the ELF binaries at hand."
>
> The script uses one of libabigail's tools, "abidiff", to compile the
> changed header before and after the commit to detect any changes.
>
> abidiff "compares the ABI of two shared libraries in ELF format. It
> emits a meaningful report describing the differences between the two
> ABIs."
>
> The script also includes the ability to check the compatibility of
> all UAPI headers across commits. This allows developers to inspect
> the stability of the UAPIs over time.
>
> Signed-off-by: John Moon <quic_johmoo at quicinc.com>
> ---
>     - Applied minor code style suggestions from v6 review.




The code looks OK. I think it should work as designed.

Line 197 is inconsistently indented by spaces instead of a space,
but I can fix it up locally.


I just thought requiring target commits as positional parameters
("check-uapi.sh treeA treeB" just like "git diff treeA treeB")
might be intuitive, but I guess everything is specified
by a short option is a design. I can live with that.



I will wait a few days, and if there is nothing more,
I will pick up 1/3 and 2/3.




-- 
Best Regards
Masahiro Yamada


From jernej.skrabec at gmail.com  Fri Dec 22 09:51:30 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Fri, 22 Dec 2023 18:51:30 +0100
Subject: [PATCH RESEND] ARM: dts: sun8i: r40: open the regulator aldo1
In-Reply-To: <ZYKjYypuAx7gNuam@debian.cyg>
References: <ZYKjYypuAx7gNuam@debian.cyg>
Message-ID: <9259140.rMLUfLXkoz@jernej-laptop>

Dne sreda, 20. december 2023 ob 09:18:43 CET je fuyao napisal(a):
> the aldo1 is connect regulator pin which power the TV.
> The USB core use TV ref as reference Voltage.
> 
> Signed-off-by: fuyao <fuyao1697 at cyg.com>

Subject line must have board name in it. Please also update message
as it's unclear.

Best regards,
Jernej

> ---
>  arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> index 9f39b5a2bb35..8906170461df 100644
> --- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> +++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> @@ -42,6 +42,13 @@ &pio {
>  	vcc-pg-supply = <&reg_dldo1>;
>  };
>  
> +&reg_aldo1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-aldo1";
> +};
> +
>  &reg_aldo2 {
>  	regulator-always-on;
>  	regulator-min-microvolt = <1800000>;
> 






From knaerzche at gmail.com  Fri Dec 22 09:51:49 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Fri, 22 Dec 2023 18:51:49 +0100
Subject: [PATCH v2 19/27] drm/rockchip: inno_hdmi: Move tmds rate to
 connector state subclass
In-Reply-To: <cbb7866c-5e72-4656-966e-9c2244afedbd@gmail.com>
References: <20231216162639.125215-1-knaerzche@gmail.com>
 <20231216162639.125215-20-knaerzche@gmail.com>
 <xte5vjc3o77wnlozz6sy5yysiezdxbzvbwdblhbqb5s2nwnnv5@xxknftdeo6uk>
 <cbb7866c-5e72-4656-966e-9c2244afedbd@gmail.com>
Message-ID: <ebe86636-95aa-4766-b8d8-de5d81218537@gmail.com>

Hi Maxime,

Am 18.12.23 um 13:49 schrieb Alex Bee:
>
> Am 18.12.23 um 11:06 schrieb Maxime Ripard:
>> Hi,
>>
>> On Sat, Dec 16, 2023 at 05:26:30PM +0100, Alex Bee wrote:
>>> Similar to the othter members of inno_hdmi_connector_state the 
>>> tmds_rate is
>>> not a property of the device, but of the connector state. Move it to
>>> inno_hdmi_connector_state and make it a long to comply with the clock
>>> framework. To get arround the issue of not having the connector 
>>> state when
>>> inno_hdmi_i2c_init is called in the bind path, getting the tmds rate is
>>> wrapped in function which returns the fallback rate if the connector
>>> doesn't have a state yet.
>>>
>>> Signed-off-by: Alex Bee <knaerzche at gmail.com>
>>> ---
>>> changes in v2:
>>> ? - new patch
>>>
>>> ? drivers/gpu/drm/rockchip/inno_hdmi.c | 36 
>>> +++++++++++++++++++---------
>>> ? 1 file changed, 25 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
>>> b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>> index f9bfae1e97a2..6799d24501b8 100644
>>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>> @@ -47,14 +47,13 @@ struct inno_hdmi {
>>> ? ????? struct inno_hdmi_i2c *i2c;
>>> ????? struct i2c_adapter *ddc;
>>> -
>>> -??? unsigned int tmds_rate;
>>> ? };
>>> ? ? struct inno_hdmi_connector_state {
>>> ????? struct drm_connector_state??? base;
>>> ????? unsigned int??????????? enc_out_format;
>>> ????? unsigned int??????????? colorimetry;
>>> +??? unsigned long??????????? tmds_rate;
>>> ? };
>>> ? ? static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder 
>>> *encoder)
>>> @@ -133,11 +132,33 @@ static inline void hdmi_modb(struct inno_hdmi 
>>> *hdmi, u16 offset,
>>> ????? hdmi_writeb(hdmi, offset, temp);
>>> ? }
>>> ? +static unsigned long inno_hdmi_tmds_rate(struct inno_hdmi *hdmi)
>>> +{
>>> +??? struct drm_connector *connector = &hdmi->connector;
>>> +??? struct drm_connector_state *conn_state = connector->state;
>>> +??? struct inno_hdmi_connector_state *inno_conn_state;
>>> +
>>> +??? if (conn_state) {
>>> +??????? inno_conn_state = to_inno_hdmi_conn_state(conn_state);
>>> +??????? return inno_conn_state->tmds_rate;
>>> +??? }
>>> +
>>> +??? /*
>>> +???? * When IP controller haven't configured to an accurate video
>>> +???? * timing, then the TMDS clock source would be switched to
>>> +???? * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
>>> +???? * and reconfigure the DDC clock.
>>> +???? */
>>> +
>>> +??? return clk_get_rate(hdmi->pclk);
>>> +}
>>> +
>>> ? static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
>>> ? {
>>> ????? int ddc_bus_freq;
>>> +??? unsigned long tmds_rate = inno_hdmi_tmds_rate(hdmi);
>>> ? -??? ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE;
>>> +??? ddc_bus_freq = (tmds_rate >> 2) / HDMI_SCL_RATE;
>>> ? ????? hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
>>> ????? hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
>>> @@ -431,7 +452,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>> ?????? * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
>>> ?????? * clock rate, and reconfigure the DDC clock.
>>> ?????? */
>>> -??? hdmi->tmds_rate = mode->clock * 1000;
>>> +??? inno_conn_state->tmds_rate = mode->clock * 1000;
>>> ????? inno_hdmi_i2c_init(hdmi);
>>> ? ????? /* Unmute video and audio output */
>>> @@ -823,13 +844,6 @@ static int inno_hdmi_bind(struct device *dev, 
>>> struct device *master,
>>> ????????? goto err_disable_clk;
>>> ????? }
>>> ? -??? /*
>>> -???? * When IP controller haven't configured to an accurate video
>>> -???? * timing, then the TMDS clock source would be switched to
>>> -???? * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
>>> -???? * and reconfigure the DDC clock.
>>> -???? */
>>> -??? hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
>>> ????? inno_hdmi_i2c_init(hdmi);
>> I still think my patch is better there.
>>
I found a way now and added your patch which removes the tmds_rate: I
noticed powering up the phy initially isn't necessary at all (and makes no
sense). I refactored?inno_hdmi_set_pwr_mode in two functions (in a similar
way you did for the infoframe), so that the tmds rate (pixelclock) is only
needed as parameter when a mode is set.

Alex

>> There's two places that use the inno_hdmi.tmds_rate field: the two
>> callers of inno_hdmi_i2c_init(). One is at bind time and needs to
>> initialise it with a sane default since we don't have a mode set yet,
>> the other is to update the internal clock rate while we have a mode set.
> That?s, unfortunately, not fully true: inno_hdmi_set_pwr_mode not only
> called at mode_set-time, but also in inno_hdmi_reset which is called 
> in the
> bind path (where we do not have a mode). That?s the point why I thought
> extracting this in function makes sense. Otherwise I would have to 
> pass the
> tmds_rate to inno_hdmi_set_pwr_mode (also for the LOWER_PWR-case where I
> don't need it) or do that whole fallback-if-no-mode thing in
> inno_hdmi_set_pwr_mode directly. Neither would make the code easier to
> follow. Being able to use it in inno_hdmi_i2c_init also is a nice 
> gimmick.
> I agree, having it in the custom connector state is not strictly 
> required,
> but I'd really like to keep the wrapping function.
>
> Alex
>
>> Since there's a single "modeset" user, there's no need to store it in
>> the state structure at all: it can be a local variable.
>>
>> And in the bind function, you're not going to use the state structure
>> either since there's no state, and it's just a default that has no
>> relation to the modeset code at all.
>>
>> Your function on the other end tries to reconcile and handle the two.
>> But there's no reason to, it just makes the code harder to follow. Just
>> pass the parent rate you want to init with as an argument and it's easy
>> to read and maintain.
>>
>> Maxime


From linus.walleij at linaro.org  Fri Dec 22 09:52:41 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 22 Dec 2023 18:52:41 +0100
Subject: [PATCH v2 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-sleep property
In-Reply-To: <20231222095258.33369-2-eichest@gmail.com>
References: <20231222095258.33369-1-eichest@gmail.com> <20231222095258.33369-2-eichest@gmail.com>
Message-ID: <CACRpkdbPjA+atjWt101f_o8hFkeUsUXL_raGdd802g_+n4FYOw@mail.gmail.com>

On Fri, Dec 22, 2023 at 10:53?AM Stefan Eichenberger <eichest at gmail.com> wrote:

> From: Stefan Eichenberger <stefan.eichenberger at toradex.com>
>
> Add a new property to indicate that the device should power off rather
> than use deep sleep. Deep sleep is a feature of the controller that
> expects the controller to remain powered in suspend. However, if a
> display shares its regulator with the touch controller, we may want to
> do a power off so that the display and touch controller do not use any
> power.
>
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger at toradex.com>

This LGTM:
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From jernej.skrabec at gmail.com  Fri Dec 22 09:54:53 2023
From: jernej.skrabec at gmail.com (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Fri, 22 Dec 2023 18:54:53 +0100
Subject: [PATCH RESEND] iio: adc: sun4i-gpadc-iio: adaptation interrupt number
In-Reply-To: <20231221152553.GM10102@google.com>
References: <YxmR5SPPY18O7LaG@google.com>
 <20231220115412.65bbc8c7@donnerap.manchester.arm.com>
 <20231221152553.GM10102@google.com>
Message-ID: <4953611.0VBMTVartN@jernej-laptop>

Dne ?etrtek, 21. december 2023 ob 16:25:53 CET je Lee Jones napisal(a):
> On Wed, 20 Dec 2023, Andre Przywara wrote:
> 
> > On Wed, 20 Dec 2023 15:23:17 +0800
> > fuyao <fuyao1697 at cyg.com> wrote:
> > 
> > Hi,
> > 
> > > __platform_get_irq_byname determinies whether the interrupt
> > > number is 0 and returns EINVAL.
> > 
> > can you please say what this fixes, exactly? Is something not working at
> > the moment? Can you please provide parts of the error message?
> > 
> > And maybe expand the explanation a bit more? For instance mention that the
> > identifiers are used as IRQ resource numbers, where 0 is treated specially.
> > 
> > Cheers,
> > Andre
> > 
> > > 
> > > Signed-off-by: fuyao <fuyao1697 at cyg.com>
> 
> You have to use your full real name as well.

Isn't that enough after
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330 ?

Best regards,
Jernej

> 
> > > Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
> > > ---
> > >  include/linux/mfd/sun4i-gpadc.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> > > index ea0ccf33a459..021f820f9d52 100644
> > > --- a/include/linux/mfd/sun4i-gpadc.h
> > > +++ b/include/linux/mfd/sun4i-gpadc.h
> > > @@ -81,8 +81,8 @@
> > >  #define SUN4I_GPADC_TEMP_DATA				0x20
> > >  #define SUN4I_GPADC_DATA				0x24
> > >  
> > > -#define SUN4I_GPADC_IRQ_FIFO_DATA			0
> > > -#define SUN4I_GPADC_IRQ_TEMP_DATA			1
> > > +#define SUN4I_GPADC_IRQ_FIFO_DATA			1
> > > +#define SUN4I_GPADC_IRQ_TEMP_DATA			2
> > >  
> > >  /* 10s delay before suspending the IP */
> > >  #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
> > 
> 
> 






From peter.griffin at linaro.org  Fri Dec 22 09:56:26 2023
From: peter.griffin at linaro.org (Peter Griffin)
Date: Fri, 22 Dec 2023 17:56:26 +0000
Subject: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0
 clock management unit
In-Reply-To: <173b06ab-2518-49ee-a67f-85256bc5b6a7@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-3-tudor.ambarus@linaro.org> <20231220150726.GA223267-robh@kernel.org>
 <173b06ab-2518-49ee-a67f-85256bc5b6a7@linaro.org>
Message-ID: <CADrjBPpGWxidBYvEcQjv1k6QRcoJSdnJ7SK1koJpeb60V3FhKA@mail.gmail.com>

Hi Tudor,

On Thu, 21 Dec 2023 at 07:20, Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
>
>
>
> On 12/20/23 15:07, Rob Herring wrote:
> > On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
> >> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
> >> clock management unit.
> >>
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
> >> ---
> >>  .../bindings/clock/google,gs101-clock.yaml    | 25 +++++-
> >>  include/dt-bindings/clock/google,gs101.h      | 86 +++++++++++++++++++
> >>  2 files changed, 109 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >> index 3eebc03a309b..ba54c13c55bc 100644
> >> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >> @@ -30,14 +30,15 @@ properties:
> >>        - google,gs101-cmu-top
> >>        - google,gs101-cmu-apm
> >>        - google,gs101-cmu-misc
> >> +      - google,gs101-cmu-peric0
> >>
> >>    clocks:
> >>      minItems: 1
> >> -    maxItems: 2
> >> +    maxItems: 3
> >>
> >>    clock-names:
> >>      minItems: 1
> >> -    maxItems: 2
> >> +    maxItems: 3
> >>
> >>    "#clock-cells":
> >>      const: 1
> >> @@ -88,6 +89,26 @@ allOf:
> >>              - const: dout_cmu_misc_bus
> >>              - const: dout_cmu_misc_sss
> >>
> >> +  - if:
> >> +      properties:
> >> +        compatible:
> >> +          contains:
> >> +            const: google,gs101-cmu-peric0
> >> +
> >> +    then:
> >> +      properties:
> >> +        clocks:
> >> +          items:
> >> +            - description: External reference clock (24.576 MHz)
> >> +            - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
> >> +            - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
> >> +
> >> +        clock-names:
> >> +          items:
> >> +            - const: oscclk
> >> +            - const: dout_cmu_peric0_bus
> >> +            - const: dout_cmu_peric0_ip
> >
> > 'bus' and 'ip' are sufficient because naming is local to the module. The
> > same is true on 'dout_cmu_misc_bus'. As that has not made a release,
> > please fix all of them.
> >
>
> Ok, will fix them shortly. Thanks, Rob!

With Robs review comments addressed feel free to add my:

Reviewed-by: Peter Griffin <peter.griffin at linaro.org>


From masahiroy at kernel.org  Fri Dec 22 09:57:00 2023
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Sat, 23 Dec 2023 02:57:00 +0900
Subject: [PATCH v7 3/3] check-module-params: Introduce check-module-params.sh
In-Reply-To: <93ee22bc-b357-4291-b3d9-07ff2cd6c87b@quicinc.com>
References: <20231212020259.2451253-1-quic_johmoo@quicinc.com>
 <20231212020259.2451253-4-quic_johmoo@quicinc.com> <ZXgOpRzNYGtiE35T@infradead.org>
 <93ee22bc-b357-4291-b3d9-07ff2cd6c87b@quicinc.com>
Message-ID: <CAK7LNAQfzxiMoiLXvksUWtPiRhXQ7zypUzQpYER_7B=00XBr=A@mail.gmail.com>

On Wed, Dec 13, 2023 at 1:58?AM John Moon <quic_johmoo at quicinc.com> wrote:
>
> On 12/11/2023 11:41 PM, Christoph Hellwig wrote:
> > On Mon, Dec 11, 2023 at 06:02:59PM -0800, John Moon wrote:
> >> One part of maintaining backwards compatibility with older
> >> userspace programs is avoiding changes to module parameters.
> >
> > Really?  I don't think module parameters are a UAPI in the traditional
> > sense.
>
> Agreed, they're not UAPI in the traditional sense. But, we're trying to
> establish tooling to help the community stabilize all interfaces that
> cross the kernel <-> userspace boundary and module params do fall into
> that bucket.
>
> > Now if you break a heavily used one you got to fix it, but
> > applying strict stability guarantees on module options which are not
> > availble to normal users or even normal programs doesn't make a whole
> > lot of sense.
> >
>
> True, but unfortunately we don't have any heuristic to determine if a
> param is "heavily used". However, in this rev, we added the ability to
> parse the permissions of a module param, so we could add a filter which
> does not flag change/removal of params with 0{0,4,6}000 permissions.
>
> It's also obviously fine if the community has no interest in the script.
> We just wanted to share it as we find it to be a useful supplement to
> our code reviews and thought maintainers may find it useful as well.
>
> Cheers,
> John


I am with Christoph.

This tool detects some changes and removals, but I think
the community intentionally changed them.

To merge this tool in the mainline,
I need more people who are interested in this.




-- 
Best Regards
Masahiro Yamada


From nathan at kernel.org  Fri Dec 22 10:06:45 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Fri, 22 Dec 2023 11:06:45 -0700
Subject: [PATCH 2/2] dmaengine: xilinx: xdma: Fix initialization location
 of desc in xdma_channel_isr()
In-Reply-To: <20231222-dma-xilinx-xdma-clang-fixes-v1-0-84a18ff184d2@kernel.org>
References: <20231222-dma-xilinx-xdma-clang-fixes-v1-0-84a18ff184d2@kernel.org>
Message-ID: <20231222-dma-xilinx-xdma-clang-fixes-v1-2-84a18ff184d2@kernel.org>

Clang warns (or errors with CONFIG_WERROR=y):

  drivers/dma/xilinx/xdma.c:894:3: error: variable 'desc' is uninitialized when used here [-Werror,-Wuninitialized]
    894 |                 desc->error = true;
        |                 ^~~~

The initialization of desc was moved too far forward, move it back so
that this assignment does not result in a potential crash at runtime
while clearing up the warning.

Closes: https://github.com/ClangBuiltLinux/linux/issues/1972
Fixes: 2f8f90cd2f8d ("dmaengine: xilinx: xdma: Implement interleaved DMA transfers")
Signed-off-by: Nathan Chancellor <nathan at kernel.org>
---
 drivers/dma/xilinx/xdma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/xdma.c b/drivers/dma/xilinx/xdma.c
index d5b9fc3fd955..ee595d1ebc63 100644
--- a/drivers/dma/xilinx/xdma.c
+++ b/drivers/dma/xilinx/xdma.c
@@ -888,6 +888,8 @@ static irqreturn_t xdma_channel_isr(int irq, void *dev_id)
 	if (ret)
 		goto out;
 
+	desc = to_xdma_desc(vd);
+
 	st &= XDMA_CHAN_STATUS_MASK;
 	if ((st & XDMA_CHAN_ERROR_MASK) ||
 	    !(st & (CHAN_CTRL_IE_DESC_COMPLETED | CHAN_CTRL_IE_DESC_STOPPED))) {
@@ -901,7 +903,6 @@ static irqreturn_t xdma_channel_isr(int irq, void *dev_id)
 	if (ret)
 		goto out;
 
-	desc = to_xdma_desc(vd);
 	if (desc->interleaved_dma) {
 		xchan->busy = false;
 		desc->completed_desc_num += complete_desc_num;

-- 
2.43.0



From nathan at kernel.org  Fri Dec 22 10:06:44 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Fri, 22 Dec 2023 11:06:44 -0700
Subject: [PATCH 1/2] dmaengine: xilinx: xdma: Fix operator precedence in
 xdma_prep_interleaved_dma()
In-Reply-To: <20231222-dma-xilinx-xdma-clang-fixes-v1-0-84a18ff184d2@kernel.org>
References: <20231222-dma-xilinx-xdma-clang-fixes-v1-0-84a18ff184d2@kernel.org>
Message-ID: <20231222-dma-xilinx-xdma-clang-fixes-v1-1-84a18ff184d2@kernel.org>

Clang warns (or errors with CONFIG_WERROR=y):

  drivers/dma/xilinx/xdma.c:757:68: error: operator '?:' has lower precedence than '+'; '+' will be evaluated first [-Werror,-Wparentheses]
    757 |                 src_addr += dmaengine_get_src_icg(xt, &xt->sgl[i]) + xt->src_inc ?
        |                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
  drivers/dma/xilinx/xdma.c:757:68: note: place parentheses around the '+' expression to silence this warning
    757 |                 src_addr += dmaengine_get_src_icg(xt, &xt->sgl[i]) + xt->src_inc ?
        |                                                                                  ^
        |                             (                                                   )
  drivers/dma/xilinx/xdma.c:757:68: note: place parentheses around the '?:' expression to evaluate it first
    757 |                 src_addr += dmaengine_get_src_icg(xt, &xt->sgl[i]) + xt->src_inc ?
        |                                                                                  ^
        |                                                                      (
    758 |                                                               xt->sgl[i].size : 0;
        |
        |                                                                                  )
  drivers/dma/xilinx/xdma.c:759:68: error: operator '?:' has lower precedence than '+'; '+' will be evaluated first [-Werror,-Wparentheses]
    759 |                 dst_addr += dmaengine_get_dst_icg(xt, &xt->sgl[i]) + xt->dst_inc ?
        |                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
  drivers/dma/xilinx/xdma.c:759:68: note: place parentheses around the '+' expression to silence this warning
    759 |                 dst_addr += dmaengine_get_dst_icg(xt, &xt->sgl[i]) + xt->dst_inc ?
        |                                                                                  ^
        |                             (                                                   )
  drivers/dma/xilinx/xdma.c:759:68: note: place parentheses around the '?:' expression to evaluate it first
    759 |                 dst_addr += dmaengine_get_dst_icg(xt, &xt->sgl[i]) + xt->dst_inc ?
        |                                                                                  ^
        |                                                                      (
    760 |                                                               xt->sgl[i].size : 0;
        |
        |                                                                                  )

The src_inc and dst_inc members of 'struct dma_interleaved_template' are
booleans, so it does not make sense for the addition to happen first.
Wrap the conditional operator in parantheses so it is evaluated first.

Closes: https://github.com/ClangBuiltLinux/linux/issues/1971
Fixes: 2f8f90cd2f8d ("dmaengine: xilinx: xdma: Implement interleaved DMA transfers")
Signed-off-by: Nathan Chancellor <nathan at kernel.org>
---
 drivers/dma/xilinx/xdma.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/xilinx/xdma.c b/drivers/dma/xilinx/xdma.c
index 4ebc90b41bdb..d5b9fc3fd955 100644
--- a/drivers/dma/xilinx/xdma.c
+++ b/drivers/dma/xilinx/xdma.c
@@ -754,10 +754,10 @@ xdma_prep_interleaved_dma(struct dma_chan *chan,
 	dst_addr = xt->dst_start;
 	for (i = 0; i < xt->frame_size; ++i) {
 		desc_num += xdma_fill_descs(sw_desc, src_addr, dst_addr, xt->sgl[i].size, desc_num);
-		src_addr += dmaengine_get_src_icg(xt, &xt->sgl[i]) + xt->src_inc ?
-							      xt->sgl[i].size : 0;
-		dst_addr += dmaengine_get_dst_icg(xt, &xt->sgl[i]) + xt->dst_inc ?
-							      xt->sgl[i].size : 0;
+		src_addr += dmaengine_get_src_icg(xt, &xt->sgl[i]) + (xt->src_inc ?
+							      xt->sgl[i].size : 0);
+		dst_addr += dmaengine_get_dst_icg(xt, &xt->sgl[i]) + (xt->dst_inc ?
+							      xt->sgl[i].size : 0);
 		period_size += xt->sgl[i].size;
 	}
 	sw_desc->period_size = period_size;

-- 
2.43.0



From nathan at kernel.org  Fri Dec 22 10:06:43 2023
From: nathan at kernel.org (Nathan Chancellor)
Date: Fri, 22 Dec 2023 11:06:43 -0700
Subject: [PATCH 0/2] dmaengine: xilinx: xdma: Fix two clang warnings
Message-ID: <20231222-dma-xilinx-xdma-clang-fixes-v1-0-84a18ff184d2@kernel.org>

Hi all,

This series fixes two clang warnings that I see after
commit 2f8f90cd2f8d ("dmaengine: xilinx: xdma: Implement interleaved DMA
transfers"). They have just been build tested but I think the logic is
sound, please double check though.

---
Nathan Chancellor (2):
      dmaengine: xilinx: xdma: Fix operator precedence in xdma_prep_interleaved_dma()
      dmaengine: xilinx: xdma: Fix initialization location of desc in xdma_channel_isr()

 drivers/dma/xilinx/xdma.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
---
base-commit: 3d0b2176e04261ab4ac095ff2a17db077fc1e46d
change-id: 20231222-dma-xilinx-xdma-clang-fixes-b9c2c3f5d0f3

Best regards,
-- 
Nathan Chancellor <nathan at kernel.org>



From lkp at intel.com  Fri Dec 22 10:07:49 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 02:07:49 +0800
Subject: [soc:qcom/dt32] BUILD SUCCESS
 648002a27c6b3ae293cc415e1fbf20aaa6af8bd3
Message-ID: <202312230246.AFE1we9U-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/dt32
branch HEAD: 648002a27c6b3ae293cc415e1fbf20aaa6af8bd3  ARM: dts: qcom: msm8974*: Re-enable remoteprocs on various boards

elapsed time: 7018m

configs tested: 174
configs skipped: 135

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                        nsim_700_defconfig   gcc  
arc                   randconfig-001-20231222   gcc  
arc                   randconfig-002-20231222   gcc  
arc                           tb10x_defconfig   gcc  
arm                               allnoconfig   gcc  
arm                           h3600_defconfig   gcc  
arm                            mps2_defconfig   gcc  
arm                       omap2plus_defconfig   gcc  
arm                         orion5x_defconfig   clang
arm                          pxa910_defconfig   gcc  
arm                            qcom_defconfig   gcc  
arm                   randconfig-001-20231222   gcc  
arm                   randconfig-002-20231222   gcc  
arm                   randconfig-003-20231222   gcc  
arm                   randconfig-004-20231222   gcc  
arm                           sama5_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231222   gcc  
arm64                 randconfig-002-20231222   gcc  
arm64                 randconfig-003-20231222   gcc  
arm64                 randconfig-004-20231222   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231222   gcc  
csky                  randconfig-002-20231222   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231222   clang
i386                  randconfig-012-20231222   clang
i386                  randconfig-013-20231222   clang
i386                  randconfig-014-20231222   clang
i386                  randconfig-015-20231222   clang
i386                  randconfig-016-20231222   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231222   gcc  
loongarch             randconfig-002-20231222   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                       m5208evb_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                      maltasmvp_defconfig   gcc  
mips                        maltaup_defconfig   clang
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231222   gcc  
nios2                 randconfig-002-20231222   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231222   gcc  
parisc                randconfig-002-20231222   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                      arches_defconfig   gcc  
powerpc                      bamboo_defconfig   gcc  
powerpc                   currituck_defconfig   gcc  
powerpc                      ep88xc_defconfig   gcc  
powerpc                      makalu_defconfig   gcc  
powerpc                       maple_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                 mpc832x_rdb_defconfig   clang
powerpc                      pcm030_defconfig   gcc  
powerpc               randconfig-001-20231222   gcc  
powerpc               randconfig-002-20231222   gcc  
powerpc               randconfig-003-20231222   gcc  
powerpc                     redwood_defconfig   gcc  
powerpc                    sam440ep_defconfig   gcc  
powerpc                     tqm8560_defconfig   gcc  
powerpc                        warp_defconfig   gcc  
powerpc64             randconfig-001-20231222   gcc  
powerpc64             randconfig-002-20231222   gcc  
powerpc64             randconfig-003-20231222   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                    nommu_k210_defconfig   gcc  
riscv                    nommu_virt_defconfig   clang
riscv                 randconfig-001-20231222   gcc  
riscv                 randconfig-002-20231222   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                        apsh4ad0a_defconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                             espt_defconfig   gcc  
sh                          polaris_defconfig   gcc  
sh                    randconfig-001-20231222   gcc  
sh                    randconfig-002-20231222   gcc  
sh                          rsk7264_defconfig   gcc  
sh                           se7619_defconfig   gcc  
sh                   secureedge5410_defconfig   gcc  
sh                     sh7710voipgw_defconfig   gcc  
sh                            titan_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc                       sparc32_defconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231222   gcc  
sparc64               randconfig-002-20231222   gcc  
um                               alldefconfig   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231222   gcc  
um                    randconfig-002-20231222   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           alldefconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231222   gcc  
x86_64       buildonly-randconfig-002-20231222   gcc  
x86_64       buildonly-randconfig-003-20231222   gcc  
x86_64       buildonly-randconfig-004-20231222   gcc  
x86_64       buildonly-randconfig-005-20231222   gcc  
x86_64       buildonly-randconfig-006-20231222   gcc  
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231222   gcc  
x86_64                randconfig-012-20231222   gcc  
x86_64                randconfig-013-20231222   gcc  
x86_64                randconfig-014-20231222   gcc  
x86_64                randconfig-015-20231222   gcc  
x86_64                randconfig-016-20231222   gcc  
x86_64                randconfig-071-20231222   gcc  
x86_64                randconfig-072-20231222   gcc  
x86_64                randconfig-073-20231222   gcc  
x86_64                randconfig-074-20231222   gcc  
x86_64                randconfig-075-20231222   gcc  
x86_64                randconfig-076-20231222   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                  cadence_csp_defconfig   gcc  
xtensa                randconfig-001-20231222   gcc  
xtensa                randconfig-002-20231222   gcc  
xtensa                    smp_lx200_defconfig   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Fri Dec 22 10:08:08 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 02:08:08 +0800
Subject: [soc:k3/dt] BUILD SUCCESS
 8bbe8a7dbaabb84d93321f116966af73ba6a7233
Message-ID: <202312230204.p0O8ZnRo-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git k3/dt
branch HEAD: 8bbe8a7dbaabb84d93321f116966af73ba6a7233  arm64: dts: ti: k3-j784s4-main: Add Itap Delay Value For DDR50 speed mode

elapsed time: 1462m

configs tested: 177
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                        nsim_700_defconfig   gcc  
arc                   randconfig-001-20231222   gcc  
arc                   randconfig-002-20231222   gcc  
arc                           tb10x_defconfig   gcc  
arm                               allnoconfig   gcc  
arm                           h3600_defconfig   gcc  
arm                            mps2_defconfig   gcc  
arm                       omap2plus_defconfig   gcc  
arm                         orion5x_defconfig   clang
arm                          pxa910_defconfig   gcc  
arm                            qcom_defconfig   gcc  
arm                   randconfig-001-20231222   gcc  
arm                   randconfig-002-20231222   gcc  
arm                   randconfig-003-20231222   gcc  
arm                   randconfig-004-20231222   gcc  
arm                           sama5_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231222   gcc  
arm64                 randconfig-002-20231222   gcc  
arm64                 randconfig-003-20231222   gcc  
arm64                 randconfig-004-20231222   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231222   gcc  
csky                  randconfig-002-20231222   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                                defconfig   gcc  
i386                  randconfig-011-20231222   clang
i386                  randconfig-012-20231222   clang
i386                  randconfig-013-20231222   clang
i386                  randconfig-014-20231222   clang
i386                  randconfig-015-20231222   clang
i386                  randconfig-016-20231222   clang
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231222   gcc  
loongarch             randconfig-002-20231222   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                       m5208evb_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                      maltasmvp_defconfig   gcc  
mips                        maltaup_defconfig   clang
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231222   gcc  
nios2                 randconfig-002-20231222   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231222   gcc  
parisc                randconfig-002-20231222   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                      arches_defconfig   gcc  
powerpc                      bamboo_defconfig   gcc  
powerpc                   currituck_defconfig   gcc  
powerpc                      ep88xc_defconfig   gcc  
powerpc                      makalu_defconfig   gcc  
powerpc                       maple_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                 mpc832x_rdb_defconfig   clang
powerpc                      pcm030_defconfig   gcc  
powerpc               randconfig-001-20231222   gcc  
powerpc               randconfig-002-20231222   gcc  
powerpc               randconfig-003-20231222   gcc  
powerpc                     redwood_defconfig   gcc  
powerpc                    sam440ep_defconfig   gcc  
powerpc                     tqm8560_defconfig   gcc  
powerpc                        warp_defconfig   gcc  
powerpc64             randconfig-001-20231222   gcc  
powerpc64             randconfig-002-20231222   gcc  
powerpc64             randconfig-003-20231222   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                    nommu_k210_defconfig   gcc  
riscv                    nommu_virt_defconfig   clang
riscv                 randconfig-001-20231222   gcc  
riscv                 randconfig-002-20231222   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                        apsh4ad0a_defconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                             espt_defconfig   gcc  
sh                          polaris_defconfig   gcc  
sh                    randconfig-001-20231222   gcc  
sh                    randconfig-002-20231222   gcc  
sh                          rsk7264_defconfig   gcc  
sh                           se7619_defconfig   gcc  
sh                   secureedge5410_defconfig   gcc  
sh                     sh7710voipgw_defconfig   gcc  
sh                            titan_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc                       sparc32_defconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231222   gcc  
sparc64               randconfig-002-20231222   gcc  
um                               alldefconfig   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231222   gcc  
um                    randconfig-002-20231222   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           alldefconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231222   gcc  
x86_64       buildonly-randconfig-002-20231222   gcc  
x86_64       buildonly-randconfig-003-20231222   gcc  
x86_64       buildonly-randconfig-004-20231222   gcc  
x86_64       buildonly-randconfig-005-20231222   gcc  
x86_64       buildonly-randconfig-006-20231222   gcc  
x86_64                              defconfig   gcc  
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231222   gcc  
x86_64                randconfig-012-20231222   gcc  
x86_64                randconfig-013-20231222   gcc  
x86_64                randconfig-014-20231222   gcc  
x86_64                randconfig-015-20231222   gcc  
x86_64                randconfig-016-20231222   gcc  
x86_64                randconfig-071-20231222   gcc  
x86_64                randconfig-072-20231222   gcc  
x86_64                randconfig-073-20231222   gcc  
x86_64                randconfig-074-20231222   gcc  
x86_64                randconfig-075-20231222   gcc  
x86_64                randconfig-076-20231222   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                  cadence_csp_defconfig   gcc  
xtensa                randconfig-001-20231222   gcc  
xtensa                randconfig-002-20231222   gcc  
xtensa                    smp_lx200_defconfig   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From festevam at gmail.com  Fri Dec 22 10:25:53 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 22 Dec 2023 15:25:53 -0300
Subject: [PATCH 2/6] drm/panel: Add driver for BOE TH101MB31IG002-28A panel
In-Reply-To: <20231222-pinetab2-v1-2-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net> <20231222-pinetab2-v1-2-e148a7f61bd1@mecka.net>
Message-ID: <CAOMZO5DV9Kev8njR5ORhUM+mxSa9WxewB3xNKjEWP4zcuTZtiQ@mail.gmail.com>

On Fri, Dec 22, 2023 at 2:32?PM Manuel Traut <manut at mecka.net> wrote:
>
> From: Segfault <awarnecke002 at hotmail.com>
>
> The BOE TH101MB31IG002-28A panel is a WXGA panel.
> It is used in Pine64 Pinetab2 and PinetabV.
>
> Signed-off-by: Segfault <awarnecke002 at hotmail.com>

Please use a real name instead...

> +MODULE_AUTHOR("Alexander Warnecke <awarnecke002 at hotmail.com>");

like here.


From fancer.lancer at gmail.com  Fri Dec 22 11:02:47 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Fri, 22 Dec 2023 22:02:47 +0300
Subject: [PATCH net-next v1 2/4] net: stmmac: Make MSI interrupt routine
 generic
In-Reply-To: <20231222054451.2683242-3-leong.ching.swee@intel.com>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
 <20231222054451.2683242-3-leong.ching.swee@intel.com>
Message-ID: <zwlnzllanmd6wtmn6ts7pd6y2sxgbauy4ffgqlf3yaq4uo65tw@ybigwcjpk7uf>

On Fri, Dec 22, 2023 at 01:44:49PM +0800, Leong Ching Swee wrote:
> From: Swee Leong Ching <leong.ching.swee at intel.com>
> 
> There is no support for per DMA channel interrupt for non-MSI platform,
> where the MAC's per channel interrupt hooks up to interrupt controller(GIC)
> through shared peripheral interrupt(SPI) to handle interrupt from TX/RX
> transmit channel.
> 
> This patch generalize the existing MSI ISR to also support non-MSI
> platform.
> 
> Signed-off-by: Teoh Ji Sheng <ji.sheng.teoh at intel.com>
> Signed-off-by: Swee Leong Ching <leong.ching.swee at intel.com>
> ---
>  .../net/ethernet/stmicro/stmmac/dwmac-intel.c |  4 +--
>  .../net/ethernet/stmicro/stmmac/dwmac4_dma.c  |  2 +-
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c | 29 ++++++++++---------
>  include/linux/stmmac.h                        |  4 +--
>  4 files changed, 21 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> index 60283543ffc8..f0ec69af96c9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> @@ -952,7 +952,7 @@ static int stmmac_config_single_msi(struct pci_dev *pdev,
>  
>  	res->irq = pci_irq_vector(pdev, 0);
>  	res->wol_irq = res->irq;
> -	plat->flags &= ~STMMAC_FLAG_MULTI_MSI_EN;
> +	plat->flags &= ~STMMAC_FLAG_MULTI_IRQ_EN;
>  	dev_info(&pdev->dev, "%s: Single IRQ enablement successful\n",
>  		 __func__);
>  
> @@ -1004,7 +1004,7 @@ static int stmmac_config_multi_msi(struct pci_dev *pdev,
>  	if (plat->msi_sfty_ue_vec < STMMAC_MSI_VEC_MAX)
>  		res->sfty_ue_irq = pci_irq_vector(pdev, plat->msi_sfty_ue_vec);
>  
> -	plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> +	plat->flags |= STMMAC_FLAG_MULTI_IRQ_EN;
>  	dev_info(&pdev->dev, "%s: multi MSI enablement successful\n", __func__);
>  
>  	return 0;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> index 84d3a8551b03..5f649106ffcd 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> @@ -175,7 +175,7 @@ static void dwmac4_dma_init(void __iomem *ioaddr,
>  
>  	value = readl(ioaddr + DMA_BUS_MODE);
>  
> -	if (dma_cfg->multi_msi_en) {
> +	if (dma_cfg->multi_irq_en) {
>  		value &= ~DMA_BUS_MODE_INTM_MASK;
>  		value |= (DMA_BUS_MODE_INTM_MODE1 << DMA_BUS_MODE_INTM_SHIFT);
>  	}
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 47de466e432c..30cc9edb4198 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -129,8 +129,8 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id);
>  /* For MSI interrupts handling */
>  static irqreturn_t stmmac_mac_interrupt(int irq, void *dev_id);
>  static irqreturn_t stmmac_safety_interrupt(int irq, void *dev_id);

> -static irqreturn_t stmmac_msi_intr_tx(int irq, void *data);
> -static irqreturn_t stmmac_msi_intr_rx(int irq, void *data);
> +static irqreturn_t stmmac_tx_queue_interrupt(int irq, void *data);
> +static irqreturn_t stmmac_rx_queue_interrupt(int irq, void *data);

Let's use the next names instead:

+static irqreturn_t stmmac_dma_tx_interrupt(int irq, void *data);
+static irqreturn_t stmmac_dma_rx_interrupt(int irq, void *data);

It would be semantically more correct and would refer to the
stmmac_dma_interrupt() handler.

>  static void stmmac_reset_rx_queue(struct stmmac_priv *priv, u32 queue);
>  static void stmmac_reset_tx_queue(struct stmmac_priv *priv, u32 queue);
>  static void stmmac_reset_queues_param(struct stmmac_priv *priv);
> @@ -3602,7 +3602,7 @@ static void stmmac_free_irq(struct net_device *dev,
>  	}
>  }
>  
> -static int stmmac_request_irq_multi_msi(struct net_device *dev)
> +static int stmmac_request_irq_multi(struct net_device *dev)
>  {
>  	struct stmmac_priv *priv = netdev_priv(dev);
>  	enum request_irq_err irq_err;
> @@ -3701,13 +3701,13 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
>  	for (i = 0; i < priv->plat->rx_queues_to_use; i++) {
>  		if (i >= MTL_MAX_RX_QUEUES)
>  			break;

> -		if (priv->rx_irq[i] == 0)
> +		if (priv->rx_irq[i] <= 0)

Why? What about just using a temporary variable in
stmmac_get_platform_resources() to get the Per-channel DMA IRQs and
not saving error number in priv->rx_irq[]?

>  			continue;
>  
>  		int_name = priv->int_name_rx_irq[i];
>  		sprintf(int_name, "%s:%s-%d", dev->name, "rx", i);
>  		ret = request_irq(priv->rx_irq[i],
> -				  stmmac_msi_intr_rx,
> +				  stmmac_rx_queue_interrupt,
>  				  0, int_name, &priv->dma_conf.rx_queue[i]);
>  		if (unlikely(ret < 0)) {
>  			netdev_err(priv->dev,
> @@ -3726,13 +3726,13 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
>  	for (i = 0; i < priv->plat->tx_queues_to_use; i++) {
>  		if (i >= MTL_MAX_TX_QUEUES)
>  			break;

> -		if (priv->tx_irq[i] == 0)
> +		if (priv->tx_irq[i] <= 0)

ditto.

>  			continue;
>  
>  		int_name = priv->int_name_tx_irq[i];
>  		sprintf(int_name, "%s:%s-%d", dev->name, "tx", i);
>  		ret = request_irq(priv->tx_irq[i],
> -				  stmmac_msi_intr_tx,
> +				  stmmac_tx_queue_interrupt,
>  				  0, int_name, &priv->dma_conf.tx_queue[i]);
>  		if (unlikely(ret < 0)) {
>  			netdev_err(priv->dev,

Please fix the error message strings in stmmac_request_irq_multi_msi()
too.

> @@ -3811,8 +3811,8 @@ static int stmmac_request_irq(struct net_device *dev)
>  	int ret;
>  
>  	/* Request the IRQ lines */
> -	if (priv->plat->flags & STMMAC_FLAG_MULTI_MSI_EN)
> -		ret = stmmac_request_irq_multi_msi(dev);
> +	if (priv->plat->flags & STMMAC_FLAG_MULTI_IRQ_EN)
> +		ret = stmmac_request_irq_multi(dev);
>  	else
>  		ret = stmmac_request_irq_single(dev);
>  
> @@ -6075,7 +6075,7 @@ static irqreturn_t stmmac_safety_interrupt(int irq, void *dev_id)
>  	return IRQ_HANDLED;
>  }
>  
> -static irqreturn_t stmmac_msi_intr_tx(int irq, void *data)
> +static irqreturn_t stmmac_tx_queue_interrupt(int irq, void *data)
>  {
>  	struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)data;
>  	struct stmmac_dma_conf *dma_conf;
> @@ -6107,7 +6107,7 @@ static irqreturn_t stmmac_msi_intr_tx(int irq, void *data)
>  	return IRQ_HANDLED;
>  }
>  
> -static irqreturn_t stmmac_msi_intr_rx(int irq, void *data)
> +static irqreturn_t stmmac_rx_queue_interrupt(int irq, void *data)
>  {
>  	struct stmmac_rx_queue *rx_q = (struct stmmac_rx_queue *)data;
>  	struct stmmac_dma_conf *dma_conf;
> @@ -7456,8 +7456,11 @@ int stmmac_dvr_probe(struct device *device,
>  	priv->plat = plat_dat;
>  	priv->ioaddr = res->addr;
>  	priv->dev->base_addr = (unsigned long)res->addr;
> -	priv->plat->dma_cfg->multi_msi_en =
> -		(priv->plat->flags & STMMAC_FLAG_MULTI_MSI_EN);
> +

> +	if (res->rx_irq[0] > 0 && res->tx_irq[0] > 0) {
> +		priv->plat->flags |= STMMAC_FLAG_MULTI_IRQ_EN;
> +		priv->plat->dma_cfg->multi_irq_en = true;
> +	}

This is wrong. It activates the stmmac_request_irq_multi_msi() method
to assign all the IRQ handlers to the individual IRQs. Even if DMA
IRQs line are available it doesn't mean that for instance Safety
Feature IRQs too. So it's better to rely on the glue drivers to set
that flag as before and leave the code as is.

-Serge(y) 

>  
>  	priv->dev->irq = res->irq;
>  	priv->wol_irq = res->wol_irq;
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index dee5ad6e48c5..b950e6f9761d 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -98,7 +98,7 @@ struct stmmac_dma_cfg {
>  	int mixed_burst;
>  	bool aal;
>  	bool eame;
> -	bool multi_msi_en;
> +	bool multi_irq_en;
>  	bool dche;
>  };
>  
> @@ -215,7 +215,7 @@ struct dwmac4_addrs {
>  #define STMMAC_FLAG_TSO_EN			BIT(4)
>  #define STMMAC_FLAG_SERDES_UP_AFTER_PHY_LINKUP	BIT(5)
>  #define STMMAC_FLAG_VLAN_FAIL_Q_EN		BIT(6)
> -#define STMMAC_FLAG_MULTI_MSI_EN		BIT(7)
> +#define STMMAC_FLAG_MULTI_IRQ_EN		BIT(7)
>  #define STMMAC_FLAG_EXT_SNAPSHOT_EN		BIT(8)
>  #define STMMAC_FLAG_INT_SNAPSHOT_EN		BIT(9)
>  #define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI		BIT(10)
> -- 
> 2.34.1
> 
> 


From canghousehold at aol.com  Fri Dec 22 11:08:38 2023
From: canghousehold at aol.com (Household Cang)
Date: Fri, 22 Dec 2023 14:08:38 -0500
Subject: [PATCH net 0/1] Prevent DSA tags from breaking COE
In-Reply-To: <20231222123023.voxoxfcckxsz2vce@skbuf>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <0351C5C2-FEE2-4AED-84C8-9DCACCE4ED0A@aol.com>
 <20231222123023.voxoxfcckxsz2vce@skbuf>
Message-ID: <F568DE45-3140-4636-BCA6-24BB7140C6CE@aol.com>


> On Dec 22, 2023, at 7:30 AM, Vladimir Oltean <olteanv at gmail.com> wrote:
> 
> Is "rx off" actually required, or just "tx off??

Before adjusted the ethtool -K, the client upload speed is 880Mbps (download speed 0.6Mbps). RK3568 is acting as a router, so client is sending to eth1 via DSA user port, rx used here, and then tx on eth0. So this might suggest only tx needs to be turned off on eth1.

> 
> The MT7531BE switch requires transmitted packets to have an additional
> header which indicates what switch port is targeted. So the packet
> structure is not the same as what eth0 transmits.
> 

I understand. How many bytes are the DSA header for MT, 8 bytes?

> Your GMAC datasheet should explain what packets it is able to offload
> L4 checksumming for, quite plainly. Probably MAC + IP + TCP yes, but
> MAC + MTK DSA + IP + TCP no.

I hardly could find this in the data sheet for RK3568. From the DMA mapping, it insinuates a correct ether type needs to be detected after the MAC header, besides an inner and an outer VLAN tag, if there are any.

>  The driver still declares
> the NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM features because it is able to
> offload checksumming for _some_ packets, but it falls back to the
> software checksum helper for the rest. This includes your MTK DSA tagged
> packets.

I guess the end verdict regarding whether the hardware supports checksum offloading on DSA frames is a NO. So this is going to use some precious CPU power I am looking to fully dedicate to ipsec. Though I am pursuing crypto hw offloading at the same time with baylibre.

Lucas.

From graf at amazon.com  Fri Dec 22 11:35:50 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:50 +0000
Subject: [PATCH v2 00/17] kexec: Allow preservation of ftrace buffers
Message-ID: <20231222193607.15474-1-graf@amazon.com>

Kexec today considers itself purely a boot loader: When we enter the new
kernel, any state the previous kernel left behind is irrelevant and the
new kernel reinitializes the system.

However, there are use cases where this mode of operation is not what we
actually want. In virtualization hosts for example, we want to use kexec
to update the host kernel while virtual machine memory stays untouched.
When we add device assignment to the mix, we also need to ensure that
IOMMU and VFIO states are untouched. If we add PCIe peer to peer DMA, we
need to do the same for the PCI subsystem. If we want to kexec while an
SEV-SNP enabled virtual machine is running, we need to preserve the VM
context pages and physical memory. See James' and my Linux Plumbers
Conference 2023 presentation for details:

  https://lpc.events/event/17/contributions/1485/

To start us on the journey to support all the use cases above, this
patch implements basic infrastructure to allow hand over of kernel state
across kexec (Kexec HandOver, aka KHO). As example target, we use ftrace:
With this patch set applied, you can read ftrace records from the
pre-kexec environment in your post-kexec one. This creates a very powerful
debugging and performance analysis tool for kexec. It's also slightly
easier to reason about than full blown VFIO state preservation.

== Alternatives ==

There are alternative approaches to (parts of) the problems above:

  * Memory Pools [1] - preallocated persistent memory region + allocator
  * PRMEM [2] - resizable persistent memory regions with fixed metadata
                pointer on the kernel command line + allocator
  * Pkernfs [3] - preallocated file system for in-kernel data with fixed
                  address location on the kernel command line
  * PKRAM [4] - handover of user space pages using a fixed metadata page
                specified via command line

All of the approaches above fundamentally have the same problem: They
require the administrator to explicitly carve out a physical memory
location because they have no mechanism outside of the kernel command
line to pass data (including memory reservations) between kexec'ing
kernels.

KHO provides that base foundation. We will determine later whether we
still need any of the approaches above for fast bulk memory handover of for
example IOMMU page tables. But IMHO they would all be users of KHO, with
KHO providing the foundational primitive to pass metadata and bulk memory
reservations as well as provide easy versioning for data.

== Documentation ==

If people are happy with the approach in this patch set, I will write up
conclusive documentation including schemas for the metadata as part of its
next iteration. For now, here's a rudimentary overview:

We introduce a metadata file that the kernels pass between each other. How
they pass it is architecture specific. The file's format is a Flattened
Device Tree (fdt) which has a generator and parser already included in
Linux. When the root user enables KHO through /sys/kernel/kho/active, the
kernel invokes callbacks to every driver that supports KHO to serialize
its state. When the actual kexec happens, the fdt is part of the image
set that we boot into. In addition, we keep a "scratch region" available
for kexec: A physically contiguous memory region that is guaranteed to
not have any memory that KHO would preserve.  The new kernel bootstraps
itself using the scratch region and sets all handed over memory as in use.
When drivers initialize that support KHO, they introspect the fdt and
recover their state from it. This includes memory reservations, where the
driver can either discard or claim reservations.

== Limitations ==

I currently only implemented file based kexec. The kernel interfaces
in the patch set are already in place to support user space kexec as well,
but I have not implemented it yet.

== How to Use ==

To use the code, please boot the kernel with the "kho_scratch=" command
line parameter set: "kho_scratch=512M". KHO requires a scratch region.

Make sure to fill ftrace with contents that you want to observe after
kexec.  Then, before you invoke file based "kexec -l", activate KHO:

  # echo 1 > /sys/kernel/kho/active
  # kexec -l Image --initrd=initrd -s
  # kexec -e

The new kernel will boot up and contain the previous kernel's trace
buffers in /sys/kernel/debug/tracing/trace.

== Changelog ==

v1 -> v2:
  - Removed: tracing: Introduce names for ring buffers
  - Removed: tracing: Introduce names for events
  - New: kexec: Add config option for KHO
  - New: kexec: Add documentation for KHO
  - New: tracing: Initialize fields before registering
  - New: devicetree: Add bindings for ftrace KHO
  - test bot warning fixes
  - Change kconfig option to ARCH_SUPPORTS_KEXEC_KHO
  - s/kho_reserve_mem/kho_reserve_previous_mem/g
  - s/kho_reserve/kho_reserve_scratch/g
  - Remove / reduce ifdefs
  - Select crc32
  - Leave anything that requires a name in trace.c to keep buffers
    unnamed entities
  - Put events as array into a property, use fingerprint instead of
    names to identify them
  - Reduce footprint without CONFIG_FTRACE_KHO
  - s/kho_reserve_mem/kho_reserve_previous_mem/g
  - make kho_get_fdt() const
  - Add stubs for return_mem and claim_mem
  - make kho_get_fdt() const
  - Get events as array from a property, use fingerprint instead of
    names to identify events
  - Change kconfig option to ARCH_SUPPORTS_KEXEC_KHO
  - s/kho_reserve_mem/kho_reserve_previous_mem/g
  - s/kho_reserve/kho_reserve_scratch/g
  - Leave the node generation code that needs to know the name in
    trace.c so that ring buffers can stay anonymous
  - s/kho_reserve/kho_reserve_scratch/g
  - Move kho enums out of ifdef
  - Move from names to fdt offsets. That way, trace.c can find the trace
    array offset and then the ring buffer code only needs to read out
    its per-CPU data. That way it can stay oblivient to its name.
  - Make kho_get_fdt() const


Alex

[1] https://lore.kernel.org/all/169645773092.11424.7258549771090599226.stgit at skinsburskii./
[2] https://lore.kernel.org/all/20231016233215.13090-1-madvenka at linux.microsoft.com/
[3] https://lpc.events/event/17/contributions/1485/attachments/1296/2650/jgowans-preserving-across-kexec.pdf
[4] https://lore.kernel.org/kexec/1682554137-13938-1-git-send-email-anthony.yznaga at oracle.com/

Alexander Graf (17):
  mm,memblock: Add support for scratch memory
  memblock: Declare scratch memory as CMA
  kexec: Add Kexec HandOver (KHO) generation helpers
  kexec: Add KHO parsing support
  kexec: Add KHO support to kexec file loads
  kexec: Add config option for KHO
  kexec: Add documentation for KHO
  arm64: Add KHO support
  x86: Add KHO support
  tracing: Initialize fields before registering
  tracing: Introduce kho serialization
  tracing: Add kho serialization of trace buffers
  tracing: Recover trace buffers from kexec handover
  tracing: Add kho serialization of trace events
  tracing: Recover trace events from kexec handover
  tracing: Add config option for kexec handover
  devicetree: Add bindings for ftrace KHO

 Documentation/ABI/testing/sysfs-firmware-kho  |   9 +
 Documentation/ABI/testing/sysfs-kernel-kho    |  53 ++
 .../admin-guide/kernel-parameters.txt         |  10 +
 .../bindings/kho/ftrace/ftrace-array.yaml     |  46 ++
 .../bindings/kho/ftrace/ftrace-cpu.yaml       |  56 ++
 .../bindings/kho/ftrace/ftrace.yaml           |  48 ++
 Documentation/kho/concepts.rst                |  88 +++
 Documentation/kho/index.rst                   |  19 +
 Documentation/kho/usage.rst                   |  57 ++
 Documentation/subsystem-apis.rst              |   1 +
 MAINTAINERS                                   |   2 +
 arch/arm64/Kconfig                            |   3 +
 arch/arm64/kernel/setup.c                     |   2 +
 arch/arm64/mm/init.c                          |   8 +
 arch/x86/Kconfig                              |   3 +
 arch/x86/boot/compressed/kaslr.c              |  55 ++
 arch/x86/include/uapi/asm/bootparam.h         |  15 +-
 arch/x86/kernel/e820.c                        |   9 +
 arch/x86/kernel/kexec-bzimage64.c             |  39 ++
 arch/x86/kernel/setup.c                       |  46 ++
 arch/x86/mm/init_32.c                         |   7 +
 arch/x86/mm/init_64.c                         |   7 +
 drivers/of/fdt.c                              |  39 ++
 drivers/of/kexec.c                            |  54 ++
 include/linux/kexec.h                         |  58 ++
 include/linux/memblock.h                      |  19 +
 include/linux/ring_buffer.h                   |  17 +-
 include/linux/trace_events.h                  |   1 +
 include/uapi/linux/kexec.h                    |   6 +
 kernel/Kconfig.kexec                          |  13 +
 kernel/Makefile                               |   2 +
 kernel/kexec_file.c                           |  41 ++
 kernel/kexec_kho_in.c                         | 298 ++++++++++
 kernel/kexec_kho_out.c                        | 526 ++++++++++++++++++
 kernel/trace/Kconfig                          |  14 +
 kernel/trace/ring_buffer.c                    | 243 +++++++-
 kernel/trace/trace.c                          |  96 +++-
 kernel/trace/trace_events.c                   |  14 +-
 kernel/trace/trace_events_synth.c             |  14 +-
 kernel/trace/trace_events_user.c              |   4 +
 kernel/trace/trace_output.c                   | 246 +++++++-
 kernel/trace/trace_output.h                   |   5 +
 kernel/trace/trace_probe.c                    |   4 +
 mm/Kconfig                                    |   4 +
 mm/memblock.c                                 |  83 ++-
 45 files changed, 2360 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-kho
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-kho
 create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
 create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
 create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
 create mode 100644 Documentation/kho/concepts.rst
 create mode 100644 Documentation/kho/index.rst
 create mode 100644 Documentation/kho/usage.rst
 create mode 100644 kernel/kexec_kho_in.c
 create mode 100644 kernel/kexec_kho_out.c

-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:35:51 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:51 +0000
Subject: [PATCH v2 01/17] mm,memblock: Add support for scratch memory
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-2-graf@amazon.com>

With KHO (Kexec HandOver), we need a way to ensure that the new kernel
does not allocate memory on top of any memory regions that the previous
kernel was handing over. But to know where those are, we need to include
them in the reserved memblocks array which may not be big enough to hold
all allocations. To resize the array, we need to allocate memory. That
brings us into a catch 22 situation.

The solution to that is the scratch region: a safe region to operate in.
KHO provides a "scratch region" as part of its metadata. This scratch
region is a single, contiguous memory block that we know does not
contain any KHO allocations. We can exclusively allocate from there until
we finish kernel initialization to a point where it knows about all the
KHO memory reservations. We introduce a new memblock_set_scratch_only()
function that allows KHO to indicate that any memblock allocation must
happen from the scratch region.

Later, we may want to perform another KHO kexec. For that, we reuse the
same scratch region. To ensure that no eventually handed over data gets
allocated inside that scratch region, we flip the semantics of the scratch
region with memblock_clear_scratch_only(): After that call, no allocations
may happen from scratch memblock regions. We will lift that restriction
in the next patch.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 include/linux/memblock.h | 19 +++++++++++++
 mm/Kconfig               |  4 +++
 mm/memblock.c            | 61 +++++++++++++++++++++++++++++++++++++++-
 3 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index ae3bde302f70..14043f5b696f 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -42,6 +42,10 @@ extern unsigned long long max_possible_pfn;
  * kernel resource tree.
  * @MEMBLOCK_RSRV_NOINIT: memory region for which struct pages are
  * not initialized (only for reserved regions).
+ * @MEMBLOCK_SCRATCH: memory region that kexec can pass to the next kernel in
+ * handover mode. During early boot, we do not know about all memory reservations
+ * yet, so we get scratch memory from the previous kernel that we know is good
+ * to use. It is the only memory that allocations may happen from in this phase.
  */
 enum memblock_flags {
 	MEMBLOCK_NONE		= 0x0,	/* No special request */
@@ -50,6 +54,7 @@ enum memblock_flags {
 	MEMBLOCK_NOMAP		= 0x4,	/* don't add to kernel direct mapping */
 	MEMBLOCK_DRIVER_MANAGED = 0x8,	/* always detected via a driver */
 	MEMBLOCK_RSRV_NOINIT	= 0x10,	/* don't initialize struct pages */
+	MEMBLOCK_SCRATCH	= 0x20,	/* scratch memory for kexec handover */
 };
 
 /**
@@ -129,6 +134,8 @@ int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
 int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
 int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
 int memblock_reserved_mark_noinit(phys_addr_t base, phys_addr_t size);
+int memblock_mark_scratch(phys_addr_t base, phys_addr_t size);
+int memblock_clear_scratch(phys_addr_t base, phys_addr_t size);
 
 void memblock_free_all(void);
 void memblock_free(void *ptr, size_t size);
@@ -273,6 +280,11 @@ static inline bool memblock_is_driver_managed(struct memblock_region *m)
 	return m->flags & MEMBLOCK_DRIVER_MANAGED;
 }
 
+static inline bool memblock_is_scratch(struct memblock_region *m)
+{
+	return m->flags & MEMBLOCK_SCRATCH;
+}
+
 int memblock_search_pfn_nid(unsigned long pfn, unsigned long *start_pfn,
 			    unsigned long  *end_pfn);
 void __next_mem_pfn_range(int *idx, int nid, unsigned long *out_start_pfn,
@@ -610,5 +622,12 @@ static inline void early_memtest(phys_addr_t start, phys_addr_t end) { }
 static inline void memtest_report_meminfo(struct seq_file *m) { }
 #endif
 
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+void memblock_set_scratch_only(void);
+void memblock_clear_scratch_only(void);
+#else
+static inline void memblock_set_scratch_only(void) { }
+static inline void memblock_clear_scratch_only(void) { }
+#endif
 
 #endif /* _LINUX_MEMBLOCK_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index 57cd378c73d6..384369e40f10 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -513,6 +513,10 @@ config ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
 config HAVE_MEMBLOCK_PHYS_MAP
 	bool
 
+# Enable memblock support for scratch memory which is needed for KHO
+config MEMBLOCK_SCRATCH
+	bool
+
 config HAVE_FAST_GUP
 	depends on MMU
 	bool
diff --git a/mm/memblock.c b/mm/memblock.c
index 5a88d6d24d79..e89e6c8f9d75 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -106,6 +106,13 @@ unsigned long min_low_pfn;
 unsigned long max_pfn;
 unsigned long long max_possible_pfn;
 
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+/* When set to true, only allocate from MEMBLOCK_SCRATCH ranges */
+static bool scratch_only;
+#else
+#define scratch_only false
+#endif
+
 static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_MEMORY_REGIONS] __initdata_memblock;
 static struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_RESERVED_REGIONS] __initdata_memblock;
 #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
@@ -168,6 +175,10 @@ bool __init_memblock memblock_has_mirror(void)
 
 static enum memblock_flags __init_memblock choose_memblock_flags(void)
 {
+	/* skip non-scratch memory for kho early boot allocations */
+	if (scratch_only)
+		return MEMBLOCK_SCRATCH;
+
 	return system_has_some_mirror ? MEMBLOCK_MIRROR : MEMBLOCK_NONE;
 }
 
@@ -643,7 +654,7 @@ static int __init_memblock memblock_add_range(struct memblock_type *type,
 #ifdef CONFIG_NUMA
 			WARN_ON(nid != memblock_get_region_node(rgn));
 #endif
-			WARN_ON(flags != rgn->flags);
+			WARN_ON(flags != (rgn->flags & ~MEMBLOCK_SCRATCH));
 			nr_new++;
 			if (insert) {
 				if (start_rgn == -1)
@@ -890,6 +901,18 @@ int __init_memblock memblock_physmem_add(phys_addr_t base, phys_addr_t size)
 }
 #endif
 
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+__init_memblock void memblock_set_scratch_only(void)
+{
+	scratch_only = true;
+}
+
+__init_memblock void memblock_clear_scratch_only(void)
+{
+	scratch_only = false;
+}
+#endif
+
 /**
  * memblock_setclr_flag - set or clear flag for a memory region
  * @type: memblock type to set/clear flag for
@@ -1015,6 +1038,33 @@ int __init_memblock memblock_reserved_mark_noinit(phys_addr_t base, phys_addr_t
 				    MEMBLOCK_RSRV_NOINIT);
 }
 
+/**
+ * memblock_mark_scratch - Mark a memory region with flag MEMBLOCK_SCRATCH.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * Only memory regions marked with %MEMBLOCK_SCRATCH will be considered for
+ * allocations during early boot with kexec handover.
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+int __init_memblock memblock_mark_scratch(phys_addr_t base, phys_addr_t size)
+{
+	return memblock_setclr_flag(&memblock.memory, base, size, 1, MEMBLOCK_SCRATCH);
+}
+
+/**
+ * memblock_clear_scratch - Clear flag MEMBLOCK_SCRATCH for a specified region.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+int __init_memblock memblock_clear_scratch(phys_addr_t base, phys_addr_t size)
+{
+	return memblock_setclr_flag(&memblock.memory, base, size, 0, MEMBLOCK_SCRATCH);
+}
+
 static bool should_skip_region(struct memblock_type *type,
 			       struct memblock_region *m,
 			       int nid, int flags)
@@ -1046,6 +1096,14 @@ static bool should_skip_region(struct memblock_type *type,
 	if (!(flags & MEMBLOCK_DRIVER_MANAGED) && memblock_is_driver_managed(m))
 		return true;
 
+	/* In early alloc during kho, we can only consider scratch allocations */
+	if ((flags & MEMBLOCK_SCRATCH) && !memblock_is_scratch(m))
+		return true;
+
+	/* Leave scratch memory alone after scratch-only phase */
+	if (!(flags & MEMBLOCK_SCRATCH) && memblock_is_scratch(m))
+		return true;
+
 	return false;
 }
 
@@ -2211,6 +2269,7 @@ static const char * const flagname[] = {
 	[ilog2(MEMBLOCK_MIRROR)] = "MIRROR",
 	[ilog2(MEMBLOCK_NOMAP)] = "NOMAP",
 	[ilog2(MEMBLOCK_DRIVER_MANAGED)] = "DRV_MNG",
+	[ilog2(MEMBLOCK_SCRATCH)] = "SCRATCH",
 };
 
 static int memblock_debug_show(struct seq_file *m, void *private)
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:35:52 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:52 +0000
Subject: [PATCH v2 02/17] memblock: Declare scratch memory as CMA
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-3-graf@amazon.com>

When we finish populating our memory, we don't want to lose the scratch
region as memory we can use for useful data. Do do that, we mark it as
CMA memory. That means that any allocation within it only happens with
movable memory which we can then happily discard for the next kexec.

That way we don't lose the scratch region's memory anymore for
allocations after boot.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - test bot warning fix
---
 mm/memblock.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index e89e6c8f9d75..3700c2c1a96d 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -16,6 +16,7 @@
 #include <linux/kmemleak.h>
 #include <linux/seq_file.h>
 #include <linux/memblock.h>
+#include <linux/page-isolation.h>
 
 #include <asm/sections.h>
 #include <linux/io.h>
@@ -1100,10 +1101,6 @@ static bool should_skip_region(struct memblock_type *type,
 	if ((flags & MEMBLOCK_SCRATCH) && !memblock_is_scratch(m))
 		return true;
 
-	/* Leave scratch memory alone after scratch-only phase */
-	if (!(flags & MEMBLOCK_SCRATCH) && memblock_is_scratch(m))
-		return true;
-
 	return false;
 }
 
@@ -2153,6 +2150,20 @@ static void __init __free_pages_memory(unsigned long start, unsigned long end)
 	}
 }
 
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+static void reserve_scratch_mem(phys_addr_t start, phys_addr_t end)
+{
+	ulong start_pfn = pageblock_start_pfn(PFN_DOWN(start));
+	ulong end_pfn = pageblock_align(PFN_UP(end));
+	ulong pfn;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn += pageblock_nr_pages) {
+		/* Mark as CMA to prevent kernel allocations in it */
+		set_pageblock_migratetype(pfn_to_page(pfn), MIGRATE_CMA);
+	}
+}
+#endif
+
 static unsigned long __init __free_memory_core(phys_addr_t start,
 				 phys_addr_t end)
 {
@@ -2214,6 +2225,17 @@ static unsigned long __init free_low_memory_core_early(void)
 
 	memmap_init_reserved_pages();
 
+#ifdef CONFIG_MEMBLOCK_SCRATCH
+	/*
+	 * Mark scratch mem as CMA before we return it. That way we ensure that
+	 * no kernel allocations happen on it. That means we can reuse it as
+	 * scratch memory again later.
+	 */
+	__for_each_mem_range(i, &memblock.memory, NULL, NUMA_NO_NODE,
+			     MEMBLOCK_SCRATCH, &start, &end, NULL)
+		reserve_scratch_mem(start, end);
+#endif
+
 	/*
 	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
 	 *  because in some case like Node0 doesn't have RAM installed
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:35:53 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:53 +0000
Subject: [PATCH v2 03/17] kexec: Add Kexec HandOver (KHO) generation helpers
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-4-graf@amazon.com>

This patch adds the core infrastructure to generate Kexec HandOver
metadata. Kexec HandOver is a mechanism that allows Linux to preserve
state - arbitrary properties as well as memory locations - across kexec.

It does so using 3 concepts:

  1) Device Tree - Every KHO kexec carries a KHO specific flattened
     device tree blob that describes the state of the system. Device
     drivers can register to KHO to serialize their state before kexec.

  2) Mem cache - A memblocks like structure that contains full page
     ranges of reservations. These can not be part of the architectural
     reservations, because they differ on every kexec.

  3) Scratch Region - A CMA region that we allocate in the first kernel.
     CMA gives us the guarantee that no handover pages land in that
     region, because handover pages must be at a static physical memory
     location. We use this region as the place to load future kexec
     images into which then won't collide with any handover data.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - s/kho_reserve/kho_reserve_scratch/g
  - Move kho enums out of ifdef
---
 Documentation/ABI/testing/sysfs-kernel-kho    |  53 +++
 .../admin-guide/kernel-parameters.txt         |  10 +
 MAINTAINERS                                   |   1 +
 include/linux/kexec.h                         |  24 ++
 include/uapi/linux/kexec.h                    |   6 +
 kernel/Makefile                               |   1 +
 kernel/kexec_kho_out.c                        | 316 ++++++++++++++++++
 7 files changed, 411 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-kho
 create mode 100644 kernel/kexec_kho_out.c

diff --git a/Documentation/ABI/testing/sysfs-kernel-kho b/Documentation/ABI/testing/sysfs-kernel-kho
new file mode 100644
index 000000000000..f69e7b81a337
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-kho
@@ -0,0 +1,53 @@
+What:		/sys/kernel/kho/active
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		Kexec HandOver (KHO) allows Linux to transition the state of
+		compatible drivers into the next kexec'ed kernel. To do so,
+		device drivers will serialize their current state into a DT.
+		While the state is serialized, they are unable to perform
+		any modifications to state that was serialized, such as
+		handed over memory allocations.
+
+		When this file contains "1", the system is in the transition
+		state. When contains "0", it is not. To switch between the
+		two states, echo the respective number into this file.
+
+What:		/sys/kernel/kho/dt_max
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		KHO needs to allocate a buffer for the DT that gets
+		generated before it knows the final size. By default, it
+		will allocate 10 MiB for it. You can write to this file
+		to modify the size of that allocation.
+
+What:		/sys/kernel/kho/scratch_len
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		To support continuous KHO kexecs, we need to reserve a
+		physically contiguous memory region that will always stay
+		available for future kexec allocations. This file describes
+		the length of that memory region. Kexec user space tooling
+		can use this to determine where it should place its payload
+		images.
+
+What:		/sys/kernel/kho/scratch_phys
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		To support continuous KHO kexecs, we need to reserve a
+		physically contiguous memory region that will always stay
+		available for future kexec allocations. This file describes
+		the physical location of that memory region. Kexec user space
+		tooling can use this to determine where it should place its
+		payload images.
+
+What:		/sys/kernel/kho/dt
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		When KHO is active, the kernel exposes the generated DT that
+		carries its current KHO state in this file. Kexec user space
+		tooling can use this as input file for the KHO payload image.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 51575cd31741..efeef075617e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2504,6 +2504,16 @@
 	kgdbwait	[KGDB] Stop kernel execution and enter the
 			kernel debugger at the earliest opportunity.
 
+	kho_scratch=n[KMG]	[KEXEC] Sets the size of the KHO scratch
+			region. The KHO scratch region is a physically
+			memory range that can only be used for non-kernel
+			allocations. That way, even when memory is heavily
+			fragmented with handed over memory, kexec will always
+			be able to find contiguous memory to place the next
+			kernel for kexec into.
+
+			The default is 0.
+
 	kmac=		[MIPS] Korina ethernet MAC address.
 			Configure the RouterBoard 532 series on-chip
 			Ethernet adapter MAC address.
diff --git a/MAINTAINERS b/MAINTAINERS
index 9104430e148e..2a19bd282dd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11713,6 +11713,7 @@ M:	Eric Biederman <ebiederm at xmission.com>
 L:	kexec at lists.infradead.org
 S:	Maintained
 W:	http://kernel.org/pub/linux/utils/kernel/kexec/
+F:	Documentation/ABI/testing/sysfs-kernel-kho
 F:	include/linux/kexec.h
 F:	include/uapi/linux/kexec.h
 F:	kernel/kexec*
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 8227455192b7..5d3b6b015838 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -21,6 +21,8 @@
 
 #include <uapi/linux/kexec.h>
 #include <linux/verification.h>
+#include <linux/libfdt.h>
+#include <linux/notifier.h>
 
 extern note_buf_t __percpu *crash_notes;
 
@@ -516,6 +518,28 @@ void set_kexec_sig_enforced(void);
 static inline void set_kexec_sig_enforced(void) {}
 #endif
 
+/* Notifier index */
+enum kho_event {
+	KEXEC_KHO_DUMP = 0,
+	KEXEC_KHO_ABORT = 1,
+};
+
+#ifdef CONFIG_KEXEC_KHO
+extern phys_addr_t kho_scratch_phys;
+extern phys_addr_t kho_scratch_len;
+
+/* egest handover metadata */
+void kho_reserve_scratch(void);
+int register_kho_notifier(struct notifier_block *nb);
+int unregister_kho_notifier(struct notifier_block *nb);
+bool kho_is_active(void);
+#else
+static inline void kho_reserve_scratch(void) {}
+static inline int register_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
+static inline int unregister_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
+static inline bool kho_is_active(void) { return false; }
+#endif
+
 #endif /* !defined(__ASSEBMLY__) */
 
 #endif /* LINUX_KEXEC_H */
diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
index 01766dd839b0..d02ffd5960d6 100644
--- a/include/uapi/linux/kexec.h
+++ b/include/uapi/linux/kexec.h
@@ -49,6 +49,12 @@
 /* The artificial cap on the number of segments passed to kexec_load. */
 #define KEXEC_SEGMENT_MAX 16
 
+/* KHO passes an array of kho_mem as "mem cache" to the new kernel */
+struct kho_mem {
+	__u64 addr;
+	__u64 len;
+};
+
 #ifndef __KERNEL__
 /*
  * This structure is used to hold the arguments that are used when
diff --git a/kernel/Makefile b/kernel/Makefile
index 3947122d618b..a6bd31e22c09 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC_FILE) += kexec_file.o
 obj-$(CONFIG_KEXEC_ELF) += kexec_elf.o
+obj-$(CONFIG_KEXEC_KHO) += kexec_kho_out.o
 obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
 obj-$(CONFIG_COMPAT) += compat.o
 obj-$(CONFIG_CGROUPS) += cgroup/
diff --git a/kernel/kexec_kho_out.c b/kernel/kexec_kho_out.c
new file mode 100644
index 000000000000..765cf6ba7a46
--- /dev/null
+++ b/kernel/kexec_kho_out.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * kexec_kho_out.c - kexec handover code to egest metadata.
+ * Copyright (C) 2023 Alexander Graf <graf at amazon.com>
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/cma.h>
+#include <linux/kexec.h>
+#include <linux/device.h>
+#include <linux/compiler.h>
+#include <linux/kmsg_dump.h>
+
+struct kho_out {
+	struct kobject *kobj;
+	bool active;
+	struct cma *cma;
+	struct blocking_notifier_head chain_head;
+	void *dt;
+	u64 dt_len;
+	u64 dt_max;
+	struct mutex lock;
+};
+
+static struct kho_out kho = {
+	.dt_max = (1024 * 1024 * 10),
+	.chain_head = BLOCKING_NOTIFIER_INIT(kho.chain_head),
+	.lock = __MUTEX_INITIALIZER(kho.lock),
+};
+
+/*
+ * Size for scratch (non-KHO) memory. With KHO enabled, memory can become
+ * fragmented because KHO regions may be anywhere in physical address
+ * space. The scratch region gives us a safe zone that we will never see
+ * KHO allocations from. This is where we can later safely load our new kexec
+ * images into.
+ */
+static phys_addr_t kho_scratch_size __initdata;
+
+int register_kho_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_register(&kho.chain_head, nb);
+}
+EXPORT_SYMBOL_GPL(register_kho_notifier);
+
+int unregister_kho_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_unregister(&kho.chain_head, nb);
+}
+EXPORT_SYMBOL_GPL(unregister_kho_notifier);
+
+bool kho_is_active(void)
+{
+	return kho.active;
+}
+EXPORT_SYMBOL_GPL(kho_is_active);
+
+static ssize_t raw_read(struct file *file, struct kobject *kobj,
+			struct bin_attribute *attr, char *buf,
+			loff_t pos, size_t count)
+{
+	mutex_lock(&kho.lock);
+	memcpy(buf, attr->private + pos, count);
+	mutex_unlock(&kho.lock);
+
+	return count;
+}
+
+static BIN_ATTR(dt, 0400, raw_read, NULL, 0);
+
+static int kho_expose_dt(void *fdt)
+{
+	long fdt_len = fdt_totalsize(fdt);
+	int err;
+
+	kho.dt = fdt;
+	kho.dt_len = fdt_len;
+
+	bin_attr_dt.size = fdt_totalsize(fdt);
+	bin_attr_dt.private = fdt;
+	err = sysfs_create_bin_file(kho.kobj, &bin_attr_dt);
+
+	return err;
+}
+
+static void kho_abort(void)
+{
+	if (!kho.active)
+		return;
+
+	sysfs_remove_bin_file(kho.kobj, &bin_attr_dt);
+
+	kvfree(kho.dt);
+	kho.dt = NULL;
+	kho.dt_len = 0;
+
+	blocking_notifier_call_chain(&kho.chain_head, KEXEC_KHO_ABORT, NULL);
+
+	kho.active = false;
+}
+
+static int kho_serialize(void)
+{
+	void *fdt = NULL;
+	int err;
+
+	kho.active = true;
+	err = -ENOMEM;
+
+	fdt = kvmalloc(kho.dt_max, GFP_KERNEL);
+	if (!fdt)
+		goto out;
+
+	if (fdt_create(fdt, kho.dt_max)) {
+		err = -EINVAL;
+		goto out;
+	}
+
+	err = fdt_finish_reservemap(fdt);
+	if (err)
+		goto out;
+
+	err = fdt_begin_node(fdt, "");
+	if (err)
+		goto out;
+
+	err = fdt_property_string(fdt, "compatible", "kho-v1");
+	if (err)
+		goto out;
+
+	/* Loop through all kho dump functions */
+	err = blocking_notifier_call_chain(&kho.chain_head, KEXEC_KHO_DUMP, fdt);
+	err = notifier_to_errno(err);
+	if (err)
+		goto out;
+
+	/* Close / */
+	err =  fdt_end_node(fdt);
+	if (err)
+		goto out;
+
+	err = fdt_finish(fdt);
+	if (err)
+		goto out;
+
+	if (WARN_ON(fdt_check_header(fdt))) {
+		err = -EINVAL;
+		goto out;
+	}
+
+	err = kho_expose_dt(fdt);
+
+out:
+	if (err) {
+		pr_err("kho failed to serialize state: %d", err);
+		kho_abort();
+	}
+	return err;
+}
+
+/* Handling for /sys/kernel/kho */
+
+#define KHO_ATTR_RO(_name) static struct kobj_attribute _name##_attr = __ATTR_RO_MODE(_name, 0400)
+#define KHO_ATTR_RW(_name) static struct kobj_attribute _name##_attr = __ATTR_RW_MODE(_name, 0600)
+
+static ssize_t active_store(struct kobject *dev, struct kobj_attribute *attr,
+			    const char *buf, size_t size)
+{
+	ssize_t retsize = size;
+	bool val = false;
+	int ret;
+
+	if (kstrtobool(buf, &val) < 0)
+		return -EINVAL;
+
+	if (!kho_scratch_len)
+		return -ENOMEM;
+
+	mutex_lock(&kho.lock);
+	if (val != kho.active) {
+		if (val) {
+			ret = kho_serialize();
+			if (ret) {
+				retsize = -EINVAL;
+				goto out;
+			}
+		} else {
+			kho_abort();
+		}
+	}
+
+out:
+	mutex_unlock(&kho.lock);
+	return retsize;
+}
+
+static ssize_t active_show(struct kobject *dev, struct kobj_attribute *attr,
+			   char *buf)
+{
+	ssize_t ret;
+
+	mutex_lock(&kho.lock);
+	ret = sysfs_emit(buf, "%d\n", kho.active);
+	mutex_unlock(&kho.lock);
+
+	return ret;
+}
+KHO_ATTR_RW(active);
+
+static ssize_t dt_max_store(struct kobject *dev, struct kobj_attribute *attr,
+			    const char *buf, size_t size)
+{
+	u64 val;
+
+	if (kstrtoull(buf, 0, &val))
+		return -EINVAL;
+
+	kho.dt_max = val;
+
+	return size;
+}
+
+static ssize_t dt_max_show(struct kobject *dev, struct kobj_attribute *attr,
+			   char *buf)
+{
+	return sysfs_emit(buf, "0x%llx\n", kho.dt_max);
+}
+KHO_ATTR_RW(dt_max);
+
+static ssize_t scratch_len_show(struct kobject *dev, struct kobj_attribute *attr,
+				char *buf)
+{
+	return sysfs_emit(buf, "0x%llx\n", kho_scratch_len);
+}
+KHO_ATTR_RO(scratch_len);
+
+static ssize_t scratch_phys_show(struct kobject *dev, struct kobj_attribute *attr,
+				 char *buf)
+{
+	return sysfs_emit(buf, "0x%llx\n", kho_scratch_phys);
+}
+KHO_ATTR_RO(scratch_phys);
+
+static __init int kho_out_init(void)
+{
+	int ret = 0;
+
+	kho.kobj = kobject_create_and_add("kho", kernel_kobj);
+	if (!kho.kobj) {
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	ret = sysfs_create_file(kho.kobj, &active_attr.attr);
+	if (ret)
+		goto err;
+
+	ret = sysfs_create_file(kho.kobj, &dt_max_attr.attr);
+	if (ret)
+		goto err;
+
+	ret = sysfs_create_file(kho.kobj, &scratch_phys_attr.attr);
+	if (ret)
+		goto err;
+
+	ret = sysfs_create_file(kho.kobj, &scratch_len_attr.attr);
+	if (ret)
+		goto err;
+
+err:
+	return ret;
+}
+late_initcall(kho_out_init);
+
+static int __init early_kho_scratch(char *p)
+{
+	kho_scratch_size = memparse(p, &p);
+	return 0;
+}
+early_param("kho_scratch", early_kho_scratch);
+
+/**
+ * kho_reserve_scratch - Reserve a contiguous chunk of memory for kexec
+ *
+ * With KHO we can preserve arbitrary pages in the system. To ensure we still
+ * have a large contiguous region of memory when we search the physical address
+ * space for target memory, let's make sure we always have a large CMA region
+ * active. This CMA region will only be used for movable pages which are not a
+ * problem for us during KHO because we can just move them somewhere else.
+ */
+__init void kho_reserve_scratch(void)
+{
+	int r;
+
+	if (kho_get_fdt()) {
+		/*
+		 * We came from a previous KHO handover, so we already have
+		 * a known good scratch region that we preserve. No need to
+		 * allocate another.
+		 */
+		return;
+	}
+
+	/* Only allocate KHO scratch memory when we're asked to */
+	if (!kho_scratch_size)
+		return;
+
+	r = cma_declare_contiguous_nid(0, kho_scratch_size, 0, PAGE_SIZE, 0,
+				       false, "kho", &kho.cma, NUMA_NO_NODE);
+	if (WARN_ON(r))
+		return;
+
+	kho_scratch_phys = cma_get_base(kho.cma);
+	kho_scratch_len = cma_get_size(kho.cma);
+}
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:35:54 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:54 +0000
Subject: [PATCH v2 04/17] kexec: Add KHO parsing support
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-5-graf@amazon.com>

When we have a KHO kexec, we get a device tree, mem cache and scratch
region to populate the state of the system. Provide helper functions
that allow architecture code to easily handle memory reservations based
on them and give device drivers visibility into the KHO DT and memory
reservations so they can recover their own state.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - s/kho_reserve_mem/kho_reserve_previous_mem/g
  - make kho_get_fdt() const
  - Add stubs for return_mem and claim_mem
---
 Documentation/ABI/testing/sysfs-firmware-kho |   9 +
 MAINTAINERS                                  |   1 +
 include/linux/kexec.h                        |  27 +-
 kernel/Makefile                              |   1 +
 kernel/kexec_kho_in.c                        | 298 +++++++++++++++++++
 5 files changed, 335 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-kho
 create mode 100644 kernel/kexec_kho_in.c

diff --git a/Documentation/ABI/testing/sysfs-firmware-kho b/Documentation/ABI/testing/sysfs-firmware-kho
new file mode 100644
index 000000000000..e4ed2cb7c810
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-kho
@@ -0,0 +1,9 @@
+What:		/sys/firmware/kho/dt
+Date:		December 2023
+Contact:	Alexander Graf <graf at amazon.com>
+Description:
+		When the kernel was booted with Kexec HandOver (KHO),
+		the device tree that carries metadata about the previous
+		kernel's state is in this file. This file may disappear
+		when all consumers of it finished to interpret their
+		metadata.
diff --git a/MAINTAINERS b/MAINTAINERS
index 2a19bd282dd0..61bdfd47bb23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11713,6 +11713,7 @@ M:	Eric Biederman <ebiederm at xmission.com>
 L:	kexec at lists.infradead.org
 S:	Maintained
 W:	http://kernel.org/pub/linux/utils/kernel/kexec/
+F:	Documentation/ABI/testing/sysfs-firmware-kho
 F:	Documentation/ABI/testing/sysfs-kernel-kho
 F:	include/linux/kexec.h
 F:	include/uapi/linux/kexec.h
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 5d3b6b015838..765f71976230 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -528,13 +528,38 @@ enum kho_event {
 extern phys_addr_t kho_scratch_phys;
 extern phys_addr_t kho_scratch_len;
 
+/* ingest handover metadata */
+void kho_reserve_previous_mem(void);
+void kho_populate(phys_addr_t dt_phys, phys_addr_t scratch_phys, u64 scratch_len,
+		  phys_addr_t mem_phys, u64 mem_len);
+void kho_populate_refcount(void);
+const void *kho_get_fdt(void);
+void kho_return_mem(const struct kho_mem *mem);
+void *kho_claim_mem(const struct kho_mem *mem);
+static inline bool is_kho_boot(void)
+{
+	return !!kho_scratch_phys;
+}
+
 /* egest handover metadata */
 void kho_reserve_scratch(void);
 int register_kho_notifier(struct notifier_block *nb);
 int unregister_kho_notifier(struct notifier_block *nb);
 bool kho_is_active(void);
 #else
-static inline void kho_reserve_scratch(void) {}
+/* ingest handover metadata */
+static inline void kho_reserve_previous_mem(void) { }
+static inline void kho_populate(phys_addr_t dt_phys, phys_addr_t scratch_phys,
+				u64 scratch_len, phys_addr_t mem_phys,
+				u64 mem_len) { }
+static inline void kho_populate_refcount(void) { }
+static inline void *kho_get_fdt(void) { return NULL; }
+static inline void kho_return_mem(const struct kho_mem *mem) { }
+static inline void *kho_claim_mem(const struct kho_mem *mem) { return NULL; }
+static inline bool is_kho_boot(void) { return false; }
+
+/* egest handover metadata */
+static inline void kho_reserve_scratch(void) { }
 static inline int register_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
 static inline int unregister_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
 static inline bool kho_is_active(void) { return false; }
diff --git a/kernel/Makefile b/kernel/Makefile
index a6bd31e22c09..7c3065e40c75 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC_FILE) += kexec_file.o
 obj-$(CONFIG_KEXEC_ELF) += kexec_elf.o
+obj-$(CONFIG_KEXEC_KHO) += kexec_kho_in.o
 obj-$(CONFIG_KEXEC_KHO) += kexec_kho_out.o
 obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
 obj-$(CONFIG_COMPAT) += compat.o
diff --git a/kernel/kexec_kho_in.c b/kernel/kexec_kho_in.c
new file mode 100644
index 000000000000..5f8e0d9f9e12
--- /dev/null
+++ b/kernel/kexec_kho_in.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * kexec_kho_in.c - kexec handover code to ingest metadata.
+ * Copyright (C) 2023 Alexander Graf <graf at amazon.com>
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/kexec.h>
+#include <linux/device.h>
+#include <linux/compiler.h>
+#include <linux/io.h>
+#include <linux/kmsg_dump.h>
+#include <linux/memblock.h>
+
+/* The kho dt during runtime */
+static void *fdt;
+
+/* Globals to hand over phys/len from early to runtime */
+static phys_addr_t handover_phys __initdata;
+static u32 handover_len __initdata;
+
+static phys_addr_t mem_phys __initdata;
+static u32 mem_len __initdata;
+
+phys_addr_t kho_scratch_phys;
+phys_addr_t kho_scratch_len;
+
+const void *kho_get_fdt(void)
+{
+	return fdt;
+}
+EXPORT_SYMBOL_GPL(kho_get_fdt);
+
+/**
+ * kho_populate_refcount - Scan the DT for any memory ranges. Increase the
+ * affected pages' refcount by 1 for each.
+ */
+__init void kho_populate_refcount(void)
+{
+	const void *fdt = kho_get_fdt();
+	void *mem_virt = __va(mem_phys);
+	int offset = 0, depth = 0, initial_depth = 0, len;
+
+	if (!fdt)
+		return;
+
+	/* Go through the mem list and add 1 for each reference */
+	for (offset = 0;
+	     offset >= 0 && depth >= initial_depth;
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		const struct kho_mem *mems;
+		u32 i;
+
+		mems = fdt_getprop(fdt, offset, "mem", &len);
+		if (!mems || len & (sizeof(*mems) - 1))
+			continue;
+
+		for (i = 0; i < len; i += sizeof(*mems)) {
+			const struct kho_mem *mem = ((void *)mems) + i;
+			u64 start_pfn = PFN_DOWN(mem->addr);
+			u64 end_pfn = PFN_UP(mem->addr + mem->len);
+			u64 pfn;
+
+			for (pfn = start_pfn; pfn < end_pfn; pfn++)
+				get_page(pfn_to_page(pfn));
+		}
+	}
+
+	/*
+	 * Then reduce the reference count by 1 to offset the initial ref count
+	 * of 1. In addition, unreserve the page. That way, we can free_page()
+	 * it for every consumer and automatically free it to the global memory
+	 * pool when everyone is done.
+	 */
+	for (offset = 0; offset < mem_len; offset += sizeof(struct kho_mem)) {
+		struct kho_mem *mem = mem_virt + offset;
+		u64 start_pfn = PFN_DOWN(mem->addr);
+		u64 end_pfn = PFN_UP(mem->addr + mem->len);
+		u64 pfn;
+
+		for (pfn = start_pfn; pfn < end_pfn; pfn++) {
+			struct page *page = pfn_to_page(pfn);
+
+			/*
+			 * This is similar to free_reserved_page(), but
+			 * preserves the reference count
+			 */
+			ClearPageReserved(page);
+			__free_page(page);
+			adjust_managed_page_count(page, 1);
+		}
+	}
+}
+
+static void kho_return_pfn(ulong pfn)
+{
+	struct page *page = pfn_to_page(pfn);
+
+	if (WARN_ON(!page))
+		return;
+	__free_page(page);
+}
+
+/**
+ * kho_return_mem - Notify the kernel that initially reserved memory is no
+ * longer needed. When the last consumer of a page returns their mem, kho
+ * returns the page to the buddy allocator as free page.
+ */
+void kho_return_mem(const struct kho_mem *mem)
+{
+	uint64_t start_pfn, end_pfn, pfn;
+
+	start_pfn = PFN_DOWN(mem->addr);
+	end_pfn = PFN_UP(mem->addr + mem->len);
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		kho_return_pfn(pfn);
+}
+EXPORT_SYMBOL_GPL(kho_return_mem);
+
+static void kho_claim_pfn(ulong pfn)
+{
+	struct page *page = pfn_to_page(pfn);
+
+	WARN_ON(!page);
+	if (WARN_ON(page_count(page) != 1))
+		pr_err("Claimed non kho pfn %lx", pfn);
+}
+
+/**
+ * kho_claim_mem - Notify the kernel that a handed over memory range is now in
+ * use by a kernel subsystem and considered an allocated page. This function
+ * removes the reserved state for all pages that the mem spans.
+ */
+void *kho_claim_mem(const struct kho_mem *mem)
+{
+	u64 start_pfn, end_pfn, pfn;
+	void *va = __va(mem->addr);
+
+	start_pfn = PFN_DOWN(mem->addr);
+	end_pfn = PFN_UP(mem->addr + mem->len);
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		kho_claim_pfn(pfn);
+
+	return va;
+}
+EXPORT_SYMBOL_GPL(kho_claim_mem);
+
+/**
+ * kho_reserve_previous_mem - Adds all memory reservations into memblocks
+ * and moves us out of the scratch only phase. Must be called after page tables
+ * are initialized and memblock_allow_resize().
+ */
+void __init kho_reserve_previous_mem(void)
+{
+	void *mem_virt = __va(mem_phys);
+	int off, err;
+
+	if (!handover_phys || !mem_phys)
+		return;
+
+	/*
+	 * We reached here because we are running inside a working linear map
+	 * that allows us to resize memblocks dynamically. Use the chance and
+	 * populate the global fdt pointer
+	 */
+	fdt = __va(handover_phys);
+
+	off = fdt_path_offset(fdt, "/");
+	if (off < 0) {
+		fdt = NULL;
+		return;
+	}
+
+	err = fdt_node_check_compatible(fdt, off, "kho-v1");
+	if (err) {
+		pr_warn("KHO has invalid compatible, disabling.");
+		return;
+	}
+
+	/* Then populate all preserved memory areas as reserved */
+	for (off = 0; off < mem_len; off += sizeof(struct kho_mem)) {
+		struct kho_mem *mem = mem_virt + off;
+
+		memblock_reserve(mem->addr, mem->len);
+	}
+
+	/* Unreserve the mem cache - we don't need it from here on */
+	memblock_phys_free(mem_phys, mem_len);
+
+	/*
+	 * Now we know about all memory reservations, release the scratch only
+	 * constraint and allow normal allocations from the scratch region.
+	 */
+	memblock_clear_scratch_only();
+}
+
+/* Handling for /sys/firmware/kho */
+static struct kobject *kho_kobj;
+
+static ssize_t raw_read(struct file *file, struct kobject *kobj,
+			struct bin_attribute *attr, char *buf,
+			loff_t pos, size_t count)
+{
+	memcpy(buf, attr->private + pos, count);
+	return count;
+}
+
+static BIN_ATTR(dt, 0400, raw_read, NULL, 0);
+
+static __init int kho_in_init(void)
+{
+	int ret = 0;
+
+	if (!fdt)
+		return 0;
+
+	kho_kobj = kobject_create_and_add("kho", firmware_kobj);
+	if (!kho_kobj) {
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	bin_attr_dt.size = fdt_totalsize(fdt);
+	bin_attr_dt.private = fdt;
+	ret = sysfs_create_bin_file(kho_kobj, &bin_attr_dt);
+	if (ret)
+		goto err;
+
+err:
+	return ret;
+}
+subsys_initcall(kho_in_init);
+
+void __init kho_populate(phys_addr_t handover_dt_phys, phys_addr_t scratch_phys,
+			 u64 scratch_len, phys_addr_t mem_cache_phys,
+			 u64 mem_cache_len)
+{
+	void *handover_dt;
+
+	/* Determine the real size of the DT */
+	handover_dt = early_memremap(handover_dt_phys, sizeof(struct fdt_header));
+	if (!handover_dt) {
+		pr_warn("setup: failed to memremap kexec FDT (0x%llx)\n", handover_dt_phys);
+		return;
+	}
+
+	if (fdt_check_header(handover_dt)) {
+		pr_warn("setup: kexec handover FDT is invalid (0x%llx)\n", handover_dt_phys);
+		early_memunmap(handover_dt, PAGE_SIZE);
+		return;
+	}
+
+	handover_len = fdt_totalsize(handover_dt);
+	handover_phys = handover_dt_phys;
+
+	/* Reserve the DT so we can still access it in late boot */
+	memblock_reserve(handover_phys, handover_len);
+
+	/* Reserve the mem cache so we can still access it later */
+	memblock_reserve(mem_cache_phys, mem_cache_len);
+
+	/*
+	 * We pass a safe contiguous block of memory to use for early boot purporses from
+	 * the previous kernel so that we can resize the memblock array as needed.
+	 */
+	memblock_add(scratch_phys, scratch_len);
+
+	if (WARN_ON(memblock_mark_scratch(scratch_phys, scratch_len))) {
+		pr_err("Kexec failed to mark the scratch region. Disabling KHO.");
+		handover_len = 0;
+		handover_phys = 0;
+		return;
+	}
+	pr_debug("Marked 0x%lx+0x%lx as scratch", (long)scratch_phys, (long)scratch_len);
+
+	/*
+	 * Now that we have a viable region of scratch memory, let's tell the memblocks
+	 * allocator to only use that for any allocations. That way we ensure that nothing
+	 * scribbles over in use data while we initialize the page tables which we will need
+	 * to ingest all memory reservations from the previous kernel.
+	 */
+	memblock_set_scratch_only();
+
+	early_memunmap(handover_dt, sizeof(struct fdt_header));
+
+	/* Remember the mem cache location for kho_reserve_previous_mem() */
+	mem_len = mem_cache_len;
+	mem_phys = mem_cache_phys;
+
+	/* Remember the scratch block - we will reuse it again for the next kexec */
+	kho_scratch_phys = scratch_phys;
+	kho_scratch_len = scratch_len;
+
+	pr_info("setup: Found kexec handover data. Will skip init for some devices\n");
+}
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:35:55 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:55 +0000
Subject: [PATCH v2 05/17] kexec: Add KHO support to kexec file loads
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-6-graf@amazon.com>

Kexec has 2 modes: A user space driven mode and a kernel driven mode.
For the kernel driven mode, kernel code determines the physical
addresses of all target buffers that the payload gets copied into.

With KHO, we can only safely copy payloads into the "scratch area".
Teach the kexec file loader about it, so it only allocates for that
area. In addition, enlighten it with support to ask the KHO subsystem
for its respective payloads to copy into target memory. Also teach the
KHO subsystem how to fill the images for file loads.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 include/linux/kexec.h  |   9 ++
 kernel/kexec_file.c    |  41 ++++++++
 kernel/kexec_kho_out.c | 210 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 260 insertions(+)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 765f71976230..39a2990007a8 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -362,6 +362,13 @@ struct kimage {
 	size_t ima_buffer_size;
 #endif
 
+#ifdef CONFIG_KEXEC_KHO
+	struct {
+		struct kexec_buf dt;
+		struct kexec_buf mem_cache;
+	} kho;
+#endif
+
 	/* Core ELF header buffer */
 	void *elf_headers;
 	unsigned long elf_headers_sz;
@@ -543,6 +550,7 @@ static inline bool is_kho_boot(void)
 
 /* egest handover metadata */
 void kho_reserve_scratch(void);
+int kho_fill_kimage(struct kimage *image);
 int register_kho_notifier(struct notifier_block *nb);
 int unregister_kho_notifier(struct notifier_block *nb);
 bool kho_is_active(void);
@@ -560,6 +568,7 @@ static inline bool is_kho_boot(void) { return false; }
 
 /* egest handover metadata */
 static inline void kho_reserve_scratch(void) { }
+static inline int kho_fill_kimage(struct kimage *image) { return 0; }
 static inline int register_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
 static inline int unregister_kho_notifier(struct notifier_block *nb) { return -EINVAL; }
 static inline bool kho_is_active(void) { return false; }
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index f9a419cd22d4..d895d0a49bd9 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -113,6 +113,13 @@ void kimage_file_post_load_cleanup(struct kimage *image)
 	image->ima_buffer = NULL;
 #endif /* CONFIG_IMA_KEXEC */
 
+#ifdef CONFIG_KEXEC_KHO
+	kvfree(image->kho.mem_cache.buffer);
+	image->kho.mem_cache = (struct kexec_buf) {};
+	kvfree(image->kho.dt.buffer);
+	image->kho.dt = (struct kexec_buf) {};
+#endif
+
 	/* See if architecture has anything to cleanup post load */
 	arch_kimage_file_post_load_cleanup(image);
 
@@ -249,6 +256,11 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd,
 	/* IMA needs to pass the measurement list to the next kernel. */
 	ima_add_kexec_buffer(image);
 
+	/* If KHO is active, add its images to the list */
+	ret = kho_fill_kimage(image);
+	if (ret)
+		goto out;
+
 	/* Call image load handler */
 	ldata = kexec_image_load_default(image);
 
@@ -518,6 +530,24 @@ static int locate_mem_hole_callback(struct resource *res, void *arg)
 	return locate_mem_hole_bottom_up(start, end, kbuf);
 }
 
+#ifdef CONFIG_KEXEC_KHO
+static int kexec_walk_kho_scratch(struct kexec_buf *kbuf,
+				  int (*func)(struct resource *, void *))
+{
+	int ret = 0;
+
+	struct resource res = {
+		.start = kho_scratch_phys,
+		.end = kho_scratch_phys + kho_scratch_len,
+	};
+
+	/* Try to fit the kimage into our KHO scratch region */
+	ret = func(&res, kbuf);
+
+	return ret;
+}
+#endif
+
 #ifdef CONFIG_ARCH_KEEP_MEMBLOCK
 static int kexec_walk_memblock(struct kexec_buf *kbuf,
 			       int (*func)(struct resource *, void *))
@@ -612,6 +642,17 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
 	if (kbuf->mem != KEXEC_BUF_MEM_UNKNOWN)
 		return 0;
 
+#ifdef CONFIG_KEXEC_KHO
+	/*
+	 * If KHO is active, only use KHO scratch memory. All other memory
+	 * could potentially be handed over.
+	 */
+	if (kho_is_active() && kbuf->image->type != KEXEC_TYPE_CRASH) {
+		ret = kexec_walk_kho_scratch(kbuf, locate_mem_hole_callback);
+		return ret == 1 ? 0 : -EADDRNOTAVAIL;
+	}
+#endif
+
 	if (!IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK))
 		ret = kexec_walk_resources(kbuf, locate_mem_hole_callback);
 	else
diff --git a/kernel/kexec_kho_out.c b/kernel/kexec_kho_out.c
index 765cf6ba7a46..2cf5755f5e4a 100644
--- a/kernel/kexec_kho_out.c
+++ b/kernel/kexec_kho_out.c
@@ -50,6 +50,216 @@ int unregister_kho_notifier(struct notifier_block *nb)
 }
 EXPORT_SYMBOL_GPL(unregister_kho_notifier);
 
+static int kho_mem_cache_add(void *fdt, struct kho_mem *mem_cache, int size,
+			     struct kho_mem *new_mem)
+{
+	int entries = size / sizeof(*mem_cache);
+	u64 new_start = new_mem->addr;
+	u64 new_end = new_mem->addr + new_mem->len;
+	u64 prev_start = 0;
+	u64 prev_end = 0;
+	int i;
+
+	if (WARN_ON((new_start < (kho_scratch_phys + kho_scratch_len)) &&
+		    (new_end > kho_scratch_phys))) {
+		pr_err("KHO memory runs over scratch memory");
+		return -EINVAL;
+	}
+
+	/*
+	 * We walk the existing sorted mem cache and find the spot where this
+	 * new entry would start, so we can insert it right there.
+	 */
+	for (i = 0; i < entries; i++) {
+		struct kho_mem *mem = &mem_cache[i];
+		u64 mem_end = (mem->addr + mem->len);
+
+		if (mem_end < new_start) {
+			/* No overlap */
+			prev_start = mem->addr;
+			prev_end = mem->addr + mem->len;
+			continue;
+		} else if ((new_start >= mem->addr) && (new_end <= mem_end)) {
+			/* new_mem fits into mem, skip */
+			return size;
+		} else if ((new_end >= mem->addr) && (new_start <= mem_end)) {
+			/* new_mem and mem overlap, fold them */
+			bool remove = false;
+
+			mem->addr = min(new_start, mem->addr);
+			mem->len = max(mem_end, new_end) - mem->addr;
+			mem_end = (mem->addr + mem->len);
+
+			if (i > 0 && prev_end >= mem->addr) {
+				/* We now overlap with the previous mem, fold */
+				struct kho_mem *prev = &mem_cache[i - 1];
+
+				prev->addr = min(prev->addr, mem->addr);
+				prev->len = max(mem_end, prev_end) - prev->addr;
+				remove = true;
+			} else if (i < (entries - 1) && mem_end >= mem_cache[i + 1].addr) {
+				/* We now overlap with the next mem, fold */
+				struct kho_mem *next = &mem_cache[i + 1];
+				u64 next_end = (next->addr + next->len);
+
+				next->addr = min(next->addr, mem->addr);
+				next->len = max(mem_end, next_end) - next->addr;
+				remove = true;
+			}
+
+			if (remove) {
+				/* We folded this mem into another, remove it */
+				memmove(mem, mem + 1, (entries - i - 1) * sizeof(*mem));
+				size -= sizeof(*new_mem);
+			}
+
+			return size;
+		} else if (mem->addr > new_end) {
+			/*
+			 * The mem cache is sorted. If we find the current
+			 * entry start after our new_mem's end, we shot over
+			 * which means we need to add it by creating a new
+			 * hole right after the current entry.
+			 */
+			memmove(mem + 1, mem, (entries - i) * sizeof(*mem));
+			break;
+		}
+	}
+
+	mem_cache[i] = *new_mem;
+	size += sizeof(*new_mem);
+
+	return size;
+}
+
+/**
+ * kho_alloc_mem_cache - Allocate and initialize the mem cache kexec_buf
+ */
+static int kho_alloc_mem_cache(struct kimage *image, void *fdt)
+{
+	int offset, depth, initial_depth, len;
+	void *mem_cache;
+	int size;
+
+	/* Count the elements inside all "mem" properties in the DT */
+	size = offset = depth = initial_depth = 0;
+	for (offset = 0;
+	     offset >= 0 && depth >= initial_depth;
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		const struct kho_mem *mems;
+
+		mems = fdt_getprop(fdt, offset, "mem", &len);
+		if (!mems || len & (sizeof(*mems) - 1))
+			continue;
+		size += len;
+	}
+
+	/* Allocate based on the max size we determined */
+	mem_cache = kvmalloc(size, GFP_KERNEL);
+	if (!mem_cache)
+		return -ENOMEM;
+
+	/* And populate the array */
+	size = offset = depth = initial_depth = 0;
+	for (offset = 0;
+	     offset >= 0 && depth >= initial_depth;
+	     offset = fdt_next_node(fdt, offset, &depth)) {
+		const struct kho_mem *mems;
+		int nr_mems, i;
+
+		mems = fdt_getprop(fdt, offset, "mem", &len);
+		if (!mems || len & (sizeof(*mems) - 1))
+			continue;
+
+		for (i = 0, nr_mems = len / sizeof(*mems); i < nr_mems; i++) {
+			const struct kho_mem *mem = &mems[i];
+			ulong mstart = PAGE_ALIGN_DOWN(mem->addr);
+			ulong mend = PAGE_ALIGN(mem->addr + mem->len);
+			struct kho_mem cmem = {
+				.addr = mstart,
+				.len = (mend - mstart),
+			};
+
+			size = kho_mem_cache_add(fdt, mem_cache, size, &cmem);
+			if (size < 0)
+				return size;
+		}
+	}
+
+	image->kho.mem_cache.buffer = mem_cache;
+	image->kho.mem_cache.bufsz = size;
+	image->kho.mem_cache.memsz = size;
+
+	return 0;
+}
+
+int kho_fill_kimage(struct kimage *image)
+{
+	int err = 0;
+	void *dt;
+
+	mutex_lock(&kho.lock);
+
+	if (!kho.active)
+		goto out;
+
+	/* Initialize kexec_buf for mem_cache */
+	image->kho.mem_cache = (struct kexec_buf) {
+		.image = image,
+		.buffer = NULL,
+		.bufsz = 0,
+		.mem = KEXEC_BUF_MEM_UNKNOWN,
+		.memsz = 0,
+		.buf_align = SZ_64K, /* Makes it easier to map */
+		.buf_max = ULONG_MAX,
+		.top_down = true,
+	};
+
+	/*
+	 * We need to make all allocations visible here via the mem_cache so that
+	 * kho_is_destination_range() can identify overlapping regions and ensure
+	 * that no kimage (including the DT one) lands on handed over memory.
+	 *
+	 * Since we conveniently already built an array of all allocations, let's
+	 * pass that on to the target kernel so that reuse it to initialize its
+	 * memory blocks.
+	 */
+	err = kho_alloc_mem_cache(image, kho.dt);
+	if (err)
+		goto out;
+
+	err = kexec_add_buffer(&image->kho.mem_cache);
+	if (err)
+		goto out;
+
+	/*
+	 * Create a kexec copy of the DT here. We need this because lifetime may
+	 * be different between kho.dt and the kimage
+	 */
+	dt = kvmemdup(kho.dt, kho.dt_len, GFP_KERNEL);
+	if (!dt) {
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* Allocate target memory for kho dt */
+	image->kho.dt = (struct kexec_buf) {
+		.image = image,
+		.buffer = dt,
+		.bufsz = kho.dt_len,
+		.mem = KEXEC_BUF_MEM_UNKNOWN,
+		.memsz = kho.dt_len,
+		.buf_align = SZ_64K, /* Makes it easier to map */
+		.buf_max = ULONG_MAX,
+		.top_down = true,
+	};
+	err = kexec_add_buffer(&image->kho.dt);
+
+out:
+	mutex_unlock(&kho.lock);
+	return err;
+}
+
 bool kho_is_active(void)
 {
 	return kho.active;
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:35:56 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:56 +0000
Subject: [PATCH v2 06/17] kexec: Add config option for KHO
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-7-graf@amazon.com>

We have all generic code in place now to support Kexec with KHO. This
patch adds a config option that depends on architecture support to
enable KHO support.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 kernel/Kconfig.kexec | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index 2fd510256604..909ab28f1341 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -91,6 +91,19 @@ config KEXEC_JUMP
 	  Jump between original kernel and kexeced kernel and invoke
 	  code in physical address mode via KEXEC
 
+config KEXEC_KHO
+	bool "kexec handover"
+	depends on ARCH_SUPPORTS_KEXEC_KHO
+	depends on KEXEC
+	select MEMBLOCK_SCRATCH
+	select LIBFDT
+	select CMA
+	help
+	  Allow kexec to hand over state across kernels by generating and
+	  passing additional metadata to the target kernel. This is useful
+	  to keep data or state alive across the kexec. For this to work,
+	  both source and target kernels need to have this option enabled.
+
 config CRASH_DUMP
 	bool "kernel crash dumps"
 	depends on ARCH_SUPPORTS_CRASH_DUMP
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:35:57 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:57 +0000
Subject: [PATCH v2 07/17] kexec: Add documentation for KHO
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-8-graf@amazon.com>

With KHO in place, let's add documentation that describes what it is and
how to use it.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 Documentation/kho/concepts.rst   | 88 ++++++++++++++++++++++++++++++++
 Documentation/kho/index.rst      | 19 +++++++
 Documentation/kho/usage.rst      | 57 +++++++++++++++++++++
 Documentation/subsystem-apis.rst |  1 +
 4 files changed, 165 insertions(+)
 create mode 100644 Documentation/kho/concepts.rst
 create mode 100644 Documentation/kho/index.rst
 create mode 100644 Documentation/kho/usage.rst

diff --git a/Documentation/kho/concepts.rst b/Documentation/kho/concepts.rst
new file mode 100644
index 000000000000..8e4fe8c57865
--- /dev/null
+++ b/Documentation/kho/concepts.rst
@@ -0,0 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+=======================
+Kexec Handover Concepts
+=======================
+
+Kexec HandOver (KHO) is a mechanism that allows Linux to preserve state -
+arbitrary properties as well as memory locations - across kexec.
+
+It introduces multiple concepts:
+
+KHO Device Tree
+---------------
+
+Every KHO kexec carries a KHO specific flattened device tree blob that
+describes the state of the system. Device drivers can register to KHO to
+serialize their state before kexec. After KHO, device drivers can read
+the device tree and extract previous state.
+
+KHO only uses the fdt container format and libfdt library, but does not
+adhere to the same property semantics that normal device trees do: Properties
+are passed in native endianness and standardized properties like ``regs`` and
+``ranges`` do not exist, hence there are no ``#...-cells`` properties.
+
+KHO introduces a new concept to its device tree: ``mem`` properties. A
+``mem`` property can inside any subnode in the device tree. When present,
+it contains an array of physical memory ranges that the new kernel must mark
+as reserved on boot. It is recommended, but not required, to make these ranges
+as physically contiguous as possible to reduce the number of array elements ::
+
+    struct kho_mem {
+            __u64 addr;
+            __u64 len;
+    };
+
+After boot, drivers can call the kho subsystem to transfer ownership of memory
+that was reserved via a ``mem`` property to themselves to continue using memory
+from the previous execution.
+
+The KHO device tree follows the in-Linux schema requirements. Any element in
+the device tree is documented via device tree schema yamls that explain what
+data gets transferred.
+
+Mem cache
+---------
+
+The new kernel needs to know about all memory reservations, but is unable to
+parse the device tree yet in early bootup code because of memory limitations.
+To simplify the initial memory reservation flow, the old kernel passes a
+preprocessed array of physically contiguous reserved ranges to the new kernel.
+
+These reservations have to be separate from architectural memory maps and
+reservations because they differ on every kexec, while the architectural ones
+get passed directly between invocations.
+
+The less entries this cache contains, the faster the new kernel will boot.
+
+Scratch Region
+--------------
+
+To boot into kexec, we need to have a physically contiguous memory range that
+contains no handed over memory. Kexec then places the target kernel and initrd
+into that region. The new kernel exclusively uses this region for memory
+allocations before it ingests the mem cache.
+
+We guarantee that we always have such a region through the scratch region: On
+first boot, you can pass the ``kho_scratch`` kernel command line option. When
+it is set, Linux allocates a CMA region of the given size. CMA gives us the
+guarantee that no handover pages land in that region, because handover
+pages must be at a static physical memory location and CMA enforces that
+only movable pages can be located inside.
+
+After KHO kexec, we ignore the ``kho_scratch`` kernel command line option and
+instead reuse the exact same region that was originally allocated. This allows
+us to recursively execute any amount of KHO kexecs. Because we used this region
+for boot memory allocations and as target memory for kexec blobs, some parts
+of that memory region may be reserved. These reservations are irrenevant for
+the next KHO, because kexec can overwrite even the original kernel.
+
+KHO active phase
+----------------
+
+To enable user space based kexec file loader, the kernel needs to be able to
+provide the device tree that describes the previous kernel's state before
+performing the actual kexec. The process of generating that device tree is
+called serialization. When the device tree is generated, some properties
+of the system may become immutable because they are already written down
+in the device tree. That state is called the KHO active phase.
diff --git a/Documentation/kho/index.rst b/Documentation/kho/index.rst
new file mode 100644
index 000000000000..5e7eeeca8520
--- /dev/null
+++ b/Documentation/kho/index.rst
@@ -0,0 +1,19 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+========================
+Kexec Handover Subsystem
+========================
+
+.. toctree::
+   :maxdepth: 1
+
+   concepts
+   usage
+
+.. only::  subproject and html
+
+
+   Indices
+   =======
+
+   * :ref:`genindex`
diff --git a/Documentation/kho/usage.rst b/Documentation/kho/usage.rst
new file mode 100644
index 000000000000..5efa2a58f9c3
--- /dev/null
+++ b/Documentation/kho/usage.rst
@@ -0,0 +1,57 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+====================
+Kexec Handover Usage
+====================
+
+Kexec HandOver (KHO) is a mechanism that allows Linux to preserve state -
+arbitrary properties as well as memory locations - across kexec.
+
+This document expects that you are familiar with the base KHO
+:ref:`Documentation/kho/concepts.rst <concepts>`. If you have not read
+them yet, please do so now.
+
+Prerequisites
+-------------
+
+KHO is available when the ``CONFIG_KEXEC_KHO`` config option is set to y
+at compile team. Every KHO producer has its own config option that you
+need to enable if you would like to preserve their respective state across
+kexec.
+
+To use KHO, please boot the kernel with the ``kho_scratch`` command
+line parameter set to allocate a scratch region. For example
+``kho_scratch=512M`` will reserve a 512 MiB scratch region on boot.
+
+Perform a KHO kexec
+-------------------
+
+Before you can perform a KHO kexec, you need to move the system into the
+:ref:`Documentation/kho/concepts.rst <KHO active phase>` ::
+
+  $ echo 1 > /sys/kernel/kho/active
+
+After this command, the KHO device tree is available in ``/sys/kernel/kho/dt``.
+
+Next, load the target payload and kexec into it. It is important that you
+use the ``-s`` parameter to use the in-kernel kexec file loader, as user
+space kexec tooling currently has no support for KHO with the user space
+based file loader ::
+
+  # kexec -l Image --initrd=initrd -s
+  # kexec -e
+
+The new kernel will boot up and contain some of the previous kernel's state.
+
+For example, if you enabled ``CONFIG_FTRACE_KHO``, the new kernel will contain
+the old kernel's trace buffers in ``/sys/kernel/debug/tracing/trace``.
+
+Abort a KHO exec
+----------------
+
+You can move the system out of KHO active phase again by calling ::
+
+  $ echo 1 > /sys/kernel/kho/active
+
+After this command, the KHO device tree is no longer available in
+``/sys/kernel/kho/dt``.
diff --git a/Documentation/subsystem-apis.rst b/Documentation/subsystem-apis.rst
index 930dc23998a0..8207b6514d87 100644
--- a/Documentation/subsystem-apis.rst
+++ b/Documentation/subsystem-apis.rst
@@ -86,3 +86,4 @@ Storage interfaces
    misc-devices/index
    peci/index
    wmi/index
+   kho/index
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:35:58 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:58 +0000
Subject: [PATCH v2 08/17] arm64: Add KHO support
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-9-graf@amazon.com>

We now have all bits in place to support KHO kexecs. This patch adds
awareness of KHO in the kexec file as well as boot path for arm64 and
adds the respective kconfig option to the architecture so that it can
use KHO successfully.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - test bot warning fix
  - Change kconfig option to ARCH_SUPPORTS_KEXEC_KHO
  - s/kho_reserve_mem/kho_reserve_previous_mem/g
  - s/kho_reserve/kho_reserve_scratch/g
  - Remove / reduce ifdefs for kho fdt code
---
 arch/arm64/Kconfig        |  3 +++
 arch/arm64/kernel/setup.c |  2 ++
 arch/arm64/mm/init.c      |  8 ++++++
 drivers/of/fdt.c          | 39 ++++++++++++++++++++++++++++
 drivers/of/kexec.c        | 54 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 106 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..4a2fd3deaa16 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1495,6 +1495,9 @@ config ARCH_SUPPORTS_KEXEC_IMAGE_VERIFY_SIG
 config ARCH_DEFAULT_KEXEC_IMAGE_VERIFY_SIG
 	def_bool y
 
+config ARCH_SUPPORTS_KEXEC_KHO
+	def_bool y
+
 config ARCH_SUPPORTS_CRASH_DUMP
 	def_bool y
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 417a8a86b2db..9aa05b84d202 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -346,6 +346,8 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
 
 	paging_init();
 
+	kho_reserve_previous_mem();
+
 	acpi_table_upgrade();
 
 	/* Parse the ACPI tables for possible boot-time configuration */
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 74c1db8ce271..1a8fc91509af 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -358,6 +358,8 @@ void __init bootmem_init(void)
 	 */
 	arch_reserve_crashkernel();
 
+	kho_reserve_scratch();
+
 	memblock_dump_all();
 }
 
@@ -386,6 +388,12 @@ void __init mem_init(void)
 	/* this will put all unused low memory onto the freelists */
 	memblock_free_all();
 
+	/*
+	 * Now that all KHO pages are marked as reserved, let's flip them back
+	 * to normal pages with accurate refcount.
+	 */
+	kho_populate_refcount();
+
 	/*
 	 * Check boundaries twice: Some fundamental inconsistencies can be
 	 * detected at build time already.
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bf502ba8da95..f9b9a36fb722 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1006,6 +1006,42 @@ void __init early_init_dt_check_for_usable_mem_range(void)
 		memblock_add(rgn[i].base, rgn[i].size);
 }
 
+/**
+ * early_init_dt_check_kho - Decode info required for kexec handover from DT
+ */
+static void __init early_init_dt_check_kho(void)
+{
+	unsigned long node = chosen_node_offset;
+	u64 kho_start, scratch_start, scratch_size, mem_start, mem_size;
+	const __be32 *p;
+	int l;
+
+	if (!IS_ENABLED(CONFIG_KEXEC_KHO) || (long)node < 0)
+		return;
+
+	p = of_get_flat_dt_prop(node, "linux,kho-dt", &l);
+	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
+		return;
+
+	kho_start = dt_mem_next_cell(dt_root_addr_cells, &p);
+
+	p = of_get_flat_dt_prop(node, "linux,kho-scratch", &l);
+	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
+		return;
+
+	scratch_start = dt_mem_next_cell(dt_root_addr_cells, &p);
+	scratch_size = dt_mem_next_cell(dt_root_addr_cells, &p);
+
+	p = of_get_flat_dt_prop(node, "linux,kho-mem", &l);
+	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
+		return;
+
+	mem_start = dt_mem_next_cell(dt_root_addr_cells, &p);
+	mem_size = dt_mem_next_cell(dt_root_addr_cells, &p);
+
+	kho_populate(kho_start, scratch_start, scratch_size, mem_start, mem_size);
+}
+
 #ifdef CONFIG_SERIAL_EARLYCON
 
 int __init early_init_dt_scan_chosen_stdout(void)
@@ -1304,6 +1340,9 @@ void __init early_init_dt_scan_nodes(void)
 
 	/* Handle linux,usable-memory-range property */
 	early_init_dt_check_for_usable_mem_range();
+
+	/* Handle kexec handover */
+	early_init_dt_check_kho();
 }
 
 bool __init early_init_dt_scan(void *params)
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 68278340cecf..59070b09ad45 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -264,6 +264,55 @@ static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
 }
 #endif /* CONFIG_IMA_KEXEC */
 
+static int kho_add_chosen(const struct kimage *image, void *fdt, int chosen_node)
+{
+	void *dt = NULL;
+	phys_addr_t dt_mem = 0;
+	phys_addr_t dt_len = 0;
+	phys_addr_t scratch_mem = 0;
+	phys_addr_t scratch_len = 0;
+	void *mem_cache = NULL;
+	phys_addr_t mem_cache_mem = 0;
+	phys_addr_t mem_cache_len = 0;
+	int ret = 0;
+
+#ifdef CONFIG_KEXEC_KHO
+	dt = image->kho.dt.buffer;
+	dt_mem = image->kho.dt.mem;
+	dt_len = image->kho.dt.bufsz;
+
+	scratch_mem = kho_scratch_phys;
+	scratch_len = kho_scratch_len;
+
+	mem_cache = image->kho.mem_cache.buffer;
+	mem_cache_mem = image->kho.mem_cache.mem;
+	mem_cache_len = image->kho.mem_cache.bufsz;
+#endif
+
+	if (!dt || !mem_cache)
+		goto out;
+
+	pr_debug("Adding kho metadata to DT");
+
+	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-dt",
+				       dt_mem, dt_len);
+	if (ret)
+		goto out;
+
+	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-scratch",
+				       scratch_mem, scratch_len);
+	if (ret)
+		goto out;
+
+	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-mem",
+				       mem_cache_mem, mem_cache_len);
+	if (ret)
+		goto out;
+
+out:
+	return ret;
+}
+
 /*
  * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
  *
@@ -412,6 +461,11 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
 		}
 	}
 
+	/* Add kho metadata if this is a KHO image */
+	ret = kho_add_chosen(image, fdt, chosen_node);
+	if (ret)
+		goto out;
+
 	/* add bootargs */
 	if (cmdline) {
 		ret = fdt_setprop_string(fdt, chosen_node, "bootargs", cmdline);
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:36:00 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:36:00 +0000
Subject: [PATCH v2 10/17] tracing: Initialize fields before registering
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-11-graf@amazon.com>

With KHO, we need to know all event fields before we allocate an event
type for a trace event so that we can recover it based on a previous
execution context.

Before this patch, fields were only initialized after we allocated a
type id. After this patch, we try to allocate it early as well.

This patch leaves the old late initialization logic in place. The field
init code already validates whether there are any fields present, which
means it's legal to call it multiple times. This way we're sure we don't
miss any call sites.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 include/linux/trace_events.h      |  1 +
 kernel/trace/trace_events.c       | 14 +++++++++-----
 kernel/trace/trace_events_synth.c | 14 +++++++++-----
 kernel/trace/trace_events_user.c  |  4 ++++
 kernel/trace/trace_probe.c        |  4 ++++
 5 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index d68ff9b1247f..8fe8970b48e3 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -842,6 +842,7 @@ extern int trace_define_field(struct trace_event_call *call, const char *type,
 extern int trace_add_event_call(struct trace_event_call *call);
 extern int trace_remove_event_call(struct trace_event_call *call);
 extern int trace_event_get_offsets(struct trace_event_call *call);
+extern int trace_event_define_fields(struct trace_event_call *call);
 
 int ftrace_set_clr_event(struct trace_array *tr, char *buf, int set);
 int trace_set_clr_event(const char *system, const char *event, int set);
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index f29e815ca5b2..fbf8be1d2806 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -462,6 +462,11 @@ static void test_event_printk(struct trace_event_call *call)
 int trace_event_raw_init(struct trace_event_call *call)
 {
 	int id;
+	int ret;
+
+	ret = trace_event_define_fields(call);
+	if (ret)
+		return ret;
 
 	id = register_trace_event(&call->event);
 	if (!id)
@@ -2402,8 +2407,7 @@ event_subsystem_dir(struct trace_array *tr, const char *name,
 	return NULL;
 }
 
-static int
-event_define_fields(struct trace_event_call *call)
+int trace_event_define_fields(struct trace_event_call *call)
 {
 	struct list_head *head;
 	int ret = 0;
@@ -2592,7 +2596,7 @@ event_create_dir(struct eventfs_inode *parent, struct trace_event_file *file)
 
 	file->ei = ei;
 
-	ret = event_define_fields(call);
+	ret = trace_event_define_fields(call);
 	if (ret < 0) {
 		pr_warn("Could not initialize trace point events/%s\n", name);
 		return ret;
@@ -2978,7 +2982,7 @@ __trace_add_new_event(struct trace_event_call *call, struct trace_array *tr)
 	if (eventdir_initialized)
 		return event_create_dir(tr->event_dir, file);
 	else
-		return event_define_fields(call);
+		return trace_event_define_fields(call);
 }
 
 static void trace_early_triggers(struct trace_event_file *file, const char *name)
@@ -3015,7 +3019,7 @@ __trace_early_add_new_event(struct trace_event_call *call,
 	if (!file)
 		return -ENOMEM;
 
-	ret = event_define_fields(call);
+	ret = trace_event_define_fields(call);
 	if (ret)
 		return ret;
 
diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c
index 846e02c0fb59..4db41218ccf7 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -880,17 +880,21 @@ static int register_synth_event(struct synth_event *event)
 	INIT_LIST_HEAD(&call->class->fields);
 	call->event.funcs = &synth_event_funcs;
 	call->class->fields_array = synth_event_fields_array;
+	call->flags = TRACE_EVENT_FL_TRACEPOINT;
+	call->class->reg = trace_event_reg;
+	call->class->probe = trace_event_raw_event_synth;
+	call->data = event;
+	call->tp = event->tp;
+
+	ret = trace_event_define_fields(call);
+	if (ret)
+		goto out;
 
 	ret = register_trace_event(&call->event);
 	if (!ret) {
 		ret = -ENODEV;
 		goto out;
 	}
-	call->flags = TRACE_EVENT_FL_TRACEPOINT;
-	call->class->reg = trace_event_reg;
-	call->class->probe = trace_event_raw_event_synth;
-	call->data = event;
-	call->tp = event->tp;
 
 	ret = trace_add_event_call(call);
 	if (ret) {
diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
index 9365ce407426..b9837e987525 100644
--- a/kernel/trace/trace_events_user.c
+++ b/kernel/trace/trace_events_user.c
@@ -1900,6 +1900,10 @@ static int user_event_trace_register(struct user_event *user)
 {
 	int ret;
 
+	ret = trace_event_define_fields(&user->call);
+	if (ret)
+		return ret;
+
 	ret = register_trace_event(&user->call.event);
 
 	if (!ret)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 4dc74d73fc1d..da73a02246d8 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -1835,6 +1835,10 @@ int trace_probe_register_event_call(struct trace_probe *tp)
 				  trace_probe_name(tp)))
 		return -EEXIST;
 
+	ret = trace_event_define_fields(call);
+	if (ret)
+		return ret;
+
 	ret = register_trace_event(&call->event);
 	if (!ret)
 		return -ENODEV;
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:35:59 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:35:59 +0000
Subject: [PATCH v2 09/17] x86: Add KHO support
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-10-graf@amazon.com>

We now have all bits in place to support KHO kexecs. This patch adds
awareness of KHO in the kexec file as well as boot path for x86 and
adds the respective kconfig option to the architecture so that it can
use KHO successfully.

In addition, it enlightens it decompression code with KHO so that its
KASLR location finder only considers memory regions that are not already
occupied by KHO memory.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - Change kconfig option to ARCH_SUPPORTS_KEXEC_KHO
  - s/kho_reserve_mem/kho_reserve_previous_mem/g
  - s/kho_reserve/kho_reserve_scratch/g
---
 arch/x86/Kconfig                      |  3 ++
 arch/x86/boot/compressed/kaslr.c      | 55 +++++++++++++++++++++++++++
 arch/x86/include/uapi/asm/bootparam.h | 15 +++++++-
 arch/x86/kernel/e820.c                |  9 +++++
 arch/x86/kernel/kexec-bzimage64.c     | 39 +++++++++++++++++++
 arch/x86/kernel/setup.c               | 46 ++++++++++++++++++++++
 arch/x86/mm/init_32.c                 |  7 ++++
 arch/x86/mm/init_64.c                 |  7 ++++
 8 files changed, 180 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3762f41bb092..9aa31b3dcebc 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2094,6 +2094,9 @@ config ARCH_SUPPORTS_KEXEC_BZIMAGE_VERIFY_SIG
 config ARCH_SUPPORTS_KEXEC_JUMP
 	def_bool y
 
+config ARCH_SUPPORTS_KEXEC_KHO
+	def_bool y
+
 config ARCH_SUPPORTS_CRASH_DUMP
 	def_bool X86_64 || (X86_32 && HIGHMEM)
 
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index dec961c6d16a..93ea292e4c18 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -29,6 +29,7 @@
 #include <linux/uts.h>
 #include <linux/utsname.h>
 #include <linux/ctype.h>
+#include <uapi/linux/kexec.h>
 #include <generated/utsversion.h>
 #include <generated/utsrelease.h>
 
@@ -472,6 +473,60 @@ static bool mem_avoid_overlap(struct mem_vector *img,
 			}
 		}
 
+#ifdef CONFIG_KEXEC_KHO
+		if (ptr->type == SETUP_KEXEC_KHO) {
+			struct kho_data *kho = (struct kho_data *)ptr->data;
+			struct kho_mem *mems = (void *)kho->mem_cache_addr;
+			int nr_mems = kho->mem_cache_size / sizeof(*mems);
+			int i;
+
+			/* Avoid the mem cache */
+			avoid = (struct mem_vector) {
+				.start = kho->mem_cache_addr,
+				.size = kho->mem_cache_size,
+			};
+
+			if (mem_overlaps(img, &avoid) && (avoid.start < earliest)) {
+				*overlap = avoid;
+				earliest = overlap->start;
+				is_overlapping = true;
+			}
+
+			/* And the KHO DT */
+			avoid = (struct mem_vector) {
+				.start = kho->dt_addr,
+				.size = kho->dt_size,
+			};
+
+			if (mem_overlaps(img, &avoid) && (avoid.start < earliest)) {
+				*overlap = avoid;
+				earliest = overlap->start;
+				is_overlapping = true;
+			}
+
+			/* As well as any other KHO memory reservations */
+			for (i = 0; i < nr_mems; i++) {
+				avoid = (struct mem_vector) {
+					.start = mems[i].addr,
+					.size = mems[i].len,
+				};
+
+				/*
+				 * This mem starts after our current break.
+				 * The array is sorted, so we're done.
+				 */
+				if (avoid.start >= earliest)
+					break;
+
+				if (mem_overlaps(img, &avoid)) {
+					*overlap = avoid;
+					earliest = overlap->start;
+					is_overlapping = true;
+				}
+			}
+		}
+#endif
+
 		ptr = (struct setup_data *)(unsigned long)ptr->next;
 	}
 
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 01d19fc22346..013af38a9673 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -13,7 +13,8 @@
 #define SETUP_CC_BLOB			7
 #define SETUP_IMA			8
 #define SETUP_RNG_SEED			9
-#define SETUP_ENUM_MAX			SETUP_RNG_SEED
+#define SETUP_KEXEC_KHO		10
+#define SETUP_ENUM_MAX			SETUP_KEXEC_KHO
 
 #define SETUP_INDIRECT			(1<<31)
 #define SETUP_TYPE_MAX			(SETUP_ENUM_MAX | SETUP_INDIRECT)
@@ -181,6 +182,18 @@ struct ima_setup_data {
 	__u64 size;
 } __attribute__((packed));
 
+/*
+ * Locations of kexec handover metadata
+ */
+struct kho_data {
+	__u64 dt_addr;
+	__u64 dt_size;
+	__u64 scratch_addr;
+	__u64 scratch_size;
+	__u64 mem_cache_addr;
+	__u64 mem_cache_size;
+} __attribute__((packed));
+
 /* The so-called "zeropage" */
 struct boot_params {
 	struct screen_info screen_info;			/* 0x000 */
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index fb8cf953380d..c891b83f5b1c 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1341,6 +1341,15 @@ void __init e820__memblock_setup(void)
 			continue;
 
 		memblock_add(entry->addr, entry->size);
+
+		/*
+		 * At this point with KHO we only allocate from scratch memory
+		 * and only from memory below ISA_END_ADDRESS. Make sure that
+		 * when we add memory for the eligible range, we add it as
+		 * scratch memory so that we can resize the memblocks array.
+		 */
+		if (is_kho_boot() && (end <= ISA_END_ADDRESS))
+			memblock_mark_scratch(entry->addr, end);
 	}
 
 	/* Throw away partial pages: */
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index a61c12c01270..0cb8d0650a02 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -15,6 +15,7 @@
 #include <linux/slab.h>
 #include <linux/kexec.h>
 #include <linux/kernel.h>
+#include <linux/libfdt.h>
 #include <linux/mm.h>
 #include <linux/efi.h>
 #include <linux/random.h>
@@ -233,6 +234,33 @@ setup_ima_state(const struct kimage *image, struct boot_params *params,
 #endif /* CONFIG_IMA_KEXEC */
 }
 
+static void setup_kho(const struct kimage *image, struct boot_params *params,
+		       unsigned long params_load_addr,
+		       unsigned int setup_data_offset)
+{
+#ifdef CONFIG_KEXEC_KHO
+	struct setup_data *sd = (void *)params + setup_data_offset;
+	struct kho_data *kho = (void *)sd + sizeof(*sd);
+
+	sd->type = SETUP_KEXEC_KHO;
+	sd->len = sizeof(struct kho_data);
+
+	/* Only add if we have all KHO images in place */
+	if (!image->kho.dt.buffer || !image->kho.mem_cache.buffer)
+		return;
+
+	/* Add setup data */
+	kho->dt_addr = image->kho.dt.mem;
+	kho->dt_size = image->kho.dt.bufsz;
+	kho->scratch_addr = kho_scratch_phys;
+	kho->scratch_size = kho_scratch_len;
+	kho->mem_cache_addr = image->kho.mem_cache.mem;
+	kho->mem_cache_size = image->kho.mem_cache.bufsz;
+	sd->next = params->hdr.setup_data;
+	params->hdr.setup_data = params_load_addr + setup_data_offset;
+#endif /* CONFIG_KEXEC_KHO */
+}
+
 static int
 setup_boot_parameters(struct kimage *image, struct boot_params *params,
 		      unsigned long params_load_addr,
@@ -305,6 +333,13 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
 				     sizeof(struct ima_setup_data);
 	}
 
+	if (IS_ENABLED(CONFIG_KEXEC_KHO)) {
+		/* Setup space to store preservation metadata */
+		setup_kho(image, params, params_load_addr, setup_data_offset);
+		setup_data_offset += sizeof(struct setup_data) +
+				     sizeof(struct kho_data);
+	}
+
 	/* Setup RNG seed */
 	setup_rng_seed(params, params_load_addr, setup_data_offset);
 
@@ -470,6 +505,10 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
 		kbuf.bufsz += sizeof(struct setup_data) +
 			      sizeof(struct ima_setup_data);
 
+	if (IS_ENABLED(CONFIG_KEXEC_KHO))
+		kbuf.bufsz += sizeof(struct setup_data) +
+			      sizeof(struct kho_data);
+
 	params = kzalloc(kbuf.bufsz, GFP_KERNEL);
 	if (!params)
 		return ERR_PTR(-ENOMEM);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1526747bedf2..bd21f9a601a2 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -382,6 +382,29 @@ int __init ima_get_kexec_buffer(void **addr, size_t *size)
 }
 #endif
 
+static void __init add_kho(u64 phys_addr, u32 data_len)
+{
+#ifdef CONFIG_KEXEC_KHO
+	struct kho_data *kho;
+	u64 addr = phys_addr + sizeof(struct setup_data);
+	u64 size = data_len - sizeof(struct setup_data);
+
+	kho = early_memremap(addr, size);
+	if (!kho) {
+		pr_warn("setup: failed to memremap kho data (0x%llx, 0x%llx)\n",
+			 addr, size);
+		return;
+	}
+
+	kho_populate(kho->dt_addr, kho->scratch_addr, kho->scratch_size,
+		     kho->mem_cache_addr, kho->mem_cache_size);
+
+	early_memunmap(kho, size);
+#else
+	pr_warn("Passed KHO data, but CONFIG_KEXEC_KHO not set. Ignoring.\n");
+#endif
+}
+
 static void __init parse_setup_data(void)
 {
 	struct setup_data *data;
@@ -410,6 +433,9 @@ static void __init parse_setup_data(void)
 		case SETUP_IMA:
 			add_early_ima_buffer(pa_data);
 			break;
+		case SETUP_KEXEC_KHO:
+			add_kho(pa_data, data_len);
+			break;
 		case SETUP_RNG_SEED:
 			data = early_memremap(pa_data, data_len);
 			add_bootloader_randomness(data->data, data->len);
@@ -989,8 +1015,26 @@ void __init setup_arch(char **cmdline_p)
 	cleanup_highmap();
 
 	memblock_set_current_limit(ISA_END_ADDRESS);
+
 	e820__memblock_setup();
 
+	/*
+	 * We can resize memblocks at this point, let's dump all KHO
+	 * reservations in and switch from scratch-only to normal allocations
+	 */
+	kho_reserve_previous_mem();
+
+	/* Allocations now skip scratch mem, return low 1M to the pool */
+	if (is_kho_boot()) {
+		u64 i;
+		phys_addr_t base, end;
+
+		__for_each_mem_range(i, &memblock.memory, NULL, NUMA_NO_NODE,
+				     MEMBLOCK_SCRATCH, &base, &end, NULL)
+			if (end <= ISA_END_ADDRESS)
+				memblock_clear_scratch(base, end - base);
+	}
+
 	/*
 	 * Needs to run after memblock setup because it needs the physical
 	 * memory size.
@@ -1106,6 +1150,8 @@ void __init setup_arch(char **cmdline_p)
 	 */
 	arch_reserve_crashkernel();
 
+	kho_reserve_scratch();
+
 	memblock_find_dma_reserve();
 
 	if (!early_xdbc_setup_hardware())
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index b63403d7179d..6c3810afed04 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -20,6 +20,7 @@
 #include <linux/smp.h>
 #include <linux/init.h>
 #include <linux/highmem.h>
+#include <linux/kexec.h>
 #include <linux/pagemap.h>
 #include <linux/pci.h>
 #include <linux/pfn.h>
@@ -738,6 +739,12 @@ void __init mem_init(void)
 	after_bootmem = 1;
 	x86_init.hyper.init_after_bootmem();
 
+	/*
+	 * Now that all KHO pages are marked as reserved, let's flip them back
+	 * to normal pages with accurate refcount.
+	 */
+	kho_populate_refcount();
+
 	/*
 	 * Check boundaries twice: Some fundamental inconsistencies can
 	 * be detected at build time already.
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index a190aae8ceaf..3ce1a4767610 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -20,6 +20,7 @@
 #include <linux/smp.h>
 #include <linux/init.h>
 #include <linux/initrd.h>
+#include <linux/kexec.h>
 #include <linux/pagemap.h>
 #include <linux/memblock.h>
 #include <linux/proc_fs.h>
@@ -1339,6 +1340,12 @@ void __init mem_init(void)
 	after_bootmem = 1;
 	x86_init.hyper.init_after_bootmem();
 
+	/*
+	 * Now that all KHO pages are marked as reserved, let's flip them back
+	 * to normal pages with accurate refcount.
+	 */
+	kho_populate_refcount();
+
 	/*
 	 * Must be done after boot memory is put on freelist, because here we
 	 * might set fields in deferred struct pages that have not yet been
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:36:01 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:36:01 +0000
Subject: [PATCH v2 11/17] tracing: Introduce kho serialization
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222193607.15474-12-graf@amazon.com>

We want to be able to transfer ftrace state from one kernel to the next.
To start off with, let's establish all the boiler plate to get a write
hook when KHO wants to serialize and fill out basic data.

Follow-up patches will fill in serialization of ring buffers and events.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - Remove ifdefs
---
 kernel/trace/trace.c | 47 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 199df497db07..6ec31879b4eb 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -32,6 +32,7 @@
 #include <linux/percpu.h>
 #include <linux/splice.h>
 #include <linux/kdebug.h>
+#include <linux/kexec.h>
 #include <linux/string.h>
 #include <linux/mount.h>
 #include <linux/rwsem.h>
@@ -866,6 +867,8 @@ static struct tracer		*trace_types __read_mostly;
  */
 DEFINE_MUTEX(trace_types_lock);
 
+static bool trace_in_kho;
+
 /*
  * serialize the access of the ring buffer
  *
@@ -10560,12 +10563,56 @@ void __init early_trace_init(void)
 	init_events();
 }
 
+static int trace_kho_notifier(struct notifier_block *self,
+			      unsigned long cmd,
+			      void *v)
+{
+	const char compatible[] = "ftrace-v1";
+	void *fdt = v;
+	int err = 0;
+
+	switch (cmd) {
+	case KEXEC_KHO_ABORT:
+		if (trace_in_kho)
+			mutex_unlock(&trace_types_lock);
+		trace_in_kho = false;
+		return NOTIFY_DONE;
+	case KEXEC_KHO_DUMP:
+		/* Handled below */
+		break;
+	default:
+		return NOTIFY_BAD;
+	}
+
+	if (unlikely(tracing_disabled))
+		return NOTIFY_DONE;
+
+	err |= fdt_begin_node(fdt, "ftrace");
+	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= fdt_end_node(fdt);
+
+	if (!err) {
+		/* Hold all future allocations */
+		mutex_lock(&trace_types_lock);
+		trace_in_kho = true;
+	}
+
+	return err ? NOTIFY_BAD : NOTIFY_DONE;
+}
+
+static struct notifier_block trace_kho_nb = {
+	.notifier_call = trace_kho_notifier,
+};
+
 void __init trace_init(void)
 {
 	trace_event_init();
 
 	if (boot_instance_index)
 		enable_instances();
+
+	if (IS_ENABLED(CONFIG_FTRACE_KHO))
+		register_kho_notifier(&trace_kho_nb);
 }
 
 __init static void clear_boot_tracer(void)
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:33 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:33 +0000
Subject: [PATCH v2 06/17] kexec: Add config option for KHO
In-Reply-To: <20231222193607.15474-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
Message-ID: <20231222195144.24532-1-graf@amazon.com>

We have all generic code in place now to support Kexec with KHO. This
patch adds a config option that depends on architecture support to
enable KHO support.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 kernel/Kconfig.kexec | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index 2fd510256604..909ab28f1341 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -91,6 +91,19 @@ config KEXEC_JUMP
 	  Jump between original kernel and kexeced kernel and invoke
 	  code in physical address mode via KEXEC
 
+config KEXEC_KHO
+	bool "kexec handover"
+	depends on ARCH_SUPPORTS_KEXEC_KHO
+	depends on KEXEC
+	select MEMBLOCK_SCRATCH
+	select LIBFDT
+	select CMA
+	help
+	  Allow kexec to hand over state across kernels by generating and
+	  passing additional metadata to the target kernel. This is useful
+	  to keep data or state alive across the kexec. For this to work,
+	  both source and target kernels need to have this option enabled.
+
 config CRASH_DUMP
 	bool "kernel crash dumps"
 	depends on ARCH_SUPPORTS_CRASH_DUMP
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:34 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:34 +0000
Subject: [PATCH v2 07/17] kexec: Add documentation for KHO
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-2-graf@amazon.com>

With KHO in place, let's add documentation that describes what it is and
how to use it.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 Documentation/kho/concepts.rst   | 88 ++++++++++++++++++++++++++++++++
 Documentation/kho/index.rst      | 19 +++++++
 Documentation/kho/usage.rst      | 57 +++++++++++++++++++++
 Documentation/subsystem-apis.rst |  1 +
 4 files changed, 165 insertions(+)
 create mode 100644 Documentation/kho/concepts.rst
 create mode 100644 Documentation/kho/index.rst
 create mode 100644 Documentation/kho/usage.rst

diff --git a/Documentation/kho/concepts.rst b/Documentation/kho/concepts.rst
new file mode 100644
index 000000000000..8e4fe8c57865
--- /dev/null
+++ b/Documentation/kho/concepts.rst
@@ -0,0 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+=======================
+Kexec Handover Concepts
+=======================
+
+Kexec HandOver (KHO) is a mechanism that allows Linux to preserve state -
+arbitrary properties as well as memory locations - across kexec.
+
+It introduces multiple concepts:
+
+KHO Device Tree
+---------------
+
+Every KHO kexec carries a KHO specific flattened device tree blob that
+describes the state of the system. Device drivers can register to KHO to
+serialize their state before kexec. After KHO, device drivers can read
+the device tree and extract previous state.
+
+KHO only uses the fdt container format and libfdt library, but does not
+adhere to the same property semantics that normal device trees do: Properties
+are passed in native endianness and standardized properties like ``regs`` and
+``ranges`` do not exist, hence there are no ``#...-cells`` properties.
+
+KHO introduces a new concept to its device tree: ``mem`` properties. A
+``mem`` property can inside any subnode in the device tree. When present,
+it contains an array of physical memory ranges that the new kernel must mark
+as reserved on boot. It is recommended, but not required, to make these ranges
+as physically contiguous as possible to reduce the number of array elements ::
+
+    struct kho_mem {
+            __u64 addr;
+            __u64 len;
+    };
+
+After boot, drivers can call the kho subsystem to transfer ownership of memory
+that was reserved via a ``mem`` property to themselves to continue using memory
+from the previous execution.
+
+The KHO device tree follows the in-Linux schema requirements. Any element in
+the device tree is documented via device tree schema yamls that explain what
+data gets transferred.
+
+Mem cache
+---------
+
+The new kernel needs to know about all memory reservations, but is unable to
+parse the device tree yet in early bootup code because of memory limitations.
+To simplify the initial memory reservation flow, the old kernel passes a
+preprocessed array of physically contiguous reserved ranges to the new kernel.
+
+These reservations have to be separate from architectural memory maps and
+reservations because they differ on every kexec, while the architectural ones
+get passed directly between invocations.
+
+The less entries this cache contains, the faster the new kernel will boot.
+
+Scratch Region
+--------------
+
+To boot into kexec, we need to have a physically contiguous memory range that
+contains no handed over memory. Kexec then places the target kernel and initrd
+into that region. The new kernel exclusively uses this region for memory
+allocations before it ingests the mem cache.
+
+We guarantee that we always have such a region through the scratch region: On
+first boot, you can pass the ``kho_scratch`` kernel command line option. When
+it is set, Linux allocates a CMA region of the given size. CMA gives us the
+guarantee that no handover pages land in that region, because handover
+pages must be at a static physical memory location and CMA enforces that
+only movable pages can be located inside.
+
+After KHO kexec, we ignore the ``kho_scratch`` kernel command line option and
+instead reuse the exact same region that was originally allocated. This allows
+us to recursively execute any amount of KHO kexecs. Because we used this region
+for boot memory allocations and as target memory for kexec blobs, some parts
+of that memory region may be reserved. These reservations are irrenevant for
+the next KHO, because kexec can overwrite even the original kernel.
+
+KHO active phase
+----------------
+
+To enable user space based kexec file loader, the kernel needs to be able to
+provide the device tree that describes the previous kernel's state before
+performing the actual kexec. The process of generating that device tree is
+called serialization. When the device tree is generated, some properties
+of the system may become immutable because they are already written down
+in the device tree. That state is called the KHO active phase.
diff --git a/Documentation/kho/index.rst b/Documentation/kho/index.rst
new file mode 100644
index 000000000000..5e7eeeca8520
--- /dev/null
+++ b/Documentation/kho/index.rst
@@ -0,0 +1,19 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+========================
+Kexec Handover Subsystem
+========================
+
+.. toctree::
+   :maxdepth: 1
+
+   concepts
+   usage
+
+.. only::  subproject and html
+
+
+   Indices
+   =======
+
+   * :ref:`genindex`
diff --git a/Documentation/kho/usage.rst b/Documentation/kho/usage.rst
new file mode 100644
index 000000000000..5efa2a58f9c3
--- /dev/null
+++ b/Documentation/kho/usage.rst
@@ -0,0 +1,57 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+====================
+Kexec Handover Usage
+====================
+
+Kexec HandOver (KHO) is a mechanism that allows Linux to preserve state -
+arbitrary properties as well as memory locations - across kexec.
+
+This document expects that you are familiar with the base KHO
+:ref:`Documentation/kho/concepts.rst <concepts>`. If you have not read
+them yet, please do so now.
+
+Prerequisites
+-------------
+
+KHO is available when the ``CONFIG_KEXEC_KHO`` config option is set to y
+at compile team. Every KHO producer has its own config option that you
+need to enable if you would like to preserve their respective state across
+kexec.
+
+To use KHO, please boot the kernel with the ``kho_scratch`` command
+line parameter set to allocate a scratch region. For example
+``kho_scratch=512M`` will reserve a 512 MiB scratch region on boot.
+
+Perform a KHO kexec
+-------------------
+
+Before you can perform a KHO kexec, you need to move the system into the
+:ref:`Documentation/kho/concepts.rst <KHO active phase>` ::
+
+  $ echo 1 > /sys/kernel/kho/active
+
+After this command, the KHO device tree is available in ``/sys/kernel/kho/dt``.
+
+Next, load the target payload and kexec into it. It is important that you
+use the ``-s`` parameter to use the in-kernel kexec file loader, as user
+space kexec tooling currently has no support for KHO with the user space
+based file loader ::
+
+  # kexec -l Image --initrd=initrd -s
+  # kexec -e
+
+The new kernel will boot up and contain some of the previous kernel's state.
+
+For example, if you enabled ``CONFIG_FTRACE_KHO``, the new kernel will contain
+the old kernel's trace buffers in ``/sys/kernel/debug/tracing/trace``.
+
+Abort a KHO exec
+----------------
+
+You can move the system out of KHO active phase again by calling ::
+
+  $ echo 1 > /sys/kernel/kho/active
+
+After this command, the KHO device tree is no longer available in
+``/sys/kernel/kho/dt``.
diff --git a/Documentation/subsystem-apis.rst b/Documentation/subsystem-apis.rst
index 930dc23998a0..8207b6514d87 100644
--- a/Documentation/subsystem-apis.rst
+++ b/Documentation/subsystem-apis.rst
@@ -86,3 +86,4 @@ Storage interfaces
    misc-devices/index
    peci/index
    wmi/index
+   kho/index
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:35 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:35 +0000
Subject: [PATCH v2 08/17] arm64: Add KHO support
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-3-graf@amazon.com>

We now have all bits in place to support KHO kexecs. This patch adds
awareness of KHO in the kexec file as well as boot path for arm64 and
adds the respective kconfig option to the architecture so that it can
use KHO successfully.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - test bot warning fix
  - Change kconfig option to ARCH_SUPPORTS_KEXEC_KHO
  - s/kho_reserve_mem/kho_reserve_previous_mem/g
  - s/kho_reserve/kho_reserve_scratch/g
  - Remove / reduce ifdefs for kho fdt code
---
 arch/arm64/Kconfig        |  3 +++
 arch/arm64/kernel/setup.c |  2 ++
 arch/arm64/mm/init.c      |  8 ++++++
 drivers/of/fdt.c          | 39 ++++++++++++++++++++++++++++
 drivers/of/kexec.c        | 54 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 106 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..4a2fd3deaa16 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1495,6 +1495,9 @@ config ARCH_SUPPORTS_KEXEC_IMAGE_VERIFY_SIG
 config ARCH_DEFAULT_KEXEC_IMAGE_VERIFY_SIG
 	def_bool y
 
+config ARCH_SUPPORTS_KEXEC_KHO
+	def_bool y
+
 config ARCH_SUPPORTS_CRASH_DUMP
 	def_bool y
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 417a8a86b2db..9aa05b84d202 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -346,6 +346,8 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
 
 	paging_init();
 
+	kho_reserve_previous_mem();
+
 	acpi_table_upgrade();
 
 	/* Parse the ACPI tables for possible boot-time configuration */
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 74c1db8ce271..1a8fc91509af 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -358,6 +358,8 @@ void __init bootmem_init(void)
 	 */
 	arch_reserve_crashkernel();
 
+	kho_reserve_scratch();
+
 	memblock_dump_all();
 }
 
@@ -386,6 +388,12 @@ void __init mem_init(void)
 	/* this will put all unused low memory onto the freelists */
 	memblock_free_all();
 
+	/*
+	 * Now that all KHO pages are marked as reserved, let's flip them back
+	 * to normal pages with accurate refcount.
+	 */
+	kho_populate_refcount();
+
 	/*
 	 * Check boundaries twice: Some fundamental inconsistencies can be
 	 * detected at build time already.
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bf502ba8da95..f9b9a36fb722 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1006,6 +1006,42 @@ void __init early_init_dt_check_for_usable_mem_range(void)
 		memblock_add(rgn[i].base, rgn[i].size);
 }
 
+/**
+ * early_init_dt_check_kho - Decode info required for kexec handover from DT
+ */
+static void __init early_init_dt_check_kho(void)
+{
+	unsigned long node = chosen_node_offset;
+	u64 kho_start, scratch_start, scratch_size, mem_start, mem_size;
+	const __be32 *p;
+	int l;
+
+	if (!IS_ENABLED(CONFIG_KEXEC_KHO) || (long)node < 0)
+		return;
+
+	p = of_get_flat_dt_prop(node, "linux,kho-dt", &l);
+	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
+		return;
+
+	kho_start = dt_mem_next_cell(dt_root_addr_cells, &p);
+
+	p = of_get_flat_dt_prop(node, "linux,kho-scratch", &l);
+	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
+		return;
+
+	scratch_start = dt_mem_next_cell(dt_root_addr_cells, &p);
+	scratch_size = dt_mem_next_cell(dt_root_addr_cells, &p);
+
+	p = of_get_flat_dt_prop(node, "linux,kho-mem", &l);
+	if (l != (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32))
+		return;
+
+	mem_start = dt_mem_next_cell(dt_root_addr_cells, &p);
+	mem_size = dt_mem_next_cell(dt_root_addr_cells, &p);
+
+	kho_populate(kho_start, scratch_start, scratch_size, mem_start, mem_size);
+}
+
 #ifdef CONFIG_SERIAL_EARLYCON
 
 int __init early_init_dt_scan_chosen_stdout(void)
@@ -1304,6 +1340,9 @@ void __init early_init_dt_scan_nodes(void)
 
 	/* Handle linux,usable-memory-range property */
 	early_init_dt_check_for_usable_mem_range();
+
+	/* Handle kexec handover */
+	early_init_dt_check_kho();
 }
 
 bool __init early_init_dt_scan(void *params)
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 68278340cecf..59070b09ad45 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -264,6 +264,55 @@ static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
 }
 #endif /* CONFIG_IMA_KEXEC */
 
+static int kho_add_chosen(const struct kimage *image, void *fdt, int chosen_node)
+{
+	void *dt = NULL;
+	phys_addr_t dt_mem = 0;
+	phys_addr_t dt_len = 0;
+	phys_addr_t scratch_mem = 0;
+	phys_addr_t scratch_len = 0;
+	void *mem_cache = NULL;
+	phys_addr_t mem_cache_mem = 0;
+	phys_addr_t mem_cache_len = 0;
+	int ret = 0;
+
+#ifdef CONFIG_KEXEC_KHO
+	dt = image->kho.dt.buffer;
+	dt_mem = image->kho.dt.mem;
+	dt_len = image->kho.dt.bufsz;
+
+	scratch_mem = kho_scratch_phys;
+	scratch_len = kho_scratch_len;
+
+	mem_cache = image->kho.mem_cache.buffer;
+	mem_cache_mem = image->kho.mem_cache.mem;
+	mem_cache_len = image->kho.mem_cache.bufsz;
+#endif
+
+	if (!dt || !mem_cache)
+		goto out;
+
+	pr_debug("Adding kho metadata to DT");
+
+	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-dt",
+				       dt_mem, dt_len);
+	if (ret)
+		goto out;
+
+	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-scratch",
+				       scratch_mem, scratch_len);
+	if (ret)
+		goto out;
+
+	ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-mem",
+				       mem_cache_mem, mem_cache_len);
+	if (ret)
+		goto out;
+
+out:
+	return ret;
+}
+
 /*
  * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
  *
@@ -412,6 +461,11 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
 		}
 	}
 
+	/* Add kho metadata if this is a KHO image */
+	ret = kho_add_chosen(image, fdt, chosen_node);
+	if (ret)
+		goto out;
+
 	/* add bootargs */
 	if (cmdline) {
 		ret = fdt_setprop_string(fdt, chosen_node, "bootargs", cmdline);
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:37 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:37 +0000
Subject: [PATCH v2 10/17] tracing: Initialize fields before registering
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-5-graf@amazon.com>

With KHO, we need to know all event fields before we allocate an event
type for a trace event so that we can recover it based on a previous
execution context.

Before this patch, fields were only initialized after we allocated a
type id. After this patch, we try to allocate it early as well.

This patch leaves the old late initialization logic in place. The field
init code already validates whether there are any fields present, which
means it's legal to call it multiple times. This way we're sure we don't
miss any call sites.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 include/linux/trace_events.h      |  1 +
 kernel/trace/trace_events.c       | 14 +++++++++-----
 kernel/trace/trace_events_synth.c | 14 +++++++++-----
 kernel/trace/trace_events_user.c  |  4 ++++
 kernel/trace/trace_probe.c        |  4 ++++
 5 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index d68ff9b1247f..8fe8970b48e3 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -842,6 +842,7 @@ extern int trace_define_field(struct trace_event_call *call, const char *type,
 extern int trace_add_event_call(struct trace_event_call *call);
 extern int trace_remove_event_call(struct trace_event_call *call);
 extern int trace_event_get_offsets(struct trace_event_call *call);
+extern int trace_event_define_fields(struct trace_event_call *call);
 
 int ftrace_set_clr_event(struct trace_array *tr, char *buf, int set);
 int trace_set_clr_event(const char *system, const char *event, int set);
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index f29e815ca5b2..fbf8be1d2806 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -462,6 +462,11 @@ static void test_event_printk(struct trace_event_call *call)
 int trace_event_raw_init(struct trace_event_call *call)
 {
 	int id;
+	int ret;
+
+	ret = trace_event_define_fields(call);
+	if (ret)
+		return ret;
 
 	id = register_trace_event(&call->event);
 	if (!id)
@@ -2402,8 +2407,7 @@ event_subsystem_dir(struct trace_array *tr, const char *name,
 	return NULL;
 }
 
-static int
-event_define_fields(struct trace_event_call *call)
+int trace_event_define_fields(struct trace_event_call *call)
 {
 	struct list_head *head;
 	int ret = 0;
@@ -2592,7 +2596,7 @@ event_create_dir(struct eventfs_inode *parent, struct trace_event_file *file)
 
 	file->ei = ei;
 
-	ret = event_define_fields(call);
+	ret = trace_event_define_fields(call);
 	if (ret < 0) {
 		pr_warn("Could not initialize trace point events/%s\n", name);
 		return ret;
@@ -2978,7 +2982,7 @@ __trace_add_new_event(struct trace_event_call *call, struct trace_array *tr)
 	if (eventdir_initialized)
 		return event_create_dir(tr->event_dir, file);
 	else
-		return event_define_fields(call);
+		return trace_event_define_fields(call);
 }
 
 static void trace_early_triggers(struct trace_event_file *file, const char *name)
@@ -3015,7 +3019,7 @@ __trace_early_add_new_event(struct trace_event_call *call,
 	if (!file)
 		return -ENOMEM;
 
-	ret = event_define_fields(call);
+	ret = trace_event_define_fields(call);
 	if (ret)
 		return ret;
 
diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c
index 846e02c0fb59..4db41218ccf7 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -880,17 +880,21 @@ static int register_synth_event(struct synth_event *event)
 	INIT_LIST_HEAD(&call->class->fields);
 	call->event.funcs = &synth_event_funcs;
 	call->class->fields_array = synth_event_fields_array;
+	call->flags = TRACE_EVENT_FL_TRACEPOINT;
+	call->class->reg = trace_event_reg;
+	call->class->probe = trace_event_raw_event_synth;
+	call->data = event;
+	call->tp = event->tp;
+
+	ret = trace_event_define_fields(call);
+	if (ret)
+		goto out;
 
 	ret = register_trace_event(&call->event);
 	if (!ret) {
 		ret = -ENODEV;
 		goto out;
 	}
-	call->flags = TRACE_EVENT_FL_TRACEPOINT;
-	call->class->reg = trace_event_reg;
-	call->class->probe = trace_event_raw_event_synth;
-	call->data = event;
-	call->tp = event->tp;
 
 	ret = trace_add_event_call(call);
 	if (ret) {
diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
index 9365ce407426..b9837e987525 100644
--- a/kernel/trace/trace_events_user.c
+++ b/kernel/trace/trace_events_user.c
@@ -1900,6 +1900,10 @@ static int user_event_trace_register(struct user_event *user)
 {
 	int ret;
 
+	ret = trace_event_define_fields(&user->call);
+	if (ret)
+		return ret;
+
 	ret = register_trace_event(&user->call.event);
 
 	if (!ret)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 4dc74d73fc1d..da73a02246d8 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -1835,6 +1835,10 @@ int trace_probe_register_event_call(struct trace_probe *tp)
 				  trace_probe_name(tp)))
 		return -EEXIST;
 
+	ret = trace_event_define_fields(call);
+	if (ret)
+		return ret;
+
 	ret = register_trace_event(&call->event);
 	if (!ret)
 		return -ENODEV;
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:36 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:36 +0000
Subject: [PATCH v2 09/17] x86: Add KHO support
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-4-graf@amazon.com>

We now have all bits in place to support KHO kexecs. This patch adds
awareness of KHO in the kexec file as well as boot path for x86 and
adds the respective kconfig option to the architecture so that it can
use KHO successfully.

In addition, it enlightens it decompression code with KHO so that its
KASLR location finder only considers memory regions that are not already
occupied by KHO memory.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - Change kconfig option to ARCH_SUPPORTS_KEXEC_KHO
  - s/kho_reserve_mem/kho_reserve_previous_mem/g
  - s/kho_reserve/kho_reserve_scratch/g
---
 arch/x86/Kconfig                      |  3 ++
 arch/x86/boot/compressed/kaslr.c      | 55 +++++++++++++++++++++++++++
 arch/x86/include/uapi/asm/bootparam.h | 15 +++++++-
 arch/x86/kernel/e820.c                |  9 +++++
 arch/x86/kernel/kexec-bzimage64.c     | 39 +++++++++++++++++++
 arch/x86/kernel/setup.c               | 46 ++++++++++++++++++++++
 arch/x86/mm/init_32.c                 |  7 ++++
 arch/x86/mm/init_64.c                 |  7 ++++
 8 files changed, 180 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3762f41bb092..9aa31b3dcebc 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2094,6 +2094,9 @@ config ARCH_SUPPORTS_KEXEC_BZIMAGE_VERIFY_SIG
 config ARCH_SUPPORTS_KEXEC_JUMP
 	def_bool y
 
+config ARCH_SUPPORTS_KEXEC_KHO
+	def_bool y
+
 config ARCH_SUPPORTS_CRASH_DUMP
 	def_bool X86_64 || (X86_32 && HIGHMEM)
 
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index dec961c6d16a..93ea292e4c18 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -29,6 +29,7 @@
 #include <linux/uts.h>
 #include <linux/utsname.h>
 #include <linux/ctype.h>
+#include <uapi/linux/kexec.h>
 #include <generated/utsversion.h>
 #include <generated/utsrelease.h>
 
@@ -472,6 +473,60 @@ static bool mem_avoid_overlap(struct mem_vector *img,
 			}
 		}
 
+#ifdef CONFIG_KEXEC_KHO
+		if (ptr->type == SETUP_KEXEC_KHO) {
+			struct kho_data *kho = (struct kho_data *)ptr->data;
+			struct kho_mem *mems = (void *)kho->mem_cache_addr;
+			int nr_mems = kho->mem_cache_size / sizeof(*mems);
+			int i;
+
+			/* Avoid the mem cache */
+			avoid = (struct mem_vector) {
+				.start = kho->mem_cache_addr,
+				.size = kho->mem_cache_size,
+			};
+
+			if (mem_overlaps(img, &avoid) && (avoid.start < earliest)) {
+				*overlap = avoid;
+				earliest = overlap->start;
+				is_overlapping = true;
+			}
+
+			/* And the KHO DT */
+			avoid = (struct mem_vector) {
+				.start = kho->dt_addr,
+				.size = kho->dt_size,
+			};
+
+			if (mem_overlaps(img, &avoid) && (avoid.start < earliest)) {
+				*overlap = avoid;
+				earliest = overlap->start;
+				is_overlapping = true;
+			}
+
+			/* As well as any other KHO memory reservations */
+			for (i = 0; i < nr_mems; i++) {
+				avoid = (struct mem_vector) {
+					.start = mems[i].addr,
+					.size = mems[i].len,
+				};
+
+				/*
+				 * This mem starts after our current break.
+				 * The array is sorted, so we're done.
+				 */
+				if (avoid.start >= earliest)
+					break;
+
+				if (mem_overlaps(img, &avoid)) {
+					*overlap = avoid;
+					earliest = overlap->start;
+					is_overlapping = true;
+				}
+			}
+		}
+#endif
+
 		ptr = (struct setup_data *)(unsigned long)ptr->next;
 	}
 
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 01d19fc22346..013af38a9673 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -13,7 +13,8 @@
 #define SETUP_CC_BLOB			7
 #define SETUP_IMA			8
 #define SETUP_RNG_SEED			9
-#define SETUP_ENUM_MAX			SETUP_RNG_SEED
+#define SETUP_KEXEC_KHO		10
+#define SETUP_ENUM_MAX			SETUP_KEXEC_KHO
 
 #define SETUP_INDIRECT			(1<<31)
 #define SETUP_TYPE_MAX			(SETUP_ENUM_MAX | SETUP_INDIRECT)
@@ -181,6 +182,18 @@ struct ima_setup_data {
 	__u64 size;
 } __attribute__((packed));
 
+/*
+ * Locations of kexec handover metadata
+ */
+struct kho_data {
+	__u64 dt_addr;
+	__u64 dt_size;
+	__u64 scratch_addr;
+	__u64 scratch_size;
+	__u64 mem_cache_addr;
+	__u64 mem_cache_size;
+} __attribute__((packed));
+
 /* The so-called "zeropage" */
 struct boot_params {
 	struct screen_info screen_info;			/* 0x000 */
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index fb8cf953380d..c891b83f5b1c 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1341,6 +1341,15 @@ void __init e820__memblock_setup(void)
 			continue;
 
 		memblock_add(entry->addr, entry->size);
+
+		/*
+		 * At this point with KHO we only allocate from scratch memory
+		 * and only from memory below ISA_END_ADDRESS. Make sure that
+		 * when we add memory for the eligible range, we add it as
+		 * scratch memory so that we can resize the memblocks array.
+		 */
+		if (is_kho_boot() && (end <= ISA_END_ADDRESS))
+			memblock_mark_scratch(entry->addr, end);
 	}
 
 	/* Throw away partial pages: */
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index a61c12c01270..0cb8d0650a02 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -15,6 +15,7 @@
 #include <linux/slab.h>
 #include <linux/kexec.h>
 #include <linux/kernel.h>
+#include <linux/libfdt.h>
 #include <linux/mm.h>
 #include <linux/efi.h>
 #include <linux/random.h>
@@ -233,6 +234,33 @@ setup_ima_state(const struct kimage *image, struct boot_params *params,
 #endif /* CONFIG_IMA_KEXEC */
 }
 
+static void setup_kho(const struct kimage *image, struct boot_params *params,
+		       unsigned long params_load_addr,
+		       unsigned int setup_data_offset)
+{
+#ifdef CONFIG_KEXEC_KHO
+	struct setup_data *sd = (void *)params + setup_data_offset;
+	struct kho_data *kho = (void *)sd + sizeof(*sd);
+
+	sd->type = SETUP_KEXEC_KHO;
+	sd->len = sizeof(struct kho_data);
+
+	/* Only add if we have all KHO images in place */
+	if (!image->kho.dt.buffer || !image->kho.mem_cache.buffer)
+		return;
+
+	/* Add setup data */
+	kho->dt_addr = image->kho.dt.mem;
+	kho->dt_size = image->kho.dt.bufsz;
+	kho->scratch_addr = kho_scratch_phys;
+	kho->scratch_size = kho_scratch_len;
+	kho->mem_cache_addr = image->kho.mem_cache.mem;
+	kho->mem_cache_size = image->kho.mem_cache.bufsz;
+	sd->next = params->hdr.setup_data;
+	params->hdr.setup_data = params_load_addr + setup_data_offset;
+#endif /* CONFIG_KEXEC_KHO */
+}
+
 static int
 setup_boot_parameters(struct kimage *image, struct boot_params *params,
 		      unsigned long params_load_addr,
@@ -305,6 +333,13 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
 				     sizeof(struct ima_setup_data);
 	}
 
+	if (IS_ENABLED(CONFIG_KEXEC_KHO)) {
+		/* Setup space to store preservation metadata */
+		setup_kho(image, params, params_load_addr, setup_data_offset);
+		setup_data_offset += sizeof(struct setup_data) +
+				     sizeof(struct kho_data);
+	}
+
 	/* Setup RNG seed */
 	setup_rng_seed(params, params_load_addr, setup_data_offset);
 
@@ -470,6 +505,10 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
 		kbuf.bufsz += sizeof(struct setup_data) +
 			      sizeof(struct ima_setup_data);
 
+	if (IS_ENABLED(CONFIG_KEXEC_KHO))
+		kbuf.bufsz += sizeof(struct setup_data) +
+			      sizeof(struct kho_data);
+
 	params = kzalloc(kbuf.bufsz, GFP_KERNEL);
 	if (!params)
 		return ERR_PTR(-ENOMEM);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1526747bedf2..bd21f9a601a2 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -382,6 +382,29 @@ int __init ima_get_kexec_buffer(void **addr, size_t *size)
 }
 #endif
 
+static void __init add_kho(u64 phys_addr, u32 data_len)
+{
+#ifdef CONFIG_KEXEC_KHO
+	struct kho_data *kho;
+	u64 addr = phys_addr + sizeof(struct setup_data);
+	u64 size = data_len - sizeof(struct setup_data);
+
+	kho = early_memremap(addr, size);
+	if (!kho) {
+		pr_warn("setup: failed to memremap kho data (0x%llx, 0x%llx)\n",
+			 addr, size);
+		return;
+	}
+
+	kho_populate(kho->dt_addr, kho->scratch_addr, kho->scratch_size,
+		     kho->mem_cache_addr, kho->mem_cache_size);
+
+	early_memunmap(kho, size);
+#else
+	pr_warn("Passed KHO data, but CONFIG_KEXEC_KHO not set. Ignoring.\n");
+#endif
+}
+
 static void __init parse_setup_data(void)
 {
 	struct setup_data *data;
@@ -410,6 +433,9 @@ static void __init parse_setup_data(void)
 		case SETUP_IMA:
 			add_early_ima_buffer(pa_data);
 			break;
+		case SETUP_KEXEC_KHO:
+			add_kho(pa_data, data_len);
+			break;
 		case SETUP_RNG_SEED:
 			data = early_memremap(pa_data, data_len);
 			add_bootloader_randomness(data->data, data->len);
@@ -989,8 +1015,26 @@ void __init setup_arch(char **cmdline_p)
 	cleanup_highmap();
 
 	memblock_set_current_limit(ISA_END_ADDRESS);
+
 	e820__memblock_setup();
 
+	/*
+	 * We can resize memblocks at this point, let's dump all KHO
+	 * reservations in and switch from scratch-only to normal allocations
+	 */
+	kho_reserve_previous_mem();
+
+	/* Allocations now skip scratch mem, return low 1M to the pool */
+	if (is_kho_boot()) {
+		u64 i;
+		phys_addr_t base, end;
+
+		__for_each_mem_range(i, &memblock.memory, NULL, NUMA_NO_NODE,
+				     MEMBLOCK_SCRATCH, &base, &end, NULL)
+			if (end <= ISA_END_ADDRESS)
+				memblock_clear_scratch(base, end - base);
+	}
+
 	/*
 	 * Needs to run after memblock setup because it needs the physical
 	 * memory size.
@@ -1106,6 +1150,8 @@ void __init setup_arch(char **cmdline_p)
 	 */
 	arch_reserve_crashkernel();
 
+	kho_reserve_scratch();
+
 	memblock_find_dma_reserve();
 
 	if (!early_xdbc_setup_hardware())
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index b63403d7179d..6c3810afed04 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -20,6 +20,7 @@
 #include <linux/smp.h>
 #include <linux/init.h>
 #include <linux/highmem.h>
+#include <linux/kexec.h>
 #include <linux/pagemap.h>
 #include <linux/pci.h>
 #include <linux/pfn.h>
@@ -738,6 +739,12 @@ void __init mem_init(void)
 	after_bootmem = 1;
 	x86_init.hyper.init_after_bootmem();
 
+	/*
+	 * Now that all KHO pages are marked as reserved, let's flip them back
+	 * to normal pages with accurate refcount.
+	 */
+	kho_populate_refcount();
+
 	/*
 	 * Check boundaries twice: Some fundamental inconsistencies can
 	 * be detected at build time already.
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index a190aae8ceaf..3ce1a4767610 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -20,6 +20,7 @@
 #include <linux/smp.h>
 #include <linux/init.h>
 #include <linux/initrd.h>
+#include <linux/kexec.h>
 #include <linux/pagemap.h>
 #include <linux/memblock.h>
 #include <linux/proc_fs.h>
@@ -1339,6 +1340,12 @@ void __init mem_init(void)
 	after_bootmem = 1;
 	x86_init.hyper.init_after_bootmem();
 
+	/*
+	 * Now that all KHO pages are marked as reserved, let's flip them back
+	 * to normal pages with accurate refcount.
+	 */
+	kho_populate_refcount();
+
 	/*
 	 * Must be done after boot memory is put on freelist, because here we
 	 * might set fields in deferred struct pages that have not yet been
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:38 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:38 +0000
Subject: [PATCH v2 11/17] tracing: Introduce kho serialization
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-6-graf@amazon.com>

We want to be able to transfer ftrace state from one kernel to the next.
To start off with, let's establish all the boiler plate to get a write
hook when KHO wants to serialize and fill out basic data.

Follow-up patches will fill in serialization of ring buffers and events.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - Remove ifdefs
---
 kernel/trace/trace.c | 47 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 199df497db07..6ec31879b4eb 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -32,6 +32,7 @@
 #include <linux/percpu.h>
 #include <linux/splice.h>
 #include <linux/kdebug.h>
+#include <linux/kexec.h>
 #include <linux/string.h>
 #include <linux/mount.h>
 #include <linux/rwsem.h>
@@ -866,6 +867,8 @@ static struct tracer		*trace_types __read_mostly;
  */
 DEFINE_MUTEX(trace_types_lock);
 
+static bool trace_in_kho;
+
 /*
  * serialize the access of the ring buffer
  *
@@ -10560,12 +10563,56 @@ void __init early_trace_init(void)
 	init_events();
 }
 
+static int trace_kho_notifier(struct notifier_block *self,
+			      unsigned long cmd,
+			      void *v)
+{
+	const char compatible[] = "ftrace-v1";
+	void *fdt = v;
+	int err = 0;
+
+	switch (cmd) {
+	case KEXEC_KHO_ABORT:
+		if (trace_in_kho)
+			mutex_unlock(&trace_types_lock);
+		trace_in_kho = false;
+		return NOTIFY_DONE;
+	case KEXEC_KHO_DUMP:
+		/* Handled below */
+		break;
+	default:
+		return NOTIFY_BAD;
+	}
+
+	if (unlikely(tracing_disabled))
+		return NOTIFY_DONE;
+
+	err |= fdt_begin_node(fdt, "ftrace");
+	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= fdt_end_node(fdt);
+
+	if (!err) {
+		/* Hold all future allocations */
+		mutex_lock(&trace_types_lock);
+		trace_in_kho = true;
+	}
+
+	return err ? NOTIFY_BAD : NOTIFY_DONE;
+}
+
+static struct notifier_block trace_kho_nb = {
+	.notifier_call = trace_kho_notifier,
+};
+
 void __init trace_init(void)
 {
 	trace_event_init();
 
 	if (boot_instance_index)
 		enable_instances();
+
+	if (IS_ENABLED(CONFIG_FTRACE_KHO))
+		register_kho_notifier(&trace_kho_nb);
 }
 
 __init static void clear_boot_tracer(void)
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:39 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:39 +0000
Subject: [PATCH v2 12/17] tracing: Add kho serialization of trace buffers
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-7-graf@amazon.com>

When we do a kexec handover, we want to preserve previous ftrace data
into the new kernel. At the point when we write out the handover data,
ftrace may still be running and recording new events and we want to
capture all of those too.

To allow the new kernel to revive all trace data up to reboot, we store
all locations of trace buffers as well as their linked list metadata. We
can then later reuse the linked list to reconstruct the head pointer.

This patch implements the write-out logic for trace buffers.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - Leave the node generation code that needs to know the name in
    trace.c so that ring buffers can stay anonymous
---
 include/linux/ring_buffer.h |  2 +
 kernel/trace/ring_buffer.c  | 76 +++++++++++++++++++++++++++++++++++++
 kernel/trace/trace.c        | 16 ++++++++
 3 files changed, 94 insertions(+)

diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index 782e14f62201..1c5eb33f0cb5 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -211,4 +211,6 @@ int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node);
 #define trace_rb_cpu_prepare	NULL
 #endif
 
+int ring_buffer_kho_write(void *fdt, struct trace_buffer *buffer);
+
 #endif /* _LINUX_RING_BUFFER_H */
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 83eab547f1d1..971af7ee35da 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -20,6 +20,7 @@
 #include <linux/percpu.h>
 #include <linux/mutex.h>
 #include <linux/delay.h>
+#include <linux/kexec.h>
 #include <linux/slab.h>
 #include <linux/init.h>
 #include <linux/hash.h>
@@ -5853,6 +5854,81 @@ int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node)
 	return 0;
 }
 
+#ifdef CONFIG_FTRACE_KHO
+static int rb_kho_write_cpu(void *fdt, struct trace_buffer *buffer, int cpu)
+{
+	int i = 0;
+	int err = 0;
+	struct list_head *tmp;
+	const char compatible[] = "ftrace,cpu-v1";
+	char name[] = "cpuffffffff";
+	int nr_pages;
+	struct ring_buffer_per_cpu *cpu_buffer;
+	bool first_loop = true;
+	struct kho_mem *mem;
+	uint64_t mem_len;
+
+	if (!cpumask_test_cpu(cpu, buffer->cpumask))
+		return 0;
+
+	cpu_buffer = buffer->buffers[cpu];
+
+	nr_pages = cpu_buffer->nr_pages;
+	mem_len = sizeof(*mem) * nr_pages * 2;
+	mem = vmalloc(mem_len);
+
+	snprintf(name, sizeof(name), "cpu%x", cpu);
+
+	err |= fdt_begin_node(fdt, name);
+	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= fdt_property(fdt, "cpu", &cpu, sizeof(cpu));
+
+	for (tmp = rb_list_head(cpu_buffer->pages);
+	     tmp != rb_list_head(cpu_buffer->pages) || first_loop;
+	     tmp = rb_list_head(tmp->next), first_loop = false) {
+		struct buffer_page *bpage = (struct buffer_page *)tmp;
+
+		/* Ring is larger than it should be? */
+		if (i >= (nr_pages * 2)) {
+			pr_err("ftrace ring has more pages than nr_pages (%d / %d)", i, nr_pages);
+			err = -EINVAL;
+			break;
+		}
+
+		/* First describe the bpage */
+		mem[i++] = (struct kho_mem) {
+			.addr = __pa(bpage),
+			.len = sizeof(*bpage)
+		};
+
+		/* Then the data page */
+		mem[i++] = (struct kho_mem) {
+			.addr = __pa(bpage->page),
+			.len = PAGE_SIZE
+		};
+	}
+
+	err |= fdt_property(fdt, "mem", mem, mem_len);
+	err |= fdt_end_node(fdt);
+
+	vfree(mem);
+	return err;
+}
+
+int ring_buffer_kho_write(void *fdt, struct trace_buffer *buffer)
+{
+	int err, i;
+
+	for (i = 0; i < buffer->cpus; i++) {
+		err = rb_kho_write_cpu(fdt, buffer, i);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+#endif
+
 #ifdef CONFIG_RING_BUFFER_STARTUP_TEST
 /*
  * This is a basic integrity check of the ring buffer.
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 6ec31879b4eb..2ccea4c1965b 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -10563,6 +10563,21 @@ void __init early_trace_init(void)
 	init_events();
 }
 
+static int trace_kho_write_trace_array(void *fdt, struct trace_array *tr)
+{
+	const char *name = tr->name ? tr->name : "global_trace";
+	const char compatible[] = "ftrace,array-v1";
+	int err = 0;
+
+	err |= fdt_begin_node(fdt, name);
+	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= fdt_property(fdt, "trace_flags", &tr->trace_flags, sizeof(tr->trace_flags));
+	err |= ring_buffer_kho_write(fdt, tr->array_buffer.buffer);
+	err |= fdt_end_node(fdt);
+
+	return err;
+}
+
 static int trace_kho_notifier(struct notifier_block *self,
 			      unsigned long cmd,
 			      void *v)
@@ -10589,6 +10604,7 @@ static int trace_kho_notifier(struct notifier_block *self,
 
 	err |= fdt_begin_node(fdt, "ftrace");
 	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= trace_kho_write_trace_array(fdt, &global_trace);
 	err |= fdt_end_node(fdt);
 
 	if (!err) {
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:40 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:40 +0000
Subject: [PATCH v2 13/17] tracing: Recover trace buffers from kexec handover
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-8-graf@amazon.com>

When kexec handover is in place, we now know the location of all
previous buffers for ftrace rings. With this patch applied, ftrace
reassembles any new trace buffer that carries the same name as a
previous one with the same data pages that the previous buffer had.

That way, a buffer that we had in place before kexec becomes readable
after kexec again as soon as it gets initialized with the same name.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - Move from names to fdt offsets. That way, trace.c can find the trace
    array offset and then the ring buffer code only needs to read out
    its per-CPU data. That way it can stay oblivient to its name.
  - Make kho_get_fdt() const
  - Remove ifdefs
---
 include/linux/ring_buffer.h |  15 ++--
 kernel/trace/ring_buffer.c  | 171 ++++++++++++++++++++++++++++++++++--
 kernel/trace/trace.c        |  32 ++++++-
 3 files changed, 206 insertions(+), 12 deletions(-)

diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index 1c5eb33f0cb5..f6d6ce441890 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -84,20 +84,23 @@ void ring_buffer_discard_commit(struct trace_buffer *buffer,
 /*
  * size is in bytes for each per CPU buffer.
  */
-struct trace_buffer *
-__ring_buffer_alloc(unsigned long size, unsigned flags, struct lock_class_key *key);
+struct trace_buffer *__ring_buffer_alloc(unsigned long size, unsigned flags,
+					 struct lock_class_key *key,
+					 int tr_off);
 
 /*
  * Because the ring buffer is generic, if other users of the ring buffer get
  * traced by ftrace, it can produce lockdep warnings. We need to keep each
  * ring buffer's lock class separate.
  */
-#define ring_buffer_alloc(size, flags)			\
-({							\
-	static struct lock_class_key __key;		\
-	__ring_buffer_alloc((size), (flags), &__key);	\
+#define ring_buffer_alloc_kho(size, flags, tr_off)		\
+({								\
+	static struct lock_class_key __key;			\
+	__ring_buffer_alloc((size), (flags), &__key, tr_off);	\
 })
 
+#define ring_buffer_alloc(size, flags) ring_buffer_alloc_kho(size, flags, 0)
+
 int ring_buffer_wait(struct trace_buffer *buffer, int cpu, int full);
 __poll_t ring_buffer_poll_wait(struct trace_buffer *buffer, int cpu,
 			  struct file *filp, poll_table *poll_table, int full);
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 971af7ee35da..4c62a66068a7 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -558,6 +558,7 @@ struct trace_buffer {
 
 	struct rb_irq_work		irq_work;
 	bool				time_stamp_abs;
+	int				tr_off;
 };
 
 struct ring_buffer_iter {
@@ -574,6 +575,15 @@ struct ring_buffer_iter {
 	int				missed_events;
 };
 
+struct rb_kho_cpu {
+	const struct kho_mem *mem;
+	uint32_t nr_mems;
+};
+
+static int rb_kho_replace_buffers(struct ring_buffer_per_cpu *cpu_buffer,
+				     struct rb_kho_cpu *kho);
+static int rb_kho_read_cpu(int tr_off, int cpu, struct rb_kho_cpu *kho);
+
 #ifdef RB_TIME_32
 
 /*
@@ -1762,12 +1772,15 @@ static void rb_free_cpu_buffer(struct ring_buffer_per_cpu *cpu_buffer)
  * drop data when the tail hits the head.
  */
 struct trace_buffer *__ring_buffer_alloc(unsigned long size, unsigned flags,
-					struct lock_class_key *key)
+					 struct lock_class_key *key,
+					 int tr_off)
 {
+	int cpu = raw_smp_processor_id();
+	struct rb_kho_cpu kho = {};
 	struct trace_buffer *buffer;
+	bool use_kho = false;
 	long nr_pages;
 	int bsize;
-	int cpu;
 	int ret;
 
 	/* keep it in its own cache line */
@@ -1780,9 +1793,16 @@ struct trace_buffer *__ring_buffer_alloc(unsigned long size, unsigned flags,
 		goto fail_free_buffer;
 
 	nr_pages = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
+	if (!rb_kho_read_cpu(tr_off, cpu, &kho) && kho.nr_mems > 4) {
+		nr_pages = kho.nr_mems / 2;
+		use_kho = true;
+		pr_debug("Using kho on CPU [%03d]", cpu);
+	}
+
 	buffer->flags = flags;
 	buffer->clock = trace_clock_local;
 	buffer->reader_lock_key = key;
+	buffer->tr_off = tr_off;
 
 	init_irq_work(&buffer->irq_work.work, rb_wake_up_waiters);
 	init_waitqueue_head(&buffer->irq_work.waiters);
@@ -1799,12 +1819,14 @@ struct trace_buffer *__ring_buffer_alloc(unsigned long size, unsigned flags,
 	if (!buffer->buffers)
 		goto fail_free_cpumask;
 
-	cpu = raw_smp_processor_id();
 	cpumask_set_cpu(cpu, buffer->cpumask);
 	buffer->buffers[cpu] = rb_allocate_cpu_buffer(buffer, nr_pages, cpu);
 	if (!buffer->buffers[cpu])
 		goto fail_free_buffers;
 
+	if (use_kho && rb_kho_replace_buffers(buffer->buffers[cpu], &kho))
+		pr_warn("Could not revive all previous trace data");
+
 	ret = cpuhp_state_add_instance(CPUHP_TRACE_RB_PREPARE, &buffer->node);
 	if (ret < 0)
 		goto fail_free_buffers;
@@ -5818,7 +5840,9 @@ EXPORT_SYMBOL_GPL(ring_buffer_read_page);
  */
 int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node)
 {
+	struct rb_kho_cpu kho = {};
 	struct trace_buffer *buffer;
+	bool use_kho = false;
 	long nr_pages_same;
 	int cpu_i;
 	unsigned long nr_pages;
@@ -5842,6 +5866,12 @@ int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node)
 	/* allocate minimum pages, user can later expand it */
 	if (!nr_pages_same)
 		nr_pages = 2;
+
+	if (!rb_kho_read_cpu(buffer->tr_off, cpu, &kho) && kho.nr_mems > 4) {
+		nr_pages = kho.nr_mems / 2;
+		use_kho = true;
+	}
+
 	buffer->buffers[cpu] =
 		rb_allocate_cpu_buffer(buffer, nr_pages, cpu);
 	if (!buffer->buffers[cpu]) {
@@ -5849,13 +5879,143 @@ int trace_rb_cpu_prepare(unsigned int cpu, struct hlist_node *node)
 		     cpu);
 		return -ENOMEM;
 	}
+
+	if (use_kho && rb_kho_replace_buffers(buffer->buffers[cpu], &kho))
+		pr_warn("Could not revive all previous trace data");
+
 	smp_wmb();
 	cpumask_set_cpu(cpu, buffer->cpumask);
 	return 0;
 }
 
-#ifdef CONFIG_FTRACE_KHO
-static int rb_kho_write_cpu(void *fdt, struct trace_buffer *buffer, int cpu)
+static int rb_kho_replace_buffers(struct ring_buffer_per_cpu *cpu_buffer,
+				     struct rb_kho_cpu *kho)
+{
+	bool first_loop = true;
+	struct list_head *tmp;
+	int err = 0;
+	int i = 0;
+
+	if (!IS_ENABLED(CONFIG_FTRACE_KHO))
+		return -EINVAL;
+
+	if (kho->nr_mems != cpu_buffer->nr_pages * 2)
+		return -EINVAL;
+
+	for (tmp = rb_list_head(cpu_buffer->pages);
+	     tmp != rb_list_head(cpu_buffer->pages) || first_loop;
+	     tmp = rb_list_head(tmp->next), first_loop = false) {
+		struct buffer_page *bpage = (struct buffer_page *)tmp;
+		const struct kho_mem *mem_bpage = &kho->mem[i++];
+		const struct kho_mem *mem_page = &kho->mem[i++];
+		const uint64_t rb_page_head = 1;
+		struct buffer_page *old_bpage;
+		void *old_page;
+
+		old_bpage = __va(mem_bpage->addr);
+		if (!bpage)
+			goto out;
+
+		if ((ulong)old_bpage->list.next & rb_page_head) {
+			struct list_head *new_lhead;
+			struct buffer_page *new_head;
+
+			new_lhead = rb_list_head(bpage->list.next);
+			new_head = (struct buffer_page *)new_lhead;
+
+			/* Assume the buffer is completely full */
+			cpu_buffer->tail_page = bpage;
+			cpu_buffer->commit_page = bpage;
+			/* Set the head pointers to what they were before */
+			cpu_buffer->head_page->list.prev->next = (struct list_head *)
+				((ulong)cpu_buffer->head_page->list.prev->next & ~rb_page_head);
+			cpu_buffer->head_page = new_head;
+			bpage->list.next = (struct list_head *)((ulong)new_lhead | rb_page_head);
+		}
+
+		if (rb_page_entries(old_bpage) || rb_page_write(old_bpage)) {
+			/*
+			 * We want to recycle the pre-kho page, it contains
+			 * trace data. To do so, we unreserve it and swap the
+			 * current data page with the pre-kho one
+			 */
+			old_page = kho_claim_mem(mem_page);
+
+			/* Recycle the old page, it contains data */
+			free_page((ulong)bpage->page);
+			bpage->page = old_page;
+
+			bpage->write = old_bpage->write;
+			bpage->entries = old_bpage->entries;
+			bpage->real_end = old_bpage->real_end;
+
+			local_inc(&cpu_buffer->pages_touched);
+		} else {
+			kho_return_mem(mem_page);
+		}
+
+		kho_return_mem(mem_bpage);
+	}
+
+out:
+	return err;
+}
+
+static int rb_kho_read_cpu(int tr_off, int cpu, struct rb_kho_cpu *kho)
+{
+	const void *fdt = kho_get_fdt();
+	int mem_len;
+	int err = 0;
+	char *path;
+	int off;
+
+	if (!IS_ENABLED(CONFIG_FTRACE_KHO))
+		return -EINVAL;
+
+	if (!tr_off || !fdt || !kho)
+		return -EINVAL;
+
+	path = kasprintf(GFP_KERNEL, "cpu%x", cpu);
+	if (!path)
+		return -ENOMEM;
+
+	pr_debug("Trying to revive trace cpu '%s'", path);
+
+	off = fdt_subnode_offset(fdt, tr_off, path);
+	if (off < 0) {
+		pr_debug("Could not find '%s' in DT", path);
+		err = -ENOENT;
+		goto out;
+	}
+
+	err = fdt_node_check_compatible(fdt, off, "ftrace,cpu-v1");
+	if (err) {
+		pr_warn("Node '%s' has invalid compatible", path);
+		err = -EINVAL;
+		goto out;
+	}
+
+	kho->mem = fdt_getprop(fdt, off, "mem", &mem_len);
+	if (!kho->mem) {
+		pr_warn("Node '%s' has invalid mem property", path);
+		err = -EINVAL;
+		goto out;
+	}
+
+	kho->nr_mems = mem_len / sizeof(*kho->mem);
+
+	/* Should follow "bpage 0, page 0, bpage 1, page 1, ..." pattern */
+	if ((kho->nr_mems & 1)) {
+		err = -EINVAL;
+		goto out;
+	}
+
+out:
+	kfree(path);
+	return err;
+}
+
+static int __maybe_unused rb_kho_write_cpu(void *fdt, struct trace_buffer *buffer, int cpu)
 {
 	int i = 0;
 	int err = 0;
@@ -5915,6 +6075,7 @@ static int rb_kho_write_cpu(void *fdt, struct trace_buffer *buffer, int cpu)
 	return err;
 }
 
+#ifdef CONFIG_FTRACE_KHO
 int ring_buffer_kho_write(void *fdt, struct trace_buffer *buffer)
 {
 	int err, i;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2ccea4c1965b..94e30dfacfd1 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -9348,16 +9348,46 @@ static struct dentry *trace_instance_dir;
 static void
 init_tracer_tracefs(struct trace_array *tr, struct dentry *d_tracer);
 
+static int trace_kho_off_tr(struct trace_array *tr)
+{
+	const char *name = tr->name ? tr->name : "global_trace";
+	const void *fdt = kho_get_fdt();
+	char *path;
+	int off;
+
+	if (!IS_ENABLED(CONFIG_FTRACE_KHO))
+		return 0;
+
+	if (!fdt)
+		return 0;
+
+	path = kasprintf(GFP_KERNEL, "/ftrace/%s", name);
+	if (!path)
+		return -ENOMEM;
+
+	pr_debug("Trying to revive trace buffer '%s'", path);
+
+	off = fdt_path_offset(fdt, path);
+	if (off < 0) {
+		pr_debug("Could not find '%s' in DT", path);
+		off = 0;
+	}
+
+	kfree(path);
+	return off;
+}
+
 static int
 allocate_trace_buffer(struct trace_array *tr, struct array_buffer *buf, int size)
 {
+	int tr_off = trace_kho_off_tr(tr);
 	enum ring_buffer_flags rb_flags;
 
 	rb_flags = tr->trace_flags & TRACE_ITER_OVERWRITE ? RB_FL_OVERWRITE : 0;
 
 	buf->tr = tr;
 
-	buf->buffer = ring_buffer_alloc(size, rb_flags);
+	buf->buffer = ring_buffer_alloc_kho(size, rb_flags, tr_off);
 	if (!buf->buffer)
 		return -ENOMEM;
 
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:41 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:41 +0000
Subject: [PATCH v2 14/17] tracing: Add kho serialization of trace events
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-9-graf@amazon.com>

Events and thus their parsing handle in ftrace have dynamic IDs that get
assigned whenever the event is added to the system. If we want to parse
trace events after kexec, we need to link event IDs back to the original
trace event that existed before we kexec'ed.

There are broadly 2 paths we could take for that:

  1) Save full event description across KHO, restore after kexec,
     merge identical trace events into a single identifier.
  2) Recover the ID of post-kexec added events so they get the same
     ID after kexec that they had before kexec

This patch implements the second option. It's simpler and thus less
intrusive. However, it means we can not fully parse affected events
when the kernel removes or modifies trace events across a kho kexec.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - Leave anything that requires a name in trace.c to keep buffers
    unnamed entities
  - Put events as array into a property, use fingerprint instead of
    names to identify them
  - Reduce footprint without CONFIG_FTRACE_KHO
---
 kernel/trace/trace.c        |  1 +
 kernel/trace/trace_output.c | 89 +++++++++++++++++++++++++++++++++++++
 kernel/trace/trace_output.h |  5 +++
 3 files changed, 95 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 94e30dfacfd1..b9ce8cf24d02 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -10634,6 +10634,7 @@ static int trace_kho_notifier(struct notifier_block *self,
 
 	err |= fdt_begin_node(fdt, "ftrace");
 	err |= fdt_property(fdt, "compatible", compatible, sizeof(compatible));
+	err |= trace_kho_write_events(fdt);
 	err |= trace_kho_write_trace_array(fdt, &global_trace);
 	err |= fdt_end_node(fdt);
 
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 3e7fa44dc2b2..7d8815352e20 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -12,6 +12,8 @@
 #include <linux/sched/clock.h>
 #include <linux/sched/mm.h>
 #include <linux/idr.h>
+#include <linux/kexec.h>
+#include <linux/crc32.h>
 
 #include "trace_output.h"
 
@@ -669,6 +671,93 @@ int trace_print_lat_context(struct trace_iterator *iter)
 	return !trace_seq_has_overflowed(s);
 }
 
+/**
+ * event2fp - Return fingerprint of an event
+ * @event: The event to fingerprint
+ *
+ * For KHO, we need to match events before and after kexec to recover its type
+ * id. This function returns a hash that combines an event's name, and all of
+ * its fields' lengths.
+ */
+static u32 event2fp(struct trace_event *event)
+{
+	struct ftrace_event_field *field;
+	struct trace_event_call *call;
+	struct list_head *head;
+	const char *name;
+	u32 crc32 = ~0;
+
+	/* Low type numbers are static, nothing to checksum */
+	if (event->type && event->type < __TRACE_LAST_TYPE)
+		return event->type;
+
+	call = container_of(event, struct trace_event_call, event);
+	name = trace_event_name(call);
+	if (name)
+		crc32 = crc32_le(crc32, name, strlen(name));
+
+	head = trace_get_fields(call);
+	list_for_each_entry(field, head, link)
+		crc32 = crc32_le(crc32, (char *)&field->size, sizeof(field->size));
+
+	return crc32;
+}
+
+struct trace_event_map {
+	u32 crc32;
+	u32 type;
+};
+
+static int __maybe_unused _trace_kho_write_events(void *fdt)
+{
+	struct trace_event_call *call;
+	int count = __TRACE_LAST_TYPE - 1;
+	struct trace_event_map *map;
+	int err = 0;
+	int i;
+
+	down_read(&trace_event_sem);
+	/* Allocate an array that we can place all maps into */
+	list_for_each_entry(call, &ftrace_events, list)
+		count++;
+
+	map = vmalloc(count * sizeof(*map));
+	if (!map)
+		return -ENOMEM;
+
+	/* Then fill the array with all crc32 values */
+	count = 0;
+	for (i = 1; i < __TRACE_LAST_TYPE; i++)
+		map[count++] = (struct trace_event_map) {
+			.crc32 = count,
+			.type = count,
+		};
+
+	list_for_each_entry(call, &ftrace_events, list) {
+		struct trace_event *event = &call->event;
+
+		map[count++] = (struct trace_event_map) {
+			.crc32 = event2fp(event),
+			.type = event->type,
+		};
+	}
+	up_read(&trace_event_sem);
+
+	/* And finally write it into a DT variable */
+	err |= fdt_property(fdt, "events", map, count * sizeof(*map));
+
+	vfree(map);
+	return err;
+}
+
+#ifdef CONFIG_FTRACE_KHO
+int trace_kho_write_events(void *fdt)
+{
+	return _trace_kho_write_events(fdt);
+}
+#endif
+
+
 /**
  * ftrace_find_event - find a registered event
  * @type: the type of event to look for
diff --git a/kernel/trace/trace_output.h b/kernel/trace/trace_output.h
index dca40f1f1da4..07481f295436 100644
--- a/kernel/trace/trace_output.h
+++ b/kernel/trace/trace_output.h
@@ -25,6 +25,11 @@ extern enum print_line_t print_event_fields(struct trace_iterator *iter,
 extern void trace_event_read_lock(void);
 extern void trace_event_read_unlock(void);
 extern struct trace_event *ftrace_find_event(int type);
+#ifdef CONFIG_FTRACE_KHO
+extern int trace_kho_write_events(void *fdt);
+#else
+static inline int trace_kho_write_events(void *fdt) { return -EINVAL; }
+#endif
 
 extern enum print_line_t trace_nop_print(struct trace_iterator *iter,
 					 int flags, struct trace_event *event);
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:42 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:42 +0000
Subject: [PATCH v2 15/17] tracing: Recover trace events from kexec handover
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-10-graf@amazon.com>

This patch implements all logic necessary to match a new trace event
that we add against preserved trace events from kho. If we find a match,
we give the new trace event the old event's identifier. That way, trace
read-outs are able to make sense of buffer contents again because the
parsing code for events looks at the same identifiers.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - make kho_get_fdt() const
  - Get events as array from a property, use fingerprint instead of
    names to identify events
  - Remove ifdefs
---
 kernel/trace/trace_output.c | 158 +++++++++++++++++++++++++++++++++++-
 1 file changed, 156 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 7d8815352e20..937002a204e1 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -24,6 +24,8 @@ DECLARE_RWSEM(trace_event_sem);
 
 static struct hlist_head event_hash[EVENT_HASHSIZE] __read_mostly;
 
+static bool trace_is_kho_event(int type);
+
 enum print_line_t trace_print_bputs_msg_only(struct trace_iterator *iter)
 {
 	struct trace_seq *s = &iter->seq;
@@ -784,7 +786,7 @@ static DEFINE_IDA(trace_event_ida);
 
 static void free_trace_event_type(int type)
 {
-	if (type >= __TRACE_LAST_TYPE)
+	if (type >= __TRACE_LAST_TYPE && !trace_is_kho_event(type))
 		ida_free(&trace_event_ida, type);
 }
 
@@ -810,6 +812,156 @@ void trace_event_read_unlock(void)
 	up_read(&trace_event_sem);
 }
 
+
+/**
+ * trace_kho_get_map - Return the KHO event map
+ * @pmap: Pointer to a trace map array. Will be filled on success.
+ * @plen: Pointer to the length of the map. Will be filled on success.
+ * @unallocated: True if the event does not have an ID yet
+ *
+ * Event types are semi-dynamically generated. To ensure that
+ * their identifiers match before and after kexec with KHO,
+ * we store an event map in the KHO DT. Whenever we need the
+ * map, this function provides it.
+ *
+ * The first time we request a map, it also walks through it and
+ * reserves all identifiers so later event registration has find their
+ * identifier already reserved.
+ */
+static int trace_kho_get_map(const struct trace_event_map **pmap, int *plen,
+			     bool unallocated)
+{
+	static const struct trace_event_map *event_map;
+	static int event_map_len;
+	static bool event_map_reserved;
+	const struct trace_event_map *map = NULL;
+	const void *fdt = kho_get_fdt();
+	const char *path = "/ftrace";
+	int off, err, len = 0;
+	int i;
+
+	if (!IS_ENABLED(CONFIG_FTRACE_KHO) || !fdt)
+		return -EINVAL;
+
+	if (event_map) {
+		map = event_map;
+		len = event_map_len;
+	}
+
+	if (!map) {
+		off = fdt_path_offset(fdt, path);
+
+		if (off < 0) {
+			pr_debug("Could not find '%s' in DT", path);
+			return -EINVAL;
+		}
+
+		err = fdt_node_check_compatible(fdt, off, "ftrace-v1");
+		if (err) {
+			pr_warn("Node '%s' has invalid compatible", path);
+			return -EINVAL;
+		}
+
+		map = fdt_getprop(fdt, off, "events", &len);
+		if (!map)
+			return -EINVAL;
+
+		event_map = map;
+		event_map_len = len;
+	}
+
+	if (unallocated && !event_map_reserved) {
+		/*
+		 * Reserve all IDs in our IDA. We only have a working IDA later
+		 * in boot, so restrict it to when we allocate a dynamic type id
+		 * for an event.
+		 */
+		for (i = 0; i < len; i += sizeof(*map)) {
+			const struct trace_event_map *imap = (void *)map + i;
+
+			if (imap->type < __TRACE_LAST_TYPE)
+				continue;
+			if (ida_alloc_range(&trace_event_ida, imap->type, imap->type,
+					    GFP_KERNEL) != imap->type) {
+				pr_warn("Unable to reserve id %d", imap->type);
+				return -EINVAL;
+			}
+		}
+
+		event_map_reserved = true;
+	}
+
+	*pmap = map;
+	*plen = len;
+
+	return 0;
+}
+
+/**
+ * trace_is_kho_event - returns true if the event type is KHO reserved
+ * @event: the event type to enumerate
+ *
+ * With KHO, we reserve all previous kernel's trace event types in the
+ * KHO DT. Then, when we allocate a type, we just reuse the previous
+ * kernel's value. However, that means we have to keep these type identifiers
+ * reserved across the lifetime of the system, because we may get a new event
+ * that matches the old kernel's event fingerprint. This function is a small
+ * helper that allows us to check whether a type ID is in use by KHO.
+ */
+static bool trace_is_kho_event(int type)
+{
+	const struct trace_event_map *map = NULL;
+	int len, i;
+
+	if (trace_kho_get_map(&map, &len, false))
+		return false;
+
+	if (!map)
+		return false;
+
+	for (i = 0; i < len; i += sizeof(*map), map++)
+		if (map->type == type)
+			return true;
+
+	return false;
+}
+
+/**
+ * trace_kho_fill_event_type - restore event type info from KHO
+ * @event: the event to enumerate
+ *
+ * Event types are semi-dynamically generated. To ensure that
+ * their identifiers match before and after kexec with KHO,
+ * let's match up unique fingerprint - either their predetermined
+ * type or their crc32 value - and fill in the respective type
+ * information if we booted with KHO.
+ */
+static bool trace_kho_fill_event_type(struct trace_event *event)
+{
+	const struct trace_event_map *map = NULL;
+	int len = 0, i;
+	u32 crc32;
+
+	if (trace_kho_get_map(&map, &len, !event->type))
+		return false;
+
+	crc32 = event2fp(event);
+
+	for (i = 0; i < len; i += sizeof(*map), map++) {
+		if (map->crc32 == crc32) {
+			if (!map->type)
+				return false;
+
+			event->type = map->type;
+			return true;
+		}
+	}
+
+	pr_debug("Could not find event");
+
+	return false;
+}
+
 /**
  * register_trace_event - register output for an event type
  * @event: the event type to register
@@ -838,7 +990,9 @@ int register_trace_event(struct trace_event *event)
 	if (WARN_ON(!event->funcs))
 		goto out;
 
-	if (!event->type) {
+	if (trace_kho_fill_event_type(event)) {
+		pr_debug("Recovered id=%d", event->type);
+	} else if (!event->type) {
 		event->type = alloc_trace_event_type();
 		if (!event->type)
 			goto out;
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:43 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:43 +0000
Subject: [PATCH v2 16/17] tracing: Add config option for kexec handover
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-11-graf@amazon.com>

Now that all bits are in place to allow ftrace to pass its trace data
into the next kernel on kexec, let's give users a kconfig option to
enable the functionality.

Signed-off-by: Alexander Graf <graf at amazon.com>

---

v1 -> v2:

  - Select crc32
---
 kernel/trace/Kconfig | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 61c541c36596..418a5ae11aac 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -1169,6 +1169,20 @@ config HIST_TRIGGERS_DEBUG
 
           If unsure, say N.
 
+config FTRACE_KHO
+	bool "Ftrace Kexec handover support"
+	depends on KEXEC_KHO
+	select CRC32
+	help
+          Enable support for ftrace to pass metadata across kexec so the new
+	  kernel continues to use the previous kernel's trace buffers.
+
+	  This can be useful when debugging kexec performance or correctness
+	  issues: The new kernel can dump the old kernel's trace buffer which
+	  contains all events until reboot.
+
+	  If unsure, say N.
+
 source "kernel/trace/rv/Kconfig"
 
 endif # FTRACE
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From graf at amazon.com  Fri Dec 22 11:51:44 2023
From: graf at amazon.com (Alexander Graf)
Date: Fri, 22 Dec 2023 19:51:44 +0000
Subject: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO
In-Reply-To: <20231222195144.24532-1-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
Message-ID: <20231222195144.24532-12-graf@amazon.com>

With ftrace in KHO, we are creating an ABI between old kernel and new
kernel about the state that they transfer. To ensure that we document
that state and catch any breaking change, let's add its schema to the
common devicetree bindings. This way, we can quickly reason about the
state that gets passed.

Signed-off-by: Alexander Graf <graf at amazon.com>
---
 .../bindings/kho/ftrace/ftrace-array.yaml     | 46 +++++++++++++++
 .../bindings/kho/ftrace/ftrace-cpu.yaml       | 56 +++++++++++++++++++
 .../bindings/kho/ftrace/ftrace.yaml           | 48 ++++++++++++++++
 3 files changed, 150 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
 create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
 create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml

diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
new file mode 100644
index 000000000000..9960fefc292d
--- /dev/null
+++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/kho/ftrace/ftrace-array.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ftrace trace array
+
+maintainers:
+  - Alexander Graf <graf at amazon.com>
+
+properties:
+  compatible:
+    enum:
+      - ftrace,array-v1
+
+  trace_flags:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Bitmap of all the trace flags that were enabled in the trace array at the
+      point of serialization.
+
+# Subnodes will be of type "ftrace,cpu-v1", one each per CPU
+additionalProperties: true
+
+required:
+  - compatible
+  - trace_flags
+
+examples:
+  - |
+    ftrace {
+        compatible = "ftrace-v1";
+        events = <1 1 2 2 3 3>;
+
+        global_trace {
+          compatible = "ftrace,array-v1";
+          trace_flags = < 0x3354601 >;
+
+          cpu0 {
+            compatible = "ftrace,cpu-v1";
+            cpu = < 0x00 >;
+            mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
+          };
+        };
+      };
diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
new file mode 100644
index 000000000000..58c715e93f37
--- /dev/null
+++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/kho/ftrace/ftrace-cpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ftrace per-CPU ring buffer contents
+
+maintainers:
+  - Alexander Graf <graf at amazon.com>
+
+properties:
+  compatible:
+    enum:
+      - ftrace,cpu-v1
+
+  cpu:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      CPU number of the CPU that this ring buffer belonged to when it was
+      serialized.
+
+  mem:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+      Array of { u64 phys_addr, u64 len } elements that describe a list of ring
+      buffer pages. Each page consists of two elements. The first element
+      describes the location of the struct buffer_page that contains metadata
+      for a given ring buffer page, such as the ring's head indicator. The
+      second element points to the ring buffer data page which contains the raw
+      trace data.
+
+additionalProperties: false
+
+required:
+  - compatible
+  - cpu
+  - mem
+
+examples:
+  - |
+    ftrace {
+        compatible = "ftrace-v1";
+        events = <1 1 2 2 3 3>;
+
+        global_trace {
+          compatible = "ftrace,array-v1";
+          trace_flags = < 0x3354601 >;
+
+          cpu0 {
+            compatible = "ftrace,cpu-v1";
+            cpu = < 0x00 >;
+            mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
+          };
+        };
+      };
diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
new file mode 100644
index 000000000000..b87a64843af3
--- /dev/null
+++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/kho/ftrace/ftrace.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ftrace core data
+
+maintainers:
+  - Alexander Graf <graf at amazon.com>
+
+properties:
+  compatible:
+    enum:
+      - ftrace-v1
+
+  events:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+      Array of { u32 crc, u32 type } elements. Each element contains a unique
+      identifier for an event, followed by the identifier that this event had
+      in the previous kernel's trace buffers.
+
+# Other child nodes will be of type "ftrace,array-v1". Each of which describe
+# a trace buffer
+additionalProperties: true
+
+required:
+  - compatible
+  - events
+
+examples:
+  - |
+    ftrace {
+        compatible = "ftrace-v1";
+        events = <1 1 2 2 3 3>;
+
+        global_trace {
+          compatible = "ftrace,array-v1";
+          trace_flags = < 0x3354601 >;
+
+          cpu0 {
+            compatible = "ftrace,cpu-v1";
+            cpu = < 0x00 >;
+            mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
+          };
+        };
+      };
-- 
2.40.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





From peter.ujfalusi at gmail.com  Fri Dec 22 12:16:11 2023
From: peter.ujfalusi at gmail.com (=?UTF-8?Q?P=C3=A9ter_Ujfalusi?=)
Date: Fri, 22 Dec 2023 22:16:11 +0200
Subject: [PATCH v3 0/4] Add APIs to request TX/RX DMA channels for thread
 ID
In-Reply-To: <20231218062640.2338453-1-s-vadapalli@ti.com>
References: <20231218062640.2338453-1-s-vadapalli@ti.com>
Message-ID: <4b5bd2c2-37c9-4cdf-934d-8bc6d6f73152@gmail.com>

Hi Siddharth,

On 12/18/23 08:26, Siddharth Vadapalli wrote:
> The existing APIs for requesting TX and RX DMA channels rely on parsing
> a device-tree node to obtain the Channel/Thread IDs from their names.
> However, it is possible to know the thread IDs by alternative means such
> as being informed by Firmware on a remote core via RPMsg regarding the
> allocated TX/RX DMA channel thread IDs. In such cases, the driver can be
> probed by non device-tree methods such as RPMsg-bus, due to which it is not
> necessary that the device using the DMA has a device-tree node
> corresponding to it. Thus, add APIs to enable the driver to make use of
> the existing DMA APIs even when there's no device-tree node.
> 
> Additionally, since the name of the device for the remote RX channel is
> being set purely on the basis of the RX channel ID itself, it can result
> in duplicate names when multiple flows are used on the same channel.
> Avoid name duplication by including the flow in the name.

Thank you for the updates,
Acked-by: Peter Ujfalusi <peter.ujfalusi at gmail.com>

> Series is based on linux-next tagged next-20231215.
> 
> v2:
> https://lore.kernel.org/r/20231212111011.1401641-1-s-vadapalli at ti.com/
> Changes since v2:
> - Rebased series on linux-next tagged next-20231215.
> - Renamed the function "k3_udma_glue_request_tx_chn_by_id()" to
>   "k3_udma_glue_request_tx_chn_for_thread_id()" as suggested by:
>   P?ter Ujfalusi <peter.ujfalusi at gmail.com>
> - Similar to the above change, I have also renamed the function
>   "k3_udma_glue_request_remote_rx_chn_by_id()" to
>   "k3_udma_glue_request_remote_rx_chn_for_thread_id()".
> - Updated the function prototypes in include/linux/dma/k3-udma-glue.h
>   accordingly.
> - Updated the commit messages for patches 3/4 and 4/4 to match the
>   changes made to the function names.
> 
> v1:
> https://lore.kernel.org/r/20231114083906.3143548-1-s-vadapalli at ti.com/
> Changes since v1:
> - Rebased series on linux-next tagged next-20231212.
> - Updated commit messages with details regarding the use-case for which
>   the newly added APIs will be required.
> - Removed unnecessary return value check within
>   "of_k3_udma_glue_parse_chn()" function in patch 1, since it will fall
>   through to "out_put_spec" anyway.
> - Removed unnecessary return value check within
>   "of_k3_udma_glue_parse_chn_by_id()" function in patch 1, since it will
>   fall through to "out_put_spec" anyway.
> - Moved patch 4 of v1 series to patch 2 of current series.
> 
> RFC Series:
> https://lore.kernel.org/r/20231111121555.2656760-1-s-vadapalli at ti.com/
> Changes since RFC Series:
> - Rebased patches 1, 2 and 3 on linux-next tagged next-20231114.
> - Added patch 4 to the series.
> 
> Regards,
> Siddharth.
> 
> Siddharth Vadapalli (4):
>   dmaengine: ti: k3-udma-glue: Add function to parse channel by ID
>   dmaengine: ti: k3-udma-glue: Update name for remote RX channel device
>   dmaengine: ti: k3-udma-glue: Add function to request TX chan for
>     thread ID
>   dmaengine: ti: k3-udma-glue: Add function to request RX chan for
>     thread ID
> 
>  drivers/dma/ti/k3-udma-glue.c    | 306 ++++++++++++++++++++++---------
>  include/linux/dma/k3-udma-glue.h |  10 +
>  2 files changed, 229 insertions(+), 87 deletions(-)
> 

-- 
P?ter


From festevam at gmail.com  Fri Dec 22 12:26:11 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 22 Dec 2023 17:26:11 -0300
Subject: imx7_media_csi probe deferred
In-Reply-To: <CAJ+vNU2Kj=a-_xDBsNO5zkyP_mgLsVtA2bXqkAkpmCQmVEA_=w@mail.gmail.com>
References: <CAJ+vNU2Kj=a-_xDBsNO5zkyP_mgLsVtA2bXqkAkpmCQmVEA_=w@mail.gmail.com>
Message-ID: <CAOMZO5CX4xuMvZDMVEND0vpMyuU7ozDm2pk+yVQZAKLenipY_g@mail.gmail.com>

Hi Tim,

On Thu, Dec 21, 2023 at 10:12?PM Tim Harvey <tharvey at gateworks.com> wrote:
>
> Greetings,
>
> I'm running into an issue with Linux 6.6 (6.6.8) when compiling with
> modules where the imx7_media_csi driver probe is deferred and I'm not
> clear how to troubleshoot the cause.
>
> The board is imx8mm-venice-gw73xx-0x [1] with
> imx8mm-venice-gw73xx-0x-imx219.dtso [2] and I'm using
> arch/arm64/configs/defconfig.
>
> The kernel reports the following:
> # dmesg | egrep csi\|mipi\|imx219
> [    1.293264] i2c 2-0010: Fixed dependency cycle(s) with
> /soc at 0/bus at 32c00000/mipi-csi at 32e30000/ports/port at 0/endpoint
> [   12.001419] imx219 2-0010: supply VANA not found, using dummy regulator
> [   12.044885] imx219 2-0010: supply VDDL not found, using dummy regulator
> [   12.164308] imx7-csi 32e20000.csi: Registered csi capture as /dev/video0
> [   12.178460] imx7-csi 32e20000.csi: error -ENOTCONN: Failed to get
> remote endpoint
> [   12.200047] imx7-csi: probe of 32e20000.csi failed with error -107
> # cat /sys/kernel/debug/devices_deferred
> cpufreq-dt
> 32e30000.mipi-csi       platform: wait for supplier

I am not able to reproduce this problem.

I have just booted 6.6.8 on an imx8mm-evk and the camera is working well:

root at imx8mmevk:~# dmesg | egrep csi\|mipi\|ov56
[    0.042431] platform 32e30000.mipi-csi: Fixed dependency cycle(s)
with /soc at 0/bus at 32c00000/csi at 32e20000/port/endpoint
[    1.575489] i2c 2-003c: Fixed dependency cycle(s) with
/soc at 0/bus at 32c00000/mipi-csi at 32e30000/ports/port at 0/endpoint
[    5.514082] ov5640 2-003c: supply DOVDD not found, using dummy regulator
[    5.522453] ov5640 2-003c: supply AVDD not found, using dummy regulator
[    5.538136] ov5640 2-003c: supply DVDD not found, using dummy regulator
[    5.552376] imx-mipi-csis 32e30000.mipi-csi: lanes: 2, freq: 333000000
[    5.583661] imx7-csi 32e20000.csi: Registered csi capture as /dev/video0

root at imx8mmevk:~# cat /sys/kernel/debug/devices_deferred
root at imx8mmevk:~# zcat /proc/config.gz | egrep
VIDEO_OV5640\|VIDEO_IMX_MIPI\|VIDEO_IMX7
CONFIG_VIDEO_IMX7_CSI=m
CONFIG_VIDEO_IMX_MIPI_CSIS=m
CONFIG_VIDEO_OV5640=m


From tharvey at gateworks.com  Fri Dec 22 12:51:38 2023
From: tharvey at gateworks.com (Tim Harvey)
Date: Fri, 22 Dec 2023 12:51:38 -0800
Subject: imx7_media_csi probe deferred
In-Reply-To: <CAOMZO5CX4xuMvZDMVEND0vpMyuU7ozDm2pk+yVQZAKLenipY_g@mail.gmail.com>
References: <CAJ+vNU2Kj=a-_xDBsNO5zkyP_mgLsVtA2bXqkAkpmCQmVEA_=w@mail.gmail.com>
 <CAOMZO5CX4xuMvZDMVEND0vpMyuU7ozDm2pk+yVQZAKLenipY_g@mail.gmail.com>
Message-ID: <CAJ+vNU3FUMBt7WyEJHJFkgjUViTUjS1EgeVt49CcdN7dgtaMfQ@mail.gmail.com>

On Fri, Dec 22, 2023 at 12:26?PM Fabio Estevam <festevam at gmail.com> wrote:
>
> Hi Tim,
>
> On Thu, Dec 21, 2023 at 10:12?PM Tim Harvey <tharvey at gateworks.com> wrote:
> >
> > Greetings,
> >
> > I'm running into an issue with Linux 6.6 (6.6.8) when compiling with
> > modules where the imx7_media_csi driver probe is deferred and I'm not
> > clear how to troubleshoot the cause.
> >
> > The board is imx8mm-venice-gw73xx-0x [1] with
> > imx8mm-venice-gw73xx-0x-imx219.dtso [2] and I'm using
> > arch/arm64/configs/defconfig.
> >
> > The kernel reports the following:
> > # dmesg | egrep csi\|mipi\|imx219
> > [    1.293264] i2c 2-0010: Fixed dependency cycle(s) with
> > /soc at 0/bus at 32c00000/mipi-csi at 32e30000/ports/port at 0/endpoint
> > [   12.001419] imx219 2-0010: supply VANA not found, using dummy regulator
> > [   12.044885] imx219 2-0010: supply VDDL not found, using dummy regulator
> > [   12.164308] imx7-csi 32e20000.csi: Registered csi capture as /dev/video0
> > [   12.178460] imx7-csi 32e20000.csi: error -ENOTCONN: Failed to get
> > remote endpoint
> > [   12.200047] imx7-csi: probe of 32e20000.csi failed with error -107
> > # cat /sys/kernel/debug/devices_deferred
> > cpufreq-dt
> > 32e30000.mipi-csi       platform: wait for supplier
>
> I am not able to reproduce this problem.
>
> I have just booted 6.6.8 on an imx8mm-evk and the camera is working well:
>
> root at imx8mmevk:~# dmesg | egrep csi\|mipi\|ov56
> [    0.042431] platform 32e30000.mipi-csi: Fixed dependency cycle(s)
> with /soc at 0/bus at 32c00000/csi at 32e20000/port/endpoint
> [    1.575489] i2c 2-003c: Fixed dependency cycle(s) with
> /soc at 0/bus at 32c00000/mipi-csi at 32e30000/ports/port at 0/endpoint
> [    5.514082] ov5640 2-003c: supply DOVDD not found, using dummy regulator
> [    5.522453] ov5640 2-003c: supply AVDD not found, using dummy regulator
> [    5.538136] ov5640 2-003c: supply DVDD not found, using dummy regulator
> [    5.552376] imx-mipi-csis 32e30000.mipi-csi: lanes: 2, freq: 333000000
> [    5.583661] imx7-csi 32e20000.csi: Registered csi capture as /dev/video0
>
> root at imx8mmevk:~# cat /sys/kernel/debug/devices_deferred
> root at imx8mmevk:~# zcat /proc/config.gz | egrep
> VIDEO_OV5640\|VIDEO_IMX_MIPI\|VIDEO_IMX7
> CONFIG_VIDEO_IMX7_CSI=m
> CONFIG_VIDEO_IMX_MIPI_CSIS=m
> CONFIG_VIDEO_OV5640=m

Fabio,

Thanks for testing. Is this with arch/arm64/defconfig?

Best Regards,

Tim


From festevam at gmail.com  Fri Dec 22 12:56:50 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 22 Dec 2023 17:56:50 -0300
Subject: imx7_media_csi probe deferred
In-Reply-To: <CAJ+vNU3FUMBt7WyEJHJFkgjUViTUjS1EgeVt49CcdN7dgtaMfQ@mail.gmail.com>
References: <CAJ+vNU2Kj=a-_xDBsNO5zkyP_mgLsVtA2bXqkAkpmCQmVEA_=w@mail.gmail.com>
 <CAOMZO5CX4xuMvZDMVEND0vpMyuU7ozDm2pk+yVQZAKLenipY_g@mail.gmail.com> <CAJ+vNU3FUMBt7WyEJHJFkgjUViTUjS1EgeVt49CcdN7dgtaMfQ@mail.gmail.com>
Message-ID: <CAOMZO5AGLAxeRfya2EJOMghqE5cvqZtqPAz05oMfFJT==F6PvQ@mail.gmail.com>

On Fri, Dec 22, 2023 at 5:51?PM Tim Harvey <tharvey at gateworks.com> wrote:

> Fabio,
>
> Thanks for testing. Is this with arch/arm64/defconfig?

I modified arch/arm64/defconfig to only build for NXP i.MX.

The resultant defconfig is this one:
https://pastebin.com/raw/6dFx3tfp


From robh at kernel.org  Fri Dec 22 13:19:39 2023
From: robh at kernel.org (Rob Herring)
Date: Fri, 22 Dec 2023 15:19:39 -0600
Subject: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO
In-Reply-To: <20231222195144.24532-12-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
 <20231222195144.24532-12-graf@amazon.com>
Message-ID: <170327997978.2942294.14458926896132199704.robh@kernel.org>


On Fri, 22 Dec 2023 19:51:44 +0000, Alexander Graf wrote:
> With ftrace in KHO, we are creating an ABI between old kernel and new
> kernel about the state that they transfer. To ensure that we document
> that state and catch any breaking change, let's add its schema to the
> common devicetree bindings. This way, we can quickly reason about the
> state that gets passed.
> 
> Signed-off-by: Alexander Graf <graf at amazon.com>
> ---
>  .../bindings/kho/ftrace/ftrace-array.yaml     | 46 +++++++++++++++
>  .../bindings/kho/ftrace/ftrace-cpu.yaml       | 56 +++++++++++++++++++
>  .../bindings/kho/ftrace/ftrace.yaml           | 48 ++++++++++++++++
>  3 files changed, 150 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
>  create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
>  create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml:43:111: [warning] line too long (117 > 110 characters) (line-length)
./Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml:53:111: [warning] line too long (117 > 110 characters) (line-length)
./Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml:45:111: [warning] line too long (117 > 110 characters) (line-length)

dtschema/dtc warnings/errors:
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace-array.example.dts:29.25-39: Value 0x0000000101000000 truncated to 0x01000000
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace-array.example.dts:29.48-62: Value 0x0000000101000100 truncated to 0x01000100
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace-array.example.dts:29.73-87: Value 0x0000000101000038 truncated to 0x01000038
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace-array.example.dts:29.96-110: Value 0x0000000101002000 truncated to 0x01002000
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.example.dts:29.25-39: Value 0x0000000101000000 truncated to 0x01000000
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.example.dts:29.48-62: Value 0x0000000101000100 truncated to 0x01000100
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.example.dts:29.73-87: Value 0x0000000101000038 truncated to 0x01000038
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.example.dts:29.96-110: Value 0x0000000101002000 truncated to 0x01002000
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace.example.dts:29.25-39: Value 0x0000000101000000 truncated to 0x01000000
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace.example.dts:29.48-62: Value 0x0000000101000100 truncated to 0x01000100
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace.example.dts:29.73-87: Value 0x0000000101000038 truncated to 0x01000038
WARNING: Documentation/devicetree/bindings/kho/ftrace/ftrace.example.dts:29.96-110: Value 0x0000000101002000 truncated to 0x01002000

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231222195144.24532-12-graf at amazon.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From fancer.lancer at gmail.com  Fri Dec 22 13:49:10 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Sat, 23 Dec 2023 00:49:10 +0300
Subject: [PATCH net-next v1 3/4] net: stmmac: Add support for TX/RX
 channel interrupt
In-Reply-To: <20231222054451.2683242-4-leong.ching.swee@intel.com>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
 <20231222054451.2683242-4-leong.ching.swee@intel.com>
Message-ID: <qyiveqz3egzctymkwflgw4u6ubnpiss2x244fsepop7t3ve7ev@7x24oaiferuy>

On Fri, Dec 22, 2023 at 01:44:50PM +0800, Leong Ching Swee wrote:
> From: Swee Leong Ching <leong.ching.swee at intel.com>
> 
> Enable TX/RX channel interrupt registration for MAC that interrupts CPU
> through shared peripheral interrupt (SPI).
> 
> Per channel interrupts and interrupt-names are registered through,
> Eg: 4 tx and 4 rx channels:
> interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
>              <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
>              <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
>              <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
>              <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
>              <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
>              <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
>              <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "dma_tx0",
>                   "dma_tx1",
>                   "dma_tx2",
>                   "dma_tx3",
>                   "dma_rx0",
>                   "dma_rx1",
>                   "dma_rx2",
>                   "dma_rx3";
> 
> Signed-off-by: Teoh Ji Sheng <ji.sheng.teoh at intel.com>
> Signed-off-by: Swee Leong Ching <leong.ching.swee at intel.com>
> ---
>  .../ethernet/stmicro/stmmac/stmmac_platform.c | 24 +++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 70eadc83ca68..f857907f13a0 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -710,6 +710,8 @@ EXPORT_SYMBOL_GPL(devm_stmmac_probe_config_dt);
>  int stmmac_get_platform_resources(struct platform_device *pdev,
>  				  struct stmmac_resources *stmmac_res)
>  {

> +	char irq_name[8];

By DW XGMAC v2.x IP-core design there can be up to 16 Tx channels and
12 Rx channels. Thus it's better to set irq_name size being at least
(strlen("dma_tx16") + 1) == 9 beforehand since you are adding this
code anyway and for some reason didn't consider to pick the Jisheng'
patch up which fixed the MTL_MAX_TX_QUEUES/MTL_MAX_RX_QUEUES macros.

> +	int i;

Please add an empty line between the variables declaration and the
next statement.

>  	memset(stmmac_res, 0, sizeof(*stmmac_res));
>  
>  	/* Get IRQ information early to have an ability to ask for deferred
> @@ -719,6 +721,28 @@ int stmmac_get_platform_resources(struct platform_device *pdev,
>  	if (stmmac_res->irq < 0)
>  		return stmmac_res->irq;
>  

> +	/* For RX Channel */
> +	for (i = 0; i < MTL_MAX_RX_QUEUES; i++) {
> +		snprintf(irq_name, sizeof(irq_name), "dma_rx%i", i);
> +		stmmac_res->rx_irq[i] = platform_get_irq_byname_optional(pdev, irq_name);
> +		if (stmmac_res->rx_irq[i] < 0) {
> +			if (stmmac_res->rx_irq[i] == -EPROBE_DEFER)
> +				return -EPROBE_DEFER;
> +			break;
> +		}
> +	}

What about:

+	/* Get optional Tx/Rx DMA per-channel IRQs, which otherwise
+	 * are supposed to be delivered via the common MAC IRQ line
+	 */
+	for (i = 0; i < MTL_MAX_RX_QUEUES; i++) {
+		snprintf(irq_name, sizeof(irq_name), "dma_rx%i", i);
+		irq = platform_get_irq_byname_optional(pdev, irq_name);
+		if (irq == -EPROBE_DEFER)
+			return irq;
+		else if (irq < 0)
+			break;
+
+		stmmac_res->rx_irq[i] = irq;
+	}

It's cleaner a bit with less indentations and doesn't pollute
rx_irq[]/tx_irq[] arrays with the error numbers.

> +
> +	/* For TX Channel */
> +	for (i = 0; i < MTL_MAX_TX_QUEUES; i++) {
> +		snprintf(irq_name, sizeof(irq_name), "dma_tx%i", i);
> +		stmmac_res->tx_irq[i] = platform_get_irq_byname_optional(pdev, irq_name);
> +		if (stmmac_res->tx_irq[i] < 0) {
> +			if (stmmac_res->rx_irq[i] == -EPROBE_DEFER)
> +				return -EPROBE_DEFER;
> +			break;
> +		}
> +	}
> +

Please move the Tx/Rx IRQs getting loops to the bottom of the
stmmac_get_platform_resources() method. Thus the order of the IRQs
getting would be the same as the order of the IRQs requests
implemented in the stmmac_request_irq_multi_msi() and
stmmac_request_irq_single() methods.

-Serge(y)

>  	/* On some platforms e.g. SPEAr the wake up irq differs from the mac irq
>  	 * The external wake up irq can be passed through the platform code
>  	 * named as "eth_wake_irq"
> -- 
> 2.34.1
> 
> 


From fancer.lancer at gmail.com  Fri Dec 22 13:56:46 2023
From: fancer.lancer at gmail.com (Serge Semin)
Date: Sat, 23 Dec 2023 00:56:46 +0300
Subject: [PATCH net-next v1 4/4] net: stmmac: Use interrupt mode INTM=1
 for per channel irq
In-Reply-To: <20231222054451.2683242-5-leong.ching.swee@intel.com>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
 <20231222054451.2683242-5-leong.ching.swee@intel.com>
Message-ID: <prjrrsznvpnbanseqttqgtu3s6kgillyyhs5hozwxwh4kt7eiv@zmups3rcbvby>

On Fri, Dec 22, 2023 at 01:44:51PM +0800, Leong Ching Swee wrote:
> From: Swee Leong Ching <leong.ching.swee at intel.com>
> 
> Enable per DMA channel interrupt that uses shared peripheral
> interrupt (SPI), so only per channel TX and RX intr (TI/RI)
> are handled by TX/RX ISR without calling common interrupt ISR.
> 
> Signed-off-by: Teoh Ji Sheng <ji.sheng.teoh at intel.com>
> Signed-off-by: Swee Leong Ching <leong.ching.swee at intel.com>
> ---
>  .../net/ethernet/stmicro/stmmac/dwxgmac2.h    |  3 ++
>  .../ethernet/stmicro/stmmac/dwxgmac2_dma.c    | 32 +++++++++++--------
>  2 files changed, 22 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> index 207ff1799f2c..04bf731cb7ea 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> @@ -346,6 +346,9 @@
>  /* DMA Registers */
>  #define XGMAC_DMA_MODE			0x00003000
>  #define XGMAC_SWR			BIT(0)
> +#define XGMAC_DMA_MODE_INTM_MASK	GENMASK(13, 12)
> +#define XGMAC_DMA_MODE_INTM_SHIFT	12
> +#define XGMAC_DMA_MODE_INTM_MODE1	0x1
>  #define XGMAC_DMA_SYSBUS_MODE		0x00003004
>  #define XGMAC_WR_OSR_LMT		GENMASK(29, 24)
>  #define XGMAC_WR_OSR_LMT_SHIFT		24
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> index 3cde695fec91..dcb9f094415d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> @@ -31,6 +31,13 @@ static void dwxgmac2_dma_init(void __iomem *ioaddr,
>  		value |= XGMAC_EAME;
>  
>  	writel(value, ioaddr + XGMAC_DMA_SYSBUS_MODE);
> +
> +	if (dma_cfg->multi_irq_en) {
> +		value = readl(ioaddr + XGMAC_DMA_MODE);
> +		value &= ~XGMAC_DMA_MODE_INTM_MASK;
> +		value |= (XGMAC_DMA_MODE_INTM_MODE1 << XGMAC_DMA_MODE_INTM_SHIFT);
> +		writel(value, ioaddr + XGMAC_DMA_MODE);
> +	}
>  }
>  
>  static void dwxgmac2_dma_init_chan(struct stmmac_priv *priv,
> @@ -365,19 +372,18 @@ static int dwxgmac2_dma_interrupt(struct stmmac_priv *priv,
>  	}
>  

>  	/* TX/RX NORMAL interrupts */
> -	if (likely(intr_status & XGMAC_NIS)) {
> -		if (likely(intr_status & XGMAC_RI)) {
> -			u64_stats_update_begin(&rxq_stats->syncp);
> -			rxq_stats->rx_normal_irq_n++;
> -			u64_stats_update_end(&rxq_stats->syncp);
> -			ret |= handle_rx;
> -		}
> -		if (likely(intr_status & (XGMAC_TI | XGMAC_TBU))) {
> -			u64_stats_update_begin(&txq_stats->syncp);
> -			txq_stats->tx_normal_irq_n++;
> -			u64_stats_update_end(&txq_stats->syncp);
> -			ret |= handle_tx;
> -		}
> +	if (likely(intr_status & XGMAC_RI)) {
> +		u64_stats_update_begin(&rxq_stats->syncp);
> +		rxq_stats->rx_normal_irq_n++;
> +		u64_stats_update_end(&rxq_stats->syncp);
> +		ret |= handle_rx;
> +	}
> +
> +	if (likely(intr_status & (XGMAC_TI | XGMAC_TBU))) {
> +		u64_stats_update_begin(&txq_stats->syncp);
> +		txq_stats->tx_normal_irq_n++;
> +		u64_stats_update_end(&txq_stats->syncp);
> +		ret |= handle_tx;

Could you please clarify my comment to the original patch:

On Fri, Aug 18, 2023 at 20:10:21PM +0300, Serge Semin wrote:
> Just curious. Is this change really necessary seeing NIS IRQ is
> unmasked and it is unmasked-OR of the RI/TI/TBU flags in the
> DMA_CHx_Status register? Moreover based on the HW manual,
> DMA_CHx_Status reflects raw IRQ flags status except NIS and AIS which
> are the masked OR of the respective flags. So AFAIU NIS will be set in
> anyway if you have RI/TI/TBU IRQs enabled.

-Serge(y)

>  	}
>  
>  	/* Clear interrupts */
> -- 
> 2.34.1
> 
> 


From cniedermaier at dh-electronics.com  Fri Dec 22 14:02:16 2023
From: cniedermaier at dh-electronics.com (Christoph Niedermaier)
Date: Fri, 22 Dec 2023 23:02:16 +0100
Subject: [PATCH] serial: imx: Correct clock error message in function probe()
Message-ID: <20231222220216.2188-1-cniedermaier@dh-electronics.com>

Correct the clock error message by changing the clock name.

Signed-off-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>
---
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Jiri Slaby <jirislaby at kernel.org>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <festevam at denx.de>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: Sergey Organov <sorganov at gmail.com>
Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
Cc: Rob Herring <robh at kernel.org>
Cc: "Ilpo J?rvinen" <ilpo.jarvinen at linux.intel.com>
Cc: Tom Rix <trix at redhat.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
To: linux-serial at vger.kernel.org
To: linux-arm-kernel at lists.infradead.org
---
 drivers/tty/serial/imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e7e952bb7bb8..55105a4b1af8 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2327,7 +2327,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 	/* For register access, we only need to enable the ipg clock. */
 	ret = clk_prepare_enable(sport->clk_ipg);
 	if (ret) {
-		dev_err(&pdev->dev, "failed to enable per clk: %d\n", ret);
+		dev_err(&pdev->dev, "failed to enable ipg clk: %d\n", ret);
 		return ret;
 	}
 
-- 
2.11.0



From cniedermaier at dh-electronics.com  Fri Dec 22 14:11:01 2023
From: cniedermaier at dh-electronics.com (Christoph Niedermaier)
Date: Fri, 22 Dec 2023 23:11:01 +0100
Subject: [PATCH] serial: imx: Ensure that imx_uart_rs485_config() is called with enabled clock
Message-ID: <20231222221101.2380-1-cniedermaier@dh-electronics.com>

There are register accesses in the function imx_uart_rs485_config(). The
clock must be enabled for these accesses. This was ensured by calling it
via the function uart_rs485_config() in the probe() function within the
range where the clock is enabled. With the commit 7c7f9bc986e6 ("serial:
Deassert Transmit Enable on probe in driver-specific way") it was removed
from the probe() function and is now only called through the function
uart_add_one_port() which is located at the end of the probe() function.
But the clock is already switched off in this area. To ensure that the
clock is enabled during register access, move the disabling of the clock
to the very end of the probe() function.

Fixes: 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way")
Signed-off-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>
---
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Jiri Slaby <jirislaby at kernel.org>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <festevam at denx.de>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: Sergey Organov <sorganov at gmail.com>
Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
Cc: Rob Herring <robh at kernel.org>
Cc: "Ilpo J?rvinen" <ilpo.jarvinen at linux.intel.com>
Cc: Tom Rix <trix at redhat.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Lukas Wunner <lukas at wunner.de>
To: linux-serial at vger.kernel.org
To: linux-arm-kernel at lists.infradead.org
---
 drivers/tty/serial/imx.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e7e952bb7bb8..2ec2e8a55884 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2419,8 +2419,6 @@ static int imx_uart_probe(struct platform_device *pdev)
 		imx_uart_writel(sport, ucr3, UCR3);
 	}
 
-	clk_disable_unprepare(sport->clk_ipg);
-
 	hrtimer_init(&sport->trigger_start_tx, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	hrtimer_init(&sport->trigger_stop_tx, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	sport->trigger_start_tx.function = imx_trigger_start_tx;
@@ -2467,7 +2465,11 @@ static int imx_uart_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, sport);
 
-	return uart_add_one_port(&imx_uart_uart_driver, &sport->port);
+	ret = uart_add_one_port(&imx_uart_uart_driver, &sport->port);
+
+	clk_disable_unprepare(sport->clk_ipg);
+
+	return ret;
 }
 
 static void imx_uart_remove(struct platform_device *pdev)
-- 
2.11.0



From marex at denx.de  Fri Dec 22 14:21:01 2023
From: marex at denx.de (Marek Vasut)
Date: Fri, 22 Dec 2023 23:21:01 +0100
Subject: [PATCH] serial: imx: Correct clock error message in function
 probe()
In-Reply-To: <20231222220216.2188-1-cniedermaier@dh-electronics.com>
References: <20231222220216.2188-1-cniedermaier@dh-electronics.com>
Message-ID: <560dfe3e-f991-4f33-b6b8-d31d6a4caacf@denx.de>

On 12/22/23 23:02, Christoph Niedermaier wrote:
> Correct the clock error message by changing the clock name.
> 
> Signed-off-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>

Fixes: tag missing ?


From markhas at chromium.org  Fri Dec 22 14:30:43 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Fri, 22 Dec 2023 15:30:43 -0700
Subject: [PATCH v2 00/22] Improve IRQ wake capability reporting and update
 the cros_ec driver to use it
In-Reply-To: <ZYRAuY1LGdD8_u5K@smile.fi.intel.com>
References: <20231220235459.2965548-1-markhas@chromium.org> <ZYRAuY1LGdD8_u5K@smile.fi.intel.com>
Message-ID: <CANg-bXDw+bYNTu-HFaNAPb4e+_oKt2ExR6PehWR_==vpboKGaw@mail.gmail.com>

> Just wondering if you used --histogram diff algo when preparing patches.

Not knowingly. I use patman which uses 'git format-patch' under the
covers with some added options:
https://github.com/siemens/u-boot/blob/master/tools/patman/gitutil.py#L308


From patrick at stwcx.xyz  Fri Dec 22 14:38:12 2023
From: patrick at stwcx.xyz (Patrick Williams)
Date: Fri, 22 Dec 2023 16:38:12 -0600
Subject: [PATCH v8] ARM: dts: aspeed: Adding Facebook Bletchley BMC
In-Reply-To: <20231220170012.GA10387@wunner.de>
References: <20231220080733.GA30641@wunner.de>
 <F444BFCC-1D44-4AF6-A0E1-B153A217FFE3@stwcx.xyz>
 <20231220170012.GA10387@wunner.de>
Message-ID: <ZYYP1C0h4ms9kEjA@heinlein.vulture-banana.ts.net>

(cc'd TPM mailing list for awareness)

On Wed, Dec 20, 2023 at 06:00:12PM +0100, Lukas Wunner wrote:
> On Wed, Dec 20, 2023 at 06:38:59AM -0600, Patrick Williams wrote:
> > On Dec 20, 2023, at 2:07AM, Lukas Wunner <lukas at wunner.de> wrote:
> > > On Tue, Dec 07, 2021 at 05:49:24PM +0800, Howard Chiu wrote:
> > > > Initial introduction of Facebook Bletchley equipped with
> > > > Aspeed 2600 BMC SoC.
> > > [...]
> > > > +        tpmdev at 0 {
> > > > +            compatible = "tcg,tpm_tis-spi";
> > > 
> > > What's the chip used on this board?  Going forward, the DT schema for TPMs
> > > requires the exact chip name in addition to the generic "tcg,tpm_tis-spi".
> > 
> > Why is this a requirement?  This assumes there is exactly one chip.
> > TPMs are often placed on a pluggable module in which multiple vendors
> > could be used. There is no way in the DTS to specify multiple compatible
> > chips.
> 
> It seems to be a convention to provide the name of the chip that's
> actually used, in addition to the generic compatible.

My impression is that this is subsystem dependent.  The MTD SPI-NOR
subsystem, for example, does not want any compatible or additional devices
added and instead `compatible = "jedic,spi-nor"` is all you need.  The
subsystem does the SFDP detection of the specific device (and
parameters) [1].

> One advantage I see is that specific properties can be enforced per-chip.
> E.g. Infineon SLB9670 TPMs support an SPI clock of up to 43 MHz,
> whereas Atmel ATTPM20P support 36 MHz.  The devicetree schema may
> contain those maximum speeds and the validator can check whether
> devicetrees observe them.

Noble goal.

For the Aspeed SOC that we use to interact with the TPM module, the
hardware logic doesn't properly implement bi-directional access, so we
end up using the SPI-GPIO driver and running at speeds far far below any
device maximum (obviously this isn't everyone's problem).

> Similarly, a device driver may use chip-specific quirks based on the
> compatible string.

IMO, if a chip requires quirks in order to function properly then it
isn't compatible with "tcg,tpm_tis-spi" is it?  Standards exist for a
reason.  If a chip can't follow them, don't claim it does.

> Last not least, it is useful for documentation purposes to specify which
> chip is used.
> 
> If chips are dual-sourced or triple-sourced, as you say, and they
> behave identically, then I think it is fine to specify all of their
> compatible strings plus the generic compatible.  

This has explicitly been rejected before; having multiple incompatible
chips listed in the same compatible.  I've tried to search lore but I
can't find a reference unfortunately.  We've had similar scenarios with
second-source scenarios and have been told to: change the DTS in u-boot,
use user-space bind calls, or work with the DTS overlay project to get
that working.  Frankly, all of those options are a challenge for
something fundamental like the TPM.

Furthermore, what you're suggesting does not jive with what is in the
devicetree binding documentation for tpm_tis-spi [2]:

- compatible: should be **one** of the following (emphasis mine)

> If they do not
> behave identically, separate devicetrees should be used for each
> board version with a different chip.

I am not following how that would work in a reasonable way.  As I said,
these are pluggable modules and not simply second-source builds.  There
are a collection of modules that can all be plugged into the same header.
They might not even be shipped with the device...  You might want TPM
modules provisioned under control of your own process, rather than the
device manufacturer, and you plug them in prior to using the device.

The only way I can conceive of doing this is to have a good chunk of u-boot
code that detects which module is plugged in and manually modifies the
compatible string in the DTS before loading the kernel.  Of course,
doing this changes your measurements and has to be done in the CRTM,
both of which decrease your security posture.

1. https://lore.kernel.org/lkml/4817515e-2833-6d39-03c3-30470344ac3a at microchip.com/
2. https://github.com/torvalds/linux/blob/c0f65a7c112b3cfa691cead54bcf24d6cc2182b5/Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt#L2

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231222/b03720ca/attachment.sig>

From jankul at alatek.krakow.pl  Fri Dec 22 14:43:38 2023
From: jankul at alatek.krakow.pl (Jan Kuliga)
Date: Fri, 22 Dec 2023 23:43:38 +0100
Subject: [PATCH 0/2] dmaengine: xilinx: xdma: Fix two clang warnings
In-Reply-To: <20231222-dma-xilinx-xdma-clang-fixes-v1-0-84a18ff184d2@kernel.org>
References: <20231222-dma-xilinx-xdma-clang-fixes-v1-0-84a18ff184d2@kernel.org>
Message-ID: <d3ada600-c0ed-486d-98d0-e161059099f3@alatek.krakow.pl>

Hi all,

On 22.12.2023 19:06, Nathan Chancellor wrote:
> Hi all,
> 
> This series fixes two clang warnings that I see after
> commit 2f8f90cd2f8d ("dmaengine: xilinx: xdma: Implement interleaved DMA
> transfers"). They have just been build tested but I think the logic is
> sound, please double check though.
> 
> ---
> Nathan Chancellor (2):
>       dmaengine: xilinx: xdma: Fix operator precedence in xdma_prep_interleaved_dma()
>       dmaengine: xilinx: xdma: Fix initialization location of desc in xdma_channel_isr()
> 
>  drivers/dma/xilinx/xdma.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> ---
> base-commit: 3d0b2176e04261ab4ac095ff2a17db077fc1e46d
> change-id: 20231222-dma-xilinx-xdma-clang-fixes-b9c2c3f5d0f3
> 
> Best regards,

Thanks for fixing my broken patches Nathan. Next time I submit any patch, I have to pay more attention to use proper compiler flags for sure (I didn't use those flags so I didn't get any warnings/errors). The logic is okay.

Thanks,
Jan


From u.kleine-koenig at pengutronix.de  Fri Dec 22 14:50:38 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 22 Dec 2023 23:50:38 +0100
Subject: [PATCH 07/13] irqchip/mvebu-pic: Convert to platform remove callback returning void
In-Reply-To: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>
Message-ID: <df977ad4c02ff913b01cdd6c348e7fae3e08e651.1703284359.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/irqchip/irq-mvebu-pic.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-mvebu-pic.c b/drivers/irqchip/irq-mvebu-pic.c
index ef3d3646ccc2..57e3f99b61f5 100644
--- a/drivers/irqchip/irq-mvebu-pic.c
+++ b/drivers/irqchip/irq-mvebu-pic.c
@@ -167,14 +167,12 @@ static int mvebu_pic_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int mvebu_pic_remove(struct platform_device *pdev)
+static void mvebu_pic_remove(struct platform_device *pdev)
 {
 	struct mvebu_pic *pic = platform_get_drvdata(pdev);
 
 	on_each_cpu(mvebu_pic_disable_percpu_irq, pic, 1);
 	irq_domain_remove(pic->domain);
-
-	return 0;
 }
 
 static const struct of_device_id mvebu_pic_of_match[] = {
@@ -185,7 +183,7 @@ MODULE_DEVICE_TABLE(of, mvebu_pic_of_match);
 
 static struct platform_driver mvebu_pic_driver = {
 	.probe  = mvebu_pic_probe,
-	.remove = mvebu_pic_remove,
+	.remove_new = mvebu_pic_remove,
 	.driver = {
 		.name = "mvebu-pic",
 		.of_match_table = mvebu_pic_of_match,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 22 14:50:43 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 22 Dec 2023 23:50:43 +0100
Subject: [PATCH 12/13] irqchip/stm32-exti: Convert to platform remove callback returning void
In-Reply-To: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>
Message-ID: <ac551b89025bafadce05102b94596f8cd3564a32.1703284359.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/irqchip/irq-stm32-exti.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
index 971240e2e31b..c61a97caafc9 100644
--- a/drivers/irqchip/irq-stm32-exti.c
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -898,10 +898,9 @@ static void stm32_exti_remove_irq(void *data)
 	irq_domain_remove(domain);
 }
 
-static int stm32_exti_remove(struct platform_device *pdev)
+static void stm32_exti_remove(struct platform_device *pdev)
 {
 	stm32_exti_h_syscore_deinit();
-	return 0;
 }
 
 static int stm32_exti_probe(struct platform_device *pdev)
@@ -991,7 +990,7 @@ MODULE_DEVICE_TABLE(of, stm32_exti_ids);
 
 static struct platform_driver stm32_exti_driver = {
 	.probe		= stm32_exti_probe,
-	.remove		= stm32_exti_remove,
+	.remove_new	= stm32_exti_remove,
 	.driver		= {
 		.name	= "stm32_exti",
 		.of_match_table = stm32_exti_ids,
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 22 14:50:31 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 22 Dec 2023 23:50:31 +0100
Subject: [PATCH 00/13] irqchip: Convert to platform remove callback returning void
Message-ID: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>

this series converts all drivers below drivers/irqchip to use
.remove_new(). See commit 5c5a7680e67b ("platform: Provide a remove
callback that returns no value") for an extended explanation and the
eventual goal. The TL;DR; is to make it harder for driver authors to
leak resources.

The drivers touched here are all fine though and don't return early in
.remove(). So all conversions in this series are trivial.

Best regards
Uwe

Uwe Kleine-K?nig (13):
  irqchip/imgpdc: Convert to platform remove callback returning void
  irqchip/imx-intmux: Convert to platform remove callback returning void
  irqchip/imx-irqsteer: Convert to platform remove callback returning void
  irqchip/keystone: Convert to platform remove callback returning void
  irqchip/ls-scfg-msi: Convert to platform remove callback returning void
  irqchip/madera: Convert to platform remove callback returning void
  irqchip/mvebu-pic: Convert to platform remove callback returning void
  irqchip/pruss-intc: Convert to platform remove callback returning void
  irqchip/renesas-intc-irqpin: Convert to platform remove callback returning void
  irqchip/renesas-irqc: Convert to platform remove callback returning void
  irqchip/renesas-rza1: Convert to platform remove callback returning void
  irqchip/stm32-exti: Convert to platform remove callback returning void
  irqchip/ts4800: Convert to platform remove callback returning void

 drivers/irqchip/irq-imgpdc.c              | 5 ++---
 drivers/irqchip/irq-imx-intmux.c          | 6 ++----
 drivers/irqchip/irq-imx-irqsteer.c        | 6 ++----
 drivers/irqchip/irq-keystone.c            | 5 ++---
 drivers/irqchip/irq-ls-scfg-msi.c         | 6 ++----
 drivers/irqchip/irq-madera.c              | 6 ++----
 drivers/irqchip/irq-mvebu-pic.c           | 6 ++----
 drivers/irqchip/irq-pruss-intc.c          | 6 ++----
 drivers/irqchip/irq-renesas-intc-irqpin.c | 5 ++---
 drivers/irqchip/irq-renesas-irqc.c        | 5 ++---
 drivers/irqchip/irq-renesas-rza1.c        | 5 ++---
 drivers/irqchip/irq-stm32-exti.c          | 5 ++---
 drivers/irqchip/irq-ts4800.c              | 6 ++----
 13 files changed, 26 insertions(+), 46 deletions(-)

base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 22 14:50:34 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 22 Dec 2023 23:50:34 +0100
Subject: [PATCH 03/13] irqchip/imx-irqsteer: Convert to platform remove callback returning void
In-Reply-To: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>
Message-ID: <c0e5afe62256860150d25bcf644f2b8d62794c86.1703284359.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/irqchip/irq-imx-irqsteer.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-imx-irqsteer.c b/drivers/irqchip/irq-imx-irqsteer.c
index bd9543314539..05f6b5e8370d 100644
--- a/drivers/irqchip/irq-imx-irqsteer.c
+++ b/drivers/irqchip/irq-imx-irqsteer.c
@@ -231,7 +231,7 @@ static int imx_irqsteer_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int imx_irqsteer_remove(struct platform_device *pdev)
+static void imx_irqsteer_remove(struct platform_device *pdev)
 {
 	struct irqsteer_data *irqsteer_data = platform_get_drvdata(pdev);
 	int i;
@@ -243,8 +243,6 @@ static int imx_irqsteer_remove(struct platform_device *pdev)
 	irq_domain_remove(irqsteer_data->domain);
 
 	clk_disable_unprepare(irqsteer_data->ipg_clk);
-
-	return 0;
 }
 
 #ifdef CONFIG_PM
@@ -312,6 +310,6 @@ static struct platform_driver imx_irqsteer_driver = {
 		.pm = &imx_irqsteer_pm_ops,
 	},
 	.probe = imx_irqsteer_probe,
-	.remove = imx_irqsteer_remove,
+	.remove_new = imx_irqsteer_remove,
 };
 builtin_platform_driver(imx_irqsteer_driver);
-- 
2.42.0



From u.kleine-koenig at pengutronix.de  Fri Dec 22 14:50:33 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri, 22 Dec 2023 23:50:33 +0100
Subject: [PATCH 02/13] irqchip/imx-intmux: Convert to platform remove callback returning void
In-Reply-To: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>
Message-ID: <edeee074956dd943d3c67da894a01dc5f0d33bd7.1703284359.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/irqchip/irq-imx-intmux.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-imx-intmux.c b/drivers/irqchip/irq-imx-intmux.c
index aa041e4dfee0..de292bde058f 100644
--- a/drivers/irqchip/irq-imx-intmux.c
+++ b/drivers/irqchip/irq-imx-intmux.c
@@ -282,7 +282,7 @@ static int imx_intmux_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int imx_intmux_remove(struct platform_device *pdev)
+static void imx_intmux_remove(struct platform_device *pdev)
 {
 	struct intmux_data *data = platform_get_drvdata(pdev);
 	int i;
@@ -298,8 +298,6 @@ static int imx_intmux_remove(struct platform_device *pdev)
 	}
 
 	pm_runtime_disable(&pdev->dev);
-
-	return 0;
 }
 
 #ifdef CONFIG_PM
@@ -359,6 +357,6 @@ static struct platform_driver imx_intmux_driver = {
 		.pm = &imx_intmux_pm_ops,
 	},
 	.probe = imx_intmux_probe,
-	.remove = imx_intmux_remove,
+	.remove_new = imx_intmux_remove,
 };
 builtin_platform_driver(imx_intmux_driver);
-- 
2.42.0



From tharvey at gateworks.com  Fri Dec 22 15:40:51 2023
From: tharvey at gateworks.com (Tim Harvey)
Date: Fri, 22 Dec 2023 15:40:51 -0800
Subject: imx7_media_csi probe deferred
In-Reply-To: <CAOMZO5AGLAxeRfya2EJOMghqE5cvqZtqPAz05oMfFJT==F6PvQ@mail.gmail.com>
References: <CAJ+vNU2Kj=a-_xDBsNO5zkyP_mgLsVtA2bXqkAkpmCQmVEA_=w@mail.gmail.com>
 <CAOMZO5CX4xuMvZDMVEND0vpMyuU7ozDm2pk+yVQZAKLenipY_g@mail.gmail.com>
 <CAJ+vNU3FUMBt7WyEJHJFkgjUViTUjS1EgeVt49CcdN7dgtaMfQ@mail.gmail.com> <CAOMZO5AGLAxeRfya2EJOMghqE5cvqZtqPAz05oMfFJT==F6PvQ@mail.gmail.com>
Message-ID: <CAJ+vNU2A38FpZEWapbXFGnHPyq9JUTBFD0CsKZy7L69Koc1pVw@mail.gmail.com>

On Fri, Dec 22, 2023 at 12:57?PM Fabio Estevam <festevam at gmail.com> wrote:
>
> On Fri, Dec 22, 2023 at 5:51?PM Tim Harvey <tharvey at gateworks.com> wrote:
>
> > Fabio,
> >
> > Thanks for testing. Is this with arch/arm64/defconfig?
>
> I modified arch/arm64/defconfig to only build for NXP i.MX.
>
> The resultant defconfig is this one:
> https://pastebin.com/raw/6dFx3tfp

Fabio,

Interesting... when I avoid using the dt overlay it works fine. There
is something wrong with my overlay - the phandle from the sensor at 10
node was missing.

When comparing the output of 'dtc -I fs -O dts
/sys/firmware/devicetree/base' between booting with my overlay vs
booting with the contents of the overlay merged into the base file I
the following diffs:
$ diff /tmp/good.dts /tmp/bad.dts
266a267,269
> <stdout>: Warning (graph_endpoint): /soc at 0/bus at 32c00000/csi at 32e20000/port/endpoint:remote-endpoint: graph phandle is not valid
> <stdout>: Warning (graph_endpoint): /soc at 0/bus at 32c00000/mipi-csi at 32e30000/ports/port at 1/endpoint: graph connection to node '/soc at 0/bus at 32c00000/csi at 32e20000/port/endpoint' is not bidirectional
> <stdout>: Warning (graph_endpoint): /soc at 0/bus at 32c00000/csi at 32e20000/port/endpoint:remote-endpoint: graph phandle is not valid
941a945
> phandle = <0xaa>;
1711c1715
< phandle = <0x45>;
---
> phandle = <0xab>;
2461a2466
> imx219 = "/soc at 0/bus at 30800000/i2c at 30a40000/sensor at 10";
2524a2530
> imx8mm_mipi_csi_in = "/soc at 0/bus at 32c00000/mipi-csi at 32e30000/ports/port at 0/endpoint";
2543a2550
> cam24m = "/cam24m";
2560a2568
> imx219_to_mipi_csi2 = "/soc at 0/bus at 30800000/i2c at 30a40000/sensor at 10/port/endpoint";
2569a2578
> reg_cam = "/regulator-cam";
2572a2582
> pinctrl_reg_cam = "/soc at 0/bus at 30000000/pinctrl at 30330000/regcamgrp";

Not very fun trying to debug this. I'm not sure where exactly a
warning could go that would help show the problem.

With initcall_debug added and manually probing the drivers to help
isolate the messages:
# modprobe imx219
[ 1163.785027] calling  v4l2_async_init+0x0/0x1000 [v4l2_async] @ 627
[ 1163.791401] initcall v4l2_async_init+0x0/0x1000 [v4l2_async]
returned 0 after 44 usecs
[ 1163.808005] calling  imx219_i2c_driver_init+0x0/0x1000 [imx219] @ 627
[ 1163.814693] imx219 2-0010: supply VANA not found, using dummy regulator
[ 1163.821625] imx219 2-0010: supply VDDL not found, using dummy regulator
[ 1163.837185] probe of 2-0010 returned 0 after 22594 usecs
[ 1163.842614] initcall imx219_i2c_driver_init+0x0/0x1000 [imx219]
returned 0 after 28094 usecs
^^ no problems here with the imx219 camera sensor

# modprobe imx_mipi_csis
[ 1207.488915] calling  mipi_csis_driver_init+0x0/0x1000 [imx_mipi_csis] @ 633
[ 1207.496401] probe of 32e30000.mipi-csi returned -517 after 24 usecs
[ 1207.502884] initcall mipi_csis_driver_init+0x0/0x1000
[imx_mipi_csis] returned 0 after 6866 usecs
^^^ the -517 (EPROBE_DEFER) here shows a problem but its not clear why it defers

# modprobe imx7_media_csi
[ 1214.345573] calling  imx7_csi_driver_init+0x0/0x1000 [imx7_media_csi] @ 636
[ 1214.353170] imx-pgc imx-pgc-domain.10: imx_pgc_power_up dispmix
[ 1214.359185] imx-pgc imx-pgc-domain.10: imx_pgc_power_up dispmix ok
[ 1214.365424] imx7_csi_probe
[ 1214.368532] imx7-csi 32e20000.csi: Registered csi capture as /dev/video2
[ 1214.375688] imx7-csi 32e20000.csi: error -ENOTCONN: Failed to get
remote endpoint
[ 1214.383250] imx7_csi_probe async_register failed -107
[ 1214.388643] imx7-csi: probe of 32e20000.csi failed with error -107
[ 1214.394913] imx-pgc imx-pgc-domain.10: imx_pgc_power_down dispmix
[ 1214.396068] probe of 32e20000.csi returned 107 after 42995 usecs
[ 1214.401065] imx-pgc imx-pgc-domain.10: imx_pgc_power_down dispmix ok
[ 1214.414034] initcall imx7_csi_driver_init+0x0/0x1000
[imx7_media_csi] returned 0 after 61350 usecs
^^^ the ENOTCONN here is due to imx_mipi_csis being deferred

The whole problem appears to be because I was using 'make
DTC_FLAGS="-@" dtbs' in my build script because my previous kernel
version required the DTC_FLAG for overlays and now apparently not only
is it no longer required it causes an issue.

Thanks for the testing, and thanks Stefan for the suggestion of adding
initcall_debug - they both helped me down the right path to
understanding this issue.

Best Regards,

Tim


From peng.fan at nxp.com  Fri Dec 22 18:14:08 2023
From: peng.fan at nxp.com (Peng Fan)
Date: Sat, 23 Dec 2023 02:14:08 +0000
Subject: [PATCH 7/7] pinctrl: scmi: implement
 pinctrl_scmi_imx_dt_node_to_map
In-Reply-To: <ZYXK2YVJ1nnETSuI@pluto>
References: <20231215-pinctrl-scmi-v1-0-0fe35e4611f7@nxp.com>
 <20231215-pinctrl-scmi-v1-7-0fe35e4611f7@nxp.com> <ZYXK2YVJ1nnETSuI@pluto>
Message-ID: <DU0PR04MB9417FAE597ACB2B72DC446F6889BA@DU0PR04MB9417.eurprd04.prod.outlook.com>

> Subject: Re: [PATCH 7/7] pinctrl: scmi: implement
> pinctrl_scmi_imx_dt_node_to_map
> 
> On Fri, Dec 15, 2023 at 07:56:35PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan at nxp.com>
> >
> > i.MX95 System Manager FW supports SCMI PINCTRL protocol, but uses
> OEM
> > Pin Configuration type, so need i.MX specific dt_node_to_map.
> >
> 
> This does not even compile for me, as of now, when configuring the Pinctrl
> SCMI driver as a module with your IMX custom additions. (I think the
> Makefile with the additional pinctrl-imx is wrong in how describes the objects
> composing the pinctrl-scmi module with IMX addons...)
> 
> ERROR: modpost: "pinctrl_scmi_imx_dt_node_to_map"
> [drivers/pinctrl/pinctrl-scmi.ko] undefined!
> make[3]: *** [dev/src/linux/scripts/Makefile.modpost:145: Module.symvers]
> Error 1
> make[2]: *** [dev/src/linux/Makefile:1863: modpost] Error 2
> make[1]: *** [dev/src/linux/Makefile:234: __sub-make] Error 2
> make[1]: Leaving directory dev/out_linux
> make: *** [Makefile:234: __sub-make] Error 2

Oh, sorry for this. I could post a new version if you require. But before
that we may better align on the approach on how to support i.MX.

> 
> More in general, I think that this NXP OEM specific additions, which are in
> general welcome (and indeed as you know part of the spec was modified to
> allow for OEM specific needs), do NOT belong to this generic SCMI Pinctrl
> driver, because the driver from Oleksii/EPAM was born as a generic SCMI
> driver and it fits perfectly with the Generic Pinctrl Linux subsystem and
> related generic bindings parsing: now with this you are trying to stick a
> custom OEM slight varied behaviour (and related binding) on top of a generic
> thing.
> 
> And this choice leads to a number of additional changes in the SCMI core to
> support an even more complex handling of SCMI devices, which is already too
> complex IMO..
> 
> IOW...I dont think that the whole idea of the per-protocol optional
> compatible to be able to select slightly different behaviours/parsing would
> have a great chance to fly sincerely...
> 
> I know there is an issue with having a completely distinct SCMI IMX pinctrl
> driver that uses the same protocol node @19 (without the need for the
> compatible trick) due to the way in which the Pinctrl subsystem searches for
> devices (by of_node)...I'll think about an alternative way to allow this but I am
> not sure (as you saw) that would be so easily doable...

For all protocols supports VENDOR extension attributes, we need a way
to handle I think. 

As Linus wrote in
https://lore.kernel.org/all/CACRpkdaRY+rU+md-r5gVyFH5ATt3Pqp9=M4=+WArYkfVLAFdpw at mail.gmail.com/:

We may need:
protocol at 19 {
    compatible = "vendor,soc-scmi-pinctrl";
(...)

> 
> Also, I am wondering if this is really a problem in reality since I would NOT
> expect you to load/ship both the OEM/NXP custom specific SCMI pinctrl
> driver AND the generic one on the same platform (after having made them
> distinct I mean...) am I wrong ?

You are right, but that means the upstream ARM64 defconfig will not 
able to support both i.MX9 and others.

Thanks,
Peng.

> (so you could even made them exclude each other at compile time...far from
> being the best option I agree...)
> 
> Thanks,
> Cristian


From andersson at kernel.org  Fri Dec 22 19:23:19 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Fri, 22 Dec 2023 21:23:19 -0600
Subject: [PATCH] arm64: defconfig: Enable Qualcomm SC8280XP camera clock controller
In-Reply-To: <20231221-enable-sc8280xp-camcc-v1-1-2249581dd538@quicinc.com>
References: <20231221-enable-sc8280xp-camcc-v1-1-2249581dd538@quicinc.com>
Message-ID: <170330179579.491992.7396004534427896998.b4-ty@kernel.org>


On Thu, 21 Dec 2023 20:47:16 -0800, Bjorn Andersson wrote:
> With the camera clock controller added to the DeviceTree of SC8280XP the
> interconnect providers no longer reaches sync_state, resulting in a
> noticeable reduction in battery life.
> 
> Enable the camera clock controller (as a module) to avoid this, and
> hopefully soon provide some level of camera support.
> 
> [...]

Applied, thanks!

[1/1] arm64: defconfig: Enable Qualcomm SC8280XP camera clock controller
      commit: 191fcf77e304392cc330fc19595cb90fd52d595f

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From Frank.li at nxp.com  Fri Dec 22 19:46:29 2023
From: Frank.li at nxp.com (Frank Li)
Date: Fri, 22 Dec 2023 22:46:29 -0500
Subject: [PATCH v5 10/16] dt-bindings: imx6q-pcie: remove reg and reg-name
In-Reply-To: <20231221225033.GA228866-robh@kernel.org>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-11-Frank.Li@nxp.com>
 <20231221225033.GA228866-robh@kernel.org>
Message-ID: <ZYZYFYBr23OtTtrd@lizhi-Precision-Tower-5810>

On Thu, Dec 21, 2023 at 04:50:33PM -0600, Rob Herring wrote:
> On Wed, Dec 20, 2023 at 04:36:09PM -0500, Frank Li wrote:
> > snps,dw-pcie.yaml already have reg and reg-name information. Needn't
> > duplciate here.
> > 
> > Acked-by: Rob Herring <robh at kernel.org>
> > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > ---
> > 
> > Notes:
> >     Change from v4 to v5
> >     - add Rob's Acked
> 
> Err, that was intended for patch 9, not this one. This patch should be 
> dropped.

Sorry, will correct it.

Actually I want to move it under Allof

if compatiable string (A, B, C...)
then
	reg-names:
		-const: dbi
		-const: config

Differece SOC have difference reg-names required list. If split it, it
will be easy when add new SOC. Needn't change two place.

Let me update at next version.


> 
> >     Change from v1 to v4:
> >     - new patch at v4
> > 
> >  .../devicetree/bindings/pci/fsl,imx6q-pcie.yaml        | 10 ----------
> >  1 file changed, 10 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > index 81bbb8728f0f9..f20d4f0e3cb6c 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > @@ -30,16 +30,6 @@ properties:
> >        - fsl,imx8mm-pcie
> >        - fsl,imx8mp-pcie
> >  
> > -  reg:
> > -    items:
> > -      - description: Data Bus Interface (DBI) registers.
> > -      - description: PCIe configuration space region.
> > -
> > -  reg-names:
> > -    items:
> > -      - const: dbi
> > -      - const: config
> > -
> >    clocks:
> >      minItems: 3
> >      items:
> > -- 
> > 2.34.1
> > 


From lkp at intel.com  Fri Dec 22 22:54:38 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 14:54:38 +0800
Subject: [soc:soc/arm 5/5] arch/arm/kernel/perf_event_v6.c:455:13: warning:
 'armv6mpcore_pmu_disable_event' defined but not used
Message-ID: <202312231434.wNbFQ3Bx-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/arm
head:   2560cffd2134c2e070dee369b37f6e55438087f9
commit: 2560cffd2134c2e070dee369b37f6e55438087f9 [5/5] ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support
config: arm-allmodconfig (https://download.01.org/0day-ci/archive/20231223/202312231434.wNbFQ3Bx-lkp at intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231223/202312231434.wNbFQ3Bx-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312231434.wNbFQ3Bx-lkp at intel.com/

All warnings (new ones prefixed by >>):

   arch/arm/kernel/perf_event_v6.c:83:51: warning: initialized field overwritten [-Woverride-init]
      83 |         [PERF_COUNT_HW_STALLED_CYCLES_BACKEND]  = ARMV6_PERFCTR_LSU_FULL_STALL,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:83:51: note: (near initialization for 'armv6_perf_map[8]')
   arch/arm/kernel/perf_event_v6.c:96:51: warning: initialized field overwritten [-Woverride-init]
      96 |         [C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]  = ARMV6_PERFCTR_DCACHE_ACCESS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:96:51: note: (near initialization for 'armv6_perf_cache_map[0][0][0]')
   arch/arm/kernel/perf_event_v6.c:97:51: warning: initialized field overwritten [-Woverride-init]
      97 |         [C(L1D)][C(OP_READ)][C(RESULT_MISS)]    = ARMV6_PERFCTR_DCACHE_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:97:51: note: (near initialization for 'armv6_perf_cache_map[0][0][1]')
   arch/arm/kernel/perf_event_v6.c:98:51: warning: initialized field overwritten [-Woverride-init]
      98 |         [C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV6_PERFCTR_DCACHE_ACCESS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:98:51: note: (near initialization for 'armv6_perf_cache_map[0][1][0]')
   arch/arm/kernel/perf_event_v6.c:99:51: warning: initialized field overwritten [-Woverride-init]
      99 |         [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]   = ARMV6_PERFCTR_DCACHE_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:99:51: note: (near initialization for 'armv6_perf_cache_map[0][1][1]')
   arch/arm/kernel/perf_event_v6.c:101:51: warning: initialized field overwritten [-Woverride-init]
     101 |         [C(L1I)][C(OP_READ)][C(RESULT_MISS)]    = ARMV6_PERFCTR_ICACHE_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:101:51: note: (near initialization for 'armv6_perf_cache_map[1][0][1]')
   arch/arm/kernel/perf_event_v6.c:109:51: warning: initialized field overwritten [-Woverride-init]
     109 |         [C(DTLB)][C(OP_READ)][C(RESULT_MISS)]   = ARMV6_PERFCTR_DTLB_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:109:51: note: (near initialization for 'armv6_perf_cache_map[3][0][1]')
   arch/arm/kernel/perf_event_v6.c:110:51: warning: initialized field overwritten [-Woverride-init]
     110 |         [C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]  = ARMV6_PERFCTR_DTLB_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:110:51: note: (near initialization for 'armv6_perf_cache_map[3][1][1]')
   arch/arm/kernel/perf_event_v6.c:112:51: warning: initialized field overwritten [-Woverride-init]
     112 |         [C(ITLB)][C(OP_READ)][C(RESULT_MISS)]   = ARMV6_PERFCTR_ITLB_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:112:51: note: (near initialization for 'armv6_perf_cache_map[4][0][1]')
   arch/arm/kernel/perf_event_v6.c:113:51: warning: initialized field overwritten [-Woverride-init]
     113 |         [C(ITLB)][C(OP_WRITE)][C(RESULT_MISS)]  = ARMV6_PERFCTR_ITLB_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:113:51: note: (near initialization for 'armv6_perf_cache_map[4][1][1]')
   arch/arm/kernel/perf_event_v6.c:146:51: warning: initialized field overwritten [-Woverride-init]
     146 |         [PERF_COUNT_HW_CPU_CYCLES]              = ARMV6MPCORE_PERFCTR_CPU_CYCLES,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:146:51: note: (near initialization for 'armv6mpcore_perf_map[0]')
   arch/arm/kernel/perf_event_v6.c:147:51: warning: initialized field overwritten [-Woverride-init]
     147 |         [PERF_COUNT_HW_INSTRUCTIONS]            = ARMV6MPCORE_PERFCTR_INSTR_EXEC,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:147:51: note: (near initialization for 'armv6mpcore_perf_map[1]')
   arch/arm/kernel/perf_event_v6.c:148:51: warning: initialized field overwritten [-Woverride-init]
     148 |         [PERF_COUNT_HW_BRANCH_INSTRUCTIONS]     = ARMV6MPCORE_PERFCTR_BR_EXEC,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:148:51: note: (near initialization for 'armv6mpcore_perf_map[4]')
   arch/arm/kernel/perf_event_v6.c:149:51: warning: initialized field overwritten [-Woverride-init]
     149 |         [PERF_COUNT_HW_BRANCH_MISSES]           = ARMV6MPCORE_PERFCTR_BR_MISPREDICT,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:149:51: note: (near initialization for 'armv6mpcore_perf_map[5]')
   arch/arm/kernel/perf_event_v6.c:150:51: warning: initialized field overwritten [-Woverride-init]
     150 |         [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = ARMV6MPCORE_PERFCTR_IBUF_STALL,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:150:51: note: (near initialization for 'armv6mpcore_perf_map[7]')
   arch/arm/kernel/perf_event_v6.c:151:51: warning: initialized field overwritten [-Woverride-init]
     151 |         [PERF_COUNT_HW_STALLED_CYCLES_BACKEND]  = ARMV6MPCORE_PERFCTR_LSU_FULL_STALL,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:151:51: note: (near initialization for 'armv6mpcore_perf_map[8]')
   arch/arm/kernel/perf_event_v6.c:159:51: warning: initialized field overwritten [-Woverride-init]
     159 |         [C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]  = ARMV6MPCORE_PERFCTR_DCACHE_RDACCESS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:159:51: note: (near initialization for 'armv6mpcore_perf_cache_map[0][0][0]')
   arch/arm/kernel/perf_event_v6.c:160:51: warning: initialized field overwritten [-Woverride-init]
     160 |         [C(L1D)][C(OP_READ)][C(RESULT_MISS)]    = ARMV6MPCORE_PERFCTR_DCACHE_RDMISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:160:51: note: (near initialization for 'armv6mpcore_perf_cache_map[0][0][1]')
   arch/arm/kernel/perf_event_v6.c:161:51: warning: initialized field overwritten [-Woverride-init]
     161 |         [C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV6MPCORE_PERFCTR_DCACHE_WRACCESS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:161:51: note: (near initialization for 'armv6mpcore_perf_cache_map[0][1][0]')
   arch/arm/kernel/perf_event_v6.c:162:51: warning: initialized field overwritten [-Woverride-init]
     162 |         [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]   = ARMV6MPCORE_PERFCTR_DCACHE_WRMISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:162:51: note: (near initialization for 'armv6mpcore_perf_cache_map[0][1][1]')
   arch/arm/kernel/perf_event_v6.c:164:51: warning: initialized field overwritten [-Woverride-init]
     164 |         [C(L1I)][C(OP_READ)][C(RESULT_MISS)]    = ARMV6MPCORE_PERFCTR_ICACHE_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:164:51: note: (near initialization for 'armv6mpcore_perf_cache_map[1][0][1]')
   arch/arm/kernel/perf_event_v6.c:172:51: warning: initialized field overwritten [-Woverride-init]
     172 |         [C(DTLB)][C(OP_READ)][C(RESULT_MISS)]   = ARMV6MPCORE_PERFCTR_DTLB_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:172:51: note: (near initialization for 'armv6mpcore_perf_cache_map[3][0][1]')
   arch/arm/kernel/perf_event_v6.c:173:51: warning: initialized field overwritten [-Woverride-init]
     173 |         [C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]  = ARMV6MPCORE_PERFCTR_DTLB_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:173:51: note: (near initialization for 'armv6mpcore_perf_cache_map[3][1][1]')
   arch/arm/kernel/perf_event_v6.c:175:51: warning: initialized field overwritten [-Woverride-init]
     175 |         [C(ITLB)][C(OP_READ)][C(RESULT_MISS)]   = ARMV6MPCORE_PERFCTR_ITLB_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:175:51: note: (near initialization for 'armv6mpcore_perf_cache_map[4][0][1]')
   arch/arm/kernel/perf_event_v6.c:176:51: warning: initialized field overwritten [-Woverride-init]
     176 |         [C(ITLB)][C(OP_WRITE)][C(RESULT_MISS)]  = ARMV6MPCORE_PERFCTR_ITLB_MISS,
         |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/perf_event_v6.c:176:51: note: (near initialization for 'armv6mpcore_perf_cache_map[4][1][1]')
>> arch/arm/kernel/perf_event_v6.c:455:13: warning: 'armv6mpcore_pmu_disable_event' defined but not used [-Wunused-function]
     455 | static void armv6mpcore_pmu_disable_event(struct perf_event *event)
         |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> arch/arm/kernel/perf_event_v6.c:154:23: warning: 'armv6mpcore_perf_cache_map' defined but not used [-Wunused-const-variable=]
     154 | static const unsigned armv6mpcore_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
         |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
>> arch/arm/kernel/perf_event_v6.c:144:23: warning: 'armv6mpcore_perf_map' defined but not used [-Wunused-const-variable=]
     144 | static const unsigned armv6mpcore_perf_map[PERF_COUNT_HW_MAX] = {
         |                       ^~~~~~~~~~~~~~~~~~~~


vim +/armv6mpcore_pmu_disable_event +455 arch/arm/kernel/perf_event_v6.c

43eab87828fee6 Will Deacon  2010-11-13  454  
ed6f2a522398c2 Sudeep Holla 2012-07-30 @455  static void armv6mpcore_pmu_disable_event(struct perf_event *event)
43eab87828fee6 Will Deacon  2010-11-13  456  {
43eab87828fee6 Will Deacon  2010-11-13  457  	unsigned long val, mask, flags, evt = 0;
ed6f2a522398c2 Sudeep Holla 2012-07-30  458  	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
ed6f2a522398c2 Sudeep Holla 2012-07-30  459  	struct hw_perf_event *hwc = &event->hw;
11679250860700 Mark Rutland 2014-05-13  460  	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
ed6f2a522398c2 Sudeep Holla 2012-07-30  461  	int idx = hwc->idx;
43eab87828fee6 Will Deacon  2010-11-13  462  
43eab87828fee6 Will Deacon  2010-11-13  463  	if (ARMV6_CYCLE_COUNTER == idx) {
43eab87828fee6 Will Deacon  2010-11-13  464  		mask	= ARMV6_PMCR_CCOUNT_IEN;
43eab87828fee6 Will Deacon  2010-11-13  465  	} else if (ARMV6_COUNTER0 == idx) {
43eab87828fee6 Will Deacon  2010-11-13  466  		mask	= ARMV6_PMCR_COUNT0_IEN;
43eab87828fee6 Will Deacon  2010-11-13  467  	} else if (ARMV6_COUNTER1 == idx) {
43eab87828fee6 Will Deacon  2010-11-13  468  		mask	= ARMV6_PMCR_COUNT1_IEN;
43eab87828fee6 Will Deacon  2010-11-13  469  	} else {
43eab87828fee6 Will Deacon  2010-11-13  470  		WARN_ONCE(1, "invalid counter number (%d)\n", idx);
43eab87828fee6 Will Deacon  2010-11-13  471  		return;
43eab87828fee6 Will Deacon  2010-11-13  472  	}
43eab87828fee6 Will Deacon  2010-11-13  473  
43eab87828fee6 Will Deacon  2010-11-13  474  	/*
43eab87828fee6 Will Deacon  2010-11-13  475  	 * Unlike UP ARMv6, we don't have a way of stopping the counters. We
43eab87828fee6 Will Deacon  2010-11-13  476  	 * simply disable the interrupt reporting.
43eab87828fee6 Will Deacon  2010-11-13  477  	 */
0f78d2d5ccf72e Mark Rutland 2011-04-28  478  	raw_spin_lock_irqsave(&events->pmu_lock, flags);
43eab87828fee6 Will Deacon  2010-11-13  479  	val = armv6_pmcr_read();
43eab87828fee6 Will Deacon  2010-11-13  480  	val &= ~mask;
43eab87828fee6 Will Deacon  2010-11-13  481  	val |= evt;
43eab87828fee6 Will Deacon  2010-11-13  482  	armv6_pmcr_write(val);
0f78d2d5ccf72e Mark Rutland 2011-04-28  483  	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
43eab87828fee6 Will Deacon  2010-11-13  484  }
43eab87828fee6 Will Deacon  2010-11-13  485  

:::::: The code at line 455 was first introduced by commit
:::::: ed6f2a522398c26559f4da23a80aa6195e6284c7 ARM: perf: consistently use struct perf_event in arm_pmu functions

:::::: TO: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha at arm.com>
:::::: CC: Will Deacon <will.deacon at arm.com>

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Fri Dec 22 23:36:37 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 15:36:37 +0800
Subject: [PATCH v2 3/4] drm/mediatek: dsi: Use bitfield macros where
 useful
In-Reply-To: <20231220135722.192080-4-angelogioacchino.delregno@collabora.com>
References: <20231220135722.192080-4-angelogioacchino.delregno@collabora.com>
Message-ID: <202312231512.ioiD48LA-lkp@intel.com>

Hi AngeloGioacchino,

kernel test robot noticed the following build errors:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc6 next-20231222]
[cannot apply to drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/AngeloGioacchino-Del-Regno/drm-mediatek-dsi-Use-GENMASK-for-register-mask-definitions/20231222-164513
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:    https://lore.kernel.org/r/20231220135722.192080-4-angelogioacchino.delregno%40collabora.com
patch subject: [PATCH v2 3/4] drm/mediatek: dsi: Use bitfield macros where useful
config: arm-allmodconfig (https://download.01.org/0day-ci/archive/20231223/202312231512.ioiD48LA-lkp at intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231223/202312231512.ioiD48LA-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312231512.ioiD48LA-lkp at intel.com/

All errors (new ones prefixed by >>):

   drivers/gpu/drm/mediatek/mtk_dsi.c: In function 'mtk_dsi_phy_timconfig':
>> drivers/gpu/drm/mediatek/mtk_dsi.c:260:19: error: implicit declaration of function 'FIELD_PREP' [-Werror=implicit-function-declaration]
     260 |         timcon0 = FIELD_PREP(LPX, timing->lpx) |
         |                   ^~~~~~~~~~
   cc1: some warnings being treated as errors


vim +/FIELD_PREP +260 drivers/gpu/drm/mediatek/mtk_dsi.c

   236	
   237	static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
   238	{
   239		u32 timcon0, timcon1, timcon2, timcon3;
   240		u32 data_rate_mhz = DIV_ROUND_UP(dsi->data_rate, 1000000);
   241		struct mtk_phy_timing *timing = &dsi->phy_timing;
   242	
   243		timing->lpx = (60 * data_rate_mhz / (8 * 1000)) + 1;
   244		timing->da_hs_prepare = (80 * data_rate_mhz + 4 * 1000) / 8000;
   245		timing->da_hs_zero = (170 * data_rate_mhz + 10 * 1000) / 8000 + 1 -
   246				     timing->da_hs_prepare;
   247		timing->da_hs_trail = timing->da_hs_prepare + 1;
   248	
   249		timing->ta_go = 4 * timing->lpx - 2;
   250		timing->ta_sure = timing->lpx + 2;
   251		timing->ta_get = 4 * timing->lpx;
   252		timing->da_hs_exit = 2 * timing->lpx + 1;
   253	
   254		timing->clk_hs_prepare = 70 * data_rate_mhz / (8 * 1000);
   255		timing->clk_hs_post = timing->clk_hs_prepare + 8;
   256		timing->clk_hs_trail = timing->clk_hs_prepare;
   257		timing->clk_hs_zero = timing->clk_hs_trail * 4;
   258		timing->clk_hs_exit = 2 * timing->clk_hs_trail;
   259	
 > 260		timcon0 = FIELD_PREP(LPX, timing->lpx) |
   261			  FIELD_PREP(HS_PREP, timing->da_hs_prepare) |
   262			  FIELD_PREP(HS_ZERO, timing->da_hs_zero) |
   263			  FIELD_PREP(HS_TRAIL, timing->da_hs_trail);
   264	
   265		timcon1 = FIELD_PREP(TA_GO, timing->ta_go) |
   266			  FIELD_PREP(TA_SURE, timing->ta_sure) |
   267			  FIELD_PREP(TA_GET, timing->ta_get) |
   268			  FIELD_PREP(DA_HS_EXIT, timing->da_hs_exit);
   269	
   270		timcon2 = FIELD_PREP(DA_HS_SYNC, 1) |
   271			  FIELD_PREP(CLK_ZERO, timing->clk_hs_zero) |
   272			  FIELD_PREP(CLK_TRAIL, timing->clk_hs_trail);
   273	
   274		timcon3 = FIELD_PREP(CLK_HS_PREP, timing->clk_hs_prepare) |
   275			  FIELD_PREP(CLK_HS_POST, timing->clk_hs_post) |
   276			  FIELD_PREP(CLK_HS_EXIT, timing->clk_hs_exit);
   277	
   278		writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
   279		writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
   280		writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
   281		writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
   282	}
   283	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From u.kleine-koenig at pengutronix.de  Fri Dec 22 23:59:07 2023
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Sat, 23 Dec 2023 08:59:07 +0100
Subject: [PATCH] serial: imx: Correct clock error message in function
 probe()
In-Reply-To: <20231222220216.2188-1-cniedermaier@dh-electronics.com>
References: <20231222220216.2188-1-cniedermaier@dh-electronics.com>
Message-ID: <i3pzwocqgiqywcw2wj3q6oziofpivmmgsfqkaehsbt5ng2iehn@7zwfo7pke4wb>

Hello,

On Fri, Dec 22, 2023 at 11:02:16PM +0100, Christoph Niedermaier wrote:
> Correct the clock error message by changing the clock name.
> 
> Signed-off-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>

Fixes: 1e512d45332b ("serial: imx: add error messages when .probe fails")
Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231223/8cdd67dd/attachment-0001.sig>

From danct12 at riseup.net  Sat Dec 23 01:48:16 2023
From: danct12 at riseup.net (Dang Huynh)
Date: Sat, 23 Dec 2023 09:48:16 +0000
Subject: [PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2
In-Reply-To: <20231222-pinetab2-v1-4-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-4-e148a7f61bd1@mecka.net>
Message-ID: <5102022.LvFx2qVVIh@melttower>

On Friday, December 22, 2023 11:05:44 AM UTC Manuel Traut wrote:
> From: Segfault <awarnecke002 at hotmail.com>
Using nickname is not allowed:
https://www.kernel.org/doc/html/v6.6/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> 
> This includes support for both the v0.1 units that were sent to developers
> and the v2.0 units from production.
> 
> v1.0 is not included as no units are known to exist.
> 
> Working/Tested:
> - SDMMC
> - UART
> - Buttons
> - Charging/Battery/PMIC
> - Audio
> - USB
> - Display
> 
> WiFi is not added, since the driver is not ready for mainline.
> 
> Signed-off-by: Segfault <awarnecke002 at hotmail.com>
> Signed-off-by: Manuel Traut <manut at mecka.net>
> ---
>  arch/arm64/boot/dts/rockchip/Makefile              |    2 +
>  .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts     |   26 +
>  .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts     |   46 +
>  arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi  | 1032
> ++++++++++++++++++++ 4 files changed, 1106 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile index a18f33bf0c0e..ef66c0937a9b
> 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -77,6 +77,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v0.1.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v2.0.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts new file mode
> 100644
> index 000000000000..ba244545ba26
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
Not sure if this is needed but there's no copyright header here (same with other files in this patch)
> +
> +/dts-v1/;
> +
> +#include "rk3566-pinetab2.dtsi"
> +
> +/ {
> +	model = "Pine64 PineTab2 v0.1";
> +	compatible = "pine64,pinetab2-v0.1", "pine64,pinetab2", "rockchip,rk3566";
> +};
> +
> +&lcd {
> +	reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
> +};
> +
> +&pinctrl {
> +	display {
> +		lcd0_rst_l: lcd0-rst-l {
> +			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&vcc_wl {
> +	gpio = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>;
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts new file mode
> 100644
> index 000000000000..f401ff802175
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3566-pinetab2.dtsi"
> +
> +/ {
> +	model = "Pine64 PineTab2 v2.0";
> +	compatible = "pine64,pinetab2-v2.0", "pine64,pinetab2", "rockchip,rk3566";
> +};
> +
> +&gpio_keys {
> +	pinctrl-0 = <&kb_id_det>, <&hall_int_l>;
> +
> +	event-hall-sensor {
> +		debounce-interval = <20>;
> +		gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
> +		label = "Hall Sensor";
> +		linux,code = <SW_LID>;
> +		linux,input-type = <EV_SW>;
> +		wakeup-event-action = <EV_ACT_DEASSERTED>;
> +		wakeup-source;
> +	};
> +};
> +
> +&lcd {
> +	reset-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_LOW>;
> +};
> +
> +&pinctrl {
> +	display {
> +		lcd0_rst_l: lcd0-rst-l {
> +			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	hall {
> +		hall_int_l: hall-int-l {
> +			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&vcc_wl {
> +	gpio = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi new file mode 100644
> index 000000000000..6d320cfee338
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> @@ -0,0 +1,1032 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/gpio-keys.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/soc/rockchip,vop2.h>
> +#include <dt-bindings/usb/pd.h>
> +#include "rk3566.dtsi"
> +
> +/ {
> +	chassis-type = "tablet";
> +
> +	aliases {
> +		mmc0 = &sdmmc0;
> +		mmc1 = &sdhci;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial2:1500000n8";
> +	};
> +
> +	adc-keys {
> +		compatible = "adc-keys";
> +		io-channels = <&saradc 0>;
> +		io-channel-names = "buttons";
> +		keyup-threshold-microvolt = <1800000>;
> +		poll-interval = <25>;
> +
> +		button-vol-up {
> +			label = "Volume Up";
> +			linux,code = <KEY_VOLUMEUP>;
> +			press-threshold-microvolt = <297500>;
> +		};
> +
> +		button-vol-down {
> +			label = "Volume Down";
> +			linux,code = <KEY_VOLUMEDOWN>;
> +			press-threshold-microvolt = <1750>;
> +		};
> +	};
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm4 0 25000 0>;
> +		brightness-levels = <20 220>;
> +		num-interpolated-steps = <200>;
> +		default-brightness-level = <100>;
> +		power-supply = <&vcc_sys>;
> +	};
> +
> +	battery: battery {
> +		compatible = "simple-battery";
> +		charge-full-design-microamp-hours = <6000000>;
> +		charge-term-current-microamp = <300000>;
> +		constant-charge-current-max-microamp = <2000000>;
> +		constant-charge-voltage-max-microvolt = <4300000>;
> +		voltage-max-design-microvolt = <4350000>;
> +		voltage-min-design-microvolt = <3400000>;
> +
> +		ocv-capacity-celsius = <20>;
> +		ocv-capacity-table-0 = <4322000 100>, <4250000 95>, <4192000 90>,
> <4136000 85>, +				       <4080000 80>, <4022000 75>, <3972000 70>,
> <3928000 65>, +				       <3885000 60>, <3833000 55>, <3798000 50>,
> <3780000 45>, +				       <3776000 40>, <3773000 35>, <3755000 30>,
> <3706000 25>, +				       <3640000 20>, <3589000 15>, <3535000 10>,
> <3492000 5>, +				       <3400000 0>;
> +	};
> +
> +	gpio_keys: gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&kb_id_det>;
> +
> +		tablet-mode-switch {
> +			debounce-interval = <20>;
> +			gpios = <&gpio4 RK_PA4 GPIO_ACTIVE_HIGH>;
> +			label = "Tablet Mode";
> +			linux,input-type = <EV_SW>;
> +			linux,code = <SW_TABLET_MODE>;
> +		};
> +	};
> +
> +	hdmi-con {
> +		compatible = "hdmi-connector";
> +		type = "d";
> +
> +		port {
> +			hdmi_con_in: endpoint {
> +				remote-endpoint = <&hdmi_out_con>;
> +			};
> +		};
> +	};
> +
> +	led-flash {
> +		compatible = "regulator-led";
> +		vled-supply = <&led_flash_reg>;
> +		function = LED_FUNCTION_FLASH;
> +		color = <LED_COLOR_ID_WHITE>;
> +	};
> +
> +	led_flash_reg: led-flash-reg {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&flash_led_en_h>;
> +		regulator-name = "led_flash_reg";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v_midu>;
> +	};
> +
> +	rk817-sound {
> +		compatible = "simple-audio-card";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&hp_det_l>;
> +		simple-audio-card,format = "i2s";
> +		simple-audio-card,name = "PineTab2";
> +		simple-audio-card,mclk-fs = <256>;
> +
> +		simple-audio-card,widgets =
> +			"Microphone", "Mic Jack",
> +			"Headphone", "Headphones",
> +			"Microphone", "Microphone",
> +			"Speaker", "Speakers";
> +
> +		simple-audio-card,routing =
> +			"MICL", "Microphone",
> +			"MICR", "Mic Jack",
> +			"Headphones", "HPOL",
> +			"Headphones", "HPOR",
> +			"Speaker Amplifier INL", "HPOL",
> +			"Speaker Amplifier INR", "HPOR",
> +			"Speakers", "Speaker Amplifier OUTL",
> +			"Speakers", "Speaker Amplifier OUTR";
> +
> +		simple-audio-card,hp-det-gpio = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
> +		simple-audio-card,aux-devs = <&speaker_amp>;
> +		simple-audio-card,pin-switches = "Speakers", "Microphone";
> +
> +		simple-audio-card,cpu {
> +			sound-dai = <&i2s1_8ch>;
> +		};
> +
> +		simple-audio-card,codec {
> +			sound-dai = <&rk817>;
> +		};
> +	};
> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		clocks = <&rk817 1>;
> +		clock-names = "ext_clock";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_reset>;
> +		reset-gpios = <&gpio3 RK_PD2 GPIO_ACTIVE_LOW>;
> +		post-power-on-delay-ms = <200>;
> +	};
> +
> +	speaker_amp: speaker-amplifier {
> +		compatible = "simple-audio-amplifier";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&spk_ctl>;
> +		enable-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_HIGH>;
> +		sound-name-prefix = "Speaker Amplifier";
> +		VCC-supply = <&vcc_bat>;
> +	};
> +
> +	vcc_3v3: vcc_3v3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_3v3";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc3v3_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc3v3_minipcie: vcc3v3_minipcie {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PC3 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pcie_pwren_h>;
> +		regulator-name = "vcc3v3_minipcie";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc3v3_sd: vcc3v3_sd {
> +		compatible = "regulator-fixed";
> +		gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&sdmmc_pwren_l>;
> +		regulator-name = "vcc3v3_sd";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc3v3_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc5v0_usb_host0: vcc5v0_usb_host0 {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PC4 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&usb_host_pwren1_h>;
> +		regulator-name = "vcc5v0_usb_host0";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v_midu>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc5v0_usb_host2: vcc5v0_usb_host2 {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PC5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&usb_host_pwren2_h>;
> +		regulator-name = "vcc5v0_usb_host2";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v_midu>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc_bat: vcc_bat {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_bat";
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +
> +	vcc_sys: vcc_sys {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vcc_bat>;
> +	};
> +
> +	vcc_wl: vcc_wl {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_pwren>;
> +		regulator-name = "vcc_wl";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc3v3_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vdd1v2_dvp: vdd1v2_dvp {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vdd1v2_dvp";
> +		regulator-min-microvolt = <1200000>;
> +		regulator-max-microvolt = <1200000>;
> +		vin-supply = <&vcc_3v3>;
> +		/*enable-supply = <&vcc2v8_dvp>;*/
> +	};
> +};
> +
> +&combphy1 {
> +	status = "okay";
> +};
> +
> +&combphy2 {
> +	status = "okay";
> +};
> +
> +&cpu0 {
> +	cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cpu1 {
> +	cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cpu2 {
> +	cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cpu3 {
> +	cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cru {
> +	assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>, <&cru PLL_VPLL>;
> +	assigned-clock-rates = <1200000000>, <200000000>, <500000000>;
> +};
> +
> +&csi_dphy {
> +	status = "okay";
> +};
> +
> +&dsi0 {
> +	status = "okay";
> +	clock-master;
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	lcd: panel at 0 {
> +		compatible = "boe,th101mb31ig002-28a";
> +		reg = <0>;
> +		backlight = <&backlight>;
> +		enable-gpios = <&gpio0 RK_PC7 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&lcd_pwren_h &lcd0_rst_l>;
> +		rotation = <90>;
> +		power-supply = <&vcc_3v3>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				panel_in_dsi: endpoint at 0 {
> +					reg = <0>;
> +					remote-endpoint = <&dsi0_out_con>;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&dsi0_in {
> +	dsi0_in_vp1: endpoint {
> +		remote-endpoint = <&vp1_out_dsi0>;
> +	};
> +};
> +
> +&dsi0_out {
> +	dsi0_out_con: endpoint {
> +		remote-endpoint = <&panel_in_dsi>;
> +	};
> +};
> +
> +&dsi_dphy0 {
> +	status = "okay";
> +};
> +
> +&gpu {
> +	mali-supply = <&vdd_gpu_npu>;
> +	status = "okay";
> +};
> +
> +&hdmi {
> +	avdd-0v9-supply = <&vdda_0v9_p>;
> +	avdd-1v8-supply = <&vcc_1v8>;
> +	status = "okay";
> +};
> +
> +&hdmi_in {
> +	hdmi_in_vp0: endpoint {
> +		remote-endpoint = <&vp0_out_hdmi>;
> +	};
> +};
> +
> +&hdmi_out {
> +	hdmi_out_con: endpoint {
> +		remote-endpoint = <&hdmi_con_in>;
> +	};
> +};
> +
> +&hdmi_sound {
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	vdd_cpu: regulator at 1c {
> +		compatible = "tcs,tcs4525";
> +		reg = <0x1c>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu";
> +		regulator-min-microvolt = <800000>;
> +		regulator-max-microvolt = <1150000>;
> +		regulator-ramp-delay = <2300>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vcc_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	rk817: pmic at 20 {
> +		compatible = "rockchip,rk817";
> +		reg = <0x20>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
> +		assigned-clocks = <&cru I2S1_MCLKOUT_TX>;
> +		assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>;
> +		clock-names = "mclk";
> +		clocks = <&cru I2S1_MCLKOUT_TX>;
> +		clock-output-names = "rk808-clkout1", "rk808-clkout2";
> +		#clock-cells = <1>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_int_l>, <&i2s1m0_mclk>;
> +		rockchip,system-power-controller;
> +		#sound-dai-cells = <0>;
> +		wakeup-source;
> +
> +		vcc1-supply = <&vcc_sys>;
> +		vcc2-supply = <&vcc_sys>;
> +		vcc3-supply = <&vcc_sys>;
> +		vcc4-supply = <&vcc_sys>;
> +		vcc5-supply = <&vcc_sys>;
> +		vcc6-supply = <&vcc_sys>;
> +		vcc7-supply = <&vcc_sys>;
> +		vcc8-supply = <&vcc_sys>;
> +		vcc9-supply = <&vcc5v_midu>;
> +
> +		regulators {
> +			vdd_logic: DCDC_REG1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vdd_logic";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_gpu_npu: DCDC_REG2 {
> +				regulator-always-on;
> +				regulator-boot-on;
No need to regulator-always-on and regulator-boot-on here. The panfrost driver should turn it on.
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vdd_gpu_npu";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_ddr: DCDC_REG3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vcc_ddr";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc3v3_sys: DCDC_REG4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vcc3v3_sys";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcca1v8_pmu: LDO_REG1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcca1v8_pmu";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vdda_0v9_p: LDO_REG2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <900000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-name = "vdda_0v9_p";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdda0v9_pmu: LDO_REG3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <900000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-name = "vdda0v9_pmu";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vccio_acodec: LDO_REG4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vccio_acodec";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vccio_sd: LDO_REG5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vccio_sd";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc3v3_pmu: LDO_REG6 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vcc3v3_pmu";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8: LDO_REG7 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc_1v8";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc1v8_dvp: LDO_REG8 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc1v8_dvp";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc2v8_dvp: LDO_REG9 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <2800000>;
> +				regulator-max-microvolt = <2800000>;
> +				regulator-name = "vcc2v8_dvp";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc5v_midu: BOOST {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <5000000>;
> +				regulator-max-microvolt = <5000000>;
> +				regulator-name = "boost";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vbus: OTG_SWITCH {
> +				regulator-min-microvolt = <5000000>;
> +				regulator-max-microvolt = <5000000>;
> +				regulator-name = "otg_switch";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +
> +		charger {
> +			monitored-battery = <&battery>;
> +			rockchip,resistor-sense-micro-ohms = <10000>;
> +			rockchip,sleep-enter-current-microamp = <300000>;
> +			rockchip,sleep-filter-current-microamp = <100000>;
> +		};
> +	};
> +};
> +
> +&i2c1 {
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	touchscreen at 5d {
> +		compatible = "goodix,gt911";
> +		reg = <0x5d>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PB0 IRQ_TYPE_EDGE_FALLING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&tp_int_l_pmuio2>, <&tp_rst_l_pmuio2>;
> +		AVDD28-supply = <&vcc3v3_pmu>;
> +		VDDIO-supply = <&vcca1v8_pmu>;
> +		irq-gpios = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>;
> +		reset-gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_HIGH>;
> +	};
> +};
> +
> +&i2c2 {
> +	clock-frequency = <400000>;
> +	pinctrl-0 = <&i2c2m1_xfer>;
> +	status = "okay";
> +
> +	vcm at c {
> +		compatible = "dongwoon,dw9714";
> +		reg = <0x0c>;
> +		vcc-supply = <&vcc1v8_dvp>;
> +	};
> +
> +	camera at 36 {
> +		compatible = "ovti,ov5648";
> +		reg = <0x36>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&camerab_pdn_l &camerab_rst_l>;
> +
> +		clocks = <&cru CLK_CIF_OUT>;
> +		assigned-clocks = <&cru CLK_CIF_OUT>;
> +		assigned-clock-rates = <24000000>;
> +
> +		avdd-supply = <&vcc2v8_dvp>;
> +		dvdd-supply = <&vdd1v2_dvp>;
> +		dovdd-supply = <&vcc1v8_dvp>;
> +		powerdown-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
> +		reset-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
> +
> +		port {
> +			endpoint {
> +				data-lanes = <1 2>;
> +				remote-endpoint = <0>;
> +				link-frequencies = /bits/ 64 <210000000 168000000>;
> +			};
> +		};
> +	};
> +};
> +
> +&i2c5 {
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	accelerometer at 18 {
> +		compatible = "silan,sc7a20";
> +		reg = <0x18>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gsensor_int_l>;
> +		st,drdy-int-pin = <1>;
> +		vdd-supply = <&vcc_1v8>;
> +		vddio-supply = <&vcc_1v8>;
> +		mount-matrix = "1", "0", "0",
> +			       "0", "0", "1",
> +			       "0", "1", "0";
> +	};
> +};
> +
> +&i2s0_8ch {
> +	status = "okay";
> +};
> +
> +&i2s1_8ch {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2s1m0_sclktx
> +		     &i2s1m0_lrcktx
> +		     &i2s1m0_sdi0
> +		     &i2s1m0_sdo0>;
> +	rockchip,trcm-sync-tx-only;
> +	status = "okay";
> +};
> +
> +&pcie2x1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pcie_reset_h>;
> +	reset-gpios = <&gpio1 RK_PB2 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc3v3_minipcie>;
> +	status = "okay";
> +};
> +
> +&pinctrl {
> +	accelerometer {
> +		gsensor_int_l: gsensor-int-l {
> +			rockchip,pins = <3 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	bluetooth {
> +		bt_wake_host_h: bt-wake-host-h {
> +			rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
> +		};
> +	};
> +
> +	camerab {
> +		camerab_pdn_l: camerab-pdn-l {
> +			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		camerab_rst_l: camerab-rst-l {
> +			rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	cameraf {
> +		cameraf_pdn_l: cameraf-pdn-l {
> +			rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		cameraf_rst_l: cameraf-rst-l {
> +			rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	display {
> +		lcd_pwren_h: lcd-pwren-h {
> +			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	flash {
> +		flash_led_en_h: flash-led-en-h {
> +			rockchip,pins = <4 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	keyboard {
> +		kb_id_det: kb-id-det {
> +			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	pcie {
> +		pcie_pwren_h: pcie-pwren-h {
> +			rockchip,pins = <4 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		pcie_reset_h: pcie-reset-h {
> +			rockchip,pins = <1 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	pmic {
> +		pmic_int_l: pmic-int-l {
> +			rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	sd {
> +		sdmmc_pwren_l: sdmmc-pwren-l {
> +			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	fspi {
> +		fspi_dual_io_pins: fspi-dual-io-pins {
> +			rockchip,pins =
> +				/* fspi_clk */
> +				<1 RK_PD0 1 &pcfg_pull_none>,
> +				/* fspi_cs0n */
> +				<1 RK_PD3 1 &pcfg_pull_none>,
> +				/* fspi_d0 */
> +				<1 RK_PD1 1 &pcfg_pull_none>,
> +				/* fspi_d1 */
> +				<1 RK_PD2 1 &pcfg_pull_none>;
> +		};
> +	};
> +
> +	sound {
> +		hp_det_l: hp-det-l {
> +			rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		spk_ctl: spk-ctl {
> +			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	touchscreen {
> +		tp_int_l_pmuio2: tp-int-l-pmuio2 {
> +			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +
> +		tp_rst_l_pmuio2: tp-rst-l-pmuio2 {
> +			rockchip,pins = <0 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	usb {
> +		usbcc_int_l: usbcc-int-l {
> +			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		usb_host_pwren1_h: usb-host-pwren1-h {
> +			rockchip,pins = <4 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		usb_host_pwren2_h: usb-host-pwren2-h {
> +			rockchip,pins = <4 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	wifi {
> +		host_wake_wl: host-wake-wl {
> +			rockchip,pins = <0 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		wifi_pwren: wifi-pwren {
> +			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		wifi_reg_on_h: wifi-reg-on-h {
> +			rockchip,pins = <0 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		wifi_reset: wifi-reset {
> +			rockchip,pins = <3 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		wifi_wake_host_h: wifi-wake-host-h {
> +			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
> +		};
> +	};
> +};
> +
> +&pmu_io_domains {
> +	pmuio1-supply = <&vcc3v3_pmu>;
> +	pmuio2-supply = <&vcca1v8_pmu>;
> +	vccio1-supply = <&vccio_acodec>;
> +	vccio2-supply = <&vcc_1v8>;
> +	vccio3-supply = <&vccio_sd>;
> +	vccio4-supply = <&vcc_1v8>;
> +	vccio5-supply = <&vcc_1v8>;
> +	vccio6-supply = <&vcc1v8_dvp>;
> +	vccio7-supply = <&vcc_3v3>;
> +	status = "okay";
> +};
> +
> +&pwm4 {
> +	status = "okay";
> +};
> +
> +&saradc {
> +	vref-supply = <&vcc_1v8>;
> +	status = "okay";
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	no-sdio;
> +	no-sd;
> +	non-removable;
> +	max-frequency = <200000000>;
> +	mmc-hs200-1_8v;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&emmc_bus8
> +		     &emmc_clk
> +		     &emmc_cmd
> +		     &emmc_datastrobe
> +		     &emmc_rstnout>;
> +	vmmc-supply = <&vcc_3v3>;
> +	vqmmc-supply = <&vcc_1v8>;
> +	status = "okay";
> +};
> +
> +&sdmmc0 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
> +	disable-wp;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdmmc0_bus4
> +		     &sdmmc0_clk
> +		     &sdmmc0_cmd
> +		     &sdmmc0_det>;
> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc3v3_sd>;
> +	vqmmc-supply = <&vccio_sd>;
> +	status = "okay";
> +};
> +
> +&sdmmc1 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cap-sdio-irq;
> +	keep-power-in-suspend;
> +	mmc-pwrseq = <&sdio_pwrseq>;
> +	non-removable;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdmmc1_bus4
> +		     &sdmmc1_cmd
> +		     &sdmmc1_clk>;
> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc_wl>;
> +	vqmmc-supply = <&vcca1v8_pmu>;
> +	status = "okay";
> +};
> +
> +&sfc {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&fspi_dual_io_pins>;
> +	status = "okay";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	flash at 0 {
> +		compatible = "jedec,spi-nor";
> +		reg = <0>;
> +		spi-max-frequency = <24000000>;
> +		spi-rx-bus-width = <2>;
> +		spi-tx-bus-width = <1>;
> +	};
> +};
> +
> +&tsadc {
> +	rockchip,hw-tshut-mode = <1>;
> +	rockchip,hw-tshut-polarity = <0>;
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart1m0_xfer
> +		     &uart1m0_ctsn
> +		     &uart1m0_rtsn>;
> +	status = "okay";
> +	uart-has-rtscts;
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> +
> +&usb_host0_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host0_ohci {
> +	status = "okay";
> +};
> +
> +&usb_host0_xhci {
> +	status = "okay";
> +};
> +
> +&usb_host1_xhci {
> +	status = "okay";
> +};
> +
> +&usb2phy0 {
> +	status = "okay";
> +};
> +
> +&usb2phy0_host {
> +	phy-supply = <&vcc5v0_usb_host0>;
> +	status = "okay";
> +};
> +
> +&usb2phy0_otg {
> +	status = "okay";
> +};
> +
> +&usb2phy1 {
> +	status = "okay";
> +};
> +
> +&usb2phy1_otg {
> +	phy-supply = <&vcc5v0_usb_host2>;
> +	status = "okay";
> +};
> +
> +&vop {
> +	assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
> +	assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
> +	status = "okay";
> +};
> +
> +&vop_mmu {
> +	status = "okay";
> +};
> +
> +&vp0 {
> +	vp0_out_hdmi: endpoint at ROCKCHIP_VOP2_EP_HDMI0 {
> +		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
> +		remote-endpoint = <&hdmi_in_vp0>;
> +	};
> +};
> +
> +&vp1 {
> +	vp1_out_dsi0: endpoint at ROCKCHIP_VOP2_EP_MIPI0 {
> +		reg = <ROCKCHIP_VOP2_EP_MIPI0>;
> +		remote-endpoint = <&dsi0_in_vp1>;
> +	};
> +};






From manut at mecka.net  Sat Dec 23 03:01:27 2023
From: manut at mecka.net (Manuel Traut)
Date: Sat, 23 Dec 2023 12:01:27 +0100
Subject: [PATCH 0/6] arm64: rockchip: Pine64 pinetab2 support
In-Reply-To: <2631715.l0DajZZ3Y3@bagend>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <2631715.l0DajZZ3Y3@bagend>
Message-ID: <ZYa-Bw61x-BPaGsi@mecka.net>

On Fri, Dec 22, 2023 at 05:51:41PM +0100, Diederik de Haas wrote:
> On Friday, 22 December 2023 12:05:40 CET Manuel Traut wrote:
> > [3]
> > https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/
> > mobian-6.6/debian/patches/display/0018-drm-panel-add-BOE-TH101MB31IG002-28A-
> > driver.patch?ref_type=heads 
> > [4]
> > https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/
> > mobian-6.6/debian/patches/device-tree/0134-arch-arm64-add-Pine64-PineTab2-de
> > vice-trees.patch?ref_type=heads
> 
> FWIW I believe the actual sources are from
> https://github.com/TuxThePenguin0/linux/commits/device/pine64-pinetab2_stable

Thanks for pointing this out, there are also some other relevant changes.
I will take care on this and Krzysztofs review and post a v2 later.

Thanks
Manuel


From andy.yan at rock-chips.com  Sat Dec 23 03:14:03 2023
From: andy.yan at rock-chips.com (Andy Yan)
Date: Sat, 23 Dec 2023 19:14:03 +0800
Subject: [PATCH v2 1/3] ARM: dts: rockchip: Add psci for rk3036
In-Reply-To: <18c16355-9140-45be-bd16-96fad8b184a4@gmail.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
 <20231218105523.2478315-2-andyshrk@163.com>
 <da10e2fc-3179-4bd5-88ed-b4d5f64a7191@gmail.com>
 <28216be5-810f-40d6-850b-a0fc590ffa3c@rock-chips.com>
 <a82481ca-b578-49a4-b0d0-974b6ee65c98@gmail.com>
 <74e497f5-0361-47f7-a410-4b20d3526d52@rock-chips.com>
 <18c16355-9140-45be-bd16-96fad8b184a4@gmail.com>
Message-ID: <b81d91e4-a06d-40c6-8c08-23c3ea5bd945@rock-chips.com>

Hi Alex,

On 12/22/23 23:37, Alex Bee wrote:
> Hi Andy,
> 
> Am 22.12.23 um 11:37 schrieb Andy Yan:
>> Hi Alex,
>>
>> On 12/21/23 23:58, Alex Bee wrote:
>>> Hi Andy,
>>>
>>> Am 21.12.23 um 02:07 schrieb Andy Yan:
>>>> Hi Alex:
>>>>
>>>> On 12/20/23 19:16, Alex Bee wrote:
>>>>> Hi Andy,
>>>>> Am 18.12.23 um 11:55 schrieb Andy Yan:
>>>>>> From: Andy Yan <andy.yan at rock-chips.com>
>>>>>>
>>>>>> The system will hang at bringup secondary CPUs
>>>>>> without psci node.
>>>>>>
>>>>>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> (no changes since v1)
>>>>>>
>>>>>> ? arch/arm/boot/dts/rockchip/rk3036.dtsi | 5 +++++
>>>>>> ? 1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>>>>> index 78686fc72ce6..5344803442a1 100644
>>>>>> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>>>>> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>>>>> @@ -67,6 +67,11 @@ display-subsystem {
>>>>>> ????????? ports = <&vop_out>;
>>>>>> ????? };
>>>>>> +??? psci {
>>>>>> +??????? compatible = "arm,psci-1.0";
>>>>>> +??????? method = "smc";
>>>>>> +??? };
>>>>>> +
>>>>> I don't think that's an good idea. 
>>>>
>>>> Why?
>>> It's only what I've been told before: We shoudn't add properties which
>>> depend on non-upstream software (if an upstream alternative exists). Also
>>
>>> I'm not sure what happens if somebody doesn't?use downstream bootloader
>>> and PSCI can't be found: Would the board still be able to boot?
>>
>> The psci is released herel[0].
>> And also, there are only two rk3036 based boards in mainline:
>> rk3036-evb,rk3036-keylin, both of them from rockchip.
>> And the mainline support of these boards broken from linux 5.7(2020, see PATCH 3),
>> no one report this broken until I try to run this board now.
>> So maybe there is no such somebody will run into this situation.
>>
>>
>> [0]https://github.com/rockchip-linux/rkbin/tree/master/bin/rk30
>>
> Yeah sure, there are binary release for downstream optee implementations,
> but the won't work with upstream u-boot, since they are using a calling
> convention different from upstream optee os. I tried to add support for
> those, but it was rejected [0].
> 
> Upstream bootflow doesn't implement/need PSCI as it uses a SMP bringup
> method which is done in kernel only (see enable-method in cpu section). I
> guess that it doesn't work for you is most likely because the downstream
> tee os makes the cpu registers the upstream enable-method uses only
> accessible in a higher exception level.
> 
> I can undust my RK3036 evb board during christmas holidays and check whats
> broken for RK3036 in u-boot. Everything was working fine (including SMP

With one day bisect, I finally fond the mainline u-boot support for rk3036
was broken by this commit f113d7d30346 (" Convert CONFIG_SPL_STACK to Kconfig")

It makes rk3036 can't set SPL_STACK as rk3036 can't enable SPL_FRAMEWORK(very small sram)

I still don't have a proper patch to fix this issue.

Thank you very much for you explanation.
I think i should not add psci to mainline before the tee binary can be used by mainline u-boot.

Nice holidays!
> bringup w/o PSCI and upstream u-boot) when I was adding VPU support in 5.14
> [1]. I likely booted from TF-card rather than eMMC.
> 
> [0] https://patchwork.ozlabs.org/project/uboot/patch/20230718145715.1280201-6-knaerzche at gmail.com/
> [1] https://patchwork.kernel.org/project/linux-rockchip/patch/20210527154455.358869-11-knaerzche at gmail.com/
> 
> Nice holidays!
> 
> Alex
> 
>>>>
>>>>> You most likely need that because you have downstream bootloader installed on this board. PSCI implementation takes place in TEE-OS for Rockchips ARM SoCs. There is no support for RK3036 in upstream op-tee OS. It's pretty much the same for RK3128 and RK3288.
>>>>> If you use upstream u-boot it should be good as-is.
>>>>
>>>> Unfortunately, upstream u-boot also cannot boot up on this board.
>>>> At present, I haven't had time to debug what is going on.
>>>>
>>>> Another reason I want to use downstream u-boot it is: I try run
>>>> this board with mainline just because i want to test some community
>>>> patches about inno-hdmi driver, as you said "the inno-hdmi driver currently gets a lot of attention"[0]
>>>>
>>> Thanks for helping testing this.
>>>
>>> Alex
>>>
>>>> With a downstream u-boot I can easy switch between upstream kernel and downstream kernel(no need to replace other components)
>>>> if I found some function is not work as expected.
>>>>
>>>>
>>>> [0]https://patchwork.kernel.org/project/linux-rockchip/cover/20231219170100.188800-1-knaerzche at gmail.com/
>>>>>
>>>>> Alex
>>>>>> ????? timer {
>>>>>> ????????? compatible = "arm,armv7-timer";
>>>>>> ????????? arm,cpu-registers-not-fw-configured;
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-rockchip mailing list
>>>>> Linux-rockchip at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip


From heiko at sntech.de  Sat Dec 23 03:43:56 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sat, 23 Dec 2023 12:43:56 +0100
Subject: [PATCH 5/6] arm64: dts: rockchip: Fix some dtb-check warnings
In-Reply-To: <20231222-pinetab2-v1-5-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-5-e148a7f61bd1@mecka.net>
Message-ID: <2337863.6tgchFWduM@diego>

Am Freitag, 22. Dezember 2023, 12:05:45 CET schrieb Manuel Traut:
> devicetree checks show some warnings:
> 
> video-codec at fdea0400: 'interrupt-names' is a required property
> from schema $id: http://devicetree.org/schemas/media/rockchip-vpu.yaml#
> 
> hdmi at fe0a0000: Unevaluated properties are not allowed ('power-domains' were unexpected)
> from schema $id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
> 
> i2s at fe420000: reset-names:0: 'm' is not one of ['tx-m', 'rx-m']
> from schema $id: http://devicetree.org/schemas/sound/rockchip,i2s-tdm.yaml#
> 
> phy at fe870000: 'power-domains' is a required property
> from schema $id: http://devicetree.org/schemas/phy/rockchip-inno-csi-dphy.yaml#
> 
> Fix them by
>   - setting a interrupt-name for the video-codec
>   - remove the unevaluated power-domain property from hdmi
>   - set reset-names according to the spec for i2s
>   - add a power-domain property for the CSI phy
> 
> Signed-off-by: Manuel Traut <manut at mecka.net>
> ---
>  arch/arm64/boot/dts/rockchip/rk356x.dtsi | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> index c19c0f1b3778..651156759582 100644
> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> @@ -597,6 +597,7 @@ vpu: video-codec at fdea0400 {
>  		compatible = "rockchip,rk3568-vpu";
>  		reg = <0x0 0xfdea0000 0x0 0x800>;
>  		interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-names = "vdpu";
>  		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
>  		clock-names = "aclk", "hclk";
>  		iommus = <&vdpu_mmu>;
> @@ -819,7 +820,6 @@ hdmi: hdmi at fe0a0000 {
>  		clock-names = "iahb", "isfr", "cec", "ref";
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
> -		power-domains = <&power RK3568_PD_VO>;

are you really sure that the hdmi controller is _not_ part of
the VO powerdomain? I.e. Depending on that knowledge it could
also simply be necessary to add the property to the binding.


Heiko




From wahrenst at gmx.net  Sat Dec 23 04:35:46 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Sat, 23 Dec 2023 13:35:46 +0100
Subject: [PATCH] ARM: sun9i: smp: Fix array-index-out-of-bounds read in sunxi_mc_smp_init
Message-ID: <20231223123546.88125-1-wahrenst@gmx.net>

Running a multi-arch kernel (multi_v7_defconfig) on a Raspberry Pi 3B+
with enabled CONFIG_UBSAN triggers the following warning:

 UBSAN: array-index-out-of-bounds in arch/arm/mach-sunxi/mc_smp.c:810:29
 index 2 is out of range for type 'sunxi_mc_smp_data [2]'
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc6-00248-g5254c0cbc92d
 Hardware name: BCM2835
  unwind_backtrace from show_stack+0x10/0x14
  show_stack from dump_stack_lvl+0x40/0x4c
  dump_stack_lvl from ubsan_epilogue+0x8/0x34
  ubsan_epilogue from __ubsan_handle_out_of_bounds+0x78/0x80
  __ubsan_handle_out_of_bounds from sunxi_mc_smp_init+0xe4/0x4cc
  sunxi_mc_smp_init from do_one_initcall+0xa0/0x2fc
  do_one_initcall from kernel_init_freeable+0xf4/0x2f4
  kernel_init_freeable from kernel_init+0x18/0x158
  kernel_init from ret_from_fork+0x14/0x28

Since the enabled method couldn't match with any entry from
sunxi_mc_smp_data, the value of the index shouldn't be used right after
the loop. So move it after the check of ret in order to have a valid
index.

Fixes: 1631090e34f5 ("ARM: sun9i: smp: Add is_a83t field")
Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
 arch/arm/mach-sunxi/mc_smp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index cb63921232a6..6ec3445f3c72 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -807,12 +807,12 @@ static int __init sunxi_mc_smp_init(void)
 			break;
 	}

-	is_a83t = sunxi_mc_smp_data[i].is_a83t;
-
 	of_node_put(node);
 	if (ret)
 		return -ENODEV;

+	is_a83t = sunxi_mc_smp_data[i].is_a83t;
+
 	if (!sunxi_mc_smp_cpu_table_init())
 		return -EINVAL;

--
2.34.1



From lkp at intel.com  Sat Dec 23 04:47:53 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 20:47:53 +0800
Subject: [soc:tee/shmem] BUILD SUCCESS
 7bdee41575919773818e525ea19e54eb817770af
Message-ID: <202312232049.3hxsV1QD-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tee/shmem
branch HEAD: 7bdee41575919773818e525ea19e54eb817770af  tee: Use iov_iter to better support shared buffer registration

elapsed time: 1498m

configs tested: 135
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                              alldefconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231223   gcc  
arc                   randconfig-002-20231223   gcc  
arm                               allnoconfig   gcc  
arm                          exynos_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231223   gcc  
csky                  randconfig-002-20231223   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231223   gcc  
i386                  randconfig-012-20231223   gcc  
i386                  randconfig-013-20231223   gcc  
i386                  randconfig-014-20231223   gcc  
i386                  randconfig-015-20231223   gcc  
i386                  randconfig-016-20231223   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231223   gcc  
loongarch             randconfig-002-20231223   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                       bvme6000_defconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5407c3_defconfig   gcc  
m68k                           virt_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                          rm200_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231223   gcc  
nios2                 randconfig-002-20231223   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231223   gcc  
parisc                randconfig-002-20231223   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                    amigaone_defconfig   gcc  
powerpc                      mgcoge_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                      pcm030_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231223   gcc  
s390                  randconfig-002-20231223   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                    randconfig-001-20231223   gcc  
sh                    randconfig-002-20231223   gcc  
sh                   rts7751r2dplus_defconfig   gcc  
sh                          sdk7780_defconfig   gcc  
sh                           se7705_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231223   gcc  
sparc64               randconfig-002-20231223   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231223   clang
x86_64       buildonly-randconfig-002-20231223   clang
x86_64       buildonly-randconfig-003-20231223   clang
x86_64       buildonly-randconfig-004-20231223   clang
x86_64       buildonly-randconfig-005-20231223   clang
x86_64       buildonly-randconfig-006-20231223   clang
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231223   clang
x86_64                randconfig-012-20231223   clang
x86_64                randconfig-013-20231223   clang
x86_64                randconfig-014-20231223   clang
x86_64                randconfig-015-20231223   clang
x86_64                randconfig-016-20231223   clang
x86_64                randconfig-071-20231223   clang
x86_64                randconfig-072-20231223   clang
x86_64                randconfig-073-20231223   clang
x86_64                randconfig-074-20231223   clang
x86_64                randconfig-075-20231223   clang
x86_64                randconfig-076-20231223   clang
x86_64                           rhel-8.3-bpf   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                           alldefconfig   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231223   gcc  
xtensa                randconfig-002-20231223   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Sat Dec 23 04:51:30 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 20:51:30 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS
 fa3d6c7183106a187a8d399216db3f088a6aab81
Message-ID: <202312232027.qvsfsD6j-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: fa3d6c7183106a187a8d399216db3f088a6aab81  arm64: dts: mediatek: mt8395-genio-1200-evk: add interrupt-parent for mt6360

elapsed time: 2587m

configs tested: 73
configs skipped: 0

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
arc                   randconfig-001-20231223   gcc  
arc                   randconfig-002-20231223   gcc  
arm                   randconfig-001-20231223   clang
arm                   randconfig-002-20231223   clang
arm                   randconfig-003-20231223   clang
arm                   randconfig-004-20231223   clang
arm64                 randconfig-001-20231223   clang
arm64                 randconfig-002-20231223   clang
arm64                 randconfig-003-20231223   clang
arm64                 randconfig-004-20231223   clang
csky                  randconfig-001-20231223   gcc  
csky                  randconfig-002-20231223   gcc  
hexagon               randconfig-001-20231223   clang
hexagon               randconfig-002-20231223   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231223   clang
i386         buildonly-randconfig-002-20231223   clang
i386         buildonly-randconfig-003-20231223   clang
i386         buildonly-randconfig-004-20231223   clang
i386         buildonly-randconfig-005-20231223   clang
i386         buildonly-randconfig-006-20231223   clang
i386                                defconfig   gcc  
i386                  randconfig-001-20231223   clang
i386                  randconfig-002-20231223   clang
i386                  randconfig-003-20231223   clang
i386                  randconfig-004-20231223   clang
i386                  randconfig-005-20231223   clang
i386                  randconfig-006-20231223   clang
i386                  randconfig-011-20231223   gcc  
i386                  randconfig-012-20231223   gcc  
i386                  randconfig-013-20231223   gcc  
i386                  randconfig-014-20231223   gcc  
i386                  randconfig-015-20231223   gcc  
i386                  randconfig-016-20231223   gcc  
loongarch             randconfig-001-20231223   gcc  
loongarch             randconfig-002-20231223   gcc  
nios2                 randconfig-001-20231223   gcc  
nios2                 randconfig-002-20231223   gcc  
parisc                randconfig-001-20231223   gcc  
parisc                randconfig-002-20231223   gcc  
powerpc               randconfig-001-20231223   clang
powerpc               randconfig-002-20231223   clang
powerpc               randconfig-003-20231223   clang
powerpc64             randconfig-001-20231223   clang
powerpc64             randconfig-002-20231223   clang
powerpc64             randconfig-003-20231223   clang
riscv                 randconfig-001-20231223   clang
riscv                 randconfig-002-20231223   clang
s390                             allmodconfig   gcc  
s390                             allyesconfig   gcc  
s390                  randconfig-001-20231223   gcc  
s390                  randconfig-002-20231223   gcc  
sh                               allmodconfig   gcc  
sh                               allyesconfig   gcc  
sh                    randconfig-001-20231223   gcc  
sh                    randconfig-002-20231223   gcc  
sparc                            allmodconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64               randconfig-001-20231223   gcc  
sparc64               randconfig-002-20231223   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                    randconfig-001-20231223   clang
um                    randconfig-002-20231223   clang
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64                              defconfig   gcc  
x86_64                          rhel-8.3-rust   clang
xtensa                randconfig-001-20231223   gcc  
xtensa                randconfig-002-20231223   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Sat Dec 23 04:55:30 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 20:55:30 +0800
Subject: [soc:k3/defconfig] BUILD SUCCESS
 e8779517788fa0f3d04840cb7d4121d3df8dfd54
Message-ID: <202312232026.K1eYAdaD-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git k3/defconfig
branch HEAD: e8779517788fa0f3d04840cb7d4121d3df8dfd54  arm64: defconfig: Enable DRM_POWERVR

elapsed time: 1506m

configs tested: 135
configs skipped: 93

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                              alldefconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231223   gcc  
arc                   randconfig-002-20231223   gcc  
arm                               allnoconfig   gcc  
arm                          exynos_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231223   gcc  
csky                  randconfig-002-20231223   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231223   gcc  
i386                  randconfig-012-20231223   gcc  
i386                  randconfig-013-20231223   gcc  
i386                  randconfig-014-20231223   gcc  
i386                  randconfig-015-20231223   gcc  
i386                  randconfig-016-20231223   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231223   gcc  
loongarch             randconfig-002-20231223   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                       bvme6000_defconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5407c3_defconfig   gcc  
m68k                           virt_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                          rm200_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231223   gcc  
nios2                 randconfig-002-20231223   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231223   gcc  
parisc                randconfig-002-20231223   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                    amigaone_defconfig   gcc  
powerpc                      mgcoge_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                      pcm030_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231223   gcc  
s390                  randconfig-002-20231223   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                    randconfig-001-20231223   gcc  
sh                    randconfig-002-20231223   gcc  
sh                   rts7751r2dplus_defconfig   gcc  
sh                          sdk7780_defconfig   gcc  
sh                           se7705_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231223   gcc  
sparc64               randconfig-002-20231223   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231223   clang
x86_64       buildonly-randconfig-002-20231223   clang
x86_64       buildonly-randconfig-003-20231223   clang
x86_64       buildonly-randconfig-004-20231223   clang
x86_64       buildonly-randconfig-005-20231223   clang
x86_64       buildonly-randconfig-006-20231223   clang
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231223   clang
x86_64                randconfig-012-20231223   clang
x86_64                randconfig-013-20231223   clang
x86_64                randconfig-014-20231223   clang
x86_64                randconfig-015-20231223   clang
x86_64                randconfig-016-20231223   clang
x86_64                randconfig-071-20231223   clang
x86_64                randconfig-072-20231223   clang
x86_64                randconfig-073-20231223   clang
x86_64                randconfig-074-20231223   clang
x86_64                randconfig-075-20231223   clang
x86_64                randconfig-076-20231223   clang
x86_64                           rhel-8.3-bpf   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                           alldefconfig   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231223   gcc  
xtensa                randconfig-002-20231223   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Sat Dec 23 04:54:48 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 20:54:48 +0800
Subject: [soc:k3/soc-driver] BUILD SUCCESS
 2c2235292b33d788a1436f1d2a6108184a657f51
Message-ID: <202312232045.d09CHQ94-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git k3/soc-driver
branch HEAD: 2c2235292b33d788a1436f1d2a6108184a657f51  soc: ti: k3-socinfo: Add JTAG ID for J722S

elapsed time: 1506m

configs tested: 135
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                              alldefconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231223   gcc  
arc                   randconfig-002-20231223   gcc  
arm                               allnoconfig   gcc  
arm                          exynos_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231223   gcc  
csky                  randconfig-002-20231223   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231223   gcc  
i386                  randconfig-012-20231223   gcc  
i386                  randconfig-013-20231223   gcc  
i386                  randconfig-014-20231223   gcc  
i386                  randconfig-015-20231223   gcc  
i386                  randconfig-016-20231223   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231223   gcc  
loongarch             randconfig-002-20231223   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                       bvme6000_defconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5407c3_defconfig   gcc  
m68k                           virt_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                          rm200_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231223   gcc  
nios2                 randconfig-002-20231223   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231223   gcc  
parisc                randconfig-002-20231223   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                    amigaone_defconfig   gcc  
powerpc                      mgcoge_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                      pcm030_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231223   gcc  
s390                  randconfig-002-20231223   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                    randconfig-001-20231223   gcc  
sh                    randconfig-002-20231223   gcc  
sh                   rts7751r2dplus_defconfig   gcc  
sh                          sdk7780_defconfig   gcc  
sh                           se7705_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231223   gcc  
sparc64               randconfig-002-20231223   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231223   clang
x86_64       buildonly-randconfig-002-20231223   clang
x86_64       buildonly-randconfig-003-20231223   clang
x86_64       buildonly-randconfig-004-20231223   clang
x86_64       buildonly-randconfig-005-20231223   clang
x86_64       buildonly-randconfig-006-20231223   clang
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231223   clang
x86_64                randconfig-012-20231223   clang
x86_64                randconfig-013-20231223   clang
x86_64                randconfig-014-20231223   clang
x86_64                randconfig-015-20231223   clang
x86_64                randconfig-016-20231223   clang
x86_64                randconfig-071-20231223   clang
x86_64                randconfig-072-20231223   clang
x86_64                randconfig-073-20231223   clang
x86_64                randconfig-074-20231223   clang
x86_64                randconfig-075-20231223   clang
x86_64                randconfig-076-20231223   clang
x86_64                           rhel-8.3-bpf   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                           alldefconfig   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231223   gcc  
xtensa                randconfig-002-20231223   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Sat Dec 23 05:32:25 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 21:32:25 +0800
Subject: [soc:qcom/defconfig] BUILD SUCCESS
 48a9ba5eb4d720c6e21c6e4d2a6fb6e1a97f5f2a
Message-ID: <202312232121.K1IQ9Xvt-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/defconfig
branch HEAD: 48a9ba5eb4d720c6e21c6e4d2a6fb6e1a97f5f2a  arm64: defconfig: enable Qualcomm WSA884x driver

elapsed time: 8182m

configs tested: 138
configs skipped: 152

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                              alldefconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231223   gcc  
arc                   randconfig-002-20231223   gcc  
arm                               allnoconfig   gcc  
arm                          exynos_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231223   gcc  
csky                  randconfig-002-20231223   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231223   gcc  
i386                  randconfig-012-20231223   gcc  
i386                  randconfig-013-20231223   gcc  
i386                  randconfig-014-20231223   gcc  
i386                  randconfig-015-20231223   gcc  
i386                  randconfig-016-20231223   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231223   gcc  
loongarch             randconfig-002-20231223   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                       bvme6000_defconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5407c3_defconfig   gcc  
m68k                           virt_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                          rm200_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231223   gcc  
nios2                 randconfig-002-20231223   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231223   gcc  
parisc                randconfig-002-20231223   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                    amigaone_defconfig   gcc  
powerpc                      mgcoge_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                      pcm030_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231223   gcc  
s390                  randconfig-002-20231223   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                    randconfig-001-20231223   gcc  
sh                    randconfig-002-20231223   gcc  
sh                   rts7751r2dplus_defconfig   gcc  
sh                          sdk7780_defconfig   gcc  
sh                           se7705_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231223   gcc  
sparc64               randconfig-002-20231223   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231223   clang
x86_64       buildonly-randconfig-002-20231223   clang
x86_64       buildonly-randconfig-003-20231223   clang
x86_64       buildonly-randconfig-004-20231223   clang
x86_64       buildonly-randconfig-005-20231223   clang
x86_64       buildonly-randconfig-006-20231223   clang
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231223   clang
x86_64                randconfig-012-20231223   clang
x86_64                randconfig-013-20231223   clang
x86_64                randconfig-014-20231223   clang
x86_64                randconfig-015-20231223   clang
x86_64                randconfig-016-20231223   clang
x86_64                randconfig-071-20231223   clang
x86_64                randconfig-072-20231223   clang
x86_64                randconfig-073-20231223   clang
x86_64                randconfig-074-20231223   clang
x86_64                randconfig-075-20231223   clang
x86_64                randconfig-076-20231223   clang
x86_64                           rhel-8.3-bpf   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                           alldefconfig   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231223   gcc  
xtensa                randconfig-002-20231223   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Sat Dec 23 05:34:51 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 21:34:51 +0800
Subject: [soc:qcom/dt64] BUILD SUCCESS
 b7b9a6aa7aea2bcba2d35d65e4ce2913115485a3
Message-ID: <202312232148.AAizjpCM-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/dt64
branch HEAD: b7b9a6aa7aea2bcba2d35d65e4ce2913115485a3  arm64: dts: qcom: sc8180x-primus: Allow UFS regulators load/mode setting

elapsed time: 8183m

configs tested: 156
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                              alldefconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231223   gcc  
arc                   randconfig-002-20231223   gcc  
arm                               allnoconfig   gcc  
arm                          exynos_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231223   gcc  
csky                  randconfig-002-20231223   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231218   gcc  
i386         buildonly-randconfig-002-20231218   gcc  
i386         buildonly-randconfig-003-20231218   gcc  
i386         buildonly-randconfig-004-20231218   gcc  
i386         buildonly-randconfig-005-20231218   gcc  
i386         buildonly-randconfig-006-20231218   gcc  
i386                  randconfig-001-20231218   gcc  
i386                  randconfig-002-20231218   gcc  
i386                  randconfig-003-20231218   gcc  
i386                  randconfig-004-20231218   gcc  
i386                  randconfig-005-20231218   gcc  
i386                  randconfig-006-20231218   gcc  
i386                  randconfig-011-20231218   clang
i386                  randconfig-011-20231223   gcc  
i386                  randconfig-012-20231218   clang
i386                  randconfig-012-20231223   gcc  
i386                  randconfig-013-20231218   clang
i386                  randconfig-013-20231223   gcc  
i386                  randconfig-014-20231218   clang
i386                  randconfig-014-20231223   gcc  
i386                  randconfig-015-20231218   clang
i386                  randconfig-015-20231223   gcc  
i386                  randconfig-016-20231218   clang
i386                  randconfig-016-20231223   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231223   gcc  
loongarch             randconfig-002-20231223   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                       bvme6000_defconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5407c3_defconfig   gcc  
m68k                           virt_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                          rm200_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231223   gcc  
nios2                 randconfig-002-20231223   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231223   gcc  
parisc                randconfig-002-20231223   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                    amigaone_defconfig   gcc  
powerpc                      mgcoge_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                      pcm030_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231223   gcc  
s390                  randconfig-002-20231223   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                    randconfig-001-20231223   gcc  
sh                    randconfig-002-20231223   gcc  
sh                   rts7751r2dplus_defconfig   gcc  
sh                          sdk7780_defconfig   gcc  
sh                           se7705_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231223   gcc  
sparc64               randconfig-002-20231223   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231223   clang
x86_64       buildonly-randconfig-002-20231223   clang
x86_64       buildonly-randconfig-003-20231223   clang
x86_64       buildonly-randconfig-004-20231223   clang
x86_64       buildonly-randconfig-005-20231223   clang
x86_64       buildonly-randconfig-006-20231223   clang
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231223   clang
x86_64                randconfig-012-20231223   clang
x86_64                randconfig-013-20231223   clang
x86_64                randconfig-014-20231223   clang
x86_64                randconfig-015-20231223   clang
x86_64                randconfig-016-20231223   clang
x86_64                randconfig-071-20231223   clang
x86_64                randconfig-072-20231223   clang
x86_64                randconfig-073-20231223   clang
x86_64                randconfig-074-20231223   clang
x86_64                randconfig-075-20231223   clang
x86_64                randconfig-076-20231223   clang
x86_64                           rhel-8.3-bpf   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                           alldefconfig   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231223   gcc  
xtensa                randconfig-002-20231223   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Sat Dec 23 05:36:32 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 21:36:32 +0800
Subject: [soc:soc/defconfig] BUILD SUCCESS
 ed27e15bc49097f26689b201af5ea89e7154d880
Message-ID: <202312232129.3vPdC6m2-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/defconfig
branch HEAD: ed27e15bc49097f26689b201af5ea89e7154d880  ARM: multi_v7_defconfig: enable STM32 DCMIPP media support

elapsed time: 1473m

configs tested: 138
configs skipped: 93

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                              alldefconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231223   gcc  
arc                   randconfig-002-20231223   gcc  
arm                               allnoconfig   gcc  
arm                          exynos_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231223   gcc  
csky                  randconfig-002-20231223   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231223   gcc  
i386                  randconfig-012-20231223   gcc  
i386                  randconfig-013-20231223   gcc  
i386                  randconfig-014-20231223   gcc  
i386                  randconfig-015-20231223   gcc  
i386                  randconfig-016-20231223   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231223   gcc  
loongarch             randconfig-002-20231223   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                       bvme6000_defconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5407c3_defconfig   gcc  
m68k                           virt_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                          rm200_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231223   gcc  
nios2                 randconfig-002-20231223   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231223   gcc  
parisc                randconfig-002-20231223   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                    amigaone_defconfig   gcc  
powerpc                      mgcoge_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                      pcm030_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231223   gcc  
s390                  randconfig-002-20231223   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                    randconfig-001-20231223   gcc  
sh                    randconfig-002-20231223   gcc  
sh                   rts7751r2dplus_defconfig   gcc  
sh                          sdk7780_defconfig   gcc  
sh                           se7705_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231223   gcc  
sparc64               randconfig-002-20231223   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231223   clang
x86_64       buildonly-randconfig-002-20231223   clang
x86_64       buildonly-randconfig-003-20231223   clang
x86_64       buildonly-randconfig-004-20231223   clang
x86_64       buildonly-randconfig-005-20231223   clang
x86_64       buildonly-randconfig-006-20231223   clang
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231223   clang
x86_64                randconfig-012-20231223   clang
x86_64                randconfig-013-20231223   clang
x86_64                randconfig-014-20231223   clang
x86_64                randconfig-015-20231223   clang
x86_64                randconfig-016-20231223   clang
x86_64                randconfig-071-20231223   clang
x86_64                randconfig-072-20231223   clang
x86_64                randconfig-073-20231223   clang
x86_64                randconfig-074-20231223   clang
x86_64                randconfig-075-20231223   clang
x86_64                randconfig-076-20231223   clang
x86_64                           rhel-8.3-bpf   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                           alldefconfig   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231223   gcc  
xtensa                randconfig-002-20231223   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Sat Dec 23 05:39:38 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 21:39:38 +0800
Subject: [soc:soc/drivers] BUILD SUCCESS
 db0a7c09b2a552c5028a29942e80a4848d182934
Message-ID: <202312232134.eS5hXoaz-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/drivers
branch HEAD: db0a7c09b2a552c5028a29942e80a4848d182934  Merge tag 'tee-iov-iter-for-v6.8' of https://git.linaro.org/people/jens.wiklander/linux-tee into soc/drivers

elapsed time: 1476m

configs tested: 138
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                              alldefconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231223   gcc  
arc                   randconfig-002-20231223   gcc  
arm                               allnoconfig   gcc  
arm                          exynos_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231223   gcc  
csky                  randconfig-002-20231223   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231223   gcc  
i386                  randconfig-012-20231223   gcc  
i386                  randconfig-013-20231223   gcc  
i386                  randconfig-014-20231223   gcc  
i386                  randconfig-015-20231223   gcc  
i386                  randconfig-016-20231223   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231223   gcc  
loongarch             randconfig-002-20231223   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                       bvme6000_defconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5407c3_defconfig   gcc  
m68k                           virt_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                          rm200_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231223   gcc  
nios2                 randconfig-002-20231223   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231223   gcc  
parisc                randconfig-002-20231223   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                    amigaone_defconfig   gcc  
powerpc                      mgcoge_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                      pcm030_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231223   gcc  
s390                  randconfig-002-20231223   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                    randconfig-001-20231223   gcc  
sh                    randconfig-002-20231223   gcc  
sh                   rts7751r2dplus_defconfig   gcc  
sh                          sdk7780_defconfig   gcc  
sh                           se7705_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231223   gcc  
sparc64               randconfig-002-20231223   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231223   clang
x86_64       buildonly-randconfig-002-20231223   clang
x86_64       buildonly-randconfig-003-20231223   clang
x86_64       buildonly-randconfig-004-20231223   clang
x86_64       buildonly-randconfig-005-20231223   clang
x86_64       buildonly-randconfig-006-20231223   clang
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231223   clang
x86_64                randconfig-012-20231223   clang
x86_64                randconfig-013-20231223   clang
x86_64                randconfig-014-20231223   clang
x86_64                randconfig-015-20231223   clang
x86_64                randconfig-016-20231223   clang
x86_64                randconfig-071-20231223   clang
x86_64                randconfig-072-20231223   clang
x86_64                randconfig-073-20231223   clang
x86_64                randconfig-074-20231223   clang
x86_64                randconfig-075-20231223   clang
x86_64                randconfig-076-20231223   clang
x86_64                           rhel-8.3-bpf   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                           alldefconfig   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231223   gcc  
xtensa                randconfig-002-20231223   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From krzysztof.kozlowski at linaro.org  Sat Dec 23 05:54:44 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 14:54:44 +0100
Subject: [PATCH v2 1/2] dt-bindings: input: atmel,maxtouch: add
 poweroff-sleep property
In-Reply-To: <20231222095258.33369-2-eichest@gmail.com>
References: <20231222095258.33369-1-eichest@gmail.com>
 <20231222095258.33369-2-eichest@gmail.com>
Message-ID: <91dd66ac-8a2b-4b1f-9d88-56e48152c1fe@linaro.org>

On 22/12/2023 10:52, Stefan Eichenberger wrote:
> From: Stefan Eichenberger <stefan.eichenberger at toradex.com>
> 
> Add a new property to indicate that the device should power off rather
> than use deep sleep. Deep sleep is a feature of the controller that
> expects the controller to remain powered in suspend. However, if a
> display shares its regulator with the touch controller, we may want to
> do a power off so that the display and touch controller do not use any
> power.
> 

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From lkp at intel.com  Sat Dec 23 05:37:02 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 23 Dec 2023 21:37:02 +0800
Subject: [soc:soc/arm] BUILD SUCCESS WITH WARNING
 2560cffd2134c2e070dee369b37f6e55438087f9
Message-ID: <202312232158.te0PBX3a-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/arm
branch HEAD: 2560cffd2134c2e070dee369b37f6e55438087f9  ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support

Warning reports:

https://lore.kernel.org/oe-kbuild-all/202312231434.wNbFQ3Bx-lkp at intel.com

Warning: (recently discovered and may have been fixed)

arch/arm/kernel/perf_event_v6.c:144:23: warning: 'armv6mpcore_perf_map' defined but not used [-Wunused-const-variable=]
arch/arm/kernel/perf_event_v6.c:154:23: warning: 'armv6mpcore_perf_cache_map' defined but not used [-Wunused-const-variable=]
arch/arm/kernel/perf_event_v6.c:455:13: warning: 'armv6mpcore_pmu_disable_event' defined but not used [-Wunused-function]

Warning ids grouped by kconfigs:

gcc_recent_errors
|-- arm-allmodconfig
|   |-- arch-arm-kernel-perf_event_v6.c:warning:armv6mpcore_perf_cache_map-defined-but-not-used
|   |-- arch-arm-kernel-perf_event_v6.c:warning:armv6mpcore_perf_map-defined-but-not-used
|   `-- arch-arm-kernel-perf_event_v6.c:warning:armv6mpcore_pmu_disable_event-defined-but-not-used
`-- arm-allyesconfig
    |-- arch-arm-kernel-perf_event_v6.c:warning:armv6mpcore_perf_cache_map-defined-but-not-used
    |-- arch-arm-kernel-perf_event_v6.c:warning:armv6mpcore_perf_map-defined-but-not-used
    `-- arch-arm-kernel-perf_event_v6.c:warning:armv6mpcore_pmu_disable_event-defined-but-not-used

elapsed time: 1473m

configs tested: 138
configs skipped: 1

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                              alldefconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231223   gcc  
arc                   randconfig-002-20231223   gcc  
arm                               allnoconfig   gcc  
arm                          exynos_defconfig   gcc  
arm                        spear6xx_defconfig   gcc  
arm                         wpcm450_defconfig   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231223   gcc  
csky                  randconfig-002-20231223   gcc  
hexagon                          allmodconfig   clang
hexagon                          allyesconfig   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386                  randconfig-011-20231223   gcc  
i386                  randconfig-012-20231223   gcc  
i386                  randconfig-013-20231223   gcc  
i386                  randconfig-014-20231223   gcc  
i386                  randconfig-015-20231223   gcc  
i386                  randconfig-016-20231223   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                        allyesconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231223   gcc  
loongarch             randconfig-002-20231223   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                       bvme6000_defconfig   gcc  
m68k                                defconfig   gcc  
m68k                          hp300_defconfig   gcc  
m68k                        m5407c3_defconfig   gcc  
m68k                           virt_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                             allmodconfig   gcc  
mips                             allyesconfig   gcc  
mips                          rm200_defconfig   gcc  
mips                   sb1250_swarm_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231223   gcc  
nios2                 randconfig-002-20231223   gcc  
openrisc                         allmodconfig   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231223   gcc  
parisc                randconfig-002-20231223   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   clang
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                    amigaone_defconfig   gcc  
powerpc                      mgcoge_defconfig   gcc  
powerpc                   motionpro_defconfig   gcc  
powerpc                      pcm030_defconfig   gcc  
powerpc                      ppc40x_defconfig   gcc  
powerpc                     stx_gp3_defconfig   gcc  
riscv                            allmodconfig   gcc  
riscv                            allyesconfig   gcc  
riscv                               defconfig   gcc  
riscv                          rv32_defconfig   clang
s390                             allmodconfig   gcc  
s390                              allnoconfig   gcc  
s390                             allyesconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231223   gcc  
s390                  randconfig-002-20231223   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                    randconfig-001-20231223   gcc  
sh                    randconfig-002-20231223   gcc  
sh                   rts7751r2dplus_defconfig   gcc  
sh                          sdk7780_defconfig   gcc  
sh                           se7705_defconfig   gcc  
sh                           se7780_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                            allyesconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231223   gcc  
sparc64               randconfig-002-20231223   gcc  
um                               allmodconfig   clang
um                               allyesconfig   clang
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                           x86_64_defconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231223   clang
x86_64       buildonly-randconfig-002-20231223   clang
x86_64       buildonly-randconfig-003-20231223   clang
x86_64       buildonly-randconfig-004-20231223   clang
x86_64       buildonly-randconfig-005-20231223   clang
x86_64       buildonly-randconfig-006-20231223   clang
x86_64                                  kexec   gcc  
x86_64                randconfig-011-20231223   clang
x86_64                randconfig-012-20231223   clang
x86_64                randconfig-013-20231223   clang
x86_64                randconfig-014-20231223   clang
x86_64                randconfig-015-20231223   clang
x86_64                randconfig-016-20231223   clang
x86_64                randconfig-071-20231223   clang
x86_64                randconfig-072-20231223   clang
x86_64                randconfig-073-20231223   clang
x86_64                randconfig-074-20231223   clang
x86_64                randconfig-075-20231223   clang
x86_64                randconfig-076-20231223   clang
x86_64                           rhel-8.3-bpf   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                           alldefconfig   gcc  
xtensa                            allnoconfig   gcc  
xtensa                           allyesconfig   gcc  
xtensa                randconfig-001-20231223   gcc  
xtensa                randconfig-002-20231223   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From manut at mecka.net  Sat Dec 23 05:59:34 2023
From: manut at mecka.net (Manuel Traut)
Date: Sat, 23 Dec 2023 14:59:34 +0100
Subject: [PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64
 Pinetab2
In-Reply-To: <2121710.IWpXjAX0fk@bagend>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-4-e148a7f61bd1@mecka.net>
 <2121710.IWpXjAX0fk@bagend>
Message-ID: <ZYbnxkkCIJtzqa0h@mecka.net>

Hi Diederik,

On Fri, Dec 22, 2023 at 06:01:54PM +0100, Diederik de Haas wrote:
> On Friday, 22 December 2023 12:05:44 CET Manuel Traut wrote:
> > +
> > +&cru {
> > +       assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>, <&cru
> > PLL_VPLL>; +       assigned-clock-rates = <1200000000>, <200000000>,
> > <500000000>; +};
> 
> Attachment seem to work and for this I also have the attached patch in my 
> patch set.
> IIRC without it you get an error in dmesg immediately at boot up which is 
> visible on the PT2 *if* you have immediate visual output (which is not (yet?) 
> the case in my image/kernel).

you can see the message also by calling "dmesg --level err".
I could verify that your patch removes the error message.
I will pick the change for v2.

> Cheers,
>   Diederik

> From d782a64f3b51ffb2f33d3ba3e11e2ebc416542e3 Mon Sep 17 00:00:00 2001
> From: Jonas Karlman <jonas at kwiboo.se>
> Date: Thu, 17 Aug 2023 17:52:47 +0200
> Subject: [PATCH 6/8] arm64: dts: rk3566-pinetab2: Fix cru assigned clocks
> 
> Jonas Karlman provided/linked to the patch on IRC.
> Seems related to upstream commit 64b69474edf3b885c19a89bb165f978ba1b4be00.
> 
> Signed-off-by: Diederik de Haas <didi.debian at cknow.org>
> Link: https://github.com/Kwiboo/u-boot-rockchip/blob/rk3568-2023.10/arch/arm/dts/rk3566-pinetab2-u-boot.dtsi#L11-L15
> Link: https://lore.kernel.org/all/20230110225547.1563119-2-jonas at kwiboo.se/
> ---
>  arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> index bbd7ed53602a..4a5bee5a28a7 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> @@ -288,8 +288,9 @@ &cpu3 {
>  };
>  
>  &cru {
> -	assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>, <&cru PLL_VPLL>;
> -	assigned-clock-rates = <1200000000>, <200000000>, <500000000>;
> +	assigned-clocks = <&pmucru CLK_RTC_32K>, <&cru PLL_GPLL>, <&pmucru PLL_PPLL>, <&cru PLL_VPLL>;
> +	assigned-clock-rates = <32768>, <1200000000>, <200000000>, <500000000>;
> +	assigned-clock-parents = <&pmucru CLK_RTC32K_FRAC>;
>  };
>  
>  &csi_dphy {
> -- 
> 2.42.0
> 





From manut at mecka.net  Sat Dec 23 06:03:36 2023
From: manut at mecka.net (Manuel Traut)
Date: Sat, 23 Dec 2023 15:03:36 +0100
Subject: [PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64
 Pinetab2
In-Reply-To: <2250271.fI8GBZLEnK@bagend>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-4-e148a7f61bd1@mecka.net>
 <2250271.fI8GBZLEnK@bagend>
Message-ID: <ZYbouFFFmf7PInOk@mecka.net>

On Fri, Dec 22, 2023 at 05:49:35PM +0100, Diederik de Haas wrote:
> On Friday, 22 December 2023 12:05:44 CET Manuel Traut wrote:
> > +       rk817-sound {
> > +               compatible = "simple-audio-card";
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&hp_det_l>;
> > +               simple-audio-card,format = "i2s";
> > +               simple-audio-card,name = "PineTab2";
> > +               simple-audio-card,mclk-fs = <256>;
> > +
> > +               simple-audio-card,widgets =
> > +                       "Microphone", "Mic Jack",
> > +                       "Headphone", "Headphones",
> > +                       "Microphone", "Microphone",
> > +                       "Speaker", "Speakers";
> > +
> > +               simple-audio-card,routing =
> > +                       "MICL", "Microphone",
> > +                       "MICR", "Mic Jack",
> > +                       "Headphones", "HPOL",
> > +                       "Headphones", "HPOR",
> > +                       "Speaker Amplifier INL", "HPOL",
> > +                       "Speaker Amplifier INR", "HPOR",
> > +                       "Speakers", "Speaker Amplifier OUTL",
> > +                       "Speakers", "Speaker Amplifier OUTR";
> > +
> > +               simple-audio-card,hp-det-gpio = <&gpio4 RK_PC6
> > GPIO_ACTIVE_HIGH>; +               simple-audio-card,aux-devs =
> > <&speaker_amp>;
> > +               simple-audio-card,pin-switches = "Speakers", "Microphone";
> > +
> > +               simple-audio-card,cpu {
> > +                       sound-dai = <&i2s1_8ch>;
> > +               };
> > +
> > +               simple-audio-card,codec {
> > +                       sound-dai = <&rk817>;
> > +               };
> > +       };
> 
> Not sure if it's right (or allowed) to post a different patch as attachment, 
> but I have been using a different audio configuration (see attachment).
> I haven't yet tried if/how it works via HDMI yet, but the speakers and 
> headphones work fine.
> This patch is based on the following commit:
> https://github.com/TuxThePenguin0/linux/commit/
> 872b829a3511cfa853bd3af3bd4f30be1cb3d1ab

Yes, this fixes the headphone detection. I cannot test HDMI because of a missing
cable.

I will pick the change in v2.

> I've added 'Danct12' to the To list as they are the maintainer of the primary 
> PT2 image and we worked together to get to this audio config.
> I don't if they still use it.
> (I've been using my own kernel/image for a while now).

Thanks. I just crossed this repo:
https://github.com/dreemurrs-embedded/linux-pinetab2/tree/v6.6.7-danctnix1

It includes some more improvements I will pick for v2.

Regards
Manuel

> From 17efeb0ae766886345ff0574c534079742539b56 Mon Sep 17 00:00:00 2001
> From: Scott Santucci <ScottFreeCode at users.noreply.github.com>
> Date: Mon, 17 Jul 2023 13:06:20 +0200
> Subject: [PATCH 3/8] arm64: dts: rk3566-pinetab2: Fix audio configuration
> 
> The audio configuration of the PineTab2 matches the `rk817_ext` alsa
> ucm2 profile, so switch the configuration to that. Use `rk817_ext` and
> not `rk817_int` as the PineTab2 uses an external amplifier.
> 
> Also the headphones plugged/unplugged detection is backwards, so apply
> the fix provided by Danct12 <danct12 at disroot.org>.
> 
> Signed-off-by: Diederik de Haas <didi.debian at cknow.org>
> Link: https://github.com/dreemurrs-embedded/Pine64-Arch/pull/555
> ---
>  arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> index a766f21bd6f8..59e4bf2f77c7 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> @@ -116,14 +116,14 @@ rk817-sound {
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&hp_det_l>;
>  		simple-audio-card,format = "i2s";
> -		simple-audio-card,name = "PineTab2";
> +		simple-audio-card,name = "rk817_ext";
>  		simple-audio-card,mclk-fs = <256>;
>  
>  		simple-audio-card,widgets =
>  			"Microphone", "Mic Jack",
>  			"Headphone", "Headphones",
>  			"Microphone", "Microphone",
> -			"Speaker", "Speakers";
> +			"Speaker", "Internal Speakers";
>  
>  		simple-audio-card,routing =
>  			"MICL", "Microphone",
> @@ -132,12 +132,12 @@ rk817-sound {
>  			"Headphones", "HPOR",
>  			"Speaker Amplifier INL", "HPOL",
>  			"Speaker Amplifier INR", "HPOR",
> -			"Speakers", "Speaker Amplifier OUTL",
> -			"Speakers", "Speaker Amplifier OUTR";
> +			"Internal Speakers", "Speaker Amplifier OUTL",
> +			"Internal Speakers", "Speaker Amplifier OUTR";
>  
> -		simple-audio-card,hp-det-gpio = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
> +		simple-audio-card,hp-det-gpio = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>  		simple-audio-card,aux-devs = <&speaker_amp>;
> -		simple-audio-card,pin-switches = "Speakers", "Microphone";
> +		simple-audio-card,pin-switches = "Internal Speakers", "Microphone";
>  
>  		simple-audio-card,cpu {
>  			sound-dai = <&i2s1_8ch>;
> -- 
> 2.42.0
> 





From ruipengqi7 at gmail.com  Sat Dec 23 06:12:57 2023
From: ruipengqi7 at gmail.com (ruipeng qi)
Date: Sat, 23 Dec 2023 22:12:57 +0800
Subject: [PATCH 1/7] [RFC PATCH 1/7] osdump: Add one new os minidump module
In-Reply-To: <e9aa311f-6f13-410e-bb35-20320275668c@linaro.org>
References: <20231221130930.32634-1-ruipengqi7@gmail.com> <e9aa311f-6f13-410e-bb35-20320275668c@linaro.org>
Message-ID: <CADHLONGLZaZT4Ot56AnxOf=ROrTWvge5=NUx5uqKqJhpJibfOQ@mail.gmail.com>

On Fri, Dec 22, 2023 at 12:25?AM Krzysztof Kozlowski <krzysztof.kozlowski
@linaro.org> wrote:
> > Osdump is a new crash dumping solution aiming at specific embedded
> > devices within automotive or Industrial.
> >  - limited memory.
> >  - reboot as soon as possible when system fault.
>
> NAK, sorry, work with Qualcomm minidump series to incorporate all your
> needs there.

Sorry, I didn't explain it properly. Will add more descriptions in the
next version. Osdump is a totally different mindump, which aims at
helping to solve kernel issues as easy as kdump/kexec/crash, but
with little costs.

For something like Pstore, you can get where the issue occurs. You can
figure out the problem if it is easy, but sometimes you can't. For example:

<4>[    5.311431]  task_blocks_on_rt_mutex+0x234/0x380
<4>[    5.316166]  rt_spin_lock_slowlock_locked+0xcc/0x2b0
<4>[    5.321257]  rt_spin_lock_slowlock+0x5c/0x90
<4>[    5.325633]  rt_spin_lock+0x60/0x74
<4>[    5.329207]  refill_stock+0x58/0x230

You can find where the issue occurs.
static inline struct rt_mutex_waiter *rt_mutex_top_waiter(struct rt_mutex *lock)
 {
  struct rb_node *leftmost = rb_first_cached(&lock->waiters);
  struct rt_mutex_waiter *w = NULL;
  if (leftmost) {
    w = rb_entry(leftmost, struct rt_mutex_waiter, tree_entry);
    BUG_ON(w->lock != lock);

But you don't know why w->lock and lock are different, and who is wrong.

Qcom minidump can dump some logs like dmsg, some status like IRQ or
Run queue. This can help to learn some information when the issue occurs,
which will help to find out the root cause. But what it dumps are limited, it
doesn't dump w and lock if they are not local data.

For osdump, it dumps objects stored in slab, datas in bss, data segments,
some data alloced with memblock, data stored in local stack, and so on.
In a word, it dumps almost all of the key data in the kernel. Besides, you
can use the crash tool to analyze the dump file.

In a word, I think this toal different minidump should have its own place in
the kernel world. Looking forward to your suggestions!

Best Regards
Ruipeng


From krzysztof.kozlowski at linaro.org  Sat Dec 23 06:14:30 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 15:14:30 +0100
Subject: [PATCH 1/3] dt-bindings: timer: exynos4210-mct: Add
 google,gs101-mct compatible
In-Reply-To: <20231222165355.1462740-2-peter.griffin@linaro.org>
References: <20231222165355.1462740-1-peter.griffin@linaro.org>
 <20231222165355.1462740-2-peter.griffin@linaro.org>
Message-ID: <a4f4cf5a-ba51-4c5b-b9ce-3eddd1ec6bd7@linaro.org>

On 22/12/2023 17:53, Peter Griffin wrote:
> Add dedicated google,gs101-mct compatible to the dt-schema for
> representing mct timer of the Google Tensor gs101 SoC.
> 
> Signed-off-by: Peter Griffin <peter.griffin at linaro.org>


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

I assume this will go via clocksource/timer. But I am also fine taking
it via Samsung SoC tree if needed.

Best regards,
Krzysztof



From didi.debian at cknow.org  Sat Dec 23 06:17:58 2023
From: didi.debian at cknow.org (Diederik de Haas)
Date: Sat, 23 Dec 2023 15:17:58 +0100
Subject: [PATCH 4/6] arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2
In-Reply-To: <ZYbnxkkCIJtzqa0h@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net> <2121710.IWpXjAX0fk@bagend>
 <ZYbnxkkCIJtzqa0h@mecka.net>
Message-ID: <1883322.fLvJxeCpJd@bagend>

Hi Manuel,

On Saturday, 23 December 2023 14:59:34 CET Manuel Traut wrote:
> On Fri, Dec 22, 2023 at 06:01:54PM +0100, Diederik de Haas wrote:
> > On Friday, 22 December 2023 12:05:44 CET Manuel Traut wrote:
> > > +
> > > +&cru {
> > > +       assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>, <&cru
> > > PLL_VPLL>; +       assigned-clock-rates = <1200000000>, <200000000>,
> > > <500000000>; +};
> > 
> > Attachment seem to work and for this I also have the attached patch in my
> > patch set.
> > IIRC without it you get an error in dmesg immediately at boot up which is
> > visible on the PT2 *if* you have immediate visual output (which is not
> > (yet?) the case in my image/kernel).
> 
> you can see the message also by calling "dmesg --level err".
> I could verify that your patch removes the error message.

As I have been using that patch for a while, I couldn't verify it myself 
anymore ;-)
If you use the (default) danctnix image, then you see it immediately at boot 
up (at least the last time I tried it). With my (WIP) image, I only get visual 
output after 5-7 seconds, so you'll likely miss that visual error if the image 
you use also has a delay before outputting things on the screen.
But indeed, it would still show up in dmesg (without the patch).

> I will pick the change for v2.

Great :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231223/91ed0fe7/attachment.sig>

From krzysztof.kozlowski at linaro.org  Sat Dec 23 06:23:03 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 15:23:03 +0100
Subject: [PATCH 1/7] [RFC PATCH 1/7] osdump: Add one new os minidump
 module
In-Reply-To: <CADHLONGLZaZT4Ot56AnxOf=ROrTWvge5=NUx5uqKqJhpJibfOQ@mail.gmail.com>
References: <20231221130930.32634-1-ruipengqi7@gmail.com>
 <e9aa311f-6f13-410e-bb35-20320275668c@linaro.org>
 <CADHLONGLZaZT4Ot56AnxOf=ROrTWvge5=NUx5uqKqJhpJibfOQ@mail.gmail.com>
Message-ID: <6fe05804-da74-45cd-a6f1-df4644671d99@linaro.org>

On 23/12/2023 15:12, ruipeng qi wrote:
> On Fri, Dec 22, 2023 at 12:25?AM Krzysztof Kozlowski <krzysztof.kozlowski
> @linaro.org> wrote:
>>> Osdump is a new crash dumping solution aiming at specific embedded
>>> devices within automotive or Industrial.
>>>  - limited memory.
>>>  - reboot as soon as possible when system fault.
>>
>> NAK, sorry, work with Qualcomm minidump series to incorporate all your
>> needs there.
> 
> Sorry, I didn't explain it properly. Will add more descriptions in the
> next version. Osdump is a totally different mindump, which aims at
> helping to solve kernel issues as easy as kdump/kexec/crash, but
> with little costs.
> 
> For something like Pstore, you can get where the issue occurs. You can
> figure out the problem if it is easy, but sometimes you can't. For example:
> 
> <4>[    5.311431]  task_blocks_on_rt_mutex+0x234/0x380
> <4>[    5.316166]  rt_spin_lock_slowlock_locked+0xcc/0x2b0
> <4>[    5.321257]  rt_spin_lock_slowlock+0x5c/0x90
> <4>[    5.325633]  rt_spin_lock+0x60/0x74
> <4>[    5.329207]  refill_stock+0x58/0x230
> 
> You can find where the issue occurs.
> static inline struct rt_mutex_waiter *rt_mutex_top_waiter(struct rt_mutex *lock)
>  {
>   struct rb_node *leftmost = rb_first_cached(&lock->waiters);
>   struct rt_mutex_waiter *w = NULL;
>   if (leftmost) {
>     w = rb_entry(leftmost, struct rt_mutex_waiter, tree_entry);
>     BUG_ON(w->lock != lock);
> 
> But you don't know why w->lock and lock are different, and who is wrong.
> 
> Qcom minidump can dump some logs like dmsg, some status like IRQ or
> Run queue. This can help to learn some information when the issue occurs,
> which will help to find out the root cause. But what it dumps are limited, it
> doesn't dump w and lock if they are not local data.

So add missing features to it. I don't think you got my comment and keep
arguing on the same thing repeated for upstream submissions many times.
We do not want multiple vendor solutions. Every vendor wants his work
and does not care about integrating or reusing other pieces.

> 
> For osdump, it dumps objects stored in slab, datas in bss, data segments,
> some data alloced with memblock, data stored in local stack, and so on.
> In a word, it dumps almost all of the key data in the kernel. Besides, you
> can use the crash tool to analyze the dump file.

I don't see a problem why minidump cannot do it.

> 
> In a word, I think this toal different minidump should have its own place in
> the kernel world. Looking forward to your suggestions!

No, work with minidump.

For any further submissions which do not merge this work into minidump,
please carry:

Nacked-by: Krzysztof Kozlowski <krzk at kernel.org>

Best regards,
Krzysztof



From othacehe at gnu.org  Sat Dec 23 06:29:37 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Sat, 23 Dec 2023 15:29:37 +0100
Subject: [PATCH] arm64: dts: imx93-var-som: Add Variscite VAR-SOM-MX93
Message-ID: <20231223142939.23735-1-othacehe@gnu.org>

Add DTSI for Variscite VAR-SOM-MX93 System on Module and DTS for Variscite
VAR-SOM-MX93 on Symphony evaluation board.

This version comes with:
- NXP i.MX 93 Dual, 1.7GHz, Cortex-A55 + Cortex-M33
- 2 GB of RAM
- 16GB eMMC
- 802.11ax/ac/a/b/g/n WiFi with 5.3 Bluetooth
- CAN bus
- Audio codec

Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-var-som-symphony.dts  | 307 +++++++++++++++++
 .../boot/dts/freescale/imx93-var-som.dtsi     | 312 ++++++++++++++++++
 3 files changed, 620 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2e027675d7bb..a6f1700961e3 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -203,6 +203,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxca.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
 
 imx8mm-venice-gw72xx-0x-imx219-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-imx219.dtbo
 imx8mm-venice-gw72xx-0x-rpidsi-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rpidsi.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
new file mode 100644
index 000000000000..85b1355cf805
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 NXP
+ * Copyright 2023 Variscite Ltd.
+ */
+
+/dts-v1/;
+
+#include "imx93-var-som.dtsi"
+
+/{
+	model = "Variscite VAR-SOM-MX93 on Symphony evaluation board";
+	compatible = "variscite,var-som-imx93-symphony", "variscite,var-som-mx93", "fsl,imx93";
+
+	aliases {
+		ethernet1 = &fec;
+	};
+
+	chosen {
+		stdout-path = &lpuart1;
+	};
+
+	/*
+	 * Needed only for Symphony <= v1.5
+	 */
+	reg_fec_phy: regulator-fec-phy {
+		compatible = "regulator-fixed";
+		regulator-name = "fec-phy";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-enable-ramp-delay = <20000>;
+		gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	reg_usdhc2_vmmc: regulator-usdhc2 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+		regulator-name = "VSD_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+		off-on-delay-us = <20000>;
+		enable-active-high;
+	};
+
+	reg_vref_1v8: regulator-adc-vref {
+		compatible = "regulator-fixed";
+		regulator-name = "vref_1v8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		ethosu_mem: ethosu_region at 88000000 {
+			compatible = "shared-dma-pool";
+			reusable;
+			reg = <0x0 0x88000000 0x0 0x8000000>;
+		};
+
+		vdev0vring0: vdev0vring0 at 87ee0000 {
+			reg = <0 0x87ee0000 0 0x8000>;
+			no-map;
+		};
+
+		vdev0vring1: vdev0vring1 at 87ee8000 {
+			reg = <0 0x87ee8000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring0: vdev1vring0 at 87ef0000 {
+			reg = <0 0x87ef0000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring1: vdev1vring1 at 87ef8000 {
+			reg = <0 0x87ef8000 0 0x8000>;
+			no-map;
+		};
+
+		rsc_table: rsc-table at 2021f000 {
+			reg = <0 0x2021f000 0 0x1000>;
+			no-map;
+		};
+
+		vdevbuffer: vdevbuffer at 87f00000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x87f00000 0 0x100000>;
+			no-map;
+		};
+
+		ele_reserved: ele-reserved at 87de0000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x87de0000 0 0x100000>;
+			no-map;
+		};
+	};
+};
+
+/* Use external instead of internal RTC*/
+&bbnsm_rtc {
+	status = "disabled";
+};
+
+&eqos {
+	mdio {
+		ethphy1: ethernet-phy at 5 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <5>;
+			qca,disable-smarteee;
+			eee-broken-1000t;
+			reset-gpios = <&pca9534 5 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <20000>;
+			vddio-supply = <&vddio1>;
+
+			vddio1: vddio-regulator {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+			};
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy1>;
+	phy-supply = <&reg_fec_phy>;
+	status = "okay";
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_fec: fecgrp {
+		fsl,pins = <
+			MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0		0x57e
+			MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1		0x57e
+			MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2		0x57e
+			MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3		0x57e
+			MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC		0x5fe
+			MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL	0x57e
+			MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0		0x57e
+			MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1		0x57e
+			MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2		0x57e
+			MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3		0x57e
+			MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC		0x5fe
+			MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL	0x57e
+		>;
+	};
+
+	pinctrl_flexcan1: flexcan1grp {
+		fsl,pins = <
+			MX93_PAD_PDM_CLK__CAN1_TX                       0x139e
+			MX93_PAD_PDM_BIT_STREAM0__CAN1_RX               0x139e
+		>;
+	};
+
+	pinctrl_lpi2c1: lpi2c1grp {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__LPI2C1_SCL			0x40000b9e
+			MX93_PAD_I2C1_SDA__LPI2C1_SDA			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c1_gpio: lpi2c1grp-gpio {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__GPIO1_IO00			0x31e
+			MX93_PAD_I2C1_SDA__GPIO1_IO01			0x31e
+		>;
+	};
+
+	pinctrl_lpi2c5: lpi2c5grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO23__LPI2C5_SCL			0x40000b9e
+			MX93_PAD_GPIO_IO22__LPI2C5_SDA			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c5_gpio: lpi2c5grp-gpio {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO23__GPIO2_IO23			0x31e
+			MX93_PAD_GPIO_IO22__GPIO2_IO22			0x31e
+		>;
+	};
+
+	pinctrl_pca9534: pca9534grp {
+		fsl,pins = <
+			MX93_PAD_CCM_CLKO1__GPIO3_IO26		0x31e
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX93_PAD_UART1_RXD__LPUART1_RX			0x31e
+			MX93_PAD_UART1_TXD__LPUART1_TX			0x31e
+		>;
+	};
+
+	pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO18__GPIO2_IO18		0x31e
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX93_PAD_SD2_CLK__USDHC2_CLK		0x15fe
+			MX93_PAD_SD2_CMD__USDHC2_CMD		0x13fe
+			MX93_PAD_SD2_DATA0__USDHC2_DATA0	0x13fe
+			MX93_PAD_SD2_DATA1__USDHC2_DATA1	0x13fe
+			MX93_PAD_SD2_DATA2__USDHC2_DATA2	0x13fe
+			MX93_PAD_SD2_DATA3__USDHC2_DATA3	0x13fe
+			MX93_PAD_SD2_VSELECT__USDHC2_VSELECT	0x51e
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+		fsl,pins = <
+			MX93_PAD_SD2_CD_B__GPIO3_IO00		0x31e
+		>;
+	};
+};
+
+&lpi2c1 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c1>;
+	pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
+	pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
+	scl-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	/* DS1337 RTC module */
+	rtc at 68 {
+		status = "okay";
+		compatible = "dallas,ds1337";
+		reg = <0x68>;
+	};
+};
+
+&lpi2c5 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c5>;
+	pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+	pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
+	scl-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	pca9534: gpio at 20 {
+		status = "okay";
+		compatible = "nxp,pca9534";
+		reg = <0x20>;
+		gpio-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9534>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+		#gpio-cells = <2>;
+		wakeup-source;
+	};
+};
+
+/* Console */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
+	vmmc-supply = <&reg_usdhc2_vmmc>;
+	bus-width = <4>;
+	status = "okay";
+	no-sdio;
+	no-mmc;
+};
+
+/* Watchdog */
+&wdog3 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
new file mode 100644
index 000000000000..30b969d0134d
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 NXP
+ * Copyright 2023 Variscite Ltd.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx93.dtsi"
+
+/{
+	model = "Variscite VAR-SOM-MX93 module";
+	compatible = "variscite,var-som-imx93", "fsl,imx93";
+
+	iw612_pwrseq: iw612_pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		post-power-on-delay-ms = <100>;
+		power-off-delay-us = <10000>;
+		reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>,	/* WIFI_RESET */
+			      <&gpio3 7 GPIO_ACTIVE_LOW>;	/* WIFI_PWR_EN */
+		status = "okay";
+	};
+
+	reg_eqos_phy: regulator-eqos-phy {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_eqos_phy>;
+		regulator-name = "eth_phy_pwr";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		startup-delay-us = <100000>;
+		regulator-always-on;
+	};
+};
+
+&eqos {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_eqos>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+	phy-supply = <&reg_eqos_phy>;
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clock-frequency = <1000000>;
+
+		ethphy0: ethernet-phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
+			eee-broken-1000t;
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl_bt: btgrp {
+		fsl,pins = <
+			MX93_PAD_ENET2_MDIO__GPIO4_IO15				0x51e
+		>;
+	};
+
+	pinctrl_eqos: eqosgrp {
+		fsl,pins = <
+			MX93_PAD_ENET1_MDC__ENET_QOS_MDC			0x57e
+			MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO			0x57e
+			MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0			0x57e
+			MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1			0x57e
+			MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2			0x57e
+			MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3			0x57e
+			MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK	0x5fe
+			MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL		0x57e
+			MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0			0x57e
+			MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1			0x57e
+			MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2			0x57e
+			MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3			0x57e
+			MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK	0x5fe
+			MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL		0x57e
+		>;
+	};
+
+	pinctrl_lpi2c3: lpi2c3grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO28__LPI2C3_SDA			0x40000b9e
+			MX93_PAD_GPIO_IO29__LPI2C3_SCL			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c3_gpio: lpi2c3grp-gpio {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO28__GPIO2_IO28			0x40000b9e
+			MX93_PAD_GPIO_IO29__GPIO2_IO29			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpspi8: lpspi8grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO12__GPIO2_IO12			0x31e
+			MX93_PAD_GPIO_IO13__LPSPI8_SIN			0x31e
+			MX93_PAD_GPIO_IO14__LPSPI8_SOUT			0x31e
+			MX93_PAD_GPIO_IO15__LPSPI8_SCK			0x31e
+		>;
+	};
+
+	pinctrl_reg_eqos_phy: regeqosgrp {
+		fsl,pins = <
+			MX93_PAD_UART2_TXD__GPIO1_IO07			0x51e
+		>;
+	};
+
+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			MX93_PAD_ENET2_MDC__GPIO4_IO14			0x51e /* WIFI_REG_ON     */
+			MX93_PAD_SD2_RESET_B__GPIO3_IO07		0x51e /* WIFI_PWR_EN     */
+		>;
+	};
+
+	pinctrl_restouch: restouchgrp {
+		fsl,pins = <
+			MX93_PAD_CCM_CLKO4__GPIO4_IO29			0x31e
+		>;
+	};
+
+	pinctrl_sai1: sai1grp {
+		fsl,pins = <
+			MX93_PAD_SAI1_TXC__SAI1_TX_BCLK			0x31e
+			MX93_PAD_SAI1_TXFS__SAI1_TX_SYNC		0x31e
+			MX93_PAD_SAI1_TXD0__SAI1_TX_DATA00		0x31e
+			MX93_PAD_SAI1_RXD0__SAI1_RX_DATA00		0x31e
+			MX93_PAD_I2C2_SDA__SAI1_RX_BCLK			0x31e
+			MX93_PAD_I2C2_SCL__SAI1_RX_SYNC			0x31e
+			MX93_PAD_UART2_RXD__SAI1_MCLK			0x31e
+		>;
+	};
+
+	pinctrl_sai1_sleep: sai1grp-sleep {
+		fsl,pins = <
+			MX93_PAD_SAI1_TXC__GPIO1_IO12		0x31e
+			MX93_PAD_SAI1_TXFS__GPIO1_IO11		0x31e
+			MX93_PAD_SAI1_TXD0__GPIO1_IO13		0x31e
+			MX93_PAD_SAI1_RXD0__GPIO1_IO14		0x31e
+			MX93_PAD_UART2_RXD__GPIO1_IO06		0x31e
+			MX93_PAD_I2C2_SDA__GPIO1_IO03		0x31e
+			MX93_PAD_I2C2_SCL__GPIO1_IO02		0x31e
+		>;
+	};
+
+	pinctrl_uart5: uart5grp {
+		fsl,pins = <
+			MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX	0x31e
+			MX93_PAD_DAP_TDI__LPUART5_RX		0x31e
+			MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B	0x31e
+			MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B	0x31e
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX93_PAD_SD1_CLK__USDHC1_CLK		0x15fe
+			MX93_PAD_SD1_CMD__USDHC1_CMD		0x13fe
+			MX93_PAD_SD1_DATA0__USDHC1_DATA0	0x13fe
+			MX93_PAD_SD1_DATA1__USDHC1_DATA1	0x13fe
+			MX93_PAD_SD1_DATA2__USDHC1_DATA2	0x13fe
+			MX93_PAD_SD1_DATA3__USDHC1_DATA3	0x13fe
+			MX93_PAD_SD1_DATA4__USDHC1_DATA4	0x13fe
+			MX93_PAD_SD1_DATA5__USDHC1_DATA5	0x13fe
+			MX93_PAD_SD1_DATA6__USDHC1_DATA6	0x13fe
+			MX93_PAD_SD1_DATA7__USDHC1_DATA7	0x13fe
+			MX93_PAD_SD1_STROBE__USDHC1_STROBE	0x15fe
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX93_PAD_SD3_CLK__USDHC3_CLK		0x1382
+			MX93_PAD_SD3_CMD__USDHC3_CMD		0x1382
+			MX93_PAD_SD3_DATA0__USDHC3_DATA0	0x1382
+			MX93_PAD_SD3_DATA1__USDHC3_DATA1	0x1382
+			MX93_PAD_SD3_DATA2__USDHC3_DATA2	0x1382
+			MX93_PAD_SD3_DATA3__USDHC3_DATA3	0x1382
+		>;
+	};
+
+	pinctrl_usdhc3_sleep: usdhc3grp-sleep {
+		fsl,pins = <
+			MX93_PAD_SD3_CLK__GPIO3_IO20		0x400
+			MX93_PAD_SD3_CMD__GPIO3_IO21		0x400
+			MX93_PAD_SD3_DATA0__GPIO3_IO22		0x400
+			MX93_PAD_SD3_DATA1__GPIO3_IO23		0x400
+			MX93_PAD_SD3_DATA2__GPIO3_IO24		0x400
+			MX93_PAD_SD3_DATA3__GPIO3_IO25		0x400
+		>;
+	};
+};
+
+&lpi2c3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c3>;
+	pinctrl-1 = <&pinctrl_lpi2c3_gpio>;
+	pinctrl-2 = <&pinctrl_lpi2c3_gpio>;
+	scl-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	pmic at 25 {
+		compatible = "nxp,pca9451a";
+		reg = <0x25>;
+
+		regulators {
+			buck1: BUCK1 {
+				regulator-name = "BUCK1";
+				regulator-min-microvolt = <650000>;
+				regulator-max-microvolt = <2237500>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <3125>;
+			};
+
+			buck2: BUCK2 {
+				regulator-name = "BUCK2";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <2187500>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <3125>;
+			};
+
+			buck4: BUCK4{
+				regulator-name = "BUCK4";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buck5: BUCK5{
+				regulator-name = "BUCK5";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buck6: BUCK6 {
+				regulator-name = "BUCK6";
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo1: LDO1 {
+				regulator-name = "LDO1";
+				regulator-min-microvolt = <1600000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo2: LDO2 {
+				regulator-name = "LDO2";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1150000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo3: LDO3 {
+				regulator-name = "LDO3";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo4: LDO4 {
+				regulator-name = "LDO4";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo5: LDO5 {
+				regulator-name = "LDO5";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+};
+
+/* eMMC */
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1>;
+	pinctrl-2 = <&pinctrl_usdhc1>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
-- 
2.41.0



From krzk at kernel.org  Sat Dec 23 06:30:55 2023
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 15:30:55 +0100
Subject: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO
In-Reply-To: <20231222195144.24532-12-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
 <20231222195144.24532-12-graf@amazon.com>
Message-ID: <39a33f9b-0290-428d-ab1f-f90856cdb31d@kernel.org>

On 22/12/2023 20:51, Alexander Graf wrote:
> With ftrace in KHO, we are creating an ABI between old kernel and new
> kernel about the state that they transfer. To ensure that we document
> that state and catch any breaking change, let's add its schema to the
> common devicetree bindings. This way, we can quickly reason about the
> state that gets passed.

Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC (and consider --no-git-fallback argument). It might
happen, that command when run on an older kernel, gives you outdated
entries. Therefore please be sure you base your patches on recent Linux
kernel.

Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.

A nit, subject: drop second/last, redundant "bindings". The
"dt-bindings" prefix is already stating that these are bindings.

> 
> Signed-off-by: Alexander Graf <graf at amazon.com>
> ---
>  .../bindings/kho/ftrace/ftrace-array.yaml     | 46 +++++++++++++++
>  .../bindings/kho/ftrace/ftrace-cpu.yaml       | 56 +++++++++++++++++++
>  .../bindings/kho/ftrace/ftrace.yaml           | 48 ++++++++++++++++
>  3 files changed, 150 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
>  create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
>  create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> 
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> new file mode 100644
> index 000000000000..9960fefc292d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-array.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace trace array
> +

Missing description. Commit msg also does not tell me much. This must
stand on its own and must describe the hardware. Whatever you have in
cover letter, does not matter, especially that you did not Cc us on it.

> +maintainers:
> +  - Alexander Graf <graf at amazon.com>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - ftrace,array-v1
> +
> +  trace_flags:

Underscores are not allowed. Does not look like generic property.


> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      Bitmap of all the trace flags that were enabled in the trace array at the
> +      point of serialization.
> +
> +# Subnodes will be of type "ftrace,cpu-v1", one each per CPU

> +additionalProperties: true

No, this must be false. And it goes after required:


> +
> +required:
> +  - compatible
> +  - trace_flags
> +
> +examples:
> +  - |
> +    ftrace {
> +        compatible = "ftrace-v1";
> +        events = <1 1 2 2 3 3>;
> +
> +        global_trace {

Again, no underscores.

> +          compatible = "ftrace,array-v1";
> +          trace_flags = < 0x3354601 >;
> +
> +          cpu0 {
> +            compatible = "ftrace,cpu-v1";
> +            cpu = < 0x00 >;

Drop redundant spaces.

> +            mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;

? Do you see any of such syntax in DTS?

Best regards,
Krzysztof



From mathieu.poirier at linaro.org  Sat Dec 23 06:34:02 2023
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Sat, 23 Dec 2023 07:34:02 -0700
Subject: [PATCH v8 2/3] dts: zynqmp: add properties for TCM in remoteproc
In-Reply-To: <e9e9777d-f8c1-48cd-b433-0292c77f6d57@amd.com>
References: <20231215235725.1247350-1-tanmay.shah@amd.com> <20231215235725.1247350-3-tanmay.shah@amd.com>
 <6ab19ceb-38ed-4e4c-aabc-a959bc123cf2@amd.com> <e9e9777d-f8c1-48cd-b433-0292c77f6d57@amd.com>
Message-ID: <CANLsYkxJyKFm4LR_JJx-kQMs=xa1C=SnD1Ha=jGqXM5nfy5dxw@mail.gmail.com>

On Wed, 20 Dec 2023 at 07:45, Tanmay Shah <tanmay.shah at amd.com> wrote:
>
>
> On 12/20/23 7:14 AM, Michal Simek wrote:
> >
> > On 12/16/23 00:57, Tanmay Shah wrote:
> > > Add properties as per new bindings in zynqmp remoteproc node
> > > to represent TCM address and size.
> > >
> > > This patch also adds alternative remoteproc node to represent
> > > remoteproc cluster in split mode. By default lockstep mode is
> > > enabled and users should disable it before using split mode
> > > dts. Both device-tree nodes can't be used simultaneously one
> > > of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
> > > remoteproc split mode dts node is enabled and lockstep mode
> > > dts is disabled.
> > >
> > > Signed-off-by: Tanmay Shah <tanmay.shah at amd.com>
> > > ---
> > >   .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts  |  8 +++
> > >   arch/arm64/boot/dts/xilinx/zynqmp.dtsi        | 60 +++++++++++++++++--
> > >   2 files changed, 63 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
> > > index c8f71a1aec89..495ca94b45db 100644
> > > --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
> > > +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
> > > @@ -14,6 +14,14 @@ / {
> > >     compatible = "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102", "xlnx,zynqmp";
> > >   };
> > >
> > > +&rproc_split {
> > > +   status = "okay";
> > > +};
> > > +
> > > +&rproc_lockstep {
> > > +   status = "disabled";
> > > +};
> > > +
> > >   &eeprom {
> > >     #address-cells = <1>;
> > >     #size-cells = <1>;
> > > diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > > index b61fc99cd911..602e6aba7ac5 100644
> > > --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > > +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> > > @@ -247,19 +247,69 @@ fpga_full: fpga-full {
> > >             ranges;
> > >     };
> > >
> > > -   remoteproc {
> > > +   rproc_lockstep: remoteproc at ffe00000 {
> > >             compatible = "xlnx,zynqmp-r5fss";
> > >             xlnx,cluster-mode = <1>;
> > >
> > > -           r5f-0 {
> > > +           #address-cells = <2>;
> > > +           #size-cells = <2>;
> > > +
> > > +           ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x20000>,
> > > +                    <0x0 0x20000 0x0 0xffe20000 0x0 0x20000>,
> > > +                    <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
> > > +                    <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
> > > +
> > > +           r5f at 0 {
> > > +                   compatible = "xlnx,zynqmp-r5f";
> > > +                   reg = <0x0 0x0 0x0 0x20000>, <0x0 0x20000 0x0 0x20000>;
> > > +                   reg-names = "atcm", "btcm";
> > > +                   power-domains = <&zynqmp_firmware PD_RPU_0>,
> > > +                                   <&zynqmp_firmware PD_R5_0_ATCM>,
> > > +                                   <&zynqmp_firmware PD_R5_0_BTCM>;
> > > +                   memory-region = <&rproc_0_fw_image>;
> > > +           };
> > > +
> > > +           r5f at 1 {
> > > +                   compatible = "xlnx,zynqmp-r5f";
> > > +                   reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
> > > +                   reg-names = "atcm", "btcm";
> > > +                   power-domains = <&zynqmp_firmware PD_RPU_1>,
> > > +                                   <&zynqmp_firmware PD_R5_1_ATCM>,
> > > +                                   <&zynqmp_firmware PD_R5_1_BTCM>;
> > > +                   memory-region = <&rproc_1_fw_image>;
> > > +           };
> > > +   };
> > > +
> > > +   rproc_split: remoteproc-split at ffe00000 {
> > > +           status = "disabled";
> > > +           compatible = "xlnx,zynqmp-r5fss";
> > > +           xlnx,cluster-mode = <0>;
> > > +
> > > +           #address-cells = <2>;
> > > +           #size-cells = <2>;
> > > +
> > > +           ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
> > > +                    <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
> > > +                    <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
> > > +                    <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
> > > +
> > > +           r5f at 0 {
> > >                     compatible = "xlnx,zynqmp-r5f";
> > > -                   power-domains = <&zynqmp_firmware PD_RPU_0>;
> > > +                   reg = <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0x0 0x10000>;
> > > +                   reg-names = "atcm", "btcm";
> > > +                   power-domains = <&zynqmp_firmware PD_RPU_0>,
> > > +                                   <&zynqmp_firmware PD_R5_0_ATCM>,
> > > +                                   <&zynqmp_firmware PD_R5_0_BTCM>;
> > >                     memory-region = <&rproc_0_fw_image>;
> > >             };
> > >
> > > -           r5f-1 {
> > > +           r5f at 1 {
> > >                     compatible = "xlnx,zynqmp-r5f";
> > > -                   power-domains = <&zynqmp_firmware PD_RPU_1>;
> > > +                   reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
> > > +                   reg-names = "atcm", "btcm";
> > > +                   power-domains = <&zynqmp_firmware PD_RPU_1>,
> > > +                                   <&zynqmp_firmware PD_R5_1_ATCM>,
> > > +                                   <&zynqmp_firmware PD_R5_1_BTCM>;
> > >                     memory-region = <&rproc_1_fw_image>;
> > >             };
> > >     };
> >
> > Acked-by: Michal Simek <michal.simek at amd.com>
> >
> > Let me know if you want me to take this via my tree.
>
> Hi Michal,
>
> Thanks for reviews. I will ping you once driver changes are approved.

I'll pick this up with the rest of the driver.  It will be easier that way.

>
> Or Mathieu can take this in remoteproc tree, either way is fine.
>
> But I would like to wait till driver changes are approved.
>
> Tanmay
>
> >
> > Thanks,
> > Michal


From krzysztof.kozlowski at linaro.org  Sat Dec 23 06:39:05 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 15:39:05 +0100
Subject: [PATCH] arm64: dts: imx93-var-som: Add Variscite VAR-SOM-MX93
In-Reply-To: <20231223142939.23735-1-othacehe@gnu.org>
References: <20231223142939.23735-1-othacehe@gnu.org>
Message-ID: <3ad14d62-df64-45b1-9be4-008d30d2b52f@linaro.org>

On 23/12/2023 15:29, Mathieu Othacehe wrote:
> Add DTSI for Variscite VAR-SOM-MX93 System on Module and DTS for Variscite
> VAR-SOM-MX93 on Symphony evaluation board.
> 
> This version comes with:
> - NXP i.MX 93 Dual, 1.7GHz, Cortex-A55 + Cortex-M33
> - 2 GB of RAM
> - 16GB eMMC
> - 802.11ax/ac/a/b/g/n WiFi with 5.3 Bluetooth
> - CAN bus
> - Audio codec
> 
> Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
> ---
>  arch/arm64/boot/dts/freescale/Makefile        |   1 +
>  .../dts/freescale/imx93-var-som-symphony.dts  | 307 +++++++++++++++++
>  .../boot/dts/freescale/imx93-var-som.dtsi     | 312 ++++++++++++++++++
>  3 files changed, 620 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
>  create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
> 
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 2e027675d7bb..a6f1700961e3 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -203,6 +203,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxca.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
>  
>  imx8mm-venice-gw72xx-0x-imx219-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-imx219.dtbo
>  imx8mm-venice-gw72xx-0x-rpidsi-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rpidsi.dtbo
> diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
> new file mode 100644
> index 000000000000..85b1355cf805
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
> @@ -0,0 +1,307 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2021 NXP
> + * Copyright 2023 Variscite Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "imx93-var-som.dtsi"
> +
> +/{
> +	model = "Variscite VAR-SOM-MX93 on Symphony evaluation board";
> +	compatible = "variscite,var-som-imx93-symphony", "variscite,var-som-mx93", "fsl,imx93";

Please run scripts/checkpatch.pl and fix reported warnings. Some
warnings can be ignored, but the code here looks like it needs a fix.
Feel free to get in touch if the warning is not clear.

Also, wrap it at 80.

> +
> +	aliases {
> +		ethernet1 = &fec;
> +	};
> +
> +	chosen {
> +		stdout-path = &lpuart1;
> +	};
> +
> +	/*
> +	 * Needed only for Symphony <= v1.5
> +	 */
> +	reg_fec_phy: regulator-fec-phy {
> +		compatible = "regulator-fixed";
> +		regulator-name = "fec-phy";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		regulator-enable-ramp-delay = <20000>;
> +		gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +		regulator-always-on;
> +	};
> +
> +	reg_usdhc2_vmmc: regulator-usdhc2 {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
> +		regulator-name = "VSD_3V3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
> +		off-on-delay-us = <20000>;
> +		enable-active-high;
> +	};
> +
> +	reg_vref_1v8: regulator-adc-vref {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vref_1v8";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +	};
> +
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		ethosu_mem: ethosu_region at 88000000 {

No underscores in node names.

Please do not upstream downstream DTS, but fix it to match proper Linux
coding style.

...


> +	pinctrl_lpi2c1: lpi2c1grp {
> +		fsl,pins = <
> +			MX93_PAD_I2C1_SCL__LPI2C1_SCL			0x40000b9e
> +			MX93_PAD_I2C1_SDA__LPI2C1_SDA			0x40000b9e
> +		>;
> +	};
> +
> +	pinctrl_lpi2c1_gpio: lpi2c1grp-gpio {

It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).


...

> +
> +&lpi2c1 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default", "sleep", "gpio";
> +	pinctrl-0 = <&pinctrl_lpi2c1>;
> +	pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
> +	pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
> +	scl-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
> +	sda-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
> +	status = "okay";
> +
> +	/* DS1337 RTC module */
> +	rtc at 68 {
> +		status = "okay";

Drop. It is never the first property, BTW.

> +		compatible = "dallas,ds1337";
> +		reg = <0x68>;
> +	};
> +};
> +
> +&lpi2c5 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default", "sleep", "gpio";
> +	pinctrl-0 = <&pinctrl_lpi2c5>;
> +	pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
> +	pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
> +	scl-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;
> +	sda-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
> +	status = "okay";
> +
> +	pca9534: gpio at 20 {
> +		status = "okay";

Drop.

> +		compatible = "nxp,pca9534";
> +		reg = <0x20>;
> +		gpio-controller;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pca9534>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
> +		#gpio-cells = <2>;
> +		wakeup-source;
> +	};
> +};

...

> diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
> new file mode 100644
> index 000000000000..30b969d0134d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
> @@ -0,0 +1,312 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2022 NXP
> + * Copyright 2023 Variscite Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/usb/pd.h>
> +#include "imx93.dtsi"
> +
> +/{
> +	model = "Variscite VAR-SOM-MX93 module";
> +	compatible = "variscite,var-som-imx93", "fsl,imx93";

Please run scripts/checkpatch.pl and fix reported warnings. Some
warnings can be ignored, but the code here looks like it needs a fix.
Feel free to get in touch if the warning is not clear.

> +
> +	iw612_pwrseq: iw612_pwrseq {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation


> +		compatible = "mmc-pwrseq-simple";
> +		post-power-on-delay-ms = <100>;
> +		power-off-delay-us = <10000>;
> +		reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>,	/* WIFI_RESET */
> +			      <&gpio3 7 GPIO_ACTIVE_LOW>;	/* WIFI_PWR_EN */
> +		status = "okay";

Drop

....

> +	pinctrl_lpi2c3: lpi2c3grp {
> +		fsl,pins = <
> +			MX93_PAD_GPIO_IO28__LPI2C3_SDA			0x40000b9e
> +			MX93_PAD_GPIO_IO29__LPI2C3_SCL			0x40000b9e
> +		>;
> +	};
> +
> +	pinctrl_lpi2c3_gpio: lpi2c3grp-gpio {

It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).

...

> +
> +&lpi2c3 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default", "sleep", "gpio";
> +	pinctrl-0 = <&pinctrl_lpi2c3>;
> +	pinctrl-1 = <&pinctrl_lpi2c3_gpio>;
> +	pinctrl-2 = <&pinctrl_lpi2c3_gpio>;
> +	scl-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
> +	sda-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>;
> +	status = "okay";
> +
> +	pmic at 25 {
> +		compatible = "nxp,pca9451a";

Please run scripts/checkpatch.pl and fix reported warnings. Some
warnings can be ignored, but the code here looks like it needs a fix.
Feel free to get in touch if the warning is not clear.

I don't see this compatible documented and cover letter or changelog
does not mention neither dependencies nor other series bringing it.

> +		reg = <0x25>;
> +
> +		regulators {
> +			buck1: BUCK1 {

Lowercase

> +				regulator-name = "BUCK1";
> +				regulator-min-microvolt = <650000>;
> +				regulator-max-microvolt = <2237500>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +				regulator-ramp-delay = <3125>;
> +			};
> +
> +			buck2: BUCK2 {

Lowercase, further as well

...

Best regards,
Krzysztof



From ruipengqi7 at gmail.com  Sat Dec 23 07:13:22 2023
From: ruipengqi7 at gmail.com (ruipeng qi)
Date: Sat, 23 Dec 2023 23:13:22 +0800
Subject: [PATCH 1/7] [RFC PATCH 1/7] osdump: Add one new os minidump module
In-Reply-To: <6fe05804-da74-45cd-a6f1-df4644671d99@linaro.org>
References: <20231221130930.32634-1-ruipengqi7@gmail.com> <e9aa311f-6f13-410e-bb35-20320275668c@linaro.org>
 <CADHLONGLZaZT4Ot56AnxOf=ROrTWvge5=NUx5uqKqJhpJibfOQ@mail.gmail.com> <6fe05804-da74-45cd-a6f1-df4644671d99@linaro.org>
Message-ID: <CADHLONE2YnBJGJUp2-vn_XEpc7+quTMWF7y1zpV0ygeL2VpQxA@mail.gmail.com>

On Sat, Dec 23, 2023 at 10:23?PM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:

> > Qcom minidump can dump some logs like dmsg, some status like IRQ or
> > Run queue. This can help to learn some information when the issue occurs,
> > which will help to find out the root cause. But what it dumps are limited, it
> > doesn't dump w and lock if they are not local data.
>
> So add missing features to it. I don't think you got my comment and keep
> arguing on the same thing repeated for upstream submissions many times.
> We do not want multiple vendor solutions. Every vendor wants his work
> and does not care about integrating or reusing other pieces.
>
> >
> > For osdump, it dumps objects stored in slab, datas in bss, data segments,
> > some data alloced with memblock, data stored in local stack, and so on.
> > In a word, it dumps almost all of the key data in the kernel. Besides, you
> > can use the crash tool to analyze the dump file.
>
> I don't see a problem why minidump cannot do it.
Qcom minidump allows one kernel client to register its region to dump, and then
driver will create and maintain one elf head for it.
But osdump will dump thousands of non-continuous regions. If you register one
by one, and add an elf head for each, it will cause heavy overhead. So it store
data in binary, and reassemble a standard elf format file offline for debug.

Sir, I am not really familiar with Qcom minidump, and some options may be wrong.
But do you think it is ok to integrate osdump to Qcom? Looking forward to your
suggestions!

Best Regards
Ruipeng


From manut at mecka.net  Sat Dec 23 07:20:15 2023
From: manut at mecka.net (Manuel Traut)
Date: Sat, 23 Dec 2023 16:20:15 +0100
Subject: [PATCH v2 1/4] dt-bindings: display: panel: Add BOE
 TH101MB31IG002-28A panel
In-Reply-To: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
References: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
Message-ID: <20231223-pinetab2-v2-1-ec1856d0030e@mecka.net>

Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
used e.g. in the Pine64 Pinetab2 and PinetabV.

Signed-off-by: Manuel Traut <manut at mecka.net>
---
 .../display/panel/boe,th101mb31ig002-28a.yaml      | 58 ++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
new file mode 100644
index 000000000000..32df26cbfeed
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,th101mb31ig002-28a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TH101MB31IG002-28A WXGA DSI Display Panel
+
+maintainers:
+  - Manuel Traut <manut at mecka.net>
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+    enum:
+        # BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel
+      - boe,th101mb31ig002-28a
+
+  reg: true
+  backlight: true
+  enable-gpios: true
+  power-supply: true
+  port: true
+  rotation: true
+
+required:
+  - compatible
+  - reg
+  - enable-gpios
+  - power-supply
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    dsi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        panel at 0 {
+            compatible = "boe,th101mb31ig002-28a";
+            reg = <0>;
+            backlight = <&backlight_lcd0>;
+            enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
+            rotation = <90>;
+            power-supply = <&vcc_3v3>;
+            port {
+                panel_in_dsi: endpoint {
+                    remote-endpoint = <&dsi_out_con>;
+                };
+            };
+        };
+    };
+
+...

-- 
2.43.0



From manut at mecka.net  Sat Dec 23 07:20:14 2023
From: manut at mecka.net (Manuel Traut)
Date: Sat, 23 Dec 2023 16:20:14 +0100
Subject: [PATCH v2 0/4] arm64: rockchip: Pine64 pinetab2 support
Message-ID: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>

This adds support for the BOE TH101MB31IG002 LCD Panel used in Pinetab2 [1] and
Pinetab-V [2] as well as the devictrees for the Pinetab2 v0.1 and v2.0.

The BOE LCD Panel patch was retrieved from [3]. The function-name prefix has
been adapted and the LCD init section was simplified.

The Pinetab2 devicetree patch was retrieved from [4]. Some renaming was needed
to pass the dtb-checks, the brightness-levels are specified as range and steps
instead of a list of values.

[5] was also used as source for this queue.

The last to patches fix some dtb-checker warnings that showed up with the new
device-trees.

[1] https://wiki.pine64.org/wiki/PineTab2
[2] https://wiki.pine64.org/wiki/PineTab-V
[3] https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/display/0018-drm-panel-add-BOE-TH101MB31IG002-28A-driver.patch?ref_type=heads
[4] https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/device-tree/0134-arch-arm64-add-Pine64-PineTab2-device-trees.patch?ref_type=heads
[5] https://github.com/dreemurrs-embedded/linux-pinetab2/tree/v6.6.7-danctnix1

Signed-off-by: Manuel Traut <manut at mecka.net>
---
Changes in v2:
- Removed dtb-checker fixups, cause I am not sure if they are correct
- Applied review comments for dt bindings
- pinetab2 dts:
    * Remove unverified WLAN entries, as in [5]
    * Simplify flash LED definition, as in [5]
    * Fix headphone detection and sound routing, as in [5]
    * Fix CRU clock configuration
- BOE TH101MB31IG002 LCD Panel:
    * Reworked prepare/enable unprepare/disable, as in [5]
- Replaced nicknames by realnames in author and signed-offs

- Link to v1: https://lore.kernel.org/r/20231222-pinetab2-v1-0-e148a7f61bd1 at mecka.net

---
Alexander Warnecke (2):
      drm/panel: Add driver for BOE TH101MB31IG002-28A panel
      arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2

Manuel Traut (2):
      dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel
      dt-bindings: arm64: rockchip: Add Pine64 Pinetab2

 .../devicetree/bindings/arm/rockchip.yaml          |   8 +
 .../display/panel/boe,th101mb31ig002-28a.yaml      |  58 ++
 arch/arm64/boot/dts/rockchip/Makefile              |   2 +
 .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts     |  26 +
 .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts     |  46 +
 arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi  | 979 +++++++++++++++++++++
 drivers/gpu/drm/panel/Kconfig                      |  11 +
 drivers/gpu/drm/panel/Makefile                     |   1 +
 .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c   | 348 ++++++++
 9 files changed, 1479 insertions(+)
---
base-commit: 5254c0cbc92d2a08e75443bdb914f1c4839cdf5a
change-id: 20231222-pinetab2-faa77e01db6f

Best regards,
-- 
Manuel Traut <manut at mecka.net>



From manut at mecka.net  Sat Dec 23 07:20:17 2023
From: manut at mecka.net (Manuel Traut)
Date: Sat, 23 Dec 2023 16:20:17 +0100
Subject: [PATCH v2 3/4] dt-bindings: arm64: rockchip: Add Pine64 Pinetab2
In-Reply-To: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
References: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
Message-ID: <20231223-pinetab2-v2-3-ec1856d0030e@mecka.net>

Add devicvetree binding documentation for Pine64 Pinetab2
which uses the Rockchip RK3566 SoC.

Signed-off-by: Manuel Traut <manut at mecka.net>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5f7c6c4aad8f..96d54b0587ab 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -635,6 +635,14 @@ properties:
           - const: pine64,pinenote
           - const: rockchip,rk3566
 
+      - description: Pine64 PineTab2
+        items:
+          - enum:
+              - pine64,pinetab2-v0.1
+              - pine64,pinetab2-v2.0
+          - const: pine64,pinetab2
+          - const: rockchip,rk3566
+
       - description: Pine64 PinePhonePro
         items:
           - const: pine64,pinephone-pro

-- 
2.43.0



From manut at mecka.net  Sat Dec 23 07:20:16 2023
From: manut at mecka.net (Manuel Traut)
Date: Sat, 23 Dec 2023 16:20:16 +0100
Subject: [PATCH v2 2/4] drm/panel: Add driver for BOE TH101MB31IG002-28A
 panel
In-Reply-To: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
References: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
Message-ID: <20231223-pinetab2-v2-2-ec1856d0030e@mecka.net>

From: Alexander Warnecke <awarnecke002 at hotmail.com>

The BOE TH101MB31IG002-28A panel is a WXGA panel.
It is used in Pine64 Pinetab2 and PinetabV.

Signed-off-by: Alexander Warnecke <awarnecke002 at hotmail.com>
Signed-off-by: Manuel Traut <manut at mecka.net>
---
 drivers/gpu/drm/panel/Kconfig                      |  11 +
 drivers/gpu/drm/panel/Makefile                     |   1 +
 .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c   | 348 +++++++++++++++++++++
 3 files changed, 360 insertions(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..927ddd10e688 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -67,6 +67,17 @@ config DRM_PANEL_BOE_HIMAX8279D
 	  24 bit RGB per pixel. It provides a MIPI DSI interface to
 	  the host and has a built-in LED backlight.
 
+config DRM_PANEL_BOE_TH101MB31UIG002_28A
+	tristate "Boe TH101MB31UIG002-28A panel"
+	depends on OF
+	depends on DRM_MIPI_DSI
+	depends on BACKLIGHT_CLASS_DEVICE
+	help
+	  Say Y here if you want to enable support for Boe
+	  TH101MB31UIG002-28A TFT-LCD modules. The panel has a 800x1280
+	  resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI
+	  interface to the host and has a built-in LED backlight.
+
 config DRM_PANEL_BOE_TV101WUM_NL6
 	tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
 	depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..dd6e1ac9d0a2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) += panel-asus-z00t-tm5p5-n35596.
 obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
 obj-$(CONFIG_DRM_PANEL_BOE_BF060Y8M_AJ0) += panel-boe-bf060y8m-aj0.o
 obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
+obj-$(CONFIG_DRM_PANEL_BOE_TH101MB31UIG002_28A) += panel-boe-th101mb31ig002-28a.o
 obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
 obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
diff --git a/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
new file mode 100644
index 000000000000..ffe4047b7434
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Alexander Warnecke <awarnecke002 at hotmail.com>
+ * Copyright (c) 2023 Manuel Traut <manut at mecka.net>
+ * Copyright (c) 2023 Dang Huynh <danct12 at riseup.net>
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/drm_connector.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_panel.h>
+
+struct boe_th101mb31ig002 {
+	struct drm_panel panel;
+	bool enabled;
+	bool prepared;
+
+	struct mipi_dsi_device *dsi;
+
+	struct regulator *power;
+	struct gpio_desc *enable;
+	struct gpio_desc *reset;
+
+	enum drm_panel_orientation orientation;
+};
+
+static void boe_th101mb31ig002_reset(struct boe_th101mb31ig002 *ctx)
+{
+	gpiod_direction_output(ctx->reset, 0);
+	usleep_range(10, 100);
+	gpiod_direction_output(ctx->reset, 1);
+	usleep_range(10, 100);
+	gpiod_direction_output(ctx->reset, 0);
+	usleep_range(5000, 6000);
+}
+
+static int boe_th101mb31ig002_enable(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+	struct mipi_dsi_device *dsi = ctx->dsi;
+	struct device *dev = &dsi->dev;
+	int ret;
+
+	if (ctx->enabled)
+		return 0;
+
+	mipi_dsi_dcs_write_seq(dsi, 0xE0, 0xAB, 0xBA);
+	mipi_dsi_dcs_write_seq(dsi, 0xE1, 0xBA, 0xAB);
+	mipi_dsi_dcs_write_seq(dsi, 0xB1, 0x10, 0x01, 0x47, 0xFF);
+	mipi_dsi_dcs_write_seq(dsi, 0xB2, 0x0C, 0x14, 0x04, 0x50, 0x50, 0x14);
+	mipi_dsi_dcs_write_seq(dsi, 0xB3, 0x56, 0x53, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xB4, 0x33, 0x30, 0x04);
+	mipi_dsi_dcs_write_seq(dsi, 0xB6, 0xB0, 0x00, 0x00, 0x10, 0x00, 0x10,
+				    0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xB8, 0x05, 0x12, 0x29, 0x49, 0x48, 0x00,
+				    0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xB9, 0x7C, 0x65, 0x55, 0x49, 0x46, 0x36,
+				    0x3B, 0x24, 0x3D, 0x3C, 0x3D, 0x5C, 0x4C,
+				    0x55, 0x47, 0x46, 0x39, 0x26, 0x06, 0x7C,
+				    0x65, 0x55, 0x49, 0x46, 0x36, 0x3B, 0x24,
+				    0x3D, 0x3C, 0x3D, 0x5C, 0x4C, 0x55, 0x47,
+				    0x46, 0x39, 0x26, 0x06);
+	mipi_dsi_dcs_write_seq(dsi, 0x00, 0xFF, 0x87, 0x12, 0x34, 0x44, 0x44,
+				    0x44, 0x44, 0x98, 0x04, 0x98, 0x04, 0x0F,
+				    0x00, 0x00, 0xC1);
+	mipi_dsi_dcs_write_seq(dsi, 0xC1, 0x54, 0x94, 0x02, 0x85, 0x9F, 0x00,
+				    0x7F, 0x00, 0x54, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xC2, 0x17, 0x09, 0x08, 0x89, 0x08, 0x11,
+				    0x22, 0x20, 0x44, 0xFF, 0x18, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xC3, 0x86, 0x46, 0x05, 0x05, 0x1C, 0x1C,
+				    0x1D, 0x1D, 0x02, 0x1F, 0x1F, 0x1E, 0x1E,
+				    0x0F, 0x0F, 0x0D, 0x0D, 0x13, 0x13, 0x11,
+				    0x11, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xC4, 0x07, 0x07, 0x04, 0x04, 0x1C, 0x1C,
+				    0x1D, 0x1D, 0x02, 0x1F, 0x1F, 0x1E, 0x1E,
+				    0x0E, 0x0E, 0x0C, 0x0C, 0x12, 0x12, 0x10,
+				    0x10, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xC6, 0x2A, 0x2A);
+	mipi_dsi_dcs_write_seq(dsi, 0xC8, 0x21, 0x00, 0x31, 0x42, 0x34, 0x16);
+	mipi_dsi_dcs_write_seq(dsi, 0xCA, 0xCB, 0x43);
+	mipi_dsi_dcs_write_seq(dsi, 0xCD, 0x0E, 0x4B, 0x4B, 0x20, 0x19, 0x6B,
+				    0x06, 0xB3);
+	mipi_dsi_dcs_write_seq(dsi, 0xD2, 0xE3, 0x2B, 0x38, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xD4, 0x00, 0x01, 0x00, 0x0E, 0x04, 0x44,
+				    0x08, 0x10, 0x00, 0x00, 0x00);
+	mipi_dsi_dcs_write_seq(dsi, 0xE6, 0x80, 0x01, 0xFF, 0xFF, 0xFF, 0xFF,
+				    0xFF, 0xFF);
+	mipi_dsi_dcs_write_seq(dsi, 0xF0, 0x12, 0x03, 0x20, 0x00, 0xFF);
+	mipi_dsi_dcs_write_seq(dsi, 0xF3, 0x00);
+
+	ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+	if (ret < 0) {
+		dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+		return ret;
+	}
+
+	msleep(120);
+
+	ret = mipi_dsi_dcs_set_display_on(dsi);
+	if (ret < 0) {
+		dev_err(dev, "Failed to set panel on: %d\n", ret);
+		return ret;
+	}
+
+	ctx->enabled = true;
+
+	return 0;
+}
+
+static int boe_th101mb31ig002_disable(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+	struct mipi_dsi_device *dsi = ctx->dsi;
+	struct device *dev = &dsi->dev;
+	int ret;
+
+	if (!ctx->enabled)
+		return 0;
+
+	ret = mipi_dsi_dcs_set_display_off(dsi);
+	if (ret < 0)
+		dev_err(dev, "Failed to set panel off: %d\n", ret);
+
+	msleep(120);
+
+	ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
+	if (ret < 0)
+		dev_err(dev, "Failed to enter sleep mode: %d\n", ret);
+
+	ctx->enabled = false;
+
+	return 0;
+}
+
+static int boe_th101mb31ig002_unprepare(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+
+	if (!ctx->prepared)
+		return 0;
+
+	gpiod_set_value_cansleep(ctx->reset, 1);
+	gpiod_set_value_cansleep(ctx->enable, 0);
+	regulator_disable(ctx->power);
+
+	ctx->prepared = false;
+
+	return 0;
+}
+
+static int boe_th101mb31ig002_prepare(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+	struct device *dev = &ctx->dsi->dev;
+	int ret;
+
+	if (ctx->prepared)
+		return 0;
+
+	ret = regulator_enable(ctx->power);
+	if (ret) {
+		dev_err(dev, "Failed to enable power supply: %d\n", ret);
+		return ret;
+	}
+
+	gpiod_set_value_cansleep(ctx->enable, 1);
+	msleep(50);
+	boe_th101mb31ig002_reset(ctx);
+	boe_th101mb31ig002_enable(panel);
+
+	ctx->prepared = true;
+
+	return 0;
+}
+
+static const struct drm_display_mode boe_th101mb31ig002_default_mode = {
+	.clock		= 73500,
+	.hdisplay	= 800,
+	.hsync_start	= 800 + 64,
+	.hsync_end	= 800 + 64 + 16,
+	.htotal		= 800 + 64 + 16 + 64,
+	.vdisplay	= 1280,
+	.vsync_start	= 1280 + 2,
+	.vsync_end	= 1280 + 2 + 4,
+	.vtotal		= 1280 + 2 + 4 + 12,
+	.width_mm	= 135,
+	.height_mm	= 216,
+	.type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static int boe_th101mb31ig002_get_modes(struct drm_panel *panel,
+					struct drm_connector *connector)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+	struct drm_display_mode *mode;
+
+	mode = drm_mode_duplicate(connector->dev,
+				  &boe_th101mb31ig002_default_mode);
+	if (!mode) {
+		dev_err(panel->dev, "Failed to add mode %ux%u@%u\n",
+			boe_th101mb31ig002_default_mode.hdisplay,
+			boe_th101mb31ig002_default_mode.vdisplay,
+			drm_mode_vrefresh(&boe_th101mb31ig002_default_mode));
+		return -ENOMEM;
+	}
+
+	drm_mode_set_name(mode);
+
+	connector->display_info.bpc = 8;
+	connector->display_info.width_mm = mode->width_mm;
+	connector->display_info.height_mm = mode->height_mm;
+
+	/*
+	 * TODO: Remove once all drm drivers call
+	 * drm_connector_set_orientation_from_panel()
+	 */
+	drm_connector_set_panel_orientation(connector, ctx->orientation);
+
+	drm_mode_probed_add(connector, mode);
+
+	return 1;
+}
+
+static enum drm_panel_orientation
+boe_th101mb31ig002_get_orientation(struct drm_panel *panel)
+{
+	struct boe_th101mb31ig002 *ctx = container_of(panel,
+						      struct boe_th101mb31ig002,
+						      panel);
+
+	return ctx->orientation;
+}
+
+static const struct drm_panel_funcs boe_th101mb31ig002_funcs = {
+	.prepare = boe_th101mb31ig002_prepare,
+	.unprepare = boe_th101mb31ig002_unprepare,
+	.enable = boe_th101mb31ig002_enable,
+	.disable = boe_th101mb31ig002_disable,
+	.get_modes = boe_th101mb31ig002_get_modes,
+	.get_orientation = boe_th101mb31ig002_get_orientation,
+};
+
+static int boe_th101mb31ig002_dsi_probe(struct mipi_dsi_device *dsi)
+{
+	struct boe_th101mb31ig002 *ctx;
+	int ret;
+
+	ctx = devm_kzalloc(&dsi->dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ctx->enabled = false;
+	ctx->prepared = false;
+
+	mipi_dsi_set_drvdata(dsi, ctx);
+	ctx->dsi = dsi;
+
+	dsi->lanes = 4;
+	dsi->format = MIPI_DSI_FMT_RGB888;
+	dsi->mode_flags = MIPI_DSI_MODE_VIDEO_BURST |
+			  MIPI_DSI_MODE_NO_EOT_PACKET |
+			  MIPI_DSI_MODE_LPM;
+
+	ctx->power = devm_regulator_get(&dsi->dev, "power");
+	if (IS_ERR(ctx->power))
+		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->power),
+				     "Failed to get power regulator\n");
+
+	ctx->enable = devm_gpiod_get(&dsi->dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(ctx->enable))
+		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->enable),
+				     "Failed to get enable GPIO\n");
+
+	ctx->reset = devm_gpiod_get(&dsi->dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(ctx->reset))
+		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
+				     "Failed to get reset GPIO\n");
+
+	ret = of_drm_get_panel_orientation(dsi->dev.of_node,
+					   &ctx->orientation);
+	if (ret)
+		return dev_err_probe(&dsi->dev, ret,
+				     "Failed to get orientation\n");
+
+	drm_panel_init(&ctx->panel, &dsi->dev, &boe_th101mb31ig002_funcs,
+		       DRM_MODE_CONNECTOR_DSI);
+
+	ret = drm_panel_of_backlight(&ctx->panel);
+	if (ret)
+		return ret;
+
+	drm_panel_add(&ctx->panel);
+
+	ret = mipi_dsi_attach(dsi);
+	if (ret < 0) {
+		dev_err_probe(&dsi->dev, ret,
+			      "Failed to attach panel to DSI host\n");
+		drm_panel_remove(&ctx->panel);
+		return ret;
+	}
+
+	return 0;
+}
+
+static void boe_th101mb31ig002_dsi_remove(struct mipi_dsi_device *dsi)
+{
+	struct boe_th101mb31ig002 *ctx = mipi_dsi_get_drvdata(dsi);
+
+	mipi_dsi_detach(dsi);
+	drm_panel_remove(&ctx->panel);
+}
+
+static const struct of_device_id boe_th101mb31ig002_of_match[] = {
+	{ .compatible = "boe,th101mb31ig002-28a", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, boe_th101mb31ig002_of_match);
+
+static struct mipi_dsi_driver boe_th101mb31ig002_driver = {
+	.driver = {
+		.name = "boe-th101mb31ig002-28a",
+		.of_match_table = boe_th101mb31ig002_of_match,
+	},
+	.probe = boe_th101mb31ig002_dsi_probe,
+	.remove = boe_th101mb31ig002_dsi_remove,
+};
+module_mipi_dsi_driver(boe_th101mb31ig002_driver);
+
+MODULE_AUTHOR("Alexander Warnecke <awarnecke002 at hotmail.com>");
+MODULE_DESCRIPTION("BOE TH101MB31IG002-28A MIPI-DSI LCD panel");
+MODULE_LICENSE("GPL");

-- 
2.43.0



From manut at mecka.net  Sat Dec 23 07:20:18 2023
From: manut at mecka.net (Manuel Traut)
Date: Sat, 23 Dec 2023 16:20:18 +0100
Subject: [PATCH v2 4/4] arm64: dts: rockchip: Add devicetree for Pine64
 Pinetab2
In-Reply-To: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
References: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
Message-ID: <20231223-pinetab2-v2-4-ec1856d0030e@mecka.net>

From: Alexander Warnecke <awarnecke002 at hotmail.com>

This includes support for both the v0.1 units that were sent to developers and
the v2.0 units from production.

v1.0 is not included as no units are known to exist.

Working/Tested:
- SDMMC
- UART
- Buttons
- Charging/Battery/PMIC
- Audio
- USB
- Display

WiFi is not added, since the driver is not ready for mainline.

Signed-off-by: Alexander Warnecke <awarnecke002 at hotmail.com>
Signed-off-by: Manuel Traut <manut at mecka.net>
---
 arch/arm64/boot/dts/rockchip/Makefile              |   2 +
 .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts     |  26 +
 .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts     |  46 +
 arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi  | 979 +++++++++++++++++++++
 4 files changed, 1053 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index a18f33bf0c0e..ef66c0937a9b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -77,6 +77,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v0.1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v2.0.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
new file mode 100644
index 000000000000..8b110186a3eb
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+	model = "Pine64 PineTab2 v0.1";
+	compatible = "pine64,pinetab2-v0.1", "pine64,pinetab2", "rockchip,rk3566";
+};
+
+&lcd {
+	reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+};
+
+&pinctrl {
+	lcd0 {
+		lcd0_rst_l: lcd0-rst-l {
+			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&sdmmc1 {
+	vmmc-supply = <&vcc3v3_sys>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
new file mode 100644
index 000000000000..6f80446b5802
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+	model = "Pine64 PineTab2 v2.0";
+	compatible = "pine64,pinetab2-v2.0", "pine64,pinetab2", "rockchip,rk3566";
+};
+
+&gpio_keys {
+	pinctrl-0 = <&kb_id_det>, <&hall_int_l>;
+
+	event-hall-sensor {
+		debounce-interval = <20>;
+		gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+		label = "Hall Sensor";
+		linux,code = <SW_LID>;
+		linux,input-type = <EV_SW>;
+		wakeup-event-action = <EV_ACT_DEASSERTED>;
+		wakeup-source;
+	};
+};
+
+&lcd {
+	reset-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_LOW>;
+};
+
+&pinctrl {
+	lcd0 {
+		lcd0_rst_l: lcd0-rst-l {
+			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	hall {
+		hall_int_l: hall-int-l {
+			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&sdmmc1 {
+	vmmc-supply = <&vcc_sys>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
new file mode 100644
index 000000000000..3ab7d8dbe1ec
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -0,0 +1,979 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include <dt-bindings/usb/pd.h>
+#include "rk3566.dtsi"
+
+/ {
+	chassis-type = "tablet";
+
+	aliases {
+		mmc0 = &sdmmc0;
+		mmc1 = &sdhci;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <25>;
+
+		button-vol-up {
+			label = "Volume Up";
+			linux,code = <KEY_VOLUMEUP>;
+			press-threshold-microvolt = <297500>;
+		};
+
+		button-vol-down {
+			label = "Volume Down";
+			linux,code = <KEY_VOLUMEDOWN>;
+			press-threshold-microvolt = <1750>;
+		};
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm4 0 25000 0>;
+		brightness-levels = <20 220>;
+		num-interpolated-steps = <200>;
+		default-brightness-level = <100>;
+		power-supply = <&vcc_sys>;
+	};
+
+	battery: battery {
+		compatible = "simple-battery";
+		charge-full-design-microamp-hours = <6000000>;
+		charge-term-current-microamp = <300000>;
+		constant-charge-current-max-microamp = <2000000>;
+		constant-charge-voltage-max-microvolt = <4300000>;
+		voltage-max-design-microvolt = <4350000>;
+		voltage-min-design-microvolt = <3400000>;
+
+		ocv-capacity-celsius = <20>;
+		ocv-capacity-table-0 = <4322000 100>, <4250000 95>, <4192000 90>, <4136000 85>,
+				       <4080000 80>, <4022000 75>, <3972000 70>, <3928000 65>,
+				       <3885000 60>, <3833000 55>, <3798000 50>, <3780000 45>,
+				       <3776000 40>, <3773000 35>, <3755000 30>, <3706000 25>,
+				       <3640000 20>, <3589000 15>, <3535000 10>, <3492000 5>,
+				       <3400000 0>;
+	};
+
+	gpio_keys: gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&kb_id_det>;
+
+		tablet-mode-switch {
+			debounce-interval = <20>;
+			gpios = <&gpio4 RK_PA4 GPIO_ACTIVE_HIGH>;
+			label = "Tablet Mode";
+			linux,input-type = <EV_SW>;
+			linux,code = <SW_TABLET_MODE>;
+		};
+	};
+
+	hdmi-con {
+		compatible = "hdmi-connector";
+		type = "d";
+
+		port {
+			hdmi_con_in: endpoint {
+				remote-endpoint = <&hdmi_out_con>;
+			};
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&flash_led_en_h>;
+
+		led-0 {
+			gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+			color = <LED_COLOR_ID_WHITE>;
+			function = LED_FUNCTION_FLASH;
+		};
+	};
+
+	rk817-sound {
+		compatible = "simple-audio-card";
+		pinctrl-names = "default";
+		pinctrl-0 = <&hp_det_l>;
+		simple-audio-card,format = "i2s";
+		simple-audio-card,name = "rk817_ext";
+		simple-audio-card,mclk-fs = <256>;
+
+		simple-audio-card,widgets =
+			"Microphone", "Mic Jack",
+			"Headphone", "Headphones",
+			"Speaker", "Internal Speakers";
+
+		simple-audio-card,routing =
+			"MICR", "Mic Jack",
+			"Headphones", "HPOL",
+			"Headphones", "HPOR",
+			"Internal Speakers", "Speaker Amplifier OUTL",
+			"Internal Speakers", "Speaker Amplifier OUTR",
+			"Speaker Amplifier INL", "HPOL",
+			"Speaker Amplifier INR", "HPOR";
+		simple-audio-card,hp-det-gpio = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
+		simple-audio-card,aux-devs = <&speaker_amp>;
+		simple-audio-card,pin-switches = "Internal Speakers";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s1_8ch>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&rk817>;
+		};
+	};
+
+	speaker_amp: speaker-amplifier {
+		compatible = "simple-audio-amplifier";
+		pinctrl-names = "default";
+		pinctrl-0 = <&spk_ctl>;
+		enable-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_HIGH>;
+		sound-name-prefix = "Speaker Amplifier";
+		VCC-supply = <&vcc_bat>;
+	};
+
+	vcc_3v3: vcc-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc3v3_minipcie: vcc3v3-minipcie {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PC3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pcie_pwren_h>;
+		regulator-name = "vcc3v3_minipcie";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc3v3_sd: vcc3v3-sd {
+		compatible = "regulator-fixed";
+		gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc_pwren_l>;
+		regulator-name = "vcc3v3_sd";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc5v0_usb_host0: vcc5v0-usb-host0 {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PC4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren1_h>;
+		regulator-name = "vcc5v0_usb_host0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v_midu>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc5v0_usb_host2: vcc5v0-usb-host2 {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PC5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren2_h>;
+		regulator-name = "vcc5v0_usb_host2";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v_midu>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc_bat: vcc-bat {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_bat";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vcc_sys: vcc-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc_bat>;
+	};
+
+	vdd1v2_dvp: vdd1v2-dvp {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd1v2_dvp";
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+		vin-supply = <&vcc_3v3>;
+		/*enable-supply = <&vcc2v8_dvp>;*/
+	};
+};
+
+&combphy1 {
+	status = "okay";
+};
+
+&combphy2 {
+	status = "okay";
+};
+
+&cpu0 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cru {
+	assigned-clocks = <&pmucru CLK_RTC_32K>, <&cru PLL_GPLL>,
+			  <&pmucru PLL_PPLL>, <&cru PLL_VPLL>;
+	assigned-clock-rates = <32768>, <1200000000>, <200000000>, <500000000>;
+	assigned-clock-parents = <&pmucru CLK_RTC32K_FRAC>;
+};
+
+&csi_dphy {
+	status = "okay";
+};
+
+&dsi0 {
+	status = "okay";
+	clock-master;
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	lcd: panel at 0 {
+		compatible = "boe,th101mb31ig002-28a";
+		reg = <0>;
+		backlight = <&backlight>;
+		enable-gpios = <&gpio0 RK_PC7 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&lcd_pwren_h &lcd0_rst_l>;
+		rotation = <90>;
+		power-supply = <&vcc_3v3>;
+
+		port at 0 {
+			panel_in_dsi: endpoint at 0 {
+				remote-endpoint = <&dsi0_out_con>;
+			};
+		};
+	};
+};
+
+&dsi0_in {
+	dsi0_in_vp1: endpoint {
+		remote-endpoint = <&vp1_out_dsi0>;
+	};
+};
+
+&dsi0_out {
+	dsi0_out_con: endpoint {
+		remote-endpoint = <&panel_in_dsi>;
+	};
+};
+
+&dsi_dphy0 {
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu_npu>;
+	status = "okay";
+};
+
+&hdmi {
+	avdd-0v9-supply = <&vdda_0v9_p>;
+	avdd-1v8-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&hdmi_in {
+	hdmi_in_vp0: endpoint {
+		remote-endpoint = <&vp0_out_hdmi>;
+	};
+};
+
+&hdmi_out {
+	hdmi_out_con: endpoint {
+		remote-endpoint = <&hdmi_con_in>;
+	};
+};
+
+&hdmi_sound {
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	vdd_cpu: regulator at 1c {
+		compatible = "tcs,tcs4525";
+		reg = <0x1c>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu";
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <1150000>;
+		regulator-ramp-delay = <2300>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	rk817: pmic at 20 {
+		compatible = "rockchip,rk817";
+		reg = <0x20>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+		assigned-clocks = <&cru I2S1_MCLKOUT_TX>;
+		assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>;
+		clock-names = "mclk";
+		clocks = <&cru I2S1_MCLKOUT_TX>;
+		clock-output-names = "rk808-clkout1", "rk808-clkout2";
+		#clock-cells = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>, <&i2s1m0_mclk>;
+		rockchip,system-power-controller;
+		#sound-dai-cells = <0>;
+		wakeup-source;
+
+		vcc1-supply = <&vcc_sys>;
+		vcc2-supply = <&vcc_sys>;
+		vcc3-supply = <&vcc_sys>;
+		vcc4-supply = <&vcc_sys>;
+		vcc5-supply = <&vcc_sys>;
+		vcc6-supply = <&vcc_sys>;
+		vcc7-supply = <&vcc_sys>;
+		vcc8-supply = <&vcc_sys>;
+		vcc9-supply = <&vcc5v_midu>;
+
+		regulators {
+			vdd_logic: DCDC_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vdd_logic";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_gpu_npu: DCDC_REG2 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vdd_gpu_npu";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vcc_ddr";
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc3v3_sys: DCDC_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vcc3v3_sys";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca1v8_pmu: LDO_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca1v8_pmu";
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vdda_0v9_p: LDO_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-name = "vdda_0v9_p";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda0v9_pmu: LDO_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-name = "vdda0v9_pmu";
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vccio_acodec: LDO_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vccio_acodec";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd: LDO_REG5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vccio_sd";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_pmu: LDO_REG6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc3v3_pmu";
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: LDO_REG7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc1v8_dvp: LDO_REG8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8_dvp";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc2v8_dvp: LDO_REG9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-name = "vcc2v8_dvp";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc5v_midu: BOOST {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5000000>;
+				regulator-name = "boost";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vbus: OTG_SWITCH {
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5000000>;
+				regulator-name = "otg_switch";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+
+		charger {
+			monitored-battery = <&battery>;
+			rockchip,resistor-sense-micro-ohms = <10000>;
+			rockchip,sleep-enter-current-microamp = <300000>;
+			rockchip,sleep-filter-current-microamp = <100000>;
+		};
+	};
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	touchscreen at 5d {
+		compatible = "goodix,gt911";
+		reg = <0x5d>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_EDGE_FALLING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&tp_int_l_pmuio2>, <&tp_rst_l_pmuio2>;
+		AVDD28-supply = <&vcc3v3_pmu>;
+		VDDIO-supply = <&vcca1v8_pmu>;
+		irq-gpios = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+	pinctrl-0 = <&i2c2m1_xfer>;
+	status = "okay";
+
+	vcm at c {
+		compatible = "dongwoon,dw9714";
+		reg = <0x0c>;
+		vcc-supply = <&vcc1v8_dvp>;
+	};
+
+	camera at 36 {
+		compatible = "ovti,ov5648";
+		reg = <0x36>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&camerab_pdn_l &camerab_rst_l>;
+
+		clocks = <&cru CLK_CIF_OUT>;
+		assigned-clocks = <&cru CLK_CIF_OUT>;
+		assigned-clock-rates = <24000000>;
+
+		avdd-supply = <&vcc2v8_dvp>;
+		dvdd-supply = <&vdd1v2_dvp>;
+		dovdd-supply = <&vcc1v8_dvp>;
+		powerdown-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
+
+		port {
+			endpoint {
+				data-lanes = <1 2>;
+				remote-endpoint = <0>;
+				link-frequencies = /bits/ 64 <210000000 168000000>;
+			};
+		};
+	};
+};
+
+&i2c5 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	accelerometer at 18 {
+		compatible = "silan,sc7a20";
+		reg = <0x18>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gsensor_int_l>;
+		st,drdy-int-pin = <1>;
+		vdd-supply = <&vcc_1v8>;
+		vddio-supply = <&vcc_1v8>;
+		mount-matrix = "1", "0", "0",
+			       "0", "0", "1",
+			       "0", "1", "0";
+	};
+};
+
+&i2s0_8ch {
+	status = "okay";
+};
+
+&i2s1_8ch {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s1m0_sclktx
+		     &i2s1m0_lrcktx
+		     &i2s1m0_sdi0
+		     &i2s1m0_sdo0>;
+	rockchip,trcm-sync-tx-only;
+	status = "okay";
+};
+
+&pcie2x1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie_reset_h>;
+	reset-gpios = <&gpio1 RK_PB2 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_minipcie>;
+	status = "okay";
+};
+
+&pinctrl {
+	bt {
+		bt_wake_host_h: bt-wake-host-h {
+			rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	camerab {
+		camerab_pdn_l: camerab-pdn-l {
+			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		camerab_rst_l: camerab-rst-l {
+			rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	cameraf {
+		cameraf_pdn_l: cameraf-pdn-l {
+			rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		cameraf_rst_l: cameraf-rst-l {
+			rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	flash {
+		flash_led_en_h: flash-led-en-h {
+			rockchip,pins = <4 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	fspi {
+		fspi_dual_io_pins: fspi-dual-io-pins {
+			rockchip,pins =
+				/* fspi_clk */
+				<1 RK_PD0 1 &pcfg_pull_none>,
+				/* fspi_cs0n */
+				<1 RK_PD3 1 &pcfg_pull_none>,
+				/* fspi_d0 */
+				<1 RK_PD1 1 &pcfg_pull_none>,
+				/* fspi_d1 */
+				<1 RK_PD2 1 &pcfg_pull_none>;
+		};
+	};
+
+	gsensor {
+		gsensor_int_l: gsensor-int-l {
+			rockchip,pins = <3 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	kb {
+		kb_id_det: kb-id-det {
+			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	lcd {
+		lcd_pwren_h: lcd-pwren-h {
+			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pcie {
+		pcie_pwren_h: pcie-pwren-h {
+			rockchip,pins = <4 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		pcie_reset_h: pcie-reset-h {
+			rockchip,pins = <1 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		pmic_int_l: pmic-int-l {
+			rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sdmmc {
+		sdmmc_pwren_l: sdmmc-pwren-l {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sound {
+		hp_det_l: hp-det-l {
+			rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		spk_ctl: spk-ctl {
+			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	tp {
+		tp_int_l_pmuio2: tp-int-l-pmuio2 {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		tp_rst_l_pmuio2: tp-rst-l-pmuio2 {
+			rockchip,pins = <0 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		usbcc_int_l: usbcc-int-l {
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_host_pwren1_h: usb-host-pwren1-h {
+			rockchip,pins = <4 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_host_pwren2_h: usb-host-pwren2-h {
+			rockchip,pins = <4 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wifi {
+		host_wake_wl: host-wake-wl {
+			rockchip,pins = <0 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_pwren: wifi-pwren {
+			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_wake_host_h: wifi-wake-host-h {
+			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+};
+
+&pmu_io_domains {
+	pmuio1-supply = <&vcc3v3_pmu>;
+	pmuio2-supply = <&vcca1v8_pmu>;
+	vccio1-supply = <&vccio_acodec>;
+	vccio2-supply = <&vcc_1v8>;
+	vccio3-supply = <&vccio_sd>;
+	vccio4-supply = <&vcc_1v8>;
+	vccio5-supply = <&vcc_1v8>;
+	vccio6-supply = <&vcc1v8_dvp>;
+	vccio7-supply = <&vcc_3v3>;
+	status = "okay";
+};
+
+&pwm4 {
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	max-frequency = <200000000>;
+	mmc-hs200-1_8v;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_bus8
+		     &emmc_clk
+		     &emmc_cmd
+		     &emmc_datastrobe
+		     &emmc_rstnout>;
+	vmmc-supply = <&vcc_3v3>;
+	vqmmc-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdmmc0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc0_bus4
+		     &sdmmc0_clk
+		     &sdmmc0_cmd
+		     &sdmmc0_det>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc3v3_sd>;
+	vqmmc-supply = <&vccio_sd>;
+	status = "okay";
+};
+
+&sdmmc1 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc1_bus4
+		     &sdmmc1_cmd
+		     &sdmmc1_clk>;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vcca1v8_pmu>;
+	status = "okay";
+};
+
+&sfc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&fspi_dual_io_pins>;
+	status = "okay";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	flash at 0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <24000000>;
+		spi-rx-bus-width = <2>;
+		spi-tx-bus-width = <1>;
+	};
+};
+
+&tsadc {
+	rockchip,hw-tshut-mode = <1>;
+	rockchip,hw-tshut-polarity = <0>;
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1m0_xfer
+		     &uart1m0_ctsn
+		     &uart1m0_rtsn>;
+	status = "okay";
+	uart-has-rtscts;
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host0_xhci {
+	status = "okay";
+};
+
+&usb_host1_xhci {
+	status = "okay";
+};
+
+&usb2phy0 {
+	status = "okay";
+};
+
+&usb2phy0_host {
+	phy-supply = <&vcc5v0_usb_host0>;
+	status = "okay";
+};
+
+&usb2phy0_otg {
+	status = "okay";
+};
+
+&usb2phy1 {
+	status = "okay";
+};
+
+&usb2phy1_otg {
+	phy-supply = <&vcc5v0_usb_host2>;
+	status = "okay";
+};
+
+&vop {
+	assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+	assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+	status = "okay";
+};
+
+&vop_mmu {
+	status = "okay";
+};
+
+&vp0 {
+	vp0_out_hdmi: endpoint at ROCKCHIP_VOP2_EP_HDMI0 {
+		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi_in_vp0>;
+	};
+};
+
+&vp1 {
+	vp1_out_dsi0: endpoint at ROCKCHIP_VOP2_EP_MIPI0 {
+		reg = <ROCKCHIP_VOP2_EP_MIPI0>;
+		remote-endpoint = <&dsi0_in_vp1>;
+	};
+};

-- 
2.43.0



From ruipengqi7 at gmail.com  Sat Dec 23 07:30:13 2023
From: ruipengqi7 at gmail.com (ruipeng qi)
Date: Sat, 23 Dec 2023 23:30:13 +0800
Subject: [PATCH 1/7] [RFC PATCH 1/7] osdump: Add one new os minidump module
In-Reply-To: <CADHLONE2YnBJGJUp2-vn_XEpc7+quTMWF7y1zpV0ygeL2VpQxA@mail.gmail.com>
References: <20231221130930.32634-1-ruipengqi7@gmail.com> <e9aa311f-6f13-410e-bb35-20320275668c@linaro.org>
 <CADHLONGLZaZT4Ot56AnxOf=ROrTWvge5=NUx5uqKqJhpJibfOQ@mail.gmail.com>
 <6fe05804-da74-45cd-a6f1-df4644671d99@linaro.org> <CADHLONE2YnBJGJUp2-vn_XEpc7+quTMWF7y1zpV0ygeL2VpQxA@mail.gmail.com>
Message-ID: <CADHLONHHZAeubePPfZbG1N0Nv3ZJM5OWaJWqchBUpiN5Q27UdQ@mail.gmail.com>

On Sat, Dec 23, 2023 at 11:13?PM ruipeng qi <ruipengqi7 at gmail.com> wrote:

> > I don't see a problem why minidump cannot do it.
> Qcom minidump allows one kernel client to register its region to dump, and then
> driver will create and maintain one elf head for it.
> But osdump will dump thousands of non-continuous regions. If you register one
> by one, and add an elf head for each, it will cause heavy overhead. So it store
> data in binary, and reassemble a standard elf format file offline for debug.
>
Osdump will only dump useful data, which may have been allocated before but
freed now. In a word, useful data are changing all the time. I think this is not
suitable for Qcom minidump's framework?

Best Regards
Ruipeng


From islituo at gmail.com  Sat Dec 23 08:43:51 2023
From: islituo at gmail.com (Tuo Li)
Date: Sun, 24 Dec 2023 00:43:51 +0800
Subject: [PATCH] media:fimc-capture: Fix a possible data inconsistency due to a data race in fimc_subdev_set_fmt()
Message-ID: <20231223164351.3521588-1-islituo@gmail.com>

Accesses to ctx->s_frame.width and ctx->s_frame.height should be protected
by the lock fimc->lock to guarantee that width and height are consistent.
Here is an example in fimc_subdev_get_fmt():

  struct fimc_frame *ff = &ctx->s_frame; // Alias
  mutex_lock(&fimc->lock);
  mf->width = ff->width;
  mf->height = ff->height;

However, ctx->s_frame.width and ctx->s_frame.height are accessed without 
holding the lock fimc->lock in fimc_subdev_set_fmt():

  mf->width = ctx->s_frame.width;
  mf->height = ctx->s_frame.height;

And thus a harmful data race can occur, which can make ctx->s_frame.width
inconsistent with ctx->s_frame.height, if ctx->s_frame.height is updated 
right after ctx->s_frame.width is accessed by another thread.

This possible bug is found by an experimental static analysis tool
developed by our team, BassCheck[1]. This tool analyzes the locking APIs
to extract function pairs that can be concurrently executed, and then
analyzes the instructions in the paired functions to identify possible
concurrency bugs including data races and atomicity violations. The above
possible bug is reported when our tool analyzes the source code of
Linux 6.2.

To fix this possible data race, the lock operation mutex_lock(&fimc->lock)
is moved to the front of the accesses to these two variables. With this 
patch applied, our tool no longer reports the bug, with the kernel 
configuration allyesconfig for x86_64. Due to the lack of associated 
hardware, we cannot test the patch in runtime testing, and just verify it 
according to the code logic.

[1] https://sites.google.com/view/basscheck/

Fixes: 88fa8311ee36 ("[media] s5p-fimc: Add support for ISP Writeback ...")
Signed-off-by: Tuo Li <islituo at gmail.com>
Cc: stable at vger.kernel.org
Reported-by: BassCheck <bass at buaa.edu.cn>
---
 drivers/media/platform/samsung/exynos4-is/fimc-capture.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
index a0d43bf892e6..5c8b67f92c65 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
@@ -1546,6 +1546,7 @@ static int fimc_subdev_set_fmt(struct v4l2_subdev *sd,
 	fimc_alpha_ctrl_update(ctx);
 
 	fimc_capture_mark_jpeg_xfer(ctx, ffmt->color);
+	mutex_lock(&fimc->lock);
 	if (fmt->pad == FIMC_SD_PAD_SOURCE) {
 		ff = &ctx->d_frame;
 		/* Sink pads crop rectangle size */
@@ -1555,7 +1556,6 @@ static int fimc_subdev_set_fmt(struct v4l2_subdev *sd,
 		ff = &ctx->s_frame;
 	}
 
-	mutex_lock(&fimc->lock);
 	set_frame_bounds(ff, mf->width, mf->height);
 
 	if (fmt->pad == FIMC_SD_PAD_SINK_FIFO)
-- 
2.34.1



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:26 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:26 +0800
Subject: [PATCH v3 05/11] drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-6-jason-jh.lin@mediatek.com>

Add mtk_ddp_sec_write to configure secure buffer information to
cmdq secure packet data.
Then secure cmdq driver will use these information to configure
curresponding secure DRAM address to HW overlay in secure world.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 4bae55bdb034..b5a05ca3a385 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -7,6 +7,8 @@
 #define MTK_DRM_DDP_COMP_H
 
 #include <linux/io.h>
+#include <linux/pm_runtime.h>
+#include <linux/mailbox/mtk-cmdq-sec-mailbox.h>
 #include <linux/soc/mediatek/mtk-cmdq.h>
 #include <linux/soc/mediatek/mtk-mmsys.h>
 #include <linux/soc/mediatek/mtk-mutex.h>
@@ -308,4 +310,7 @@ void mtk_ddp_write_relaxed(struct cmdq_pkt *cmdq_pkt, unsigned int value,
 void mtk_ddp_write_mask(struct cmdq_pkt *cmdq_pkt, unsigned int value,
 			struct cmdq_client_reg *cmdq_reg, void __iomem *regs,
 			unsigned int offset, unsigned int mask);
+void mtk_ddp_sec_write(struct cmdq_pkt *cmdq_pkt, u32 addr, u64 base,
+		       const enum cmdq_iwc_addr_metadata_type type,
+		       const u32 offset, const u32 size, const u32 port);
 #endif /* MTK_DRM_DDP_COMP_H */
-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:22 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:22 +0800
Subject: [PATCH v3 01/11] drm/mediatek: Add interface to allocate MediaTek GEM buffer.
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-2-jason-jh.lin@mediatek.com>

From: CK Hu <ck.hu at mediatek.com>

Add an interface to allocate MediaTek GEM buffers, allow the IOCTLs
to be used by render nodes.
This patch also sets the RENDER driver feature.

Signed-off-by: CK Hu <ck.hu at mediatek.com>
Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat at chromium.org>
Tested-by: Daniel Kurtz <djkurtz at chromium.org>
Tested-by: Pi-Hsun Shih <pihsun at chromium.org>
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 ++++++
 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 39 +++++++++++++++++
 drivers/gpu/drm/mediatek/mtk_drm_gem.h | 12 ++++++
 include/uapi/drm/mediatek_drm.h        | 58 ++++++++++++++++++++++++++
 4 files changed, 122 insertions(+)
 create mode 100644 include/uapi/drm/mediatek_drm.h

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 2b0c35cacbc6..5d2a39e491aa 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -24,6 +24,7 @@
 #include <drm/drm_of.h>
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_vblank.h>
+#include <drm/mediatek_drm.h>
 
 #include "mtk_drm_crtc.h"
 #include "mtk_drm_ddp_comp.h"
@@ -569,6 +570,14 @@ static void mtk_drm_kms_deinit(struct drm_device *drm)
 	component_unbind_all(drm->dev, drm);
 }
 
+static const struct drm_ioctl_desc mtk_ioctls[] = {
+	DRM_IOCTL_DEF_DRV(MTK_GEM_CREATE, mtk_gem_create_ioctl,
+			  DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+	DRM_IOCTL_DEF_DRV(MTK_GEM_MAP_OFFSET,
+			  mtk_gem_map_offset_ioctl,
+			  DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+};
+
 DEFINE_DRM_GEM_FOPS(mtk_drm_fops);
 
 /*
@@ -590,6 +599,10 @@ static const struct drm_driver mtk_drm_driver = {
 
 	.gem_prime_import = mtk_drm_gem_prime_import,
 	.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
+
+	.ioctls = mtk_ioctls,
+	.num_ioctls = ARRAY_SIZE(mtk_ioctls),
+
 	.fops = &mtk_drm_fops,
 
 	.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 4f2e3feabc0f..30e347adcbe9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -4,6 +4,7 @@
  */
 
 #include <linux/dma-buf.h>
+#include <drm/mediatek_drm.h>
 
 #include <drm/drm.h>
 #include <drm/drm_device.h>
@@ -283,3 +284,41 @@ void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj,
 	mtk_gem->kvaddr = NULL;
 	kfree(mtk_gem->pages);
 }
+
+int mtk_gem_map_offset_ioctl(struct drm_device *drm, void *data,
+			     struct drm_file *file_priv)
+{
+	struct drm_mtk_gem_map_off *args = data;
+
+	return drm_gem_dumb_map_offset(file_priv, drm, args->handle,
+				       &args->offset);
+}
+
+int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
+			 struct drm_file *file_priv)
+{
+	struct mtk_drm_gem_obj *mtk_gem;
+	struct drm_mtk_gem_create *args = data;
+	int ret;
+
+	mtk_gem = mtk_drm_gem_create(dev, args->size, false);
+	if (IS_ERR(mtk_gem))
+		return PTR_ERR(mtk_gem);
+
+	/*
+	 * allocate a id of idr table where the obj is registered
+	 * and handle has the id what user can see.
+	 */
+	ret = drm_gem_handle_create(file_priv, &mtk_gem->base, &args->handle);
+	if (ret)
+		goto err_handle_create;
+
+	/* drop reference from allocate - handle holds it now. */
+	drm_gem_object_put(&mtk_gem->base);
+
+	return 0;
+
+err_handle_create:
+	mtk_drm_gem_free_object(&mtk_gem->base);
+	return ret;
+}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.h b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
index 78f23b07a02e..90f3d2916ec5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
@@ -46,4 +46,16 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map);
 void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj,
 			      struct iosys_map *map);
 
+/*
+ * request gem object creation and buffer allocation as the size
+ * that it is calculated with framebuffer information such as width,
+ * height and bpp.
+ */
+int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
+			 struct drm_file *file_priv);
+
+/* get buffer offset to map to user space. */
+int mtk_gem_map_offset_ioctl(struct drm_device *dev, void *data,
+			     struct drm_file *file_priv);
+
 #endif
diff --git a/include/uapi/drm/mediatek_drm.h b/include/uapi/drm/mediatek_drm.h
new file mode 100644
index 000000000000..f4d47577c94e
--- /dev/null
+++ b/include/uapi/drm/mediatek_drm.h
@@ -0,0 +1,58 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _UAPI_MEDIATEK_DRM_H
+#define _UAPI_MEDIATEK_DRM_H
+
+#include <drm/drm.h>
+
+/**
+ * struct drm_mtk_gem_create - User-desired buffer creation information structure.
+ *
+ * @size: user-desired memory allocation size.
+ *	- this size value would be page-aligned internally.
+ * @flags: user request for setting memory type or cache attributes.
+ * @handle: returned a handle to created gem object.
+ *	- this handle will be set by gem module of kernel side.
+ */
+struct drm_mtk_gem_create {
+	uint64_t size;
+	uint32_t flags;
+	uint32_t handle;
+};
+
+/**
+ * struct drm_mtk_gem_map_off - A structure for getting buffer offset.
+ *
+ * @handle: a pointer to gem object created.
+ * @pad: just padding to be 64-bit aligned.
+ * @offset: relatived offset value of the memory region allocated.
+ *     - this value should be set by user.
+ */
+struct drm_mtk_gem_map_off {
+	uint32_t handle;
+	uint32_t pad;
+	uint64_t offset;
+};
+
+#define DRM_MTK_GEM_CREATE		0x00
+#define DRM_MTK_GEM_MAP_OFFSET		0x01
+
+#define DRM_IOCTL_MTK_GEM_CREATE	DRM_IOWR(DRM_COMMAND_BASE + \
+		DRM_MTK_GEM_CREATE, struct drm_mtk_gem_create)
+
+#define DRM_IOCTL_MTK_GEM_MAP_OFFSET	DRM_IOWR(DRM_COMMAND_BASE + \
+		DRM_MTK_GEM_MAP_OFFSET, struct drm_mtk_gem_map_off)
+
+#endif /* _UAPI_MEDIATEK_DRM_H */
-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:27 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:27 +0800
Subject: [PATCH v3 06/11] drm/mediatek: Add get_sec_port interface to mtk_ddp_comp
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-7-jason-jh.lin@mediatek.com>

Add get_sec_port interface to ddp_comp to get the secure port settings
from ovl and ovl_adaptor.
Then mediatek-drm will use secure cmdq driver to configure DRAM access
permission in secure world by their secure port settings.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index b5a05ca3a385..1e6a120a103d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -84,6 +84,7 @@ struct mtk_ddp_comp_funcs {
 	void (*add)(struct device *dev, struct mtk_mutex *mutex);
 	void (*remove)(struct device *dev, struct mtk_mutex *mutex);
 	unsigned int (*encoder_index)(struct device *dev);
+	u64 (*get_sec_port)(struct mtk_ddp_comp *comp, unsigned int idx);
 };
 
 struct mtk_ddp_comp {
@@ -199,6 +200,14 @@ static inline unsigned int mtk_ddp_gamma_get_lut_size(struct mtk_ddp_comp *comp)
 	return 0;
 }
 
+static inline u64 mtk_ddp_comp_layer_get_sec_port(struct mtk_ddp_comp *comp,
+						  unsigned int idx)
+{
+	if (comp->funcs && comp->funcs->get_sec_port)
+		return comp->funcs->get_sec_port(comp, idx);
+	return 0;
+}
+
 static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp *comp,
 				     struct drm_crtc_state *state)
 {
-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:23 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:23 +0800
Subject: [PATCH v3 02/11] drm/mediatek/uapi: Add DRM_MTK_GEM_CREATE_ENCRYPTED flag
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-3-jason-jh.lin@mediatek.com>

Add DRM_MTK_GEM_CREATE_ENCRYPTED flag to allow user to allocate
a secure buffer to support secure video path feature.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 include/uapi/drm/mediatek_drm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/drm/mediatek_drm.h b/include/uapi/drm/mediatek_drm.h
index f4d47577c94e..189d20301205 100644
--- a/include/uapi/drm/mediatek_drm.h
+++ b/include/uapi/drm/mediatek_drm.h
@@ -48,6 +48,7 @@ struct drm_mtk_gem_map_off {
 
 #define DRM_MTK_GEM_CREATE		0x00
 #define DRM_MTK_GEM_MAP_OFFSET		0x01
+#define DRM_MTK_GEM_CREATE_ENCRYPTED	0x02
 
 #define DRM_IOCTL_MTK_GEM_CREATE	DRM_IOWR(DRM_COMMAND_BASE + \
 		DRM_MTK_GEM_CREATE, struct drm_mtk_gem_create)
-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:21 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:21 +0800
Subject: [PATCH v3 00/11] Add mediate-drm secure flow for SVP
Message-ID: <20231223182932.27683-1-jason-jh.lin@mediatek.com>

From: Jason-jh Lin <jason-jh.lin at mediatek.corp-partner.google.com>

Memory Definitions:
secure memory - Memory allocated in the TEE (Trusted Execution
Environment) which is inaccessible in the REE (Rich Execution
Environment, i.e. linux kernel/userspace).
secure handle - Integer value which acts as reference to 'secure
memory'. Used in communication between TEE and REE to reference
'secure memory'.
secure buffer - 'secure memory' that is used to store decrypted,
compressed video or for other general purposes in the TEE.
secure surface - 'secure memory' that is used to store graphic buffers.

Memory Usage in SVP:
The overall flow of SVP starts with encrypted video coming in from an
outside source into the REE. The REE will then allocate a 'secure
buffer' and send the corresponding 'secure handle' along with the
encrypted, compressed video data to the TEE. The TEE will then decrypt
the video and store the result in the 'secure buffer'. The REE will
then allocate a 'secure surface'. The REE will pass the 'secure
handles' for both the 'secure buffer' and 'secure surface' into the
TEE for video decoding. The video decoder HW will then decode the
contents of the 'secure buffer' and place the result in the 'secure
surface'. The REE will then attach the 'secure surface' to the overlay
plane for rendering of the video.

Everything relating to ensuring security of the actual contents of the
'secure buffer' and 'secure surface' is out of scope for the REE and
is the responsibility of the TEE.

DRM driver handles allocation of gem objects that are backed by a 'secure
surface' and for displaying a 'secure surface' on the overlay plane.
This introduces a new flag for object creation called
DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure
surface'. All changes here are in MediaTek specific code.
---
TODO:
1) Remove get sec larb port interface in ddp_comp, ovl and ovl_adaptor.
2) Verify instruction for enabling/disabling dapc and larb port in TEE
   drop the sec_engine flags in normal world and.
3) Move DISP_REG_OVL_SECURE setting to secure world for mtk_disp_ovl.c.
4) Change the parameter register address in mtk_ddp_sec_write()
   from "u32 addr" to "struct cmdq_client_reg *cmdq_reg".
5) Implement setting mmsys routing table in the secure world series.
---
Based on 5 series and 1 patch:
[1] v3 dma-buf: heaps: Add MediaTek secure heap
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=809023
[2] v3 add driver to support secure video decoder
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=807308
[3] v4 soc: mediatek: Add register definitions for GCE
- https://patchwork.kernel.org/project/linux-mediatek/patch/20231212121957.19231-2-shawn.sung at mediatek.com/
[4] v2 Add CMDQ driver support for mt8188
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=810302
[5] Add mediatek,gce-events definition to mediatek,gce-mailbox bindings
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=810938
[6] v3 Add CMDQ secure driver for SVP
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=812379
---
Change in v3:
1. fix kerneldoc problems
2. fix typo in title and commit message
3. adjust naming for secure variable
4. add the missing part for is_suecure plane implementation
5. use BIT_ULL macro to replace bit shifting
6. move modification of ovl_adaptor part to the correct patch
7. add TODO list in commit message
8. add commit message for using share memory to store execute count

Change in v2:

1. remove the DRIVER_RDNDER flag for mtk_drm_ioctl
2. move cmdq_insert_backup_cookie into client driver
3. move secure gce node define from mt8195-cherry.dtsi to mt8195.dtsi
---
CK Hu (1):
  drm/mediatek: Add interface to allocate MediaTek GEM buffer.

Jason-JH.Lin (10):
  drm/mediatek/uapi: Add DRM_MTK_GEM_CREATE_ENCRYPTED flag
  drm/mediatek: Add secure buffer control flow to mtk_drm_gem
  drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane
  drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info
  drm/mediatek: Add get_sec_port interface to mtk_ddp_comp
  drm/mediatek: Add secure layer config support for ovl
  drm/mediatek: Add secure layer config support for ovl_adaptor
  drm/mediatek: Add secure flow support to mediatek-drm
  drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt finalize
  arm64: dts: mt8195: Add secure mbox settings for vdosys

 arch/arm64/boot/dts/mediatek/mt8195.dtsi      |   6 +-
 drivers/gpu/drm/mediatek/mtk_disp_drv.h       |   3 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c       |  31 +-
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   |  15 +
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c       | 274 +++++++++++++++++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h       |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |  30 ++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   |  14 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c        |  13 +
 drivers/gpu/drm/mediatek/mtk_drm_gem.c        | 122 ++++++++
 drivers/gpu/drm/mediatek/mtk_drm_gem.h        |  16 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.c      |  26 ++
 drivers/gpu/drm/mediatek/mtk_drm_plane.h      |   2 +
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c       |  11 +-
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.h       |   2 +
 include/uapi/drm/mediatek_drm.h               |  59 ++++
 16 files changed, 607 insertions(+), 18 deletions(-)
 create mode 100644 include/uapi/drm/mediatek_drm.h

-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:29 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:29 +0800
Subject: [PATCH v3 08/11] drm/mediatek: Add secure layer config support for ovl_adaptor
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-9-jason-jh.lin@mediatek.com>

Add secure layer config support for ovl_adaptor and sub driver mdp_rdma.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h         |  1 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 +++++++++++++++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c     |  1 +
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c         | 11 ++++++++---
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.h         |  2 ++
 5 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 77054adcd9cf..ec9746767468 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -117,6 +117,7 @@ void mtk_ovl_adaptor_clk_disable(struct device *dev);
 void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
 			    unsigned int h, unsigned int vrefresh,
 			    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+u64 mtk_ovl_adaptor_get_sec_port(struct mtk_ddp_comp *comp, unsigned int idx);
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
 				  struct mtk_plane_state *state,
 				  struct cmdq_pkt *cmdq_pkt);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 6bf6367853fb..f419c2e70ba3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -83,6 +83,18 @@ static const struct ovl_adaptor_comp_match comp_matches[OVL_ADAPTOR_ID_MAX] = {
 	[OVL_ADAPTOR_ETHDR0]	= { OVL_ADAPTOR_TYPE_ETHDR, 0 },
 };
 
+static const u64 ovl_adaptor_sec_port[] = {
+	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L0),
+	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L1),
+	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L2),
+	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L3),
+};
+
+u64 mtk_ovl_adaptor_get_sec_port(struct mtk_ddp_comp *comp, unsigned int idx)
+{
+	return ovl_adaptor_sec_port[idx];
+}
+
 void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
 				  struct mtk_plane_state *state,
 				  struct cmdq_pkt *cmdq_pkt)
@@ -141,6 +153,9 @@ void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
 	rdma_config.pitch = pending->pitch;
 	rdma_config.fmt = pending->format;
 	rdma_config.color_encoding = pending->color_encoding;
+	rdma_config.source_size = (pending->height - 1) * pending->pitch +
+				  pending->width * fmt_info->cpp[0];
+	rdma_config.is_secure = state->pending.is_secure;
 	mtk_mdp_rdma_config(rdma_l, &rdma_config, cmdq_pkt);
 
 	if (use_dual_pipe) {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 6aed7647dfc0..9b7fe34df9a6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -445,6 +445,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl_adaptor = {
 	.remove = mtk_ovl_adaptor_remove_comp,
 	.get_formats = mtk_ovl_adaptor_get_formats,
 	.get_num_formats = mtk_ovl_adaptor_get_num_formats,
+	.get_sec_port = mtk_ovl_adaptor_get_sec_port,
 };
 
 static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
index c3adaeefd551..a164ba82d022 100644
--- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
@@ -94,6 +94,7 @@ struct mtk_mdp_rdma {
 	void __iomem		*regs;
 	struct clk		*clk;
 	struct cmdq_client_reg	cmdq_reg;
+	resource_size_t		regs_pa;
 };
 
 static unsigned int rdma_fmt_convert(unsigned int fmt)
@@ -198,9 +199,12 @@ void mtk_mdp_rdma_config(struct device *dev, struct mtk_mdp_rdma_cfg *cfg,
 	else
 		mtk_ddp_write_mask(cmdq_pkt, 0, &priv->cmdq_reg, priv->regs,
 				   MDP_RDMA_SRC_CON, FLD_OUTPUT_ARGB);
-
-	mtk_ddp_write_mask(cmdq_pkt, cfg->addr0, &priv->cmdq_reg, priv->regs,
-			   MDP_RDMA_SRC_BASE_0, FLD_SRC_BASE_0);
+	if (cfg->is_secure)
+		mtk_ddp_sec_write(cmdq_pkt, priv->regs_pa + MDP_RDMA_SRC_BASE_0,
+				  cfg->addr0, CMDQ_IWC_H_2_MVA, 0, cfg->source_size, 0);
+	else
+		mtk_ddp_write_mask(cmdq_pkt, cfg->addr0, &priv->cmdq_reg, priv->regs,
+				   MDP_RDMA_SRC_BASE_0, FLD_SRC_BASE_0);
 
 	mtk_ddp_write_mask(cmdq_pkt, src_pitch_y, &priv->cmdq_reg, priv->regs,
 			   MDP_RDMA_MF_BKGD_SIZE_IN_BYTE, FLD_MF_BKGD_WB);
@@ -285,6 +289,7 @@ static int mtk_mdp_rdma_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->regs_pa = res->start;
 	priv->regs = devm_ioremap_resource(dev, res);
 	if (IS_ERR(priv->regs)) {
 		dev_err(dev, "failed to ioremap rdma\n");
diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.h b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.h
index 9943ee3aac31..cd4840411411 100644
--- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.h
+++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.h
@@ -15,6 +15,8 @@ struct mtk_mdp_rdma_cfg {
 	unsigned int	y_top;
 	int		fmt;
 	int		color_encoding;
+	unsigned int	source_size;
+	unsigned int	is_secure;
 };
 
 #endif // __MTK_MDP_RDMA_H__
-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:31 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:31 +0800
Subject: [PATCH v3 10/11] drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt finalize
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-11-jason-jh.lin@mediatek.com>

Add cmdq_insert_backup_cookie to append some commands before EOC:
1. Get GCE HW thread execute count from the GCE HW register.
2. Add 1 to the execute count and then store into a shared memory.
3. Set a software event siganl as secure irq to GCE HW.

Since the value of execute count + 1 is stored in a shared memory,
CMDQ driver in the normal world can use it to handle task done in irq
handler and CMDQ driver in the secure world will use it to schedule
the task slot for each secure thread.

The reason why we use shared memory to record execute count here is:
1. normal world can not access the register of secure GCE thread in
normal world.
2. calling TEE invoke cmd in the irq handler would be expensive and not
stable. I've tested that a single TEE invloke cmd to CMDQ PTA costs
19~53 us. Maybe it would cost more during the scenario that needs more
CPU loading.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 79617c0f016d..856513a14cda 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -179,7 +179,7 @@ void mtk_crtc_disable_secure_state(struct drm_crtc *crtc)
 		sec_scn = CMDQ_SEC_SCNR_SUB_DISP_DISABLE;
 
 	cmdq_sec_pkt_set_data(&mtk_crtc->sec_cmdq_handle, sec_engine, sec_engine, sec_scn);
-
+	cmdq_sec_insert_backup_cookie(&mtk_crtc->sec_cmdq_handle);
 	cmdq_pkt_finalize(&mtk_crtc->sec_cmdq_handle);
 	dma_sync_single_for_device(mtk_crtc->sec_cmdq_client.chan->mbox->dev,
 				   mtk_crtc->sec_cmdq_handle.pa_base,
@@ -791,6 +791,8 @@ static void mtk_drm_crtc_update_config(struct mtk_drm_crtc *mtk_crtc,
 		cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
 		cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
 		mtk_crtc_ddp_config(crtc, cmdq_handle);
+		if (cmdq_handle->sec_data)
+			cmdq_sec_insert_backup_cookie(cmdq_handle);
 		cmdq_pkt_finalize(cmdq_handle);
 		dma_sync_single_for_device(cmdq_client.chan->mbox->dev,
 					   cmdq_handle->pa_base,
-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:28 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:28 +0800
Subject: [PATCH v3 07/11] drm/mediatek: Add secure layer config support for ovl
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-8-jason-jh.lin@mediatek.com>

Add secure layer config support for ovl.

TODO:
1. Move DISP_REG_OVL_SECURE setting to secure world.
2. Change the parameter register address in mtk_ddp_sec_write()
   from "u32 addr" to "struct cmdq_client_reg *cmdq_reg".

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h     |  2 ++
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c     | 31 +++++++++++++++++++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 29 +++++++++++++++++++
 3 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 1311562d25cc..77054adcd9cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -9,6 +9,7 @@
 #include <linux/soc/mediatek/mtk-cmdq.h>
 #include <linux/soc/mediatek/mtk-mmsys.h>
 #include <linux/soc/mediatek/mtk-mutex.h>
+#include "mtk_drm_ddp_comp.h"
 #include "mtk_drm_plane.h"
 #include "mtk_mdp_rdma.h"
 
@@ -82,6 +83,7 @@ void mtk_ovl_clk_disable(struct device *dev);
 void mtk_ovl_config(struct device *dev, unsigned int w,
 		    unsigned int h, unsigned int vrefresh,
 		    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+u64 mtk_ovl_get_sec_port(struct mtk_ddp_comp *comp, unsigned int idx);
 int mtk_ovl_layer_check(struct device *dev, unsigned int idx,
 			struct mtk_plane_state *mtk_state);
 void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 2bffe4245466..c18f76412a2e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -46,6 +46,7 @@
 #define DISP_REG_OVL_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n))
 #define DISP_REG_OVL_HDR_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n) + 0x04)
 #define DISP_REG_OVL_HDR_PITCH(ovl, n)		((ovl)->data->addr + 0x20 * (n) + 0x08)
+#define DISP_REG_OVL_SECURE			0x0fc0
 
 #define GMC_THRESHOLD_BITS	16
 #define GMC_THRESHOLD_HIGH	((1 << GMC_THRESHOLD_BITS) / 4)
@@ -126,8 +127,19 @@ struct mtk_disp_ovl {
 	const struct mtk_disp_ovl_data	*data;
 	void				(*vblank_cb)(void *data);
 	void				*vblank_cb_data;
+	resource_size_t			regs_pa;
 };
 
+u64 mtk_ovl_get_sec_port(struct mtk_ddp_comp *comp, unsigned int idx)
+{
+	if (comp->id == DDP_COMPONENT_OVL0)
+		return BIT_ULL(CMDQ_SEC_DISP_OVL0);
+	else if (comp->id == DDP_COMPONENT_OVL1)
+		return BIT_ULL(CMDQ_SEC_DISP_OVL1);
+
+	return 0;
+}
+
 static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
 {
 	struct mtk_disp_ovl *priv = dev_id;
@@ -449,8 +461,22 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
 			      DISP_REG_OVL_SRC_SIZE(idx));
 	mtk_ddp_write_relaxed(cmdq_pkt, offset, &ovl->cmdq_reg, ovl->regs,
 			      DISP_REG_OVL_OFFSET(idx));
-	mtk_ddp_write_relaxed(cmdq_pkt, addr, &ovl->cmdq_reg, ovl->regs,
-			      DISP_REG_OVL_ADDR(ovl, idx));
+
+	if (state->pending.is_secure) {
+		const struct drm_format_info *fmt_info = drm_format_info(fmt);
+		unsigned int buf_size = (pending->height - 1) * pending->pitch +
+					pending->width * fmt_info->cpp[0];
+
+		mtk_ddp_write_mask(cmdq_pkt, BIT(idx), &ovl->cmdq_reg, ovl->regs,
+				   DISP_REG_OVL_SECURE, BIT(idx));
+		mtk_ddp_sec_write(cmdq_pkt, ovl->regs_pa + DISP_REG_OVL_ADDR(ovl, idx),
+				  pending->addr, CMDQ_IWC_H_2_MVA, 0, buf_size, 0);
+	} else {
+		mtk_ddp_write_mask(cmdq_pkt, 0, &ovl->cmdq_reg, ovl->regs,
+				   DISP_REG_OVL_SECURE, BIT(idx));
+		mtk_ddp_write_relaxed(cmdq_pkt, addr, &ovl->cmdq_reg, ovl->regs,
+				      DISP_REG_OVL_ADDR(ovl, idx));
+	}
 
 	if (is_afbc) {
 		mtk_ddp_write_relaxed(cmdq_pkt, hdr_addr, &ovl->cmdq_reg, ovl->regs,
@@ -529,6 +555,7 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
 	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->regs_pa = res->start;
 	priv->regs = devm_ioremap_resource(dev, res);
 	if (IS_ERR(priv->regs)) {
 		dev_err(dev, "failed to ioremap ovl\n");
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3046c0409353..6aed7647dfc0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -111,6 +111,34 @@ void mtk_ddp_write_mask(struct cmdq_pkt *cmdq_pkt, unsigned int value,
 #endif
 }
 
+void mtk_ddp_sec_write(struct cmdq_pkt *cmdq_pkt, u32 addr, u64 base,
+		       const enum cmdq_iwc_addr_metadata_type type,
+		       const u32 offset, const u32 size, const u32 port)
+{
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	if (!cmdq_pkt)
+		return;
+
+	/* secure buffer will be 4K alignment */
+	cmdq_sec_pkt_write(cmdq_pkt, addr, base, type,
+			   offset, ALIGN(size, PAGE_SIZE), port);
+#endif
+}
+
+void mtk_ddp_sec_write(struct cmdq_pkt *cmdq_pkt, u32 addr, u64 base,
+		       const enum cmdq_iwc_addr_metadata_type type,
+		       const u32 offset, const u32 size, const u32 port)
+{
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	if (!cmdq_pkt)
+		return;
+
+	/* secure buffer will be 4K alignment */
+	cmdq_sec_pkt_write(cmdq_pkt, addr, base, type,
+			   offset, ALIGN(size, PAGE_SIZE), port);
+#endif
+}
+
 static int mtk_ddp_clk_enable(struct device *dev)
 {
 	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
@@ -365,6 +393,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = {
 	.bgclr_in_off = mtk_ovl_bgclr_in_off,
 	.get_formats = mtk_ovl_get_formats,
 	.get_num_formats = mtk_ovl_get_num_formats,
+	.get_sec_port = mtk_ovl_get_sec_port,
 };
 
 static const struct mtk_ddp_comp_funcs ddp_postmask = {
-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:30 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:30 +0800
Subject: [PATCH v3 09/11] drm/mediatek: Add secure flow support to mediatek-drm
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-10-jason-jh.lin@mediatek.com>

To add secure flow support for mediatek-drm, each crtc have to
create a secure cmdq mailbox channel. Then cmdq packets with
display HW configuration will be sent to secure cmdq mailbox channel
and configured in the secure world.

Each crtc have to use secure cmdq interface to configure some secure
settings for display HW before sending cmdq packets to secure cmdq
mailbox channel.

If any of fb get from current drm_atomic_state is secure, then crtc
will switch to the secure flow to configure display HW.
If all fbs are not secure in current drm_atomic_state, then crtc will
switch to the normal flow.

TODO:
1. Remove get sec larb port interface in ddp_comp, ovl and ovl_adaptor.
2. Verify instruction for enabling/disabling dapc and larb port in TEE
   drop the sec_engine flags in normal world.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  | 272 ++++++++++++++++++++++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h  |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.c |   7 +
 3 files changed, 269 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index db43f9dff912..79617c0f016d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -56,6 +56,11 @@ struct mtk_drm_crtc {
 	u32				cmdq_event;
 	u32				cmdq_vblank_cnt;
 	wait_queue_head_t		cb_blocking_queue;
+
+	struct cmdq_client		sec_cmdq_client;
+	struct cmdq_pkt			sec_cmdq_handle;
+	bool				sec_cmdq_working;
+	wait_queue_head_t		sec_cb_blocking_queue;
 #endif
 
 	struct device			*mmsys_dev;
@@ -69,6 +74,7 @@ struct mtk_drm_crtc {
 	/* lock for display hardware access */
 	struct mutex			hw_lock;
 	bool				config_updating;
+	bool				sec_on;
 };
 
 struct mtk_crtc_state {
@@ -111,6 +117,154 @@ static void mtk_drm_finish_page_flip(struct mtk_drm_crtc *mtk_crtc)
 	}
 }
 
+void mtk_crtc_disable_secure_state(struct drm_crtc *crtc)
+{
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	enum cmdq_sec_scenario sec_scn = CMDQ_SEC_SCNR_MAX;
+	int i;
+	struct mtk_ddp_comp *ddp_first_comp;
+	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+	u64 sec_engine = 0; /* for hw engine write output secure fb */
+	u64 sec_port = 0; /* for larb port read input secure fb */
+
+	mutex_lock(&mtk_crtc->hw_lock);
+
+	if (!mtk_crtc->sec_cmdq_client.chan) {
+		pr_err("crtc-%d secure mbox channel is NULL\n", drm_crtc_index(crtc));
+		goto err;
+	}
+
+	if (!mtk_crtc->sec_on) {
+		pr_debug("crtc-%d is already disabled!\n", drm_crtc_index(crtc));
+		goto err;
+	}
+
+	mbox_flush(mtk_crtc->sec_cmdq_client.chan, 0);
+	mtk_crtc->sec_cmdq_handle.cmd_buf_size = 0;
+
+	if (mtk_crtc->sec_cmdq_handle.sec_data) {
+		struct cmdq_sec_data *sec_data;
+
+		sec_data = mtk_crtc->sec_cmdq_handle.sec_data;
+		sec_data->addr_metadata_cnt = 0;
+		sec_data->addr_metadatas = (uintptr_t)NULL;
+	}
+
+	/*
+	 * Secure path only support DL mode, so we just wait
+	 * the first path frame done here
+	 */
+	cmdq_pkt_wfe(&mtk_crtc->sec_cmdq_handle, mtk_crtc->cmdq_event, false);
+
+	ddp_first_comp = mtk_crtc->ddp_comp[0];
+	for (i = 0; i < mtk_crtc->layer_nr; i++) {
+		struct drm_plane *plane = &mtk_crtc->planes[i];
+
+		sec_port |= mtk_ddp_comp_layer_get_sec_port(ddp_first_comp, i);
+
+		/* make sure secure layer off before switching secure state */
+		if (!mtk_plane_fb_is_secure(plane->state->fb)) {
+			struct mtk_plane_state *plane_state = to_mtk_plane_state(plane->state);
+
+			plane_state->pending.enable = false;
+			mtk_ddp_comp_layer_config(ddp_first_comp, i, plane_state,
+						  &mtk_crtc->sec_cmdq_handle);
+		}
+	}
+
+	/* Disable secure path */
+	if (drm_crtc_index(crtc) == 0)
+		sec_scn = CMDQ_SEC_SCNR_PRIMARY_DISP_DISABLE;
+	else if (drm_crtc_index(crtc) == 1)
+		sec_scn = CMDQ_SEC_SCNR_SUB_DISP_DISABLE;
+
+	cmdq_sec_pkt_set_data(&mtk_crtc->sec_cmdq_handle, sec_engine, sec_engine, sec_scn);
+
+	cmdq_pkt_finalize(&mtk_crtc->sec_cmdq_handle);
+	dma_sync_single_for_device(mtk_crtc->sec_cmdq_client.chan->mbox->dev,
+				   mtk_crtc->sec_cmdq_handle.pa_base,
+				   mtk_crtc->sec_cmdq_handle.cmd_buf_size,
+				   DMA_TO_DEVICE);
+
+	mtk_crtc->sec_cmdq_working = true;
+	mbox_send_message(mtk_crtc->sec_cmdq_client.chan, &mtk_crtc->sec_cmdq_handle);
+	mbox_client_txdone(mtk_crtc->sec_cmdq_client.chan, 0);
+
+	// Wait for sec state to be disabled by cmdq
+	wait_event_timeout(mtk_crtc->sec_cb_blocking_queue,
+			   !mtk_crtc->sec_cmdq_working,
+			   msecs_to_jiffies(500));
+
+	mtk_crtc->sec_on = false;
+	pr_debug("crtc-%d disable secure plane!\n", drm_crtc_index(crtc));
+
+err:
+	mutex_unlock(&mtk_crtc->hw_lock);
+#endif
+}
+
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+static void mtk_crtc_enable_secure_state(struct drm_crtc *crtc)
+{
+	enum cmdq_sec_scenario sec_scn = CMDQ_SEC_SCNR_MAX;
+	int i;
+	struct mtk_ddp_comp *ddp_first_comp;
+	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+	u64 sec_engine = 0; /* for hw engine write output secure fb */
+	u64 sec_port = 0; /* for larb port read input secure fb */
+
+	cmdq_pkt_wfe(&mtk_crtc->sec_cmdq_handle, mtk_crtc->cmdq_event, false);
+
+	ddp_first_comp = mtk_crtc->ddp_comp[0];
+	for (i = 0; i < mtk_crtc->layer_nr; i++)
+		if (mtk_crtc->planes[i].type == DRM_PLANE_TYPE_CURSOR)
+			sec_port |= mtk_ddp_comp_layer_get_sec_port(ddp_first_comp, i);
+
+	if (drm_crtc_index(crtc) == 0)
+		sec_scn = CMDQ_SEC_SCNR_PRIMARY_DISP;
+	else if (drm_crtc_index(crtc) == 1)
+		sec_scn = CMDQ_SEC_SCNR_SUB_DISP;
+
+	cmdq_sec_pkt_set_data(&mtk_crtc->sec_cmdq_handle, sec_engine, sec_port, sec_scn);
+
+	pr_debug("crtc-%d enable secure plane!\n", drm_crtc_index(crtc));
+}
+#endif
+
+static void mtk_drm_crtc_plane_switch_sec_state(struct drm_crtc *crtc,
+						struct drm_atomic_state *state)
+{
+#if IS_REACHABLE(CONFIG_MTK_CMDQ)
+	bool sec_on[MAX_CRTC] = {0};
+	int i;
+	struct drm_crtc_state *crtc_state;
+	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+	struct drm_plane *plane;
+	struct drm_plane_state *old_plane_state;
+
+	for_each_old_plane_in_state(state, plane, old_plane_state, i) {
+		if (!plane->state->crtc)
+			continue;
+
+		if (plane->state->fb &&
+		    mtk_plane_fb_is_secure(plane->state->fb) &&
+		    mtk_crtc->sec_cmdq_client.chan)
+			sec_on[drm_crtc_index(plane->state->crtc)] = true;
+	}
+
+	for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
+		mtk_crtc = to_mtk_crtc(crtc);
+
+		if (!sec_on[i])
+			mtk_crtc_disable_secure_state(crtc);
+
+		mutex_lock(&mtk_crtc->hw_lock);
+		mtk_crtc->sec_on = true;
+		mutex_unlock(&mtk_crtc->hw_lock);
+	}
+#endif
+}
+
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 static int mtk_drm_cmdq_pkt_create(struct cmdq_client *client, struct cmdq_pkt *pkt,
 				   size_t size)
@@ -146,22 +300,33 @@ static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
 	dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
 			 DMA_TO_DEVICE);
 	kfree(pkt->va_base);
+	kfree(pkt->sec_data);
 }
 #endif
 
 static void mtk_drm_crtc_destroy(struct drm_crtc *crtc)
 {
 	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+	struct mtk_drm_private *priv = crtc->dev->dev_private;
 	int i;
 
+	priv = priv->all_drm_private[drm_crtc_index(crtc)];
+
 	mtk_mutex_put(mtk_crtc->mutex);
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 	mtk_drm_cmdq_pkt_destroy(&mtk_crtc->cmdq_handle);
+	mtk_drm_cmdq_pkt_destroy(&mtk_crtc->sec_cmdq_handle);
 
 	if (mtk_crtc->cmdq_client.chan) {
 		mbox_free_channel(mtk_crtc->cmdq_client.chan);
 		mtk_crtc->cmdq_client.chan = NULL;
 	}
+
+	if (mtk_crtc->sec_cmdq_client.chan) {
+		device_link_remove(priv->dev, mtk_crtc->sec_cmdq_client.chan->mbox->dev);
+		mbox_free_channel(mtk_crtc->sec_cmdq_client.chan);
+		mtk_crtc->sec_cmdq_client.chan = NULL;
+	}
 #endif
 
 	for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
@@ -288,13 +453,18 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
 {
 	struct cmdq_cb_data *data = mssg;
 	struct cmdq_client *cmdq_cl = container_of(cl, struct cmdq_client, client);
-	struct mtk_drm_crtc *mtk_crtc = container_of(cmdq_cl, struct mtk_drm_crtc, cmdq_client);
+	struct mtk_drm_crtc *mtk_crtc;
 	struct mtk_crtc_state *state;
 	unsigned int i;
 
 	if (data->sta < 0)
 		return;
 
+	if (!data->pkt || !data->pkt->sec_data)
+		mtk_crtc = container_of(cmdq_cl, struct mtk_drm_crtc, cmdq_client);
+	else
+		mtk_crtc = container_of(cmdq_cl, struct mtk_drm_crtc, sec_cmdq_client);
+
 	state = to_mtk_crtc_state(mtk_crtc->base.state);
 
 	state->pending_config = false;
@@ -323,6 +493,11 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
 		mtk_crtc->pending_async_planes = false;
 	}
 
+	if (mtk_crtc->sec_cmdq_working) {
+		mtk_crtc->sec_cmdq_working = false;
+		wake_up(&mtk_crtc->sec_cb_blocking_queue);
+	}
+
 	mtk_crtc->cmdq_vblank_cnt = 0;
 	wake_up(&mtk_crtc->cb_blocking_queue);
 }
@@ -549,7 +724,8 @@ static void mtk_drm_crtc_update_config(struct mtk_drm_crtc *mtk_crtc,
 				       bool needs_vblank)
 {
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
-	struct cmdq_pkt *cmdq_handle = &mtk_crtc->cmdq_handle;
+	struct cmdq_client cmdq_client;
+	struct cmdq_pkt *cmdq_handle;
 #endif
 	struct drm_crtc *crtc = &mtk_crtc->base;
 	struct mtk_drm_private *priv = crtc->dev->dev_private;
@@ -587,14 +763,36 @@ static void mtk_drm_crtc_update_config(struct mtk_drm_crtc *mtk_crtc,
 		mtk_mutex_release(mtk_crtc->mutex);
 	}
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
-	if (mtk_crtc->cmdq_client.chan) {
+	if (mtk_crtc->sec_on) {
+		mbox_flush(mtk_crtc->sec_cmdq_client.chan, 0);
+		mtk_crtc->sec_cmdq_handle.cmd_buf_size = 0;
+
+		if (mtk_crtc->sec_cmdq_handle.sec_data) {
+			struct cmdq_sec_data *sec_data;
+
+			sec_data = mtk_crtc->sec_cmdq_handle.sec_data;
+			sec_data->addr_metadata_cnt = 0;
+			sec_data->addr_metadatas = (uintptr_t)NULL;
+		}
+
+		mtk_crtc_enable_secure_state(crtc);
+
+		cmdq_client = mtk_crtc->sec_cmdq_client;
+		cmdq_handle = &mtk_crtc->sec_cmdq_handle;
+	} else if (mtk_crtc->cmdq_client.chan) {
 		mbox_flush(mtk_crtc->cmdq_client.chan, 2000);
-		cmdq_handle->cmd_buf_size = 0;
+		mtk_crtc->cmdq_handle.cmd_buf_size = 0;
+
+		cmdq_client =  mtk_crtc->cmdq_client;
+		cmdq_handle = &mtk_crtc->cmdq_handle;
+	}
+
+	if (cmdq_client.chan) {
 		cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
 		cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
 		mtk_crtc_ddp_config(crtc, cmdq_handle);
 		cmdq_pkt_finalize(cmdq_handle);
-		dma_sync_single_for_device(mtk_crtc->cmdq_client.chan->mbox->dev,
+		dma_sync_single_for_device(cmdq_client.chan->mbox->dev,
 					   cmdq_handle->pa_base,
 					   cmdq_handle->cmd_buf_size,
 					   DMA_TO_DEVICE);
@@ -607,8 +805,8 @@ static void mtk_drm_crtc_update_config(struct mtk_drm_crtc *mtk_crtc,
 		 */
 		mtk_crtc->cmdq_vblank_cnt = 3;
 
-		mbox_send_message(mtk_crtc->cmdq_client.chan, cmdq_handle);
-		mbox_client_txdone(mtk_crtc->cmdq_client.chan, 0);
+		mbox_send_message(cmdq_client.chan, cmdq_handle);
+		mbox_client_txdone(cmdq_client.chan, 0);
 	}
 #endif
 	mtk_crtc->config_updating = false;
@@ -750,6 +948,8 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
 	if (!mtk_crtc->enabled)
 		return;
 
+	mtk_crtc_disable_secure_state(crtc);
+
 	/* Set all pending plane state to disabled */
 	for (i = 0; i < mtk_crtc->layer_nr; i++) {
 		struct drm_plane *plane = &mtk_crtc->planes[i];
@@ -790,6 +990,8 @@ static void mtk_drm_crtc_atomic_begin(struct drm_crtc *crtc,
 	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
 	unsigned long flags;
 
+	mtk_drm_crtc_plane_switch_sec_state(crtc, state);
+
 	if (mtk_crtc->event && mtk_crtc_state->base.event)
 		DRM_ERROR("new event while there is still a pending event\n");
 
@@ -1082,8 +1284,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
 		if (ret) {
 			dev_dbg(dev, "mtk_crtc %d failed to get mediatek,gce-events property\n",
 				drm_crtc_index(&mtk_crtc->base));
-			mbox_free_channel(mtk_crtc->cmdq_client.chan);
-			mtk_crtc->cmdq_client.chan = NULL;
+			goto cmdq_err;
 		} else {
 			ret = mtk_drm_cmdq_pkt_create(&mtk_crtc->cmdq_client,
 						      &mtk_crtc->cmdq_handle,
@@ -1091,14 +1292,63 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
 			if (ret) {
 				dev_dbg(dev, "mtk_crtc %d failed to create cmdq packet\n",
 					drm_crtc_index(&mtk_crtc->base));
-				mbox_free_channel(mtk_crtc->cmdq_client.chan);
-				mtk_crtc->cmdq_client.chan = NULL;
+				goto cmdq_err;
 			}
 		}
 
 		/* for sending blocking cmd in crtc disable */
 		init_waitqueue_head(&mtk_crtc->cb_blocking_queue);
 	}
+
+	mtk_crtc->sec_cmdq_client.client.dev = mtk_crtc->mmsys_dev;
+	mtk_crtc->sec_cmdq_client.client.tx_block = false;
+	mtk_crtc->sec_cmdq_client.client.knows_txdone = true;
+	mtk_crtc->sec_cmdq_client.client.rx_callback = ddp_cmdq_cb;
+	mtk_crtc->sec_cmdq_client.chan =
+			mbox_request_channel(&mtk_crtc->sec_cmdq_client.client, i + 1);
+	if (IS_ERR(mtk_crtc->sec_cmdq_client.chan)) {
+		dev_err(dev, "mtk_crtc %d failed to create sec mailbox client\n",
+			drm_crtc_index(&mtk_crtc->base));
+		mtk_crtc->sec_cmdq_client.chan = NULL;
+	}
+
+	if (mtk_crtc->sec_cmdq_client.chan) {
+		struct device_link *link;
+
+		/* add devlink to cmdq dev to make sure suspend/resume order is correct */
+		link = device_link_add(priv->dev, mtk_crtc->sec_cmdq_client.chan->mbox->dev,
+				       DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+		if (!link) {
+			dev_err(priv->dev, "Unable to link dev=%s\n",
+				dev_name(mtk_crtc->sec_cmdq_client.chan->mbox->dev));
+			ret = -ENODEV;
+			goto cmdq_err;
+		}
+
+		ret = mtk_drm_cmdq_pkt_create(&mtk_crtc->sec_cmdq_client,
+					      &mtk_crtc->sec_cmdq_handle,
+					      PAGE_SIZE);
+		if (ret) {
+			dev_dbg(dev, "mtk_crtc %d failed to create cmdq secure packet\n",
+				drm_crtc_index(&mtk_crtc->base));
+			goto cmdq_err;
+		}
+
+		/* for sending blocking cmd in crtc disable */
+		init_waitqueue_head(&mtk_crtc->sec_cb_blocking_queue);
+	}
+
+cmdq_err:
+	if (ret) {
+		if (mtk_crtc->cmdq_client.chan) {
+			mbox_free_channel(mtk_crtc->cmdq_client.chan);
+			mtk_crtc->cmdq_client.chan = NULL;
+		}
+		if (mtk_crtc->sec_cmdq_client.chan) {
+			mbox_free_channel(mtk_crtc->sec_cmdq_client.chan);
+			mtk_crtc->sec_cmdq_client.chan = NULL;
+		}
+	}
 #endif
 
 	if (conn_routes) {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index 1f988ff1bf9f..cf8433846108 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -21,6 +21,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
 			int priv_data_index,
 			const struct mtk_drm_route *conn_routes,
 			unsigned int num_conn_routes);
+void mtk_crtc_disable_secure_state(struct drm_crtc *crtc);
 int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,
 			     struct mtk_plane_state *state);
 void mtk_drm_crtc_async_update(struct drm_crtc *crtc, struct drm_plane *plane,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index d4d515627ca4..96293c632d67 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -287,6 +287,13 @@ static void mtk_plane_atomic_disable(struct drm_plane *plane,
 	mtk_plane_state->pending.enable = false;
 	wmb(); /* Make sure the above parameter is set before update */
 	mtk_plane_state->pending.dirty = true;
+
+	if (mtk_plane_state->pending.is_secure) {
+		struct drm_plane_state *old_state = drm_atomic_get_old_plane_state(state, plane);
+
+		if (old_state->crtc)
+			mtk_crtc_disable_secure_state(old_state->crtc);
+	}
 }
 
 static void mtk_plane_atomic_update(struct drm_plane *plane,
-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:32 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:32 +0800
Subject: [PATCH v3 11/11] arm64: dts: mt8195: Add secure mbox settings for vdosys
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-12-jason-jh.lin@mediatek.com>

Add a secure mailbox channel to support secure video path on
vdosys0 and vdosys1.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8195.dtsi | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index e0ac2e9f5b72..416d575be123 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -2621,7 +2621,8 @@
 		vdosys0: syscon at 1c01a000 {
 			compatible = "mediatek,mt8195-vdosys0", "mediatek,mt8195-mmsys", "syscon";
 			reg = <0 0x1c01a000 0 0x1000>;
-			mboxes = <&gce0 0 CMDQ_THR_PRIO_4>;
+			mboxes = <&gce0 0 CMDQ_THR_PRIO_4>,
+				 <&gce0 8 CMDQ_THR_PRIO_4>; /* secure mbox */
 			#clock-cells = <1>;
 		};
 
@@ -2806,7 +2807,8 @@
 		vdosys1: syscon at 1c100000 {
 			compatible = "mediatek,mt8195-vdosys1", "syscon";
 			reg = <0 0x1c100000 0 0x1000>;
-			mboxes = <&gce0 1 CMDQ_THR_PRIO_4>;
+			mboxes = <&gce0 1 CMDQ_THR_PRIO_4>,
+				 <&gce0 9 CMDQ_THR_PRIO_4>; /* secure mbox */;
 			mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX 0x0000 0x1000>;
 			#clock-cells = <1>;
 			#reset-cells = <1>;
-- 
2.18.0



From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:25 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:25 +0800
Subject: [PATCH v3 04/11] drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-5-jason-jh.lin@mediatek.com>

Add is_sec flag to identify current mtk_drm_plane is secure.
Add mtk_plane_is_sec_fb() to check current drm_framebuffer is secure.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 19 +++++++++++++++++++
 drivers/gpu/drm/mediatek/mtk_drm_plane.h |  2 ++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index ddc9355b06d5..d4d515627ca4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -210,6 +210,7 @@ static void mtk_plane_update_new_state(struct drm_plane_state *new_state,
 	mtk_plane_state->pending.height = drm_rect_height(&new_state->dst);
 	mtk_plane_state->pending.rotation = new_state->rotation;
 	mtk_plane_state->pending.color_encoding = new_state->color_encoding;
+	mtk_plane_state->pending.is_secure = mtk_plane_fb_is_secure(fb);
 }
 
 static void mtk_plane_atomic_async_update(struct drm_plane *plane,
@@ -348,3 +349,21 @@ int mtk_plane_init(struct drm_device *dev, struct drm_plane *plane,
 
 	return 0;
 }
+
+bool mtk_plane_fb_is_secure(struct drm_framebuffer *fb)
+{
+	struct drm_gem_object *gem = NULL;
+	struct mtk_drm_gem_obj *mtk_gem = NULL;
+
+	if (!fb)
+		return false;
+
+	gem = fb->obj[0];
+	if (!gem)
+		return false;
+
+	mtk_gem = to_mtk_gem_obj(gem);
+
+	return mtk_gem->secure;
+}
+
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.h b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
index 99aff7da0831..5a330797b5db 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
@@ -33,6 +33,7 @@ struct mtk_plane_pending_state {
 	bool				async_dirty;
 	bool				async_config;
 	enum drm_color_encoding		color_encoding;
+	bool				is_secure;
 };
 
 struct mtk_plane_state {
@@ -46,6 +47,7 @@ to_mtk_plane_state(struct drm_plane_state *state)
 	return container_of(state, struct mtk_plane_state, base);
 }
 
+bool mtk_plane_fb_is_secure(struct drm_framebuffer *fb);
 int mtk_plane_init(struct drm_device *dev, struct drm_plane *plane,
 		   unsigned long possible_crtcs, enum drm_plane_type type,
 		   unsigned int supported_rotations, const u32 *formats,
-- 
2.18.0



From krzysztof.kozlowski at linaro.org  Sat Dec 23 10:32:41 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 19:32:41 +0100
Subject: [PATCH v2 1/4] dt-bindings: display: panel: Add BOE
 TH101MB31IG002-28A panel
In-Reply-To: <20231223-pinetab2-v2-1-ec1856d0030e@mecka.net>
References: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
 <20231223-pinetab2-v2-1-ec1856d0030e@mecka.net>
Message-ID: <9cf495b8-eaa6-4dfc-9286-ba07f09c1f76@linaro.org>

On 23/12/2023 16:20, Manuel Traut wrote:
> Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
> used e.g. in the Pine64 Pinetab2 and PinetabV.
> 
> Signed-off-by: Manuel Traut <manut at mecka.net>


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From Jason-JH.Lin at mediatek.com  Sat Dec 23 10:38:31 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Sat, 23 Dec 2023 18:38:31 +0000
Subject: [PATCH v3 2/9] dt-bindings: mailbox: Add mboxes property for CMDQ
 secure driver
In-Reply-To: <20231222-unpicked-jaundice-837baa3092ed@spud>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-3-jason-jh.lin@mediatek.com>
	 <20231222-unpicked-jaundice-837baa3092ed@spud>
Message-ID: <63d64568f6c1ee68b81f9d8efb7c3c090e42e5ec.camel@mediatek.com>

Hi Conor,

Thanks for the reviews.

On Fri, 2023-12-22 at 15:07 +0000, Conor Dooley wrote:
> On Fri, Dec 22, 2023 at 12:52:21PM +0800, Jason-JH.Lin wrote:
> > Add mboxes to define a GCE loopping thread as a secure irq handler.
> > This property is only required if CMDQ secure driver is supported.
> 
> What do drivers have to do with this? Either the mailbox channel
> exists
> or it does not. That said, I am not sure why this should be in DT in
> the
> first place, can't the driver for the mailbox controller reserve a
> channel for its own use?
> 
> Thanks,
> Conor.

Since we implemented our mtk-cmdq-mailbox driver with mailbox
frameworks, one mbox channel bounds to a GCE HW thread.
So if we want to request a mbox channel for using a GCE HW thread for
secure irq handler in mtk-cmdq-mailbox driver itself, I think we need
to add this property to DT.

Regards,
Jason-JH.Lin

[snip]

From jason-jh.lin at mediatek.com  Sat Dec 23 10:29:24 2023
From: jason-jh.lin at mediatek.com (Jason-JH.Lin)
Date: Sun, 24 Dec 2023 02:29:24 +0800
Subject: [PATCH v3 03/11] drm/mediatek: Add secure buffer control flow to mtk_drm_gem
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <20231223182932.27683-4-jason-jh.lin@mediatek.com>

Add secure buffer control flow to mtk_drm_gem.

When user space takes DRM_MTK_GEM_CREATE_ENCRYPTED flag and size
to create a mtk_drm_gem object, mtk_drm_gem will find a matched size
dma buffer from secure dma-heap and bind it to mtk_drm_gem object.

Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 85 +++++++++++++++++++++++++-
 drivers/gpu/drm/mediatek/mtk_drm_gem.h |  4 ++
 2 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 30e347adcbe9..858f34a735f8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -4,6 +4,8 @@
  */
 
 #include <linux/dma-buf.h>
+#include <linux/dma-heap.h>
+#include <uapi/linux/dma-heap.h>
 #include <drm/mediatek_drm.h>
 
 #include <drm/drm.h>
@@ -55,6 +57,81 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev,
 	return mtk_gem_obj;
 }
 
+struct mtk_drm_gem_obj *mtk_drm_gem_create_from_heap(struct drm_device *dev,
+						     const char *heap, size_t size)
+{
+	struct mtk_drm_private *priv = dev->dev_private;
+	struct mtk_drm_gem_obj *mtk_gem;
+	struct drm_gem_object *obj;
+	struct dma_heap *dma_heap;
+	struct dma_buf *dma_buf;
+	struct dma_buf_attachment *attach;
+	struct sg_table *sgt;
+	struct iosys_map map = {};
+	int ret;
+
+	mtk_gem = mtk_drm_gem_init(dev, size);
+	if (IS_ERR(mtk_gem))
+		return ERR_CAST(mtk_gem);
+
+	obj = &mtk_gem->base;
+
+	dma_heap = dma_heap_find(heap);
+	if (!dma_heap) {
+		DRM_ERROR("heap find fail\n");
+		goto err_gem_free;
+	}
+	dma_buf = dma_heap_buffer_alloc(dma_heap, size,
+					O_RDWR | O_CLOEXEC, DMA_HEAP_VALID_HEAP_FLAGS);
+	if (IS_ERR(dma_buf)) {
+		DRM_ERROR("buffer alloc fail\n");
+		dma_heap_put(dma_heap);
+		goto err_gem_free;
+	}
+	dma_heap_put(dma_heap);
+
+	attach = dma_buf_attach(dma_buf, priv->dma_dev);
+	if (IS_ERR(attach)) {
+		DRM_ERROR("attach fail, return\n");
+		dma_buf_put(dma_buf);
+		goto err_gem_free;
+	}
+
+	sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+	if (IS_ERR(sgt)) {
+		DRM_ERROR("map failed, detach and return\n");
+		dma_buf_detach(dma_buf, attach);
+		dma_buf_put(dma_buf);
+		goto err_gem_free;
+	}
+	obj->import_attach = attach;
+	mtk_gem->dma_addr = sg_dma_address(sgt->sgl);
+	mtk_gem->sg = sgt;
+	mtk_gem->size = dma_buf->size;
+
+	if (!strcmp(heap, "mtk_svp") || !strcmp(heap, "mtk_svp_cma")) {
+		/* secure buffer can not be mapped */
+		mtk_gem->secure = true;
+	} else {
+		ret = dma_buf_vmap(dma_buf, &map);
+		mtk_gem->kvaddr = map.vaddr;
+		if (ret) {
+			DRM_ERROR("map failed, ret=%d\n", ret);
+			dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+			dma_buf_detach(dma_buf, attach);
+			dma_buf_put(dma_buf);
+			mtk_gem->kvaddr = NULL;
+		}
+	}
+
+	return mtk_gem;
+
+err_gem_free:
+	drm_gem_object_release(obj);
+	kfree(mtk_gem);
+	return ERR_PTR(-ENOMEM);
+}
+
 struct mtk_drm_gem_obj *mtk_drm_gem_create(struct drm_device *dev,
 					   size_t size, bool alloc_kmap)
 {
@@ -225,7 +302,9 @@ struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev,
 	if (IS_ERR(mtk_gem))
 		return ERR_CAST(mtk_gem);
 
+	mtk_gem->secure = !sg_page(sg->sgl);
 	mtk_gem->dma_addr = sg_dma_address(sg->sgl);
+	mtk_gem->size = attach->dmabuf->size;
 	mtk_gem->sg = sg;
 
 	return &mtk_gem->base;
@@ -301,7 +380,11 @@ int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
 	struct drm_mtk_gem_create *args = data;
 	int ret;
 
-	mtk_gem = mtk_drm_gem_create(dev, args->size, false);
+	if (args->flags & DRM_MTK_GEM_CREATE_ENCRYPTED)
+		mtk_gem = mtk_drm_gem_create_from_heap(dev, "mtk_svp_cma", args->size);
+	else
+		mtk_gem = mtk_drm_gem_create(dev, args->size, false);
+
 	if (IS_ERR(mtk_gem))
 		return PTR_ERR(mtk_gem);
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.h b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
index 90f3d2916ec5..8fd5ce827d4f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
@@ -27,9 +27,11 @@ struct mtk_drm_gem_obj {
 	void			*cookie;
 	void			*kvaddr;
 	dma_addr_t		dma_addr;
+	size_t			size;
 	unsigned long		dma_attrs;
 	struct sg_table		*sg;
 	struct page		**pages;
+	bool			secure;
 };
 
 #define to_mtk_gem_obj(x)	container_of(x, struct mtk_drm_gem_obj, base)
@@ -37,6 +39,8 @@ struct mtk_drm_gem_obj {
 void mtk_drm_gem_free_object(struct drm_gem_object *gem);
 struct mtk_drm_gem_obj *mtk_drm_gem_create(struct drm_device *dev, size_t size,
 					   bool alloc_kmap);
+struct mtk_drm_gem_obj *mtk_drm_gem_create_from_heap(struct drm_device *dev,
+						     const char *heap, size_t size);
 int mtk_drm_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
 			    struct drm_mode_create_dumb *args);
 struct sg_table *mtk_gem_prime_get_sg_table(struct drm_gem_object *obj);
-- 
2.18.0



From krzysztof.kozlowski at linaro.org  Sat Dec 23 10:40:28 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 19:40:28 +0100
Subject: [PATCH v5 04/16] dt-bindings: imx6q-pcie: Add linux,pci-domain as
 required for iMX8MQ
In-Reply-To: <20231220213615.1561528-5-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-5-Frank.Li@nxp.com>
Message-ID: <f6d9a333-3259-4dc6-bdc7-23ffa26e590b@linaro.org>

On 20/12/2023 22:36, Frank Li wrote:
> iMX8MQ have two pci controllers. Adds "linux,pci-domain" as required
> proptery for iMX8MQ to indicate pci controller index.


Why it has to be required? Everything will work fine if skipped.
Otherwise please provide reason why it must be *required*.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sat Dec 23 10:42:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 19:42:12 +0100
Subject: [PATCH v5 09/16] dt-bindings: imx6q-pcie: Clean up irrationality
 clocks check
In-Reply-To: <20231220213615.1561528-10-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-10-Frank.Li@nxp.com>
Message-ID: <9efe017d-e887-4239-a4ca-ff8ffeb08aec@linaro.org>

On 20/12/2023 22:36, Frank Li wrote:
> There are clocks and clock-names restriction for difference compatible
> string. So needn't irrationality check again for clock's miniItems and
> maxItems.

That's not really true. Other entry does not restrict clocks and leave
items quite flexible. These entries should be combined so all
constraints are fixed for all variants.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sat Dec 23 10:43:01 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 19:43:01 +0100
Subject: [PATCH v5 10/16] dt-bindings: imx6q-pcie: remove reg and reg-name
In-Reply-To: <ZYZYFYBr23OtTtrd@lizhi-Precision-Tower-5810>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-11-Frank.Li@nxp.com>
 <20231221225033.GA228866-robh@kernel.org>
 <ZYZYFYBr23OtTtrd@lizhi-Precision-Tower-5810>
Message-ID: <524646e6-17d4-4a72-be96-74347be36482@linaro.org>

On 23/12/2023 04:46, Frank Li wrote:
> On Thu, Dec 21, 2023 at 04:50:33PM -0600, Rob Herring wrote:
>> On Wed, Dec 20, 2023 at 04:36:09PM -0500, Frank Li wrote:
>>> snps,dw-pcie.yaml already have reg and reg-name information. Needn't
>>> duplciate here.
>>>
>>> Acked-by: Rob Herring <robh at kernel.org>
>>> Signed-off-by: Frank Li <Frank.Li at nxp.com>
>>> ---
>>>
>>> Notes:
>>>     Change from v4 to v5
>>>     - add Rob's Acked
>>
>> Err, that was intended for patch 9, not this one. This patch should be 
>> dropped.
> 
> Sorry, will correct it.
> 
> Actually I want to move it under Allof
> 
> if compatiable string (A, B, C...)
> then
> 	reg-names:
> 		-const: dbi
> 		-const: config
> 
> Differece SOC have difference reg-names required list. If split it, it
> will be easy when add new SOC. Needn't change two place.
> 
> Let me update at next version.
> 

This patch should be dropped. Why do you remove entries from top-level?
Are they defined in other schema?

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sat Dec 23 10:44:30 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 19:44:30 +0100
Subject: [PATCH v5 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint
 compatible string
In-Reply-To: <20231220213615.1561528-16-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-16-Frank.Li@nxp.com>
Message-ID: <8fb359da-2d35-4cea-8a62-199fde1d9a29@linaro.org>

On 20/12/2023 22:36, Frank Li wrote:
> Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
> Add reg-name: "atu", "dbi2", "dma" and "serdes".
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> 
> Notes:
>     Change from v1 to v3
>     - new patches at v3
> 
>  .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 52 ++++++++++++++++---
>  1 file changed, 44 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> index ee155ed5f1811..be9ea77ce8548 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> @@ -22,14 +22,7 @@ properties:
>        - fsl,imx8mm-pcie-ep
>        - fsl,imx8mq-pcie-ep
>        - fsl,imx8mp-pcie-ep
> -
> -  reg:
> -    minItems: 2
> -
> -  reg-names:
> -    items:
> -      - const: dbi
> -      - const: addr_space

No, why? Entries should be defined top-level. If you remove them here,
where are they defined (in which schema)?


> +  - if:
> +      properties:
> +        compatible:
> +          enum:
> +            - fsl,imx95-pcie-ep
> +    then:
> +      properties:
> +        linux,pci-domain: true

Why? It is allowed already.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sat Dec 23 11:19:02 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 23 Dec 2023 20:19:02 +0100
Subject: [PATCH] pinctrl: samsung: constify iomem pointers
Message-ID: <20231223191902.22857-1-krzysztof.kozlowski@linaro.org>

Constify few pointers to iomem, where the destination memory is not
modified, for code safety and readability.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 4 ++--
 drivers/pinctrl/samsung/pinctrl-samsung.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d3d4b5d036c8..871c1eb46ddf 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -693,7 +693,7 @@ static void exynos_pinctrl_suspend_bank(
 				struct samsung_pin_bank *bank)
 {
 	struct exynos_eint_gpio_save *save = bank->soc_priv;
-	void __iomem *regs = bank->eint_base;
+	const void __iomem *regs = bank->eint_base;
 
 	save->eint_con = readl(regs + EXYNOS_GPIO_ECON_OFFSET
 						+ bank->eint_offset);
@@ -714,7 +714,7 @@ static void exynosauto_pinctrl_suspend_bank(struct samsung_pinctrl_drv_data *drv
 					    struct samsung_pin_bank *bank)
 {
 	struct exynos_eint_gpio_save *save = bank->soc_priv;
-	void __iomem *regs = bank->eint_base;
+	const void __iomem *regs = bank->eint_base;
 
 	save->eint_con = readl(regs + bank->pctl_offset + bank->eint_con_offset);
 	save->eint_mask = readl(regs + bank->pctl_offset + bank->eint_mask_offset);
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index dbf38767f15f..ed07e23e0912 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -565,7 +565,7 @@ static void samsung_gpio_set(struct gpio_chip *gc, unsigned offset, int value)
 /* gpiolib gpio_get callback function */
 static int samsung_gpio_get(struct gpio_chip *gc, unsigned offset)
 {
-	void __iomem *reg;
+	const void __iomem *reg;
 	u32 data;
 	struct samsung_pin_bank *bank = gpiochip_get_data(gc);
 	const struct samsung_pin_bank_type *type = bank->type;
@@ -1204,7 +1204,7 @@ static int __maybe_unused samsung_pinctrl_suspend(struct device *dev)
 
 	for (i = 0; i < drvdata->nr_banks; i++) {
 		struct samsung_pin_bank *bank = &drvdata->pin_banks[i];
-		void __iomem *reg = bank->pctl_base + bank->pctl_offset;
+		const void __iomem *reg = bank->pctl_base + bank->pctl_offset;
 		const u8 *offs = bank->type->reg_offset;
 		const u8 *widths = bank->type->fld_width;
 		enum pincfg_type type;
-- 
2.34.1



From othacehe at gnu.org  Sat Dec 23 12:52:29 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Sat, 23 Dec 2023 21:52:29 +0100
Subject: [PATCH v2 1/2] dt-bindings: arm: fsl: Add VAR-SOM-MX93 with Symphony
In-Reply-To: <20231223205230.10534-1-othacehe@gnu.org>
References: <20231223205230.10534-1-othacehe@gnu.org>
Message-ID: <20231223205230.10534-2-othacehe@gnu.org>

Add support for Variscite i.MX93 VAR-SOM-MX93 SoM with Symphony board.

Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
 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 228dcc5c7d6f..27936edfe054 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1275,6 +1275,12 @@ properties:
           - const: tq,imx93-tqma9352        # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM
           - const: fsl,imx93
 
+      - description: Variscite VAR-SOM-MX93 based boards
+        items:
+          - const: variscite,var-som-mx93-symphony
+          - const: variscite,var-som-mx93
+          - const: fsl,imx93
+
       - description:
           Freescale Vybrid Platform Device Tree Bindings
 
-- 
2.41.0



From othacehe at gnu.org  Sat Dec 23 12:52:28 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Sat, 23 Dec 2023 21:52:28 +0100
Subject: [PATCH v2 0/2] Add Variscite VAR-SOM-MX93 support
Message-ID: <20231223205230.10534-1-othacehe@gnu.org>

Hey,

This is a v2 adding support for the Variscite VAR-SOM-MX93 SoM on Symphony
Board.

Support for "nxp,pca9451a" is not mainlined yet, it has been proposed here:
https://lore.kernel.org/lkml/20230531065724.3671795-1-joy.zou at nxp.com/T/

I removed it from the device-tree for now.

Thanks,

Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
Changes in v2:
- Remove "nxp,pca9451a" block
- Fixed checkpatch warnings
- Fixed dtb_checks warnings
- Introduce dt-bindings documentation

v1: https://lore.kernel.org/linux-devicetree/3ad14d62-df64-45b1-9be4-008d30d2b52f at linaro.org/T/#t

---
Mathieu Othacehe (2):
  dt-bindings: arm: fsl: Add VAR-SOM-MX93 with Symphony
  arm64: dts: imx93-var-som: Add Variscite VAR-SOM-MX93

 .../devicetree/bindings/arm/fsl.yaml          |   6 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-var-som-symphony.dts  | 306 ++++++++++++++++++
 .../boot/dts/freescale/imx93-var-som.dtsi     | 209 ++++++++++++
 4 files changed, 522 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som.dtsi

-- 
2.41.0



From othacehe at gnu.org  Sat Dec 23 12:52:30 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Sat, 23 Dec 2023 21:52:30 +0100
Subject: [PATCH v2 2/2] arm64: dts: imx93-var-som: Add Variscite VAR-SOM-MX93
In-Reply-To: <20231223205230.10534-1-othacehe@gnu.org>
References: <20231223205230.10534-1-othacehe@gnu.org>
Message-ID: <20231223205230.10534-3-othacehe@gnu.org>

Add DTSI for Variscite VAR-SOM-MX93 System on Module and DTS for Variscite
VAR-SOM-MX93 on Symphony evaluation board.

This version comes with:
- NXP i.MX 93 Dual, 1.7GHz, Cortex-A55 + Cortex-M33
- 2 GB of RAM
- 16GB eMMC
- 802.11ax/ac/a/b/g/n WiFi with 5.3 Bluetooth
- CAN bus
- Audio codec

Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-var-som-symphony.dts  | 306 ++++++++++++++++++
 .../boot/dts/freescale/imx93-var-som.dtsi     | 209 ++++++++++++
 3 files changed, 516 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2e027675d7bb..a6f1700961e3 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -203,6 +203,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxca.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
 
 imx8mm-venice-gw72xx-0x-imx219-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-imx219.dtbo
 imx8mm-venice-gw72xx-0x-rpidsi-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rpidsi.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
new file mode 100644
index 000000000000..ab675739e3ba
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 NXP
+ * Copyright 2023 Variscite Ltd.
+ */
+
+/dts-v1/;
+
+#include "imx93-var-som.dtsi"
+
+/{
+	model = "Variscite VAR-SOM-MX93 on Symphony evaluation board";
+	compatible = "variscite,var-som-mx93-symphony",
+	"variscite,var-som-mx93", "fsl,imx93";
+
+	aliases {
+		ethernet1 = &fec;
+	};
+
+	chosen {
+		stdout-path = &lpuart1;
+	};
+
+	/*
+	 * Needed only for Symphony <= v1.5
+	 */
+	reg_fec_phy: regulator-fec-phy {
+		compatible = "regulator-fixed";
+		regulator-name = "fec-phy";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-enable-ramp-delay = <20000>;
+		gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	reg_usdhc2_vmmc: regulator-usdhc2 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+		regulator-name = "VSD_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+		off-on-delay-us = <20000>;
+		enable-active-high;
+	};
+
+	reg_vref_1v8: regulator-adc-vref {
+		compatible = "regulator-fixed";
+		regulator-name = "vref_1v8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		ethosu_mem: ethosu-region at 88000000 {
+			compatible = "shared-dma-pool";
+			reusable;
+			reg = <0x0 0x88000000 0x0 0x8000000>;
+		};
+
+		vdev0vring0: vdev0vring0 at 87ee0000 {
+			reg = <0 0x87ee0000 0 0x8000>;
+			no-map;
+		};
+
+		vdev0vring1: vdev0vring1 at 87ee8000 {
+			reg = <0 0x87ee8000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring0: vdev1vring0 at 87ef0000 {
+			reg = <0 0x87ef0000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring1: vdev1vring1 at 87ef8000 {
+			reg = <0 0x87ef8000 0 0x8000>;
+			no-map;
+		};
+
+		rsc_table: rsc-table at 2021f000 {
+			reg = <0 0x2021f000 0 0x1000>;
+			no-map;
+		};
+
+		vdevbuffer: vdevbuffer at 87f00000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x87f00000 0 0x100000>;
+			no-map;
+		};
+
+		ele_reserved: ele-reserved at 87de0000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x87de0000 0 0x100000>;
+			no-map;
+		};
+	};
+};
+
+/* Use external instead of internal RTC*/
+&bbnsm_rtc {
+	status = "disabled";
+};
+
+&eqos {
+	mdio {
+		ethphy1: ethernet-phy at 5 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <5>;
+			qca,disable-smarteee;
+			eee-broken-1000t;
+			reset-gpios = <&pca9534 5 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <20000>;
+			vddio-supply = <&vddio1>;
+
+			vddio1: vddio-regulator {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+			};
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy1>;
+	phy-supply = <&reg_fec_phy>;
+	status = "okay";
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_fec: fecgrp {
+		fsl,pins = <
+			MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0		0x57e
+			MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1		0x57e
+			MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2		0x57e
+			MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3		0x57e
+			MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC		0x5fe
+			MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL	0x57e
+			MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0		0x57e
+			MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1		0x57e
+			MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2		0x57e
+			MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3		0x57e
+			MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC		0x5fe
+			MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL	0x57e
+		>;
+	};
+
+	pinctrl_flexcan1: flexcan1grp {
+		fsl,pins = <
+			MX93_PAD_PDM_CLK__CAN1_TX                       0x139e
+			MX93_PAD_PDM_BIT_STREAM0__CAN1_RX               0x139e
+		>;
+	};
+
+	pinctrl_lpi2c1: lpi2c1grp {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__LPI2C1_SCL			0x40000b9e
+			MX93_PAD_I2C1_SDA__LPI2C1_SDA			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c1_gpio: lpi2c1gpiogrp {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__GPIO1_IO00			0x31e
+			MX93_PAD_I2C1_SDA__GPIO1_IO01			0x31e
+		>;
+	};
+
+	pinctrl_lpi2c5: lpi2c5grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO23__LPI2C5_SCL			0x40000b9e
+			MX93_PAD_GPIO_IO22__LPI2C5_SDA			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c5_gpio: lpi2c5gpiogrp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO23__GPIO2_IO23			0x31e
+			MX93_PAD_GPIO_IO22__GPIO2_IO22			0x31e
+		>;
+	};
+
+	pinctrl_pca9534: pca9534grp {
+		fsl,pins = <
+			MX93_PAD_CCM_CLKO1__GPIO3_IO26		0x31e
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX93_PAD_UART1_RXD__LPUART1_RX			0x31e
+			MX93_PAD_UART1_TXD__LPUART1_TX			0x31e
+		>;
+	};
+
+	pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO18__GPIO2_IO18		0x31e
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX93_PAD_SD2_CLK__USDHC2_CLK		0x15fe
+			MX93_PAD_SD2_CMD__USDHC2_CMD		0x13fe
+			MX93_PAD_SD2_DATA0__USDHC2_DATA0	0x13fe
+			MX93_PAD_SD2_DATA1__USDHC2_DATA1	0x13fe
+			MX93_PAD_SD2_DATA2__USDHC2_DATA2	0x13fe
+			MX93_PAD_SD2_DATA3__USDHC2_DATA3	0x13fe
+			MX93_PAD_SD2_VSELECT__USDHC2_VSELECT	0x51e
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+		fsl,pins = <
+			MX93_PAD_SD2_CD_B__GPIO3_IO00		0x31e
+		>;
+	};
+};
+
+&lpi2c1 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c1>;
+	pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
+	pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
+	scl-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	/* DS1337 RTC module */
+	rtc at 68 {
+		compatible = "dallas,ds1337";
+		reg = <0x68>;
+	};
+};
+
+&lpi2c5 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c5>;
+	pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+	pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
+	scl-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	pca9534: gpio at 20 {
+		compatible = "nxp,pca9534";
+		reg = <0x20>;
+		gpio-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9534>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+		#gpio-cells = <2>;
+		wakeup-source;
+	};
+};
+
+/* Console */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
+	vmmc-supply = <&reg_usdhc2_vmmc>;
+	bus-width = <4>;
+	status = "okay";
+	no-sdio;
+	no-mmc;
+};
+
+/* Watchdog */
+&wdog3 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
new file mode 100644
index 000000000000..42c627e98379
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 NXP
+ * Copyright 2023 Variscite Ltd.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx93.dtsi"
+
+/{
+	model = "Variscite VAR-SOM-MX93 module";
+	compatible = "variscite,var-som-mx93", "fsl,imx93";
+
+	mmc_pwrseq: mmc-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		post-power-on-delay-ms = <100>;
+		power-off-delay-us = <10000>;
+		reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>,	/* WIFI_RESET */
+			      <&gpio3 7 GPIO_ACTIVE_LOW>;	/* WIFI_PWR_EN */
+	};
+
+	reg_eqos_phy: regulator-eqos-phy {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_eqos_phy>;
+		regulator-name = "eth_phy_pwr";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		startup-delay-us = <100000>;
+		regulator-always-on;
+	};
+};
+
+&eqos {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_eqos>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+	phy-supply = <&reg_eqos_phy>;
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clock-frequency = <1000000>;
+
+		ethphy0: ethernet-phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
+			eee-broken-1000t;
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl_bt: btgrp {
+		fsl,pins = <
+			MX93_PAD_ENET2_MDIO__GPIO4_IO15				0x51e
+		>;
+	};
+
+	pinctrl_eqos: eqosgrp {
+		fsl,pins = <
+			MX93_PAD_ENET1_MDC__ENET_QOS_MDC			0x57e
+			MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO			0x57e
+			MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0			0x57e
+			MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1			0x57e
+			MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2			0x57e
+			MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3			0x57e
+			MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK	0x5fe
+			MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL		0x57e
+			MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0			0x57e
+			MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1			0x57e
+			MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2			0x57e
+			MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3			0x57e
+			MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK	0x5fe
+			MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL		0x57e
+		>;
+	};
+
+	pinctrl_lpi2c3: lpi2c3grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO28__LPI2C3_SDA			0x40000b9e
+			MX93_PAD_GPIO_IO29__LPI2C3_SCL			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c3_gpio: lpi2c3gpiogrp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO28__GPIO2_IO28			0x40000b9e
+			MX93_PAD_GPIO_IO29__GPIO2_IO29			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpspi8: lpspi8grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO12__GPIO2_IO12			0x31e
+			MX93_PAD_GPIO_IO13__LPSPI8_SIN			0x31e
+			MX93_PAD_GPIO_IO14__LPSPI8_SOUT			0x31e
+			MX93_PAD_GPIO_IO15__LPSPI8_SCK			0x31e
+		>;
+	};
+
+	pinctrl_reg_eqos_phy: regeqosgrp {
+		fsl,pins = <
+			MX93_PAD_UART2_TXD__GPIO1_IO07			0x51e
+		>;
+	};
+
+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			MX93_PAD_ENET2_MDC__GPIO4_IO14			0x51e /* WIFI_REG_ON     */
+			MX93_PAD_SD2_RESET_B__GPIO3_IO07		0x51e /* WIFI_PWR_EN     */
+		>;
+	};
+
+	pinctrl_restouch: restouchgrp {
+		fsl,pins = <
+			MX93_PAD_CCM_CLKO4__GPIO4_IO29			0x31e
+		>;
+	};
+
+	pinctrl_sai1: sai1grp {
+		fsl,pins = <
+			MX93_PAD_SAI1_TXC__SAI1_TX_BCLK			0x31e
+			MX93_PAD_SAI1_TXFS__SAI1_TX_SYNC		0x31e
+			MX93_PAD_SAI1_TXD0__SAI1_TX_DATA00		0x31e
+			MX93_PAD_SAI1_RXD0__SAI1_RX_DATA00		0x31e
+			MX93_PAD_I2C2_SDA__SAI1_RX_BCLK			0x31e
+			MX93_PAD_I2C2_SCL__SAI1_RX_SYNC			0x31e
+			MX93_PAD_UART2_RXD__SAI1_MCLK			0x31e
+		>;
+	};
+
+	pinctrl_sai1_sleep: sai1-sleep-grp {
+		fsl,pins = <
+			MX93_PAD_SAI1_TXC__GPIO1_IO12		0x31e
+			MX93_PAD_SAI1_TXFS__GPIO1_IO11		0x31e
+			MX93_PAD_SAI1_TXD0__GPIO1_IO13		0x31e
+			MX93_PAD_SAI1_RXD0__GPIO1_IO14		0x31e
+			MX93_PAD_UART2_RXD__GPIO1_IO06		0x31e
+			MX93_PAD_I2C2_SDA__GPIO1_IO03		0x31e
+			MX93_PAD_I2C2_SCL__GPIO1_IO02		0x31e
+		>;
+	};
+
+	pinctrl_uart5: uart5grp {
+		fsl,pins = <
+			MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX	0x31e
+			MX93_PAD_DAP_TDI__LPUART5_RX		0x31e
+			MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B	0x31e
+			MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B	0x31e
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX93_PAD_SD1_CLK__USDHC1_CLK		0x15fe
+			MX93_PAD_SD1_CMD__USDHC1_CMD		0x13fe
+			MX93_PAD_SD1_DATA0__USDHC1_DATA0	0x13fe
+			MX93_PAD_SD1_DATA1__USDHC1_DATA1	0x13fe
+			MX93_PAD_SD1_DATA2__USDHC1_DATA2	0x13fe
+			MX93_PAD_SD1_DATA3__USDHC1_DATA3	0x13fe
+			MX93_PAD_SD1_DATA4__USDHC1_DATA4	0x13fe
+			MX93_PAD_SD1_DATA5__USDHC1_DATA5	0x13fe
+			MX93_PAD_SD1_DATA6__USDHC1_DATA6	0x13fe
+			MX93_PAD_SD1_DATA7__USDHC1_DATA7	0x13fe
+			MX93_PAD_SD1_STROBE__USDHC1_STROBE	0x15fe
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX93_PAD_SD3_CLK__USDHC3_CLK		0x1382
+			MX93_PAD_SD3_CMD__USDHC3_CMD		0x1382
+			MX93_PAD_SD3_DATA0__USDHC3_DATA0	0x1382
+			MX93_PAD_SD3_DATA1__USDHC3_DATA1	0x1382
+			MX93_PAD_SD3_DATA2__USDHC3_DATA2	0x1382
+			MX93_PAD_SD3_DATA3__USDHC3_DATA3	0x1382
+		>;
+	};
+
+	pinctrl_usdhc3_sleep: usdhc3gpiogrp {
+		fsl,pins = <
+			MX93_PAD_SD3_CLK__GPIO3_IO20		0x400
+			MX93_PAD_SD3_CMD__GPIO3_IO21		0x400
+			MX93_PAD_SD3_DATA0__GPIO3_IO22		0x400
+			MX93_PAD_SD3_DATA1__GPIO3_IO23		0x400
+			MX93_PAD_SD3_DATA2__GPIO3_IO24		0x400
+			MX93_PAD_SD3_DATA3__GPIO3_IO25		0x400
+		>;
+	};
+};
+
+/* eMMC */
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1>;
+	pinctrl-2 = <&pinctrl_usdhc1>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
-- 
2.41.0



From josua at solid-run.com  Sat Dec 23 13:29:26 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 23 Dec 2023 22:29:26 +0100
Subject: [PATCH 1/5] arm: dts: marvell: clearfog-gtr: add board-specific compatible strings
In-Reply-To: <20231223212930.14624-1-josua@solid-run.com>
References: <20231223212930.14624-1-josua@solid-run.com>
Message-ID: <20231223212930.14624-2-josua@solid-run.com>

Most arm board have a board-specific compatible string that allows e.g.
userspace to match specific firmware variants or apply specific
policies.

Add board-specific properties to both variants of the Clearfog GTR:
- solidrun,clearfog-gtr-l8
- solidrun,clearfog-gtr-s4

Introduction of a common parent (e.g. "solidrun,clearfog-gtr") is
omitted for brevity.
Since announcement of the two products no additional variants were added
it is assumed that there will always be just two.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 1 +
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index 1990f7d0cc79..ae921a674c93 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -4,6 +4,7 @@
 
 / {
 	model = "SolidRun Clearfog GTR L8";
+	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385", "marvell,armada380";
 };
 
 &mdio {
diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
index b795ad573891..8c96695ca990 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
@@ -4,6 +4,7 @@
 
 / {
 	model = "SolidRun Clearfog GTR S4";
+	compatible = "solidrun,clearfog-gtr-s4", "marvell,armada385", "marvell,armada380";
 };
 
 &sfp0 {
-- 
2.35.3



From josua at solid-run.com  Sat Dec 23 13:29:25 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 23 Dec 2023 22:29:25 +0100
Subject: [PATCH 0/5] arm: dts: marvell: clearfog-gtr: miscellaneous enhancements
Message-ID: <20231223212930.14624-1-josua@solid-run.com>

Dear Maintainers,

The initially merged device-tree for Clearfog GTR devices contained
various subtle mistakes and omissions:

- missing pinctrl entries
- off-by-1 errors on gpio numbers
- mismatch of labels between dsa ports and enclosure
- invalid sfp loss-of-signal gpio
- missing second sfp connector

Most notably this had caused functional issues with the mini-pci-e
connectors and sfp module insertions were not detected.

This patch set includes corrections for all gpio references where appropriate,
matching board revision 1.1.

The secondary sfp connector is added to board-variant "L8", connected to the
managed ethernet switch port number 9.

To help support OpenWRT board-specific configurations, new compatible strings
are added to both boards.
Documentation has not been added because marvell armada-388 dt-bindings
are not yet converted to yaml, and document not a single board:
Documentation/devicetree/bindings/arm/marvell/armada-38x.txt

Finally labels of dsa switch ports were updated to match the enclosure.
That patch is not suitable for stable.

Josua Mayer (5):
  arm: dts: marvell: clearfog-gtr: add board-specific compatible strings
  arm: dts: marvell: clearfog-gtr: sort pinctrl nodes alphabetically
  arm: dts: marvell: clearfog-gtr: fix various off-by-1 gpio numbers
  arm: dts: marvell: clearfog-gtr-l8: add support for second sfp
    connector
  arm: dts: marvell: clearfog-gtr-l8: align port numbers with enclosure

 .../marvell/armada-385-clearfog-gtr-l8.dts    |  35 ++++--
 .../marvell/armada-385-clearfog-gtr-s4.dts    |   1 +
 .../dts/marvell/armada-385-clearfog-gtr.dtsi  | 103 ++++++++++++------
 3 files changed, 99 insertions(+), 40 deletions(-)

Cc: Andrew Lunn <andrew at lunn.ch> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
Cc: Gregory Clement <gregory.clement at bootlin.com> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
Cc: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
Cc: Rob Herring <robh+dt at kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: Conor Dooley <conor+dt at kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)

-- 
2.35.3



From josua at solid-run.com  Sat Dec 23 13:29:28 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 23 Dec 2023 22:29:28 +0100
Subject: [PATCH 3/5] arm: dts: marvell: clearfog-gtr: fix various off-by-1 gpio numbers
In-Reply-To: <20231223212930.14624-1-josua@solid-run.com>
References: <20231223212930.14624-1-josua@solid-run.com>
Message-ID: <20231223212930.14624-4-josua@solid-run.com>

Various control signals such as sfp module-absence, pci-e reset or led
gpios had off-by-1 mistakes where calculation from mpp number to gpio
index in bank 1 was incorrect.

Fix all such mistakes, and add explicit pinctrl entries for those gpios
where missing.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../dts/marvell/armada-385-clearfog-gtr.dtsi  | 61 ++++++++++++++-----
 1 file changed, 47 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index 8eabb60765b0..d43bab0fe884 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -162,6 +162,22 @@ cf_gtr_isolation_pins: cf-gtr-isolation-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_led_pins: led-pins {
+					marvell,pins = "mpp42", "mpp52";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_lte_disable_pins: lte-disable-pins {
+					marvell,pins = "mpp34";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_pci_pins: pci-pins {
+					// pci reset
+					marvell,pins = "mpp33", "mpp35";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_poe_reset_pins: cf-gtr-poe-reset-pins {
 					marvell,pins = "mpp48";
 					marvell,function = "gpio";
@@ -179,6 +195,12 @@ cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
 					marvell,function = "sd0";
 				};
 
+				cf_gtr_sfp0_pins: sfp0-pins {
+					/* sfp modabs, txdisable */
+					marvell,pins = "mpp25", "mpp46";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
@@ -193,6 +215,11 @@ cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
 					marvell,pins = "mpp22";
 					marvell,function = "gpio";
 				};
+
+				cf_gtr_wifi_disable_pins: wifi-disable-pins {
+					marvell,pins = "mpp30", "mpp31";
+					marvell,function = "gpio";
+				};
 			};
 
 			sdhci at d8000 {
@@ -221,34 +248,38 @@ usb3 at f8000 {
 		};
 
 		pcie {
+			pinctrl-0 = <&cf_gtr_pci_pins>;
+			pinctrl-names = "default";
 			status = "okay";
 			/*
 			 * The PCIe units are accessible through
 			 * the mini-PCIe connectors on the board.
 			 */
 			pcie at 1,0 {
-				reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
+				reset-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
 				status = "okay";
 			};
 
 			pcie at 2,0 {
-				reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+				reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
 				status = "okay";
 			};
 
 			pcie at 3,0 {
-				reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
+				reset-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
 				status = "okay";
 			};
 		};
 	};
 
+	/* CON5 */
 	sfp0: sfp {
 		compatible = "sff,sfp";
+		pinctrl-0 = <&cf_gtr_sfp0_pins>;
+		pinctrl-names = "default";
 		i2c-bus = <&i2c1>;
-		los-gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
 		mod-def0-gpio = <&gpio0 25 GPIO_ACTIVE_LOW>;
-		tx-disable-gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
+		tx-disable-gpio = <&gpio1 15 GPIO_ACTIVE_HIGH>;
 	};
 
 	gpio-keys {
@@ -258,14 +289,14 @@ gpio-keys {
 
 		button-0 {
 			label = "Rear Button";
-			gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;
 			linux,can-disable;
 			linux,code = <BTN_0>;
 		};
 
 		button-1 {
 			label = "Front Button";
-			gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
 			linux,can-disable;
 			linux,code = <BTN_1>;
 		};
@@ -273,17 +304,19 @@ button-1 {
 
 	gpio-leds {
 		compatible = "gpio-leds";
+		pinctrl-0 = <&cf_gtr_led_pins>;
+		pinctrl-names = "default";
 
 		led1 {
 			function = LED_FUNCTION_CPU;
 			color = <LED_COLOR_ID_GREEN>;
-			gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
 		};
 
 		led2 {
 			function = LED_FUNCTION_HEARTBEAT;
 			color = <LED_COLOR_ID_GREEN>;
-			gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
+			gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
 		};
 	};
 };
@@ -408,7 +441,7 @@ &ahci1 {
 };
 
 &gpio0 {
-	pinctrl-0 = <&cf_gtr_fan_pwm>;
+	pinctrl-0 = <&cf_gtr_fan_pwm &cf_gtr_wifi_disable_pins>;
 	pinctrl-names = "default";
 
 	wifi-disable {
@@ -420,12 +453,12 @@ wifi-disable {
 };
 
 &gpio1 {
-	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins>;
+	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins &cf_gtr_lte_disable_pins>;
 	pinctrl-names = "default";
 
 	lte-disable {
 		gpio-hog;
-		gpios = <2 GPIO_ACTIVE_LOW>;
+		gpios = <3 GPIO_ACTIVE_LOW>;
 		output-low;
 		line-name = "lte-disable";
 	};
@@ -436,14 +469,14 @@ lte-disable {
 	 */
 	sar-isolation {
 		gpio-hog;
-		gpios = <15 GPIO_ACTIVE_LOW>;
+		gpios = <16 GPIO_ACTIVE_LOW>;
 		output-low;
 		line-name = "sar-isolation";
 	};
 
 	poe-reset {
 		gpio-hog;
-		gpios = <16 GPIO_ACTIVE_LOW>;
+		gpios = <17 GPIO_ACTIVE_LOW>;
 		output-low;
 		line-name = "poe-reset";
 	};
-- 
2.35.3



From josua at solid-run.com  Sat Dec 23 13:29:27 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 23 Dec 2023 22:29:27 +0100
Subject: [PATCH 2/5] arm: dts: marvell: clearfog-gtr: sort pinctrl nodes alphabetically
In-Reply-To: <20231223212930.14624-1-josua@solid-run.com>
References: <20231223212930.14624-1-josua@solid-run.com>
Message-ID: <20231223212930.14624-3-josua@solid-run.com>

Cosmetic change to increase future patches readability when adding new
pinctrl nodes.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../dts/marvell/armada-385-clearfog-gtr.dtsi  | 40 +++++++++----------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index d1452a04e904..8eabb60765b0 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -141,18 +141,13 @@ i2c at 11100 { /* SFP (CON5/CON6) */
 			};
 
 			pinctrl at 18000 {
-				cf_gtr_switch_reset_pins: cf-gtr-switch-reset-pins {
-					marvell,pins = "mpp18";
-					marvell,function = "gpio";
-				};
-
-				cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
-					marvell,pins = "mpp22";
+				cf_gtr_fan_pwm: cf-gtr-fan-pwm {
+					marvell,pins = "mpp23";
 					marvell,function = "gpio";
 				};
 
-				cf_gtr_fan_pwm: cf-gtr-fan-pwm {
-					marvell,pins = "mpp23";
+				cf_gtr_front_button_pins: cf-gtr-front-button-pins {
+					marvell,pins = "mpp53";
 					marvell,function = "gpio";
 				};
 
@@ -162,13 +157,6 @@ cf_gtr_i2c1_pins: i2c1-pins {
 					marvell,function = "i2c1";
 				};
 
-				cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
-					marvell,pins = "mpp21", "mpp28",
-						       "mpp37", "mpp38",
-						       "mpp39", "mpp40";
-					marvell,function = "sd0";
-				};
-
 				cf_gtr_isolation_pins: cf-gtr-isolation-pins {
 					marvell,pins = "mpp47";
 					marvell,function = "gpio";
@@ -179,18 +167,30 @@ cf_gtr_poe_reset_pins: cf-gtr-poe-reset-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_rear_button_pins: cf-gtr-rear-button-pins {
+					marvell,pins = "mpp36";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
+					marvell,pins = "mpp21", "mpp28",
+						       "mpp37", "mpp38",
+						       "mpp39", "mpp40";
+					marvell,function = "sd0";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
 				};
 
-				cf_gtr_front_button_pins: cf-gtr-front-button-pins {
-					marvell,pins = "mpp53";
+				cf_gtr_switch_reset_pins: cf-gtr-switch-reset-pins {
+					marvell,pins = "mpp18";
 					marvell,function = "gpio";
 				};
 
-				cf_gtr_rear_button_pins: cf-gtr-rear-button-pins {
-					marvell,pins = "mpp36";
+				cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
+					marvell,pins = "mpp22";
 					marvell,function = "gpio";
 				};
 			};
-- 
2.35.3



From josua at solid-run.com  Sat Dec 23 13:29:29 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 23 Dec 2023 22:29:29 +0100
Subject: [PATCH 4/5] arm: dts: marvell: clearfog-gtr-l8: add support for second sfp connector
In-Reply-To: <20231223212930.14624-1-josua@solid-run.com>
References: <20231223212930.14624-1-josua@solid-run.com>
Message-ID: <20231223212930.14624-5-josua@solid-run.com>

Clearfog GTR L8 has an extra SFP connector on the managed switch port 9.
Add descriptions for both entities along with pinctrl.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../dts/marvell/armada-385-clearfog-gtr-l8.dts | 18 ++++++++++++++++++
 .../dts/marvell/armada-385-clearfog-gtr.dtsi   |  8 +++++++-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index ae921a674c93..bb2142907023 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -5,6 +5,16 @@
 / {
 	model = "SolidRun Clearfog GTR L8";
 	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385", "marvell,armada380";
+
+	/* CON25 */
+	sfp1: sfp-1 {
+		compatible = "sff,sfp";
+		pinctrl-0 = <&cf_gtr_sfp1_pins>;
+		pinctrl-names = "default";
+		i2c-bus = <&i2c0>;
+		mod-def0-gpio = <&gpio0 24 GPIO_ACTIVE_LOW>;
+		tx-disable-gpio = <&gpio1 23 GPIO_ACTIVE_HIGH>;
+	};
 };
 
 &mdio {
@@ -67,6 +77,14 @@ port at 8 {
 				phy-handle = <&switch0phy7>;
 			};
 
+			port at 9 {
+				reg = <9>;
+				label = "lan-sfp";
+				phy-mode = "sgmii";
+				sfp = <&sfp1>;
+				managed = "in-band-status";
+			};
+
 			port at 10 {
 				reg = <10>;
 				phy-mode = "2500base-x";
diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index d43bab0fe884..a70085fb38dd 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -201,6 +201,12 @@ cf_gtr_sfp0_pins: sfp0-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_sfp1_pins: sfp1-pins {
+					/* sfp modabs, txdisable */
+					marvell,pins = "mpp24", "mpp54";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
@@ -273,7 +279,7 @@ pcie at 3,0 {
 	};
 
 	/* CON5 */
-	sfp0: sfp {
+	sfp0: sfp-0 {
 		compatible = "sff,sfp";
 		pinctrl-0 = <&cf_gtr_sfp0_pins>;
 		pinctrl-names = "default";
-- 
2.35.3



From josua at solid-run.com  Sat Dec 23 13:29:30 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 23 Dec 2023 22:29:30 +0100
Subject: [PATCH 5/5] arm: dts: marvell: clearfog-gtr-l8: align port numbers with enclosure
In-Reply-To: <20231223212930.14624-1-josua@solid-run.com>
References: <20231223212930.14624-1-josua@solid-run.com>
Message-ID: <20231223212930.14624-6-josua@solid-run.com>

Clearfog GTR has an official enclosure with labels for all interfaces.
The "lan" ports on the 8-port switch in device-tree were numbered  in
reverse wrt. enclosure.

Update all device-tree labels to match.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../dts/marvell/armada-385-clearfog-gtr-l8.dts   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index bb2142907023..44303e79c489 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -31,49 +31,49 @@ ports {
 
 			port at 1 {
 				reg = <1>;
-				label = "lan8";
+				label = "lan1";
 				phy-handle = <&switch0phy0>;
 			};
 
 			port at 2 {
 				reg = <2>;
-				label = "lan7";
+				label = "lan2";
 				phy-handle = <&switch0phy1>;
 			};
 
 			port at 3 {
 				reg = <3>;
-				label = "lan6";
+				label = "lan3";
 				phy-handle = <&switch0phy2>;
 			};
 
 			port at 4 {
 				reg = <4>;
-				label = "lan5";
+				label = "lan4";
 				phy-handle = <&switch0phy3>;
 			};
 
 			port at 5 {
 				reg = <5>;
-				label = "lan4";
+				label = "lan5";
 				phy-handle = <&switch0phy4>;
 			};
 
 			port at 6 {
 				reg = <6>;
-				label = "lan3";
+				label = "lan6";
 				phy-handle = <&switch0phy5>;
 			};
 
 			port at 7 {
 				reg = <7>;
-				label = "lan2";
+				label = "lan7";
 				phy-handle = <&switch0phy6>;
 			};
 
 			port at 8 {
 				reg = <8>;
-				label = "lan1";
+				label = "lan8";
 				phy-handle = <&switch0phy7>;
 			};
 
-- 
2.35.3



From andreas at kemnade.info  Sat Dec 23 14:12:11 2023
From: andreas at kemnade.info (Andreas Kemnade)
Date: Sat, 23 Dec 2023 23:12:11 +0100
Subject: [PATCH v3 2/4] dt-bindings: touchscreen: neonode,zforce: Use standard properties
In-Reply-To: <20231223221213.774868-1-andreas@kemnade.info>
References: <20231223221213.774868-1-andreas@kemnade.info>
Message-ID: <20231223221213.774868-3-andreas@kemnade.info>

Enable touchscreen orientation to be specified by using standard
properties.

Signed-off-by: Andreas Kemnade <andreas at kemnade.info>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/input/touchscreen/neonode,zforce.yaml  | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
index c39662815a6c5..c2ee89b76ea13 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
@@ -9,6 +9,9 @@ title: Neonode infrared touchscreen controller
 maintainers:
   - Heiko Stuebner <heiko at sntech.de>
 
+allOf:
+  - $ref: touchscreen.yaml#
+
 properties:
   compatible:
     const: neonode,zforce
@@ -26,9 +29,11 @@ properties:
     maxItems: 1
 
   x-size:
+    deprecated: true
     $ref: /schemas/types.yaml#/definitions/uint32
 
   y-size:
+    deprecated: true
     $ref: /schemas/types.yaml#/definitions/uint32
 
   vdd-supply: true
@@ -38,8 +43,6 @@ required:
   - reg
   - interrupts
   - reset-gpios
-  - x-size
-  - y-size
 
 unevaluatedProperties: false
 
@@ -60,8 +63,10 @@ examples:
             reset-gpios = <&gpio5 9 0>; /* RST */
             irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
 
-            x-size = <800>;
-            y-size = <600>;
+            touchscreen-min-x = <0>;
+            touchscreen-size-x = <800>;
+            touchscreen-min-y = <0>;
+            touchscreen-size-y = <600>;
         };
     };
 ...
-- 
2.39.2



From andreas at kemnade.info  Sat Dec 23 14:12:12 2023
From: andreas at kemnade.info (Andreas Kemnade)
Date: Sat, 23 Dec 2023 23:12:12 +0100
Subject: [PATCH v3 3/4] Input: zforce_ts: Accept standard touchscreen properties
In-Reply-To: <20231223221213.774868-1-andreas@kemnade.info>
References: <20231223221213.774868-1-andreas@kemnade.info>
Message-ID: <20231223221213.774868-4-andreas@kemnade.info>

Only driver-specific properties were accepted, change it
to use the now-available standard properties.

Signed-off-by: Andreas Kemnade <andreas at kemnade.info>
---
 drivers/input/touchscreen/zforce_ts.c | 36 +++++++++++++--------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/input/touchscreen/zforce_ts.c b/drivers/input/touchscreen/zforce_ts.c
index 5be5112845e1e..f4397497bbe94 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -20,6 +20,7 @@
 #include <linux/device.h>
 #include <linux/sysfs.h>
 #include <linux/input/mt.h>
+#include <linux/input/touchscreen.h>
 #include <linux/platform_data/zforce_ts.h>
 #include <linux/regulator/consumer.h>
 #include <linux/of.h>
@@ -106,6 +107,7 @@ struct zforce_point {
 struct zforce_ts {
 	struct i2c_client	*client;
 	struct input_dev	*input;
+	struct touchscreen_properties prop;
 	const struct zforce_ts_platdata *pdata;
 	char			phys[32];
 
@@ -266,7 +268,6 @@ static int zforce_setconfig(struct zforce_ts *ts, char b1)
 static int zforce_start(struct zforce_ts *ts)
 {
 	struct i2c_client *client = ts->client;
-	const struct zforce_ts_platdata *pdata = ts->pdata;
 	int ret;
 
 	dev_dbg(&client->dev, "starting device\n");
@@ -277,7 +278,7 @@ static int zforce_start(struct zforce_ts *ts)
 		return ret;
 	}
 
-	ret = zforce_resolution(ts, pdata->x_max, pdata->y_max);
+	ret = zforce_resolution(ts, ts->prop.max_x, ts->prop.max_y);
 	if (ret) {
 		dev_err(&client->dev, "Unable to set resolution, %d\n", ret);
 		goto error;
@@ -337,7 +338,6 @@ static int zforce_stop(struct zforce_ts *ts)
 static int zforce_touch_event(struct zforce_ts *ts, u8 *payload)
 {
 	struct i2c_client *client = ts->client;
-	const struct zforce_ts_platdata *pdata = ts->pdata;
 	struct zforce_point point;
 	int count, i, num = 0;
 
@@ -355,8 +355,8 @@ static int zforce_touch_event(struct zforce_ts *ts, u8 *payload)
 		point.coord_y =
 			payload[9 * i + 4] << 8 | payload[9 * i + 3];
 
-		if (point.coord_x > pdata->x_max ||
-		    point.coord_y > pdata->y_max) {
+		if (point.coord_x > ts->prop.max_x ||
+		    point.coord_y > ts->prop.max_y) {
 			dev_warn(&client->dev, "coordinates (%d,%d) invalid\n",
 				point.coord_x, point.coord_y);
 			point.coord_x = point.coord_y = 0;
@@ -390,10 +390,11 @@ static int zforce_touch_event(struct zforce_ts *ts, u8 *payload)
 						point.state != STATE_UP);
 
 		if (point.state != STATE_UP) {
-			input_report_abs(ts->input, ABS_MT_POSITION_X,
-					 point.coord_x);
-			input_report_abs(ts->input, ABS_MT_POSITION_Y,
-					 point.coord_y);
+			touchscreen_report_pos(ts->input,
+					       &ts->prop,
+					       point.coord_x,
+					       point.coord_y,
+					       true);
 			input_report_abs(ts->input, ABS_MT_TOUCH_MAJOR,
 					 point.area_major);
 			input_report_abs(ts->input, ABS_MT_TOUCH_MINOR,
@@ -719,15 +720,8 @@ static struct zforce_ts_platdata *zforce_parse_dt(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 	}
 
-	if (of_property_read_u32(np, "x-size", &pdata->x_max)) {
-		dev_err(dev, "failed to get x-size property\n");
-		return ERR_PTR(-EINVAL);
-	}
-
-	if (of_property_read_u32(np, "y-size", &pdata->y_max)) {
-		dev_err(dev, "failed to get y-size property\n");
-		return ERR_PTR(-EINVAL);
-	}
+	of_property_read_u32(np, "x-size", &pdata->x_max);
+	of_property_read_u32(np, "y-size", &pdata->y_max);
 
 	return pdata;
 }
@@ -856,6 +850,12 @@ static int zforce_probe(struct i2c_client *client)
 	input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0,
 			     pdata->y_max, 0, 0);
 
+	touchscreen_parse_properties(input_dev, true, &ts->prop);
+	if (ts->prop.max_x == 0 || ts->prop.max_y == 0) {
+		dev_err(&client->dev, "no size specified\n");
+		return -EINVAL;
+	}
+
 	input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0,
 			     ZFORCE_MAX_AREA, 0, 0);
 	input_set_abs_params(input_dev, ABS_MT_TOUCH_MINOR, 0,
-- 
2.39.2



From andreas at kemnade.info  Sat Dec 23 14:12:13 2023
From: andreas at kemnade.info (Andreas Kemnade)
Date: Sat, 23 Dec 2023 23:12:13 +0100
Subject: [PATCH v3 4/4] ARM: dts: imx6sl-tolino-shine2hd: fix touchscreen rotation
In-Reply-To: <20231223221213.774868-1-andreas@kemnade.info>
References: <20231223221213.774868-1-andreas@kemnade.info>
Message-ID: <20231223221213.774868-5-andreas@kemnade.info>

The display is in landscape orientation, but the touchscreen is in portrait
orientation. Specify that properly in the devicetree.

Signed-off-by: Andreas Kemnade <andreas at kemnade.info>
---
 arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts b/arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts
index 815119c12bd48..5636fb3661e8a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts
@@ -141,8 +141,10 @@ zforce: touchscreen at 50 {
 		interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
 		vdd-supply = <&ldo1_reg>;
 		reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
-		x-size = <1072>;
-		y-size = <1448>;
+		touchscreen-size-x = <1072>;
+		touchscreen-size-y = <1448>;
+		touchscreen-swapped-x-y;
+		touchscreen-inverted-x;
 	};
 
 	/* TODO: TPS65185 PMIC for E Ink at 0x68 */
-- 
2.39.2



From andreas at kemnade.info  Sat Dec 23 14:12:09 2023
From: andreas at kemnade.info (Andreas Kemnade)
Date: Sat, 23 Dec 2023 23:12:09 +0100
Subject: [PATCH v3 0/4] Input: zforce_ts: standard properties
Message-ID: <20231223221213.774868-1-andreas@kemnade.info>

Accept standard touchscreen properties to also enable specification
of touchscreen orientation.

Changes in V3:
- adding R-bys, no change in code

Changes in V2:
- correct mail address in .yaml

Andreas Kemnade (4):
  dt-bindings: touchscreen: convert neonode,zforce to json-schema
  dt-bindings: touchscreen: neonode,zforce: Use standard properties
  Input: zforce_ts: Accept standard touchscreen properties
  ARM: dts: imx6sl-tolino-shine2hd: fix touchscreen rotation

 .../input/touchscreen/neonode,zforce.yaml     | 72 +++++++++++++++++++
 .../bindings/input/touchscreen/zforce_ts.txt  | 34 ---------
 .../dts/nxp/imx/imx6sl-tolino-shine2hd.dts    |  6 +-
 drivers/input/touchscreen/zforce_ts.c         | 36 +++++-----
 4 files changed, 94 insertions(+), 54 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
 delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt

-- 
2.39.2



From andreas at kemnade.info  Sat Dec 23 14:12:10 2023
From: andreas at kemnade.info (Andreas Kemnade)
Date: Sat, 23 Dec 2023 23:12:10 +0100
Subject: [PATCH v3 1/4] dt-bindings: touchscreen: convert neonode,zforce to json-schema
In-Reply-To: <20231223221213.774868-1-andreas@kemnade.info>
References: <20231223221213.774868-1-andreas@kemnade.info>
Message-ID: <20231223221213.774868-2-andreas@kemnade.info>

Convert Neonode infrared touchscreen controller binding to DT schema.

Signed-off-by: Andreas Kemnade <andreas at kemnade.info>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../input/touchscreen/neonode,zforce.yaml     | 67 +++++++++++++++++++
 .../bindings/input/touchscreen/zforce_ts.txt  | 34 ----------
 2 files changed, 67 insertions(+), 34 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
 delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
new file mode 100644
index 0000000000000..c39662815a6c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/neonode,zforce.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Neonode infrared touchscreen controller
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    const: neonode,zforce
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  reset-gpios:
+    maxItems: 1
+
+  irq-gpios:
+    maxItems: 1
+
+  x-size:
+    $ref: /schemas/types.yaml#/definitions/uint32
+
+  y-size:
+    $ref: /schemas/types.yaml#/definitions/uint32
+
+  vdd-supply: true
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - reset-gpios
+  - x-size
+  - y-size
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        touchscreen at 50 {
+            compatible = "neonode,zforce";
+            reg = <0x50>;
+            interrupts = <2 0>;
+            vdd-supply = <&reg_zforce_vdd>;
+
+            reset-gpios = <&gpio5 9 0>; /* RST */
+            irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
+
+            x-size = <800>;
+            y-size = <600>;
+        };
+    };
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
deleted file mode 100644
index e3c27c4fd9c85..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-* Neonode infrared touchscreen controller
-
-Required properties:
-- compatible: must be "neonode,zforce"
-- reg: I2C address of the chip
-- interrupts: interrupt to which the chip is connected
-- reset-gpios: reset gpio the chip is connected to
-- x-size: horizontal resolution of touchscreen
-- y-size: vertical resolution of touchscreen
-
-Optional properties:
-- irq-gpios : interrupt gpio the chip is connected to
-- vdd-supply: Regulator controlling the controller supply
-
-Example:
-
-	i2c at 00000000 {
-		/* ... */
-
-		zforce_ts at 50 {
-			compatible = "neonode,zforce";
-			reg = <0x50>;
-			interrupts = <2 0>;
-			vdd-supply = <&reg_zforce_vdd>;
-
-			reset-gpios = <&gpio5 9 0>; /* RST */
-			irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
-
-			x-size = <800>;
-			y-size = <600>;
-		};
-
-		/* ... */
-	};
-- 
2.39.2



From graf at amazon.com  Sat Dec 23 15:20:17 2023
From: graf at amazon.com (Alexander Graf)
Date: Sun, 24 Dec 2023 00:20:17 +0100
Subject: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO
In-Reply-To: <39a33f9b-0290-428d-ab1f-f90856cdb31d@kernel.org>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
 <20231222195144.24532-12-graf@amazon.com>
 <39a33f9b-0290-428d-ab1f-f90856cdb31d@kernel.org>
Message-ID: <34e78a84-a29d-4b01-a860-cac3959f6cb6@amazon.com>

Hi Krzysztof!

Thanks a lot for the fast review!

On 23.12.23 15:30, Krzysztof Kozlowski wrote:
> On 22/12/2023 20:51, Alexander Graf wrote:
>> With ftrace in KHO, we are creating an ABI between old kernel and new
>> kernel about the state that they transfer. To ensure that we document
>> that state and catch any breaking change, let's add its schema to the
>> common devicetree bindings. This way, we can quickly reason about the
>> state that gets passed.
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC (and consider --no-git-fallback argument). It might
> happen, that command when run on an older kernel, gives you outdated
> entries. Therefore please be sure you base your patches on recent Linux
> kernel.


Ah, this is about directly CC'ing maintainers? I was slightly picky on 
CCs since the CC list is already a bit long for this patch set, so I 
limited the CC list to mailing lists and people that I know were 
directly interested. Happy to CC you next time.


>
> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching.
>
> A nit, subject: drop second/last, redundant "bindings". The
> "dt-bindings" prefix is already stating that these are bindings.


Happy to fix up for v3 :)


>
>> Signed-off-by: Alexander Graf <graf at amazon.com>
>> ---
>>   .../bindings/kho/ftrace/ftrace-array.yaml     | 46 +++++++++++++++
>>   .../bindings/kho/ftrace/ftrace-cpu.yaml       | 56 +++++++++++++++++++
>>   .../bindings/kho/ftrace/ftrace.yaml           | 48 ++++++++++++++++
>>   3 files changed, 150 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
>>   create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
>>   create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
>> new file mode 100644
>> index 000000000000..9960fefc292d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
>> @@ -0,0 +1,46 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-array.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Ftrace trace array
>> +
> Missing description. Commit msg also does not tell me much. This must
> stand on its own and must describe the hardware. Whatever you have in
> cover letter, does not matter, especially that you did not Cc us on it.


Alrighty, I'll add descriptions and make the commit message stand on its 
own.

For quick reference: KHO is a new mechanism this patch set introduces 
which allows Linux to pass arbitrary memory and metadata between kernels 
on kexec. I'm reusing FDTs to implement the hand over protocol, as 
Linux-to-Linux boot communication holds very similar properties to 
firmware-to-Linux boot communication. So this binding is not about 
hardware; it's about preserving Linux subsystem state across kexec.

For more details, please refer to the KHO documentation which is part of 
patch 7 of this patch set: 
https://lore.kernel.org/lkml/20231222195144.24532-2-graf at amazon.com/


>
>> +maintainers:
>> +  - Alexander Graf <graf at amazon.com>
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - ftrace,array-v1
>> +
>> +  trace_flags:
> Underscores are not allowed. Does not look like generic property.


Let me make it "trace-flags" to not have underscores. Could you please 
elaborate on what you mean by generic property?


>
>
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      Bitmap of all the trace flags that were enabled in the trace array at the
>> +      point of serialization.
>> +
>> +# Subnodes will be of type "ftrace,cpu-v1", one each per CPU
>> +additionalProperties: true
> No, this must be false. And it goes after required:


Ok, making it false and adding pattern matches instead for subnodes.


>
>
>> +
>> +required:
>> +  - compatible
>> +  - trace_flags
>> +
>> +examples:
>> +  - |
>> +    ftrace {
>> +        compatible = "ftrace-v1";
>> +        events = <1 1 2 2 3 3>;
>> +
>> +        global_trace {
> Again, no underscores.


Ok :)


>
>> +          compatible = "ftrace,array-v1";
>> +          trace_flags = < 0x3354601 >;
>> +
>> +          cpu0 {
>> +            compatible = "ftrace,cpu-v1";
>> +            cpu = < 0x00 >;
> Drop redundant spaces.


I don't understand what you're referring to as redundant spaces? Double 
checking, I believe indentation is off for every line below "ftrace {". 
Is that what you're referring to? Fixing :)


>
>> +            mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> ? Do you see any of such syntax in DTS?


I was trying to make it easy to reason to readers about 64bit numbers - 
and then potentially extend dtc to consume that new syntax. KHO DTs are 
native/little endian, so dtc already has some difficulties interpreting 
it which I'll need to fix up with patches to it eventually :). I'll 
change it to something that looks more 32bit'y for now.


Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From semen.protsenko at linaro.org  Sat Dec 23 18:00:46 2023
From: semen.protsenko at linaro.org (Sam Protsenko)
Date: Sat, 23 Dec 2023 20:00:46 -0600
Subject: [PATCH] pinctrl: samsung: constify iomem pointers
In-Reply-To: <20231223191902.22857-1-krzysztof.kozlowski@linaro.org>
References: <20231223191902.22857-1-krzysztof.kozlowski@linaro.org>
Message-ID: <CAPLW+4na0s6D_BOYBCuT70FtMGSmhi2bApHxOd1H0CoJRqz9Kw@mail.gmail.com>

On Sat, Dec 23, 2023 at 1:19?PM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
>
> Constify few pointers to iomem, where the destination memory is not
> modified, for code safety and readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>

>  drivers/pinctrl/samsung/pinctrl-exynos.c  | 4 ++--
>  drivers/pinctrl/samsung/pinctrl-samsung.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index d3d4b5d036c8..871c1eb46ddf 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -693,7 +693,7 @@ static void exynos_pinctrl_suspend_bank(
>                                 struct samsung_pin_bank *bank)
>  {
>         struct exynos_eint_gpio_save *save = bank->soc_priv;
> -       void __iomem *regs = bank->eint_base;
> +       const void __iomem *regs = bank->eint_base;
>
>         save->eint_con = readl(regs + EXYNOS_GPIO_ECON_OFFSET
>                                                 + bank->eint_offset);
> @@ -714,7 +714,7 @@ static void exynosauto_pinctrl_suspend_bank(struct samsung_pinctrl_drv_data *drv
>                                             struct samsung_pin_bank *bank)
>  {
>         struct exynos_eint_gpio_save *save = bank->soc_priv;
> -       void __iomem *regs = bank->eint_base;
> +       const void __iomem *regs = bank->eint_base;
>
>         save->eint_con = readl(regs + bank->pctl_offset + bank->eint_con_offset);
>         save->eint_mask = readl(regs + bank->pctl_offset + bank->eint_mask_offset);
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index dbf38767f15f..ed07e23e0912 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -565,7 +565,7 @@ static void samsung_gpio_set(struct gpio_chip *gc, unsigned offset, int value)
>  /* gpiolib gpio_get callback function */
>  static int samsung_gpio_get(struct gpio_chip *gc, unsigned offset)
>  {
> -       void __iomem *reg;
> +       const void __iomem *reg;
>         u32 data;
>         struct samsung_pin_bank *bank = gpiochip_get_data(gc);
>         const struct samsung_pin_bank_type *type = bank->type;
> @@ -1204,7 +1204,7 @@ static int __maybe_unused samsung_pinctrl_suspend(struct device *dev)
>
>         for (i = 0; i < drvdata->nr_banks; i++) {
>                 struct samsung_pin_bank *bank = &drvdata->pin_banks[i];
> -               void __iomem *reg = bank->pctl_base + bank->pctl_offset;
> +               const void __iomem *reg = bank->pctl_base + bank->pctl_offset;
>                 const u8 *offs = bank->type->reg_offset;
>                 const u8 *widths = bank->type->fld_width;
>                 enum pincfg_type type;
> --
> 2.34.1
>
>


From Frank.li at nxp.com  Sat Dec 23 20:29:17 2023
From: Frank.li at nxp.com (Frank Li)
Date: Sat, 23 Dec 2023 23:29:17 -0500
Subject: [PATCH v5 04/16] dt-bindings: imx6q-pcie: Add linux,pci-domain
 as required for iMX8MQ
In-Reply-To: <f6d9a333-3259-4dc6-bdc7-23ffa26e590b@linaro.org>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-5-Frank.Li@nxp.com>
 <f6d9a333-3259-4dc6-bdc7-23ffa26e590b@linaro.org>
Message-ID: <ZYeznY7gXM+zoQeB@lizhi-Precision-Tower-5810>

On Sat, Dec 23, 2023 at 07:40:28PM +0100, Krzysztof Kozlowski wrote:
> On 20/12/2023 22:36, Frank Li wrote:
> > iMX8MQ have two pci controllers. Adds "linux,pci-domain" as required
> > proptery for iMX8MQ to indicate pci controller index.
> 
> 
> Why it has to be required? Everything will work fine if skipped.
> Otherwise please provide reason why it must be *required*.

Next patch will use "linux,pci-domain" as PCI slot ID, instead compared
with hard code register address.

The below code will be removed.

-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;


when there are more than 2 controller, this compare logic will become
complex. 

So after next patch, "linux,pci-domain" will be required.

Frank

> 
> Best regards,
> Krzysztof
> 


From Frank.li at nxp.com  Sat Dec 23 20:34:03 2023
From: Frank.li at nxp.com (Frank Li)
Date: Sat, 23 Dec 2023 23:34:03 -0500
Subject: [PATCH v5 10/16] dt-bindings: imx6q-pcie: remove reg and reg-name
In-Reply-To: <524646e6-17d4-4a72-be96-74347be36482@linaro.org>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-11-Frank.Li@nxp.com>
 <20231221225033.GA228866-robh@kernel.org>
 <ZYZYFYBr23OtTtrd@lizhi-Precision-Tower-5810>
 <524646e6-17d4-4a72-be96-74347be36482@linaro.org>
Message-ID: <ZYe0u+DyPztkQ82t@lizhi-Precision-Tower-5810>

On Sat, Dec 23, 2023 at 07:43:01PM +0100, Krzysztof Kozlowski wrote:
> On 23/12/2023 04:46, Frank Li wrote:
> > On Thu, Dec 21, 2023 at 04:50:33PM -0600, Rob Herring wrote:
> >> On Wed, Dec 20, 2023 at 04:36:09PM -0500, Frank Li wrote:
> >>> snps,dw-pcie.yaml already have reg and reg-name information. Needn't
> >>> duplciate here.
> >>>
> >>> Acked-by: Rob Herring <robh at kernel.org>
> >>> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> >>> ---
> >>>
> >>> Notes:
> >>>     Change from v4 to v5
> >>>     - add Rob's Acked
> >>
> >> Err, that was intended for patch 9, not this one. This patch should be 
> >> dropped.
> > 
> > Sorry, will correct it.
> > 
> > Actually I want to move it under Allof
> > 
> > if compatiable string (A, B, C...)
> > then
> > 	reg-names:
> > 		-const: dbi
> > 		-const: config
> > 
> > Differece SOC have difference reg-names required list. If split it, it
> > will be easy when add new SOC. Needn't change two place.
> > 
> > Let me update at next version.
> > 
> 
> This patch should be dropped. Why do you remove entries from top-level?
> Are they defined in other schema?

pci/snps,dw-pcie.yaml already define it.

Frank

> 
> Best regards,
> Krzysztof
> 


From Frank.li at nxp.com  Sat Dec 23 20:43:19 2023
From: Frank.li at nxp.com (Frank Li)
Date: Sat, 23 Dec 2023 23:43:19 -0500
Subject: [PATCH v5 09/16] dt-bindings: imx6q-pcie: Clean up irrationality
 clocks check
In-Reply-To: <9efe017d-e887-4239-a4ca-ff8ffeb08aec@linaro.org>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-10-Frank.Li@nxp.com>
 <9efe017d-e887-4239-a4ca-ff8ffeb08aec@linaro.org>
Message-ID: <ZYe252yFqKDsyfke@lizhi-Precision-Tower-5810>

On Sat, Dec 23, 2023 at 07:42:12PM +0100, Krzysztof Kozlowski wrote:
> On 20/12/2023 22:36, Frank Li wrote:
> > There are clocks and clock-names restriction for difference compatible
> > string. So needn't irrationality check again for clock's miniItems and
> > maxItems.
> 
> That's not really true. Other entry does not restrict clocks and leave
> items quite flexible. These entries should be combined so all
> constraints are fixed for all variants.

There are 7 compatible string at pci/fsl,imx6q-pcie.yaml 

- fsl,imx6q-pcie                                                     
      - fsl,imx6sx-pcie                                                    
      - fsl,imx6qp-pcie                                                    
      - fsl,imx7d-pcie                                                     
      - fsl,imx8mq-pcie                                                    
      - fsl,imx8mm-pcie                                                    
      - fsl,imx8mp-pcie                                                    
      - fsl,imx95-pcie                                                     
                      
All 7 compatible string have check

 - if:                                                                    
      properties:                                                          
        compatible:                                                        
          enum:                                                            
            - fsl,imx6sx-pcie
...
- if:                                                                    
      properties:                                                          
        compatible:                                                        
          enum:                                                            
            - fsl,imx8mq-pcie

...
- if:                                                                    
      properties:                                                          
        compatible:                                                        
          enum:                                                            
            - fsl,imx6q-pcie                                               
            - fsl,imx6qp-pcie                                              
            - fsl,imx7d-pcie
...
  - if:                                                                    
      properties:                                                          
        compatible:                                                        
          enum:                                                            
            - fsl,imx8mm-pcie                                              
            - fsl,imx8mp-pcie
...

This check was not necessary at all. 

> 
> Best regards,
> Krzysztof
> 


From Frank.li at nxp.com  Sat Dec 23 20:47:14 2023
From: Frank.li at nxp.com (Frank Li)
Date: Sat, 23 Dec 2023 23:47:14 -0500
Subject: [PATCH v5 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie
 endpoint compatible string
In-Reply-To: <8fb359da-2d35-4cea-8a62-199fde1d9a29@linaro.org>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-16-Frank.Li@nxp.com>
 <8fb359da-2d35-4cea-8a62-199fde1d9a29@linaro.org>
Message-ID: <ZYe30jb7dxRxQ3hr@lizhi-Precision-Tower-5810>

On Sat, Dec 23, 2023 at 07:44:30PM +0100, Krzysztof Kozlowski wrote:
> On 20/12/2023 22:36, Frank Li wrote:
> > Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
> > Add reg-name: "atu", "dbi2", "dma" and "serdes".
> > 
> > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > ---
> > 
> > Notes:
> >     Change from v1 to v3
> >     - new patches at v3
> > 
> >  .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 52 ++++++++++++++++---
> >  1 file changed, 44 insertions(+), 8 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> > index ee155ed5f1811..be9ea77ce8548 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
> > @@ -22,14 +22,7 @@ properties:
> >        - fsl,imx8mm-pcie-ep
> >        - fsl,imx8mq-pcie-ep
> >        - fsl,imx8mp-pcie-ep
> > -
> > -  reg:
> > -    minItems: 2
> > -
> > -  reg-names:
> > -    items:
> > -      - const: dbi
> > -      - const: addr_space
> 
> No, why? Entries should be defined top-level. If you remove them here,
> where are they defined (in which schema)?

See: pci/snps,dw-pcie.yaml

> 
> 
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          enum:
> > +            - fsl,imx95-pcie-ep
> > +    then:
> > +      properties:
> > +        linux,pci-domain: true
> 
> Why? It is allowed already.

Sorry, I suppose it should be required. I will fix it.

> 
> 
> Best regards,
> Krzysztof
> 


From arinc.unal at arinc9.com  Sat Dec 23 23:37:12 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Sun, 24 Dec 2023 10:37:12 +0300
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal
 MDIO bus
In-Reply-To: <20231221151607.ujobhh4aet4obxdz@skbuf>
References: <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231221151607.ujobhh4aet4obxdz@skbuf>
Message-ID: <6600c6b1-2230-4963-940c-8b95a01750fd@arinc9.com>

On 21.12.2023 18:16, Vladimir Oltean wrote:
> On Wed, Dec 20, 2023 at 07:35:39PM +0200, Ar?n? ?NAL wrote:
>> From: David Bauer <mail at david-bauer.net>
>>
>> The MT753x switches provide a switch-internal MDIO bus for the embedded
>> PHYs.
>>
>> Register a OF sub-node on the switch OF-node for this internal MDIO bus.
>> This allows to configure the embedded PHYs using device-tree.
>>
>> Signed-off-by: David Bauer <mail at david-bauer.net>
>> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
>> Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
>> ---
> 
> Can you please not assign "bus" to ds->user_mii_bus unless there is no
> "mdio" OF node? We don't need ds->user_mii_bus populated when it is
> described in device tree.

Do you mean like this:

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 391c4dbdff42..d239462a4bd8 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2155,15 +2155,21 @@ mt7530_setup_mdio(struct mt7530_priv *priv)
  {
  	struct dsa_switch *ds = priv->ds;
  	struct device *dev = priv->dev;
+	struct device_node *np, *mnp;
  	struct mii_bus *bus;
  	static int idx;
  	int ret;
  
+	np = priv->dev->of_node;
+	mnp = of_get_child_by_name(np, "mdio");
+
  	bus = devm_mdiobus_alloc(dev);
  	if (!bus)
  		return -ENOMEM;
  
-	ds->user_mii_bus = bus;
+	if (mnp == NULL)
+		ds->user_mii_bus = bus;
+
  	bus->priv = priv;
  	bus->name = KBUILD_MODNAME "-mii";
  	snprintf(bus->id, MII_BUS_ID_SIZE, KBUILD_MODNAME "-%d", idx++);
@@ -2177,7 +2183,8 @@ mt7530_setup_mdio(struct mt7530_priv *priv)
  	if (priv->irq)
  		mt7530_setup_mdio_irq(priv);
  
-	ret = devm_mdiobus_register(dev, bus);
+	ret = devm_of_mdiobus_register(dev, bus, mnp);
+	of_node_put(mnp);
  	if (ret) {
  		dev_err(dev, "failed to register MDIO bus: %d\n", ret);
  		if (priv->irq)

If the MDIO bus of the switch is defined on the devicetree, the
(!ds->user_mii_bus && ds->ops->phy_read) check in dsa_switch_setup will be
true so the MDIO bus will be attempted to be registered again, resulting in
a kernel panic.

[    1.369012] mt7530-mdio mdio-bus:1f: MT7530 adapts as multi-chip module
[    1.391552] CPU 0 Unable to handle kernel paging request at virtual address 00000700, epc == 802eb948, ra == 802eb938
[    1.402205] Oops[#1]:
[    1.404481] CPU: 0 PID: 26 Comm: kworker/u5:1 Not tainted 6.7.0-rc6-next-20231222-00012-g9997041f4e67-dirty #281
[    1.414622] Hardware name: UniElec U7621-06 (16M flash)
[    1.419829] Workqueue: events_unbound deferred_probe_work_func
[    1.425664] $ 0   : 00000000 00000001 00000011 00000700
[    1.430895] $ 4   : 00000700 814d0000 00000000 00000000
[    1.436123] $ 8   : 00000001 00000011 00000011 81595a80
[    1.441353] $12   : 81595a80 81595ad8 81595a80 81595ad8
[    1.446585] $16   : 81589a80 00000000 82019000 81589600
[    1.451815] $20   : 807d4a88 8205a280 00000005 00000000
[    1.457045] $24   : 00000000 802efd60
[    1.462274] $28   : 81594000 81595c18 80760000 802eb938
[    1.467505] Hi    : 00000000
[    1.470371] Lo    : 00000000
[    1.473235] epc   : 802eb948 mt753x_setup+0x39c/0x3bc
[    1.478283] ra    : 802eb938 mt753x_setup+0x38c/0x3bc
[    1.483324] Status: 11000403	KERNEL EXL IE
[    1.487508] Cause : 4080000c (ExcCode 03)
[    1.491502] BadVA : 00000700
[    1.494367] PrId  : 0001992f (MIPS 1004Kc)
[    1.498446] Process kworker/u5:1 (pid: 26, threadinfo=(ptrval), task=(ptrval), tls=00000000)
[    1.506853] Stack : 7fffffff 00000000 8205a280 00000000 806a8ab8 81589a80 8205a280 81521f00
[    1.515224]         81521f08 8157dc00 806ba49c 8205a280 00000001 804c6374 81589e00 81589c80
[    1.523601]         806a5ed0 81589600 00000000 81595c9c 805cab30 806d0000 8069e96c 806b99cc
[    1.531971]         00000006 00000dc0 ffffffff 802bd188 81589600 802bd29c fffffff4 fffffff4
[    1.540341]         8205a480 807d339c 00000000 00000000 00000000 00000000 00000000 00000000
[    1.548707]         ...
[    1.551150] Call Trace:
[    1.553583] [<802eb948>] mt753x_setup+0x39c/0x3bc
[    1.558286] [<804c6374>] dsa_register_switch+0x924/0xcc4
[    1.563592] [<802ddad0>] mdio_probe+0x34/0x6c
[    1.567943] [<802b95d0>] really_probe+0x16c/0x2dc
[    1.572639] [<802b995c>] driver_probe_device+0x40/0xd0
[    1.577767] [<802b9a4c>] __device_attach_driver+0x60/0xe8
[    1.583154] [<802b7694>] bus_for_each_drv+0xc8/0xf4
[    1.588042] [<802b9d8c>] __device_attach+0xd8/0x14c
[    1.592912] [<802b831c>] bus_probe_device+0x48/0xd8
[    1.597788] [<802b8f5c>] deferred_probe_work_func+0xb4/0xcc
[    1.603348] [<8003ab1c>] process_scheduled_works+0x1dc/0x2b8
[    1.609015] [<8003b1b0>] worker_thread+0x2dc/0x330
[    1.613804] [<80041d4c>] kthread+0xf8/0x100
[    1.617996] [<80002a18>] ret_from_kernel_thread+0x14/0x1c
[    1.623385]
[    1.624869] Code: 8ea30030  00042080  00641821 <ac620000> 26310001  1636fff1  00003825  1000ff67  02803025
[    1.634638]
[    1.636435] ---[ end trace 0000000000000000 ]---

Ar?n?


From andyshrk at 163.com  Sat Dec 23 23:50:01 2023
From: andyshrk at 163.com (Andy Yan)
Date: Sun, 24 Dec 2023 15:50:01 +0800
Subject: [PATCH] arm64: boot: dts: rockchip: Fix led pinctrl of lubancat 1
Message-ID: <20231224075001.3032214-1-andyshrk@163.com>

According to the sch, the gpio control sys_led
is GPIO0_C5.

Fixes: 8d94da58de53 ("arm64: dts: rockchip: Add EmbedFire LubanCat 1")
Reported-by: zhangn1985 at outlook.com
Closes: https://lore.kernel.org/linux-rockchip/OS0P286MB06412D049D8BF7B063D41350CD95A at OS0P286MB0641.JPNP286.PROD.OUTLOOK.COM/T/#u
Signed-off-by: Andy Yan <andyshrk at 163.com>
---

 arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts b/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts
index 1c6d83b47cd2..6ecdf5d28339 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts
@@ -455,7 +455,7 @@ &pcie2x1 {
 &pinctrl {
 	leds {
 		sys_led_pin: sys-status-led-pin {
-			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>;
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
 	};
 
-- 
2.34.1



From dmitry.torokhov at gmail.com  Sun Dec 24 00:31:10 2023
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Sun, 24 Dec 2023 00:31:10 -0800
Subject: [PATCH v3 1/4] dt-bindings: touchscreen: convert neonode,zforce
 to json-schema
In-Reply-To: <20231223221213.774868-2-andreas@kemnade.info>
References: <20231223221213.774868-1-andreas@kemnade.info>
 <20231223221213.774868-2-andreas@kemnade.info>
Message-ID: <ZYfsTsS8G8SdhFTn@google.com>

On Sat, Dec 23, 2023 at 11:12:10PM +0100, Andreas Kemnade wrote:
> Convert Neonode infrared touchscreen controller binding to DT schema.
> 
> Signed-off-by: Andreas Kemnade <andreas at kemnade.info>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Applied, thank you.

-- 
Dmitry


From dmitry.torokhov at gmail.com  Sun Dec 24 00:31:19 2023
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Sun, 24 Dec 2023 00:31:19 -0800
Subject: [PATCH v3 2/4] dt-bindings: touchscreen: neonode,zforce: Use
 standard properties
In-Reply-To: <20231223221213.774868-3-andreas@kemnade.info>
References: <20231223221213.774868-1-andreas@kemnade.info>
 <20231223221213.774868-3-andreas@kemnade.info>
Message-ID: <ZYfsV_RQqLcee4mz@google.com>

On Sat, Dec 23, 2023 at 11:12:11PM +0100, Andreas Kemnade wrote:
> Enable touchscreen orientation to be specified by using standard
> properties.
> 
> Signed-off-by: Andreas Kemnade <andreas at kemnade.info>
> Reviewed-by: Rob Herring <robh at kernel.org>

Applied, thank you.

-- 
Dmitry


From dmitry.torokhov at gmail.com  Sun Dec 24 00:31:29 2023
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Sun, 24 Dec 2023 00:31:29 -0800
Subject: [PATCH v3 3/4] Input: zforce_ts: Accept standard touchscreen
 properties
In-Reply-To: <20231223221213.774868-4-andreas@kemnade.info>
References: <20231223221213.774868-1-andreas@kemnade.info>
 <20231223221213.774868-4-andreas@kemnade.info>
Message-ID: <ZYfsYW2527_nT9DA@google.com>

On Sat, Dec 23, 2023 at 11:12:12PM +0100, Andreas Kemnade wrote:
> Only driver-specific properties were accepted, change it
> to use the now-available standard properties.
> 
> Signed-off-by: Andreas Kemnade <andreas at kemnade.info>

Applied, thank you.

-- 
Dmitry


From leo.yan at linaro.org  Sun Dec 24 00:33:32 2023
From: leo.yan at linaro.org (Leo Yan)
Date: Sun, 24 Dec 2023 16:33:32 +0800
Subject: [PATCH 1/3] perf scripts python: arm-cs-trace-disasm.py: print
 dso base address
In-Reply-To: <6177beec-f140-44aa-b534-182cd4b0a988@linux.alibaba.com>
References: <20231214123304.34087-1-tianruidong@linux.alibaba.com>
 <20231214123304.34087-2-tianruidong@linux.alibaba.com>
 <912a39f4-025e-26a1-7786-091fa211f293@arm.com>
 <6177beec-f140-44aa-b534-182cd4b0a988@linux.alibaba.com>
Message-ID: <20231224083332.GB13521@leoy-huanghe.lan>

Hi Ruidong,

On Fri, Dec 22, 2023 at 03:29:18PM +0800, Ruidong Tian wrote:

[...]

> > Although it's also not that clear what this is useful for, given that
> > all the other output is relative too? Maybe you could add an example to
> > the commit message, even if it's just for debugging. Would an option
> > that turned _all_ the output into virtual addresses not be more useful?
>
> I want to use arm-cs-trace-disasm.py output associate with PMU and SPE data
> to explore more CPU performance info, all the PMU/SPE/Coresight informations
> generated by `perf report` and `perf script` include virtual address, so i
> want this script do the same thing.

I think James' suggestion is valid for replacing all offsets with
virtual addresses, in addition to introducing a new option.

Below change works well at my side. Hope this is helpful.

  diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py b/tools/perf/scripts/python/arm-cs-trace-disasm.py
  index de58991c78bb..6c94ff2287cd 100755
  --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py
  +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py
  @@ -36,7 +36,10 @@ option_list = [
                      help="Set path to objdump executable file"),
          make_option("-v", "--verbose", dest="verbose",
                      action="store_true", default=False,
  -                   help="Enable debugging log")
  +                   help="Enable debugging log"),
  +       make_option("-a", "--vaddr", dest="vaddr",
  +                   action="store_true", default=False,
  +                   help="Enable virtual address")
   ]
  
   parser = OptionParser(option_list=option_list)
  @@ -108,6 +111,14 @@ def print_disam(dso_fname, dso_start, start_addr, stop_addr):
                          m = disasm_re.search(line)
                          if m is None:
                                  continue
  +
  +               # Replace offset with virtual address
  +               if (options.vaddr == True):
  +                       offset = re.search(r"^\s*([0-9a-fA-F]+)", line).group()
  +                       if offset:
  +                               virt_addr = dso_start + int(offset, 16)
  +                               line = line.replace(offset.lstrip(), "0x%016x" % virt_addr)
  +
                  print("\t" + line)
  
   def print_sample(sample):

Thanks,
Leo


From dmitry.torokhov at gmail.com  Sun Dec 24 00:47:08 2023
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Sun, 24 Dec 2023 00:47:08 -0800
Subject: [PATCH v3 4/4] ARM: dts: imx6sl-tolino-shine2hd: fix touchscreen
 rotation
In-Reply-To: <20231223221213.774868-5-andreas@kemnade.info>
References: <20231223221213.774868-1-andreas@kemnade.info>
 <20231223221213.774868-5-andreas@kemnade.info>
Message-ID: <ZYfwDJYesTwnoun6@google.com>

On Sat, Dec 23, 2023 at 11:12:13PM +0100, Andreas Kemnade wrote:
> The display is in landscape orientation, but the touchscreen is in portrait
> orientation. Specify that properly in the devicetree.

This needs to be merged by the board maintainer.

> 
> Signed-off-by: Andreas Kemnade <andreas at kemnade.info>
> ---
>  arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts b/arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts
> index 815119c12bd48..5636fb3661e8a 100644
> --- a/arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts
> +++ b/arch/arm/boot/dts/nxp/imx/imx6sl-tolino-shine2hd.dts
> @@ -141,8 +141,10 @@ zforce: touchscreen at 50 {
>  		interrupts = <6 IRQ_TYPE_EDGE_FALLING>;

Could you please prepare a patch changing this to IRQ_TYPE_LEVEL_LOW to
match what the driver is actually doing?

>  		vdd-supply = <&ldo1_reg>;
>  		reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
> -		x-size = <1072>;
> -		y-size = <1448>;
> +		touchscreen-size-x = <1072>;
> +		touchscreen-size-y = <1448>;
> +		touchscreen-swapped-x-y;
> +		touchscreen-inverted-x;
>  	};
>  
>  	/* TODO: TPS65185 PMIC for E Ink at 0x68 */
> -- 
> 2.39.2
> 

Thanks.

-- 
Dmitry


From Markus.Elfring at web.de  Sun Dec 24 00:52:21 2023
From: Markus.Elfring at web.de (Markus Elfring)
Date: Sun, 24 Dec 2023 09:52:21 +0100
Subject: [PATCH] clk: stm32f4: One function call less in stm32f4_rcc_init()
 after error detection
Message-ID: <89708781-f34a-47af-8aab-025136507da0@web.de>

From: Markus Elfring <elfring at users.sourceforge.net>
Date: Sun, 24 Dec 2023 09:40:10 +0100

The kfree() function was called in one case by the
stm32f4_rcc_init() function during error handling
even if the passed variable contained a null pointer.
This issue was detected by using the Coccinelle software.

Thus use another label.

Signed-off-by: Markus Elfring <elfring at users.sourceforge.net>
---
 drivers/clk/clk-stm32f4.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 07c13ebe327d..c7690a1594eb 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -1714,7 +1714,7 @@ static void __init stm32f4_rcc_init(struct device_node *np)
 	clks = kmalloc_array(data->gates_num + stm32fx_end_primary_clk,
 			sizeof(*clks), GFP_KERNEL);
 	if (!clks)
-		goto fail;
+		goto unmap_io;

 	stm32f4_gate_map = data->gates_map;

@@ -1897,6 +1897,7 @@ static void __init stm32f4_rcc_init(struct device_node *np)
 	return;
 fail:
 	kfree(clks);
+unmap_io:
 	iounmap(base);
 }
 CLK_OF_DECLARE_DRIVER(stm32f42xx_rcc, "st,stm32f42xx-rcc", stm32f4_rcc_init);
--
2.43.0



From krzk at kernel.org  Sun Dec 24 00:58:57 2023
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 09:58:57 +0100
Subject: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO
In-Reply-To: <34e78a84-a29d-4b01-a860-cac3959f6cb6@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222195144.24532-1-graf@amazon.com>
 <20231222195144.24532-12-graf@amazon.com>
 <39a33f9b-0290-428d-ab1f-f90856cdb31d@kernel.org>
 <34e78a84-a29d-4b01-a860-cac3959f6cb6@amazon.com>
Message-ID: <b860528c-d6b9-4531-8522-acbadc154b15@kernel.org>

On 24/12/2023 00:20, Alexander Graf wrote:
>>> new file mode 100644
>>> index 000000000000..9960fefc292d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
>>> @@ -0,0 +1,46 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-array.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Ftrace trace array
>>> +
>> Missing description. Commit msg also does not tell me much. This must
>> stand on its own and must describe the hardware. Whatever you have in
>> cover letter, does not matter, especially that you did not Cc us on it.
> 
> 
> Alrighty, I'll add descriptions and make the commit message stand on its 
> own.
> 
> For quick reference: KHO is a new mechanism this patch set introduces 
> which allows Linux to pass arbitrary memory and metadata between kernels 
> on kexec. I'm reusing FDTs to implement the hand over protocol, as 
> Linux-to-Linux boot communication holds very similar properties to 
> firmware-to-Linux boot communication. So this binding is not about 
> hardware; it's about preserving Linux subsystem state across kexec.

Devicetree is for non-discoverable systems and their hardware, not for
passing arbitrary data between kernels. For me this does not suit DT at
all, please use other ways.


> 
> For more details, please refer to the KHO documentation which is part of 
> patch 7 of this patch set: 
> https://lore.kernel.org/lkml/20231222195144.24532-2-graf at amazon.com/
> 
> 
>>
>>> +maintainers:
>>> +  - Alexander Graf <graf at amazon.com>
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - ftrace,array-v1
>>> +
>>> +  trace_flags:
>> Underscores are not allowed. Does not look like generic property.
> 
> 
> Let me make it "trace-flags" to not have underscores. Could you please 
> elaborate on what you mean by generic property?

Generic property, so one without vendor prefix, is shared and common to
a group of devices.


> 
> 
>>
>>
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description:
>>> +      Bitmap of all the trace flags that were enabled in the trace array at the
>>> +      point of serialization.
>>> +
>>> +# Subnodes will be of type "ftrace,cpu-v1", one each per CPU
>>> +additionalProperties: true
>> No, this must be false. And it goes after required:
> 
> 
> Ok, making it false and adding pattern matches instead for subnodes.
> 
> 
>>
>>
>>> +
>>> +required:
>>> +  - compatible
>>> +  - trace_flags
>>> +
>>> +examples:
>>> +  - |
>>> +    ftrace {
>>> +        compatible = "ftrace-v1";
>>> +        events = <1 1 2 2 3 3>;
>>> +
>>> +        global_trace {
>> Again, no underscores.
> 
> 
> Ok :)
> 
> 
>>
>>> +          compatible = "ftrace,array-v1";
>>> +          trace_flags = < 0x3354601 >;
>>> +
>>> +          cpu0 {
>>> +            compatible = "ftrace,cpu-v1";
>>> +            cpu = < 0x00 >;
>> Drop redundant spaces.
> 
> 
> I don't understand what you're referring to as redundant spaces? Double 
> checking, I believe indentation is off for every line below "ftrace {". 
> Is that what you're referring to? Fixing :)

Open DTS, some recent, arm64 like Qualcomm. Do you see spaces around <>?
Or open the coding style document... Please do not introduce different
coding style.

> 
> 
>>
>>> +            mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
>> ? Do you see any of such syntax in DTS?
> 
> 
> I was trying to make it easy to reason to readers about 64bit numbers - 

64bit numbers are not a problem for DTS reading. Above syntax is.

> and then potentially extend dtc to consume that new syntax. KHO DTs are 
> native/little endian, so dtc already has some difficulties interpreting 
> it which I'll need to fix up with patches to it eventually :). I'll 
> change it to something that looks more 32bit'y for now.
> 


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 01:01:25 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 10:01:25 +0100
Subject: [PATCH] arm64: boot: dts: rockchip: Fix led pinctrl of lubancat 1
In-Reply-To: <20231224075001.3032214-1-andyshrk@163.com>
References: <20231224075001.3032214-1-andyshrk@163.com>
Message-ID: <38c959a4-4f08-4111-9c7b-36e47ab3790a@linaro.org>

On 24/12/2023 08:50, Andy Yan wrote:
> According to the sch, the gpio control sys_led
> is GPIO0_C5.

For the future:

Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.

There is no "boot".

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 01:02:28 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 10:02:28 +0100
Subject: [PATCH v5 04/16] dt-bindings: imx6q-pcie: Add linux,pci-domain as
 required for iMX8MQ
In-Reply-To: <ZYeznY7gXM+zoQeB@lizhi-Precision-Tower-5810>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-5-Frank.Li@nxp.com>
 <f6d9a333-3259-4dc6-bdc7-23ffa26e590b@linaro.org>
 <ZYeznY7gXM+zoQeB@lizhi-Precision-Tower-5810>
Message-ID: <cf231452-e1e6-44bd-bff4-c699d5f2a53a@linaro.org>

On 24/12/2023 05:29, Frank Li wrote:
> On Sat, Dec 23, 2023 at 07:40:28PM +0100, Krzysztof Kozlowski wrote:
>> On 20/12/2023 22:36, Frank Li wrote:
>>> iMX8MQ have two pci controllers. Adds "linux,pci-domain" as required
>>> proptery for iMX8MQ to indicate pci controller index.
>>
>>
>> Why it has to be required? Everything will work fine if skipped.
>> Otherwise please provide reason why it must be *required*.
> 
> Next patch will use "linux,pci-domain" as PCI slot ID, instead compared
> with hard code register address.
> 
> The below code will be removed.
> 
> -		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> -			imx6_pcie->controller_id = 1;
> 
> 
> when there are more than 2 controller, this compare logic will become
> complex. 
> 
> So after next patch, "linux,pci-domain" will be required.

Nothing in commit msg explains this. Why you cannot use some
auto-incremented values when this is missing?

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 01:04:34 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 10:04:34 +0100
Subject: [PATCH v5 09/16] dt-bindings: imx6q-pcie: Clean up irrationality
 clocks check
In-Reply-To: <ZYe252yFqKDsyfke@lizhi-Precision-Tower-5810>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-10-Frank.Li@nxp.com>
 <9efe017d-e887-4239-a4ca-ff8ffeb08aec@linaro.org>
 <ZYe252yFqKDsyfke@lizhi-Precision-Tower-5810>
Message-ID: <6bf94c6e-adfe-4931-9314-4f6b73f96981@linaro.org>

On 24/12/2023 05:43, Frank Li wrote:
> On Sat, Dec 23, 2023 at 07:42:12PM +0100, Krzysztof Kozlowski wrote:
>> On 20/12/2023 22:36, Frank Li wrote:
>>> There are clocks and clock-names restriction for difference compatible
>>> string. So needn't irrationality check again for clock's miniItems and
>>> maxItems.
>>
>> That's not really true. Other entry does not restrict clocks and leave
>> items quite flexible. These entries should be combined so all
>> constraints are fixed for all variants.
> 
> There are 7 compatible string at pci/fsl,imx6q-pcie.yaml 

Then explain it in the commit msg. The file you are touching has
something entirely else.

And what about -ep binding? Commit msg explains nothing here as well.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 01:06:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 10:06:53 +0100
Subject: [PATCH v5 10/16] dt-bindings: imx6q-pcie: remove reg and reg-name
In-Reply-To: <ZYe0u+DyPztkQ82t@lizhi-Precision-Tower-5810>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-11-Frank.Li@nxp.com>
 <20231221225033.GA228866-robh@kernel.org>
 <ZYZYFYBr23OtTtrd@lizhi-Precision-Tower-5810>
 <524646e6-17d4-4a72-be96-74347be36482@linaro.org>
 <ZYe0u+DyPztkQ82t@lizhi-Precision-Tower-5810>
Message-ID: <d48f4c72-623c-446d-b015-ea822fa2fedf@linaro.org>

On 24/12/2023 05:34, Frank Li wrote:
> On Sat, Dec 23, 2023 at 07:43:01PM +0100, Krzysztof Kozlowski wrote:
>> On 23/12/2023 04:46, Frank Li wrote:
>>> On Thu, Dec 21, 2023 at 04:50:33PM -0600, Rob Herring wrote:
>>>> On Wed, Dec 20, 2023 at 04:36:09PM -0500, Frank Li wrote:
>>>>> snps,dw-pcie.yaml already have reg and reg-name information. Needn't
>>>>> duplciate here.
>>>>>
>>>>> Acked-by: Rob Herring <robh at kernel.org>
>>>>> Signed-off-by: Frank Li <Frank.Li at nxp.com>
>>>>> ---
>>>>>
>>>>> Notes:
>>>>>     Change from v4 to v5
>>>>>     - add Rob's Acked
>>>>
>>>> Err, that was intended for patch 9, not this one. This patch should be 
>>>> dropped.
>>>
>>> Sorry, will correct it.
>>>
>>> Actually I want to move it under Allof
>>>
>>> if compatiable string (A, B, C...)
>>> then
>>> 	reg-names:
>>> 		-const: dbi
>>> 		-const: config
>>>
>>> Differece SOC have difference reg-names required list. If split it, it
>>> will be easy when add new SOC. Needn't change two place.
>>>
>>> Let me update at next version.
>>>
>>
>> This patch should be dropped. Why do you remove entries from top-level?
>> Are they defined in other schema?
> 
> pci/snps,dw-pcie.yaml already define it.

Indeed I see you wrote it in commit msg. However snps,dwc-pcie has it in
 an unconstrained way. Nothing in commit msg suggests there are
constrains somewhere.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 01:07:54 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 10:07:54 +0100
Subject: [PATCH v5 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint
 compatible string
In-Reply-To: <20231220213615.1561528-16-Frank.Li@nxp.com>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-16-Frank.Li@nxp.com>
Message-ID: <efadc706-ddf5-41bc-b4f3-c50dee548db5@linaro.org>

On 20/12/2023 22:36, Frank Li wrote:
> +    then:
> +      properties:
> +        reg:
> +          minItems: 2

Missing maxItems.

> +        reg-names:
> +          items:
> +            - const: dbi
> +            - const: addr_space
> +
> +  - if:
> +      properties:
> +        compatible:
> +          enum:
> +            - fsl,imx95-pcie-ep
> +    then:
> +      properties:
> +        reg:
> +          minItems: 6

Missing maxItems.



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 01:09:48 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 10:09:48 +0100
Subject: [PATCH v5 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint
 compatible string
In-Reply-To: <ZYe30jb7dxRxQ3hr@lizhi-Precision-Tower-5810>
References: <20231220213615.1561528-1-Frank.Li@nxp.com>
 <20231220213615.1561528-16-Frank.Li@nxp.com>
 <8fb359da-2d35-4cea-8a62-199fde1d9a29@linaro.org>
 <ZYe30jb7dxRxQ3hr@lizhi-Precision-Tower-5810>
Message-ID: <5676cb8d-c1fb-4b01-b0e0-beb76f2b6ca5@linaro.org>

On 24/12/2023 05:47, Frank Li wrote:
> On Sat, Dec 23, 2023 at 07:44:30PM +0100, Krzysztof Kozlowski wrote:
>> On 20/12/2023 22:36, Frank Li wrote:
>>> Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
>>> Add reg-name: "atu", "dbi2", "dma" and "serdes".
>>>
>>> Signed-off-by: Frank Li <Frank.Li at nxp.com>
>>> ---
>>>
>>> Notes:
>>>     Change from v1 to v3
>>>     - new patches at v3
>>>
>>>  .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 52 ++++++++++++++++---
>>>  1 file changed, 44 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
>>> index ee155ed5f1811..be9ea77ce8548 100644
>>> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
>>> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
>>> @@ -22,14 +22,7 @@ properties:
>>>        - fsl,imx8mm-pcie-ep
>>>        - fsl,imx8mq-pcie-ep
>>>        - fsl,imx8mp-pcie-ep
>>> -
>>> -  reg:
>>> -    minItems: 2
>>> -
>>> -  reg-names:
>>> -    items:
>>> -      - const: dbi
>>> -      - const: addr_space
>>
>> No, why? Entries should be defined top-level. If you remove them here,
>> where are they defined (in which schema)?
> 
> See: pci/snps,dw-pcie.yaml

OK



Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 01:10:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 10:10:53 +0100
Subject: [PATCH 1/5] arm: dts: marvell: clearfog-gtr: add board-specific
 compatible strings
In-Reply-To: <20231223212930.14624-2-josua@solid-run.com>
References: <20231223212930.14624-1-josua@solid-run.com>
 <20231223212930.14624-2-josua@solid-run.com>
Message-ID: <44a1dab9-5fa9-4128-a5e5-c0deeeeebaab@linaro.org>

On 23/12/2023 22:29, Josua Mayer wrote:
> Most arm board have a board-specific compatible string that allows e.g.
> userspace to match specific firmware variants or apply specific
> policies.
> 
> Add board-specific properties to both variants of the Clearfog GTR:
> - solidrun,clearfog-gtr-l8
> - solidrun,clearfog-gtr-s4
> 
> Introduction of a common parent (e.g. "solidrun,clearfog-gtr") is
> omitted for brevity.
> Since announcement of the two products no additional variants were added
> it is assumed that there will always be just two.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com>
> ---
>  arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 1 +
>  arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
> index 1990f7d0cc79..ae921a674c93 100644
> --- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
> +++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
> @@ -4,6 +4,7 @@
>  
>  / {
>  	model = "SolidRun Clearfog GTR L8";
> +	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385", "marvell,armada380";

Please run scripts/checkpatch.pl and fix reported warnings. Some
warnings can be ignored, but the code here looks like it needs a fix.
Feel free to get in touch if the warning is not clear.

I don't see them being documented.

Also, wrap at 80, as Linux coding style asks.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 01:11:36 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 10:11:36 +0100
Subject: [PATCH v2 1/2] dt-bindings: arm: fsl: Add VAR-SOM-MX93 with
 Symphony
In-Reply-To: <20231223205230.10534-2-othacehe@gnu.org>
References: <20231223205230.10534-1-othacehe@gnu.org>
 <20231223205230.10534-2-othacehe@gnu.org>
Message-ID: <90188f47-96cb-4673-b6ad-aad98d205843@linaro.org>

On 23/12/2023 21:52, Mathieu Othacehe wrote:
> Add support for Variscite i.MX93 VAR-SOM-MX93 SoM with Symphony board.
> 
> Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 01:12:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 10:12:53 +0100
Subject: [PATCH v2 2/2] arm64: dts: imx93-var-som: Add Variscite
 VAR-SOM-MX93
In-Reply-To: <20231223205230.10534-3-othacehe@gnu.org>
References: <20231223205230.10534-1-othacehe@gnu.org>
 <20231223205230.10534-3-othacehe@gnu.org>
Message-ID: <834a786c-c14e-4db5-a2a1-5223c7bb922b@linaro.org>

On 23/12/2023 21:52, Mathieu Othacehe wrote:
> Add DTSI for Variscite VAR-SOM-MX93 System on Module and DTS for Variscite
> VAR-SOM-MX93 on Symphony evaluation board.
> 

Thank you for your patch. There is something to discuss/improve.


> index 000000000000..ab675739e3ba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
> @@ -0,0 +1,306 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2021 NXP
> + * Copyright 2023 Variscite Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "imx93-var-som.dtsi"
> +
> +/{
> +	model = "Variscite VAR-SOM-MX93 on Symphony evaluation board";
> +	compatible = "variscite,var-som-mx93-symphony",
> +	"variscite,var-som-mx93", "fsl,imx93";

Missing indentation. Continued entries must be aligned with previous ".


Best regards,
Krzysztof



From cniedermaier at dh-electronics.com  Sun Dec 24 01:32:09 2023
From: cniedermaier at dh-electronics.com (Christoph Niedermaier)
Date: Sun, 24 Dec 2023 10:32:09 +0100
Subject: [PATCH V2] serial: imx: Correct clock error message in function probe()
Message-ID: <20231224093209.2612-1-cniedermaier@dh-electronics.com>

Correct the clock error message by changing the clock name.

Fixes: 1e512d45332b ("serial: imx: add error messages when .probe fails")
Signed-off-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>
Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Jiri Slaby <jirislaby at kernel.org>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <festevam at denx.de>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: Sergey Organov <sorganov at gmail.com>
Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
Cc: Rob Herring <robh at kernel.org>
Cc: "Ilpo J?rvinen" <ilpo.jarvinen at linux.intel.com>
Cc: Tom Rix <trix at redhat.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
To: linux-serial at vger.kernel.org
To: linux-arm-kernel at lists.infradead.org
---
V2: - Add Fixes tag
    - Add Reviewed-by tag
---
 drivers/tty/serial/imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e7e952bb7bb8..55105a4b1af8 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2327,7 +2327,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 	/* For register access, we only need to enable the ipg clock. */
 	ret = clk_prepare_enable(sport->clk_ipg);
 	if (ret) {
-		dev_err(&pdev->dev, "failed to enable per clk: %d\n", ret);
+		dev_err(&pdev->dev, "failed to enable ipg clk: %d\n", ret);
 		return ret;
 	}
 
-- 
2.11.0



From lkp at intel.com  Sun Dec 24 01:56:47 2023
From: lkp at intel.com (kernel test robot)
Date: Sun, 24 Dec 2023 17:56:47 +0800
Subject: [soc:soc/dt] BUILD SUCCESS
 2d7123c7e1678a01901887562f88890f39d1a51c
Message-ID: <202312241743.oYF2COll-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/dt
branch HEAD: 2d7123c7e1678a01901887562f88890f39d1a51c  Merge tag 'qcom-arm64-for-6.8' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt

elapsed time: 2693m

configs tested: 111
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231224   gcc  
arc                   randconfig-002-20231224   gcc  
arc                        vdk_hs38_defconfig   gcc  
arm                               allnoconfig   gcc  
arm                      jornada720_defconfig   gcc  
arm                   randconfig-001-20231224   gcc  
arm                   randconfig-002-20231224   gcc  
arm                   randconfig-003-20231224   gcc  
arm                   randconfig-004-20231224   gcc  
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231224   gcc  
arm64                 randconfig-002-20231224   gcc  
arm64                 randconfig-003-20231224   gcc  
arm64                 randconfig-004-20231224   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231224   gcc  
csky                  randconfig-002-20231224   gcc  
hexagon               randconfig-001-20231224   clang
hexagon               randconfig-002-20231224   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231224   gcc  
i386         buildonly-randconfig-002-20231224   gcc  
i386         buildonly-randconfig-003-20231224   gcc  
i386         buildonly-randconfig-004-20231224   gcc  
i386         buildonly-randconfig-005-20231224   gcc  
i386         buildonly-randconfig-006-20231224   gcc  
i386                                defconfig   gcc  
i386                  randconfig-001-20231224   gcc  
i386                  randconfig-002-20231224   gcc  
i386                  randconfig-003-20231224   gcc  
i386                  randconfig-004-20231224   gcc  
i386                  randconfig-005-20231224   gcc  
i386                  randconfig-006-20231224   gcc  
i386                  randconfig-011-20231224   clang
i386                  randconfig-012-20231224   clang
i386                  randconfig-013-20231224   clang
i386                  randconfig-014-20231224   clang
i386                  randconfig-015-20231224   clang
i386                  randconfig-016-20231224   clang
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20231224   gcc  
loongarch             randconfig-002-20231224   gcc  
m68k                              allnoconfig   gcc  
m68k                          amiga_defconfig   gcc  
m68k                                defconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                          defconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20231224   gcc  
nios2                 randconfig-002-20231224   gcc  
openrisc                          allnoconfig   gcc  
openrisc                            defconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20231224   gcc  
parisc                randconfig-002-20231224   gcc  
parisc64                         alldefconfig   gcc  
parisc64                            defconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                    amigaone_defconfig   gcc  
powerpc               randconfig-001-20231224   gcc  
powerpc               randconfig-002-20231224   gcc  
powerpc               randconfig-003-20231224   gcc  
powerpc                     tqm8555_defconfig   gcc  
powerpc                        warp_defconfig   gcc  
powerpc64             randconfig-001-20231224   gcc  
powerpc64             randconfig-002-20231224   gcc  
powerpc64             randconfig-003-20231224   gcc  
riscv                               defconfig   gcc  
riscv                 randconfig-001-20231224   gcc  
riscv                 randconfig-002-20231224   gcc  
s390                              allnoconfig   gcc  
s390                                defconfig   gcc  
s390                  randconfig-001-20231224   clang
s390                  randconfig-002-20231224   clang
sh                                allnoconfig   gcc  
sh                                  defconfig   gcc  
sh                        edosk7760_defconfig   gcc  
sh                    randconfig-001-20231224   gcc  
sh                    randconfig-002-20231224   gcc  
sh                          rsk7201_defconfig   gcc  
sh                           se7751_defconfig   gcc  
sh                            shmin_defconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20231224   gcc  
sparc64               randconfig-002-20231224   gcc  
um                                  defconfig   gcc  
um                             i386_defconfig   gcc  
um                    randconfig-001-20231224   gcc  
um                    randconfig-002-20231224   gcc  
um                           x86_64_defconfig   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64                              defconfig   gcc  
x86_64                                  kexec   gcc  
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                  audio_kc705_defconfig   gcc  
xtensa                randconfig-001-20231224   gcc  
xtensa                randconfig-002-20231224   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From krzysztof.kozlowski at linaro.org  Sun Dec 24 02:11:00 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 11:11:00 +0100
Subject: [PATCH] media:fimc-capture: Fix a possible data inconsistency due
 to a data race in fimc_subdev_set_fmt()
In-Reply-To: <20231223164351.3521588-1-islituo@gmail.com>
References: <20231223164351.3521588-1-islituo@gmail.com>
Message-ID: <93da765f-44c8-4023-b416-eae617d5ed74@linaro.org>

On 23/12/2023 17:43, Tuo Li wrote:
> Accesses to ctx->s_frame.width and ctx->s_frame.height should be protected
> by the lock fimc->lock to guarantee that width and height are consistent.
> Here is an example in fimc_subdev_get_fmt():
> 
>   struct fimc_frame *ff = &ctx->s_frame; // Alias
>   mutex_lock(&fimc->lock);
>   mf->width = ff->width;
>   mf->height = ff->height;
> 
> However, ctx->s_frame.width and ctx->s_frame.height are accessed without 
> holding the lock fimc->lock in fimc_subdev_set_fmt():
> 
>   mf->width = ctx->s_frame.width;
>   mf->height = ctx->s_frame.height;

Other places setting parts of s_frame, like fimc_capture_try_format() or
fimc_capture_try_selection(), do not have mutex.


> 
> And thus a harmful data race can occur, which can make ctx->s_frame.width

Harmful how?

> inconsistent with ctx->s_frame.height, if ctx->s_frame.height is updated 
> right after ctx->s_frame.width is accessed by another thread.
> 
> This possible bug is found by an experimental static analysis tool
> developed by our team, BassCheck[1]. This tool analyzes the locking APIs
> to extract function pairs that can be concurrently executed, and then
> analyzes the instructions in the paired functions to identify possible
> concurrency bugs including data races and atomicity violations. The above
> possible bug is reported when our tool analyzes the source code of
> Linux 6.2.
> 
> To fix this possible data race, the lock operation mutex_lock(&fimc->lock)
> is moved to the front of the accesses to these two variables. With this 
> patch applied, our tool no longer reports the bug, with the kernel 
> configuration allyesconfig for x86_64. Due to the lack of associated 
> hardware, we cannot test the patch in runtime testing, and just verify it 
> according to the code logic.

You wrote long four paragraphs which have basically almost zero relevant
information, whether this locking is needed or not. Your bass
description is not relevant... or actually making things worse because I
am certain you are fixing it just to fix your report, not to fix real issue.

> 
> [1] https://sites.google.com/view/basscheck/

Instead provide the report.

> 
> Fixes: 88fa8311ee36 ("[media] s5p-fimc: Add support for ISP Writeback ...")
> Signed-off-by: Tuo Li <islituo at gmail.com>
> Cc: stable at vger.kernel.org
> Reported-by: BassCheck <bass at buaa.edu.cn>

Run checkpatch, you will see the warning.


Best regards,
Krzysztof



From josua at solid-run.com  Sun Dec 24 02:11:34 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 10:11:34 +0000
Subject: [PATCH 3/5] arm: dts: marvell: clearfog-gtr: fix various off-by-1
 gpio numbers
In-Reply-To: <20231223212930.14624-4-josua@solid-run.com>
References: <20231223212930.14624-1-josua@solid-run.com>
 <20231223212930.14624-4-josua@solid-run.com>
Message-ID: <0ca7e3d9-a9bf-45aa-b867-d986edec6761@solid-run.com>

Hi everyone,

please disregard this patch, i added several mistakes of my own, will 
carefully rework this one for a v2.

Am 23.12.23 um 22:29 schrieb Josua Mayer:
> Various control signals such as sfp module-absence, pci-e reset or led
> gpios had off-by-1 mistakes where calculation from mpp number to gpio
> index in bank 1 was incorrect.
>
> Fix all such mistakes, and add explicit pinctrl entries for those gpios
> where missing.
>
> Signed-off-by: Josua Mayer <josua at solid-run.com>
> ---
>   .../dts/marvell/armada-385-clearfog-gtr.dtsi  | 61 ++++++++++++++-----
>   1 file changed, 47 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
> index 8eabb60765b0..d43bab0fe884 100644
> --- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
> +++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
> @@ -162,6 +162,22 @@ cf_gtr_isolation_pins: cf-gtr-isolation-pins {
>   					marvell,function = "gpio";
>   				};
>   
> +				cf_gtr_led_pins: led-pins {
> +					marvell,pins = "mpp42", "mpp52";
> +					marvell,function = "gpio";
> +				};
> +
> +				cf_gtr_lte_disable_pins: lte-disable-pins {
> +					marvell,pins = "mpp34";
> +					marvell,function = "gpio";
> +				};
> +
> +				cf_gtr_pci_pins: pci-pins {
> +					// pci reset
> +					marvell,pins = "mpp33", "mpp35";
> +					marvell,function = "gpio";
> +				};
> +
>   				cf_gtr_poe_reset_pins: cf-gtr-poe-reset-pins {
>   					marvell,pins = "mpp48";
>   					marvell,function = "gpio";
> @@ -179,6 +195,12 @@ cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
>   					marvell,function = "sd0";
>   				};
>   
> +				cf_gtr_sfp0_pins: sfp0-pins {
> +					/* sfp modabs, txdisable */
> +					marvell,pins = "mpp25", "mpp46";
> +					marvell,function = "gpio";
> +				};
> +
>   				cf_gtr_spi1_cs_pins: spi1-cs-pins {
>   					marvell,pins = "mpp59";
>   					marvell,function = "spi1";
> @@ -193,6 +215,11 @@ cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
>   					marvell,pins = "mpp22";
>   					marvell,function = "gpio";
>   				};
> +
> +				cf_gtr_wifi_disable_pins: wifi-disable-pins {
> +					marvell,pins = "mpp30", "mpp31";
> +					marvell,function = "gpio";
> +				};
>   			};
>   
>   			sdhci at d8000 {
> @@ -221,34 +248,38 @@ usb3 at f8000 {
>   		};
>   
>   		pcie {
> +			pinctrl-0 = <&cf_gtr_pci_pins>;
> +			pinctrl-names = "default";
>   			status = "okay";
>   			/*
>   			 * The PCIe units are accessible through
>   			 * the mini-PCIe connectors on the board.
>   			 */
>   			pcie at 1,0 {
> -				reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
> +				reset-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
>   				status = "okay";
>   			};
>   
>   			pcie at 2,0 {
> -				reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
> +				reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
>   				status = "okay";
>   			};
>   
>   			pcie at 3,0 {
> -				reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
> +				reset-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
>   				status = "okay";
>   			};
>   		};
>   	};
>   
> +	/* CON5 */
>   	sfp0: sfp {
>   		compatible = "sff,sfp";
> +		pinctrl-0 = <&cf_gtr_sfp0_pins>;
> +		pinctrl-names = "default";
>   		i2c-bus = <&i2c1>;
> -		los-gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
>   		mod-def0-gpio = <&gpio0 25 GPIO_ACTIVE_LOW>;
> -		tx-disable-gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
> +		tx-disable-gpio = <&gpio1 15 GPIO_ACTIVE_HIGH>;
>   	};
>   
>   	gpio-keys {
> @@ -258,14 +289,14 @@ gpio-keys {
>   
>   		button-0 {
>   			label = "Rear Button";
> -			gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
> +			gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;
>   			linux,can-disable;
>   			linux,code = <BTN_0>;
>   		};
>   
>   		button-1 {
>   			label = "Front Button";
> -			gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
> +			gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
>   			linux,can-disable;
>   			linux,code = <BTN_1>;
>   		};
> @@ -273,17 +304,19 @@ button-1 {
>   
>   	gpio-leds {
>   		compatible = "gpio-leds";
> +		pinctrl-0 = <&cf_gtr_led_pins>;
> +		pinctrl-names = "default";
>   
>   		led1 {
>   			function = LED_FUNCTION_CPU;
>   			color = <LED_COLOR_ID_GREEN>;
> -			gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
> +			gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
>   		};
>   
>   		led2 {
>   			function = LED_FUNCTION_HEARTBEAT;
>   			color = <LED_COLOR_ID_GREEN>;
> -			gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
> +			gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
>   		};
>   	};
>   };
> @@ -408,7 +441,7 @@ &ahci1 {
>   };
>   
>   &gpio0 {
> -	pinctrl-0 = <&cf_gtr_fan_pwm>;
> +	pinctrl-0 = <&cf_gtr_fan_pwm &cf_gtr_wifi_disable_pins>;
>   	pinctrl-names = "default";
>   
>   	wifi-disable {
> @@ -420,12 +453,12 @@ wifi-disable {
>   };
>   
>   &gpio1 {
> -	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins>;
> +	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins &cf_gtr_lte_disable_pins>;
>   	pinctrl-names = "default";
>   
>   	lte-disable {
>   		gpio-hog;
> -		gpios = <2 GPIO_ACTIVE_LOW>;
> +		gpios = <3 GPIO_ACTIVE_LOW>;
>   		output-low;
>   		line-name = "lte-disable";
>   	};
> @@ -436,14 +469,14 @@ lte-disable {
>   	 */
>   	sar-isolation {
>   		gpio-hog;
> -		gpios = <15 GPIO_ACTIVE_LOW>;
> +		gpios = <16 GPIO_ACTIVE_LOW>;
>   		output-low;
>   		line-name = "sar-isolation";
>   	};
>   
>   	poe-reset {
>   		gpio-hog;
> -		gpios = <16 GPIO_ACTIVE_LOW>;
> +		gpios = <17 GPIO_ACTIVE_LOW>;
>   		output-low;
>   		line-name = "poe-reset";
>   	};



From f.fainelli at gmail.com  Sun Dec 24 02:12:53 2023
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sun, 24 Dec 2023 11:12:53 +0100
Subject: [PATCH] ARM: sun9i: smp: Fix array-index-out-of-bounds read in
 sunxi_mc_smp_init
In-Reply-To: <20231223123546.88125-1-wahrenst@gmx.net>
References: <20231223123546.88125-1-wahrenst@gmx.net>
Message-ID: <17bfb503-9e6a-40c7-b9fa-fc89c8a903c9@gmail.com>



On 12/23/2023 1:35 PM, Stefan Wahren wrote:
> Running a multi-arch kernel (multi_v7_defconfig) on a Raspberry Pi 3B+
> with enabled CONFIG_UBSAN triggers the following warning:
> 
>   UBSAN: array-index-out-of-bounds in arch/arm/mach-sunxi/mc_smp.c:810:29
>   index 2 is out of range for type 'sunxi_mc_smp_data [2]'
>   CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc6-00248-g5254c0cbc92d
>   Hardware name: BCM2835
>    unwind_backtrace from show_stack+0x10/0x14
>    show_stack from dump_stack_lvl+0x40/0x4c
>    dump_stack_lvl from ubsan_epilogue+0x8/0x34
>    ubsan_epilogue from __ubsan_handle_out_of_bounds+0x78/0x80
>    __ubsan_handle_out_of_bounds from sunxi_mc_smp_init+0xe4/0x4cc
>    sunxi_mc_smp_init from do_one_initcall+0xa0/0x2fc
>    do_one_initcall from kernel_init_freeable+0xf4/0x2f4
>    kernel_init_freeable from kernel_init+0x18/0x158
>    kernel_init from ret_from_fork+0x14/0x28
> 
> Since the enabled method couldn't match with any entry from
> sunxi_mc_smp_data, the value of the index shouldn't be used right after
> the loop. So move it after the check of ret in order to have a valid
> index.
> 
> Fixes: 1631090e34f5 ("ARM: sun9i: smp: Add is_a83t field")
> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>

Previous attempts at fixing this:

https://lore.kernel.org/lkml/20230516-sunxi-v1-1-ac4b9651a8c1 at google.com/T/

including a patch from William from nearly 18 months ago, which was not 
captured by lore however.

Is anyone collecting patches for that platform still?
-- 
Florian


From josua at solid-run.com  Sun Dec 24 02:16:22 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 10:16:22 +0000
Subject: [PATCH 1/5] arm: dts: marvell: clearfog-gtr: add board-specific
 compatible strings
In-Reply-To: <44a1dab9-5fa9-4128-a5e5-c0deeeeebaab@linaro.org>
References: <20231223212930.14624-1-josua@solid-run.com>
 <20231223212930.14624-2-josua@solid-run.com>
 <44a1dab9-5fa9-4128-a5e5-c0deeeeebaab@linaro.org>
Message-ID: <7a8f0c19-096c-4d29-a8b5-431f60601876@solid-run.com>

Am 24.12.23 um 10:10 schrieb Krzysztof Kozlowski:
> On 23/12/2023 22:29, Josua Mayer wrote:
>> Most arm board have a board-specific compatible string that allows e.g.
>> userspace to match specific firmware variants or apply specific
>> policies.
>>
>> Add board-specific properties to both variants of the Clearfog GTR:
>> - solidrun,clearfog-gtr-l8
>> - solidrun,clearfog-gtr-s4
>>
>> Introduction of a common parent (e.g. "solidrun,clearfog-gtr") is
>> omitted for brevity.
>> Since announcement of the two products no additional variants were added
>> it is assumed that there will always be just two.
>>
>> Signed-off-by: Josua Mayer <josua at solid-run.com>
>> ---
>>   arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 1 +
>>   arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts | 1 +
>>   2 files changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
>> index 1990f7d0cc79..ae921a674c93 100644
>> --- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
>> +++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
>> @@ -4,6 +4,7 @@
>>   
>>   / {
>>   	model = "SolidRun Clearfog GTR L8";
>> +	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385", "marvell,armada380";
> Please run scripts/checkpatch.pl and fix reported warnings. Some
> warnings can be ignored, but the code here looks like it needs a fix.
> Feel free to get in touch if the warning is not clear.
>
> I don't see them being documented.

Yes, checkpatch warned about that specifially, but I am not sure how to 
proceed.
The armada-38x dt bindings documentation is stil in text format, and 
doesn't document any board:

Documentation/devicetree/bindings/arm/marvell/armada-38x.txt

>
> Also, wrap at 80, as Linux coding style asks.
Will do.
>
> Best regards,
> Krzysztof
>


From krzysztof.kozlowski at linaro.org  Sun Dec 24 02:52:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 11:52:08 +0100
Subject: [PATCH 1/5] arm: dts: marvell: clearfog-gtr: add board-specific
 compatible strings
In-Reply-To: <7a8f0c19-096c-4d29-a8b5-431f60601876@solid-run.com>
References: <20231223212930.14624-1-josua@solid-run.com>
 <20231223212930.14624-2-josua@solid-run.com>
 <44a1dab9-5fa9-4128-a5e5-c0deeeeebaab@linaro.org>
 <7a8f0c19-096c-4d29-a8b5-431f60601876@solid-run.com>
Message-ID: <2d2535fb-185c-4663-a012-46a93d2d17bb@linaro.org>

On 24/12/2023 11:16, Josua Mayer wrote:
> Am 24.12.23 um 10:10 schrieb Krzysztof Kozlowski:
>> On 23/12/2023 22:29, Josua Mayer wrote:
>>> Most arm board have a board-specific compatible string that allows e.g.
>>> userspace to match specific firmware variants or apply specific
>>> policies.
>>>
>>> Add board-specific properties to both variants of the Clearfog GTR:
>>> - solidrun,clearfog-gtr-l8
>>> - solidrun,clearfog-gtr-s4
>>>
>>> Introduction of a common parent (e.g. "solidrun,clearfog-gtr") is
>>> omitted for brevity.
>>> Since announcement of the two products no additional variants were added
>>> it is assumed that there will always be just two.
>>>
>>> Signed-off-by: Josua Mayer <josua at solid-run.com>
>>> ---
>>>   arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 1 +
>>>   arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts | 1 +
>>>   2 files changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
>>> index 1990f7d0cc79..ae921a674c93 100644
>>> --- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
>>> +++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
>>> @@ -4,6 +4,7 @@
>>>   
>>>   / {
>>>   	model = "SolidRun Clearfog GTR L8";
>>> +	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385", "marvell,armada380";
>> Please run scripts/checkpatch.pl and fix reported warnings. Some
>> warnings can be ignored, but the code here looks like it needs a fix.
>> Feel free to get in touch if the warning is not clear.
>>
>> I don't see them being documented.
> 
> Yes, checkpatch warned about that specifially, but I am not sure how to 
> proceed.
> The armada-38x dt bindings documentation is stil in text format, and 
> doesn't document any board:
> 
> Documentation/devicetree/bindings/arm/marvell/armada-38x.txt

There was some work in progress, AFAIR. This should be solved before
bringing more undocumented compatibles.

Best regards,
Krzysztof



From wahrenst at gmx.net  Sun Dec 24 03:17:42 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Sun, 24 Dec 2023 12:17:42 +0100
Subject: [PATCH] ARM: sun9i: smp: Fix array-index-out-of-bounds read in
 sunxi_mc_smp_init
In-Reply-To: <17bfb503-9e6a-40c7-b9fa-fc89c8a903c9@gmail.com>
References: <20231223123546.88125-1-wahrenst@gmx.net>
 <17bfb503-9e6a-40c7-b9fa-fc89c8a903c9@gmail.com>
Message-ID: <44838edf-a7c7-4563-b9ea-b874dc3a1698@gmx.net>

Hi Florian,

Am 24.12.23 um 11:12 schrieb Florian Fainelli:
>
>
> On 12/23/2023 1:35 PM, Stefan Wahren wrote:
>> Running a multi-arch kernel (multi_v7_defconfig) on a Raspberry Pi 3B+
>> with enabled CONFIG_UBSAN triggers the following warning:
>>
>> ? UBSAN: array-index-out-of-bounds in
>> arch/arm/mach-sunxi/mc_smp.c:810:29
>> ? index 2 is out of range for type 'sunxi_mc_smp_data [2]'
>> ? CPU: 0 PID: 1 Comm: swapper/0 Not tainted
>> 6.7.0-rc6-00248-g5254c0cbc92d
>> ? Hardware name: BCM2835
>> ?? unwind_backtrace from show_stack+0x10/0x14
>> ?? show_stack from dump_stack_lvl+0x40/0x4c
>> ?? dump_stack_lvl from ubsan_epilogue+0x8/0x34
>> ?? ubsan_epilogue from __ubsan_handle_out_of_bounds+0x78/0x80
>> ?? __ubsan_handle_out_of_bounds from sunxi_mc_smp_init+0xe4/0x4cc
>> ?? sunxi_mc_smp_init from do_one_initcall+0xa0/0x2fc
>> ?? do_one_initcall from kernel_init_freeable+0xf4/0x2f4
>> ?? kernel_init_freeable from kernel_init+0x18/0x158
>> ?? kernel_init from ret_from_fork+0x14/0x28
>>
>> Since the enabled method couldn't match with any entry from
>> sunxi_mc_smp_data, the value of the index shouldn't be used right after
>> the loop. So move it after the check of ret in order to have a valid
>> index.
>>
>> Fixes: 1631090e34f5 ("ARM: sun9i: smp: Add is_a83t field")
>> Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
>
> Previous attempts at fixing this:
>
> https://lore.kernel.org/lkml/20230516-sunxi-v1-1-ac4b9651a8c1 at google.com/T/
thanks for pointing out. Nick's version missed the refcounting of node
and my version missed the proper handling of of_property_match_string.
So we have actually two issues in the original code.

I will prepare a second version.

Nevertheless merry x-mas
>
> including a patch from William from nearly 18 months ago, which was
> not captured by lore however.
>
> Is anyone collecting patches for that platform still?



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:05 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:05 +0100
Subject: [PATCH 01/12] media: fimc-lite: drop unused flite_hw_set_camera_polarity()
Message-ID: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>

Function flite_hw_set_camera_polarity() is not defined, so drop its
declaration from the header.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.h b/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.h
index c5656e902750..3b8af3ce1838 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.h
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.h
@@ -134,8 +134,6 @@ void flite_hw_capture_start(struct fimc_lite *dev);
 void flite_hw_capture_stop(struct fimc_lite *dev);
 void flite_hw_set_camera_bus(struct fimc_lite *dev,
 			     struct fimc_source_info *s_info);
-void flite_hw_set_camera_polarity(struct fimc_lite *dev,
-				  struct fimc_source_info *cam);
 void flite_hw_set_window_offset(struct fimc_lite *dev, struct flite_frame *f);
 void flite_hw_set_source_format(struct fimc_lite *dev, struct flite_frame *f);
 
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:06 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:06 +0100
Subject: [PATCH 02/12] media: fimc-lite: constify several pointers in function arguments
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-2-krzysztof.kozlowski@linaro.org>

Several functions do not modify pointed structure, thus the pointer can
point to const data for additional safety and self-documenting intention
of the function.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../platform/samsung/exynos4-is/fimc-lite-reg.c     | 13 +++++++------
 .../platform/samsung/exynos4-is/fimc-lite-reg.h     | 10 +++++-----
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.c b/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.c
index 57996b4104b4..2483277a6cb0 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.c
@@ -124,7 +124,7 @@ static const u32 src_pixfmt_map[8][3] = {
 };
 
 /* Set camera input pixel format and resolution */
-void flite_hw_set_source_format(struct fimc_lite *dev, struct flite_frame *f)
+void flite_hw_set_source_format(struct fimc_lite *dev, const struct flite_frame *f)
 {
 	u32 pixelcode = f->fmt->mbus_code;
 	int i = ARRAY_SIZE(src_pixfmt_map);
@@ -155,7 +155,7 @@ void flite_hw_set_source_format(struct fimc_lite *dev, struct flite_frame *f)
 }
 
 /* Set the camera host input window offsets (cropping) */
-void flite_hw_set_window_offset(struct fimc_lite *dev, struct flite_frame *f)
+void flite_hw_set_window_offset(struct fimc_lite *dev, const struct flite_frame *f)
 {
 	u32 hoff2, voff2;
 	u32 cfg;
@@ -186,7 +186,7 @@ static void flite_hw_set_camera_port(struct fimc_lite *dev, int id)
 
 /* Select serial or parallel bus, camera port (A,B) and set signals polarity */
 void flite_hw_set_camera_bus(struct fimc_lite *dev,
-			     struct fimc_source_info *si)
+			     const struct fimc_source_info *si)
 {
 	u32 cfg = readl(dev->regs + FLITE_REG_CIGCTRL);
 	unsigned int flags = si->flags;
@@ -226,7 +226,8 @@ static void flite_hw_set_pack12(struct fimc_lite *dev, int on)
 	writel(cfg, dev->regs + FLITE_REG_CIODMAFMT);
 }
 
-static void flite_hw_set_out_order(struct fimc_lite *dev, struct flite_frame *f)
+static void flite_hw_set_out_order(struct fimc_lite *dev,
+				   const struct flite_frame *f)
 {
 	static const u32 pixcode[4][2] = {
 		{ MEDIA_BUS_FMT_YUYV8_2X8, FLITE_REG_CIODMAFMT_YCBYCR },
@@ -244,7 +245,7 @@ static void flite_hw_set_out_order(struct fimc_lite *dev, struct flite_frame *f)
 	writel(cfg | pixcode[i][1], dev->regs + FLITE_REG_CIODMAFMT);
 }
 
-void flite_hw_set_dma_window(struct fimc_lite *dev, struct flite_frame *f)
+void flite_hw_set_dma_window(struct fimc_lite *dev, const struct flite_frame *f)
 {
 	u32 cfg;
 
@@ -294,7 +295,7 @@ void flite_hw_mask_dma_buffer(struct fimc_lite *dev, u32 index)
 }
 
 /* Enable/disable output DMA, set output pixel size and offsets (composition) */
-void flite_hw_set_output_dma(struct fimc_lite *dev, struct flite_frame *f,
+void flite_hw_set_output_dma(struct fimc_lite *dev, const struct flite_frame *f,
 			     bool enable)
 {
 	u32 cfg = readl(dev->regs + FLITE_REG_CIGCTRL);
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.h b/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.h
index 3b8af3ce1838..c5ec36dfb2f9 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.h
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-lite-reg.h
@@ -133,13 +133,13 @@ void flite_hw_set_interrupt_mask(struct fimc_lite *dev);
 void flite_hw_capture_start(struct fimc_lite *dev);
 void flite_hw_capture_stop(struct fimc_lite *dev);
 void flite_hw_set_camera_bus(struct fimc_lite *dev,
-			     struct fimc_source_info *s_info);
-void flite_hw_set_window_offset(struct fimc_lite *dev, struct flite_frame *f);
-void flite_hw_set_source_format(struct fimc_lite *dev, struct flite_frame *f);
+			     const struct fimc_source_info *s_info);
+void flite_hw_set_window_offset(struct fimc_lite *dev, const struct flite_frame *f);
+void flite_hw_set_source_format(struct fimc_lite *dev, const struct flite_frame *f);
 
-void flite_hw_set_output_dma(struct fimc_lite *dev, struct flite_frame *f,
+void flite_hw_set_output_dma(struct fimc_lite *dev, const struct flite_frame *f,
 			     bool enable);
-void flite_hw_set_dma_window(struct fimc_lite *dev, struct flite_frame *f);
+void flite_hw_set_dma_window(struct fimc_lite *dev, const struct flite_frame *f);
 void flite_hw_set_test_pattern(struct fimc_lite *dev, bool on);
 void flite_hw_dump_regs(struct fimc_lite *dev, const char *label);
 void flite_hw_set_dma_buffer(struct fimc_lite *dev, struct flite_buffer *buf);
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:07 +0100
Subject: [PATCH 03/12] media: fimc-lite: constify pointers to v4l2_pix_format_mplane
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-3-krzysztof.kozlowski@linaro.org>

In few places functions do not modify pointed "struct
v4l2_pix_format_mplane", thus the pointer can point to const data for
additional safety and self-documenting intention of the function.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/exynos4-is/fimc-lite.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-lite.c b/drivers/media/platform/samsung/exynos4-is/fimc-lite.c
index 7898c9bebb04..d1d860fa3454 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-lite.c
@@ -738,7 +738,7 @@ static int fimc_lite_try_fmt_mplane(struct file *file, void *fh,
 static int fimc_lite_s_fmt_mplane(struct file *file, void *priv,
 				  struct v4l2_format *f)
 {
-	struct v4l2_pix_format_mplane *pixm = &f->fmt.pix_mp;
+	const struct v4l2_pix_format_mplane *pixm = &f->fmt.pix_mp;
 	struct fimc_lite *fimc = video_drvdata(file);
 	struct flite_frame *frame = &fimc->out_frame;
 	const struct fimc_fmt *fmt = NULL;
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:08 +0100
Subject: [PATCH 04/12] media: fimc-is: drop unused fimc_vidioc_enum_fmt_mplane()
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-4-krzysztof.kozlowski@linaro.org>

Function fimc_vidioc_enum_fmt_mplane() is not defined, so drop its
declaration from the header.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/exynos4-is/fimc-core.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-core.h b/drivers/media/platform/samsung/exynos4-is/fimc-core.h
index 2b0760add092..cc840e6e07a9 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-core.h
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-core.h
@@ -610,8 +610,6 @@ static inline struct fimc_frame *ctx_get_frame(struct fimc_ctx *ctx,
 
 /* -----------------------------------------------------*/
 /* fimc-core.c */
-int fimc_vidioc_enum_fmt_mplane(struct file *file, void *priv,
-				struct v4l2_fmtdesc *f);
 int fimc_ctrls_create(struct fimc_ctx *ctx);
 void fimc_ctrls_delete(struct fimc_ctx *ctx);
 void fimc_ctrls_activate(struct fimc_ctx *ctx, bool active);
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:09 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:09 +0100
Subject: [PATCH 05/12] media: fimc-is: constify clock names
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-5-krzysztof.kozlowski@linaro.org>

Static array with clock names can be made const for code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/exynos4-is/fimc-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-core.c b/drivers/media/platform/samsung/exynos4-is/fimc-core.c
index 97908778e1c8..ad72cc31dc45 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-core.c
@@ -29,7 +29,7 @@
 #include "fimc-reg.h"
 #include "media-dev.h"
 
-static char *fimc_clocks[MAX_FIMC_CLOCKS] = {
+static const char *fimc_clocks[MAX_FIMC_CLOCKS] = {
 	"sclk_fimc", "fimc"
 };
 
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:10 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:10 +0100
Subject: [PATCH 06/12] media: fimc-is: constify several pointers in function arguments
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-6-krzysztof.kozlowski@linaro.org>

Several functions do not modify pointed structure, thus the pointer can
point to const data for additional safety and self-documenting intention
of the function.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../media/platform/samsung/exynos4-is/fimc-core.c    |  6 +++---
 .../media/platform/samsung/exynos4-is/fimc-core.h    | 12 ++++++------
 drivers/media/platform/samsung/exynos4-is/fimc-reg.c | 10 +++++-----
 drivers/media/platform/samsung/exynos4-is/fimc-reg.h | 10 +++++-----
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-core.c b/drivers/media/platform/samsung/exynos4-is/fimc-core.c
index ad72cc31dc45..13b04fda8716 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-core.c
@@ -326,7 +326,7 @@ static irqreturn_t fimc_irq_handler(int irq, void *priv)
 
 /* The color format (colplanes, memplanes) must be already configured. */
 int fimc_prepare_addr(struct fimc_ctx *ctx, struct vb2_buffer *vb,
-		      struct fimc_frame *frame, struct fimc_addr *addr)
+		      const struct fimc_frame *frame, struct fimc_addr *addr)
 {
 	int ret = 0;
 	u32 pix_size;
@@ -670,7 +670,7 @@ void fimc_alpha_ctrl_update(struct fimc_ctx *ctx)
 	v4l2_ctrl_unlock(ctrl);
 }
 
-void __fimc_get_format(struct fimc_frame *frame, struct v4l2_format *f)
+void __fimc_get_format(const struct fimc_frame *frame, struct v4l2_format *f)
 {
 	struct v4l2_pix_format_mplane *pixm = &f->fmt.pix_mp;
 	int i;
@@ -695,7 +695,7 @@ void __fimc_get_format(struct fimc_frame *frame, struct v4l2_format *f)
  * @height: requested pixel height
  * @pix: multi-plane format to adjust
  */
-void fimc_adjust_mplane_format(struct fimc_fmt *fmt, u32 width, u32 height,
+void fimc_adjust_mplane_format(const struct fimc_fmt *fmt, u32 width, u32 height,
 			       struct v4l2_pix_format_mplane *pix)
 {
 	u32 bytesperline = 0;
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-core.h b/drivers/media/platform/samsung/exynos4-is/fimc-core.h
index cc840e6e07a9..261c9aac2f7f 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-core.h
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-core.h
@@ -515,7 +515,7 @@ static inline void set_frame_crop(struct fimc_frame *f,
 	f->height = height;
 }
 
-static inline u32 fimc_get_format_depth(struct fimc_fmt *ff)
+static inline u32 fimc_get_format_depth(const struct fimc_fmt *ff)
 {
 	u32 i, depth = 0;
 
@@ -557,7 +557,7 @@ static inline bool fimc_ctx_state_is_set(u32 mask, struct fimc_ctx *ctx)
 	return ret;
 }
 
-static inline int tiled_fmt(struct fimc_fmt *fmt)
+static inline int tiled_fmt(const struct fimc_fmt *fmt)
 {
 	return fmt->fourcc == V4L2_PIX_FMT_NV12MT;
 }
@@ -575,7 +575,7 @@ static inline bool fimc_user_defined_mbus_fmt(u32 code)
 }
 
 /* Return the alpha component bit mask */
-static inline int fimc_get_alpha_mask(struct fimc_fmt *fmt)
+static inline int fimc_get_alpha_mask(const struct fimc_fmt *fmt)
 {
 	switch (fmt->color) {
 	case FIMC_FMT_RGB444:	return 0x0f;
@@ -614,8 +614,8 @@ int fimc_ctrls_create(struct fimc_ctx *ctx);
 void fimc_ctrls_delete(struct fimc_ctx *ctx);
 void fimc_ctrls_activate(struct fimc_ctx *ctx, bool active);
 void fimc_alpha_ctrl_update(struct fimc_ctx *ctx);
-void __fimc_get_format(struct fimc_frame *frame, struct v4l2_format *f);
-void fimc_adjust_mplane_format(struct fimc_fmt *fmt, u32 width, u32 height,
+void __fimc_get_format(const struct fimc_frame *frame, struct v4l2_format *f);
+void fimc_adjust_mplane_format(const struct fimc_fmt *fmt, u32 width, u32 height,
 			       struct v4l2_pix_format_mplane *pix);
 struct fimc_fmt *fimc_find_format(const u32 *pixelformat, const u32 *mbus_code,
 				  unsigned int mask, int index);
@@ -626,7 +626,7 @@ int fimc_check_scaler_ratio(struct fimc_ctx *ctx, int sw, int sh,
 int fimc_set_scaler_info(struct fimc_ctx *ctx);
 int fimc_prepare_config(struct fimc_ctx *ctx, u32 flags);
 int fimc_prepare_addr(struct fimc_ctx *ctx, struct vb2_buffer *vb,
-		      struct fimc_frame *frame, struct fimc_addr *addr);
+		      const struct fimc_frame *frame, struct fimc_addr *addr);
 void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct fimc_frame *f);
 void fimc_set_yuv_order(struct fimc_ctx *ctx);
 void fimc_capture_irq_handler(struct fimc_dev *fimc, int deq_buf);
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
index 95165a2cc7d1..f20fb74dd0c6 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
@@ -526,7 +526,7 @@ void fimc_hw_set_output_path(struct fimc_ctx *ctx)
 	writel(cfg, dev->regs + FIMC_REG_CISCCTRL);
 }
 
-void fimc_hw_set_input_addr(struct fimc_dev *dev, struct fimc_addr *addr)
+void fimc_hw_set_input_addr(struct fimc_dev *dev, const struct fimc_addr *addr)
 {
 	u32 cfg = readl(dev->regs + FIMC_REG_CIREAL_ISIZE);
 	cfg |= FIMC_REG_CIREAL_ISIZE_ADDR_CH_DIS;
@@ -541,7 +541,7 @@ void fimc_hw_set_input_addr(struct fimc_dev *dev, struct fimc_addr *addr)
 }
 
 void fimc_hw_set_output_addr(struct fimc_dev *dev,
-			     struct fimc_addr *addr, int index)
+			     const struct fimc_addr *addr, int index)
 {
 	int i = (index == -1) ? 0 : index;
 	do {
@@ -554,7 +554,7 @@ void fimc_hw_set_output_addr(struct fimc_dev *dev,
 }
 
 int fimc_hw_set_camera_polarity(struct fimc_dev *fimc,
-				struct fimc_source_info *cam)
+				const struct fimc_source_info *cam)
 {
 	u32 cfg = readl(fimc->regs + FIMC_REG_CIGCTRL);
 
@@ -648,7 +648,7 @@ int fimc_hw_set_camera_source(struct fimc_dev *fimc,
 	return 0;
 }
 
-void fimc_hw_set_camera_offset(struct fimc_dev *fimc, struct fimc_frame *f)
+void fimc_hw_set_camera_offset(struct fimc_dev *fimc, const struct fimc_frame *f)
 {
 	u32 hoff2, voff2;
 
@@ -668,7 +668,7 @@ void fimc_hw_set_camera_offset(struct fimc_dev *fimc, struct fimc_frame *f)
 }
 
 int fimc_hw_set_camera_type(struct fimc_dev *fimc,
-			    struct fimc_source_info *source)
+			    const struct fimc_source_info *source)
 {
 	struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
 	u32 csis_data_alignment = 32;
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-reg.h b/drivers/media/platform/samsung/exynos4-is/fimc-reg.h
index b9b33aa1f12f..9714f4309655 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-reg.h
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-reg.h
@@ -302,16 +302,16 @@ void fimc_hw_set_rgb_alpha(struct fimc_ctx *ctx);
 void fimc_hw_set_in_dma(struct fimc_ctx *ctx);
 void fimc_hw_set_input_path(struct fimc_ctx *ctx);
 void fimc_hw_set_output_path(struct fimc_ctx *ctx);
-void fimc_hw_set_input_addr(struct fimc_dev *fimc, struct fimc_addr *addr);
-void fimc_hw_set_output_addr(struct fimc_dev *fimc, struct fimc_addr *addr,
+void fimc_hw_set_input_addr(struct fimc_dev *fimc, const struct fimc_addr *addr);
+void fimc_hw_set_output_addr(struct fimc_dev *fimc, const struct fimc_addr *addr,
 			     int index);
 int fimc_hw_set_camera_source(struct fimc_dev *fimc,
 			      struct fimc_source_info *cam);
-void fimc_hw_set_camera_offset(struct fimc_dev *fimc, struct fimc_frame *f);
+void fimc_hw_set_camera_offset(struct fimc_dev *fimc, const struct fimc_frame *f);
 int fimc_hw_set_camera_polarity(struct fimc_dev *fimc,
-				struct fimc_source_info *cam);
+				const struct fimc_source_info *cam);
 int fimc_hw_set_camera_type(struct fimc_dev *fimc,
-			    struct fimc_source_info *cam);
+			    const struct fimc_source_info *cam);
 void fimc_hw_clear_irq(struct fimc_dev *dev);
 void fimc_hw_enable_scaler(struct fimc_dev *dev, bool on);
 void fimc_hw_activate_input_dma(struct fimc_dev *dev, bool on);
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:11 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:11 +0100
Subject: [PATCH 07/12] media: fimc-is: constify local pointers to fimc_fmt
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-7-krzysztof.kozlowski@linaro.org>

Constify the local variable pointing to "struct fimc_fmt" to annotate
the function is not modifying pointed data.  This is the easy and
obvious step of constifying all "struct fimc_fmt" instances.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/exynos4-is/fimc-capture.c | 6 +++---
 drivers/media/platform/samsung/exynos4-is/fimc-m2m.c     | 4 ++--
 drivers/media/platform/samsung/exynos4-is/fimc-reg.c     | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
index 05cafba1c728..dde36e5be0c7 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
@@ -343,7 +343,7 @@ static int queue_setup(struct vb2_queue *vq,
 {
 	struct fimc_ctx *ctx = vq->drv_priv;
 	struct fimc_frame *frame = &ctx->d_frame;
-	struct fimc_fmt *fmt = frame->fmt;
+	const struct fimc_fmt *fmt = frame->fmt;
 	unsigned long wh = frame->f_width * frame->f_height;
 	int i;
 
@@ -722,7 +722,7 @@ static int fimc_cap_querycap(struct file *file, void *priv,
 static int fimc_cap_enum_fmt(struct file *file, void *priv,
 			     struct v4l2_fmtdesc *f)
 {
-	struct fimc_fmt *fmt;
+	const struct fimc_fmt *fmt;
 
 	fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM | FMT_FLAGS_M2M,
 			       f->index);
@@ -1460,7 +1460,7 @@ static int fimc_subdev_enum_mbus_code(struct v4l2_subdev *sd,
 				      struct v4l2_subdev_state *sd_state,
 				      struct v4l2_subdev_mbus_code_enum *code)
 {
-	struct fimc_fmt *fmt;
+	const struct fimc_fmt *fmt;
 
 	fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM, code->index);
 	if (!fmt)
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c b/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
index df8e2aa454d8..1918390a2469 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
@@ -237,7 +237,7 @@ static int fimc_m2m_querycap(struct file *file, void *fh,
 static int fimc_m2m_enum_fmt(struct file *file, void *priv,
 			     struct v4l2_fmtdesc *f)
 {
-	struct fimc_fmt *fmt;
+	const struct fimc_fmt *fmt;
 
 	fmt = fimc_find_format(NULL, NULL, get_m2m_fmt_flags(f->type),
 			       f->index);
@@ -266,7 +266,7 @@ static int fimc_try_fmt_mplane(struct fimc_ctx *ctx, struct v4l2_format *f)
 	struct fimc_dev *fimc = ctx->fimc_dev;
 	const struct fimc_variant *variant = fimc->variant;
 	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
-	struct fimc_fmt *fmt;
+	const struct fimc_fmt *fmt;
 	u32 max_w, mod_x, mod_y;
 
 	if (!IS_M2M(f->type))
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
index f20fb74dd0c6..dbc43b703324 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
@@ -168,7 +168,7 @@ void fimc_hw_set_out_dma(struct fimc_ctx *ctx)
 	struct fimc_dev *dev = ctx->fimc_dev;
 	struct fimc_frame *frame = &ctx->d_frame;
 	struct fimc_dma_offset *offset = &frame->dma_offset;
-	struct fimc_fmt *fmt = frame->fmt;
+	const struct fimc_fmt *fmt = frame->fmt;
 	u32 cfg;
 
 	/* Set the input dma offsets. */
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:12 +0100
Subject: [PATCH 08/12] media: fimc-is: constify fimc_formats array
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-8-krzysztof.kozlowski@linaro.org>

Pointers to elements of the static array "fimc_formats" with "struct
fimc_fmt" are passed all around to various calls, but all of them do not
modify pointed data.  Constify the pointers everywhere which at the end
allows to make static array "fimc_formats" const itself.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../samsung/exynos4-is/fimc-capture.c         | 26 +++++++++----------
 .../platform/samsung/exynos4-is/fimc-core.c   | 11 ++++----
 .../platform/samsung/exynos4-is/fimc-core.h   |  9 ++++---
 .../platform/samsung/exynos4-is/fimc-m2m.c    |  7 ++---
 4 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
index dde36e5be0c7..a3a677a3065f 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
@@ -559,9 +559,9 @@ static const struct v4l2_file_operations fimc_capture_fops = {
  * Format and crop negotiation helpers
  */
 
-static struct fimc_fmt *fimc_capture_try_format(struct fimc_ctx *ctx,
-						u32 *width, u32 *height,
-						u32 *code, u32 *fourcc, int pad)
+static const struct fimc_fmt *fimc_capture_try_format(struct fimc_ctx *ctx,
+						      u32 *width, u32 *height,
+						      u32 *code, u32 *fourcc, int pad)
 {
 	bool rotation = ctx->rotation == 90 || ctx->rotation == 270;
 	struct fimc_dev *fimc = ctx->fimc_dev;
@@ -569,8 +569,8 @@ static struct fimc_fmt *fimc_capture_try_format(struct fimc_ctx *ctx,
 	const struct fimc_pix_limit *pl = var->pix_limit;
 	struct fimc_frame *dst = &ctx->d_frame;
 	u32 depth, min_w, max_w, min_h, align_h = 3;
+	const struct fimc_fmt *ffmt;
 	u32 mask = FMT_FLAGS_CAM;
-	struct fimc_fmt *ffmt;
 
 	/* Conversion from/to JPEG or User Defined format is not supported */
 	if (code && ctx->s_frame.fmt && pad == FIMC_SD_PAD_SOURCE &&
@@ -757,7 +757,7 @@ static struct media_entity *fimc_pipeline_get_head(struct media_entity *me)
  */
 static int fimc_pipeline_try_format(struct fimc_ctx *ctx,
 				    struct v4l2_mbus_framefmt *tfmt,
-				    struct fimc_fmt **fmt_id,
+				    const struct fimc_fmt **fmt_id,
 				    bool set)
 {
 	struct fimc_dev *fimc = ctx->fimc_dev;
@@ -768,8 +768,8 @@ static int fimc_pipeline_try_format(struct fimc_ctx *ctx,
 		       : V4L2_SUBDEV_FORMAT_TRY,
 	};
 	struct v4l2_mbus_framefmt *mf = &sfmt.format;
+	const struct fimc_fmt *ffmt;
 	struct media_entity *me;
-	struct fimc_fmt *ffmt;
 	struct media_pad *pad;
 	int ret, i = 1;
 	u32 fcc;
@@ -903,8 +903,8 @@ static int fimc_cap_g_fmt_mplane(struct file *file, void *fh,
  */
 static int __video_try_or_set_format(struct fimc_dev *fimc,
 				     struct v4l2_format *f, bool try,
-				     struct fimc_fmt **inp_fmt,
-				     struct fimc_fmt **out_fmt)
+				     const struct fimc_fmt **inp_fmt,
+				     const struct fimc_fmt **out_fmt)
 {
 	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
 	struct fimc_vid_cap *vc = &fimc->vid_cap;
@@ -986,7 +986,7 @@ static int fimc_cap_try_fmt_mplane(struct file *file, void *fh,
 				   struct v4l2_format *f)
 {
 	struct fimc_dev *fimc = video_drvdata(file);
-	struct fimc_fmt *out_fmt = NULL, *inp_fmt = NULL;
+	const struct fimc_fmt *out_fmt = NULL, *inp_fmt = NULL;
 
 	return __video_try_or_set_format(fimc, f, true, &inp_fmt, &out_fmt);
 }
@@ -1012,7 +1012,7 @@ static int __fimc_capture_set_format(struct fimc_dev *fimc,
 	struct fimc_ctx *ctx = vc->ctx;
 	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
 	struct fimc_frame *ff = &ctx->d_frame;
-	struct fimc_fmt *inp_fmt = NULL;
+	const struct fimc_fmt *inp_fmt = NULL;
 	int ret, i;
 
 	if (vb2_is_busy(&fimc->vid_cap.vbq))
@@ -1519,7 +1519,7 @@ static int fimc_subdev_set_fmt(struct v4l2_subdev *sd,
 	struct fimc_vid_cap *vc = &fimc->vid_cap;
 	struct fimc_ctx *ctx = vc->ctx;
 	struct fimc_frame *ff;
-	struct fimc_fmt *ffmt;
+	const struct fimc_fmt *ffmt;
 
 	dbg("pad%d: code: 0x%x, %dx%d",
 	    fmt->pad, mf->code, mf->width, mf->height);
@@ -1715,9 +1715,9 @@ static int fimc_register_capture_device(struct fimc_dev *fimc,
 {
 	struct video_device *vfd = &fimc->vid_cap.ve.vdev;
 	struct vb2_queue *q = &fimc->vid_cap.vbq;
-	struct fimc_ctx *ctx;
 	struct fimc_vid_cap *vid_cap;
-	struct fimc_fmt *fmt;
+	const struct fimc_fmt *fmt;
+	struct fimc_ctx *ctx;
 	int ret = -ENOMEM;
 
 	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-core.c b/drivers/media/platform/samsung/exynos4-is/fimc-core.c
index 13b04fda8716..37f4952c7a9b 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-core.c
@@ -33,7 +33,7 @@ static const char *fimc_clocks[MAX_FIMC_CLOCKS] = {
 	"sclk_fimc", "fimc"
 };
 
-static struct fimc_fmt fimc_formats[] = {
+static const struct fimc_fmt fimc_formats[] = {
 	{
 		.fourcc		= V4L2_PIX_FMT_RGB565,
 		.depth		= { 16 },
@@ -180,7 +180,7 @@ static struct fimc_fmt fimc_formats[] = {
 	},
 };
 
-struct fimc_fmt *fimc_get_format(unsigned int index)
+const struct fimc_fmt *fimc_get_format(unsigned int index)
 {
 	if (index >= ARRAY_SIZE(fimc_formats))
 		return NULL;
@@ -752,10 +752,11 @@ void fimc_adjust_mplane_format(const struct fimc_fmt *fmt, u32 width, u32 height
  * @mask: the color flags to match
  * @index: offset in the fimc_formats array, ignored if negative
  */
-struct fimc_fmt *fimc_find_format(const u32 *pixelformat, const u32 *mbus_code,
-				  unsigned int mask, int index)
+const struct fimc_fmt *fimc_find_format(const u32 *pixelformat,
+					const u32 *mbus_code,
+					unsigned int mask, int index)
 {
-	struct fimc_fmt *fmt, *def_fmt = NULL;
+	const struct fimc_fmt *fmt, *def_fmt = NULL;
 	unsigned int i;
 	int id = 0;
 
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-core.h b/drivers/media/platform/samsung/exynos4-is/fimc-core.h
index 261c9aac2f7f..63385152a2ff 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-core.h
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-core.h
@@ -257,7 +257,7 @@ struct fimc_frame {
 	unsigned int		bytesperline[VIDEO_MAX_PLANES];
 	struct fimc_addr	addr;
 	struct fimc_dma_offset	dma_offset;
-	struct fimc_fmt		*fmt;
+	const struct fimc_fmt	*fmt;
 	u8			alpha;
 };
 
@@ -617,9 +617,10 @@ void fimc_alpha_ctrl_update(struct fimc_ctx *ctx);
 void __fimc_get_format(const struct fimc_frame *frame, struct v4l2_format *f);
 void fimc_adjust_mplane_format(const struct fimc_fmt *fmt, u32 width, u32 height,
 			       struct v4l2_pix_format_mplane *pix);
-struct fimc_fmt *fimc_find_format(const u32 *pixelformat, const u32 *mbus_code,
-				  unsigned int mask, int index);
-struct fimc_fmt *fimc_get_format(unsigned int index);
+const struct fimc_fmt *fimc_find_format(const u32 *pixelformat,
+					const u32 *mbus_code,
+					unsigned int mask, int index);
+const struct fimc_fmt *fimc_get_format(unsigned int index);
 
 int fimc_check_scaler_ratio(struct fimc_ctx *ctx, int sw, int sh,
 			    int dw, int dh, int rotation);
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c b/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
index 1918390a2469..e9023f64cfba 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
@@ -314,7 +314,8 @@ static int fimc_m2m_try_fmt_mplane(struct file *file, void *fh,
 	return fimc_try_fmt_mplane(ctx, f);
 }
 
-static void __set_frame_format(struct fimc_frame *frame, struct fimc_fmt *fmt,
+static void __set_frame_format(struct fimc_frame *frame,
+			       const struct fimc_fmt *fmt,
 			       struct v4l2_pix_format_mplane *pixm)
 {
 	int i;
@@ -340,7 +341,7 @@ static int fimc_m2m_s_fmt_mplane(struct file *file, void *fh,
 {
 	struct fimc_ctx *ctx = fh_to_ctx(fh);
 	struct fimc_dev *fimc = ctx->fimc_dev;
-	struct fimc_fmt *fmt;
+	const struct fimc_fmt *fmt;
 	struct vb2_queue *vq;
 	struct fimc_frame *frame;
 	int ret;
@@ -588,7 +589,7 @@ static int fimc_m2m_set_default_format(struct fimc_ctx *ctx)
 			.sizeimage = 800 * 4 * 600,
 		},
 	};
-	struct fimc_fmt *fmt;
+	const struct fimc_fmt *fmt;
 
 	fmt = fimc_find_format(&pixm.pixelformat, NULL, FMT_FLAGS_M2M, 0);
 	if (!fmt)
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:13 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:13 +0100
Subject: [PATCH 09/12] media: fimc-is: constify pointers to v4l2_pix_format_mplane
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-9-krzysztof.kozlowski@linaro.org>

In few places functions do not modify pointed "struct
v4l2_pix_format_mplane", thus the pointer can point to const data for
additional safety and self-documenting intention of the function.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/exynos4-is/fimc-capture.c   | 2 +-
 drivers/media/platform/samsung/exynos4-is/fimc-isp-video.c | 2 +-
 drivers/media/platform/samsung/exynos4-is/fimc-m2m.c       | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
index a3a677a3065f..7c2bcd5be933 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
@@ -1010,7 +1010,7 @@ static int __fimc_capture_set_format(struct fimc_dev *fimc,
 {
 	struct fimc_vid_cap *vc = &fimc->vid_cap;
 	struct fimc_ctx *ctx = vc->ctx;
-	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
+	const struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
 	struct fimc_frame *ff = &ctx->d_frame;
 	const struct fimc_fmt *inp_fmt = NULL;
 	int ret, i;
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-isp-video.c b/drivers/media/platform/samsung/exynos4-is/fimc-isp-video.c
index 8fa26969c411..06c4352562b3 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-isp-video.c
@@ -40,7 +40,7 @@ static int isp_video_capture_queue_setup(struct vb2_queue *vq,
 			unsigned int sizes[], struct device *alloc_devs[])
 {
 	struct fimc_isp *isp = vb2_get_drv_priv(vq);
-	struct v4l2_pix_format_mplane *vid_fmt = &isp->video_capture.pixfmt;
+	const struct v4l2_pix_format_mplane *vid_fmt = &isp->video_capture.pixfmt;
 	const struct fimc_fmt *fmt = isp->video_capture.format;
 	unsigned int wh, i;
 
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c b/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
index e9023f64cfba..e5829a457f3d 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
@@ -316,7 +316,7 @@ static int fimc_m2m_try_fmt_mplane(struct file *file, void *fh,
 
 static void __set_frame_format(struct fimc_frame *frame,
 			       const struct fimc_fmt *fmt,
-			       struct v4l2_pix_format_mplane *pixm)
+			       const struct v4l2_pix_format_mplane *pixm)
 {
 	int i;
 
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:14 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:14 +0100
Subject: [PATCH 10/12] media: fimc-is: constify local pointers to fimc_dma_offset
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-10-krzysztof.kozlowski@linaro.org>

Constify the local variables pointing to "struct fimc_dma_offset" to
annotate the function is not modifying pointed data.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/exynos4-is/fimc-reg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
index dbc43b703324..0ed6e22e6c47 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
@@ -167,7 +167,7 @@ void fimc_hw_set_out_dma(struct fimc_ctx *ctx)
 {
 	struct fimc_dev *dev = ctx->fimc_dev;
 	struct fimc_frame *frame = &ctx->d_frame;
-	struct fimc_dma_offset *offset = &frame->dma_offset;
+	const struct fimc_dma_offset *offset = &frame->dma_offset;
 	const struct fimc_fmt *fmt = frame->fmt;
 	u32 cfg;
 
@@ -421,7 +421,7 @@ void fimc_hw_set_in_dma(struct fimc_ctx *ctx)
 {
 	struct fimc_dev *dev = ctx->fimc_dev;
 	struct fimc_frame *frame = &ctx->s_frame;
-	struct fimc_dma_offset *offset = &frame->dma_offset;
+	const struct fimc_dma_offset *offset = &frame->dma_offset;
 	u32 cfg;
 
 	/* Set the pixel offsets. */
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:15 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:15 +0100
Subject: [PATCH 11/12] media: fimc-is: constify local pointers to fimc_vid_cap
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-11-krzysztof.kozlowski@linaro.org>

Constify the local variables pointing to "struct fimc_vid_cap" to
annotate the function is not modifying pointed data.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/exynos4-is/fimc-reg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
index 0ed6e22e6c47..edff6e5179cf 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
@@ -598,7 +598,7 @@ static const struct mbus_pixfmt_desc pix_desc[] = {
 int fimc_hw_set_camera_source(struct fimc_dev *fimc,
 			      struct fimc_source_info *source)
 {
-	struct fimc_vid_cap *vc = &fimc->vid_cap;
+	const struct fimc_vid_cap *vc = &fimc->vid_cap;
 	struct fimc_frame *f = &vc->ctx->s_frame;
 	u32 bus_width, cfg = 0;
 	int i;
@@ -670,7 +670,7 @@ void fimc_hw_set_camera_offset(struct fimc_dev *fimc, const struct fimc_frame *f
 int fimc_hw_set_camera_type(struct fimc_dev *fimc,
 			    const struct fimc_source_info *source)
 {
-	struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
+	const struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
 	u32 csis_data_alignment = 32;
 	u32 cfg, tmp;
 
-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 03:49:16 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 12:49:16 +0100
Subject: [PATCH 12/12] media: fimc-is: constify local pointers to fimc_frame
In-Reply-To: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
References: <20231224114916.111433-1-krzysztof.kozlowski@linaro.org>
Message-ID: <20231224114916.111433-12-krzysztof.kozlowski@linaro.org>

Constify the local variables pointing to "struct fimc_frame" to annotate
the function is not modifying pointed data.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../platform/samsung/exynos4-is/fimc-capture.c | 18 +++++++++---------
 .../platform/samsung/exynos4-is/fimc-core.c    |  4 ++--
 .../platform/samsung/exynos4-is/fimc-m2m.c     | 10 +++++-----
 .../platform/samsung/exynos4-is/fimc-reg.c     | 18 +++++++++---------
 4 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
index 7c2bcd5be933..ffa4ea21387d 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-capture.c
@@ -180,7 +180,7 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc, int deq_buf)
 	struct fimc_vid_cap *cap = &fimc->vid_cap;
 	struct fimc_pipeline *p = to_fimc_pipeline(cap->ve.pipe);
 	struct v4l2_subdev *csis = p->subdevs[IDX_CSIS];
-	struct fimc_frame *f = &cap->ctx->d_frame;
+	const struct fimc_frame *f = &cap->ctx->d_frame;
 	struct fimc_vid_buffer *v_buf;
 
 	if (test_and_clear_bit(ST_CAPT_SHUT, &fimc->state)) {
@@ -342,7 +342,7 @@ static int queue_setup(struct vb2_queue *vq,
 		       unsigned int sizes[], struct device *alloc_devs[])
 {
 	struct fimc_ctx *ctx = vq->drv_priv;
-	struct fimc_frame *frame = &ctx->d_frame;
+	const struct fimc_frame *frame = &ctx->d_frame;
 	const struct fimc_fmt *fmt = frame->fmt;
 	unsigned long wh = frame->f_width * frame->f_height;
 	int i;
@@ -567,7 +567,7 @@ static const struct fimc_fmt *fimc_capture_try_format(struct fimc_ctx *ctx,
 	struct fimc_dev *fimc = ctx->fimc_dev;
 	const struct fimc_variant *var = fimc->variant;
 	const struct fimc_pix_limit *pl = var->pix_limit;
-	struct fimc_frame *dst = &ctx->d_frame;
+	const struct fimc_frame *dst = &ctx->d_frame;
 	u32 depth, min_w, max_w, min_h, align_h = 3;
 	const struct fimc_fmt *ffmt;
 	u32 mask = FMT_FLAGS_CAM;
@@ -644,7 +644,7 @@ static void fimc_capture_try_selection(struct fimc_ctx *ctx,
 	struct fimc_dev *fimc = ctx->fimc_dev;
 	const struct fimc_variant *var = fimc->variant;
 	const struct fimc_pix_limit *pl = var->pix_limit;
-	struct fimc_frame *sink = &ctx->s_frame;
+	const struct fimc_frame *sink = &ctx->s_frame;
 	u32 max_w, max_h, min_w = 0, min_h = 0, min_sz;
 	u32 align_sz = 0, align_h = 4;
 	u32 max_sc_h, max_sc_v;
@@ -1132,7 +1132,7 @@ static int fimc_pipeline_validate(struct fimc_dev *fimc)
 
 		/* Don't call FIMC subdev operation to avoid nested locking */
 		if (sd == &vc->subdev) {
-			struct fimc_frame *ff = &vc->ctx->s_frame;
+			const struct fimc_frame *ff = &vc->ctx->s_frame;
 			sink_fmt.format.width = ff->f_width;
 			sink_fmt.format.height = ff->f_height;
 			sink_fmt.format.code = ff->fmt ? ff->fmt->mbus_code : 0;
@@ -1158,7 +1158,7 @@ static int fimc_pipeline_validate(struct fimc_dev *fimc)
 		if (sd == p->subdevs[IDX_SENSOR] &&
 		    fimc_user_defined_mbus_fmt(src_fmt.format.code)) {
 			struct v4l2_plane_pix_format plane_fmt[FIMC_MAX_PLANES];
-			struct fimc_frame *frame = &vc->ctx->d_frame;
+			const struct fimc_frame *frame = &vc->ctx->d_frame;
 			unsigned int i;
 
 			ret = fimc_get_sensor_frame_desc(sd, plane_fmt,
@@ -1263,7 +1263,7 @@ static int fimc_cap_g_selection(struct file *file, void *fh,
 {
 	struct fimc_dev *fimc = video_drvdata(file);
 	struct fimc_ctx *ctx = fimc->vid_cap.ctx;
-	struct fimc_frame *f = &ctx->s_frame;
+	const struct fimc_frame *f = &ctx->s_frame;
 
 	if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
 		return -EINVAL;
@@ -1475,7 +1475,7 @@ static int fimc_subdev_get_fmt(struct v4l2_subdev *sd,
 {
 	struct fimc_dev *fimc = v4l2_get_subdevdata(sd);
 	struct fimc_ctx *ctx = fimc->vid_cap.ctx;
-	struct fimc_frame *ff = &ctx->s_frame;
+	const struct fimc_frame *ff = &ctx->s_frame;
 	struct v4l2_mbus_framefmt *mf;
 
 	if (fmt->which == V4L2_SUBDEV_FORMAT_TRY) {
@@ -1582,7 +1582,7 @@ static int fimc_subdev_get_selection(struct v4l2_subdev *sd,
 {
 	struct fimc_dev *fimc = v4l2_get_subdevdata(sd);
 	struct fimc_ctx *ctx = fimc->vid_cap.ctx;
-	struct fimc_frame *f = &ctx->s_frame;
+	const struct fimc_frame *f = &ctx->s_frame;
 	struct v4l2_rect *r = &sel->r;
 	struct v4l2_rect *try_sel;
 
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-core.c b/drivers/media/platform/samsung/exynos4-is/fimc-core.c
index 37f4952c7a9b..1f627f257359 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-core.c
@@ -228,8 +228,8 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
 	const struct fimc_variant *variant = ctx->fimc_dev->variant;
 	struct device *dev = &ctx->fimc_dev->pdev->dev;
 	struct fimc_scaler *sc = &ctx->scaler;
-	struct fimc_frame *s_frame = &ctx->s_frame;
-	struct fimc_frame *d_frame = &ctx->d_frame;
+	const struct fimc_frame *s_frame = &ctx->s_frame;
+	const struct fimc_frame *d_frame = &ctx->d_frame;
 	int tx, ty, sx, sy;
 	int ret;
 
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c b/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
index e5829a457f3d..199997eec1cc 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-m2m.c
@@ -170,7 +170,7 @@ static int fimc_queue_setup(struct vb2_queue *vq,
 			    unsigned int sizes[], struct device *alloc_devs[])
 {
 	struct fimc_ctx *ctx = vb2_get_drv_priv(vq);
-	struct fimc_frame *f;
+	const struct fimc_frame *f;
 	int i;
 
 	f = ctx_get_frame(ctx, vq->type);
@@ -192,7 +192,7 @@ static int fimc_queue_setup(struct vb2_queue *vq,
 static int fimc_buf_prepare(struct vb2_buffer *vb)
 {
 	struct fimc_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
-	struct fimc_frame *frame;
+	const struct fimc_frame *frame;
 	int i;
 
 	frame = ctx_get_frame(ctx, vb->vb2_queue->type);
@@ -252,7 +252,7 @@ static int fimc_m2m_g_fmt_mplane(struct file *file, void *fh,
 				 struct v4l2_format *f)
 {
 	struct fimc_ctx *ctx = fh_to_ctx(fh);
-	struct fimc_frame *frame = ctx_get_frame(ctx, f->type);
+	const struct fimc_frame *frame = ctx_get_frame(ctx, f->type);
 
 	if (IS_ERR(frame))
 		return PTR_ERR(frame);
@@ -379,7 +379,7 @@ static int fimc_m2m_g_selection(struct file *file, void *fh,
 				struct v4l2_selection *s)
 {
 	struct fimc_ctx *ctx = fh_to_ctx(fh);
-	struct fimc_frame *frame;
+	const struct fimc_frame *frame;
 
 	frame = ctx_get_frame(ctx, s->type);
 	if (IS_ERR(frame))
@@ -429,7 +429,7 @@ static int fimc_m2m_try_selection(struct fimc_ctx *ctx,
 				  struct v4l2_selection *s)
 {
 	struct fimc_dev *fimc = ctx->fimc_dev;
-	struct fimc_frame *f;
+	const struct fimc_frame *f;
 	u32 min_size, halign, depth = 0;
 	int i;
 
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
index edff6e5179cf..b4ee39e471e7 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-reg.c
@@ -105,7 +105,7 @@ void fimc_hw_set_target_format(struct fimc_ctx *ctx)
 {
 	u32 cfg;
 	struct fimc_dev *dev = ctx->fimc_dev;
-	struct fimc_frame *frame = &ctx->d_frame;
+	const struct fimc_frame *frame = &ctx->d_frame;
 
 	dbg("w= %d, h= %d color: %d", frame->width,
 	    frame->height, frame->fmt->color);
@@ -147,7 +147,7 @@ void fimc_hw_set_target_format(struct fimc_ctx *ctx)
 static void fimc_hw_set_out_dma_size(struct fimc_ctx *ctx)
 {
 	struct fimc_dev *dev = ctx->fimc_dev;
-	struct fimc_frame *frame = &ctx->d_frame;
+	const struct fimc_frame *frame = &ctx->d_frame;
 	u32 cfg;
 
 	cfg = (frame->f_height << 16) | frame->f_width;
@@ -166,7 +166,7 @@ static void fimc_hw_set_out_dma_size(struct fimc_ctx *ctx)
 void fimc_hw_set_out_dma(struct fimc_ctx *ctx)
 {
 	struct fimc_dev *dev = ctx->fimc_dev;
-	struct fimc_frame *frame = &ctx->d_frame;
+	const struct fimc_frame *frame = &ctx->d_frame;
 	const struct fimc_dma_offset *offset = &frame->dma_offset;
 	const struct fimc_fmt *fmt = frame->fmt;
 	u32 cfg;
@@ -248,8 +248,8 @@ static void fimc_hw_set_scaler(struct fimc_ctx *ctx)
 {
 	struct fimc_dev *dev = ctx->fimc_dev;
 	struct fimc_scaler *sc = &ctx->scaler;
-	struct fimc_frame *src_frame = &ctx->s_frame;
-	struct fimc_frame *dst_frame = &ctx->d_frame;
+	const struct fimc_frame *src_frame = &ctx->s_frame;
+	const struct fimc_frame *dst_frame = &ctx->d_frame;
 
 	u32 cfg = readl(dev->regs + FIMC_REG_CISCCTRL);
 
@@ -388,7 +388,7 @@ void fimc_hw_set_effect(struct fimc_ctx *ctx)
 void fimc_hw_set_rgb_alpha(struct fimc_ctx *ctx)
 {
 	struct fimc_dev *dev = ctx->fimc_dev;
-	struct fimc_frame *frame = &ctx->d_frame;
+	const struct fimc_frame *frame = &ctx->d_frame;
 	u32 cfg;
 
 	if (!(frame->fmt->flags & FMT_HAS_ALPHA))
@@ -403,7 +403,7 @@ void fimc_hw_set_rgb_alpha(struct fimc_ctx *ctx)
 static void fimc_hw_set_in_dma_size(struct fimc_ctx *ctx)
 {
 	struct fimc_dev *dev = ctx->fimc_dev;
-	struct fimc_frame *frame = &ctx->s_frame;
+	const struct fimc_frame *frame = &ctx->s_frame;
 	u32 cfg_o = 0;
 	u32 cfg_r = 0;
 
@@ -420,7 +420,7 @@ static void fimc_hw_set_in_dma_size(struct fimc_ctx *ctx)
 void fimc_hw_set_in_dma(struct fimc_ctx *ctx)
 {
 	struct fimc_dev *dev = ctx->fimc_dev;
-	struct fimc_frame *frame = &ctx->s_frame;
+	const struct fimc_frame *frame = &ctx->s_frame;
 	const struct fimc_dma_offset *offset = &frame->dma_offset;
 	u32 cfg;
 
@@ -599,7 +599,7 @@ int fimc_hw_set_camera_source(struct fimc_dev *fimc,
 			      struct fimc_source_info *source)
 {
 	const struct fimc_vid_cap *vc = &fimc->vid_cap;
-	struct fimc_frame *f = &vc->ctx->s_frame;
+	const struct fimc_frame *f = &vc->ctx->s_frame;
 	u32 bus_width, cfg = 0;
 	int i;
 
-- 
2.34.1



From antonio.borneo at foss.st.com  Sun Dec 24 03:59:58 2023
From: antonio.borneo at foss.st.com (Antonio Borneo)
Date: Sun, 24 Dec 2023 12:59:58 +0100
Subject: [Linux-stm32] [PATCH 12/13] irqchip/stm32-exti: Convert to
 platform remove callback returning void
In-Reply-To: <ac551b89025bafadce05102b94596f8cd3564a32.1703284359.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703284359.git.u.kleine-koenig@pengutronix.de>
	 <ac551b89025bafadce05102b94596f8cd3564a32.1703284359.git.u.kleine-koenig@pengutronix.de>
Message-ID: <0e586f3d05a03bd5d9a8bfead55162e14a6aa4de.camel@foss.st.com>

On Fri, 2023-12-22 at 23:50 +0100, Uwe Kleine-K?nig wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> 
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Reviewed-by: Antonio Borneo <antonio.borneo at foss.st.com>

Regards,
Antonio

> ---
> ?drivers/irqchip/irq-stm32-exti.c | 5 ++---
> ?1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
> index 971240e2e31b..c61a97caafc9 100644
> --- a/drivers/irqchip/irq-stm32-exti.c
> +++ b/drivers/irqchip/irq-stm32-exti.c
> @@ -898,10 +898,9 @@ static void stm32_exti_remove_irq(void *data)
> ????????irq_domain_remove(domain);
> ?}
> ?
> -static int stm32_exti_remove(struct platform_device *pdev)
> +static void stm32_exti_remove(struct platform_device *pdev)
> ?{
> ????????stm32_exti_h_syscore_deinit();
> -???????return 0;
> ?}
> ?
> ?static int stm32_exti_probe(struct platform_device *pdev)
> @@ -991,7 +990,7 @@ MODULE_DEVICE_TABLE(of, stm32_exti_ids);
> ?
> ?static struct platform_driver stm32_exti_driver = {
> ????????.probe??????????= stm32_exti_probe,
> -???????.remove?????????= stm32_exti_remove,
> +???????.remove_new?????= stm32_exti_remove,
> ????????.driver?????????= {
> ????????????????.name???= "stm32_exti",
> ????????????????.of_match_table = stm32_exti_ids,



From lkp at intel.com  Sun Dec 24 04:06:43 2023
From: lkp at intel.com (kernel test robot)
Date: Sun, 24 Dec 2023 20:06:43 +0800
Subject: [soc:for-next] BUILD SUCCESS
 6c473546063dbef63aebd4c29401d17274e46b7b
Message-ID: <202312242040.WqtA39Ej-lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 6c473546063dbef63aebd4c29401d17274e46b7b  soc: document merges

elapsed time: 2824m

configs tested: 93
configs skipped: 0

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                               defconfig   gcc  
arc                               allnoconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20231224   gcc  
arc                   randconfig-002-20231224   gcc  
arc                        vdk_hs38_defconfig   gcc  
arm                               allnoconfig   gcc  
arm                                 defconfig   clang
arm                   randconfig-001-20231224   gcc  
arm                   randconfig-002-20231224   gcc  
arm                   randconfig-003-20231224   gcc  
arm                   randconfig-004-20231224   gcc  
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20231224   gcc  
arm64                 randconfig-002-20231224   gcc  
arm64                 randconfig-003-20231224   gcc  
arm64                 randconfig-004-20231224   gcc  
csky                              allnoconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20231224   gcc  
csky                  randconfig-002-20231224   gcc  
hexagon                           allnoconfig   clang
hexagon                             defconfig   clang
hexagon               randconfig-001-20231224   clang
hexagon               randconfig-002-20231224   clang
i386                             allmodconfig   clang
i386                              allnoconfig   clang
i386                             allyesconfig   clang
i386         buildonly-randconfig-001-20231224   gcc  
i386         buildonly-randconfig-002-20231224   gcc  
i386         buildonly-randconfig-003-20231224   gcc  
i386         buildonly-randconfig-004-20231224   gcc  
i386         buildonly-randconfig-005-20231224   gcc  
i386         buildonly-randconfig-006-20231224   gcc  
i386                                defconfig   gcc  
i386                  randconfig-001-20231224   gcc  
i386                  randconfig-002-20231224   gcc  
i386                  randconfig-003-20231224   gcc  
i386                  randconfig-004-20231224   gcc  
i386                  randconfig-005-20231224   gcc  
i386                  randconfig-006-20231224   gcc  
i386                  randconfig-011-20231224   clang
i386                  randconfig-012-20231224   clang
i386                  randconfig-013-20231224   clang
i386                  randconfig-014-20231224   clang
i386                  randconfig-015-20231224   clang
i386                  randconfig-016-20231224   clang
loongarch                         allnoconfig   gcc  
loongarch             randconfig-001-20231224   gcc  
loongarch             randconfig-002-20231224   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
nios2                 randconfig-001-20231224   gcc  
nios2                 randconfig-002-20231224   gcc  
openrisc                         allyesconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                randconfig-001-20231224   gcc  
parisc                randconfig-002-20231224   gcc  
powerpc                          allmodconfig   clang
powerpc               randconfig-001-20231224   gcc  
powerpc               randconfig-002-20231224   gcc  
powerpc               randconfig-003-20231224   gcc  
powerpc64             randconfig-001-20231224   gcc  
powerpc64             randconfig-002-20231224   gcc  
powerpc64             randconfig-003-20231224   gcc  
riscv                 randconfig-001-20231224   gcc  
riscv                 randconfig-002-20231224   gcc  
s390                             allmodconfig   gcc  
s390                             allyesconfig   gcc  
s390                  randconfig-001-20231224   clang
s390                  randconfig-002-20231224   clang
sh                               allmodconfig   gcc  
sh                               allyesconfig   gcc  
sh                    randconfig-001-20231224   gcc  
sh                    randconfig-002-20231224   gcc  
sparc64               randconfig-001-20231224   gcc  
sparc64               randconfig-002-20231224   gcc  
um                    randconfig-001-20231224   gcc  
um                    randconfig-002-20231224   gcc  
x86_64                            allnoconfig   gcc  
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20231224   gcc  
x86_64       buildonly-randconfig-002-20231224   gcc  
x86_64       buildonly-randconfig-003-20231224   gcc  
x86_64       buildonly-randconfig-004-20231224   gcc  
x86_64       buildonly-randconfig-005-20231224   gcc  
x86_64                              defconfig   gcc  
x86_64                          rhel-8.3-rust   clang
xtensa                randconfig-001-20231224   gcc  
xtensa                randconfig-002-20231224   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From josua at solid-run.com  Sun Dec 24 04:39:14 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 12:39:14 +0000
Subject: [PATCH 1/5] arm: dts: marvell: clearfog-gtr: add board-specific
 compatible strings
In-Reply-To: <2d2535fb-185c-4663-a012-46a93d2d17bb@linaro.org>
References: <20231223212930.14624-1-josua@solid-run.com>
 <20231223212930.14624-2-josua@solid-run.com>
 <44a1dab9-5fa9-4128-a5e5-c0deeeeebaab@linaro.org>
 <7a8f0c19-096c-4d29-a8b5-431f60601876@solid-run.com>
 <2d2535fb-185c-4663-a012-46a93d2d17bb@linaro.org>
Message-ID: <d0391ef8-8d4d-4b0d-b841-ec4589290bcd@solid-run.com>

Am 24.12.23 um 11:52 schrieb Krzysztof Kozlowski:
> On 24/12/2023 11:16, Josua Mayer wrote:
>> Am 24.12.23 um 10:10 schrieb Krzysztof Kozlowski:
>>> On 23/12/2023 22:29, Josua Mayer wrote:
>>>> Most arm board have a board-specific compatible string that allows e.g.
>>>> userspace to match specific firmware variants or apply specific
>>>> policies.
>>>>
>>>> Add board-specific properties to both variants of the Clearfog GTR:
>>>> - solidrun,clearfog-gtr-l8
>>>> - solidrun,clearfog-gtr-s4
>>>>
>>>> Introduction of a common parent (e.g. "solidrun,clearfog-gtr") is
>>>> omitted for brevity.
>>>> Since announcement of the two products no additional variants were added
>>>> it is assumed that there will always be just two.
>>>>
>>>> Signed-off-by: Josua Mayer <josua at solid-run.com>
>>>> ---
>>>>    arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 1 +
>>>>    arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts | 1 +
>>>>    2 files changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
>>>> index 1990f7d0cc79..ae921a674c93 100644
>>>> --- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
>>>> +++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
>>>> @@ -4,6 +4,7 @@
>>>>    
>>>>    / {
>>>>    	model = "SolidRun Clearfog GTR L8";
>>>> +	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385", "marvell,armada380";
>>> Please run scripts/checkpatch.pl and fix reported warnings. Some
>>> warnings can be ignored, but the code here looks like it needs a fix.
>>> Feel free to get in touch if the warning is not clear.
>>>
>>> I don't see them being documented.
>> Yes, checkpatch warned about that specifially, but I am not sure how to
>> proceed.
>> The armada-38x dt bindings documentation is stil in text format, and
>> doesn't document any board:
>>
>> Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
> There was some work in progress, AFAIR. This should be solved before
> bringing more undocumented compatibles.

Okay. Since armada-38x.txt is small enough,
I have drafted conversion to yaml and new bindings.
Will submit them as part of a v2 after validating other changes.

Thanks!

>
> Best regards,
> Krzysztof
>


From othacehe at gnu.org  Sun Dec 24 04:41:12 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Sun, 24 Dec 2023 13:41:12 +0100
Subject: [PATCH v3 0/2] Add Variscite VAR-SOM-MX93 support
Message-ID: <20231224124114.31119-1-othacehe@gnu.org>

Hey,

This is a v3 adding support for the Variscite VAR-SOM-MX93 SoM on Symphony
Board.

Thanks,

Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
Changes in v3:
- Fix indentation on a continuation line
- Remove useless nodes and include

Changes in v2:
- Remove "nxp,pca9451a" block
- Fixed checkpatch warnings
- Fixed dtb_checks warnings
- Introduce dt-bindings documentation

v2: https://lore.kernel.org/linux-devicetree/20231223205230.10534-1-othacehe at gnu.org/T/#t

---
Mathieu Othacehe (2):
  dt-bindings: arm: fsl: Add VAR-SOM-MX93 with Symphony
  arm64: dts: imx93-var-som: Add Variscite VAR-SOM-MX93

 .../devicetree/bindings/arm/fsl.yaml          |   6 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-var-som-symphony.dts  | 306 ++++++++++++++++++
 .../boot/dts/freescale/imx93-var-som.dtsi     | 111 +++++++
 4 files changed, 424 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som.dtsi

-- 
2.41.0



From othacehe at gnu.org  Sun Dec 24 04:41:13 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Sun, 24 Dec 2023 13:41:13 +0100
Subject: [PATCH v3 1/2] dt-bindings: arm: fsl: Add VAR-SOM-MX93 with Symphony
In-Reply-To: <20231224124114.31119-1-othacehe@gnu.org>
References: <20231224124114.31119-1-othacehe@gnu.org>
Message-ID: <20231224124114.31119-2-othacehe@gnu.org>

Add support for Variscite i.MX93 VAR-SOM-MX93 SoM with Symphony board.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
 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 228dcc5c7d6f..27936edfe054 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1275,6 +1275,12 @@ properties:
           - const: tq,imx93-tqma9352        # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM
           - const: fsl,imx93
 
+      - description: Variscite VAR-SOM-MX93 based boards
+        items:
+          - const: variscite,var-som-mx93-symphony
+          - const: variscite,var-som-mx93
+          - const: fsl,imx93
+
       - description:
           Freescale Vybrid Platform Device Tree Bindings
 
-- 
2.41.0



From othacehe at gnu.org  Sun Dec 24 04:41:14 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Sun, 24 Dec 2023 13:41:14 +0100
Subject: [PATCH v3 2/2] arm64: dts: imx93-var-som: Add Variscite VAR-SOM-MX93
In-Reply-To: <20231224124114.31119-1-othacehe@gnu.org>
References: <20231224124114.31119-1-othacehe@gnu.org>
Message-ID: <20231224124114.31119-3-othacehe@gnu.org>

Add DTSI for Variscite VAR-SOM-MX93 System on Module and DTS for Variscite
VAR-SOM-MX93 on Symphony evaluation board.

This version comes with:
- NXP i.MX 93 Dual, 1.7GHz, Cortex-A55 + Cortex-M33
- 2 GB of RAM
- 16GB eMMC
- 802.11ax/ac/a/b/g/n WiFi with 5.3 Bluetooth
- CAN bus
- Audio codec

Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-var-som-symphony.dts  | 306 ++++++++++++++++++
 .../boot/dts/freescale/imx93-var-som.dtsi     | 111 +++++++
 3 files changed, 418 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2e027675d7bb..a6f1700961e3 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -203,6 +203,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxca.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
 
 imx8mm-venice-gw72xx-0x-imx219-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-imx219.dtbo
 imx8mm-venice-gw72xx-0x-rpidsi-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rpidsi.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
new file mode 100644
index 000000000000..08efdf45693b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 NXP
+ * Copyright 2023 Variscite Ltd.
+ */
+
+/dts-v1/;
+
+#include "imx93-var-som.dtsi"
+
+/{
+	model = "Variscite VAR-SOM-MX93 on Symphony evaluation board";
+	compatible = "variscite,var-som-mx93-symphony",
+		     "variscite,var-som-mx93", "fsl,imx93";
+
+	aliases {
+		ethernet1 = &fec;
+	};
+
+	chosen {
+		stdout-path = &lpuart1;
+	};
+
+	/*
+	 * Needed only for Symphony <= v1.5
+	 */
+	reg_fec_phy: regulator-fec-phy {
+		compatible = "regulator-fixed";
+		regulator-name = "fec-phy";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-enable-ramp-delay = <20000>;
+		gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	reg_usdhc2_vmmc: regulator-usdhc2 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+		regulator-name = "VSD_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+		off-on-delay-us = <20000>;
+		enable-active-high;
+	};
+
+	reg_vref_1v8: regulator-adc-vref {
+		compatible = "regulator-fixed";
+		regulator-name = "vref_1v8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		ethosu_mem: ethosu-region at 88000000 {
+			compatible = "shared-dma-pool";
+			reusable;
+			reg = <0x0 0x88000000 0x0 0x8000000>;
+		};
+
+		vdev0vring0: vdev0vring0 at 87ee0000 {
+			reg = <0 0x87ee0000 0 0x8000>;
+			no-map;
+		};
+
+		vdev0vring1: vdev0vring1 at 87ee8000 {
+			reg = <0 0x87ee8000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring0: vdev1vring0 at 87ef0000 {
+			reg = <0 0x87ef0000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring1: vdev1vring1 at 87ef8000 {
+			reg = <0 0x87ef8000 0 0x8000>;
+			no-map;
+		};
+
+		rsc_table: rsc-table at 2021f000 {
+			reg = <0 0x2021f000 0 0x1000>;
+			no-map;
+		};
+
+		vdevbuffer: vdevbuffer at 87f00000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x87f00000 0 0x100000>;
+			no-map;
+		};
+
+		ele_reserved: ele-reserved at 87de0000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x87de0000 0 0x100000>;
+			no-map;
+		};
+	};
+};
+
+/* Use external instead of internal RTC*/
+&bbnsm_rtc {
+	status = "disabled";
+};
+
+&eqos {
+	mdio {
+		ethphy1: ethernet-phy at 5 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <5>;
+			qca,disable-smarteee;
+			eee-broken-1000t;
+			reset-gpios = <&pca9534 5 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <20000>;
+			vddio-supply = <&vddio1>;
+
+			vddio1: vddio-regulator {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+			};
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy1>;
+	phy-supply = <&reg_fec_phy>;
+	status = "okay";
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_fec: fecgrp {
+		fsl,pins = <
+			MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0		0x57e
+			MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1		0x57e
+			MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2		0x57e
+			MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3		0x57e
+			MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC		0x5fe
+			MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL	0x57e
+			MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0		0x57e
+			MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1		0x57e
+			MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2		0x57e
+			MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3		0x57e
+			MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC		0x5fe
+			MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL	0x57e
+		>;
+	};
+
+	pinctrl_flexcan1: flexcan1grp {
+		fsl,pins = <
+			MX93_PAD_PDM_CLK__CAN1_TX                       0x139e
+			MX93_PAD_PDM_BIT_STREAM0__CAN1_RX               0x139e
+		>;
+	};
+
+	pinctrl_lpi2c1: lpi2c1grp {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__LPI2C1_SCL			0x40000b9e
+			MX93_PAD_I2C1_SDA__LPI2C1_SDA			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c1_gpio: lpi2c1gpiogrp {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__GPIO1_IO00			0x31e
+			MX93_PAD_I2C1_SDA__GPIO1_IO01			0x31e
+		>;
+	};
+
+	pinctrl_lpi2c5: lpi2c5grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO23__LPI2C5_SCL			0x40000b9e
+			MX93_PAD_GPIO_IO22__LPI2C5_SDA			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c5_gpio: lpi2c5gpiogrp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO23__GPIO2_IO23			0x31e
+			MX93_PAD_GPIO_IO22__GPIO2_IO22			0x31e
+		>;
+	};
+
+	pinctrl_pca9534: pca9534grp {
+		fsl,pins = <
+			MX93_PAD_CCM_CLKO1__GPIO3_IO26		0x31e
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX93_PAD_UART1_RXD__LPUART1_RX			0x31e
+			MX93_PAD_UART1_TXD__LPUART1_TX			0x31e
+		>;
+	};
+
+	pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO18__GPIO2_IO18		0x31e
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX93_PAD_SD2_CLK__USDHC2_CLK		0x15fe
+			MX93_PAD_SD2_CMD__USDHC2_CMD		0x13fe
+			MX93_PAD_SD2_DATA0__USDHC2_DATA0	0x13fe
+			MX93_PAD_SD2_DATA1__USDHC2_DATA1	0x13fe
+			MX93_PAD_SD2_DATA2__USDHC2_DATA2	0x13fe
+			MX93_PAD_SD2_DATA3__USDHC2_DATA3	0x13fe
+			MX93_PAD_SD2_VSELECT__USDHC2_VSELECT	0x51e
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+		fsl,pins = <
+			MX93_PAD_SD2_CD_B__GPIO3_IO00		0x31e
+		>;
+	};
+};
+
+&lpi2c1 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c1>;
+	pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
+	pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
+	scl-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	/* DS1337 RTC module */
+	rtc at 68 {
+		compatible = "dallas,ds1337";
+		reg = <0x68>;
+	};
+};
+
+&lpi2c5 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c5>;
+	pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+	pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
+	scl-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	pca9534: gpio at 20 {
+		compatible = "nxp,pca9534";
+		reg = <0x20>;
+		gpio-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9534>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+		#gpio-cells = <2>;
+		wakeup-source;
+	};
+};
+
+/* Console */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
+	vmmc-supply = <&reg_usdhc2_vmmc>;
+	bus-width = <4>;
+	status = "okay";
+	no-sdio;
+	no-mmc;
+};
+
+/* Watchdog */
+&wdog3 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
new file mode 100644
index 000000000000..6c77b886666b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 NXP
+ * Copyright 2023 Variscite Ltd.
+ */
+
+/dts-v1/;
+
+#include "imx93.dtsi"
+
+/{
+	model = "Variscite VAR-SOM-MX93 module";
+	compatible = "variscite,var-som-mx93", "fsl,imx93";
+
+	mmc_pwrseq: mmc-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		post-power-on-delay-ms = <100>;
+		power-off-delay-us = <10000>;
+		reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>,	/* WIFI_RESET */
+			      <&gpio3 7 GPIO_ACTIVE_LOW>;	/* WIFI_PWR_EN */
+	};
+
+	reg_eqos_phy: regulator-eqos-phy {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_eqos_phy>;
+		regulator-name = "eth_phy_pwr";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		startup-delay-us = <100000>;
+		regulator-always-on;
+	};
+};
+
+&eqos {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_eqos>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+	phy-supply = <&reg_eqos_phy>;
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clock-frequency = <1000000>;
+
+		ethphy0: ethernet-phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
+			eee-broken-1000t;
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl_eqos: eqosgrp {
+		fsl,pins = <
+			MX93_PAD_ENET1_MDC__ENET_QOS_MDC			0x57e
+			MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO			0x57e
+			MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0			0x57e
+			MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1			0x57e
+			MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2			0x57e
+			MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3			0x57e
+			MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK	0x5fe
+			MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL		0x57e
+			MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0			0x57e
+			MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1			0x57e
+			MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2			0x57e
+			MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3			0x57e
+			MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK	0x5fe
+			MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL		0x57e
+		>;
+	};
+
+	pinctrl_reg_eqos_phy: regeqosgrp {
+		fsl,pins = <
+			MX93_PAD_UART2_TXD__GPIO1_IO07			0x51e
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX93_PAD_SD1_CLK__USDHC1_CLK		0x15fe
+			MX93_PAD_SD1_CMD__USDHC1_CMD		0x13fe
+			MX93_PAD_SD1_DATA0__USDHC1_DATA0	0x13fe
+			MX93_PAD_SD1_DATA1__USDHC1_DATA1	0x13fe
+			MX93_PAD_SD1_DATA2__USDHC1_DATA2	0x13fe
+			MX93_PAD_SD1_DATA3__USDHC1_DATA3	0x13fe
+			MX93_PAD_SD1_DATA4__USDHC1_DATA4	0x13fe
+			MX93_PAD_SD1_DATA5__USDHC1_DATA5	0x13fe
+			MX93_PAD_SD1_DATA6__USDHC1_DATA6	0x13fe
+			MX93_PAD_SD1_DATA7__USDHC1_DATA7	0x13fe
+			MX93_PAD_SD1_STROBE__USDHC1_STROBE	0x15fe
+		>;
+	};
+};
+
+/* eMMC */
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1>;
+	pinctrl-2 = <&pinctrl_usdhc1>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
-- 
2.41.0



From zhangn1985 at outlook.com  Sun Dec 24 04:44:35 2023
From: zhangn1985 at outlook.com (Zhang Ning)
Date: Sun, 24 Dec 2023 20:44:35 +0800
Subject: [PATCH] arm64: boot: dts: rockchip: Fix led pinctrl of lubancat 1
In-Reply-To: <20231224075001.3032214-1-andyshrk@163.com>
References: <20231224075001.3032214-1-andyshrk@163.com>
Message-ID: <OS0P286MB064153B62ECBBEED9C16755DCD9AA@OS0P286MB0641.JPNP286.PROD.OUTLOOK.COM>

O Sun, Dec 24, 2023 at 03:50:01PM +0800, Andy Yan wrote:
> According to the sch, the gpio control sys_led
> is GPIO0_C5.
> 
> Fixes: 8d94da58de53 ("arm64: dts: rockchip: Add EmbedFire LubanCat 1")
>Reported-by: zhangn1985 at outlook.com

Reported-by: Zhang Ning <zhangn1985 at outlook.com>

in case if have rev2.

> Closes: https://lore.kernel.org/linux-rockchip/OS0P286MB06412D049D8BF7B063D41350CD95A at OS0P286MB0641.JPNP286.PROD.OUTLOOK.COM/T/#u
> Signed-off-by: Andy Yan <andyshrk at 163.com>
> ---
> 
>  arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts b/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts
> index 1c6d83b47cd2..6ecdf5d28339 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts
> @@ -455,7 +455,7 @@ &pcie2x1 {
>  &pinctrl {
>  	leds {
>  		sys_led_pin: sys-status-led-pin {
> -			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>;
> +			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
>  		};
>  	};
>  
> -- 
> 2.34.1
> 


From cniedermaier at dh-electronics.com  Sun Dec 24 04:53:14 2023
From: cniedermaier at dh-electronics.com (Christoph Niedermaier)
Date: Sun, 24 Dec 2023 12:53:14 +0000
Subject: [PATCH] serial: imx: Ensure that imx_uart_rs485_config() is
 called with enabled clock
In-Reply-To: <20231224123254.GA15377@wunner.de>
References: <20231222221101.2380-1-cniedermaier@dh-electronics.com>
 <20231224123254.GA15377@wunner.de>
Message-ID: <149f4e1020954e2e91fe1cde0e4afebc@dh-electronics.com>

From: Lukas Wunner [mailto:lukas at wunner.de]
Sent: Sunday, December 24, 2023 1:33 PM
> On Fri, Dec 22, 2023 at 11:11:01PM +0100, Christoph Niedermaier wrote:
>> There are register accesses in the function imx_uart_rs485_config(). The
>> clock must be enabled for these accesses. This was ensured by calling it
>> via the function uart_rs485_config() in the probe() function within the
>> range where the clock is enabled. With the commit 7c7f9bc986e6 ("serial:
>> Deassert Transmit Enable on probe in driver-specific way") it was removed
>> from the probe() function and is now only called through the function
>> uart_add_one_port() which is located at the end of the probe() function.
>> But the clock is already switched off in this area. To ensure that the
>> clock is enabled during register access, move the disabling of the clock
>> to the very end of the probe() function.
> 
> Thanks for catching this and sorry for the breakage.
> 
> 
>> @@ -2467,7 +2465,11 @@ static int imx_uart_probe(struct platform_device *pdev)
>>
>>       platform_set_drvdata(pdev, sport);
>>
>> -     return uart_add_one_port(&imx_uart_uart_driver, &sport->port);
>> +     ret = uart_add_one_port(&imx_uart_uart_driver, &sport->port);
>> +
>> +     clk_disable_unprepare(sport->clk_ipg);
>> +
>> +     return ret;
>>  }
> 
> There are a bunch of return statements in the "if (txirq > 0) ... else"
> clause a little further up.  You need to add a goto label in front of
> the "clk_disable_unprepare()" and change the return statements to gotos
> to avoid leaking enabled clocks in those error paths.

You are right. I overlooked that.
I will fix that in version 2.
 

Thanks and Regards
Christoph

From josua at solid-run.com  Sun Dec 24 06:37:41 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:37:41 +0100
Subject: [PATCH v2 0/8] arm: dts: marvell: clearfog-gtr: miscellaneous enhancements
Message-ID: <20231224143750.5604-1-josua@solid-run.com>

Dear Maintainers,

The initially merged device-tree for Clearfog GTR devices contained
various subtle mistakes and omissions:

- missing board-specific compatible strings
- missing pinctrl entries
- missing second sfp connector
- invalid sfp loss-of-signal gpio
- mismatch of labels between dsa ports and enclosure

Most notably this had caused functional issues with the sfp connectors.

This patch-set first converts the armada-38x dt-bindings to yaml.
New bindings are added specifically for the Clearfog GTR boards,
and for the already in-place clearfog base and pro boards' compatible strings.

Secondly pinctrl nodes are added for all referenced gpios for independence
from bootloader defaults. U-Boot is shared between armada-388 clearfog,
and armada-385 clearfog gtr.

Further remove an invalid io from the first sfp connector description,
and add descriptions for the secondary sfp connector which is driven
by dsa switch port number 9.

Finally labels of dsa switch ports were updated to match the enclosure.
That patch is not suitable for stable.

Josua Mayer (8):
  dt-bindings: marvell: a38x: convert the soc compatibles description to
    yaml
  dt-bindings: marvell: a38x: add solidrun armada 385 clearfog gtr
    boards
  dt-bindings: marvell: a38x: add solidrun armada 388 clearfog boards
  arm: dts: marvell: clearfog-gtr: add board-specific compatible strings
  arm: dts: marvell: clearfog-gtr: sort pinctrl nodes alphabetically
  arm: dts: marvell: clearfog-gtr: add missing pinctrl for all used
    gpios
  arm: dts: marvell: clearfog-gtr-l8: add support for second sfp
    connector
  arm: dts: marvell: clearfog-gtr-l8: align port numbers with enclosure

 .../bindings/arm/marvell/armada-38x.txt       | 27 ------
 .../bindings/arm/marvell/armada-38x.yaml      | 61 ++++++++++++++
 .../marvell/armada-385-clearfog-gtr-l8.dts    | 38 +++++++--
 .../marvell/armada-385-clearfog-gtr-s4.dts    |  2 +
 .../dts/marvell/armada-385-clearfog-gtr.dtsi  | 84 ++++++++++++++-----
 5 files changed, 155 insertions(+), 57 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml

Cc: Andrew Lunn <andrew at lunn.ch> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
Cc: Gregory Clement <gregory.clement at bootlin.com> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
Cc: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> (maintainer:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...)
Cc: Rob Herring <robh+dt at kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: Conor Dooley <conor+dt at kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)

-- 
2.35.3



From josua at solid-run.com  Sun Dec 24 06:37:42 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:37:42 +0100
Subject: [PATCH v2 1/8] dt-bindings: marvell: a38x: convert the soc compatibles description to yaml
In-Reply-To: <20231224143750.5604-1-josua@solid-run.com>
References: <20231224143750.5604-1-josua@solid-run.com>
Message-ID: <20231224143750.5604-2-josua@solid-run.com>

Convert the existing txt binding for armada-38x socs to DT schema
format.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../bindings/arm/marvell/armada-38x.txt       | 27 ---------------
 .../bindings/arm/marvell/armada-38x.yaml      | 33 +++++++++++++++++++
 2 files changed, 33 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
deleted file mode 100644
index 202953f1887e..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Marvell Armada 38x Platforms Device Tree Bindings
--------------------------------------------------
-
-Boards with a SoC of the Marvell Armada 38x family shall have the
-following property:
-
-Required root node property:
-
- - compatible: must contain "marvell,armada380"
-
-In addition, boards using the Marvell Armada 385 SoC shall have the
-following property before the previous one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada385"
-
-In addition, boards using the Marvell Armada 388 SoC shall have the
-following property before the previous one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada388"
-
-Example:
-
-compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
new file mode 100644
index 000000000000..5af222e6db18
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/armada-38x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 38x Platforms
+
+maintainers:
+  - Gregory CLEMENT <gregory.clement at bootlin.com>
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+
+      - description: Armada 380 SoC
+        items:
+          - const: marvell,armada380
+
+      - description: Armada 385 SoC
+        items:
+          - const: marvell,armada385
+          - const: marvell,armada380
+
+      - description: Armada 388 SoC
+        items:
+          - const: marvell,armada388
+          - const: marvell,armada385
+          - const: marvell,armada380
+
+additionalProperties: true
-- 
2.35.3



From josua at solid-run.com  Sun Dec 24 06:38:44 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:38:44 +0100
Subject: [PATCH v2 2/8] dt-bindings: marvell: a38x: add solidrun armada 385 clearfog gtr boards
Message-ID: <20231224143850.5671-3-josua@solid-run.com>

Add DT compatible for SolidRun Armada-385 based Clearfog GTR L8 and S4
boards.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../devicetree/bindings/arm/marvell/armada-38x.yaml       | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
index 5af222e6db18..5bc69c4fe34d 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -30,4 +30,12 @@ properties:
           - const: marvell,armada385
           - const: marvell,armada380
 
+      - description: SolidRun Armada 385 based single-board computers
+        items:
+          - enum:
+             - solidrun,clearfog-gtr-l8
+             - solidrun,clearfog-gtr-s4
+          - const: marvell,armada385
+          - const: marvell,armada380
+
 additionalProperties: true
-- 
2.35.3



From josua at solid-run.com  Sun Dec 24 06:38:45 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:38:45 +0100
Subject: [PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada 388 clearfog boards
In-Reply-To: <20231224143850.5671-3-josua@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
Message-ID: <20231224143850.5671-4-josua@solid-run.com>

Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
boards.

While they are just two variants, we have 3 device-tree:
- armada-388-clearfog.dts
- armada-388-clearfog-base.dts
- armada-388-clearfog-pro.dts

While the first one is identical to the pro variant, the filename is
not, and neither are the compatible strings.

The first is compatible to armada-380, 385, 388 and
solidrun,clearfog-a1.
The other two are compatible to the same, plus an additional string
including the pro/base as suffix.

Add two bindings, one for the explicit pro and base variants using a
total of 5 compatibles, and one for the generic name using just 4.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../bindings/arm/marvell/armada-38x.yaml      | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
index 5bc69c4fe34d..25c29b466094 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -38,4 +38,24 @@ properties:
           - const: marvell,armada385
           - const: marvell,armada380
 
+      - description: |
+          SolidRun Armada 388 SoM based clearfog board. This is
+          equivalent to clearfog pro, but lacks the "pro" label
+          in dtb filename and compatible strings.
+        items:
+          - const: solidrun,clearfog-a1
+          - const: marvell,armada388
+          - const: marvell,armada385
+          - const: marvell,armada380
+
+      - description: SolidRun Armada 388 SoM based clearfog board variants
+        items:
+          - enum:
+             - solidrun,clearfog-base-a1
+             - solidrun,clearfog-pro-a1
+          - const: solidrun,clearfog-a1
+          - const: marvell,armada388
+          - const: marvell,armada385
+          - const: marvell,armada380
+
 additionalProperties: true
-- 
2.35.3



From josua at solid-run.com  Sun Dec 24 06:38:46 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:38:46 +0100
Subject: [PATCH v2 4/8] arm: dts: marvell: clearfog-gtr: add board-specific compatible strings
In-Reply-To: <20231224143850.5671-3-josua@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
Message-ID: <20231224143850.5671-5-josua@solid-run.com>

Most arm board have a board-specific compatible string that allows e.g.
userspace to match specific firmware variants or apply specific
policies.

Add board-specific properties to both variants of the Clearfog GTR:
- solidrun,clearfog-gtr-l8
- solidrun,clearfog-gtr-s4

Introduction of a common parent (e.g. "solidrun,clearfog-gtr") is
omitted for brevity.
Since announcement of the two products no additional variants were added
it is assumed that there will always be just two.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 2 ++
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index 1990f7d0cc79..cd5b070f1218 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -4,6 +4,8 @@
 
 / {
 	model = "SolidRun Clearfog GTR L8";
+	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385",
+		     "marvell,armada380";
 };
 
 &mdio {
diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
index b795ad573891..4a9736ec99b6 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
@@ -4,6 +4,8 @@
 
 / {
 	model = "SolidRun Clearfog GTR S4";
+	compatible = "solidrun,clearfog-gtr-s4", "marvell,armada385",
+		     "marvell,armada380";
 };
 
 &sfp0 {
-- 
2.35.3



From josua at solid-run.com  Sun Dec 24 06:38:47 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:38:47 +0100
Subject: [PATCH v2 5/8] arm: dts: marvell: clearfog-gtr: sort pinctrl nodes alphabetically
In-Reply-To: <20231224143850.5671-3-josua@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
Message-ID: <20231224143850.5671-6-josua@solid-run.com>

Cosmetic change to increase future patches readability when adding new
pinctrl nodes.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../dts/marvell/armada-385-clearfog-gtr.dtsi  | 40 +++++++++----------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index d1452a04e904..8eabb60765b0 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -141,18 +141,13 @@ i2c at 11100 { /* SFP (CON5/CON6) */
 			};
 
 			pinctrl at 18000 {
-				cf_gtr_switch_reset_pins: cf-gtr-switch-reset-pins {
-					marvell,pins = "mpp18";
-					marvell,function = "gpio";
-				};
-
-				cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
-					marvell,pins = "mpp22";
+				cf_gtr_fan_pwm: cf-gtr-fan-pwm {
+					marvell,pins = "mpp23";
 					marvell,function = "gpio";
 				};
 
-				cf_gtr_fan_pwm: cf-gtr-fan-pwm {
-					marvell,pins = "mpp23";
+				cf_gtr_front_button_pins: cf-gtr-front-button-pins {
+					marvell,pins = "mpp53";
 					marvell,function = "gpio";
 				};
 
@@ -162,13 +157,6 @@ cf_gtr_i2c1_pins: i2c1-pins {
 					marvell,function = "i2c1";
 				};
 
-				cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
-					marvell,pins = "mpp21", "mpp28",
-						       "mpp37", "mpp38",
-						       "mpp39", "mpp40";
-					marvell,function = "sd0";
-				};
-
 				cf_gtr_isolation_pins: cf-gtr-isolation-pins {
 					marvell,pins = "mpp47";
 					marvell,function = "gpio";
@@ -179,18 +167,30 @@ cf_gtr_poe_reset_pins: cf-gtr-poe-reset-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_rear_button_pins: cf-gtr-rear-button-pins {
+					marvell,pins = "mpp36";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
+					marvell,pins = "mpp21", "mpp28",
+						       "mpp37", "mpp38",
+						       "mpp39", "mpp40";
+					marvell,function = "sd0";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
 				};
 
-				cf_gtr_front_button_pins: cf-gtr-front-button-pins {
-					marvell,pins = "mpp53";
+				cf_gtr_switch_reset_pins: cf-gtr-switch-reset-pins {
+					marvell,pins = "mpp18";
 					marvell,function = "gpio";
 				};
 
-				cf_gtr_rear_button_pins: cf-gtr-rear-button-pins {
-					marvell,pins = "mpp36";
+				cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
+					marvell,pins = "mpp22";
 					marvell,function = "gpio";
 				};
 			};
-- 
2.35.3



From josua at solid-run.com  Sun Dec 24 06:38:48 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:38:48 +0100
Subject: [PATCH v2 6/8] arm: dts: marvell: clearfog-gtr: add missing pinctrl for all used gpios
In-Reply-To: <20231224143850.5671-3-josua@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
Message-ID: <20231224143850.5671-7-josua@solid-run.com>

Various control signals such as sfp module-absence, pci-e reset or led
gpios were missing pinctrl nodes, leaving any u-boot choices in place.

Since U-Boot is shared between multiple board variants, i.e. a388
clearfog pro / base, clearfog gtr l / 4, it is better to explicitly
configure functions.
Add explicit pinctrl entries for all gpios currently in use.

Additionally the loss-of-signal gpio specified is invalid, in fact los
only has a pull-up on the board but no gpio connection to the cpu.
Remove this stray reference.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../dts/marvell/armada-385-clearfog-gtr.dtsi  | 42 +++++++++++++++++--
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index 8eabb60765b0..39ac97edb463 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -162,6 +162,22 @@ cf_gtr_isolation_pins: cf-gtr-isolation-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_led_pins: led-pins {
+					marvell,pins = "mpp42", "mpp52";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_lte_disable_pins: lte-disable-pins {
+					marvell,pins = "mpp34";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_pci_pins: pci-pins {
+					// pci reset
+					marvell,pins = "mpp33", "mpp35", "mpp44";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_poe_reset_pins: cf-gtr-poe-reset-pins {
 					marvell,pins = "mpp48";
 					marvell,function = "gpio";
@@ -179,6 +195,12 @@ cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
 					marvell,function = "sd0";
 				};
 
+				cf_gtr_sfp0_pins: sfp0-pins {
+					/* sfp modabs, txdisable */
+					marvell,pins = "mpp25", "mpp46";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
@@ -193,6 +215,11 @@ cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
 					marvell,pins = "mpp22";
 					marvell,function = "gpio";
 				};
+
+				cf_gtr_wifi_disable_pins: wifi-disable-pins {
+					marvell,pins = "mpp30", "mpp31";
+					marvell,function = "gpio";
+				};
 			};
 
 			sdhci at d8000 {
@@ -221,21 +248,26 @@ usb3 at f8000 {
 		};
 
 		pcie {
+			pinctrl-0 = <&cf_gtr_pci_pins>;
+			pinctrl-names = "default";
 			status = "okay";
 			/*
 			 * The PCIe units are accessible through
 			 * the mini-PCIe connectors on the board.
 			 */
+			/* CON3 - serdes 0 */
 			pcie at 1,0 {
 				reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
 				status = "okay";
 			};
 
+			/* CON4 - serdes 2 */
 			pcie at 2,0 {
 				reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
 				status = "okay";
 			};
 
+			/* CON2 - serdes 4 */
 			pcie at 3,0 {
 				reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
 				status = "okay";
@@ -243,10 +275,12 @@ pcie at 3,0 {
 		};
 	};
 
+	/* CON5 */
 	sfp0: sfp {
 		compatible = "sff,sfp";
+		pinctrl-0 = <&cf_gtr_sfp0_pins>;
+		pinctrl-names = "default";
 		i2c-bus = <&i2c1>;
-		los-gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
 		mod-def0-gpio = <&gpio0 25 GPIO_ACTIVE_LOW>;
 		tx-disable-gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
 	};
@@ -273,6 +307,8 @@ button-1 {
 
 	gpio-leds {
 		compatible = "gpio-leds";
+		pinctrl-0 = <&cf_gtr_led_pins>;
+		pinctrl-names = "default";
 
 		led1 {
 			function = LED_FUNCTION_CPU;
@@ -408,7 +444,7 @@ &ahci1 {
 };
 
 &gpio0 {
-	pinctrl-0 = <&cf_gtr_fan_pwm>;
+	pinctrl-0 = <&cf_gtr_fan_pwm &cf_gtr_wifi_disable_pins>;
 	pinctrl-names = "default";
 
 	wifi-disable {
@@ -420,7 +456,7 @@ wifi-disable {
 };
 
 &gpio1 {
-	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins>;
+	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins &cf_gtr_lte_disable_pins>;
 	pinctrl-names = "default";
 
 	lte-disable {
-- 
2.35.3



From josua at solid-run.com  Sun Dec 24 06:38:49 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:38:49 +0100
Subject: [PATCH v2 7/8] arm: dts: marvell: clearfog-gtr-l8: add support for second sfp connector
In-Reply-To: <20231224143850.5671-3-josua@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
Message-ID: <20231224143850.5671-8-josua@solid-run.com>

Clearfog GTR L8 has an extra SFP connector on the managed switch port 9.
Add descriptions for both entities along with pinctrl.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../marvell/armada-385-clearfog-gtr-l8.dts    | 20 ++++++++++++++++++-
 .../dts/marvell/armada-385-clearfog-gtr.dtsi  |  8 +++++++-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index cd5b070f1218..2df388f222ec 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -6,6 +6,16 @@ / {
 	model = "SolidRun Clearfog GTR L8";
 	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385",
 		     "marvell,armada380";
+
+	/* CON25 */
+	sfp1: sfp-1 {
+		compatible = "sff,sfp";
+		pinctrl-0 = <&cf_gtr_sfp1_pins>;
+		pinctrl-names = "default";
+		i2c-bus = <&i2c0>;
+		mod-def0-gpio = <&gpio0 24 GPIO_ACTIVE_LOW>;
+		tx-disable-gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
+	};
 };
 
 &mdio {
@@ -68,11 +78,19 @@ port at 8 {
 				phy-handle = <&switch0phy7>;
 			};
 
+			port at 9 {
+				reg = <9>;
+				label = "lan-sfp";
+				phy-mode = "sgmii";
+				sfp = <&sfp1>;
+				managed = "in-band-status";
+			};
+
 			port at 10 {
 				reg = <10>;
 				phy-mode = "2500base-x";
-
 				ethernet = <&eth1>;
+
 				fixed-link {
 					speed = <2500>;
 					full-duplex;
diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index 39ac97edb463..f3a3cb6ac311 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -201,6 +201,12 @@ cf_gtr_sfp0_pins: sfp0-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_sfp1_pins: sfp1-pins {
+					/* sfp modabs, txdisable */
+					marvell,pins = "mpp24", "mpp54";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
@@ -276,7 +282,7 @@ pcie at 3,0 {
 	};
 
 	/* CON5 */
-	sfp0: sfp {
+	sfp0: sfp-0 {
 		compatible = "sff,sfp";
 		pinctrl-0 = <&cf_gtr_sfp0_pins>;
 		pinctrl-names = "default";
-- 
2.35.3



From josua at solid-run.com  Sun Dec 24 06:38:50 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:38:50 +0100
Subject: [PATCH v2 8/8] arm: dts: marvell: clearfog-gtr-l8: align port numbers with enclosure
In-Reply-To: <20231224143850.5671-3-josua@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
Message-ID: <20231224143850.5671-9-josua@solid-run.com>

Clearfog GTR has an official enclosure with labels for all interfaces.
The "lan" ports on the 8-port switch in device-tree were numbered  in
reverse wrt. enclosure.

Update all device-tree labels to match.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../dts/marvell/armada-385-clearfog-gtr-l8.dts   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index 2df388f222ec..da6981677b03 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -32,49 +32,49 @@ ports {
 
 			port at 1 {
 				reg = <1>;
-				label = "lan8";
+				label = "lan1";
 				phy-handle = <&switch0phy0>;
 			};
 
 			port at 2 {
 				reg = <2>;
-				label = "lan7";
+				label = "lan2";
 				phy-handle = <&switch0phy1>;
 			};
 
 			port at 3 {
 				reg = <3>;
-				label = "lan6";
+				label = "lan3";
 				phy-handle = <&switch0phy2>;
 			};
 
 			port at 4 {
 				reg = <4>;
-				label = "lan5";
+				label = "lan4";
 				phy-handle = <&switch0phy3>;
 			};
 
 			port at 5 {
 				reg = <5>;
-				label = "lan4";
+				label = "lan5";
 				phy-handle = <&switch0phy4>;
 			};
 
 			port at 6 {
 				reg = <6>;
-				label = "lan3";
+				label = "lan6";
 				phy-handle = <&switch0phy5>;
 			};
 
 			port at 7 {
 				reg = <7>;
-				label = "lan2";
+				label = "lan7";
 				phy-handle = <&switch0phy6>;
 			};
 
 			port at 8 {
 				reg = <8>;
-				label = "lan1";
+				label = "lan8";
 				phy-handle = <&switch0phy7>;
 			};
 
-- 
2.35.3



From conor at kernel.org  Sun Dec 24 06:42:42 2023
From: conor at kernel.org (Conor Dooley)
Date: Sun, 24 Dec 2023 14:42:42 +0000
Subject: [PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <20231224143850.5671-4-josua@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
 <20231224143850.5671-4-josua@solid-run.com>
Message-ID: <20231224-tibia-thursday-bea9dde2fbf1@spud>

On Sun, Dec 24, 2023 at 03:38:45PM +0100, Josua Mayer wrote:
> Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
> boards.
> 
> While they are just two variants, we have 3 device-tree:
> - armada-388-clearfog.dts
> - armada-388-clearfog-base.dts
> - armada-388-clearfog-pro.dts
> 
> While the first one is identical to the pro variant, the filename is
> not, and neither are the compatible strings.
> 
> The first is compatible to armada-380, 385, 388 and
> solidrun,clearfog-a1.
> The other two are compatible to the same, plus an additional string
> including the pro/base as suffix.
> 
> Add two bindings, one for the explicit pro and base variants using a
> total of 5 compatibles, and one for the generic name using just 4.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com>

There's nothing here that explains to me _why_ there are three sets of
compatibles for only two boards. Why is this the case?

Also, binding patches need to be sent to the devicetree mailing list.
get_maintainer.pl should have told you that, no?


> ---
>  .../bindings/arm/marvell/armada-38x.yaml      | 20 +++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> index 5bc69c4fe34d..25c29b466094 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> @@ -38,4 +38,24 @@ properties:
>            - const: marvell,armada385
>            - const: marvell,armada380
>  
> +      - description: |

This isn't needed, there's no formatting to preserve.

Cheers,
Conor.

> +          SolidRun Armada 388 SoM based clearfog board. This is
> +          equivalent to clearfog pro, but lacks the "pro" label
> +          in dtb filename and compatible strings.
> +        items:
> +          - const: solidrun,clearfog-a1
> +          - const: marvell,armada388
> +          - const: marvell,armada385
> +          - const: marvell,armada380
> +
> +      - description: SolidRun Armada 388 SoM based clearfog board variants
> +        items:
> +          - enum:
> +             - solidrun,clearfog-base-a1
> +             - solidrun,clearfog-pro-a1
> +          - const: solidrun,clearfog-a1
> +          - const: marvell,armada388
> +          - const: marvell,armada385
> +          - const: marvell,armada380
> +
>  additionalProperties: true
> -- 
> 2.35.3
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231224/4c74af18/attachment.sig>

From krzk at kernel.org  Sun Dec 24 06:54:36 2023
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 15:54:36 +0100
Subject: [PATCH v2 2/8] dt-bindings: marvell: a38x: add solidrun armada
 385 clearfog gtr boards
In-Reply-To: <20231224143850.5671-3-josua@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
Message-ID: <d0378667-cd8b-4e39-a7dc-195fc2159ee7@kernel.org>

On 24/12/2023 15:38, Josua Mayer wrote:
> Add DT compatible for SolidRun Armada-385 based Clearfog GTR L8 and S4
> boards.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com>

Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.

You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time, thus I will skip this patch entirely till you follow
the process allowing the patch to be tested.

Please kindly resend and include all necessary To/Cc entries.

> ---
>  .../devicetree/bindings/arm/marvell/armada-38x.yaml       | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> index 5af222e6db18..5bc69c4fe34d 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> @@ -30,4 +30,12 @@ properties:
>            - const: marvell,armada385
>            - const: marvell,armada380
>  
> +      - description: SolidRun Armada 385 based single-board computers
> +        items:
> +          - enum:
> +             - solidrun,clearfog-gtr-l8
> +             - solidrun,clearfog-gtr-s4

Not tested. This will fail and if you bothered to Cc lists, at least
automation would test it for you. Now, neither you nor automation will
tell it does not work :(


Best regards,
Krzysztof



From krzk at kernel.org  Sun Dec 24 06:55:26 2023
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 15:55:26 +0100
Subject: [PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <20231224143850.5671-4-josua@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
 <20231224143850.5671-4-josua@solid-run.com>
Message-ID: <d5698668-e589-4ce0-a66f-3b6f107aa257@kernel.org>

On 24/12/2023 15:38, Josua Mayer wrote:
> Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
> boards.
> 
> While they are just two variants, we have 3 device-tree:
> - armada-388-clearfog.dts
> - armada-388-clearfog-base.dts
> - armada-388-clearfog-pro.dts
> 
> While the first one is identical to the pro variant, the filename is
> not, and neither are the compatible strings.
> 
> The first is compatible to armada-380, 385, 388 and
> solidrun,clearfog-a1.
> The other two are compatible to the same, plus an additional string
> including the pro/base as suffix.
> 
> Add two bindings, one for the explicit pro and base variants using a
> total of 5 compatibles, and one for the generic name using just 4.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com>
> ---
>  .../bindings/arm/marvell/armada-38x.yaml      | 20 +++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> index 5bc69c4fe34d..25c29b466094 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> @@ -38,4 +38,24 @@ properties:
>            - const: marvell,armada385
>            - const: marvell,armada380
>  
> +      - description: |
> +          SolidRun Armada 388 SoM based clearfog board. This is
> +          equivalent to clearfog pro, but lacks the "pro" label
> +          in dtb filename and compatible strings.
> +        items:
> +          - const: solidrun,clearfog-a1

SoM cannot be alone.

> +          - const: marvell,armada388
> +          - const: marvell,armada385
> +          - const: marvell,armada380
> +
> +      - description: SolidRun Armada 388 SoM based clearfog board variants
> +        items:
> +          - enum:
> +             - solidrun,clearfog-base-a1

Board has name "base"?

Still not tested...

Best regards,
Krzysztof



From krzk at kernel.org  Sun Dec 24 06:57:24 2023
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 15:57:24 +0100
Subject: [PATCH v2 1/8] dt-bindings: marvell: a38x: convert the soc
 compatibles description to yaml
In-Reply-To: <20231224143750.5604-2-josua@solid-run.com>
References: <20231224143750.5604-1-josua@solid-run.com>
 <20231224143750.5604-2-josua@solid-run.com>
Message-ID: <495a0f12-2627-4c47-9d51-ca580d378652@kernel.org>

On 24/12/2023 15:37, Josua Mayer wrote:
> Convert the existing txt binding for armada-38x socs to DT schema
> format.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com>

Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.

You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time, thus I will skip this patch entirely till you follow
the process allowing the patch to be tested.

Please kindly resend and include all necessary To/Cc entries.

> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +
> +      - description: Armada 380 SoC
> +        items:
> +          - const: marvell,armada380
> +
> +      - description: Armada 385 SoC
> +        items:
> +          - const: marvell,armada385
> +          - const: marvell,armada380
> +
> +      - description: Armada 388 SoC
> +        items:
> +          - const: marvell,armada388
> +          - const: marvell,armada385
> +          - const: marvell,armada380

These should not be used alone, so such schema is not what we want. We
want boards to be documented with these SoCs.

Best regards,
Krzysztof



From marietto2008 at gmail.com  Sun Dec 24 07:40:55 2023
From: marietto2008 at gmail.com (Mario Marietto)
Date: Sun, 24 Dec 2023 16:40:55 +0100
Subject: vidioc_try_fmt:379: Unsupported format for destination.
Message-ID: <CA+1FSig3FqyymCY6prFnX9Bx24WSiec-CxgriKgG5iJvuEPB=A@mail.gmail.com>

Hello.

Have you ever seen the errors below inside the log of the ARM
Chromebook model XE303C12 ?


[ 2416.631903] vidioc_try_fmt:379: Unsupported format for destination.
[ 2416.631937] vidioc_try_fmt:379: Unsupported format for destination.
[ 2437.287065] vidioc_g_selection:764: Can not get compose information
[ 2437.294194] vidioc_g_fmt:347: Format could not be read
[ 2437.300364] vidioc_g_selection:764: Can not get compose information
[ 2437.301979] vidioc_g_fmt:347: Format could not be read
[ 2441.711496] vidioc_g_selection:764: Can not get compose information
[ 2441.713115] vidioc_g_fmt:347: Format could not be read
[ 2455.174443] vidioc_g_selection:764: Can not get compose information
[ 2455.175663] vidioc_g_fmt:347: Format could not be read


I'm not sure but they could be correlated with the warnings I get when
I try to watch an mp4 file using SMPlayer :


libEGL warning : egl failed to create dri2 screen
libEGL warning : failed to get driver name for fd -1
libEGL warning : MESA-LOADER : failed to retrieve device informations


I'm looking for the technical reason why,when I play an mp4 video with
VLC or SMplayer (and for sure other multimedia players),the video
proceeds in spurts.

Thanks.

-- 
Mario.


From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:43:59 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:43:59 +0100
Subject: [PATCH 00/15] media: s5p-mfc: cleanups
Message-ID: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>

Hi,

Few simple cleanups for Samsung Exynos SoC S5P MFC drivers.

Best regards,
Krzysztof

---
Krzysztof Kozlowski (15):
      media: s5p-mfc: drop unused static s5p_mfc_cmds
      media: s5p-mfc: drop unused static s5p_mfc_ops
      media: s5p-mfc: drop unused get_*_def_fmt declarations
      media: s5p-mfc: constify fw_name strings
      media: s5p-mfc: constify s5p_mfc_buf_size structures
      media: s5p-mfc: constify s5p_mfc_variant structures
      media: s5p-mfc: constify s5p_mfc_hw_cmds structures
      media: s5p-mfc: constify s5p_mfc_hw_ops structures
      media: s5p-mfc: constify s5p_mfc_fmt structures
      media: s5p-mfc: constify struct structures
      media: s5p-mfc: constify pointers to s5p_mfc_cmd_args
      media: s5p-mfc: constify local pointers to s5p_mfc_enc_params
      media: s5p-mfc: drop useless clock refcnt debugging
      media: s5p-mfc: drop useless static s5p_mfc_dev in s5p_mfc_pm.c
      media: s5p-mfc: drop static device variable in s5p_mfc_pm.c

 drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c   | 76 +++++++++++-----------
 .../media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c   |  8 +--
 .../media/platform/samsung/s5p-mfc/s5p_mfc_cmd.h   |  2 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c      |  6 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h      |  2 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c      |  8 +--
 .../platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h      |  2 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_common.h      | 14 ++--
 .../media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c  | 26 ++++----
 .../media/platform/samsung/s5p-mfc/s5p_mfc_dec.c   | 20 +++---
 .../media/platform/samsung/s5p-mfc/s5p_mfc_dec.h   |  3 +-
 .../media/platform/samsung/s5p-mfc/s5p_mfc_enc.c   | 12 ++--
 .../media/platform/samsung/s5p-mfc/s5p_mfc_enc.h   |  3 +-
 .../media/platform/samsung/s5p-mfc/s5p_mfc_opr.c   |  7 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c      | 28 ++++----
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.h      |  2 +-
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c      | 36 +++++-----
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h      |  2 +-
 .../media/platform/samsung/s5p-mfc/s5p_mfc_pm.c    | 51 ++++++---------
 .../media/platform/samsung/s5p-mfc/s5p_mfc_pm.h    |  8 +--
 20 files changed, 147 insertions(+), 169 deletions(-)
---
base-commit: ceb2fe0d438644e1de06b9a6468a1fb8e2199c70
change-id: 20231224-n-s5p-mfc-const-def6093c0104

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:00 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:00 +0100
Subject: [PATCH 01/15] media: s5p-mfc: drop unused static s5p_mfc_cmds
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-1-a3b246470fe4@linaro.org>

File-scope static variable "s5p_mfc_cmds" is not read after assignment,
thus it can be dropped entirely.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c
index 774c573dc075..196d8c99647b 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c
@@ -12,14 +12,10 @@
 #include "s5p_mfc_cmd_v5.h"
 #include "s5p_mfc_cmd_v6.h"
 
-static struct s5p_mfc_hw_cmds *s5p_mfc_cmds;
-
 void s5p_mfc_init_hw_cmds(struct s5p_mfc_dev *dev)
 {
 	if (IS_MFCV6_PLUS(dev))
-		s5p_mfc_cmds = s5p_mfc_init_hw_cmds_v6();
+		dev->mfc_cmds = s5p_mfc_init_hw_cmds_v6();
 	else
-		s5p_mfc_cmds = s5p_mfc_init_hw_cmds_v5();
-
-	dev->mfc_cmds = s5p_mfc_cmds;
+		dev->mfc_cmds = s5p_mfc_init_hw_cmds_v5();
 }

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:01 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:01 +0100
Subject: [PATCH 02/15] media: s5p-mfc: drop unused static s5p_mfc_ops
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-2-a3b246470fe4@linaro.org>

File-scope static variable "s5p_mfc_ops" is not read after assignment,
thus it can be dropped entirely.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c
index 673962301173..5ba791fa3676 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c
@@ -14,18 +14,15 @@
 #include "s5p_mfc_opr_v5.h"
 #include "s5p_mfc_opr_v6.h"
 
-static struct s5p_mfc_hw_ops *s5p_mfc_ops;
-
 void s5p_mfc_init_hw_ops(struct s5p_mfc_dev *dev)
 {
 	if (IS_MFCV6_PLUS(dev)) {
-		s5p_mfc_ops = s5p_mfc_init_hw_ops_v6();
+		dev->mfc_ops = s5p_mfc_init_hw_ops_v6();
 		dev->warn_start = S5P_FIMV_ERR_WARNINGS_START_V6;
 	} else {
-		s5p_mfc_ops = s5p_mfc_init_hw_ops_v5();
+		dev->mfc_ops = s5p_mfc_init_hw_ops_v5();
 		dev->warn_start = S5P_FIMV_ERR_WARNINGS_START;
 	}
-	dev->mfc_ops = s5p_mfc_ops;
 }
 
 void s5p_mfc_init_regs(struct s5p_mfc_dev *dev)

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:02 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:02 +0100
Subject: [PATCH 03/15] media: s5p-mfc: drop unused get_*_def_fmt
 declarations
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-3-a3b246470fe4@linaro.org>

get_dec_def_fmt() and get_enc_def_fmt() do not have definitions, so
their declarations are pointless.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h | 1 -
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
index 0c52ab46cff7..d4310966a0c2 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
@@ -12,7 +12,6 @@
 const struct s5p_mfc_codec_ops *get_dec_codec_ops(void);
 struct vb2_ops *get_dec_queue_ops(void);
 const struct v4l2_ioctl_ops *get_dec_v4l2_ioctl_ops(void);
-struct s5p_mfc_fmt *get_dec_def_fmt(bool src);
 int s5p_mfc_dec_ctrls_setup(struct s5p_mfc_ctx *ctx);
 void s5p_mfc_dec_ctrls_delete(struct s5p_mfc_ctx *ctx);
 void s5p_mfc_dec_init(struct s5p_mfc_ctx *ctx);
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
index 3f1b1a037a4f..0cf08b8d40ff 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
@@ -12,7 +12,6 @@
 const struct s5p_mfc_codec_ops *get_enc_codec_ops(void);
 struct vb2_ops *get_enc_queue_ops(void);
 const struct v4l2_ioctl_ops *get_enc_v4l2_ioctl_ops(void);
-struct s5p_mfc_fmt *get_enc_def_fmt(bool src);
 int s5p_mfc_enc_ctrls_setup(struct s5p_mfc_ctx *ctx);
 void s5p_mfc_enc_ctrls_delete(struct s5p_mfc_ctx *ctx);
 void s5p_mfc_enc_init(struct s5p_mfc_ctx *ctx);

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:03 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:03 +0100
Subject: [PATCH 04/15] media: s5p-mfc: constify fw_name strings
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-4-a3b246470fe4@linaro.org>

Constify stored pointers to firmware names for code safety.  These are
not modified by the driver.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index 5304f42c8c72..f33a755327ef 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -227,7 +227,7 @@ struct s5p_mfc_variant {
 	unsigned int port_num;
 	u32 version_bit;
 	struct s5p_mfc_buf_size *buf_size;
-	char	*fw_name[MFC_FW_MAX_VERSIONS];
+	const char	*fw_name[MFC_FW_MAX_VERSIONS];
 	const char	*clk_names[MFC_MAX_CLOCKS];
 	int		num_clocks;
 	bool		use_clock_gating;

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:04 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:04 +0100
Subject: [PATCH 05/15] media: s5p-mfc: constify s5p_mfc_buf_size structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-5-a3b246470fe4@linaro.org>

Static "s5p_mfc_buf_size*" structures are not modified by the driver, so
they can be made const for code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c     | 20 ++++++++++----------
 .../media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c  |  2 +-
 .../media/platform/samsung/s5p-mfc/s5p_mfc_common.h  |  4 ++--
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c |  2 +-
 .../media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c  |  6 +++---
 .../media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c  |  6 +++---
 6 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index e30e54935d79..6af7b812c5df 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -1516,14 +1516,14 @@ static const struct dev_pm_ops s5p_mfc_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(s5p_mfc_suspend, s5p_mfc_resume)
 };
 
-static struct s5p_mfc_buf_size_v5 mfc_buf_size_v5 = {
+static const struct s5p_mfc_buf_size_v5 mfc_buf_size_v5 = {
 	.h264_ctx	= MFC_H264_CTX_BUF_SIZE,
 	.non_h264_ctx	= MFC_CTX_BUF_SIZE,
 	.dsc		= DESC_BUF_SIZE,
 	.shm		= SHARED_BUF_SIZE,
 };
 
-static struct s5p_mfc_buf_size buf_size_v5 = {
+static const struct s5p_mfc_buf_size buf_size_v5 = {
 	.fw	= MAX_FW_SIZE,
 	.cpb	= MAX_CPB_SIZE,
 	.priv	= &mfc_buf_size_v5,
@@ -1540,7 +1540,7 @@ static struct s5p_mfc_variant mfc_drvdata_v5 = {
 	.use_clock_gating = true,
 };
 
-static struct s5p_mfc_buf_size_v6 mfc_buf_size_v6 = {
+static const struct s5p_mfc_buf_size_v6 mfc_buf_size_v6 = {
 	.dev_ctx	= MFC_CTX_BUF_SIZE_V6,
 	.h264_dec_ctx	= MFC_H264_DEC_CTX_BUF_SIZE_V6,
 	.other_dec_ctx	= MFC_OTHER_DEC_CTX_BUF_SIZE_V6,
@@ -1548,7 +1548,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v6 = {
 	.other_enc_ctx	= MFC_OTHER_ENC_CTX_BUF_SIZE_V6,
 };
 
-static struct s5p_mfc_buf_size buf_size_v6 = {
+static const struct s5p_mfc_buf_size buf_size_v6 = {
 	.fw	= MAX_FW_SIZE_V6,
 	.cpb	= MAX_CPB_SIZE_V6,
 	.priv	= &mfc_buf_size_v6,
@@ -1569,7 +1569,7 @@ static struct s5p_mfc_variant mfc_drvdata_v6 = {
 	.num_clocks	= 1,
 };
 
-static struct s5p_mfc_buf_size_v6 mfc_buf_size_v7 = {
+static const struct s5p_mfc_buf_size_v6 mfc_buf_size_v7 = {
 	.dev_ctx	= MFC_CTX_BUF_SIZE_V7,
 	.h264_dec_ctx	= MFC_H264_DEC_CTX_BUF_SIZE_V7,
 	.other_dec_ctx	= MFC_OTHER_DEC_CTX_BUF_SIZE_V7,
@@ -1577,7 +1577,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v7 = {
 	.other_enc_ctx	= MFC_OTHER_ENC_CTX_BUF_SIZE_V7,
 };
 
-static struct s5p_mfc_buf_size buf_size_v7 = {
+static const struct s5p_mfc_buf_size buf_size_v7 = {
 	.fw	= MAX_FW_SIZE_V7,
 	.cpb	= MAX_CPB_SIZE_V7,
 	.priv	= &mfc_buf_size_v7,
@@ -1603,7 +1603,7 @@ static struct s5p_mfc_variant mfc_drvdata_v7_3250 = {
 	.num_clocks     = 2,
 };
 
-static struct s5p_mfc_buf_size_v6 mfc_buf_size_v8 = {
+static const struct s5p_mfc_buf_size_v6 mfc_buf_size_v8 = {
 	.dev_ctx	= MFC_CTX_BUF_SIZE_V8,
 	.h264_dec_ctx	= MFC_H264_DEC_CTX_BUF_SIZE_V8,
 	.other_dec_ctx	= MFC_OTHER_DEC_CTX_BUF_SIZE_V8,
@@ -1611,7 +1611,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v8 = {
 	.other_enc_ctx	= MFC_OTHER_ENC_CTX_BUF_SIZE_V8,
 };
 
-static struct s5p_mfc_buf_size buf_size_v8 = {
+static const struct s5p_mfc_buf_size buf_size_v8 = {
 	.fw	= MAX_FW_SIZE_V8,
 	.cpb	= MAX_CPB_SIZE_V8,
 	.priv	= &mfc_buf_size_v8,
@@ -1637,7 +1637,7 @@ static struct s5p_mfc_variant mfc_drvdata_v8_5433 = {
 	.num_clocks	= 3,
 };
 
-static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
+static const struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
 	.dev_ctx        = MFC_CTX_BUF_SIZE_V10,
 	.h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
 	.other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
@@ -1646,7 +1646,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
 	.other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
 };
 
-static struct s5p_mfc_buf_size buf_size_v10 = {
+static const struct s5p_mfc_buf_size buf_size_v10 = {
 	.fw     = MAX_FW_SIZE_V10,
 	.cpb    = MAX_CPB_SIZE_V10,
 	.priv   = &mfc_buf_size_v10,
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
index f8588e52dfc8..25c4719a5dd0 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
@@ -32,7 +32,7 @@ static int s5p_mfc_cmd_host2risc_v6(struct s5p_mfc_dev *dev, int cmd,
 static int s5p_mfc_sys_init_cmd_v6(struct s5p_mfc_dev *dev)
 {
 	struct s5p_mfc_cmd_args h2r_args;
-	struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size->priv;
+	const struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size->priv;
 	int ret;
 
 	ret = s5p_mfc_hw_call(dev->mfc_ops, alloc_dev_context_buffer, dev);
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index f33a755327ef..6a47f3434c60 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -219,14 +219,14 @@ struct s5p_mfc_buf_size_v6 {
 struct s5p_mfc_buf_size {
 	unsigned int fw;
 	unsigned int cpb;
-	void *priv;
+	const void *priv;
 };
 
 struct s5p_mfc_variant {
 	unsigned int version;
 	unsigned int port_num;
 	u32 version_bit;
-	struct s5p_mfc_buf_size *buf_size;
+	const struct s5p_mfc_buf_size *buf_size;
 	const char	*fw_name[MFC_FW_MAX_VERSIONS];
 	const char	*clk_names[MFC_MAX_CLOCKS];
 	int		num_clocks;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
index 268ffe4da53c..4dbe8792ac3d 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
@@ -426,7 +426,7 @@ static int vidioc_s_fmt(struct file *file, void *priv, struct v4l2_format *f)
 	struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
 	int ret = 0;
 	struct v4l2_pix_format_mplane *pix_mp;
-	struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
+	const struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
 
 	mfc_debug_enter();
 	ret = vidioc_try_fmt(file, priv, f);
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
index 28a06dc343fd..13a3ff55e547 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
@@ -34,7 +34,7 @@
 static int s5p_mfc_alloc_dec_temp_buffers_v5(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	struct s5p_mfc_buf_size_v5 *buf_size = dev->variant->buf_size->priv;
+	const struct s5p_mfc_buf_size_v5 *buf_size = dev->variant->buf_size->priv;
 	int ret;
 
 	ctx->dsc.size = buf_size->dsc;
@@ -200,7 +200,7 @@ static void s5p_mfc_release_codec_buffers_v5(struct s5p_mfc_ctx *ctx)
 static int s5p_mfc_alloc_instance_buffer_v5(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	struct s5p_mfc_buf_size_v5 *buf_size = dev->variant->buf_size->priv;
+	const struct s5p_mfc_buf_size_v5 *buf_size = dev->variant->buf_size->priv;
 	int ret;
 
 	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
@@ -345,7 +345,7 @@ static void s5p_mfc_enc_calc_src_size_v5(struct s5p_mfc_ctx *ctx)
 static void s5p_mfc_set_dec_desc_buffer(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	struct s5p_mfc_buf_size_v5 *buf_size = dev->variant->buf_size->priv;
+	const struct s5p_mfc_buf_size_v5 *buf_size = dev->variant->buf_size->priv;
 
 	mfc_write(dev, OFFSETA(ctx->dsc.dma), S5P_FIMV_SI_CH0_DESC_ADR);
 	mfc_write(dev, buf_size->dsc, S5P_FIMV_SI_CH0_DESC_SIZE);
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index c0df5ac9fcff..70a62400908e 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -333,7 +333,7 @@ static void s5p_mfc_release_codec_buffers_v6(struct s5p_mfc_ctx *ctx)
 static int s5p_mfc_alloc_instance_buffer_v6(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size->priv;
+	const struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size->priv;
 	int ret;
 
 	mfc_debug_enter();
@@ -393,7 +393,7 @@ static void s5p_mfc_release_instance_buffer_v6(struct s5p_mfc_ctx *ctx)
 /* Allocate context buffers for SYS_INIT */
 static int s5p_mfc_alloc_dev_context_buffer_v6(struct s5p_mfc_dev *dev)
 {
-	struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size->priv;
+	const struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size->priv;
 	int ret;
 
 	mfc_debug_enter();
@@ -493,7 +493,7 @@ static int s5p_mfc_set_dec_stream_buffer_v6(struct s5p_mfc_ctx *ctx,
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
-	struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
+	const struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
 
 	mfc_debug_enter();
 	mfc_debug(2, "inst_no: %d, buf_addr: 0x%08x,\n"

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:05 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:05 +0100
Subject: [PATCH 06/15] media: s5p-mfc: constify s5p_mfc_variant structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-6-a3b246470fe4@linaro.org>

Static "s5p_mfc_variant" structures are not modified by the driver, so
they can be made const for code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index 6af7b812c5df..5d10c1cb8b92 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -1529,7 +1529,7 @@ static const struct s5p_mfc_buf_size buf_size_v5 = {
 	.priv	= &mfc_buf_size_v5,
 };
 
-static struct s5p_mfc_variant mfc_drvdata_v5 = {
+static const struct s5p_mfc_variant mfc_drvdata_v5 = {
 	.version	= MFC_VERSION,
 	.version_bit	= MFC_V5_BIT,
 	.port_num	= MFC_NUM_PORTS,
@@ -1554,7 +1554,7 @@ static const struct s5p_mfc_buf_size buf_size_v6 = {
 	.priv	= &mfc_buf_size_v6,
 };
 
-static struct s5p_mfc_variant mfc_drvdata_v6 = {
+static const struct s5p_mfc_variant mfc_drvdata_v6 = {
 	.version	= MFC_VERSION_V6,
 	.version_bit	= MFC_V6_BIT,
 	.port_num	= MFC_NUM_PORTS_V6,
@@ -1583,7 +1583,7 @@ static const struct s5p_mfc_buf_size buf_size_v7 = {
 	.priv	= &mfc_buf_size_v7,
 };
 
-static struct s5p_mfc_variant mfc_drvdata_v7 = {
+static const struct s5p_mfc_variant mfc_drvdata_v7 = {
 	.version	= MFC_VERSION_V7,
 	.version_bit	= MFC_V7_BIT,
 	.port_num	= MFC_NUM_PORTS_V7,
@@ -1593,7 +1593,7 @@ static struct s5p_mfc_variant mfc_drvdata_v7 = {
 	.num_clocks	= 1,
 };
 
-static struct s5p_mfc_variant mfc_drvdata_v7_3250 = {
+static const struct s5p_mfc_variant mfc_drvdata_v7_3250 = {
 	.version        = MFC_VERSION_V7,
 	.version_bit    = MFC_V7_BIT,
 	.port_num       = MFC_NUM_PORTS_V7,
@@ -1617,7 +1617,7 @@ static const struct s5p_mfc_buf_size buf_size_v8 = {
 	.priv	= &mfc_buf_size_v8,
 };
 
-static struct s5p_mfc_variant mfc_drvdata_v8 = {
+static const struct s5p_mfc_variant mfc_drvdata_v8 = {
 	.version	= MFC_VERSION_V8,
 	.version_bit	= MFC_V8_BIT,
 	.port_num	= MFC_NUM_PORTS_V8,
@@ -1627,7 +1627,7 @@ static struct s5p_mfc_variant mfc_drvdata_v8 = {
 	.num_clocks	= 1,
 };
 
-static struct s5p_mfc_variant mfc_drvdata_v8_5433 = {
+static const struct s5p_mfc_variant mfc_drvdata_v8_5433 = {
 	.version	= MFC_VERSION_V8,
 	.version_bit	= MFC_V8_BIT,
 	.port_num	= MFC_NUM_PORTS_V8,
@@ -1652,7 +1652,7 @@ static const struct s5p_mfc_buf_size buf_size_v10 = {
 	.priv   = &mfc_buf_size_v10,
 };
 
-static struct s5p_mfc_variant mfc_drvdata_v10 = {
+static const struct s5p_mfc_variant mfc_drvdata_v10 = {
 	.version        = MFC_VERSION_V10,
 	.version_bit    = MFC_V10_BIT,
 	.port_num       = MFC_NUM_PORTS_V10,

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:06 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:06 +0100
Subject: [PATCH 07/15] media: s5p-mfc: constify s5p_mfc_hw_cmds structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-7-a3b246470fe4@linaro.org>

Static "s5p_mfc_hw_cmds" structures are not modified by the driver, so
they can be made const for code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c | 4 ++--
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h | 2 +-
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c | 4 ++--
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h | 2 +-
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
index 327e54e70611..1fbf7ed5d4cc 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
@@ -148,7 +148,7 @@ static int s5p_mfc_close_inst_cmd_v5(struct s5p_mfc_ctx *ctx)
 }
 
 /* Initialize cmd function pointers for MFC v5 */
-static struct s5p_mfc_hw_cmds s5p_mfc_cmds_v5 = {
+static const struct s5p_mfc_hw_cmds s5p_mfc_cmds_v5 = {
 	.cmd_host2risc = s5p_mfc_cmd_host2risc_v5,
 	.sys_init_cmd = s5p_mfc_sys_init_cmd_v5,
 	.sleep_cmd = s5p_mfc_sleep_cmd_v5,
@@ -157,7 +157,7 @@ static struct s5p_mfc_hw_cmds s5p_mfc_cmds_v5 = {
 	.close_inst_cmd = s5p_mfc_close_inst_cmd_v5,
 };
 
-struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v5(void)
+const struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v5(void)
 {
 	return &s5p_mfc_cmds_v5;
 }
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h
index 6eafa514aebc..c626376053c4 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h
@@ -11,6 +11,6 @@
 
 #include "s5p_mfc_common.h"
 
-struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v5(void);
+const struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v5(void);
 
 #endif /* S5P_MFC_CMD_H_ */
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
index 25c4719a5dd0..740aa4dfae57 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
@@ -154,7 +154,7 @@ static int s5p_mfc_close_inst_cmd_v6(struct s5p_mfc_ctx *ctx)
 }
 
 /* Initialize cmd function pointers for MFC v6 */
-static struct s5p_mfc_hw_cmds s5p_mfc_cmds_v6 = {
+static const struct s5p_mfc_hw_cmds s5p_mfc_cmds_v6 = {
 	.cmd_host2risc = s5p_mfc_cmd_host2risc_v6,
 	.sys_init_cmd = s5p_mfc_sys_init_cmd_v6,
 	.sleep_cmd = s5p_mfc_sleep_cmd_v6,
@@ -163,7 +163,7 @@ static struct s5p_mfc_hw_cmds s5p_mfc_cmds_v6 = {
 	.close_inst_cmd = s5p_mfc_close_inst_cmd_v6,
 };
 
-struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v6(void)
+const struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v6(void)
 {
 	return &s5p_mfc_cmds_v6;
 }
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h
index 9dc44460cc38..29083436f517 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h
@@ -11,6 +11,6 @@
 
 #include "s5p_mfc_common.h"
 
-struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v6(void);
+const struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v6(void);
 
 #endif /* S5P_MFC_CMD_H_ */
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index 6a47f3434c60..9278ed537e9c 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -339,7 +339,7 @@ struct s5p_mfc_dev {
 	struct s5p_mfc_priv_buf ctx_buf;
 	int warn_start;
 	struct s5p_mfc_hw_ops *mfc_ops;
-	struct s5p_mfc_hw_cmds *mfc_cmds;
+	const struct s5p_mfc_hw_cmds *mfc_cmds;
 	const struct s5p_mfc_regs *mfc_regs;
 	enum s5p_mfc_fw_ver fw_ver;
 	bool fw_get_done;

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:07 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:07 +0100
Subject: [PATCH 08/15] media: s5p-mfc: constify s5p_mfc_hw_ops structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-8-a3b246470fe4@linaro.org>

Static "s5p_mfc_hw_ops" structures are not modified by the driver, so
they can be made const for code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h | 2 +-
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c | 4 ++--
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.h | 2 +-
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c | 4 ++--
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index 9278ed537e9c..fa556f27fa06 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -338,7 +338,7 @@ struct s5p_mfc_dev {
 
 	struct s5p_mfc_priv_buf ctx_buf;
 	int warn_start;
-	struct s5p_mfc_hw_ops *mfc_ops;
+	const struct s5p_mfc_hw_ops *mfc_ops;
 	const struct s5p_mfc_hw_cmds *mfc_cmds;
 	const struct s5p_mfc_regs *mfc_regs;
 	enum s5p_mfc_fw_ver fw_ver;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
index 13a3ff55e547..2a0fb78e8e82 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
@@ -1591,7 +1591,7 @@ static unsigned int s5p_mfc_get_crop_info_v_v5(struct s5p_mfc_ctx *ctx)
 }
 
 /* Initialize opr function pointers for MFC v5 */
-static struct s5p_mfc_hw_ops s5p_mfc_ops_v5 = {
+static const struct s5p_mfc_hw_ops s5p_mfc_ops_v5 = {
 	.alloc_dec_temp_buffers = s5p_mfc_alloc_dec_temp_buffers_v5,
 	.release_dec_desc_buffer = s5p_mfc_release_dec_desc_buffer_v5,
 	.alloc_codec_buffers = s5p_mfc_alloc_codec_buffers_v5,
@@ -1631,7 +1631,7 @@ static struct s5p_mfc_hw_ops s5p_mfc_ops_v5 = {
 	.get_crop_info_v = s5p_mfc_get_crop_info_v_v5,
 };
 
-struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v5(void)
+const struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v5(void)
 {
 	return &s5p_mfc_ops_v5;
 }
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.h
index b53d376ead60..0b98c619676e 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.h
@@ -78,5 +78,5 @@ enum MFC_SHM_OFS {
 	FRAME_PACK_SEI_INFO	= 0x17c, /* E */
 };
 
-struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v5(void);
+const struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v5(void);
 #endif /* S5P_MFC_OPR_H_ */
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 70a62400908e..6157c5f97707 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -2484,7 +2484,7 @@ const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev)
 }
 
 /* Initialize opr function pointers for MFC v6 */
-static struct s5p_mfc_hw_ops s5p_mfc_ops_v6 = {
+static const struct s5p_mfc_hw_ops s5p_mfc_ops_v6 = {
 	.alloc_dec_temp_buffers = s5p_mfc_alloc_dec_temp_buffers_v6,
 	.release_dec_desc_buffer = s5p_mfc_release_dec_desc_buffer_v6,
 	.alloc_codec_buffers = s5p_mfc_alloc_codec_buffers_v6,
@@ -2528,7 +2528,7 @@ static struct s5p_mfc_hw_ops s5p_mfc_ops_v6 = {
 	.get_e_min_scratch_buf_size = s5p_mfc_get_e_min_scratch_buf_size,
 };
 
-struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v6(void)
+const struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v6(void)
 {
 	return &s5p_mfc_ops_v6;
 }
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
index e4dd03c5454c..e4b651a8d590 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.h
@@ -52,6 +52,6 @@
 
 #define FRAME_DELTA_DEFAULT		1
 
-struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v6(void);
+const struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v6(void);
 const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev);
 #endif /* S5P_MFC_OPR_V6_H_ */

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:08 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:08 +0100
Subject: [PATCH 09/15] media: s5p-mfc: constify s5p_mfc_fmt structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-9-a3b246470fe4@linaro.org>

Static "s5p_mfc_fmt" structures are not modified by the driver, so
they can be made const for code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h | 4 ++--
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c    | 6 +++---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c    | 8 ++++----
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
index fa556f27fa06..e9283020070e 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
@@ -633,8 +633,8 @@ struct s5p_mfc_ctx {
 	unsigned int int_err;
 	wait_queue_head_t queue;
 
-	struct s5p_mfc_fmt *src_fmt;
-	struct s5p_mfc_fmt *dst_fmt;
+	const struct s5p_mfc_fmt *src_fmt;
+	const struct s5p_mfc_fmt *dst_fmt;
 
 	struct vb2_queue vq_src;
 	struct vb2_queue vq_dst;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
index 4dbe8792ac3d..2f664c7e9e4c 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
@@ -27,7 +27,7 @@
 #include "s5p_mfc_opr.h"
 #include "s5p_mfc_pm.h"
 
-static struct s5p_mfc_fmt formats[] = {
+static const struct s5p_mfc_fmt formats[] = {
 	{
 		.fourcc		= V4L2_PIX_FMT_NV12MT_16X16,
 		.codec_mode	= S5P_MFC_CODEC_NONE,
@@ -163,7 +163,7 @@ static struct s5p_mfc_fmt formats[] = {
 #define NUM_FORMATS ARRAY_SIZE(formats)
 
 /* Find selected format description */
-static struct s5p_mfc_fmt *find_format(struct v4l2_format *f, unsigned int t)
+static const struct s5p_mfc_fmt *find_format(struct v4l2_format *f, unsigned int t)
 {
 	unsigned int i;
 
@@ -387,7 +387,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 {
 	struct s5p_mfc_dev *dev = video_drvdata(file);
-	struct s5p_mfc_fmt *fmt;
+	const struct s5p_mfc_fmt *fmt;
 
 	mfc_debug(2, "Type is %d\n", f->type);
 	if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index 4b4c129c09e7..d6a4b9c701eb 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -30,7 +30,7 @@
 #define DEF_SRC_FMT_ENC	V4L2_PIX_FMT_NV12M
 #define DEF_DST_FMT_ENC	V4L2_PIX_FMT_H264
 
-static struct s5p_mfc_fmt formats[] = {
+static const struct s5p_mfc_fmt formats[] = {
 	{
 		.fourcc		= V4L2_PIX_FMT_NV12MT_16X16,
 		.codec_mode	= S5P_MFC_CODEC_NONE,
@@ -97,7 +97,7 @@ static struct s5p_mfc_fmt formats[] = {
 };
 
 #define NUM_FORMATS ARRAY_SIZE(formats)
-static struct s5p_mfc_fmt *find_format(struct v4l2_format *f, unsigned int t)
+static const struct s5p_mfc_fmt *find_format(struct v4l2_format *f, unsigned int t)
 {
 	unsigned int i;
 
@@ -1394,7 +1394,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 {
 	struct s5p_mfc_dev *dev = video_drvdata(file);
-	struct s5p_mfc_fmt *fmt;
+	const struct s5p_mfc_fmt *fmt;
 	struct v4l2_pix_format_mplane *pix_fmt_mp = &f->fmt.pix_mp;
 
 	if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
@@ -2355,7 +2355,7 @@ static const struct v4l2_ioctl_ops s5p_mfc_enc_ioctl_ops = {
 	.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
 };
 
-static int check_vb_with_fmt(struct s5p_mfc_fmt *fmt, struct vb2_buffer *vb)
+static int check_vb_with_fmt(const struct s5p_mfc_fmt *fmt, struct vb2_buffer *vb)
 {
 	int i;
 

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:09 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:09 +0100
Subject: [PATCH 10/15] media: s5p-mfc: constify struct structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-10-a3b246470fe4@linaro.org>

Static "struct" structures are not modified by the driver, so
they can be made const for code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c | 4 ++--
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h | 2 +-
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c | 4 ++--
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
index 2f664c7e9e4c..eef26d4e02cf 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
@@ -1117,7 +1117,7 @@ static void s5p_mfc_buf_queue(struct vb2_buffer *vb)
 	s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 }
 
-static struct vb2_ops s5p_mfc_dec_qops = {
+static const struct vb2_ops s5p_mfc_dec_qops = {
 	.queue_setup		= s5p_mfc_queue_setup,
 	.wait_prepare		= vb2_ops_wait_prepare,
 	.wait_finish		= vb2_ops_wait_finish,
@@ -1132,7 +1132,7 @@ const struct s5p_mfc_codec_ops *get_dec_codec_ops(void)
 	return &decoder_codec_ops;
 }
 
-struct vb2_ops *get_dec_queue_ops(void)
+const struct vb2_ops *get_dec_queue_ops(void)
 {
 	return &s5p_mfc_dec_qops;
 }
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
index d4310966a0c2..47a6eb9a8fc0 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
@@ -10,7 +10,7 @@
 #define S5P_MFC_DEC_H_
 
 const struct s5p_mfc_codec_ops *get_dec_codec_ops(void);
-struct vb2_ops *get_dec_queue_ops(void);
+const struct vb2_ops *get_dec_queue_ops(void);
 const struct v4l2_ioctl_ops *get_dec_v4l2_ioctl_ops(void);
 int s5p_mfc_dec_ctrls_setup(struct s5p_mfc_ctx *ctx);
 void s5p_mfc_dec_ctrls_delete(struct s5p_mfc_ctx *ctx);
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
index d6a4b9c701eb..537c6e603cd5 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
@@ -2594,7 +2594,7 @@ static void s5p_mfc_buf_queue(struct vb2_buffer *vb)
 	s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 }
 
-static struct vb2_ops s5p_mfc_enc_qops = {
+static const struct vb2_ops s5p_mfc_enc_qops = {
 	.queue_setup		= s5p_mfc_queue_setup,
 	.wait_prepare		= vb2_ops_wait_prepare,
 	.wait_finish		= vb2_ops_wait_finish,
@@ -2610,7 +2610,7 @@ const struct s5p_mfc_codec_ops *get_enc_codec_ops(void)
 	return &encoder_codec_ops;
 }
 
-struct vb2_ops *get_enc_queue_ops(void)
+const struct vb2_ops *get_enc_queue_ops(void)
 {
 	return &s5p_mfc_enc_qops;
 }
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
index 0cf08b8d40ff..62d6db67fd91 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
@@ -10,7 +10,7 @@
 #define S5P_MFC_ENC_H_
 
 const struct s5p_mfc_codec_ops *get_enc_codec_ops(void);
-struct vb2_ops *get_enc_queue_ops(void);
+const struct vb2_ops *get_enc_queue_ops(void);
 const struct v4l2_ioctl_ops *get_enc_v4l2_ioctl_ops(void);
 int s5p_mfc_enc_ctrls_setup(struct s5p_mfc_ctx *ctx);
 void s5p_mfc_enc_ctrls_delete(struct s5p_mfc_ctx *ctx);

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:10 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:10 +0100
Subject: [PATCH 11/15] media: s5p-mfc: constify pointers to
 s5p_mfc_cmd_args
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-11-a3b246470fe4@linaro.org>

In few places functions do not modify pointed "struct
s5p_mfc_cmd_args", thus the pointer can point to const data for
additional safety and self-documenting intention of the function.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.h    | 2 +-
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c | 2 +-
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.h
index 945d12fdceb7..172c5a63b58e 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.h
@@ -19,7 +19,7 @@ struct s5p_mfc_cmd_args {
 
 struct s5p_mfc_hw_cmds {
 	int (*cmd_host2risc)(struct s5p_mfc_dev *dev, int cmd,
-				struct s5p_mfc_cmd_args *args);
+			     const struct s5p_mfc_cmd_args *args);
 	int (*sys_init_cmd)(struct s5p_mfc_dev *dev);
 	int (*sleep_cmd)(struct s5p_mfc_dev *dev);
 	int (*wakeup_cmd)(struct s5p_mfc_dev *dev);
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
index 1fbf7ed5d4cc..82ee6d300c73 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
@@ -14,7 +14,7 @@
 
 /* This function is used to send a command to the MFC */
 static int s5p_mfc_cmd_host2risc_v5(struct s5p_mfc_dev *dev, int cmd,
-				struct s5p_mfc_cmd_args *args)
+				    const struct s5p_mfc_cmd_args *args)
 {
 	int cur_cmd;
 	unsigned long timeout;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
index 740aa4dfae57..47bc3014b5d8 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
@@ -15,7 +15,7 @@
 #include "s5p_mfc_cmd_v6.h"
 
 static int s5p_mfc_cmd_host2risc_v6(struct s5p_mfc_dev *dev, int cmd,
-				struct s5p_mfc_cmd_args *args)
+				    const struct s5p_mfc_cmd_args *args)
 {
 	mfc_debug(2, "Issue the command: %d\n", cmd);
 

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:11 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:11 +0100
Subject: [PATCH 12/15] media: s5p-mfc: constify local pointers to
 s5p_mfc_enc_params
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-12-a3b246470fe4@linaro.org>

Constify the local variables pointing to "struct s5p_mfc_enc_params" and
other encoding params to annotate the function is not modifying pointed
data.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 .../media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c    | 14 +++++++-------
 .../media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c    | 18 +++++++++---------
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
index 2a0fb78e8e82..ba22c6a3219a 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
@@ -674,7 +674,7 @@ static int s5p_mfc_set_enc_ref_buffer_v5(struct s5p_mfc_ctx *ctx)
 static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	struct s5p_mfc_enc_params *p = &ctx->enc_params;
+	const struct s5p_mfc_enc_params *p = &ctx->enc_params;
 	unsigned int reg;
 	unsigned int shm;
 
@@ -757,8 +757,8 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
 static int s5p_mfc_set_enc_params_h264(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	struct s5p_mfc_enc_params *p = &ctx->enc_params;
-	struct s5p_mfc_h264_enc_params *p_264 = &p->codec.h264;
+	const struct s5p_mfc_enc_params *p = &ctx->enc_params;
+	const struct s5p_mfc_h264_enc_params *p_264 = &p->codec.h264;
 	unsigned int reg;
 	unsigned int shm;
 
@@ -914,8 +914,8 @@ static int s5p_mfc_set_enc_params_h264(struct s5p_mfc_ctx *ctx)
 static int s5p_mfc_set_enc_params_mpeg4(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	struct s5p_mfc_enc_params *p = &ctx->enc_params;
-	struct s5p_mfc_mpeg4_enc_params *p_mpeg4 = &p->codec.mpeg4;
+	const struct s5p_mfc_enc_params *p = &ctx->enc_params;
+	const struct s5p_mfc_mpeg4_enc_params *p_mpeg4 = &p->codec.mpeg4;
 	unsigned int reg;
 	unsigned int shm;
 	unsigned int framerate;
@@ -993,8 +993,8 @@ static int s5p_mfc_set_enc_params_mpeg4(struct s5p_mfc_ctx *ctx)
 static int s5p_mfc_set_enc_params_h263(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
-	struct s5p_mfc_enc_params *p = &ctx->enc_params;
-	struct s5p_mfc_mpeg4_enc_params *p_h263 = &p->codec.mpeg4;
+	const struct s5p_mfc_enc_params *p = &ctx->enc_params;
+	const struct s5p_mfc_mpeg4_enc_params *p_h263 = &p->codec.mpeg4;
 	unsigned int reg;
 	unsigned int shm;
 
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 6157c5f97707..08545213caa9 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -750,7 +750,7 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
-	struct s5p_mfc_enc_params *p = &ctx->enc_params;
+	const struct s5p_mfc_enc_params *p = &ctx->enc_params;
 	unsigned int reg = 0;
 
 	mfc_debug_enter();
@@ -1196,8 +1196,8 @@ static int s5p_mfc_set_enc_params_mpeg4(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
-	struct s5p_mfc_enc_params *p = &ctx->enc_params;
-	struct s5p_mfc_mpeg4_enc_params *p_mpeg4 = &p->codec.mpeg4;
+	const struct s5p_mfc_enc_params *p = &ctx->enc_params;
+	const struct s5p_mfc_mpeg4_enc_params *p_mpeg4 = &p->codec.mpeg4;
 	unsigned int reg = 0;
 
 	mfc_debug_enter();
@@ -1278,8 +1278,8 @@ static int s5p_mfc_set_enc_params_h263(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
-	struct s5p_mfc_enc_params *p = &ctx->enc_params;
-	struct s5p_mfc_mpeg4_enc_params *p_h263 = &p->codec.mpeg4;
+	const struct s5p_mfc_enc_params *p = &ctx->enc_params;
+	const struct s5p_mfc_mpeg4_enc_params *p_h263 = &p->codec.mpeg4;
 	unsigned int reg = 0;
 
 	mfc_debug_enter();
@@ -1348,8 +1348,8 @@ static int s5p_mfc_set_enc_params_vp8(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
-	struct s5p_mfc_enc_params *p = &ctx->enc_params;
-	struct s5p_mfc_vp8_enc_params *p_vp8 = &p->codec.vp8;
+	const struct s5p_mfc_enc_params *p = &ctx->enc_params;
+	const struct s5p_mfc_vp8_enc_params *p_vp8 = &p->codec.vp8;
 	unsigned int reg = 0;
 	unsigned int val = 0;
 
@@ -1737,8 +1737,8 @@ static int s5p_mfc_h264_set_aso_slice_order_v6(struct s5p_mfc_ctx *ctx)
 {
 	struct s5p_mfc_dev *dev = ctx->dev;
 	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
-	struct s5p_mfc_enc_params *p = &ctx->enc_params;
-	struct s5p_mfc_h264_enc_params *p_h264 = &p->codec.h264;
+	const struct s5p_mfc_enc_params *p = &ctx->enc_params;
+	const struct s5p_mfc_h264_enc_params *p_h264 = &p->codec.h264;
 	int i;
 
 	if (p_h264->aso) {

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:12 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:12 +0100
Subject: [PATCH 13/15] media: s5p-mfc: drop useless clock refcnt debugging
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-13-a3b246470fe4@linaro.org>

Drop useless debugging of clock enabl/disable counts, because core
handles this much better.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
index 187849841a28..29b141d4a7a7 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
@@ -16,7 +16,6 @@
 
 static struct s5p_mfc_pm *pm;
 static struct s5p_mfc_dev *p_dev;
-static atomic_t clk_ref;
 
 int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
 {
@@ -49,7 +48,6 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
 		pm->clock_gate = pm->clocks[0];
 
 	pm_runtime_enable(pm->device);
-	atomic_set(&clk_ref, 0);
 	return 0;
 }
 
@@ -60,17 +58,11 @@ void s5p_mfc_final_pm(struct s5p_mfc_dev *dev)
 
 int s5p_mfc_clock_on(void)
 {
-	atomic_inc(&clk_ref);
-	mfc_debug(3, "+ %d\n", atomic_read(&clk_ref));
-
 	return clk_enable(pm->clock_gate);
 }
 
 void s5p_mfc_clock_off(void)
 {
-	atomic_dec(&clk_ref);
-	mfc_debug(3, "- %d\n", atomic_read(&clk_ref));
-
 	clk_disable(pm->clock_gate);
 }
 

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:13 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:13 +0100
Subject: [PATCH 14/15] media: s5p-mfc: drop useless static s5p_mfc_dev in
 s5p_mfc_pm.c
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-14-a3b246470fe4@linaro.org>

Pointer "struct s5p_mfc_dev" is stored in s5p_mfc_pm.c once and never
used again.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
index 29b141d4a7a7..ecb3065c33c9 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
@@ -15,15 +15,12 @@
 #include "s5p_mfc_pm.h"
 
 static struct s5p_mfc_pm *pm;
-static struct s5p_mfc_dev *p_dev;
 
 int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
 {
 	int i;
 
 	pm = &dev->pm;
-	p_dev = dev;
-
 	pm->num_clocks = dev->variant->num_clocks;
 	pm->clk_names = dev->variant->clk_names;
 	pm->device = &dev->plat_dev->dev;

-- 
2.34.1



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:44:14 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:44:14 +0100
Subject: [PATCH 15/15] media: s5p-mfc: drop static device variable in
 s5p_mfc_pm.c
In-Reply-To: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
Message-ID: <20231224-n-s5p-mfc-const-v1-15-a3b246470fe4@linaro.org>

Change the interface of power management functions in s5p_mfc_pm.c to
accept the pointer to S5P MFC device structure. instead of relying on
file-scope static variable.  This makes code easier to read and modify
in case more devices are added.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
---
 drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c   | 42 +++++++++++-----------
 .../media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c  | 26 +++++++-------
 .../media/platform/samsung/s5p-mfc/s5p_mfc_dec.c   |  8 ++---
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c      |  4 +--
 .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c      |  8 ++---
 .../media/platform/samsung/s5p-mfc/s5p_mfc_pm.c    | 40 ++++++++++-----------
 .../media/platform/samsung/s5p-mfc/s5p_mfc_pm.h    |  8 ++---
 7 files changed, 67 insertions(+), 69 deletions(-)

diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
index 5d10c1cb8b92..f0bda2f7f1c2 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
@@ -183,7 +183,7 @@ static void s5p_mfc_watchdog_worker(struct work_struct *work)
 		mfc_err("Error: some instance may be closing/opening\n");
 	spin_lock_irqsave(&dev->irqlock, flags);
 
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 
 	for (i = 0; i < MFC_NUM_CONTEXTS; i++) {
 		ctx = dev->ctx[i];
@@ -211,9 +211,9 @@ static void s5p_mfc_watchdog_worker(struct work_struct *work)
 			mfc_err("Failed to reload FW\n");
 			goto unlock;
 		}
-		s5p_mfc_clock_on();
+		s5p_mfc_clock_on(dev);
 		ret = s5p_mfc_init_hw(dev);
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 		if (ret)
 			mfc_err("Failed to reinit FW\n");
 	}
@@ -393,7 +393,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
 		s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
 		wake_up_ctx(ctx, reason, err);
 		WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 		s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 		return;
 	}
@@ -465,7 +465,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
 	s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
 	wake_up_ctx(ctx, reason, err);
 	WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	/* if suspending, wake up device and do not try_run again*/
 	if (test_bit(0, &dev->enter_suspend))
 		wake_up_dev(dev, reason, err);
@@ -509,7 +509,7 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
 	}
 	WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
 	s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	wake_up_dev(dev, reason, err);
 }
 
@@ -565,7 +565,7 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
 	s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
 	clear_work_bit(ctx);
 	WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 	wake_up_ctx(ctx, reason, err);
 }
@@ -601,14 +601,14 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx *ctx,
 		}
 		WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
 
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 
 		wake_up(&ctx->queue);
 		s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 	} else {
 		WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
 
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 
 		wake_up(&ctx->queue);
 	}
@@ -636,7 +636,7 @@ static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx)
 
 	WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
 
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	wake_up(&ctx->queue);
 	s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 }
@@ -688,7 +688,7 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
 			}
 			s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
 			WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
-			s5p_mfc_clock_off();
+			s5p_mfc_clock_off(dev);
 			wake_up_ctx(ctx, reason, err);
 			s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 		} else {
@@ -752,7 +752,7 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
 	if (test_and_clear_bit(0, &dev->hw_lock) == 0)
 		mfc_err("Failed to unlock hw\n");
 
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	clear_work_bit(ctx);
 	wake_up(&ctx->queue);
 
@@ -837,20 +837,20 @@ static int s5p_mfc_open(struct file *file)
 		dev->watchdog_timer.expires = jiffies +
 					msecs_to_jiffies(MFC_WATCHDOG_INTERVAL);
 		add_timer(&dev->watchdog_timer);
-		ret = s5p_mfc_power_on();
+		ret = s5p_mfc_power_on(dev);
 		if (ret < 0) {
 			mfc_err("power on failed\n");
 			goto err_pwr_enable;
 		}
-		s5p_mfc_clock_on();
+		s5p_mfc_clock_on(dev);
 		ret = s5p_mfc_load_firmware(dev);
 		if (ret) {
-			s5p_mfc_clock_off();
+			s5p_mfc_clock_off(dev);
 			goto err_load_fw;
 		}
 		/* Init the FW */
 		ret = s5p_mfc_init_hw(dev);
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 		if (ret)
 			goto err_init_hw;
 	}
@@ -927,7 +927,7 @@ static int s5p_mfc_open(struct file *file)
 err_load_fw:
 err_pwr_enable:
 	if (dev->num_inst == 1) {
-		if (s5p_mfc_power_off() < 0)
+		if (s5p_mfc_power_off(dev) < 0)
 			mfc_err("power off failed\n");
 		del_timer_sync(&dev->watchdog_timer);
 	}
@@ -959,7 +959,7 @@ static int s5p_mfc_release(struct file *file)
 	vb2_queue_release(&ctx->vq_src);
 	vb2_queue_release(&ctx->vq_dst);
 	if (dev) {
-		s5p_mfc_clock_on();
+		s5p_mfc_clock_on(dev);
 
 		/* Mark context as idle */
 		clear_work_bit_irqsave(ctx);
@@ -979,12 +979,12 @@ static int s5p_mfc_release(struct file *file)
 			mfc_debug(2, "Last instance\n");
 			s5p_mfc_deinit_hw(dev);
 			del_timer_sync(&dev->watchdog_timer);
-			s5p_mfc_clock_off();
-			if (s5p_mfc_power_off() < 0)
+			s5p_mfc_clock_off(dev);
+			if (s5p_mfc_power_off(dev) < 0)
 				mfc_err("Power off failed\n");
 		} else {
 			mfc_debug(2, "Shutting down clock\n");
-			s5p_mfc_clock_off();
+			s5p_mfc_clock_off(dev);
 		}
 	}
 	if (dev)
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
index 6d3c92045c05..8eedf6524c39 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
@@ -215,7 +215,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
 
 	/* 0. MFC reset */
 	mfc_debug(2, "MFC reset..\n");
-	s5p_mfc_clock_on();
+	s5p_mfc_clock_on(dev);
 	dev->risc_on = 0;
 	ret = s5p_mfc_reset(dev);
 	if (ret) {
@@ -243,7 +243,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
 	if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_FW_STATUS_RET)) {
 		mfc_err("Failed to load firmware\n");
 		s5p_mfc_reset(dev);
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 		return -EIO;
 	}
 	s5p_mfc_clean_dev_int_flags(dev);
@@ -252,14 +252,14 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
 	if (ret) {
 		mfc_err("Failed to send command to MFC - timeout\n");
 		s5p_mfc_reset(dev);
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 		return ret;
 	}
 	mfc_debug(2, "Ok, now will wait for completion of hardware init\n");
 	if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_SYS_INIT_RET)) {
 		mfc_err("Failed to init hardware\n");
 		s5p_mfc_reset(dev);
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 		return -EIO;
 	}
 	dev->int_cond = 0;
@@ -269,7 +269,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
 		mfc_err("Failed to init firmware - error: %d int: %d\n",
 						dev->int_err, dev->int_type);
 		s5p_mfc_reset(dev);
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 		return -EIO;
 	}
 	if (IS_MFCV6_PLUS(dev))
@@ -279,7 +279,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
 
 	mfc_debug(2, "MFC F/W version : %02xyy, %02xmm, %02xdd\n",
 		(ver >> 16) & 0xFF, (ver >> 8) & 0xFF, ver & 0xFF);
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	mfc_debug_leave();
 	return 0;
 }
@@ -288,12 +288,12 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
 /* Deinitialize hardware */
 void s5p_mfc_deinit_hw(struct s5p_mfc_dev *dev)
 {
-	s5p_mfc_clock_on();
+	s5p_mfc_clock_on(dev);
 
 	s5p_mfc_reset(dev);
 	s5p_mfc_hw_call(dev->mfc_ops, release_dev_context_buffer, dev);
 
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 }
 
 int s5p_mfc_sleep(struct s5p_mfc_dev *dev)
@@ -301,7 +301,7 @@ int s5p_mfc_sleep(struct s5p_mfc_dev *dev)
 	int ret;
 
 	mfc_debug_enter();
-	s5p_mfc_clock_on();
+	s5p_mfc_clock_on(dev);
 	s5p_mfc_clean_dev_int_flags(dev);
 	ret = s5p_mfc_hw_call(dev->mfc_cmds, sleep_cmd, dev);
 	if (ret) {
@@ -312,7 +312,7 @@ int s5p_mfc_sleep(struct s5p_mfc_dev *dev)
 		mfc_err("Failed to sleep\n");
 		return -EIO;
 	}
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	dev->int_cond = 0;
 	if (dev->int_err != 0 || dev->int_type !=
 						S5P_MFC_R2H_CMD_SLEEP_RET) {
@@ -384,12 +384,12 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
 	mfc_debug_enter();
 	/* 0. MFC reset */
 	mfc_debug(2, "MFC reset..\n");
-	s5p_mfc_clock_on();
+	s5p_mfc_clock_on(dev);
 	dev->risc_on = 0;
 	ret = s5p_mfc_reset(dev);
 	if (ret) {
 		mfc_err("Failed to reset MFC - timeout\n");
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 		return ret;
 	}
 	mfc_debug(2, "Done MFC reset..\n");
@@ -404,7 +404,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
 	else
 		ret = s5p_mfc_wait_wakeup(dev);
 
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	if (ret)
 		return ret;
 
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
index eef26d4e02cf..b620db8896e1 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
@@ -477,7 +477,7 @@ static int reqbufs_output(struct s5p_mfc_dev *dev, struct s5p_mfc_ctx *ctx,
 {
 	int ret = 0;
 
-	s5p_mfc_clock_on();
+	s5p_mfc_clock_on(dev);
 
 	if (reqbufs->count == 0) {
 		mfc_debug(2, "Freeing buffers\n");
@@ -514,7 +514,7 @@ static int reqbufs_output(struct s5p_mfc_dev *dev, struct s5p_mfc_ctx *ctx,
 		ret = -EINVAL;
 	}
 out:
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	if (ret)
 		mfc_err("Failed allocating buffers for OUTPUT queue\n");
 	return ret;
@@ -525,7 +525,7 @@ static int reqbufs_capture(struct s5p_mfc_dev *dev, struct s5p_mfc_ctx *ctx,
 {
 	int ret = 0;
 
-	s5p_mfc_clock_on();
+	s5p_mfc_clock_on(dev);
 
 	if (reqbufs->count == 0) {
 		mfc_debug(2, "Freeing buffers\n");
@@ -568,7 +568,7 @@ static int reqbufs_capture(struct s5p_mfc_dev *dev, struct s5p_mfc_ctx *ctx,
 		ret = -EINVAL;
 	}
 out:
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(dev);
 	if (ret)
 		mfc_err("Failed allocating buffers for CAPTURE queue\n");
 	return ret;
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
index ba22c6a3219a..87492db83536 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
@@ -1346,7 +1346,7 @@ static void s5p_mfc_try_run_v5(struct s5p_mfc_dev *dev)
 	 * Last frame has already been sent to MFC.
 	 * Now obtaining frames from MFC buffer
 	 */
-	s5p_mfc_clock_on();
+	s5p_mfc_clock_on(dev);
 	s5p_mfc_clean_ctx_int_flags(ctx);
 
 	if (ctx->type == MFCINST_DECODER) {
@@ -1422,7 +1422,7 @@ static void s5p_mfc_try_run_v5(struct s5p_mfc_dev *dev)
 		 * scheduled, reduce the clock count as no one will
 		 * ever do this, because no interrupt related to this try_run
 		 * will ever come from hardware. */
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 	}
 }
 
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
index 08545213caa9..8908c159a91e 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1992,7 +1992,7 @@ static void s5p_mfc_try_run_v6(struct s5p_mfc_dev *dev)
 	/* Last frame has already been sent to MFC
 	 * Now obtaining frames from MFC buffer */
 
-	s5p_mfc_clock_on();
+	s5p_mfc_clock_on(dev);
 	s5p_mfc_clean_ctx_int_flags(ctx);
 
 	if (ctx->type == MFCINST_DECODER) {
@@ -2072,7 +2072,7 @@ static void s5p_mfc_try_run_v6(struct s5p_mfc_dev *dev)
 		 * scheduled, reduce the clock count as no one will
 		 * ever do this, because no interrupt related to this try_run
 		 * will ever come from hardware. */
-		s5p_mfc_clock_off();
+		s5p_mfc_clock_off(dev);
 	}
 }
 
@@ -2088,9 +2088,9 @@ s5p_mfc_read_info_v6(struct s5p_mfc_ctx *ctx, unsigned long ofs)
 {
 	int ret;
 
-	s5p_mfc_clock_on();
+	s5p_mfc_clock_on(ctx->dev);
 	ret = readl((void __iomem *)ofs);
-	s5p_mfc_clock_off();
+	s5p_mfc_clock_off(ctx->dev);
 
 	return ret;
 }
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
index ecb3065c33c9..ae4241408383 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
@@ -14,13 +14,11 @@
 #include "s5p_mfc_debug.h"
 #include "s5p_mfc_pm.h"
 
-static struct s5p_mfc_pm *pm;
-
 int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
 {
+	struct s5p_mfc_pm *pm = &dev->pm;
 	int i;
 
-	pm = &dev->pm;
 	pm->num_clocks = dev->variant->num_clocks;
 	pm->clk_names = dev->variant->clk_names;
 	pm->device = &dev->plat_dev->dev;
@@ -50,58 +48,58 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
 
 void s5p_mfc_final_pm(struct s5p_mfc_dev *dev)
 {
-	pm_runtime_disable(pm->device);
+	pm_runtime_disable(dev->pm.device);
 }
 
-int s5p_mfc_clock_on(void)
+int s5p_mfc_clock_on(struct s5p_mfc_dev *dev)
 {
-	return clk_enable(pm->clock_gate);
+	return clk_enable(dev->pm.clock_gate);
 }
 
-void s5p_mfc_clock_off(void)
+void s5p_mfc_clock_off(struct s5p_mfc_dev *dev)
 {
-	clk_disable(pm->clock_gate);
+	clk_disable(dev->pm.clock_gate);
 }
 
-int s5p_mfc_power_on(void)
+int s5p_mfc_power_on(struct s5p_mfc_dev *dev)
 {
 	int i, ret = 0;
 
-	ret = pm_runtime_resume_and_get(pm->device);
+	ret = pm_runtime_resume_and_get(dev->pm.device);
 	if (ret < 0)
 		return ret;
 
 	/* clock control */
-	for (i = 0; i < pm->num_clocks; i++) {
-		ret = clk_prepare_enable(pm->clocks[i]);
+	for (i = 0; i < dev->pm.num_clocks; i++) {
+		ret = clk_prepare_enable(dev->pm.clocks[i]);
 		if (ret < 0) {
 			mfc_err("clock prepare failed for clock: %s\n",
-				pm->clk_names[i]);
+				dev->pm.clk_names[i]);
 			goto err;
 		}
 	}
 
 	/* prepare for software clock gating */
-	clk_disable(pm->clock_gate);
+	clk_disable(dev->pm.clock_gate);
 
 	return 0;
 err:
 	while (--i >= 0)
-		clk_disable_unprepare(pm->clocks[i]);
-	pm_runtime_put(pm->device);
+		clk_disable_unprepare(dev->pm.clocks[i]);
+	pm_runtime_put(dev->pm.device);
 	return ret;
 }
 
-int s5p_mfc_power_off(void)
+int s5p_mfc_power_off(struct s5p_mfc_dev *dev)
 {
 	int i;
 
 	/* finish software clock gating */
-	clk_enable(pm->clock_gate);
+	clk_enable(dev->pm.clock_gate);
 
-	for (i = 0; i < pm->num_clocks; i++)
-		clk_disable_unprepare(pm->clocks[i]);
+	for (i = 0; i < dev->pm.num_clocks; i++)
+		clk_disable_unprepare(dev->pm.clocks[i]);
 
-	return pm_runtime_put_sync(pm->device);
+	return pm_runtime_put_sync(dev->pm.device);
 }
 
diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.h b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.h
index 4159d2364e87..9c71036f0385 100644
--- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.h
+++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.h
@@ -12,9 +12,9 @@
 int s5p_mfc_init_pm(struct s5p_mfc_dev *dev);
 void s5p_mfc_final_pm(struct s5p_mfc_dev *dev);
 
-int s5p_mfc_clock_on(void);
-void s5p_mfc_clock_off(void);
-int s5p_mfc_power_on(void);
-int s5p_mfc_power_off(void);
+int s5p_mfc_clock_on(struct s5p_mfc_dev *dev);
+void s5p_mfc_clock_off(struct s5p_mfc_dev *dev);
+int s5p_mfc_power_on(struct s5p_mfc_dev *dev);
+int s5p_mfc_power_off(struct s5p_mfc_dev *dev);
 
 #endif /* S5P_MFC_PM_H_ */

-- 
2.34.1



From josua at solid-run.com  Sun Dec 24 07:45:48 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 15:45:48 +0000
Subject: [PATCH v2 1/8] dt-bindings: marvell: a38x: convert the soc
 compatibles description to yaml
In-Reply-To: <495a0f12-2627-4c47-9d51-ca580d378652@kernel.org>
References: <20231224143750.5604-1-josua@solid-run.com>
 <20231224143750.5604-2-josua@solid-run.com>
 <495a0f12-2627-4c47-9d51-ca580d378652@kernel.org>
Message-ID: <a32f81b0-cd01-4290-8be7-83b94e4b504e@solid-run.com>

Am 24.12.23 um 15:57 schrieb Krzysztof Kozlowski:
> On 24/12/2023 15:37, Josua Mayer wrote:
>> Convert the existing txt binding for armada-38x socs to DT schema
>> format.
>>
>> Signed-off-by: Josua Mayer <josua at solid-run.com>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC. It might happen, that command when run on an older
> kernel, gives you outdated entries. Therefore please be sure you base
> your patches on recent Linux kernel.
>
> You missed at least devicetree list (maybe more), so this won't be
> tested by automated tooling. Performing review on untested code might be
> a waste of time, thus I will skip this patch entirely till you follow
> the process allowing the patch to be tested.
>
> Please kindly resend and include all necessary To/Cc entries.
I am sorry ...
I will verify what get_maintainers said ...

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#select-the-recipients-for-your-patch
I got confused from this guide - what to do when it tells me 3 or more 
lists.
Should I take the most specific one? Or all of them? I.e.:

linux-arm-kernel at lists.infradead.org (moderated list:ARM/Marvell 
Kirkwood and Armada 370, 375, 38x,...)
devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE 
TREE BINDINGS)
linux-kernel at vger.kernel.org (open list)

>
>> +
>> +properties:
>> +  $nodename:
>> +    const: '/'
>> +  compatible:
>> +    oneOf:
>> +
>> +      - description: Armada 380 SoC
>> +        items:
>> +          - const: marvell,armada380
>> +
>> +      - description: Armada 385 SoC
>> +        items:
>> +          - const: marvell,armada385
>> +          - const: marvell,armada380
>> +
>> +      - description: Armada 388 SoC
>> +        items:
>> +          - const: marvell,armada388
>> +          - const: marvell,armada385
>> +          - const: marvell,armada380
> These should not be used alone, so such schema is not what we want. We
> want boards to be documented with these SoCs.
There is only one Marvell example for armada-8k:
Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml

I mirrored how that conversion had been done from text to yaml.
If only boards belong in the yaml, then the conversion from txt will 
create an empty file,
to which I could then add specific boards on top.

>
> Best regards,
> Krzysztof
>
sincerely
Josua Mayer


From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:52:57 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:52:57 +0100
Subject: [PATCH v2 1/8] dt-bindings: marvell: a38x: convert the soc
 compatibles description to yaml
In-Reply-To: <a32f81b0-cd01-4290-8be7-83b94e4b504e@solid-run.com>
References: <20231224143750.5604-1-josua@solid-run.com>
 <20231224143750.5604-2-josua@solid-run.com>
 <495a0f12-2627-4c47-9d51-ca580d378652@kernel.org>
 <a32f81b0-cd01-4290-8be7-83b94e4b504e@solid-run.com>
Message-ID: <de3ada73-0e62-4b44-815d-69f5f9d2e60a@linaro.org>

On 24/12/2023 16:45, Josua Mayer wrote:
> Am 24.12.23 um 15:57 schrieb Krzysztof Kozlowski:
>> On 24/12/2023 15:37, Josua Mayer wrote:
>>> Convert the existing txt binding for armada-38x socs to DT schema
>>> format.
>>>
>>> Signed-off-by: Josua Mayer <josua at solid-run.com>
>> Please use scripts/get_maintainers.pl to get a list of necessary people
>> and lists to CC. It might happen, that command when run on an older
>> kernel, gives you outdated entries. Therefore please be sure you base
>> your patches on recent Linux kernel.
>>
>> You missed at least devicetree list (maybe more), so this won't be
>> tested by automated tooling. Performing review on untested code might be
>> a waste of time, thus I will skip this patch entirely till you follow
>> the process allowing the patch to be tested.
>>
>> Please kindly resend and include all necessary To/Cc entries.
> I am sorry ...
> I will verify what get_maintainers said ...
> 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#select-the-recipients-for-your-patch
> I got confused from this guide - what to do when it tells me 3 or more 
> lists.
> Should I take the most specific one? Or all of them? I.e.:
> 
> linux-arm-kernel at lists.infradead.org (moderated list:ARM/Marvell 
> Kirkwood and Armada 370, 375, 38x,...)
> devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE 
> TREE BINDINGS)
> linux-kernel at vger.kernel.org (open list)

The same what b4 and all scripts are doing: all lists. Why even
bothering in selective remove of people or lists?

> 
>>
>>> +
>>> +properties:
>>> +  $nodename:
>>> +    const: '/'
>>> +  compatible:
>>> +    oneOf:
>>> +
>>> +      - description: Armada 380 SoC
>>> +        items:
>>> +          - const: marvell,armada380
>>> +
>>> +      - description: Armada 385 SoC
>>> +        items:
>>> +          - const: marvell,armada385
>>> +          - const: marvell,armada380
>>> +
>>> +      - description: Armada 388 SoC
>>> +        items:
>>> +          - const: marvell,armada388
>>> +          - const: marvell,armada385
>>> +          - const: marvell,armada380
>> These should not be used alone, so such schema is not what we want. We
>> want boards to be documented with these SoCs.
> There is only one Marvell example for armada-8k:
> Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> 
> I mirrored how that conversion had been done from text to yaml.
> If only boards belong in the yaml, then the conversion from txt will 
> create an empty file,
> to which I could then add specific boards on top.


Marvell is a mess, someone should really take care about these files...

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Sun Dec 24 07:54:31 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 16:54:31 +0100
Subject: [PATCH v3 2/2] arm64: dts: imx93-var-som: Add Variscite
 VAR-SOM-MX93
In-Reply-To: <20231224124114.31119-3-othacehe@gnu.org>
References: <20231224124114.31119-1-othacehe@gnu.org>
 <20231224124114.31119-3-othacehe@gnu.org>
Message-ID: <2d9f170d-e7a0-4893-8efa-a6d2eee4f0a7@linaro.org>

On 24/12/2023 13:41, Mathieu Othacehe wrote:
> Add DTSI for Variscite VAR-SOM-MX93 System on Module and DTS for Variscite
> VAR-SOM-MX93 on Symphony evaluation board.
> 
> This version comes with:
> - NXP i.MX 93 Dual, 1.7GHz, Cortex-A55 + Cortex-M33
> - 2 GB of RAM
> - 16GB eMMC
> - 802.11ax/ac/a/b/g/n WiFi with 5.3 Bluetooth
> - CAN bus
> - Audio codec
> 
> Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From josua at solid-run.com  Sun Dec 24 08:02:00 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 16:02:00 +0000
Subject: [PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <d5698668-e589-4ce0-a66f-3b6f107aa257@kernel.org>
References: <20231224143850.5671-3-josua@solid-run.com>
 <20231224143850.5671-4-josua@solid-run.com>
 <d5698668-e589-4ce0-a66f-3b6f107aa257@kernel.org>
Message-ID: <cadd49fe-8910-4c41-a1de-6efde20d001a@solid-run.com>

Am 24.12.23 um 15:55 schrieb Krzysztof Kozlowski:
> On 24/12/2023 15:38, Josua Mayer wrote:
>> Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
>> boards.
>>
>> While they are just two variants, we have 3 device-tree:
>> - armada-388-clearfog.dts
>> - armada-388-clearfog-base.dts
>> - armada-388-clearfog-pro.dts
>>
>> While the first one is identical to the pro variant, the filename is
>> not, and neither are the compatible strings.
>>
>> The first is compatible to armada-380, 385, 388 and
>> solidrun,clearfog-a1.
>> The other two are compatible to the same, plus an additional string
>> including the pro/base as suffix.
>>
>> Add two bindings, one for the explicit pro and base variants using a
>> total of 5 compatibles, and one for the generic name using just 4.
>>
>> Signed-off-by: Josua Mayer <josua at solid-run.com>
>> ---
>>   .../bindings/arm/marvell/armada-38x.yaml      | 20 +++++++++++++++++++
>>   1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
>> index 5bc69c4fe34d..25c29b466094 100644
>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
>> @@ -38,4 +38,24 @@ properties:
>>             - const: marvell,armada385
>>             - const: marvell,armada380
>>   
>> +      - description: |
>> +          SolidRun Armada 388 SoM based clearfog board. This is
>> +          equivalent to clearfog pro, but lacks the "pro" label
>> +          in dtb filename and compatible strings.
>> +        items:
>> +          - const: solidrun,clearfog-a1
> SoM cannot be alone.

Please confirm, I think my wording above was not clear.

I meant to say "clearfog" devices based on a SoM,.
Armada 388 Clearfog Base / Pro are combinations of SoM and carrier.
Current device-trees do not mention a som-specific compatible string though.

This is in contrast to "Clearfog GTR" which
a) uses aramda-385
b) solders SoC to the board.

>
>> +          - const: marvell,armada388
>> +          - const: marvell,armada385
>> +          - const: marvell,armada380
>> +
>> +      - description: SolidRun Armada 388 SoM based clearfog board variants
>> +        items:
>> +          - enum:
>> +             - solidrun,clearfog-base-a1
> Board has name "base"?
Yes.
In marketing and in device-tree model field the board names are
Clearfog Base, Clearfog Pro
and historically just Clearfog, for the Pro.
>
> Still not tested...
>
> Best regards,
> Krzysztof
>


From josua at solid-run.com  Sun Dec 24 08:04:20 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 16:04:20 +0000
Subject: [PATCH v2 1/8] dt-bindings: marvell: a38x: convert the soc
 compatibles description to yaml
In-Reply-To: <de3ada73-0e62-4b44-815d-69f5f9d2e60a@linaro.org>
References: <20231224143750.5604-1-josua@solid-run.com>
 <20231224143750.5604-2-josua@solid-run.com>
 <495a0f12-2627-4c47-9d51-ca580d378652@kernel.org>
 <a32f81b0-cd01-4290-8be7-83b94e4b504e@solid-run.com>
 <de3ada73-0e62-4b44-815d-69f5f9d2e60a@linaro.org>
Message-ID: <30e45f02-15cc-4b97-94c8-e869a7eb51fd@solid-run.com>

Am 24.12.23 um 16:52 schrieb Krzysztof Kozlowski:
> On 24/12/2023 16:45, Josua Mayer wrote:
>> Am 24.12.23 um 15:57 schrieb Krzysztof Kozlowski:
>>> On 24/12/2023 15:37, Josua Mayer wrote:
>>>> Convert the existing txt binding for armada-38x socs to DT schema
>>>> format.
>>>>
>>>> Signed-off-by: Josua Mayer <josua at solid-run.com>
>>> Please use scripts/get_maintainers.pl to get a list of necessary people
>>> and lists to CC. It might happen, that command when run on an older
>>> kernel, gives you outdated entries. Therefore please be sure you base
>>> your patches on recent Linux kernel.
>>>
>>> You missed at least devicetree list (maybe more), so this won't be
>>> tested by automated tooling. Performing review on untested code might be
>>> a waste of time, thus I will skip this patch entirely till you follow
>>> the process allowing the patch to be tested.
>>>
>>> Please kindly resend and include all necessary To/Cc entries.
>> I am sorry ...
>> I will verify what get_maintainers said ...
>>
>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#select-the-recipients-for-your-patch
>> I got confused from this guide - what to do when it tells me 3 or more
>> lists.
>> Should I take the most specific one? Or all of them? I.e.:
>>
>> linux-arm-kernel at lists.infradead.org (moderated list:ARM/Marvell
>> Kirkwood and Armada 370, 375, 38x,...)
>> devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE
>> TREE BINDINGS)
>> linux-kernel at vger.kernel.org (open list)
> The same what b4 and all scripts are doing: all lists. Why even
> bothering in selective remove of people or lists?
Understood, thank you.
>
>>>> +
>>>> +properties:
>>>> +  $nodename:
>>>> +    const: '/'
>>>> +  compatible:
>>>> +    oneOf:
>>>> +
>>>> +      - description: Armada 380 SoC
>>>> +        items:
>>>> +          - const: marvell,armada380
>>>> +
>>>> +      - description: Armada 385 SoC
>>>> +        items:
>>>> +          - const: marvell,armada385
>>>> +          - const: marvell,armada380
>>>> +
>>>> +      - description: Armada 388 SoC
>>>> +        items:
>>>> +          - const: marvell,armada388
>>>> +          - const: marvell,armada385
>>>> +          - const: marvell,armada380
>>> These should not be used alone, so such schema is not what we want. We
>>> want boards to be documented with these SoCs.
>> There is only one Marvell example for armada-8k:
>> Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>
>> I mirrored how that conversion had been done from text to yaml.
>> If only boards belong in the yaml, then the conversion from txt will
>> create an empty file,
>> to which I could then add specific boards on top.
>
> Marvell is a mess, someone should really take care about these files...
Okay ... so better to re-open discussion once I submit properly?
>
> Best regards,
> Krzysztof
>


From krzysztof.kozlowski at linaro.org  Sun Dec 24 08:09:37 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sun, 24 Dec 2023 17:09:37 +0100
Subject: [PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <cadd49fe-8910-4c41-a1de-6efde20d001a@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
 <20231224143850.5671-4-josua@solid-run.com>
 <d5698668-e589-4ce0-a66f-3b6f107aa257@kernel.org>
 <cadd49fe-8910-4c41-a1de-6efde20d001a@solid-run.com>
Message-ID: <0be16ab8-8be4-4af4-af0b-4287beeb0386@linaro.org>

On 24/12/2023 17:02, Josua Mayer wrote:
> Am 24.12.23 um 15:55 schrieb Krzysztof Kozlowski:
>> On 24/12/2023 15:38, Josua Mayer wrote:
>>> Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
>>> boards.
>>>
>>> While they are just two variants, we have 3 device-tree:
>>> - armada-388-clearfog.dts
>>> - armada-388-clearfog-base.dts
>>> - armada-388-clearfog-pro.dts
>>>
>>> While the first one is identical to the pro variant, the filename is
>>> not, and neither are the compatible strings.
>>>
>>> The first is compatible to armada-380, 385, 388 and
>>> solidrun,clearfog-a1.
>>> The other two are compatible to the same, plus an additional string
>>> including the pro/base as suffix.
>>>
>>> Add two bindings, one for the explicit pro and base variants using a
>>> total of 5 compatibles, and one for the generic name using just 4.
>>>
>>> Signed-off-by: Josua Mayer <josua at solid-run.com>
>>> ---
>>>   .../bindings/arm/marvell/armada-38x.yaml      | 20 +++++++++++++++++++
>>>   1 file changed, 20 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
>>> index 5bc69c4fe34d..25c29b466094 100644
>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
>>> @@ -38,4 +38,24 @@ properties:
>>>             - const: marvell,armada385
>>>             - const: marvell,armada380
>>>   
>>> +      - description: |
>>> +          SolidRun Armada 388 SoM based clearfog board. This is
>>> +          equivalent to clearfog pro, but lacks the "pro" label
>>> +          in dtb filename and compatible strings.
>>> +        items:
>>> +          - const: solidrun,clearfog-a1
>> SoM cannot be alone.
> 
> Please confirm, I think my wording above was not clear.
> 
> I meant to say "clearfog" devices based on a SoM,.
> Armada 388 Clearfog Base / Pro are combinations of SoM and carrier.
> Current device-trees do not mention a som-specific compatible string though.

So Clearfog Base is a board, then what is Clearfog A1?

> 
> This is in contrast to "Clearfog GTR" which
> a) uses aramda-385
> b) solders SoC to the board.
> 
>>
>>> +          - const: marvell,armada388
>>> +          - const: marvell,armada385
>>> +          - const: marvell,armada380
>>> +
>>> +      - description: SolidRun Armada 388 SoM based clearfog board variants
>>> +        items:
>>> +          - enum:
>>> +             - solidrun,clearfog-base-a1
>> Board has name "base"?
> Yes.
> In marketing and in device-tree model field the board names are
> Clearfog Base, Clearfog Pro

Then clearfog-base or clearfog-a1-base, but why a1 is at the end? Or is
it the case that Clearfog Base can have different SoMs? Think what you
have there and choose appropriate compatibles. See Renesas SMARC for one
choice and iMX Toradex boards for different example

> 

Best regards,
Krzysztof



From josua at solid-run.com  Sun Dec 24 08:29:35 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sun, 24 Dec 2023 16:29:35 +0000
Subject: [PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <0be16ab8-8be4-4af4-af0b-4287beeb0386@linaro.org>
References: <20231224143850.5671-3-josua@solid-run.com>
 <20231224143850.5671-4-josua@solid-run.com>
 <d5698668-e589-4ce0-a66f-3b6f107aa257@kernel.org>
 <cadd49fe-8910-4c41-a1de-6efde20d001a@solid-run.com>
 <0be16ab8-8be4-4af4-af0b-4287beeb0386@linaro.org>
Message-ID: <28729f48-1357-4f3a-bd7b-e9c34bcf2c58@solid-run.com>

Am 24.12.23 um 17:09 schrieb Krzysztof Kozlowski:
> On 24/12/2023 17:02, Josua Mayer wrote:
>> Am 24.12.23 um 15:55 schrieb Krzysztof Kozlowski:
>>> On 24/12/2023 15:38, Josua Mayer wrote:
>>>> Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
>>>> boards.
>>>>
>>>> While they are just two variants, we have 3 device-tree:
>>>> - armada-388-clearfog.dts
>>>> - armada-388-clearfog-base.dts
>>>> - armada-388-clearfog-pro.dts
>>>>
>>>> While the first one is identical to the pro variant, the filename is
>>>> not, and neither are the compatible strings.
>>>>
>>>> The first is compatible to armada-380, 385, 388 and
>>>> solidrun,clearfog-a1.
>>>> The other two are compatible to the same, plus an additional string
>>>> including the pro/base as suffix.
>>>>
>>>> Add two bindings, one for the explicit pro and base variants using a
>>>> total of 5 compatibles, and one for the generic name using just 4.
>>>>
>>>> Signed-off-by: Josua Mayer <josua at solid-run.com>
>>>> ---
>>>>    .../bindings/arm/marvell/armada-38x.yaml      | 20 +++++++++++++++++++
>>>>    1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
>>>> index 5bc69c4fe34d..25c29b466094 100644
>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
>>>> @@ -38,4 +38,24 @@ properties:
>>>>              - const: marvell,armada385
>>>>              - const: marvell,armada380
>>>>    
>>>> +      - description: |
>>>> +          SolidRun Armada 388 SoM based clearfog board. This is
>>>> +          equivalent to clearfog pro, but lacks the "pro" label
>>>> +          in dtb filename and compatible strings.
>>>> +        items:
>>>> +          - const: solidrun,clearfog-a1
>>> SoM cannot be alone.
>> Please confirm, I think my wording above was not clear.
>>
>> I meant to say "clearfog" devices based on a SoM,.
>> Armada 388 Clearfog Base / Pro are combinations of SoM and carrier.
>> Current device-trees do not mention a som-specific compatible string though.
> So Clearfog Base is a board, then what is Clearfog A1?
"Clearfog A1" is printed on the silk screen of a Clearfog Pro revision 
2.0 or earlier.
I don't have a later revision to look at.
So Clearfog A1 and Clearfog Pro? and Clearfog Pro A1 all mean the same 
board,
Clearfog Base (+-A1) mean the other board.

"-a1" of the compatible string is already used by openwrt to differentiate.

>
>> This is in contrast to "Clearfog GTR" which
>> a) uses aramda-385
>> b) solders SoC to the board.
>>
>>>> +          - const: marvell,armada388
>>>> +          - const: marvell,armada385
>>>> +          - const: marvell,armada380
>>>> +
>>>> +      - description: SolidRun Armada 388 SoM based clearfog board variants
>>>> +        items:
>>>> +          - enum:
>>>> +             - solidrun,clearfog-base-a1
>>> Board has name "base"?
>> Yes.
>> In marketing and in device-tree model field the board names are
>> Clearfog Base, Clearfog Pro
> Then clearfog-base or clearfog-a1-base, but why a1 is at the end? Or is
> it the case that Clearfog Base can have different SoMs? Think what you
> have there and choose appropriate compatibles. See Renesas SMARC for one
> choice and iMX Toradex boards for different example
Conceptually at this point, is it worth changing the compatibles of 
existing boards to make sense?
Or better to describe them in yaml as they are now (ensuring language is 
understood)?

If I try really hard, I can add a new armada-388 som compatible, but 
that opens another can.
There are other boards also based on the solidrun armada-388 SoMs, e.g. 
helios4 - and
there is no shared -som dtsi.
Effectively I guess they are all just individual boards, maybe not worth 
mentioning "SoM".

>
> Best regards,
> Krzysztof
>


From Frank.Li at nxp.com  Sun Dec 24 10:32:26 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:26 -0500
Subject: [PATCH v6 00/16] PCI: imx6: Clean up and add imx95 pci support
Message-ID: <20231224183242.1675372-1-Frank.Li@nxp.com>

first 6 patches use drvdata: flags to simplify some switch-case code.
Improve maintaince and easy to read code.

Then add imx95 basic pci host function.

follow two patch do endpoint code clean up.
Then add imx95 basic endpont function.

Compared with v2, added EP function support and some fixes,  please change
notes at each patches.

dt-binding pass pcie node:

pcie0: pcie at 4c300000 {
                        compatible = "fsl,imx95-pcie";
                        reg = <0 0x4c300000 0 0x40000>,
                                <0 0x4c360000 0 0x10000>,
                                <0 0x4c340000 0 0x20000>,
                                <0 0x60100000 0 0xfe00000>;
                        reg-names = "dbi", "atu", "app", "config";
                        #address-cells = <3>;
                        #size-cells = <2>;
                        device_type = "pci";
                        linux,pci-domain = <0>;
                        bus-range = <0x00 0xff>;
                        ranges = <0x81000000 0x0 0x00000000 0x0 0x6ff00000 0 0x00100000>,
                                 <0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000>;
                        num-lanes = <1>;
                        num-viewport = <8>;
                        interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
                        interrupt-names = "msi";
                        #interrupt-cells = <1>;
                        interrupt-map-mask = <0 0 0 0x7>;
                        interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 2 &gic 0 0 GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 3 &gic 0 0 GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 4 &gic 0 0 GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
                        fsl,max-link-speed = <3>;
                        clocks = <&scmi_clk IMX95_CLK_HSIO>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                 <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux";
                        assigned-clocks =<&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                         <&scmi_clk IMX95_CLK_HSIOPLL>,
                                         <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        assigned-clock-rates = <3600000000>, <100000000>, <10000000>;
                        assigned-clock-parents = <0>, <0>,
                                                 <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
                        power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
                        /* 0x30~0x37 stream id for pci0 */
                        /*
                         * iommu-map = <0x000 &apps_smmu 0x30 0x1>,
                         * <0x100 &apps_smmu 0x31 0x1>;
                         */
                        status = "disabled";
                };

pcie1: pcie-ep at 4c380000 {
                        compatible = "fsl,imx95-pcie-ep";
                        reg = <0 0x4c380000 0 0x20000>,
                              <0 0x4c3e0000 0 0x1000>,
                              <0 0x4c3a0000 0 0x1000>,
                              <0 0x4c3c0000 0 0x10000>,
                              <0 0x4c3f0000 0 0x10000>,
                              <0xa 0 1 0>;
                        reg-names = "dbi", "atu", "dbi2", "app", "dma", "addr_space";
                        interrupts = <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>;
                        interrupt-names = "dma";
                        fsl,max-link-speed = <3>;
                        clocks = <&scmi_clk IMX95_CLK_HSIO>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                 <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux";
                        assigned-clocks =<&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                         <&scmi_clk IMX95_CLK_HSIOPLL>,
                                         <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        assigned-clock-rates = <3600000000>, <100000000>, <10000000>;
                        assigned-clock-parents = <0>, <0>,
                                                 <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
                        power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
                        status = "disabled";
                };

Frank Li (15):
  PCI: imx6: Simplify clock handling by using bulk_clk_*() function
  PCI: imx6: Simplify phy handling by using by using
    IMX6_PCIE_FLAG_HAS_PHY
  PCI: imx6: Simplify reset handling by using by using
    *_FLAG_HAS_*_RESET
  dt-bindings: imx6q-pcie: Add linux,pci-domain as required for iMX8MQ
  PCI: imx6: Using "linux,pci-domain" as slot ID
  PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
  PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
  PCI: imx6: Simplify switch-case logic by involve init_phy callback
  dt-bindings: imx6q-pcie: Clean up irrationality clocks check
  dt-bindings: imx6q-pcie: restruct reg and reg-name
  PCI: imx6: Add iMX95 PCIe support
  PCI: imx6: Clean up get addr_space code
  PCI: imx6: Add epc_features in imx6_pcie_drvdata
  dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
  PCI: imx6: Add iMX95 Endpoint (EP) function support

Richard Zhu (1):
  dt-bindings: imx6q-pcie: Add imx95 pcie compatible string

 .../bindings/pci/fsl,imx6q-pcie-common.yaml   |  28 +-
 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       |  57 +-
 .../bindings/pci/fsl,imx6q-pcie.yaml          |  49 +-
 drivers/pci/controller/dwc/pci-imx6.c         | 628 ++++++++++--------
 4 files changed, 452 insertions(+), 310 deletions(-)

-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:27 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:27 -0500
Subject: [PATCH v6 01/16] PCI: imx6: Simplify clock handling by using bulk_clk_*() function
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-2-Frank.Li@nxp.com>

Refactors the clock handling logic. Adds clk_names[] define in drvdata.
Using clk_bulk*() api simplifies the code.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5
    - update commit message
    - direct using clk name list, instead of macro
    - still keep caculate clk list count because sizeof return pre allocated
    array size.
    
    Change from v3 to v4
    - using clk_bulk_*() API
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 125 ++++++++------------------
 1 file changed, 35 insertions(+), 90 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 74703362aeec7..50d9faaa17f71 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -61,12 +61,15 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 
+#define IMX6_PCIE_MAX_CLKS       6
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
 	u32 flags;
 	int dbi_length;
 	const char *gpr;
+	const char *clk_names[IMX6_PCIE_MAX_CLKS];
 };
 
 struct imx6_pcie {
@@ -74,11 +77,8 @@ struct imx6_pcie {
 	int			reset_gpio;
 	bool			gpio_active_high;
 	bool			link_is_up;
-	struct clk		*pcie_bus;
-	struct clk		*pcie_phy;
-	struct clk		*pcie_inbound_axi;
-	struct clk		*pcie;
-	struct clk		*pcie_aux;
+	struct clk_bulk_data	clks[IMX6_PCIE_MAX_CLKS];
+	u32			clks_cnt;
 	struct regmap		*iomuxc_gpr;
 	u16			msi_ctrl;
 	u32			controller_id;
@@ -407,13 +407,18 @@ static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
 
 static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
 {
-	unsigned long phy_rate = clk_get_rate(imx6_pcie->pcie_phy);
+	unsigned long phy_rate = 0;
 	int mult, div;
 	u16 val;
+	int i;
 
 	if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
 		return 0;
 
+	for (i = 0; i < imx6_pcie->clks_cnt; i++)
+		if (strncmp(imx6_pcie->clks[i].id, "pcie_phy", 8) == 0)
+			phy_rate = clk_get_rate(imx6_pcie->clks[i].clk);
+
 	switch (phy_rate) {
 	case 125000000:
 		/*
@@ -550,19 +555,11 @@ static int imx6_pcie_attach_pd(struct device *dev)
 
 static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	struct dw_pcie *pci = imx6_pcie->pci;
-	struct device *dev = pci->dev;
 	unsigned int offset;
 	int ret = 0;
 
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX6SX:
-		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_axi clock\n");
-			break;
-		}
-
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
 		break;
@@ -589,12 +586,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_aux clock\n");
-			break;
-		}
-
 		offset = imx6_pcie_grp_offset(imx6_pcie);
 		/*
 		 * Set the over ride low and enabled
@@ -615,9 +606,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		clk_disable_unprepare(imx6_pcie->pcie_inbound_axi);
-		break;
 	case IMX6QP:
 	case IMX6Q:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
@@ -631,14 +619,6 @@ static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		clk_disable_unprepare(imx6_pcie->pcie_aux);
-		break;
 	default:
 		break;
 	}
@@ -650,23 +630,9 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 	struct device *dev = pci->dev;
 	int ret;
 
-	ret = clk_prepare_enable(imx6_pcie->pcie_phy);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie_phy clock\n");
+	ret =  clk_bulk_prepare_enable(imx6_pcie->clks_cnt, imx6_pcie->clks);
+	if (ret)
 		return ret;
-	}
-
-	ret = clk_prepare_enable(imx6_pcie->pcie_bus);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie_bus clock\n");
-		goto err_pcie_bus;
-	}
-
-	ret = clk_prepare_enable(imx6_pcie->pcie);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie clock\n");
-		goto err_pcie;
-	}
 
 	ret = imx6_pcie_enable_ref_clk(imx6_pcie);
 	if (ret) {
@@ -679,11 +645,7 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 	return 0;
 
 err_ref_clk:
-	clk_disable_unprepare(imx6_pcie->pcie);
-err_pcie:
-	clk_disable_unprepare(imx6_pcie->pcie_bus);
-err_pcie_bus:
-	clk_disable_unprepare(imx6_pcie->pcie_phy);
+	clk_bulk_disable_unprepare(imx6_pcie->clks_cnt, imx6_pcie->clks);
 
 	return ret;
 }
@@ -691,9 +653,7 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 {
 	imx6_pcie_disable_ref_clk(imx6_pcie);
-	clk_disable_unprepare(imx6_pcie->pcie);
-	clk_disable_unprepare(imx6_pcie->pcie_bus);
-	clk_disable_unprepare(imx6_pcie->pcie_phy);
+	clk_bulk_disable_unprepare(imx6_pcie->clks_cnt, imx6_pcie->clks);
 }
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
@@ -1305,32 +1265,19 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return imx6_pcie->reset_gpio;
 	}
 
-	/* Fetch clocks */
-	imx6_pcie->pcie_bus = devm_clk_get(dev, "pcie_bus");
-	if (IS_ERR(imx6_pcie->pcie_bus))
-		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_bus),
-				     "pcie_bus clock source missing or invalid\n");
+	while (imx6_pcie->drvdata->clk_names[imx6_pcie->clks_cnt]) {
+		int i = imx6_pcie->clks_cnt;
+
+		imx6_pcie->clks[i].id = imx6_pcie->drvdata->clk_names[i];
+		imx6_pcie->clks_cnt++;
+	}
 
-	imx6_pcie->pcie = devm_clk_get(dev, "pcie");
-	if (IS_ERR(imx6_pcie->pcie))
-		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
-				     "pcie clock source missing or invalid\n");
+	/* Fetch clocks */
+	ret = devm_clk_bulk_get(dev, imx6_pcie->clks_cnt, imx6_pcie->clks);
+	if (ret)
+		return ret;
 
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
-							   "pcie_inbound_axi");
-		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
-					     "pcie_inbound_axi clock missing or invalid\n");
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
-		fallthrough;
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
 			imx6_pcie->controller_id = 1;
@@ -1353,10 +1300,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	case IMX8MM_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
 		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
 									 "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
@@ -1372,14 +1315,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	default:
 		break;
 	}
-	/* Don't fetch the pcie_phy clock, if it has abstract PHY driver */
-	if (imx6_pcie->phy == NULL) {
-		imx6_pcie->pcie_phy = devm_clk_get(dev, "pcie_phy");
-		if (IS_ERR(imx6_pcie->pcie_phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_phy),
-					     "pcie_phy clock source missing or invalid\n");
-	}
-
 
 	/* Grab turnoff reset */
 	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
@@ -1477,6 +1412,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1484,6 +1420,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_inbound_axi"},
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1492,40 +1429,48 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:28 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:28 -0500
Subject: [PATCH v6 02/16] PCI: imx6: Simplify phy handling by using by using IMX6_PCIE_FLAG_HAS_PHY
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-3-Frank.Li@nxp.com>

Refactors the phy handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_PHY bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling phy.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5:
    - none, Keep IMX6_PCIE_FLAG_HAS_PHY to indicate dts mismatch when platform
    require phy suppport.
    
    Change from v1 to v3:
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 50d9faaa17f71..4d620249f3d52 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -60,6 +60,9 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
+#define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
+
+#define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
 #define IMX6_PCIE_MAX_CLKS       6
 
@@ -1277,6 +1280,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY)) {
+		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+		if (IS_ERR(imx6_pcie->phy))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
+					     "failed to get pcie phy\n");
+	}
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
@@ -1306,11 +1316,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
 
-		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
-		if (IS_ERR(imx6_pcie->phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
-					     "failed to get pcie phy\n");
-
 		break;
 	default:
 		break;
@@ -1444,13 +1449,15 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
@@ -1462,12 +1469,14 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:29 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:29 -0500
Subject: [PATCH v6 03/16] PCI: imx6: Simplify reset handling by using by using *_FLAG_HAS_*_RESET
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-4-Frank.Li@nxp.com>

Refactors the reset handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling reset.

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5:
    - Add Mani's Reviewed-by tag
    - Fixed MQ_EP's flags
    
    Chagne from v3 to v4:
    - none
    Change from v2 to v3:
    - add Philipp's Reviewed-by tag
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.
    
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.

 drivers/pci/controller/dwc/pci-imx6.c | 108 ++++++++++----------------
 1 file changed, 41 insertions(+), 67 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 4d620249f3d52..294f61a9c6fd9 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -61,6 +61,8 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
+#define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
+#define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -661,18 +663,10 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 {
+	reset_control_assert(imx6_pcie->pciephy_reset);
+	reset_control_assert(imx6_pcie->apps_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_assert(imx6_pcie->pciephy_reset);
-		fallthrough;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
-		break;
 	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
@@ -693,6 +687,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
 		break;
+	default:
+		break;
 	}
 
 	/* Some boards don't have PCIe reset GPIO. */
@@ -706,14 +702,10 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
 
+	reset_control_deassert(imx6_pcie->pciephy_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-		break;
 	case IMX7D:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
 		 * Corrector" and other mysterious undocumented things.
@@ -745,11 +737,7 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 
 		usleep_range(200, 500);
 		break;
-	case IMX6Q:		/* Nothing to do */
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
+	default:
 		break;
 	}
 
@@ -796,16 +784,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2,
 				   IMX6Q_GPR12_PCIE_CTL_2);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_deassert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_deassert(imx6_pcie->apps_reset);
 }
 
 static void imx6_pcie_ltssm_disable(struct device *dev)
@@ -819,16 +802,11 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_assert(imx6_pcie->apps_reset);
 }
 
 static int imx6_pcie_start_link(struct dw_pcie *pci)
@@ -1287,36 +1265,24 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "failed to get pcie phy\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-
-		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
-									    "pciephy");
-		if (IS_ERR(imx6_pcie->pciephy_reset)) {
-			dev_err(dev, "Failed to get PCIEPHY reset control\n");
-			return PTR_ERR(imx6_pcie->pciephy_reset);
-		}
-
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
-		if (IS_ERR(imx6_pcie->apps_reset)) {
-			dev_err(dev, "Failed to get PCIE APPS reset control\n");
-			return PTR_ERR(imx6_pcie->apps_reset);
-		}
-		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET)) {
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev, "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
+	}
 
-		break;
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET)) {
+		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev, "pciephy");
+		if (IS_ERR(imx6_pcie->pciephy_reset))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pciephy_reset),
+					     "Failed to get PCIEPHY reset control\n");
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX7D:
+		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
+			imx6_pcie->controller_id = 1;
 	default:
 		break;
 	}
@@ -1438,31 +1404,39 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
+		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:30 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:30 -0500
Subject: [PATCH v6 04/16] dt-bindings: imx6q-pcie: Add linux,pci-domain as required for iMX8MQ
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-5-Frank.Li@nxp.com>

iMX8MQ have two pci controllers. Adds "linux,pci-domain" as required
proptery for iMX8MQ to indicate pci controller index.

This adjustment paves the way for eliminating the hardcoded check on the
base register for acquiring the controller_id.

	...
	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
		imx6_pcie->controller_id = 1;
	...

The controller_id is crucial and utilized for certain register bit
positions. It must align precisely with the controller index in the SoC.
An auto-incremented ID don't fit this case. The DTS or fuse configurations
may deactivate specific PCI controllers.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v5 to v6
    - rework commit message to explain why need required and why auto increase
    id not work
    
    Change from v4 to v5
    - new patch at v5

 .../bindings/pci/fsl,imx6q-pcie-common.yaml           | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index d91b639ae7ae7..8f39b4e6e8491 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -265,6 +265,17 @@ allOf:
             - const: apps
             - const: turnoff
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fsl,imx8mq-pcie
+              - fsl,imx8mq-pcie-ep
+    then:
+      required:
+        - linux,pci-domain
+
 additionalProperties: true
 
 ...
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:31 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:31 -0500
Subject: [PATCH v6 05/16] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-6-Frank.Li@nxp.com>

Avoid use get slot id by compared with register physical address. If there
are more than 2 slots, compared logic will become complex.

"linux,pci-domain" already exist at dts since commit:
	commit (c0b70f05c87f3b arm64: dts: imx8mq: use_dt_domains for pci node).

So it is safe to remove compare basic address code:
	...
	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
		imx6_pcie->controller_id = 1;
	...

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v3 to v4
    - remove compare basic address logic
    Change from v2 to v3
    - none
    Change from v1 to v2
    - fix of_get_pci_domain_nr return value check logic

 drivers/pci/controller/dwc/pci-imx6.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 294f61a9c6fd9..332c392f8e5bc 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -33,6 +33,7 @@
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
+#include "../../pci.h"
 #include "pcie-designware.h"
 
 #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
@@ -40,7 +41,6 @@
 #define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE	BIT(11)
 #define IMX8MQ_GPR_PCIE_VREG_BYPASS		BIT(12)
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
-#define IMX8MQ_PCIE2_BASE_ADDR			0x33c00000
 
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
@@ -1279,13 +1279,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "Failed to get PCIEPHY reset control\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-	default:
-		break;
-	}
+	/* Using linux,pci-domain as PCI slot id */
+	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
+	/* If there are not "linux,pci-domain" in dts file, means only 1 controller */
+	if (imx6_pcie->controller_id == -EINVAL)
+		imx6_pcie->controller_id = 0;
+	else if (imx6_pcie->controller_id < 0)
+		return dev_err_probe(dev, imx6_pcie->controller_id,
+				     "linux,pci-domain have wrong value\n");
 
 	/* Grab turnoff reset */
 	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:32 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:32 -0500
Subject: [PATCH v6 06/16] PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-7-Frank.Li@nxp.com>

Add drvdata::ltssm_off and drvdata::ltssm_mask to simple
imx6_pcie_ltssm_enable(disable)() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 37 ++++++++++++---------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 332c392f8e5bc..588bfb616260e 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,8 @@ struct imx6_pcie_drvdata {
 	int dbi_length;
 	const char *gpr;
 	const char *clk_names[IMX6_PCIE_MAX_CLKS];
+	const u32 ltssm_off;
+	const u32 ltssm_mask;
 };
 
 struct imx6_pcie {
@@ -775,18 +777,11 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_ltssm_enable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2,
-				   IMX6Q_GPR12_PCIE_CTL_2);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off, drvdata->ltssm_mask,
+				   drvdata->ltssm_mask);
 
 	reset_control_deassert(imx6_pcie->apps_reset);
 }
@@ -794,17 +789,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 static void imx6_pcie_ltssm_disable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2, 0);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off,
+				   drvdata->ltssm_mask, 0);
 
 	reset_control_assert(imx6_pcie->apps_reset);
 }
@@ -1385,6 +1374,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1393,6 +1384,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_inbound_axi"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1402,6 +1395,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:33 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:33 -0500
Subject: [PATCH v6 07/16] PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-8-Frank.Li@nxp.com>

Add drvdata::mode_off and drvdata::mode_mask to simple
imx6_pcie_configure_type() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v2 to v3
    - none
    Change from v1 to v2
    - use ffs() to fixe build error.

 drivers/pci/controller/dwc/pci-imx6.c | 60 ++++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 588bfb616260e..717e8fa030deb 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -68,6 +68,7 @@ enum imx6_pcie_variants {
 
 #define IMX6_PCIE_MAX_CLKS       6
 
+#define IMX6_PCIE_MAX_INSTANCES			2
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -77,6 +78,8 @@ struct imx6_pcie_drvdata {
 	const char *clk_names[IMX6_PCIE_MAX_CLKS];
 	const u32 ltssm_off;
 	const u32 ltssm_mask;
+	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
+	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
 };
 
 struct imx6_pcie {
@@ -174,32 +177,25 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
-	unsigned int mask, val, mode;
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
+	unsigned int mask, val, mode, id;
 
-	if (imx6_pcie->drvdata->mode == DW_PCIE_EP_TYPE)
+	if (drvdata->mode == DW_PCIE_EP_TYPE)
 		mode = PCI_EXP_TYPE_ENDPOINT;
 	else
 		mode = PCI_EXP_TYPE_ROOT_PORT;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		if (imx6_pcie->controller_id == 1) {
-			mask = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
-					  mode);
-		} else {
-			mask = IMX6Q_GPR12_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		}
-		break;
-	default:
-		mask = IMX6Q_GPR12_DEVICE_TYPE;
-		val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		break;
-	}
+	id = imx6_pcie->controller_id;
+
+	/* If mode_mask[id] is zero, means each controller have its individual gpr */
+	if (!drvdata->mode_mask[id])
+		id = 0;
+
+	mask = drvdata->mode_mask[id];
+	/* FIELD_PREP mask have been constant */
+	val = mode << (ffs(mask) - 1);
 
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, mask, val);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->mode_off[id], mask, val);
 }
 
 static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
@@ -1376,6 +1372,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1386,6 +1384,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_inbound_axi"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1397,6 +1397,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1405,6 +1407,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1412,6 +1416,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1420,6 +1428,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
@@ -1428,6 +1438,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
@@ -1436,6 +1448,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
@@ -1443,6 +1459,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
@@ -1450,6 +1468,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:34 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:34 -0500
Subject: [PATCH v6 08/16] PCI: imx6: Simplify switch-case logic by involve init_phy callback
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-9-Frank.Li@nxp.com>

Add drvdata::init_phy() callback function, so difference SOC choose
difference callback function to simple switch-case logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    change from v1 to v4:
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 135 ++++++++++++++------------
 1 file changed, 71 insertions(+), 64 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 717e8fa030deb..d66a2db53bdb7 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -69,6 +69,9 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_MAX_CLKS       6
 
 #define IMX6_PCIE_MAX_INSTANCES			2
+
+struct imx6_pcie;
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -80,6 +83,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
 struct imx6_pcie {
@@ -323,76 +327,69 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
 	return 0;
 }
 
-static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+static int imx8mq_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		/*
-		 * The PHY initialization had been done in the PHY
-		 * driver, break here directly.
-		 */
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		/*
-		 * TODO: Currently this code assumes external
-		 * oscillator is being used
-		 */
+	/*
+	 * TODO: Currently this code assumes external
+	 * oscillator is being used
+	 */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   imx6_pcie_grp_offset(imx6_pcie),
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD,
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD);
+	/*
+	 * Regarding the datasheet, the PCIE_VPH is suggested
+	 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
+	 * VREG_BYPASS should be cleared to zero.
+	 */
+	if (imx6_pcie->vph && regulator_get_voltage(imx6_pcie->vph) > 3000000)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr,
 				   imx6_pcie_grp_offset(imx6_pcie),
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD,
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD);
-		/*
-		 * Regarding the datasheet, the PCIE_VPH is suggested
-		 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
-		 * VREG_BYPASS should be cleared to zero.
-		 */
-		if (imx6_pcie->vph &&
-		    regulator_get_voltage(imx6_pcie->vph) > 3000000)
-			regmap_update_bits(imx6_pcie->iomuxc_gpr,
-					   imx6_pcie_grp_offset(imx6_pcie),
-					   IMX8MQ_GPR_PCIE_VREG_BYPASS,
-					   0);
-		break;
-	case IMX7D:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX8MQ_GPR_PCIE_VREG_BYPASS,
+				   0);
+
+	return 0;
+}
+
+static int imx7d_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	return	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
-		break;
-	case IMX6SX:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6SX_GPR12_PCIE_RX_EQ_MASK,
-				   IMX6SX_GPR12_PCIE_RX_EQ_2);
-		fallthrough;
-	default:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+}
+
+static int imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 
-		/* configure constant input signal to the pcie ctrl and phy */
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
-
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN1,
-				   imx6_pcie->tx_deemph_gen1 << 0);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
-				   imx6_pcie->tx_deemph_gen2_3p5db << 6);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
-				   imx6_pcie->tx_deemph_gen2_6db << 12);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_FULL,
-				   imx6_pcie->tx_swing_full << 18);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_LOW,
-				   imx6_pcie->tx_swing_low << 25);
-		break;
-	}
+	/* configure constant input signal to the pcie ctrl and phy */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN1,
+			   imx6_pcie->tx_deemph_gen1 << 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
+			   imx6_pcie->tx_deemph_gen2_3p5db << 6);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
+			   imx6_pcie->tx_deemph_gen2_6db << 12);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_FULL,
+			   imx6_pcie->tx_swing_full << 18);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_LOW,
+			   imx6_pcie->tx_swing_low << 25);
+	return 0;
+}
 
-	imx6_pcie_configure_type(imx6_pcie);
+static int imx6sx_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6SX_GPR12_PCIE_RX_EQ_MASK, IMX6SX_GPR12_PCIE_RX_EQ_2);
+
+	return imx6_pcie_init_phy(imx6_pcie);
 }
 
 static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
@@ -903,7 +900,11 @@ static int imx6_pcie_host_init(struct dw_pcie_rp *pp)
 	}
 
 	imx6_pcie_assert_core_reset(imx6_pcie);
-	imx6_pcie_init_phy(imx6_pcie);
+
+	if (imx6_pcie->drvdata->init_phy)
+		imx6_pcie->drvdata->init_phy(imx6_pcie);
+
+	imx6_pcie_configure_type(imx6_pcie);
 
 	ret = imx6_pcie_clk_enable(imx6_pcie);
 	if (ret) {
@@ -1374,6 +1375,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1386,6 +1388,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6sx_pcie_init_phy,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1399,6 +1402,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1409,6 +1413,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx7d_pcie_init_phy,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1420,6 +1425,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1452,6 +1458,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:35 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:35 -0500
Subject: [PATCH v6 09/16] dt-bindings: imx6q-pcie: Clean up irrationality clocks check
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-10-Frank.Li@nxp.com>

There are clocks and clock-names restriction for difference compatible
string. So needn't irrationality check again for clock's miniItems and
maxItems.

In fsl,imx6q-pcie-ep.yaml
    if:
        enum: fsl,imx8mq-pcie-ep
    then:
	...
        clocks:
	clock-names:
	...
    else:
	...
        clocks:
	clock-names:
	...

In fsl,imx6q-pcie.yaml. There are 7 compatible string. Each one already
have clock check logic.

    if:
	enum: <compatible string>
    then:
	...
	clocks:
	clock-names:
	...

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v5 to v6
    - rewrite git commit message and explain why remove it safely.
    - Add Rob's Ack
    Change from v1 to v4
    - new patch at v4

 .../bindings/pci/fsl,imx6q-pcie-common.yaml      | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index 8f39b4e6e8491..a284a27c5e873 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -150,22 +150,6 @@ allOf:
             - {}
             - const: pcie_phy
             - const: pcie_aux
-  - if:
-      properties:
-        compatible:
-          not:
-            contains:
-              enum:
-                - fsl,imx6sx-pcie
-                - fsl,imx8mq-pcie
-                - fsl,imx6sx-pcie-ep
-                - fsl,imx8mq-pcie-ep
-    then:
-      properties:
-        clocks:
-          maxItems: 3
-        clock-names:
-          maxItems: 3
 
   - if:
       properties:
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:36 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:36 -0500
Subject: [PATCH v6 10/16] dt-bindings: imx6q-pcie: restruct reg and reg-name
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-11-Frank.Li@nxp.com>

snps,dw-pcie.yaml already have reg and reg-name information. Needn't
duplciate here.

Add 'if' check for existed compatible string to restrict reg and reg-names.
This prepare to add new compatible string with difference reg-names sets.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v5 to v6
    - Add if check for existed compatible string
    Change from v4 to v5
    - add Rob's Acked
    Change from v1 to v4:
    - new patch at v4

 .../bindings/pci/fsl,imx6q-pcie.yaml          | 30 ++++++++++++-------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 81bbb8728f0f9..eeca6b7b540f9 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -30,16 +30,6 @@ properties:
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
 
-  reg:
-    items:
-      - description: Data Bus Interface (DBI) registers.
-      - description: PCIe configuration space region.
-
-  reg-names:
-    items:
-      - const: dbi
-      - const: config
-
   clocks:
     minItems: 3
     items:
@@ -90,6 +80,26 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx6q-pcie
+            - fsl,imx6sx-pcie
+            - fsl,imx6qp-pcie
+            - fsl,imx7d-pcie
+            - fsl,imx8mq-pcie
+            - fsl,imx8mm-pcie
+            - fsl,imx8mp-pcie
+    then:
+      properties:
+        reg:
+          maxItems: 2
+        reg-names:
+          items:
+            - const: dbi
+            - const: config
+
   - if:
       properties:
         compatible:
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:37 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:37 -0500
Subject: [PATCH v6 11/16] dt-bindings: imx6q-pcie: Add imx95 pcie compatible string
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-12-Frank.Li@nxp.com>

From: Richard Zhu <hongxing.zhu at nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
Add "atu" and "app" to reg-names.

Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
---

Notes:
    Change from v5 to v6
    - move atu and app after config
    
    Change from v2 to v3
    - Remove krzy's ACK tag
    - Add condition check for imx95, which required more reg-names then old
    platform, so need Krzy review again,
    
    Change from v1 to v2
    - add Krzy's ACK tag

 .../bindings/pci/fsl,imx6q-pcie-common.yaml   |  1 +
 .../bindings/pci/fsl,imx6q-pcie.yaml          | 19 +++++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index a284a27c5e873..1b63089ff0aee 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -207,6 +207,7 @@ allOf:
                 - fsl,imx6sx-pcie
                 - fsl,imx6q-pcie
                 - fsl,imx6qp-pcie
+                - fsl,imx95-pcie
                 - fsl,imx6sx-pcie-ep
                 - fsl,imx6q-pcie-ep
                 - fsl,imx6qp-pcie-ep
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index eeca6b7b540f9..8b8d77b1154b5 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -29,6 +29,7 @@ properties:
       - fsl,imx8mq-pcie
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
+      - fsl,imx95-pcie
 
   clocks:
     minItems: 3
@@ -100,6 +101,23 @@ allOf:
             - const: dbi
             - const: config
 
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie
+    then:
+      properties:
+        reg:
+          minItems: 4
+          maxItems: 4
+        reg-names:
+          items:
+            - const: dbi
+            - const: config
+            - const: atu
+            - const: app
+
   - if:
       properties:
         compatible:
@@ -121,6 +139,7 @@ allOf:
         compatible:
           enum:
             - fsl,imx8mq-pcie
+            - fsl,imx95-pcie
     then:
       properties:
         clocks:
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:38 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:38 -0500
Subject: [PATCH v6 12/16] PCI: imx6: Add iMX95 PCIe support
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-13-Frank.Li@nxp.com>

Add iMX95 PCIe basic root complex function support.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 90 +++++++++++++++++++++++++--
 1 file changed, 85 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index d66a2db53bdb7..9e60ab6f1885a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -42,6 +42,25 @@
 #define IMX8MQ_GPR_PCIE_VREG_BYPASS		BIT(12)
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
 
+#define IMX95_PCIE_PHY_GEN_CTRL			0x0
+#define IMX95_PCIE_REF_USE_PAD			BIT(17)
+
+#define IMX95_PCIE_PHY_MPLLA_CTRL		0x10
+#define IMX95_PCIE_PHY_MPLL_STATE		BIT(30)
+
+#define IMX95_PCIE_SS_RW_REG_0			0xf0
+#define IMX95_PCIE_REF_CLKEN			BIT(23)
+#define IMX95_PCIE_PHY_CR_PARA_SEL		BIT(9)
+
+#define IMX95_PE0_GEN_CTRL_1			0x1050
+#define IMX95_PCIE_DEVICE_TYPE			GENMASK(3, 0)
+
+#define IMX95_PE0_GEN_CTRL_3			0x1058
+#define IMX95_PCIE_LTSSM_EN			BIT(0)
+
+#define IMX95_PE0_PM_STS			0x1064
+#define IMX95_PCIE_PM_LINKST_IN_L2		BIT(14)
+
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -52,6 +71,7 @@ enum imx6_pcie_variants {
 	IMX8MQ,
 	IMX8MM,
 	IMX8MP,
+	IMX95,
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
@@ -63,6 +83,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
+#define IMX6_PCIE_FLAG_HAS_SERDES		BIT(6)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -179,6 +200,24 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
+static int imx95_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			IMX95_PCIE_SS_RW_REG_0,
+			IMX95_PCIE_PHY_CR_PARA_SEL,
+			IMX95_PCIE_PHY_CR_PARA_SEL);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_PHY_GEN_CTRL,
+			   IMX95_PCIE_REF_USE_PAD, 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_SS_RW_REG_0,
+			   IMX95_PCIE_REF_CLKEN,
+			   IMX95_PCIE_REF_CLKEN);
+
+	return 0;
+}
+
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
 	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
@@ -579,6 +618,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
 		break;
 	case IMX7D:
+	case IMX95:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -696,10 +736,19 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 {
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
+	u32 val;
 
 	reset_control_deassert(imx6_pcie->pciephy_reset);
 
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX95:
+		/* Polling the MPLL_STATE */
+		if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+					IMX95_PCIE_PHY_MPLLA_CTRL, val,
+					val & IMX95_PCIE_PHY_MPLL_STATE,
+					10, 10000))
+			dev_err(dev, "PCIe PLL lock timeout\n");
+		break;
 	case IMX7D:
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
@@ -1281,12 +1330,32 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(imx6_pcie->turnoff_reset);
 	}
 
+	if (imx6_pcie->drvdata->gpr) {
 	/* Grab GPR config register range */
-	imx6_pcie->iomuxc_gpr =
-		 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
-	if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
-		dev_err(dev, "unable to find iomuxc registers\n");
-		return PTR_ERR(imx6_pcie->iomuxc_gpr);
+		imx6_pcie->iomuxc_gpr =
+			 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
+	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_SERDES)) {
+		void __iomem *off = devm_platform_ioremap_resource_byname(pdev, "app");
+
+		if (IS_ERR(off))
+			return dev_err_probe(dev, PTR_ERR(off),
+					     "unable to find serdes registers\n");
+
+		static struct regmap_config regmap_config = {
+			.reg_bits = 32,
+			.val_bits = 32,
+			.reg_stride = 4,
+		};
+
+		imx6_pcie->iomuxc_gpr = devm_regmap_init_mmio(dev, off, &regmap_config);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
 	}
 
 	/* Grab PCIe PHY Tx Settings */
@@ -1447,6 +1516,16 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
+	[IMX95] = {
+		.variant = IMX95,
+		.flags = IMX6_PCIE_FLAG_HAS_SERDES,
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
@@ -1488,6 +1567,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
 	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{ .compatible = "fsl,imx8mp-pcie", .data = &drvdata[IMX8MP], },
+	{ .compatible = "fsl,imx95-pcie", .data = &drvdata[IMX95], },
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:39 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:39 -0500
Subject: [PATCH v6 13/16] PCI: imx6: Clean up get addr_space code
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-14-Frank.Li@nxp.com>

The common dw_pcie_ep_init() already do the same thing. Needn't platform
driver do it again.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches

 drivers/pci/controller/dwc/pci-imx6.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 9e60ab6f1885a..4b2b9aafad1b4 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1080,7 +1080,6 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 	int ret;
 	unsigned int pcie_dbi2_offset;
 	struct dw_pcie_ep *ep;
-	struct resource *res;
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct dw_pcie_rp *pp = &pci->pp;
 	struct device *dev = pci->dev;
@@ -1099,14 +1098,8 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 		pcie_dbi2_offset = SZ_4K;
 		break;
 	}
-	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
-	if (!res)
-		return -EINVAL;
 
-	ep->phys_base = res->start;
-	ep->addr_size = resource_size(res);
-	ep->page_size = SZ_64K;
+	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:40 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:40 -0500
Subject: [PATCH v6 14/16] PCI: imx6: Add epc_features in imx6_pcie_drvdata
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-15-Frank.Li@nxp.com>

The i.MX EP exhibits variations in epc_features among different EP
configurations. This introduces the addition of epc_features in
imx6_pcie_drvdata to accommodate these differences. It's important to note
that there are no functional changes in this commit; instead, it lays the
groundwork for supporting i.MX95 EP functions.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v5 to v6
    - add missed maxitems.
    - add comments about reuse linux,pci-domain as controller id.
    linux,pci-domain have not defined at PCI endpoint side.
    
    Change from v1 to v3
    - new patch at v3

 drivers/pci/controller/dwc/pci-imx6.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 4b2b9aafad1b4..6a58fd63a9dd2 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -104,6 +104,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	const struct pci_epc_features *epc_features;
 	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
@@ -1065,7 +1066,10 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
-	return &imx8m_pcie_epc_features;
+	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pci);
+
+	return imx6_pcie->drvdata->epc_features;
 }
 
 static const struct dw_pcie_ep_ops pcie_ep_ops = {
@@ -1530,6 +1534,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
@@ -1540,6 +1545,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
@@ -1549,6 +1555,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:41 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:41 -0500
Subject: [PATCH v6 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-16-Frank.Li@nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
Add reg-name: "atu", "dbi2", "dma" and "app".
Reuse PCI linux,pci-domain as controller id at endpoint.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches at v3

 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 57 ++++++++++++++++---
 1 file changed, 49 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
index ee155ed5f1811..f4d6ae5dab785 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
@@ -22,14 +22,7 @@ properties:
       - fsl,imx8mm-pcie-ep
       - fsl,imx8mq-pcie-ep
       - fsl,imx8mp-pcie-ep
-
-  reg:
-    minItems: 2
-
-  reg-names:
-    items:
-      - const: dbi
-      - const: addr_space
+      - fsl,imx95-pcie-ep
 
   clocks:
     minItems: 3
@@ -62,11 +55,48 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx8mm-pcie-ep
+            - fsl,imx8mq-pcie-ep
+            - fsl,imx8mp-pcie-ep
+    then:
+      properties:
+        reg:
+          minItems: 2
+          maxItems: 2
+        reg-names:
+          items:
+            - const: dbi
+            - const: addr_space
+
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie-ep
+    then:
+      properties:
+        reg:
+          minItems: 6
+          maxItems: 6
+        reg-names:
+          items:
+            - const: dbi
+            - const: atu
+            - const: dbi2
+            - const: app
+            - const: dma
+            - const: addr_space
+
   - if:
       properties:
         compatible:
           enum:
             - fsl,imx8mq-pcie-ep
+            - fsl,imx95-pcie-ep
     then:
       properties:
         clocks:
@@ -87,6 +117,17 @@ allOf:
             - const: pcie_bus
             - const: pcie_aux
 
+# reuse PCI linux,pci-domain as controller id at Endpoint
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie-ep
+    then:
+      properties:
+        linux,pci-domain: true
+      required:
+        - linux,pci-domain
 
 unevaluatedProperties: false
 
-- 
2.34.1



From Frank.Li at nxp.com  Sun Dec 24 10:32:42 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Sun, 24 Dec 2023 13:32:42 -0500
Subject: [PATCH v6 16/16] PCI: imx6: Add iMX95 Endpoint (EP) function support
In-Reply-To: <20231224183242.1675372-1-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
Message-ID: <20231224183242.1675372-17-Frank.Li@nxp.com>

Add iMX95 EP function support and add 64bit address support. Internal bus
bridge for PCI support 64bit dma address in iMX95. So set call
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)).

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v3 to v4
    - change align to 4k for imx95
    Change from v1 to v3
    - new patches at v3

 drivers/pci/controller/dwc/pci-imx6.c | 45 +++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 6a58fd63a9dd2..00ec59867c17b 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,7 @@ enum imx6_pcie_variants {
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
+	IMX95_EP,
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
@@ -84,6 +85,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
 #define IMX6_PCIE_FLAG_HAS_SERDES		BIT(6)
+#define IMX6_PCIE_FLAG_SUPPORT_64BIT		BIT(7)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -620,6 +622,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 		break;
 	case IMX7D:
 	case IMX95:
+	case IMX95_EP:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -1063,6 +1066,23 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 	.align = SZ_64K,
 };
 
+/*
+ * BAR#	| Default BAR enable	| Default BAR Type	| Default BAR Size	| BAR Sizing Scheme
+ * ================================================================================================
+ * BAR0	| Enable		| 64-bit		| 1 MB			| Programmable Size
+ * BAR1	| Disable		| 32-bit		| 64 KB			| Fixed Size
+ *	| (BAR0 is 64-bit)	| if BAR0 is 32-bit	|			| As Bar0 is 64bit
+ * BAR2	| Enable		| 32-bit		| 1 MB			| Programmable Size
+ * BAR3	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ * BAR4	| Enable		| 32-bit		| 1M			| Programmable Size
+ * BAR5	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ */
+static const struct pci_epc_features imx95_pcie_epc_features = {
+	.msi_capable = true,
+	.bar_fixed_size[1] = SZ_64K,
+	.align = SZ_4K,
+};
+
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
@@ -1105,6 +1125,14 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 
 	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
+	/*
+	 * db2 information should fetch from dtb file. dw_pcie_ep_init() can get dbi_base2 from
+	 * "dbi2" if pci->dbi_base2 is NULL. All code related pcie_dbi2_offset should be removed
+	 * after all dts added "dbi2" reg.
+	 */
+	if (imx6_pcie->drvdata->variant == IMX95_EP)
+		pci->dbi_base2 = NULL;
+
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
 		dev_err(dev, "failed to initialize endpoint\n");
@@ -1355,6 +1383,9 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "unable to find iomuxc registers\n");
 	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_SUPPORT_64BIT))
+		dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+
 	/* Grab PCIe PHY Tx Settings */
 	if (of_property_read_u32(node, "fsl,tx-deemph-gen1",
 				 &imx6_pcie->tx_deemph_gen1))
@@ -1557,6 +1588,19 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.epc_features = &imx8m_pcie_epc_features,
 	},
+	[IMX95_EP] = {
+		.variant = IMX95_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_SERDES |
+			 IMX6_PCIE_FLAG_SUPPORT_64BIT,
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+		.epc_features = &imx95_pcie_epc_features,
+		.mode = DW_PCIE_EP_TYPE,
+	},
 };
 
 static const struct of_device_id imx6_pcie_of_match[] = {
@@ -1571,6 +1615,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
+	{ .compatible = "fsl,imx95-pcie-ep", .data = &drvdata[IMX95_EP], },
 	{},
 };
 
-- 
2.34.1



From heiko at sntech.de  Sun Dec 24 10:59:36 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sun, 24 Dec 2023 19:59:36 +0100
Subject: [PATCH] arm64: rockchip: dts: rk3328-rock-pi-e: enable GbE eth
In-Reply-To: <20231221062244.11871-1-twoerner@gmail.com>
References: <20231221062244.11871-1-twoerner@gmail.com>
Message-ID: <2404910.8hb0ThOEGa@diego>

Hi Trevor,

Am Donnerstag, 21. Dezember 2023, 07:22:43 CET schrieb Trevor Woerner:
> Adjust the device-tree to get the GbE interface working using a patch found
> on the Radxa forum.
> 
> Link: https://forum.radxa.com/t/rock-pi-e-board-version-1-21-ethhernet-not-working-in-armbian/15061/3
> Signed-off-by: Trevor Woerner <twoerner at gmail.com>
> ---

> @@ -165,15 +165,17 @@ mdio {
>  		#address-cells = <1>;
>  		#size-cells = <0>;
>  
> -		rtl8211e: ethernet-phy at 1 {
> +		rtl8211f: ethernet-phy at 1 {
> +			compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22";

skipping through that thread, it looks like there are variants of the
board with one of the rtl8211e _or_ rtl8211f phys.

So while the "ethernet-phy-ieee802.3-c22" compatible would work for both,
the "ethernet-phy-id001c.c916" compat effectively disables phy- probing.
So applying this patch would effectively disable ethernet support on those
older rock-pi-e boards?

In a similar context concerning boards using different phys, it was
suggested [0] that the bootloader should modify the dt it passes to the
kernel to provide the correct phy id.


>  			reg = <1>;
>  			pinctrl-0 = <&eth_phy_int_pin>, <&eth_phy_reset_pin>;
>  			pinctrl-names = "default";
>  			interrupt-parent = <&gpio1>;
>  			interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
> -			reset-assert-us = <10000>;
> -			reset-deassert-us = <50000>;
> +			reset-assert-us = <20000>;
> +			reset-deassert-us = <100000>;

I guess for those we can consolidate onto the "slower" ones in the kernel though.


>  			reset-gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
> +			max-speed = <1000>;
>  		};
>  	};
>  };
> 


Heiko

[0] https://lore.kernel.org/all/ecbdcfb7-32ab-45cc-991a-982c52bf4b14 at gmail.com/





From heiko at sntech.de  Sun Dec 24 11:54:47 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sun, 24 Dec 2023 20:54:47 +0100
Subject: [PATCH] arm64: dts: rockchip: Support poweroff on NanoPC-T6
In-Reply-To: <20231216212134.23314-1-sigmaris@gmail.com>
References: <20231216212134.23314-1-sigmaris@gmail.com>
Message-ID: <170344745822.2405994.12076780121215785589.b4-ty@sntech.de>

On Sat, 16 Dec 2023 21:21:34 +0000, Hugh Cole-Baker wrote:
> The RK806 on the NanoPC-T6 can be used to power on/off the whole board.
> Mark it as the system power controller.
> 
> 

Applied, thanks!

[1/1] arm64: dts: rockchip: Support poweroff on NanoPC-T6
      commit: c699fbfdfd54630fc51b96da577f02e7b772eb37

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Sun Dec 24 11:54:46 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sun, 24 Dec 2023 20:54:46 +0100
Subject: [PATCH] arm64: dts: rockchip: configure pad driver strength for orangepi r1 plus lts
In-Reply-To: <20231216040723.17864-1-cnsztl@gmail.com>
References: <20231216040723.17864-1-cnsztl@gmail.com>
Message-ID: <170344745823.2405994.14854102458051573585.b4-ty@sntech.de>

On Sat, 16 Dec 2023 12:07:23 +0800, Tianling Shen wrote:
> The default strength is not enough to provide stable connection
> under 3.3v LDO voltage.
> 
> Fixes: 387b3bbac5ea ("arm64: dts: rockchip: Add Xunlong OrangePi R1 Plus LTS")
> 
> 

Applied, thanks!

[1/1] arm64: dts: rockchip: configure pad driver strength for orangepi r1 plus lts
      commit: fc5a80a432607d05e85bba37971712405f75c546

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Sun Dec 24 11:54:48 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sun, 24 Dec 2023 20:54:48 +0100
Subject: [PATCH] arm64: dts: rockchip: rk3308-rock-pi-s cleanup
In-Reply-To: <20231219173814.1569-1-twoerner@gmail.com>
References: <20231219173814.1569-1-twoerner@gmail.com>
Message-ID: <170344745822.2405994.1040172386629808336.b4-ty@sntech.de>

On Tue, 19 Dec 2023 12:38:13 -0500, Trevor Woerner wrote:
> Perform the following cleanups on a previous patch:
> - indent lines after "gpio-line-names"
> - fix D0-D8 -> D0-D7
> - sort phandle references
> 
> 

Applied, thanks!

[1/1] arm64: dts: rockchip: rk3308-rock-pi-s cleanup
      commit: 085021cc825ed90a6ddc4406f608fb8a85745f81

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Sun Dec 24 11:54:45 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sun, 24 Dec 2023 20:54:45 +0100
Subject: [PATCH] arm64: dts: rockchip: rk3588: Fix USB PD clocks
In-Reply-To: <20231216021019.1543811-1-CFSworks@gmail.com>
References: <20231216021019.1543811-1-CFSworks@gmail.com>
Message-ID: <170344745824.2405994.11750508038108170854.b4-ty@sntech.de>

On Fri, 15 Dec 2023 19:10:19 -0700, Sam Edwards wrote:
> The QoS blocks saved/restored when toggling the PD_USB power domain are
> clocked by ACLK_USB. Attempting to access these memory regions without
> that clock running will result in an indefinite CPU stall.
> 
> The PD_USB node wasn't specifying this clock dependency, resulting in
> hangs when trying to toggle the power domain (either on or off), unless
> we get "lucky" and have ACLK_USB running for another reason at the time.
> This "luck" can result from the bootloader leaving USB powered/clocked,
> and if no built-in driver wants USB, Linux will disable the unused
> PD+CLK on boot when {pd,clk}_ignore_unused aren't given. This can also
> be unlucky because the two cleanup tasks run in parallel and race: if
> the CLK is disabled first, the PD deactivation stalls the boot. In any
> case, the PD cannot then be reenabled (if e.g. the driver loads later)
> once the clock has been stopped.
> 
> [...]

Applied, thanks!

[1/1] arm64: dts: rockchip: rk3588: Fix USB PD clocks
      commit: 44de8996ed5a10f08f2fe947182da6535edcfae5

I've changed the patch to only add the ACLK_USB.
For the HCLK_* type, Rockchip added both the root as well as the
actual controller clocks, so I guess it should be the same
for the ACLK-type. Powerdomains are strange with their clock-
synchronization, so I'm opting for better save than sorry ;-)

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Sun Dec 24 11:54:44 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sun, 24 Dec 2023 20:54:44 +0100
Subject: (subset) [PATCH v2 0/3] Fix mainline support for rk3036 kylin board
In-Reply-To: <20231218105523.2478315-1-andyshrk@163.com>
References: <20231218105523.2478315-1-andyshrk@163.com>
Message-ID: <170344745821.2405994.10562040784600617888.b4-ty@sntech.de>

On Mon, 18 Dec 2023 18:55:20 +0800, Andy Yan wrote:
> From: Andy Yan <andy.yan at rock-chips.com>
> 
> 
> When I want to test some patch of inno hdmi driver on
> mainline, I found the support of rk3036 kylin board
> was broken by somehow:
> 
> [...]

Applied, thanks!

[2/3] ARM: dts: rockchip: Add stdout-path for rk3036 kylin
      commit: 1df4bc6908b2739f7ff28a1775729730d1addf16
[3/3] ARM: dts: rockchip: Remove rockchip,default-sample-phase from rk3036.dtsi
      commit: bb0b255fb6f14b1620566d7d32c43adaca09c5e5

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From lkp at intel.com  Sun Dec 24 13:23:48 2023
From: lkp at intel.com (kernel test robot)
Date: Mon, 25 Dec 2023 05:23:48 +0800
Subject: [soc:soc/arm 5/5] arch/arm/kernel/perf_event_v6.c:144:23: warning:
 unused variable 'armv6mpcore_perf_map'
Message-ID: <202312250521.K3pNHbty-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/arm
head:   2560cffd2134c2e070dee369b37f6e55438087f9
commit: 2560cffd2134c2e070dee369b37f6e55438087f9 [5/5] ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support
config: arm-randconfig-r111-20231224 (https://download.01.org/0day-ci/archive/20231225/202312250521.K3pNHbty-lkp at intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project.git f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce: (https://download.01.org/0day-ci/archive/20231225/202312250521.K3pNHbty-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312250521.K3pNHbty-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> arch/arm/kernel/perf_event_v6.c:144:23: warning: unused variable 'armv6mpcore_perf_map' [-Wunused-const-variable]
   static const unsigned armv6mpcore_perf_map[PERF_COUNT_HW_MAX] = {
                         ^
>> arch/arm/kernel/perf_event_v6.c:154:23: warning: unused variable 'armv6mpcore_perf_cache_map' [-Wunused-const-variable]
   static const unsigned armv6mpcore_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
                         ^
   arch/arm/kernel/perf_event_v6.c:455:13: warning: unused function 'armv6mpcore_pmu_disable_event' [-Wunused-function]
   static void armv6mpcore_pmu_disable_event(struct perf_event *event)
               ^
   3 warnings generated.


vim +/armv6mpcore_perf_map +144 arch/arm/kernel/perf_event_v6.c

43eab87828fee6 Will Deacon  2010-11-13  138  
43eab87828fee6 Will Deacon  2010-11-13  139  /*
43eab87828fee6 Will Deacon  2010-11-13  140   * The hardware events that we support. We do support cache operations but
43eab87828fee6 Will Deacon  2010-11-13  141   * we have harvard caches and no way to combine instruction and data
43eab87828fee6 Will Deacon  2010-11-13  142   * accesses/misses in hardware.
43eab87828fee6 Will Deacon  2010-11-13  143   */
43eab87828fee6 Will Deacon  2010-11-13 @144  static const unsigned armv6mpcore_perf_map[PERF_COUNT_HW_MAX] = {
cf20ae8cfcb3ab Mark Rutland 2014-05-30  145  	PERF_MAP_ALL_UNSUPPORTED,
43eab87828fee6 Will Deacon  2010-11-13  146  	[PERF_COUNT_HW_CPU_CYCLES]		= ARMV6MPCORE_PERFCTR_CPU_CYCLES,
43eab87828fee6 Will Deacon  2010-11-13  147  	[PERF_COUNT_HW_INSTRUCTIONS]		= ARMV6MPCORE_PERFCTR_INSTR_EXEC,
43eab87828fee6 Will Deacon  2010-11-13  148  	[PERF_COUNT_HW_BRANCH_INSTRUCTIONS]	= ARMV6MPCORE_PERFCTR_BR_EXEC,
43eab87828fee6 Will Deacon  2010-11-13  149  	[PERF_COUNT_HW_BRANCH_MISSES]		= ARMV6MPCORE_PERFCTR_BR_MISPREDICT,
0445e7a58e794d Will Deacon  2011-09-29  150  	[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND]	= ARMV6MPCORE_PERFCTR_IBUF_STALL,
0445e7a58e794d Will Deacon  2011-09-29  151  	[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]	= ARMV6MPCORE_PERFCTR_LSU_FULL_STALL,
43eab87828fee6 Will Deacon  2010-11-13  152  };
43eab87828fee6 Will Deacon  2010-11-13  153  
43eab87828fee6 Will Deacon  2010-11-13 @154  static const unsigned armv6mpcore_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
43eab87828fee6 Will Deacon  2010-11-13  155  					[PERF_COUNT_HW_CACHE_OP_MAX]
43eab87828fee6 Will Deacon  2010-11-13  156  					[PERF_COUNT_HW_CACHE_RESULT_MAX] = {
cf20ae8cfcb3ab Mark Rutland 2014-05-30  157  	PERF_CACHE_MAP_ALL_UNSUPPORTED,
cf20ae8cfcb3ab Mark Rutland 2014-05-30  158  
cf20ae8cfcb3ab Mark Rutland 2014-05-30  159  	[C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV6MPCORE_PERFCTR_DCACHE_RDACCESS,
cf20ae8cfcb3ab Mark Rutland 2014-05-30  160  	[C(L1D)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DCACHE_RDMISS,
cf20ae8cfcb3ab Mark Rutland 2014-05-30  161  	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV6MPCORE_PERFCTR_DCACHE_WRACCESS,
cf20ae8cfcb3ab Mark Rutland 2014-05-30  162  	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DCACHE_WRMISS,
cf20ae8cfcb3ab Mark Rutland 2014-05-30  163  
cf20ae8cfcb3ab Mark Rutland 2014-05-30  164  	[C(L1I)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_ICACHE_MISS,
cf20ae8cfcb3ab Mark Rutland 2014-05-30  165  
43eab87828fee6 Will Deacon  2010-11-13  166  	/*
cf20ae8cfcb3ab Mark Rutland 2014-05-30  167  	 * The ARM performance counters can count micro DTLB misses, micro ITLB
cf20ae8cfcb3ab Mark Rutland 2014-05-30  168  	 * misses and main TLB misses. There isn't an event for TLB misses, so
cf20ae8cfcb3ab Mark Rutland 2014-05-30  169  	 * use the micro misses here and if users want the main TLB misses they
cf20ae8cfcb3ab Mark Rutland 2014-05-30  170  	 * can use a raw counter.
43eab87828fee6 Will Deacon  2010-11-13  171  	 */
cf20ae8cfcb3ab Mark Rutland 2014-05-30  172  	[C(DTLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DTLB_MISS,
cf20ae8cfcb3ab Mark Rutland 2014-05-30  173  	[C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DTLB_MISS,
cf20ae8cfcb3ab Mark Rutland 2014-05-30  174  
cf20ae8cfcb3ab Mark Rutland 2014-05-30  175  	[C(ITLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_ITLB_MISS,
cf20ae8cfcb3ab Mark Rutland 2014-05-30  176  	[C(ITLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_ITLB_MISS,
43eab87828fee6 Will Deacon  2010-11-13  177  };
43eab87828fee6 Will Deacon  2010-11-13  178  

:::::: The code at line 144 was first introduced by commit
:::::: 43eab87828fee65f89f4088736b2b7a187390a2f ARM: perf: separate PMU backends into multiple files

:::::: TO: Will Deacon <will.deacon at arm.com>
:::::: CC: Will Deacon <will.deacon at arm.com>

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From linus.walleij at linaro.org  Sun Dec 24 14:24:38 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 24 Dec 2023 23:24:38 +0100
Subject: [PATCH] ARM: Delete ARM11MPCore perf leftovers
Message-ID: <20231224-drop-11mpcore-fix-v1-1-d8b16d1c1fae@linaro.org>

My commit deleting the PB11MPCore apparently left a few dangling
structs in the perf event code. Fix it up.

Fixes: 2560cffd2134 ("ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support")
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
This fixes a warning reported in the SoC tree, it's not even
in next yet. Now that I turned on ARMv6 in my builds it is
also tested.
---
 arch/arm/kernel/perf_event_v6.c | 94 -----------------------------------------
 1 file changed, 94 deletions(-)

diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index 3115077f6abc..0cbf46233d6b 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -113,69 +113,6 @@ static const unsigned armv6_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
 	[C(ITLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6_PERFCTR_ITLB_MISS,
 };
 
-enum armv6mpcore_perf_types {
-	ARMV6MPCORE_PERFCTR_ICACHE_MISS	    = 0x0,
-	ARMV6MPCORE_PERFCTR_IBUF_STALL	    = 0x1,
-	ARMV6MPCORE_PERFCTR_DDEP_STALL	    = 0x2,
-	ARMV6MPCORE_PERFCTR_ITLB_MISS	    = 0x3,
-	ARMV6MPCORE_PERFCTR_DTLB_MISS	    = 0x4,
-	ARMV6MPCORE_PERFCTR_BR_EXEC	    = 0x5,
-	ARMV6MPCORE_PERFCTR_BR_NOTPREDICT   = 0x6,
-	ARMV6MPCORE_PERFCTR_BR_MISPREDICT   = 0x7,
-	ARMV6MPCORE_PERFCTR_INSTR_EXEC	    = 0x8,
-	ARMV6MPCORE_PERFCTR_DCACHE_RDACCESS = 0xA,
-	ARMV6MPCORE_PERFCTR_DCACHE_RDMISS   = 0xB,
-	ARMV6MPCORE_PERFCTR_DCACHE_WRACCESS = 0xC,
-	ARMV6MPCORE_PERFCTR_DCACHE_WRMISS   = 0xD,
-	ARMV6MPCORE_PERFCTR_DCACHE_EVICTION = 0xE,
-	ARMV6MPCORE_PERFCTR_SW_PC_CHANGE    = 0xF,
-	ARMV6MPCORE_PERFCTR_MAIN_TLB_MISS   = 0x10,
-	ARMV6MPCORE_PERFCTR_EXPL_MEM_ACCESS = 0x11,
-	ARMV6MPCORE_PERFCTR_LSU_FULL_STALL  = 0x12,
-	ARMV6MPCORE_PERFCTR_WBUF_DRAINED    = 0x13,
-	ARMV6MPCORE_PERFCTR_CPU_CYCLES	    = 0xFF,
-};
-
-/*
- * The hardware events that we support. We do support cache operations but
- * we have harvard caches and no way to combine instruction and data
- * accesses/misses in hardware.
- */
-static const unsigned armv6mpcore_perf_map[PERF_COUNT_HW_MAX] = {
-	PERF_MAP_ALL_UNSUPPORTED,
-	[PERF_COUNT_HW_CPU_CYCLES]		= ARMV6MPCORE_PERFCTR_CPU_CYCLES,
-	[PERF_COUNT_HW_INSTRUCTIONS]		= ARMV6MPCORE_PERFCTR_INSTR_EXEC,
-	[PERF_COUNT_HW_BRANCH_INSTRUCTIONS]	= ARMV6MPCORE_PERFCTR_BR_EXEC,
-	[PERF_COUNT_HW_BRANCH_MISSES]		= ARMV6MPCORE_PERFCTR_BR_MISPREDICT,
-	[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND]	= ARMV6MPCORE_PERFCTR_IBUF_STALL,
-	[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]	= ARMV6MPCORE_PERFCTR_LSU_FULL_STALL,
-};
-
-static const unsigned armv6mpcore_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
-					[PERF_COUNT_HW_CACHE_OP_MAX]
-					[PERF_COUNT_HW_CACHE_RESULT_MAX] = {
-	PERF_CACHE_MAP_ALL_UNSUPPORTED,
-
-	[C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV6MPCORE_PERFCTR_DCACHE_RDACCESS,
-	[C(L1D)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DCACHE_RDMISS,
-	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV6MPCORE_PERFCTR_DCACHE_WRACCESS,
-	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DCACHE_WRMISS,
-
-	[C(L1I)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_ICACHE_MISS,
-
-	/*
-	 * The ARM performance counters can count micro DTLB misses, micro ITLB
-	 * misses and main TLB misses. There isn't an event for TLB misses, so
-	 * use the micro misses here and if users want the main TLB misses they
-	 * can use a raw counter.
-	 */
-	[C(DTLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DTLB_MISS,
-	[C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DTLB_MISS,
-
-	[C(ITLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_ITLB_MISS,
-	[C(ITLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_ITLB_MISS,
-};
-
 static inline unsigned long
 armv6_pmcr_read(void)
 {
@@ -452,37 +389,6 @@ static void armv6pmu_disable_event(struct perf_event *event)
 	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
 }
 
-static void armv6mpcore_pmu_disable_event(struct perf_event *event)
-{
-	unsigned long val, mask, flags, evt = 0;
-	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
-	struct hw_perf_event *hwc = &event->hw;
-	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
-	int idx = hwc->idx;
-
-	if (ARMV6_CYCLE_COUNTER == idx) {
-		mask	= ARMV6_PMCR_CCOUNT_IEN;
-	} else if (ARMV6_COUNTER0 == idx) {
-		mask	= ARMV6_PMCR_COUNT0_IEN;
-	} else if (ARMV6_COUNTER1 == idx) {
-		mask	= ARMV6_PMCR_COUNT1_IEN;
-	} else {
-		WARN_ONCE(1, "invalid counter number (%d)\n", idx);
-		return;
-	}
-
-	/*
-	 * Unlike UP ARMv6, we don't have a way of stopping the counters. We
-	 * simply disable the interrupt reporting.
-	 */
-	raw_spin_lock_irqsave(&events->pmu_lock, flags);
-	val = armv6_pmcr_read();
-	val &= ~mask;
-	val |= evt;
-	armv6_pmcr_write(val);
-	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
-}
-
 static int armv6_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv6_perf_map,

---
base-commit: b057e7afb79ec2edddc940b82af6e3571d1f0ffe
change-id: 20231224-drop-11mpcore-fix-c6cb526d1296

Best regards,
-- 
Linus Walleij <linus.walleij at linaro.org>



From heiko at sntech.de  Sun Dec 24 16:21:05 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 25 Dec 2023 01:21:05 +0100
Subject: [PATCH] drm/rockchip: vop2: clean up some inconsistent indenting
In-Reply-To: <20231219062635.100718-1-jiapeng.chong@linux.alibaba.com>
References: <20231219062635.100718-1-jiapeng.chong@linux.alibaba.com>
Message-ID: <170346364425.2455794.13619549678241145924.b4-ty@sntech.de>

On Tue, 19 Dec 2023 14:26:35 +0800, Jiapeng Chong wrote:
> No functional modification involved.
> 
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:1708 rk3588_calc_cru_cfg() warn: inconsistent indenting.
> 
> 

Applied, thanks!

[1/1] drm/rockchip: vop2: clean up some inconsistent indenting
      commit: f40e61eb538d35661d6dda1de92867954d776c4a

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Sun Dec 24 16:21:04 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 25 Dec 2023 01:21:04 +0100
Subject: [PATCH] drm/rockchip: vop2: Avoid use regmap_reinit_cache at runtime
In-Reply-To: <20231217084415.2373043-1-andyshrk@163.com>
References: <20231217084415.2373043-1-andyshrk@163.com>
Message-ID: <170346364423.2455794.3597954899361458023.b4-ty@sntech.de>

On Sun, 17 Dec 2023 16:44:15 +0800, Andy Yan wrote:
> From: Andy Yan <andy.yan at rock-chips.com>
> 
> Marek Report a possible irq lock inversion dependency warning when
> commit 81a06f1d02e5 ("Revert "drm/rockchip: vop2: Use regcache_sync()
> to fix suspend/resume"") lands linux-next.
> 
> I can reproduce this warning with:
> CONFIG_PROVE_LOCKING=y
> CONFIG_DEBUG_LOCKDEP=y
> 
> [...]

Applied, thanks!

[1/1] drm/rockchip: vop2: Avoid use regmap_reinit_cache at runtime
      commit: 3ee348eb36f14e9303a7e9757efb91b0bbf3f7a9

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From andyshrk at 163.com  Sun Dec 24 16:50:55 2023
From: andyshrk at 163.com (Andy Yan)
Date: Mon, 25 Dec 2023 08:50:55 +0800
Subject: [PATCH v2] arm64: dts: rockchip: Fix led pinctrl of lubancat 1
Message-ID: <20231225005055.3102743-1-andyshrk@163.com>

According to the sch, the gpio control sys_led
is GPIO0_C5.

Fixes: 8d94da58de53 ("arm64: dts: rockchip: Add EmbedFire LubanCat 1")
Reported-by: Zhang Ning <zhangn1985 at outlook.com>
Closes: https://lore.kernel.org/linux-rockchip/OS0P286MB06412D049D8BF7B063D41350CD95A at OS0P286MB0641.JPNP286.PROD.OUTLOOK.COM/T/#u
Signed-off-by: Andy Yan <andyshrk at 163.com>

---

Changes in v2:
- remove "boot" in subject prefix
- Add Zhang Ning full name in Reported-by

 arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts b/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts
index 1c6d83b47cd2..6ecdf5d28339 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts
@@ -455,7 +455,7 @@ &pcie2x1 {
 &pinctrl {
 	leds {
 		sys_led_pin: sys-status-led-pin {
-			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>;
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
 	};
 
-- 
2.34.1



From quic_taozha at quicinc.com  Sun Dec 24 17:55:49 2023
From: quic_taozha at quicinc.com (Tao Zhang)
Date: Mon, 25 Dec 2023 09:55:49 +0800
Subject: [PATCH v3 6/8] coresight-tpdm: Add timestamp control register
 support for the CMB
In-Reply-To: <cc7b83ec-2c97-4a5d-87a9-36f1e13d8fc4@arm.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-7-git-send-email-quic_taozha@quicinc.com>
 <ebd7e310-d1b4-4b2e-a915-6241e04763d4@arm.com>
 <b61c3d70-7277-4fe7-ab67-8afc1062c737@quicinc.com>
 <cdad425c-b965-44c7-a612-1c99341e95b9@arm.com>
 <b7ef4e75-69c6-4251-8f9c-58682699e3f6@quicinc.com>
 <cc7b83ec-2c97-4a5d-87a9-36f1e13d8fc4@arm.com>
Message-ID: <797eadf6-2708-47ad-a61f-88bb0d4fcf28@quicinc.com>


On 12/20/2023 7:07 PM, Suzuki K Poulose wrote:
> On 20/12/2023 09:51, Tao Zhang wrote:
>>
>> On 12/19/2023 9:51 PM, Suzuki K Poulose wrote:
>>> On 19/12/2023 02:43, Tao Zhang wrote:
>>>>
>>>> On 12/18/2023 6:46 PM, Suzuki K Poulose wrote:
>>>>> On 21/11/2023 02:24, Tao Zhang wrote:
>>>>>> CMB_TIER register is CMB subunit timestamp insertion enable 
>>>>>> register.
>>>>>> Bit 0 is PATT_TSENAB bit. Set this bit to 1 to request a timestamp
>>>>>> following a CMB interface pattern match. Bit 1 is XTRIG_TSENAB bit.
>>>>>> Set this bit to 1 to request a timestamp following a CMB CTI 
>>>>>> timestamp
>>>>>> request. Bit 2 is TS_ALL bit. Set this bit to 1 to request timestamp
>>>>>> for all packets.
>>>>>>
>>>>>> Reviewed-by: James Clark <james.clark at arm.com>
>>>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>>>> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
>>>>>> ---
>>>>>> ? .../testing/sysfs-bus-coresight-devices-tpdm? |? 35 ++++++
>>>>>> ? drivers/hwtracing/coresight/coresight-tpdm.c? | 116 
>>>>>> +++++++++++++++++-
>>>>>> ? drivers/hwtracing/coresight/coresight-tpdm.h? |? 14 +++
>>>>>> ? 3 files changed, 162 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git 
>>>>>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm 
>>>>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>>>> index 53662ce7c2d0..e0b77107be13 100644
>>>>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>>>> @@ -214,3 +214,38 @@ KernelVersion??? 6.7
>>>>>> ? Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>>> ? Description:
>>>>>> ????????? (RW) Set/Get the mask of the pattern for the CMB 
>>>>>> subunit TPDM.
>>>>>> +
>>>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
>>>>>> +Date:??????? September 2023
>>>>>> +KernelVersion??? 6.7
>>>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>>> +Description:
>>>>>> +??????? (Write) Set the pattern timestamp of CMB tpdm. Read
>>>>>> +??????? the pattern timestamp of CMB tpdm.
>>>>>> +
>>>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>>>> +??????? 0 : Disable CMB pattern timestamp.
>>>>>> +??????? 1 : Enable CMB pattern timestamp.
>>>>>> +
>>>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
>>>>>> +Date:??????? September 2023
>>>>>> +KernelVersion??? 6.7
>>>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>>> +Description:
>>>>>> +??????? (RW) Set/Get the trigger timestamp of the CMB for tpdm.
>>>>>> +
>>>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>>>> +??????? 0 : Set the CMB trigger type to false
>>>>>> +??????? 1 : Set the CMB trigger type to true
>>>>>> +
>>>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
>>>>>> +Date:??????? September 2023
>>>>>> +KernelVersion??? 6.7
>>>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>>> +Description:
>>>>>> +??????? (RW) Read or write the status of timestamp upon all 
>>>>>> interface.
>>>>>> +??????? Only value 0 and 1? can be written to this node. Set 
>>>>>> this node to 1 to requeset
>>>>>> +??????? timestamp to all trace packet.
>>>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>>>> +??????? 0 : Disable the timestamp of all trace packets.
>>>>>> +??????? 1 : Enable the timestamp of all trace packets.
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>>>>>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> index 894d4309f1c7..f6cda5616e84 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> @@ -331,6 +331,36 @@ static void tpdm_enable_dsb(struct 
>>>>>> tpdm_drvdata *drvdata)
>>>>>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>>>>>> ? }
>>>>>> ? +static void set_cmb_tier(struct tpdm_drvdata *drvdata)
>>>>>> +{
>>>>>> +??? u32 val;
>>>>>> +
>>>>>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_TIER);
>>>>>> +
>>>>>> +??? /* Clear all relevant fields */
>>>>>> +??? val &= ~(TPDM_CMB_TIER_PATT_TSENAB | TPDM_CMB_TIER_TS_ALL |
>>>>>> +???????? TPDM_CMB_TIER_XTRIG_TSENAB);
>>>>>> +
>>>>>> +??? /* Set pattern timestamp type and enablement */
>>>>>> +??? if (drvdata->cmb->patt_ts)
>>>>>> +??????? val |= TPDM_CMB_TIER_PATT_TSENAB;
>>>>>
>>>>> ?-- cut --
>>>>>> +??? else
>>>>>> +??????? val &= ~TPDM_CMB_TIER_PATT_TSENAB;
>>>>>
>>>>>
>>>>> All the else cases in this function are superfluous. Please remove 
>>>>> all
>>>>> of them.
>>>> I will update this in the next patch.
>>>>>
>>>>>> +
>>>>>> +??? /* Set trigger timestamp */
>>>>>> +??? if (drvdata->cmb->trig_ts)
>>>>>> +??????? val |= TPDM_CMB_TIER_XTRIG_TSENAB;
>>>>>> +??? else
>>>>>> +??????? val &= ~TPDM_CMB_TIER_XTRIG_TSENAB;
>>>>>> +
>>>>>> +??? /* Set all timestamp enablement*/
>>>>>> +??? if (drvdata->cmb->ts_all)
>>>>>> +??????? val |= TPDM_CMB_TIER_TS_ALL;
>>>>>> +??? else
>>>>>> +??????? val &= ~TPDM_CMB_TIER_TS_ALL;
>>>>>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>>>>>> +}
>>>>>> +
>>>>>> ? static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>>>>>> ? {
>>>>>> ????? u32 val, i;
>>>>>> @@ -347,6 +377,8 @@ static void tpdm_enable_cmb(struct 
>>>>>> tpdm_drvdata *drvdata)
>>>>>> ????????????????? drvdata->base + TPDM_CMB_XPMR(i));
>>>>>> ????? }
>>>>>> ? +??? set_cmb_tier(drvdata);
>>>>>> +
>>>>>> ????? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>>>>> ????? /*
>>>>>> ?????? * Set to 0 for continuous CMB collection mode,
>>>>>> @@ -695,9 +727,17 @@ static ssize_t enable_ts_show(struct device 
>>>>>> *dev,
>>>>>> ??????????????????? char *buf)
>>>>>> ? {
>>>>>> ????? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>> +??? ssize_t size = 0;
>>>>>> ? -??? return sysfs_emit(buf, "%u\n",
>>>>>> -???????????? (unsigned int)drvdata->dsb->patt_ts);
>>>>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>>>>> +??????? size = sysfs_emit(buf, "%u\n",
>>>>>> +???????????????? (unsigned int)drvdata->dsb->patt_ts);
>>>>>> +
>>>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>>>> +??????? size = sysfs_emit(buf, "%u\n",
>>>>>> +???????????????? (unsigned int)drvdata->cmb->patt_ts);
>>>>>
>>>>> Why does this need to show two values ? This must only show ONE 
>>>>> value.
>>>>> How you deduce that might be based on the availability of the feature
>>>>> set. Or store the TS value in the drvdata and use that instead for
>>>>> controlling CMB/DSB.
>>>>
>>>> Since both of CMB/DSB need to have "enable_ts" SysFs file, can I 
>>>> separate them
>>>
>>> The question really is, do we need fine grained control. i.e.,
>>>
>>> enable TS for DSB but not for CMB or vice versa.
>>>
>>> I am not an expert on the usage scenario of the same. So, if you/Qcomm
>>> thinks the users need separate, fine grained control for timestamp
>>> for the DSB and CMB, then yes, follow your recommendation below.
>>> i.e., tpdm.../dsb_patt/enable_ts
>>>
>>>> as "enable_dsb_ts" and "enable_cmb_ts"? The path will be like below.
>>>>
>>>> tpdm0/dsb_patt/enable_dsb_ts
>>>
>>> You don't need enable_dsb_ts. It could be "enable_ts"
>>>
>>>>
>>>> tpdm1/cmb_patt/enable_cmb_ts
>>>>
>>>> Is this design appropriate?
>>>
>>>
>>> Otherwise, stick to single enable_ts : which enables the ts for both
>>> CMB/DSB. And it only ever show one value : 0 (TS is disabled for both
>>> CMB/DSB) 1 : TS enabled for both.
>>
>> We have a very special case, such as the TPDM supporting both CMB and
>>
>> DSB datasets. Although this case is very rare, it still exists.
>>
>> Can I use the data bit to instruct whether timestamp is enabled for 
>> CMB/DSB or not? For example,
>>
>> size = sysfs_emit(buf, "%u\n",
>> ???? ??? ??? ??? (unsigned int)(drvdata->dsb->patt_ts << 1 | 
>> drvdata->cmb->patt_ts));
>>
>> Thus, this value can instruct the following situations.
>>
>> 0 - TS is disabled for both CMB/DSB
>>
>> 1 - TS is enabled for CMB
>>
>> 2 - TS is enabled for DSB
>>
>> 3 - TS is enabled for both
>>
>> Is this approach acceptable?
>>
>
> No, please stick to separate controls for TS. Do not complicate
> the user interface.
>
> i.e.,
> tpdm0/dsb_patt/enable_ts
> tpdm0/cmb_patt/enable_ts

We need to be able to control/show dsb and cmb timestamp enablement 
independently.

Can we achieve this requirement if we use a sysfs file with the same name?

I'm not able to find a good way to achieve it. Do you have any 
suggestions for this?


Best,

Tao

>
> Suzuki
>
>
>>
>> Best,
>>
>> Tao
>>
>>>
>>> Suzuki
>>>
>>>
>>>>>
>>>
>>>>> Also, the sysfs documentation needs update, if this is going to
>>>>> control the CMB.
>>>>
>>>> Sure. I will update the SysFs documentation according to the 
>>>> modification in the
>>>>
>>>> next patch series.
>>>>
>>>>
>>>> Best,
>>>>
>>>> Tao
>>>>
>>>>>
>>>>> Suzuki
>>>>>
>>>>>
>>>>>> +
>>>>>> +??? return size;
>>>>>> ? }
>>>>>> ? ? /*
>>>>>> @@ -715,8 +755,13 @@ static ssize_t enable_ts_store(struct device 
>>>>>> *dev,
>>>>>> ????????? return -EINVAL;
>>>>>> ? ????? spin_lock(&drvdata->spinlock);
>>>>>> -??? drvdata->dsb->patt_ts = !!val;
>>>>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>>>>> +??????? drvdata->dsb->patt_ts = !!val;
>>>>>> +
>>>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>>>> +??????? drvdata->cmb->patt_ts = !!val;
>>>>>> ????? spin_unlock(&drvdata->spinlock);
>>>>>> +
>>>>>> ????? return size;
>>>>>> ? }
>>>>>> ? static DEVICE_ATTR_RW(enable_ts);
>>>>>> @@ -851,6 +896,68 @@ static ssize_t cmb_mode_store(struct device 
>>>>>> *dev,
>>>>>> ? }
>>>>>> ? static DEVICE_ATTR_RW(cmb_mode);
>>>>>> ? +static ssize_t cmb_ts_all_show(struct device *dev,
>>>>>> +?????????????????? struct device_attribute *attr,
>>>>>> +?????????????????? char *buf)
>>>>>> +{
>>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>> +
>>>>>> +??? return sysfs_emit(buf, "%u\n",
>>>>>> +????????????? (unsigned int)drvdata->cmb->ts_all);
>>>>>> +}
>>>>>> +
>>>>>> +static ssize_t cmb_ts_all_store(struct device *dev,
>>>>>> +??????????????? struct device_attribute *attr,
>>>>>> +??????????????? const char *buf,
>>>>>> +??????????????? size_t size)
>>>>>> +{
>>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>> +??? unsigned long val;
>>>>>> +
>>>>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>>>>> +??????? return -EINVAL;
>>>>>> +
>>>>>> +??? spin_lock(&drvdata->spinlock);
>>>>>> +??? if (val)
>>>>>> +??????? drvdata->cmb->ts_all = true;
>>>>>> +??? else
>>>>>> +??????? drvdata->cmb->ts_all = false;
>>>>>> +??? spin_unlock(&drvdata->spinlock);
>>>>>> +??? return size;
>>>>>> +}
>>>>>> +static DEVICE_ATTR_RW(cmb_ts_all);
>>>>>> +
>>>>>> +static ssize_t cmb_trig_ts_show(struct device *dev,
>>>>>> +??????????????? struct device_attribute *attr,
>>>>>> +??????????????? char *buf)
>>>>>> +{
>>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>> +
>>>>>> +??? return sysfs_emit(buf, "%u\n",
>>>>>> +????????????? (unsigned int)drvdata->cmb->trig_ts);
>>>>>> +}
>>>>>> +
>>>>>> +static ssize_t cmb_trig_ts_store(struct device *dev,
>>>>>> +???????????????? struct device_attribute *attr,
>>>>>> +???????????????? const char *buf,
>>>>>> +???????????????? size_t size)
>>>>>> +{
>>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>> +??? unsigned long val;
>>>>>> +
>>>>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>>>>> +??????? return -EINVAL;
>>>>>> +
>>>>>> +??? spin_lock(&drvdata->spinlock);
>>>>>> +??? if (val)
>>>>>> +??????? drvdata->cmb->trig_ts = true;
>>>>>> +??? else
>>>>>> +??????? drvdata->cmb->trig_ts = false;
>>>>>> +??? spin_unlock(&drvdata->spinlock);
>>>>>> +??? return size;
>>>>>> +}
>>>>>> +static DEVICE_ATTR_RW(cmb_trig_ts);
>>>>>> +
>>>>>> ? static struct attribute *tpdm_dsb_edge_attrs[] = {
>>>>>> ????? &dev_attr_ctrl_idx.attr,
>>>>>> ????? &dev_attr_ctrl_val.attr,
>>>>>> @@ -973,6 +1080,7 @@ static struct attribute 
>>>>>> *tpdm_cmb_patt_attrs[] = {
>>>>>> ????? CMB_PATT_ATTR(1),
>>>>>> ????? CMB_PATT_MASK_ATTR(0),
>>>>>> ????? CMB_PATT_MASK_ATTR(1),
>>>>>> +??? &dev_attr_enable_ts.attr,
>>>>>> ????? NULL,
>>>>>> ? };
>>>>>> ? @@ -985,6 +1093,8 @@ static struct attribute *tpdm_dsb_attrs[] = {
>>>>>> ? ? static struct attribute *tpdm_cmb_attrs[] = {
>>>>>> ????? &dev_attr_cmb_mode.attr,
>>>>>> +??? &dev_attr_cmb_ts_all.attr,
>>>>>> +??? &dev_attr_cmb_trig_ts.attr,
>>>>>> ????? NULL,
>>>>>> ? };
>>>>>> ? diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>>>>>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> index e90d008c1cb2..65b7ca6c4077 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> @@ -11,6 +11,8 @@
>>>>>> ? ? /* CMB Subunit Registers */
>>>>>> ? #define TPDM_CMB_CR??????? (0xA00)
>>>>>> +/*CMB subunit timestamp insertion enable register*/
>>>>>> +#define TPDM_CMB_TIER??????? (0xA04)
>>>>>> ? /*CMB subunit timestamp pattern registers*/
>>>>>> ? #define TPDM_CMB_TPR(n)??????? (0xA08 + (n * 4))
>>>>>> ? /*CMB subunit timestamp pattern mask registers*/
>>>>>> @@ -24,6 +26,12 @@
>>>>>> ? #define TPDM_CMB_CR_ENA??????? BIT(0)
>>>>>> ? /* Trace collection mode for CMB subunit */
>>>>>> ? #define TPDM_CMB_CR_MODE??? BIT(1)
>>>>>> +/* Timestamp control for pattern match */
>>>>>> +#define TPDM_CMB_TIER_PATT_TSENAB??? BIT(0)
>>>>>> +/* CMB CTI timestamp request */
>>>>>> +#define TPDM_CMB_TIER_XTRIG_TSENAB??? BIT(1)
>>>>>> +/* For timestamp fo all trace */
>>>>>> +#define TPDM_CMB_TIER_TS_ALL??????? BIT(2)
>>>>>> ? ? /*Patten register number*/
>>>>>> ? #define TPDM_CMB_MAX_PATT??????? 2
>>>>>> @@ -217,6 +225,9 @@ struct dsb_dataset {
>>>>>> ?? * @patt_mask:??????? Save value for pattern mask
>>>>>> ?? * @trig_patt:??????? Save value for trigger pattern
>>>>>> ?? * @trig_patt_mask:?? Save value for trigger pattern mask
>>>>>> + * @patt_ts:????????? Indicates if pattern match for timestamp 
>>>>>> is enabled.
>>>>>> + * @trig_ts:????????? Indicates if CTI trigger for timestamp is 
>>>>>> enabled.
>>>>>> + * @ts_all:?????????? Indicates if timestamp is enabled for all 
>>>>>> packets.
>>>>>> ?? */
>>>>>> ? struct cmb_dataset {
>>>>>> ????? u32??????????? trace_mode;
>>>>>> @@ -224,6 +235,9 @@ struct cmb_dataset {
>>>>>> ????? u32??????????? patt_mask[TPDM_CMB_MAX_PATT];
>>>>>> ????? u32??????????? trig_patt[TPDM_CMB_MAX_PATT];
>>>>>> ????? u32??????????? trig_patt_mask[TPDM_CMB_MAX_PATT];
>>>>>> +??? bool??????????? patt_ts;
>>>>>> +??? bool??????????? trig_ts;
>>>>>> +??? bool??????????? ts_all;
>>>>>> ? };
>>>>>> ? ? /**
>>>>>
>>>
>>> _______________________________________________
>>> CoreSight mailing list -- coresight at lists.linaro.org
>>> To unsubscribe send an email to coresight-leave at lists.linaro.org
>
> _______________________________________________
> CoreSight mailing list -- coresight at lists.linaro.org
> To unsubscribe send an email to coresight-leave at lists.linaro.org


From xu.yang_2 at nxp.com  Sun Dec 24 18:20:07 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Mon, 25 Dec 2023 02:20:07 +0000
Subject: [EXT] Re: [PATCH v2 1/3] usb: chipidea: ci_hdrc_imx: add wakeup
 clock and keep it always on
In-Reply-To: <568fce67-a9e2-4aa8-a165-f12efcf494b8@gmx.net>
References: <20231218061420.3460145-1-xu.yang_2@nxp.com>
 <568fce67-a9e2-4aa8-a165-f12efcf494b8@gmx.net>
Message-ID: <DB7PR04MB5146D07949E18C623F76A3438C99A@DB7PR04MB5146.eurprd04.prod.outlook.com>

Hi Stefan,

> 
> Hi Xu,
> 
> Am 18.12.23 um 07:14 schrieb Xu Yang:
> > Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
> > on without usb driver intervention. And some may need driver to handle
> > this clock. For now only i.MX93 needs this wakeup clock. This patch will
> > get wakeup clock and keep it always on to make controller work properly.
> >
> > Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> >
> > ---
> > Changes in v2:
> >   - modify commit msg to make it clear
> > ---
> >   drivers/usb/chipidea/ci_hdrc_imx.c | 22 +++++++++++++++++++++-
> >   1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> > index e28bb2f2612d..4330be8240ff 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > @@ -96,6 +96,7 @@ struct ci_hdrc_imx_data {
> >       struct usb_phy *phy;
> >       struct platform_device *ci_pdev;
> >       struct clk *clk;
> > +     struct clk *clk_wakeup;
> >       struct imx_usbmisc_data *usbmisc_data;
> >       bool supports_runtime_pm;
> >       bool override_phy_control;
> > @@ -199,7 +200,7 @@ static int imx_get_clks(struct device *dev)
> >
> >       data->clk_ipg = devm_clk_get(dev, "ipg");
> >       if (IS_ERR(data->clk_ipg)) {
> > -             /* If the platform only needs one clocks */
> > +             /* If the platform only needs one primary clock */
> >               data->clk = devm_clk_get(dev, NULL);
> >               if (IS_ERR(data->clk)) {
> >                       ret = PTR_ERR(data->clk);
> > @@ -208,6 +209,18 @@ static int imx_get_clks(struct device *dev)
> >                               PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
> >                       return ret;
> >               }
> > +             /* Get wakeup clock. Not all of the platforms need to
> > +              * handle this clock. So make it optional.
> > +              */
> > +             data->clk_wakeup = devm_clk_get_optional(dev,
> > +                                                      "usb_wakeup_clk");
> > +             if (IS_ERR(data->clk_wakeup)) {
> > +                     ret = PTR_ERR(data->clk_wakeup);
> > +                     dev_err(dev,
> > +                             "Failed to get wakeup clk, err=%ld\n",
> > +                             PTR_ERR(data->clk_wakeup));
> > +                     return ret;
> this could be simplified to:
> 
> return dev_err_probe(dev, PTR_ERR(data->clk_wakeup), "Failed to get
> wakeup clk\n");
> 
> AFAIK the error code is also printed out. Another benefit is that this
> handles deferred probe of the clock and avoid spamming.

Okay, I will try this.

Thanks,
Xu Yang

> > +             }
> >               return ret;
> >       }
> >
> > @@ -423,6 +436,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> >       if (ret)
> >               goto disable_hsic_regulator;
> >
> > +     ret = clk_prepare_enable(data->clk_wakeup);
> > +     if (ret)
> > +             goto err_wakeup_clk;
> > +
> >       data->phy = devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0);
> >       if (IS_ERR(data->phy)) {
> >               ret = PTR_ERR(data->phy);
> > @@ -504,6 +521,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> >   disable_device:
> >       ci_hdrc_remove_device(data->ci_pdev);
> >   err_clk:
> > +     clk_disable_unprepare(data->clk_wakeup);
> > +err_wakeup_clk:
> >       imx_disable_unprepare_clks(dev);
> >   disable_hsic_regulator:
> >       if (data->hsic_pad_regulator)
> > @@ -530,6 +549,7 @@ static void ci_hdrc_imx_remove(struct platform_device *pdev)
> >               usb_phy_shutdown(data->phy);
> >       if (data->ci_pdev) {
> >               imx_disable_unprepare_clks(&pdev->dev);
> > +             clk_disable_unprepare(data->clk_wakeup);
> >               if (data->plat_data->flags & CI_HDRC_PMQOS)
> >                       cpu_latency_qos_remove_request(&data->pm_qos_req);
> >               if (data->hsic_pad_regulator)


From Yu-chang.Lee at mediatek.com  Sun Dec 24 18:55:34 2023
From: Yu-chang.Lee at mediatek.com (=?utf-8?B?WXUtY2hhbmcgTGVlICjmnY7nprnnkosp?=)
Date: Mon, 25 Dec 2023 02:55:34 +0000
Subject: Discuss Mediatek Power Domain Driver Support Mulitle Smi Clamp
 Protection
In-Reply-To: <e80dbd42-b9c8-4564-be4e-6ee449d24c70@collabora.com>
References: <a3aaf3180fdb3da117132089bd160ba4d5cebc17.camel@mediatek.com>
	 <b4fa9b7f-512f-4a34-884a-a99a3b035d34@collabora.com>
	 <f8150ce2859bc8d22d2fa7cbc671bf2d43d4a86d.camel@mediatek.com>
	 <e80dbd42-b9c8-4564-be4e-6ee449d24c70@collabora.com>
Message-ID: <6fe4d15afc6220c0f131d33925b82dd24bedcd06.camel@mediatek.com>

On Thu, 2023-12-21 at 13:31 +0100, AngeloGioacchino Del Regno wrote:
> > 
> > We can clamp IMG1 before clamping IMG0, I am more concerned with
> > the
> > order between infra and smi rather than the order between smi. And
> > I
> > think current structure mixed smi and infra may also introduce
> > misunderstanding in the future. Maybe separate the bp_cfg and match
> > the
> > smi name with smi's bus protection step could be a direction to fix
> > the
> > problem?
> > 
> 
> That could work, yes. You could alternatively build an array, or a 32
> bit value for
> which each bit corresponds to the position of a BUS_PROT_WR entry in
> .bp_cfg, and
> then use that to locate SMI vs INFRA bus protection entries.
> 
> Taking as an example a "messy" bp_cfg:
> 
> .bp_cfg = {
> 	BUS_PROT_WR(INFRA, other_params),
> 	BUS_PROT_WR(SMI, other_params),
> 	BUS_PROT_WR(INFRA, ...),
> 	BUS_PROT_WR(INFRA, ...),
> 	BUS_PROT_WR(SMI, ...),
> }
> 
> probe_function() {
> 	...
> 
> 	for (....) {
> 		if (.bp_cfg[i] == SMI)
> 			pd->smi_bp_map |= BIT(i);
> 	}
> 
> 	....
> }
> 
> powerup_function() {
> 	...
> 	u16 smi_bp_map = pd->smi_bp_map;
> 
> 	for_each_set_bit(i, &smi_pd_map, 16)
> 		bus_protect_smi_write(somewhere->bp_cfg[i]);
> 
> 	...
> 
> 	bus_protect_infra_write()
> 
> 	...
> }
> 
> 
> Or, simply, we can *enforce* ordering in bp_cfg, so that all of the
> SMI entries
> are before INFRA, like:
> 
> .bp_cfg = {
> 	/* Ordering is important here: SMI bus prot always before INFRA
> */
> 	BUS_PROT_WR(SMI, other_params),
> 	BUS_PROT_WR(SMI, ...),
> 	BUS_PROT_WR(INFRA, other_params),
> 	BUS_PROT_WR(INFRA, ...),
> 	BUS_PROT_WR(INFRA, ...),
> }
> 
> ...so that we never build any positional information / bitmaps.
> 
> Since the SMI vs INFRA order is really important, we could add a
> "failsafe" check
> in the probe function, like:
> 
> probe() {
> 	bool smi_prot_found;
> 
> 	for (....) {
> 		if ((...->bp_cfg[i].flags & BUS_PROT_COMPONENT_INFRA)
> &&
> 		    smi_prot_found) {
> 			dev_err(... , "SMI bus prot cannot be mixed
> with INFRA");
> 			return -EINVAL;
> 		} else if (....->bp_cfg[i] & BUS_PROT_COMPONENT_SMI)
> 			smi_prot_found = true;
> 	}
> }
> 
> Obviously the error message etc should be reworded, all the above is
> just
> examples to solve the issue without having any meaningful overhead in
> the
> performance paths [scpsys_power_on() and scpsys_power_off()].
> 
> Does that help you?
> 
> Cheers,
> Angelo

Hi Angelo:

Thanks for your generous feedback and advice, I will think about it.
See you upstream then.

Best Regards,
Yu-Chang.Lee



From peng.fan at nxp.com  Sun Dec 24 19:17:27 2023
From: peng.fan at nxp.com (Peng Fan)
Date: Mon, 25 Dec 2023 03:17:27 +0000
Subject: [PATCH 1/2] clk: imx: composite-8m: Less function calls in
 __imx8m_clk_hw_composite() after error detection
In-Reply-To: <147ca1e6-69f3-4586-b5b3-b69f9574a862@web.de>
References: <1d494176-2238-4430-bc26-4e4c78fe4ede@web.de>
 <147ca1e6-69f3-4586-b5b3-b69f9574a862@web.de>
Message-ID: <DU0PR04MB941778B838752475D39E562F8899A@DU0PR04MB9417.eurprd04.prod.outlook.com>

> Subject: [PATCH 1/2] clk: imx: composite-8m: Less function calls in
> __imx8m_clk_hw_composite() after error detection
> 
> From: Markus Elfring <elfring at users.sourceforge.net>
> Date: Fri, 22 Dec 2023 16:48:24 +0100
> 
> The function ?kfree? was called in up to three cases by the function
> ?__imx8m_clk_hw_composite? during error handling even if the passed
> variables contained a null pointer.
> 
> Adjust jump targets according to the Linux coding style convention.
> 
> Signed-off-by: Markus Elfring <elfring at users.sourceforge.net>

Reviewed-by: Peng Fan <peng.fan at nxp.com>

From peng.fan at nxp.com  Sun Dec 24 19:18:56 2023
From: peng.fan at nxp.com (Peng Fan)
Date: Mon, 25 Dec 2023 03:18:56 +0000
Subject: [PATCH 2/2] clk: imx: composite-8m: Delete two unnecessary
 initialisations in __imx8m_clk_hw_composite()
In-Reply-To: <6604590e-d0f7-4798-a1b9-b2f474f3a642@web.de>
References: <1d494176-2238-4430-bc26-4e4c78fe4ede@web.de>
 <6604590e-d0f7-4798-a1b9-b2f474f3a642@web.de>
Message-ID: <DU0PR04MB9417C785D62961AEB47CFDD38899A@DU0PR04MB9417.eurprd04.prod.outlook.com>

> Subject: [PATCH 2/2] clk: imx: composite-8m: Delete two unnecessary
> initialisations in __imx8m_clk_hw_composite()
> 
> From: Markus Elfring <elfring at users.sourceforge.net>
> Date: Fri, 22 Dec 2023 17:11:03 +0100
> 
> Two local variables will eventually be set to appropriate pointers a bit later.
> Thus omit the explicit initialisation at the beginning.
> 
> Signed-off-by: Markus Elfring <elfring at users.sourceforge.net>

Reviewed-by: Peng Fan <peng.fan at nxp.com>

From yilun.xu at linux.intel.com  Sun Dec 24 22:01:40 2023
From: yilun.xu at linux.intel.com (Xu Yilun)
Date: Mon, 25 Dec 2023 14:01:40 +0800
Subject: [PATCH 00/13] fpga: Convert to platform remove callback
 returning void
In-Reply-To: <cover.1703006638.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703006638.git.u.kleine-koenig@pengutronix.de>
Message-ID: <ZYkaxIFf4rxiiDOR@yilunxu-OptiPlex-7050>

On Tue, Dec 19, 2023 at 06:31:58PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> this series converts all drivers below drivers/fpga to use
> .remove_new(). See commit 5c5a7680e67b ("platform: Provide a remove
> callback that returns no value") for an extended explanation and the
> eventual goal. The TL;DR; is to make it harder for driver authors to
> leak resources without noticing.
> 
> This is merge window material. All patches are pairwise independent of
> each other, so they could be applied individually. Getting them all in
> together would be nicer though :-)
> 
> Best regards
> Uwe
> 
> Uwe Kleine-K?nig (13):
>   fpga: altera-fpga2sdram: Convert to platform remove callback returning void
>   fpga: altera-freeze-bridge: Convert to platform remove callback returning void
>   fpga: altera-hps2fpga: Convert to platform remove callback returning void
>   fpga: dfl-afu-main: Convert to platform remove callback returning void
>   fpga: dfl-fme-br: Convert to platform remove callback returning void
>   fpga: dfl-fme-main: Convert to platform remove callback returning void
>   fpga: dfl-fme-region: Convert to platform remove callback returning void
>   fpga: intel-m10-bmc-sec-update: Convert to platform remove callback returning void
>   fpga: of-fpga-region: Convert to platform remove callback returning void
>   fpga: socfpga-a10: Convert to platform remove callback returning void
>   fpga: stratix10-soc: Convert to platform remove callback returning void
>   fpga: xilinx-pr-decoupler: Convert to platform remove callback returning void
>   fpga: zynq-fpga: Convert to platform remove callback returning void
> 
>  drivers/fpga/altera-fpga2sdram.c        | 6 ++----
>  drivers/fpga/altera-freeze-bridge.c     | 6 ++----
>  drivers/fpga/altera-hps2fpga.c          | 6 ++----
>  drivers/fpga/dfl-afu-main.c             | 6 ++----
>  drivers/fpga/dfl-fme-br.c               | 6 ++----
>  drivers/fpga/dfl-fme-main.c             | 6 ++----
>  drivers/fpga/dfl-fme-region.c           | 6 ++----
>  drivers/fpga/intel-m10-bmc-sec-update.c | 6 ++----
>  drivers/fpga/of-fpga-region.c           | 6 ++----
>  drivers/fpga/socfpga-a10.c              | 6 ++----
>  drivers/fpga/stratix10-soc.c            | 6 ++----
>  drivers/fpga/xilinx-pr-decoupler.c      | 6 ++----
>  drivers/fpga/zynq-fpga.c                | 6 ++----
>  13 files changed, 26 insertions(+), 52 deletions(-)

Acked-by: Xu Yilun <yilun.xu at intel.com>

And applied this series to for-next for 6.8-rc1.

> 
> base-commit: aa4db8324c4d0e67aa4670356df4e9fae14b4d37
> -- 
> 2.42.0
> 
> 


From muchun.song at linux.dev  Sun Dec 24 22:29:53 2023
From: muchun.song at linux.dev (Muchun Song)
Date: Mon, 25 Dec 2023 14:29:53 +0800
Subject: [PATCH 03/13] mm: Provide generic pmd_thp_or_huge()
In-Reply-To: <20231219075538.414708-4-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
 <20231219075538.414708-4-peterx@redhat.com>
Message-ID: <135b3189-f459-4b57-9861-bb8acb999d91@linux.dev>



On 2023/12/19 15:55, peterx at redhat.com wrote:
> From: Peter Xu <peterx at redhat.com>
>
> ARM defines pmd_thp_or_huge(), detecting either a THP or a huge PMD.  It
> can be a helpful helper if we want to merge more THP and hugetlb code
> paths.  Make it a generic default implementation, only exist when
> CONFIG_MMU.  Arch can overwrite it by defining its own version.
>
> For example, ARM's pgtable-2level.h defines it to always return false.
>
> Keep the macro declared with all config, it should be optimized to a false
> anyway if !THP && !HUGETLB.
>
> Signed-off-by: Peter Xu <peterx at redhat.com>
> ---
>   include/linux/pgtable.h | 4 ++++
>   mm/gup.c                | 3 +--
>   2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index af7639c3b0a3..6f2fa1977b8a 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1355,6 +1355,10 @@ static inline int pmd_write(pmd_t pmd)
>   #endif /* pmd_write */
>   #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>   
> +#ifndef pmd_thp_or_huge

I think it may be the time to rename to pmd_thp_or_hugetlb,
the "huge" is really confusing. thp is not huge? Actually,
it is huge. It is better to make it more specific from now on, like
"hugetlb".

BTW, please cc me via the new email (muchun.song at linux.dev) next edition.

Thanks.

> +#define pmd_thp_or_huge(pmd)	(pmd_huge(pmd) || pmd_trans_huge(pmd))
> +#endif
> +
>   #ifndef pud_write
>   static inline int pud_write(pud_t pud)
>   {
> diff --git a/mm/gup.c b/mm/gup.c
> index 0a5f0e91bfec..efc9847e58fb 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -3004,8 +3004,7 @@ static int gup_pmd_range(pud_t *pudp, pud_t pud, unsigned long addr, unsigned lo
>   		if (!pmd_present(pmd))
>   			return 0;
>   
> -		if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
> -			     pmd_devmap(pmd))) {
> +		if (unlikely(pmd_thp_or_huge(pmd) || pmd_devmap(pmd))) {
>   			/* See gup_pte_range() */
>   			if (pmd_protnone(pmd))
>   				return 0;



From muchun.song at linux.dev  Sun Dec 24 22:34:48 2023
From: muchun.song at linux.dev (Muchun Song)
Date: Mon, 25 Dec 2023 14:34:48 +0800
Subject: [PATCH 05/13] mm: Introduce vma_pgtable_walk_{begin|end}()
In-Reply-To: <20231219075538.414708-6-peterx@redhat.com>
References: <20231219075538.414708-1-peterx@redhat.com>
 <20231219075538.414708-6-peterx@redhat.com>
Message-ID: <0D9E28F4-AFA8-479C-8311-093DAFD9DF41@linux.dev>



> On Dec 19, 2023, at 15:55, peterx at redhat.com wrote:
> 
> From: Peter Xu <peterx at redhat.com>
> 
> Introduce per-vma begin()/end() helpers for pgtable walks.  This is a
> preparation work to merge hugetlb pgtable walkers with generic mm.
> 
> The helpers need to be called before and after a pgtable walk, will start
> to be needed if the pgtable walker code supports hugetlb pages.  It's a
> hook point for any type of VMA, but for now only hugetlb uses it to
> stablize the pgtable pages from getting away (due to possible pmd
> unsharing).
> 
> Reviewed-by: Christoph Hellwig <hch at infradead.org>
> Signed-off-by: Peter Xu <peterx at redhat.com>

Reviewed-by: Muchun Song <songmuchun at bytedance.com>

Thanks.



From ck.hu at mediatek.com  Mon Dec 25 01:05:33 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Mon, 25 Dec 2023 09:05:33 +0000
Subject: [PATCH v3 01/11] drm/mediatek: Add interface to allocate MediaTek
 GEM buffer.
In-Reply-To: <20231223182932.27683-2-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-2-jason-jh.lin@mediatek.com>
Message-ID: <4169f943f6e82da50243d91614ab73d6b5f57c8a.camel@mediatek.com>

Hi, Jason:


On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> From: CK Hu <ck.hu at mediatek.com>
> 
> Add an interface to allocate MediaTek GEM buffers, allow the IOCTLs
> to be used by render nodes.
> This patch also sets the RENDER driver feature.
> 
> Signed-off-by: CK Hu <ck.hu at mediatek.com>
> Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>
> Reviewed-by: Nicolas Boichat <drinkcat at chromium.org>
> Tested-by: Daniel Kurtz <djkurtz at chromium.org>
> Tested-by: Pi-Hsun Shih <pihsun at chromium.org>
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 ++++++
>  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 39 +++++++++++++++++
>  drivers/gpu/drm/mediatek/mtk_drm_gem.h | 12 ++++++
>  include/uapi/drm/mediatek_drm.h        | 58
> ++++++++++++++++++++++++++
>  4 files changed, 122 insertions(+)
>  create mode 100644 include/uapi/drm/mediatek_drm.h
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 2b0c35cacbc6..5d2a39e491aa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -24,6 +24,7 @@
>  #include <drm/drm_of.h>
>  #include <drm/drm_probe_helper.h>
>  #include <drm/drm_vblank.h>
> +#include <drm/mediatek_drm.h>
>  
>  #include "mtk_drm_crtc.h"
>  #include "mtk_drm_ddp_comp.h"
> @@ -569,6 +570,14 @@ static void mtk_drm_kms_deinit(struct drm_device
> *drm)
>  	component_unbind_all(drm->dev, drm);
>  }
>  
> +static const struct drm_ioctl_desc mtk_ioctls[] = {
> +	DRM_IOCTL_DEF_DRV(MTK_GEM_CREATE, mtk_gem_create_ioctl,
> +			  DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
> +	DRM_IOCTL_DEF_DRV(MTK_GEM_MAP_OFFSET,
> +			  mtk_gem_map_offset_ioctl,
> +			  DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),

For secure buffer, we don't need map offset function. If you really
need this function, separate this to another patch and describe why
need this.

Regards,
CK

> +};
> +
>  DEFINE_DRM_GEM_FOPS(mtk_drm_fops);
>  
>  /*
> @@ -590,6 +599,10 @@ static const struct drm_driver mtk_drm_driver =
> {
>  
>  	.gem_prime_import = mtk_drm_gem_prime_import,
>  	.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
> +
> +	.ioctls = mtk_ioctls,
> +	.num_ioctls = ARRAY_SIZE(mtk_ioctls),
> +
>  	.fops = &mtk_drm_fops,
>  
>  	.name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> index 4f2e3feabc0f..30e347adcbe9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include <linux/dma-buf.h>
> +#include <drm/mediatek_drm.h>
>  
>  #include <drm/drm.h>
>  #include <drm/drm_device.h>
> @@ -283,3 +284,41 @@ void mtk_drm_gem_prime_vunmap(struct
> drm_gem_object *obj,
>  	mtk_gem->kvaddr = NULL;
>  	kfree(mtk_gem->pages);
>  }
> +
> +int mtk_gem_map_offset_ioctl(struct drm_device *drm, void *data,
> +			     struct drm_file *file_priv)
> +{
> +	struct drm_mtk_gem_map_off *args = data;
> +
> +	return drm_gem_dumb_map_offset(file_priv, drm, args->handle,
> +				       &args->offset);
> +}
> +
> +int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
> +			 struct drm_file *file_priv)
> +{
> +	struct mtk_drm_gem_obj *mtk_gem;
> +	struct drm_mtk_gem_create *args = data;
> +	int ret;
> +
> +	mtk_gem = mtk_drm_gem_create(dev, args->size, false);
> +	if (IS_ERR(mtk_gem))
> +		return PTR_ERR(mtk_gem);
> +
> +	/*
> +	 * allocate a id of idr table where the obj is registered
> +	 * and handle has the id what user can see.
> +	 */
> +	ret = drm_gem_handle_create(file_priv, &mtk_gem->base, &args-
> >handle);
> +	if (ret)
> +		goto err_handle_create;
> +
> +	/* drop reference from allocate - handle holds it now. */
> +	drm_gem_object_put(&mtk_gem->base);
> +
> +	return 0;
> +
> +err_handle_create:
> +	mtk_drm_gem_free_object(&mtk_gem->base);
> +	return ret;
> +}
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> index 78f23b07a02e..90f3d2916ec5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> @@ -46,4 +46,16 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object
> *obj, struct iosys_map *map);
>  void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj,
>  			      struct iosys_map *map);
>  
> +/*
> + * request gem object creation and buffer allocation as the size
> + * that it is calculated with framebuffer information such as width,
> + * height and bpp.
> + */
> +int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
> +			 struct drm_file *file_priv);
> +
> +/* get buffer offset to map to user space. */
> +int mtk_gem_map_offset_ioctl(struct drm_device *dev, void *data,
> +			     struct drm_file *file_priv);
> +
>  #endif
> diff --git a/include/uapi/drm/mediatek_drm.h
> b/include/uapi/drm/mediatek_drm.h
> new file mode 100644
> index 000000000000..f4d47577c94e
> --- /dev/null
> +++ b/include/uapi/drm/mediatek_drm.h
> @@ -0,0 +1,58 @@
> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef _UAPI_MEDIATEK_DRM_H
> +#define _UAPI_MEDIATEK_DRM_H
> +
> +#include <drm/drm.h>
> +
> +/**
> + * struct drm_mtk_gem_create - User-desired buffer creation
> information structure.
> + *
> + * @size: user-desired memory allocation size.
> + *	- this size value would be page-aligned internally.
> + * @flags: user request for setting memory type or cache attributes.
> + * @handle: returned a handle to created gem object.
> + *	- this handle will be set by gem module of kernel side.
> + */
> +struct drm_mtk_gem_create {
> +	uint64_t size;
> +	uint32_t flags;
> +	uint32_t handle;
> +};
> +
> +/**
> + * struct drm_mtk_gem_map_off - A structure for getting buffer
> offset.
> + *
> + * @handle: a pointer to gem object created.
> + * @pad: just padding to be 64-bit aligned.
> + * @offset: relatived offset value of the memory region allocated.
> + *     - this value should be set by user.
> + */
> +struct drm_mtk_gem_map_off {
> +	uint32_t handle;
> +	uint32_t pad;
> +	uint64_t offset;
> +};
> +
> +#define DRM_MTK_GEM_CREATE		0x00
> +#define DRM_MTK_GEM_MAP_OFFSET		0x01
> +
> +#define DRM_IOCTL_MTK_GEM_CREATE	DRM_IOWR(DRM_COMMAND_BASE + \
> +		DRM_MTK_GEM_CREATE, struct drm_mtk_gem_create)
> +
> +#define DRM_IOCTL_MTK_GEM_MAP_OFFSET	DRM_IOWR(DRM_COMMAND_BASE + \
> +		DRM_MTK_GEM_MAP_OFFSET, struct drm_mtk_gem_map_off)
> +
> +#endif /* _UAPI_MEDIATEK_DRM_H */

From krzysztof.kozlowski at linaro.org  Mon Dec 25 01:24:36 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 25 Dec 2023 10:24:36 +0100
Subject: [PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <28729f48-1357-4f3a-bd7b-e9c34bcf2c58@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
 <20231224143850.5671-4-josua@solid-run.com>
 <d5698668-e589-4ce0-a66f-3b6f107aa257@kernel.org>
 <cadd49fe-8910-4c41-a1de-6efde20d001a@solid-run.com>
 <0be16ab8-8be4-4af4-af0b-4287beeb0386@linaro.org>
 <28729f48-1357-4f3a-bd7b-e9c34bcf2c58@solid-run.com>
Message-ID: <96d42bcb-7928-44d0-8421-87689a1de3bd@linaro.org>

On 24/12/2023 17:29, Josua Mayer wrote:

>>>>> +      - description: |
>>>>> +          SolidRun Armada 388 SoM based clearfog board. This is
>>>>> +          equivalent to clearfog pro, but lacks the "pro" label
>>>>> +          in dtb filename and compatible strings.
>>>>> +        items:
>>>>> +          - const: solidrun,clearfog-a1
>>>> SoM cannot be alone.
>>> Please confirm, I think my wording above was not clear.
>>>
>>> I meant to say "clearfog" devices based on a SoM,.
>>> Armada 388 Clearfog Base / Pro are combinations of SoM and carrier.
>>> Current device-trees do not mention a som-specific compatible string though.
>> So Clearfog Base is a board, then what is Clearfog A1?
> "Clearfog A1" is printed on the silk screen of a Clearfog Pro revision 
> 2.0 or earlier.
> I don't have a later revision to look at.
> So Clearfog A1 and Clearfog Pro? and Clearfog Pro A1 all mean the same 
> board,
> Clearfog Base (+-A1) mean the other board.

Then if A1 and Pro A1 are the same, why do you have A1 here and Pro A1
second time in the entry below?

> 
> "-a1" of the compatible string is already used by openwrt to differentiate.

Does not matter, we do not document out of tree users.

> 
>>
>>> This is in contrast to "Clearfog GTR" which
>>> a) uses aramda-385
>>> b) solders SoC to the board.
>>>
>>>>> +          - const: marvell,armada388
>>>>> +          - const: marvell,armada385
>>>>> +          - const: marvell,armada380
>>>>> +
>>>>> +      - description: SolidRun Armada 388 SoM based clearfog board variants
>>>>> +        items:
>>>>> +          - enum:
>>>>> +             - solidrun,clearfog-base-a1
>>>> Board has name "base"?
>>> Yes.
>>> In marketing and in device-tree model field the board names are
>>> Clearfog Base, Clearfog Pro
>> Then clearfog-base or clearfog-a1-base, but why a1 is at the end? Or is
>> it the case that Clearfog Base can have different SoMs? Think what you
>> have there and choose appropriate compatibles. See Renesas SMARC for one
>> choice and iMX Toradex boards for different example
> Conceptually at this point, is it worth changing the compatibles of 
> existing boards to make sense?

There are no existing boards - you add them here. I have doubts whether
you described it properly, thus my questions.


> Or better to describe them in yaml as they are now (ensuring language is 
> understood)?
> 
> If I try really hard, I can add a new armada-388 som compatible, but 
> that opens another can.
> There are other boards also based on the solidrun armada-388 SoMs, e.g. 
> helios4 - and
> there is no shared -som dtsi.
> Effectively I guess they are all just individual boards, maybe not worth 
> mentioning "SoM".
> 

Depends, is this SoM? If yes, usually you should have SoM DTSI and SoM
compatible.

Best regards,
Krzysztof



From mengqi.zhang at mediatek.com  Mon Dec 25 01:38:38 2023
From: mengqi.zhang at mediatek.com (Mengqi Zhang)
Date: Mon, 25 Dec 2023 17:38:38 +0800
Subject: [PATCH v3 0/1] mmc: core: Add HS400 tuning in HS400es initialization
Message-ID: <20231225093839.22931-1-mengqi.zhang@mediatek.com>

change v3
1. remove mmc_retune_disable() and mmc_retune_enable() from
   hs400es initialization.

change v2
1. remove hs400 tuning from mmc_retune.
2. remove mmc_retune_enable() from hs400es initialization.

Mengqi Zhang (1):
  mmc: core: Add HS400 tuning in HS400es initialization

 drivers/mmc/core/mmc.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

-- 
2.25.1



From mengqi.zhang at mediatek.com  Mon Dec 25 01:38:40 2023
From: mengqi.zhang at mediatek.com (Mengqi Zhang)
Date: Mon, 25 Dec 2023 17:38:40 +0800
Subject: [PATCH v3 1/1] mmc: core: Add HS400 tuning in HS400es initialization
In-Reply-To: <20231225093839.22931-1-mengqi.zhang@mediatek.com>
References: <20231225093839.22931-1-mengqi.zhang@mediatek.com>
Message-ID: <20231225093839.22931-2-mengqi.zhang@mediatek.com>

During the initialization to HS400es stage, add hs400 tuning flow as an
optional process. For Mediatek IP, HS00es mode requires a specific
tuning to ensure the correct HS400 timing setting.

Signed-off-by: Mengqi Zhang <mengqi.zhang at mediatek.com>
---
v1 https://patchwork.kernel.org/project/linux-mediatek/patch/20231201030547.11553-1-mengqi.zhang at mediatek.com/
v2 https://patchwork.kernel.org/project/linux-mediatek/patch/20231222062236.26370-1-mengqi.zhang at mediatek.com/
---
 drivers/mmc/core/mmc.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 705942edacc6..d5173a9bb4b0 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1822,8 +1822,13 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
 
 		if (err)
 			goto free_card;
-
-	} else if (!mmc_card_hs400es(card)) {
+	} else if (mmc_card_hs400es(card)) {
+		if (host->ops->execute_hs400_tuning) {
+			err = host->ops->execute_hs400_tuning(host, card);
+			if (err)
+				goto free_card;
+		}
+	} else {
 		/* Select the desired bus width optionally */
 		err = mmc_select_bus_width(card);
 		if (err > 0 && mmc_card_hs(card)) {
-- 
2.25.1



From fuyao at sjterm.com  Mon Dec 25 01:52:05 2023
From: fuyao at sjterm.com (fuyao)
Date: Mon, 25 Dec 2023 17:52:05 +0800
Subject: [PATCH RESEND] iio: adc: sun4i-gpadc-iio: adaptation interrupt
 number
In-Reply-To: <20231220115412.65bbc8c7@donnerap.manchester.arm.com>
References: <YxmR5SPPY18O7LaG@google.com>
 <YwdhTlk+9h+9Mrwm@scg>
 <20231220115412.65bbc8c7@donnerap.manchester.arm.com>
Message-ID: <ZYlQxccd-_1kyHt5@debian.cyg>

On Wed, Dec 20, 2023 at 11:54:12AM +0000, Andre Przywara wrote:
> On Wed, 20 Dec 2023 15:23:17 +0800
> fuyao <fuyao1697 at cyg.com> wrote:
> 
> Hi,
> 
> > __platform_get_irq_byname determinies whether the interrupt
> > number is 0 and returns EINVAL.
> 
> can you please say what this fixes, exactly? Is something not working at
> the moment? Can you please provide parts of the error message?
> 

With open MFD_SUN4I_GPADC and SUN4I_GPADC, It happens:

[    0.185068] ------------[ cut here ]------------
[    0.185093] WARNING: CPU: 3 PID: 1 at drivers/base/platform.c:451 __platform_get_irq_byname+0xb8/0xc4
[    0.185131] 0 is an invalid IRQ number
[    0.185140] Modules linked in:
[    0.185160] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc6 #9
[    0.185179] Hardware name: Allwinner sun8i Family
[    0.185203]  unwind_backtrace from show_stack+0x10/0x14
[    0.185234]  show_stack from dump_stack_lvl+0x48/0x54
[    0.185262]  dump_stack_lvl from __warn+0xcc/0x1ac
[    0.185285]  __warn from warn_slowpath_fmt+0xb4/0x168
[    0.185304]  warn_slowpath_fmt from __platform_get_irq_byname+0xb8/0xc4
[    0.185328]  __platform_get_irq_byname from platform_get_irq_byname+0x10/0x38
[    0.185354]  platform_get_irq_byname from sun4i_irq_init+0x40/0xdc
[    0.185382]  sun4i_irq_init from sun4i_gpadc_probe+0x1cc/0x310
[    0.185403]  sun4i_gpadc_probe from platform_probe+0x98/0xc0
[    0.185426]  platform_probe from really_probe+0x10c/0x374
[    0.185450]  really_probe from __driver_probe_device+0x90/0x188
[    0.185473]  __driver_probe_device from driver_probe_device+0x3c/0x198
[    0.185496]  driver_probe_device from __driver_attach+0x118/0x1b4
[    0.185518]  __driver_attach from bus_for_each_dev+0x104/0x148
[    0.185540]  bus_for_each_dev from bus_add_driver+0x164/0x25c
[    0.185560]  bus_add_driver from driver_register+0x70/0x118
[    0.185582]  driver_register from do_one_initcall+0xcc/0x29c
[    0.185605]  do_one_initcall from do_initcall_level+0x80/0x8c
[    0.185630]  do_initcall_level from do_initcalls+0x50/0x80
[    0.185653]  do_initcalls from kernel_init_freeable+0xb0/0xfc
[    0.185675]  kernel_init_freeable from kernel_init+0x14/0x1b4
[    0.185698]  kernel_init from ret_from_fork+0x14/0x28
[    0.185720] Exception stack(0xf0825fb0 to 0xf0825ff8)
[    0.185737] 5fa0:                                     00000000 00000000 00000000 00000000
[    0.185756] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.185775] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    0.185788] ---[ end trace 0000000000000000 ]---
[    0.185804] sun4i-gpadc-iio sun6i-a31-gpadc-iio.0: error -EINVAL: IRQ FIFO_DATA_PENDING not found
[    0.185828] sun4i-gpadc-iio: probe of sun6i-a31-gpadc-iio.0 failed with error -22

The gpadc-iio can not request irq.

> And maybe expand the explanation a bit more? For instance mention that the
> identifiers are used as IRQ resource numbers, where 0 is treated specially.
> 

thanks

> Cheers,
> Andre
> 
> > 
> > Signed-off-by: fuyao <fuyao1697 at cyg.com>
> > Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
> > ---
> >  include/linux/mfd/sun4i-gpadc.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> > index ea0ccf33a459..021f820f9d52 100644
> > --- a/include/linux/mfd/sun4i-gpadc.h
> > +++ b/include/linux/mfd/sun4i-gpadc.h
> > @@ -81,8 +81,8 @@
> >  #define SUN4I_GPADC_TEMP_DATA				0x20
> >  #define SUN4I_GPADC_DATA				0x24
> >  
> > -#define SUN4I_GPADC_IRQ_FIFO_DATA			0
> > -#define SUN4I_GPADC_IRQ_TEMP_DATA			1
> > +#define SUN4I_GPADC_IRQ_FIFO_DATA			1
> > +#define SUN4I_GPADC_IRQ_TEMP_DATA			2
> >  
> >  /* 10s delay before suspending the IP */
> >  #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
> 

-- 
CYG Technology.


From fuyao at sjterm.com  Mon Dec 25 01:54:03 2023
From: fuyao at sjterm.com (fuyao)
Date: Mon, 25 Dec 2023 17:54:03 +0800
Subject: [PATCH RESEND] iio: adc: sun4i-gpadc-iio: adaptation interrupt
 number
In-Reply-To: <4953611.0VBMTVartN@jernej-laptop>
References: <YxmR5SPPY18O7LaG@google.com>
 <20231220115412.65bbc8c7@donnerap.manchester.arm.com>
 <20231221152553.GM10102@google.com>
 <4953611.0VBMTVartN@jernej-laptop>
Message-ID: <ZYlROwtUv1iZr5Kj@debian.cyg>

On Fri, Dec 22, 2023 at 06:54:53PM +0100, Jernej ?krabec wrote:
> Dne ?etrtek, 21. december 2023 ob 16:25:53 CET je Lee Jones napisal(a):
> > On Wed, 20 Dec 2023, Andre Przywara wrote:
> > 
> > > On Wed, 20 Dec 2023 15:23:17 +0800
> > > fuyao <fuyao1697 at cyg.com> wrote:
> > > 
> > > Hi,
> > > 
> > > > __platform_get_irq_byname determinies whether the interrupt
> > > > number is 0 and returns EINVAL.
> > > 
> > > can you please say what this fixes, exactly? Is something not working at
> > > the moment? Can you please provide parts of the error message?
> > > 
> > > And maybe expand the explanation a bit more? For instance mention that the
> > > identifiers are used as IRQ resource numbers, where 0 is treated specially.
> > > 
> > > Cheers,
> > > Andre
> > > 
> > > > 
> > > > Signed-off-by: fuyao <fuyao1697 at cyg.com>
> > 
> > You have to use your full real name as well.

> 
> Isn't that enough after
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330 ?

Thanks

> 
> Best regards,
> Jernej
> 
> > 
> > > > Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
> > > > ---
> > > >  include/linux/mfd/sun4i-gpadc.h | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> > > > index ea0ccf33a459..021f820f9d52 100644
> > > > --- a/include/linux/mfd/sun4i-gpadc.h
> > > > +++ b/include/linux/mfd/sun4i-gpadc.h
> > > > @@ -81,8 +81,8 @@
> > > >  #define SUN4I_GPADC_TEMP_DATA				0x20
> > > >  #define SUN4I_GPADC_DATA				0x24
> > > >  
> > > > -#define SUN4I_GPADC_IRQ_FIFO_DATA			0
> > > > -#define SUN4I_GPADC_IRQ_TEMP_DATA			1
> > > > +#define SUN4I_GPADC_IRQ_FIFO_DATA			1
> > > > +#define SUN4I_GPADC_IRQ_TEMP_DATA			2
> > > >  
> > > >  /* 10s delay before suspending the IP */
> > > >  #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
> > > 
> > 
> > 
> 
> 
> 
> 

-- 
CYG Technology.


From fuyao at sjterm.com  Mon Dec 25 02:11:24 2023
From: fuyao at sjterm.com (fuyao)
Date: Mon, 25 Dec 2023 18:11:24 +0800
Subject: [PATCH RESEND] ARM: dts: sun8i: r40: open the regulator aldo1
In-Reply-To: <20231221103906.1830ef94@donnerap.manchester.arm.com>
References: <ZYKjYypuAx7gNuam@debian.cyg>
 <20231220150400.0f32e2a5@donnerap.manchester.arm.com>
 <ZYOhAQi7XeLUuAC9@debian.cyg>
 <20231221103906.1830ef94@donnerap.manchester.arm.com>
Message-ID: <ZYlVTFrWkPaci92K@debian.cyg>

On Thu, Dec 21, 2023 at 10:39:06AM +0000, Andre Przywara wrote:
> On Thu, 21 Dec 2023 10:20:49 +0800
> fuyao <fuyao at sjterm.com> wrote:
> 
> Hi,
> 
> thanks for the reply!
> 
> > On Wed, Dec 20, 2023 at 03:04:00PM +0000, Andre Przywara wrote:
> > > On Wed, 20 Dec 2023 16:18:43 +0800
> > > fuyao <fuyao1697 at cyg.com> wrote:
> > > 
> > > Hi,
> > >   
> > > > the aldo1 is connect regulator pin which power the TV.  
> > > 
> > > What do you mean with that? That ALDO1 is connected to VCC-TVOUT and/or
> > > VCC-TVIN on the R40 SoC?  
> > 
> > The ALDO1 is connected to VCC-TVOUT on the R40 Soc.
> 
> Ah, thanks for the confirmation.
> 
> > > > The USB core use TV ref as reference Voltage.  
> > > 
> > > The USB core in the SoC? So pin VCC-USB, which requires 3.3V, the same
> > > voltage as the TV pins?
> > > Which means this doesn't really have much to do with TV, it's just that
> > > USB and also "TV" are supplied by ALDO1?  
> > 
> > The internal USB PHY requires a reference voltage. It seems that in
> > order to save costs, the reference voltage of the TVOUT module is used.
> 
> Do you mean a USB *reference* voltage that is separate from the USB PHY
> power supply voltage, so pin VCC-USB on the SoC? And that it is internally
> connected to some TV-OUT related circuits? So that would apply to all
> devices using the R40 SoC then?
yes, The usb need a power from TV module insides.
> 
> Or is it simply that the SoC pins VCC-TVOUT and VCC-USB are connected
> together, on this SoM?
no
> Do you have access to some schematic? I couldn't find one online easily,
> so cannot check this myself.
> 
It has up to https://file.io/VSUL4FDrapDY
> Thanks,
> Andre
> 
> > > > Signed-off-by: fuyao <fuyao1697 at cyg.com>
> > > > ---
> > > >  arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > > > index 9f39b5a2bb35..8906170461df 100644
> > > > --- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > > > +++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > > > @@ -42,6 +42,13 @@ &pio {
> > > >  	vcc-pg-supply = <&reg_dldo1>;
> > > >  };
> > > >  
> > > > +&reg_aldo1 {
> > > > +	regulator-always-on;  
> > > 
> > > So did USB never work before, with the DT as in mainline?
> > >   
> > 
> > The USB can work, but is unstable. Occasionally disconnected because of
> > the D+/D- electrical characteristics.
> > 
> > > For always-on regulators it would be good to see some rationale why this
> > > cannot be referenced by its consumer. If it is really supplying the USB
> > > core, that would be a reason, because we don't have a good way of
> > > describing this.
> > >   
> > > > +	regulator-min-microvolt = <3300000>;
> > > > +	regulator-max-microvolt = <3300000>;
> > > > +	regulator-name = "vcc-aldo1";  
> > > 
> > > Regulators should be named after their users, so use something like:
> > > 	regulator-name = "vcc-3v3-tv-usb";
> > >   
> > 
> > thanks.
> > 
> > > That then also serves as documentation of why this is always on.
> > > 
> > > Cheers,
> > > Andre
> > >   
> > > > +};
> > > > +
> > > >  &reg_aldo2 {
> > > >  	regulator-always-on;
> > > >  	regulator-min-microvolt = <1800000>;  
> > >   
> > 

-- 
fuyao [??]


From m.brock at vanmierlo.com  Mon Dec 25 04:10:09 2023
From: m.brock at vanmierlo.com (m.brock at vanmierlo.com)
Date: Mon, 25 Dec 2023 13:10:09 +0100
Subject: [PATCH V7 3/3] tty: serial: uartps: Add rs485 support to uartps
 driver
In-Reply-To: <20231218094415.2503672-4-manikanta.guntupalli@amd.com>
References: <20231218094415.2503672-1-manikanta.guntupalli@amd.com>
 <20231218094415.2503672-4-manikanta.guntupalli@amd.com>
Message-ID: <4d8031d25ac3d38ef1807896fe9a6a9f@vanmierlo.com>

Manikanta Guntupalli wrote on 2023-12-18 10:44:
>  drivers/tty/serial/xilinx_uartps.c | 222 +++++++++++++++++++++++++++--
>  1 file changed, 213 insertions(+), 9 deletions(-)
> 
> @@ -203,10 +209,22 @@ struct cdns_uart {
>  	struct notifier_block	clk_rate_change_nb;
>  	u32			quirks;
>  	bool cts_override;
> +	struct gpio_desc	*gpiod_rts;
> +	bool			rs485_tx_started;
> +	struct timer_list	timer;

start_tx_timer

> +	struct timer_list	stop_tx_timer;

struct hrtimer maybe?

>  };
>  struct cdns_platform_data {
>  	u32 quirks;
>  };
> +
> +struct serial_rs485 cdns_rs485_supported = {
> +	.flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND |
> +		 SER_RS485_RTS_AFTER_SEND,
> +	.delay_rts_before_send = 1,
> +	.delay_rts_after_send = 1,
> +};
> +
>  #define to_cdns_uart(_nb) container_of(_nb, struct cdns_uart, \
>  		clk_rate_change_nb)
> 
> @@ -305,6 +323,55 @@ static void cdns_uart_handle_rx(void *dev_id,
> unsigned int isrstatus)
>  	tty_flip_buffer_push(&port->state->port);
>  }
> 
> +/**
> + * cdns_rts_gpio_enable - Configure RTS/GPIO to high/low
> + * @cdns_uart: Handle to the cdns_uart
> + * @enable: Value to be set to RTS/GPIO
> + */
> +static void cdns_rts_gpio_enable(struct cdns_uart *cdns_uart, bool 
> enable)
> +{
> +	u32 val;
> +
> +	if (cdns_uart->gpiod_rts) {
> +		gpiod_set_value(cdns_uart->gpiod_rts, enable);
> +	} else {
> +		val = readl(cdns_uart->port->membase + CDNS_UART_MODEMCR);
> +		if (enable)
> +			val &= ~CDNS_UART_MODEMCR_RTS;
> +		else
> +			val |= CDNS_UART_MODEMCR_RTS;
> +		writel(val, cdns_uart->port->membase + CDNS_UART_MODEMCR);
> +	}
> +}
> +
> +/**
> + * cdns_rs485_tx_setup - Tx setup specific to rs485
> + * @cdns_uart: Handle to the cdns_uart
> + */
> +static void cdns_rs485_tx_setup(struct cdns_uart *cdns_uart)
> +{
> +	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_ON_SEND)
> +		cdns_rts_gpio_enable(cdns_uart, 1);
> +	else
> +		cdns_rts_gpio_enable(cdns_uart, 0);

Maybe simply:
	bool enable = cdns_uart->port->rs485.flags & SER_RS485_RTS_ON_SEND;
	cdns_rts_gpio_enable(cdns_uart, enable);

> +
> +	cdns_uart->rs485_tx_started = true;
> +}
> +
> +/**
> + * cdns_rs485_rx_setup - Rx setup specific to rs485
> + * @cdns_uart: Handle to the cdns_uart
> + */
> +static void cdns_rs485_rx_setup(struct cdns_uart *cdns_uart)
> +{
> +	if (cdns_uart->port->rs485.flags & SER_RS485_RTS_AFTER_SEND)
> +		cdns_rts_gpio_enable(cdns_uart, 1);
> +	else
> +		cdns_rts_gpio_enable(cdns_uart, 0);

Same here

> +
> +	cdns_uart->rs485_tx_started = false;
> +}
> +
>  /**
>   * cdns_uart_tx_empty -  Check whether TX is empty
>   * @port: Handle to the uart port structure
> @@ -579,6 +646,44 @@ static int cdns_uart_clk_notifier_cb(struct
> notifier_block *nb,
>  }
>  #endif
> 
> +/**
> + * cdns_rs485_rx_callback - Timer rx callback handler for rs485.
> + * @t: Handle to the timer list structure
> + */
> +static void cdns_rs485_rx_callback(struct timer_list *t)
> +{
> +	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
> +
> +	/*
> +	 * Default Rx should be setup, because Rx signaling path
> +	 * need to enable to receive data.
> +	 */
> +	cdns_rs485_rx_setup(cdns_uart);
> +}
> +
> +/**
> + * cdns_rs485_tx_callback - Timer tx callback handler for rs485.
> + * @t: Handle to the timer list structure
> + */
> +static void cdns_rs485_tx_callback(struct timer_list *t)
> +{
> +	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, timer);
> +
> +	uart_port_lock(cdns_uart->port);
> +	cdns_uart_handle_tx(cdns_uart->port);
> +
> +	/* Enable the TX Empty interrupt */
> +	writel(CDNS_UART_IXR_TXEMPTY, cdns_uart->port->membase + 
> CDNS_UART_IER);
> +	uart_port_unlock(cdns_uart->port);
> +
> +	if (uart_circ_empty(&cdns_uart->port->state->xmit) ||
> +	    uart_tx_stopped(cdns_uart->port)) {
> +		timer_setup(&cdns_uart->timer, cdns_rs485_rx_callback, 0);

You really should not do this here. This belongs in 
cdns_uart_handle_tx() which
is also called from the TXEMPTY handler. And make sure TXEMPTY is true 
and on
top you also must account for the time it takes for the last character 
to leave
the transmitter including the stopbit.

See also em485 code in 8250_port.c:
	stop_delay = p->port.frame_time + DIV_ROUND_UP(p->port.frame_time, 7);

> +		mod_timer(&cdns_uart->timer, jiffies +
> +			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));
> +	}

Should you not stop the stop_tx_timer in case it is still running when a 
new
transmission is requested?

> +}
> +
>  /**
>   * cdns_uart_start_tx -  Start transmitting bytes
>   * @port: Handle to the uart port structure
> @@ -586,6 +691,7 @@ static int cdns_uart_clk_notifier_cb(struct
> notifier_block *nb,
>  static void cdns_uart_start_tx(struct uart_port *port)
>  {
>  	unsigned int status;
> +	struct cdns_uart *cdns_uart = port->private_data;
> 
>  	if (uart_tx_stopped(port))
>  		return;
> @@ -604,10 +710,40 @@ static void cdns_uart_start_tx(struct uart_port 
> *port)
> 
>  	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_ISR);
> 
> -	cdns_uart_handle_tx(port);
> +	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
> +		if (!cdns_uart->rs485_tx_started) {
> +			timer_setup(&cdns_uart->timer,
> +				    cdns_rs485_tx_callback, 0);

On a single line

> +			cdns_rs485_tx_setup(cdns_uart);
> +			mod_timer(&cdns_uart->timer, jiffies +
> +				  msecs_to_jiffies(port->rs485.delay_rts_before_send));
> +		} else {
> +			if (!timer_pending(&cdns_uart->timer))
> +				mod_timer(&cdns_uart->timer, jiffies);
> +		}
> +	} else {
> +		cdns_uart_handle_tx(port);
> 
> -	/* Enable the TX Empty interrupt */
> -	writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
> +		/* Enable the TX Empty interrupt */
> +		writel(CDNS_UART_IXR_TXEMPTY, port->membase + CDNS_UART_IER);
> +	}
> +}
> +
> +/**
> + * cdns_rs485_stop_tx_callback - Timer stop tx callback handler for 
> rs485.
> + * @t: Handle to the timer list structure
> + */
> +static void cdns_rs485_stop_tx_callback(struct timer_list *t)
> +{
> +	unsigned int regval;
> +	struct cdns_uart *cdns_uart = from_timer(cdns_uart, t, 
> stop_tx_timer);
> +
> +	cdns_rs485_rx_setup(cdns_uart);
> +
> +	regval = readl(cdns_uart->port->membase + CDNS_UART_CR);
> +	regval |= CDNS_UART_CR_TX_DIS;
> +	/* Disable the transmitter */

Why do you want to do this?

> +	writel(regval, cdns_uart->port->membase + CDNS_UART_CR);
>  }
> 
>  /**
> @@ -617,11 +753,19 @@ static void cdns_uart_start_tx(struct uart_port 
> *port)
>  static void cdns_uart_stop_tx(struct uart_port *port)
>  {
>  	unsigned int regval;
> +	struct cdns_uart *cdns_uart = port->private_data;
> 
> -	regval = readl(port->membase + CDNS_UART_CR);
> -	regval |= CDNS_UART_CR_TX_DIS;
> -	/* Disable the transmitter */
> -	writel(regval, port->membase + CDNS_UART_CR);
> +	if ((cdns_uart->port->rs485.flags & SER_RS485_ENABLED) &&
> +	    !timer_pending(&cdns_uart->stop_tx_timer) &&
> +	    cdns_uart->rs485_tx_started) {
> +		mod_timer(&cdns_uart->stop_tx_timer, jiffies +
> +			  msecs_to_jiffies(cdns_uart->port->rs485.delay_rts_after_send));

Why try to adhere to the rts delay here? The original code doesn't seem 
to care
if the fifo is still filled either. Or was it already broken?

I did not yet find out exactly when this struct uart_ops .stop_tx is 
called.

> +	} else {
> +		regval = readl(port->membase + CDNS_UART_CR);
> +		regval |= CDNS_UART_CR_TX_DIS;
> +		/* Disable the transmitter */
> +		writel(regval, port->membase + CDNS_UART_CR);
> +	}
>  }
> 
>  /**
> @@ -829,6 +973,12 @@ static int cdns_uart_startup(struct uart_port 
> *port)
>  		(CDNS_UART_CR_TXRST | CDNS_UART_CR_RXRST))
>  		cpu_relax();
> 
> +	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
> +		timer_setup(&cdns_uart->stop_tx_timer,
> +			    cdns_rs485_stop_tx_callback, 0);
> +		cdns_rs485_rx_setup(cdns_uart);
> +	}
> +
>  	/*
>  	 * Clear the RX disable bit and then set the RX enable bit to enable
>  	 * the receiver.
> @@ -888,6 +1038,7 @@ static void cdns_uart_shutdown(struct uart_port 
> *port)
>  {
>  	int status;
>  	unsigned long flags;
> +	struct cdns_uart *cdns_uart = port->private_data;
> 
>  	uart_port_lock_irqsave(port, &flags);
> 
> @@ -903,6 +1054,11 @@ static void cdns_uart_shutdown(struct uart_port 
> *port)
>  	uart_port_unlock_irqrestore(port, flags);
> 
>  	free_irq(port->irq, port);
> +
> +	if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED) {
> +		del_timer_sync(&cdns_uart->timer);
> +		del_timer_sync(&cdns_uart->stop_tx_timer);
> +	}
>  }
> 
>  /**
> @@ -1032,7 +1188,7 @@ static void cdns_uart_set_mctrl(struct uart_port
> *port, unsigned int mctrl)
>  	mode_reg &= ~CDNS_UART_MR_CHMODE_MASK;
> 
>  	if (mctrl & TIOCM_RTS)
> -		val |= CDNS_UART_MODEMCR_RTS;
> +		cdns_rts_gpio_enable(cdns_uart_data, 1);

First passing 1 here is wrong. It should be 0.
Also there is no call with the opposite value here.

But this call could modify the MODEMCR register however its result is
immediately overwritten in the lines below with a wrong value in val.
Keep as-is and maybe add the following instead:

+	if (cdns_uart->gpiod_rts)
+		gpiod_set_value(cdns_uart->gpiod_rts, !(mctrl & TIOCM_RTS));

>  	if (mctrl & TIOCM_DTR)
>  		val |= CDNS_UART_MODEMCR_DTR;
>  	if (mctrl & TIOCM_LOOP)
> @@ -1455,6 +1611,37 @@ MODULE_DEVICE_TABLE(of, cdns_uart_of_match);
>  /* Temporary variable for storing number of instances */
>  static int instances;
> 
> +/**
> + * cdns_rs485_config - Called when an application calls TIOCSRS485 
> ioctl.
> + * @port: Pointer to the uart_port structure
> + * @termios: Pointer to the ktermios structure
> + * @rs485: Pointer to the serial_rs485 structure
> + *
> + * Return: 0
> + */
> +static int cdns_rs485_config(struct uart_port *port, struct ktermios 
> *termios,
> +			     struct serial_rs485 *rs485)
> +{
> +	u32 val;
> +	unsigned int ctrl_reg;
> +
> +	if (rs485->flags & SER_RS485_ENABLED) {
> +		dev_dbg(port->dev, "Setting UART to RS485\n");
> +		/* Make sure auto RTS is disabled */
> +		val = readl(port->membase + CDNS_UART_MODEMCR);
> +		val &= ~CDNS_UART_MODEMCR_FCM;
> +		writel(val, port->membase + CDNS_UART_MODEMCR);
> +		/* Disable transmitter and make Rx setup*/
> +		cdns_uart_stop_tx(port);
> +	} else {
> +		/* Disable the TX and RX */
> +		ctrl_reg = readl(port->membase + CDNS_UART_CR);
> +		ctrl_reg |= CDNS_UART_CR_TX_DIS | CDNS_UART_CR_RX_DIS;
> +		writel(ctrl_reg, port->membase + CDNS_UART_CR);

Why would you disable the transmitter and receiver here?

> +	}
> +	return 0;
> +}
> +
>  /**
>   * cdns_uart_probe - Platform driver probe
>   * @pdev: Pointer to the platform device structure
> @@ -1597,9 +1784,23 @@ static int cdns_uart_probe(struct 
> platform_device *pdev)
>  	port->private_data = cdns_uart_data;
>  	port->read_status_mask = CDNS_UART_IXR_TXEMPTY | CDNS_UART_IXR_RXTRIG 
> |
>  			CDNS_UART_IXR_OVERRUN | CDNS_UART_IXR_TOUT;
> +	port->rs485_config = cdns_rs485_config;
> +	port->rs485_supported = cdns_rs485_supported;
>  	cdns_uart_data->port = port;
>  	platform_set_drvdata(pdev, port);
> 
> +	rc = uart_get_rs485_mode(port);
> +	if (rc)
> +		goto err_out_clk_notifier;
> +
> +	cdns_uart_data->gpiod_rts = devm_gpiod_get_optional(&pdev->dev, 
> "rts",
> +							    GPIOD_OUT_LOW);
> +	if (IS_ERR(cdns_uart_data->gpiod_rts)) {
> +		rc = PTR_ERR(cdns_uart_data->gpiod_rts);
> +		dev_err(port->dev, "xuartps: devm_gpiod_get_optional failed\n");
> +		goto err_out_clk_notifier;
> +	}
> +
>  	pm_runtime_use_autosuspend(&pdev->dev);
>  	pm_runtime_set_autosuspend_delay(&pdev->dev, 
> UART_AUTOSUSPEND_TIMEOUT);
>  	pm_runtime_set_active(&pdev->dev);
> @@ -1618,6 +1819,8 @@ static int cdns_uart_probe(struct platform_device 
> *pdev)
>  		console_port = port;
>  	}
>  #endif
> +	if (cdns_uart_data->port->rs485.flags & SER_RS485_ENABLED)
> +		cdns_rs485_rx_setup(cdns_uart_data);
> 
>  	rc = uart_add_one_port(&cdns_uart_uart_driver, port);
>  	if (rc) {
> @@ -1646,6 +1849,7 @@ static int cdns_uart_probe(struct platform_device 
> *pdev)
>  	pm_runtime_disable(&pdev->dev);
>  	pm_runtime_set_suspended(&pdev->dev);
>  	pm_runtime_dont_use_autosuspend(&pdev->dev);
> +err_out_clk_notifier:
>  #ifdef CONFIG_COMMON_CLK
>  	clk_notifier_unregister(cdns_uart_data->uartclk,
>  			&cdns_uart_data->clk_rate_change_nb);

Kind Regards,
Maarten Brock



From mshavit at google.com  Mon Dec 25 04:17:14 2023
From: mshavit at google.com (Michael Shavit)
Date: Mon, 25 Dec 2023 20:17:14 +0800
Subject: [PATCH 04/19] iommu/arm-smmu-v3: Make STE programming independent
 of the callers
In-Reply-To: <CAKHBV27qsgjgwPfn8OpSq30z1w203NDqBZ0s66bPgjp1XDnLOg@mail.gmail.com>
References: <0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com> <CAKHBV24UGZuG6+J4cybadJCTyf9hN+e_VgAC0NVOPotmEur7SQ@mail.gmail.com>
 <20231012121616.GF3952@nvidia.com> <CAKHBV27G1PLZ5gkYkOOCZdD9waZOZypkWqk4_HSR4XXGFT-+LA@mail.gmail.com>
 <20231018130455.GU3952@nvidia.com> <CAKHBV270uJjdj4zeK-NNt+j3TiqoGDdLUQ5uRrLw9PN0ysCDbw@mail.gmail.com>
 <20231020113918.GD3952@nvidia.com> <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
 <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com>
 <ZX7xu8jN/rBZ4A/d@nvidia.com> <CAKHBV26CRC8eWMuOk6EZYMHOZoR2FauP=NBazzOiWCmQYEa1vg@mail.gmail.com>
 <CAKHBV27qsgjgwPfn8OpSq30z1w203NDqBZ0s66bPgjp1XDnLOg@mail.gmail.com>
Message-ID: <CAKHBV24ApTjc3hy-kbMD9Y7wVdb5OPTb8bU6AkZdCQPg+LWDSg@mail.gmail.com>

On Tue, Dec 19, 2023 at 9:42?PM Michael Shavit <mshavit at google.com> wrote:
>
>
> +static void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer,
> +                                __le64 *cur, const __le64 *target,
> +                                __le64 *staging_entry)
> +{
> +       bool cleanup_sync_required = false;
> +       u8 entry_qwords_used_diff = 0;
> +       int i = 0;
> +
> +       entry_qwords_used_diff =
> +               writer->ops.get_used_qword_diff_indexes(cur, target);
> +       if (WARN_ON_ONCE(entry_qwords_used_diff == 0))
> +               return;
> +
> +       if (hweight8(entry_qwords_used_diff) > 1) {
> +               /*
> +                * If transitioning to the target entry with a single qword
> +                * write isn't possible, then we must first transition to an
> +                * intermediate entry. The intermediate entry may either be an
> +                * entry that melds bits of the target entry into the current
> +                * entry without disrupting the hardware, or a breaking entry if
> +                * a hitless transition to the target is impossible.
> +                */
> +
> +               /*
> +                * Compute a staging entry that has all the bits currently
> +                * unused by HW set to their target values, such that comitting
> +                * it to the entry table woudn't disrupt the hardware.
> +                */
> +               memcpy(staging_entry, cur, writer->entry_length);

This should be `memcpy(staging_entry, cur, writer->entry_length *
sizeof(cur[0]));`

>
> +               writer->ops.set_unused_bits(staging_entry, target);
> +
> +               entry_qwords_used_diff =
> +                       writer->ops.get_used_qword_diff_indexes(staging_entry,
> +                                                               target);
> +               if (hweight8(entry_qwords_used_diff) > 1) {
> +                       /*
> +                        * More than 1 qword is mismatched between the staging
> +                        * and target entry. A hitless transition to the target
> +                        * entry is not possible. Set the staging entry to be
> +                        * equal to the target entry, apart from the V bit's
> +                        * qword. As long as the V bit is cleared first then
> +                        * writes to the subsequent qwords will not further
> +                        * disrupt the hardware.
> +                        */
> +                       memcpy(staging_entry, target, writer->entry_length);

 ditto, this should be `memcpy(staging_entry, target,
writer->entry_length * sizeof(target[0]));`


From mshavit at google.com  Mon Dec 25 04:58:06 2023
From: mshavit at google.com (Michael Shavit)
Date: Mon, 25 Dec 2023 20:58:06 +0800
Subject: [PATCH 04/19] iommu/arm-smmu-v3: Make STE programming independent
 of the callers
In-Reply-To: <CAKHBV24ApTjc3hy-kbMD9Y7wVdb5OPTb8bU6AkZdCQPg+LWDSg@mail.gmail.com>
References: <0-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com>
 <4-v1-e289ca9121be+2be-smmuv3_newapi_p1_jgg@nvidia.com> <CAKHBV24UGZuG6+J4cybadJCTyf9hN+e_VgAC0NVOPotmEur7SQ@mail.gmail.com>
 <20231012121616.GF3952@nvidia.com> <CAKHBV27G1PLZ5gkYkOOCZdD9waZOZypkWqk4_HSR4XXGFT-+LA@mail.gmail.com>
 <20231018130455.GU3952@nvidia.com> <CAKHBV270uJjdj4zeK-NNt+j3TiqoGDdLUQ5uRrLw9PN0ysCDbw@mail.gmail.com>
 <20231020113918.GD3952@nvidia.com> <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
 <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com>
 <ZX7xu8jN/rBZ4A/d@nvidia.com> <CAKHBV26CRC8eWMuOk6EZYMHOZoR2FauP=NBazzOiWCmQYEa1vg@mail.gmail.com>
 <CAKHBV27qsgjgwPfn8OpSq30z1w203NDqBZ0s66bPgjp1XDnLOg@mail.gmail.com> <CAKHBV24ApTjc3hy-kbMD9Y7wVdb5OPTb8bU6AkZdCQPg+LWDSg@mail.gmail.com>
Message-ID: <CAKHBV26kVYoXP-vNtQMhv3fBDYSmSCG5AU8eyU=D6fWUV1BCBQ@mail.gmail.com>

Ok I'm probably getting ahead of myself here, but on an nth re-read to
sanity check things I realized that this is pretty well suited to
unit-testing. In fact that's how I caught the bug that this last email
fixed.

(Sorry for duplicate email Jason, first email was accidentally off-list).

---
>From 8b71430fd55a40203d600b29da93b413af4349ee Mon Sep 17 00:00:00 2001
From: Michael Shavit <mshavit at google.com>
Date: Fri, 22 Dec 2023 16:54:12 +0800
Subject: [PATCH] iommu/arm-smmu-v3: Add unit tests for arm_smmu_write_entry

Add tests for some of the more common STE update operations that we
expect to see, as well as some artificial STE updates to test the edges
of arm_smmu_write_entry. These also serve as a record of which common
operation is expected to be hitless, and how many syncs they require.

arm_smmu_write_entry implements a generic algorithm that updates an
STE/CD to any other abritrary STE/CD configuration. The update requires
a sequence of write+sync operations, with some invariants that must be
held true after each sync. arm_smmu_write_entry lends itself well to
unit-testing since the function's interaction with the STE/CD is already
abstracted by input callbacks that we can hook to introspect into the
sequence of operations. We can use these hooks to guarantee that
invariants are held throughout the entire update operation.

Signed-off-by: Michael Shavit <mshavit at google.com>
---

 drivers/iommu/Kconfig                         |   9 +
 drivers/iommu/arm/arm-smmu-v3/Makefile        |   2 +
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c  | 344 ++++++++++++++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   |  41 +--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  38 +-
 5 files changed, 400 insertions(+), 34 deletions(-)
 create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 7673bb82945b6..e4c4071115c8e 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -405,6 +405,15 @@ config ARM_SMMU_V3_SVA
          Say Y here if your system supports SVA extensions such as PCIe PASID
          and PRI.

+config ARM_SMMU_V3_KUNIT_TEST
+       tristate "KUnit tests for arm-smmu-v3 driver"  if !KUNIT_ALL_TESTS
+       depends on ARM_SMMU_V3 && KUNIT
+       default KUNIT_ALL_TESTS
+       help
+         Enable this option to unit-test arm-smmu-v3 driver functions.
+
+         If unsure, say N.
+
 config S390_IOMMU
        def_bool y if S390 && PCI
        depends on S390 && PCI
diff --git a/drivers/iommu/arm/arm-smmu-v3/Makefile
b/drivers/iommu/arm/arm-smmu-v3/Makefile
index 54feb1ecccad8..014a997753a8a 100644
--- a/drivers/iommu/arm/arm-smmu-v3/Makefile
+++ b/drivers/iommu/arm/arm-smmu-v3/Makefile
@@ -3,3 +3,5 @@ obj-$(CONFIG_ARM_SMMU_V3) += arm_smmu_v3.o
 arm_smmu_v3-objs-y += arm-smmu-v3.o
 arm_smmu_v3-objs-$(CONFIG_ARM_SMMU_V3_SVA) += arm-smmu-v3-sva.o
 arm_smmu_v3-objs := $(arm_smmu_v3-objs-y)
+
+obj-$(CONFIG_ARM_SMMU_V3_KUNIT_TEST) += arm-smmu-v3-test.o
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c
new file mode 100644
index 0000000000000..2e59e157bf528
--- /dev/null
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <kunit/test.h>
+
+#include "arm-smmu-v3.h"
+
+struct arm_smmu_test_writer {
+       struct arm_smmu_entry_writer writer;
+       struct kunit *test;
+       __le64 *(*get_used_bits)(struct arm_smmu_test_writer *test_writer,
+                                const __le64 *entry);
+
+       const __le64 *init_entry;
+       const __le64 *target_entry;
+       __le64 *entry;
+
+       bool invalid_entry_written;
+       int num_syncs;
+};
+
+static bool arm_smmu_entry_differs_in_used_bits(const __le64 *entry,
+                                               const __le64 *used_bits,
+                                               const __le64 *target,
+                                               unsigned int length)
+{
+       bool differs = false;
+       int i;
+
+       for (i = 0; i < length; i++) {
+               if ((entry[i] & used_bits[i]) != target[i])
+                       differs = true;
+       }
+       return differs;
+}
+
+static void
+arm_smmu_test_writer_record_syncs(struct arm_smmu_entry_writer *writer)
+{
+       struct arm_smmu_test_writer *test_writer =
+               container_of(writer, struct arm_smmu_test_writer, writer);
+       __le64 *entry_used_bits;
+
+       pr_debug("STE value is now set to: ");
+       print_hex_dump_debug("    ", DUMP_PREFIX_NONE, 16, 8,
+                            test_writer->entry,
+                            writer->entry_length * sizeof(*test_writer->entry),
+                            false);
+
+       test_writer->num_syncs += 1;
+       if (!(test_writer->entry[0] & writer->v_bit))
+               test_writer->invalid_entry_written = true;
+       else {
+               /*
+                * At any stage in a hitless transition, the entry must be
+                * equivalent to either the initial entry or the target entry
+                * when only considering the bits used by the current
+                * configuration.
+                */
+               entry_used_bits = test_writer->get_used_bits(
+                       test_writer, test_writer->entry);
+               KUNIT_EXPECT_FALSE(test_writer->test,
+                                  arm_smmu_entry_differs_in_used_bits(
+                                          test_writer->entry, entry_used_bits,
+                                          test_writer->init_entry,
+                                          writer->entry_length) &&
+                                          arm_smmu_entry_differs_in_used_bits(
+                                                  test_writer->entry,
+                                                  entry_used_bits,
+                                                  test_writer->target_entry,
+                                                  writer->entry_length));
+       }
+}
+
+static __le64 *
+arm_smmu_test_ste_writer_get_used_bits(struct arm_smmu_test_writer
*test_writer,
+                                      const __le64 *entry)
+{
+       struct arm_smmu_ste *used_bits = kunit_kzalloc(
+               test_writer->test, sizeof(*used_bits), GFP_KERNEL);
+
+       arm_smmu_get_ste_used(entry, used_bits);
+       return used_bits->data;
+}
+
+static void
+arm_smmu_v3_test_ste_debug_print_used_bits(const struct arm_smmu_ste *ste)
+{
+       struct arm_smmu_ste used_bits = { 0 };
+
+       arm_smmu_get_ste_used(ste->data, &used_bits);
+       pr_debug("STE used bits: ");
+       print_hex_dump_debug(
+               "    ", DUMP_PREFIX_NONE, 16, 8, used_bits.data,
+               ARRAY_SIZE(used_bits.data) * sizeof(*used_bits.data), false);
+}
+
+static void arm_smmu_v3_test_ste_expect_transition(
+       struct kunit *test, const struct arm_smmu_ste *cur,
+       const struct arm_smmu_ste *target, int num_syncs_expected, bool hitless)
+{
+       struct arm_smmu_ste cur_copy;
+       struct arm_smmu_ste preallocated_staging_ste = { 0 };
+       struct arm_smmu_entry_writer_ops arm_smmu_test_writer_ops = {
+               .sync_entry = arm_smmu_test_writer_record_syncs,
+               .set_unused_bits = arm_smmu_ste_set_unused_bits,
+               .get_used_qword_diff_indexes =
+                       arm_smmu_ste_used_qword_diff_indexes,
+       };
+       struct arm_smmu_test_writer test_writer = {
+               .writer = {
+                       .ops = arm_smmu_test_writer_ops,
+                       .v_bit = cpu_to_le64(STRTAB_STE_0_V),
+                       .entry_length = ARRAY_SIZE(cur_copy.data),
+               },
+               .get_used_bits = arm_smmu_test_ste_writer_get_used_bits,
+               .test = test,
+               .init_entry = cur->data,
+               .target_entry = target->data,
+               .entry = cur_copy.data,
+               .num_syncs = 0,
+               .invalid_entry_written = false,
+
+       };
+       memcpy(&cur_copy, cur, sizeof(cur_copy));
+
+       pr_debug("STE initial value: ");
+       print_hex_dump_debug("    ", DUMP_PREFIX_NONE, 16, 8, cur_copy.data,
+                            ARRAY_SIZE(cur_copy.data) * sizeof(*cur_copy.data),
+                            false);
+       arm_smmu_v3_test_ste_debug_print_used_bits(cur);
+       pr_debug("STE target value: ");
+       print_hex_dump_debug("    ", DUMP_PREFIX_NONE, 16, 8, target->data,
+                            ARRAY_SIZE(cur_copy.data) * sizeof(*cur_copy.data),
+                            false);
+       arm_smmu_v3_test_ste_debug_print_used_bits(target);
+
+       arm_smmu_write_entry(&test_writer.writer, cur_copy.data, target->data,
+                            preallocated_staging_ste.data);
+
+       KUNIT_EXPECT_EQ(test, test_writer.invalid_entry_written, !hitless);
+       KUNIT_EXPECT_EQ(test, test_writer.num_syncs, num_syncs_expected);
+       KUNIT_EXPECT_MEMEQ(test, target->data, cur_copy.data,
+                          ARRAY_SIZE(cur_copy.data));
+}
+
+static void arm_smmu_v3_test_ste_expect_non_hitless_transition(
+       struct kunit *test, const struct arm_smmu_ste *cur,
+       const struct arm_smmu_ste *target, int num_syncs_expected)
+{
+       arm_smmu_v3_test_ste_expect_transition(test, cur, target,
+                                              num_syncs_expected, false);
+}
+
+static void arm_smmu_v3_test_ste_expect_hitless_transition(
+       struct kunit *test, const struct arm_smmu_ste *cur,
+       const struct arm_smmu_ste *target, int num_syncs_expected)
+{
+       arm_smmu_v3_test_ste_expect_transition(test, cur, target,
+                                              num_syncs_expected, true);
+}
+
+static const dma_addr_t fake_cdtab_dma_addr = 0xF0F0F0F0F0F0;
+
+static void arm_smmu_test_make_cdtable_ste(struct arm_smmu_ste *ste,
+                                          unsigned int s1dss,
+                                          const dma_addr_t dma_addr)
+{
+       struct arm_smmu_master master;
+       struct arm_smmu_ctx_desc_cfg cd_table;
+       struct arm_smmu_device smmu;
+
+       cd_table.cdtab_dma = dma_addr;
+       cd_table.s1cdmax = 0xFF;
+       cd_table.s1fmt = STRTAB_STE_0_S1FMT_64K_L2;
+       smmu.features = ARM_SMMU_FEAT_STALLS;
+       master.smmu = &smmu;
+
+       arm_smmu_make_cdtable_ste(ste, &master, &cd_table, true, s1dss);
+}
+
+struct arm_smmu_ste bypass_ste;
+struct arm_smmu_ste abort_ste;
+
+static int arm_smmu_v3_test_suite_init(struct kunit_suite *test)
+{
+       arm_smmu_make_bypass_ste(&bypass_ste);
+       arm_smmu_make_abort_ste(&abort_ste);
+
+       return 0;
+}
+
+static void arm_smmu_v3_write_ste_test_bypass_to_abort(struct kunit *test)
+{
+       /*
+        * Bypass STEs has used bits in the first two Qwords, while abort STEs
+        * only have used bits in the first QWord. Transitioning from bypass to
+        * abort requires two syncs: the first to set the first qword and make
+        * the STE into an abort, the second to clean up the second qword.
+        */
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &bypass_ste, &abort_ste,
+               /*num_syncs_expected=*/2);
+}
+
+static void arm_smmu_v3_write_ste_test_abort_to_bypass(struct kunit *test)
+{
+       /*
+        * Transitioning from abort to bypass also requires two syncs: the first
+        * to set the second qword data required by the bypass STE, and the
+        * second to set the first qword and switch to bypass.
+        */
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &abort_ste, &bypass_ste,
+               /*num_syncs_expected=*/2);
+}
+
+static void arm_smmu_v3_write_ste_test_cdtable_to_abort(struct kunit *test)
+{
+       struct arm_smmu_ste ste;
+
+       arm_smmu_test_make_cdtable_ste(&ste, STRTAB_STE_1_S1DSS_SSID0,
+                                      fake_cdtab_dma_addr);
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &ste, &abort_ste,
+               /*num_syncs_expected=*/2);
+}
+
+static void arm_smmu_v3_write_ste_test_abort_to_cdtable(struct kunit *test)
+{
+       struct arm_smmu_ste ste;
+
+       arm_smmu_test_make_cdtable_ste(&ste, STRTAB_STE_1_S1DSS_SSID0,
+                                      fake_cdtab_dma_addr);
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &abort_ste, &ste,
+               /*num_syncs_expected=*/2);
+}
+
+static void arm_smmu_v3_write_ste_test_cdtable_to_bypass(struct kunit *test)
+{
+       struct arm_smmu_ste ste;
+
+       arm_smmu_test_make_cdtable_ste(&ste, STRTAB_STE_1_S1DSS_SSID0,
+                                      fake_cdtab_dma_addr);
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &ste, &bypass_ste,
+               /*num_syncs_expected=*/3);
+}
+
+static void arm_smmu_v3_write_ste_test_bypass_to_cdtable(struct kunit *test)
+{
+       struct arm_smmu_ste ste;
+
+       arm_smmu_test_make_cdtable_ste(&ste, STRTAB_STE_1_S1DSS_SSID0,
+                                      fake_cdtab_dma_addr);
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &bypass_ste, &ste,
+               /*num_syncs_expected=*/3);
+}
+
+static void arm_smmu_v3_write_ste_test_cdtable_s1dss_change(struct kunit *test)
+{
+       struct arm_smmu_ste ste;
+       struct arm_smmu_ste s1dss_bypass;
+
+       arm_smmu_test_make_cdtable_ste(&ste, STRTAB_STE_1_S1DSS_SSID0,
+                                      fake_cdtab_dma_addr);
+       arm_smmu_test_make_cdtable_ste(&s1dss_bypass, STRTAB_STE_1_S1DSS_BYPASS,
+                                      fake_cdtab_dma_addr);
+
+       /*
+        * Flipping s1dss on a CD table STE only involves changes to the second
+        * qword of an STE and can be done in a single write.
+        */
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &ste, &s1dss_bypass,
+               /*num_syncs_expected=*/1);
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &s1dss_bypass, &ste,
+               /*num_syncs_expected=*/1);
+}
+
+static void
+arm_smmu_v3_write_ste_test_s1dssbypass_to_stebypass(struct kunit *test)
+{
+       struct arm_smmu_ste s1dss_bypass;
+
+       arm_smmu_test_make_cdtable_ste(&s1dss_bypass, STRTAB_STE_1_S1DSS_BYPASS,
+                                      fake_cdtab_dma_addr);
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &s1dss_bypass, &bypass_ste,
+               /*num_syncs_expected=*/2);
+}
+
+static void
+arm_smmu_v3_write_ste_test_stebypass_to_s1dssbypass(struct kunit *test)
+{
+       struct arm_smmu_ste s1dss_bypass;
+
+       arm_smmu_test_make_cdtable_ste(&s1dss_bypass, STRTAB_STE_1_S1DSS_BYPASS,
+                                      fake_cdtab_dma_addr);
+       arm_smmu_v3_test_ste_expect_hitless_transition(
+               test, &bypass_ste, &s1dss_bypass,
+               /*num_syncs_expected=*/2);
+}
+
+static void arm_smmu_v3_write_ste_test_non_hitless(struct kunit *test)
+{
+       struct arm_smmu_ste ste;
+       struct arm_smmu_ste ste_2;
+
+       /*
+        * Although no flow resembles this in practice, one way to force an STE
+        * update to be non-hitless is to change its CD table pointer as well as
+        * s1 dss field in the same update.
+        */
+       arm_smmu_test_make_cdtable_ste(&ste, STRTAB_STE_1_S1DSS_SSID0,
+                                      fake_cdtab_dma_addr);
+       arm_smmu_test_make_cdtable_ste(&ste_2, STRTAB_STE_1_S1DSS_BYPASS,
+                                      0x4B4B4b4B4B);
+       arm_smmu_v3_test_ste_expect_non_hitless_transition(
+               test, &ste, &ste_2,
+               /*num_syncs_expected=*/2);
+}
+
+static struct kunit_case arm_smmu_v3_test_cases[] = {
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_bypass_to_abort),
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_abort_to_bypass),
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_cdtable_to_abort),
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_abort_to_cdtable),
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_cdtable_to_bypass),
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_bypass_to_cdtable),
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_cdtable_s1dss_change),
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_s1dssbypass_to_stebypass),
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_stebypass_to_s1dssbypass),
+       KUNIT_CASE(arm_smmu_v3_write_ste_test_non_hitless),
+       {},
+};
+
+static struct kunit_suite arm_smmu_v3_test_module = {
+       .name = "arm-smmu-v3-kunit-test",
+       .suite_init = arm_smmu_v3_test_suite_init,
+       .test_cases = arm_smmu_v3_test_cases,
+};
+kunit_test_suites(&arm_smmu_v3_test_module);
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 0accd00ed1918..ec15a8c6a0f65 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -967,31 +967,6 @@ void arm_smmu_tlb_inv_asid(struct arm_smmu_device
*smmu, u16 asid)
        arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd);
 }

-struct arm_smmu_entry_writer;
-
-/**
- * struct arm_smmu_entry_writer_ops - Helper class for writing a CD/STE entry.
- * @sync_entry: sync entry to the hardware after writing to it.
- * @set_unused_bits: Make bits of the entry that aren't in use by the hardware
- *                   equal to the target's bits.
- * @get_used_qword_diff_indexes: Compute the list of qwords in the entry that
- *                               are incorrect compared to the target,
- *                               considering only the used bits in the target.
- *                               The set bits in the return value
represents the
- *                               indexes of those qwords.
- */
-struct arm_smmu_entry_writer_ops {
-       void (*sync_entry)(struct arm_smmu_entry_writer *);
-       void (*set_unused_bits)(__le64 *entry, const __le64 *target);
-       u8 (*get_used_qword_diff_indexes)(__le64 *entry, const __le64 *target);
-};
-
-struct arm_smmu_entry_writer {
-       struct arm_smmu_entry_writer_ops ops;
-       __le64 v_bit;
-       unsigned int entry_length;
-};
-
 static void arm_smmu_entry_set_unused_bits(__le64 *entry, const __le64 *target,
                                           const __le64 *entry_used,
                                           unsigned int length)
@@ -1046,7 +1021,7 @@ static u8
arm_smmu_entry_used_qword_diff_indexes(__le64 *entry,
  * V=0 process. This relies on the IGNORED behavior described in the
  * specification
  */
-static void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer,
+void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer,
                                 __le64 *cur, const __le64 *target,
                                 __le64 *staging_entry)
 {
@@ -1466,8 +1441,8 @@ static void arm_smmu_sync_ste_for_sid(struct
arm_smmu_device *smmu, u32 sid)
  * would be nice if this was complete according to the spec, but minimally it
  * has to capture the bits this driver uses.
  */
-static void arm_smmu_get_ste_used(const __le64 *ent,
-                                 struct arm_smmu_ste *used_bits)
+void arm_smmu_get_ste_used(const __le64 *ent,
+                         struct arm_smmu_ste *used_bits)
 {
        memset(used_bits, 0, sizeof(*used_bits));

@@ -1523,7 +1498,7 @@ struct arm_smmu_ste_writer {
        u32 sid;
 };

-static void arm_smmu_ste_set_unused_bits(__le64 *entry, const __le64 *target)
+void arm_smmu_ste_set_unused_bits(__le64 *entry, const __le64 *target)
 {
        struct arm_smmu_ste entry_used;
        arm_smmu_get_ste_used(entry, &entry_used);
@@ -1532,7 +1507,7 @@ static void arm_smmu_ste_set_unused_bits(__le64
*entry, const __le64 *target)
                                       ARRAY_SIZE(entry_used.data));
 }

-static u8 arm_smmu_ste_used_qword_diff_indexes(__le64 *cur,
+u8 arm_smmu_ste_used_qword_diff_indexes(__le64 *cur,
                                               const __le64 *target)
 {
        struct arm_smmu_ste target_used;
@@ -1588,7 +1563,7 @@ static void arm_smmu_write_ste(struct
arm_smmu_device *smmu, u32 sid,
        }
 }

-static void arm_smmu_make_abort_ste(struct arm_smmu_ste *target)
+void arm_smmu_make_abort_ste(struct arm_smmu_ste *target)
 {
        memset(target, 0, sizeof(*target));
        target->data[0] = cpu_to_le64(
@@ -1596,7 +1571,7 @@ static void arm_smmu_make_abort_ste(struct
arm_smmu_ste *target)
                FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_ABORT));
 }

-static void arm_smmu_make_bypass_ste(struct arm_smmu_ste *target)
+void arm_smmu_make_bypass_ste(struct arm_smmu_ste *target)
 {
        memset(target, 0, sizeof(*target));
        target->data[0] = cpu_to_le64(
@@ -1606,7 +1581,7 @@ static void arm_smmu_make_bypass_ste(struct
arm_smmu_ste *target)
                FIELD_PREP(STRTAB_STE_1_SHCFG, STRTAB_STE_1_SHCFG_INCOMING));
 }

-static void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
+void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
                                      struct arm_smmu_master *master,
                                      struct arm_smmu_ctx_desc_cfg *cd_table,
                                      bool ats_enabled, unsigned int s1dss)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 91b23437f4105..9789f18a04a59 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -752,6 +752,43 @@ struct arm_smmu_master_domain {
        u16 ssid;
 };

+struct arm_smmu_entry_writer;
+
+/**
+ * struct arm_smmu_entry_writer_ops - Helper class for writing a CD/STE entry.
+ * @sync_entry: sync entry to the hardware after writing to it.
+ * @set_unused_bits: Make bits of the entry that aren't in use by the hardware
+ *                   equal to the target's bits.
+ * @get_used_qword_diff_indexes: Compute the list of qwords in the entry that
+ *                               are incorrect compared to the target,
+ *                               considering only the used bits in the target.
+ *                               The set bits in the return value
represents the
+ *                               indexes of those qwords.
+ */
+struct arm_smmu_entry_writer_ops {
+       void (*sync_entry)(struct arm_smmu_entry_writer *writer);
+       void (*set_unused_bits)(__le64 *entry, const __le64 *target);
+       u8 (*get_used_qword_diff_indexes)(__le64 *entry, const __le64 *target);
+};
+
+struct arm_smmu_entry_writer {
+       struct arm_smmu_entry_writer_ops ops;
+       __le64 v_bit;
+       unsigned int entry_length;
+};
+
+void arm_smmu_get_ste_used(const __le64 *ent, struct arm_smmu_ste *used_bits);
+void arm_smmu_ste_set_unused_bits(__le64 *entry, const __le64 *target);
+u8 arm_smmu_ste_used_qword_diff_indexes(__le64 *cur, const __le64 *target);
+void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer, __le64 *cur,
+                         const __le64 *target, __le64 *staging_entry);
+void arm_smmu_make_abort_ste(struct arm_smmu_ste *target);
+void arm_smmu_make_bypass_ste(struct arm_smmu_ste *target);
+void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target,
+                                     struct arm_smmu_master *master,
+                                     struct arm_smmu_ctx_desc_cfg *cd_table,
+                                     bool ats_enabled, unsigned int s1dss);
+
 static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
 {
        return container_of(dom, struct arm_smmu_domain, domain);
@@ -783,7 +820,6 @@ void arm_smmu_make_s1_cd(struct arm_smmu_cd *target,
 void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
                             struct arm_smmu_cd *cdptr,
                             const struct arm_smmu_cd *target);
-
 int arm_smmu_set_pasid(struct arm_smmu_master *master,
                       struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
                       struct arm_smmu_cd *cd);

base-commit: 5c93358344002b351615b6f8c8c526a7ae83f72d
--
2.43.0.472.g3155946c3a-goog


From krzysztof.kozlowski at linaro.org  Mon Dec 25 05:11:03 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 25 Dec 2023 14:11:03 +0100
Subject: [PATCH RFC] dt-bindings: nvmem: u-boot, env: add any-name MAC
 cells compatible
In-Reply-To: <1b4feb5d-f03c-44b3-9474-901534db5eb7@gmail.com>
References: <20231214153620.23998-1-zajec5@gmail.com>
 <CAPnjgZ31AAauR876W1RmU4JPzKUD8XAMCZrJDumE+Dr4miqABQ@mail.gmail.com>
 <1b4feb5d-f03c-44b3-9474-901534db5eb7@gmail.com>
Message-ID: <7e2f36fa-c201-4c8b-a485-077f65a9a0e1@linaro.org>

On 18/12/2023 23:02, Rafa? Mi?ecki wrote:
> On 14.12.2023 22:27, Simon Glass wrote:
>> On Thu, 14 Dec 2023 at 08:36, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
>>>
>>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>>
>>> So far we had a property for "ethaddr" NVMEM cell containing base
>>> Ethernet MAC address. The problem is vendors often pick non-standard
>>> names for storing MAC(s) (other than "ethaddr"). A few names were
>>> noticed over years:
>>> 1. "wanaddr" (Edimax, ELECOM, EnGenius, I-O DATA, Sitecom)
>>> 2. "et1macaddr" (ASUS)
>>> 3. "eth1addr" (Buffalo)
>>> 4. "athaddr" (EnGenius)
>>> 5. "baseMAC" (Netgear)
>>> 6. "mac" (Netgear)
>>> 7. "mac_addr" (Moxa)
>>> and more ("HW_LAN_MAC", "HW_WAN_MAC", "INIC_MAC_ADDR", "LAN_MAC_ADDR",
>>> "RADIOADDR0", "RADIOADDR1", "WAN_MAC_ADDR", "lan1_mac_addr", "wanmac",
>>> "wmac1", "wmac2").
>>>
>>> It doesn't make sense to add property for every possible MAC cell name.
>>> Instead allow specifying cells with "mac" compatible.
>>>
>>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
>>> ---
>>> List of devices and their U-Boot MAC variables:
>>> alphanetworks,asl56026) wanmac
>>> asus,rt-ac65p) et1macaddr
>>> asus,rt-ac85p) et1macaddr
>>> belkin,f9k1109v1) HW_WAN_MAC + HW_LAN_MAC
>>> buffalo,ls220de) eth1addr
>>> buffalo,ls421de) eth1addr
>>> checkpoint,l-50) lan1_mac_addr
>>> dovado,tiny-ac) INIC_MAC_ADDR
>>> dovado,tiny-ac) LAN_MAC_ADDR + WAN_MAC_ADDR
>>> edimax,ra21s) wanaddr
>>> edimax,rg21s) wanaddr
>>> elecom,wrc-2533ghbk-i) wanaddr
>>> elecom,wrc-2533ghbk2-t) wanaddr
>>> engenius,ecb1200) athaddr
>>> engenius,ecb1750) athaddr
>>> engenius,epg5000) wanaddr
>>> engenius,epg600) wanaddr
>>> engenius,esr1200) wanaddr
>>> engenius,esr1750) wanaddr
>>> engenius,esr600) wanaddr
>>> engenius,esr600h) wanaddr
>>> engenius,esr900) wanaddr
>>> enterasys,ws-ap3705i) RADIOADDR0 + RADIOADDR1
>>> iodata,wn-ac1167dgr) wanaddr
>>> iodata,wn-ac1167gr) wanaddr
>>> iodata,wn-ac1600dgr) wanaddr
>>> iodata,wn-ac1600dgr2) wanaddr
>>> iodata,wn-ac733gr3) wanaddr
>>> iodata,wn-ag300dgr) wanaddr
>>> iodata,wnpr2600g) wanaddr
>>> moxa,awk-1137c) mac_addr
>>> netgear,wax220) mac
>>> netgear,wndap620) baseMAC
>>> netgear,wndap660) baseMAC
>>> ocedo,panda) wmac1 + wmac2
>>> sitecom,wlr-7100) wanaddr
>>> sitecom,wlr-8100) wanaddr
>>>
>>>   .../devicetree/bindings/nvmem/u-boot,env.yaml | 33 +++++++++++++++++++
>>>   1 file changed, 33 insertions(+)
>>>
>>
>> Are these upstream U-Boots, or just vendor forks?
> 
> I guess most of those devices don't have upstream U-Boot support. Please

We do not document properties used in all possible projects, like vendor
forks. Only upstream U-Boot matters.

> note that while upstreaming vendors changes would be great in most cases
> it doesn't happen. Most vendors sadly don't care and most end users
> don't have enough time for that. In practice we often stick with vendor
> provided bootloader to flash and boot self build Linux system (like
> OpenWrt).
> 
> I'm not sure if/how does it help with this PATCH but please note that
> upstream U-Boot code also supports few extra variables.
> 
> There is generic eth_env_get_enetaddr_by_index() that supports variables
> like "<%s><%d>addr" and "<%s>addr". Right now it's used only for
> "eth<%d>addr" and "ethaddr" so that mostly limits us to "ethaddr",
> "eth1addr", "eth2addr" and "eth3addr".
> 
>  From some rare cases: there are also "usbnet_devaddr" and "wolpassword".
> 
> So given that U-Boot oficially supports at least 6 env variables for
> MAC and there are many used with custom U-Boots and firmwares this
> binding would help a lot.

Please limit this to upstream U-Boot. Drop all custom and firmware ones.

Then, just fix upstream U-Boot to have only one property...

Best regards,
Krzysztof



From eugen.hristev at collabora.com  Mon Dec 25 05:36:15 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Mon, 25 Dec 2023 15:36:15 +0200
Subject: [PATCH] pmdomain: mediatek: fix race conditions with genpd
Message-ID: <20231225133615.78993-1-eugen.hristev@collabora.com>

If the power domains are registered first with genpd and *after that*
the driver attempts to power them on in the probe sequence, then it is
possible that a race condition occurs if genpd tries to power them on
in the same time.
The same is valid for powering them off before unregistering them
from genpd.
Attempt to fix race conditions by first removing the domains from genpd
and *after that* powering down domains.
Also first power up the domains and *after that* register them
to genpd.

Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power domains")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---

This comes as another way to fix the problem as described in this thread:
https://lore.kernel.org/linux-arm-kernel/20231129113120.4907-1-eugen.hristev at collabora.com/

I have not been able to reproduce the problem with either fix anymore
(so far).

I have a few doubts about this one though, if I really covered the
way it's supposed to work, and registering the pmdomains in the recursive
function in the reversed order has any side effect or if it does not
work correctly.
Tested on mt8186 where it appears to be fine.

Eugen

 drivers/pmdomain/mediatek/mtk-pm-domains.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
index e26dc17d07ad..e274e3315fe7 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
@@ -561,6 +561,11 @@ static int scpsys_add_subdomain(struct scpsys *scpsys, struct device_node *paren
 			goto err_put_node;
 		}
 
+		/* recursive call to add all subdomains */
+		ret = scpsys_add_subdomain(scpsys, child);
+		if (ret)
+			goto err_put_node;
+
 		ret = pm_genpd_add_subdomain(parent_pd, child_pd);
 		if (ret) {
 			dev_err(scpsys->dev, "failed to add %s subdomain to parent %s\n",
@@ -570,11 +575,6 @@ static int scpsys_add_subdomain(struct scpsys *scpsys, struct device_node *paren
 			dev_dbg(scpsys->dev, "%s add subdomain: %s\n", parent_pd->name,
 				child_pd->name);
 		}
-
-		/* recursive call to add all subdomains */
-		ret = scpsys_add_subdomain(scpsys, child);
-		if (ret)
-			goto err_put_node;
 	}
 
 	return 0;
@@ -588,9 +588,6 @@ static void scpsys_remove_one_domain(struct scpsys_domain *pd)
 {
 	int ret;
 
-	if (scpsys_domain_is_on(pd))
-		scpsys_power_off(&pd->genpd);
-
 	/*
 	 * We're in the error cleanup already, so we only complain,
 	 * but won't emit another error on top of the original one.
@@ -600,6 +597,8 @@ static void scpsys_remove_one_domain(struct scpsys_domain *pd)
 		dev_err(pd->scpsys->dev,
 			"failed to remove domain '%s' : %d - state may be inconsistent\n",
 			pd->genpd.name, ret);
+	if (scpsys_domain_is_on(pd))
+		scpsys_power_off(&pd->genpd);
 
 	clk_bulk_put(pd->num_clks, pd->clks);
 	clk_bulk_put(pd->num_subsys_clks, pd->subsys_clks);
-- 
2.34.1



From ruipengqi7 at gmail.com  Mon Dec 25 05:51:53 2023
From: ruipengqi7 at gmail.com (Ruipeng Qi)
Date: Mon, 25 Dec 2023 21:51:53 +0800
Subject: RESEND: Re: [Patch v6 03/12] docs: qcom: Add qualcomm minidump guide
In-Reply-To: <in-reply-to=1700864395-1479-4-git-send-email-quic_mojha@quicinc.com>
References: <in-reply-to=1700864395-1479-4-git-send-email-quic_mojha@quicinc.com>
Message-ID: <20231225135153.1408-1-ruipengqi7@gmail.com>

<+How a kernel client driver can register region with minidump
<+------------------------------------------------------------
<+
<+Client driver can use ``qcom_minidump_region_register`` API's to register
<+and ``qcom_minidump_region_unregister`` to unregister their region from
<+minidump driver.
<+
<+Client needs to fill their region by filling ``qcom_minidump_region``
<+structure object which consists of the region name, region's virtual
<+and physical address and its size.

Hi, Mukesh, wish you a good holiday :)

I have the following idea, please help me to assess whether this can be
implemented or not. As we all know, most of the kernel objects are
allocated by the slab sub-system.I wonder if we can dump all memory
keeped by the slab sub-system? If so,  we got most of the kernel objects
which will be helpful to fix problems when we run with system issues.

How can we do this? From the description above, I think we should
register one region for each slab,  for each slab will have some pages,
and the memory between each slab is non-continuous. As we all
know, there are millions of slabs in the system, so if we dump slabs
in this way, it will introduce a heavy overhead.

I am not very familiar with qualcomm minidump, maybe my thought
is wrong. Looking forward to your reply!

Best Regards
Ruipeng


From ruipengqi7 at gmail.com  Mon Dec 25 05:55:42 2023
From: ruipengqi7 at gmail.com (Ruipeng Qi)
Date: Mon, 25 Dec 2023 21:55:42 +0800
Subject: RESEND: Re: [Patch v6 03/12] docs: qcom: Add qualcomm minidump guide
In-Reply-To: <1700864395-1479-4-git-send-email-quic_mojha@quicinc.com>
References: <1700864395-1479-4-git-send-email-quic_mojha@quicinc.com>
Message-ID: <20231225135542.1789-1-ruipengqi7@gmail.com>

<+How a kernel client driver can register region with minidump
<+------------------------------------------------------------
<+
<+Client driver can use ``qcom_minidump_region_register`` API's to register
<+and ``qcom_minidump_region_unregister`` to unregister their region from
<+minidump driver.
<+
<+Client needs to fill their region by filling ``qcom_minidump_region``
<+structure object which consists of the region name, region's virtual
<+and physical address and its size.

Hi, Mukesh, wish you a good holiday :)

I have the following idea, please help me to assess whether this can be
implemented or not. As we all know, most of the kernel objects are
allocated by the slab sub-system.I wonder if we can dump all memory
keeped by the slab sub-system? If so,  we got most of the kernel objects
which will be helpful to fix problems when we run with system issues.

How can we do this? From the description above, I think we should
register one region for each slab,  for each slab will have some pages,
and the memory between each slab is non-continuous. As we all
know, there are millions of slabs in the system, so if we dump slabs
in this way, it will introduce a heavy overhead.

I am not very familiar with qualcomm minidump, maybe my thought
is wrong. Looking forward to your reply!

Best Regards
Ruipeng


From islituo at gmail.com  Mon Dec 25 06:57:23 2023
From: islituo at gmail.com (Li Tuo)
Date: Mon, 25 Dec 2023 22:57:23 +0800
Subject: [PATCH] media:fimc-capture: Fix a possible data inconsistency due
 to a data race in fimc_subdev_set_fmt()
In-Reply-To: <93da765f-44c8-4023-b416-eae617d5ed74@linaro.org>
References: <20231223164351.3521588-1-islituo@gmail.com>
 <93da765f-44c8-4023-b416-eae617d5ed74@linaro.org>
Message-ID: <0edbd57a-cf94-4710-a20c-04d0cc43cfad@gmail.com>

Hi Krzysztof,

Thanks for your reply very much. It is very helpful.
I am really sorry to confuse you.

On 2023/12/24 18:11, Krzysztof Kozlowski wrote:

> On 23/12/2023 17:43, Tuo Li wrote:
>> Accesses to ctx->s_frame.width and ctx->s_frame.height should be protected
>> by the lock fimc->lock to guarantee that width and height are consistent.
>> Here is an example in fimc_subdev_get_fmt():
>>
>>    struct fimc_frame *ff = &ctx->s_frame; // Alias
>>    mutex_lock(&fimc->lock);
>>    mf->width = ff->width;
>>    mf->height = ff->height;
>>
>> However, ctx->s_frame.width and ctx->s_frame.height are accessed without
>> holding the lock fimc->lock in fimc_subdev_set_fmt():
>>
>>    mf->width = ctx->s_frame.width;
>>    mf->height = ctx->s_frame.height;
> Other places setting parts of s_frame, like fimc_capture_try_format() or
> fimc_capture_try_selection(), do not have mutex.
>
>> And thus a harmful data race can occur, which can make ctx->s_frame.width
> Harmful how?

The function set_frame_crop() which updates s_frame.width and
s_frame.height is called by fimc_cap_s_selection(). fimc_cap_s_selection()
is an ioctl function and it is likely to be able to execute concurrently
with other functions such as fimc_subdev_set_fmt(). However, in
fimc_subdev_set_fmt(), the accesses to s_frame.width and s_frame.height are
not protected by the mutex lock fimc->lock.

If fimc_cap_s_selection() and fimc_subdev_set_fmt() can execute
concurrently and the execution orders is like this:

1. ctx->s_frame.width is accessed and assigned to mf->width in
    fimc_subdev_set_fmt()      Line 1552 in fimc-capture.c
2. ctx->s_frame.width and ctx->s_frame.height is updated by
    fimc_cap_s_selection()     Line 1329 in fimc-capture.c
3. ctx->s_frame.height is accessed and assigned to mf->height in
    fimc_subdev_set_fmt()      Line 1553 in fimc-capture.c

The width and height assigned to mf are not coming from the same
ctx->s_frame configuration and can cause data inconsistency.

Besides, the functions fimc_subdev_set_selection() and
fimc_subdev_set_fmt() exist in the same driver interface named
fimc_subdev_pad_ops. Therefore, it seems that fimc_subdev_set_fmt() and
fimc_subdev_set_selection() can also execute concurrently. However, if the
execution order of fimc_subdev_set_selection() and fimc_subdev_set_fmt() is
like mentioned above, a data inconsistency can also occur.

I analyze this possible data race manually according to the code logic, and
I am not sure whether all accesses to configurations such as width, height,
f_width, and f_height should be protected by a mutex lock to make them
consistent. I am really sorry to trouble you, and any feedback will be
appreciated!

>> inconsistent with ctx->s_frame.height, if ctx->s_frame.height is updated
>> right after ctx->s_frame.width is accessed by another thread.
>>
>> This possible bug is found by an experimental static analysis tool
>> developed by our team, BassCheck[1]. This tool analyzes the locking APIs
>> to extract function pairs that can be concurrently executed, and then
>> analyzes the instructions in the paired functions to identify possible
>> concurrency bugs including data races and atomicity violations. The above
>> possible bug is reported when our tool analyzes the source code of
>> Linux 6.2.
>>
>> To fix this possible data race, the lock operation mutex_lock(&fimc->lock)
>> is moved to the front of the accesses to these two variables. With this
>> patch applied, our tool no longer reports the bug, with the kernel
>> configuration allyesconfig for x86_64. Due to the lack of associated
>> hardware, we cannot test the patch in runtime testing, and just verify it
>> according to the code logic.
> You wrote long four paragraphs which have basically almost zero relevant
> information, whether this locking is needed or not. Your bass
> description is not relevant... or actually making things worse because I
> am certain you are fixing it just to fix your report, not to fix real issue.
>
>> [1] https://sites.google.com/view/basscheck/
> Instead provide the report.

I am sorry to confuse you, and I wrote these descriptions according to
researcher guidelines in the kernel documentation
Documentation/process/researcher-guidelines.rst
I will provide a more concise patch in the future.

>> Fixes: 88fa8311ee36 ("[media] s5p-fimc: Add support for ISP Writeback ...")
>> Signed-off-by: Tuo Li <islituo at gmail.com>
>> Cc: stable at vger.kernel.org
>> Reported-by: BassCheck <bass at buaa.edu.cn>
> Run checkpatch, you will see the warning.

Thanks for your advice. I am sorry to bother you, and I will be careful in
the subsequent patches.

> Best regards,
> Krzysztof
>
Sincerely,
Tuo Li



From bogus@does.not.exist.com  Mon Dec 25 07:28:04 2023
From: bogus@does.not.exist.com ()
Date: Mon, 25 Dec 2023 20:58:04 +0530
Subject: [PATCH] clk: mediatek: fix cppcheck error for uninitialized variable
Message-ID: <20231225152806.3716898-1-user@falcon>

From: Kishan Dudhatra <kishan.dudhatra at siliconsignals.io>

cppcheck reports below warning

clk/mediatek/clk-fhctl.c:206:27:
error: Uninitialized variable: pll_postdiv [uninitvar]
if (postdiv && postdiv < pll_postdiv)

This is due to uninitialization of variable pll_postdiv,
which is now initialized as part of this patch.

Signed-off-by: Kishan Dudhatra <kishan.dudhatra at siliconsignals.io>

diff --git a/drivers/clk/mediatek/clk-fhctl.c b/drivers/clk/mediatek/clk-fhctl.c
index 33b6ad8fdc2e..b0e71e4fd938 100644
--- a/drivers/clk/mediatek/clk-fhctl.c
+++ b/drivers/clk/mediatek/clk-fhctl.c
@@ -186,7 +186,7 @@ static int fhctl_hopping(struct mtk_fh *fh, unsigned int new_dds,
 	struct fh_pll_regs *regs = &fh->regs;
 	struct mtk_clk_pll *pll = &fh->clk_pll;
 	spinlock_t *lock = fh->lock;
-	unsigned int pll_postdiv;
+	unsigned int pll_postdiv = 0;
 	unsigned long flags = 0;
 	int ret;
 
-- 
2.25.1



From krzysztof.kozlowski at linaro.org  Mon Dec 25 11:05:55 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 25 Dec 2023 20:05:55 +0100
Subject: [PATCH v6 09/16] dt-bindings: imx6q-pcie: Clean up irrationality
 clocks check
In-Reply-To: <20231224183242.1675372-10-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
 <20231224183242.1675372-10-Frank.Li@nxp.com>
Message-ID: <63d93850-e88b-4311-accb-e7fa9a89d44f@linaro.org>

On 24/12/2023 19:32, Frank Li wrote:
> There are clocks and clock-names restriction for difference compatible
> string. So needn't irrationality check again for clock's miniItems and
> maxItems.
> 
> In fsl,imx6q-pcie-ep.yaml

It is enough to say that bindings referencing this file already define
these constraints for each of the variants, so the if:else: is redundant.

Two lines instead of ~20.

> 	...
> 
> Acked-by: Rob Herring <robh at kernel.org>

How did you get it? Please point me to the lore link. This patch
appeared in v5 and there was no response from Rob, AFAIK.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 25 11:09:51 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 25 Dec 2023 20:09:51 +0100
Subject: [PATCH v6 09/16] dt-bindings: imx6q-pcie: Clean up irrationality
 clocks check
In-Reply-To: <63d93850-e88b-4311-accb-e7fa9a89d44f@linaro.org>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
 <20231224183242.1675372-10-Frank.Li@nxp.com>
 <63d93850-e88b-4311-accb-e7fa9a89d44f@linaro.org>
Message-ID: <cf5fd42f-6ca8-4109-a314-3ede9810a5ed@linaro.org>

On 25/12/2023 20:05, Krzysztof Kozlowski wrote:
> On 24/12/2023 19:32, Frank Li wrote:
>> There are clocks and clock-names restriction for difference compatible
>> string. So needn't irrationality check again for clock's miniItems and
>> maxItems.
>>
>> In fsl,imx6q-pcie-ep.yaml
> 
> It is enough to say that bindings referencing this file already define
> these constraints for each of the variants, so the if:else: is redundant.
> 
> Two lines instead of ~20.
> 
>> 	...
>>
>> Acked-by: Rob Herring <robh at kernel.org>
> 
> How did you get it? Please point me to the lore link. This patch
> appeared in v5 and there was no response from Rob, AFAIK.

Ah, this patch was added at v4 and Rob acked that one. It's fine then,
but you still could narrow the commit msg, if there is going to be a
resend. Please write informative but concise messages.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 25 11:11:40 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 25 Dec 2023 20:11:40 +0100
Subject: [PATCH v6 10/16] dt-bindings: imx6q-pcie: restruct reg and
 reg-name
In-Reply-To: <20231224183242.1675372-11-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
 <20231224183242.1675372-11-Frank.Li@nxp.com>
Message-ID: <5cfa370d-4d56-42f8-9ee6-4c0c2943fc60@linaro.org>

On 24/12/2023 19:32, Frank Li wrote:
> snps,dw-pcie.yaml already have reg and reg-name information. Needn't
> duplciate here.
> 
> Add 'if' check for existed compatible string to restrict reg and reg-names.
> This prepare to add new compatible string with difference reg-names sets.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 25 11:13:34 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 25 Dec 2023 20:13:34 +0100
Subject: [PATCH v6 11/16] dt-bindings: imx6q-pcie: Add imx95 pcie
 compatible string
In-Reply-To: <20231224183242.1675372-12-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
 <20231224183242.1675372-12-Frank.Li@nxp.com>
Message-ID: <c1fb5806-22b4-4c99-8718-66767bd641d8@linaro.org>

On 24/12/2023 19:32, Frank Li wrote:
> From: Richard Zhu <hongxing.zhu at nxp.com>
> 
> Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
> Add "atu" and "app" to reg-names.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>

Where is your SoB?

I wanted to add Rb tag... but again this is still wrong. Please read the
DCO and submitting patches.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Mon Dec 25 11:16:17 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Mon, 25 Dec 2023 20:16:17 +0100
Subject: [PATCH v6 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint
 compatible string
In-Reply-To: <20231224183242.1675372-16-Frank.Li@nxp.com>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
 <20231224183242.1675372-16-Frank.Li@nxp.com>
Message-ID: <6a61f325-a58b-4aa6-9a0a-7a3086f63829@linaro.org>

On 24/12/2023 19:32, Frank Li wrote:
> Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
> Add reg-name: "atu", "dbi2", "dma" and "app".
> Reuse PCI linux,pci-domain as controller id at endpoint.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> 

...

> +# reuse PCI linux,pci-domain as controller id at Endpoint
> +  - if:
> +      properties:
> +        compatible:
> +          enum:
> +            - fsl,imx95-pcie-ep
> +    then:
> +      properties:
> +        linux,pci-domain: true

Same comment: why do you need? Don't ignore my feedback. You responded
you will fix it, but it is still here...

Best regards,
Krzysztof



From inindev at gmail.com  Mon Dec 25 14:28:19 2023
From: inindev at gmail.com (John Clark)
Date: Mon, 25 Dec 2023 22:28:19 +0000
Subject: [PATCH v2 1/2] arm64: dts: rockchip: support poweroff on the rock-5b
Message-ID: <20231225222859.17153-1-inindev@gmail.com>

Allow the rock-5b to poweroff its pmic. When issuing a "shutdown -h now"
on the rock-5b it reboots instead. Defining 'system-power-controller'
allows the rk806 to power down.

Commit c699fbfdfd54 ("arm64: dts: rockchip: Support poweroff on
NanoPC-T6") similarly resolves this issue for the nanopc-t6.

Signed-off-by: John Clark <inindev at gmail.com>
---
Changes since v1:
 - added commit message with additional patch detail
 - expressed the related commit using checkpatch

---
 arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
index 74719aaf697c..dc7b88f29172 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
@@ -426,6 +426,8 @@ pmic at 0 {
 		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
 			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
 
+		system-power-controller;
+
 		vcc1-supply = <&vcc5v0_sys>;
 		vcc2-supply = <&vcc5v0_sys>;
 		vcc3-supply = <&vcc5v0_sys>;
-- 
2.43.0



From inindev at gmail.com  Mon Dec 25 14:28:20 2023
From: inindev at gmail.com (John Clark)
Date: Mon, 25 Dec 2023 22:28:20 +0000
Subject: [PATCH v2 2/2] arm64: dts: rockchip: correct gpio_pwrctrl1 typo
In-Reply-To: <20231225222859.17153-1-inindev@gmail.com>
References: <20231225222859.17153-1-inindev@gmail.com>
Message-ID: <20231225222859.17153-2-inindev@gmail.com>

Both rk806_dvs1_null and rk806_dvs2_null duplicate gpio_pwrctrl2 and
gpio_pwrctrl1 is not set. This patch sets gpio_pwrctrl1.

Signed-off-by: John Clark <inindev at gmail.com>
---
Changes since v1:
 - added commit message with additional patch detail

---
 arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
index dc7b88f29172..a0e303c3a1dc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
@@ -448,7 +448,7 @@ pmic at 0 {
 		#gpio-cells = <2>;
 
 		rk806_dvs1_null: dvs1-null-pins {
-			pins = "gpio_pwrctrl2";
+			pins = "gpio_pwrctrl1";
 			function = "pin_fun0";
 		};
 
-- 
2.43.0



From inindev at gmail.com  Mon Dec 25 14:32:16 2023
From: inindev at gmail.com (John Clark)
Date: Mon, 25 Dec 2023 22:32:16 +0000
Subject: [PATCH v2] arm64: dts: rockchip: correct gpio_pwrctrl1 typo
Message-ID: <20231225223226.17690-1-inindev@gmail.com>

Both rk806_dvs1_null and rk806_dvs2_null duplicate gpio_pwrctrl2 and
gpio_pwrctrl1 is not set. This patch sets gpio_pwrctrl1.

Signed-off-by: John Clark <inindev at gmail.com>
---
Changes since v1:
 - added commit message with additional patch detail

---
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
index 0fc48fb0d34d..e83b71510a47 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
@@ -591,7 +591,7 @@ pmic at 0 {
 		#gpio-cells = <2>;
 
 		rk806_dvs1_null: dvs1-null-pins {
-			pins = "gpio_pwrctrl2";
+			pins = "gpio_pwrctrl1";
 			function = "pin_fun0";
 		};
 
-- 
2.43.0



From sashal at kernel.org  Mon Dec 25 16:19:21 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 25 Dec 2023 19:19:21 -0500
Subject: [PATCH AUTOSEL 6.6 31/39] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <20231226002021.4776-1-sashal@kernel.org>
References: <20231226002021.4776-1-sashal@kernel.org>
Message-ID: <20231226002021.4776-31-sashal@kernel.org>

From: Jensen Huang <jensenhuang at friendlyarm.com>

[ Upstream commit 19cde9c92b8d3b7ee555d0da3bcb0232d3a784f4 ]

Possible deadlock scenario (on reboot):
rk3x_i2c_xfer_common(polling)
    -> rk3x_i2c_wait_xfer_poll()
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock);
            ...
        <rk3x i2c interrupt>
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock); (deadlock here)

Store the IRQ number and disable/enable it around the polling transfer.
This patch has been tested on NanoPC-T4.

Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
Signed-off-by: Wolfram Sang <wsa at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/i2c/busses/i2c-rk3x.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index a044ca0c35a19..4362db7c57892 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -178,6 +178,7 @@ struct rk3x_i2c_soc_data {
  * @clk: function clk for rk3399 or function & Bus clks for others
  * @pclk: Bus clk for rk3399
  * @clk_rate_nb: i2c clk rate change notify
+ * @irq: irq number
  * @t: I2C known timing information
  * @lock: spinlock for the i2c bus
  * @wait: the waitqueue to wait for i2c transfer
@@ -200,6 +201,7 @@ struct rk3x_i2c {
 	struct clk *clk;
 	struct clk *pclk;
 	struct notifier_block clk_rate_nb;
+	int irq;
 
 	/* Settings */
 	struct i2c_timings t;
@@ -1087,13 +1089,18 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
 
 		spin_unlock_irqrestore(&i2c->lock, flags);
 
-		rk3x_i2c_start(i2c);
-
 		if (!polling) {
+			rk3x_i2c_start(i2c);
+
 			timeout = wait_event_timeout(i2c->wait, !i2c->busy,
 						     msecs_to_jiffies(WAIT_TIMEOUT));
 		} else {
+			disable_irq(i2c->irq);
+			rk3x_i2c_start(i2c);
+
 			timeout = rk3x_i2c_wait_xfer_poll(i2c);
+
+			enable_irq(i2c->irq);
 		}
 
 		spin_lock_irqsave(&i2c->lock, flags);
@@ -1310,6 +1317,8 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	i2c->irq = irq;
+
 	platform_set_drvdata(pdev, i2c);
 
 	if (i2c->soc_data->calc_timings == rk3x_i2c_v0_calc_timings) {
-- 
2.43.0



From sashal at kernel.org  Mon Dec 25 16:19:28 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 25 Dec 2023 19:19:28 -0500
Subject: [PATCH AUTOSEL 6.6 38/39] posix-timers: Get rid of [COMPAT_]SYS_NI() uses
In-Reply-To: <20231226002021.4776-1-sashal@kernel.org>
References: <20231226002021.4776-1-sashal@kernel.org>
Message-ID: <20231226002021.4776-38-sashal@kernel.org>

From: Linus Torvalds <torvalds at linux-foundation.org>

[ Upstream commit a4aebe936554dac6a91e5d091179c934f8325708 ]

Only the posix timer system calls use this (when the posix timer support
is disabled, which does not actually happen in any normal case), because
they had debug code to print out a warning about missing system calls.

Get rid of that special case, and just use the standard COND_SYSCALL
interface that creates weak system call stubs that return -ENOSYS for
when the system call does not exist.

This fixes a kCFI issue with the SYS_NI() hackery:

  CFI failure at int80_emulation+0x67/0xb0 (target: sys_ni_posix_timers+0x0/0x70; expected type: 0xb02b34d9)
  WARNING: CPU: 0 PID: 48 at int80_emulation+0x67/0xb0

Reported-by: kernel test robot <oliver.sang at intel.com>
Reviewed-by: Sami Tolvanen <samitolvanen at google.com>
Tested-by: Sami Tolvanen <samitolvanen at google.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Dave Hansen <dave.hansen at linux.intel.com>
Cc: Borislav Petkov <bp at alien8.de>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/include/asm/syscall_wrapper.h |  4 ---
 arch/riscv/include/asm/syscall_wrapper.h |  5 ---
 arch/s390/include/asm/syscall_wrapper.h  | 13 +------
 arch/x86/include/asm/syscall_wrapper.h   | 34 +++---------------
 kernel/sys_ni.c                          | 14 ++++++++
 kernel/time/posix-stubs.c                | 45 ------------------------
 6 files changed, 19 insertions(+), 96 deletions(-)

diff --git a/arch/arm64/include/asm/syscall_wrapper.h b/arch/arm64/include/asm/syscall_wrapper.h
index 17f687510c485..7a0e7b59be9b9 100644
--- a/arch/arm64/include/asm/syscall_wrapper.h
+++ b/arch/arm64/include/asm/syscall_wrapper.h
@@ -44,9 +44,6 @@
 		return sys_ni_syscall();						\
 	}
 
-#define COMPAT_SYS_NI(name) \
-	SYSCALL_ALIAS(__arm64_compat_sys_##name, sys_ni_posix_timers);
-
 #endif /* CONFIG_COMPAT */
 
 #define __SYSCALL_DEFINEx(x, name, ...)						\
@@ -82,6 +79,5 @@
 	}
 
 asmlinkage long __arm64_sys_ni_syscall(const struct pt_regs *__unused);
-#define SYS_NI(name) SYSCALL_ALIAS(__arm64_sys_##name, sys_ni_posix_timers);
 
 #endif /* __ASM_SYSCALL_WRAPPER_H */
diff --git a/arch/riscv/include/asm/syscall_wrapper.h b/arch/riscv/include/asm/syscall_wrapper.h
index 1d7942c8a6cba..eeec04b7dae67 100644
--- a/arch/riscv/include/asm/syscall_wrapper.h
+++ b/arch/riscv/include/asm/syscall_wrapper.h
@@ -46,9 +46,6 @@ asmlinkage long __riscv_sys_ni_syscall(const struct pt_regs *);
 		return sys_ni_syscall();						\
 	}
 
-#define COMPAT_SYS_NI(name) \
-	SYSCALL_ALIAS(__riscv_compat_sys_##name, sys_ni_posix_timers);
-
 #endif /* CONFIG_COMPAT */
 
 #define __SYSCALL_DEFINEx(x, name, ...)						\
@@ -82,6 +79,4 @@ asmlinkage long __riscv_sys_ni_syscall(const struct pt_regs *);
 		return sys_ni_syscall();					\
 	}
 
-#define SYS_NI(name) SYSCALL_ALIAS(__riscv_sys_##name, sys_ni_posix_timers);
-
 #endif /* __ASM_SYSCALL_WRAPPER_H */
diff --git a/arch/s390/include/asm/syscall_wrapper.h b/arch/s390/include/asm/syscall_wrapper.h
index 9286430fe7290..35c1d1b860d88 100644
--- a/arch/s390/include/asm/syscall_wrapper.h
+++ b/arch/s390/include/asm/syscall_wrapper.h
@@ -63,10 +63,6 @@
 	cond_syscall(__s390x_sys_##name);				\
 	cond_syscall(__s390_sys_##name)
 
-#define SYS_NI(name)							\
-	SYSCALL_ALIAS(__s390x_sys_##name, sys_ni_posix_timers);		\
-	SYSCALL_ALIAS(__s390_sys_##name, sys_ni_posix_timers)
-
 #define COMPAT_SYSCALL_DEFINEx(x, name, ...)						\
 	long __s390_compat_sys##name(struct pt_regs *regs);				\
 	ALLOW_ERROR_INJECTION(__s390_compat_sys##name, ERRNO);				\
@@ -85,15 +81,11 @@
 
 /*
  * As some compat syscalls may not be implemented, we need to expand
- * COND_SYSCALL_COMPAT in kernel/sys_ni.c and COMPAT_SYS_NI in
- * kernel/time/posix-stubs.c to cover this case as well.
+ * COND_SYSCALL_COMPAT in kernel/sys_ni.c to cover this case as well.
  */
 #define COND_SYSCALL_COMPAT(name)					\
 	cond_syscall(__s390_compat_sys_##name)
 
-#define COMPAT_SYS_NI(name)						\
-	SYSCALL_ALIAS(__s390_compat_sys_##name, sys_ni_posix_timers)
-
 #define __S390_SYS_STUBx(x, name, ...)						\
 	long __s390_sys##name(struct pt_regs *regs);				\
 	ALLOW_ERROR_INJECTION(__s390_sys##name, ERRNO);				\
@@ -124,9 +116,6 @@
 #define COND_SYSCALL(name)						\
 	cond_syscall(__s390x_sys_##name)
 
-#define SYS_NI(name)							\
-	SYSCALL_ALIAS(__s390x_sys_##name, sys_ni_posix_timers)
-
 #define __S390_SYS_STUBx(x, fullname, name, ...)
 
 #endif /* CONFIG_COMPAT */
diff --git a/arch/x86/include/asm/syscall_wrapper.h b/arch/x86/include/asm/syscall_wrapper.h
index fd2669b1cb2d9..21f9407be5d35 100644
--- a/arch/x86/include/asm/syscall_wrapper.h
+++ b/arch/x86/include/asm/syscall_wrapper.h
@@ -86,9 +86,6 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
 		return sys_ni_syscall();				\
 	}
 
-#define __SYS_NI(abi, name)						\
-	SYSCALL_ALIAS(__##abi##_##name, sys_ni_posix_timers);
-
 #ifdef CONFIG_X86_64
 #define __X64_SYS_STUB0(name)						\
 	__SYS_STUB0(x64, sys_##name)
@@ -100,13 +97,10 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
 #define __X64_COND_SYSCALL(name)					\
 	__COND_SYSCALL(x64, sys_##name)
 
-#define __X64_SYS_NI(name)						\
-	__SYS_NI(x64, sys_##name)
 #else /* CONFIG_X86_64 */
 #define __X64_SYS_STUB0(name)
 #define __X64_SYS_STUBx(x, name, ...)
 #define __X64_COND_SYSCALL(name)
-#define __X64_SYS_NI(name)
 #endif /* CONFIG_X86_64 */
 
 #if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
@@ -120,13 +114,10 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
 #define __IA32_COND_SYSCALL(name)					\
 	__COND_SYSCALL(ia32, sys_##name)
 
-#define __IA32_SYS_NI(name)						\
-	__SYS_NI(ia32, sys_##name)
 #else /* CONFIG_X86_32 || CONFIG_IA32_EMULATION */
 #define __IA32_SYS_STUB0(name)
 #define __IA32_SYS_STUBx(x, name, ...)
 #define __IA32_COND_SYSCALL(name)
-#define __IA32_SYS_NI(name)
 #endif /* CONFIG_X86_32 || CONFIG_IA32_EMULATION */
 
 #ifdef CONFIG_IA32_EMULATION
@@ -135,8 +126,7 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
  * additional wrappers (aptly named __ia32_sys_xyzzy) which decode the
  * ia32 regs in the proper order for shared or "common" syscalls. As some
  * syscalls may not be implemented, we need to expand COND_SYSCALL in
- * kernel/sys_ni.c and SYS_NI in kernel/time/posix-stubs.c to cover this
- * case as well.
+ * kernel/sys_ni.c to cover this case as well.
  */
 #define __IA32_COMPAT_SYS_STUB0(name)					\
 	__SYS_STUB0(ia32, compat_sys_##name)
@@ -148,14 +138,10 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
 #define __IA32_COMPAT_COND_SYSCALL(name)				\
 	__COND_SYSCALL(ia32, compat_sys_##name)
 
-#define __IA32_COMPAT_SYS_NI(name)					\
-	__SYS_NI(ia32, compat_sys_##name)
-
 #else /* CONFIG_IA32_EMULATION */
 #define __IA32_COMPAT_SYS_STUB0(name)
 #define __IA32_COMPAT_SYS_STUBx(x, name, ...)
 #define __IA32_COMPAT_COND_SYSCALL(name)
-#define __IA32_COMPAT_SYS_NI(name)
 #endif /* CONFIG_IA32_EMULATION */
 
 
@@ -175,13 +161,10 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
 #define __X32_COMPAT_COND_SYSCALL(name)					\
 	__COND_SYSCALL(x64, compat_sys_##name)
 
-#define __X32_COMPAT_SYS_NI(name)					\
-	__SYS_NI(x64, compat_sys_##name)
 #else /* CONFIG_X86_X32_ABI */
 #define __X32_COMPAT_SYS_STUB0(name)
 #define __X32_COMPAT_SYS_STUBx(x, name, ...)
 #define __X32_COMPAT_COND_SYSCALL(name)
-#define __X32_COMPAT_SYS_NI(name)
 #endif /* CONFIG_X86_X32_ABI */
 
 
@@ -212,17 +195,12 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
 
 /*
  * As some compat syscalls may not be implemented, we need to expand
- * COND_SYSCALL_COMPAT in kernel/sys_ni.c and COMPAT_SYS_NI in
- * kernel/time/posix-stubs.c to cover this case as well.
+ * COND_SYSCALL_COMPAT in kernel/sys_ni.c to cover this case as well.
  */
 #define COND_SYSCALL_COMPAT(name) 					\
 	__IA32_COMPAT_COND_SYSCALL(name)				\
 	__X32_COMPAT_COND_SYSCALL(name)
 
-#define COMPAT_SYS_NI(name)						\
-	__IA32_COMPAT_SYS_NI(name)					\
-	__X32_COMPAT_SYS_NI(name)
-
 #endif /* CONFIG_COMPAT */
 
 #define __SYSCALL_DEFINEx(x, name, ...)					\
@@ -243,8 +221,8 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
  * As the generic SYSCALL_DEFINE0() macro does not decode any parameters for
  * obvious reasons, and passing struct pt_regs *regs to it in %rdi does not
  * hurt, we only need to re-define it here to keep the naming congruent to
- * SYSCALL_DEFINEx() -- which is essential for the COND_SYSCALL() and SYS_NI()
- * macros to work correctly.
+ * SYSCALL_DEFINEx() -- which is essential for the COND_SYSCALL() macro
+ * to work correctly.
  */
 #define SYSCALL_DEFINE0(sname)						\
 	SYSCALL_METADATA(_##sname, 0);					\
@@ -257,10 +235,6 @@ extern long __ia32_sys_ni_syscall(const struct pt_regs *regs);
 	__X64_COND_SYSCALL(name)					\
 	__IA32_COND_SYSCALL(name)
 
-#define SYS_NI(name)							\
-	__X64_SYS_NI(name)						\
-	__IA32_SYS_NI(name)
-
 
 /*
  * For VSYSCALLS, we need to declare these three syscalls with the new
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index e137c1385c569..11c55593a2e91 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -200,6 +200,20 @@ COND_SYSCALL(recvmmsg_time32);
 COND_SYSCALL_COMPAT(recvmmsg_time32);
 COND_SYSCALL_COMPAT(recvmmsg_time64);
 
+/* Posix timer syscalls may be configured out */
+COND_SYSCALL(timer_create);
+COND_SYSCALL(timer_gettime);
+COND_SYSCALL(timer_getoverrun);
+COND_SYSCALL(timer_settime);
+COND_SYSCALL(timer_delete);
+COND_SYSCALL(clock_adjtime);
+COND_SYSCALL(getitimer);
+COND_SYSCALL(setitimer);
+COND_SYSCALL(alarm);
+COND_SYSCALL_COMPAT(timer_create);
+COND_SYSCALL_COMPAT(getitimer);
+COND_SYSCALL_COMPAT(setitimer);
+
 /*
  * Architecture specific syscalls: see further below
  */
diff --git a/kernel/time/posix-stubs.c b/kernel/time/posix-stubs.c
index 828aeecbd1e8a..9b6fcb8d85e78 100644
--- a/kernel/time/posix-stubs.c
+++ b/kernel/time/posix-stubs.c
@@ -17,40 +17,6 @@
 #include <linux/time_namespace.h>
 #include <linux/compat.h>
 
-#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
-/* Architectures may override SYS_NI and COMPAT_SYS_NI */
-#include <asm/syscall_wrapper.h>
-#endif
-
-asmlinkage long sys_ni_posix_timers(void)
-{
-	pr_err_once("process %d (%s) attempted a POSIX timer syscall "
-		    "while CONFIG_POSIX_TIMERS is not set\n",
-		    current->pid, current->comm);
-	return -ENOSYS;
-}
-
-#ifndef SYS_NI
-#define SYS_NI(name)  SYSCALL_ALIAS(sys_##name, sys_ni_posix_timers)
-#endif
-
-#ifndef COMPAT_SYS_NI
-#define COMPAT_SYS_NI(name)  SYSCALL_ALIAS(compat_sys_##name, sys_ni_posix_timers)
-#endif
-
-SYS_NI(timer_create);
-SYS_NI(timer_gettime);
-SYS_NI(timer_getoverrun);
-SYS_NI(timer_settime);
-SYS_NI(timer_delete);
-SYS_NI(clock_adjtime);
-SYS_NI(getitimer);
-SYS_NI(setitimer);
-SYS_NI(clock_adjtime32);
-#ifdef __ARCH_WANT_SYS_ALARM
-SYS_NI(alarm);
-#endif
-
 /*
  * We preserve minimal support for CLOCK_REALTIME and CLOCK_MONOTONIC
  * as it is easy to remain compatible with little code. CLOCK_BOOTTIME
@@ -158,18 +124,7 @@ SYSCALL_DEFINE4(clock_nanosleep, const clockid_t, which_clock, int, flags,
 				 which_clock);
 }
 
-#ifdef CONFIG_COMPAT
-COMPAT_SYS_NI(timer_create);
-#endif
-
-#if defined(CONFIG_COMPAT) || defined(CONFIG_ALPHA)
-COMPAT_SYS_NI(getitimer);
-COMPAT_SYS_NI(setitimer);
-#endif
-
 #ifdef CONFIG_COMPAT_32BIT_TIME
-SYS_NI(timer_settime32);
-SYS_NI(timer_gettime32);
 
 SYSCALL_DEFINE2(clock_settime32, const clockid_t, which_clock,
 		struct old_timespec32 __user *, tp)
-- 
2.43.0



From sashal at kernel.org  Mon Dec 25 16:22:12 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 25 Dec 2023 19:22:12 -0500
Subject: [PATCH AUTOSEL 6.1 19/24] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <20231226002255.5730-1-sashal@kernel.org>
References: <20231226002255.5730-1-sashal@kernel.org>
Message-ID: <20231226002255.5730-19-sashal@kernel.org>

From: Jensen Huang <jensenhuang at friendlyarm.com>

[ Upstream commit 19cde9c92b8d3b7ee555d0da3bcb0232d3a784f4 ]

Possible deadlock scenario (on reboot):
rk3x_i2c_xfer_common(polling)
    -> rk3x_i2c_wait_xfer_poll()
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock);
            ...
        <rk3x i2c interrupt>
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock); (deadlock here)

Store the IRQ number and disable/enable it around the polling transfer.
This patch has been tested on NanoPC-T4.

Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
Signed-off-by: Wolfram Sang <wsa at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/i2c/busses/i2c-rk3x.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index b31cf4f18f854..6aa4f1f062401 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -178,6 +178,7 @@ struct rk3x_i2c_soc_data {
  * @clk: function clk for rk3399 or function & Bus clks for others
  * @pclk: Bus clk for rk3399
  * @clk_rate_nb: i2c clk rate change notify
+ * @irq: irq number
  * @t: I2C known timing information
  * @lock: spinlock for the i2c bus
  * @wait: the waitqueue to wait for i2c transfer
@@ -200,6 +201,7 @@ struct rk3x_i2c {
 	struct clk *clk;
 	struct clk *pclk;
 	struct notifier_block clk_rate_nb;
+	int irq;
 
 	/* Settings */
 	struct i2c_timings t;
@@ -1087,13 +1089,18 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
 
 		spin_unlock_irqrestore(&i2c->lock, flags);
 
-		rk3x_i2c_start(i2c);
-
 		if (!polling) {
+			rk3x_i2c_start(i2c);
+
 			timeout = wait_event_timeout(i2c->wait, !i2c->busy,
 						     msecs_to_jiffies(WAIT_TIMEOUT));
 		} else {
+			disable_irq(i2c->irq);
+			rk3x_i2c_start(i2c);
+
 			timeout = rk3x_i2c_wait_xfer_poll(i2c);
+
+			enable_irq(i2c->irq);
 		}
 
 		spin_lock_irqsave(&i2c->lock, flags);
@@ -1310,6 +1317,8 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	i2c->irq = irq;
+
 	platform_set_drvdata(pdev, i2c);
 
 	if (i2c->soc_data->calc_timings == rk3x_i2c_v0_calc_timings) {
-- 
2.43.0



From sashal at kernel.org  Mon Dec 25 16:23:59 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 25 Dec 2023 19:23:59 -0500
Subject: [PATCH AUTOSEL 5.15 10/11] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <20231226002420.6303-1-sashal@kernel.org>
References: <20231226002420.6303-1-sashal@kernel.org>
Message-ID: <20231226002420.6303-10-sashal@kernel.org>

From: Jensen Huang <jensenhuang at friendlyarm.com>

[ Upstream commit 19cde9c92b8d3b7ee555d0da3bcb0232d3a784f4 ]

Possible deadlock scenario (on reboot):
rk3x_i2c_xfer_common(polling)
    -> rk3x_i2c_wait_xfer_poll()
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock);
            ...
        <rk3x i2c interrupt>
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock); (deadlock here)

Store the IRQ number and disable/enable it around the polling transfer.
This patch has been tested on NanoPC-T4.

Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
Signed-off-by: Wolfram Sang <wsa at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/i2c/busses/i2c-rk3x.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 13c14eb175e94..6abcf975a2db9 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -178,6 +178,7 @@ struct rk3x_i2c_soc_data {
  * @clk: function clk for rk3399 or function & Bus clks for others
  * @pclk: Bus clk for rk3399
  * @clk_rate_nb: i2c clk rate change notify
+ * @irq: irq number
  * @t: I2C known timing information
  * @lock: spinlock for the i2c bus
  * @wait: the waitqueue to wait for i2c transfer
@@ -200,6 +201,7 @@ struct rk3x_i2c {
 	struct clk *clk;
 	struct clk *pclk;
 	struct notifier_block clk_rate_nb;
+	int irq;
 
 	/* Settings */
 	struct i2c_timings t;
@@ -1087,13 +1089,18 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
 
 		spin_unlock_irqrestore(&i2c->lock, flags);
 
-		rk3x_i2c_start(i2c);
-
 		if (!polling) {
+			rk3x_i2c_start(i2c);
+
 			timeout = wait_event_timeout(i2c->wait, !i2c->busy,
 						     msecs_to_jiffies(WAIT_TIMEOUT));
 		} else {
+			disable_irq(i2c->irq);
+			rk3x_i2c_start(i2c);
+
 			timeout = rk3x_i2c_wait_xfer_poll(i2c);
+
+			enable_irq(i2c->irq);
 		}
 
 		spin_lock_irqsave(&i2c->lock, flags);
@@ -1301,6 +1308,8 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	i2c->irq = irq;
+
 	platform_set_drvdata(pdev, i2c);
 
 	if (i2c->soc_data->calc_timings == rk3x_i2c_v0_calc_timings) {
-- 
2.43.0



From sashal at kernel.org  Mon Dec 25 16:24:52 2023
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 25 Dec 2023 19:24:52 -0500
Subject: [PATCH AUTOSEL 5.10 8/9] i2c: rk3x: fix potential spinlock recursion on poll
In-Reply-To: <20231226002526.6605-1-sashal@kernel.org>
References: <20231226002526.6605-1-sashal@kernel.org>
Message-ID: <20231226002526.6605-8-sashal@kernel.org>

From: Jensen Huang <jensenhuang at friendlyarm.com>

[ Upstream commit 19cde9c92b8d3b7ee555d0da3bcb0232d3a784f4 ]

Possible deadlock scenario (on reboot):
rk3x_i2c_xfer_common(polling)
    -> rk3x_i2c_wait_xfer_poll()
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock);
            ...
        <rk3x i2c interrupt>
        -> rk3x_i2c_irq(0, i2c);
            --> spin_lock(&i2c->lock); (deadlock here)

Store the IRQ number and disable/enable it around the polling transfer.
This patch has been tested on NanoPC-T4.

Signed-off-by: Jensen Huang <jensenhuang at friendlyarm.com>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
Reviewed-by: Andi Shyti <andi.shyti at kernel.org>
Signed-off-by: Wolfram Sang <wsa at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/i2c/busses/i2c-rk3x.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 13c14eb175e94..6abcf975a2db9 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -178,6 +178,7 @@ struct rk3x_i2c_soc_data {
  * @clk: function clk for rk3399 or function & Bus clks for others
  * @pclk: Bus clk for rk3399
  * @clk_rate_nb: i2c clk rate change notify
+ * @irq: irq number
  * @t: I2C known timing information
  * @lock: spinlock for the i2c bus
  * @wait: the waitqueue to wait for i2c transfer
@@ -200,6 +201,7 @@ struct rk3x_i2c {
 	struct clk *clk;
 	struct clk *pclk;
 	struct notifier_block clk_rate_nb;
+	int irq;
 
 	/* Settings */
 	struct i2c_timings t;
@@ -1087,13 +1089,18 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
 
 		spin_unlock_irqrestore(&i2c->lock, flags);
 
-		rk3x_i2c_start(i2c);
-
 		if (!polling) {
+			rk3x_i2c_start(i2c);
+
 			timeout = wait_event_timeout(i2c->wait, !i2c->busy,
 						     msecs_to_jiffies(WAIT_TIMEOUT));
 		} else {
+			disable_irq(i2c->irq);
+			rk3x_i2c_start(i2c);
+
 			timeout = rk3x_i2c_wait_xfer_poll(i2c);
+
+			enable_irq(i2c->irq);
 		}
 
 		spin_lock_irqsave(&i2c->lock, flags);
@@ -1301,6 +1308,8 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	i2c->irq = irq;
+
 	platform_set_drvdata(pdev, i2c);
 
 	if (i2c->soc_data->calc_timings == rk3x_i2c_v0_calc_timings) {
-- 
2.43.0



From andre.przywara at arm.com  Mon Dec 25 17:16:34 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 26 Dec 2023 01:16:34 +0000
Subject: [PATCH RESEND] ARM: dts: sun8i: r40: open the regulator aldo1
In-Reply-To: <ZYlVTFrWkPaci92K@debian.cyg>
References: <ZYKjYypuAx7gNuam@debian.cyg>
	<20231220150400.0f32e2a5@donnerap.manchester.arm.com>
	<ZYOhAQi7XeLUuAC9@debian.cyg>
	<20231221103906.1830ef94@donnerap.manchester.arm.com>
	<ZYlVTFrWkPaci92K@debian.cyg>
Message-ID: <20231226011634.32e2342d@minigeek.lan>

On Mon, 25 Dec 2023 18:11:24 +0800
fuyao <fuyao at sjterm.com> wrote:

Hi,

thanks for the reply, with insightful information!

> On Thu, Dec 21, 2023 at 10:39:06AM +0000, Andre Przywara wrote:
> > On Thu, 21 Dec 2023 10:20:49 +0800
> > fuyao <fuyao at sjterm.com> wrote:
> > 
> > Hi,
> > 
> > thanks for the reply!
> >   
> > > On Wed, Dec 20, 2023 at 03:04:00PM +0000, Andre Przywara wrote:  
> > > > On Wed, 20 Dec 2023 16:18:43 +0800
> > > > fuyao <fuyao1697 at cyg.com> wrote:
> > > > 
> > > > Hi,
> > > >     
> > > > > the aldo1 is connect regulator pin which power the TV.    
> > > > 
> > > > What do you mean with that? That ALDO1 is connected to VCC-TVOUT and/or
> > > > VCC-TVIN on the R40 SoC?    
> > > 
> > > The ALDO1 is connected to VCC-TVOUT on the R40 Soc.  
> > 
> > Ah, thanks for the confirmation.
> >   
> > > > > The USB core use TV ref as reference Voltage.    
> > > > 
> > > > The USB core in the SoC? So pin VCC-USB, which requires 3.3V, the same
> > > > voltage as the TV pins?
> > > > Which means this doesn't really have much to do with TV, it's just that
> > > > USB and also "TV" are supplied by ALDO1?    
> > > 
> > > The internal USB PHY requires a reference voltage. It seems that in
> > > order to save costs, the reference voltage of the TVOUT module is used.  
> > 
> > Do you mean a USB *reference* voltage that is separate from the USB PHY
> > power supply voltage, so pin VCC-USB on the SoC? And that it is internally
> > connected to some TV-OUT related circuits? So that would apply to all
> > devices using the R40 SoC then?  
> yes, The usb need a power from TV module insides.

Ah, alright. I dimly remember hearing reports about unstable USB
operation on some (custom?) R40 boards, that might as well explain it.
On the BananaPis (the only other officially supported R40 boards),
TVOUT and TVOUT are connected to DCDC1, so are effectively always
powered by 3.3V already, which would explain why we didn't observe USB
issues there.

> > Or is it simply that the SoC pins VCC-TVOUT and VCC-USB are connected
> > together, on this SoM?  
> no

Thanks for the confirmation!

> > Do you have access to some schematic? I couldn't find one online easily,
> > so cannot check this myself.
> >   
> It has up to https://file.io/VSUL4FDrapDY

Ah, many thanks, that's really useful! That indeed confirms that both
TVIN and TVOUT are exclusively powered by ALDO1.

So if you resend the patch as v2, with the regulator-name changed, and
possibly with the following commit message, I'd support it:

=============
The USB PHY in the Allwinner R40 SoC seems to rely on voltage on the
VCC-TVIN/OUT supply pins for proper operation, on top of its own supply
voltage on VCC-USB. Without a 3.3V voltage supplied to VCC-TV*, USB
operation becomes unstable and can result in disconnects.

The Forlinx FETA40i-C SoM connects both the VCC-TVOUT and VCC-TVIN pins
to the ALDO1 rail of the PMIC, so we need to enable that rail for USB
operation. Since there is no supply property in the DT bindings for
the USB core, we need to always enable the regulator.

This fixes unstable USB operation on boards using the Forlinx FETA40i-C
module.
================

Cheers,
Andre


> > Thanks,
> > Andre
> >   
> > > > > Signed-off-by: fuyao <fuyao1697 at cyg.com>
> > > > > ---
> > > > >  arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
> > > > >  1 file changed, 7 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > > > > index 9f39b5a2bb35..8906170461df 100644
> > > > > --- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > > > > +++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> > > > > @@ -42,6 +42,13 @@ &pio {
> > > > >  	vcc-pg-supply = <&reg_dldo1>;
> > > > >  };
> > > > >  
> > > > > +&reg_aldo1 {
> > > > > +	regulator-always-on;    
> > > > 
> > > > So did USB never work before, with the DT as in mainline?
> > > >     
> > > 
> > > The USB can work, but is unstable. Occasionally disconnected because of
> > > the D+/D- electrical characteristics.
> > >   
> > > > For always-on regulators it would be good to see some rationale why this
> > > > cannot be referenced by its consumer. If it is really supplying the USB
> > > > core, that would be a reason, because we don't have a good way of
> > > > describing this.
> > > >     
> > > > > +	regulator-min-microvolt = <3300000>;
> > > > > +	regulator-max-microvolt = <3300000>;
> > > > > +	regulator-name = "vcc-aldo1";    
> > > > 
> > > > Regulators should be named after their users, so use something like:
> > > > 	regulator-name = "vcc-3v3-tv-usb";
> > > >     
> > > 
> > > thanks.
> > >   
> > > > That then also serves as documentation of why this is always on.
> > > > 
> > > > Cheers,
> > > > Andre
> > > >     
> > > > > +};
> > > > > +
> > > > >  &reg_aldo2 {
> > > > >  	regulator-always-on;
> > > > >  	regulator-min-microvolt = <1800000>;    
> > > >     
> > >   
> 



From ck.hu at mediatek.com  Mon Dec 25 19:20:35 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 03:20:35 +0000
Subject: [PATCH v3 08/11] drm/mediatek: Add secure layer config support
 for ovl_adaptor
In-Reply-To: <20231223182932.27683-9-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-9-jason-jh.lin@mediatek.com>
Message-ID: <2d045768bb3f1da3e2ea77f9f94050b194627e5b.camel@mediatek.com>

Hi, Jason:

On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> Add secure layer config support for ovl_adaptor and sub driver
> mdp_rdma.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_drv.h         |  1 +
>  drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 +++++++++++++++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c     |  1 +
>  drivers/gpu/drm/mediatek/mtk_mdp_rdma.c         | 11 ++++++++---
>  drivers/gpu/drm/mediatek/mtk_mdp_rdma.h         |  2 ++
>  5 files changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 77054adcd9cf..ec9746767468 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -117,6 +117,7 @@ void mtk_ovl_adaptor_clk_disable(struct device
> *dev);
>  void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
>  			    unsigned int h, unsigned int vrefresh,
>  			    unsigned int bpc, struct cmdq_pkt
> *cmdq_pkt);
> +u64 mtk_ovl_adaptor_get_sec_port(struct mtk_ddp_comp *comp, unsigned
> int idx);
>  void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int
> idx,
>  				  struct mtk_plane_state *state,
>  				  struct cmdq_pkt *cmdq_pkt);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> index 6bf6367853fb..f419c2e70ba3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> @@ -83,6 +83,18 @@ static const struct ovl_adaptor_comp_match
> comp_matches[OVL_ADAPTOR_ID_MAX] = {
>  	[OVL_ADAPTOR_ETHDR0]	= { OVL_ADAPTOR_TYPE_ETHDR, 0 },
>  };
>  
> +static const u64 ovl_adaptor_sec_port[] = {
> +	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L0),
> +	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L1),
> +	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L2),
> +	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L3),
> +};
> +
> +u64 mtk_ovl_adaptor_get_sec_port(struct mtk_ddp_comp *comp, unsigned
> int idx)
> +{
> +	return ovl_adaptor_sec_port[idx];
> +}
> +
>  void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int
> idx,
>  				  struct mtk_plane_state *state,
>  				  struct cmdq_pkt *cmdq_pkt)
> @@ -141,6 +153,9 @@ void mtk_ovl_adaptor_layer_config(struct device
> *dev, unsigned int idx,
>  	rdma_config.pitch = pending->pitch;
>  	rdma_config.fmt = pending->format;
>  	rdma_config.color_encoding = pending->color_encoding;
> +	rdma_config.source_size = (pending->height - 1) * pending-
> >pitch +
> +				  pending->width * fmt_info->cpp[0];
> +	rdma_config.is_secure = state->pending.is_secure;
>  	mtk_mdp_rdma_config(rdma_l, &rdma_config, cmdq_pkt);
>  
>  	if (use_dual_pipe) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 6aed7647dfc0..9b7fe34df9a6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -445,6 +445,7 @@ static const struct mtk_ddp_comp_funcs
> ddp_ovl_adaptor = {
>  	.remove = mtk_ovl_adaptor_remove_comp,
>  	.get_formats = mtk_ovl_adaptor_get_formats,
>  	.get_num_formats = mtk_ovl_adaptor_get_num_formats,
> +	.get_sec_port = mtk_ovl_adaptor_get_sec_port,
>  };
>  
>  static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] =
> {
> diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> index c3adaeefd551..a164ba82d022 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> @@ -94,6 +94,7 @@ struct mtk_mdp_rdma {
>  	void __iomem		*regs;
>  	struct clk		*clk;
>  	struct cmdq_client_reg	cmdq_reg;
> +	resource_size_t		regs_pa;
>  };
>  
>  static unsigned int rdma_fmt_convert(unsigned int fmt)
> @@ -198,9 +199,12 @@ void mtk_mdp_rdma_config(struct device *dev,
> struct mtk_mdp_rdma_cfg *cfg,
>  	else
>  		mtk_ddp_write_mask(cmdq_pkt, 0, &priv->cmdq_reg, priv-
> >regs,
>  				   MDP_RDMA_SRC_CON, FLD_OUTPUT_ARGB);
> -
> -	mtk_ddp_write_mask(cmdq_pkt, cfg->addr0, &priv->cmdq_reg, priv-
> >regs,
> -			   MDP_RDMA_SRC_BASE_0, FLD_SRC_BASE_0);
> +	if (cfg->is_secure)
> +		mtk_ddp_sec_write(cmdq_pkt, priv->regs_pa +
> MDP_RDMA_SRC_BASE_0,
> +				  cfg->addr0, CMDQ_IWC_H_2_MVA, 0, cfg-
> >source_size, 0);

In OVL, there is one bit that control OVL hardware could access secure
buffer or not. Why mdp rdma has no this bit?

Regards,
CK

> +	else
> +		mtk_ddp_write_mask(cmdq_pkt, cfg->addr0, &priv-
> >cmdq_reg, priv->regs,
> +				   MDP_RDMA_SRC_BASE_0,
> FLD_SRC_BASE_0);
>  
>  	mtk_ddp_write_mask(cmdq_pkt, src_pitch_y, &priv->cmdq_reg,
> priv->regs,
>  			   MDP_RDMA_MF_BKGD_SIZE_IN_BYTE,
> FLD_MF_BKGD_WB);
> @@ -285,6 +289,7 @@ static int mtk_mdp_rdma_probe(struct
> platform_device *pdev)
>  		return -ENOMEM;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	priv->regs_pa = res->start;
>  	priv->regs = devm_ioremap_resource(dev, res);
>  	if (IS_ERR(priv->regs)) {
>  		dev_err(dev, "failed to ioremap rdma\n");
> diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.h
> b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.h
> index 9943ee3aac31..cd4840411411 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.h
> +++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.h
> @@ -15,6 +15,8 @@ struct mtk_mdp_rdma_cfg {
>  	unsigned int	y_top;
>  	int		fmt;
>  	int		color_encoding;
> +	unsigned int	source_size;
> +	unsigned int	is_secure;
>  };
>  
>  #endif // __MTK_MDP_RDMA_H__

From viresh.kumar at linaro.org  Mon Dec 25 21:12:28 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Tue, 26 Dec 2023 10:42:28 +0530
Subject: [PATCH 1/2] OPP: Add API to update EM after adjustment of
 voltage for OPPs
In-Reply-To: <20231220110339.1065505-2-lukasz.luba@arm.com>
References: <20231220110339.1065505-1-lukasz.luba@arm.com>
 <20231220110339.1065505-2-lukasz.luba@arm.com>
Message-ID: <20231226051228.oe7rpgf34nwgr5ah@vireshk-i7>

On 20-12-23, 11:03, Lukasz Luba wrote:
> There are device drivers which can modify voltage values for OPPs. It
> could be due to the chip binning and those drivers have specific chip
> knowledge about this. This adjustment can happen after Energy Model is
> registered, thus EM can have stale data about power.
> 
> Introduce new API function which can be used by device driver which
> adjusted the voltage for OPPs. The implementation takes care about
> calculating needed internal details in the new EM table ('cost' field).
> It plugs in the new EM table to the framework so other subsystems would
> use the correct data.
> 
> Signed-off-by: Lukasz Luba <lukasz.luba at arm.com>
> ---
>  drivers/opp/of.c       | 69 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/pm_opp.h |  6 ++++
>  2 files changed, 75 insertions(+)
> 
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 81fa27599d58..992434c0b711 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -1596,3 +1596,72 @@ int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus)
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_opp_of_register_em);
> +
> +/**
> + * dev_pm_opp_of_update_em() - Update Energy Model with new power values
> + * @dev		: Device for which an Energy Model has to be registered
> + *
> + * This uses the "dynamic-power-coefficient" devicetree property to calculate
> + * power values for EM. It uses the new adjusted voltage values known for OPPs
> + * which have changed after boot.
> + */
> +int dev_pm_opp_of_update_em(struct device *dev)

I don't see anything OPP or OF related in this function, I don't think it needs
to be part of the OPP core. You just want to reuse _get_power() I guess, which
can be exported then.

This should really be part of the EM core instead.

-- 
viresh


From ck.hu at mediatek.com  Mon Dec 25 21:14:45 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 05:14:45 +0000
Subject: [PATCH v3 07/11] drm/mediatek: Add secure layer config support
 for ovl
In-Reply-To: <20231223182932.27683-8-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-8-jason-jh.lin@mediatek.com>
Message-ID: <eb8fa56d4dfa78f84d32fd7c9e271186d13f4ade.camel@mediatek.com>

Hi, Jason:

On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> Add secure layer config support for ovl.
> 
> TODO:
> 1. Move DISP_REG_OVL_SECURE setting to secure world.
> 2. Change the parameter register address in mtk_ddp_sec_write()
>    from "u32 addr" to "struct cmdq_client_reg *cmdq_reg".
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_drv.h     |  2 ++
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c     | 31
> +++++++++++++++++++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 29 +++++++++++++++++++
>  3 files changed, 60 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 1311562d25cc..77054adcd9cf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -9,6 +9,7 @@
>  #include <linux/soc/mediatek/mtk-cmdq.h>
>  #include <linux/soc/mediatek/mtk-mmsys.h>
>  #include <linux/soc/mediatek/mtk-mutex.h>
> +#include "mtk_drm_ddp_comp.h"
>  #include "mtk_drm_plane.h"
>  #include "mtk_mdp_rdma.h"
>  
> @@ -82,6 +83,7 @@ void mtk_ovl_clk_disable(struct device *dev);
>  void mtk_ovl_config(struct device *dev, unsigned int w,
>  		    unsigned int h, unsigned int vrefresh,
>  		    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> +u64 mtk_ovl_get_sec_port(struct mtk_ddp_comp *comp, unsigned int
> idx);
>  int mtk_ovl_layer_check(struct device *dev, unsigned int idx,
>  			struct mtk_plane_state *mtk_state);
>  void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 2bffe4245466..c18f76412a2e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -46,6 +46,7 @@
>  #define DISP_REG_OVL_ADDR(ovl, n)		((ovl)->data->addr +
> 0x20 * (n))
>  #define DISP_REG_OVL_HDR_ADDR(ovl, n)		((ovl)->data-
> >addr + 0x20 * (n) + 0x04)
>  #define DISP_REG_OVL_HDR_PITCH(ovl, n)		((ovl)->data-
> >addr + 0x20 * (n) + 0x08)
> +#define DISP_REG_OVL_SECURE			0x0fc0
>  
>  #define GMC_THRESHOLD_BITS	16
>  #define GMC_THRESHOLD_HIGH	((1 << GMC_THRESHOLD_BITS) / 4)
> @@ -126,8 +127,19 @@ struct mtk_disp_ovl {
>  	const struct mtk_disp_ovl_data	*data;
>  	void				(*vblank_cb)(void *data);
>  	void				*vblank_cb_data;
> +	resource_size_t			regs_pa;
>  };
>  
> +u64 mtk_ovl_get_sec_port(struct mtk_ddp_comp *comp, unsigned int
> idx)
> +{
> +	if (comp->id == DDP_COMPONENT_OVL0)
> +		return BIT_ULL(CMDQ_SEC_DISP_OVL0);
> +	else if (comp->id == DDP_COMPONENT_OVL1)
> +		return BIT_ULL(CMDQ_SEC_DISP_OVL1);
> +
> +	return 0;
> +}
> +
>  static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
>  {
>  	struct mtk_disp_ovl *priv = dev_id;
> @@ -449,8 +461,22 @@ void mtk_ovl_layer_config(struct device *dev,
> unsigned int idx,
>  			      DISP_REG_OVL_SRC_SIZE(idx));
>  	mtk_ddp_write_relaxed(cmdq_pkt, offset, &ovl->cmdq_reg, ovl-
> >regs,
>  			      DISP_REG_OVL_OFFSET(idx));
> -	mtk_ddp_write_relaxed(cmdq_pkt, addr, &ovl->cmdq_reg, ovl-
> >regs,
> -			      DISP_REG_OVL_ADDR(ovl, idx));
> +
> +	if (state->pending.is_secure) {
> +		const struct drm_format_info *fmt_info =
> drm_format_info(fmt);
> +		unsigned int buf_size = (pending->height - 1) *
> pending->pitch +
> +					pending->width * fmt_info-
> >cpp[0];
> +
> +		mtk_ddp_write_mask(cmdq_pkt, BIT(idx), &ovl->cmdq_reg,
> ovl->regs,
> +				   DISP_REG_OVL_SECURE, BIT(idx));
> +		mtk_ddp_sec_write(cmdq_pkt, ovl->regs_pa +
> DISP_REG_OVL_ADDR(ovl, idx),
> +				  pending->addr, CMDQ_IWC_H_2_MVA, 0,
> buf_size, 0);

Mapping iova should be done when buffer allocation or some other
mapping function, instead of every OVL frame configuration. So the size
should not be set here.

Regards,
CK

> +	} else {
> +		mtk_ddp_write_mask(cmdq_pkt, 0, &ovl->cmdq_reg, ovl-
> >regs,
> +				   DISP_REG_OVL_SECURE, BIT(idx));
> +		mtk_ddp_write_relaxed(cmdq_pkt, addr, &ovl->cmdq_reg,
> ovl->regs,
> +				      DISP_REG_OVL_ADDR(ovl, idx));
> +	}
>  
>  	if (is_afbc) {
>  		mtk_ddp_write_relaxed(cmdq_pkt, hdr_addr, &ovl-
> >cmdq_reg, ovl->regs,
> @@ -529,6 +555,7 @@ static int mtk_disp_ovl_probe(struct
> platform_device *pdev)
>  	}
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	priv->regs_pa = res->start;
>  	priv->regs = devm_ioremap_resource(dev, res);
>  	if (IS_ERR(priv->regs)) {
>  		dev_err(dev, "failed to ioremap ovl\n");
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 3046c0409353..6aed7647dfc0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -111,6 +111,34 @@ void mtk_ddp_write_mask(struct cmdq_pkt
> *cmdq_pkt, unsigned int value,
>  #endif
>  }
>  
> +void mtk_ddp_sec_write(struct cmdq_pkt *cmdq_pkt, u32 addr, u64
> base,
> +		       const enum cmdq_iwc_addr_metadata_type type,
> +		       const u32 offset, const u32 size, const u32
> port)
> +{
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> +	if (!cmdq_pkt)
> +		return;
> +
> +	/* secure buffer will be 4K alignment */
> +	cmdq_sec_pkt_write(cmdq_pkt, addr, base, type,
> +			   offset, ALIGN(size, PAGE_SIZE), port);
> +#endif
> +}
> +
> +void mtk_ddp_sec_write(struct cmdq_pkt *cmdq_pkt, u32 addr, u64
> base,
> +		       const enum cmdq_iwc_addr_metadata_type type,
> +		       const u32 offset, const u32 size, const u32
> port)
> +{
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> +	if (!cmdq_pkt)
> +		return;
> +
> +	/* secure buffer will be 4K alignment */
> +	cmdq_sec_pkt_write(cmdq_pkt, addr, base, type,
> +			   offset, ALIGN(size, PAGE_SIZE), port);
> +#endif
> +}
> +
>  static int mtk_ddp_clk_enable(struct device *dev)
>  {
>  	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> @@ -365,6 +393,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl =
> {
>  	.bgclr_in_off = mtk_ovl_bgclr_in_off,
>  	.get_formats = mtk_ovl_get_formats,
>  	.get_num_formats = mtk_ovl_get_num_formats,
> +	.get_sec_port = mtk_ovl_get_sec_port,
>  };
>  
>  static const struct mtk_ddp_comp_funcs ddp_postmask = {

From viresh.kumar at linaro.org  Mon Dec 25 21:32:33 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Tue, 26 Dec 2023 11:02:33 +0530
Subject: [PATCH v2 3/5] thermal/cpufreq: Remove
 arch_update_thermal_pressure()
In-Reply-To: <20231221152407.436177-4-vincent.guittot@linaro.org>
References: <20231221152407.436177-1-vincent.guittot@linaro.org>
 <20231221152407.436177-4-vincent.guittot@linaro.org>
Message-ID: <20231226053233.gtvuflyonkcifa4x@vireshk-i7>

On 21-12-23, 16:24, Vincent Guittot wrote:
> arch_update_thermal_pressure() aims to update fast changing signal which
> should be averaged using PELT filtering before being provided to the
> scheduler which can't make smart use of fast changing signal.
> cpufreq now provides the maximum freq_qos pressure on the capacity to the
> scheduler, which includes cpufreq cooling device. Remove the call to
> arch_update_thermal_pressure() in cpufreq cooling device as this is
> handled by cpufreq_get_pressure().
> 
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

-- 
viresh


From viresh.kumar at linaro.org  Mon Dec 25 21:36:47 2023
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Tue, 26 Dec 2023 11:06:47 +0530
Subject: [RFC PATCH v3 3/3] riscv: dts: allwinner: Fill in OPPs
In-Reply-To: <20231222111407.104270-4-fusibrandon13@gmail.com>
References: <20231222111407.104270-1-fusibrandon13@gmail.com>
 <20231222111407.104270-4-fusibrandon13@gmail.com>
Message-ID: <20231226053647.kvrpn4pjtc2lhfcm@vireshk-i7>

On 22-12-23, 12:14, Brandon Cheo Fusi wrote:
> Specify two voltage ranges, in order of increasing stability,
> for each OPP.
> 
> Also define an nvmem cpu speed grade cell of length 2.
> 
> Link: https://github.com/Tina-Linux/linux-5.4/blob/master/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L133
> Link: https://github.com/mangopi-sbc/tina-linux-5.4/blob/0d4903ebd9d2194ad914686d5b0fc1ddacf11a9d/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsi#L118-L182
> 
> Signed-off-by: Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> ---
>  arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> index 64c3c2e6c..7e2e015e0 100644
> --- a/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi
> @@ -39,16 +39,23 @@ cpu0_intc: interrupt-controller {
>  	};
>  
>  	opp_table_cpu: opp-table-cpu {
> -		compatible = "operating-points-v2";
> +		compatible = "allwinner,sun20i-d1-operating-points";
> +		nvmem-cells = <&cpu_speed_grade>;
> +		nvmem-cell-names = "speed";
> +		opp-shared;
>  
>  		opp-408000000 {
>  			opp-hz = /bits/ 64 <408000000>;
> -			opp-microvolt = <900000 900000 1100000>;
> +
> +			opp-microvolt-speed0 = <950000 950000 1100000>;
> +			opp-microvolt-speed1 = <900000 900000 1100000>;
>  		};
>  
>  		opp-1080000000 {
>  			opp-hz = /bits/ 64 <1008000000>;
> -			opp-microvolt = <900000 900000 1100000>;
> +
> +			opp-microvolt-speed0 = <1100000>;

I was expecting the above two lines to have same values. Why change
them ?

> +			opp-microvolt-speed1 = <950000 950000 1100000>;
>  		};
>  	};
>  
> @@ -115,3 +122,9 @@ pmu {
>  			<0x00000000 0x0000000f 0xffffffff 0xffffffff 0x00020000>;
>  	};
>  };
> +
> +&sid {
> +	cpu_speed_grade: cpu-speed-grade at 0 {
> +		reg = <0x00 0x2>;
> +	};
> +};
> -- 
> 2.30.2

-- 
viresh


From ck.hu at mediatek.com  Mon Dec 25 21:43:15 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 05:43:15 +0000
Subject: [PATCH v3 09/11] drm/mediatek: Add secure flow support to
 mediatek-drm
In-Reply-To: <20231223182932.27683-10-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-10-jason-jh.lin@mediatek.com>
Message-ID: <63c24cda9e007ef2128e9350b6a6ed3bc61f3a85.camel@mediatek.com>

Hi, Jason:

On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> To add secure flow support for mediatek-drm, each crtc have to
> create a secure cmdq mailbox channel. Then cmdq packets with
> display HW configuration will be sent to secure cmdq mailbox channel
> and configured in the secure world.
> 
> Each crtc have to use secure cmdq interface to configure some secure
> settings for display HW before sending cmdq packets to secure cmdq
> mailbox channel.
> 
> If any of fb get from current drm_atomic_state is secure, then crtc
> will switch to the secure flow to configure display HW.
> If all fbs are not secure in current drm_atomic_state, then crtc will
> switch to the normal flow.
> 
> TODO:
> 1. Remove get sec larb port interface in ddp_comp, ovl and
> ovl_adaptor.
> 2. Verify instruction for enabling/disabling dapc and larb port in
> TEE
>    drop the sec_engine flags in normal world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> 

[snip]

> @@ -1091,14 +1292,63 @@ int mtk_drm_crtc_create(struct drm_device
> *drm_dev,
>  			if (ret) {
>  				dev_dbg(dev, "mtk_crtc %d failed to
> create cmdq packet\n",
>  					drm_crtc_index(&mtk_crtc-
> >base));
> -				mbox_free_channel(mtk_crtc-
> >cmdq_client.chan);
> -				mtk_crtc->cmdq_client.chan = NULL;
> +				goto cmdq_err;
>  			}
>  		}
>  
>  		/* for sending blocking cmd in crtc disable */
>  		init_waitqueue_head(&mtk_crtc->cb_blocking_queue);
>  	}
> +
> +	mtk_crtc->sec_cmdq_client.client.dev = mtk_crtc->mmsys_dev;
> +	mtk_crtc->sec_cmdq_client.client.tx_block = false;
> +	mtk_crtc->sec_cmdq_client.client.knows_txdone = true;
> +	mtk_crtc->sec_cmdq_client.client.rx_callback = ddp_cmdq_cb;
> +	mtk_crtc->sec_cmdq_client.chan =
> +			mbox_request_channel(&mtk_crtc-
> >sec_cmdq_client.client, i + 1);
> +	if (IS_ERR(mtk_crtc->sec_cmdq_client.chan)) {
> +		dev_err(dev, "mtk_crtc %d failed to create sec mailbox
> client\n",
> +			drm_crtc_index(&mtk_crtc->base));
> +		mtk_crtc->sec_cmdq_client.chan = NULL;
> +	}
> +
> +	if (mtk_crtc->sec_cmdq_client.chan) {

I would like use secure channel to replace normal channel. It means
that no extra channel is required and change the original normal
channel to secure channel. The secure channel could process both normal
buffer and secure buffer, so you need not to switch the channel.

Regards,
CK

> +		struct device_link *link;
> +
> +		/* add devlink to cmdq dev to make sure suspend/resume
> order is correct */
> +		link = device_link_add(priv->dev, mtk_crtc-
> >sec_cmdq_client.chan->mbox->dev,
> +				       DL_FLAG_PM_RUNTIME |
> DL_FLAG_STATELESS);
> +		if (!link) {
> +			dev_err(priv->dev, "Unable to link dev=%s\n",
> +				dev_name(mtk_crtc-
> >sec_cmdq_client.chan->mbox->dev));
> +			ret = -ENODEV;
> +			goto cmdq_err;
> +		}
> +
> +		ret = mtk_drm_cmdq_pkt_create(&mtk_crtc-
> >sec_cmdq_client,
> +					      &mtk_crtc-
> >sec_cmdq_handle,
> +					      PAGE_SIZE);
> +		if (ret) {
> +			dev_dbg(dev, "mtk_crtc %d failed to create cmdq
> secure packet\n",
> +				drm_crtc_index(&mtk_crtc->base));
> +			goto cmdq_err;
> +		}
> +
> +		/* for sending blocking cmd in crtc disable */
> +		init_waitqueue_head(&mtk_crtc->sec_cb_blocking_queue);
> +	}
> +
> +cmdq_err:
> +	if (ret) {
> +		if (mtk_crtc->cmdq_client.chan) {
> +			mbox_free_channel(mtk_crtc->cmdq_client.chan);
> +			mtk_crtc->cmdq_client.chan = NULL;
> +		}
> +		if (mtk_crtc->sec_cmdq_client.chan) {
> +			mbox_free_channel(mtk_crtc-
> >sec_cmdq_client.chan);
> +			mtk_crtc->sec_cmdq_client.chan = NULL;
> +		}
> +	}
>  #endif
>  
>  	if (conn_routes) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> index 1f988ff1bf9f..cf8433846108 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> @@ -21,6 +21,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
>  			int priv_data_index,
>  			const struct mtk_drm_route *conn_routes,
>  			unsigned int num_conn_routes);
> +void mtk_crtc_disable_secure_state(struct drm_crtc *crtc);
>  int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane
> *plane,
>  			     struct mtk_plane_state *state);
>  void mtk_drm_crtc_async_update(struct drm_crtc *crtc, struct
> drm_plane *plane,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index d4d515627ca4..96293c632d67 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -287,6 +287,13 @@ static void mtk_plane_atomic_disable(struct
> drm_plane *plane,
>  	mtk_plane_state->pending.enable = false;
>  	wmb(); /* Make sure the above parameter is set before update */
>  	mtk_plane_state->pending.dirty = true;
> +
> +	if (mtk_plane_state->pending.is_secure) {
> +		struct drm_plane_state *old_state =
> drm_atomic_get_old_plane_state(state, plane);
> +
> +		if (old_state->crtc)
> +			mtk_crtc_disable_secure_state(old_state->crtc);
> +	}
>  }
>  
>  static void mtk_plane_atomic_update(struct drm_plane *plane,

From ck.hu at mediatek.com  Mon Dec 25 21:24:37 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 05:24:37 +0000
Subject: [PATCH v3 06/11] drm/mediatek: Add get_sec_port interface to
 mtk_ddp_comp
In-Reply-To: <20231223182932.27683-7-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-7-jason-jh.lin@mediatek.com>
Message-ID: <4165d71dd9d0043346ca57d1a556f21639885d18.camel@mediatek.com>

On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> Add get_sec_port interface to ddp_comp to get the secure port
> settings
> from ovl and ovl_adaptor.
> Then mediatek-drm will use secure cmdq driver to configure DRAM
> access
> permission in secure world by their secure port settings.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

TODO: drop this patch.


Regards,
CK

>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index b5a05ca3a385..1e6a120a103d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -84,6 +84,7 @@ struct mtk_ddp_comp_funcs {
>  	void (*add)(struct device *dev, struct mtk_mutex *mutex);
>  	void (*remove)(struct device *dev, struct mtk_mutex *mutex);
>  	unsigned int (*encoder_index)(struct device *dev);
> +	u64 (*get_sec_port)(struct mtk_ddp_comp *comp, unsigned int
> idx);
>  };
>  
>  struct mtk_ddp_comp {
> @@ -199,6 +200,14 @@ static inline unsigned int
> mtk_ddp_gamma_get_lut_size(struct mtk_ddp_comp *comp)
>  	return 0;
>  }
>  
> +static inline u64 mtk_ddp_comp_layer_get_sec_port(struct
> mtk_ddp_comp *comp,
> +						  unsigned int idx)
> +{
> +	if (comp->funcs && comp->funcs->get_sec_port)
> +		return comp->funcs->get_sec_port(comp, idx);
> +	return 0;
> +}
> +
>  static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp *comp,
>  				     struct drm_crtc_state *state)
>  {

From aakarsh.jain at samsung.com  Mon Dec 25 21:10:11 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Tue, 26 Dec 2023 10:40:11 +0530
Subject: [PATCH 01/15] media: s5p-mfc: drop unused static s5p_mfc_cmds
In-Reply-To: <20231224-n-s5p-mfc-const-v1-1-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
	<CGME20231224154435epcas5p11c17dce71c5ce263c8028a43b401aa22@epcas5p1.samsung.com>
	<20231224-n-s5p-mfc-const-v1-1-a3b246470fe4@linaro.org>
Message-ID: <15ce01da37b9$cede8d20$6c9ba760$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: 24 December 2023 21:14
> To: Marek Szyprowski <m.szyprowski at samsung.com>; Andrzej Hajda
> <andrzej.hajda at intel.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>
> Cc: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-fsd at tesla.coma; linux-
> samsung-soc at vger.kernel.org; Smitha T Murthy
> <smithatmurthy at gmail.com>; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org; linux-kernel at vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>
> Subject: [PATCH 01/15] media: s5p-mfc: drop unused static s5p_mfc_cmds
> 
> File-scope static variable "s5p_mfc_cmds" is not read after assignment, thus
> it can be dropped entirely.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c
> index 774c573dc075..196d8c99647b 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd.c
> @@ -12,14 +12,10 @@
>  #include "s5p_mfc_cmd_v5.h"
>  #include "s5p_mfc_cmd_v6.h"
> 
> -static struct s5p_mfc_hw_cmds *s5p_mfc_cmds;
> -
>  void s5p_mfc_init_hw_cmds(struct s5p_mfc_dev *dev)  {
>  	if (IS_MFCV6_PLUS(dev))
> -		s5p_mfc_cmds = s5p_mfc_init_hw_cmds_v6();
> +		dev->mfc_cmds = s5p_mfc_init_hw_cmds_v6();
>  	else
> -		s5p_mfc_cmds = s5p_mfc_init_hw_cmds_v5();
> -
> -	dev->mfc_cmds = s5p_mfc_cmds;
> +		dev->mfc_cmds = s5p_mfc_init_hw_cmds_v5();
>  }
> 
> --
> 2.34.1

Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Thanks!



From aakarsh.jain at samsung.com  Mon Dec 25 21:12:15 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Tue, 26 Dec 2023 10:42:15 +0530
Subject: [PATCH 02/15] media: s5p-mfc: drop unused static s5p_mfc_ops
In-Reply-To: <20231224-n-s5p-mfc-const-v1-2-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
	<CGME20231224154437epcas5p4ce3d24f3cbdc4ad25b215f14c5bccd3e@epcas5p4.samsung.com>
	<20231224-n-s5p-mfc-const-v1-2-a3b246470fe4@linaro.org>
Message-ID: <15cf01da37ba$18936ad0$49ba4070$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: 24 December 2023 21:14
> To: Marek Szyprowski <m.szyprowski at samsung.com>; Andrzej Hajda
> <andrzej.hajda at intel.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>
> Cc: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-fsd at tesla.coma; linux-
> samsung-soc at vger.kernel.org; Smitha T Murthy
> <smithatmurthy at gmail.com>; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org; linux-kernel at vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>
> Subject: [PATCH 02/15] media: s5p-mfc: drop unused static s5p_mfc_ops
> 
> File-scope static variable "s5p_mfc_ops" is not read after assignment, thus it
> can be dropped entirely.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c
> index 673962301173..5ba791fa3676 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr.c
> @@ -14,18 +14,15 @@
>  #include "s5p_mfc_opr_v5.h"
>  #include "s5p_mfc_opr_v6.h"
> 
> -static struct s5p_mfc_hw_ops *s5p_mfc_ops;
> -
>  void s5p_mfc_init_hw_ops(struct s5p_mfc_dev *dev)  {
>  	if (IS_MFCV6_PLUS(dev)) {
> -		s5p_mfc_ops = s5p_mfc_init_hw_ops_v6();
> +		dev->mfc_ops = s5p_mfc_init_hw_ops_v6();
>  		dev->warn_start = S5P_FIMV_ERR_WARNINGS_START_V6;
>  	} else {
> -		s5p_mfc_ops = s5p_mfc_init_hw_ops_v5();
> +		dev->mfc_ops = s5p_mfc_init_hw_ops_v5();
>  		dev->warn_start = S5P_FIMV_ERR_WARNINGS_START;
>  	}
> -	dev->mfc_ops = s5p_mfc_ops;
>  }
> 
>  void s5p_mfc_init_regs(struct s5p_mfc_dev *dev)
> 
> --
> 2.34.1

Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Thanks!



From aakarsh.jain at samsung.com  Mon Dec 25 21:18:55 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Tue, 26 Dec 2023 10:48:55 +0530
Subject: [PATCH 03/15] media: s5p-mfc: drop unused get_*_def_fmt
 declarations
In-Reply-To: <20231224-n-s5p-mfc-const-v1-3-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
	<CGME20231224154438epcas5p4eaeb4089c97bd804f1c0eb3fa756d2e4@epcas5p4.samsung.com>
	<20231224-n-s5p-mfc-const-v1-3-a3b246470fe4@linaro.org>
Message-ID: <15d001da37bb$0754f030$15fed090$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: 24 December 2023 21:14
> To: Marek Szyprowski <m.szyprowski at samsung.com>; Andrzej Hajda
> <andrzej.hajda at intel.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>
> Cc: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-fsd at tesla.coma; linux-
> samsung-soc at vger.kernel.org; Smitha T Murthy
> <smithatmurthy at gmail.com>; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org; linux-kernel at vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>
> Subject: [PATCH 03/15] media: s5p-mfc: drop unused get_*_def_fmt
> declarations
> 
> get_dec_def_fmt() and get_enc_def_fmt() do not have definitions, so their
> declarations are pointless.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h | 1 -
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
> index 0c52ab46cff7..d4310966a0c2 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.h
> @@ -12,7 +12,6 @@
>  const struct s5p_mfc_codec_ops *get_dec_codec_ops(void);  struct
> vb2_ops *get_dec_queue_ops(void);  const struct v4l2_ioctl_ops
> *get_dec_v4l2_ioctl_ops(void); -struct s5p_mfc_fmt
> *get_dec_def_fmt(bool src);  int s5p_mfc_dec_ctrls_setup(struct
> s5p_mfc_ctx *ctx);  void s5p_mfc_dec_ctrls_delete(struct s5p_mfc_ctx
> *ctx);  void s5p_mfc_dec_init(struct s5p_mfc_ctx *ctx); diff --git
> a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
> index 3f1b1a037a4f..0cf08b8d40ff 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.h
> @@ -12,7 +12,6 @@
>  const struct s5p_mfc_codec_ops *get_enc_codec_ops(void);  struct
> vb2_ops *get_enc_queue_ops(void);  const struct v4l2_ioctl_ops
> *get_enc_v4l2_ioctl_ops(void); -struct s5p_mfc_fmt
> *get_enc_def_fmt(bool src);  int s5p_mfc_enc_ctrls_setup(struct
> s5p_mfc_ctx *ctx);  void s5p_mfc_enc_ctrls_delete(struct s5p_mfc_ctx
> *ctx);  void s5p_mfc_enc_init(struct s5p_mfc_ctx *ctx);
> 
> --
> 2.34.1

Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Thanks!



From aakarsh.jain at samsung.com  Mon Dec 25 21:43:49 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Tue, 26 Dec 2023 11:13:49 +0530
Subject: [PATCH 05/15] media: s5p-mfc: constify s5p_mfc_buf_size
 structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-5-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
	<CGME20231224154441epcas5p3c802781d7e3fc305be11e19caee7b639@epcas5p3.samsung.com>
	<20231224-n-s5p-mfc-const-v1-5-a3b246470fe4@linaro.org>
Message-ID: <15d101da37be$818f7f70$84ae7e50$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: 24 December 2023 21:14
> To: Marek Szyprowski <m.szyprowski at samsung.com>; Andrzej Hajda
> <andrzej.hajda at intel.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>
> Cc: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-fsd at tesla.coma; linux-
> samsung-soc at vger.kernel.org; Smitha T Murthy
> <smithatmurthy at gmail.com>; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org; linux-kernel at vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>
> Subject: [PATCH 05/15] media: s5p-mfc: constify s5p_mfc_buf_size
> structures
> 
> Static "s5p_mfc_buf_size*" structures are not modified by the driver, so
> they can be made const for code safety.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c     | 20 ++++++++++---
> -------
>  .../media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c  |  2 +-
> .../media/platform/samsung/s5p-mfc/s5p_mfc_common.h  |  4 ++--
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c |  2 +-
> .../media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c  |  6 +++---
> .../media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c  |  6 +++---
>  6 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> index e30e54935d79..6af7b812c5df 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> @@ -1516,14 +1516,14 @@ static const struct dev_pm_ops
> s5p_mfc_pm_ops = {
>  	SET_SYSTEM_SLEEP_PM_OPS(s5p_mfc_suspend, s5p_mfc_resume)
> };
> 
> -static struct s5p_mfc_buf_size_v5 mfc_buf_size_v5 = {
> +static const struct s5p_mfc_buf_size_v5 mfc_buf_size_v5 = {
>  	.h264_ctx	= MFC_H264_CTX_BUF_SIZE,
>  	.non_h264_ctx	= MFC_CTX_BUF_SIZE,
>  	.dsc		= DESC_BUF_SIZE,
>  	.shm		= SHARED_BUF_SIZE,
>  };
> 
> -static struct s5p_mfc_buf_size buf_size_v5 = {
> +static const struct s5p_mfc_buf_size buf_size_v5 = {
>  	.fw	= MAX_FW_SIZE,
>  	.cpb	= MAX_CPB_SIZE,
>  	.priv	= &mfc_buf_size_v5,
> @@ -1540,7 +1540,7 @@ static struct s5p_mfc_variant mfc_drvdata_v5 = {
>  	.use_clock_gating = true,
>  };
> 
> -static struct s5p_mfc_buf_size_v6 mfc_buf_size_v6 = {
> +static const struct s5p_mfc_buf_size_v6 mfc_buf_size_v6 = {
>  	.dev_ctx	= MFC_CTX_BUF_SIZE_V6,
>  	.h264_dec_ctx	= MFC_H264_DEC_CTX_BUF_SIZE_V6,
>  	.other_dec_ctx	= MFC_OTHER_DEC_CTX_BUF_SIZE_V6,
> @@ -1548,7 +1548,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v6
> = {
>  	.other_enc_ctx	= MFC_OTHER_ENC_CTX_BUF_SIZE_V6,
>  };
> 
> -static struct s5p_mfc_buf_size buf_size_v6 = {
> +static const struct s5p_mfc_buf_size buf_size_v6 = {
>  	.fw	= MAX_FW_SIZE_V6,
>  	.cpb	= MAX_CPB_SIZE_V6,
>  	.priv	= &mfc_buf_size_v6,
> @@ -1569,7 +1569,7 @@ static struct s5p_mfc_variant mfc_drvdata_v6 = {
>  	.num_clocks	= 1,
>  };
> 
> -static struct s5p_mfc_buf_size_v6 mfc_buf_size_v7 = {
> +static const struct s5p_mfc_buf_size_v6 mfc_buf_size_v7 = {
>  	.dev_ctx	= MFC_CTX_BUF_SIZE_V7,
>  	.h264_dec_ctx	= MFC_H264_DEC_CTX_BUF_SIZE_V7,
>  	.other_dec_ctx	= MFC_OTHER_DEC_CTX_BUF_SIZE_V7,
> @@ -1577,7 +1577,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v7
> = {
>  	.other_enc_ctx	= MFC_OTHER_ENC_CTX_BUF_SIZE_V7,
>  };
> 
> -static struct s5p_mfc_buf_size buf_size_v7 = {
> +static const struct s5p_mfc_buf_size buf_size_v7 = {
>  	.fw	= MAX_FW_SIZE_V7,
>  	.cpb	= MAX_CPB_SIZE_V7,
>  	.priv	= &mfc_buf_size_v7,
> @@ -1603,7 +1603,7 @@ static struct s5p_mfc_variant mfc_drvdata_v7_3250
> = {
>  	.num_clocks     = 2,
>  };
> 
> -static struct s5p_mfc_buf_size_v6 mfc_buf_size_v8 = {
> +static const struct s5p_mfc_buf_size_v6 mfc_buf_size_v8 = {
>  	.dev_ctx	= MFC_CTX_BUF_SIZE_V8,
>  	.h264_dec_ctx	= MFC_H264_DEC_CTX_BUF_SIZE_V8,
>  	.other_dec_ctx	= MFC_OTHER_DEC_CTX_BUF_SIZE_V8,
> @@ -1611,7 +1611,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v8
> = {
>  	.other_enc_ctx	= MFC_OTHER_ENC_CTX_BUF_SIZE_V8,
>  };
> 
> -static struct s5p_mfc_buf_size buf_size_v8 = {
> +static const struct s5p_mfc_buf_size buf_size_v8 = {
>  	.fw	= MAX_FW_SIZE_V8,
>  	.cpb	= MAX_CPB_SIZE_V8,
>  	.priv	= &mfc_buf_size_v8,
> @@ -1637,7 +1637,7 @@ static struct s5p_mfc_variant mfc_drvdata_v8_5433
> = {
>  	.num_clocks	= 3,
>  };
> 
> -static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
> +static const struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
>  	.dev_ctx        = MFC_CTX_BUF_SIZE_V10,
>  	.h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
>  	.other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10, @@ -
> 1646,7 +1646,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
>  	.other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,  };
> 
> -static struct s5p_mfc_buf_size buf_size_v10 = {
> +static const struct s5p_mfc_buf_size buf_size_v10 = {
>  	.fw     = MAX_FW_SIZE_V10,
>  	.cpb    = MAX_CPB_SIZE_V10,
>  	.priv   = &mfc_buf_size_v10,
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
> index f8588e52dfc8..25c4719a5dd0 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -32,7 +32,7 @@ static int s5p_mfc_cmd_host2risc_v6(struct
> s5p_mfc_dev *dev, int cmd,  static int s5p_mfc_sys_init_cmd_v6(struct
> s5p_mfc_dev *dev)  {
>  	struct s5p_mfc_cmd_args h2r_args;
> -	struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size-
> >priv;
> +	const struct s5p_mfc_buf_size_v6 *buf_size =
> +dev->variant->buf_size->priv;
>  	int ret;
> 
>  	ret = s5p_mfc_hw_call(dev->mfc_ops, alloc_dev_context_buffer,
> dev); diff --git a/drivers/media/platform/samsung/s5p-
> mfc/s5p_mfc_common.h b/drivers/media/platform/samsung/s5p-
> mfc/s5p_mfc_common.h
> index f33a755327ef..6a47f3434c60 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> @@ -219,14 +219,14 @@ struct s5p_mfc_buf_size_v6 {  struct
> s5p_mfc_buf_size {
>  	unsigned int fw;
>  	unsigned int cpb;
> -	void *priv;
> +	const void *priv;
>  };
> 
>  struct s5p_mfc_variant {
>  	unsigned int version;
>  	unsigned int port_num;
>  	u32 version_bit;
> -	struct s5p_mfc_buf_size *buf_size;
> +	const struct s5p_mfc_buf_size *buf_size;
>  	const char	*fw_name[MFC_FW_MAX_VERSIONS];
>  	const char	*clk_names[MFC_MAX_CLOCKS];
>  	int		num_clocks;
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> index 268ffe4da53c..4dbe8792ac3d 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> @@ -426,7 +426,7 @@ static int vidioc_s_fmt(struct file *file, void *priv,
> struct v4l2_format *f)
>  	struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
>  	int ret = 0;
>  	struct v4l2_pix_format_mplane *pix_mp;
> -	struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
> +	const struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
> 
>  	mfc_debug_enter();
>  	ret = vidioc_try_fmt(file, priv, f);
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
> index 28a06dc343fd..13a3ff55e547 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
> @@ -34,7 +34,7 @@
>  static int s5p_mfc_alloc_dec_temp_buffers_v5(struct s5p_mfc_ctx *ctx)  {
>  	struct s5p_mfc_dev *dev = ctx->dev;
> -	struct s5p_mfc_buf_size_v5 *buf_size = dev->variant->buf_size-
> >priv;
> +	const struct s5p_mfc_buf_size_v5 *buf_size =
> +dev->variant->buf_size->priv;
>  	int ret;
> 
>  	ctx->dsc.size = buf_size->dsc;
> @@ -200,7 +200,7 @@ static void s5p_mfc_release_codec_buffers_v5(struct
> s5p_mfc_ctx *ctx)  static int s5p_mfc_alloc_instance_buffer_v5(struct
> s5p_mfc_ctx *ctx)  {
>  	struct s5p_mfc_dev *dev = ctx->dev;
> -	struct s5p_mfc_buf_size_v5 *buf_size = dev->variant->buf_size-
> >priv;
> +	const struct s5p_mfc_buf_size_v5 *buf_size =
> +dev->variant->buf_size->priv;
>  	int ret;
> 
>  	if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC || @@ -345,7
> +345,7 @@ static void s5p_mfc_enc_calc_src_size_v5(struct s5p_mfc_ctx
> *ctx)  static void s5p_mfc_set_dec_desc_buffer(struct s5p_mfc_ctx *ctx)  {
>  	struct s5p_mfc_dev *dev = ctx->dev;
> -	struct s5p_mfc_buf_size_v5 *buf_size = dev->variant->buf_size-
> >priv;
> +	const struct s5p_mfc_buf_size_v5 *buf_size =
> +dev->variant->buf_size->priv;
> 
>  	mfc_write(dev, OFFSETA(ctx->dsc.dma),
> S5P_FIMV_SI_CH0_DESC_ADR);
>  	mfc_write(dev, buf_size->dsc, S5P_FIMV_SI_CH0_DESC_SIZE); diff --
> git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
> index c0df5ac9fcff..70a62400908e 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -333,7 +333,7 @@ static void s5p_mfc_release_codec_buffers_v6(struct
> s5p_mfc_ctx *ctx)  static int s5p_mfc_alloc_instance_buffer_v6(struct
> s5p_mfc_ctx *ctx)  {
>  	struct s5p_mfc_dev *dev = ctx->dev;
> -	struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size-
> >priv;
> +	const struct s5p_mfc_buf_size_v6 *buf_size =
> +dev->variant->buf_size->priv;
>  	int ret;
> 
>  	mfc_debug_enter();
> @@ -393,7 +393,7 @@ static void
> s5p_mfc_release_instance_buffer_v6(struct s5p_mfc_ctx *ctx)
>  /* Allocate context buffers for SYS_INIT */  static int
> s5p_mfc_alloc_dev_context_buffer_v6(struct s5p_mfc_dev *dev)  {
> -	struct s5p_mfc_buf_size_v6 *buf_size = dev->variant->buf_size-
> >priv;
> +	const struct s5p_mfc_buf_size_v6 *buf_size =
> +dev->variant->buf_size->priv;
>  	int ret;
> 
>  	mfc_debug_enter();
> @@ -493,7 +493,7 @@ static int s5p_mfc_set_dec_stream_buffer_v6(struct
> s5p_mfc_ctx *ctx,  {
>  	struct s5p_mfc_dev *dev = ctx->dev;
>  	const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
> -	struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
> +	const struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
> 
>  	mfc_debug_enter();
>  	mfc_debug(2, "inst_no: %d, buf_addr: 0x%08x,\n"
> 
> --
> 2.34.1

Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Thanks!



From aakarsh.jain at samsung.com  Mon Dec 25 21:44:59 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Tue, 26 Dec 2023 11:14:59 +0530
Subject: [PATCH 06/15] media: s5p-mfc: constify s5p_mfc_variant
 structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-6-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
	<CGME20231224154442epcas5p229ceb7d1000dd0949b89cded46d73bb7@epcas5p2.samsung.com>
	<20231224-n-s5p-mfc-const-v1-6-a3b246470fe4@linaro.org>
Message-ID: <15d201da37be$abae6d20$030b4760$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: 24 December 2023 21:14
> To: Marek Szyprowski <m.szyprowski at samsung.com>; Andrzej Hajda
> <andrzej.hajda at intel.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>
> Cc: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-fsd at tesla.coma; linux-
> samsung-soc at vger.kernel.org; Smitha T Murthy
> <smithatmurthy at gmail.com>; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org; linux-kernel at vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>
> Subject: [PATCH 06/15] media: s5p-mfc: constify s5p_mfc_variant structures
> 
> Static "s5p_mfc_variant" structures are not modified by the driver, so they
> can be made const for code safety.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> index 6af7b812c5df..5d10c1cb8b92 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> @@ -1529,7 +1529,7 @@ static const struct s5p_mfc_buf_size buf_size_v5 =
> {
>  	.priv	= &mfc_buf_size_v5,
>  };
> 
> -static struct s5p_mfc_variant mfc_drvdata_v5 = {
> +static const struct s5p_mfc_variant mfc_drvdata_v5 = {
>  	.version	= MFC_VERSION,
>  	.version_bit	= MFC_V5_BIT,
>  	.port_num	= MFC_NUM_PORTS,
> @@ -1554,7 +1554,7 @@ static const struct s5p_mfc_buf_size buf_size_v6 =
> {
>  	.priv	= &mfc_buf_size_v6,
>  };
> 
> -static struct s5p_mfc_variant mfc_drvdata_v6 = {
> +static const struct s5p_mfc_variant mfc_drvdata_v6 = {
>  	.version	= MFC_VERSION_V6,
>  	.version_bit	= MFC_V6_BIT,
>  	.port_num	= MFC_NUM_PORTS_V6,
> @@ -1583,7 +1583,7 @@ static const struct s5p_mfc_buf_size buf_size_v7 =
> {
>  	.priv	= &mfc_buf_size_v7,
>  };
> 
> -static struct s5p_mfc_variant mfc_drvdata_v7 = {
> +static const struct s5p_mfc_variant mfc_drvdata_v7 = {
>  	.version	= MFC_VERSION_V7,
>  	.version_bit	= MFC_V7_BIT,
>  	.port_num	= MFC_NUM_PORTS_V7,
> @@ -1593,7 +1593,7 @@ static struct s5p_mfc_variant mfc_drvdata_v7 = {
>  	.num_clocks	= 1,
>  };
> 
> -static struct s5p_mfc_variant mfc_drvdata_v7_3250 = {
> +static const struct s5p_mfc_variant mfc_drvdata_v7_3250 = {
>  	.version        = MFC_VERSION_V7,
>  	.version_bit    = MFC_V7_BIT,
>  	.port_num       = MFC_NUM_PORTS_V7,
> @@ -1617,7 +1617,7 @@ static const struct s5p_mfc_buf_size buf_size_v8 =
> {
>  	.priv	= &mfc_buf_size_v8,
>  };
> 
> -static struct s5p_mfc_variant mfc_drvdata_v8 = {
> +static const struct s5p_mfc_variant mfc_drvdata_v8 = {
>  	.version	= MFC_VERSION_V8,
>  	.version_bit	= MFC_V8_BIT,
>  	.port_num	= MFC_NUM_PORTS_V8,
> @@ -1627,7 +1627,7 @@ static struct s5p_mfc_variant mfc_drvdata_v8 = {
>  	.num_clocks	= 1,
>  };
> 
> -static struct s5p_mfc_variant mfc_drvdata_v8_5433 = {
> +static const struct s5p_mfc_variant mfc_drvdata_v8_5433 = {
>  	.version	= MFC_VERSION_V8,
>  	.version_bit	= MFC_V8_BIT,
>  	.port_num	= MFC_NUM_PORTS_V8,
> @@ -1652,7 +1652,7 @@ static const struct s5p_mfc_buf_size buf_size_v10
> = {
>  	.priv   = &mfc_buf_size_v10,
>  };
> 
> -static struct s5p_mfc_variant mfc_drvdata_v10 = {
> +static const struct s5p_mfc_variant mfc_drvdata_v10 = {
>  	.version        = MFC_VERSION_V10,
>  	.version_bit    = MFC_V10_BIT,
>  	.port_num       = MFC_NUM_PORTS_V10,
> 
> --
> 2.34.1

Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Thanks!



From ck.hu at mediatek.com  Mon Dec 25 22:15:18 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 06:15:18 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <8234222df9443008db31158bfb7f203da9d5b4f0.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +
> +static void cmdq_sec_task_exec_work(struct work_struct *work_item)
> +{
> +	struct cmdq_sec_task *sec_task = container_of(work_item,
> +						      struct
> cmdq_sec_task, exec_work);
> +	struct cmdq_sec_thread *sec_thread = container_of(sec_task-
> >task.thread,
> +							 struct
> cmdq_sec_thread, thread);
> +	struct cmdq_sec *cmdq = container_of(sec_thread->thread.chan-
> >mbox,
> +					     struct cmdq_sec, mbox);
> +	struct cmdq_sec_data *data;
> +	unsigned long flags;
> +	int err;
> +
> +	dev_dbg(cmdq->mbox.dev, "%s gce:%#lx sec_task:%p pkt:%p
> thread:%u",
> +		__func__, (unsigned long)cmdq->base_pa,
> +		sec_task, sec_task->task.pkt, sec_thread->idx);
> +
> +	if (!sec_task->task.pkt->sec_data) {
> +		dev_err(cmdq->mbox.dev, "pkt:%p without sec_data",
> sec_task->task.pkt);
> +		return;
> +	}
> +	data = (struct cmdq_sec_data *)sec_task->task.pkt->sec_data;
> +
> +	mutex_lock(&cmdq->exec_lock);
> +
> +	spin_lock_irqsave(&sec_thread->thread.chan->lock, flags);
> +	if (!sec_thread->task_cnt) {
> +		mod_timer(&sec_thread->timeout, jiffies +
> +			  msecs_to_jiffies(sec_thread->timeout_ms));
> +		sec_thread->wait_cookie = 1;
> +		sec_thread->next_cookie = 1;
> +		sec_thread->task_cnt = 0;
> +		__raw_writel(0, (void __iomem *)cmdq->shared_mem->va +
> +			     CMDQ_SEC_SHARED_THR_CNT_OFFSET +
> sec_thread->idx * sizeof(u32));
> +	}
> +
> +	sec_task->reset_exec = sec_thread->task_cnt ? false : true;
> +	sec_task->wait_cookie = sec_thread->next_cookie;
> +	sec_thread->next_cookie = (sec_thread->next_cookie + 1) %
> CMDQ_MAX_COOKIE_VALUE;
> +	list_add_tail(&sec_task->task.list_entry, &sec_thread-
> >thread.task_busy_list);
> +	sec_thread->task_cnt += 1;
> +	spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
> +	sec_task->trigger = sched_clock();
> +
> +	if (!atomic_cmpxchg(&cmdq_path_res, 0, 1)) {
> +		err = cmdq_sec_task_submit(cmdq, NULL,
> CMD_CMDQ_IWC_PATH_RES_ALLOCATE,
> +					   CMDQ_INVALID_THREAD, NULL);
> +		if (err) {
> +			atomic_set(&cmdq_path_res, 0);
> +			goto task_end;
> +		}
> +	}
> +
> +	if (sec_thread->task_cnt > CMDQ_MAX_TASK_IN_SECURE_THREAD) {
> +		dev_err(cmdq->mbox.dev, "task_cnt:%u cannot more than
> %u sec_task:%p thread:%u",
> +			sec_thread->task_cnt,
> CMDQ_MAX_TASK_IN_SECURE_THREAD,
> +			sec_task, sec_thread->idx);
> +		err = -EMSGSIZE;
> +		goto task_end;
> +	}
> +
> +	err = cmdq_sec_task_submit(cmdq, sec_task,
> CMD_CMDQ_IWC_SUBMIT_TASK,
> +				   sec_thread->idx, NULL);
> +	if (err)
> +		dev_err(cmdq->mbox.dev, "cmdq_sec_task_submit err:%d
> sec_task:%p thread:%u",
> +			err, sec_task, sec_thread->idx);
> +
> +task_end:
> +	if (err) {
> +		struct cmdq_cb_data cb_data;
> +
> +		cb_data.sta = err;
> +		cb_data.pkt = sec_task->task.pkt;
> +		mbox_chan_received_data(sec_thread->thread.chan,
> &cb_data);
> +
> +		spin_lock_irqsave(&sec_thread->thread.chan->lock,
> flags);
> +		if (!sec_thread->task_cnt)
> +			dev_err(cmdq->mbox.dev, "thread:%u task_cnt:%u
> cannot below zero",
> +				sec_thread->idx, sec_thread->task_cnt);
> +		else
> +			sec_thread->task_cnt -= 1;
> +
> +		sec_thread->next_cookie = (sec_thread->next_cookie - 1
> +
> +			CMDQ_MAX_COOKIE_VALUE) % CMDQ_MAX_COOKIE_VALUE;
> +		list_del(&sec_task->task.list_entry);
> +		dev_dbg(cmdq->mbox.dev, "gce:%#lx err:%d sec_task:%p
> pkt:%p",
> +			(unsigned long)cmdq->base_pa, err, sec_task,
> sec_task->task.pkt);
> +		dev_dbg(cmdq->mbox.dev, "thread:%u task_cnt:%u
> wait_cookie:%u next_cookie:%u",
> +			sec_thread->idx, sec_thread->task_cnt,
> +			sec_thread->wait_cookie, sec_thread-
> >next_cookie);
> +		spin_unlock_irqrestore(&sec_thread->thread.chan->lock,
> flags);
> +
> +		kfree(sec_task);
> +	}
> +
> +	mutex_unlock(&cmdq->exec_lock);
> +}
> +
> +static int cmdq_sec_mbox_send_data(struct mbox_chan *chan, void
> *data)
> +{
> +	struct cmdq_pkt *pkt = (struct cmdq_pkt *)data;
> +	struct cmdq_sec_data *sec_data = (struct cmdq_sec_data *)pkt-
> >sec_data;
> +	struct cmdq_thread *thread = (struct cmdq_thread *)chan-
> >con_priv;
> +	struct cmdq_sec_thread *sec_thread = container_of(thread,
> struct cmdq_sec_thread, thread);
> +	struct cmdq_sec_task *sec_task;
> +
> +	if (!sec_data)
> +		return -EINVAL;
> +
> +	sec_task = kzalloc(sizeof(*sec_task), GFP_ATOMIC);
> +	if (!sec_task)
> +		return -ENOMEM;
> +
> +	sec_task->task.pkt = pkt;
> +	sec_task->task.thread = thread;
> +	sec_task->scenario = sec_data->scenario;
> +	sec_task->engine_flag = sec_data->engs_need_dapc | sec_data-
> >engs_need_sec_port;
> +
> +	INIT_WORK(&sec_task->exec_work, cmdq_sec_task_exec_work);
> +	queue_work(sec_thread->task_exec_wq, &sec_task->exec_work);

It's not necessary to queue a work here. Squash
cmdq_sec_task_exec_work() into this function.

Regards,
CK


> +	return 0;
> +}
> +

From aakarsh.jain at samsung.com  Mon Dec 25 22:21:48 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Tue, 26 Dec 2023 11:51:48 +0530
Subject: [PATCH 15/15] media: s5p-mfc: drop static device variable in
 s5p_mfc_pm.c
In-Reply-To: <20231224-n-s5p-mfc-const-v1-15-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
	<CGME20231224154454epcas5p311d2b74fb1809bb555a442d1bce82edb@epcas5p3.samsung.com>
	<20231224-n-s5p-mfc-const-v1-15-a3b246470fe4@linaro.org>
Message-ID: <15d301da37c3$cff325e0$6fd971a0$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: 24 December 2023 21:14
> To: Marek Szyprowski <m.szyprowski at samsung.com>; Andrzej Hajda
> <andrzej.hajda at intel.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>
> Cc: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-fsd at tesla.coma; linux-
> samsung-soc at vger.kernel.org; Smitha T Murthy
> <smithatmurthy at gmail.com>; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org; linux-kernel at vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>
> Subject: [PATCH 15/15] media: s5p-mfc: drop static device variable in
> s5p_mfc_pm.c
> 
> Change the interface of power management functions in s5p_mfc_pm.c to
> accept the pointer to S5P MFC device structure. instead of relying on file-
> scope static variable.  This makes code easier to read and modify in case
> more devices are added.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c   | 42 +++++++++++---
> --------
>  .../media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c  | 26 +++++++-------
>  .../media/platform/samsung/s5p-mfc/s5p_mfc_dec.c   |  8 ++---
>  .../platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c      |  4 +--
>  .../platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c      |  8 ++---
>  .../media/platform/samsung/s5p-mfc/s5p_mfc_pm.c    | 40 ++++++++++----
> -------
>  .../media/platform/samsung/s5p-mfc/s5p_mfc_pm.h    |  8 ++---
>  7 files changed, 67 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> index 5d10c1cb8b92..f0bda2f7f1c2 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> @@ -183,7 +183,7 @@ static void s5p_mfc_watchdog_worker(struct
> work_struct *work)
>  		mfc_err("Error: some instance may be closing/opening\n");
>  	spin_lock_irqsave(&dev->irqlock, flags);
> 
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
> 
>  	for (i = 0; i < MFC_NUM_CONTEXTS; i++) {
>  		ctx = dev->ctx[i];
> @@ -211,9 +211,9 @@ static void s5p_mfc_watchdog_worker(struct
> work_struct *work)
>  			mfc_err("Failed to reload FW\n");
>  			goto unlock;
>  		}
> -		s5p_mfc_clock_on();
> +		s5p_mfc_clock_on(dev);
>  		ret = s5p_mfc_init_hw(dev);
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  		if (ret)
>  			mfc_err("Failed to reinit FW\n");
>  	}
> @@ -393,7 +393,7 @@ static void s5p_mfc_handle_frame(struct
> s5p_mfc_ctx *ctx,
>  		s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
>  		wake_up_ctx(ctx, reason, err);
>  		WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  		s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
>  		return;
>  	}
> @@ -465,7 +465,7 @@ static void s5p_mfc_handle_frame(struct
> s5p_mfc_ctx *ctx,
>  	s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
>  	wake_up_ctx(ctx, reason, err);
>  	WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	/* if suspending, wake up device and do not try_run again*/
>  	if (test_bit(0, &dev->enter_suspend))
>  		wake_up_dev(dev, reason, err);
> @@ -509,7 +509,7 @@ static void s5p_mfc_handle_error(struct
> s5p_mfc_dev *dev,
>  	}
>  	WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
>  	s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	wake_up_dev(dev, reason, err);
>  }
> 
> @@ -565,7 +565,7 @@ static void s5p_mfc_handle_seq_done(struct
> s5p_mfc_ctx *ctx,
>  	s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
>  	clear_work_bit(ctx);
>  	WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
>  	wake_up_ctx(ctx, reason, err);
>  }
> @@ -601,14 +601,14 @@ static void s5p_mfc_handle_init_buffers(struct
> s5p_mfc_ctx *ctx,
>  		}
>  		WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
> 
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
> 
>  		wake_up(&ctx->queue);
>  		s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
>  	} else {
>  		WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
> 
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
> 
>  		wake_up(&ctx->queue);
>  	}
> @@ -636,7 +636,7 @@ static void s5p_mfc_handle_stream_complete(struct
> s5p_mfc_ctx *ctx)
> 
>  	WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0);
> 
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	wake_up(&ctx->queue);
>  	s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);  } @@ -688,7 +688,7
> @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
>  			}
>  			s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags,
> dev);
>  			WARN_ON(test_and_clear_bit(0, &dev->hw_lock)
> == 0);
> -			s5p_mfc_clock_off();
> +			s5p_mfc_clock_off(dev);
>  			wake_up_ctx(ctx, reason, err);
>  			s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
>  		} else {
> @@ -752,7 +752,7 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
>  	if (test_and_clear_bit(0, &dev->hw_lock) == 0)
>  		mfc_err("Failed to unlock hw\n");
> 
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	clear_work_bit(ctx);
>  	wake_up(&ctx->queue);
> 
> @@ -837,20 +837,20 @@ static int s5p_mfc_open(struct file *file)
>  		dev->watchdog_timer.expires = jiffies +
> 
> 	msecs_to_jiffies(MFC_WATCHDOG_INTERVAL);
>  		add_timer(&dev->watchdog_timer);
> -		ret = s5p_mfc_power_on();
> +		ret = s5p_mfc_power_on(dev);
>  		if (ret < 0) {
>  			mfc_err("power on failed\n");
>  			goto err_pwr_enable;
>  		}
> -		s5p_mfc_clock_on();
> +		s5p_mfc_clock_on(dev);
>  		ret = s5p_mfc_load_firmware(dev);
>  		if (ret) {
> -			s5p_mfc_clock_off();
> +			s5p_mfc_clock_off(dev);
>  			goto err_load_fw;
>  		}
>  		/* Init the FW */
>  		ret = s5p_mfc_init_hw(dev);
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  		if (ret)
>  			goto err_init_hw;
>  	}
> @@ -927,7 +927,7 @@ static int s5p_mfc_open(struct file *file)
>  err_load_fw:
>  err_pwr_enable:
>  	if (dev->num_inst == 1) {
> -		if (s5p_mfc_power_off() < 0)
> +		if (s5p_mfc_power_off(dev) < 0)
>  			mfc_err("power off failed\n");
>  		del_timer_sync(&dev->watchdog_timer);
>  	}
> @@ -959,7 +959,7 @@ static int s5p_mfc_release(struct file *file)
>  	vb2_queue_release(&ctx->vq_src);
>  	vb2_queue_release(&ctx->vq_dst);
>  	if (dev) {
> -		s5p_mfc_clock_on();
> +		s5p_mfc_clock_on(dev);
> 
>  		/* Mark context as idle */
>  		clear_work_bit_irqsave(ctx);
> @@ -979,12 +979,12 @@ static int s5p_mfc_release(struct file *file)
>  			mfc_debug(2, "Last instance\n");
>  			s5p_mfc_deinit_hw(dev);
>  			del_timer_sync(&dev->watchdog_timer);
> -			s5p_mfc_clock_off();
> -			if (s5p_mfc_power_off() < 0)
> +			s5p_mfc_clock_off(dev);
> +			if (s5p_mfc_power_off(dev) < 0)
>  				mfc_err("Power off failed\n");
>  		} else {
>  			mfc_debug(2, "Shutting down clock\n");
> -			s5p_mfc_clock_off();
> +			s5p_mfc_clock_off(dev);
>  		}
>  	}
>  	if (dev)
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> index 6d3c92045c05..8eedf6524c39 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_ctrl.c
> @@ -215,7 +215,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
> 
>  	/* 0. MFC reset */
>  	mfc_debug(2, "MFC reset..\n");
> -	s5p_mfc_clock_on();
> +	s5p_mfc_clock_on(dev);
>  	dev->risc_on = 0;
>  	ret = s5p_mfc_reset(dev);
>  	if (ret) {
> @@ -243,7 +243,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
>  	if (s5p_mfc_wait_for_done_dev(dev,
> S5P_MFC_R2H_CMD_FW_STATUS_RET)) {
>  		mfc_err("Failed to load firmware\n");
>  		s5p_mfc_reset(dev);
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  		return -EIO;
>  	}
>  	s5p_mfc_clean_dev_int_flags(dev);
> @@ -252,14 +252,14 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
>  	if (ret) {
>  		mfc_err("Failed to send command to MFC - timeout\n");
>  		s5p_mfc_reset(dev);
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  		return ret;
>  	}
>  	mfc_debug(2, "Ok, now will wait for completion of hardware init\n");
>  	if (s5p_mfc_wait_for_done_dev(dev,
> S5P_MFC_R2H_CMD_SYS_INIT_RET)) {
>  		mfc_err("Failed to init hardware\n");
>  		s5p_mfc_reset(dev);
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  		return -EIO;
>  	}
>  	dev->int_cond = 0;
> @@ -269,7 +269,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
>  		mfc_err("Failed to init firmware - error: %d int: %d\n",
>  						dev->int_err, dev->int_type);
>  		s5p_mfc_reset(dev);
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  		return -EIO;
>  	}
>  	if (IS_MFCV6_PLUS(dev))
> @@ -279,7 +279,7 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
> 
>  	mfc_debug(2, "MFC F/W version : %02xyy, %02xmm, %02xdd\n",
>  		(ver >> 16) & 0xFF, (ver >> 8) & 0xFF, ver & 0xFF);
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	mfc_debug_leave();
>  	return 0;
>  }
> @@ -288,12 +288,12 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
>  /* Deinitialize hardware */
>  void s5p_mfc_deinit_hw(struct s5p_mfc_dev *dev)  {
> -	s5p_mfc_clock_on();
> +	s5p_mfc_clock_on(dev);
> 
>  	s5p_mfc_reset(dev);
>  	s5p_mfc_hw_call(dev->mfc_ops, release_dev_context_buffer,
> dev);
> 
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  }
> 
>  int s5p_mfc_sleep(struct s5p_mfc_dev *dev) @@ -301,7 +301,7 @@ int
> s5p_mfc_sleep(struct s5p_mfc_dev *dev)
>  	int ret;
> 
>  	mfc_debug_enter();
> -	s5p_mfc_clock_on();
> +	s5p_mfc_clock_on(dev);
>  	s5p_mfc_clean_dev_int_flags(dev);
>  	ret = s5p_mfc_hw_call(dev->mfc_cmds, sleep_cmd, dev);
>  	if (ret) {
> @@ -312,7 +312,7 @@ int s5p_mfc_sleep(struct s5p_mfc_dev *dev)
>  		mfc_err("Failed to sleep\n");
>  		return -EIO;
>  	}
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	dev->int_cond = 0;
>  	if (dev->int_err != 0 || dev->int_type !=
> 
> 	S5P_MFC_R2H_CMD_SLEEP_RET) {
> @@ -384,12 +384,12 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
>  	mfc_debug_enter();
>  	/* 0. MFC reset */
>  	mfc_debug(2, "MFC reset..\n");
> -	s5p_mfc_clock_on();
> +	s5p_mfc_clock_on(dev);
>  	dev->risc_on = 0;
>  	ret = s5p_mfc_reset(dev);
>  	if (ret) {
>  		mfc_err("Failed to reset MFC - timeout\n");
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  		return ret;
>  	}
>  	mfc_debug(2, "Done MFC reset..\n");
> @@ -404,7 +404,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
>  	else
>  		ret = s5p_mfc_wait_wakeup(dev);
> 
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	if (ret)
>  		return ret;
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> index eef26d4e02cf..b620db8896e1 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> @@ -477,7 +477,7 @@ static int reqbufs_output(struct s5p_mfc_dev *dev,
> struct s5p_mfc_ctx *ctx,  {
>  	int ret = 0;
> 
> -	s5p_mfc_clock_on();
> +	s5p_mfc_clock_on(dev);
> 
>  	if (reqbufs->count == 0) {
>  		mfc_debug(2, "Freeing buffers\n");
> @@ -514,7 +514,7 @@ static int reqbufs_output(struct s5p_mfc_dev *dev,
> struct s5p_mfc_ctx *ctx,
>  		ret = -EINVAL;
>  	}
>  out:
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	if (ret)
>  		mfc_err("Failed allocating buffers for OUTPUT queue\n");
>  	return ret;
> @@ -525,7 +525,7 @@ static int reqbufs_capture(struct s5p_mfc_dev *dev,
> struct s5p_mfc_ctx *ctx,  {
>  	int ret = 0;
> 
> -	s5p_mfc_clock_on();
> +	s5p_mfc_clock_on(dev);
> 
>  	if (reqbufs->count == 0) {
>  		mfc_debug(2, "Freeing buffers\n");
> @@ -568,7 +568,7 @@ static int reqbufs_capture(struct s5p_mfc_dev *dev,
> struct s5p_mfc_ctx *ctx,
>  		ret = -EINVAL;
>  	}
>  out:
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(dev);
>  	if (ret)
>  		mfc_err("Failed allocating buffers for CAPTURE queue\n");
>  	return ret;
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
> index ba22c6a3219a..87492db83536 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v5.c
> @@ -1346,7 +1346,7 @@ static void s5p_mfc_try_run_v5(struct
> s5p_mfc_dev *dev)
>  	 * Last frame has already been sent to MFC.
>  	 * Now obtaining frames from MFC buffer
>  	 */
> -	s5p_mfc_clock_on();
> +	s5p_mfc_clock_on(dev);
>  	s5p_mfc_clean_ctx_int_flags(ctx);
> 
>  	if (ctx->type == MFCINST_DECODER) {
> @@ -1422,7 +1422,7 @@ static void s5p_mfc_try_run_v5(struct
> s5p_mfc_dev *dev)
>  		 * scheduled, reduce the clock count as no one will
>  		 * ever do this, because no interrupt related to this try_run
>  		 * will ever come from hardware. */
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  	}
>  }
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
> index 08545213caa9..8908c159a91e 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -1992,7 +1992,7 @@ static void s5p_mfc_try_run_v6(struct
> s5p_mfc_dev *dev)
>  	/* Last frame has already been sent to MFC
>  	 * Now obtaining frames from MFC buffer */
> 
> -	s5p_mfc_clock_on();
> +	s5p_mfc_clock_on(dev);
>  	s5p_mfc_clean_ctx_int_flags(ctx);
> 
>  	if (ctx->type == MFCINST_DECODER) {
> @@ -2072,7 +2072,7 @@ static void s5p_mfc_try_run_v6(struct
> s5p_mfc_dev *dev)
>  		 * scheduled, reduce the clock count as no one will
>  		 * ever do this, because no interrupt related to this try_run
>  		 * will ever come from hardware. */
> -		s5p_mfc_clock_off();
> +		s5p_mfc_clock_off(dev);
>  	}
>  }
> 
> @@ -2088,9 +2088,9 @@ s5p_mfc_read_info_v6(struct s5p_mfc_ctx *ctx,
> unsigned long ofs)  {
>  	int ret;
> 
> -	s5p_mfc_clock_on();
> +	s5p_mfc_clock_on(ctx->dev);
>  	ret = readl((void __iomem *)ofs);
> -	s5p_mfc_clock_off();
> +	s5p_mfc_clock_off(ctx->dev);
> 
>  	return ret;
>  }
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
> index ecb3065c33c9..ae4241408383 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.c
> @@ -14,13 +14,11 @@
>  #include "s5p_mfc_debug.h"
>  #include "s5p_mfc_pm.h"
> 
> -static struct s5p_mfc_pm *pm;
> -
>  int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)  {
> +	struct s5p_mfc_pm *pm = &dev->pm;
>  	int i;
> 
> -	pm = &dev->pm;
>  	pm->num_clocks = dev->variant->num_clocks;
>  	pm->clk_names = dev->variant->clk_names;
>  	pm->device = &dev->plat_dev->dev;
> @@ -50,58 +48,58 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
> 
>  void s5p_mfc_final_pm(struct s5p_mfc_dev *dev)  {
> -	pm_runtime_disable(pm->device);
> +	pm_runtime_disable(dev->pm.device);
>  }
> 
> -int s5p_mfc_clock_on(void)
> +int s5p_mfc_clock_on(struct s5p_mfc_dev *dev)
>  {
> -	return clk_enable(pm->clock_gate);
> +	return clk_enable(dev->pm.clock_gate);
>  }
> 
> -void s5p_mfc_clock_off(void)
> +void s5p_mfc_clock_off(struct s5p_mfc_dev *dev)
>  {
> -	clk_disable(pm->clock_gate);
> +	clk_disable(dev->pm.clock_gate);
>  }
> 
> -int s5p_mfc_power_on(void)
> +int s5p_mfc_power_on(struct s5p_mfc_dev *dev)
>  {
>  	int i, ret = 0;
> 
> -	ret = pm_runtime_resume_and_get(pm->device);
> +	ret = pm_runtime_resume_and_get(dev->pm.device);
>  	if (ret < 0)
>  		return ret;
> 
>  	/* clock control */
> -	for (i = 0; i < pm->num_clocks; i++) {
> -		ret = clk_prepare_enable(pm->clocks[i]);
> +	for (i = 0; i < dev->pm.num_clocks; i++) {
> +		ret = clk_prepare_enable(dev->pm.clocks[i]);
>  		if (ret < 0) {
>  			mfc_err("clock prepare failed for clock: %s\n",
> -				pm->clk_names[i]);
> +				dev->pm.clk_names[i]);
>  			goto err;
>  		}
>  	}
> 
>  	/* prepare for software clock gating */
> -	clk_disable(pm->clock_gate);
> +	clk_disable(dev->pm.clock_gate);
> 
>  	return 0;
>  err:
>  	while (--i >= 0)
> -		clk_disable_unprepare(pm->clocks[i]);
> -	pm_runtime_put(pm->device);
> +		clk_disable_unprepare(dev->pm.clocks[i]);
> +	pm_runtime_put(dev->pm.device);
>  	return ret;
>  }
> 
> -int s5p_mfc_power_off(void)
> +int s5p_mfc_power_off(struct s5p_mfc_dev *dev)
>  {
>  	int i;
> 
>  	/* finish software clock gating */
> -	clk_enable(pm->clock_gate);
> +	clk_enable(dev->pm.clock_gate);
> 
> -	for (i = 0; i < pm->num_clocks; i++)
> -		clk_disable_unprepare(pm->clocks[i]);
> +	for (i = 0; i < dev->pm.num_clocks; i++)
> +		clk_disable_unprepare(dev->pm.clocks[i]);
> 
> -	return pm_runtime_put_sync(pm->device);
> +	return pm_runtime_put_sync(dev->pm.device);
>  }
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.h
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.h
> index 4159d2364e87..9c71036f0385 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.h
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_pm.h
> @@ -12,9 +12,9 @@
>  int s5p_mfc_init_pm(struct s5p_mfc_dev *dev);  void
> s5p_mfc_final_pm(struct s5p_mfc_dev *dev);
> 
> -int s5p_mfc_clock_on(void);
> -void s5p_mfc_clock_off(void);
> -int s5p_mfc_power_on(void);
> -int s5p_mfc_power_off(void);
> +int s5p_mfc_clock_on(struct s5p_mfc_dev *dev); void
> +s5p_mfc_clock_off(struct s5p_mfc_dev *dev); int
> s5p_mfc_power_on(struct
> +s5p_mfc_dev *dev); int s5p_mfc_power_off(struct s5p_mfc_dev *dev);
> 
>  #endif /* S5P_MFC_PM_H_ */
> 
> --
> 2.34.1

Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Thanks!



From aakarsh.jain at samsung.com  Mon Dec 25 22:27:53 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Tue, 26 Dec 2023 11:57:53 +0530
Subject: [PATCH 09/15] media: s5p-mfc: constify s5p_mfc_fmt structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-9-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
	<CGME20231224154446epcas5p2b08000b76b8a94063b164a55e5e8a999@epcas5p2.samsung.com>
	<20231224-n-s5p-mfc-const-v1-9-a3b246470fe4@linaro.org>
Message-ID: <15d401da37c4$a9dece80$fd9c6b80$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: 24 December 2023 21:14
> To: Marek Szyprowski <m.szyprowski at samsung.com>; Andrzej Hajda
> <andrzej.hajda at intel.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>
> Cc: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-fsd at tesla.coma; linux-
> samsung-soc at vger.kernel.org; Smitha T Murthy
> <smithatmurthy at gmail.com>; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org; linux-kernel at vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>
> Subject: [PATCH 09/15] media: s5p-mfc: constify s5p_mfc_fmt structures
> 
> Static "s5p_mfc_fmt" structures are not modified by the driver, so they can
> be made const for code safety.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h | 4 ++--
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c    | 6 +++---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c    | 8 ++++----
>  3 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> index fa556f27fa06..e9283020070e 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> @@ -633,8 +633,8 @@ struct s5p_mfc_ctx {
>  	unsigned int int_err;
>  	wait_queue_head_t queue;
> 
> -	struct s5p_mfc_fmt *src_fmt;
> -	struct s5p_mfc_fmt *dst_fmt;
> +	const struct s5p_mfc_fmt *src_fmt;
> +	const struct s5p_mfc_fmt *dst_fmt;
> 
>  	struct vb2_queue vq_src;
>  	struct vb2_queue vq_dst;
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> index 4dbe8792ac3d..2f664c7e9e4c 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_dec.c
> @@ -27,7 +27,7 @@
>  #include "s5p_mfc_opr.h"
>  #include "s5p_mfc_pm.h"
> 
> -static struct s5p_mfc_fmt formats[] = {
> +static const struct s5p_mfc_fmt formats[] = {
>  	{
>  		.fourcc		= V4L2_PIX_FMT_NV12MT_16X16,
>  		.codec_mode	= S5P_MFC_CODEC_NONE,
> @@ -163,7 +163,7 @@ static struct s5p_mfc_fmt formats[] = {  #define
> NUM_FORMATS ARRAY_SIZE(formats)
> 
>  /* Find selected format description */
> -static struct s5p_mfc_fmt *find_format(struct v4l2_format *f, unsigned int
> t)
> +static const struct s5p_mfc_fmt *find_format(struct v4l2_format *f,
> +unsigned int t)
>  {
>  	unsigned int i;
> 
> @@ -387,7 +387,7 @@ static int vidioc_g_fmt(struct file *file, void *priv,
> struct v4l2_format *f)  static int vidioc_try_fmt(struct file *file, void *priv,
> struct v4l2_format *f)  {
>  	struct s5p_mfc_dev *dev = video_drvdata(file);
> -	struct s5p_mfc_fmt *fmt;
> +	const struct s5p_mfc_fmt *fmt;
> 
>  	mfc_debug(2, "Type is %d\n", f->type);
>  	if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) { diff --git
> a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
> index 4b4c129c09e7..d6a4b9c701eb 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_enc.c
> @@ -30,7 +30,7 @@
>  #define DEF_SRC_FMT_ENC	V4L2_PIX_FMT_NV12M
>  #define DEF_DST_FMT_ENC	V4L2_PIX_FMT_H264
> 
> -static struct s5p_mfc_fmt formats[] = {
> +static const struct s5p_mfc_fmt formats[] = {
>  	{
>  		.fourcc		= V4L2_PIX_FMT_NV12MT_16X16,
>  		.codec_mode	= S5P_MFC_CODEC_NONE,
> @@ -97,7 +97,7 @@ static struct s5p_mfc_fmt formats[] = {  };
> 
>  #define NUM_FORMATS ARRAY_SIZE(formats) -static struct s5p_mfc_fmt
> *find_format(struct v4l2_format *f, unsigned int t)
> +static const struct s5p_mfc_fmt *find_format(struct v4l2_format *f,
> +unsigned int t)
>  {
>  	unsigned int i;
> 
> @@ -1394,7 +1394,7 @@ static int vidioc_g_fmt(struct file *file, void *priv,
> struct v4l2_format *f)  static int vidioc_try_fmt(struct file *file, void *priv,
> struct v4l2_format *f)  {
>  	struct s5p_mfc_dev *dev = video_drvdata(file);
> -	struct s5p_mfc_fmt *fmt;
> +	const struct s5p_mfc_fmt *fmt;
>  	struct v4l2_pix_format_mplane *pix_fmt_mp = &f->fmt.pix_mp;
> 
>  	if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) { @@ -
> 2355,7 +2355,7 @@ static const struct v4l2_ioctl_ops s5p_mfc_enc_ioctl_ops
> = {
>  	.vidioc_unsubscribe_event = v4l2_event_unsubscribe,  };
> 
> -static int check_vb_with_fmt(struct s5p_mfc_fmt *fmt, struct vb2_buffer
> *vb)
> +static int check_vb_with_fmt(const struct s5p_mfc_fmt *fmt, struct
> +vb2_buffer *vb)
>  {
>  	int i;
> 
> 
> --
> 2.34.1

Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Thanks!



From ck.hu at mediatek.com  Mon Dec 25 22:46:02 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 06:46:02 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <957c5ec4fe3a1ad6eb44df37bd68cfedfcb0b926.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +
> +static int cmdq_sec_session_init(struct cmdq_sec_context *context)
> +{
> +	int err = 0;
> +
> +	if (context->state >= IWC_SES_OPENED) {
> +		pr_debug("session opened:%u", context->state);
> +		return 0;
> +	}
> +
> +	switch (context->state) {
> +	case IWC_INIT:
> +		err = cmdq_sec_init_context(&context->tee_ctx);
> +		if (err)
> +			return err;
> +		context->state = IWC_CONTEXT_INITED;
> +	fallthrough;
> +	case IWC_CONTEXT_INITED:
> +		if (context->iwc_msg) {
> +			pr_err("iwcMessage not NULL:%p", context-
> >iwc_msg);
> +			return -EINVAL;
> +		}
> +
> +		err = cmdq_sec_allocate_wsm(&context->tee_ctx,
> &context->iwc_msg,
> +					    sizeof(struct
> iwc_cmdq_message_t));
> +		if (err)
> +			return err;
> +
> +		context->state = IWC_WSM_ALLOCATED;
> +	fallthrough;

Squash cmdq_sec_session_init() into cmdq_sec_mbox_of_xlate() and drop
the context->state.

Regards,
CK

> +	case IWC_WSM_ALLOCATED:
> +		err = cmdq_sec_open_session(&context->tee_ctx, context-
> >iwc_msg);
> +		if (err)
> +			return err;
> +
> +		context->state = IWC_SES_OPENED;
> +	fallthrough;
> +	default:
> +		break;
> +	}
> +
> +	return 0;
> +}
> +

From Yu-chang.Lee at mediatek.com  Mon Dec 25 22:56:39 2023
From: Yu-chang.Lee at mediatek.com (=?utf-8?B?WXUtY2hhbmcgTGVlICjmnY7nprnnkosp?=)
Date: Tue, 26 Dec 2023 06:56:39 +0000
Subject: Need help to validate power domain driver modification on mt8365
Message-ID: <d4445c168a15c03ebfe3bc88dc12b219f08a81d5.camel@mediatek.com>

Hi Markus,

Attachment 0003 is the proposal I make for the clamp protection issue
we last discussed and others are some dependency patch. Since smi has
have two type of protection but in different stage. So I eventually
decide to separate it. May you help test these patch on mt8365, I test
it a bit on mt8188 and it work fine. Still any advice and modification
are welcome!

SMI protection type
1. clamp 
2. bus protection

For example: power on 
"clamp protection enable" (smi, with clamp flag)
  -> regulator enable 
    ...
      -> clamp protection disaled (smi, with clamp flag)
        -> bus protection disabled (smi -> infra)

For example: power off
"clamp protection enable" (smi, with clamp flag)
  -> bus protection enable (infra -> smi)

Best Regards,
Yu-chang.lee
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-soc-mediatek-pm-domains-add-smi_larb_reset-function-.patch
Type: text/x-patch
Size: 6608 bytes
Desc: 0001-soc-mediatek-pm-domains-add-smi_larb_reset-function-.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231226/143cab04/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-soc-mediatek-pm-domains-Adding-back-buck-isolation-s.patch
Type: text/x-patch
Size: 1812 bytes
Desc: 0002-soc-mediatek-pm-domains-Adding-back-buck-isolation-s.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231226/143cab04/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-soc-mediatek-pm-domains-support-clamp-protection.patch
Type: text/x-patch
Size: 17954 bytes
Desc: 0003-soc-mediatek-pm-domains-support-clamp-protection.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231226/143cab04/attachment-0005.bin>

From jagan at amarulasolutions.com  Mon Dec 25 23:41:08 2023
From: jagan at amarulasolutions.com (Jagan Teki)
Date: Tue, 26 Dec 2023 13:11:08 +0530
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <20231222145100.sfcuux7ayxtxgogo@skbuf>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf>
Message-ID: <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>

On Fri, Dec 22, 2023 at 8:21?PM Vladimir Oltean <olteanv at gmail.com> wrote:
>
> On Wed, Dec 20, 2023 at 12:49:30PM +0530, Jagan Teki wrote:
> > [ 1255.021656] Modules linked in: mdio_netlink(O) bnep tag_sja1105 sja1105 pcs_xpcs brcmfmac brcmutil imx_sdma coda_vpu v4l2_jpeg imx_vdoa evbug
> > [ 1255.034578] CPU: 0 PID: 374 Comm: ip Tainted: G           O       6.1.58 #1
>
> Can you please reproduce the issue with no out-of-tree modules used
> (here mdio_netlink)?

root at imx6solo:~# ip link set dev eth0 down
root at imx6solo:~# ip link set dev ethphy0 down
root at imx6solo:~# ip link set dev ethphy1 down
root at imx6solo:~# ip link set dev ethphy0 address 00:11:22:33:44:55
root at imx6solo:~# ip link set dev ethphy1 address 00:11:22:33:44:66
root at imx6solo:~# ip addr add dev ethphy0 192.168.1.1/16
root at imx6solo:~# ip addr add dev ethphy1 192.168.1.5/16
root at imx6solo:~# ip link set dev eth0 up
[  617.126753] dp83848_config_init: ret 0
[  617.130831] TI DP83849I 10/100 Mbps PHY 2188000.ethernet-1:00:
attached PHY driver (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
root at imx6solo:~# [  619.207519] fec 2188000.ethernet eth0: Link is Up
- 100Mbps/Full - flow control rx/tx
[  619.215698] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

root at imx6solo:~# ip link set dev ethphy0 up
[  634.114608] sja1105 spi1.0 ethphy0: configuring for phy/mii link mode
[  634.126617] ------------[ cut here ]------------
[  634.131463] WARNING: CPU: 0 PID: 330 at drivers/net/phy/phy.c:1157
phy_start+0x58/0xb4
[  634.139627] called from state RUNNING
[  634.143310] Modules linked in: bnep tag_sja1105 sja1105 pcs_xpcs
brcmfmac brcmutil imx_sdma coda_vpu v4l2_jpeg imx_vdoa evbug
[  634.154815] CPU: 0 PID: 330 Comm: ip Not tainted 6.1.58 #1
[  634.160321] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  634.166866]  unwind_backtrace from show_stack+0x10/0x14
[  634.172125]  show_stack from dump_stack_lvl+0x58/0x70
[  634.177205]  dump_stack_lvl from __warn+0x70/0x1a4
[  634.182023]  __warn from warn_slowpath_fmt+0x1bc/0x270
[  634.187181]  warn_slowpath_fmt from phy_start+0x58/0xb4
[  634.192427]  phy_start from dsa_port_enable_rt+0x54/0x9c
[  634.197765]  dsa_port_enable_rt from dsa_slave_open+0xb8/0x17c
[  634.203624]  dsa_slave_open from __dev_open+0xec/0x1ac
[  634.208788]  __dev_open from __dev_change_flags+0x18c/0x224
[  634.214377]  __dev_change_flags from dev_change_flags+0x14/0x44
[  634.220313]  dev_change_flags from do_setlink+0x254/0xe4c
[  634.225737]  do_setlink from rtnl_newlink+0x598/0x80c
[  634.230811]  rtnl_newlink from rtnetlink_rcv_msg+0x168/0x574
[  634.236485]  rtnetlink_rcv_msg from netlink_rcv_skb+0xb8/0x11c
[  634.242337]  netlink_rcv_skb from netlink_unicast+0x1a8/0x2dc
[  634.248108]  netlink_unicast from netlink_sendmsg+0x1d8/0x450
[  634.253884]  netlink_sendmsg from ____sys_sendmsg+0x188/0x258
[  634.259656]  ____sys_sendmsg from ___sys_sendmsg+0x6c/0xa4
[  634.265164]  ___sys_sendmsg from sys_sendmsg+0x50/0x98
[  634.270324]  sys_sendmsg from ret_fast_syscall+0x0/0x1c
[  634.275569] Exception stack(0xf1071fa8 to 0xf1071ff0)
[  634.280637] 1fa0:                   00000000 00000001 00000003
bef4d710 00000000 00000000
[  634.288828] 1fc0: 00000000 00000001 b6f415a0 00000128 626ad475
00000000 00531cc0 00531cc0
[  634.297016] 1fe0: 00000128 bef4d6b0 b6e3f6d3 b6db1ae6
[  634.302150] irq event stamp: 3327
[  634.305485] hardirqs last  enabled at (3335): [<c0195dbc>]
__up_console_sem+0x50/0x60
[  634.313404] hardirqs last disabled at (3344): [<c0195da8>]
__up_console_sem+0x3c/0x60
[  634.321318] softirqs last  enabled at (3230): [<c01017d0>]
__do_softirq+0x2c0/0x57c
[  634.329055] softirqs last disabled at (3187): [<c012f204>]
__irq_exit_rcu+0x138/0x17c
[  634.336971] ---[ end trace 0000000000000000 ]---
root at imx6solo:~# ip link set dev ethphy1 up
[  644.613564] sja1105 spi1.0 ethphy1: configuring for phy/mii link mode
root at imx6solo:~# [  646.727549] sja1105 spi1.0 ethphy1: Link is Up -
100Mbps/Full - flow control off
[  646.735033] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy1: link becomes ready

Thanks,
Jagan.


From ck.hu at mediatek.com  Mon Dec 25 23:57:40 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 07:57:40 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <13754f308ce9ff1a9787b2597e416613b638c611.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +
> +static u32 cmdq_sec_get_cookie(struct cmdq_sec *cmdq, u32 idx)
> +{
> +	return *(u32 *)(cmdq->shared_mem->va +
> +		CMDQ_SEC_SHARED_THR_CNT_OFFSET + idx * sizeof(u32));
> +}

cmdq_sec_get_cookie() is called in normal context not irq context, so
we could allow a function call into TEE to query cookie even though the
function call would take time. Therefore, it's not necessary to use a
cmdq command to copy cookie value into share memory.

Regards,
CK

From ck.hu at mediatek.com  Tue Dec 26 00:28:03 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 08:28:03 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <a0c9d84f8a2d6efdfd7502f796e5629a8471c9eb.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +
> +int cmdq_sec_pkt_write(struct cmdq_pkt *pkt, u32 addr, u64 base,
> +		       const enum cmdq_iwc_addr_metadata_type type,
> +		       const u32 offset, const u32 size, const u32
> port)
> +{
> +	int ret;
> +
> +	ret = cmdq_pkt_assign(pkt, CMDQ_THR_SPR_IDX0, addr);
> +	if (ret)
> +		return ret;
> +
> +	ret = cmdq_pkt_write_s_reg_value(pkt, CMDQ_THR_SPR_IDX0,
> (u32)base);
> +	if (ret)
> +		return ret;
> +
> +	return cmdq_sec_append_metadata(pkt, type, base, offset, size,
> port);

Why do you append this metadata? It looks like TEE would use this meta
data to check command is secure or not. But this meta data is in normal
world, so it may be modified by hacker. I think TEE should check
command buffer directly not by the meta data.

Regards,
CK

> +}
> +EXPORT_SYMBOL_GPL(cmdq_sec_pkt_write);
> +

From quic_snehshah at quicinc.com  Tue Dec 26 00:34:32 2023
From: quic_snehshah at quicinc.com (Sneh Shah)
Date: Tue, 26 Dec 2023 14:04:32 +0530
Subject: [PATCH net v2] net: stmmac: Fix ethool link settings ops for integrated PCS
Message-ID: <20231226083432.24920-1-quic_snehshah@quicinc.com>

Currently get/set_link_ksettings ethtool ops are dependent on PCS.
When  PCS is integrated, it will not have separate link config.
Bypass configuring and checking PCS for integrated PCS.

Fixes: ("aa571b6275fb net: stmmac: add new switch to struct plat_stmmacenet_data")
Tested-by: Andrew Halaney <ahalaney at redhat.com> # sa8775p-ride
Signed-off-by: Sneh Shah <quic_snehshah at quicinc.com>
---
v2 changelog:
- Added tested by tag.
- Added Fixes tag.
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index f628411ae4ae..e3ba4cd47b8d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -311,8 +311,9 @@ static int stmmac_ethtool_get_link_ksettings(struct net_device *dev,
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 
-	if (priv->hw->pcs & STMMAC_PCS_RGMII ||
-	    priv->hw->pcs & STMMAC_PCS_SGMII) {
+	if (!(priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS) &&
+	    (priv->hw->pcs & STMMAC_PCS_RGMII ||
+	     priv->hw->pcs & STMMAC_PCS_SGMII)) {
 		struct rgmii_adv adv;
 		u32 supported, advertising, lp_advertising;
 
@@ -397,8 +398,9 @@ stmmac_ethtool_set_link_ksettings(struct net_device *dev,
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 
-	if (priv->hw->pcs & STMMAC_PCS_RGMII ||
-	    priv->hw->pcs & STMMAC_PCS_SGMII) {
+	if (!(priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS) &&
+	    (priv->hw->pcs & STMMAC_PCS_RGMII ||
+	     priv->hw->pcs & STMMAC_PCS_SGMII)) {
 		/* Only support ANE */
 		if (cmd->base.autoneg != AUTONEG_ENABLE)
 			return -EINVAL;
-- 
2.17.1



From fuyao at sjterm.com  Tue Dec 26 00:40:05 2023
From: fuyao at sjterm.com (Fuyao Kashizuku)
Date: Tue, 26 Dec 2023 16:40:05 +0800
Subject: [PATCH v2] ARM: dts: sun8i: Open FETA40i-C regulator aldo1
Message-ID: <ZYqRZev1g_mztff2@debian.cyg>

The USB PHY in the Allwinner R40 SoC seems to rely on voltage on the
VCC-TVIN/OUT supply pins for proper operation, on top of its own supply
voltage on VCC-USB. Without a 3.3V voltage supplied to VCC-TV*, USB
operation becomes unstable and can result in disconnects.

The Forlinx FETA40i-C SoM connects both the VCC-TVOUT and VCC-TVIN pins
to the ALDO1 rail of the PMIC, so we need to enable that rail for USB
operation. Since there is no supply property in the DT bindings for
the USB core, we need to always enable the regulator.

This fixes unstable USB operation on boards using the Forlinx FETA40i-C
module.

Signed-off-by: Fuyao Kashizuku <fuyao at sjterm.com>
---
Changes in v2:
 - Subject include board name.
 - regulator name changed to vcc-3v3-tv-usb.
 - explain why we need to enable the regulator.
 - use full name of the commiter
 - Link to v1: https://lore.kernel.org/lkml/ZYKjYypuAx7gNuam at debian.cyg/

 arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
index 9f39b5a2bb35..c12361d0317f 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
@@ -42,6 +42,13 @@ &pio {
 	vcc-pg-supply = <&reg_dldo1>;
 };
 
+&reg_aldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-3v3-tv-usb";
+};
+
 &reg_aldo2 {
 	regulator-always-on;
 	regulator-min-microvolt = <1800000>;
-- 
2.39.2


From aakarsh.jain at samsung.com  Tue Dec 26 00:53:21 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Tue, 26 Dec 2023 14:23:21 +0530
Subject: [PATCH 04/15] media: s5p-mfc: constify fw_name strings
In-Reply-To: <20231224-n-s5p-mfc-const-v1-4-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
	<CGME20231224154440epcas5p3c2f26174c8b32edf390629f1e829403a@epcas5p3.samsung.com>
	<20231224-n-s5p-mfc-const-v1-4-a3b246470fe4@linaro.org>
Message-ID: <15d501da37d8$fc10bd30$f4323790$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: 24 December 2023 21:14
> To: Marek Szyprowski <m.szyprowski at samsung.com>; Andrzej Hajda
> <andrzej.hajda at intel.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>
> Cc: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-fsd at tesla.coma; linux-
> samsung-soc at vger.kernel.org; Smitha T Murthy
> <smithatmurthy at gmail.com>; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org; linux-kernel at vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>
> Subject: [PATCH 04/15] media: s5p-mfc: constify fw_name strings
> 
> Constify stored pointers to firmware names for code safety.  These are not
> modified by the driver.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> index 5304f42c8c72..f33a755327ef 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> @@ -227,7 +227,7 @@ struct s5p_mfc_variant {
>  	unsigned int port_num;
>  	u32 version_bit;
>  	struct s5p_mfc_buf_size *buf_size;
> -	char	*fw_name[MFC_FW_MAX_VERSIONS];
> +	const char	*fw_name[MFC_FW_MAX_VERSIONS];
>  	const char	*clk_names[MFC_MAX_CLOCKS];
>  	int		num_clocks;
>  	bool		use_clock_gating;
> 
> --
> 2.34.1

Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Thanks!



From aakarsh.jain at samsung.com  Tue Dec 26 01:02:22 2023
From: aakarsh.jain at samsung.com (Aakarsh Jain)
Date: Tue, 26 Dec 2023 14:32:22 +0530
Subject: [PATCH 07/15] media: s5p-mfc: constify s5p_mfc_hw_cmds
 structures
In-Reply-To: <20231224-n-s5p-mfc-const-v1-7-a3b246470fe4@linaro.org>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
	<CGME20231224154443epcas5p1ff84ea0f066dc19c908a18ccf0222b2f@epcas5p1.samsung.com>
	<20231224-n-s5p-mfc-const-v1-7-a3b246470fe4@linaro.org>
Message-ID: <15d601da37da$3e8235d0$bb86a170$@samsung.com>



> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: 24 December 2023 21:14
> To: Marek Szyprowski <m.szyprowski at samsung.com>; Andrzej Hajda
> <andrzej.hajda at intel.com>; Mauro Carvalho Chehab
> <mchehab at kernel.org>
> Cc: Aakarsh Jain <aakarsh.jain at samsung.com>; linux-fsd at tesla.coma; linux-
> samsung-soc at vger.kernel.org; Smitha T Murthy
> <smithatmurthy at gmail.com>; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org; linux-kernel at vger.kernel.org; Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org>
> Subject: [PATCH 07/15] media: s5p-mfc: constify s5p_mfc_hw_cmds
> structures
> 
> Static "s5p_mfc_hw_cmds" structures are not modified by the driver, so they
> can be made const for code safety.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c | 4 ++--
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h | 2 +-
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c | 4 ++--
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h | 2 +-
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h | 2 +-
>  5 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
> index 327e54e70611..1fbf7ed5d4cc 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.c
> @@ -148,7 +148,7 @@ static int s5p_mfc_close_inst_cmd_v5(struct
> s5p_mfc_ctx *ctx)  }
> 
>  /* Initialize cmd function pointers for MFC v5 */ -static struct
> s5p_mfc_hw_cmds s5p_mfc_cmds_v5 = {
> +static const struct s5p_mfc_hw_cmds s5p_mfc_cmds_v5 = {
>  	.cmd_host2risc = s5p_mfc_cmd_host2risc_v5,
>  	.sys_init_cmd = s5p_mfc_sys_init_cmd_v5,
>  	.sleep_cmd = s5p_mfc_sleep_cmd_v5,
> @@ -157,7 +157,7 @@ static struct s5p_mfc_hw_cmds s5p_mfc_cmds_v5 = {
>  	.close_inst_cmd = s5p_mfc_close_inst_cmd_v5,  };
> 
> -struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v5(void)
> +const struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v5(void)
>  {
>  	return &s5p_mfc_cmds_v5;
>  }
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h
> index 6eafa514aebc..c626376053c4 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v5.h
> @@ -11,6 +11,6 @@
> 
>  #include "s5p_mfc_common.h"
> 
> -struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v5(void);
> +const struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v5(void);
> 
>  #endif /* S5P_MFC_CMD_H_ */
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
> index 25c4719a5dd0..740aa4dfae57 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -154,7 +154,7 @@ static int s5p_mfc_close_inst_cmd_v6(struct
> s5p_mfc_ctx *ctx)  }
> 
>  /* Initialize cmd function pointers for MFC v6 */ -static struct
> s5p_mfc_hw_cmds s5p_mfc_cmds_v6 = {
> +static const struct s5p_mfc_hw_cmds s5p_mfc_cmds_v6 = {
>  	.cmd_host2risc = s5p_mfc_cmd_host2risc_v6,
>  	.sys_init_cmd = s5p_mfc_sys_init_cmd_v6,
>  	.sleep_cmd = s5p_mfc_sleep_cmd_v6,
> @@ -163,7 +163,7 @@ static struct s5p_mfc_hw_cmds s5p_mfc_cmds_v6 = {
>  	.close_inst_cmd = s5p_mfc_close_inst_cmd_v6,  };
> 
> -struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v6(void)
> +const struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v6(void)
>  {
>  	return &s5p_mfc_cmds_v6;
>  }
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h
> index 9dc44460cc38..29083436f517 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.h
> @@ -11,6 +11,6 @@
> 
>  #include "s5p_mfc_common.h"
> 
> -struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v6(void);
> +const struct s5p_mfc_hw_cmds *s5p_mfc_init_hw_cmds_v6(void);
> 
>  #endif /* S5P_MFC_CMD_H_ */
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> index 6a47f3434c60..9278ed537e9c 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
> @@ -339,7 +339,7 @@ struct s5p_mfc_dev {
>  	struct s5p_mfc_priv_buf ctx_buf;
>  	int warn_start;
>  	struct s5p_mfc_hw_ops *mfc_ops;
> -	struct s5p_mfc_hw_cmds *mfc_cmds;
> +	const struct s5p_mfc_hw_cmds *mfc_cmds;
>  	const struct s5p_mfc_regs *mfc_regs;
>  	enum s5p_mfc_fw_ver fw_ver;
>  	bool fw_get_done;
> 
> --
> 2.34.1

Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Thanks!




From krzysztof.kozlowski at linaro.org  Tue Dec 26 01:06:14 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 26 Dec 2023 10:06:14 +0100
Subject: [PATCH 15/15] media: s5p-mfc: drop static device variable in
 s5p_mfc_pm.c
In-Reply-To: <15d301da37c3$cff325e0$6fd971a0$@samsung.com>
References: <20231224-n-s5p-mfc-const-v1-0-a3b246470fe4@linaro.org>
 <CGME20231224154454epcas5p311d2b74fb1809bb555a442d1bce82edb@epcas5p3.samsung.com>
 <20231224-n-s5p-mfc-const-v1-15-a3b246470fe4@linaro.org>
 <15d301da37c3$cff325e0$6fd971a0$@samsung.com>
Message-ID: <cdb2cfb6-8385-4f4d-b49b-b04d19d4bdc0@linaro.org>

On 26/12/2023 07:21, Aakarsh Jain wrote:
>> -int s5p_mfc_clock_on(void);
>> -void s5p_mfc_clock_off(void);
>> -int s5p_mfc_power_on(void);
>> -int s5p_mfc_power_off(void);
>> +int s5p_mfc_clock_on(struct s5p_mfc_dev *dev); void
>> +s5p_mfc_clock_off(struct s5p_mfc_dev *dev); int
>> s5p_mfc_power_on(struct
>> +s5p_mfc_dev *dev); int s5p_mfc_power_off(struct s5p_mfc_dev *dev);
>>
>>  #endif /* S5P_MFC_PM_H_ */
>>
>> --
>> 2.34.1
> 
> Reviewed-by: Aakarsh Jain <aakarsh.jain at samsung.com>

Pleasy kindly trim the replies from unnecessary context.  It makes it
much easier to find new content.

Best regards,
Krzysztof



From ck.hu at mediatek.com  Tue Dec 26 00:58:45 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 08:58:45 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <f338215fb8f7ff1e0ebeb0f1e21a8b4dec5f0c61.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +
> +static int cmdq_sec_fill_iwc_msg(struct cmdq_sec_context *context,
> +				 struct cmdq_sec_task *sec_task, u32
> thrd_idx)
> +{
> +	struct iwc_cmdq_message_t *iwc_msg = NULL;
> +	struct cmdq_sec_data *data = (struct cmdq_sec_data *)sec_task-
> >task.pkt->sec_data;
> +	u32 size = 0, offset = 0, *instr;
> +
> +	iwc_msg = (struct iwc_cmdq_message_t *)context->iwc_msg;
> +
> +	if (sec_task->task.pkt->cmd_buf_size + 4 * CMDQ_INST_SIZE >
> CMDQ_TZ_CMD_BLOCK_SIZE) {
> +		pr_err("sec_task:%p size:%zu > %u",
> +		       sec_task, sec_task->task.pkt->cmd_buf_size,
> CMDQ_TZ_CMD_BLOCK_SIZE);
> +		return -EFAULT;
> +	}
> +
> +	if (thrd_idx == CMDQ_INVALID_THREAD) {
> +		iwc_msg->command.cmd_size = 0;
> +		iwc_msg->command.metadata.addr_list_length = 0;
> +		return -EINVAL;
> +	}
> +
> +	iwc_msg->command.thread = thrd_idx;
> +	iwc_msg->command.scenario = sec_task->scenario;
> +	iwc_msg->command.eng_flag = sec_task->engine_flag;
> +	size = sec_task->task.pkt->cmd_buf_size;
> +	memcpy(iwc_msg->command.va_base + offset, sec_task->task.pkt-
> >va_base, size);

I think it's not necessary to copy from normal command buffer to normal
command buffer. Just

iwc_msg->command.va_base = sec_task->task.pkt->va_base;

You have a secure command buffer for secure gce to execute command. If
you want to modify command buffer, copy from normal command buffer to
secure command buffer, and modify the secure command buffer.

Regards,
CK


> +	iwc_msg->command.cmd_size += size;
> +	offset += size / 4;
> +
> +	instr = &iwc_msg->command.va_base[iwc_msg->command.cmd_size / 4
> - 4];
> +	if ((u64)*instr == CMDQ_EOC_CMD)
> +		instr[0] = 0;
> +	else
> +		pr_err("%s %d: find EOC failed: %#x %#x",
> +		       __func__, __LINE__, instr[1], instr[0]);
> +
> +	iwc_msg->command.wait_cookie = sec_task->wait_cookie;
> +	iwc_msg->command.reset_exec = sec_task->reset_exec;
> +
> +	if (data->addr_metadata_cnt) {
> +		iwc_msg->command.metadata.addr_list_length = data-
> >addr_metadata_cnt;
> +		memcpy(iwc_msg->command.metadata.addr_list,
> +		       (u32 *)(unsigned long)data->addr_metadatas,
> +		       data->addr_metadata_cnt * sizeof(struct
> iwc_cmdq_addr_metadata_t));
> +	}
> +
> +	iwc_msg->command.metadata.engs_need_dapc = data-
> >engs_need_dapc;
> +	iwc_msg->command.metadata.engs_need_sec_port = data-
> >engs_need_sec_port;
> +	iwc_msg->command.normal_task_handle = (unsigned long)sec_task-
> >task.pkt;
> +
> +	return 0;
> +}
> +

From ck.hu at mediatek.com  Tue Dec 26 01:18:34 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Tue, 26 Dec 2023 09:18:34 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <c179d1ab68298efd314ffbe39fc67c5bb2dc5764.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +
> +/**
> + * struct iwc_cmdq_command_t - structure for excuting cmdq task in
> secure world.
> + * @thread: GCE secure thread index to execute command.
> + * @scenario: scenario to execute command.
> + * @priority: priority of GCE secure thread.
> + * @cmd_size: command size used in command buffer.
> + * @eng_flag: HW engine flag need to enable protection
> configuration.
> + * @va_base: command buffer
> + * @wait_cookie: index in thread's task list, it should be
> (nextCookie - 1).
> + * @reset_exec: reset HW thread.
> + * @caller_pid: pid of client module.
> + * @caller_name: name of client module.
> + * @metadata: metadata structure for converting a list of secure
> buffer address.
> + * @extension: extension HW engine flag to be protcted in secure
> world.
> + * @readback_pa: readback buffer pa.
> + * @normal_task_handle: handle to reference task in normal world.
> + * @mdp_extension: extension MDP HW engine flag to be protcted in
> secure world.
> + * @readback_engs: array of readback engines parameters.
> + * @readback_cnt: count of readback_engs array.
> + */
> +struct iwc_cmdq_command_t {
> +	/* basic execution data */
> +	u32 thread;
> +	u32 scenario;
> +	u32 priority;
> +	u32 cmd_size;
> +	u64 eng_flag;
> +	u32 va_base[CMDQ_IWC_MAX_CMD_LENGTH];
> +
> +	/* exec order data */
> +	u32 wait_cookie;
> +	bool reset_exec;
> +
> +	/* client info */
> +	s32 caller_pid;

Useless, drop it.

> +	char caller_name[CMDQ_IWC_CLIENT_NAME];

Ditto.

> +
> +	/* metadata */
> +	struct iwc_cmdq_metadata_t metadata;
> +
> +	/* client extension bits */
> +	u64 extension;

Ditto.

> +	u64 readback_pa;

Ditto.

> +
> +	/* debug */
> +	u64 normal_task_handle;
> +
> +	/* SVP HDR */
> +	u32 mdp_extension;

Ditto.

> +	struct readback_engine readback_engs[CMDQ_MAX_READBACK_ENG];

Ditto.

> +	u32 readback_cnt;

Ditto.

Regards,
CK

> +};
> +

From andre.przywara at arm.com  Tue Dec 26 02:40:04 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 26 Dec 2023 10:40:04 +0000
Subject: [PATCH v2] ARM: dts: sun8i: Open FETA40i-C regulator aldo1
In-Reply-To: <ZYqRZev1g_mztff2@debian.cyg>
References: <ZYqRZev1g_mztff2@debian.cyg>
Message-ID: <20231226104004.0cec26a9@minigeek.lan>

On Tue, 26 Dec 2023 16:40:05 +0800
Fuyao Kashizuku <fuyao at sjterm.com> wrote:

Hi,

many thanks for the quick turnaround!

> The USB PHY in the Allwinner R40 SoC seems to rely on voltage on the
> VCC-TVIN/OUT supply pins for proper operation, on top of its own supply
> voltage on VCC-USB. Without a 3.3V voltage supplied to VCC-TV*, USB
> operation becomes unstable and can result in disconnects.
> 
> The Forlinx FETA40i-C SoM connects both the VCC-TVOUT and VCC-TVIN pins
> to the ALDO1 rail of the PMIC, so we need to enable that rail for USB
> operation. Since there is no supply property in the DT bindings for
> the USB core, we need to always enable the regulator.
> 
> This fixes unstable USB operation on boards using the Forlinx FETA40i-C
> module.
> 
> Signed-off-by: Fuyao Kashizuku <fuyao at sjterm.com>

Perfect, looks good to me now!

Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Thanks!
Andre

> ---
> Changes in v2:
>  - Subject include board name.
>  - regulator name changed to vcc-3v3-tv-usb.
>  - explain why we need to enable the regulator.
>  - use full name of the commiter
>  - Link to v1: https://lore.kernel.org/lkml/ZYKjYypuAx7gNuam at debian.cyg/
> 
>  arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> index 9f39b5a2bb35..c12361d0317f 100644
> --- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> +++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
> @@ -42,6 +42,13 @@ &pio {
>  	vcc-pg-supply = <&reg_dldo1>;
>  };
>  
> +&reg_aldo1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-3v3-tv-usb";
> +};
> +
>  &reg_aldo2 {
>  	regulator-always-on;
>  	regulator-min-microvolt = <1800000>;



From florian.fainelli at broadcom.com  Tue Dec 26 02:44:02 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Tue, 26 Dec 2023 11:44:02 +0100
Subject: [PATCH v2] pwm: bcm2835: Remove duplicate call to
 clk_rate_exclusive_put()
In-Reply-To: <20231222131312.174491-1-sean@mess.org>
References: <20231222131312.174491-1-sean@mess.org>
Message-ID: <fe891b5a-cacb-4ea7-9f95-53bfe252a525@broadcom.com>



On 12/22/2023 2:13 PM, Sean Young wrote:
> devm_add_action_or_reset() already calls the action in the error case.
> 
> Reported-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> Closes: https://lore.kernel.org/linux-pwm/fuku3b5ur6y4k4refd3vmeoenzjo6mwe3b3gtel34rhhhtvnsa at w4uktgbqsc3w/
> Fixes: fcc760729359 ("pwm: bcm2835: Allow PWM driver to be used in atomic context")
> Signed-off-by: Sean Young <sean at mess.org>
> Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231226/c68bdb62/attachment.p7s>

From fshao at chromium.org  Tue Dec 26 02:46:18 2023
From: fshao at chromium.org (Fei Shao)
Date: Tue, 26 Dec 2023 18:46:18 +0800
Subject: [PATCH v2 1/4] drm/mediatek: dsi: Use GENMASK() for register mask definitions
In-Reply-To: <20231220135722.192080-2-angelogioacchino.delregno@collabora.com>
References: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com> <20231220135722.192080-2-angelogioacchino.delregno@collabora.com>
Message-ID: <CAC=S1ng+kkJS-g3FHe4SC-r1a6hegj3=Any07TCdvTU_apvZNg@mail.gmail.com>

Hi Angelo,

On Wed, Dec 20, 2023 at 9:57?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Change magic numerical masks with usage of the GENMASK() macro
> to improve readability.
>
> This commit brings no functional changes.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 46 ++++++++++++++++--------------
>  1 file changed, 24 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index a2fdfc8ddb15..23d2c5be8dbb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -58,18 +58,18 @@
>
>  #define DSI_TXRX_CTRL          0x18
>  #define VC_NUM                         BIT(1)
> -#define LANE_NUM                       (0xf << 2)
> +#define LANE_NUM                       GENMASK(5, 2)
>  #define DIS_EOT                                BIT(6)
>  #define NULL_EN                                BIT(7)
>  #define TE_FREERUN                     BIT(8)
>  #define EXT_TE_EN                      BIT(9)
>  #define EXT_TE_EDGE                    BIT(10)
> -#define MAX_RTN_SIZE                   (0xf << 12)
> +#define MAX_RTN_SIZE                   GENMASK(15, 12)
>  #define HSTX_CKLP_EN                   BIT(16)
>
>  #define DSI_PSCTRL             0x1c
> -#define DSI_PS_WC                      0x3fff
> -#define DSI_PS_SEL                     (3 << 16)
> +#define DSI_PS_WC                      GENMASK(14, 0)
> +#define DSI_PS_SEL                     GENMASK(19, 16)

GENMASK(17, 16)
>
>  #define PACKED_PS_16BIT_RGB565         (0 << 16)
>  #define LOOSELY_PS_18BIT_RGB666                (1 << 16)
>  #define PACKED_PS_18BIT_RGB666         (2 << 16)
> @@ -109,26 +109,27 @@
>  #define LD0_WAKEUP_EN                  BIT(2)
>
>  #define DSI_PHY_TIMECON0       0x110
> -#define LPX                            (0xff << 0)
> -#define HS_PREP                                (0xff << 8)
> -#define HS_ZERO                                (0xff << 16)
> -#define HS_TRAIL                       (0xff << 24)
> +#define LPX                            GENMASK(7, 0)
> +#define HS_PREP                                GENMASK(15, 8)
> +#define HS_ZERO                                GENMASK(23, 16)
> +#define HS_TRAIL                       GENMASK(31, 24)
>
>  #define DSI_PHY_TIMECON1       0x114
> -#define TA_GO                          (0xff << 0)
> -#define TA_SURE                                (0xff << 8)
> -#define TA_GET                         (0xff << 16)
> -#define DA_HS_EXIT                     (0xff << 24)
> +#define TA_GO                          GENMASK(7, 0)
> +#define TA_SURE                                GENMASK(15, 8)
> +#define TA_GET                         GENMASK(23, 16)
> +#define DA_HS_EXIT                     GENMASK(31, 24)
>
>  #define DSI_PHY_TIMECON2       0x118
> -#define CONT_DET                       (0xff << 0)
> -#define CLK_ZERO                       (0xff << 16)
> -#define CLK_TRAIL                      (0xff << 24)
> +#define CONT_DET                       GENMASK(7, 0)
> +#define DA_HS_SYNC                     GENMASK(15, 8)

This is new, so please introduce it in a separate patch if intended.

The rest looks good to me.

Regards,
Fei


>
> +#define CLK_ZERO                       GENMASK(23, 16)
> +#define CLK_TRAIL                      GENMASK(31, 24)
>
>  #define DSI_PHY_TIMECON3       0x11c
> -#define CLK_HS_PREP                    (0xff << 0)
> -#define CLK_HS_POST                    (0xff << 8)
> -#define CLK_HS_EXIT                    (0xff << 16)
> +#define CLK_HS_PREP                    GENMASK(7, 0)
> +#define CLK_HS_POST                    GENMASK(15, 8)
> +#define CLK_HS_EXIT                    GENMASK(23, 16)
>
>  #define DSI_VM_CMD_CON         0x130
>  #define VM_CMD_EN                      BIT(0)
> @@ -138,13 +139,14 @@
>  #define FORCE_COMMIT                   BIT(0)
>  #define BYPASS_SHADOW                  BIT(1)
>
> -#define CONFIG                         (0xff << 0)
> +/* CMDQ related bits */
> +#define CONFIG                         GENMASK(7, 0)
>  #define SHORT_PACKET                   0
>  #define LONG_PACKET                    2
>  #define BTA                            BIT(2)
> -#define DATA_ID                                (0xff << 8)
> -#define DATA_0                         (0xff << 16)
> -#define DATA_1                         (0xff << 24)
> +#define DATA_ID                                GENMASK(15, 8)
> +#define DATA_0                         GENMASK(23, 16)
> +#define DATA_1                         GENMASK(31, 24)
>
>  #define NS_TO_CYCLE(n, c)    ((n) / (c) + (((n) % (c)) ? 1 : 0))
>
> --
> 2.43.0
>
>


From fshao at chromium.org  Tue Dec 26 02:48:18 2023
From: fshao at chromium.org (Fei Shao)
Date: Tue, 26 Dec 2023 18:48:18 +0800
Subject: [PATCH v2 2/4] drm/mediatek: dsi: Cleanup functions mtk_dsi_ps_control{_vact}()
In-Reply-To: <20231220135722.192080-3-angelogioacchino.delregno@collabora.com>
References: <20231220135722.192080-1-angelogioacchino.delregno@collabora.com> <20231220135722.192080-3-angelogioacchino.delregno@collabora.com>
Message-ID: <CAC=S1nhNfyEWKaJZjb_G-pXpxSpXvNQd2EMJUzWWwxmC+TzSaA@mail.gmail.com>

Hi Angelo,

On Wed, Dec 20, 2023 at 9:57?PM AngeloGioacchino Del Regno
<angelogioacchino.delregno at collabora.com> wrote:
>
> Function mtk_dsi_ps_control() is a subset of mtk_dsi_ps_control_vact():
> merge the two in one mtk_dsi_ps_control() function by adding one
> function parameter `config_vact` which, when true, writes the VACT
> related registers.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 76 +++++++++---------------------
>  1 file changed, 23 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 23d2c5be8dbb..b618e2e31022 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -352,40 +352,6 @@ static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
>         mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
>  }
>
> -static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> -{
> -       struct videomode *vm = &dsi->vm;
> -       u32 dsi_buf_bpp, ps_wc;
> -       u32 ps_bpp_mode;
> -
> -       if (dsi->format == MIPI_DSI_FMT_RGB565)
> -               dsi_buf_bpp = 2;
> -       else
> -               dsi_buf_bpp = 3;
> -
> -       ps_wc = vm->hactive * dsi_buf_bpp;
> -       ps_bpp_mode = ps_wc;
> -
> -       switch (dsi->format) {
> -       case MIPI_DSI_FMT_RGB888:
> -               ps_bpp_mode |= PACKED_PS_24BIT_RGB888;
> -               break;
> -       case MIPI_DSI_FMT_RGB666:
> -               ps_bpp_mode |= PACKED_PS_18BIT_RGB666;
> -               break;
> -       case MIPI_DSI_FMT_RGB666_PACKED:
> -               ps_bpp_mode |= LOOSELY_PS_18BIT_RGB666;
> -               break;
> -       case MIPI_DSI_FMT_RGB565:
> -               ps_bpp_mode |= PACKED_PS_16BIT_RGB565;
> -               break;
> -       }
> -
> -       writel(vm->vactive, dsi->regs + DSI_VACT_NL);
> -       writel(ps_bpp_mode, dsi->regs + DSI_PSCTRL);
> -       writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
> -}
> -
>  static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
>  {
>         u32 tmp_reg;
> @@ -417,36 +383,40 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
>         writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
>  }
>
> -static void mtk_dsi_ps_control(struct mtk_dsi *dsi)
> +static void mtk_dsi_ps_control(struct mtk_dsi *dsi, bool config_vact)
>  {
> -       u32 dsi_tmp_buf_bpp;
> -       u32 tmp_reg;
> +       struct videomode *vm = &dsi->vm;
> +       u32 dsi_buf_bpp, ps_wc;
> +       u32 ps_bpp_mode;
> +
> +       if (dsi->format == MIPI_DSI_FMT_RGB565)
> +               dsi_buf_bpp = 2;
> +       else
> +               dsi_buf_bpp = 3;

The same is also in mtk_dsi_config_vdo_timing(). Given this is a
cleanup series, I think it'd be a good chance to add another patch
and integrate those usages. Just a thought.  :)
>
> +
> +       ps_wc = vm->hactive * dsi_buf_bpp;

I noticed the "& DSI_PS_WC" part was dropped (but perhaps with awareness?).

While the outcome seems to always fall within the range of
DSI_PS_WC so we should be fine in practice, I think it doesn't hurt to
keep the value masked to save readers some time to check if this would
ever be possible to overflow and write undesired bits down the line.
WDYT?

Regardless of that, I didn't find obvious issue in this patch, so

Reviewed-by: Fei Shao <fshao at chromium.org>

Regards,
Fei




>
> +       ps_bpp_mode = ps_wc;
>
>         switch (dsi->format) {
>         case MIPI_DSI_FMT_RGB888:
> -               tmp_reg = PACKED_PS_24BIT_RGB888;
> -               dsi_tmp_buf_bpp = 3;
> +               ps_bpp_mode |= PACKED_PS_24BIT_RGB888;
>                 break;
>         case MIPI_DSI_FMT_RGB666:
> -               tmp_reg = LOOSELY_PS_18BIT_RGB666;
> -               dsi_tmp_buf_bpp = 3;
> +               ps_bpp_mode |= PACKED_PS_18BIT_RGB666;
>                 break;
>         case MIPI_DSI_FMT_RGB666_PACKED:
> -               tmp_reg = PACKED_PS_18BIT_RGB666;
> -               dsi_tmp_buf_bpp = 3;
> +               ps_bpp_mode |= LOOSELY_PS_18BIT_RGB666;
>                 break;
>         case MIPI_DSI_FMT_RGB565:
> -               tmp_reg = PACKED_PS_16BIT_RGB565;
> -               dsi_tmp_buf_bpp = 2;
> -               break;
> -       default:
>
> -               tmp_reg = PACKED_PS_24BIT_RGB888;
> -               dsi_tmp_buf_bpp = 3;
> +               ps_bpp_mode |= PACKED_PS_16BIT_RGB565;
>                 break;
>         }
>
> -       tmp_reg += dsi->vm.hactive * dsi_tmp_buf_bpp & DSI_PS_WC;
>
> -       writel(tmp_reg, dsi->regs + DSI_PSCTRL);
> +       if (config_vact) {
> +               writel(vm->vactive, dsi->regs + DSI_VACT_NL);
> +               writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
> +       }
> +       writel(ps_bpp_mode, dsi->regs + DSI_PSCTRL);
>  }
>
>  static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> @@ -522,7 +492,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
>         writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
>         writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
>
> -       mtk_dsi_ps_control(dsi);
> +       mtk_dsi_ps_control(dsi, false);
>  }
>
>  static void mtk_dsi_start(struct mtk_dsi *dsi)
> @@ -667,7 +637,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>         mtk_dsi_reset_engine(dsi);
>         mtk_dsi_phy_timconfig(dsi);
>
> -       mtk_dsi_ps_control_vact(dsi);
> +       mtk_dsi_ps_control(dsi, true);
>         mtk_dsi_set_vm_cmd(dsi);
>         mtk_dsi_config_vdo_timing(dsi);
>         mtk_dsi_set_interrupt_enable(dsi);
> --
> 2.43.0
>
>


From cniedermaier at dh-electronics.com  Tue Dec 26 03:36:47 2023
From: cniedermaier at dh-electronics.com (Christoph Niedermaier)
Date: Tue, 26 Dec 2023 12:36:47 +0100
Subject: [PATCH V2] serial: imx: Ensure that imx_uart_rs485_config() is called with enabled clock
Message-ID: <20231226113647.39376-1-cniedermaier@dh-electronics.com>

There are register accesses in the function imx_uart_rs485_config(). The
clock must be enabled for these accesses. This was ensured by calling it
via the function uart_rs485_config() in the probe() function within the
range where the clock is enabled. With the commit 7c7f9bc986e6 ("serial:
Deassert Transmit Enable on probe in driver-specific way") it was removed
from the probe() function and is now only called through the function
uart_add_one_port() which is located at the end of the probe() function.
But the clock is already switched off in this area. To ensure that the
clock is enabled during register access, move the disabling of the clock
to the very end of the probe() function. To avoid leaking enabled clocks
on error also add an error path for exiting with disabling the clock.

Fixes: 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way")
Signed-off-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>
---
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Jiri Slaby <jirislaby at kernel.org>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Marek Vasut <marex at denx.de>
Cc: Fabio Estevam <festevam at denx.de>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: Sergey Organov <sorganov at gmail.com>
Cc: "Uwe Kleine-K?nig" <u.kleine-koenig at pengutronix.de>
Cc: Rob Herring <robh at kernel.org>
Cc: "Ilpo J?rvinen" <ilpo.jarvinen at linux.intel.com>
Cc: Tom Rix <trix at redhat.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Lukas Wunner <lukas at wunner.de>
To: linux-serial at vger.kernel.org
To: linux-arm-kernel at lists.infradead.org
---
V2: - Avoid leaking enabled clocks on error path
    - Adapt commit message
---
 drivers/tty/serial/imx.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e7e952bb7bb8..c2fec44c28e8 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2332,10 +2332,8 @@ static int imx_uart_probe(struct platform_device *pdev)
 	}
 
 	ret = uart_get_rs485_mode(&sport->port);
-	if (ret) {
-		clk_disable_unprepare(sport->clk_ipg);
-		return ret;
-	}
+	if (ret)
+		goto err_clk;
 
 	if (sport->port.rs485.flags & SER_RS485_ENABLED &&
 	    (!sport->have_rtscts && !sport->have_rtsgpio))
@@ -2419,8 +2417,6 @@ static int imx_uart_probe(struct platform_device *pdev)
 		imx_uart_writel(sport, ucr3, UCR3);
 	}
 
-	clk_disable_unprepare(sport->clk_ipg);
-
 	hrtimer_init(&sport->trigger_start_tx, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	hrtimer_init(&sport->trigger_stop_tx, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	sport->trigger_start_tx.function = imx_trigger_start_tx;
@@ -2436,7 +2432,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(&pdev->dev, "failed to request rx irq: %d\n",
 				ret);
-			return ret;
+			goto err_clk;
 		}
 
 		ret = devm_request_irq(&pdev->dev, txirq, imx_uart_txint, 0,
@@ -2444,7 +2440,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(&pdev->dev, "failed to request tx irq: %d\n",
 				ret);
-			return ret;
+			goto err_clk;
 		}
 
 		ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
@@ -2452,14 +2448,14 @@ static int imx_uart_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(&pdev->dev, "failed to request rts irq: %d\n",
 				ret);
-			return ret;
+			goto err_clk;
 		}
 	} else {
 		ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
 				       dev_name(&pdev->dev), sport);
 		if (ret) {
 			dev_err(&pdev->dev, "failed to request irq: %d\n", ret);
-			return ret;
+			goto err_clk;
 		}
 	}
 
@@ -2467,7 +2463,12 @@ static int imx_uart_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, sport);
 
-	return uart_add_one_port(&imx_uart_uart_driver, &sport->port);
+	ret = uart_add_one_port(&imx_uart_uart_driver, &sport->port);
+
+err_clk:
+	clk_disable_unprepare(sport->clk_ipg);
+
+	return ret;
 }
 
 static void imx_uart_remove(struct platform_device *pdev)
-- 
2.11.0



From conor at kernel.org  Tue Dec 26 04:10:33 2023
From: conor at kernel.org (Conor Dooley)
Date: Tue, 26 Dec 2023 12:10:33 +0000
Subject: [PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <655855b6-ff68-4a3c-9ec7-fc72967b702a@solid-run.com>
References: <20231224143850.5671-3-josua@solid-run.com>
 <20231224143850.5671-4-josua@solid-run.com>
 <20231224-tibia-thursday-bea9dde2fbf1@spud>
 <655855b6-ff68-4a3c-9ec7-fc72967b702a@solid-run.com>
Message-ID: <20231226-dictate-spearman-0fe1ec4bee3b@spud>

On Sun, Dec 24, 2023 at 03:58:14PM +0000, Josua Mayer wrote:
> Am 24.12.23 um 15:42 schrieb Conor Dooley:
> 
> On Sun, Dec 24, 2023 at 03:38:45PM +0100, Josua Mayer wrote:
> 
> 
> Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
> boards.
> 
> While they are just two variants, we have 3 device-tree:
> - armada-388-clearfog.dts
> - armada-388-clearfog-base.dts
> - armada-388-clearfog-pro.dts
> 
> While the first one is identical to the pro variant, the filename is
> not, and neither are the compatible strings.
> 
> The first is compatible to armada-380, 385, 388 and
> solidrun,clearfog-a1.
> The other two are compatible to the same, plus an additional string
> including the pro/base as suffix.
> 
> Add two bindings, one for the explicit pro and base variants using a
> total of 5 compatibles, and one for the generic name using just 4.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com><mailto:josua at solid-run.com>
> 
> 
> 
> There's nothing here that explains to me _why_ there are three sets of
> compatibles for only two boards. Why is this the case?
> 
> I have no idea how we ended up with these 3 combinations:
> clearfog-a1, armada388, ...
> clearfog-base-a1, clearfog-base-a1, armada388, ...
> clearfog-pro-a1, clearfog-base-a1, armada388, ...
> I can only assume it is because these boards are so similar they can boot
> from each others device-tree without large functional impact.

I think Krzysztof has dug more into this, but please just create two
combinations that make sense and have common elements (which they
already do to be fair). It doesn't really matter if some combination
that doesn't make sense is used out of tree.

Cheers,
Conor.

> 
> Note we did end up with 3 individual filenames because the Pro was supported first,
> without a suffix - and then both were supported with specific suffix.
> 
> 
> Also, binding patches need to be sent to the devicetree mailing list.
> get_maintainer.pl should have told you that, no?
> 
> I will fix it in v3, or do a resend.
> It did tell me, but I wrongly decided to pick only linux-arm-kernel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231226/ff840862/attachment.sig>

From festevam at gmail.com  Tue Dec 26 05:24:32 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 26 Dec 2023 10:24:32 -0300
Subject: [PATCH v3 2/2] arm64: dts: imx93-var-som: Add Variscite VAR-SOM-MX93
In-Reply-To: <20231224124114.31119-3-othacehe@gnu.org>
References: <20231224124114.31119-1-othacehe@gnu.org> <20231224124114.31119-3-othacehe@gnu.org>
Message-ID: <CAOMZO5AmpdE2uMgx8+P-zXf8mYRvsJDBUf7xeRpaHC3jN-7_ww@mail.gmail.com>

On Sun, Dec 24, 2023 at 9:41?AM Mathieu Othacehe <othacehe at gnu.org> wrote:

> +/{
> +       model = "Variscite VAR-SOM-MX93 on Symphony evaluation board";
> +       compatible = "variscite,var-som-mx93-symphony",
> +                    "variscite,var-som-mx93", "fsl,imx93";
> +
> +       aliases {
> +               ethernet1 = &fec;

You could pass ethernet0 here as well.


> +&lpi2c1 {
> +       #address-cells = <1>;
> +       #size-cells = <0>;

These are present in imx93.dtsi. You can drop them from here.

> +&lpi2c5 {
> +       #address-cells = <1>;
> +       #size-cells = <0>;

Ditto.

Reviewed-by: Fabio Estevam <festevam at gmail.com>


From didi.debian at cknow.org  Tue Dec 26 05:32:32 2023
From: didi.debian at cknow.org (Diederik de Haas)
Date: Tue, 26 Dec 2023 14:32:32 +0100
Subject: [PATCH v2 0/4] arm64: rockchip: Pine64 pinetab2 support
In-Reply-To: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
References: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
Message-ID: <2905432.tPBmtbmofK@bagend>

On Saturday, 23 December 2023 16:20:14 CET Manuel Traut wrote:
> This adds support for the BOE TH101MB31IG002 LCD Panel used in Pinetab2 [1]
> and Pinetab-V [2] as well as the devictrees for the Pinetab2 v0.1 and v2.0.

I have a PineTab2 4GB/64GB model and I run a Debian Trixie system
*from an SDcard* (danctnix system is on eMMC). On it, I have a 6.6
kernel with my own patch set and a 6.7-rc7 kernel with this patch set.

Everything seems to work properly. I've now also tested the HDMI output
connector and that worked too :) So based on that, you can add my
Tested-By: Diederik de Haas <didi.debian at cknow.org>

I do see an error in dmesg wrt mmc. I had one with my own patch set
too, but a different one and it seems the mainline patch set fixes that,
but then runs into another issue: 
[    5.570059] dwmmc_rockchip fe2c0000.mmc: could not set regulator OCR (-22)
[    5.570835] dwmmc_rockchip fe2c0000.mmc: failed to enable vmmc regulator
[    5.616373] dwmmc_rockchip fe2c0000.mmc: could not set regulator OCR (-22)
[    5.621903] dwmmc_rockchip fe2c0000.mmc: failed to enable vmmc regulator

Both also have an error wrt `goodix_911_cfg.bin` firmware, but the error
could be because Debian kernel 'upgraded' a warning to an error.
I've searched online for that filename, but haven't found anything.
The touchscreen works, so I guess that one can be ignored.

kernel 6.7-rc7 + mainline patch set:
===========================================================
# uname -a
Linux pinetab2 6.7-rc7+unreleased-arm64 #1 SMP Debian 6.7~rc7-1~pine64 (2023-12-24) aarch64 GNU/Linux
# dmesg --level emerg,alert,crit
# dmesg --level emerg,alert,crit,err
[    5.570059] dwmmc_rockchip fe2c0000.mmc: could not set regulator OCR (-22)
[    5.570835] dwmmc_rockchip fe2c0000.mmc: failed to enable vmmc regulator
[    5.616373] dwmmc_rockchip fe2c0000.mmc: could not set regulator OCR (-22)
[    5.621903] dwmmc_rockchip fe2c0000.mmc: failed to enable vmmc regulator
[   19.569452] Goodix-TS 1-005d: firmware: failed to load goodix_911_cfg.bin (-2)
[   19.575504] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[   19.613497] Goodix-TS 1-005d: firmware: failed to load goodix_911_cfg.bin (-2)
# dmesg | grep mmc
[    3.782844] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[    3.783027] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[    3.783132] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[    3.783314] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 24,32 bit host data width,256 deep fifo
[    3.853034] dwmmc_rockchip fe2b0000.mmc: IDMAC supports 32-bit address mode.
[    3.853859] dwmmc_rockchip fe2b0000.mmc: Using internal DMA controller.
[    3.854492] dwmmc_rockchip fe2b0000.mmc: Version ID is 270a
[    3.856863] dwmmc_rockchip fe2b0000.mmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo
[    3.861731] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[    3.862459] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[    3.863088] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[    3.863656] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 24,32 bit host data width,256 deep fifo
[    3.870506] dwmmc_rockchip fe2c0000.mmc: Failed getting OCR mask: -22
[    4.015316] dwmmc_rockchip fe2b0000.mmc: IDMAC supports 32-bit address mode.
[    4.016042] dwmmc_rockchip fe2b0000.mmc: Using internal DMA controller.
[    4.016660] dwmmc_rockchip fe2b0000.mmc: Version ID is 270a
[    4.017223] dwmmc_rockchip fe2b0000.mmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo
[    4.034954] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[    4.035772] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[    4.037119] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[    4.039868] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 24,32 bit host data width,256 deep fifo
[    4.041248] dwmmc_rockchip fe2c0000.mmc: Failed getting OCR mask: -22
[    5.172937] dwmmc_rockchip fe2b0000.mmc: IDMAC supports 32-bit address mode.
[    5.175108] dwmmc_rockchip fe2b0000.mmc: Using internal DMA controller.
[    5.175750] dwmmc_rockchip fe2b0000.mmc: Version ID is 270a
[    5.176311] dwmmc_rockchip fe2b0000.mmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo
[    5.179484] dwmmc_rockchip fe2b0000.mmc: Got CD GPIO
[    5.193439] mmc_host mmc0: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0)
[    5.259322] mmc_host mmc0: Bus speed (slot 0) = 150000000Hz (slot req 150000000Hz, actual 150000000HZ div = 0)
[    5.332873] dwmmc_rockchip fe2b0000.mmc: Successfully tuned phase to 254
[    5.332922] mmc0: new ultra high speed SDR104 SDHC card at address 59b4
[    5.335025] mmcblk0: mmc0:59b4 00000 14.9 GiB
[    5.345735]  mmcblk0: p1 p2
[    5.563710] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[    5.564608] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[    5.565399] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[    5.566101] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 24,32 bit host data width,256 deep fifo
[    5.568350] dwmmc_rockchip fe2c0000.mmc: Failed getting OCR mask: -22
[    5.569190] mmc_host mmc2: card is non-removable.
[    5.570059] dwmmc_rockchip fe2c0000.mmc: could not set regulator OCR (-22)
[    5.570835] dwmmc_rockchip fe2c0000.mmc: failed to enable vmmc regulator
[    5.585194] mmc_host mmc2: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0)
[    5.616373] dwmmc_rockchip fe2c0000.mmc: could not set regulator OCR (-22)
[    5.621903] dwmmc_rockchip fe2c0000.mmc: failed to enable vmmc regulator
[    5.635189] mmc_host mmc2: Bus speed (slot 0) = 375000Hz (slot req 375000Hz, actual 375000HZ div = 0)
[    5.670372] mmc2: Failed to initialize a non-removable card
[    6.080928] EXT4-fs (mmcblk0p2): mounted filesystem 9aca1904-b511-411f-bb28-4ecfbf1b4061 ro with ordered data mode. Quota mode: none.
[    9.969704] EXT4-fs (mmcblk0p2): re-mounted 9aca1904-b511-411f-bb28-4ecfbf1b4061 r/w. Quota mode: none.
[   11.095737] EXT4-fs (mmcblk0p2): resizing filesystem from 3903227 to 3903227 blocks
[   19.432869] mmc1: SDHCI controller on fe310000.mmc [fe310000.mmc] using ADMA
[   19.569396] mmc1: new HS200 MMC card at address 0001
[   19.574273] mmcblk1: mmc1:0001 SPeMMC 58.2 GiB
[   19.737723]  mmcblk1: p1 p2
[   19.744563] mmcblk1boot0: mmc1:0001 SPeMMC 4.00 MiB
[   19.757787] mmcblk1boot1: mmc1:0001 SPeMMC 4.00 MiB
[   19.833373] mmcblk1rpmb: mmc1:0001 SPeMMC 4.00 MiB, chardev (240:0)
===========================================================
kernel 6.6 + my patch set:
===========================================================
# uname -a
Linux pinetab2 6.6.0-0-pine64-arm64 #1 SMP Debian 6.6-1~pine64 (2023-11-04) aarch64
# dmesg --level emerg,alert,crit
# dmesg --level emerg,alert,crit,err
[    5.632076] mmc0: tuning execution failed: -5
[    5.632089] mmc0: error -5 whilst initialising SD card
[    5.712059] mmc0: tuning execution failed: -5
[   21.192647] Goodix-TS 1-005d: firmware: failed to load goodix_911_cfg.bin (-2)
[   21.196489] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[   21.212984] Goodix-TS 1-005d: firmware: failed to load goodix_911_cfg.bin (-2)
[   21.632392] ov5648 2-0036: failed to find 168000000 clk rate in endpoint link-frequencies
# dmesg | grep mmc
[    4.184334] dwmmc_rockchip fe2b0000.mmc: IDMAC supports 32-bit address mode.
[    4.185120] dwmmc_rockchip fe2b0000.mmc: Using internal DMA controller.
[    4.185745] dwmmc_rockchip fe2b0000.mmc: Version ID is 270a
[    4.186375] dwmmc_rockchip fe2b0000.mmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo
[    4.186549] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[    4.188064] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[    4.188702] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[    4.189380] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo
[    4.235598] dwmmc_rockchip fe2b0000.mmc: IDMAC supports 32-bit address mode.
[    4.236317] dwmmc_rockchip fe2b0000.mmc: Using internal DMA controller.
[    4.236988] dwmmc_rockchip fe2b0000.mmc: Version ID is 270a
[    4.237594] dwmmc_rockchip fe2b0000.mmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo
[    4.245532] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[    4.246253] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[    4.246861] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[    4.247415] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo
[    4.368444] dwmmc_rockchip fe2b0000.mmc: IDMAC supports 32-bit address mode.
[    4.370700] dwmmc_rockchip fe2b0000.mmc: Using internal DMA controller.
[    4.371345] dwmmc_rockchip fe2b0000.mmc: Version ID is 270a
[    4.371969] dwmmc_rockchip fe2b0000.mmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo
[    4.374128] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[    4.375122] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[    4.375752] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[    4.377884] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo
[    5.542858] dwmmc_rockchip fe2b0000.mmc: IDMAC supports 32-bit address mode.
[    5.543575] dwmmc_rockchip fe2b0000.mmc: Using internal DMA controller.
[    5.543970] dwmmc_rockchip fe2c0000.mmc: IDMAC supports 32-bit address mode.
[    5.544176] dwmmc_rockchip fe2b0000.mmc: Version ID is 270a
[    5.544894] dwmmc_rockchip fe2c0000.mmc: Using internal DMA controller.
[    5.545867] dwmmc_rockchip fe2b0000.mmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo
[    5.546117] dwmmc_rockchip fe2c0000.mmc: Version ID is 270a
[    5.548155] dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo
[    5.549753] dwmmc_rockchip fe2b0000.mmc: Got CD GPIO
[    5.550997] dwmmc_rockchip fe2c0000.mmc: allocated mmc-pwrseq
[    5.551557] mmc_host mmc2: card is non-removable.
[    5.563821] mmc_host mmc0: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0)
[    5.630780] mmc_host mmc0: Bus speed (slot 0) = 150000000Hz (slot req 150000000Hz, actual 150000000HZ div = 0)
[    5.632066] dwmmc_rockchip fe2b0000.mmc: All phases bad!
[    5.632076] mmc0: tuning execution failed: -5
[    5.632089] mmc0: error -5 whilst initialising SD card
[    5.646986] mmc_host mmc0: Bus speed (slot 0) = 375000Hz (slot req 375000Hz, actual 375000HZ div = 0)
[    5.710777] mmc_host mmc0: Bus speed (slot 0) = 150000000Hz (slot req 150000000Hz, actual 150000000HZ div = 0)
[    5.712050] dwmmc_rockchip fe2b0000.mmc: All phases bad!
[    5.712059] mmc0: tuning execution failed: -5
[    5.728169] mmc_host mmc0: Bus speed (slot 0) = 375000Hz (slot req 375000Hz, actual 375000HZ div = 0)
[    5.768379] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    5.768503] mmc0: new high speed SDHC card at address 59b4
[    5.770692] mmcblk0: mmc0:59b4 00000 14.9 GiB
[    5.772990] mmc_host mmc2: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0)
[    5.791753]  mmcblk0: p1 p2
[    6.962745] EXT4-fs (mmcblk0p2): mounted filesystem 9aca1904-b511-411f-bb28-4ecfbf1b4061 ro with ordered data mode. Quota mode: none.
[    8.264296] mmc2: Skipping voltage switch
[    8.280973] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    8.293741] mmc2: new high speed SDIO card at address 0001
[   11.101267] EXT4-fs (mmcblk0p2): re-mounted 9aca1904-b511-411f-bb28-4ecfbf1b4061 r/w. Quota mode: none.
[   12.839514] EXT4-fs (mmcblk0p2): resizing filesystem from 3903227 to 3903227 blocks
[   21.248940] mmc1: SDHCI controller on fe310000.mmc [fe310000.mmc] using ADMA
[   21.345979] mmc1: new HS200 MMC card at address 0001
[   21.357326] mmcblk1: mmc1:0001 SPeMMC 58.2 GiB
[   21.462230]  mmcblk1: p1 p2
[   21.466068] mmcblk1boot0: mmc1:0001 SPeMMC 4.00 MiB
[   21.478585] mmcblk1boot1: mmc1:0001 SPeMMC 4.00 MiB
[   21.516472] mmcblk1rpmb: mmc1:0001 SPeMMC 4.00 MiB, chardev (240:0)
===========================================================

Cheers,
  Diederik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231226/a599edd0/attachment.sig>

From olteanv at gmail.com  Tue Dec 26 07:30:55 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Tue, 26 Dec 2023 17:30:55 +0200
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf>
 <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
Message-ID: <20231226153055.4yihsmu6kiak6hkf@skbuf>

On Tue, Dec 26, 2023 at 01:11:08PM +0530, Jagan Teki wrote:
> &fec {
>           pinctrl-names = "default";
>           pinctrl-0 = <&pinctrl_enet>;
>           phy-mode = "mii";
>           status = "okay";

tl;dr: I think what is missing is:

		fixed-link {
			speed = <100>;
			full-duplex;
		};

> 
>           mdio {
>              #address-cells = <1>;
>              #size-cells = <0>;
> 
>             ethphy0: ethernet-phy at 0 {
>                       compatible = "ethernet-phy-ieee802.3-c22";
>                       reg = <0>;
>             };
> 
>             ethphy1: ethernet-phy at 1 {
>                     compatible = "ethernet-phy-ieee802.3-c22";
>                     reg = <1>;
>            };
>         };
> };
> 
> root at imx6solo:~# ip link set dev eth0 down
> root at imx6solo:~# ip link set dev ethphy0 down
> root at imx6solo:~# ip link set dev ethphy1 down
> root at imx6solo:~# ip link set dev ethphy0 address 00:11:22:33:44:55
> root at imx6solo:~# ip link set dev ethphy1 address 00:11:22:33:44:66
> root at imx6solo:~# ip addr add dev ethphy0 192.168.1.1/16
> root at imx6solo:~# ip addr add dev ethphy1 192.168.1.5/16
> root at imx6solo:~# ip link set dev eth0 up
> [  617.126753] dp83848_config_init: ret 0
> [  617.130831] TI DP83849I 10/100 Mbps PHY 2188000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
> root at imx6solo:~# [  619.207519] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> [  619.215698] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

eth0 is the FEC port, right?

> root at imx6solo:~# ip link set dev ethphy0 up
> [  634.114608] sja1105 spi1.0 ethphy0: configuring for phy/mii link mode
> [  634.126617] ------------[ cut here ]------------
> [  634.131463] WARNING: CPU: 0 PID: 330 at drivers/net/phy/phy.c:1157 phy_start+0x58/0xb4
> [  634.139627] called from state RUNNING
> [  634.143310] Modules linked in: bnep tag_sja1105 sja1105 pcs_xpcs brcmfmac brcmutil imx_sdma coda_vpu v4l2_jpeg imx_vdoa evbug
> [  634.154815] CPU: 0 PID: 330 Comm: ip Not tainted 6.1.58 #1
> [  634.160321] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [  634.166866]  unwind_backtrace from show_stack+0x10/0x14
> [  634.172125]  show_stack from dump_stack_lvl+0x58/0x70
> [  634.177205]  dump_stack_lvl from __warn+0x70/0x1a4
> [  634.182023]  __warn from warn_slowpath_fmt+0x1bc/0x270
> [  634.187181]  warn_slowpath_fmt from phy_start+0x58/0xb4
> [  634.192427]  phy_start from dsa_port_enable_rt+0x54/0x9c
> [  634.197765]  dsa_port_enable_rt from dsa_slave_open+0xb8/0x17c
> [  634.203624]  dsa_slave_open from __dev_open+0xec/0x1ac
> [  634.208788]  __dev_open from __dev_change_flags+0x18c/0x224
> [  634.214377]  __dev_change_flags from dev_change_flags+0x14/0x44
> [  634.220313]  dev_change_flags from do_setlink+0x254/0xe4c
> [  634.225737]  do_setlink from rtnl_newlink+0x598/0x80c
> [  634.230811]  rtnl_newlink from rtnetlink_rcv_msg+0x168/0x574
> [  634.236485]  rtnetlink_rcv_msg from netlink_rcv_skb+0xb8/0x11c
> [  634.242337]  netlink_rcv_skb from netlink_unicast+0x1a8/0x2dc
> [  634.248108]  netlink_unicast from netlink_sendmsg+0x1d8/0x450
> [  634.253884]  netlink_sendmsg from ____sys_sendmsg+0x188/0x258
> [  634.259656]  ____sys_sendmsg from ___sys_sendmsg+0x6c/0xa4
> [  634.265164]  ___sys_sendmsg from sys_sendmsg+0x50/0x98
> [  634.270324]  sys_sendmsg from ret_fast_syscall+0x0/0x1c
> [  634.275569] Exception stack(0xf1071fa8 to 0xf1071ff0)
> [  634.280637] 1fa0:                   00000000 00000001 00000003 bef4d710 00000000 00000000
> [  634.288828] 1fc0: 00000000 00000001 b6f415a0 00000128 626ad475 00000000 00531cc0 00531cc0
> [  634.297016] 1fe0: 00000128 bef4d6b0 b6e3f6d3 b6db1ae6
> [  634.302150] irq event stamp: 3327
> [  634.305485] hardirqs last  enabled at (3335): [<c0195dbc>] __up_console_sem+0x50/0x60
> [  634.313404] hardirqs last disabled at (3344): [<c0195da8>] __up_console_sem+0x3c/0x60
> [  634.321318] softirqs last  enabled at (3230): [<c01017d0>] __do_softirq+0x2c0/0x57c
> [  634.329055] softirqs last disabled at (3187): [<c012f204>] __irq_exit_rcu+0x138/0x17c
> [  634.336971] ---[ end trace 0000000000000000 ]---
> root at imx6solo:~# ip link set dev ethphy1 up
> [  644.613564] sja1105 spi1.0 ethphy1: configuring for phy/mii link mode
> root at imx6solo:~# [  646.727549] sja1105 spi1.0 ethphy1: Link is Up -
> 100Mbps/Full - flow control off
> [  646.735033] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy1: link becomes ready

Ok. The WARN_ON() is saying that the DSA user port's phy_start() found
the attached PHY already in the RUNNING state. As if there was already
someone else driving it.

That "someone else" seems to be the FEC driver from the log above, which
for some reason has connected to the DP83849I by itself, and phylink/phylib
hasn't denied the second attempt to connect to the same PHY for some
reason.

If you look at fec_enet_mii_probe(), I see it has 2 code paths, one for
when fep->phy_node (defined as the "phy-handle" reference) is non-NULL,
and one for when it is NULL. What you're missing is a fixed-link
specifier in the device tree for FEC, otherwise it tries to call
phy_connect() to some random MDIO address on the bus and that breaks
things in some way which I don't understand.

The code which should have prevented this from happening is in
phy_attach_direct():

	if (phydev->attached_dev) {
		dev_err(&dev->dev, "PHY already attached\n");
		err = -EBUSY;
		goto error;
	}


From Frank.li at nxp.com  Tue Dec 26 08:12:19 2023
From: Frank.li at nxp.com (Frank Li)
Date: Tue, 26 Dec 2023 11:12:19 -0500
Subject: [PATCH v6 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie
 endpoint compatible string
In-Reply-To: <6a61f325-a58b-4aa6-9a0a-7a3086f63829@linaro.org>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
 <20231224183242.1675372-16-Frank.Li@nxp.com>
 <6a61f325-a58b-4aa6-9a0a-7a3086f63829@linaro.org>
Message-ID: <ZYr7Y+mJea6fChjS@lizhi-Precision-Tower-5810>

On Mon, Dec 25, 2023 at 08:16:17PM +0100, Krzysztof Kozlowski wrote:
> On 24/12/2023 19:32, Frank Li wrote:
> > Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
> > Add reg-name: "atu", "dbi2", "dma" and "app".
> > Reuse PCI linux,pci-domain as controller id at endpoint.
> > 
> > Signed-off-by: Frank Li <Frank.Li at nxp.com>
> > ---
> > 
> 
> ...
> 
> > +# reuse PCI linux,pci-domain as controller id at Endpoint
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          enum:
> > +            - fsl,imx95-pcie-ep
> > +    then:
> > +      properties:
> > +        linux,pci-domain: true
> 
> Same comment: why do you need? Don't ignore my feedback. You responded
> you will fix it, but it is still here...

DTB_CHECK report error after I remove it. linux,pci-domain is only define
in pci, not pci-ep.

So I add comments about this. linux,pci-domain was resued ad controller id.

If include pci.yaml, there are too much other properties was involved, but
not used by pci-ep.

Frank

> 
> Best regards,
> Krzysztof
> 


From danct12 at riseup.net  Tue Dec 26 08:32:10 2023
From: danct12 at riseup.net (Dang Huynh)
Date: Tue, 26 Dec 2023 16:32:10 +0000
Subject: [PATCH v2 0/4] arm64: rockchip: Pine64 pinetab2 support
In-Reply-To: <2905432.tPBmtbmofK@bagend>
References: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net> <2905432.tPBmtbmofK@bagend>
Message-ID: <6875992.lOV4Wx5bFT@melttower>

On Tuesday, December 26, 2023 1:32:32 PM UTC Diederik de Haas wrote:
> [    5.570059] dwmmc_rockchip fe2c0000.mmc: could not set regulator OCR
> (-22) [    5.570835] dwmmc_rockchip fe2c0000.mmc: failed to enable vmmc
> regulator [    5.616373] dwmmc_rockchip fe2c0000.mmc: could not set
> regulator OCR (-22) [    5.621903] dwmmc_rockchip fe2c0000.mmc: failed to
> enable vmmc regulator
This is the WLAN SDIO, the error shows up when the device is not powered on.

> Both also have an error wrt `goodix_911_cfg.bin` firmware, but the error
> could be because Debian kernel 'upgraded' a warning to an error.
> I've searched online for that filename, but haven't found anything.
> The touchscreen works, so I guess that one can be ignored.
This can be ignored, it's for touch panels where it's config is not on flash 
(typically touch panel calibration data).




From josua at solid-run.com  Tue Dec 26 08:39:36 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 16:39:36 +0000
Subject: [PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <20231226-dictate-spearman-0fe1ec4bee3b@spud>
References: <20231224143850.5671-3-josua@solid-run.com>
 <20231224143850.5671-4-josua@solid-run.com>
 <20231224-tibia-thursday-bea9dde2fbf1@spud>
 <655855b6-ff68-4a3c-9ec7-fc72967b702a@solid-run.com>
 <20231226-dictate-spearman-0fe1ec4bee3b@spud>
Message-ID: <701c3157-cfd8-42ec-bdb0-5be58fef4197@solid-run.com>

Am 26.12.23 um 13:10 schrieb Conor Dooley:
> On Sun, Dec 24, 2023 at 03:58:14PM +0000, Josua Mayer wrote:
>> Am 24.12.23 um 15:42 schrieb Conor Dooley:
>>
>> On Sun, Dec 24, 2023 at 03:38:45PM +0100, Josua Mayer wrote:
>>
>>
>> Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
>> boards.
>>
>> While they are just two variants, we have 3 device-tree:
>> - armada-388-clearfog.dts
>> - armada-388-clearfog-base.dts
>> - armada-388-clearfog-pro.dts
>>
>> While the first one is identical to the pro variant, the filename is
>> not, and neither are the compatible strings.
>>
>> The first is compatible to armada-380, 385, 388 and
>> solidrun,clearfog-a1.
>> The other two are compatible to the same, plus an additional string
>> including the pro/base as suffix.
>>
>> Add two bindings, one for the explicit pro and base variants using a
>> total of 5 compatibles, and one for the generic name using just 4.
>>
>> Signed-off-by: Josua Mayer <josua at solid-run.com><mailto:josua at solid-run.com>
>>
>>
>>
>> There's nothing here that explains to me _why_ there are three sets of
>> compatibles for only two boards. Why is this the case?
>>
>> I have no idea how we ended up with these 3 combinations:
>> clearfog-a1, armada388, ...
>> clearfog-base-a1, clearfog-base-a1, armada388, ...
>> clearfog-pro-a1, clearfog-base-a1, armada388, ...
>> I can only assume it is because these boards are so similar they can boot
>> from each others device-tree without large functional impact.
> I think Krzysztof has dug more into this, but please just create two
> combinations that make sense and have common elements (which they
> already do to be fair). It doesn't really matter if some combination
> that doesn't make sense is used out of tree.

Okay, thanks.
I will create another revision and rewrite descriptions to be more clear,
especially considering questions raised by Krzysztof.

>
> Cheers,
> Conor.
>
>> Note we did end up with 3 individual filenames because the Pro was supported first,
>> without a suffix - and then both were supported with specific suffix.
>>
>>
>> Also, binding patches need to be sent to the devicetree mailing list.
>> get_maintainer.pl should have told you that, no?
>>
>> I will fix it in v3, or do a resend.
>> It did tell me, but I wrongly decided to pick only linux-arm-kernel.



From andrew at lunn.ch  Tue Dec 26 08:49:56 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 26 Dec 2023 17:49:56 +0100
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <20231226153055.4yihsmu6kiak6hkf@skbuf>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf>
 <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
 <20231226153055.4yihsmu6kiak6hkf@skbuf>
Message-ID: <5ec0c324-b07a-4001-b495-f34bfdd8ffe0@lunn.ch>

> Ok. The WARN_ON() is saying that the DSA user port's phy_start() found
> the attached PHY already in the RUNNING state. As if there was already
> someone else driving it.
> 
> That "someone else" seems to be the FEC driver from the log above, which
> for some reason has connected to the DP83849I by itself, and phylink/phylib
> hasn't denied the second attempt to connect to the same PHY for some
> reason.
> 
> If you look at fec_enet_mii_probe(), I see it has 2 code paths, one for
> when fep->phy_node (defined as the "phy-handle" reference) is non-NULL,
> and one for when it is NULL. What you're missing is a fixed-link
> specifier in the device tree for FEC, otherwise it tries to call
> phy_connect() to some random MDIO address on the bus and that breaks
> things in some way which I don't understand.

At has an open coded phy_find_first(), or something similar. The FEC
is a bit of a mess in this respect, but it is hard to fix because of
backwards compatibility.

> The code which should have prevented this from happening is in
> phy_attach_direct():
> 
> 	if (phydev->attached_dev) {
> 		dev_err(&dev->dev, "PHY already attached\n");
> 		err = -EBUSY;
> 		goto error;
> 	}

Yes, that is odd.

     Andrew


From andrew at lunn.ch  Tue Dec 26 09:00:17 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 26 Dec 2023 18:00:17 +0100
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <20231226153055.4yihsmu6kiak6hkf@skbuf>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf>
 <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
 <20231226153055.4yihsmu6kiak6hkf@skbuf>
Message-ID: <f7b894d0-9378-4c4d-8a3e-e35bb9593c72@lunn.ch>

> The code which should have prevented this from happening is in
> phy_attach_direct():
> 
> 	if (phydev->attached_dev) {
> 		dev_err(&dev->dev, "PHY already attached\n");
> 		err = -EBUSY;
> 		goto error;
> 	}

The problem might be dsa_shared_port_phylink_register():

        err = phylink_of_phy_connect(dp->pl, port_dn, 0);
        if (err && err != -ENODEV) {
                pr_err("could not attach to PHY: %d\n", err);
                goto err_phy_connect;
        }

        return 0;

Since it is not -ENODEV, it just keep going.

      Andrew


From olteanv at gmail.com  Tue Dec 26 09:05:09 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Tue, 26 Dec 2023 19:05:09 +0200
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <f7b894d0-9378-4c4d-8a3e-e35bb9593c72@lunn.ch>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf>
 <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
 <20231226153055.4yihsmu6kiak6hkf@skbuf>
 <f7b894d0-9378-4c4d-8a3e-e35bb9593c72@lunn.ch>
Message-ID: <20231226170509.vysmvg6soz54xekb@skbuf>

On Tue, Dec 26, 2023 at 06:00:17PM +0100, Andrew Lunn wrote:
> > The code which should have prevented this from happening is in
> > phy_attach_direct():
> > 
> > 	if (phydev->attached_dev) {
> > 		dev_err(&dev->dev, "PHY already attached\n");
> > 		err = -EBUSY;
> > 		goto error;
> > 	}
> 
> The problem might be dsa_shared_port_phylink_register():
> 
>         err = phylink_of_phy_connect(dp->pl, port_dn, 0);
>         if (err && err != -ENODEV) {
>                 pr_err("could not attach to PHY: %d\n", err);
>                 goto err_phy_connect;
>         }
> 
>         return 0;
> 
> Since it is not -ENODEV, it just keep going.
> 
>       Andrew

"Shared" ports are DSA and CPU ports, the report is on a user port.
There, if phylink_of_phy_connect() fails, we try dsa_user_phy_connect(),
but only if the driver provides a ds->user_mii_bus, which sja1105 does not.
So the failure should be nice and clean. It might be worth posting a
full boot log though, since this is really strange.


From josua at solid-run.com  Tue Dec 26 10:11:32 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 19:11:32 +0100
Subject: [PATCH v3 1/8] dt-bindings: marvell: a38x: convert the soc
 compatibles description to yaml
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
Message-ID: <20231226-support-clearfog-gtr-l8-sfp-v3-1-fd1ac2d6bf2e@solid-run.com>

Convert the existing txt binding for armada-38x socs to DT schema
format.

Note that the current bindings only document the SoC (armada380,
armada385, armada388). This is undesirable, instead there should be
entries for actual boards.

For now only convert to yaml, the content can be corrected separately.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../devicetree/bindings/arm/marvell/armada-38x.txt | 27 ------------------
 .../bindings/arm/marvell/armada-38x.yaml           | 33 ++++++++++++++++++++++
 2 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
deleted file mode 100644
index 202953f1887e..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Marvell Armada 38x Platforms Device Tree Bindings
--------------------------------------------------
-
-Boards with a SoC of the Marvell Armada 38x family shall have the
-following property:
-
-Required root node property:
-
- - compatible: must contain "marvell,armada380"
-
-In addition, boards using the Marvell Armada 385 SoC shall have the
-following property before the previous one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada385"
-
-In addition, boards using the Marvell Armada 388 SoC shall have the
-following property before the previous one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada388"
-
-Example:
-
-compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
new file mode 100644
index 000000000000..5af222e6db18
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/armada-38x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 38x Platforms
+
+maintainers:
+  - Gregory CLEMENT <gregory.clement at bootlin.com>
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+
+      - description: Armada 380 SoC
+        items:
+          - const: marvell,armada380
+
+      - description: Armada 385 SoC
+        items:
+          - const: marvell,armada385
+          - const: marvell,armada380
+
+      - description: Armada 388 SoC
+        items:
+          - const: marvell,armada388
+          - const: marvell,armada385
+          - const: marvell,armada380
+
+additionalProperties: true

-- 
2.35.3



From josua at solid-run.com  Tue Dec 26 10:11:33 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 19:11:33 +0100
Subject: [PATCH v3 2/8] dt-bindings: marvell: a38x: add solidrun armada 385
 clearfog gtr boards
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
Message-ID: <20231226-support-clearfog-gtr-l8-sfp-v3-2-fd1ac2d6bf2e@solid-run.com>

Add DT compatible for SolidRun Armada-385 based Clearfog GTR L8 and S4
boards.

Despite similar name these two boards are designed differently from the
armada 388 clearfog base and pro, they only share a name and general use
case.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
index 5af222e6db18..5bc69c4fe34d 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -30,4 +30,12 @@ properties:
           - const: marvell,armada385
           - const: marvell,armada380
 
+      - description: SolidRun Armada 385 based single-board computers
+        items:
+          - enum:
+             - solidrun,clearfog-gtr-l8
+             - solidrun,clearfog-gtr-s4
+          - const: marvell,armada385
+          - const: marvell,armada380
+
 additionalProperties: true

-- 
2.35.3



From josua at solid-run.com  Tue Dec 26 10:11:34 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 19:11:34 +0100
Subject: [PATCH v3 3/8] dt-bindings: marvell: a38x: add solidrun armada 388
 clearfog boards
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
Message-ID: <20231226-support-clearfog-gtr-l8-sfp-v3-3-fd1ac2d6bf2e@solid-run.com>

Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
boards, which are already in place in-tree.

There are already 3 distinct dts in tree for these *two* boards,
declaring particular compatible strings:
- armada-388-clearfog.dts:
  compatible = "solidrun,clearfog-a1", "marvell,armada388",
               "marvell,armada385, "marvell,armada380";
- armada-388-clearfog-base.dts:
  compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1",
               "marvell,armada388", "marvell,armada385,
               "marvell,armada380";
- armada-388-clearfog-pro.dts:
  compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1",
               "marvell,armada388", "marvell,armada385,
               "marvell,armada380";

This has historic reasons, the first entry is a legacy name for the
"pro" version, old versions of u-boot built when only one variant
existed explicitly boot by this name.

Note that both compatibles and model field include the string "A1".
At least up to revision 2.0 of the board, this had been printed
on the pcb. However in marketing material and conversations it is
usually omitted. "Clearfog Pro" and "Clearfog Pro A1" always mean
exactly the same product.

Technically Base and Pro variants are similar enough that they can
successfully boot with each other's dts. Hence it makes (some)
sense for them to share the "clearfog-a1" compatible.

Add bindings for the explicit variants including base / pro suffix.
The legacy "armada-388-clearfog.dts" is not supported by these
bindings" as it does not make sense having two bindings for one board.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../devicetree/bindings/arm/marvell/armada-38x.yaml          | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
index 5bc69c4fe34d..f77976138bb3 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -38,4 +38,16 @@ properties:
           - const: marvell,armada385
           - const: marvell,armada380
 
+      - description:
+          SolidRun Armada 388 based single-board computers
+
+        items:
+          - enum:
+             - solidrun,clearfog-base-a1
+             - solidrun,clearfog-pro-a1
+          - const: solidrun,clearfog-a1
+          - const: marvell,armada388
+          - const: marvell,armada385
+          - const: marvell,armada380
+
 additionalProperties: true

-- 
2.35.3



From josua at solid-run.com  Tue Dec 26 10:11:35 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 19:11:35 +0100
Subject: [PATCH v3 4/8] arm: dts: marvell: clearfog-gtr: add board-specific
 compatible strings
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
Message-ID: <20231226-support-clearfog-gtr-l8-sfp-v3-4-fd1ac2d6bf2e@solid-run.com>

Most arm board have a board-specific compatible string that allows e.g.
userspace to match specific firmware variants or apply specific
policies.

Add board-specific properties to both variants of the Clearfog GTR:
- solidrun,clearfog-gtr-l8
- solidrun,clearfog-gtr-s4

Introduction of a common parent (e.g. "solidrun,clearfog-gtr") is
omitted for brevity.
Since announcement of the two products no additional variants were added
it is assumed that there will always be just two.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 2 ++
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index 1990f7d0cc79..cd5b070f1218 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -4,6 +4,8 @@
 
 / {
 	model = "SolidRun Clearfog GTR L8";
+	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385",
+		     "marvell,armada380";
 };
 
 &mdio {
diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
index b795ad573891..4a9736ec99b6 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
@@ -4,6 +4,8 @@
 
 / {
 	model = "SolidRun Clearfog GTR S4";
+	compatible = "solidrun,clearfog-gtr-s4", "marvell,armada385",
+		     "marvell,armada380";
 };
 
 &sfp0 {

-- 
2.35.3



From josua at solid-run.com  Tue Dec 26 10:11:31 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 19:11:31 +0100
Subject: [PATCH v3 0/8] dt-bindings: marvell: a38x: add solidrun armada 388
 clearfog boards
Message-ID: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>

Dear Maintainers,

The initially merged device-tree for Clearfog GTR devices contained
various subtle mistakes and omissions:

- missing board-specific compatible strings
- missing pinctrl entries
- missing second sfp connector
- invalid sfp loss-of-signal gpio
- mismatch of labels between dsa ports and enclosure

Most notably this had caused functional issues with the sfp connectors.

This patch-set first converts the armada-38x dt-bindings to yaml.
New bindings are added specifically for the Clearfog GTR boards,
and for the already in-tree clearfog base and pro boards' compatible strings.

Secondly pinctrl nodes are added for all referenced gpios for independence
from bootloader defaults. U-Boot is shared between armada-388 clearfog,
and armada-385 clearfog gtr.

Further remove an invalid io from the first sfp connector description,
and add descriptions for the secondary sfp connector which is driven
by dsa switch port number 9.

Finally labels of dsa switch ports were updated to match the enclosure.
That patch is not suitable for stable.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
Changes in v3:
- armada-38x.yaml: removed '|', no need to prerserve formatting
  (reported by Conor Dooley conor+dt at kernel.org)
- update commit descriptions to clarify confusing board names and
  compatible strings
  (reported by Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>)
- send to all relevant lists
  (reported by Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>)
- remove duplicate binding for clearfog / clearfog
- Link to v2 (patches 0-2):
  https://lore.kernel.org/r/20231224143750.5604-1-josua at solid-run.com
- Link to v2 (patches 3-8):
  https://lore.kernel.org/r/20231224143850.5671-3-josua at solid-run.com

Changes in v2:
- removed changes changes to gpio numbers because they were wrong
- added bindings documentation
- Link to v1: https://lore.kernel.org/r/20231223212930.14624-1-josua at solid-run.com

---
Josua Mayer (8):
      dt-bindings: marvell: a38x: convert the soc compatibles description to yaml
      dt-bindings: marvell: a38x: add solidrun armada 385 clearfog gtr boards
      dt-bindings: marvell: a38x: add solidrun armada 388 clearfog boards
      arm: dts: marvell: clearfog-gtr: add board-specific compatible strings
      arm: dts: marvell: clearfog-gtr: sort pinctrl nodes alphabetically
      arm: dts: marvell: clearfog-gtr: add missing pinctrl for all used gpios
      arm: dts: marvell: clearfog-gtr-l8: add support for second sfp connector
      arm: dts: marvell: clearfog-gtr-l8: align port numbers with enclosure

 .../devicetree/bindings/arm/marvell/armada-38x.txt | 27 -------
 .../bindings/arm/marvell/armada-38x.yaml           | 53 ++++++++++++++
 .../dts/marvell/armada-385-clearfog-gtr-l8.dts     | 38 +++++++---
 .../dts/marvell/armada-385-clearfog-gtr-s4.dts     |  2 +
 .../boot/dts/marvell/armada-385-clearfog-gtr.dtsi  | 84 ++++++++++++++++------
 5 files changed, 147 insertions(+), 57 deletions(-)
---
base-commit: 861deac3b092f37b2c5e6871732f3e11486f7082
change-id: 20231226-support-clearfog-gtr-l8-sfp-d87ae715a787

Sincerely,
-- 
Josua Mayer <josua at solid-run.com>



From josua at solid-run.com  Tue Dec 26 10:11:36 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 19:11:36 +0100
Subject: [PATCH v3 5/8] arm: dts: marvell: clearfog-gtr: sort pinctrl nodes
 alphabetically
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
Message-ID: <20231226-support-clearfog-gtr-l8-sfp-v3-5-fd1ac2d6bf2e@solid-run.com>

Cosmetic change to increase future patches readability when adding new
pinctrl nodes.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../boot/dts/marvell/armada-385-clearfog-gtr.dtsi  | 40 +++++++++++-----------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index d1452a04e904..8eabb60765b0 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -141,18 +141,13 @@ i2c at 11100 { /* SFP (CON5/CON6) */
 			};
 
 			pinctrl at 18000 {
-				cf_gtr_switch_reset_pins: cf-gtr-switch-reset-pins {
-					marvell,pins = "mpp18";
-					marvell,function = "gpio";
-				};
-
-				cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
-					marvell,pins = "mpp22";
+				cf_gtr_fan_pwm: cf-gtr-fan-pwm {
+					marvell,pins = "mpp23";
 					marvell,function = "gpio";
 				};
 
-				cf_gtr_fan_pwm: cf-gtr-fan-pwm {
-					marvell,pins = "mpp23";
+				cf_gtr_front_button_pins: cf-gtr-front-button-pins {
+					marvell,pins = "mpp53";
 					marvell,function = "gpio";
 				};
 
@@ -162,13 +157,6 @@ cf_gtr_i2c1_pins: i2c1-pins {
 					marvell,function = "i2c1";
 				};
 
-				cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
-					marvell,pins = "mpp21", "mpp28",
-						       "mpp37", "mpp38",
-						       "mpp39", "mpp40";
-					marvell,function = "sd0";
-				};
-
 				cf_gtr_isolation_pins: cf-gtr-isolation-pins {
 					marvell,pins = "mpp47";
 					marvell,function = "gpio";
@@ -179,18 +167,30 @@ cf_gtr_poe_reset_pins: cf-gtr-poe-reset-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_rear_button_pins: cf-gtr-rear-button-pins {
+					marvell,pins = "mpp36";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
+					marvell,pins = "mpp21", "mpp28",
+						       "mpp37", "mpp38",
+						       "mpp39", "mpp40";
+					marvell,function = "sd0";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
 				};
 
-				cf_gtr_front_button_pins: cf-gtr-front-button-pins {
-					marvell,pins = "mpp53";
+				cf_gtr_switch_reset_pins: cf-gtr-switch-reset-pins {
+					marvell,pins = "mpp18";
 					marvell,function = "gpio";
 				};
 
-				cf_gtr_rear_button_pins: cf-gtr-rear-button-pins {
-					marvell,pins = "mpp36";
+				cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
+					marvell,pins = "mpp22";
 					marvell,function = "gpio";
 				};
 			};

-- 
2.35.3



From josua at solid-run.com  Tue Dec 26 10:11:37 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 19:11:37 +0100
Subject: [PATCH v3 6/8] arm: dts: marvell: clearfog-gtr: add missing
 pinctrl for all used gpios
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
Message-ID: <20231226-support-clearfog-gtr-l8-sfp-v3-6-fd1ac2d6bf2e@solid-run.com>

Various control signals such as sfp module-absence, pci-e reset or led
gpios were missing pinctrl nodes, leaving any u-boot choices in place.

Since U-Boot is shared between multiple board variants, i.e. a388
clearfog pro / base, clearfog gtr l8 / s4, it is better to explicitly
configure functions.
Add explicit pinctrl entries for all gpios currently in use.

Additionally the loss-of-signal gpio specified is invalid, in fact los
only has a pull-up on the board but no gpio connection to the cpu.
Remove this stray reference.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../boot/dts/marvell/armada-385-clearfog-gtr.dtsi  | 42 ++++++++++++++++++++--
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index 8eabb60765b0..39ac97edb463 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -162,6 +162,22 @@ cf_gtr_isolation_pins: cf-gtr-isolation-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_led_pins: led-pins {
+					marvell,pins = "mpp42", "mpp52";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_lte_disable_pins: lte-disable-pins {
+					marvell,pins = "mpp34";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_pci_pins: pci-pins {
+					// pci reset
+					marvell,pins = "mpp33", "mpp35", "mpp44";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_poe_reset_pins: cf-gtr-poe-reset-pins {
 					marvell,pins = "mpp48";
 					marvell,function = "gpio";
@@ -179,6 +195,12 @@ cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
 					marvell,function = "sd0";
 				};
 
+				cf_gtr_sfp0_pins: sfp0-pins {
+					/* sfp modabs, txdisable */
+					marvell,pins = "mpp25", "mpp46";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
@@ -193,6 +215,11 @@ cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
 					marvell,pins = "mpp22";
 					marvell,function = "gpio";
 				};
+
+				cf_gtr_wifi_disable_pins: wifi-disable-pins {
+					marvell,pins = "mpp30", "mpp31";
+					marvell,function = "gpio";
+				};
 			};
 
 			sdhci at d8000 {
@@ -221,21 +248,26 @@ usb3 at f8000 {
 		};
 
 		pcie {
+			pinctrl-0 = <&cf_gtr_pci_pins>;
+			pinctrl-names = "default";
 			status = "okay";
 			/*
 			 * The PCIe units are accessible through
 			 * the mini-PCIe connectors on the board.
 			 */
+			/* CON3 - serdes 0 */
 			pcie at 1,0 {
 				reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
 				status = "okay";
 			};
 
+			/* CON4 - serdes 2 */
 			pcie at 2,0 {
 				reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
 				status = "okay";
 			};
 
+			/* CON2 - serdes 4 */
 			pcie at 3,0 {
 				reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
 				status = "okay";
@@ -243,10 +275,12 @@ pcie at 3,0 {
 		};
 	};
 
+	/* CON5 */
 	sfp0: sfp {
 		compatible = "sff,sfp";
+		pinctrl-0 = <&cf_gtr_sfp0_pins>;
+		pinctrl-names = "default";
 		i2c-bus = <&i2c1>;
-		los-gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
 		mod-def0-gpio = <&gpio0 25 GPIO_ACTIVE_LOW>;
 		tx-disable-gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
 	};
@@ -273,6 +307,8 @@ button-1 {
 
 	gpio-leds {
 		compatible = "gpio-leds";
+		pinctrl-0 = <&cf_gtr_led_pins>;
+		pinctrl-names = "default";
 
 		led1 {
 			function = LED_FUNCTION_CPU;
@@ -408,7 +444,7 @@ &ahci1 {
 };
 
 &gpio0 {
-	pinctrl-0 = <&cf_gtr_fan_pwm>;
+	pinctrl-0 = <&cf_gtr_fan_pwm &cf_gtr_wifi_disable_pins>;
 	pinctrl-names = "default";
 
 	wifi-disable {
@@ -420,7 +456,7 @@ wifi-disable {
 };
 
 &gpio1 {
-	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins>;
+	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins &cf_gtr_lte_disable_pins>;
 	pinctrl-names = "default";
 
 	lte-disable {

-- 
2.35.3



From josua at solid-run.com  Tue Dec 26 10:11:38 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 19:11:38 +0100
Subject: [PATCH v3 7/8] arm: dts: marvell: clearfog-gtr-l8: add support for
 second sfp connector
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
Message-ID: <20231226-support-clearfog-gtr-l8-sfp-v3-7-fd1ac2d6bf2e@solid-run.com>

Clearfog GTR L8 has an extra SFP connector on the managed switch port 9.
Add descriptions for both entities along with pinctrl.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../boot/dts/marvell/armada-385-clearfog-gtr-l8.dts  | 20 +++++++++++++++++++-
 .../boot/dts/marvell/armada-385-clearfog-gtr.dtsi    |  8 +++++++-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index cd5b070f1218..2df388f222ec 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -6,6 +6,16 @@ / {
 	model = "SolidRun Clearfog GTR L8";
 	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385",
 		     "marvell,armada380";
+
+	/* CON25 */
+	sfp1: sfp-1 {
+		compatible = "sff,sfp";
+		pinctrl-0 = <&cf_gtr_sfp1_pins>;
+		pinctrl-names = "default";
+		i2c-bus = <&i2c0>;
+		mod-def0-gpio = <&gpio0 24 GPIO_ACTIVE_LOW>;
+		tx-disable-gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
+	};
 };
 
 &mdio {
@@ -68,11 +78,19 @@ port at 8 {
 				phy-handle = <&switch0phy7>;
 			};
 
+			port at 9 {
+				reg = <9>;
+				label = "lan-sfp";
+				phy-mode = "sgmii";
+				sfp = <&sfp1>;
+				managed = "in-band-status";
+			};
+
 			port at 10 {
 				reg = <10>;
 				phy-mode = "2500base-x";
-
 				ethernet = <&eth1>;
+
 				fixed-link {
 					speed = <2500>;
 					full-duplex;
diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index 39ac97edb463..f3a3cb6ac311 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -201,6 +201,12 @@ cf_gtr_sfp0_pins: sfp0-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_sfp1_pins: sfp1-pins {
+					/* sfp modabs, txdisable */
+					marvell,pins = "mpp24", "mpp54";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
@@ -276,7 +282,7 @@ pcie at 3,0 {
 	};
 
 	/* CON5 */
-	sfp0: sfp {
+	sfp0: sfp-0 {
 		compatible = "sff,sfp";
 		pinctrl-0 = <&cf_gtr_sfp0_pins>;
 		pinctrl-names = "default";

-- 
2.35.3



From josua at solid-run.com  Tue Dec 26 10:11:39 2023
From: josua at solid-run.com (Josua Mayer)
Date: Tue, 26 Dec 2023 19:11:39 +0100
Subject: [PATCH v3 8/8] arm: dts: marvell: clearfog-gtr-l8: align port
 numbers with enclosure
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
Message-ID: <20231226-support-clearfog-gtr-l8-sfp-v3-8-fd1ac2d6bf2e@solid-run.com>

Clearfog GTR has an official enclosure with labels for all interfaces.
The "lan" ports on the 8-port switch in device-tree were numbered  in
reverse wrt. enclosure.

Update all device-tree labels to match.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index 2df388f222ec..da6981677b03 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -32,49 +32,49 @@ ports {
 
 			port at 1 {
 				reg = <1>;
-				label = "lan8";
+				label = "lan1";
 				phy-handle = <&switch0phy0>;
 			};
 
 			port at 2 {
 				reg = <2>;
-				label = "lan7";
+				label = "lan2";
 				phy-handle = <&switch0phy1>;
 			};
 
 			port at 3 {
 				reg = <3>;
-				label = "lan6";
+				label = "lan3";
 				phy-handle = <&switch0phy2>;
 			};
 
 			port at 4 {
 				reg = <4>;
-				label = "lan5";
+				label = "lan4";
 				phy-handle = <&switch0phy3>;
 			};
 
 			port at 5 {
 				reg = <5>;
-				label = "lan4";
+				label = "lan5";
 				phy-handle = <&switch0phy4>;
 			};
 
 			port at 6 {
 				reg = <6>;
-				label = "lan3";
+				label = "lan6";
 				phy-handle = <&switch0phy5>;
 			};
 
 			port at 7 {
 				reg = <7>;
-				label = "lan2";
+				label = "lan7";
 				phy-handle = <&switch0phy6>;
 			};
 
 			port at 8 {
 				reg = <8>;
-				label = "lan1";
+				label = "lan8";
 				phy-handle = <&switch0phy7>;
 			};
 

-- 
2.35.3



From krzysztof.kozlowski at linaro.org  Tue Dec 26 11:01:53 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Tue, 26 Dec 2023 20:01:53 +0100
Subject: [PATCH v6 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint
 compatible string
In-Reply-To: <ZYr7Y+mJea6fChjS@lizhi-Precision-Tower-5810>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
 <20231224183242.1675372-16-Frank.Li@nxp.com>
 <6a61f325-a58b-4aa6-9a0a-7a3086f63829@linaro.org>
 <ZYr7Y+mJea6fChjS@lizhi-Precision-Tower-5810>
Message-ID: <0233cf48-93cb-4f19-ad1d-e3e1835c1fef@linaro.org>

On 26/12/2023 17:12, Frank Li wrote:
> On Mon, Dec 25, 2023 at 08:16:17PM +0100, Krzysztof Kozlowski wrote:
>> On 24/12/2023 19:32, Frank Li wrote:
>>> Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
>>> Add reg-name: "atu", "dbi2", "dma" and "app".
>>> Reuse PCI linux,pci-domain as controller id at endpoint.
>>>
>>> Signed-off-by: Frank Li <Frank.Li at nxp.com>
>>> ---
>>>
>>
>> ...
>>
>>> +# reuse PCI linux,pci-domain as controller id at Endpoint
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          enum:
>>> +            - fsl,imx95-pcie-ep
>>> +    then:
>>> +      properties:
>>> +        linux,pci-domain: true
>>
>> Same comment: why do you need? Don't ignore my feedback. You responded
>> you will fix it, but it is still here...
> 
> DTB_CHECK report error after I remove it. linux,pci-domain is only define
> in pci, not pci-ep.

Ah, thank you, indeed.

> 
> So I add comments about this. linux,pci-domain was resued ad controller id.

However maybe there is reason why it is not for endpoints. The
description is saying it is valid only for host bridge, so maybe it
should not be used for endpoint case?
> 
> If include pci.yaml, there are too much other properties was involved, but
> not used by pci-ep.

Best regards,
Krzysztof



From markhas at chromium.org  Tue Dec 26 11:21:10 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Tue, 26 Dec 2023 12:21:10 -0700
Subject: [PATCH v3 06/24] ARM: dts: rockchip: rk3288: Enable cros-ec-spi as wake source
In-Reply-To: <20231226192149.1830592-1-markhas@chromium.org>
References: <20231226192149.1830592-1-markhas@chromium.org>
Message-ID: <20231226122113.v3.6.I8249df4df0b7d12fb68ea1e69f84ca589c574bb1@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Some Chromebooks use a separate wake pin, while others overload the
interrupt for wake and IO. With the current assumption, spurious wakes
can occur on systems that use a separate wake pin. It is planned to
update the driver to no longer assume that the EC interrupt pin should
be enabled for wake.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to signify to the driver that they should still be a valid wakeup
source.

-Commit-changes: 3
-Update commit message to provide details of the motivation behind the
change

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

(no changes since v2)

Changes in v2:
-Split by arch/soc

 arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi
index 092316be67f74..1554fe36e60fe 100644
--- a/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3288-veyron-chromebook.dtsi
@@ -112,6 +112,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_int>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Tue Dec 26 11:21:11 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Tue, 26 Dec 2023 12:21:11 -0700
Subject: [PATCH v3 07/24] ARM: dts: samsung: exynos5420: Enable cros-ec-spi as wake source
In-Reply-To: <20231226192149.1830592-1-markhas@chromium.org>
References: <20231226192149.1830592-1-markhas@chromium.org>
Message-ID: <20231226122113.v3.7.I06b059021de1bf6103e60a73211f078f2af75d17@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Some Chromebooks use a separate wake pin, while others overload the
interrupt for wake and IO. With the current assumption, spurious wakes
can occur on systems that use a separate wake pin. It is planned to
update the driver to no longer assume that the EC interrupt pin should
be enabled for wake.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to signify to the driver that they should still be a valid wakeup
source.

-Commit-changes: 3
-Update commit message to provide details of the motivation behind the
change

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

(no changes since v2)

Changes in v2:
-Split by arch/soc

 arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts b/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts
index 4e757b6e28e1c..3759742d38cac 100644
--- a/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts
@@ -967,6 +967,7 @@ cros_ec: cros-ec at 0 {
 		reg = <0>;
 		spi-max-frequency = <3125000>;
 		google,has-vbc-nvram;
+		wakeup-source;
 
 		controller-data {
 			samsung,spi-feedback-delay = <1>;
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Tue Dec 26 11:21:12 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Tue, 26 Dec 2023 12:21:12 -0700
Subject: [PATCH v3 08/24] ARM: dts: samsung: exynos5800: Enable cros-ec-spi as wake source
In-Reply-To: <20231226192149.1830592-1-markhas@chromium.org>
References: <20231226192149.1830592-1-markhas@chromium.org>
Message-ID: <20231226122113.v3.8.Idc995ce08a52ba4c5fde0685118ddf2873fc8acd@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Some Chromebooks use a separate wake pin, while others overload the
interrupt for wake and IO. With the current assumption, spurious wakes
can occur on systems that use a separate wake pin. It is planned to
update the driver to no longer assume that the EC interrupt pin should
be enabled for wake.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to signify to the driver that they should still be a valid wakeup
source.

-Commit-changes: 3
-Update commit message to provide details of the motivation behind the
change

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

(no changes since v2)

Changes in v2:
-Split by arch/soc

 arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts b/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts
index f91bc4ae008e4..9bbbdce9103a6 100644
--- a/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts
@@ -949,6 +949,7 @@ cros_ec: cros-ec at 0 {
 		reg = <0>;
 		spi-max-frequency = <3125000>;
 		google,has-vbc-nvram;
+		wakeup-source;
 
 		controller-data {
 			samsung,spi-feedback-delay = <1>;
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Tue Dec 26 11:21:14 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Tue, 26 Dec 2023 12:21:14 -0700
Subject: [PATCH v3 10/24] arm64: dts: mediatek: mt8183: Enable cros-ec-spi as wake source
In-Reply-To: <20231226192149.1830592-1-markhas@chromium.org>
References: <20231226192149.1830592-1-markhas@chromium.org>
Message-ID: <20231226122113.v3.10.Iba4a8b7e908989e57f7838a80013a4062be5e614@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Some Chromebooks use a separate wake pin, while others overload the
interrupt for wake and IO. With the current assumption, spurious wakes
can occur on systems that use a separate wake pin. It is planned to
update the driver to no longer assume that the EC interrupt pin should
be enabled for wake.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to signify to the driver that they should still be a valid wakeup
source.

-Commit-changes: 3
-Update commit message to provide details of the motivation behind the
change

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

(no changes since v2)

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index 5506de83f61d4..08261164ab18d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -924,6 +924,7 @@ cros_ec: cros-ec at 0 {
 		interrupts-extended = <&pio 151 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_ap_int_odl>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Tue Dec 26 11:21:15 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Tue, 26 Dec 2023 12:21:15 -0700
Subject: [PATCH v3 11/24] arm64: dts: mediatek: mt8192: Enable cros-ec-spi as wake source
In-Reply-To: <20231226192149.1830592-1-markhas@chromium.org>
References: <20231226192149.1830592-1-markhas@chromium.org>
Message-ID: <20231226122113.v3.11.Ibd330d26a00f5e219a7e448452769124833a9762@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Some Chromebooks use a separate wake pin, while others overload the
interrupt for wake and IO. With the current assumption, spurious wakes
can occur on systems that use a separate wake pin. It is planned to
update the driver to no longer assume that the EC interrupt pin should
be enabled for wake.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to signify to the driver that they should still be a valid wakeup
source.

-Commit-changes: 3
-Update commit message to provide details of the motivation behind the
change

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

(no changes since v2)

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
index f2281250ac35d..ab44d382f757e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
@@ -1332,6 +1332,7 @@ cros_ec: ec at 0 {
 		spi-max-frequency = <3000000>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&cros_ec_int>;
+		wakeup-source;
 
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Tue Dec 26 11:21:13 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Tue, 26 Dec 2023 12:21:13 -0700
Subject: [PATCH v3 09/24] arm64: dts: mediatek: mt8173: Enable cros-ec-spi as wake source
In-Reply-To: <20231226192149.1830592-1-markhas@chromium.org>
References: <20231226192149.1830592-1-markhas@chromium.org>
Message-ID: <20231226122113.v3.9.Ic09ebe116c18e83cc1161f4bb073fea8043f03f3@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Some Chromebooks use a separate wake pin, while others overload the
interrupt for wake and IO. With the current assumption, spurious wakes
can occur on systems that use a separate wake pin. It is planned to
update the driver to no longer assume that the EC interrupt pin should
be enabled for wake.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to signify to the driver that they should still be a valid wakeup
source.

-Commit-changes: 3
-Update commit message to provide details of the motivation behind the
change

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

(no changes since v2)

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index 8d614ac2c58ed..335aed42dc9e3 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -1155,6 +1155,7 @@ cros_ec: ec at 0 {
 		spi-max-frequency = <12000000>;
 		interrupts-extended = <&pio 0 IRQ_TYPE_LEVEL_LOW>;
 		google,cros-ec-spi-msg-delay = <500>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel0 {
 			compatible = "google,cros-ec-i2c-tunnel";
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Tue Dec 26 11:21:16 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Tue, 26 Dec 2023 12:21:16 -0700
Subject: [PATCH v3 12/24] arm64: dts: mediatek: mt8195: Enable cros-ec-spi as wake source
In-Reply-To: <20231226192149.1830592-1-markhas@chromium.org>
References: <20231226192149.1830592-1-markhas@chromium.org>
Message-ID: <20231226122113.v3.12.Iee33a7f1f991408cef372744199026f936bf54e2@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Some Chromebooks use a separate wake pin, while others overload the
interrupt for wake and IO. With the current assumption, spurious wakes
can occur on systems that use a separate wake pin. It is planned to
update the driver to no longer assume that the EC interrupt pin should
be enabled for wake.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to signify to the driver that they should still be a valid wakeup
source.

-Commit-changes: 3
-Update commit message to provide details of the motivation behind the
change

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

(no changes since v2)

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index bbdcd441c049d..2edb270d0bc2f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -1149,6 +1149,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&cros_ec_int>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		keyboard-backlight {
 			compatible = "google,cros-kbd-led-backlight";
-- 
2.43.0.472.g3155946c3a-goog



From markhas at chromium.org  Tue Dec 26 11:21:21 2023
From: markhas at chromium.org (Mark Hasemeyer)
Date: Tue, 26 Dec 2023 12:21:21 -0700
Subject: [PATCH v3 17/24] arm64: dts: rockchip: rk3399: Enable cros-ec-spi as wake source
In-Reply-To: <20231226192149.1830592-1-markhas@chromium.org>
References: <20231226192149.1830592-1-markhas@chromium.org>
Message-ID: <20231226122113.v3.17.Ice617703aded22ad4c806459129e1ae693eb57af@changeid>

The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.

Some Chromebooks use a separate wake pin, while others overload the
interrupt for wake and IO. With the current assumption, spurious wakes
can occur on systems that use a separate wake pin. It is planned to
update the driver to no longer assume that the EC interrupt pin should
be enabled for wake.

Add the wakeup-source property to all cros-ec-spi compatible device
nodes to signify to the driver that they should still be a valid wakeup
source.

-Commit-changes: 3
-Update commit message to provide details of the motivation behind the
change

Signed-off-by: Mark Hasemeyer <markhas at chromium.org>
---

(no changes since v2)

Changes in v2:
-Split by arch/soc

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 789fd0dcc88ba..b5734e056aef1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -603,6 +603,7 @@ cros_ec: ec at 0 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&ec_ap_int_l>;
 		spi-max-frequency = <3000000>;
+		wakeup-source;
 
 		i2c_tunnel: i2c-tunnel {
 			compatible = "google,cros-ec-i2c-tunnel";
-- 
2.43.0.472.g3155946c3a-goog



From robh at kernel.org  Tue Dec 26 11:40:03 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 26 Dec 2023 13:40:03 -0600
Subject: [PATCH v3 3/8] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-3-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
 <20231226-support-clearfog-gtr-l8-sfp-v3-3-fd1ac2d6bf2e@solid-run.com>
Message-ID: <170361960357.2887119.16192958166206698998.robh@kernel.org>


On Tue, 26 Dec 2023 19:11:34 +0100, Josua Mayer wrote:
> Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
> boards, which are already in place in-tree.
> 
> There are already 3 distinct dts in tree for these *two* boards,
> declaring particular compatible strings:
> - armada-388-clearfog.dts:
>   compatible = "solidrun,clearfog-a1", "marvell,armada388",
>                "marvell,armada385, "marvell,armada380";
> - armada-388-clearfog-base.dts:
>   compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1",
>                "marvell,armada388", "marvell,armada385,
>                "marvell,armada380";
> - armada-388-clearfog-pro.dts:
>   compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1",
>                "marvell,armada388", "marvell,armada385,
>                "marvell,armada380";
> 
> This has historic reasons, the first entry is a legacy name for the
> "pro" version, old versions of u-boot built when only one variant
> existed explicitly boot by this name.
> 
> Note that both compatibles and model field include the string "A1".
> At least up to revision 2.0 of the board, this had been printed
> on the pcb. However in marketing material and conversations it is
> usually omitted. "Clearfog Pro" and "Clearfog Pro A1" always mean
> exactly the same product.
> 
> Technically Base and Pro variants are similar enough that they can
> successfully boot with each other's dts. Hence it makes (some)
> sense for them to share the "clearfog-a1" compatible.
> 
> Add bindings for the explicit variants including base / pro suffix.
> The legacy "armada-388-clearfog.dts" is not supported by these
> bindings" as it does not make sense having two bindings for one board.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com>
> ---
>  .../devicetree/bindings/arm/marvell/armada-38x.yaml          | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml:46:14: [warning] wrong indentation: expected 14 but found 13 (indentation)

dtschema/dtc warnings/errors:

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231226-support-clearfog-gtr-l8-sfp-v3-3-fd1ac2d6bf2e at solid-run.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From robh at kernel.org  Tue Dec 26 11:40:03 2023
From: robh at kernel.org (Rob Herring)
Date: Tue, 26 Dec 2023 13:40:03 -0600
Subject: [PATCH v3 2/8] dt-bindings: marvell: a38x: add solidrun armada
 385 clearfog gtr boards
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-2-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
 <20231226-support-clearfog-gtr-l8-sfp-v3-2-fd1ac2d6bf2e@solid-run.com>
Message-ID: <170361960294.2887071.7965045689667974977.robh@kernel.org>


On Tue, 26 Dec 2023 19:11:33 +0100, Josua Mayer wrote:
> Add DT compatible for SolidRun Armada-385 based Clearfog GTR L8 and S4
> boards.
> 
> Despite similar name these two boards are designed differently from the
> armada 388 clearfog base and pro, they only share a name and general use
> case.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com>
> ---
>  Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml:36:14: [warning] wrong indentation: expected 14 but found 13 (indentation)

dtschema/dtc warnings/errors:

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231226-support-clearfog-gtr-l8-sfp-v3-2-fd1ac2d6bf2e at solid-run.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From duje.mihanovic at skole.hr  Tue Dec 26 12:00:24 2023
From: duje.mihanovic at skole.hr (=?UTF-8?q?Duje=20Mihanovi=C4=87?=)
Date: Tue, 26 Dec 2023 21:00:24 +0100
Subject: [PATCH RFC] ASoC: pxa: sspa: Don't select SND_ARM
Message-ID: <20231226200025.30870-1-duje.mihanovic@skole.hr>

On ARM64 platforms, SND_ARM shouldn't be selectable, but enabling
SND_SOC_MMP_SSPA will enable SND_ARM and cause build errors if
SND_ARMAACI is enabled (which it is by default). Since the SSPA driver
doesn't depend on AACI nor PXA2XX_LIB, remove this false dependency.

Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202310230518.zs9Qpg3j-lkp at intel.com/
Signed-off-by: Duje Mihanovi? <duje.mihanovic at skole.hr>
---
This patch is necessary for my Marvell PXA1908 series to compile successfully
with allyesconfig:
https://lore.kernel.org/all/20231102-pxa1908-lkml-v7-0-cabb1a0cb52b at skole.hr/
---
 sound/soc/pxa/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index e6bca9070953..f03c74809324 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -35,7 +35,6 @@ config SND_MMP_SOC_SSPA
 	tristate "SoC Audio via MMP SSPA ports"
 	depends on ARCH_MMP
 	select SND_SOC_GENERIC_DMAENGINE_PCM
-	select SND_ARM
 	help
 	  Say Y if you want to add support for codecs attached to
 	  the MMP SSPA interface.
-- 
2.43.0




From surenb at google.com  Tue Dec 26 13:46:10 2023
From: surenb at google.com (Suren Baghdasaryan)
Date: Tue, 26 Dec 2023 13:46:10 -0800
Subject: [PATCH 1/1] arch/mm/fault: fix major fault accounting when retrying
 under per-VMA lock
Message-ID: <20231226214610.109282-1-surenb@google.com>

A test [1] in Android test suite started failing after [2] was merged.
It turns out that after handling a major fault under per-VMA lock, the
process major fault counter does not register that fault as major.
Before [2] read faults would be done under mmap_lock, in which case
FAULT_FLAG_TRIED flag is set before retrying. That in turn causes
mm_account_fault() to account the fault as major once retry completes.
With per-VMA locks we often retry because a fault can't be handled
without locking the whole mm using mmap_lock. Therefore such retries
do not set FAULT_FLAG_TRIED flag. This logic does not work after [2]
because we can now handle read major faults under per-VMA lock and
upon retry the fact there was a major fault gets lost. Fix this by
setting FAULT_FLAG_TRIED after retrying under per-VMA lock if
VM_FAULT_MAJOR was returned. Ideally we would use an additional
VM_FAULT bit to indicate the reason for the retry (could not handle
under per-VMA lock vs other reason) but this simpler solution seems
to work, so keeping it simple.

[1] https://cs.android.com/android/platform/superproject/+/master:test/vts-testcase/kernel/api/drop_caches_prop/drop_caches_test.cpp
[2] https://lore.kernel.org/all/20231006195318.4087158-6-willy at infradead.org/

Fixes: 12214eba1992 ("mm: handle read faults under the VMA lock")
Cc: Matthew Wilcox <willy at infradead.org>
Signed-off-by: Suren Baghdasaryan <surenb at google.com>
---
 arch/arm64/mm/fault.c   | 2 ++
 arch/powerpc/mm/fault.c | 2 ++
 arch/riscv/mm/fault.c   | 2 ++
 arch/s390/mm/fault.c    | 3 +++
 arch/x86/mm/fault.c     | 2 ++
 5 files changed, 11 insertions(+)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 460d799e1296..55f6455a8284 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -607,6 +607,8 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
 		goto done;
 	}
 	count_vm_vma_lock_event(VMA_LOCK_RETRY);
+	if (fault & VM_FAULT_MAJOR)
+		mm_flags |= FAULT_FLAG_TRIED;
 
 	/* Quick path to respond to signals */
 	if (fault_signal_pending(fault, regs)) {
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 9e49ede2bc1c..53335ae21a40 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -497,6 +497,8 @@ static int ___do_page_fault(struct pt_regs *regs, unsigned long address,
 		goto done;
 	}
 	count_vm_vma_lock_event(VMA_LOCK_RETRY);
+	if (fault & VM_FAULT_MAJOR)
+		flags |= FAULT_FLAG_TRIED;
 
 	if (fault_signal_pending(fault, regs))
 		return user_mode(regs) ? 0 : SIGBUS;
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index 90d4ba36d1d0..081339ddf47e 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -304,6 +304,8 @@ void handle_page_fault(struct pt_regs *regs)
 		goto done;
 	}
 	count_vm_vma_lock_event(VMA_LOCK_RETRY);
+	if (fault & VM_FAULT_MAJOR)
+		flags |= FAULT_FLAG_TRIED;
 
 	if (fault_signal_pending(fault, regs)) {
 		if (!user_mode(regs))
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index 249aefcf7c4e..ab4098886e56 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -337,6 +337,9 @@ static void do_exception(struct pt_regs *regs, int access)
 		return;
 	}
 	count_vm_vma_lock_event(VMA_LOCK_RETRY);
+	if (fault & VM_FAULT_MAJOR)
+		flags |= FAULT_FLAG_TRIED;
+
 	/* Quick path to respond to signals */
 	if (fault_signal_pending(fault, regs)) {
 		if (!user_mode(regs))
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index ab778eac1952..679b09cfe241 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1370,6 +1370,8 @@ void do_user_addr_fault(struct pt_regs *regs,
 		goto done;
 	}
 	count_vm_vma_lock_event(VMA_LOCK_RETRY);
+	if (fault & VM_FAULT_MAJOR)
+		flags |= FAULT_FLAG_TRIED;
 
 	/* Quick path to respond to signals */
 	if (fault_signal_pending(fault, regs)) {
-- 
2.43.0.472.g3155946c3a-goog



From Frank.li at nxp.com  Tue Dec 26 13:53:01 2023
From: Frank.li at nxp.com (Frank Li)
Date: Tue, 26 Dec 2023 16:53:01 -0500
Subject: [PATCH v6 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie
 endpoint compatible string
In-Reply-To: <0233cf48-93cb-4f19-ad1d-e3e1835c1fef@linaro.org>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
 <20231224183242.1675372-16-Frank.Li@nxp.com>
 <6a61f325-a58b-4aa6-9a0a-7a3086f63829@linaro.org>
 <ZYr7Y+mJea6fChjS@lizhi-Precision-Tower-5810>
 <0233cf48-93cb-4f19-ad1d-e3e1835c1fef@linaro.org>
Message-ID: <ZYtLPQgMVUSNduLG@lizhi-Precision-Tower-5810>

On Tue, Dec 26, 2023 at 08:01:53PM +0100, Krzysztof Kozlowski wrote:
> On 26/12/2023 17:12, Frank Li wrote:
> > On Mon, Dec 25, 2023 at 08:16:17PM +0100, Krzysztof Kozlowski wrote:
> >> On 24/12/2023 19:32, Frank Li wrote:
> >>> Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
> >>> Add reg-name: "atu", "dbi2", "dma" and "app".
> >>> Reuse PCI linux,pci-domain as controller id at endpoint.
> >>>
> >>> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> >>> ---
> >>>
> >>
> >> ...
> >>
> >>> +# reuse PCI linux,pci-domain as controller id at Endpoint
> >>> +  - if:
> >>> +      properties:
> >>> +        compatible:
> >>> +          enum:
> >>> +            - fsl,imx95-pcie-ep
> >>> +    then:
> >>> +      properties:
> >>> +        linux,pci-domain: true
> >>
> >> Same comment: why do you need? Don't ignore my feedback. You responded
> >> you will fix it, but it is still here...
> > 
> > DTB_CHECK report error after I remove it. linux,pci-domain is only define
> > in pci, not pci-ep.
> 
> Ah, thank you, indeed.
> 
> > 
> > So I add comments about this. linux,pci-domain was resued ad controller id.
> 
> However maybe there is reason why it is not for endpoints. The
> description is saying it is valid only for host bridge, so maybe it
> should not be used for endpoint case?

EP side, it is not PCI bus. So it is reasonable that linux,pci-doamin not
in EP side.

iMX6 host driver(and other some host controller drivers) already use it as
"controller id". EP driver is mostly reused with host bridge drivers. I
think needn't create new property such as "controller_id" for EP only.

A comments should be enough for this case.

Frank

> > 
> > If include pci.yaml, there are too much other properties was involved, but
> > not used by pci-ep.
> 
> Best regards,
> Krzysztof
> 


From tanzirh at google.com  Tue Dec 26 14:52:03 2023
From: tanzirh at google.com (Tanzir Hasan)
Date: Tue, 26 Dec 2023 22:52:03 +0000
Subject: [PATCH] firmware: arm_scmi: removed asm-generic
Message-ID: <20231226-shmem-v1-1-ea15ce81d8ba@google.com>

asm-generic/bug.h can be replaced by linux/bug.h and the file will still
build correctly. It is an asm-generic file which should be avoided if
possible.

Suggested-by: Al Viro <viro at zeniv.linux.org.uk>
Signed-off-by: Tanzir Hasan <tanzirh at google.com>
---
 drivers/firmware/arm_scmi/shmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scmi/shmem.c b/drivers/firmware/arm_scmi/shmem.c
index 87b4f4d35f06..524509f4468e 100644
--- a/drivers/firmware/arm_scmi/shmem.c
+++ b/drivers/firmware/arm_scmi/shmem.c
@@ -10,7 +10,7 @@
 #include <linux/processor.h>
 #include <linux/types.h>
 
-#include <asm-generic/bug.h>
+#include <linux/bug.h>
 
 #include "common.h"
 

---
base-commit: fbafc3e621c3f4ded43720fdb1d6ce1728ec664e
change-id: 20231226-shmem-1a44aa308e18

Best regards,
-- 
Tanzir Hasan <tanzirh at google.com>



From quic_jesszhan at quicinc.com  Tue Dec 26 14:51:28 2023
From: quic_jesszhan at quicinc.com (Jessica Zhang)
Date: Tue, 26 Dec 2023 14:51:28 -0800
Subject: [PATCH 2/6] drm/panel: Add driver for BOE TH101MB31IG002-28A
 panel
In-Reply-To: <20231222-pinetab2-v1-2-e148a7f61bd1@mecka.net>
References: <20231222-pinetab2-v1-0-e148a7f61bd1@mecka.net>
 <20231222-pinetab2-v1-2-e148a7f61bd1@mecka.net>
Message-ID: <1eab96e0-fad1-437b-b8bc-77013e32f724@quicinc.com>



On 12/22/2023 3:05 AM, Manuel Traut wrote:
> From: Segfault <awarnecke002 at hotmail.com>
> 
> The BOE TH101MB31IG002-28A panel is a WXGA panel.
> It is used in Pine64 Pinetab2 and PinetabV.
> 
> Signed-off-by: Segfault <awarnecke002 at hotmail.com>
> Signed-off-by: Manuel Traut <manut at mecka.net>
> ---
>   drivers/gpu/drm/panel/Kconfig                      |  11 +
>   drivers/gpu/drm/panel/Makefile                     |   1 +
>   .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c   | 307 +++++++++++++++++++++
>   3 files changed, 319 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 99e14dc212ec..927ddd10e688 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -67,6 +67,17 @@ config DRM_PANEL_BOE_HIMAX8279D
>   	  24 bit RGB per pixel. It provides a MIPI DSI interface to
>   	  the host and has a built-in LED backlight.
>   
> +config DRM_PANEL_BOE_TH101MB31UIG002_28A
> +	tristate "Boe TH101MB31UIG002-28A panel"
> +	depends on OF
> +	depends on DRM_MIPI_DSI
> +	depends on BACKLIGHT_CLASS_DEVICE
> +	help
> +	  Say Y here if you want to enable support for Boe
> +	  TH101MB31UIG002-28A TFT-LCD modules. The panel has a 800x1280
> +	  resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI
> +	  interface to the host and has a built-in LED backlight.
> +
>   config DRM_PANEL_BOE_TV101WUM_NL6
>   	tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
>   	depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index d10c3de51c6d..dd6e1ac9d0a2 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) += panel-asus-z00t-tm5p5-n35596.
>   obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
>   obj-$(CONFIG_DRM_PANEL_BOE_BF060Y8M_AJ0) += panel-boe-bf060y8m-aj0.o
>   obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
> +obj-$(CONFIG_DRM_PANEL_BOE_TH101MB31UIG002_28A) += panel-boe-th101mb31ig002-28a.o
>   obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
>   obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
>   obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
> diff --git a/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
> new file mode 100644
> index 000000000000..ac1dc99a0300
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
> @@ -0,0 +1,307 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2023 Alexander Warnecke <awarnecke002 at hotmail.com>
> + * Copyright (c) 2023 Manuel Traut <manut at mecka.net>
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/drm_connector.h>
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_panel.h>
> +
> +struct boe_th101mb31ig002 {
> +	struct drm_panel panel;
> +	bool enabled;
> +	bool prepared;

Hi Manuel,

If I remember correctly, commit 
d2aacaf07395bd798373cbec6af05fff4147aff3 should have introduced 
prepared/enabled do the drm_panel struct.

Thanks,

Jessica Zhang

> +
> +	struct mipi_dsi_device *dsi;
> +
> +	struct regulator *power;
> +	struct gpio_desc *enable;
> +	struct gpio_desc *reset;
> +
> +	enum drm_panel_orientation orientation;
> +};
> +
> +static int boe_th101mb31ig002_disable(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +
> +	if (!ctx->enabled)
> +		return 0;
> +
> +	mipi_dsi_dcs_set_display_off(ctx->dsi);
> +	msleep(120);
> +	ctx->enabled = false;
> +
> +	return 0;
> +}
> +
> +static int boe_th101mb31ig002_unprepare(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +
> +	if (!ctx->prepared)
> +		return 0;
> +
> +	mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
> +	msleep(220);
> +	gpiod_set_value_cansleep(ctx->reset, 1);
> +	gpiod_set_value_cansleep(ctx->enable, 0);
> +	regulator_disable(ctx->power);
> +	ctx->prepared = false;
> +
> +	return 0;
> +}
> +
> +static int boe_th101mb31ig002_prepare(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +	struct mipi_dsi_device *dsi = ctx->dsi;
> +	int ret;
> +
> +	if (ctx->prepared)
> +		return 0;
> +
> +	ret = regulator_enable(ctx->power);
> +	if (ret) {
> +		dev_err(&dsi->dev, "Failed to enable power supply: %d\n", ret);
> +		return ret;
> +	}
> +
> +	gpiod_set_value_cansleep(ctx->enable, 1);
> +	msleep(120);
> +	gpiod_direction_output(ctx->reset, 1);
> +	msleep(120);
> +	gpiod_direction_output(ctx->reset, 0);
> +	msleep(120);
> +
> +	mipi_dsi_dcs_write_seq(dsi, 0xE0, 0xAB, 0xBA);
> +	mipi_dsi_dcs_write_seq(dsi, 0xE1, 0xBA, 0xAB);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB1, 0x10, 0x01, 0x47, 0xFF);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB2, 0x0C, 0x14, 0x04, 0x50, 0x50, 0x14);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB3, 0x56, 0x53, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB4, 0x33, 0x30, 0x04);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB6, 0xB0, 0x00, 0x00, 0x10, 0x00, 0x10,
> +			       0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB8, 0x05, 0x12, 0x29, 0x49, 0x48, 0x00,
> +			       0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB9, 0x7C, 0x65, 0x55, 0x49, 0x46, 0x36,
> +			       0x3B, 0x24, 0x3D, 0x3C, 0x3D, 0x5C, 0x4C, 0x55,
> +			       0x47, 0x46, 0x39, 0x26, 0x06, 0x7C, 0x65, 0x55,
> +			       0x49, 0x46, 0x36, 0x3B, 0x24, 0x3D, 0x3C, 0x3D,
> +			       0x5C, 0x4C, 0x55, 0x47, 0x46, 0x39, 0x26, 0x06);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC0, 0xFF, 0x87, 0x12, 0x34, 0x44, 0x44,
> +			       0x44, 0x44, 0x98, 0x04, 0x98, 0x04, 0x0F, 0x00,
> +			       0x00, 0xC1);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC1, 0x54, 0x94, 0x02, 0x85, 0x9F, 0x00,
> +			       0x7F, 0x00, 0x54, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC2, 0x17, 0x09, 0x08, 0x89, 0x08, 0x11,
> +			       0x22, 0x20, 0x44, 0xFF, 0x18, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC3, 0x86, 0x46, 0x05, 0x05, 0x1C, 0x1C,
> +			       0x1D, 0x1D, 0x02, 0x1F, 0x1F, 0x1E, 0x1E, 0x0F,
> +			       0x0F, 0x0D, 0x0D, 0x13, 0x13, 0x11, 0x11, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC4, 0x07, 0x07, 0x04, 0x04, 0x1C, 0x1C,
> +			       0x1D, 0x1D, 0x02, 0x1F, 0x1F, 0x1E, 0x1E, 0x0E,
> +			       0x0E, 0x0C, 0x0C, 0x12, 0x12, 0x10, 0x10, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC6, 0x2A, 0x2A);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC8, 0x21, 0x00, 0x31, 0x42, 0x34, 0x16);
> +	mipi_dsi_dcs_write_seq(dsi, 0xCA, 0xCB, 0x43);
> +	mipi_dsi_dcs_write_seq(dsi, 0xCD, 0x0E, 0x4B, 0x4B, 0x20, 0x19, 0x6B,
> +			       0x06, 0xB3);
> +	mipi_dsi_dcs_write_seq(dsi, 0xD2, 0xE3, 0x2B, 0x38, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xD4, 0x00, 0x01, 0x00, 0x0E, 0x04, 0x44,
> +			       0x08, 0x10, 0x00, 0x00, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xE6, 0x80, 0x01, 0xFF, 0xFF, 0xFF, 0xFF,
> +			       0xFF, 0xFF);
> +	mipi_dsi_dcs_write_seq(dsi, 0xF0, 0x12, 0x03, 0x20, 0x00, 0xFF);
> +	mipi_dsi_dcs_write_seq(dsi, 0xF3, 0x00);
> +
> +	mipi_dsi_dcs_exit_sleep_mode(dsi);
> +	msleep(120);
> +	ctx->prepared = true;
> +
> +	return 0;
> +}
> +
> +static int boe_th101mb31ig002_enable(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +
> +	if (ctx->enabled)
> +		return 0;
> +
> +	mipi_dsi_dcs_set_display_on(ctx->dsi);
> +	msleep(120);
> +	ctx->enabled = true;
> +
> +	return 0;
> +}
> +
> +static const struct drm_display_mode boe_th101mb31ig002_default_mode = {
> +	.clock		= 73500,
> +	.hdisplay	= 800,
> +	.hsync_start	= 800 + 64,
> +	.hsync_end	= 800 + 64 + 16,
> +	.htotal		= 800 + 64 + 16 + 64,
> +	.vdisplay	= 1280,
> +	.vsync_start	= 1280 + 2,
> +	.vsync_end	= 1280 + 2 + 4,
> +	.vtotal		= 1280 + 2 + 4 + 12,
> +	.type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +};
> +
> +static int boe_th101mb31ig002_get_modes(struct drm_panel *panel,
> +					struct drm_connector *connector)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +	struct drm_display_mode *mode;
> +
> +	mode = drm_mode_duplicate(connector->dev,
> +				  &boe_th101mb31ig002_default_mode);
> +	if (!mode) {
> +		dev_err(panel->dev, "Failed to add mode %ux%u@%u\n",
> +			boe_th101mb31ig002_default_mode.hdisplay,
> +			boe_th101mb31ig002_default_mode.vdisplay,
> +			drm_mode_vrefresh(&boe_th101mb31ig002_default_mode));
> +		return -ENOMEM;
> +	}
> +
> +	drm_mode_set_name(mode);
> +	drm_mode_probed_add(connector, mode);
> +
> +	connector->display_info.bpc = 8;
> +	connector->display_info.width_mm = 216;
> +	connector->display_info.height_mm = 135;
> +
> +	/*
> +	 * TODO: Remove once all drm drivers call
> +	 * drm_connector_set_orientation_from_panel()
> +	 */
> +	drm_connector_set_panel_orientation(connector, ctx->orientation);
> +
> +	return 1;
> +}
> +
> +static enum drm_panel_orientation boe_th101mb31ig002_get_orientation(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +
> +	return ctx->orientation;
> +}
> +
> +static const struct drm_panel_funcs boe_th101mb31ig002_funcs = {
> +	.disable = boe_th101mb31ig002_disable,
> +	.unprepare = boe_th101mb31ig002_unprepare,
> +	.prepare = boe_th101mb31ig002_prepare,
> +	.enable = boe_th101mb31ig002_enable,
> +	.get_modes = boe_th101mb31ig002_get_modes,
> +	.get_orientation = boe_th101mb31ig002_get_orientation,
> +};
> +
> +static int boe_th101mb31ig002_dsi_probe(struct mipi_dsi_device *dsi)
> +{
> +	struct boe_th101mb31ig002 *ctx;
> +	int ret;
> +
> +	ctx = devm_kzalloc(&dsi->dev, sizeof(*ctx), GFP_KERNEL);
> +	if (!ctx)
> +		return -ENOMEM;
> +
> +	ctx->enabled = false;
> +	ctx->prepared = false;
> +
> +	mipi_dsi_set_drvdata(dsi, ctx);
> +	ctx->dsi = dsi;
> +
> +	drm_panel_init(&ctx->panel, &dsi->dev, &boe_th101mb31ig002_funcs,
> +		       DRM_MODE_CONNECTOR_DSI);
> +
> +	ctx->power = devm_regulator_get(&dsi->dev, "power");
> +	if (IS_ERR(ctx->power))
> +		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->power),
> +				     "Failed to get power regulator\n");
> +
> +	ctx->enable = devm_gpiod_get(&dsi->dev, "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(ctx->enable))
> +		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->enable),
> +				     "Failed to get enable GPIO\n");
> +
> +	ctx->reset = devm_gpiod_get(&dsi->dev, "reset", GPIOD_OUT_HIGH);
> +	if (IS_ERR(ctx->reset))
> +		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
> +				     "Failed to get reset GPIO\n");
> +
> +	ret = of_drm_get_panel_orientation(dsi->dev.of_node,
> +					   &ctx->orientation);
> +	if (ret)
> +		return dev_err_probe(&dsi->dev, ret,
> +				     "Failed to get orientation\n");
> +
> +	ret = drm_panel_of_backlight(&ctx->panel);
> +	if (ret)
> +		return ret;
> +
> +	drm_panel_add(&ctx->panel);
> +
> +	dsi->lanes = 4;
> +	dsi->format = MIPI_DSI_FMT_RGB888;
> +	dsi->mode_flags = MIPI_DSI_MODE_VIDEO_BURST |
> +			  MIPI_DSI_MODE_NO_EOT_PACKET |
> +			  MIPI_DSI_MODE_LPM;
> +
> +	ret = mipi_dsi_attach(dsi);
> +	if (ret < 0) {
> +		drm_panel_remove(&ctx->panel);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static void boe_th101mb31ig002_dsi_remove(struct mipi_dsi_device *dsi)
> +{
> +	struct boe_th101mb31ig002 *ctx = mipi_dsi_get_drvdata(dsi);
> +
> +	mipi_dsi_detach(dsi);
> +	drm_panel_remove(&ctx->panel);
> +}
> +
> +static const struct of_device_id boe_th101mb31ig002_of_match[] = {
> +	{ .compatible = "boe,th101mb31ig002-28a", },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, boe_th101mb31ig002_of_match);
> +
> +static struct mipi_dsi_driver boe_th101mb31ig002_driver = {
> +	.driver = {
> +		.name = "boe-th101mb31ig002-28a",
> +		.of_match_table = boe_th101mb31ig002_of_match,
> +	},
> +	.probe = boe_th101mb31ig002_dsi_probe,
> +	.remove = boe_th101mb31ig002_dsi_remove,
> +};
> +module_mipi_dsi_driver(boe_th101mb31ig002_driver);
> +
> +MODULE_AUTHOR("Alexander Warnecke <awarnecke002 at hotmail.com>");
> +MODULE_DESCRIPTION("BOE TH101MB31IG002-28A MIPI-DSI LCD panel");
> +MODULE_LICENSE("GPL");
> 
> -- 
> 2.43.0
> 


From quic_jesszhan at quicinc.com  Tue Dec 26 14:56:58 2023
From: quic_jesszhan at quicinc.com (Jessica Zhang)
Date: Tue, 26 Dec 2023 14:56:58 -0800
Subject: [PATCH v2 2/4] drm/panel: Add driver for BOE TH101MB31IG002-28A
 panel
In-Reply-To: <20231223-pinetab2-v2-2-ec1856d0030e@mecka.net>
References: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
 <20231223-pinetab2-v2-2-ec1856d0030e@mecka.net>
Message-ID: <342bf5a0-8454-4fd6-be45-462f1e31e606@quicinc.com>



On 12/23/2023 7:20 AM, Manuel Traut wrote:
> From: Alexander Warnecke <awarnecke002 at hotmail.com>
> 
> The BOE TH101MB31IG002-28A panel is a WXGA panel.
> It is used in Pine64 Pinetab2 and PinetabV.
> 
> Signed-off-by: Alexander Warnecke <awarnecke002 at hotmail.com>
> Signed-off-by: Manuel Traut <manut at mecka.net>
> ---
>   drivers/gpu/drm/panel/Kconfig                      |  11 +
>   drivers/gpu/drm/panel/Makefile                     |   1 +
>   .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c   | 348 +++++++++++++++++++++
>   3 files changed, 360 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 99e14dc212ec..927ddd10e688 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -67,6 +67,17 @@ config DRM_PANEL_BOE_HIMAX8279D
>   	  24 bit RGB per pixel. It provides a MIPI DSI interface to
>   	  the host and has a built-in LED backlight.
>   
> +config DRM_PANEL_BOE_TH101MB31UIG002_28A
> +	tristate "Boe TH101MB31UIG002-28A panel"
> +	depends on OF
> +	depends on DRM_MIPI_DSI
> +	depends on BACKLIGHT_CLASS_DEVICE
> +	help
> +	  Say Y here if you want to enable support for Boe
> +	  TH101MB31UIG002-28A TFT-LCD modules. The panel has a 800x1280
> +	  resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI
> +	  interface to the host and has a built-in LED backlight.
> +
>   config DRM_PANEL_BOE_TV101WUM_NL6
>   	tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
>   	depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index d10c3de51c6d..dd6e1ac9d0a2 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) += panel-asus-z00t-tm5p5-n35596.
>   obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
>   obj-$(CONFIG_DRM_PANEL_BOE_BF060Y8M_AJ0) += panel-boe-bf060y8m-aj0.o
>   obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
> +obj-$(CONFIG_DRM_PANEL_BOE_TH101MB31UIG002_28A) += panel-boe-th101mb31ig002-28a.o
>   obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
>   obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
>   obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
> diff --git a/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
> new file mode 100644
> index 000000000000..ffe4047b7434
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
> @@ -0,0 +1,348 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2023 Alexander Warnecke <awarnecke002 at hotmail.com>
> + * Copyright (c) 2023 Manuel Traut <manut at mecka.net>
> + * Copyright (c) 2023 Dang Huynh <danct12 at riseup.net>
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/drm_connector.h>
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_panel.h>
> +
> +struct boe_th101mb31ig002 {
> +	struct drm_panel panel;
> +	bool enabled;
> +	bool prepared;

Hi Manuel,

Sorry, I responded to the v1 instead of the latest version. Carrying my 
comment over to here:

If I remember correctly, commit d2aacaf07395bd798373cbec6af05fff4147aff3 
should have introduced prepared/enabled do the drm_panel struct.

Thanks,

Jessica Zhang

> +
> +	struct mipi_dsi_device *dsi;
> +
> +	struct regulator *power;
> +	struct gpio_desc *enable;
> +	struct gpio_desc *reset;
> +
> +	enum drm_panel_orientation orientation;
> +};
> +
> +static void boe_th101mb31ig002_reset(struct boe_th101mb31ig002 *ctx)
> +{
> +	gpiod_direction_output(ctx->reset, 0);
> +	usleep_range(10, 100);
> +	gpiod_direction_output(ctx->reset, 1);
> +	usleep_range(10, 100);
> +	gpiod_direction_output(ctx->reset, 0);
> +	usleep_range(5000, 6000);
> +}
> +
> +static int boe_th101mb31ig002_enable(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +	struct mipi_dsi_device *dsi = ctx->dsi;
> +	struct device *dev = &dsi->dev;
> +	int ret;
> +
> +	if (ctx->enabled)
> +		return 0;
> +
> +	mipi_dsi_dcs_write_seq(dsi, 0xE0, 0xAB, 0xBA);
> +	mipi_dsi_dcs_write_seq(dsi, 0xE1, 0xBA, 0xAB);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB1, 0x10, 0x01, 0x47, 0xFF);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB2, 0x0C, 0x14, 0x04, 0x50, 0x50, 0x14);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB3, 0x56, 0x53, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB4, 0x33, 0x30, 0x04);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB6, 0xB0, 0x00, 0x00, 0x10, 0x00, 0x10,
> +				    0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB8, 0x05, 0x12, 0x29, 0x49, 0x48, 0x00,
> +				    0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xB9, 0x7C, 0x65, 0x55, 0x49, 0x46, 0x36,
> +				    0x3B, 0x24, 0x3D, 0x3C, 0x3D, 0x5C, 0x4C,
> +				    0x55, 0x47, 0x46, 0x39, 0x26, 0x06, 0x7C,
> +				    0x65, 0x55, 0x49, 0x46, 0x36, 0x3B, 0x24,
> +				    0x3D, 0x3C, 0x3D, 0x5C, 0x4C, 0x55, 0x47,
> +				    0x46, 0x39, 0x26, 0x06);
> +	mipi_dsi_dcs_write_seq(dsi, 0x00, 0xFF, 0x87, 0x12, 0x34, 0x44, 0x44,
> +				    0x44, 0x44, 0x98, 0x04, 0x98, 0x04, 0x0F,
> +				    0x00, 0x00, 0xC1);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC1, 0x54, 0x94, 0x02, 0x85, 0x9F, 0x00,
> +				    0x7F, 0x00, 0x54, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC2, 0x17, 0x09, 0x08, 0x89, 0x08, 0x11,
> +				    0x22, 0x20, 0x44, 0xFF, 0x18, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC3, 0x86, 0x46, 0x05, 0x05, 0x1C, 0x1C,
> +				    0x1D, 0x1D, 0x02, 0x1F, 0x1F, 0x1E, 0x1E,
> +				    0x0F, 0x0F, 0x0D, 0x0D, 0x13, 0x13, 0x11,
> +				    0x11, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC4, 0x07, 0x07, 0x04, 0x04, 0x1C, 0x1C,
> +				    0x1D, 0x1D, 0x02, 0x1F, 0x1F, 0x1E, 0x1E,
> +				    0x0E, 0x0E, 0x0C, 0x0C, 0x12, 0x12, 0x10,
> +				    0x10, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC6, 0x2A, 0x2A);
> +	mipi_dsi_dcs_write_seq(dsi, 0xC8, 0x21, 0x00, 0x31, 0x42, 0x34, 0x16);
> +	mipi_dsi_dcs_write_seq(dsi, 0xCA, 0xCB, 0x43);
> +	mipi_dsi_dcs_write_seq(dsi, 0xCD, 0x0E, 0x4B, 0x4B, 0x20, 0x19, 0x6B,
> +				    0x06, 0xB3);
> +	mipi_dsi_dcs_write_seq(dsi, 0xD2, 0xE3, 0x2B, 0x38, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xD4, 0x00, 0x01, 0x00, 0x0E, 0x04, 0x44,
> +				    0x08, 0x10, 0x00, 0x00, 0x00);
> +	mipi_dsi_dcs_write_seq(dsi, 0xE6, 0x80, 0x01, 0xFF, 0xFF, 0xFF, 0xFF,
> +				    0xFF, 0xFF);
> +	mipi_dsi_dcs_write_seq(dsi, 0xF0, 0x12, 0x03, 0x20, 0x00, 0xFF);
> +	mipi_dsi_dcs_write_seq(dsi, 0xF3, 0x00);
> +
> +	ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> +	if (ret < 0) {
> +		dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
> +		return ret;
> +	}
> +
> +	msleep(120);
> +
> +	ret = mipi_dsi_dcs_set_display_on(dsi);
> +	if (ret < 0) {
> +		dev_err(dev, "Failed to set panel on: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ctx->enabled = true;
> +
> +	return 0;
> +}
> +
> +static int boe_th101mb31ig002_disable(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +	struct mipi_dsi_device *dsi = ctx->dsi;
> +	struct device *dev = &dsi->dev;
> +	int ret;
> +
> +	if (!ctx->enabled)
> +		return 0;
> +
> +	ret = mipi_dsi_dcs_set_display_off(dsi);
> +	if (ret < 0)
> +		dev_err(dev, "Failed to set panel off: %d\n", ret);
> +
> +	msleep(120);
> +
> +	ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
> +	if (ret < 0)
> +		dev_err(dev, "Failed to enter sleep mode: %d\n", ret);
> +
> +	ctx->enabled = false;
> +
> +	return 0;
> +}
> +
> +static int boe_th101mb31ig002_unprepare(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +
> +	if (!ctx->prepared)
> +		return 0;
> +
> +	gpiod_set_value_cansleep(ctx->reset, 1);
> +	gpiod_set_value_cansleep(ctx->enable, 0);
> +	regulator_disable(ctx->power);
> +
> +	ctx->prepared = false;
> +
> +	return 0;
> +}
> +
> +static int boe_th101mb31ig002_prepare(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +	struct device *dev = &ctx->dsi->dev;
> +	int ret;
> +
> +	if (ctx->prepared)
> +		return 0;
> +
> +	ret = regulator_enable(ctx->power);
> +	if (ret) {
> +		dev_err(dev, "Failed to enable power supply: %d\n", ret);
> +		return ret;
> +	}
> +
> +	gpiod_set_value_cansleep(ctx->enable, 1);
> +	msleep(50);
> +	boe_th101mb31ig002_reset(ctx);
> +	boe_th101mb31ig002_enable(panel);
> +
> +	ctx->prepared = true;
> +
> +	return 0;
> +}
> +
> +static const struct drm_display_mode boe_th101mb31ig002_default_mode = {
> +	.clock		= 73500,
> +	.hdisplay	= 800,
> +	.hsync_start	= 800 + 64,
> +	.hsync_end	= 800 + 64 + 16,
> +	.htotal		= 800 + 64 + 16 + 64,
> +	.vdisplay	= 1280,
> +	.vsync_start	= 1280 + 2,
> +	.vsync_end	= 1280 + 2 + 4,
> +	.vtotal		= 1280 + 2 + 4 + 12,
> +	.width_mm	= 135,
> +	.height_mm	= 216,
> +	.type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +};
> +
> +static int boe_th101mb31ig002_get_modes(struct drm_panel *panel,
> +					struct drm_connector *connector)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +	struct drm_display_mode *mode;
> +
> +	mode = drm_mode_duplicate(connector->dev,
> +				  &boe_th101mb31ig002_default_mode);
> +	if (!mode) {
> +		dev_err(panel->dev, "Failed to add mode %ux%u@%u\n",
> +			boe_th101mb31ig002_default_mode.hdisplay,
> +			boe_th101mb31ig002_default_mode.vdisplay,
> +			drm_mode_vrefresh(&boe_th101mb31ig002_default_mode));
> +		return -ENOMEM;
> +	}
> +
> +	drm_mode_set_name(mode);
> +
> +	connector->display_info.bpc = 8;
> +	connector->display_info.width_mm = mode->width_mm;
> +	connector->display_info.height_mm = mode->height_mm;
> +
> +	/*
> +	 * TODO: Remove once all drm drivers call
> +	 * drm_connector_set_orientation_from_panel()
> +	 */
> +	drm_connector_set_panel_orientation(connector, ctx->orientation);
> +
> +	drm_mode_probed_add(connector, mode);
> +
> +	return 1;
> +}
> +
> +static enum drm_panel_orientation
> +boe_th101mb31ig002_get_orientation(struct drm_panel *panel)
> +{
> +	struct boe_th101mb31ig002 *ctx = container_of(panel,
> +						      struct boe_th101mb31ig002,
> +						      panel);
> +
> +	return ctx->orientation;
> +}
> +
> +static const struct drm_panel_funcs boe_th101mb31ig002_funcs = {
> +	.prepare = boe_th101mb31ig002_prepare,
> +	.unprepare = boe_th101mb31ig002_unprepare,
> +	.enable = boe_th101mb31ig002_enable,
> +	.disable = boe_th101mb31ig002_disable,
> +	.get_modes = boe_th101mb31ig002_get_modes,
> +	.get_orientation = boe_th101mb31ig002_get_orientation,
> +};
> +
> +static int boe_th101mb31ig002_dsi_probe(struct mipi_dsi_device *dsi)
> +{
> +	struct boe_th101mb31ig002 *ctx;
> +	int ret;
> +
> +	ctx = devm_kzalloc(&dsi->dev, sizeof(*ctx), GFP_KERNEL);
> +	if (!ctx)
> +		return -ENOMEM;
> +
> +	ctx->enabled = false;
> +	ctx->prepared = false;
> +
> +	mipi_dsi_set_drvdata(dsi, ctx);
> +	ctx->dsi = dsi;
> +
> +	dsi->lanes = 4;
> +	dsi->format = MIPI_DSI_FMT_RGB888;
> +	dsi->mode_flags = MIPI_DSI_MODE_VIDEO_BURST |
> +			  MIPI_DSI_MODE_NO_EOT_PACKET |
> +			  MIPI_DSI_MODE_LPM;
> +
> +	ctx->power = devm_regulator_get(&dsi->dev, "power");
> +	if (IS_ERR(ctx->power))
> +		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->power),
> +				     "Failed to get power regulator\n");
> +
> +	ctx->enable = devm_gpiod_get(&dsi->dev, "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(ctx->enable))
> +		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->enable),
> +				     "Failed to get enable GPIO\n");
> +
> +	ctx->reset = devm_gpiod_get(&dsi->dev, "reset", GPIOD_OUT_HIGH);
> +	if (IS_ERR(ctx->reset))
> +		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
> +				     "Failed to get reset GPIO\n");
> +
> +	ret = of_drm_get_panel_orientation(dsi->dev.of_node,
> +					   &ctx->orientation);
> +	if (ret)
> +		return dev_err_probe(&dsi->dev, ret,
> +				     "Failed to get orientation\n");
> +
> +	drm_panel_init(&ctx->panel, &dsi->dev, &boe_th101mb31ig002_funcs,
> +		       DRM_MODE_CONNECTOR_DSI);
> +
> +	ret = drm_panel_of_backlight(&ctx->panel);
> +	if (ret)
> +		return ret;
> +
> +	drm_panel_add(&ctx->panel);
> +
> +	ret = mipi_dsi_attach(dsi);
> +	if (ret < 0) {
> +		dev_err_probe(&dsi->dev, ret,
> +			      "Failed to attach panel to DSI host\n");
> +		drm_panel_remove(&ctx->panel);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static void boe_th101mb31ig002_dsi_remove(struct mipi_dsi_device *dsi)
> +{
> +	struct boe_th101mb31ig002 *ctx = mipi_dsi_get_drvdata(dsi);
> +
> +	mipi_dsi_detach(dsi);
> +	drm_panel_remove(&ctx->panel);
> +}
> +
> +static const struct of_device_id boe_th101mb31ig002_of_match[] = {
> +	{ .compatible = "boe,th101mb31ig002-28a", },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, boe_th101mb31ig002_of_match);
> +
> +static struct mipi_dsi_driver boe_th101mb31ig002_driver = {
> +	.driver = {
> +		.name = "boe-th101mb31ig002-28a",
> +		.of_match_table = boe_th101mb31ig002_of_match,
> +	},
> +	.probe = boe_th101mb31ig002_dsi_probe,
> +	.remove = boe_th101mb31ig002_dsi_remove,
> +};
> +module_mipi_dsi_driver(boe_th101mb31ig002_driver);
> +
> +MODULE_AUTHOR("Alexander Warnecke <awarnecke002 at hotmail.com>");
> +MODULE_DESCRIPTION("BOE TH101MB31IG002-28A MIPI-DSI LCD panel");
> +MODULE_LICENSE("GPL");
> 
> -- 
> 2.43.0
> 


From helgaas at kernel.org  Tue Dec 26 15:56:02 2023
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Tue, 26 Dec 2023 17:56:02 -0600
Subject: [RFC PATCH v3 03/17] PCI: Make pci_create_root_bus() declare its
 reliance on MSI domains
In-Reply-To: <20231219174526.2235150-4-sunilvl@ventanamicro.com>
Message-ID: <20231226235602.GA1483795@bhelgaas>

On Tue, Dec 19, 2023 at 11:15:12PM +0530, Sunil V L wrote:
> Similar to [1], declare this dependency for PCI probe in ACPI based
> flow.

It would be better to refer to this as 9ec37efb8783 ("PCI/MSI: Make
pci_host_common_probe() declare its reliance on MSI domains") instead
of a link to the mailing list archives.

The git SHA1 is part of the git repo, and git can tell us where that
SHA1 is included.  The lore URL is external and doesn't say anything
about what happened to the patch.

> This is required especially for RISC-V platforms where MSI controller
> can be absent.
> 
> [1] - https://lore.kernel.org/all/20210330151145.997953-12-maz at kernel.org/


From helgaas at kernel.org  Tue Dec 26 15:59:47 2023
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Tue, 26 Dec 2023 17:59:47 -0600
Subject: [PATCH] PCI: cadence: Fix TI J721E PCIe SoC dependencies
In-Reply-To: <20231220113214.413632-1-pbrobinson@gmail.com>
Message-ID: <20231226235947.GA1483922@bhelgaas>

On Wed, Dec 20, 2023 at 11:32:08AM +0000, Peter Robinson wrote:
> The J721E PCIe is hardware specific to the TI SoC parts
> so add a depenency on that so it's available for those

dependency

> SoC parts and for compile testing but not necessarily
> everyone who enables the Cadence PCIe controller.

Wrap to fill 75 columns.

The subject could possibly be more specific than "fix", e.g.,

  PCI: cadence: Make TI J721E depend on ARCH_K3

> Signed-off-by: Peter Robinson <pbrobinson at gmail.com>
> ---
>  drivers/pci/controller/cadence/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/controller/cadence/Kconfig b/drivers/pci/controller/cadence/Kconfig
> index 291d12711363..1d5a70c9055e 100644
> --- a/drivers/pci/controller/cadence/Kconfig
> +++ b/drivers/pci/controller/cadence/Kconfig
> @@ -47,6 +47,7 @@ config PCI_J721E
>  
>  config PCI_J721E_HOST
>  	bool "TI J721E PCIe controller (host mode)"
> +	depends on ARCH_K3 || COMPILE_TEST
>  	depends on OF
>  	select PCIE_CADENCE_HOST
>  	select PCI_J721E
> @@ -57,6 +58,7 @@ config PCI_J721E_HOST
>  
>  config PCI_J721E_EP
>  	bool "TI J721E PCIe controller (endpoint mode)"
> +	depends on ARCH_K3 || COMPILE_TEST
>  	depends on OF
>  	depends on PCI_ENDPOINT
>  	select PCIE_CADENCE_EP
> -- 
> 2.43.0
> 


From konrad.dybcio at linaro.org  Tue Dec 26 17:07:15 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 27 Dec 2023 02:07:15 +0100
Subject: [PATCH v2 2/8] clk: qcom: gdsc: Enable supply reglator in GPU GX
 handler
In-Reply-To: <20231220-sa8295p-gpu-v2-2-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-2-4763246b72c0@quicinc.com>
Message-ID: <43728d36-0d20-4e1e-8671-726c29d09a2d@linaro.org>

On 22.12.2023 05:39, Bjorn Andersson wrote:
> The GX GDSC is modelled to aid the GMU in powering down the GPU in the
> event that the GPU crashes, so that it can be restarted again. But in
> the event that the power-domain is supplied through a dedicated
> regulator (in contrast to being a subdomin of another power-domain),
> something needs to turn that regulator on, both to make sure things are
> powered and to match the operation in gdsc_disable().
> 
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio at linaro.org>

Konrad


From konrad.dybcio at linaro.org  Tue Dec 26 17:07:52 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 27 Dec 2023 02:07:52 +0100
Subject: [PATCH v2 3/8] clk: qcom: gpucc-sc8280xp: Add external supply for
 GX gdsc
In-Reply-To: <20231220-sa8295p-gpu-v2-3-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-3-4763246b72c0@quicinc.com>
Message-ID: <0d20be70-7db2-4d8b-aecb-5256a42ba62e@linaro.org>

On 22.12.2023 05:39, Bjorn Andersson wrote:
> On SA8295P and SA8540P the GFX rail is powered by a dedicated external
> regulator, instead of the rpmh-controlled "gfx.lvl".
> 
> Define the "vdd-gfx" as the supply regulator for the GDSC, to cause the
> gdsc logic to look for, and control, this external power supply.
> 
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
Worth noting the regulator framework will create a virtual supply
for the normal 8280

Reviewed-by: Konrad Dybcio <konrad.dybcio at linaro.org>

Konrad


From konrad.dybcio at linaro.org  Tue Dec 26 17:08:08 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 27 Dec 2023 02:08:08 +0100
Subject: [PATCH v2 4/8] soc: qcom: rpmhpd: Drop SA8540P gfx.lvl
In-Reply-To: <20231220-sa8295p-gpu-v2-4-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-4-4763246b72c0@quicinc.com>
Message-ID: <0ea71183-1bfc-41b7-8141-eb01e027bbb9@linaro.org>

On 22.12.2023 05:39, Bjorn Andersson wrote:
> On SA8295P and SA8540P gfx.lvl is not provdied by rpmh, but rather is
> handled by an external regulator (max20411). Drop gfx.lvl from the list
> of power-domains exposed on this platform.
> 
> Fixes: f68f1cb3437d ("soc: qcom: rpmhpd: add sc8280xp & sa8540p rpmh power-domains")
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio at linaro.org>

Konrad


From konrad.dybcio at linaro.org  Tue Dec 26 17:08:43 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 27 Dec 2023 02:08:43 +0100
Subject: [PATCH v2 6/8] arm64: dts: qcom: sa8295p-adp: add max20411
In-Reply-To: <20231220-sa8295p-gpu-v2-6-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-6-4763246b72c0@quicinc.com>
Message-ID: <9a11ba2f-d7bc-4860-9987-58f56fad76da@linaro.org>

On 22.12.2023 05:39, Bjorn Andersson wrote:
> From: Bjorn Andersson <andersson at kernel.org>
> 
> The SA8295P ADP has a MAX20411 LDO regulator on I2C 12, supplying the
> VDD_GFX pads. Enable the bus and add the maxim,max20411 device on the
> bus.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
> ---

>  &tlmm {
>  	pcie2a_default: pcie2a-default-state {
>  		clkreq-n-pins {
> @@ -728,4 +760,12 @@ wake-n-pins {
>  			bias-pull-up;
>  		};
>  	};
> +
> +	qup1_i2c4_state: qup1-i2c4-state {
> +		pins = "gpio0", "gpio1";
> +		function = "qup12";
> +
> +		drive-strength = <2>;
unnecessary newline

Konrad


From konrad.dybcio at linaro.org  Tue Dec 26 17:09:47 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 27 Dec 2023 02:09:47 +0100
Subject: [PATCH v2 7/8] arm64: dts: qcom: sa8295p-adp: Enable GPU
In-Reply-To: <20231220-sa8295p-gpu-v2-7-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-7-4763246b72c0@quicinc.com>
Message-ID: <4a1c18e3-39c8-4070-ae55-b1148b3dc65b@linaro.org>

On 22.12.2023 05:39, Bjorn Andersson wrote:
> With the necessary support in place for supplying VDD_GFX from the
> MAX20411 regulator, enable the GPU clock controller, GMU, Adreno SMMU
> and the GPU on the SA8295P ADP.
> 
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
[...]

> +&gpucc {
> +	vdd-gfx-supply = <&vdd_gfx>;
> +	status = "okay";
> +};
Already enabled

> +
> +&gmu {
> +	status = "okay";
> +};
> +
> +&gpu {
> +	status = "okay";
> +
> +	zap-shader {
> +		memory-region = <&gpu_mem>;
> +		firmware-name = "qcom/sa8295p/a690_zap.mbn";
> +	};
> +};
> +
> +&gpu_smmu {
> +	status = "okay";
> +};
Already enabled


Konrad


From konrad.dybcio at linaro.org  Tue Dec 26 17:10:08 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 27 Dec 2023 02:10:08 +0100
Subject: [PATCH v2 5/8] arm64: dts: qcom: sa8540p: Drop gfx.lvl as
 power-domain for gpucc
In-Reply-To: <20231220-sa8295p-gpu-v2-5-4763246b72c0@quicinc.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-5-4763246b72c0@quicinc.com>
Message-ID: <9e551b61-a365-4a53-a04f-8a7f228d3e97@linaro.org>

On 22.12.2023 05:39, Bjorn Andersson wrote:
> The SA8295P and SA8540P uses an external regulator (max20411), and
> gfx.lvl is not provided by rpmh. Drop the power-domains property of the
> gpucc node to reflect this.
> 
> Fixes: eec51ab2fd6f ("arm64: dts: qcom: sc8280xp: Add GPU related nodes")
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio at linaro.org>

Konrad


From Chunfeng.Yun at mediatek.com  Tue Dec 26 17:58:46 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Wed, 27 Dec 2023 01:58:46 +0000
Subject: [PATCH v3 2/3] usb: xhci-mtk: fix a short packet issue of gen1
 isoc-in transfer
In-Reply-To: <2023122033-footprint-impose-9989@gregkh>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
	 <20231220025842.7082-2-chunfeng.yun@mediatek.com>
	 <2023122033-footprint-impose-9989@gregkh>
Message-ID: <0268aecb00fc4d77858d5eef644d30b4e3fb4a0c.camel@mediatek.com>

On Wed, 2023-12-20 at 06:57 +0100, Greg Kroah-Hartman wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On Wed, Dec 20, 2023 at 10:58:41AM +0800, Chunfeng Yun wrote:
> > For Gen1 isoc-in transfer, host still send out unexpected ACK after
> device
> > finish the burst with a short packet, this will cause an exception
> on the
> > connected device, such as, a usb 4k camera.
> > It can be fixed by setting rxfifo depth less than 4k bytes, prefer
> to use
> > 3k here, the side-effect is that may cause performance drop about
> 10%,
> > including bulk transfer.
> > 
> > Fixes: 926d60ae64a6 ("usb: xhci-mtk: modify the SOF/ITP interval
> for mt8195")
> > Cc: stable at vger.kernel.org
> > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > ---
> > v3:
> > add Cc stable
> 
> Why is a patch that you are marking for stable inclusion (and I am
> guessing inclusion in 6.7-final) in the middle of other patches that
> are
> not marked as such?
I'll remove Cc.

> 
> Always split out bugfixes from other things so that they can go
> through
> the two different branches, one for this current release, and one for
> the next one.
> 
> Otherwise you will have to wait until 6.8-rc1 for this bugfix to
> land,
> which I doubt you intend to have happen.
> 
> Please fix up and resend 2 different patch series.
Send v3 today, and modify property;

Thanks a lot
> 
> thanks,
> 
> greg k-h

From Chunfeng.Yun at mediatek.com  Tue Dec 26 17:59:22 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Wed, 27 Dec 2023 01:59:22 +0000
Subject: [PATCH v3 3/3] arm64: dts: mediatek: mt8195: Add 'rx-fifo-depth'
 for cherry
In-Reply-To: <d1767b1d-0b80-4ece-8a35-18eed52a3f6e@collabora.com>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
	 <20231220025842.7082-3-chunfeng.yun@mediatek.com>
	 <d1767b1d-0b80-4ece-8a35-18eed52a3f6e@collabora.com>
Message-ID: <9d335e9e1cc859ea296831d7bf9e5d8e8f6a3876.camel@mediatek.com>

On Wed, 2023-12-20 at 11:30 +0100, AngeloGioacchino Del Regno wrote:
> Il 20/12/23 03:58, Chunfeng Yun ha scritto:
> > Add the quirk property "rx-fifo-depth" to work around Gen1 isoc-in
> > transfer issue which send out unexpected ACK even after device
> > already finished the burst transfer with a short patcket, specially
> > for a 4K camera device.
> > 
> > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > ---
> > v3: change value according to binding
> > v2: use 'rx-fifo-depth' property
> > ---
> >   arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> > index dd5b89b73190..58593348b810 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> > @@ -1185,6 +1185,7 @@
> >   
> 
> Can you please place rx-fifo-depth before power supplies?
Ok, thanks

> 
> after which,
> 
> Reviewed-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno at collabora.com>
> 
> Thanks,
> Angelo
> 
> >   	vusb33-supply = <&mt6359_vusb_ldo_reg>;
> >   	vbus-supply = <&usb_vbus>;
> > +	rx-fifo-depth = <3>;
> >   };
> >   
> >   &xhci1 {
> > @@ -1192,6 +1193,7 @@
> >   
> >   	vusb33-supply = <&mt6359_vusb_ldo_reg>;
> >   	vbus-supply = <&usb_vbus>;
> > +	rx-fifo-depth = <3>;
> >   };
> >   
> >   &xhci2 {
> 
> 

From Chunfeng.Yun at mediatek.com  Tue Dec 26 18:00:39 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Wed, 27 Dec 2023 02:00:39 +0000
Subject: [PATCH v2 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <1050b195-9ac2-4c63-88b0-d8ba3299d334@linaro.org>
References: <20231215073431.8512-1-chunfeng.yun@mediatek.com>
	 <d50abf1a-1ee7-4f84-9f53-69dfe9aad103@linaro.org>
	 <2f38caeb95fe9b2d01f158fd91ed0cedafa5d2fa.camel@mediatek.com>
	 <1050b195-9ac2-4c63-88b0-d8ba3299d334@linaro.org>
Message-ID: <d463f6b87ec36087c062530a929031bcbc3f8924.camel@mediatek.com>

On Wed, 2023-12-20 at 08:25 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 20/12/2023 03:05, Chunfeng Yun (???) wrote:
> > On Fri, 2023-12-15 at 08:36 +0100, Krzysztof Kozlowski wrote:
> >>   
> >> External email : Please do not click links or open attachments
> until
> >> you have verified the sender or the content.
> >>  On 15/12/2023 08:34, Chunfeng Yun wrote:
> >>> For Gen1 isoc-in endpoint on controller before about SSUSB IPM
> >> v1.6.0, it
> >>> still send out unexpected ACK after receiving a short packet in
> >> burst
> >>> transfer, this will cause an exception on connected device,
> >> specially for
> >>> a 4k camera.
> >>> Add a quirk property "rx-fifo-depth" to work around this hardware
> >> issue,
> >>> prefer to use 2;
> >>> The side-effect is that may cause performance drop about 10%,
> >> including
> >>> bulk transfer.
> >>>
> >>> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> >>> ---
> >>> v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
> >>> ---
> >>>  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12
> >> ++++++++++++
> >>>  1 file changed, 12 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> >> xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> >> xhci.yaml
> >>> index e9644e333d78..e44a71acb5c0 100644
> >>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> xhci.yaml
> >>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> xhci.yaml
> >>> @@ -124,6 +124,18 @@ properties:
> >>>        defined in the xHCI spec on MTK's controller.
> >>>      default: 5000
> >>>  
> >>> +  rx-fifo-depth:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32
> >>> +    description:
> >>> +      It is a quirk used to work around Gen1 isoc-in endpoint
> >> transfer issue
> >>> +      that still send out unexpected ACK after device finish the
> >> burst transfer
> >>> +      with a short packet and cause an exception, specially on a
> >> 4K camera
> >>> +      device, it happens on controller before about IPM v1.6.0;
> >> the side-effect
> >>> +      is that may cause performance drop about 10%, include bulk
> >> transfer,
> >>> +      prefer to use 2 here.
> >>
> >> What is the meaning of 0-3? bytes? words?
> > 0 - 1K bytes;
> > 3 - 4K bytes;
> > I will add this in description
> 
> No, don't add. Just use correct values. 0 means 0 words or bytes. Not
> 1000 bytes.
Ok, I'll modify it;

Thanks
> 
> Best regards,
> Krzysztof
> 

From fuyao at sjterm.com  Tue Dec 26 18:01:17 2023
From: fuyao at sjterm.com (Fuyao Kashizuku)
Date: Wed, 27 Dec 2023 10:01:17 +0800
Subject: [PATCH] mfd: sun4i-gpadc: adaptation interrupt number
Message-ID: <ZYuFbUUus9apiCpq@debian.cyg>

The identifiers are used as IRQ resource numbers, where 0 is treated
specially.

This fixes sun4i-gpadc-iio probe failed when request irq.

The backstack:
	WARNING: CPU: 3 PID: 1 at drivers/base/platform.c:451
	__platform_get_irq_byname+0xb8/0xc4
	0 is an invalid IRQ number
	Modules linked in:
	CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc6 #9
	Hardware name: Allwinner sun8i Family
	 unwind_backtrace
	 show_stack
	 dump_stack_lvl
	 __warn
	 warn_slowpath_fmt
	 __platform_get_irq_byname
	 platform_get_irq_byname
	 sun4i_irq_init
	 sun4i_gpadc_probe
	 platform_probe
	 really_probe
	 __driver_probe_device
	 driver_probe_device
	 __driver_attach
	 bus_for_each_dev
	 bus_add_driver
	 driver_register
	 do_one_initcall
	 do_initcall_level
	 do_initcalls
	 kernel_init_freeable
	 kernel_init

Log reports:
sun4i-gpadc-iio sun6i-a31-gpadc-iio.0: error -EINVAL: IRQ FIFO_DATA_PENDING
not found
sun4i-gpadc-iio: probe of sun6i-a31-gpadc-iio.0 failed with error -22

Signed-off-by: Fuyao Kashizuku <fuyao at sjterm.com>
---
Changes in v2:
 - Fix the commit message.
 - Add the backstack.
 - Add the log reports.
 - Use the correct full name and email address.
 - Correct the subsystem to mfd.
 - Link to v1: https://lore.kernel.org/lkml/YwdhTlk+9h+9Mrwm at scg/

 include/linux/mfd/sun4i-gpadc.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
index ea0ccf33a459..021f820f9d52 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h
@@ -81,8 +81,8 @@
 #define SUN4I_GPADC_TEMP_DATA				0x20
 #define SUN4I_GPADC_DATA				0x24
 
-#define SUN4I_GPADC_IRQ_FIFO_DATA			0
-#define SUN4I_GPADC_IRQ_TEMP_DATA			1
+#define SUN4I_GPADC_IRQ_FIFO_DATA			1
+#define SUN4I_GPADC_IRQ_TEMP_DATA			2
 
 /* 10s delay before suspending the IP */
 #define SUN4I_GPADC_AUTOSUSPEND_DELAY			10000
-- 
2.39.2



From Chunfeng.Yun at mediatek.com  Tue Dec 26 18:08:39 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Wed, 27 Dec 2023 02:08:39 +0000
Subject: [PATCH v3 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <4117de24-75fd-4355-9ffb-7d1bc0167295@collabora.com>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
	 <c3d372f0-3d21-4500-96cd-9c88aaf5ce89@linaro.org>
	 <4117de24-75fd-4355-9ffb-7d1bc0167295@collabora.com>
Message-ID: <6510fb531ffb109c05b3ccd270ee516831209bd7.camel@mediatek.com>

On Wed, 2023-12-20 at 11:40 +0100, AngeloGioacchino Del Regno wrote:
> Il 20/12/23 08:38, Krzysztof Kozlowski ha scritto:
> > On 20/12/2023 03:58, Chunfeng Yun wrote:
> > > For Gen1 isoc-in endpoint on controller before about SSUSB IPM
> > > v1.6.0, it
> > > still send out unexpected ACK after receiving a short packet in
> > > burst
> > > transfer, this will cause an exception on connected device,
> > > specially for
> > > a 4k camera.
> > > Add a quirk property "rx-fifo-depth" to work around this hardware
> > > issue,
> > > prefer to use 3k bytes;
> > > The side-effect is that may cause performance drop about 10%,
> > > including
> > > bulk transfer.
> > > 
> > > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > > ---
> > > v3: add fifo depth unit, change the value range from 0-3 to 1-4
> > > v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
> > > ---
> > >   .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12
> > > ++++++++++++
> > >   1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml
> > > index e9644e333d78..9478b7031796 100644
> > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml
> > > @@ -124,6 +124,18 @@ properties:
> > >         defined in the xHCI spec on MTK's controller.
> > >       default: 5000
> > >   
> > > +  rx-fifo-depth:
> > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > +    description:
> > > +      It is a quirk used to work around Gen1 isoc-in endpoint
> > > transfer issue
> > > +      that still send out unexpected ACK after device finish the
> > > burst transfer
> > > +      with a short packet and cause an exception, specially on a
> > > 4K camera
> > > +      device, it happens on controller before about IPM v1.6.0;
> > > the side-effect
> > > +      is that may cause performance drop about 10%, include bulk
> > > transfer,
> > > +      prefer to use 3 here. The unit is 1K bytes.
> > 
> > NAK. Read comments on previous submission.
> > 
> > Best regards,
> > Krzysztof
> > 
> 
> Chunfeng, I think the discussion was not clear for you, so I will try
> to give
> you a different explanation: this should be expressed in bytes, so
> 1000, or 1024,
> 2048, 4096, etc, and not 1/2/3/4/5/n.
> 
> The driver shall then validate and map your bytes number to hardware
> register
> value and subsequently write to the registers.
Got it, I left out Krzysztof's comments when sent v3 series,

Thanks a lot

> 
> Cheers,
> Angleo

From Chunfeng.Yun at mediatek.com  Tue Dec 26 18:03:02 2023
From: Chunfeng.Yun at mediatek.com (=?utf-8?B?Q2h1bmZlbmcgWXVuICjkupHmmKXls7Ap?=)
Date: Wed, 27 Dec 2023 02:03:02 +0000
Subject: [PATCH v3 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <c3d372f0-3d21-4500-96cd-9c88aaf5ce89@linaro.org>
References: <20231220025842.7082-1-chunfeng.yun@mediatek.com>
	 <c3d372f0-3d21-4500-96cd-9c88aaf5ce89@linaro.org>
Message-ID: <26766389b92dbc0996a7e9c461a2f27c790999fb.camel@mediatek.com>

On Wed, 2023-12-20 at 08:38 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 20/12/2023 03:58, Chunfeng Yun wrote:
> > For Gen1 isoc-in endpoint on controller before about SSUSB IPM
> v1.6.0, it
> > still send out unexpected ACK after receiving a short packet in
> burst
> > transfer, this will cause an exception on connected device,
> specially for
> > a 4k camera.
> > Add a quirk property "rx-fifo-depth" to work around this hardware
> issue,
> > prefer to use 3k bytes;
> > The side-effect is that may cause performance drop about 10%,
> including
> > bulk transfer.
> > 
> > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > ---
> > v3: add fifo depth unit, change the value range from 0-3 to 1-4
> > v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
> > ---
> >  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12
> ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> xhci.yaml
> > index e9644e333d78..9478b7031796 100644
> > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> > @@ -124,6 +124,18 @@ properties:
> >        defined in the xHCI spec on MTK's controller.
> >      default: 5000
> >  
> > +  rx-fifo-depth:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    description:
> > +      It is a quirk used to work around Gen1 isoc-in endpoint
> transfer issue
> > +      that still send out unexpected ACK after device finish the
> burst transfer
> > +      with a short packet and cause an exception, specially on a
> 4K camera
> > +      device, it happens on controller before about IPM v1.6.0;
> the side-effect
> > +      is that may cause performance drop about 10%, include bulk
> transfer,
> > +      prefer to use 3 here. The unit is 1K bytes.
> 
> NAK. Read comments on previous submission.
Ok, will do it today

Thanks a lot

> 
> Best regards,
> Krzysztof
> 

From Jason-JH.Lin at mediatek.com  Tue Dec 26 19:19:04 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 03:19:04 +0000
Subject: [PATCH v3 06/11] drm/mediatek: Add get_sec_port interface to
 mtk_ddp_comp
In-Reply-To: <4165d71dd9d0043346ca57d1a556f21639885d18.camel@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-7-jason-jh.lin@mediatek.com>
	 <4165d71dd9d0043346ca57d1a556f21639885d18.camel@mediatek.com>
Message-ID: <9508ff90e84a47865c982a5978d144ecacd4010f.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Tue, 2023-12-26 at 05:24 +0000, CK Hu (???) wrote:
> On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> > Add get_sec_port interface to ddp_comp to get the secure port
> > settings
> > from ovl and ovl_adaptor.
> > Then mediatek-drm will use secure cmdq driver to configure DRAM
> > access
> > permission in secure world by their secure port settings.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> 
> TODO: drop this patch.
> 
> 
> Regards,
> CK
> 
OK, I'll drop this.

Regards,
Jason-JH.Lin


From Jason-JH.Lin at mediatek.com  Tue Dec 26 19:35:34 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 03:35:34 +0000
Subject: [PATCH v3 08/11] drm/mediatek: Add secure layer config support
 for ovl_adaptor
In-Reply-To: <2d045768bb3f1da3e2ea77f9f94050b194627e5b.camel@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-9-jason-jh.lin@mediatek.com>
	 <2d045768bb3f1da3e2ea77f9f94050b194627e5b.camel@mediatek.com>
Message-ID: <6d03f325f3ad25a96c143c0c7ac52b580c69814f.camel@mediatek.com>

Hi CK,

Thanks for the reivews.

On Tue, 2023-12-26 at 03:20 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> > Add secure layer config support for ovl_adaptor and sub driver
> > mdp_rdma.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_disp_drv.h         |  1 +
> >  drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15
> > +++++++++++++++
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c     |  1 +
> >  drivers/gpu/drm/mediatek/mtk_mdp_rdma.c         | 11 ++++++++---
> >  drivers/gpu/drm/mediatek/mtk_mdp_rdma.h         |  2 ++
> >  5 files changed, 27 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > index 77054adcd9cf..ec9746767468 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > @@ -117,6 +117,7 @@ void mtk_ovl_adaptor_clk_disable(struct device
> > *dev);
> >  void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
> >  			    unsigned int h, unsigned int vrefresh,
> >  			    unsigned int bpc, struct cmdq_pkt
> > *cmdq_pkt);
> > +u64 mtk_ovl_adaptor_get_sec_port(struct mtk_ddp_comp *comp,
> > unsigned
> > int idx);
> >  void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int
> > idx,
> >  				  struct mtk_plane_state *state,
> >  				  struct cmdq_pkt *cmdq_pkt);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > index 6bf6367853fb..f419c2e70ba3 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > @@ -83,6 +83,18 @@ static const struct ovl_adaptor_comp_match
> > comp_matches[OVL_ADAPTOR_ID_MAX] = {
> >  	[OVL_ADAPTOR_ETHDR0]	= { OVL_ADAPTOR_TYPE_ETHDR, 0 },
> >  };
> >  
> > +static const u64 ovl_adaptor_sec_port[] = {
> > +	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L0),
> > +	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L1),
> > +	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L2),
> > +	BIT_ULL(CMDQ_SEC_VDO1_DISP_RDMA_L3),
> > +};
> > +
> > +u64 mtk_ovl_adaptor_get_sec_port(struct mtk_ddp_comp *comp,
> > unsigned
> > int idx)
> > +{
> > +	return ovl_adaptor_sec_port[idx];
> > +}
> > +
> >  void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int
> > idx,
> >  				  struct mtk_plane_state *state,
> >  				  struct cmdq_pkt *cmdq_pkt)
> > @@ -141,6 +153,9 @@ void mtk_ovl_adaptor_layer_config(struct device
> > *dev, unsigned int idx,
> >  	rdma_config.pitch = pending->pitch;
> >  	rdma_config.fmt = pending->format;
> >  	rdma_config.color_encoding = pending->color_encoding;
> > +	rdma_config.source_size = (pending->height - 1) * pending-
> > > pitch +
> > 
> > +				  pending->width * fmt_info->cpp[0];
> > +	rdma_config.is_secure = state->pending.is_secure;
> >  	mtk_mdp_rdma_config(rdma_l, &rdma_config, cmdq_pkt);
> >  
> >  	if (use_dual_pipe) {
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 6aed7647dfc0..9b7fe34df9a6 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -445,6 +445,7 @@ static const struct mtk_ddp_comp_funcs
> > ddp_ovl_adaptor = {
> >  	.remove = mtk_ovl_adaptor_remove_comp,
> >  	.get_formats = mtk_ovl_adaptor_get_formats,
> >  	.get_num_formats = mtk_ovl_adaptor_get_num_formats,
> > +	.get_sec_port = mtk_ovl_adaptor_get_sec_port,
> >  };
> >  
> >  static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX]
> > =
> > {
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> > b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> > index c3adaeefd551..a164ba82d022 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> > @@ -94,6 +94,7 @@ struct mtk_mdp_rdma {
> >  	void __iomem		*regs;
> >  	struct clk		*clk;
> >  	struct cmdq_client_reg	cmdq_reg;
> > +	resource_size_t		regs_pa;
> >  };
> >  
> >  static unsigned int rdma_fmt_convert(unsigned int fmt)
> > @@ -198,9 +199,12 @@ void mtk_mdp_rdma_config(struct device *dev,
> > struct mtk_mdp_rdma_cfg *cfg,
> >  	else
> >  		mtk_ddp_write_mask(cmdq_pkt, 0, &priv->cmdq_reg, priv-
> > > regs,
> > 
> >  				   MDP_RDMA_SRC_CON, FLD_OUTPUT_ARGB);
> > -
> > -	mtk_ddp_write_mask(cmdq_pkt, cfg->addr0, &priv->cmdq_reg, priv-
> > > regs,
> > 
> > -			   MDP_RDMA_SRC_BASE_0, FLD_SRC_BASE_0);
> > +	if (cfg->is_secure)
> > +		mtk_ddp_sec_write(cmdq_pkt, priv->regs_pa +
> > MDP_RDMA_SRC_BASE_0,
> > +				  cfg->addr0, CMDQ_IWC_H_2_MVA, 0, cfg-
> > > source_size, 0);
> 
> In OVL, there is one bit that control OVL hardware could access
> secure
> buffer or not. Why mdp rdma has no this bit?
> 
> Regards,
> CK
> 
Yes, that's different HW design for OVL.

Because OVL has 4 layers, we can't witch the whole larb port to secure
like MDP_RDMA. So that OVL can support normal buffer input and secure
buffer input at the same time.

Regards,
Jason-JH.Lin


From Jason-JH.Lin at mediatek.com  Tue Dec 26 19:18:04 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 03:18:04 +0000
Subject: [PATCH v3 01/11] drm/mediatek: Add interface to allocate MediaTek
 GEM buffer.
In-Reply-To: <4169f943f6e82da50243d91614ab73d6b5f57c8a.camel@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-2-jason-jh.lin@mediatek.com>
	 <4169f943f6e82da50243d91614ab73d6b5f57c8a.camel@mediatek.com>
Message-ID: <323607d815bf7ad593144dceecc387af1f661729.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Mon, 2023-12-25 at 09:05 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> 
> On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> > From: CK Hu <ck.hu at mediatek.com>
> > 
> > Add an interface to allocate MediaTek GEM buffers, allow the IOCTLs
> > to be used by render nodes.
> > This patch also sets the RENDER driver feature.
> > 
> > Signed-off-by: CK Hu <ck.hu at mediatek.com>
> > Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> > Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>
> > Reviewed-by: Nicolas Boichat <drinkcat at chromium.org>
> > Tested-by: Daniel Kurtz <djkurtz at chromium.org>
> > Tested-by: Pi-Hsun Shih <pihsun at chromium.org>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 ++++++
> >  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 39 +++++++++++++++++
> >  drivers/gpu/drm/mediatek/mtk_drm_gem.h | 12 ++++++
> >  include/uapi/drm/mediatek_drm.h        | 58
> > ++++++++++++++++++++++++++
> >  4 files changed, 122 insertions(+)
> >  create mode 100644 include/uapi/drm/mediatek_drm.h
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 2b0c35cacbc6..5d2a39e491aa 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -24,6 +24,7 @@
> >  #include <drm/drm_of.h>
> >  #include <drm/drm_probe_helper.h>
> >  #include <drm/drm_vblank.h>
> > +#include <drm/mediatek_drm.h>
> >  
> >  #include "mtk_drm_crtc.h"
> >  #include "mtk_drm_ddp_comp.h"
> > @@ -569,6 +570,14 @@ static void mtk_drm_kms_deinit(struct
> > drm_device
> > *drm)
> >  	component_unbind_all(drm->dev, drm);
> >  }
> >  
> > +static const struct drm_ioctl_desc mtk_ioctls[] = {
> > +	DRM_IOCTL_DEF_DRV(MTK_GEM_CREATE, mtk_gem_create_ioctl,
> > +			  DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
> > +	DRM_IOCTL_DEF_DRV(MTK_GEM_MAP_OFFSET,
> > +			  mtk_gem_map_offset_ioctl,
> > +			  DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
> 
> For secure buffer, we don't need map offset function. If you really
> need this function, separate this to another patch and describe why
> need this.
> 
> Regards,
> CK

OK, I'll remove this function.

Regards
Jason-JH.Lin
> 
> > +};
> > +
> >  DEFINE_DRM_GEM_FOPS(mtk_drm_fops);
> >  
> >  /*
> > @@ -590,6 +599,10 @@ static const struct drm_driver mtk_drm_driver
> > =
> > {
> >  
> >  	.gem_prime_import = mtk_drm_gem_prime_import,
> >  	.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
> > +
> > +	.ioctls = mtk_ioctls,
> > +	.num_ioctls = ARRAY_SIZE(mtk_ioctls),
> > +
> >  	.fops = &mtk_drm_fops,
> >  
> >  	.name = DRIVER_NAME,
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > index 4f2e3feabc0f..30e347adcbe9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> > @@ -4,6 +4,7 @@
> >   */
> >  
> >  #include <linux/dma-buf.h>
> > +#include <drm/mediatek_drm.h>
> >  
> >  #include <drm/drm.h>
> >  #include <drm/drm_device.h>
> > @@ -283,3 +284,41 @@ void mtk_drm_gem_prime_vunmap(struct
> > drm_gem_object *obj,
> >  	mtk_gem->kvaddr = NULL;
> >  	kfree(mtk_gem->pages);
> >  }
> > +
> > +int mtk_gem_map_offset_ioctl(struct drm_device *drm, void *data,
> > +			     struct drm_file *file_priv)
> > +{
> > +	struct drm_mtk_gem_map_off *args = data;
> > +
> > +	return drm_gem_dumb_map_offset(file_priv, drm, args->handle,
> > +				       &args->offset);
> > +}
> > +
> > +int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
> > +			 struct drm_file *file_priv)
> > +{
> > +	struct mtk_drm_gem_obj *mtk_gem;
> > +	struct drm_mtk_gem_create *args = data;
> > +	int ret;
> > +
> > +	mtk_gem = mtk_drm_gem_create(dev, args->size, false);
> > +	if (IS_ERR(mtk_gem))
> > +		return PTR_ERR(mtk_gem);
> > +
> > +	/*
> > +	 * allocate a id of idr table where the obj is registered
> > +	 * and handle has the id what user can see.
> > +	 */
> > +	ret = drm_gem_handle_create(file_priv, &mtk_gem->base, &args-
> > > handle);
> > 
> > +	if (ret)
> > +		goto err_handle_create;
> > +
> > +	/* drop reference from allocate - handle holds it now. */
> > +	drm_gem_object_put(&mtk_gem->base);
> > +
> > +	return 0;
> > +
> > +err_handle_create:
> > +	mtk_drm_gem_free_object(&mtk_gem->base);
> > +	return ret;
> > +}
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> > b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> > index 78f23b07a02e..90f3d2916ec5 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
> > @@ -46,4 +46,16 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object
> > *obj, struct iosys_map *map);
> >  void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj,
> >  			      struct iosys_map *map);
> >  
> > +/*
> > + * request gem object creation and buffer allocation as the size
> > + * that it is calculated with framebuffer information such as
> > width,
> > + * height and bpp.
> > + */
> > +int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
> > +			 struct drm_file *file_priv);
> > +
> > +/* get buffer offset to map to user space. */
> > +int mtk_gem_map_offset_ioctl(struct drm_device *dev, void *data,
> > +			     struct drm_file *file_priv);
> > +
> >  #endif
> > diff --git a/include/uapi/drm/mediatek_drm.h
> > b/include/uapi/drm/mediatek_drm.h
> > new file mode 100644
> > index 000000000000..f4d47577c94e
> > --- /dev/null
> > +++ b/include/uapi/drm/mediatek_drm.h
> > @@ -0,0 +1,58 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2
> > as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef _UAPI_MEDIATEK_DRM_H
> > +#define _UAPI_MEDIATEK_DRM_H
> > +
> > +#include <drm/drm.h>
> > +
> > +/**
> > + * struct drm_mtk_gem_create - User-desired buffer creation
> > information structure.
> > + *
> > + * @size: user-desired memory allocation size.
> > + *	- this size value would be page-aligned internally.
> > + * @flags: user request for setting memory type or cache
> > attributes.
> > + * @handle: returned a handle to created gem object.
> > + *	- this handle will be set by gem module of kernel side.
> > + */
> > +struct drm_mtk_gem_create {
> > +	uint64_t size;
> > +	uint32_t flags;
> > +	uint32_t handle;
> > +};
> > +
> > +/**
> > + * struct drm_mtk_gem_map_off - A structure for getting buffer
> > offset.
> > + *
> > + * @handle: a pointer to gem object created.
> > + * @pad: just padding to be 64-bit aligned.
> > + * @offset: relatived offset value of the memory region allocated.
> > + *     - this value should be set by user.
> > + */
> > +struct drm_mtk_gem_map_off {
> > +	uint32_t handle;
> > +	uint32_t pad;
> > +	uint64_t offset;
> > +};
> > +
> > +#define DRM_MTK_GEM_CREATE		0x00
> > +#define DRM_MTK_GEM_MAP_OFFSET		0x01
> > +
> > +#define DRM_IOCTL_MTK_GEM_CREATE	DRM_IOWR(DRM_COMMAND_BASE + \
> > +		DRM_MTK_GEM_CREATE, struct drm_mtk_gem_create)
> > +
> > +#define DRM_IOCTL_MTK_GEM_MAP_OFFSET	DRM_IOWR(DRM_COMMAND_BA
> > SE + \
> > +		DRM_MTK_GEM_MAP_OFFSET, struct drm_mtk_gem_map_off)
> > +
> > +#endif /* _UAPI_MEDIATEK_DRM_H */

From Jason-JH.Lin at mediatek.com  Tue Dec 26 19:40:51 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 03:40:51 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <8234222df9443008db31158bfb7f203da9d5b4f0.camel@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
	 <8234222df9443008db31158bfb7f203da9d5b4f0.camel@mediatek.com>
Message-ID: <a1c4f29bc8d8b12f962fd791cacf22ff489c6fc6.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Tue, 2023-12-26 at 06:15 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> > To support secure video path feature, GCE have to read/write
> > registgers
> > in the secure world. GCE will enable the secure access permission
> > to
> > the
> > HW who wants to access the secure content buffer.
> > 
> > Add CMDQ secure mailbox driver to make CMDQ client user is able to
> > sending their HW settings to the secure world. So that GCE can
> > execute
> > all instructions to configure HW in the secure world.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> 
> [snip]
> 
> > +
> > +static void cmdq_sec_task_exec_work(struct work_struct *work_item)
> > +{
> > +	struct cmdq_sec_task *sec_task = container_of(work_item,
> > +						      struct
> > cmdq_sec_task, exec_work);
> > +	struct cmdq_sec_thread *sec_thread = container_of(sec_task-
> > > task.thread,
> > 
> > +							 struct
> > cmdq_sec_thread, thread);
> > +	struct cmdq_sec *cmdq = container_of(sec_thread->thread.chan-
> > > mbox,
> > 
> > +					     struct cmdq_sec, mbox);
> > +	struct cmdq_sec_data *data;
> > +	unsigned long flags;
> > +	int err;
> > +
> > +	dev_dbg(cmdq->mbox.dev, "%s gce:%#lx sec_task:%p pkt:%p
> > thread:%u",
> > +		__func__, (unsigned long)cmdq->base_pa,
> > +		sec_task, sec_task->task.pkt, sec_thread->idx);
> > +
> > +	if (!sec_task->task.pkt->sec_data) {
> > +		dev_err(cmdq->mbox.dev, "pkt:%p without sec_data",
> > sec_task->task.pkt);
> > +		return;
> > +	}
> > +	data = (struct cmdq_sec_data *)sec_task->task.pkt->sec_data;
> > +
> > +	mutex_lock(&cmdq->exec_lock);
> > +
> > +	spin_lock_irqsave(&sec_thread->thread.chan->lock, flags);
> > +	if (!sec_thread->task_cnt) {
> > +		mod_timer(&sec_thread->timeout, jiffies +
> > +			  msecs_to_jiffies(sec_thread->timeout_ms));
> > +		sec_thread->wait_cookie = 1;
> > +		sec_thread->next_cookie = 1;
> > +		sec_thread->task_cnt = 0;
> > +		__raw_writel(0, (void __iomem *)cmdq->shared_mem->va +
> > +			     CMDQ_SEC_SHARED_THR_CNT_OFFSET +
> > sec_thread->idx * sizeof(u32));
> > +	}
> > +
> > +	sec_task->reset_exec = sec_thread->task_cnt ? false : true;
> > +	sec_task->wait_cookie = sec_thread->next_cookie;
> > +	sec_thread->next_cookie = (sec_thread->next_cookie + 1) %
> > CMDQ_MAX_COOKIE_VALUE;
> > +	list_add_tail(&sec_task->task.list_entry, &sec_thread-
> > > thread.task_busy_list);
> > 
> > +	sec_thread->task_cnt += 1;
> > +	spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
> > +	sec_task->trigger = sched_clock();
> > +
> > +	if (!atomic_cmpxchg(&cmdq_path_res, 0, 1)) {
> > +		err = cmdq_sec_task_submit(cmdq, NULL,
> > CMD_CMDQ_IWC_PATH_RES_ALLOCATE,
> > +					   CMDQ_INVALID_THREAD, NULL);
> > +		if (err) {
> > +			atomic_set(&cmdq_path_res, 0);
> > +			goto task_end;
> > +		}
> > +	}
> > +
> > +	if (sec_thread->task_cnt > CMDQ_MAX_TASK_IN_SECURE_THREAD) {
> > +		dev_err(cmdq->mbox.dev, "task_cnt:%u cannot more than
> > %u sec_task:%p thread:%u",
> > +			sec_thread->task_cnt,
> > CMDQ_MAX_TASK_IN_SECURE_THREAD,
> > +			sec_task, sec_thread->idx);
> > +		err = -EMSGSIZE;
> > +		goto task_end;
> > +	}
> > +
> > +	err = cmdq_sec_task_submit(cmdq, sec_task,
> > CMD_CMDQ_IWC_SUBMIT_TASK,
> > +				   sec_thread->idx, NULL);
> > +	if (err)
> > +		dev_err(cmdq->mbox.dev, "cmdq_sec_task_submit err:%d
> > sec_task:%p thread:%u",
> > +			err, sec_task, sec_thread->idx);
> > +
> > +task_end:
> > +	if (err) {
> > +		struct cmdq_cb_data cb_data;
> > +
> > +		cb_data.sta = err;
> > +		cb_data.pkt = sec_task->task.pkt;
> > +		mbox_chan_received_data(sec_thread->thread.chan,
> > &cb_data);
> > +
> > +		spin_lock_irqsave(&sec_thread->thread.chan->lock,
> > flags);
> > +		if (!sec_thread->task_cnt)
> > +			dev_err(cmdq->mbox.dev, "thread:%u task_cnt:%u
> > cannot below zero",
> > +				sec_thread->idx, sec_thread->task_cnt);
> > +		else
> > +			sec_thread->task_cnt -= 1;
> > +
> > +		sec_thread->next_cookie = (sec_thread->next_cookie - 1
> > +
> > +			CMDQ_MAX_COOKIE_VALUE) % CMDQ_MAX_COOKIE_VALUE;
> > +		list_del(&sec_task->task.list_entry);
> > +		dev_dbg(cmdq->mbox.dev, "gce:%#lx err:%d sec_task:%p
> > pkt:%p",
> > +			(unsigned long)cmdq->base_pa, err, sec_task,
> > sec_task->task.pkt);
> > +		dev_dbg(cmdq->mbox.dev, "thread:%u task_cnt:%u
> > wait_cookie:%u next_cookie:%u",
> > +			sec_thread->idx, sec_thread->task_cnt,
> > +			sec_thread->wait_cookie, sec_thread-
> > > next_cookie);
> > 
> > +		spin_unlock_irqrestore(&sec_thread->thread.chan->lock,
> > flags);
> > +
> > +		kfree(sec_task);
> > +	}
> > +
> > +	mutex_unlock(&cmdq->exec_lock);
> > +}
> > +
> > +static int cmdq_sec_mbox_send_data(struct mbox_chan *chan, void
> > *data)
> > +{
> > +	struct cmdq_pkt *pkt = (struct cmdq_pkt *)data;
> > +	struct cmdq_sec_data *sec_data = (struct cmdq_sec_data *)pkt-
> > > sec_data;
> > 
> > +	struct cmdq_thread *thread = (struct cmdq_thread *)chan-
> > > con_priv;
> > 
> > +	struct cmdq_sec_thread *sec_thread = container_of(thread,
> > struct cmdq_sec_thread, thread);
> > +	struct cmdq_sec_task *sec_task;
> > +
> > +	if (!sec_data)
> > +		return -EINVAL;
> > +
> > +	sec_task = kzalloc(sizeof(*sec_task), GFP_ATOMIC);
> > +	if (!sec_task)
> > +		return -ENOMEM;
> > +
> > +	sec_task->task.pkt = pkt;
> > +	sec_task->task.thread = thread;
> > +	sec_task->scenario = sec_data->scenario;
> > +	sec_task->engine_flag = sec_data->engs_need_dapc | sec_data-
> > > engs_need_sec_port;
> > 
> > +
> > +	INIT_WORK(&sec_task->exec_work, cmdq_sec_task_exec_work);
> > +	queue_work(sec_thread->task_exec_wq, &sec_task->exec_work);
> 
> It's not necessary to queue a work here. Squash
> cmdq_sec_task_exec_work() into this function.
> 
> Regards,
> CK
> 
OK, I'll squash it.

Regards,
Jason-JH.Lin

From arinc.unal at arinc9.com  Tue Dec 26 20:43:40 2023
From: arinc.unal at arinc9.com (=?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=)
Date: Wed, 27 Dec 2023 07:43:40 +0300
Subject: [PATCH net-next v2 0/7] MT7530 DSA Subdriver Improvements Act I
Message-ID: <20231227044347.107291-1-arinc.unal@arinc9.com>

Hello!

This patch series simplifies the MT7530 DSA subdriver and improves the
logic of the support for MT7530, MT7531, and the switch on the MT7988 SoC.

I have done a simple ping test to confirm basic communication on all switch
ports on MCM and standalone MT7530, and MT7531 switch with this patch
series applied.

MT7621 Unielec, MCM MT7530:

rgmii-only-gmac0-mt7621-unielec-u7621-06-16m.dtb
gmac0-and-gmac1-mt7621-unielec-u7621-06-16m.dtb

tftpboot 0x80008000 mips-uzImage.bin; tftpboot 0x83000000 mips-rootfs.cpio.uboot; tftpboot 0x83f00000 $dtb; bootm 0x80008000 0x83000000 0x83f00000

MT7622 Bananapi, MT7531:

gmac0-and-gmac1-mt7622-bananapi-bpi-r64.dtb

tftpboot 0x40000000 arm64-Image; tftpboot 0x45000000 arm64-rootfs.cpio.uboot; tftpboot 0x4a000000 $dtb; booti 0x40000000 0x45000000 0x4a000000

MT7623 Bananapi, standalone MT7530:

rgmii-only-gmac0-mt7623n-bananapi-bpi-r2.dtb
gmac0-and-gmac1-mt7623n-bananapi-bpi-r2.dtb

tftpboot 0x80008000 arm-zImage; tftpboot 0x83000000 arm-rootfs.cpio.uboot; tftpboot 0x83f00000 $dtb; bootz 0x80008000 0x83000000 0x83f00000

This patch series is the continuation of the patch series linked below.

https://lore.kernel.org/netdev/20230522121532.86610-1-arinc.unal at arinc9.com/

v1: https://lore.kernel.org/netdev/20231118123205.266819-1-arinc.unal at arinc9.com/

Ar?n?

v2:
- Shorten the patch series, include only 7 patches.
- Add the reviewed-by tags given.
- Patch 1
  - Change variable ordering of mt753x_conduit_state_change().
  - Define the mask variable and store BIT(cpu_dp->index) on it.
  - Disable CPU_EN if priv->active_cpu_ports is 0.
- Patch 5
	- On the patch log, take the irrelevant information about the
    mt7530_setup_port5() call from mt7530_setup() out.
- Patch 6
  - Change the patch log to reflect correct information.

Ar?n? ?NAL (7):
  net: dsa: mt7530: always trap frames to active CPU port on MT7530
  net: dsa: mt7530: use p5_interface_select as data type for p5_intf_sel
  net: dsa: mt7530: store port 5 SGMII capability of MT7531
  net: dsa: mt7530: improve comments regarding port 5 and 6
  net: dsa: mt7530: improve code path for setting up port 5
  net: dsa: mt7530: do not set priv->p5_interface on mt7530_setup_port5()
  net: dsa: mt7530: do not run mt7530_setup_port5() if port 5 is disabled

 drivers/net/dsa/mt7530-mdio.c |   7 +-
 drivers/net/dsa/mt7530.c      | 139 +++++++++++++++++++++----------------
 drivers/net/dsa/mt7530.h      |  16 +++--
 3 files changed, 91 insertions(+), 71 deletions(-)




From arinc.unal at arinc9.com  Tue Dec 26 20:43:41 2023
From: arinc.unal at arinc9.com (=?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=)
Date: Wed, 27 Dec 2023 07:43:41 +0300
Subject: [PATCH net-next v2 1/7] net: dsa: mt7530: always trap frames to active CPU port on MT7530
In-Reply-To: <20231227044347.107291-1-arinc.unal@arinc9.com>
References: <20231227044347.107291-1-arinc.unal@arinc9.com>
Message-ID: <20231227044347.107291-2-arinc.unal@arinc9.com>

On the MT7530 switch, the CPU_PORT field indicates which CPU port to trap
frames to, regardless of the affinity of the inbound user port.

When multiple CPU ports are in use, if the DSA conduit interface is down,
trapped frames won't be passed to the conduit interface.

To make trapping frames work including this case, implement
ds->ops->master_state_change() on this subdriver and set the CPU_PORT field
to the numerically smallest CPU port which the DSA conduit interface its
affine to is up. Introduce the active_cpu_ports field to store the
information of the active CPU ports. Correct the macros, CPU_PORT is bits 4
through 6 of the register.

Add a comment to explain frame trapping for this switch.

Currently, the driver doesn't support the use of multiple CPU ports so this
is not necessarily a bug fix.

Suggested-by: Vladimir Oltean <olteanv at gmail.com>
Suggested-by: Russell King (Oracle) <linux at armlinux.org.uk>
Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
---
 drivers/net/dsa/mt7530.c | 37 +++++++++++++++++++++++++++++++++----
 drivers/net/dsa/mt7530.h |  6 ++++--
 2 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 391c4dbdff42..436d5c311be0 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1035,10 +1035,6 @@ mt753x_cpu_port_enable(struct dsa_switch *ds, int port)
 	mt7530_set(priv, MT7530_MFC, BC_FFP(BIT(port)) | UNM_FFP(BIT(port)) |
 		   UNU_FFP(BIT(port)));
 
-	/* Set CPU port number */
-	if (priv->id == ID_MT7530 || priv->id == ID_MT7621)
-		mt7530_rmw(priv, MT7530_MFC, CPU_MASK, CPU_EN | CPU_PORT(port));
-
 	/* Add the CPU port to the CPU port bitmap for MT7531 and the switch on
 	 * the MT7988 SoC. Trapped frames will be forwarded to the CPU port that
 	 * is affine to the inbound user port.
@@ -3075,6 +3071,38 @@ static int mt753x_set_mac_eee(struct dsa_switch *ds, int port,
 	return 0;
 }
 
+static void
+mt753x_conduit_state_change(struct dsa_switch *ds,
+			    const struct net_device *conduit,
+			    bool operational)
+{
+	struct dsa_port *cpu_dp = conduit->dsa_ptr;
+	struct mt7530_priv *priv = ds->priv;
+	u8 mask;
+	int val = 0;
+
+	/* Set the CPU port to trap frames to for MT7530. Trapped frames will be
+	 * forwarded to the numerically smallest CPU port which the DSA conduit
+	 * interface its affine to is up.
+	 */
+	if (priv->id != ID_MT7530 && priv->id != ID_MT7621)
+		return;
+
+	mask = BIT(cpu_dp->index);
+
+	if (operational)
+		priv->active_cpu_ports |= mask;
+	else
+		priv->active_cpu_ports &= ~mask;
+
+	if (priv->active_cpu_ports)
+		val =
+		    CPU_EN |
+		    CPU_PORT(__ffs((unsigned long)priv->active_cpu_ports));
+
+	mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val);
+}
+
 static int mt7988_pad_setup(struct dsa_switch *ds, phy_interface_t interface)
 {
 	return 0;
@@ -3130,6 +3158,7 @@ const struct dsa_switch_ops mt7530_switch_ops = {
 	.phylink_mac_link_up	= mt753x_phylink_mac_link_up,
 	.get_mac_eee		= mt753x_get_mac_eee,
 	.set_mac_eee		= mt753x_set_mac_eee,
+	.conduit_state_change	= mt753x_conduit_state_change,
 };
 EXPORT_SYMBOL_GPL(mt7530_switch_ops);
 
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 17e42d30fff4..ebfb3a7acfcd 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -41,8 +41,8 @@ enum mt753x_id {
 #define  UNU_FFP(x)			(((x) & 0xff) << 8)
 #define  UNU_FFP_MASK			UNU_FFP(~0)
 #define  CPU_EN				BIT(7)
-#define  CPU_PORT(x)			((x) << 4)
-#define  CPU_MASK			(0xf << 4)
+#define  CPU_PORT_MASK			GENMASK(6, 4)
+#define  CPU_PORT(x)			FIELD_PREP(CPU_PORT_MASK, x)
 #define  MIRROR_EN			BIT(3)
 #define  MIRROR_PORT(x)			((x) & 0x7)
 #define  MIRROR_MASK			0x7
@@ -760,6 +760,7 @@ struct mt753x_info {
  * @irq_domain:		IRQ domain of the switch irq_chip
  * @irq_enable:		IRQ enable bits, synced to SYS_INT_EN
  * @create_sgmii:	Pointer to function creating SGMII PCS instance(s)
+ * @active_cpu_ports:	Holding the active CPU ports
  */
 struct mt7530_priv {
 	struct device		*dev;
@@ -786,6 +787,7 @@ struct mt7530_priv {
 	struct irq_domain *irq_domain;
 	u32 irq_enable;
 	int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii);
+	u8 active_cpu_ports;
 };
 
 struct mt7530_hw_vlan_entry {
-- 
2.40.1



From arinc.unal at arinc9.com  Tue Dec 26 20:43:42 2023
From: arinc.unal at arinc9.com (=?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=)
Date: Wed, 27 Dec 2023 07:43:42 +0300
Subject: [PATCH net-next v2 2/7] net: dsa: mt7530: use p5_interface_select as data type for p5_intf_sel
In-Reply-To: <20231227044347.107291-1-arinc.unal@arinc9.com>
References: <20231227044347.107291-1-arinc.unal@arinc9.com>
Message-ID: <20231227044347.107291-3-arinc.unal@arinc9.com>

Use the p5_interface_select enumeration as the data type for the
p5_intf_sel field. This ensures p5_intf_sel can only take the values
defined in the p5_interface_select enumeration.

Remove the explicit assignment of 0 to P5_DISABLED as the first enum item
is automatically assigned 0.

Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
Acked-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: Vladimir Oltean <olteanv at gmail.com>
---
 drivers/net/dsa/mt7530.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index ebfb3a7acfcd..9cbf18efa416 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -683,7 +683,7 @@ struct mt7530_port {
 
 /* Port 5 interface select definitions */
 enum p5_interface_select {
-	P5_DISABLED = 0,
+	P5_DISABLED,
 	P5_INTF_SEL_PHY_P0,
 	P5_INTF_SEL_PHY_P4,
 	P5_INTF_SEL_GMAC5,
@@ -776,7 +776,7 @@ struct mt7530_priv {
 	bool			mcm;
 	phy_interface_t		p6_interface;
 	phy_interface_t		p5_interface;
-	unsigned int		p5_intf_sel;
+	enum p5_interface_select p5_intf_sel;
 	u8			mirror_rx;
 	u8			mirror_tx;
 	struct mt7530_port	ports[MT7530_NUM_PORTS];
-- 
2.40.1



From arinc.unal at arinc9.com  Tue Dec 26 20:43:43 2023
From: arinc.unal at arinc9.com (=?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=)
Date: Wed, 27 Dec 2023 07:43:43 +0300
Subject: [PATCH net-next v2 3/7] net: dsa: mt7530: store port 5 SGMII capability of MT7531
In-Reply-To: <20231227044347.107291-1-arinc.unal@arinc9.com>
References: <20231227044347.107291-1-arinc.unal@arinc9.com>
Message-ID: <20231227044347.107291-4-arinc.unal@arinc9.com>

Introduce the p5_sgmii field to store the information for whether port 5
has got SGMII or not. Instead of reading the MT7531_TOP_SIG_SR register
multiple times, the register will be read once and the value will be
stored on the p5_sgmii field. This saves unnecessary reads of the
register.

Move the comment about MT7531AE and MT7531BE to mt7531_setup(), where the
switch is identified.

Get rid of mt7531_dual_sgmii_supported() now that priv->p5_sgmii stores the
information. Address the code where mt7531_dual_sgmii_supported() is used.

Get rid of mt7531_is_rgmii_port() which just prints the opposite of
priv->p5_sgmii.

Instead of calling mt7531_pll_setup() then returning, do not call it if
port 5 is SGMII.

Remove P5_INTF_SEL_GMAC5_SGMII. The p5_interface_select enum is supposed to
represent the mode that port 5 is being used in, not the hardware
information of port 5. Set p5_intf_sel to P5_INTF_SEL_GMAC5 instead, if
port 5 is not dsa_is_unused_port().

Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
Acked-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: Vladimir Oltean <olteanv at gmail.com>
---
 drivers/net/dsa/mt7530-mdio.c |  7 ++---
 drivers/net/dsa/mt7530.c      | 48 ++++++++++++-----------------------
 drivers/net/dsa/mt7530.h      |  6 +++--
 3 files changed, 22 insertions(+), 39 deletions(-)

diff --git a/drivers/net/dsa/mt7530-mdio.c b/drivers/net/dsa/mt7530-mdio.c
index 088533663b83..fa3ee85a99c1 100644
--- a/drivers/net/dsa/mt7530-mdio.c
+++ b/drivers/net/dsa/mt7530-mdio.c
@@ -81,17 +81,14 @@ static const struct regmap_bus mt7530_regmap_bus = {
 };
 
 static int
-mt7531_create_sgmii(struct mt7530_priv *priv, bool dual_sgmii)
+mt7531_create_sgmii(struct mt7530_priv *priv)
 {
 	struct regmap_config *mt7531_pcs_config[2] = {};
 	struct phylink_pcs *pcs;
 	struct regmap *regmap;
 	int i, ret = 0;
 
-	/* MT7531AE has two SGMII units for port 5 and port 6
-	 * MT7531BE has only one SGMII unit for port 6
-	 */
-	for (i = dual_sgmii ? 0 : 1; i < 2; i++) {
+	for (i = priv->p5_sgmii ? 0 : 1; i < 2; i++) {
 		mt7531_pcs_config[i] = devm_kzalloc(priv->dev,
 						    sizeof(struct regmap_config),
 						    GFP_KERNEL);
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 436d5c311be0..ab9b291c7a5f 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -487,15 +487,6 @@ mt7530_pad_clk_setup(struct dsa_switch *ds, phy_interface_t interface)
 	return 0;
 }
 
-static bool mt7531_dual_sgmii_supported(struct mt7530_priv *priv)
-{
-	u32 val;
-
-	val = mt7530_read(priv, MT7531_TOP_SIG_SR);
-
-	return (val & PAD_DUAL_SGMII_EN) != 0;
-}
-
 static int
 mt7531_pad_setup(struct dsa_switch *ds, phy_interface_t interface)
 {
@@ -510,9 +501,6 @@ mt7531_pll_setup(struct mt7530_priv *priv)
 	u32 xtal;
 	u32 val;
 
-	if (mt7531_dual_sgmii_supported(priv))
-		return;
-
 	val = mt7530_read(priv, MT7531_CREV);
 	top_sig = mt7530_read(priv, MT7531_TOP_SIG_SR);
 	hwstrap = mt7530_read(priv, MT7531_HWTRAP);
@@ -920,8 +908,6 @@ static const char *p5_intf_modes(unsigned int p5_interface)
 		return "PHY P4";
 	case P5_INTF_SEL_GMAC5:
 		return "GMAC5";
-	case P5_INTF_SEL_GMAC5_SGMII:
-		return "GMAC5_SGMII";
 	default:
 		return "unknown";
 	}
@@ -2470,6 +2456,12 @@ mt7531_setup(struct dsa_switch *ds)
 		return -ENODEV;
 	}
 
+	/* MT7531AE has got two SGMII units. One for port 5, one for port 6.
+	 * MT7531BE has got only one SGMII unit which is for port 6.
+	 */
+	val = mt7530_read(priv, MT7531_TOP_SIG_SR);
+	priv->p5_sgmii = !!(val & PAD_DUAL_SGMII_EN);
+
 	/* all MACs must be forced link-down before sw reset */
 	for (i = 0; i < MT7530_NUM_PORTS; i++)
 		mt7530_write(priv, MT7530_PMCR_P(i), MT7531_FORCE_LNK);
@@ -2479,21 +2471,18 @@ mt7531_setup(struct dsa_switch *ds)
 		     SYS_CTRL_PHY_RST | SYS_CTRL_SW_RST |
 		     SYS_CTRL_REG_RST);
 
-	mt7531_pll_setup(priv);
-
-	if (mt7531_dual_sgmii_supported(priv)) {
-		priv->p5_intf_sel = P5_INTF_SEL_GMAC5_SGMII;
-
+	if (!priv->p5_sgmii) {
+		mt7531_pll_setup(priv);
+	} else {
 		/* Let ds->user_mii_bus be able to access external phy. */
 		mt7530_rmw(priv, MT7531_GPIO_MODE1, MT7531_GPIO11_RG_RXD2_MASK,
 			   MT7531_EXT_P_MDC_11);
 		mt7530_rmw(priv, MT7531_GPIO_MODE1, MT7531_GPIO12_RG_RXD3_MASK,
 			   MT7531_EXT_P_MDIO_12);
-	} else {
-		priv->p5_intf_sel = P5_INTF_SEL_GMAC5;
 	}
-	dev_dbg(ds->dev, "P5 support %s interface\n",
-		p5_intf_modes(priv->p5_intf_sel));
+
+	if (!dsa_is_unused_port(ds, 5))
+		priv->p5_intf_sel = P5_INTF_SEL_GMAC5;
 
 	mt7530_rmw(priv, MT7531_GPIO_MODE0, MT7531_GPIO0_MASK,
 		   MT7531_GPIO0_INTERRUPT);
@@ -2553,11 +2542,6 @@ static void mt7530_mac_port_get_caps(struct dsa_switch *ds, int port,
 	}
 }
 
-static bool mt7531_is_rgmii_port(struct mt7530_priv *priv, u32 port)
-{
-	return (port == 5) && (priv->p5_intf_sel != P5_INTF_SEL_GMAC5_SGMII);
-}
-
 static void mt7531_mac_port_get_caps(struct dsa_switch *ds, int port,
 				     struct phylink_config *config)
 {
@@ -2570,7 +2554,7 @@ static void mt7531_mac_port_get_caps(struct dsa_switch *ds, int port,
 		break;
 
 	case 5: /* 2nd cpu port supports either rgmii or sgmii/8023z */
-		if (mt7531_is_rgmii_port(priv, port)) {
+		if (!priv->p5_sgmii) {
 			phy_interface_set_rgmii(config->supported_interfaces);
 			break;
 		}
@@ -2637,7 +2621,7 @@ static int mt7531_rgmii_setup(struct mt7530_priv *priv, u32 port,
 {
 	u32 val;
 
-	if (!mt7531_is_rgmii_port(priv, port)) {
+	if (priv->p5_sgmii) {
 		dev_err(priv->dev, "RGMII mode is not available for port %d\n",
 			port);
 		return -EINVAL;
@@ -2881,7 +2865,7 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int port)
 
 	switch (port) {
 	case 5:
-		if (mt7531_is_rgmii_port(priv, port))
+		if (!priv->p5_sgmii)
 			interface = PHY_INTERFACE_MODE_RGMII;
 		else
 			interface = PHY_INTERFACE_MODE_2500BASEX;
@@ -3033,7 +3017,7 @@ mt753x_setup(struct dsa_switch *ds)
 		mt7530_free_irq_common(priv);
 
 	if (priv->create_sgmii) {
-		ret = priv->create_sgmii(priv, mt7531_dual_sgmii_supported(priv));
+		ret = priv->create_sgmii(priv);
 		if (ret && priv->irq)
 			mt7530_free_irq(priv);
 	}
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 9cbf18efa416..80060cc740d2 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -687,7 +687,6 @@ enum p5_interface_select {
 	P5_INTF_SEL_PHY_P0,
 	P5_INTF_SEL_PHY_P4,
 	P5_INTF_SEL_GMAC5,
-	P5_INTF_SEL_GMAC5_SGMII,
 };
 
 struct mt7530_priv;
@@ -756,6 +755,8 @@ struct mt753x_info {
  *			registers
  * @p6_interface	Holding the current port 6 interface
  * @p5_intf_sel:	Holding the current port 5 interface select
+ * @p5_sgmii:		Flag for distinguishing if port 5 of the MT7531 switch
+ *			has got SGMII
  * @irq:		IRQ number of the switch
  * @irq_domain:		IRQ domain of the switch irq_chip
  * @irq_enable:		IRQ enable bits, synced to SYS_INT_EN
@@ -777,6 +778,7 @@ struct mt7530_priv {
 	phy_interface_t		p6_interface;
 	phy_interface_t		p5_interface;
 	enum p5_interface_select p5_intf_sel;
+	bool			p5_sgmii;
 	u8			mirror_rx;
 	u8			mirror_tx;
 	struct mt7530_port	ports[MT7530_NUM_PORTS];
@@ -786,7 +788,7 @@ struct mt7530_priv {
 	int irq;
 	struct irq_domain *irq_domain;
 	u32 irq_enable;
-	int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii);
+	int (*create_sgmii)(struct mt7530_priv *priv);
 	u8 active_cpu_ports;
 };
 
-- 
2.40.1



From arinc.unal at arinc9.com  Tue Dec 26 20:43:44 2023
From: arinc.unal at arinc9.com (=?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=)
Date: Wed, 27 Dec 2023 07:43:44 +0300
Subject: [PATCH net-next v2 4/7] net: dsa: mt7530: improve comments regarding port 5 and 6
In-Reply-To: <20231227044347.107291-1-arinc.unal@arinc9.com>
References: <20231227044347.107291-1-arinc.unal@arinc9.com>
Message-ID: <20231227044347.107291-5-arinc.unal@arinc9.com>

There's no logic to numerically order the CPU ports. State the port number
and its capability of being used as a CPU port instead.

Remove the irrelevant PHY muxing information from
mt7530_mac_port_get_caps(). Explain the supported MII modes instead.

Remove the out of place PHY muxing information from
mt753x_phylink_mac_config(). The function is for MT7530, MT7531, and the
switch on the MT7988 SoC but there's no PHY muxing on MT7531 or the switch
on the MT7988 SoC.

These comments were gradually introduced with the commits below.
ca366d6c889b ("net: dsa: mt7530: Convert to PHYLINK API")
38f790a80560 ("net: dsa: mt7530: Add support for port 5")
88bdef8be9f6 ("net: dsa: mt7530: Extend device data ready for adding a new
hardware")
c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch")

Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
Acked-by: Daniel Golle <daniel at makrotopia.org>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
 drivers/net/dsa/mt7530.c | 32 ++++++++++++++++++++++----------
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index ab9b291c7a5f..558784f830c2 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2520,12 +2520,16 @@ static void mt7530_mac_port_get_caps(struct dsa_switch *ds, int port,
 				     struct phylink_config *config)
 {
 	switch (port) {
-	case 0 ... 4: /* Internal phy */
+	/* Internal PHY */
+	case 0 ... 4:
 		__set_bit(PHY_INTERFACE_MODE_GMII,
 			  config->supported_interfaces);
 		break;
 
-	case 5: /* 2nd cpu port with phy of port 0 or 4 / external phy */
+	/* Port 5 which can be used as a CPU port supports rgmii with delays,
+	 * mii, and gmii.
+	 */
+	case 5:
 		phy_interface_set_rgmii(config->supported_interfaces);
 		__set_bit(PHY_INTERFACE_MODE_MII,
 			  config->supported_interfaces);
@@ -2533,7 +2537,8 @@ static void mt7530_mac_port_get_caps(struct dsa_switch *ds, int port,
 			  config->supported_interfaces);
 		break;
 
-	case 6: /* 1st cpu port */
+	/* Port 6 which can be used as a CPU port supports rgmii and trgmii. */
+	case 6:
 		__set_bit(PHY_INTERFACE_MODE_RGMII,
 			  config->supported_interfaces);
 		__set_bit(PHY_INTERFACE_MODE_TRGMII,
@@ -2548,19 +2553,24 @@ static void mt7531_mac_port_get_caps(struct dsa_switch *ds, int port,
 	struct mt7530_priv *priv = ds->priv;
 
 	switch (port) {
-	case 0 ... 4: /* Internal phy */
+	/* Internal PHY */
+	case 0 ... 4:
 		__set_bit(PHY_INTERFACE_MODE_GMII,
 			  config->supported_interfaces);
 		break;
 
-	case 5: /* 2nd cpu port supports either rgmii or sgmii/8023z */
+	/* Port 5 which can be used as a CPU port supports rgmii with delays on
+	 * MT7531BE, sgmii/802.3z on MT7531AE.
+	 */
+	case 5:
 		if (!priv->p5_sgmii) {
 			phy_interface_set_rgmii(config->supported_interfaces);
 			break;
 		}
 		fallthrough;
 
-	case 6: /* 1st cpu port supports sgmii/8023z only */
+	/* Port 6 which can be used as a CPU port supports sgmii/802.3z. */
+	case 6:
 		__set_bit(PHY_INTERFACE_MODE_SGMII,
 			  config->supported_interfaces);
 		__set_bit(PHY_INTERFACE_MODE_1000BASEX,
@@ -2579,11 +2589,13 @@ static void mt7988_mac_port_get_caps(struct dsa_switch *ds, int port,
 	phy_interface_zero(config->supported_interfaces);
 
 	switch (port) {
-	case 0 ... 4: /* Internal phy */
+	/* Internal PHY */
+	case 0 ... 4:
 		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
 			  config->supported_interfaces);
 		break;
 
+	/* Port 6 which can be used as a CPU port is an internal 10G port. */
 	case 6:
 		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
 			  config->supported_interfaces);
@@ -2747,12 +2759,12 @@ mt753x_phylink_mac_config(struct dsa_switch *ds, int port, unsigned int mode,
 	u32 mcr_cur, mcr_new;
 
 	switch (port) {
-	case 0 ... 4: /* Internal phy */
+	case 0 ... 4:
 		if (state->interface != PHY_INTERFACE_MODE_GMII &&
 		    state->interface != PHY_INTERFACE_MODE_INTERNAL)
 			goto unsupported;
 		break;
-	case 5: /* 2nd cpu port with phy of port 0 or 4 / external phy */
+	case 5:
 		if (priv->p5_interface == state->interface)
 			break;
 
@@ -2762,7 +2774,7 @@ mt753x_phylink_mac_config(struct dsa_switch *ds, int port, unsigned int mode,
 		if (priv->p5_intf_sel != P5_DISABLED)
 			priv->p5_interface = state->interface;
 		break;
-	case 6: /* 1st cpu port */
+	case 6:
 		if (priv->p6_interface == state->interface)
 			break;
 
-- 
2.40.1



From arinc.unal at arinc9.com  Tue Dec 26 20:43:45 2023
From: arinc.unal at arinc9.com (=?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=)
Date: Wed, 27 Dec 2023 07:43:45 +0300
Subject: [PATCH net-next v2 5/7] net: dsa: mt7530: improve code path for setting up port 5
In-Reply-To: <20231227044347.107291-1-arinc.unal@arinc9.com>
References: <20231227044347.107291-1-arinc.unal@arinc9.com>
Message-ID: <20231227044347.107291-6-arinc.unal@arinc9.com>

There're two code paths for setting up port 5:

mt7530_setup()
-> mt7530_setup_port5()

mt753x_phylink_mac_config()
-> mt753x_mac_config()
   -> mt7530_mac_config()
      -> mt7530_setup_port5()

Currently mt7530_setup_port5() from mt7530_setup() always runs. If port 5
is used as a CPU, DSA, or user port, mt7530_setup_port5() from
mt753x_phylink_mac_config() won't run. That is because priv->p5_interface
set on mt7530_setup_port5() will match state->interface on
mt753x_phylink_mac_config() which will stop running mt7530_setup_port5()
again.

Therefore, mt7530_setup_port5() will never run from
mt753x_phylink_mac_config().

Address this by not running mt7530_setup_port5() from mt7530_setup() if
port 5 is used as a CPU, DSA, or user port. This driver isn't in the
dsa_switches_apply_workarounds[] array so phylink will always be present.

To keep the cases where port 5 isn't controlled by phylink working as
before, preserve the mt7530_setup_port5() call from mt7530_setup().

Do not set priv->p5_intf_sel to P5_DISABLED. It is already set to that when
"priv" is allocated.

Move setting the interface to a more specific location. It's supposed to be
overwritten if PHY muxing is detected.

Improve the comment which explains the process.

Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
---
 drivers/net/dsa/mt7530.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 558784f830c2..bf6c59ecc489 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2308,16 +2308,15 @@ mt7530_setup(struct dsa_switch *ds)
 		return ret;
 
 	/* Setup port 5 */
-	priv->p5_intf_sel = P5_DISABLED;
-	interface = PHY_INTERFACE_MODE_NA;
-
 	if (!dsa_is_unused_port(ds, 5)) {
 		priv->p5_intf_sel = P5_INTF_SEL_GMAC5;
-		ret = of_get_phy_mode(dsa_to_port(ds, 5)->dn, &interface);
-		if (ret && ret != -ENODEV)
-			return ret;
 	} else {
-		/* Scan the ethernet nodes. look for GMAC1, lookup used phy */
+		/* Scan the ethernet nodes. Look for GMAC1, lookup the used PHY.
+		 * Set priv->p5_intf_sel to the appropriate value if PHY muxing
+		 * is detected.
+		 */
+		interface = PHY_INTERFACE_MODE_NA;
+
 		for_each_child_of_node(dn, mac_np) {
 			if (!of_device_is_compatible(mac_np,
 						     "mediatek,eth-mac"))
@@ -2348,6 +2347,8 @@ mt7530_setup(struct dsa_switch *ds)
 			of_node_put(phy_node);
 			break;
 		}
+
+		mt7530_setup_port5(ds, interface);
 	}
 
 #ifdef CONFIG_GPIOLIB
@@ -2358,8 +2359,6 @@ mt7530_setup(struct dsa_switch *ds)
 	}
 #endif /* CONFIG_GPIOLIB */
 
-	mt7530_setup_port5(ds, interface);
-
 	/* Flush the FDB table */
 	ret = mt7530_fdb_cmd(priv, MT7530_FDB_FLUSH, NULL);
 	if (ret < 0)
-- 
2.40.1



From arinc.unal at arinc9.com  Tue Dec 26 20:43:46 2023
From: arinc.unal at arinc9.com (=?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=)
Date: Wed, 27 Dec 2023 07:43:46 +0300
Subject: [PATCH net-next v2 6/7] net: dsa: mt7530: do not set priv->p5_interface on mt7530_setup_port5()
In-Reply-To: <20231227044347.107291-1-arinc.unal@arinc9.com>
References: <20231227044347.107291-1-arinc.unal@arinc9.com>
Message-ID: <20231227044347.107291-7-arinc.unal@arinc9.com>

priv->p5_interface and priv->p6_interface are for use on the MT7531 switch.
They prevent the CPU ports of MT7531 to be configured again. They are
useless for MT7530. Therefore, remove setting priv->p5_interface for
MT7530.

Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
---
 drivers/net/dsa/mt7530.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index bf6c59ecc489..07c5f1c6d036 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -978,8 +978,6 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
 	dev_dbg(ds->dev, "Setup P5, HWTRAP=0x%x, intf_sel=%s, phy-mode=%s\n",
 		val, p5_intf_modes(priv->p5_intf_sel), phy_modes(interface));
 
-	priv->p5_interface = interface;
-
 unlock_exit:
 	mutex_unlock(&priv->reg_mutex);
 }
-- 
2.40.1



From arinc.unal at arinc9.com  Tue Dec 26 20:43:47 2023
From: arinc.unal at arinc9.com (=?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?=)
Date: Wed, 27 Dec 2023 07:43:47 +0300
Subject: [PATCH net-next v2 7/7] net: dsa: mt7530: do not run mt7530_setup_port5() if port 5 is disabled
In-Reply-To: <20231227044347.107291-1-arinc.unal@arinc9.com>
References: <20231227044347.107291-1-arinc.unal@arinc9.com>
Message-ID: <20231227044347.107291-8-arinc.unal@arinc9.com>

There's no need to run all the code on mt7530_setup_port5() if port 5 is
disabled. The only case for calling mt7530_setup_port5() from
mt7530_setup() is when PHY muxing is enabled. That is because port 5 is not
defined as a port on the devicetree, therefore, it cannot be controlled by
phylink.

Because of this, run mt7530_setup_port5() if priv->p5_intf_sel is
P5_INTF_SEL_PHY_P0 or P5_INTF_SEL_PHY_P4. Remove the P5_DISABLED case from
mt7530_setup_port5().

Stop initialising the interface variable as the remaining cases will always
call mt7530_setup_port5() with it initialised.

Signed-off-by: Ar?n? ?NAL <arinc.unal at arinc9.com>
Reviewed-by: Vladimir Oltean <olteanv at gmail.com>
---
 drivers/net/dsa/mt7530.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 07c5f1c6d036..0c3b2b75f106 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -942,9 +942,6 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
 		/* MT7530_P5_MODE_GMAC: P5 -> External phy or 2nd GMAC */
 		val &= ~MHWTRAP_P5_DIS;
 		break;
-	case P5_DISABLED:
-		interface = PHY_INTERFACE_MODE_NA;
-		break;
 	default:
 		dev_err(ds->dev, "Unsupported p5_intf_sel %d\n",
 			priv->p5_intf_sel);
@@ -2313,8 +2310,6 @@ mt7530_setup(struct dsa_switch *ds)
 		 * Set priv->p5_intf_sel to the appropriate value if PHY muxing
 		 * is detected.
 		 */
-		interface = PHY_INTERFACE_MODE_NA;
-
 		for_each_child_of_node(dn, mac_np) {
 			if (!of_device_is_compatible(mac_np,
 						     "mediatek,eth-mac"))
@@ -2346,7 +2341,9 @@ mt7530_setup(struct dsa_switch *ds)
 			break;
 		}
 
-		mt7530_setup_port5(ds, interface);
+		if (priv->p5_intf_sel == P5_INTF_SEL_PHY_P0 ||
+		    priv->p5_intf_sel == P5_INTF_SEL_PHY_P4)
+			mt7530_setup_port5(ds, interface);
 	}
 
 #ifdef CONFIG_GPIOLIB
-- 
2.40.1



From chunfeng.yun at mediatek.com  Tue Dec 26 22:03:16 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Wed, 27 Dec 2023 14:03:16 +0800
Subject: [PATCH v4 3/3] arm64: dts: mediatek: mt8195: Add 'rx-fifo-depth' for cherry
In-Reply-To: <20231227060316.8539-1-chunfeng.yun@mediatek.com>
References: <20231227060316.8539-1-chunfeng.yun@mediatek.com>
Message-ID: <20231227060316.8539-3-chunfeng.yun@mediatek.com>

Add the quirk property "rx-fifo-depth" to work around Gen1 isoc-in
transfer issue which send out unexpected ACK even after device
already finished the burst transfer with a short patcket, specially
for a 4K camera device.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v4:
change property value, and put before supply
add reviewed-by Angelo
v3: change value according to binding
v2: use 'rx-fifo-depth' property
---
 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index dd5b89b73190..00fcde60300e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -1183,6 +1183,7 @@
 &xhci0 {
 	status = "okay";
 
+	rx-fifo-depth = <3072>;
 	vusb33-supply = <&mt6359_vusb_ldo_reg>;
 	vbus-supply = <&usb_vbus>;
 };
@@ -1190,6 +1191,7 @@
 &xhci1 {
 	status = "okay";
 
+	rx-fifo-depth = <3072>;
 	vusb33-supply = <&mt6359_vusb_ldo_reg>;
 	vbus-supply = <&usb_vbus>;
 };
-- 
2.18.0



From chunfeng.yun at mediatek.com  Tue Dec 26 22:03:14 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Wed, 27 Dec 2023 14:03:14 +0800
Subject: [PATCH v4 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1 isoc-in transfer issue
Message-ID: <20231227060316.8539-1-chunfeng.yun@mediatek.com>

For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
still send out unexpected ACK after receiving a short packet in burst
transfer, this will cause an exception on connected device, specially for
a 4k camera.
Add a quirk property "rx-fifo-depth" to work around this hardware issue,
prefer to use 3k bytes;
The side-effect is that may cause performance drop about 10%, including
bulk transfer.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v4: change rx-fifo size in bytes
v3: add fifo depth unit, change the value range from 0-3 to 1-4
v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
---
 .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml    | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index e9644e333d78..9f621f2209df 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -124,6 +124,17 @@ properties:
       defined in the xHCI spec on MTK's controller.
     default: 5000
 
+  rx-fifo-depth:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      It is a quirk used to work around Gen1 isoc-in endpoint transfer issue
+      that still send out unexpected ACK after device finish the burst transfer
+      with a short packet and cause an exception, specially on a 4K camera
+      device, it happens on controller before about IPM v1.6.0; the side-effect
+      is that may cause performance drop about 10%, include bulk transfer,
+      prefer to use 3k here. The size is in bytes.
+    enum: [1024, 2048, 3072, 4096]
+
   # the following properties are only used for case 1
   wakeup-source:
     description: enable USB remote wakeup, see power/wakeup-source.txt
-- 
2.18.0



From Jason-JH.Lin at mediatek.com  Tue Dec 26 22:15:07 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 06:15:07 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <13754f308ce9ff1a9787b2597e416613b638c611.camel@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
	 <13754f308ce9ff1a9787b2597e416613b638c611.camel@mediatek.com>
Message-ID: <96712d3424f630480eed4bf2f4d5417a70b2a3a4.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Tue, 2023-12-26 at 07:57 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> > To support secure video path feature, GCE have to read/write
> > registgers
> > in the secure world. GCE will enable the secure access permission
> > to
> > the
> > HW who wants to access the secure content buffer.
> > 
> > Add CMDQ secure mailbox driver to make CMDQ client user is able to
> > sending their HW settings to the secure world. So that GCE can
> > execute
> > all instructions to configure HW in the secure world.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> 
> [snip]
> 
> > +
> > +static u32 cmdq_sec_get_cookie(struct cmdq_sec *cmdq, u32 idx)
> > +{
> > +	return *(u32 *)(cmdq->shared_mem->va +
> > +		CMDQ_SEC_SHARED_THR_CNT_OFFSET + idx * sizeof(u32));
> > +}
> 
> cmdq_sec_get_cookie() is called in normal context not irq context, so
> we could allow a function call into TEE to query cookie even though
> the
> function call would take time. Therefore, it's not necessary to use a
> cmdq command to copy cookie value into share memory.
> 
> Regards,
> CK

OK, I will try it and see if we can remove this share memory.

Regards,
Jason-JH.Lin

From chunfeng.yun at mediatek.com  Tue Dec 26 22:03:15 2023
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Wed, 27 Dec 2023 14:03:15 +0800
Subject: [PATCH v4 2/3] usb: xhci-mtk: fix a short packet issue of gen1 isoc-in transfer
In-Reply-To: <20231227060316.8539-1-chunfeng.yun@mediatek.com>
References: <20231227060316.8539-1-chunfeng.yun@mediatek.com>
Message-ID: <20231227060316.8539-2-chunfeng.yun@mediatek.com>

For Gen1 isoc-in transfer, host still send out unexpected ACK after device
finish the burst with a short packet, this will cause an exception on the
connected device, such as, a usb 4k camera.
It can be fixed by setting rxfifo depth less than 4k bytes, prefer to use
3k here, the side-effect is that may cause performance drop about 10%,
including bulk transfer.

Fixes: 926d60ae64a6 ("usb: xhci-mtk: modify the SOF/ITP interval for mt8195")
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v4:
drop Cc stable
add reviewed-by Angelo
change rxfifo depth in bytes
v3:
add Cc stable
change @rxfifo_depth from int to u32, due to property's value range is changed
v2:
use 'rx-fifo-depth' property;
add header file 'linux/bitfield.h' to avoid building error on some ARCH;
---
 drivers/usb/host/xhci-mtk.c | 40 +++++++++++++++++++++++++++++++++++--
 drivers/usb/host/xhci-mtk.h |  2 ++
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bbdf1b0b7be1..3252e3d2d79c 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -7,6 +7,7 @@
  *  Chunfeng Yun <chunfeng.yun at mediatek.com>
  */
 
+#include <linux/bitfield.h>
 #include <linux/dma-mapping.h>
 #include <linux/iopoll.h>
 #include <linux/kernel.h>
@@ -73,6 +74,9 @@
 #define FRMCNT_LEV1_RANG	(0x12b << 8)
 #define FRMCNT_LEV1_RANG_MASK	GENMASK(19, 8)
 
+#define HSCH_CFG1		0x960
+#define SCH3_RXFIFO_DEPTH_MASK	GENMASK(21, 20)
+
 #define SS_GEN2_EOF_CFG		0x990
 #define SSG2EOF_OFFSET		0x3c
 
@@ -114,6 +118,8 @@
 #define SSC_IP_SLEEP_EN	BIT(4)
 #define SSC_SPM_INT_EN		BIT(1)
 
+#define SCH_FIFO_TO_KB(x)	((x) >> 10)
+
 enum ssusb_uwk_vers {
 	SSUSB_UWK_V1 = 1,
 	SSUSB_UWK_V2,
@@ -165,6 +171,35 @@ static void xhci_mtk_set_frame_interval(struct xhci_hcd_mtk *mtk)
 	writel(value, hcd->regs + SS_GEN2_EOF_CFG);
 }
 
+/*
+ * workaround: usb3.2 gen1 isoc rx hw issue
+ * host send out unexpected ACK afer device fininsh a burst transfer with
+ * a short packet.
+ */
+static void xhci_mtk_rxfifo_depth_set(struct xhci_hcd_mtk *mtk)
+{
+	struct usb_hcd *hcd = mtk->hcd;
+	u32 value;
+
+	if (!mtk->rxfifo_depth)
+		return;
+
+	value = readl(hcd->regs + HSCH_CFG1);
+	value &= ~SCH3_RXFIFO_DEPTH_MASK;
+	value |= FIELD_PREP(SCH3_RXFIFO_DEPTH_MASK,
+			    SCH_FIFO_TO_KB(mtk->rxfifo_depth) - 1);
+	writel(value, hcd->regs + HSCH_CFG1);
+}
+
+static void xhci_mtk_init_quirk(struct xhci_hcd_mtk *mtk)
+{
+	/* workaround only for mt8195 */
+	xhci_mtk_set_frame_interval(mtk);
+
+	/* workaround for SoCs using SSUSB about before IPM v1.6.0 */
+	xhci_mtk_rxfifo_depth_set(mtk);
+}
+
 static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
 {
 	struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
@@ -448,8 +483,7 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
 		if (ret)
 			return ret;
 
-		/* workaround only for mt8195 */
-		xhci_mtk_set_frame_interval(mtk);
+		xhci_mtk_init_quirk(mtk);
 	}
 
 	ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
@@ -527,6 +561,8 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	of_property_read_u32(node, "mediatek,u2p-dis-msk",
 			     &mtk->u2p_dis_msk);
 
+	of_property_read_u32(node, "rx-fifo-depth", &mtk->rxfifo_depth);
+
 	ret = usb_wakeup_of_property_parse(mtk, node);
 	if (ret) {
 		dev_err(dev, "failed to parse uwk property\n");
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 39f7ae7d3087..f5e2bd66bb1b 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -171,6 +171,8 @@ struct xhci_hcd_mtk {
 	struct regmap *uwk;
 	u32 uwk_reg_base;
 	u32 uwk_vers;
+	/* quirk */
+	u32 rxfifo_depth;
 };
 
 static inline struct xhci_hcd_mtk *hcd_to_mtk(struct usb_hcd *hcd)
-- 
2.18.0



From Jason-JH.Lin at mediatek.com  Tue Dec 26 22:13:01 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 06:13:01 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <957c5ec4fe3a1ad6eb44df37bd68cfedfcb0b926.camel@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
	 <957c5ec4fe3a1ad6eb44df37bd68cfedfcb0b926.camel@mediatek.com>
Message-ID: <db1591bdf52f3cd02335155c45cb7841da9fcbc1.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Tue, 2023-12-26 at 06:46 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> > To support secure video path feature, GCE have to read/write
> > registgers
> > in the secure world. GCE will enable the secure access permission
> > to
> > the
> > HW who wants to access the secure content buffer.
> > 
> > Add CMDQ secure mailbox driver to make CMDQ client user is able to
> > sending their HW settings to the secure world. So that GCE can
> > execute
> > all instructions to configure HW in the secure world.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> 
> [snip]
> 
> > +
> > +static int cmdq_sec_session_init(struct cmdq_sec_context *context)
> > +{
> > +	int err = 0;
> > +
> > +	if (context->state >= IWC_SES_OPENED) {
> > +		pr_debug("session opened:%u", context->state);
> > +		return 0;
> > +	}
> > +
> > +	switch (context->state) {
> > +	case IWC_INIT:
> > +		err = cmdq_sec_init_context(&context->tee_ctx);
> > +		if (err)
> > +			return err;
> > +		context->state = IWC_CONTEXT_INITED;
> > +	fallthrough;
> > +	case IWC_CONTEXT_INITED:
> > +		if (context->iwc_msg) {
> > +			pr_err("iwcMessage not NULL:%p", context-
> > > iwc_msg);
> > 
> > +			return -EINVAL;
> > +		}
> > +
> > +		err = cmdq_sec_allocate_wsm(&context->tee_ctx,
> > &context->iwc_msg,
> > +					    sizeof(struct
> > iwc_cmdq_message_t));
> > +		if (err)
> > +			return err;
> > +
> > +		context->state = IWC_WSM_ALLOCATED;
> > +	fallthrough;
> 
> Squash cmdq_sec_session_init() into cmdq_sec_mbox_of_xlate() and drop
> the context->state.
> 
> Regards,
> CK
> 
cmdq_sec_session_init() is called in the first cmdq_sec_task_submit().
It means we don't need to connect a session to TEE or allocate share
memory if no one submit secure task.

On the other hand, optee may load slower than cmdq secure driver. If we
move it to xlate secure session may init fail.

Regards,
Jason-JH.Lin

From mani at kernel.org  Tue Dec 26 22:30:38 2023
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Wed, 27 Dec 2023 12:00:38 +0530
Subject: [PATCH v2] ufs: mcq: Adding a function for MCQ enable
In-Reply-To: <20231221065608.9899-1-cw9316.lee@samsung.com>
References: <CGME20231221065637epcas1p203dcd5cfb1d4a3964fff9543a041d78d@epcas1p2.samsung.com>
 <20231221065608.9899-1-cw9316.lee@samsung.com>
Message-ID: <20231227063038.GJ2814@thinkpad>

On Thu, Dec 21, 2023 at 03:56:08PM +0900, Chanwoo Lee wrote:
> From: ChanWoo Lee <cw9316.lee at samsung.com>
> 
> The REG_UFS_MEM_CFG register is too general(broad)
> and it is difficult to know the meaning only with a value of 0x1.
> So far, comments were required.
> 
> Therefore, I have added new functions and defines
> to improve code readability/reusability.
> 
> Signed-off-by: ChanWoo Lee <cw9316.lee at samsung.com>

I would reword the subject and description as below:

```
ufs: mcq: Add definition for REG_UFS_MEM_CFG register

Instead of hardcoding the register field, add the proper definition. While
at it, let's also use ufshcd_rmwl() to simplify updating this register.
```

- Mani
> 
> * v1->v2:
>    1) Excluding ESI_ENABLE
>    2) Replace with ufshcd_rmwl, BIT()
>    3) Separating hba->mcq_enabled
> ---
>  drivers/ufs/core/ufs-mcq.c      | 6 ++++++
>  drivers/ufs/core/ufshcd.c       | 4 +---
>  drivers/ufs/host/ufs-mediatek.c | 4 +---
>  include/ufs/ufshcd.h            | 1 +
>  include/ufs/ufshci.h            | 3 +++
>  5 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-mcq.c
> index 0787456c2b89..edc752e55878 100644
> --- a/drivers/ufs/core/ufs-mcq.c
> +++ b/drivers/ufs/core/ufs-mcq.c
> @@ -399,6 +399,12 @@ void ufshcd_mcq_enable_esi(struct ufs_hba *hba)
>  }
>  EXPORT_SYMBOL_GPL(ufshcd_mcq_enable_esi);
>  
> +void ufshcd_mcq_enable(struct ufs_hba *hba)
> +{
> +	ufshcd_rmwl(hba, MCQ_MODE_SELECT, MCQ_MODE_SELECT, REG_UFS_MEM_CFG);
> +}
> +EXPORT_SYMBOL_GPL(ufshcd_mcq_enable);
> +
>  void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg *msg)
>  {
>  	ufshcd_writel(hba, msg->address_lo, REG_UFS_ESILBA);
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index ae9936fc6ffb..30df6f6a72c6 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -8723,9 +8723,7 @@ static void ufshcd_config_mcq(struct ufs_hba *hba)
>  	hba->host->can_queue = hba->nutrs - UFSHCD_NUM_RESERVED;
>  	hba->reserved_slot = hba->nutrs - UFSHCD_NUM_RESERVED;
>  
> -	/* Select MCQ mode */
> -	ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
> -		      REG_UFS_MEM_CFG);
> +	ufshcd_mcq_enable(hba);
>  	hba->mcq_enabled = true;
>  
>  	dev_info(hba->dev, "MCQ configured, nr_queues=%d, io_queues=%d, read_queue=%d, poll_queues=%d, queue_depth=%d\n",
> diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
> index fc61790d289b..1048add66419 100644
> --- a/drivers/ufs/host/ufs-mediatek.c
> +++ b/drivers/ufs/host/ufs-mediatek.c
> @@ -1219,9 +1219,7 @@ static int ufs_mtk_link_set_hpm(struct ufs_hba *hba)
>  		ufs_mtk_config_mcq(hba, false);
>  		ufshcd_mcq_make_queues_operational(hba);
>  		ufshcd_mcq_config_mac(hba, hba->nutrs);
> -		/* Enable MCQ mode */
> -		ufshcd_writel(hba, ufshcd_readl(hba, REG_UFS_MEM_CFG) | 0x1,
> -			      REG_UFS_MEM_CFG);
> +		ufshcd_mcq_enable(hba);
>  	}
>  
>  	if (err)
> diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
> index d862c8ddce03..a96c45fa4b4b 100644
> --- a/include/ufs/ufshcd.h
> +++ b/include/ufs/ufshcd.h
> @@ -1257,6 +1257,7 @@ unsigned long ufshcd_mcq_poll_cqe_lock(struct ufs_hba *hba,
>  					 struct ufs_hw_queue *hwq);
>  void ufshcd_mcq_make_queues_operational(struct ufs_hba *hba);
>  void ufshcd_mcq_enable_esi(struct ufs_hba *hba);
> +void ufshcd_mcq_enable(struct ufs_hba *hba);
>  void ufshcd_mcq_config_esi(struct ufs_hba *hba, struct msi_msg *msg);
>  
>  int ufshcd_opp_config_clks(struct device *dev, struct opp_table *opp_table,
> diff --git a/include/ufs/ufshci.h b/include/ufs/ufshci.h
> index d5accacae6bc..2a6989a70671 100644
> --- a/include/ufs/ufshci.h
> +++ b/include/ufs/ufshci.h
> @@ -282,6 +282,9 @@ enum {
>  /* UTMRLRSR - UTP Task Management Request Run-Stop Register 80h */
>  #define UTP_TASK_REQ_LIST_RUN_STOP_BIT		0x1
>  
> +/* REG_UFS_MEM_CFG - Global Config Registers 300h */
> +#define MCQ_MODE_SELECT 	BIT(0)
> +
>  /* CQISy - CQ y Interrupt Status Register  */
>  #define UFSHCD_MCQ_CQIS_TAIL_ENT_PUSH_STS	0x1
>  
> -- 
> 2.29.0
> 

-- 
????????? ????????


From Jason-JH.Lin at mediatek.com  Tue Dec 26 23:05:45 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 07:05:45 +0000
Subject: [PATCH v3 09/11] drm/mediatek: Add secure flow support to
 mediatek-drm
In-Reply-To: <63c24cda9e007ef2128e9350b6a6ed3bc61f3a85.camel@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-10-jason-jh.lin@mediatek.com>
	 <63c24cda9e007ef2128e9350b6a6ed3bc61f3a85.camel@mediatek.com>
Message-ID: <e21a66b279fd780e4d23f3f58f0b1108e6cda2b7.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Tue, 2023-12-26 at 05:43 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> > To add secure flow support for mediatek-drm, each crtc have to
> > create a secure cmdq mailbox channel. Then cmdq packets with
> > display HW configuration will be sent to secure cmdq mailbox
> > channel
> > and configured in the secure world.
> > 
> > Each crtc have to use secure cmdq interface to configure some
> > secure
> > settings for display HW before sending cmdq packets to secure cmdq
> > mailbox channel.
> > 
> > If any of fb get from current drm_atomic_state is secure, then crtc
> > will switch to the secure flow to configure display HW.
> > If all fbs are not secure in current drm_atomic_state, then crtc
> > will
> > switch to the normal flow.
> > 
> > TODO:
> > 1. Remove get sec larb port interface in ddp_comp, ovl and
> > ovl_adaptor.
> > 2. Verify instruction for enabling/disabling dapc and larb port in
> > TEE
> >    drop the sec_engine flags in normal world.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > 
> 
> [snip]
> 
> > @@ -1091,14 +1292,63 @@ int mtk_drm_crtc_create(struct drm_device
> > *drm_dev,
> >  			if (ret) {
> >  				dev_dbg(dev, "mtk_crtc %d failed to
> > create cmdq packet\n",
> >  					drm_crtc_index(&mtk_crtc-
> > > base));
> > 
> > -				mbox_free_channel(mtk_crtc-
> > > cmdq_client.chan);
> > 
> > -				mtk_crtc->cmdq_client.chan = NULL;
> > +				goto cmdq_err;
> >  			}
> >  		}
> >  
> >  		/* for sending blocking cmd in crtc disable */
> >  		init_waitqueue_head(&mtk_crtc->cb_blocking_queue);
> >  	}
> > +
> > +	mtk_crtc->sec_cmdq_client.client.dev = mtk_crtc->mmsys_dev;
> > +	mtk_crtc->sec_cmdq_client.client.tx_block = false;
> > +	mtk_crtc->sec_cmdq_client.client.knows_txdone = true;
> > +	mtk_crtc->sec_cmdq_client.client.rx_callback = ddp_cmdq_cb;
> > +	mtk_crtc->sec_cmdq_client.chan =
> > +			mbox_request_channel(&mtk_crtc-
> > > sec_cmdq_client.client, i + 1);
> > 
> > +	if (IS_ERR(mtk_crtc->sec_cmdq_client.chan)) {
> > +		dev_err(dev, "mtk_crtc %d failed to create sec mailbox
> > client\n",
> > +			drm_crtc_index(&mtk_crtc->base));
> > +		mtk_crtc->sec_cmdq_client.chan = NULL;
> > +	}
> > +
> > +	if (mtk_crtc->sec_cmdq_client.chan) {
> 
> I would like use secure channel to replace normal channel. It means
> that no extra channel is required and change the original normal
> channel to secure channel. The secure channel could process both
> normal
> buffer and secure buffer, so you need not to switch the channel.
> 
> Regards,
> CK

It sounds quite reasonable!

If the platform or project support OPTEE, we can default use secure
channel to handle both normal and secure buffers. 
I will try to to refine this and make sure it won't cause latency issue
on OPTEE transaction frequently.

Regards,
Jason-JH.Lin

From Jason-JH.Lin at mediatek.com  Tue Dec 26 23:16:31 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 07:16:31 +0000
Subject: [PATCH v3 07/11] drm/mediatek: Add secure layer config support
 for ovl
In-Reply-To: <eb8fa56d4dfa78f84d32fd7c9e271186d13f4ade.camel@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
	 <20231223182932.27683-8-jason-jh.lin@mediatek.com>
	 <eb8fa56d4dfa78f84d32fd7c9e271186d13f4ade.camel@mediatek.com>
Message-ID: <47c5d0e4e74fb0be651035227f0067e6b308b591.camel@mediatek.com>

Hi CK,

Thanks for the review.

On Tue, 2023-12-26 at 05:14 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> > Add secure layer config support for ovl.
> > 
> > TODO:
> > 1. Move DISP_REG_OVL_SECURE setting to secure world.
> > 2. Change the parameter register address in mtk_ddp_sec_write()
> >    from "u32 addr" to "struct cmdq_client_reg *cmdq_reg".
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_disp_drv.h     |  2 ++
> >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c     | 31
> > +++++++++++++++++++--
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 29
> > +++++++++++++++++++
> >  3 files changed, 60 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > index 1311562d25cc..77054adcd9cf 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > @@ -9,6 +9,7 @@
> >  #include <linux/soc/mediatek/mtk-cmdq.h>
> >  #include <linux/soc/mediatek/mtk-mmsys.h>
> >  #include <linux/soc/mediatek/mtk-mutex.h>
> > +#include "mtk_drm_ddp_comp.h"
> >  #include "mtk_drm_plane.h"
> >  #include "mtk_mdp_rdma.h"
> >  
> > @@ -82,6 +83,7 @@ void mtk_ovl_clk_disable(struct device *dev);
> >  void mtk_ovl_config(struct device *dev, unsigned int w,
> >  		    unsigned int h, unsigned int vrefresh,
> >  		    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> > +u64 mtk_ovl_get_sec_port(struct mtk_ddp_comp *comp, unsigned int
> > idx);
> >  int mtk_ovl_layer_check(struct device *dev, unsigned int idx,
> >  			struct mtk_plane_state *mtk_state);
> >  void mtk_ovl_layer_config(struct device *dev, unsigned int idx,
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 2bffe4245466..c18f76412a2e 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -46,6 +46,7 @@
> >  #define DISP_REG_OVL_ADDR(ovl, n)		((ovl)->data->addr +
> > 0x20 * (n))
> >  #define DISP_REG_OVL_HDR_ADDR(ovl, n)		((ovl)->data-
> > > addr + 0x20 * (n) + 0x04)
> > 
> >  #define DISP_REG_OVL_HDR_PITCH(ovl, n)		((ovl)->data-
> > > addr + 0x20 * (n) + 0x08)
> > 
> > +#define DISP_REG_OVL_SECURE			0x0fc0
> >  
> >  #define GMC_THRESHOLD_BITS	16
> >  #define GMC_THRESHOLD_HIGH	((1 << GMC_THRESHOLD_BITS) / 4)
> > @@ -126,8 +127,19 @@ struct mtk_disp_ovl {
> >  	const struct mtk_disp_ovl_data	*data;
> >  	void				(*vblank_cb)(void *data);
> >  	void				*vblank_cb_data;
> > +	resource_size_t			regs_pa;
> >  };
> >  
> > +u64 mtk_ovl_get_sec_port(struct mtk_ddp_comp *comp, unsigned int
> > idx)
> > +{
> > +	if (comp->id == DDP_COMPONENT_OVL0)
> > +		return BIT_ULL(CMDQ_SEC_DISP_OVL0);
> > +	else if (comp->id == DDP_COMPONENT_OVL1)
> > +		return BIT_ULL(CMDQ_SEC_DISP_OVL1);
> > +
> > +	return 0;
> > +}
> > +
> >  static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
> >  {
> >  	struct mtk_disp_ovl *priv = dev_id;
> > @@ -449,8 +461,22 @@ void mtk_ovl_layer_config(struct device *dev,
> > unsigned int idx,
> >  			      DISP_REG_OVL_SRC_SIZE(idx));
> >  	mtk_ddp_write_relaxed(cmdq_pkt, offset, &ovl->cmdq_reg, ovl-
> > > regs,
> > 
> >  			      DISP_REG_OVL_OFFSET(idx));
> > -	mtk_ddp_write_relaxed(cmdq_pkt, addr, &ovl->cmdq_reg, ovl-
> > > regs,
> > 
> > -			      DISP_REG_OVL_ADDR(ovl, idx));
> > +
> > +	if (state->pending.is_secure) {
> > +		const struct drm_format_info *fmt_info =
> > drm_format_info(fmt);
> > +		unsigned int buf_size = (pending->height - 1) *
> > pending->pitch +
> > +					pending->width * fmt_info-
> > > cpp[0];
> > 
> > +
> > +		mtk_ddp_write_mask(cmdq_pkt, BIT(idx), &ovl->cmdq_reg,
> > ovl->regs,
> > +				   DISP_REG_OVL_SECURE, BIT(idx));
> > +		mtk_ddp_sec_write(cmdq_pkt, ovl->regs_pa +
> > DISP_REG_OVL_ADDR(ovl, idx),
> > +				  pending->addr, CMDQ_IWC_H_2_MVA, 0,
> > buf_size, 0);
> 
> Mapping iova should be done when buffer allocation or some other
> mapping function, instead of every OVL frame configuration. So the
> size
> should not be set here.
> 
> Regards,
> CK
> 

Since we can only get the secure handle when the plane updates, the
buffer have to be mapped here every time.
So I'll ask IOMMU owner to move this mapping process into allocation
step, then we can remove the size here.

Regards,
Jason-JH.Lin

From Jason-JH.Lin at mediatek.com  Tue Dec 26 23:20:44 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 07:20:44 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <c179d1ab68298efd314ffbe39fc67c5bb2dc5764.camel@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
	 <c179d1ab68298efd314ffbe39fc67c5bb2dc5764.camel@mediatek.com>
Message-ID: <7204d5a3192a37edc2d44e3ddce67a2fc50d0206.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Tue, 2023-12-26 at 09:18 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> > To support secure video path feature, GCE have to read/write
> > registgers
> > in the secure world. GCE will enable the secure access permission
> > to
> > the
> > HW who wants to access the secure content buffer.
> > 
> > Add CMDQ secure mailbox driver to make CMDQ client user is able to
> > sending their HW settings to the secure world. So that GCE can
> > execute
> > all instructions to configure HW in the secure world.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> 
> [snip]
> 
> > +
> > +/**
> > + * struct iwc_cmdq_command_t - structure for excuting cmdq task in
> > secure world.
> > + * @thread: GCE secure thread index to execute command.
> > + * @scenario: scenario to execute command.
> > + * @priority: priority of GCE secure thread.
> > + * @cmd_size: command size used in command buffer.
> > + * @eng_flag: HW engine flag need to enable protection
> > configuration.
> > + * @va_base: command buffer
> > + * @wait_cookie: index in thread's task list, it should be
> > (nextCookie - 1).
> > + * @reset_exec: reset HW thread.
> > + * @caller_pid: pid of client module.
> > + * @caller_name: name of client module.
> > + * @metadata: metadata structure for converting a list of secure
> > buffer address.
> > + * @extension: extension HW engine flag to be protcted in secure
> > world.
> > + * @readback_pa: readback buffer pa.
> > + * @normal_task_handle: handle to reference task in normal world.
> > + * @mdp_extension: extension MDP HW engine flag to be protcted in
> > secure world.
> > + * @readback_engs: array of readback engines parameters.
> > + * @readback_cnt: count of readback_engs array.
> > + */
> > +struct iwc_cmdq_command_t {
> > +	/* basic execution data */
> > +	u32 thread;
> > +	u32 scenario;
> > +	u32 priority;
> > +	u32 cmd_size;
> > +	u64 eng_flag;
> > +	u32 va_base[CMDQ_IWC_MAX_CMD_LENGTH];
> > +
> > +	/* exec order data */
> > +	u32 wait_cookie;
> > +	bool reset_exec;
> > +
> > +	/* client info */
> > +	s32 caller_pid;
> 
> Useless, drop it.
> 
> > +	char caller_name[CMDQ_IWC_CLIENT_NAME];
> 
> Ditto.
> 
> > +
> > +	/* metadata */
> > +	struct iwc_cmdq_metadata_t metadata;
> > +
> > +	/* client extension bits */
> > +	u64 extension;
> 
> Ditto.
> 
> > +	u64 readback_pa;
> 
> Ditto.
> 
> > +
> > +	/* debug */
> > +	u64 normal_task_handle;
> > +
> > +	/* SVP HDR */
> > +	u32 mdp_extension;
> 
> Ditto.
> 
> > +	struct readback_engine readback_engs[CMDQ_MAX_READBACK_ENG];
> 
> Ditto.
> 
> > +	u32 readback_cnt;
> 
> Ditto.
> 
> Regards,
> CK
> 

OK, I'll drop them.

Regards,
Jason-JH.Lin

> > +};
> > +

From Jason-JH.Lin at mediatek.com  Tue Dec 26 23:26:10 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 07:26:10 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <a0c9d84f8a2d6efdfd7502f796e5629a8471c9eb.camel@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
	 <a0c9d84f8a2d6efdfd7502f796e5629a8471c9eb.camel@mediatek.com>
Message-ID: <4f2cf25c730e59784afa5ce690cf4cc99544025f.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Tue, 2023-12-26 at 08:28 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> > To support secure video path feature, GCE have to read/write
> > registgers
> > in the secure world. GCE will enable the secure access permission
> > to
> > the
> > HW who wants to access the secure content buffer.
> > 
> > Add CMDQ secure mailbox driver to make CMDQ client user is able to
> > sending their HW settings to the secure world. So that GCE can
> > execute
> > all instructions to configure HW in the secure world.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> 
> [snip]
> 
> > +
> > +int cmdq_sec_pkt_write(struct cmdq_pkt *pkt, u32 addr, u64 base,
> > +		       const enum cmdq_iwc_addr_metadata_type type,
> > +		       const u32 offset, const u32 size, const u32
> > port)
> > +{
> > +	int ret;
> > +
> > +	ret = cmdq_pkt_assign(pkt, CMDQ_THR_SPR_IDX0, addr);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = cmdq_pkt_write_s_reg_value(pkt, CMDQ_THR_SPR_IDX0,
> > (u32)base);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return cmdq_sec_append_metadata(pkt, type, base, offset, size,
> > port);
> 
> Why do you append this metadata? It looks like TEE would use this
> meta
> data to check command is secure or not. But this meta data is in
> normal
> world, so it may be modified by hacker. I think TEE should check
> command buffer directly not by the meta data.
> 
> Regards,
> CK
> 

OK, I'll try to remove this.

Regards,
Jason-JH.Lin

> > +}
> > +EXPORT_SYMBOL_GPL(cmdq_sec_pkt_write);
> > +

From Jason-JH.Lin at mediatek.com  Tue Dec 26 23:25:02 2023
From: Jason-JH.Lin at mediatek.com (=?utf-8?B?SmFzb24tSkggTGluICjmnpfnnb/npaUp?=)
Date: Wed, 27 Dec 2023 07:25:02 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <f338215fb8f7ff1e0ebeb0f1e21a8b4dec5f0c61.camel@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
	 <f338215fb8f7ff1e0ebeb0f1e21a8b4dec5f0c61.camel@mediatek.com>
Message-ID: <83db5f669a6404ba3bf65ecd7b024af2509c19dc.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Tue, 2023-12-26 at 08:58 +0000, CK Hu (???) wrote:
> Hi, Jason:
> 
> On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> > To support secure video path feature, GCE have to read/write
> > registgers
> > in the secure world. GCE will enable the secure access permission
> > to
> > the
> > HW who wants to access the secure content buffer.
> > 
> > Add CMDQ secure mailbox driver to make CMDQ client user is able to
> > sending their HW settings to the secure world. So that GCE can
> > execute
> > all instructions to configure HW in the secure world.
> > 
> > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > ---
> 
> [snip]
> 
> > +
> > +static int cmdq_sec_fill_iwc_msg(struct cmdq_sec_context *context,
> > +				 struct cmdq_sec_task *sec_task, u32
> > thrd_idx)
> > +{
> > +	struct iwc_cmdq_message_t *iwc_msg = NULL;
> > +	struct cmdq_sec_data *data = (struct cmdq_sec_data *)sec_task-
> > > task.pkt->sec_data;
> > 
> > +	u32 size = 0, offset = 0, *instr;
> > +
> > +	iwc_msg = (struct iwc_cmdq_message_t *)context->iwc_msg;
> > +
> > +	if (sec_task->task.pkt->cmd_buf_size + 4 * CMDQ_INST_SIZE >
> > CMDQ_TZ_CMD_BLOCK_SIZE) {
> > +		pr_err("sec_task:%p size:%zu > %u",
> > +		       sec_task, sec_task->task.pkt->cmd_buf_size,
> > CMDQ_TZ_CMD_BLOCK_SIZE);
> > +		return -EFAULT;
> > +	}
> > +
> > +	if (thrd_idx == CMDQ_INVALID_THREAD) {
> > +		iwc_msg->command.cmd_size = 0;
> > +		iwc_msg->command.metadata.addr_list_length = 0;
> > +		return -EINVAL;
> > +	}
> > +
> > +	iwc_msg->command.thread = thrd_idx;
> > +	iwc_msg->command.scenario = sec_task->scenario;
> > +	iwc_msg->command.eng_flag = sec_task->engine_flag;
> > +	size = sec_task->task.pkt->cmd_buf_size;
> > +	memcpy(iwc_msg->command.va_base + offset, sec_task->task.pkt-
> > > va_base, size);
> 
> I think it's not necessary to copy from normal command buffer to
> normal
> command buffer. Just
> 
> iwc_msg->command.va_base = sec_task->task.pkt->va_base;
> 
> You have a secure command buffer for secure gce to execute command.
> If
> you want to modify command buffer, copy from normal command buffer to
> secure command buffer, and modify the secure command buffer.
> 
> Regards,
> CK
> 
> 

I think secure world won't recognize normal world's va, so we nee to
copy to iwc_msg->command.va_base, which is a world share memory first.

Regards,
Jason-JH.Lin

From figure1802 at 126.com  Tue Dec 26 23:49:15 2023
From: figure1802 at 126.com (Ben)
Date: Wed, 27 Dec 2023 15:49:15 +0800 (CST)
Subject: Fw:how test the Translation Support for SMMUv3?
Message-ID: <f4ebb6e.40d3.18caa3fc75c.Coremail.figure1802@126.com>


Hi Nicolin,

I saw your pachset on https://lwn.net/Articles/931502/?, i have built the kernel and qemu you provided in cover letter.
I run a QEMU system as Host, and launch a VM by kvmtool. But i cannot find a IOMMU on VM, how do you test your patchset? would you like provide your steps?


BTW, I add a printk on?arm_smmu_device_hw_probe() to print out the?smmu->features , it looks your QEMU still only support?ARM_SMMU_FEAT_TRANS_S1.


Does it provide a vIOMMU of SMMUv3 for your kernel and qemu patchset?


Best
Ben

From ansuelsmth at gmail.com  Wed Dec 27 01:02:26 2023
From: ansuelsmth at gmail.com (Christian Marangi)
Date: Wed, 27 Dec 2023 10:02:26 +0100
Subject: [net-next PATCH v5 0/5] net: phy: generic polarity + LED support for qca808x
Message-ID: <20231227090231.4246-1-ansuelsmth@gmail.com>

This small series add LEDs support for qca808x.

QCA808x apply on PHY reset a strange polarity settings and require
some tweak to apply a more common configuration found on devices.
On adding support for it, it was pointed out that a similar
feature is also being implemented for a marvell PHY where
LED polarity is set per LED (and not global) and also have
a special mode where the LED is tristated.

The first 3 patch are to generalize this as we expect more PHY
in the future to have a similar configuration.

The implementation is extensible to support additional special
mode in the future with minimal changes and don't create regression
on already implemented PHY drivers.

(changelog present in single patch)

Christian Marangi (5):
  dt-bindings: net: phy: Make LED active-low property common
  dt-bindings: net: phy: Document LED inactive high impedance mode
  net: phy: add support for PHY LEDs polarity modes
  dt-bindings: net: Document QCA808x PHYs
  net: phy: at803x: add LED support for qca808x

 .../devicetree/bindings/leds/common.yaml      |  12 +
 .../bindings/leds/leds-bcm63138.yaml          |   4 -
 .../bindings/leds/leds-bcm6328.yaml           |   4 -
 .../devicetree/bindings/leds/leds-bcm6358.txt |   2 -
 .../bindings/leds/leds-pwm-multicolor.yaml    |   4 -
 .../devicetree/bindings/leds/leds-pwm.yaml    |   5 -
 .../devicetree/bindings/net/qca,qca808x.yaml  |  54 +++
 drivers/net/phy/at803x.c                      | 333 ++++++++++++++++++
 drivers/net/phy/phy_device.c                  |  12 +
 include/linux/phy.h                           |  22 ++
 10 files changed, 433 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/qca,qca808x.yaml

-- 
2.40.1



From ansuelsmth at gmail.com  Wed Dec 27 01:02:27 2023
From: ansuelsmth at gmail.com (Christian Marangi)
Date: Wed, 27 Dec 2023 10:02:27 +0100
Subject: [net-next PATCH v5 1/5] dt-bindings: net: phy: Make LED active-low property common
In-Reply-To: <20231227090231.4246-1-ansuelsmth@gmail.com>
References: <20231227090231.4246-1-ansuelsmth@gmail.com>
Message-ID: <20231227090231.4246-2-ansuelsmth@gmail.com>

Move LED active-low property to common.yaml. This property is currently
defined multiple times by bcm LEDs. This property will now be supported
in a generic way for PHY LEDs with the use of a generic function.

With active-low bool property not defined, active-high is always
assumed.

Signed-off-by: Christian Marangi <ansuelsmth at gmail.com>
---
Changes v5:
- Make active-low generic
Changes v4:
- Drop support for global active-low
- Rework to polarity option (for marvell10g series support)
Changes v3:
- Out of RFC
Changes v2:
- Add this patch

 Documentation/devicetree/bindings/leds/common.yaml          | 6 ++++++
 Documentation/devicetree/bindings/leds/leds-bcm63138.yaml   | 4 ----
 Documentation/devicetree/bindings/leds/leds-bcm6328.yaml    | 4 ----
 Documentation/devicetree/bindings/leds/leds-bcm6358.txt     | 2 --
 .../devicetree/bindings/leds/leds-pwm-multicolor.yaml       | 4 ----
 Documentation/devicetree/bindings/leds/leds-pwm.yaml        | 5 -----
 6 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index c8d0ba5f2327..f5b40df6b421 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -200,6 +200,12 @@ properties:
       #trigger-source-cells property in the source node.
     $ref: /schemas/types.yaml#/definitions/phandle-array
 
+  active-low:
+    type: boolean
+    description:
+      Makes LED active low. To turn the LED ON, line needs to be
+      set to low voltage instead of high.
+
   # Required properties for flash LED child nodes:
   flash-max-microamp:
     description:
diff --git a/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml
index 52252fb6bb32..bb20394fca5c 100644
--- a/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml
@@ -52,10 +52,6 @@ patternProperties:
         maxItems: 1
         description: LED pin number
 
-      active-low:
-        type: boolean
-        description: Makes LED active low
-
     required:
       - reg
 
diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml b/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml
index 51cc0d82c12e..f3a3ef992929 100644
--- a/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml
@@ -78,10 +78,6 @@ patternProperties:
           - maximum: 23
         description: LED pin number (only LEDs 0 to 23 are valid).
 
-      active-low:
-        type: boolean
-        description: Makes LED active low.
-
       brcm,hardware-controlled:
         type: boolean
         description: Makes this LED hardware controlled.
diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6358.txt b/Documentation/devicetree/bindings/leds/leds-bcm6358.txt
index 6e51c6b91ee5..211ffc3c4a20 100644
--- a/Documentation/devicetree/bindings/leds/leds-bcm6358.txt
+++ b/Documentation/devicetree/bindings/leds/leds-bcm6358.txt
@@ -25,8 +25,6 @@ LED sub-node required properties:
 
 LED sub-node optional properties:
   - label : see Documentation/devicetree/bindings/leds/common.txt
-  - active-low : Boolean, makes LED active low.
-    Default : false
   - default-state : see
     Documentation/devicetree/bindings/leds/common.txt
   - linux,default-trigger : see
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
index bd6ec04a8727..5edfbe347341 100644
--- a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
@@ -41,10 +41,6 @@ properties:
 
           pwm-names: true
 
-          active-low:
-            description: For PWMs where the LED is wired to supply rather than ground.
-            type: boolean
-
           color: true
 
         required:
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.yaml b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
index 7de6da58be3c..113b7c218303 100644
--- a/Documentation/devicetree/bindings/leds/leds-pwm.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
@@ -34,11 +34,6 @@ patternProperties:
           Maximum brightness possible for the LED
         $ref: /schemas/types.yaml#/definitions/uint32
 
-      active-low:
-        description:
-          For PWMs where the LED is wired to supply rather than ground.
-        type: boolean
-
     required:
       - pwms
       - max-brightness
-- 
2.40.1



From ansuelsmth at gmail.com  Wed Dec 27 01:02:28 2023
From: ansuelsmth at gmail.com (Christian Marangi)
Date: Wed, 27 Dec 2023 10:02:28 +0100
Subject: [net-next PATCH v5 2/5] dt-bindings: net: phy: Document LED inactive high impedance mode
In-Reply-To: <20231227090231.4246-1-ansuelsmth@gmail.com>
References: <20231227090231.4246-1-ansuelsmth@gmail.com>
Message-ID: <20231227090231.4246-3-ansuelsmth@gmail.com>

Document LED inactive high impedance mode to set the LED to require high
impedance configuration to be turned OFF.

Signed-off-by: Christian Marangi <ansuelsmth at gmail.com>
---
Changes v5:
- Add this patch

 Documentation/devicetree/bindings/leds/common.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index f5b40df6b421..9e7b4aabe0bb 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -206,6 +206,12 @@ properties:
       Makes LED active low. To turn the LED ON, line needs to be
       set to low voltage instead of high.
 
+  inactive-high-impedance:
+    type: boolean
+    description:
+      Set LED to high-impedance mode to turn the LED OFF. LED might also
+      describe this mode as tristate.
+
   # Required properties for flash LED child nodes:
   flash-max-microamp:
     description:
-- 
2.40.1



From ansuelsmth at gmail.com  Wed Dec 27 01:02:29 2023
From: ansuelsmth at gmail.com (Christian Marangi)
Date: Wed, 27 Dec 2023 10:02:29 +0100
Subject: [net-next PATCH v5 3/5] net: phy: add support for PHY LEDs polarity modes
In-Reply-To: <20231227090231.4246-1-ansuelsmth@gmail.com>
References: <20231227090231.4246-1-ansuelsmth@gmail.com>
Message-ID: <20231227090231.4246-4-ansuelsmth@gmail.com>

Add support for PHY LEDs polarity modes. Some PHY require LED to be set
to active low to be turned ON. Adds support for this by declaring
active-low property in DT.

PHY driver needs to declare .led_polarity_set() to configure LED
polarity modes. Function will pass the index with the LED index and a
bitmap with all the required modes to set.

Current supported modes are:
- active-low with the flag PHY_LED_ACTIVE_LOW. LED is set to active-low
  to turn it ON.
- inactive-high-impedance with the flag PHY_LED_INACTIVE_HIGH_IMPEDANCE.
  LED is set to high impedance to turn it OFF.

Signed-off-by: Christian Marangi <ansuelsmth at gmail.com>
---
Changes v5:
- Rework to LED modes bitmap
Changes v4:
- Drop for global active-low
- Rework to polarity option (for marvell10g series support)
Changes v3:
- Out of RFC
Changes v2:
- Add this patch

 drivers/net/phy/phy_device.c | 12 ++++++++++++
 include/linux/phy.h          | 22 ++++++++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 3611ea64875e..b99c7579d9c4 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -3097,6 +3097,7 @@ static int of_phy_led(struct phy_device *phydev,
 	struct device *dev = &phydev->mdio.dev;
 	struct led_init_data init_data = {};
 	struct led_classdev *cdev;
+	unsigned long modes = 0;
 	struct phy_led *phyled;
 	u32 index;
 	int err;
@@ -3114,6 +3115,17 @@ static int of_phy_led(struct phy_device *phydev,
 	if (index > U8_MAX)
 		return -EINVAL;
 
+	if (phydev->drv->led_polarity_set) {
+		if (of_property_read_bool(led, "active-low"))
+			set_bit(PHY_LED_ACTIVE_LOW, &modes);
+		if (of_property_read_bool(led, "inactive-high-impedance"))
+			set_bit(PHY_LED_INACTIVE_HIGH_IMPEDANCE, &modes);
+
+		err = phydev->drv->led_polarity_set(phydev, index, modes);
+		if (err)
+			return err;
+	}
+
 	phyled->index = index;
 	if (phydev->drv->led_brightness_set)
 		cdev->brightness_set_blocking = phy_led_set_brightness;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index e9e85d347587..5ac54f9eee82 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -853,6 +853,15 @@ struct phy_plca_status {
 	bool pst;
 };
 
+/* Modes for PHY LED configuration */
+enum phy_led_modes {
+	PHY_LED_ACTIVE_LOW = 0,
+	PHY_LED_INACTIVE_HIGH_IMPEDANCE = 1,
+
+	/* keep it last */
+	__PHY_LED_MODES_NUM,
+};
+
 /**
  * struct phy_led: An LED driven by the PHY
  *
@@ -1146,6 +1155,19 @@ struct phy_driver {
 	int (*led_hw_control_get)(struct phy_device *dev, u8 index,
 				  unsigned long *rules);
 
+	/**
+	 * @led_polarity_set: Set the LED polarity if active low
+	 * @dev: PHY device which has the LED
+	 * @index: Which LED of the PHY device or -1
+	 * @modes: bitmap of LED polarity modes
+	 *
+	 * Configure LED with all the required polarity modes in @modes
+	 * to make it correctly turn ON or OFF.
+	 *
+	 * Returns 0, or an error code.
+	 */
+	int (*led_polarity_set)(struct phy_device *dev, int index,
+				unsigned long modes);
 };
 #define to_phy_driver(d) container_of(to_mdio_common_driver(d),		\
 				      struct phy_driver, mdiodrv)
-- 
2.40.1



From ansuelsmth at gmail.com  Wed Dec 27 01:02:30 2023
From: ansuelsmth at gmail.com (Christian Marangi)
Date: Wed, 27 Dec 2023 10:02:30 +0100
Subject: [net-next PATCH v5 4/5] dt-bindings: net: Document QCA808x PHYs
In-Reply-To: <20231227090231.4246-1-ansuelsmth@gmail.com>
References: <20231227090231.4246-1-ansuelsmth@gmail.com>
Message-ID: <20231227090231.4246-5-ansuelsmth@gmail.com>

Add Documentation for QCA808x PHYs for the additional LED configuration
for this PHY.

Signed-off-by: Christian Marangi <ansuelsmth at gmail.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
Changes v4:
- Add Reviewed-by tag
Changes v3:
- Use compatible instead of select
- Out of RFC
Changes v2:
- Fix License warning from checkpatch
- Drop redundant Description phrase
- Improve commit tile
- Drop special property (generalized)

 .../devicetree/bindings/net/qca,qca808x.yaml  | 54 +++++++++++++++++++
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/qca,qca808x.yaml

diff --git a/Documentation/devicetree/bindings/net/qca,qca808x.yaml b/Documentation/devicetree/bindings/net/qca,qca808x.yaml
new file mode 100644
index 000000000000..e2552655902a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qca,qca808x.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/qca,qca808x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Atheros QCA808X PHY
+
+maintainers:
+  - Christian Marangi <ansuelsmth at gmail.com>
+
+description:
+  QCA808X PHYs can have up to 3 LEDs attached.
+  All 3 LEDs are disabled by default.
+  2 LEDs have dedicated pins with the 3rd LED having the
+  double function of Interrupt LEDs/GPIO or additional LED.
+
+  By default this special PIN is set to LED function.
+
+allOf:
+  - $ref: ethernet-phy.yaml#
+
+properties:
+  compatible:
+    enum:
+      - ethernet-phy-id004d.d101
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/leds/common.h>
+
+    mdio {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        ethernet-phy at 0 {
+            compatible = "ethernet-phy-id004d.d101";
+            reg = <0>;
+
+            leds {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                led at 0 {
+                    reg = <0>;
+                    color = <LED_COLOR_ID_GREEN>;
+                    function = LED_FUNCTION_WAN;
+                    default-state = "keep";
+                };
+            };
+        };
+    };
-- 
2.40.1



From ansuelsmth at gmail.com  Wed Dec 27 01:02:31 2023
From: ansuelsmth at gmail.com (Christian Marangi)
Date: Wed, 27 Dec 2023 10:02:31 +0100
Subject: [net-next PATCH v5 5/5] net: phy: at803x: add LED support for qca808x
In-Reply-To: <20231227090231.4246-1-ansuelsmth@gmail.com>
References: <20231227090231.4246-1-ansuelsmth@gmail.com>
Message-ID: <20231227090231.4246-6-ansuelsmth@gmail.com>

Add LED support for QCA8081 PHY.

Documentation for this LEDs PHY is very scarce even with NDA access
to Documentation for OEMs. Only the blink pattern are documented and are
very confusing most of the time. No documentation is present about
forcing the LED on/off or to always blink.

Those settings were reversed by poking the regs and trying to find the
correct bits to trigger these modes. Some bits mode are not clear and
maybe the documentation option are not 100% correct. For the sake of LED
support the reversed option are enough to add support for current LED
APIs.

Supported HW control modes are:
- tx
- rx
- link10
- link100
- link1000
- half_duplex
- full_duplex

Also add support for LED polarity set to set LED polarity to active
high or low. QSDK sets this value to high by default but PHY reset value
doesn't have this enabled by default.

QSDK also sets 2 additional bits but their usage is not clear, info about
this is added in the header. It was verified that for correct function
of the LED if active high is needed, only BIT 6 is needed.

Signed-off-by: Christian Marangi <ansuelsmth at gmail.com>
---
Changes v5:
- Rework to polarity option bitmap
- Rafactor with new finding from further reverse
Changes v4:
- Rework to polarity option (for marvell10g series support)
- Rework logic to enforce single PHY polarity mode
Changes v3:
- Out of RFC
- Drop link_25000 and add TODO commends waiting for the
  netdev trigger thing to be merged (I will take care of
  sending a followup patch later)
Changes v2:
- Move to new led_polarity_set implementation
- Drop special probe

 drivers/net/phy/at803x.c | 333 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 333 insertions(+)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index d5dc927618ab..bc9a219fd499 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -272,6 +272,87 @@
 #define QCA808X_CDT_STATUS_STAT_OPEN		2
 #define QCA808X_CDT_STATUS_STAT_SHORT		3
 
+#define QCA808X_MMD7_LED_GLOBAL			0x8073
+#define QCA808X_LED_BLINK_1			GENMASK(11, 6)
+#define QCA808X_LED_BLINK_2			GENMASK(5, 0)
+/* Values are the same for both BLINK_1 and BLINK_2 */
+#define QCA808X_LED_BLINK_FREQ_MASK		GENMASK(5, 3)
+#define QCA808X_LED_BLINK_FREQ_2HZ		FIELD_PREP(QCA808X_LED_BLINK_FREQ_MASK, 0x0)
+#define QCA808X_LED_BLINK_FREQ_4HZ		FIELD_PREP(QCA808X_LED_BLINK_FREQ_MASK, 0x1)
+#define QCA808X_LED_BLINK_FREQ_8HZ		FIELD_PREP(QCA808X_LED_BLINK_FREQ_MASK, 0x2)
+#define QCA808X_LED_BLINK_FREQ_16HZ		FIELD_PREP(QCA808X_LED_BLINK_FREQ_MASK, 0x3)
+#define QCA808X_LED_BLINK_FREQ_32HZ		FIELD_PREP(QCA808X_LED_BLINK_FREQ_MASK, 0x4)
+#define QCA808X_LED_BLINK_FREQ_64HZ		FIELD_PREP(QCA808X_LED_BLINK_FREQ_MASK, 0x5)
+#define QCA808X_LED_BLINK_FREQ_128HZ		FIELD_PREP(QCA808X_LED_BLINK_FREQ_MASK, 0x6)
+#define QCA808X_LED_BLINK_FREQ_256HZ		FIELD_PREP(QCA808X_LED_BLINK_FREQ_MASK, 0x7)
+#define QCA808X_LED_BLINK_DUTY_MASK		GENMASK(2, 0)
+#define QCA808X_LED_BLINK_DUTY_50_50		FIELD_PREP(QCA808X_LED_BLINK_DUTY_MASK, 0x0)
+#define QCA808X_LED_BLINK_DUTY_75_25		FIELD_PREP(QCA808X_LED_BLINK_DUTY_MASK, 0x1)
+#define QCA808X_LED_BLINK_DUTY_25_75		FIELD_PREP(QCA808X_LED_BLINK_DUTY_MASK, 0x2)
+#define QCA808X_LED_BLINK_DUTY_33_67		FIELD_PREP(QCA808X_LED_BLINK_DUTY_MASK, 0x3)
+#define QCA808X_LED_BLINK_DUTY_67_33		FIELD_PREP(QCA808X_LED_BLINK_DUTY_MASK, 0x4)
+#define QCA808X_LED_BLINK_DUTY_17_83		FIELD_PREP(QCA808X_LED_BLINK_DUTY_MASK, 0x5)
+#define QCA808X_LED_BLINK_DUTY_83_17		FIELD_PREP(QCA808X_LED_BLINK_DUTY_MASK, 0x6)
+#define QCA808X_LED_BLINK_DUTY_8_92		FIELD_PREP(QCA808X_LED_BLINK_DUTY_MASK, 0x7)
+
+#define QCA808X_MMD7_LED2_CTRL			0x8074
+#define QCA808X_MMD7_LED2_FORCE_CTRL		0x8075
+#define QCA808X_MMD7_LED1_CTRL			0x8076
+#define QCA808X_MMD7_LED1_FORCE_CTRL		0x8077
+#define QCA808X_MMD7_LED0_CTRL			0x8078
+#define QCA808X_MMD7_LED_CTRL(x)		(0x8078 - ((x) * 2))
+
+/* LED hw control pattern is the same for every LED */
+#define QCA808X_LED_PATTERN_MASK		GENMASK(15, 0)
+#define QCA808X_LED_SPEED2500_ON		BIT(15)
+#define QCA808X_LED_SPEED2500_BLINK		BIT(14)
+/* Follow blink trigger even if duplex or speed condition doesn't match */
+#define QCA808X_LED_BLINK_CHECK_BYPASS		BIT(13)
+#define QCA808X_LED_FULL_DUPLEX_ON		BIT(12)
+#define QCA808X_LED_HALF_DUPLEX_ON		BIT(11)
+#define QCA808X_LED_TX_BLINK			BIT(10)
+#define QCA808X_LED_RX_BLINK			BIT(9)
+#define QCA808X_LED_TX_ON_10MS			BIT(8)
+#define QCA808X_LED_RX_ON_10MS			BIT(7)
+#define QCA808X_LED_SPEED1000_ON		BIT(6)
+#define QCA808X_LED_SPEED100_ON			BIT(5)
+#define QCA808X_LED_SPEED10_ON			BIT(4)
+#define QCA808X_LED_COLLISION_BLINK		BIT(3)
+#define QCA808X_LED_SPEED1000_BLINK		BIT(2)
+#define QCA808X_LED_SPEED100_BLINK		BIT(1)
+#define QCA808X_LED_SPEED10_BLINK		BIT(0)
+
+#define QCA808X_MMD7_LED0_FORCE_CTRL		0x8079
+#define QCA808X_MMD7_LED_FORCE_CTRL(x)		(0x8079 - ((x) * 2))
+
+/* LED force ctrl is the same for every LED
+ * No documentation exist for this, not even internal one
+ * with NDA as QCOM gives only info about configuring
+ * hw control pattern rules and doesn't indicate any way
+ * to force the LED to specific mode.
+ * These define comes from reverse and testing and maybe
+ * lack of some info or some info are not entirely correct.
+ * For the basic LED control and hw control these finding
+ * are enough to support LED control in all the required APIs.
+ *
+ * On doing some comparison with implementation with qca807x,
+ * it was found that it's 1:1 equal to it and confirms all the
+ * reverse done. It was also found further specification with the
+ * force mode and the blink modes.
+ */
+#define QCA808X_LED_FORCE_EN			BIT(15)
+#define QCA808X_LED_FORCE_MODE_MASK		GENMASK(14, 13)
+#define QCA808X_LED_FORCE_BLINK_1		FIELD_PREP(QCA808X_LED_FORCE_MODE_MASK, 0x3)
+#define QCA808X_LED_FORCE_BLINK_2		FIELD_PREP(QCA808X_LED_FORCE_MODE_MASK, 0x2)
+#define QCA808X_LED_FORCE_ON			FIELD_PREP(QCA808X_LED_FORCE_MODE_MASK, 0x1)
+#define QCA808X_LED_FORCE_OFF			FIELD_PREP(QCA808X_LED_FORCE_MODE_MASK, 0x0)
+
+#define QCA808X_MMD7_LED_POLARITY_CTRL		0x901a
+/* QSDK sets by default 0x46 to this reg that sets BIT 6 for
+ * LED to active high. It's not clear what BIT 3 and BIT 4 does.
+ */
+#define QCA808X_LED_ACTIVE_HIGH			BIT(6)
+
 /* QCA808X 1G chip type */
 #define QCA808X_PHY_MMD7_CHIP_TYPE		0x901d
 #define QCA808X_PHY_CHIP_TYPE_1G		BIT(0)
@@ -317,6 +398,7 @@ struct at803x_priv {
 	struct regulator_dev *vddio_rdev;
 	struct regulator_dev *vddh_rdev;
 	u64 stats[ARRAY_SIZE(qca83xx_hw_stats)];
+	int led_polarity_mode;
 };
 
 struct at803x_context {
@@ -677,6 +759,9 @@ static int at803x_probe(struct phy_device *phydev)
 	if (!priv)
 		return -ENOMEM;
 
+	/* Init LED polarity mode to -1 */
+	priv->led_polarity_mode = -1;
+
 	phydev->priv = priv;
 
 	ret = at803x_parse_dt(phydev);
@@ -2152,6 +2237,248 @@ static void qca808x_link_change_notify(struct phy_device *phydev)
 			QCA8081_PHY_FIFO_RSTN, phydev->link ? QCA8081_PHY_FIFO_RSTN : 0);
 }
 
+static int qca808x_led_parse_netdev(struct phy_device *phydev, unsigned long rules,
+				    u16 *offload_trigger)
+{
+	/* TODO: add link_2500 when added to netdev trigger */
+	/* Parsing specific to netdev trigger */
+	if (test_bit(TRIGGER_NETDEV_TX, &rules))
+		*offload_trigger |= QCA808X_LED_TX_BLINK;
+	if (test_bit(TRIGGER_NETDEV_RX, &rules))
+		*offload_trigger |= QCA808X_LED_RX_BLINK;
+	if (test_bit(TRIGGER_NETDEV_LINK_10, &rules))
+		*offload_trigger |= QCA808X_LED_SPEED10_ON;
+	if (test_bit(TRIGGER_NETDEV_LINK_100, &rules))
+		*offload_trigger |= QCA808X_LED_SPEED100_ON;
+	if (test_bit(TRIGGER_NETDEV_LINK_1000, &rules))
+		*offload_trigger |= QCA808X_LED_SPEED1000_ON;
+	if (test_bit(TRIGGER_NETDEV_HALF_DUPLEX, &rules))
+		*offload_trigger |= QCA808X_LED_HALF_DUPLEX_ON;
+	if (test_bit(TRIGGER_NETDEV_FULL_DUPLEX, &rules))
+		*offload_trigger |= QCA808X_LED_FULL_DUPLEX_ON;
+
+	if (rules && !*offload_trigger)
+		return -EOPNOTSUPP;
+
+	/* Enable BLINK_CHECK_BYPASS by default to make the LED
+	 * blink even with duplex or speed mode not enabled.
+	 */
+	*offload_trigger |= QCA808X_LED_BLINK_CHECK_BYPASS;
+
+	return 0;
+}
+
+static int qca808x_led_hw_control_enable(struct phy_device *phydev, u8 index)
+{
+	u16 reg;
+
+	if (index > 2)
+		return -EINVAL;
+
+	reg = QCA808X_MMD7_LED_FORCE_CTRL(index);
+
+	return phy_clear_bits_mmd(phydev, MDIO_MMD_AN, reg,
+				  QCA808X_LED_FORCE_EN);
+}
+
+static int qca808x_led_hw_is_supported(struct phy_device *phydev, u8 index,
+				       unsigned long rules)
+{
+	u16 offload_trigger = 0;
+
+	if (index > 2)
+		return -EINVAL;
+
+	return qca808x_led_parse_netdev(phydev, rules, &offload_trigger);
+}
+
+static int qca808x_led_hw_control_set(struct phy_device *phydev, u8 index,
+				      unsigned long rules)
+{
+	u16 reg, offload_trigger = 0;
+	int ret;
+
+	if (index > 2)
+		return -EINVAL;
+
+	reg = QCA808X_MMD7_LED_CTRL(index);
+
+	ret = qca808x_led_parse_netdev(phydev, rules, &offload_trigger);
+	if (ret)
+		return ret;
+
+	ret = qca808x_led_hw_control_enable(phydev, index);
+	if (ret)
+		return ret;
+
+	return phy_modify_mmd(phydev, MDIO_MMD_AN, reg,
+			      QCA808X_LED_PATTERN_MASK,
+			      offload_trigger);
+}
+
+static bool qca808x_led_hw_control_status(struct phy_device *phydev, u8 index)
+{
+	u16 reg;
+	int val;
+
+	if (index > 2)
+		return false;
+
+	reg = QCA808X_MMD7_LED_FORCE_CTRL(index);
+
+	val = phy_read_mmd(phydev, MDIO_MMD_AN, reg);
+
+	return !(val & QCA808X_LED_FORCE_EN);
+}
+
+static int qca808x_led_hw_control_get(struct phy_device *phydev, u8 index,
+				      unsigned long *rules)
+{
+	u16 reg;
+	int val;
+
+	if (index > 2)
+		return -EINVAL;
+
+	/* Check if we have hw control enabled */
+	if (qca808x_led_hw_control_status(phydev, index))
+		return -EINVAL;
+
+	reg = QCA808X_MMD7_LED_CTRL(index);
+
+	/* TODO: add link_2500 when added to netdev trigger */
+	val = phy_read_mmd(phydev, MDIO_MMD_AN, reg);
+	if (val & QCA808X_LED_TX_BLINK)
+		set_bit(TRIGGER_NETDEV_TX, rules);
+	if (val & QCA808X_LED_RX_BLINK)
+		set_bit(TRIGGER_NETDEV_RX, rules);
+	if (val & QCA808X_LED_SPEED10_ON)
+		set_bit(TRIGGER_NETDEV_LINK_10, rules);
+	if (val & QCA808X_LED_SPEED100_ON)
+		set_bit(TRIGGER_NETDEV_LINK_100, rules);
+	if (val & QCA808X_LED_SPEED1000_ON)
+		set_bit(TRIGGER_NETDEV_LINK_1000, rules);
+	if (val & QCA808X_LED_HALF_DUPLEX_ON)
+		set_bit(TRIGGER_NETDEV_HALF_DUPLEX, rules);
+	if (val & QCA808X_LED_FULL_DUPLEX_ON)
+		set_bit(TRIGGER_NETDEV_FULL_DUPLEX, rules);
+
+	return 0;
+}
+
+static int qca808x_led_hw_control_reset(struct phy_device *phydev, u8 index)
+{
+	u16 reg;
+
+	if (index > 2)
+		return -EINVAL;
+
+	reg = QCA808X_MMD7_LED_CTRL(index);
+
+	return phy_clear_bits_mmd(phydev, MDIO_MMD_AN, reg,
+				  QCA808X_LED_PATTERN_MASK);
+}
+
+static int qca808x_led_brightness_set(struct phy_device *phydev,
+				      u8 index, enum led_brightness value)
+{
+	u16 reg;
+	int ret;
+
+	if (index > 2)
+		return -EINVAL;
+
+	if (!value) {
+		ret = qca808x_led_hw_control_reset(phydev, index);
+		if (ret)
+			return ret;
+	}
+
+	reg = QCA808X_MMD7_LED_FORCE_CTRL(index);
+
+	return phy_modify_mmd(phydev, MDIO_MMD_AN, reg,
+			      QCA808X_LED_FORCE_EN | QCA808X_LED_FORCE_MODE_MASK,
+			      QCA808X_LED_FORCE_EN | value ? QCA808X_LED_FORCE_ON :
+							     QCA808X_LED_FORCE_OFF);
+}
+
+static int qca808x_led_blink_set(struct phy_device *phydev, u8 index,
+				 unsigned long *delay_on,
+				 unsigned long *delay_off)
+{
+	int ret;
+	u16 reg;
+
+	if (index > 2)
+		return -EINVAL;
+
+	reg = QCA808X_MMD7_LED_FORCE_CTRL(index);
+
+	/* Set blink to 50% off, 50% on at 4Hz by default */
+	ret = phy_modify_mmd(phydev, MDIO_MMD_AN, QCA808X_MMD7_LED_GLOBAL,
+			     QCA808X_LED_BLINK_FREQ_MASK | QCA808X_LED_BLINK_DUTY_MASK,
+			     QCA808X_LED_BLINK_FREQ_256HZ | QCA808X_LED_BLINK_DUTY_50_50);
+	if (ret)
+		return ret;
+
+	/* We use BLINK_1 for normal blinking */
+	ret = phy_modify_mmd(phydev, MDIO_MMD_AN, reg,
+			     QCA808X_LED_FORCE_EN | QCA808X_LED_FORCE_MODE_MASK,
+			     QCA808X_LED_FORCE_EN | QCA808X_LED_FORCE_BLINK_1);
+	if (ret)
+		return ret;
+
+	/* We set blink to 4Hz, aka 250ms */
+	*delay_on = 250 / 2;
+	*delay_off = 250 / 2;
+
+	return 0;
+}
+
+static int qca808x_led_polarity_set(struct phy_device *phydev, int index,
+				    unsigned long modes)
+{
+	struct at803x_priv *priv = phydev->priv;
+	bool active_low = false;
+	u32 mode;
+	int ret;
+
+	for_each_set_bit(mode, &modes, __PHY_LED_MODES_NUM) {
+		switch (mode) {
+		case PHY_LED_ACTIVE_LOW:
+			active_low = true;
+			break;
+		default:
+			return -EINVAL;
+		}
+	}
+
+	/* PHY polarity is global and can't be set per LED.
+	 * To detect this, check if last requested polarity mode
+	 * match the new one.
+	 */
+	if (priv->led_polarity_mode >= 0 &&
+	    priv->led_polarity_mode != active_low) {
+		phydev_err(phydev, "PHY polarity is global. Mismatched polarity on different LED\n");
+		return -EINVAL;
+	}
+
+	/* Save the last PHY polarity mode */
+	priv->led_polarity_mode = active_low;
+
+	if (active_low) {
+		ret = phy_clear_bits_mmd(phydev, MDIO_MMD_AN,
+					 QCA808X_MMD7_LED_POLARITY_CTRL,
+					 QCA808X_LED_ACTIVE_HIGH);
+	} else {
+		ret = phy_set_bits_mmd(phydev, MDIO_MMD_AN,
+				       QCA808X_MMD7_LED_POLARITY_CTRL,
+				       QCA808X_LED_ACTIVE_HIGH);
+	}
+
+	return ret;
+}
+
 static struct phy_driver at803x_driver[] = {
 {
 	/* Qualcomm Atheros AR8035 */
@@ -2328,6 +2655,12 @@ static struct phy_driver at803x_driver[] = {
 	.cable_test_start	= qca808x_cable_test_start,
 	.cable_test_get_status	= qca808x_cable_test_get_status,
 	.link_change_notify	= qca808x_link_change_notify,
+	.led_brightness_set	= qca808x_led_brightness_set,
+	.led_blink_set		= qca808x_led_blink_set,
+	.led_hw_is_supported	= qca808x_led_hw_is_supported,
+	.led_hw_control_set	= qca808x_led_hw_control_set,
+	.led_hw_control_get	= qca808x_led_hw_control_get,
+	.led_polarity_set	= qca808x_led_polarity_set,
 }, };
 
 module_phy_driver(at803x_driver);
-- 
2.40.1



From treapking at chromium.org  Wed Dec 27 01:04:42 2023
From: treapking at chromium.org (Pin-yen Lin)
Date: Wed, 27 Dec 2023 17:04:42 +0800
Subject: [PATCH 1/2] clk: mediatek: Introduce need_pm_runtime to mtk_clk_desc
Message-ID: <20231227090448.2216295-1-treapking@chromium.org>

Introduce a new need_pm_runtime variable to mtk_clk_desc to indicate this
clock needs a runtime PM get during the probing stage.

Signed-off-by: Pin-yen Lin <treapking at chromium.org>
---

 drivers/clk/mediatek/clk-mtk.c | 15 +++++++++++++++
 drivers/clk/mediatek/clk-mtk.h |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 2e55368dc4d8..c31e535909c8 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -13,6 +13,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
 #include "clk-mtk.h"
@@ -494,6 +495,14 @@ static int __mtk_clk_simple_probe(struct platform_device *pdev,
 			return IS_ERR(base) ? PTR_ERR(base) : -ENOMEM;
 	}
 
+
+	if (mcd->need_runtime_pm) {
+		devm_pm_runtime_enable(&pdev->dev);
+		r = pm_runtime_resume_and_get(&pdev->dev);
+		if (r)
+			return r;
+	}
+
 	/* Calculate how many clk_hw_onecell_data entries to allocate */
 	num_clks = mcd->num_clks + mcd->num_composite_clks;
 	num_clks += mcd->num_fixed_clks + mcd->num_factor_clks;
@@ -574,6 +583,9 @@ static int __mtk_clk_simple_probe(struct platform_device *pdev,
 			goto unregister_clks;
 	}
 
+	if (mcd->need_runtime_pm)
+		pm_runtime_put(&pdev->dev);
+
 	return r;
 
 unregister_clks:
@@ -604,6 +616,9 @@ static int __mtk_clk_simple_probe(struct platform_device *pdev,
 free_base:
 	if (mcd->shared_io && base)
 		iounmap(base);
+
+	if (mcd->need_runtime_pm)
+		pm_runtime_put(&pdev->dev);
 	return r;
 }
 
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 22096501a60a..c17fe1c2d732 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -237,6 +237,8 @@ struct mtk_clk_desc {
 
 	int (*clk_notifier_func)(struct device *dev, struct clk *clk);
 	unsigned int mfg_clk_idx;
+
+	bool need_runtime_pm;
 };
 
 int mtk_clk_pdev_probe(struct platform_device *pdev);
-- 
2.43.0.472.g3155946c3a-goog



From treapking at chromium.org  Wed Dec 27 01:04:43 2023
From: treapking at chromium.org (Pin-yen Lin)
Date: Wed, 27 Dec 2023 17:04:43 +0800
Subject: [PATCH 2/2] clk: mediatek: mt8183: Enable need_runtime_pm on mt8183-mfgcfg
In-Reply-To: <20231227090448.2216295-1-treapking@chromium.org>
References: <20231227090448.2216295-1-treapking@chromium.org>
Message-ID: <20231227090448.2216295-2-treapking@chromium.org>

mt8183-mfgcfg has a mutual dependency with genpd during the probing
stage, so enable need_runtim_pm to prevent a deadlock in the following
call stack:

CPU0:  genpd_lock --> clk_prepare_lock
genpd_power_off_work_fn()
 genpd_lock()
 generic_pm_domain::power_off()
    clk_unprepare()
      clk_prepare_lock()

CPU1: clk_prepare_lock --> genpd_lock
clk_register()
  __clk_core_init()
    clk_prepare_lock()
    clk_pm_runtime_get()
      genpd_lock()

Do a runtime PM get at the probe function to make sure clk_register()
won't acquire the genpd lock.

Fixes: acddfc2c261b ("clk: mediatek: Add MT8183 clock support")
Signed-off-by: Pin-yen Lin <treapking at chromium.org>
---

 drivers/clk/mediatek/clk-mt8183-mfgcfg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/mediatek/clk-mt8183-mfgcfg.c b/drivers/clk/mediatek/clk-mt8183-mfgcfg.c
index ba504e19d420..62d876e150e1 100644
--- a/drivers/clk/mediatek/clk-mt8183-mfgcfg.c
+++ b/drivers/clk/mediatek/clk-mt8183-mfgcfg.c
@@ -29,6 +29,7 @@ static const struct mtk_gate mfg_clks[] = {
 static const struct mtk_clk_desc mfg_desc = {
 	.clks = mfg_clks,
 	.num_clks = ARRAY_SIZE(mfg_clks),
+	.need_runtime_pm = true,
 };
 
 static const struct of_device_id of_match_clk_mt8183_mfg[] = {
-- 
2.43.0.472.g3155946c3a-goog



From s.shtylyov at omp.ru  Wed Dec 27 01:19:42 2023
From: s.shtylyov at omp.ru (Sergey Shtylyov)
Date: Wed, 27 Dec 2023 12:19:42 +0300
Subject: [PATCH v4 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <20231227060316.8539-1-chunfeng.yun@mediatek.com>
References: <20231227060316.8539-1-chunfeng.yun@mediatek.com>
Message-ID: <1e5772b3-2e71-069c-5794-ded2ee72222f@omp.ru>

On 12/27/23 9:03 AM, Chunfeng Yun wrote:

> For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
> still send out unexpected ACK after receiving a short packet in burst
> transfer, this will cause an exception on connected device, specially for
> a 4k camera.
> Add a quirk property "rx-fifo-depth" to work around this hardware issue,
> prefer to use 3k bytes;
> The side-effect is that may cause performance drop about 10%, including

   That it may cause?

> bulk transfer.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
> v4: change rx-fifo size in bytes
> v3: add fifo depth unit, change the value range from 0-3 to 1-4
> v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
> ---
>  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml    | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> index e9644e333d78..9f621f2209df 100644
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
> @@ -124,6 +124,17 @@ properties:
>        defined in the xHCI spec on MTK's controller.
>      default: 5000
>  
> +  rx-fifo-depth:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      It is a quirk used to work around Gen1 isoc-in endpoint transfer issue
> +      that still send out unexpected ACK after device finish the burst transfer

   Finishes.

> +      with a short packet and cause an exception, specially on a 4K camera
> +      device, it happens on controller before about IPM v1.6.0; the side-effect
> +      is that may cause performance drop about 10%, include bulk transfer,

   That it may cause? And including?

[...]

MBR, Sergey


From shengjiu.wang at nxp.com  Wed Dec 27 01:27:43 2023
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Wed, 27 Dec 2023 17:27:43 +0800
Subject: [PATCH] ASoC: SOF: imx: Add SNDRV_PCM_INFO_BATCH flag
Message-ID: <1703669263-13832-1-git-send-email-shengjiu.wang@nxp.com>

The sof imx pcm device is a device which should support
double buffering.

Found this issue with pipewire. When there is no
SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will
set headroom to be zero, and because sof pcm device
don't support residue report, when the latency setting
is small, the "delay" always larger than "target" in
alsa-pcm.c, that reading next period data is not
scheduled on time.

With SNDRV_PCM_INFO_BATCH flag in driver, the pipewire
will select a smaller period size for device, then
the task of reading next period data will be scheduled
on time.

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
---
 sound/soc/sof/imx/imx8.c    | 1 +
 sound/soc/sof/imx/imx8m.c   | 1 +
 sound/soc/sof/imx/imx8ulp.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/sound/soc/sof/imx/imx8.c b/sound/soc/sof/imx/imx8.c
index 170740bce839..d777e70250ef 100644
--- a/sound/soc/sof/imx/imx8.c
+++ b/sound/soc/sof/imx/imx8.c
@@ -603,6 +603,7 @@ static struct snd_sof_dsp_ops sof_imx8x_ops = {
 			SNDRV_PCM_INFO_MMAP_VALID |
 			SNDRV_PCM_INFO_INTERLEAVED |
 			SNDRV_PCM_INFO_PAUSE |
+			SNDRV_PCM_INFO_BATCH |
 			SNDRV_PCM_INFO_NO_PERIOD_WAKEUP
 };
 
diff --git a/sound/soc/sof/imx/imx8m.c b/sound/soc/sof/imx/imx8m.c
index f088fd1a672b..1b976fa500aa 100644
--- a/sound/soc/sof/imx/imx8m.c
+++ b/sound/soc/sof/imx/imx8m.c
@@ -472,6 +472,7 @@ static struct snd_sof_dsp_ops sof_imx8m_ops = {
 		SNDRV_PCM_INFO_MMAP_VALID |
 		SNDRV_PCM_INFO_INTERLEAVED |
 		SNDRV_PCM_INFO_PAUSE |
+		SNDRV_PCM_INFO_BATCH |
 		SNDRV_PCM_INFO_NO_PERIOD_WAKEUP,
 };
 
diff --git a/sound/soc/sof/imx/imx8ulp.c b/sound/soc/sof/imx/imx8ulp.c
index ca6edb85ff71..2badca75782b 100644
--- a/sound/soc/sof/imx/imx8ulp.c
+++ b/sound/soc/sof/imx/imx8ulp.c
@@ -463,6 +463,7 @@ static struct snd_sof_dsp_ops sof_imx8ulp_ops = {
 			SNDRV_PCM_INFO_MMAP_VALID |
 			SNDRV_PCM_INFO_INTERLEAVED |
 			SNDRV_PCM_INFO_PAUSE |
+			SNDRV_PCM_INFO_BATCH |
 			SNDRV_PCM_INFO_NO_PERIOD_WAKEUP,
 
 	/* PM */
-- 
2.34.1



From johan+linaro at kernel.org  Wed Dec 27 02:10:03 2023
From: johan+linaro at kernel.org (Johan Hovold)
Date: Wed, 27 Dec 2023 11:10:03 +0100
Subject: [PATCH] Bluetooth: hci_bcm4377: do not mark valid bd_addr as invalid
Message-ID: <20231227101003.10534-1-johan+linaro@kernel.org>

A recent commit restored the original (and still documented) semantics
for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device address
is considered invalid unless an address is provided by firmware.

This specifically means that this flag must only be set for devices with
invalid addresses, but the Broadcom BCM4377 driver has so far been
setting this flag unconditionally.

Fortunately the driver already checks for invalid addresses during setup
and sets the HCI_QUIRK_INVALID_BDADDR flag, which can simply be replaced
with HCI_QUIRK_USE_BDADDR_PROPERTY to indicate that the default address
is invalid but can be overridden by firmware (long term, this should
probably just always be allowed).

Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk")
Cc: stable at vger.kernel.org      # 6.5
Reported-by: Felix Zhang <mrman at mrman314.tech>
Link: https://lore.kernel.org/r/77419ffacc5b4875e920e038332575a2a5bff29f.camel at mrman314.tech/
Signed-off-by: Johan Hovold <johan+linaro at kernel.org>
---
 drivers/bluetooth/hci_bcm4377.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index a61757835695..9a7243d5db71 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -1417,7 +1417,7 @@ static int bcm4377_check_bdaddr(struct bcm4377_data *bcm4377)
 
 	bda = (struct hci_rp_read_bd_addr *)skb->data;
 	if (!bcm4377_is_valid_bdaddr(bcm4377, &bda->bdaddr))
-		set_bit(HCI_QUIRK_INVALID_BDADDR, &bcm4377->hdev->quirks);
+		set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &bcm4377->hdev->quirks);
 
 	kfree_skb(skb);
 	return 0;
@@ -2368,7 +2368,6 @@ static int bcm4377_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	hdev->set_bdaddr = bcm4377_hci_set_bdaddr;
 	hdev->setup = bcm4377_hci_setup;
 
-	set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
 	if (bcm4377->hw->broken_mws_transport_config)
 		set_bit(HCI_QUIRK_BROKEN_MWS_TRANSPORT_CONFIG, &hdev->quirks);
 	if (bcm4377->hw->broken_ext_scan)
-- 
2.41.0



From lpieralisi at kernel.org  Wed Dec 27 03:00:35 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Wed, 27 Dec 2023 12:00:35 +0100
Subject: [PATCH v4 0/3] irqchip/gic-v3: Enable non-coherent GIC designs probing
In-Reply-To: <20230905104721.52199-1-lpieralisi@kernel.org>
References: <20230905104721.52199-1-lpieralisi@kernel.org>
Message-ID: <20231227110038.55453-1-lpieralisi@kernel.org>

This series is v4 of previous series:

v3: https://lore.kernel.org/all/20231006125929.48591-1-lpieralisi at kernel.org
v2: https://lore.kernel.org/all/20230906094139.16032-1-lpieralisi at kernel.org
v1: https://lore.kernel.org/all/20230905104721.52199-1-lpieralisi at kernel.org

v3 -> v4:
	- Dropped patches [1-3], already merged
	- Added Linuxized ACPICA changes accepted upstream
	- Rebased against v6.7-rc3

v2 -> v3:
	- Added ACPICA temporary changes and ACPI changes to implement
	  ECR https://bugzilla.tianocore.org/show_bug.cgi?id=4557
	- ACPI changes are for testing purposes - subject to ECR code
	  first approval

v1 -> v2:
	- Updated DT bindings as per feedback
	- Updated patch[2] to use GIC quirks infrastructure

Original cover letter
---
The GICv3 architecture specifications provide a means for the
system programmer to set the shareability and cacheability
attributes the GIC components (redistributors and ITSes) use
to drive memory transactions.

Albeit the architecture give control over shareability/cacheability
memory transactions attributes (and barriers), it is allowed to
connect the GIC interconnect ports to non-coherent memory ports
on the interconnect, basically tying off shareability/cacheability
"wires" and de-facto making the redistributors and ITSes non-coherent
memory observers.

This series aims at starting a discussion over a possible solution
to this problem, by adding to the GIC device tree bindings the
standard dma-noncoherent property. The GIC driver uses the property
to force the redistributors and ITSes shareability attributes to
non-shareable, which consequently forces the driver to use CMOs
on GIC memory tables.

On ARM DT DMA is default non-coherent, so the GIC driver can't rely
on the generic DT dma-coherent/non-coherent property management layer
(of_dma_is_coherent()) which would default all GIC designs in the field
as non-coherent; it has to rely on ad-hoc dma-noncoherent property handling.

When a consistent approach is agreed upon for DT an equivalent binding will
be put forward for ACPI based systems.

Lorenzo Pieralisi (3):
  ACPICA: MADT: Add GICC online capable bit handling
  ACPICA: MADT: Add new MADT GICC/GICR/ITS non-coherent flags handling
  irqchip/gic-v3: Enable non-coherent redistributors/ITSes ACPI probing

 drivers/acpi/processor_core.c    | 21 +++++++++++++++++++++
 drivers/irqchip/irq-gic-common.h |  8 ++++++++
 drivers/irqchip/irq-gic-v3-its.c |  4 ++++
 drivers/irqchip/irq-gic-v3.c     |  9 +++++++++
 include/acpi/actbl2.h            | 12 ++++++++++--
 include/linux/acpi.h             |  3 +++
 6 files changed, 55 insertions(+), 2 deletions(-)

-- 
2.34.1



From lpieralisi at kernel.org  Wed Dec 27 03:00:36 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Wed, 27 Dec 2023 12:00:36 +0100
Subject: [PATCH v4 1/3] ACPICA: MADT: Add GICC online capable bit handling
In-Reply-To: <20231227110038.55453-1-lpieralisi@kernel.org>
References: <20230905104721.52199-1-lpieralisi@kernel.org>
 <20231227110038.55453-1-lpieralisi@kernel.org>
Message-ID: <20231227110038.55453-2-lpieralisi@kernel.org>

ACPICA commit 16f0befdeddf25756f317907798192bbaa417e5e

Implement code to handle the GICC online capable bit management
added into ACPI v6.5.

Link: https://github.com/acpica/acpica/commit/16f0befd
Signed-off-by: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Robert Moore <robert.moore at intel.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki at intel.com>
---
 include/acpi/actbl2.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index 3751ae69432f..2b4dd2c3348f 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -1046,6 +1046,7 @@ struct acpi_madt_generic_interrupt {
 /* ACPI_MADT_ENABLED                    (1)      Processor is usable if set */
 #define ACPI_MADT_PERFORMANCE_IRQ_MODE  (1<<1)	/* 01: Performance Interrupt Mode */
 #define ACPI_MADT_VGIC_IRQ_MODE         (1<<2)	/* 02: VGIC Maintenance Interrupt mode */
+#define ACPI_MADT_GICC_ONLINE_CAPABLE   (1<<3)	/* 03: Processor is online capable  */
 
 /* 12: Generic Distributor (ACPI 5.0 + ACPI 6.0 changes) */
 
-- 
2.34.1



From lpieralisi at kernel.org  Wed Dec 27 03:00:37 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Wed, 27 Dec 2023 12:00:37 +0100
Subject: [PATCH v4 2/3] ACPICA: MADT: Add new MADT GICC/GICR/ITS non-coherent flags handling
In-Reply-To: <20231227110038.55453-1-lpieralisi@kernel.org>
References: <20230905104721.52199-1-lpieralisi@kernel.org>
 <20231227110038.55453-1-lpieralisi@kernel.org>
Message-ID: <20231227110038.55453-3-lpieralisi@kernel.org>

ACPICA commit c5d2010744b1bf7efba0bd04a8a9c200ef8fb610

Add new flags and related fields to the MADT GICC/GICR/ITS
structures according to the code first ECR:

https://bugzilla.tianocore.org/show_bug.cgi?id=4557

Update the MADT template to the latest MADT revision.

Link: https://github.com/acpica/acpica/commit/c5d20107
Signed-off-by: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Robert Moore <robert.moore at intel.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki at intel.com>
---
 include/acpi/actbl2.h | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index 2b4dd2c3348f..9775384d61c6 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -1047,6 +1047,7 @@ struct acpi_madt_generic_interrupt {
 #define ACPI_MADT_PERFORMANCE_IRQ_MODE  (1<<1)	/* 01: Performance Interrupt Mode */
 #define ACPI_MADT_VGIC_IRQ_MODE         (1<<2)	/* 02: VGIC Maintenance Interrupt mode */
 #define ACPI_MADT_GICC_ONLINE_CAPABLE   (1<<3)	/* 03: Processor is online capable  */
+#define ACPI_MADT_GICC_NON_COHERENT     (1<<4)	/* 04: GIC redistributor is not coherent */
 
 /* 12: Generic Distributor (ACPI 5.0 + ACPI 6.0 changes) */
 
@@ -1091,21 +1092,27 @@ struct acpi_madt_generic_msi_frame {
 
 struct acpi_madt_generic_redistributor {
 	struct acpi_subtable_header header;
-	u16 reserved;		/* reserved - must be zero */
+	u8 flags;
+	u8 reserved;		/* reserved - must be zero */
 	u64 base_address;
 	u32 length;
 };
 
+#define ACPI_MADT_GICR_NON_COHERENT     (1)
+
 /* 15: Generic Translator (ACPI 6.0) */
 
 struct acpi_madt_generic_translator {
 	struct acpi_subtable_header header;
-	u16 reserved;		/* reserved - must be zero */
+	u8 flags;
+	u8 reserved;		/* reserved - must be zero */
 	u32 translation_id;
 	u64 base_address;
 	u32 reserved2;
 };
 
+#define ACPI_MADT_ITS_NON_COHERENT      (1)
+
 /* 16: Multiprocessor wakeup (ACPI 6.4) */
 
 struct acpi_madt_multiproc_wakeup {
-- 
2.34.1



From lpieralisi at kernel.org  Wed Dec 27 03:00:38 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Wed, 27 Dec 2023 12:00:38 +0100
Subject: [PATCH v4 3/3] irqchip/gic-v3: Enable non-coherent redistributors/ITSes ACPI probing
In-Reply-To: <20231227110038.55453-1-lpieralisi@kernel.org>
References: <20230905104721.52199-1-lpieralisi@kernel.org>
 <20231227110038.55453-1-lpieralisi@kernel.org>
Message-ID: <20231227110038.55453-4-lpieralisi@kernel.org>

The GIC architecture specification defines a set of registers
for redistributors and ITSes that control the sharebility and
cacheability attributes of redistributors/ITSes initiator ports
on the interconnect (GICR_[V]PROPBASER, GICR_[V]PENDBASER,
GITS_BASER<n>).

Architecturally the GIC provides a means to drive shareability
and cacheability attributes signals and related IWB/OWB/ISH barriers
but it is not mandatory for designs to wire up the corresponding
interconnect signals that control the cacheability/shareability
of transactions.

Redistributors and ITSes interconnect ports can be connected to
non-coherent interconnects that are not able to manage the
shareability/cacheability attributes; this implicitly makes
the redistributors and ITSes non-coherent observers.

So far, the GIC driver on probe executes a write to "probe" for
the redistributors and ITSes registers shareability bitfields
by writing a value (ie InnerShareable - the shareability domain the
CPUs are in) and check it back to detect whether the value sticks or
not; this hinges on a GIC programming model behaviour that predates the
current specifications, that just define shareability bits as writeable
but do not guarantee that writing certain shareability values
enable the expected behaviour for the redistributors/ITSes
memory interconnect ports.

To enable non-coherent GIC designs on ACPI based systems, parse the MADT
GICC/GICR/ITS subtables non-coherent flags to determine whether the
respective components are non-coherent observers and force the shareability
attributes to be programmed into the redistributors and ITSes registers.

An ACPI global function (acpi_get_madt_revision()) is added to retrieve
the MADT revision, in that it is essential to check the MADT revision
before checking for flags that were added with MADT revision 7 so that
if the kernel is booted with ACPI tables (MADT rev < 7) it skips parsing
the newly added flags (that should be zeroed reserved values for MADT
versions < 7 but they could turn out to be buggy and should be ignored).

Signed-off-by: Lorenzo Pieralisi <lpieralisi at kernel.org>
Cc: Robin Murphy <robin.murphy at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: "Rafael J. Wysocki" <rafael at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
---
 drivers/acpi/processor_core.c    | 21 +++++++++++++++++++++
 drivers/irqchip/irq-gic-common.h |  8 ++++++++
 drivers/irqchip/irq-gic-v3-its.c |  4 ++++
 drivers/irqchip/irq-gic-v3.c     |  9 +++++++++
 include/linux/acpi.h             |  3 +++
 5 files changed, 45 insertions(+)

diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index b203cfe28550..c253d151275e 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -215,6 +215,27 @@ phys_cpuid_t __init acpi_map_madt_entry(u32 acpi_id)
 	return rv;
 }
 
+u8 __init acpi_get_madt_revision(void)
+{
+	static u8 madt_revision __initdata;
+	static bool madt_read __initdata;
+	struct acpi_table_header *madt = NULL;
+
+	if (!madt_read) {
+		madt_read = true;
+
+		acpi_get_table(ACPI_SIG_MADT, 0, &madt);
+		if (!madt)
+			return madt_revision;
+
+		madt_revision = madt->revision;
+
+		acpi_put_table(madt);
+	}
+
+	return madt_revision;
+}
+
 static phys_cpuid_t map_mat_entry(acpi_handle handle, int type, u32 acpi_id)
 {
 	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
index f407cce9ecaa..8dffee95f7e8 100644
--- a/drivers/irqchip/irq-gic-common.h
+++ b/drivers/irqchip/irq-gic-common.h
@@ -6,6 +6,7 @@
 #ifndef _IRQ_GIC_COMMON_H
 #define _IRQ_GIC_COMMON_H
 
+#include <linux/acpi.h>
 #include <linux/of.h>
 #include <linux/irqdomain.h>
 #include <linux/irqchip/arm-gic-common.h>
@@ -29,6 +30,13 @@ void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
 void gic_enable_of_quirks(const struct device_node *np,
 			  const struct gic_quirk *quirks, void *data);
 
+#ifdef CONFIG_ACPI
+static inline bool gic_acpi_non_coherent_flag(u32 flags, u32 mask)
+{
+	return (acpi_get_madt_revision() >= 7) && (flags & mask);
+}
+#endif
+
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING    (1 << 0)
 #define RDIST_FLAGS_RD_TABLES_PREALLOCATED     (1 << 1)
 #define RDIST_FLAGS_FORCE_NON_SHAREABLE        (1 << 2)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 9a7a74239eab..8d088fca65a1 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -5578,6 +5578,10 @@ static int __init gic_acpi_parse_madt_its(union acpi_subtable_headers *header,
 		goto node_err;
 	}
 
+	if (gic_acpi_non_coherent_flag(its_entry->flags,
+				       ACPI_MADT_ITS_NON_COHERENT))
+		its->flags |= ITS_FLAGS_FORCE_NON_SHAREABLE;
+
 	err = its_probe_one(its);
 	if (!err)
 		return 0;
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 98b0329b7154..48e02838fdc8 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -2356,6 +2356,11 @@ gic_acpi_parse_madt_redist(union acpi_subtable_headers *header,
 		pr_err("Couldn't map GICR region @%llx\n", redist->base_address);
 		return -ENOMEM;
 	}
+
+	if (gic_acpi_non_coherent_flag(redist->flags,
+				       ACPI_MADT_GICR_NON_COHERENT))
+		gic_data.rdists.flags |= RDIST_FLAGS_FORCE_NON_SHAREABLE;
+
 	gic_request_region(redist->base_address, redist->length, "GICR");
 
 	gic_acpi_register_redist(redist->base_address, redist_base);
@@ -2380,6 +2385,10 @@ gic_acpi_parse_madt_gicc(union acpi_subtable_headers *header,
 		return -ENOMEM;
 	gic_request_region(gicc->gicr_base_address, size, "GICR");
 
+	if (gic_acpi_non_coherent_flag(gicc->flags,
+				       ACPI_MADT_GICC_NON_COHERENT))
+		gic_data.rdists.flags |= RDIST_FLAGS_FORCE_NON_SHAREABLE;
+
 	gic_acpi_register_redist(gicc->gicr_base_address, redist_base);
 	return 0;
 }
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 54189e0e5f41..a292f2bdb693 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -283,6 +283,9 @@ static inline bool invalid_phys_cpuid(phys_cpuid_t phys_id)
 	return phys_id == PHYS_CPUID_INVALID;
 }
 
+
+u8 __init acpi_get_madt_revision(void);
+
 /* Validate the processor object's proc_id */
 bool acpi_duplicate_processor_id(int proc_id);
 /* Processor _CTS control */
-- 
2.34.1



From liviu.dudau at arm.com  Wed Dec 27 03:07:16 2023
From: liviu.dudau at arm.com (Liviu Dudau)
Date: Wed, 27 Dec 2023 11:07:16 +0000
Subject: [PATCH] ARM: Delete ARM11MPCore perf leftovers
In-Reply-To: <20231224-drop-11mpcore-fix-v1-1-d8b16d1c1fae@linaro.org>
References: <20231224-drop-11mpcore-fix-v1-1-d8b16d1c1fae@linaro.org>
Message-ID: <ZYwFZOwbBAEy9PJ1@e110455-lin.cambridge.arm.com>

On Sun, Dec 24, 2023 at 11:24:38PM +0100, Linus Walleij wrote:
> My commit deleting the PB11MPCore apparently left a few dangling
> structs in the perf event code. Fix it up.
> 
> Fixes: 2560cffd2134 ("ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support")
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Reviewed-by: Liviu Dudau <liviu.dudau at arm.com>

Best regards,
Liviu

> ---
> This fixes a warning reported in the SoC tree, it's not even
> in next yet. Now that I turned on ARMv6 in my builds it is
> also tested.
> ---
>  arch/arm/kernel/perf_event_v6.c | 94 -----------------------------------------
>  1 file changed, 94 deletions(-)
> 
> diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
> index 3115077f6abc..0cbf46233d6b 100644
> --- a/arch/arm/kernel/perf_event_v6.c
> +++ b/arch/arm/kernel/perf_event_v6.c
> @@ -113,69 +113,6 @@ static const unsigned armv6_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
>  	[C(ITLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6_PERFCTR_ITLB_MISS,
>  };
>  
> -enum armv6mpcore_perf_types {
> -	ARMV6MPCORE_PERFCTR_ICACHE_MISS	    = 0x0,
> -	ARMV6MPCORE_PERFCTR_IBUF_STALL	    = 0x1,
> -	ARMV6MPCORE_PERFCTR_DDEP_STALL	    = 0x2,
> -	ARMV6MPCORE_PERFCTR_ITLB_MISS	    = 0x3,
> -	ARMV6MPCORE_PERFCTR_DTLB_MISS	    = 0x4,
> -	ARMV6MPCORE_PERFCTR_BR_EXEC	    = 0x5,
> -	ARMV6MPCORE_PERFCTR_BR_NOTPREDICT   = 0x6,
> -	ARMV6MPCORE_PERFCTR_BR_MISPREDICT   = 0x7,
> -	ARMV6MPCORE_PERFCTR_INSTR_EXEC	    = 0x8,
> -	ARMV6MPCORE_PERFCTR_DCACHE_RDACCESS = 0xA,
> -	ARMV6MPCORE_PERFCTR_DCACHE_RDMISS   = 0xB,
> -	ARMV6MPCORE_PERFCTR_DCACHE_WRACCESS = 0xC,
> -	ARMV6MPCORE_PERFCTR_DCACHE_WRMISS   = 0xD,
> -	ARMV6MPCORE_PERFCTR_DCACHE_EVICTION = 0xE,
> -	ARMV6MPCORE_PERFCTR_SW_PC_CHANGE    = 0xF,
> -	ARMV6MPCORE_PERFCTR_MAIN_TLB_MISS   = 0x10,
> -	ARMV6MPCORE_PERFCTR_EXPL_MEM_ACCESS = 0x11,
> -	ARMV6MPCORE_PERFCTR_LSU_FULL_STALL  = 0x12,
> -	ARMV6MPCORE_PERFCTR_WBUF_DRAINED    = 0x13,
> -	ARMV6MPCORE_PERFCTR_CPU_CYCLES	    = 0xFF,
> -};
> -
> -/*
> - * The hardware events that we support. We do support cache operations but
> - * we have harvard caches and no way to combine instruction and data
> - * accesses/misses in hardware.
> - */
> -static const unsigned armv6mpcore_perf_map[PERF_COUNT_HW_MAX] = {
> -	PERF_MAP_ALL_UNSUPPORTED,
> -	[PERF_COUNT_HW_CPU_CYCLES]		= ARMV6MPCORE_PERFCTR_CPU_CYCLES,
> -	[PERF_COUNT_HW_INSTRUCTIONS]		= ARMV6MPCORE_PERFCTR_INSTR_EXEC,
> -	[PERF_COUNT_HW_BRANCH_INSTRUCTIONS]	= ARMV6MPCORE_PERFCTR_BR_EXEC,
> -	[PERF_COUNT_HW_BRANCH_MISSES]		= ARMV6MPCORE_PERFCTR_BR_MISPREDICT,
> -	[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND]	= ARMV6MPCORE_PERFCTR_IBUF_STALL,
> -	[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]	= ARMV6MPCORE_PERFCTR_LSU_FULL_STALL,
> -};
> -
> -static const unsigned armv6mpcore_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
> -					[PERF_COUNT_HW_CACHE_OP_MAX]
> -					[PERF_COUNT_HW_CACHE_RESULT_MAX] = {
> -	PERF_CACHE_MAP_ALL_UNSUPPORTED,
> -
> -	[C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV6MPCORE_PERFCTR_DCACHE_RDACCESS,
> -	[C(L1D)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DCACHE_RDMISS,
> -	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV6MPCORE_PERFCTR_DCACHE_WRACCESS,
> -	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DCACHE_WRMISS,
> -
> -	[C(L1I)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_ICACHE_MISS,
> -
> -	/*
> -	 * The ARM performance counters can count micro DTLB misses, micro ITLB
> -	 * misses and main TLB misses. There isn't an event for TLB misses, so
> -	 * use the micro misses here and if users want the main TLB misses they
> -	 * can use a raw counter.
> -	 */
> -	[C(DTLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DTLB_MISS,
> -	[C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_DTLB_MISS,
> -
> -	[C(ITLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_ITLB_MISS,
> -	[C(ITLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV6MPCORE_PERFCTR_ITLB_MISS,
> -};
> -
>  static inline unsigned long
>  armv6_pmcr_read(void)
>  {
> @@ -452,37 +389,6 @@ static void armv6pmu_disable_event(struct perf_event *event)
>  	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  }
>  
> -static void armv6mpcore_pmu_disable_event(struct perf_event *event)
> -{
> -	unsigned long val, mask, flags, evt = 0;
> -	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> -	struct hw_perf_event *hwc = &event->hw;
> -	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> -	int idx = hwc->idx;
> -
> -	if (ARMV6_CYCLE_COUNTER == idx) {
> -		mask	= ARMV6_PMCR_CCOUNT_IEN;
> -	} else if (ARMV6_COUNTER0 == idx) {
> -		mask	= ARMV6_PMCR_COUNT0_IEN;
> -	} else if (ARMV6_COUNTER1 == idx) {
> -		mask	= ARMV6_PMCR_COUNT1_IEN;
> -	} else {
> -		WARN_ONCE(1, "invalid counter number (%d)\n", idx);
> -		return;
> -	}
> -
> -	/*
> -	 * Unlike UP ARMv6, we don't have a way of stopping the counters. We
> -	 * simply disable the interrupt reporting.
> -	 */
> -	raw_spin_lock_irqsave(&events->pmu_lock, flags);
> -	val = armv6_pmcr_read();
> -	val &= ~mask;
> -	val |= evt;
> -	armv6_pmcr_write(val);
> -	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> -}
> -
>  static int armv6_map_event(struct perf_event *event)
>  {
>  	return armpmu_map_event(event, &armv6_perf_map,
> 
> ---
> base-commit: b057e7afb79ec2edddc940b82af6e3571d1f0ffe
> change-id: 20231224-drop-11mpcore-fix-c6cb526d1296
> 
> Best regards,
> -- 
> Linus Walleij <linus.walleij at linaro.org>
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?


From lpieralisi at kernel.org  Wed Dec 27 03:15:14 2023
From: lpieralisi at kernel.org (Lorenzo Pieralisi)
Date: Wed, 27 Dec 2023 12:15:14 +0100
Subject: [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields
In-Reply-To: <CAJZ5v0hyUqJspPbGTgTMSVHVBe=wHR6swPx-O3UcsH5dXDFpTA@mail.gmail.com>
References: <ZXmn46ptis59F0CO@shell.armlinux.org.uk>
 <E1rDOgs-00Dvko-6t@rmk-PC.armlinux.org.uk>
 <20231215162322.00007391@Huawei.com>
 <ZXyEiHLFBsoUkfNI@shell.armlinux.org.uk>
 <ZYAPhlwPUT/7dN4n@lpieralisi>
 <CAJZ5v0hyUqJspPbGTgTMSVHVBe=wHR6swPx-O3UcsH5dXDFpTA@mail.gmail.com>
Message-ID: <ZYwHQgdGGGVkwmJ8@lpieralisi>

On Mon, Dec 18, 2023 at 02:14:30PM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 18, 2023 at 10:23?AM Lorenzo Pieralisi
> <lpieralisi at kernel.org> wrote:
> >
> > On Fri, Dec 15, 2023 at 04:53:28PM +0000, Russell King (Oracle) wrote:
> > > On Fri, Dec 15, 2023 at 04:23:22PM +0000, Jonathan Cameron wrote:
> > > > On Wed, 13 Dec 2023 12:50:18 +0000
> > > > Russell King (Oracle) <rmk+kernel at armlinux.org.uk> wrote:
> > > >
> > > > > From: James Morse <james.morse at arm.com>
> > > > >
> > > > > Add the new flag field to the MADT's GICC structure.
> > > > >
> > > > > 'Online Capable' indicates a disabled CPU can be enabled later. See
> > > > > ACPI specification 6.5 Tabel 5.37: GICC CPU Interface Flags.
> > > > >
> > > > > Signed-off-by: James Morse <james.morse at arm.com>
> > > > > Tested-by: Miguel Luis <miguel.luis at oracle.com>
> > > > > Tested-by: Vishnu Pajjuri <vishnu at os.amperecomputing.com>
> > > > > Tested-by: Jianyong Wu <jianyong.wu at arm.com>
> > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> > > >
> > > > I see there is an acpica pull request including this bit but with a different name
> > > > For reference.
> > > > https://github.com/acpica/acpica/pull/914/commits/453a5f67567786522021d5f6913f561f8b3cabf6
> > > >
> > > > +CC Lorenzo who submitted that.
> > >
> > > > > +#define ACPI_MADT_GICC_CPU_CAPABLE      (1<<3)   /* 03: CPU is online capable */
> > > >
> > > > ACPI_MADT_GICC_ONLINE_CAPABLE
> > >
> > > It's somewhat disappointing, but no big deal. It's easy enough to change
> > > "irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs"
> > > to use Lorenzo's name when that patch hits - and it becomes one less
> > > patch in this patch set when Lorenzo's change eventually hits mainline.
> > >
> > > Does anyone know how long it may take for Lorenzo's change to get into
> > > mainline? Would it be by the 6.8 merge window or the following one?
> >
> > I wish I knew. I submitted ACPICA changes for the online capable bit
> > since I had to add additional flags on top (ie DMA coherent) and it
> > would not make sense to submit the latter without the former.
> >
> > I'd be great if the ACPICA headers can make it into Linux for the upcoming
> > merge window, not sure what I can do to fasttrack the process though
> > (I shall ping the maintainers).
> 
> If your upstream pull request has been merged, I can pick up Linux
> patches carrying Link: tags pointing to the upstream ACPICA commits in
> that pull request.

ACPICA PR was merged, sent the Linuxized version along with the GIC changes
here:

https://lore.kernel.org/lkml/20231227110038.55453-1-lpieralisi at kernel.org

Thanks,
Lorenzo


From krzysztof.kozlowski at linaro.org  Wed Dec 27 03:49:11 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 27 Dec 2023 12:49:11 +0100
Subject: [PATCH v3 1/8] dt-bindings: marvell: a38x: convert the soc
 compatibles description to yaml
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-1-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
 <20231226-support-clearfog-gtr-l8-sfp-v3-1-fd1ac2d6bf2e@solid-run.com>
Message-ID: <d105c2c5-4d36-4489-b7ac-ae8da74fa9d3@linaro.org>

On 26/12/2023 19:11, Josua Mayer wrote:
> Convert the existing txt binding for armada-38x socs to DT schema
> format.

...

> +---
> +$id: http://devicetree.org/schemas/arm/marvell/armada-38x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell Armada 38x Platforms
> +
> +maintainers:
> +  - Gregory CLEMENT <gregory.clement at bootlin.com>
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +
> +      - description: Armada 380 SoC
> +        items:
> +          - const: marvell,armada380
> +

Thanks for the conversion. I think this is still not what we want. The
main problem is of course in the original binding, not your conversion.
Compatible armada380 above alone is not correct. This is SoC and SoC
compatible cannot be used alone, because it is not specific enough to
differentiate boards. Same applies for further lists, which I removed
from the quote, for the same reasons.

What we could do here is to fix this instead of pure conversion:
1. Add this binding file with new compatibles for existing boards and
drop the TXT file, with explanation that you actually document properly
all existing board compatibles.
2. Add compatibles to existing DTS.
3. Add your new board compatibles.

At least this is what I would do for typical cases, but as I said
before, Marvell here is in some surprising limbo state.
Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 27 03:50:15 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 27 Dec 2023 12:50:15 +0100
Subject: [PATCH v3 2/8] dt-bindings: marvell: a38x: add solidrun armada
 385 clearfog gtr boards
In-Reply-To: <20231226-support-clearfog-gtr-l8-sfp-v3-2-fd1ac2d6bf2e@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
 <20231226-support-clearfog-gtr-l8-sfp-v3-2-fd1ac2d6bf2e@solid-run.com>
Message-ID: <1adf1fc6-1b9d-4174-beac-5b6b9edb4dd7@linaro.org>

On 26/12/2023 19:11, Josua Mayer wrote:
> Add DT compatible for SolidRun Armada-385 based Clearfog GTR L8 and S4
> boards.
> 
> Despite similar name these two boards are designed differently from the
> armada 388 clearfog base and pro, they only share a name and general use
> case.
> 
> Signed-off-by: Josua Mayer <josua at solid-run.com>
> ---
>  Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> index 5af222e6db18..5bc69c4fe34d 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
> @@ -30,4 +30,12 @@ properties:
>            - const: marvell,armada385
>            - const: marvell,armada380
>  
> +      - description: SolidRun Armada 385 based single-board computers
> +        items:
> +          - enum:
> +             - solidrun,clearfog-gtr-l8

When I pointed out in your previous versions that you do not test
patches, I did it in hope to encourage testing patches...

Standard boiler plate:

It does not look like you tested the bindings, at least after quick
look. Please run `make dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 27 03:54:43 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 27 Dec 2023 12:54:43 +0100
Subject: [PATCH v3 07/24] ARM: dts: samsung: exynos5420: Enable
 cros-ec-spi as wake source
In-Reply-To: <20231226122113.v3.7.I06b059021de1bf6103e60a73211f078f2af75d17@changeid>
References: <20231226192149.1830592-1-markhas@chromium.org>
 <20231226122113.v3.7.I06b059021de1bf6103e60a73211f078f2af75d17@changeid>
Message-ID: <103c1d8c-314a-457e-884d-6ad67fe65e62@linaro.org>

On 26/12/2023 20:21, Mark Hasemeyer wrote:
> The cros_ec driver currently assumes that cros-ec-spi compatible device
> nodes are a wakeup-source even though the wakeup-source property is not
> defined.
> 
> Some Chromebooks use a separate wake pin, while others overload the
> interrupt for wake and IO. With the current assumption, spurious wakes
> can occur on systems that use a separate wake pin. It is planned to
> update the driver to no longer assume that the EC interrupt pin should
> be enabled for wake.
> 
> Add the wakeup-source property to all cros-ec-spi compatible device
> nodes to signify to the driver that they should still be a valid wakeup
> source.
> 
> -Commit-changes: 3

This looks like changelog, although a bit confusing. If it is changelog,
then please keep it under ---.

I can fix it while applying, but this will be after the merge window.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 27 04:00:57 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 27 Dec 2023 13:00:57 +0100
Subject: [PATCH v6 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint
 compatible string
In-Reply-To: <ZYtLPQgMVUSNduLG@lizhi-Precision-Tower-5810>
References: <20231224183242.1675372-1-Frank.Li@nxp.com>
 <20231224183242.1675372-16-Frank.Li@nxp.com>
 <6a61f325-a58b-4aa6-9a0a-7a3086f63829@linaro.org>
 <ZYr7Y+mJea6fChjS@lizhi-Precision-Tower-5810>
 <0233cf48-93cb-4f19-ad1d-e3e1835c1fef@linaro.org>
 <ZYtLPQgMVUSNduLG@lizhi-Precision-Tower-5810>
Message-ID: <e9541a57-07de-456a-a12f-7f09482fbbc4@linaro.org>

On 26/12/2023 22:53, Frank Li wrote:
>>> DTB_CHECK report error after I remove it. linux,pci-domain is only define
>>> in pci, not pci-ep.
>>
>> Ah, thank you, indeed.
>>
>>>
>>> So I add comments about this. linux,pci-domain was resued ad controller id.
>>
>> However maybe there is reason why it is not for endpoints. The
>> description is saying it is valid only for host bridge, so maybe it
>> should not be used for endpoint case?
> 
> EP side, it is not PCI bus. So it is reasonable that linux,pci-doamin not
> in EP side.
> 
> iMX6 host driver(and other some host controller drivers) already use it as
> "controller id". EP driver is mostly reused with host bridge drivers. I
> think needn't create new property such as "controller_id" for EP only.
> 
> A comments should be enough for this case.

Hm, ok, seems fine for me. I don't know PCI good enough to judge, so
unless Rob or Conor say something else, it looks good.

Best regards,
Krzysztof



From josua at solid-run.com  Wed Dec 27 04:05:18 2023
From: josua at solid-run.com (Josua Mayer)
Date: Wed, 27 Dec 2023 12:05:18 +0000
Subject: [PATCH v3 1/8] dt-bindings: marvell: a38x: convert the soc
 compatibles description to yaml
In-Reply-To: <d105c2c5-4d36-4489-b7ac-ae8da74fa9d3@linaro.org>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
 <20231226-support-clearfog-gtr-l8-sfp-v3-1-fd1ac2d6bf2e@solid-run.com>
 <d105c2c5-4d36-4489-b7ac-ae8da74fa9d3@linaro.org>
Message-ID: <202e7469-60a4-4d8f-87e6-8932c593a877@solid-run.com>

Am 27.12.23 um 12:49 schrieb Krzysztof Kozlowski:
> On 26/12/2023 19:11, Josua Mayer wrote:
>> Convert the existing txt binding for armada-38x socs to DT schema
>> format.
> ...
>
>> +---
>> +$id: http://devicetree.org/schemas/arm/marvell/armada-38x.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Marvell Armada 38x Platforms
>> +
>> +maintainers:
>> +  - Gregory CLEMENT <gregory.clement at bootlin.com>
>> +
>> +properties:
>> +  $nodename:
>> +    const: '/'
>> +  compatible:
>> +    oneOf:
>> +
>> +      - description: Armada 380 SoC
>> +        items:
>> +          - const: marvell,armada380
>> +
> Thanks for the conversion. I think this is still not what we want. The
> main problem is of course in the original binding, not your conversion.
> Compatible armada380 above alone is not correct. This is SoC and SoC
> compatible cannot be used alone, because it is not specific enough to
> differentiate boards. Same applies for further lists, which I removed
> from the quote, for the same reasons.
>
> What we could do here is to fix this instead of pure conversion:
> 1. Add this binding file with new compatibles for existing boards and
> drop the TXT file, with explanation that you actually document properly
> all existing board compatibles.
So - we could add a boilerplate yaml with zero boards in conversion commit,
and then add new or existing boards through separate commits?

I feel that collecting / fixing the compatibles for all a38x based 
boards might be a lot of effort.
Would it be acceptable to start with the few that I know / use myself?
In addition to those already submitted I could include 
armada-388-helios4.dts.

> 2. Add compatibles to existing DTS.
For boards I do not know / using codenames - is there a template / 
generic description string?
> 3. Add your new board compatibles.
>
> At least this is what I would do for typical cases, but as I said
> before, Marvell here is in some surprising limbo state.

Thank you for the constructive notes!

> Best regards,
> Krzysztof
>


From krzysztof.kozlowski at linaro.org  Wed Dec 27 04:37:31 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 27 Dec 2023 13:37:31 +0100
Subject: [PATCH v3 1/8] dt-bindings: marvell: a38x: convert the soc
 compatibles description to yaml
In-Reply-To: <202e7469-60a4-4d8f-87e6-8932c593a877@solid-run.com>
References: <20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e@solid-run.com>
 <20231226-support-clearfog-gtr-l8-sfp-v3-1-fd1ac2d6bf2e@solid-run.com>
 <d105c2c5-4d36-4489-b7ac-ae8da74fa9d3@linaro.org>
 <202e7469-60a4-4d8f-87e6-8932c593a877@solid-run.com>
Message-ID: <2bf1c818-4a7e-4fe7-9441-471de4a8c469@linaro.org>

On 27/12/2023 13:05, Josua Mayer wrote:
>>> +      - description: Armada 380 SoC
>>> +        items:
>>> +          - const: marvell,armada380
>>> +
>> Thanks for the conversion. I think this is still not what we want. The
>> main problem is of course in the original binding, not your conversion.
>> Compatible armada380 above alone is not correct. This is SoC and SoC
>> compatible cannot be used alone, because it is not specific enough to
>> differentiate boards. Same applies for further lists, which I removed
>> from the quote, for the same reasons.
>>
>> What we could do here is to fix this instead of pure conversion:
>> 1. Add this binding file with new compatibles for existing boards and
>> drop the TXT file, with explanation that you actually document properly
>> all existing board compatibles.
> So - we could add a boilerplate yaml with zero boards in conversion commit,
> and then add new or existing boards through separate commits?

boilerplate YAML file is kind of useless. It's like writing new driver
with adding empty C file and Makefile entry. I understand you want to
split logical items, but there is no logical action as "empty binding file".

> 
> I feel that collecting / fixing the compatibles for all a38x based 
> boards might be a lot of effort.
> Would it be acceptable to start with the few that I know / use myself?
> In addition to those already submitted I could include 
> armada-388-helios4.dts.

Yes, it's fine.

> 
>> 2. Add compatibles to existing DTS.
> For boards I do not know / using codenames - is there a template / 
> generic description string?
>> 3. Add your new board compatibles.
>>
>> At least this is what I would do for typical cases, but as I said
>> before, Marvell here is in some surprising limbo state.
> 
Best regards,
Krzysztof



From tudor.ambarus at linaro.org  Wed Dec 27 04:38:21 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Wed, 27 Dec 2023 12:38:21 +0000
Subject: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0
 clock management unit
In-Reply-To: <173b06ab-2518-49ee-a67f-85256bc5b6a7@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-3-tudor.ambarus@linaro.org>
 <20231220150726.GA223267-robh@kernel.org>
 <173b06ab-2518-49ee-a67f-85256bc5b6a7@linaro.org>
Message-ID: <425a228e-b2d3-4b19-9bcb-6ee1a90cd2ef@linaro.org>

Hi, Rob,

On 12/21/23 07:20, Tudor Ambarus wrote:
> 
> 
> On 12/20/23 15:07, Rob Herring wrote:
>> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>>> clock management unit.
>>>
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>>> ---
>>>  .../bindings/clock/google,gs101-clock.yaml    | 25 +++++-
>>>  include/dt-bindings/clock/google,gs101.h      | 86 +++++++++++++++++++
>>>  2 files changed, 109 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>> index 3eebc03a309b..ba54c13c55bc 100644
>>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>> @@ -30,14 +30,15 @@ properties:
>>>        - google,gs101-cmu-top
>>>        - google,gs101-cmu-apm
>>>        - google,gs101-cmu-misc
>>> +      - google,gs101-cmu-peric0
>>>  
>>>    clocks:
>>>      minItems: 1
>>> -    maxItems: 2
>>> +    maxItems: 3
>>>  
>>>    clock-names:
>>>      minItems: 1
>>> -    maxItems: 2
>>> +    maxItems: 3
>>>  
>>>    "#clock-cells":
>>>      const: 1
>>> @@ -88,6 +89,26 @@ allOf:
>>>              - const: dout_cmu_misc_bus
>>>              - const: dout_cmu_misc_sss
>>>  
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            const: google,gs101-cmu-peric0
>>> +
>>> +    then:
>>> +      properties:
>>> +        clocks:
>>> +          items:
>>> +            - description: External reference clock (24.576 MHz)
>>> +            - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>>> +            - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>>> +
>>> +        clock-names:
>>> +          items:
>>> +            - const: oscclk
>>> +            - const: dout_cmu_peric0_bus
>>> +            - const: dout_cmu_peric0_ip
>>
>> 'bus' and 'ip' are sufficient because naming is local to the module. The 
>> same is true on 'dout_cmu_misc_bus'. As that has not made a release, 
>> please fix all of them.
>>
> 
> Ok, will fix them shortly. Thanks, Rob!

I tried your suggestion at
https://lore.kernel.org/linux-arm-kernel/c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f at linaro.org/

and we noticed that we'd have to update the clock driver as well.
These CMUs set the DT clock-name of the parent clock in the driver in
struct samsung_cmu_info::clk_name[]. The driver then tries to enable the
parent clock based on the clock-name in exynos_arm64_register_cmu().

In order to enable the parent clock of the CMU the following would be
needed in the driver:

diff --git a/drivers/clk/samsung/clk-gs101.c
b/drivers/clk/samsung/clk-gs101.c
index 68a27b78b00b..e91836ea3a98 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -2476,7 +2476,7 @@ static const struct samsung_cmu_info misc_cmu_info
__initconst = {
        .nr_clk_ids             = CLKS_NR_MISC,
        .clk_regs               = misc_clk_regs,
        .nr_clk_regs            = ARRAY_SIZE(misc_clk_regs),
-       .clk_name               = "dout_cmu_misc_bus",
+       .clk_name               = "bus",
 };

I think I lean towards keeping the name as it was because it's clearer
what are the clock dependencies in the driver. "dout_cmu_misc_bus" is
the clock name used when defining the clock:
DIV(CLK_DOUT_CMU_MISC_BUS, "dout_cmu_misc_bus", "gout_cmu_misc_bus",
    CLK_CON_DIV_CLKCMU_MISC_BUS, 0, 4),
The other exynos clock drivers are using too the driver's clock names
for the clock-names device tree property. For consistency I'd keep it
the same.

If you have a stronger opinion than mine, please tell and I'll happily
update the driver.

Thanks,
ta


From krzysztof.kozlowski at linaro.org  Wed Dec 27 04:38:51 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 27 Dec 2023 13:38:51 +0100
Subject: [PATCH 2/4] dt-bindings: mmc: add Marvell ac5
In-Reply-To: <20231227123257.1170590-3-enachman@marvell.com>
References: <20231227123257.1170590-1-enachman@marvell.com>
 <20231227123257.1170590-3-enachman@marvell.com>
Message-ID: <6ff67469-2522-425a-a96a-25460e38beda@linaro.org>

On 27/12/2023 13:32, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> Add dt bindings for Marvell ac5 eMMC controller
> 
> Signed-off-by: Elad Nachman <enachman at marvell.com>
> ---
>  Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml
> index 3a8e74894ae0..50c6de8bf0bc 100644
> --- a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml
> @@ -34,6 +34,9 @@ properties:
>            - const: marvell,armada-3700-sdhci
>            - const: marvell,sdhci-xenon
>  
> +      - items:
> +          - const: marvell,ac5-sdhci

Please make earlier const as enum and add it there.

> +          - const: marvell,armada-ap806-sdhci

You also missed here blank line, but that won't matter after above change.


Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 27 04:40:59 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 27 Dec 2023 13:40:59 +0100
Subject: [PATCH 3/4] arm64: dts: ac5: add mmc node and clock
In-Reply-To: <20231227123257.1170590-4-enachman@marvell.com>
References: <20231227123257.1170590-1-enachman@marvell.com>
 <20231227123257.1170590-4-enachman@marvell.com>
Message-ID: <75fd794c-0366-445b-aa69-0975afb247c7@linaro.org>

On 27/12/2023 13:32, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> Add mmc and mmc clock nodes to ac5 and ac5x device tree files
> 
> Signed-off-by: Elad Nachman <enachman at marvell.com>
> ---
>  arch/arm64/boot/dts/marvell/ac5-98dx25xx.dtsi | 33 ++++++++++++++++++-
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/marvell/ac5-98dx25xx.dtsi b/arch/arm64/boot/dts/marvell/ac5-98dx25xx.dtsi
> index b5e042b8e929..decad14d0db8 100644
> --- a/arch/arm64/boot/dts/marvell/ac5-98dx25xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/ac5-98dx25xx.dtsi
> @@ -77,7 +77,6 @@ soc {
>  		#address-cells = <2>;
>  		#size-cells = <2>;
>  		ranges;
> -		dma-ranges;
>  
>  		internal-regs at 7f000000 {
>  			#address-cells = <1>;
> @@ -204,6 +203,31 @@ gpio1: gpio at 18140 {
>  			};
>  		};
>  
> +		mmc_dma: mmc-dma-peripherals at 80500000 {

Generic node name, so bus@?

> +				compatible = "simple-bus";
> +				#address-cells = <0x2>;
> +				#size-cells = <0x2>;
> +				ranges;

ranges is second.

You have address/size cells, so are you sure dtbs W=1 does not complain?


> +				dma-ranges = <0x0 0x0 0x2 0x0 0x0 0x80000000>;
> +				dma-coherent;
> +
> +				sdhci: mmc at 805c0000 {
> +					compatible = "marvell,ac5-sdhci",
> +						     "marvell,armada-ap806-sdhci";
> +					reg = <0x0 0x805c0000 0x0 0x1000>;
> +					interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
> +					clocks = <&emmc_clock>, <&cnm_clock>;
> +					clock-names = "core", "axi";
> +					status = "okay";

Drop

> +					bus-width = <8>;
> +					/*marvell,xenon-phy-slow-mode;*/

Drop or explain why commented code should be here.

> +					non-removable;
> +					mmc-ddr-1_8v;
> +					mmc-hs200-1_8v;
> +					mmc-hs400-1_8v;
> +				};
> +		};
> +
>  		/*
>  		 * Dedicated section for devices behind 32bit controllers so we
>  		 * can configure specific DMA mapping for them
> @@ -335,5 +359,12 @@ nand_clock: nand-clock {
>  			#clock-cells = <0>;
>  			clock-frequency = <400000000>;
>  		};
> +
> +		emmc_clock: emmc_clock {

No underscores in node names. I think you got such feedback before.

But anyway, this looks like a fake clock.

> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-frequency = <400000000>;
> +		};
> +

Drop

>  	};
>  };

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 27 04:41:56 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Wed, 27 Dec 2023 13:41:56 +0100
Subject: [PATCH 2/4] dt-bindings: mmc: add Marvell ac5
In-Reply-To: <20231227123257.1170590-3-enachman@marvell.com>
References: <20231227123257.1170590-1-enachman@marvell.com>
 <20231227123257.1170590-3-enachman@marvell.com>
Message-ID: <80568ab6-da4c-408c-b628-fa399aedefc2@linaro.org>

On 27/12/2023 13:32, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> Add dt bindings for Marvell ac5 eMMC controller

Driver change says it is not fully compatible. Your commit msg here
explains nothing, except what subject is saying. You have entire commit
msg to explain such cases.


Best regards,
Krzysztof



From eugen.hristev at collabora.com  Wed Dec 27 05:08:11 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Wed, 27 Dec 2023 15:08:11 +0200
Subject: [PATCH 1/2] dt-bindings: media: mediatek-jpeg-encoder: change max ioomus count
Message-ID: <20231227130812.148914-1-eugen.hristev@collabora.com>

MT8186 has 4 iommus in the list, to cope with this situation, adjust
the maxItems to 4 (instead of previous 2).
Add also minItems as 1 since iommus are mandatory, to avoid warning
on the example.

Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
 .../devicetree/bindings/media/mediatek-jpeg-encoder.yaml       | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 37800e1908cc..60c75b9312e8 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -38,7 +38,8 @@ properties:
     maxItems: 1
 
   iommus:
-    maxItems: 2
+    minItems: 1
+    maxItems: 4
     description: |
       Points to the respective IOMMU block with master port as argument, see
       Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
-- 
2.34.1



From eugen.hristev at collabora.com  Wed Dec 27 05:08:12 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Wed, 27 Dec 2023 15:08:12 +0200
Subject: [PATCH 2/2] arm64: dts: mediatek: mt8186: Add jpgenc node
In-Reply-To: <20231227130812.148914-1-eugen.hristev@collabora.com>
References: <20231227130812.148914-1-eugen.hristev@collabora.com>
Message-ID: <20231227130812.148914-2-eugen.hristev@collabora.com>

From: Allen-KH Cheng <allen-kh.cheng at mediatek.com>

Add JPEG encoder node.

Signed-off-by: Allen-KH Cheng <allen-kh.cheng at mediatek.com>
Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Max Staudt <mstaudt at chromium.org>
Tested-by: Max Staudt <mstaudt at chromium.org>
Reviewed-by: Ricardo Ribalda <ribalda at chromium.org>
[eugen.hristev at collabora.com: minor cleanup]
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index e451b6c8cd9e..ef1b269f9184 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -2054,6 +2054,19 @@ venc: video-encoder at 17020000 {
 			mediatek,scp = <&scp>;
 		};
 
+		jpgenc: jpgenc at 17030000 {
+			compatible = "mediatek,mt8186-jpgenc", "mediatek,mtk-jpgenc";
+			reg = <0 0x17030000 0 0x10000>;
+			interrupts = <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks = <&vencsys CLK_VENC_CKE2_JPGENC>;
+			clock-names = "jpgenc";
+			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
+			iommus = <&iommu_mm IOMMU_PORT_L7_JPGENC_Y_RDMA>,
+				 <&iommu_mm IOMMU_PORT_L7_JPGENC_C_RDMA>,
+				 <&iommu_mm IOMMU_PORT_L7_JPGENC_Q_TABLE>,
+				 <&iommu_mm IOMMU_PORT_L7_JPGENC_BSDMA>;
+		};
+
 		camsys: clock-controller at 1a000000 {
 			compatible = "mediatek,mt8186-camsys";
 			reg = <0 0x1a000000 0 0x1000>;
-- 
2.34.1



From daniel.lezcano at linaro.org  Wed Dec 27 05:25:26 2023
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 27 Dec 2023 14:25:26 +0100
Subject: [PATCH v1] thermal: sun8i: extend H6 calibration function to
 support 4 sensors
In-Reply-To: <20231218111404.5f08a4c4@donnerap.manchester.arm.com>
References: <20231217133637.54773-1-bigunclemax@gmail.com>
 <20231218111404.5f08a4c4@donnerap.manchester.arm.com>
Message-ID: <20231227132509.GA4121@linaro.org>

On Mon, Dec 18, 2023 at 11:14:04AM +0000, Andre Przywara wrote:

[ ... ]

> I will incorporate this patch into the next submission of the H616 THS
> series, so there is no need to merge this patch as is.

Noted, thanks

  -- Daniel

[ ... ]
-- 

 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


From vigneshr at ti.com  Wed Dec 27 05:59:01 2023
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Wed, 27 Dec 2023 19:29:01 +0530
Subject: [PATCH] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0
In-Reply-To: <20230912111215.18415-1-tony@atomide.com>
References: <20230912111215.18415-1-tony@atomide.com>
Message-ID: <170368552643.1332094.7883858507182654481.b4-ty@ti.com>


On Tue, 12 Sep 2023 14:12:15 +0300, Tony Lindgren wrote:
> The devices in the wkup domain are capable of waking up the system from
> suspend. We can configure the wkup domain devices in a generic way using
> the ti-sysc interconnect target module driver like we have done with the
> earlier TI SoCs.
> 
> As ti-sysc manages the SYSCONFIG related registers independent of the
> child hardware device, the wake-up configuration is also set even if
> wkup_uart0 is reserved by sysfw.
> 
> [...]

Applied, thanks!

[1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0
      commit: 86224524b52a8efba26f920736d08c8bfdd22d87

Best regards,
-- 
Vignesh



From daniel.lezcano at linaro.org  Wed Dec 27 06:35:46 2023
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 27 Dec 2023 15:35:46 +0100
Subject: [PATCH] clocksource/drivers/imx: Fix -Wunused-but-set-variable warning
Message-ID: <20231227143546.2823683-1-daniel.lezcano@linaro.org>

All warnings (new ones prefixed by >>):

   drivers/clocksource/timer-imx-gpt.c: In function 'mxc_timer_interrupt':
>> drivers/clocksource/timer-imx-gpt.c:279:18: warning: variable 'tstat' set but not used [-Wunused-but-set-variable]
     279 |         uint32_t tstat;
         |                  ^~~~~

vim +/tstat +279 drivers/clocksource/timer-imx-gpt.c

The change remove the tstats assignment but not the reading of the
register, assuming the register may be a ROR (Reset On Read) which
happens in the driver's interrupt registers.

Fixes: df181e382816 ("clocksource/drivers/imx-gpt: Add support for ARM64")
Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312231803.XzPddRa5-lkp at intel.com/
Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/clocksource/timer-imx-gpt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/clocksource/timer-imx-gpt.c b/drivers/clocksource/timer-imx-gpt.c
index 6a878d227a13..489e69169ed4 100644
--- a/drivers/clocksource/timer-imx-gpt.c
+++ b/drivers/clocksource/timer-imx-gpt.c
@@ -258,9 +258,8 @@ static irqreturn_t mxc_timer_interrupt(int irq, void *dev_id)
 {
 	struct clock_event_device *ced = dev_id;
 	struct imx_timer *imxtm = to_imx_timer(ced);
-	uint32_t tstat;
 
-	tstat = readl_relaxed(imxtm->base + imxtm->gpt->reg_tstat);
+	readl_relaxed(imxtm->base + imxtm->gpt->reg_tstat);
 
 	imxtm->gpt->gpt_irq_acknowledge(imxtm);
 
-- 
2.34.1



From baruch at tkos.co.il  Wed Dec 27 07:04:26 2023
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 27 Dec 2023 17:04:26 +0200
Subject: [PATCH RFC 2/4] of: unittest: add test for of_dma_get_cpu_limits() 'min' param
In-Reply-To: <cover.1703683642.git.baruch@tkos.co.il>
References: <cover.1703683642.git.baruch@tkos.co.il>
Message-ID: <9704923d06839d92f4ef6fb28523b0f47e154df4.1703683642.git.baruch@tkos.co.il>

Verify that of_dma_get_cpu_limits() sets this new parameter to the
expected result.

Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 drivers/of/unittest.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 21d273a05ba6..d3b2c6ca56cd 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -911,7 +911,7 @@ static void __init of_unittest_changeset(void)
 static void __init of_unittest_dma_get_cpu_limits(void)
 {
 	struct device_node *np;
-	phys_addr_t cpu_addr;
+	phys_addr_t cpu_addr_max, cpu_addr_min;
 
 	if (!IS_ENABLED(CONFIG_OF_ADDRESS))
 		return;
@@ -922,10 +922,13 @@ static void __init of_unittest_dma_get_cpu_limits(void)
 		return;
 	}
 
-	of_dma_get_cpu_limits(np, &cpu_addr, NULL);
-	unittest(cpu_addr == 0x4fffffff,
-		 "of_dma_get_cpu_limits: wrong CPU addr %pad (expecting %x)\n",
-		 &cpu_addr, 0x4fffffff);
+	of_dma_get_cpu_limits(np, &cpu_addr_max, &cpu_addr_min);
+	unittest(cpu_addr_max == 0x4fffffff,
+		 "of_dma_get_cpu_limits: wrong CPU max addr %pad (expecting %x)\n",
+		 &cpu_addr_max, 0x4fffffff);
+	unittest(cpu_addr_min == 0x40000000,
+		 "of_dma_get_cpu_limits: wrong CPU min addr %pad (expecting %x)\n",
+		 &cpu_addr_min, 0x40000000);
 }
 
 static void __init of_unittest_dma_ranges_one(const char *path,
-- 
2.43.0



From baruch at tkos.co.il  Wed Dec 27 07:04:24 2023
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 27 Dec 2023 17:04:24 +0200
Subject: [PATCH RFC 0/4] arm64: support DMA zone starting above 4GB
Message-ID: <cover.1703683642.git.baruch@tkos.co.il>

DMA zones code assumes that DMA lower limit is zero. When there is no RAM 
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire 
RAM[0].

The platform I have has RAM starting at 32GB. Devices with 30-bit DMA mask are 
mapped to 1GB at the bottom of RAM, between 32GB - 33GB. A DMA zone over the 
entire RAM breaks DMA allocation for these devices.

In response to a previous RFC hack[1] Catalin Marinas suggested to add a
separate offset value as base address for the DMA zone. This RFC series 
attempts to implement that suggestion.

With this series applied, the DMA zone covers the right RAM range for my 
platform.

[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the 
    max_zone_phys() calculation")

[1] https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.baruch at tkos.co.il/

Baruch Siach (4):
  of: get dma area lower limit
  of: unittest: add test for of_dma_get_cpu_limits() 'min' param
  dma-direct: add offset to zone_dma_bits
  arm64: mm: take DMA zone offset into account

 arch/arm64/mm/init.c       | 18 +++++++++++++-----
 drivers/of/address.c       | 38 +++++++++++++++++++++++++++-----------
 drivers/of/unittest.c      | 17 ++++++++++-------
 include/linux/dma-direct.h |  1 +
 include/linux/of.h         | 11 ++++++++---
 kernel/dma/direct.c        | 10 ++++++----
 kernel/dma/pool.c          |  2 +-
 kernel/dma/swiotlb.c       |  5 +++--
 8 files changed, 69 insertions(+), 33 deletions(-)

-- 
2.43.0



From baruch at tkos.co.il  Wed Dec 27 07:04:27 2023
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 27 Dec 2023 17:04:27 +0200
Subject: [PATCH RFC 3/4] dma-direct: add offset to zone_dma_bits
In-Reply-To: <cover.1703683642.git.baruch@tkos.co.il>
References: <cover.1703683642.git.baruch@tkos.co.il>
Message-ID: <fae5b1180161a7d8cd626a96f5df80b0a0796b8b.1703683642.git.baruch@tkos.co.il>

Current code using zone_dma_bits assume that all addresses range in the
bits mask are suitable for DMA. For some existing platforms this
assumption is not correct. DMA range might have non zero lower limit.

Add 'zone_dma_off' for platform code to set base address for DMA zone.

Rename the dma_direct_supported() local 'min_mask' variable to better
describe its use as limit.

Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 include/linux/dma-direct.h |  1 +
 kernel/dma/direct.c        | 10 ++++++----
 kernel/dma/pool.c          |  2 +-
 kernel/dma/swiotlb.c       |  5 +++--
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 18aade195884..77c52019c1ff 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -13,6 +13,7 @@
 #include <linux/swiotlb.h>
 
 extern unsigned int zone_dma_bits;
+extern phys_addr_t zone_dma_off;
 
 /*
  * Record the mapping of CPU physical to DMA addresses for a given region.
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 73c95815789a..7a54fa71a174 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -21,6 +21,7 @@
  * override the variable below for dma-direct to work properly.
  */
 unsigned int zone_dma_bits __ro_after_init = 24;
+phys_addr_t zone_dma_off __ro_after_init;
 
 static inline dma_addr_t phys_to_dma_direct(struct device *dev,
 		phys_addr_t phys)
@@ -59,7 +60,7 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev, u64 *phys_limit)
 	 * zones.
 	 */
 	*phys_limit = dma_to_phys(dev, dma_limit);
-	if (*phys_limit <= DMA_BIT_MASK(zone_dma_bits))
+	if (*phys_limit <= zone_dma_off + DMA_BIT_MASK(zone_dma_bits))
 		return GFP_DMA;
 	if (*phys_limit <= DMA_BIT_MASK(32))
 		return GFP_DMA32;
@@ -566,7 +567,7 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
 
 int dma_direct_supported(struct device *dev, u64 mask)
 {
-	u64 min_mask = (max_pfn - 1) << PAGE_SHIFT;
+	u64 min_limit = (max_pfn - 1) << PAGE_SHIFT;
 
 	/*
 	 * Because 32-bit DMA masks are so common we expect every architecture
@@ -583,8 +584,9 @@ int dma_direct_supported(struct device *dev, u64 mask)
 	 * part of the check.
 	 */
 	if (IS_ENABLED(CONFIG_ZONE_DMA))
-		min_mask = min_t(u64, min_mask, DMA_BIT_MASK(zone_dma_bits));
-	return mask >= phys_to_dma_unencrypted(dev, min_mask);
+		min_limit = min_t(u64, min_limit,
+				zone_dma_off + DMA_BIT_MASK(zone_dma_bits));
+	return mask >= phys_to_dma_unencrypted(dev, min_limit);
 }
 
 /*
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index b481c48a31a6..0103e932444d 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -70,7 +70,7 @@ static bool cma_in_zone(gfp_t gfp)
 	/* CMA can't cross zone boundaries, see cma_activate_area() */
 	end = cma_get_base(cma) + size - 1;
 	if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
-		return end <= DMA_BIT_MASK(zone_dma_bits);
+		return end <= zone_dma_off + DMA_BIT_MASK(zone_dma_bits);
 	if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32))
 		return end <= DMA_BIT_MASK(32);
 	return true;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 33d942615be5..bd3071894d2b 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -446,7 +446,8 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
 	if (!remap)
 		io_tlb_default_mem.can_grow = true;
 	if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp_mask & __GFP_DMA))
-		io_tlb_default_mem.phys_limit = DMA_BIT_MASK(zone_dma_bits);
+		io_tlb_default_mem.phys_limit =
+			zone_dma_off + DMA_BIT_MASK(zone_dma_bits);
 	else if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp_mask & __GFP_DMA32))
 		io_tlb_default_mem.phys_limit = DMA_BIT_MASK(32);
 	else
@@ -625,7 +626,7 @@ static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
 	}
 
 	gfp &= ~GFP_ZONEMASK;
-	if (phys_limit <= DMA_BIT_MASK(zone_dma_bits))
+	if (phys_limit <= zone_dma_off + DMA_BIT_MASK(zone_dma_bits))
 		gfp |= __GFP_DMA;
 	else if (phys_limit <= DMA_BIT_MASK(32))
 		gfp |= __GFP_DMA32;
-- 
2.43.0



From baruch at tkos.co.il  Wed Dec 27 07:04:28 2023
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 27 Dec 2023 17:04:28 +0200
Subject: [PATCH RFC 4/4] arm64: mm: take DMA zone offset into account
In-Reply-To: <cover.1703683642.git.baruch@tkos.co.il>
References: <cover.1703683642.git.baruch@tkos.co.il>
Message-ID: <c6dbd432196c4ba5f390845db14b1a422cc77d4c.1703683642.git.baruch@tkos.co.il>

Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made DMA/DMA32 zones span the entire RAM
when RAM starts above 32-bits. This breaks hardware with DMA area that
start above 32-bits. But the commit log says that "we haven't noticed
any such hardware". It turns out that such hardware does exist.

One such platform has RAM starting at 32GB with an internal bus that has
the following DMA limits:

  #address-cells = <2>;
  #size-cells = <2>;
  dma-ranges = <0x00 0xc0000000 0x08 0x00000000 0x00 0x40000000>;

Devices under this bus can see 1GB of DMA range between 3GB-4GB in each
device address space. This range is mapped to CPU memory at 32GB-33GB.
With current code DMA allocations for devices under this bus are not
limited to DMA area, leading to run-time allocation failure.

Modify 'zone_dma_bits' calculation (via dt_zone_dma_bits) to only cover
the actual DMA area starting at 'zone_dma_off'. Use the newly introduced
'min' parameter of of_dma_get_cpu_limits() to set 'zone_dma_off'.

DMA32 zone is useless in this configuration, so make its limit the same
as the DMA zone when the lower DMA limit is higher than 32-bits.

The result is DMA zone that properly reflects the hardware constraints
as follows:

[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000800000000-0x000000083fffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000000840000000-0x0000000bffffffff]

Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 arch/arm64/mm/init.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index d6c723ae6fb0..4a8fd8394ce6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -118,10 +118,11 @@ static void __init arch_reserve_crashkernel(void)
  * limit. If DRAM starts above 32-bit, expand the zone to the maximum
  * available memory, otherwise cap it at 32-bit.
  */
-static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
+static phys_addr_t __init max_zone_phys(unsigned int zone_bits,
+		phys_addr_t zone_off)
 {
 	phys_addr_t zone_mask = DMA_BIT_MASK(zone_bits);
-	phys_addr_t phys_start = memblock_start_of_DRAM();
+	phys_addr_t phys_start = memblock_start_of_DRAM() - zone_off;
 
 	if (phys_start > U32_MAX)
 		zone_mask = PHYS_ADDR_MAX;
@@ -137,14 +138,19 @@ static void __init zone_sizes_init(void)
 	unsigned int __maybe_unused acpi_zone_dma_bits;
 	unsigned int __maybe_unused dt_zone_dma_bits;
 	phys_addr_t __maybe_unused max_cpu_address;
-	phys_addr_t __maybe_unused dma32_phys_limit = max_zone_phys(32);
+	phys_addr_t __maybe_unused min_cpu_address;
+	phys_addr_t __maybe_unused dma32_phys_limit = max_zone_phys(32, 0);
 
 #ifdef CONFIG_ZONE_DMA
 	acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
-	of_dma_get_cpu_limits(NULL, &max_cpu_address, NULL);
-	dt_zone_dma_bits = fls64(max_cpu_address);
+	of_dma_get_cpu_limits(NULL, &max_cpu_address, &min_cpu_address);
+	dt_zone_dma_bits = fls64(max_cpu_address - min_cpu_address);
 	zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
-	arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+	zone_dma_off = min_cpu_address;
+	arm64_dma_phys_limit = max_zone_phys(zone_dma_bits, zone_dma_off)
+		+ zone_dma_off;
+	if (zone_dma_off > U32_MAX)
+		dma32_phys_limit = arm64_dma_phys_limit;
 	max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
 #endif
 #ifdef CONFIG_ZONE_DMA32
-- 
2.43.0



From baruch at tkos.co.il  Wed Dec 27 07:04:25 2023
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 27 Dec 2023 17:04:25 +0200
Subject: [PATCH RFC 1/4] of: get dma area lower limit
In-Reply-To: <cover.1703683642.git.baruch@tkos.co.il>
References: <cover.1703683642.git.baruch@tkos.co.il>
Message-ID: <be71fbb0963584b8c401423d9dd2fba2511bd5b4.1703683642.git.baruch@tkos.co.il>

of_dma_get_max_cpu_address() returns the highest CPU address that
devices can use for DMA. The implicit assumption is that all CPU
addresses below that limit are suitable for DMA. However the
'dma-ranges' property this code uses also encodes a lower limit for DMA
that is potentially non zero.

Rename to of_dma_get_cpu_limits(), and extend to retrieve also the lower
limit for the same 'dma-ranges' property describing the high limit.

Update callers of of_dma_get_max_cpu_address(). No functional change
intended.

Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 arch/arm64/mm/init.c  |  4 +++-
 drivers/of/address.c  | 38 +++++++++++++++++++++++++++-----------
 drivers/of/unittest.c |  8 ++++----
 include/linux/of.h    | 11 ++++++++---
 4 files changed, 42 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 74c1db8ce271..d6c723ae6fb0 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -136,11 +136,13 @@ static void __init zone_sizes_init(void)
 	unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
 	unsigned int __maybe_unused acpi_zone_dma_bits;
 	unsigned int __maybe_unused dt_zone_dma_bits;
+	phys_addr_t __maybe_unused max_cpu_address;
 	phys_addr_t __maybe_unused dma32_phys_limit = max_zone_phys(32);
 
 #ifdef CONFIG_ZONE_DMA
 	acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
-	dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
+	of_dma_get_cpu_limits(NULL, &max_cpu_address, NULL);
+	dt_zone_dma_bits = fls64(max_cpu_address);
 	zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
 	arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
 	max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
diff --git a/drivers/of/address.c b/drivers/of/address.c
index b59956310f66..51fa52bbe911 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -965,21 +965,25 @@ int of_dma_get_range(struct device_node *np, const struct bus_dma_region **map)
 #endif /* CONFIG_HAS_DMA */
 
 /**
- * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
+ * of_dma_get_cpu_limits - Gets highest CPU address suitable for DMA
  * @np: The node to start searching from or NULL to start from the root
+ * @max: Pointer to high address limit or NULL if not needed
+ * @min: Pointer to low address limit or NULL if not needed
  *
  * Gets the highest CPU physical address that is addressable by all DMA masters
- * in the sub-tree pointed by np, or the whole tree if NULL is passed. If no
- * DMA constrained device is found, it returns PHYS_ADDR_MAX.
+ * in the sub-tree pointed by np, or the whole tree if @np in NULL. If no
+ * DMA constrained device is found, @*max is PHYS_ADDR_MAX, and @*low is 0.
  */
-phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
+void __init of_dma_get_cpu_limits(struct device_node *np,
+		phys_addr_t *max, phys_addr_t *min)
 {
 	phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
 	struct of_range_parser parser;
-	phys_addr_t subtree_max_addr;
+	phys_addr_t min_cpu_addr = 0;
 	struct device_node *child;
 	struct of_range range;
 	const __be32 *ranges;
+	u64 cpu_start = 0;
 	u64 cpu_end = 0;
 	int len;
 
@@ -989,21 +993,33 @@ phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
 	ranges = of_get_property(np, "dma-ranges", &len);
 	if (ranges && len) {
 		of_dma_range_parser_init(&parser, np);
-		for_each_of_range(&parser, &range)
-			if (range.cpu_addr + range.size > cpu_end)
+		for_each_of_range(&parser, &range) {
+			if (range.cpu_addr + range.size > cpu_end) {
 				cpu_end = range.cpu_addr + range.size - 1;
+				cpu_start = range.cpu_addr;
+			}
+		}
 
-		if (max_cpu_addr > cpu_end)
+		if (max_cpu_addr > cpu_end) {
 			max_cpu_addr = cpu_end;
+			min_cpu_addr = cpu_start;
+		}
 	}
 
 	for_each_available_child_of_node(np, child) {
-		subtree_max_addr = of_dma_get_max_cpu_address(child);
-		if (max_cpu_addr > subtree_max_addr)
+		phys_addr_t subtree_max_addr, subtree_min_addr;
+
+		of_dma_get_cpu_limits(child, &subtree_max_addr, &subtree_min_addr);
+		if (max_cpu_addr > subtree_max_addr) {
 			max_cpu_addr = subtree_max_addr;
+			min_cpu_addr = subtree_min_addr;
+		}
 	}
 
-	return max_cpu_addr;
+	if (max)
+		*max = max_cpu_addr;
+	if (min)
+		*min = min_cpu_addr;
 }
 
 /**
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index e9e90e96600e..21d273a05ba6 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -908,7 +908,7 @@ static void __init of_unittest_changeset(void)
 #endif
 }
 
-static void __init of_unittest_dma_get_max_cpu_address(void)
+static void __init of_unittest_dma_get_cpu_limits(void)
 {
 	struct device_node *np;
 	phys_addr_t cpu_addr;
@@ -922,9 +922,9 @@ static void __init of_unittest_dma_get_max_cpu_address(void)
 		return;
 	}
 
-	cpu_addr = of_dma_get_max_cpu_address(np);
+	of_dma_get_cpu_limits(np, &cpu_addr, NULL);
 	unittest(cpu_addr == 0x4fffffff,
-		 "of_dma_get_max_cpu_address: wrong CPU addr %pad (expecting %x)\n",
+		 "of_dma_get_cpu_limits: wrong CPU addr %pad (expecting %x)\n",
 		 &cpu_addr, 0x4fffffff);
 }
 
@@ -4104,7 +4104,7 @@ static int __init of_unittest(void)
 	of_unittest_changeset();
 	of_unittest_parse_interrupts();
 	of_unittest_parse_interrupts_extended();
-	of_unittest_dma_get_max_cpu_address();
+	of_unittest_dma_get_cpu_limits();
 	of_unittest_parse_dma_ranges();
 	of_unittest_pci_dma_ranges();
 	of_unittest_bus_ranges();
diff --git a/include/linux/of.h b/include/linux/of.h
index 6a9ddf20e79a..629b402d81bf 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -445,7 +445,8 @@ int of_map_id(struct device_node *np, u32 id,
 	       const char *map_name, const char *map_mask_name,
 	       struct device_node **target, u32 *id_out);
 
-phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
+void of_dma_get_cpu_limits(struct device_node *np, phys_addr_t *max,
+		phys_addr_t *min);
 
 struct kimage;
 void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
@@ -865,9 +866,13 @@ static inline int of_map_id(struct device_node *np, u32 id,
 	return -EINVAL;
 }
 
-static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np)
+static inline void of_dma_get_cpu_limits(struct device_node *np,
+		phys_addr_t *max, phys_addr_t *min)
 {
-	return PHYS_ADDR_MAX;
+	if (max)
+		*max = PHYS_ADDR_MAX;
+	if (min)
+		*min = 0;
 }
 
 static inline const void *of_device_get_match_data(const struct device *dev)
-- 
2.43.0



From vigneshr at ti.com  Wed Dec 27 07:22:04 2023
From: vigneshr at ti.com (Raghavendra, Vignesh)
Date: Wed, 27 Dec 2023 20:52:04 +0530
Subject: [PATCH] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for
 wkup_uart0
In-Reply-To: <170368552643.1332094.7883858507182654481.b4-ty@ti.com>
References: <20230912111215.18415-1-tony@atomide.com>
 <170368552643.1332094.7883858507182654481.b4-ty@ti.com>
Message-ID: <e28a4f16-f9a8-499a-a6a3-7acef0e0aa10@ti.com>



On 12/27/2023 7:29 PM, Vignesh Raghavendra wrote:
> 
> On Tue, 12 Sep 2023 14:12:15 +0300, Tony Lindgren wrote:
>> The devices in the wkup domain are capable of waking up the system from
>> suspend. We can configure the wkup domain devices in a generic way using
>> the ti-sysc interconnect target module driver like we have done with the
>> earlier TI SoCs.
>>
>> As ti-sysc manages the SYSCONFIG related registers independent of the
>> child hardware device, the wake-up configuration is also set even if
>> wkup_uart0 is reserved by sysfw.
>>
>> [...]
> 
> Applied, thanks!
> 
> [1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0
>       commit: 86224524b52a8efba26f920736d08c8bfdd22d87
> 


Please ignore above. I meant to pick v4. Sorry for the noise!

Regards
Vignesh


From jgg at nvidia.com  Wed Dec 27 07:33:14 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 27 Dec 2023 11:33:14 -0400
Subject: [PATCH 04/19] iommu/arm-smmu-v3: Make STE programming
 independent of the callers
In-Reply-To: <CAKHBV26kVYoXP-vNtQMhv3fBDYSmSCG5AU8eyU=D6fWUV1BCBQ@mail.gmail.com>
References: <20231018130455.GU3952@nvidia.com>
 <CAKHBV270uJjdj4zeK-NNt+j3TiqoGDdLUQ5uRrLw9PN0ysCDbw@mail.gmail.com>
 <20231020113918.GD3952@nvidia.com>
 <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
 <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com>
 <ZX7xu8jN/rBZ4A/d@nvidia.com>
 <CAKHBV26CRC8eWMuOk6EZYMHOZoR2FauP=NBazzOiWCmQYEa1vg@mail.gmail.com>
 <CAKHBV27qsgjgwPfn8OpSq30z1w203NDqBZ0s66bPgjp1XDnLOg@mail.gmail.com>
 <CAKHBV24ApTjc3hy-kbMD9Y7wVdb5OPTb8bU6AkZdCQPg+LWDSg@mail.gmail.com>
 <CAKHBV26kVYoXP-vNtQMhv3fBDYSmSCG5AU8eyU=D6fWUV1BCBQ@mail.gmail.com>
Message-ID: <20231227153314.GA50406@nvidia.com>

On Mon, Dec 25, 2023 at 08:58:06PM +0800, Michael Shavit wrote:
> Ok I'm probably getting ahead of myself here, but on an nth re-read to
> sanity check things I realized that this is pretty well suited to
> unit-testing. In fact that's how I caught the bug that this last email
> fixed.

Yeah, this is great! I was thinking of building it too! Especially I
think it helps with the concern over complexity if the whole thi   ng is
covered by a unit test. That is far more maintainable than most kernel
code.

I'll look at this in detail next week

Thanks,
Jason


From jgg at nvidia.com  Wed Dec 27 07:46:48 2023
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Wed, 27 Dec 2023 11:46:48 -0400
Subject: [PATCH 04/19] iommu/arm-smmu-v3: Make STE programming
 independent of the callers
In-Reply-To: <CAKHBV27qsgjgwPfn8OpSq30z1w203NDqBZ0s66bPgjp1XDnLOg@mail.gmail.com>
References: <20231012121616.GF3952@nvidia.com>
 <CAKHBV27G1PLZ5gkYkOOCZdD9waZOZypkWqk4_HSR4XXGFT-+LA@mail.gmail.com>
 <20231018130455.GU3952@nvidia.com>
 <CAKHBV270uJjdj4zeK-NNt+j3TiqoGDdLUQ5uRrLw9PN0ysCDbw@mail.gmail.com>
 <20231020113918.GD3952@nvidia.com>
 <CAKHBV274M-DDD+vJgO-k9s4MF=FLhKajPdphfBVofjyOS3vHbA@mail.gmail.com>
 <CAKHBV24nfdq1q76T+DRQGNYeA-kP7ONnSjDsRFGsQCJVSrSm0w@mail.gmail.com>
 <ZX7xu8jN/rBZ4A/d@nvidia.com>
 <CAKHBV26CRC8eWMuOk6EZYMHOZoR2FauP=NBazzOiWCmQYEa1vg@mail.gmail.com>
 <CAKHBV27qsgjgwPfn8OpSq30z1w203NDqBZ0s66bPgjp1XDnLOg@mail.gmail.com>
Message-ID: <20231227154648.GB50406@nvidia.com>

On Tue, Dec 19, 2023 at 09:42:27PM +0800, Michael Shavit wrote:

> +static void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer,
> +                                __le64 *cur, const __le64 *target,
> +                                __le64 *staging_entry)
> +{
> +       bool cleanup_sync_required = false;
> +       u8 entry_qwords_used_diff = 0;
> +       int i = 0;
> +
> +       entry_qwords_used_diff =
> +               writer->ops.get_used_qword_diff_indexes(cur, target);
> +       if (WARN_ON_ONCE(entry_qwords_used_diff == 0))
> +               return;

A no change update is actually API legal, eg we can set the same
domain twice in a row. It should just do nothing.

If the goal is to improve readability I'd split this into smaller
functions and have the main function look like this:

       compute_used(..)
       if (hweight8(entry_qwords_used_diff) > 1) {
             set_v_0(..);
             set(qword_start=1,qword_end=N);
	     set(qword_start=0,qword_end=1); // V=1
       } else if (hweight8(entry_qwords_used_diff) == 1) {
             set_unused(..);
	     critical = ffs(..);
             set(qword_start=critical,qword_end=critical+1);
             set(qword_start=0,qword_end=N);
       } else { // hweight8 == 0
             set(qword_start=0,qword_end=N);
       }

Then the three different programming algorithms are entirely clear in
code. Make the generic set() function skip the sync if nothing
changed.

> +       if (hweight8(entry_qwords_used_diff) > 1) {
> +               /*
> +                * If transitioning to the target entry with a single qword
> +                * write isn't possible, then we must first transition to an
> +                * intermediate entry. The intermediate entry may either be an
> +                * entry that melds bits of the target entry into the current
> +                * entry without disrupting the hardware, or a breaking entry if
> +                * a hitless transition to the target is impossible.
> +                */
> +
> +               /*
> +                * Compute a staging entry that has all the bits currently
> +                * unused by HW set to their target values, such that comitting
> +                * it to the entry table woudn't disrupt the hardware.
> +                */
> +               memcpy(staging_entry, cur, writer->entry_length);
> +               writer->ops.set_unused_bits(staging_entry, target);
> +
> +               entry_qwords_used_diff =
> +                       writer->ops.get_used_qword_diff_indexes(staging_entry,
> +                                                               target);

Put the number qwords directly in the ops struct and don't make this
an op.  Above will need N=number of qwords as well.

Regrads,
Jason


From andriy.shevchenko at intel.com  Wed Dec 27 08:01:40 2023
From: andriy.shevchenko at intel.com (Andy Shevchenko)
Date: Wed, 27 Dec 2023 18:01:40 +0200
Subject: [PATCH v2 00/22] Improve IRQ wake capability reporting and
 update the cros_ec driver to use it
In-Reply-To: <CANg-bXDw+bYNTu-HFaNAPb4e+_oKt2ExR6PehWR_==vpboKGaw@mail.gmail.com>
References: <20231220235459.2965548-1-markhas@chromium.org>
 <ZYRAuY1LGdD8_u5K@smile.fi.intel.com>
 <CANg-bXDw+bYNTu-HFaNAPb4e+_oKt2ExR6PehWR_==vpboKGaw@mail.gmail.com>
Message-ID: <ZYxKZD4IMJH_QjQW@smile.fi.intel.com>

On Fri, Dec 22, 2023 at 03:30:43PM -0700, Mark Hasemeyer wrote:
> > Just wondering if you used --histogram diff algo when preparing patches.
> 
> Not knowingly. I use patman which uses 'git format-patch' under the
> covers with some added options:
> https://github.com/siemens/u-boot/blob/master/tools/patman/gitutil.py#L308

Add a configuration into your ~/.gitconfig (or local for the project),
it really makes the difference.

-- 
With Best Regards,
Andy Shevchenko




From u.kleine-koenig at pengutronix.de  Wed Dec 27 08:26:26 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 17:26:26 +0100
Subject: [PATCH 02/11] firmware: arm_scpi: Convert to platform remove callback returning void
In-Reply-To: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e7b4bc389949c3613a358bd8e57d70d7acd5552b.1703693980.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/firmware/arm_scpi.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 3f123f592cb4..94a6b4e667de 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -863,7 +863,7 @@ static void scpi_free_channels(void *data)
 		mbox_free_channel(info->channels[i].chan);
 }
 
-static int scpi_remove(struct platform_device *pdev)
+static void scpi_remove(struct platform_device *pdev)
 {
 	int i;
 	struct scpi_drvinfo *info = platform_get_drvdata(pdev);
@@ -874,8 +874,6 @@ static int scpi_remove(struct platform_device *pdev)
 		kfree(info->dvfs[i]->opps);
 		kfree(info->dvfs[i]);
 	}
-
-	return 0;
 }
 
 #define MAX_SCPI_XFERS		10
@@ -1048,7 +1046,7 @@ static struct platform_driver scpi_driver = {
 		.dev_groups = versions_groups,
 	},
 	.probe = scpi_probe,
-	.remove = scpi_remove,
+	.remove_new = scpi_remove,
 };
 module_platform_driver(scpi_driver);
 
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 08:26:25 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 17:26:25 +0100
Subject: [PATCH 01/11] firmware: arm_scmi: Convert to platform remove callback returning void
In-Reply-To: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
Message-ID: <86165c8ccd0bb47000a29e711102795b36c8df41.1703693980.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/firmware/arm_scmi/driver.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index a9f70e6e58ac..3ea64b22cf0d 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2834,7 +2834,7 @@ static int scmi_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int scmi_remove(struct platform_device *pdev)
+static void scmi_remove(struct platform_device *pdev)
 {
 	int id;
 	struct scmi_info *info = platform_get_drvdata(pdev);
@@ -2868,8 +2868,6 @@ static int scmi_remove(struct platform_device *pdev)
 	scmi_cleanup_txrx_channels(info);
 
 	ida_free(&scmi_id, info->id);
-
-	return 0;
 }
 
 static ssize_t protocol_version_show(struct device *dev,
@@ -2947,7 +2945,7 @@ static struct platform_driver scmi_driver = {
 		   .dev_groups = versions_groups,
 		   },
 	.probe = scmi_probe,
-	.remove = scmi_remove,
+	.remove_new = scmi_remove,
 };
 
 /**
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 08:26:31 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 17:26:31 +0100
Subject: [PATCH 07/11] firmware: raspberrypi: Convert to platform remove callback returning void
In-Reply-To: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
Message-ID: <5df31ef3c069f45634631c9c639bbb60ab1d4798.1703693980.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/firmware/raspberrypi.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 4cd290a60fba..322aada20f74 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -317,7 +317,7 @@ static void rpi_firmware_shutdown(struct platform_device *pdev)
 	rpi_firmware_property(fw, RPI_FIRMWARE_NOTIFY_REBOOT, NULL, 0);
 }
 
-static int rpi_firmware_remove(struct platform_device *pdev)
+static void rpi_firmware_remove(struct platform_device *pdev)
 {
 	struct rpi_firmware *fw = platform_get_drvdata(pdev);
 
@@ -327,8 +327,6 @@ static int rpi_firmware_remove(struct platform_device *pdev)
 	rpi_clk = NULL;
 
 	rpi_firmware_put(fw);
-
-	return 0;
 }
 
 static const struct of_device_id rpi_firmware_of_match[] = {
@@ -406,7 +404,7 @@ static struct platform_driver rpi_firmware_driver = {
 	},
 	.probe		= rpi_firmware_probe,
 	.shutdown	= rpi_firmware_shutdown,
-	.remove		= rpi_firmware_remove,
+	.remove_new	= rpi_firmware_remove,
 };
 module_platform_driver(rpi_firmware_driver);
 
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 08:26:29 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 17:26:29 +0100
Subject: [PATCH 05/11] firmware: mtk-adsp-ipc: Convert to platform remove callback returning void
In-Reply-To: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
Message-ID: <e2ea8abb4c30190392a86cf05cecd722d0f0b493.1703693980.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/firmware/mtk-adsp-ipc.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/mtk-adsp-ipc.c b/drivers/firmware/mtk-adsp-ipc.c
index 85e94ddc7204..a762302978de 100644
--- a/drivers/firmware/mtk-adsp-ipc.c
+++ b/drivers/firmware/mtk-adsp-ipc.c
@@ -116,7 +116,7 @@ static int mtk_adsp_ipc_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int mtk_adsp_ipc_remove(struct platform_device *pdev)
+static void mtk_adsp_ipc_remove(struct platform_device *pdev)
 {
 	struct mtk_adsp_ipc *adsp_ipc = dev_get_drvdata(&pdev->dev);
 	struct mtk_adsp_chan *adsp_chan;
@@ -126,8 +126,6 @@ static int mtk_adsp_ipc_remove(struct platform_device *pdev)
 		adsp_chan = &adsp_ipc->chans[i];
 		mbox_free_channel(adsp_chan->ch);
 	}
-
-	return 0;
 }
 
 static struct platform_driver mtk_adsp_ipc_driver = {
@@ -135,7 +133,7 @@ static struct platform_driver mtk_adsp_ipc_driver = {
 		.name = "mtk-adsp-ipc",
 	},
 	.probe = mtk_adsp_ipc_probe,
-	.remove = mtk_adsp_ipc_remove,
+	.remove_new = mtk_adsp_ipc_remove,
 };
 builtin_platform_driver(mtk_adsp_ipc_driver);
 
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 08:26:35 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 17:26:35 +0100
Subject: [PATCH 11/11] firmware: zynqmp: Convert to platform remove callback returning void
In-Reply-To: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
Message-ID: <b5a82472a6d61608c2cd7728ca364f6c88a821c3.1703693980.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/firmware/xilinx/zynqmp.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a55dfd9bae6b..73cae6ef83ec 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -1929,7 +1929,7 @@ static int zynqmp_firmware_probe(struct platform_device *pdev)
 	return of_platform_populate(dev->of_node, NULL, NULL, dev);
 }
 
-static int zynqmp_firmware_remove(struct platform_device *pdev)
+static void zynqmp_firmware_remove(struct platform_device *pdev)
 {
 	struct pm_api_feature_data *feature_data;
 	struct hlist_node *tmp;
@@ -1944,8 +1944,6 @@ static int zynqmp_firmware_remove(struct platform_device *pdev)
 	}
 
 	platform_device_unregister(em_dev);
-
-	return 0;
 }
 
 static const struct of_device_id zynqmp_firmware_of_match[] = {
@@ -1962,6 +1960,6 @@ static struct platform_driver zynqmp_firmware_driver = {
 		.dev_groups = zynqmp_firmware_groups,
 	},
 	.probe = zynqmp_firmware_probe,
-	.remove = zynqmp_firmware_remove,
+	.remove_new = zynqmp_firmware_remove,
 };
 module_platform_driver(zynqmp_firmware_driver);
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 08:26:28 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 17:26:28 +0100
Subject: [PATCH 04/11] firmware: imx-dsp: Convert to platform remove callback returning void
In-Reply-To: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
Message-ID: <f4cc1ffe30b837d5eab96f2924f51999dfa9f671.1703693980.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/firmware/imx/imx-dsp.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/imx/imx-dsp.c b/drivers/firmware/imx/imx-dsp.c
index a48a58e0c61f..01c8ef14eaec 100644
--- a/drivers/firmware/imx/imx-dsp.c
+++ b/drivers/firmware/imx/imx-dsp.c
@@ -160,7 +160,7 @@ static int imx_dsp_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int imx_dsp_remove(struct platform_device *pdev)
+static void imx_dsp_remove(struct platform_device *pdev)
 {
 	struct imx_dsp_chan *dsp_chan;
 	struct imx_dsp_ipc *dsp_ipc;
@@ -173,8 +173,6 @@ static int imx_dsp_remove(struct platform_device *pdev)
 		mbox_free_channel(dsp_chan->ch);
 		kfree(dsp_chan->name);
 	}
-
-	return 0;
 }
 
 static struct platform_driver imx_dsp_driver = {
@@ -182,7 +180,7 @@ static struct platform_driver imx_dsp_driver = {
 		.name = "imx-dsp",
 	},
 	.probe = imx_dsp_probe,
-	.remove = imx_dsp_remove,
+	.remove_new = imx_dsp_remove,
 };
 builtin_platform_driver(imx_dsp_driver);
 
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 08:26:24 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 17:26:24 +0100
Subject: [PATCH 00/11] firmware: Convert to platform remove callback returning void
Message-ID: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>

Hello,

this series converts all platform drivers below drivers/firmware that
make use of .remove() to use .remove_new() instead.

See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for an extended explanation and the eventual goal.
The TL;DR; is to make it harder for driver authors to leak resources
without noticing. The drivers here get it right though and so can be
converted trivially.

This is merge window material. There doesn't seem to be a maintainer for
all of drivers/firmware and I don't know how patch application works
there usually.  All patches are pairwise independent, so they can be
applied individually.

Best regards
Uwe

Uwe Kleine-K?nig (11):
  firmware: arm_scmi: Convert to platform remove callback returning void
  firmware: arm_scpi: Convert to platform remove callback returning void
  firmware: coreboot_table: Convert to platform remove callback returning void
  firmware: imx-dsp: Convert to platform remove callback returning void
  firmware: mtk-adsp-ipc: Convert to platform remove callback returning void
  firmware: qemu_fw_cfg: Convert to platform remove callback returning void
  firmware: raspberrypi: Convert to platform remove callback returning void
  firmware: stratix10-rsu: Convert to platform remove callback returning void
  firmware: stratix10-svc: Convert to platform remove callback returning void
  firmware: turris-mox-rwtm: Convert to platform remove callback returning void
  firmware: zynqmp: Convert to platform remove callback returning void

 drivers/firmware/arm_scmi/driver.c       | 6 ++----
 drivers/firmware/arm_scpi.c              | 6 ++----
 drivers/firmware/google/coreboot_table.c | 5 ++---
 drivers/firmware/imx/imx-dsp.c           | 6 ++----
 drivers/firmware/mtk-adsp-ipc.c          | 6 ++----
 drivers/firmware/qemu_fw_cfg.c           | 5 ++---
 drivers/firmware/raspberrypi.c           | 6 ++----
 drivers/firmware/stratix10-rsu.c         | 5 ++---
 drivers/firmware/stratix10-svc.c         | 6 ++----
 drivers/firmware/turris-mox-rwtm.c       | 6 ++----
 drivers/firmware/xilinx/zynqmp.c         | 6 ++----
 11 files changed, 22 insertions(+), 41 deletions(-)

base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
-- 
2.43.0



From florian.fainelli at broadcom.com  Wed Dec 27 08:43:08 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Wed, 27 Dec 2023 17:43:08 +0100
Subject: [PATCH 07/11] firmware: raspberrypi: Convert to platform remove
 callback returning void
In-Reply-To: <5df31ef3c069f45634631c9c639bbb60ab1d4798.1703693980.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703693980.git.u.kleine-koenig@pengutronix.de>
 <5df31ef3c069f45634631c9c639bbb60ab1d4798.1703693980.git.u.kleine-koenig@pengutronix.de>
Message-ID: <cf5303ee-6474-4212-b8a9-f1e99ef98ab7@broadcom.com>



On 12/27/2023 5:26 PM, Uwe Kleine-K?nig wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
> 
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
> 
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Reviewed-by: Florian Fainelli <florian.fainelli at broadcom.com>
-- 
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231227/1e0a1ad8/attachment-0001.p7s>

From othacehe at gnu.org  Wed Dec 27 09:09:17 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Wed, 27 Dec 2023 18:09:17 +0100
Subject: [PATCH v4 0/2] Add Variscite VAR-SOM-MX93 support
Message-ID: <20231227170919.8771-1-othacehe@gnu.org>

Hey,

This is a v4 adding support for the Variscite VAR-SOM-MX93 SoM on Symphony
Board.

Thanks,

Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
Changes in v4:
- Add ethernet0 alias
- Remove useless properties

Changes in v3:
- Fix indentation on a continuation line
- Remove useless nodes and include

Changes in v2:
- Remove "nxp,pca9451a" block
- Fixed checkpatch warnings
- Fixed dtb_checks warnings
- Introduce dt-bindings documentation

v3: https://lore.kernel.org/linux-devicetree/20231224124114.31119-1-othacehe at gnu.org/T/#t


Mathieu Othacehe (2):
  dt-bindings: arm: fsl: Add VAR-SOM-MX93 with Symphony
  arm64: dts: imx93-var-som: Add Variscite VAR-SOM-MX93

 .../devicetree/bindings/arm/fsl.yaml          |   6 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-var-som-symphony.dts  | 303 ++++++++++++++++++
 .../boot/dts/freescale/imx93-var-som.dtsi     | 111 +++++++
 4 files changed, 421 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som.dtsi

-- 
2.41.0



From othacehe at gnu.org  Wed Dec 27 09:09:18 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Wed, 27 Dec 2023 18:09:18 +0100
Subject: [PATCH v4 1/2] dt-bindings: arm: fsl: Add VAR-SOM-MX93 with Symphony
In-Reply-To: <20231227170919.8771-1-othacehe@gnu.org>
References: <20231227170919.8771-1-othacehe@gnu.org>
Message-ID: <20231227170919.8771-2-othacehe@gnu.org>

Add support for Variscite i.MX93 VAR-SOM-MX93 SoM with Symphony board.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
 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 228dcc5c7d6f..27936edfe054 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1275,6 +1275,12 @@ properties:
           - const: tq,imx93-tqma9352        # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM
           - const: fsl,imx93
 
+      - description: Variscite VAR-SOM-MX93 based boards
+        items:
+          - const: variscite,var-som-mx93-symphony
+          - const: variscite,var-som-mx93
+          - const: fsl,imx93
+
       - description:
           Freescale Vybrid Platform Device Tree Bindings
 
-- 
2.41.0



From othacehe at gnu.org  Wed Dec 27 09:09:19 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Wed, 27 Dec 2023 18:09:19 +0100
Subject: [PATCH v4 2/2] arm64: dts: imx93-var-som: Add Variscite VAR-SOM-MX93
In-Reply-To: <20231227170919.8771-1-othacehe@gnu.org>
References: <20231227170919.8771-1-othacehe@gnu.org>
Message-ID: <20231227170919.8771-3-othacehe@gnu.org>

Add DTSI for Variscite VAR-SOM-MX93 System on Module and DTS for Variscite
VAR-SOM-MX93 on Symphony evaluation board.

This version comes with:
- NXP i.MX 93 Dual, 1.7GHz, Cortex-A55 + Cortex-M33
- 2 GB of RAM
- 16GB eMMC
- 802.11ax/ac/a/b/g/n WiFi with 5.3 Bluetooth
- CAN bus
- Audio codec

Reviewed-by: Fabio Estevam <festevam at gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
---
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-var-som-symphony.dts  | 303 ++++++++++++++++++
 .../boot/dts/freescale/imx93-var-som.dtsi     | 111 +++++++
 3 files changed, 415 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2e027675d7bb..a6f1700961e3 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -203,6 +203,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxca.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
 
 imx8mm-venice-gw72xx-0x-imx219-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-imx219.dtbo
 imx8mm-venice-gw72xx-0x-rpidsi-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rpidsi.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
new file mode 100644
index 000000000000..3b7a01fb1b51
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
@@ -0,0 +1,303 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 NXP
+ * Copyright 2023 Variscite Ltd.
+ */
+
+/dts-v1/;
+
+#include "imx93-var-som.dtsi"
+
+/{
+	model = "Variscite VAR-SOM-MX93 on Symphony evaluation board";
+	compatible = "variscite,var-som-mx93-symphony",
+		     "variscite,var-som-mx93", "fsl,imx93";
+
+	aliases {
+		ethernet0 = &eqos;
+		ethernet1 = &fec;
+	};
+
+	chosen {
+		stdout-path = &lpuart1;
+	};
+
+	/*
+	 * Needed only for Symphony <= v1.5
+	 */
+	reg_fec_phy: regulator-fec-phy {
+		compatible = "regulator-fixed";
+		regulator-name = "fec-phy";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-enable-ramp-delay = <20000>;
+		gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	reg_usdhc2_vmmc: regulator-usdhc2 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+		regulator-name = "VSD_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+		off-on-delay-us = <20000>;
+		enable-active-high;
+	};
+
+	reg_vref_1v8: regulator-adc-vref {
+		compatible = "regulator-fixed";
+		regulator-name = "vref_1v8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		ethosu_mem: ethosu-region at 88000000 {
+			compatible = "shared-dma-pool";
+			reusable;
+			reg = <0x0 0x88000000 0x0 0x8000000>;
+		};
+
+		vdev0vring0: vdev0vring0 at 87ee0000 {
+			reg = <0 0x87ee0000 0 0x8000>;
+			no-map;
+		};
+
+		vdev0vring1: vdev0vring1 at 87ee8000 {
+			reg = <0 0x87ee8000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring0: vdev1vring0 at 87ef0000 {
+			reg = <0 0x87ef0000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring1: vdev1vring1 at 87ef8000 {
+			reg = <0 0x87ef8000 0 0x8000>;
+			no-map;
+		};
+
+		rsc_table: rsc-table at 2021f000 {
+			reg = <0 0x2021f000 0 0x1000>;
+			no-map;
+		};
+
+		vdevbuffer: vdevbuffer at 87f00000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x87f00000 0 0x100000>;
+			no-map;
+		};
+
+		ele_reserved: ele-reserved at 87de0000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x87de0000 0 0x100000>;
+			no-map;
+		};
+	};
+};
+
+/* Use external instead of internal RTC*/
+&bbnsm_rtc {
+	status = "disabled";
+};
+
+&eqos {
+	mdio {
+		ethphy1: ethernet-phy at 5 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <5>;
+			qca,disable-smarteee;
+			eee-broken-1000t;
+			reset-gpios = <&pca9534 5 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <20000>;
+			vddio-supply = <&vddio1>;
+
+			vddio1: vddio-regulator {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+			};
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy1>;
+	phy-supply = <&reg_fec_phy>;
+	status = "okay";
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_fec: fecgrp {
+		fsl,pins = <
+			MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0		0x57e
+			MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1		0x57e
+			MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2		0x57e
+			MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3		0x57e
+			MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC		0x5fe
+			MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL	0x57e
+			MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0		0x57e
+			MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1		0x57e
+			MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2		0x57e
+			MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3		0x57e
+			MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC		0x5fe
+			MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL	0x57e
+		>;
+	};
+
+	pinctrl_flexcan1: flexcan1grp {
+		fsl,pins = <
+			MX93_PAD_PDM_CLK__CAN1_TX                       0x139e
+			MX93_PAD_PDM_BIT_STREAM0__CAN1_RX               0x139e
+		>;
+	};
+
+	pinctrl_lpi2c1: lpi2c1grp {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__LPI2C1_SCL			0x40000b9e
+			MX93_PAD_I2C1_SDA__LPI2C1_SDA			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c1_gpio: lpi2c1gpiogrp {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__GPIO1_IO00			0x31e
+			MX93_PAD_I2C1_SDA__GPIO1_IO01			0x31e
+		>;
+	};
+
+	pinctrl_lpi2c5: lpi2c5grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO23__LPI2C5_SCL			0x40000b9e
+			MX93_PAD_GPIO_IO22__LPI2C5_SDA			0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c5_gpio: lpi2c5gpiogrp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO23__GPIO2_IO23			0x31e
+			MX93_PAD_GPIO_IO22__GPIO2_IO22			0x31e
+		>;
+	};
+
+	pinctrl_pca9534: pca9534grp {
+		fsl,pins = <
+			MX93_PAD_CCM_CLKO1__GPIO3_IO26		0x31e
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX93_PAD_UART1_RXD__LPUART1_RX			0x31e
+			MX93_PAD_UART1_TXD__LPUART1_TX			0x31e
+		>;
+	};
+
+	pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO18__GPIO2_IO18		0x31e
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX93_PAD_SD2_CLK__USDHC2_CLK		0x15fe
+			MX93_PAD_SD2_CMD__USDHC2_CMD		0x13fe
+			MX93_PAD_SD2_DATA0__USDHC2_DATA0	0x13fe
+			MX93_PAD_SD2_DATA1__USDHC2_DATA1	0x13fe
+			MX93_PAD_SD2_DATA2__USDHC2_DATA2	0x13fe
+			MX93_PAD_SD2_DATA3__USDHC2_DATA3	0x13fe
+			MX93_PAD_SD2_VSELECT__USDHC2_VSELECT	0x51e
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+		fsl,pins = <
+			MX93_PAD_SD2_CD_B__GPIO3_IO00		0x31e
+		>;
+	};
+};
+
+&lpi2c1 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c1>;
+	pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
+	pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
+	scl-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	/* DS1337 RTC module */
+	rtc at 68 {
+		compatible = "dallas,ds1337";
+		reg = <0x68>;
+	};
+};
+
+&lpi2c5 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "sleep", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c5>;
+	pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+	pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
+	scl-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	pca9534: gpio at 20 {
+		compatible = "nxp,pca9534";
+		reg = <0x20>;
+		gpio-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9534>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+		#gpio-cells = <2>;
+		wakeup-source;
+	};
+};
+
+/* Console */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
+	vmmc-supply = <&reg_usdhc2_vmmc>;
+	bus-width = <4>;
+	status = "okay";
+	no-sdio;
+	no-mmc;
+};
+
+/* Watchdog */
+&wdog3 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
new file mode 100644
index 000000000000..6c77b886666b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 NXP
+ * Copyright 2023 Variscite Ltd.
+ */
+
+/dts-v1/;
+
+#include "imx93.dtsi"
+
+/{
+	model = "Variscite VAR-SOM-MX93 module";
+	compatible = "variscite,var-som-mx93", "fsl,imx93";
+
+	mmc_pwrseq: mmc-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		post-power-on-delay-ms = <100>;
+		power-off-delay-us = <10000>;
+		reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>,	/* WIFI_RESET */
+			      <&gpio3 7 GPIO_ACTIVE_LOW>;	/* WIFI_PWR_EN */
+	};
+
+	reg_eqos_phy: regulator-eqos-phy {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_eqos_phy>;
+		regulator-name = "eth_phy_pwr";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		startup-delay-us = <100000>;
+		regulator-always-on;
+	};
+};
+
+&eqos {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_eqos>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+	phy-supply = <&reg_eqos_phy>;
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clock-frequency = <1000000>;
+
+		ethphy0: ethernet-phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
+			eee-broken-1000t;
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl_eqos: eqosgrp {
+		fsl,pins = <
+			MX93_PAD_ENET1_MDC__ENET_QOS_MDC			0x57e
+			MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO			0x57e
+			MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0			0x57e
+			MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1			0x57e
+			MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2			0x57e
+			MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3			0x57e
+			MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK	0x5fe
+			MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL		0x57e
+			MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0			0x57e
+			MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1			0x57e
+			MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2			0x57e
+			MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3			0x57e
+			MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK	0x5fe
+			MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL		0x57e
+		>;
+	};
+
+	pinctrl_reg_eqos_phy: regeqosgrp {
+		fsl,pins = <
+			MX93_PAD_UART2_TXD__GPIO1_IO07			0x51e
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX93_PAD_SD1_CLK__USDHC1_CLK		0x15fe
+			MX93_PAD_SD1_CMD__USDHC1_CMD		0x13fe
+			MX93_PAD_SD1_DATA0__USDHC1_DATA0	0x13fe
+			MX93_PAD_SD1_DATA1__USDHC1_DATA1	0x13fe
+			MX93_PAD_SD1_DATA2__USDHC1_DATA2	0x13fe
+			MX93_PAD_SD1_DATA3__USDHC1_DATA3	0x13fe
+			MX93_PAD_SD1_DATA4__USDHC1_DATA4	0x13fe
+			MX93_PAD_SD1_DATA5__USDHC1_DATA5	0x13fe
+			MX93_PAD_SD1_DATA6__USDHC1_DATA6	0x13fe
+			MX93_PAD_SD1_DATA7__USDHC1_DATA7	0x13fe
+			MX93_PAD_SD1_STROBE__USDHC1_STROBE	0x15fe
+		>;
+	};
+};
+
+/* eMMC */
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1>;
+	pinctrl-2 = <&pinctrl_usdhc1>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
-- 
2.41.0



From Frank.Li at nxp.com  Wed Dec 27 10:27:11 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:11 -0500
Subject: [PATCH v7 00/16] PCI: imx6: Clean up and add imx95 pci support
Message-ID: <20231227182727.1747435-1-Frank.Li@nxp.com>

first 6 patches use drvdata: flags to simplify some switch-case code.
Improve maintaince and easy to read code.

Then add imx95 basic pci host function.

follow two patch do endpoint code clean up.
Then add imx95 basic endpont function.

Compared with v2, added EP function support and some fixes,  please change
notes at each patches.

dt-binding pass pcie node:

pcie0: pcie at 4c300000 {
                        compatible = "fsl,imx95-pcie";
                        reg = <0 0x4c300000 0 0x40000>,
                                <0 0x4c360000 0 0x10000>,
                                <0 0x4c340000 0 0x20000>,
                                <0 0x60100000 0 0xfe00000>;
                        reg-names = "dbi", "atu", "app", "config";
                        #address-cells = <3>;
                        #size-cells = <2>;
                        device_type = "pci";
                        linux,pci-domain = <0>;
                        bus-range = <0x00 0xff>;
                        ranges = <0x81000000 0x0 0x00000000 0x0 0x6ff00000 0 0x00100000>,
                                 <0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000>;
                        num-lanes = <1>;
                        num-viewport = <8>;
                        interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
                        interrupt-names = "msi";
                        #interrupt-cells = <1>;
                        interrupt-map-mask = <0 0 0 0x7>;
                        interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 2 &gic 0 0 GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 3 &gic 0 0 GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
                                        <0 0 0 4 &gic 0 0 GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
                        fsl,max-link-speed = <3>;
                        clocks = <&scmi_clk IMX95_CLK_HSIO>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                 <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux";
                        assigned-clocks =<&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                         <&scmi_clk IMX95_CLK_HSIOPLL>,
                                         <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        assigned-clock-rates = <3600000000>, <100000000>, <10000000>;
                        assigned-clock-parents = <0>, <0>,
                                                 <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
                        power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
                        /* 0x30~0x37 stream id for pci0 */
                        /*
                         * iommu-map = <0x000 &apps_smmu 0x30 0x1>,
                         * <0x100 &apps_smmu 0x31 0x1>;
                         */
                        status = "disabled";
                };

pcie1: pcie-ep at 4c380000 {
                        compatible = "fsl,imx95-pcie-ep";
                        reg = <0 0x4c380000 0 0x20000>,
                              <0 0x4c3e0000 0 0x1000>,
                              <0 0x4c3a0000 0 0x1000>,
                              <0 0x4c3c0000 0 0x10000>,
                              <0 0x4c3f0000 0 0x10000>,
                              <0xa 0 1 0>;
                        reg-names = "dbi", "atu", "dbi2", "app", "dma", "addr_space";
                        interrupts = <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>;
                        interrupt-names = "dma";
                        fsl,max-link-speed = <3>;
                        clocks = <&scmi_clk IMX95_CLK_HSIO>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL>,
                                 <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                 <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux";
                        assigned-clocks =<&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
                                         <&scmi_clk IMX95_CLK_HSIOPLL>,
                                         <&scmi_clk IMX95_CLK_HSIOPCIEAUX>;
                        assigned-clock-rates = <3600000000>, <100000000>, <10000000>;
                        assigned-clock-parents = <0>, <0>,
                                                 <&scmi_clk IMX95_CLK_SYSPLL1_PFD1_DIV2>;
                        power-domains = <&scmi_devpd IMX95_PD_HSIO_TOP>;
                        status = "disabled";
                };

Frank Li (15):
  PCI: imx6: Simplify clock handling by using bulk_clk_*() function
  PCI: imx6: Simplify phy handling by using by using
    IMX6_PCIE_FLAG_HAS_PHY
  PCI: imx6: Simplify reset handling by using by using
    *_FLAG_HAS_*_RESET
  dt-bindings: imx6q-pcie: Add linux,pci-domain as required for iMX8MQ
  PCI: imx6: Using "linux,pci-domain" as slot ID
  PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
  PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
  PCI: imx6: Simplify switch-case logic by involve init_phy callback
  dt-bindings: imx6q-pcie: Clean up irrationality clocks check
  dt-bindings: imx6q-pcie: restruct reg and reg-name
  PCI: imx6: Add iMX95 PCIe support
  PCI: imx6: Clean up get addr_space code
  PCI: imx6: Add epc_features in imx6_pcie_drvdata
  dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
  PCI: imx6: Add iMX95 Endpoint (EP) function support

Richard Zhu (1):
  dt-bindings: imx6q-pcie: Add imx95 pcie compatible string

 .../bindings/pci/fsl,imx6q-pcie-common.yaml   |  28 +-
 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       |  57 +-
 .../bindings/pci/fsl,imx6q-pcie.yaml          |  49 +-
 drivers/pci/controller/dwc/pci-imx6.c         | 628 ++++++++++--------
 4 files changed, 452 insertions(+), 310 deletions(-)

-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:12 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:12 -0500
Subject: [PATCH v7 01/16] PCI: imx6: Simplify clock handling by using bulk_clk_*() function
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-2-Frank.Li@nxp.com>

Refactors the clock handling logic. Adds clk_names[] define in drvdata.
Using clk_bulk*() api simplifies the code.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5
    - update commit message
    - direct using clk name list, instead of macro
    - still keep caculate clk list count because sizeof return pre allocated
    array size.
    
    Change from v3 to v4
    - using clk_bulk_*() API
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 125 ++++++++------------------
 1 file changed, 35 insertions(+), 90 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 74703362aeec7..50d9faaa17f71 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -61,12 +61,15 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 
+#define IMX6_PCIE_MAX_CLKS       6
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
 	u32 flags;
 	int dbi_length;
 	const char *gpr;
+	const char *clk_names[IMX6_PCIE_MAX_CLKS];
 };
 
 struct imx6_pcie {
@@ -74,11 +77,8 @@ struct imx6_pcie {
 	int			reset_gpio;
 	bool			gpio_active_high;
 	bool			link_is_up;
-	struct clk		*pcie_bus;
-	struct clk		*pcie_phy;
-	struct clk		*pcie_inbound_axi;
-	struct clk		*pcie;
-	struct clk		*pcie_aux;
+	struct clk_bulk_data	clks[IMX6_PCIE_MAX_CLKS];
+	u32			clks_cnt;
 	struct regmap		*iomuxc_gpr;
 	u16			msi_ctrl;
 	u32			controller_id;
@@ -407,13 +407,18 @@ static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
 
 static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
 {
-	unsigned long phy_rate = clk_get_rate(imx6_pcie->pcie_phy);
+	unsigned long phy_rate = 0;
 	int mult, div;
 	u16 val;
+	int i;
 
 	if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
 		return 0;
 
+	for (i = 0; i < imx6_pcie->clks_cnt; i++)
+		if (strncmp(imx6_pcie->clks[i].id, "pcie_phy", 8) == 0)
+			phy_rate = clk_get_rate(imx6_pcie->clks[i].clk);
+
 	switch (phy_rate) {
 	case 125000000:
 		/*
@@ -550,19 +555,11 @@ static int imx6_pcie_attach_pd(struct device *dev)
 
 static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
-	struct dw_pcie *pci = imx6_pcie->pci;
-	struct device *dev = pci->dev;
 	unsigned int offset;
 	int ret = 0;
 
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX6SX:
-		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_axi clock\n");
-			break;
-		}
-
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
 		break;
@@ -589,12 +586,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 	case IMX8MQ_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		ret = clk_prepare_enable(imx6_pcie->pcie_aux);
-		if (ret) {
-			dev_err(dev, "unable to enable pcie_aux clock\n");
-			break;
-		}
-
 		offset = imx6_pcie_grp_offset(imx6_pcie);
 		/*
 		 * Set the over ride low and enabled
@@ -615,9 +606,6 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		clk_disable_unprepare(imx6_pcie->pcie_inbound_axi);
-		break;
 	case IMX6QP:
 	case IMX6Q:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
@@ -631,14 +619,6 @@ static void imx6_pcie_disable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
 		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		clk_disable_unprepare(imx6_pcie->pcie_aux);
-		break;
 	default:
 		break;
 	}
@@ -650,23 +630,9 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 	struct device *dev = pci->dev;
 	int ret;
 
-	ret = clk_prepare_enable(imx6_pcie->pcie_phy);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie_phy clock\n");
+	ret =  clk_bulk_prepare_enable(imx6_pcie->clks_cnt, imx6_pcie->clks);
+	if (ret)
 		return ret;
-	}
-
-	ret = clk_prepare_enable(imx6_pcie->pcie_bus);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie_bus clock\n");
-		goto err_pcie_bus;
-	}
-
-	ret = clk_prepare_enable(imx6_pcie->pcie);
-	if (ret) {
-		dev_err(dev, "unable to enable pcie clock\n");
-		goto err_pcie;
-	}
 
 	ret = imx6_pcie_enable_ref_clk(imx6_pcie);
 	if (ret) {
@@ -679,11 +645,7 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 	return 0;
 
 err_ref_clk:
-	clk_disable_unprepare(imx6_pcie->pcie);
-err_pcie:
-	clk_disable_unprepare(imx6_pcie->pcie_bus);
-err_pcie_bus:
-	clk_disable_unprepare(imx6_pcie->pcie_phy);
+	clk_bulk_disable_unprepare(imx6_pcie->clks_cnt, imx6_pcie->clks);
 
 	return ret;
 }
@@ -691,9 +653,7 @@ static int imx6_pcie_clk_enable(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 {
 	imx6_pcie_disable_ref_clk(imx6_pcie);
-	clk_disable_unprepare(imx6_pcie->pcie);
-	clk_disable_unprepare(imx6_pcie->pcie_bus);
-	clk_disable_unprepare(imx6_pcie->pcie_phy);
+	clk_bulk_disable_unprepare(imx6_pcie->clks_cnt, imx6_pcie->clks);
 }
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
@@ -1305,32 +1265,19 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return imx6_pcie->reset_gpio;
 	}
 
-	/* Fetch clocks */
-	imx6_pcie->pcie_bus = devm_clk_get(dev, "pcie_bus");
-	if (IS_ERR(imx6_pcie->pcie_bus))
-		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_bus),
-				     "pcie_bus clock source missing or invalid\n");
+	while (imx6_pcie->drvdata->clk_names[imx6_pcie->clks_cnt]) {
+		int i = imx6_pcie->clks_cnt;
+
+		imx6_pcie->clks[i].id = imx6_pcie->drvdata->clk_names[i];
+		imx6_pcie->clks_cnt++;
+	}
 
-	imx6_pcie->pcie = devm_clk_get(dev, "pcie");
-	if (IS_ERR(imx6_pcie->pcie))
-		return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie),
-				     "pcie clock source missing or invalid\n");
+	/* Fetch clocks */
+	ret = devm_clk_bulk_get(dev, imx6_pcie->clks_cnt, imx6_pcie->clks);
+	if (ret)
+		return ret;
 
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX6SX:
-		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
-							   "pcie_inbound_axi");
-		if (IS_ERR(imx6_pcie->pcie_inbound_axi))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_inbound_axi),
-					     "pcie_inbound_axi clock missing or invalid\n");
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
-		fallthrough;
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
 			imx6_pcie->controller_id = 1;
@@ -1353,10 +1300,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	case IMX8MM_EP:
 	case IMX8MP:
 	case IMX8MP_EP:
-		imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
-		if (IS_ERR(imx6_pcie->pcie_aux))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_aux),
-					     "pcie_aux clock source missing or invalid\n");
 		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
 									 "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
@@ -1372,14 +1315,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	default:
 		break;
 	}
-	/* Don't fetch the pcie_phy clock, if it has abstract PHY driver */
-	if (imx6_pcie->phy == NULL) {
-		imx6_pcie->pcie_phy = devm_clk_get(dev, "pcie_phy");
-		if (IS_ERR(imx6_pcie->pcie_phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pcie_phy),
-					     "pcie_phy clock source missing or invalid\n");
-	}
-
 
 	/* Grab turnoff reset */
 	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
@@ -1477,6 +1412,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1484,6 +1420,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_inbound_axi"},
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1492,40 +1429,48 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
+		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:13 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:13 -0500
Subject: [PATCH v7 02/16] PCI: imx6: Simplify phy handling by using by using IMX6_PCIE_FLAG_HAS_PHY
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-3-Frank.Li@nxp.com>

Refactors the phy handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_PHY bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling phy.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5:
    - none, Keep IMX6_PCIE_FLAG_HAS_PHY to indicate dts mismatch when platform
    require phy suppport.
    
    Change from v1 to v3:
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 50d9faaa17f71..4d620249f3d52 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -60,6 +60,9 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
+#define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
+
+#define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
 #define IMX6_PCIE_MAX_CLKS       6
 
@@ -1277,6 +1280,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY)) {
+		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
+		if (IS_ERR(imx6_pcie->phy))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
+					     "failed to get pcie phy\n");
+	}
+
 	switch (imx6_pcie->drvdata->variant) {
 	case IMX7D:
 		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
@@ -1306,11 +1316,6 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
 
-		imx6_pcie->phy = devm_phy_get(dev, "pcie-phy");
-		if (IS_ERR(imx6_pcie->phy))
-			return dev_err_probe(dev, PTR_ERR(imx6_pcie->phy),
-					     "failed to get pcie phy\n");
-
 		break;
 	default:
 		break;
@@ -1444,13 +1449,15 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_PHY,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
@@ -1462,12 +1469,14 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_PHY,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:14 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:14 -0500
Subject: [PATCH v7 03/16] PCI: imx6: Simplify reset handling by using by using *_FLAG_HAS_*_RESET
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-4-Frank.Li@nxp.com>

Refactors the reset handling logic in the imx6 PCI driver by adding
IMX6_PCIE_FLAG_HAS_*_RESET bitmask define for drvdata::flags.

The drvdata::flags and a bitmask ensures a cleaner and more scalable
switch-case structure for handling reset.

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v4 to v5:
    - Add Mani's Reviewed-by tag
    - Fixed MQ_EP's flags
    
    Chagne from v3 to v4:
    - none
    Change from v2 to v3:
    - add Philipp's Reviewed-by tag
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.
    
    Change from v1 to v2:
    - remove condition check before reset_control_(de)assert() because it is
      none ops if a NULL pointer pass down.
    - still keep condition check at probe to help identify dts file mismatch
      problem.

 drivers/pci/controller/dwc/pci-imx6.c | 108 ++++++++++----------------
 1 file changed, 41 insertions(+), 67 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 4d620249f3d52..294f61a9c6fd9 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -61,6 +61,8 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE	BIT(1)
 #define IMX6_PCIE_FLAG_SUPPORTS_SUSPEND		BIT(2)
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
+#define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
+#define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -661,18 +663,10 @@ static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 {
+	reset_control_assert(imx6_pcie->pciephy_reset);
+	reset_control_assert(imx6_pcie->apps_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_assert(imx6_pcie->pciephy_reset);
-		fallthrough;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
-		break;
 	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
@@ -693,6 +687,8 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
 		break;
+	default:
+		break;
 	}
 
 	/* Some boards don't have PCIe reset GPIO. */
@@ -706,14 +702,10 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
 
+	reset_control_deassert(imx6_pcie->pciephy_reset);
+
 	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-		break;
 	case IMX7D:
-		reset_control_deassert(imx6_pcie->pciephy_reset);
-
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
 		 * Corrector" and other mysterious undocumented things.
@@ -745,11 +737,7 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 
 		usleep_range(200, 500);
 		break;
-	case IMX6Q:		/* Nothing to do */
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
+	default:
 		break;
 	}
 
@@ -796,16 +784,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 				   IMX6Q_GPR12_PCIE_CTL_2,
 				   IMX6Q_GPR12_PCIE_CTL_2);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_deassert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_deassert(imx6_pcie->apps_reset);
 }
 
 static void imx6_pcie_ltssm_disable(struct device *dev)
@@ -819,16 +802,11 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0);
 		break;
-	case IMX7D:
-	case IMX8MQ:
-	case IMX8MQ_EP:
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		reset_control_assert(imx6_pcie->apps_reset);
+	default:
 		break;
 	}
+
+	reset_control_assert(imx6_pcie->apps_reset);
 }
 
 static int imx6_pcie_start_link(struct dw_pcie *pci)
@@ -1287,36 +1265,24 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "failed to get pcie phy\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-
-		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
-									    "pciephy");
-		if (IS_ERR(imx6_pcie->pciephy_reset)) {
-			dev_err(dev, "Failed to get PCIEPHY reset control\n");
-			return PTR_ERR(imx6_pcie->pciephy_reset);
-		}
-
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
-		if (IS_ERR(imx6_pcie->apps_reset)) {
-			dev_err(dev, "Failed to get PCIE APPS reset control\n");
-			return PTR_ERR(imx6_pcie->apps_reset);
-		}
-		break;
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
-									 "apps");
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_APP_RESET)) {
+		imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev, "apps");
 		if (IS_ERR(imx6_pcie->apps_reset))
 			return dev_err_probe(dev, PTR_ERR(imx6_pcie->apps_reset),
 					     "failed to get pcie apps reset control\n");
+	}
 
-		break;
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_PHY_RESET)) {
+		imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev, "pciephy");
+		if (IS_ERR(imx6_pcie->pciephy_reset))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->pciephy_reset),
+					     "Failed to get PCIEPHY reset control\n");
+	}
+
+	switch (imx6_pcie->drvdata->variant) {
+	case IMX7D:
+		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
+			imx6_pcie->controller_id = 1;
 	default:
 		break;
 	}
@@ -1438,31 +1404,39 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
+		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
+		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
 		.flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND |
-			 IMX6_PCIE_FLAG_HAS_PHY,
+			 IMX6_PCIE_FLAG_HAS_PHY |
+			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
+			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:15 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:15 -0500
Subject: [PATCH v7 04/16] dt-bindings: imx6q-pcie: Add linux,pci-domain as required for iMX8MQ
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-5-Frank.Li@nxp.com>

iMX8MQ have two pci controllers. Adds "linux,pci-domain" as required
proptery for iMX8MQ to indicate pci controller index.

This adjustment paves the way for eliminating the hardcoded check on the
base register for acquiring the controller_id.

	...
	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
		imx6_pcie->controller_id = 1;
	...

The controller_id is crucial and utilized for certain register bit
positions. It must align precisely with the controller index in the SoC.
An auto-incremented ID don't fit this case. The DTS or fuse configurations
may deactivate specific PCI controllers.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v5 to v6
    - rework commit message to explain why need required and why auto increase
    id not work
    
    Change from v4 to v5
    - new patch at v5

 .../bindings/pci/fsl,imx6q-pcie-common.yaml           | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index d91b639ae7ae7..8f39b4e6e8491 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -265,6 +265,17 @@ allOf:
             - const: apps
             - const: turnoff
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fsl,imx8mq-pcie
+              - fsl,imx8mq-pcie-ep
+    then:
+      required:
+        - linux,pci-domain
+
 additionalProperties: true
 
 ...
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:16 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:16 -0500
Subject: [PATCH v7 05/16] PCI: imx6: Using "linux,pci-domain" as slot ID
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-6-Frank.Li@nxp.com>

Avoid use get slot id by compared with register physical address. If there
are more than 2 slots, compared logic will become complex.

"linux,pci-domain" already exist at dts since commit:
	commit (c0b70f05c87f3b arm64: dts: imx8mq: use_dt_domains for pci node).

So it is safe to remove compare basic address code:
	...
	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
		imx6_pcie->controller_id = 1;
	...

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v3 to v4
    - remove compare basic address logic
    Change from v2 to v3
    - none
    Change from v1 to v2
    - fix of_get_pci_domain_nr return value check logic

 drivers/pci/controller/dwc/pci-imx6.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 294f61a9c6fd9..332c392f8e5bc 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -33,6 +33,7 @@
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 
+#include "../../pci.h"
 #include "pcie-designware.h"
 
 #define IMX8MQ_GPR_PCIE_REF_USE_PAD		BIT(9)
@@ -40,7 +41,6 @@
 #define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE	BIT(11)
 #define IMX8MQ_GPR_PCIE_VREG_BYPASS		BIT(12)
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
-#define IMX8MQ_PCIE2_BASE_ADDR			0x33c00000
 
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
@@ -1279,13 +1279,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "Failed to get PCIEPHY reset control\n");
 	}
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX7D:
-		if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
-			imx6_pcie->controller_id = 1;
-	default:
-		break;
-	}
+	/* Using linux,pci-domain as PCI slot id */
+	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
+	/* If there are not "linux,pci-domain" in dts file, means only 1 controller */
+	if (imx6_pcie->controller_id == -EINVAL)
+		imx6_pcie->controller_id = 0;
+	else if (imx6_pcie->controller_id < 0)
+		return dev_err_probe(dev, imx6_pcie->controller_id,
+				     "linux,pci-domain have wrong value\n");
 
 	/* Grab turnoff reset */
 	imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:17 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:17 -0500
Subject: [PATCH v7 06/16] PCI: imx6: Simplify ltssm_enable() by using ltssm_off and ltssm_mask
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-7-Frank.Li@nxp.com>

Add drvdata::ltssm_off and drvdata::ltssm_mask to simple
imx6_pcie_ltssm_enable(disable)() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 37 ++++++++++++---------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 332c392f8e5bc..588bfb616260e 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,8 @@ struct imx6_pcie_drvdata {
 	int dbi_length;
 	const char *gpr;
 	const char *clk_names[IMX6_PCIE_MAX_CLKS];
+	const u32 ltssm_off;
+	const u32 ltssm_mask;
 };
 
 struct imx6_pcie {
@@ -775,18 +777,11 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
 static void imx6_pcie_ltssm_enable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2,
-				   IMX6Q_GPR12_PCIE_CTL_2);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off, drvdata->ltssm_mask,
+				   drvdata->ltssm_mask);
 
 	reset_control_deassert(imx6_pcie->apps_reset);
 }
@@ -794,17 +789,11 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 static void imx6_pcie_ltssm_disable(struct device *dev)
 {
 	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX6Q:
-	case IMX6SX:
-	case IMX6QP:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2, 0);
-		break;
-	default:
-		break;
-	}
+	if (drvdata->ltssm_mask)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->ltssm_off,
+				   drvdata->ltssm_mask, 0);
 
 	reset_control_assert(imx6_pcie->apps_reset);
 }
@@ -1385,6 +1374,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1393,6 +1384,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_inbound_axi"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1402,6 +1395,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.dbi_length = 0x200,
 		.gpr = "fsl,imx6q-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
+		.ltssm_off = IOMUXC_GPR12,
+		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:18 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:18 -0500
Subject: [PATCH v7 07/16] PCI: imx6: Simplify configure_type() by using mode_off and mode_mask
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-8-Frank.Li@nxp.com>

Add drvdata::mode_off and drvdata::mode_mask to simple
imx6_pcie_configure_type() logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v2 to v3
    - none
    Change from v1 to v2
    - use ffs() to fixe build error.

 drivers/pci/controller/dwc/pci-imx6.c | 60 ++++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 588bfb616260e..717e8fa030deb 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -68,6 +68,7 @@ enum imx6_pcie_variants {
 
 #define IMX6_PCIE_MAX_CLKS       6
 
+#define IMX6_PCIE_MAX_INSTANCES			2
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -77,6 +78,8 @@ struct imx6_pcie_drvdata {
 	const char *clk_names[IMX6_PCIE_MAX_CLKS];
 	const u32 ltssm_off;
 	const u32 ltssm_mask;
+	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
+	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
 };
 
 struct imx6_pcie {
@@ -174,32 +177,25 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
-	unsigned int mask, val, mode;
+	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
+	unsigned int mask, val, mode, id;
 
-	if (imx6_pcie->drvdata->mode == DW_PCIE_EP_TYPE)
+	if (drvdata->mode == DW_PCIE_EP_TYPE)
 		mode = PCI_EXP_TYPE_ENDPOINT;
 	else
 		mode = PCI_EXP_TYPE_ROOT_PORT;
 
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		if (imx6_pcie->controller_id == 1) {
-			mask = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
-					  mode);
-		} else {
-			mask = IMX6Q_GPR12_DEVICE_TYPE;
-			val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		}
-		break;
-	default:
-		mask = IMX6Q_GPR12_DEVICE_TYPE;
-		val  = FIELD_PREP(IMX6Q_GPR12_DEVICE_TYPE, mode);
-		break;
-	}
+	id = imx6_pcie->controller_id;
+
+	/* If mode_mask[id] is zero, means each controller have its individual gpr */
+	if (!drvdata->mode_mask[id])
+		id = 0;
+
+	mask = drvdata->mode_mask[id];
+	/* FIELD_PREP mask have been constant */
+	val = mode << (ffs(mask) - 1);
 
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, mask, val);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, drvdata->mode_off[id], mask, val);
 }
 
 static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
@@ -1376,6 +1372,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1386,6 +1384,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_inbound_axi"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1397,6 +1397,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 		.ltssm_off = IOMUXC_GPR12,
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1405,6 +1407,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx7d-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1412,6 +1416,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_PHY_RESET,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1420,6 +1428,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP] = {
 		.variant = IMX8MP,
@@ -1428,6 +1438,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 			 IMX6_PCIE_FLAG_HAS_APP_RESET,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
@@ -1436,6 +1448,10 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mq-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.mode_off[1] = IOMUXC_GPR12,
+		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
@@ -1443,6 +1459,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mm-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
@@ -1450,6 +1468,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode = DW_PCIE_EP_TYPE,
 		.gpr = "fsl,imx8mp-iomuxc-gpr",
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
+		.mode_off[0] = IOMUXC_GPR12,
+		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:19 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:19 -0500
Subject: [PATCH v7 08/16] PCI: imx6: Simplify switch-case logic by involve init_phy callback
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-9-Frank.Li@nxp.com>

Add drvdata::init_phy() callback function, so difference SOC choose
difference callback function to simple switch-case logic.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    change from v1 to v4:
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 135 ++++++++++++++------------
 1 file changed, 71 insertions(+), 64 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 717e8fa030deb..d66a2db53bdb7 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -69,6 +69,9 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_MAX_CLKS       6
 
 #define IMX6_PCIE_MAX_INSTANCES			2
+
+struct imx6_pcie;
+
 struct imx6_pcie_drvdata {
 	enum imx6_pcie_variants variant;
 	enum dw_pcie_device_mode mode;
@@ -80,6 +83,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
 struct imx6_pcie {
@@ -323,76 +327,69 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
 	return 0;
 }
 
-static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+static int imx8mq_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
-	switch (imx6_pcie->drvdata->variant) {
-	case IMX8MM:
-	case IMX8MM_EP:
-	case IMX8MP:
-	case IMX8MP_EP:
-		/*
-		 * The PHY initialization had been done in the PHY
-		 * driver, break here directly.
-		 */
-		break;
-	case IMX8MQ:
-	case IMX8MQ_EP:
-		/*
-		 * TODO: Currently this code assumes external
-		 * oscillator is being used
-		 */
+	/*
+	 * TODO: Currently this code assumes external
+	 * oscillator is being used
+	 */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   imx6_pcie_grp_offset(imx6_pcie),
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD,
+			   IMX8MQ_GPR_PCIE_REF_USE_PAD);
+	/*
+	 * Regarding the datasheet, the PCIE_VPH is suggested
+	 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
+	 * VREG_BYPASS should be cleared to zero.
+	 */
+	if (imx6_pcie->vph && regulator_get_voltage(imx6_pcie->vph) > 3000000)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr,
 				   imx6_pcie_grp_offset(imx6_pcie),
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD,
-				   IMX8MQ_GPR_PCIE_REF_USE_PAD);
-		/*
-		 * Regarding the datasheet, the PCIE_VPH is suggested
-		 * to be 1.8V. If the PCIE_VPH is supplied by 3.3V, the
-		 * VREG_BYPASS should be cleared to zero.
-		 */
-		if (imx6_pcie->vph &&
-		    regulator_get_voltage(imx6_pcie->vph) > 3000000)
-			regmap_update_bits(imx6_pcie->iomuxc_gpr,
-					   imx6_pcie_grp_offset(imx6_pcie),
-					   IMX8MQ_GPR_PCIE_VREG_BYPASS,
-					   0);
-		break;
-	case IMX7D:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX8MQ_GPR_PCIE_VREG_BYPASS,
+				   0);
+
+	return 0;
+}
+
+static int imx7d_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	return	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
-		break;
-	case IMX6SX:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6SX_GPR12_PCIE_RX_EQ_MASK,
-				   IMX6SX_GPR12_PCIE_RX_EQ_2);
-		fallthrough;
-	default:
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+}
+
+static int imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 
-		/* configure constant input signal to the pcie ctrl and phy */
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
-
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN1,
-				   imx6_pcie->tx_deemph_gen1 << 0);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
-				   imx6_pcie->tx_deemph_gen2_3p5db << 6);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
-				   imx6_pcie->tx_deemph_gen2_6db << 12);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_FULL,
-				   imx6_pcie->tx_swing_full << 18);
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-				   IMX6Q_GPR8_TX_SWING_LOW,
-				   imx6_pcie->tx_swing_low << 25);
-		break;
-	}
+	/* configure constant input signal to the pcie ctrl and phy */
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN1,
+			   imx6_pcie->tx_deemph_gen1 << 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
+			   imx6_pcie->tx_deemph_gen2_3p5db << 6);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
+			   imx6_pcie->tx_deemph_gen2_6db << 12);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_FULL,
+			   imx6_pcie->tx_swing_full << 18);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+			   IMX6Q_GPR8_TX_SWING_LOW,
+			   imx6_pcie->tx_swing_low << 25);
+	return 0;
+}
 
-	imx6_pcie_configure_type(imx6_pcie);
+static int imx6sx_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			   IMX6SX_GPR12_PCIE_RX_EQ_MASK, IMX6SX_GPR12_PCIE_RX_EQ_2);
+
+	return imx6_pcie_init_phy(imx6_pcie);
 }
 
 static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
@@ -903,7 +900,11 @@ static int imx6_pcie_host_init(struct dw_pcie_rp *pp)
 	}
 
 	imx6_pcie_assert_core_reset(imx6_pcie);
-	imx6_pcie_init_phy(imx6_pcie);
+
+	if (imx6_pcie->drvdata->init_phy)
+		imx6_pcie->drvdata->init_phy(imx6_pcie);
+
+	imx6_pcie_configure_type(imx6_pcie);
 
 	ret = imx6_pcie_clk_enable(imx6_pcie);
 	if (ret) {
@@ -1374,6 +1375,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX6SX] = {
 		.variant = IMX6SX,
@@ -1386,6 +1388,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6sx_pcie_init_phy,
 	},
 	[IMX6QP] = {
 		.variant = IMX6QP,
@@ -1399,6 +1402,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.ltssm_mask = IMX6Q_GPR12_PCIE_CTL_2,
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx6_pcie_init_phy,
 	},
 	[IMX7D] = {
 		.variant = IMX7D,
@@ -1409,6 +1413,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_phy"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.init_phy = imx7d_pcie_init_phy,
 	},
 	[IMX8MQ] = {
 		.variant = IMX8MQ,
@@ -1420,6 +1425,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM] = {
 		.variant = IMX8MM,
@@ -1452,6 +1458,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
 		.variant = IMX8MM_EP,
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:20 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:20 -0500
Subject: [PATCH v7 09/16] dt-bindings: imx6q-pcie: Clean up irrationality clocks check
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-10-Frank.Li@nxp.com>

The bindings referencing this file already define these constraints for
each of the variants, so the if not: then: is redundant.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v6 to v7
    - rewrite git commit message by using simple words
    Change from v5 to v6
    - rewrite git commit message and explain why remove it safely.
    - Add Rob's Ack
    Change from v1 to v4
    - new patch at v4

 .../bindings/pci/fsl,imx6q-pcie-common.yaml      | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index 8f39b4e6e8491..a284a27c5e873 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -150,22 +150,6 @@ allOf:
             - {}
             - const: pcie_phy
             - const: pcie_aux
-  - if:
-      properties:
-        compatible:
-          not:
-            contains:
-              enum:
-                - fsl,imx6sx-pcie
-                - fsl,imx8mq-pcie
-                - fsl,imx6sx-pcie-ep
-                - fsl,imx8mq-pcie-ep
-    then:
-      properties:
-        clocks:
-          maxItems: 3
-        clock-names:
-          maxItems: 3
 
   - if:
       properties:
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:21 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:21 -0500
Subject: [PATCH v7 10/16] dt-bindings: imx6q-pcie: restruct reg and reg-name
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-11-Frank.Li@nxp.com>

snps,dw-pcie.yaml already have reg and reg-name information. Needn't
duplciate here.

Add 'if' check for existed compatible string to restrict reg and reg-names.
This prepare to add new compatible string with difference reg-names sets.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v6 to v7
    - add Krzysztof's review tag
    Change from v5 to v6
    - Add if check for existed compatible string
    Change from v4 to v5
    - add Rob's Acked
    Change from v1 to v4:
    - new patch at v4

 .../bindings/pci/fsl,imx6q-pcie.yaml          | 30 ++++++++++++-------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 81bbb8728f0f9..eeca6b7b540f9 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -30,16 +30,6 @@ properties:
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
 
-  reg:
-    items:
-      - description: Data Bus Interface (DBI) registers.
-      - description: PCIe configuration space region.
-
-  reg-names:
-    items:
-      - const: dbi
-      - const: config
-
   clocks:
     minItems: 3
     items:
@@ -90,6 +80,26 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx6q-pcie
+            - fsl,imx6sx-pcie
+            - fsl,imx6qp-pcie
+            - fsl,imx7d-pcie
+            - fsl,imx8mq-pcie
+            - fsl,imx8mm-pcie
+            - fsl,imx8mp-pcie
+    then:
+      properties:
+        reg:
+          maxItems: 2
+        reg-names:
+          items:
+            - const: dbi
+            - const: config
+
   - if:
       properties:
         compatible:
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:22 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:22 -0500
Subject: [PATCH v7 11/16] dt-bindings: imx6q-pcie: Add imx95 pcie compatible string
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-12-Frank.Li@nxp.com>

From: Richard Zhu <hongxing.zhu at nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie" compatible string.
Add "atu" and "app" to reg-names.

Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v6 to v7
    - Added my sign off
    
    Change from v5 to v6
    - move atu and app after config
    
    Change from v2 to v3
    - Remove krzy's ACK tag
    - Add condition check for imx95, which required more reg-names then old
    platform, so need Krzy review again,
    
    Change from v1 to v2
    - add Krzy's ACK tag

 .../bindings/pci/fsl,imx6q-pcie-common.yaml   |  1 +
 .../bindings/pci/fsl,imx6q-pcie.yaml          | 19 +++++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
index a284a27c5e873..1b63089ff0aee 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -207,6 +207,7 @@ allOf:
                 - fsl,imx6sx-pcie
                 - fsl,imx6q-pcie
                 - fsl,imx6qp-pcie
+                - fsl,imx95-pcie
                 - fsl,imx6sx-pcie-ep
                 - fsl,imx6q-pcie-ep
                 - fsl,imx6qp-pcie-ep
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index eeca6b7b540f9..8b8d77b1154b5 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -29,6 +29,7 @@ properties:
       - fsl,imx8mq-pcie
       - fsl,imx8mm-pcie
       - fsl,imx8mp-pcie
+      - fsl,imx95-pcie
 
   clocks:
     minItems: 3
@@ -100,6 +101,23 @@ allOf:
             - const: dbi
             - const: config
 
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie
+    then:
+      properties:
+        reg:
+          minItems: 4
+          maxItems: 4
+        reg-names:
+          items:
+            - const: dbi
+            - const: config
+            - const: atu
+            - const: app
+
   - if:
       properties:
         compatible:
@@ -121,6 +139,7 @@ allOf:
         compatible:
           enum:
             - fsl,imx8mq-pcie
+            - fsl,imx95-pcie
     then:
       properties:
         clocks:
-- 
2.34.1



From mrman at mrman314.tech  Wed Dec 27 10:19:39 2023
From: mrman at mrman314.tech (Felix Zhang)
Date: Wed, 27 Dec 2023 13:19:39 -0500
Subject: [PATCH] Bluetooth: hci_bcm4377: do not mark valid bd_addr as
 invalid
In-Reply-To: <20231227101003.10534-1-johan+linaro@kernel.org>
References: <20231227101003.10534-1-johan+linaro@kernel.org>
Message-ID: <f06dbc4d10ff5eb038228e9c7abb75c85514cf36.camel@mrman314.tech>

On Wed, 2023-12-27 at 11:10 +0100, Johan Hovold wrote:
> A recent commit restored the original (and still documented)
> semantics
> for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device
> address
> is considered invalid unless an address is provided by firmware.
> 
> This specifically means that this flag must only be set for devices
> with
> invalid addresses, but the Broadcom BCM4377 driver has so far been
> setting this flag unconditionally.
> 
> Fortunately the driver already checks for invalid addresses during
> setup
> and sets the HCI_QUIRK_INVALID_BDADDR flag, which can simply be
> replaced
> with HCI_QUIRK_USE_BDADDR_PROPERTY to indicate that the default
> address
> is invalid but can be overridden by firmware (long term, this should
> probably just always be allowed).
> 
> Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk")
> Cc: stable at vger.kernel.org????? # 6.5
> Reported-by: Felix Zhang <mrman at mrman314.tech>
> Link:
> https://lore.kernel.org/r/77419ffacc5b4875e920e038332575a2a5bff29f.camel at mrman314.tech/
> Signed-off-by: Johan Hovold <johan+linaro at kernel.org>
> ---
> ?drivers/bluetooth/hci_bcm4377.c | 3 +--
> ?1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/bluetooth/hci_bcm4377.c
> b/drivers/bluetooth/hci_bcm4377.c
> index a61757835695..9a7243d5db71 100644
> --- a/drivers/bluetooth/hci_bcm4377.c
> +++ b/drivers/bluetooth/hci_bcm4377.c
> @@ -1417,7 +1417,7 @@ static int bcm4377_check_bdaddr(struct
> bcm4377_data *bcm4377)
> ?
> ?	bda = (struct hci_rp_read_bd_addr *)skb->data;
> ?	if (!bcm4377_is_valid_bdaddr(bcm4377, &bda->bdaddr))
> -		set_bit(HCI_QUIRK_INVALID_BDADDR, &bcm4377->hdev-
> >quirks);
> +		set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &bcm4377-
> >hdev->quirks);
> ?
> ?	kfree_skb(skb);
> ?	return 0;
> @@ -2368,7 +2368,6 @@ static int bcm4377_probe(struct pci_dev *pdev,
> const struct pci_device_id *id)
> ?	hdev->set_bdaddr = bcm4377_hci_set_bdaddr;
> ?	hdev->setup = bcm4377_hci_setup;
> ?
> -	set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
> ?	if (bcm4377->hw->broken_mws_transport_config)
> ?		set_bit(HCI_QUIRK_BROKEN_MWS_TRANSPORT_CONFIG,
> &hdev->quirks);
> ?	if (bcm4377->hw->broken_ext_scan)
Hi,

Thanks for the patch!  I have just tested the patch on my MacBookAir9,1
with some modifications to make it patch with the master branch of the
Linux kernel, and it works great!  The device is recognized by the
system; and I can scan, pair, connect, and play audio just fine.  If
you want me to send over the modified patch that I have used, please
let me know.

Thanks!


From Frank.Li at nxp.com  Wed Dec 27 10:27:23 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:23 -0500
Subject: [PATCH v7 12/16] PCI: imx6: Add iMX95 PCIe support
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-13-Frank.Li@nxp.com>

Add iMX95 PCIe basic root complex function support.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - none

 drivers/pci/controller/dwc/pci-imx6.c | 90 +++++++++++++++++++++++++--
 1 file changed, 85 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index d66a2db53bdb7..9e60ab6f1885a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -42,6 +42,25 @@
 #define IMX8MQ_GPR_PCIE_VREG_BYPASS		BIT(12)
 #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE	GENMASK(11, 8)
 
+#define IMX95_PCIE_PHY_GEN_CTRL			0x0
+#define IMX95_PCIE_REF_USE_PAD			BIT(17)
+
+#define IMX95_PCIE_PHY_MPLLA_CTRL		0x10
+#define IMX95_PCIE_PHY_MPLL_STATE		BIT(30)
+
+#define IMX95_PCIE_SS_RW_REG_0			0xf0
+#define IMX95_PCIE_REF_CLKEN			BIT(23)
+#define IMX95_PCIE_PHY_CR_PARA_SEL		BIT(9)
+
+#define IMX95_PE0_GEN_CTRL_1			0x1050
+#define IMX95_PCIE_DEVICE_TYPE			GENMASK(3, 0)
+
+#define IMX95_PE0_GEN_CTRL_3			0x1058
+#define IMX95_PCIE_LTSSM_EN			BIT(0)
+
+#define IMX95_PE0_PM_STS			0x1064
+#define IMX95_PCIE_PM_LINKST_IN_L2		BIT(14)
+
 #define to_imx6_pcie(x)	dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -52,6 +71,7 @@ enum imx6_pcie_variants {
 	IMX8MQ,
 	IMX8MM,
 	IMX8MP,
+	IMX95,
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
@@ -63,6 +83,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_PHY			BIT(3)
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
+#define IMX6_PCIE_FLAG_HAS_SERDES		BIT(6)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -179,6 +200,24 @@ static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
 	return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
 }
 
+static int imx95_pcie_init_phy(struct imx6_pcie *imx6_pcie)
+{
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			IMX95_PCIE_SS_RW_REG_0,
+			IMX95_PCIE_PHY_CR_PARA_SEL,
+			IMX95_PCIE_PHY_CR_PARA_SEL);
+
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_PHY_GEN_CTRL,
+			   IMX95_PCIE_REF_USE_PAD, 0);
+	regmap_update_bits(imx6_pcie->iomuxc_gpr,
+			   IMX95_PCIE_SS_RW_REG_0,
+			   IMX95_PCIE_REF_CLKEN,
+			   IMX95_PCIE_REF_CLKEN);
+
+	return 0;
+}
+
 static void imx6_pcie_configure_type(struct imx6_pcie *imx6_pcie)
 {
 	const struct imx6_pcie_drvdata *drvdata = imx6_pcie->drvdata;
@@ -579,6 +618,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
 		break;
 	case IMX7D:
+	case IMX95:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -696,10 +736,19 @@ static int imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 {
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
+	u32 val;
 
 	reset_control_deassert(imx6_pcie->pciephy_reset);
 
 	switch (imx6_pcie->drvdata->variant) {
+	case IMX95:
+		/* Polling the MPLL_STATE */
+		if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+					IMX95_PCIE_PHY_MPLLA_CTRL, val,
+					val & IMX95_PCIE_PHY_MPLL_STATE,
+					10, 10000))
+			dev_err(dev, "PCIe PLL lock timeout\n");
+		break;
 	case IMX7D:
 		/* Workaround for ERR010728, failure of PCI-e PLL VCO to
 		 * oscillate, especially when cold.  This turns off "Duty-cycle
@@ -1281,12 +1330,32 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(imx6_pcie->turnoff_reset);
 	}
 
+	if (imx6_pcie->drvdata->gpr) {
 	/* Grab GPR config register range */
-	imx6_pcie->iomuxc_gpr =
-		 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
-	if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
-		dev_err(dev, "unable to find iomuxc registers\n");
-		return PTR_ERR(imx6_pcie->iomuxc_gpr);
+		imx6_pcie->iomuxc_gpr =
+			 syscon_regmap_lookup_by_compatible(imx6_pcie->drvdata->gpr);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
+	}
+
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_HAS_SERDES)) {
+		void __iomem *off = devm_platform_ioremap_resource_byname(pdev, "app");
+
+		if (IS_ERR(off))
+			return dev_err_probe(dev, PTR_ERR(off),
+					     "unable to find serdes registers\n");
+
+		static struct regmap_config regmap_config = {
+			.reg_bits = 32,
+			.val_bits = 32,
+			.reg_stride = 4,
+		};
+
+		imx6_pcie->iomuxc_gpr = devm_regmap_init_mmio(dev, off, &regmap_config);
+		if (IS_ERR(imx6_pcie->iomuxc_gpr))
+			return dev_err_probe(dev, PTR_ERR(imx6_pcie->iomuxc_gpr),
+					     "unable to find iomuxc registers\n");
 	}
 
 	/* Grab PCIe PHY Tx Settings */
@@ -1447,6 +1516,16 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 	},
+	[IMX95] = {
+		.variant = IMX95,
+		.flags = IMX6_PCIE_FLAG_HAS_SERDES,
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+	},
 	[IMX8MQ_EP] = {
 		.variant = IMX8MQ_EP,
 		.flags = IMX6_PCIE_FLAG_HAS_APP_RESET |
@@ -1488,6 +1567,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie", .data = &drvdata[IMX8MQ], },
 	{ .compatible = "fsl,imx8mm-pcie", .data = &drvdata[IMX8MM], },
 	{ .compatible = "fsl,imx8mp-pcie", .data = &drvdata[IMX8MP], },
+	{ .compatible = "fsl,imx95-pcie", .data = &drvdata[IMX95], },
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:24 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:24 -0500
Subject: [PATCH v7 13/16] PCI: imx6: Clean up get addr_space code
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-14-Frank.Li@nxp.com>

The common dw_pcie_ep_init() already do the same thing. Needn't platform
driver do it again.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches

 drivers/pci/controller/dwc/pci-imx6.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 9e60ab6f1885a..4b2b9aafad1b4 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1080,7 +1080,6 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 	int ret;
 	unsigned int pcie_dbi2_offset;
 	struct dw_pcie_ep *ep;
-	struct resource *res;
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct dw_pcie_rp *pp = &pci->pp;
 	struct device *dev = pci->dev;
@@ -1099,14 +1098,8 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 		pcie_dbi2_offset = SZ_4K;
 		break;
 	}
-	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
-	if (!res)
-		return -EINVAL;
 
-	ep->phys_base = res->start;
-	ep->addr_size = resource_size(res);
-	ep->page_size = SZ_64K;
+	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:25 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:25 -0500
Subject: [PATCH v7 14/16] PCI: imx6: Add epc_features in imx6_pcie_drvdata
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-15-Frank.Li@nxp.com>

The i.MX EP exhibits variations in epc_features among different EP
configurations. This introduces the addition of epc_features in
imx6_pcie_drvdata to accommodate these differences. It's important to note
that there are no functional changes in this commit; instead, it lays the
groundwork for supporting i.MX95 EP functions.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v5 to v6
    - add missed maxitems.
    - add comments about reuse linux,pci-domain as controller id.
    linux,pci-domain have not defined at PCI endpoint side.
    
    Change from v1 to v3
    - new patch at v3

 drivers/pci/controller/dwc/pci-imx6.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 4b2b9aafad1b4..6a58fd63a9dd2 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -104,6 +104,7 @@ struct imx6_pcie_drvdata {
 	const u32 ltssm_mask;
 	const u32 mode_off[IMX6_PCIE_MAX_INSTANCES];
 	const u32 mode_mask[IMX6_PCIE_MAX_INSTANCES];
+	const struct pci_epc_features *epc_features;
 	int (*init_phy)(struct imx6_pcie *pcie);
 };
 
@@ -1065,7 +1066,10 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
-	return &imx8m_pcie_epc_features;
+	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pci);
+
+	return imx6_pcie->drvdata->epc_features;
 }
 
 static const struct dw_pcie_ep_ops pcie_ep_ops = {
@@ -1530,6 +1534,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.mode_off[1] = IOMUXC_GPR12,
 		.mode_mask[1] = IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 		.init_phy = imx8mq_pcie_init_phy,
 	},
 	[IMX8MM_EP] = {
@@ -1540,6 +1545,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 	[IMX8MP_EP] = {
 		.variant = IMX8MP_EP,
@@ -1549,6 +1555,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.clk_names = {"pcie_bus", "pcie", "pcie_aux"},
 		.mode_off[0] = IOMUXC_GPR12,
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
+		.epc_features = &imx8m_pcie_epc_features,
 	},
 };
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:26 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:26 -0500
Subject: [PATCH v7 15/16] dt-bindings: imx6q-pcie: Add iMX95 pcie endpoint compatible string
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-16-Frank.Li@nxp.com>

Add i.MX95 PCIe "fsl,imx95-pcie-ep" compatible string.
Add reg-name: "atu", "dbi2", "dma" and "app".
Reuse PCI linux,pci-domain as controller id at endpoint.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v1 to v3
    - new patches at v3

 .../bindings/pci/fsl,imx6q-pcie-ep.yaml       | 57 ++++++++++++++++---
 1 file changed, 49 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
index ee155ed5f1811..f4d6ae5dab785 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
@@ -22,14 +22,7 @@ properties:
       - fsl,imx8mm-pcie-ep
       - fsl,imx8mq-pcie-ep
       - fsl,imx8mp-pcie-ep
-
-  reg:
-    minItems: 2
-
-  reg-names:
-    items:
-      - const: dbi
-      - const: addr_space
+      - fsl,imx95-pcie-ep
 
   clocks:
     minItems: 3
@@ -62,11 +55,48 @@ required:
 allOf:
   - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
   - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx8mm-pcie-ep
+            - fsl,imx8mq-pcie-ep
+            - fsl,imx8mp-pcie-ep
+    then:
+      properties:
+        reg:
+          minItems: 2
+          maxItems: 2
+        reg-names:
+          items:
+            - const: dbi
+            - const: addr_space
+
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie-ep
+    then:
+      properties:
+        reg:
+          minItems: 6
+          maxItems: 6
+        reg-names:
+          items:
+            - const: dbi
+            - const: atu
+            - const: dbi2
+            - const: app
+            - const: dma
+            - const: addr_space
+
   - if:
       properties:
         compatible:
           enum:
             - fsl,imx8mq-pcie-ep
+            - fsl,imx95-pcie-ep
     then:
       properties:
         clocks:
@@ -87,6 +117,17 @@ allOf:
             - const: pcie_bus
             - const: pcie_aux
 
+# reuse PCI linux,pci-domain as controller id at Endpoint
+  - if:
+      properties:
+        compatible:
+          enum:
+            - fsl,imx95-pcie-ep
+    then:
+      properties:
+        linux,pci-domain: true
+      required:
+        - linux,pci-domain
 
 unevaluatedProperties: false
 
-- 
2.34.1



From Frank.Li at nxp.com  Wed Dec 27 10:27:27 2023
From: Frank.Li at nxp.com (Frank Li)
Date: Wed, 27 Dec 2023 13:27:27 -0500
Subject: [PATCH v7 16/16] PCI: imx6: Add iMX95 Endpoint (EP) function support
In-Reply-To: <20231227182727.1747435-1-Frank.Li@nxp.com>
References: <20231227182727.1747435-1-Frank.Li@nxp.com>
Message-ID: <20231227182727.1747435-17-Frank.Li@nxp.com>

Add iMX95 EP function support and add 64bit address support. Internal bus
bridge for PCI support 64bit dma address in iMX95. So set call
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)).

Signed-off-by: Frank Li <Frank.Li at nxp.com>
---

Notes:
    Change from v3 to v4
    - change align to 4k for imx95
    Change from v1 to v3
    - new patches at v3

 drivers/pci/controller/dwc/pci-imx6.c | 45 +++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 6a58fd63a9dd2..00ec59867c17b 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -75,6 +75,7 @@ enum imx6_pcie_variants {
 	IMX8MQ_EP,
 	IMX8MM_EP,
 	IMX8MP_EP,
+	IMX95_EP,
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHY			BIT(0)
@@ -84,6 +85,7 @@ enum imx6_pcie_variants {
 #define IMX6_PCIE_FLAG_HAS_APP_RESET		BIT(4)
 #define IMX6_PCIE_FLAG_HAS_PHY_RESET		BIT(5)
 #define IMX6_PCIE_FLAG_HAS_SERDES		BIT(6)
+#define IMX6_PCIE_FLAG_SUPPORT_64BIT		BIT(7)
 
 #define imx6_check_flag(pci, val)     (pci->drvdata->flags & val)
 
@@ -620,6 +622,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 		break;
 	case IMX7D:
 	case IMX95:
+	case IMX95_EP:
 		break;
 	case IMX8MM:
 	case IMX8MM_EP:
@@ -1063,6 +1066,23 @@ static const struct pci_epc_features imx8m_pcie_epc_features = {
 	.align = SZ_64K,
 };
 
+/*
+ * BAR#	| Default BAR enable	| Default BAR Type	| Default BAR Size	| BAR Sizing Scheme
+ * ================================================================================================
+ * BAR0	| Enable		| 64-bit		| 1 MB			| Programmable Size
+ * BAR1	| Disable		| 32-bit		| 64 KB			| Fixed Size
+ *	| (BAR0 is 64-bit)	| if BAR0 is 32-bit	|			| As Bar0 is 64bit
+ * BAR2	| Enable		| 32-bit		| 1 MB			| Programmable Size
+ * BAR3	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ * BAR4	| Enable		| 32-bit		| 1M			| Programmable Size
+ * BAR5	| Enable		| 32-bit		| 64 KB			| Programmable Size
+ */
+static const struct pci_epc_features imx95_pcie_epc_features = {
+	.msi_capable = true,
+	.bar_fixed_size[1] = SZ_64K,
+	.align = SZ_4K,
+};
+
 static const struct pci_epc_features*
 imx6_pcie_ep_get_features(struct dw_pcie_ep *ep)
 {
@@ -1105,6 +1125,14 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
 
 	pci->dbi_base2 = pci->dbi_base + pcie_dbi2_offset;
 
+	/*
+	 * db2 information should fetch from dtb file. dw_pcie_ep_init() can get dbi_base2 from
+	 * "dbi2" if pci->dbi_base2 is NULL. All code related pcie_dbi2_offset should be removed
+	 * after all dts added "dbi2" reg.
+	 */
+	if (imx6_pcie->drvdata->variant == IMX95_EP)
+		pci->dbi_base2 = NULL;
+
 	ret = dw_pcie_ep_init(ep);
 	if (ret) {
 		dev_err(dev, "failed to initialize endpoint\n");
@@ -1355,6 +1383,9 @@ static int imx6_pcie_probe(struct platform_device *pdev)
 					     "unable to find iomuxc registers\n");
 	}
 
+	if (imx6_check_flag(imx6_pcie, IMX6_PCIE_FLAG_SUPPORT_64BIT))
+		dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+
 	/* Grab PCIe PHY Tx Settings */
 	if (of_property_read_u32(node, "fsl,tx-deemph-gen1",
 				 &imx6_pcie->tx_deemph_gen1))
@@ -1557,6 +1588,19 @@ static const struct imx6_pcie_drvdata drvdata[] = {
 		.mode_mask[0] = IMX6Q_GPR12_DEVICE_TYPE,
 		.epc_features = &imx8m_pcie_epc_features,
 	},
+	[IMX95_EP] = {
+		.variant = IMX95_EP,
+		.flags = IMX6_PCIE_FLAG_HAS_SERDES |
+			 IMX6_PCIE_FLAG_SUPPORT_64BIT,
+		.clk_names = {"pcie_bus", "pcie", "pcie_phy", "pcie_aux"},
+		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
+		.ltssm_mask = IMX95_PCIE_LTSSM_EN,
+		.mode_off[0]  = IMX95_PE0_GEN_CTRL_1,
+		.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+		.init_phy = imx95_pcie_init_phy,
+		.epc_features = &imx95_pcie_epc_features,
+		.mode = DW_PCIE_EP_TYPE,
+	},
 };
 
 static const struct of_device_id imx6_pcie_of_match[] = {
@@ -1571,6 +1615,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx8mq-pcie-ep", .data = &drvdata[IMX8MQ_EP], },
 	{ .compatible = "fsl,imx8mm-pcie-ep", .data = &drvdata[IMX8MM_EP], },
 	{ .compatible = "fsl,imx8mp-pcie-ep", .data = &drvdata[IMX8MP_EP], },
+	{ .compatible = "fsl,imx95-pcie-ep", .data = &drvdata[IMX95_EP], },
 	{},
 };
 
-- 
2.34.1



From jbx6244 at gmail.com  Wed Dec 27 10:33:11 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 27 Dec 2023 19:33:11 +0100
Subject: [PATCH v3 1/2] ARM: dts: rockchip: add gpio-ranges property to gpio
 nodes
Message-ID: <cf46c685-bf4b-63b5-0373-dd0ba70e9700@gmail.com>

Add a gpio-ranges property to Rockchip gpio nodes similar to
rk356x/rk3588 to be independent from aliases and probe order.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
Reviewed-by: Kever Yang <kever.yang at rock-chips.com>
---

Changed V3:
  reword
  rebase to new Rockchip directory
  remove unknown properties
---
 arch/arm/boot/dts/rockchip/rk3036.dtsi  | 3 +++
 arch/arm/boot/dts/rockchip/rk3066a.dtsi | 6 ++++++
 arch/arm/boot/dts/rockchip/rk3128.dtsi  | 4 ++++
 arch/arm/boot/dts/rockchip/rk3188.dtsi  | 4 ++++
 arch/arm/boot/dts/rockchip/rk322x.dtsi  | 4 ++++
 arch/arm/boot/dts/rockchip/rk3288.dtsi  | 9 +++++++++
 arch/arm/boot/dts/rockchip/rv1108.dtsi  | 4 ++++
 arch/arm/boot/dts/rockchip/rv1126.dtsi  | 5 +++++
 8 files changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
index 2b00109bea6a..6e5028b6dbfa 100644
--- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
@@ -593,6 +593,7 @@ gpio0: gpio at 2007c000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -606,6 +607,7 @@ gpio1: gpio at 20080000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -619,6 +621,7 @@ gpio2: gpio at 20084000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rk3066a.dtsi b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
index 30139f21de64..a4962b6b3f4c 100644
--- a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
@@ -285,6 +285,7 @@ gpio0: gpio at 20034000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -298,6 +299,7 @@ gpio1: gpio at 2003c000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -311,6 +313,7 @@ gpio2: gpio at 2003e000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -324,6 +327,7 @@ gpio3: gpio at 20080000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -337,6 +341,7 @@ gpio4: gpio at 20084000 {
 			clocks = <&cru PCLK_GPIO4>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -350,6 +355,7 @@ gpio6: gpio at 2000a000 {
 			clocks = <&cru PCLK_GPIO6>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 192 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index e2264c40b924..d66fcf12032e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -712,6 +712,7 @@ gpio0: gpio at 2007c000 {
 			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO0>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -723,6 +724,7 @@ gpio1: gpio at 20080000 {
 			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO1>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -734,6 +736,7 @@ gpio2: gpio at 20084000 {
 			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO2>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -745,6 +748,7 @@ gpio3: gpio at 20088000 {
 			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO3>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
diff --git a/arch/arm/boot/dts/rockchip/rk3188.dtsi b/arch/arm/boot/dts/rockchip/rk3188.dtsi
index 44b54af0bbf9..6677e4a10e5d 100644
--- a/arch/arm/boot/dts/rockchip/rk3188.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3188.dtsi
@@ -231,6 +231,7 @@ gpio0: gpio at 2000a000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -244,6 +245,7 @@ gpio1: gpio at 2003c000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -257,6 +259,7 @@ gpio2: gpio at 2003e000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -270,6 +273,7 @@ gpio3: gpio at 20080000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi b/arch/arm/boot/dts/rockchip/rk322x.dtsi
index 831561fc1814..0d4f9957b99b 100644
--- a/arch/arm/boot/dts/rockchip/rk322x.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk322x.dtsi
@@ -959,6 +959,7 @@ gpio0: gpio at 11110000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -972,6 +973,7 @@ gpio1: gpio at 11120000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -985,6 +987,7 @@ gpio2: gpio at 11130000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -998,6 +1001,7 @@ gpio3: gpio at 11140000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi b/arch/arm/boot/dts/rockchip/rk3288.dtsi
index ead343dc3df1..c5550aae4ed8 100644
--- a/arch/arm/boot/dts/rockchip/rk3288.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3288.dtsi
@@ -1461,6 +1461,7 @@ gpio0: gpio at ff750000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1474,6 +1475,7 @@ gpio1: gpio at ff780000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1487,6 +1489,7 @@ gpio2: gpio at ff790000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1500,6 +1503,7 @@ gpio3: gpio at ff7a0000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1513,6 +1517,7 @@ gpio4: gpio at ff7b0000 {
 			clocks = <&cru PCLK_GPIO4>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1526,6 +1531,7 @@ gpio5: gpio at ff7c0000 {
 			clocks = <&cru PCLK_GPIO5>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 160 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1539,6 +1545,7 @@ gpio6: gpio at ff7d0000 {
 			clocks = <&cru PCLK_GPIO6>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 192 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1552,6 +1559,7 @@ gpio7: gpio at ff7e0000 {
 			clocks = <&cru PCLK_GPIO7>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 224 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1565,6 +1573,7 @@ gpio8: gpio at ff7f0000 {
 			clocks = <&cru PCLK_GPIO8>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 256 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rv1108.dtsi b/arch/arm/boot/dts/rockchip/rv1108.dtsi
index abf3006f0a84..d12b97ee7588 100644
--- a/arch/arm/boot/dts/rockchip/rv1108.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1108.dtsi
@@ -602,6 +602,7 @@ gpio0: gpio at 20030000 {
 			clocks = <&cru PCLK_GPIO0_PMU>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -615,6 +616,7 @@ gpio1: gpio at 10310000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -628,6 +630,7 @@ gpio2: gpio at 10320000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -641,6 +644,7 @@ gpio3: gpio at 10330000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index bb603cae13df..71d091af6395 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -569,6 +569,7 @@ gpio0: gpio at ff460000 {
 			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -580,6 +581,7 @@ gpio1: gpio at ff620000 {
 			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -591,6 +593,7 @@ gpio2: gpio at ff630000 {
 			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -602,6 +605,7 @@ gpio3: gpio at ff640000 {
 			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -613,6 +617,7 @@ gpio4: gpio at ff650000 {
 			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
--
2.39.2



From jbx6244 at gmail.com  Wed Dec 27 10:34:59 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 27 Dec 2023 19:34:59 +0100
Subject: [PATCH v3 2/2] arm64: dts: rockchip: add gpio-ranges property to gpio
 nodes
In-Reply-To: <cf46c685-bf4b-63b5-0373-dd0ba70e9700@gmail.com>
References: <cf46c685-bf4b-63b5-0373-dd0ba70e9700@gmail.com>
Message-ID: <e5214570-0948-ad57-a68f-d4d9a5d23b78@gmail.com>

Add a gpio-ranges property to Rockchip gpio nodes similar to
rk356x/rk3588 to be independent from aliases and probe order.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
Reviewed-by: Kever Yang <kever.yang at rock-chips.com>
---

Changed V3:
  reword
  remove rk356x part
---
 arch/arm64/boot/dts/rockchip/px30.dtsi   | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3308.dtsi | 5 +++++
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
 5 files changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index d0905515399b..27d045296388 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1394,6 +1394,7 @@ gpio0: gpio at ff040000 {
 			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&pmucru PCLK_GPIO0_PMU>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1406,6 +1407,7 @@ gpio1: gpio at ff250000 {
 			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO1>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1418,6 +1420,7 @@ gpio2: gpio at ff260000 {
 			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO2>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1430,6 +1433,7 @@ gpio3: gpio at ff270000 {
 			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO3>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
index cfc0a87b5195..09fda512c101 100644
--- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
@@ -804,6 +804,7 @@ gpio0: gpio at ff220000 {
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO0>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -815,6 +816,7 @@ gpio1: gpio at ff230000 {
 			interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO1>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -826,6 +828,7 @@ gpio2: gpio at ff240000 {
 			interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO2>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -837,6 +840,7 @@ gpio3: gpio at ff250000 {
 			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO3>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -848,6 +852,7 @@ gpio4: gpio at ff260000 {
 			interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO4>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index fb5dcf6e9327..2cead2e85c07 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -1058,6 +1058,7 @@ gpio0: gpio at ff210000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1071,6 +1072,7 @@ gpio1: gpio at ff220000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1084,6 +1086,7 @@ gpio2: gpio at ff230000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1097,6 +1100,7 @@ gpio3: gpio at ff240000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 62af0cb94839..2a017c862263 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -987,6 +987,7 @@ gpio0: gpio at ff750000 {
 			interrupts = <GIC_SPI 0x51 IRQ_TYPE_LEVEL_HIGH>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -1000,6 +1001,7 @@ gpio1: gpio at ff780000 {
 			interrupts = <GIC_SPI 0x52 IRQ_TYPE_LEVEL_HIGH>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -1013,6 +1015,7 @@ gpio2: gpio at ff790000 {
 			interrupts = <GIC_SPI 0x53 IRQ_TYPE_LEVEL_HIGH>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -1026,6 +1029,7 @@ gpio3: gpio at ff7a0000 {
 			interrupts = <GIC_SPI 0x54 IRQ_TYPE_LEVEL_HIGH>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 6e12c5a920ca..206f7d54d4d0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -2138,6 +2138,7 @@ gpio0: gpio at ff720000 {
 			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -2151,6 +2152,7 @@ gpio1: gpio at ff730000 {
 			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -2164,6 +2166,7 @@ gpio2: gpio at ff780000 {
 			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -2177,6 +2180,7 @@ gpio3: gpio at ff788000 {
 			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -2190,6 +2194,7 @@ gpio4: gpio at ff790000 {
 			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
--
2.39.2



From johan at kernel.org  Wed Dec 27 10:35:53 2023
From: johan at kernel.org (Johan Hovold)
Date: Wed, 27 Dec 2023 19:35:53 +0100
Subject: [PATCH] Bluetooth: hci_bcm4377: do not mark valid bd_addr as
 invalid
In-Reply-To: <f06dbc4d10ff5eb038228e9c7abb75c85514cf36.camel@mrman314.tech>
References: <20231227101003.10534-1-johan+linaro@kernel.org>
 <f06dbc4d10ff5eb038228e9c7abb75c85514cf36.camel@mrman314.tech>
Message-ID: <ZYxuiTYxToF7FpdW@hovoldconsulting.com>

On Wed, Dec 27, 2023 at 01:19:39PM -0500, Felix Zhang wrote:
> On Wed, 2023-12-27 at 11:10 +0100, Johan Hovold wrote:
> > A recent commit restored the original (and still documented)
> > semantics
> > for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device
> > address
> > is considered invalid unless an address is provided by firmware.
> > 
> > This specifically means that this flag must only be set for devices
> > with
> > invalid addresses, but the Broadcom BCM4377 driver has so far been
> > setting this flag unconditionally.
> > 
> > Fortunately the driver already checks for invalid addresses during
> > setup
> > and sets the HCI_QUIRK_INVALID_BDADDR flag, which can simply be
> > replaced
> > with HCI_QUIRK_USE_BDADDR_PROPERTY to indicate that the default
> > address
> > is invalid but can be overridden by firmware (long term, this should
> > probably just always be allowed).
> > 
> > Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk")
> > Cc: stable at vger.kernel.org????? # 6.5
> > Reported-by: Felix Zhang <mrman at mrman314.tech>
> > Link:
> > https://lore.kernel.org/r/77419ffacc5b4875e920e038332575a2a5bff29f.camel at mrman314.tech/
> > Signed-off-by: Johan Hovold <johan+linaro at kernel.org>

> Thanks for the patch!  I have just tested the patch on my MacBookAir9,1
> with some modifications to make it patch with the master branch of the
> Linux kernel, and it works great!  The device is recognized by the
> system; and I can scan, pair, connect, and play audio just fine.  If
> you want me to send over the modified patch that I have used, please
> let me know.

Thanks for confirming. You should not need to modify the patch, though,
as it has been created against 6.7-rc6 and there hasn't been any changes
to this driver since rc1.

Johan


From olteanv at gmail.com  Wed Dec 27 11:11:54 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Wed, 27 Dec 2023 21:11:54 +0200
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal
 MDIO bus
In-Reply-To: <6600c6b1-2230-4963-940c-8b95a01750fd@arinc9.com>
References: <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231221151607.ujobhh4aet4obxdz@skbuf>
 <6600c6b1-2230-4963-940c-8b95a01750fd@arinc9.com>
Message-ID: <20231227191154.6jkqdlqdxciidpfw@skbuf>

On Sun, Dec 24, 2023 at 10:37:12AM +0300, Ar?n? ?NAL wrote:
> If the MDIO bus of the switch is defined on the devicetree, the
> (!ds->user_mii_bus && ds->ops->phy_read) check in dsa_switch_setup will be
> true so the MDIO bus will be attempted to be registered again, resulting in
> a kernel panic.

Where does mt7530 provide ds->ops->phy_read() in upstream?


From arinc.unal at arinc9.com  Wed Dec 27 11:51:08 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Wed, 27 Dec 2023 22:51:08 +0300
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal
 MDIO bus
In-Reply-To: <20231227191154.6jkqdlqdxciidpfw@skbuf>
References: <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231221151607.ujobhh4aet4obxdz@skbuf>
 <6600c6b1-2230-4963-940c-8b95a01750fd@arinc9.com>
 <20231227191154.6jkqdlqdxciidpfw@skbuf>
Message-ID: <bdbe24b2-30f6-48fa-b6eb-a1ae3afe9076@arinc9.com>

On 27.12.2023 22:11, Vladimir Oltean wrote:
> On Sun, Dec 24, 2023 at 10:37:12AM +0300, Ar?n? ?NAL wrote:
>> If the MDIO bus of the switch is defined on the devicetree, the
>> (!ds->user_mii_bus && ds->ops->phy_read) check in dsa_switch_setup will be
>> true so the MDIO bus will be attempted to be registered again, resulting in
>> a kernel panic.
> 
> Where does mt7530 provide ds->ops->phy_read() in upstream?

Sorry, that's a misdiagnosis from my part. There's indeed no
ds->ops->phy_read() or ds->ops->phy_write(). I should know that as I have
intensively studied the MDIO bus registration on all DSA subdrivers. The
issue is at mt7530_setup_mdio_irq():

ds->user_mii_bus->irq[p] = irq;

I didn't realise ds->user_mii_bus is also used to store irq mapping for
each PHY. Should we agree that user_mii_bus is needed for all cases or make
another way to store the irq mappings?

Ar?n?


From olteanv at gmail.com  Wed Dec 27 12:02:17 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Wed, 27 Dec 2023 22:02:17 +0200
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal
 MDIO bus
In-Reply-To: <bdbe24b2-30f6-48fa-b6eb-a1ae3afe9076@arinc9.com>
References: <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231221151607.ujobhh4aet4obxdz@skbuf>
 <6600c6b1-2230-4963-940c-8b95a01750fd@arinc9.com>
 <20231227191154.6jkqdlqdxciidpfw@skbuf>
 <bdbe24b2-30f6-48fa-b6eb-a1ae3afe9076@arinc9.com>
Message-ID: <20231227200217.kdltxpmhvlp6z4cd@skbuf>

On Wed, Dec 27, 2023 at 10:51:08PM +0300, Ar?n? ?NAL wrote:
> I didn't realise ds->user_mii_bus is also used to store irq mapping for
> each PHY.

It needs to, if the MDIO bus does not have an OF description through
which PHYs can have an 'interrupts' property. But if there is an OF
description for the MDIO bus and the PHYs, I think it is strange to
expect PHYs to have interrupts if they aren't described in OF.

> Should we agree that user_mii_bus is needed for all cases or make
> another way to store the irq mappings?

I looked at the upstream device trees:
- users of arch/mips/boot/dts/ralink/mt7621.dtsi
- arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dts
- arch/arm/boot/dts/mediatek/mt7623n-rfb-emmc.dts
- arch/arm/boot/dts/mediatek/mt7623a.dtsi
- arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
- arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
- arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts
- arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts

and without exception, none of these have the MDIO bus described in OF.
I'm not sure about other device trees. But it may well be that the
situation where "MDIO buses present in OF need an IRQ mapping for their
PHYs" does not need to be handled.


From quic_bjorande at quicinc.com  Wed Dec 27 12:21:30 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 27 Dec 2023 12:21:30 -0800
Subject: [PATCH v2 7/8] arm64: dts: qcom: sa8295p-adp: Enable GPU
In-Reply-To: <4a1c18e3-39c8-4070-ae55-b1148b3dc65b@linaro.org>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-7-4763246b72c0@quicinc.com>
 <4a1c18e3-39c8-4070-ae55-b1148b3dc65b@linaro.org>
Message-ID: <20231227202130.GA1315173@hu-bjorande-lv.qualcomm.com>

On Wed, Dec 27, 2023 at 02:09:47AM +0100, Konrad Dybcio wrote:
> On 22.12.2023 05:39, Bjorn Andersson wrote:
> > With the necessary support in place for supplying VDD_GFX from the
> > MAX20411 regulator, enable the GPU clock controller, GMU, Adreno SMMU
> > and the GPU on the SA8295P ADP.
> > 
> > Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> > ---
> [...]
> 
> > +&gpucc {
> > +	vdd-gfx-supply = <&vdd_gfx>;
> > +	status = "okay";
> > +};
> Already enabled
> 

No, we're disabling these in sa8540p.dtsi, so they need to be re-enabled
here.

I don't remember if it's because the attempt to bring up gfx.lvl or if
it's the attempt to operate the GPU components without adequate VDD_GFX,
that is causing the issue...but either way, we don't survive boot.


It's possible that we could move the max20411 up to sa8540p.dtsi to
avoid the intermediate disable, but I'm not confident that it's "part of
the platform"...

Regards,
Bjorn

> > +
> > +&gmu {
> > +	status = "okay";
> > +};
> > +
> > +&gpu {
> > +	status = "okay";
> > +
> > +	zap-shader {
> > +		memory-region = <&gpu_mem>;
> > +		firmware-name = "qcom/sa8295p/a690_zap.mbn";
> > +	};
> > +};
> > +
> > +&gpu_smmu {
> > +	status = "okay";
> > +};
> Already enabled
> 
> 
> Konrad


From quic_bjorande at quicinc.com  Wed Dec 27 12:30:48 2023
From: quic_bjorande at quicinc.com (Bjorn Andersson)
Date: Wed, 27 Dec 2023 12:30:48 -0800
Subject: [PATCH v2 1/8] dt-bindings: clock: qcom: Allow VDD_GFX supply to
 GX
In-Reply-To: <26617c83-31b3-4ad9-8a61-0b8271fad41f@linaro.org>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-1-4763246b72c0@quicinc.com>
 <26617c83-31b3-4ad9-8a61-0b8271fad41f@linaro.org>
Message-ID: <20231227203048.GB1315173@hu-bjorande-lv.qualcomm.com>

On Fri, Dec 22, 2023 at 09:12:04AM +0100, Krzysztof Kozlowski wrote:
> On 22/12/2023 05:39, Bjorn Andersson wrote:
> > In some designs the SoC's VDD_GFX pads are supplied by an external
> > regulator, rather than a power-domain. Allow this to be described in the
> > GPU clock controller binding.
> > 
> > Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
> > ---
> >  Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> > index f369fa34e00c..c0dd24c9dcb3 100644
> > --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> > +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
> > @@ -53,6 +53,9 @@ properties:
> >    power-domains:
> >      maxItems: 1
> >  
> > +  vdd-gfx-supply:
> > +    description: Regulator supply for the VDD_GFX pads
> > +
> >    '#clock-cells':
> >      const: 1
> >  
> > @@ -74,6 +77,19 @@ required:
> >    - '#reset-cells'
> >    - '#power-domain-cells'
> >  
> > +# Allow either power-domains or vdd-gfx-supply, not both
> > +oneOf:
> > +  - required:
> > +      - power-domains
> > +  - required:
> > +      - vdd-gfx-supply
> 
> This should be enough, assuming one of them is actually required. The
> code. See also:
> https://elixir.bootlin.com/linux/v5.17-rc2/source/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml#L91
> 

Yes, that would be the correct binding. But the majority of our
DeviceTree source does not specify a power-domain for their gpucc.

While this should be corrected, it seem reasonable to leave this
optional for now.

Regards,
Bjorn


From honyuenkwun at gmail.com  Wed Dec 27 12:32:11 2023
From: honyuenkwun at gmail.com (Jimmy Hon)
Date: Wed, 27 Dec 2023 14:32:11 -0600
Subject: [PATCH] arm64: dts: rockchip: Support poweroff on Orange Pi 5
Message-ID: <20231227203211.1047-1-honyuenkwun@gmail.com>

The RK806 on the Orange Pi 5 can be used to power on/off the whole board.
Mark it as the system power controller.

Signed-off-by: Jimmy Hon <honyuenkwun at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 8cefdbf3207a..c3a90a769605 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -323,6 +323,8 @@ pmic at 0 {
 				<&rk806_dvs2_null>, <&rk806_dvs3_null>;
 		spi-max-frequency = <1000000>;
 
+		system-power-controller;
+
 		vcc1-supply = <&vcc5v0_sys>;
 		vcc2-supply = <&vcc5v0_sys>;
 		vcc3-supply = <&vcc5v0_sys>;
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 13:02:28 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 22:02:28 +0100
Subject: [PATCH 00/12] mailbox: Convert to platform remove callback returning void
Message-ID: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>

Hello,

this series converts all platform drivers below drivers/mailbox that
make use of .remove() to use .remove_new() instead.

See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for an extended explanation and the eventual goal.
The TL;DR; is to make it harder for driver authors to leak resources
without noticing. The drivers here get it right though and so can be
converted trivially.

This is merge window material. All patches are pairwise independent, so
they can be applied individually.

Best regards
Uwe

Uwe Kleine-K?nig (12):
  mailbox: bcm-flexrm: Convert to platform remove callback returning void
  mailbox: bcm-pdc: Convert to platform remove callback returning void
  mailbox: imx: Convert to platform remove callback returning void
  mailbox: mailbox-test: Convert to platform remove callback returning void
  mailbox: mtk-cmdq: Convert to platform remove callback returning void
  mailbox: omap: Convert to platform remove callback returning void
  mailbox: qcom-apcs-ipc: Convert to platform remove callback returning void
  mailbox: qcom-ipcc: Convert to platform remove callback returning void
  mailbox: stm32-ipcc: Convert to platform remove callback returning void
  mailbox: sun6i-msgbox: Convert to platform remove callback returning void
  mailbox: tegra-hsp: Convert to platform remove callback returning void
  mailbox: zynqmp-ipi: Convert to platform remove callback returning void

 drivers/mailbox/bcm-flexrm-mailbox.c    | 6 ++----
 drivers/mailbox/bcm-pdc-mailbox.c       | 5 ++---
 drivers/mailbox/imx-mailbox.c           | 6 ++----
 drivers/mailbox/mailbox-test.c          | 6 ++----
 drivers/mailbox/mtk-cmdq-mailbox.c      | 5 ++---
 drivers/mailbox/omap-mailbox.c          | 6 ++----
 drivers/mailbox/qcom-apcs-ipc-mailbox.c | 6 ++----
 drivers/mailbox/qcom-ipcc.c             | 6 ++----
 drivers/mailbox/stm32-ipcc.c            | 6 ++----
 drivers/mailbox/sun6i-msgbox.c          | 6 ++----
 drivers/mailbox/tegra-hsp.c             | 6 ++----
 drivers/mailbox/zynqmp-ipi-mailbox.c    | 6 ++----
 12 files changed, 24 insertions(+), 46 deletions(-)

base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 13:02:33 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 22:02:33 +0100
Subject: [PATCH 05/12] mailbox: mtk-cmdq: Convert to platform remove callback returning void
In-Reply-To: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
Message-ID: <f09086fb0576e17c5b06ea5a75e1098fb24030ec.1703710628.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/mailbox/mtk-cmdq-mailbox.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index de862e9137d5..c9009b729ab2 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -367,7 +367,7 @@ static int cmdq_resume(struct device *dev)
 	return 0;
 }
 
-static int cmdq_remove(struct platform_device *pdev)
+static void cmdq_remove(struct platform_device *pdev)
 {
 	struct cmdq *cmdq = platform_get_drvdata(pdev);
 
@@ -378,7 +378,6 @@ static int cmdq_remove(struct platform_device *pdev)
 		cmdq_runtime_suspend(&pdev->dev);
 
 	clk_bulk_unprepare(cmdq->pdata->gce_num, cmdq->clocks);
-	return 0;
 }
 
 static int cmdq_mbox_send_data(struct mbox_chan *chan, void *data)
@@ -761,7 +760,7 @@ static const struct of_device_id cmdq_of_ids[] = {
 
 static struct platform_driver cmdq_drv = {
 	.probe = cmdq_probe,
-	.remove = cmdq_remove,
+	.remove_new = cmdq_remove,
 	.driver = {
 		.name = "mtk_cmdq",
 		.pm = &cmdq_pm_ops,
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 13:02:31 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 22:02:31 +0100
Subject: [PATCH 03/12] mailbox: imx: Convert to platform remove callback returning void
In-Reply-To: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
Message-ID: <cac656a03311ac42a633c874620b6b6d967a2102.1703710628.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/mailbox/imx-mailbox.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 0af739ab571c..656171362fe9 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -903,13 +903,11 @@ static int imx_mu_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int imx_mu_remove(struct platform_device *pdev)
+static void imx_mu_remove(struct platform_device *pdev)
 {
 	struct imx_mu_priv *priv = platform_get_drvdata(pdev);
 
 	pm_runtime_disable(priv->dev);
-
-	return 0;
 }
 
 static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
@@ -1070,7 +1068,7 @@ static const struct dev_pm_ops imx_mu_pm_ops = {
 
 static struct platform_driver imx_mu_driver = {
 	.probe		= imx_mu_probe,
-	.remove		= imx_mu_remove,
+	.remove_new	= imx_mu_remove,
 	.driver = {
 		.name	= "imx_mu",
 		.of_match_table = imx_mu_dt_ids,
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 13:02:37 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 22:02:37 +0100
Subject: [PATCH 09/12] mailbox: stm32-ipcc: Convert to platform remove callback returning void
In-Reply-To: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
Message-ID: <3189b81c29e185e76e87a150051e5e73047b76ea.1703710628.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/mailbox/stm32-ipcc.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mailbox/stm32-ipcc.c b/drivers/mailbox/stm32-ipcc.c
index 4ad3653f3866..1442f275782b 100644
--- a/drivers/mailbox/stm32-ipcc.c
+++ b/drivers/mailbox/stm32-ipcc.c
@@ -331,7 +331,7 @@ static int stm32_ipcc_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int stm32_ipcc_remove(struct platform_device *pdev)
+static void stm32_ipcc_remove(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 
@@ -339,8 +339,6 @@ static int stm32_ipcc_remove(struct platform_device *pdev)
 		dev_pm_clear_wake_irq(&pdev->dev);
 
 	device_set_wakeup_capable(dev, false);
-
-	return 0;
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -381,7 +379,7 @@ static struct platform_driver stm32_ipcc_driver = {
 		.of_match_table = stm32_ipcc_of_match,
 	},
 	.probe		= stm32_ipcc_probe,
-	.remove		= stm32_ipcc_remove,
+	.remove_new	= stm32_ipcc_remove,
 };
 
 module_platform_driver(stm32_ipcc_driver);
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 13:02:40 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 22:02:40 +0100
Subject: [PATCH 12/12] mailbox: zynqmp-ipi: Convert to platform remove callback returning void
In-Reply-To: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
Message-ID: <d3343eec618fde99b47b12f792dc415d66b3d7a1.1703710628.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/mailbox/zynqmp-ipi-mailbox.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c b/drivers/mailbox/zynqmp-ipi-mailbox.c
index 7fa533e80dd9..610a92f9c0b2 100644
--- a/drivers/mailbox/zynqmp-ipi-mailbox.c
+++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
@@ -688,19 +688,17 @@ static int zynqmp_ipi_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int zynqmp_ipi_remove(struct platform_device *pdev)
+static void zynqmp_ipi_remove(struct platform_device *pdev)
 {
 	struct zynqmp_ipi_pdata *pdata;
 
 	pdata = platform_get_drvdata(pdev);
 	zynqmp_ipi_free_mboxes(pdata);
-
-	return 0;
 }
 
 static struct platform_driver zynqmp_ipi_driver = {
 	.probe = zynqmp_ipi_probe,
-	.remove = zynqmp_ipi_remove,
+	.remove_new = zynqmp_ipi_remove,
 	.driver = {
 		   .name = "zynqmp-ipi",
 		   .of_match_table = of_match_ptr(zynqmp_ipi_of_match),
-- 
2.43.0



From u.kleine-koenig at pengutronix.de  Wed Dec 27 13:02:38 2023
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 27 Dec 2023 22:02:38 +0100
Subject: [PATCH 10/12] mailbox: sun6i-msgbox: Convert to platform remove callback returning void
In-Reply-To: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
References: <cover.1703710628.git.u.kleine-koenig@pengutronix.de>
Message-ID: <2db7ef94aa35587980697405ec373e0b7bb70466.1703710628.git.u.kleine-koenig@pengutronix.de>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/mailbox/sun6i-msgbox.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mailbox/sun6i-msgbox.c b/drivers/mailbox/sun6i-msgbox.c
index 7f8d931042d3..3dcc54dc83b2 100644
--- a/drivers/mailbox/sun6i-msgbox.c
+++ b/drivers/mailbox/sun6i-msgbox.c
@@ -287,15 +287,13 @@ static int sun6i_msgbox_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int sun6i_msgbox_remove(struct platform_device *pdev)
+static void sun6i_msgbox_remove(struct platform_device *pdev)
 {
 	struct sun6i_msgbox *mbox = platform_get_drvdata(pdev);
 
 	mbox_controller_unregister(&mbox->controller);
 	/* See the comment in sun6i_msgbox_probe about the reset line. */
 	clk_disable_unprepare(mbox->clk);
-
-	return 0;
 }
 
 static const struct of_device_id sun6i_msgbox_of_match[] = {
@@ -310,7 +308,7 @@ static struct platform_driver sun6i_msgbox_driver = {
 		.of_match_table = sun6i_msgbox_of_match,
 	},
 	.probe  = sun6i_msgbox_probe,
-	.remove = sun6i_msgbox_remove,
+	.remove_new = sun6i_msgbox_remove,
 };
 module_platform_driver(sun6i_msgbox_driver);
 
-- 
2.43.0



From nicolinc at nvidia.com  Wed Dec 27 13:30:56 2023
From: nicolinc at nvidia.com (Nicolin Chen)
Date: Wed, 27 Dec 2023 13:30:56 -0800
Subject: how test the Translation Support for SMMUv3?
In-Reply-To: <61332e87.404e.18caa3d6e15.Coremail.figure1802@126.com>
References: <61332e87.404e.18caa3d6e15.Coremail.figure1802@126.com>
Message-ID: <ZYyXkMWc7xvE3KkM@Asurada-Nvidia>

On Wed, Dec 27, 2023 at 03:46:41PM +0800, Ben wrote:
> Hi Nicolin,
> I saw your pachset on Add Nested Translation Support for SMMUv3
> [LWN.net]<https://lwn.net/Articles/931502/>, i have built the
> kernel and qemu you provided in cover letter.
> I run a QEMU system as Host, and launch a VM by kvmtool. But i
> cannot find a IOMMU on VM, how do you test your patchset?

Make sure you build the kernel with CONFIG_IOMMUFD, and QEMU
likely.

> would you like provide your steps?

# A set of sample commands
echo 0002:01:00.0 | tee /sys/bus/pci/devices/0002\:01\:00.0/driver/unbind; dmesg | tail
echo 8086 0111 | tee /sys/bus/pci/drivers/vfio-pci/new_id

qemu-1214 -object iommufd,id=iommufd0 \
-machine virt,accel=kvm,gic-version=3,iommu=nested-smmuv3,iommufd=iommufd0 \
-cpu host -m 256m -nographic  -kernel /root/Image -bios /root/AAVMF_CODE.fd \
-initrd /root/buildroot-20200422-aarch64-qemu-test-rootfs.cpio \
-object memory-backend-ram,size=256m,id=m0 -numa node,cpus=0,nodeid=0,memdev=m0 \
-device vfio-pci,host=0002:01:00.0,rombar=0,iommufd=iommufd0,id="test0"

> BTW, i add a printk on arm_smmu_device_hw_probe() to print out the smmu->features , it looks your QEMU still only support ARM_SMMU_FEAT_TRANS_S1.

QEMU is used by the guest that should only support S1. The host
kernel on the hand should support both S1 and S2 for nesting.

> Does it provide a vIOMMU of SMMUv3 for your kernel and qemu patchset?

Once you boot with "iommu=nested-smmuv3", there should be one.

Nicolin


From konrad.dybcio at linaro.org  Wed Dec 27 14:15:29 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 27 Dec 2023 23:15:29 +0100
Subject: [PATCH 0/2] Advertise pm_resume/suspend_via_firmware with PSCI
Message-ID: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>

Some device drivers are curious to know if "the firmware" (which to many
just means ACPI, because x86/ibm_pc is clearly the only arch on this
planet :P) is responsible for suspending/resuming the platform, altering
their behavior if that's the case.

The same flag makes sense regardless of the type of firmware used. PSCI
also happens to be the suspend handler on many platforms even without
ACPI, so it's only natural to report such capabilities as well.

Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
Konrad Dybcio (2):
      firmware/psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
      firmware/psci: Set pm_set_resume/suspend_via_firmware() on qcom

 drivers/firmware/psci/psci.c | 67 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 66 insertions(+), 1 deletion(-)
---
base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
change-id: 20231227-topic-psci_fw_sus-a0b0206dc876

Best regards,
-- 
Konrad Dybcio <konrad.dybcio at linaro.org>



From konrad.dybcio at linaro.org  Wed Dec 27 14:15:30 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 27 Dec 2023 23:15:30 +0100
Subject: [PATCH 1/2] firmware/psci: Set
 pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
In-Reply-To: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
References: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
Message-ID: <20231227-topic-psci_fw_sus-v1-1-6910add70bf3@linaro.org>

Some device drivers are curious to know whether "the firmware" (which is
often assumed to be ACPI) takes care of suspending or resuming the
platform. Set the flag that reports this behavior if SYSTEM_SUSPEND is
implemented.

Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
 drivers/firmware/psci/psci.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index d9629ff87861..1bcb752977b1 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -505,12 +505,22 @@ static int psci_system_suspend(unsigned long unused)
 
 static int psci_system_suspend_enter(suspend_state_t state)
 {
+	pm_set_resume_via_firmware();
+
 	return cpu_suspend(0, psci_system_suspend);
 }
 
+static int psci_system_suspend_begin(suspend_state_t state)
+{
+	pm_set_suspend_via_firmware();
+
+	return 0;
+}
+
 static const struct platform_suspend_ops psci_suspend_ops = {
 	.valid          = suspend_valid_only_mem,
 	.enter          = psci_system_suspend_enter,
+	.begin          = psci_system_suspend_begin,
 };
 
 static void __init psci_init_system_reset2(void)

-- 
2.43.0



From konrad.dybcio at linaro.org  Wed Dec 27 14:15:31 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Wed, 27 Dec 2023 23:15:31 +0100
Subject: [PATCH 2/2] firmware/psci: Set
 pm_set_resume/suspend_via_firmware() on qcom
In-Reply-To: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
References: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
Message-ID: <20231227-topic-psci_fw_sus-v1-2-6910add70bf3@linaro.org>

Most Qualcomm platforms implementing PSCI (ab)use CPU_SUSPEND for
entering various stages of suspend, across the SoC. These range from a
simple WFI to a full-fledged power collapse of the entire chip
(mostly, anyway).

Some device drivers are curious to know whether "the firmware" (which is
often assumed to be ACPI) takes care of suspending or resuming the
platform. Set the flag that reports this behavior on the aforementioned
chips.

Some newer Qualcomm chips ship with firmware that actually advertises
PSCI SYSTEM_SUSPEND, so the compatible list should only grow slightly.

Signed-off-by: Konrad Dybcio <konrad.dybcio at linaro.org>
---
 drivers/firmware/psci/psci.c | 57 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 1bcb752977b1..ddfdc14e2423 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -523,6 +523,30 @@ static const struct platform_suspend_ops psci_suspend_ops = {
 	.begin          = psci_system_suspend_begin,
 };
 
+/*
+ * Some PSCI implementations (particularly on Qualcomm platforms) silently
+ * sneak in SoC-wide power collapse through CPU_SUSPEND, while advertising no
+ * support for SYSTEM_SUSPEND.
+ */
+
+static int psci_cpu_as_system_suspend_enter(suspend_state_t state)
+{
+	pm_set_resume_via_firmware();
+
+	return 0;
+}
+
+static int suspend_valid_all(suspend_state_t state)
+{
+	return state == PM_SUSPEND_TO_IDLE;
+}
+
+static const struct platform_suspend_ops psci_cpu_as_system_suspend_ops = {
+	.valid         = suspend_valid_all,
+	.enter         = psci_cpu_as_system_suspend_enter,
+	.begin         = psci_system_suspend_begin,
+};
+
 static void __init psci_init_system_reset2(void)
 {
 	int ret;
@@ -533,8 +557,33 @@ static void __init psci_init_system_reset2(void)
 		psci_system_reset2_supported = true;
 }
 
+
+static const struct of_device_id cpu_as_system_suspend_match_table[] = {
+	{ .compatible = "qcom,msm8998" },
+	{ .compatible = "qcom,qcm2290" },
+	{ .compatible = "qcom,sa8775p" },
+	{ .compatible = "qcom,sc7180" },
+	{ .compatible = "qcom,sc7280" },
+	{ .compatible = "qcom,sc8180x" },
+	{ .compatible = "qcom,sc8280xp" },
+	{ .compatible = "qcom,sdm630" },
+	{ .compatible = "qcom,sdm670" },
+	{ .compatible = "qcom,sdm845" },
+	{ .compatible = "qcom,sm4450" },
+	{ .compatible = "qcom,sm6115" },
+	{ .compatible = "qcom,sm6125" },
+	{ .compatible = "qcom,sm6350" },
+	{ .compatible = "qcom,sm6375" },
+	{ .compatible = "qcom,sm7125" },
+	{ .compatible = "qcom,sm8150" },
+	{ .compatible = "qcom,sm8250" },
+	{ .compatible = "qcom,sm8350" },
+	{ }
+};
+
 static void __init psci_init_system_suspend(void)
 {
+	struct device_node *np = of_find_node_by_path("/");
 	int ret;
 
 	if (!IS_ENABLED(CONFIG_SUSPEND))
@@ -542,8 +591,14 @@ static void __init psci_init_system_suspend(void)
 
 	ret = psci_features(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND));
 
-	if (ret != PSCI_RET_NOT_SUPPORTED)
+	if (ret == PSCI_RET_NOT_SUPPORTED) {
+		if (of_match_node(cpu_as_system_suspend_match_table, np))
+			suspend_set_ops(&psci_cpu_as_system_suspend_ops);
+	} else {
 		suspend_set_ops(&psci_suspend_ops);
+	}
+
+	of_node_put(np);
 }
 
 static void __init psci_init_cpu_suspend(void)

-- 
2.43.0



From sebastian.reichel at collabora.com  Tue Dec 26 16:16:51 2023
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Wed, 27 Dec 2023 01:16:51 +0100
Subject: [PATCH v2 2/2] arm64: dts: rockchip: correct gpio_pwrctrl1 typo
In-Reply-To: <20231225222859.17153-2-inindev@gmail.com>
References: <20231225222859.17153-1-inindev@gmail.com>
 <20231225222859.17153-2-inindev@gmail.com>
Message-ID: <i3gvn6inzgeg257s7l254rfxvdvpdtmybdswjafz3w6gm3wki4@6fvx6pqfbgvp>

Hi,

On Mon, Dec 25, 2023 at 10:28:20PM +0000, John Clark wrote:
> Both rk806_dvs1_null and rk806_dvs2_null duplicate gpio_pwrctrl2 and
> gpio_pwrctrl1 is not set. This patch sets gpio_pwrctrl1.
> 
> Signed-off-by: John Clark <inindev at gmail.com>
> ---
> Changes since v1:
>  - added commit message with additional patch detail
> 
> ---

Reviewed-by: Sebastian Reichel <sebastian.reichel at collabora.com>

-- Sebastian

>  arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> index dc7b88f29172..a0e303c3a1dc 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> @@ -448,7 +448,7 @@ pmic at 0 {
>  		#gpio-cells = <2>;
>  
>  		rk806_dvs1_null: dvs1-null-pins {
> -			pins = "gpio_pwrctrl2";
> +			pins = "gpio_pwrctrl1";
>  			function = "pin_fun0";
>  		};
>  
> -- 
> 2.43.0
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231227/f1f55e9e/attachment.sig>

From sebastian.reichel at collabora.com  Tue Dec 26 16:16:01 2023
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Wed, 27 Dec 2023 01:16:01 +0100
Subject: [PATCH v2 1/2] arm64: dts: rockchip: support poweroff on the
 rock-5b
In-Reply-To: <20231225222859.17153-1-inindev@gmail.com>
References: <20231225222859.17153-1-inindev@gmail.com>
Message-ID: <pqvmguq77qbxmuxsushrz4ykxtmvkugirbxnckmbfk47gx2u5n@cz2kllnjr6ba>

Hi,

On Mon, Dec 25, 2023 at 10:28:19PM +0000, John Clark wrote:
> Allow the rock-5b to poweroff its pmic. When issuing a "shutdown -h now"
> on the rock-5b it reboots instead. Defining 'system-power-controller'
> allows the rk806 to power down.
> 
> Commit c699fbfdfd54 ("arm64: dts: rockchip: Support poweroff on
> NanoPC-T6") similarly resolves this issue for the nanopc-t6.
> 
> Signed-off-by: John Clark <inindev at gmail.com>
> ---

Reviewed-by: Sebastian Reichel <sebastian.reichel at collabora.com>

-- Sebastian

> Changes since v1:
>  - added commit message with additional patch detail
>  - expressed the related commit using checkpatch
> 
> ---
>  arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> index 74719aaf697c..dc7b88f29172 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> @@ -426,6 +426,8 @@ pmic at 0 {
>  		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
>  			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
>  
> +		system-power-controller;
> +
>  		vcc1-supply = <&vcc5v0_sys>;
>  		vcc2-supply = <&vcc5v0_sys>;
>  		vcc3-supply = <&vcc5v0_sys>;
> -- 
> 2.43.0
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231227/ddd33d75/attachment.sig>

From linus.walleij at linaro.org  Wed Dec 27 16:23:56 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 28 Dec 2023 01:23:56 +0100
Subject: [PATCH] pinctrl: samsung: constify iomem pointers
In-Reply-To: <20231223191902.22857-1-krzysztof.kozlowski@linaro.org>
References: <20231223191902.22857-1-krzysztof.kozlowski@linaro.org>
Message-ID: <CACRpkdYLXEA3D-_22jsios5-CdpC5CLxFbTUA-Z=dqTHmtH9XQ@mail.gmail.com>

On Sat, Dec 23, 2023 at 8:19?PM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:

> Constify few pointers to iomem, where the destination memory is not
> modified, for code safety and readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Is this something I should just apply directly at this point?

Yours,
Linus Walleij


From samuel.holland at sifive.com  Wed Dec 27 17:41:50 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:50 -0800
Subject: [PATCH v2 00/14] Unified cross-architecture kernel-mode FPU API
Message-ID: <20231228014220.3562640-1-samuel.holland@sifive.com>

This series unifies the kernel-mode FPU API across several architectures
by wrapping the existing functions (where needed) in consistently-named
functions placed in a consistent header location, with mostly the same
semantics: they can be called from preemptible or non-preemptible task
context, and are not assumed to be reentrant. Architectures are also
expected to provide CFLAGS adjustments for compiling FPU-dependent code.
For the moment, SIMD/vector units are out of scope for this common API.

This allows us to remove the ifdeffery and duplicated Makefile logic at
each FPU user. It then implements the common API on RISC-V, and converts
a couple of users to the new API: the AMDGPU DRM driver, and the FPU
self test.

The underlying goal of this series is to allow using newer AMD GPUs
(e.g. Navi) on RISC-V boards such as SiFive's HiFive Unmatched. Those
GPUs need CONFIG_DRM_AMD_DC_FP to initialize, which requires kernel-mode
FPU support.

Previous versions:
v1: https://lore.kernel.org/linux-kernel/20231208055501.2916202-1-samuel.holland at sifive.com/
v0: https://lore.kernel.org/linux-kernel/20231122030621.3759313-1-samuel.holland at sifive.com/

Changes in v2:
 - Add documentation explaining the built-time and runtime APIs
 - Add a linux/fpu.h header for generic isolation enforcement
 - Remove file name from header comment
 - Clean up arch/arm64/lib/Makefile, like for arch/arm
 - Remove RISC-V architecture-specific preprocessor check
 - Split altivec removal to a separate patch
 - Use linux/fpu.h instead of asm/fpu.h in consumers
 - Declare test_fpu() in a header

Michael Ellerman (1):
  drm/amd/display: Only use hard-float, not altivec on powerpc

Samuel Holland (13):
  arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
  ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  ARM: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
  arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  arm64: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
  lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
  LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  powerpc: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  x86: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
  riscv: Add support for kernel-mode FPU
  drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
  selftests/fpu: Move FP code to a separate translation unit
  selftests/fpu: Allow building on other architectures

 Documentation/core-api/floating-point.rst     | 78 +++++++++++++++++++
 Documentation/core-api/index.rst              |  1 +
 Makefile                                      |  5 ++
 arch/Kconfig                                  |  6 ++
 arch/arm/Kconfig                              |  1 +
 arch/arm/Makefile                             |  7 ++
 arch/arm/include/asm/fpu.h                    | 15 ++++
 arch/arm/lib/Makefile                         |  3 +-
 arch/arm64/Kconfig                            |  1 +
 arch/arm64/Makefile                           |  9 ++-
 arch/arm64/include/asm/fpu.h                  | 15 ++++
 arch/arm64/lib/Makefile                       |  6 +-
 arch/loongarch/Kconfig                        |  1 +
 arch/loongarch/Makefile                       |  5 +-
 arch/loongarch/include/asm/fpu.h              |  1 +
 arch/powerpc/Kconfig                          |  1 +
 arch/powerpc/Makefile                         |  5 +-
 arch/powerpc/include/asm/fpu.h                | 28 +++++++
 arch/riscv/Kconfig                            |  1 +
 arch/riscv/Makefile                           |  3 +
 arch/riscv/include/asm/fpu.h                  | 16 ++++
 arch/riscv/kernel/Makefile                    |  1 +
 arch/riscv/kernel/kernel_mode_fpu.c           | 28 +++++++
 arch/x86/Kconfig                              |  1 +
 arch/x86/Makefile                             | 20 +++++
 arch/x86/include/asm/fpu.h                    | 13 ++++
 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 .../gpu/drm/amd/display/amdgpu_dm/dc_fpu.c    | 35 +--------
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 36 +--------
 drivers/gpu/drm/amd/display/dc/dml2/Makefile  | 36 +--------
 include/linux/fpu.h                           | 12 +++
 lib/Kconfig.debug                             |  2 +-
 lib/Makefile                                  | 26 +------
 lib/raid6/Makefile                            | 31 ++------
 lib/test_fpu.h                                |  8 ++
 lib/{test_fpu.c => test_fpu_glue.c}           | 37 ++-------
 lib/test_fpu_impl.c                           | 37 +++++++++
 37 files changed, 343 insertions(+), 190 deletions(-)
 create mode 100644 Documentation/core-api/floating-point.rst
 create mode 100644 arch/arm/include/asm/fpu.h
 create mode 100644 arch/arm64/include/asm/fpu.h
 create mode 100644 arch/powerpc/include/asm/fpu.h
 create mode 100644 arch/riscv/include/asm/fpu.h
 create mode 100644 arch/riscv/kernel/kernel_mode_fpu.c
 create mode 100644 arch/x86/include/asm/fpu.h
 create mode 100644 include/linux/fpu.h
 create mode 100644 lib/test_fpu.h
 rename lib/{test_fpu.c => test_fpu_glue.c} (71%)
 create mode 100644 lib/test_fpu_impl.c

-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:41:51 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:51 -0800
Subject: [PATCH v2 01/14] arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-2-samuel.holland@sifive.com>

Several architectures provide an API to enable the FPU and run
floating-point SIMD code in kernel space. However, the function names,
header locations, and semantics are inconsistent across architectures,
and FPU support may be gated behind other Kconfig options.

Provide a standard way for architectures to declare that kernel space
FPU support is available. Architectures selecting this option must
implement what is currently the most common API (kernel_fpu_begin() and
kernel_fpu_end(), plus a new function kernel_fpu_available()) and
provide the appropriate CFLAGS for compiling floating-point C code.

Suggested-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

Changes in v2:
 - Add documentation explaining the built-time and runtime APIs
 - Add a linux/fpu.h header for generic isolation enforcement

 Documentation/core-api/floating-point.rst | 78 +++++++++++++++++++++++
 Documentation/core-api/index.rst          |  1 +
 Makefile                                  |  5 ++
 arch/Kconfig                              |  6 ++
 include/linux/fpu.h                       | 12 ++++
 5 files changed, 102 insertions(+)
 create mode 100644 Documentation/core-api/floating-point.rst
 create mode 100644 include/linux/fpu.h

diff --git a/Documentation/core-api/floating-point.rst b/Documentation/core-api/floating-point.rst
new file mode 100644
index 000000000000..a8d0d4b05052
--- /dev/null
+++ b/Documentation/core-api/floating-point.rst
@@ -0,0 +1,78 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Floating-point API
+==================
+
+Kernel code is normally prohibited from using floating-point (FP) registers or
+instructions, including the C float and double data types. This rule reduces
+system call overhead, because the kernel does not need to save and restore the
+userspace floating-point register state.
+
+However, occasionally drivers or library functions may need to include FP code.
+This is supported by isolating the functions containing FP code to a separate
+translation unit (a separate source file), and saving/restoring the FP register
+state around calls to those functions. This creates "critical sections" of
+floating-point usage.
+
+The reason for this isolation is to prevent the compiler from generating code
+touching the FP registers outside these critical sections. Compilers sometimes
+use FP registers to optimize inlined ``memcpy`` or variable assignment, as
+floating-point registers may be wider than general-purpose registers.
+
+Usability of floating-point code within the kernel is architecture-specific.
+Additionally, because a single kernel may be configured to support platforms
+both with and without a floating-point unit, FPU availability must be checked
+both at build time and at run time.
+
+Several architectures implement the generic kernel floating-point API from
+``linux/fpu.h``, as described below. Some other architectures implement their
+own unique APIs, which are documented separately.
+
+Build-time API
+--------------
+
+Floating-point code may be built if the option ``ARCH_HAS_KERNEL_FPU_SUPPORT``
+is enabled. For C code, such code must be placed in a separate file, and that
+file must have its compilation flags adjusted using the following pattern::
+
+    CFLAGS_foo.o += $(CC_FLAGS_FPU)
+    CFLAGS_REMOVE_foo.o += $(CC_FLAGS_NO_FPU)
+
+Architectures are expected to define one or both of these variables in their
+top-level Makefile as needed. For example::
+
+    CC_FLAGS_FPU := -mhard-float
+
+or::
+
+    CC_FLAGS_NO_FPU := -msoft-float
+
+Normal kernel code is assumed to use the equivalent of ``CC_FLAGS_NO_FPU``.
+
+Runtime API
+-----------
+
+The runtime API is provided in ``linux/fpu.h``. This header cannot be included
+from files implementing FP code (those with their compilation flags adjusted as
+above). Instead, it must be included when defining the FP critical sections.
+
+.. c:function:: bool kernel_fpu_available( void )
+
+        This function reports if floating-point code can be used on this CPU or
+        platform. The value returned by this function is not expected to change
+        at runtime, so it only needs to be called once, not before every
+        critical section.
+
+.. c:function:: void kernel_fpu_begin( void )
+                void kernel_fpu_end( void )
+
+        These functions create a floating-point critical section. It is only
+        valid to call ``kernel_fpu_begin()`` after a previous call to
+        ``kernel_fpu_available()`` returned ``true``. These functions are only
+        guaranteed to be callable from (preemptible or non-preemptible) process
+        context.
+
+        Preemption may be disabled inside critical sections, so their size
+        should be minimized. They are *not* required to be reentrant. If the
+        caller expects to nest critical sections, it must implement its own
+        reference counting.
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index 7a3a08d81f11..974beccd671f 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -48,6 +48,7 @@ Library functionality that is used throughout the kernel.
    errseq
    wrappers/atomic_t
    wrappers/atomic_bitops
+   floating-point
 
 Low level entry and exit
 ========================
diff --git a/Makefile b/Makefile
index ee995fc2b0e5..79c9e0b56ab8 100644
--- a/Makefile
+++ b/Makefile
@@ -969,6 +969,11 @@ KBUILD_CFLAGS	+= $(CC_FLAGS_CFI)
 export CC_FLAGS_CFI
 endif
 
+# Architectures can define flags to add/remove for floating-point support
+CC_FLAGS_FPU	+= -D_LINUX_FPU_COMPILATION_UNIT
+export CC_FLAGS_FPU
+export CC_FLAGS_NO_FPU
+
 ifneq ($(CONFIG_FUNCTION_ALIGNMENT),0)
 KBUILD_CFLAGS += -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT)
 endif
diff --git a/arch/Kconfig b/arch/Kconfig
index f4b210ab0612..e1c01ce819ed 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1478,6 +1478,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG
 	  address translations. Page table walkers that clear the accessed bit
 	  may use this capability to reduce their search space.
 
+config ARCH_HAS_KERNEL_FPU_SUPPORT
+	bool
+	help
+	  Architectures that select this option can run floating-point code in
+	  the kernel, as described in Documentation/core-api/floating-point.rst.
+
 source "kernel/gcov/Kconfig"
 
 source "scripts/gcc-plugins/Kconfig"
diff --git a/include/linux/fpu.h b/include/linux/fpu.h
new file mode 100644
index 000000000000..2fb63e22913b
--- /dev/null
+++ b/include/linux/fpu.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_FPU_H
+#define _LINUX_FPU_H
+
+#ifdef _LINUX_FPU_COMPILATION_UNIT
+#error FP code must be compiled separately. See Documentation/core-api/floating-point.rst.
+#endif
+
+#include <asm/fpu.h>
+
+#endif
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:41:52 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:52 -0800
Subject: [PATCH v2 02/14] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-3-samuel.holland@sifive.com>

ARM provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.

Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

Changes in v2:
 - Remove file name from header comment

 arch/arm/Kconfig           |  1 +
 arch/arm/Makefile          |  7 +++++++
 arch/arm/include/asm/fpu.h | 15 +++++++++++++++
 3 files changed, 23 insertions(+)
 create mode 100644 arch/arm/include/asm/fpu.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f8567e95f98b..92e21a4a2903 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_KEEPINITRD
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT if KERNEL_MODE_NEON
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
 	select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5ba42f69f8ce..1dd860dba5f5 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -130,6 +130,13 @@ endif
 # Accept old syntax despite ".syntax unified"
 AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
 
+# The GCC option -ffreestanding is required in order to compile code containing
+# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
+CC_FLAGS_FPU	:= -ffreestanding
+# Enable <arm_neon.h>
+CC_FLAGS_FPU	+= -isystem $(shell $(CC) -print-file-name=include)
+CC_FLAGS_FPU	+= -march=armv7-a -mfloat-abi=softfp -mfpu=neon
+
 ifeq ($(CONFIG_THUMB2_KERNEL),y)
 CFLAGS_ISA	:=-Wa,-mimplicit-it=always $(AFLAGS_NOWARN)
 AFLAGS_ISA	:=$(CFLAGS_ISA) -Wa$(comma)-mthumb
diff --git a/arch/arm/include/asm/fpu.h b/arch/arm/include/asm/fpu.h
new file mode 100644
index 000000000000..2ae50bdce59b
--- /dev/null
+++ b/arch/arm/include/asm/fpu.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef __ASM_FPU_H
+#define __ASM_FPU_H
+
+#include <asm/neon.h>
+
+#define kernel_fpu_available()	cpu_has_neon()
+#define kernel_fpu_begin()	kernel_neon_begin()
+#define kernel_fpu_end()	kernel_neon_end()
+
+#endif /* ! __ASM_FPU_H */
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:41:54 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:54 -0800
Subject: [PATCH v2 04/14] arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-5-samuel.holland@sifive.com>

arm64 provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.

Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

Changes in v2:
 - Remove file name from header comment

 arch/arm64/Kconfig           |  1 +
 arch/arm64/Makefile          |  9 ++++++++-
 arch/arm64/include/asm/fpu.h | 15 +++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/include/asm/fpu.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..485ac389ac11 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -30,6 +30,7 @@ config ARM64
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_GIGANTIC_PAGE
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT if KERNEL_MODE_NEON
 	select ARCH_HAS_KEEPINITRD
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 9a2d3723cd0f..4a65f24c7998 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -36,7 +36,14 @@ ifeq ($(CONFIG_BROKEN_GAS_INST),y)
 $(warning Detected assembler with broken .inst; disassembly will be unreliable)
 endif
 
-KBUILD_CFLAGS	+= -mgeneral-regs-only	\
+# The GCC option -ffreestanding is required in order to compile code containing
+# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
+CC_FLAGS_FPU	:= -ffreestanding
+# Enable <arm_neon.h>
+CC_FLAGS_FPU	+= -isystem $(shell $(CC) -print-file-name=include)
+CC_FLAGS_NO_FPU	:= -mgeneral-regs-only
+
+KBUILD_CFLAGS	+= $(CC_FLAGS_NO_FPU) \
 		   $(compat_vdso) $(cc_has_k_constraint)
 KBUILD_CFLAGS	+= $(call cc-disable-warning, psabi)
 KBUILD_AFLAGS	+= $(compat_vdso)
diff --git a/arch/arm64/include/asm/fpu.h b/arch/arm64/include/asm/fpu.h
new file mode 100644
index 000000000000..2ae50bdce59b
--- /dev/null
+++ b/arch/arm64/include/asm/fpu.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef __ASM_FPU_H
+#define __ASM_FPU_H
+
+#include <asm/neon.h>
+
+#define kernel_fpu_available()	cpu_has_neon()
+#define kernel_fpu_begin()	kernel_neon_begin()
+#define kernel_fpu_end()	kernel_neon_end()
+
+#endif /* ! __ASM_FPU_H */
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:41:53 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:53 -0800
Subject: [PATCH v2 03/14] ARM: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-4-samuel.holland@sifive.com>

Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.

Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

(no changes since v1)

 arch/arm/lib/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 650404be6768..0ca5aae1bcc3 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -40,8 +40,7 @@ $(obj)/csumpartialcopy.o:	$(obj)/csumpartialcopygeneric.S
 $(obj)/csumpartialcopyuser.o:	$(obj)/csumpartialcopygeneric.S
 
 ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
-  NEON_FLAGS			:= -march=armv7-a -mfloat-abi=softfp -mfpu=neon
-  CFLAGS_xor-neon.o		+= $(NEON_FLAGS)
+  CFLAGS_xor-neon.o		+= $(CC_FLAGS_FPU)
   obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
 endif
 
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:41:55 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:55 -0800
Subject: [PATCH v2 05/14] arm64: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-6-samuel.holland@sifive.com>

Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

Changes in v2:
 - New patch for v2

 arch/arm64/lib/Makefile | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 29490be2546b..13e6a2829116 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -7,10 +7,8 @@ lib-y		:= clear_user.o delay.o copy_from_user.o		\
 
 ifeq ($(CONFIG_KERNEL_MODE_NEON), y)
 obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
-CFLAGS_REMOVE_xor-neon.o	+= -mgeneral-regs-only
-CFLAGS_xor-neon.o		+= -ffreestanding
-# Enable <arm_neon.h>
-CFLAGS_xor-neon.o		+= -isystem $(shell $(CC) -print-file-name=include)
+CFLAGS_xor-neon.o		+= $(CC_FLAGS_FPU)
+CFLAGS_REMOVE_xor-neon.o	+= $(CC_FLAGS_NO_FPU)
 endif
 
 lib-$(CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE) += uaccess_flushcache.o
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:41:56 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:56 -0800
Subject: [PATCH v2 06/14] lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-7-samuel.holland@sifive.com>

Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.

Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

(no changes since v1)

 lib/raid6/Makefile | 31 ++++++++-----------------------
 1 file changed, 8 insertions(+), 23 deletions(-)

diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 1c5420ff254e..309fea97efc6 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -33,25 +33,6 @@ CFLAGS_REMOVE_vpermxor8.o += -msoft-float
 endif
 endif
 
-# The GCC option -ffreestanding is required in order to compile code containing
-# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
-ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
-NEON_FLAGS := -ffreestanding
-# Enable <arm_neon.h>
-NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include)
-ifeq ($(ARCH),arm)
-NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
-endif
-CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
-ifeq ($(ARCH),arm64)
-CFLAGS_REMOVE_recov_neon_inner.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon2.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon4.o += -mgeneral-regs-only
-CFLAGS_REMOVE_neon8.o += -mgeneral-regs-only
-endif
-endif
-
 quiet_cmd_unroll = UNROLL  $@
       cmd_unroll = $(AWK) -v N=$* -f $(srctree)/$(src)/unroll.awk < $< > $@
 
@@ -75,10 +56,14 @@ targets += vpermxor1.c vpermxor2.c vpermxor4.c vpermxor8.c
 $(obj)/vpermxor%.c: $(src)/vpermxor.uc $(src)/unroll.awk FORCE
 	$(call if_changed,unroll)
 
-CFLAGS_neon1.o += $(NEON_FLAGS)
-CFLAGS_neon2.o += $(NEON_FLAGS)
-CFLAGS_neon4.o += $(NEON_FLAGS)
-CFLAGS_neon8.o += $(NEON_FLAGS)
+CFLAGS_neon1.o += $(CC_FLAGS_FPU)
+CFLAGS_neon2.o += $(CC_FLAGS_FPU)
+CFLAGS_neon4.o += $(CC_FLAGS_FPU)
+CFLAGS_neon8.o += $(CC_FLAGS_FPU)
+CFLAGS_REMOVE_neon1.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
 targets += neon1.c neon2.c neon4.c neon8.c
 $(obj)/neon%.c: $(src)/neon.uc $(src)/unroll.awk FORCE
 	$(call if_changed,unroll)
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:41:57 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:57 -0800
Subject: [PATCH v2 07/14] LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-8-samuel.holland@sifive.com>

LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
asm/fpu.h, so it only needs to add kernel_fpu_available() and export
the CFLAGS adjustments.

Acked-by: WANG Xuerui <git at xen0n.name>
Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

(no changes since v1)

 arch/loongarch/Kconfig           | 1 +
 arch/loongarch/Makefile          | 5 ++++-
 arch/loongarch/include/asm/fpu.h | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index ee123820a476..65d4475565b8 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -15,6 +15,7 @@ config LOONGARCH
 	select ARCH_HAS_CPU_FINALIZE_INIT
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT if CPU_HAS_FPU
 	select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
 	select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
 	select ARCH_HAS_PTE_SPECIAL
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
index 4ba8d67ddb09..1afe28feaba5 100644
--- a/arch/loongarch/Makefile
+++ b/arch/loongarch/Makefile
@@ -25,6 +25,9 @@ endif
 32bit-emul		= elf32loongarch
 64bit-emul		= elf64loongarch
 
+CC_FLAGS_FPU		:= -mfpu=64
+CC_FLAGS_NO_FPU		:= -msoft-float
+
 ifdef CONFIG_DYNAMIC_FTRACE
 KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
 CC_FLAGS_FTRACE := -fpatchable-function-entry=2
@@ -46,7 +49,7 @@ ld-emul			= $(64bit-emul)
 cflags-y		+= -mabi=lp64s
 endif
 
-cflags-y			+= -pipe -msoft-float
+cflags-y			+= -pipe $(CC_FLAGS_NO_FPU)
 LDFLAGS_vmlinux			+= -static -n -nostdlib
 
 # When the assembler supports explicit relocation hint, we must use it.
diff --git a/arch/loongarch/include/asm/fpu.h b/arch/loongarch/include/asm/fpu.h
index c2d8962fda00..3177674228f8 100644
--- a/arch/loongarch/include/asm/fpu.h
+++ b/arch/loongarch/include/asm/fpu.h
@@ -21,6 +21,7 @@
 
 struct sigcontext;
 
+#define kernel_fpu_available() cpu_has_fpu
 extern void kernel_fpu_begin(void);
 extern void kernel_fpu_end(void);
 
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:41:59 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:59 -0800
Subject: [PATCH v2 09/14] x86: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-10-samuel.holland@sifive.com>

x86 already provides kernel_fpu_begin() and kernel_fpu_end(), but in a
different header. Add a wrapper header, and export the CFLAGS
adjustments as found in lib/Makefile.

Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

(no changes since v1)

 arch/x86/Kconfig           |  1 +
 arch/x86/Makefile          | 20 ++++++++++++++++++++
 arch/x86/include/asm/fpu.h | 13 +++++++++++++
 3 files changed, 34 insertions(+)
 create mode 100644 arch/x86/include/asm/fpu.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3762f41bb092..1fe7f2d8d017 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -81,6 +81,7 @@ config X86
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_KCOV			if X86_64
+	select ARCH_HAS_KERNEL_FPU_SUPPORT
 	select ARCH_HAS_MEM_ENCRYPT
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 1a068de12a56..71576c8dbe79 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -70,6 +70,26 @@ export BITS
 KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
 KBUILD_RUSTFLAGS += -Ctarget-feature=-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2
 
+#
+# CFLAGS for compiling floating point code inside the kernel.
+#
+CC_FLAGS_FPU := -msse -msse2
+ifdef CONFIG_CC_IS_GCC
+# Stack alignment mismatch, proceed with caution.
+# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3
+# (8B stack alignment).
+# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
+#
+# The "-msse" in the first argument is there so that the
+# -mpreferred-stack-boundary=3 build error:
+#
+#  -mpreferred-stack-boundary=3 is not between 4 and 12
+#
+# can be triggered. Otherwise gcc doesn't complain.
+CC_FLAGS_FPU += -mhard-float
+CC_FLAGS_FPU += $(call cc-option,-msse -mpreferred-stack-boundary=3,-mpreferred-stack-boundary=4)
+endif
+
 ifeq ($(CONFIG_X86_KERNEL_IBT),y)
 #
 # Kernel IBT has S_CET.NOTRACK_EN=0, as such the compilers must not generate
diff --git a/arch/x86/include/asm/fpu.h b/arch/x86/include/asm/fpu.h
new file mode 100644
index 000000000000..b2743fe19339
--- /dev/null
+++ b/arch/x86/include/asm/fpu.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef _ASM_X86_FPU_H
+#define _ASM_X86_FPU_H
+
+#include <asm/fpu/api.h>
+
+#define kernel_fpu_available()	true
+
+#endif /* ! _ASM_X86_FPU_H */
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:42:02 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:42:02 -0800
Subject: [PATCH v2 12/14] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-13-samuel.holland@sifive.com>

Now that all previously-supported architectures select
ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
of the existing list of architectures. It can also take advantage of the
common kernel-mode FPU API and method of adjusting CFLAGS.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

Changes in v2:
 - Split altivec removal to a separate patch
 - Use linux/fpu.h instead of asm/fpu.h in consumers

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 .../gpu/drm/amd/display/amdgpu_dm/dc_fpu.c    | 27 ++------------
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 36 ++-----------------
 drivers/gpu/drm/amd/display/dc/dml2/Makefile  | 36 ++-----------------
 4 files changed, 7 insertions(+), 94 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig
index 901d1961b739..5fcd4f778dc3 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -8,7 +8,7 @@ config DRM_AMD_DC
 	depends on BROKEN || !CC_IS_CLANG || ARM64 || RISCV || SPARC64 || X86_64
 	select SND_HDA_COMPONENT if SND_HDA_CORE
 	# !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
-	select DRM_AMD_DC_FP if (X86 || LOONGARCH || (PPC64 && ALTIVEC) || (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
+	select DRM_AMD_DC_FP if ARCH_HAS_KERNEL_FPU_SUPPORT && (!ARM64 || !CC_IS_CLANG)
 	help
 	  Choose this option if you want to use the new display engine
 	  support for AMDGPU. This adds required support for Vega and
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
index 0de16796466b..e46f8ce41d87 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
@@ -26,16 +26,7 @@
 
 #include "dc_trace.h"
 
-#if defined(CONFIG_X86)
-#include <asm/fpu/api.h>
-#elif defined(CONFIG_PPC64)
-#include <asm/switch_to.h>
-#include <asm/cputable.h>
-#elif defined(CONFIG_ARM64)
-#include <asm/neon.h>
-#elif defined(CONFIG_LOONGARCH)
-#include <asm/fpu.h>
-#endif
+#include <linux/fpu.h>
 
 /**
  * DOC: DC FPU manipulation overview
@@ -87,16 +78,9 @@ void dc_fpu_begin(const char *function_name, const int line)
 	WARN_ON_ONCE(!in_task());
 	preempt_disable();
 	depth = __this_cpu_inc_return(fpu_recursion_depth);
-
 	if (depth == 1) {
-#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
+		BUG_ON(!kernel_fpu_available());
 		kernel_fpu_begin();
-#elif defined(CONFIG_PPC64)
-		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
-			enable_kernel_fp();
-#elif defined(CONFIG_ARM64)
-		kernel_neon_begin();
-#endif
 	}
 
 	TRACE_DCN_FPU(true, function_name, line, depth);
@@ -118,14 +102,7 @@ void dc_fpu_end(const char *function_name, const int line)
 
 	depth = __this_cpu_dec_return(fpu_recursion_depth);
 	if (depth == 0) {
-#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 		kernel_fpu_end();
-#elif defined(CONFIG_PPC64)
-		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
-			disable_kernel_fp();
-#elif defined(CONFIG_ARM64)
-		kernel_neon_end();
-#endif
 	} else {
 		WARN_ON_ONCE(depth < 0);
 	}
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 554c39024a40..be15d366b786 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -25,40 +25,8 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-ifdef CONFIG_X86
-dml_ccflags-$(CONFIG_CC_IS_GCC) := -mhard-float
-dml_ccflags := $(dml_ccflags-y) -msse
-endif
-
-ifdef CONFIG_PPC64
-dml_ccflags := -mhard-float
-endif
-
-ifdef CONFIG_ARM64
-dml_rcflags := -mgeneral-regs-only
-endif
-
-ifdef CONFIG_LOONGARCH
-dml_ccflags := -mfpu=64
-dml_rcflags := -msoft-float
-endif
-
-ifdef CONFIG_CC_IS_GCC
-ifneq ($(call gcc-min-version, 70100),y)
-IS_OLD_GCC = 1
-endif
-endif
-
-ifdef CONFIG_X86
-ifdef IS_OLD_GCC
-# Stack alignment mismatch, proceed with caution.
-# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3
-# (8B stack alignment).
-dml_ccflags += -mpreferred-stack-boundary=4
-else
-dml_ccflags += -msse2
-endif
-endif
+dml_ccflags := $(CC_FLAGS_FPU)
+dml_rcflags := $(CC_FLAGS_NO_FPU)
 
 ifneq ($(CONFIG_FRAME_WARN),0)
 ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index 7b51364084b5..4f6c804a26ad 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -24,40 +24,8 @@
 #
 # Makefile for dml2.
 
-ifdef CONFIG_X86
-dml2_ccflags-$(CONFIG_CC_IS_GCC) := -mhard-float
-dml2_ccflags := $(dml2_ccflags-y) -msse
-endif
-
-ifdef CONFIG_PPC64
-dml2_ccflags := -mhard-float
-endif
-
-ifdef CONFIG_ARM64
-dml2_rcflags := -mgeneral-regs-only
-endif
-
-ifdef CONFIG_LOONGARCH
-dml2_ccflags := -mfpu=64
-dml2_rcflags := -msoft-float
-endif
-
-ifdef CONFIG_CC_IS_GCC
-ifeq ($(call cc-ifversion, -lt, 0701, y), y)
-IS_OLD_GCC = 1
-endif
-endif
-
-ifdef CONFIG_X86
-ifdef IS_OLD_GCC
-# Stack alignment mismatch, proceed with caution.
-# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3
-# (8B stack alignment).
-dml2_ccflags += -mpreferred-stack-boundary=4
-else
-dml2_ccflags += -msse2
-endif
-endif
+dml2_ccflags := $(CC_FLAGS_FPU)
+dml2_rcflags := $(CC_FLAGS_NO_FPU)
 
 ifneq ($(CONFIG_FRAME_WARN),0)
 ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:42:03 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:42:03 -0800
Subject: [PATCH v2 13/14] selftests/fpu: Move FP code to a separate translation unit
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-14-samuel.holland@sifive.com>

This ensures no compiler-generated floating-point code can appear
outside kernel_fpu_{begin,end}() sections, and some architectures
enforce this separation.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

Changes in v2:
 - Declare test_fpu() in a header

 lib/Makefile                        |  3 ++-
 lib/test_fpu.h                      |  8 +++++++
 lib/{test_fpu.c => test_fpu_glue.c} | 32 +------------------------
 lib/test_fpu_impl.c                 | 37 +++++++++++++++++++++++++++++
 4 files changed, 48 insertions(+), 32 deletions(-)
 create mode 100644 lib/test_fpu.h
 rename lib/{test_fpu.c => test_fpu_glue.c} (71%)
 create mode 100644 lib/test_fpu_impl.c

diff --git a/lib/Makefile b/lib/Makefile
index 6b09731d8e61..e7cbd54944a2 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -132,7 +132,8 @@ FPU_CFLAGS += $(call cc-option,-msse -mpreferred-stack-boundary=3,-mpreferred-st
 endif
 
 obj-$(CONFIG_TEST_FPU) += test_fpu.o
-CFLAGS_test_fpu.o += $(FPU_CFLAGS)
+test_fpu-y := test_fpu_glue.o test_fpu_impl.o
+CFLAGS_test_fpu_impl.o += $(FPU_CFLAGS)
 
 obj-$(CONFIG_TEST_LIVEPATCH) += livepatch/
 
diff --git a/lib/test_fpu.h b/lib/test_fpu.h
new file mode 100644
index 000000000000..4459807084bc
--- /dev/null
+++ b/lib/test_fpu.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef _LIB_TEST_FPU_H
+#define _LIB_TEST_FPU_H
+
+int test_fpu(void);
+
+#endif
diff --git a/lib/test_fpu.c b/lib/test_fpu_glue.c
similarity index 71%
rename from lib/test_fpu.c
rename to lib/test_fpu_glue.c
index e82db19fed84..85963d7be826 100644
--- a/lib/test_fpu.c
+++ b/lib/test_fpu_glue.c
@@ -19,37 +19,7 @@
 #include <linux/debugfs.h>
 #include <asm/fpu/api.h>
 
-static int test_fpu(void)
-{
-	/*
-	 * This sequence of operations tests that rounding mode is
-	 * to nearest and that denormal numbers are supported.
-	 * Volatile variables are used to avoid compiler optimizing
-	 * the calculations away.
-	 */
-	volatile double a, b, c, d, e, f, g;
-
-	a = 4.0;
-	b = 1e-15;
-	c = 1e-310;
-
-	/* Sets precision flag */
-	d = a + b;
-
-	/* Result depends on rounding mode */
-	e = a + b / 2;
-
-	/* Denormal and very large values */
-	f = b / c;
-
-	/* Depends on denormal support */
-	g = a + c * f;
-
-	if (d > a && e > a && g > a)
-		return 0;
-	else
-		return -EINVAL;
-}
+#include "test_fpu.h"
 
 static int test_fpu_get(void *data, u64 *val)
 {
diff --git a/lib/test_fpu_impl.c b/lib/test_fpu_impl.c
new file mode 100644
index 000000000000..777894dbbe86
--- /dev/null
+++ b/lib/test_fpu_impl.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/errno.h>
+
+#include "test_fpu.h"
+
+int test_fpu(void)
+{
+	/*
+	 * This sequence of operations tests that rounding mode is
+	 * to nearest and that denormal numbers are supported.
+	 * Volatile variables are used to avoid compiler optimizing
+	 * the calculations away.
+	 */
+	volatile double a, b, c, d, e, f, g;
+
+	a = 4.0;
+	b = 1e-15;
+	c = 1e-310;
+
+	/* Sets precision flag */
+	d = a + b;
+
+	/* Result depends on rounding mode */
+	e = a + b / 2;
+
+	/* Denormal and very large values */
+	f = b / c;
+
+	/* Depends on denormal support */
+	g = a + c * f;
+
+	if (d > a && e > a && g > a)
+		return 0;
+	else
+		return -EINVAL;
+}
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:42:04 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:42:04 -0800
Subject: [PATCH v2 14/14] selftests/fpu: Allow building on other architectures
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-15-samuel.holland@sifive.com>

Now that ARCH_HAS_KERNEL_FPU_SUPPORT provides a common way to compile
and run floating-point code, this test is no longer x86-specific.

Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

(no changes since v1)

 lib/Kconfig.debug   |  2 +-
 lib/Makefile        | 25 ++-----------------------
 lib/test_fpu_glue.c |  5 ++++-
 3 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 4405f81248fb..4596100eeb14 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2918,7 +2918,7 @@ config TEST_FREE_PAGES
 
 config TEST_FPU
 	tristate "Test floating point operations in kernel space"
-	depends on X86 && !KCOV_INSTRUMENT_ALL
+	depends on ARCH_HAS_KERNEL_FPU_SUPPORT && !KCOV_INSTRUMENT_ALL
 	help
 	  Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu
 	  which will trigger a sequence of floating point operations. This is used
diff --git a/lib/Makefile b/lib/Makefile
index e7cbd54944a2..b9f28558c9bd 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -109,31 +109,10 @@ CFLAGS_test_fprobe.o += $(CC_FLAGS_FTRACE)
 obj-$(CONFIG_FPROBE_SANITY_TEST) += test_fprobe.o
 obj-$(CONFIG_TEST_OBJPOOL) += test_objpool.o
 
-#
-# CFLAGS for compiling floating point code inside the kernel. x86/Makefile turns
-# off the generation of FPU/SSE* instructions for kernel proper but FPU_FLAGS
-# get appended last to CFLAGS and thus override those previous compiler options.
-#
-FPU_CFLAGS := -msse -msse2
-ifdef CONFIG_CC_IS_GCC
-# Stack alignment mismatch, proceed with caution.
-# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3
-# (8B stack alignment).
-# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
-#
-# The "-msse" in the first argument is there so that the
-# -mpreferred-stack-boundary=3 build error:
-#
-#  -mpreferred-stack-boundary=3 is not between 4 and 12
-#
-# can be triggered. Otherwise gcc doesn't complain.
-FPU_CFLAGS += -mhard-float
-FPU_CFLAGS += $(call cc-option,-msse -mpreferred-stack-boundary=3,-mpreferred-stack-boundary=4)
-endif
-
 obj-$(CONFIG_TEST_FPU) += test_fpu.o
 test_fpu-y := test_fpu_glue.o test_fpu_impl.o
-CFLAGS_test_fpu_impl.o += $(FPU_CFLAGS)
+CFLAGS_test_fpu_impl.o += $(CC_FLAGS_FPU)
+CFLAGS_REMOVE_test_fpu_impl.o += $(CC_FLAGS_NO_FPU)
 
 obj-$(CONFIG_TEST_LIVEPATCH) += livepatch/
 
diff --git a/lib/test_fpu_glue.c b/lib/test_fpu_glue.c
index 85963d7be826..eef282a2715f 100644
--- a/lib/test_fpu_glue.c
+++ b/lib/test_fpu_glue.c
@@ -17,7 +17,7 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/debugfs.h>
-#include <asm/fpu/api.h>
+#include <linux/fpu.h>
 
 #include "test_fpu.h"
 
@@ -38,6 +38,9 @@ static struct dentry *selftest_dir;
 
 static int __init test_fpu_init(void)
 {
+	if (!kernel_fpu_available())
+		return -EINVAL;
+
 	selftest_dir = debugfs_create_dir("selftest_helpers", NULL);
 	if (!selftest_dir)
 		return -ENOMEM;
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:42:00 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:42:00 -0800
Subject: [PATCH v2 10/14] riscv: Add support for kernel-mode FPU
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-11-samuel.holland@sifive.com>

This is motivated by the amdgpu DRM driver, which needs floating-point
code to support recent hardware. That code is not performance-critical,
so only provide a minimal non-preemptible implementation for now.

Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

Changes in v2:
 - Remove RISC-V architecture-specific preprocessor check

 arch/riscv/Kconfig                  |  1 +
 arch/riscv/Makefile                 |  3 +++
 arch/riscv/include/asm/fpu.h        | 16 ++++++++++++++++
 arch/riscv/kernel/Makefile          |  1 +
 arch/riscv/kernel/kernel_mode_fpu.c | 28 ++++++++++++++++++++++++++++
 5 files changed, 49 insertions(+)
 create mode 100644 arch/riscv/include/asm/fpu.h
 create mode 100644 arch/riscv/kernel/kernel_mode_fpu.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 24c1799e2ec4..4d4d1d64ce34 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -27,6 +27,7 @@ config RISCV
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_GIGANTIC_PAGE
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT if FPU
 	select ARCH_HAS_MMIOWB
 	select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
 	select ARCH_HAS_PMEM_API
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index a74be78678eb..2e719c369210 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -81,6 +81,9 @@ KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64i
 
 KBUILD_AFLAGS += -march=$(riscv-march-y)
 
+# For C code built with floating-point support, exclude V but keep F and D.
+CC_FLAGS_FPU  := -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)([^v_]*)v?/\1\2/')
+
 KBUILD_CFLAGS += -mno-save-restore
 KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET)
 
diff --git a/arch/riscv/include/asm/fpu.h b/arch/riscv/include/asm/fpu.h
new file mode 100644
index 000000000000..91c04c244e12
--- /dev/null
+++ b/arch/riscv/include/asm/fpu.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef _ASM_RISCV_FPU_H
+#define _ASM_RISCV_FPU_H
+
+#include <asm/switch_to.h>
+
+#define kernel_fpu_available()	has_fpu()
+
+void kernel_fpu_begin(void);
+void kernel_fpu_end(void);
+
+#endif /* ! _ASM_RISCV_FPU_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index fee22a3d1b53..662c483e338d 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_MMU) += vdso.o vdso/
 
 obj-$(CONFIG_RISCV_MISALIGNED)	+= traps_misaligned.o
 obj-$(CONFIG_FPU)		+= fpu.o
+obj-$(CONFIG_FPU)		+= kernel_mode_fpu.o
 obj-$(CONFIG_RISCV_ISA_V)	+= vector.o
 obj-$(CONFIG_SMP)		+= smpboot.o
 obj-$(CONFIG_SMP)		+= smp.o
diff --git a/arch/riscv/kernel/kernel_mode_fpu.c b/arch/riscv/kernel/kernel_mode_fpu.c
new file mode 100644
index 000000000000..0ac8348876c4
--- /dev/null
+++ b/arch/riscv/kernel/kernel_mode_fpu.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#include <linux/export.h>
+#include <linux/preempt.h>
+
+#include <asm/csr.h>
+#include <asm/fpu.h>
+#include <asm/processor.h>
+#include <asm/switch_to.h>
+
+void kernel_fpu_begin(void)
+{
+	preempt_disable();
+	fstate_save(current, task_pt_regs(current));
+	csr_set(CSR_SSTATUS, SR_FS);
+}
+EXPORT_SYMBOL_GPL(kernel_fpu_begin);
+
+void kernel_fpu_end(void)
+{
+	csr_clear(CSR_SSTATUS, SR_FS);
+	fstate_restore(current, task_pt_regs(current));
+	preempt_enable();
+}
+EXPORT_SYMBOL_GPL(kernel_fpu_end);
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:41:58 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:41:58 -0800
Subject: [PATCH v2 08/14] powerpc: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-9-samuel.holland@sifive.com>

PowerPC provides an equivalent to the common kernel-mode FPU API, but in
a different header and using different function names. The PowerPC API
also requires a non-preemptible context. Add a wrapper header, and
export the CFLAGS adjustments.

Reviewed-by: Christoph Hellwig <hch at lst.de>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

(no changes since v1)

 arch/powerpc/Kconfig           |  1 +
 arch/powerpc/Makefile          |  5 ++++-
 arch/powerpc/include/asm/fpu.h | 28 ++++++++++++++++++++++++++++
 3 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/include/asm/fpu.h

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6f105ee4f3cf..e96cb5b7c571 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -137,6 +137,7 @@ config PPC
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_HUGEPD			if HUGETLB_PAGE
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_KERNEL_FPU_SUPPORT	if PPC_FPU
 	select ARCH_HAS_MEMBARRIER_CALLBACKS
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_MEMREMAP_COMPAT_ALIGN	if PPC_64S_HASH_MMU
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f19dbaa1d541..91106970a8c1 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -142,6 +142,9 @@ CFLAGS-$(CONFIG_PPC32)	+= $(call cc-option, $(MULTIPLEWORD))
 
 CFLAGS-$(CONFIG_PPC32)	+= $(call cc-option,-mno-readonly-in-sdata)
 
+CC_FLAGS_FPU		:= $(call cc-option,-mhard-float)
+CC_FLAGS_NO_FPU		:= $(call cc-option,-msoft-float)
+
 ifdef CONFIG_FUNCTION_TRACER
 ifdef CONFIG_ARCH_USING_PATCHABLE_FUNCTION_ENTRY
 KBUILD_CPPFLAGS	+= -DCC_USING_PATCHABLE_FUNCTION_ENTRY
@@ -163,7 +166,7 @@ asinstr := $(call as-instr,lis 9$(comma)foo at high,-DHAVE_AS_ATHIGH=1)
 
 KBUILD_CPPFLAGS	+= -I $(srctree)/arch/$(ARCH) $(asinstr)
 KBUILD_AFLAGS	+= $(AFLAGS-y)
-KBUILD_CFLAGS	+= $(call cc-option,-msoft-float)
+KBUILD_CFLAGS	+= $(CC_FLAGS_NO_FPU)
 KBUILD_CFLAGS	+= $(CFLAGS-y)
 CPP		= $(CC) -E $(KBUILD_CFLAGS)
 
diff --git a/arch/powerpc/include/asm/fpu.h b/arch/powerpc/include/asm/fpu.h
new file mode 100644
index 000000000000..ca584e4bc40f
--- /dev/null
+++ b/arch/powerpc/include/asm/fpu.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2023 SiFive
+ */
+
+#ifndef _ASM_POWERPC_FPU_H
+#define _ASM_POWERPC_FPU_H
+
+#include <linux/preempt.h>
+
+#include <asm/cpu_has_feature.h>
+#include <asm/switch_to.h>
+
+#define kernel_fpu_available()	(!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
+
+static inline void kernel_fpu_begin(void)
+{
+	preempt_disable();
+	enable_kernel_fp();
+}
+
+static inline void kernel_fpu_end(void)
+{
+	disable_kernel_fp();
+	preempt_enable();
+}
+
+#endif /* ! _ASM_POWERPC_FPU_H */
-- 
2.42.0



From samuel.holland at sifive.com  Wed Dec 27 17:42:01 2023
From: samuel.holland at sifive.com (Samuel Holland)
Date: Wed, 27 Dec 2023 17:42:01 -0800
Subject: [PATCH v2 11/14] drm/amd/display: Only use hard-float, not altivec on powerpc
In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
Message-ID: <20231228014220.3562640-12-samuel.holland@sifive.com>

From: Michael Ellerman <mpe at ellerman.id.au>

The compiler flags enable altivec, but that is not required; hard-float
is sufficient for the code to build and function.

Drop altivec from the compiler flags and adjust the enable/disable code
to only enable FPU use.

Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
---

Changes in v2:
 - New patch for v2

 drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c | 12 ++----------
 drivers/gpu/drm/amd/display/dc/dml/Makefile    |  2 +-
 drivers/gpu/drm/amd/display/dc/dml2/Makefile   |  2 +-
 3 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
index 4ae4720535a5..0de16796466b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
@@ -92,11 +92,7 @@ void dc_fpu_begin(const char *function_name, const int line)
 #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 		kernel_fpu_begin();
 #elif defined(CONFIG_PPC64)
-		if (cpu_has_feature(CPU_FTR_VSX_COMP))
-			enable_kernel_vsx();
-		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
-			enable_kernel_altivec();
-		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
+		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
 			enable_kernel_fp();
 #elif defined(CONFIG_ARM64)
 		kernel_neon_begin();
@@ -125,11 +121,7 @@ void dc_fpu_end(const char *function_name, const int line)
 #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 		kernel_fpu_end();
 #elif defined(CONFIG_PPC64)
-		if (cpu_has_feature(CPU_FTR_VSX_COMP))
-			disable_kernel_vsx();
-		else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP))
-			disable_kernel_altivec();
-		else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
+		if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE))
 			disable_kernel_fp();
 #elif defined(CONFIG_ARM64)
 		kernel_neon_end();
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 6042a5a6a44f..554c39024a40 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -31,7 +31,7 @@ dml_ccflags := $(dml_ccflags-y) -msse
 endif
 
 ifdef CONFIG_PPC64
-dml_ccflags := -mhard-float -maltivec
+dml_ccflags := -mhard-float
 endif
 
 ifdef CONFIG_ARM64
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index acff3449b8d7..7b51364084b5 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -30,7 +30,7 @@ dml2_ccflags := $(dml2_ccflags-y) -msse
 endif
 
 ifdef CONFIG_PPC64
-dml2_ccflags := -mhard-float -maltivec
+dml2_ccflags := -mhard-float
 endif
 
 ifdef CONFIG_ARM64
-- 
2.42.0



From wenst at chromium.org  Wed Dec 27 17:45:44 2023
From: wenst at chromium.org (Chen-Yu Tsai)
Date: Thu, 28 Dec 2023 10:45:44 +0900
Subject: [PATCH 1/2] clk: mediatek: Introduce need_pm_runtime to mtk_clk_desc
In-Reply-To: <20231227090448.2216295-1-treapking@chromium.org>
References: <20231227090448.2216295-1-treapking@chromium.org>
Message-ID: <CAGXv+5E-vn4pCCJr-Qs4tcbMAyGBWk4YQEzm=fkHjE0U9nBpiA@mail.gmail.com>

On Wed, Dec 27, 2023 at 6:05?PM Pin-yen Lin <treapking at chromium.org> wrote:
>
> Introduce a new need_pm_runtime variable to mtk_clk_desc to indicate this
> clock needs a runtime PM get during the probing stage.

Actually it means (based on our discussions and your code here) that
runtime PM should be enabled for the clock controller. If runtime PM
is not enabled before the clocks are registered, the CCF subsequently
never toggles runtime PM.

The runtime PM get during the probe stage is to avoid triggering runtime
suspend/resume during each clock registration, and hopefully avoid a
deadlock. It should be mentioned separately. A comment should be added
so that folks going over the code in the future don't remove it.

> Signed-off-by: Pin-yen Lin <treapking at chromium.org>
> ---
>
>  drivers/clk/mediatek/clk-mtk.c | 15 +++++++++++++++
>  drivers/clk/mediatek/clk-mtk.h |  2 ++
>  2 files changed, 17 insertions(+)
>
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index 2e55368dc4d8..c31e535909c8 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -13,6 +13,7 @@
>  #include <linux/of.h>
>  #include <linux/of_address.h>
>  #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
>  #include <linux/slab.h>
>
>  #include "clk-mtk.h"
> @@ -494,6 +495,14 @@ static int __mtk_clk_simple_probe(struct platform_device *pdev,
>                         return IS_ERR(base) ? PTR_ERR(base) : -ENOMEM;
>         }
>
> +
> +       if (mcd->need_runtime_pm) {
> +               devm_pm_runtime_enable(&pdev->dev);
> +               r = pm_runtime_resume_and_get(&pdev->dev);

A comment for the resume and get should be added. Otherwise someone looking
at this and the CCF could think that this isn't needed, since the CCF already
has similar calls.

> +               if (r)
> +                       return r;
> +       }
> +
>         /* Calculate how many clk_hw_onecell_data entries to allocate */
>         num_clks = mcd->num_clks + mcd->num_composite_clks;
>         num_clks += mcd->num_fixed_clks + mcd->num_factor_clks;
> @@ -574,6 +583,9 @@ static int __mtk_clk_simple_probe(struct platform_device *pdev,
>                         goto unregister_clks;
>         }
>
> +       if (mcd->need_runtime_pm)
> +               pm_runtime_put(&pdev->dev);
> +
>         return r;
>
>  unregister_clks:
> @@ -604,6 +616,9 @@ static int __mtk_clk_simple_probe(struct platform_device *pdev,
>  free_base:
>         if (mcd->shared_io && base)
>                 iounmap(base);
> +
> +       if (mcd->need_runtime_pm)
> +               pm_runtime_put(&pdev->dev);

Please keep the error path calls strictly in reverse order of the setup
calls. So this should go before iounmap().

ChenYu

>         return r;
>  }

> diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index 22096501a60a..c17fe1c2d732 100644
> --- a/drivers/clk/mediatek/clk-mtk.h
> +++ b/drivers/clk/mediatek/clk-mtk.h
> @@ -237,6 +237,8 @@ struct mtk_clk_desc {
>
>         int (*clk_notifier_func)(struct device *dev, struct clk *clk);
>         unsigned int mfg_clk_idx;
> +
> +       bool need_runtime_pm;
>  };
>
>  int mtk_clk_pdev_probe(struct platform_device *pdev);
> --
> 2.43.0.472.g3155946c3a-goog
>


From ck.hu at mediatek.com  Wed Dec 27 17:38:15 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Thu, 28 Dec 2023 01:38:15 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <83db5f669a6404ba3bf65ecd7b024af2509c19dc.camel@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
	 <f338215fb8f7ff1e0ebeb0f1e21a8b4dec5f0c61.camel@mediatek.com>
	 <83db5f669a6404ba3bf65ecd7b024af2509c19dc.camel@mediatek.com>
Message-ID: <f3a8c0cbdcf5da0381eaee5e0595319cd1970dde.camel@mediatek.com>

On Wed, 2023-12-27 at 07:25 +0000, Jason-JH Lin (???) wrote:
> Hi CK,
> 
> Thanks for the reviews.
> 
> On Tue, 2023-12-26 at 08:58 +0000, CK Hu (???) wrote:
> > Hi, Jason:
> > 
> > On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> > > To support secure video path feature, GCE have to read/write
> > > registgers
> > > in the secure world. GCE will enable the secure access permission
> > > to
> > > the
> > > HW who wants to access the secure content buffer.
> > > 
> > > Add CMDQ secure mailbox driver to make CMDQ client user is able
> > > to
> > > sending their HW settings to the secure world. So that GCE can
> > > execute
> > > all instructions to configure HW in the secure world.
> > > 
> > > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > > ---
> > 
> > [snip]
> > 
> > > +
> > > +static int cmdq_sec_fill_iwc_msg(struct cmdq_sec_context
> > > *context,
> > > +				 struct cmdq_sec_task *sec_task, u32
> > > thrd_idx)
> > > +{
> > > +	struct iwc_cmdq_message_t *iwc_msg = NULL;
> > > +	struct cmdq_sec_data *data = (struct cmdq_sec_data *)sec_task-
> > > > task.pkt->sec_data;
> > > 
> > > +	u32 size = 0, offset = 0, *instr;
> > > +
> > > +	iwc_msg = (struct iwc_cmdq_message_t *)context->iwc_msg;
> > > +
> > > +	if (sec_task->task.pkt->cmd_buf_size + 4 * CMDQ_INST_SIZE >
> > > CMDQ_TZ_CMD_BLOCK_SIZE) {
> > > +		pr_err("sec_task:%p size:%zu > %u",
> > > +		       sec_task, sec_task->task.pkt->cmd_buf_size,
> > > CMDQ_TZ_CMD_BLOCK_SIZE);
> > > +		return -EFAULT;
> > > +	}
> > > +
> > > +	if (thrd_idx == CMDQ_INVALID_THREAD) {
> > > +		iwc_msg->command.cmd_size = 0;
> > > +		iwc_msg->command.metadata.addr_list_length = 0;
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	iwc_msg->command.thread = thrd_idx;
> > > +	iwc_msg->command.scenario = sec_task->scenario;
> > > +	iwc_msg->command.eng_flag = sec_task->engine_flag;
> > > +	size = sec_task->task.pkt->cmd_buf_size;
> > > +	memcpy(iwc_msg->command.va_base + offset, sec_task->task.pkt-
> > > > va_base, size);
> > 
> > I think it's not necessary to copy from normal command buffer to
> > normal
> > command buffer. Just
> > 
> > iwc_msg->command.va_base = sec_task->task.pkt->va_base;
> > 
> > You have a secure command buffer for secure gce to execute command.
> > If
> > you want to modify command buffer, copy from normal command buffer
> > to
> > secure command buffer, and modify the secure command buffer.
> > 
> > Regards,
> > CK
> > 
> > 
> 
> I think secure world won't recognize normal world's va, so we nee to
> copy to iwc_msg->command.va_base, which is a world share memory
> first.

Referring to cmdq_sec_allocate_wsm(), any kernel buffer could use
tee_shm_register_kernel_buf() to become share buffer between normal
world and secure world. In client driver, use tee_client_open_context()
to create tee context and register normal command buffer to be share
buffer. This would reduce the redundant memory copy.

Regards,
CK

> 
> Regards,
> Jason-JH.Lin

From ck.hu at mediatek.com  Wed Dec 27 18:02:03 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Thu, 28 Dec 2023 02:02:03 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <db1591bdf52f3cd02335155c45cb7841da9fcbc1.camel@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
	 <957c5ec4fe3a1ad6eb44df37bd68cfedfcb0b926.camel@mediatek.com>
	 <db1591bdf52f3cd02335155c45cb7841da9fcbc1.camel@mediatek.com>
Message-ID: <ae7dba29db2591ca3d09020e1cebbbbbc24b1f18.camel@mediatek.com>

On Wed, 2023-12-27 at 06:13 +0000, Jason-JH Lin (???) wrote:
> Hi CK,
> 
> Thanks for the reviews.
> 
> On Tue, 2023-12-26 at 06:46 +0000, CK Hu (???) wrote:
> > Hi, Jason:
> > 
> > On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> > > To support secure video path feature, GCE have to read/write
> > > registgers
> > > in the secure world. GCE will enable the secure access permission
> > > to
> > > the
> > > HW who wants to access the secure content buffer.
> > > 
> > > Add CMDQ secure mailbox driver to make CMDQ client user is able
> > > to
> > > sending their HW settings to the secure world. So that GCE can
> > > execute
> > > all instructions to configure HW in the secure world.
> > > 
> > > Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> > > ---
> > 
> > [snip]
> > 
> > > +
> > > +static int cmdq_sec_session_init(struct cmdq_sec_context
> > > *context)
> > > +{
> > > +	int err = 0;
> > > +
> > > +	if (context->state >= IWC_SES_OPENED) {
> > > +		pr_debug("session opened:%u", context->state);
> > > +		return 0;
> > > +	}
> > > +
> > > +	switch (context->state) {
> > > +	case IWC_INIT:
> > > +		err = cmdq_sec_init_context(&context->tee_ctx);
> > > +		if (err)
> > > +			return err;
> > > +		context->state = IWC_CONTEXT_INITED;
> > > +	fallthrough;
> > > +	case IWC_CONTEXT_INITED:
> > > +		if (context->iwc_msg) {
> > > +			pr_err("iwcMessage not NULL:%p", context-
> > > > iwc_msg);
> > > 
> > > +			return -EINVAL;
> > > +		}
> > > +
> > > +		err = cmdq_sec_allocate_wsm(&context->tee_ctx,
> > > &context->iwc_msg,
> > > +					    sizeof(struct
> > > iwc_cmdq_message_t));
> > > +		if (err)
> > > +			return err;
> > > +
> > > +		context->state = IWC_WSM_ALLOCATED;
> > > +	fallthrough;
> > 
> > Squash cmdq_sec_session_init() into cmdq_sec_mbox_of_xlate() and
> > drop
> > the context->state.
> > 
> > Regards,
> > CK
> > 
> 
> cmdq_sec_session_init() is called in the first
> cmdq_sec_task_submit().
> It means we don't need to connect a session to TEE or allocate share
> memory if no one submit secure task.
> 
> On the other hand, optee may load slower than cmdq secure driver. If
> we
> move it to xlate secure session may init fail.

For driver probe dependency, you could refer to [1]. I would like
resource allocation and free to be symmetric. So maybe allocate/free in
probe/remove or starup/shutdown. If the secure driver is probed, I
think it would finally allocate secure resource. So later allocation
has no much benefit and make code more complicated. 

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/mediatek?h=next-20231222&id=c8048dd0b07df68724805254b9e994d99e9a7af4

Regards,
CK


> 
> Regards,
> Jason-JH.Lin

From mpe at ellerman.id.au  Wed Dec 27 19:19:08 2023
From: mpe at ellerman.id.au (Michael Ellerman)
Date: Thu, 28 Dec 2023 14:19:08 +1100
Subject: [PATCH v2 08/14] powerpc: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-9-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com>
 <20231228014220.3562640-9-samuel.holland@sifive.com>
Message-ID: <87wmszj9oz.fsf@mail.lhotse>

Samuel Holland <samuel.holland at sifive.com> writes:
> PowerPC provides an equivalent to the common kernel-mode FPU API, but in
> a different header and using different function names. The PowerPC API
> also requires a non-preemptible context. Add a wrapper header, and
> export the CFLAGS adjustments.
>
> Reviewed-by: Christoph Hellwig <hch at lst.de>
> Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
> ---
>
> (no changes since v1)
>
>  arch/powerpc/Kconfig           |  1 +
>  arch/powerpc/Makefile          |  5 ++++-
>  arch/powerpc/include/asm/fpu.h | 28 ++++++++++++++++++++++++++++
>  3 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 arch/powerpc/include/asm/fpu.h

Acked-by: Michael Ellerman <mpe at ellerman.id.au> (powerpc)

cheers


From inindev at gmail.com  Wed Dec 27 19:21:13 2023
From: inindev at gmail.com (John Clark)
Date: Thu, 28 Dec 2023 03:21:13 +0000
Subject: [PATCH] arm64: dts: rockchip: nanopc-t6 sdmmc device tuning
Message-ID: <20231228032114.1157-1-inindev@gmail.com>

1) sdmmc on the nanopc-t6 is powered by vcc3v3_sd_s0, not vcc_3v3_s3
   add the supply vcc3v3_sd_s0, and control it with gpio4_a5
2) add the card detection property gpio0_a4
3) drop max-frequency = <200000000> as it is already defined in rk3588s.dtsi
4) order no-sdio & no-mmc properties while we are here

Signed-off-by: John Clark <inindev at gmail.com>
---
 .../boot/dts/rockchip/rk3588-nanopc-t6.dts    | 27 ++++++++++++++++---
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
index e83b71510a47..2360735e58a1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
@@ -159,6 +159,19 @@ vcc3v3_pcie30: vcc3v3-pcie30-regulator {
 		regulator-max-microvolt = <3300000>;
 		vin-supply = <&vcc5v0_sys>;
 	};
+
+	vcc3v3_sd_s0: vcc3v3-sd-s0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sd_s0_pwren>;
+		regulator-boot-on;
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		regulator-name = "vcc3v3_sd_s0";
+		vin-supply = <&vcc_3v3_s3>;
+	};
 };
 
 &combphy0_ps {
@@ -503,6 +516,12 @@ pcie_m2_1_pwren: pcie-m21-pwren {
 		};
 	};
 
+	sdmmc {
+		sd_s0_pwren: sd-s0-pwren {
+			rockchip,pins = <4 RK_PA5 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
 	usb {
 		typec5v_pwren: typec5v-pwren {
 			rockchip,pins = <1 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
@@ -536,15 +555,15 @@ &sdhci {
 };
 
 &sdmmc {
-	max-frequency = <200000000>;
-	no-sdio;
-	no-mmc;
 	bus-width = <4>;
 	cap-mmc-highspeed;
 	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
 	disable-wp;
+	no-mmc;
+	no-sdio;
 	sd-uhs-sdr104;
-	vmmc-supply = <&vcc_3v3_s3>;
+	vmmc-supply = <&vcc3v3_sd_s0>;
 	vqmmc-supply = <&vccio_sd_s0>;
 	status = "okay";
 };
-- 
2.43.0



From ck.hu at mediatek.com  Wed Dec 27 21:31:37 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Thu, 28 Dec 2023 05:31:37 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <0124eca6dfcd45af4c454ab1937590ca89a2a787.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +
> +static struct mbox_chan *cmdq_sec_mbox_of_xlate(struct
> mbox_controller *mbox,
> +						const struct
> of_phandle_args *sp)
> +{
> +	struct cmdq_thread *thread;
> +	struct cmdq_sec_thread *sec_thread;
> +	int idx = sp->args[0];
> +
> +	if (mbox->num_chans <= idx) {
> +		pr_err("invalid thrd-idx:%u", idx);
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	thread = (struct cmdq_thread *)mbox->chans[idx].con_priv;
> +	thread->chan = &mbox->chans[idx];
> +	thread->priority = sp->args[1];
> +	sec_thread = container_of(thread, struct cmdq_sec_thread,
> thread);
> +	sec_thread->timeout_ms = CMDQ_NO_TIMEOUT;

The timeout_ms could only be CMDQ_NO_TIMEOUT, so this driver just has
no timeout. So drop timeout_ms.

Regards,
CK

> +
> +	return &mbox->chans[idx];
> +}
> 

From hch at lst.de  Wed Dec 27 22:19:04 2023
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 28 Dec 2023 07:19:04 +0100
Subject: [PATCH v2 01/14] arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-2-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com> <20231228014220.3562640-2-samuel.holland@sifive.com>
Message-ID: <20231228061904.GA12475@lst.de>

Thanks for all the great documentation!

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>



From hch at lst.de  Wed Dec 27 22:19:30 2023
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 28 Dec 2023 07:19:30 +0100
Subject: [PATCH v2 05/14] arm64: crypto: Use CC_FLAGS_FPU for NEON
 CFLAGS
In-Reply-To: <20231228014220.3562640-6-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com> <20231228014220.3562640-6-samuel.holland@sifive.com>
Message-ID: <20231228061930.GB12475@lst.de>

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>



From hch at lst.de  Wed Dec 27 22:20:04 2023
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 28 Dec 2023 07:20:04 +0100
Subject: [PATCH v2 10/14] riscv: Add support for kernel-mode FPU
In-Reply-To: <20231228014220.3562640-11-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com> <20231228014220.3562640-11-samuel.holland@sifive.com>
Message-ID: <20231228062004.GC12475@lst.de>

On Wed, Dec 27, 2023 at 05:42:00PM -0800, Samuel Holland wrote:
> This is motivated by the amdgpu DRM driver, which needs floating-point
> code to support recent hardware. That code is not performance-critical,
> so only provide a minimal non-preemptible implementation for now.
> 
> Signed-off-by: Samuel Holland <samuel.holland at sifive.com>

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at lst.de  Wed Dec 27 22:20:40 2023
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 28 Dec 2023 07:20:40 +0100
Subject: [PATCH v2 12/14] drm/amd/display: Use
 ARCH_HAS_KERNEL_FPU_SUPPORT
In-Reply-To: <20231228014220.3562640-13-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com> <20231228014220.3562640-13-samuel.holland@sifive.com>
Message-ID: <20231228062040.GD12475@lst.de>

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>


From hch at lst.de  Wed Dec 27 22:20:57 2023
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 28 Dec 2023 07:20:57 +0100
Subject: [PATCH v2 13/14] selftests/fpu: Move FP code to a separate
 translation unit
In-Reply-To: <20231228014220.3562640-14-samuel.holland@sifive.com>
References: <20231228014220.3562640-1-samuel.holland@sifive.com> <20231228014220.3562640-14-samuel.holland@sifive.com>
Message-ID: <20231228062057.GE12475@lst.de>

Looks good:

Reviewed-by: Christoph Hellwig <hch at lst.de>



From ck.hu at mediatek.com  Wed Dec 27 22:27:06 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Thu, 28 Dec 2023 06:27:06 +0000
Subject: [PATCH v3 00/11] Add mediate-drm secure flow for SVP
In-Reply-To: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
References: <20231223182932.27683-1-jason-jh.lin@mediatek.com>
Message-ID: <4fd704b3438e524362fada762b380bd18949cd0a.camel@mediatek.com>

Hi, Jason:

On Sun, 2023-12-24 at 02:29 +0800, Jason-JH.Lin wrote:
> From: Jason-jh Lin <jason-jh.lin at mediatek.corp-partner.google.com>
> 
> Memory Definitions:
> secure memory - Memory allocated in the TEE (Trusted Execution
> Environment) which is inaccessible in the REE (Rich Execution
> Environment, i.e. linux kernel/userspace).
> secure handle - Integer value which acts as reference to 'secure
> memory'. Used in communication between TEE and REE to reference
> 'secure memory'.
> secure buffer - 'secure memory' that is used to store decrypted,
> compressed video or for other general purposes in the TEE.
> secure surface - 'secure memory' that is used to store graphic
> buffers.
> 
> Memory Usage in SVP:
> The overall flow of SVP starts with encrypted video coming in from an
> outside source into the REE. The REE will then allocate a 'secure
> buffer' and send the corresponding 'secure handle' along with the
> encrypted, compressed video data to the TEE. The TEE will then
> decrypt
> the video and store the result in the 'secure buffer'. The REE will
> then allocate a 'secure surface'. The REE will pass the 'secure
> handles' for both the 'secure buffer' and 'secure surface' into the
> TEE for video decoding. The video decoder HW will then decode the
> contents of the 'secure buffer' and place the result in the 'secure
> surface'. The REE will then attach the 'secure surface' to the
> overlay
> plane for rendering of the video.
> 
> Everything relating to ensuring security of the actual contents of
> the
> 'secure buffer' and 'secure surface' is out of scope for the REE and
> is the responsibility of the TEE.
> 
> DRM driver handles allocation of gem objects that are backed by a
> 'secure
> surface' and for displaying a 'secure surface' on the overlay plane.
> This introduces a new flag for object creation called
> DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure
> surface'. All changes here are in MediaTek specific code.

I would like to decouple secure display and secure decode. One reason
is that I would like secure display could be tested itself without
secure decode. Another reason is that if someone has draw an image and
want to display securely, this is not related to decode.

To achieve this, mediatek drm driver should provide render function on
secure surface. The most simple function is to bitblt a normal surface
onto secure surface. User could allocate both normal surface and secure
surface, draw on normal surface and bitblt normal surface onto secure
surface. We could have limitation that normal surface and secure
surface have the same width, height, pitch, pixel format, and the
bitblt is the full image bitblt. So mediatek drm driver just need a TEE
function that do memory copy from normal surface to secure surface.

This is not a must-be function, but it has some benefit for secure
display.

Regards,
CK

> ---
> TODO:
> 1) Remove get sec larb port interface in ddp_comp, ovl and
> ovl_adaptor.
> 2) Verify instruction for enabling/disabling dapc and larb port in
> TEE
>    drop the sec_engine flags in normal world and.
> 3) Move DISP_REG_OVL_SECURE setting to secure world for
> mtk_disp_ovl.c.
> 4) Change the parameter register address in mtk_ddp_sec_write()
>    from "u32 addr" to "struct cmdq_client_reg *cmdq_reg".
> 5) Implement setting mmsys routing table in the secure world series.
> ---
> Based on 5 series and 1 patch:
> [1] v3 dma-buf: heaps: Add MediaTek secure heap
> - 
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=809023__;!!CTRNKA9wMg0ARbw!lYGWfjjIBlxJvwBXWyxHTyc2vew5YagqT_qJZrYONTH20h95qxC3PH9V91vjplYU3S0ayseyHpxRQFSqATHgDnU$
>  
> [2] v3 add driver to support secure video decoder
> - 
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=807308__;!!CTRNKA9wMg0ARbw!lYGWfjjIBlxJvwBXWyxHTyc2vew5YagqT_qJZrYONTH20h95qxC3PH9V91vjplYU3S0ayseyHpxRQFSq9TXMSIQ$
>  
> [3] v4 soc: mediatek: Add register definitions for GCE
> - 
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20231212121957.19231-2-shawn.sung at mediatek.com/__;!!CTRNKA9wMg0ARbw!lYGWfjjIBlxJvwBXWyxHTyc2vew5YagqT_qJZrYONTH20h95qxC3PH9V91vjplYU3S0ayseyHpxRQFSqkO4_0ac$
>  
> [4] v2 Add CMDQ driver support for mt8188
> - 
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=810302__;!!CTRNKA9wMg0ARbw!lYGWfjjIBlxJvwBXWyxHTyc2vew5YagqT_qJZrYONTH20h95qxC3PH9V91vjplYU3S0ayseyHpxRQFSqcXdKnXU$
>  
> [5] Add mediatek,gce-events definition to mediatek,gce-mailbox
> bindings
> - 
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=810938__;!!CTRNKA9wMg0ARbw!lYGWfjjIBlxJvwBXWyxHTyc2vew5YagqT_qJZrYONTH20h95qxC3PH9V91vjplYU3S0ayseyHpxRQFSqqGM08aE$
>  
> [6] v3 Add CMDQ secure driver for SVP
> - 
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=812379__;!!CTRNKA9wMg0ARbw!lYGWfjjIBlxJvwBXWyxHTyc2vew5YagqT_qJZrYONTH20h95qxC3PH9V91vjplYU3S0ayseyHpxRQFSq_YXTH9A$
>  
> ---
> Change in v3:
> 1. fix kerneldoc problems
> 2. fix typo in title and commit message
> 3. adjust naming for secure variable
> 4. add the missing part for is_suecure plane implementation
> 5. use BIT_ULL macro to replace bit shifting
> 6. move modification of ovl_adaptor part to the correct patch
> 7. add TODO list in commit message
> 8. add commit message for using share memory to store execute count
> 
> Change in v2:
> 
> 1. remove the DRIVER_RDNDER flag for mtk_drm_ioctl
> 2. move cmdq_insert_backup_cookie into client driver
> 3. move secure gce node define from mt8195-cherry.dtsi to mt8195.dtsi
> ---
> CK Hu (1):
>   drm/mediatek: Add interface to allocate MediaTek GEM buffer.
> 
> Jason-JH.Lin (10):
>   drm/mediatek/uapi: Add DRM_MTK_GEM_CREATE_ENCRYPTED flag
>   drm/mediatek: Add secure buffer control flow to mtk_drm_gem
>   drm/mediatek: Add secure identify flag and funcution to
> mtk_drm_plane
>   drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info
>   drm/mediatek: Add get_sec_port interface to mtk_ddp_comp
>   drm/mediatek: Add secure layer config support for ovl
>   drm/mediatek: Add secure layer config support for ovl_adaptor
>   drm/mediatek: Add secure flow support to mediatek-drm
>   drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt
> finalize
>   arm64: dts: mt8195: Add secure mbox settings for vdosys
> 
>  arch/arm64/boot/dts/mediatek/mt8195.dtsi      |   6 +-
>  drivers/gpu/drm/mediatek/mtk_disp_drv.h       |   3 +
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c       |  31 +-
>  .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   |  15 +
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c       | 274
> +++++++++++++++++-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.h       |   1 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |  30 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   |  14 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c        |  13 +
>  drivers/gpu/drm/mediatek/mtk_drm_gem.c        | 122 ++++++++
>  drivers/gpu/drm/mediatek/mtk_drm_gem.h        |  16 +
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c      |  26 ++
>  drivers/gpu/drm/mediatek/mtk_drm_plane.h      |   2 +
>  drivers/gpu/drm/mediatek/mtk_mdp_rdma.c       |  11 +-
>  drivers/gpu/drm/mediatek/mtk_mdp_rdma.h       |   2 +
>  include/uapi/drm/mediatek_drm.h               |  59 ++++
>  16 files changed, 607 insertions(+), 18 deletions(-)
>  create mode 100644 include/uapi/drm/mediatek_drm.h
> 

From zajec5 at gmail.com  Wed Dec 27 23:03:09 2023
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 28 Dec 2023 08:03:09 +0100
Subject: [PATCH] arm64: dts: mediatek: mt7986: fix reference to PWM in fan
 node
In-Reply-To: <a5113b85-e29c-454f-b776-ac7abbca771f@gmail.com>
References: <20231116130816.4932-1-zajec5@gmail.com>
 <a5113b85-e29c-454f-b776-ac7abbca771f@gmail.com>
Message-ID: <d0734a8f-0b72-4609-a941-da4bdc3e323e@gmail.com>

Hi,

On 14.12.2023 07:43, Rafa? Mi?ecki wrote:
> On 16.11.2023 14:08, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>
>> This fixes typo and resolves following validation error:
>> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm-fan: pwms: [[54, 0, 10000], [0]] is too long
>> ???????? from schema $id: http://devicetree.org/schemas/hwmon/pwm-fan.yaml#
>>
>> Fixes: c26f779a2295 ("arm64: dts: mt7986: add pwm-fan and cooling-maps to BPI-R3 dts")
>> Cc: Daniel Golle <daniel at makrotopia.org>
>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> I sent those few trivial fixes weeks ago:
> [PATCH] arm64: dts: mediatek: mt7986: fix reference to PWM in fan node
> [PATCH 1/2] arm64: dts: mediatek: mt7986: fix SPI bus width properties
> [PATCH 2/2] arm64: dts: mediatek: mt7986: fix SPI nodename
> [PATCH] arm64: dts: mediatek: mt7986: drop crypto's unneeded/invalid clock name
> 
> Could someone pick them up, please?

Anyone, please?

I did quick research and it seems Linus pulls mediatek DTS changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc (from Arnd)


Arnd seems to pull mediatek changes from either:

1. https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux
(Most pulls so far from Matthias)

2. git://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux
(The most recent pull from AngeloGioacchino)


AngeloGioacchino, Matthias: can you pick up my patches, please?

-- 
Rafa? Mi?ecki


From krzysztof.kozlowski at linaro.org  Wed Dec 27 23:06:45 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 28 Dec 2023 08:06:45 +0100
Subject: [PATCH] pinctrl: samsung: constify iomem pointers
In-Reply-To: <CACRpkdYLXEA3D-_22jsios5-CdpC5CLxFbTUA-Z=dqTHmtH9XQ@mail.gmail.com>
References: <20231223191902.22857-1-krzysztof.kozlowski@linaro.org>
 <CACRpkdYLXEA3D-_22jsios5-CdpC5CLxFbTUA-Z=dqTHmtH9XQ@mail.gmail.com>
Message-ID: <2ba69228-f916-4c63-8b51-b9f4695a7d58@linaro.org>

On 28/12/2023 01:23, Linus Walleij wrote:
> On Sat, Dec 23, 2023 at 8:19?PM Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org> wrote:
> 
>> Constify few pointers to iomem, where the destination memory is not
>> modified, for code safety and readability.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> 
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> 
> Is this something I should just apply directly at this point?

Yes, please take it.

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 27 23:14:24 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 28 Dec 2023 08:14:24 +0100
Subject: [PATCH] arm64: dts: mediatek: mt7986: fix reference to PWM in fan
 node
In-Reply-To: <d0734a8f-0b72-4609-a941-da4bdc3e323e@gmail.com>
References: <20231116130816.4932-1-zajec5@gmail.com>
 <a5113b85-e29c-454f-b776-ac7abbca771f@gmail.com>
 <d0734a8f-0b72-4609-a941-da4bdc3e323e@gmail.com>
Message-ID: <ddbdec9b-f075-4c7e-9411-28baf1e68401@linaro.org>

On 28/12/2023 08:03, Rafa? Mi?ecki wrote:
> Hi,
> 
> On 14.12.2023 07:43, Rafa? Mi?ecki wrote:
>> On 16.11.2023 14:08, Rafa? Mi?ecki wrote:
>>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>>
>>> This fixes typo and resolves following validation error:
>>> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm-fan: pwms: [[54, 0, 10000], [0]] is too long
>>> ???????? from schema $id: http://devicetree.org/schemas/hwmon/pwm-fan.yaml#
>>>
>>> Fixes: c26f779a2295 ("arm64: dts: mt7986: add pwm-fan and cooling-maps to BPI-R3 dts")
>>> Cc: Daniel Golle <daniel at makrotopia.org>
>>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
>>
>> I sent those few trivial fixes weeks ago:
>> [PATCH] arm64: dts: mediatek: mt7986: fix reference to PWM in fan node
>> [PATCH 1/2] arm64: dts: mediatek: mt7986: fix SPI bus width properties
>> [PATCH 2/2] arm64: dts: mediatek: mt7986: fix SPI nodename
>> [PATCH] arm64: dts: mediatek: mt7986: drop crypto's unneeded/invalid clock name
>>
>> Could someone pick them up, please?

This should happen some time ago but...

> 
> Anyone, please?

... exactly now, this cannot happen. We are way past applying patches
for the next cycle. Please ping or resend after the merge window.

> 
> I did quick research and it seems Linus pulls mediatek DTS changes from:
> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc (from Arnd)
> 
> 
> Arnd seems to pull mediatek changes from either:
> 
> 1. https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux
> (Most pulls so far from Matthias)
> 
> 2. git://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux
> (The most recent pull from AngeloGioacchino)
> 
> 
> AngeloGioacchino, Matthias: can you pick up my patches, please?

Best regards,
Krzysztof



From krzysztof.kozlowski at linaro.org  Wed Dec 27 23:30:05 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Thu, 28 Dec 2023 08:30:05 +0100
Subject: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0
 clock management unit
In-Reply-To: <425a228e-b2d3-4b19-9bcb-6ee1a90cd2ef@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-3-tudor.ambarus@linaro.org>
 <20231220150726.GA223267-robh@kernel.org>
 <173b06ab-2518-49ee-a67f-85256bc5b6a7@linaro.org>
 <425a228e-b2d3-4b19-9bcb-6ee1a90cd2ef@linaro.org>
Message-ID: <7b39f962-8040-48b0-8580-abf5970bfad0@linaro.org>

On 27/12/2023 13:38, Tudor Ambarus wrote:
> Hi, Rob,
> 
> On 12/21/23 07:20, Tudor Ambarus wrote:
>>
>>
>> On 12/20/23 15:07, Rob Herring wrote:
>>> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>>>> clock management unit.
>>>>
>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>>>> ---
>>>>  .../bindings/clock/google,gs101-clock.yaml    | 25 +++++-
>>>>  include/dt-bindings/clock/google,gs101.h      | 86 +++++++++++++++++++
>>>>  2 files changed, 109 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>> index 3eebc03a309b..ba54c13c55bc 100644
>>>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>> @@ -30,14 +30,15 @@ properties:
>>>>        - google,gs101-cmu-top
>>>>        - google,gs101-cmu-apm
>>>>        - google,gs101-cmu-misc
>>>> +      - google,gs101-cmu-peric0
>>>>  
>>>>    clocks:
>>>>      minItems: 1
>>>> -    maxItems: 2
>>>> +    maxItems: 3
>>>>  
>>>>    clock-names:
>>>>      minItems: 1
>>>> -    maxItems: 2
>>>> +    maxItems: 3
>>>>  
>>>>    "#clock-cells":
>>>>      const: 1
>>>> @@ -88,6 +89,26 @@ allOf:
>>>>              - const: dout_cmu_misc_bus
>>>>              - const: dout_cmu_misc_sss
>>>>  
>>>> +  - if:
>>>> +      properties:
>>>> +        compatible:
>>>> +          contains:
>>>> +            const: google,gs101-cmu-peric0
>>>> +
>>>> +    then:
>>>> +      properties:
>>>> +        clocks:
>>>> +          items:
>>>> +            - description: External reference clock (24.576 MHz)
>>>> +            - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>>>> +            - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>>>> +
>>>> +        clock-names:
>>>> +          items:
>>>> +            - const: oscclk
>>>> +            - const: dout_cmu_peric0_bus
>>>> +            - const: dout_cmu_peric0_ip
>>>
>>> 'bus' and 'ip' are sufficient because naming is local to the module. The 
>>> same is true on 'dout_cmu_misc_bus'. As that has not made a release, 
>>> please fix all of them.
>>>
>>
>> Ok, will fix them shortly. Thanks, Rob!
> 
> I tried your suggestion at
> https://lore.kernel.org/linux-arm-kernel/c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f at linaro.org/
> 
> and we noticed that we'd have to update the clock driver as well.
> These CMUs set the DT clock-name of the parent clock in the driver in
> struct samsung_cmu_info::clk_name[]. The driver then tries to enable the
> parent clock based on the clock-name in exynos_arm64_register_cmu().
> 
> In order to enable the parent clock of the CMU the following would be
> needed in the driver:
> 
> diff --git a/drivers/clk/samsung/clk-gs101.c
> b/drivers/clk/samsung/clk-gs101.c
> index 68a27b78b00b..e91836ea3a98 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -2476,7 +2476,7 @@ static const struct samsung_cmu_info misc_cmu_info
> __initconst = {
>         .nr_clk_ids             = CLKS_NR_MISC,
>         .clk_regs               = misc_clk_regs,
>         .nr_clk_regs            = ARRAY_SIZE(misc_clk_regs),
> -       .clk_name               = "dout_cmu_misc_bus",
> +       .clk_name               = "bus",

Yes, obviously, the names are used...

The entire point was that a week ago Rob said:
"As that has not made a release,  please fix all of them."
but if you keep waiting, like 8 days for this simple patch, his
statement is not true anymore.

The only point was to send a fix *the next day*, so I would apply it and
send further. You kind of solved that problem by waiting entire week for
a simple driver and DTS change.

Best regards,
Krzysztof



From ck.hu at mediatek.com  Wed Dec 27 23:35:15 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Thu, 28 Dec 2023 07:35:15 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <d4eb25a2affed65ed30a269e4b54e8d1a671abde.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +static int cmdq_sec_session_reply(const u32 iwc_cmd, struct
> iwc_cmdq_message_t *iwc_msg,
> +				  void *data, struct cmdq_sec_task
> *sec_task)
> +{
> +	struct iwc_cmdq_cancel_task_t *cancel = data;
> +	struct cmdq_sec_data *sec_data = sec_task->task.pkt->sec_data;
> +
> +	if (iwc_cmd == CMD_CMDQ_IWC_SUBMIT_TASK && iwc_msg->rsp < 0) {
> +		/* submit fail case copy status */
> +		memcpy(&sec_data->sec_status, &iwc_msg->sec_status,
> +		       sizeof(sec_data->sec_status));

sec_data->sec_status is useless, so drop it.

> +		sec_data->response = iwc_msg->rsp;

sec_data->response is useless, so drop it.

Regards,
CK

> +	} else if (iwc_cmd == CMD_CMDQ_IWC_CANCEL_TASK && cancel) {
> +		/* cancel case only copy cancel result */
> +		memcpy(cancel, &iwc_msg->cancel_task, sizeof(*cancel));
> +	}
> +
> +	return iwc_msg->rsp;
> +}
> +

From ck.hu at mediatek.com  Wed Dec 27 23:37:20 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Thu, 28 Dec 2023 07:37:20 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <c33745a4424777df44efe811dba060700f0009f0.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +
> +static bool cmdq_sec_irq_handler(struct cmdq_sec_thread *sec_thread,
> +				 const u32 cookie, const int err)
> +{
> +	struct cmdq_sec_task *sec_task;
> +	struct cmdq_task *task, *temp, *cur_task = NULL;
> +	struct cmdq_sec *cmdq = container_of(sec_thread->thread.chan-
> >mbox, struct cmdq_sec, mbox);
> +	unsigned long flags;
> +	int done;
> +
> +	spin_lock_irqsave(&sec_thread->thread.chan->lock, flags);
> +	if (sec_thread->wait_cookie <= cookie)
> +		done = cookie - sec_thread->wait_cookie + 1;
> +	else if (sec_thread->wait_cookie == (cookie + 1) %
> CMDQ_MAX_COOKIE_VALUE)
> +		done = 0;
> +	else
> +		done = CMDQ_MAX_COOKIE_VALUE - sec_thread->wait_cookie
> + 1 + cookie + 1;
> +
> +	list_for_each_entry_safe(task, temp, &sec_thread-
> >thread.task_busy_list, list_entry) {
> +		if (!done)
> +			break;
> +
> +		sec_task = container_of(task, struct cmdq_sec_task,
> task);
> +		cmdq_sec_task_done(sec_task, err);
> +
> +		if (sec_thread->task_cnt)
> +			sec_thread->task_cnt -= 1;
> +
> +		done--;
> +	}
> +
> +	cur_task = list_first_entry_or_null(&sec_thread-
> >thread.task_busy_list,
> +					    struct cmdq_task,
> list_entry);
> +	if (err && cur_task) {
> +		spin_unlock_irqrestore(&sec_thread->thread.chan->lock,
> flags);
> +
> +		sec_task = container_of(cur_task, struct cmdq_sec_task,
> task);
> +
> +		/* for error task, cancel, callback and done */
> +		memset(&cmdq->cancel, 0, sizeof(cmdq->cancel));
> +		cmdq_sec_task_submit(cmdq, sec_task,
> CMD_CMDQ_IWC_CANCEL_TASK,
> +				     sec_thread->idx, &cmdq->cancel);

cmdq->cancel is useless, so drop it.

Regards,
CK

> +
> +		cmdq_sec_task_done(sec_task, err);
> +
> +		spin_lock_irqsave(&sec_thread->thread.chan->lock,
> flags);
> +
> +		task = list_first_entry_or_null(&sec_thread-
> >thread.task_busy_list,
> +						struct cmdq_task,
> list_entry);
> +		if (cur_task == task)
> +			cmdq_sec_task_done(sec_task, err);
> +		else
> +			dev_err(cmdq->mbox.dev, "task list changed");
> +
> +		/*
> +		 * error case stop all task for secure,
> +		 * since secure tdrv always remove all when cancel
> +		 */
> +		while (!list_empty(&sec_thread->thread.task_busy_list)) 
> {
> +			cur_task = list_first_entry(&sec_thread-
> >thread.task_busy_list,
> +						    struct cmdq_task,
> list_entry);
> +
> +			sec_task = container_of(cur_task, struct
> cmdq_sec_task, task);
> +			cmdq_sec_task_done(sec_task, -ECONNABORTED);
> +		}
> +	} else if (err) {
> +		dev_dbg(cmdq->mbox.dev, "error but all task done, check
> notify callback");
> +	}
> +
> +	if (list_empty(&sec_thread->thread.task_busy_list)) {
> +		sec_thread->wait_cookie = 0;
> +		sec_thread->next_cookie = 0;
> +		sec_thread->task_cnt = 0;
> +		__raw_writel(0, (void __iomem *)cmdq->shared_mem->va +
> +			     CMDQ_SEC_SHARED_THR_CNT_OFFSET +
> +			     sec_thread->idx * sizeof(u32));
> +		spin_unlock_irqrestore(&sec_thread->thread.chan->lock,
> flags);
> +		del_timer(&sec_thread->timeout);
> +		return true;
> +	}
> +
> +	sec_thread->wait_cookie = cookie % CMDQ_MAX_COOKIE_VALUE + 1;
> +
> +	mod_timer(&sec_thread->timeout, jiffies +
> msecs_to_jiffies(sec_thread->timeout_ms));
> +	spin_unlock_irqrestore(&sec_thread->thread.chan->lock, flags);
> +
> +	return false;
> +}

From tudor.ambarus at linaro.org  Wed Dec 27 23:49:46 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 07:49:46 +0000
Subject: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0
 clock management unit
In-Reply-To: <7b39f962-8040-48b0-8580-abf5970bfad0@linaro.org>
References: <20231214105243.3707730-1-tudor.ambarus@linaro.org>
 <20231214105243.3707730-3-tudor.ambarus@linaro.org>
 <20231220150726.GA223267-robh@kernel.org>
 <173b06ab-2518-49ee-a67f-85256bc5b6a7@linaro.org>
 <425a228e-b2d3-4b19-9bcb-6ee1a90cd2ef@linaro.org>
 <7b39f962-8040-48b0-8580-abf5970bfad0@linaro.org>
Message-ID: <68b64171-6548-44b0-b5c9-8a5343b57828@linaro.org>



On 12/28/23 07:30, Krzysztof Kozlowski wrote:
> On 27/12/2023 13:38, Tudor Ambarus wrote:
>> Hi, Rob,
>>
>> On 12/21/23 07:20, Tudor Ambarus wrote:
>>>
>>>
>>> On 12/20/23 15:07, Rob Herring wrote:
>>>> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>>>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>>>>> clock management unit.
>>>>>
>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
>>>>> ---
>>>>>  .../bindings/clock/google,gs101-clock.yaml    | 25 +++++-
>>>>>  include/dt-bindings/clock/google,gs101.h      | 86 +++++++++++++++++++
>>>>>  2 files changed, 109 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>>> index 3eebc03a309b..ba54c13c55bc 100644
>>>>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>>> @@ -30,14 +30,15 @@ properties:
>>>>>        - google,gs101-cmu-top
>>>>>        - google,gs101-cmu-apm
>>>>>        - google,gs101-cmu-misc
>>>>> +      - google,gs101-cmu-peric0
>>>>>  
>>>>>    clocks:
>>>>>      minItems: 1
>>>>> -    maxItems: 2
>>>>> +    maxItems: 3
>>>>>  
>>>>>    clock-names:
>>>>>      minItems: 1
>>>>> -    maxItems: 2
>>>>> +    maxItems: 3
>>>>>  
>>>>>    "#clock-cells":
>>>>>      const: 1
>>>>> @@ -88,6 +89,26 @@ allOf:
>>>>>              - const: dout_cmu_misc_bus
>>>>>              - const: dout_cmu_misc_sss
>>>>>  
>>>>> +  - if:
>>>>> +      properties:
>>>>> +        compatible:
>>>>> +          contains:
>>>>> +            const: google,gs101-cmu-peric0
>>>>> +
>>>>> +    then:
>>>>> +      properties:
>>>>> +        clocks:
>>>>> +          items:
>>>>> +            - description: External reference clock (24.576 MHz)
>>>>> +            - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>>>>> +            - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>>>>> +
>>>>> +        clock-names:
>>>>> +          items:
>>>>> +            - const: oscclk
>>>>> +            - const: dout_cmu_peric0_bus
>>>>> +            - const: dout_cmu_peric0_ip
>>>>
>>>> 'bus' and 'ip' are sufficient because naming is local to the module. The 
>>>> same is true on 'dout_cmu_misc_bus'. As that has not made a release, 
>>>> please fix all of them.
>>>>
>>>
>>> Ok, will fix them shortly. Thanks, Rob!
>>
>> I tried your suggestion at
>> https://lore.kernel.org/linux-arm-kernel/c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f at linaro.org/
>>
>> and we noticed that we'd have to update the clock driver as well.
>> These CMUs set the DT clock-name of the parent clock in the driver in
>> struct samsung_cmu_info::clk_name[]. The driver then tries to enable the
>> parent clock based on the clock-name in exynos_arm64_register_cmu().
>>
>> In order to enable the parent clock of the CMU the following would be
>> needed in the driver:
>>
>> diff --git a/drivers/clk/samsung/clk-gs101.c
>> b/drivers/clk/samsung/clk-gs101.c
>> index 68a27b78b00b..e91836ea3a98 100644
>> --- a/drivers/clk/samsung/clk-gs101.c
>> +++ b/drivers/clk/samsung/clk-gs101.c
>> @@ -2476,7 +2476,7 @@ static const struct samsung_cmu_info misc_cmu_info
>> __initconst = {
>>         .nr_clk_ids             = CLKS_NR_MISC,
>>         .clk_regs               = misc_clk_regs,
>>         .nr_clk_regs            = ARRAY_SIZE(misc_clk_regs),
>> -       .clk_name               = "dout_cmu_misc_bus",
>> +       .clk_name               = "bus",
> 
> Yes, obviously, the names are used...
> 
> The entire point was that a week ago Rob said:
> "As that has not made a release,  please fix all of them."
> but if you keep waiting, like 8 days for this simple patch, his
> statement is not true anymore.
> 

I saw the problem at the end of Thursday, reported it, and after that I
entered vacation.

> The only point was to send a fix *the next day*, so I would apply it and
> send further. You kind of solved that problem by waiting entire week for
> a simple driver and DTS change.
> 
Why can't we queue the name fix as a patch for v6.8-rc1? Of course if
you consider that the change is worth it. As I said, I lean towards not
changing it.

Thanks,
ta


From chunyan.zhang at unisoc.com  Thu Dec 28 00:49:58 2023
From: chunyan.zhang at unisoc.com (Chunyan Zhang)
Date: Thu, 28 Dec 2023 16:49:58 +0800
Subject: [GIT PULL] ARM: sprd: DTS and bindings for v6.8-rc1
Message-ID: <20231228084958.1439115-1-chunyan.zhang@unisoc.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://github.com/lyrazhang/linux.git tags/sprd-dt-6.8-rc1

for you to fetch changes up to 1cff7243334f851b7dddf450abdaa6223a7a28e3:

  arm64: dts: sprd: Change UMS512 idle-state nodename to match bindings (2023-12-28 16:10:39 +0800)

----------------------------------------------------------------
ARM: sprd: DTS and bindings for v6.8-rc1

Unisoc ARM64 DTS and bindings changes are:
- Fixed a few dtb_check warnings
- Add bindings for a new SoC - UMS9620
- Fixed an issue on UMS512

----------------------------------------------------------------
Chunyan Zhang (5):
      dt-bindings: arm: Add compatible strings for Unisoc's UMS9620
      arm64: dts: sprd: Add support for Unisoc's UMS9620
      arm64: dts: sprd: Removed unused clock references from etm nodes
      arm64: dts: sprd: Add clock reference for pll2 on UMS512
      arm64: dts: sprd: Change UMS512 idle-state nodename to match bindings

Cixi Geng (1):
      arm64: dts: sprd: fix the cpu node for UMS512

 .../devicetree/bindings/arm/sprd/sprd.yaml         |   5 +
 arch/arm64/boot/dts/sprd/Makefile                  |   3 +-
 arch/arm64/boot/dts/sprd/ums512.dtsi               |  39 ++--
 arch/arm64/boot/dts/sprd/ums9620-2h10.dts          |  38 ++++
 arch/arm64/boot/dts/sprd/ums9620.dtsi              | 245 +++++++++++++++++++++
 5 files changed, 310 insertions(+), 20 deletions(-)
 create mode 100644 arch/arm64/boot/dts/sprd/ums9620-2h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/ums9620.dtsi


From florian.fainelli at broadcom.com  Thu Dec 28 00:58:22 2023
From: florian.fainelli at broadcom.com (Florian Fainelli)
Date: Thu, 28 Dec 2023 00:58:22 -0800
Subject: [GIT PULL 1/1] Broadcom devicetree changes for 6.8
Message-ID: <20231228085822.3656546-1-florian.fainelli@broadcom.com>

The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://github.com/Broadcom/stblinux.git tags/arm-soc/for-6.8/devicetree

for you to fetch changes up to dadc77c93b6e8ca8edd1e290fc1702dc5cef18e3:

  ARM: dts: broadcom: Add BCM63138's high speed UART (2023-12-05 14:44:48 -0800)

----------------------------------------------------------------
This pull request contains Broadcom ARM-based SoCs Device Tree changes
for 6.8, please pull the following:

- Rafal adds a Device Tree node for the BCM63138 high-speed UART used
  for Bluetooth devices

----------------------------------------------------------------
Rafa? Mi?ecki (1):
      ARM: dts: broadcom: Add BCM63138's high speed UART

 arch/arm/boot/dts/broadcom/bcm63138.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)


From jszhang at kernel.org  Thu Dec 28 00:46:40 2023
From: jszhang at kernel.org (Jisheng Zhang)
Date: Thu, 28 Dec 2023 16:46:40 +0800
Subject: [PATCH 0/2] riscv: tlb: avoid tlb flushing on exit & execve
Message-ID: <20231228084642.1765-1-jszhang@kernel.org>

The mmu_gather code sets fullmm=1 when tearing down the entire address
space for an mm_struct on exit or execve. So if the underlying platform
supports ASID, the tlb flushing can be avoided because the ASID
allocator will never re-allocate a dirty ASID.

But currently, the tlb_finish_mmu() sets fullmm, when in fact it wants
to say that the TLB should be fully flushed.

So patch1 takes one of Nadav's patch from [1] to fix fullmm semantics.
Compared with original patch from[1], the differences are:
a. fixes the fullmm semantics in arm64 too
b. bring back the fullmm optimization back on arm64.

patch2 does the optimization on riscv.

Use the performance of Process creation in unixbench on T-HEAD TH1520
platform is improved by about 4%.

Link: https://lore.kernel.org/linux-mm/20210131001132.3368247-2-namit at vmware.com/ [1]

Jisheng Zhang (1):
  riscv: tlb: avoid tlb flushing if fullmm == 1

Nadav Amit (1):
  mm/tlb: fix fullmm semantics

 arch/arm64/include/asm/tlb.h | 5 ++++-
 arch/riscv/include/asm/tlb.h | 9 +++++++++
 include/asm-generic/tlb.h    | 2 +-
 mm/mmu_gather.c              | 2 +-
 4 files changed, 15 insertions(+), 3 deletions(-)

-- 
2.40.0



From jszhang at kernel.org  Thu Dec 28 00:46:41 2023
From: jszhang at kernel.org (Jisheng Zhang)
Date: Thu, 28 Dec 2023 16:46:41 +0800
Subject: [PATCH 1/2] mm/tlb: fix fullmm semantics
In-Reply-To: <20231228084642.1765-1-jszhang@kernel.org>
References: <20231228084642.1765-1-jszhang@kernel.org>
Message-ID: <20231228084642.1765-2-jszhang@kernel.org>

From: Nadav Amit <namit at vmware.com>

fullmm in mmu_gather is supposed to indicate that the mm is torn-down
(e.g., on process exit) and can therefore allow certain optimizations.
However, tlb_finish_mmu() sets fullmm, when in fact it want to say that
the TLB should be fully flushed.

Change tlb_finish_mmu() to set need_flush_all and check this flag in
tlb_flush_mmu_tlbonly() when deciding whether a flush is needed.

At the same time, bring the arm64 fullmm on process exit optimization back.

Signed-off-by: Nadav Amit <namit at vmware.com>
Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
Cc: Andrea Arcangeli <aarcange at redhat.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Andy Lutomirski <luto at kernel.org>
Cc: Dave Hansen <dave.hansen at linux.intel.com>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Will Deacon <will at kernel.org>
Cc: Yu Zhao <yuzhao at google.com>
Cc: Nick Piggin <npiggin at gmail.com>
Cc: x86 at kernel.org
---
 arch/arm64/include/asm/tlb.h | 5 ++++-
 include/asm-generic/tlb.h    | 2 +-
 mm/mmu_gather.c              | 2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
index 846c563689a8..6164c5f3b78f 100644
--- a/arch/arm64/include/asm/tlb.h
+++ b/arch/arm64/include/asm/tlb.h
@@ -62,7 +62,10 @@ static inline void tlb_flush(struct mmu_gather *tlb)
 	 * invalidating the walk-cache, since the ASID allocator won't
 	 * reallocate our ASID without invalidating the entire TLB.
 	 */
-	if (tlb->fullmm) {
+	if (tlb->fullmm)
+		return;
+
+	if (tlb->need_flush_all) {
 		if (!last_level)
 			flush_tlb_mm(tlb->mm);
 		return;
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 129a3a759976..f2d46357bcbb 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -452,7 +452,7 @@ static inline void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
 	 * these bits.
 	 */
 	if (!(tlb->freed_tables || tlb->cleared_ptes || tlb->cleared_pmds ||
-	      tlb->cleared_puds || tlb->cleared_p4ds))
+	      tlb->cleared_puds || tlb->cleared_p4ds || tlb->need_flush_all))
 		return;
 
 	tlb_flush(tlb);
diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
index 4f559f4ddd21..79298bac3481 100644
--- a/mm/mmu_gather.c
+++ b/mm/mmu_gather.c
@@ -384,7 +384,7 @@ void tlb_finish_mmu(struct mmu_gather *tlb)
 		 * On x86 non-fullmm doesn't yield significant difference
 		 * against fullmm.
 		 */
-		tlb->fullmm = 1;
+		tlb->need_flush_all = 1;
 		__tlb_reset_range(tlb);
 		tlb->freed_tables = 1;
 	}
-- 
2.40.0



From jszhang at kernel.org  Thu Dec 28 00:46:42 2023
From: jszhang at kernel.org (Jisheng Zhang)
Date: Thu, 28 Dec 2023 16:46:42 +0800
Subject: [PATCH 2/2] riscv: tlb: avoid tlb flushing if fullmm == 1
In-Reply-To: <20231228084642.1765-1-jszhang@kernel.org>
References: <20231228084642.1765-1-jszhang@kernel.org>
Message-ID: <20231228084642.1765-3-jszhang@kernel.org>

The mmu_gather code sets fullmm=1 when tearing down the entire address
space for an mm_struct on exit or execve. So if the underlying platform
supports ASID, the tlb flushing can be avoided because the ASID
allocator will never re-allocate a dirty ASID.

Use the performance of Process creation in unixbench on T-HEAD TH1520
platform is improved by about 4%.

Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
---
 arch/riscv/include/asm/tlb.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/riscv/include/asm/tlb.h b/arch/riscv/include/asm/tlb.h
index 1eb5682b2af6..35f3c214332e 100644
--- a/arch/riscv/include/asm/tlb.h
+++ b/arch/riscv/include/asm/tlb.h
@@ -12,10 +12,19 @@ static void tlb_flush(struct mmu_gather *tlb);
 
 #define tlb_flush tlb_flush
 #include <asm-generic/tlb.h>
+#include <asm/mmu_context.h>
 
 static inline void tlb_flush(struct mmu_gather *tlb)
 {
 #ifdef CONFIG_MMU
+	/*
+	 * If ASID is supported, the ASID allocator will either invalidate the
+	 * ASID or mark it as used. So we can avoid TLB invalidation when
+	 * pulling down a full mm.
+	 */
+	if (static_branch_likely(&use_asid_allocator) && tlb->fullmm)
+		return;
+
 	if (tlb->fullmm || tlb->need_flush_all)
 		flush_tlb_mm(tlb->mm);
 	else
-- 
2.40.0



From quic_jinlmao at quicinc.com  Thu Dec 28 01:33:19 2023
From: quic_jinlmao at quicinc.com (Mao Jinlong)
Date: Thu, 28 Dec 2023 01:33:19 -0800
Subject: [PATCH] coresight: Add coresight name support
Message-ID: <20231228093321.5522-1-quic_jinlmao@quicinc.com>

Add coresight name support for custom names which will be
easy to identify the device by the name.

Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
---
 .../hwtracing/coresight/coresight-cti-core.c  | 20 ++++++++------
 drivers/hwtracing/coresight/coresight-dummy.c | 10 ++++---
 .../hwtracing/coresight/coresight-platform.c  | 27 +++++++++++++++++++
 drivers/hwtracing/coresight/coresight-tpdm.c  | 10 ++++---
 include/linux/coresight.h                     |  1 +
 5 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
index 3999d0a2cb60..60a1e76064a9 100644
--- a/drivers/hwtracing/coresight/coresight-cti-core.c
+++ b/drivers/hwtracing/coresight/coresight-cti-core.c
@@ -902,14 +902,18 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
 	/* default to powered - could change on PM notifications */
 	drvdata->config.hw_powered = true;
 
-	/* set up device name - will depend if cpu bound or otherwise */
-	if (drvdata->ctidev.cpu >= 0)
-		cti_desc.name = devm_kasprintf(dev, GFP_KERNEL, "cti_cpu%d",
-					       drvdata->ctidev.cpu);
-	else
-		cti_desc.name = coresight_alloc_device_name(&cti_sys_devs, dev);
-	if (!cti_desc.name)
-		return -ENOMEM;
+	cti_desc.name = coresight_get_device_name(dev);
+	if (!cti_desc.name) {
+		/* set up device name - will depend if cpu bound or otherwise */
+		if (drvdata->ctidev.cpu >= 0)
+			cti_desc.name = devm_kasprintf(dev, GFP_KERNEL, "cti_cpu%d",
+						       drvdata->ctidev.cpu);
+		else {
+			cti_desc.name = coresight_alloc_device_name(&cti_sys_devs, dev);
+			if (!cti_desc.name)
+				return -ENOMEM;
+		}
+	}
 
 	/* setup CPU power management handling for CPU bound CTI devices. */
 	ret = cti_pm_setup(drvdata);
diff --git a/drivers/hwtracing/coresight/coresight-dummy.c b/drivers/hwtracing/coresight/coresight-dummy.c
index e4deafae7bc2..b19cd400df79 100644
--- a/drivers/hwtracing/coresight/coresight-dummy.c
+++ b/drivers/hwtracing/coresight/coresight-dummy.c
@@ -76,10 +76,12 @@ static int dummy_probe(struct platform_device *pdev)
 	struct coresight_desc desc = { 0 };
 
 	if (of_device_is_compatible(node, "arm,coresight-dummy-source")) {
-
-		desc.name = coresight_alloc_device_name(&source_devs, dev);
-		if (!desc.name)
-			return -ENOMEM;
+		desc.name = coresight_get_device_name(dev);
+		if (!desc.name) {
+			desc.name = coresight_alloc_device_name(&source_devs, dev);
+			if (!desc.name)
+				return -ENOMEM;
+		}
 
 		desc.type = CORESIGHT_DEV_TYPE_SOURCE;
 		desc.subtype.source_subtype =
diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
index 9d550f5697fa..284aa22a06b7 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -183,6 +183,18 @@ static int of_coresight_get_cpu(struct device *dev)
 	return cpu;
 }
 
+static const char *of_coresight_get_device_name(struct device *dev)
+{
+	const char *name = NULL;
+
+	if (!dev->of_node)
+		return NULL;
+
+	of_property_read_string(dev->of_node, "coresight-name", &name);
+
+	return name;
+}
+
 /*
  * of_coresight_parse_endpoint : Parse the given output endpoint @ep
  * and fill the connection information in @pdata->out_conns
@@ -315,6 +327,12 @@ static inline int of_coresight_get_cpu(struct device *dev)
 {
 	return -ENODEV;
 }
+
+static inline const char *of_coresight_get_device_name(struct device *dev)
+{
+	return NULL;
+}
+
 #endif
 
 #ifdef CONFIG_ACPI
@@ -794,6 +812,15 @@ int coresight_get_cpu(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(coresight_get_cpu);
 
+const char *coresight_get_device_name(struct device *dev)
+{
+	if (is_of_node(dev->fwnode))
+		return of_coresight_get_device_name(dev);
+	else
+		return NULL;
+}
+EXPORT_SYMBOL_GPL(coresight_get_device_name);
+
 struct coresight_platform_data *
 coresight_get_platform_data(struct device *dev)
 {
diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
index f4854af0431e..7735ff18c48e 100644
--- a/drivers/hwtracing/coresight/coresight-tpdm.c
+++ b/drivers/hwtracing/coresight/coresight-tpdm.c
@@ -201,9 +201,13 @@ static int tpdm_probe(struct amba_device *adev, const struct amba_id *id)
 	drvdata->base = base;
 
 	/* Set up coresight component description */
-	desc.name = coresight_alloc_device_name(&tpdm_devs, dev);
-	if (!desc.name)
-		return -ENOMEM;
+	desc.name = coresight_get_device_name(dev);
+	if (!desc.name) {
+		desc.name = coresight_alloc_device_name(&tpdm_devs, dev);
+		if (!desc.name)
+			return -ENOMEM;
+	}
+
 	desc.type = CORESIGHT_DEV_TYPE_SOURCE;
 	desc.subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS;
 	desc.ops = &tpdm_cs_ops;
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index a269fffaf991..caa17c8af865 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -675,6 +675,7 @@ static inline void coresight_write64(struct coresight_device *csdev, u64 val, u3
 #endif		/* IS_ENABLED(CONFIG_CORESIGHT) */
 
 extern int coresight_get_cpu(struct device *dev);
+extern const char *coresight_get_device_name(struct device *dev);
 
 struct coresight_platform_data *coresight_get_platform_data(struct device *dev);
 struct coresight_connection *
-- 
2.41.0



From sudeep.holla at arm.com  Thu Dec 28 02:25:08 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Thu, 28 Dec 2023 10:25:08 +0000
Subject: [PATCH 1/2] firmware/psci: Set
 pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
In-Reply-To: <20231227-topic-psci_fw_sus-v1-1-6910add70bf3@linaro.org>
References: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
 <20231227-topic-psci_fw_sus-v1-1-6910add70bf3@linaro.org>
Message-ID: <20231228102508.dyyrfxkd7lssweoj@bogus>

On Wed, Dec 27, 2023 at 11:15:30PM +0100, Konrad Dybcio wrote:
> Some device drivers are curious to know whether "the firmware" (which is
> often assumed to be ACPI) takes care of suspending or resuming the
> platform. Set the flag that reports this behavior if SYSTEM_SUSPEND is
> implemented.
>

Reviewed-by: Sudeep Holla <sudeep.holla at arm.com>

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Thu Dec 28 02:28:01 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Thu, 28 Dec 2023 10:28:01 +0000
Subject: [PATCH 2/2] firmware/psci: Set
 pm_set_resume/suspend_via_firmware() on qcom
In-Reply-To: <20231227-topic-psci_fw_sus-v1-2-6910add70bf3@linaro.org>
References: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
 <20231227-topic-psci_fw_sus-v1-2-6910add70bf3@linaro.org>
Message-ID: <20231228102801.fzaubcjq5thfwgxg@bogus>

On Wed, Dec 27, 2023 at 11:15:31PM +0100, Konrad Dybcio wrote:
> Most Qualcomm platforms implementing PSCI (ab)use CPU_SUSPEND for
> entering various stages of suspend, across the SoC. These range from a
> simple WFI to a full-fledged power collapse of the entire chip
> (mostly, anyway).
> 
> Some device drivers are curious to know whether "the firmware" (which is
> often assumed to be ACPI) takes care of suspending or resuming the
> platform. Set the flag that reports this behavior on the aforementioned
> chips.
> 
> Some newer Qualcomm chips ship with firmware that actually advertises
> PSCI SYSTEM_SUSPEND, so the compatible list should only grow slightly.
>

NACK, just use suspend-to-idle if SYSTEM_SUSPEND is not advertised. It is
designed for such platforms especially on x86/ACPI which don't advertise
Sx states. I see no reason why that doesn't work on ARM platforms as well.

-- 
Regards,
Sudeep


From s.trumtrar at pengutronix.de  Thu Dec 28 02:19:06 2023
From: s.trumtrar at pengutronix.de (Steffen Trumtrar)
Date: Thu, 28 Dec 2023 11:19:06 +0100
Subject: [BUG] soc: fsl: qbman: lockdep invalid wait context with
 qman_update_cgr_smp_call
Message-ID: <87wmsyvclu.fsf@pengutronix.de>


Hi,

I noticed that lockdep reports a BUG on the qman driver since

    914f8b228ede709274b8c80514b352248ec9da00
    Author:     Sean Anderson <sean.anderson at seco.com>
    AuthorDate: Fri Sep 2 17:57:35 2022 -0400
    Commit:     David S. Miller <davem at davemloft.net>
    CommitDate: Mon Sep 5 14:27:39 2022 +0100

    soc: fsl: qbman: Add CGR update function

    This adds a function to update a CGR with new parameters. qman_create_cgr
    can almost be used for this (with flags=0), but it's not suitable because
    it also registers the callback function. The _safe variant was modeled off
    of qman_cgr_delete_safe. However, we handle multiple arguments and a return
    value.

The stack trace looks something like:

    [   20.192060] =============================
    [   20.196067] [ BUG: Invalid wait context ]
    [   20.200073] 6.7.0-rc6 #73 Not tainted
    [   20.203733] -----------------------------
    [   20.207738] systemd-journal/114 is trying to lock:
    [   20.212528] ffff000973403860 (&portal->cgr_lock){+.+.}-{3:3}, at: qman_update_cgr_smp_call+0x40/0xb0
    [   20.221688] other info that might help us debug this:
    [   20.226736] context-{2:2}
    [   20.229350] 1 lock held by systemd-journal/114:
    [   20.233878]  #0: ffff0008001a0208 (&root->kernfs_iattr_rwsem){++++}-{4:4}, at: kernfs_iop_permission+0x48/0xa0
    [   20.243902] stack backtrace:
    [   20.246779] CPU: 2 PID: 114 Comm: systemd-journal Not tainted 6.7.0-rc6 #73
    [   20.253743] Hardware name: TQ TQMLS1046A SoM on Arkona AT1130 (AT300) board (DT)
    [   20.261144] Call trace:
    [   20.261147]  dump_backtrace+0xa0/0x128
    [   20.261154]  show_stack+0x20/0x38
    [   20.261158]  dump_stack_lvl+0x74/0xd8
    [   20.274303]  dump_stack+0x18/0x28
    [   20.279004]  __lock_acquire+0x920/0x1b58
    [   20.284309]  lock_acquire+0x1fc/0x348
    [   20.289354]  _raw_spin_lock_irqsave+0x6c/0xd0
    [   20.294748]  qman_update_cgr_smp_call+0x40/0xb0
    [   20.299278]  __flush_smp_call_function_queue+0x1d0/0x3e0
    [   20.304593]  generic_smp_call_function_single_interrupt+0x1c/0x30
    [   20.310689]  ipi_handler+0x250/0x290
    [   20.314263]  handle_percpu_devid_irq+0xb0/0x170
    [   20.318793]  generic_handle_domain_irq+0x34/0x58
    [   20.323411]  gic_handle_irq+0x4c/0xd8
    [   20.327070]  call_on_irq_stack+0x24/0x58
    [   20.330991]  do_interrupt_handler+0xdc/0xe8
    [   20.335173]  el1_interrupt+0x34/0x68
    [   20.338747]  el1h_64_irq_handler+0x18/0x28
    [   20.342843]  el1h_64_irq+0x64/0x68
    [   20.346240]  lock_acquired+0x198/0x448
    [   20.349988]  down_read+0x98/0x1c0
    [   20.353300]  kernfs_iop_permission+0x48/0xa0
    [   20.357569]  inode_permission+0x118/0x190
    [   20.361578]  link_path_walk.part.0.constprop.0+0x2b0/0x398
    [   20.367065]  path_lookupat+0x44/0x1b8
    [   20.370726]  filename_lookup+0x9c/0x170
    [   20.374561]  user_path_at_empty+0x54/0x88
    [   20.378571]  do_faccessat+0x88/0x308
    [   20.382144]  __arm64_sys_access+0x2c/0x40
    [   20.386152]  invoke_syscall+0x50/0x120
    [   20.389901]  el0_svc_common.constprop.0+0xc8/0xf0
    [   20.394606]  do_el0_svc_compat+0x24/0x40
    [   20.398528]  el0_svc_compat+0x4c/0x148
    [   20.402275]  el0t_32_sync_handler+0xb0/0x138
    [   20.406545]  el0t_32_sync+0x194/0x198

The
    [   20.207738] systemd-journal/114 is trying to lock:
can be any other process and must not be systemd-journal. For example when barebox-state triggers the stacktrace the function calls look like:

#                                _-----=> irqs-off/BH-disabled
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| / _-=> migrate-disable
#                              |||| /     delay
#           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
#              | |         |   |||||     |         |
         systemd-1       [002] ...2.     6.871198: qm_modify_cgr <-qman_init_cgr_all
         (...)
     kworker/2:1-38      [002] ...1.    19.070335: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed
   barebox-state-211     [001] d.h1.    19.070344: qman_update_cgr_smp_call <-__flush_smp_call_function_queue
   barebox-state-211     [001] d.h3.    19.260311: qm_modify_cgr <-qman_update_cgr_smp_call
     kworker/2:1-38      [002] ...1.    19.305517: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed
          <idle>-0       [001] d.h2.    19.305524: qman_update_cgr_smp_call <-__flush_smp_call_function_queue
          <idle>-0       [001] d.h4.    19.305526: qm_modify_cgr <-qman_update_cgr_smp_call
     kworker/3:1-40      [003] ...1.    19.354259: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed
          <idle>-0       [001] d.h2.    19.354265: qman_update_cgr_smp_call <-__flush_smp_call_function_queue
          <idle>-0       [001] d.h4.    19.354267: qm_modify_cgr <-qman_update_cgr_smp_call

I'm not sure why the CPU# detection in the patch is necessary, but maybe you have an idea what is happening here.


Best regards,
Steffen

--
Pengutronix e.K.                | Dipl.-Inform. Steffen Trumtrar |
Steuerwalder Str. 21            | https://www.pengutronix.de/    |
31137 Hildesheim, Germany       | Phone: +49-5121-206917-0       |
Amtsgericht Hildesheim, HRA 2686| Fax:   +49-5121-206917-5555    |


From mathias.nyman at linux.intel.com  Thu Dec 28 02:44:15 2023
From: mathias.nyman at linux.intel.com (Mathias Nyman)
Date: Thu, 28 Dec 2023 12:44:15 +0200
Subject: [PATCH v4 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue
In-Reply-To: <20231227060316.8539-1-chunfeng.yun@mediatek.com>
References: <20231227060316.8539-1-chunfeng.yun@mediatek.com>
Message-ID: <1718f25d-3274-3e4d-0cdf-72fda8788e39@linux.intel.com>

Hi

On 27.12.2023 8.03, Chunfeng Yun wrote:
> For Gen1 isoc-in endpoint on controller before about SSUSB IPM v1.6.0, it
> still send out unexpected ACK after receiving a short packet in burst
> transfer, this will cause an exception on connected device, specially for
> a 4k camera.
> Add a quirk property "rx-fifo-depth" to work around this hardware issue,
> prefer to use 3k bytes;
> The side-effect is that may cause performance drop about 10%, including
> bulk transfer.

Is it be possible to detect those Mediatek xHC versions that need this
workaround in the xhci-mtk driver directly?

This way we could avoid passing a new "rx-fifo-depth" property to it.

Thanks
Mathias



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:28 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:28 +0800
Subject: [PATCH v8 01/20] docs: geniezone: Introduce GenieZone hypervisor
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-2-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

GenieZone is MediaTek proprietary hypervisor solution, and it is running
in EL2 stand alone as a type-I hypervisor. It is a pure EL2
implementation which implies it does not rely any specific host VM, and
this behavior improves GenieZone's security as it limits its interface.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 Documentation/virt/geniezone/introduction.rst | 87 +++++++++++++++++++
 Documentation/virt/index.rst                  |  1 +
 MAINTAINERS                                   |  6 ++
 3 files changed, 94 insertions(+)
 create mode 100644 Documentation/virt/geniezone/introduction.rst

diff --git a/Documentation/virt/geniezone/introduction.rst b/Documentation/virt/geniezone/introduction.rst
new file mode 100644
index 000000000000..f280476228b3
--- /dev/null
+++ b/Documentation/virt/geniezone/introduction.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
+GenieZone Introduction
+======================
+
+Overview
+========
+GenieZone hypervisor (gzvm) is a type-1 hypervisor that supports various virtual
+machine types and provides security features such as TEE-like scenarios and
+secure boot. It can create guest VMs for security use cases and has
+virtualization capabilities for both platform and interrupt. Although the
+hypervisor can be booted independently, it requires the assistance of GenieZone
+hypervisor kernel driver(also named gzvm) to leverage the ability of Linux
+kernel for vCPU scheduling, memory management, inter-VM communication and virtio
+backend support.
+
+Supported Architecture
+======================
+GenieZone now only supports MediaTek ARM64 SoC.
+
+Features
+========
+
+- vCPU Management
+
+  VM manager aims to provide vCPUs on the basis of time sharing on physical
+  CPUs. It requires Linux kernel in host VM for vCPU scheduling and VM power
+  management.
+
+- Memory Management
+
+  Direct use of physical memory from VMs is forbidden and designed to be
+  dictated to the privilege models managed by GenieZone hypervisor for security
+  reason. With the help of gzvm module, the hypervisor would be able to manipulate
+  memory as objects.
+
+- Virtual Platform
+
+  We manage to emulate a virtual mobile platform for guest OS running on guest
+  VM. The platform supports various architecture-defined devices, such as
+  virtual arch timer, GIC, MMIO, PSCI, and exception watching...etc.
+
+- Inter-VM Communication
+
+  Communication among guest VMs was provided mainly on RPC. More communication
+  mechanisms were to be provided in the future based on VirtIO-vsock.
+
+- Device Virtualization
+
+  The solution is provided using the well-known VirtIO. The gzvm module would
+  redirect MMIO traps back to VMM where the virtual devices are mostly emulated.
+  Ioeventfd is implemented using eventfd for signaling host VM that some IO
+  events in guest VMs need to be processed.
+
+- Interrupt virtualization
+
+  All Interrupts during some guest VMs running would be handled by GenieZone
+  hypervisor with the help of gzvm module, both virtual and physical ones.
+  In case there's no guest VM running out there, physical interrupts would be
+  handled by host VM directly for performance reason. Irqfd is also implemented
+  using eventfd for accepting vIRQ requests in gzvm module.
+
+Platform architecture component
+===============================
+
+- vm
+
+  The vm component is responsible for setting up the capability and memory
+  management for the protected VMs. The capability is mainly about the lifecycle
+  control and boot context initialization. And the memory management is highly
+  integrated with ARM 2-stage translation tables to convert VA to IPA to PA
+  under proper security measures required by protected VMs.
+
+- vcpu
+
+  The vcpu component is the core of virtualizing aarch64 physical CPU runnable,
+  and it controls the vCPU lifecycle including creating, running and destroying.
+  With self-defined exit handler, the vm component would be able to act
+  accordingly before terminated.
+
+- vgic
+
+  The vgic component exposes control interfaces to Linux kernel via irqchip, and
+  we intend to support all SPI, PPI, and SGI. When it comes to virtual
+  interrupts, the GenieZone hypervisor would write to list registers and trigger
+  vIRQ injection in guest VMs via GIC.
diff --git a/Documentation/virt/index.rst b/Documentation/virt/index.rst
index 7fb55ae08598..cf12444db336 100644
--- a/Documentation/virt/index.rst
+++ b/Documentation/virt/index.rst
@@ -16,6 +16,7 @@ Virtualization Support
    coco/sev-guest
    coco/tdx-guest
    hyperv/index
+   geniezone/introduction
 
 .. only:: html and subproject
 
diff --git a/MAINTAINERS b/MAINTAINERS
index d1af56dc3113..184a16268032 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8979,6 +8979,12 @@ F:	include/vdso/
 F:	kernel/time/vsyscall.c
 F:	lib/vdso/
 
+GENIEZONE HYPERVISOR DRIVER
+M:	Yingshiuan Pan <yingshiuan.pan at mediatek.com>
+M:	Ze-Yu Wang <ze-yu.wang at mediatek.com>
+M:	Yi-De Wu <yi-de.wu at mediatek.com>
+F:	Documentation/virt/geniezone/
+
 GENWQE (IBM Generic Workqueue Card)
 M:	Frank Haverkamp <haver at linux.ibm.com>
 S:	Supported
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:38 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:38 +0800
Subject: [PATCH v8 11/20] virt: geniezone: Add ioeventfd support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-12-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

Ioeventfd leverages eventfd to provide asynchronous notification
mechanism for VMM. VMM can register a mmio address and bind with an
eventfd. Once a mmio trap occurs on this registered region, its
corresponding eventfd will be notified.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 drivers/virt/geniezone/Makefile         |   3 +-
 drivers/virt/geniezone/gzvm_ioeventfd.c | 276 ++++++++++++++++++++++++
 drivers/virt/geniezone/gzvm_vcpu.c      |  27 ++-
 drivers/virt/geniezone/gzvm_vm.c        |  17 ++
 include/linux/gzvm_drv.h                |  12 ++
 include/uapi/linux/gzvm.h               |  25 +++
 6 files changed, 358 insertions(+), 2 deletions(-)
 create mode 100644 drivers/virt/geniezone/gzvm_ioeventfd.c

diff --git a/drivers/virt/geniezone/Makefile b/drivers/virt/geniezone/Makefile
index cebe5ad53f41..9956f4891df2 100644
--- a/drivers/virt/geniezone/Makefile
+++ b/drivers/virt/geniezone/Makefile
@@ -8,4 +8,5 @@ GZVM_DIR ?= ../../../drivers/virt/geniezone
 
 gzvm-y := $(GZVM_DIR)/gzvm_main.o $(GZVM_DIR)/gzvm_vm.o \
 	  $(GZVM_DIR)/gzvm_mmu.o $(GZVM_DIR)/gzvm_vcpu.o \
-	  $(GZVM_DIR)/gzvm_irqfd.o
+	  $(GZVM_DIR)/gzvm_irqfd.o $(GZVM_DIR)/gzvm_ioeventfd.o
+
diff --git a/drivers/virt/geniezone/gzvm_ioeventfd.c b/drivers/virt/geniezone/gzvm_ioeventfd.c
new file mode 100644
index 000000000000..542b414485e3
--- /dev/null
+++ b/drivers/virt/geniezone/gzvm_ioeventfd.c
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/eventfd.h>
+#include <linux/file.h>
+#include <linux/syscalls.h>
+#include <linux/gzvm.h>
+#include <linux/gzvm_drv.h>
+#include <linux/wait.h>
+#include <linux/poll.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+struct gzvm_ioevent {
+	struct list_head list;
+	__u64 addr;
+	__u32 len;
+	struct eventfd_ctx  *evt_ctx;
+	__u64 datamatch;
+	bool wildcard;
+};
+
+/**
+ * ioeventfd_check_collision() - Check collison assumes gzvm->slots_lock held.
+ * @gzvm: Pointer to gzvm.
+ * @p: Pointer to gzvm_ioevent.
+ *
+ * Return:
+ * * true			- collison found
+ * * false			- no collison
+ */
+static bool ioeventfd_check_collision(struct gzvm *gzvm, struct gzvm_ioevent *p)
+{
+	struct gzvm_ioevent *_p;
+
+	list_for_each_entry(_p, &gzvm->ioevents, list) {
+		if (_p->addr == p->addr &&
+		    (!_p->len || !p->len ||
+		     (_p->len == p->len &&
+		      (_p->wildcard || p->wildcard ||
+		       _p->datamatch == p->datamatch))))
+			return true;
+		if (p->addr >= _p->addr && p->addr < _p->addr + _p->len)
+			return true;
+	}
+
+	return false;
+}
+
+static void gzvm_ioevent_release(struct gzvm_ioevent *p)
+{
+	eventfd_ctx_put(p->evt_ctx);
+	list_del(&p->list);
+	kfree(p);
+}
+
+static bool gzvm_ioevent_in_range(struct gzvm_ioevent *p, __u64 addr, int len,
+				  const void *val)
+{
+	u64 _val;
+
+	if (addr != p->addr)
+		/* address must be precise for a hit */
+		return false;
+
+	if (!p->len)
+		/* length = 0 means only look at the address, so always a hit */
+		return true;
+
+	if (len != p->len)
+		/* address-range must be precise for a hit */
+		return false;
+
+	if (p->wildcard)
+		/* all else equal, wildcard is always a hit */
+		return true;
+
+	/* otherwise, we have to actually compare the data */
+
+	WARN_ON_ONCE(!IS_ALIGNED((unsigned long)val, len));
+
+	switch (len) {
+	case 1:
+		_val = *(u8 *)val;
+		break;
+	case 2:
+		_val = *(u16 *)val;
+		break;
+	case 4:
+		_val = *(u32 *)val;
+		break;
+	case 8:
+		_val = *(u64 *)val;
+		break;
+	default:
+		return false;
+	}
+
+	return _val == p->datamatch;
+}
+
+static int gzvm_deassign_ioeventfd(struct gzvm *gzvm,
+				   struct gzvm_ioeventfd *args)
+{
+	struct gzvm_ioevent *p, *tmp;
+	struct eventfd_ctx *evt_ctx;
+	int ret = -ENOENT;
+	bool wildcard;
+
+	evt_ctx = eventfd_ctx_fdget(args->fd);
+	if (IS_ERR(evt_ctx))
+		return PTR_ERR(evt_ctx);
+
+	wildcard = !(args->flags & GZVM_IOEVENTFD_FLAG_DATAMATCH);
+
+	mutex_lock(&gzvm->lock);
+
+	list_for_each_entry_safe(p, tmp, &gzvm->ioevents, list) {
+		if (p->evt_ctx != evt_ctx  ||
+		    p->addr != args->addr  ||
+		    p->len != args->len ||
+		    p->wildcard != wildcard)
+			continue;
+
+		if (!p->wildcard && p->datamatch != args->datamatch)
+			continue;
+
+		gzvm_ioevent_release(p);
+		ret = 0;
+		break;
+	}
+
+	mutex_unlock(&gzvm->lock);
+
+	/* got in the front of this function */
+	eventfd_ctx_put(evt_ctx);
+
+	return ret;
+}
+
+static int gzvm_assign_ioeventfd(struct gzvm *gzvm, struct gzvm_ioeventfd *args)
+{
+	struct eventfd_ctx *evt_ctx;
+	struct gzvm_ioevent *evt;
+	int ret;
+
+	evt_ctx = eventfd_ctx_fdget(args->fd);
+	if (IS_ERR(evt_ctx))
+		return PTR_ERR(evt_ctx);
+
+	evt = kmalloc(sizeof(*evt), GFP_KERNEL);
+	if (!evt)
+		return -ENOMEM;
+	*evt = (struct gzvm_ioevent) {
+		.addr = args->addr,
+		.len = args->len,
+		.evt_ctx = evt_ctx,
+	};
+	if (args->flags & GZVM_IOEVENTFD_FLAG_DATAMATCH) {
+		evt->datamatch = args->datamatch;
+		evt->wildcard = false;
+	} else {
+		evt->wildcard = true;
+	}
+
+	if (ioeventfd_check_collision(gzvm, evt)) {
+		ret = -EEXIST;
+		goto err_free;
+	}
+
+	mutex_lock(&gzvm->lock);
+	list_add_tail(&evt->list, &gzvm->ioevents);
+	mutex_unlock(&gzvm->lock);
+
+	return 0;
+
+err_free:
+	kfree(evt);
+	eventfd_ctx_put(evt_ctx);
+	return ret;
+}
+
+/**
+ * gzvm_ioeventfd_check_valid() - Check user arguments is valid.
+ * @args: Pointer to gzvm_ioeventfd.
+ *
+ * Return:
+ * * true if user arguments are valid.
+ * * false if user arguments are invalid.
+ */
+static bool gzvm_ioeventfd_check_valid(struct gzvm_ioeventfd *args)
+{
+	/* must be natural-word sized, or 0 to ignore length */
+	switch (args->len) {
+	case 0:
+	case 1:
+	case 2:
+	case 4:
+	case 8:
+		break;
+	default:
+		return false;
+	}
+
+	/* check for range overflow */
+	if (args->addr + args->len < args->addr)
+		return false;
+
+	/* check for extra flags that we don't understand */
+	if (args->flags & ~GZVM_IOEVENTFD_VALID_FLAG_MASK)
+		return false;
+
+	/* ioeventfd with no length can't be combined with DATAMATCH */
+	if (!args->len && (args->flags & GZVM_IOEVENTFD_FLAG_DATAMATCH))
+		return false;
+
+	/* gzvm does not support pio bus ioeventfd */
+	if (args->flags & GZVM_IOEVENTFD_FLAG_PIO)
+		return false;
+
+	return true;
+}
+
+/**
+ * gzvm_ioeventfd() - Register ioevent to ioevent list.
+ * @gzvm: Pointer to gzvm.
+ * @args: Pointer to gzvm_ioeventfd.
+ *
+ * Return:
+ * * 0			- Success.
+ * * Negative		- Failure.
+ */
+int gzvm_ioeventfd(struct gzvm *gzvm, struct gzvm_ioeventfd *args)
+{
+	if (gzvm_ioeventfd_check_valid(args) == false)
+		return -EINVAL;
+
+	if (args->flags & GZVM_IOEVENTFD_FLAG_DEASSIGN)
+		return gzvm_deassign_ioeventfd(gzvm, args);
+	return gzvm_assign_ioeventfd(gzvm, args);
+}
+
+/**
+ * gzvm_ioevent_write() - Travers this vm's registered ioeventfd to see if
+ *			  need notifying it.
+ * @vcpu: Pointer to vcpu.
+ * @addr: mmio address.
+ * @len: mmio size.
+ * @val: Pointer to void.
+ *
+ * Return:
+ * * true if this io is already sent to ioeventfd's listener.
+ * * false if we cannot find any ioeventfd registering this mmio write.
+ */
+bool gzvm_ioevent_write(struct gzvm_vcpu *vcpu, __u64 addr, int len,
+			const void *val)
+{
+	struct gzvm_ioevent *e;
+
+	list_for_each_entry(e, &vcpu->gzvm->ioevents, list) {
+		if (gzvm_ioevent_in_range(e, addr, len, val)) {
+			eventfd_signal(e->evt_ctx);
+			return true;
+		}
+	}
+	return false;
+}
+
+int gzvm_init_ioeventfd(struct gzvm *gzvm)
+{
+	INIT_LIST_HEAD(&gzvm->ioevents);
+
+	return 0;
+}
diff --git a/drivers/virt/geniezone/gzvm_vcpu.c b/drivers/virt/geniezone/gzvm_vcpu.c
index 598f0ed2dbb5..77138e749e9a 100644
--- a/drivers/virt/geniezone/gzvm_vcpu.c
+++ b/drivers/virt/geniezone/gzvm_vcpu.c
@@ -51,6 +51,30 @@ static long gzvm_vcpu_update_one_reg(struct gzvm_vcpu *vcpu,
 	return 0;
 }
 
+/**
+ * gzvm_vcpu_handle_mmio() - Handle mmio in kernel space.
+ * @vcpu: Pointer to vcpu.
+ *
+ * Return:
+ * * true - This mmio exit has been processed.
+ * * false - This mmio exit has not been processed, require userspace.
+ */
+static bool gzvm_vcpu_handle_mmio(struct gzvm_vcpu *vcpu)
+{
+	__u64 addr;
+	__u32 len;
+	const void *val_ptr;
+
+	/* So far, we don't have in-kernel mmio read handler */
+	if (!vcpu->run->mmio.is_write)
+		return false;
+	addr = vcpu->run->mmio.phys_addr;
+	len = vcpu->run->mmio.size;
+	val_ptr = &vcpu->run->mmio.data;
+
+	return gzvm_ioevent_write(vcpu, addr, len, val_ptr);
+}
+
 /**
  * gzvm_vcpu_run() - Handle vcpu run ioctl, entry point to guest and exit
  *		     point from guest
@@ -82,7 +106,8 @@ static long gzvm_vcpu_run(struct gzvm_vcpu *vcpu, void __user *argp)
 
 		switch (exit_reason) {
 		case GZVM_EXIT_MMIO:
-			need_userspace = true;
+			if (!gzvm_vcpu_handle_mmio(vcpu))
+				need_userspace = true;
 			break;
 		/**
 		 * it's geniezone's responsibility to fill corresponding data
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index 2ab4391ff16a..d67bf647b615 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -223,6 +223,16 @@ static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 		ret = gzvm_irqfd(gzvm, &data);
 		break;
 	}
+	case GZVM_IOEVENTFD: {
+		struct gzvm_ioeventfd data;
+
+		if (copy_from_user(&data, argp, sizeof(data))) {
+			ret = -EFAULT;
+			goto out;
+		}
+		ret = gzvm_ioeventfd(gzvm, &data);
+		break;
+	}
 	case GZVM_ENABLE_CAP: {
 		struct gzvm_enable_cap cap;
 
@@ -299,6 +309,13 @@ static struct gzvm *gzvm_create_vm(unsigned long vm_type)
 		return ERR_PTR(ret);
 	}
 
+	ret = gzvm_init_ioeventfd(gzvm);
+	if (ret) {
+		pr_err("Failed to initialize ioeventfd\n");
+		kfree(gzvm);
+		return ERR_PTR(ret);
+	}
+
 	mutex_lock(&gzvm_list_lock);
 	list_add(&gzvm->vm_list, &gzvm_list);
 	mutex_unlock(&gzvm_list_lock);
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index 676e6b5714e8..406bc9f821b2 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -6,6 +6,7 @@
 #ifndef __GZVM_DRV_H__
 #define __GZVM_DRV_H__
 
+#include <linux/eventfd.h>
 #include <linux/list.h>
 #include <linux/mm.h>
 #include <linux/mutex.h>
@@ -95,6 +96,8 @@ struct gzvm {
 		struct mutex      resampler_lock;
 	} irqfds;
 
+	struct list_head ioevents;
+
 	struct list_head vm_list;
 	u16 vm_id;
 
@@ -149,4 +152,13 @@ void gzvm_drv_irqfd_exit(void);
 int gzvm_vm_irqfd_init(struct gzvm *gzvm);
 void gzvm_vm_irqfd_release(struct gzvm *gzvm);
 
+int gzvm_init_ioeventfd(struct gzvm *gzvm);
+int gzvm_ioeventfd(struct gzvm *gzvm, struct gzvm_ioeventfd *args);
+bool gzvm_ioevent_write(struct gzvm_vcpu *vcpu, __u64 addr, int len,
+			const void *val);
+void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt);
+struct vm_area_struct *vma_lookup(struct mm_struct *mm, unsigned long addr);
+void add_wait_queue_priority(struct wait_queue_head *wq_head,
+			     struct wait_queue_entry *wq_entry);
+
 #endif /* __GZVM_DRV_H__ */
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index cb02f278972f..ef433e311fa7 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -335,4 +335,29 @@ struct gzvm_irqfd {
 
 #define GZVM_IRQFD	_IOW(GZVM_IOC_MAGIC, 0x76, struct gzvm_irqfd)
 
+enum {
+	gzvm_ioeventfd_flag_nr_datamatch = 0,
+	gzvm_ioeventfd_flag_nr_pio = 1,
+	gzvm_ioeventfd_flag_nr_deassign = 2,
+	gzvm_ioeventfd_flag_nr_max,
+};
+
+#define GZVM_IOEVENTFD_FLAG_DATAMATCH	(1 << gzvm_ioeventfd_flag_nr_datamatch)
+#define GZVM_IOEVENTFD_FLAG_PIO		(1 << gzvm_ioeventfd_flag_nr_pio)
+#define GZVM_IOEVENTFD_FLAG_DEASSIGN	(1 << gzvm_ioeventfd_flag_nr_deassign)
+#define GZVM_IOEVENTFD_VALID_FLAG_MASK	((1 << gzvm_ioeventfd_flag_nr_max) - 1)
+
+struct gzvm_ioeventfd {
+	__u64 datamatch;
+	/* private: legal pio/mmio address */
+	__u64 addr;
+	/* private: 1, 2, 4, or 8 bytes; or 0 to ignore length */
+	__u32 len;
+	__s32 fd;
+	__u32 flags;
+	__u8  pad[36];
+};
+
+#define GZVM_IOEVENTFD	_IOW(GZVM_IOC_MAGIC, 0x79, struct gzvm_ioeventfd)
+
 #endif /* __GZVM_H__ */
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:29 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:29 +0800
Subject: [PATCH v8 02/20] dt-bindings: hypervisor: Add MediaTek GenieZone hypervisor
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-3-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

Add documentation for GenieZone(gzvm) node. This node informs gzvm
driver to start probing if geniezone hypervisor is available and
able to do virtual machine operations.

[Reason to use dt solution]
- The GenieZone hypervisor serves as a vendor model for facilitating platform
virtualization, with an implementation that is independent from Linuxism.
- In contrast to the dt solution, our previous approach involved probing via
hypercall to determine the existence of our hypervisor. However, this method
raised concerns about potentially impacting all systems, including those
without the GenieZone hypervisor embedded[ref].

ref: https://lore.kernel.org/all/2fe0c7f9-55fc-ae63-3631-8526a0212ccd at linaro.org/

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 .../hypervisor/mediatek,geniezone-hyp.yaml    | 31 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hypervisor/mediatek,geniezone-hyp.yaml

diff --git a/Documentation/devicetree/bindings/hypervisor/mediatek,geniezone-hyp.yaml b/Documentation/devicetree/bindings/hypervisor/mediatek,geniezone-hyp.yaml
new file mode 100644
index 000000000000..ab89a4c310cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/hypervisor/mediatek,geniezone-hyp.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hypervisor/mediatek,geniezone-hyp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek GenieZone hypervisor
+
+maintainers:
+  - Yingshiuan Pan <yingshiuan.pan at mediatek.com>
+
+description:
+  This interface is designed for integrating GenieZone hypervisor into Android
+  Virtualization Framework(AVF) along with Crosvm as a VMM.
+  It acts like a wrapper for every hypercall to GenieZone hypervisor in
+  order to control guest VM lifecycles and virtual interrupt injections.
+
+properties:
+  compatible:
+    const: mediatek,geniezone-hyp
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    hypervisor {
+        compatible = "mediatek,geniezone-hyp";
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 184a16268032..ac2b1c91f4b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8983,6 +8983,7 @@ GENIEZONE HYPERVISOR DRIVER
 M:	Yingshiuan Pan <yingshiuan.pan at mediatek.com>
 M:	Ze-Yu Wang <ze-yu.wang at mediatek.com>
 M:	Yi-De Wu <yi-de.wu at mediatek.com>
+F:	Documentation/devicetree/bindings/hypervisor/mediatek,geniezone-hyp.yaml
 F:	Documentation/virt/geniezone/
 
 GENWQE (IBM Generic Workqueue Card)
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:46 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:46 +0800
Subject: [PATCH v8 19/20] virt: geniezone: Add tracing support for hyp call and vcpu exit_reason
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-20-yi-de.wu@mediatek.com>

Add tracepoints for hypervisor calls and VCPU exit reasons in GenieZone
driver. It aids performance debugging by providing more information
about hypervisor operations and VCPU behavior.

Command Usage:
echo geniezone:* >> /sys/kernel/tracing/set_event
echo 1 > /sys/kernel/tracing/tracing_on
echo 0 > /sys/kernel/tracing/tracing_on
cat /sys/kernel/tracing/trace

For example:
crosvm_vcpu0-4838 [004] ..... 76053.536034: mtk_hypcall_enter: id=0xbb001005
crosvm_vcpu0-4838 [004] ..... 76053.540039: mtk_hypcall_leave: id=0xbb001005 invalid=0
crosvm_vcpu0-4838 [004] ..... 76053.540040: mtk_vcpu_exit: vcpu exit_reason=0x92920003

This example tracks a hypervisor function call by an ID (`0xbb001005`)
from initiation to termination, which is supported (invalid=0). A vCPU
exit is triggered by an Interrupt Request (IRQ) (exit reason: 0x92920003).

/* VM exit reason */
enum {
	GZVM_EXIT_UNKNOWN = 0x92920000,
	GZVM_EXIT_MMIO = 0x92920001,
	GZVM_EXIT_HYPERCALL = 0x92920002,
	GZVM_EXIT_IRQ = 0x92920003,
	GZVM_EXIT_EXCEPTION = 0x92920004,
	GZVM_EXIT_DEBUG = 0x92920005,
	GZVM_EXIT_FAIL_ENTRY = 0x92920006,
	GZVM_EXIT_INTERNAL_ERROR = 0x92920007,
	GZVM_EXIT_SYSTEM_EVENT = 0x92920008,
	GZVM_EXIT_SHUTDOWN = 0x92920009,
	GZVM_EXIT_GZ = 0x9292000a,
};

Signed-off-by: Liju-clr Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/vm.c          |  5 +++
 drivers/virt/geniezone/gzvm_vcpu.c |  3 ++
 include/trace/events/geniezone.h   | 54 ++++++++++++++++++++++++++++++
 3 files changed, 62 insertions(+)
 create mode 100644 include/trace/events/geniezone.h

diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index a9d264bbb3b1..5667643251b5 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -7,6 +7,8 @@
 #include <linux/err.h>
 #include <linux/uaccess.h>
 
+#define CREATE_TRACE_POINTS
+#include <trace/events/geniezone.h>
 #include <linux/gzvm.h>
 #include <linux/gzvm_drv.h>
 #include "gzvm_arch_common.h"
@@ -33,7 +35,10 @@ int gzvm_hypcall_wrapper(unsigned long a0, unsigned long a1,
 			 unsigned long a6, unsigned long a7,
 			 struct arm_smccc_res *res)
 {
+	trace_mtk_hypcall_enter(a0);
 	arm_smccc_hvc(a0, a1, a2, a3, a4, a5, a6, a7, res);
+	trace_mtk_hypcall_leave(a0, (res->a0 != ERR_NOT_SUPPORTED) ? 0 : 1);
+
 	return gzvm_err_to_errno(res->a0);
 }
 
diff --git a/drivers/virt/geniezone/gzvm_vcpu.c b/drivers/virt/geniezone/gzvm_vcpu.c
index 86c690749277..138ec064596b 100644
--- a/drivers/virt/geniezone/gzvm_vcpu.c
+++ b/drivers/virt/geniezone/gzvm_vcpu.c
@@ -10,6 +10,8 @@
 #include <linux/mm.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
+
+#include <trace/events/geniezone.h>
 #include <linux/gzvm_drv.h>
 
 /* maximum size needed for holding an integer */
@@ -103,6 +105,7 @@ static long gzvm_vcpu_run(struct gzvm_vcpu *vcpu, void __user *argp)
 
 	while (!need_userspace && !signal_pending(current)) {
 		gzvm_arch_vcpu_run(vcpu, &exit_reason);
+		trace_mtk_vcpu_exit(exit_reason);
 
 		switch (exit_reason) {
 		case GZVM_EXIT_MMIO:
diff --git a/include/trace/events/geniezone.h b/include/trace/events/geniezone.h
new file mode 100644
index 000000000000..1fa44f9c4b3c
--- /dev/null
+++ b/include/trace/events/geniezone.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM geniezone
+
+#define _TRACE_GENIEZONE_H
+
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(mtk_hypcall_enter,
+	    TP_PROTO(unsigned long id),
+
+	    TP_ARGS(id),
+
+	    TP_STRUCT__entry(__field(unsigned long, id)),
+
+	    TP_fast_assign(__entry->id = id;),
+
+	    TP_printk("id=0x%lx", __entry->id)
+);
+
+TRACE_EVENT(mtk_hypcall_leave,
+	    TP_PROTO(unsigned long id, unsigned long invalid),
+
+	    TP_ARGS(id, invalid),
+
+	    TP_STRUCT__entry(__field(unsigned long, id)
+			     __field(unsigned long, invalid)
+	    ),
+
+	    TP_fast_assign(__entry->id = id;
+			   __entry->invalid = invalid;
+	    ),
+
+	    TP_printk("id=0x%lx invalid=%lu", __entry->id, __entry->invalid)
+);
+
+TRACE_EVENT(mtk_vcpu_exit,
+	    TP_PROTO(unsigned long exit_reason),
+
+	    TP_ARGS(exit_reason),
+
+	    TP_STRUCT__entry(__field(unsigned long, exit_reason)),
+
+	    TP_fast_assign(__entry->exit_reason = exit_reason;),
+
+	    TP_printk("vcpu exit_reason=0x%lx", __entry->exit_reason)
+);
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:47 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:47 +0800
Subject: [PATCH v8 20/20] virt: geniezone: Enable PTP for synchronizing time between host and guest VMs
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-21-yi-de.wu@mediatek.com>

From: "Kevenny Hsieh" <kevenny.hsieh at mediatek.com>

Enabled Precision Time Protocol (PTP) for improved host-guest VM time
synchronization, optimizing operations needing precise clock sync in
virtual environment.

Signed-off-by: Kevenny Hsieh <kevenny.hsieh at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/Makefile           |  2 +-
 arch/arm64/geniezone/gzvm_arch_common.h |  3 +
 arch/arm64/geniezone/hvc.c              | 73 +++++++++++++++++++++++++
 drivers/virt/geniezone/gzvm_exception.c |  3 +-
 include/linux/gzvm_drv.h                |  1 +
 include/uapi/linux/gzvm.h               |  1 +
 6 files changed, 80 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/geniezone/hvc.c

diff --git a/arch/arm64/geniezone/Makefile b/arch/arm64/geniezone/Makefile
index 0e4f1087f9de..553a64a926dc 100644
--- a/arch/arm64/geniezone/Makefile
+++ b/arch/arm64/geniezone/Makefile
@@ -4,6 +4,6 @@
 #
 include $(srctree)/drivers/virt/geniezone/Makefile
 
-gzvm-y += vm.o vcpu.o vgic.o
+gzvm-y += vm.o vcpu.o vgic.o hvc.o
 
 obj-$(CONFIG_MTK_GZVM) += gzvm.o
diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index fbaf2da792a4..e697223f0fd6 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -93,6 +93,8 @@ static inline u16 get_vcpuid_from_tuple(unsigned int tuple)
  * @__pad: add an explicit '__u32 __pad;' in the middle to make it clear
  *         what the actual layout is.
  * @lr: The array of LRs(list registers).
+ * @vtimer_offset: The offset maintained by hypervisor that is host cycle count
+ *                 when guest VM startup.
  *
  * - Keep the same layout of hypervisor data struct.
  * - Sync list registers back for acking virtual device interrupt status.
@@ -101,6 +103,7 @@ struct gzvm_vcpu_hwstate {
 	__le32 nr_lrs;
 	__le32 __pad;
 	__le64 lr[GIC_V3_NR_LRS];
+	__le64 vtimer_offset;
 };
 
 static inline unsigned int
diff --git a/arch/arm64/geniezone/hvc.c b/arch/arm64/geniezone/hvc.c
new file mode 100644
index 000000000000..603db0fad3d8
--- /dev/null
+++ b/arch/arm64/geniezone/hvc.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+#include <linux/clocksource.h>
+#include <linux/kernel.h>
+#include <linux/timekeeping.h>
+#include <linux/gzvm_drv.h>
+#include "gzvm_arch_common.h"
+
+#define GZVM_PTP_VIRT_COUNTER 0
+#define GZVM_PTP_PHYS_COUNTER 1
+/**
+ * gzvm_handle_ptp_time() - Sync time between host and guest VM
+ * @vcpu: Pointer to struct gzvm_vcpu_run in userspace
+ * @counter: Counter type from guest VM
+ * Return: Always return 0 because there are no cases of failure
+ *
+ * The following register values will be passed to the guest VM
+ * for time synchronization:
+ * regs->x0 (upper 32 bits) wall clock time
+ * regs->x1 (lower 32 bits) wall clock time
+ * regs->x2 (upper 32 bits) cycles
+ * regs->x3 (lower 32 bits) cycles
+ */
+static int gzvm_handle_ptp_time(struct gzvm_vcpu *vcpu, int counter)
+{
+	struct system_time_snapshot snapshot;
+	u64 cycles = 0;
+
+	ktime_get_snapshot(&snapshot);
+
+	switch (counter) {
+	case GZVM_PTP_VIRT_COUNTER:
+		cycles = snapshot.cycles -
+			 le64_to_cpu(vcpu->hwstate->vtimer_offset);
+		break;
+	case GZVM_PTP_PHYS_COUNTER:
+		cycles = snapshot.cycles;
+		break;
+	default:
+		break;
+	}
+
+	vcpu->run->hypercall.args[0] = upper_32_bits(snapshot.real);
+	vcpu->run->hypercall.args[1] = lower_32_bits(snapshot.real);
+	vcpu->run->hypercall.args[2] = upper_32_bits(cycles);
+	vcpu->run->hypercall.args[3] = lower_32_bits(cycles);
+
+	return 0;
+}
+
+/**
+ * gzvm_arch_handle_guest_hvc() - Handle architecture-related guest hvc
+ * @vcpu: Pointer to struct gzvm_vcpu_run in userspace
+ * Return:
+ * * true - This hvc has been processed, no need to back to VMM.
+ * * false - This hvc has not been processed, require userspace.
+ */
+bool gzvm_arch_handle_guest_hvc(struct gzvm_vcpu *vcpu)
+{
+	int ret, counter;
+
+	switch (vcpu->run->hypercall.args[0]) {
+	case GZVM_HVC_PTP:
+		counter = vcpu->run->hypercall.args[1];
+		ret = gzvm_handle_ptp_time(vcpu, counter);
+		return (ret == 0) ? true : false;
+	default:
+		break;
+	}
+	return false;
+}
diff --git a/drivers/virt/geniezone/gzvm_exception.c b/drivers/virt/geniezone/gzvm_exception.c
index af26d1c82791..e6209b3b3a3e 100644
--- a/drivers/virt/geniezone/gzvm_exception.c
+++ b/drivers/virt/geniezone/gzvm_exception.c
@@ -56,7 +56,6 @@ bool gzvm_handle_guest_hvc(struct gzvm_vcpu *vcpu)
 		ret = gzvm_handle_relinquish(vcpu, ipa);
 		return (ret == 0) ? true : false;
 	default:
-		break;
+		return gzvm_arch_handle_guest_hvc(vcpu);
 	}
-	return false;
 }
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index a4e6c7eb9c17..fcdc6c30baea 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -192,6 +192,7 @@ int gzvm_handle_page_fault(struct gzvm_vcpu *vcpu);
 bool gzvm_handle_guest_exception(struct gzvm_vcpu *vcpu);
 int gzvm_handle_relinquish(struct gzvm_vcpu *vcpu, phys_addr_t ipa);
 bool gzvm_handle_guest_hvc(struct gzvm_vcpu *vcpu);
+bool gzvm_arch_handle_guest_hvc(struct gzvm_vcpu *vcpu);
 
 int gzvm_arch_create_device(u16 vm_id, struct gzvm_create_device *gzvm_dev);
 int gzvm_arch_inject_irq(struct gzvm *gzvm, unsigned int vcpu_idx,
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index a98787a18c36..cd854afb445e 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -195,6 +195,7 @@ enum {
 
 /* hypercall definitions of GZVM_EXIT_HYPERCALL */
 enum {
+	GZVM_HVC_PTP = 0x86000001,
 	GZVM_HVC_MEM_RELINQUISH = 0xc6000009,
 };
 
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:40 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:40 +0800
Subject: [PATCH v8 13/20] virt: geniezone: Add dtb config support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-14-yi-de.wu@mediatek.com>

From: "Jerry Wang" <ze-yu.wang at mediatek.com>

Hypervisor might need to know the accurate address and size of dtb
passed from userspace. And then hypervisor would parse the dtb and get
vm information.

Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: Liju-clr Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/gzvm_arch_common.h |  2 ++
 arch/arm64/geniezone/vm.c               |  9 +++++++++
 drivers/virt/geniezone/gzvm_vm.c        | 10 ++++++++++
 include/linux/gzvm_drv.h                |  1 +
 include/uapi/linux/gzvm.h               | 14 ++++++++++++++
 5 files changed, 36 insertions(+)

diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index 8d1406beeaed..afb91713fc45 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -23,6 +23,7 @@ enum {
 	GZVM_FUNC_ENABLE_CAP = 13,
 	GZVM_FUNC_INFORM_EXIT = 14,
 	GZVM_FUNC_MEMREGION_PURPOSE = 15,
+	GZVM_FUNC_SET_DTB_CONFIG = 16,
 	NR_GZVM_FUNC,
 };
 
@@ -46,6 +47,7 @@ enum {
 #define MT_HVC_GZVM_ENABLE_CAP		GZVM_HCALL_ID(GZVM_FUNC_ENABLE_CAP)
 #define MT_HVC_GZVM_INFORM_EXIT		GZVM_HCALL_ID(GZVM_FUNC_INFORM_EXIT)
 #define MT_HVC_GZVM_MEMREGION_PURPOSE	GZVM_HCALL_ID(GZVM_FUNC_MEMREGION_PURPOSE)
+#define MT_HVC_GZVM_SET_DTB_CONFIG	GZVM_HCALL_ID(GZVM_FUNC_SET_DTB_CONFIG)
 
 #define GIC_V3_NR_LRS			16
 
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index 210f7569d7cc..4ca2ec43b37c 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -140,6 +140,15 @@ int gzvm_arch_memregion_purpose(struct gzvm *gzvm,
 				    mem->flags, 0, 0, 0, &res);
 }
 
+int gzvm_arch_set_dtb_config(struct gzvm *gzvm, struct gzvm_dtb_config *cfg)
+{
+	struct arm_smccc_res res;
+
+	return gzvm_hypcall_wrapper(MT_HVC_GZVM_SET_DTB_CONFIG, gzvm->vm_id,
+				    cfg->dtb_addr, cfg->dtb_size, 0, 0, 0, 0,
+				    &res);
+}
+
 static int gzvm_vm_arch_enable_cap(struct gzvm *gzvm,
 				   struct gzvm_enable_cap *cap,
 				   struct arm_smccc_res *res)
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index 4134605cbf7d..538549ef405c 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -250,6 +250,16 @@ static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 		ret = gzvm_vm_ioctl_enable_cap(gzvm, &cap, argp);
 		break;
 	}
+	case GZVM_SET_DTB_CONFIG: {
+		struct gzvm_dtb_config cfg;
+
+		if (copy_from_user(&cfg, argp, sizeof(cfg))) {
+			ret = -EFAULT;
+			goto out;
+		}
+		ret = gzvm_arch_set_dtb_config(gzvm, &cfg);
+		break;
+	}
 	default:
 		ret = -ENOTTY;
 	}
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index d35ca179b688..43d85dc5d7c0 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -154,6 +154,7 @@ void gzvm_vm_irqfd_release(struct gzvm *gzvm);
 
 int gzvm_arch_memregion_purpose(struct gzvm *gzvm,
 				struct gzvm_userspace_memory_region *mem);
+int gzvm_arch_set_dtb_config(struct gzvm *gzvm, struct gzvm_dtb_config *args);
 
 int gzvm_init_ioeventfd(struct gzvm *gzvm);
 int gzvm_ioeventfd(struct gzvm *gzvm, struct gzvm_ioeventfd *args);
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index ef433e311fa7..f4f04403d5b3 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -360,4 +360,18 @@ struct gzvm_ioeventfd {
 
 #define GZVM_IOEVENTFD	_IOW(GZVM_IOC_MAGIC, 0x79, struct gzvm_ioeventfd)
 
+/**
+ * struct gzvm_dtb_config: store address and size of dtb passed from userspace
+ *
+ * @dtb_addr: dtb address set by VMM (guset memory)
+ * @dtb_size: dtb size
+ */
+struct gzvm_dtb_config {
+	__u64 dtb_addr;
+	__u64 dtb_size;
+};
+
+#define GZVM_SET_DTB_CONFIG       _IOW(GZVM_IOC_MAGIC, 0xff, \
+				       struct gzvm_dtb_config)
+
 #endif /* __GZVM_H__ */
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:37 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:37 +0800
Subject: [PATCH v8 10/20] virt: geniezone: Add irqfd support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-11-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

irqfd enables other threads than vcpu threads to inject virtual
interrupt through irqfd asynchronously rather through ioctl interface.
This interface is necessary for VMM which creates separated thread for
IO handling or uses vhost devices.

Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202311182112.B1KM0yj9-lkp at intel.com/
Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: kevenny hsieh <kevenny.hsieh at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/gzvm_arch_common.h |  18 ++
 drivers/virt/geniezone/Makefile         |   3 +-
 drivers/virt/geniezone/gzvm_irqfd.c     | 382 ++++++++++++++++++++++++
 drivers/virt/geniezone/gzvm_main.c      |  12 +-
 drivers/virt/geniezone/gzvm_vcpu.c      |   1 +
 drivers/virt/geniezone/gzvm_vm.c        |  18 ++
 include/linux/gzvm_drv.h                |  25 ++
 include/uapi/linux/gzvm.h               |  26 ++
 8 files changed, 483 insertions(+), 2 deletions(-)
 create mode 100644 drivers/virt/geniezone/gzvm_irqfd.c

diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index 7b423c1c4549..67c7864c3afc 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -45,6 +45,8 @@ enum {
 #define MT_HVC_GZVM_ENABLE_CAP		GZVM_HCALL_ID(GZVM_FUNC_ENABLE_CAP)
 #define MT_HVC_GZVM_INFORM_EXIT		GZVM_HCALL_ID(GZVM_FUNC_INFORM_EXIT)
 
+#define GIC_V3_NR_LRS			16
+
 /**
  * gzvm_hypcall_wrapper() - the wrapper for hvc calls
  * @a0: arguments passed in registers 0
@@ -75,6 +77,22 @@ static inline u16 get_vcpuid_from_tuple(unsigned int tuple)
 	return (u16)(tuple & 0xffff);
 }
 
+/**
+ * struct gzvm_vcpu_hwstate: Sync architecture state back to host for handling
+ * @nr_lrs: The available LRs(list registers) in Soc.
+ * @__pad: add an explicit '__u32 __pad;' in the middle to make it clear
+ *         what the actual layout is.
+ * @lr: The array of LRs(list registers).
+ *
+ * - Keep the same layout of hypervisor data struct.
+ * - Sync list registers back for acking virtual device interrupt status.
+ */
+struct gzvm_vcpu_hwstate {
+	__le32 nr_lrs;
+	__le32 __pad;
+	__le64 lr[GIC_V3_NR_LRS];
+};
+
 static inline unsigned int
 assemble_vm_vcpu_tuple(u16 vmid, u16 vcpuid)
 {
diff --git a/drivers/virt/geniezone/Makefile b/drivers/virt/geniezone/Makefile
index a630b919cda5..cebe5ad53f41 100644
--- a/drivers/virt/geniezone/Makefile
+++ b/drivers/virt/geniezone/Makefile
@@ -7,4 +7,5 @@
 GZVM_DIR ?= ../../../drivers/virt/geniezone
 
 gzvm-y := $(GZVM_DIR)/gzvm_main.o $(GZVM_DIR)/gzvm_vm.o \
-	  $(GZVM_DIR)/gzvm_mmu.o $(GZVM_DIR)/gzvm_vcpu.o
+	  $(GZVM_DIR)/gzvm_mmu.o $(GZVM_DIR)/gzvm_vcpu.o \
+	  $(GZVM_DIR)/gzvm_irqfd.o
diff --git a/drivers/virt/geniezone/gzvm_irqfd.c b/drivers/virt/geniezone/gzvm_irqfd.c
new file mode 100644
index 000000000000..fe77d074cf20
--- /dev/null
+++ b/drivers/virt/geniezone/gzvm_irqfd.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/eventfd.h>
+#include <linux/syscalls.h>
+#include <linux/gzvm_drv.h>
+#include "gzvm_common.h"
+
+struct gzvm_irq_ack_notifier {
+	struct hlist_node link;
+	unsigned int gsi;
+	void (*irq_acked)(struct gzvm_irq_ack_notifier *ian);
+};
+
+/**
+ * struct gzvm_kernel_irqfd: gzvm kernel irqfd descriptor.
+ * @gzvm: Pointer to struct gzvm.
+ * @wait: Wait queue entry.
+ * @gsi: Used for level IRQ fast-path.
+ * @eventfd: Used for setup/shutdown.
+ * @list: struct list_head.
+ * @pt: struct poll_table_struct.
+ * @shutdown: struct work_struct.
+ */
+struct gzvm_kernel_irqfd {
+	struct gzvm *gzvm;
+	wait_queue_entry_t wait;
+
+	int gsi;
+
+	struct eventfd_ctx *eventfd;
+	struct list_head list;
+	poll_table pt;
+	struct work_struct shutdown;
+};
+
+static struct workqueue_struct *irqfd_cleanup_wq;
+
+/**
+ * irqfd_set_irq(): irqfd to inject virtual interrupt.
+ * @gzvm: Pointer to gzvm.
+ * @irq: This is spi interrupt number (starts from 0 instead of 32).
+ * @level: irq triggered level.
+ */
+static void irqfd_set_irq(struct gzvm *gzvm, u32 irq, int level)
+{
+	if (level)
+		gzvm_irqchip_inject_irq(gzvm, 0, irq, level);
+}
+
+/**
+ * irqfd_shutdown() - Race-free decouple logic (ordering is critical).
+ * @work: Pointer to work_struct.
+ */
+static void irqfd_shutdown(struct work_struct *work)
+{
+	struct gzvm_kernel_irqfd *irqfd =
+		container_of(work, struct gzvm_kernel_irqfd, shutdown);
+	struct gzvm *gzvm = irqfd->gzvm;
+	u64 cnt;
+
+	/* Make sure irqfd has been initialized in assign path. */
+	synchronize_srcu(&gzvm->irq_srcu);
+
+	/*
+	 * Synchronize with the wait-queue and unhook ourselves to prevent
+	 * further events.
+	 */
+	eventfd_ctx_remove_wait_queue(irqfd->eventfd, &irqfd->wait, &cnt);
+
+	/*
+	 * It is now safe to release the object's resources
+	 */
+	eventfd_ctx_put(irqfd->eventfd);
+	kfree(irqfd);
+}
+
+/**
+ * irqfd_is_active() - Assumes gzvm->irqfds.lock is held.
+ * @irqfd: Pointer to gzvm_kernel_irqfd.
+ *
+ * Return:
+ * * true			- irqfd is active.
+ */
+static bool irqfd_is_active(struct gzvm_kernel_irqfd *irqfd)
+{
+	return list_empty(&irqfd->list) ? false : true;
+}
+
+/**
+ * irqfd_deactivate() - Mark the irqfd as inactive and schedule it for removal.
+ *			assumes gzvm->irqfds.lock is held.
+ * @irqfd: Pointer to gzvm_kernel_irqfd.
+ */
+static void irqfd_deactivate(struct gzvm_kernel_irqfd *irqfd)
+{
+	if (!irqfd_is_active(irqfd))
+		return;
+
+	list_del_init(&irqfd->list);
+
+	queue_work(irqfd_cleanup_wq, &irqfd->shutdown);
+}
+
+/**
+ * irqfd_wakeup() - Callback of irqfd wait queue, would be woken by writing to
+ *                  irqfd to do virtual interrupt injection.
+ * @wait: Pointer to wait_queue_entry_t.
+ * @mode: Unused.
+ * @sync: Unused.
+ * @key: Get flags about Epoll events.
+ *
+ * Return:
+ * * 0			- Success
+ */
+static int irqfd_wakeup(wait_queue_entry_t *wait, unsigned int mode, int sync,
+			void *key)
+{
+	struct gzvm_kernel_irqfd *irqfd =
+		container_of(wait, struct gzvm_kernel_irqfd, wait);
+	__poll_t flags = key_to_poll(key);
+	struct gzvm *gzvm = irqfd->gzvm;
+
+	if (flags & EPOLLIN) {
+		u64 cnt;
+
+		eventfd_ctx_do_read(irqfd->eventfd, &cnt);
+		/* gzvm's irq injection is not blocked, don't need workq */
+		irqfd_set_irq(gzvm, irqfd->gsi, 1);
+	}
+
+	if (flags & EPOLLHUP) {
+		/* The eventfd is closing, detach from GZVM */
+		unsigned long iflags;
+
+		spin_lock_irqsave(&gzvm->irqfds.lock, iflags);
+
+		/*
+		 * Do more check if someone deactivated the irqfd before
+		 * we could acquire the irqfds.lock.
+		 */
+		if (irqfd_is_active(irqfd))
+			irqfd_deactivate(irqfd);
+
+		spin_unlock_irqrestore(&gzvm->irqfds.lock, iflags);
+	}
+
+	return 0;
+}
+
+static void irqfd_ptable_queue_proc(struct file *file, wait_queue_head_t *wqh,
+				    poll_table *pt)
+{
+	struct gzvm_kernel_irqfd *irqfd =
+		container_of(pt, struct gzvm_kernel_irqfd, pt);
+	add_wait_queue_priority(wqh, &irqfd->wait);
+}
+
+static int gzvm_irqfd_assign(struct gzvm *gzvm, struct gzvm_irqfd *args)
+{
+	struct gzvm_kernel_irqfd *irqfd, *tmp;
+	struct fd f;
+	struct eventfd_ctx *eventfd = NULL;
+	int ret;
+	int idx;
+
+	irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL_ACCOUNT);
+	if (!irqfd)
+		return -ENOMEM;
+
+	irqfd->gzvm = gzvm;
+	irqfd->gsi = args->gsi;
+
+	INIT_LIST_HEAD(&irqfd->list);
+	INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
+
+	f = fdget(args->fd);
+	if (!f.file) {
+		ret = -EBADF;
+		goto out;
+	}
+
+	eventfd = eventfd_ctx_fileget(f.file);
+	if (IS_ERR(eventfd)) {
+		ret = PTR_ERR(eventfd);
+		goto fail;
+	}
+
+	irqfd->eventfd = eventfd;
+
+	/*
+	 * Install our own custom wake-up handling so we are notified via
+	 * a callback whenever someone signals the underlying eventfd
+	 */
+	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
+	init_poll_funcptr(&irqfd->pt, irqfd_ptable_queue_proc);
+
+	spin_lock_irq(&gzvm->irqfds.lock);
+
+	ret = 0;
+	list_for_each_entry(tmp, &gzvm->irqfds.items, list) {
+		if (irqfd->eventfd != tmp->eventfd)
+			continue;
+		/* This fd is used for another irq already. */
+		pr_err("already used: gsi=%d fd=%d\n", args->gsi, args->fd);
+		ret = -EBUSY;
+		spin_unlock_irq(&gzvm->irqfds.lock);
+		goto fail;
+	}
+
+	idx = srcu_read_lock(&gzvm->irq_srcu);
+
+	list_add_tail(&irqfd->list, &gzvm->irqfds.items);
+
+	spin_unlock_irq(&gzvm->irqfds.lock);
+
+	vfs_poll(f.file, &irqfd->pt);
+
+	srcu_read_unlock(&gzvm->irq_srcu, idx);
+
+	/*
+	 * do not drop the file until the irqfd is fully initialized, otherwise
+	 * we might race against the EPOLLHUP
+	 */
+	fdput(f);
+	return 0;
+
+fail:
+	if (eventfd && !IS_ERR(eventfd))
+		eventfd_ctx_put(eventfd);
+
+	fdput(f);
+
+out:
+	kfree(irqfd);
+	return ret;
+}
+
+static void gzvm_notify_acked_gsi(struct gzvm *gzvm, int gsi)
+{
+	struct gzvm_irq_ack_notifier *gian;
+
+	hlist_for_each_entry_srcu(gian, &gzvm->irq_ack_notifier_list,
+				  link, srcu_read_lock_held(&gzvm->irq_srcu))
+		if (gian->gsi == gsi)
+			gian->irq_acked(gian);
+}
+
+void gzvm_notify_acked_irq(struct gzvm *gzvm, unsigned int gsi)
+{
+	int idx;
+
+	idx = srcu_read_lock(&gzvm->irq_srcu);
+	gzvm_notify_acked_gsi(gzvm, gsi);
+	srcu_read_unlock(&gzvm->irq_srcu, idx);
+}
+
+/**
+ * gzvm_irqfd_deassign() - Shutdown any irqfd's that match fd+gsi.
+ * @gzvm: Pointer to gzvm.
+ * @args: Pointer to gzvm_irqfd.
+ *
+ * Return:
+ * * 0			- Success.
+ * * Negative value	- Failure.
+ */
+static int gzvm_irqfd_deassign(struct gzvm *gzvm, struct gzvm_irqfd *args)
+{
+	struct gzvm_kernel_irqfd *irqfd, *tmp;
+	struct eventfd_ctx *eventfd;
+
+	eventfd = eventfd_ctx_fdget(args->fd);
+	if (IS_ERR(eventfd))
+		return PTR_ERR(eventfd);
+
+	spin_lock_irq(&gzvm->irqfds.lock);
+
+	list_for_each_entry_safe(irqfd, tmp, &gzvm->irqfds.items, list) {
+		if (irqfd->eventfd == eventfd && irqfd->gsi == args->gsi)
+			irqfd_deactivate(irqfd);
+	}
+
+	spin_unlock_irq(&gzvm->irqfds.lock);
+	eventfd_ctx_put(eventfd);
+
+	/*
+	 * Block until we know all outstanding shutdown jobs have completed
+	 * so that we guarantee there will not be any more interrupts on this
+	 * gsi once this deassign function returns.
+	 */
+	flush_workqueue(irqfd_cleanup_wq);
+
+	return 0;
+}
+
+int gzvm_irqfd(struct gzvm *gzvm, struct gzvm_irqfd *args)
+{
+	for (int i = 0; i < ARRAY_SIZE(args->pad); i++) {
+		if (args->pad[i])
+			return -EINVAL;
+	}
+
+	if (args->flags &
+	    ~(GZVM_IRQFD_FLAG_DEASSIGN | GZVM_IRQFD_FLAG_RESAMPLE))
+		return -EINVAL;
+
+	if (args->flags & GZVM_IRQFD_FLAG_DEASSIGN)
+		return gzvm_irqfd_deassign(gzvm, args);
+
+	return gzvm_irqfd_assign(gzvm, args);
+}
+
+/**
+ * gzvm_vm_irqfd_init() - Initialize irqfd data structure per VM
+ *
+ * @gzvm: Pointer to struct gzvm.
+ *
+ * Return:
+ * * 0			- Success.
+ * * Negative		- Failure.
+ */
+int gzvm_vm_irqfd_init(struct gzvm *gzvm)
+{
+	mutex_init(&gzvm->irq_lock);
+
+	spin_lock_init(&gzvm->irqfds.lock);
+	INIT_LIST_HEAD(&gzvm->irqfds.items);
+	if (init_srcu_struct(&gzvm->irq_srcu))
+		return -EINVAL;
+	INIT_HLIST_HEAD(&gzvm->irq_ack_notifier_list);
+
+	return 0;
+}
+
+/**
+ * gzvm_vm_irqfd_release() - This function is called as the gzvm VM fd is being
+ *			  released. Shutdown all irqfds that still remain open.
+ * @gzvm: Pointer to gzvm.
+ */
+void gzvm_vm_irqfd_release(struct gzvm *gzvm)
+{
+	struct gzvm_kernel_irqfd *irqfd, *tmp;
+
+	spin_lock_irq(&gzvm->irqfds.lock);
+
+	list_for_each_entry_safe(irqfd, tmp, &gzvm->irqfds.items, list)
+		irqfd_deactivate(irqfd);
+
+	spin_unlock_irq(&gzvm->irqfds.lock);
+
+	/*
+	 * Block until we know all outstanding shutdown jobs have completed.
+	 */
+	flush_workqueue(irqfd_cleanup_wq);
+}
+
+/**
+ * gzvm_drv_irqfd_init() - Erase flushing work items when a VM exits.
+ *
+ * Return:
+ * * 0			- Success.
+ * * Negative		- Failure.
+ *
+ * Create a host-wide workqueue for issuing deferred shutdown requests
+ * aggregated from all vm* instances. We need our own isolated
+ * queue to ease flushing work items when a VM exits.
+ */
+int gzvm_drv_irqfd_init(void)
+{
+	irqfd_cleanup_wq = alloc_workqueue("gzvm-irqfd-cleanup", 0, 0);
+	if (!irqfd_cleanup_wq)
+		return -ENOMEM;
+
+	return 0;
+}
+
+void gzvm_drv_irqfd_exit(void)
+{
+	destroy_workqueue(irqfd_cleanup_wq);
+}
diff --git a/drivers/virt/geniezone/gzvm_main.c b/drivers/virt/geniezone/gzvm_main.c
index 30f6c3975026..4e5d1b83df4a 100644
--- a/drivers/virt/geniezone/gzvm_main.c
+++ b/drivers/virt/geniezone/gzvm_main.c
@@ -97,16 +97,26 @@ static struct miscdevice gzvm_dev = {
 
 static int gzvm_drv_probe(struct platform_device *pdev)
 {
+	int ret;
+
 	if (gzvm_arch_probe() != 0) {
 		dev_err(&pdev->dev, "Not found available conduit\n");
 		return -ENODEV;
 	}
 
-	return misc_register(&gzvm_dev);
+	ret = misc_register(&gzvm_dev);
+	if (ret)
+		return ret;
+
+	ret = gzvm_drv_irqfd_init();
+	if (ret)
+		return ret;
+	return 0;
 }
 
 static int gzvm_drv_remove(struct platform_device *pdev)
 {
+	gzvm_drv_irqfd_exit();
 	gzvm_destroy_all_vms();
 	misc_deregister(&gzvm_dev);
 	return 0;
diff --git a/drivers/virt/geniezone/gzvm_vcpu.c b/drivers/virt/geniezone/gzvm_vcpu.c
index 39c471d0d257..598f0ed2dbb5 100644
--- a/drivers/virt/geniezone/gzvm_vcpu.c
+++ b/drivers/virt/geniezone/gzvm_vcpu.c
@@ -228,6 +228,7 @@ int gzvm_vm_ioctl_create_vcpu(struct gzvm *gzvm, u32 cpuid)
 		ret = -ENOMEM;
 		goto free_vcpu;
 	}
+	vcpu->hwstate = (void *)vcpu->run + PAGE_SIZE;
 	vcpu->vcpuid = cpuid;
 	vcpu->gzvm = gzvm;
 	mutex_init(&vcpu->lock);
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index 8d6b7aebaf3a..2ab4391ff16a 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -213,6 +213,16 @@ static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 		ret = gzvm_vm_ioctl_create_device(gzvm, argp);
 		break;
 	}
+	case GZVM_IRQFD: {
+		struct gzvm_irqfd data;
+
+		if (copy_from_user(&data, argp, sizeof(data))) {
+			ret = -EFAULT;
+			goto out;
+		}
+		ret = gzvm_irqfd(gzvm, &data);
+		break;
+	}
 	case GZVM_ENABLE_CAP: {
 		struct gzvm_enable_cap cap;
 
@@ -236,6 +246,7 @@ static void gzvm_destroy_vm(struct gzvm *gzvm)
 
 	mutex_lock(&gzvm->lock);
 
+	gzvm_vm_irqfd_release(gzvm);
 	gzvm_destroy_vcpus(gzvm);
 	gzvm_arch_destroy_vm(gzvm->vm_id);
 
@@ -281,6 +292,13 @@ static struct gzvm *gzvm_create_vm(unsigned long vm_type)
 	gzvm->mm = current->mm;
 	mutex_init(&gzvm->lock);
 
+	ret = gzvm_vm_irqfd_init(gzvm);
+	if (ret) {
+		pr_err("Failed to initialize irqfd\n");
+		kfree(gzvm);
+		return ERR_PTR(ret);
+	}
+
 	mutex_lock(&gzvm_list_lock);
 	list_add(&gzvm->vm_list, &gzvm_list);
 	mutex_unlock(&gzvm_list_lock);
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index 805a866acecc..676e6b5714e8 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -10,6 +10,7 @@
 #include <linux/mm.h>
 #include <linux/mutex.h>
 #include <linux/gzvm.h>
+#include <linux/srcu.h>
 
 /*
  * For the normal physical address, the highest 12 bits should be zero, so we
@@ -30,6 +31,7 @@
 #define ERR_NOT_SUPPORTED       (-24)
 #define ERR_NOT_IMPLEMENTED     (-27)
 #define ERR_FAULT               (-40)
+#define GZVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID       1
 
 /*
  * The following data structures are for data transferring between driver and
@@ -73,6 +75,7 @@ struct gzvm_vcpu {
 	/* lock of vcpu*/
 	struct mutex lock;
 	struct gzvm_vcpu_run *run;
+	struct gzvm_vcpu_hwstate *hwstate;
 };
 
 struct gzvm {
@@ -82,8 +85,23 @@ struct gzvm {
 	struct gzvm_memslot memslot[GZVM_MAX_MEM_REGION];
 	/* lock for list_add*/
 	struct mutex lock;
+
+	struct {
+		/* lock for irqfds list operation */
+		spinlock_t        lock;
+		struct list_head  items;
+		struct list_head  resampler_list;
+		/* lock for irqfds resampler */
+		struct mutex      resampler_lock;
+	} irqfds;
+
 	struct list_head vm_list;
 	u16 vm_id;
+
+	struct hlist_head irq_ack_notifier_list;
+	struct srcu_struct irq_srcu;
+	/* lock for irq injection */
+	struct mutex irq_lock;
 };
 
 long gzvm_dev_ioctl_check_extension(struct gzvm *gzvm, unsigned long args);
@@ -124,4 +142,11 @@ int gzvm_arch_create_device(u16 vm_id, struct gzvm_create_device *gzvm_dev);
 int gzvm_arch_inject_irq(struct gzvm *gzvm, unsigned int vcpu_idx,
 			 u32 irq, bool level);
 
+void gzvm_notify_acked_irq(struct gzvm *gzvm, unsigned int gsi);
+int gzvm_irqfd(struct gzvm *gzvm, struct gzvm_irqfd *args);
+int gzvm_drv_irqfd_init(void);
+void gzvm_drv_irqfd_exit(void);
+int gzvm_vm_irqfd_init(struct gzvm *gzvm);
+void gzvm_vm_irqfd_release(struct gzvm *gzvm);
+
 #endif /* __GZVM_DRV_H__ */
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index a1f6acdc4055..cb02f278972f 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -309,4 +309,30 @@ struct gzvm_one_reg {
 
 #define GZVM_REG_GENERIC	   0x0000000000000000ULL
 
+#define GZVM_IRQFD_FLAG_DEASSIGN	BIT(0)
+/*
+ * GZVM_IRQFD_FLAG_RESAMPLE indicates resamplefd is valid and specifies
+ * the irqfd to operate in resampling mode for level triggered interrupt
+ * emulation.
+ */
+#define GZVM_IRQFD_FLAG_RESAMPLE	BIT(1)
+
+/**
+ * struct gzvm_irqfd: gzvm irqfd descriptor
+ * @fd: File descriptor.
+ * @gsi: Used for level IRQ fast-path.
+ * @flags: FLAG_DEASSIGN or FLAG_RESAMPLE.
+ * @resamplefd: The file descriptor of the resampler.
+ * @pad: Reserved for future-proof.
+ */
+struct gzvm_irqfd {
+	__u32 fd;
+	__u32 gsi;
+	__u32 flags;
+	__u32 resamplefd;
+	__u8  pad[16];
+};
+
+#define GZVM_IRQFD	_IOW(GZVM_IOC_MAGIC, 0x76, struct gzvm_irqfd)
+
 #endif /* __GZVM_H__ */
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:34 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:34 +0800
Subject: [PATCH v8 07/20] virt: geniezone: Optimize performance of protected VM memory
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-8-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

The memory protection mechanism performs better with batch operations on
memory pages. To leverage this, we pre-allocate memory for VMs that are
set to protected mode. As a result, the memory protection mechanism can
proactively protect the pre-allocated memory in advance through batch
operations, leading to improved performance during VM booting.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/vm.c         | 146 ++++++++++++++++++++++++++++++
 drivers/virt/geniezone/Makefile   |   3 +-
 drivers/virt/geniezone/gzvm_mmu.c | 108 ++++++++++++++++++++++
 3 files changed, 256 insertions(+), 1 deletion(-)
 create mode 100644 drivers/virt/geniezone/gzvm_mmu.c

diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index 02f94c86fbf1..e669a63ccac3 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -156,6 +156,122 @@ static int gzvm_vm_ioctl_get_pvmfw_size(struct gzvm *gzvm,
 	return 0;
 }
 
+/**
+ * fill_constituents() - Populate pa to buffer until full
+ * @consti: Pointer to struct mem_region_addr_range.
+ * @consti_cnt: Constituent count.
+ * @max_nr_consti: Maximum number of constituent count.
+ * @gfn: Guest frame number.
+ * @total_pages: Total page numbers.
+ * @slot: Pointer to struct gzvm_memslot.
+ *
+ * Return: how many pages we've fill in, negative if error
+ */
+static int fill_constituents(struct mem_region_addr_range *consti,
+			     int *consti_cnt, int max_nr_consti, u64 gfn,
+			     u32 total_pages, struct gzvm_memslot *slot)
+{
+	u64 pfn, prev_pfn, gfn_end;
+	int nr_pages = 1;
+	int i = 0;
+
+	if (unlikely(total_pages == 0))
+		return -EINVAL;
+	gfn_end = gfn + total_pages;
+
+	/* entry 0 */
+	if (gzvm_gfn_to_pfn_memslot(slot, gfn, &pfn) != 0)
+		return -EFAULT;
+	consti[0].address = PFN_PHYS(pfn);
+	consti[0].pg_cnt = 1;
+	gfn++;
+	prev_pfn = pfn;
+
+	while (i < max_nr_consti && gfn < gfn_end) {
+		if (gzvm_gfn_to_pfn_memslot(slot, gfn, &pfn) != 0)
+			return -EFAULT;
+		if (pfn == (prev_pfn + 1)) {
+			consti[i].pg_cnt++;
+		} else {
+			i++;
+			if (i >= max_nr_consti)
+				break;
+			consti[i].address = PFN_PHYS(pfn);
+			consti[i].pg_cnt = 1;
+		}
+		prev_pfn = pfn;
+		gfn++;
+		nr_pages++;
+	}
+	if (i != max_nr_consti)
+		i++;
+	*consti_cnt = i;
+
+	return nr_pages;
+}
+
+/**
+ * populate_mem_region() - Iterate all mem slot and populate pa to buffer until it's full
+ * @gzvm: Pointer to struct gzvm.
+ *
+ * Return: 0 if it is successful, negative if error
+ */
+static int populate_mem_region(struct gzvm *gzvm)
+{
+	int slot_cnt = 0;
+
+	while (slot_cnt < GZVM_MAX_MEM_REGION && gzvm->memslot[slot_cnt].npages != 0) {
+		struct gzvm_memslot *memslot = &gzvm->memslot[slot_cnt];
+		struct gzvm_memory_region_ranges *region;
+		int max_nr_consti, remain_pages;
+		u64 gfn, gfn_end;
+		u32 buf_size;
+
+		buf_size = PAGE_SIZE * 2;
+		region = alloc_pages_exact(buf_size, GFP_KERNEL);
+		if (!region)
+			return -ENOMEM;
+
+		max_nr_consti = (buf_size - sizeof(*region)) /
+				sizeof(struct mem_region_addr_range);
+
+		region->slot = memslot->slot_id;
+		remain_pages = memslot->npages;
+		gfn = memslot->base_gfn;
+		gfn_end = gfn + remain_pages;
+
+		while (gfn < gfn_end) {
+			int nr_pages;
+
+			nr_pages = fill_constituents(region->constituents,
+						     &region->constituent_cnt,
+						     max_nr_consti, gfn,
+						     remain_pages, memslot);
+
+			if (nr_pages < 0) {
+				pr_err("Failed to fill constituents\n");
+				free_pages_exact(region, buf_size);
+				return -EFAULT;
+			}
+
+			region->gpa = PFN_PHYS(gfn);
+			region->total_pages = nr_pages;
+			remain_pages -= nr_pages;
+			gfn += nr_pages;
+
+			if (gzvm_arch_set_memregion(gzvm->vm_id, buf_size,
+						    virt_to_phys(region))) {
+				pr_err("Failed to register memregion to hypervisor\n");
+				free_pages_exact(region, buf_size);
+				return -EFAULT;
+			}
+		}
+		free_pages_exact(region, buf_size);
+		++slot_cnt;
+	}
+	return 0;
+}
+
 /**
  * gzvm_vm_ioctl_cap_pvm() - Proceed GZVM_CAP_PROTECTED_VM's subcommands
  * @gzvm: Pointer to struct gzvm.
@@ -177,6 +293,11 @@ static int gzvm_vm_ioctl_cap_pvm(struct gzvm *gzvm,
 	case GZVM_CAP_PVM_SET_PVMFW_GPA:
 		fallthrough;
 	case GZVM_CAP_PVM_SET_PROTECTED_VM:
+		/*
+		 * To improve performance for protected VM, we have to populate VM's memory
+		 * before VM booting
+		 */
+		populate_mem_region(gzvm);
 		ret = gzvm_vm_arch_enable_cap(gzvm, cap, &res);
 		return ret;
 	case GZVM_CAP_PVM_GET_PVMFW_SIZE:
@@ -205,3 +326,28 @@ int gzvm_vm_ioctl_arch_enable_cap(struct gzvm *gzvm,
 
 	return -EINVAL;
 }
+
+/**
+ * gzvm_hva_to_pa_arch() - converts hva to pa with arch-specific way
+ * @hva: Host virtual address.
+ *
+ * Return: GZVM_PA_ERR_BAD for translation error
+ */
+u64 gzvm_hva_to_pa_arch(u64 hva)
+{
+	unsigned long flags;
+	u64 par;
+
+	local_irq_save(flags);
+	asm volatile("at s1e1r, %0" :: "r" (hva));
+	isb();
+	par = read_sysreg_par();
+	local_irq_restore(flags);
+
+	if (par & SYS_PAR_EL1_F)
+		return GZVM_PA_ERR_BAD;
+	par = par & PAR_PA47_MASK;
+	if (!par)
+		return GZVM_PA_ERR_BAD;
+	return par;
+}
diff --git a/drivers/virt/geniezone/Makefile b/drivers/virt/geniezone/Makefile
index 25614ea3dea2..59fc4510a843 100644
--- a/drivers/virt/geniezone/Makefile
+++ b/drivers/virt/geniezone/Makefile
@@ -6,4 +6,5 @@
 
 GZVM_DIR ?= ../../../drivers/virt/geniezone
 
-gzvm-y := $(GZVM_DIR)/gzvm_main.o $(GZVM_DIR)/gzvm_vm.o
+gzvm-y := $(GZVM_DIR)/gzvm_main.o $(GZVM_DIR)/gzvm_vm.o \
+	  $(GZVM_DIR)/gzvm_mmu.o
diff --git a/drivers/virt/geniezone/gzvm_mmu.c b/drivers/virt/geniezone/gzvm_mmu.c
new file mode 100644
index 000000000000..f24fa7e6d975
--- /dev/null
+++ b/drivers/virt/geniezone/gzvm_mmu.c
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/gzvm_drv.h>
+
+/**
+ * hva_to_pa_fast() - converts hva to pa in generic fast way
+ * @hva: Host virtual address.
+ *
+ * Return: GZVM_PA_ERR_BAD for translation error
+ */
+u64 hva_to_pa_fast(u64 hva)
+{
+	struct page *page[1];
+	u64 pfn;
+
+	if (get_user_page_fast_only(hva, 0, page)) {
+		pfn = page_to_phys(page[0]);
+		put_page(page[0]);
+		return pfn;
+	}
+	return GZVM_PA_ERR_BAD;
+}
+
+/**
+ * hva_to_pa_slow() - converts hva to pa in a slow way
+ * @hva: Host virtual address
+ *
+ * This function converts HVA to PA in a slow way because the target hva is not
+ * yet allocated and mapped in the host stage1 page table, we cannot find it
+ * directly from current page table.
+ * Thus, we have to allocate it and this operation is much slower than directly
+ * find via current page table.
+ *
+ * Context: This function may sleep
+ * Return: PA or GZVM_PA_ERR_BAD for translation error
+ */
+u64 hva_to_pa_slow(u64 hva)
+{
+	struct page *page = NULL;
+	u64 pfn = 0;
+	int npages;
+
+	npages = get_user_pages_unlocked(hva, 1, &page, 0);
+	if (npages != 1)
+		return GZVM_PA_ERR_BAD;
+
+	if (page) {
+		pfn = page_to_phys(page);
+		put_page(page);
+		return pfn;
+	}
+
+	return GZVM_PA_ERR_BAD;
+}
+
+static u64 __gzvm_gfn_to_pfn_memslot(struct gzvm_memslot *memslot, u64 gfn)
+{
+	u64 hva, pa;
+
+	hva = gzvm_gfn_to_hva_memslot(memslot, gfn);
+
+	pa = gzvm_hva_to_pa_arch(hva);
+	if (pa != GZVM_PA_ERR_BAD)
+		return PHYS_PFN(pa);
+
+	pa = hva_to_pa_fast(hva);
+	if (pa != GZVM_PA_ERR_BAD)
+		return PHYS_PFN(pa);
+
+	pa = hva_to_pa_slow(hva);
+	if (pa != GZVM_PA_ERR_BAD)
+		return PHYS_PFN(pa);
+
+	return GZVM_PA_ERR_BAD;
+}
+
+/**
+ * gzvm_gfn_to_pfn_memslot() - Translate gfn (guest ipa) to pfn (host pa),
+ *			       result is in @pfn
+ * @memslot: Pointer to struct gzvm_memslot.
+ * @gfn: Guest frame number.
+ * @pfn: Host page frame number.
+ *
+ * Return:
+ * * 0			- Succeed
+ * * -EFAULT		- Failed to convert
+ */
+int gzvm_gfn_to_pfn_memslot(struct gzvm_memslot *memslot, u64 gfn,
+			    u64 *pfn)
+{
+	u64 __pfn;
+
+	if (!memslot)
+		return -EFAULT;
+
+	__pfn = __gzvm_gfn_to_pfn_memslot(memslot, gfn);
+	if (__pfn == GZVM_PA_ERR_BAD) {
+		*pfn = 0;
+		return -EFAULT;
+	}
+
+	*pfn = __pfn;
+
+	return 0;
+}
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:42 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:42 +0800
Subject: [PATCH v8 15/20] virt: geniezone: Add block-based demand paging support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-16-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

To balance memory usage and performance, GenieZone supports larger
granularity demand paging, called block-based demand paging.
Gzvm driver uses enable_cap to query the hypervisor if it supports
block-based demand paging and the given granularity or not. Meanwhile,
the gzvm driver allocates a shared buffer for storing the physical
pages later.

If the hypervisor supports, every time the gzvm driver handles guest
page faults, it allocates more memory in advance (default: 2MB) for
demand paging. And fills those physical pages into the allocated shared
memory, then calls the hypervisor to map to guest's memory.

The physical pages allocated for block-based demand paging is not
necessary to be contiguous because in many cases, 2MB block is not
followed. 1st, the memory is allocated because of VMM's page fault
(VMM loads kernel image to guest memory before running). In this case,
the page is allocated by the host kernel and using PAGE_SIZE. 2nd is
that guest may return memory to host via ballooning and that is still
4KB (or PAGE_SIZE) granularity. Therefore, we do not have to allocate
physically contiguous 2MB pages.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/gzvm_arch_common.h |  2 +
 arch/arm64/geniezone/vm.c               | 19 ++++++++--
 drivers/virt/geniezone/gzvm_mmu.c       | 44 +++++++++++++++++++++-
 drivers/virt/geniezone/gzvm_vm.c        | 49 +++++++++++++++++++++++++
 include/linux/gzvm_drv.h                | 16 ++++++++
 include/uapi/linux/gzvm.h               |  2 +
 6 files changed, 128 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index 1f0c7a3fede8..07c5e2df7a74 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -25,6 +25,7 @@ enum {
 	GZVM_FUNC_MEMREGION_PURPOSE = 15,
 	GZVM_FUNC_SET_DTB_CONFIG = 16,
 	GZVM_FUNC_MAP_GUEST = 17,
+	GZVM_FUNC_MAP_GUEST_BLOCK = 18,
 	NR_GZVM_FUNC,
 };
 
@@ -50,6 +51,7 @@ enum {
 #define MT_HVC_GZVM_MEMREGION_PURPOSE	GZVM_HCALL_ID(GZVM_FUNC_MEMREGION_PURPOSE)
 #define MT_HVC_GZVM_SET_DTB_CONFIG	GZVM_HCALL_ID(GZVM_FUNC_SET_DTB_CONFIG)
 #define MT_HVC_GZVM_MAP_GUEST		GZVM_HCALL_ID(GZVM_FUNC_MAP_GUEST)
+#define MT_HVC_GZVM_MAP_GUEST_BLOCK	GZVM_HCALL_ID(GZVM_FUNC_MAP_GUEST_BLOCK)
 
 #define GIC_V3_NR_LRS			16
 
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index ecc43bcc2705..e709872e3dfe 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -325,10 +325,11 @@ static int gzvm_vm_ioctl_cap_pvm(struct gzvm *gzvm,
 		fallthrough;
 	case GZVM_CAP_PVM_SET_PROTECTED_VM:
 		/*
-		 * To improve performance for protected VM, we have to populate VM's memory
-		 * before VM booting
+		 * If the hypervisor doesn't support block-based demand paging, we
+		 * populate memory in advance to improve performance for protected VM.
 		 */
-		populate_mem_region(gzvm);
+		if (gzvm->demand_page_gran == PAGE_SIZE)
+			populate_mem_region(gzvm);
 		ret = gzvm_vm_arch_enable_cap(gzvm, cap, &res);
 		return ret;
 	case GZVM_CAP_PVM_GET_PVMFW_SIZE:
@@ -345,12 +346,16 @@ int gzvm_vm_ioctl_arch_enable_cap(struct gzvm *gzvm,
 				  struct gzvm_enable_cap *cap,
 				  void __user *argp)
 {
+	struct arm_smccc_res res = {0};
 	int ret;
 
 	switch (cap->cap) {
 	case GZVM_CAP_PROTECTED_VM:
 		ret = gzvm_vm_ioctl_cap_pvm(gzvm, cap, argp);
 		return ret;
+	case GZVM_CAP_BLOCK_BASED_DEMAND_PAGING:
+		ret = gzvm_vm_arch_enable_cap(gzvm, cap, &res);
+		return ret;
 	default:
 		break;
 	}
@@ -391,3 +396,11 @@ int gzvm_arch_map_guest(u16 vm_id, int memslot_id, u64 pfn, u64 gfn,
 	return gzvm_hypcall_wrapper(MT_HVC_GZVM_MAP_GUEST, vm_id, memslot_id,
 				    pfn, gfn, nr_pages, 0, 0, &res);
 }
+
+int gzvm_arch_map_guest_block(u16 vm_id, int memslot_id, u64 gfn, u64 nr_pages)
+{
+	struct arm_smccc_res res;
+
+	return gzvm_hypcall_wrapper(MT_HVC_GZVM_MAP_GUEST_BLOCK, vm_id,
+				    memslot_id, gfn, nr_pages, 0, 0, 0, &res);
+}
diff --git a/drivers/virt/geniezone/gzvm_mmu.c b/drivers/virt/geniezone/gzvm_mmu.c
index e6415baa064d..1f8471509be2 100644
--- a/drivers/virt/geniezone/gzvm_mmu.c
+++ b/drivers/virt/geniezone/gzvm_mmu.c
@@ -107,6 +107,45 @@ int gzvm_gfn_to_pfn_memslot(struct gzvm_memslot *memslot, u64 gfn,
 	return 0;
 }
 
+static int handle_block_demand_page(struct gzvm *vm, int memslot_id, u64 gfn)
+{
+	u64 pfn, __gfn;
+	int ret, i;
+
+	u32 nr_entries = GZVM_BLOCK_BASED_DEMAND_PAGE_SIZE / PAGE_SIZE;
+	struct gzvm_memslot *memslot = &vm->memslot[memslot_id];
+	u64 start_gfn = ALIGN_DOWN(gfn, nr_entries);
+	u32 total_pages = memslot->npages;
+	u64 base_gfn = memslot->base_gfn;
+
+	/* if the demand region is less than a block, adjust the nr_entries */
+	if (start_gfn + nr_entries > base_gfn + total_pages)
+		nr_entries = base_gfn + total_pages - start_gfn;
+
+	mutex_lock(&vm->demand_paging_lock);
+	for (i = 0, __gfn = start_gfn; i < nr_entries; i++, __gfn++) {
+		ret = gzvm_gfn_to_pfn_memslot(&vm->memslot[memslot_id], __gfn,
+					      &pfn);
+		if (unlikely(ret)) {
+			ret = -ERR_FAULT;
+			goto err_unlock;
+		}
+		vm->demand_page_buffer[i] = pfn;
+	}
+
+	ret = gzvm_arch_map_guest_block(vm->vm_id, memslot_id, start_gfn,
+					nr_entries);
+	if (unlikely(ret)) {
+		ret = -EFAULT;
+		goto err_unlock;
+	}
+
+err_unlock:
+	mutex_unlock(&vm->demand_paging_lock);
+
+	return ret;
+}
+
 static int handle_single_demand_page(struct gzvm *vm, int memslot_id, u64 gfn)
 {
 	int ret;
@@ -143,5 +182,8 @@ int gzvm_handle_page_fault(struct gzvm_vcpu *vcpu)
 	if (unlikely(memslot_id < 0))
 		return -EFAULT;
 
-	return handle_single_demand_page(vm, memslot_id, gfn);
+	if (vm->demand_page_gran == PAGE_SIZE)
+		return handle_single_demand_page(vm, memslot_id, gfn);
+	else
+		return handle_block_demand_page(vm, memslot_id, gfn);
 }
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index 9f7e44521de5..485d1e2097aa 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -294,6 +294,8 @@ static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 
 static void gzvm_destroy_vm(struct gzvm *gzvm)
 {
+	size_t allocated_size;
+
 	pr_debug("VM-%u is going to be destroyed\n", gzvm->vm_id);
 
 	mutex_lock(&gzvm->lock);
@@ -306,6 +308,11 @@ static void gzvm_destroy_vm(struct gzvm *gzvm)
 	list_del(&gzvm->vm_list);
 	mutex_unlock(&gzvm_list_lock);
 
+	if (gzvm->demand_page_buffer) {
+		allocated_size = GZVM_BLOCK_BASED_DEMAND_PAGE_SIZE / PAGE_SIZE * sizeof(u64);
+		free_pages_exact(gzvm->demand_page_buffer, allocated_size);
+	}
+
 	mutex_unlock(&gzvm->lock);
 
 	kfree(gzvm);
@@ -325,6 +332,46 @@ static const struct file_operations gzvm_vm_fops = {
 	.llseek		= noop_llseek,
 };
 
+/**
+ * setup_vm_demand_paging - Query hypervisor suitable demand page size and set
+ * @vm: gzvm instance for setting up demand page size
+ *
+ * Return: void
+ */
+static void setup_vm_demand_paging(struct gzvm *vm)
+{
+	u32 buf_size = GZVM_BLOCK_BASED_DEMAND_PAGE_SIZE / PAGE_SIZE * sizeof(u64);
+	struct gzvm_enable_cap cap = {0};
+	void *buffer;
+	int ret;
+
+	mutex_init(&vm->demand_paging_lock);
+	buffer = alloc_pages_exact(buf_size, GFP_KERNEL);
+	if (!buffer) {
+		/* Fall back to use default page size for demand paging */
+		vm->demand_page_gran = PAGE_SIZE;
+		vm->demand_page_buffer = NULL;
+		return;
+	}
+
+	cap.cap = GZVM_CAP_BLOCK_BASED_DEMAND_PAGING;
+	cap.args[0] = GZVM_BLOCK_BASED_DEMAND_PAGE_SIZE;
+	cap.args[1] = (__u64)virt_to_phys(buffer);
+	/* demand_page_buffer is freed when destroy VM */
+	vm->demand_page_buffer = buffer;
+
+	ret = gzvm_vm_ioctl_enable_cap(vm, &cap, NULL);
+	if (ret == 0) {
+		vm->demand_page_gran = GZVM_BLOCK_BASED_DEMAND_PAGE_SIZE;
+		/* freed when destroy vm */
+		vm->demand_page_buffer = buffer;
+	} else {
+		vm->demand_page_gran = PAGE_SIZE;
+		vm->demand_page_buffer = NULL;
+		free_pages_exact(buffer, buf_size);
+	}
+}
+
 static struct gzvm *gzvm_create_vm(unsigned long vm_type)
 {
 	int ret;
@@ -358,6 +405,8 @@ static struct gzvm *gzvm_create_vm(unsigned long vm_type)
 		return ERR_PTR(ret);
 	}
 
+	setup_vm_demand_paging(gzvm);
+
 	mutex_lock(&gzvm_list_lock);
 	list_add(&gzvm->vm_list, &gzvm_list);
 	mutex_unlock(&gzvm_list_lock);
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index b9e60fe5dcde..0a8b21e1ed1a 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -44,6 +44,8 @@
 
 #define GZVM_VCPU_RUN_MAP_SIZE		(PAGE_SIZE * 2)
 
+#define GZVM_BLOCK_BASED_DEMAND_PAGE_SIZE	(2 * 1024 * 1024) /* 2MB */
+
 /* struct mem_region_addr_range - Identical to ffa memory constituent */
 struct mem_region_addr_range {
 	/* the base IPA of the constituent memory region, aligned to 4 kiB */
@@ -106,6 +108,19 @@ struct gzvm {
 	struct srcu_struct irq_srcu;
 	/* lock for irq injection */
 	struct mutex irq_lock;
+
+	/*
+	 * demand page granularity: how much memory we allocate for VM in a
+	 * single page fault
+	 */
+	u32 demand_page_gran;
+	/* the mailbox for transferring large portion pages */
+	u64 *demand_page_buffer;
+	/*
+	 * lock for preventing multiple cpu using the same demand page mailbox
+	 * at the same time
+	 */
+	struct mutex  demand_paging_lock;
 };
 
 long gzvm_dev_ioctl_check_extension(struct gzvm *gzvm, unsigned long args);
@@ -126,6 +141,7 @@ int gzvm_arch_create_vm(unsigned long vm_type);
 int gzvm_arch_destroy_vm(u16 vm_id);
 int gzvm_arch_map_guest(u16 vm_id, int memslot_id, u64 pfn, u64 gfn,
 			u64 nr_pages);
+int gzvm_arch_map_guest_block(u16 vm_id, int memslot_id, u64 gfn, u64 nr_pages);
 int gzvm_vm_ioctl_arch_enable_cap(struct gzvm *gzvm,
 				  struct gzvm_enable_cap *cap,
 				  void __user *argp);
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index 1f134c55ac2a..f858b04bf7b9 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -18,6 +18,8 @@
 
 #define GZVM_CAP_VM_GPA_SIZE	0xa5
 #define GZVM_CAP_PROTECTED_VM	0xffbadab1
+/* query hypervisor supported block-based demand page */
+#define GZVM_CAP_BLOCK_BASED_DEMAND_PAGING	0x9201
 
 /* sub-commands put in args[0] for GZVM_CAP_PROTECTED_VM */
 #define GZVM_CAP_PVM_SET_PVMFW_GPA		0
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:35 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:35 +0800
Subject: [PATCH v8 08/20] virt: geniezone: Add vcpu support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-9-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

VMM use this interface to create vcpu instance which is a fd, and this
fd will be for any vcpu operations, such as setting vcpu registers and
accepts the most important ioctl GZVM_VCPU_RUN which requests GenieZone
hypervisor to do context switch to execute VM's vcpu context.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: kevenny hsieh <kevenny.hsieh at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/Makefile           |   2 +-
 arch/arm64/geniezone/gzvm_arch_common.h |  30 +++
 arch/arm64/geniezone/vcpu.c             |  80 ++++++++
 arch/arm64/geniezone/vm.c               |  12 ++
 drivers/virt/geniezone/Makefile         |   2 +-
 drivers/virt/geniezone/gzvm_vcpu.c      | 251 ++++++++++++++++++++++++
 drivers/virt/geniezone/gzvm_vm.c        |   5 +
 include/linux/gzvm_drv.h                |  24 +++
 include/uapi/linux/gzvm.h               | 164 ++++++++++++++++
 9 files changed, 568 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/geniezone/vcpu.c
 create mode 100644 drivers/virt/geniezone/gzvm_vcpu.c

diff --git a/arch/arm64/geniezone/Makefile b/arch/arm64/geniezone/Makefile
index 2957898cdd05..69b0a4abeab0 100644
--- a/arch/arm64/geniezone/Makefile
+++ b/arch/arm64/geniezone/Makefile
@@ -4,6 +4,6 @@
 #
 include $(srctree)/drivers/virt/geniezone/Makefile
 
-gzvm-y += vm.o
+gzvm-y += vm.o vcpu.o
 
 obj-$(CONFIG_MTK_GZVM) += gzvm.o
diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index 383af0829f11..684c35e2d9bc 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -11,9 +11,15 @@
 enum {
 	GZVM_FUNC_CREATE_VM = 0,
 	GZVM_FUNC_DESTROY_VM = 1,
+	GZVM_FUNC_CREATE_VCPU = 2,
+	GZVM_FUNC_DESTROY_VCPU = 3,
 	GZVM_FUNC_SET_MEMREGION = 4,
+	GZVM_FUNC_RUN = 5,
+	GZVM_FUNC_GET_ONE_REG = 8,
+	GZVM_FUNC_SET_ONE_REG = 9,
 	GZVM_FUNC_PROBE = 12,
 	GZVM_FUNC_ENABLE_CAP = 13,
+	GZVM_FUNC_INFORM_EXIT = 14,
 	NR_GZVM_FUNC,
 };
 
@@ -25,9 +31,15 @@ enum {
 
 #define MT_HVC_GZVM_CREATE_VM		GZVM_HCALL_ID(GZVM_FUNC_CREATE_VM)
 #define MT_HVC_GZVM_DESTROY_VM		GZVM_HCALL_ID(GZVM_FUNC_DESTROY_VM)
+#define MT_HVC_GZVM_CREATE_VCPU		GZVM_HCALL_ID(GZVM_FUNC_CREATE_VCPU)
+#define MT_HVC_GZVM_DESTROY_VCPU	GZVM_HCALL_ID(GZVM_FUNC_DESTROY_VCPU)
 #define MT_HVC_GZVM_SET_MEMREGION	GZVM_HCALL_ID(GZVM_FUNC_SET_MEMREGION)
+#define MT_HVC_GZVM_RUN			GZVM_HCALL_ID(GZVM_FUNC_RUN)
+#define MT_HVC_GZVM_GET_ONE_REG		GZVM_HCALL_ID(GZVM_FUNC_GET_ONE_REG)
+#define MT_HVC_GZVM_SET_ONE_REG		GZVM_HCALL_ID(GZVM_FUNC_SET_ONE_REG)
 #define MT_HVC_GZVM_PROBE		GZVM_HCALL_ID(GZVM_FUNC_PROBE)
 #define MT_HVC_GZVM_ENABLE_CAP		GZVM_HCALL_ID(GZVM_FUNC_ENABLE_CAP)
+#define MT_HVC_GZVM_INFORM_EXIT		GZVM_HCALL_ID(GZVM_FUNC_INFORM_EXIT)
 
 /**
  * gzvm_hypcall_wrapper() - the wrapper for hvc calls
@@ -54,4 +66,22 @@ static inline u16 get_vmid_from_tuple(unsigned int tuple)
 	return (u16)(tuple >> 16);
 }
 
+static inline u16 get_vcpuid_from_tuple(unsigned int tuple)
+{
+	return (u16)(tuple & 0xffff);
+}
+
+static inline unsigned int
+assemble_vm_vcpu_tuple(u16 vmid, u16 vcpuid)
+{
+	return ((unsigned int)vmid << 16 | vcpuid);
+}
+
+static inline void
+disassemble_vm_vcpu_tuple(unsigned int tuple, u16 *vmid, u16 *vcpuid)
+{
+	*vmid = get_vmid_from_tuple(tuple);
+	*vcpuid = get_vcpuid_from_tuple(tuple);
+}
+
 #endif /* __GZVM_ARCH_COMMON_H__ */
diff --git a/arch/arm64/geniezone/vcpu.c b/arch/arm64/geniezone/vcpu.c
new file mode 100644
index 000000000000..f6670bd77ad6
--- /dev/null
+++ b/arch/arm64/geniezone/vcpu.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/err.h>
+#include <linux/uaccess.h>
+
+#include <linux/gzvm.h>
+#include <linux/gzvm_drv.h>
+#include "gzvm_arch_common.h"
+
+int gzvm_arch_vcpu_update_one_reg(struct gzvm_vcpu *vcpu, __u64 reg_id,
+				  bool is_write, __u64 *data)
+{
+	struct arm_smccc_res res;
+	unsigned long a1;
+	int ret;
+
+	a1 = assemble_vm_vcpu_tuple(vcpu->gzvm->vm_id, vcpu->vcpuid);
+	if (!is_write) {
+		ret = gzvm_hypcall_wrapper(MT_HVC_GZVM_GET_ONE_REG,
+					   a1, reg_id, 0, 0, 0, 0, 0, &res);
+		if (ret == 0)
+			*data = res.a1;
+	} else {
+		ret = gzvm_hypcall_wrapper(MT_HVC_GZVM_SET_ONE_REG,
+					   a1, reg_id, *data, 0, 0, 0, 0, &res);
+	}
+
+	return ret;
+}
+
+int gzvm_arch_vcpu_run(struct gzvm_vcpu *vcpu, __u64 *exit_reason)
+{
+	struct arm_smccc_res res;
+	unsigned long a1;
+	int ret;
+
+	a1 = assemble_vm_vcpu_tuple(vcpu->gzvm->vm_id, vcpu->vcpuid);
+	ret = gzvm_hypcall_wrapper(MT_HVC_GZVM_RUN, a1, 0, 0, 0, 0, 0,
+				   0, &res);
+	*exit_reason = res.a1;
+	return ret;
+}
+
+int gzvm_arch_destroy_vcpu(u16 vm_id, int vcpuid)
+{
+	struct arm_smccc_res res;
+	unsigned long a1;
+
+	a1 = assemble_vm_vcpu_tuple(vm_id, vcpuid);
+	gzvm_hypcall_wrapper(MT_HVC_GZVM_DESTROY_VCPU, a1, 0, 0, 0, 0, 0, 0,
+			     &res);
+
+	return 0;
+}
+
+/**
+ * gzvm_arch_create_vcpu() - Call smc to gz hypervisor to create vcpu
+ * @vm_id: vm id
+ * @vcpuid: vcpu id
+ * @run: Virtual address of vcpu->run
+ *
+ * Return: The wrapper helps caller to convert geniezone errno to Linux errno.
+ */
+int gzvm_arch_create_vcpu(u16 vm_id, int vcpuid, void *run)
+{
+	struct arm_smccc_res res;
+	unsigned long a1, a2;
+	int ret;
+
+	a1 = assemble_vm_vcpu_tuple(vm_id, vcpuid);
+	a2 = (__u64)virt_to_phys(run);
+	ret = gzvm_hypcall_wrapper(MT_HVC_GZVM_CREATE_VCPU, a1, a2, 0, 0, 0, 0,
+				   0, &res);
+
+	return ret;
+}
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index e669a63ccac3..0afdb49b71f5 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -37,6 +37,18 @@ int gzvm_hypcall_wrapper(unsigned long a0, unsigned long a1,
 	return gzvm_err_to_errno(res->a0);
 }
 
+int gzvm_arch_inform_exit(u16 vm_id)
+{
+	struct arm_smccc_res res;
+	int ret;
+
+	ret = gzvm_hypcall_wrapper(MT_HVC_GZVM_INFORM_EXIT, vm_id, 0, 0, 0, 0, 0, 0, &res);
+	if (ret)
+		return -ENXIO;
+
+	return 0;
+}
+
 int gzvm_arch_probe(void)
 {
 	struct arm_smccc_res res;
diff --git a/drivers/virt/geniezone/Makefile b/drivers/virt/geniezone/Makefile
index 59fc4510a843..a630b919cda5 100644
--- a/drivers/virt/geniezone/Makefile
+++ b/drivers/virt/geniezone/Makefile
@@ -7,4 +7,4 @@
 GZVM_DIR ?= ../../../drivers/virt/geniezone
 
 gzvm-y := $(GZVM_DIR)/gzvm_main.o $(GZVM_DIR)/gzvm_vm.o \
-	  $(GZVM_DIR)/gzvm_mmu.o
+	  $(GZVM_DIR)/gzvm_mmu.o $(GZVM_DIR)/gzvm_vcpu.o
diff --git a/drivers/virt/geniezone/gzvm_vcpu.c b/drivers/virt/geniezone/gzvm_vcpu.c
new file mode 100644
index 000000000000..39c471d0d257
--- /dev/null
+++ b/drivers/virt/geniezone/gzvm_vcpu.c
@@ -0,0 +1,251 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <asm/sysreg.h>
+#include <linux/anon_inodes.h>
+#include <linux/device.h>
+#include <linux/file.h>
+#include <linux/mm.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/gzvm_drv.h>
+
+/* maximum size needed for holding an integer */
+#define ITOA_MAX_LEN 12
+
+static long gzvm_vcpu_update_one_reg(struct gzvm_vcpu *vcpu,
+				     void __user *argp,
+				     bool is_write)
+{
+	struct gzvm_one_reg reg;
+	void __user *reg_addr;
+	u64 data = 0;
+	u64 reg_size;
+	long ret;
+
+	if (copy_from_user(&reg, argp, sizeof(reg)))
+		return -EFAULT;
+
+	reg_addr = (void __user *)reg.addr;
+	reg_size = (reg.id & GZVM_REG_SIZE_MASK) >> GZVM_REG_SIZE_SHIFT;
+	reg_size = BIT(reg_size);
+
+	if (reg_size != 1 && reg_size != 2 && reg_size != 4 && reg_size != 8)
+		return -EINVAL;
+
+	if (is_write) {
+		/* GZ hypervisor would filter out invalid vcpu register access */
+		if (copy_from_user(&data, reg_addr, reg_size))
+			return -EFAULT;
+	} else {
+		return -EOPNOTSUPP;
+	}
+
+	ret = gzvm_arch_vcpu_update_one_reg(vcpu, reg.id, is_write, &data);
+
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+/**
+ * gzvm_vcpu_run() - Handle vcpu run ioctl, entry point to guest and exit
+ *		     point from guest
+ * @vcpu: Pointer to struct gzvm_vcpu
+ * @argp: Pointer to struct gzvm_vcpu_run in userspace
+ *
+ * Return:
+ * * 0			- Success.
+ * * Negative		- Failure.
+ */
+static long gzvm_vcpu_run(struct gzvm_vcpu *vcpu, void __user *argp)
+{
+	bool need_userspace = false;
+	u64 exit_reason = 0;
+
+	if (copy_from_user(vcpu->run, argp, sizeof(struct gzvm_vcpu_run)))
+		return -EFAULT;
+
+	for (int i = 0; i < ARRAY_SIZE(vcpu->run->padding1); i++) {
+		if (vcpu->run->padding1[i])
+			return -EINVAL;
+	}
+
+	if (vcpu->run->immediate_exit == 1)
+		return -EINTR;
+
+	while (!need_userspace && !signal_pending(current)) {
+		gzvm_arch_vcpu_run(vcpu, &exit_reason);
+
+		switch (exit_reason) {
+		case GZVM_EXIT_MMIO:
+			need_userspace = true;
+			break;
+		/**
+		 * it's geniezone's responsibility to fill corresponding data
+		 * structure
+		 */
+		case GZVM_EXIT_HYPERCALL:
+			fallthrough;
+		case GZVM_EXIT_EXCEPTION:
+			fallthrough;
+		case GZVM_EXIT_DEBUG:
+			fallthrough;
+		case GZVM_EXIT_FAIL_ENTRY:
+			fallthrough;
+		case GZVM_EXIT_INTERNAL_ERROR:
+			fallthrough;
+		case GZVM_EXIT_SYSTEM_EVENT:
+			fallthrough;
+		case GZVM_EXIT_SHUTDOWN:
+			need_userspace = true;
+			break;
+		case GZVM_EXIT_IRQ:
+			fallthrough;
+		case GZVM_EXIT_GZ:
+			break;
+		case GZVM_EXIT_UNKNOWN:
+			fallthrough;
+		default:
+			pr_err("vcpu unknown exit\n");
+			need_userspace = true;
+			goto out;
+		}
+	}
+
+out:
+	if (copy_to_user(argp, vcpu->run, sizeof(struct gzvm_vcpu_run)))
+		return -EFAULT;
+	if (signal_pending(current)) {
+		// invoke hvc to inform gz to map memory
+		gzvm_arch_inform_exit(vcpu->gzvm->vm_id);
+		return -ERESTARTSYS;
+	}
+	return 0;
+}
+
+static long gzvm_vcpu_ioctl(struct file *filp, unsigned int ioctl,
+			    unsigned long arg)
+{
+	int ret = -ENOTTY;
+	void __user *argp = (void __user *)arg;
+	struct gzvm_vcpu *vcpu = filp->private_data;
+
+	switch (ioctl) {
+	case GZVM_RUN:
+		ret = gzvm_vcpu_run(vcpu, argp);
+		break;
+	case GZVM_GET_ONE_REG:
+		/* !is_write */
+		ret = -EOPNOTSUPP;
+		break;
+	case GZVM_SET_ONE_REG:
+		/* is_write */
+		ret = gzvm_vcpu_update_one_reg(vcpu, argp, true);
+		break;
+	default:
+		break;
+	}
+
+	return ret;
+}
+
+static const struct file_operations gzvm_vcpu_fops = {
+	.unlocked_ioctl = gzvm_vcpu_ioctl,
+	.llseek		= noop_llseek,
+};
+
+/* caller must hold the vm lock */
+static void gzvm_destroy_vcpu(struct gzvm_vcpu *vcpu)
+{
+	if (!vcpu)
+		return;
+
+	gzvm_arch_destroy_vcpu(vcpu->gzvm->vm_id, vcpu->vcpuid);
+	/* clean guest's data */
+	memset(vcpu->run, 0, GZVM_VCPU_RUN_MAP_SIZE);
+	free_pages_exact(vcpu->run, GZVM_VCPU_RUN_MAP_SIZE);
+	kfree(vcpu);
+}
+
+/**
+ * gzvm_destroy_vcpus() - Destroy all vcpus, caller has to hold the vm lock
+ *
+ * @gzvm: vm struct that owns the vcpus
+ */
+void gzvm_destroy_vcpus(struct gzvm *gzvm)
+{
+	int i;
+
+	for (i = 0; i < GZVM_MAX_VCPUS; i++) {
+		gzvm_destroy_vcpu(gzvm->vcpus[i]);
+		gzvm->vcpus[i] = NULL;
+	}
+}
+
+/* create_vcpu_fd() - Allocates an inode for the vcpu. */
+static int create_vcpu_fd(struct gzvm_vcpu *vcpu)
+{
+	/* sizeof("gzvm-vcpu:") + max(strlen(itoa(vcpuid))) + null */
+	char name[10 + ITOA_MAX_LEN + 1];
+
+	snprintf(name, sizeof(name), "gzvm-vcpu:%d", vcpu->vcpuid);
+	return anon_inode_getfd(name, &gzvm_vcpu_fops, vcpu, O_RDWR | O_CLOEXEC);
+}
+
+/**
+ * gzvm_vm_ioctl_create_vcpu() - for GZVM_CREATE_VCPU
+ * @gzvm: Pointer to struct gzvm
+ * @cpuid: equals arg
+ *
+ * Return: Fd of vcpu, negative errno if error occurs
+ */
+int gzvm_vm_ioctl_create_vcpu(struct gzvm *gzvm, u32 cpuid)
+{
+	struct gzvm_vcpu *vcpu;
+	int ret;
+
+	if (cpuid >= GZVM_MAX_VCPUS)
+		return -EINVAL;
+
+	vcpu = kzalloc(sizeof(*vcpu), GFP_KERNEL);
+	if (!vcpu)
+		return -ENOMEM;
+
+	/**
+	 * Allocate 2 pages for data sharing between driver and gz hypervisor
+	 *
+	 * |- page 0           -|- page 1      -|
+	 * |gzvm_vcpu_run|......|hwstate|.......|
+	 *
+	 */
+	vcpu->run = alloc_pages_exact(GZVM_VCPU_RUN_MAP_SIZE,
+				      GFP_KERNEL_ACCOUNT | __GFP_ZERO);
+	if (!vcpu->run) {
+		ret = -ENOMEM;
+		goto free_vcpu;
+	}
+	vcpu->vcpuid = cpuid;
+	vcpu->gzvm = gzvm;
+	mutex_init(&vcpu->lock);
+
+	ret = gzvm_arch_create_vcpu(gzvm->vm_id, vcpu->vcpuid, vcpu->run);
+	if (ret < 0)
+		goto free_vcpu_run;
+
+	ret = create_vcpu_fd(vcpu);
+	if (ret < 0)
+		goto free_vcpu_run;
+	gzvm->vcpus[cpuid] = vcpu;
+
+	return ret;
+
+free_vcpu_run:
+	free_pages_exact(vcpu->run, GZVM_VCPU_RUN_MAP_SIZE);
+free_vcpu:
+	kfree(vcpu);
+	return ret;
+}
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index ba6bfb7ee6e5..ab5a96400f3c 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -118,6 +118,10 @@ static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 		ret = gzvm_dev_ioctl_check_extension(gzvm, arg);
 		break;
 	}
+	case GZVM_CREATE_VCPU: {
+		ret = gzvm_vm_ioctl_create_vcpu(gzvm, arg);
+		break;
+	}
 	case GZVM_SET_USER_MEMORY_REGION: {
 		struct gzvm_userspace_memory_region userspace_mem;
 
@@ -151,6 +155,7 @@ static void gzvm_destroy_vm(struct gzvm *gzvm)
 
 	mutex_lock(&gzvm->lock);
 
+	gzvm_destroy_vcpus(gzvm);
 	gzvm_arch_destroy_vm(gzvm->vm_id);
 
 	mutex_lock(&gzvm_list_lock);
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index a7d6df29b34e..a4203801740c 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -17,6 +17,7 @@
  */
 #define GZVM_PA_ERR_BAD (0x7ffULL << 52)
 
+#define GZVM_VCPU_MMAP_SIZE  PAGE_SIZE
 #define INVALID_VM_ID   0xffff
 
 /*
@@ -34,8 +35,11 @@
  * The following data structures are for data transferring between driver and
  * hypervisor, and they're aligned with hypervisor definitions
  */
+#define GZVM_MAX_VCPUS		 8
 #define GZVM_MAX_MEM_REGION	10
 
+#define GZVM_VCPU_RUN_MAP_SIZE		(PAGE_SIZE * 2)
+
 /* struct mem_region_addr_range - Identical to ffa memory constituent */
 struct mem_region_addr_range {
 	/* the base IPA of the constituent memory region, aligned to 4 kiB */
@@ -63,7 +67,16 @@ struct gzvm_memslot {
 	u32 slot_id;
 };
 
+struct gzvm_vcpu {
+	struct gzvm *gzvm;
+	int vcpuid;
+	/* lock of vcpu*/
+	struct mutex lock;
+	struct gzvm_vcpu_run *run;
+};
+
 struct gzvm {
+	struct gzvm_vcpu *vcpus[GZVM_MAX_VCPUS];
 	/* userspace tied to this vm */
 	struct mm_struct *mm;
 	struct gzvm_memslot memslot[GZVM_MAX_MEM_REGION];
@@ -80,6 +93,8 @@ int gzvm_err_to_errno(unsigned long err);
 
 void gzvm_destroy_all_vms(void);
 
+void gzvm_destroy_vcpus(struct gzvm *gzvm);
+
 /* arch-dependant functions */
 int gzvm_arch_probe(void);
 int gzvm_arch_set_memregion(u16 vm_id, size_t buf_size,
@@ -90,10 +105,19 @@ int gzvm_arch_destroy_vm(u16 vm_id);
 int gzvm_vm_ioctl_arch_enable_cap(struct gzvm *gzvm,
 				  struct gzvm_enable_cap *cap,
 				  void __user *argp);
+
 u64 gzvm_hva_to_pa_arch(u64 hva);
 u64 hva_to_pa_fast(u64 hva);
 u64 hva_to_pa_slow(u64 hva);
 int gzvm_gfn_to_pfn_memslot(struct gzvm_memslot *memslot, u64 gfn, u64 *pfn);
 u64 gzvm_gfn_to_hva_memslot(struct gzvm_memslot *memslot, u64 gfn);
 
+int gzvm_vm_ioctl_create_vcpu(struct gzvm *gzvm, u32 cpuid);
+int gzvm_arch_vcpu_update_one_reg(struct gzvm_vcpu *vcpu, __u64 reg_id,
+				  bool is_write, __u64 *data);
+int gzvm_arch_create_vcpu(u16 vm_id, int vcpuid, void *run);
+int gzvm_arch_vcpu_run(struct gzvm_vcpu *vcpu, __u64 *exit_reason);
+int gzvm_arch_destroy_vcpu(u16 vm_id, int vcpuid);
+int gzvm_arch_inform_exit(u16 vm_id);
+
 #endif /* __GZVM_DRV_H__ */
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index 77a58ee085df..bdf277fa248a 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -25,6 +25,34 @@
 /* GZVM_CAP_PVM_SET_PROTECTED_VM only sets protected but not load pvmfw */
 #define GZVM_CAP_PVM_SET_PROTECTED_VM		2
 
+/*
+ * Architecture specific registers are to be defined and ORed with
+ * the arch identifier.
+ */
+#define GZVM_REG_ARCH_ARM64	0x6000000000000000ULL
+#define GZVM_REG_ARCH_MASK	0xff00000000000000ULL
+
+/*
+ * Reg size = BIT((reg.id & GZVM_REG_SIZE_MASK) >> GZVM_REG_SIZE_SHIFT) bytes
+ */
+#define GZVM_REG_SIZE_SHIFT	52
+#define GZVM_REG_SIZE_MASK	0x00f0000000000000ULL
+
+#define GZVM_REG_SIZE_U8	0x0000000000000000ULL
+#define GZVM_REG_SIZE_U16	0x0010000000000000ULL
+#define GZVM_REG_SIZE_U32	0x0020000000000000ULL
+#define GZVM_REG_SIZE_U64	0x0030000000000000ULL
+#define GZVM_REG_SIZE_U128	0x0040000000000000ULL
+#define GZVM_REG_SIZE_U256	0x0050000000000000ULL
+#define GZVM_REG_SIZE_U512	0x0060000000000000ULL
+#define GZVM_REG_SIZE_U1024	0x0070000000000000ULL
+#define GZVM_REG_SIZE_U2048	0x0080000000000000ULL
+
+/* Register type definitions */
+#define GZVM_REG_TYPE_SHIFT	16
+/* Register type: general purpose */
+#define GZVM_REG_TYPE_GENERAL	(0x10 << GZVM_REG_TYPE_SHIFT)
+
 /* GZVM ioctls */
 #define GZVM_IOC_MAGIC			0x92	/* gz */
 
@@ -51,6 +79,11 @@ struct gzvm_memory_region {
 
 #define GZVM_SET_MEMORY_REGION     _IOW(GZVM_IOC_MAGIC,  0x40, \
 					struct gzvm_memory_region)
+/*
+ * GZVM_CREATE_VCPU receives as a parameter the vcpu slot,
+ * and returns a vcpu fd.
+ */
+#define GZVM_CREATE_VCPU           _IO(GZVM_IOC_MAGIC,   0x41)
 
 /* for GZVM_SET_USER_MEMORY_REGION */
 struct gzvm_userspace_memory_region {
@@ -66,6 +99,124 @@ struct gzvm_userspace_memory_region {
 #define GZVM_SET_USER_MEMORY_REGION _IOW(GZVM_IOC_MAGIC, 0x46, \
 					 struct gzvm_userspace_memory_region)
 
+/*
+ * ioctls for vcpu fds
+ */
+#define GZVM_RUN                   _IO(GZVM_IOC_MAGIC,   0x80)
+
+/* VM exit reason */
+enum {
+	GZVM_EXIT_UNKNOWN = 0x92920000,
+	GZVM_EXIT_MMIO = 0x92920001,
+	GZVM_EXIT_HYPERCALL = 0x92920002,
+	GZVM_EXIT_IRQ = 0x92920003,
+	GZVM_EXIT_EXCEPTION = 0x92920004,
+	GZVM_EXIT_DEBUG = 0x92920005,
+	GZVM_EXIT_FAIL_ENTRY = 0x92920006,
+	GZVM_EXIT_INTERNAL_ERROR = 0x92920007,
+	GZVM_EXIT_SYSTEM_EVENT = 0x92920008,
+	GZVM_EXIT_SHUTDOWN = 0x92920009,
+	GZVM_EXIT_GZ = 0x9292000a,
+};
+
+/**
+ * struct gzvm_vcpu_run: Same purpose as kvm_run, this struct is
+ *			shared between userspace, kernel and
+ *			GenieZone hypervisor
+ * @exit_reason: The reason why gzvm_vcpu_run has stopped running the vCPU
+ * @immediate_exit: Polled when the vcpu is scheduled.
+ *                  If set, immediately returns -EINTR
+ * @padding1: Reserved for future-proof and must be zero filled
+ * @mmio: The nested struct in anonymous union. Handle mmio in host side
+ * @phys_addr: The address guest tries to access
+ * @data: The value to be written (is_write is 1) or
+ *        be filled by user for reads (is_write is 0)
+ * @size: The size of written data.
+ *        Only the first `size` bytes of `data` are handled
+ * @reg_nr: The register number where the data is stored
+ * @is_write: 1 for VM to perform a write or 0 for VM to perform a read
+ * @fail_entry: The nested struct in anonymous union.
+ *              Handle invalid entry address at the first run
+ * @hardware_entry_failure_reason: The reason codes about hardware entry failure
+ * @cpu: The current processor number via smp_processor_id()
+ * @exception: The nested struct in anonymous union.
+ *             Handle exception occurred in VM
+ * @exception: Which exception vector
+ * @error_code: Exception error codes
+ * @hypercall: The nested struct in anonymous union.
+ *             Some hypercalls issued from VM must be handled
+ * @args: The hypercall's arguments
+ * @internal: The nested struct in anonymous union. The errors from hypervisor
+ * @suberror: The errors codes about GZVM_EXIT_INTERNAL_ERROR
+ * @ndata: The number of elements used in data[]
+ * @data: Keep the detailed information about GZVM_EXIT_INTERNAL_ERROR
+ * @system_event: The nested struct in anonymous union.
+ *                VM's PSCI must be handled by host
+ * @type: System event type.
+ *        Ex. GZVM_SYSTEM_EVENT_SHUTDOWN or GZVM_SYSTEM_EVENT_RESET...etc.
+ * @ndata: The number of elements used in data[]
+ * @data: Keep the detailed information about GZVM_EXIT_SYSTEM_EVENT
+ * @padding: Fix it to a reasonable size future-proof for keeping the same
+ *           struct size when adding new variables in the union is needed
+ *
+ * Keep identical layout between the 3 modules
+ */
+struct gzvm_vcpu_run {
+	/* to userspace */
+	__u32 exit_reason;
+	__u8 immediate_exit;
+	__u8 padding1[3];
+	/* union structure of collection of guest exit reason */
+	union {
+		/* GZVM_EXIT_MMIO */
+		struct {
+			/* from FAR_EL2 */
+			__u64 phys_addr;
+			__u8 data[8];
+			/* from ESR_EL2 as */
+			__u64 size;
+			/* from ESR_EL2 */
+			__u32 reg_nr;
+			/* from ESR_EL2 */
+			__u8 is_write;
+		} mmio;
+		/* GZVM_EXIT_FAIL_ENTRY */
+		struct {
+			__u64 hardware_entry_failure_reason;
+			__u32 cpu;
+		} fail_entry;
+		/* GZVM_EXIT_EXCEPTION */
+		struct {
+			__u32 exception;
+			__u32 error_code;
+		} exception;
+		/* GZVM_EXIT_HYPERCALL */
+		struct {
+			__u64 args[8];	/* in-out */
+		} hypercall;
+		/* GZVM_EXIT_INTERNAL_ERROR */
+		struct {
+			__u32 suberror;
+			__u32 ndata;
+			__u64 data[16];
+		} internal;
+		/* GZVM_EXIT_SYSTEM_EVENT */
+		struct {
+#define GZVM_SYSTEM_EVENT_SHUTDOWN       1
+#define GZVM_SYSTEM_EVENT_RESET          2
+#define GZVM_SYSTEM_EVENT_CRASH          3
+#define GZVM_SYSTEM_EVENT_WAKEUP         4
+#define GZVM_SYSTEM_EVENT_SUSPEND        5
+#define GZVM_SYSTEM_EVENT_SEV_TERM       6
+#define GZVM_SYSTEM_EVENT_S2IDLE         7
+			__u32 type;
+			__u32 ndata;
+			__u64 data[16];
+		} system_event;
+		char padding[256];
+	};
+};
+
 /**
  * struct gzvm_enable_cap: The `capability support` on GenieZone hypervisor
  * @cap: `GZVM_CAP_ARM_PROTECTED_VM` or `GZVM_CAP_ARM_VM_IPA_SIZE`
@@ -79,4 +230,17 @@ struct gzvm_enable_cap {
 #define GZVM_ENABLE_CAP            _IOW(GZVM_IOC_MAGIC,  0xa3, \
 					struct gzvm_enable_cap)
 
+/* for GZVM_GET/SET_ONE_REG */
+struct gzvm_one_reg {
+	__u64 id;
+	__u64 addr;
+};
+
+#define GZVM_GET_ONE_REG	   _IOW(GZVM_IOC_MAGIC,  0xab, \
+					struct gzvm_one_reg)
+#define GZVM_SET_ONE_REG	   _IOW(GZVM_IOC_MAGIC,  0xac, \
+					struct gzvm_one_reg)
+
+#define GZVM_REG_GENERIC	   0x0000000000000000ULL
+
 #endif /* __GZVM_H__ */
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:30 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:30 +0800
Subject: [PATCH v8 03/20] virt: geniezone: Add GenieZone hypervisor driver
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-4-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

GenieZone hypervisor(gzvm) is a type-1 hypervisor that supports various
virtual machine types and provides security features such as TEE-like
scenarios and secure boot. It can create guest VMs for security use
cases and has virtualization capabilities for both platform and
interrupt. Although the hypervisor can be booted independently, it
requires the assistance of GenieZone hypervisor kernel driver(gzvm-ko)
to leverage the ability of Linux kernel for vCPU scheduling, memory
management, inter-VM communication and virtio backend support.

Add the basic hypervisor driver. Subsequent patches will add more
supported features to this driver.

Reported-by: kernel test robot <lkp at intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202311170638.aouOEHi7-lkp at intel.com/
Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 MAINTAINERS                             |  3 +
 arch/arm64/Kbuild                       |  1 +
 arch/arm64/geniezone/Makefile           |  9 +++
 arch/arm64/geniezone/gzvm_arch_common.h | 44 ++++++++++++
 arch/arm64/geniezone/vm.c               | 47 +++++++++++++
 drivers/virt/Kconfig                    |  2 +
 drivers/virt/geniezone/Kconfig          | 16 +++++
 drivers/virt/geniezone/Makefile         | 10 +++
 drivers/virt/geniezone/gzvm_main.c      | 89 +++++++++++++++++++++++++
 include/linux/gzvm_drv.h                | 25 +++++++
 10 files changed, 246 insertions(+)
 create mode 100644 arch/arm64/geniezone/Makefile
 create mode 100644 arch/arm64/geniezone/gzvm_arch_common.h
 create mode 100644 arch/arm64/geniezone/vm.c
 create mode 100644 drivers/virt/geniezone/Kconfig
 create mode 100644 drivers/virt/geniezone/Makefile
 create mode 100644 drivers/virt/geniezone/gzvm_main.c
 create mode 100644 include/linux/gzvm_drv.h

diff --git a/MAINTAINERS b/MAINTAINERS
index ac2b1c91f4b5..682396176290 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8985,6 +8985,9 @@ M:	Ze-Yu Wang <ze-yu.wang at mediatek.com>
 M:	Yi-De Wu <yi-de.wu at mediatek.com>
 F:	Documentation/devicetree/bindings/hypervisor/mediatek,geniezone-hyp.yaml
 F:	Documentation/virt/geniezone/
+F:	arch/arm64/geniezone/
+F:	drivers/virt/geniezone/
+F:	include/linux/gzvm_drv.h
 
 GENWQE (IBM Generic Workqueue Card)
 M:	Frank Haverkamp <haver at linux.ibm.com>
diff --git a/arch/arm64/Kbuild b/arch/arm64/Kbuild
index 5bfbf7d79c99..0c3cca572919 100644
--- a/arch/arm64/Kbuild
+++ b/arch/arm64/Kbuild
@@ -4,6 +4,7 @@ obj-$(CONFIG_KVM)	+= kvm/
 obj-$(CONFIG_XEN)	+= xen/
 obj-$(subst m,y,$(CONFIG_HYPERV))	+= hyperv/
 obj-$(CONFIG_CRYPTO)	+= crypto/
+obj-$(CONFIG_MTK_GZVM)	+= geniezone/
 
 # for cleaning
 subdir- += boot
diff --git a/arch/arm64/geniezone/Makefile b/arch/arm64/geniezone/Makefile
new file mode 100644
index 000000000000..2957898cdd05
--- /dev/null
+++ b/arch/arm64/geniezone/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Main Makefile for gzvm, this one includes drivers/virt/geniezone/Makefile
+#
+include $(srctree)/drivers/virt/geniezone/Makefile
+
+gzvm-y += vm.o
+
+obj-$(CONFIG_MTK_GZVM) += gzvm.o
diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
new file mode 100644
index 000000000000..f5bddcfe3a1f
--- /dev/null
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#ifndef __GZVM_ARCH_COMMON_H__
+#define __GZVM_ARCH_COMMON_H__
+
+#include <linux/arm-smccc.h>
+
+enum {
+	GZVM_FUNC_PROBE = 12,
+	NR_GZVM_FUNC,
+};
+
+#define SMC_ENTITY_MTK			59
+#define GZVM_FUNCID_START		(0x1000)
+#define GZVM_HCALL_ID(func)						\
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64,	\
+			   SMC_ENTITY_MTK, (GZVM_FUNCID_START + (func)))
+
+#define MT_HVC_GZVM_PROBE		GZVM_HCALL_ID(GZVM_FUNC_PROBE)
+
+/**
+ * gzvm_hypcall_wrapper() - the wrapper for hvc calls
+ * @a0: arguments passed in registers 0
+ * @a1: arguments passed in registers 1
+ * @a2: arguments passed in registers 2
+ * @a3: arguments passed in registers 3
+ * @a4: arguments passed in registers 4
+ * @a5: arguments passed in registers 5
+ * @a6: arguments passed in registers 6
+ * @a7: arguments passed in registers 7
+ * @res: result values from registers 0 to 3
+ *
+ * Return: The wrapper helps caller to convert geniezone errno to Linux errno.
+ */
+int gzvm_hypcall_wrapper(unsigned long a0, unsigned long a1,
+			 unsigned long a2, unsigned long a3,
+			 unsigned long a4, unsigned long a5,
+			 unsigned long a6, unsigned long a7,
+			 struct arm_smccc_res *res);
+
+#endif /* __GZVM_ARCH_COMMON_H__ */
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
new file mode 100644
index 000000000000..e313aadec212
--- /dev/null
+++ b/arch/arm64/geniezone/vm.c
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/err.h>
+#include <linux/uaccess.h>
+
+#include <linux/gzvm_drv.h>
+#include "gzvm_arch_common.h"
+
+/**
+ * gzvm_hypcall_wrapper() - the wrapper for hvc calls
+ * @a0: arguments passed in registers 0
+ * @a1: arguments passed in registers 1
+ * @a2: arguments passed in registers 2
+ * @a3: arguments passed in registers 3
+ * @a4: arguments passed in registers 4
+ * @a5: arguments passed in registers 5
+ * @a6: arguments passed in registers 6
+ * @a7: arguments passed in registers 7
+ * @res: result values from registers 0 to 3
+ *
+ * Return: The wrapper helps caller to convert geniezone errno to Linux errno.
+ */
+int gzvm_hypcall_wrapper(unsigned long a0, unsigned long a1,
+			 unsigned long a2, unsigned long a3,
+			 unsigned long a4, unsigned long a5,
+			 unsigned long a6, unsigned long a7,
+			 struct arm_smccc_res *res)
+{
+	arm_smccc_hvc(a0, a1, a2, a3, a4, a5, a6, a7, res);
+	return gzvm_err_to_errno(res->a0);
+}
+
+int gzvm_arch_probe(void)
+{
+	struct arm_smccc_res res;
+	int ret;
+
+	ret = gzvm_hypcall_wrapper(MT_HVC_GZVM_PROBE, 0, 0, 0, 0, 0, 0, 0, &res);
+	if (ret)
+		return -ENXIO;
+
+	return 0;
+}
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
index 40129b6f0eca..b4e9bddbcee7 100644
--- a/drivers/virt/Kconfig
+++ b/drivers/virt/Kconfig
@@ -50,4 +50,6 @@ source "drivers/virt/acrn/Kconfig"
 
 source "drivers/virt/coco/Kconfig"
 
+source "drivers/virt/geniezone/Kconfig"
+
 endif
diff --git a/drivers/virt/geniezone/Kconfig b/drivers/virt/geniezone/Kconfig
new file mode 100644
index 000000000000..b17c06c91074
--- /dev/null
+++ b/drivers/virt/geniezone/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config MTK_GZVM
+	tristate "GenieZone Hypervisor driver for guest VM operation"
+	depends on ARM64 && EVENTFD
+	help
+	  This driver, gzvm, enables to run guest VMs on MTK GenieZone
+	  hypervisor. It exports kvm-like interfaces for VMM (e.g., crosvm) in
+	  order to operate guest VMs on GenieZone hypervisor.
+
+	  GenieZone hypervisor now only supports MediaTek SoC and arm64
+	  architecture.
+
+	  Select M if you want it be built as a module (gzvm.ko).
+
+	  If unsure, say N.
diff --git a/drivers/virt/geniezone/Makefile b/drivers/virt/geniezone/Makefile
new file mode 100644
index 000000000000..8c1f0053e773
--- /dev/null
+++ b/drivers/virt/geniezone/Makefile
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Makefile for GenieZone driver, this file should be include in arch's
+# to avoid two ko being generated.
+#
+
+GZVM_DIR ?= ../../../drivers/virt/geniezone
+
+gzvm-y := $(GZVM_DIR)/gzvm_main.o
+
diff --git a/drivers/virt/geniezone/gzvm_main.c b/drivers/virt/geniezone/gzvm_main.c
new file mode 100644
index 000000000000..f7d4f0646d97
--- /dev/null
+++ b/drivers/virt/geniezone/gzvm_main.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/device.h>
+#include <linux/kdev_t.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/gzvm_drv.h>
+
+/**
+ * gzvm_err_to_errno() - Convert geniezone return value to standard errno
+ *
+ * @err: Return value from geniezone function return
+ *
+ * Return: Standard errno
+ */
+int gzvm_err_to_errno(unsigned long err)
+{
+	int gz_err = (int)err;
+
+	switch (gz_err) {
+	case 0:
+		return 0;
+	case ERR_NO_MEMORY:
+		return -ENOMEM;
+	case ERR_NOT_SUPPORTED:
+		return -EOPNOTSUPP;
+	case ERR_NOT_IMPLEMENTED:
+		return -EOPNOTSUPP;
+	case ERR_FAULT:
+		return -EFAULT;
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static const struct file_operations gzvm_chardev_ops = {
+	.llseek		= noop_llseek,
+};
+
+static struct miscdevice gzvm_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = KBUILD_MODNAME,
+	.fops = &gzvm_chardev_ops,
+};
+
+static int gzvm_drv_probe(struct platform_device *pdev)
+{
+	if (gzvm_arch_probe() != 0) {
+		dev_err(&pdev->dev, "Not found available conduit\n");
+		return -ENODEV;
+	}
+
+	return misc_register(&gzvm_dev);
+}
+
+static int gzvm_drv_remove(struct platform_device *pdev)
+{
+	misc_deregister(&gzvm_dev);
+	return 0;
+}
+
+static const struct of_device_id gzvm_of_match[] = {
+	{ .compatible = "mediatek,geniezone-hyp" },
+	{/* sentinel */},
+};
+
+static struct platform_driver gzvm_driver = {
+	.probe = gzvm_drv_probe,
+	.remove = gzvm_drv_remove,
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.owner = THIS_MODULE,
+		.of_match_table = gzvm_of_match,
+	},
+};
+
+module_platform_driver(gzvm_driver);
+
+MODULE_DEVICE_TABLE(of, gzvm_of_match);
+MODULE_AUTHOR("MediaTek");
+MODULE_DESCRIPTION("GenieZone interface for VMM");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
new file mode 100644
index 000000000000..907f2f984de9
--- /dev/null
+++ b/include/linux/gzvm_drv.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#ifndef __GZVM_DRV_H__
+#define __GZVM_DRV_H__
+
+/*
+ * These are the definitions of APIs between GenieZone hypervisor and driver,
+ * there's no need to be visible to uapi. Furthermore, we need GenieZone
+ * specific error code in order to map to Linux errno
+ */
+#define NO_ERROR                (0)
+#define ERR_NO_MEMORY           (-5)
+#define ERR_NOT_SUPPORTED       (-24)
+#define ERR_NOT_IMPLEMENTED     (-27)
+#define ERR_FAULT               (-40)
+
+int gzvm_err_to_errno(unsigned long err);
+
+/* arch-dependant functions */
+int gzvm_arch_probe(void);
+
+#endif /* __GZVM_DRV_H__ */
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:41 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:41 +0800
Subject: [PATCH v8 14/20] virt: geniezone: Add demand paging support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-15-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

This page fault handler helps GenieZone hypervisor to do demand paging.
On a lower level translation fault, GenieZone hypervisor will first
check the fault GPA (guest physical address or IPA in ARM) is valid
e.g. within the registered memory region, then it will setup the
vcpu_run->exit_reason with necessary information for returning to
gzvm driver.

With the fault information, the gzvm driver looks up the physical
address and call the MT_HVC_GZVM_MAP_GUEST to request the hypervisor
maps the found PA to the fault GPA (IPA).

There is one exception, for protected vm, we will populate full VM's
memory region in advance in order to improve performance.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: kevenny hsieh <kevenny.hsieh at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/gzvm_arch_common.h |  2 ++
 arch/arm64/geniezone/vm.c               |  9 ++++++
 drivers/virt/geniezone/Makefile         |  4 +--
 drivers/virt/geniezone/gzvm_exception.c | 39 +++++++++++++++++++++++++
 drivers/virt/geniezone/gzvm_main.c      |  2 ++
 drivers/virt/geniezone/gzvm_mmu.c       | 39 +++++++++++++++++++++++++
 drivers/virt/geniezone/gzvm_vcpu.c      |  6 ++--
 drivers/virt/geniezone/gzvm_vm.c        | 25 ++++++++++++++++
 include/linux/gzvm_drv.h                |  7 +++++
 include/uapi/linux/gzvm.h               | 11 +++++++
 10 files changed, 140 insertions(+), 4 deletions(-)
 create mode 100644 drivers/virt/geniezone/gzvm_exception.c

diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index afb91713fc45..1f0c7a3fede8 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -24,6 +24,7 @@ enum {
 	GZVM_FUNC_INFORM_EXIT = 14,
 	GZVM_FUNC_MEMREGION_PURPOSE = 15,
 	GZVM_FUNC_SET_DTB_CONFIG = 16,
+	GZVM_FUNC_MAP_GUEST = 17,
 	NR_GZVM_FUNC,
 };
 
@@ -48,6 +49,7 @@ enum {
 #define MT_HVC_GZVM_INFORM_EXIT		GZVM_HCALL_ID(GZVM_FUNC_INFORM_EXIT)
 #define MT_HVC_GZVM_MEMREGION_PURPOSE	GZVM_HCALL_ID(GZVM_FUNC_MEMREGION_PURPOSE)
 #define MT_HVC_GZVM_SET_DTB_CONFIG	GZVM_HCALL_ID(GZVM_FUNC_SET_DTB_CONFIG)
+#define MT_HVC_GZVM_MAP_GUEST		GZVM_HCALL_ID(GZVM_FUNC_MAP_GUEST)
 
 #define GIC_V3_NR_LRS			16
 
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index 4ca2ec43b37c..ecc43bcc2705 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -382,3 +382,12 @@ u64 gzvm_hva_to_pa_arch(u64 hva)
 		return GZVM_PA_ERR_BAD;
 	return par;
 }
+
+int gzvm_arch_map_guest(u16 vm_id, int memslot_id, u64 pfn, u64 gfn,
+			u64 nr_pages)
+{
+	struct arm_smccc_res res;
+
+	return gzvm_hypcall_wrapper(MT_HVC_GZVM_MAP_GUEST, vm_id, memslot_id,
+				    pfn, gfn, nr_pages, 0, 0, &res);
+}
diff --git a/drivers/virt/geniezone/Makefile b/drivers/virt/geniezone/Makefile
index 9956f4891df2..2e12870637d5 100644
--- a/drivers/virt/geniezone/Makefile
+++ b/drivers/virt/geniezone/Makefile
@@ -8,5 +8,5 @@ GZVM_DIR ?= ../../../drivers/virt/geniezone
 
 gzvm-y := $(GZVM_DIR)/gzvm_main.o $(GZVM_DIR)/gzvm_vm.o \
 	  $(GZVM_DIR)/gzvm_mmu.o $(GZVM_DIR)/gzvm_vcpu.o \
-	  $(GZVM_DIR)/gzvm_irqfd.o $(GZVM_DIR)/gzvm_ioeventfd.o
-
+	  $(GZVM_DIR)/gzvm_irqfd.o $(GZVM_DIR)/gzvm_ioeventfd.o \
+	  $(GZVM_DIR)/gzvm_exception.o
diff --git a/drivers/virt/geniezone/gzvm_exception.c b/drivers/virt/geniezone/gzvm_exception.c
new file mode 100644
index 000000000000..31fdb4ae8db4
--- /dev/null
+++ b/drivers/virt/geniezone/gzvm_exception.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/device.h>
+#include <linux/gzvm_drv.h>
+
+/**
+ * gzvm_handle_guest_exception() - Handle guest exception
+ * @vcpu: Pointer to struct gzvm_vcpu_run in userspace
+ * Return:
+ * * true - This exception has been processed, no need to back to VMM.
+ * * false - This exception has not been processed, require userspace.
+ */
+bool gzvm_handle_guest_exception(struct gzvm_vcpu *vcpu)
+{
+	int ret;
+
+	for (int i = 0; i < ARRAY_SIZE(vcpu->run->exception.reserved); i++) {
+		if (vcpu->run->exception.reserved[i])
+			return -EINVAL;
+	}
+
+	switch (vcpu->run->exception.exception) {
+	case GZVM_EXCEPTION_PAGE_FAULT:
+		ret = gzvm_handle_page_fault(vcpu);
+		break;
+	case GZVM_EXCEPTION_UNKNOWN:
+		fallthrough;
+	default:
+		ret = -EFAULT;
+	}
+
+	if (!ret)
+		return true;
+	else
+		return false;
+}
diff --git a/drivers/virt/geniezone/gzvm_main.c b/drivers/virt/geniezone/gzvm_main.c
index 4e5d1b83df4a..af5ab8949206 100644
--- a/drivers/virt/geniezone/gzvm_main.c
+++ b/drivers/virt/geniezone/gzvm_main.c
@@ -28,6 +28,8 @@ int gzvm_err_to_errno(unsigned long err)
 		return 0;
 	case ERR_NO_MEMORY:
 		return -ENOMEM;
+	case ERR_INVALID_ARGS:
+		return -EINVAL;
 	case ERR_NOT_SUPPORTED:
 		return -EOPNOTSUPP;
 	case ERR_NOT_IMPLEMENTED:
diff --git a/drivers/virt/geniezone/gzvm_mmu.c b/drivers/virt/geniezone/gzvm_mmu.c
index f24fa7e6d975..e6415baa064d 100644
--- a/drivers/virt/geniezone/gzvm_mmu.c
+++ b/drivers/virt/geniezone/gzvm_mmu.c
@@ -106,3 +106,42 @@ int gzvm_gfn_to_pfn_memslot(struct gzvm_memslot *memslot, u64 gfn,
 
 	return 0;
 }
+
+static int handle_single_demand_page(struct gzvm *vm, int memslot_id, u64 gfn)
+{
+	int ret;
+	u64 pfn;
+
+	ret = gzvm_gfn_to_pfn_memslot(&vm->memslot[memslot_id], gfn, &pfn);
+	if (unlikely(ret))
+		return -EFAULT;
+
+	ret = gzvm_arch_map_guest(vm->vm_id, memslot_id, pfn, gfn, 1);
+	if (unlikely(ret))
+		return -EFAULT;
+
+	return 0;
+}
+
+/**
+ * gzvm_handle_page_fault() - Handle guest page fault, find corresponding page
+ *                            for the faulting gpa
+ * @vcpu: Pointer to struct gzvm_vcpu_run of the faulting vcpu
+ *
+ * Return:
+ * * 0		- Success to handle guest page fault
+ * * -EFAULT	- Failed to map phys addr to guest's GPA
+ */
+int gzvm_handle_page_fault(struct gzvm_vcpu *vcpu)
+{
+	struct gzvm *vm = vcpu->gzvm;
+	int memslot_id;
+	u64 gfn;
+
+	gfn = PHYS_PFN(vcpu->run->exception.fault_gpa);
+	memslot_id = gzvm_find_memslot(vm, gfn);
+	if (unlikely(memslot_id < 0))
+		return -EFAULT;
+
+	return handle_single_demand_page(vm, memslot_id, gfn);
+}
diff --git a/drivers/virt/geniezone/gzvm_vcpu.c b/drivers/virt/geniezone/gzvm_vcpu.c
index 77138e749e9a..455ae2e4285c 100644
--- a/drivers/virt/geniezone/gzvm_vcpu.c
+++ b/drivers/virt/geniezone/gzvm_vcpu.c
@@ -113,9 +113,11 @@ static long gzvm_vcpu_run(struct gzvm_vcpu *vcpu, void __user *argp)
 		 * it's geniezone's responsibility to fill corresponding data
 		 * structure
 		 */
-		case GZVM_EXIT_HYPERCALL:
-			fallthrough;
 		case GZVM_EXIT_EXCEPTION:
+			if (!gzvm_handle_guest_exception(vcpu))
+				need_userspace = true;
+			break;
+		case GZVM_EXIT_HYPERCALL:
 			fallthrough;
 		case GZVM_EXIT_DEBUG:
 			fallthrough;
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index 538549ef405c..9f7e44521de5 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -23,6 +23,31 @@ u64 gzvm_gfn_to_hva_memslot(struct gzvm_memslot *memslot, u64 gfn)
 	return memslot->userspace_addr + offset * PAGE_SIZE;
 }
 
+/**
+ * gzvm_find_memslot() - Find memslot containing this @gpa
+ * @vm: Pointer to struct gzvm
+ * @gfn: Guest frame number
+ *
+ * Return:
+ * * >=0		- Index of memslot
+ * * -EFAULT		- Not found
+ */
+int gzvm_find_memslot(struct gzvm *vm, u64 gfn)
+{
+	int i;
+
+	for (i = 0; i < GZVM_MAX_MEM_REGION; i++) {
+		if (vm->memslot[i].npages == 0)
+			continue;
+
+		if (gfn >= vm->memslot[i].base_gfn &&
+		    gfn < vm->memslot[i].base_gfn + vm->memslot[i].npages)
+			return i;
+	}
+
+	return -EFAULT;
+}
+
 /**
  * register_memslot_addr_range() - Register memory region to GenieZone
  * @gzvm: Pointer to struct gzvm
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index 43d85dc5d7c0..b9e60fe5dcde 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -29,6 +29,7 @@
  */
 #define NO_ERROR                (0)
 #define ERR_NO_MEMORY           (-5)
+#define ERR_INVALID_ARGS        (-8)
 #define ERR_NOT_SUPPORTED       (-24)
 #define ERR_NOT_IMPLEMENTED     (-27)
 #define ERR_FAULT               (-40)
@@ -123,6 +124,8 @@ int gzvm_arch_set_memregion(u16 vm_id, size_t buf_size,
 int gzvm_arch_check_extension(struct gzvm *gzvm, __u64 cap, void __user *argp);
 int gzvm_arch_create_vm(unsigned long vm_type);
 int gzvm_arch_destroy_vm(u16 vm_id);
+int gzvm_arch_map_guest(u16 vm_id, int memslot_id, u64 pfn, u64 gfn,
+			u64 nr_pages);
 int gzvm_vm_ioctl_arch_enable_cap(struct gzvm *gzvm,
 				  struct gzvm_enable_cap *cap,
 				  void __user *argp);
@@ -141,6 +144,10 @@ int gzvm_arch_vcpu_run(struct gzvm_vcpu *vcpu, __u64 *exit_reason);
 int gzvm_arch_destroy_vcpu(u16 vm_id, int vcpuid);
 int gzvm_arch_inform_exit(u16 vm_id);
 
+int gzvm_find_memslot(struct gzvm *vm, u64 gpa);
+int gzvm_handle_page_fault(struct gzvm_vcpu *vcpu);
+bool gzvm_handle_guest_exception(struct gzvm_vcpu *vcpu);
+
 int gzvm_arch_create_device(u16 vm_id, struct gzvm_create_device *gzvm_dev);
 int gzvm_arch_inject_irq(struct gzvm *gzvm, unsigned int vcpu_idx,
 			 u32 irq, bool level);
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index f4f04403d5b3..1f134c55ac2a 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -185,6 +185,12 @@ enum {
 	GZVM_EXIT_GZ = 0x9292000a,
 };
 
+/* exception definitions of GZVM_EXIT_EXCEPTION */
+enum {
+	GZVM_EXCEPTION_UNKNOWN = 0x0,
+	GZVM_EXCEPTION_PAGE_FAULT = 0x1,
+};
+
 /**
  * struct gzvm_vcpu_run: Same purpose as kvm_run, this struct is
  *			shared between userspace, kernel and
@@ -209,6 +215,9 @@ enum {
  *             Handle exception occurred in VM
  * @exception: Which exception vector
  * @error_code: Exception error codes
+ * @fault_gpa: Fault GPA (guest physical address or IPA in ARM)
+ * @reserved: Future-proof reservation and reset to zero in hypervisor.
+ *            Fill up to the union size, 256 bytes.
  * @hypercall: The nested struct in anonymous union.
  *             Some hypercalls issued from VM must be handled
  * @args: The hypercall's arguments
@@ -255,6 +264,8 @@ struct gzvm_vcpu_run {
 		struct {
 			__u32 exception;
 			__u32 error_code;
+			__u64 fault_gpa;
+			__u64 reserved[30];
 		} exception;
 		/* GZVM_EXIT_HYPERCALL */
 		struct {
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:31 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:31 +0800
Subject: [PATCH v8 04/20] virt: geniezone: Add vm support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-5-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

The VM component is responsible for setting up the capability and memory
management for the protected VMs. The capability is mainly about the
lifecycle control and boot context initialization.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 MAINTAINERS                             |   1 +
 arch/arm64/geniezone/gzvm_arch_common.h |   9 ++
 arch/arm64/geniezone/vm.c               |  29 +++++++
 drivers/virt/geniezone/Makefile         |   2 +-
 drivers/virt/geniezone/gzvm_main.c      |  19 +++++
 drivers/virt/geniezone/gzvm_vm.c        | 107 ++++++++++++++++++++++++
 include/linux/gzvm_drv.h                |  26 ++++++
 include/uapi/linux/gzvm.h               |  25 ++++++
 8 files changed, 217 insertions(+), 1 deletion(-)
 create mode 100644 drivers/virt/geniezone/gzvm_vm.c
 create mode 100644 include/uapi/linux/gzvm.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 682396176290..ee7cc8cd7622 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8988,6 +8988,7 @@ F:	Documentation/virt/geniezone/
 F:	arch/arm64/geniezone/
 F:	drivers/virt/geniezone/
 F:	include/linux/gzvm_drv.h
+F:	include/uapi/linux/gzvm.h
 
 GENWQE (IBM Generic Workqueue Card)
 M:	Frank Haverkamp <haver at linux.ibm.com>
diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index f5bddcfe3a1f..fdaa7849353d 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -9,6 +9,8 @@
 #include <linux/arm-smccc.h>
 
 enum {
+	GZVM_FUNC_CREATE_VM = 0,
+	GZVM_FUNC_DESTROY_VM = 1,
 	GZVM_FUNC_PROBE = 12,
 	NR_GZVM_FUNC,
 };
@@ -19,6 +21,8 @@ enum {
 	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64,	\
 			   SMC_ENTITY_MTK, (GZVM_FUNCID_START + (func)))
 
+#define MT_HVC_GZVM_CREATE_VM		GZVM_HCALL_ID(GZVM_FUNC_CREATE_VM)
+#define MT_HVC_GZVM_DESTROY_VM		GZVM_HCALL_ID(GZVM_FUNC_DESTROY_VM)
 #define MT_HVC_GZVM_PROBE		GZVM_HCALL_ID(GZVM_FUNC_PROBE)
 
 /**
@@ -41,4 +45,9 @@ int gzvm_hypcall_wrapper(unsigned long a0, unsigned long a1,
 			 unsigned long a6, unsigned long a7,
 			 struct arm_smccc_res *res);
 
+static inline u16 get_vmid_from_tuple(unsigned int tuple)
+{
+	return (u16)(tuple >> 16);
+}
+
 #endif /* __GZVM_ARCH_COMMON_H__ */
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index e313aadec212..a15bad13c2ee 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -7,9 +7,12 @@
 #include <linux/err.h>
 #include <linux/uaccess.h>
 
+#include <linux/gzvm.h>
 #include <linux/gzvm_drv.h>
 #include "gzvm_arch_common.h"
 
+#define PAR_PA47_MASK ((((1UL << 48) - 1) >> 12) << 12)
+
 /**
  * gzvm_hypcall_wrapper() - the wrapper for hvc calls
  * @a0: arguments passed in registers 0
@@ -45,3 +48,29 @@ int gzvm_arch_probe(void)
 
 	return 0;
 }
+
+/**
+ * gzvm_arch_create_vm() - create vm
+ * @vm_type: VM type. Only supports Linux VM now.
+ *
+ * Return:
+ * * positive value	- VM ID
+ * * -ENOMEM		- Memory not enough for storing VM data
+ */
+int gzvm_arch_create_vm(unsigned long vm_type)
+{
+	struct arm_smccc_res res;
+	int ret;
+
+	ret = gzvm_hypcall_wrapper(MT_HVC_GZVM_CREATE_VM, vm_type, 0, 0, 0, 0,
+				   0, 0, &res);
+	return ret ? ret : res.a1;
+}
+
+int gzvm_arch_destroy_vm(u16 vm_id)
+{
+	struct arm_smccc_res res;
+
+	return gzvm_hypcall_wrapper(MT_HVC_GZVM_DESTROY_VM, vm_id, 0, 0, 0, 0,
+				    0, 0, &res);
+}
diff --git a/drivers/virt/geniezone/Makefile b/drivers/virt/geniezone/Makefile
index 8c1f0053e773..066efddc0b9c 100644
--- a/drivers/virt/geniezone/Makefile
+++ b/drivers/virt/geniezone/Makefile
@@ -6,5 +6,5 @@
 
 GZVM_DIR ?= ../../../drivers/virt/geniezone
 
-gzvm-y := $(GZVM_DIR)/gzvm_main.o
+gzvm-y := $(GZVM_DIR)/gzvm_main.o $(GZVM_DIR)/gzvm_vm.o
 
diff --git a/drivers/virt/geniezone/gzvm_main.c b/drivers/virt/geniezone/gzvm_main.c
index f7d4f0646d97..4e7d60067c55 100644
--- a/drivers/virt/geniezone/gzvm_main.c
+++ b/drivers/virt/geniezone/gzvm_main.c
@@ -4,6 +4,7 @@
  */
 
 #include <linux/device.h>
+#include <linux/file.h>
 #include <linux/kdev_t.h>
 #include <linux/miscdevice.h>
 #include <linux/module.h>
@@ -40,7 +41,24 @@ int gzvm_err_to_errno(unsigned long err)
 	return -EINVAL;
 }
 
+static long gzvm_dev_ioctl(struct file *filp, unsigned int cmd,
+			   unsigned long user_args)
+{
+	long ret;
+
+	switch (cmd) {
+	case GZVM_CREATE_VM:
+		ret = gzvm_dev_ioctl_create_vm(user_args);
+		return ret;
+	default:
+		break;
+	}
+
+	return -ENOTTY;
+}
+
 static const struct file_operations gzvm_chardev_ops = {
+	.unlocked_ioctl = gzvm_dev_ioctl,
 	.llseek		= noop_llseek,
 };
 
@@ -62,6 +80,7 @@ static int gzvm_drv_probe(struct platform_device *pdev)
 
 static int gzvm_drv_remove(struct platform_device *pdev)
 {
+	gzvm_destroy_all_vms();
 	misc_deregister(&gzvm_dev);
 	return 0;
 }
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
new file mode 100644
index 000000000000..d5e850af924a
--- /dev/null
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/anon_inodes.h>
+#include <linux/file.h>
+#include <linux/kdev_t.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/gzvm_drv.h>
+
+static DEFINE_MUTEX(gzvm_list_lock);
+static LIST_HEAD(gzvm_list);
+
+static void gzvm_destroy_vm(struct gzvm *gzvm)
+{
+	pr_debug("VM-%u is going to be destroyed\n", gzvm->vm_id);
+
+	mutex_lock(&gzvm->lock);
+
+	gzvm_arch_destroy_vm(gzvm->vm_id);
+
+	mutex_lock(&gzvm_list_lock);
+	list_del(&gzvm->vm_list);
+	mutex_unlock(&gzvm_list_lock);
+
+	mutex_unlock(&gzvm->lock);
+
+	kfree(gzvm);
+}
+
+static int gzvm_vm_release(struct inode *inode, struct file *filp)
+{
+	struct gzvm *gzvm = filp->private_data;
+
+	gzvm_destroy_vm(gzvm);
+	return 0;
+}
+
+static const struct file_operations gzvm_vm_fops = {
+	.release        = gzvm_vm_release,
+	.llseek		= noop_llseek,
+};
+
+static struct gzvm *gzvm_create_vm(unsigned long vm_type)
+{
+	int ret;
+	struct gzvm *gzvm;
+
+	gzvm = kzalloc(sizeof(*gzvm), GFP_KERNEL);
+	if (!gzvm)
+		return ERR_PTR(-ENOMEM);
+
+	ret = gzvm_arch_create_vm(vm_type);
+	if (ret < 0) {
+		kfree(gzvm);
+		return ERR_PTR(ret);
+	}
+
+	gzvm->vm_id = ret;
+	gzvm->mm = current->mm;
+	mutex_init(&gzvm->lock);
+
+	mutex_lock(&gzvm_list_lock);
+	list_add(&gzvm->vm_list, &gzvm_list);
+	mutex_unlock(&gzvm_list_lock);
+
+	pr_debug("VM-%u is created\n", gzvm->vm_id);
+
+	return gzvm;
+}
+
+/**
+ * gzvm_dev_ioctl_create_vm - Create vm fd
+ * @vm_type: VM type. Only supports Linux VM now.
+ *
+ * Return: fd of vm, negative if error
+ */
+int gzvm_dev_ioctl_create_vm(unsigned long vm_type)
+{
+	struct gzvm *gzvm;
+
+	gzvm = gzvm_create_vm(vm_type);
+	if (IS_ERR(gzvm))
+		return PTR_ERR(gzvm);
+
+	return anon_inode_getfd("gzvm-vm", &gzvm_vm_fops, gzvm,
+			       O_RDWR | O_CLOEXEC);
+}
+
+void gzvm_destroy_all_vms(void)
+{
+	struct gzvm *gzvm, *tmp;
+
+	mutex_lock(&gzvm_list_lock);
+	if (list_empty(&gzvm_list))
+		goto out;
+
+	list_for_each_entry_safe(gzvm, tmp, &gzvm_list, vm_list)
+		gzvm_destroy_vm(gzvm);
+
+out:
+	mutex_unlock(&gzvm_list_lock);
+}
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index 907f2f984de9..f1dce23838e4 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -6,6 +6,12 @@
 #ifndef __GZVM_DRV_H__
 #define __GZVM_DRV_H__
 
+#include <linux/list.h>
+#include <linux/mutex.h>
+#include <linux/gzvm.h>
+
+#define INVALID_VM_ID   0xffff
+
 /*
  * These are the definitions of APIs between GenieZone hypervisor and driver,
  * there's no need to be visible to uapi. Furthermore, we need GenieZone
@@ -17,9 +23,29 @@
 #define ERR_NOT_IMPLEMENTED     (-27)
 #define ERR_FAULT               (-40)
 
+/*
+ * The following data structures are for data transferring between driver and
+ * hypervisor, and they're aligned with hypervisor definitions
+ */
+
+struct gzvm {
+	/* userspace tied to this vm */
+	struct mm_struct *mm;
+	/* lock for list_add*/
+	struct mutex lock;
+	struct list_head vm_list;
+	u16 vm_id;
+};
+
+int gzvm_dev_ioctl_create_vm(unsigned long vm_type);
+
 int gzvm_err_to_errno(unsigned long err);
 
+void gzvm_destroy_all_vms(void);
+
 /* arch-dependant functions */
 int gzvm_arch_probe(void);
+int gzvm_arch_create_vm(unsigned long vm_type);
+int gzvm_arch_destroy_vm(u16 vm_id);
 
 #endif /* __GZVM_DRV_H__ */
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
new file mode 100644
index 000000000000..c26c7720fab7
--- /dev/null
+++ b/include/uapi/linux/gzvm.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+/**
+ * DOC: UAPI of GenieZone Hypervisor
+ *
+ * This file declares common data structure shared among user space,
+ * kernel space, and GenieZone hypervisor.
+ */
+#ifndef __GZVM_H__
+#define __GZVM_H__
+
+#include <linux/const.h>
+#include <linux/types.h>
+#include <linux/ioctl.h>
+
+/* GZVM ioctls */
+#define GZVM_IOC_MAGIC			0x92	/* gz */
+
+/* ioctls for /dev/gzvm fds */
+#define GZVM_CREATE_VM             _IO(GZVM_IOC_MAGIC,   0x01) /* Returns a Geniezone VM fd */
+
+#endif /* __GZVM_H__ */
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:36 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:36 +0800
Subject: [PATCH v8 09/20] virt: geniezone: Add irqchip support for virtual interrupt injection
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-10-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

Enable GenieZone to handle virtual interrupt injection request.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: kevenny hsieh <kevenny.hsieh at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/Makefile           |  2 +-
 arch/arm64/geniezone/gzvm_arch_common.h |  4 ++
 arch/arm64/geniezone/vgic.c             | 50 +++++++++++++++
 drivers/virt/geniezone/gzvm_common.h    | 12 ++++
 drivers/virt/geniezone/gzvm_vm.c        | 81 +++++++++++++++++++++++++
 include/linux/gzvm_drv.h                |  4 ++
 include/uapi/linux/gzvm.h               | 66 ++++++++++++++++++++
 7 files changed, 218 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/geniezone/vgic.c
 create mode 100644 drivers/virt/geniezone/gzvm_common.h

diff --git a/arch/arm64/geniezone/Makefile b/arch/arm64/geniezone/Makefile
index 69b0a4abeab0..0e4f1087f9de 100644
--- a/arch/arm64/geniezone/Makefile
+++ b/arch/arm64/geniezone/Makefile
@@ -4,6 +4,6 @@
 #
 include $(srctree)/drivers/virt/geniezone/Makefile
 
-gzvm-y += vm.o vcpu.o
+gzvm-y += vm.o vcpu.o vgic.o
 
 obj-$(CONFIG_MTK_GZVM) += gzvm.o
diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index 684c35e2d9bc..7b423c1c4549 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -17,6 +17,8 @@ enum {
 	GZVM_FUNC_RUN = 5,
 	GZVM_FUNC_GET_ONE_REG = 8,
 	GZVM_FUNC_SET_ONE_REG = 9,
+	GZVM_FUNC_IRQ_LINE = 10,
+	GZVM_FUNC_CREATE_DEVICE = 11,
 	GZVM_FUNC_PROBE = 12,
 	GZVM_FUNC_ENABLE_CAP = 13,
 	GZVM_FUNC_INFORM_EXIT = 14,
@@ -37,6 +39,8 @@ enum {
 #define MT_HVC_GZVM_RUN			GZVM_HCALL_ID(GZVM_FUNC_RUN)
 #define MT_HVC_GZVM_GET_ONE_REG		GZVM_HCALL_ID(GZVM_FUNC_GET_ONE_REG)
 #define MT_HVC_GZVM_SET_ONE_REG		GZVM_HCALL_ID(GZVM_FUNC_SET_ONE_REG)
+#define MT_HVC_GZVM_IRQ_LINE		GZVM_HCALL_ID(GZVM_FUNC_IRQ_LINE)
+#define MT_HVC_GZVM_CREATE_DEVICE	GZVM_HCALL_ID(GZVM_FUNC_CREATE_DEVICE)
 #define MT_HVC_GZVM_PROBE		GZVM_HCALL_ID(GZVM_FUNC_PROBE)
 #define MT_HVC_GZVM_ENABLE_CAP		GZVM_HCALL_ID(GZVM_FUNC_ENABLE_CAP)
 #define MT_HVC_GZVM_INFORM_EXIT		GZVM_HCALL_ID(GZVM_FUNC_INFORM_EXIT)
diff --git a/arch/arm64/geniezone/vgic.c b/arch/arm64/geniezone/vgic.c
new file mode 100644
index 000000000000..122125f7f8d4
--- /dev/null
+++ b/arch/arm64/geniezone/vgic.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#include <linux/irqchip/arm-gic-v3.h>
+#include <linux/gzvm.h>
+#include <linux/gzvm_drv.h>
+#include "gzvm_arch_common.h"
+
+int gzvm_arch_create_device(u16 vm_id, struct gzvm_create_device *gzvm_dev)
+{
+	struct arm_smccc_res res;
+
+	return gzvm_hypcall_wrapper(MT_HVC_GZVM_CREATE_DEVICE, vm_id,
+				    virt_to_phys(gzvm_dev), 0, 0, 0, 0, 0,
+				    &res);
+}
+
+/**
+ * gzvm_arch_inject_irq() - Inject virtual interrupt to a VM
+ * @gzvm: Pointer to struct gzvm
+ * @vcpu_idx: vcpu index, only valid if PPI
+ * @irq: *SPI* irq number (excluding offset value `32`)
+ * @level: 1 if true else 0
+ *
+ * Return:
+ * * 0			- Success.
+ * * Negative		- Failure.
+ */
+int gzvm_arch_inject_irq(struct gzvm *gzvm, unsigned int vcpu_idx,
+			 u32 irq, bool level)
+{
+	unsigned long a1 = assemble_vm_vcpu_tuple(gzvm->vm_id, vcpu_idx);
+	struct arm_smccc_res res;
+
+	/*
+	 * VMM's virtual device irq number starts from 0, but ARM's shared peripheral
+	 * interrupt number starts from 32. hypervisor adds offset 32
+	 */
+	gzvm_hypcall_wrapper(MT_HVC_GZVM_IRQ_LINE, a1, irq, level,
+			     0, 0, 0, 0, &res);
+	if (res.a0) {
+		pr_err("Failed to set IRQ level (%d) to irq#%u on vcpu %d with ret=%d\n",
+		       level, irq, vcpu_idx, (int)res.a0);
+		return -EFAULT;
+	}
+
+	return 0;
+}
diff --git a/drivers/virt/geniezone/gzvm_common.h b/drivers/virt/geniezone/gzvm_common.h
new file mode 100644
index 000000000000..c8d90fee3a18
--- /dev/null
+++ b/drivers/virt/geniezone/gzvm_common.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+
+#ifndef __GZ_COMMON_H__
+#define __GZ_COMMON_H__
+
+int gzvm_irqchip_inject_irq(struct gzvm *gzvm, unsigned int vcpu_idx,
+			    u32 irq, bool level);
+
+#endif /* __GZVM_COMMON_H__ */
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index ab5a96400f3c..8d6b7aebaf3a 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -11,6 +11,7 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/gzvm_drv.h>
+#include "gzvm_common.h"
 
 static DEFINE_MUTEX(gzvm_list_lock);
 static LIST_HEAD(gzvm_list);
@@ -98,6 +99,72 @@ gzvm_vm_ioctl_set_memory_region(struct gzvm *gzvm,
 	return register_memslot_addr_range(gzvm, memslot);
 }
 
+int gzvm_irqchip_inject_irq(struct gzvm *gzvm, unsigned int vcpu_idx,
+			    u32 irq, bool level)
+{
+	return gzvm_arch_inject_irq(gzvm, vcpu_idx, irq, level);
+}
+
+static int gzvm_vm_ioctl_irq_line(struct gzvm *gzvm,
+				  struct gzvm_irq_level *irq_level)
+{
+	u32 irq = irq_level->irq;
+	u32 vcpu_idx, vcpu2_idx, irq_num;
+	bool level = irq_level->level;
+
+	vcpu_idx = FIELD_GET(GZVM_IRQ_LINE_VCPU, irq);
+	vcpu2_idx = FIELD_GET(GZVM_IRQ_LINE_VCPU2, irq) * (GZVM_IRQ_VCPU_MASK + 1);
+	irq_num = FIELD_GET(GZVM_IRQ_LINE_NUM, irq);
+
+	return gzvm_irqchip_inject_irq(gzvm, vcpu_idx + vcpu2_idx, irq_num,
+				       level);
+}
+
+static int gzvm_vm_ioctl_create_device(struct gzvm *gzvm, void __user *argp)
+{
+	struct gzvm_create_device *gzvm_dev;
+	void *dev_data = NULL;
+	int ret;
+
+	gzvm_dev = (struct gzvm_create_device *)alloc_pages_exact(PAGE_SIZE,
+								  GFP_KERNEL);
+	if (!gzvm_dev)
+		return -ENOMEM;
+	if (copy_from_user(gzvm_dev, argp, sizeof(*gzvm_dev))) {
+		ret = -EFAULT;
+		goto err_free_dev;
+	}
+
+	if (gzvm_dev->attr_addr != 0 && gzvm_dev->attr_size != 0) {
+		size_t attr_size = gzvm_dev->attr_size;
+		void __user *attr_addr = (void __user *)gzvm_dev->attr_addr;
+
+		/* Size of device specific data should not be over a page. */
+		if (attr_size > PAGE_SIZE)
+			return -EINVAL;
+
+		dev_data = alloc_pages_exact(attr_size, GFP_KERNEL);
+		if (!dev_data) {
+			ret = -ENOMEM;
+			goto err_free_dev;
+		}
+
+		if (copy_from_user(dev_data, attr_addr, attr_size)) {
+			ret = -EFAULT;
+			goto err_free_dev_data;
+		}
+		gzvm_dev->attr_addr = virt_to_phys(dev_data);
+	}
+
+	ret = gzvm_arch_create_device(gzvm->vm_id, gzvm_dev);
+err_free_dev_data:
+	if (dev_data)
+		free_pages_exact(dev_data, 0);
+err_free_dev:
+	free_pages_exact(gzvm_dev, 0);
+	return ret;
+}
+
 static int gzvm_vm_ioctl_enable_cap(struct gzvm *gzvm,
 				    struct gzvm_enable_cap *cap,
 				    void __user *argp)
@@ -132,6 +199,20 @@ static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 		ret = gzvm_vm_ioctl_set_memory_region(gzvm, &userspace_mem);
 		break;
 	}
+	case GZVM_IRQ_LINE: {
+		struct gzvm_irq_level irq_event;
+
+		if (copy_from_user(&irq_event, argp, sizeof(irq_event))) {
+			ret = -EFAULT;
+			goto out;
+		}
+		ret = gzvm_vm_ioctl_irq_line(gzvm, &irq_event);
+		break;
+	}
+	case GZVM_CREATE_DEVICE: {
+		ret = gzvm_vm_ioctl_create_device(gzvm, argp);
+		break;
+	}
 	case GZVM_ENABLE_CAP: {
 		struct gzvm_enable_cap cap;
 
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index a4203801740c..805a866acecc 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -120,4 +120,8 @@ int gzvm_arch_vcpu_run(struct gzvm_vcpu *vcpu, __u64 *exit_reason);
 int gzvm_arch_destroy_vcpu(u16 vm_id, int vcpuid);
 int gzvm_arch_inform_exit(u16 vm_id);
 
+int gzvm_arch_create_device(u16 vm_id, struct gzvm_create_device *gzvm_dev);
+int gzvm_arch_inject_irq(struct gzvm *gzvm, unsigned int vcpu_idx,
+			 u32 irq, bool level);
+
 #endif /* __GZVM_DRV_H__ */
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index bdf277fa248a..a1f6acdc4055 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -99,6 +99,72 @@ struct gzvm_userspace_memory_region {
 #define GZVM_SET_USER_MEMORY_REGION _IOW(GZVM_IOC_MAGIC, 0x46, \
 					 struct gzvm_userspace_memory_region)
 
+/* for GZVM_IRQ_LINE, irq field index values */
+#define GZVM_IRQ_VCPU_MASK		0xff
+#define GZVM_IRQ_LINE_TYPE		GENMASK(27, 24)
+#define GZVM_IRQ_LINE_VCPU		GENMASK(23, 16)
+#define GZVM_IRQ_LINE_VCPU2		GENMASK(31, 28)
+#define GZVM_IRQ_LINE_NUM		GENMASK(15, 0)
+
+/* irq_type field */
+#define GZVM_IRQ_TYPE_CPU		0
+#define GZVM_IRQ_TYPE_SPI		1
+#define GZVM_IRQ_TYPE_PPI		2
+
+/* out-of-kernel GIC cpu interrupt injection irq_number field */
+#define GZVM_IRQ_CPU_IRQ		0
+#define GZVM_IRQ_CPU_FIQ		1
+
+struct gzvm_irq_level {
+	union {
+		__u32 irq;
+		__s32 status;
+	};
+	__u32 level;
+};
+
+#define GZVM_IRQ_LINE              _IOW(GZVM_IOC_MAGIC,  0x61, \
+					struct gzvm_irq_level)
+
+enum gzvm_device_type {
+	GZVM_DEV_TYPE_ARM_VGIC_V3_DIST = 0,
+	GZVM_DEV_TYPE_ARM_VGIC_V3_REDIST = 1,
+	GZVM_DEV_TYPE_MAX,
+};
+
+/**
+ * struct gzvm_create_device: For GZVM_CREATE_DEVICE.
+ * @dev_type: Device type.
+ * @id: Device id.
+ * @flags: Bypass to hypervisor to handle them and these are flags of virtual
+ *         devices.
+ * @dev_addr: Device ipa address in VM's view.
+ * @dev_reg_size: Device register range size.
+ * @attr_addr: If user -> kernel, this is user virtual address of device
+ *             specific attributes (if needed). If kernel->hypervisor,
+ *             this is ipa.
+ * @attr_size: This attr_size is the buffer size in bytes of each attribute
+ *             needed from various devices. The attribute here refers to the
+ *             additional data passed from VMM(e.g. Crosvm) to GenieZone
+ *             hypervisor when virtual devices were to be created. Thus,
+ *             we need attr_addr and attr_size in the gzvm_create_device
+ *             structure to keep track of the attribute mentioned.
+ *
+ * Store information needed to create device.
+ */
+struct gzvm_create_device {
+	__u32 dev_type;
+	__u32 id;
+	__u64 flags;
+	__u64 dev_addr;
+	__u64 dev_reg_size;
+	__u64 attr_addr;
+	__u64 attr_size;
+};
+
+#define GZVM_CREATE_DEVICE	   _IOWR(GZVM_IOC_MAGIC,  0xe0, \
+					struct gzvm_create_device)
+
 /*
  * ioctls for vcpu fds
  */
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:43 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:43 +0800
Subject: [PATCH v8 16/20] virt: geniezone: Add memory pin/unpin support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-17-yi-de.wu@mediatek.com>

From: "Jerry Wang" <ze-yu.wang at mediatek.com>

Protected VM's memory cannot be swapped out because the memory pages are
protected from host access.

Once host accesses to those protected pages, the hardware exception is
triggered and may crash the host. So, we have to make those protected
pages be ineligible for swapping or merging by the host kernel to avoid
host access. To do so, we pin the page when it is assigned (donated) to
VM and unpin when VM relinquish the pages or is destroyed. Besides, the
protected VM?s memory requires hypervisor to clear the content before
returning to host, but VMM may free those memory before clearing, it
will result in those memory pages are reclaimed and reused before
totally clearing. Using pin/unpin can also avoid the above problems.

The implementation is described as follows.
- Use rb_tree to store pinned memory pages.
- Pin the page when handling page fault.
- Unpin the pages when VM relinquish the pages or is destroyed.

Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 drivers/virt/geniezone/gzvm_mmu.c | 74 ++++++++++++++++++++++++++++++-
 drivers/virt/geniezone/gzvm_vm.c  | 21 +++++++++
 include/linux/gzvm_drv.h          | 12 +++++
 3 files changed, 106 insertions(+), 1 deletion(-)

diff --git a/drivers/virt/geniezone/gzvm_mmu.c b/drivers/virt/geniezone/gzvm_mmu.c
index 1f8471509be2..857cc68f76dc 100644
--- a/drivers/virt/geniezone/gzvm_mmu.c
+++ b/drivers/virt/geniezone/gzvm_mmu.c
@@ -107,8 +107,73 @@ int gzvm_gfn_to_pfn_memslot(struct gzvm_memslot *memslot, u64 gfn,
 	return 0;
 }
 
+static int cmp_ppages(struct rb_node *node, const struct rb_node *parent)
+{
+	struct gzvm_pinned_page *a = container_of(node,
+						  struct gzvm_pinned_page,
+						  node);
+	struct gzvm_pinned_page *b = container_of(parent,
+						  struct gzvm_pinned_page,
+						  node);
+
+	if (a->ipa < b->ipa)
+		return -1;
+	if (a->ipa > b->ipa)
+		return 1;
+	return 0;
+}
+
+static int rb_ppage_cmp(const void *key, const struct rb_node *node)
+{
+	struct gzvm_pinned_page *p = container_of(node,
+						  struct gzvm_pinned_page,
+						  node);
+	phys_addr_t ipa = (phys_addr_t)key;
+
+	return (ipa < p->ipa) ? -1 : (ipa > p->ipa);
+}
+
+/* Invoker of this function is responsible for locking */
+static int gzvm_insert_ppage(struct gzvm *vm, struct gzvm_pinned_page *ppage)
+{
+	if (rb_find_add(&ppage->node, &vm->pinned_pages, cmp_ppages))
+		return -EEXIST;
+	return 0;
+}
+
+static int pin_one_page(struct gzvm *vm, unsigned long hva, u64 gpa)
+{
+	unsigned int flags = FOLL_HWPOISON | FOLL_LONGTERM | FOLL_WRITE;
+	struct gzvm_pinned_page *ppage = NULL;
+	struct mm_struct *mm = current->mm;
+	struct page *page = NULL;
+
+	ppage = kmalloc(sizeof(*ppage), GFP_KERNEL_ACCOUNT);
+	if (!ppage)
+		return -ENOMEM;
+
+	mmap_read_lock(mm);
+	pin_user_pages(hva, 1, flags, &page);
+	mmap_read_unlock(mm);
+
+	if (!page) {
+		kfree(ppage);
+		return -EFAULT;
+	}
+
+	ppage->page = page;
+	ppage->ipa = gpa;
+
+	mutex_lock(&vm->mem_lock);
+	gzvm_insert_ppage(vm, ppage);
+	mutex_unlock(&vm->mem_lock);
+
+	return 0;
+}
+
 static int handle_block_demand_page(struct gzvm *vm, int memslot_id, u64 gfn)
 {
+	unsigned long hva;
 	u64 pfn, __gfn;
 	int ret, i;
 
@@ -131,6 +196,11 @@ static int handle_block_demand_page(struct gzvm *vm, int memslot_id, u64 gfn)
 			goto err_unlock;
 		}
 		vm->demand_page_buffer[i] = pfn;
+
+		hva = gzvm_gfn_to_hva_memslot(&vm->memslot[memslot_id], __gfn);
+		ret = pin_one_page(vm, hva, PFN_PHYS(__gfn));
+		if (ret)
+			goto err_unlock;
 	}
 
 	ret = gzvm_arch_map_guest_block(vm->vm_id, memslot_id, start_gfn,
@@ -148,6 +218,7 @@ static int handle_block_demand_page(struct gzvm *vm, int memslot_id, u64 gfn)
 
 static int handle_single_demand_page(struct gzvm *vm, int memslot_id, u64 gfn)
 {
+	unsigned long hva;
 	int ret;
 	u64 pfn;
 
@@ -159,7 +230,8 @@ static int handle_single_demand_page(struct gzvm *vm, int memslot_id, u64 gfn)
 	if (unlikely(ret))
 		return -EFAULT;
 
-	return 0;
+	hva = gzvm_gfn_to_hva_memslot(&vm->memslot[memslot_id], gfn);
+	return pin_one_page(vm, hva, PFN_PHYS(gfn));
 }
 
 /**
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index 485d1e2097aa..1af78f161eb3 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -292,6 +292,22 @@ static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 	return ret;
 }
 
+/* Invoker of this function is responsible for locking */
+static void gzvm_destroy_all_ppage(struct gzvm *gzvm)
+{
+	struct gzvm_pinned_page *ppage;
+	struct rb_node *node;
+
+	node = rb_first(&gzvm->pinned_pages);
+	while (node) {
+		ppage = rb_entry(node, struct gzvm_pinned_page, node);
+		unpin_user_pages_dirty_lock(&ppage->page, 1, true);
+		node = rb_next(node);
+		rb_erase(&ppage->node, &gzvm->pinned_pages);
+		kfree(ppage);
+	}
+}
+
 static void gzvm_destroy_vm(struct gzvm *gzvm)
 {
 	size_t allocated_size;
@@ -315,6 +331,9 @@ static void gzvm_destroy_vm(struct gzvm *gzvm)
 
 	mutex_unlock(&gzvm->lock);
 
+	/* No need to lock here becauese it's single-threaded execution */
+	gzvm_destroy_all_ppage(gzvm);
+
 	kfree(gzvm);
 }
 
@@ -390,6 +409,8 @@ static struct gzvm *gzvm_create_vm(unsigned long vm_type)
 	gzvm->vm_id = ret;
 	gzvm->mm = current->mm;
 	mutex_init(&gzvm->lock);
+	mutex_init(&gzvm->mem_lock);
+	gzvm->pinned_pages = RB_ROOT;
 
 	ret = gzvm_vm_irqfd_init(gzvm);
 	if (ret) {
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index 0a8b21e1ed1a..116d1d7c1562 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -12,6 +12,7 @@
 #include <linux/mutex.h>
 #include <linux/gzvm.h>
 #include <linux/srcu.h>
+#include <linux/rbtree.h>
 
 /*
  * For the normal physical address, the highest 12 bits should be zero, so we
@@ -82,6 +83,12 @@ struct gzvm_vcpu {
 	struct gzvm_vcpu_hwstate *hwstate;
 };
 
+struct gzvm_pinned_page {
+	struct rb_node node;
+	struct page *page;
+	u64 ipa;
+};
+
 struct gzvm {
 	struct gzvm_vcpu *vcpus[GZVM_MAX_VCPUS];
 	/* userspace tied to this vm */
@@ -121,6 +128,11 @@ struct gzvm {
 	 * at the same time
 	 */
 	struct mutex  demand_paging_lock;
+
+	/* Use rb-tree to record pin/unpin page */
+	struct rb_root pinned_pages;
+	/* lock for memory operations */
+	struct mutex mem_lock;
 };
 
 long gzvm_dev_ioctl_check_extension(struct gzvm *gzvm, unsigned long args);
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:39 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:39 +0800
Subject: [PATCH v8 12/20] virt: geniezone: Add memory region support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-13-yi-de.wu@mediatek.com>

From: "Jerry Wang" <ze-yu.wang at mediatek.com>

Hypervisor might need to know the precise purpose of each memory
region, so that it can provide specific memory protection. We add a new
uapi to pass address and size of a memory region and its purpose.

Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: Liju-clr Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/gzvm_arch_common.h |  2 ++
 arch/arm64/geniezone/vm.c               | 10 ++++++++++
 drivers/virt/geniezone/gzvm_vm.c        |  7 +++++++
 include/linux/gzvm_drv.h                |  3 +++
 4 files changed, 22 insertions(+)

diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index 67c7864c3afc..8d1406beeaed 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -22,6 +22,7 @@ enum {
 	GZVM_FUNC_PROBE = 12,
 	GZVM_FUNC_ENABLE_CAP = 13,
 	GZVM_FUNC_INFORM_EXIT = 14,
+	GZVM_FUNC_MEMREGION_PURPOSE = 15,
 	NR_GZVM_FUNC,
 };
 
@@ -44,6 +45,7 @@ enum {
 #define MT_HVC_GZVM_PROBE		GZVM_HCALL_ID(GZVM_FUNC_PROBE)
 #define MT_HVC_GZVM_ENABLE_CAP		GZVM_HCALL_ID(GZVM_FUNC_ENABLE_CAP)
 #define MT_HVC_GZVM_INFORM_EXIT		GZVM_HCALL_ID(GZVM_FUNC_INFORM_EXIT)
+#define MT_HVC_GZVM_MEMREGION_PURPOSE	GZVM_HCALL_ID(GZVM_FUNC_MEMREGION_PURPOSE)
 
 #define GIC_V3_NR_LRS			16
 
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index 0afdb49b71f5..210f7569d7cc 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -130,6 +130,16 @@ int gzvm_arch_destroy_vm(u16 vm_id)
 				    0, 0, &res);
 }
 
+int gzvm_arch_memregion_purpose(struct gzvm *gzvm,
+				struct gzvm_userspace_memory_region *mem)
+{
+	struct arm_smccc_res res;
+
+	return gzvm_hypcall_wrapper(MT_HVC_GZVM_MEMREGION_PURPOSE, gzvm->vm_id,
+				    mem->guest_phys_addr, mem->memory_size,
+				    mem->flags, 0, 0, 0, &res);
+}
+
 static int gzvm_vm_arch_enable_cap(struct gzvm *gzvm,
 				   struct gzvm_enable_cap *cap,
 				   struct arm_smccc_res *res)
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index d67bf647b615..4134605cbf7d 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -72,6 +72,7 @@ static int
 gzvm_vm_ioctl_set_memory_region(struct gzvm *gzvm,
 				struct gzvm_userspace_memory_region *mem)
 {
+	int ret;
 	struct vm_area_struct *vma;
 	struct gzvm_memslot *memslot;
 	unsigned long size;
@@ -96,6 +97,12 @@ gzvm_vm_ioctl_set_memory_region(struct gzvm *gzvm,
 	memslot->vma = vma;
 	memslot->flags = mem->flags;
 	memslot->slot_id = mem->slot;
+
+	ret = gzvm_arch_memregion_purpose(gzvm, mem);
+	if (ret) {
+		pr_err("Failed to config memory region for the specified purpose\n");
+		return -EFAULT;
+	}
 	return register_memslot_addr_range(gzvm, memslot);
 }
 
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index 406bc9f821b2..d35ca179b688 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -152,6 +152,9 @@ void gzvm_drv_irqfd_exit(void);
 int gzvm_vm_irqfd_init(struct gzvm *gzvm);
 void gzvm_vm_irqfd_release(struct gzvm *gzvm);
 
+int gzvm_arch_memregion_purpose(struct gzvm *gzvm,
+				struct gzvm_userspace_memory_region *mem);
+
 int gzvm_init_ioeventfd(struct gzvm *gzvm);
 int gzvm_ioeventfd(struct gzvm *gzvm, struct gzvm_ioeventfd *args);
 bool gzvm_ioevent_write(struct gzvm_vcpu *vcpu, __u64 addr, int len,
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:32 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:32 +0800
Subject: [PATCH v8 05/20] virt: geniezone: Add set_user_memory_region for vm
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-6-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

Direct use of physical memory from VMs is forbidden and designed to be
dictated to the privilege models managed by GenieZone hypervisor for
security reason. With the help of gzvm-ko, the hypervisor would be able
to manipulate memory as objects. And the memory management is highly
integrated with ARM 2-stage translation tables to convert VA to IPA to
PA under proper security measures required by protected VMs.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/gzvm_arch_common.h |   2 +
 arch/arm64/geniezone/vm.c               |   9 ++
 drivers/virt/geniezone/Makefile         |   1 -
 drivers/virt/geniezone/gzvm_vm.c        | 110 ++++++++++++++++++++++++
 include/linux/gzvm_drv.h                |  44 ++++++++++
 include/uapi/linux/gzvm.h               |  26 ++++++
 6 files changed, 191 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index fdaa7849353d..2f66e496dfae 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -11,6 +11,7 @@
 enum {
 	GZVM_FUNC_CREATE_VM = 0,
 	GZVM_FUNC_DESTROY_VM = 1,
+	GZVM_FUNC_SET_MEMREGION = 4,
 	GZVM_FUNC_PROBE = 12,
 	NR_GZVM_FUNC,
 };
@@ -23,6 +24,7 @@ enum {
 
 #define MT_HVC_GZVM_CREATE_VM		GZVM_HCALL_ID(GZVM_FUNC_CREATE_VM)
 #define MT_HVC_GZVM_DESTROY_VM		GZVM_HCALL_ID(GZVM_FUNC_DESTROY_VM)
+#define MT_HVC_GZVM_SET_MEMREGION	GZVM_HCALL_ID(GZVM_FUNC_SET_MEMREGION)
 #define MT_HVC_GZVM_PROBE		GZVM_HCALL_ID(GZVM_FUNC_PROBE)
 
 /**
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index a15bad13c2ee..998d6498ac5e 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -49,6 +49,15 @@ int gzvm_arch_probe(void)
 	return 0;
 }
 
+int gzvm_arch_set_memregion(u16 vm_id, size_t buf_size,
+			    phys_addr_t region)
+{
+	struct arm_smccc_res res;
+
+	return gzvm_hypcall_wrapper(MT_HVC_GZVM_SET_MEMREGION, vm_id,
+				    buf_size, region, 0, 0, 0, 0, &res);
+}
+
 /**
  * gzvm_arch_create_vm() - create vm
  * @vm_type: VM type. Only supports Linux VM now.
diff --git a/drivers/virt/geniezone/Makefile b/drivers/virt/geniezone/Makefile
index 066efddc0b9c..25614ea3dea2 100644
--- a/drivers/virt/geniezone/Makefile
+++ b/drivers/virt/geniezone/Makefile
@@ -7,4 +7,3 @@
 GZVM_DIR ?= ../../../drivers/virt/geniezone
 
 gzvm-y := $(GZVM_DIR)/gzvm_main.o $(GZVM_DIR)/gzvm_vm.o
-
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index d5e850af924a..326cc9e93d92 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -15,6 +15,115 @@
 static DEFINE_MUTEX(gzvm_list_lock);
 static LIST_HEAD(gzvm_list);
 
+u64 gzvm_gfn_to_hva_memslot(struct gzvm_memslot *memslot, u64 gfn)
+{
+	u64 offset = gfn - memslot->base_gfn;
+
+	return memslot->userspace_addr + offset * PAGE_SIZE;
+}
+
+/**
+ * register_memslot_addr_range() - Register memory region to GenieZone
+ * @gzvm: Pointer to struct gzvm
+ * @memslot: Pointer to struct gzvm_memslot
+ *
+ * Return: 0 for success, negative number for error
+ */
+static int
+register_memslot_addr_range(struct gzvm *gzvm, struct gzvm_memslot *memslot)
+{
+	struct gzvm_memory_region_ranges *region;
+	u32 buf_size = PAGE_SIZE * 2;
+	u64 gfn;
+
+	region = alloc_pages_exact(buf_size, GFP_KERNEL);
+	if (!region)
+		return -ENOMEM;
+
+	region->slot = memslot->slot_id;
+	region->total_pages = memslot->npages;
+	gfn = memslot->base_gfn;
+	region->gpa = PFN_PHYS(gfn);
+
+	if (gzvm_arch_set_memregion(gzvm->vm_id, buf_size,
+				    virt_to_phys(region))) {
+		pr_err("Failed to register memregion to hypervisor\n");
+		free_pages_exact(region, buf_size);
+		return -EFAULT;
+	}
+
+	free_pages_exact(region, buf_size);
+	return 0;
+}
+
+/**
+ * gzvm_vm_ioctl_set_memory_region() - Set memory region of guest
+ * @gzvm: Pointer to struct gzvm.
+ * @mem: Input memory region from user.
+ *
+ * Return: 0 for success, negative number for error
+ *
+ * -EXIO		- The memslot is out-of-range
+ * -EFAULT		- Cannot find corresponding vma
+ * -EINVAL		- Region size and VMA size mismatch
+ */
+static int
+gzvm_vm_ioctl_set_memory_region(struct gzvm *gzvm,
+				struct gzvm_userspace_memory_region *mem)
+{
+	struct vm_area_struct *vma;
+	struct gzvm_memslot *memslot;
+	unsigned long size;
+	__u32 slot;
+
+	slot = mem->slot;
+	if (slot >= GZVM_MAX_MEM_REGION)
+		return -ENXIO;
+	memslot = &gzvm->memslot[slot];
+
+	vma = vma_lookup(gzvm->mm, mem->userspace_addr);
+	if (!vma)
+		return -EFAULT;
+
+	size = vma->vm_end - vma->vm_start;
+	if (size != mem->memory_size)
+		return -EINVAL;
+
+	memslot->base_gfn = __phys_to_pfn(mem->guest_phys_addr);
+	memslot->npages = size >> PAGE_SHIFT;
+	memslot->userspace_addr = mem->userspace_addr;
+	memslot->vma = vma;
+	memslot->flags = mem->flags;
+	memslot->slot_id = mem->slot;
+	return register_memslot_addr_range(gzvm, memslot);
+}
+
+/* gzvm_vm_ioctl() - Ioctl handler of VM FD */
+static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
+			  unsigned long arg)
+{
+	long ret;
+	void __user *argp = (void __user *)arg;
+	struct gzvm *gzvm = filp->private_data;
+
+	switch (ioctl) {
+	case GZVM_SET_USER_MEMORY_REGION: {
+		struct gzvm_userspace_memory_region userspace_mem;
+
+		if (copy_from_user(&userspace_mem, argp, sizeof(userspace_mem))) {
+			ret = -EFAULT;
+			goto out;
+		}
+		ret = gzvm_vm_ioctl_set_memory_region(gzvm, &userspace_mem);
+		break;
+	}
+	default:
+		ret = -ENOTTY;
+	}
+out:
+	return ret;
+}
+
 static void gzvm_destroy_vm(struct gzvm *gzvm)
 {
 	pr_debug("VM-%u is going to be destroyed\n", gzvm->vm_id);
@@ -42,6 +151,7 @@ static int gzvm_vm_release(struct inode *inode, struct file *filp)
 
 static const struct file_operations gzvm_vm_fops = {
 	.release        = gzvm_vm_release,
+	.unlocked_ioctl = gzvm_vm_ioctl,
 	.llseek		= noop_llseek,
 };
 
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index f1dce23838e4..aa1eaf4d43b4 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -7,9 +7,16 @@
 #define __GZVM_DRV_H__
 
 #include <linux/list.h>
+#include <linux/mm.h>
 #include <linux/mutex.h>
 #include <linux/gzvm.h>
 
+/*
+ * For the normal physical address, the highest 12 bits should be zero, so we
+ * can mask bit 62 ~ bit 52 to indicate the error physical address
+ */
+#define GZVM_PA_ERR_BAD (0x7ffULL << 52)
+
 #define INVALID_VM_ID   0xffff
 
 /*
@@ -27,10 +34,39 @@
  * The following data structures are for data transferring between driver and
  * hypervisor, and they're aligned with hypervisor definitions
  */
+#define GZVM_MAX_MEM_REGION	10
+
+/* struct mem_region_addr_range - Identical to ffa memory constituent */
+struct mem_region_addr_range {
+	/* the base IPA of the constituent memory region, aligned to 4 kiB */
+	__u64 address;
+	/* the number of 4 kiB pages in the constituent memory region. */
+	__u32 pg_cnt;
+	__u32 reserved;
+};
+
+struct gzvm_memory_region_ranges {
+	__u32 slot;
+	__u32 constituent_cnt;
+	__u64 total_pages;
+	__u64 gpa;
+	struct mem_region_addr_range constituents[];
+};
+
+/* struct gzvm_memslot - VM's memory slot descriptor */
+struct gzvm_memslot {
+	u64 base_gfn;			/* begin of guest page frame */
+	unsigned long npages;		/* number of pages this slot covers */
+	unsigned long userspace_addr;	/* corresponding userspace va */
+	struct vm_area_struct *vma;	/* vma related to this userspace addr */
+	u32 flags;
+	u32 slot_id;
+};
 
 struct gzvm {
 	/* userspace tied to this vm */
 	struct mm_struct *mm;
+	struct gzvm_memslot memslot[GZVM_MAX_MEM_REGION];
 	/* lock for list_add*/
 	struct mutex lock;
 	struct list_head vm_list;
@@ -45,7 +81,15 @@ void gzvm_destroy_all_vms(void);
 
 /* arch-dependant functions */
 int gzvm_arch_probe(void);
+int gzvm_arch_set_memregion(u16 vm_id, size_t buf_size,
+			    phys_addr_t region);
 int gzvm_arch_create_vm(unsigned long vm_type);
 int gzvm_arch_destroy_vm(u16 vm_id);
 
+u64 gzvm_hva_to_pa_arch(u64 hva);
+u64 hva_to_pa_fast(u64 hva);
+u64 hva_to_pa_slow(u64 hva);
+int gzvm_gfn_to_pfn_memslot(struct gzvm_memslot *memslot, u64 gfn, u64 *pfn);
+u64 gzvm_gfn_to_hva_memslot(struct gzvm_memslot *memslot, u64 gfn);
+
 #endif /* __GZVM_DRV_H__ */
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index c26c7720fab7..d2d5e6cfc2c9 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -22,4 +22,30 @@
 /* ioctls for /dev/gzvm fds */
 #define GZVM_CREATE_VM             _IO(GZVM_IOC_MAGIC,   0x01) /* Returns a Geniezone VM fd */
 
+/* ioctls for VM fds */
+/* for GZVM_SET_MEMORY_REGION */
+struct gzvm_memory_region {
+	__u32 slot;
+	__u32 flags;
+	__u64 guest_phys_addr;
+	__u64 memory_size; /* bytes */
+};
+
+#define GZVM_SET_MEMORY_REGION     _IOW(GZVM_IOC_MAGIC,  0x40, \
+					struct gzvm_memory_region)
+
+/* for GZVM_SET_USER_MEMORY_REGION */
+struct gzvm_userspace_memory_region {
+	__u32 slot;
+	__u32 flags;
+	__u64 guest_phys_addr;
+	/* bytes */
+	__u64 memory_size;
+	/* start of the userspace allocated memory */
+	__u64 userspace_addr;
+};
+
+#define GZVM_SET_USER_MEMORY_REGION _IOW(GZVM_IOC_MAGIC, 0x46, \
+					 struct gzvm_userspace_memory_region)
+
 #endif /* __GZVM_H__ */
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:33 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:33 +0800
Subject: [PATCH v8 06/20] virt: geniezone: Add vm capability check
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-7-yi-de.wu@mediatek.com>

From: "Yingshiuan Pan" <yingshiuan.pan at mediatek.com>

Inquire the `capability support` on GenieZone hypervisor.
Example:
`GZVM_CAP_PROTECTED_VM` or `GZVM_CAP_VM_GPA_SIZE`.

Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: kevenny hsieh <kevenny.hsieh at mediatek.com>
Signed-off-by: Liju Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/gzvm_arch_common.h |   2 +
 arch/arm64/geniezone/vm.c               | 122 ++++++++++++++++++++++++
 drivers/virt/geniezone/gzvm_main.c      |  27 ++++++
 drivers/virt/geniezone/gzvm_vm.c        |  21 ++++
 include/linux/gzvm_drv.h                |   6 +-
 include/uapi/linux/gzvm.h               |  31 ++++++
 6 files changed, 208 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index 2f66e496dfae..383af0829f11 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -13,6 +13,7 @@ enum {
 	GZVM_FUNC_DESTROY_VM = 1,
 	GZVM_FUNC_SET_MEMREGION = 4,
 	GZVM_FUNC_PROBE = 12,
+	GZVM_FUNC_ENABLE_CAP = 13,
 	NR_GZVM_FUNC,
 };
 
@@ -26,6 +27,7 @@ enum {
 #define MT_HVC_GZVM_DESTROY_VM		GZVM_HCALL_ID(GZVM_FUNC_DESTROY_VM)
 #define MT_HVC_GZVM_SET_MEMREGION	GZVM_HCALL_ID(GZVM_FUNC_SET_MEMREGION)
 #define MT_HVC_GZVM_PROBE		GZVM_HCALL_ID(GZVM_FUNC_PROBE)
+#define MT_HVC_GZVM_ENABLE_CAP		GZVM_HCALL_ID(GZVM_FUNC_ENABLE_CAP)
 
 /**
  * gzvm_hypcall_wrapper() - the wrapper for hvc calls
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index 998d6498ac5e..02f94c86fbf1 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -58,6 +58,40 @@ int gzvm_arch_set_memregion(u16 vm_id, size_t buf_size,
 				    buf_size, region, 0, 0, 0, 0, &res);
 }
 
+static int gzvm_cap_vm_gpa_size(void __user *argp)
+{
+	__u64 value = CONFIG_ARM64_PA_BITS;
+
+	if (copy_to_user(argp, &value, sizeof(__u64)))
+		return -EFAULT;
+
+	return 0;
+}
+
+int gzvm_arch_check_extension(struct gzvm *gzvm, __u64 cap, void __user *argp)
+{
+	int ret;
+
+	switch (cap) {
+	case GZVM_CAP_PROTECTED_VM: {
+		__u64 success = 1;
+
+		if (copy_to_user(argp, &success, sizeof(__u64)))
+			return -EFAULT;
+
+		return 0;
+	}
+	case GZVM_CAP_VM_GPA_SIZE: {
+		ret = gzvm_cap_vm_gpa_size(argp);
+		return ret;
+	}
+	default:
+		break;
+	}
+
+	return -EOPNOTSUPP;
+}
+
 /**
  * gzvm_arch_create_vm() - create vm
  * @vm_type: VM type. Only supports Linux VM now.
@@ -83,3 +117,91 @@ int gzvm_arch_destroy_vm(u16 vm_id)
 	return gzvm_hypcall_wrapper(MT_HVC_GZVM_DESTROY_VM, vm_id, 0, 0, 0, 0,
 				    0, 0, &res);
 }
+
+static int gzvm_vm_arch_enable_cap(struct gzvm *gzvm,
+				   struct gzvm_enable_cap *cap,
+				   struct arm_smccc_res *res)
+{
+	return gzvm_hypcall_wrapper(MT_HVC_GZVM_ENABLE_CAP, gzvm->vm_id,
+				    cap->cap, cap->args[0], cap->args[1],
+				    cap->args[2], cap->args[3], cap->args[4],
+				    res);
+}
+
+/**
+ * gzvm_vm_ioctl_get_pvmfw_size() - Get pvmfw size from hypervisor, return
+ *				    in x1, and return to userspace in args
+ * @gzvm: Pointer to struct gzvm.
+ * @cap: Pointer to struct gzvm_enable_cap.
+ * @argp: Pointer to struct gzvm_enable_cap in user space.
+ *
+ * Return:
+ * * 0			- Succeed
+ * * -EINVAL		- Hypervisor return invalid results
+ * * -EFAULT		- Fail to copy back to userspace buffer
+ */
+static int gzvm_vm_ioctl_get_pvmfw_size(struct gzvm *gzvm,
+					struct gzvm_enable_cap *cap,
+					void __user *argp)
+{
+	struct arm_smccc_res res = {0};
+
+	if (gzvm_vm_arch_enable_cap(gzvm, cap, &res) != 0)
+		return -EINVAL;
+
+	cap->args[1] = res.a1;
+	if (copy_to_user(argp, cap, sizeof(*cap)))
+		return -EFAULT;
+
+	return 0;
+}
+
+/**
+ * gzvm_vm_ioctl_cap_pvm() - Proceed GZVM_CAP_PROTECTED_VM's subcommands
+ * @gzvm: Pointer to struct gzvm.
+ * @cap: Pointer to struct gzvm_enable_cap.
+ * @argp: Pointer to struct gzvm_enable_cap in user space.
+ *
+ * Return:
+ * * 0			- Succeed
+ * * -EINVAL		- Invalid subcommand or arguments
+ */
+static int gzvm_vm_ioctl_cap_pvm(struct gzvm *gzvm,
+				 struct gzvm_enable_cap *cap,
+				 void __user *argp)
+{
+	struct arm_smccc_res res = {0};
+	int ret;
+
+	switch (cap->args[0]) {
+	case GZVM_CAP_PVM_SET_PVMFW_GPA:
+		fallthrough;
+	case GZVM_CAP_PVM_SET_PROTECTED_VM:
+		ret = gzvm_vm_arch_enable_cap(gzvm, cap, &res);
+		return ret;
+	case GZVM_CAP_PVM_GET_PVMFW_SIZE:
+		ret = gzvm_vm_ioctl_get_pvmfw_size(gzvm, cap, argp);
+		return ret;
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+int gzvm_vm_ioctl_arch_enable_cap(struct gzvm *gzvm,
+				  struct gzvm_enable_cap *cap,
+				  void __user *argp)
+{
+	int ret;
+
+	switch (cap->cap) {
+	case GZVM_CAP_PROTECTED_VM:
+		ret = gzvm_vm_ioctl_cap_pvm(gzvm, cap, argp);
+		return ret;
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
diff --git a/drivers/virt/geniezone/gzvm_main.c b/drivers/virt/geniezone/gzvm_main.c
index 4e7d60067c55..30f6c3975026 100644
--- a/drivers/virt/geniezone/gzvm_main.c
+++ b/drivers/virt/geniezone/gzvm_main.c
@@ -41,6 +41,28 @@ int gzvm_err_to_errno(unsigned long err)
 	return -EINVAL;
 }
 
+/**
+ * gzvm_dev_ioctl_check_extension() - Check if given capability is support
+ *				      or not
+ *
+ * @gzvm: Pointer to struct gzvm
+ * @args: Pointer in u64 from userspace
+ *
+ * Return:
+ * * 0			- Supported, no error
+ * * -EOPNOTSUPP	- Unsupported
+ * * -EFAULT		- Failed to get data from userspace
+ */
+long gzvm_dev_ioctl_check_extension(struct gzvm *gzvm, unsigned long args)
+{
+	__u64 cap;
+	void __user *argp = (void __user *)args;
+
+	if (copy_from_user(&cap, argp, sizeof(uint64_t)))
+		return -EFAULT;
+	return gzvm_arch_check_extension(gzvm, cap, argp);
+}
+
 static long gzvm_dev_ioctl(struct file *filp, unsigned int cmd,
 			   unsigned long user_args)
 {
@@ -50,6 +72,11 @@ static long gzvm_dev_ioctl(struct file *filp, unsigned int cmd,
 	case GZVM_CREATE_VM:
 		ret = gzvm_dev_ioctl_create_vm(user_args);
 		return ret;
+	case GZVM_CHECK_EXTENSION:
+		if (!user_args)
+			return -EINVAL;
+		ret = gzvm_dev_ioctl_check_extension(NULL, user_args);
+		return ret;
 	default:
 		break;
 	}
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index 326cc9e93d92..ba6bfb7ee6e5 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -98,6 +98,13 @@ gzvm_vm_ioctl_set_memory_region(struct gzvm *gzvm,
 	return register_memslot_addr_range(gzvm, memslot);
 }
 
+static int gzvm_vm_ioctl_enable_cap(struct gzvm *gzvm,
+				    struct gzvm_enable_cap *cap,
+				    void __user *argp)
+{
+	return gzvm_vm_ioctl_arch_enable_cap(gzvm, cap, argp);
+}
+
 /* gzvm_vm_ioctl() - Ioctl handler of VM FD */
 static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 			  unsigned long arg)
@@ -107,6 +114,10 @@ static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 	struct gzvm *gzvm = filp->private_data;
 
 	switch (ioctl) {
+	case GZVM_CHECK_EXTENSION: {
+		ret = gzvm_dev_ioctl_check_extension(gzvm, arg);
+		break;
+	}
 	case GZVM_SET_USER_MEMORY_REGION: {
 		struct gzvm_userspace_memory_region userspace_mem;
 
@@ -117,6 +128,16 @@ static long gzvm_vm_ioctl(struct file *filp, unsigned int ioctl,
 		ret = gzvm_vm_ioctl_set_memory_region(gzvm, &userspace_mem);
 		break;
 	}
+	case GZVM_ENABLE_CAP: {
+		struct gzvm_enable_cap cap;
+
+		if (copy_from_user(&cap, argp, sizeof(cap))) {
+			ret = -EFAULT;
+			goto out;
+		}
+		ret = gzvm_vm_ioctl_enable_cap(gzvm, &cap, argp);
+		break;
+	}
 	default:
 		ret = -ENOTTY;
 	}
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index aa1eaf4d43b4..a7d6df29b34e 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -73,6 +73,7 @@ struct gzvm {
 	u16 vm_id;
 };
 
+long gzvm_dev_ioctl_check_extension(struct gzvm *gzvm, unsigned long args);
 int gzvm_dev_ioctl_create_vm(unsigned long vm_type);
 
 int gzvm_err_to_errno(unsigned long err);
@@ -83,9 +84,12 @@ void gzvm_destroy_all_vms(void);
 int gzvm_arch_probe(void);
 int gzvm_arch_set_memregion(u16 vm_id, size_t buf_size,
 			    phys_addr_t region);
+int gzvm_arch_check_extension(struct gzvm *gzvm, __u64 cap, void __user *argp);
 int gzvm_arch_create_vm(unsigned long vm_type);
 int gzvm_arch_destroy_vm(u16 vm_id);
-
+int gzvm_vm_ioctl_arch_enable_cap(struct gzvm *gzvm,
+				  struct gzvm_enable_cap *cap,
+				  void __user *argp);
 u64 gzvm_hva_to_pa_arch(u64 hva);
 u64 hva_to_pa_fast(u64 hva);
 u64 hva_to_pa_slow(u64 hva);
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index d2d5e6cfc2c9..77a58ee085df 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -16,12 +16,30 @@
 #include <linux/types.h>
 #include <linux/ioctl.h>
 
+#define GZVM_CAP_VM_GPA_SIZE	0xa5
+#define GZVM_CAP_PROTECTED_VM	0xffbadab1
+
+/* sub-commands put in args[0] for GZVM_CAP_PROTECTED_VM */
+#define GZVM_CAP_PVM_SET_PVMFW_GPA		0
+#define GZVM_CAP_PVM_GET_PVMFW_SIZE		1
+/* GZVM_CAP_PVM_SET_PROTECTED_VM only sets protected but not load pvmfw */
+#define GZVM_CAP_PVM_SET_PROTECTED_VM		2
+
 /* GZVM ioctls */
 #define GZVM_IOC_MAGIC			0x92	/* gz */
 
 /* ioctls for /dev/gzvm fds */
 #define GZVM_CREATE_VM             _IO(GZVM_IOC_MAGIC,   0x01) /* Returns a Geniezone VM fd */
 
+/*
+ * Check if the given capability is supported or not.
+ * The argument is capability. Ex. GZVM_CAP_PROTECTED_VM or GZVM_CAP_VM_GPA_SIZE
+ * return is 0 (supported, no error)
+ * return is -EOPNOTSUPP (unsupported)
+ * return is -EFAULT (failed to get the argument from userspace)
+ */
+#define GZVM_CHECK_EXTENSION       _IO(GZVM_IOC_MAGIC,   0x03)
+
 /* ioctls for VM fds */
 /* for GZVM_SET_MEMORY_REGION */
 struct gzvm_memory_region {
@@ -48,4 +66,17 @@ struct gzvm_userspace_memory_region {
 #define GZVM_SET_USER_MEMORY_REGION _IOW(GZVM_IOC_MAGIC, 0x46, \
 					 struct gzvm_userspace_memory_region)
 
+/**
+ * struct gzvm_enable_cap: The `capability support` on GenieZone hypervisor
+ * @cap: `GZVM_CAP_ARM_PROTECTED_VM` or `GZVM_CAP_ARM_VM_IPA_SIZE`
+ * @args: x3-x7 registers can be used for additional args
+ */
+struct gzvm_enable_cap {
+	__u64 cap;
+	__u64 args[5];
+};
+
+#define GZVM_ENABLE_CAP            _IOW(GZVM_IOC_MAGIC,  0xa3, \
+					struct gzvm_enable_cap)
+
 #endif /* __GZVM_H__ */
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:44 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:44 +0800
Subject: [PATCH v8 17/20] virt: geniezone: Add memory relinquish support
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-18-yi-de.wu@mediatek.com>

From: "Jerry Wang" <ze-yu.wang at mediatek.com>

Unpin the pages when VM relinquish the pages or is destroyed.

Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: Yingshiuan Pan <yingshiuan.pan at mediatek.com>
Signed-off-by: Liju-Clr Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 drivers/virt/geniezone/gzvm_exception.c | 23 +++++++++++++++
 drivers/virt/geniezone/gzvm_mmu.c       | 39 +++++++++++++++++++++++++
 drivers/virt/geniezone/gzvm_vcpu.c      |  6 ++--
 include/linux/gzvm_drv.h                |  2 ++
 include/uapi/linux/gzvm.h               |  5 ++++
 5 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/drivers/virt/geniezone/gzvm_exception.c b/drivers/virt/geniezone/gzvm_exception.c
index 31fdb4ae8db4..af26d1c82791 100644
--- a/drivers/virt/geniezone/gzvm_exception.c
+++ b/drivers/virt/geniezone/gzvm_exception.c
@@ -37,3 +37,26 @@ bool gzvm_handle_guest_exception(struct gzvm_vcpu *vcpu)
 	else
 		return false;
 }
+
+/**
+ * gzvm_handle_guest_hvc() - Handle guest hvc
+ * @vcpu: Pointer to struct gzvm_vcpu struct
+ * Return:
+ * * true - This hvc has been processed, no need to back to VMM.
+ * * false - This hvc has not been processed, require userspace.
+ */
+bool gzvm_handle_guest_hvc(struct gzvm_vcpu *vcpu)
+{
+	unsigned long ipa;
+	int ret;
+
+	switch (vcpu->run->hypercall.args[0]) {
+	case GZVM_HVC_MEM_RELINQUISH:
+		ipa = vcpu->run->hypercall.args[1];
+		ret = gzvm_handle_relinquish(vcpu, ipa);
+		return (ret == 0) ? true : false;
+	default:
+		break;
+	}
+	return false;
+}
diff --git a/drivers/virt/geniezone/gzvm_mmu.c b/drivers/virt/geniezone/gzvm_mmu.c
index 857cc68f76dc..ab0afec48381 100644
--- a/drivers/virt/geniezone/gzvm_mmu.c
+++ b/drivers/virt/geniezone/gzvm_mmu.c
@@ -141,6 +141,26 @@ static int gzvm_insert_ppage(struct gzvm *vm, struct gzvm_pinned_page *ppage)
 	return 0;
 }
 
+/* Invoker of this function is responsible for locking */
+static int gzvm_remove_ppage(struct gzvm *vm, phys_addr_t ipa)
+{
+	struct gzvm_pinned_page *ppage;
+	struct rb_node *node;
+
+	node = rb_find((void *)ipa, &vm->pinned_pages, rb_ppage_cmp);
+
+	if (node)
+		rb_erase(node, &vm->pinned_pages);
+	else
+		return 0;
+
+	ppage = container_of(node, struct gzvm_pinned_page, node);
+	unpin_user_pages_dirty_lock(&ppage->page, 1, true);
+	kfree(ppage);
+
+	return 0;
+}
+
 static int pin_one_page(struct gzvm *vm, unsigned long hva, u64 gpa)
 {
 	unsigned int flags = FOLL_HWPOISON | FOLL_LONGTERM | FOLL_WRITE;
@@ -171,6 +191,25 @@ static int pin_one_page(struct gzvm *vm, unsigned long hva, u64 gpa)
 	return 0;
 }
 
+/**
+ * gzvm_handle_relinquish() - Handle memory relinquish request from hypervisor
+ *
+ * @vcpu: Pointer to struct gzvm_vcpu_run in userspace
+ * @ipa: Start address(gpa) of a reclaimed page
+ *
+ * Return: Always return 0 because there are no cases of failure
+ */
+int gzvm_handle_relinquish(struct gzvm_vcpu *vcpu, phys_addr_t ipa)
+{
+	struct gzvm *vm = vcpu->gzvm;
+
+	mutex_lock(&vm->mem_lock);
+	gzvm_remove_ppage(vm, ipa);
+	mutex_unlock(&vm->mem_lock);
+
+	return 0;
+}
+
 static int handle_block_demand_page(struct gzvm *vm, int memslot_id, u64 gfn)
 {
 	unsigned long hva;
diff --git a/drivers/virt/geniezone/gzvm_vcpu.c b/drivers/virt/geniezone/gzvm_vcpu.c
index 455ae2e4285c..86c690749277 100644
--- a/drivers/virt/geniezone/gzvm_vcpu.c
+++ b/drivers/virt/geniezone/gzvm_vcpu.c
@@ -113,12 +113,14 @@ static long gzvm_vcpu_run(struct gzvm_vcpu *vcpu, void __user *argp)
 		 * it's geniezone's responsibility to fill corresponding data
 		 * structure
 		 */
+		case GZVM_EXIT_HYPERCALL:
+			if (!gzvm_handle_guest_hvc(vcpu))
+				need_userspace = true;
+			break;
 		case GZVM_EXIT_EXCEPTION:
 			if (!gzvm_handle_guest_exception(vcpu))
 				need_userspace = true;
 			break;
-		case GZVM_EXIT_HYPERCALL:
-			fallthrough;
 		case GZVM_EXIT_DEBUG:
 			fallthrough;
 		case GZVM_EXIT_FAIL_ENTRY:
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index 116d1d7c1562..17f5fb9d843d 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -175,6 +175,8 @@ int gzvm_arch_inform_exit(u16 vm_id);
 int gzvm_find_memslot(struct gzvm *vm, u64 gpa);
 int gzvm_handle_page_fault(struct gzvm_vcpu *vcpu);
 bool gzvm_handle_guest_exception(struct gzvm_vcpu *vcpu);
+int gzvm_handle_relinquish(struct gzvm_vcpu *vcpu, phys_addr_t ipa);
+bool gzvm_handle_guest_hvc(struct gzvm_vcpu *vcpu);
 
 int gzvm_arch_create_device(u16 vm_id, struct gzvm_create_device *gzvm_dev);
 int gzvm_arch_inject_irq(struct gzvm *gzvm, unsigned int vcpu_idx,
diff --git a/include/uapi/linux/gzvm.h b/include/uapi/linux/gzvm.h
index f858b04bf7b9..a98787a18c36 100644
--- a/include/uapi/linux/gzvm.h
+++ b/include/uapi/linux/gzvm.h
@@ -193,6 +193,11 @@ enum {
 	GZVM_EXCEPTION_PAGE_FAULT = 0x1,
 };
 
+/* hypercall definitions of GZVM_EXIT_HYPERCALL */
+enum {
+	GZVM_HVC_MEM_RELINQUISH = 0xc6000009,
+};
+
 /**
  * struct gzvm_vcpu_run: Same purpose as kvm_run, this struct is
  *			shared between userspace, kernel and
-- 
2.18.0



From yuanhsinte at chromium.org  Thu Dec 28 02:57:01 2023
From: yuanhsinte at chromium.org (Hsin-Te Yuan)
Date: Thu, 28 Dec 2023 18:57:01 +0800
Subject: [PATCH RESEND v2] arm64: dts: mt8195-cherry-tomato: change watchdog reset boot flow
Message-ID: <20231228105717.719624-1-yuanhsinte@chromium.org>

The external output reset signal was originally disabled and sent from
firmware. However, an unfixed bug in the firmware on tomato prevents
the signal from being sent, causing the device to fail to boot. To fix
this, enable external output reset signal to allow the device to reboot
normally.

Signed-off-by: Hsin-Te Yuan <yuanhsinte at chromium.org>

---

Changes in v2:
- Limit the effect only on tomato.

---
 arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts | 4 ++++
 3 files changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts
index 2d5e8f371b6d..a82d716f10d4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts
@@ -23,3 +23,7 @@ &sound {
 &ts_10 {
 	status = "okay";
 };
+
+&watchdog {
+	/delete-property/ mediatek,disable-extrst;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts
index 2586c32ce6e6..2fe20e0dad83 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts
@@ -43,3 +43,7 @@ &sound {
 &ts_10 {
 	status = "okay";
 };
+
+&watchdog {
+	/delete-property/ mediatek,disable-extrst;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts
index f54f9477b99d..dd294ca98194 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts
@@ -44,3 +44,7 @@ &sound {
 &ts_10 {
 	status = "okay";
 };
+
+&watchdog {
+	/delete-property/ mediatek,disable-extrst;
+};
-- 
2.43.0.472.g3155946c3a-goog



From xu.yang_2 at nxp.com  Thu Dec 28 03:07:51 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 28 Dec 2023 19:07:51 +0800
Subject: [PATCH v3 1/3] usb: chipidea: ci_hdrc_imx: add wakeup clock and keep it always on
Message-ID: <20231228110753.1755756-1-xu.yang_2@nxp.com>

Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
on without usb driver intervention. And some may need driver to handle
this clock. For now only i.MX93 needs this wakeup clock. This patch will
get wakeup clock and keep it always on to make controller work properly.

Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
Acked-by: Peter Chen <peter.chen at kernel.org>

---
Changes in v2:
 - modify commit msg to make it clear
Changes in v3:
 - use dev_err_probe as suggested by Stefan Wahren
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index e28bb2f2612d..ae9a6a17ec6e 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -96,6 +96,7 @@ struct ci_hdrc_imx_data {
 	struct usb_phy *phy;
 	struct platform_device *ci_pdev;
 	struct clk *clk;
+	struct clk *clk_wakeup;
 	struct imx_usbmisc_data *usbmisc_data;
 	bool supports_runtime_pm;
 	bool override_phy_control;
@@ -199,7 +200,7 @@ static int imx_get_clks(struct device *dev)
 
 	data->clk_ipg = devm_clk_get(dev, "ipg");
 	if (IS_ERR(data->clk_ipg)) {
-		/* If the platform only needs one clocks */
+		/* If the platform only needs one primary clock */
 		data->clk = devm_clk_get(dev, NULL);
 		if (IS_ERR(data->clk)) {
 			ret = PTR_ERR(data->clk);
@@ -208,6 +209,13 @@ static int imx_get_clks(struct device *dev)
 				PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
 			return ret;
 		}
+		/* Get wakeup clock. Not all of the platforms need to
+		 * handle this clock. So make it optional.
+		 */
+		data->clk_wakeup = devm_clk_get_optional(dev, "usb_wakeup_clk");
+		if (IS_ERR(data->clk_wakeup))
+			ret = dev_err_probe(dev, PTR_ERR(data->clk_wakeup),
+					"Failed to get wakeup clk\n");
 		return ret;
 	}
 
@@ -423,6 +431,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 	if (ret)
 		goto disable_hsic_regulator;
 
+	ret = clk_prepare_enable(data->clk_wakeup);
+	if (ret)
+		goto err_wakeup_clk;
+
 	data->phy = devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0);
 	if (IS_ERR(data->phy)) {
 		ret = PTR_ERR(data->phy);
@@ -504,6 +516,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 disable_device:
 	ci_hdrc_remove_device(data->ci_pdev);
 err_clk:
+	clk_disable_unprepare(data->clk_wakeup);
+err_wakeup_clk:
 	imx_disable_unprepare_clks(dev);
 disable_hsic_regulator:
 	if (data->hsic_pad_regulator)
@@ -530,6 +544,7 @@ static void ci_hdrc_imx_remove(struct platform_device *pdev)
 		usb_phy_shutdown(data->phy);
 	if (data->ci_pdev) {
 		imx_disable_unprepare_clks(&pdev->dev);
+		clk_disable_unprepare(data->clk_wakeup);
 		if (data->plat_data->flags & CI_HDRC_PMQOS)
 			cpu_latency_qos_remove_request(&data->pm_qos_req);
 		if (data->hsic_pad_regulator)
-- 
2.34.1



From xu.yang_2 at nxp.com  Thu Dec 28 03:07:52 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 28 Dec 2023 19:07:52 +0800
Subject: [PATCH v3 2/3] usb: chipidea: wait controller resume finished for wakeup irq
In-Reply-To: <20231228110753.1755756-1-xu.yang_2@nxp.com>
References: <20231228110753.1755756-1-xu.yang_2@nxp.com>
Message-ID: <20231228110753.1755756-2-xu.yang_2@nxp.com>

After the chipidea driver introduce extcon for id and vbus, it's able
to wakeup from another irq source, in case the system with extcon ID
cable, wakeup from usb ID cable and device removal, the usb device
disconnect irq may come firstly before the extcon notifier while system
resume, so we will get 2 "wakeup" irq, one for usb device disconnect;
and one for extcon ID cable change(real wakeup event), current driver
treat them as 2 successive wakeup irq so can't handle it correctly, then
finally the usb irq can't be enabled. This patch adds a check to bypass
further usb events before controller resume finished to fix it.

Fixes: 1f874edcb731 ("usb: chipidea: add runtime power management support")
cc: <stable at vger.kernel.org>
Acked-by: Peter Chen <peter.chen at kernel.org>
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
Signed-off-by: Li Jun <jun.li at nxp.com>

---
Changes in v2:
 - no changes
Changes in v3:
 - no changes
---
 drivers/usb/chipidea/core.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 0af9e68035fb..41014f93cfdf 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -523,6 +523,13 @@ static irqreturn_t ci_irq_handler(int irq, void *data)
 	u32 otgsc = 0;
 
 	if (ci->in_lpm) {
+		/*
+		 * If we already have a wakeup irq pending there,
+		 * let's just return to wait resume finished firstly.
+		 */
+		if (ci->wakeup_int)
+			return IRQ_HANDLED;
+
 		disable_irq_nosync(irq);
 		ci->wakeup_int = true;
 		pm_runtime_get(ci->dev);
-- 
2.34.1



From xu.yang_2 at nxp.com  Thu Dec 28 03:07:53 2023
From: xu.yang_2 at nxp.com (Xu Yang)
Date: Thu, 28 Dec 2023 19:07:53 +0800
Subject: [PATCH v3 3/3] usb: phy: mxs: remove CONFIG_USB_OTG condition for mxs_phy_is_otg_host()
In-Reply-To: <20231228110753.1755756-1-xu.yang_2@nxp.com>
References: <20231228110753.1755756-1-xu.yang_2@nxp.com>
Message-ID: <20231228110753.1755756-3-xu.yang_2@nxp.com>

When CONFIG_USB_OTG is not set, mxs_phy_is_otg_host() will always return
false. This behaviour is wrong. Since phy.last_event will always be set
for either host or device mode. Therefore, CONFIG_USB_OTG condition
can be removed.

Fixes: 5eda42aebb76 ("usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host()")
cc: <stable at vger.kernel.org>
Acked-by: Peter Chen <peter.chen at kernel.org>
Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>

---
Changes in v2:
 - add fix tag and stable maillist
Changes in v3:
 - no changes
---
 drivers/usb/phy/phy-mxs-usb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index acd46b72899e..920a32cd094d 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -388,8 +388,7 @@ static void __mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool disconnect)
 
 static bool mxs_phy_is_otg_host(struct mxs_phy *mxs_phy)
 {
-	return IS_ENABLED(CONFIG_USB_OTG) &&
-		mxs_phy->phy.last_event == USB_EVENT_ID;
+	return mxs_phy->phy.last_event == USB_EVENT_ID;
 }
 
 static void mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool on)
-- 
2.34.1



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:45 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:45 +0800
Subject: [PATCH v8 18/20] virt: geniezone: Provide individual VM memory statistics within debugfs
In-Reply-To: <20231228105147.13752-1-yi-de.wu@mediatek.com>
References: <20231228105147.13752-1-yi-de.wu@mediatek.com>
Message-ID: <20231228105147.13752-19-yi-de.wu@mediatek.com>

From: "Jerry Wang" <ze-yu.wang at mediatek.com>

Created a dedicated per-VM debugfs folder under gzvm, providing
user-level programs with easy access to per-VM memory statistics for
debugging and profiling purposes. This enables users to effectively
analyze and optimize the memory usage of individual virtual machines.

Two types of information can be obtained:

`cat /sys/kernel/debug/gzvm/<pid>-<vmid>/protected_hyp_mem` shows memory
used by the hypervisor and the size of the stage 2 table in bytes.

`cat /sys/kernel/debug/gzvm/<pid>-<vmid>/protected_shared_mem` gives
memory used by the shared resources of the guest and host in bytes.

For example:
console:/ # cat /sys/kernel/debug/gzvm/3417-15/protected_hyp_mem
180328
console:/ # cat /sys/kernel/debug/gzvm/3417-15/protected_shared_mem
262144
console:/ #

More stats will be added in the future.

Signed-off-by: Jerry Wang <ze-yu.wang at mediatek.com>
Signed-off-by: Liju-Clr Chen <liju-clr.chen at mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu at mediatek.com>
---
 arch/arm64/geniezone/gzvm_arch_common.h |   2 +
 arch/arm64/geniezone/vm.c               |  13 +++
 drivers/virt/geniezone/gzvm_main.c      |   6 ++
 drivers/virt/geniezone/gzvm_vm.c        | 137 ++++++++++++++++++++++++
 include/linux/gzvm_drv.h                |  15 +++
 5 files changed, 173 insertions(+)

diff --git a/arch/arm64/geniezone/gzvm_arch_common.h b/arch/arm64/geniezone/gzvm_arch_common.h
index 07c5e2df7a74..fbaf2da792a4 100644
--- a/arch/arm64/geniezone/gzvm_arch_common.h
+++ b/arch/arm64/geniezone/gzvm_arch_common.h
@@ -26,6 +26,7 @@ enum {
 	GZVM_FUNC_SET_DTB_CONFIG = 16,
 	GZVM_FUNC_MAP_GUEST = 17,
 	GZVM_FUNC_MAP_GUEST_BLOCK = 18,
+	GZVM_FUNC_GET_STATISTICS = 19,
 	NR_GZVM_FUNC,
 };
 
@@ -52,6 +53,7 @@ enum {
 #define MT_HVC_GZVM_SET_DTB_CONFIG	GZVM_HCALL_ID(GZVM_FUNC_SET_DTB_CONFIG)
 #define MT_HVC_GZVM_MAP_GUEST		GZVM_HCALL_ID(GZVM_FUNC_MAP_GUEST)
 #define MT_HVC_GZVM_MAP_GUEST_BLOCK	GZVM_HCALL_ID(GZVM_FUNC_MAP_GUEST_BLOCK)
+#define MT_HVC_GZVM_GET_STATISTICS	GZVM_HCALL_ID(GZVM_FUNC_GET_STATISTICS)
 
 #define GIC_V3_NR_LRS			16
 
diff --git a/arch/arm64/geniezone/vm.c b/arch/arm64/geniezone/vm.c
index e709872e3dfe..a9d264bbb3b1 100644
--- a/arch/arm64/geniezone/vm.c
+++ b/arch/arm64/geniezone/vm.c
@@ -404,3 +404,16 @@ int gzvm_arch_map_guest_block(u16 vm_id, int memslot_id, u64 gfn, u64 nr_pages)
 	return gzvm_hypcall_wrapper(MT_HVC_GZVM_MAP_GUEST_BLOCK, vm_id,
 				    memslot_id, gfn, nr_pages, 0, 0, 0, &res);
 }
+
+int gzvm_arch_get_statistics(struct gzvm *gzvm)
+{
+	struct arm_smccc_res res;
+	int ret;
+
+	ret = gzvm_hypcall_wrapper(MT_HVC_GZVM_GET_STATISTICS, gzvm->vm_id,
+				   0, 0, 0, 0, 0, 0, &res);
+
+	gzvm->stat.protected_hyp_mem = ((ret == 0) ? res.a1 : 0);
+	gzvm->stat.protected_shared_mem = ((ret == 0) ? res.a2 : 0);
+	return ret;
+}
diff --git a/drivers/virt/geniezone/gzvm_main.c b/drivers/virt/geniezone/gzvm_main.c
index af5ab8949206..da1c0f478b61 100644
--- a/drivers/virt/geniezone/gzvm_main.c
+++ b/drivers/virt/geniezone/gzvm_main.c
@@ -113,6 +113,11 @@ static int gzvm_drv_probe(struct platform_device *pdev)
 	ret = gzvm_drv_irqfd_init();
 	if (ret)
 		return ret;
+
+	ret = gzvm_drv_debug_init();
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
@@ -121,6 +126,7 @@ static int gzvm_drv_remove(struct platform_device *pdev)
 	gzvm_drv_irqfd_exit();
 	gzvm_destroy_all_vms();
 	misc_deregister(&gzvm_dev);
+	gzvm_drv_debug_exit();
 	return 0;
 }
 
diff --git a/drivers/virt/geniezone/gzvm_vm.c b/drivers/virt/geniezone/gzvm_vm.c
index 1af78f161eb3..4861730d555d 100644
--- a/drivers/virt/geniezone/gzvm_vm.c
+++ b/drivers/virt/geniezone/gzvm_vm.c
@@ -11,11 +11,14 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/gzvm_drv.h>
+#include <linux/debugfs.h>
 #include "gzvm_common.h"
 
 static DEFINE_MUTEX(gzvm_list_lock);
 static LIST_HEAD(gzvm_list);
 
+static struct dentry *gzvm_debugfs_dir;
+
 u64 gzvm_gfn_to_hva_memslot(struct gzvm_memslot *memslot, u64 gfn)
 {
 	u64 offset = gfn - memslot->base_gfn;
@@ -308,6 +311,12 @@ static void gzvm_destroy_all_ppage(struct gzvm *gzvm)
 	}
 }
 
+static int gzvm_destroy_vm_debugfs(struct gzvm *vm)
+{
+	debugfs_remove_recursive(vm->debug_dir);
+	return 0;
+}
+
 static void gzvm_destroy_vm(struct gzvm *gzvm)
 {
 	size_t allocated_size;
@@ -334,6 +343,8 @@ static void gzvm_destroy_vm(struct gzvm *gzvm)
 	/* No need to lock here becauese it's single-threaded execution */
 	gzvm_destroy_all_ppage(gzvm);
 
+	gzvm_destroy_vm_debugfs(gzvm);
+
 	kfree(gzvm);
 }
 
@@ -391,6 +402,113 @@ static void setup_vm_demand_paging(struct gzvm *vm)
 	}
 }
 
+static int debugfs_open(struct inode *inode, struct file *file)
+{
+	file->private_data = inode->i_private;
+	return 0;
+}
+
+/**
+ * hyp_mem_read() - Get size of hypervisor-allocated memory and stage 2 table
+ * @file: Pointer to struct file
+ * @buf: User space buffer for storing the return value
+ * @len: Size of @buf, in bytes
+ * @offset: Pointer to loff_t
+ *
+ * Return: Size of hypervisor-allocated memory and stage 2 table, in bytes
+ */
+static ssize_t hyp_mem_read(struct file *file, char __user *buf, size_t len,
+			    loff_t *offset)
+{
+	char tmp_buffer[GZVM_MAX_DEBUGFS_VALUE_SIZE] = {0};
+	struct gzvm *vm = file->private_data;
+	int ret;
+
+	if (*offset == 0) {
+		ret = gzvm_arch_get_statistics(vm);
+		if (ret)
+			return ret;
+		snprintf(tmp_buffer, sizeof(tmp_buffer), "%llu\n",
+			 vm->stat.protected_hyp_mem);
+		if (copy_to_user(buf, tmp_buffer, sizeof(tmp_buffer)))
+			return -EFAULT;
+		*offset += sizeof(tmp_buffer);
+		return sizeof(tmp_buffer);
+	}
+	return 0;
+}
+
+/**
+ * shared_mem_read() - Get size of memory shared between host and guest
+ * @file: Pointer to struct file
+ * @buf: User space buffer for storing the return value
+ * @len: Size of @buf, in bytes
+ * @offset: Pointer to loff_t
+ *
+ * Return: Size of memory shared between host and guest, in bytes
+ */
+static ssize_t shared_mem_read(struct file *file, char __user *buf, size_t len,
+			       loff_t *offset)
+{
+	char tmp_buffer[GZVM_MAX_DEBUGFS_VALUE_SIZE] = {0};
+	struct gzvm *vm = file->private_data;
+	int ret;
+
+	if (*offset == 0) {
+		ret = gzvm_arch_get_statistics(vm);
+		if (ret)
+			return ret;
+		snprintf(tmp_buffer, sizeof(tmp_buffer), "%llu\n",
+			 vm->stat.protected_shared_mem);
+		if (copy_to_user(buf, tmp_buffer, sizeof(tmp_buffer)))
+			return -EFAULT;
+		*offset += sizeof(tmp_buffer);
+		return sizeof(tmp_buffer);
+	}
+	return 0;
+}
+
+static const struct file_operations hyp_mem_fops = {
+	.owner = THIS_MODULE,
+	.open = debugfs_open,
+	.read = hyp_mem_read,
+	.llseek = no_llseek,
+};
+
+static const struct file_operations shared_mem_fops = {
+	.owner = THIS_MODULE,
+	.open = debugfs_open,
+	.read = shared_mem_read,
+	.llseek = no_llseek,
+};
+
+static int gzvm_create_vm_debugfs(struct gzvm *vm)
+{
+	struct dentry *dent;
+	char dir_name[GZVM_MAX_DEBUGFS_DIR_NAME_SIZE];
+
+	if (vm->debug_dir) {
+		pr_warn("VM debugfs directory is duplicated\n");
+		return 0;
+	}
+
+	snprintf(dir_name, sizeof(dir_name), "%d-%d", task_pid_nr(current), vm->vm_id);
+
+	dent = debugfs_lookup(dir_name, gzvm_debugfs_dir);
+	if (dent) {
+		pr_warn("Debugfs directory is duplicated\n");
+		dput(dent);
+		return 0;
+	}
+	dent = debugfs_create_dir(dir_name, gzvm_debugfs_dir);
+	vm->debug_dir = dent;
+
+	debugfs_create_file("protected_shared_mem", 0444, dent, vm, &shared_mem_fops);
+	debugfs_create_file("protected_hyp_mem", 0444, dent, vm, &hyp_mem_fops);
+
+	return 0;
+}
+
 static struct gzvm *gzvm_create_vm(unsigned long vm_type)
 {
 	int ret;
@@ -432,6 +550,8 @@ static struct gzvm *gzvm_create_vm(unsigned long vm_type)
 	list_add(&gzvm->vm_list, &gzvm_list);
 	mutex_unlock(&gzvm_list_lock);
 
+	gzvm_create_vm_debugfs(gzvm);
+
 	pr_debug("VM-%u is created\n", gzvm->vm_id);
 
 	return gzvm;
@@ -469,3 +589,20 @@ void gzvm_destroy_all_vms(void)
 out:
 	mutex_unlock(&gzvm_list_lock);
 }
+
+int gzvm_drv_debug_init(void)
+{
+	if (!debugfs_initialized())
+		return 0;
+
+	if (!gzvm_debugfs_dir && !debugfs_lookup("gzvm", gzvm_debugfs_dir))
+		gzvm_debugfs_dir = debugfs_create_dir("gzvm", NULL);
+
+	return 0;
+}
+
+void gzvm_drv_debug_exit(void)
+{
+	if (gzvm_debugfs_dir && debugfs_lookup("gzvm", gzvm_debugfs_dir))
+		debugfs_remove_recursive(gzvm_debugfs_dir);
+}
diff --git a/include/linux/gzvm_drv.h b/include/linux/gzvm_drv.h
index 17f5fb9d843d..a4e6c7eb9c17 100644
--- a/include/linux/gzvm_drv.h
+++ b/include/linux/gzvm_drv.h
@@ -47,6 +47,9 @@
 
 #define GZVM_BLOCK_BASED_DEMAND_PAGE_SIZE	(2 * 1024 * 1024) /* 2MB */
 
+#define GZVM_MAX_DEBUGFS_DIR_NAME_SIZE  20
+#define GZVM_MAX_DEBUGFS_VALUE_SIZE	20
+
 /* struct mem_region_addr_range - Identical to ffa memory constituent */
 struct mem_region_addr_range {
 	/* the base IPA of the constituent memory region, aligned to 4 kiB */
@@ -89,6 +92,11 @@ struct gzvm_pinned_page {
 	u64 ipa;
 };
 
+struct gzvm_vm_stat {
+	u64 protected_hyp_mem;
+	u64 protected_shared_mem;
+};
+
 struct gzvm {
 	struct gzvm_vcpu *vcpus[GZVM_MAX_VCPUS];
 	/* userspace tied to this vm */
@@ -133,6 +141,9 @@ struct gzvm {
 	struct rb_root pinned_pages;
 	/* lock for memory operations */
 	struct mutex mem_lock;
+
+	struct gzvm_vm_stat stat;
+	struct dentry *debug_dir;
 };
 
 long gzvm_dev_ioctl_check_extension(struct gzvm *gzvm, unsigned long args);
@@ -154,6 +165,7 @@ int gzvm_arch_destroy_vm(u16 vm_id);
 int gzvm_arch_map_guest(u16 vm_id, int memslot_id, u64 pfn, u64 gfn,
 			u64 nr_pages);
 int gzvm_arch_map_guest_block(u16 vm_id, int memslot_id, u64 gfn, u64 nr_pages);
+int gzvm_arch_get_statistics(struct gzvm *gzvm);
 int gzvm_vm_ioctl_arch_enable_cap(struct gzvm *gzvm,
 				  struct gzvm_enable_cap *cap,
 				  void __user *argp);
@@ -172,6 +184,9 @@ int gzvm_arch_vcpu_run(struct gzvm_vcpu *vcpu, __u64 *exit_reason);
 int gzvm_arch_destroy_vcpu(u16 vm_id, int vcpuid);
 int gzvm_arch_inform_exit(u16 vm_id);
 
+int gzvm_drv_debug_init(void);
+void gzvm_drv_debug_exit(void);
+
 int gzvm_find_memslot(struct gzvm *vm, u64 gpa);
 int gzvm_handle_page_fault(struct gzvm_vcpu *vcpu);
 bool gzvm_handle_guest_exception(struct gzvm_vcpu *vcpu);
-- 
2.18.0



From yi-de.wu at mediatek.com  Thu Dec 28 02:51:27 2023
From: yi-de.wu at mediatek.com (Yi-De Wu)
Date: Thu, 28 Dec 2023 18:51:27 +0800
Subject: [PATCH v8 00/20] GenieZone hypervisor drivers
Message-ID: <20231228105147.13752-1-yi-de.wu@mediatek.com>

This series is based on linux-next, tag: next-20231222.

GenieZone hypervisor(gzvm) is a type-1 hypervisor that supports various virtual
machine types and provides security features such as TEE-like scenarios and
secure boot. It can create guest VMs for security use cases and has
virtualization capabilities for both platform and interrupt. Although the
hypervisor can be booted independently, it requires the assistance of GenieZone
hypervisor kernel driver(gzvm-ko) to leverage the ability of Linux kernel for
vCPU scheduling, memory management, inter-VM communication and virtio backend
support.

Changes in v8:
- Add reasons for using dt solution in dt-bindings.
- Add locks for memory pin/unpin and relinquish operations.
- Add VM memory stats in debugfs.
- Add tracing support for hypercall and vcpu exit reasons.
- Enable PTP for timing synchronization between host and guests.
- Optimize memory performance for protected VMs.
- Refactor wording and titles in documentation.

Changes in v7:
https://lore.kernel.org/all/20231116152756.4250-1-yi-de.wu at mediatek.com/
- Rebase these patches to the Linux 6.7-rc1 release.
- Refactor patches 1 to 15 to improve coding style while ensuring they do not
  violate the majority of the changes made in v6
- Provide individual VM memory statistics within debugfs in patch 16.
- Add tracing support for hyper call and vcpu exit_reason.

Changes in v6:
https://lore.kernel.org/all/20230919111210.19615-1-yi-de.wu at mediatek.com/
- Rebase based on kernel 6.6-rc1
- Keep dt solution and leave the reasons in the commit message
- Remove arch/arm64/include/uapi/asm/gzvm_arch.h due to simplicity
- Remove resampler in drivers/virt/geniezone/gzvm_irqfd.c due to defeature for
  now
- Remove PPI in arch/arm64/geniezone/vgic.c
- Refactor vm related components into 3 smaller patches, namely adding vm
  support, setting user memory region and checking vm capability 
- Refactor vcpu and vm component to remove unnecessary ARM prefix 
- Add demand paging to fix crash on destroying memory page, acclerate on booting
  and support ballooning deflate
- Add memory pin/unpin memory mechanism to support protected VM
- Add block-based demand paging for performance concern
- Response to reviewers and fix coding style accordingly

Changes in v5:
https://lore.kernel.org/all/20230727080005.14474-1-yi-de.wu at mediatek.com/
- Add dt solution back for device initialization
- Add GZVM_EXIT_GZ reason for gzvm_vcpu_run()
- Add patch for guest page fault handler
- Add patch for supporitng pin/unpin memory
- Remove unused enum members, namely GZVM_FUNC_GET_REGS and GZVM_FUNC_SET_REGS
- Use dev_debug() for debugging when platform device is available, and use
  pr_debug() otherwise
- Response to reviewers and fix bugs accordingly


Changes in v4:
https://lore.kernel.org/all/20230609085214.31071-1-yi-de.wu at mediatek.com/
- Add macro to set VM as protected without triggering pvmfw in AVF.
- Add support to pass dtb config to hypervisor.
- Add support for virtual timer.
- Add UAPI to pass memory region metadata to hypervisor.
- Define our own macros for ARM's interrupt number
- Elaborate more on GenieZone hyperivsor in documentation
- Fix coding style.
- Implement our own module for coverting ipa to pa
- Modify the way of initializing device from dt to a more discoverable way
- Move refactoring changes into indepedent patches.

Changes in v3:
https://lore.kernel.org/all/20230512080405.12043-1-yi-de.wu at mediatek.com/
- Refactor: separate arch/arm64/geniezone/gzvm_arch.c into vm.c/vcpu.c/vgic.c
- Remove redundant functions
- Fix reviewer's comments

Changes in v2:
https://lore.kernel.org/all/20230428103622.18291-1-yi-de.wu at mediatek.com/
- Refactor: move to drivers/virt/geniezone
- Refactor: decouple arch-dependent and arch-independent
- Check pending signal before entering guest context
- Fix reviewer's comments

Initial Commit in v1:
https://lore.kernel.org/all/20230413090735.4182-1-yi-de.wu at mediatek.com/


Yi-De Wu (20):
  docs: geniezone: Introduce GenieZone hypervisor
  dt-bindings: hypervisor: Add MediaTek GenieZone hypervisor
  virt: geniezone: Add GenieZone hypervisor driver
  virt: geniezone: Add vm support
  virt: geniezone: Add set_user_memory_region for vm
  virt: geniezone: Add vm capability check
  virt: geniezone: Optimize performance of protected VM memory
  virt: geniezone: Add vcpu support
  virt: geniezone: Add irqchip support for virtual interrupt injection
  virt: geniezone: Add irqfd support
  virt: geniezone: Add ioeventfd support
  virt: geniezone: Add memory region support
  virt: geniezone: Add dtb config support
  virt: geniezone: Add demand paging support
  virt: geniezone: Add block-based demand paging support
  virt: geniezone: Add memory pin/unpin support
  virt: geniezone: Add memory relinquish support
  virt: geniezone: Provide individual VM memory statistics within
    debugfs
  virt: geniezone: Add tracing support for hyp call and vcpu exit_reason
  virt: geniezone: Enable PTP for synchronizing time between host and
    guest VMs

 .../hypervisor/mediatek,geniezone-hyp.yaml    |  31 +
 Documentation/virt/geniezone/introduction.rst |  87 +++
 Documentation/virt/index.rst                  |   1 +
 MAINTAINERS                                   |  11 +
 arch/arm64/Kbuild                             |   1 +
 arch/arm64/geniezone/Makefile                 |   9 +
 arch/arm64/geniezone/gzvm_arch_common.h       | 122 ++++
 arch/arm64/geniezone/hvc.c                    |  73 +++
 arch/arm64/geniezone/vcpu.c                   |  80 +++
 arch/arm64/geniezone/vgic.c                   |  50 ++
 arch/arm64/geniezone/vm.c                     | 424 ++++++++++++
 drivers/virt/Kconfig                          |   2 +
 drivers/virt/geniezone/Kconfig                |  16 +
 drivers/virt/geniezone/Makefile               |  12 +
 drivers/virt/geniezone/gzvm_common.h          |  12 +
 drivers/virt/geniezone/gzvm_exception.c       |  61 ++
 drivers/virt/geniezone/gzvm_ioeventfd.c       | 276 ++++++++
 drivers/virt/geniezone/gzvm_irqfd.c           | 382 +++++++++++
 drivers/virt/geniezone/gzvm_main.c            | 153 +++++
 drivers/virt/geniezone/gzvm_mmu.c             | 300 +++++++++
 drivers/virt/geniezone/gzvm_vcpu.c            | 284 ++++++++
 drivers/virt/geniezone/gzvm_vm.c              | 608 ++++++++++++++++++
 include/linux/gzvm_drv.h                      | 221 +++++++
 include/trace/events/geniezone.h              |  54 ++
 include/uapi/linux/gzvm.h                     | 396 ++++++++++++
 25 files changed, 3666 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hypervisor/mediatek,geniezone-hyp.yaml
 create mode 100644 Documentation/virt/geniezone/introduction.rst
 create mode 100644 arch/arm64/geniezone/Makefile
 create mode 100644 arch/arm64/geniezone/gzvm_arch_common.h
 create mode 100644 arch/arm64/geniezone/hvc.c
 create mode 100644 arch/arm64/geniezone/vcpu.c
 create mode 100644 arch/arm64/geniezone/vgic.c
 create mode 100644 arch/arm64/geniezone/vm.c
 create mode 100644 drivers/virt/geniezone/Kconfig
 create mode 100644 drivers/virt/geniezone/Makefile
 create mode 100644 drivers/virt/geniezone/gzvm_common.h
 create mode 100644 drivers/virt/geniezone/gzvm_exception.c
 create mode 100644 drivers/virt/geniezone/gzvm_ioeventfd.c
 create mode 100644 drivers/virt/geniezone/gzvm_irqfd.c
 create mode 100644 drivers/virt/geniezone/gzvm_main.c
 create mode 100644 drivers/virt/geniezone/gzvm_mmu.c
 create mode 100644 drivers/virt/geniezone/gzvm_vcpu.c
 create mode 100644 drivers/virt/geniezone/gzvm_vm.c
 create mode 100644 include/linux/gzvm_drv.h
 create mode 100644 include/trace/events/geniezone.h
 create mode 100644 include/uapi/linux/gzvm.h

-- 
2.18.0



From james.clark at arm.com  Thu Dec 28 03:26:09 2023
From: james.clark at arm.com (James Clark)
Date: Thu, 28 Dec 2023 11:26:09 +0000
Subject: [PATCH] coresight: Add coresight name support
In-Reply-To: <20231228093321.5522-1-quic_jinlmao@quicinc.com>
References: <20231228093321.5522-1-quic_jinlmao@quicinc.com>
Message-ID: <12ce6e5d-6e4d-fb99-eb82-dece97423bfb@arm.com>



On 28/12/2023 09:33, Mao Jinlong wrote:
> Add coresight name support for custom names which will be
> easy to identify the device by the name.
> 

I suppose this is more of a V2 because the subject is the same as the
one sent earlier this year. But it looks like the discussion on the
previous one wasn't resolved.

With the main issues to solve being:

 * It would be nice to use the existing root node name instead of adding
   a new property. But at the same time DT nodes are supposed to have
   generic names.

 * This only works for DT and not ACPI

To me it seems like adding the new property is just a "cheat" to get
around not being allowed to have a specific name for the root node. But
if we admit that we need a name I don't see the benefit of not putting
the name where the node is already named.

Using the root node name at this point would also undo the hard coded
per-cpu naming of the CTI and ETM devices, so maybe it would be nice,
but it's just too late. That means that a new field is necessary.
Although that field could be a boolean like "use-root-name-for-display"
or something like that. In the end it probably doesn't really make a
difference whether it's that or a name string.

And maybe the answer to the ACPI question is just that if anyone needs
it, they can add it in the future. It doesn't seem like it would
conflict with anything we do here.

> Signed-off-by: Mao Jinlong <quic_jinlmao at quicinc.com>
> ---
>  .../hwtracing/coresight/coresight-cti-core.c  | 20 ++++++++------
>  drivers/hwtracing/coresight/coresight-dummy.c | 10 ++++---
>  .../hwtracing/coresight/coresight-platform.c  | 27 +++++++++++++++++++
>  drivers/hwtracing/coresight/coresight-tpdm.c  | 10 ++++---
>  include/linux/coresight.h                     |  1 +
>  5 files changed, 53 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
> index 3999d0a2cb60..60a1e76064a9 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-core.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-core.c
> @@ -902,14 +902,18 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
>  	/* default to powered - could change on PM notifications */
>  	drvdata->config.hw_powered = true;
>  
> -	/* set up device name - will depend if cpu bound or otherwise */
> -	if (drvdata->ctidev.cpu >= 0)
> -		cti_desc.name = devm_kasprintf(dev, GFP_KERNEL, "cti_cpu%d",
> -					       drvdata->ctidev.cpu);
> -	else
> -		cti_desc.name = coresight_alloc_device_name(&cti_sys_devs, dev);

Can we put the new name stuff inside coresight_alloc_device_name()? Then
it happens by default for every device.

I know Suzuki said previously to do it per-device, but the new DT
property is just "coresight-name", so it's generic. Rather than being
specific like "cti-name". So I don't see the benefit of duplicating the
code at this point if we do decide to do it.

> -	if (!cti_desc.name)
> -		return -ENOMEM;
> +	cti_desc.name = coresight_get_device_name(dev);
> +	if (!cti_desc.name) {
> +		/* set up device name - will depend if cpu bound or otherwise */
> +		if (drvdata->ctidev.cpu >= 0)
> +			cti_desc.name = devm_kasprintf(dev, GFP_KERNEL, "cti_cpu%d",
> +						       drvdata->ctidev.cpu);
> +		else {
> +			cti_desc.name = coresight_alloc_device_name(&cti_sys_devs, dev);
> +			if (!cti_desc.name)
> +				return -ENOMEM;
> +		}
> +	}

>  
>  	/* setup CPU power management handling for CPU bound CTI devices. */
>  	ret = cti_pm_setup(drvdata);
> diff --git a/drivers/hwtracing/coresight/coresight-dummy.c b/drivers/hwtracing/coresight/coresight-dummy.c
> index e4deafae7bc2..b19cd400df79 100644
> --- a/drivers/hwtracing/coresight/coresight-dummy.c
> +++ b/drivers/hwtracing/coresight/coresight-dummy.c
> @@ -76,10 +76,12 @@ static int dummy_probe(struct platform_device *pdev)
>  	struct coresight_desc desc = { 0 };
>  
>  	if (of_device_is_compatible(node, "arm,coresight-dummy-source")) {
> -
> -		desc.name = coresight_alloc_device_name(&source_devs, dev);
> -		if (!desc.name)
> -			return -ENOMEM;
> +		desc.name = coresight_get_device_name(dev);
> +		if (!desc.name) {
> +			desc.name = coresight_alloc_device_name(&source_devs, dev);
> +			if (!desc.name)
> +				return -ENOMEM;
> +		}
>  
>  		desc.type = CORESIGHT_DEV_TYPE_SOURCE;
>  		desc.subtype.source_subtype =
> diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
> index 9d550f5697fa..284aa22a06b7 100644
> --- a/drivers/hwtracing/coresight/coresight-platform.c
> +++ b/drivers/hwtracing/coresight/coresight-platform.c
> @@ -183,6 +183,18 @@ static int of_coresight_get_cpu(struct device *dev)
>  	return cpu;
>  }
>  
> +static const char *of_coresight_get_device_name(struct device *dev)
> +{
> +	const char *name = NULL;
> +
> +	if (!dev->of_node)
> +		return NULL;
> +
> +	of_property_read_string(dev->of_node, "coresight-name", &name);

Do you need to update the binding docs with this new property?

Also a minor nit: Maybe "display-name" is better? "Coresight" is
implied, and the node is already named, although that node name isn't
used for display purposes, but this one is.

Thanks
James


From eugen.hristev at collabora.com  Thu Dec 28 03:32:42 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Thu, 28 Dec 2023 13:32:42 +0200
Subject: [PATCH v3 3/6] arm64: dts: mediatek: mt8192: fix vencoder clock name
In-Reply-To: <20231228113245.174706-1-eugen.hristev@collabora.com>
References: <20231228113245.174706-1-eugen.hristev@collabora.com>
Message-ID: <20231228113245.174706-4-eugen.hristev@collabora.com>

Clock name should be `venc_sel` as per binding.
Fix the warning message :
arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dtb: vcodec at 17020000: clock-names:0: 'venc_sel' was expected
        from schema $id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml#

Fixes: aa8f3711fc87 ("arm64: dts: mt8192: Add H264 venc device node")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
Changes in v3:
none
Changes in v2:
- new patch.
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 69f4cded5dbb..f1fc14e53f8c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -1770,7 +1770,7 @@ vcodec_enc: vcodec at 17020000 {
 			mediatek,scp = <&scp>;
 			power-domains = <&spm MT8192_POWER_DOMAIN_VENC>;
 			clocks = <&vencsys CLK_VENC_SET1_VENC>;
-			clock-names = "venc-set1";
+			clock-names = "venc_sel";
 			assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>;
 			assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D4>;
 		};
-- 
2.34.1



From eugen.hristev at collabora.com  Thu Dec 28 03:32:39 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Thu, 28 Dec 2023 13:32:39 +0200
Subject: [PATCH v3 0/6] video encoder on mt8186
Message-ID: <20231228113245.174706-1-eugen.hristev@collabora.com>

Hello,

This series adds support for the video encoder on mt8186.

Few patches fix the binding, there is a patch for the DT node,
and one patch for the driver that fixes an imbalance.

Changes in v3:
- removed the patch to add dma-ranges, because this was intentionally
removed (e.g. https://patchwork.kernel.org/project/linux-media/patch/20230303013842.23259-3-allen-kh.cheng at mediatek.com/ )
also removed dma-ranges and cells from the DT node

Changes in v2:
- change log in every patch

Eugen Hristev (5):
  media: mediatek: vcodec: fix possible unbalanced PM counter
  dt-bindings: media: mtk-vcodec-encoder: fix non-vp8 clock name
  arm64: dts: mediatek: mt8192: fix vencoder clock name
  dt-bindings: media: mtk-vcodec-encoder: add compatible for mt8186
  arm64: dts: mediatek: mt8186: fix VENC power domain clocks

Kyrie Wu (1):
  arm64: dts: mediatek: mt8186: Add venc node

 .../media/mediatek,vcodec-encoder.yaml        | 31 ++++++++++---------
 arch/arm64/boot/dts/mediatek/mt8186.dtsi      | 23 +++++++++++++-
 arch/arm64/boot/dts/mediatek/mt8192.dtsi      |  2 +-
 .../vcodec/encoder/mtk_vcodec_enc_pm.c        |  4 ++-
 .../vcodec/encoder/mtk_vcodec_enc_pm.h        |  2 +-
 .../mediatek/vcodec/encoder/venc_drv_if.c     |  5 ++-
 6 files changed, 47 insertions(+), 20 deletions(-)

-- 
2.34.1



From eugen.hristev at collabora.com  Thu Dec 28 03:32:41 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Thu, 28 Dec 2023 13:32:41 +0200
Subject: [PATCH v3 2/6] dt-bindings: media: mtk-vcodec-encoder: fix non-vp8 clock name
In-Reply-To: <20231228113245.174706-1-eugen.hristev@collabora.com>
References: <20231228113245.174706-1-eugen.hristev@collabora.com>
Message-ID: <20231228113245.174706-3-eugen.hristev@collabora.com>

Looking at the binding it makes sense that the `-vp8` compatible has
the `venc_lt_sel` while the other bindings have the `venc_sel` as name for
the clock.
This was also mentioned in the txt version of the binding before the
conversion:
 `
 clock-names: avc encoder must contain "venc_sel", vp8 encoder must
 contain "venc_lt_sel", decoder must contain "vcodecpll", "univpll_d2",
 `

So it is easier to check for compatible that includes vp8, since that's
just one, to have the requirement for the clock name property as
`venc_lt_sel`, rather than for all the others, some of which are missing,
thus for them, the requirement is wrongly `venc_lt_sel`.

Reordered the if/then/else to match `-vp8` and have all the rest of
the compatibles using the other clock name (`venc_sel`).

Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
Changes in v3:
- collect R-B
Changes in v2:
- new patch.
 .../bindings/media/mediatek,vcodec-encoder.yaml       | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
index a2051b31fa29..849721c0571a 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
@@ -109,10 +109,7 @@ allOf:
       properties:
         compatible:
           enum:
-            - mediatek,mt8173-vcodec-enc
-            - mediatek,mt8188-vcodec-enc
-            - mediatek,mt8192-vcodec-enc
-            - mediatek,mt8195-vcodec-enc
+            - mediatek,mt8173-vcodec-enc-vp8
 
     then:
       properties:
@@ -122,8 +119,8 @@ allOf:
             maxItems: 1
         clock-names:
           items:
-            - const: venc_sel
-    else:  # for vp8 hw encoder
+            - const: venc_lt_sel
+    else:
       properties:
         clock:
           items:
@@ -131,7 +128,7 @@ allOf:
             maxItems: 1
         clock-names:
           items:
-            - const: venc_lt_sel
+            - const: venc_sel
 
 additionalProperties: false
 
-- 
2.34.1



From eugen.hristev at collabora.com  Thu Dec 28 03:32:43 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Thu, 28 Dec 2023 13:32:43 +0200
Subject: [PATCH v3 4/6] dt-bindings: media: mtk-vcodec-encoder: add compatible for mt8186
In-Reply-To: <20231228113245.174706-1-eugen.hristev@collabora.com>
References: <20231228113245.174706-1-eugen.hristev@collabora.com>
Message-ID: <20231228113245.174706-5-eugen.hristev@collabora.com>

Add compatible for the mt8186 encoder which currently works in the same
way as mt8183.

Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
Changes in v3:
- collect R-b
Changes in v2:
- new patch.
 .../media/mediatek,vcodec-encoder.yaml        | 20 +++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
index 849721c0571a..b45743d0a9ec 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
@@ -16,14 +16,18 @@ description: |+
 
 properties:
   compatible:
-    enum:
-      - mediatek,mt8173-vcodec-enc-vp8
-      - mediatek,mt8173-vcodec-enc
-      - mediatek,mt8183-vcodec-enc
-      - mediatek,mt8188-vcodec-enc
-      - mediatek,mt8192-vcodec-enc
-      - mediatek,mt8195-vcodec-enc
-
+    oneOf:
+      - items:
+          - enum:
+              - mediatek,mt8173-vcodec-enc-vp8
+              - mediatek,mt8173-vcodec-enc
+              - mediatek,mt8183-vcodec-enc
+              - mediatek,mt8188-vcodec-enc
+              - mediatek,mt8192-vcodec-enc
+              - mediatek,mt8195-vcodec-enc
+      - items:
+          - const: mediatek,mt8186-vcodec-enc
+          - const: mediatek,mt8183-vcodec-enc
   reg:
     maxItems: 1
 
-- 
2.34.1



From eugen.hristev at collabora.com  Thu Dec 28 03:32:40 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Thu, 28 Dec 2023 13:32:40 +0200
Subject: [PATCH v3 1/6] media: mediatek: vcodec: fix possible unbalanced PM counter
In-Reply-To: <20231228113245.174706-1-eugen.hristev@collabora.com>
References: <20231228113245.174706-1-eugen.hristev@collabora.com>
Message-ID: <20231228113245.174706-2-eugen.hristev@collabora.com>

It is possible that mtk_vcodec_enc_pw_on fails, and in that scenario
the PM counter is not incremented, and subsequent call to
mtk_vcodec_enc_pw_off decrements the counter, leading to a PM imbalance.
Fix by bailing out of venc_if_encode in the case when mtk_vcodec_enc_pw_on
fails.

Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
---
Changes in v3:
-none
Changes in v2:
- collect R-b

 .../platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c     | 4 +++-
 .../platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h     | 2 +-
 drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c | 5 ++++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c
index a22b7dfc656e..1a2b14a3e219 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.c
@@ -58,13 +58,15 @@ int mtk_vcodec_init_enc_clk(struct mtk_vcodec_enc_dev *mtkdev)
 	return 0;
 }
 
-void mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm)
+int mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm)
 {
 	int ret;
 
 	ret = pm_runtime_resume_and_get(pm->dev);
 	if (ret)
 		dev_err(pm->dev, "pm_runtime_resume_and_get fail: %d", ret);
+
+	return ret;
 }
 
 void mtk_vcodec_enc_pw_off(struct mtk_vcodec_pm *pm)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h
index 157ea08ba9e3..2e28f25e36cc 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_pm.h
@@ -10,7 +10,7 @@
 #include "mtk_vcodec_enc_drv.h"
 
 int mtk_vcodec_init_enc_clk(struct mtk_vcodec_enc_dev *dev);
-void mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm);
+int mtk_vcodec_enc_pw_on(struct mtk_vcodec_pm *pm);
 void mtk_vcodec_enc_pw_off(struct mtk_vcodec_pm *pm);
 void mtk_vcodec_enc_clock_on(struct mtk_vcodec_pm *pm);
 void mtk_vcodec_enc_clock_off(struct mtk_vcodec_pm *pm);
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
index c402a686f3cb..e83747b8d69a 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
@@ -64,7 +64,9 @@ int venc_if_encode(struct mtk_vcodec_enc_ctx *ctx,
 	ctx->dev->curr_ctx = ctx;
 	spin_unlock_irqrestore(&ctx->dev->irqlock, flags);
 
-	mtk_vcodec_enc_pw_on(&ctx->dev->pm);
+	ret = mtk_vcodec_enc_pw_on(&ctx->dev->pm);
+	if (ret)
+		goto venc_if_encode_pw_on_err;
 	mtk_vcodec_enc_clock_on(&ctx->dev->pm);
 	ret = ctx->enc_if->encode(ctx->drv_handle, opt, frm_buf,
 				  bs_buf, result);
@@ -75,6 +77,7 @@ int venc_if_encode(struct mtk_vcodec_enc_ctx *ctx,
 	ctx->dev->curr_ctx = NULL;
 	spin_unlock_irqrestore(&ctx->dev->irqlock, flags);
 
+venc_if_encode_pw_on_err:
 	mtk_venc_unlock(ctx);
 	return ret;
 }
-- 
2.34.1



From eugen.hristev at collabora.com  Thu Dec 28 03:32:44 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Thu, 28 Dec 2023 13:32:44 +0200
Subject: [PATCH v3 5/6] arm64: dts: mediatek: mt8186: fix VENC power domain clocks
In-Reply-To: <20231228113245.174706-1-eugen.hristev@collabora.com>
References: <20231228113245.174706-1-eugen.hristev@collabora.com>
Message-ID: <20231228113245.174706-6-eugen.hristev@collabora.com>

The larb clock is in fact a subsys clock, so it must be prefixed by
'subsys-' to be correctly identified in the driver.

Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
Changes in v2,v3:
- none.

 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index df0c04f2ba1d..66ead3f23336 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1061,7 +1061,7 @@ power-domain at MT8186_POWER_DOMAIN_VENC {
 						reg = <MT8186_POWER_DOMAIN_VENC>;
 						clocks = <&topckgen CLK_TOP_VENC>,
 							 <&vencsys CLK_VENC_CKE1_VENC>;
-						clock-names = "venc0", "larb";
+						clock-names = "venc0", "subsys-larb";
 						mediatek,infracfg = <&infracfg_ao>;
 						#power-domain-cells = <0>;
 					};
-- 
2.34.1



From eugen.hristev at collabora.com  Thu Dec 28 03:32:45 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Thu, 28 Dec 2023 13:32:45 +0200
Subject: [PATCH v3 6/6] arm64: dts: mediatek: mt8186: Add venc node
In-Reply-To: <20231228113245.174706-1-eugen.hristev@collabora.com>
References: <20231228113245.174706-1-eugen.hristev@collabora.com>
Message-ID: <20231228113245.174706-7-eugen.hristev@collabora.com>

From: Kyrie Wu <kyrie.wu at mediatek.com>

Add video encoder node.

Signed-off-by: Kyrie Wu <kyrie.wu at mediatek.com>
Signed-off-by: Allen-KH Cheng <allen-kh.cheng at mediatek.com>
Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.org>
[eugen.hristev at collabora.com: minor cleanup]
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
Changes in v3:
- remove dma ranges and cells.
Changes in v2:
- change node name
- change compatible to include 8186
- change props order
- change clock name to cope with binding

 arch/arm64/boot/dts/mediatek/mt8186.dtsi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index 66ead3f23336..bafb0845e986 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -1993,6 +1993,27 @@ larb7: smi at 17010000 {
 			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
 		};
 
+		venc: video-encoder at 17020000 {
+			compatible = "mediatek,mt8186-vcodec-enc", "mediatek,mt8183-vcodec-enc";
+			reg = <0 0x17020000 0 0x2000>;
+			interrupts = <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH 0>;
+			iommus = <&iommu_mm IOMMU_PORT_L7_VENC_RCPU>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_REC>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_BSDMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_SV_COMV>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_RD_COMV>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_LUMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_CUR_CHROMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_LUMA>,
+				 <&iommu_mm IOMMU_PORT_L7_VENC_REF_CHROMA>;
+			clocks = <&vencsys CLK_VENC_CKE1_VENC>;
+			clock-names = "venc_sel";
+			assigned-clocks = <&topckgen CLK_TOP_VENC>;
+			assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D3>;
+			power-domains = <&spm MT8186_POWER_DOMAIN_VENC>;
+			mediatek,scp = <&scp>;
+		};
+
 		camsys: clock-controller at 1a000000 {
 			compatible = "mediatek,mt8186-camsys";
 			reg = <0 0x1a000000 0 0x1000>;
-- 
2.34.1



From ulf.hansson at linaro.org  Thu Dec 28 03:41:52 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 28 Dec 2023 12:41:52 +0100
Subject: [PATCH 0/5] PM: domains: Add helpers for multi PM domains to avoid open-coding
Message-ID: <20231228114157.104822-1-ulf.hansson@linaro.org>

Attaching/detaching of a device to multiple PM domains has started to become a
common operation for many drivers, typically during ->probe() and ->remove().
In most cases, this has lead to lots of boilerplate code in the drivers.

This series adds a pair of helper functions to manage the attach/detach of a
device to its multiple PM domains. Moreover, a couple of drivers have been
converted to use the new helpers as a proof of concept.

Note 1)
The changes in the drivers have only been compile tested, while the helpers
have been tested along with a couple of local dummy drivers that I have hacked
up to model both genpd providers and genpd consumers.

Note 2)
I was struggling to make up mind if we should have a separate helper to attach
all available power-domains described in DT, rather than providing "NULL" to the
dev_pm_domain_attach_list(). I decided not to, but please let me know if you
prefer the other option.

Note 3)
For OPP integration, as a follow up I am striving to make the
dev_pm_opp_attach_genpd() redundant. Instead I think we should move towards
using dev_pm_opp_set_config()->_opp_set_required_devs(), which would allow us to
use the helpers that $subject series is adding.

Kind regards
Ulf Hansson

Ulf Hansson (5):
  PM: domains: Add helper functions to attach/detach multiple PM domains
  remoteproc: imx_dsp_rproc: Convert to
    dev_pm_domain_attach|detach_list()
  remoteproc: imx_rproc: Convert to dev_pm_domain_attach|detach_list()
  remoteproc: qcom_q6v5_adsp: Convert to
    dev_pm_domain_attach|detach_list()
  media: venus: Convert to dev_pm_domain_attach|detach_list() for vcodec

 drivers/base/power/common.c                   | 133 +++++++++++++++
 drivers/media/platform/qcom/venus/core.c      |  12 +-
 drivers/media/platform/qcom/venus/core.h      |   7 +-
 .../media/platform/qcom/venus/pm_helpers.c    |  48 ++----
 drivers/remoteproc/imx_dsp_rproc.c            |  82 +--------
 drivers/remoteproc/imx_rproc.c                |  73 +-------
 drivers/remoteproc/qcom_q6v5_adsp.c           | 160 ++++++++----------
 include/linux/pm_domain.h                     |  38 +++++
 8 files changed, 288 insertions(+), 265 deletions(-)

-- 
2.34.1



From ulf.hansson at linaro.org  Thu Dec 28 03:41:53 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 28 Dec 2023 12:41:53 +0100
Subject: [PATCH 1/5] PM: domains: Add helper functions to attach/detach multiple PM domains
In-Reply-To: <20231228114157.104822-1-ulf.hansson@linaro.org>
References: <20231228114157.104822-1-ulf.hansson@linaro.org>
Message-ID: <20231228114157.104822-2-ulf.hansson@linaro.org>

Attaching/detaching of a device to multiple PM domains has started to
become a common operation for many drivers, typically during ->probe() and
->remove(). In most cases, this has lead to lots of boilerplate code in the
drivers.

To fixup up the situation, let's introduce a pair of helper functions,
dev_pm_domain_attach|detach_list(), that driver can use instead of the
open-coding. Note that, it seems reasonable to limit the support for these
helpers to DT based platforms, at it's the only valid use case for now.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/base/power/common.c | 133 ++++++++++++++++++++++++++++++++++++
 include/linux/pm_domain.h   |  38 +++++++++++
 2 files changed, 171 insertions(+)

diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
index 44ec20918a4d..1ef51889fc6f 100644
--- a/drivers/base/power/common.c
+++ b/drivers/base/power/common.c
@@ -167,6 +167,114 @@ struct device *dev_pm_domain_attach_by_name(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(dev_pm_domain_attach_by_name);
 
+/**
+ * dev_pm_domain_attach_list - Associate a device with its PM domains.
+ * @dev: The device used to lookup the PM domains for.
+ * @data: The data used for attaching to the PM domains.
+ * @list: An out-parameter with an allocated list of attached PM domains.
+ *
+ * This function helps to attach a device to its multiple PM domains. The
+ * caller, which is typically a driver's probe function, may provide a list of
+ * names for the PM domains that we should try to attach the device to, but it
+ * may also provide an empty list, in case the attach should be done for all of
+ * the available PM domains.
+ *
+ * Callers must ensure proper synchronization of this function with power
+ * management callbacks.
+ *
+ * Returns the number of attached PM domains or a negative error code in case of
+ * a failure. Note that, to detach the list of PM domains, the driver shall call
+ * dev_pm_domain_detach_list(), typically during the remove phase.
+ */
+int dev_pm_domain_attach_list(struct device *dev,
+			      const struct dev_pm_domain_attach_data *data,
+			      struct dev_pm_domain_list **list)
+{
+	struct device_node *np = dev->of_node;
+	struct dev_pm_domain_list *pds;
+	struct device *pd_dev = NULL;
+	int ret, i, num_pds = 0;
+	bool by_id = true;
+	u32 link_flags = data && data->pd_flags & PD_FLAG_NO_DEV_LINK ? 0 :
+			DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME;
+
+	if (dev->pm_domain)
+		return -EEXIST;
+
+	/* For now this is limited to OF based platforms. */
+	if (!np)
+		return 0;
+
+	if (data && data->pd_names) {
+		num_pds = data->num_pd_names;
+		by_id = false;
+	} else {
+		num_pds = of_count_phandle_with_args(np, "power-domains",
+						     "#power-domain-cells");
+	}
+
+	if (num_pds <= 0)
+		return 0;
+
+	pds = devm_kzalloc(dev, sizeof(*pds), GFP_KERNEL);
+	if (!pds)
+		return -ENOMEM;
+
+	pds->pd_devs = devm_kcalloc(dev, num_pds, sizeof(*pds->pd_devs),
+				    GFP_KERNEL);
+	if (!pds->pd_devs)
+		return -ENOMEM;
+
+	pds->pd_links = devm_kcalloc(dev, num_pds, sizeof(*pds->pd_links),
+				     GFP_KERNEL);
+	if (!pds->pd_links)
+		return -ENOMEM;
+
+	if (link_flags && data->pd_flags & PD_FLAG_DEV_LINK_ON)
+		link_flags |= DL_FLAG_RPM_ACTIVE;
+
+	for (i = 0; i < num_pds; i++) {
+		if (by_id)
+			pd_dev = dev_pm_domain_attach_by_id(dev, i);
+		else
+			pd_dev = dev_pm_domain_attach_by_name(dev,
+							data->pd_names[i]);
+		if (IS_ERR_OR_NULL(pd_dev)) {
+			ret = pd_dev ? PTR_ERR(pd_dev) : -ENODEV;
+			goto err_attach;
+		}
+
+		if (link_flags) {
+			struct device_link *link;
+
+			link = device_link_add(dev, pd_dev, link_flags);
+			if (!link) {
+				ret = -ENODEV;
+				goto err_link;
+			}
+
+			pds->pd_links[i] = link;
+		}
+
+		pds->pd_devs[i] = pd_dev;
+	}
+
+	pds->num_pds = num_pds;
+	*list = pds;
+	return num_pds;
+
+err_link:
+	dev_pm_domain_detach(pd_dev, true);
+err_attach:
+	while (--i >= 0) {
+		if (pds->pd_links[i])
+			device_link_del(pds->pd_links[i]);
+		dev_pm_domain_detach(pds->pd_devs[i], true);
+	}
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_domain_attach_list);
+
 /**
  * dev_pm_domain_detach - Detach a device from its PM domain.
  * @dev: Device to detach.
@@ -187,6 +295,31 @@ void dev_pm_domain_detach(struct device *dev, bool power_off)
 }
 EXPORT_SYMBOL_GPL(dev_pm_domain_detach);
 
+/**
+ * dev_pm_domain_detach_list - Detach a list of PM domains.
+ * @list: The list of PM domains to detach.
+ *
+ * This function reverse the actions from dev_pm_domain_attach_list().
+ * Typically it should be invoked during the remove phase from drivers.
+ *
+ * Callers must ensure proper synchronization of this function with power
+ * management callbacks.
+ */
+void dev_pm_domain_detach_list(struct dev_pm_domain_list *list)
+{
+	int i;
+
+	if (!list)
+		return;
+
+	for (i = 0; i < list->num_pds; i++) {
+		if (list->pd_links[i])
+			device_link_del(list->pd_links[i]);
+		dev_pm_domain_detach(list->pd_devs[i], true);
+	}
+}
+EXPORT_SYMBOL_GPL(dev_pm_domain_detach_list);
+
 /**
  * dev_pm_domain_start - Start the device through its PM domain.
  * @dev: Device to start.
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 34663d0d5c55..6b71fb69c349 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -19,6 +19,33 @@
 #include <linux/cpumask.h>
 #include <linux/time64.h>
 
+/*
+ * Flags to control the behaviour when attaching a device to its PM domains.
+ *
+ * PD_FLAG_NO_DEV_LINK:		As the default behaviour creates a device-link
+ *				for every PM domain that gets attached, this
+ *				flag can be used to skip that.
+ *
+ * PD_FLAG_DEV_LINK_ON:		Add the DL_FLAG_RPM_ACTIVE to power-on the
+ *				supplier and its PM domain when creating the
+ *				device-links.
+ *
+ */
+#define PD_FLAG_NO_DEV_LINK		BIT(0)
+#define PD_FLAG_DEV_LINK_ON		BIT(1)
+
+struct dev_pm_domain_attach_data {
+	const char * const *pd_names;
+	const u32 num_pd_names;
+	const u32 pd_flags;
+};
+
+struct dev_pm_domain_list {
+	struct device **pd_devs;
+	struct device_link **pd_links;
+	u32 num_pds;
+};
+
 /*
  * Flags to control the behaviour of a genpd.
  *
@@ -432,7 +459,11 @@ struct device *dev_pm_domain_attach_by_id(struct device *dev,
 					  unsigned int index);
 struct device *dev_pm_domain_attach_by_name(struct device *dev,
 					    const char *name);
+int dev_pm_domain_attach_list(struct device *dev,
+			      const struct dev_pm_domain_attach_data *data,
+			      struct dev_pm_domain_list **list);
 void dev_pm_domain_detach(struct device *dev, bool power_off);
+void dev_pm_domain_detach_list(struct dev_pm_domain_list *list);
 int dev_pm_domain_start(struct device *dev);
 void dev_pm_domain_set(struct device *dev, struct dev_pm_domain *pd);
 int dev_pm_domain_set_performance_state(struct device *dev, unsigned int state);
@@ -451,7 +482,14 @@ static inline struct device *dev_pm_domain_attach_by_name(struct device *dev,
 {
 	return NULL;
 }
+static inline int dev_pm_domain_attach_list(struct device *dev,
+				const struct dev_pm_domain_attach_data *data,
+				struct dev_pm_domain_list **list)
+{
+	return 0;
+}
 static inline void dev_pm_domain_detach(struct device *dev, bool power_off) {}
+static inline void dev_pm_domain_detach_list(struct dev_pm_domain_list *list) {}
 static inline int dev_pm_domain_start(struct device *dev)
 {
 	return 0;
-- 
2.34.1



From ulf.hansson at linaro.org  Thu Dec 28 03:41:54 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 28 Dec 2023 12:41:54 +0100
Subject: [PATCH 2/5] remoteproc: imx_dsp_rproc: Convert to dev_pm_domain_attach|detach_list()
In-Reply-To: <20231228114157.104822-1-ulf.hansson@linaro.org>
References: <20231228114157.104822-1-ulf.hansson@linaro.org>
Message-ID: <20231228114157.104822-3-ulf.hansson@linaro.org>

Let's avoid the boilerplate code to manage the multiple PM domain case, by
converting into using dev_pm_domain_attach|detach_list().

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Bjorn Andersson <andersson at kernel.org>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: <linux-remoteproc at vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/remoteproc/imx_dsp_rproc.c | 82 ++++--------------------------
 1 file changed, 9 insertions(+), 73 deletions(-)

diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
index 8fcda9b74545..0409b7c47d5c 100644
--- a/drivers/remoteproc/imx_dsp_rproc.c
+++ b/drivers/remoteproc/imx_dsp_rproc.c
@@ -103,12 +103,10 @@ enum imx_dsp_rp_mbox_messages {
  * @tx_ch: mailbox tx channel handle
  * @rx_ch: mailbox rx channel handle
  * @rxdb_ch: mailbox rx doorbell channel handle
- * @pd_dev: power domain device
- * @pd_dev_link: power domain device link
+ * @pd_list: power domain list
  * @ipc_handle: System Control Unit ipc handle
  * @rproc_work: work for processing virtio interrupts
  * @pm_comp: completion primitive to sync for suspend response
- * @num_domains: power domain number
  * @flags: control flags
  */
 struct imx_dsp_rproc {
@@ -121,12 +119,10 @@ struct imx_dsp_rproc {
 	struct mbox_chan			*tx_ch;
 	struct mbox_chan			*rx_ch;
 	struct mbox_chan			*rxdb_ch;
-	struct device				**pd_dev;
-	struct device_link			**pd_dev_link;
+	struct dev_pm_domain_list		*pd_list;
 	struct imx_sc_ipc			*ipc_handle;
 	struct work_struct			rproc_work;
 	struct completion			pm_comp;
-	int					num_domains;
 	u32					flags;
 };
 
@@ -954,74 +950,14 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
 static int imx_dsp_attach_pm_domains(struct imx_dsp_rproc *priv)
 {
 	struct device *dev = priv->rproc->dev.parent;
-	int ret, i;
-
-	priv->num_domains = of_count_phandle_with_args(dev->of_node,
-						       "power-domains",
-						       "#power-domain-cells");
-
-	/* If only one domain, then no need to link the device */
-	if (priv->num_domains <= 1)
-		return 0;
-
-	priv->pd_dev = devm_kmalloc_array(dev, priv->num_domains,
-					  sizeof(*priv->pd_dev),
-					  GFP_KERNEL);
-	if (!priv->pd_dev)
-		return -ENOMEM;
-
-	priv->pd_dev_link = devm_kmalloc_array(dev, priv->num_domains,
-					       sizeof(*priv->pd_dev_link),
-					       GFP_KERNEL);
-	if (!priv->pd_dev_link)
-		return -ENOMEM;
-
-	for (i = 0; i < priv->num_domains; i++) {
-		priv->pd_dev[i] = dev_pm_domain_attach_by_id(dev, i);
-		if (IS_ERR(priv->pd_dev[i])) {
-			ret = PTR_ERR(priv->pd_dev[i]);
-			goto detach_pm;
-		}
-
-		/*
-		 * device_link_add will check priv->pd_dev[i], if it is
-		 * NULL, then will break.
-		 */
-		priv->pd_dev_link[i] = device_link_add(dev,
-						       priv->pd_dev[i],
-						       DL_FLAG_STATELESS |
-						       DL_FLAG_PM_RUNTIME);
-		if (!priv->pd_dev_link[i]) {
-			dev_pm_domain_detach(priv->pd_dev[i], false);
-			ret = -EINVAL;
-			goto detach_pm;
-		}
-	}
-
-	return 0;
-
-detach_pm:
-	while (--i >= 0) {
-		device_link_del(priv->pd_dev_link[i]);
-		dev_pm_domain_detach(priv->pd_dev[i], false);
-	}
-
-	return ret;
-}
-
-static int imx_dsp_detach_pm_domains(struct imx_dsp_rproc *priv)
-{
-	int i;
+	int ret;
 
-	if (priv->num_domains <= 1)
+	/* A single PM domain is already attached. */
+	if (dev->pm_domain)
 		return 0;
 
-	for (i = 0; i < priv->num_domains; i++) {
-		device_link_del(priv->pd_dev_link[i]);
-		dev_pm_domain_detach(priv->pd_dev[i], false);
-	}
-
-	return 0;
+	ret = dev_pm_domain_attach_list(dev, NULL, &priv->pd_list);
+	return ret < 0 ? ret : 0;
 }
 
 /**
@@ -1153,7 +1089,7 @@ static int imx_dsp_rproc_probe(struct platform_device *pdev)
 	return 0;
 
 err_detach_domains:
-	imx_dsp_detach_pm_domains(priv);
+	dev_pm_domain_detach_list(priv->pd_list);
 err_put_rproc:
 	rproc_free(rproc);
 
@@ -1167,7 +1103,7 @@ static void imx_dsp_rproc_remove(struct platform_device *pdev)
 
 	pm_runtime_disable(&pdev->dev);
 	rproc_del(rproc);
-	imx_dsp_detach_pm_domains(priv);
+	dev_pm_domain_detach_list(priv->pd_list);
 	rproc_free(rproc);
 }
 
-- 
2.34.1



From ulf.hansson at linaro.org  Thu Dec 28 03:41:55 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 28 Dec 2023 12:41:55 +0100
Subject: [PATCH 3/5] remoteproc: imx_rproc: Convert to dev_pm_domain_attach|detach_list()
In-Reply-To: <20231228114157.104822-1-ulf.hansson@linaro.org>
References: <20231228114157.104822-1-ulf.hansson@linaro.org>
Message-ID: <20231228114157.104822-4-ulf.hansson@linaro.org>

Let's avoid the boilerplate code to manage the multiple PM domain case, by
converting into using dev_pm_domain_attach|detach_list().

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Bjorn Andersson <andersson at kernel.org>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: <linux-remoteproc at vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/remoteproc/imx_rproc.c | 73 +++++-----------------------------
 1 file changed, 9 insertions(+), 64 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 8bb293b9f327..3161f14442bc 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -92,7 +92,6 @@ struct imx_rproc_mem {
 
 static int imx_rproc_xtr_mbox_init(struct rproc *rproc);
 static void imx_rproc_free_mbox(struct rproc *rproc);
-static int imx_rproc_detach_pd(struct rproc *rproc);
 
 struct imx_rproc {
 	struct device			*dev;
@@ -113,10 +112,8 @@ struct imx_rproc {
 	u32				rproc_pt;	/* partition id */
 	u32				rsrc_id;	/* resource id */
 	u32				entry;		/* cpu start address */
-	int                             num_pd;
 	u32				core_index;
-	struct device                   **pd_dev;
-	struct device_link              **pd_dev_link;
+	struct dev_pm_domain_list	*pd_list;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx93[] = {
@@ -853,7 +850,7 @@ static void imx_rproc_put_scu(struct rproc *rproc)
 		return;
 
 	if (imx_sc_rm_is_resource_owned(priv->ipc_handle, priv->rsrc_id)) {
-		imx_rproc_detach_pd(rproc);
+		dev_pm_domain_detach_list(priv->pd_list);
 		return;
 	}
 
@@ -880,72 +877,20 @@ static int imx_rproc_partition_notify(struct notifier_block *nb,
 static int imx_rproc_attach_pd(struct imx_rproc *priv)
 {
 	struct device *dev = priv->dev;
-	int ret, i;
-
-	/*
-	 * If there is only one power-domain entry, the platform driver framework
-	 * will handle it, no need handle it in this driver.
-	 */
-	priv->num_pd = of_count_phandle_with_args(dev->of_node, "power-domains",
-						  "#power-domain-cells");
-	if (priv->num_pd <= 1)
-		return 0;
-
-	priv->pd_dev = devm_kmalloc_array(dev, priv->num_pd, sizeof(*priv->pd_dev), GFP_KERNEL);
-	if (!priv->pd_dev)
-		return -ENOMEM;
-
-	priv->pd_dev_link = devm_kmalloc_array(dev, priv->num_pd, sizeof(*priv->pd_dev_link),
-					       GFP_KERNEL);
-
-	if (!priv->pd_dev_link)
-		return -ENOMEM;
-
-	for (i = 0; i < priv->num_pd; i++) {
-		priv->pd_dev[i] = dev_pm_domain_attach_by_id(dev, i);
-		if (IS_ERR(priv->pd_dev[i])) {
-			ret = PTR_ERR(priv->pd_dev[i]);
-			goto detach_pd;
-		}
-
-		priv->pd_dev_link[i] = device_link_add(dev, priv->pd_dev[i], DL_FLAG_STATELESS |
-						       DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
-		if (!priv->pd_dev_link[i]) {
-			dev_pm_domain_detach(priv->pd_dev[i], false);
-			ret = -EINVAL;
-			goto detach_pd;
-		}
-	}
-
-	return 0;
-
-detach_pd:
-	while (--i >= 0) {
-		device_link_del(priv->pd_dev_link[i]);
-		dev_pm_domain_detach(priv->pd_dev[i], false);
-	}
-
-	return ret;
-}
-
-static int imx_rproc_detach_pd(struct rproc *rproc)
-{
-	struct imx_rproc *priv = rproc->priv;
-	int i;
+	int ret;
+	struct dev_pm_domain_attach_data pd_data = {
+		.pd_flags = PD_FLAG_DEV_LINK_ON,
+	};
 
 	/*
 	 * If there is only one power-domain entry, the platform driver framework
 	 * will handle it, no need handle it in this driver.
 	 */
-	if (priv->num_pd <= 1)
+	if (dev->pm_domain)
 		return 0;
 
-	for (i = 0; i < priv->num_pd; i++) {
-		device_link_del(priv->pd_dev_link[i]);
-		dev_pm_domain_detach(priv->pd_dev[i], false);
-	}
-
-	return 0;
+	ret = dev_pm_domain_attach_list(dev, &pd_data, &priv->pd_list);
+	return ret < 0 ? ret : 0;
 }
 
 static int imx_rproc_detect_mode(struct imx_rproc *priv)
-- 
2.34.1



From ulf.hansson at linaro.org  Thu Dec 28 03:41:56 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 28 Dec 2023 12:41:56 +0100
Subject: [PATCH 4/5] remoteproc: qcom_q6v5_adsp: Convert to dev_pm_domain_attach|detach_list()
In-Reply-To: <20231228114157.104822-1-ulf.hansson@linaro.org>
References: <20231228114157.104822-1-ulf.hansson@linaro.org>
Message-ID: <20231228114157.104822-5-ulf.hansson@linaro.org>

Let's avoid some of the boilerplate code to manage the various PM domain
cases, by converting into using dev_pm_domain_attach|detach_list().

As a part of the conversion, we are moving over to use device_links, which
simplifies the runtime PM support too. Moreover, while attaching let's
trust that an already attached single PM domain is the correct one.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Bjorn Andersson <andersson at kernel.org>
Cc: Konrad Dybcio <konrad.dybcio at linaro.org>
Cc: <linux-remoteproc at vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/remoteproc/qcom_q6v5_adsp.c | 160 +++++++++++++---------------
 1 file changed, 73 insertions(+), 87 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c b/drivers/remoteproc/qcom_q6v5_adsp.c
index 6c67514cc493..93f9a1537ec6 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -55,8 +55,6 @@
 #define QDSP6SS_CORE_CBCR	0x20
 #define QDSP6SS_SLEEP_CBCR	0x3c
 
-#define QCOM_Q6V5_RPROC_PROXY_PD_MAX	3
-
 #define LPASS_BOOT_CORE_START	BIT(0)
 #define LPASS_BOOT_CMD_START	BIT(0)
 #define LPASS_EFUSE_Q6SS_EVB_SEL 0x0
@@ -74,7 +72,8 @@ struct adsp_pil_data {
 
 	const char **clk_ids;
 	int num_clks;
-	const char **proxy_pd_names;
+	const char **pd_names;
+	unsigned int num_pds;
 	const char *load_state;
 };
 
@@ -110,8 +109,7 @@ struct qcom_adsp {
 	size_t mem_size;
 	bool has_iommu;
 
-	struct device *proxy_pds[QCOM_Q6V5_RPROC_PROXY_PD_MAX];
-	size_t proxy_pd_count;
+	struct dev_pm_domain_list *pd_list;
 
 	struct qcom_rproc_glink glink_subdev;
 	struct qcom_rproc_ssr ssr_subdev;
@@ -120,98 +118,92 @@ struct qcom_adsp {
 	int (*shutdown)(struct qcom_adsp *adsp);
 };
 
-static int qcom_rproc_pds_attach(struct device *dev, struct qcom_adsp *adsp,
-				 const char **pd_names)
+static int qcom_rproc_pds_attach(struct qcom_adsp *adsp, const char **pd_names,
+				 unsigned int num_pds)
 {
-	struct device **devs = adsp->proxy_pds;
-	size_t num_pds = 0;
+	struct device *dev = adsp->dev;
+	struct dev_pm_domain_attach_data pd_data = {
+		.pd_names = pd_names,
+		.num_pd_names = num_pds,
+	};
 	int ret;
-	int i;
-
-	if (!pd_names)
-		return 0;
 
 	/* Handle single power domain */
-	if (dev->pm_domain) {
-		devs[0] = dev;
-		pm_runtime_enable(dev);
-		return 1;
-	}
+	if (dev->pm_domain)
+		goto out;
 
-	while (pd_names[num_pds])
-		num_pds++;
+	if (!pd_names)
+		return 0;
 
-	if (num_pds > ARRAY_SIZE(adsp->proxy_pds))
-		return -E2BIG;
+	ret = dev_pm_domain_attach_list(dev, &pd_data, &adsp->pd_list);
+	if (ret < 0)
+		return ret;
 
-	for (i = 0; i < num_pds; i++) {
-		devs[i] = dev_pm_domain_attach_by_name(dev, pd_names[i]);
-		if (IS_ERR_OR_NULL(devs[i])) {
-			ret = PTR_ERR(devs[i]) ? : -ENODATA;
-			goto unroll_attach;
-		}
-	}
+out:
+	pm_runtime_enable(dev);
+	return 0;
+}
 
-	return num_pds;
+static void qcom_rproc_pds_detach(struct qcom_adsp *adsp)
+{
+	struct device *dev = adsp->dev;
+	struct dev_pm_domain_list *pds = adsp->pd_list;
 
-unroll_attach:
-	for (i--; i >= 0; i--)
-		dev_pm_domain_detach(devs[i], false);
+	dev_pm_domain_detach_list(pds);
 
-	return ret;
+	if (dev->pm_domain || pds)
+		pm_runtime_disable(adsp->dev);
 }
 
-static void qcom_rproc_pds_detach(struct qcom_adsp *adsp, struct device **pds,
-				  size_t pd_count)
+static int qcom_rproc_pds_enable(struct qcom_adsp *adsp)
 {
 	struct device *dev = adsp->dev;
-	int i;
+	struct dev_pm_domain_list *pds = adsp->pd_list;
+	int ret, i = 0;
 
-	/* Handle single power domain */
-	if (dev->pm_domain && pd_count) {
-		pm_runtime_disable(dev);
-		return;
-	}
+	if (!dev->pm_domain && !pds)
+		return 0;
 
-	for (i = 0; i < pd_count; i++)
-		dev_pm_domain_detach(pds[i], false);
-}
+	if (dev->pm_domain)
+		dev_pm_genpd_set_performance_state(dev, INT_MAX);
 
-static int qcom_rproc_pds_enable(struct qcom_adsp *adsp, struct device **pds,
-				 size_t pd_count)
-{
-	int ret;
-	int i;
-
-	for (i = 0; i < pd_count; i++) {
-		dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
-		ret = pm_runtime_resume_and_get(pds[i]);
-		if (ret < 0) {
-			dev_pm_genpd_set_performance_state(pds[i], 0);
-			goto unroll_pd_votes;
-		}
+	while (pds && i < pds->num_pds) {
+		dev_pm_genpd_set_performance_state(pds->pd_devs[i], INT_MAX);
+		i++;
 	}
 
-	return 0;
+	ret = pm_runtime_resume_and_get(dev);
+	if (ret < 0) {
+		while (pds && i > 0) {
+			i--;
+			dev_pm_genpd_set_performance_state(pds->pd_devs[i], 0);
+		}
 
-unroll_pd_votes:
-	for (i--; i >= 0; i--) {
-		dev_pm_genpd_set_performance_state(pds[i], 0);
-		pm_runtime_put(pds[i]);
+		if (dev->pm_domain)
+			dev_pm_genpd_set_performance_state(dev, 0);
 	}
 
 	return ret;
 }
 
-static void qcom_rproc_pds_disable(struct qcom_adsp *adsp, struct device **pds,
-				   size_t pd_count)
+static void qcom_rproc_pds_disable(struct qcom_adsp *adsp)
 {
-	int i;
+	struct device *dev = adsp->dev;
+	struct dev_pm_domain_list *pds = adsp->pd_list;
+	int i = 0;
+
+	if (!dev->pm_domain && !pds)
+		return;
+
+	if (dev->pm_domain)
+		dev_pm_genpd_set_performance_state(dev, 0);
 
-	for (i = 0; i < pd_count; i++) {
-		dev_pm_genpd_set_performance_state(pds[i], 0);
-		pm_runtime_put(pds[i]);
+	while (pds && i < pds->num_pds) {
+		dev_pm_genpd_set_performance_state(pds->pd_devs[i], 0);
+		i++;
 	}
+
+	pm_runtime_put(dev);
 }
 
 static int qcom_wpss_shutdown(struct qcom_adsp *adsp)
@@ -397,8 +389,7 @@ static int adsp_start(struct rproc *rproc)
 	if (ret)
 		goto adsp_smmu_unmap;
 
-	ret = qcom_rproc_pds_enable(adsp, adsp->proxy_pds,
-				    adsp->proxy_pd_count);
+	ret = qcom_rproc_pds_enable(adsp);
 	if (ret < 0)
 		goto disable_xo_clk;
 
@@ -448,7 +439,7 @@ static int adsp_start(struct rproc *rproc)
 disable_adsp_clks:
 	clk_bulk_disable_unprepare(adsp->num_clks, adsp->clks);
 disable_power_domain:
-	qcom_rproc_pds_disable(adsp, adsp->proxy_pds, adsp->proxy_pd_count);
+	qcom_rproc_pds_disable(adsp);
 disable_xo_clk:
 	clk_disable_unprepare(adsp->xo);
 adsp_smmu_unmap:
@@ -464,7 +455,7 @@ static void qcom_adsp_pil_handover(struct qcom_q6v5 *q6v5)
 	struct qcom_adsp *adsp = container_of(q6v5, struct qcom_adsp, q6v5);
 
 	clk_disable_unprepare(adsp->xo);
-	qcom_rproc_pds_disable(adsp, adsp->proxy_pds, adsp->proxy_pd_count);
+	qcom_rproc_pds_disable(adsp);
 }
 
 static int adsp_stop(struct rproc *rproc)
@@ -715,13 +706,11 @@ static int adsp_probe(struct platform_device *pdev)
 	if (ret)
 		goto free_rproc;
 
-	ret = qcom_rproc_pds_attach(adsp->dev, adsp,
-				    desc->proxy_pd_names);
+	ret = qcom_rproc_pds_attach(adsp, desc->pd_names, desc->num_pds);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Failed to attach proxy power domains\n");
 		goto free_rproc;
 	}
-	adsp->proxy_pd_count = ret;
 
 	ret = adsp_init_reset(adsp);
 	if (ret)
@@ -753,7 +742,7 @@ static int adsp_probe(struct platform_device *pdev)
 	return 0;
 
 disable_pm:
-	qcom_rproc_pds_detach(adsp, adsp->proxy_pds, adsp->proxy_pd_count);
+	qcom_rproc_pds_detach(adsp);
 
 free_rproc:
 	rproc_free(rproc);
@@ -771,7 +760,7 @@ static void adsp_remove(struct platform_device *pdev)
 	qcom_remove_glink_subdev(adsp->rproc, &adsp->glink_subdev);
 	qcom_remove_sysmon_subdev(adsp->sysmon);
 	qcom_remove_ssr_subdev(adsp->rproc, &adsp->ssr_subdev);
-	qcom_rproc_pds_detach(adsp, adsp->proxy_pds, adsp->proxy_pd_count);
+	qcom_rproc_pds_detach(adsp);
 	rproc_free(adsp->rproc);
 }
 
@@ -788,9 +777,8 @@ static const struct adsp_pil_data adsp_resource_init = {
 		"qdsp6ss_xo", "qdsp6ss_sleep", "qdsp6ss_core", NULL
 	},
 	.num_clks = 7,
-	.proxy_pd_names = (const char*[]) {
-		"cx", NULL
-	},
+	.pd_names = (const char*[]) { "cx" },
+	.num_pds = 1,
 };
 
 static const struct adsp_pil_data adsp_sc7280_resource_init = {
@@ -821,9 +809,8 @@ static const struct adsp_pil_data cdsp_resource_init = {
 		"q6_axim", NULL
 	},
 	.num_clks = 7,
-	.proxy_pd_names = (const char*[]) {
-		"cx", NULL
-	},
+	.pd_names = (const char*[]) { "cx" },
+	.num_pds = 1,
 };
 
 static const struct adsp_pil_data wpss_resource_init = {
@@ -839,9 +826,8 @@ static const struct adsp_pil_data wpss_resource_init = {
 		"ahb_bdg", "ahb", "rscp", NULL
 	},
 	.num_clks = 3,
-	.proxy_pd_names = (const char*[]) {
-		"cx", "mx", NULL
-	},
+	.pd_names = (const char*[]) { "cx", "mx" },
+	.num_pds = 2,
 };
 
 static const struct of_device_id adsp_of_match[] = {
-- 
2.34.1



From ulf.hansson at linaro.org  Thu Dec 28 03:41:57 2023
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 28 Dec 2023 12:41:57 +0100
Subject: [PATCH 5/5] media: venus: Convert to dev_pm_domain_attach|detach_list() for vcodec
In-Reply-To: <20231228114157.104822-1-ulf.hansson@linaro.org>
References: <20231228114157.104822-1-ulf.hansson@linaro.org>
Message-ID: <20231228114157.104822-6-ulf.hansson@linaro.org>

Let's avoid some of the boilerplate code to manage the vcodec PM domains,
by converting into using dev_pm_domain_attach|detach_list().

Cc: Mauro Carvalho Chehab <mchehab at kernel.org>
Cc: Stanimir Varbanov <stanimir.k.varbanov at gmail.com>
Cc: Vikash Garodia <quic_vgarodia at quicinc.com>
Cc: "Bryan O'Donoghue" <bryan.odonoghue at linaro.org>
Cc: Bjorn Andersson <andersson at kernel.org>
Cc: Konrad Dybcio <konrad.dybcio at linaro.org>
Cc: <linux-media at vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/media/platform/qcom/venus/core.c      | 12 +++--
 drivers/media/platform/qcom/venus/core.h      |  7 ++-
 .../media/platform/qcom/venus/pm_helpers.c    | 48 +++++++------------
 3 files changed, 26 insertions(+), 41 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
index 9cffe975581b..bd9b474280e4 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -16,6 +16,7 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 #include <media/videobuf2-v4l2.h>
 #include <media/v4l2-mem2mem.h>
@@ -114,7 +115,8 @@ static void venus_sys_error_handler(struct work_struct *work)
 	pm_runtime_put_sync(core->dev);
 
 	for (i = 0; i < max_attempts; i++) {
-		if (!core->pmdomains[0] || !pm_runtime_active(core->pmdomains[0]))
+		if (!core->pmdomains ||
+		    !pm_runtime_active(core->pmdomains->pd_devs[0]))
 			break;
 		usleep_range(1000, 1500);
 	}
@@ -705,7 +707,7 @@ static const struct venus_resources sdm845_res_v2 = {
 	.vcodec0_clks = { "vcodec0_core", "vcodec0_bus" },
 	.vcodec1_clks = { "vcodec1_core", "vcodec1_bus" },
 	.vcodec_clks_num = 2,
-	.vcodec_pmdomains = { "venus", "vcodec0", "vcodec1" },
+	.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0", "vcodec1" },
 	.vcodec_pmdomains_num = 3,
 	.opp_pmdomain = (const char *[]) { "cx", NULL },
 	.vcodec_num = 2,
@@ -754,7 +756,7 @@ static const struct venus_resources sc7180_res = {
 	.clks_num = 3,
 	.vcodec0_clks = { "vcodec0_core", "vcodec0_bus" },
 	.vcodec_clks_num = 2,
-	.vcodec_pmdomains = { "venus", "vcodec0" },
+	.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0" },
 	.vcodec_pmdomains_num = 2,
 	.opp_pmdomain = (const char *[]) { "cx", NULL },
 	.vcodec_num = 1,
@@ -811,7 +813,7 @@ static const struct venus_resources sm8250_res = {
 	.resets_num = 2,
 	.vcodec0_clks = { "vcodec0_core" },
 	.vcodec_clks_num = 1,
-	.vcodec_pmdomains = { "venus", "vcodec0" },
+	.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0" },
 	.vcodec_pmdomains_num = 2,
 	.opp_pmdomain = (const char *[]) { "mx", NULL },
 	.vcodec_num = 1,
@@ -870,7 +872,7 @@ static const struct venus_resources sc7280_res = {
 	.clks_num = 3,
 	.vcodec0_clks = {"vcodec_core", "vcodec_bus"},
 	.vcodec_clks_num = 2,
-	.vcodec_pmdomains = { "venus", "vcodec0" },
+	.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0" },
 	.vcodec_pmdomains_num = 2,
 	.opp_pmdomain = (const char *[]) { "cx", NULL },
 	.vcodec_num = 1,
diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
index 4a633261ece4..7ef341bf21cc 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -25,7 +25,6 @@
 
 #define VIDC_CLKS_NUM_MAX		4
 #define VIDC_VCODEC_CLKS_NUM_MAX	2
-#define VIDC_PMDOMAINS_NUM_MAX		3
 #define VIDC_RESETS_NUM_MAX		2
 
 extern int venus_fw_debug;
@@ -72,7 +71,7 @@ struct venus_resources {
 	const char * const vcodec0_clks[VIDC_VCODEC_CLKS_NUM_MAX];
 	const char * const vcodec1_clks[VIDC_VCODEC_CLKS_NUM_MAX];
 	unsigned int vcodec_clks_num;
-	const char * const vcodec_pmdomains[VIDC_PMDOMAINS_NUM_MAX];
+	const char **vcodec_pmdomains;
 	unsigned int vcodec_pmdomains_num;
 	const char **opp_pmdomain;
 	unsigned int vcodec_num;
@@ -134,7 +133,7 @@ struct venus_format {
  * @video_path: an interconnect handle to video to/from memory path
  * @cpucfg_path: an interconnect handle to cpu configuration path
  * @has_opp_table: does OPP table exist
- * @pmdomains:	an array of pmdomains struct device pointers
+ * @pmdomains:	a pointer to a list of pmdomains
  * @opp_dl_venus: an device-link for device OPP
  * @opp_pmdomain: an OPP power-domain
  * @resets: an array of reset signals
@@ -187,7 +186,7 @@ struct venus_core {
 	struct icc_path *video_path;
 	struct icc_path *cpucfg_path;
 	bool has_opp_table;
-	struct device *pmdomains[VIDC_PMDOMAINS_NUM_MAX];
+	struct dev_pm_domain_list *pmdomains;
 	struct device_link *opp_dl_venus;
 	struct device *opp_pmdomain;
 	struct reset_control *resets[VIDC_RESETS_NUM_MAX];
diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
index a1b127caa90a..502822059498 100644
--- a/drivers/media/platform/qcom/venus/pm_helpers.c
+++ b/drivers/media/platform/qcom/venus/pm_helpers.c
@@ -455,7 +455,7 @@ static int poweroff_coreid(struct venus_core *core, unsigned int coreid_mask)
 		if (ret)
 			return ret;
 
-		ret = pm_runtime_put_sync(core->pmdomains[1]);
+		ret = pm_runtime_put_sync(core->pmdomains->pd_devs[1]);
 		if (ret < 0)
 			return ret;
 	}
@@ -471,7 +471,7 @@ static int poweroff_coreid(struct venus_core *core, unsigned int coreid_mask)
 		if (ret)
 			return ret;
 
-		ret = pm_runtime_put_sync(core->pmdomains[2]);
+		ret = pm_runtime_put_sync(core->pmdomains->pd_devs[2]);
 		if (ret < 0)
 			return ret;
 	}
@@ -484,7 +484,7 @@ static int poweron_coreid(struct venus_core *core, unsigned int coreid_mask)
 	int ret;
 
 	if (coreid_mask & VIDC_CORE_ID_1) {
-		ret = pm_runtime_get_sync(core->pmdomains[1]);
+		ret = pm_runtime_get_sync(core->pmdomains->pd_devs[1]);
 		if (ret < 0)
 			return ret;
 
@@ -502,7 +502,7 @@ static int poweron_coreid(struct venus_core *core, unsigned int coreid_mask)
 	}
 
 	if (coreid_mask & VIDC_CORE_ID_2) {
-		ret = pm_runtime_get_sync(core->pmdomains[2]);
+		ret = pm_runtime_get_sync(core->pmdomains->pd_devs[2]);
 		if (ret < 0)
 			return ret;
 
@@ -860,19 +860,18 @@ static int vcodec_domains_get(struct venus_core *core)
 	struct device **opp_virt_dev;
 	struct device *dev = core->dev;
 	const struct venus_resources *res = core->res;
-	struct device *pd;
-	unsigned int i;
+	struct dev_pm_domain_attach_data vcodec_data = {
+		.pd_names = res->vcodec_pmdomains,
+		.num_pd_names = res->vcodec_pmdomains_num,
+		.pd_flags = PD_FLAG_NO_DEV_LINK,
+	};
 
 	if (!res->vcodec_pmdomains_num)
 		goto skip_pmdomains;
 
-	for (i = 0; i < res->vcodec_pmdomains_num; i++) {
-		pd = dev_pm_domain_attach_by_name(dev,
-						  res->vcodec_pmdomains[i]);
-		if (IS_ERR_OR_NULL(pd))
-			return pd ? PTR_ERR(pd) : -ENODATA;
-		core->pmdomains[i] = pd;
-	}
+	ret = dev_pm_domain_attach_list(dev, &vcodec_data, &core->pmdomains);
+	if (ret < 0)
+		return ret;
 
 skip_pmdomains:
 	if (!core->res->opp_pmdomain)
@@ -896,30 +895,14 @@ static int vcodec_domains_get(struct venus_core *core)
 	return 0;
 
 opp_attach_err:
-	for (i = 0; i < res->vcodec_pmdomains_num; i++) {
-		if (IS_ERR_OR_NULL(core->pmdomains[i]))
-			continue;
-		dev_pm_domain_detach(core->pmdomains[i], true);
-	}
-
+	dev_pm_domain_detach_list(core->pmdomains);
 	return ret;
 }
 
 static void vcodec_domains_put(struct venus_core *core)
 {
-	const struct venus_resources *res = core->res;
-	unsigned int i;
+	dev_pm_domain_detach_list(core->pmdomains);
 
-	if (!res->vcodec_pmdomains_num)
-		goto skip_pmdomains;
-
-	for (i = 0; i < res->vcodec_pmdomains_num; i++) {
-		if (IS_ERR_OR_NULL(core->pmdomains[i]))
-			continue;
-		dev_pm_domain_detach(core->pmdomains[i], true);
-	}
-
-skip_pmdomains:
 	if (!core->has_opp_table)
 		return;
 
@@ -1035,7 +1018,8 @@ static void core_put_v4(struct venus_core *core)
 static int core_power_v4(struct venus_core *core, int on)
 {
 	struct device *dev = core->dev;
-	struct device *pmctrl = core->pmdomains[0];
+	struct device *pmctrl = core->pmdomains ?
+			core->pmdomains->pd_devs[0] : NULL;
 	int ret = 0;
 
 	if (on == POWER_ON) {
-- 
2.34.1



From konrad.dybcio at linaro.org  Thu Dec 28 03:47:51 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Thu, 28 Dec 2023 12:47:51 +0100
Subject: [PATCH 2/2] firmware/psci: Set
 pm_set_resume/suspend_via_firmware() on qcom
In-Reply-To: <20231228102801.fzaubcjq5thfwgxg@bogus>
References: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
 <20231227-topic-psci_fw_sus-v1-2-6910add70bf3@linaro.org>
 <20231228102801.fzaubcjq5thfwgxg@bogus>
Message-ID: <f34dd5de-9e56-4c58-b9bf-2356b41d17b1@linaro.org>

On 28.12.2023 11:28, Sudeep Holla wrote:
> On Wed, Dec 27, 2023 at 11:15:31PM +0100, Konrad Dybcio wrote:
>> Most Qualcomm platforms implementing PSCI (ab)use CPU_SUSPEND for
>> entering various stages of suspend, across the SoC. These range from a
>> simple WFI to a full-fledged power collapse of the entire chip
>> (mostly, anyway).
>>
>> Some device drivers are curious to know whether "the firmware" (which is
>> often assumed to be ACPI) takes care of suspending or resuming the
>> platform. Set the flag that reports this behavior on the aforementioned
>> chips.
>>
>> Some newer Qualcomm chips ship with firmware that actually advertises
>> PSCI SYSTEM_SUSPEND, so the compatible list should only grow slightly.
>>
> 
> NACK, just use suspend-to-idle if SYSTEM_SUSPEND is not advertised. It is
> designed for such platforms especially on x86/ACPI which don't advertise
> Sx states. I see no reason why that doesn't work on ARM platforms as well.
Not sure if I got the message through well, but the bottom line is, on
Qualcomm platforms the "idle" states aren't actually just "idle" (read:
they're not like S0ix). All but the most shallow ones shut down quite a
chunk of the entire SoC, with the lowest ones being essentially S3 with
power being cut off from the entire chip, except for the memory rail.

Konrad


From sudeep.holla at arm.com  Thu Dec 28 03:50:53 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Thu, 28 Dec 2023 11:50:53 +0000
Subject: [PATCH 2/2] firmware/psci: Set
 pm_set_resume/suspend_via_firmware() on qcom
In-Reply-To: <f34dd5de-9e56-4c58-b9bf-2356b41d17b1@linaro.org>
References: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
 <20231227-topic-psci_fw_sus-v1-2-6910add70bf3@linaro.org>
 <20231228102801.fzaubcjq5thfwgxg@bogus>
 <f34dd5de-9e56-4c58-b9bf-2356b41d17b1@linaro.org>
Message-ID: <20231228115053.zlypgc5uxxvghi4a@bogus>

On Thu, Dec 28, 2023 at 12:47:51PM +0100, Konrad Dybcio wrote:
> On 28.12.2023 11:28, Sudeep Holla wrote:
> > On Wed, Dec 27, 2023 at 11:15:31PM +0100, Konrad Dybcio wrote:
> >> Most Qualcomm platforms implementing PSCI (ab)use CPU_SUSPEND for
> >> entering various stages of suspend, across the SoC. These range from a
> >> simple WFI to a full-fledged power collapse of the entire chip
> >> (mostly, anyway).
> >>
> >> Some device drivers are curious to know whether "the firmware" (which is
> >> often assumed to be ACPI) takes care of suspending or resuming the
> >> platform. Set the flag that reports this behavior on the aforementioned
> >> chips.
> >>
> >> Some newer Qualcomm chips ship with firmware that actually advertises
> >> PSCI SYSTEM_SUSPEND, so the compatible list should only grow slightly.
> >>
> > 
> > NACK, just use suspend-to-idle if SYSTEM_SUSPEND is not advertised. It is
> > designed for such platforms especially on x86/ACPI which don't advertise
> > Sx states. I see no reason why that doesn't work on ARM platforms as well.
>
> Not sure if I got the message through well, but the bottom line is, on
> Qualcomm platforms the "idle" states aren't actually just "idle" (read:
> they're not like S0ix). All but the most shallow ones shut down quite a
> chunk of the entire SoC, with the lowest ones being essentially S3 with
> power being cut off from the entire chip, except for the memory rail.
>

No I understood that and S2I is exactly what you need.
Have you checked if S2I already works as intended on these platforms ?
What extra do you achieve with this hack by advertising fake S2R ?
S2I will have less latency compared to S2R and the mem_sleep will be
automatically set to S2I if S2R is not supported, so no userspace impact
as well.

So please let us know what this change provide extra over S2I ? Until
then my NACK still stands.

--
Regards,
Sudeep


From konrad.dybcio at linaro.org  Thu Dec 28 04:16:28 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Thu, 28 Dec 2023 13:16:28 +0100
Subject: [PATCH 2/2] firmware/psci: Set
 pm_set_resume/suspend_via_firmware() on qcom
In-Reply-To: <20231228115053.zlypgc5uxxvghi4a@bogus>
References: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
 <20231227-topic-psci_fw_sus-v1-2-6910add70bf3@linaro.org>
 <20231228102801.fzaubcjq5thfwgxg@bogus>
 <f34dd5de-9e56-4c58-b9bf-2356b41d17b1@linaro.org>
 <20231228115053.zlypgc5uxxvghi4a@bogus>
Message-ID: <376d3040-b9ed-4574-90d7-fb864d694e3c@linaro.org>

On 28.12.2023 12:50, Sudeep Holla wrote:
> On Thu, Dec 28, 2023 at 12:47:51PM +0100, Konrad Dybcio wrote:
>> On 28.12.2023 11:28, Sudeep Holla wrote:
>>> On Wed, Dec 27, 2023 at 11:15:31PM +0100, Konrad Dybcio wrote:
>>>> Most Qualcomm platforms implementing PSCI (ab)use CPU_SUSPEND for
>>>> entering various stages of suspend, across the SoC. These range from a
>>>> simple WFI to a full-fledged power collapse of the entire chip
>>>> (mostly, anyway).
>>>>
>>>> Some device drivers are curious to know whether "the firmware" (which is
>>>> often assumed to be ACPI) takes care of suspending or resuming the
>>>> platform. Set the flag that reports this behavior on the aforementioned
>>>> chips.
>>>>
>>>> Some newer Qualcomm chips ship with firmware that actually advertises
>>>> PSCI SYSTEM_SUSPEND, so the compatible list should only grow slightly.
>>>>
>>>
>>> NACK, just use suspend-to-idle if SYSTEM_SUSPEND is not advertised. It is
>>> designed for such platforms especially on x86/ACPI which don't advertise
>>> Sx states. I see no reason why that doesn't work on ARM platforms as well.
>>
>> Not sure if I got the message through well, but the bottom line is, on
>> Qualcomm platforms the "idle" states aren't actually just "idle" (read:
>> they're not like S0ix). All but the most shallow ones shut down quite a
>> chunk of the entire SoC, with the lowest ones being essentially S3 with
>> power being cut off from the entire chip, except for the memory rail.
>>
> 
> No I understood that and S2I is exactly what you need.
> Have you checked if S2I already works as intended on these platforms ?
Yes, simple CPU idling works OOTB and the SoC power collapse only works
given the developer doesn't cut corners when bringing up the platform
(read: works on some of the ones we support, trying hard to expand that
group!)

> What extra do you achieve with this hack by advertising fake S2R ?
Uh.. unless I misunderstood something, I'm not advertising s2ram..
Quite the opposite, I'm making sure only s2idle is allowed.

Admittedly, my mistake, I managed to misname the function which I
didn't spot before wrapping this patch up for sending..

> S2I will have less latency compared to S2R and the mem_sleep will be
> automatically set to S2I if S2R is not supported, so no userspace impact
> as well.
Yes, everything that differs them is abstracted in TZ or through the
power management coprocessor.

> 
> So please let us know what this change provide extra over S2I ? Until
> then my NACK still stands.
The main point here is to advertise pm_resume/suspend_via_firmware,
which represents that Qualcomm does a lot of not-very-obvious power
wire plumbing within their PSCI impl.

Konrad


From sudeep.holla at arm.com  Thu Dec 28 04:43:48 2023
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Thu, 28 Dec 2023 12:43:48 +0000
Subject: [PATCH 2/2] firmware/psci: Set
 pm_set_resume/suspend_via_firmware() on qcom
In-Reply-To: <376d3040-b9ed-4574-90d7-fb864d694e3c@linaro.org>
References: <20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org>
 <20231227-topic-psci_fw_sus-v1-2-6910add70bf3@linaro.org>
 <20231228102801.fzaubcjq5thfwgxg@bogus>
 <f34dd5de-9e56-4c58-b9bf-2356b41d17b1@linaro.org>
 <20231228115053.zlypgc5uxxvghi4a@bogus>
 <376d3040-b9ed-4574-90d7-fb864d694e3c@linaro.org>
Message-ID: <20231228124348.mmtceqeuean7ly6y@bogus>

On Thu, Dec 28, 2023 at 01:16:28PM +0100, Konrad Dybcio wrote:
> On 28.12.2023 12:50, Sudeep Holla wrote:
> > On Thu, Dec 28, 2023 at 12:47:51PM +0100, Konrad Dybcio wrote:
> >> On 28.12.2023 11:28, Sudeep Holla wrote:
> >>> On Wed, Dec 27, 2023 at 11:15:31PM +0100, Konrad Dybcio wrote:
> >>>> Most Qualcomm platforms implementing PSCI (ab)use CPU_SUSPEND for
> >>>> entering various stages of suspend, across the SoC. These range from a
> >>>> simple WFI to a full-fledged power collapse of the entire chip
> >>>> (mostly, anyway).
> >>>>
> >>>> Some device drivers are curious to know whether "the firmware" (which is
> >>>> often assumed to be ACPI) takes care of suspending or resuming the
> >>>> platform. Set the flag that reports this behavior on the aforementioned
> >>>> chips.
> >>>>
> >>>> Some newer Qualcomm chips ship with firmware that actually advertises
> >>>> PSCI SYSTEM_SUSPEND, so the compatible list should only grow slightly.
> >>>>
> >>>
> >>> NACK, just use suspend-to-idle if SYSTEM_SUSPEND is not advertised. It is
> >>> designed for such platforms especially on x86/ACPI which don't advertise
> >>> Sx states. I see no reason why that doesn't work on ARM platforms as well.
> >>
> >> Not sure if I got the message through well, but the bottom line is, on
> >> Qualcomm platforms the "idle" states aren't actually just "idle" (read:
> >> they're not like S0ix). All but the most shallow ones shut down quite a
> >> chunk of the entire SoC, with the lowest ones being essentially S3 with
> >> power being cut off from the entire chip, except for the memory rail.
> >>
> > 
> > No I understood that and S2I is exactly what you need.
> > Have you checked if S2I already works as intended on these platforms ?
> Yes, simple CPU idling works OOTB and the SoC power collapse only works
> given the developer doesn't cut corners when bringing up the platform
> (read: works on some of the ones we support, trying hard to expand that
> group!)
> 
> > What extra do you achieve with this hack by advertising fake S2R ?
> Uh.. unless I misunderstood something, I'm not advertising s2ram..
> Quite the opposite, I'm making sure only s2idle is allowed.
>

Right, I didn't notice that in suspend_valid_all(), it can be rename
suspend_valid_s2i or something. "All" indicates all state is valid.

Anyways that is not the main point. IIUC S2I must still work if there is
at-least one CPU idle state other than WFI without these changes. Right ?

If all these changes is to support S2I wih WFI only, then we can look at
some generic solution as there were previous attempts to do something
similar on other platforms IIRC.

-- 
Regards,
Sudeep


From tudor.ambarus at linaro.org  Thu Dec 28 04:57:53 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:57:53 +0000
Subject: [PATCH v2 00/12] GS101 Oriole: CMU_PERIC0 support and USI updates
Message-ID: <20231228125805.661725-1-tudor.ambarus@linaro.org>

Add support for PERIC0 clocks. Use them for USI in serial and I2C
configurations. Tested the serial at different baudrates (115200,
1M, 3M) and the I2C with an at24 eeprom, all went fine.

Apart of the DT and defconfig changes, the patch set spans through the tty
and clk subsystems. The expectation is that Krzysztof will apply the whole
series through the Samsung SoC tree. If the tty and clk subsystem
maintainers can give an acked-by or reviewed-by on the relevant patches
that would be most appreciated!

Thanks!
ta

changes in v2:
- gs101 serial - infer the reg-io-width from the compatible as the entire
  PERIC block allows just 32-bit register accesses.
- identify the critical clocks from PERIC0 and mark them accordingly
  (if disabled these clocks hang the system even if their parents are
   still enabled).
- update dtsi and use USI's gate clocks instead of the dividers clocks
- move hsi2c_8 cells and pinctrls into dtsi
- address Sam's cosmetic changes in the device tree files
- drop defconfig patches (savedefconfig output & at24 eeprom enablement)
- collect Acked-by and Reviewed-by tags
- changes log in each patch as well, in the comments section under
  ```---```


Tudor Ambarus (12):
  dt-bindings: clock: google,gs101-clock: add PERIC0 clock management
    unit
  dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
  dt-bindings: serial: samsung: do not allow reg-io-width for gs101
  tty: serial: samsung: prepare for different IO types
  tty: serial: samsung: set UPIO_MEM32 iotype for gs101
  tty: serial: samsung: add gs101 earlycon support
  clk: samsung: gs101: add support for cmu_peric0
  arm64: dts: exynos: gs101: remove reg-io-width from serial
  arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
  arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
  arm64: dts: exynos: gs101: define USI8 with I2C configuration
  arm64: dts: exynos: gs101: enable eeprom on gs101-oriole

 .../bindings/clock/google,gs101-clock.yaml    |  25 +-
 .../devicetree/bindings/i2c/i2c-exynos5.yaml  |   1 +
 .../bindings/serial/samsung_uart.yaml         |   2 +
 .../boot/dts/exynos/google/gs101-oriole.dts   |  14 +
 arch/arm64/boot/dts/exynos/google/gs101.dtsi  |  56 +-
 drivers/clk/samsung/clk-gs101.c               | 583 ++++++++++++++++++
 drivers/tty/serial/samsung_tty.c              |  58 +-
 include/dt-bindings/clock/google,gs101.h      |  81 +++
 8 files changed, 796 insertions(+), 24 deletions(-)

-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:57:55 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:57:55 +0000
Subject: [PATCH v2 02/12] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-3-tudor.ambarus@linaro.org>

Add google,gs101-hsi2c dedicated compatible for representing
I2C of Google GS101 SoC.

Acked-by: Wolfram Sang <wsa at kernel.org>
Acked-by: Rob Herring <robh at kernel.org>
Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2: collect tags

 Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
index df9c57bca2a8..cc8bba5537b9 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
@@ -33,6 +33,7 @@ properties:
           - const: samsung,exynos7-hsi2c
       - items:
           - enum:
+              - google,gs101-hsi2c
               - samsung,exynos850-hsi2c
           - const: samsung,exynosautov9-hsi2c
       - const: samsung,exynos5-hsi2c    # Exynos5250 and Exynos5420
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:57:54 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:57:54 +0000
Subject: [PATCH v2 01/12] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-2-tudor.ambarus@linaro.org>

Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
clock management unit.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2:
- fix comments as per Sam's suggestion and collect his R-b tag
- Rob's suggestion of renaming the clock-names to just "bus" and "ip"
  was not implemented as I felt it affects readability in the driver
  and consistency with other exynos clock drivers. I will happily update
  the names in the -rc phase if someone else has a stronger opinion than
  mine. 

 .../bindings/clock/google,gs101-clock.yaml    | 25 +++++-
 include/dt-bindings/clock/google,gs101.h      | 81 +++++++++++++++++++
 2 files changed, 104 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
index 3eebc03a309b..ba54c13c55bc 100644
--- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -30,14 +30,15 @@ properties:
       - google,gs101-cmu-top
       - google,gs101-cmu-apm
       - google,gs101-cmu-misc
+      - google,gs101-cmu-peric0
 
   clocks:
     minItems: 1
-    maxItems: 2
+    maxItems: 3
 
   clock-names:
     minItems: 1
-    maxItems: 2
+    maxItems: 3
 
   "#clock-cells":
     const: 1
@@ -88,6 +89,26 @@ allOf:
             - const: dout_cmu_misc_bus
             - const: dout_cmu_misc_sss
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-peric0
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+            - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
+            - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
+
+        clock-names:
+          items:
+            - const: oscclk
+            - const: dout_cmu_peric0_bus
+            - const: dout_cmu_peric0_ip
+
 additionalProperties: false
 
 examples:
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
index 21adec22387c..64e6bdc6359c 100644
--- a/include/dt-bindings/clock/google,gs101.h
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -389,4 +389,85 @@
 #define CLK_GOUT_MISC_WDT_CLUSTER1_PCLK			73
 #define CLK_GOUT_MISC_XIU_D_MISC_ACLK			74
 
+/* CMU_PERIC0 */
+#define CLK_MOUT_PERIC0_BUS_USER			1
+#define CLK_MOUT_PERIC0_I3C_USER			2
+#define CLK_MOUT_PERIC0_USI0_UART_USER			3
+#define CLK_MOUT_PERIC0_USI14_USI_USER			4
+#define CLK_MOUT_PERIC0_USI1_USI_USER			5
+#define CLK_MOUT_PERIC0_USI2_USI_USER			6
+#define CLK_MOUT_PERIC0_USI3_USI_USER			7
+#define CLK_MOUT_PERIC0_USI4_USI_USER			8
+#define CLK_MOUT_PERIC0_USI5_USI_USER			9
+#define CLK_MOUT_PERIC0_USI6_USI_USER			10
+#define CLK_MOUT_PERIC0_USI7_USI_USER			11
+#define CLK_MOUT_PERIC0_USI8_USI_USER			12
+#define CLK_DOUT_PERIC0_I3C				13
+#define CLK_DOUT_PERIC0_USI0_UART			14
+#define CLK_DOUT_PERIC0_USI14_USI			15
+#define CLK_DOUT_PERIC0_USI1_USI			16
+#define CLK_DOUT_PERIC0_USI2_USI			17
+#define CLK_DOUT_PERIC0_USI3_USI			18
+#define CLK_DOUT_PERIC0_USI4_USI			19
+#define CLK_DOUT_PERIC0_USI5_USI			20
+#define CLK_DOUT_PERIC0_USI6_USI			21
+#define CLK_DOUT_PERIC0_USI7_USI			22
+#define CLK_DOUT_PERIC0_USI8_USI			23
+#define CLK_GOUT_PERIC0_IP				24
+#define CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK		25
+#define CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK		26
+#define CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK		27
+#define CLK_GOUT_PERIC0_GPC_PERIC0_PCLK			28
+#define CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK		29
+#define CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK		30
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0		31
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1		32
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10		33
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11		34
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12		35
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13		36
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14		37
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15		38
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2		39
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3		40
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4		41
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5		42
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6		43
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7		44
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8		45
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9		46
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0		47
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1		48
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10		49
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11		50
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12		51
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13		52
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14		53
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15		54
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2		55
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3		56
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4		57
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5		58
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6		59
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7		60
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8		61
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9		62
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0		63
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2		64
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0		65
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2		66
+#define CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK		67
+#define CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK		68
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK	69
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK	70
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK		71
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK		72
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK		73
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK		74
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK		75
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK		76
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK		77
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK		78
+#define CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK		79
+
 #endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:57:56 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:57:56 +0000
Subject: [PATCH v2 03/12] dt-bindings: serial: samsung: do not allow reg-io-width for gs101
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-4-tudor.ambarus@linaro.org>

All gs101 serial ports are restricted to 32-bit register accesses.
This requirement will be inferred from the compatible. Do not allow
the reg-io-width property for the google,gs101-uart compatible.

Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2: new patch

 Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index 133259ed3a34..0f0131026911 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -143,6 +143,8 @@ allOf:
     then:
       required:
         - samsung,uart-fifosize
+      properties:
+        reg-io-width: false
 
 unevaluatedProperties: false
 
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:57:57 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:57:57 +0000
Subject: [PATCH v2 04/12] tty: serial: samsung: prepare for different IO types
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-5-tudor.ambarus@linaro.org>

GS101's Connectivity Peripheral blocks (peric0/1 blocks) which
include the I3C and USI (I2C, SPI, UART) only allow 32-bit
register accesses. If using 8-bit register accesses, a SError
Interrupt is raised causing the system unusable.

Instead of specifying the reg-io-width = 4 everywhere, for each node,
the requirement should be deduced from the compatible.

Prepare the samsung tty driver to allow IO types different than
UPIO_MEM. ``struct uart_port::iotype`` is an unsigned char where all
its 8 bits are exposed to uapi. We can't make NULL checks on it to
verify if it's set, thus always set it from the driver's data.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2: new patch

 drivers/tty/serial/samsung_tty.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 66bd6c090ace..97ce4b2424af 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -72,6 +72,7 @@ struct s3c24xx_uart_info {
 	const char		*name;
 	enum s3c24xx_port_type	type;
 	unsigned int		port_type;
+	unsigned char		iotype;
 	unsigned int		fifosize;
 	unsigned long		rx_fifomask;
 	unsigned long		rx_fifoshift;
@@ -1742,7 +1743,6 @@ static void s3c24xx_serial_init_port_default(int index) {
 
 	spin_lock_init(&port->lock);
 
-	port->iotype = UPIO_MEM;
 	port->uartclk = 0;
 	port->fifosize = 16;
 	port->flags = UPF_BOOT_AUTOCONF;
@@ -1989,6 +1989,8 @@ static int s3c24xx_serial_probe(struct platform_device *pdev)
 		break;
 	}
 
+	ourport->port.iotype = ourport->info->iotype;
+
 	if (np) {
 		of_property_read_u32(np,
 			"samsung,uart-fifosize", &ourport->port.fifosize);
@@ -2401,6 +2403,7 @@ static const struct s3c24xx_serial_drv_data s3c6400_serial_drv_data = {
 		.name		= "Samsung S3C6400 UART",
 		.type		= TYPE_S3C6400,
 		.port_type	= PORT_S3C6400,
+		.iotype		= UPIO_MEM,
 		.fifosize	= 64,
 		.has_divslot	= 1,
 		.rx_fifomask	= S3C2440_UFSTAT_RXMASK,
@@ -2430,6 +2433,7 @@ static const struct s3c24xx_serial_drv_data s5pv210_serial_drv_data = {
 		.name		= "Samsung S5PV210 UART",
 		.type		= TYPE_S3C6400,
 		.port_type	= PORT_S3C6400,
+		.iotype		= UPIO_MEM,
 		.has_divslot	= 1,
 		.rx_fifomask	= S5PV210_UFSTAT_RXMASK,
 		.rx_fifoshift	= S5PV210_UFSTAT_RXSHIFT,
@@ -2459,6 +2463,7 @@ static const struct s3c24xx_serial_drv_data s5pv210_serial_drv_data = {
 		.name		= "Samsung Exynos UART",	\
 		.type		= TYPE_S3C6400,			\
 		.port_type	= PORT_S3C6400,			\
+		.iotype		= UPIO_MEM,			\
 		.has_divslot	= 1,				\
 		.rx_fifomask	= S5PV210_UFSTAT_RXMASK,	\
 		.rx_fifoshift	= S5PV210_UFSTAT_RXSHIFT,	\
@@ -2519,6 +2524,7 @@ static const struct s3c24xx_serial_drv_data s5l_serial_drv_data = {
 		.name		= "Apple S5L UART",
 		.type		= TYPE_APPLE_S5L,
 		.port_type	= PORT_8250,
+		.iotype		= UPIO_MEM,
 		.fifosize	= 16,
 		.rx_fifomask	= S3C2410_UFSTAT_RXMASK,
 		.rx_fifoshift	= S3C2410_UFSTAT_RXSHIFT,
@@ -2548,6 +2554,7 @@ static const struct s3c24xx_serial_drv_data artpec8_serial_drv_data = {
 		.name		= "Axis ARTPEC-8 UART",
 		.type		= TYPE_S3C6400,
 		.port_type	= PORT_S3C6400,
+		.iotype		= UPIO_MEM,
 		.fifosize	= 64,
 		.has_divslot	= 1,
 		.rx_fifomask	= S5PV210_UFSTAT_RXMASK,
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:57:58 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:57:58 +0000
Subject: [PATCH v2 05/12] tty: serial: samsung: set UPIO_MEM32 iotype for gs101
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-6-tudor.ambarus@linaro.org>

GS101's Connectivity Peripheral blocks (peric0/1 blocks) which
include the I3C and USI (I2C, SPI, UART) only allow 32-bit
register accesses.

Instead of specifying the reg-io-width = 4 everywhere, for each node,
the requirement should be deduced from the compatible.

Infer UPIO_MEM32 iotype from the "google,gs101-uart" compatible.
Update the uart info name to be GS101 specific in order to
differentiate from the other exynos platforms. All the other settings
are not changed.

exynos_fifoszdt_serial_drv_data was replaced by gs101_serial_drv_data
because the iotype restriction is gs101 specific and there was no other
user of exynos_fifoszdt_serial_drv_data.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2: new patch

 drivers/tty/serial/samsung_tty.c | 38 +++++++++++++++++++++++---------
 1 file changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 97ce4b2424af..938127179acf 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2497,25 +2497,43 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
 	.fifosize = { 256, 64, 64, 64 },
 };
 
-/*
- * Common drv_data struct for platforms that specify samsung,uart-fifosize in
- * device tree.
- */
-static const struct s3c24xx_serial_drv_data exynos_fifoszdt_serial_drv_data = {
-	EXYNOS_COMMON_SERIAL_DRV_DATA(),
+static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
+	.info = {
+		.name		= "Google GS101 UART",
+		.type		= TYPE_S3C6400,
+		.port_type	= PORT_S3C6400,
+		.iotype		= UPIO_MEM32,
+		.has_divslot	= 1,
+		.rx_fifomask	= S5PV210_UFSTAT_RXMASK,
+		.rx_fifoshift	= S5PV210_UFSTAT_RXSHIFT,
+		.rx_fifofull	= S5PV210_UFSTAT_RXFULL,
+		.tx_fifofull	= S5PV210_UFSTAT_TXFULL,
+		.tx_fifomask	= S5PV210_UFSTAT_TXMASK,
+		.tx_fifoshift	= S5PV210_UFSTAT_TXSHIFT,
+		.def_clk_sel	= S3C2410_UCON_CLKSEL0,
+		.num_clks	= 1,
+		.clksel_mask	= 0,
+		.clksel_shift	= 0,
+	},
+	.def_cfg = {
+		.ucon		= S5PV210_UCON_DEFAULT,
+		.ufcon		= S5PV210_UFCON_DEFAULT,
+		.has_fracval	= 1,
+	},
+	/* samsung,uart-fifosize must be specified in the device tree. */
 	.fifosize = { 0 },
 };
 
 #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
 #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
 #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
-#define EXYNOS_FIFOSZDT_DRV_DATA (&exynos_fifoszdt_serial_drv_data)
+#define GS101_SERIAL_DRV_DATA (&gs101_serial_drv_data)
 
 #else
 #define EXYNOS4210_SERIAL_DRV_DATA NULL
 #define EXYNOS5433_SERIAL_DRV_DATA NULL
 #define EXYNOS850_SERIAL_DRV_DATA NULL
-#define EXYNOS_FIFOSZDT_DRV_DATA NULL
+#define GS101_SERIAL_DRV_DATA NULL
 #endif
 
 #ifdef CONFIG_ARCH_APPLE
@@ -2603,7 +2621,7 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
 		.driver_data	= (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
 	}, {
 		.name		= "gs101-uart",
-		.driver_data	= (kernel_ulong_t)EXYNOS_FIFOSZDT_DRV_DATA,
+		.driver_data	= (kernel_ulong_t)GS101_SERIAL_DRV_DATA,
 	},
 	{ },
 };
@@ -2626,7 +2644,7 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
 	{ .compatible = "axis,artpec8-uart",
 		.data = ARTPEC8_SERIAL_DRV_DATA },
 	{ .compatible = "google,gs101-uart",
-		.data = EXYNOS_FIFOSZDT_DRV_DATA },
+		.data = GS101_SERIAL_DRV_DATA },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:57:59 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:57:59 +0000
Subject: [PATCH v2 06/12] tty: serial: samsung: add gs101 earlycon support
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-7-tudor.ambarus@linaro.org>

The entire bus (PERIC) on which the GS101 serial resides only allows
32-bit register accesses. The reg-io-width dt property is disallowed
for the "google,gs101-uart" compatible and instead the iotype is
inferred from the compatible. Always set UPIO_MEM32 iotype for the
gs101 earlycon.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2: update commit message

 drivers/tty/serial/samsung_tty.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 938127179acf..2fbaaf0e756b 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2812,6 +2812,17 @@ OF_EARLYCON_DECLARE(exynos4210, "samsung,exynos4210-uart",
 OF_EARLYCON_DECLARE(artpec8, "axis,artpec8-uart",
 			s5pv210_early_console_setup);
 
+static int __init gs101_early_console_setup(struct earlycon_device *device,
+					    const char *opt)
+{
+	/* gs101 always expects MMIO32 register accesses. */
+	device->port.iotype = UPIO_MEM32;
+
+	return s5pv210_early_console_setup(device, opt);
+}
+
+OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);
+
 /* Apple S5L */
 static int __init apple_s5l_early_console_setup(struct earlycon_device *device,
 						const char *opt)
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:58:01 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:58:01 +0000
Subject: [PATCH v2 08/12] arm64: dts: exynos: gs101: remove reg-io-width from serial
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-9-tudor.ambarus@linaro.org>

Remove the reg-io-width property in order to comply with the bindings.

The entire bus (PERIC) on which the GS101 serial resides only allows
32-bit register accesses. The reg-io-width dt property is disallowed
for the "google,gs101-uart" compatible and instead the iotype is
inferred from the compatible.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2: new patch

 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 9747cb3fa03a..2c27c3cb9237 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -366,7 +366,6 @@ usi_uart: usi at 10a000c0 {
 			serial_0: serial at 10a00000 {
 				compatible = "google,gs101-uart";
 				reg = <0x10a00000 0xc0>;
-				reg-io-width = <4>;
 				interrupts = <GIC_SPI 634
 					      IRQ_TYPE_LEVEL_HIGH 0>;
 				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:58:02 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:58:02 +0000
Subject: [PATCH v2 09/12] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-10-tudor.ambarus@linaro.org>

Enable the cmu-peric0 clock controller. It feeds USI and I3c.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2: collect R-b

 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 2c27c3cb9237..c693791ae584 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
 			};
 		};
 
+		cmu_peric0: clock-controller at 10800000 {
+			compatible = "google,gs101-cmu-peric0";
+			reg = <0x10800000 0x4000>;
+			#clock-cells = <1>;
+			clocks = <&ext_24_5m>,
+				 <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
+				 <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
+			clock-names = "oscclk",
+				      "dout_cmu_peric0_bus",
+				      "dout_cmu_peric0_ip";
+		};
+
 		sysreg_peric0: syscon at 10820000 {
 			compatible = "google,gs101-peric0-sysreg", "syscon";
 			reg = <0x10820000 0x10000>;
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:58:00 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:58:00 +0000
Subject: [PATCH v2 07/12] clk: samsung: gs101: add support for cmu_peric0
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-8-tudor.ambarus@linaro.org>

CMU_PERIC0 is the clock management unit used for the peric0 block which
is used for USI and I3C. Add support for all cmu_peric0 clocks but
CLK_GOUT_PERIC0_IP (not enough info in the datasheet).

Few clocks are marked as critical because when either of them is
disabled, the system hangs even if their clock parents are enabled.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2:
- update commit message
- identify and mark critical clocks

 drivers/clk/samsung/clk-gs101.c | 583 ++++++++++++++++++++++++++++++++
 1 file changed, 583 insertions(+)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 0964bb11657f..68a27b78b00b 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -20,6 +20,7 @@
 #define CLKS_NR_TOP	(CLK_GOUT_CMU_TPU_UART + 1)
 #define CLKS_NR_APM	(CLK_APM_PLL_DIV16_APM + 1)
 #define CLKS_NR_MISC	(CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
+#define CLKS_NR_PERIC0	(CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK + 1)
 
 /* ---- CMU_TOP ------------------------------------------------------------- */
 
@@ -2478,6 +2479,585 @@ static const struct samsung_cmu_info misc_cmu_info __initconst = {
 	.clk_name		= "dout_cmu_misc_bus",
 };
 
+/* ---- CMU_PERIC0 ---------------------------------------------------------- */
+
+/* Register Offset definitions for CMU_PERIC0 (0x10800000) */
+#define PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER		0x0600
+#define PLL_CON1_MUX_CLKCMU_PERIC0_BUS_USER		0x0604
+#define PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER		0x0610
+#define PLL_CON1_MUX_CLKCMU_PERIC0_I3C_USER		0x0614
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER	0x0620
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI0_UART_USER	0x0624
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER	0x0640
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI14_USI_USER	0x0644
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER	0x0650
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI1_USI_USER	0x0654
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER	0x0660
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI2_USI_USER	0x0664
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER	0x0670
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI3_USI_USER	0x0674
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER	0x0680
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI4_USI_USER	0x0684
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER	0x0690
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI5_USI_USER	0x0694
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER	0x06a0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI6_USI_USER	0x06a4
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER	0x06b0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI7_USI_USER	0x06b4
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER	0x06c0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI8_USI_USER	0x06c4
+#define PERIC0_CMU_PERIC0_CONTROLLER_OPTION		0x0800
+#define CLKOUT_CON_BLK_PERIC0_CMU_PERIC0_CLKOUT0	0x0810
+#define CLK_CON_DIV_DIV_CLK_PERIC0_I3C			0x1800
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART		0x1804
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI		0x180c
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI		0x1810
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI		0x1814
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI		0x1820
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI		0x1824
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI		0x1828
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI		0x182c
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI7_USI		0x1830
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI		0x1834
+#define CLK_CON_BUF_CLKBUF_PERIC0_IP			0x2000
+#define CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK			0x2004
+#define CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK		0x2008
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK			0x200c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK			0x2010
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK			0x2014
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK		0x2018
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0			0x201c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1			0x2020
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10			0x2024
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11			0x2028
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12			0x202c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13			0x2030
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14			0x2034
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15			0x2038
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2			0x203c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3			0x2040
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4			0x2044
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5			0x2048
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6			0x204c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7			0x2050
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8			0x2054
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9			0x2058
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0			0x205c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1			0x2060
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10			0x2064
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11			0x2068
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12			0x206c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13			0x2070
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14			0x2074
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15			0x2078
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2			0x207c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3			0x2080
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4			0x2084
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5			0x2088
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6			0x208c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7			0x2090
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8			0x2094
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9			0x2098
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0			0x209c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2			0x20a4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0			0x20a8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2			0x20b0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK		0x20b4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK		0x20b8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK	0x20bc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK	0x20c4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK	0x20c8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK	0x20cc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK	0x20d0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK	0x20d4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK	0x20d8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK	0x20dc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK	0x20e0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK	0x20e4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK			0x20e8
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S1			0x3000
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S2			0x3004
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S3			0x3008
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S4			0x300c
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S5			0x3010
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S6			0x3014
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S7			0x3018
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S8			0x301c
+#define PCH_CON_LHM_AXI_P_PERIC0_PCH			0x3020
+#define QCH_CON_D_TZPC_PERIC0_QCH			0x3024
+#define QCH_CON_GPC_PERIC0_QCH				0x3028
+#define QCH_CON_GPIO_PERIC0_QCH				0x302c
+#define QCH_CON_LHM_AXI_P_PERIC0_QCH			0x3030
+#define QCH_CON_PERIC0_CMU_PERIC0_QCH			0x3034
+#define QCH_CON_PERIC0_TOP0_QCH_I3C1			0x3038
+#define QCH_CON_PERIC0_TOP0_QCH_I3C2			0x303c
+#define QCH_CON_PERIC0_TOP0_QCH_I3C3			0x3040
+#define QCH_CON_PERIC0_TOP0_QCH_I3C4			0x3044
+#define QCH_CON_PERIC0_TOP0_QCH_I3C5			0x3048
+#define QCH_CON_PERIC0_TOP0_QCH_I3C6			0x304c
+#define QCH_CON_PERIC0_TOP0_QCH_I3C7			0x3050
+#define QCH_CON_PERIC0_TOP0_QCH_I3C8			0x3054
+#define QCH_CON_PERIC0_TOP0_QCH_USI1_USI		0x3058
+#define QCH_CON_PERIC0_TOP0_QCH_USI2_USI		0x305c
+#define QCH_CON_PERIC0_TOP0_QCH_USI3_USI		0x3060
+#define QCH_CON_PERIC0_TOP0_QCH_USI4_USI		0x3064
+#define QCH_CON_PERIC0_TOP0_QCH_USI5_USI		0x3068
+#define QCH_CON_PERIC0_TOP0_QCH_USI6_USI		0x306c
+#define QCH_CON_PERIC0_TOP0_QCH_USI7_USI		0x3070
+#define QCH_CON_PERIC0_TOP0_QCH_USI8_USI		0x3074
+#define QCH_CON_PERIC0_TOP1_QCH_USI0_UART		0x3078
+#define QCH_CON_PERIC0_TOP1_QCH_USI14_UART		0x307c
+#define QCH_CON_SYSREG_PERIC0_QCH			0x3080
+#define QUEUE_CTRL_REG_BLK_PERIC0_CMU_PERIC0		0x3c00
+
+static const unsigned long peric0_clk_regs[] __initconst = {
+	PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_BUS_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_I3C_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI0_UART_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI14_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI1_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI2_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI3_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI4_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI5_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI6_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI7_USI_USER,
+	PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER,
+	PLL_CON1_MUX_CLKCMU_PERIC0_USI8_USI_USER,
+	PERIC0_CMU_PERIC0_CONTROLLER_OPTION,
+	CLKOUT_CON_BLK_PERIC0_CMU_PERIC0_CLKOUT0,
+	CLK_CON_DIV_DIV_CLK_PERIC0_I3C,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI,
+	CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI,
+	CLK_CON_BUF_CLKBUF_PERIC0_IP,
+	CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S1,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S2,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S3,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S4,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S5,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S6,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S7,
+	DMYQCH_CON_PERIC0_TOP0_QCH_S8,
+	PCH_CON_LHM_AXI_P_PERIC0_PCH,
+	QCH_CON_D_TZPC_PERIC0_QCH,
+	QCH_CON_GPC_PERIC0_QCH,
+	QCH_CON_GPIO_PERIC0_QCH,
+	QCH_CON_LHM_AXI_P_PERIC0_QCH,
+	QCH_CON_PERIC0_CMU_PERIC0_QCH,
+	QCH_CON_PERIC0_TOP0_QCH_I3C1,
+	QCH_CON_PERIC0_TOP0_QCH_I3C2,
+	QCH_CON_PERIC0_TOP0_QCH_I3C3,
+	QCH_CON_PERIC0_TOP0_QCH_I3C4,
+	QCH_CON_PERIC0_TOP0_QCH_I3C5,
+	QCH_CON_PERIC0_TOP0_QCH_I3C6,
+	QCH_CON_PERIC0_TOP0_QCH_I3C7,
+	QCH_CON_PERIC0_TOP0_QCH_I3C8,
+	QCH_CON_PERIC0_TOP0_QCH_USI1_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI2_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI3_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI4_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI5_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI6_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI7_USI,
+	QCH_CON_PERIC0_TOP0_QCH_USI8_USI,
+	QCH_CON_PERIC0_TOP1_QCH_USI0_UART,
+	QCH_CON_PERIC0_TOP1_QCH_USI14_UART,
+	QCH_CON_SYSREG_PERIC0_QCH,
+	QUEUE_CTRL_REG_BLK_PERIC0_CMU_PERIC0,
+};
+
+/* List of parent clocks for Muxes in CMU_PERIC0 */
+PNAME(mout_peric0_bus_user_p)		= { "oscclk", "dout_cmu_peric0_bus" };
+PNAME(mout_peric0_i3c_user_p)		= { "oscclk", "dout_cmu_peric0_ip" };
+PNAME(mout_peric0_usi0_uart_user_p)	= { "oscclk", "dout_cmu_peric0_ip" };
+PNAME(mout_peric0_usi_usi_user_p)	= { "oscclk", "dout_cmu_peric0_ip" };
+
+static const struct samsung_mux_clock peric0_mux_clks[] __initconst = {
+	MUX(CLK_MOUT_PERIC0_BUS_USER, "mout_peric0_bus_user",
+	    mout_peric0_bus_user_p, PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_I3C_USER, "mout_peric0_i3c_user",
+	    mout_peric0_i3c_user_p, PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI0_UART_USER,
+	    "mout_peric0_usi0_uart_user", mout_peric0_usi0_uart_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI14_USI_USER,
+	    "mout_peric0_usi14_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI1_USI_USER,
+	    "mout_peric0_usi1_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI2_USI_USER,
+	    "mout_peric0_usi2_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI3_USI_USER,
+	    "mout_peric0_usi3_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI4_USI_USER,
+	    "mout_peric0_usi4_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI5_USI_USER,
+	    "mout_peric0_usi5_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI6_USI_USER,
+	    "mout_peric0_usi6_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI7_USI_USER,
+	    "mout_peric0_usi7_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER, 4, 1),
+	MUX(CLK_MOUT_PERIC0_USI8_USI_USER,
+	    "mout_peric0_usi8_usi_user", mout_peric0_usi_usi_user_p,
+	    PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER, 4, 1),
+};
+
+static const struct samsung_div_clock peric0_div_clks[] __initconst = {
+	DIV(CLK_DOUT_PERIC0_I3C, "dout_peric0_i3c", "mout_peric0_i3c_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_I3C, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI0_UART,
+	    "dout_peric0_usi0_uart", "mout_peric0_usi0_uart_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI14_USI,
+	    "dout_peric0_usi14_usi", "mout_peric0_usi14_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI1_USI,
+	    "dout_peric0_usi1_usi", "mout_peric0_usi1_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI2_USI,
+	    "dout_peric0_usi2_usi", "mout_peric0_usi2_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI3_USI,
+	    "dout_peric0_usi3_usi", "mout_peric0_usi3_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI4_USI,
+	    "dout_peric0_usi4_usi", "mout_peric0_usi4_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI5_USI,
+	    "dout_peric0_usi5_usi", "mout_peric0_usi5_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI6_USI,
+	    "dout_peric0_usi6_usi", "mout_peric0_usi6_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI7_USI,
+	    "dout_peric0_usi7_usi", "mout_peric0_usi7_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI7_USI, 0, 3),
+	DIV(CLK_DOUT_PERIC0_USI8_USI,
+	    "dout_peric0_usi8_usi", "mout_peric0_usi8_usi_user",
+	    CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI, 0, 3),
+};
+
+static const struct samsung_gate_clock peric0_gate_clks[] __initconst = {
+	/* Disabling this clock makes the system hang. Mark the clock as critical. */
+	GATE(CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK,
+	     "gout_peric0_peric0_cmu_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK,
+	     21, CLK_IS_CRITICAL, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK,
+	     "gout_peric0_clk_peric0_oscclk_clk", "oscclk",
+	     CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK,
+	     "gout_peric0_d_tzpc_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_GPC_PERIC0_PCLK,
+	     "gout_peric0_gpc_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK,
+	     "gout_peric0_gpio_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+	/* Disabling this clock makes the system hang. Mark the clock as critical. */
+	GATE(CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK,
+	     "gout_peric0_lhm_axi_p_peric0_i_clk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK,
+	     21, CLK_IS_CRITICAL, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0,
+	     "gout_peric0_peric0_top0_ipclk_0", "dout_peric0_usi1_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1,
+	     "gout_peric0_peric0_top0_ipclk_1", "dout_peric0_usi2_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10,
+	     "gout_peric0_peric0_top0_ipclk_10", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11,
+	     "gout_peric0_peric0_top0_ipclk_11", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12,
+	     "gout_peric0_peric0_top0_ipclk_12", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13,
+	     "gout_peric0_peric0_top0_ipclk_13", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14,
+	     "gout_peric0_peric0_top0_ipclk_14", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15,
+	     "gout_peric0_peric0_top0_ipclk_15", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2,
+	     "gout_peric0_peric0_top0_ipclk_2", "dout_peric0_usi3_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3,
+	     "gout_peric0_peric0_top0_ipclk_3", "dout_peric0_usi4_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4,
+	     "gout_peric0_peric0_top0_ipclk_4", "dout_peric0_usi5_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5,
+	     "gout_peric0_peric0_top0_ipclk_5", "dout_peric0_usi6_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6,
+	     "gout_peric0_peric0_top0_ipclk_6", "dout_peric0_usi7_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7,
+	     "gout_peric0_peric0_top0_ipclk_7", "dout_peric0_usi8_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8,
+	     "gout_peric0_peric0_top0_ipclk_8", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9,
+	     "gout_peric0_peric0_top0_ipclk_9", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0,
+	     "gout_peric0_peric0_top0_pclk_0", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1,
+	     "gout_peric0_peric0_top0_pclk_1", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10,
+	     "gout_peric0_peric0_top0_pclk_10", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11,
+	     "gout_peric0_peric0_top0_pclk_11", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12,
+	     "gout_peric0_peric0_top0_pclk_12", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13,
+	     "gout_peric0_peric0_top0_pclk_13", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14,
+	     "gout_peric0_peric0_top0_pclk_14", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15,
+	     "gout_peric0_peric0_top0_pclk_15", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2,
+	     "gout_peric0_peric0_top0_pclk_2", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3,
+	     "gout_peric0_peric0_top0_pclk_3", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4,
+	     "gout_peric0_peric0_top0_pclk_4", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5,
+	     "gout_peric0_peric0_top0_pclk_5", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6,
+	     "gout_peric0_peric0_top0_pclk_6", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7,
+	     "gout_peric0_peric0_top0_pclk_7", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8,
+	     "gout_peric0_peric0_top0_pclk_8", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9,
+	     "gout_peric0_peric0_top0_pclk_9", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9,
+	     21, 0, 0),
+	/* Disabling this clock makes the system hang. Mark the clock as critical. */
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0,
+	     "gout_peric0_peric0_top1_ipclk_0", "dout_peric0_usi0_uart",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0,
+	     21, CLK_IS_CRITICAL, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2,
+	     "gout_peric0_peric0_top1_ipclk_2", "dout_peric0_usi14_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2,
+	     21, 0, 0),
+	/* Disabling this clock makes the system hang. Mark the clock as critical. */
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0,
+	     "gout_peric0_peric0_top1_pclk_0", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0,
+	     21, CLK_IS_CRITICAL, 0),
+	GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2,
+	     "gout_peric0_peric0_top1_pclk_2", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK,
+	     "gout_peric0_clk_peric0_busp_clk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK,
+	     "gout_peric0_clk_peric0_i3c_clk", "dout_peric0_i3c",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK,
+	     "gout_peric0_clk_peric0_usi0_uart_clk", "dout_peric0_usi0_uart",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK,
+	     "gout_peric0_clk_peric0_usi14_usi_clk", "dout_peric0_usi14_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK,
+	     "gout_peric0_clk_peric0_usi1_usi_clk", "dout_peric0_usi1_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK,
+	     "gout_peric0_clk_peric0_usi2_usi_clk", "dout_peric0_usi2_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK,
+	     "gout_peric0_clk_peric0_usi3_usi_clk", "dout_peric0_usi3_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK,
+	     "gout_peric0_clk_peric0_usi4_usi_clk", "dout_peric0_usi4_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK,
+	     "gout_peric0_clk_peric0_usi5_usi_clk", "dout_peric0_usi5_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK,
+	     "gout_peric0_clk_peric0_usi6_usi_clk", "dout_peric0_usi6_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK,
+	     "gout_peric0_clk_peric0_usi7_usi_clk", "dout_peric0_usi7_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK,
+	     "gout_peric0_clk_peric0_usi8_usi_clk", "dout_peric0_usi8_usi",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK,
+	     21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK,
+	     "gout_peric0_sysreg_peric0_pclk", "mout_peric0_bus_user",
+	     CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+};
+
+static const struct samsung_cmu_info peric0_cmu_info __initconst = {
+	.mux_clks		= peric0_mux_clks,
+	.nr_mux_clks		= ARRAY_SIZE(peric0_mux_clks),
+	.div_clks		= peric0_div_clks,
+	.nr_div_clks		= ARRAY_SIZE(peric0_div_clks),
+	.gate_clks		= peric0_gate_clks,
+	.nr_gate_clks		= ARRAY_SIZE(peric0_gate_clks),
+	.nr_clk_ids		= CLKS_NR_PERIC0,
+	.clk_regs		= peric0_clk_regs,
+	.nr_clk_regs		= ARRAY_SIZE(peric0_clk_regs),
+	.clk_name		= "dout_cmu_peric0_bus",
+};
+
 /* ---- platform_driver ----------------------------------------------------- */
 
 static int __init gs101_cmu_probe(struct platform_device *pdev)
@@ -2498,6 +3078,9 @@ static const struct of_device_id gs101_cmu_of_match[] = {
 	}, {
 		.compatible = "google,gs101-cmu-misc",
 		.data = &misc_cmu_info,
+	}, {
+		.compatible = "google,gs101-cmu-peric0",
+		.data = &peric0_cmu_info,
 	}, {
 	},
 };
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:58:03 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:58:03 +0000
Subject: [PATCH v2 10/12] arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-11-tudor.ambarus@linaro.org>

Get rid of the dummy clock and start using the cmu_peric0 clocks
for the usi_uart and serial_0 nodes.

Tested the serial at 115200, 1000000 and 3000000 baudrates,
everthing went fine.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2: identify and use gate clocks instead of divider clocks

 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index c693791ae584..0e5b1b490b0b 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -180,14 +180,6 @@ HERA_CPU_SLEEP: cpu-hera-sleep {
 		};
 	};
 
-	/* TODO replace with CCF clock */
-	dummy_clk: clock-3 {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		clock-frequency = <12345>;
-		clock-output-names = "pclk";
-	};
-
 	/* ect node is required to be present by bootloader */
 	ect {
 	};
@@ -369,7 +361,8 @@ usi_uart: usi at 10a000c0 {
 			ranges;
 			#address-cells = <1>;
 			#size-cells = <1>;
-			clocks = <&dummy_clk>, <&dummy_clk>;
+			clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
+				 <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0>;
 			clock-names = "pclk", "ipclk";
 			samsung,sysreg = <&sysreg_peric0 0x1020>;
 			samsung,mode = <USI_V2_UART>;
@@ -380,7 +373,8 @@ serial_0: serial at 10a00000 {
 				reg = <0x10a00000 0xc0>;
 				interrupts = <GIC_SPI 634
 					      IRQ_TYPE_LEVEL_HIGH 0>;
-				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
+				clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
+					 <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0>;
 				clock-names = "uart", "clk_uart_baud0";
 				samsung,uart-fifosize = <256>;
 				status = "disabled";
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:58:04 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:58:04 +0000
Subject: [PATCH v2 11/12] arm64: dts: exynos: gs101: define USI8 with I2C configuration
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-12-tudor.ambarus@linaro.org>

USI8 I2C is used to communicate with an eeprom found on the battery
connector. Define USI8 in I2C configuration.

USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
selection of the protocol is intentionally left for the board dts file.

Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2:
- identify and use gate clocks instead of dividers
- move cells and pinctrl properties from dts to dtsi
- move IRQ type constant on the previous line

 arch/arm64/boot/dts/exynos/google/gs101.dtsi | 29 ++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 0e5b1b490b0b..c6ae33016992 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -354,6 +354,35 @@ pinctrl_peric0: pinctrl at 10840000 {
 			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
 		};
 
+		usi8: usi at 109700c0 {
+			compatible = "google,gs101-usi",
+				     "samsung,exynos850-usi";
+			reg = <0x109700c0 0x20>;
+			ranges;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>,
+				 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
+			clock-names = "pclk", "ipclk";
+			samsung,sysreg = <&sysreg_peric0 0x101c>;
+			status = "disabled";
+
+			hsi2c_8: i2c at 10970000 {
+				compatible = "google,gs101-hsi2c",
+					     "samsung,exynosautov9-hsi2c";
+				reg = <0x10970000 0xc0>;
+				interrupts = <GIC_SPI 642 IRQ_TYPE_LEVEL_HIGH 0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&hsi2c8_bus>;
+				clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>,
+					 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
+				clock-names = "hsi2c", "hsi2c_pclk";
+				status = "disabled";
+			};
+		};
+
 		usi_uart: usi at 10a000c0 {
 			compatible = "google,gs101-usi",
 				     "samsung,exynos850-usi";
-- 
2.43.0.472.g3155946c3a-goog



From tudor.ambarus at linaro.org  Thu Dec 28 04:58:05 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Thu, 28 Dec 2023 12:58:05 +0000
Subject: [PATCH v2 12/12] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
In-Reply-To: <20231228125805.661725-1-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
Message-ID: <20231228125805.661725-13-tudor.ambarus@linaro.org>

Enable the eeprom found on the battery connector.

The selection of the USI protocol is done in the board dts file because
the USI CONFIG register comes with a 0x0 reset value, meaning that USI8
does not have a default protocol (I2C, SPI, UART) at reset.

Reviewed-by: Sam Protsenko <semen.protsenko at linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus at linaro.org>
---
v2:
- move cells and pinctrls properties to dtsi
- collect Sam's R-b

 arch/arm64/boot/dts/exynos/google/gs101-oriole.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
index 4a71f752200d..cb4d17339b6b 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
+++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
@@ -63,6 +63,15 @@ &ext_200m {
 	clock-frequency = <200000000>;
 };
 
+&hsi2c_8 {
+	status = "okay";
+
+	eeprom: eeprom at 50 {
+		compatible = "atmel,24c08";
+		reg = <0x50>;
+	};
+};
+
 &pinctrl_far_alive {
 	key_voldown: key-voldown-pins {
 		samsung,pins = "gpa7-3";
@@ -99,6 +108,11 @@ &usi_uart {
 	status = "okay";
 };
 
+&usi8 {
+	samsung,mode = <USI_V2_I2C>;
+	status = "okay";
+};
+
 &watchdog_cl0 {
 	timeout-sec = <30>;
 	status = "okay";
-- 
2.43.0.472.g3155946c3a-goog



From sunilvl at ventanamicro.com  Thu Dec 28 05:08:28 2023
From: sunilvl at ventanamicro.com (Sunil V L)
Date: Thu, 28 Dec 2023 18:38:28 +0530
Subject: [RFC PATCH v3 03/17] PCI: Make pci_create_root_bus() declare its
 reliance on MSI domains
In-Reply-To: <20231226235602.GA1483795@bhelgaas>
References: <20231219174526.2235150-4-sunilvl@ventanamicro.com>
 <20231226235602.GA1483795@bhelgaas>
Message-ID: <ZY1zTMnYnjy7bn4A@sunil-laptop>

On Tue, Dec 26, 2023 at 05:56:02PM -0600, Bjorn Helgaas wrote:
> On Tue, Dec 19, 2023 at 11:15:12PM +0530, Sunil V L wrote:
> > Similar to [1], declare this dependency for PCI probe in ACPI based
> > flow.
> 
> It would be better to refer to this as 9ec37efb8783 ("PCI/MSI: Make
> pci_host_common_probe() declare its reliance on MSI domains") instead
> of a link to the mailing list archives.
> 
> The git SHA1 is part of the git repo, and git can tell us where that
> SHA1 is included.  The lore URL is external and doesn't say anything
> about what happened to the patch.
> 
Yes!. Let me update in next version. Thanks!

> > This is required especially for RISC-V platforms where MSI controller
> > can be absent.
> > 
> > [1] - https://lore.kernel.org/all/20210330151145.997953-12-maz at kernel.org/


From liujianfeng1994 at gmail.com  Thu Dec 28 05:16:14 2023
From: liujianfeng1994 at gmail.com (Jianfeng Liu)
Date: Thu, 28 Dec 2023 21:16:14 +0800
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
Message-ID: <20231228131617.3411561-1-liujianfeng1994@gmail.com>

This is the v2 version of this series adding hantro g1 video decoder
support for rk3588.

Changes in v2:
- Fix alphabetical order in patch1 and patch3
- Sort device tree node by bus-address
- Drop rk3588_vpu_variant fron v1 because that is exactly the same as rk3568_vpu_variant
- Link to v1: https://lore.kernel.org/all/20231227173911.3295410-1-liujianfeng1994 at gmail.com

Jianfeng Liu (3):
  media: verisilicon: Add support for Hantro G1 on RK3588
  arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588
  dt-bindings: media: rockchip-vpu: Add RK3588 compatible

 .../bindings/media/rockchip-vpu.yaml          |  1 +
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 20 +++++++++++++++++++
 .../media/platform/verisilicon/hantro_drv.c   |  1 +
 3 files changed, 22 insertions(+)

-- 
2.34.1



From liujianfeng1994 at gmail.com  Thu Dec 28 05:16:15 2023
From: liujianfeng1994 at gmail.com (Jianfeng Liu)
Date: Thu, 28 Dec 2023 21:16:15 +0800
Subject: [PATCH v2 1/3] media: verisilicon: Add support for Hantro G1 on RK3588
In-Reply-To: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
References: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
Message-ID: <20231228131617.3411561-2-liujianfeng1994@gmail.com>

This patch adds support for existing Hantro G1 video
decoder on RK3588.

Tested with FFmpeg v4l2_request code taken from [1]
with MPEG2, H.264 and VP8 samples.

[1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch

Signed-off-by: Jianfeng Liu <liujianfeng1994 at gmail.com>
---
 drivers/media/platform/verisilicon/hantro_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
index db3df6cc4..21334bb64 100644
--- a/drivers/media/platform/verisilicon/hantro_drv.c
+++ b/drivers/media/platform/verisilicon/hantro_drv.c
@@ -723,6 +723,7 @@ static const struct of_device_id of_hantro_match[] = {
 	{ .compatible = "rockchip,rk3568-vepu", .data = &rk3568_vepu_variant, },
 	{ .compatible = "rockchip,rk3568-vpu", .data = &rk3568_vpu_variant, },
 	{ .compatible = "rockchip,rk3588-av1-vpu", .data = &rk3588_vpu981_variant, },
+	{ .compatible = "rockchip,rk3588-vpu", .data = &rk3568_vpu_variant, },
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_IMX8M
 	{ .compatible = "nxp,imx8mm-vpu-g1", .data = &imx8mm_vpu_g1_variant, },
-- 
2.34.1



From liujianfeng1994 at gmail.com  Thu Dec 28 05:16:16 2023
From: liujianfeng1994 at gmail.com (Jianfeng Liu)
Date: Thu, 28 Dec 2023 21:16:16 +0800
Subject: [PATCH v2 2/3] arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588
In-Reply-To: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
References: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
Message-ID: <20231228131617.3411561-3-liujianfeng1994@gmail.com>

This patch enables Hantro G1 video decoder in RK3588's
devicetree.

Tested with FFmpeg v4l2_request code taken from [1]
with MPEG2, H.264 and VP8 samples.

[1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch

Signed-off-by: Jianfeng Liu <liujianfeng1994 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 5fb0baf8a..5da668184 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -640,6 +640,26 @@ i2c0: i2c at fd880000 {
 		status = "disabled";
 	};
 
+	vpu: video-codec at fdb50400 {
+		compatible = "rockchip,rk3588-vpu";
+		reg = <0x0 0xfdb50000 0x0 0x800>;
+		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH 0>;
+		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+		clock-names = "aclk", "hclk";
+		iommus = <&vdpu_mmu>;
+		power-domains = <&power RK3588_PD_VDPU>;
+	};
+
+	vdpu_mmu: iommu at fdb50800 {
+		compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
+		reg = <0x0 0xfdb50800 0x0 0x40>;
+		interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH 0>;
+		clock-names = "aclk", "iface";
+		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+		power-domains = <&power RK3588_PD_VDPU>;
+		#iommu-cells = <0>;
+	};
+
 	vop: vop at fdd90000 {
 		compatible = "rockchip,rk3588-vop";
 		reg = <0x0 0xfdd90000 0x0 0x4200>, <0x0 0xfdd95000 0x0 0x1000>;
-- 
2.34.1



From liujianfeng1994 at gmail.com  Thu Dec 28 05:16:17 2023
From: liujianfeng1994 at gmail.com (Jianfeng Liu)
Date: Thu, 28 Dec 2023 21:16:17 +0800
Subject: [PATCH v2 3/3] dt-bindings: media: rockchip-vpu: Add RK3588 compatible
In-Reply-To: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
References: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
Message-ID: <20231228131617.3411561-4-liujianfeng1994@gmail.com>

Add compatible for rk3588 Hantro G1 vpu decoder.

Signed-off-by: Jianfeng Liu <liujianfeng1994 at gmail.com>
---
 Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
index c57e1f488..ba41446f6 100644
--- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
@@ -25,6 +25,7 @@ properties:
           - rockchip,px30-vpu
           - rockchip,rk3568-vpu
           - rockchip,rk3588-av1-vpu
+          - rockchip,rk3588-vpu
       - items:
           - const: rockchip,rk3188-vpu
           - const: rockchip,rk3066-vpu
-- 
2.34.1



From wahrenst at gmx.net  Thu Dec 28 05:29:58 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Thu, 28 Dec 2023 14:29:58 +0100
Subject: [PATCH v3 1/3] usb: chipidea: ci_hdrc_imx: add wakeup clock and
 keep it always on
In-Reply-To: <20231228110753.1755756-1-xu.yang_2@nxp.com>
References: <20231228110753.1755756-1-xu.yang_2@nxp.com>
Message-ID: <f7988879-4822-48dd-aab2-954fb9cd819e@gmx.net>

Hi Xu,

Am 28.12.23 um 12:07 schrieb Xu Yang:
> Some platform using ChipIdea IP  may keep 32KHz wakeup clock always
> on without usb driver intervention. And some may need driver to handle
> this clock. For now only i.MX93 needs this wakeup clock. This patch will
> get wakeup clock and keep it always on to make controller work properly.
>
> Signed-off-by: Xu Yang <xu.yang_2 at nxp.com>
> Acked-by: Peter Chen <peter.chen at kernel.org>
i've tested successfully the whole series on a custom i.MX28 board
(EVAcharge SE).

Tested-by: Stefan Wahren <wahrenst at gmx.net>

Looking deeper into this patch i'm a little bit confused. The commit
message suggests that this patch introduce USB support for i.MX93, but
ci-hdrc-usb2.yaml and imx93.dtsi doesn't contain the necessary parts.
After a quick search i noticed a separate pending series which contains
these parts.

https://lore.kernel.org/linux-arm-kernel/DB7PR04MB5146920CF37DBF212199C1958C95A at DB7PR04MB5146.eurprd04.prod.outlook.com/T/#u

Please keep in such a case: dt-bindings, driver and DTS changes in one
series. This makes reviewing much easier. Especially for a series
without any cover letter.

Best regards
>
> ---
> Changes in v2:
>   - modify commit msg to make it clear
> Changes in v3:
>   - use dev_err_probe as suggested by Stefan Wahren
> ---
>   drivers/usb/chipidea/ci_hdrc_imx.c | 17 ++++++++++++++++-
>   1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> index e28bb2f2612d..ae9a6a17ec6e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -96,6 +96,7 @@ struct ci_hdrc_imx_data {
>   	struct usb_phy *phy;
>   	struct platform_device *ci_pdev;
>   	struct clk *clk;
> +	struct clk *clk_wakeup;
>   	struct imx_usbmisc_data *usbmisc_data;
>   	bool supports_runtime_pm;
>   	bool override_phy_control;
> @@ -199,7 +200,7 @@ static int imx_get_clks(struct device *dev)
>
>   	data->clk_ipg = devm_clk_get(dev, "ipg");
>   	if (IS_ERR(data->clk_ipg)) {
> -		/* If the platform only needs one clocks */
> +		/* If the platform only needs one primary clock */
>   		data->clk = devm_clk_get(dev, NULL);
>   		if (IS_ERR(data->clk)) {
>   			ret = PTR_ERR(data->clk);
> @@ -208,6 +209,13 @@ static int imx_get_clks(struct device *dev)
>   				PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
>   			return ret;
>   		}
> +		/* Get wakeup clock. Not all of the platforms need to
> +		 * handle this clock. So make it optional.
> +		 */
> +		data->clk_wakeup = devm_clk_get_optional(dev, "usb_wakeup_clk");
> +		if (IS_ERR(data->clk_wakeup))
> +			ret = dev_err_probe(dev, PTR_ERR(data->clk_wakeup),
> +					"Failed to get wakeup clk\n");
>   		return ret;
>   	}
>
> @@ -423,6 +431,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>   	if (ret)
>   		goto disable_hsic_regulator;
>
> +	ret = clk_prepare_enable(data->clk_wakeup);
> +	if (ret)
> +		goto err_wakeup_clk;
> +
>   	data->phy = devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0);
>   	if (IS_ERR(data->phy)) {
>   		ret = PTR_ERR(data->phy);
> @@ -504,6 +516,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>   disable_device:
>   	ci_hdrc_remove_device(data->ci_pdev);
>   err_clk:
> +	clk_disable_unprepare(data->clk_wakeup);
> +err_wakeup_clk:
>   	imx_disable_unprepare_clks(dev);
>   disable_hsic_regulator:
>   	if (data->hsic_pad_regulator)
> @@ -530,6 +544,7 @@ static void ci_hdrc_imx_remove(struct platform_device *pdev)
>   		usb_phy_shutdown(data->phy);
>   	if (data->ci_pdev) {
>   		imx_disable_unprepare_clks(&pdev->dev);
> +		clk_disable_unprepare(data->clk_wakeup);
>   		if (data->plat_data->flags & CI_HDRC_PMQOS)
>   			cpu_latency_qos_remove_request(&data->pm_qos_req);
>   		if (data->hsic_pad_regulator)



From andre.draszik at linaro.org  Thu Dec 28 06:04:02 2023
From: andre.draszik at linaro.org (=?ISO-8859-1?Q?Andr=E9?= Draszik)
Date: Thu, 28 Dec 2023 14:04:02 +0000
Subject: [PATCH v2 11/12] arm64: dts: exynos: gs101: define USI8 with
 I2C configuration
In-Reply-To: <20231228125805.661725-12-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
	 <20231228125805.661725-12-tudor.ambarus@linaro.org>
Message-ID: <a40b5d0dc3e151fede14aa00bcb853d1eeb8824b.camel@linaro.org>

Hi Tudor,

On Thu, 2023-12-28 at 12:58 +0000, Tudor Ambarus wrote:
> [...]
> 
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index 0e5b1b490b0b..c6ae33016992 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -354,6 +354,35 @@ pinctrl_peric0: pinctrl at 10840000 {
> ?			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> ?		};
> ?
> +		usi8: usi at 109700c0 {
> +			compatible = "google,gs101-usi",
> +				???? "samsung,exynos850-usi";
> +			reg = <0x109700c0 0x20>;
> +			ranges;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>,
> +				 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
> +			clock-names = "pclk", "ipclk";

Given the clock-names, shouldn't the clock indices be the other way around? Also see below.

> +			samsung,sysreg = <&sysreg_peric0 0x101c>;
> +			status = "disabled";
> +
> +			hsi2c_8: i2c at 10970000 {
> +				compatible = "google,gs101-hsi2c",
> +					???? "samsung,exynosautov9-hsi2c";
> +				reg = <0x10970000 0xc0>;
> +				interrupts = <GIC_SPI 642 IRQ_TYPE_LEVEL_HIGH 0>;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&hsi2c8_bus>;
> +				clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>,
> +					 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
> +				clock-names = "hsi2c", "hsi2c_pclk";

Here, pclk == CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK (which is correct, I believe), whereas
above pclk == CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7

Cheers,
A.



From andre.draszik at linaro.org  Thu Dec 28 06:22:22 2023
From: andre.draszik at linaro.org (=?ISO-8859-1?Q?Andr=E9?= Draszik)
Date: Thu, 28 Dec 2023 14:22:22 +0000
Subject: [PATCH v2 10/12] arm64: dts: exynos: gs101: update USI UART to
 use peric0 clocks
In-Reply-To: <20231228125805.661725-11-tudor.ambarus@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
	 <20231228125805.661725-11-tudor.ambarus@linaro.org>
Message-ID: <5a961a6992d7661e6c7589496438cad7b68d4f5a.camel@linaro.org>

Hi Tudor,

On Thu, 2023-12-28 at 12:58 +0000, Tudor Ambarus wrote:
> 
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> [...]
> @@ -380,7 +373,8 @@ serial_0: serial at 10a00000 {
> ?				reg = <0x10a00000 0xc0>;
> ?				interrupts = <GIC_SPI 634
> ?					????? IRQ_TYPE_LEVEL_HIGH 0>;
> -				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
> +				clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
> +					 <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0>;

I suspect these two should be the other way around, given the clock-names below?

> ?				clock-names = "uart", "clk_uart_baud0";
> ?				samsung,uart-fifosize = <256>;
> ?				status = "disabled";

Cheers,
A.


From nfraprado at collabora.com  Thu Dec 28 07:00:59 2023
From: nfraprado at collabora.com (=?utf-8?B?TsOtY29sYXMgRi4gUi4gQS4=?= Prado)
Date: Thu, 28 Dec 2023 12:00:59 -0300
Subject: [PATCH 2/2] PCI: mediatek-gen3: Assert MAC reset only if PHY
 reset also present
In-Reply-To: <20230504113509.184633-3-angelogioacchino.delregno@collabora.com>
References: <20230504113509.184633-1-angelogioacchino.delregno@collabora.com>
 <20230504113509.184633-3-angelogioacchino.delregno@collabora.com>
Message-ID: <d8cfb804-e47a-471c-8bc0-e974ee045655@notapiano>

On Thu, May 04, 2023 at 01:35:09PM +0200, AngeloGioacchino Del Regno wrote:
> Some SoCs have two PCI-Express controllers: in the case of MT8195,
> one of them is using a dedicated PHY, but the other uses a combo PHY
> that is shared with USB and in that case the PHY cannot be reset
> from the PCIe driver, or USB functionality will be unable to resume.
> 
> Resetting the PCIe MAC without also resetting the PHY will result in
> a full system lockup at PCIe resume time and the only option to
> resume operation is to hard reboot the system (with a PMIC cut-off).
> 
> To resolve this issue, check if we've got both a PHY and a MAC reset
> and, if not, never assert resets at PM suspend time: in that case,
> the link is still getting powered down as both the clocks and the
> power domains will go down anyway.
> 
> Fixes: d537dc125f07 ("PCI: mediatek-gen3: Add system PM support")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>

Hi Angelo,

It seems this patch was forgotten but it's still very much needed. As you
describe above, the Tomato Chromebook (MT8195-based) is currently unable to
resume from suspend due to this issue. Upon resume, the following error is
printed, and the system hangs:

[   67.018281] mtk-pcie-gen3 112f8000.pcie: PCIe link down, current LTSSM state: detect.quiet (0x0)
[   67.027162] mtk-pcie-gen3 112f8000.pcie: PM: dpm_run_callback(): genpd_resume_noirq+0x0/0x24 returns -110
[   67.036791] mtk-pcie-gen3 112f8000.pcie: PM: failed to resume noirq: error -110

And further investigation showed that all PCIe registers return 0x0 when read in
this situation.

Commenting out the MAC reset in the PCIe DT node fixes the issue: the PCIe
registers can be read correctly upon resume and resume proceeds succesfully.
Your patch here essentially does the same as not providing the MAC reset, with
the benefit of us still being able to describe the reset in DT and thus having a
more complete HW description.

But this patch no longer applies, so please rebase it so we can get working
suspend/resume on MT8195-Tomato :).

Thanks,
N?colas


From jszhang at kernel.org  Thu Dec 28 06:56:46 2023
From: jszhang at kernel.org (Jisheng Zhang)
Date: Thu, 28 Dec 2023 22:56:46 +0800
Subject: [PATCH 1/2] dt-bindings: arm: sunxi: Add Sipeed Longan Module 3H and Longan Pi 3H
In-Reply-To: <20231228145647.1470-1-jszhang@kernel.org>
References: <20231228145647.1470-1-jszhang@kernel.org>
Message-ID: <20231228145647.1470-2-jszhang@kernel.org>

Add name & compatible for the Sipeed Longan Module 3H and Longan PI 3H
board.

Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 11c5ce941dd7..34d8ae484e01 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -835,6 +835,13 @@ properties:
           - const: sinlinx,sina33
           - const: allwinner,sun8i-a33
 
+      - description: Sipeed Longan Pi 3H board for the Sipeed Longan Module 3H
+        items:
+          - enum:
+              - sipeed,longan-pi-3h
+          - const: sipeed,longan-module-3h
+          - const: allwinner,sun50i-h618
+
       - description: SourceParts PopStick v1.1
         items:
           - const: sourceparts,popstick-v1.1
-- 
2.40.0



From jszhang at kernel.org  Thu Dec 28 06:56:47 2023
From: jszhang at kernel.org (Jisheng Zhang)
Date: Thu, 28 Dec 2023 22:56:47 +0800
Subject: [PATCH 2/2] arm64: dts: allwinner: h616: Add Sipeed Longan SoM 3H and Pi 3H board support
In-Reply-To: <20231228145647.1470-1-jszhang@kernel.org>
References: <20231228145647.1470-1-jszhang@kernel.org>
Message-ID: <20231228145647.1470-3-jszhang@kernel.org>

The Sipeed Longan SoM 3H is a system on module based on the Allwinner
H618 SoC. The SoM features:

- Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
- 2/4 GiB LPDDR4 DRAM SoMs
- AXP313a PMIC
- eMMC

The Sipeed Longan PI 3H is a development board based on the above SoM.
The board features:
- Longan SoM 3H
- Raspberry-Pi-1 compatible GPIO header
- 2 USB 2.0 host port
- 1 USB 2.0 type C port (power supply + OTG)
- MicroSD slot
- 1Gbps Ethernet port (via RTL8211 PHY)
- HDMI port
- WiFi/BT chip

Add the devicetree file describing the currently supported features,
namely PMIC, LEDs, UART, SD card, eMMC, USB and Ethernet.

Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
---
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../sun50i-h618-longan-module-3h.dtsi         |  82 +++++++++++
 .../dts/allwinner/sun50i-h618-longanpi-3h.dts | 133 ++++++++++++++++++
 3 files changed, 216 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-longanpi-3h.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 3aca6787a167..00db504a9b8c 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -42,4 +42,5 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-longanpi-3h.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero3.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
new file mode 100644
index 000000000000..88a7d287b73c
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) Jisheng Zhang <jszhang at kernel.org>
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+/ {
+	model = "Sipeed Longan Module 3H";
+	compatible = "sipeed,longan-module-3h", "allwinner,sun50i-h618";
+};
+
+&mmc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_pins>;
+	vmmc-supply = <&reg_dldo1>;
+	vqmmc-supply = <&reg_aldo1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	mmc-ddr-1_8v;
+	mmc-hs200-1_8v;
+	status = "okay";
+};
+
+&r_i2c {
+	status = "okay";
+
+	axp313: pmic at 36 {
+		compatible = "x-powers,axp313a";
+		reg = <0x36>;
+
+		regulators {
+			/* Supplies VCC-PLL, so needs to be always on. */
+			reg_aldo1: aldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8";
+			};
+
+			/* Supplies VCC-IO, so needs to be always on. */
+			reg_dldo1: dldo1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc3v3";
+			};
+
+			reg_dcdc1: dcdc1 {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <990000>;
+				regulator-name = "vdd-gpu-sys";
+			};
+
+			reg_dcdc2: dcdc2 {
+				regulator-always-on;
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-cpu";
+			};
+
+			reg_dcdc3: dcdc3 {
+				regulator-always-on;
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-dram";
+			};
+		};
+	};
+};
+
+&pio {
+	vcc-pc-supply = <&reg_dldo1>;
+	vcc-pf-supply = <&reg_dldo1>;
+	vcc-pg-supply = <&reg_aldo1>;
+	vcc-ph-supply = <&reg_dldo1>;
+	vcc-pi-supply = <&reg_dldo1>;
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-longanpi-3h.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-longanpi-3h.dts
new file mode 100644
index 000000000000..245583881549
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-longanpi-3h.dts
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) Jisheng Zhang <jszhang at kernel.org>
+ */
+
+/dts-v1/;
+
+#include "sun50i-h618-longan-module-3h.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "Sipeed Longan Pi 3H";
+	compatible = "sipeed,longan-pi-3h", "sipeed,longan-module-3h", "allwinner,sun50i-h618";
+
+	aliases {
+		ethernet0 = &emac0;
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			color = <LED_COLOR_ID_ORANGE>;
+			function = LED_FUNCTION_INDICATOR;
+			function-enumerator = <0>;
+			gpios = <&pio 6 2 GPIO_ACTIVE_LOW>; /* PG2 */
+		};
+
+		led-1 {
+			color = <LED_COLOR_ID_ORANGE>;
+			function = LED_FUNCTION_INDICATOR;
+			function-enumerator = <1>;
+			gpios = <&pio 6 4 GPIO_ACTIVE_LOW>; /* PG4 */
+		};
+	};
+
+	reg_vcc5v: vcc5v {
+		/* board wide 5V supply directly from the USB-C socket */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-5v";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+};
+
+&axp313 {
+	vin1-supply = <&reg_vcc5v>;
+	vin2-supply = <&reg_vcc5v>;
+	vin3-supply = <&reg_vcc5v>;
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&ehci2 {
+	status = "okay";
+};
+
+&ohci2 {
+	status = "okay";
+};
+
+&ehci3 {
+	status = "okay";
+};
+
+&ohci3 {
+	status = "okay";
+};
+
+&emac0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ext_rgmii_pins>;
+	phy-mode = "rgmii";
+	phy-handle = <&ext_rgmii_phy>;
+	allwinner,rx-delay-ps = <3100>;
+	allwinner,tx-delay-ps = <700>;
+	phy-supply = <&reg_dldo1>;
+	status = "okay";
+};
+
+&mdio0 {
+	ext_rgmii_phy: ethernet-phy at 1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
+&mmc0 {
+	bus-width = <4>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;	/* PF6 */
+	vmmc-supply = <&reg_dldo1>;
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&usbotg {
+	/*
+	 * PHY0 pins are connected to a USB-C socket, but a role switch
+	 * is not implemented: both CC pins are pulled to GND.
+	 * The VBUS pins power the device, so a fixed peripheral mode
+	 * is the best choice.
+	 * The board can be powered via GPIOs, in this case port0 *can*
+	 * act as a host (with a cable/adapter ignoring CC), as VBUS is
+	 * then provided by the GPIOs. Any user of this setup would
+	 * need to adjust the DT accordingly: dr_mode set to "host",
+	 * enabling OHCI0 and EHCI0.
+	 */
+	dr_mode = "peripheral";
+	status = "okay";
+};
+
+&usbphy {
+	usb1_vbus-supply = <&reg_vcc5v>;
+	status = "okay";
+};
-- 
2.40.0



From jszhang at kernel.org  Thu Dec 28 06:56:45 2023
From: jszhang at kernel.org (Jisheng Zhang)
Date: Thu, 28 Dec 2023 22:56:45 +0800
Subject: [PATCH 0/2] arm64: dts: allwinner: h618: Add Sipeed Longan SoM 3H and Pi 3H board
Message-ID: <20231228145647.1470-1-jszhang@kernel.org>

Add Sipeed Longan SoM 3H and Longan Pi 3H board support.

The Sipeed Longan SoM 3H is a system on module based on the Allwinner
H618 SoC. The SoM features:

- Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
- 2/4 GiB LPDDR4 DRAM SoMs
- AXP313a PMIC
- eMMC

The Sipeed Longan PI 3H is a development board based on the above SoM.
The board features:
- Longan SoM 3H
- Raspberry-Pi-1 compatible GPIO header
- 2 USB 2.0 host port
- 1 USB 2.0 type C port (power supply + OTG)
- MicroSD slot
- 1Gbps Ethernet port (via RTL8211 PHY)
- HDMI port
- WiFi/BT chip

NOTE: I know it's too late for v6.8-rc1, but I want to send out this
series so that the board users can easily get mainline support with two
additional patches. I will send out v2 once v6.8-rc1 is out.

Jisheng Zhang (2):
  dt-bindings: arm: sunxi: Add Sipeed Longan Module 3H and Longan Pi 3H
  arm64: dts: allwinner: h618: Add Sipeed Longan SoM 3H and Pi 3H board
    support

 .../devicetree/bindings/arm/sunxi.yaml        |   7 +
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../sun50i-h618-longan-module-3h.dtsi         |  82 +++++++++++
 .../dts/allwinner/sun50i-h618-longanpi-3h.dts | 133 ++++++++++++++++++
 4 files changed, 223 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-longanpi-3h.dts

-- 
2.40.0



From lkp at intel.com  Thu Dec 28 07:22:16 2023
From: lkp at intel.com (kernel test robot)
Date: Thu, 28 Dec 2023 23:22:16 +0800
Subject: [soc:mediatek/soc-drivers 7/24]
 drivers/soc/mediatek/mt8188-mmsys.h:126:3: error: use of undeclared
 identifier 'MT8188_VDO0_RST_DISP_OVL0'
Message-ID: <202312282303.RiMNsTV5-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/soc-drivers
head:   2bfbf82956e2de75249ce83901800c68d17d9e62
commit: 27222a779d0404d6faab8aeaf028db4ac4de9b1f [7/24] soc: mediatek: Add MT8188 VDOSYS reset bit map
config: arm64-allmodconfig (https://download.01.org/0day-ci/archive/20231228/202312282303.RiMNsTV5-lkp at intel.com/config)
compiler: clang version 18.0.0git (https://github.com/llvm/llvm-project d3ef86708241a3bee902615c190dead1638c4e09)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231228/202312282303.RiMNsTV5-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312282303.RiMNsTV5-lkp at intel.com/

All errors (new ones prefixed by >>):

   In file included from drivers/soc/mediatek/mtk-mmsys.c:21:
>> drivers/soc/mediatek/mt8188-mmsys.h:126:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_OVL0'
     126 |         [MT8188_VDO0_RST_DISP_OVL0]     = MMSYS_RST_NR(0, 0),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:127:3: error: use of undeclared identifier 'MT8188_VDO0_RST_FAKE_ENG0'
     127 |         [MT8188_VDO0_RST_FAKE_ENG0]     = MMSYS_RST_NR(0, 2),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:128:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_CCORR0'
     128 |         [MT8188_VDO0_RST_DISP_CCORR0]   = MMSYS_RST_NR(0, 4),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:129:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_MUTEX0'
     129 |         [MT8188_VDO0_RST_DISP_MUTEX0]   = MMSYS_RST_NR(0, 6),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:130:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_GAMMA0'
     130 |         [MT8188_VDO0_RST_DISP_GAMMA0]   = MMSYS_RST_NR(0, 8),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:131:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_DITHER0'
     131 |         [MT8188_VDO0_RST_DISP_DITHER0]  = MMSYS_RST_NR(0, 10),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:132:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_WDMA0'
     132 |         [MT8188_VDO0_RST_DISP_WDMA0]    = MMSYS_RST_NR(0, 17),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:133:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_RDMA0'
     133 |         [MT8188_VDO0_RST_DISP_RDMA0]    = MMSYS_RST_NR(0, 19),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:134:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DSI0'
     134 |         [MT8188_VDO0_RST_DSI0]          = MMSYS_RST_NR(0, 21),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:135:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DSI1'
     135 |         [MT8188_VDO0_RST_DSI1]          = MMSYS_RST_NR(0, 22),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:136:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DSC_WRAP0'
     136 |         [MT8188_VDO0_RST_DSC_WRAP0]     = MMSYS_RST_NR(0, 23),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:137:3: error: use of undeclared identifier 'MT8188_VDO0_RST_VPP_MERGE0'
     137 |         [MT8188_VDO0_RST_VPP_MERGE0]    = MMSYS_RST_NR(0, 24),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:138:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DP_INTF0'
     138 |         [MT8188_VDO0_RST_DP_INTF0]      = MMSYS_RST_NR(0, 25),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:139:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_AAL0'
     139 |         [MT8188_VDO0_RST_DISP_AAL0]     = MMSYS_RST_NR(0, 26),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:140:3: error: use of undeclared identifier 'MT8188_VDO0_RST_INLINEROT0'
     140 |         [MT8188_VDO0_RST_INLINEROT0]    = MMSYS_RST_NR(0, 27),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:141:3: error: use of undeclared identifier 'MT8188_VDO0_RST_APB_BUS'
     141 |         [MT8188_VDO0_RST_APB_BUS]       = MMSYS_RST_NR(0, 28),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:142:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_COLOR0'
     142 |         [MT8188_VDO0_RST_DISP_COLOR0]   = MMSYS_RST_NR(0, 29),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:143:3: error: use of undeclared identifier 'MT8188_VDO0_RST_MDP_WROT0'
     143 |         [MT8188_VDO0_RST_MDP_WROT0]     = MMSYS_RST_NR(0, 30),
         |          ^
>> drivers/soc/mediatek/mt8188-mmsys.h:144:3: error: use of undeclared identifier 'MT8188_VDO0_RST_DISP_RSZ0'
     144 |         [MT8188_VDO0_RST_DISP_RSZ0]     = MMSYS_RST_NR(0, 31),
         |          ^
   fatal error: too many errors emitted, stopping now [-ferror-limit=]
   20 errors generated.


vim +/MT8188_VDO0_RST_DISP_OVL0 +126 drivers/soc/mediatek/mt8188-mmsys.h

   124	
   125	static const u8 mmsys_mt8188_vdo0_rst_tb[] = {
 > 126		[MT8188_VDO0_RST_DISP_OVL0]	= MMSYS_RST_NR(0, 0),
 > 127		[MT8188_VDO0_RST_FAKE_ENG0]	= MMSYS_RST_NR(0, 2),
 > 128		[MT8188_VDO0_RST_DISP_CCORR0]	= MMSYS_RST_NR(0, 4),
 > 129		[MT8188_VDO0_RST_DISP_MUTEX0]	= MMSYS_RST_NR(0, 6),
 > 130		[MT8188_VDO0_RST_DISP_GAMMA0]	= MMSYS_RST_NR(0, 8),
 > 131		[MT8188_VDO0_RST_DISP_DITHER0]	= MMSYS_RST_NR(0, 10),
 > 132		[MT8188_VDO0_RST_DISP_WDMA0]	= MMSYS_RST_NR(0, 17),
 > 133		[MT8188_VDO0_RST_DISP_RDMA0]	= MMSYS_RST_NR(0, 19),
 > 134		[MT8188_VDO0_RST_DSI0]		= MMSYS_RST_NR(0, 21),
 > 135		[MT8188_VDO0_RST_DSI1]		= MMSYS_RST_NR(0, 22),
 > 136		[MT8188_VDO0_RST_DSC_WRAP0]	= MMSYS_RST_NR(0, 23),
 > 137		[MT8188_VDO0_RST_VPP_MERGE0]	= MMSYS_RST_NR(0, 24),
 > 138		[MT8188_VDO0_RST_DP_INTF0]	= MMSYS_RST_NR(0, 25),
 > 139		[MT8188_VDO0_RST_DISP_AAL0]	= MMSYS_RST_NR(0, 26),
 > 140		[MT8188_VDO0_RST_INLINEROT0]	= MMSYS_RST_NR(0, 27),
 > 141		[MT8188_VDO0_RST_APB_BUS]	= MMSYS_RST_NR(0, 28),
 > 142		[MT8188_VDO0_RST_DISP_COLOR0]	= MMSYS_RST_NR(0, 29),
 > 143		[MT8188_VDO0_RST_MDP_WROT0]	= MMSYS_RST_NR(0, 30),
 > 144		[MT8188_VDO0_RST_DISP_RSZ0]	= MMSYS_RST_NR(0, 31),
   145	};
   146	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From sean.anderson at seco.com  Thu Dec 28 08:17:40 2023
From: sean.anderson at seco.com (Sean Anderson)
Date: Thu, 28 Dec 2023 11:17:40 -0500
Subject: [BUG] soc: fsl: qbman: lockdep invalid wait context with
 qman_update_cgr_smp_call
In-Reply-To: <87wmsyvclu.fsf@pengutronix.de>
References: <87wmsyvclu.fsf@pengutronix.de>
Message-ID: <33088f1b-4a44-425b-8694-3f602afb4537@seco.com>

On 12/28/23 05:19, Steffen Trumtrar wrote:
> [You don't often get email from s.trumtrar at pengutronix.de. Learn why this is important at https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2faka.ms%2fLearnAboutSenderIdentification&umid=72a5c76d-1830-45a7-9b06-a3ea261ec2fb&auth=d807158c60b7d2502abde8a2fc01f40662980862-c66d6dcafe8b63c2b68864762f9c6ab8a12651d4 ]
> 
> Hi,
> 
> I noticed that lockdep reports a BUG on the qman driver since
> 
> ?? 914f8b228ede709274b8c80514b352248ec9da00
> ?? Author:???? Sean Anderson <sean.anderson at seco.com>
> ?? AuthorDate: Fri Sep 2 17:57:35 2022 -0400
> ?? Commit:???? David S. Miller <davem at davemloft.net>
> ?? CommitDate: Mon Sep 5 14:27:39 2022 +0100
> 
> ?? soc: fsl: qbman: Add CGR update function
> 
> ?? This adds a function to update a CGR with new parameters. qman_create_cgr
> ?? can almost be used for this (with flags=0), but it's not suitable because
> ?? it also registers the callback function. The _safe variant was modeled off
> ?? of qman_cgr_delete_safe. However, we handle multiple arguments and a return
> ?? value.
> 
> The stack trace looks something like:
> 
> ?? [?? 20.192060] =============================
> ?? [?? 20.196067] [ BUG: Invalid wait context ]
> ?? [?? 20.200073] 6.7.0-rc6 #73 Not tainted
> ?? [?? 20.203733] -----------------------------
> ?? [?? 20.207738] systemd-journal/114 is trying to lock:
> ?? [?? 20.212528] ffff000973403860 (&portal->cgr_lock){+.+.}-{3:3}, at: qman_update_cgr_smp_call+0x40/0xb0
> ?? [?? 20.221688] other info that might help us debug this:
> ?? [?? 20.226736] context-{2:2}
> ?? [?? 20.229350] 1 lock held by systemd-journal/114:
> ?? [?? 20.233878]? #0: ffff0008001a0208 (&root->kernfs_iattr_rwsem){++++}-{4:4}, at: kernfs_iop_permission+0x48/0xa0
> ?? [?? 20.243902] stack backtrace:
> ?? [?? 20.246779] CPU: 2 PID: 114 Comm: systemd-journal Not tainted 6.7.0-rc6 #73
> ?? [?? 20.253743] Hardware name: TQ TQMLS1046A SoM on Arkona AT1130 (AT300) board (DT)
> ?? [?? 20.261144] Call trace:
> ?? [?? 20.261147]? dump_backtrace+0xa0/0x128
> ?? [?? 20.261154]? show_stack+0x20/0x38
> ?? [?? 20.261158]? dump_stack_lvl+0x74/0xd8
> ?? [?? 20.274303]? dump_stack+0x18/0x28
> ?? [?? 20.279004]? __lock_acquire+0x920/0x1b58
> ?? [?? 20.284309]? lock_acquire+0x1fc/0x348
> ?? [?? 20.289354]? _raw_spin_lock_irqsave+0x6c/0xd0
> ?? [?? 20.294748]? qman_update_cgr_smp_call+0x40/0xb0
> ?? [?? 20.299278]? __flush_smp_call_function_queue+0x1d0/0x3e0
> ?? [?? 20.304593]? generic_smp_call_function_single_interrupt+0x1c/0x30
> ?? [?? 20.310689]? ipi_handler+0x250/0x290
> ?? [?? 20.314263]? handle_percpu_devid_irq+0xb0/0x170
> ?? [?? 20.318793]? generic_handle_domain_irq+0x34/0x58
> ?? [?? 20.323411]? gic_handle_irq+0x4c/0xd8
> ?? [?? 20.327070]? call_on_irq_stack+0x24/0x58
> ?? [?? 20.330991]? do_interrupt_handler+0xdc/0xe8
> ?? [?? 20.335173]? el1_interrupt+0x34/0x68
> ?? [?? 20.338747]? el1h_64_irq_handler+0x18/0x28
> ?? [?? 20.342843]? el1h_64_irq+0x64/0x68
> ?? [?? 20.346240]? lock_acquired+0x198/0x448
> ?? [?? 20.349988]? down_read+0x98/0x1c0
> ?? [?? 20.353300]? kernfs_iop_permission+0x48/0xa0
> ?? [?? 20.357569]? inode_permission+0x118/0x190
> ?? [?? 20.361578]? link_path_walk.part.0.constprop.0+0x2b0/0x398
> ?? [?? 20.367065]? path_lookupat+0x44/0x1b8
> ?? [?? 20.370726]? filename_lookup+0x9c/0x170
> ?? [?? 20.374561]? user_path_at_empty+0x54/0x88
> ?? [?? 20.378571]? do_faccessat+0x88/0x308
> ?? [?? 20.382144]? __arm64_sys_access+0x2c/0x40
> ?? [?? 20.386152]? invoke_syscall+0x50/0x120
> ?? [?? 20.389901]? el0_svc_common.constprop.0+0xc8/0xf0
> ?? [?? 20.394606]? do_el0_svc_compat+0x24/0x40
> ?? [?? 20.398528]? el0_svc_compat+0x4c/0x148
> ?? [?? 20.402275]? el0t_32_sync_handler+0xb0/0x138
> ?? [?? 20.406545]? el0t_32_sync+0x194/0x198
> 
> The
> ?? [?? 20.207738] systemd-journal/114 is trying to lock:
> can be any other process and must not be systemd-journal. For example when barebox-state triggers the stacktrace the function calls look like:
> 
> #??????????????????????????????? _-----=> irqs-off/BH-disabled
> #?????????????????????????????? / _----=> need-resched
> #????????????????????????????? | / _---=> hardirq/softirq
> #????????????????????????????? || / _--=> preempt-depth
> #????????????????????????????? ||| / _-=> migrate-disable
> #????????????????????????????? |||| /???? delay
> #?????????? TASK-PID???? CPU#? |||||? TIMESTAMP? FUNCTION
> #????????????? | |???????? |?? |||||???? |???????? |
> ??????? systemd-1?????? [002] ...2.???? 6.871198: qm_modify_cgr <-qman_init_cgr_all
> ??????? (...)
> ??? kworker/2:1-38????? [002] ...1.??? 19.070335: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed
> ? barebox-state-211???? [001] d.h1.??? 19.070344: qman_update_cgr_smp_call <-__flush_smp_call_function_queue
> ? barebox-state-211???? [001] d.h3.??? 19.260311: qm_modify_cgr <-qman_update_cgr_smp_call
> ??? kworker/2:1-38????? [002] ...1.??? 19.305517: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed
> ???????? <idle>-0?????? [001] d.h2.??? 19.305524: qman_update_cgr_smp_call <-__flush_smp_call_function_queue
> ???????? <idle>-0?????? [001] d.h4.??? 19.305526: qm_modify_cgr <-qman_update_cgr_smp_call
> ??? kworker/3:1-40????? [003] ...1.??? 19.354259: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed
> ???????? <idle>-0?????? [001] d.h2.??? 19.354265: qman_update_cgr_smp_call <-__flush_smp_call_function_queue
> ???????? <idle>-0?????? [001] d.h4.??? 19.354267: qm_modify_cgr <-qman_update_cgr_smp_call
> 
> I'm not sure why the CPU# detection in the patch is necessary, but maybe you have an idea what is happening here.

Can you try [1]?

If that works for you I'll resend.

--Sean

[1] https://lore.kernel.org/linux-arm-kernel/20230404145557.2356894-1-sean.anderson at seco.com/


From sean.anderson at seco.com  Thu Dec 28 08:24:45 2023
From: sean.anderson at seco.com (Sean Anderson)
Date: Thu, 28 Dec 2023 11:24:45 -0500
Subject: [BUG] soc: fsl: qbman: lockdep invalid wait context with
 qman_update_cgr_smp_call
In-Reply-To: <87wmsyvclu.fsf@pengutronix.de>
References: <87wmsyvclu.fsf@pengutronix.de>
Message-ID: <94eee331-20ce-429a-ac7e-65f5ae68dc65@seco.com>

On 12/28/23 05:19, Steffen Trumtrar wrote:
> [You don't often get email from s.trumtrar at pengutronix.de. Learn why this is important at https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2faka.ms%2fLearnAboutSenderIdentification&umid=72a5c76d-1830-45a7-9b06-a3ea261ec2fb&auth=d807158c60b7d2502abde8a2fc01f40662980862-c66d6dcafe8b63c2b68864762f9c6ab8a12651d4 ]
> 
> Hi,
> 
> I noticed that lockdep reports a BUG on the qman driver since
> 
> ?? 914f8b228ede709274b8c80514b352248ec9da00
> ?? Author:???? Sean Anderson <sean.anderson at seco.com>
> ?? AuthorDate: Fri Sep 2 17:57:35 2022 -0400
> ?? Commit:???? David S. Miller <davem at davemloft.net>
> ?? CommitDate: Mon Sep 5 14:27:39 2022 +0100
> 
> ?? soc: fsl: qbman: Add CGR update function
> 
> ?? This adds a function to update a CGR with new parameters. qman_create_cgr
> ?? can almost be used for this (with flags=0), but it's not suitable because
> ?? it also registers the callback function. The _safe variant was modeled off
> ?? of qman_cgr_delete_safe. However, we handle multiple arguments and a return
> ?? value.
> 
> The stack trace looks something like:
> 
> ?? [?? 20.192060] =============================
> ?? [?? 20.196067] [ BUG: Invalid wait context ]
> ?? [?? 20.200073] 6.7.0-rc6 #73 Not tainted
> ?? [?? 20.203733] -----------------------------
> ?? [?? 20.207738] systemd-journal/114 is trying to lock:
> ?? [?? 20.212528] ffff000973403860 (&portal->cgr_lock){+.+.}-{3:3}, at: qman_update_cgr_smp_call+0x40/0xb0
> ?? [?? 20.221688] other info that might help us debug this:
> ?? [?? 20.226736] context-{2:2}
> ?? [?? 20.229350] 1 lock held by systemd-journal/114:
> ?? [?? 20.233878]? #0: ffff0008001a0208 (&root->kernfs_iattr_rwsem){++++}-{4:4}, at: kernfs_iop_permission+0x48/0xa0
> ?? [?? 20.243902] stack backtrace:
> ?? [?? 20.246779] CPU: 2 PID: 114 Comm: systemd-journal Not tainted 6.7.0-rc6 #73
> ?? [?? 20.253743] Hardware name: TQ TQMLS1046A SoM on Arkona AT1130 (AT300) board (DT)
> ?? [?? 20.261144] Call trace:
> ?? [?? 20.261147]? dump_backtrace+0xa0/0x128
> ?? [?? 20.261154]? show_stack+0x20/0x38
> ?? [?? 20.261158]? dump_stack_lvl+0x74/0xd8
> ?? [?? 20.274303]? dump_stack+0x18/0x28
> ?? [?? 20.279004]? __lock_acquire+0x920/0x1b58
> ?? [?? 20.284309]? lock_acquire+0x1fc/0x348
> ?? [?? 20.289354]? _raw_spin_lock_irqsave+0x6c/0xd0
> ?? [?? 20.294748]? qman_update_cgr_smp_call+0x40/0xb0
> ?? [?? 20.299278]? __flush_smp_call_function_queue+0x1d0/0x3e0
> ?? [?? 20.304593]? generic_smp_call_function_single_interrupt+0x1c/0x30
> ?? [?? 20.310689]? ipi_handler+0x250/0x290
> ?? [?? 20.314263]? handle_percpu_devid_irq+0xb0/0x170
> ?? [?? 20.318793]? generic_handle_domain_irq+0x34/0x58
> ?? [?? 20.323411]? gic_handle_irq+0x4c/0xd8
> ?? [?? 20.327070]? call_on_irq_stack+0x24/0x58
> ?? [?? 20.330991]? do_interrupt_handler+0xdc/0xe8
> ?? [?? 20.335173]? el1_interrupt+0x34/0x68
> ?? [?? 20.338747]? el1h_64_irq_handler+0x18/0x28
> ?? [?? 20.342843]? el1h_64_irq+0x64/0x68
> ?? [?? 20.346240]? lock_acquired+0x198/0x448
> ?? [?? 20.349988]? down_read+0x98/0x1c0
> ?? [?? 20.353300]? kernfs_iop_permission+0x48/0xa0
> ?? [?? 20.357569]? inode_permission+0x118/0x190
> ?? [?? 20.361578]? link_path_walk.part.0.constprop.0+0x2b0/0x398
> ?? [?? 20.367065]? path_lookupat+0x44/0x1b8
> ?? [?? 20.370726]? filename_lookup+0x9c/0x170
> ?? [?? 20.374561]? user_path_at_empty+0x54/0x88
> ?? [?? 20.378571]? do_faccessat+0x88/0x308
> ?? [?? 20.382144]? __arm64_sys_access+0x2c/0x40
> ?? [?? 20.386152]? invoke_syscall+0x50/0x120
> ?? [?? 20.389901]? el0_svc_common.constprop.0+0xc8/0xf0
> ?? [?? 20.394606]? do_el0_svc_compat+0x24/0x40
> ?? [?? 20.398528]? el0_svc_compat+0x4c/0x148
> ?? [?? 20.402275]? el0t_32_sync_handler+0xb0/0x138
> ?? [?? 20.406545]? el0t_32_sync+0x194/0x198
> 
> The
> ?? [?? 20.207738] systemd-journal/114 is trying to lock:
> can be any other process and must not be systemd-journal. For example when barebox-state triggers the stacktrace the function calls look like:
> 
> #??????????????????????????????? _-----=> irqs-off/BH-disabled
> #?????????????????????????????? / _----=> need-resched
> #????????????????????????????? | / _---=> hardirq/softirq
> #????????????????????????????? || / _--=> preempt-depth
> #????????????????????????????? ||| / _-=> migrate-disable
> #????????????????????????????? |||| /???? delay
> #?????????? TASK-PID???? CPU#? |||||? TIMESTAMP? FUNCTION
> #????????????? | |???????? |?? |||||???? |???????? |
> ??????? systemd-1?????? [002] ...2.???? 6.871198: qm_modify_cgr <-qman_init_cgr_all
> ??????? (...)
> ??? kworker/2:1-38????? [002] ...1.??? 19.070335: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed
> ? barebox-state-211???? [001] d.h1.??? 19.070344: qman_update_cgr_smp_call <-__flush_smp_call_function_queue
> ? barebox-state-211???? [001] d.h3.??? 19.260311: qm_modify_cgr <-qman_update_cgr_smp_call
> ??? kworker/2:1-38????? [002] ...1.??? 19.305517: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed
> ???????? <idle>-0?????? [001] d.h2.??? 19.305524: qman_update_cgr_smp_call <-__flush_smp_call_function_queue
> ???????? <idle>-0?????? [001] d.h4.??? 19.305526: qm_modify_cgr <-qman_update_cgr_smp_call
> ??? kworker/3:1-40????? [003] ...1.??? 19.354259: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed
> ???????? <idle>-0?????? [001] d.h2.??? 19.354265: qman_update_cgr_smp_call <-__flush_smp_call_function_queue
> ???????? <idle>-0?????? [001] d.h4.??? 19.354267: qm_modify_cgr <-qman_update_cgr_smp_call
> 
> I'm not sure why the CPU# detection in the patch is necessary, but maybe you have an idea what is happening here.

And to keep this from being lost again:

#regzbot introduced 914f8b228ede709274b8c80514b352248ec9da00  https://lore.kernel.org/netdev/20230323153935.nofnjucqjqnz34ej at skbuf/
#regzbot monitor https://lore.kernel.org/linux-arm-kernel/20230404145557.2356894-1-sean.anderson at seco.com/
#regzbot dup https://lore.kernel.org/netdev/20230323153935.nofnjucqjqnz34ej at skbuf/


From jonas at kwiboo.se  Thu Dec 28 08:30:33 2023
From: jonas at kwiboo.se (Jonas Karlman)
Date: Thu, 28 Dec 2023 17:30:33 +0100
Subject: [PATCH v3 1/2] ARM: dts: rockchip: add gpio-ranges property to
 gpio nodes
In-Reply-To: <cf46c685-bf4b-63b5-0373-dd0ba70e9700@gmail.com>
References: <cf46c685-bf4b-63b5-0373-dd0ba70e9700@gmail.com>
Message-ID: <541b7633-af3b-4392-ac29-7ee1f2c6f943@kwiboo.se>

Hi Johan,

On 2023-12-27 19:33, Johan Jonker wrote:
> Add a gpio-ranges property to Rockchip gpio nodes similar to
> rk356x/rk3588 to be independent from aliases and probe order.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> Reviewed-by: Kever Yang <kever.yang at rock-chips.com>
> ---
> 
> Changed V3:
>   reword
>   rebase to new Rockchip directory
>   remove unknown properties
> ---
>  arch/arm/boot/dts/rockchip/rk3036.dtsi  | 3 +++
>  arch/arm/boot/dts/rockchip/rk3066a.dtsi | 6 ++++++
>  arch/arm/boot/dts/rockchip/rk3128.dtsi  | 4 ++++
>  arch/arm/boot/dts/rockchip/rk3188.dtsi  | 4 ++++
>  arch/arm/boot/dts/rockchip/rk322x.dtsi  | 4 ++++
>  arch/arm/boot/dts/rockchip/rk3288.dtsi  | 9 +++++++++
>  arch/arm/boot/dts/rockchip/rv1108.dtsi  | 4 ++++
>  arch/arm/boot/dts/rockchip/rv1126.dtsi  | 5 +++++
>  8 files changed, 39 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> index 2b00109bea6a..6e5028b6dbfa 100644
> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
> @@ -593,6 +593,7 @@ gpio0: gpio at 2007c000 {
>  			clocks = <&cru PCLK_GPIO0>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 0 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -606,6 +607,7 @@ gpio1: gpio at 20080000 {
>  			clocks = <&cru PCLK_GPIO1>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 32 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -619,6 +621,7 @@ gpio2: gpio at 20084000 {
>  			clocks = <&cru PCLK_GPIO2>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 64 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> diff --git a/arch/arm/boot/dts/rockchip/rk3066a.dtsi b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> index 30139f21de64..a4962b6b3f4c 100644
> --- a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
> @@ -285,6 +285,7 @@ gpio0: gpio at 20034000 {
>  			clocks = <&cru PCLK_GPIO0>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 0 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -298,6 +299,7 @@ gpio1: gpio at 2003c000 {
>  			clocks = <&cru PCLK_GPIO1>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 32 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -311,6 +313,7 @@ gpio2: gpio at 2003e000 {
>  			clocks = <&cru PCLK_GPIO2>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 64 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -324,6 +327,7 @@ gpio3: gpio at 20080000 {
>  			clocks = <&cru PCLK_GPIO3>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 96 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -337,6 +341,7 @@ gpio4: gpio at 20084000 {
>  			clocks = <&cru PCLK_GPIO4>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 128 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -350,6 +355,7 @@ gpio6: gpio at 2000a000 {
>  			clocks = <&cru PCLK_GPIO6>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 192 32>;

It does not look like this matches what pins the pinctrl driver expose
for rk3066a. Something like <&pinctrl 0 160 16> would probably be more
correct.

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
> index e2264c40b924..d66fcf12032e 100644
> --- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
> @@ -712,6 +712,7 @@ gpio0: gpio at 2007c000 {
>  			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&cru PCLK_GPIO0>;
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 0 32>;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> @@ -723,6 +724,7 @@ gpio1: gpio at 20080000 {
>  			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&cru PCLK_GPIO1>;
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 32 32>;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> @@ -734,6 +736,7 @@ gpio2: gpio at 20084000 {
>  			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&cru PCLK_GPIO2>;
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 64 32>;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> @@ -745,6 +748,7 @@ gpio3: gpio at 20088000 {
>  			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&cru PCLK_GPIO3>;
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 96 32>;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> diff --git a/arch/arm/boot/dts/rockchip/rk3188.dtsi b/arch/arm/boot/dts/rockchip/rk3188.dtsi
> index 44b54af0bbf9..6677e4a10e5d 100644
> --- a/arch/arm/boot/dts/rockchip/rk3188.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3188.dtsi
> @@ -231,6 +231,7 @@ gpio0: gpio at 2000a000 {
>  			clocks = <&cru PCLK_GPIO0>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 0 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -244,6 +245,7 @@ gpio1: gpio at 2003c000 {
>  			clocks = <&cru PCLK_GPIO1>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 32 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -257,6 +259,7 @@ gpio2: gpio at 2003e000 {
>  			clocks = <&cru PCLK_GPIO2>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 64 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -270,6 +273,7 @@ gpio3: gpio at 20080000 {
>  			clocks = <&cru PCLK_GPIO3>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 96 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi b/arch/arm/boot/dts/rockchip/rk322x.dtsi
> index 831561fc1814..0d4f9957b99b 100644
> --- a/arch/arm/boot/dts/rockchip/rk322x.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk322x.dtsi
> @@ -959,6 +959,7 @@ gpio0: gpio at 11110000 {
>  			clocks = <&cru PCLK_GPIO0>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 0 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -972,6 +973,7 @@ gpio1: gpio at 11120000 {
>  			clocks = <&cru PCLK_GPIO1>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 32 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -985,6 +987,7 @@ gpio2: gpio at 11130000 {
>  			clocks = <&cru PCLK_GPIO2>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 64 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -998,6 +1001,7 @@ gpio3: gpio at 11140000 {
>  			clocks = <&cru PCLK_GPIO3>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 96 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi b/arch/arm/boot/dts/rockchip/rk3288.dtsi
> index ead343dc3df1..c5550aae4ed8 100644
> --- a/arch/arm/boot/dts/rockchip/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rk3288.dtsi
> @@ -1461,6 +1461,7 @@ gpio0: gpio at ff750000 {
>  			clocks = <&cru PCLK_GPIO0>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 0 32>;

The pinctrl driver for rk3288 only expose 24 pins for the first bank,
correct range would probably be <&pinctrl 0 0 24> here,

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -1474,6 +1475,7 @@ gpio1: gpio at ff780000 {
>  			clocks = <&cru PCLK_GPIO1>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 32 32>;

and correct range would probably be <&pinctrl 0 24 32> here,

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -1487,6 +1489,7 @@ gpio2: gpio at ff790000 {
>  			clocks = <&cru PCLK_GPIO2>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 64 32>;

and <&pinctrl 0 56 32> here,

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -1500,6 +1503,7 @@ gpio3: gpio at ff7a0000 {
>  			clocks = <&cru PCLK_GPIO3>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 96 32>;

and <&pinctrl 0 88 32> here,

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -1513,6 +1517,7 @@ gpio4: gpio at ff7b0000 {
>  			clocks = <&cru PCLK_GPIO4>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 128 32>;

and <&pinctrl 0 120 32> here,

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -1526,6 +1531,7 @@ gpio5: gpio at ff7c0000 {
>  			clocks = <&cru PCLK_GPIO5>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 160 32>;

and <&pinctrl 0 152 32> here,

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -1539,6 +1545,7 @@ gpio6: gpio at ff7d0000 {
>  			clocks = <&cru PCLK_GPIO6>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 192 32>;

and <&pinctrl 0 184 32> here,

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -1552,6 +1559,7 @@ gpio7: gpio at ff7e0000 {
>  			clocks = <&cru PCLK_GPIO7>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 224 32>;

and <&pinctrl 0 216 32> here,

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -1565,6 +1573,7 @@ gpio8: gpio at ff7f0000 {
>  			clocks = <&cru PCLK_GPIO8>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 256 32>;

and bank num 8 only expose 16 pins, so <&pinctrl 0 248 16> here.

>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> diff --git a/arch/arm/boot/dts/rockchip/rv1108.dtsi b/arch/arm/boot/dts/rockchip/rv1108.dtsi
> index abf3006f0a84..d12b97ee7588 100644
> --- a/arch/arm/boot/dts/rockchip/rv1108.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rv1108.dtsi
> @@ -602,6 +602,7 @@ gpio0: gpio at 20030000 {
>  			clocks = <&cru PCLK_GPIO0_PMU>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 0 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -615,6 +616,7 @@ gpio1: gpio at 10310000 {
>  			clocks = <&cru PCLK_GPIO1>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 32 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -628,6 +630,7 @@ gpio2: gpio at 10320000 {
>  			clocks = <&cru PCLK_GPIO2>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 64 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> @@ -641,6 +644,7 @@ gpio3: gpio at 10330000 {
>  			clocks = <&cru PCLK_GPIO3>;
> 
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 96 32>;
>  			#gpio-cells = <2>;
> 
>  			interrupt-controller;
> diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
> index bb603cae13df..71d091af6395 100644
> --- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
> @@ -569,6 +569,7 @@ gpio0: gpio at ff460000 {
>  			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 0 32>;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> @@ -580,6 +581,7 @@ gpio1: gpio at ff620000 {
>  			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 32 32>;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> @@ -591,6 +593,7 @@ gpio2: gpio at ff630000 {
>  			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 64 32>;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> @@ -602,6 +605,7 @@ gpio3: gpio at ff640000 {
>  			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 96 32>;
>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> @@ -613,6 +617,7 @@ gpio4: gpio at ff650000 {
>  			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
>  			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
>  			gpio-controller;
> +			gpio-ranges = <&pinctrl 0 128 32>;

Bank num 4 only expose 2 pins, so should probably be <&pinctrl 0 128 2>.

Regards,
Jonas

>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> --
> 2.39.2
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip



From jonas at kwiboo.se  Thu Dec 28 08:53:43 2023
From: jonas at kwiboo.se (Jonas Karlman)
Date: Thu, 28 Dec 2023 17:53:43 +0100
Subject: [PATCH v2 4/4] arm64: dts: rockchip: Add devicetree for Pine64
 Pinetab2
In-Reply-To: <20231223-pinetab2-v2-4-ec1856d0030e@mecka.net>
References: <20231223-pinetab2-v2-0-ec1856d0030e@mecka.net>
 <20231223-pinetab2-v2-4-ec1856d0030e@mecka.net>
Message-ID: <639dda39-9b4c-48fc-a024-8dffc281b879@kwiboo.se>

Hi Manuel,

On 2023-12-23 16:20, Manuel Traut wrote:
> From: Alexander Warnecke <awarnecke002 at hotmail.com>
> 
> This includes support for both the v0.1 units that were sent to developers and
> the v2.0 units from production.
> 
> v1.0 is not included as no units are known to exist.
> 
> Working/Tested:
> - SDMMC
> - UART
> - Buttons
> - Charging/Battery/PMIC
> - Audio
> - USB
> - Display
> 
> WiFi is not added, since the driver is not ready for mainline.
> 
> Signed-off-by: Alexander Warnecke <awarnecke002 at hotmail.com>
> Signed-off-by: Manuel Traut <manut at mecka.net>
> ---
>  arch/arm64/boot/dts/rockchip/Makefile              |   2 +
>  .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts     |  26 +
>  .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts     |  46 +
>  arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi  | 979 +++++++++++++++++++++
>  4 files changed, 1053 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index a18f33bf0c0e..ef66c0937a9b 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -77,6 +77,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v0.1.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v2.0.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> new file mode 100644
> index 000000000000..8b110186a3eb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3566-pinetab2.dtsi"
> +
> +/ {
> +	model = "Pine64 PineTab2 v0.1";
> +	compatible = "pine64,pinetab2-v0.1", "pine64,pinetab2", "rockchip,rk3566";
> +};
> +
> +&lcd {
> +	reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
> +};
> +
> +&pinctrl {
> +	lcd0 {
> +		lcd0_rst_l: lcd0-rst-l {
> +			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&sdmmc1 {
> +	vmmc-supply = <&vcc3v3_sys>;
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> new file mode 100644
> index 000000000000..6f80446b5802
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3566-pinetab2.dtsi"
> +
> +/ {
> +	model = "Pine64 PineTab2 v2.0";
> +	compatible = "pine64,pinetab2-v2.0", "pine64,pinetab2", "rockchip,rk3566";
> +};
> +
> +&gpio_keys {
> +	pinctrl-0 = <&kb_id_det>, <&hall_int_l>;
> +
> +	event-hall-sensor {
> +		debounce-interval = <20>;
> +		gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
> +		label = "Hall Sensor";
> +		linux,code = <SW_LID>;
> +		linux,input-type = <EV_SW>;
> +		wakeup-event-action = <EV_ACT_DEASSERTED>;
> +		wakeup-source;
> +	};
> +};
> +
> +&lcd {
> +	reset-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_LOW>;
> +};
> +
> +&pinctrl {
> +	lcd0 {
> +		lcd0_rst_l: lcd0-rst-l {
> +			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	hall {
> +		hall_int_l: hall-int-l {
> +			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&sdmmc1 {
> +	vmmc-supply = <&vcc_sys>;
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> new file mode 100644
> index 000000000000..3ab7d8dbe1ec
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> @@ -0,0 +1,979 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/gpio-keys.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/soc/rockchip,vop2.h>
> +#include <dt-bindings/usb/pd.h>
> +#include "rk3566.dtsi"
> +
> +/ {
> +	chassis-type = "tablet";
> +
> +	aliases {
> +		mmc0 = &sdmmc0;
> +		mmc1 = &sdhci;

I would have expected to see sdhci as mmc0 and sdmmc0 as mmc1 here
because the emmc is on-board and the sd-card is optional/secondary.

Also please be consistent with product name and use PineTab2 instead of
Pinetab2 in commit subject/messages.

Regards,
Jonas

> +	};
> +
> +	chosen {
> +		stdout-path = "serial2:1500000n8";
> +	};
> +
> +	adc-keys {
> +		compatible = "adc-keys";
> +		io-channels = <&saradc 0>;
> +		io-channel-names = "buttons";
> +		keyup-threshold-microvolt = <1800000>;
> +		poll-interval = <25>;
> +
> +		button-vol-up {
> +			label = "Volume Up";
> +			linux,code = <KEY_VOLUMEUP>;
> +			press-threshold-microvolt = <297500>;
> +		};
> +
> +		button-vol-down {
> +			label = "Volume Down";
> +			linux,code = <KEY_VOLUMEDOWN>;
> +			press-threshold-microvolt = <1750>;
> +		};
> +	};
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm4 0 25000 0>;
> +		brightness-levels = <20 220>;
> +		num-interpolated-steps = <200>;
> +		default-brightness-level = <100>;
> +		power-supply = <&vcc_sys>;
> +	};
> +
> +	battery: battery {
> +		compatible = "simple-battery";
> +		charge-full-design-microamp-hours = <6000000>;
> +		charge-term-current-microamp = <300000>;
> +		constant-charge-current-max-microamp = <2000000>;
> +		constant-charge-voltage-max-microvolt = <4300000>;
> +		voltage-max-design-microvolt = <4350000>;
> +		voltage-min-design-microvolt = <3400000>;
> +
> +		ocv-capacity-celsius = <20>;
> +		ocv-capacity-table-0 = <4322000 100>, <4250000 95>, <4192000 90>, <4136000 85>,
> +				       <4080000 80>, <4022000 75>, <3972000 70>, <3928000 65>,
> +				       <3885000 60>, <3833000 55>, <3798000 50>, <3780000 45>,
> +				       <3776000 40>, <3773000 35>, <3755000 30>, <3706000 25>,
> +				       <3640000 20>, <3589000 15>, <3535000 10>, <3492000 5>,
> +				       <3400000 0>;
> +	};
> +
> +	gpio_keys: gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&kb_id_det>;
> +
> +		tablet-mode-switch {
> +			debounce-interval = <20>;
> +			gpios = <&gpio4 RK_PA4 GPIO_ACTIVE_HIGH>;
> +			label = "Tablet Mode";
> +			linux,input-type = <EV_SW>;
> +			linux,code = <SW_TABLET_MODE>;
> +		};
> +	};
> +
> +	hdmi-con {
> +		compatible = "hdmi-connector";
> +		type = "d";
> +
> +		port {
> +			hdmi_con_in: endpoint {
> +				remote-endpoint = <&hdmi_out_con>;
> +			};
> +		};
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&flash_led_en_h>;
> +
> +		led-0 {
> +			gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
> +			color = <LED_COLOR_ID_WHITE>;
> +			function = LED_FUNCTION_FLASH;
> +		};
> +	};
> +
> +	rk817-sound {
> +		compatible = "simple-audio-card";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&hp_det_l>;
> +		simple-audio-card,format = "i2s";
> +		simple-audio-card,name = "rk817_ext";
> +		simple-audio-card,mclk-fs = <256>;
> +
> +		simple-audio-card,widgets =
> +			"Microphone", "Mic Jack",
> +			"Headphone", "Headphones",
> +			"Speaker", "Internal Speakers";
> +
> +		simple-audio-card,routing =
> +			"MICR", "Mic Jack",
> +			"Headphones", "HPOL",
> +			"Headphones", "HPOR",
> +			"Internal Speakers", "Speaker Amplifier OUTL",
> +			"Internal Speakers", "Speaker Amplifier OUTR",
> +			"Speaker Amplifier INL", "HPOL",
> +			"Speaker Amplifier INR", "HPOR";
> +		simple-audio-card,hp-det-gpio = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
> +		simple-audio-card,aux-devs = <&speaker_amp>;
> +		simple-audio-card,pin-switches = "Internal Speakers";
> +
> +		simple-audio-card,cpu {
> +			sound-dai = <&i2s1_8ch>;
> +		};
> +
> +		simple-audio-card,codec {
> +			sound-dai = <&rk817>;
> +		};
> +	};
> +
> +	speaker_amp: speaker-amplifier {
> +		compatible = "simple-audio-amplifier";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&spk_ctl>;
> +		enable-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_HIGH>;
> +		sound-name-prefix = "Speaker Amplifier";
> +		VCC-supply = <&vcc_bat>;
> +	};
> +
> +	vcc_3v3: vcc-3v3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_3v3";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc3v3_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc3v3_minipcie: vcc3v3-minipcie {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PC3 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pcie_pwren_h>;
> +		regulator-name = "vcc3v3_minipcie";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc3v3_sd: vcc3v3-sd {
> +		compatible = "regulator-fixed";
> +		gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&sdmmc_pwren_l>;
> +		regulator-name = "vcc3v3_sd";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc3v3_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc5v0_usb_host0: vcc5v0-usb-host0 {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PC4 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&usb_host_pwren1_h>;
> +		regulator-name = "vcc5v0_usb_host0";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v_midu>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc5v0_usb_host2: vcc5v0-usb-host2 {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PC5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&usb_host_pwren2_h>;
> +		regulator-name = "vcc5v0_usb_host2";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&vcc5v_midu>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc_bat: vcc-bat {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_bat";
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +
> +	vcc_sys: vcc-sys {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vcc_bat>;
> +	};
> +
> +	vdd1v2_dvp: vdd1v2-dvp {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vdd1v2_dvp";
> +		regulator-min-microvolt = <1200000>;
> +		regulator-max-microvolt = <1200000>;
> +		vin-supply = <&vcc_3v3>;
> +		/*enable-supply = <&vcc2v8_dvp>;*/
> +	};
> +};
> +
> +&combphy1 {
> +	status = "okay";
> +};
> +
> +&combphy2 {
> +	status = "okay";
> +};
> +
> +&cpu0 {
> +	cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cpu1 {
> +	cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cpu2 {
> +	cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cpu3 {
> +	cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cru {
> +	assigned-clocks = <&pmucru CLK_RTC_32K>, <&cru PLL_GPLL>,
> +			  <&pmucru PLL_PPLL>, <&cru PLL_VPLL>;
> +	assigned-clock-rates = <32768>, <1200000000>, <200000000>, <500000000>;
> +	assigned-clock-parents = <&pmucru CLK_RTC32K_FRAC>;
> +};
> +
> +&csi_dphy {
> +	status = "okay";
> +};
> +
> +&dsi0 {
> +	status = "okay";
> +	clock-master;
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	lcd: panel at 0 {
> +		compatible = "boe,th101mb31ig002-28a";
> +		reg = <0>;
> +		backlight = <&backlight>;
> +		enable-gpios = <&gpio0 RK_PC7 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&lcd_pwren_h &lcd0_rst_l>;
> +		rotation = <90>;
> +		power-supply = <&vcc_3v3>;
> +
> +		port at 0 {
> +			panel_in_dsi: endpoint at 0 {
> +				remote-endpoint = <&dsi0_out_con>;
> +			};
> +		};
> +	};
> +};
> +
> +&dsi0_in {
> +	dsi0_in_vp1: endpoint {
> +		remote-endpoint = <&vp1_out_dsi0>;
> +	};
> +};
> +
> +&dsi0_out {
> +	dsi0_out_con: endpoint {
> +		remote-endpoint = <&panel_in_dsi>;
> +	};
> +};
> +
> +&dsi_dphy0 {
> +	status = "okay";
> +};
> +
> +&gpu {
> +	mali-supply = <&vdd_gpu_npu>;
> +	status = "okay";
> +};
> +
> +&hdmi {
> +	avdd-0v9-supply = <&vdda_0v9_p>;
> +	avdd-1v8-supply = <&vcc_1v8>;
> +	status = "okay";
> +};
> +
> +&hdmi_in {
> +	hdmi_in_vp0: endpoint {
> +		remote-endpoint = <&vp0_out_hdmi>;
> +	};
> +};
> +
> +&hdmi_out {
> +	hdmi_out_con: endpoint {
> +		remote-endpoint = <&hdmi_con_in>;
> +	};
> +};
> +
> +&hdmi_sound {
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	vdd_cpu: regulator at 1c {
> +		compatible = "tcs,tcs4525";
> +		reg = <0x1c>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu";
> +		regulator-min-microvolt = <800000>;
> +		regulator-max-microvolt = <1150000>;
> +		regulator-ramp-delay = <2300>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vcc_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	rk817: pmic at 20 {
> +		compatible = "rockchip,rk817";
> +		reg = <0x20>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
> +		assigned-clocks = <&cru I2S1_MCLKOUT_TX>;
> +		assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>;
> +		clock-names = "mclk";
> +		clocks = <&cru I2S1_MCLKOUT_TX>;
> +		clock-output-names = "rk808-clkout1", "rk808-clkout2";
> +		#clock-cells = <1>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_int_l>, <&i2s1m0_mclk>;
> +		rockchip,system-power-controller;
> +		#sound-dai-cells = <0>;
> +		wakeup-source;
> +
> +		vcc1-supply = <&vcc_sys>;
> +		vcc2-supply = <&vcc_sys>;
> +		vcc3-supply = <&vcc_sys>;
> +		vcc4-supply = <&vcc_sys>;
> +		vcc5-supply = <&vcc_sys>;
> +		vcc6-supply = <&vcc_sys>;
> +		vcc7-supply = <&vcc_sys>;
> +		vcc8-supply = <&vcc_sys>;
> +		vcc9-supply = <&vcc5v_midu>;
> +
> +		regulators {
> +			vdd_logic: DCDC_REG1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vdd_logic";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_gpu_npu: DCDC_REG2 {
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vdd_gpu_npu";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_ddr: DCDC_REG3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vcc_ddr";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc3v3_sys: DCDC_REG4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vcc3v3_sys";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcca1v8_pmu: LDO_REG1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcca1v8_pmu";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vdda_0v9_p: LDO_REG2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <900000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-name = "vdda_0v9_p";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdda0v9_pmu: LDO_REG3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <900000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-name = "vdda0v9_pmu";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vccio_acodec: LDO_REG4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vccio_acodec";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vccio_sd: LDO_REG5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vccio_sd";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc3v3_pmu: LDO_REG6 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vcc3v3_pmu";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8: LDO_REG7 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc_1v8";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc1v8_dvp: LDO_REG8 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc1v8_dvp";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc2v8_dvp: LDO_REG9 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <2800000>;
> +				regulator-max-microvolt = <2800000>;
> +				regulator-name = "vcc2v8_dvp";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc5v_midu: BOOST {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <5000000>;
> +				regulator-max-microvolt = <5000000>;
> +				regulator-name = "boost";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vbus: OTG_SWITCH {
> +				regulator-min-microvolt = <5000000>;
> +				regulator-max-microvolt = <5000000>;
> +				regulator-name = "otg_switch";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +
> +		charger {
> +			monitored-battery = <&battery>;
> +			rockchip,resistor-sense-micro-ohms = <10000>;
> +			rockchip,sleep-enter-current-microamp = <300000>;
> +			rockchip,sleep-filter-current-microamp = <100000>;
> +		};
> +	};
> +};
> +
> +&i2c1 {
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	touchscreen at 5d {
> +		compatible = "goodix,gt911";
> +		reg = <0x5d>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PB0 IRQ_TYPE_EDGE_FALLING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&tp_int_l_pmuio2>, <&tp_rst_l_pmuio2>;
> +		AVDD28-supply = <&vcc3v3_pmu>;
> +		VDDIO-supply = <&vcca1v8_pmu>;
> +		irq-gpios = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>;
> +		reset-gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_HIGH>;
> +	};
> +};
> +
> +&i2c2 {
> +	clock-frequency = <400000>;
> +	pinctrl-0 = <&i2c2m1_xfer>;
> +	status = "okay";
> +
> +	vcm at c {
> +		compatible = "dongwoon,dw9714";
> +		reg = <0x0c>;
> +		vcc-supply = <&vcc1v8_dvp>;
> +	};
> +
> +	camera at 36 {
> +		compatible = "ovti,ov5648";
> +		reg = <0x36>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&camerab_pdn_l &camerab_rst_l>;
> +
> +		clocks = <&cru CLK_CIF_OUT>;
> +		assigned-clocks = <&cru CLK_CIF_OUT>;
> +		assigned-clock-rates = <24000000>;
> +
> +		avdd-supply = <&vcc2v8_dvp>;
> +		dvdd-supply = <&vdd1v2_dvp>;
> +		dovdd-supply = <&vcc1v8_dvp>;
> +		powerdown-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
> +		reset-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
> +
> +		port {
> +			endpoint {
> +				data-lanes = <1 2>;
> +				remote-endpoint = <0>;
> +				link-frequencies = /bits/ 64 <210000000 168000000>;
> +			};
> +		};
> +	};
> +};
> +
> +&i2c5 {
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	accelerometer at 18 {
> +		compatible = "silan,sc7a20";
> +		reg = <0x18>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gsensor_int_l>;
> +		st,drdy-int-pin = <1>;
> +		vdd-supply = <&vcc_1v8>;
> +		vddio-supply = <&vcc_1v8>;
> +		mount-matrix = "1", "0", "0",
> +			       "0", "0", "1",
> +			       "0", "1", "0";
> +	};
> +};
> +
> +&i2s0_8ch {
> +	status = "okay";
> +};
> +
> +&i2s1_8ch {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2s1m0_sclktx
> +		     &i2s1m0_lrcktx
> +		     &i2s1m0_sdi0
> +		     &i2s1m0_sdo0>;
> +	rockchip,trcm-sync-tx-only;
> +	status = "okay";
> +};
> +
> +&pcie2x1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pcie_reset_h>;
> +	reset-gpios = <&gpio1 RK_PB2 GPIO_ACTIVE_HIGH>;
> +	vpcie3v3-supply = <&vcc3v3_minipcie>;
> +	status = "okay";
> +};
> +
> +&pinctrl {
> +	bt {
> +		bt_wake_host_h: bt-wake-host-h {
> +			rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
> +		};
> +	};
> +
> +	camerab {
> +		camerab_pdn_l: camerab-pdn-l {
> +			rockchip,pins = <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		camerab_rst_l: camerab-rst-l {
> +			rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	cameraf {
> +		cameraf_pdn_l: cameraf-pdn-l {
> +			rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		cameraf_rst_l: cameraf-rst-l {
> +			rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	flash {
> +		flash_led_en_h: flash-led-en-h {
> +			rockchip,pins = <4 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	fspi {
> +		fspi_dual_io_pins: fspi-dual-io-pins {
> +			rockchip,pins =
> +				/* fspi_clk */
> +				<1 RK_PD0 1 &pcfg_pull_none>,
> +				/* fspi_cs0n */
> +				<1 RK_PD3 1 &pcfg_pull_none>,
> +				/* fspi_d0 */
> +				<1 RK_PD1 1 &pcfg_pull_none>,
> +				/* fspi_d1 */
> +				<1 RK_PD2 1 &pcfg_pull_none>;
> +		};
> +	};
> +
> +	gsensor {
> +		gsensor_int_l: gsensor-int-l {
> +			rockchip,pins = <3 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	kb {
> +		kb_id_det: kb-id-det {
> +			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	lcd {
> +		lcd_pwren_h: lcd-pwren-h {
> +			rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	pcie {
> +		pcie_pwren_h: pcie-pwren-h {
> +			rockchip,pins = <4 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		pcie_reset_h: pcie-reset-h {
> +			rockchip,pins = <1 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	pmic {
> +		pmic_int_l: pmic-int-l {
> +			rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	sdmmc {
> +		sdmmc_pwren_l: sdmmc-pwren-l {
> +			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	sound {
> +		hp_det_l: hp-det-l {
> +			rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		spk_ctl: spk-ctl {
> +			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	tp {
> +		tp_int_l_pmuio2: tp-int-l-pmuio2 {
> +			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +
> +		tp_rst_l_pmuio2: tp-rst-l-pmuio2 {
> +			rockchip,pins = <0 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	usb {
> +		usbcc_int_l: usbcc-int-l {
> +			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		usb_host_pwren1_h: usb-host-pwren1-h {
> +			rockchip,pins = <4 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		usb_host_pwren2_h: usb-host-pwren2-h {
> +			rockchip,pins = <4 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	wifi {
> +		host_wake_wl: host-wake-wl {
> +			rockchip,pins = <0 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		wifi_pwren: wifi-pwren {
> +			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		wifi_wake_host_h: wifi-wake-host-h {
> +			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
> +		};
> +	};
> +};
> +
> +&pmu_io_domains {
> +	pmuio1-supply = <&vcc3v3_pmu>;
> +	pmuio2-supply = <&vcca1v8_pmu>;
> +	vccio1-supply = <&vccio_acodec>;
> +	vccio2-supply = <&vcc_1v8>;
> +	vccio3-supply = <&vccio_sd>;
> +	vccio4-supply = <&vcc_1v8>;
> +	vccio5-supply = <&vcc_1v8>;
> +	vccio6-supply = <&vcc1v8_dvp>;
> +	vccio7-supply = <&vcc_3v3>;
> +	status = "okay";
> +};
> +
> +&pwm4 {
> +	status = "okay";
> +};
> +
> +&saradc {
> +	vref-supply = <&vcc_1v8>;
> +	status = "okay";
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	no-sdio;
> +	no-sd;
> +	non-removable;
> +	max-frequency = <200000000>;
> +	mmc-hs200-1_8v;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&emmc_bus8
> +		     &emmc_clk
> +		     &emmc_cmd
> +		     &emmc_datastrobe
> +		     &emmc_rstnout>;
> +	vmmc-supply = <&vcc_3v3>;
> +	vqmmc-supply = <&vcc_1v8>;
> +	status = "okay";
> +};
> +
> +&sdmmc0 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
> +	disable-wp;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdmmc0_bus4
> +		     &sdmmc0_clk
> +		     &sdmmc0_cmd
> +		     &sdmmc0_det>;
> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc3v3_sd>;
> +	vqmmc-supply = <&vccio_sd>;
> +	status = "okay";
> +};
> +
> +&sdmmc1 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cap-sdio-irq;
> +	keep-power-in-suspend;
> +	non-removable;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdmmc1_bus4
> +		     &sdmmc1_cmd
> +		     &sdmmc1_clk>;
> +	sd-uhs-sdr104;
> +	vqmmc-supply = <&vcca1v8_pmu>;
> +	status = "okay";
> +};
> +
> +&sfc {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&fspi_dual_io_pins>;
> +	status = "okay";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	flash at 0 {
> +		compatible = "jedec,spi-nor";
> +		reg = <0>;
> +		spi-max-frequency = <24000000>;
> +		spi-rx-bus-width = <2>;
> +		spi-tx-bus-width = <1>;
> +	};
> +};
> +
> +&tsadc {
> +	rockchip,hw-tshut-mode = <1>;
> +	rockchip,hw-tshut-polarity = <0>;
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart1m0_xfer
> +		     &uart1m0_ctsn
> +		     &uart1m0_rtsn>;
> +	status = "okay";
> +	uart-has-rtscts;
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> +
> +&usb_host0_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host0_ohci {
> +	status = "okay";
> +};
> +
> +&usb_host0_xhci {
> +	status = "okay";
> +};
> +
> +&usb_host1_xhci {
> +	status = "okay";
> +};
> +
> +&usb2phy0 {
> +	status = "okay";
> +};
> +
> +&usb2phy0_host {
> +	phy-supply = <&vcc5v0_usb_host0>;
> +	status = "okay";
> +};
> +
> +&usb2phy0_otg {
> +	status = "okay";
> +};
> +
> +&usb2phy1 {
> +	status = "okay";
> +};
> +
> +&usb2phy1_otg {
> +	phy-supply = <&vcc5v0_usb_host2>;
> +	status = "okay";
> +};
> +
> +&vop {
> +	assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
> +	assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
> +	status = "okay";
> +};
> +
> +&vop_mmu {
> +	status = "okay";
> +};
> +
> +&vp0 {
> +	vp0_out_hdmi: endpoint at ROCKCHIP_VOP2_EP_HDMI0 {
> +		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
> +		remote-endpoint = <&hdmi_in_vp0>;
> +	};
> +};
> +
> +&vp1 {
> +	vp1_out_dsi0: endpoint at ROCKCHIP_VOP2_EP_MIPI0 {
> +		reg = <ROCKCHIP_VOP2_EP_MIPI0>;
> +		remote-endpoint = <&dsi0_in_vp1>;
> +	};
> +};
> 



From arinc.unal at arinc9.com  Thu Dec 28 08:58:13 2023
From: arinc.unal at arinc9.com (=?UTF-8?B?QXLEsW7DpyDDnE5BTA==?=)
Date: Thu, 28 Dec 2023 19:58:13 +0300
Subject: [PATCH net-next] net: dsa: mt7530: register OF node for internal
 MDIO bus
In-Reply-To: <20231227200217.kdltxpmhvlp6z4cd@skbuf>
References: <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231220173539.59071-1-arinc.unal@arinc9.com>
 <20231221151607.ujobhh4aet4obxdz@skbuf>
 <6600c6b1-2230-4963-940c-8b95a01750fd@arinc9.com>
 <20231227191154.6jkqdlqdxciidpfw@skbuf>
 <bdbe24b2-30f6-48fa-b6eb-a1ae3afe9076@arinc9.com>
 <20231227200217.kdltxpmhvlp6z4cd@skbuf>
Message-ID: <d2a7cc7e-bb27-472f-8921-5579a894c71d@arinc9.com>

On 27.12.2023 23:02, Vladimir Oltean wrote:
> On Wed, Dec 27, 2023 at 10:51:08PM +0300, Ar?n? ?NAL wrote:
>> I didn't realise ds->user_mii_bus is also used to store irq mapping for
>> each PHY.
> 
> It needs to, if the MDIO bus does not have an OF description through
> which PHYs can have an 'interrupts' property. But if there is an OF
> description for the MDIO bus and the PHYs, I think it is strange to
> expect PHYs to have interrupts if they aren't described in OF.
> 
>> Should we agree that user_mii_bus is needed for all cases or make
>> another way to store the irq mappings?
> 
> I looked at the upstream device trees:
> - users of arch/mips/boot/dts/ralink/mt7621.dtsi
> - arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dts
> - arch/arm/boot/dts/mediatek/mt7623n-rfb-emmc.dts
> - arch/arm/boot/dts/mediatek/mt7623a.dtsi
> - arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
> - arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
> - arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts
> - arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
> 
> and without exception, none of these have the MDIO bus described in OF.
> I'm not sure about other device trees. But it may well be that the
> situation where "MDIO buses present in OF need an IRQ mapping for their
> PHYs" does not need to be handled.

As Daniel stated on a previous submission of this patch, being able to
reference the PHYs on the switch MDIO bus is mandatory on MT7988 as
calibration data from NVMEM for each PHY is required, so defining the MDIO
bus is required to support MT7988. Therefore, we should support interrupts
on device trees with the switch MDIO bus defined.

The implementation below follows this logic:

No switch MDIO bus defined: Register the MDIO bus, set the interrupts for
PHYs if "interrupt-controller" is defined at the switch node.

Switch MDIO bus defined: Register the MDIO bus, set the interrupts for PHYs
if ["interrupt-controller" is defined at the switch node and "interrupts"
is defined at the PHY nodes under the switch MDIO bus node].

I think this approach fits your description so I'd like to agree that this
should be the way for all DSA subdrivers. Please let me know what you
think.

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 391c4dbdff42..bbd230a73ead 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2155,15 +2155,21 @@ mt7530_setup_mdio(struct mt7530_priv *priv)
  {
  	struct dsa_switch *ds = priv->ds;
  	struct device *dev = priv->dev;
+	struct device_node *np, *mnp;
  	struct mii_bus *bus;
  	static int idx;
  	int ret;
  
+	np = priv->dev->of_node;
+	mnp = of_get_child_by_name(np, "mdio");
+
  	bus = devm_mdiobus_alloc(dev);
  	if (!bus)
  		return -ENOMEM;
  
-	ds->user_mii_bus = bus;
+	if (mnp == NULL)
+		ds->user_mii_bus = bus;
+
  	bus->priv = priv;
  	bus->name = KBUILD_MODNAME "-mii";
  	snprintf(bus->id, MII_BUS_ID_SIZE, KBUILD_MODNAME "-%d", idx++);
@@ -2174,10 +2180,11 @@ mt7530_setup_mdio(struct mt7530_priv *priv)
  	bus->parent = dev;
  	bus->phy_mask = ~ds->phys_mii_mask;
  
-	if (priv->irq)
+	if (priv->irq && mnp == NULL)
  		mt7530_setup_mdio_irq(priv);
  
-	ret = devm_mdiobus_register(dev, bus);
+	ret = devm_of_mdiobus_register(dev, bus, mnp);
+	of_node_put(mnp);
  	if (ret) {
  		dev_err(dev, "failed to register MDIO bus: %d\n", ret);
  		if (priv->irq)

With this device tree:

switch {
	interrupt-controller;
}

[    1.420534] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7530 PHY] (irq=17)
[    1.433224] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=18)
[    1.445338] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=19)
[    1.457472] mt7530-mdio mdio-bus:1f lan4 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=20)
[    1.469587] mt7530-mdio mdio-bus:1f wan (uninitialized): PHY [mt7530-0:04] driver [MediaTek MT7530 PHY] (irq=21)

With this device tree:

switch {
	interrupt-controller;

	mdio {
		phy {
			reg = <0>;
		}
	}
}

[    1.413101] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7530 PHY] (irq=POLL)
[    1.429954] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=POLL)
[    1.443704] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=POLL)
[    1.455876] mt7530-mdio mdio-bus:1f lan4 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=POLL)
[    1.468079] mt7530-mdio mdio-bus:1f wan (uninitialized): PHY [mt7530-0:04] driver [MediaTek MT7530 PHY] (irq=POLL)

With this device tree:

switch {
	interrupt-controller;

	mdio {
		phy {
			reg = <0>;
			interrupts = <0>;
		}
	}
}

[    1.420534] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7530 PHY] (irq=17)
[    1.433224] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=18)
[    1.445338] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=19)
[    1.457472] mt7530-mdio mdio-bus:1f lan4 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=20)
[    1.469587] mt7530-mdio mdio-bus:1f wan (uninitialized): PHY [mt7530-0:04] driver [MediaTek MT7530 PHY] (irq=21)

Ar?n?


From inindev at gmail.com  Thu Dec 28 09:29:35 2023
From: inindev at gmail.com (John Clark)
Date: Thu, 28 Dec 2023 17:29:35 +0000
Subject: [PATCH v2] arm64: dts: rockchip: nanopc-t6 sdmmc device tuning
Message-ID: <20231228173011.2863-1-inindev@gmail.com>

drop max-frequency = <200000000> as it is already defined in rk3588s.dtsi
order no-sdio & no-mmc properties while we are here

Signed-off-by: John Clark <inindev at gmail.com>
---
Changes since v1:
Additional scenarios need to be tested for proposed regulator and
cd-gpios changes. Withdrawing those submissions for now.
- removed proposed vcc3v3_sd_s0 regulator
- removed proposed cd-gpios
---
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
index e83b71510a47..d7722772ecd8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
@@ -536,13 +536,12 @@ &sdhci {
 };
 
 &sdmmc {
-	max-frequency = <200000000>;
-	no-sdio;
-	no-mmc;
 	bus-width = <4>;
 	cap-mmc-highspeed;
 	cap-sd-highspeed;
 	disable-wp;
+	no-mmc;
+	no-sdio;
 	sd-uhs-sdr104;
 	vmmc-supply = <&vcc_3v3_s3>;
 	vqmmc-supply = <&vccio_sd_s0>;
-- 
2.43.0



From wahrenst at gmx.net  Thu Dec 28 11:39:02 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Thu, 28 Dec 2023 20:39:02 +0100
Subject: [PATCH V2 1/2] ARM: sun9i: smp: Fix array-index-out-of-bounds read in sunxi_mc_smp_init
Message-ID: <20231228193903.9078-1-wahrenst@gmx.net>

Running a multi-arch kernel (multi_v7_defconfig) on a Raspberry Pi 3B+
with enabled CONFIG_UBSAN triggers the following warning:

 UBSAN: array-index-out-of-bounds in arch/arm/mach-sunxi/mc_smp.c:810:29
 index 2 is out of range for type 'sunxi_mc_smp_data [2]'
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc6-00248-g5254c0cbc92d
 Hardware name: BCM2835
  unwind_backtrace from show_stack+0x10/0x14
  show_stack from dump_stack_lvl+0x40/0x4c
  dump_stack_lvl from ubsan_epilogue+0x8/0x34
  ubsan_epilogue from __ubsan_handle_out_of_bounds+0x78/0x80
  __ubsan_handle_out_of_bounds from sunxi_mc_smp_init+0xe4/0x4cc
  sunxi_mc_smp_init from do_one_initcall+0xa0/0x2fc
  do_one_initcall from kernel_init_freeable+0xf4/0x2f4
  kernel_init_freeable from kernel_init+0x18/0x158
  kernel_init from ret_from_fork+0x14/0x28

Since the enabled method couldn't match with any entry from
sunxi_mc_smp_data, the value of the index shouldn't be used right after
the loop. So move it after the check of ret in order to have a valid
index.

Fixes: 1631090e34f5 ("ARM: sun9i: smp: Add is_a83t field")
Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
Changes in V2:
- append another patch to fix return code check

 arch/arm/mach-sunxi/mc_smp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index cb63921232a6..6ec3445f3c72 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -807,12 +807,12 @@ static int __init sunxi_mc_smp_init(void)
 			break;
 	}

-	is_a83t = sunxi_mc_smp_data[i].is_a83t;
-
 	of_node_put(node);
 	if (ret)
 		return -ENODEV;

+	is_a83t = sunxi_mc_smp_data[i].is_a83t;
+
 	if (!sunxi_mc_smp_cpu_table_init())
 		return -EINVAL;

--
2.34.1



From wahrenst at gmx.net  Thu Dec 28 11:39:03 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Thu, 28 Dec 2023 20:39:03 +0100
Subject: [PATCH V2 2/2] ARM: sun9i: smp: fix return code check of of_property_match_string
In-Reply-To: <20231228193903.9078-1-wahrenst@gmx.net>
References: <20231228193903.9078-1-wahrenst@gmx.net>
Message-ID: <20231228193903.9078-2-wahrenst@gmx.net>

of_property_match_string returns an int; either an index from 0 or
greater if successful or negative on failure. Even it's very
unlikely that the DT CPU node contains multiple enable-methods
these checks should be fixed.

This patch was inspired by the work of Nick Desaulniers.

Link: https://lore.kernel.org/lkml/20230516-sunxi-v1-1-ac4b9651a8c1 at google.com/T/
Cc: Nick Desaulniers <ndesaulniers at google.com>
Signed-off-by: Stefan Wahren <wahrenst at gmx.net>
---
 arch/arm/mach-sunxi/mc_smp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index 6ec3445f3c72..277f6aa8e6c2 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -803,12 +803,12 @@ static int __init sunxi_mc_smp_init(void)
 	for (i = 0; i < ARRAY_SIZE(sunxi_mc_smp_data); i++) {
 		ret = of_property_match_string(node, "enable-method",
 					       sunxi_mc_smp_data[i].enable_method);
-		if (!ret)
+		if (ret >= 0)
 			break;
 	}

 	of_node_put(node);
-	if (ret)
+	if (ret < 0)
 		return -ENODEV;

 	is_a83t = sunxi_mc_smp_data[i].is_a83t;
--
2.34.1



From wahrenst at gmx.net  Thu Dec 28 12:46:08 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Thu, 28 Dec 2023 21:46:08 +0100
Subject: [PATCH v4 2/2] arm64: dts: imx93-var-som: Add Variscite
 VAR-SOM-MX93
In-Reply-To: <20231227170919.8771-3-othacehe@gnu.org>
References: <20231227170919.8771-1-othacehe@gnu.org>
 <20231227170919.8771-3-othacehe@gnu.org>
Message-ID: <d378ad67-2a75-4a14-a131-7eb91de9ad3d@gmx.net>

Hi Mathieu,

Am 27.12.23 um 18:09 schrieb Mathieu Othacehe:
> Add DTSI for Variscite VAR-SOM-MX93 System on Module and DTS for Variscite
> VAR-SOM-MX93 on Symphony evaluation board.
>
> This version comes with:
> - NXP i.MX 93 Dual, 1.7GHz, Cortex-A55 + Cortex-M33
> - 2 GB of RAM
> - 16GB eMMC
> - 802.11ax/ac/a/b/g/n WiFi with 5.3 Bluetooth
> - CAN bus
> - Audio codec
>
> Reviewed-by: Fabio Estevam <festevam at gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Signed-off-by: Mathieu Othacehe <othacehe at gnu.org>
> ---
>   arch/arm64/boot/dts/freescale/Makefile        |   1 +
>   .../dts/freescale/imx93-var-som-symphony.dts  | 303 ++++++++++++++++++
>   .../boot/dts/freescale/imx93-var-som.dtsi     | 111 +++++++
>   3 files changed, 415 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
>   create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 2e027675d7bb..a6f1700961e3 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -203,6 +203,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
>   dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
>   dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxca.dtb
>   dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba93xxla.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
>
>   imx8mm-venice-gw72xx-0x-imx219-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-imx219.dtbo
>   imx8mm-venice-gw72xx-0x-rpidsi-dtbs	:= imx8mm-venice-gw72xx-0x.dtb imx8mm-venice-gw72xx-0x-rpidsi.dtbo
> diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
> new file mode 100644
> index 000000000000..3b7a01fb1b51
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-var-som-symphony.dts
> @@ -0,0 +1,303 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2021 NXP
> + * Copyright 2023 Variscite Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "imx93-var-som.dtsi"
> +
> +/{
> +	model = "Variscite VAR-SOM-MX93 on Symphony evaluation board";
> +	compatible = "variscite,var-som-mx93-symphony",
> +		     "variscite,var-som-mx93", "fsl,imx93";
> +
> +	aliases {
> +		ethernet0 = &eqos;
> +		ethernet1 = &fec;
> +	};
> +
> +	chosen {
> +		stdout-path = &lpuart1;
> +	};
> +
> +	/*
> +	 * Needed only for Symphony <= v1.5
> +	 */
> +	reg_fec_phy: regulator-fec-phy {
> +		compatible = "regulator-fixed";
> +		regulator-name = "fec-phy";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		regulator-enable-ramp-delay = <20000>;
> +		gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +		regulator-always-on;
> +	};
> +
> +	reg_usdhc2_vmmc: regulator-usdhc2 {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
> +		regulator-name = "VSD_3V3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
> +		off-on-delay-us = <20000>;
> +		enable-active-high;
> +	};
> +
> +	reg_vref_1v8: regulator-adc-vref {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vref_1v8";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +	};
> +
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		ethosu_mem: ethosu-region at 88000000 {
> +			compatible = "shared-dma-pool";
> +			reusable;
> +			reg = <0x0 0x88000000 0x0 0x8000000>;
> +		};
> +
> +		vdev0vring0: vdev0vring0 at 87ee0000 {
> +			reg = <0 0x87ee0000 0 0x8000>;
> +			no-map;
> +		};
> +
> +		vdev0vring1: vdev0vring1 at 87ee8000 {
> +			reg = <0 0x87ee8000 0 0x8000>;
> +			no-map;
> +		};
> +
> +		vdev1vring0: vdev1vring0 at 87ef0000 {
> +			reg = <0 0x87ef0000 0 0x8000>;
> +			no-map;
> +		};
> +
> +		vdev1vring1: vdev1vring1 at 87ef8000 {
> +			reg = <0 0x87ef8000 0 0x8000>;
> +			no-map;
> +		};
> +
> +		rsc_table: rsc-table at 2021f000 {
> +			reg = <0 0x2021f000 0 0x1000>;
> +			no-map;
> +		};
> +
> +		vdevbuffer: vdevbuffer at 87f00000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0 0x87f00000 0 0x100000>;
> +			no-map;
> +		};
> +
> +		ele_reserved: ele-reserved at 87de0000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0 0x87de0000 0 0x100000>;
> +			no-map;
> +		};
> +	};
> +};
> +
> +/* Use external instead of internal RTC*/
> +&bbnsm_rtc {
> +	status = "disabled";
> +};
> +
> +&eqos {
> +	mdio {
> +		ethphy1: ethernet-phy at 5 {
> +			compatible = "ethernet-phy-ieee802.3-c22";
> +			reg = <5>;
> +			qca,disable-smarteee;
> +			eee-broken-1000t;
> +			reset-gpios = <&pca9534 5 GPIO_ACTIVE_LOW>;
> +			reset-assert-us = <10000>;
> +			reset-deassert-us = <20000>;
> +			vddio-supply = <&vddio1>;
> +
> +			vddio1: vddio-regulator {
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +			};
> +		};
> +	};
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_fec>;
> +	phy-mode = "rgmii";
> +	phy-handle = <&ethphy1>;
> +	phy-supply = <&reg_fec_phy>;
> +	status = "okay";
> +};
> +
> +&flexcan1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_flexcan1>;
> +	status = "okay";
> +};
> +
> +&iomuxc {
> +	pinctrl_fec: fecgrp {
> +		fsl,pins = <
> +			MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0		0x57e
> +			MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1		0x57e
> +			MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2		0x57e
> +			MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3		0x57e
> +			MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC		0x5fe
> +			MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL	0x57e
> +			MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0		0x57e
> +			MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1		0x57e
> +			MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2		0x57e
> +			MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3		0x57e
> +			MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC		0x5fe
> +			MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL	0x57e
> +		>;
> +	};
> +
> +	pinctrl_flexcan1: flexcan1grp {
> +		fsl,pins = <
> +			MX93_PAD_PDM_CLK__CAN1_TX                       0x139e
> +			MX93_PAD_PDM_BIT_STREAM0__CAN1_RX               0x139e
> +		>;
> +	};
> +
> +	pinctrl_lpi2c1: lpi2c1grp {
> +		fsl,pins = <
> +			MX93_PAD_I2C1_SCL__LPI2C1_SCL			0x40000b9e
> +			MX93_PAD_I2C1_SDA__LPI2C1_SDA			0x40000b9e
> +		>;
> +	};
> +
> +	pinctrl_lpi2c1_gpio: lpi2c1gpiogrp {
> +		fsl,pins = <
> +			MX93_PAD_I2C1_SCL__GPIO1_IO00			0x31e
> +			MX93_PAD_I2C1_SDA__GPIO1_IO01			0x31e
> +		>;
> +	};
> +
> +	pinctrl_lpi2c5: lpi2c5grp {
> +		fsl,pins = <
> +			MX93_PAD_GPIO_IO23__LPI2C5_SCL			0x40000b9e
> +			MX93_PAD_GPIO_IO22__LPI2C5_SDA			0x40000b9e
> +		>;
> +	};
> +
> +	pinctrl_lpi2c5_gpio: lpi2c5gpiogrp {
> +		fsl,pins = <
> +			MX93_PAD_GPIO_IO23__GPIO2_IO23			0x31e
> +			MX93_PAD_GPIO_IO22__GPIO2_IO22			0x31e
> +		>;
> +	};
> +
> +	pinctrl_pca9534: pca9534grp {
> +		fsl,pins = <
> +			MX93_PAD_CCM_CLKO1__GPIO3_IO26		0x31e
> +		>;
> +	};
> +
> +	pinctrl_uart1: uart1grp {
> +		fsl,pins = <
> +			MX93_PAD_UART1_RXD__LPUART1_RX			0x31e
> +			MX93_PAD_UART1_TXD__LPUART1_TX			0x31e
> +		>;
> +	};
> +
> +	pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
> +		fsl,pins = <
> +			MX93_PAD_GPIO_IO18__GPIO2_IO18		0x31e
> +		>;
> +	};
> +
> +	pinctrl_usdhc2: usdhc2grp {
> +		fsl,pins = <
> +			MX93_PAD_SD2_CLK__USDHC2_CLK		0x15fe
> +			MX93_PAD_SD2_CMD__USDHC2_CMD		0x13fe
> +			MX93_PAD_SD2_DATA0__USDHC2_DATA0	0x13fe
> +			MX93_PAD_SD2_DATA1__USDHC2_DATA1	0x13fe
> +			MX93_PAD_SD2_DATA2__USDHC2_DATA2	0x13fe
> +			MX93_PAD_SD2_DATA3__USDHC2_DATA3	0x13fe
> +			MX93_PAD_SD2_VSELECT__USDHC2_VSELECT	0x51e
> +		>;
> +	};
> +
> +	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
> +		fsl,pins = <
> +			MX93_PAD_SD2_CD_B__GPIO3_IO00		0x31e
> +		>;
> +	};
> +};
> +
> +&lpi2c1 {
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default", "sleep", "gpio";
> +	pinctrl-0 = <&pinctrl_lpi2c1>;
> +	pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
> +	pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
> +	scl-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
> +	sda-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
> +	status = "okay";
> +
> +	/* DS1337 RTC module */
> +	rtc at 68 {
> +		compatible = "dallas,ds1337";
> +		reg = <0x68>;
> +	};
> +};
> +
> +&lpi2c5 {
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default", "sleep", "gpio";
> +	pinctrl-0 = <&pinctrl_lpi2c5>;
> +	pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
> +	pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
> +	scl-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>;
> +	sda-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
> +	status = "okay";
> +
> +	pca9534: gpio at 20 {
> +		compatible = "nxp,pca9534";
> +		reg = <0x20>;
> +		gpio-controller;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pca9534>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
> +		#gpio-cells = <2>;
> +		wakeup-source;
> +	};
there are neither gpio-line-names defined for this GPIO expander nor the
SOC. Are there no GPIOs which can be accessed from userspace?

Best regards


From linus.walleij at linaro.org  Thu Dec 28 13:13:45 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 28 Dec 2023 22:13:45 +0100
Subject: [PATCH] pinctrl: samsung: constify iomem pointers
In-Reply-To: <20231223191902.22857-1-krzysztof.kozlowski@linaro.org>
References: <20231223191902.22857-1-krzysztof.kozlowski@linaro.org>
Message-ID: <CACRpkdah=gsOuE8JVeG4ab2772ebgQ-0Vm8gRmPZbCZJWq4f2g@mail.gmail.com>

On Sat, Dec 23, 2023 at 8:19?PM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:

> Constify few pointers to iomem, where the destination memory is not
> modified, for code safety and readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>

Patch applied!

Yours,
Linus Walleij


From ck.hu at mediatek.com  Thu Dec 28 17:27:00 2023
From: ck.hu at mediatek.com (=?utf-8?B?Q0sgSHUgKOiDoeS/iuWFiSk=?=)
Date: Fri, 29 Dec 2023 01:27:00 +0000
Subject: [PATCH v3 8/9] mailbox: mediatek: Add CMDQ secure mailbox driver
In-Reply-To: <20231222045228.27826-9-jason-jh.lin@mediatek.com>
References: <20231222045228.27826-1-jason-jh.lin@mediatek.com>
	 <20231222045228.27826-9-jason-jh.lin@mediatek.com>
Message-ID: <1b21f5bfa561b049193742804de42a1c03500a73.camel@mediatek.com>

Hi, Jason:

On Fri, 2023-12-22 at 12:52 +0800, Jason-JH.Lin wrote:
> To support secure video path feature, GCE have to read/write
> registgers
> in the secure world. GCE will enable the secure access permission to
> the
> HW who wants to access the secure content buffer.
> 
> Add CMDQ secure mailbox driver to make CMDQ client user is able to
> sending their HW settings to the secure world. So that GCE can
> execute
> all instructions to configure HW in the secure world.
> 
> Signed-off-by: Jason-JH.Lin <jason-jh.lin at mediatek.com>
> ---

[snip]

> +
> +static int cmdq_sec_session_send(struct cmdq_sec_context *context,
> +				 struct cmdq_sec_task *sec_task, const
> u32 iwc_cmd,
> +				 const u32 thrd_idx, struct cmdq_sec
> *cmdq)
> +{
> +	int err = 0;
> +	u64 cost;
> +	struct iwc_cmdq_message_t *iwc_msg = NULL;
> +
> +	iwc_msg = (struct iwc_cmdq_message_t *)context->iwc_msg;
> +
> +	memset(iwc_msg, 0, sizeof(*iwc_msg));
> +	iwc_msg->cmd = iwc_cmd;
> +	iwc_msg->cmdq_id = cmdq->pdata->hwid;
> +	iwc_msg->command.thread = thrd_idx;
> +
> +	switch (iwc_cmd) {
> +	case CMD_CMDQ_IWC_SUBMIT_TASK:
> +		err = cmdq_sec_fill_iwc_msg(context, sec_task,
> thrd_idx);
> +		if (err)
> +			return err;
> +		break;
> +	case CMD_CMDQ_IWC_CANCEL_TASK:
> +		iwc_msg->cancel_task.wait_cookie = sec_task-
> >wait_cookie;
> +		iwc_msg->cancel_task.thread = thrd_idx;
> +		break;
> +	case CMD_CMDQ_IWC_PATH_RES_ALLOCATE:
> +		if (!cmdq->shared_mem || !cmdq->shared_mem->va) {
> +			dev_err(cmdq->mbox.dev, "%s %d: shared_mem is
> NULL", __func__, __LINE__);
> +			return -EFAULT;
> +		}
> +		iwc_msg->path_resource.size = cmdq->shared_mem->size;
> +		iwc_msg->path_resource.share_memoy_pa = cmdq-
> >shared_mem->pa;
> +		iwc_msg->path_resource.use_normal_irq = 1;
> +		break;
> +	default:
> +		break;
> +	}
> +
> +	cmdq->sec_invoke = sched_clock();
> +	dev_dbg(cmdq->mbox.dev, "%s execute cmdq:%p sec_task:%p
> command:%u thread:%u cookie:%d",
> +		__func__, cmdq, sec_task, iwc_cmd, thrd_idx,
> +		sec_task ? sec_task->wait_cookie : -1);
> +
> +	/* send message */
> +	err = cmdq_sec_execute_session(&context->tee_ctx, iwc_cmd,
> CMDQ_TIMEOUT_DEFAULT);
> +
> +	cmdq->sec_done = sched_clock();
> +	cost = div_u64(cmdq->sec_done - cmdq->sec_invoke, 1000000);
> +	if (cost >= CMDQ_TIMEOUT_DEFAULT)

Maybe for some client driver, 1 ms is too long, and for some client
driver 1 second is not long. So I think the timeout detection should be
done by client driver. And the execution time depend on the command
buffer generated by client driver, so only client driver has the
ability to debug the command buffer it generated. So it's not necessary
to detect timeout in cmdq driver.

Regards,
CK

> +		dev_err(cmdq->mbox.dev, "%s execute timeout cmdq:%p
> sec_task:%p cost:%lluus",
> +			__func__, cmdq, sec_task, cost);
> +	else
> +		dev_dbg(cmdq->mbox.dev, "%s execute done cmdq:%p
> sec_task:%p cost:%lluus",
> +			__func__, cmdq, sec_task, cost);
> +
> +	if (err)
> +		return err;
> +
> +	context->state = IWC_SES_ON_TRANSACTED;
> +	return 0;
> +}
> +

From herbert at gondor.apana.org.au  Thu Dec 28 19:28:43 2023
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 29 Dec 2023 11:28:43 +0800
Subject: [PATCH 1/7] crypto: rk3288 - Use helper to set reqsize
In-Reply-To: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
References: <20231218164649.2492465-1-ovidiu.panait@windriver.com>
Message-ID: <ZY486/gwA4o/hmeM@gondor.apana.org.au>

On Mon, Dec 18, 2023 at 06:46:43PM +0200, ovidiu.panait at windriver.com wrote:
> From: Ovidiu Panait <ovidiu.panait at windriver.com>
> 
> The value of reqsize must only be changed through the helper.
> 
> Signed-off-by: Ovidiu Panait <ovidiu.panait at windriver.com>
> ---
> Cc: Heiko Stuebner <heiko at sntech.de>
> Cc: Corentin Labbe <clabbe at baylibre.com>
> Cc: linux-rockchip at lists.infradead.org
> Cc: linux-arm-kernel at lists.infradead.org
> 
>  drivers/crypto/rockchip/rk3288_crypto_skcipher.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

All applied.  Thanks.
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From pratikmanvar09 at gmail.com  Thu Dec 28 22:30:07 2023
From: pratikmanvar09 at gmail.com (pratikmanvar09 at gmail.com)
Date: Fri, 29 Dec 2023 12:00:07 +0530
Subject: [PATCH] pwm: imx27: workaround of the pwm output bug
Message-ID: <20231229063013.1786-1-pratikmanvar09@gmail.com>

From: Clark Wang <xiaoning.wang at nxp.com>

This fixes the pwm output bug when decrease the duty cycle.
This is a limited workaround for the PWM IP issue TKT0577206.

Root cause:
When the SAR FIFO is empty, the new write value will be directly applied
to SAR even the current period is not over.
If the new SAR value is less than the old one, and the counter is
greater than the new SAR value, the current period will not filp the
level. This will result in a pulse with a duty cycle of 100%.

Workaround:
Add an old value SAR write before updating the new duty cycle to SAR.
This will keep the new value is always in a not empty fifo, and can be
wait to update after a period finished.

Limitation:
This workaround can only solve this issue when the PWM period is longer
than 2us(or <500KHz).

Reviewed-by: Jun Li <jun.li at nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Link: https://github.com/nxp-imx/linux-imx/commit/16181cc4eee61d87cbaba0e5a479990507816317
Tested-by: Pratik Manvar <pratik.manvar at ifm.com>
---
 drivers/pwm/pwm-imx27.c | 67 ++++++++++++++++++++++++++++++++++++++---
 1 file changed, 62 insertions(+), 5 deletions(-)

diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 29a3089c534c..c21b2a9f02ae 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -21,11 +21,13 @@
 #include <linux/platform_device.h>
 #include <linux/pwm.h>
 #include <linux/slab.h>
+#include <linux/spinlock.h>
 
 #define MX3_PWMCR			0x00    /* PWM Control Register */
 #define MX3_PWMSR			0x04    /* PWM Status Register */
 #define MX3_PWMSAR			0x0C    /* PWM Sample Register */
 #define MX3_PWMPR			0x10    /* PWM Period Register */
+#define MX3_PWMCNR			0x14    /* PWM Counter Register */
 
 #define MX3_PWMCR_FWM			GENMASK(27, 26)
 #define MX3_PWMCR_STOPEN		BIT(25)
@@ -91,6 +93,7 @@ struct pwm_imx27_chip {
 	 * value to return in that case.
 	 */
 	unsigned int duty_cycle;
+	spinlock_t lock;
 };
 
 #define to_pwm_imx27_chip(chip)	container_of(chip, struct pwm_imx27_chip, chip)
@@ -203,10 +206,10 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
 
 	sr = readl(imx->mmio_base + MX3_PWMSR);
 	fifoav = FIELD_GET(MX3_PWMSR_FIFOAV, sr);
-	if (fifoav == MX3_PWMSR_FIFOAV_4WORDS) {
+	if (fifoav >= MX3_PWMSR_FIFOAV_3WORDS) {
 		period_ms = DIV_ROUND_UP_ULL(pwm_get_period(pwm),
 					 NSEC_PER_MSEC);
-		msleep(period_ms);
+		msleep(period_ms * (fifoav - 2));
 
 		sr = readl(imx->mmio_base + MX3_PWMSR);
 		if (fifoav == FIELD_GET(MX3_PWMSR_FIFOAV, sr))
@@ -217,13 +220,15 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
 static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 			   const struct pwm_state *state)
 {
-	unsigned long period_cycles, duty_cycles, prescale;
+	unsigned long period_cycles, duty_cycles, prescale, counter_check, flags;
 	struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
+	void __iomem *reg_sar = imx->mmio_base + MX3_PWMSAR;
+	__force u32 sar_last, sar_current;
 	struct pwm_state cstate;
 	unsigned long long c;
 	unsigned long long clkrate;
 	int ret;
-	u32 cr;
+	u32 cr, timeout = 1000;
 
 	pwm_get_state(pwm, &cstate);
 
@@ -264,7 +269,57 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 		pwm_imx27_sw_reset(chip);
 	}
 
-	writel(duty_cycles, imx->mmio_base + MX3_PWMSAR);
+	/*
+	 * This is a limited workaround. When the SAR FIFO is empty, the new
+	 * write value will be directly applied to SAR even the current period
+	 * is not over.
+	 * If the new SAR value is less than the old one, and the counter is
+	 * greater than the new SAR value, the current period will not filp
+	 * the level. This will result in a pulse with a duty cycle of 100%.
+	 * So, writing the current value of the SAR to SAR here before updating
+	 * the new SAR value can avoid this issue.
+	 *
+	 * Add a spin lock and turn off the interrupt to ensure that the
+	 * real-time performance can be guaranteed as much as possible when
+	 * operating the following operations.
+	 *
+	 * 1. Add a threshold of 1.5us. If the time T between the read current
+	 * count value CNR and the end of the cycle is less than 1.5us, wait
+	 * for T to be longer than 1.5us before updating the SAR register.
+	 * This is to avoid the situation that when the first SAR is written,
+	 * the current cycle just ends and the SAR FIFO that just be written
+	 * is emptied again.
+	 *
+	 * 2. Use __raw_writel() to minimize the interval between two writes to
+	 * the SAR register to increase the fastest pwm frequency supported.
+	 *
+	 * When the PWM period is longer than 2us(or <500KHz), this workaround
+	 * can solve this problem.
+	 */
+	if (duty_cycles < imx->duty_cycle) {
+		c = clkrate * 1500;
+		do_div(c, NSEC_PER_SEC);
+		counter_check = c;
+		sar_last = cpu_to_le32(imx->duty_cycle);
+		sar_current = cpu_to_le32(duty_cycles);
+
+		spin_lock_irqsave(&imx->lock, flags);
+		if (state->period >= 2000) {
+			while ((period_cycles -
+				readl_relaxed(imx->mmio_base + MX3_PWMCNR))
+				< counter_check) {
+				if (!--timeout)
+					break;
+			};
+		}
+		if (!(MX3_PWMSR_FIFOAV &
+		      readl_relaxed(imx->mmio_base + MX3_PWMSR)))
+			__raw_writel(sar_last, reg_sar);
+		__raw_writel(sar_current, reg_sar);
+		spin_unlock_irqrestore(&imx->lock, flags);
+	} else
+		writel(duty_cycles, imx->mmio_base + MX3_PWMSAR);
+
 	writel(period_cycles, imx->mmio_base + MX3_PWMPR);
 
 	/*
@@ -325,6 +380,8 @@ static int pwm_imx27_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(imx->clk_per),
 				     "failed to get peripheral clock\n");
 
+	spin_lock_init(&imx->lock);
+	imx->duty_cycle = 0;
 	imx->chip.ops = &pwm_imx27_ops;
 	imx->chip.dev = &pdev->dev;
 	imx->chip.npwm = 1;
-- 
2.25.1



From sjg at chromium.org  Thu Dec 28 22:38:50 2023
From: sjg at chromium.org (Simon Glass)
Date: Fri, 29 Dec 2023 06:38:50 +0000
Subject: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
In-Reply-To: <CAK7LNAR7Fm-1yaZmyH78vG5yNbbW2Avjj5F63u+aST6JQoMd5A@mail.gmail.com>
References: <20231202035511.487946-1-sjg@chromium.org> <20231202035511.487946-3-sjg@chromium.org>
 <20231203153401.GV8402@pendragon.ideasonboard.com> <20231207142723.GA3187877@google.com>
 <20231207143814.GD15521@pendragon.ideasonboard.com> <CAGXv+5Go_0pEVAOLQmRCc_a9-YUtZEmBfXtMuBupX_nb9iqwbw@mail.gmail.com>
 <20231209152946.GC13421@pendragon.ideasonboard.com> <CAMuHMdVMZs6mnwWBgFwktO=8o=QzROv60cfZe085MhD6HxQjpQ@mail.gmail.com>
 <CAGXv+5Est3FL-XcEL-vB-6zVNas0mqb2cNYa==Yb7W2SQU9xVQ@mail.gmail.com>
 <CAK7LNATyD-PeNbaLTjJmU9=koqqE+V6QvFe09c2VrXopWvjpcw@mail.gmail.com> <CAK7LNAR7Fm-1yaZmyH78vG5yNbbW2Avjj5F63u+aST6JQoMd5A@mail.gmail.com>
Message-ID: <CAFLszTjfN8dzBNpr6+EVQiwen5BPoYtu8LJM3dCcd-sMP3=Nvw@mail.gmail.com>

Hi Masahiro,

On Thu, Dec 14, 2023 at 7:34?AM Masahiro Yamada <masahiroy at kernel.org> wrote:
>
> On Thu, Dec 14, 2023 at 3:12?PM Masahiro Yamada <masahiroy at kernel.org> wrote:
> >
> > On Thu, Dec 14, 2023 at 1:03?PM Chen-Yu Tsai <wenst at chromium.org> wrote:
> > >
> > > On Sun, Dec 10, 2023 at 1:31?AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > >
> > > > Hi Laurent,
> > > >
> > > > On Sat, Dec 9, 2023 at 4:29?PM Laurent Pinchart
> > > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > > On Thu, Dec 7, 2023 at 11:38?PM Laurent Pinchart
> > > > > > <laurent.pinchart at ideasonboard.com> wrote:
> > > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > > > > Compression defaults to gzip which gives a good balance of size and
> > > > > > > > > > performance.
> > > > > > > > > >
> > > > > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > > > > >
> > > > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > > > > devicetree, matching the compatible string of the running board with
> > > > > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > > > > filenames or other workarounds.
> > > > > > > > > >
> > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > > >
> > > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > > >
> > > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > > > > > > > requires compression utilities for the algorithm being used. Supported
> > > > > > > > > > compression options are the same as the Image.xxx files. For now there
> > > > > > > > > > is no way to change the compression other than by editing the rule for
> > > > > > > > > > $(obj)/image.fit
> > > > > > > > > >
> > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > > > > > > > this here, since it must be built separately from the Linux build.
> > > > > > > > >
> > > > > > > > > FIT images are very useful, so I think this is a very welcome addition
> > > > > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > > > > versatile nature of FIT images, there can't be any
> > > > > > > > > one-size-fits-them-all solution to build them, and striking the right
> > > > > > > > > balance between what makes sense for the kernel and the features that
> > > > > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > > > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > > > > > > > to delay merging this series.
> > > > > > > > >
> > > > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > > > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > > > > extending the supported command line arguments. It would perhaps be more
> > > > > > > > > difficult to integrate in the kernel build system though. This leads me
> > > > > > > > > to a second question: would you consider merging extensions to this
> > > > > > > > > script if they are not used by the kernel build system, but meant for
> > > > > > > > > users who manually invoke the script ? More generally, is the script
> > > > > > > >
> > > > > > > > We'd also be interested in some customization, though in a different way.
> > > > > > > > We imagine having a rule file that says X compatible string should map
> > > > > > > > to A base DTB, plus B and C DTBO for the configuration section. The base
> > > > > > > > DTB would carry all common elements of some device, while the DTBOs
> > > > > > > > carry all the possible second source components, like different display
> > > > > > > > panels or MIPI cameras for instance. This could drastically reduce the
> > > > > > > > size of FIT images in ChromeOS by deduplicating all the common stuff.
> > > > > > >
> > > > > > > Do you envision the "mapping" compatible string mapping to a config
> > > > > > > section in the FIT image, that would bundle the base DTB and the DTBOs ?
> > > > > >
> > > > > > That's exactly the idea. The mapping compatible string could be untied
> > > > > > from the base board's compatible string if needed (which we probably do).
> > > > > >
> > > > > > So something like:
> > > > > >
> > > > > > config {
> > > > > >     config-1 {
> > > > > >         compatible = "google,krane-sku0";
> > > > > >         fdt = "krane-baseboard", "krane-sku0-overlay";
> > > > > >     };
> > > > > > };
> > > > > >
> > > > > > With "krane-sku0-overlay" being an overlay that holds the differences
> > > > > > between the SKUs, in this case the display panel and MIPI camera (not
> > > > > > upstreamed) that applies to SKU0 in particular.
> > > > >
> > > > > The kernel DT makefiles already contain information on what overlays to
> > > > > apply to what base boards, in order to test the overlays and produce
> > > > > "full" DTBs. Maybe that information could be leveraged to create the
> > > > > configurations in the FIT image ?
> > > >
> > > > Although the "full" DTBs created may only be a subset of all possible
> > > > combinations (I believe Rob just started with creating one "full" DTB
> > > > for each overlay, cfr. the additions I made in commit a09c3e105a208580
> > > > ("arm64: dts: renesas: Apply overlays to base dtbs")), that could
> > > > definitely be a start.
> > > >
> > > > Now, since the kernel build system already creates "full" DTBs, does
> > > > that mean that all of the base DTBs, overlays, and "full" DTBs will
> > > > end up in the FIT image?
> > >
> > > I suppose we could add an option to the packing tool to be able to _not_
> > > add the "full" DTBs if they can also be assembled with a base DTB and
> > > overlays. Think of it as a firmware compatibility option: if the firmware
> > > supports overlays, then you almost always want the deconstructed parts,
> > > not the fully assembled ones. Vice versa.
> > >
> > > If we don't we could end up with two configurations that have the same
> > > compatible string?
> >
> >
> > Right.
> >
> > We would end up with such situations because applying
> > an overlay does not change the compatible string.
> >
> >
> >
> > With this code in arch/arm64/boot/dts/ti/Makefile:
> >
> > k3-am642-tqma64xxl-mbax4xxl-sdcard-dtbs := \
> >       k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-sdcard.dtbo
> > k3-am642-tqma64xxl-mbax4xxl-wlan-dtbs := \
> >       k3-am642-tqma64xxl-mbax4xxl.dtb k3-am64-tqma64xxl-mbax4xxl-wlan.dtbo
> >
> >
> >
> >
> > $ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-sdcard.dtb
> > 2>/dev/null| head -n15 | tail -n2
> >     model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> >     compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
> > "ti,am642";
> >
> >
> > $ fdtdump  arch/arm64/boot/dts/ti/k3-am642-tqma64xxl-mbax4xxl-wlan.dtb
> > 2>/dev/null| head -n15 | tail -n2
> >     model = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> >     compatible = "tq,am642-tqma6442l-mbax4xxl", "tq,am642-tqma6442l",
> > "ti,am642";
> >
> >
> >
> >
> >
> > These two go into image.fit, but one of them is completely dead
> > since there is no way to distinguish them.
> >
> >
> > $ fdtdump  arch/arm64/boot/image.fit
> >
> >         ...
> >
> >         conf-10 {
> >             compatible = "tq,am642-tqma6442l-mbax4xxl",
> > "tq,am642-tqma6442l", "ti,am642";
> >             description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> >             fdt = "fdt-10";
> >             kernel = "kernel";
> >         };
> >
> >         ...
> >
> >         conf-25 {
> >             compatible = "tq,am642-tqma6442l-mbax4xxl",
> > "tq,am642-tqma6442l", "ti,am642";
> >             description = "TQ-Systems TQMa64xxL SoM on MBax4xxL carrier board";
> >             fdt = "fdt-25";
> >             kernel = "kernel";
> >         };
> >
> >
> >
> >
> >
> > I agree with Chen-Yu.
> >
> > FIT should not include full DTBs.
> >
> > Bootloaders should assemble the final DTB
> > from base and overlays on-the-fly.
> >
> >
> > The FIT spec allows the "fdt" property to list
> > multiple image nodes.
> >
> >
> > o config-1
> >  |- description = "configuration description"
> >  |- kernel = "kernel sub-node unit name"
> >  |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
> >  |- loadables = "loadables sub-node unit-name"
> >  |- script = "
> >  |- compatible = "vendor
>
>
>
>
>
> This is a question for U-Boot (and barebox).
>
>
>
>
>    images {
>           base {
>                 ...
>           };
>
>           addon1 {
>                 ...
>           };
>
>           addon2 {
>                 ...
>           };
>     };
>
>     configurations {
>           ...
>           fdt = "base", "addon1", "addon2";
>     };
>
>
>
>
> Is U-Boot's "bootm" command able to dynamically construct
> the full DTB from "base" + "addon1" + "addon2"
> and pass to the kernel?
>
>
>
> When I used overlay from U-Boot command line last time,
> I typed complicated commands, following this manual:
> https://docs.u-boot.org/en/latest/usage/fdt_overlays.html
>
>

So far this is not possible with bootm, no. But if we can add
extensions to the FIT spec, then it should be possible to implement
this.

Is it (or will it be) possible to get Linux to build the DT + overlay
combinations?

>
>
> One more question to confirm if I can use this
> for my practical use-cases.
>
> Is U-Boot able to handle FIT (includes kernel + DTs)
> and a separate initrd?
>
>   # bootm  <fit-address>:<conf-name>  <ramdisk-address>
>
>
> Presumably, it would be difficult to inject initramdisk
> into image.fit later, so I am hoping bootm would work like that,
> but I did not delve into U-Boot code.
>
>

The ramdisk is handled by the FIT configuration. I suppose it would be
possible to add a way to bypass the logic in select_ramdisk(), but I
wonder what is the use case for this?

>
> If it works, is it possible to verify the integrity of initrd?
> The kernel and DTs inside FIT will be verified, but not sure
> if it is possible for ramdisk.

I do have thoughts about a possible new FIT feature to allow external
files, which could perhaps include an initrd.

Regards,
Simon


From zajec5 at gmail.com  Thu Dec 28 23:57:38 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Fri, 29 Dec 2023 08:57:38 +0100
Subject: [PATCH 1/2] arm64: dts: mediatek: mt7986: reorder properties
Message-ID: <20231229075739.8328-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Use order described as preferred in DTS Coding Style. Mostly just move
"compatible", "reg" and "ranges" properties. In two nodes also move
vendor-prefixed props down.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 67 ++++++++++++-----------
 1 file changed, 34 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
index fc751e049953..23feeff881de 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
@@ -27,34 +27,34 @@ cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		cpu0: cpu at 0 {
-			device_type = "cpu";
 			compatible = "arm,cortex-a53";
-			enable-method = "psci";
 			reg = <0x0>;
+			device_type = "cpu";
+			enable-method = "psci";
 			#cooling-cells = <2>;
 		};
 
 		cpu1: cpu at 1 {
-			device_type = "cpu";
 			compatible = "arm,cortex-a53";
-			enable-method = "psci";
 			reg = <0x1>;
+			device_type = "cpu";
+			enable-method = "psci";
 			#cooling-cells = <2>;
 		};
 
 		cpu2: cpu at 2 {
-			device_type = "cpu";
 			compatible = "arm,cortex-a53";
-			enable-method = "psci";
 			reg = <0x2>;
+			device_type = "cpu";
+			enable-method = "psci";
 			#cooling-cells = <2>;
 		};
 
 		cpu3: cpu at 3 {
-			device_type = "cpu";
-			enable-method = "psci";
 			compatible = "arm,cortex-a53";
 			reg = <0x3>;
+			device_type = "cpu";
+			enable-method = "psci";
 			#cooling-cells = <2>;
 		};
 	};
@@ -131,22 +131,22 @@ timer {
 	};
 
 	soc {
-		#address-cells = <2>;
-		#size-cells = <2>;
 		compatible = "simple-bus";
 		ranges;
+		#address-cells = <2>;
+		#size-cells = <2>;
 
 		gic: interrupt-controller at c000000 {
 			compatible = "arm,gic-v3";
-			#interrupt-cells = <3>;
-			interrupt-parent = <&gic>;
-			interrupt-controller;
 			reg = <0 0x0c000000 0 0x10000>,  /* GICD */
 			      <0 0x0c080000 0 0x80000>,  /* GICR */
 			      <0 0x0c400000 0 0x2000>,   /* GICC */
 			      <0 0x0c410000 0 0x1000>,   /* GICH */
 			      <0 0x0c420000 0 0x2000>;   /* GICV */
+			interrupt-parent = <&gic>;
 			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
 		};
 
 		infracfg: infracfg at 10001000 {
@@ -311,9 +311,9 @@ i2c0: i2c at 11008000 {
 
 		spi0: spi at 1100a000 {
 			compatible = "mediatek,mt7986-spi-ipm", "mediatek,spi-ipm";
+			reg = <0 0x1100a000 0 0x100>;
 			#address-cells = <1>;
 			#size-cells = <0>;
-			reg = <0 0x1100a000 0 0x100>;
 			interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&topckgen CLK_TOP_MPLL_D2>,
 				 <&topckgen CLK_TOP_SPI_SEL>,
@@ -325,9 +325,9 @@ spi0: spi at 1100a000 {
 
 		spi1: spi at 1100b000 {
 			compatible = "mediatek,mt7986-spi-ipm", "mediatek,spi-ipm";
+			reg = <0 0x1100b000 0 0x100>;
 			#address-cells = <1>;
 			#size-cells = <0>;
-			reg = <0 0x1100b000 0 0x100>;
 			interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&topckgen CLK_TOP_MPLL_D2>,
 				 <&topckgen CLK_TOP_SPIM_MST_SEL>,
@@ -389,7 +389,6 @@ mmc0: mmc at 11230000 {
 		};
 
 		thermal: thermal at 1100c800 {
-			#thermal-sensor-cells = <1>;
 			compatible = "mediatek,mt7986-thermal";
 			reg = <0 0x1100c800 0 0x800>;
 			interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
@@ -397,30 +396,30 @@ thermal: thermal at 1100c800 {
 				 <&infracfg CLK_INFRA_ADC_26M_CK>,
 				 <&infracfg CLK_INFRA_ADC_FRC_CK>;
 			clock-names = "therm", "auxadc", "adc_32k";
-			mediatek,auxadc = <&auxadc>;
-			mediatek,apmixedsys = <&apmixedsys>;
 			nvmem-cells = <&thermal_calibration>;
 			nvmem-cell-names = "calibration-data";
+			#thermal-sensor-cells = <1>;
+			mediatek,auxadc = <&auxadc>;
+			mediatek,apmixedsys = <&apmixedsys>;
 		};
 
 		pcie: pcie at 11280000 {
 			compatible = "mediatek,mt7986-pcie",
 				     "mediatek,mt8192-pcie";
+			reg = <0x00 0x11280000 0x00 0x4000>;
+			reg-names = "pcie-mac";
+			ranges = <0x82000000 0x00 0x20000000 0x00
+				  0x20000000 0x00 0x10000000>;
 			device_type = "pci";
 			#address-cells = <3>;
 			#size-cells = <2>;
-			reg = <0x00 0x11280000 0x00 0x4000>;
-			reg-names = "pcie-mac";
 			interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
 			bus-range = <0x00 0xff>;
-			ranges = <0x82000000 0x00 0x20000000 0x00
-				  0x20000000 0x00 0x10000000>;
 			clocks = <&infracfg CLK_INFRA_IPCIE_PIPE_CK>,
 				 <&infracfg CLK_INFRA_IPCIE_CK>,
 				 <&infracfg CLK_INFRA_IPCIER_CK>,
 				 <&infracfg CLK_INFRA_IPCIEB_CK>;
 			clock-names = "pl_250m", "tl_26m", "peri_26m", "top_133m";
-			status = "disabled";
 
 			phys = <&pcie_port PHY_TYPE_PCIE>;
 			phy-names = "pcie-phy";
@@ -431,6 +430,8 @@ pcie: pcie at 11280000 {
 					<0 0 0 2 &pcie_intc 1>,
 					<0 0 0 3 &pcie_intc 2>,
 					<0 0 0 4 &pcie_intc 3>;
+			status = "disabled";
+
 			pcie_intc: interrupt-controller {
 				#address-cells = <0>;
 				#interrupt-cells = <1>;
@@ -441,9 +442,9 @@ pcie_intc: interrupt-controller {
 		pcie_phy: t-phy {
 			compatible = "mediatek,mt7986-tphy",
 				     "mediatek,generic-tphy-v2";
+			ranges;
 			#address-cells = <2>;
 			#size-cells = <2>;
-			ranges;
 			status = "disabled";
 
 			pcie_port: pcie-phy at 11c00000 {
@@ -468,9 +469,9 @@ thermal_calibration: calib at 274 {
 		usb_phy: t-phy at 11e10000 {
 			compatible = "mediatek,mt7986-tphy",
 				     "mediatek,generic-tphy-v2";
+			ranges = <0 0 0x11e10000 0x1700>;
 			#address-cells = <1>;
 			#size-cells = <1>;
-			ranges = <0 0 0x11e10000 0x1700>;
 			status = "disabled";
 
 			u2port0: usb-phy at 0 {
@@ -498,11 +499,11 @@ u2port1: usb-phy at 1000 {
 		};
 
 		ethsys: syscon at 15000000 {
-			 #address-cells = <1>;
-			 #size-cells = <1>;
 			 compatible = "mediatek,mt7986-ethsys",
 				      "syscon";
 			 reg = <0 0x15000000 0 0x1000>;
+			 #address-cells = <1>;
+			 #size-cells = <1>;
 			 #clock-cells = <1>;
 			 #reset-cells = <1>;
 		};
@@ -579,26 +580,26 @@ eth: ethernet at 15100000 {
 					  <&topckgen CLK_TOP_SGM_325M_SEL>;
 			assigned-clock-parents = <&apmixedsys CLK_APMIXED_NET2PLL>,
 						 <&apmixedsys CLK_APMIXED_SGMPLL>;
+			#reset-cells = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
 			mediatek,ethsys = <&ethsys>;
 			mediatek,sgmiisys = <&sgmiisys0>, <&sgmiisys1>;
 			mediatek,wed-pcie = <&wed_pcie>;
 			mediatek,wed = <&wed0>, <&wed1>;
-			#reset-cells = <1>;
-			#address-cells = <1>;
-			#size-cells = <0>;
 			status = "disabled";
 		};
 
 		wifi: wifi at 18000000 {
 			compatible = "mediatek,mt7986-wmac";
+			reg = <0 0x18000000 0 0x1000000>,
+			      <0 0x10003000 0 0x1000>,
+			      <0 0x11d10000 0 0x1000>;
 			resets = <&watchdog MT7986_TOPRGU_CONSYS_SW_RST>;
 			reset-names = "consys";
 			clocks = <&topckgen CLK_TOP_CONN_MCUSYS_SEL>,
 				 <&topckgen CLK_TOP_AP2CNN_HOST_SEL>;
 			clock-names = "mcu", "ap2conn";
-			reg = <0 0x18000000 0 0x1000000>,
-			      <0 0x10003000 0 0x1000>,
-			      <0 0x11d10000 0 0x1000>;
 			interrupts = <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.35.3



From zajec5 at gmail.com  Thu Dec 28 23:57:39 2023
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Fri, 29 Dec 2023 08:57:39 +0100
Subject: [PATCH 2/2] arm64: dts: mediatek: mt7986: reorder nodes
In-Reply-To: <20231229075739.8328-1-zajec5@gmail.com>
References: <20231229075739.8328-1-zajec5@gmail.com>
Message-ID: <20231229075739.8328-2-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

Use order described as preferred in DTS Coding Style:
1. Sort bus nodes by unit address
2. Use alpha-numerical order for the rest

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 118 +++++++++++-----------
 1 file changed, 59 insertions(+), 59 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
index 23feeff881de..a0f28b9ada18 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
@@ -16,13 +16,6 @@ / {
 	#address-cells = <2>;
 	#size-cells = <2>;
 
-	clk40m: oscillator-40m {
-		compatible = "fixed-clock";
-		clock-frequency = <40000000>;
-		#clock-cells = <0>;
-		clock-output-names = "clkxtal";
-	};
-
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -59,6 +52,13 @@ cpu3: cpu at 3 {
 		};
 	};
 
+	clk40m: oscillator-40m {
+		compatible = "fixed-clock";
+		clock-frequency = <40000000>;
+		#clock-cells = <0>;
+		clock-output-names = "clkxtal";
+	};
+
 	psci {
 		compatible = "arm,psci-0.2";
 		method = "smc";
@@ -121,15 +121,6 @@ wo_boot: wo-boot at 15194000 {
 
 	};
 
-	timer {
-		compatible = "arm,armv8-timer";
-		interrupt-parent = <&gic>;
-		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
-			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
-			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
-			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
-	};
-
 	soc {
 		compatible = "simple-bus";
 		ranges;
@@ -202,6 +193,20 @@ pio: pinctrl at 1001f000 {
 			#interrupt-cells = <2>;
 		};
 
+		pwm: pwm at 10048000 {
+			compatible = "mediatek,mt7986-pwm";
+			reg = <0 0x10048000 0 0x1000>;
+			#clock-cells = <1>;
+			#pwm-cells = <2>;
+			interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&topckgen CLK_TOP_PWM_SEL>,
+				 <&infracfg CLK_INFRA_PWM_STA>,
+				 <&infracfg CLK_INFRA_PWM1_CK>,
+				 <&infracfg CLK_INFRA_PWM2_CK>;
+			clock-names = "top", "main", "pwm1", "pwm2";
+			status = "disabled";
+		};
+
 		sgmiisys0: syscon at 10060000 {
 			compatible = "mediatek,mt7986-sgmiisys_0",
 				     "syscon";
@@ -240,20 +245,6 @@ crypto: crypto at 10320000 {
 			status = "disabled";
 		};
 
-		pwm: pwm at 10048000 {
-			compatible = "mediatek,mt7986-pwm";
-			reg = <0 0x10048000 0 0x1000>;
-			#clock-cells = <1>;
-			#pwm-cells = <2>;
-			interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&topckgen CLK_TOP_PWM_SEL>,
-				 <&infracfg CLK_INFRA_PWM_STA>,
-				 <&infracfg CLK_INFRA_PWM1_CK>,
-				 <&infracfg CLK_INFRA_PWM2_CK>;
-			clock-names = "top", "main", "pwm1", "pwm2";
-			status = "disabled";
-		};
-
 		uart0: serial at 11002000 {
 			compatible = "mediatek,mt7986-uart",
 				     "mediatek,mt6577-uart";
@@ -337,6 +328,21 @@ spi1: spi at 1100b000 {
 			status = "disabled";
 		};
 
+		thermal: thermal at 1100c800 {
+			compatible = "mediatek,mt7986-thermal";
+			reg = <0 0x1100c800 0 0x800>;
+			interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&infracfg CLK_INFRA_THERM_CK>,
+				 <&infracfg CLK_INFRA_ADC_26M_CK>,
+				 <&infracfg CLK_INFRA_ADC_FRC_CK>;
+			clock-names = "therm", "auxadc", "adc_32k";
+			nvmem-cells = <&thermal_calibration>;
+			nvmem-cell-names = "calibration-data";
+			#thermal-sensor-cells = <1>;
+			mediatek,auxadc = <&auxadc>;
+			mediatek,apmixedsys = <&apmixedsys>;
+		};
+
 		auxadc: adc at 1100d000 {
 			compatible = "mediatek,mt7986-auxadc";
 			reg = <0 0x1100d000 0 0x1000>;
@@ -388,21 +394,6 @@ mmc0: mmc at 11230000 {
 			status = "disabled";
 		};
 
-		thermal: thermal at 1100c800 {
-			compatible = "mediatek,mt7986-thermal";
-			reg = <0 0x1100c800 0 0x800>;
-			interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&infracfg CLK_INFRA_THERM_CK>,
-				 <&infracfg CLK_INFRA_ADC_26M_CK>,
-				 <&infracfg CLK_INFRA_ADC_FRC_CK>;
-			clock-names = "therm", "auxadc", "adc_32k";
-			nvmem-cells = <&thermal_calibration>;
-			nvmem-cell-names = "calibration-data";
-			#thermal-sensor-cells = <1>;
-			mediatek,auxadc = <&auxadc>;
-			mediatek,apmixedsys = <&apmixedsys>;
-		};
-
 		pcie: pcie at 11280000 {
 			compatible = "mediatek,mt7986-pcie",
 				     "mediatek,mt8192-pcie";
@@ -534,20 +525,6 @@ wed1: wed at 15011000 {
 			mediatek,wo-ccif = <&wo_ccif1>;
 		};
 
-		wo_ccif0: syscon at 151a5000 {
-			compatible = "mediatek,mt7986-wo-ccif", "syscon";
-			reg = <0 0x151a5000 0 0x1000>;
-			interrupt-parent = <&gic>;
-			interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>;
-		};
-
-		wo_ccif1: syscon at 151ad000 {
-			compatible = "mediatek,mt7986-wo-ccif", "syscon";
-			reg = <0 0x151ad000 0 0x1000>;
-			interrupt-parent = <&gic>;
-			interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
-		};
-
 		eth: ethernet at 15100000 {
 			compatible = "mediatek,mt7986-eth";
 			reg = <0 0x15100000 0 0x80000>;
@@ -590,6 +567,20 @@ eth: ethernet at 15100000 {
 			status = "disabled";
 		};
 
+		wo_ccif0: syscon at 151a5000 {
+			compatible = "mediatek,mt7986-wo-ccif", "syscon";
+			reg = <0 0x151a5000 0 0x1000>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		wo_ccif1: syscon at 151ad000 {
+			compatible = "mediatek,mt7986-wo-ccif", "syscon";
+			reg = <0 0x151ad000 0 0x1000>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
 		wifi: wifi at 18000000 {
 			compatible = "mediatek,mt7986-wmac";
 			reg = <0 0x18000000 0 0x1000000>,
@@ -647,4 +638,13 @@ cpu_trip_active_low: active-low {
 			};
 		};
 	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+	};
 };
-- 
2.35.3



From tudor.ambarus at linaro.org  Fri Dec 29 00:04:21 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Fri, 29 Dec 2023 08:04:21 +0000
Subject: [PATCH v2 11/12] arm64: dts: exynos: gs101: define USI8 with I2C
 configuration
In-Reply-To: <a40b5d0dc3e151fede14aa00bcb853d1eeb8824b.camel@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
 <20231228125805.661725-12-tudor.ambarus@linaro.org>
 <a40b5d0dc3e151fede14aa00bcb853d1eeb8824b.camel@linaro.org>
Message-ID: <387303b4-d912-480c-a50c-9f9efa386ef3@linaro.org>



On 12/28/23 14:04, Andr? Draszik wrote:
> Hi Tudor,

Hi!

> 
> On Thu, 2023-12-28 at 12:58 +0000, Tudor Ambarus wrote:
>> [...]
>>
>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> index 0e5b1b490b0b..c6ae33016992 100644
>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> @@ -354,6 +354,35 @@ pinctrl_peric0: pinctrl at 10840000 {
>> ?			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
>> ?		};
>> ?
>> +		usi8: usi at 109700c0 {
>> +			compatible = "google,gs101-usi",
>> +				???? "samsung,exynos850-usi";
>> +			reg = <0x109700c0 0x20>;
>> +			ranges;
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>,
>> +				 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
>> +			clock-names = "pclk", "ipclk";
> 
> Given the clock-names, shouldn't the clock indices be the other way around? Also see below.

You're right, they should have been the other way around! Didn't make
any difference at testing because the usi driver uses
clk_bulk_prepare_enable(), what matters is the order of clocks in the
i2c node, and those are fine.

> 
>> +			samsung,sysreg = <&sysreg_peric0 0x101c>;
>> +			status = "disabled";
>> +
>> +			hsi2c_8: i2c at 10970000 {
>> +				compatible = "google,gs101-hsi2c",
>> +					???? "samsung,exynosautov9-hsi2c";
>> +				reg = <0x10970000 0xc0>;
>> +				interrupts = <GIC_SPI 642 IRQ_TYPE_LEVEL_HIGH 0>;
>> +				#address-cells = <1>;
>> +				#size-cells = <0>;
>> +				pinctrl-names = "default";
>> +				pinctrl-0 = <&hsi2c8_bus>;
>> +				clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>,
>> +					 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
>> +				clock-names = "hsi2c", "hsi2c_pclk";
> 
> Here, pclk == CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK (which is correct, I believe), whereas
> above pclk == CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7
> 

Indeed, I'll reverse the order for the USI clocks and do some more
testing. Thanks!
ta


From tudor.ambarus at linaro.org  Fri Dec 29 00:26:06 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Fri, 29 Dec 2023 08:26:06 +0000
Subject: [PATCH v2 10/12] arm64: dts: exynos: gs101: update USI UART to
 use peric0 clocks
In-Reply-To: <5a961a6992d7661e6c7589496438cad7b68d4f5a.camel@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
 <20231228125805.661725-11-tudor.ambarus@linaro.org>
 <5a961a6992d7661e6c7589496438cad7b68d4f5a.camel@linaro.org>
Message-ID: <0c288847-b495-44e4-a5c5-5e7a4e83a444@linaro.org>



On 12/28/23 14:22, Andr? Draszik wrote:
> Hi Tudor,

Hi, Andre'!
> 
> On Thu, 2023-12-28 at 12:58 +0000, Tudor Ambarus wrote:
>>
>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> [...]
>> @@ -380,7 +373,8 @@ serial_0: serial at 10a00000 {
>> ?				reg = <0x10a00000 0xc0>;
>> ?				interrupts = <GIC_SPI 634
>> ?					????? IRQ_TYPE_LEVEL_HIGH 0>;
>> -				clocks = <&dummy_clk 0>, <&dummy_clk 0>;
>> +				clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
>> +					 <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0>;
> 
> I suspect these two should be the other way around, given the clock-names below?

These ones look sane to me. The clocks on the USI parent as well. USI
datasheet says that IPCLK is the protocol operating clock and PCLK the
APB clock. In the serial driver clk_uart_baud0 (IPCLK) is used as the
operating clock, all fine here.

Tell if you still think otherwise. Thanks!
ta

> 
>> ?				clock-names = "uart", "clk_uart_baud0";
>> ?				samsung,uart-fifosize = <256>;
>> ?				status = "disabled";
> 
> Cheers,
> A.


From bryan.odonoghue at linaro.org  Fri Dec 29 02:50:47 2023
From: bryan.odonoghue at linaro.org (Bryan O'Donoghue)
Date: Fri, 29 Dec 2023 10:50:47 +0000
Subject: [PATCH 5/5] media: venus: Convert to
 dev_pm_domain_attach|detach_list() for vcodec
In-Reply-To: <20231228114157.104822-6-ulf.hansson@linaro.org>
References: <20231228114157.104822-1-ulf.hansson@linaro.org>
 <20231228114157.104822-6-ulf.hansson@linaro.org>
Message-ID: <fc16eb72-fbef-4059-a871-ef229e1f121a@linaro.org>

On 28/12/2023 11:41, Ulf Hansson wrote:
> Let's avoid some of the boilerplate code to manage the vcodec PM domains,
> by converting into using dev_pm_domain_attach|detach_list().
> 
> Cc: Mauro Carvalho Chehab <mchehab at kernel.org>
> Cc: Stanimir Varbanov <stanimir.k.varbanov at gmail.com>
> Cc: Vikash Garodia <quic_vgarodia at quicinc.com>
> Cc: "Bryan O'Donoghue" <bryan.odonoghue at linaro.org>
> Cc: Bjorn Andersson <andersson at kernel.org>
> Cc: Konrad Dybcio <konrad.dybcio at linaro.org>
> Cc: <linux-media at vger.kernel.org>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>

On top of 39676dfe52331 - (tag: next-20231222, linux-next/master) Add 
linux-next specific files for 20231222 (7 days ago)

Tested-by: Bryan O'Donoghue <bryan.odonoghue at linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue at linaro.org>

---
bod


From sigmaris at gmail.com  Fri Dec 29 03:01:09 2023
From: sigmaris at gmail.com (Hugh Cole-Baker)
Date: Fri, 29 Dec 2023 11:01:09 +0000
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
In-Reply-To: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
References: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
Message-ID: <CAAXNxMT3f68-ptM7Crhrfmn7iwTyJc9pwz4Beob+5beVODaSHQ@mail.gmail.com>

On Thu, 28 Dec 2023 at 13:16, Jianfeng Liu <liujianfeng1994 at gmail.com> wrote:
>
> This is the v2 version of this series adding hantro g1 video decoder
> support for rk3588.
>
> Changes in v2:
> - Fix alphabetical order in patch1 and patch3
> - Sort device tree node by bus-address
> - Drop rk3588_vpu_variant fron v1 because that is exactly the same as rk3568_vpu_variant
> - Link to v1: https://lore.kernel.org/all/20231227173911.3295410-1-liujianfeng1994 at gmail.com
>
> Jianfeng Liu (3):
>   media: verisilicon: Add support for Hantro G1 on RK3588
>   arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588
>   dt-bindings: media: rockchip-vpu: Add RK3588 compatible
>
>  .../bindings/media/rockchip-vpu.yaml          |  1 +
>  arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 20 +++++++++++++++++++
>  .../media/platform/verisilicon/hantro_drv.c   |  1 +
>  3 files changed, 22 insertions(+)
>
> --
> 2.34.1

Tested H.264 and VP8 decode with Fluster on NanoPC T6;

H.264 JVT-AVC_V1 test suite:
  Ran 129/135 tests successfully.
  (matches FFmpeg-H.264 software decoder)
H.264 JVT-FR-EXT test suite:
  Ran 44/69 tests successfully
  (some failures caused by lack of support for Hi10P and 4:2:2)
VP8-TEST-VECTORS test suite:
  Ran 59/61 tests successfully
  (matches FFmpeg-VP8 software decoder)
Full results at:
https://gist.github.com/sigmaris/d3d8586bfced5ddc021aa9dab94d4ab8

Tested-by: Hugh Cole-Baker <sigmaris at gmail.com>


From sigmaris at gmail.com  Fri Dec 29 03:02:08 2023
From: sigmaris at gmail.com (Hugh Cole-Baker)
Date: Fri, 29 Dec 2023 11:02:08 +0000
Subject: [PATCH v2 2/3] arm64: dts: rockchip: Add Hantro G1 VPU support
 for RK3588
In-Reply-To: <20231228131617.3411561-3-liujianfeng1994@gmail.com>
References: <20231228131617.3411561-1-liujianfeng1994@gmail.com> <20231228131617.3411561-3-liujianfeng1994@gmail.com>
Message-ID: <CAAXNxMRkpM+dSV3azDFgm07ygJrXyS=Htz_h8Z_WMmeG0YZ+ig@mail.gmail.com>

On Thu, 28 Dec 2023 at 13:17, Jianfeng Liu <liujianfeng1994 at gmail.com> wrote:
>
> This patch enables Hantro G1 video decoder in RK3588's
> devicetree.
>
> Tested with FFmpeg v4l2_request code taken from [1]
> with MPEG2, H.264 and VP8 samples.
>
> [1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch
>
> Signed-off-by: Jianfeng Liu <liujianfeng1994 at gmail.com>
> ---
>  arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> index 5fb0baf8a..5da668184 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> @@ -640,6 +640,26 @@ i2c0: i2c at fd880000 {
>                 status = "disabled";
>         };
>
> +       vpu: video-codec at fdb50400 {

The node name should be video-codec at fdb50000 to match the reg address.

> +               compatible = "rockchip,rk3588-vpu";
> +               reg = <0x0 0xfdb50000 0x0 0x800>;
> +               interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH 0>;
> +               clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
> +               clock-names = "aclk", "hclk";
> +               iommus = <&vdpu_mmu>;
> +               power-domains = <&power RK3588_PD_VDPU>;
> +       };
> +
> +       vdpu_mmu: iommu at fdb50800 {
> +               compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
> +               reg = <0x0 0xfdb50800 0x0 0x40>;
> +               interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH 0>;
> +               clock-names = "aclk", "iface";
> +               clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
> +               power-domains = <&power RK3588_PD_VDPU>;
> +               #iommu-cells = <0>;
> +       };
> +
>         vop: vop at fdd90000 {
>                 compatible = "rockchip,rk3588-vop";
>                 reg = <0x0 0xfdd90000 0x0 0x4200>, <0x0 0xfdd95000 0x0 0x1000>;
> --
> 2.34.1


From jagan at amarulasolutions.com  Fri Dec 29 03:42:39 2023
From: jagan at amarulasolutions.com (Jagan Teki)
Date: Fri, 29 Dec 2023 17:12:39 +0530
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <20231226153055.4yihsmu6kiak6hkf@skbuf>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf> <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
 <20231226153055.4yihsmu6kiak6hkf@skbuf>
Message-ID: <CAMty3ZDnAFR9a1BM89mx3bmrQzGC7nvazt42_v4JF_QpwPkS4w@mail.gmail.com>

On Tue, Dec 26, 2023 at 9:00?PM Vladimir Oltean <olteanv at gmail.com> wrote:
>
> On Tue, Dec 26, 2023 at 01:11:08PM +0530, Jagan Teki wrote:
> > &fec {
> >           pinctrl-names = "default";
> >           pinctrl-0 = <&pinctrl_enet>;
> >           phy-mode = "mii";
> >           status = "okay";
>
> tl;dr: I think what is missing is:
>
>                 fixed-link {
>                         speed = <100>;
>                         full-duplex;
>                 };

Okay. I added this and now the warning seems gone. Please check the below log.

>
> >
> >           mdio {
> >              #address-cells = <1>;
> >              #size-cells = <0>;
> >
> >             ethphy0: ethernet-phy at 0 {
> >                       compatible = "ethernet-phy-ieee802.3-c22";
> >                       reg = <0>;
> >             };
> >
> >             ethphy1: ethernet-phy at 1 {
> >                     compatible = "ethernet-phy-ieee802.3-c22";
> >                     reg = <1>;
> >            };
> >         };
> > };
> >
> > root at imx6solo:~# ip link set dev eth0 down
> > root at imx6solo:~# ip link set dev ethphy0 down
> > root at imx6solo:~# ip link set dev ethphy1 down
> > root at imx6solo:~# ip link set dev ethphy0 address 00:11:22:33:44:55
> > root at imx6solo:~# ip link set dev ethphy1 address 00:11:22:33:44:66
> > root at imx6solo:~# ip addr add dev ethphy0 192.168.1.1/16
> > root at imx6solo:~# ip addr add dev ethphy1 192.168.1.5/16
> > root at imx6solo:~# ip link set dev eth0 up
> > [  617.126753] dp83848_config_init: ret 0
> > [  617.130831] TI DP83849I 10/100 Mbps PHY 2188000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
> > root at imx6solo:~# [  619.207519] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> > [  619.215698] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> eth0 is the FEC port, right?

Yes.

With fec0 fixed-link and 3 different switch port configurations, the
result of the link seems to be up but the ping not working and even
the packets are not transmitted via eth0.

DT Combinations:

- Port0 is ethphy0, Port1 is ethphy1, Port2 is disabled, Port3 is
disabled, Port4 is FEC
- Port0 is disabled, Port1 is ethphy0, Port2 is ethphy1, Port3 is
disabled, Port4 is FEC
- Port0 is disabled, Port1 is disabled, Port2 is ethphy0, Port3 is
ethphy1, Port4 as FEC


DT: (with Port0 is ethphy0, Port1 is ethphy1, Port2 is disabled, Port3
is disabled, Port4 is FEC)

&ecspi2 {
    cs-gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_ecspi2>;
    status = "okay";

    switch at 0 {
        compatible = "nxp,sja1105q";
        reg = <0>;
        spi-max-frequency = <4000000>;
        spi-rx-delay-us = <1>;
        spi-tx-delay-us = <1>;
        spi-cpha;

       clocks = <&clk25m>;

       pinctrl-0 = <&pinctrl_sja1105_rst>;
       pinctrl-names = "default";
       reset-gpios = <&gpio6 5 GPIO_ACTIVE_LOW>;

       ports {
              #address-cells = <1>;
              #size-cells = <0>;

             port at 0 {
                  reg = <0>;
                  label = "ethphy0";
                  phy-handle = <&ethphy0>;
                  phy-mode = "mii";
            };

            port at 1 {
                 reg = <1>;
                 label = "ethphy1";
                 phy-handle = <&ethphy1>;
                 phy-mode = "mii";
           };

           port at 2 {
                reg = <2>;
                status = "disabled";
           };

            port at 3 {
                 reg = <3>;
                 status = "disabled";
           };

           port at 4 {
                reg = <4>;
                label = "cpu";
                ethernet = <&fec>;
                phy-mode = "mii";
                rx-internal-delay-ps = <2000>;
                tx-internal-delay-ps = <2000>;

               fixed-link {
                   speed = <100>;
                   full-duplex;
               };
            };
          };
     };
};

&fec {
       pinctrl-names = "default";
       pinctrl-0 = <&pinctrl_enet>;
       phy-mode = "mii";
       status = "okay";

       fixed-link {
          speed = <100>;
          full-duplex;
       };

       mdio {
            #address-cells = <1>;
            #size-cells = <0>;

            ethphy0: ethernet-phy at 0 {
                    compatible = "ethernet-phy-ieee802.3-c22";
                    reg = <0>;
            };

           ethphy1: ethernet-phy at 1 {
               compatible = "ethernet-phy-ieee802.3-c22";
                reg = <1>;
            };
    };
};

Full dmesg:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 6.1.58 (oe-user at oe-host)
(arm-fslc-linux-gnueabi-gcc (GCC) 11.4.0, GNU ld (GNU Binutils)
2.38.20220708) #1 SMP Sun Oct 15 16:32:41 UTC 2023
[    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[    0.000000] OF: fdt: Machine model: LTTS i.MX6DL/SOLO Processor
Board (P0-PHY0, P1-PHY1)
[    0.000000] Memory policy: Data cache writeback
[    0.000000] cma: Reserved 64 MiB at 0x4c000000
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000010000000-0x000000003fffffff]
[    0.000000]   HighMem  [mem 0x0000000040000000-0x000000004fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000010000000-0x000000004fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000004fffffff]
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] percpu: Embedded 17 pages/cpu s38452 r8192 d22988 u69632
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 260608
[    0.000000] Kernel command line: console=ttymxc1,115200
root=/dev/mmcblk0p2 rootwait rw
mtdparts=gpmi-nand:2m(spl),2m(uboot),1m(env),16m(kernel),1m(dtb),-(rootfs)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7,
524288 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 942324K/1048576K available (15360K kernel code,
2198K rwdata, 5632K rodata, 1024K init, 6674K bss, 40716K reserved,
65536K cma-reserved, 196608K highmem)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] trace event string verifier disabled
[    0.000000] Running RCU self tests
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU event tracing is enabled.
[    0.000000] rcu:     RCU lockdep checking is enabled.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay
is 10 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] L2C-310 erratum 769419 enabled
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[    0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 cache controller enabled, 16 ways, 512 kB
[    0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x76450001
[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[    0.000000] Switching to timer-based delay loop, resolution 333ns
[    0.000001] sched_clock: 32 bits at 3000kHz, resolution 333ns,
wraps every 715827882841ns
[    0.000026] clocksource: mxc_timer1: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 637086815595 ns
[    0.002024] Console: colour dummy device 80x30
[    0.002103] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[    0.002115] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.002127] ... MAX_LOCK_DEPTH:          48
[    0.002140] ... MAX_LOCKDEP_KEYS:        8192
[    0.002151] ... CLASSHASH_SIZE:          4096
[    0.002163] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.002174] ... MAX_LOCKDEP_CHAINS:      65536
[    0.002186] ... CHAINHASH_SIZE:          32768
[    0.002197]  memory used by lock dependency info: 4061 kB
[    0.002209]  memory used for stack traces: 2112 kB
[    0.002220]  per task-struct memory footprint: 1536 bytes
[    0.002337] Calibrating delay loop (skipped), value calculated
using timer frequency.. 6.00 BogoMIPS (lpj=30000)
[    0.002370] CPU: Testing write buffer coherency: ok
[    0.002550] CPU0: Spectre v2: using BPIALL workaround
[    0.002570] pid_max: default: 32768 minimum: 301
[    0.003241] Mount-cache hash table entries: 2048 (order: 1, 8192
bytes, linear)
[    0.003279] Mountpoint-cache hash table entries: 2048 (order: 1,
8192 bytes, linear)
[    0.008782] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.012642] cblist_init_generic: Setting adjustable number of
callback queues.
[    0.012663] cblist_init_generic: Setting shift to 1 and lim to 1.
[    0.013078] Running RCU-tasks wait API self tests
[    0.013428] Setting up static identity map for 0x10100000 - 0x10100078
[    0.014115] Callback from call_rcu_tasks_trace() invoked.
[    0.014401] rcu: Hierarchical SRCU implementation.
[    0.014416] rcu:     Max phase no-delay instances is 1000.
[    0.017147] smp: Bringing up secondary CPUs ...
[    0.020861] smp: Brought up 1 node, 1 CPU
[    0.020887] SMP: Total of 1 processors activated (6.00 BogoMIPS).
[    0.020906] CPU: All CPU(s) started in SVC mode.
[    0.023936] devtmpfs: initialized
[    0.064038] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
[    0.066614] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.066685] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[    0.069638] pinctrl core: initialized pinctrl subsystem
[    0.076431] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.103057] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.108831] thermal_sys: Registered thermal governor 'step_wise'
[    0.109233] cpuidle: using governor menu
[    0.109642] CPU identified as i.MX6DL, silicon rev 1.4
[    0.129331] platform soc: Fixed dependency cycle(s) with
/soc/bus at 2000000/gpc at 20dc000
[    0.196131] platform 2400000.ipu: Fixed dependency cycle(s) with
/ldb/lvds-channel at 0/port at 1/endpoint
[    0.196257] platform 2400000.ipu: Fixed dependency cycle(s) with
/ldb/lvds-channel at 0/port at 0/endpoint
[    0.196358] platform 2400000.ipu: Fixed dependency cycle(s) with
/soc/bus at 2000000/iomuxc-gpr at 20e0000/ipu1_csi1_mux/port at 5/endpoint
[    0.196495] platform 2400000.ipu: Fixed dependency cycle(s) with
/soc/bus at 2000000/iomuxc-gpr at 20e0000/ipu1_csi0_mux/port at 5/endpoint
[    0.201135] platform panel: Fixed dependency cycle(s) with
/ldb/lvds-channel at 0/port at 4/endpoint
[    0.208560] No ATAGs?
[    0.208881] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[    0.208926] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.214921] imx6dl-pinctrl 20e0000.pinctrl: initialized IMX pinctrl driver
[    0.272738] kprobes: kprobe jump-optimization is enabled. All
kprobes are optimized if possible.
[    1.498973] SCSI subsystem initialized
[    1.501106] usbcore: registered new interface driver usbfs
[    1.501396] usbcore: registered new interface driver hub
[    1.501565] usbcore: registered new device driver usb
[    1.502033] usb_phy_generic usbphynop1: supply vcc not found, using
dummy regulator
[    1.502911] usb_phy_generic usbphynop1: dummy supplies not allowed
for exclusive requests
[    1.503404] usb_phy_generic usbphynop2: supply vcc not found, using
dummy regulator
[    1.504037] usb_phy_generic usbphynop2: dummy supplies not allowed
for exclusive requests
[    1.510235] i2c i2c-0: IMX I2C adapter registered
[    1.514947] i2c i2c-1: IMX I2C adapter registered
[    1.518067] i2c i2c-2: IMX I2C adapter registered
[    1.518853] mc: Linux media interface: v0.10
[    1.519141] videodev: Linux video capture interface: v2.00
[    1.522785] pps_core: LinuxPPS API ver. 1 registered
[    1.522807] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti <giometti at linux.it>
[    1.522874] PTP clock support registered
[    1.525697] Advanced Linux Sound Architecture Driver Initialized.
[    1.529830] Bluetooth: Core ver 2.22
[    1.529992] NET: Registered PF_BLUETOOTH protocol family
[    1.530010] Bluetooth: HCI device and connection manager initialized
[    1.530145] Bluetooth: HCI socket layer initialized
[    1.530180] Bluetooth: L2CAP socket layer initialized
[    1.530347] Bluetooth: SCO socket layer initialized
[    1.533222] vgaarb: loaded
[    1.535344] clocksource: Switched to clocksource mxc_timer1
[    1.538364] VFS: Disk quotas dquot_6.6.0
[    1.538543] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.579519] NET: Registered PF_INET protocol family
[    1.580549] IP idents hash table entries: 16384 (order: 5, 131072
bytes, linear)
[    1.584148] tcp_listen_portaddr_hash hash table entries: 512
(order: 2, 20480 bytes, linear)
[    1.584256] Table-perturb hash table entries: 65536 (order: 6,
262144 bytes, linear)
[    1.584303] TCP established hash table entries: 8192 (order: 3,
32768 bytes, linear)
[    1.584658] TCP bind hash table entries: 8192 (order: 7, 655360
bytes, linear)
[    1.586988] TCP: Hash tables configured (established 8192 bind 8192)
[    1.587712] UDP hash table entries: 512 (order: 3, 49152 bytes, linear)
[    1.587929] UDP-Lite hash table entries: 512 (order: 3, 49152 bytes, linear)
[    1.588553] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    1.591483] RPC: Registered named UNIX socket transport module.
[    1.591536] RPC: Registered udp transport module.
[    1.591553] RPC: Registered tcp transport module.
[    1.591567] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.593486] PCI: CLS 0 bytes, default 64
[    1.595609] armv7-pmu pmu: hw perfevents: no interrupt-affinity
property, guessing.
[    1.598721] hw perfevents: enabled with armv7_cortex_a9 PMU driver,
7 counters available
[    1.606329] Initialise system trusted keyrings
[    1.607301] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[    1.635184] NFS: Registering the id_resolver key type
[    1.635456] Key type id_resolver registered
[    1.635507] Key type id_legacy registered
[    1.635885] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    1.635995] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver
Registering...
[    1.636188] jffs2: version 2.2. (NAND) ? 2001-2006 Red Hat, Inc.
[    1.637781] fuse: init (API version 7.37)
[    1.730733] Key type asymmetric registered
[    1.730857] Asymmetric key parser 'x509' registered
[    1.731593] bounce: pool size: 64 pages
[    1.732072] io scheduler mq-deadline registered
[    1.732097] io scheduler kyber registered
[    1.749796] pwm-backlight backlight-lvds: supply power not found,
using dummy regulator
[    1.794041] mxs-dma 110000.dma-apbh: initialized
[    1.830861] pfuze100-regulator 1-0008: Full layer: 2, Metal layer: 1
[    1.831964] pfuze100-regulator 1-0008: FAB: 0, FIN: 0
[    1.831988] pfuze100-regulator 1-0008: pfuze100 found.
[    1.911047] 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 268,
base_baud = 5000000) is a IMX
[    3.289603] printk: console [ttymxc1] enabled
[    3.298390] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 269,
base_baud = 5000000) is a IMX
[    3.310022] 21f4000.serial: ttymxc4 at MMIO 0x21f4000 (irq = 270,
base_baud = 5000000) is a IMX
[    3.339597] panel-simple panel: supply power not found, using dummy regulator
[    3.365682] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
[    3.372400] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
[    3.378114] etnaviv-gpu 130000.gpu: model: GC880, revision: 5106
[    3.385550] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[    3.395114] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0
[    3.409334] imx-ipuv3 2400000.ipu: IPUv3H probed
[    3.456061] brd: module loaded
[    3.491073] loop: module loaded
[    3.506529] nand: device found, Manufacturer ID: 0xef, Chip ID: 0xd3
[    3.512923] nand: Winbond W29N08GV
[    3.516421] nand: 1024 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[    3.525991] Bad block table found at page 524224, version 0x01
[    3.532422] Bad block table found at page 524160, version 0x01
[    3.538885] 6 cmdlinepart partitions found on MTD device gpmi-nand
[    3.545094] Creating 6 MTD partitions on "gpmi-nand":
[    3.550240] 0x000000000000-0x000000200000 : "spl"
[    3.566776] 0x000000200000-0x000000400000 : "uboot"
[    3.579186] 0x000000400000-0x000000500000 : "env"
[    3.591520] 0x000000500000-0x000001500000 : "kernel"
[    3.604423] 0x000001500000-0x000001600000 : "dtb"
[    3.618303] 0x000001600000-0x000040000000 : "rootfs"
[    3.659665] gpmi-nand 112000.nand-controller: driver registered.
[    3.666959] SPI driver spidev has no spi_device_id for ltts,evalspi
[    3.686253] CAN device driver interface
[    3.702126] pps pps0: new PPS source ptp0
[    3.709056] fec 2188000.ethernet: Invalid MAC address: 00:00:00:00:00:00
[    3.715988] fec 2188000.ethernet: Using random MAC address: 86:d6:01:18:ff:de
[    3.733304] fec 2188000.ethernet eth0: registered PHC device 0
[    3.741777] usbcore: registered new interface driver r8152
[    3.747648] usbcore: registered new interface driver lan78xx
[    3.753513] usbcore: registered new interface driver asix
[    3.759328] usbcore: registered new interface driver ax88179_178a
[    3.765791] usbcore: registered new interface driver cdc_ether
[    3.771827] usbcore: registered new interface driver smsc95xx
[    3.777918] usbcore: registered new interface driver net1080
[    3.783727] usbcore: registered new interface driver cdc_subset
[    3.789881] usbcore: registered new interface driver zaurus
[    3.795672] usbcore: registered new interface driver MOSCHIP
usb-ethernet driver
[    3.803385] usbcore: registered new interface driver cdc_ncm
[    3.809271] usbcore: registered new interface driver r8153_ecm
[    3.815506] usbcore: registered new interface driver usb-storage
[    3.831006] SPI driver ads7846 has no spi_device_id for ti,tsc2046
[    3.837316] SPI driver ads7846 has no spi_device_id for ti,ads7843
[    3.843521] SPI driver ads7846 has no spi_device_id for ti,ads7845
[    3.849776] SPI driver ads7846 has no spi_device_id for ti,ads7873
[    4.445853] input: ILI210x Touchscreen as
/devices/platform/soc/2100000.bus/21a0000.i2c/i2c-0/0-0041/input/input0
[    4.463608] pwm-beeper buzzer: supply amp not found, using dummy regulator
[    4.471904] input: pwm-beeper as /devices/platform/buzzer/input/input1
[    4.489945] rtc-rv3032 2-0051: registered as rtc0
[    4.495855] rtc-rv3032 2-0051: hctosys: unable to read the hardware clock
[    4.508809] hwmon hwmon0: temp1_input not attached to any thermal zone
[    4.521570] snvs_rtc 20cc000.snvs:snvs-rtc-lp: registered as rtc1
[    4.528373] i2c_dev: i2c /dev entries driver
[    4.549409] Bluetooth: HCI UART driver ver 2.3
[    4.553894] Bluetooth: HCI UART protocol H4 registered
[    4.559248] Bluetooth: HCI UART protocol LL registered
[    4.564605] usbcore: registered new interface driver btusb
[    4.573887] sdhci: Secure Digital Host Controller Interface driver
[    4.580184] sdhci: Copyright(c) Pierre Ossman
[    4.584567] sdhci-pltfm: SDHCI platform and OF driver helper
[    4.594237] sdhci-esdhc-imx 2190000.mmc: Got CD GPIO
[    4.608457] caam 2100000.crypto: Entropy delay = 3200
[    4.674334] caam 2100000.crypto: Instantiated RNG4 SH0
[    4.735099] caam 2100000.crypto: Instantiated RNG4 SH1
[    4.745853] caam 2100000.crypto: device ID = 0x0a16010000000100 (Era 4)
[    4.752569] caam 2100000.crypto: job rings = 2, qi = 0
[    4.766963] caam algorithms registered in /proc/crypto
[    4.772822] caam 2100000.crypto: registering rng-caam
[    4.786217] mmc0: SDHCI controller on 2190000.mmc [2190000.mmc] using ADMA
[    4.797221] caam 2100000.crypto: rng crypto API alg registered prng-caam
[    4.810644] usbcore: registered new interface driver usbhid
[    4.816367] usbhid: USB HID core driver
[    4.826100] imx-ipuv3-csi imx-ipuv3-csi.0: Registered ipu1_csi0
capture as /dev/video0
[    4.836462] imx-ipuv3 2400000.ipu: Registered ipu1_ic_prpenc
capture as /dev/video1
[    4.845191] imx-ipuv3 2400000.ipu: Registered ipu1_ic_prpvf capture
as /dev/video2
[    4.854918] imx-ipuv3-csi imx-ipuv3-csi.1: Registered ipu1_csi1
capture as /dev/video3
[    4.871518] mmc0: host does not support reading read-only switch,
assuming write-enable
[    4.887794] mmc0: new high speed SDHC card at address 0001
[    4.907708] mmcblk0: mmc0:0001 USD 7.44 GiB
[    4.923964] NET: Registered PF_INET6 protocol family
[    4.938124]  mmcblk0: p1 p2 p3
[    4.949653] Segment Routing with IPv6
[    4.953421] In-situ OAM (IOAM) with IPv6
[    4.958277] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    4.967245] NET: Registered PF_PACKET protocol family
[    4.973235] can: controller area network core
[    4.978040] NET: Registered PF_CAN protocol family
[    4.982948] can: raw protocol
[    4.986206] random: crng init done
[    4.989816] can: broadcast manager protocol
[    4.994071] can: netlink gateway - max_hops=1
[    4.999596] Key type dns_resolver registered
[    5.016720] Registering SWP/SWPB emulation handler
[    5.022738] Loading compiled-in X.509 certificates
[    5.204409] Stack Depot allocating hash table of 65536 entries with kvcalloc
[    5.216619] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
ipu_crtc_ops)
[    5.224503] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops
ipu_crtc_ops)
[    5.232738] imx-drm display-subsystem: bound ldb (ops imx_ldb_ops)
[    5.242432] [drm] Initialized imx-drm 1.0.0 20120507 for
display-subsystem on minor 1
[    5.336982] Console: switching to colour frame buffer device 160x50
[    5.363752] imx-drm display-subsystem: [drm] fb0: imx-drmdrmfb
frame buffer device
[    5.997424] mxs_phy 20c9000.usbphy: Data pin can't make good contact.
[    6.013128] ci_hdrc ci_hdrc.1: EHCI Host Controller
[    6.018536] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1
[    6.055398] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[    6.062453] usb usb1: New USB device found, idVendor=1d6b,
idProduct=0002, bcdDevice= 6.01
[    6.071010] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    6.078308] usb usb1: Product: EHCI Host Controller
[    6.083208] usb usb1: Manufacturer: Linux 6.1.58 ehci_hcd
[    6.089002] usb usb1: SerialNumber: ci_hdrc.1
[    6.098174] hub 1-0:1.0: USB hub found
[    6.102309] hub 1-0:1.0: 1 port detected
[    6.113416] video-mux 20e0000.iomuxc-gpr:ipu1_csi0_mux: Consider
updating driver video-mux to match on endpoints
[    6.126877] video-mux 20e0000.iomuxc-gpr:ipu1_csi1_mux: Consider
updating driver video-mux to match on endpoints
[    6.145163] imx-media: Registered ipu_ic_pp csc/scaler as /dev/video4
[    6.156758] imx_thermal 20c8000.anatop:tempmon: Extended Commercial
CPU temperature grade - max:105C critical:100C passive:95C
[    6.181973] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[    6.196443] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    6.204613] platform regulatory.0: Direct firmware load for
regulatory.db failed with error -2
[    6.213542] platform regulatory.0: Falling back to sysfs fallback
for: regulatory.db
[    6.224065] ALSA device list:
[    6.230889]   No soundcards found.
[    6.271484] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
data mode. Quota mode: none.
[    6.281110] VFS: Mounted root (ext4 filesystem) on device 179:2.
[    6.289875] devtmpfs: mounted
[    6.295188] Freeing unused kernel image (initmem) memory: 1024K
[    6.302075] Run /sbin/init as init process
[    6.395409] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[    6.598005] usb 1-1: New USB device found, idVendor=0451,
idProduct=8142, bcdDevice= 1.00
[    6.606485] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[    6.613748] usb 1-1: SerialNumber: EA030849138F
[    6.628789] hub 1-1:1.0: USB hub found
[    6.633391] hub 1-1:1.0: 4 ports detected
[    6.772078] systemd[1]: System time before build time, advancing clock.
[    6.900824] systemd[1]: systemd 250.5+ running in system mode (-PAM
-AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP -GCRYPT -GNUTLS
-OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD
-LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2
-LZ4 -XZ -ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT
default-hierarchy=hybrid)
[    6.934384] systemd[1]: Detected architecture arm.

Welcome to FSLC FrameBuffer [    6.955469] usb 1-1.1: new high-speed
USB device number 3 using ci_hdrc
4.0 (kirkstone)!

[    6.987732] systemd[1]: Hostname set to <ltts-imx6solo>.
[    7.002838] systemd[1]: Initializing machine ID from random generator.
[    7.107401] usb 1-1.1: New USB device found, idVendor=04b4,
idProduct=bd30, bcdDevice= 1.00
[    7.116088] usb 1-1.1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[    7.138412] hub 1-1.1:1.0: USB hub found
[    7.145842] hub 1-1.1:1.0: 2 ports detected
[    7.575615] usb 1-1.1.1: new high-speed USB device number 4 using ci_hdrc
[    7.747978] usb 1-1.1.1: New USB device found, idVendor=04b4,
idProduct=bd29, bcdDevice= 0.01
[    7.756770] usb 1-1.1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[    7.764382] usb 1-1.1.1: Product: Remote Download Wireless Adapter
[    7.770725] usb 1-1.1.1: Manufacturer: Cypress Semiconductor Corp.
[    7.776982] usb 1-1.1.1: SerialNumber: 000000000001
[    7.905545] usb 1-1.1.2: new high-speed USB device number 5 using ci_hdrc
[    8.067618] usb 1-1.1.2: New USB device found, idVendor=04b4,
idProduct=640c, bcdDevice= 1.12
[    8.076399] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[    8.083962] usb 1-1.1.2: Product: BCM2045A0
[    8.088278] usb 1-1.1.2: Manufacturer: Cypress Semiconductor Corp.
[    8.094481] usb 1-1.1.2: SerialNumber: C0EE40822FFD
[    8.115037] Bluetooth: : invalid diagnostic descriptors
[    8.258777] Bluetooth: hci0: BCM: chip id 135
[    8.264757] Bluetooth: hci0: BCM: features 0x0f
[    8.270748] Bluetooth: hci0: BCM4373A0
[    8.274527] Bluetooth: hci0: BCM (001.001.025) build 0000
[    8.586409] systemd[1]: Queued start job for default target
Multi-User System.
[    8.603805] systemd[1]: Created slice Slice /system/getty.
[  OK  ] Created slice Slice /system/getty.
[    8.648833] systemd[1]: Created slice Slice /system/modprobe.
[  OK  ] Created slice Slice /system/modprobe.
[    8.688774] systemd[1]: Created slice Slice /system/serial-getty.
[  OK  ] Created slice Slice /system/serial-getty.
[    8.727817] systemd[1]: Created slice User and Session Slice.
[  OK  ] Created slice User and Session Slice.
[    8.766815] systemd[1]: Started Dispatch Password Requests to
Console Directory Watch.
[  OK  ] Started Dispatch Password ?ts to Console Directory Watch.
[    8.806596] systemd[1]: Started Forward Password Requests to Wall
Directory Watch.
[  OK  ] Started Forward Password R?uests to Wall Directory Watch.
[    8.846133] systemd[1]: Reached target Remote File Systems.
[  OK  ] Reached target Remote File Systems.
[    8.885810] systemd[1]: Reached target Slice Units.
[  OK  ] Reached target Slice Units.
[    8.915823] systemd[1]: Reached target Swaps.
[  OK  ] Reached target Swaps.
[    9.039331] systemd[1]: Listening on RPCbind Server Activation Socket.
[  OK  ] Listening on RPCbind Server Activation Socket.
[    9.075978] systemd[1]: Reached target RPC Port Mapper.
[  OK  ] Reached target RPC Port Mapper.
[    9.118117] systemd[1]: Listening on Syslog Socket.
[  OK  ] Listening on Syslog Socket.
[    9.157256] systemd[1]: Listening on initctl Compatibility Named Pipe.
[  OK  ] Listening on initctl Compatibility Named Pipe.
[    9.209924] systemd[1]: Journal Audit Socket was skipped because of
a failed condition check (ConditionSecurity=audit).
[    9.222922] systemd[1]: Listening on Journal Socket (/dev/log).
[  OK  ] Listening on Journal Socket (/dev/log).
[    9.267869] systemd[1]: Listening on Journal Socket.
[  OK  ] Listening on Journal Socket.
[    9.307376] systemd[1]: Listening on Network Service Netlink Socket.
[  OK  ] Listening on Network Service Netlink Socket.
[    9.348009] systemd[1]: Listening on udev Control Socket.
[  OK  ] Listening on udev Control Socket.
[    9.387020] systemd[1]: Listening on udev Kernel Socket.
[  OK  ] Listening on udev Kernel Socket.
[    9.427590] systemd[1]: Listening on User Database Manager Socket.
[  OK  ] Listening on User Database Manager Socket.
[    9.467036] systemd[1]: Huge Pages File System was skipped because
of a failed condition check
(ConditionPathExists=/sys/kernel/mm/hugepages).
[    9.481016] systemd[1]: POSIX Message Queue File System was skipped
because of a failed condition check
(ConditionPathExists=/proc/sys/fs/mqueue).
[    9.527378] systemd[1]: Mounting Kernel Debug File System...
         Mounting Kernel Debug File System...
[    9.558506] systemd[1]: Mounting Kernel Trace File System...
         Mounting Kernel Trace File System...
[    9.616712] systemd[1]: Mounting Temporary Directory /tmp...
         Mounting Temporary Directory /tmp...
[    9.656702] systemd[1]: Create List of Static Device Nodes was
skipped because of a failed condition check
(ConditionFileNotEmpty=/lib/modules/6.1.58/modules.devname).
[    9.707567] systemd[1]: Starting Load Kernel Module configfs...
         Starting Load Kernel Module configfs...
[    9.751753] systemd[1]: Starting Load Kernel Module drm...
         Starting Load Kernel Module drm...
[    9.798167] systemd[1]: Starting Load Kernel Module fuse...
         Starting Load Kernel Module fuse...
[    9.832532] systemd[1]: Starting RPC Bind...
         Starting RPC Bind...
[    9.886356] systemd[1]: File System Check on Root Device was
skipped because of a failed condition check
(ConditionPathIsReadWrite=!/).
[    9.957558] systemd[1]: Starting Journal Service...
         Starting Journal Service...
[    9.988890] systemd[1]: Load Kernel Modules was skipped because all
trigger condition checks failed.
[   10.042346] systemd[1]: Starting Generate network units from Kernel
command line...
         Starting Generate network ?ts from Kernel command line...
[   10.133724] systemd[1]: Starting Remount Root and Kernel File Systems...
         Starting Remount Root and Kernel File Systems...
[   10.243537] systemd[1]: Starting Apply Kernel Variables...
         Starting Apply Kernel Variables...
[   10.343465] systemd[1]: Starting Coldplug All udev Devices...
[   10.374405] EXT4-fs (mmcblk0p2): re-mounted. Quota mode: none.
         Starting Coldplug All udev Devices...
[   10.534913] systemd[1]: Started RPC Bind.
[  OK  ] Started RPC Bind.
[   10.608027] systemd[1]: Mounted Kernel Debug File System.
[  OK  ] Mounted Kernel Debug File System.
[   10.637271] systemd[1]: Mounted Kernel Trace File System.
[  OK  ] Mounted Kernel Trace File System.
[   10.657321] systemd[1]: Mounted Temporary Directory /tmp.
[  OK  ] Mounted Temporary Directory /tmp.
[   10.681203] systemd[1]: modprobe at configfs.service: Deactivated successfully.
[   10.737464] systemd[1]: Finished Load Kernel Module configfs.
[  OK  ] Finished Load Kernel Module configfs.
[   10.760018] systemd[1]: modprobe at drm.service: Deactivated successfully.
[   10.806004] systemd[1]: Finished Load Kernel Module drm.
[  OK  ] Finished Load Kernel Module drm.
[   10.849819] systemd[1]: modprobe at fuse.service: Deactivated successfully.
[   10.886052] systemd[1]: Finished Load Kernel Module fuse.
[  OK  ] Finished Load Kernel Module fuse.
[   10.936205] systemd[1]: Finished Generate network units from Kernel
command line.
[  OK  ] Finished Generate network units from Kernel command line.
[   10.969049] systemd[1]: Finished Remount Root and Kernel File Systems.
[  OK  ] Finished Remount Root and Kernel File Systems.
[   11.036198] systemd[1]: Finished Apply Kernel Variables.
[  OK  ] Finished Apply Kernel Variables.
[   11.087501] systemd[1]: Mounting FUSE Control File System...
         Mounting FUSE Control File System...
[   11.176360] systemd[1]: Mounting Kernel Configuration File System...
         Mounting Kernel Configuration File System...
[   11.215767] systemd[1]: Rebuild Hardware Database was skipped
because all trigger condition checks failed.
[   11.251767] systemd[1]: Platform Persistent Storage Archival was
skipped because of a failed condition check
(ConditionDirectoryNotEmpty=/sys/fs/pstore).
[   11.328008] systemd[1]: Starting Create System Users...
         Starting Create System Users...
[   11.364934] systemd[1]: Mounted FUSE Control File System.
[  OK  ] Mounted FUSE Control File System.
[   11.497676] systemd[1]: Mounted Kernel Configuration File System.
[  OK  ] Mounted Kernel Configuration File System.
[   11.646076] systemd[1]: Finished Create System Users.
[  OK  ] Finished Create System Users.
[   11.713902] systemd[1]: Starting Create Static Device Nodes in /dev...
         Starting Create Static Device Nodes in /dev...
[   11.874042] systemd[1]: Started Journal Service.
[  OK  ] Started Journal Service.
         Starting Flush Journal to Persistent Storage...
[  OK  ] Finished Create Static Device Nodes in /dev.
[  OK  ] Reached target Preparation for Local File Systems.
[   12.106123] systemd-journald[189]: Received client request to flush
runtime journal.
         Mounting /var/volatile...
         Starting Rule-based Manage?for Device Events and Files...
[  OK  ] Finished Flush Journal to Persistent Storage.
[  OK  ] Mounted /var/volatile.
         Starting Load/Save Random Seed...
[  OK  ] Reached target Local File Systems.
         Starting Rebuild Dynamic Linker Cache...
         Starting Create Volatile Files and Directories...
[  OK  ] Finished Load/Save Random Seed.
[  OK  ] Started Rule-based Manager for Device Events and Files.
[  OK  ] Finished Create Volatile Files and Directories.
         Starting Rebuild Journal Catalog...
         Starting Network Time Synchronization...
         Starting Record System Boot/Shutdown in UTMP...
[  OK  ] Finished Record System Boot/Shutdown in UTMP.
[  OK  ] Finished Rebuild Journal Catalog.
[   16.493054] platform 2008000.spi: deferred probe pending
[   16.499144] platform 200c000.spi: deferred probe pending
[  OK  ] Finished Rebuild Dynamic Linker Cache.
         Starting Update is Completed...
[  OK  ] Started Network Time Synchronization.
[  OK  ] Reached target System Time Set.
[  OK  ] Finished Update is Completed.
[  OK  ] Created slice Slice /system/systemd-backlight.
         Starting Load/Save Screen ?of backlight:backlight-lvds...
[   18.799032] mtdblock: MTD device 'spl' is NAND, please consider
using UBI block devices instead.
[   18.816735] mtdblock: MTD device 'env' is NAND, please consider
using UBI block devices instead.
[   18.828089] mtdblock: MTD device 'uboot' is NAND, please consider
using UBI block devices instead.
[  OK  ] Finished Load/Save Screen ?s of backlight:backlight-lvds.
[   18.876158] mtdblock: MTD device 'kernel' is NAND, please consider
using UBI block devices instead.
[   19.041189] mtdblock: MTD device 'dtb' is NAND, please consider
using UBI block devices instead.
[   19.110839] mtdblock: MTD device 'rootfs' is NAND, please consider
using UBI block devices instead.
[  OK  ] Finished Coldplug All udev Devices.
[   19.724404] coda 2040000.vpu: Firmware code revision: 46076
[   19.730290] coda 2040000.vpu: Initialized CODA960.
[   19.735106] coda 2040000.vpu: Firmware version: 3.1.1
[  OK  ] Reached target System Initialization.
[  OK  ] Started CUPS Scheduler.
[   19.976908] coda 2040000.vpu: coda-jpeg-encoder registered as video5
[  OK  ] Started Daily Cleanup of Temporary Directories.
[  OK  ] Reached target Path Units.
[  OK  ] Reached target Timer Units.
[   20.070627] coda 2040000.vpu: coda-jpeg-decoder registered as video6
[  OK  ] Listening on Avahi mDNS/DNS-SD Stack Activation Socket.
[   20.152447] coda 2040000.vpu: coda-video-encoder registered as video7
[   20.209677] coda 2040000.vpu: coda-video-decoder registered as video8
[   20.338632] switch at 0 enforce active low on chipselect handle
[  OK  ] Listening on [   20.369744] imx-sdma 20ec000.dma-controller:
loaded firmware 3.5
CUPS LPD Server Socket.
[  OK  ] Listening on CUPS Scheduler.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Socket Units.
[  OK  ] Reached target Basic System.
[  OK  ] Started Kernel Logging Service.
[  OK  ] Started System Logging Service.
         Starting D-Bus System Message Bus...
[  OK  ] Started Getty on tty1.
         Starting IPv6 Packet Filtering Framework...
         Starting IPv4 Packet Filtering Framework...
         Starting Turn OFF RGB LED...
         Starting Telephony service...
[  OK  ] Started Serial Getty on ttymxc1.
[   22.118482] brcmfmac: brcmf_fw_alloc_request: using
brcm/brcmfmac4373 for chip BCM4373/0
[  OK  ] Reached target Login Prompts.
[   22.318014] usbcore: registered new interface driver brcmfmac
         Starting User Login Management...
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Finished IPv6 Packet Filtering Framework.
[  OK  ] Finished IPv4 Packet Filtering Framework.
[  OK  ] Finished Turn OFF RGB LED.
[   25.296596] sja1105 spi1.0: Probed switch chip: SJA1105Q
[   25.567725] sja1105 spi1.0: configuring for fixed/mii link mode
[   25.646176] sja1105 spi1.0 ethphy0 (uninitialized): PHY
[2188000.ethernet-1:00] driver [TI DP83848C 10/100 Mbps PHY]
(irq=POLL)
[  OK  ] Started Telephony service.
[   25.805638] sja1105 spi1.0 ethphy1 (uninitialized): PHY
[2188000.ethernet-1:01] driver [TI DP83848C 10/100 Mbps PHY]
(irq=POLL)
[   25.925915] device eth0 entered promiscuous mode
[   25.930974] DSA: tree 0 setup

FSLC FrameBuffer 4.0 ltts-imx6solo ttymxc1

ltts-imx6solo login: [   27.736803] usb 1-1.1.1: USB disconnect, device number 4
[   27.844068] brcmfmac: brcmf_usb_dl_cmd: usb_submit_urb failed -19
[   27.936752] sja1105 spi1.0: Link is Up - 100Mbps/Full - flow control off
[   28.235476] usb 1-1.1.1: new high-speed USB device number 6 using ci_hdrc
[   28.418004] usb 1-1.1.1: New USB device found, idVendor=04b4,
idProduct=0bdc, bcdDevice= 0.01
[   28.426753] usb 1-1.1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[   28.434317] usb 1-1.1.1: Product: Cypress USB 802.11 Wireless Adapter
[   28.440924] usb 1-1.1.1: Manufacturer: Cypress Semiconductor Corp.
[   28.447196] usb 1-1.1.1: SerialNumber: 000000000001
[   28.565571] brcmfmac: brcmf_fw_alloc_request: using
brcm/brcmfmac4373 for chip BCM4373/0
[   28.627016] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4373/0
wl0: Nov 16 2022 23:54:18 version 13.10.246.300 (ed9caf7 CY) FWID
01-3b88916b
[   29.486120] Generic PHY fixed-0:00: attached PHY driver
(mii_bus:phy_addr=fixed-0:00, irq=POLL)
[   29.497422] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full -
flow control off
[   29.623164] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   29.637065] Bluetooth: BNEP socket layer initialized
[   29.836814] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   69.610610] cfg80211: failed to load regulatory.db
[   69.620405] Bluetooth: hci0: BCM 'brcm/BCM-04b4-640c.hcd' Patch
[   70.347701] Bluetooth: hci0: BCM: features 0x0f
[   70.353703] Bluetooth: hci0: CYW94373 UART 37.4MHz Class 1 wlbga sLNA-0102
[   70.360747] Bluetooth: hci0: BCM (001.001.025) build 0149
[   70.422010] Bluetooth: MGMT ver 1.22

ltts-imx6solo login: root
root at ltts-imx6solo:~# cat /usr/phynew.sh
#!/bin/sh

echo ======= MDIO: PHY0 ========
mdio 2188000.ethernet-1 phy 0 raw 0x0
mdio 2188000.ethernet-1 phy 0 raw 0x1
mdio 2188000.ethernet-1 phy 0 raw 0x2
mdio 2188000.ethernet-1 phy 0 raw 0x3
mdio 2188000.ethernet-1 phy 0 raw 0x4
mdio 2188000.ethernet-1 phy 0 raw 0x5
mdio 2188000.ethernet-1 phy 0 raw 0x6
mdio 2188000.ethernet-1 phy 0 raw 0x7
mdio 2188000.ethernet-1 phy 0 raw 0x10
mdio 2188000.ethernet-1 phy 0 raw 0x19

echo ======= MDIO: PHY1 ========
mdio 2188000.ethernet-1 phy 1 raw 0x0
mdio 2188000.ethernet-1 phy 1 raw 0x1
mdio 2188000.ethernet-1 phy 1 raw 0x2
mdio 2188000.ethernet-1 phy 1 raw 0x3
mdio 2188000.ethernet-1 phy 1 raw 0x4
mdio 2188000.ethernet-1 phy 1 raw 0x5
mdio 2188000.ethernet-1 phy 1 raw 0x6
mdio 2188000.ethernet-1 phy 1 raw 0x7
mdio 2188000.ethernet-1 phy 1 raw 0x10
mdio 2188000.ethernet-1 phy 1 raw 0x19

ip link set dev eth0 down
ip link set dev ethphy0 down
ip link set dev ethphy1 down

ip link set dev ethphy0 address 00:11:22:33:44:55
ip link set dev ethphy1 address 00:11:22:33:44:66

ip addr add dev ethphy0 169.254.178.1/16
ip addr add dev ethphy1 169.253.178.2/16

ip link set dev eth0 up
ip link set dev ethphy0 up
ip link set dev ethphy1 up
ip link

echo ########## MDIO: PHY0 ###########
mdio 2188000.ethernet-1 phy 0 raw 0x0
mdio 2188000.ethernet-1 phy 0 raw 0x1
mdio 2188000.ethernet-1 phy 0 raw 0x2
mdio 2188000.ethernet-1 phy 0 raw 0x3
mdio 2188000.ethernet-1 phy 0 raw 0x4
mdio 2188000.ethernet-1 phy 0 raw 0x5
mdio 2188000.ethernet-1 phy 0 raw 0x6
mdio 2188000.ethernet-1 phy 0 raw 0x7
mdio 2188000.ethernet-1 phy 0 raw 0x10
mdio 2188000.ethernet-1 phy 0 raw 0x19

echo ########## MDIO: PHY1 ###########
mdio 2188000.ethernet-1 phy 1 raw 0x0
mdio 2188000.ethernet-1 phy 1 raw 0x1
mdio 2188000.ethernet-1 phy 1 raw 0x2
mdio 2188000.ethernet-1 phy 1 raw 0x3
mdio 2188000.ethernet-1 phy 1 raw 0x4
mdio 2188000.ethernet-1 phy 1 raw 0x5
mdio 2188000.ethernet-1 phy 1 raw 0x6
mdio 2188000.ethernet-1 phy 1 raw 0x7
mdio 2188000.ethernet-1 phy 1 raw 0x10
mdio 2188000.ethernet-1 phy 1 raw 0x19


root at ltts-imx6solo:~# bash /usr/phynew.sh
======= MDIO: PHY0 ========
[  162.426515] mdio_netlink: loading out-of-tree module taints kernel.
0x3100
0x7869
0x2000
0x5ca2
0x01e1
0x45e1
0x0007
0x2801
0x4015
0x8020
======= MDIO: PHY1 ========
0x3100
0x7869
0x2000
0x5ca2
0x01e1
0x45e1
0x0007
0x2801
0x0015
0x8021
[  162.992201] Generic PHY fixed-0:00: attached PHY driver
(mii_bus:phy_addr=fixed-0:00, irq=POLL)
[  163.002179] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full -
flow control off
[  163.035906] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  163.074193] sja1105 spi1.0 ethphy0: configuring for phy/mii link mode
[  163.144909] sja1105 spi1.0 ethphy1: configuring for phy/mii link mode
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 1000
    link/ether 6a:fb:08:df:d3:77 brd ff:ff:ff:ff:ff:ff
3: sit0 at NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
4: ethphy0 at eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
5: ethphy1 at eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:66 brd ff:ff:ff:ff:ff:ff
6: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
    link/ether c0:ee:40:82:2f:fc brd ff:ff:ff:ff:ff:ff

0x3100
0x7849
0x2000
0x5ca2
0x0141
0x0000
0x0005
0x2801
0x4000
0x8020

0x3100
0x7849
0x2000
0x5ca2
0x0141
0x0000
0x0005
0x2801
0x0000
0x8021
root at ltts-imx6solo:~# [  165.208656] sja1105 spi1.0 ethphy0: Link is
Up - 100Mbps/Full - flow control off
[  165.225788] sja1105 spi1.0 ethphy1: Link is Up - 100Mbps/Full -
flow control off
[  165.235925] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy0: link becomes ready
[  165.255777] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy1: link becomes ready

root at ltts-imx6solo:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1504
        inet6 fe80::68fb:8ff:fedf:d377  prefixlen 64  scopeid 0x20<link>
        ether 6a:fb:08:df:d3:77  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethphy0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.178.1  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 fe80::211:22ff:fe33:4455  prefixlen 64  scopeid 0x20<link>
        ether 00:11:22:33:44:55  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 30  bytes 4071 (3.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethphy1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.253.178.2  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 fe80::211:22ff:fe33:4466  prefixlen 64  scopeid 0x20<link>
        ether 00:11:22:33:44:66  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 30  bytes 4071 (3.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 89  bytes 7675 (7.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 89  bytes 7675 (7.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

mytsl02383 at MYTSL02383:~$ ifconfig -a
enp43s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.178.2  netmask 255.255.0.0  broadcast 169.254.255.255
        inet6 fe80::d71b:4bdd:27bd:2a1a  prefixlen 64  scopeid 0x20<link>
        ether 00:be:43:20:9a:26  txqueuelen 1000  (Ethernet)
        RX packets 272356  bytes 27099064 (27.0 MB)
        RX errors 0  dropped 19  overruns 0  frame 0
        TX packets 862  bytes 300806 (300.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
mytsl02383 at MYTSL02383:~$ ping 169.254.178.1
PING 169.254.178.1 (169.254.178.1) 56(84) bytes of data.
>From 169.254.178.2 icmp_seq=1 Destination Host Unreachable

Let me know if you need any more details.

Thanks,
Jagan.


From eugen.hristev at collabora.com  Fri Dec 29 03:43:42 2023
From: eugen.hristev at collabora.com (Eugen Hristev)
Date: Fri, 29 Dec 2023 13:43:42 +0200
Subject: [PATCH] ASoC: mediatek: mt8186: fix AUD_PAD_TOP register and offset
Message-ID: <20231229114342.195867-1-eugen.hristev@collabora.com>

AUD_PAD_TOP widget's correct register is AFE_AUD_PAD_TOP , and not zero.
Having a zero as register, it would mean that the `snd_soc_dapm_new_widgets`
would try to read the register at offset zero when trying to get the power
status of this widget, which is incorrect.

Fixes: b65c466220b3 ("ASoC: mediatek: mt8186: support adda in platform driver")
Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
---
 sound/soc/mediatek/mt8186/mt8186-dai-adda.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/mediatek/mt8186/mt8186-dai-adda.c b/sound/soc/mediatek/mt8186/mt8186-dai-adda.c
index 85ae3f76d951..ad6d4b5cf697 100644
--- a/sound/soc/mediatek/mt8186/mt8186-dai-adda.c
+++ b/sound/soc/mediatek/mt8186/mt8186-dai-adda.c
@@ -499,7 +499,7 @@ static const struct snd_soc_dapm_widget mtk_dai_adda_widgets[] = {
 			      SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
 
 	SND_SOC_DAPM_SUPPLY_S("AUD_PAD_TOP", SUPPLY_SEQ_ADDA_AUD_PAD_TOP,
-			      0, 0, 0,
+			      AFE_AUD_PAD_TOP, RG_RX_FIFO_ON_SFT, 0,
 			      mtk_adda_pad_top_event,
 			      SND_SOC_DAPM_PRE_PMU),
 	SND_SOC_DAPM_SUPPLY_S("ADDA_MTKAIF_CFG", SUPPLY_SEQ_ADDA_MTKAIF_CFG,
-- 
2.34.1



From leong.ching.swee at intel.com  Fri Dec 29 03:51:06 2023
From: leong.ching.swee at intel.com (Swee, Leong Ching)
Date: Fri, 29 Dec 2023 11:51:06 +0000
Subject: [PATCH net-next v1 4/4] net: stmmac: Use interrupt mode INTM=1
 for per channel irq
In-Reply-To: <prjrrsznvpnbanseqttqgtu3s6kgillyyhs5hozwxwh4kt7eiv@zmups3rcbvby>
References: <20231222054451.2683242-1-leong.ching.swee@intel.com>
 <20231222054451.2683242-5-leong.ching.swee@intel.com>
 <prjrrsznvpnbanseqttqgtu3s6kgillyyhs5hozwxwh4kt7eiv@zmups3rcbvby>
Message-ID: <CH0PR11MB5490FBE567511E89C8F80BE5CF9DA@CH0PR11MB5490.namprd11.prod.outlook.com>

> -----Original Message-----
> From: Serge Semin <fancer.lancer at gmail.com>
> Sent: Saturday, December 23, 2023 5:57 AM
> To: Swee, Leong Ching <leong.ching.swee at intel.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>; Alexandre Torgue
> <alexandre.torgue at foss.st.com>; Jose Abreu <joabreu at synopsys.com>;
> David S . Miller <davem at davemloft.net>; Eric Dumazet
> <edumazet at google.com>; Jakub Kicinski <kuba at kernel.org>; Paolo Abeni
> <pabeni at redhat.com>; Rob Herring <robh+dt at kernel.org>; Krzysztof
> Kozlowski <krzysztof.kozlowski+dt at linaro.org>; Conor Dooley
> <conor+dt at kernel.org>; Giuseppe Cavallaro <peppe.cavallaro at st.com>;
> linux-stm32 at st-md-mailman.stormreply.com; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> netdev at vger.kernel.org; devicetree at vger.kernel.org; Teoh Ji Sheng
> <ji.sheng.teoh at intel.com>
> Subject: Re: [PATCH net-next v1 4/4] net: stmmac: Use interrupt mode
> INTM=1 for per channel irq
> 
> On Fri, Dec 22, 2023 at 01:44:51PM +0800, Leong Ching Swee wrote:
> > From: Swee Leong Ching <leong.ching.swee at intel.com>
> >
> > Enable per DMA channel interrupt that uses shared peripheral interrupt
> > (SPI), so only per channel TX and RX intr (TI/RI) are handled by TX/RX
> > ISR without calling common interrupt ISR.
> >
> > Signed-off-by: Teoh Ji Sheng <ji.sheng.teoh at intel.com>
> > Signed-off-by: Swee Leong Ching <leong.ching.swee at intel.com>
> > ---
> >  .../net/ethernet/stmicro/stmmac/dwxgmac2.h    |  3 ++
> >  .../ethernet/stmicro/stmmac/dwxgmac2_dma.c    | 32 +++++++++++-------
> -
> >  2 files changed, 22 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> > b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> > index 207ff1799f2c..04bf731cb7ea 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> > @@ -346,6 +346,9 @@
> >  /* DMA Registers */
> >  #define XGMAC_DMA_MODE			0x00003000
> >  #define XGMAC_SWR			BIT(0)
> > +#define XGMAC_DMA_MODE_INTM_MASK	GENMASK(13, 12)
> > +#define XGMAC_DMA_MODE_INTM_SHIFT	12
> > +#define XGMAC_DMA_MODE_INTM_MODE1	0x1
> >  #define XGMAC_DMA_SYSBUS_MODE		0x00003004
> >  #define XGMAC_WR_OSR_LMT		GENMASK(29, 24)
> >  #define XGMAC_WR_OSR_LMT_SHIFT		24
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> > b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> > index 3cde695fec91..dcb9f094415d 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
> > @@ -31,6 +31,13 @@ static void dwxgmac2_dma_init(void __iomem
> *ioaddr,
> >  		value |= XGMAC_EAME;
> >
> >  	writel(value, ioaddr + XGMAC_DMA_SYSBUS_MODE);
> > +
> > +	if (dma_cfg->multi_irq_en) {
> > +		value = readl(ioaddr + XGMAC_DMA_MODE);
> > +		value &= ~XGMAC_DMA_MODE_INTM_MASK;
> > +		value |= (XGMAC_DMA_MODE_INTM_MODE1 <<
> XGMAC_DMA_MODE_INTM_SHIFT);
> > +		writel(value, ioaddr + XGMAC_DMA_MODE);
> > +	}
> >  }
> >
> >  static void dwxgmac2_dma_init_chan(struct stmmac_priv *priv, @@
> > -365,19 +372,18 @@ static int dwxgmac2_dma_interrupt(struct
> stmmac_priv *priv,
> >  	}
> >
> 
> >  	/* TX/RX NORMAL interrupts */
> > -	if (likely(intr_status & XGMAC_NIS)) {
> > -		if (likely(intr_status & XGMAC_RI)) {
> > -			u64_stats_update_begin(&rxq_stats->syncp);
> > -			rxq_stats->rx_normal_irq_n++;
> > -			u64_stats_update_end(&rxq_stats->syncp);
> > -			ret |= handle_rx;
> > -		}
> > -		if (likely(intr_status & (XGMAC_TI | XGMAC_TBU))) {
> > -			u64_stats_update_begin(&txq_stats->syncp);
> > -			txq_stats->tx_normal_irq_n++;
> > -			u64_stats_update_end(&txq_stats->syncp);
> > -			ret |= handle_tx;
> > -		}
> > +	if (likely(intr_status & XGMAC_RI)) {
> > +		u64_stats_update_begin(&rxq_stats->syncp);
> > +		rxq_stats->rx_normal_irq_n++;
> > +		u64_stats_update_end(&rxq_stats->syncp);
> > +		ret |= handle_rx;
> > +	}
> > +
> > +	if (likely(intr_status & (XGMAC_TI | XGMAC_TBU))) {
> > +		u64_stats_update_begin(&txq_stats->syncp);
> > +		txq_stats->tx_normal_irq_n++;
> > +		u64_stats_update_end(&txq_stats->syncp);
> > +		ret |= handle_tx;
> 
> Could you please clarify my comment to the original patch:
> 
> On Fri, Aug 18, 2023 at 20:10:21PM +0300, Serge Semin wrote:
> > Just curious. Is this change really necessary seeing NIS IRQ is
> > unmasked and it is unmasked-OR of the RI/TI/TBU flags in the
> > DMA_CHx_Status register? Moreover based on the HW manual,
> > DMA_CHx_Status reflects raw IRQ flags status except NIS and AIS which
> > are the masked OR of the respective flags. So AFAIU NIS will be set in
> > anyway if you have RI/TI/TBU IRQs enabled.
> 
> -Serge(y)
> 
Thanks for your comment. 
>From my test, NIS bit value is 0 once INTM is set, even with RI/TI flags value is 1. 
This might be the reason why previous patch set had this change.
-Jim
> >  	}
> >
> >  	/* Clear interrupts */
> > --
> > 2.34.1
> >
> >


From othacehe at gnu.org  Fri Dec 29 05:00:58 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Fri, 29 Dec 2023 14:00:58 +0100
Subject: [PATCH v4 2/2] arm64: dts: imx93-var-som: Add Variscite
 VAR-SOM-MX93
In-Reply-To: <d378ad67-2a75-4a14-a131-7eb91de9ad3d@gmx.net> (Stefan Wahren's
	message of "Thu, 28 Dec 2023 21:46:08 +0100")
References: <20231227170919.8771-1-othacehe@gnu.org>
	<20231227170919.8771-3-othacehe@gnu.org>
	<d378ad67-2a75-4a14-a131-7eb91de9ad3d@gmx.net>
Message-ID: <87plypqi2d.fsf@gnu.org>


Hello Stefan,

> there are neither gpio-line-names defined for this GPIO expander nor the
> SOC. Are there no GPIOs which can be accessed from userspace?

The carrier board schematic is here:
https://www.variscite.com/wp-content/uploads/2023/01/symphony-board_VAR-SOM-MX93.pdf

All the pin headers are mapped to specific functions. On the other,
already mainlined device-trees, that are based on the same "Symphony"
carrier board, there are however gpio-keys for three buttons:


	gpio-keys {
		compatible = "gpio-keys";

		key-back {
			label = "Back";
			gpios = <&pca9534 1 GPIO_ACTIVE_LOW>;
			linux,code = <KEY_BACK>;
		};

		key-home {
			label = "Home";
			gpios = <&pca9534 2 GPIO_ACTIVE_LOW>;
			linux,code = <KEY_HOME>;
		};

		key-menu {
			label = "Menu";
			gpios = <&pca9534 3 GPIO_ACTIVE_LOW>;
			linux,code = <KEY_MENU>;
		};
	};

I can add that in v5.

Thanks,

Mathieu


From hardevsinh.palaniya at siliconsignals.io  Fri Dec 29 05:02:07 2023
From: hardevsinh.palaniya at siliconsignals.io (Hardevsinh Palaniya)
Date: Fri, 29 Dec 2023 18:32:07 +0530
Subject: [PATCH] mmc: sdhci-esdhc-imx: Fix smatch errors
Message-ID: <20231229130207.3539334-1-hardevsinh.palaniya@siliconsignals.io>

Resolve smatch errors in esdhc_executing_tuning()

esdhc_executing_tuning() error: uninitialized symbol 'target_min'
esdhc_executing_tuning() error: uninitialized symbol 'target_max'

Signed-off-by: Hardevsinh Palaniya <hardevsinh.palaniya at siliconsignals.io>

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 40a6e2f8145a..839b60138f04 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -1166,6 +1166,8 @@ static int esdhc_executing_tuning(struct sdhci_host *host, u32 opcode)
 	min = ESDHC_TUNE_CTRL_MIN;
 	max = ESDHC_TUNE_CTRL_MIN;
 	target_win_length = 0;
+	target_min = 0;
+	target_max = 0;
 	while (max < ESDHC_TUNE_CTRL_MAX) {
 		/* find the mininum delay first which can pass tuning */
 		while (min < ESDHC_TUNE_CTRL_MAX) {
-- 
2.25.1



From dario.binacchi at amarulasolutions.com  Fri Dec 29 05:51:15 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Fri, 29 Dec 2023 14:51:15 +0100
Subject: [PATCH 0/8] Add display support for stm32f769-disco board
Message-ID: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>

The series adds display support for the stm32f769-disco board. It has been
tested on hardware revisions MB1225-B03 and MB1166-A09. This required
modifications to the nt35510 driver. As I do not have the Hydis HVA40WV1
display, it would be better if someone tested the driver in that
configuration.


Dario Binacchi (8):
  dt-bindings: mfd: stm32f7: Add binding definition for DSI
  ARM: dts: stm32: add DSI support on stm32f769
  ARM: dts: stm32: rename mmc_vcard to vcc-3v3 on stm32f769-disco
  ARM: dts: stm32: add display support on stm32f769-disco
  dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK
  ARM: dts: add stm32f769-disco-mb1225-revb03-mb1166-reva09
  drm/panel: nt35510: refactor panel initialization
  drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK

 .../display/panel/novatek,nt35510.yaml        |  20 +-
 arch/arm/boot/dts/st/Makefile                 |   1 +
 ...f769-disco-mb1225-revb03-mb1166-reva09.dts |  13 +
 arch/arm/boot/dts/st/stm32f769-disco.dts      |  78 +-
 arch/arm/boot/dts/st/stm32f769.dtsi           |  21 +
 drivers/gpu/drm/panel/panel-novatek-nt35510.c | 872 +++++-------------
 include/dt-bindings/mfd/stm32f7-rcc.h         |   1 +
 7 files changed, 362 insertions(+), 644 deletions(-)
 create mode 100644 arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
 create mode 100644 arch/arm/boot/dts/st/stm32f769.dtsi

-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Fri Dec 29 05:51:16 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Fri, 29 Dec 2023 14:51:16 +0100
Subject: [PATCH 1/8] dt-bindings: mfd: stm32f7: Add binding definition for DSI
In-Reply-To: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
References: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231229135154.675946-2-dario.binacchi@amarulasolutions.com>

Add binding definition for MIPI DSI Host controller.

Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>
---

 include/dt-bindings/mfd/stm32f7-rcc.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/mfd/stm32f7-rcc.h b/include/dt-bindings/mfd/stm32f7-rcc.h
index 8d73a9c51e2b..a4e4f9271395 100644
--- a/include/dt-bindings/mfd/stm32f7-rcc.h
+++ b/include/dt-bindings/mfd/stm32f7-rcc.h
@@ -108,6 +108,7 @@
 #define STM32F7_RCC_APB2_SAI1		22
 #define STM32F7_RCC_APB2_SAI2		23
 #define STM32F7_RCC_APB2_LTDC		26
+#define STM32F7_RCC_APB2_DSI		27
 
 #define STM32F7_APB2_RESET(bit)	(STM32F7_RCC_APB2_##bit + (0x24 * 8))
 #define STM32F7_APB2_CLOCK(bit)	(STM32F7_RCC_APB2_##bit + 0xA0)
-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Fri Dec 29 05:51:17 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Fri, 29 Dec 2023 14:51:17 +0100
Subject: [PATCH 2/8] ARM: dts: stm32: add DSI support on stm32f769
In-Reply-To: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
References: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231229135154.675946-3-dario.binacchi@amarulasolutions.com>

Add support for MIPI DSI Host controller. Since MIPI DSI is not
available on stm32f746, the patch adds the "stm32f769.dtsi" file
containing the dsi node inside.

Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>
---

 arch/arm/boot/dts/st/stm32f769.dtsi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 arch/arm/boot/dts/st/stm32f769.dtsi

diff --git a/arch/arm/boot/dts/st/stm32f769.dtsi b/arch/arm/boot/dts/st/stm32f769.dtsi
new file mode 100644
index 000000000000..e09184f7079c
--- /dev/null
+++ b/arch/arm/boot/dts/st/stm32f769.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Dario Binacchi <dario.binacchi at amarulasolutions.com>
+ */
+
+#include "stm32f746.dtsi"
+
+/ {
+	soc {
+		dsi: dsi at 40016c00 {
+			compatible = "st,stm32-dsi";
+			reg = <0x40016c00 0x800>;
+			interrupts = <98>;
+			clocks = <&rcc 1 CLK_F769_DSI>, <&clk_hse>;
+			clock-names = "pclk", "ref";
+			resets = <&rcc STM32F7_APB2_RESET(DSI)>;
+			reset-names = "apb";
+			status = "disabled";
+		};
+	};
+};
-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Fri Dec 29 05:51:18 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Fri, 29 Dec 2023 14:51:18 +0100
Subject: [PATCH 3/8] ARM: dts: stm32: rename mmc_vcard to vcc-3v3 on stm32f769-disco
In-Reply-To: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
References: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231229135154.675946-4-dario.binacchi@amarulasolutions.com>

In the schematics of document UM2033, the power supply for the micro SD
card is the same 3v3 voltage that is used to power other devices on the
board. By generalizing the name of the voltage regulator, it can be
referenced by other nodes in the device tree without creating
misunderstandings.

This patch is preparatory for future developments.

Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>
---

 arch/arm/boot/dts/st/stm32f769-disco.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/st/stm32f769-disco.dts b/arch/arm/boot/dts/st/stm32f769-disco.dts
index 5d12ae25b327..8632bd866272 100644
--- a/arch/arm/boot/dts/st/stm32f769-disco.dts
+++ b/arch/arm/boot/dts/st/stm32f769-disco.dts
@@ -92,9 +92,9 @@ usbotg_hs_phy: usb-phy {
 		clock-names = "main_clk";
 	};
 
-	mmc_vcard: mmc_vcard {
+	vcc_3v3: vcc_3v3 {
 		compatible = "regulator-fixed";
-		regulator-name = "mmc_vcard";
+		regulator-name = "vcc_3v3";
 		regulator-min-microvolt = <3300000>;
 		regulator-max-microvolt = <3300000>;
 	};
@@ -128,7 +128,7 @@ &rtc {
 
 &sdio2 {
 	status = "okay";
-	vmmc-supply = <&mmc_vcard>;
+	vmmc-supply = <&vcc_3v3>;
 	cd-gpios = <&gpioi 15 GPIO_ACTIVE_LOW>;
 	broken-cd;
 	pinctrl-names = "default", "opendrain", "sleep";
-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Fri Dec 29 05:51:19 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Fri, 29 Dec 2023 14:51:19 +0100
Subject: [PATCH 4/8] ARM: dts: stm32: add display support on stm32f769-disco
In-Reply-To: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
References: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231229135154.675946-5-dario.binacchi@amarulasolutions.com>

The patch adds display support on the stm32f769-disco board.

Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>
---

 arch/arm/boot/dts/st/stm32f769-disco.dts | 72 +++++++++++++++++++++++-
 1 file changed, 71 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/st/stm32f769-disco.dts b/arch/arm/boot/dts/st/stm32f769-disco.dts
index 8632bd866272..d1eb5f9c78bf 100644
--- a/arch/arm/boot/dts/st/stm32f769-disco.dts
+++ b/arch/arm/boot/dts/st/stm32f769-disco.dts
@@ -41,7 +41,7 @@
  */
 
 /dts-v1/;
-#include "stm32f746.dtsi"
+#include "stm32f769.dtsi"
 #include "stm32f769-pinctrl.dtsi"
 #include <dt-bindings/input/input.h>
 #include <dt-bindings/gpio/gpio.h>
@@ -60,6 +60,19 @@ memory at c0000000 {
 		reg = <0xC0000000 0x1000000>;
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		linux,dma {
+			compatible = "shared-dma-pool";
+			linux,dma-default;
+			no-map;
+			size = <0x100000>;
+		};
+	};
+
 	aliases {
 		serial0 = &usart1;
 	};
@@ -85,6 +98,13 @@ button-0 {
 		};
 	};
 
+	panel_backlight: panel-backlight {
+		compatible = "gpio-backlight";
+		gpios = <&gpioi 14 GPIO_ACTIVE_HIGH>;
+		default-on;
+		status = "okay";
+	};
+
 	usbotg_hs_phy: usb-phy {
 		#phy-cells = <0>;
 		compatible = "usb-nop-xceiv";
@@ -114,6 +134,46 @@ &clk_hse {
 	clock-frequency = <25000000>;
 };
 
+&dsi {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port at 0 {
+			reg = <0>;
+			dsi_in: endpoint {
+				remote-endpoint = <&ltdc_out_dsi>;
+			};
+		};
+
+		port at 1 {
+			reg = <1>;
+			dsi_out: endpoint {
+				remote-endpoint = <&dsi_panel_in>;
+			};
+		};
+	};
+
+	panel0: panel-dsi at 0 {
+		compatible = "orisetech,otm8009a";
+		reg = <0>; /* dsi virtual channel (0..3) */
+		reset-gpios = <&gpioj 15 GPIO_ACTIVE_LOW>;
+		power-supply = <&vcc_3v3>;
+		backlight = <&panel_backlight>;
+		status = "okay";
+
+		port {
+			dsi_panel_in: endpoint {
+				remote-endpoint = <&dsi_out>;
+			};
+		};
+	};
+};
+
 &i2c1 {
 	pinctrl-0 = <&i2c1_pins_b>;
 	pinctrl-names = "default";
@@ -122,6 +182,16 @@ &i2c1 {
 	status = "okay";
 };
 
+&ltdc {
+	status = "okay";
+
+	port {
+		ltdc_out_dsi: endpoint at 0 {
+			remote-endpoint = <&dsi_in>;
+		};
+	};
+};
+
 &rtc {
 	status = "okay";
 };
-- 
2.43.0



From dario.binacchi at amarulasolutions.com  Fri Dec 29 05:51:21 2023
From: dario.binacchi at amarulasolutions.com (Dario Binacchi)
Date: Fri, 29 Dec 2023 14:51:21 +0100
Subject: [PATCH 6/8] ARM: dts: add stm32f769-disco-mb1225-revb03-mb1166-reva09
In-Reply-To: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
References: <20231229135154.675946-1-dario.binacchi@amarulasolutions.com>
Message-ID: <20231229135154.675946-7-dario.binacchi@amarulasolutions.com>

As reported in the section 8.3 (i. e. Board revision history) of document
UM2033 (i. e. Discovery kit with STM32F769NI MCU) these are the changes
related to the board revisions addressed by the patch:
- Board MB1225 revision B-03:
  - Memory MICRON MT48LC4M32B2B5-6A replaced by ISSI IS42S32400F-6BL
- Board MB1166 revision A-09:
  - LCD FRIDA FRD397B25009-D-CTK replaced by FRIDA FRD400B25025-A-CTK

The patch only adds the DTS support for the new display which belongs to
to the Novatek NT35510-based panel family.

Signed-off-by: Dario Binacchi <dario.binacchi at amarulasolutions.com>
---

 arch/arm/boot/dts/st/Makefile                       |  1 +
 .../stm32f769-disco-mb1225-revb03-mb1166-reva09.dts | 13 +++++++++++++
 2 files changed, 14 insertions(+)
 create mode 100644 arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts

diff --git a/arch/arm/boot/dts/st/Makefile b/arch/arm/boot/dts/st/Makefile
index 7892ad69b441..390dbd300a57 100644
--- a/arch/arm/boot/dts/st/Makefile
+++ b/arch/arm/boot/dts/st/Makefile
@@ -23,6 +23,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
 	stm32f469-disco.dtb \
 	stm32f746-disco.dtb \
 	stm32f769-disco.dtb \
+	stm32f769-disco-mb1225-revb03-mb1166-reva09.dts \
 	stm32429i-eval.dtb \
 	stm32746g-eval.dtb \
 	stm32h743i-eval.dtb \
diff --git a/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts b/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
new file mode 100644
index 000000000000..ff7ff32371d0
--- /dev/null
+++ b/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Dario Binacchi <dario.binacchi at amarulasolutions.com>
+ */
+
+#include "stm32f769-disco.dts"
+
+&panel0 {
+	compatible = "frida,frd400b25025", "novatek,nt35510";
+	vddi-supply = <&vcc_3v3>;
+	vdd-supply = <&vcc_3v3>;
+	/delete-property/power-supply;
+};
-- 
2.43.0



From wahrenst at gmx.net  Fri Dec 29 06:08:02 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Fri, 29 Dec 2023 15:08:02 +0100
Subject: [PATCH v4 2/2] arm64: dts: imx93-var-som: Add Variscite
 VAR-SOM-MX93
In-Reply-To: <87plypqi2d.fsf@gnu.org>
References: <20231227170919.8771-1-othacehe@gnu.org>
 <20231227170919.8771-3-othacehe@gnu.org>
 <d378ad67-2a75-4a14-a131-7eb91de9ad3d@gmx.net> <87plypqi2d.fsf@gnu.org>
Message-ID: <4e3a0328-0ae7-40fa-b37d-16b661e28a1e@gmx.net>

Hi Mathieu,

Am 29.12.23 um 14:00 schrieb Mathieu Othacehe:
> Hello Stefan,
>
>> there are neither gpio-line-names defined for this GPIO expander nor the
>> SOC. Are there no GPIOs which can be accessed from userspace?
> The carrier board schematic is here:
> https://www.variscite.com/wp-content/uploads/2023/01/symphony-board_VAR-SOM-MX93.pdf
Thanks this helps.
>
> All the pin headers are mapped to specific functions. On the other,
> already mainlined device-trees, that are based on the same "Symphony"
> carrier board, there are however gpio-keys for three buttons:
>
>
> 	gpio-keys {
> 		compatible = "gpio-keys";
>
> 		key-back {
> 			label = "Back";
> 			gpios = <&pca9534 1 GPIO_ACTIVE_LOW>;
> 			linux,code = <KEY_BACK>;
> 		};
>
> 		key-home {
> 			label = "Home";
> 			gpios = <&pca9534 2 GPIO_ACTIVE_LOW>;
> 			linux,code = <KEY_HOME>;
> 		};
>
> 		key-menu {
> 			label = "Menu";
> 			gpios = <&pca9534 3 GPIO_ACTIVE_LOW>;
> 			linux,code = <KEY_MENU>;
> 		};
> 	};
>
> I can add that in v5.
yes please.

I also saw in the other Symphony DTS a LED for heartbeat. Is it usable, too?

According to the datasheet the SOM expose 7 UARTs, but only the debug
UART is enable. What is the reason for this?

Btw the commit log mentions a Wifi (via SDIO?) and audio interface. This
is currently not supported by Linux?

Thanks
>
> Thanks,
>
> Mathieu



From tudor.ambarus at linaro.org  Fri Dec 29 06:21:29 2023
From: tudor.ambarus at linaro.org (Tudor Ambarus)
Date: Fri, 29 Dec 2023 14:21:29 +0000
Subject: [PATCH v2 11/12] arm64: dts: exynos: gs101: define USI8 with I2C
 configuration
In-Reply-To: <387303b4-d912-480c-a50c-9f9efa386ef3@linaro.org>
References: <20231228125805.661725-1-tudor.ambarus@linaro.org>
 <20231228125805.661725-12-tudor.ambarus@linaro.org>
 <a40b5d0dc3e151fede14aa00bcb853d1eeb8824b.camel@linaro.org>
 <387303b4-d912-480c-a50c-9f9efa386ef3@linaro.org>
Message-ID: <d1b17379-84b0-465b-a30c-1a1e62d3c86a@linaro.org>



On 12/29/23 08:04, Tudor Ambarus wrote:
> 
> 
> On 12/28/23 14:04, Andr? Draszik wrote:
>> Hi Tudor,
> 
> Hi!
> 
>>
>> On Thu, 2023-12-28 at 12:58 +0000, Tudor Ambarus wrote:
>>> [...]
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>> index 0e5b1b490b0b..c6ae33016992 100644
>>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>>> @@ -354,6 +354,35 @@ pinctrl_peric0: pinctrl at 10840000 {
>>> ?			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
>>> ?		};
>>> ?
>>> +		usi8: usi at 109700c0 {
>>> +			compatible = "google,gs101-usi",
>>> +				???? "samsung,exynos850-usi";
>>> +			reg = <0x109700c0 0x20>;
>>> +			ranges;
>>> +			#address-cells = <1>;
>>> +			#size-cells = <1>;
>>> +			clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>,
>>> +				 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
>>> +			clock-names = "pclk", "ipclk";
>>
>> Given the clock-names, shouldn't the clock indices be the other way around? Also see below.
> 
> You're right, they should have been the other way around! Didn't make
> any difference at testing because the usi driver uses
> clk_bulk_prepare_enable(), what matters is the order of clocks in the
> i2c node, and those are fine.
> 
>>
>>> +			samsung,sysreg = <&sysreg_peric0 0x101c>;
>>> +			status = "disabled";
>>> +
>>> +			hsi2c_8: i2c at 10970000 {
>>> +				compatible = "google,gs101-hsi2c",
>>> +					???? "samsung,exynosautov9-hsi2c";
>>> +				reg = <0x10970000 0xc0>;
>>> +				interrupts = <GIC_SPI 642 IRQ_TYPE_LEVEL_HIGH 0>;
>>> +				#address-cells = <1>;
>>> +				#size-cells = <0>;
>>> +				pinctrl-names = "default";
>>> +				pinctrl-0 = <&hsi2c8_bus>;
>>> +				clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>,
>>> +					 <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
>>> +				clock-names = "hsi2c", "hsi2c_pclk";
>>
>> Here, pclk == CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK (which is correct, I believe), whereas
>> above pclk == CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7
>>
> 
> Indeed, I'll reverse the order for the USI clocks and do some more
> testing. Thanks!

FYI, I reversed the order of the USI clocks, tested again with the
eeprom at 100 KHz and 10KHz, everything went fine. I'll wait for some
other feedback and probably submit a v3 next week.

Cheers,
ta


From wahrenst at gmx.net  Fri Dec 29 06:34:57 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Fri, 29 Dec 2023 15:34:57 +0100
Subject: [PATCH] mmc: sdhci-esdhc-imx: Fix smatch errors
In-Reply-To: <20231229130207.3539334-1-hardevsinh.palaniya@siliconsignals.io>
References: <20231229130207.3539334-1-hardevsinh.palaniya@siliconsignals.io>
Message-ID: <838abf56-e2b1-474b-977a-8671a31053ed@gmx.net>

Hi Hardevsinh,

the patch subject is a too generic. Maybe something like "fix
initialization of target_min/max"

Am 29.12.23 um 14:02 schrieb Hardevsinh Palaniya:
> Resolve smatch errors in esdhc_executing_tuning()
>
> esdhc_executing_tuning() error: uninitialized symbol 'target_min'
> esdhc_executing_tuning() error: uninitialized symbol 'target_max'
I think this deserve

Fixes: 541a95e64d76 ("mmc: sdhci-esdhc-imx: optimize the manual tuing
logic to get the best timing")

Thanks
> Signed-off-by: Hardevsinh Palaniya <hardevsinh.palaniya at siliconsignals.io>
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
> index 40a6e2f8145a..839b60138f04 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -1166,6 +1166,8 @@ static int esdhc_executing_tuning(struct sdhci_host *host, u32 opcode)
>   	min = ESDHC_TUNE_CTRL_MIN;
>   	max = ESDHC_TUNE_CTRL_MIN;
>   	target_win_length = 0;
> +	target_min = 0;
> +	target_max = 0;
>   	while (max < ESDHC_TUNE_CTRL_MAX) {
>   		/* find the mininum delay first which can pass tuning */
>   		while (min < ESDHC_TUNE_CTRL_MAX) {



From ilpo.jarvinen at linux.intel.com  Fri Dec 29 06:52:32 2023
From: ilpo.jarvinen at linux.intel.com (=?UTF-8?q?Ilpo=20J=C3=A4rvinen?=)
Date: Fri, 29 Dec 2023 16:52:32 +0200
Subject: [PATCH 1/1] net: mdio: mux-bcm-iproc: Use alignment helpers and SZ_4K
Message-ID: <20231229145232.6163-1-ilpo.jarvinen@linux.intel.com>

Instead of open coding, use IS_ALIGNED() and ALIGN_DOWN() when dealing
with alignment. Replace also literals with SZ_4K.

Signed-off-by: Ilpo J?rvinen <ilpo.jarvinen at linux.intel.com>
---
 drivers/net/mdio/mdio-mux-bcm-iproc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mdio/mdio-mux-bcm-iproc.c b/drivers/net/mdio/mdio-mux-bcm-iproc.c
index a750bd4c77a0..1ce7d67ba72e 100644
--- a/drivers/net/mdio/mdio-mux-bcm-iproc.c
+++ b/drivers/net/mdio/mdio-mux-bcm-iproc.c
@@ -2,6 +2,7 @@
 /*
  * Copyright 2016 Broadcom
  */
+#include <linux/align.h>
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/device.h>
@@ -11,6 +12,7 @@
 #include <linux/of_mdio.h>
 #include <linux/phy.h>
 #include <linux/platform_device.h>
+#include <linux/sizes.h>
 
 #define MDIO_RATE_ADJ_EXT_OFFSET	0x000
 #define MDIO_RATE_ADJ_INT_OFFSET	0x004
@@ -220,12 +222,12 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
 	md->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
 	if (IS_ERR(md->base))
 		return PTR_ERR(md->base);
-	if (res->start & 0xfff) {
+	if (!IS_ALIGNED(res->start, SZ_4K)) {
 		/* For backward compatibility in case the
 		 * base address is specified with an offset.
 		 */
 		dev_info(&pdev->dev, "fix base address in dt-blob\n");
-		res->start &= ~0xfff;
+		res->start = ALIGN_DOWN(res->start, SZ_4K);
 		res->end = res->start + MDIO_REG_ADDR_SPACE_SIZE - 1;
 	}
 
-- 
2.39.2



From neal at gompa.dev  Fri Dec 29 07:11:32 2023
From: neal at gompa.dev (Neal Gompa)
Date: Fri, 29 Dec 2023 10:11:32 -0500
Subject: [PATCH] Bluetooth: hci_bcm4377: do not mark valid bd_addr as invalid
In-Reply-To: <20231227101003.10534-1-johan+linaro@kernel.org>
References: <20231227101003.10534-1-johan+linaro@kernel.org>
Message-ID: <CAEg-Je-WJZGMgurcQY3p9wQffEJmN3OsiK_9ictsFV3uTGdS9g@mail.gmail.com>

On Wed, Dec 27, 2023 at 5:10?AM Johan Hovold <johan+linaro at kernel.org> wrote:
>
> A recent commit restored the original (and still documented) semantics
> for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device address
> is considered invalid unless an address is provided by firmware.
>
> This specifically means that this flag must only be set for devices with
> invalid addresses, but the Broadcom BCM4377 driver has so far been
> setting this flag unconditionally.
>
> Fortunately the driver already checks for invalid addresses during setup
> and sets the HCI_QUIRK_INVALID_BDADDR flag, which can simply be replaced
> with HCI_QUIRK_USE_BDADDR_PROPERTY to indicate that the default address
> is invalid but can be overridden by firmware (long term, this should
> probably just always be allowed).
>
> Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk")
> Cc: stable at vger.kernel.org      # 6.5
> Reported-by: Felix Zhang <mrman at mrman314.tech>
> Link: https://lore.kernel.org/r/77419ffacc5b4875e920e038332575a2a5bff29f.camel at mrman314.tech/
> Signed-off-by: Johan Hovold <johan+linaro at kernel.org>
> ---
>  drivers/bluetooth/hci_bcm4377.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
> index a61757835695..9a7243d5db71 100644
> --- a/drivers/bluetooth/hci_bcm4377.c
> +++ b/drivers/bluetooth/hci_bcm4377.c
> @@ -1417,7 +1417,7 @@ static int bcm4377_check_bdaddr(struct bcm4377_data *bcm4377)
>
>         bda = (struct hci_rp_read_bd_addr *)skb->data;
>         if (!bcm4377_is_valid_bdaddr(bcm4377, &bda->bdaddr))
> -               set_bit(HCI_QUIRK_INVALID_BDADDR, &bcm4377->hdev->quirks);
> +               set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &bcm4377->hdev->quirks);
>
>         kfree_skb(skb);
>         return 0;
> @@ -2368,7 +2368,6 @@ static int bcm4377_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>         hdev->set_bdaddr = bcm4377_hci_set_bdaddr;
>         hdev->setup = bcm4377_hci_setup;
>
> -       set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
>         if (bcm4377->hw->broken_mws_transport_config)
>                 set_bit(HCI_QUIRK_BROKEN_MWS_TRANSPORT_CONFIG, &hdev->quirks);
>         if (bcm4377->hw->broken_ext_scan)
> --
> 2.41.0
>
>

Looks good to me. This replaces the other patch[1], I take it?

Reviewed-by: Neal Gompa <neal at gompa.dev>

[1]: https://lore.kernel.org/asahi/aaa107865f4cbd61f8f9006fd3e7ac43b5d1bdad.camel at mrman314.tech/

-- 
?????????/ Always, there's only one truth!


From olteanv at gmail.com  Fri Dec 29 07:25:19 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Fri, 29 Dec 2023 17:25:19 +0200
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <CAMty3ZDnAFR9a1BM89mx3bmrQzGC7nvazt42_v4JF_QpwPkS4w@mail.gmail.com>
 <CAMty3ZDnAFR9a1BM89mx3bmrQzGC7nvazt42_v4JF_QpwPkS4w@mail.gmail.com>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf>
 <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
 <20231226153055.4yihsmu6kiak6hkf@skbuf>
 <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf>
 <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
 <20231226153055.4yihsmu6kiak6hkf@skbuf>
 <CAMty3ZDnAFR9a1BM89mx3bmrQzGC7nvazt42_v4JF_QpwPkS4w@mail.gmail.com>
 <CAMty3ZDnAFR9a1BM89mx3bmrQzGC7nvazt42_v4JF_QpwPkS4w@mail.gmail.com>
Message-ID: <20231229152519.2jxrwaeltp4pxlms@skbuf>

On Fri, Dec 29, 2023 at 05:12:39PM +0530, Jagan Teki wrote:
> With fec0 fixed-link and 3 different switch port configurations, the
> result of the link seems to be up but the ping not working and even
> the packets are not transmitted via eth0.
> 
> DT Combinations:
> 
> - Port0 is ethphy0, Port1 is ethphy1, Port2 is disabled, Port3 is
> disabled, Port4 is FEC
> - Port0 is disabled, Port1 is ethphy0, Port2 is ethphy1, Port3 is
> disabled, Port4 is FEC
> - Port0 is disabled, Port1 is disabled, Port2 is ethphy0, Port3 is
> ethphy1, Port4 as FEC

Why all these combinations? You don't know which switch port is which?

> DT: (with Port0 is ethphy0, Port1 is ethphy1, Port2 is disabled, Port3
> is disabled, Port4 is FEC)
> 
> &ecspi2 {
>     cs-gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
>     pinctrl-names = "default";
>     pinctrl-0 = <&pinctrl_ecspi2>;
>     status = "okay";
> 
>     switch at 0 {
>         compatible = "nxp,sja1105q";
>         reg = <0>;
>         spi-max-frequency = <4000000>;
>         spi-rx-delay-us = <1>;
>         spi-tx-delay-us = <1>;
>         spi-cpha;
> 
>        clocks = <&clk25m>;
> 
>        pinctrl-0 = <&pinctrl_sja1105_rst>;
>        pinctrl-names = "default";
>        reset-gpios = <&gpio6 5 GPIO_ACTIVE_LOW>;
> 
>        ports {
>               #address-cells = <1>;
>               #size-cells = <0>;
> 
>              port at 0 {
>                   reg = <0>;
>                   label = "ethphy0";
>                   phy-handle = <&ethphy0>;
>                   phy-mode = "mii";
>             };
> 
>             port at 1 {
>                  reg = <1>;
>                  label = "ethphy1";
>                  phy-handle = <&ethphy1>;
>                  phy-mode = "mii";
>            };
> 
>            port at 2 {
>                 reg = <2>;
>                 status = "disabled";
>            };
> 
>             port at 3 {
>                  reg = <3>;
>                  status = "disabled";
>            };
> 
>            port at 4 {
>                 reg = <4>;
>                 label = "cpu";
>                 ethernet = <&fec>;
>                 phy-mode = "mii";
>                 rx-internal-delay-ps = <2000>;
>                 tx-internal-delay-ps = <2000>;

This looks suspicious. "rx-internal-delay-ps" and "tx-internal-delay-ps"
are only relevant for the RGMII modes, but you specify phy-mode = "mii".
Does the board schematic confirm that MII is the physical connection
being used from the switch to the FEC?

If you are truly using MII, then you should remove the RGMII delay
properties, and since you are using a 6.1 kernel - hence after kernel
commit 5d645df99ac6 ("net: dsa: sja1105: determine PHY/MAC role from PHY
interface type") - you should be using phy-mode = "rev-mii" to put this
port in MII PHY ("RevMII") mode - to interoperate with the FEC in MII
MAC mode.

> 
>                fixed-link {
>                    speed = <100>;
>                    full-duplex;
>                };
>             };
>           };
>      };
> };
> 
> &fec {
>        pinctrl-names = "default";
>        pinctrl-0 = <&pinctrl_enet>;
>        phy-mode = "mii";
>        status = "okay";
> 
>        fixed-link {
>           speed = <100>;
>           full-duplex;
>        };
> 
>        mdio {
>             #address-cells = <1>;
>             #size-cells = <0>;
> 
>             ethphy0: ethernet-phy at 0 {
>                     compatible = "ethernet-phy-ieee802.3-c22";
>                     reg = <0>;
>             };
> 
>            ethphy1: ethernet-phy at 1 {
>                compatible = "ethernet-phy-ieee802.3-c22";
>                 reg = <1>;
>             };
>     };
> };
> 
> root at ltts-imx6solo:~# bash /usr/phynew.sh
> ======= MDIO: PHY0 ========
> [  162.426515] mdio_netlink: loading out-of-tree module taints kernel.

Still, please refrain from involving out-of-tree modules when asking for
help upstream. Thanks.

> root at ltts-imx6solo:~# [  165.208656] sja1105 spi1.0 ethphy0: Link is
> Up - 100Mbps/Full - flow control off
> [  165.225788] sja1105 spi1.0 ethphy1: Link is Up - 100Mbps/Full -
> flow control off
> [  165.235925] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy0: link becomes ready
> [  165.255777] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy1: link becomes ready
> 
> root at ltts-imx6solo:~# ifconfig
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1504
>         inet6 fe80::68fb:8ff:fedf:d377  prefixlen 64  scopeid 0x20<link>
>         ether 6a:fb:08:df:d3:77  txqueuelen 1000  (Ethernet)
>         RX packets 0  bytes 0 (0.0 B)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 0  bytes 0 (0.0 B)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> ethphy0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet 169.254.178.1  netmask 255.255.0.0  broadcast 0.0.0.0
>         inet6 fe80::211:22ff:fe33:4455  prefixlen 64  scopeid 0x20<link>
>         ether 00:11:22:33:44:55  txqueuelen 1000  (Ethernet)
>         RX packets 0  bytes 0 (0.0 B)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 30  bytes 4071 (3.9 KiB)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> ethphy1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet 169.253.178.2  netmask 255.255.0.0  broadcast 0.0.0.0
>         inet6 fe80::211:22ff:fe33:4466  prefixlen 64  scopeid 0x20<link>
>         ether 00:11:22:33:44:66  txqueuelen 1000  (Ethernet)
>         RX packets 0  bytes 0 (0.0 B)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 30  bytes 4071 (3.9 KiB)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
>         inet 127.0.0.1  netmask 255.0.0.0
>         inet6 ::1  prefixlen 128  scopeid 0x10<host>
>         loop  txqueuelen 1000  (Local Loopback)
>         RX packets 89  bytes 7675 (7.4 KiB)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 89  bytes 7675 (7.4 KiB)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ifconfig reports statistics counters from the /proc/net/dev interface,
which the sja1105 does not report very well (they don't come from hardware).
It's best to use "ethtool -S eth0 | grep -v ': 0'" for FEC and SJA1105
CPU port (named "p04_*") counters, and "ethtool -S ethphy0 | grep -v ': 0'"
to get hardware counters from the switch user ports.

You can also use the RX counters to determine which switch port is which
(but the phy-handle of each port to each PHY needs to be correct).

> mytsl02383 at MYTSL02383:~$ ifconfig -a
> enp43s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet 169.254.178.2  netmask 255.255.0.0  broadcast 169.254.255.255
>         inet6 fe80::d71b:4bdd:27bd:2a1a  prefixlen 64  scopeid 0x20<link>
>         ether 00:be:43:20:9a:26  txqueuelen 1000  (Ethernet)
>         RX packets 272356  bytes 27099064 (27.0 MB)
>         RX errors 0  dropped 19  overruns 0  frame 0
>         TX packets 862  bytes 300806 (300.8 KB)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> mytsl02383 at MYTSL02383:~$ ping 169.254.178.1
> PING 169.254.178.1 (169.254.178.1) 56(84) bytes of data.
> From 169.254.178.2 icmp_seq=1 Destination Host Unreachable
> 
> Let me know if you need any more details.

I'm not convinced packets are routed through ethphy0 or ethphy1, since
all interfaces have IPv4 link-local addresses only. You can use
"ip route get 169.254.178.1" to confirm what interface gets chosen.
This is not indicative of a device-level problem, just a setup one.
Please set up some IPv4 static addresses which are not link-local on the
DSA user ports and try to ping a link partner which has an IP address in
the same subnet.


From jbx6244 at gmail.com  Fri Dec 29 07:47:59 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 29 Dec 2023 16:47:59 +0100
Subject: [PATCH v3 1/2] ARM: dts: rockchip: add gpio-ranges property to
 gpio nodes
In-Reply-To: <541b7633-af3b-4392-ac29-7ee1f2c6f943@kwiboo.se>
References: <cf46c685-bf4b-63b5-0373-dd0ba70e9700@gmail.com>
 <541b7633-af3b-4392-ac29-7ee1f2c6f943@kwiboo.se>
Message-ID: <396abf33-567c-b020-b12d-ee1cd7eca836@gmail.com>

Hi Jonas,

On 12/28/23 17:30, Jonas Karlman wrote:
> Hi Johan,
> 
> On 2023-12-27 19:33, Johan Jonker wrote:
>> Add a gpio-ranges property to Rockchip gpio nodes similar to
>> rk356x/rk3588 to be independent from aliases and probe order.
>>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>> Reviewed-by: Kever Yang <kever.yang at rock-chips.com>
>> ---
>>
>> Changed V3:
>>   reword
>>   rebase to new Rockchip directory
>>   remove unknown properties
>> ---
>>  arch/arm/boot/dts/rockchip/rk3036.dtsi  | 3 +++
>>  arch/arm/boot/dts/rockchip/rk3066a.dtsi | 6 ++++++
>>  arch/arm/boot/dts/rockchip/rk3128.dtsi  | 4 ++++
>>  arch/arm/boot/dts/rockchip/rk3188.dtsi  | 4 ++++
>>  arch/arm/boot/dts/rockchip/rk322x.dtsi  | 4 ++++
>>  arch/arm/boot/dts/rockchip/rk3288.dtsi  | 9 +++++++++
>>  arch/arm/boot/dts/rockchip/rv1108.dtsi  | 4 ++++
>>  arch/arm/boot/dts/rockchip/rv1126.dtsi  | 5 +++++
>>  8 files changed, 39 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> index 2b00109bea6a..6e5028b6dbfa 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>> @@ -593,6 +593,7 @@ gpio0: gpio at 2007c000 {
>>  			clocks = <&cru PCLK_GPIO0>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -606,6 +607,7 @@ gpio1: gpio at 20080000 {
>>  			clocks = <&cru PCLK_GPIO1>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -619,6 +621,7 @@ gpio2: gpio at 20084000 {
>>  			clocks = <&cru PCLK_GPIO2>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> diff --git a/arch/arm/boot/dts/rockchip/rk3066a.dtsi b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
>> index 30139f21de64..a4962b6b3f4c 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
>> @@ -285,6 +285,7 @@ gpio0: gpio at 20034000 {
>>  			clocks = <&cru PCLK_GPIO0>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -298,6 +299,7 @@ gpio1: gpio at 2003c000 {
>>  			clocks = <&cru PCLK_GPIO1>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -311,6 +313,7 @@ gpio2: gpio at 2003e000 {
>>  			clocks = <&cru PCLK_GPIO2>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -324,6 +327,7 @@ gpio3: gpio at 20080000 {
>>  			clocks = <&cru PCLK_GPIO3>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -337,6 +341,7 @@ gpio4: gpio at 20084000 {
>>  			clocks = <&cru PCLK_GPIO4>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 128 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -350,6 +355,7 @@ gpio6: gpio at 2000a000 {
>>  			clocks = <&cru PCLK_GPIO6>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 192 32>;
> 

> It does not look like this matches what pins the pinctrl driver expose
> for rk3066a. Something like <&pinctrl 0 160 16> would probably be more
> correct.

See comment below.

> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>> index e2264c40b924..d66fcf12032e 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>> @@ -712,6 +712,7 @@ gpio0: gpio at 2007c000 {
>>  			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>>  			clocks = <&cru PCLK_GPIO0>;
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>  			#gpio-cells = <2>;
>>  			interrupt-controller;
>>  			#interrupt-cells = <2>;
>> @@ -723,6 +724,7 @@ gpio1: gpio at 20080000 {
>>  			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
>>  			clocks = <&cru PCLK_GPIO1>;
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>  			#gpio-cells = <2>;
>>  			interrupt-controller;
>>  			#interrupt-cells = <2>;
>> @@ -734,6 +736,7 @@ gpio2: gpio at 20084000 {
>>  			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
>>  			clocks = <&cru PCLK_GPIO2>;
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>  			#gpio-cells = <2>;
>>  			interrupt-controller;
>>  			#interrupt-cells = <2>;
>> @@ -745,6 +748,7 @@ gpio3: gpio at 20088000 {
>>  			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>>  			clocks = <&cru PCLK_GPIO3>;
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>  			#gpio-cells = <2>;
>>  			interrupt-controller;
>>  			#interrupt-cells = <2>;
>> diff --git a/arch/arm/boot/dts/rockchip/rk3188.dtsi b/arch/arm/boot/dts/rockchip/rk3188.dtsi
>> index 44b54af0bbf9..6677e4a10e5d 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3188.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3188.dtsi
>> @@ -231,6 +231,7 @@ gpio0: gpio at 2000a000 {
>>  			clocks = <&cru PCLK_GPIO0>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -244,6 +245,7 @@ gpio1: gpio at 2003c000 {
>>  			clocks = <&cru PCLK_GPIO1>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -257,6 +259,7 @@ gpio2: gpio at 2003e000 {
>>  			clocks = <&cru PCLK_GPIO2>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -270,6 +273,7 @@ gpio3: gpio at 20080000 {
>>  			clocks = <&cru PCLK_GPIO3>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi b/arch/arm/boot/dts/rockchip/rk322x.dtsi
>> index 831561fc1814..0d4f9957b99b 100644
>> --- a/arch/arm/boot/dts/rockchip/rk322x.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk322x.dtsi
>> @@ -959,6 +959,7 @@ gpio0: gpio at 11110000 {
>>  			clocks = <&cru PCLK_GPIO0>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -972,6 +973,7 @@ gpio1: gpio at 11120000 {
>>  			clocks = <&cru PCLK_GPIO1>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -985,6 +987,7 @@ gpio2: gpio at 11130000 {
>>  			clocks = <&cru PCLK_GPIO2>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -998,6 +1001,7 @@ gpio3: gpio at 11140000 {
>>  			clocks = <&cru PCLK_GPIO3>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi b/arch/arm/boot/dts/rockchip/rk3288.dtsi
>> index ead343dc3df1..c5550aae4ed8 100644
>> --- a/arch/arm/boot/dts/rockchip/rk3288.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rk3288.dtsi
>> @@ -1461,6 +1461,7 @@ gpio0: gpio at ff750000 {
>>  			clocks = <&cru PCLK_GPIO0>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 0 32>;
> 
> The pinctrl driver for rk3288 only expose 24 pins for the first bank,
> correct range would probably be <&pinctrl 0 0 24> here,
> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -1474,6 +1475,7 @@ gpio1: gpio at ff780000 {
>>  			clocks = <&cru PCLK_GPIO1>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 32 32>;
> 

> and correct range would probably be <&pinctrl 0 24 32> here,

Random gpio offset ranges for a gpio bank of the various Rockchip SoCs makes it impossible to easy link gpio to pinctrl and vica versa in a standard way without additional Rockchip specific node properties.
To keep things simple the gpio-range for a gpio bank must always be inside to same multiple of 32 for all Rockchip SoCs in relation to the pinctrl.
A "rockchip,pins" property always must have the same "gpio-ranges" set.

Johan

> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -1487,6 +1489,7 @@ gpio2: gpio at ff790000 {
>>  			clocks = <&cru PCLK_GPIO2>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 64 32>;
> 
> and <&pinctrl 0 56 32> here,
> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -1500,6 +1503,7 @@ gpio3: gpio at ff7a0000 {
>>  			clocks = <&cru PCLK_GPIO3>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 96 32>;
> 
> and <&pinctrl 0 88 32> here,
> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -1513,6 +1517,7 @@ gpio4: gpio at ff7b0000 {
>>  			clocks = <&cru PCLK_GPIO4>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 128 32>;
> 
> and <&pinctrl 0 120 32> here,
> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -1526,6 +1531,7 @@ gpio5: gpio at ff7c0000 {
>>  			clocks = <&cru PCLK_GPIO5>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 160 32>;
> 
> and <&pinctrl 0 152 32> here,
> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -1539,6 +1545,7 @@ gpio6: gpio at ff7d0000 {
>>  			clocks = <&cru PCLK_GPIO6>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 192 32>;
> 
> and <&pinctrl 0 184 32> here,
> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -1552,6 +1559,7 @@ gpio7: gpio at ff7e0000 {
>>  			clocks = <&cru PCLK_GPIO7>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 224 32>;
> 
> and <&pinctrl 0 216 32> here,
> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -1565,6 +1573,7 @@ gpio8: gpio at ff7f0000 {
>>  			clocks = <&cru PCLK_GPIO8>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 256 32>;
> 
> and bank num 8 only expose 16 pins, so <&pinctrl 0 248 16> here.
> 
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> diff --git a/arch/arm/boot/dts/rockchip/rv1108.dtsi b/arch/arm/boot/dts/rockchip/rv1108.dtsi
>> index abf3006f0a84..d12b97ee7588 100644
>> --- a/arch/arm/boot/dts/rockchip/rv1108.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rv1108.dtsi
>> @@ -602,6 +602,7 @@ gpio0: gpio at 20030000 {
>>  			clocks = <&cru PCLK_GPIO0_PMU>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -615,6 +616,7 @@ gpio1: gpio at 10310000 {
>>  			clocks = <&cru PCLK_GPIO1>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -628,6 +630,7 @@ gpio2: gpio at 10320000 {
>>  			clocks = <&cru PCLK_GPIO2>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> @@ -641,6 +644,7 @@ gpio3: gpio at 10330000 {
>>  			clocks = <&cru PCLK_GPIO3>;
>>
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>  			#gpio-cells = <2>;
>>
>>  			interrupt-controller;
>> diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
>> index bb603cae13df..71d091af6395 100644
>> --- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
>> +++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
>> @@ -569,6 +569,7 @@ gpio0: gpio at ff460000 {
>>  			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
>>  			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>  			#gpio-cells = <2>;
>>  			interrupt-controller;
>>  			#interrupt-cells = <2>;
>> @@ -580,6 +581,7 @@ gpio1: gpio at ff620000 {
>>  			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
>>  			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>  			#gpio-cells = <2>;
>>  			interrupt-controller;
>>  			#interrupt-cells = <2>;
>> @@ -591,6 +593,7 @@ gpio2: gpio at ff630000 {
>>  			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>>  			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>  			#gpio-cells = <2>;
>>  			interrupt-controller;
>>  			#interrupt-cells = <2>;
>> @@ -602,6 +605,7 @@ gpio3: gpio at ff640000 {
>>  			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
>>  			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>  			#gpio-cells = <2>;
>>  			interrupt-controller;
>>  			#interrupt-cells = <2>;
>> @@ -613,6 +617,7 @@ gpio4: gpio at ff650000 {
>>  			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
>>  			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
>>  			gpio-controller;
>> +			gpio-ranges = <&pinctrl 0 128 32>;
> 
> Bank num 4 only expose 2 pins, so should probably be <&pinctrl 0 128 2>.
> 
> Regards,
> Jonas
> 
>>  			#gpio-cells = <2>;
>>  			interrupt-controller;
>>  			#interrupt-cells = <2>;
>> --
>> 2.39.2
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 


From johan at kernel.org  Fri Dec 29 07:51:25 2023
From: johan at kernel.org (Johan Hovold)
Date: Fri, 29 Dec 2023 16:51:25 +0100
Subject: [PATCH] Bluetooth: hci_bcm4377: do not mark valid bd_addr as
 invalid
In-Reply-To: <CAEg-Je-WJZGMgurcQY3p9wQffEJmN3OsiK_9ictsFV3uTGdS9g@mail.gmail.com>
References: <20231227101003.10534-1-johan+linaro@kernel.org>
 <CAEg-Je-WJZGMgurcQY3p9wQffEJmN3OsiK_9ictsFV3uTGdS9g@mail.gmail.com>
Message-ID: <ZY7q_XOKya1MjH9h@hovoldconsulting.com>

On Fri, Dec 29, 2023 at 10:11:32AM -0500, Neal Gompa wrote:
> On Wed, Dec 27, 2023 at 5:10?AM Johan Hovold <johan+linaro at kernel.org> wrote:
> >
> > A recent commit restored the original (and still documented) semantics
> > for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device address
> > is considered invalid unless an address is provided by firmware.
> >
> > This specifically means that this flag must only be set for devices with
> > invalid addresses, but the Broadcom BCM4377 driver has so far been
> > setting this flag unconditionally.
> >
> > Fortunately the driver already checks for invalid addresses during setup
> > and sets the HCI_QUIRK_INVALID_BDADDR flag, which can simply be replaced
> > with HCI_QUIRK_USE_BDADDR_PROPERTY to indicate that the default address
> > is invalid but can be overridden by firmware (long term, this should
> > probably just always be allowed).
> >
> > Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk")
> > Cc: stable at vger.kernel.org      # 6.5
> > Reported-by: Felix Zhang <mrman at mrman314.tech>
> > Link: https://lore.kernel.org/r/77419ffacc5b4875e920e038332575a2a5bff29f.camel at mrman314.tech/
> > Signed-off-by: Johan Hovold <johan+linaro at kernel.org>

> Looks good to me. This replaces the other patch[1], I take it?

Yes, but as Sven explained here, that patch is also correct even though
that wasn't obvious from just reading the commit message (which should
be amended in my opinion):

	https://lore.kernel.org/asahi/AB87C916-9CF9-4B8C-AFF5-74CA4151C4FC at svenpeter.dev/
 
> Reviewed-by: Neal Gompa <neal at gompa.dev>

Thanks for reviewing.

> [1]: https://lore.kernel.org/asahi/aaa107865f4cbd61f8f9006fd3e7ac43b5d1bdad.camel at mrman314.tech/

Johan


From romain.gantois at bootlin.com  Fri Dec 29 08:11:48 2023
From: romain.gantois at bootlin.com (Romain Gantois)
Date: Fri, 29 Dec 2023 17:11:48 +0100 (CET)
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking
 COE
In-Reply-To: <20231219122034.pg2djgrosa4irubh@skbuf>
References: <20231218162326.173127-1-romain.gantois@bootlin.com> <20231218162326.173127-2-romain.gantois@bootlin.com> <20231219122034.pg2djgrosa4irubh@skbuf>
Message-ID: <3b53aa8a-73e9-9260-f05b-05dac80a4276@bootlin.com>


On Tue, 19 Dec 2023, Vladimir Oltean wrote:
> DSA_TAG_PROTO_LAN9303, DSA_TAG_PROTO_SJA1105 and DSA_TAG_PROTO_SJA1110
> construct tags with ETH_P_8021Q as EtherType. Do you still think it
> would be correct to say that all DSA tags break COE on the stmmac, as
> this patch assumes?
> 
> The NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM convention is not about
> statically checking whether the interface using DSA, but about looking
> at each packet before deciding whether to use the offload engine or to
> call skb_checksum_help().
> 
> You can experiment with any tagging protocol on the stmmac driver, and
> thus with the controller's response to any kind of traffic, even if the
> port is not attached to a hardware switch. You need to enable the
Thanks for telling me about DSA_LOOP, I've tested several DSA tagging protocols 
with the RZN1 GMAC1 hardware using this method. Here's what I found in a 
nutshell:

For tagging protocols that change the EtherType field in the MAC header (e.g. 
DSA_TAG_PROTO_(DSA/EDSA/BRCM/MTK/RTL4C_A/SJA1105): On TX the tagged frames are 
almost always ignored by the checksum offload engine and IP header checker of 
the MAC device. I say "almost always" because there is an 
unlikely but nasty corner case where a DSA tag can be identical to an IP 
EtherType value. In these cases, the frame will likely fail IP header checks 
and be dropped by the MAC.

Ignoring these corner cases, the DSA frames will egress with a partial 
checksum and be dropped by the recipient. On RX, these frames will, once again, 
not be detected as IP frames by the MAC. So they will be transmitted to the CPU. 
However, the stmmac driver will assume (wrongly in this case) that
these frames' checksums have been verified by the MAC. So it will set 
CHECKSUM_UNECESSARY:

https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#L5493
 
And so the IP/TCP checksums will not be checked at all, 
which is not ideal.

There are other DSA tagging protocols which cause different issues. For example 
DSA_TAG_PROTO_BRCM_PREPEND, which seems to offset the whole MAC header, and 
DSA_TAG_PROTO_LAN9303 which sets ETH_P_8021Q as its EtherType. I haven't dug too 
deeply on these issues yet, since I'd rather deal with the checksumming issue 
before getting distracted by VLAN offloading and other stuff.

Among the tagging protocols I tested, the only one that didn't cause any issues 
was DSA_TAG_PROTO_TRAILER, which only appends stuff to the frame.

TLDR: The simplest solution seems to be to modify the stmmac TX and RX paths to 
disable checksum offloading for frames that have a non-IP ethertype in 
their MAC header. This will fix the checksum situation for DSA tagging protocols 
that set non-IP and non-8021Q EtherTypes. Some edge cases like 
DSA_TAG_PROTO_BRCM_PREPEND and DSA_TAG_PROTO_LAN9303 will require a completely 
different solution if we want these MAC devices to handle them properly.
Please share any thoughts you might have on this suggestion.

Best Regards,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From jbx6244 at gmail.com  Fri Dec 29 08:11:57 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 29 Dec 2023 17:11:57 +0100
Subject: [PATCH v4 1/2] ARM: dts: rockchip: add gpio-ranges property to gpio
 nodes
Message-ID: <26007385-81dc-9961-05d5-8b9a0969d0b6@gmail.com>

Add a gpio-ranges property to Rockchip gpio nodes similar to
rk356x/rk3588 to be independent from aliases and probe order.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
Reviewed-by: Kever Yang <kever.yang at rock-chips.com>
---

Changed V4:
  change number of pins for rk3066,rk3288 and rv1126 (Jonas)

Changed V3:
  reword
  rebase to new rockchip directory
  remove unknown properties
---
 arch/arm/boot/dts/rockchip/rk3036.dtsi  | 3 +++
 arch/arm/boot/dts/rockchip/rk3066a.dtsi | 6 ++++++
 arch/arm/boot/dts/rockchip/rk3128.dtsi  | 4 ++++
 arch/arm/boot/dts/rockchip/rk3188.dtsi  | 4 ++++
 arch/arm/boot/dts/rockchip/rk322x.dtsi  | 4 ++++
 arch/arm/boot/dts/rockchip/rk3288.dtsi  | 9 +++++++++
 arch/arm/boot/dts/rockchip/rv1108.dtsi  | 4 ++++
 arch/arm/boot/dts/rockchip/rv1126.dtsi  | 5 +++++
 8 files changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
index 2b00109bea6a..6e5028b6dbfa 100644
--- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
@@ -593,6 +593,7 @@ gpio0: gpio at 2007c000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -606,6 +607,7 @@ gpio1: gpio at 20080000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -619,6 +621,7 @@ gpio2: gpio at 20084000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rk3066a.dtsi b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
index 30139f21de64..9a8603b34fa2 100644
--- a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
@@ -285,6 +285,7 @@ gpio0: gpio at 20034000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -298,6 +299,7 @@ gpio1: gpio at 2003c000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -311,6 +313,7 @@ gpio2: gpio at 2003e000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -324,6 +327,7 @@ gpio3: gpio at 20080000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -337,6 +341,7 @@ gpio4: gpio at 20084000 {
 			clocks = <&cru PCLK_GPIO4>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -350,6 +355,7 @@ gpio6: gpio at 2000a000 {
 			clocks = <&cru PCLK_GPIO6>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 192 16>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
index e2264c40b924..d66fcf12032e 100644
--- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
@@ -712,6 +712,7 @@ gpio0: gpio at 2007c000 {
 			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO0>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -723,6 +724,7 @@ gpio1: gpio at 20080000 {
 			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO1>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -734,6 +736,7 @@ gpio2: gpio at 20084000 {
 			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO2>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -745,6 +748,7 @@ gpio3: gpio at 20088000 {
 			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO3>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
diff --git a/arch/arm/boot/dts/rockchip/rk3188.dtsi b/arch/arm/boot/dts/rockchip/rk3188.dtsi
index 44b54af0bbf9..6677e4a10e5d 100644
--- a/arch/arm/boot/dts/rockchip/rk3188.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3188.dtsi
@@ -231,6 +231,7 @@ gpio0: gpio at 2000a000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -244,6 +245,7 @@ gpio1: gpio at 2003c000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -257,6 +259,7 @@ gpio2: gpio at 2003e000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -270,6 +273,7 @@ gpio3: gpio at 20080000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi b/arch/arm/boot/dts/rockchip/rk322x.dtsi
index 831561fc1814..0d4f9957b99b 100644
--- a/arch/arm/boot/dts/rockchip/rk322x.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk322x.dtsi
@@ -959,6 +959,7 @@ gpio0: gpio at 11110000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -972,6 +973,7 @@ gpio1: gpio at 11120000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -985,6 +987,7 @@ gpio2: gpio at 11130000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -998,6 +1001,7 @@ gpio3: gpio at 11140000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi b/arch/arm/boot/dts/rockchip/rk3288.dtsi
index ead343dc3df1..7116399461c8 100644
--- a/arch/arm/boot/dts/rockchip/rk3288.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3288.dtsi
@@ -1461,6 +1461,7 @@ gpio0: gpio at ff750000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 24>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1474,6 +1475,7 @@ gpio1: gpio at ff780000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1487,6 +1489,7 @@ gpio2: gpio at ff790000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1500,6 +1503,7 @@ gpio3: gpio at ff7a0000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1513,6 +1517,7 @@ gpio4: gpio at ff7b0000 {
 			clocks = <&cru PCLK_GPIO4>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1526,6 +1531,7 @@ gpio5: gpio at ff7c0000 {
 			clocks = <&cru PCLK_GPIO5>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 160 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1539,6 +1545,7 @@ gpio6: gpio at ff7d0000 {
 			clocks = <&cru PCLK_GPIO6>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 192 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1552,6 +1559,7 @@ gpio7: gpio at ff7e0000 {
 			clocks = <&cru PCLK_GPIO7>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 224 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1565,6 +1573,7 @@ gpio8: gpio at ff7f0000 {
 			clocks = <&cru PCLK_GPIO8>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 256 16>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rv1108.dtsi b/arch/arm/boot/dts/rockchip/rv1108.dtsi
index abf3006f0a84..d12b97ee7588 100644
--- a/arch/arm/boot/dts/rockchip/rv1108.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1108.dtsi
@@ -602,6 +602,7 @@ gpio0: gpio at 20030000 {
 			clocks = <&cru PCLK_GPIO0_PMU>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -615,6 +616,7 @@ gpio1: gpio at 10310000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -628,6 +630,7 @@ gpio2: gpio at 10320000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -641,6 +644,7 @@ gpio3: gpio at 10330000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index bb603cae13df..cf58cca4f09e 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -569,6 +569,7 @@ gpio0: gpio at ff460000 {
 			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -580,6 +581,7 @@ gpio1: gpio at ff620000 {
 			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -591,6 +593,7 @@ gpio2: gpio at ff630000 {
 			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -602,6 +605,7 @@ gpio3: gpio at ff640000 {
 			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -613,6 +617,7 @@ gpio4: gpio at ff650000 {
 			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 2>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
--
2.39.2



From jbx6244 at gmail.com  Fri Dec 29 08:12:52 2023
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 29 Dec 2023 17:12:52 +0100
Subject: [PATCH v4 2/2] arm64: dts: rockchip: add gpio-ranges property to gpio
 nodes
In-Reply-To: <26007385-81dc-9961-05d5-8b9a0969d0b6@gmail.com>
References: <26007385-81dc-9961-05d5-8b9a0969d0b6@gmail.com>
Message-ID: <18c8c89a-9962-40f0-814f-81e2c420c957@gmail.com>

Add a gpio-ranges property to Rockchip gpio nodes similar to
rk356x/rk3588 to be independent from aliases and probe order.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
Reviewed-by: Kever Yang <kever.yang at rock-chips.com>
---

Changed V3:
  reword
  remove rk356x part
---
 arch/arm64/boot/dts/rockchip/px30.dtsi   | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3308.dtsi | 5 +++++
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 4 ++++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
 5 files changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index d0905515399b..27d045296388 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1394,6 +1394,7 @@ gpio0: gpio at ff040000 {
 			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&pmucru PCLK_GPIO0_PMU>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1406,6 +1407,7 @@ gpio1: gpio at ff250000 {
 			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO1>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1418,6 +1420,7 @@ gpio2: gpio at ff260000 {
 			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO2>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1430,6 +1433,7 @@ gpio3: gpio at ff270000 {
 			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO3>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
index cfc0a87b5195..09fda512c101 100644
--- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
@@ -804,6 +804,7 @@ gpio0: gpio at ff220000 {
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO0>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -815,6 +816,7 @@ gpio1: gpio at ff230000 {
 			interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO1>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -826,6 +828,7 @@ gpio2: gpio at ff240000 {
 			interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO2>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -837,6 +840,7 @@ gpio3: gpio at ff250000 {
 			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO3>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
@@ -848,6 +852,7 @@ gpio4: gpio at ff260000 {
 			interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cru PCLK_GPIO4>;
 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 32>;
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index fb5dcf6e9327..2cead2e85c07 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -1058,6 +1058,7 @@ gpio0: gpio at ff210000 {
 			clocks = <&cru PCLK_GPIO0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1071,6 +1072,7 @@ gpio1: gpio at ff220000 {
 			clocks = <&cru PCLK_GPIO1>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1084,6 +1086,7 @@ gpio2: gpio at ff230000 {
 			clocks = <&cru PCLK_GPIO2>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
@@ -1097,6 +1100,7 @@ gpio3: gpio at ff240000 {
 			clocks = <&cru PCLK_GPIO3>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <2>;

 			interrupt-controller;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 62af0cb94839..2a017c862263 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -987,6 +987,7 @@ gpio0: gpio at ff750000 {
 			interrupts = <GIC_SPI 0x51 IRQ_TYPE_LEVEL_HIGH>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -1000,6 +1001,7 @@ gpio1: gpio at ff780000 {
 			interrupts = <GIC_SPI 0x52 IRQ_TYPE_LEVEL_HIGH>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -1013,6 +1015,7 @@ gpio2: gpio at ff790000 {
 			interrupts = <GIC_SPI 0x53 IRQ_TYPE_LEVEL_HIGH>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -1026,6 +1029,7 @@ gpio3: gpio at ff7a0000 {
 			interrupts = <GIC_SPI 0x54 IRQ_TYPE_LEVEL_HIGH>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 6e12c5a920ca..206f7d54d4d0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -2138,6 +2138,7 @@ gpio0: gpio at ff720000 {
 			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 0 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -2151,6 +2152,7 @@ gpio1: gpio at ff730000 {
 			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 32 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -2164,6 +2166,7 @@ gpio2: gpio at ff780000 {
 			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 64 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -2177,6 +2180,7 @@ gpio3: gpio at ff788000 {
 			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 96 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
@@ -2190,6 +2194,7 @@ gpio4: gpio at ff790000 {
 			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH 0>;

 			gpio-controller;
+			gpio-ranges = <&pinctrl 0 128 32>;
 			#gpio-cells = <0x2>;

 			interrupt-controller;
--
2.39.2



From othacehe at gnu.org  Fri Dec 29 08:48:21 2023
From: othacehe at gnu.org (Mathieu Othacehe)
Date: Fri, 29 Dec 2023 17:48:21 +0100
Subject: [PATCH v4 2/2] arm64: dts: imx93-var-som: Add Variscite
 VAR-SOM-MX93
In-Reply-To: <4e3a0328-0ae7-40fa-b37d-16b661e28a1e@gmx.net> (Stefan Wahren's
	message of "Fri, 29 Dec 2023 15:08:02 +0100")
References: <20231227170919.8771-1-othacehe@gnu.org>
	<20231227170919.8771-3-othacehe@gnu.org>
	<d378ad67-2a75-4a14-a131-7eb91de9ad3d@gmx.net>
	<87plypqi2d.fsf@gnu.org>
	<4e3a0328-0ae7-40fa-b37d-16b661e28a1e@gmx.net>
Message-ID: <87zfxtosyy.fsf@gnu.org>


Hey,

> I also saw in the other Symphony DTS a LED for heartbeat. Is it usable, too?

Yes, I will add it to in v5.

> According to the datasheet the SOM expose 7 UARTs, but only the debug
> UART is enable. What is the reason for this?

So those 7 UARTs are:

UART1: console
UART2: used by the microphone
UART3: used by the resistive touch
UART4: used by the ethernet/resistive touch
UART5: on J18.4,6,8,10 (used by BT)
UART6: on J18.7 and J18.9 (available)
UART7: on J18.3 and J18.5 (used by the M33 firmware)

I will enable UART6, and add a mention about UART7, something like:

/* J18.7, J18.9 */
&lpuart6 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_uart6>;
	status = "okay";
};

/* J18.3, J18.5 - used by M33 firmware */
&lpuart7 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_uart7>;
	status = "disabled";
};

> Btw the commit log mentions a Wifi (via SDIO?) and audio interface. This
> is currently not supported by Linux?

I am not sure about that, and I would prefer to study that a bit later
on if that's OK :) I can remove it from the commit log as this is
misleading as not already supported / tested.

Thanks,

Mathieu


From wahrenst at gmx.net  Fri Dec 29 09:17:57 2023
From: wahrenst at gmx.net (Stefan Wahren)
Date: Fri, 29 Dec 2023 18:17:57 +0100
Subject: [PATCH v4 2/2] arm64: dts: imx93-var-som: Add Variscite
 VAR-SOM-MX93
In-Reply-To: <87zfxtosyy.fsf@gnu.org>
References: <20231227170919.8771-1-othacehe@gnu.org>
 <20231227170919.8771-3-othacehe@gnu.org>
 <d378ad67-2a75-4a14-a131-7eb91de9ad3d@gmx.net> <87plypqi2d.fsf@gnu.org>
 <4e3a0328-0ae7-40fa-b37d-16b661e28a1e@gmx.net> <87zfxtosyy.fsf@gnu.org>
Message-ID: <ab993f3d-142c-4094-9320-772e1e3aad41@gmx.net>

Hi,

Am 29.12.23 um 17:48 schrieb Mathieu Othacehe:
> Hey,
>
>> I also saw in the other Symphony DTS a LED for heartbeat. Is it usable, too?
> Yes, I will add it to in v5.
>
>> According to the datasheet the SOM expose 7 UARTs, but only the debug
>> UART is enable. What is the reason for this?
> So those 7 UARTs are:
>
> UART1: console
> UART2: used by the microphone
> UART3: used by the resistive touch
> UART4: used by the ethernet/resistive touch
> UART5: on J18.4,6,8,10 (used by BT)
> UART6: on J18.7 and J18.9 (available)
> UART7: on J18.3 and J18.5 (used by the M33 firmware)
>
> I will enable UART6, and add a mention about UART7, something like:
>
> /* J18.7, J18.9 */
> &lpuart6 {
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&pinctrl_uart6>;
> 	status = "okay";
> };
>
> /* J18.3, J18.5 - used by M33 firmware */
> &lpuart7 {
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&pinctrl_uart7>;
> 	status = "disabled";
> };
in case this is used by the M33 firmware, this applies to all i.MX93 so
we don't need this. Just enable UART6 and keep UART7.
>> Btw the commit log mentions a Wifi (via SDIO?) and audio interface. This
>> is currently not supported by Linux?
> I am not sure about that, and I would prefer to study that a bit later
> on if that's OK :) I can remove it from the commit log as this is
> misleading as not already supported / tested.
This sounds good. No need to have it all at first.
>
> Thanks,
>
> Mathieu
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From broonie at kernel.org  Fri Dec 29 10:29:33 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 29 Dec 2023 18:29:33 +0000
Subject: [PATCH] ASoC: SOF: imx: Add SNDRV_PCM_INFO_BATCH flag
In-Reply-To: <1703669263-13832-1-git-send-email-shengjiu.wang@nxp.com>
References: <1703669263-13832-1-git-send-email-shengjiu.wang@nxp.com>
Message-ID: <170387457344.3008588.12379397390101428213.b4-ty@kernel.org>

On Wed, 27 Dec 2023 17:27:43 +0800, Shengjiu Wang wrote:
> The sof imx pcm device is a device which should support
> double buffering.
> 
> Found this issue with pipewire. When there is no
> SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will
> set headroom to be zero, and because sof pcm device
> don't support residue report, when the latency setting
> is small, the "delay" always larger than "target" in
> alsa-pcm.c, that reading next period data is not
> scheduled on time.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: SOF: imx: Add SNDRV_PCM_INFO_BATCH flag
      commit: b6190c452a2264ccd88c849b91990fe854a7ec72

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From broonie at kernel.org  Fri Dec 29 10:39:07 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 29 Dec 2023 18:39:07 +0000
Subject: [PATCH] ASoC: mediatek: mt8186: fix AUD_PAD_TOP register and
 offset
In-Reply-To: <20231229114342.195867-1-eugen.hristev@collabora.com>
References: <20231229114342.195867-1-eugen.hristev@collabora.com>
Message-ID: <170387514707.3010118.10483161102893986503.b4-ty@kernel.org>

On Fri, 29 Dec 2023 13:43:42 +0200, Eugen Hristev wrote:
> AUD_PAD_TOP widget's correct register is AFE_AUD_PAD_TOP , and not zero.
> Having a zero as register, it would mean that the `snd_soc_dapm_new_widgets`
> would try to read the register at offset zero when trying to get the power
> status of this widget, which is incorrect.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: mediatek: mt8186: fix AUD_PAD_TOP register and offset
      commit: 38744c3fa00109c51076121c2deb4f02e2f09194

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From broonie at kernel.org  Fri Dec 29 11:17:43 2023
From: broonie at kernel.org (Mark Brown)
Date: Fri, 29 Dec 2023 19:17:43 +0000
Subject: [PATCH RFC] ASoC: pxa: sspa: Don't select SND_ARM
In-Reply-To: <20231226200025.30870-1-duje.mihanovic@skole.hr>
References: <20231226200025.30870-1-duje.mihanovic@skole.hr>
Message-ID: <170387746330.3014555.13529710502553873994.b4-ty@kernel.org>

On Tue, 26 Dec 2023 21:00:24 +0100, Duje Mihanovi? wrote:
> On ARM64 platforms, SND_ARM shouldn't be selectable, but enabling
> SND_SOC_MMP_SSPA will enable SND_ARM and cause build errors if
> SND_ARMAACI is enabled (which it is by default). Since the SSPA driver
> doesn't depend on AACI nor PXA2XX_LIB, remove this false dependency.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: pxa: sspa: Don't select SND_ARM
      commit: 67508b874844b80ac49f70b78d67036c28b9fe7e

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From jagan at amarulasolutions.com  Fri Dec 29 12:18:38 2023
From: jagan at amarulasolutions.com (Jagan Teki)
Date: Sat, 30 Dec 2023 01:48:38 +0530
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <20231229152519.2jxrwaeltp4pxlms@skbuf>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf> <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
 <20231226153055.4yihsmu6kiak6hkf@skbuf> <CAMty3ZDnAFR9a1BM89mx3bmrQzGC7nvazt42_v4JF_QpwPkS4w@mail.gmail.com>
 <20231229152519.2jxrwaeltp4pxlms@skbuf>
Message-ID: <CAMty3ZAOM5+EMw9sLVOq-=CH_sP=1TLAGEMF9LYOZ4aFbNUtsg@mail.gmail.com>

On Fri, Dec 29, 2023 at 8:55?PM Vladimir Oltean <olteanv at gmail.com> wrote:
>
> On Fri, Dec 29, 2023 at 05:12:39PM +0530, Jagan Teki wrote:
> > With fec0 fixed-link and 3 different switch port configurations, the
> > result of the link seems to be up but the ping not working and even
> > the packets are not transmitted via eth0.
> >
> > DT Combinations:
> >
> > - Port0 is ethphy0, Port1 is ethphy1, Port2 is disabled, Port3 is
> > disabled, Port4 is FEC
> > - Port0 is disabled, Port1 is ethphy0, Port2 is ethphy1, Port3 is
> > disabled, Port4 is FEC
> > - Port0 is disabled, Port1 is disabled, Port2 is ethphy0, Port3 is
> > ethphy1, Port4 as FEC
>
> Why all these combinations? You don't know which switch port is which?

This is where I get confused in the first place. I didn't find proper
information on binding about how the physical pin-out is to be
configured in DT ports or maybe I didn't understand properly.

As per schematics.
Pin MII0_RXD0-D3/TXD0-D3 is connected to PROC_MII0_RXD0-D3/TXD0-D3
this would be fec0.
Pin MII1_RXD0-D3/TXD0-D3 is connected to PHY_MII1_RXD0-D3/TXD0-D3 this
would be ethphy0.
Pin MII2_RXD0-D3/TXD0-D3 is connected to PHY_MII2_RXD0-D3/TXD0-D3 this
would be ethphy1.
Pin MII3_RXD0-D3/TXD0-D3 is grounded
Pin MII4_RXD0-D3/TXD0-D3 is grounded

So, I did use the above 3 combinations and assumed fec0 is always a
port4 based on existing DTS in the tree. Please let me know which
configuration is proper as per schematic connections.

>
> > DT: (with Port0 is ethphy0, Port1 is ethphy1, Port2 is disabled, Port3
> > is disabled, Port4 is FEC)
> >
> > &ecspi2 {
> >     cs-gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
> >     pinctrl-names = "default";
> >     pinctrl-0 = <&pinctrl_ecspi2>;
> >     status = "okay";
> >
> >     switch at 0 {
> >         compatible = "nxp,sja1105q";
> >         reg = <0>;
> >         spi-max-frequency = <4000000>;
> >         spi-rx-delay-us = <1>;
> >         spi-tx-delay-us = <1>;
> >         spi-cpha;
> >
> >        clocks = <&clk25m>;
> >
> >        pinctrl-0 = <&pinctrl_sja1105_rst>;
> >        pinctrl-names = "default";
> >        reset-gpios = <&gpio6 5 GPIO_ACTIVE_LOW>;
> >
> >        ports {
> >               #address-cells = <1>;
> >               #size-cells = <0>;
> >
> >              port at 0 {
> >                   reg = <0>;
> >                   label = "ethphy0";
> >                   phy-handle = <&ethphy0>;
> >                   phy-mode = "mii";
> >             };
> >
> >             port at 1 {
> >                  reg = <1>;
> >                  label = "ethphy1";
> >                  phy-handle = <&ethphy1>;
> >                  phy-mode = "mii";
> >            };
> >
> >            port at 2 {
> >                 reg = <2>;
> >                 status = "disabled";
> >            };
> >
> >             port at 3 {
> >                  reg = <3>;
> >                  status = "disabled";
> >            };
> >
> >            port at 4 {
> >                 reg = <4>;
> >                 label = "cpu";
> >                 ethernet = <&fec>;
> >                 phy-mode = "mii";
> >                 rx-internal-delay-ps = <2000>;
> >                 tx-internal-delay-ps = <2000>;
>
> This looks suspicious. "rx-internal-delay-ps" and "tx-internal-delay-ps"
> are only relevant for the RGMII modes, but you specify phy-mode = "mii".
> Does the board schematic confirm that MII is the physical connection
> being used from the switch to the FEC?

Yes, the design uses MII.

>
> If you are truly using MII, then you should remove the RGMII delay
> properties, and since you are using a 6.1 kernel - hence after kernel
> commit 5d645df99ac6 ("net: dsa: sja1105: determine PHY/MAC role from PHY
> interface type") - you should be using phy-mode = "rev-mii" to put this
> port in MII PHY ("RevMII") mode - to interoperate with the FEC in MII
> MAC mode.

Okay, I will remove RGMII delay. is phy-mode = "rev-mii" applicable to
all ports or only for fec port4?

>
> >
> >                fixed-link {
> >                    speed = <100>;
> >                    full-duplex;
> >                };
> >             };
> >           };
> >      };
> > };
> >
> > &fec {
> >        pinctrl-names = "default";
> >        pinctrl-0 = <&pinctrl_enet>;
> >        phy-mode = "mii";
> >        status = "okay";
> >
> >        fixed-link {
> >           speed = <100>;
> >           full-duplex;
> >        };
> >
> >        mdio {
> >             #address-cells = <1>;
> >             #size-cells = <0>;
> >
> >             ethphy0: ethernet-phy at 0 {
> >                     compatible = "ethernet-phy-ieee802.3-c22";
> >                     reg = <0>;
> >             };
> >
> >            ethphy1: ethernet-phy at 1 {
> >                compatible = "ethernet-phy-ieee802.3-c22";
> >                 reg = <1>;
> >             };
> >     };
> > };
> >
> > root at ltts-imx6solo:~# bash /usr/phynew.sh
> > ======= MDIO: PHY0 ========
> > [  162.426515] mdio_netlink: loading out-of-tree module taints kernel.
>
> Still, please refrain from involving out-of-tree modules when asking for
> help upstream. Thanks.

Sorry, I didn't remove it during this log, but I did remove this
module at runtime during my actual sanity tests.

>
> > root at ltts-imx6solo:~# [  165.208656] sja1105 spi1.0 ethphy0: Link is
> > Up - 100Mbps/Full - flow control off
> > [  165.225788] sja1105 spi1.0 ethphy1: Link is Up - 100Mbps/Full -
> > flow control off
> > [  165.235925] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy0: link becomes ready
> > [  165.255777] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy1: link becomes ready
> >
> > root at ltts-imx6solo:~# ifconfig
> > eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1504
> >         inet6 fe80::68fb:8ff:fedf:d377  prefixlen 64  scopeid 0x20<link>
> >         ether 6a:fb:08:df:d3:77  txqueuelen 1000  (Ethernet)
> >         RX packets 0  bytes 0 (0.0 B)
> >         RX errors 0  dropped 0  overruns 0  frame 0
> >         TX packets 0  bytes 0 (0.0 B)
> >         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> > ethphy0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >         inet 169.254.178.1  netmask 255.255.0.0  broadcast 0.0.0.0
> >         inet6 fe80::211:22ff:fe33:4455  prefixlen 64  scopeid 0x20<link>
> >         ether 00:11:22:33:44:55  txqueuelen 1000  (Ethernet)
> >         RX packets 0  bytes 0 (0.0 B)
> >         RX errors 0  dropped 0  overruns 0  frame 0
> >         TX packets 30  bytes 4071 (3.9 KiB)
> >         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> > ethphy1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >         inet 169.253.178.2  netmask 255.255.0.0  broadcast 0.0.0.0
> >         inet6 fe80::211:22ff:fe33:4466  prefixlen 64  scopeid 0x20<link>
> >         ether 00:11:22:33:44:66  txqueuelen 1000  (Ethernet)
> >         RX packets 0  bytes 0 (0.0 B)
> >         RX errors 0  dropped 0  overruns 0  frame 0
> >         TX packets 30  bytes 4071 (3.9 KiB)
> >         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> > lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
> >         inet 127.0.0.1  netmask 255.0.0.0
> >         inet6 ::1  prefixlen 128  scopeid 0x10<host>
> >         loop  txqueuelen 1000  (Local Loopback)
> >         RX packets 89  bytes 7675 (7.4 KiB)
> >         RX errors 0  dropped 0  overruns 0  frame 0
> >         TX packets 89  bytes 7675 (7.4 KiB)
> >         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> ifconfig reports statistics counters from the /proc/net/dev interface,
> which the sja1105 does not report very well (they don't come from hardware).
> It's best to use "ethtool -S eth0 | grep -v ': 0'" for FEC and SJA1105
> CPU port (named "p04_*") counters, and "ethtool -S ethphy0 | grep -v ': 0'"
> to get hardware counters from the switch user ports.

Okay.

>
> You can also use the RX counters to determine which switch port is which
> (but the phy-handle of each port to each PHY needs to be correct).

RX counters in ethtool you mean?

>
> > mytsl02383 at MYTSL02383:~$ ifconfig -a
> > enp43s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >         inet 169.254.178.2  netmask 255.255.0.0  broadcast 169.254.255.255
> >         inet6 fe80::d71b:4bdd:27bd:2a1a  prefixlen 64  scopeid 0x20<link>
> >         ether 00:be:43:20:9a:26  txqueuelen 1000  (Ethernet)
> >         RX packets 272356  bytes 27099064 (27.0 MB)
> >         RX errors 0  dropped 19  overruns 0  frame 0
> >         TX packets 862  bytes 300806 (300.8 KB)
> >         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> > mytsl02383 at MYTSL02383:~$ ping 169.254.178.1
> > PING 169.254.178.1 (169.254.178.1) 56(84) bytes of data.
> > From 169.254.178.2 icmp_seq=1 Destination Host Unreachable
> >
> > Let me know if you need any more details.
>
> I'm not convinced packets are routed through ethphy0 or ethphy1, since
> all interfaces have IPv4 link-local addresses only. You can use
> "ip route get 169.254.178.1" to confirm what interface gets chosen.
> This is not indicative of a device-level problem, just a setup one.
> Please set up some IPv4 static addresses which are not link-local on the
> DSA user ports and try to ping a link partner which has an IP address in
> the same subnet.

Okay. I will update this test along with DT changes.

Thanks,
Jagan.


From quic_nkela at quicinc.com  Fri Dec 29 12:21:15 2023
From: quic_nkela at quicinc.com (Nikunj Kela)
Date: Fri, 29 Dec 2023 12:21:15 -0800
Subject: [PATCH 1/5] PM: domains: Add helper functions to attach/detach
 multiple PM domains
In-Reply-To: <20231228114157.104822-2-ulf.hansson@linaro.org>
References: <20231228114157.104822-1-ulf.hansson@linaro.org>
 <20231228114157.104822-2-ulf.hansson@linaro.org>
Message-ID: <22330d85-1d5c-48de-b006-9176f275328e@quicinc.com>


On 12/28/2023 3:41 AM, Ulf Hansson wrote:
> Attaching/detaching of a device to multiple PM domains has started to
> become a common operation for many drivers, typically during ->probe() and
> ->remove(). In most cases, this has lead to lots of boilerplate code in the
> drivers.
>
> To fixup up the situation, let's introduce a pair of helper functions,
> dev_pm_domain_attach|detach_list(), that driver can use instead of the
> open-coding. Note that, it seems reasonable to limit the support for these
> helpers to DT based platforms, at it's the only valid use case for now.
>
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> ---
>   drivers/base/power/common.c | 133 ++++++++++++++++++++++++++++++++++++
>   include/linux/pm_domain.h   |  38 +++++++++++
>   2 files changed, 171 insertions(+)
>
> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
> index 44ec20918a4d..1ef51889fc6f 100644
> --- a/drivers/base/power/common.c
> +++ b/drivers/base/power/common.c
> @@ -167,6 +167,114 @@ struct device *dev_pm_domain_attach_by_name(struct device *dev,
>   }
>   EXPORT_SYMBOL_GPL(dev_pm_domain_attach_by_name);
>   
> +/**
> + * dev_pm_domain_attach_list - Associate a device with its PM domains.
> + * @dev: The device used to lookup the PM domains for.
> + * @data: The data used for attaching to the PM domains.
> + * @list: An out-parameter with an allocated list of attached PM domains.
> + *
> + * This function helps to attach a device to its multiple PM domains. The
> + * caller, which is typically a driver's probe function, may provide a list of
> + * names for the PM domains that we should try to attach the device to, but it
> + * may also provide an empty list, in case the attach should be done for all of
> + * the available PM domains.
> + *
> + * Callers must ensure proper synchronization of this function with power
> + * management callbacks.
> + *
> + * Returns the number of attached PM domains or a negative error code in case of
> + * a failure. Note that, to detach the list of PM domains, the driver shall call
> + * dev_pm_domain_detach_list(), typically during the remove phase.
> + */
> +int dev_pm_domain_attach_list(struct device *dev,
> +			      const struct dev_pm_domain_attach_data *data,
> +			      struct dev_pm_domain_list **list)
> +{
> +	struct device_node *np = dev->of_node;
> +	struct dev_pm_domain_list *pds;
> +	struct device *pd_dev = NULL;
> +	int ret, i, num_pds = 0;
> +	bool by_id = true;
> +	u32 link_flags = data && data->pd_flags & PD_FLAG_NO_DEV_LINK ? 0 :
> +			DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME;
> +
> +	if (dev->pm_domain)
> +		return -EEXIST;
> +
> +	/* For now this is limited to OF based platforms. */
> +	if (!np)
> +		return 0;
> +
> +	if (data && data->pd_names) {
> +		num_pds = data->num_pd_names;
> +		by_id = false;
> +	} else {
> +		num_pds = of_count_phandle_with_args(np, "power-domains",
> +						     "#power-domain-cells");
> +	}
> +
> +	if (num_pds <= 0)
> +		return 0;
> +
> +	pds = devm_kzalloc(dev, sizeof(*pds), GFP_KERNEL);
> +	if (!pds)
> +		return -ENOMEM;
> +
> +	pds->pd_devs = devm_kcalloc(dev, num_pds, sizeof(*pds->pd_devs),
> +				    GFP_KERNEL);
> +	if (!pds->pd_devs)
> +		return -ENOMEM;
> +
> +	pds->pd_links = devm_kcalloc(dev, num_pds, sizeof(*pds->pd_links),
> +				     GFP_KERNEL);
> +	if (!pds->pd_links)
> +		return -ENOMEM;
> +
> +	if (link_flags && data->pd_flags & PD_FLAG_DEV_LINK_ON)

Since data is optional, this check results in crash if data is NULL. Thanks


> +		link_flags |= DL_FLAG_RPM_ACTIVE;
> +
> +	for (i = 0; i < num_pds; i++) {
> +		if (by_id)
> +			pd_dev = dev_pm_domain_attach_by_id(dev, i);
> +		else
> +			pd_dev = dev_pm_domain_attach_by_name(dev,
> +							data->pd_names[i]);
> +		if (IS_ERR_OR_NULL(pd_dev)) {
> +			ret = pd_dev ? PTR_ERR(pd_dev) : -ENODEV;
> +			goto err_attach;
> +		}
> +
> +		if (link_flags) {
> +			struct device_link *link;
> +
> +			link = device_link_add(dev, pd_dev, link_flags);
> +			if (!link) {
> +				ret = -ENODEV;
> +				goto err_link;
> +			}
> +
> +			pds->pd_links[i] = link;
> +		}
> +
> +		pds->pd_devs[i] = pd_dev;
> +	}
> +
> +	pds->num_pds = num_pds;
> +	*list = pds;
> +	return num_pds;
> +
> +err_link:
> +	dev_pm_domain_detach(pd_dev, true);
> +err_attach:
> +	while (--i >= 0) {
> +		if (pds->pd_links[i])
> +			device_link_del(pds->pd_links[i]);
> +		dev_pm_domain_detach(pds->pd_devs[i], true);
> +	}
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_domain_attach_list);
> +
>   /**
>    * dev_pm_domain_detach - Detach a device from its PM domain.
>    * @dev: Device to detach.
> @@ -187,6 +295,31 @@ void dev_pm_domain_detach(struct device *dev, bool power_off)
>   }
>   EXPORT_SYMBOL_GPL(dev_pm_domain_detach);
>   
> +/**
> + * dev_pm_domain_detach_list - Detach a list of PM domains.
> + * @list: The list of PM domains to detach.
> + *
> + * This function reverse the actions from dev_pm_domain_attach_list().
> + * Typically it should be invoked during the remove phase from drivers.
> + *
> + * Callers must ensure proper synchronization of this function with power
> + * management callbacks.
> + */
> +void dev_pm_domain_detach_list(struct dev_pm_domain_list *list)
> +{
> +	int i;
> +
> +	if (!list)
> +		return;
> +
> +	for (i = 0; i < list->num_pds; i++) {
> +		if (list->pd_links[i])
> +			device_link_del(list->pd_links[i]);
> +		dev_pm_domain_detach(list->pd_devs[i], true);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_domain_detach_list);
> +
>   /**
>    * dev_pm_domain_start - Start the device through its PM domain.
>    * @dev: Device to start.
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 34663d0d5c55..6b71fb69c349 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -19,6 +19,33 @@
>   #include <linux/cpumask.h>
>   #include <linux/time64.h>
>   
> +/*
> + * Flags to control the behaviour when attaching a device to its PM domains.
> + *
> + * PD_FLAG_NO_DEV_LINK:		As the default behaviour creates a device-link
> + *				for every PM domain that gets attached, this
> + *				flag can be used to skip that.
> + *
> + * PD_FLAG_DEV_LINK_ON:		Add the DL_FLAG_RPM_ACTIVE to power-on the
> + *				supplier and its PM domain when creating the
> + *				device-links.
> + *
> + */
> +#define PD_FLAG_NO_DEV_LINK		BIT(0)
> +#define PD_FLAG_DEV_LINK_ON		BIT(1)
> +
> +struct dev_pm_domain_attach_data {
> +	const char * const *pd_names;
> +	const u32 num_pd_names;
> +	const u32 pd_flags;
> +};
> +
> +struct dev_pm_domain_list {
> +	struct device **pd_devs;
> +	struct device_link **pd_links;
> +	u32 num_pds;
> +};
> +
>   /*
>    * Flags to control the behaviour of a genpd.
>    *
> @@ -432,7 +459,11 @@ struct device *dev_pm_domain_attach_by_id(struct device *dev,
>   					  unsigned int index);
>   struct device *dev_pm_domain_attach_by_name(struct device *dev,
>   					    const char *name);
> +int dev_pm_domain_attach_list(struct device *dev,
> +			      const struct dev_pm_domain_attach_data *data,
> +			      struct dev_pm_domain_list **list);
>   void dev_pm_domain_detach(struct device *dev, bool power_off);
> +void dev_pm_domain_detach_list(struct dev_pm_domain_list *list);
>   int dev_pm_domain_start(struct device *dev);
>   void dev_pm_domain_set(struct device *dev, struct dev_pm_domain *pd);
>   int dev_pm_domain_set_performance_state(struct device *dev, unsigned int state);
> @@ -451,7 +482,14 @@ static inline struct device *dev_pm_domain_attach_by_name(struct device *dev,
>   {
>   	return NULL;
>   }
> +static inline int dev_pm_domain_attach_list(struct device *dev,
> +				const struct dev_pm_domain_attach_data *data,
> +				struct dev_pm_domain_list **list)
> +{
> +	return 0;
> +}
>   static inline void dev_pm_domain_detach(struct device *dev, bool power_off) {}
> +static inline void dev_pm_domain_detach_list(struct dev_pm_domain_list *list) {}
>   static inline int dev_pm_domain_start(struct device *dev)
>   {
>   	return 0;


From jonas at kwiboo.se  Fri Dec 29 13:24:50 2023
From: jonas at kwiboo.se (Jonas Karlman)
Date: Fri, 29 Dec 2023 22:24:50 +0100
Subject: [PATCH v3 1/2] ARM: dts: rockchip: add gpio-ranges property to
 gpio nodes
In-Reply-To: <396abf33-567c-b020-b12d-ee1cd7eca836@gmail.com>
References: <cf46c685-bf4b-63b5-0373-dd0ba70e9700@gmail.com>
 <541b7633-af3b-4392-ac29-7ee1f2c6f943@kwiboo.se>
 <396abf33-567c-b020-b12d-ee1cd7eca836@gmail.com>
Message-ID: <8df5b058-aec5-4b94-8d80-fed5d4dde10f@kwiboo.se>

Hi Johan,

On 2023-12-29 16:47, Johan Jonker wrote:
> Hi Jonas,
> 
> On 12/28/23 17:30, Jonas Karlman wrote:
>> Hi Johan,
>>
>> On 2023-12-27 19:33, Johan Jonker wrote:
>>> Add a gpio-ranges property to Rockchip gpio nodes similar to
>>> rk356x/rk3588 to be independent from aliases and probe order.
>>>
>>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>>> Reviewed-by: Kever Yang <kever.yang at rock-chips.com>
>>> ---
>>>
>>> Changed V3:
>>>   reword
>>>   rebase to new Rockchip directory
>>>   remove unknown properties
>>> ---
>>>  arch/arm/boot/dts/rockchip/rk3036.dtsi  | 3 +++
>>>  arch/arm/boot/dts/rockchip/rk3066a.dtsi | 6 ++++++
>>>  arch/arm/boot/dts/rockchip/rk3128.dtsi  | 4 ++++
>>>  arch/arm/boot/dts/rockchip/rk3188.dtsi  | 4 ++++
>>>  arch/arm/boot/dts/rockchip/rk322x.dtsi  | 4 ++++
>>>  arch/arm/boot/dts/rockchip/rk3288.dtsi  | 9 +++++++++
>>>  arch/arm/boot/dts/rockchip/rv1108.dtsi  | 4 ++++
>>>  arch/arm/boot/dts/rockchip/rv1126.dtsi  | 5 +++++
>>>  8 files changed, 39 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/rockchip/rk3036.dtsi b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>> index 2b00109bea6a..6e5028b6dbfa 100644
>>> --- a/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>> +++ b/arch/arm/boot/dts/rockchip/rk3036.dtsi
>>> @@ -593,6 +593,7 @@ gpio0: gpio at 2007c000 {
>>>  			clocks = <&cru PCLK_GPIO0>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -606,6 +607,7 @@ gpio1: gpio at 20080000 {
>>>  			clocks = <&cru PCLK_GPIO1>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -619,6 +621,7 @@ gpio2: gpio at 20084000 {
>>>  			clocks = <&cru PCLK_GPIO2>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> diff --git a/arch/arm/boot/dts/rockchip/rk3066a.dtsi b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
>>> index 30139f21de64..a4962b6b3f4c 100644
>>> --- a/arch/arm/boot/dts/rockchip/rk3066a.dtsi
>>> +++ b/arch/arm/boot/dts/rockchip/rk3066a.dtsi
>>> @@ -285,6 +285,7 @@ gpio0: gpio at 20034000 {
>>>  			clocks = <&cru PCLK_GPIO0>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -298,6 +299,7 @@ gpio1: gpio at 2003c000 {
>>>  			clocks = <&cru PCLK_GPIO1>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -311,6 +313,7 @@ gpio2: gpio at 2003e000 {
>>>  			clocks = <&cru PCLK_GPIO2>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -324,6 +327,7 @@ gpio3: gpio at 20080000 {
>>>  			clocks = <&cru PCLK_GPIO3>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -337,6 +341,7 @@ gpio4: gpio at 20084000 {
>>>  			clocks = <&cru PCLK_GPIO4>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 128 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -350,6 +355,7 @@ gpio6: gpio at 2000a000 {
>>>  			clocks = <&cru PCLK_GPIO6>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 192 32>;
>>
> 
>> It does not look like this matches what pins the pinctrl driver expose
>> for rk3066a. Something like <&pinctrl 0 160 16> would probably be more
>> correct.
> 
> See comment below.
> 
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> diff --git a/arch/arm/boot/dts/rockchip/rk3128.dtsi b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>>> index e2264c40b924..d66fcf12032e 100644
>>> --- a/arch/arm/boot/dts/rockchip/rk3128.dtsi
>>> +++ b/arch/arm/boot/dts/rockchip/rk3128.dtsi
>>> @@ -712,6 +712,7 @@ gpio0: gpio at 2007c000 {
>>>  			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>>>  			clocks = <&cru PCLK_GPIO0>;
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>>  			#gpio-cells = <2>;
>>>  			interrupt-controller;
>>>  			#interrupt-cells = <2>;
>>> @@ -723,6 +724,7 @@ gpio1: gpio at 20080000 {
>>>  			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
>>>  			clocks = <&cru PCLK_GPIO1>;
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>>  			#gpio-cells = <2>;
>>>  			interrupt-controller;
>>>  			#interrupt-cells = <2>;
>>> @@ -734,6 +736,7 @@ gpio2: gpio at 20084000 {
>>>  			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
>>>  			clocks = <&cru PCLK_GPIO2>;
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>>  			#gpio-cells = <2>;
>>>  			interrupt-controller;
>>>  			#interrupt-cells = <2>;
>>> @@ -745,6 +748,7 @@ gpio3: gpio at 20088000 {
>>>  			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>>>  			clocks = <&cru PCLK_GPIO3>;
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>>  			#gpio-cells = <2>;
>>>  			interrupt-controller;
>>>  			#interrupt-cells = <2>;
>>> diff --git a/arch/arm/boot/dts/rockchip/rk3188.dtsi b/arch/arm/boot/dts/rockchip/rk3188.dtsi
>>> index 44b54af0bbf9..6677e4a10e5d 100644
>>> --- a/arch/arm/boot/dts/rockchip/rk3188.dtsi
>>> +++ b/arch/arm/boot/dts/rockchip/rk3188.dtsi
>>> @@ -231,6 +231,7 @@ gpio0: gpio at 2000a000 {
>>>  			clocks = <&cru PCLK_GPIO0>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -244,6 +245,7 @@ gpio1: gpio at 2003c000 {
>>>  			clocks = <&cru PCLK_GPIO1>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -257,6 +259,7 @@ gpio2: gpio at 2003e000 {
>>>  			clocks = <&cru PCLK_GPIO2>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -270,6 +273,7 @@ gpio3: gpio at 20080000 {
>>>  			clocks = <&cru PCLK_GPIO3>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi b/arch/arm/boot/dts/rockchip/rk322x.dtsi
>>> index 831561fc1814..0d4f9957b99b 100644
>>> --- a/arch/arm/boot/dts/rockchip/rk322x.dtsi
>>> +++ b/arch/arm/boot/dts/rockchip/rk322x.dtsi
>>> @@ -959,6 +959,7 @@ gpio0: gpio at 11110000 {
>>>  			clocks = <&cru PCLK_GPIO0>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -972,6 +973,7 @@ gpio1: gpio at 11120000 {
>>>  			clocks = <&cru PCLK_GPIO1>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -985,6 +987,7 @@ gpio2: gpio at 11130000 {
>>>  			clocks = <&cru PCLK_GPIO2>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -998,6 +1001,7 @@ gpio3: gpio at 11140000 {
>>>  			clocks = <&cru PCLK_GPIO3>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi b/arch/arm/boot/dts/rockchip/rk3288.dtsi
>>> index ead343dc3df1..c5550aae4ed8 100644
>>> --- a/arch/arm/boot/dts/rockchip/rk3288.dtsi
>>> +++ b/arch/arm/boot/dts/rockchip/rk3288.dtsi
>>> @@ -1461,6 +1461,7 @@ gpio0: gpio at ff750000 {
>>>  			clocks = <&cru PCLK_GPIO0>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>
>> The pinctrl driver for rk3288 only expose 24 pins for the first bank,
>> correct range would probably be <&pinctrl 0 0 24> here,
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -1474,6 +1475,7 @@ gpio1: gpio at ff780000 {
>>>  			clocks = <&cru PCLK_GPIO1>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>
> 
>> and correct range would probably be <&pinctrl 0 24 32> here,
> 
> Random gpio offset ranges for a gpio bank of the various Rockchip SoCs makes it impossible to easy link gpio to pinctrl and vica versa in a standard way without additional Rockchip specific node properties.
> To keep things simple the gpio-range for a gpio bank must always be inside to same multiple of 32 for all Rockchip SoCs in relation to the pinctrl.
> A "rockchip,pins" property always must have the same "gpio-ranges" set.

I am fully aware that each gpio controller can handle up to 32 gpio pins
and that the relationship with the pin controller is not fully aligned
for some SoCs.

However, the gpio-ranges prop is described as:

"
It is useful to represent which GPIOs correspond to which pins on which pin
controllers. The gpio-ranges property described below represents this with
a discrete set of ranges mapping pins from the pin controller local number space
to pins in the GPIO controller local number space.

The format is: <[pin controller phandle], [GPIO controller offset],
                [pin controller offset], [number of pins]>;
"

For RK each GPIO controller have a local number space 0 - 31, and the
pin controller local number space is 0 - <npins - 1> (total number of
exposed pins).

So for rk3066a the pinctrl local number space is 0-175, and this patch
(and v4) try to reference pin controller offset 192 for gpio6.

Same goes for rk3288, where the pinctrl local number space is 0-263 and
because of only 24 pins from bank num 0 is exposed the pin controller
offset used for gpio1-8 in this patch (and v4) result in wrong pins
being referenced.

Remaining SoCs seem to have gpio and pinctrl pins aligned to 32 and
look correct in v4.

Please also note that all RK SoC DTs beside px30, rv1108 and rv1126 have
a stable /aliases/gpioX DT reference for each gpio controller.

Regards,
Jonas

> 
> Johan
> 
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -1487,6 +1489,7 @@ gpio2: gpio at ff790000 {
>>>  			clocks = <&cru PCLK_GPIO2>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>
>> and <&pinctrl 0 56 32> here,
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -1500,6 +1503,7 @@ gpio3: gpio at ff7a0000 {
>>>  			clocks = <&cru PCLK_GPIO3>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>
>> and <&pinctrl 0 88 32> here,
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -1513,6 +1517,7 @@ gpio4: gpio at ff7b0000 {
>>>  			clocks = <&cru PCLK_GPIO4>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 128 32>;
>>
>> and <&pinctrl 0 120 32> here,
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -1526,6 +1531,7 @@ gpio5: gpio at ff7c0000 {
>>>  			clocks = <&cru PCLK_GPIO5>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 160 32>;
>>
>> and <&pinctrl 0 152 32> here,
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -1539,6 +1545,7 @@ gpio6: gpio at ff7d0000 {
>>>  			clocks = <&cru PCLK_GPIO6>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 192 32>;
>>
>> and <&pinctrl 0 184 32> here,
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -1552,6 +1559,7 @@ gpio7: gpio at ff7e0000 {
>>>  			clocks = <&cru PCLK_GPIO7>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 224 32>;
>>
>> and <&pinctrl 0 216 32> here,
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -1565,6 +1573,7 @@ gpio8: gpio at ff7f0000 {
>>>  			clocks = <&cru PCLK_GPIO8>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 256 32>;
>>
>> and bank num 8 only expose 16 pins, so <&pinctrl 0 248 16> here.
>>
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> diff --git a/arch/arm/boot/dts/rockchip/rv1108.dtsi b/arch/arm/boot/dts/rockchip/rv1108.dtsi
>>> index abf3006f0a84..d12b97ee7588 100644
>>> --- a/arch/arm/boot/dts/rockchip/rv1108.dtsi
>>> +++ b/arch/arm/boot/dts/rockchip/rv1108.dtsi
>>> @@ -602,6 +602,7 @@ gpio0: gpio at 20030000 {
>>>  			clocks = <&cru PCLK_GPIO0_PMU>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -615,6 +616,7 @@ gpio1: gpio at 10310000 {
>>>  			clocks = <&cru PCLK_GPIO1>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -628,6 +630,7 @@ gpio2: gpio at 10320000 {
>>>  			clocks = <&cru PCLK_GPIO2>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> @@ -641,6 +644,7 @@ gpio3: gpio at 10330000 {
>>>  			clocks = <&cru PCLK_GPIO3>;
>>>
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>>  			#gpio-cells = <2>;
>>>
>>>  			interrupt-controller;
>>> diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
>>> index bb603cae13df..71d091af6395 100644
>>> --- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
>>> +++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
>>> @@ -569,6 +569,7 @@ gpio0: gpio at ff460000 {
>>>  			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
>>>  			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 0 32>;
>>>  			#gpio-cells = <2>;
>>>  			interrupt-controller;
>>>  			#interrupt-cells = <2>;
>>> @@ -580,6 +581,7 @@ gpio1: gpio at ff620000 {
>>>  			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
>>>  			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 32 32>;
>>>  			#gpio-cells = <2>;
>>>  			interrupt-controller;
>>>  			#interrupt-cells = <2>;
>>> @@ -591,6 +593,7 @@ gpio2: gpio at ff630000 {
>>>  			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>>>  			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 64 32>;
>>>  			#gpio-cells = <2>;
>>>  			interrupt-controller;
>>>  			#interrupt-cells = <2>;
>>> @@ -602,6 +605,7 @@ gpio3: gpio at ff640000 {
>>>  			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
>>>  			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 96 32>;
>>>  			#gpio-cells = <2>;
>>>  			interrupt-controller;
>>>  			#interrupt-cells = <2>;
>>> @@ -613,6 +617,7 @@ gpio4: gpio at ff650000 {
>>>  			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
>>>  			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
>>>  			gpio-controller;
>>> +			gpio-ranges = <&pinctrl 0 128 32>;
>>
>> Bank num 4 only expose 2 pins, so should probably be <&pinctrl 0 128 2>.
>>
>> Regards,
>> Jonas
>>
>>>  			#gpio-cells = <2>;
>>>  			interrupt-controller;
>>>  			#interrupt-cells = <2>;
>>> --
>>> 2.39.2
>>>
>>>
>>> _______________________________________________
>>> Linux-rockchip mailing list
>>> Linux-rockchip at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>



From nfraprado at collabora.com  Fri Dec 29 13:28:39 2023
From: nfraprado at collabora.com (=?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?=)
Date: Fri, 29 Dec 2023 18:28:39 -0300
Subject: [PATCH 1/2] dt-bindings: cpufreq: Add big CPU supply
Message-ID: <20231229212853.277334-1-nfraprado@collabora.com>

The performance-controller hardware block on MediaTek SoCs is
responsible for controlling the frequency of the CPUs. As such, it needs
any CPU regulator to have been configured prior to initializing. Add a
phandle in the binding so this dependency can be described.

Signed-off-by: N?colas F. R. A. Prado <nfraprado at collabora.com>
---

 .../devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml        | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
index d0aecde2b89b..d75b01d04998 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
@@ -33,6 +33,8 @@ properties:
       performance domains.
     const: 1
 
+  big-cpus-supply: true
+
 required:
   - compatible
   - reg
-- 
2.43.0



From nfraprado at collabora.com  Fri Dec 29 13:28:40 2023
From: nfraprado at collabora.com (=?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?=)
Date: Fri, 29 Dec 2023 18:28:40 -0300
Subject: [PATCH 2/2] arm64: dts: mediatek: cherry: Add CPU supply dependency to cpufreq-hw
In-Reply-To: <20231229212853.277334-1-nfraprado@collabora.com>
References: <20231229212853.277334-1-nfraprado@collabora.com>
Message-ID: <20231229212853.277334-2-nfraprado@collabora.com>

When the mediatek-cpufreq-hw driver enables the hardware (by
writing to REG_FREQ_ENABLE), if the regulator supplying the voltage to
the big CPUs hasn't probed yet, the platform hangs shortly after and
"rcu: INFO: rcu_preempt detected stalls on CPUs/tasks" are printed in
the log.

To prevent this from happening, describe the big CPUs regulator in the
performance-controller DT node, so that devlink ensures the regulator
has been probed and configured before the frequency scaling hardware is
probed and enabled.

Signed-off-by: N?colas F. R. A. Prado <nfraprado at collabora.com>

---

 arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index dd5b89b73190..505da60eee90 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -502,6 +502,10 @@ &pcie1 {
 	pinctrl-0 = <&pcie1_pins_default>;
 };
 
+&performance {
+	big-cpus-supply = <&mt6315_6_vbuck1>;
+};
+
 &pio {
 	mediatek,rsel-resistance-in-si-unit;
 	pinctrl-names = "default";
-- 
2.43.0



From andrew at lunn.ch  Fri Dec 29 13:43:48 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 29 Dec 2023 22:43:48 +0100
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <CAMty3ZAOM5+EMw9sLVOq-=CH_sP=1TLAGEMF9LYOZ4aFbNUtsg@mail.gmail.com>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf>
 <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
 <20231226153055.4yihsmu6kiak6hkf@skbuf>
 <CAMty3ZDnAFR9a1BM89mx3bmrQzGC7nvazt42_v4JF_QpwPkS4w@mail.gmail.com>
 <20231229152519.2jxrwaeltp4pxlms@skbuf>
 <CAMty3ZAOM5+EMw9sLVOq-=CH_sP=1TLAGEMF9LYOZ4aFbNUtsg@mail.gmail.com>
Message-ID: <dc66ab0e-1c63-4a57-98a5-a440d97d13f7@lunn.ch>

> > If you are truly using MII, then you should remove the RGMII delay
> > properties, and since you are using a 6.1 kernel - hence after kernel
> > commit 5d645df99ac6 ("net: dsa: sja1105: determine PHY/MAC role from PHY
> > interface type") - you should be using phy-mode = "rev-mii" to put this
> > port in MII PHY ("RevMII") mode - to interoperate with the FEC in MII
> > MAC mode.
> 
> Okay, I will remove RGMII delay. is phy-mode = "rev-mii" applicable to
> all ports or only for fec port4?

phy-mode indicates what the PHY should be doing. In this case, the
switch is taking the place of the PHY and so the switch MAC needs to
be revMII so that it acts like a PHY. For the other ports of the
switch, you have a real PHY connected, so you want MII.

	Andrew


From andrew at lunn.ch  Fri Dec 29 13:56:10 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 29 Dec 2023 22:56:10 +0100
Subject: [PATCH 0/4] mmc: xenon: add AC5 support
In-Reply-To: <20231227123257.1170590-1-enachman@marvell.com>
References: <20231227123257.1170590-1-enachman@marvell.com>
Message-ID: <cfbbe706-5953-488c-9bff-f72f6d00b44f@lunn.ch>

On Wed, Dec 27, 2023 at 02:32:53PM +0200, Elad Nachman wrote:
> From: Elad Nachman <enachman at marvell.com>
> 
> This patch series adds support for the Marvell AC5/X/IM series of SOCs.
> The main hurdles in supporting these SOCs are the following limitations:
> 1. DDR starts at offset 0x2_0000_0000
> 2. mmc controller has only 31-bit path on the crossbar to the DDR.
> 
> Point number one is solved by the first patch, which targets the
> arm64 subsystem, by taking into account the DDR start address when
> calculating the DMA and DMA32 zones.
> 
> This yields the correct split between DMA, DMA32 and NORMAL zones
> according to the device tree CPU address limitations.
> 
> Point number two is solved in the mmc xenon driver by detecting the memory
> size, and when it is more than 2GB, disable ADMA and 64-bit DMA, which
> effectively enables SDMA with a bounce buffer.
> DMA mask is then set manually to 34 bit to account for the DDR starting
> at offset 0x2_0000_0000 .

You probably need to split this patchset up since the first patch will
get merged via the arm64 core maintainers, the MMC driver change via
the MMC maintainers, and maybe the DT changes for the
ac5-98dx25xx.dtsi via the mvebu maintainers, or the MMC maintainer?

	Andrew


From heiko at sntech.de  Fri Dec 29 14:55:12 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 29 Dec 2023 23:55:12 +0100
Subject: [PATCH] arm64: dts: rockchip: Support poweroff on Orange Pi 5
In-Reply-To: <20231227203211.1047-1-honyuenkwun@gmail.com>
References: <20231227203211.1047-1-honyuenkwun@gmail.com>
Message-ID: <170389050012.2630399.823278864304556357.b4-ty@sntech.de>

On Wed, 27 Dec 2023 14:32:11 -0600, Jimmy Hon wrote:
> The RK806 on the Orange Pi 5 can be used to power on/off the whole board.
> Mark it as the system power controller.
> 
> 

Applied, thanks!

[1/1] arm64: dts: rockchip: Support poweroff on Orange Pi 5
      commit: e9126f9d3c83acbc88461a535e24c949c7e0b6ca

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Fri Dec 29 14:55:14 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 29 Dec 2023 23:55:14 +0100
Subject: [PATCH v2] arm64: dts: rockchip: correct gpio_pwrctrl1 typo
In-Reply-To: <20231225223226.17690-1-inindev@gmail.com>
References: <20231225223226.17690-1-inindev@gmail.com>
Message-ID: <170389050012.2630399.15117069356427722375.b4-ty@sntech.de>

On Mon, 25 Dec 2023 22:32:16 +0000, John Clark wrote:
> Both rk806_dvs1_null and rk806_dvs2_null duplicate gpio_pwrctrl2 and
> gpio_pwrctrl1 is not set. This patch sets gpio_pwrctrl1.
> 
> 

Applied, thanks!

[1/1] arm64: dts: rockchip: correct gpio_pwrctrl1 typo
      commit: 24559788384916041a0bbf54c32e2a16b612d247

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Fri Dec 29 14:55:13 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 29 Dec 2023 23:55:13 +0100
Subject: [PATCH v2 1/2] arm64: dts: rockchip: support poweroff on the rock-5b
In-Reply-To: <20231225222859.17153-1-inindev@gmail.com>
References: <20231225222859.17153-1-inindev@gmail.com>
Message-ID: <170389050012.2630399.8754217298577818519.b4-ty@sntech.de>

On Mon, 25 Dec 2023 22:28:19 +0000, John Clark wrote:
> Allow the rock-5b to poweroff its pmic. When issuing a "shutdown -h now"
> on the rock-5b it reboots instead. Defining 'system-power-controller'
> allows the rk806 to power down.
> 
> Commit c699fbfdfd54 ("arm64: dts: rockchip: Support poweroff on
> NanoPC-T6") similarly resolves this issue for the nanopc-t6.
> 
> [...]

Applied, thanks!

[1/2] arm64: dts: rockchip: support poweroff on the rock-5b
      commit: 7738f551173540b3daa63a91b384b167eacd24fd
[2/2] arm64: dts: rockchip: correct gpio_pwrctrl1 typo
      commit: aed6514c4e3aee843385ded4c5ee0921b51c30fa

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Fri Dec 29 14:55:11 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 29 Dec 2023 23:55:11 +0100
Subject: [PATCH v2] arm64: dts: rockchip: Fix led pinctrl of lubancat 1
In-Reply-To: <20231225005055.3102743-1-andyshrk@163.com>
References: <20231225005055.3102743-1-andyshrk@163.com>
Message-ID: <170389050013.2630399.12594636943647142051.b4-ty@sntech.de>

On Mon, 25 Dec 2023 08:50:55 +0800, Andy Yan wrote:
> According to the sch, the gpio control sys_led
> is GPIO0_C5.
> 
> 

Applied, thanks!

[1/1] arm64: dts: rockchip: Fix led pinctrl of lubancat 1
      commit: 8586a5d217ef7bfeee24943c600a8a7890d6f477

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Fri Dec 29 14:55:15 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 29 Dec 2023 23:55:15 +0100
Subject: [PATCH v2] arm64: dts: rockchip: nanopc-t6 sdmmc device tuning
In-Reply-To: <20231228173011.2863-1-inindev@gmail.com>
References: <20231228173011.2863-1-inindev@gmail.com>
Message-ID: <170389050011.2630399.396518160692088358.b4-ty@sntech.de>

On Thu, 28 Dec 2023 17:29:35 +0000, John Clark wrote:
> drop max-frequency = <200000000> as it is already defined in rk3588s.dtsi
> order no-sdio & no-mmc properties while we are here
> 
> 

Applied, thanks!

[1/1] arm64: dts: rockchip: nanopc-t6 sdmmc device tuning
      commit: 9e1faff1cbc877903d019a7943d37ddc5042704d

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From festevam at gmail.com  Fri Dec 29 15:01:59 2023
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 29 Dec 2023 20:01:59 -0300
Subject: [PATCH] arm64: dts: imx8mp: Disable UART4 by default on Data
 Modul i.MX8M Plus eDM SBC
In-Reply-To: <20231220000345.42593-1-marex@denx.de>
References: <20231220000345.42593-1-marex@denx.de>
Message-ID: <CAOMZO5B-U8Tw9c2zecK_cfw0o+B=S7Jd1dH74goGxXeFFqmOLA@mail.gmail.com>

On Tue, Dec 19, 2023 at 9:04?PM Marek Vasut <marex at denx.de> wrote:
>
> UART4 is used as CM7 coprocessor debug UART and may not be accessible from
> Linux in case it is protected by RDC. The RDC protection is set up by the
> platform firmware. UART4 is not used on this platform by Linux. Disable
> UART4 by default to prevent boot hangs, which occur when the RDC protection
> is in place.
>
> Fixes: 562d222f23f0 ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC")
> Signed-off-by: Marek Vasut <marex at denx.de>

Reviewed-by: Fabio Estevam <festevam at gmail.com>


From heiko at sntech.de  Fri Dec 29 15:26:22 2023
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Sat, 30 Dec 2023 00:26:22 +0100
Subject: [PATCH v4 01/29] dt-bindings: display: rockchip,inno-hdmi: Document
 RK3128 compatible
In-Reply-To: <20231222174220.55249-2-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
 <20231222174220.55249-2-knaerzche@gmail.com>
Message-ID: <18743278.sWSEgdgrri@diego>

Am Freitag, 22. Dezember 2023, 18:41:52 CET schrieb Alex Bee:
> The integration for this SoC is different from the currently existing: It
> needs it's PHY's reference clock rate to calculate the DDC bus frequency
> correctly. The controller is also part of a powerdomain, so this gets added
> as an mandatory property for this variant.
> 
> Signed-off-by: Alex Bee <knaerzche at gmail.com>
> Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

this is just a note to myself:

The binding conversion to yaml was picked by Rob in [0], so will most 
likely be part of 6.8-rc1, so this will need to wait until 6.8-rc1 gets into
drm-misc-next .


Heiko


[0] https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/commit/?h=for-next&id=7048708fec3a401f9a70e4a74e2e12aa7f88c132

> ---
> changes in v2:
>  - clarify that the controller itself is part of the powerdomain
>  - simplify clock-names
>  - made power-domains property only allowed (and required) for new variant
> 
> changes in v3:
>  - collect RB
> 
> changes in v4:
>  - none
> 
>  .../display/rockchip/rockchip,inno-hdmi.yaml  | 40 ++++++++++++++++++-
>  1 file changed, 38 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> index 96889c86849a..be78dcfa1c76 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
> @@ -14,6 +14,7 @@ properties:
>    compatible:
>      enum:
>        - rockchip,rk3036-inno-hdmi
> +      - rockchip,rk3128-inno-hdmi
>  
>    reg:
>      maxItems: 1
> @@ -22,10 +23,19 @@ properties:
>      maxItems: 1
>  
>    clocks:
> -    maxItems: 1
> +    minItems: 1
> +    items:
> +      - description: The HDMI controller main clock
> +      - description: The HDMI PHY reference clock
>  
>    clock-names:
> -    const: pclk
> +    minItems: 1
> +    items:
> +      - const: pclk
> +      - const: ref
> +
> +  power-domains:
> +    maxItems: 1
>  
>    ports:
>      $ref: /schemas/graph.yaml#/properties/ports
> @@ -55,6 +65,32 @@ required:
>    - pinctrl-names
>    - ports
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: rockchip,rk3036-inno-hdmi
> +
> +    then:
> +      properties:
> +        power-domains: false
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: rockchip,rk3128-inno-hdmi
> +
> +    then:
> +      properties:
> +        clocks:
> +          minItems: 2
> +        clock-names:
> +          minItems: 2
> +      required:
> +        - power-domains
> +
>  additionalProperties: false
>  
>  examples:
> 






From heiko at sntech.de  Fri Dec 29 15:36:52 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sat, 30 Dec 2023 00:36:52 +0100
Subject: (subset) [PATCH v4 00/29] Add HDMI support for RK3128
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <170389300283.2698513.7009749210069050452.b4-ty@sntech.de>

On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote:
> This is version 4 of my series that aims to add support for the display
> controller (VOP) and the HDMI controller block of RK3128 (which is very
> similar to the one found in RK3036). The original intention of this series
> was to add support for this slightly different integration but is by now,
> driven by maintainer's feedback, exploded to be a rework of inno-hdmi
> driver in large parts. It is, however, a change for the better.
> 
> [...]

Applied, thanks!

[02/29] drm/rockchip: vop: Add output selection registers for RK312x
        commit: 407eaa4aa64a8429094fa75fac00fff5e471138d
[03/29] drm/rockchip: inno_hdmi: Fix video timing
        commit: 47a145c03484d33e65d773169d5ca1b9fe2a492e
[04/29] drm/rockchip: inno_hdmi: Remove useless mode_fixup
        commit: 099be7b6718685ebafb417e74bb637abf992474a
[05/29] drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
        commit: 8f0df2012b8a94aed0cc450016f7592c24e92cfb
[06/29] drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
        commit: ff4d4fa76fcc19f7d5d261f717121f0a88ec4e30
[07/29] drm/rockchip: inno_hdmi: Get rid of mode_set
        commit: d3e040f450ec8e46ff42fa495a433b976ab47686
[08/29] drm/rockchip: inno_hdmi: no need to store vic
        commit: d7ba3d711cf537ef0ece14cd85d2113ca338a00b
[09/29] drm/rockchip: inno_hdmi: Remove unneeded has audio flag
        commit: f8723484e045ff2d176124484907ec0199c55a0c
[10/29] drm/rockchip: inno_hdmi: Remove useless input format
        commit: c1ceee3248742149d1a602fd913bd88857da1d52
[11/29] drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents
        commit: 139771b8239c43ad1bd6c2976aa12788096a5483
[12/29] drm/rockchip: inno_hdmi: Remove tmds rate from structure
        commit: 5f92474844a4fcb7997da20dd1de2031aed1d794

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From heiko at sntech.de  Fri Dec 29 15:42:11 2023
From: heiko at sntech.de (Heiko Stuebner)
Date: Sat, 30 Dec 2023 00:42:11 +0100
Subject: (subset) [PATCH v4 00/29] Add HDMI support for RK3128
In-Reply-To: <20231222174220.55249-1-knaerzche@gmail.com>
References: <20231222174220.55249-1-knaerzche@gmail.com>
Message-ID: <170389332196.2712965.572879488382890334.b4-ty@sntech.de>

On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote:
> This is version 4 of my series that aims to add support for the display
> controller (VOP) and the HDMI controller block of RK3128 (which is very
> similar to the one found in RK3036). The original intention of this series
> was to add support for this slightly different integration but is by now,
> driven by maintainer's feedback, exploded to be a rework of inno-hdmi
> driver in large parts. It is, however, a change for the better.
> 
> [...]

Applied, thanks!

[13/29] drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe support
        commit: aa4f96e2de82f5e0dfc0102d08f66918c5e3637f
[14/29] drm/rockchip: inno_hdmi: Move infoframe disable to separate function
        commit: cc9ec38cb2cd32518fe02615d004e96ce2fd0348
[15/29] drm/rockchip: inno_hdmi: Switch to infoframe type
        commit: 4278ff62b73936a9138b60cc0610381003132b77
[16/29] drm/rockchip: inno_hdmi: Remove unused drm device pointer
        commit: 153fe8dbd866869846af3a359ecf82d5ad9fe247
[17/29] drm/rockchip: inno_hdmi: Drop irq struct member
        commit: 073aa696f8cbc170a2c3502c2165aeb835be0156
[18/29] drm/rockchip: inno_hdmi: Remove useless include
        commit: f68a68fe9d9197ea6aa9cb461270685f370b165e
[19/29] drm/rockchip: inno_hdmi: Subclass connector state
        commit: ceeb0f0104a62c867656c2730a51df47e7350b8f
[20/29] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
        commit: 164abbd2b7ef62aae6fc80450a2d085acdc3da3e
[21/29] drm/rockchip: inno_hdmi: Don't power up the phy after resetting
        commit: 71892cee6ceb3e1b88e0bb44b05c8397d8261a85
[22/29] drm/rockchip: inno_hdmi: Split power mode setting
        commit: f01e33cb586b5fd354cba73052f82c3b4246109d

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From konrad.dybcio at linaro.org  Fri Dec 29 15:51:50 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Sat, 30 Dec 2023 00:51:50 +0100
Subject: [PATCH v2 1/8] dt-bindings: clock: qcom: Allow VDD_GFX supply to
 GX
In-Reply-To: <20231227203048.GB1315173@hu-bjorande-lv.qualcomm.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-1-4763246b72c0@quicinc.com>
 <26617c83-31b3-4ad9-8a61-0b8271fad41f@linaro.org>
 <20231227203048.GB1315173@hu-bjorande-lv.qualcomm.com>
Message-ID: <4e56729e-0549-4075-8f6c-a43c84ae9b9a@linaro.org>

On 27.12.2023 21:30, Bjorn Andersson wrote:
> On Fri, Dec 22, 2023 at 09:12:04AM +0100, Krzysztof Kozlowski wrote:
>> On 22/12/2023 05:39, Bjorn Andersson wrote:
>>> In some designs the SoC's VDD_GFX pads are supplied by an external
>>> regulator, rather than a power-domain. Allow this to be described in the
>>> GPU clock controller binding.
>>>
>>> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
>>> ---
>>>  Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 16 ++++++++++++++++
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
>>> index f369fa34e00c..c0dd24c9dcb3 100644
>>> --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
>>> +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
>>> @@ -53,6 +53,9 @@ properties:
>>>    power-domains:
>>>      maxItems: 1
>>>  
>>> +  vdd-gfx-supply:
>>> +    description: Regulator supply for the VDD_GFX pads
>>> +
>>>    '#clock-cells':
>>>      const: 1
>>>  
>>> @@ -74,6 +77,19 @@ required:
>>>    - '#reset-cells'
>>>    - '#power-domain-cells'
>>>  
>>> +# Allow either power-domains or vdd-gfx-supply, not both
>>> +oneOf:
>>> +  - required:
>>> +      - power-domains
>>> +  - required:
>>> +      - vdd-gfx-supply
>>
>> This should be enough, assuming one of them is actually required. The
>> code. See also:
>> https://elixir.bootlin.com/linux/v5.17-rc2/source/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml#L91
>>
> 
> Yes, that would be the correct binding. But the majority of our
> DeviceTree source does not specify a power-domain for their gpucc.
> 
> While this should be corrected, it seem reasonable to leave this
> optional for now.
Moreover, I think it would be reasonable to add power-domains as
required in qcom,gcc.yaml. IIRC all "normal" (not q6) clock controllers
use at least CX+MX, with perhaps more hw-specific domains for some clocks
or GDSCs.

Konrad


From andre.przywara at arm.com  Fri Dec 29 15:55:43 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 29 Dec 2023 23:55:43 +0000
Subject: [PATCH 2/2] arm64: dts: allwinner: h616: Add Sipeed Longan SoM
 3H and Pi 3H board support
In-Reply-To: <20231228145647.1470-3-jszhang@kernel.org>
References: <20231228145647.1470-1-jszhang@kernel.org>
	<20231228145647.1470-3-jszhang@kernel.org>
Message-ID: <20231229235543.7548cafa@minigeek.lan>

On Thu, 28 Dec 2023 22:56:47 +0800
Jisheng Zhang <jszhang at kernel.org> wrote:

Hi,

> The Sipeed Longan SoM 3H is a system on module based on the Allwinner
> H618 SoC. The SoM features:
> 
> - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
> - 2/4 GiB LPDDR4 DRAM SoMs
> - AXP313a PMIC
> - eMMC
> 
> The Sipeed Longan PI 3H is a development board based on the above SoM.
> The board features:
> - Longan SoM 3H
> - Raspberry-Pi-1 compatible GPIO header
> - 2 USB 2.0 host port
> - 1 USB 2.0 type C port (power supply + OTG)
> - MicroSD slot
> - 1Gbps Ethernet port (via RTL8211 PHY)
> - HDMI port
> - WiFi/BT chip
> 
> Add the devicetree file describing the currently supported features,
> namely PMIC, LEDs, UART, SD card, eMMC, USB and Ethernet.
> 
> Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
> ---
>  arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>  .../sun50i-h618-longan-module-3h.dtsi         |  82 +++++++++++
>  .../dts/allwinner/sun50i-h618-longanpi-3h.dts | 133 ++++++++++++++++++
>  3 files changed, 216 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-longanpi-3h.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 3aca6787a167..00db504a9b8c 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -42,4 +42,5 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-longanpi-3h.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero3.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
> new file mode 100644
> index 000000000000..88a7d287b73c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
> @@ -0,0 +1,82 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) Jisheng Zhang <jszhang at kernel.org>
> + */
> +
> +/dts-v1/;

I don't see how the SoM could be used on its own, without a hosting
board. So we don't need the dts version tag in the .dtsi, that would
just be double when we are going to compile any actual .dtb.

> +
> +#include "sun50i-h616.dtsi"
> +
> +/ {
> +	model = "Sipeed Longan Module 3H";
> +	compatible = "sipeed,longan-module-3h", "allwinner,sun50i-h618";

Same here, any model or compatible string would only be overwritten by
the board versions, so you don't need those two in the SoM .dtsi.
Compare the SoPine and BTT CB1 .dtsi files.

> +};
> +
> +&mmc2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc2_pins>;

Can you please add the DS pin here? At the moment the sunxi Linux
driver doesn't support HS-400, but that can a) change and b) doesn't
affect the DT anyway, since that describes the hardware. The connection
is definitely there, according to the schematics.

> +	vmmc-supply = <&reg_dldo1>;
> +	vqmmc-supply = <&reg_aldo1>;
> +	bus-width = <8>;
> +	non-removable;
> +	cap-mmc-hw-reset;
> +	mmc-ddr-1_8v;
> +	mmc-hs200-1_8v;
> +	status = "okay";
> +};
> +
> +&r_i2c {
> +	status = "okay";
> +
> +	axp313: pmic at 36 {
> +		compatible = "x-powers,axp313a";

According to the bindings you need:

	interrupt-controller;
	#interrupt-cells = <1>;

Even without the IRQ line connected. dt-validate complains about that.

Actually, do you know of any reason why it is not connected? I see it on
the SoM pins, is the idea that any *board* could dedicate a GPIO pin for
it, if needed?

> +		reg = <0x36>;
> +
> +		regulators {
> +			/* Supplies VCC-PLL, so needs to be always on. */
> +			reg_aldo1: aldo1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcc1v8";

Can you please use "vcc-1v8-pll" instead? Then you don't need the
comment.

> +			};
> +
> +			/* Supplies VCC-IO, so needs to be always on. */
> +			reg_dldo1: dldo1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-name = "vcc3v3";

Same here, "vcc-3v3-io" is the name we used lately, to avoid the
comment.

> +			};
> +
> +			reg_dcdc1: dcdc1 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <810000>;
> +				regulator-max-microvolt = <990000>;
> +				regulator-name = "vdd-gpu-sys";
> +			};
> +
> +			reg_dcdc2: dcdc2 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <810000>;
> +				regulator-max-microvolt = <1100000>;
> +				regulator-name = "vdd-cpu";
> +			};
> +
> +			reg_dcdc3: dcdc3 {
> +				regulator-always-on;
> +				regulator-min-microvolt = <1100000>;
> +				regulator-max-microvolt = <1100000>;
> +				regulator-name = "vdd-dram";
> +			};
> +		};
> +	};
> +};
> +
> +&pio {
> +	vcc-pc-supply = <&reg_dldo1>;
> +	vcc-pf-supply = <&reg_dldo1>;
> +	vcc-pg-supply = <&reg_aldo1>;
> +	vcc-ph-supply = <&reg_dldo1>;
> +	vcc-pi-supply = <&reg_dldo1>;
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-longanpi-3h.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-longanpi-3h.dts
> new file mode 100644
> index 000000000000..245583881549
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-longanpi-3h.dts
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) Jisheng Zhang <jszhang at kernel.org>
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h618-longan-module-3h.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> +	model = "Sipeed Longan Pi 3H";
> +	compatible = "sipeed,longan-pi-3h", "sipeed,longan-module-3h", "allwinner,sun50i-h618";
> +
> +	aliases {
> +		ethernet0 = &emac0;
> +		serial0 = &uart0;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led-0 {
> +			color = <LED_COLOR_ID_ORANGE>;
> +			function = LED_FUNCTION_INDICATOR;
> +			function-enumerator = <0>;
> +			gpios = <&pio 6 2 GPIO_ACTIVE_LOW>; /* PG2 */
> +		};
> +
> +		led-1 {
> +			color = <LED_COLOR_ID_ORANGE>;
> +			function = LED_FUNCTION_INDICATOR;
> +			function-enumerator = <1>;
> +			gpios = <&pio 6 4 GPIO_ACTIVE_LOW>; /* PG4 */
> +		};
> +	};
> +
> +	reg_vcc5v: vcc5v {
> +		/* board wide 5V supply directly from the USB-C socket */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-5v";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-always-on;
> +	};

According to the schematic, there is a discrete 5V->3.3V regulator, can
you please describe this here as well?

> +};
> +
> +&axp313 {
> +	vin1-supply = <&reg_vcc5v>;
> +	vin2-supply = <&reg_vcc5v>;
> +	vin3-supply = <&reg_vcc5v>;
> +};
> +
> +&ehci1 {
> +	status = "okay";
> +};
> +
> +&ohci1 {
> +	status = "okay";
> +};
> +
> +&ehci2 {
> +	status = "okay";
> +};
> +
> +&ohci2 {
> +	status = "okay";
> +};
> +

Maybe worth adding a comment here that there is a USB WiFi chip
connected to those pins.

> +&ehci3 {
> +	status = "okay";
> +};
> +
> +&ohci3 {
> +	status = "okay";
> +};
> +
> +&emac0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ext_rgmii_pins>;
> +	phy-mode = "rgmii";
> +	phy-handle = <&ext_rgmii_phy>;
> +	allwinner,rx-delay-ps = <3100>;
> +	allwinner,tx-delay-ps = <700>;
> +	phy-supply = <&reg_dldo1>;

If I get the schematic correctly, the PHY is powered from the discrete
3.3V regulator? In fact, the 3V3-DLDO-OUT/1V8-ALDO-OUT pins on the SoM
do not seem to be connected, so anything using 3.3V or 1.8V on the
board needs to be fed from this regulator, and everything on the SoM is
supplied by the AXP?

> +	status = "okay";
> +};
> +
> +&mdio0 {
> +	ext_rgmii_phy: ethernet-phy at 1 {
> +		compatible = "ethernet-phy-ieee802.3-c22";
> +		reg = <1>;
> +	};
> +};
> +
> +&mmc0 {
> +	bus-width = <4>;
> +	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;	/* PF6 */
> +	vmmc-supply = <&reg_dldo1>;

According to the schematic, the SD card is supplied by the discrete
3.3V regulator on the board.

> +	status = "okay";
> +};
> +
> +&uart0 {
> +	status = "okay";
> +};
> +
> +&usbotg {
> +	/*
> +	 * PHY0 pins are connected to a USB-C socket, but a role switch
> +	 * is not implemented: both CC pins are pulled to GND.
> +	 * The VBUS pins power the device, so a fixed peripheral mode
> +	 * is the best choice.
> +	 * The board can be powered via GPIOs, in this case port0 *can*
> +	 * act as a host (with a cable/adapter ignoring CC), as VBUS is
> +	 * then provided by the GPIOs. Any user of this setup would
> +	 * need to adjust the DT accordingly: dr_mode set to "host",
> +	 * enabling OHCI0 and EHCI0.
> +	 */
> +	dr_mode = "peripheral";
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	usb1_vbus-supply = <&reg_vcc5v>;

The same seems to be true for USB2 as well, and the WiFi chip on USB3 is
powered by the discrete 3.3V regulator. But I think we don't need these
properties at all if it's directly connected to the input and so always
powered. Or maybe we should do this anyway, and be it to make it clear
where the bus power is coming from?

Cheers,
Andre

P.S. I saw some U-Boot patches on some github. Most of them are
merged, but feel free to post the DT (same ones as here) and the
defconfig to the U-Boot list as well. You can use "make savedefconfig"
when you have configured the board, this will create a file "defconfig"
in the build directory that contains the minimal items, this can be
directly used as a defconfig.

> +	status = "okay";
> +};



From andre.przywara at arm.com  Fri Dec 29 15:56:12 2023
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 29 Dec 2023 23:56:12 +0000
Subject: [PATCH 1/2] dt-bindings: arm: sunxi: Add Sipeed Longan Module
 3H and Longan Pi 3H
In-Reply-To: <20231228145647.1470-2-jszhang@kernel.org>
References: <20231228145647.1470-1-jszhang@kernel.org>
	<20231228145647.1470-2-jszhang@kernel.org>
Message-ID: <20231229235612.2c37e1fa@minigeek.lan>

On Thu, 28 Dec 2023 22:56:46 +0800
Jisheng Zhang <jszhang at kernel.org> wrote:

Hi Jisheng,

thanks for sending this, seems to be on time with the release of the
hardware. Don't see that very often!

> Add name & compatible for the Sipeed Longan Module 3H and Longan PI 3H
> board.
> 
> Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index 11c5ce941dd7..34d8ae484e01 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -835,6 +835,13 @@ properties:
>            - const: sinlinx,sina33
>            - const: allwinner,sun8i-a33
>  
> +      - description: Sipeed Longan Pi 3H board for the Sipeed Longan Module 3H
> +        items:
> +          - enum:
> +              - sipeed,longan-pi-3h

The picture of the SoM suggests that it cannot be used on its own, so
for anything usable we will always need both the SoM and some board.
Definitely we do for this board. So please follow the example for the
SoPine (or other SoM based boards), and just name all three names as
"const" items.

Cheers,
Andre

> +          - const: sipeed,longan-module-3h
> +          - const: allwinner,sun50i-h618
> +
>        - description: SourceParts PopStick v1.1
>          items:
>            - const: sourceparts,popstick-v1.1



From lkp at intel.com  Fri Dec 29 18:01:55 2023
From: lkp at intel.com (kernel test robot)
Date: Sat, 30 Dec 2023 10:01:55 +0800
Subject: [PATCH] pwm: imx27: workaround of the pwm output bug
In-Reply-To: <20231229063013.1786-1-pratikmanvar09@gmail.com>
References: <20231229063013.1786-1-pratikmanvar09@gmail.com>
Message-ID: <202312300907.RGtYsKxb-lkp@intel.com>

Hi,

kernel test robot noticed the following build warnings:

[auto build test WARNING on thierry-reding-pwm/for-next]
[also build test WARNING on linus/master v6.7-rc7 next-20231222]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/pratikmanvar09-gmail-com/pwm-imx27-workaround-of-the-pwm-output-bug/20231229-143435
base:   https://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git for-next
patch link:    https://lore.kernel.org/r/20231229063013.1786-1-pratikmanvar09%40gmail.com
patch subject: [PATCH] pwm: imx27: workaround of the pwm output bug
config: arm-randconfig-r133-20231230 (https://download.01.org/0day-ci/archive/20231230/202312300907.RGtYsKxb-lkp at intel.com/config)
compiler: clang version 18.0.0git (https://github.com/llvm/llvm-project 8a4266a626914765c0c69839e8a51be383013c1a)
reproduce: (https://download.01.org/0day-ci/archive/20231230/202312300907.RGtYsKxb-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312300907.RGtYsKxb-lkp at intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/pwm/pwm-imx27.c:303:26: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [usertype] sar_last @@     got restricted __le32 [usertype] @@
   drivers/pwm/pwm-imx27.c:303:26: sparse:     expected unsigned int [usertype] sar_last
   drivers/pwm/pwm-imx27.c:303:26: sparse:     got restricted __le32 [usertype]
>> drivers/pwm/pwm-imx27.c:304:29: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [usertype] sar_current @@     got restricted __le32 [usertype] @@
   drivers/pwm/pwm-imx27.c:304:29: sparse:     expected unsigned int [usertype] sar_current
   drivers/pwm/pwm-imx27.c:304:29: sparse:     got restricted __le32 [usertype]

vim +303 drivers/pwm/pwm-imx27.c

   219	
   220	static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
   221				   const struct pwm_state *state)
   222	{
   223		unsigned long period_cycles, duty_cycles, prescale, counter_check, flags;
   224		struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
   225		void __iomem *reg_sar = imx->mmio_base + MX3_PWMSAR;
   226		__force u32 sar_last, sar_current;
   227		struct pwm_state cstate;
   228		unsigned long long c;
   229		unsigned long long clkrate;
   230		int ret;
   231		u32 cr, timeout = 1000;
   232	
   233		pwm_get_state(pwm, &cstate);
   234	
   235		clkrate = clk_get_rate(imx->clk_per);
   236		c = clkrate * state->period;
   237	
   238		do_div(c, NSEC_PER_SEC);
   239		period_cycles = c;
   240	
   241		prescale = period_cycles / 0x10000 + 1;
   242	
   243		period_cycles /= prescale;
   244		c = clkrate * state->duty_cycle;
   245		do_div(c, NSEC_PER_SEC);
   246		duty_cycles = c;
   247		duty_cycles /= prescale;
   248	
   249		/*
   250		 * according to imx pwm RM, the real period value should be PERIOD
   251		 * value in PWMPR plus 2.
   252		 */
   253		if (period_cycles > 2)
   254			period_cycles -= 2;
   255		else
   256			period_cycles = 0;
   257	
   258		/*
   259		 * Wait for a free FIFO slot if the PWM is already enabled, and flush
   260		 * the FIFO if the PWM was disabled and is about to be enabled.
   261		 */
   262		if (cstate.enabled) {
   263			pwm_imx27_wait_fifo_slot(chip, pwm);
   264		} else {
   265			ret = pwm_imx27_clk_prepare_enable(imx);
   266			if (ret)
   267				return ret;
   268	
   269			pwm_imx27_sw_reset(chip);
   270		}
   271	
   272		/*
   273		 * This is a limited workaround. When the SAR FIFO is empty, the new
   274		 * write value will be directly applied to SAR even the current period
   275		 * is not over.
   276		 * If the new SAR value is less than the old one, and the counter is
   277		 * greater than the new SAR value, the current period will not filp
   278		 * the level. This will result in a pulse with a duty cycle of 100%.
   279		 * So, writing the current value of the SAR to SAR here before updating
   280		 * the new SAR value can avoid this issue.
   281		 *
   282		 * Add a spin lock and turn off the interrupt to ensure that the
   283		 * real-time performance can be guaranteed as much as possible when
   284		 * operating the following operations.
   285		 *
   286		 * 1. Add a threshold of 1.5us. If the time T between the read current
   287		 * count value CNR and the end of the cycle is less than 1.5us, wait
   288		 * for T to be longer than 1.5us before updating the SAR register.
   289		 * This is to avoid the situation that when the first SAR is written,
   290		 * the current cycle just ends and the SAR FIFO that just be written
   291		 * is emptied again.
   292		 *
   293		 * 2. Use __raw_writel() to minimize the interval between two writes to
   294		 * the SAR register to increase the fastest pwm frequency supported.
   295		 *
   296		 * When the PWM period is longer than 2us(or <500KHz), this workaround
   297		 * can solve this problem.
   298		 */
   299		if (duty_cycles < imx->duty_cycle) {
   300			c = clkrate * 1500;
   301			do_div(c, NSEC_PER_SEC);
   302			counter_check = c;
 > 303			sar_last = cpu_to_le32(imx->duty_cycle);
 > 304			sar_current = cpu_to_le32(duty_cycles);
   305	
   306			spin_lock_irqsave(&imx->lock, flags);
   307			if (state->period >= 2000) {
   308				while ((period_cycles -
   309					readl_relaxed(imx->mmio_base + MX3_PWMCNR))
   310					< counter_check) {
   311					if (!--timeout)
   312						break;
   313				};
   314			}
   315			if (!(MX3_PWMSR_FIFOAV &
   316			      readl_relaxed(imx->mmio_base + MX3_PWMSR)))
   317				__raw_writel(sar_last, reg_sar);
   318			__raw_writel(sar_current, reg_sar);
   319			spin_unlock_irqrestore(&imx->lock, flags);
   320		} else
   321			writel(duty_cycles, imx->mmio_base + MX3_PWMSAR);
   322	
   323		writel(period_cycles, imx->mmio_base + MX3_PWMPR);
   324	
   325		/*
   326		 * Store the duty cycle for future reference in cases where the
   327		 * MX3_PWMSAR register can't be read (i.e. when the PWM is disabled).
   328		 */
   329		imx->duty_cycle = duty_cycles;
   330	
   331		cr = MX3_PWMCR_PRESCALER_SET(prescale) |
   332		     MX3_PWMCR_STOPEN | MX3_PWMCR_DOZEN | MX3_PWMCR_WAITEN |
   333		     FIELD_PREP(MX3_PWMCR_CLKSRC, MX3_PWMCR_CLKSRC_IPG_HIGH) |
   334		     MX3_PWMCR_DBGEN;
   335	
   336		if (state->polarity == PWM_POLARITY_INVERSED)
   337			cr |= FIELD_PREP(MX3_PWMCR_POUTC,
   338					MX3_PWMCR_POUTC_INVERTED);
   339	
   340		if (state->enabled)
   341			cr |= MX3_PWMCR_EN;
   342	
   343		writel(cr, imx->mmio_base + MX3_PWMCR);
   344	
   345		if (!state->enabled)
   346			pwm_imx27_clk_disable_unprepare(imx);
   347	
   348		return 0;
   349	}
   350	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From xiaolei.wang at windriver.com  Fri Dec 29 21:38:31 2023
From: xiaolei.wang at windriver.com (Xiaolei Wang)
Date: Sat, 30 Dec 2023 13:38:31 +0800
Subject: [PATCH] firmware: imx: scu: ensure wakeup procedure calls pm_system_wakeup()
Message-ID: <20231230053831.67661-1-xiaolei.wang@windriver.com>

There will still be mu irq in the suspend stage, for
example, in imx8. When the system enters the suspend
state, the GPIO enters the pad wakeup state. Calling
pm_system_wakeup() at this time will cause the system
suspend to terminate, so when it is set to wakeup, call
pm_system_wakeup(), through rtcwake -s 10 -v -m freeze
verification.

mxc_gpio_noirq_suspend
     mxc_gpio_set_pad_wakeup
         mbox_send_message
              imx_mu_isr
                 imx_mu_generic_rxdb

Fixes: 0caf847975b2 ("firmware: imx: make sure MU irq can wake up system from suspend mode")
Signed-off-by: Xiaolei Wang <xiaolei.wang at windriver.com>
---
 drivers/firmware/imx/imx-scu-irq.c |  4 +++-
 drivers/firmware/imx/imx-scu.c     | 20 ++++++++++++++++++++
 include/linux/firmware/imx/sci.h   |  1 +
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/imx/imx-scu-irq.c b/drivers/firmware/imx/imx-scu-irq.c
index 6125cccc9ba7..099a1f50d995 100644
--- a/drivers/firmware/imx/imx-scu-irq.c
+++ b/drivers/firmware/imx/imx-scu-irq.c
@@ -20,6 +20,7 @@
 #define IMX_SC_IRQ_NUM_GROUP	9
 
 static u32 mu_resource_id;
+int scu_suspend;
 
 struct imx_sc_msg_irq_get_status {
 	struct imx_sc_rpc_msg hdr;
@@ -109,7 +110,8 @@ static void imx_scu_irq_work_handler(struct work_struct *work)
 			scu_irq_wakeup[i].wakeup_src = irq_status;
 		}
 
-		pm_system_wakeup();
+		if (scu_suspend)
+			pm_system_wakeup();
 		imx_scu_irq_notifier_call_chain(irq_status, &i);
 	}
 }
diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index 1dd4362ef9a3..b9f5c5eb4581 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -342,10 +342,30 @@ static int imx_scu_probe(struct platform_device *pdev)
 	return devm_of_platform_populate(dev);
 }
 
+
+
 static const struct of_device_id imx_scu_match[] = {
 	{ .compatible = "fsl,imx-scu", },
 	{ /* Sentinel */ }
 };
+static int __maybe_unused imx_scu_suspend_noirq(struct device *dev)
+{
+	scu_suspend = true;
+
+	return 0;
+}
+
+static int __maybe_unused imx_scu_resume_noirq(struct device *dev)
+{
+	scu_suspend = false;
+
+	return 0;
+};
+
+static const struct dev_pm_ops imx_scu_pm_ops = {
+	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_scu_suspend_noirq,
+				      imx_scu_resume_noirq)
+};
 
 static struct platform_driver imx_scu_driver = {
 	.driver = {
diff --git a/include/linux/firmware/imx/sci.h b/include/linux/firmware/imx/sci.h
index df17196df5ff..244df9c7629d 100644
--- a/include/linux/firmware/imx/sci.h
+++ b/include/linux/firmware/imx/sci.h
@@ -17,6 +17,7 @@
 #include <linux/firmware/imx/svc/rm.h>
 
 #if IS_ENABLED(CONFIG_IMX_SCU)
+extern int scu_suspend;
 int imx_scu_enable_general_irq_channel(struct device *dev);
 int imx_scu_irq_register_notifier(struct notifier_block *nb);
 int imx_scu_irq_unregister_notifier(struct notifier_block *nb);
-- 
2.25.1



From suzuki.poulose at arm.com  Sat Dec 30 01:39:50 2023
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Sat, 30 Dec 2023 09:39:50 +0000
Subject: [PATCH v3 6/8] coresight-tpdm: Add timestamp control register
 support for the CMB
In-Reply-To: <797eadf6-2708-47ad-a61f-88bb0d4fcf28@quicinc.com>
References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com>
 <1700533494-19276-7-git-send-email-quic_taozha@quicinc.com>
 <ebd7e310-d1b4-4b2e-a915-6241e04763d4@arm.com>
 <b61c3d70-7277-4fe7-ab67-8afc1062c737@quicinc.com>
 <cdad425c-b965-44c7-a612-1c99341e95b9@arm.com>
 <b7ef4e75-69c6-4251-8f9c-58682699e3f6@quicinc.com>
 <cc7b83ec-2c97-4a5d-87a9-36f1e13d8fc4@arm.com>
 <797eadf6-2708-47ad-a61f-88bb0d4fcf28@quicinc.com>
Message-ID: <4ae81e28-1791-4128-860f-eb6a83ea3742@arm.com>

On 25/12/2023 01:55, Tao Zhang wrote:
> 
> On 12/20/2023 7:07 PM, Suzuki K Poulose wrote:
>> On 20/12/2023 09:51, Tao Zhang wrote:
>>>
>>> On 12/19/2023 9:51 PM, Suzuki K Poulose wrote:
>>>> On 19/12/2023 02:43, Tao Zhang wrote:
>>>>>
>>>>> On 12/18/2023 6:46 PM, Suzuki K Poulose wrote:
>>>>>> On 21/11/2023 02:24, Tao Zhang wrote:
>>>>>>> CMB_TIER register is CMB subunit timestamp insertion enable 
>>>>>>> register.
>>>>>>> Bit 0 is PATT_TSENAB bit. Set this bit to 1 to request a timestamp
>>>>>>> following a CMB interface pattern match. Bit 1 is XTRIG_TSENAB bit.
>>>>>>> Set this bit to 1 to request a timestamp following a CMB CTI 
>>>>>>> timestamp
>>>>>>> request. Bit 2 is TS_ALL bit. Set this bit to 1 to request timestamp
>>>>>>> for all packets.
>>>>>>>
>>>>>>> Reviewed-by: James Clark <james.clark at arm.com>
>>>>>>> Signed-off-by: Tao Zhang <quic_taozha at quicinc.com>
>>>>>>> Signed-off-by: Jinlong Mao <quic_jinlmao at quicinc.com>
>>>>>>> ---
>>>>>>> ? .../testing/sysfs-bus-coresight-devices-tpdm? |? 35 ++++++
>>>>>>> ? drivers/hwtracing/coresight/coresight-tpdm.c? | 116 
>>>>>>> +++++++++++++++++-
>>>>>>> ? drivers/hwtracing/coresight/coresight-tpdm.h? |? 14 +++
>>>>>>> ? 3 files changed, 162 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>> diff --git 
>>>>>>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm 
>>>>>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>>>>> index 53662ce7c2d0..e0b77107be13 100644
>>>>>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>>>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>>>>> @@ -214,3 +214,38 @@ KernelVersion??? 6.7
>>>>>>> ? Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>>>> ? Description:
>>>>>>> ????????? (RW) Set/Get the mask of the pattern for the CMB 
>>>>>>> subunit TPDM.
>>>>>>> +
>>>>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
>>>>>>> +Date:??????? September 2023
>>>>>>> +KernelVersion??? 6.7
>>>>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>>>> +Description:
>>>>>>> +??????? (Write) Set the pattern timestamp of CMB tpdm. Read
>>>>>>> +??????? the pattern timestamp of CMB tpdm.
>>>>>>> +
>>>>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>>>>> +??????? 0 : Disable CMB pattern timestamp.
>>>>>>> +??????? 1 : Enable CMB pattern timestamp.
>>>>>>> +
>>>>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
>>>>>>> +Date:??????? September 2023
>>>>>>> +KernelVersion??? 6.7
>>>>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>>>> +Description:
>>>>>>> +??????? (RW) Set/Get the trigger timestamp of the CMB for tpdm.
>>>>>>> +
>>>>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>>>>> +??????? 0 : Set the CMB trigger type to false
>>>>>>> +??????? 1 : Set the CMB trigger type to true
>>>>>>> +
>>>>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
>>>>>>> +Date:??????? September 2023
>>>>>>> +KernelVersion??? 6.7
>>>>>>> +Contact:??? Jinlong Mao (QUIC) <quic_jinlmao at quicinc.com>, Tao 
>>>>>>> Zhang (QUIC) <quic_taozha at quicinc.com>
>>>>>>> +Description:
>>>>>>> +??????? (RW) Read or write the status of timestamp upon all 
>>>>>>> interface.
>>>>>>> +??????? Only value 0 and 1? can be written to this node. Set 
>>>>>>> this node to 1 to requeset
>>>>>>> +??????? timestamp to all trace packet.
>>>>>>> +??????? Accepts only one of the 2 values -? 0 or 1.
>>>>>>> +??????? 0 : Disable the timestamp of all trace packets.
>>>>>>> +??????? 1 : Enable the timestamp of all trace packets.
>>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c 
>>>>>>> b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>>> index 894d4309f1c7..f6cda5616e84 100644
>>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>>> @@ -331,6 +331,36 @@ static void tpdm_enable_dsb(struct 
>>>>>>> tpdm_drvdata *drvdata)
>>>>>>> ????? writel_relaxed(val, drvdata->base + TPDM_DSB_CR);
>>>>>>> ? }
>>>>>>> ? +static void set_cmb_tier(struct tpdm_drvdata *drvdata)
>>>>>>> +{
>>>>>>> +??? u32 val;
>>>>>>> +
>>>>>>> +??? val = readl_relaxed(drvdata->base + TPDM_CMB_TIER);
>>>>>>> +
>>>>>>> +??? /* Clear all relevant fields */
>>>>>>> +??? val &= ~(TPDM_CMB_TIER_PATT_TSENAB | TPDM_CMB_TIER_TS_ALL |
>>>>>>> +???????? TPDM_CMB_TIER_XTRIG_TSENAB);
>>>>>>> +
>>>>>>> +??? /* Set pattern timestamp type and enablement */
>>>>>>> +??? if (drvdata->cmb->patt_ts)
>>>>>>> +??????? val |= TPDM_CMB_TIER_PATT_TSENAB;
>>>>>>
>>>>>> ?-- cut --
>>>>>>> +??? else
>>>>>>> +??????? val &= ~TPDM_CMB_TIER_PATT_TSENAB;
>>>>>>
>>>>>>
>>>>>> All the else cases in this function are superfluous. Please remove 
>>>>>> all
>>>>>> of them.
>>>>> I will update this in the next patch.
>>>>>>
>>>>>>> +
>>>>>>> +??? /* Set trigger timestamp */
>>>>>>> +??? if (drvdata->cmb->trig_ts)
>>>>>>> +??????? val |= TPDM_CMB_TIER_XTRIG_TSENAB;
>>>>>>> +??? else
>>>>>>> +??????? val &= ~TPDM_CMB_TIER_XTRIG_TSENAB;
>>>>>>> +
>>>>>>> +??? /* Set all timestamp enablement*/
>>>>>>> +??? if (drvdata->cmb->ts_all)
>>>>>>> +??????? val |= TPDM_CMB_TIER_TS_ALL;
>>>>>>> +??? else
>>>>>>> +??????? val &= ~TPDM_CMB_TIER_TS_ALL;
>>>>>>> +??? writel_relaxed(val, drvdata->base + TPDM_CMB_TIER);
>>>>>>> +}
>>>>>>> +
>>>>>>> ? static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata)
>>>>>>> ? {
>>>>>>> ????? u32 val, i;
>>>>>>> @@ -347,6 +377,8 @@ static void tpdm_enable_cmb(struct 
>>>>>>> tpdm_drvdata *drvdata)
>>>>>>> ????????????????? drvdata->base + TPDM_CMB_XPMR(i));
>>>>>>> ????? }
>>>>>>> ? +??? set_cmb_tier(drvdata);
>>>>>>> +
>>>>>>> ????? val = readl_relaxed(drvdata->base + TPDM_CMB_CR);
>>>>>>> ????? /*
>>>>>>> ?????? * Set to 0 for continuous CMB collection mode,
>>>>>>> @@ -695,9 +727,17 @@ static ssize_t enable_ts_show(struct device 
>>>>>>> *dev,
>>>>>>> ??????????????????? char *buf)
>>>>>>> ? {
>>>>>>> ????? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>>> +??? ssize_t size = 0;
>>>>>>> ? -??? return sysfs_emit(buf, "%u\n",
>>>>>>> -???????????? (unsigned int)drvdata->dsb->patt_ts);
>>>>>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>>>>>> +??????? size = sysfs_emit(buf, "%u\n",
>>>>>>> +???????????????? (unsigned int)drvdata->dsb->patt_ts);
>>>>>>> +
>>>>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>>>>> +??????? size = sysfs_emit(buf, "%u\n",
>>>>>>> +???????????????? (unsigned int)drvdata->cmb->patt_ts);
>>>>>>
>>>>>> Why does this need to show two values ? This must only show ONE 
>>>>>> value.
>>>>>> How you deduce that might be based on the availability of the feature
>>>>>> set. Or store the TS value in the drvdata and use that instead for
>>>>>> controlling CMB/DSB.
>>>>>
>>>>> Since both of CMB/DSB need to have "enable_ts" SysFs file, can I 
>>>>> separate them
>>>>
>>>> The question really is, do we need fine grained control. i.e.,
>>>>
>>>> enable TS for DSB but not for CMB or vice versa.
>>>>
>>>> I am not an expert on the usage scenario of the same. So, if you/Qcomm
>>>> thinks the users need separate, fine grained control for timestamp
>>>> for the DSB and CMB, then yes, follow your recommendation below.
>>>> i.e., tpdm.../dsb_patt/enable_ts
>>>>
>>>>> as "enable_dsb_ts" and "enable_cmb_ts"? The path will be like below.
>>>>>
>>>>> tpdm0/dsb_patt/enable_dsb_ts
>>>>
>>>> You don't need enable_dsb_ts. It could be "enable_ts"
>>>>
>>>>>
>>>>> tpdm1/cmb_patt/enable_cmb_ts
>>>>>
>>>>> Is this design appropriate?
>>>>
>>>>
>>>> Otherwise, stick to single enable_ts : which enables the ts for both
>>>> CMB/DSB. And it only ever show one value : 0 (TS is disabled for both
>>>> CMB/DSB) 1 : TS enabled for both.
>>>
>>> We have a very special case, such as the TPDM supporting both CMB and
>>>
>>> DSB datasets. Although this case is very rare, it still exists.
>>>
>>> Can I use the data bit to instruct whether timestamp is enabled for 
>>> CMB/DSB or not? For example,
>>>
>>> size = sysfs_emit(buf, "%u\n",
>>> ???? ??? ??? ??? (unsigned int)(drvdata->dsb->patt_ts << 1 | 
>>> drvdata->cmb->patt_ts));
>>>
>>> Thus, this value can instruct the following situations.
>>>
>>> 0 - TS is disabled for both CMB/DSB
>>>
>>> 1 - TS is enabled for CMB
>>>
>>> 2 - TS is enabled for DSB
>>>
>>> 3 - TS is enabled for both
>>>
>>> Is this approach acceptable?
>>>
>>
>> No, please stick to separate controls for TS. Do not complicate
>> the user interface.
>>
>> i.e.,
>> tpdm0/dsb_patt/enable_ts
>> tpdm0/cmb_patt/enable_ts
> 
> We need to be able to control/show dsb and cmb timestamp enablement 
> independently.
> 
> Can we achieve this requirement if we use a sysfs file with the same name?

They are independent and in their respective directory (group) for CMB 
and DSB. What am I missing ?
e.g., if you want to enable TS for DSB, you do :

$ echo 1 > dsb_patt/enable_ts

And that only works for DSB not for CMB.

Suzuki

> 
> I'm not able to find a good way to achieve it. Do you have any 
> suggestions for this?
> 


> 
> Best,
> 
> Tao
> 
>>
>> Suzuki
>>
>>
>>>
>>> Best,
>>>
>>> Tao
>>>
>>>>
>>>> Suzuki
>>>>
>>>>
>>>>>>
>>>>
>>>>>> Also, the sysfs documentation needs update, if this is going to
>>>>>> control the CMB.
>>>>>
>>>>> Sure. I will update the SysFs documentation according to the 
>>>>> modification in the
>>>>>
>>>>> next patch series.
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> Tao
>>>>>
>>>>>>
>>>>>> Suzuki
>>>>>>
>>>>>>
>>>>>>> +
>>>>>>> +??? return size;
>>>>>>> ? }
>>>>>>> ? ? /*
>>>>>>> @@ -715,8 +755,13 @@ static ssize_t enable_ts_store(struct device 
>>>>>>> *dev,
>>>>>>> ????????? return -EINVAL;
>>>>>>> ? ????? spin_lock(&drvdata->spinlock);
>>>>>>> -??? drvdata->dsb->patt_ts = !!val;
>>>>>>> +??? if (tpdm_has_dsb_dataset(drvdata))
>>>>>>> +??????? drvdata->dsb->patt_ts = !!val;
>>>>>>> +
>>>>>>> +??? if (tpdm_has_cmb_dataset(drvdata))
>>>>>>> +??????? drvdata->cmb->patt_ts = !!val;
>>>>>>> ????? spin_unlock(&drvdata->spinlock);
>>>>>>> +
>>>>>>> ????? return size;
>>>>>>> ? }
>>>>>>> ? static DEVICE_ATTR_RW(enable_ts);
>>>>>>> @@ -851,6 +896,68 @@ static ssize_t cmb_mode_store(struct device 
>>>>>>> *dev,
>>>>>>> ? }
>>>>>>> ? static DEVICE_ATTR_RW(cmb_mode);
>>>>>>> ? +static ssize_t cmb_ts_all_show(struct device *dev,
>>>>>>> +?????????????????? struct device_attribute *attr,
>>>>>>> +?????????????????? char *buf)
>>>>>>> +{
>>>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>>> +
>>>>>>> +??? return sysfs_emit(buf, "%u\n",
>>>>>>> +????????????? (unsigned int)drvdata->cmb->ts_all);
>>>>>>> +}
>>>>>>> +
>>>>>>> +static ssize_t cmb_ts_all_store(struct device *dev,
>>>>>>> +??????????????? struct device_attribute *attr,
>>>>>>> +??????????????? const char *buf,
>>>>>>> +??????????????? size_t size)
>>>>>>> +{
>>>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>>> +??? unsigned long val;
>>>>>>> +
>>>>>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>>>>>> +??????? return -EINVAL;
>>>>>>> +
>>>>>>> +??? spin_lock(&drvdata->spinlock);
>>>>>>> +??? if (val)
>>>>>>> +??????? drvdata->cmb->ts_all = true;
>>>>>>> +??? else
>>>>>>> +??????? drvdata->cmb->ts_all = false;
>>>>>>> +??? spin_unlock(&drvdata->spinlock);
>>>>>>> +??? return size;
>>>>>>> +}
>>>>>>> +static DEVICE_ATTR_RW(cmb_ts_all);
>>>>>>> +
>>>>>>> +static ssize_t cmb_trig_ts_show(struct device *dev,
>>>>>>> +??????????????? struct device_attribute *attr,
>>>>>>> +??????????????? char *buf)
>>>>>>> +{
>>>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>>> +
>>>>>>> +??? return sysfs_emit(buf, "%u\n",
>>>>>>> +????????????? (unsigned int)drvdata->cmb->trig_ts);
>>>>>>> +}
>>>>>>> +
>>>>>>> +static ssize_t cmb_trig_ts_store(struct device *dev,
>>>>>>> +???????????????? struct device_attribute *attr,
>>>>>>> +???????????????? const char *buf,
>>>>>>> +???????????????? size_t size)
>>>>>>> +{
>>>>>>> +??? struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>>> +??? unsigned long val;
>>>>>>> +
>>>>>>> +??? if ((kstrtoul(buf, 0, &val)) || (val & ~1UL))
>>>>>>> +??????? return -EINVAL;
>>>>>>> +
>>>>>>> +??? spin_lock(&drvdata->spinlock);
>>>>>>> +??? if (val)
>>>>>>> +??????? drvdata->cmb->trig_ts = true;
>>>>>>> +??? else
>>>>>>> +??????? drvdata->cmb->trig_ts = false;
>>>>>>> +??? spin_unlock(&drvdata->spinlock);
>>>>>>> +??? return size;
>>>>>>> +}
>>>>>>> +static DEVICE_ATTR_RW(cmb_trig_ts);
>>>>>>> +
>>>>>>> ? static struct attribute *tpdm_dsb_edge_attrs[] = {
>>>>>>> ????? &dev_attr_ctrl_idx.attr,
>>>>>>> ????? &dev_attr_ctrl_val.attr,
>>>>>>> @@ -973,6 +1080,7 @@ static struct attribute 
>>>>>>> *tpdm_cmb_patt_attrs[] = {
>>>>>>> ????? CMB_PATT_ATTR(1),
>>>>>>> ????? CMB_PATT_MASK_ATTR(0),
>>>>>>> ????? CMB_PATT_MASK_ATTR(1),
>>>>>>> +??? &dev_attr_enable_ts.attr,
>>>>>>> ????? NULL,
>>>>>>> ? };
>>>>>>> ? @@ -985,6 +1093,8 @@ static struct attribute *tpdm_dsb_attrs[] = {
>>>>>>> ? ? static struct attribute *tpdm_cmb_attrs[] = {
>>>>>>> ????? &dev_attr_cmb_mode.attr,
>>>>>>> +??? &dev_attr_cmb_ts_all.attr,
>>>>>>> +??? &dev_attr_cmb_trig_ts.attr,
>>>>>>> ????? NULL,
>>>>>>> ? };
>>>>>>> ? diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h 
>>>>>>> b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>>> index e90d008c1cb2..65b7ca6c4077 100644
>>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>>> @@ -11,6 +11,8 @@
>>>>>>> ? ? /* CMB Subunit Registers */
>>>>>>> ? #define TPDM_CMB_CR??????? (0xA00)
>>>>>>> +/*CMB subunit timestamp insertion enable register*/
>>>>>>> +#define TPDM_CMB_TIER??????? (0xA04)
>>>>>>> ? /*CMB subunit timestamp pattern registers*/
>>>>>>> ? #define TPDM_CMB_TPR(n)??????? (0xA08 + (n * 4))
>>>>>>> ? /*CMB subunit timestamp pattern mask registers*/
>>>>>>> @@ -24,6 +26,12 @@
>>>>>>> ? #define TPDM_CMB_CR_ENA??????? BIT(0)
>>>>>>> ? /* Trace collection mode for CMB subunit */
>>>>>>> ? #define TPDM_CMB_CR_MODE??? BIT(1)
>>>>>>> +/* Timestamp control for pattern match */
>>>>>>> +#define TPDM_CMB_TIER_PATT_TSENAB??? BIT(0)
>>>>>>> +/* CMB CTI timestamp request */
>>>>>>> +#define TPDM_CMB_TIER_XTRIG_TSENAB??? BIT(1)
>>>>>>> +/* For timestamp fo all trace */
>>>>>>> +#define TPDM_CMB_TIER_TS_ALL??????? BIT(2)
>>>>>>> ? ? /*Patten register number*/
>>>>>>> ? #define TPDM_CMB_MAX_PATT??????? 2
>>>>>>> @@ -217,6 +225,9 @@ struct dsb_dataset {
>>>>>>> ?? * @patt_mask:??????? Save value for pattern mask
>>>>>>> ?? * @trig_patt:??????? Save value for trigger pattern
>>>>>>> ?? * @trig_patt_mask:?? Save value for trigger pattern mask
>>>>>>> + * @patt_ts:????????? Indicates if pattern match for timestamp 
>>>>>>> is enabled.
>>>>>>> + * @trig_ts:????????? Indicates if CTI trigger for timestamp is 
>>>>>>> enabled.
>>>>>>> + * @ts_all:?????????? Indicates if timestamp is enabled for all 
>>>>>>> packets.
>>>>>>> ?? */
>>>>>>> ? struct cmb_dataset {
>>>>>>> ????? u32??????????? trace_mode;
>>>>>>> @@ -224,6 +235,9 @@ struct cmb_dataset {
>>>>>>> ????? u32??????????? patt_mask[TPDM_CMB_MAX_PATT];
>>>>>>> ????? u32??????????? trig_patt[TPDM_CMB_MAX_PATT];
>>>>>>> ????? u32??????????? trig_patt_mask[TPDM_CMB_MAX_PATT];
>>>>>>> +??? bool??????????? patt_ts;
>>>>>>> +??? bool??????????? trig_ts;
>>>>>>> +??? bool??????????? ts_all;
>>>>>>> ? };
>>>>>>> ? ? /**
>>>>>>
>>>>
>>>> _______________________________________________
>>>> CoreSight mailing list -- coresight at lists.linaro.org
>>>> To unsubscribe send an email to coresight-leave at lists.linaro.org
>>
>> _______________________________________________
>> CoreSight mailing list -- coresight at lists.linaro.org
>> To unsubscribe send an email to coresight-leave at lists.linaro.org



From knaerzche at gmail.com  Sat Dec 30 01:46:42 2023
From: knaerzche at gmail.com (Alex Bee)
Date: Sat, 30 Dec 2023 10:46:42 +0100
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
In-Reply-To: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
References: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
Message-ID: <35df6456-2bc2-415d-bc61-09e4b440e2ac@gmail.com>

Hi, Jianfeng
Am 28.12.23 um 14:16 schrieb Jianfeng Liu:
> This is the v2 version of this series adding hantro g1 video decoder
> support for rk3588.
> 
> Changes in v2:
> - Fix alphabetical order in patch1 and patch3
> - Sort device tree node by bus-address
> - Drop rk3588_vpu_variant fron v1 because that is exactly the same as rk3568_vpu_variant
if the RK3568 and RK3588 variants match, patch [1/3] is not necessary. Just
document a additional compatible in a similar way it's being done for
rk3188/rk3066 or rk3228/rk3399.
If there are ever differences we don't know about yet, a additional variant
can still be added in the driver.

Alex


> - Link to v1: https://lore.kernel.org/all/20231227173911.3295410-1-liujianfeng1994 at gmail.com
> 
> Jianfeng Liu (3):
>    media: verisilicon: Add support for Hantro G1 on RK3588
>    arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588
>    dt-bindings: media: rockchip-vpu: Add RK3588 compatible
> 
>   .../bindings/media/rockchip-vpu.yaml          |  1 +
>   arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 20 +++++++++++++++++++
>   .../media/platform/verisilicon/hantro_drv.c   |  1 +
>   3 files changed, 22 insertions(+)
> 



From liujianfeng1994 at gmail.com  Sat Dec 30 01:52:28 2023
From: liujianfeng1994 at gmail.com (amazingfate)
Date: Sat, 30 Dec 2023 17:52:28 +0800
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
In-Reply-To: <CAAXNxMT3f68-ptM7Crhrfmn7iwTyJc9pwz4Beob+5beVODaSHQ@mail.gmail.com>
References: <CAAXNxMT3f68-ptM7Crhrfmn7iwTyJc9pwz4Beob+5beVODaSHQ@mail.gmail.com>
Message-ID: <20231230095228.3739806-1-liujianfeng1994@gmail.com>

Thanks for your test with fluster. I also tested on my rock-5b(rk3588)
and orangepi-3b(rk3566) which are sharing the same hantro g1 ip. I am
running on ubuntu jammy so I'm using gstreamer 1.20.1

rk3566 and rk3588 are sharing the same results:
JVT-AVC_V1 test suite with decoder GStreamer-H.264-V4L2SL-Gst1.0:
  Ran 112/135 tests successfully.
JVT-FR_EXT test suite with decoder GStreamer-H.264-V4L2SL-Gst1.0:
  Ran 27/69 tests successfully.
VP8-TEST-VECTORS test suite with decoder GStreamer-VP8-V4L2SL-Gst1.0:
  Ran 59/61 tests successfully.

H264 decoder test has less test case passing. I think that's because
of my low gstreamer version. If you have a rk356x board I guess you
will get the same result as rk3588. That should be the mainline support
status of hantro g1 decoder.

For ffmpeg at the moment fluster doesn't support v4l2-request decoder.
I tried Kwiboo's fork[1] but failed to pass tests with decoder
FFmpeg-H.264-V4L2-request. I can decode video with ffmpeg command like:
"ffmpeg -benchmark -hwaccel drm -hwaccel_output_format drm_prime -i Big_Buck_Bunny_1080_10s_30MB.mp4 -f null -"

[1] https://github.com/Kwiboo/fluster/tree/v4l2-request


From nadav.amit at broadcom.com  Sat Dec 30 01:54:02 2023
From: nadav.amit at broadcom.com (Nadav Amit)
Date: Sat, 30 Dec 2023 11:54:02 +0200
Subject: [PATCH 1/2] mm/tlb: fix fullmm semantics
In-Reply-To: <20231228084642.1765-2-jszhang@kernel.org>
References: <20231228084642.1765-1-jszhang@kernel.org>
 <20231228084642.1765-2-jszhang@kernel.org>
Message-ID: <204B6410-2EFA-462B-9DF7-64CC5F1D3AD2@broadcom.com>



> On Dec 28, 2023, at 10:46?AM, Jisheng Zhang <jszhang at kernel.org> wrote:
> 
> From: Nadav Amit <namit at vmware.com>
> 
> fullmm in mmu_gather is supposed to indicate that the mm is torn-down
> (e.g., on process exit) and can therefore allow certain optimizations.
> However, tlb_finish_mmu() sets fullmm, when in fact it want to say that
> the TLB should be fully flushed.
> 
> Change tlb_finish_mmu() to set need_flush_all and check this flag in
> tlb_flush_mmu_tlbonly() when deciding whether a flush is needed.
> 
> At the same time, bring the arm64 fullmm on process exit optimization back.
> 
> Signed-off-by: Nadav Amit <namit at vmware.com>
> Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
> Cc: Andrea Arcangeli <aarcange at redhat.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Andy Lutomirski <luto at kernel.org>
> Cc: Dave Hansen <dave.hansen at linux.intel.com>
> Cc: Peter Zijlstra <peterz at infradead.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Will Deacon <will at kernel.org>
> Cc: Yu Zhao <yuzhao at google.com>
> Cc: Nick Piggin <npiggin at gmail.com>
> Cc: x86 at kernel.org
> ---
> arch/arm64/include/asm/tlb.h | 5 ++++-
> include/asm-generic/tlb.h    | 2 +-
> mm/mmu_gather.c              | 2 +-
> 3 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
> index 846c563689a8..6164c5f3b78f 100644
> --- a/arch/arm64/include/asm/tlb.h
> +++ b/arch/arm64/include/asm/tlb.h
> @@ -62,7 +62,10 @@ static inline void tlb_flush(struct mmu_gather *tlb)
> 	 * invalidating the walk-cache, since the ASID allocator won't
> 	 * reallocate our ASID without invalidating the entire TLB.
> 	 */
> -	if (tlb->fullmm) {
> +	if (tlb->fullmm)
> +		return;
> +
> +	if (tlb->need_flush_all) {
> 		if (!last_level)
> 			flush_tlb_mm(tlb->mm);
> 		return;
> 

Thanks for pulling my patch out of the abyss, but the chunk above
did not come from my old patch.

My knowledge of arm64 is a bit limited, but the code does not seem
to match the comment, so if it is correct (which I strongly doubt),
the comment should be updated.

[1] https://lore.kernel.org/all/20210131001132.3368247-2-namit at vmware.com/


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


From liujianfeng1994 at gmail.com  Sat Dec 30 02:03:29 2023
From: liujianfeng1994 at gmail.com (amazingfate)
Date: Sat, 30 Dec 2023 18:03:29 +0800
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
In-Reply-To: <35df6456-2bc2-415d-bc61-09e4b440e2ac@gmail.com>
References: <35df6456-2bc2-415d-bc61-09e4b440e2ac@gmail.com>
Message-ID: <20231230100329.3740222-1-liujianfeng1994@gmail.com>

Jianfeng


From liujianfeng1994 at gmail.com  Sat Dec 30 02:09:30 2023
From: liujianfeng1994 at gmail.com (amazingfate)
Date: Sat, 30 Dec 2023 18:09:30 +0800
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
In-Reply-To: <35df6456-2bc2-415d-bc61-09e4b440e2ac@gmail.com>
References: <35df6456-2bc2-415d-bc61-09e4b440e2ac@gmail.com>
Message-ID: <20231230100930.3740439-1-liujianfeng1994@gmail.com>

>On Sat, 30 Dec 2023 10:46:42 +0100, Alex Bee <knaerzche at gmail.com> wrote:
>if the RK3568 and RK3588 variants match, patch [1/3] is not necessary. Just
>document a additional compatible in a similar way it's being done for
>rk3188/rk3066 or rk3228/rk3399.
>If there are ever differences we don't know about yet, a additional variant
>can still be added in the driver.

Hi Alex,
I did try to not touching hantro driver code and just enabling the node in
devicetree by a compatible property like:
compatible = "rockchip,rk3588-vpu", "rockchip,rk3568-vpu";
but the hantro g1 node is not binded by hantro driver. I guess that is
because hantro driver is already binded to the hantro av1 vpu on rk3588,
so I added patch[1/3] to make it work.

Jianfeng


From liujianfeng1994 at gmail.com  Sat Dec 30 02:20:25 2023
From: liujianfeng1994 at gmail.com (amazingfate)
Date: Sat, 30 Dec 2023 18:20:25 +0800
Subject: [PATCH v2 2/3] arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588
In-Reply-To: <CAAXNxMRkpM+dSV3azDFgm07ygJrXyS=Htz_h8Z_WMmeG0YZ+ig@mail.gmail.com>
References: <CAAXNxMRkpM+dSV3azDFgm07ygJrXyS=Htz_h8Z_WMmeG0YZ+ig@mail.gmail.com>
Message-ID: <20231230102025.3740749-1-liujianfeng1994@gmail.com>

On Fri, 29 Dec 2023 11:02:08 +0000, Hugh Cole-Baker <sigmaris at gmail.com> wrote:
>The node name should be video-codec at fdb50000 to match the reg address.

Hi,
Thanks a lot for youre review, I will change the node name in v3.

Jianfeng


From efectn at 6tel.net  Sat Dec 30 03:17:58 2023
From: efectn at 6tel.net (efectn at 6tel.net)
Date: Sat, 30 Dec 2023 14:17:58 +0300
Subject: [PATCH v2 0/3] Add Support for NanoPi R6S and R6C boards
Message-ID: <cover.1703934548.git.efectn@protonmail.com>

From: Muhammed Efe Cetin <efectn at protonmail.com>

Hi, this series add support for RK3588S based NanoPi R6S and R6C boards.

Changes on v2:
* Add commit message to dt-bindings patch.
* Fix dtbs_check warnings.
* Rename vcc_3v3_s0 -> avcc_3v3_s0 and create new fixed vcc_3v3_s0 regulator.
* Rename vdd_ddr_pll_s0 -> avdd_ddr_pll_s0.
* Rename vdd_0v85_s0 -> avdd_0v85_s0.
* Fix rk806_dvs1_null and rk806_dvs2_null on pmic node.
* Add system-power-controller property to pmic node.

Muhammed Efe Cetin (3):
  dt-bindings: arm: rockchip: Add NanoPi R6 series boards
  arm64: dts: rockchip: Add support for NanoPi R6S
  arm64: dts: rockchip: Add support for NanoPi R6C

 .../devicetree/bindings/arm/rockchip.yaml     |   7 +
 arch/arm64/boot/dts/rockchip/Makefile         |   2 +
 .../boot/dts/rockchip/rk3588s-nanopi-r6c.dts  |  14 +
 .../boot/dts/rockchip/rk3588s-nanopi-r6s.dts  | 764 ++++++++++++++++++
 4 files changed, 787 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts

-- 
2.43.0



From efectn at 6tel.net  Sat Dec 30 03:17:59 2023
From: efectn at 6tel.net (efectn at 6tel.net)
Date: Sat, 30 Dec 2023 14:17:59 +0300
Subject: [PATCH v2 1/3] dt-bindings: arm: rockchip: Add NanoPi R6 series boards
In-Reply-To: <cover.1703934548.git.efectn@protonmail.com>
References: <cover.1703934548.git.efectn@protonmail.com>
Message-ID: <30c1c7eac02cd32b76edb77572523f6ad8de89fb.1703934548.git.efectn@protonmail.com>

From: Muhammed Efe Cetin <efectn at protonmail.com>

Add support for NanoPi R6 series boards that based on RK3588S.

NanoPi R6S basically has:
- USB3
- USB2
- eMMC
- 2x 2.5GBe & 1x 1GBe ethernet
- HDMI
- SD card support

Unlike R6S variant, NanoPi R6C has PCIe M.2 M-key instead of 1x 2.5GBe.

Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ee92f0535..07c4eb828 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -225,6 +225,13 @@ properties:
               - friendlyarm,nanopi-r5s
           - const: rockchip,rk3568
 
+      - description: FriendlyElec NanoPi R6 series boards
+        items:
+          - enum:
+              - friendlyarm,nanopi-r6c
+              - friendlyarm,nanopi-r6s
+          - const: rockchip,rk3588s
+
       - description: FriendlyElec NanoPC T6
         items:
           - const: friendlyarm,nanopc-t6
-- 
2.43.0



From efectn at 6tel.net  Sat Dec 30 03:18:01 2023
From: efectn at 6tel.net (efectn at 6tel.net)
Date: Sat, 30 Dec 2023 14:18:01 +0300
Subject: [PATCH v2 3/3] arm64: dts: rockchip: Add support for NanoPi R6C
In-Reply-To: <cover.1703934548.git.efectn@protonmail.com>
References: <cover.1703934548.git.efectn@protonmail.com>
Message-ID: <0f9ee0baa6c9de4d54dd6d13957ca15a63ec934f.1703934548.git.efectn@protonmail.com>

From: Muhammed Efe Cetin <efectn at protonmail.com>

NanoPi R6C is mostly same as R6S variant. It has M2 port instead of a
NIC port and different led labeling.

Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
---
 arch/arm64/boot/dts/rockchip/Makefile              |  1 +
 .../arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts | 14 ++++++++++++++
 2 files changed, 15 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 634b9be47..f2d13482e 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -115,3 +115,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
new file mode 100644
index 000000000..497bbb570
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588s-nanopi-r6s.dts"
+
+/ {
+	model = "FriendlyElec NanoPi R6C";
+	compatible = "friendlyarm,nanopi-r6c", "rockchip,rk3588s";
+};
+
+&lan2_led {
+	label = "user_led";
+};
-- 
2.43.0



From efectn at 6tel.net  Sat Dec 30 03:18:00 2023
From: efectn at 6tel.net (efectn at 6tel.net)
Date: Sat, 30 Dec 2023 14:18:00 +0300
Subject: [PATCH v2 2/3] arm64: dts: rockchip: Add support for NanoPi R6S
In-Reply-To: <cover.1703934548.git.efectn@protonmail.com>
References: <cover.1703934548.git.efectn@protonmail.com>
Message-ID: <6db3b653efc6f0a2dca8e96fdd0503906db72fb6.1703934548.git.efectn@protonmail.com>

From: Muhammed Efe Cetin <efectn at protonmail.com>

Add basic NanoPi R6S support that comes with USB2, PCIe, SD card, eMMC
support.

Signed-off-by: Muhammed Efe Cetin <efectn at protonmail.com>
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3588s-nanopi-r6s.dts  | 764 ++++++++++++++++++
 2 files changed, 765 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 600c420bc..634b9be47 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -114,3 +114,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
new file mode 100644
index 000000000..4fa644ae5
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
@@ -0,0 +1,764 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "rk3588s.dtsi"
+
+/ {
+	model = "FriendlyElec NanoPi R6S";
+	compatible = "friendlyarm,nanopi-r6s", "rockchip,rk3588s";
+
+	aliases {
+		ethernet0 = &gmac1;
+		mmc0 = &sdmmc;
+		mmc1 = &sdhci;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-maskrom {
+			label = "Maskrom";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <1800>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&key1_pin>;
+
+		button-user {
+			label = "User";
+			linux,code = <BTN_1>;
+			gpios = <&gpio1 RK_PC0 GPIO_ACTIVE_LOW>;
+			debounce-interval = <50>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		sys_led: led-0 {
+			label = "sys_led";
+			gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+			pinctrl-names = "default";
+			pinctrl-0 = <&sys_led_pin>;
+		};
+
+		wan_led: led-1 {
+			label = "wan_led";
+			gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&wan_led_pin>;
+		};
+
+		lan1_led: led-2 {
+			label = "lan1_led";
+			gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&lan1_led_pin>;
+		};
+
+		lan2_led: led-3 {
+			label = "lan2_led";
+			gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&lan2_led_pin>;
+		};
+	};
+
+	vcc5v0_sys: vcc5v0-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+	};
+
+	vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_3v3_s0: vcc-3v3-s0-regulator {
+		compatible = "regulator-fixed";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-name = "vcc_3v3_s0";
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc_3v3_sd_s0: vcc-3v3-sd-s0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sd_s0_pwr>;
+		regulator-name = "vcc_3v3_sd_s0";
+		regulator-boot-on;
+		regulator-max-microvolt = <3000000>;
+		regulator-min-microvolt = <3000000>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc_3v3_pcie20: vcc3v3-pcie20-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3_pcie20";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_usb_otg0: vcc5v0-usb-otg0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio1 RK_PD2 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&typec5v_pwren>;
+		regulator-name = "vcc5v0_usb_otg0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usb>;
+	};
+
+	vcc5v0_host_20: vcc5v0-host-20-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host20_en>;
+		regulator-name = "vcc5v0_host_20";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usb>;
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	status = "okay";
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy1>;
+	phy-mode = "rgmii-rxid";
+	pinctrl-0 = <&gmac1_miim
+		     &gmac1_tx_bus2
+		     &gmac1_rx_bus2
+		     &gmac1_rgmii_clk
+		     &gmac1_rgmii_bus>;
+	pinctrl-names = "default";
+	tx_delay = <0x42>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator at 43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator at 42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		regulator-boot-on;
+		regulator-always-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c6 {
+	clock-frequency = <200000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c6m0_xfer>;
+	status = "okay";
+
+	hym8563: rtc at 51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-output-names = "hym8563";
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtc_int>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+		wakeup-source;
+	};
+};
+
+&mdio1 {
+	rgmii_phy1: ethernet-phy at 1 {
+		compatible = "ethernet-phy-id001c.c916";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtl8211f_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pcie2x1l1 {
+	reset-gpios = <&gpio1 RK_PA7 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc_3v3_pcie20>;
+	status = "okay";
+};
+
+&pcie2x1l2 {
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc_3v3_pcie20>;
+	status = "okay";
+};
+
+&pinctrl {
+	gpio-key {
+		key1_pin: key1-pin {
+			rockchip,pins = <1 RK_PC0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	gpio-leds {
+		sys_led_pin: sys-led-pin {
+			rockchip,pins =
+				<1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wan_led_pin: wan-led-pin {
+			rockchip,pins =
+				<1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		lan1_led_pin: lan1-led-pin {
+			rockchip,pins =
+				<1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		lan2_led_pin: lan2-led-pin {
+			rockchip,pins =
+				<1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	hym8563 {
+		rtc_int: rtc-int {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sdmmc {
+		sd_s0_pwr: sd-s0-pwr {
+			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb {
+		typec5v_pwren: typec5v-pwren {
+			rockchip,pins = <1 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		vcc5v0_host20_en: vcc5v0-host20-en {
+			rockchip,pins = <4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	rtl8211f {
+		rtl8211f_rst: rtl8211f-rst {
+			rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&saradc {
+	vref-supply = <&avcc_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	no-sdio;
+	no-sd;
+	non-removable;
+	mmc-hs200-1_8v;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	disable-wp;
+	max-frequency = <150000000>;
+	no-mmc;
+	no-sdio;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_sd_s0>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&spi2 {
+	status = "okay";
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	num-cs = <1>;
+
+	pmic at 0 {
+		compatible = "rockchip,rk806";
+		spi-max-frequency = <1000000>;
+		reg = <0x0>;
+
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+
+		system-power-controller;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc5-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc5v0_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc5v0_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc5v0_sys>;
+
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_lit_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_log_s0: dcdc-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <750000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_log_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_vdenc_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vdd2_ddr_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_2v0_pldo_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vddq_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avcc_1v8_s0: pldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "avcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			avdd_1v2_s0: pldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "avdd_1v2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			avcc_3v3_s0: pldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "avcc_3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vccio_sd_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo6_s3: pldo-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "pldo6_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			avdd_ddr_pll_s0: nldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "avdd_ddr_pll_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			avdd_0v75_s0: nldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "avdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			avdd_0v85_s0: nldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "avdd_0v85_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_0v75_s0: nldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_host_20>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
-- 
2.43.0



From olteanv at gmail.com  Sat Dec 30 03:28:06 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Sat, 30 Dec 2023 13:28:06 +0200
Subject: PHY issue with SJA1105Q/DP84849I Design
In-Reply-To: <CAMty3ZAOM5+EMw9sLVOq-=CH_sP=1TLAGEMF9LYOZ4aFbNUtsg@mail.gmail.com>
References: <CAMty3ZCn+yGr2MG3WYg+i4DsZWk5b-xEw0SDvNbeGzs6pMwjfQ@mail.gmail.com>
 <20231222145100.sfcuux7ayxtxgogo@skbuf>
 <CAMty3ZBZNugYmKMjDdZnY0kFMeEb86uzSg2XL9Tn6Yb4t-TXKQ@mail.gmail.com>
 <20231226153055.4yihsmu6kiak6hkf@skbuf>
 <CAMty3ZDnAFR9a1BM89mx3bmrQzGC7nvazt42_v4JF_QpwPkS4w@mail.gmail.com>
 <20231229152519.2jxrwaeltp4pxlms@skbuf>
 <CAMty3ZAOM5+EMw9sLVOq-=CH_sP=1TLAGEMF9LYOZ4aFbNUtsg@mail.gmail.com>
Message-ID: <20231230112806.o5ia43mu4mo64lea@skbuf>

On Sat, Dec 30, 2023 at 01:48:38AM +0530, Jagan Teki wrote:
> On Fri, Dec 29, 2023 at 8:55?PM Vladimir Oltean <olteanv at gmail.com> wrote:
> > Why all these combinations? You don't know which switch port is which?
> 
> This is where I get confused in the first place. I didn't find proper
> information on binding about how the physical pin-out is to be
> configured in DT ports or maybe I didn't understand properly.
> 
> As per schematics.
> Pin MII0_RXD0-D3/TXD0-D3 is connected to PROC_MII0_RXD0-D3/TXD0-D3
> this would be fec0.
> Pin MII1_RXD0-D3/TXD0-D3 is connected to PHY_MII1_RXD0-D3/TXD0-D3 this
> would be ethphy0.
> Pin MII2_RXD0-D3/TXD0-D3 is connected to PHY_MII2_RXD0-D3/TXD0-D3 this
> would be ethphy1.
> Pin MII3_RXD0-D3/TXD0-D3 is grounded
> Pin MII4_RXD0-D3/TXD0-D3 is grounded
> 
> So, I did use the above 3 combinations and assumed fec0 is always a
> port4 based on existing DTS in the tree. Please let me know which
> configuration is proper as per schematic connections.

With this switch, any port can be a CPU port. The CPU port selection
from existing, unrelated upstream boards has no influence upon yours.

The pin naming in "MII0_RXD/TXD" follows the same numbering scheme as
"port at 0" etc. The SJA1105PQRS.pdf datasheet should tell you as much.
So your CPU port should be the "port at 0" node and not "port at 4". The
switch "port at 3" and "port at 4" sound like they should be the ones with
status = "disabled".

> > If you are truly using MII, then you should remove the RGMII delay
> > properties, and since you are using a 6.1 kernel - hence after kernel
> > commit 5d645df99ac6 ("net: dsa: sja1105: determine PHY/MAC role from PHY
> > interface type") - you should be using phy-mode = "rev-mii" to put this
> > port in MII PHY ("RevMII") mode - to interoperate with the FEC in MII
> > MAC mode.
> 
> Okay, I will remove RGMII delay. is phy-mode = "rev-mii" applicable to
> all ports or only for fec port4?

Use phy-mode = "rev-mii" for the switch port going to the FEC, and
phy-mode = "mii" for the switch ports going to MII PHYs (and for the FEC
itself).

> > You can also use the RX counters to determine which switch port is which
> > (but the phy-handle of each port to each PHY needs to be correct).
> 
> RX counters in ethtool you mean?

Yes.


From jonas at kwiboo.se  Sat Dec 30 03:49:38 2023
From: jonas at kwiboo.se (Jonas Karlman)
Date: Sat, 30 Dec 2023 12:49:38 +0100
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
In-Reply-To: <20231230095228.3739806-1-liujianfeng1994@gmail.com>
References: <CAAXNxMT3f68-ptM7Crhrfmn7iwTyJc9pwz4Beob+5beVODaSHQ@mail.gmail.com>
 <20231230095228.3739806-1-liujianfeng1994@gmail.com>
Message-ID: <97faf49b-0109-439a-accf-251b502ad40b@kwiboo.se>

Hi,

On 2023-12-30 10:52, amazingfate wrote:
> Thanks for your test with fluster. I also tested on my rock-5b(rk3588)
> and orangepi-3b(rk3566) which are sharing the same hantro g1 ip. I am
> running on ubuntu jammy so I'm using gstreamer 1.20.1
> 
> rk3566 and rk3588 are sharing the same results:
> JVT-AVC_V1 test suite with decoder GStreamer-H.264-V4L2SL-Gst1.0:
>   Ran 112/135 tests successfully.
> JVT-FR_EXT test suite with decoder GStreamer-H.264-V4L2SL-Gst1.0:
>   Ran 27/69 tests successfully.
> VP8-TEST-VECTORS test suite with decoder GStreamer-VP8-V4L2SL-Gst1.0:
>   Ran 59/61 tests successfully.
> 
> H264 decoder test has less test case passing. I think that's because
> of my low gstreamer version. If you have a rk356x board I guess you
> will get the same result as rk3588. That should be the mainline support
> status of hantro g1 decoder.
> 
> For ffmpeg at the moment fluster doesn't support v4l2-request decoder.
> I tried Kwiboo's fork[1] but failed to pass tests with decoder
> FFmpeg-H.264-V4L2-request. I can decode video with ffmpeg command like:
> "ffmpeg -benchmark -hwaccel drm -hwaccel_output_format drm_prime -i Big_Buck_Bunny_1080_10s_30MB.mp4 -f null -"

I have only tested this fork of fluster with ffmpeg 6.x, what version of
ffmpeg did you test with? I was expecting it to also work on ffmpeg 5.x.

Please also note that ffmpeg v4l2-request patches at [2] contain some
NV15/NV20 ffmpeg pix_fmt patches that fail ffmpeg tests. They are not
needed for decoding of 10-bit frames using rkvdec but they are required
to be able to run fluster test suite JVT-FR_EXT on rkvdec. (hantro g1 do
not support 10-bit frames on rk)

[2] https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-n6.1

Regards,
Jonas

> 
> [1] https://github.com/Kwiboo/fluster/tree/v4l2-request
> 



From konrad.dybcio at linaro.org  Sat Dec 30 04:22:10 2023
From: konrad.dybcio at linaro.org (Konrad Dybcio)
Date: Sat, 30 Dec 2023 13:22:10 +0100
Subject: [PATCH v2 7/8] arm64: dts: qcom: sa8295p-adp: Enable GPU
In-Reply-To: <20231227202130.GA1315173@hu-bjorande-lv.qualcomm.com>
References: <20231220-sa8295p-gpu-v2-0-4763246b72c0@quicinc.com>
 <20231220-sa8295p-gpu-v2-7-4763246b72c0@quicinc.com>
 <4a1c18e3-39c8-4070-ae55-b1148b3dc65b@linaro.org>
 <20231227202130.GA1315173@hu-bjorande-lv.qualcomm.com>
Message-ID: <dc11577e-7088-4975-8543-ad8001e678fe@linaro.org>

On 27.12.2023 21:21, Bjorn Andersson wrote:
> On Wed, Dec 27, 2023 at 02:09:47AM +0100, Konrad Dybcio wrote:
>> On 22.12.2023 05:39, Bjorn Andersson wrote:
>>> With the necessary support in place for supplying VDD_GFX from the
>>> MAX20411 regulator, enable the GPU clock controller, GMU, Adreno SMMU
>>> and the GPU on the SA8295P ADP.
>>>
>>> Signed-off-by: Bjorn Andersson <quic_bjorande at quicinc.com>
>>> ---
>> [...]
>>
>>> +&gpucc {
>>> +	vdd-gfx-supply = <&vdd_gfx>;
>>> +	status = "okay";
>>> +};
>> Already enabled
>>
> 
> No, we're disabling these in sa8540p.dtsi, so they need to be re-enabled
> here.
> 
> I don't remember if it's because the attempt to bring up gfx.lvl or if
> it's the attempt to operate the GPU components without adequate VDD_GFX,
> that is causing the issue...but either way, we don't survive boot.
Oh right!

On 8155 touching mmcx, lcx or lmx would kaboom the platform..

> 
> 
> It's possible that we could move the max20411 up to sa8540p.dtsi to
> avoid the intermediate disable, but I'm not confident that it's "part of
> the platform"...
Yeah, it's probably a question that is impossible to answer, as my
wild assumption is that all designs are ADP-derived anyway..

Konrad


From olteanv at gmail.com  Sat Dec 30 06:17:57 2023
From: olteanv at gmail.com (Vladimir Oltean)
Date: Sat, 30 Dec 2023 16:17:57 +0200
Subject: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
In-Reply-To: <3b53aa8a-73e9-9260-f05b-05dac80a4276@bootlin.com>
References: <20231218162326.173127-1-romain.gantois@bootlin.com>
 <20231218162326.173127-2-romain.gantois@bootlin.com>
 <20231219122034.pg2djgrosa4irubh@skbuf>
 <3b53aa8a-73e9-9260-f05b-05dac80a4276@bootlin.com>
Message-ID: <20231230141757.vof2lle75vusahgf@skbuf>

On Fri, Dec 29, 2023 at 05:11:48PM +0100, Romain Gantois wrote:
> Thanks for telling me about DSA_LOOP, I've tested several DSA tagging protocols 
> with the RZN1 GMAC1 hardware using this method. Here's what I found in a 
> nutshell:

Good job exploring the complexity of the problem in depth.

> For tagging protocols that change the EtherType field in the MAC header (e.g. 
> DSA_TAG_PROTO_(DSA/EDSA/BRCM/MTK/RTL4C_A/SJA1105): On TX the tagged frames are 
> almost always ignored by the checksum offload engine and IP header checker of 
> the MAC device. I say "almost always" because there is an 
> unlikely but nasty corner case where a DSA tag can be identical to an IP 
> EtherType value. In these cases, the frame will likely fail IP header checks 
> and be dropped by the MAC.

Yes, there are a few poorly designed DSA tagging formats where arbitrary
fields overlap with what the conduit interface sees as the EtherType field.
We don't design the tagging formats, as they are proprietary (except for those
derived from tag_8021q), we just support them. In some cases where the
switch has permitted that, we have implemented dynamic changing of
tagging protocols (like 'echo edsa > /sys/class/net/eth0/dsa/tagging')
in order to increase the compatibility between a particular switch and
its conduit interface. And where the compatibility with the default
tagging protocol was beyond broken, we accepted an alternative one
through the 'dsa-tag-protocol' device tree property.

> Ignoring these corner cases, the DSA frames will egress with a partial 
> checksum and be dropped by the recipient. On RX, these frames will, once again, 
> not be detected as IP frames by the MAC. So they will be transmitted to the CPU. 
> However, the stmmac driver will assume (wrongly in this case) that
> these frames' checksums have been verified by the MAC. So it will set 
> CHECKSUM_UNECESSARY:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#L5493
>  
> And so the IP/TCP checksums will not be checked at all, which is not
> ideal.

Yup, this all stems from the fact that DSA inherits the checksum offload
features of the conduit (stmmac) from its vlan_features. People think
that vlan_features are inherited only by VLAN upper interfaces, but that
is not the case. Confusingly, in some cases, offloading NETIF_F_IP_CSUM |
NETIF_F_IPV6_CSUM really does work (Broadcom conduit + Broadcom switch,
Marvell conduit + Marvell switch, etc), so we can't remove this mechanism.
But it uncovers lack of API compliance in drivers such as the stmmac,
which is why it is a fragile mechanism.

> There are other DSA tagging protocols which cause different issues. For example 
> DSA_TAG_PROTO_BRCM_PREPEND, which seems to offset the whole MAC header, and 
> DSA_TAG_PROTO_LAN9303 which sets ETH_P_8021Q as its EtherType. I haven't dug too 
> deeply on these issues yet, since I'd rather deal with the checksumming issue 
> before getting distracted by VLAN offloading and other stuff.

I agree that what brcm-prepend does - shifting the entire frame to the
right by 4 octets - sounds problematic in general (making the conduit
see the EtherType as octets [3:2] of the original MAC SA). But you also
need to take a look at where those protocols are used, and if that is
relevant in any way to the stmmac.

	/* Broadcom BCM58xx chips have a flow accelerator on Port 8
	 * which requires us to use the prepended Broadcom tag type
	 */
	if (dev->chip_id == BCM58XX_DEVICE_ID && port == B53_CPU_PORT) {
		dev->tag_protocol = DSA_TAG_PROTO_BRCM_PREPEND;
		goto out;
	}

>From what I understand, DSA_TAG_PROTO_BRCM_PREPEND is only used
internally within Broadcom SoCs, so it seems likely that it's not
designed with generic compatibility in mind.

As for DSA_TAG_PROTO_LAN9303, let me guess what the problem was. TX was
fine, but on RX, the packets got dropped in hardware before they even
reached the stmmac driver, because it declares NETIF_F_HW_VLAN_CTAG_FILTER |
NETIF_F_HW_VLAN_STAG_FILTER as features, and the DSA tags effectively
look like unregistered VLAN traffic.

That is certainly an area where the lan9303 support can be improved.
Other VLAN-based taggers like tag_8021q perform vlan_vid_add() calls on
the conduit interface so that it won't drop the traffic even when it
uses hardware VLAN filtering.

> Among the tagging protocols I tested, the only one that didn't cause any issues 
> was DSA_TAG_PROTO_TRAILER, which only appends stuff to the frame.

It's very curious that you say this. Tail taggers are notoriously
problematic, because while the conduit will perform the checksum offload
function on the packets, the checksum calculation goes until the very end
of the frame. Thus, that checksum will be wrong after the switch consumes
the tail tag (and does not update the L4 checksum).

There is no way to overcome that except to not inherit any checksum
offload features for tail taggers. But that would break some other thing,
so we opted for having this line in the xmit procedure of tail taggers:

	if (skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_help(skb))
		return NULL;

But apparently we have been inconsistent in applying this to trailer_xmit()
as well. So DSA_TAG_PROTO_TRAILER should actually be a case of "checksum
is computed, but is incorrect after tag stripping", but you say that it
was the only one that worked fine.

> TLDR: The simplest solution seems to be to modify the stmmac TX and RX paths to 
> disable checksum offloading for frames that have a non-IP ethertype in 
> their MAC header. This will fix the checksum situation for DSA tagging protocols 
> that set non-IP and non-8021Q EtherTypes. Some edge cases like 
> DSA_TAG_PROTO_BRCM_PREPEND and DSA_TAG_PROTO_LAN9303 will require a completely 
> different solution if we want these MAC devices to handle them properly.
> Please share any thoughts you might have on this suggestion.

I think the overall idea is correct, with the small mentions of "let's
ignore brcm-prepend" and "lan9303 should work, maybe it's just a case of
disabling the VLAN filtering features through ethtool and testing again?".


From liujianfeng1994 at gmail.com  Sat Dec 30 07:31:59 2023
From: liujianfeng1994 at gmail.com (amazingfate)
Date: Sat, 30 Dec 2023 23:31:59 +0800
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
In-Reply-To: <97faf49b-0109-439a-accf-251b502ad40b@kwiboo.se>
References: <97faf49b-0109-439a-accf-251b502ad40b@kwiboo.se>
Message-ID: <20231230153159.3748580-1-liujianfeng1994@gmail.com>

Hi Jonas,

On Sat, 30 Dec 2023 12:49:38 +0100, Jonas Karlman <jonas at kwiboo.se> wrote:
>I have only tested this fork of fluster with ffmpeg 6.x, what version of
>ffmpeg did you test with? I was expecting it to also work on ffmpeg 5.x.

I am using ffmpeg 6.0 with v4l2-request patches from libreelec[1].
Ffmpeg v4l2 decoder in fluster fork is using ffmpeg args:
"-hwaccel_device /dev/dri/renderD128"
which make the test fall with hantro g1 on rk3588. After removing it I
can run tests by ffmpeg v4l2-request decoder. 

Rk3566 and rk3588 are sharing the same results:
JVT-AVC_V1 test suite with decoder FFmpeg-H.264-V4L2-request:
 Ran 127/135 tests successfully.
JVT-FR_EXT test suite with decoder FFmpeg-H.264-V4L2-request:
 Ran 44/69 tests successfully.
VP8-TEST-VECTORS test suite with decoder FFmpeg-VP8-V4L2-request:
 Ran 59/61 tests successfully.

[1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch

Regards,
Jianfeng


From josua at solid-run.com  Sat Dec 30 07:44:36 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:36 +0100
Subject: [PATCH v4 02/11] dt-bindings: marvell: a38x: convert the soc
 compatibles description to yaml
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-2-1d7f0e2c7128@solid-run.com>

Convert the existing txt binding for armada-38x socs to DT schema
format.

Note that the current bindings only document the SoC (armada380,
armada385, armada388). This is undesirable, instead there should be
entries for actual boards.

For now only convert to yaml, the content can be corrected separately.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../bindings/arm/marvell/armada-38x.yaml           | 33 ++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
new file mode 100644
index 000000000000..5af222e6db18
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/armada-38x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 38x Platforms
+
+maintainers:
+  - Gregory CLEMENT <gregory.clement at bootlin.com>
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+
+      - description: Armada 380 SoC
+        items:
+          - const: marvell,armada380
+
+      - description: Armada 385 SoC
+        items:
+          - const: marvell,armada385
+          - const: marvell,armada380
+
+      - description: Armada 388 SoC
+        items:
+          - const: marvell,armada388
+          - const: marvell,armada385
+          - const: marvell,armada380
+
+additionalProperties: true

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:35 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:35 +0100
Subject: [PATCH v4 01/11] dt-bindings: marvell: a38x: remove invalid txt
 bindings for armada 38x SoCs
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-1-1d7f0e2c7128@solid-run.com>

The current bindings documentation for armada-38x are only listing SoCs,
but no actual boards. Only actual boards should be listed.

Delete this invalid binding document.

Conversion to a boilerplate yaml has been considered but is not useful.
A new bindings documentation in yaml format can be introduced with new
bindings for specific boards.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../devicetree/bindings/arm/marvell/armada-38x.txt | 27 ----------------------
 1 file changed, 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
deleted file mode 100644
index 202953f1887e..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Marvell Armada 38x Platforms Device Tree Bindings
--------------------------------------------------
-
-Boards with a SoC of the Marvell Armada 38x family shall have the
-following property:
-
-Required root node property:
-
- - compatible: must contain "marvell,armada380"
-
-In addition, boards using the Marvell Armada 385 SoC shall have the
-following property before the previous one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada385"
-
-In addition, boards using the Marvell Armada 388 SoC shall have the
-following property before the previous one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada388"
-
-Example:
-
-compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:44 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:44 +0100
Subject: [PATCH v4 10/11] arm: dts: marvell: clearfog-gtr-l8: add support
 for second sfp connector
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-10-1d7f0e2c7128@solid-run.com>

Clearfog GTR L8 has an extra SFP connector on the managed switch port 9.
Add descriptions for both entities along with pinctrl.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../boot/dts/marvell/armada-385-clearfog-gtr-l8.dts  | 20 +++++++++++++++++++-
 .../boot/dts/marvell/armada-385-clearfog-gtr.dtsi    |  8 +++++++-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index cd5b070f1218..2df388f222ec 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -6,6 +6,16 @@ / {
 	model = "SolidRun Clearfog GTR L8";
 	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385",
 		     "marvell,armada380";
+
+	/* CON25 */
+	sfp1: sfp-1 {
+		compatible = "sff,sfp";
+		pinctrl-0 = <&cf_gtr_sfp1_pins>;
+		pinctrl-names = "default";
+		i2c-bus = <&i2c0>;
+		mod-def0-gpio = <&gpio0 24 GPIO_ACTIVE_LOW>;
+		tx-disable-gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
+	};
 };
 
 &mdio {
@@ -68,11 +78,19 @@ port at 8 {
 				phy-handle = <&switch0phy7>;
 			};
 
+			port at 9 {
+				reg = <9>;
+				label = "lan-sfp";
+				phy-mode = "sgmii";
+				sfp = <&sfp1>;
+				managed = "in-band-status";
+			};
+
 			port at 10 {
 				reg = <10>;
 				phy-mode = "2500base-x";
-
 				ethernet = <&eth1>;
+
 				fixed-link {
 					speed = <2500>;
 					full-duplex;
diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index 39ac97edb463..f3a3cb6ac311 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -201,6 +201,12 @@ cf_gtr_sfp0_pins: sfp0-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_sfp1_pins: sfp1-pins {
+					/* sfp modabs, txdisable */
+					marvell,pins = "mpp24", "mpp54";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
@@ -276,7 +282,7 @@ pcie at 3,0 {
 	};
 
 	/* CON5 */
-	sfp0: sfp {
+	sfp0: sfp-0 {
 		compatible = "sff,sfp";
 		pinctrl-0 = <&cf_gtr_sfp0_pins>;
 		pinctrl-names = "default";

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:34 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:34 +0100
Subject: [PATCH v4 00/11] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>

Dear Maintainers,

The initially merged device-tree for Clearfog GTR devices contained
various subtle mistakes and omissions:

- missing board-specific compatible strings
- missing pinctrl entries
- missing second sfp connector
- invalid sfp loss-of-signal gpio
- mismatch of labels between dsa ports and enclosure

Most notably this had caused functional issues with the sfp connectors.

This patch-set first deletes the invalid armada-38x dt-bindings.
New bindings are added specifically for the Clearfog GTR boards,
and for the already in-tree clearfog base, clearfog pro and helios-4
boards' compatible strings.

Secondly pinctrl nodes are added for all referenced gpios for independence
from bootloader defaults. U-Boot is shared between armada-388 clearfog,
and armada-385 clearfog gtr.

Further remove an invalid io from the first sfp connector description,
and add descriptions for the secondary sfp connector which is driven
by dsa switch port number 9.

Finally labels of dsa switch ports were updated to match the enclosure.
That patch is not suitable for stable.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
Changes in v4:
- dropped invalid soc-only armada-38x (txt) bindings
  (reported by Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>)
- add bindings for armada 388 helios-4
- updated yaml whitespace indentation count
  (reported by Rob Hering's bot)
- Link to v3: https://lore.kernel.org/r/20231226-support-clearfog-gtr-l8-sfp-v3-0-fd1ac2d6bf2e at solid-run.com

Changes in v3:
- armada-38x.yaml: removed '|', no need to prerserve formatting
  (reported by Conor Dooley conor+dt at kernel.org)
- update commit descriptions to clarify confusing board names and
  compatible strings
  (reported by Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>)
- send to all relevant lists
  (reported by Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>)
- remove duplicate binding for clearfog / clearfog
- Link to v2 (patches 0-2):
  https://lore.kernel.org/r/20231224143750.5604-1-josua at solid-run.com
- Link to v2 (patches 3-8):
  https://lore.kernel.org/r/20231224143850.5671-3-josua at solid-run.com

Changes in v2:
- removed changes changes to gpio numbers because they were wrong
- added bindings documentation
- Link to v1: https://lore.kernel.org/r/20231223212930.14624-1-josua at solid-run.com

---
Josua Mayer (11):
      dt-bindings: marvell: a38x: remove invalid txt bindings for armada 38x SoCs
      dt-bindings: marvell: a38x: convert the soc compatibles description to yaml
      dt-bindings: marvell: a38x: add solidrun armada 388 clearfog boards
      dt-bindings: marvell: a38x: add kobol helios-4 board
      dt-bindings: marvell: a38x: add solidrun armada 385 clearfog gtr boards
      arm: dts: marvell: clearfog: add pro variant compatible in legacy dts
      arm: dts: marvell: clearfog-gtr: add board-specific compatible strings
      arm: dts: marvell: clearfog-gtr: sort pinctrl nodes alphabetically
      arm: dts: marvell: clearfog-gtr: add missing pinctrl for all used gpios
      arm: dts: marvell: clearfog-gtr-l8: add support for second sfp connector
      arm: dts: marvell: clearfog-gtr-l8: align port numbers with enclosure

 .../devicetree/bindings/arm/marvell/armada-38x.txt | 27 -------
 .../bindings/arm/marvell/armada-38x.yaml           | 49 +++++++++++++
 .../dts/marvell/armada-385-clearfog-gtr-l8.dts     | 38 +++++++---
 .../dts/marvell/armada-385-clearfog-gtr-s4.dts     |  2 +
 .../boot/dts/marvell/armada-385-clearfog-gtr.dtsi  | 84 ++++++++++++++++------
 arch/arm/boot/dts/marvell/armada-388-clearfog.dts  |  5 +-
 6 files changed, 146 insertions(+), 59 deletions(-)
---
base-commit: 861deac3b092f37b2c5e6871732f3e11486f7082
change-id: 20231226-support-clearfog-gtr-l8-sfp-d87ae715a787

Sincerely,
-- 
Josua Mayer <josua at solid-run.com>



From josua at solid-run.com  Sat Dec 30 07:44:37 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:37 +0100
Subject: [PATCH v4 03/11] dt-bindings: marvell: a38x: add solidrun armada
 388 clearfog boards
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-3-1d7f0e2c7128@solid-run.com>

Add DT compatible for SolidRun Armada-388 based Clearfog Base and Pro
boards, which are already in place in-tree.

There are already 3 distinct dts in tree for these *two* boards,
declaring particular compatible strings:
- armada-388-clearfog.dts:
  compatible = "solidrun,clearfog-a1", "marvell,armada388",
               "marvell,armada385, "marvell,armada380";
- armada-388-clearfog-base.dts:
  compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1",
               "marvell,armada388", "marvell,armada385,
               "marvell,armada380";
- armada-388-clearfog-pro.dts:
  compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1",
               "marvell,armada388", "marvell,armada385,
               "marvell,armada380";

This has historic reasons, the first entry is a legacy name for the
"pro" version, old versions of u-boot built when only one variant
existed explicitly boot by this name.

Note that both compatibles and model field include the string "A1".
At least up to revision 2.0 of the board, this had been printed
on the pcb. However in marketing material and conversations it is
usually omitted. "Clearfog Pro" and "Clearfog Pro A1" always mean
exactly the same product.

Technically Base and Pro variants are similar enough that they can
successfully boot with each other's dts. Hence it makes (some)
sense for them to share the "clearfog-a1" compatible.

Add bindings for the explicit variants including base / pro suffix.
The legacy "armada-388-clearfog.dts" is not supported by these
bindings" as it does not make sense having two bindings for one board.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../devicetree/bindings/arm/marvell/armada-38x.yaml       | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
index 5af222e6db18..4950b840bf1c 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -15,17 +15,14 @@ properties:
   compatible:
     oneOf:
 
-      - description: Armada 380 SoC
-        items:
-          - const: marvell,armada380
-
-      - description: Armada 385 SoC
-        items:
-          - const: marvell,armada385
-          - const: marvell,armada380
+      - description:
+          SolidRun Armada 388 clearfog family single-board computers.
 
-      - description: Armada 388 SoC
         items:
+          - enum:
+              - solidrun,clearfog-base-a1
+              - solidrun,clearfog-pro-a1
+          - const: solidrun,clearfog-a1
           - const: marvell,armada388
           - const: marvell,armada385
           - const: marvell,armada380

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:45 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:45 +0100
Subject: [PATCH v4 11/11] arm: dts: marvell: clearfog-gtr-l8: align port
 numbers with enclosure
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-11-1d7f0e2c7128@solid-run.com>

Clearfog GTR has an official enclosure with labels for all interfaces.
The "lan" ports on the 8-port switch in device-tree were numbered  in
reverse wrt. enclosure.

Update all device-tree labels to match.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index 2df388f222ec..da6981677b03 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -32,49 +32,49 @@ ports {
 
 			port at 1 {
 				reg = <1>;
-				label = "lan8";
+				label = "lan1";
 				phy-handle = <&switch0phy0>;
 			};
 
 			port at 2 {
 				reg = <2>;
-				label = "lan7";
+				label = "lan2";
 				phy-handle = <&switch0phy1>;
 			};
 
 			port at 3 {
 				reg = <3>;
-				label = "lan6";
+				label = "lan3";
 				phy-handle = <&switch0phy2>;
 			};
 
 			port at 4 {
 				reg = <4>;
-				label = "lan5";
+				label = "lan4";
 				phy-handle = <&switch0phy3>;
 			};
 
 			port at 5 {
 				reg = <5>;
-				label = "lan4";
+				label = "lan5";
 				phy-handle = <&switch0phy4>;
 			};
 
 			port at 6 {
 				reg = <6>;
-				label = "lan3";
+				label = "lan6";
 				phy-handle = <&switch0phy5>;
 			};
 
 			port at 7 {
 				reg = <7>;
-				label = "lan2";
+				label = "lan7";
 				phy-handle = <&switch0phy6>;
 			};
 
 			port at 8 {
 				reg = <8>;
-				label = "lan1";
+				label = "lan8";
 				phy-handle = <&switch0phy7>;
 			};
 

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:39 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:39 +0100
Subject: [PATCH v4 05/11] dt-bindings: marvell: a38x: add solidrun armada
 385 clearfog gtr boards
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-5-1d7f0e2c7128@solid-run.com>

Add DT compatible for SolidRun Armada-385 based Clearfog GTR L8 and S4
boards.

Despite similar name these two boards are designed differently from the
armada 388 clearfog base and pro, they only share a name and general use
case.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
index 3babda0d575f..13f9aba97511 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -36,4 +36,14 @@ properties:
           - const: marvell,armada385
           - const: marvell,armada380
 
+      - description:
+          SolidRun Armada 385 based single-board computers.
+
+        items:
+          - enum:
+              - solidrun,clearfog-gtr-l8
+              - solidrun,clearfog-gtr-s4
+          - const: marvell,armada385
+          - const: marvell,armada380
+
 additionalProperties: true

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:38 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:38 +0100
Subject: [PATCH v4 04/11] dt-bindings: marvell: a38x: add kobol helios-4
 board
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-4-1d7f0e2c7128@solid-run.com>

Add DT compatible for the helios-4 nas by Kobol, which is already used
in-tree.

This product shares a common system on module with the solidrun armada
388 clearfog boards, however it is not easily described in a single
list due to their extra "solidrun,clearfog-a1" compatible string.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
index 4950b840bf1c..3babda0d575f 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -15,6 +15,15 @@ properties:
   compatible:
     oneOf:
 
+      - description:
+          Kobol Armada 388 based helios nas.
+
+        items:
+          - const: kobol,helios4
+          - const: marvell,armada388
+          - const: marvell,armada385
+          - const: marvell,armada380
+
       - description:
           SolidRun Armada 388 clearfog family single-board computers.
 

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:40 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:40 +0100
Subject: [PATCH v4 06/11] arm: dts: marvell: clearfog: add pro variant
 compatible in legacy dts
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-6-1d7f0e2c7128@solid-run.com>

Armada 388 Clearfog ("armada-388-clearfog.dts)" is a legacy filename for
the Armada 388 Clearfog Pro ("armada-388-clearfog-pro.dts").
The "Pro" suffix was only used when the smaller version, the "Base" got
released.

The two names refer to exactly the same hardware, therefore they should
share the same compatible strings.

Copy "solidrun,clearfog-pro-a1" compatible from the -pro dts and add it
to this legacy file.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 arch/arm/boot/dts/marvell/armada-388-clearfog.dts | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-388-clearfog.dts b/arch/arm/boot/dts/marvell/armada-388-clearfog.dts
index 32c569df142f..24e478a3cc99 100644
--- a/arch/arm/boot/dts/marvell/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-clearfog.dts
@@ -10,8 +10,9 @@
 
 / {
 	model = "SolidRun Clearfog A1";
-	compatible = "solidrun,clearfog-a1", "marvell,armada388",
-		"marvell,armada385", "marvell,armada380";
+	compatible = "solidrun,clearfog-pro-a1", "solidrun,clearfog-a1",
+		     "marvell,armada388", "marvell,armada385",
+		     "marvell,armada380";
 
 	soc {
 		internal-regs {

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:41 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:41 +0100
Subject: [PATCH v4 07/11] arm: dts: marvell: clearfog-gtr: add
 board-specific compatible strings
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-7-1d7f0e2c7128@solid-run.com>

Most arm board have a board-specific compatible string that allows e.g.
userspace to match specific firmware variants or apply specific
policies.

Add board-specific properties to both variants of the Clearfog GTR:
- solidrun,clearfog-gtr-l8
- solidrun,clearfog-gtr-s4

Introduction of a common parent (e.g. "solidrun,clearfog-gtr") is
omitted for brevity.
Since announcement of the two products no additional variants were added
it is assumed that there will always be just two.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts | 2 ++
 arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
index 1990f7d0cc79..cd5b070f1218 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-l8.dts
@@ -4,6 +4,8 @@
 
 / {
 	model = "SolidRun Clearfog GTR L8";
+	compatible = "solidrun,clearfog-gtr-l8", "marvell,armada385",
+		     "marvell,armada380";
 };
 
 &mdio {
diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
index b795ad573891..4a9736ec99b6 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr-s4.dts
@@ -4,6 +4,8 @@
 
 / {
 	model = "SolidRun Clearfog GTR S4";
+	compatible = "solidrun,clearfog-gtr-s4", "marvell,armada385",
+		     "marvell,armada380";
 };
 
 &sfp0 {

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:42 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:42 +0100
Subject: [PATCH v4 08/11] arm: dts: marvell: clearfog-gtr: sort pinctrl
 nodes alphabetically
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-8-1d7f0e2c7128@solid-run.com>

Cosmetic change to increase future patches readability when adding new
pinctrl nodes.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../boot/dts/marvell/armada-385-clearfog-gtr.dtsi  | 40 +++++++++++-----------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index d1452a04e904..8eabb60765b0 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -141,18 +141,13 @@ i2c at 11100 { /* SFP (CON5/CON6) */
 			};
 
 			pinctrl at 18000 {
-				cf_gtr_switch_reset_pins: cf-gtr-switch-reset-pins {
-					marvell,pins = "mpp18";
-					marvell,function = "gpio";
-				};
-
-				cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
-					marvell,pins = "mpp22";
+				cf_gtr_fan_pwm: cf-gtr-fan-pwm {
+					marvell,pins = "mpp23";
 					marvell,function = "gpio";
 				};
 
-				cf_gtr_fan_pwm: cf-gtr-fan-pwm {
-					marvell,pins = "mpp23";
+				cf_gtr_front_button_pins: cf-gtr-front-button-pins {
+					marvell,pins = "mpp53";
 					marvell,function = "gpio";
 				};
 
@@ -162,13 +157,6 @@ cf_gtr_i2c1_pins: i2c1-pins {
 					marvell,function = "i2c1";
 				};
 
-				cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
-					marvell,pins = "mpp21", "mpp28",
-						       "mpp37", "mpp38",
-						       "mpp39", "mpp40";
-					marvell,function = "sd0";
-				};
-
 				cf_gtr_isolation_pins: cf-gtr-isolation-pins {
 					marvell,pins = "mpp47";
 					marvell,function = "gpio";
@@ -179,18 +167,30 @@ cf_gtr_poe_reset_pins: cf-gtr-poe-reset-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_rear_button_pins: cf-gtr-rear-button-pins {
+					marvell,pins = "mpp36";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
+					marvell,pins = "mpp21", "mpp28",
+						       "mpp37", "mpp38",
+						       "mpp39", "mpp40";
+					marvell,function = "sd0";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
 				};
 
-				cf_gtr_front_button_pins: cf-gtr-front-button-pins {
-					marvell,pins = "mpp53";
+				cf_gtr_switch_reset_pins: cf-gtr-switch-reset-pins {
+					marvell,pins = "mpp18";
 					marvell,function = "gpio";
 				};
 
-				cf_gtr_rear_button_pins: cf-gtr-rear-button-pins {
-					marvell,pins = "mpp36";
+				cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
+					marvell,pins = "mpp22";
 					marvell,function = "gpio";
 				};
 			};

-- 
2.35.3



From josua at solid-run.com  Sat Dec 30 07:44:43 2023
From: josua at solid-run.com (Josua Mayer)
Date: Sat, 30 Dec 2023 16:44:43 +0100
Subject: [PATCH v4 09/11] arm: dts: marvell: clearfog-gtr: add missing
 pinctrl for all used gpios
In-Reply-To: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
References: <20231230-support-clearfog-gtr-l8-sfp-v4-0-1d7f0e2c7128@solid-run.com>
Message-ID: <20231230-support-clearfog-gtr-l8-sfp-v4-9-1d7f0e2c7128@solid-run.com>

Various control signals such as sfp module-absence, pci-e reset or led
gpios were missing pinctrl nodes, leaving any u-boot choices in place.

Since U-Boot is shared between multiple board variants, i.e. a388
clearfog pro / base, clearfog gtr l8 / s4, it is better to explicitly
configure functions.
Add explicit pinctrl entries for all gpios currently in use.

Additionally the loss-of-signal gpio specified is invalid, in fact los
only has a pull-up on the board but no gpio connection to the cpu.
Remove this stray reference.

Signed-off-by: Josua Mayer <josua at solid-run.com>
---
 .../boot/dts/marvell/armada-385-clearfog-gtr.dtsi  | 42 ++++++++++++++++++++--
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
index 8eabb60765b0..39ac97edb463 100644
--- a/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
+++ b/arch/arm/boot/dts/marvell/armada-385-clearfog-gtr.dtsi
@@ -162,6 +162,22 @@ cf_gtr_isolation_pins: cf-gtr-isolation-pins {
 					marvell,function = "gpio";
 				};
 
+				cf_gtr_led_pins: led-pins {
+					marvell,pins = "mpp42", "mpp52";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_lte_disable_pins: lte-disable-pins {
+					marvell,pins = "mpp34";
+					marvell,function = "gpio";
+				};
+
+				cf_gtr_pci_pins: pci-pins {
+					// pci reset
+					marvell,pins = "mpp33", "mpp35", "mpp44";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_poe_reset_pins: cf-gtr-poe-reset-pins {
 					marvell,pins = "mpp48";
 					marvell,function = "gpio";
@@ -179,6 +195,12 @@ cf_gtr_sdhci_pins: cf-gtr-sdhci-pins {
 					marvell,function = "sd0";
 				};
 
+				cf_gtr_sfp0_pins: sfp0-pins {
+					/* sfp modabs, txdisable */
+					marvell,pins = "mpp25", "mpp46";
+					marvell,function = "gpio";
+				};
+
 				cf_gtr_spi1_cs_pins: spi1-cs-pins {
 					marvell,pins = "mpp59";
 					marvell,function = "spi1";
@@ -193,6 +215,11 @@ cf_gtr_usb3_con_vbus: cf-gtr-usb3-con-vbus {
 					marvell,pins = "mpp22";
 					marvell,function = "gpio";
 				};
+
+				cf_gtr_wifi_disable_pins: wifi-disable-pins {
+					marvell,pins = "mpp30", "mpp31";
+					marvell,function = "gpio";
+				};
 			};
 
 			sdhci at d8000 {
@@ -221,21 +248,26 @@ usb3 at f8000 {
 		};
 
 		pcie {
+			pinctrl-0 = <&cf_gtr_pci_pins>;
+			pinctrl-names = "default";
 			status = "okay";
 			/*
 			 * The PCIe units are accessible through
 			 * the mini-PCIe connectors on the board.
 			 */
+			/* CON3 - serdes 0 */
 			pcie at 1,0 {
 				reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
 				status = "okay";
 			};
 
+			/* CON4 - serdes 2 */
 			pcie at 2,0 {
 				reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
 				status = "okay";
 			};
 
+			/* CON2 - serdes 4 */
 			pcie at 3,0 {
 				reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
 				status = "okay";
@@ -243,10 +275,12 @@ pcie at 3,0 {
 		};
 	};
 
+	/* CON5 */
 	sfp0: sfp {
 		compatible = "sff,sfp";
+		pinctrl-0 = <&cf_gtr_sfp0_pins>;
+		pinctrl-names = "default";
 		i2c-bus = <&i2c1>;
-		los-gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
 		mod-def0-gpio = <&gpio0 25 GPIO_ACTIVE_LOW>;
 		tx-disable-gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
 	};
@@ -273,6 +307,8 @@ button-1 {
 
 	gpio-leds {
 		compatible = "gpio-leds";
+		pinctrl-0 = <&cf_gtr_led_pins>;
+		pinctrl-names = "default";
 
 		led1 {
 			function = LED_FUNCTION_CPU;
@@ -408,7 +444,7 @@ &ahci1 {
 };
 
 &gpio0 {
-	pinctrl-0 = <&cf_gtr_fan_pwm>;
+	pinctrl-0 = <&cf_gtr_fan_pwm &cf_gtr_wifi_disable_pins>;
 	pinctrl-names = "default";
 
 	wifi-disable {
@@ -420,7 +456,7 @@ wifi-disable {
 };
 
 &gpio1 {
-	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins>;
+	pinctrl-0 = <&cf_gtr_isolation_pins &cf_gtr_poe_reset_pins &cf_gtr_lte_disable_pins>;
 	pinctrl-names = "default";
 
 	lte-disable {

-- 
2.35.3



From krzysztof.kozlowski at linaro.org  Sat Dec 30 08:06:48 2023
From: krzysztof.kozlowski at linaro.org (Krzysztof Kozlowski)
Date: Sat, 30 Dec 2023 17:06:48 +0100
Subject: [PATCH v2 3/3] dt-bindings: media: rockchip-vpu: Add RK3588
 compatible
In-Reply-To: <20231228131617.3411561-4-liujianfeng1994@gmail.com>
References: <20231228131617.3411561-1-liujianfeng1994@gmail.com>
 <20231228131617.3411561-4-liujianfeng1994@gmail.com>
Message-ID: <02e64f0f-6add-4583-9ee4-d5ace6497776@linaro.org>

On 28/12/2023 14:16, Jianfeng Liu wrote:
> Add compatible for rk3588 Hantro G1 vpu decoder.
> 
> Signed-off-by: Jianfeng Liu <liujianfeng1994 at gmail.com>
> ---
>  Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> index c57e1f488..ba41446f6 100644
> --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
> @@ -25,6 +25,7 @@ properties:
>            - rockchip,px30-vpu
>            - rockchip,rk3568-vpu
>            - rockchip,rk3588-av1-vpu
> +          - rockchip,rk3588-vpu

Your driver suggests it is compatible with 3568-vpu.

Also, nothing in commit msg explains me differences against existing
av1-vpu.

Best regards,
Krzysztof



From inindev at gmail.com  Sat Dec 30 08:50:53 2023
From: inindev at gmail.com (John Clark)
Date: Sat, 30 Dec 2023 11:50:53 -0500
Subject: [PATCH] arm64: dts: rockchip: add sdmmc card detect to the nanopc-t6
Message-ID: <20231230165053.3781-1-inindev@gmail.com>

The nanopc-t6 has an sdmmc card detect connected to gpio0_a4 which is
active low.

Signed-off-by: John Clark <inindev at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
index d7722772ecd8..54445f929a37 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dts
@@ -539,6 +539,7 @@ &sdmmc {
 	bus-width = <4>;
 	cap-mmc-highspeed;
 	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
 	disable-wp;
 	no-mmc;
 	no-sdio;
-- 
2.39.2



From liujianfeng1994 at gmail.com  Sat Dec 30 09:17:11 2023
From: liujianfeng1994 at gmail.com (amazingfate)
Date: Sun, 31 Dec 2023 01:17:11 +0800
Subject: [PATCH v2 3/3] dt-bindings: media: rockchip-vpu: Add RK3588 compatible
In-Reply-To: <02e64f0f-6add-4583-9ee4-d5ace6497776@linaro.org>
References: <02e64f0f-6add-4583-9ee4-d5ace6497776@linaro.org>
Message-ID: <20231230171711.3912776-1-liujianfeng1994@gmail.com>

Hi Krzysztof,

Sat, 30 Dec 2023 17:06:48 +0100, Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
>Your driver suggests it is compatible with 3568-vpu.
>
>Also, nothing in commit msg explains me differences against existing
>av1-vpu.

Yes, this vpu is exactly the same as the one on rk3568, so we can
make rockchip,rk3588-vpu compatible with rockchip,rk3568-vpu, just
like what we have done on rk3188/rk3066 and rk3228/rk3399.
I will update it in v3 patch.

Best regards,
Jianfeng


From liujianfeng1994 at gmail.com  Sat Dec 30 09:23:52 2023
From: liujianfeng1994 at gmail.com (amazingfate)
Date: Sun, 31 Dec 2023 01:23:52 +0800
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
In-Reply-To: <35df6456-2bc2-415d-bc61-09e4b440e2ac@gmail.com>
References: <35df6456-2bc2-415d-bc61-09e4b440e2ac@gmail.com>
Message-ID: <20231230172352.3913020-1-liujianfeng1994@gmail.com>

Hi Alex,

On Sat, 30 Dec 2023 10:46:42 +0100, Alex Bee <knaerzche at gmail.com> wrote:
>if the RK3568 and RK3588 variants match, patch [1/3] is not necessary. Just
>document a additional compatible in a similar way it's being done for
>rk3188/rk3066 or rk3228/rk3399.
>If there are ever differences we don't know about yet, a additional variant
>can still be added in the driver.
You are right, this way works. I should have encounted a ccache issue which
made me running a devicetree I didn't want.

I will drop patch[1/3] and only add devicetree node and dt-binding in v3.

Best regards,
Jianfeng


From alex at ghiti.fr  Sat Dec 30 10:26:11 2023
From: alex at ghiti.fr (Alexandre Ghiti)
Date: Sat, 30 Dec 2023 19:26:11 +0100
Subject: [PATCH 2/2] riscv: tlb: avoid tlb flushing if fullmm == 1
In-Reply-To: <20231228084642.1765-3-jszhang@kernel.org>
References: <20231228084642.1765-1-jszhang@kernel.org>
 <20231228084642.1765-3-jszhang@kernel.org>
Message-ID: <e227f095-0c3d-43c4-8ba3-8ec1b925b929@ghiti.fr>

Hi Jisheng,

On 28/12/2023 09:46, Jisheng Zhang wrote:
> The mmu_gather code sets fullmm=1 when tearing down the entire address
> space for an mm_struct on exit or execve. So if the underlying platform
> supports ASID, the tlb flushing can be avoided because the ASID
> allocator will never re-allocate a dirty ASID.
>
> Use the performance of Process creation in unixbench on T-HEAD TH1520
> platform is improved by about 4%.
>
> Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
> ---
>   arch/riscv/include/asm/tlb.h | 9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/arch/riscv/include/asm/tlb.h b/arch/riscv/include/asm/tlb.h
> index 1eb5682b2af6..35f3c214332e 100644
> --- a/arch/riscv/include/asm/tlb.h
> +++ b/arch/riscv/include/asm/tlb.h
> @@ -12,10 +12,19 @@ static void tlb_flush(struct mmu_gather *tlb);
>   
>   #define tlb_flush tlb_flush
>   #include <asm-generic/tlb.h>
> +#include <asm/mmu_context.h>
>   
>   static inline void tlb_flush(struct mmu_gather *tlb)
>   {
>   #ifdef CONFIG_MMU
> +	/*
> +	 * If ASID is supported, the ASID allocator will either invalidate the
> +	 * ASID or mark it as used. So we can avoid TLB invalidation when
> +	 * pulling down a full mm.
> +	 */


Given the number of bits are limited for the ASID, at some point we'll 
reuse previously allocated ASID so the ASID allocator must make sure to 
invalidate the entries when reusing an ASID: can you point where this is 
done?

Thanks,

Alex


> +	if (static_branch_likely(&use_asid_allocator) && tlb->fullmm)
> +		return;
> +
>   	if (tlb->fullmm || tlb->need_flush_all)
>   		flush_tlb_mm(tlb->mm);
>   	else


From lkp at intel.com  Sat Dec 30 10:55:31 2023
From: lkp at intel.com (kernel test robot)
Date: Sun, 31 Dec 2023 02:55:31 +0800
Subject: [PATCH] firmware: imx: scu: ensure wakeup procedure calls
 pm_system_wakeup()
In-Reply-To: <20231230053831.67661-1-xiaolei.wang@windriver.com>
References: <20231230053831.67661-1-xiaolei.wang@windriver.com>
Message-ID: <202312310227.7eLUYzgH-lkp@intel.com>

Hi Xiaolei,

kernel test robot noticed the following build warnings:

[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on linus/master v6.7-rc7 next-20231222]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Xiaolei-Wang/firmware-imx-scu-ensure-wakeup-procedure-calls-pm_system_wakeup/20231230-134202
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git for-next
patch link:    https://lore.kernel.org/r/20231230053831.67661-1-xiaolei.wang%40windriver.com
patch subject: [PATCH] firmware: imx: scu: ensure wakeup procedure calls pm_system_wakeup()
config: i386-buildonly-randconfig-003-20231230 (https://download.01.org/0day-ci/archive/20231231/202312310227.7eLUYzgH-lkp at intel.com/config)
compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231231/202312310227.7eLUYzgH-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312310227.7eLUYzgH-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> drivers/firmware/imx/imx-scu.c:365:32: warning: unused variable 'imx_scu_pm_ops' [-Wunused-const-variable]
     365 | static const struct dev_pm_ops imx_scu_pm_ops = {
         |                                ^~~~~~~~~~~~~~
   1 warning generated.


vim +/imx_scu_pm_ops +365 drivers/firmware/imx/imx-scu.c

   364	
 > 365	static const struct dev_pm_ops imx_scu_pm_ops = {
   366		SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_scu_suspend_noirq,
   367					      imx_scu_resume_noirq)
   368	};
   369	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From lkp at intel.com  Sat Dec 30 10:55:23 2023
From: lkp at intel.com (kernel test robot)
Date: Sun, 31 Dec 2023 02:55:23 +0800
Subject: [PATCH] firmware: imx: scu: ensure wakeup procedure calls
 pm_system_wakeup()
In-Reply-To: <20231230053831.67661-1-xiaolei.wang@windriver.com>
References: <20231230053831.67661-1-xiaolei.wang@windriver.com>
Message-ID: <202312310208.zIVggTP2-lkp@intel.com>

Hi Xiaolei,

kernel test robot noticed the following build warnings:

[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on linus/master v6.7-rc7 next-20231222]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Xiaolei-Wang/firmware-imx-scu-ensure-wakeup-procedure-calls-pm_system_wakeup/20231230-134202
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git for-next
patch link:    https://lore.kernel.org/r/20231230053831.67661-1-xiaolei.wang%40windriver.com
patch subject: [PATCH] firmware: imx: scu: ensure wakeup procedure calls pm_system_wakeup()
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20231231/202312310208.zIVggTP2-lkp at intel.com/config)
compiler: m68k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231231/202312310208.zIVggTP2-lkp at intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312310208.zIVggTP2-lkp at intel.com/

All warnings (new ones prefixed by >>):

>> drivers/firmware/imx/imx-scu.c:365:32: warning: 'imx_scu_pm_ops' defined but not used [-Wunused-const-variable=]
     365 | static const struct dev_pm_ops imx_scu_pm_ops = {
         |                                ^~~~~~~~~~~~~~


vim +/imx_scu_pm_ops +365 drivers/firmware/imx/imx-scu.c

   364	
 > 365	static const struct dev_pm_ops imx_scu_pm_ops = {
   366		SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_scu_suspend_noirq,
   367					      imx_scu_resume_noirq)
   368	};
   369	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


From jonas at kwiboo.se  Sat Dec 30 12:12:23 2023
From: jonas at kwiboo.se (Jonas Karlman)
Date: Sat, 30 Dec 2023 21:12:23 +0100
Subject: [PATCH v2 0/3] Add hantro g1 video decoder support for RK3588
In-Reply-To: <20231230153159.3748580-1-liujianfeng1994@gmail.com>
References: <97faf49b-0109-439a-accf-251b502ad40b@kwiboo.se>
 <20231230153159.3748580-1-liujianfeng1994@gmail.com>
Message-ID: <b9e6702d-4781-413b-8e4c-0b74272e9f22@kwiboo.se>

Hi Jianfeng,

On 2023-12-30 16:31, amazingfate wrote:
> Hi Jonas,
> 
> On Sat, 30 Dec 2023 12:49:38 +0100, Jonas Karlman <jonas at kwiboo.se> wrote:
>> I have only tested this fork of fluster with ffmpeg 6.x, what version of
>> ffmpeg did you test with? I was expecting it to also work on ffmpeg 5.x.
> 
> I am using ffmpeg 6.0 with v4l2-request patches from libreelec[1].

Great, that patch should match my v4l2-request-n6.0.1 branch [2],
and does not have any NV15/NV20 ffmpeg pix fmt patches that could
interfere.

[2] https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-n6.0.1/

> Ffmpeg v4l2 decoder in fluster fork is using ffmpeg args:
> "-hwaccel_device /dev/dri/renderD128"
> which make the test fall with hantro g1 on rk3588. After removing it I
> can run tests by ffmpeg v4l2-request decoder. 

Thanks for confirming and testing again, and I fully understand why
"-hwaccel_device /dev/dri/renderD128" caused issues on rk3588 :-)

The commit "HACK: hwcontext_drm: do not require drm device" was required
to run ffmpeg without a hwaccel_device, and I tested fluster without it.

Regards,
Jonas

> 
> Rk3566 and rk3588 are sharing the same results:
> JVT-AVC_V1 test suite with decoder FFmpeg-H.264-V4L2-request:
>  Ran 127/135 tests successfully.
> JVT-FR_EXT test suite with decoder FFmpeg-H.264-V4L2-request:
>  Ran 44/69 tests successfully.
> VP8-TEST-VECTORS test suite with decoder FFmpeg-VP8-V4L2-request:
>  Ran 59/61 tests successfully.
> 
> [1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch
> 
> Regards,
> Jianfeng



From frank at oltmanns.dev  Sat Dec 30 13:17:06 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Sat, 30 Dec 2023 22:17:06 +0100
Subject: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher
 clock rate
In-Reply-To: <1845418.atdPhlSkOF@jernej-laptop>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev>
 <1845418.atdPhlSkOF@jernej-laptop>
Message-ID: <87wmsvo0fh.fsf@oltmanns.dev>


On 2023-12-20 at 16:18:49 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a):
>>
>> On 2023-12-19 at 18:04:29 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
>> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns napisal(a):
>> >> This panel is used in the pinephone that runs on a Allwinner A64 SOC.
>> >> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more
>> >> than 500 MHz.
>> >>
>> >> Therefore, change [hv]sync_(start|end) so that we reach a clock rate
>> >> that is high enough to drive PLL-MIPI within its limits.
>> >>
>> >> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
>> >
>> > I'm not too sure about this patch. I see that PLL_MIPI doesn't have set
>> > minimum frequency limit in clock driver. If you add it, clock framework
>> > should find rate that is high enough and divisible with target rate.
>>
>> This one is really a tough nut. Unfortunately, the PLL_MIPI clock for
>> this panel has to run exactly at 6 * panel clock. Let me start by
>> showing the relevant part of the clock tree (this is on the pinephone
>> after applying the patches):
>>     pll-video0                 393600000
>>        pll-mipi                500945454
>>           tcon0                500945454
>>              tcon-data-clock   125236363
>>
>> To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit
>> rate [1]. It's a fixed divisor
>>
>> The panel I'm proposing to change is defined as this:
>>
>>     static const struct st7703_panel_desc xbd599_desc = {
>>     	.mode = &xbd599_mode,
>>     	.lanes = 4,
>>     	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
>>     	.format = MIPI_DSI_FMT_RGB888,
>>     	.init_sequence = xbd599_init_sequence,
>>     };
>>
>> So, we have 24 bpp and 4 lanes. Therefore, the resulting requested
>> tcon-data-clock rate is
>>     crtc_clock * 1000 * (24 / 4) / 4
>>
>> tcon-data-clock therefore requests a parent rate of
>>     4 * (crtc_clock * 1000 * (24 / 4) / 4)
>>
>> The initial 4 is the fixed divisor between tcon0 and tcon-data-clock.
>> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi.
>>
>> Since PLL-MIPI has to run at at least at 500MHz this forces us to have a
>> crtc_clock >= 83.333 MHz. The mode I'm prorposing results in a rate of
>> 83.502 MHz.
>
> This is much better explanation why this change is needed. Still, I think
> adding min and max rate to PLL_MIPI would make sense, so proper rates
> are guaranteed.

Okay, I'll include min and max rate in V2, because you're right that
it's the sane thing to do and actually it wasn't too much work. I (and
others) do experience crashes if pll-mipi is driven below the 500 MHz
mark, so let's fix this once and for all.

> Anyway, do you know where are all those old values come from?

I've done some digging on lore and the values were originally submitted
by Icenowy Zheng as part of a series to support the pinephone's LCD [1].
There has been some refactoring after this initial submission and Ondrej
Jirman took over. But the values are still the ones submitted by
Icenowy, so I've added her to CC. I couldn't find any documentation for
this specific panel.

> And how did
> you come up with new ones?

Trial and no error. :)

No, really, it was just a lucky guess. I know nothing about LCD panels,
so I only looked at the original values:
.htotal =  720 + 40 + 40 + 40,
.vtotal = 1440 + 18 + 10 + 17,

I thought, what if every time I increase a horizontal value by 2, I
increase a vertical value by 1 (very roughly).

So I ended up with:
.htotal =  720 + 65 + 65 + 65,
.vtotal = 1440 + 30 + 22 + 29,

So, in conclusion, I've increased each of the horizontal values by 25
and each of the vertical values by 12. Then I just tried out these new
values, and the world didn't end. :)

If this is stupid, please somebody let me know.

I (and at least one postmarket OS tester) have been daily driving the
panel with these values for about a week now.

I've checked the panel's refresh rate with the following test setup:
 - I created a 60 fps video that shows the current frame number in each
   frame. The video is 10 seconds (600 frames) long. [2]
 - I played that video on my pinephone using vlc. [3]
 - I recorded the playback with a Google Pixel 5 phone at 1/8 slow
   motion (240 fps).
 - I converted the video into individual pictures [4], resized
   the pictures to 10% [5], and finally - after deleting some superfluous
   pictures at the beginning and end - I created one big collage out of
   these [6].

I've uploaded the video[7], resulting collage [8] and the individual
pictures [9].

In the resulting picture you can see that in the beginning frame 2 is
missing and frame 136 is only barely visible because it is stuck too
long on frame 135. Other than that, I think this looks pretty good.

> I guess you can't just simply change timings,
> there are probably some HW limitations? Do you know if BSP kernel support
> this panel and how this situation is solved there?

I'm not aware of any BSP kernel that supports this kernel.

>> If we only changed the constraints on the PLL_MIPI without changing the
>> panel mode, we end up with a mismatch. This, in turn, would result in
>> dropped frames, right?
>
> From what I read, I think frame rate would be higher than 60 fps. What
> exactly would happen depends on the panel.

To give this a fair comparison, I tested with the original timings but
with correcting the panel's clock rate of 74844 kHZ instead of 69000 kHz
as discussed elsewhere in this thread [10] and pll-mipi running at
500MHz (because that's really a must to run the pinephone in a stable
manner). I used the same procedure as described above. Again, I've
uploaded the resulting video [11], collage [12] and the individual files
[13].

Here, the being stuck happens much more often, e.g. frames 23, 31, 40,
49, 58, 66 etc.

So, I think, in order to have a better user experience, I think it's a
good idea to update the XBD599 panel with the new values I proposed in
this patch.

Best regards,
  Frank

[1]: https://lore.kernel.org/all/20200311162936.221613-1-icenowy at aosc.io/
[2]: ffmpeg -f lavfi -i testsrc=duration=10:size=80x50:rate=60 -vf \
   "drawtext=text=%{n}:fontsize=36:r=60:x=(w-tw)/2: y=h-(1*lh):fontcolor=white:box=1:boxcolor=0x00000099"\
   test_80x50.mp4
[3]: cvlc test_80x50.mp4  --fullscreen --play-and-exit
[4]: ffmpeg -i video_from_pixel_phone.mp4 -vsync vfr output_%04d.jpg
[5]: mogrify -resize 10% output_*.jpg
[6]: montage output_*.jpg -tile 20x -geometry +0+0 \
      verify_panel_65_65_65_30_22_29_83502.jpg
[7]: https://share.mailbox.org/ajax/share/0a471a7205211949ad7067d521194571984a15d1613d74be/1/8/Njg/NjgvMzE
[8]: https://share.mailbox.org/ajax/share/0741f90808f2df4e7d1e5078f2df43cfae732189f27e75e3/1/8/Njg/NjgvMzI
[9]: https://share.mailbox.org/ajax/share/0471bc0706bfee4e4e1a0086bfee40ecba2123a14c9b8d4d/1/8/Njg/NjgvMzA
[10]: https://lore.kernel.org/all/87v88qk3ge.fsf at oltmanns.dev/
[11]: https://share.mailbox.org/ajax/share/036036d00eac574e3f02adfeac5741dda88105026a1221f4/1/8/Njg/NjgvMzQ
[12]: https://share.mailbox.org/ajax/share/05f6d3e905e30058566cfe65e300486aa936122f2414639a/1/8/Njg/NjgvMzU
[13]: https://share.mailbox.org/ajax/share/0cf25a810cce2357c62468ecce234681a4e8e674d38d02cd/1/8/Njg/NjgvMzM

>
> Best regards,
> Jernej
>
>>
>> Best regards,
>>   Frank
>>
>> [1] Source:
>> https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/sun4i_tcon.c#L346
>>
>> >
>> > Best regards,
>> > Jernej
>> >
>> >> ---
>> >>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++-------
>> >>  1 file changed, 7 insertions(+), 7 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>> >> index b55bafd1a8be..6886fd7f765e 100644
>> >> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>> >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
>> >> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 *ctx)
>> >>
>> >>  static const struct drm_display_mode xbd599_mode = {
>> >>  	.hdisplay    = 720,
>> >> -	.hsync_start = 720 + 40,
>> >> -	.hsync_end   = 720 + 40 + 40,
>> >> -	.htotal	     = 720 + 40 + 40 + 40,
>> >> +	.hsync_start = 720 + 65,
>> >> +	.hsync_end   = 720 + 65 + 65,
>> >> +	.htotal      = 720 + 65 + 65 + 65,
>> >>  	.vdisplay    = 1440,
>> >> -	.vsync_start = 1440 + 18,
>> >> -	.vsync_end   = 1440 + 18 + 10,
>> >> -	.vtotal	     = 1440 + 18 + 10 + 17,
>> >> -	.clock	     = 69000,
>> >> +	.vsync_start = 1440 + 30,
>> >> +	.vsync_end   = 1440 + 30 + 22,
>> >> +	.vtotal	     = 1440 + 30 + 22 + 29,
>> >> +	.clock	     = (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 / 1000,
>> >>  	.flags	     = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
>> >>  	.width_mm    = 68,
>> >>  	.height_mm   = 136,
>> >>
>> >>
>>


From dmitry.baryshkov at linaro.org  Sat Dec 30 16:48:12 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sun, 31 Dec 2023 02:48:12 +0200
Subject: [PATCH v2 1/3] iommu/msm-iommu: don't limit the driver too much
In-Reply-To: <20231216162700.863456-2-dmitry.baryshkov@linaro.org>
References: <20231216162700.863456-1-dmitry.baryshkov@linaro.org>
 <20231216162700.863456-2-dmitry.baryshkov@linaro.org>
Message-ID: <cb1129ca-6ee9-46cf-8ea7-77707f9d4edc@linaro.org>

On 16/12/2023 18:26, Dmitry Baryshkov wrote:
> In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
> driver just to those machines. Allow it to be built for any 32-bit
> Qualcomm platform (ARCH_QCOM).
> 
> Acked-by: Robin Murphy <robin.murphy at arm.com>
> Acked-by: Joerg Roedel <jroedel at suse.de>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>

Robin, Joerg, Will, is there any chance this can be picked up into 6.8? 
We will proceed with merging the rest through qocm tree into 6.9.

> ---
>   drivers/iommu/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 9a29d742617e..0d6095290b6a 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -179,7 +179,7 @@ config FSL_PAMU
>   config MSM_IOMMU
>   	bool "MSM IOMMU Support"
>   	depends on ARM
> -	depends on ARCH_MSM8X60 || ARCH_MSM8960 || COMPILE_TEST
> +	depends on ARCH_QCOM || COMPILE_TEST
>   	select IOMMU_API
>   	select IOMMU_IO_PGTABLE_ARMV7S
>   	help

-- 
With best wishes
Dmitry



From andersson at kernel.org  Sat Dec 30 19:31:51 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Sat, 30 Dec 2023 19:31:51 -0800
Subject: [GIT PULL] A few more Qualcomm Arm32 DeviceTree updates fr v6.8
Message-ID: <20231231033153.3262575-1-andersson@kernel.org>


The following changes since commit 648002a27c6b3ae293cc415e1fbf20aaa6af8bd3:

  ARM: dts: qcom: msm8974*: Re-enable remoteprocs on various boards (2023-12-17 12:09:42 -0600)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm32-for-6.8-2

for you to fetch changes up to cc6fc55c7ae04ab19b3972f78d3a8b1be32bf533:

  ARM: dts: qcom: sdx55: Fix the base address of PCIe PHY (2023-12-19 11:23:24 -0600)

----------------------------------------------------------------
A few more Qualcomm Arm32 DeviceTree updates fr v6.8

The recently introduced changes to the SDX55 USB controller interrupt
flags prevents the USB controller from probing. These patches corrects
the PDC's interrupt-cells, so that appropriate interrupt controller
(which supports both-edge interrupts) can be used instead, which
resolves the issue.

The SDX55 PCIe PHY base address is also adjusted, from a mistake when
the node recently was transitioned to the modernized DeviceTree binding.

----------------------------------------------------------------
Johan Hovold (3):
      ARM: dts: qcom: sdx55: fix pdc '#interrupt-cells'
      ARM: dts: qcom: sdx55: fix USB DP/DM HS PHY interrupts
      ARM: dts: qcom: sdx55: fix USB SS wakeup

Manivannan Sadhasivam (1):
      ARM: dts: qcom: sdx55: Fix the base address of PCIe PHY

 arch/arm/boot/dts/qcom/qcom-sdx55.dtsi | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)


From andersson at kernel.org  Sat Dec 30 19:41:06 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Sat, 30 Dec 2023 19:41:06 -0800
Subject: [GIT PULL] A few more Qualcomm Arm64 DeviceTree updates for v6.8
Message-ID: <20231231034108.3262678-1-andersson@kernel.org>


The following changes since commit b7b9a6aa7aea2bcba2d35d65e4ce2913115485a3:

  arm64: dts: qcom: sc8180x-primus: Allow UFS regulators load/mode setting (2023-12-17 14:28:17 -0600)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-6.8-2

for you to fetch changes up to 78403b37f6770441f80a78d13772394731afe055:

  arm64: dts: qcom: sc8180x: Fix up PCIe nodes (2023-12-20 06:26:30 -0600)

----------------------------------------------------------------
A few more Qualcomm Arm64 DeviceTree updates for v6.8

This corrects the rate of the UTMI clock on IPQ6018 USB0. The SDHCI
controller on SC7280 gains missing markings for being cache-coherent.
For SC8180X a typo in assignment of PCIe refgen clocks is corrected, PCI
controllers are marked cache-coherent, and the USB SS PHY interrupts are
corrected to allow wakeup.

Similarly USB HS PHY and SS PHY interrupts are corrected to allow
wakeup on SDM670.

On SM8550 the X3 cluster idle state is properly described, and the
latency numbers are adjusted for all the idle states.

The PM8550 regulator supplies on X1E are corrected to match the driver
and binding, and the timer node is updated to avoid an unnecessary
validation error.

----------------------------------------------------------------
Abel Vesa (1):
      arm64: dts: qcom: x1e80100-qcp: Fix supplies for some LDOs in PM8550

Chukun Pan (1):
      arm64: dts: qcom: ipq6018: fix clock rates for GCC_USB0_MOCK_UTMI_CLK

Johan Hovold (3):
      arm64: dts: qcom: sdm670: fix USB DP/DM HS PHY interrupts
      arm64: dts: qcom: sdm670: fix USB SS wakeup
      arm64: dts: qcom: sc8180x: fix USB SS wakeup

Konrad Dybcio (5):
      arm64: dts: qcom: sc7280: Mark SDHCI hosts as cache-coherent
      arm64: dts: qcom: sm8550: Separate out X3 idle state
      arm64: dts: qcom: sm8550: Update idle state time requirements
      arm64: dts: qcom: sc8180x: Mark PCIe hosts cache-coherent
      arm64: dts: qcom: sc8180x: Fix up PCIe nodes

Krzysztof Kozlowski (1):
      arm64: dts: qcom: x1e80100: align mem timer size cells with bindings

 arch/arm64/boot/dts/qcom/ipq6018.dtsi     |  2 +-
 arch/arm64/boot/dts/qcom/sc7280.dtsi      |  2 ++
 arch/arm64/boot/dts/qcom/sc8180x.dtsi     | 14 +++++++++-----
 arch/arm64/boot/dts/qcom/sdm670.dtsi      |  8 ++++----
 arch/arm64/boot/dts/qcom/sm8550.dtsi      | 32 ++++++++++++++++++++-----------
 arch/arm64/boot/dts/qcom/x1e80100-qcp.dts |  4 +---
 arch/arm64/boot/dts/qcom/x1e80100.dtsi    | 20 +++++++++----------
 7 files changed, 48 insertions(+), 34 deletions(-)


From andersson at kernel.org  Sat Dec 30 19:46:47 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Sat, 30 Dec 2023 19:46:47 -0800
Subject: [GIT PULL] A few more Qualcomm Arm64 defconfig updates for v6.8
Message-ID: <20231231034648.3262882-1-andersson@kernel.org>


The following changes since commit 48a9ba5eb4d720c6e21c6e4d2a6fb6e1a97f5f2a:

  arm64: defconfig: enable Qualcomm WSA884x driver (2023-12-17 15:03:06 -0600)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-defconfig-for-6.8-2

for you to fetch changes up to 191fcf77e304392cc330fc19595cb90fd52d595f:

  arm64: defconfig: Enable Qualcomm SC8280XP camera clock controller (2023-12-22 21:22:17 -0600)

----------------------------------------------------------------
A few more Qualcomm Arm64 defconfig updates for v6.8

This enables the base drivers necessary to boot devices on the X1E
platform.
The GPU clock controller for SM8450/SM8550 is enabled and the SC8280XP
camera clock controller is enabled, to enable respective functionality
on these platforms.

----------------------------------------------------------------
Bjorn Andersson (1):
      arm64: defconfig: Enable Qualcomm SC8280XP camera clock controller

Neil Armstrong (1):
      arm64: defconfig: enable GPU clock controller for SM8[45]50

Rajendra Nayak (1):
      arm64: defconfig: Enable X1E80100 SoC base configs

 arch/arm64/configs/defconfig | 6 ++++++
 1 file changed, 6 insertions(+)


From andersson at kernel.org  Sat Dec 30 20:11:14 2023
From: andersson at kernel.org (Bjorn Andersson)
Date: Sat, 30 Dec 2023 20:11:14 -0800
Subject: [GIT PULL] Qualcomm clock updates for v6.8
Message-ID: <20231231041115.3263074-1-andersson@kernel.org>


The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:

  Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-clk-for-6.8

for you to fetch changes up to 757d1ca14f94e4e00777491dcab0b4abee18f9bf:

  clk: qcom: dispcc-sm8650: Add test_ctl parameters to PLL config (2023-12-19 14:12:41 -0600)

----------------------------------------------------------------
Qualcomm clock updates for v6.8

New drivers to support global, display, gpu, tcsr, and rpmh clocks for
the SM8650 platform is introduced.

Global and RPMh clock support for the new X1E80100 platform is added.

Support for the Stromer APCS PLL found in IPQ5018 is added.

A new type of branch clock, with support for controlling separate memory
control bits is introduced, and used in the newly introduced clock
driver for the ECPRI on QDU1000 and QRU1000.

A number of missing clock related to CSI2 on MSM8939 are added. Support
for the camera clock controller on SC8280XP is added.

PLL configuration is corrected in GPU and Video clock controllers for
SM8150, runtim PM support and a few missing resets are added to the
video clock controller.

For SM8550 configuration of a variety of GDSCs in GCC is corrected.
Shared RCGs was not marked appropriately when the driver was upstreamed,
so this is corrected as well.
For GPU and Display clock controllers PLL configuration settings are
reviewed and corrected.

----------------------------------------------------------------
Bjorn Andersson (5):
      Merge branch '20231026105345.3376-3-bryan.odonoghue at linaro.org' into clk-for-6.8
      Merge branch '20231106-topic-sm8650-upstream-clocks-v3-5-761a6fadb4c0 at linaro.org' into clk-for-6.8
      Merge branch '20231123064735.2979802-2-quic_imrashai at quicinc.com' into clk-for-6.8
      Merge branch '20231205061002.30759-4-quic_sibis at quicinc.com' into clk-for-6.8
      Merge branch '20231201-videocc-8150-v3-1-56bec3a5e443 at quicinc.com' into clk-for-6.8

Bryan O'Donoghue (3):
      dt-bindings: clock: Use gcc.yaml for common clock properties
      dt-bindings: clock: Add SC8280XP CAMCC
      clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC

Dan Carpenter (1):
      clk: qcom: camcc-sc8280xp: Prevent error pointer dereference

Gokul Sriram Palanisamy (2):
      dt-bindings: clock: qcom,a53pll: add IPQ5018 compatible
      clk: qcom: apss-ipq-pll: add support for IPQ5018

Imran Shaik (2):
      dt-bindings: clock: qcom: Add ECPRICC clocks for QDU1000 and QRU1000
      clk: qcom: Add ECPRICC driver support for QDU1000 and QRU1000

Konrad Dybcio (9):
      clk: qcom: gcc-sm8550: Add the missing RETAIN_FF_ENABLE GDSC flag
      clk: qcom: gcc-sm8550: Mark the PCIe GDSCs votable
      clk: qcom: gcc-sm8550: use collapse-voting for PCIe GDSCs
      clk: qcom: gcc-sm8550: Mark RCGs shared where applicable
      clk: qcom: gpucc-sm8550: Update GPU PLL settings
      clk: qcom: dispcc-sm8550: Update disp PLL settings
      clk: qcom: dispcc-sm8550: Use the correct PLL configuration function
      clk: qcom: gpucc-sm8650: Add test_ctl parameters to PLL config
      clk: qcom: dispcc-sm8650: Add test_ctl parameters to PLL config

Neil Armstrong (11):
      dt-bindings: clock: qcom: document the SM8650 TCSR Clock Controller
      dt-bindings: clock: qcom: document the SM8650 General Clock Controller
      dt-bindings: clock: qcom: document the SM8650 Display Clock Controller
      dt-bindings: clock: qcom: document the SM8650 GPU Clock Controller
      dt-bindings: clock: qcom: Document the SM8650 RPMH Clock Controller
      clk: qcom: add the SM8650 Global Clock Controller driver, part 1
      clk: qcom: add the SM8650 Global Clock Controller driver, part 2
      clk: qcom: add the SM8650 TCSR Clock Controller driver
      clk: qcom: add the SM8650 Display Clock Controller driver
      clk: qcom: add the SM8650 GPU Clock Controller driver
      clk: qcom: rpmh: add clocks for SM8650

Rajendra Nayak (4):
      dt-bindings: clock: qcom: Add X1E80100 GCC clocks
      dt-bindings: clock: qcom-rpmhcc: Add RPMHCC bindings for X1E80100
      clk: qcom: Add Global Clock controller (GCC) driver for X1E80100
      clk: qcom: rpmh: Add support for X1E80100 rpmh clocks

Robert Marko (1):
      dt-bindings: clock: qcom,gcc-ipq6018: split to separate schema

Satya Priya Kakitapalli (5):
      clk: qcom: gpucc-sm8150: Update the gpu_cc_pll1 config
      dt-bindings: clock: Update the videocc resets for sm8150
      clk: qcom: videocc-sm8150: Update the videocc resets
      clk: qcom: videocc-sm8150: Add missing PLL config property
      clk: qcom: videocc-sm8150: Add runtime PM support

Taniya Das (1):
      clk: qcom: branch: Add mem ops support for branch2 clocks

Vincent Knecht (2):
      dt-bindings: clock: qcom,gcc-msm8939: Add CSI2 related clocks
      clk: qcom: gcc-msm8939: Add missing CSI2 related clocks

 .../devicetree/bindings/clock/qcom,a53pll.yaml     |    1 +
 .../bindings/clock/qcom,camcc-sm8250.yaml          |   18 +-
 .../bindings/clock/qcom,gcc-ipq6018.yaml           |   57 +
 .../devicetree/bindings/clock/qcom,gcc-other.yaml  |    3 -
 .../bindings/clock/qcom,qdu1000-ecpricc.yaml       |   68 +
 .../devicetree/bindings/clock/qcom,rpmhcc.yaml     |    2 +
 .../bindings/clock/qcom,sc7180-camcc.yaml          |   18 +-
 .../bindings/clock/qcom,sc7280-camcc.yaml          |   18 +-
 .../bindings/clock/qcom,sdm845-camcc.yaml          |   18 +-
 .../bindings/clock/qcom,sm8450-camcc.yaml          |   20 +-
 .../bindings/clock/qcom,sm8450-gpucc.yaml          |    2 +
 .../bindings/clock/qcom,sm8550-tcsr.yaml           |    8 +-
 .../bindings/clock/qcom,sm8650-dispcc.yaml         |  106 +
 .../devicetree/bindings/clock/qcom,sm8650-gcc.yaml |   65 +
 .../bindings/clock/qcom,x1e80100-gcc.yaml          |   72 +
 drivers/clk/qcom/Kconfig                           |   63 +
 drivers/clk/qcom/Makefile                          |    7 +
 drivers/clk/qcom/apss-ipq-pll.c                    |   21 +
 drivers/clk/qcom/camcc-sc8280xp.c                  | 3045 +++++++++
 drivers/clk/qcom/clk-branch.c                      |   38 +
 drivers/clk/qcom/clk-branch.h                      |   21 +
 drivers/clk/qcom/clk-rpmh.c                        |   58 +
 drivers/clk/qcom/dispcc-sm8550.c                   |   12 +-
 drivers/clk/qcom/dispcc-sm8650.c                   | 1818 ++++++
 drivers/clk/qcom/ecpricc-qdu1000.c                 | 2456 +++++++
 drivers/clk/qcom/gcc-msm8939.c                     |  110 +-
 drivers/clk/qcom/gcc-sm8550.c                      |  110 +-
 drivers/clk/qcom/gcc-sm8650.c                      | 3849 +++++++++++
 drivers/clk/qcom/gcc-x1e80100.c                    | 6807 ++++++++++++++++++++
 drivers/clk/qcom/gpucc-sm8150.c                    |    4 +-
 drivers/clk/qcom/gpucc-sm8550.c                    |    6 +-
 drivers/clk/qcom/gpucc-sm8650.c                    |  663 ++
 drivers/clk/qcom/tcsrcc-sm8650.c                   |  182 +
 drivers/clk/qcom/videocc-sm8150.c                  |   25 +-
 include/dt-bindings/clock/qcom,gcc-msm8939.h       |    6 +
 include/dt-bindings/clock/qcom,qdu1000-ecpricc.h   |  147 +
 include/dt-bindings/clock/qcom,sc8280xp-camcc.h    |  179 +
 include/dt-bindings/clock/qcom,sm8650-dispcc.h     |  102 +
 include/dt-bindings/clock/qcom,sm8650-gcc.h        |  254 +
 include/dt-bindings/clock/qcom,sm8650-gpucc.h      |   43 +
 include/dt-bindings/clock/qcom,sm8650-tcsr.h       |   18 +
 include/dt-bindings/clock/qcom,videocc-sm8150.h    |    4 +
 include/dt-bindings/clock/qcom,x1e80100-gcc.h      |  485 ++
 include/dt-bindings/reset/qcom,sm8650-gpucc.h      |   20 +
 44 files changed, 20891 insertions(+), 138 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,qdu1000-ecpricc.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,sm8650-dispcc.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,x1e80100-gcc.yaml
 create mode 100644 drivers/clk/qcom/camcc-sc8280xp.c
 create mode 100644 drivers/clk/qcom/dispcc-sm8650.c
 create mode 100644 drivers/clk/qcom/ecpricc-qdu1000.c
 create mode 100644 drivers/clk/qcom/gcc-sm8650.c
 create mode 100644 drivers/clk/qcom/gcc-x1e80100.c
 create mode 100644 drivers/clk/qcom/gpucc-sm8650.c
 create mode 100644 drivers/clk/qcom/tcsrcc-sm8650.c
 create mode 100644 include/dt-bindings/clock/qcom,qdu1000-ecpricc.h
 create mode 100644 include/dt-bindings/clock/qcom,sc8280xp-camcc.h
 create mode 100644 include/dt-bindings/clock/qcom,sm8650-dispcc.h
 create mode 100644 include/dt-bindings/clock/qcom,sm8650-gcc.h
 create mode 100644 include/dt-bindings/clock/qcom,sm8650-gpucc.h
 create mode 100644 include/dt-bindings/clock/qcom,sm8650-tcsr.h
 create mode 100644 include/dt-bindings/clock/qcom,x1e80100-gcc.h
 create mode 100644 include/dt-bindings/reset/qcom,sm8650-gpucc.h


From frank at oltmanns.dev  Sun Dec 31 01:10:40 2023
From: frank at oltmanns.dev (Frank Oltmanns)
Date: Sun, 31 Dec 2023 10:10:40 +0100
Subject: [PATCH 4/5] clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's
 n/m ratio
In-Reply-To: <13411739.uLZWGnKmhe@jernej-laptop>
References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev>
 <20231218-pinephone-pll-fixes-v1-4-e238b6ed6dc1@oltmanns.dev>
 <13411739.uLZWGnKmhe@jernej-laptop>
Message-ID: <87jzoug2jz.fsf@oltmanns.dev>


On 2023-12-19 at 17:54:19 +0100, Jernej ?krabec <jernej.skrabec at gmail.com> wrote:
> Dne ponedeljek, 18. december 2023 ob 14:35:22 CET je Frank Oltmanns napisal(a):
>> The Allwinner A64 manual lists the following constraint for the
>> PLL-VIDEO0 clock: 8 <= N/M <= 25
>>
>> Use this constraint.
>>
>> Signed-off-by: Frank Oltmanns <frank at oltmanns.dev>
>> ---
>>  drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> index c034ac027d1c..75d839da446c 100644
>> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
>> @@ -68,7 +68,8 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
>>  				       BIT(28),	/* lock */
>>  				       CLK_SET_RATE_UNGATE);
>>
>> -static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-video0",
>> +static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(pll_video0_clk,
>> +						"pll-video0",
>>  						"osc24M", 0x010,
>>  						192000000,	/* Minimum rate */
>>  						1008000000,	/* Maximum rate */

I just realized that adding the whole ratio limits for ccu_nm is
superfluous as you could just as well express them in for of a minimum
and maximum range:
Since 8 <= N/M <= 25 and parent_rate = 24 MHz, therefore
  192 MHz <= rate <= 600 MHz.

These absolute limits are also listed in Allwinner's A64 manual.

BUT, here the upper limit was raised to 1008 MHz:
5de39acaf34604bd04834f092479cf4dcc946dd "clk: sunxi-ng: a64: Add max.
rate constraint to video PLL"

With this upper limit the ratio limitation is effectively:
8 <= N/M <= 42

Icenowy Zheng (added to CC) had the reasonable explanation that this was
used in the BSP kernel, so we should probably stick to that and ditch
the two PLL-VIDEO0 related patches. What are your thoughts on that?

>> @@ -80,7 +81,10 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-vid
>>  						297000000,	/* frac rate 1 */
>>  						BIT(31),	/* gate */
>>  						BIT(28),	/* lock */
>> -						CLK_SET_RATE_UNGATE);
>> +						CLK_SET_RATE_UNGATE,
>> +						CCU_FEATURE_FRACTIONAL |
>> +						CCU_FEATURE_CLOSEST_RATE,
>
> Above flags are unrelated change, put them in new patch if needed.
>
> Best regards,
> Jernej
>
>> +						8, 25);		/* min/max nm ratio */
>>
>>  static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
>>  					"osc24M", 0x018,
>>
>>


From figure1802 at 126.com  Sun Dec 31 06:18:12 2023
From: figure1802 at 126.com (Ben)
Date: Sun, 31 Dec 2023 22:18:12 +0800 (CST)
Subject: how test the Translation Support for SMMUv3?
In-Reply-To: <ZYyXkMWc7xvE3KkM@Asurada-Nvidia>
References: <61332e87.404e.18caa3d6e15.Coremail.figure1802@126.com>
 <ZYyXkMWc7xvE3KkM@Asurada-Nvidia>
Message-ID: <141aeebe.1299.18cc03d503d.Coremail.figure1802@126.com>

At 2023-12-28 05:30:56, "Nicolin Chen" <nicolinc at nvidia.com> wrote:
>On Wed, Dec 27, 2023 at 03:46:41PM +0800, Ben wrote:
>> Hi Nicolin,
>> I saw your pachset on Add Nested Translation Support for SMMUv3
>> [LWN.net]<https://lwn.net/Articles/931502/>, i have built the
>> kernel and qemu you provided in cover letter.
>> I run a QEMU system as Host, and launch a VM by kvmtool. But i
>> cannot find a IOMMU on VM, how do you test your patchset?
>
>Make sure you build the kernel with CONFIG_IOMMUFD, and QEMU
>likely.
>
>> would you like provide your steps?
>
># A set of sample commands
>echo 0002:01:00.0 | tee /sys/bus/pci/devices/0002\:01\:00.0/driver/unbind; dmesg | tail
>echo 8086 0111 | tee /sys/bus/pci/drivers/vfio-pci/new_id
>
>qemu-1214 -object iommufd,id=iommufd0 \
>-machine virt,accel=kvm,gic-version=3,iommu=nested-smmuv3,iommufd=iommufd0 \
>-cpu host -m 256m -nographic  -kernel /root/Image -bios /root/AAVMF_CODE.fd \
>-initrd /root/buildroot-20200422-aarch64-qemu-test-rootfs.cpio \
>-object memory-backend-ram,size=256m,id=m0 -numa node,cpus=0,nodeid=0,memdev=m0 \

>-device vfio-pci,host=0002:01:00.0,rombar=0,iommufd=iommufd0,id="test0"


Thanks?

I am trying your patchset on FVP (Fixed Virtual Platforms) but failed.

Here is the Host side running on FVP (platform is  rdn1egde).

master:~# echo 0000:05:00.0 > /sys/bus/pci/devices/0000\:05\:00.0/driver/unbind
master:~# echo 0abc aced > /sys/bus/pci/drivers/vfio-pci/new_id

when i want to run the QEMU to launch a VM, some failed, like below:

root at master:/# cat qemu-iommufd.sh 
./build/qemu-system-aarch64 -L /usr/local/share/qemu -object iommufd,id=iommufd0 -machine virt,accel=kvm,gic-version=3,iommu=nested-smmuv3,iommufd=iommufd0 -cpu host -m 256m -nographic -kernel /Image -append "noinintrd nokaslr root=/dev/vda rootfstype=ext4 rw" -drive if=none,file=/busybox_arm64.ext4,id=hd0 -device virtio-blk-device,drive=hd0 -device vfio-pci,host=0000:05:00.0,iommufd=iommufd0,id="test0"
root at master:/# sh qemu-iommufd.sh 
WARNING: Image format was not specified for '/busybox_arm64.ext4' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
qemu-system-aarch64: -device vfio-pci,host=0000:05:00.0,iommufd=iommufd0,id=test0: vfio 0000:05:00.0: vfio /sys/bus/pci/devices/0000:05:00.0/vfio-dev: failed to load "/sys/bus/pci/devices/0000:05:00.0/vfio-dev/vfio0/dev"

It looks cannot find the /sys/bus/pci/devices/0000:05:00.0/vfio-dev/vfio0/dev for this device. 

root at master:/# ls -l /sys/bus/pci/devices/0000\:05\:00.0/vfio-dev/vfio0/
total 0
lrwxrwxrwx 1 root root    0 Dec 31 13:29 device -> ../../../0000:05:00.0
drwxr-xr-x 2 root root    0 Dec 31 13:29 power
lrwxrwxrwx 1 root root    0 Dec 31 13:29 subsystem -> ../../../../../../../../class/vfio-dev
-rw-r--r-- 1 root root 4096 Dec 31 13:20 uevent

any suggestion on that?

BTW, another questions, 
1. does it the device which assigned to VM by VFIO can leverage the nested IOMMU? how about the virtual device emulated  by QEMU without  assigned via VFIO? 
2. when fill the S1 and S2 page table for device on nested IOMMU scenario? does it a shadow page table for vIOMMU on VM? and will trap into hypervisor to refill the real S1 and S2 page table? I am not clear the workflow for your patchset.


From liujianfeng1994 at gmail.com  Sun Dec 31 07:11:10 2023
From: liujianfeng1994 at gmail.com (Jianfeng Liu)
Date: Sun, 31 Dec 2023 23:11:10 +0800
Subject: [PATCH v3 0/2] [v3]Add hantro g1 video decoder support for RK3588
Message-ID: <20231231151112.3994194-1-liujianfeng1994@gmail.com>

This is the v3 version of this series adding hantro g1 video decoder
support for rk3588.

RK3588 has Hantro G1 video decoder known as VDPU121 in TRM of RK3588 which
is capable to decode MPEG2/H.264/VP8 up to 1920x1088. This vpu ip is also
found in RK3568.

Test results from fluster can be found from thread of v2[1][2].

[1] https://lore.kernel.org/all/CAAXNxMT3f68-ptM7Crhrfmn7iwTyJc9pwz4Beob+5beVODaSHQ at mail.gmail.com
[2] https://lore.kernel.org/all/20231230153159.3748580-1-liujianfeng1994 at gmail.com


Changes in v3:
 - Drop code in hantro_drv.c because hantro g1 vpu in rk3588 is compatible
with the one in rk3568, only adding devicetree node should work.
 - Change devicetree node name to video-codec at fdb50000 to match the reg
address.
 - Add dt-bindings rockchip,rk3588-vpu compatible with rockchip,rk3568-vpu
 - Link to v2: https://lore.kernel.org/all/20231228131617.3411561-1-liujianfeng1994 at gmail.com

Jianfeng Liu (2):
  arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588
  dt-bindings: media: rockchip-vpu: Add rk3588 vpu compatible string

 .../bindings/media/rockchip-vpu.yaml          |  3 +++
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 20 +++++++++++++++++++
 2 files changed, 23 insertions(+)

-- 
2.34.1



From liujianfeng1994 at gmail.com  Sun Dec 31 07:11:11 2023
From: liujianfeng1994 at gmail.com (Jianfeng Liu)
Date: Sun, 31 Dec 2023 23:11:11 +0800
Subject: [PATCH v3 1/2] arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588
In-Reply-To: <20231231151112.3994194-1-liujianfeng1994@gmail.com>
References: <20231231151112.3994194-1-liujianfeng1994@gmail.com>
Message-ID: <20231231151112.3994194-2-liujianfeng1994@gmail.com>

This patch enables Hantro G1 video decoder in RK3588's
devicetree.

Tested with FFmpeg v4l2_request code taken from [1]
with MPEG2, H.264 and VP8 samples.

[1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch

Signed-off-by: Jianfeng Liu <liujianfeng1994 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 5fb0baf8a..ab2792162 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -640,6 +640,26 @@ i2c0: i2c at fd880000 {
 		status = "disabled";
 	};
 
+	vpu: video-codec at fdb50000 {
+		compatible = "rockchip,rk3588-vpu", "rockchip,rk3568-vpu";
+		reg = <0x0 0xfdb50000 0x0 0x800>;
+		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH 0>;
+		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+		clock-names = "aclk", "hclk";
+		iommus = <&vdpu_mmu>;
+		power-domains = <&power RK3588_PD_VDPU>;
+	};
+
+	vdpu_mmu: iommu at fdb50800 {
+		compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
+		reg = <0x0 0xfdb50800 0x0 0x40>;
+		interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH 0>;
+		clock-names = "aclk", "iface";
+		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+		power-domains = <&power RK3588_PD_VDPU>;
+		#iommu-cells = <0>;
+	};
+
 	vop: vop at fdd90000 {
 		compatible = "rockchip,rk3588-vop";
 		reg = <0x0 0xfdd90000 0x0 0x4200>, <0x0 0xfdd95000 0x0 0x1000>;
-- 
2.34.1



From liujianfeng1994 at gmail.com  Sun Dec 31 07:11:12 2023
From: liujianfeng1994 at gmail.com (Jianfeng Liu)
Date: Sun, 31 Dec 2023 23:11:12 +0800
Subject: [PATCH v3 2/2] dt-bindings: media: rockchip-vpu: Add rk3588 vpu compatible string
In-Reply-To: <20231231151112.3994194-1-liujianfeng1994@gmail.com>
References: <20231231151112.3994194-1-liujianfeng1994@gmail.com>
Message-ID: <20231231151112.3994194-3-liujianfeng1994@gmail.com>

Add Hantro G1 VPU compatible string for RK3588.
RK3588 has the same Hantro G1 ip as RK3568, which are both
known as VDPU121 in TRM of RK3568 and RK3588.

Signed-off-by: Jianfeng Liu <liujianfeng1994 at gmail.com>
---
 Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
index c57e1f488..16886bccf 100644
--- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
@@ -31,6 +31,9 @@ properties:
       - items:
           - const: rockchip,rk3228-vpu
           - const: rockchip,rk3399-vpu
+      - items:
+          - const: rockchip,rk3588-vpu
+          - const: rockchip,rk3568-vpu
 
   reg:
     maxItems: 1
-- 
2.34.1



From dmitry.baryshkov at linaro.org  Sun Dec 31 09:38:56 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sun, 31 Dec 2023 19:38:56 +0200
Subject: [PATCH 0/2] ARM: implement cacheinfo support (for v7/v7m)
Message-ID: <20231231-armv7-cacheinfo-v1-0-9e8d440b59d9@linaro.org>

Follow the ARM64 platform and implement simple cache information driver.
As it reads data from CTR (ARMv6+) and CLIDR (ARMv7+) registers, it is
limited to the ARMv7 / ARMv7M, providing simple fallback or just
returning -EOPNOTSUPP in case of older platforms.

In theory we should be able to skip CLIDR reading and assume that Dcache
and Icache (or unified L1 cache) always exist if CTR is supported and
returns sensible value. However I think this better be handled by the
maintainers of corresponding platforms.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
Dmitry Baryshkov (2):
      ARM: add CLIDR accessor functions
      ARM: implement cacheinfo support

 arch/arm/Kconfig                 |   1 +
 arch/arm/include/asm/cache.h     |   6 ++
 arch/arm/include/asm/cachetype.h |  13 ++++
 arch/arm/kernel/Makefile         |   1 +
 arch/arm/kernel/cacheinfo.c      | 164 +++++++++++++++++++++++++++++++++++++++
 include/linux/cacheinfo.h        |   2 +-
 6 files changed, 186 insertions(+), 1 deletion(-)
---
base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
change-id: 20231231-armv7-cacheinfo-9fa533ae371e

Best regards,
-- 
Dmitry Baryshkov <dmitry.baryshkov at linaro.org>



From dmitry.baryshkov at linaro.org  Sun Dec 31 09:38:57 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sun, 31 Dec 2023 19:38:57 +0200
Subject: [PATCH 1/2] ARM: add CLIDR accessor functions
In-Reply-To: <20231231-armv7-cacheinfo-v1-0-9e8d440b59d9@linaro.org>
References: <20231231-armv7-cacheinfo-v1-0-9e8d440b59d9@linaro.org>
Message-ID: <20231231-armv7-cacheinfo-v1-1-9e8d440b59d9@linaro.org>

Add functions to read the CLIDR, Cache Level ID Register.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 arch/arm/include/asm/cachetype.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/include/asm/cachetype.h b/arch/arm/include/asm/cachetype.h
index e8c30430be33..90203a6d7270 100644
--- a/arch/arm/include/asm/cachetype.h
+++ b/arch/arm/include/asm/cachetype.h
@@ -81,6 +81,14 @@ static inline unsigned int read_ccsidr(void)
 	asm volatile("mrc p15, 1, %0, c0, c0, 0" : "=r" (val));
 	return val;
 }
+
+static inline unsigned int read_clidr(void)
+{
+	unsigned int val;
+
+	asm volatile("mrc p15, 1, %0, c0, c0, 1" : "=r" (val));
+	return val;
+}
 #else /* CONFIG_CPU_V7M */
 #include <linux/io.h>
 #include "asm/v7m.h"
@@ -94,6 +102,11 @@ static inline unsigned int read_ccsidr(void)
 {
 	return readl(BASEADDR_V7M_SCB + V7M_SCB_CCSIDR);
 }
+
+static inline unsigned int read_clidr(void)
+{
+	return readl(BASEADDR_V7M_SCB + V7M_SCB_CLIDR);
+}
 #endif
 
 #endif

-- 
2.39.2



From dmitry.baryshkov at linaro.org  Sun Dec 31 09:38:58 2023
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Sun, 31 Dec 2023 19:38:58 +0200
Subject: [PATCH 2/2] ARM: implement cacheinfo support
In-Reply-To: <20231231-armv7-cacheinfo-v1-0-9e8d440b59d9@linaro.org>
References: <20231231-armv7-cacheinfo-v1-0-9e8d440b59d9@linaro.org>
Message-ID: <20231231-armv7-cacheinfo-v1-2-9e8d440b59d9@linaro.org>

On ARMv7 / v7m machines read CTR and CLIDR registers to provide
information regarding the cache topology. Earlier machines should
describe full cache topology in the device tree.

Note, this follows the ARM64 cacheinfo support and provides only minimal
support required to bootstrap cache info. All useful properties should
be decribed in Device Tree.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
---
 arch/arm/Kconfig             |   1 +
 arch/arm/include/asm/cache.h |   6 ++
 arch/arm/kernel/Makefile     |   1 +
 arch/arm/kernel/cacheinfo.c  | 164 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/cacheinfo.h    |   2 +-
 5 files changed, 173 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8f47d6762ea4..cb293ddae6bb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -5,6 +5,7 @@ config ARM
 	select ARCH_32BIT_OFF_T
 	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE if HAVE_KRETPROBES && FRAME_POINTER && !ARM_UNWIND
 	select ARCH_HAS_BINFMT_FLAT
+	select ARCH_HAS_CACHE_LINE_SIZE if OF
 	select ARCH_HAS_CPU_FINALIZE_INIT if MMU
 	select ARCH_HAS_CURRENT_STACK_POINTER
 	select ARCH_HAS_DEBUG_VIRTUAL if MMU
diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index e3ea34558ada..ecbc100d22a5 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -26,4 +26,10 @@
 
 #define __read_mostly __section(".data..read_mostly")
 
+#ifndef __ASSEMBLY__
+#ifdef CONFIG_ARCH_HAS_CACHE_LINE_SIZE
+int cache_line_size(void);
+#endif
+#endif
+
 #endif
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 771264d4726a..b39c38ee9fdb 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -40,6 +40,7 @@ obj-y		+= entry-armv.o
 endif
 
 obj-$(CONFIG_MMU)		+= bugs.o
+obj-$(CONFIG_OF)		+= cacheinfo.o
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 obj-$(CONFIG_ISA_DMA_API)	+= dma.o
 obj-$(CONFIG_FIQ)		+= fiq.o fiqasm.o
diff --git a/arch/arm/kernel/cacheinfo.c b/arch/arm/kernel/cacheinfo.c
new file mode 100644
index 000000000000..878ff4d10139
--- /dev/null
+++ b/arch/arm/kernel/cacheinfo.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ *  ARM cacheinfo support
+ *
+ *  Copyright (C) 2023 Linaro Ltd.
+ *  Copyright (C) 2015 ARM Ltd.
+ *  All Rights Reserved
+ */
+
+#include <linux/bitfield.h>
+#include <linux/cacheinfo.h>
+#include <linux/of.h>
+
+#include <asm/cachetype.h>
+#include <asm/cputype.h>
+#include <asm/system_info.h>
+
+/* Ctypen, bits[3(n - 1) + 2 : 3(n - 1)], for n = 1 to 7 */
+#define CLIDR_CTYPE_SHIFT(level)	(3 * (level - 1))
+#define CLIDR_CTYPE_MASK(level)		(7 << CLIDR_CTYPE_SHIFT(level))
+#define CLIDR_CTYPE(clidr, level)	\
+	(((clidr) & CLIDR_CTYPE_MASK(level)) >> CLIDR_CTYPE_SHIFT(level))
+
+#define MAX_CACHE_LEVEL			7	/* Max 7 level supported */
+
+#define CTR_FORMAT_MASK	GENMASK(27, 24)
+#define CTR_CWG_MASK	GENMASK(27, 24)
+#define CTR_DSIZE_LEN_MASK GENMASK(13, 12)
+#define CTR_ISIZE_LEN_MASK GENMASK(1, 0)
+
+/* Also valid for v7m */
+static inline int cache_line_size_cp15(void)
+{
+	u32 ctr = read_cpuid_cachetype();
+	u32 format = FIELD_GET(CTR_FORMAT_MASK, ctr);
+
+	if (format == 4) {
+		u32 cwg = FIELD_GET(CTR_CWG_MASK, ctr);
+
+		return cwg ? 4 << cwg : ARCH_DMA_MINALIGN;
+	} else if (WARN_ON_ONCE(format != 0)) {
+		return ARCH_DMA_MINALIGN;
+	}
+
+	return 8 << max(FIELD_GET(CTR_ISIZE_LEN_MASK, ctr),
+			FIELD_GET(CTR_DSIZE_LEN_MASK, ctr));
+}
+
+int cache_line_size(void)
+{
+	if (coherency_max_size != 0)
+		return coherency_max_size;
+
+	/* CP15 is optional / implementation defined before ARMv6 */
+	if (cpu_architecture() < CPU_ARCH_ARMv6)
+		return ARCH_DMA_MINALIGN;
+
+	return cache_line_size_cp15();
+}
+EXPORT_SYMBOL_GPL(cache_line_size);
+
+static inline enum cache_type get_cache_type(int level)
+{
+	u32 clidr;
+
+	if (level > MAX_CACHE_LEVEL)
+		return CACHE_TYPE_NOCACHE;
+
+	clidr = read_clidr();
+
+	return CLIDR_CTYPE(clidr, level);
+}
+
+static void ci_leaf_init(struct cacheinfo *this_leaf,
+			 enum cache_type type, unsigned int level)
+{
+	this_leaf->level = level;
+	this_leaf->type = type;
+}
+
+static int detect_cache_level(unsigned int *level_p, unsigned int *leaves_p)
+{
+	unsigned int ctype, level, leaves;
+
+	/* CLIDR is not present before ARMv7/v7m */
+	if (cpu_architecture() < CPU_ARCH_ARMv7)
+		return -EOPNOTSUPP;
+
+	for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
+		ctype = get_cache_type(level);
+		if (ctype == CACHE_TYPE_NOCACHE) {
+			level--;
+			break;
+		}
+		/* Separate instruction and data caches */
+		leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
+	}
+
+	*level_p = level;
+	*leaves_p = leaves;
+
+	return 0;
+}
+
+int early_cache_level(unsigned int cpu)
+{
+	struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+
+	return detect_cache_level(&this_cpu_ci->num_levels, &this_cpu_ci->num_leaves);
+}
+
+int init_cache_level(unsigned int cpu)
+{
+	unsigned int level, leaves;
+	struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+	int fw_level;
+	int ret;
+
+	ret = detect_cache_level(&level, &leaves);
+	if (ret)
+		return ret;
+
+	fw_level = of_find_last_cache_level(cpu);
+
+	if (level < fw_level) {
+		/*
+		 * some external caches not specified in CLIDR_EL1
+		 * the information may be available in the device tree
+		 * only unified external caches are considered here
+		 */
+		leaves += (fw_level - level);
+		level = fw_level;
+	}
+
+	this_cpu_ci->num_levels = level;
+	this_cpu_ci->num_leaves = leaves;
+	return 0;
+}
+
+int populate_cache_leaves(unsigned int cpu)
+{
+	unsigned int level, idx;
+	enum cache_type type;
+	struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+	struct cacheinfo *this_leaf = this_cpu_ci->info_list;
+	unsigned int arch = cpu_architecture();
+
+	/* CLIDR is not present before ARMv7/v7m */
+	if (arch < CPU_ARCH_ARMv7)
+		return -EOPNOTSUPP;
+
+	for (idx = 0, level = 1; level <= this_cpu_ci->num_levels &&
+	     idx < this_cpu_ci->num_leaves; idx++, level++) {
+		type = get_cache_type(level);
+		if (type == CACHE_TYPE_SEPARATE) {
+			ci_leaf_init(this_leaf++, CACHE_TYPE_DATA, level);
+			ci_leaf_init(this_leaf++, CACHE_TYPE_INST, level);
+		} else {
+			ci_leaf_init(this_leaf++, type, level);
+		}
+	}
+
+	return 0;
+}
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index d504eb4b49ab..cb1222b8bbc8 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -132,7 +132,7 @@ static inline int get_cpu_cacheinfo_id(int cpu, int level)
 	return -1;
 }
 
-#ifdef CONFIG_ARM64
+#if defined(CONFIG_ARM64) || defined(CONFIG_ARM)
 #define use_arch_cache_info()	(true)
 #else
 #define use_arch_cache_info()	(false)

-- 
2.39.2



From alexey.klimov at linaro.org  Sun Dec 31 16:00:08 2023
From: alexey.klimov at linaro.org (Alexey Klimov)
Date: Mon,  1 Jan 2024 00:00:08 +0000
Subject: [PATCH RESEND] arm64: dts: allwinner: a64: Add thermal trip points for GPU
Message-ID: <20240101000008.65747-1-alexey.klimov@linaro.org>

Without trip points for GPU, the following errors are printed in the
dmesg log and the sun8i-thermal driver fails to load:

thermal_sys: Failed to find 'trips' node
thermal_sys: Failed to find trip points for thermal-sensor id=1
sun8i-thermal: probe of 1c25000.thermal-sensor failed with error -22

When thermal zones are defined, trip points definitions are mandatory.
Trip values for the GPU are assumed to be the same values as the CPU
ones. The available specs do not provide any hints about thermal regimes
for the GPU and it seems GPU is implemented on the same die as the CPU.

Tested on Pine a64+.

Cc: Samuel Holland <samuel at sholland.org>
Cc: Jernej Skrabec <jernej.skrabec at gmail.com>
Cc: Chen-Yu Tsai <wens at csie.org>
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: devicetree at vger.kernel.org
Signed-off-by: Alexey Klimov <alexey.klimov at linaro.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 62f45f71ec65..07963eea1bf0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -243,6 +243,29 @@ gpu0_thermal: gpu0-thermal {
 			polling-delay-passive = <0>;
 			polling-delay = <0>;
 			thermal-sensors = <&ths 1>;
+
+			trips {
+				gpu0_alert0: gpu0_alert0 {
+					/* milliCelsius */
+					temperature = <75000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+
+				gpu0_alert1: gpu0_alert1 {
+					/* milliCelsius */
+					temperature = <90000>;
+					hysteresis = <2000>;
+					type = "hot";
+				};
+
+				gpu0_crit: gpu0_crit {
+					/* milliCelsius */
+					temperature = <110000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
 		};
 
 		gpu1_thermal: gpu1-thermal {
@@ -250,6 +273,29 @@ gpu1_thermal: gpu1-thermal {
 			polling-delay-passive = <0>;
 			polling-delay = <0>;
 			thermal-sensors = <&ths 2>;
+
+			trips {
+				gpu1_alert0: gpu1_alert0 {
+					/* milliCelsius */
+					temperature = <75000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+
+				gpu1_alert1: gpu1_alert1 {
+					/* milliCelsius */
+					temperature = <90000>;
+					hysteresis = <2000>;
+					type = "hot";
+				};
+
+				gpu1_crit: gpu1_crit {
+					/* milliCelsius */
+					temperature = <110000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
 		};
 	};
 
-- 
2.40.1



From skinsburskii at linux.microsoft.com  Sun Dec 31 19:33:01 2023
From: skinsburskii at linux.microsoft.com (Stanislav Kinsburskii)
Date: Sun, 31 Dec 2023 19:33:01 -0800
Subject: [PATCH v2 04/17] kexec: Add KHO parsing support
In-Reply-To: <20231222193607.15474-5-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222193607.15474-5-graf@amazon.com>
Message-ID: <20240101033301.GA765@skinsburskii.>

On Fri, Dec 22, 2023 at 07:35:54PM +0000, Alexander Graf wrote:
> +/**
> + * kho_reserve_previous_mem - Adds all memory reservations into memblocks
> + * and moves us out of the scratch only phase. Must be called after page tables
> + * are initialized and memblock_allow_resize().
> + */
> +void __init kho_reserve_previous_mem(void)
> +{
> +	void *mem_virt = __va(mem_phys);
> +	int off, err;
> +
> +	if (!handover_phys || !mem_phys)
> +		return;
> +
> +	/*
> +	 * We reached here because we are running inside a working linear map
> +	 * that allows us to resize memblocks dynamically. Use the chance and
> +	 * populate the global fdt pointer
> +	 */
> +	fdt = __va(handover_phys);
> +
> +	off = fdt_path_offset(fdt, "/");
> +	if (off < 0) {
> +		fdt = NULL;
> +		return;
> +	}
> +
> +	err = fdt_node_check_compatible(fdt, off, "kho-v1");
> +	if (err) {
> +		pr_warn("KHO has invalid compatible, disabling.");

It looks like KHO preserved regions won't be reserved in this case.
Should KHO DT state be destroyed here to prevent KHO memory regions
reuse upon rollback?

> +
> +void __init kho_populate(phys_addr_t handover_dt_phys, phys_addr_t scratch_phys,
> +			 u64 scratch_len, phys_addr_t mem_cache_phys,
> +			 u64 mem_cache_len)
> +{
> +	void *handover_dt;
> +
> +	/* Determine the real size of the DT */
> +	handover_dt = early_memremap(handover_dt_phys, sizeof(struct fdt_header));
> +	if (!handover_dt) {
> +		pr_warn("setup: failed to memremap kexec FDT (0x%llx)\n", handover_dt_phys);
> +		return;
> +	}
> +
> +	if (fdt_check_header(handover_dt)) {
> +		pr_warn("setup: kexec handover FDT is invalid (0x%llx)\n", handover_dt_phys);
> +		early_memunmap(handover_dt, PAGE_SIZE);
> +		return;
> +	}
> +
> +	handover_len = fdt_totalsize(handover_dt);
> +	handover_phys = handover_dt_phys;
> +
> +	/* Reserve the DT so we can still access it in late boot */
> +	memblock_reserve(handover_phys, handover_len);
> +
> +	/* Reserve the mem cache so we can still access it later */
> +	memblock_reserve(mem_cache_phys, mem_cache_len);
> +
> +	/*
> +	 * We pass a safe contiguous block of memory to use for early boot purporses from
> +	 * the previous kernel so that we can resize the memblock array as needed.
> +	 */
> +	memblock_add(scratch_phys, scratch_len);
> +
> +	if (WARN_ON(memblock_mark_scratch(scratch_phys, scratch_len))) {
> +		pr_err("Kexec failed to mark the scratch region. Disabling KHO.");
> +		handover_len = 0;
> +		handover_phys = 0;

Same question here: doesn't all the KHO state gets invalid in case of any
restoration error?



From skinsburskii at linux.microsoft.com  Sun Dec 31 19:55:18 2023
From: skinsburskii at linux.microsoft.com (Stanislav Kinsburskii)
Date: Sun, 31 Dec 2023 19:55:18 -0800
Subject: [PATCH v2 07/17] kexec: Add documentation for KHO
In-Reply-To: <20231222193607.15474-8-graf@amazon.com>
References: <20231222193607.15474-1-graf@amazon.com>
 <20231222193607.15474-8-graf@amazon.com>
Message-ID: <20240101035518.GA804@skinsburskii.>

On Fri, Dec 22, 2023 at 07:35:57PM +0000, Alexander Graf wrote:
> diff --git a/Documentation/kho/concepts.rst b/Documentation/kho/concepts.rst
> new file mode 100644
> index 000000000000..8e4fe8c57865
> --- /dev/null
> +++ b/Documentation/kho/concepts.rst
> @@ -0,0 +1,88 @@
> +.. SPDX-License-Identifier: GPL-2.0-or-later
> +
> +=======================
> +Kexec Handover Concepts
> +=======================
> +
> +Kexec HandOver (KHO) is a mechanism that allows Linux to preserve state -
> +arbitrary properties as well as memory locations - across kexec.
> +
> +It introduces multiple concepts:
> +
> +KHO Device Tree
> +---------------
> +
> +Every KHO kexec carries a KHO specific flattened device tree blob that
> +describes the state of the system. Device drivers can register to KHO to
> +serialize their state before kexec. After KHO, device drivers can read
> +the device tree and extract previous state.
> +
> +KHO only uses the fdt container format and libfdt library, but does not
> +adhere to the same property semantics that normal device trees do: Properties
> +are passed in native endianness and standardized properties like ``regs`` and
> +``ranges`` do not exist, hence there are no ``#...-cells`` properties.
> +
> +KHO introduces a new concept to its device tree: ``mem`` properties. A
> +``mem`` property can inside any subnode in the device tree. When present,

Should it be "property can be" ?

...

> diff --git a/Documentation/kho/usage.rst b/Documentation/kho/usage.rst
> new file mode 100644
> index 000000000000..5efa2a58f9c3
> --- /dev/null
> +++ b/Documentation/kho/usage.rst
> @@ -0,0 +1,57 @@
> +.. SPDX-License-Identifier: GPL-2.0-or-later
> +
> +====================
> +Kexec Handover Usage
> +====================
> +
> +Kexec HandOver (KHO) is a mechanism that allows Linux to preserve state -
> +arbitrary properties as well as memory locations - across kexec.
> +
> +This document expects that you are familiar with the base KHO
> +:ref:`Documentation/kho/concepts.rst <concepts>`. If you have not read
> +them yet, please do so now.
> +
> +Prerequisites
> +-------------
> +
> +KHO is available when the ``CONFIG_KEXEC_KHO`` config option is set to y
> +at compile team. Every KHO producer has its own config option that you

Should it be "at compile time."?
 


